idnits 2.17.1 draft-chunduri-lsr-isis-preferred-path-routing-07.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 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A complete PPR path may not fit into the maximum allowable size of the IS-IS TLV. To overcome this a 7 bit Fragment-ID field is defined in Section 3 . With this, a single PPR path is represented via one or more fragmented PPR path TLVs, with all having the same PPR-ID. Each fragment carries the PPR-ID as well as a numeric Fragment-ID from 0 to (N-1), when N fragments are needed to describe the PPR Graph (where N>1). In this case Fragment (N-1) MUST set the 'U' bit (PPR-Flags) to indicate it is the last fragment. If Fragment-ID is non-zero in the TLV, then it MUST not carry PPR-Prefix Sub-TLV. The optional PPR Attribute Sub-TLVs which describe the path overall MUST be included in the last fragment only (i.e., when the 'U' bit is set). -- The document date (November 12, 2021) is 889 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: 'I-D.bryant-rtgwg-plfa' is defined on line 882, but no explicit reference was found in the text == Unused Reference: 'I-D.chunduri-dmm-5g-mobility-with-ppr' is defined on line 887, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-dmm-tn-aware-mobility' is defined on line 893, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-teas-enhanced-vpn' is defined on line 922, but no explicit reference was found in the text == Unused Reference: 'RFC8402' is defined on line 988, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-chunduri-rtgwg-preferred-path-routing-01 == Outdated reference: A later version (-04) exists of draft-bryant-rtgwg-plfa-02 == Outdated reference: A later version (-09) exists of draft-ietf-dmm-tn-aware-mobility-02 == Outdated reference: A later version (-19) exists of draft-ietf-lsr-isis-srv6-extensions-18 == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-09 Summary: 0 errors (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LSR Working Group U. Chunduri 3 Internet-Draft Intel Corporation 4 Intended status: Standards Track R. Li 5 Expires: May 16, 2022 Futurewei 6 R. White 7 Juniper Networks 8 L. Contreras 9 Telefonica 10 J. Tantsura 11 Microsoft 12 Y. Qu 13 Futurewei 14 November 12, 2021 16 Preferred Path Routing (PPR) in IS-IS 17 draft-chunduri-lsr-isis-preferred-path-routing-07 19 Abstract 21 This document specifies a Preferred Path Routing (PPR), a routing 22 protocol mechanism to simplify the path description using IS-IS 23 protocol. PPR builds on existing encapsulation to add the path 24 identity to the packet and supports further extensions along the 25 preferred paths. PPR aims to provide path steering, services and 26 support further extensions along the paths. Preferred path routing 27 is achieved through the addition of path descriptions to the IS-IS 28 advertised prefixes, and mapping those to a PPR data-plane 29 identifier. 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in RFC2119 [RFC2119], 36 RFC8174 [RFC8174] when, and only when they appear in all capitals, as 37 shown here. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on May 16, 2022. 56 Copyright Notice 58 Copyright (c) 2021 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (https://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. PPR Details . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 2.1. PPR-ID and Data Plane Extensibility . . . . . . . . . . . 4 77 2.2. PPR Path Description . . . . . . . . . . . . . . . . . . 4 78 2.3. ECMP Considerations . . . . . . . . . . . . . . . . . . . 5 79 3. PPR Related TLVs . . . . . . . . . . . . . . . . . . . . . . 5 80 3.1. PPR-Prefix Sub-TLV . . . . . . . . . . . . . . . . . . . 7 81 3.2. PPR-ID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 8 82 3.3. PPR-PDE Sub-TLV . . . . . . . . . . . . . . . . . . . . . 9 83 3.4. PPR-Attributes Sub-TLV . . . . . . . . . . . . . . . . . 12 84 4. PPR Processing Procedure Example . . . . . . . . . . . . . . 13 85 4.1. PPR TLV Processing . . . . . . . . . . . . . . . . . . . 14 86 4.2. Path Fragments . . . . . . . . . . . . . . . . . . . . . 15 87 5. PPR Data Plane aspects . . . . . . . . . . . . . . . . . . . 15 88 5.1. SR-MPLS with PPR . . . . . . . . . . . . . . . . . . . . 15 89 5.2. PPR Native IP Data Planes . . . . . . . . . . . . . . . . 16 90 5.3. SRv6 with PPR . . . . . . . . . . . . . . . . . . . . . . 16 91 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 92 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 93 7.1. PPR Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . 17 94 7.2. IGP Parameters . . . . . . . . . . . . . . . . . . . . . 18 95 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 96 9. Contributing Authors . . . . . . . . . . . . . . . . . . . . 18 97 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 98 10.1. Normative References . . . . . . . . . . . . . . . . . . 19 99 10.2. Informative References . . . . . . . . . . . . . . . . . 19 100 Appendix A. Appendix . . . . . . . . . . . . . . . . . . . . . . 22 101 A.1. Challenges with Increased SID Depth . . . . . . . . . . . 22 102 A.2. Mitigation with MSD . . . . . . . . . . . . . . . . . . . 24 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 105 1. Introduction 107 PPR involves associating path descriptions to IS-IS advertised 108 prefixes, mapping those to a data-plane identifier and specifying a 109 mechanism to route packets with the abstracted identifier (PPR-ID), 110 as opposed to individual segments on the packet. This is specified 111 in detail in [I-D.chunduri-rtgwg-preferred-path-routing], along with 112 key use cases and deployment scenarios. PPR allows the traffic along 113 an engineered path through the network by replacing the label stack 114 with a path identifier, PPR-ID, in the packet. The PPR-ID can either 115 be a single label or a native destination address. To facilitate the 116 use of a single label to describe an entire path, a new TLV is added 117 to IS-IS, as described below in Section 3. 119 A PPR could be an SR path, a traffic engineered path computed based 120 on some constraints, an explicitly provisioned Fast Re-Route (FRR) 121 path or a service chained path. A PPR can be signaled by any node, 122 computed by a central controller, or manually configured by an 123 operator. PPR extends the source routing and path steering 124 capabilities to native IP (IPv4 and IPv6) data planes without 125 hardware upgrades; see Section 5. 127 1.1. Acronyms 129 EL - Entropy Label 131 ELI - Entropy Label Indicator 133 LSP - IS-IS Link State PDU 135 MPLS - Multi Protocol Label Switching 137 MSD - Maximum SID Depth 139 MTU - Maximum Transferrable Unit 141 NH - Next-Hop 143 PPR - Preferred Path Routing/Route 144 PPR-ID - Preferred Path Route Identifier, a data plane identifier 146 SID - Segment Identifier 148 SPF - Shortest Path First 150 SR-MPLS - Segment Routing with MPLS data plane 152 SRH - Segment Routing Header - IPv6 routing Extension header 154 SRv6 - Segment Routing with IPv6 data plane with SRH 156 TE - Traffic Engineering 158 2. PPR Details 160 2.1. PPR-ID and Data Plane Extensibility 162 The PPR-ID describes a path through the network. A data plane type 163 and corresponding data plane identifier as specified in Section 3.2 164 is mapped to PPR-ID to allow data plane extensibility. 166 For SR-MPLS, PPR-ID is mapped to an MPLS Label/SID and for SRv6, this 167 is mapped to an IPv6-SID. For native IP data planes, this is mapped 168 to either IPv4 or IPv6 address/prefix. 170 2.2. PPR Path Description 172 The path identified by the PPR-ID is described as a set of Path 173 Description Elements (PDEs), each of which represents a segment of 174 the path. Each node determines its location in the path as 175 described, and forwards to the next segment/hop or label of the path 176 description (see the Forwarding Procedure Example later in this 177 document). 179 These PPR-PDEs as defined in Section 3.3, like SR SIDs, can represent 180 topological elements like links/nodes, backup nodes, as well as non- 181 topological elements such as a service, function, or context on a 182 particular node. 184 A PPR path can be described as a Strict-PPR or a Loose-PPR. In a 185 Strict-PPR all nodes/links on the path are described with SR SIDs for 186 SR data planes or IPv4/IPv6 addresses for native IP data planes. In 187 a Loose-PPR only some of the nodes/links from source to destination 188 are described. More specifics and restrictions around Strict/Loose 189 PPRs are described in respective data planes in Section 5. Each PDE 190 is described as either an MPLS label towards the Next-Hop (NH) in 191 MPLS enabled networks, or as an IP NH, in the case of either 192 "plain"/"native" IP or SRv6 enabled networks. A PPR path is related 193 to a set of PDEs using the TLVs as specified in Section 3. 195 2.3. ECMP Considerations 197 PPR inherently supports Equal Cost Multi Path (ECMP) for both strict 198 and loose paths. If a path is described using nodes, it would have 199 ECMP NHs established for PPR-ID along the path. However, one can 200 avoid ECMP on any segment of the path by pinning the path using a 201 link identifier to the next segment. 203 3. PPR Related TLVs 205 This section describes the encoding of PPR TLV. This TLV can be seen 206 as having 4 logical sections viz, encoding of the PPR-Prefix (IS-IS 207 Prefix), encoding of PPR-ID, encoding of path description with an 208 ordered PDE Sub-TLVs and a set of optional PPR attribute Sub-TLVs, 209 which can be used to describe one or more parameters of the path. 210 Multiple instances of this TLV MAY be advertised in IS-IS LSPs with 211 different PPR-ID Type (data plane) and with corresponding PDE Sub- 212 TLVS. The PPR TLV has Type TBD (suggested value xxx), and has the 213 following format: 215 0 1 2 3 216 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 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Type | Length | PPR-Flags | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Fragment-ID | MT-ID | Algorithm | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | PPR-Prefix Sub-TLV (variable size) | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | PPR-ID Sub-TLV (variable size) | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | PPR-PDE Sub-TLVs (variable) | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | PPR-Attribute Sub-TLVs (variable) | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 Figure 1: PPR TLV Format 233 o Type: 155 (Suggested Value, TBD IANA) from IS-IS top level TLV 234 registry. 236 o Length: Total length of the value field in bytes. 238 o PPR-Flags: 2 Octet bit-field of flags for this TLV; described 239 below. 241 o Fragment-ID: This is an 8-bit Identifier value (0-255) of the TLV 242 fragment. If fragments are not needed to represent the complete 243 path, 'U' bit MUST be set and this value MUST be set to 0. 245 o MT-ID: The multi-topology identifier defined in [RFC5120]; the 4 246 most significant bits MUST be set to 0 on transmit and ignored on 247 receive. The remaining 12-bit field contains the MT-ID. 249 o Algorithm: 1 octet value represents the route computation 250 algorithm. Algorithm registry is as defined in [RFC8667]. 251 Computation towards PPR-ID (Section 3.2) happens per MT-ID/ 252 Algorithm pair. 254 o PPR-Prefix: A variable size Sub-TLV representing the destination 255 of the path being described. This is defined in Section 3.1. 257 o PPR-ID: A variable size Sub-TLV representing the data plane or 258 forwarding identifier of the PPR. Defined in Section 3.2. 260 o PPR-PDEs: Variable number of ordered PDE Sub-TLVs which represents 261 the path. This is defined in Section 3.3. 263 o PPR-Attributes: Variable number of PPR-Attribute Sub-TLVs which 264 represent the path attributes. These are defined in Section 3.4. 266 The Flags field has the following flag bits defined: 268 PPR TLV Flags Format 270 0 1 2 3 4 5 6 7 15 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 |F|D|A|U|Reserved | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 1. F: Flood bit. If set, the PPR TLV MUST be flooded across the 276 entire routing domain. If the F bit is not set, the PPR TLV MUST 277 NOT be leaked between IS-IS levels. This bit MUST NOT be altered 278 during the TLV leaking 280 2. D: Down Bit. When the PPR TLV is leaked from IS-IS level-2 to 281 level-1, the D bit MUST be set. Otherwise, this bit MUST be 282 clear. PPR TLVs with the D bit set MUST NOT be leaked from 283 level-1 to level-2. This is to prevent TLV looping across 284 levels. 286 3. A: Attach bit. The originator of the PPR TLV MUST set the A bit 287 in order to signal that the prefix and PPR-ID advertised in the 288 PPR TLV are directly connected to the originators. If this bit 289 is not set, this allows any other node in the network to 290 advertise this TLV on behalf of the originating node of the PPR- 291 Prefix. If PPR TLV is leaked to other areas/levels the A-flag 292 MUST be cleared. In case if the originating node of the prefix 293 must be disambiguated for any reason including, if it is a Multi 294 Homed Prefix (MHP) or leaked to a different IS-IS level or 295 because [RFC7794] X-Flag is set, then PPR-Attribute Sub-TLV 296 Source Router ID SHOULD be included. 298 4. U: Ultimate fragment bit. bit MUST be set if a path has only one 299 fragment or if it is the last Fragment of the path. PPR-ID value 300 for all fragments of the same path MUST be the same. 302 5. Reserved: For future use; MUST be set to 0 on transmit and 303 ignored on receive. 305 PPR path description for each IS-IS level is computed and given to 306 one of the nodes for L1 and L2 respectively. Similarly path 307 information when crossing the level boundaries MUST be relevant to 308 the destination level. If there is no path information available for 309 the destination level PPR TLV MUST NOT be leaked regardless of F and 310 D bits as defined above. 312 The following Sub-TLVs draw from a new registry for Sub-TLV numbers 313 as specified in Section 7.1 and Section 7.2. 315 3.1. PPR-Prefix Sub-TLV 317 The structure of PPR-Prefix is: 319 0 1 2 3 320 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 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Type | Length | Prefix Length | Mask Length | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 // IS-IS Prefix (variable) // 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 Figure 2: PPR-Prefix Sub-TLV Format 329 o Type: 1 (IANA to assign from Sub-TLV registry described above). 331 o Length: Total length of the value field in bytes. 333 o Prefix Length: The length of the IS-IS Prefix being encoded in 334 bytes. For IPv4 it MUST be 4 and IPv6 it MUST be 16 bytes. 336 o Mask Length: The length of the prefix in bits. Only the most 337 significant octets of the Prefix are encoded. 339 o IS-IS Prefix: The IS-IS prefix at the tail-end of the advertised 340 PPR. This corresponds to a routable prefix of the originating 341 node and it MAY have one of the [RFC7794] flags set (X-Flag/R- 342 Flag/N-Flag) in the IS-IS reachability TLVs. Length of this field 343 MUST be as per "Prefix Length". Encoding is same as TLV 135 344 [RFC5305] and TLV 236 [RFC5308] or MT-Capable [RFC5120] IPv4 (TLV 345 235) and IPv6 Prefixes (TLV 237) respectively. 347 3.2. PPR-ID Sub-TLV 349 This is the actual data plane identifier in the packet header and 350 could be of any data plane as defined in the PPR-ID Type field. Both 351 PPR-Prefix and PPR-ID belongs to a same node in the network. 353 0 1 2 3 354 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 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Type | Length |PPR-ID Flags | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | PPR-ID Type | PPR-ID Length |PPR-ID Mask Len| 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 // PPR-ID (variable size) // 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 Figure 3: PPR-ID Sub-TLV Format 365 o Type: 2 (IANA to assign from Sub-TLV registry described above). 367 o Length: Total length of the value field in bytes. 369 o PPR-ID Flags: 2 Octet field for PPR-ID flags: 371 PPR-ID Flags Format 373 0 1 2 3 4 5 6 7.. 15 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Reserved | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 Reserved: For future use; MUST be set to 0 on transmit and 379 ignored on receive. 381 o PPR-ID Type: Data plane type of PPR-ID. This is a new registry 382 (TBD IANA - Suggested values as below) for this Sub-TLV and the 383 defined types are as follows: 385 Type: 1 SR-MPLS SID/Label 387 Type: 2 Native IPv4 Address/Prefix 389 Type: 3 Native IPv6 Address/Prefix 391 Type: 4 IPv6 SID in SRv6 with SRH 393 o PPR-ID Length: Length of the PPR-ID field in octets and this 394 depends on the PPR-ID type. 396 o PPR-ID Mask Len: It is applicable only for PPR-ID Type 2, 3 and 4. 397 For Type 1 this value MUST be set to zero. It contains the length 398 of the PPR-ID Prefix in bits. Only the most significant octets of 399 the Prefix are encoded. This is needed, if PPR-ID followed by an 400 IPv4/IPv6 Prefix instead of 4/16 octet Address respectively. 402 o PPR-ID: This is the Preferred Path forwarding identifier that 403 would be on the data packet. The value of this field is variable 404 and it depends on the PPR-ID Type - for Type 1, this is encoded as 405 SR-MPLS SID/Label. For Type 2 this is a 4 byte IPv4 address. For 406 Type 3 this is a 16 byte IPv6 address. For Type 2 and Type 3 407 encoding is similar to "IS-IS Prefix" as specified in Section 3.1. 408 For Type 4, this is encoded as 16 byte SRv6 SID. 410 For PPR-ID Type 2, 3 or 4, PPR-ID MUST NOT be advertised as a 411 routable prefix in TLV 135, TLV 235, TLV 236 and TLV 237. PPR-ID 412 MUST belong to the node, from where the PPR-Prefix (Section 3.1) is 413 advertised. 415 3.3. PPR-PDE Sub-TLV 417 This Sub-TLV represents the PPR Path Description Element (PDE). PPR- 418 PDEs are used to describe the path in the form of a set of contiguous 419 and ordered Sub-TLVs, where first Sub-TLV represents (the top of the 420 stack in MPLS data plane or) first node/segment of the path. These 421 sets of ordered Sub-TLVs can have both topological elements and non- 422 topological elements (e.g., service segments). 424 0 1 2 3 425 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 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Type | Length | PPR-PDE Type | PDE-ID Type | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | PDE-ID Length | PPR-PDE Flags | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 // PDE-ID Value (variable size) // 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 |Sub-TLV Length | PPR-PDE Sub-TLVs (variable) | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 Figure 4: PPR-PDE Sub-TLV Format 438 o Type: 3 (See IANA for suggested value) from IS-IS PPR TLV 439 Section 3 Sub-TLV registry. 441 o Length: Total length of the value field in bytes. 443 o PPR-PDE Type: A new registry (TBD IANA) for this Sub-TLV and the 444 defined types are as follows: 446 Type: 1 Topological 448 Type: 2 Non-Topological 450 o PDE-ID Type: 1 Octet PDE-forwarding IDentifier Type. A new 451 registry (Suggested Values as listed, IANA TBD) for this Sub-TLV 452 and the defined types and corresponding PDE-ID Length, PDE-ID 453 Value are as follows: 455 Type 0: This value MUST be set only when PPR-PDE Type is Non- 456 Topological. PDE-ID Length indicates the length of the PDE-ID 457 Value field in bytes. For this type, PDE-ID value represents a 458 service/function. This information is provisioned on the 459 immediate topological PDE preceding this PDE based on the 'E' 460 bit. 462 Type 1: SID/Label type as defined in [RFC8667]. PDE-ID Length 463 and PDE-ID Value fields are per Section 2.3 of the referenced 464 document. 466 Type 2: SR-MPLS Prefix SID. PDE-ID Length and PDE-ID Value are 467 same as Type 1. 469 Type 3: SR-MPLS Adjacency SID. PDE-ID Length and PDE-ID Value 470 are same as Type 1. 472 Type 4: IPv4 Node Loopback Address. PDE-ID Length 4 bytes and 473 PDE-ID Value is full 4 bytes IPv4 address encoded as specified 474 in "4-octet IPv4 address" of Sub-TLV 6/TLV 22 in [RFC5305]. 476 Type 5: IPv4 Interface Address. PDE-ID Length is 4 bytes and 477 PDE-ID Value is full 4 bytes IPv4 address encoded as specified 478 in "4-octet IPv4 address" of Sub-TLV 6/TLV 22 in [RFC5305]. 479 This PDE-ID in the path description represents the egress 480 interface of the path segment and corresponding adjacency is set 481 as nexthop for the PPR-ID. 483 Type 6: IPv6 Node Loopback Address. PDE-ID Length and PDE-ID 484 Value are encoded as specified in "Prefix Len" and "prefix" 485 portion of TLV 236 in [RFC5308] respectively. 487 Type 7: IPv6 Interface Address. PDE-ID Length is 16 bytes and 488 PDE-ID Value is full 16 bytes IPv6 address encoded as specified 489 in "Interface Address 1" portion of TLV 232 in [RFC5308]. This 490 PDE-ID in the path description represents the egress interface 491 of the path segment and corresponding adjacency is set as 492 nexthop for the PPR-ID. 494 Type 8: SRv6 Node SID as defined in 495 [I-D.ietf-lsr-isis-srv6-extensions]. PDE-ID Length and PDE-ID 496 Value are as defined in SRv6 SID from the referenced draft. 498 Type 9: SRv6 Adjacency-SID. PDE-ID Length and PDE-ID Values are 499 similar to SRv6 Node SID above. 501 o PPR-PDE Flags: 2 Octet bit-field of flags; described below: 503 PPR-PDE Flags Format 505 0 1 2 3 4 5 6 7 .. 15 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 |L|N|E| Reserved | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 L: Loose Bit. Indicates the type of next "Topological PDE-ID" in 511 the path description. This bit MUST be set for only Node/Prefix 512 PDE type. If this flag is unset, the next Topological PDE is 513 Strict Type. 515 N: Node Bit. By default this bit MUST be unset. This bit MUST 516 be set only for PPR-PDE Type is 1 i.e., Topological and this PDE 517 represents the node, where PPR-Prefix (Section 3.1) belongs to 518 (if there is no further PDE specific Sub-TLVs to override PPR- 519 Prefix and PPR-ID values). 521 E: Egress Bit. By default this bit MUST be unset. This bit MUST 522 be set only for PPR-PDE Type is 2 i.e., Non-Topological and the 523 service needs to be applied on the egress side of the 524 topological PDE preceding this PDE. 526 Reserved: Reserved bits for future use. Reserved bits MUST be 527 reset on transmission and ignored on receive. 529 o Sub-TLV Length: 1 byte length of all Sub-TLVs followed. It MUST 530 be set to 0 if no further Sub-TLVs are present. 532 o PPR-PDE Sub-TLVs: These have 1 octet type, 1 octet length and 533 value field is defined per the type field. Types are as defined 534 in PPR-TLV Sub-TLVs (Section 7), encoded further as sub-sub-TLVs 535 of PPR-PDE and the length field represents the total length of the 536 value field in bytes. 538 IS-IS System-ID Sub-TLV: Type 4 (IANA TBD), Length Total length 539 of value field in bytes, Value: IS-IS System-ID of length "ID 540 Length" as defined in [ISO.10589.1992]. This Sub-TLV MUST NOT 541 be present, if the PPR-PDE Type is not Topological. Though the 542 type for this comes from the PPR Sub-TLV registry, here this is 543 a sub-sub-TLV and is part of PPR-ID/PPR-PDE Sub-TLV. 545 3.4. PPR-Attributes Sub-TLV 547 PPR-Attribute Sub-TLVs describe the attributes of the path. This 548 document defines the following optional PPR-Attribute Sub-TLVs: 550 o Type 5 (Suggested Value - IANA TBD): PPR-Prefix originating node's 551 IPv4 Router ID Sub-TLV. Length and Value fields are as specified 552 in [RFC7794]. 554 o Type 6 (Suggested Value - IANA TBD): PPR-Prefix originating node's 555 IPv6 Router ID Sub-TLV. Length and Value fields are as specified 556 in [RFC7794]. 558 o Type 7 (Suggested Value - IANA TBD): PPR-Metric Sub-TLV. Length 4 559 bytes, and Value is the metric of this path represented through 560 the PPR-ID. Different nodes can advertise the same PPR-ID for the 561 same Prefix with a different set of PPR-PDE Sub-TLVs and the 562 receiving node MUST consider the lowest metric value. 564 4. PPR Processing Procedure Example 566 As specified in [I-D.chunduri-rtgwg-preferred-path-routing], a PPR 567 can be a TE path, locally provisioned by the operator or by a 568 controller. Consider the following IS-IS network to describe the 569 operation of PPR TLV as defined in Section 3: 571 1 572 _______ 573 / 1 \ 574 +---R2-------R3---+ 575 / \_______/ \ 576 / 1 \ 577 1 / \ 1 578 / 1__R13__1 \ 579 / / \ \ 580 R1------R6 R7-----------R4 581 \ 2 \__R14__/ 2 /\ 582 \ 2 2 / \ 583 3 \ / 3 \1 584 \ 4 / \ 585 +----R8------R9-----R10------R12 586 \ 1 / 587 1 \ / 1 588 +----R11---+ 590 Figure 5: IS-IS Network 592 In the (Figure 5), consider node R1 as an ingress node, or a head-end 593 node, and the node R4 may be an egress node or another head-end node. 594 The numbers shown on links between nodes indicate the bi-directional 595 IS-IS metric as provisioned. R1 may be configured to receive TE 596 source routed path information from a central entity (PCE [RFC5440], 597 Netconf [RFC6241] or a Controller) that comprises PPR information 598 which relates to sources that are attached to R1. It is also 599 possible to have a PPR provisioned locally by the operator for non-TE 600 needs (e.g. FRR or for chaining certain services). 602 The PPR TLV (as specified in Section 3) is encoded as an ordered list 603 of PPR-PDEs from source to a destination node in the network and is 604 represented with a PPR-ID (Section 3.2). The PPR TLV includes PPR- 605 PDE Sub-TLVs Section 3.3, which represent both topological and non- 606 topological elements and specifies the actual path towards a PPR- 607 Prefix at R4. 609 o The shortest path towards R4 from R1 are through the following 610 sequence of nodes: R1-R2-R3-R4 based on the provisioned metrics. 612 o The central entity can define a few PPRs from R1 to R4 that 613 deviate from the shortest path based on other network 614 characteristic requirements as requested by an application or 615 service. For example, the network characteristics or performance 616 requirements may include bandwidth, jitter, latency, throughput, 617 error rate, etc. 619 o A first PPR may be identified by PPR-ID = 1 (value) and may 620 include the path of R1-R6-R7-R4 for a Prefix advertised by R4. 621 This is an example for a Loose-PPR and 'L' bit MUST be set 622 appropriately at Section 3.3. 624 o A second PPR may be identified by PPR-ID = 2 (value) and may 625 include the path of R1-R8-R9-R10-R4. This is an example for a 626 Strict-PPR and 'L' bit MUST be unset appropriately at Section 3.3. 627 Though this example shows PPR with all nodal SIDs, it is possible 628 to have a PPR with combination of node and adjacency SIDs (local 629 or global) or with PPR-PDE Type set to Non-Topological as defined 630 in Section 3.3 elements along with these. 632 4.1. PPR TLV Processing 634 The first topological sub-object or PDE (Section 3.3) relative to the 635 beginning of PPR Path contains the information about the first node 636 (e.g. in SR-MPLS it's the topmost label). The last topological sub- 637 object or PDE contains information about the last node (e.g. in SR- 638 MPLS it's the bottommost label). 640 Each receiving node determines whether an advertised PPR includes 641 information regarding the receiving node. Before processing any 642 further, validation MUST be done to see if any PPR topological PDE is 643 seen more than once (possible loop), if yes, this PPR TLV MUST be 644 ignored. Processing of PPR TLVs may be done, during the end of the 645 SPF computation (for MTID that is advertised in this TLV) and for 646 each prefix described through PPR TLV. For example, node R9 receives 647 the PPR information, and ignores the PPR-ID=1 (Section 4) because 648 this PPR TLV does not include node R9 in the path description/ordered 649 PPR-PDE list. 651 However, node R9 may determine that the second PPR identified by PPR- 652 ID = 2 does include the node R9 in its PDE list. Therefore, node R9 653 updates the local forwarding database to include an entry for the 654 destination address that R4 indicates, so that when a data packet 655 comprising a PPR-ID of 2 is received, forward the data packet to node 656 R10 instead of R11. This is done, even though from R9 the shortest 657 path to reach R4 via R11 (Cost 3: R9-R11-R12-R4) it chooses the NH to 658 R10 to reach R4 as specified in the PPR path description. Same 659 process happens to all nodes or all topological PDEs as described in 660 the PPR TLV. 662 In summary, the receiving node checks first, if this node is on the 663 path by checking the node's topological elements (with PPR-PDE Type 664 set to Topological) in the path list. If yes, it adds/adjusts the 665 PPR-ID's shortest path NH towards the next topological PDE in the 666 PPR's Path. 668 4.2. Path Fragments 670 A complete PPR path may not fit into the maximum allowable size of 671 the IS-IS TLV. To overcome this a 7 bit Fragment-ID field is defined 672 in Section 3 . With this, a single PPR path is represented via one 673 or more fragmented PPR path TLVs, with all having the same PPR-ID. 674 Each fragment carries the PPR-ID as well as a numeric Fragment-ID 675 from 0 to (N-1), when N fragments are needed to describe the PPR 676 Graph (where N>1). In this case Fragment (N-1) MUST set the 'U' bit 677 (PPR-Flags) to indicate it is the last fragment. If Fragment-ID is 678 non-zero in the TLV, then it MUST not carry PPR-Prefix Sub-TLV. The 679 optional PPR Attribute Sub-TLVs which describe the path overall MUST 680 be included in the last fragment only (i.e., when the 'U' bit is 681 set). 683 5. PPR Data Plane aspects 685 Data plane for PPR-ID is selected by the entity (e.g., a controller, 686 locally provisioned by operator), which selects a particular PPR in 687 the network. Section 3.2 defines various data plane identifier types 688 and a corresponding data plane identifier is selected by the entity 689 which selects the PPR. 691 5.1. SR-MPLS with PPR 693 If PPR-ID Type is 1, then the PPR belongs to SR-MPLS data plane and 694 the complete PPR stack is represented with a unique SR SID/Label and 695 this gets programmed on the data plane of each node, with the 696 appropriate NH computed as specified in Section 4. PPR-ID here is a 697 label/index from the SRGB (like another node SID or global ADJ-SID). 698 PPR path description here is a set of ordered SIDs represented with 699 PPR-PDE (Section 3.2) Sub-TLVs. Non-Topological segments are also 700 programmed in the forwarding to enable specific function/service, 701 when the data packet hits with corresponding PPR-ID. 703 Based on the 'L' flag in PPR-ID Flags (Section 3.2), for SR-MPLS data 704 plane either 1 label or 2 labels need to be provisioned on individual 705 nodes on the path description. For the example network in Section 4, 706 for PPR-ID=1, which is a loose path, node R6 programs the bottom 707 label as PPR-ID and the top label as the next topological PPR-PDE in 708 the path, which is a node SID of R7. The NH computed at R6 would be 709 the shortest path towards R7 i.e., the interface towards R13. If 'L' 710 flag is unset, only PPR-ID is programmed on the data plane with NH 711 set to the shortest path towards the next topological PPR-PDE. 713 5.2. PPR Native IP Data Planes 715 If PPR-ID Type is 2 then source routing and packet steering can be 716 done in IPv4 data plane (PPR-IPv4), along the path as described in 717 PPR Path description. This is achieved by setting the destination IP 718 address as PPR-ID, which is an IPv4 address in the data packet 719 (tunneled/encapsulated). There is no data plane change or upgrade 720 needed to support this. 722 Similarly for PPR-ID Type is 3, then source routing and packet 723 steering can be done in the IPv6 data plane (PPR-IPv6), along the 724 path as described in PPR Path description. Whatever specified above 725 for IPv4 applies here too, except that the destination IP address of 726 the data packet is an IPv6 Address (PPR-ID). This doesn't require 727 any IPv6 extension headers (EH), if there is no metadata/TLVs need to 728 be carried in the data packet. 730 Based on 'L' flag in PPR-ID Flags (Section 3.2), for PPR-ID Type 2 or 731 3 (Native IPv4 or IPv6 data planes respectively) the packet has to be 732 encapsulated using the capabilities (either dynamically signaled 733 through [I-D.ietf-isis-encapsulation-cap] or statically provisioned 734 on the nodes) of the next loose PDE in the path description. 736 For the example network in Section 4, for PPR-ID=1, which is a loose 737 path, node R6 programs to encapsulate the data packet towards the 738 next loose topological PPR-PDE in the path, which is R7. The NH 739 computed at R6 would be the shortest path towards R7 i.e., the 740 interface towards R13. If the 'L' flag is unset, only PPR-ID is 741 programmed on the data plane with NH set to the shortest path towards 742 the next topological PPR-PDE, with no further encapsulation of the 743 data packet. 745 5.3. SRv6 with PPR 747 If PPR-ID Type is 4, the PPR belongs to SRv6 with SRH data plane and 748 the complete PPR stack is represented with IPv6 SIDs and this gets 749 programmed on the data plane with the appropriate NH computed as 750 specified in Section 4. PPR-ID here is a SRv6 SID. PPR path 751 description here is a set of ordered SID TLVs similar to as specified 752 in Section 5.1. One way PPR-ID would be used in this case is by 753 setting it as the destination IPv6 address and SL field in SRH would 754 be set to 0; however SRH [RFC8754] can contain any other TLVs and 755 non-topological SIDs as needed. 757 6. Acknowledgements 759 Thanks to Alex Clemm, Lin Han, Toerless Eckert, Asit Chakraborti, 760 Stewart Bryant and Kiran Makhijani for initial discussions on this 761 topic. Thanks to Kevin Smith and Stephen Johnson for various 762 deployment scenarios applicability from ETSI WGs perspective. 763 Authors also acknowledge Alexander Vainshtein for detailed 764 discussions and few suggestions on this topic. 766 Earlier versions of [RFC8667] have a mechanism to advertise EROs 767 through Binding SID. 769 7. IANA Considerations 771 This document requests the following new TLV in IANA IS-IS TLV code- 772 point registry. 774 TLV # Name 775 ----- -------------- 776 155 PPR TLV (Suggested Value, IANA TBD) 778 7.1. PPR Sub-TLVs 780 This document requests IANA to create a new Sub-TLV registry for PPR 781 TLV Section 3 with the following initial entries (suggested values). 782 Though these are defined as Sub-TLVs of PPR TLV, these can be part of 783 another Sub-TLV as a nested sub-sub-TLV (e.g. IS-IS System-ID). 785 Sub-TLV # Sub-TLV Name 786 --------- --------------------------------------------------------- 788 1 PPR-Prefix (Section 3.1) 790 2 PPR-ID (Section 3.2) 792 3 PPR-PDE (Section 3.3) 794 4 IS-IS System-ID (Section 3.3) 796 5 PPR-Prefix Source IPv4 Router ID (Section 3.4) 798 6 PPR-Prefix Source IPv6 Router ID (Section 3.4) 800 7 PPR-Metric (Section 3.4) 802 7.2. IGP Parameters 804 This document requests additional IANA registries in an IANA managed 805 registry "Interior Gateway Protocol (IGP) Parameters" for various PPR 806 TLV parameters. The registration procedure is based on the "Expert 807 Review" as defined in [RFC8126]. The suggested registry names are: 809 o "PPR-Type" - Types are unsigned 8 bit numbers. Values are as 810 defined in Section 3 of this document. 812 o "PPR-Flags" - 1 Octet. Bits as described in Section 3 of this 813 document. 815 o "PPR-ID Type" - Types are unsigned 8 bit numbers. Values are as 816 defined in Section 3.2 of this document. 818 o "PPR-ID Flags" - 1 Octet. Bits as described in Section 3.2 of 819 this document. 821 o "PPR-PDE Type" - Types are unsigned 8 bit numbers. Values are as 822 defined in Section 3.3 of this document. 824 o "PPR-PDE Flags" - 1 Octet. Bits as described in Section 3.3 of 825 this document. 827 o "PDE-ID Type" - Types are unsigned 8 bit numbers. Values are as 828 defined in Section 3.3 of this document. 830 8. Security Considerations 832 Security concerns for IS-IS are addressed in [RFC5304] and [RFC5310]. 833 Further security analysis for the IS-IS protocol is done in [RFC7645] 834 with detailed analysis of various security threats and why [RFC5304] 835 should not be used in the deployments. Advertisement of the 836 additional information defined in this document introduces no new 837 security concerns in IS-IS protocol. However, for extensions related 838 ro SR-MPLS and SRH data planes, those particular data plane security 839 considerations do apply here. 841 9. Contributing Authors 843 The following people contributed substantially to the content of this 844 document and should be considered co-authors. 846 Yingzhen Qu 847 Futurewei 848 2330 Central Expressway 849 Santa Clara 850 CA 95050 851 USA 852 Email: yingzhen.qu@futurewei.com 854 10. References 856 10.1. Normative References 858 [I-D.chunduri-rtgwg-preferred-path-routing] 859 Bryant, S., Chunduri, U., and A. Clemm, "Preferred Path 860 Routing Framework", draft-chunduri-rtgwg-preferred-path- 861 routing-01 (work in progress), October 2021. 863 [ISO.10589.1992] 864 International Organization for Standardization, 865 "Intermediate system to intermediate system intra-domain- 866 routing routine information exchange protocol for use in 867 conjunction with the protocol for providing the 868 connectionless-mode Network Service (ISO 8473)", 869 ISO Standard 10589, 1992. 871 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 872 Requirement Levels", BCP 14, RFC 2119, 873 DOI 10.17487/RFC2119, March 1997, 874 . 876 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 877 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 878 May 2017, . 880 10.2. Informative References 882 [I-D.bryant-rtgwg-plfa] 883 Bryant, S., Chunduri, U., and T. Eckert, "Preferred Path 884 Loop-Free Alternate (pLFA)", draft-bryant-rtgwg-plfa-02 885 (work in progress), June 2021. 887 [I-D.chunduri-dmm-5g-mobility-with-ppr] 888 Chunduri, U., Contreras, L. M., Bhaskaran, S., Tantsura, 889 J., and P. Muley, "Transport aware 5G mobility with PPR", 890 draft-chunduri-dmm-5g-mobility-with-ppr-00 (work in 891 progress), November 2020. 893 [I-D.ietf-dmm-tn-aware-mobility] 894 Chunduri, U., Kaippallimalil, J., Bhaskaran, S., Tantsura, 895 J., and P. Muley, "Mobility aware Transport Network 896 Slicing for 5G", draft-ietf-dmm-tn-aware-mobility-02 (work 897 in progress), October 2021. 899 [I-D.ietf-isis-encapsulation-cap] 900 Xu, X., Decraene, B., Raszuk, R., Chunduri, U., Contreras, 901 L. M., and L. Jalil, "Advertising Tunnelling Capability in 902 IS-IS", draft-ietf-isis-encapsulation-cap-01 (work in 903 progress), April 2017. 905 [I-D.ietf-isis-mpls-elc] 906 Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S., 907 and M. Bocci, "Signaling Entropy Label Capability and 908 Entropy Readable Label Depth Using IS-IS", draft-ietf- 909 isis-mpls-elc-13 (work in progress), May 2020. 911 [I-D.ietf-lsr-isis-srv6-extensions] 912 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 913 Z. Hu, "IS-IS Extensions to Support Segment Routing over 914 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-18 915 (work in progress), October 2021. 917 [I-D.ietf-mpls-sfc] 918 Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based 919 Forwarding Plane for Service Function Chaining", draft- 920 ietf-mpls-sfc-07 (work in progress), March 2019. 922 [I-D.ietf-teas-enhanced-vpn] 923 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 924 Framework for Enhanced Virtual Private Network (VPN+) 925 Services", draft-ietf-teas-enhanced-vpn-09 (work in 926 progress), October 2021. 928 [I-D.xuclad-spring-sr-service-chaining] 929 Clad, F., Xu, X., Filsfils, C., Bernier, D., Li, C., 930 Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and 931 S. Salsano, "Segment Routing for Service Chaining", draft- 932 xuclad-spring-sr-service-chaining-01 (work in progress), 933 March 2018. 935 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 936 Topology (MT) Routing in Intermediate System to 937 Intermediate Systems (IS-ISs)", RFC 5120, 938 DOI 10.17487/RFC5120, February 2008, 939 . 941 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 942 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 943 2008, . 945 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 946 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 947 2008, . 949 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 950 DOI 10.17487/RFC5308, October 2008, 951 . 953 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 954 and M. Fanto, "IS-IS Generic Cryptographic 955 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 956 2009, . 958 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 959 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 960 DOI 10.17487/RFC5440, March 2009, 961 . 963 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 964 and A. Bierman, Ed., "Network Configuration Protocol 965 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 966 . 968 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 969 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 970 RFC 6790, DOI 10.17487/RFC6790, November 2012, 971 . 973 [RFC7645] Chunduri, U., Tian, A., and W. Lu, "The Keying and 974 Authentication for Routing Protocol (KARP) IS-IS Security 975 Analysis", RFC 7645, DOI 10.17487/RFC7645, September 2015, 976 . 978 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 979 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 980 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 981 March 2016, . 983 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 984 Writing an IANA Considerations Section in RFCs", BCP 26, 985 RFC 8126, DOI 10.17487/RFC8126, June 2017, 986 . 988 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 989 Decraene, B., Litkowski, S., and R. Shakir, "Segment 990 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 991 July 2018, . 993 [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 994 "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, 995 DOI 10.17487/RFC8491, November 2018, 996 . 998 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 999 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 1000 Extensions for Segment Routing", RFC 8667, 1001 DOI 10.17487/RFC8667, December 2019, 1002 . 1004 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 1005 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1006 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 1007 . 1009 Appendix A. Appendix 1011 A.1. Challenges with Increased SID Depth 1013 SR label stacks carried in the packet header create challenges in the 1014 design and deployment of networks and networking equipment. 1015 Following examples illustrates the need for increased SID depth in 1016 various use cases: 1018 (a). Consider the following network where SR-MPLS data plane is in 1019 use and with same SRGB (5000-6000) on all nodes i.e., A1 to A11 and 1020 B1 to B7 for illustration: 1022 SID:10 SID:20 SID:30 SID:40 SID:50 SID:300(Ax) SID:60 SID:70 1023 A1--------A2-------A3-------A4-------A5===============A6-- ----------A7 1024 | \ / \5 5/ \ SID:310(Ay) \ / 1025 | 5 \ 10 10/ +-A10-+ \ \10 10/ 1026 | \ SID:80 / |SID:100 \ \ / 1027 A11 SID:111 \A8-----A9/ | \ 40 \ / 1028 | / SID:90 \ +-----+ +---+ \ / 1029 | 5 /10 \10 5 \ \ \ / 1030 | /SID:125(B2x) \ \ \ \/ 1031 B1-------B2==============B3----B4------B5-------=B6----------B7 1032 SID:127(B2y) 1033 SID:110 SID:120 SID:130 SID:140 SID:150 SID:160 SID:170 1035 === = Path with Parallel Adjacencies and ADJ-SIDs 1036 --- = Shortest Path Nodal SID 1038 Figure 6: SR-MPLS Network 1040 Global ADJ-SIDs are provisioned between A5-A6 and B2-B3 (with 1041 parallel adjecencies). All other SIDs shown are nodal SID 1042 indices. 1044 All metrics of the links are set to 1, unless marked otherwise. 1046 Shortest Path from A1 to A7: A2-A3-A4-A5-A6-A7 1048 Path-x: From A1 to A7 - A2-A8-B2-B2x-A9-A10-Ax-A7; Pushed Label 1049 Stack @A1: 5020:5080:5120:5125:5090:5100:5300:5070 (where B2x is a 1050 local ADJ-SID and Ax is a global ADJ-SID). 1052 In this example, the traffic engineered path is represented with a 1053 combination of Adjacency and Node SIDs with a stack of 8 labels. 1054 However, this value can be larger, if the use of entropy label 1055 [RFC6790] is desired and based on the Readable Label Depth 1056 (Appendix A.2) capabilities of each node and additional labels 1057 required to insert ELI/EL at appropriate places. 1059 Though above network is shown with SR-MPLS data plane, if the 1060 network were to use SRv6 data plane, path size would be increased 1061 even more because of the size of the IPv6 SID (16 bytes) in SRH. 1063 (b). Apart from the TE case above, when deploying 1064 [I-D.ietf-mpls-sfc] or [I-D.xuclad-spring-sr-service-chaining], with 1065 the inclusion of services, or non-topological segments on the label 1066 stack, can also make the size of the stack much larger. 1068 Overall the additional path overhead in various SR deployments may 1069 cause the following issues: 1071 a. HW Capabilities: Not all nodes in the path can support the 1072 ability to push or read label stack (with additional non- 1073 topological and special labels) needed to satisfy user/operator 1074 requirements. Alternate paths, which meet these user/operator 1075 requirements may not be available. 1077 b. Line Rate: Potential performance issues in deployments, which use 1078 data plane with extension header as both size of the SIDs in the 1079 extension header and the fixed extension header size itself needs 1080 to be factored by the hardware. 1082 c. MTU: Larger SID stacks on the data packet can cause potential 1083 MTU/fragmentation issues (SRH). 1085 d. Header Tax: Some deployments, such as 5G, require minimal packet 1086 overhead in order to conserve network resources. Carrying 40 or 1087 50 octets of data in a packet with hundreds of octet of header 1088 would be an unacceptable use of available bandwidth. 1090 With the solution proposed in this document, for Path-x in Figure 6 1091 above, SID stack would be reduced from 8 SIDs to a single SID witout 1092 any additional overhead. 1094 A.2. Mitigation with MSD 1096 The number of SIDs in the stack a node can impose is referred as 1097 Maximum SID Depth (MSD) capability [RFC8491], which must be taken 1098 into consideration when computing a path to transport a data packet 1099 in a network implementing segment routing. [I-D.ietf-isis-mpls-elc] 1100 defines another MSD type, Readable Label Depth (RLD) that is used by 1101 a head-end to insert Entropy Label pair (ELI/EL) at appropriate 1102 depth, so it could be read by transit nodes. There are situations 1103 where the source routed path can be excessive as path represented by 1104 SR SIDs need to describe all the nodes and ELI/EL based on the 1105 readability of the nodes in that path. Registries setforth in 1106 [RFC8491] applicable for MPLS data plane and for IPv6 data plane with 1107 SRH. 1109 MSDs (and RLD type) capabilities advertisement help mitigate the 1110 problem for a central entity to create the right source routed path 1111 per application/operator requirements. However the availability of 1112 actual paths meeting these requirements are still limited by the 1113 underlying hardware and their MSD capabilities in the data path. 1115 Authors' Addresses 1117 Uma Chunduri 1118 Intel Corporation 1120 Email: umac.ietf@gmail.com 1122 Richard Li 1123 Futurewei 1124 2330 Central Expressway 1125 Santa Clara, CA 95050 1126 USA 1128 Email: richard.li@futurewei.com 1130 Russ White 1131 Juniper Networks 1132 Oak Island, NC 28465 1133 USA 1135 Email: russ@riw.us 1137 Luis M. Contreras 1138 Telefonica 1139 Sur-3 building, 3rd floor 1140 Madrid 28050 1141 Spain 1143 Email: luismiguel.contrerasmurillo@telefonica.com 1145 Jeff Tantsura 1146 Microsoft 1148 Email: jefftanti.ietf@gmail.com 1150 Yingzhen Qu 1151 Futurewei 1152 2330 Central Expressway 1153 Santa Clara, CA 95050 1154 USA 1156 Email: yingzhen.qu@futurewei.com