idnits 2.17.1 draft-li-spring-srv6-end-mpls-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 (April 20, 2021) is 1074 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) == Outdated reference: A later version (-06) exists of draft-li-spring-srh-tlv-processing-programming-00 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group Z. Li 3 Internet-Draft C. Li 4 Intended status: Standards Track Huawei Technologies 5 Expires: October 22, 2021 April 20, 2021 7 SRv6 End.M behavior for traversing MPLS Networks 8 draft-li-spring-srv6-end-mpls-00 10 Abstract 12 As the development of cloud computing, increasing services have been 13 migrated from enterprise sites to clouds, so the connection between 14 sites and clouds are critical for enterprises. 16 SRv6 provides a sourcing routing mechanism to connect the enterprise 17 sites and clouds by programming the end-to-end path at the ingress 18 node. In this scenario, the SRv6 packets may traverse multiple 19 network domains and some of them may not be SRv6-capable. 21 In order to support SRv6 end-to-end path programming, this document 22 defines the mechanism of SRv6 traversing MPLS networks, which 23 supports encoding MPLS tunnel information in the SRH. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on October 22, 2021. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 62 3. MPLS Path Programming in SRv6 . . . . . . . . . . . . . . . . 3 63 3.1. END.M . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3.2. MPLS Tunnel Information in SRH TLV . . . . . . . . . . . 6 65 4. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 6 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 71 8.2. Informative References . . . . . . . . . . . . . . . . . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 When Segment routing (SR) [RFC8402] is deployed on the IPv6 data 77 plane, it is called SRv6 [RFC8754]. For support of SRv6, a new 78 routing header called Segment Routing Header (SRH), which contains a 79 list of SIDs and other information, has been defined in [RFC8754]. 81 When deploying SRv6, the SRv6 network may need to interwork with 82 exiting networks, such as MPLS netwoks and IPv4 networks. 84 With the development of cloud computing, increasing services have 85 been migrated from enterprises to cloud data centers. Compared with 86 interconnections between branches and headquarters, new connections 87 between enterprise sites to cloud data centers and inter-cloud are 88 added, which bring new requirements and challenges for existing 89 networks. [I-D.li-rtgwg-ipv6-based-con] describes the requirements 90 and candidate technologies in IPv6-based Cloud-oriented Networking 91 (CON). In IPv6-based CON, SRv6 can be used to connect enterprise 92 sites and clouds. In this scenario, an SRv6 packet may be forwarded 93 traversing MPLS domains or IPv4 domains. 95 In order to specify the MPLS tunnel, End.BM [RFC8986] has been 96 defined for binding an SR-MPLS policy to an SRv6 SID currently. The 97 MPLS tunnel information is maintained at the ingress node of the MPLS 98 tunnel, which will introduce states to the node, and it also require 99 extra configuration at the node allocating End.BM SIDs. 101 This document defines a new mechanism to carry MPLS tunnel 102 information in the SRv6 packet, so that no configuration of SR-MPLS 103 policy is required at the intermediate node, and end-to-end path 104 programming traversing MPLS domains can be supported. 106 2. Terminology 108 This document makes use of the terms defined in [RFC8986], and the 109 reader is assumed to be familiar with that terminology. 111 2.1. 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 3. MPLS Path Programming in SRv6 121 This document defines the following mechanisms for SRv6 traversing 122 MPLS networks. 124 3.1. END.M 126 In order to indicate the start of SR-MPLS tunnel information, a new 127 SRv6 behavior End.M (End with SR-MPLS path instantiation) is defined. 129 An End.M SID MUST be encoded preceding the MPLS tunnel information, 130 therefore it can not be the last SID in the SID list. 132 The path of traversing SR-MPLS domain is called SR-MPLS sub-path. An 133 SR-MPLS sub-path can be encoded by an End.M and the following MPLS 134 label stack as shown in the following figure. 136 0 1 2 3 137 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 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 . ... . 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | | 143 | ... | 144 | MPLS Tunnel Information | 145 | | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | End.M SRv6 SID | 148 | | 149 | | 150 | | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 Figure 1. SR-MPLS Sub-path Encoding in G-SRH 154 The MPLS tunnel information include multiple MPLS labels, and they 155 are aligned with 128 bits. Therefore padding is needed if there are 156 less than 4 MPLS labels in a 128-bit space. 158 0 1 2 3 159 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 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Label 0 | TC |S| TTL | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Label 1 | TC |S| TTL | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Label 2 | TC |S| TTL | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Label 3 | TC |S| TTL | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 (a) 171 0 1 2 3 172 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 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Padding | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Padding | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Label 0 | TC |1| TTL | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Label 1 | TC |S| TTL | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 (b) 184 Figure 2. MPLS tunnel information Encoding 186 The S-bit of the last MPLS label in the SID list MUST be set 187 indicating the end of the MPLS label stack. 189 When a node processes an End.M SID, it copies the following MPLS 190 label stack of SR-MPLS sub-path to the MPLS header, and set the IPv6 191 DA as the SRv6 SID after the MPLS label stack, and then forward the 192 packet according to the active MPLS label. 194 When node N receives a packet whose IPv6 DA is S and S is a local 195 End.B4 SID, the line S13-S16 from the End processing [RFC8986] is 196 replaced by the following: 198 S13. Set SL pointing to the next SID after MPLS label stack. 199 S14. Update IPv6 DA with Segment List[Segments Left] 200 S15. Push a MPLS label stack before the IPv6 header 201 by using the MPLS label stack. 202 S16. Lookup the active MPLS label and forward the packet 203 S17. } 205 3.2. MPLS Tunnel Information in SRH TLV 207 Using SRH TLV is another option of carrying MPLS tunnel information. 209 In order to retrive the MPLS tunnel information from SRH TLV, a new 210 behavior End.MT (End with SR-MPLS path instantiation by using SRH 211 TLV) should be defined, and this will be described in the future. 213 A mechanism of specifying which SRH TLV to be processed by which SID 214 in the SID list is defined in 215 [I-D.li-spring-srh-tlv-processing-programming], and it can be used 216 for indicating the node to process MPLS tunnel information in SRH 217 TLV. 219 [Editor's note] Also, there may be some other solutions to indicate 220 and carry MPLS tunnel information in the SRv6 packet, for example 221 using the argument of a SID to indicate the MPLS label stack or 222 number of MPLS labels. 224 More details will be described in the future. 226 4. Illustration 228 For easy understanding, this section illustrates how to use End.M SID 229 to specify the MPLS tunnel. 231 Assuming that 233 o A::1:100 is the End.M SID allocated by the ingress node of an SR- 234 MPLS domain. 236 o 1001, 1002, 1003, and 1004 are the labels for an SR-MPLS sub-path. 238 Therefore, the programmed SRv6 path for traversing SR-MPLS/MPLS 239 domain is shown in Figure 2. 241 0 1 2 3 242 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 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | ... | 245 | | 246 | | 247 | | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | 1004 | TC |1| TTL | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | 1003 | TC |0| TTL | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | 1002 | TC |0| TTL | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | 1001 | TC |0| TTL | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | A::1:100 (End.M) | 258 | | 259 | | 260 | | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | ... | 263 | | 264 | | 265 | | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 Figure 3. Carrying MPLS tunnel information in SID list 269 5. IANA Considerations 271 TBD 273 6. Security Considerations 275 TBD 277 7. Acknowledgements 279 8. References 281 8.1. Normative References 283 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 284 Requirement Levels", BCP 14, RFC 2119, 285 DOI 10.17487/RFC2119, March 1997, 286 . 288 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 289 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 290 May 2017, . 292 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 293 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 294 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 295 . 297 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 298 Decraene, B., Litkowski, S., and R. Shakir, "Segment 299 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 300 July 2018, . 302 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 303 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 304 (SRv6) Network Programming", RFC 8986, 305 DOI 10.17487/RFC8986, February 2021, 306 . 308 8.2. Informative References 310 [I-D.li-spring-srh-tlv-processing-programming] 311 Li, C., Xia, Y., Dhody, D., and Z. Li, "SRH TLV Processing 312 Programming", draft-li-spring-srh-tlv-processing- 313 programming-00 (work in progress), December 2020. 315 [I-D.li-rtgwg-ipv6-based-con] 316 (editor), C. L., Li, Z., and H. Yang, "IPv6-based Cloud- 317 Oriented Networking (CON)", draft-li-rtgwg-ipv6-based- 318 con-01 (work in progress), March 2021. 320 Authors' Addresses 322 Zhenbin Li 323 Huawei Technologies 324 Huawei Campus, No. 156 Beiqing Rd. 325 Beijing 100095 326 China 328 Email: lizhenbin@huawei.com 329 Cheng Li 330 Huawei Technologies 331 Huawei Campus, No. 156 Beiqing Rd. 332 Beijing 100095 333 China 335 Email: c.l@huawei.com