idnits 2.17.1 draft-mirsky-spring-unified-id-network-programming-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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 6, 2020) is 1484 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-12 == Outdated reference: A later version (-10) exists of draft-mirsky-6man-unified-id-sr-05 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING C. Weiqiang 3 Internet-Draft China Mobile 4 Intended status: Informational G. Mirsky 5 Expires: September 7, 2020 ZTE Corp. 6 L. Aihua 7 P. Shaofu 8 ZTE Corporation 9 March 6, 2020 11 SRv6 network programming using Unified Identifier 12 draft-mirsky-spring-unified-id-network-programming-00 14 Abstract 16 This draft describes how Unified Segment Identifier can be used to 17 achieve the goals of SRv6 network programming. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 7, 2020. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Conventions used in this document . . . . . . . . . . . . 2 55 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3 56 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3 57 2. SRv6 Network Programming using U-SID . . . . . . . . . . . . 3 58 2.1. SRv6 Network Programming . . . . . . . . . . . . . . . . 3 59 2.2. SRv6 Network Programming Using 32bit U-SID . . . . . . . 4 60 2.3. U-SID with MPLS Programming Process . . . . . . . . . . . 5 61 2.3.1. U-SID with MPLS Support Programming using Flavors . . 5 62 2.4. U-SID with SRv6 Programming process . . . . . . . . . . . 6 63 2.5. U-SID Complementary Method . . . . . . . . . . . . . . . 6 64 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 67 6. Normative References . . . . . . . . . . . . . . . . . . . . 7 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Introduction 72 Segment Routing architecture [RFC8402] leverages the paradigm of 73 source routing. It can be realized in a network data plane by 74 prepending the packet with a list of instructions, a.k.a. Segment 75 Identifiers (SIDs). A segment can be encoded as a Multi-Protocol 76 Label Switching (MPLS) label, IPv4 address, or IPv6 address. Segment 77 Routing can be applied in MPLS data plane by encoding 20-bits SIDs in 78 MPLS label stack [RFC8660]. It also can be applied to IPv6 data 79 plane by encoding a list of 128-bits SIDs in IPv6 Segment Routing 80 Extension Header (SRH) [I-D.ietf-6man-segment-routing-header]. 82 Unified SID [I-D.mirsky-6man-unified-id-sr] defines an extension of 83 SRH that enables the use of a shorter segment identifier, such as 84 32-bits Label format SID or 32-bits IP address format SID. 86 SRv6 network programming is defined 87 [I-D.ietf-spring-srv6-network-programming]. SRv6 network programming 88 can be supported using Unified SID. 90 1.1. Conventions used in this document 91 1.1.1. Terminology 93 SR: Segment Routing 95 SRH: Segment Routing Extension Header 97 MPLS: Multiprotocol Label Switching 99 SR-MPLS: Segment Routing using MPLS data plane 101 SID: Segment Identifier 103 IGP: Interior Gateway Protocol 105 DA: Destination Address 107 SRv6: Segment Routing in IPv6 109 U-SID: Unified Segment Identifier 111 1.1.2. Requirements Language 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 115 "OPTIONAL" in this document are to be interpreted as described in BCP 116 14 [RFC2119] [RFC8174] when, and only when, they appear in all 117 capitals, as shown here. 119 2. SRv6 Network Programming using U-SID 121 2.1. SRv6 Network Programming 123 [I-D.ietf-spring-srv6-network-programming] defines an SRv6 SID as 124 consisting of LOC:FUNCT:ARG, where a locator (LOC) is encoded in the 125 L most significant bits of the SID, followed by F bits of function 126 (FUNCT) and A bits of arguments (ARG). L, the length of the locator, 127 is flexible, and an operator is free to use the locator length of 128 their choice. F and A may be any value as long as L + F + A <= 128. 129 When L + F + A is less than 128, then the remainder of the SID MUST 130 be zero. 132 A locator may be represented as B:N where B is the SRv6 SID block 133 (IPv6 subnet allocated for SRv6 SIDs by the operator) and N is the 134 identifier of the parent node instantiating the SID. The FUNCT is an 135 opaque identification of a local behavior bound to the SID. An SRv6 136 endpoint behavior MAY require additional information for its 137 processing (e.g., related to the flow or service). This information 138 MAY be encoded in the ARG bits of the SID. 140 2.2. SRv6 Network Programming Using 32bit U-SID 142 [I-D.mirsky-6man-unified-id-sr] defines a 32 bits SID as an MPLS 143 label or an IPv4 address or a complementary SID to a common IPv4/IPv6 144 prefix. If the U-SID represents an MPLS label, it could be mapped to 145 the 128-bits SRv6 SID. And if this U-SID represents a complementary 146 U-SID to a common IPv6 prefix, it could be associated with an SRv6 147 SID (a method to establish such association could use mapping, 148 stitching, shifting, or translation). This SID can be compliant to 149 the programming SID format as LOC:FUNCT:ARG, this means complementing 150 the SRv6 SID of programming format to 32-bits U-SID. A U-SID with 151 MPLS label format can support network programming, as illustrated in 152 Figure 1: 154 0 1 2 3 155 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 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | U-LOC (20bit, Label) |P|U|D|R|U-FUNCT (U-ARG)| 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Context (12bit) | 160 +-----------------------+ 162 Figure 1: Example of U-SID supporting Network Programming with SR- 163 MPLS 165 The context field can be defined as follow: 167 P-Flag: PSP (Penultimate Segment Pop of the SRH) Flag. If set, 168 then the penultimate segment node MUST remove the SRH from the 169 IPv6 extension header chain. 171 U-Flag: USP (Ultimate Segment Pop of the SRH) Flag. If set, then 172 the ultimate segment node MUST remove the SRH from the IPv6 173 extension header chain and proceed to process the next header in 174 the packet. 176 D-Flag: USD (Ultimate Segment Decapsulation) Flag. If set, then 177 the ultimate segment node MUST skip the SRH processing and proceed 178 to the next header. 180 R-Flag: Reserved Flag. 182 Function: 8-bits to store the short KEY for the specific table 183 lookup. The MPLS label in the leftmost 20-bits will identify the 184 context-specific table. For the context table that has a longer 185 KEY than 8-bits, the next 32-bits SID could be used for this 186 purpose. 188 A format of U-SID as 32-bits IP address can support network 189 programming, as illustrated in Figure 2. 191 0 1 2 3 192 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 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | U-LOC | U-FUNCT (U-ARG) | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 Figure 2: Example of U-SID supporting Network Programming with SRv6 199 In this case, U-SID is split to 16-bits locator (U-LOC) and 16-bits 200 function (U-FUNCT, U-ARG is optional). The operator can use any 201 method to compress the 128-bits SRv6 SID to 32-bits complementary 202 U-SID, such as mapping, stitching, shifting or translation, etc. For 203 example, an operator can simply compress the original locator to a 204 shorter locator. If the original SRv6 locator consists of B:N, this 205 case the N is 16-bits. So, only the N is the U-LOC of U-SID and the 206 B can be advertised by IGP protocol in the domain. the length of 207 U-LOC and U-FUNCT (U-ARG) is flexible, and an operator is free to use 208 the length of their choice. The length of U-LOC and U-FUNCT (U-ARG) 209 may be any value as long as its sum mo more than 32. The compressing 210 and the advertising method are out of the scope of this draft. 212 2.3. U-SID with MPLS Programming Process 214 2.3.1. U-SID with MPLS Support Programming using Flavors 216 [I-D.ietf-spring-srv6-network-programming] introduced the PSP, USP, 217 and USD flavors for SRv6 SID. The U-FUNCT (U-ARG) and Flavors are 218 combined to allocate different SRv6 SIDs, or someone can understand 219 that each U-FUNCT (U-ARG) codepoint itself has a determined flavor. 220 That is no problem for SRv6 SID allocation because IPv6 address 221 resource is enough. For SR-MPLS over SRH in this document, a 222 different MPLS label is used for each topology type of SID, such as 223 node SID, adjacency SID, or service type of SID, etc. All these 224 types of SIDs are equivalent to SIDs defined in SRv6. The label 225 allocation is independent of flavors. For the use of the behavior 226 flavor, an explicit standard Flavor codepoint could be set on the 227 rightmost 12-bits of the SID entry (label) in SRH. 229 The codepoint can be used as U-FUNCT (U-ARG) to support the network 230 programming. In this case, a 20-bits MPLS label of U-SID is 231 interpreted as the U-LOC. The U-FUNCT in the codepoint field of 232 U-SID can be advertised by the control plane. 234 Note that the flavor codepoint is different from the PHP flag of 235 prefix-SID in SR-MPLS. 237 2.4. U-SID with SRv6 Programming process 239 Processing of SRH with elements carrying 32 bits-long SIDs closely 240 follows SRH processing as defined in Section 4.3.1.1 241 [I-D.ietf-6man-segment-routing-header] and the "End" behavior is 242 demonstrated in the pseudo-code below, but it equally applies to all 243 SID behaviors. When N with U-SID receives a packet whose IPv6 DA is 244 S and S is a local End SID. The lines S08 and S14 of the End 245 processing which was, as per Section 4.1 of 246 [I-D.ietf-spring-srv6-network-programming]: 248 S08. max_LE = ( Hdr Ext Len * 8/ sizeof(SRH_element) ) - 1 249 [...] 250 S14. Get 128-bits IPv6 DA by 32-bits U-SID 251 from Segment List[Segments Left] 252 Update IPv6 DA 254 Note: S14. Obtaining 128-bits IPv6 DA from complementary U-SID 255 can be done by mapping, stitching, shifting, translation, etc. 257 2.5. U-SID Complementary Method 259 The 32-bits U-SID MAY be used as complementary to a common IPv6 260 prefix to construct an IPv6 address SID (SRv6 SID). Many methods can 261 be used to achieve that, including mapping, stitching, shifting, 262 translation, etc. 264 Generally speaking, the relationship between 32-bits U-SID and 265 128-bits SRv6 SID can be established using any transformation 266 function as long as the relationship unambiguous and reversible, 267 i.e., there exists a transformation function that when being applied 268 to the result produces the original value. We can use a function F 269 as a method that produces 32-bits U-SID from 128-bits SRv6 SID. Then 270 there must be a function F', used as the reversible method, to 271 produce the original 128-bits SRv6 SID from the 32-bits U-SID. These 272 functions are illustrated below: 274 U-SID = F (SRv6 SID); 275 SRv6 SID = F' (U-SID); 277 The details of these functions will be demonstrated in the future. 279 3. IANA Considerations 281 This draft has no requests for IANA actions. This section can be 282 removed before the publication. 284 4. Security Considerations 286 TBD 288 5. Acknowledgements 290 TBD 292 6. Normative References 294 [I-D.ietf-6man-segment-routing-header] 295 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 296 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 297 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 298 progress), October 2019. 300 [I-D.ietf-spring-srv6-network-programming] 301 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 302 Matsushima, S., and Z. Li, "SRv6 Network Programming", 303 draft-ietf-spring-srv6-network-programming-12 (work in 304 progress), March 2020. 306 [I-D.mirsky-6man-unified-id-sr] 307 Cheng, W., Mirsky, G., Peng, S., Aihua, L., Wan, X., Wei, 308 C., and S. Shay, "Unified Identifier in IPv6 Segment 309 Routing Networks", draft-mirsky-6man-unified-id-sr-05 310 (work in progress), February 2020. 312 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 313 Requirement Levels", BCP 14, RFC 2119, 314 DOI 10.17487/RFC2119, March 1997, 315 . 317 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 318 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 319 May 2017, . 321 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 322 Decraene, B., Litkowski, S., and R. Shakir, "Segment 323 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 324 July 2018, . 326 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 327 Decraene, B., Litkowski, S., and R. Shakir, "Segment 328 Routing with the MPLS Data Plane", RFC 8660, 329 DOI 10.17487/RFC8660, December 2019, 330 . 332 Authors' Addresses 334 Cheng Weiqiang 335 China Mobile 336 Beijing 337 China 339 Email: chengweiqiang@chinamobile.com 341 Greg Mirsky 342 ZTE Corp. 344 Email: gregimirsky@gmail.com 346 Liu Aihua 347 ZTE Corporation 348 Zhongxing Industrial Park, Nanshan District 349 Shenzhen 350 China 352 Email: liu.aihua@zte.com.cn 354 Peng Shaofu 355 ZTE Corporation 356 No.50 Software Avenue, Yuhuatai District 357 Nanjing 358 China 360 Email: peng.shaofu@zte.com.cn