Skip to main content

Segment Routing Policy for Traffic Engineering
draft-filsfils-spring-segment-routing-policy-03

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Clarence Filsfils , Siva Sivabalan , Syed Kamran Raza , Jose Liste , Francois Clad , Shraddha Hegde , Steven Lin , Alex Bogdanov , Martin Horneffer , Dirk Steinberg , Bruno Decraene , Stephane Litkowski
Last updated 2017-10-30
Replaced by draft-ietf-spring-segment-routing-policy, RFC 9256
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-filsfils-spring-segment-routing-policy-03
Internet-Draft                  SR Policy                   October 2017

11.2.  PCEP

   Please refer to [I-D.ietf-pce-pce-initiated-lsp]

11.3.  NETCONF

   Operator MUST be able to install policy via NETCONF with OpenConfig/
   YANG models (work in progress).

11.4.  CLI

   Operator MUST be able to install policy via CLI.

12.  Steering into an SR Policy

   A headend can steer a packet flow on an SR Policy in various ways:

   o  Incoming packets have an active SID matching a local BSID at the
      head-end.
   o  Incoming packets match a BGP/Service route which recurses on the
      BSID of a local policy.
   o  Incoming packets match a BGP/Service route which recurses on an
      array of paths to the BGP nhop where some of the paths in the
      array are local SR Policies.
   o  Incoming packets match a routing policy which directs them on a
      local SR policy.

   For simplicity of illustration, we will use the SR-MPLS example.

12.1.  Incoming Active SID is a BSID

   Let us assume that headend H has a local SR Policy P of Segment-list
   <S1, S2, S3> and BSID B.

   When H receives a packet with label stack <B, L2, L3>, H pops B and
   pushes <S1, S2, S3>.  H sends the resulting packet with label stack
   <S1, S2, S3, L2, L3> along the path to S1.

   The previous is an example assuming that S1 is the Prefix-SID of a
   remote node in the network.

   Actual programming of the first segment in the segment-list MUST take
   into accountthe type of segment represented by the SID.

   To illustrate the previous point, let us assume that headend H has a
   local SR Policy Q of Segment-list <S1, S2, S3> (where S1 is an Adj-
   SID at H) and BSID B.  When H receives a packet with label stack <B,
   L2, L3>, H pops B and pushes <S2, S3>.  H sends the resulting packet

Filsfils, et al.           Expires May 3, 2018                 [Page 21]
Internet-Draft                  SR Policy                   October 2017

   with label stack <S2, S3, L2, L3> along the outgoing interface(s)
   associated with Adj-SID S1.

   H has steered the packet in the policy P.

   H did not have to classify the packet.  The classification was done
   by a node upstream of H (e.g. the source of the packet or an
   intermediate ingress edge node of the SR domain) and the result of
   this classification was efficiently encoded in the packet header as a
   BSID.

   This is another key benefit of the segment routing in general and the
   binding SID in particular: the ability to encode a classification and
   the resulting steering in the packet header such as to better scale
   and simplify intermediate aggregation nodes.

12.2.  Recursion on a BSID

   Let us assume that headend H:

   o  learns about a BGP route R/r via next-hop N, extended-color
      community C and label V.
   o  has a local SR Policy P to (endpoint = N, color = C) of Segment-
      list <S1, S2, S3> and BSID B.
   o  has a local BGP policy which matches on the extended-color
      community C and allows its usage as an SR-TE SLA steering
      information.

   In such a case, H installs R/r in RIB/FIB with next-hop = B (instead
   of N).

   Indeed, H's local BGP policy and the received BGP route indicate that
   the headend should associate R/r with an SR-TE path to N with the SLA
   associated with color C.  The headend therefore installs the BGP
   route on that policy.

   This can be implemented by using the BSID as a generalized nhop and
   installing the BGP route on that generalized next-hop.

   When H receives a packet with a destination matching R/r, H pushes
   the label stack <S1, S2, S3, V> and sends the resulting packet along
   the path to S1.

   Note that any label associated with the BGP route is pushed after the
   Segment-list of the SR Policy.

Filsfils, et al.           Expires May 3, 2018                 [Page 22]
Internet-Draft                  SR Policy                   October 2017

12.2.1.  Multiple Colors

   When a BGP route has multiple extended-color communities each with a
   valid SRTE policy, the BGP process installs the route on the Binding
   SID corresponding to the SR policy whose color is of highest
   numerical value.

   Let us assume that headend H:

   o  learns about a BGP route R/r via next-hop N, extended-color
      communities C1 and C2 and label V.
   o  has a local SR Policy P1 to (endpoint = N, color = C1) of SID list
      <S1, S2, S3> and BSID B1.
   o  has a local SR Policy P2 to (endpoint = N, color = C2) of SID list
      <S4, S5, S6> and BSID B2.
   o  has a local BGP policy which matches on the extended-color
      communities C1 and C2 and allows their usage as an SR-TE SLA
      steering information.

   In such a case, H installs R/r in RIB/FIB with next-hop = B2 (instead
   of N) because C2 > C1.

12.3.  Recursion on an on-demand dynamic BSID

   In the previous section, we assumed that H had a pre-established
   "explicit" SR Policy (endpoint N, color C).

   In this section,independently to the a-priori existence of any
   explicit path of the SR policy (N, C), we note that the BGP process
   at node H triggers the SRTE process at node H to instantiate a
   dynamic path for the SR policy (N, C) as soon as:

   o  the BGP process learns of a route R/r via N and with color C.
   o  a local policy at node H authorizes the on-demand SRTE path
      instantiation and maps the color to a dynamic SRTE optimization
      template.

12.3.1.  Multiple Colors

   When a BGP route R/r via N has multiple extended-color communities Ci
   (with i=1 ... n), an individual on-demand SR-TE dynamic path request
   (endpoint N, color Ci) is triggered for each color Ci.

12.4.  An array of BSIDs associated with an IGP entry

   Let us assume that head-end H:

   o  learns about a BGP route R/r via next-hop N and label V.

Filsfils, et al.           Expires May 3, 2018                 [Page 23]
Internet-Draft                  SR Policy                   October 2017

   o  has a local SR Policy P1 to (endpoint = N, color = C1) of Segment-
      list <S1, S2, S3> and BSID B1.
   o  has a local SR Policy P2 to (endpoint = N, color = C2) of Segment-
      list <S4, S5, S6> and BSID B2.
   o  is configured to instantiate an array of paths to N where the
      entry 0 is the IGP path to N, color C1 is the first entry and
      Color C2 is the second entry.  The index into the array is called
      a Forwarding Class (FC).  The index can have values 0 to 7.
   o  is configured to match flows in its ingress interfaces (upon any
      field such as Ethernet destination/source/vlan/tos or IP
      destination/source/DSCP or transport ports etc.) and color them
      with an internal per-packet forwarding-class variable (0, 1 or 2
      in this example).

   In such a case, H installs in RIB/FIB:

   o  R/r in with next-hop N (as usual).
   o  N via a recursion on an array A (instead of the immediate outgoing
      link associated with the IGP shortest-path to N.
   o  Entry A(0) set to the immediate outgoing link of the IGP shortest-
      path to N.
   o  Entry A(1) set to B1.
   o  Entry A(2) set to B2.

   H receives three packets P, P1 and P2 on its incoming interface.  H
   colors them respectively with forwarding-class 0, 1 and 2.  As a
   result:

   o  H pushes <V> on packet P and forwards the resulting frame along
      the shortest-path to N (which in SR-MPLS results in the pushing of
      the prefix-SID of N.
   o  H pushes <S1, S2, S3, V> on packet P1 and forwards the resulting
      frame along the shortest-path to S1.
   o  H pushes <S4, S5, S6, V> on packet P2 and forwards the resulting
      frame along the shortest-path to S4.

   If the local configuration does not specify any explicit forwarding
   information for an entry of the array, then this entry is filled with
   the same information as entry 0 (i.e. the IGP shortest-path).

   This realizes per-flow steering: different flows bound to the same
   BGP destination R/r are steered on different SR-TE paths.

12.5.  A Routing Policy on a BSID

   Finally, headend H may be configured with a local routing policy
   which overrides any BGP/IGP path and steer a specified flow on an SR
   Policy.

Filsfils, et al.           Expires May 3, 2018                 [Page 24]
Internet-Draft                  SR Policy                   October 2017

13.  Optional Steering Modes for BGP Destinations

13.1.  Color-Only BGP Destination Steering

   In the previous section "Recursion on a BSID", we have seen that the
   steering on an SR Policy is governed by the matching of the BGP
   route's next-hop N and the authorized color C with a local SR Policy
   defined by the tuple (N, C).

   This is the most likely form of BGP destination steering and the one
   we recommend.

   In this section, we define an alternative steering mechanism based
   only on the color.

   This color-only steering variation is governed by two new flags "C"
   and "O" defined in the color extended community.

   The Color-Only flags "CO" are set to 00 by default.

   When 00, the BGP destination is preferably steered onto a valid SR
   Policy (N, C) where N is an IPv4/6 endpoint address and C is a color
   value else it is steered on the IGP path to the next-hop N.  This is
   the classic case we described before and that we recommend.

   When 01, the BGP destination is preferably steered onto a valid SR
   Policy (N, C) else onto a valid SR Policy (null endpoint, C) of the
   same address-family of N else on any valid SR Policy (any null
   endpoint, C) else on the IGP path to the next-hop N.

   When 10, the BGP destination is preferably steered onto a valid SR
   Policy (N, C) else onto a valid SR Policy (null endpoint, C) of the
   same address-family of N else on any valid SR Policy (any null
   endpoint, C) else on any valid SR Policy (any endpoint, C) of the
   same address-family of N else on any valid SR Policy (any endpoint,
   C) else on the IGP path to the next-hop N.

   The null endpoint is 0.0.0.0 for IPv4 and ::0 for IPv6 (all bits set
   to the 0 value).

   When 11, it is treated like 00.

13.2.  Drop on Invalid

   The local BGP policy authorizing the use of an extended color
   community steering on an SR policy may specify that if the related SR
   Policy becomes invalid then the related BSID should remain in RIB/FIB
   and point to null0 (drop any packet recursing on that BSID).

Filsfils, et al.           Expires May 3, 2018                 [Page 25]
Internet-Draft                  SR Policy                   October 2017

   Recall that, by default, for a BGP route R/r via next-hop N with
   extended-color community C, when the SR Policy (N, C) becomes
   invalid, then BGP re-installs R/r in RIB/FIB via N (the IGP path to
   N).

14.  Multipoint SR Policy

14.1.  Spray SR Policy

   A Spray SR-TE policy is a variant of an SR-TE policy which involves
   packet replication.

   Any traffic steered into a Spray SR Policy is replicated along the
   Segment-lists of its selected path.

   In the context of a Spray SR Policy, the selected path SHOULD have
   more than one Segment-list.  The weights of the Segment-lists is not
   applicable for a Spray SR Policy.  They MUST be set to 1.

   Like any SR policy, a Spray SR Policy has a BSID instantiated into
   the forwarding plane.

   Traffic is typically steered into a Spray SR Policy in two ways:

   o  local policy-based routing at the headend of the policy.
   o  remote classification and steering via the BSID of the Spray SR
      Policy.

15.  Reporting SR Policy

   Stateful PCEP ([I-D.ietf-pce-stateful-pce] and
   [I-D.sivabalan-pce-binding-label-sid] provides an ability for head-
   end to report BSID, attributes, and operational/administrative
   states.  Using this protocol, a PCE can also update an existing SR
   Policy whose path computation is delegated to it as well as
   instantiate new SR Policy on a head-end.

   BGP-LS reports an SR Policy via ([I-D.ietf-idr-te-lsp-distribution]

16.  Work in Progress

   o  Open configuration model.
   o  Yang model.

Filsfils, et al.           Expires May 3, 2018                 [Page 26]
Internet-Draft                  SR Policy                   October 2017

17.  Acknowledgement

18.  Normative References

   [GLOBECOM]
              Filsfils, C., Nainar, N., Pignataro, C., Cardona, J., and
              P. Francois, "The Segment Routing Architecture, IEEE
              Global Communications Conference (GLOBECOM)", 2015.

   [I-D.ietf-idr-te-lsp-distribution]
              Previdi, S., Dong, J., Chen, M., Gredler, H., and j.
              jefftant@gmail.com, "Distribution of Traffic Engineering
              (TE) Policies and State using BGP-LS", draft-ietf-idr-te-
              lsp-distribution-07 (work in progress), July 2017.

   [I-D.ietf-isis-segment-routing-extensions]
              Previdi, S., Filsfils, C., Bashandy, A., Gredler, H.,
              Litkowski, S., Decraene, B., and j. jefftant@gmail.com,
              "IS-IS Extensions for Segment Routing", draft-ietf-isis-
              segment-routing-extensions-13 (work in progress), June
              2017.

   [I-D.ietf-pce-pce-initiated-lsp]
              Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
              Extensions for PCE-initiated LSP Setup in a Stateful PCE
              Model", draft-ietf-pce-pce-initiated-lsp-11 (work in
              progress), October 2017.

   [I-D.ietf-pce-segment-routing]
              Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
              and J. Hardwick, "PCEP Extensions for Segment Routing",
              draft-ietf-pce-segment-routing-10 (work in progress),
              October 2017.

   [I-D.ietf-pce-stateful-pce]
              Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP
              Extensions for Stateful PCE", draft-ietf-pce-stateful-
              pce-21 (work in progress), June 2017.

   [I-D.ietf-spring-segment-routing]
              Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
              Litkowski, S., and R. Shakir, "Segment Routing
              Architecture", draft-ietf-spring-segment-routing-13 (work
              in progress), October 2017.

Filsfils, et al.           Expires May 3, 2018                 [Page 27]
Internet-Draft                  SR Policy                   October 2017

   [I-D.previdi-idr-segment-routing-te-policy]
              Previdi, S., Filsfils, C., Mattes, P., Rosen, E., and S.
              Lin, "Advertising Segment Routing Policies in BGP", draft-
              previdi-idr-segment-routing-te-policy-07 (work in
              progress), June 2017.

   [I-D.sivabalan-pce-binding-label-sid]
              Sivabalan, S., Filsfils, C., Previdi, S., Tantsura, J.,
              Hardwick, J., and D. Dhody, "Carrying Binding Label/
              Segment-ID in PCE-based Networks.", draft-sivabalan-pce-
              binding-label-sid-03 (work in progress), July 2017.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [SIGCOMM]  Hartert, R., Vissicchio, S., Schaus, P., Bonaventure, O.,
              Filsfils, C., Telkamp, T., and P. Francois, "A Declarative
              and Expressive Approach to Control Forwarding Paths in
              Carrier-Grade Networks, ACM SIGCOMM", 2015.

Authors' Addresses

   Clarence Filsfils
   Cisco Systems, Inc.
   Pegasus Parc
   De kleetlaan 6a, DIEGEM  BRABANT 1831
   BELGIUM

   Email: cfilsfil@cisco.com

   Siva Sivabalan
   Cisco Systems, Inc.
   2000 Innovation Drive
   Kanata, Ontario  K2K 3E8
   Canada

   Email: msiva@cisco.com

Filsfils, et al.           Expires May 3, 2018                 [Page 28]
Internet-Draft                  SR Policy                   October 2017

   Kamran Raza
   Cisco Systems, Inc.
   2000 Innovation Drive
   Kanata, Ontario  K2K 3E8
   Canada

   Email: skraza@cisco.com

   Jose Liste
   Cisco Systems, Inc.
   821 Alder Drive
   Milpitas, California  95035
   USA

   Email: jliste@cisco.com

   Francois Clad
   Cisco Systems, Inc.

   Email: fclad@cisco.com

   Shraddha Hegde
   Juniper Networks, Inc.
   Embassy Business Park
   Bangalore, KA  560093
   India

   Email: shraddha@juniper.net

   Daniel Voyer
   Bell Canada.
   671 de la gauchetiere W
   Montreal, Quebec  H3B 2M8
   Canada

   Email: daniel.voyer@bell.ca

   Steven Lin
   Google, Inc.

   Email: stevenlin@google.com

Filsfils, et al.           Expires May 3, 2018                 [Page 29]
Internet-Draft                  SR Policy                   October 2017

   Alex Bogdanov
   Google, Inc.

   Email: bogdanov@google.com

   Martin Horneffer
   Deutsche Telekom

   Email: martin.horneffer@telekom.de

   Dirk Steinberg
   Steinberg Consulting

   Email: dws@steinbergnet.net

   Bruno Decraene
   Orange Business Services

   Email: bruno.decraene@orange.com

   Stephane Litkowski
   Orange Business Services

   Email: stephane.litkowski@orange.com

Filsfils, et al.           Expires May 3, 2018                 [Page 30]