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]