SPRING Working Group W. Cheng Internet-Draft China Mobile Intended status: Standards Track Z. Li Expires: August 14, 2020 C. Li Huawei Technologies C. Xie C. Li China Telecom H. Tian F. Zhao CAICT February 11, 2020 Generalized SRv6 Network Programming draft-cl-spring-generalized-srv6-np-00 Abstract As the deployment of SRv6, some new requirements are proposed, such as SRv6 compression, transporting over SR-MPLS/MPLS and IPv4 domains. Therefore, it is necessary to consider other types of segments or sub-paths in the end-to-end SRv6 network programming. This document proposes Generalized Segment Routing over IPv6 (G-SRv6) Networking Programming, which supports to encode multiple types of Segments in a SRH, called Generalized SRH (G-SRH). These Segments can be called Generalized Segment, and the ID can be Generalized Segment Identifier (G-SID), which may include an SRv6 SID(128 bits), C-SIDs, MPLS labels, or IPv4 tunnel information. This document also defines the mechanisms of Generalized SRv6 Networking Programming and the requirements of related protocol extensions of control plane and data plane. 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 Cheng, et al. Expires August 14, 2020 [Page 1] Internet-Draft G-SRv6 February 2020 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 August 14, 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Crossing C-SRv6 Domains . . . . . . . . . . . . . . . . . 5 3.2. Crossing SR-MPLS Domains . . . . . . . . . . . . . . . . 7 3.3. Crossing IPv4 Domains . . . . . . . . . . . . . . . . . . 8 4. Concept of Generalized SRv6 . . . . . . . . . . . . . . . . . 9 4.1. SRv6 G-SID . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Compression G-SID . . . . . . . . . . . . . . . . . . . . 10 4.3. MPLS G-SID . . . . . . . . . . . . . . . . . . . . . . . 11 4.4. IPv4 G-SID . . . . . . . . . . . . . . . . . . . . . . . 12 5. G-SRv6 for Crossing SRv6 Compression Domains . . . . . . . . 13 5.1. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . 13 5.1.1. Compressable SID Indication . . . . . . . . . . . . . 13 5.1.2. C-SID Length Indication . . . . . . . . . . . . . . . 14 5.1.3. Start of Compression Indication . . . . . . . . . . . 14 5.1.4. End of Compression Indication . . . . . . . . . . . . 15 5.2. Illustration . . . . . . . . . . . . . . . . . . . . . . 16 5.3. Effect on SRv6 . . . . . . . . . . . . . . . . . . . . . 18 5.4. Protocol Extensions Requirements . . . . . . . . . . . . 19 5.4.1. Data Plane . . . . . . . . . . . . . . . . . . . . . 19 5.4.2. Control Plane . . . . . . . . . . . . . . . . . . . . 19 6. G-SRv6 for Crossing SR-MPLS Domain . . . . . . . . . . . . . 20 6.1. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . 20 6.1.1. Start of MPLS G-SID Indication . . . . . . . . . . . 20 Cheng, et al. Expires August 14, 2020 [Page 2] Internet-Draft G-SRv6 February 2020 6.1.2. End of MPLS G-SID Indication . . . . . . . . . . . . 21 6.2. Illustration . . . . . . . . . . . . . . . . . . . . . . 21 6.3. Effect on SRv6 . . . . . . . . . . . . . . . . . . . . . 22 6.4. Protocol Extensions Requirements . . . . . . . . . . . . 23 6.4.1. Data Plane . . . . . . . . . . . . . . . . . . . . . 23 6.4.2. Control Plane . . . . . . . . . . . . . . . . . . . . 23 7. G-SRv6 for Crossing IPv4 Domain . . . . . . . . . . . . . . . 24 7.1. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 24 7.1.1. Start of IPv4 G-SID Indication . . . . . . . . . . . 24 7.1.2. IPv4 G-SID encoding . . . . . . . . . . . . . . . . . 25 7.2. Illustration . . . . . . . . . . . . . . . . . . . . . . 25 7.3. Effect on SRv6 . . . . . . . . . . . . . . . . . . . . . 26 7.4. Protocol Extensions Requirements . . . . . . . . . . . . 26 7.4.1. Data Plane . . . . . . . . . . . . . . . . . . . . . 27 7.4.2. Control Plane . . . . . . . . . . . . . . . . . . . . 27 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 9. Security Considerations . . . . . . . . . . . . . . . . . . . 28 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 12.1. Normative References . . . . . . . . . . . . . . . . . . 28 12.2. Informative References . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 1. Introduction Segment routing (SR) [RFC8402] is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node by inserting an ordered list of instructions, called segments. When segment routing is deployed on the IPv6 data plane, it is called SRv6 [I-D.ietf-6man-segment-routing-header]. For support of SR, a new routing header called Segment Routing Header (SRH), which contains a list of SIDs and other information, has been defined in [I-D.ietf-6man-segment-routing-header]. In use cases like Traffic Engineering, an ordered SID List with multiple SIDs is inserted into the SRH to steer packets along an explicit path. As the deployment of SRv6, some new requirements are proposed, such as SRv6 compression, transporting over SR-MPLS/MPLS and IPv4 domains. Therefore, it is necessary to consider other types of segments or sub-paths in the end-to-end SRv6 network programming. This document proposes Generalized Segment Routing over IPv6 (G-SRv6) Networking Programming, which supports to encode multiple types of Segments in a SRH, called Generalized SRH (G-SRH). These Segments can be called Generalized Segment, and the ID can be Generalized Cheng, et al. Expires August 14, 2020 [Page 3] Internet-Draft G-SRv6 February 2020 Segment Identifier (G-SID), which may include an SRv6 SID(128 bits), C-SIDs, MPLS labels, or IPv4 tunnel information. This document also defines the mechanisms of Generalized SRv6 Networking Programming and the requirements of related protocol extensions of control plane and data plane. 2. Terminology This document makes use of the terms defined in [I-D.ietf-6man-segment-routing-header], [RFC8402] and [RFC8200], and the reader is assumed to be familiar with that terminology. This document introduces the following terms: SRv6 SID: The 128-bit segment identifier is introduced in [I-D.ietf-spring-srv6-network-programming]. It is always composed by locator, function and/or arguments. C-SRv6: Compressed SRv6 Network Programming Compressable SID: It is the 128-bit SRv6 SID which can be compressed. It is composed by Common Prefix and Compressed Segment Identifier (C-SID) and optional arguments. Common Prefix: It is the same prefix shared by multiple Compressable SIDs. C-SID: Compressed Segment Identifier [I-D.li-spring-compressed-srv6-np]. It is the remaining part of Compressable SID removing Common Prefix and arguments. The recommended length of C-SIDs is 32 bits. C-SRH: Compressed Segment Routing Header. It is the enhanced SRH used for C-SRv6. G-SRv6: Generalized SRv6 Network Programming G-SID: Generalized Segment Identifier. G-SRH: Generalized Segment Routing Header. It is the enhanced SRH used for G-SRv6. Compression G-SID: It is the G-SID for encapsulating C-SIDs. MPLS G-SID: It is the G-SID for encapsulating MPLS label stack encapsulation information. Cheng, et al. Expires August 14, 2020 [Page 4] Internet-Draft G-SRv6 February 2020 IPv4 G-SID: It is the G-SID for encapsulating IPv4 tunnel information. SRv6 Compression Sub-path: It is the path for crossing the SRv6 compression domain in the end-to-end G-SRv6 path. SR-MPLS Sub-path: It is the path for crossing the SR-MPLS domain in the end-to-end G-SRv6 path. IPv4 Tunnel Sub-path: It is the IPv4 tunnel path for crossing the IPv4 domain in the end-to-end G-SRv6 path. 2.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Requirements This section describes the requirements of G-SRv6. 3.1. Crossing C-SRv6 Domains The overhead of SIDs (16 bytes per SID) in SRH proposes challenges for packet processing and payload efficiency. For addressing this problem, some solutions are proposed. For example, [I-D.li-spring-compressed-srv6-np] proposes Compressed SRv6 Network programming(C-SRv6). In an SRv6 domain, the SIDs will be allocated from an address block, called SID space. For routing within an SRv6 domain, the SIDs may have the same prefix (Common Prefix). [I-D.li-spring-compressed-srv6-np] defines a compressed SID (C-SID) to carry the different part of the original SRv6 SID in the SRH. The format of a compressable SRv6 SID with 32 bit C-SID is shown in Figure 1. The argument part is specified by use cases, and it is zero by default. It is shared by the compressable SRv6 SIDs in a C-SRv6 sub-path Cheng, et al. Expires August 14, 2020 [Page 5] Internet-Draft G-SRv6 February 2020 0 Variable Length 32 bits 128 bits +--------------------------------------------------------------+ | Common Prefix | C-SID | Argument | +--------------------------------------------------------------+ |<-------- Locator ---------------->|<-FuncID->|<--Argument -->| |<--->| | Different part of Locator Figure 1. 32 bits C-SID in Compressable SRv6 SID In C-SRv6, the common prefix can be carried by the first SID in the IPv6 destination address, while only the C-SIDs of the original SIDs are carried in the C-SRH. In this way, the overhead of SRv6 can be reduced. C-SRv6 can reduce the overhead of SRH. But the C-SRv6 requires that all the SIDs of the SRv6 path to be the compressable SRv6 SID. The limitation causes that it does not work in the following scenarios: Scenario 1-1: In a single domain owing to the incremental deployment there will be the scenario in which some nodes can support C-SRv6 while others only support SRv6. This causes that the end-to-end SRv6 path may be composed by both SRv6 SIDs and Compressable SRv6 SIDs. In this case C-SRv6 cannot work and SRH has to be used for the SRv6 path. For example, as illustrated in Figure 2, a packet is forwarded along the path A1->A2->A3->A4->A5->A6->A7, and the SRv6 SID list is [A::1:1, A::2:1, A::3:1, A::4:1, A::5:1, A6::6:1, A::7:10]. All the nodes along the path support compression except A6. In this case, the SID list can not be compressed due to A6 does not support compression. (A::3:1) A3------A4 (A::4:1) | | (A::2:1) A2 A5 (A::5:1) | | Tenant10 CE1-----A0---A1------A6---A7-----CE3 Tenant10 with (A::1:1)(A6::6:1) (A::7:10) IPv4 20/8 Figure 2. SRv6 Path with SRv6 SIDs and Compressable SIDs Scenario 1-2: Cheng, et al. Expires August 14, 2020 [Page 6] Internet-Draft G-SRv6 February 2020 In C-SRv6, Common Prefix must be designed for the Compressable SRv6 SIDs. But in the scenario of crossing multiple SRv6 domains, it is very difficult to design the unified Common Prefix. It can be easy to design its own Common Prefix in a single domain. Thus an SRv6 path crossing multiple domains may be composed by different groups of Compressable SRv6 SIDs with different Common Prefixes, and they can not be encoded in a single C-SRH. For example, as illustrated in Figure 3, , a packet is forwarded along the path A1->A2->A3->A4->B1->B2->B3->B4, and the SRv6 SID list is [A::1:1, A::2:1, A::3:1, A:4:1, B::1:1, B::2:1, B::3:1, B:4:1]. The Common Prefix of the sub-path A1->A2->A3->A4 is A and the Common Prefix of the sub-path B1->B2->B3->B4 is B. But the end-to-end SRv6 path cannot be compressed in a single C-SRH. A2-----A3 B2-----B3 | | | | | | | | | | | | Tenant10 CE1---A0----A1-----A4----B1-----B4-----B0---CE3 Tenant10 with IPv4 20/8 Figure 3. SRv6 Path Crossing Multiple SRv6 Compression Domains For addressing above problems, a mechanism of encoding SRv6 SIDs and SRv6 C-SIDs in any order in an SRH should be provided, which does not require all the nodes along the path to support SRv6 compression. 3.2. Crossing SR-MPLS Domains In SRv6, END.BM SID can be used for indicating an SR-MPLS Policy. Therefore, when an SRv6 packet needs to travel an SR-MPLS path, the associated END.BM SID should be encoded in the SID list. When the packet arrives at the ingress node of the SR-MPLS path, an MPLS label stack will be encapsulated to the packet according to the END.BM, and the packet will be forwarded in the SR-MPLS domain based on the MPLS labels. End.BM hides the details of the SR-MPLS path, which brings benefits on security and privacy. But it brings more network states to the intermediate nodes of the SRv6 path. Also, when operators can manage both the SRv6 networks and SR-MPLS networks, it can program an end- to-end path under specific SLA assurance. If the existing SR-MPLS path associated with END.BM can not meet the SLA requirement, then a new END.BM SID should be configured and advertised among the networks. This procedure increases the complexities of deploying services. Cheng, et al. Expires August 14, 2020 [Page 7] Internet-Draft G-SRv6 February 2020 For example, as illustrated in Figure 4, when a packet is sent from CE1 to CE3, it may choose several paths in SR-MPLS domain, which provide different SLA assurance. Therefore, state of multiple SR- MPLS paths should be maintained at the node A1 and A2. - SR-MPLS Path 1: A1->A4->A5 - SR-MPLS Path 2: A1->A2->A3->A6 - SR-MPLS Path 3: A1->A2->A3->A6->A5 - SR-MPLS Path 4: A2->A3->A6 - SR-MPLS Path 5: A2->A1->A4->A5 - SR-MPLS Path 6: A2->A1->A4->A5->A6 There will be more states of path should be maintained when the scale of SR-MPLS domain is large. B2-------A2----A3-----A6-------B3 | SRv6 | SR-MPLS | SRv6 | | Domain | Domain | Domain | | | | | Tenant10 CE1---B1-------A1----A4-----A5-------B4---CE3 Tenant10 with IPv4 20/8 Figure 4. SRv6 Path Crossing SR-MPLS Domains In order to program SR-MPLS sub-path more flexible and reduce the states on the intermediate nodes, a mechanism for encoding SRv6 SID and MPLS labels should be provided. In this way, the ingress node of the path can program the end-to-end path including the SRv6 sub-path and the SR-MPLS sub-path, and no state of MPLS sub-path will be maintained. 3.3. Crossing IPv4 Domains In some scenarios such as SD-WAN an SRv6 packet may cross an IPv4 domain, and the SRv6 packets will be transported by the IPv6 over IPv4 tunnel. Similar to SR-MPLS, there can be two options for indicating the IPv4 tunnel. o Option A: the IPv4 tunnel binding SID in SRH o Option B: the IPv4 tunnel parameters in SRH Cheng, et al. Expires August 14, 2020 [Page 8] Internet-Draft G-SRv6 February 2020 For IPv4 tunnel binding SID, the ingress node of IPv4 tunnel should maintain the states of this tunnel. For example, as illustrated in Figure 5, when a packet is sent from CE1 to CE3, it may choose several paths in the IPv4 domain. Therefore, state of multiple IPv4 tunnels should be maintained at the node A1 and A2. - IPv4 Tunnel 1: Source Address A1, Destination Address A5 - IPv4 Tunnel 2: Source Address A1, Destination Address A6 - IPv4 Tunnel 3: Source Address A2, Destination Address A5 - IPv4 Tunnel 4: Source Address A2, Destination Address A6 There will be more states of IPv4 tunnels should be maintained when the scale of the IPv4 domain is large. B2-------A2----A3-----A6-------B3 | SRv6 | IPv4 | SRv6 | | Domain | Domain | Domain | | | | | Tenant10 CE1---B1-------A1----A4-----A5-------B4---CE3 Tenant10 with IPv4 20/8 Figure 5. SRv6 Path Crossing IPv4 Domains The second option can be adopted to carry the IPv4 tunnel information explicitly in the SRH. At the ingress of the IPv4 tunnel, an IPv4 tunnel header will be encapsulated to the packet according to the IPv4 tunnel information in the SRH. In order to support encoding IPv4 tunnel information in SRH, new mechanisms are required. 4. Concept of Generalized SRv6 According to the requirements described above, this document proposes Generalized SRv6, which supports to encode multiple types of Segment ID in a single SRH for an end-to-end Generalized SRv6 path that travels multiple types of networks, such as SRv6 domains, Compressed SRv6 domains, SR-MPLS domains and IPv4 domains. In order to support G-SRv6, this document proposes some enhancements of SRH. This enhanced SRH is called Generalized SRH (G-SRH). The Segments encoded in a G-SRH is called General Segments and its ID is called Generalized SID (G-SID). A G-SID is a 128 bits value, and it may contain: Cheng, et al. Expires August 14, 2020 [Page 9] Internet-Draft G-SRv6 February 2020 o an SRv6 SID o a compression G-SID o an MPLS G-SID o an IPv4 G-SID 4.1. SRv6 G-SID SRv6 SID is a type of G-SID. A G-SID contains a single SRv6 SID, and does not change anything of SRv6 SID. 4.2. Compression G-SID As per [I-D.li-spring-compressed-srv6-np], a C-SID is a sub-set of a compressable SRv6 SID, which can be used for routing the packets in compressed SRv6 network programming. A compression G-SID shown in Figure 6 may contains several C-SIDs and optional padding. When C-SID is a 32 bits value, a compression G-SID can consist of 4 C-SIDs. If the length of C-SIDs in a G-SID is less than 128 bits, then padding is required. Cheng, et al. Expires August 14, 2020 [Page 10] Internet-Draft G-SRv6 February 2020 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C-SID 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C-SID 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C-SID 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C-SID 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (a) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C-SID 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C-SID 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (b) Figure 6. Compression G-SID 4.3. MPLS G-SID An MPLS G-SID shown in Figure 7 may contains 4 MPLS Label Encapsulations, if number of MPLS Label Encapsulations is less than 4, then padding is required in G-SID for aligning with 128 bits. Cheng, et al. Expires August 14, 2020 [Page 11] Internet-Draft G-SRv6 February 2020 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label 0 | TC |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label 1 | TC |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label 2 | TC |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label 3 | TC |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (a) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label 0 | TC |1| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label 1 | TC |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (b) Figure 7. MPLS G-SID In order to indicate the MPLS G-SID, this document proposes a END.M (End function with SR-MPLS path instantiation), this will be described in section 6. An MPLS G-SID appears after the END.M SID, and it can not be the last G-SID in the G-SID list. 4.4. IPv4 G-SID An IPv4 G-SID shown in Figure 8 contains 128 bits IPv4 tunnel related information. The format of IPv4 G-SID is shown below. Cheng, et al. Expires August 14, 2020 [Page 12] Internet-Draft G-SRv6 February 2020 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 | Tunnel Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Src Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Dest Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8. IPv4 G-SID In order to indicate the IPv4 G-SID, this document proposes a END.4 (End function with IPv4 tunnel instantiation), this will be described in section 7. The detailed encoding of IPv4 tunnel G-SID is also described in section 7. An IPv4 G-SID appears after the End.4 SID, and it can not be the last G-SID in the G-SID list. 5. G-SRv6 for Crossing SRv6 Compression Domains This section describes the mechanism of G-SRv6 for crossing SRv6 Compression Domains. 5.1. Mechanisms The path for crossing SRv6 Compression Domain is called Compressed SRv6 sub-path. It should be encoded in any location of a G-SRH. There are following aspects should be considered in this mechanism: o Compression SID indication o C-SID length indication o Start of C-SIDs indication o End of C-SIDs indication 5.1.1. Compressable SID Indication A new flavor can be introduced to indicate that an SRv6 SID is compressable. There are two options for the definition of the flavor: Cheng, et al. Expires August 14, 2020 [Page 13] Internet-Draft G-SRv6 February 2020 o Option A: If the Compressable flavor is set for a specific SRv6 SID, it means that the SRv6 SID can be used as normal SRv6 SID and also can be used as Compressable SRv6 SID. o Option B: If the Compressable flavor is set for a specific SRv6 SID, it means that the SRv6 SID can only be used as Compressable SRv6 SID. In this option, if an SRv6 SID is already allocated and the compression requirement is proposed, a new SRv6 SID has to be allocated as the Compressable SRv6 SID for the same function. Though the Option B may use more SRv6 SIDs for the purpose of compression, it has much advantages in the incremental deployment. This document recommends the Option B. 5.1.2. C-SID Length Indication Compresable SRv6 SID can be represented as Common Prefix + C-SID+(Optional) Argument. There can be multiple options for the length of C-SID as follows: o Option A: a variable length in bytes o Option B: optional length such as 16/32/64 bits o Option C: only one option, 32 bits Though the length of C-SID can be configured locally or advertised by protocol extensions, the different length of C-SID will increase the complexity of process of control plane and data plane which is not necessary. This document recommends Option C which is a ideal tradeoff between the compression and the enough space for node ID and SRv6 Function. 5.1.3. Start of Compression Indication In G-SRv6, if the SID list of an SRv6 sub-path consists of a list of compressable SIDs, it can be programmed as follows: the first compressable SID indicates the start of C-SRv6 sub-path, followed by compressable G-SIDs, which includes C-SIDs and padding if the number of (32 bits) C-SIDs is less than 4 in a G-SID. The format of programmed SRv6 compression sub-path is shown in Figure 9. Cheng, et al. Expires August 14, 2020 [Page 14] Internet-Draft G-SRv6 February 2020 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . ... . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Compression G-SID 1 | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Compression G-SID 2 | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Compressable SRv6 SID | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9. G-SID list for SRv6 Compression Path 5.1.4. End of Compression Indication Since C-SIDs and SRv6 SIDs can be encoded in any order in an SRH, a mechanism for indicating the end of compression is needed. There are mainly two options for the indication of the end of compression as follows: o Option A: an EOC (End of Compression) flavor is introduced when advertise Compressable SRv6 SID. When the node determines the IPv6 destination address of SRv6 packet is the Compresable SRv6 SID with EOC flavor, meaning the associated C-SID is the last C-SID in the G-SID, and it will skip the G-SID in which the corresponding C-SID located and read the following 128-bit SRv6 SID. o Option B: an EOC C-SID is introduced in the G-SID to indicate the end of the compression. The length of EOC C-SID is a 32 bits value, and the it's value can be a well-known value such as 0 or a node allocated value. If the number of C-SIDs in a Compression G-SID is less than 4, the EOC can be used as the . If there are 4 C-SIDs in the last G-SID of Compressed SRv6 sub-path, it has to insert a G-SID composed by 4 EOCs. Cheng, et al. Expires August 14, 2020 [Page 15] Internet-Draft G-SRv6 February 2020 The different options for indication of end of compression are shown in Figure 10. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C-SID 0 (EOC Flavor) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C-SID 1 (Non-EOC Flavor) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C-SID 2 (Non-EOC Flavor) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C-SID 3 (Non-EOC Flavor) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (a) Option A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | G-SID (MBZ) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C-SID 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C-SID 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C-SID 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C-SID 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (b) Option B Figure 10. End of Compression Indication 5.2. Illustration According to the above mechanisms, the scenarios shown in the section 3.1 can be encoded as follows: Scenario 1-1: Assuming that o A::1:1, A::2:1, A::3:1, A::4:1, A::5:1 are the Compressable SIDs. o A::1:2, A::2:2, A::3:2, A::4:2, A::5:2 are the Compressable SIDs with EOC flavor. Cheng, et al. Expires August 14, 2020 [Page 16] Internet-Draft G-SRv6 February 2020 The programmed G-SRv6 path A1->A2->A3->A4->A5->A6->A7 is shown in Figure 11: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | A::7:10 | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | A6::6:1 | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 5:2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4:1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3:1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2:1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | A1::1:1 | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11. G-SRv6 Path for Scenario 1-1 Scenario 1-2: The programmed G-SRv6 path A1->A2->A3->A4->B1->B2->B3->B4 is shown in Figure 12: Cheng, et al. Expires August 14, 2020 [Page 17] Internet-Draft G-SRv6 February 2020 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4:2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3:1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2:1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | B::1:1 | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4:2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3:1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2:1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | A::1:1 | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12. G-SRv6 Path for Scenario 1-2 In reduced mode, the SID A::1:1 can be removed from the G-SRH. The mechanism of indicating the C-SIDs within the G-SID will be described in the document of G-SRH. 5.3. Effect on SRv6 G-SRv6 provides the flexibility of encoding SRv6 SID and SRv6 C-SID in a single SRH, which supports to program an SRv6 path that consists of compression capable and compression incapable nodes. In this case, G-SRv6 solves the problem of SRv6 overhead with a limited effect on SRv6. o Independent with SRv6: G-SRv6 does not require that the SRv6 SID Space has the common prefix for supporting compression. A new address block can be allocated for compressable SID, and the Cheng, et al. Expires August 14, 2020 [Page 18] Internet-Draft G-SRv6 February 2020 common prefix of Compressable SIDs can be configured with appropriate length. o Incremental upgrade: G-SRv6 does not require to upgrade all the nodes along the path to support SRv6 compression, they can be upgraded on demand to support compression. 5.4. Protocol Extensions Requirements This section describes the protocol extension requirements. 5.4.1. Data Plane REQ1-01: An SRv6 compression path can be represented as a G-SID list consists of a compressable SRv6 SID and Compression G-SIDs. REQ1-02: A Compression G-SID consists of at most 4 (32-bits) C-SIDs, if the number of C-SID is less than 4, then padding is required to align with 128 bits. REQ1-03: If the first Compressable SID is copied to the IPv6 DA, then the C-SIDs of the following G-SIDs should be read by the nodes along the SRv6 compression sub-path and the C-SID part in IPv6 DA should be replaced accordingly. REQ1-04: The last C-SID in the G-SIDs for the SRv6 compression sub- path should be the Compressable SRv6 SID with EOC flavor. REQ1-05: When process the Compressalbe SRv6 SID with EOC flavor in the IPv6 DA, the corresponding G-SID in the G-SRH should be skipped and the IPv6 DA should be updated by the following SRv6 SID if exists. 5.4.2. Control Plane REQ1-11: ISIS/OSPF/BGP-LS extensions for advertising the G-SRv6 for SRv6 compression capabilities REQ1-12: ISIS/OSPF/BGP-LS/BGP extensions for advertising the Compression flavor for Compressable SIDs. REQ1-13: ISIS/OSPF/BGP-LS extensions for advertising the End-of- compression(EOC) flavor for Compressable SIDs. REQ1-14: ISIS/OSPF/BGP-LS/BGP extensions for advertising the format of Compressable SIDs. Cheng, et al. Expires August 14, 2020 [Page 19] Internet-Draft G-SRv6 February 2020 REQ1-21: BGP SRv6 Policy extensions for advertising the G-SRv6 for SRv6 compression capabilities. REQ1-22: BGP SR Policy extensions for programming a G-SRv6 path combining with Compressable SRv6 SIDs and SRv6 SIDs. REQ1-31: PCEP SRv6 Policy extensions for advertising the G-SRv6 for SRv6 compression capabilities. REQ1-32: PCEP SR Policy extension for programming a G-SRv6 path combining with Compressable SRv6 SIDs and SRv6 SIDs. REQ1-33: PCEP extensions for programming a G-SRv6 path combining with Compressable SRv6 SIDs and SRv6 SIDs. 6. G-SRv6 for Crossing SR-MPLS Domain This section describes the mechanism for encoding SRv6 SIDs and MPLS G-SID in a single G-SRH. 6.1. Mechanisms The path for crossing SR-MPLS domain is called SR-MPLS sub-path. It can be encoded in any location of G-SRH. There are two aspects should be considered in this mechanism: o Start of MPLS G-SIDs indication o End of MPLS G-SIDs indication 6.1.1. Start of MPLS G-SID Indication In order to indicate the start of MPLS G-SIDs, new SRv6 SIDs types should be defined. This document defines an SID function to indicate the start of MPLS G-SIDs, called End.M ( End with MPLS labels). An SR-MPLS sub-path can be encoded in the G-SRH as follows: Cheng, et al. Expires August 14, 2020 [Page 20] Internet-Draft G-SRv6 February 2020 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . ... . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MPLS G-SID 1 | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MPLS G-SID 2 | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End.M SRv6 SID | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13. SR-MPLS Sub-path Encoding in G-SRH When a node processes an End.M SID, it copies the following MPLS label stack encapsulation information of SR-MPLS sub-path in the MPLS G-SIDs to the MPLS header, and set the IPv6 DA as the SRv6 SID following the last MPLS G-SID of the SR-MPLS sub-path, and then forward the packet according to the active MPLS label. 6.1.2. End of MPLS G-SID Indication The S-bit in the MPLS label indicates the end of the MPLS label within the current MPLS G-SIDs sub-list. When the ingress node of the SR-MPLS sub-path reads the MPLS label stack encapsulation information until the Label with S-bit set. If the S-bit is set for the label encapsulation, it will skip the G-SID in which the label locates and set the IPv6 DA of the SRv6 packet as the SRv6 SID following the G-SID if exists. 6.2. Illustration According to the above mechanisms, the scenarios shown in the section 3.2 can be encoded as follows: Assuming that Cheng, et al. Expires August 14, 2020 [Page 21] Internet-Draft G-SRv6 February 2020 o A::1:100 is the End.M SID allocated by the node A1 for crossing SR-MPLS domain. o Label 1001, 1002, 1003, 1004, 1005 and 1006 are allocated as the node segment for A1/A2/A3/A4/A5/A6. The programmed G-SRv6 path B1->A1->A2->A3->A6->A5->B4 is shown in Figure 14: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | B::4:1 | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1005 | TC |1| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1006 | TC |0| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1003 | TC |0| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1002 | TC |0| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | A::1:100 (End.M) | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | B::1:1 | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14. G-SRv6 Path for Sec 3.2 6.3. Effect on SRv6 G-SRv6 supports to program the SRv6 SID and SR-MPLS SID/MPLS label in a single G-SRH, which provides to encode the end-to-end G-SRv6 path across SRv6 domains and SR-MPLS/MPLS domains explicitly at the ingress node. However, it also brings complexities of network programming, so this document suggests to upgrade the SR-MPLS nodes to support SRv6. Cheng, et al. Expires August 14, 2020 [Page 22] Internet-Draft G-SRv6 February 2020 6.4. Protocol Extensions Requirements This section describes the protocol extension requirements of G-SRv6 for MPLS G-SID. 6.4.1. Data Plane REQ2-01: An MPLS path can be encoded in G-SRH as a series of G-SIDs including a 128-bit End.M SRv6 SID and a set of MPLS G-SIDs. REQ2-02: An MPLS G-SID can consist of up to 4 MPLS label/SR-MPLS SID, if the number of MPLS label/SR-MPLS SID is less than 4, padding is required to align with 128 bits. REQ2-03: An End.M SRv6 SID indicates the start of MPLS G-SID. REQ2-04: The SRv6 packet can be encapsulated with an outer MPLS header, and the MPLS header contains the MPLS labels carried by the MPLS G-SIDs. REQ2-05: When the label encapsulation with S-bit is set is read by the ingress node of the SR-MPLS sub-path, the corresponding G-SID should be skipped and the IPv6 DA should be updated by the following SRv6 SID if exists. 6.4.2. Control Plane REQ2-11: ISIS/OSPF/BGP-LS extensions for advertising the G-SRv6 for MPLS capabilities REQ2-12: ISIS/OSPF/BGP-LS extensions for advertising the End.M SRv6 SID. REQ2-21: BGP SR Policy extensions for advertising the G-SRv6 for MPLS capabilities REQ2-22: BGP SR Policy extensions for encoding G-SID list with SRv6 SID and MPLS G-SID for G-SRv6 path. REQ2-31: PCEP SR Policy extensions for advertising the G-SRv6 for MPLS capabilities REQ2-31: PCEP SR Policy extensions for encoding G-SID list with SRv6 SID and MPLS G-SID for G-SRv6 path. REQ2-33: PCEP extensions for encoding G-SID list with SRv6 SID and MPLS G-SID for G-SRv6 path. Cheng, et al. Expires August 14, 2020 [Page 23] Internet-Draft G-SRv6 February 2020 7. G-SRv6 for Crossing IPv4 Domain This section describes the mechanism of G-SRv6 for crossing IPv4 domain. 7.1. Mechanism The path for crossing IPv4 domain is called IPv4 tunnel sub-path. It should be encoded in any location of G-SRH. There are two aspects should be considered in this mechanism: o Start of IPv4 G-SID o IPv4 G-SID encoding 7.1.1. Start of IPv4 G-SID Indication In order to indicate the start of IPv4 G-SIDs, new SRv6 SIDs types should be defined. This document defines an SID function to indicate the start of IPv4 G-SIDs, called End.4( End with IPv4 tunnel). When a node processes the End.4 SID, it encapsulates an outer IPv4 tunnel header for the SRv6 packet based on the tunnel information carried by the following IPv4 G-SID, and set the IPv6 DA as the SRv6 SID following the IPv4 G-SID, and then forwards the packet according to the IPv4 DA. An IPv4 tunnel sub-path can be encoded in the G-SRH as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 G-SID | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRv6 End.4 SID | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 15. IPv4 Tunnel Sub-path Encoding in G-SRH Cheng, et al. Expires August 14, 2020 [Page 24] Internet-Draft G-SRv6 February 2020 Also, this document proposes the END.B4 (End bound to an IPv4 tunnel) SID. A End.B4 is bound to an IPv4 tunnel. When the node receives a packet with End.B4 SID, the packet should be steered into the binding IPv4 tunnel. 7.1.2. IPv4 G-SID encoding An IPv4 GID contains the IPv4 tunnel information including tunnel type, source IPv4 address, destination IPv4 address and tunnel parameters. Different types of IPv4 tunnels have specific parameters: o IPv4 UDP tunnel: the tunnel parameters includes source port and destination port. o IPv4 VXLAN tunnel: the tunnel parameters includes source port, destination port and VN ID. The detailed encapsulation formats for different types of IPv4 tunnel is out of scope of the document. 7.2. Illustration According to the above mechanisms, the scenarios shown in the section 3.3 can be encoded as follows: Assuming that o A::1:200 is the End.4 SID allocated by the node A1 for crossing IPv4 domain. The programmed G-SRv6 path B1->A1->A6->B4 is shown in Figure 16: Cheng, et al. Expires August 14, 2020 [Page 25] Internet-Draft G-SRv6 February 2020 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | B::4:1 | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Tunnel Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Src Address (A1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Dest Address (A6) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | A::1:200 (End.IP4) | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | B::1:1 | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9. G-SRv6 Path for Sec 3.3 7.3. Effect on SRv6 G-SRv6 provides the capabilities for encoding IPv4 tunnel information and SRv6 SID within a single G-SRH, which brings benefits on end-to- end network programming on scenarios of packets traveling SRv6 domains and IPv4 domains. However, it also brings new complexities, so this document suggests to upgrade the IPv4 nodes to support IPv6 or SRv6. 7.4. Protocol Extensions Requirements This section describes the protocol extension requirements of G-SRv6 for IPv4 G-SID. Cheng, et al. Expires August 14, 2020 [Page 26] Internet-Draft G-SRv6 February 2020 7.4.1. Data Plane REQ3-01: An IPv4 tunnel can be encoded in G-SRH as series of G-SIDs including a 128 bit End.4 SRv6 SID and a set of IPv4 G-SIDs. REQ3-02: An IPv4 G-SID can consist of multiple IPv4 tunnel information, such as IPv4 source address and destination address of the tunnel endpoint. REQ3-03: An End.4 SRv6 SID indicates the start of IPv4 G-SID. REQ3-04: An End.B4 SRv6 SID indicates the IPv4 tunnel. REQ3-05: The SRv6 packet can be encapsulated with an outer IPv4 tunnel header based on the parameters in the IPv4 G-SID. REQ3-06: After the tunnel information is read by the ingress node of the IPv4 tunnel sub-path, the corresponding G-SID should be skipped and the IPv6 DA should be updated by the following SRv6 SID if exists. 7.4.2. Control Plane REQ3-11: ISIS/OSPF/BGP-LS extensions for advertising the G-SRv6 for IPv4 capabilities REQ3-12: ISIS/OSPF/BGP-LS extensions for advertising the End.4 SRv6 SID. REQ3-13: ISIS/OSPF/BGP-LS extensions for advertising the End.B4 SRv6 SID. REQ3-21: BGP SR Policy extensions for advertising the G-SRv6 for IPv4 capabilities REQ3-22: BGP SR Policy extensions for encoding G-SID list with SRv6 SID and IPv4 G-SID for G-SRv6 path. REQ3-31: PCEP SR Policy extensions for advertising the G-SRv6 for IPv4 capabilities REQ3-31: PCEP SR Policy extensions for encoding G-SID list with SRv6 SID and IPv4 G-SID for G-SRv6 path. REQ3-33: PCEP extensions for encoding G-SID list with SRv6 SID and IPv4 G-SID for G-SRv6 path. Cheng, et al. Expires August 14, 2020 [Page 27] Internet-Draft G-SRv6 February 2020 8. IANA Considerations TBD 9. Security Considerations TBD 10. Contributors Zhibo Hu Huawei Technologies huzhibo@huawei.com Yang Xia Huawei Technologies yolanda.xia@huawei.com 11. Acknowledgements 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [I-D.ietf-6man-segment-routing-header] Filsfils, C., Dukes, D., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", draft-ietf-6man-segment-routing-header-26 (work in progress), October 2019. Cheng, et al. Expires August 14, 2020 [Page 28] Internet-Draft G-SRv6 February 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, . [I-D.li-spring-compressed-srv6-np] Li, Z., Li, C., Xie, C., Voyer, D., LEE, K., Tian, H., Zhao, F., Guichard, J., Cong, L., and S. Peng, "Compressed SRv6 Network Programming", draft-li-spring-compressed- srv6-np-01 (work in progress), January 2020. 12.2. Informative References [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-09 (work in progress), February 2020. [I-D.filsfils-spring-srv6-net-pgm-illustration] Filsfils, C., Camarillo, P., Li, Z., Matsushima, S., Decraene, B., Steinberg, D., Lebrun, D., Raszuk, R., and J. Leddy, "Illustrations for SRv6 Network Programming", draft-filsfils-spring-srv6-net-pgm-illustration-01 (work in progress), August 2019. [I-D.tian-spring-srv6-deployment-consideration] Tian, H., Zhao, F., Xie, C., Li, T., Ma, J., Peng, S., Li, Z., and Y. Xiao, "SRv6 Deployment Consideration", draft- tian-spring-srv6-deployment-consideration-00 (work in progress), November 2019. Authors' Addresses Weiqiang Cheng China Mobile Email: chengweiqiang@chinamobile.com Zhenbin Li Huawei Technologies Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China Email: lizhenbin@huawei.com Cheng, et al. Expires August 14, 2020 [Page 29] Internet-Draft G-SRv6 February 2020 Cheng Li Huawei Technologies Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China Email: chengli13@huawei.com Chongfeng Xie China Telecom China Telecom Information Science&Technology Innovation park, Beiqijia Town,Changping District Beijing China Email: xiechf.bri@chinatelecom.cn Cong Li China Telecom China Telecom Information Science&Technology Innovation park, Beiqijia Town,Changping District Beijing China Email: licong.bri@chinatelecom.cn Hui Tian CAICT Beijing China Email: tianhui@caict.ac.cn Feng Zhao CAICT Beijing China Email: zhaofeng@caict.ac.cn Cheng, et al. Expires August 14, 2020 [Page 30]