IDR Working Group Yao. Liu Internet-Draft Shaofu. Peng Intended status: Standards Track ZTE Corporation Expires: November 4, 2020 May 3, 2020 BGP Extensions for Unified SID in TE Policy draft-liu-idr-segment-routing-te-policy-complement-02 Abstract This document defines extensions to BGP in order to advertise Unified SIDs in SR-TE policies. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 4, 2020. Copyright Notice Copyright (c) 2020 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Liu & Peng Expires November 4, 2020 [Page 1] Internet-Draft BGP for Unified SID May 2020 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. SR policy with Unified SID . . . . . . . . . . . . . . . . . 2 2.1. BGP Extensions . . . . . . . . . . . . . . . . . . . . . 4 2.1.1. Extension of Segment List sub-TLV . . . . . . . . . . 4 2.1.2. Advertisement of SID Attribute . . . . . . . . . . . 5 2.2. Controller Processing . . . . . . . . . . . . . . . . . . 8 2.3. Head-end Processing . . . . . . . . . . . . . . . . . . . 9 3. Security Considerations . . . . . . . . . . . . . . . . . . . 10 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Normative References . . . . . . . . . . . . . . . . . . 10 5.2. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction Segment Routing [RFC8402] leverages the source routing paradigm. An ingress node steers a packet through an ordered list of instructions,called segments. [I-D.ietf-spring-segment-routing-policy] details the concepts of SR Policy and steering into an SR Policy. [I-D.ietf-idr-segment-routing-te-policy] specifies the way to use BGP to distribute one or more of the candidate paths of an SR Policy to the headend of that policy. With increasing requirements for a shortened identifier in a segment routing network with the IPv6 data plane, [I-D.mirsky-6man-unified-id-sr] proposed an extension of SRH that enables the use of a shorter segment identifier, such as 32-bits Label format SID or 32-bits IP address format SID. This document defines extensions to BGP in order to advertise Unified SIDs in SR-TE policies. Firstly, we focus on how to carry 32-bits IP address format U-SID, other type of U-SID (such as 16-bits) will be considered in future version. 2. SR policy with Unified SID As discussed in [I-D.ietf-spring-srv6-network-programming], the node with the SRv6 capability will maintain its local SID table. A Local SID is generally composed of two parts, that is, LOC:FUNCT, or may carry arguments at the same time, that is, LOC:FUNCT:ARGS. Liu & Peng Expires November 4, 2020 [Page 2] Internet-Draft BGP for Unified SID May 2020 FUNCT indicates the local function of the packet on the node that generates the LOC.ARGS may contain information related to traffic and services, or any other information required for executing the function.LOC indicates locator. In most cases, other nodes in the network can forward packets to the node that generates this LOC according to the corresponding routing table entries. The controller plane protocol can also use B:N to represent an LOC, where B is SRv6 SID Locator Block and N to represent node N. In other words, the structure of a complete SID is B:N:FUNCT:ARGS. [I-D.ietf-lsr-isis-srv6-extensions] defines the extension of ISIS to support SRv6, and each node can announce the SID assigned by itself. In particular, SRv6 SID Structure Sub-Sub-TLV is defined and the specific structure of the corresponding SID is provided, including the length of SRv6 SID Locator Block, the length of SRv6 SID Locator Node, the length of SRv6 SID Function, and the length of SRv6 SID Arguments. Similarly, [I-D.ietf-bess-srv6-services] also provide the SID structure information for L3VPN or EVPN service related SID. Thus, it can be seen that the existing control plane protocol reveals a very intuitive method to reduce the size of SRH. That is , under the specific address planning(the SIDs allocated by all SRv6 nodes are in the same SRv6 SID Locator Block), SRH only needs to store the difference between SIDs (N:FUNCT:ARGS), and does not need to contain the SRv6 SID Locator Block information. In a 128-bit classic SRv6 SID, the highest part is SRv6 SID Locator Block, and the following 32 bits are composed of SRv6 SID Locator Node, SRv6 SID Function and SRv6 SID Arguments, and the rest bits are zeros. As for how to obtain the SRv6 SID Locator Block information during packet forwarding, there maybe three cases: 1)For the head-end node, when the node sends a packet along the segment list to the first segment, it already knows the 128-bit classical SID before truncating. The head node copies it directly to the DA of IPv6 Header, but the SRH carries the 32-bit truncatured SIDs. 2)For the normal transit node, it can obtain the SRv6 SID Locator Block information from the DA of the received IPv6 packet. 3)For the inter-domain border node, it can obtain the new SRv6 SID Locator Block information from the local SID entry. Liu & Peng Expires November 4, 2020 [Page 3] Internet-Draft BGP for Unified SID May 2020 2.1. BGP Extensions 2.1.1. Extension of Segment List sub-TLV This document defines two flags in the segment-list sub-TLV [I-D.ietf-idr-segment-routing-te-policy] RESERVED field. 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 |T|FSU|RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // sub-TLVs // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Extension of Segment List sub-TLV where, T-Flag: Truncatured-Flag, one bit, when set, it indicates there are truncated piece information of classical IPv6 SID in the SR path, and the headend MUST take account of the truncated piece information to get an optimized U-SID list, otherwise the headend does not need to perform compression action. It should be noted that if T-Flag is set but the headend can not support to process it, the headend MUST withdraw the entire segment-list sub-TLV and SHOULD log an error for it, in other words, the headend MUST NOT take the SRv6 SID list included in the segment-list sub-TLV as a classical SID list used for traditional forwarding. FSU-Flag: First SID UET flag, two bits, it indicates how to compress the first SID. It could be the following values: 0: the first SID does not need compression and remains 128 bits. 1: the first SID needs to be compressed to a 32-bit IP address. 2: the first SID needs to be compressed to a 32-bit MPLS Label. 3: the first SID needs to be compressed to a 16-bit IP address. The value set in FSU-Flag field need consider two factors: the UET domain constructed by the headend and the first segment node, and whether the structure information of the first SID support to be compressed according the FSU-Flag. Liu & Peng Expires November 4, 2020 [Page 4] Internet-Draft BGP for Unified SID May 2020 Optionally, no matter how FSU-Flag field is set, the headend can use reduced SRH that exclude the first SID, to further reduce the cost of SRH. 2.1.2. Advertisement of SID Attribute The U-SID solution defined in [I-D.mirsky-6man-unified-id-sr] reply two attributes of SID, they are: SID structure attribute and Endpoint Behavior attribute. However, [I-D.ietf-idr-segment-routing-te-policy] does not provide these information now. This document discusses two options to supplement these information. 2.1.2.1. Option 1: Advertisement SID Attribute with segment sub-TLV In this document, the Flags field of each segment sub-TLV(type B/I/J/ K) [I-D.ietf-idr-segment-routing-te-policy] is extended to indicate the block length (BL) and non-block length (NBL) of a 128-bit SID, that is a simple representation of SID structure information. Figure 2 uses the type B segment sub-TLV as an example to illustrate the extended SSI field. Other types of segment sub-TLV are similar. 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 |V|A| SSI |UET| | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // SRv6 SID (16 octets) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Supplement Attribute in Segment sub-TLV Where SSI: SID Structure Indication, 3-bit field with the following values: 0: SID structure information is unknown. 1: In SRv6 SID, the length of Block is 96-bits, the sum length of Node, Function, Args is 32-bits. 2: In SRv6 SID, the length of Block is 64-bits, the sum length of Node, Function, Args is 32-bits. 3: In SRv6 SID, the length of Block is 32-bits, the sum length of Node, Function, Args is 32-bits. Liu & Peng Expires November 4, 2020 [Page 5] Internet-Draft BGP for Unified SID May 2020 4~7: reserved for future use. It should be noted that NBL represents the length of the Node:Func:ARGs that is immediately followed the block. UET: U-SID Encapsulation Type Flag, 2-bit field, it indicates the UET type of the next SID, in other words, indicates the UET domain constructed by the current segment node and the next segment node. It could be the following values: 0: the UET domain following the current segment node is UET-128 domain, that means the next SID does not need compression and remains 128 bits. 1: the UET domain following the current segment node is UET-32 domain, that means the next SID needs to be compressed to a 32-bit IP address. 2: the UET domain following the current segment node is UET- 32-MPLS domain, that means the next SID needs to be compressed to a 32-bit MPLS Label. 3: the UET domain following the current segment node is UET-16 domain, that means the next SID needs to be compressed to a 16-bit IP address. The value set in UET field need consider two factors: the UET domain constructed by the current segment node and the next segment node, and whether the structure information of the next SID support to be compressed according the UET-Flag. 2.1.2.2. Option 2: Introducing segment attribute sub-TLV To meet the requirement of more attribute advertisement for later, it is necessary to introduce a new segment attribute sub-TLV included in Segment List sub-TLV. The segment attribute sub-TLV has the following format: 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 | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // ... ... // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: segment attribute sub-TLV format Liu & Peng Expires November 4, 2020 [Page 6] Internet-Draft BGP for Unified SID May 2020 Each type of attribute is an independent sub-sub-TLV included in segment attribute sub-TLV. Currently two attributes are defined. 2.1.2.2.1. SRv6 SID Structure Sub-Sub-TLV The SRv6 SID Structure Sub-Sub-TLV has the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |sub-Type=STRUCT| Length | Count | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BL of SID 1 | NL of SID 1 | FL of SID 1 | AL of SID 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BL of SID N | NL of SID N | FL of SID N | AL of SID N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: SRv6 SID Structure Sub-Sub-TLV format Where, Count: 1 octet, the count of segments. BL: 1 octet. SRv6 SID Locator Block length in bits. NL: 1 octet. SRv6 SID Locator Node length in bits. FL: 1 octet. SRv6 SID Function length in bits. AL: 1 octet. SRv6 SID Arguments length in bits. 2.1.2.2.2. Endpoint Behavior Sub-Sub-TLV The Endpoint Behavior Sub-Sub-TLV has the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-Type=EB | Length | Count | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Endpoint Behavior of SID 1 | Endpoint Behavior of SID 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... ... | Endpoint Behavior of SID N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Endpoint Behavior Sub-Sub-TLV format Where, Liu & Peng Expires November 4, 2020 [Page 7] Internet-Draft BGP for Unified SID May 2020 Count: 1 octet, the count of segments. Endpoint Behavior: 2 octet. The codepoints for the Endpoint behaviors are defined in the "SRv6 Endpoint Behaviors" registry defined in [I-D.ietf-spring-srv6-network-programming]. Especially, [I-D.mirsky-6man-unified-id-sr] also introduced some new flavors, i.e., UET-32 Flavor, UET-32-MPLS Flavor, UET-16 Flavor, for END, END.X behavior. 2.2. Controller Processing Controller can collect UET capability information of all nodes, see [I-D.mirsky-6man-unified-id-sr], each node can support one or more than one UET capabilities. In general, a border node that belongs to multiple UET domain will support multiple UET capabilities, while other nodes can only support a single UET capability. Controller can also collect SID per UET of all nodes. If a node support an UET capability, it will also allocate related SIDs for this UET Flavor. When controller computed an SR path, it can check the UET capability of each segment node within the segment list, to outline which UET domains the SR path crosses. For example, from Headend H to endpoint E, a segment list may cross two UET domains, the node H, X1, X2, X3, B all support UET-1, and the node B, Y1, Y2, Y3, E all support UET-2. In this case, the FSU-flag will be set to UET-1, it indicates the UET domian which the first SID X1 belongs to. At the same time, the controller will select UET related SID for each segment according to the UET domain which the segment node belongs to, i.e., the UET Flag of SID X1, X2, X3 will be set to UET-1, and the UET Flag of SID B, Y1, Y2, Y3, E will be se to UET-2. Note that in this case, SID B with UET-2 Flavor, but not UET-1 Flavor, is inserted in ths list for the purpose of seamless splicing. Then, controller need to check the structure information of each selected SID, to ensure they can safely construct an SID list with UET information. For example, the structure information of SID X1 (with UET-1 Flavor), SID X2 (with UET-1 Flavor), SID X3 (with UET-1 Flavor), SID B (with UET-2 Flavor), MUST support to get UET-1 (because the UET of prev SID is UET-1) related truncated piece information (Node:Func:ARGS) from the original IPv6 SID. Similarly, the structure information of SID Y1 (with UET-2 Flavor), SID Y2 (with UET-2 Flavor), SID Y3 (with UET-2 Flavor), SID E (with UET-2 Flavor), MUST support to get UET-2 (because the UET of prev SID is UET-2) related truncated piece information from the original IPv6 SID. Liu & Peng Expires November 4, 2020 [Page 8] Internet-Draft BGP for Unified SID May 2020 There maybe another segment list example, also cross two UET domains, that is, the node H, B all support UET-1, and the node B, Y1, Y2, Y3, E all support UET-2. In this case, the FSU- flag will be also set to UET-1, it indicates the UET domian which the first SID B belongs to. At the same time, the controller will select UET related SID for each segment according to the UET domain which the segment node belongs to, i.e., the UET Flag of SID B, Y1, Y2, Y3, E will be se to UET-2. Note that in this case, SID B with UET-2 Flavor, but not UET-1 Flavor, is inserted in ths list for the purpose of seamless splicing. Then, the controller check the structure information of each selected SID to ensure they can safely construct an SID list with UET information. That is, the structure information of SID B (with UET-2 Flavor), MUST support to get UET-1 (because the UET of prev SID is UET-1) related truncated piece information from the original IPv6 SID. Similarly, the structure information of SID Y1 (with UET-2 Flavor), SID Y2 (with UET-2 Flavor), SID Y3 (with UET-2 Flavor), SID E (with UET-2 Flavor), MUST support to get UET-2 (because the UET of prev SID is UET-2) related truncated piece information from the original IPv6 SID. If a SID can not support to get UET related truncated piece according to the UET of prev SID, the controller MUST select another prev SID with UET-0 flavor. 2.3. Head-end Processing When headend received the SR policy, for each segment list of the candidate path, if the Truncatured-Flag is set, the segment list could try to be optimized to an SID list that contains short U-SIDs. For each original SID within the received SID list, it will be optimized to an U-SID according to the UET of prev SID. For example, for the above segment list , the original SID X1 could be optimized to U-SID X1 according the UET of prev SID (in fact, it is FSU), get the truncated prev-UET related piece from the original SID with the help of its SSI field. Similarly, the original SID B could be optimized to U-SID B according the UET of prev SID X3, get the truncated prev-UET related piece from the original SID with the help of its SSI field. The SRH will contain the optimized U-SIDs, and the initial SRH.UET will be set as FSU. Other procedures refer to [I-D.mirsky-6man-unified-id-sr]. Liu & Peng Expires November 4, 2020 [Page 9] Internet-Draft BGP for Unified SID May 2020 3. Security Considerations Procedures and protocol extensions defined in this document do not affect the security considerations discussed in [I-D.ietf-idr-segment-routing-te-policy]. 4. IANA Considerations TBD 5. References 5.1. Normative References [I-D.ietf-idr-segment-routing-te-policy] Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., Rosen, E., Jain, D., and S. Lin, "Advertising Segment Routing Policies in BGP", draft-ietf-idr-segment-routing- te-policy-08 (work in progress), November 2019. [I-D.ietf-lsr-isis-srv6-extensions] Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and Z. Hu, "IS-IS Extension to Support Segment Routing over IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-08 (work in progress), April 2020. [I-D.ietf-spring-segment-routing-policy] Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", draft- ietf-spring-segment-routing-policy-06 (work in progress), December 2019. [I-D.ietf-spring-srv6-network-programming] Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "SRv6 Network Programming", draft-ietf-spring-srv6-network-programming-15 (work in progress), March 2020. [I-D.mirsky-6man-unified-id-sr] Cheng, W., Mirsky, G., Peng, S., Aihua, L., Wan, X., and C. Wei, "Unified Identifier in IPv6 Segment Routing Networks", draft-mirsky-6man-unified-id-sr-06 (work in progress), March 2020. [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . Liu & Peng Expires November 4, 2020 [Page 10] Internet-Draft BGP for Unified SID May 2020 5.2. Informative References [I-D.ietf-bess-srv6-services] Dawra, G., Filsfils, C., Raszuk, R., Decraene, B., Zhuang, S., and J. Rabadan, "SRv6 BGP based Overlay services", draft-ietf-bess-srv6-services-02 (work in progress), February 2020. Authors' Addresses Liu Yao ZTE Corporation No. 50 Software Ave, Yuhuatai Distinct Nanjing China Email: liu.yao71@zte.com.cn Peng Shaofu ZTE Corporation No. 50 Software Ave, Yuhuatai Distinct Nanjing China Email: peng.shaofu@zte.com.cn Liu & Peng Expires November 4, 2020 [Page 11]