IDR Working Group Yao. Liu Internet-Draft Shaofu. Peng Intended status: Standards Track ZTE Corporation Expires: September 28, 2020 March 27, 2020 BGP Extensions for Unified SID in TE Policy draft-liu-idr-segment-routing-te-policy-complement-01 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 September 28, 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 September 28, 2020 [Page 1] Internet-Draft BGP for Unified SID March 2020 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. SR policy with Unified SID . . . . . . . . . . . . . . . . . 2 2.1. BGP Extensions . . . . . . . . . . . . . . . . . . . . . 4 2.2. Controller Processing . . . . . . . . . . . . . . . . . . 5 2.3. Head-end Processing . . . . . . . . . . . . . . . . . . . 6 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Normative References . . . . . . . . . . . . . . . . . . 7 5.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 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 September 28, 2020 [Page 2] Internet-Draft BGP for Unified SID March 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 September 28, 2020 [Page 3] Internet-Draft BGP for Unified SID March 2020 2.1. BGP Extensions This document defines two flags in the segment-list sub-TLV [I-D.ietf-idr-segment-routing-te-policy] RESERVED field, where, T-Flag: Truncatured-Flag, one bit, when set, it indicates there are truncated piece information of classical IPv6 SID in the SR path. FSU-Flag: First SID UET flag, two bits, it indicates the UET type of the first SID, in other words, indicates the UET domain constructed by the headend and the first segment node. 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: T-Flag in Segment List 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: Length Type Field in Segment sub-TLV Where SSI: SID Structure Indication, 3-bit field with the following values: 000 unknown 001 BL=96bits, NBL=32bits, Liu & Peng Expires September 28, 2020 [Page 4] Internet-Draft BGP for Unified SID March 2020 010 BL=64bits, NBL=32bits, 011 BL=32bits, NBL=32bits, Other values are 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, 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. The value refers to [I-D.mirsky-6man-unified-id-sr]. 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 Liu & Peng Expires September 28, 2020 [Page 5] Internet-Draft BGP for Unified SID March 2020 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. 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 September 28, 2020 [Page 6] Internet-Draft BGP for Unified SID March 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-07 (work in progress), March 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-14 (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 September 28, 2020 [Page 7] Internet-Draft BGP for Unified SID March 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 September 28, 2020 [Page 8]