idnits 2.17.1 draft-cp-spring-srv6-sid-allocation-00.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 4) being 66 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 6 characters in excess of 72. ** There are 22 instances of lines with control characters in the document. 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 (August 17, 2020) is 1349 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 205, but no explicit reference was found in the text == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-17 == Outdated reference: A later version (-10) exists of draft-mirsky-6man-unified-id-sr-07 Summary: 2 errors (**), 0 flaws (~~), 6 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 Sh. Peng 4 Intended status: Standards Track ZTE Corporation 5 Expires: February 18, 2021 August 17, 2020 7 SRv6 SID Allocation Requirements 8 draft-cp-spring-srv6-sid-allocation-00 10 Abstract 12 This document describes a SRv6 SID allocation method. 14 Status of This Memo 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF). Note that other groups may also distribute 21 working documents as Internet-Drafts. The list of current Internet- 22 Drafts is at https://datatracker.ietf.org/drafts/current/. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 This Internet-Draft will expire on February 18, 2021. 31 Copyright Notice 33 Copyright (c) 2020 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents 38 (https://trustee.ietf.org/license-info) in effect on the date of 39 publication of this document. Please review these documents 40 carefully, as they describe your rights and restrictions with respect 41 to this document. Code Components extracted from this document must 42 include Simplified BSD License text as described in Section 4.e of 43 the Trust Legal Provisions and are provided without warranty as 44 described in the Simplified BSD License. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 49 2. Conventions used in this document . . . . . . . . . . . . . . 2 50 3. Allocating a SRv6 Compressed SID to a node . . . . . . . . . 2 51 4. The New SR Endpoint Behaviors . . . . . . . . . . . . . . . . 3 52 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 53 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 54 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 55 8. Normative References . . . . . . . . . . . . . . . . . . . . 5 56 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 58 1. Introduction 60 Segment Routing architecture [RFC8402]leverages the paradigm of 61 source routing. It can be realized in a network data plane by 62 prepending the packet with a list of instructions, a.k.a. Segment 63 Identifiers (SIDs). A segment can be encoded as a Multi-Protocol 64 Label Switching (MPLS) label, IPv4 address, or IPv6 address. Segment 65 Routing can be applied in MPLS data plane by encoding 20-bits SIDs in 66 MPLS label stack [RFC8660]. It also can be applied to IPv6 data 67 plane by encoding a list of 128-bits SIDs in IPv6 Segment Routing 68 Extension Header (SRH)[I-D.ietf-6man-segment-routing-header]. 70 As we know, several proposals are introduced to reduce the overhead 71 of SIDs. The main ideas of them are basically to use a Compressed 72 SID to replace the complete 128 bit SID in the SID list. The 73 consequence of this is that the SID allocation space provided to each 74 node will be very limited, which will limit the deployment of 75 services in the network. 77 This document describes an SRv6 SID allocation method to increase the 78 SID allocation space. 80 2. Conventions used in this document 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in RFC2119. 86 3. Allocating a SRv6 Compressed SID to a node 88 Assign a general global SRv6 SID to the corresponding consumer type, 89 which is called the container SID. In the SID List, the container 90 SID is followed by the local index or identification to indicate a 91 specific segment with complete meaning. The container SID itself is 92 128bits and can be compressed to a short SID (such as 32 bits or 16 93 bits). The local index or identifier in general can also be a short 94 SID. 96 For example, END.X SIDs[I-D.ietf-spring-srv6-network-programming] are 97 allocated to all outbound L3 links on SRv6 nodes, and all these END.X 98 SIDs occupy the global SRv6 SID resource. Now we define a new 99 allocation method: for the consumer type of L3 link, only one general 100 global container SID (called END.T.X SID) is allocated, and then 101 allocates a local index for each specific L3 link, and the 102 combination of END.T.X SID and local index can express the meaning of 103 the original END.X. 105 4. The New SR Endpoint Behaviors 107 This document defines a new set of behaviors. Following is a set of 108 behaviors that can be associated with a SID. 110 END.T.X SID Endpoint with Layer-3 cross-connect. 111 Only one universal container SID (END.T.X SID) 112 is allocated on each node,and each outbound L3 link 113 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) 116 is allocated on each node,and each L3 link connecting 117 the CE is represented by a local index. 118 END.T.DX4 SID Endpoint with decaps and IPv4 cross-connect. 119 Only one universal container SID (END.T.DX4 SID) 120 is allocated on each node, and each L3 link connecting 121 the CE is represented by a local index. 122 END.T.DT6 SID Endpoint with decapsulation and IPv6 table lookup. 123 Only one universal container SID (END.T.DT6 SID) 124 is allocated on each node,and each L3VPN instance 125 is represented by a local index. 126 END.T.DT4 SID Endpoint with decapsulation and IPv4 table lookup. 127 Only one universal container SID (END.T.DT4 SID) 128 is allocated on each node, and each L3VPN instance 129 is represented by a local index. 130 END.T.DT46 SID Endpoint with decapsulation and IP table lookup. 131 Only one universal container SID (END.T.DT46 SID) 132 is allocated on each node, and each L3VPN instance 133 is represented by a local index. 134 END.T.DX2 SID Endpoint with decapsulation and L2 cross-connect. 135 Only one universal container SID (END.T.DX2 SID) 136 is allocated on each node,and each L2 link connecting 137 the CE is represented by a local index. 138 END.T.DX2V SID Endpoint with decapsulation and VLAN L2 table lookup. 139 Only one universal container SID (END.T.DX2V SID) 140 is allocated on each node,and each L2VPN/EVPN instance 141 is represented by a local index. 142 END.T.DT2U SID Endpoint with decapsulation and unicast MAC L2table lookup. 143 Only one universal container SID (END.T.DT2U SID) 144 is allocated on each node, and each L2VPN/EVPN instance 145 is represented by a local index. 146 END.T.DT2M SID Endpoint with decapsulation and L2 table flooding 147 Only one universal container SID (END.T.DT2M SID) 148 is allocated on each node, and each L2VPN/EVPN instance 149 is represented by a local index. 150 END.T.B SID Endpoint bound to an SRv6 policy with encapsulation 151 Only one universal container SID (END.T.B SID) 152 is allocated on each node, and each SR policy is 153 represented by a local index. 155 Above the END.T.X, END.T.DX6, END.T.DX4, END.T.DT6, END.T.DT4, 156 END.T.DT46, END.T.DX2, END.T.DX2V, END.T.DT2U, END.T.DT2M, END.T.B 157 are all variants of the End T behavior. 159 The END.T behavior allows the use of the next classic SRv6 SID as the 160 key value to look up and forward in a specific IPv6 FIB table, and 161 these variants explicitly use the next short SID of a specific length 162 (such as 32 or 16 bits) as the key value to look-up table in the 163 specific consumer type table . These variants can also be combined 164 with different Flavors, such as PSP, USP and USD Flavors defined in 165 [I-D.ietf-spring-srv6-network-programming], and UET-0, UET-1, UET-2 166 and UET-3 Flavor defined in [I-D.mirsky-6man-unified-id-sr]. 168 For example,UET-0, UET-1, UET-2 and UET-3 Flavor indicates the 169 compression type of the next SID following the current active SID. if 170 the container SID is UET-0 flavor, it means that the index and next- 171 sid following it in the SRH are both 128 bits. If the container SID 172 is in a UET-2 flavor, it means that the index and next sid following 173 it in the SRH are both 32 bits. 175 5. IANA Considerations 177 TBD. 179 6. Security Considerations 181 7. Acknowledgements 183 TBD. 185 8. Normative References 187 [I-D.ietf-6man-segment-routing-header] 188 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 189 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 190 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 191 progress), October 2019. 193 [I-D.ietf-spring-srv6-network-programming] 194 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 195 Matsushima, S., and Z. Li, "SRv6 Network Programming", 196 draft-ietf-spring-srv6-network-programming-17 (work in 197 progress), August 2020. 199 [I-D.mirsky-6man-unified-id-sr] 200 Cheng, W., Mirsky, G., Peng, S., Aihua, L., and G. Mishra, 201 "Unified Identifier in IPv6 Segment Routing Networks", 202 draft-mirsky-6man-unified-id-sr-07 (work in progress), 203 July 2020. 205 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 206 Decraene, B., Litkowski, S., and R. Shakir, "Segment 207 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 208 July 2018, . 210 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 211 Decraene, B., Litkowski, S., and R. Shakir, "Segment 212 Routing with the MPLS Data Plane", RFC 8660, 213 DOI 10.17487/RFC8660, December 2019, 214 . 216 Authors' Addresses 218 Ran Chen 219 ZTE Corporation 221 Email: chen.ran@zte.com.cn 223 Shaofu Peng 224 ZTE Corporation 226 Email: peng.shaofu@zte.com.cn