--- 1/draft-ietf-idr-segment-routing-te-policy-06.txt 2019-07-06 06:13:09.943294698 -0700 +++ 2/draft-ietf-idr-segment-routing-te-policy-07.txt 2019-07-06 06:13:10.019296971 -0700 @@ -1,27 +1,26 @@ -Network Working Group S. Previdi, Ed. +Network Working Group S. Previdi Internet-Draft Individual Intended status: Standards Track C. Filsfils -Expires: November 21, 2019 Cisco Systems, Inc. - D. Jain, Ed. - Google +Expires: January 6, 2020 Cisco Systems, Inc. P. Mattes Microsoft E. Rosen Juniper Networks + D. Jain S. Lin Google - May 20, 2019 + July 5, 2019 Advertising Segment Routing Policies in BGP - draft-ietf-idr-segment-routing-te-policy-06 + draft-ietf-idr-segment-routing-te-policy-07 Abstract This document defines a new BGP SAFI with a new NLRI in order to advertise a candidate path of a Segment Routing Policy (SR Policy). An SR Policy is a set of candidate paths, each consisting of one or more segment lists. The headend of an SR Policy may learn multiple candidate paths for an SR Policy. Candidate paths may be learned via a number of different mechanisms, e.g., CLI, NetConf, PCEP, or BGP. This document specifies the way in which BGP may be used to @@ -36,21 +35,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on November 21, 2019. + This Internet-Draft will expire on January 6, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -66,49 +65,49 @@ 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 2. SR Policy Encoding . . . . . . . . . . . . . . . . . . . . . 5 2.1. SR Policy SAFI and NLRI . . . . . . . . . . . . . . . . . 5 2.2. SR Policy and Tunnel Encapsulation Attribute . . . . . . 7 2.3. Remote Endpoint and Color . . . . . . . . . . . . . . . . 8 2.4. SR Policy Sub-TLVs . . . . . . . . . . . . . . . . . . . 9 2.4.1. Preference Sub-TLV . . . . . . . . . . . . . . . . . 9 2.4.2. Binding SID Sub-TLV . . . . . . . . . . . . . . . . . 10 2.4.3. Segment List Sub-TLV . . . . . . . . . . . . . . . . 11 2.4.4. Explicit NULL Label Policy Sub-TLV . . . . . . . . . 27 - 2.4.5. Policy Priority Sub-TLV . . . . . . . . . . . . . . . 28 + 2.4.5. Policy Priority Sub-TLV . . . . . . . . . . . . . . . 29 2.4.6. Policy Name Sub-TLV . . . . . . . . . . . . . . . . . 29 3. Extended Color Community . . . . . . . . . . . . . . . . . . 30 - 4. SR Policy Operations . . . . . . . . . . . . . . . . . . . . 30 - 4.1. Configuration and Advertisement of SR Policies . . . . . 30 + 4. SR Policy Operations . . . . . . . . . . . . . . . . . . . . 31 + 4.1. Configuration and Advertisement of SR Policies . . . . . 31 4.2. Reception of an SR Policy NLRI . . . . . . . . . . . . . 31 4.2.1. Acceptance of an SR Policy NLRI . . . . . . . . . . . 31 4.2.2. Usable SR Policy NLRI . . . . . . . . . . . . . . . . 32 4.2.3. Passing a usable SR Policy NLRI to the SRPM . . . . . 32 - 4.2.4. Propagation of an SR Policy . . . . . . . . . . . . . 32 + 4.2.4. Propagation of an SR Policy . . . . . . . . . . . . . 33 4.3. Flowspec and SR Policies . . . . . . . . . . . . . . . . 33 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 33 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 34 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 8.1. Existing Registry: Subsequent Address Family Identifiers - (SAFI) Parameters . . . . . . . . . . . . . . . . . . . . 35 + (SAFI) Parameters . . . . . . . . . . . . . . . . . . . . 36 8.2. Existing Registry: BGP Tunnel Encapsulation Attribute - Tunnel Types . . . . . . . . . . . . . . . . . . . . . . 35 + Tunnel Types . . . . . . . . . . . . . . . . . . . . . . 36 8.3. Existing Registry: BGP Tunnel Encapsulation Attribute - sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . 35 + sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . 36 8.4. New Registry: SR Policy List Sub-TLVs . . . . . . . . . . 36 - 8.5. New Registry: SR Policy Binding SID Flags . . . . . . . . 36 + 8.5. New Registry: SR Policy Binding SID Flags . . . . . . . . 37 8.6. New Registry: SR Policy Segment Flags . . . . . . . . . . 37 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 37 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 37 - 10.2. Informational References . . . . . . . . . . . . . . . . 38 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 38 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 38 + 10.2. Informational References . . . . . . . . . . . . . . . . 39 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 1. Introduction Segment Routing (SR) allows a headend node to steer a packet flow along any path. Intermediate per-flow states are eliminated thanks to source routing [I-D.ietf-spring-segment-routing]. The headend node is said to steer a flow into a Segment Routing Policy (SR Policy). @@ -1220,27 +1219,32 @@ o A-Flag is applicable to Segment Types 3, 4 and 9. If A-Flag appears with any other Segment Type, it MUST be ignored. 2.4.4. Explicit NULL Label Policy Sub-TLV In order to steer an unlabeled IP packet into an SR policy, it is necessary to create a label stack for that packet, and to push one or more labels onto that stack. - The Explicit NULL Label Policy sub-TLV is used to indicate whether an - Explicit NULL Label [RFC3032] must be pushed on an unlabeled IP - packet before any other labels. + The Explicit NULL Label Policy (ENLP) sub-TLV is used to indicate + whether an Explicit NULL Label [RFC3032] must be pushed on an + unlabeled IP packet before any other labels. - If an Explicit NULL Label Policy Sub-TLV is not present, the decision - of whether to push an Explicit NULL label on a given packet is a - matter of local policy. + If an ENLP Sub-TLV is not present, the decision of whether to push an + Explicit NULL label on a given packet is a matter of local + configuration. + + The ENLP sub-TLV is optional and it MUST NOT appear more than once in + the SR Policy. If the ENLP sub-TLV appears more than once, the + update is considered malformed and the "treat-as-withdraw" strategy + of [RFC7606] is applied. The contents of this sub-TLV are used by the SRPM as described in section 4.1 in [I-D.ietf-spring-segment-routing-policy]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Flags | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ENLP | @@ -1259,36 +1263,45 @@ receipt. RESERVED: 1 octet of reserved bits. SHOULD be unset on transmission and MUST be ignored on receipt. ENLP(Explicit NULL Label Policy): Indicates whether Explicit NULL labels are to be pushed on unlabeled IP packets that are being steered into a given SR policy. This field has one of the following 4 values: + 0: Reserved. + 1: Push an IPv4 Explicit NULL label on an unlabeled IPv4 packet, but do not push an IPv6 Explicit NULL label on an unlabeled IPv6 packet. 2: Push an IPv6 Explicit NULL label on an unlabeled IPv6 packet, but do not push an IPv4 Explicit NULL label on an unlabeled IPv4 packet. 3: Push an IPv4 Explicit NULL label on an unlabeled IPv4 packet, and push an IPv6 Explicit NULL label on an unlabeled IPv6 packet. 4: Do not push an Explicit NULL label. + 5 - 255: Reserved. + + The ENLP reserved values may be used for future extensions and + implementations SHOULD ignore the ENLP Sub-TLV with these values. + The policy signaled in this Sub-TLV MAY be overridden by local - policy. + configuration. The section 4.1 of + [I-D.ietf-spring-segment-routing-policy] draft describes the + behavior on the headend for handling of explicit null label. 2.4.5. Policy Priority Sub-TLV An operator MAY set the Policy Priority sub-TLV to indicate the order in which the SR policies are re-computed upon topological change. The Priority sub-TLV does not have any effect on the BGP bestpath selection or propagation procedures. The contents of this sub-TLV are used by the SRPM as described in section 2.11 in [I-D.ietf-spring-segment-routing-policy]. @@ -1502,20 +1515,31 @@ ([RFC5575]). In this case, when the redirect to IP next-hop is specified as in [I-D.ietf-idr-flowspec-redirect-ip], the tunnel to the next-hop is specified by the segment list in the Segment List sub-TLVs. The Segment List (e.g., label stack or IPv6 segment list) is imposed to flows matching the criteria in the Flowspec route to steer them towards the next-hop as specified in the SR Policy SAFI NLRI. 5. Contributors + Kausik Majumdar + Cisco Systems + US + + Email: kmajumda@cisco.com + + Zafar Ali + Cisco Systems + US + + Email: zali@cisco.com Arjun Sreekantiah Cisco Systems US Email: asreekan@cisco.com Acee Lindem Cisco Systems US @@ -1691,23 +1715,23 @@ 9. Security Considerations TBD. 10. References 10.1. Normative References [I-D.ietf-idr-tunnel-encaps] - Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel - Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-11 - (work in progress), February 2019. + Patel, K., Velde, G., Ramachandra, S., and E. Rosen, "The + BGP Tunnel Encapsulation Attribute", draft-ietf-idr- + tunnel-encaps-12 (work in progress), May 2019. [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-16 (work in progress), March 2019. [I-D.ietf-spring-segment-routing] Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing @@ -1761,70 +1785,70 @@ 10.2. Informational References [I-D.filsfils-spring-sr-policy-considerations] Filsfils, C., Talaulikar, K., Krol, P., Horneffer, M., and P. Mattes, "SR Policy Implementation and Deployment Considerations", draft-filsfils-spring-sr-policy- considerations-03 (work in progress), April 2019. [I-D.ietf-6man-segment-routing-header] - Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and - d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header - (SRH)", draft-ietf-6man-segment-routing-header-18 (work in - progress), April 2019. + Filsfils, C., Dukes, D., Previdi, S., Leddy, J., + Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment + Routing Header (SRH)", draft-ietf-6man-segment-routing- + header-21 (work in progress), June 2019. [I-D.ietf-idr-flowspec-redirect-ip] Uttaro, J., Haas, J., Texier, M., Andy, A., Ray, S., Simpson, A., and W. Henderickx, "BGP Flow-Spec Redirect to IP Action", draft-ietf-idr-flowspec-redirect-ip-02 (work in progress), February 2015. [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . Authors' Addresses - Stefano Previdi (editor) + Stefano Previdi Individual IT Email: stefano@previdi.net Clarence Filsfils Cisco Systems, Inc. Brussels BE Email: cfilsfil@cisco.com - Dhanendra Jain (editor) - Google - - Email: dhanendra.ietf@gmail.com Paul Mattes Microsoft One Microsoft Way Redmond, WA 98052 USA Email: pamattes@microsoft.com Eric Rosen Juniper Networks 10 Technology Park Drive Westford, MA 01886 US Email: erosen@juniper.net + Dhanendra Jain + Google + + Email: dhanendra.ietf@gmail.com Steven Lin Google Email: stevenlin@google.com