idnits 2.17.1 draft-cp-spring-srv6-sid-allocation-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 19 instances of too long lines in the document, the longest one being 21 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 22, 2021) is 1152 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC8402' is defined on line 195, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-mirsky-6man-unified-id-sr-08 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING WG R. Chen 3 Internet-Draft ZTE Corporation 4 Intended status: Standards Track Sh. Peng 5 Expires: August 26, 2021 ZTE Corp. 6 February 22, 2021 8 SRv6 SID Allocation 9 draft-cp-spring-srv6-sid-allocation-01 11 Abstract 13 This document describes a SRv6 SID allocation method. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on August 26, 2021. 32 Copyright Notice 34 Copyright (c) 2021 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Conventions used in this document . . . . . . . . . . . . . . 2 51 3. Allocating a SRv6 Compressed SID to a node . . . . . . . . . 2 52 4. The New SR Endpoint Behaviors . . . . . . . . . . . . . . . . 3 53 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 54 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 55 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 56 8. Normative References . . . . . . . . . . . . . . . . . . . . 5 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 59 1. Introduction 61 Segment Routing architecture [RFC8402]leverages the paradigm of 62 source routing. It can be realized in a network data plane by 63 prepending the packet with a list of instructions, a.k.a. Segment 64 Identifiers (SIDs). A segment can be encoded as a Multi-Protocol 65 Label Switching (MPLS) label, IPv4 address, or IPv6 address. Segment 66 Routing can be applied in MPLS data plane by encoding 20-bits SIDs in 67 MPLS label stack [RFC8660]. It also can be applied to IPv6 data 68 plane by encoding a list of 128-bits SIDs in IPv6 Segment Routing 69 Extension Header (SRH)[I-D.ietf-6man-segment-routing-header]. 71 As we know, several proposals are introduced to reduce the overhead 72 of SIDs. The main ideas of them are basically to use a Compressed 73 SID to replace the complete 128 bit SID in the SID list. The 74 consequence of this is that the SID allocation space provided to each 75 node will be very limited, which will limit the deployment of 76 services in the network. 78 This document describes an SRv6 SID allocation method to increase the 79 SID allocation space. 81 2. Conventions used in this document 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in RFC2119. 87 3. Allocating a SRv6 Compressed SID to a node 89 Assign a general global SRv6 SID to the corresponding consumer type, 90 which is called the container SID. In the SID List, the container 91 SID is followed by the local index or identification to indicate a 92 specific segment with complete meaning. The container SID itself is 93 128bits and can be compressed to a short SID (such as 32 bits or 16 94 bits). The local index or identifier in general can also be a short 95 SID. 97 For example, END.X SIDs[I-D.ietf-spring-srv6-network-programming] are 98 allocated to all outbound L3 links on SRv6 nodes, and all these END.X 99 SIDs occupy the global SRv6 SID resource. Now we define a new 100 allocation method: for the consumer type of L3 link, only one general 101 global container SID (called END.T.X SID) is allocated, and then 102 allocates a local index for each specific L3 link, and the 103 combination of END.T.X SID and local index can express the meaning of 104 the original END.X. 106 4. The New SR Endpoint Behaviors 108 This document defines a new set of behaviors. Following is a set of 109 behaviors that can be associated with a SID. 111 END.T.X SID Endpoint with Layer-3 cross-connect. 112 Only one universal container SID (END.T.X SID) is allocated on each node, 113 and each outbound L3 link is represented by a local index. 114 END.T.DX6 SID Endpoint with decapsulation and IPv6 cross-connect. 115 Only one universal container SID (END.T.DX6 SID) is allocated on each node, 116 and each L3 link connecting the CE is represented by a local index. 117 END.T.DX4 SID Endpoint with decaps and IPv4 cross-connect. 118 Only one universal container SID (END.T.DX4 SID) is allocated on each node, 119 and each L3 link connecting the CE is represented by a local index. 120 END.T.DT6 SID Endpoint with decapsulation and IPv6 table lookup. 121 Only one universal container SID (END.T.DT6 SID) is allocated on each node, 122 and each L3VPN instance is represented by a local index. 123 END.T.DT4 SID Endpoint with decapsulation and IPv4 table lookup. 124 Only one universal container SID (END.T.DT4 SID) is allocated on each node, 125 and each L3VPN instance is represented by a local index. 126 END.T.DT46 SID Endpoint with decapsulation and IP table lookup. 127 Only one universal container SID (END.T.DT46 SID) is allocated on each node, 128 and each L3VPN instance is represented by a local index. 129 END.T.DX2 SID Endpoint with decapsulation and L2 cross-connect. 130 Only one universal container SID (END.T.DX2 SID) is allocated on each node, 131 and each L2 link connecting the CE is represented by a local index. 132 END.T.DX2V SID Endpoint with decapsulation and VLAN L2 table lookup. 133 Only one universal container SID (END.T.DX2V SID) is allocated on each node, 134 and each L2VPN/EVPN instance is represented by a local index. 135 END.T.DT2U SID Endpoint with decapsulation and unicast MAC L2table lookup. 136 Only one universal container SID (END.T.DT2U SID) is allocated on each node, 137 and each L2VPN/EVPN instance is represented by a local index. 138 END.T.DT2M SID Endpoint with decapsulation and L2 table flooding 139 Only one universal container SID (END.T.DT2M SID) is allocated on each node, 140 and each L2VPN/EVPN instance is represented by a local index. 141 END.T.B SID Endpoint bound to an SRv6 policy with encapsulation 142 Only one universal container SID (END.T.B SID) is allocated on each node, 143 and each SR policy is represented by a local index. 145 Above the END.T.X, END.T.DX6, END.T.DX4, END.T.DT6, END.T.DT4, 146 END.T.DT46, END.T.DX2, END.T.DX2V, END.T.DT2U, END.T.DT2M, END.T.B 147 are all variants of the End T behavior. 149 The END.T behavior allows the use of the next classic SRv6 SID as the 150 key value to look up and forward in a specific IPv6 FIB table, and 151 these variants explicitly use the next short SID of a specific length 152 (such as 32 or 16 bits) as the key value to look-up table in the 153 specific consumer type table . These variants can also be combined 154 with different Flavors, such as PSP, USP and USD Flavors defined in 155 [I-D.ietf-spring-srv6-network-programming], and UET-0, UET-1, UET-2 156 and UET-3 Flavor defined in [I-D.mirsky-6man-unified-id-sr]. 158 For example,UET-0, UET-1, UET-2 and UET-3 Flavor indicates the 159 compression type of the next SID following the current active SID. if 160 the container SID is UET-0 flavor, it means that the index and next- 161 sid following it in the SRH are both 128 bits. If the container SID 162 is in a UET-2 flavor, it means that the index and next sid following 163 it in the SRH are both 32 bits. 165 5. IANA Considerations 167 TBD. 169 6. Security Considerations 171 7. Acknowledgements 173 TBD. 175 8. Normative References 177 [I-D.ietf-6man-segment-routing-header] 178 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 179 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 180 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 181 progress), October 2019. 183 [I-D.ietf-spring-srv6-network-programming] 184 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 185 Matsushima, S., and Z. Li, "SRv6 Network Programming", 186 draft-ietf-spring-srv6-network-programming-28 (work in 187 progress), December 2020. 189 [I-D.mirsky-6man-unified-id-sr] 190 Cheng, W., Mirsky, G., Peng, S., Aihua, L., and G. Mishra, 191 "Unified Identifier in IPv6 Segment Routing Networks", 192 draft-mirsky-6man-unified-id-sr-08 (work in progress), 193 January 2021. 195 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 196 Decraene, B., Litkowski, S., and R. Shakir, "Segment 197 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 198 July 2018, . 200 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 201 Decraene, B., Litkowski, S., and R. Shakir, "Segment 202 Routing with the MPLS Data Plane", RFC 8660, 203 DOI 10.17487/RFC8660, December 2019, 204 . 206 Authors' Addresses 208 Ran Chen 209 ZTE Corporation 211 Email: chen.ran@zte.com.cn 213 Shaofu Peng 214 ZTE Corp. 216 Email: peng.shaofu@zte.com.cn