idnits 2.17.1 draft-filsfils-spring-srv6-net-pgm-insertion-06.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The abstract seems to contain references ([RFC8986]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (22 February 2022) is 793 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) ** Downref: Normative reference to an Informational draft: draft-voyer-6man-extension-header-insertion (ref. 'I-D.voyer-6man-extension-header-insertion') == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-segment-routing-ti-lfa-08 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-18 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING C. Filsfils, Ed. 3 Internet-Draft P. Camarillo, Ed. 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: 26 August 2022 J. Leddy 6 Individual Contributor 7 D. Voyer 8 Bell Canada 9 S. Matsushima 10 SoftBank 11 Z. Li 12 Huawei Technologies 13 22 February 2022 15 SRv6 NET-PGM extension: Insertion 16 draft-filsfils-spring-srv6-net-pgm-insertion-06 18 Abstract 20 Traffic traversing an SR domain is encapsulated in an outer IPv6 21 header for its journey through the SR domain. 23 To implement transport services strictly within the SR domain, the SR 24 domain may require insertion or deletion of an SRH after the outer 25 IPv6 header of the SR domain. Any segment within the SRH is strictly 26 contained within the SR domain. 28 This document extends SRv6 Network Programming [RFC8986] with new SR 29 endpoint and transit behaviors to be performed only within the SR 30 domain in any packet owned by the domain. 32 Requirements Language 34 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 36 "OPTIONAL" in this document are to be interpreted as described in BCP 37 14 [RFC2119] [RFC8174] when, and only when, they appear in all 38 capitals, as shown here. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at https://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on 26 August 2022. 57 Copyright Notice 59 Copyright (c) 2022 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 64 license-info) in effect on the date of publication of this document. 65 Please review these documents carefully, as they describe your rights 66 and restrictions with respect to this document. Code Components 67 extracted from this document must include Revised BSD License text as 68 described in Section 4.e of the Trust Legal Provisions and are 69 provided without warranty as described in the Revised BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 74 2. SRv6 endpoint behaviors . . . . . . . . . . . . . . . . . . . 3 75 2.1. End.B6.Insert: Endpoint bound to an SRv6 policy . . . . . 3 76 2.2. End.B6.Insert.Red: [...] with reduced SRH . . . . . . . . 4 77 3. SR Policy Headend Behaviors . . . . . . . . . . . . . . . . . 5 78 3.1. H.Insert: SR Headend with insertion of an SRv6 Policy . . 5 79 3.2. H.Insert.Red: H.Insert with reduced insertion . . . . . . 5 80 4. Maximum H.Insert MSD Type . . . . . . . . . . . . . . . . . . 6 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 82 5.1. SRv6 Endpoint Behaviors . . . . . . . . . . . . . . . . . 6 83 5.2. MSD Types . . . . . . . . . . . . . . . . . . . . . . . . 6 84 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 85 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 87 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 88 8.2. Informative References . . . . . . . . . . . . . . . . . 11 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 91 1. Introduction 93 Packets transiting an SR Domain may be steered into an SR Policy for 94 a variety of reasons. For example, a PLR router reroutes traffic on 95 a TI-LFA repair path [I-D.ietf-rtgwg-segment-routing-ti-lfa] or when 96 a Binding-SID is expanded [I-D.ietf-spring-segment-routing-policy]. 98 This document extends the SRv6 Network Programming [RFC8986] model 99 with new endpoint and transit behaviors enabling the insertion of an 100 SRH after the outer IPv6 header of the SR domain. The operations 101 described in this document must take into account the considerations 102 described in [I-D.voyer-6man-extension-header-insertion]. 104 2. SRv6 endpoint behaviors 106 SRv6 Network Programming Section 4 defines a base set of SRv6 107 endpoint behaviors. This is extended with the behaviors described in 108 this section. 110 2.1. End.B6.Insert: Endpoint bound to an SRv6 policy 112 The "Endpoint bound to an SRv6 Policy" is a variant of the End 113 behavior. 115 One of its applications is to express scalable traffic-engineering 116 policies across multiple domains. It is the one of the SRv6 117 instantiations of a Binding SID [RFC8402]. 119 An End.B6.Insert SID is never the last segment in a SID list, and any 120 SID instantiation must be associated with an SR Policy 121 B[I-D.ietf-spring-segment-routing-policy]. 123 When N receives a packet whose IPv6 DA is S and S is a local 124 End.B6.Insert SID, does: 126 S01. When an SRH is processed { 127 S02. If (Segments Left == 0) { 128 S03. Send an ICMP Parameter Problem message to the Source Address 129 Code TBD-SRH (SR Upper-layer Header Error), 130 Pointer set to the offset of the upper-layer header, 131 interrupt packet processing and discard the packet 132 S04. } 133 S04. If (IPv6 Hop Limit <= 1) { 134 S05. Send an ICMP Time Exceeded message to the Source Address, 135 Code 0 (Hop limit exceeded in transit), 136 interrupt packet processing and discard the packet 137 S06. } 138 S07. max_LE = (Hdr Ext Len / 2) - 1 139 S08. If ((Last Entry > max_LE) or (Segments Left > (Last Entry+1)){ 140 S09. Send an ICMP Parameter Problem to the Source Address, 141 Code 0 (Erroneous header field encountered), 142 Pointer set to the Segments Left field, 143 interrupt packet processing and discard the packet 144 S11. } 145 S12. Decrement Hop Limit by 1 146 S13. Insert a new SRH in between the IPv6 Header and the received 147 SRH containing the list of segments of B 148 S14. Set the IPv6 DA to the first segment of B 149 S15. Resubmit the packet to the egress IPv6 FIB lookup and 150 transmission to the new destination 151 S16. } 153 When processing the Upper-layer header of a packet matching a FIB 154 entry locally instantiated as an SRv6 End.B6.Insert SID, send an ICMP 155 parameter problem message to the Source Address and discard the 156 packet. Error code "SR Upper-layer Header Error", Pointer set to the 157 offset of the upper-layer header. 159 2.2. End.B6.Insert.Red: [...] with reduced SRH 161 This is an optimization of the End.B6.Insert behavior. 163 End.B6.Insert.Red reduces the size of the new SRH by one SID by 164 avoiding the insertion of the first SID in the pushed SRH. In this 165 way, the first SID is only written in the DA and the packet is 166 forwarded according to it. 168 The new SRH is created as described in Section 4.1.1 of [RFC8754]. 170 3. SR Policy Headend Behaviors 172 SRv6 Network Programming defines in Section 5 a set of SR Policy 173 Headend Behaviors. This is extended with the following behaviors 174 defined in this section. 176 3.1. H.Insert: SR Headend with insertion of an SRv6 Policy 178 Node N receives two packets P1=(A, B2) and P2=(A,B2)(B3, B2, B1; 179 SL=1). B2 is neither a local address nor SID of N. 181 N steers the transit packets P1 and P2 into an SRv6 Policy with one 182 SID list . 184 The "H.Insert" transit insertion behavior is defined as follows: 186 1. insert the SRH (B2, S3, S2, S1; SL=3) ;; Ref1, Ref1bis 187 2. set the IPv6 DA = S1 188 3. forward along the shortest path to S1 190 Ref1: The received IPv6 DA is placed as last SID of the inserted SRH. 192 Ref1bis: The SRH is inserted 193 [I-D.voyer-6man-extension-header-insertion] before any other IPv6 194 Routing Extension Header. 196 After the H.Insert behavior, P1 and P2 respectively look like: 198 1. (A, S1) (B2, S3, S2, S1; SL=3) 200 2. (A, S1) (B2, S3, S2, S1; SL=3) (B3, B2, B1; SL=1) 202 3.2. H.Insert.Red: H.Insert with reduced insertion 204 The H.Insert.Red behavior is an optimization of the H.Insert 205 behavior. It is defined as follows: 207 1. insert the SRH (B2, S3, S2; SL=3) 208 2. set the IPv6 DA = S1 209 3. forward along the shortest path to S1 211 H.Insert.Red will reduce the size of the SRH by one segment by 212 avoiding the insertion of the first SID in the pushed SRH. In this 213 way, the first segment is only introduced in the DA and the packet is 214 forwarded according to it. 216 After the H.Insert.Red behavior, P1 and P2 respectively look like: 218 1. (A, S1) (B2, S3, S2; SL=3) 220 2. (A, S1) (B2, S3, S2; SL=3) (B3, B2, B1; SL=1) 222 4. Maximum H.Insert MSD Type 224 This document defines the MSD (Maximum SID Depth) for H.Insert 225 behavior and requests the MSD type assignment from the IGP MSD-Types 226 registry created by [RFC8491]. 228 The Maximum H.Insert MSD Type specifies the maximum number of SIDs 229 that can be inserted as part of the "H.insert" behavior: 231 1. Max H.insert Type: 43 (Suggested value - to be assigned by IANA) 233 If the advertised value is zero or no value is advertised then the 234 router is assumed not to support any variation of the "H.insert" 235 behavior. 237 5. IANA Considerations 239 5.1. SRv6 Endpoint Behaviors 241 This document requests IANA to allocate the following codepoints 242 within the "SRv6 Endpoint Behaviors" sub-registry under the top-level 243 "Segment Routing Parameters" registry. 245 +=======+========+===================+===========+ 246 | Value | Hex | Endpoint behavior | Reference | 247 +=======+========+===================+===========+ 248 | 13 | 0x000D | End.B6.Insert | [This.ID] | 249 +-------+--------+-------------------+-----------+ 250 | 26 | 0x001A | End.B6.Insert.Red | [This.ID] | 251 +-------+--------+-------------------+-----------+ 253 Table 1: IETF - SRv6 Endpoint Behaviors 255 5.2. MSD Types 257 This document requests IANA to allocate the following codepoint 258 within the "IGP MSD-Types" sub-registry under the top-level "IGP 259 Parameters" registry. 261 +=======+======+===================+===========+ 262 | Value | Hex | Endpoint behavior | Reference | 263 +=======+======+===================+===========+ 264 | 43 | 0x2B | Max H.Insert | [This.ID] | 265 +-------+------+-------------------+-----------+ 267 Table 2: IETF - MSD Types 269 6. Acknowledgements 271 The authors would like to acknowledge Stefano Previdi, Dave Barach, 272 Mark Townsley, Peter Psenak, Thierry Couture, Kris Michielsen, Paul 273 Wells, Robert Hanzl, Dan Ye, Gaurav Dawra, Faisal Iqbal, Jaganbabu 274 Rajamanickam, David Toscano, Asif Islam, Jianda Liu, Yunpeng Zhang, 275 Jiaoming Li, Narendra A.K, Mike Mc Gourty, Bhupendra Yadav, Sherif 276 Toulan, Satish Damodaran, John Bettink, Kishore Nandyala Veera Venk, 277 Jisu Bhattacharya and Saleem Hafeez. 279 7. Contributors 281 Daniel Bernier 283 Bell Canada 285 Canada 287 Email: daniel.bernier@bell.ca 289 Dirk Steinberg 291 Lapishills Consulting Limited 293 Cyprus 295 Email: dirk@lapishills.com 297 Robert Raszuk 299 Bloomberg LP 301 United States of America 303 Email: robert@raszuk.net 305 Bart Peirens 307 Proximus 308 Belgium 310 Email: bart.peirens@proximus.com 312 Hani Elmalky 314 Ericsson 316 United States of America 318 Email: hani.elmalky@gmail.com 320 Prem Jonnalagadda 322 Barefoot Networks 324 United States of America 326 Email: prem@barefootnetworks.com 328 Milad Sharif 330 Barefoot Networks 332 United States of America 334 Email: msharif@barefootnetworks.com 336 David Lebrun 338 Google 340 Belgium 342 Email: dlebrun@google.com 344 Stefano Salsano 346 Universita di Roma "Tor Vergata" 348 Italy 350 Email: stefano.salsano@uniroma2.it 352 Ahmed AbdelSalam 354 Gran Sasso Science Institute 355 Italy 357 Email: ahmed.abdelsalam@gssi.it 359 Gaurav Naik 361 Drexel University 363 United States of America 365 Email: gn@drexel.edu 367 Arthi Ayyangar 369 Arista 371 United States of America 373 Email: arthi@arista.com 375 Satish Mynam 377 Innovium Inc. 379 United States of America 381 Email: smynam@innovium.com 383 Wim Henderickx 385 Nokia 387 Belgium 389 Email: wim.henderickx@nokia.com 391 Shaowen Ma 393 Juniper 395 Singapore 397 Email: mashao@juniper.net 399 Ahmed Bashandy 401 Individual 402 United States of America 404 Email: abashandy.ietf@gmail.com 406 Francois Clad 408 Cisco Systems, Inc. 410 France 412 Email: fclad@cisco.com 414 Kamran Raza 416 Cisco Systems, Inc. 418 Canada 420 Email: skraza@cisco.com 422 Darren Dukes 424 Cisco Systems, Inc. 426 Canada 428 Email: ddukes@cisco.com 430 Patrice Brissete 432 Cisco Systems, Inc. 434 Canada 436 Email: pbrisset@cisco.com 438 Zafar Ali 440 Cisco Systems, Inc. 442 United States of America 444 Email: zali@cisco.com 446 8. References 448 8.1. Normative References 450 [I-D.voyer-6man-extension-header-insertion] 451 Voyer, D., Filsfils, C., Dukes, D., Matsushima, S., Leddy, 452 J., Li, Z., and J. Guichard, "Deployments With Insertion 453 of IPv6 Segment Routing Headers", Work in Progress, 454 Internet-Draft, draft-voyer-6man-extension-header- 455 insertion-10, 20 November 2020, 456 . 459 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 460 Requirement Levels", BCP 14, RFC 2119, 461 DOI 10.17487/RFC2119, March 1997, 462 . 464 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 465 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 466 May 2017, . 468 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 469 Decraene, B., Litkowski, S., and R. Shakir, "Segment 470 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 471 July 2018, . 473 [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 474 "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, 475 DOI 10.17487/RFC8491, November 2018, 476 . 478 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 479 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 480 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 481 . 483 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 484 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 485 (SRv6) Network Programming", RFC 8986, 486 DOI 10.17487/RFC8986, February 2021, 487 . 489 8.2. Informative References 491 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 492 Litkowski, S., Bashandy, A., Filsfils, C., Francois, P., 493 Decraene, B., and D. Voyer, "Topology Independent Fast 494 Reroute using Segment Routing", Work in Progress, 495 Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa- 496 08, 21 January 2022, . 499 [I-D.ietf-spring-segment-routing-policy] 500 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 501 P. Mattes, "Segment Routing Policy Architecture", Work in 502 Progress, Internet-Draft, draft-ietf-spring-segment- 503 routing-policy-18, 17 February 2022, 504 . 507 Authors' Addresses 509 Clarence Filsfils (editor) 510 Cisco Systems, Inc. 511 Belgium 512 Email: cf@cisco.com 514 Pablo Camarillo Garvia (editor) 515 Cisco Systems, Inc. 516 Spain 517 Email: pcamaril@cisco.com 519 John Leddy 520 Individual Contributor 521 United States of America 522 Email: john@leddy.net 524 Daniel Voyer 525 Bell Canada 526 Canada 527 Email: daniel.voyer@bell.ca 529 Satoru Matsushima 530 SoftBank 531 1-9-1,Higashi-Shimbashi,Minato-Ku, Tokyo 105-7322 532 Japan 533 Email: satoru.matsushima@g.softbank.co.jp 535 Zhenbin Li 536 Huawei Technologies 537 China 538 Email: lizhenbin@huawei.com