idnits 2.17.1 draft-chunduri-lsr-isis-preferred-path-routing-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 : ---------------------------------------------------------------------------- == 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 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 (September 28, 2020) is 1305 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 3 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 R. Li 4 Intended status: Standards Track Futurewei 5 Expires: April 1, 2021 R. White 6 Juniper Networks 7 J. Tantsura 8 Apstra Inc. 9 L. Contreras 10 Telefonica 11 Y. Qu 12 Futurewei 13 September 28, 2020 15 Preferred Path Routing (PPR) in IS-IS 16 draft-chunduri-lsr-isis-preferred-path-routing-06 18 Abstract 20 This document specifies Preferred Path Routing (PPR), an extensible 21 method of providing path based dynamic routing for a number of packet 22 types including IPv4, IPv6 and MPLS. PPR uses a simple encapsulation 23 to add the path identity to the packet. PPR can also be used to 24 mitigate the MTU and data plane processing issues that may result 25 from Segment Routing (SR) packet overhead; and also supports further 26 extensions along the paths. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC2119 [RFC2119], 33 RFC8174 [RFC8174] when, and only when they appear in all capitals, as 34 shown here. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on April 1, 2021. 53 Copyright Notice 55 Copyright (c) 2020 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Preferred Path Routing (PPR) . . . . . . . . . . . . . . . . 4 73 2.1. PPR-ID and Data Plane Extensibility . . . . . . . . . . . 4 74 2.2. PPR Path Description . . . . . . . . . . . . . . . . . . 4 75 2.3. ECMP Considerations . . . . . . . . . . . . . . . . . . . 5 76 2.4. Scalability and PPR Graphs . . . . . . . . . . . . . . . 5 77 3. PPR Related TLVs . . . . . . . . . . . . . . . . . . . . . . 5 78 3.1. PPR-Prefix Sub-TLV . . . . . . . . . . . . . . . . . . . 8 79 3.2. PPR-ID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 8 80 3.3. PPR-PDE Sub-TLV . . . . . . . . . . . . . . . . . . . . . 10 81 3.4. PPR-Attributes Sub-TLV . . . . . . . . . . . . . . . . . 13 82 4. PPR Processing Procedure Example . . . . . . . . . . . . . . 13 83 4.1. PPR TLV Processing . . . . . . . . . . . . . . . . . . . 15 84 4.2. Path Fragments . . . . . . . . . . . . . . . . . . . . . 16 85 5. PPR Data Plane aspects . . . . . . . . . . . . . . . . . . . 16 86 5.1. SR-MPLS with PPR . . . . . . . . . . . . . . . . . . . . 16 87 5.2. PPR Native IP Data Planes . . . . . . . . . . . . . . . . 17 88 5.3. SRv6 with PPR . . . . . . . . . . . . . . . . . . . . . . 17 89 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 90 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 91 7.1. PPR Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . 18 92 7.2. IGP Parameters . . . . . . . . . . . . . . . . . . . . . 19 93 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 94 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 95 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 96 9.2. Informative References . . . . . . . . . . . . . . . . . 20 97 Appendix A. Appendix . . . . . . . . . . . . . . . . . . . . . . 22 98 A.1. Challenges with Increased SID Depth . . . . . . . . . . . 22 99 A.2. Mitigation with MSD . . . . . . . . . . . . . . . . . . . 24 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 102 1. Introduction 104 In a network implementing Segment Routing (SR), packets are steered 105 through the network using Segment Identifiers (SIDs) carried in the 106 packet header. Each SID uniquely identifies a segment as defined in 107 [RFC8402] . SR capabilities are defined for MPLS and IPv6 data planes 108 called SR-MPLS and SRv6 respectively. Appendix A.1 and Appendix A.2 109 describe performance, hardware capabilities and various associated 110 issues which may result in SR deployments. 112 The above motivate the proposed solution, Preferred Path Routing 113 (PPR). In brief, PPR involves, associating path descriptions to IS- 114 IS advertised prefixes, mapping those to a data-plane identifier and 115 specifying a mechanism to route packets with the abstracted 116 identifier (PPR-ID), as opposed to individual segments on the packet. 117 This is specified in detail in Section 2 and Section 3. 119 1.1. Acronyms 121 EL - Entropy Label 123 ELI - Entropy Label Indicator 125 LSP - IS-IS Link State PDU 127 MPLS - Multi Protocol Label Switching 129 MSD - Maximum SID Depth 131 MTU - Maximum Transferrable Unit 133 NH - Next-Hop 135 PPR - Preferred Path Routing/Route 137 PPR-ID - Preferred Path Route Identifier, a data plane identifier 139 SID - Segment Identifier 141 SPF - Shortest Path First 143 SR-MPLS - Segment Routing with MPLS data plane 144 SRH - Segment Routing Header - IPv6 routing Extension header 146 SRv6 - Segment Routing with IPv6 data plane with SRH 148 TE - Traffic Engineering 150 2. Preferred Path Routing (PPR) 152 PPR mitigates the issues described in Appendix A.1, while continuing 153 to allow the direction of traffic along an engineered path through 154 the network by replacing the label stack with a PPR-ID. The PPR-ID 155 can either be a single label or a native destination address. To 156 facilitate the use of a single label to describe an entire path, a 157 new TLV is added to IS-IS, as described below in Section 3. 159 A PPR could be an SR path, a traffic engineered path computed based 160 on some constraints, an explicitly provisioned Fast Re-Route (FRR) 161 path or a service chained path. A PPR can be signaled by any node, 162 computed by a central controller, or manually configured by an 163 operator. PPR extends the source routing and path steering 164 capabilities to native IP (IPv4 and IPv6) data planes without 165 hardware upgrades; see Section 5. 167 2.1. PPR-ID and Data Plane Extensibility 169 The PPR-ID describes a path through the network. A data plane type 170 and corresponding data plane identifier as specified in Section 3.2 171 is mapped to PPR-ID to allow data plane extensibility. 173 For SR-MPLS, PPR-ID is mapped to an MPLS Label/SID and for SRv6, this 174 is mapped to an IPv6-SID. For native IP data planes, this is mapped 175 to either IPv4 or IPv6 address/prefix. 177 2.2. PPR Path Description 179 The path identified by the PPR-ID is described as a set of Path 180 Description Elements (PDEs), each of which represents a segment of 181 the path. Each node determines its location in the path as 182 described, and forwards to the next segment/hop or label of the path 183 description (see the Forwarding Procedure Example later in this 184 document). 186 These PPR-PDEs as defined in Section 3.3, like SR SIDs, can represent 187 topological elements like links/nodes, backup nodes, as well as non- 188 topological elements such as a service, function, or context on a 189 particular node. 191 A PPR path can be described as a Strict-PPR or a Loose-PPR. In a 192 Strict-PPR all nodes/links on the path are described with SR SIDs for 193 SR data planes or IPv4/IPV6 addresses for native IP data planes. In 194 a Loose-PPR only some of the nodes/links from source to destination 195 are described. More specifics and restrictions around Strict/Loose 196 PPRs are described in respective data planes in Section 5. Each PDE 197 is described as either an MPLS label towards the Next-Hop (NH) in 198 MPLS enabled networks, or as an IP NH, in the case of either 199 "plain"/"native" IP or SRv6 enabled networks. A PPR path is related 200 to a set of PDEs using the TLVs as specified in Section 3. 202 2.3. ECMP Considerations 204 PPR inherently supports Equal Cost Multi Path (ECMP) for both strict 205 and loose paths. If a path is described using nodes, would have ECMP 206 NHs established for PPR-ID along the path. However, one can avoid 207 ECMP on any segment of the path by pinning the path using link 208 identifier to the next segment. 210 2.4. Scalability and PPR Graphs 212 In a network of N nodes O(N^2) total (unidirectional) paths are 213 necessary to establish any-to-any connectivity, and multiple (k) such 214 path sets may be desirable if multiple path policies are to be 215 supported (lowest latency, highest throughput etc.). 217 In many solutions and topologies, N may be small enough and/or only a 218 small set of paths need to be preferred paths, for example for high 219 value traffic (DetNet, some of the defined 5G slices), and then the 220 technology specified in this document can support these deployments. 222 However, to address the scale needed when a larger number of PPR 223 paths are required, the PPR TREE structure can be used [I-D.draft-ce- 224 ppr-graph-00]. Each PPR Tree uses one label/SID and defines paths 225 from any set of nodes to one destination, thus reduces the number of 226 entries needed in SRGB at each node (for SR-MPLS data plane 227 Section 5.1). These paths form a tree rooted in the destination. In 228 other word, PPR Tree identifiers are destination identifiers and PPR 229 Treed are path engineered destination routes (like IP routes) and it 230 scaling simplifies to linear in N i.e., O(k*N). 232 3. PPR Related TLVs 234 This section describes the encoding of PPR TLV. This TLV can be seen 235 as having 4 logical sections viz, encoding of the PPR-Prefix (IS-IS 236 Prefix), encoding of PPR-ID, encoding of path description with an 237 ordered PDE Sub-TLVs and a set of optional PPR attribute Sub-TLVs, 238 which can be used to describe one or more parameters of the path. 240 Multiple instances of this TLV MAY be advertised in IS-IS LSPs with 241 different PPR-ID Type (data plane) and with corresponding PDE Sub- 242 TLVS. The PPR TLV has Type TBD (suggested value xxx), and has the 243 following format: 245 0 1 2 3 246 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 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Type | Length | PPR-Flags | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Fragment-ID | MT-ID | Algorithm | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | PPR-Prefix Sub-TLV (variable size) | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | PPR-ID Sub-TLV (variable size) | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | PPR-PDE Sub-TLVs (variable) | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | PPR-Attribute Sub-TLVs (variable) | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 Figure 1: PPR TLV Format 263 o Type: 155 (Suggested Value, TBD IANA) from IS-IS top level TLV 264 registry. 266 o Length: Total length of the value field in bytes. 268 o PPR-Flags: 2 Octet bit-field of flags for this TLV; described 269 below. 271 o Fragment-ID: This is an 8-bit Identifier value (0-255) of the TLV 272 fragment. If fragments are not needed to represent the complete 273 path, 'U' bit MUST be set and this value MUST be set to 0. 275 o MT-ID: The multi-topology identifier defined in [RFC5120]; the 4 276 most significant bits MUST be set to 0 on transmit and ignored on 277 receive. The remaining 12-bit field contains the MT-ID. 279 o Algorithm: 1 octet value represents the route computation 280 algorithm. Algorithm registry is as defined in 281 [I-D.ietf-isis-segment-routing-extensions]. Computation towards 282 PPR-ID (Section 3.2) happens per MT-ID/Algorithm pair. 284 o PPR-Prefix: A variable size Sub-TLV representing the destination 285 of the path being described. This is defined in Section 3.1. 287 o PPR-ID: A variable size Sub-TLV representing the data plane or 288 forwarding identifier of the PPR. Defined in Section 3.2. 290 o PPR-PDEs: Variable number of ordered PDE Sub-TLVs which represents 291 the path. This is defined in Section 3.3. 293 o PPR-Attributes: Variable number of PPR-Attribute Sub-TLVs which 294 represent the path attributes. These are defined in Section 3.4. 296 The Flags field has the following flag bits defined: 298 PPR TLV Flags Format 300 0 1 2 3 4 5 6 7 15 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 |F|D|A|U|Reserved | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 1. F: Flood bit. If set, the PPR TLV MUST be flooded across the 306 entire routing domain. If the F bit is not set, the PPR TLV MUST 307 NOT be leaked between IS-IS levels. This bit MUST NOT be altered 308 during the TLV leaking 310 2. D: Down Bit. When the PPR TLV is leaked from IS-IS level-2 to 311 level-1, the D bit MUST be set. Otherwise, this bit MUST be 312 clear. PPR TLVs with the D bit set MUST NOT be leaked from 313 level-1 to level-2. This is to prevent TLV looping across 314 levels. 316 3. A: Attach bit. The originator of the PPR TLV MUST set the A bit 317 in order to signal that the prefix and PPR-ID advertised in the 318 PPR TLV are directly connected to the originators. If this bit 319 is not set, this allows any other node in the network to 320 advertise this TLV on behalf of the originating node of the PPR- 321 Prefix. If PPR TLV is leaked to other areas/levels the A-flag 322 MUST be cleared. In case if the originating node of the prefix 323 must be disambiguated for any reason including, if it is a Multi 324 Homed Prefix (MHP) or leaked to a different IS-IS level or 325 because [RFC7794] X-Flag is set, then PPR-Attribute Sub-TLV 326 Source Router ID SHOULD be included. 328 4. U: Ultimate fragment bit. bit MUST be set if a path has only one 329 fragment or if it is the last Fragment of the path. PPR-ID value 330 for all fragments of the same path MUST be same. 332 5. Reserved: For future use; MUST be set to 0 on transmit and 333 ignored on receive. 335 PPR path description for each IS-IS level is computed and given to 336 one of the nodes for L1 and L2 respectively. Similarly path 337 information when crossing the level boundaries MUST be relevant to 338 the destination level. If there is no path information available for 339 the destination level PPR TLV MUST NOT be leaked regardless of F and 340 D bits as defined above. 342 The following Sub-TLVs draw from a new registry for Sub-TLV numbers 343 as specified in Section 7.1 and Section 7.2. 345 3.1. PPR-Prefix Sub-TLV 347 The structure of PPR-Prefix is: 349 0 1 2 3 350 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 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Type | Length | Prefix Length | Mask Length | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 // IS-IS Prefix (variable) // 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 Figure 2: PPR-Prefix Sub-TLV Format 359 o Type: 1 (IANA to assign from Sub-TLV registry described above). 361 o Length: Total length of the value field in bytes. 363 o Prefix Length: The length of the IS-IS Prefix being encoded in 364 bytes. For IPv4 it MUST be 4 and IPv6 it MUST be 16 bytes. 366 o Mask Length: The length of the prefix in bits. Only the most 367 significant octets of the Prefix are encoded. 369 o IS-IS Prefix: The IS-IS prefix at the tail-end of the advertised 370 PPR. This corresponds to a routable prefix of the originating 371 node and it MAY have one of the [RFC7794] flags set (X-Flag/R- 372 Flag/N-Flag) in the IS-IS reachability TLVs. Length of this field 373 MUST be as per "Prefix Length". Encoding is same as TLV 135 374 [RFC5305] and TLV 236 [RFC5308] or MT-Capable [RFC5120] IPv4 (TLV 375 235) and IPv6 Prefixes (TLV 237) respectively. 377 3.2. PPR-ID Sub-TLV 379 This is the actual data plane identifier in the packet header and 380 could be of any data plane as defined in PPR-ID Type field. Both 381 PPR-Prefix and PPR-ID belongs to a same node in the network. 383 0 1 2 3 384 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 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Type | Length |PPR-ID Flags | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | PPR-ID Type | PPR-ID Length |PPR-ID Mask Len| 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 // PPR-ID (variable size) // 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 Figure 3: PPR-ID Sub-TLV Format 395 o Type: 2 (IANA to assign from Sub-TLV registry described above). 397 o Length: Total length of the value field in bytes. 399 o PPR-ID Flags: 2 Octet field for PPR-ID flags: 401 PPR-ID Flags Format 403 0 1 2 3 4 5 6 7.. 15 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Reserved | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 Reserved: For future use; MUST be set to 0 on transmit and 409 ignored on receive. 411 o PPR-ID Type: Data plane type of PPR-ID. This is a new registry 412 (TBD IANA - Suggested values as below) for this Sub-TLV and the 413 defined types are as follows: 415 Type: 1 SR-MPLS SID/Label 417 Type: 2 Native IPv4 Address/Prefix 419 Type: 3 Native IPv6 Address/Prefix 421 Type: 4 IPv6 SID in SRv6 with SRH 423 o PPR-ID Length: Length of the PPR-ID field in octets and this 424 depends on the PPR-ID type. 426 o PPR-ID Mask Len: It is applicable for only for PPR-ID Type 2, 3 427 and 4. For Type 1 this value MUST be set to zero. It contains 428 the length of the PPR-ID Prefix in bits. Only the most 429 significant octets of the Prefix are encoded. This is needed, if 430 PPR-ID followed is an IPv4/IPv6 Prefix instead of 4/16 octet 431 Address respectively. 433 o PPR-ID: This is the Preferred Path forwarding identifier that 434 would be on the data packet. The value of this field is variable 435 and it depends on the PPR-ID Type - for Type 1, this is encoded as 436 SR-MPLS SID/Label. For Type 2 this is a 4 byte IPv4 address. For 437 Type 3 this is a 16 byte IPv6 address. For Type 2 and Type 3 438 encoding is similar to "IS-IS Prefix" as specified in Section 3.1. 439 For Type 4, this is encoded as 16 byte SRv6 SID. 441 For PPR-ID Type 2, 3 or 4, PPR-ID MUST NOT be advertised as a 442 routable prefix in TLV 135, TLV 235, TLV 236 and TLV 237. PPR-ID 443 MUST belong to the node, from where the PPR-Prefix (Section 3.1) is 444 advertised. 446 3.3. PPR-PDE Sub-TLV 448 This Sub-TLV represents the PPR Path Description Element (PDE). PPR- 449 PDEs are used to describe the path in the form of set of contiguous 450 and ordered Sub-TLVs, where first Sub-TLV represents (the top of the 451 stack in MPLS data plane or) first node/segment of the path. These 452 set of ordered Sub-TLVs can have both topological elements and non- 453 topological elements (e.g., service segments). 455 0 1 2 3 456 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 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Type | Length | PPR-PDE Type | PDE-ID Type | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | PDE-ID Length | PPR-PDE Flags | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 // PDE-ID Value (variable size) // 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 |Sub-TLV Length | PPR-PDE Sub-TLVs (variable) | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 Figure 4: PPR-PDE Sub-TLV Format 469 o Type: 3 (See IANA for suggested value) from IS-IS PPR TLV 470 Section 3 Sub-TLV registry. 472 o Length: Total length of the value field in bytes. 474 o PPR-PDE Type: A new registry (TBD IANA) for this Sub-TLV and the 475 defined types are as follows: 477 Type: 1 Topological 478 Type: 2 Non-Topological 480 o PDE-ID Type: 1 Octet PDE-forwarding IDentifier Type. A new 481 registry (Suggested Values as listed, IANA TBD) for this Sub-TLV 482 and the defined types and corresponding PDE-ID Length, PDE-ID 483 Value are as follows: 485 Type 0: This value MUST be set only when PPR-PDE Type is Non- 486 Topological. PDE-ID Length indicates the length of the PDE-ID 487 Value field in bytes. For this type, PDE-ID value represents a 488 service/function. This information is provisioned on the 489 immediate topological PDE preceding to this PDE based on the 'E' 490 bit. 492 Type 1: SID/Label type as defined in 493 [I-D.ietf-isis-segment-routing-extensions]. PDE-ID Length and 494 PDE-ID Value fields are per Section 2.3 of the referenced 495 document. 497 Type 2: SR-MPLS Prefix SID. PDE-ID Length and PDE-ID Value are 498 same as Type 1. 500 Type 3: SR-MPLS Adjacency SID. PDE-ID Length and PDE-ID Value 501 are same as Type 1. 503 Type 4: IPv4 Node Loopback Address. PDE-ID Length 4 bytes and 504 PDE-ID Value is full 4 bytes IPv4 address encoded as specified 505 in "4-octet IPv4 address" of Sub-TLV 6/TLV 22 in [RFC5305]. 507 Type 5: IPv4 Interface Address. PDE-ID Length is 4 bytes and 508 PDE-ID Value is full 4 bytes IPv4 address encoded as specified 509 in "4-octet IPv4 address" of Sub-TLV 6/TLV 22 in [RFC5305]. 510 This PDE-ID in the path description represents the egress 511 interface of the path segment and correponding adjacency is set 512 as nexthop for the PPR-ID. 514 Type 6: IPv6 Node Loopback Address. PDE-ID Length and PDE-ID 515 Value are encoded as specified in "Prefix Len" and "prefix" 516 portion of TLV 236 in [RFC5308] respectively. 518 Type 7: IPv6 Interface Address. PDE-ID Length is 16 bytes and 519 PDE-ID Value is full 16 bytes IPv6 address encoded as specified 520 in "Interface Address 1" portion of TLV 232 in [RFC5308]. This 521 PDE-ID in the path description represents the egress interface 522 of the path segment and correponding adjacency is set as nexthop 523 for the PPR-ID. 525 Type 8: SRv6 Node SID as defined in 526 [I-D.bashandy-isis-srv6-extensions]. PDE-ID Length and PDE-ID 527 Value are as defined in SRv6 SID from the referenced draft. 529 Type 9: SRv6 Adjacency-SID. PDE-ID Length and PDE-ID Values are 530 similar to SRv6 Node SID above. 532 o PPR-PDE Flags: 2 Octet bit-field of flags; described below: 534 PPR-PDE Flags Format 536 0 1 2 3 4 5 6 7 .. 15 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 |L|N|E| Reserved | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 L: Loose Bit. Indicates the type of next "Topological PDE-ID" in 542 the path description. This bit MUST be set for only Node/Prefix 543 PDE type. If this flag is unset, the next Topological PDE is 544 Strict Type. 546 N: Node Bit. By default this bit MUST be unset. This bit MUST 547 be set only for PPR-PDE Type is 1 i.e., Topological and this PDE 548 represents the node, where PPR-Prefix (Section 3.1) belongs to 549 (if there is no further PDE specific Sub-TLVs to override PPR- 550 Prefix and PPR-ID values). 552 E: Egress Bit. By default this bit MUST be unset. This bit MUST 553 be set only for PPR-PDE Type is 2 i.e., Non-Topological and the 554 service needs to be applied on the egress side of the 555 topological PDE preceding this PDE. 557 Reserved: Reserved bits for future use. Reserved bits MUST be 558 reset on transmission and ignored on receive. 560 o Sub-TLV Length: 1 byte length of all Sub-TLVs followed. It MUST 561 be set to 0 if no further Sub-TLVs are present. 563 o PPR-PDE Sub-TLVs: These have 1 octet type, 1 octet length and 564 value field is defined per the type field. Types are as defined 565 in PPR-TLV Sub-TLVs (Section 7), encoded further as sub-sub-TLVs 566 of PPR-PDE and the length field represents the total length of the 567 value field in bytes. 569 IS-IS System-ID Sub-TLV: Type 4 (IANA TBD), Length Total length 570 of value field in bytes, Value: IS-IS System-ID of length "ID 571 Length" as defined in [ISO.10589.1992]. This Sub-TLV MUST NOT 572 be present, if the PPR-PDE Type is not Topological. Though the 573 type for this come from the PPR Sub-TLV registry, here this is a 574 sub-sub-TLV and is part of PPR-ID/PPR-PDE Sub-TLV. 576 3.4. PPR-Attributes Sub-TLV 578 PPR-Attribute Sub-TLVs describe the attributes of the path. This 579 document defines the following optional PPR-Attribute Sub-TLVs: 581 o Type 5 (Suggested Value - IANA TBD): PPR-Prefix originating node's 582 IPv4 Router ID Sub-TLV. Length and Value field are as specified 583 in [RFC7794]. 585 o Type 6 (Suggested Value - IANA TBD): PPR-Prefix originating node's 586 IPv6 Router ID Sub-TLV. Length and Value field are as specified 587 in [RFC7794]. 589 o Type 7 (Suggested Value - IANA TBD): PPR-Metric Sub-TLV. Length 4 590 bytes, and Value is metric of this path represented through the 591 PPR-ID. Different nodes can advertise the same PPR-ID for the 592 same Prefix with a different set of PPR-PDE Sub-TLVs and the 593 receiving node MUST consider the lowest metric value. 595 4. PPR Processing Procedure Example 597 As specified in Section 2, a PPR can be a TE path, locally 598 provisioned by the operator or by a controller. Consider the 599 following IS-IS network to describe the operation of PPR TLV as 600 defined in Section 3: 602 1 603 _______ 604 / 1 \ 605 +---R2-------R3---+ 606 / \_______/ \ 607 / 1 \ 608 1 / \ 1 609 / 1__R13__1 \ 610 / / \ \ 611 R1------R6 R7-----------R4 612 \ 2 \__R14__/ 2 /\ 613 \ 2 2 / \ 614 3 \ / 3 \1 615 \ 4 / \ 616 +----R8------R9-----R10------R12 617 \ 1 / 618 1 \ / 1 619 +----R11---+ 621 Figure 5: IS-IS Network 623 In the (Figure 5), consider node R1 as an ingress node, or a head-end 624 node, and the node R4 may be an egress node or another head-end node. 625 The numbers shown on links between nodes indicate the bi-directional 626 IS-IS metric as provisioned. R1 may be configured to receive TE 627 source routed path information from a central entity (PCE [RFC5440], 628 Netconf [RFC6241] or a Controller) that comprises of PPR information 629 which relates to sources that are attached to R1. It is also 630 possible to have a PPR provisioned locally by the operator for non-TE 631 needs (e.g. FRR or for chaining certain services). 633 The PPR TLV (as specified in Section 3) is encoded as an ordered list 634 of PPR-PDEs from source to a destination node in the network and is 635 represented with a PPR-ID (Section 3.2). The PPR TLV includes PPR- 636 PDE Sub-TLVs Section 3.3, which represent both topological and non- 637 topological elements and specifies the actual path towards a PPR- 638 Prefix at R4. 640 o The shortest path towards R4 from R1 are through the following 641 sequence of nodes: R1-R2-R3-R4 based on the provisioned metrics. 643 o The central entity can define a few PPRs from R1 to R4 that 644 deviate from the shortest path based on other network 645 characteristic requirements as requested by an application or 646 service. For example, the network characteristics or performance 647 requirements may include bandwidth, jitter, latency, throughput, 648 error rate, etc. 650 o A first PPR may be identified by PPR-ID = 1 (value) and may 651 include the path of R1-R6-R7-R4 for a Prefix advertised by R4. 652 This is an example for a Loose-PPR and 'L' bit MUST be set 653 appropriately at Section 3.3. 655 o A second PPR may be identified by PPR-ID = 2 (value) and may 656 include the path of R1-R8-R9-R10-R4. This is an example for a 657 Strict-PPR and 'L' bit MUST be unset appropriately at Section 3.3. 658 Though this example shows PPR with all nodal SIDs, it is possible 659 to have a PPR with combination of node and adjacency SIDs (local 660 or global) or with PPR-PDE Type set to Non-Topological as defined 661 in Section 3.3 elements along with these. 663 4.1. PPR TLV Processing 665 The first topological sub-object or PDE (Section 3.3) relative to the 666 beginning of PPR Path contains the information about the first node 667 (e.g. in SR-MPLS it's the topmost label). The last topological sub- 668 object or PDE contains information about the last node (e.g. in SR- 669 MPLS it's the bottommost label). 671 Each receiving node, determines whether an advertised PPR includes 672 information regarding the receiving node. Before processing any 673 further, validation MUST be done to see if any PPR topological PDE is 674 seen more than once (possible loop), if yes, this PPR TLV MUST be 675 ignored. Processing of PPR TLVs may be done, during the end of the 676 SPF computation (for MTID that is advertised in this TLV) and for 677 each prefix described through PPR TLV. For example, node R9 receives 678 the PPR information, and ignores the PPR-ID=1 (Section 4) because 679 this PPR TLV does not include node R9 in the path description/ordered 680 PPR-PDE list. 682 However, node R9 may determine that the second PPR identified by PPR- 683 ID = 2 does include the node R9 in its PDE list. Therefore, node R9 684 updates the local forwarding database to include an entry for the 685 destination address that R4 indicates, so that when a data packet 686 comprising a PPR-ID of 2 is received, forward the data packet to node 687 R10 instead of R11. This is done, even though from R9 the shortest 688 path to reach R4 via R11 (Cost 3: R9-R11-R12-R4) it chooses the NH to 689 R10 to reach R4 as specified in the PPR path description. Same 690 process happens to all nodes or all topological PDEs as described in 691 the PPR TLV. 693 In summary, the receiving node checks first, if this node is on the 694 path by checking the node's topological elements (with PPR-PDE Type 695 set to Topological) in the path list. If yes, it adds/adjusts the 696 PPR-ID's shortest path NH towards the next topological PDE in the 697 PPR's Path. 699 4.2. Path Fragments 701 A complete PPR path may not fit into maximum allowable size of the 702 IS-IS TLV. To overcome this a 7 bit Fragment-ID field is defined in 703 Section 3 . With this, a single PPR path is represented via one or 704 more fragmented PPR path TLVs, with all having the same PPR-ID. Each 705 fragment carries the PPR-ID as well as a numeric Fragment-ID from 0 706 to (N-1), when N fragments are needed to describe the PPR Graph 707 (where N>1). In this case Fragment (N-1) MUST set the 'U' bit (PPR- 708 Flags) to indicate it is the last fragment. If Fragment-ID is non 709 zero in the TLV, then it MUST not carry PPR-Prefix Sub-TLV. The 710 optional PPR Attribute Sub-TLVs which describe the path overall MUST 711 be included in the last fragment only (i.e., when the 'U' bit is 712 set). 714 5. PPR Data Plane aspects 716 Data plane for PPR-ID is selected by the entity (e.g., a controller, 717 locally provisioned by operator), which selects a particular PPR in 718 the network. Section 3.2 defines various data plane identifier types 719 and a corresponding data plane identifier is selected by the entity 720 which selects the PPR. 722 5.1. SR-MPLS with PPR 724 If PPR-ID Type is 1, then the PPR belongs to SR-MPLS data plane and 725 the complete PPR stack is represented with a unique SR SID/Label and 726 this gets programmed on the data plane of each node, with the 727 appropriate NH computed as specified in Section 4. PPR-ID here is a 728 label/index from the SRGB (like another node SID or global ADJ-SID). 729 PPR path description here is a set of ordered SIDs represented with 730 PPR-PDE (Section 3.2) Sub-TLVs. Non-Topological segments also 731 programmed in the forwarding to enable specific function/service, 732 when the data packet hits with corresponding PPR-ID. 734 Based on 'L' flag in PPR-ID Flags (Section 3.2), for SR-MPLS data 735 plane either 1 label or 2 labels need to be provisioned on individual 736 nodes on the path description. For the example network in Section 4, 737 for PPR-ID=1, which is a loose path, node R6 programs the bottom 738 label as PPR-ID and the top label as the next topological PPR-PDE in 739 the path, which is a node SID of R7. The NH computed at R6 would be 740 the shortest path towards R7 i.e., the interface towards R13. If 'L' 741 flag is unset only PPR-ID is programmed on the data plane with NH set 742 to the shortest path towards next topological PPR-PDE. 744 5.2. PPR Native IP Data Planes 746 If PPR-ID Type is 2 then source routing and packet steering can be 747 done in IPv4 data plane (PPR-IPv4), along the path as described in 748 PPR Path description. This is achieved by setting the destination IP 749 address as PPR-ID, which is an IPv4 address in the data packet 750 (tunneled/encapsulated). There is no data plane change or upgrade 751 needed to support this. 753 Similarly for PPR-ID Type is 3, then source routing and packet 754 steering can be done in IPv6 data plane (PPR-IPv6), along the path as 755 described in PPR Path description. Whatever specified above for IPv4 756 applies here too, except that destination IP address of the data 757 packet is an IPv6 Address (PPR-ID). This doesn't require any IPv6 758 extension headers (EH), if there is no metadata/TLVs need to be 759 carried in the data packet. 761 Based on 'L' flag in PPR-ID Flags (Section 3.2), for PPR-ID Type 2 or 762 3 (Native IPv4 or IPv6 data planes respectively) the packet has to be 763 encapsulated using the capabilities (either dynamically signaled 764 through [I-D.ietf-isis-encapsulation-cap] or statically provisioned 765 on the nodes) of the next loose PDE in the path description. 767 For the example network in Section 4, for PPR-ID=1, which is a loose 768 path, node R6 programs to encapsulate the data packet towards the 769 next loose topological PPR-PDE in the path, which is R7. The NH 770 computed at R6 would be the shortest path towards R7 i.e., the 771 interface towards R13. If 'L' flag is unset only PPR-ID is 772 programmed on the data plane with NH set to the shortest path towards 773 next topological PPR-PDE, with no further encapsulation of the data 774 packet. 776 5.3. SRv6 with PPR 778 If PPR-ID Type is 4, the PPR belongs to SRv6 with SRH data plane and 779 the complete PPR stack is represented with IPv6 SIDs and this gets 780 programmed on the data plane with the appropriate NH computed as 781 specified in Section 4. PPR-ID here is a SRv6 SID. PPR path 782 description here is a set of ordered SID TLVs similar to as specified 783 in Section 5.1. One way PPR-ID would be used in this case is by 784 setting it as the destination IPv6 address and SL field in SRH would 785 be set to 0; however SRH [I-D.ietf-6man-segment-routing-header] can 786 contain any other TLVs and non-topological SIDs as needed. 788 6. Acknowledgements 790 Thanks to Alex Clemm, Lin Han, Toerless Eckert, Asit Chakraborti, 791 Stewart Bryant and Kiran Makhijani for initial discussions on this 792 topic. Thanks to Kevin Smith and Stephen Johnson for various 793 deployment scenarios applicability from ETSI WGs perspective. 794 Authors also acknowledge Alexander Vainshtein for detailed 795 discussions and few suggestions on this topic. 797 Earlier versions of draft-ietf-isis-segment-routing-extensions have a 798 mechanism to advertise EROs through Binding SID. 800 7. IANA Considerations 802 This document requests the following new TLV in IANA IS-IS TLV code- 803 point registry. 805 TLV # Name 806 ----- -------------- 807 155 PPR TLV (Suggested Value, IANA TBD) 809 7.1. PPR Sub-TLVs 811 This document requests IANA to create a new Sub-TLV registry for PPR 812 TLV Section 3 with the following initial entries (suggested values). 813 Though these are defined as Sub-TLVs of PPR TLV, these can be part of 814 another Sub-TLV as a nested sub-sub-TLV (e.g. IS-IS System-ID). 816 Sub-TLV # Sub-TLV Name 817 --------- --------------------------------------------------------- 819 1 PPR-Prefix (Section 3.1) 821 2 PPR-ID (Section 3.2) 823 3 PPR-PDE (Section 3.3) 825 4 IS-IS System-ID (Section 3.3) 827 5 PPR-Prefix Source IPv4 Router ID (Section 3.4) 829 6 PPR-Prefix Source IPv6 Router ID (Section 3.4) 831 7 PPR-Metric (Section 3.4) 833 7.2. IGP Parameters 835 This document requests additional IANA registries in an IANA managed 836 registry "Interior Gateway Protocol (IGP) Parameters" for various PPR 837 TLV parameters. The registration procedure is based on the "Expert 838 Review" as defined in [RFC8126]. The suggested registry names are: 840 o "PPR-Type" - Types are an unsigned 8 bit numbers. Values are as 841 defined in Section 3 of this document. 843 o "PPR-Flags" - 1 Octet. Bits as described in Section 3 of this 844 document. 846 o "PPR-ID Type" - Types are an unsigned 8 bit numbers. Values are 847 as defined in Section 3.2 of this document. 849 o "PPR-ID Flags" - 1 Octet. Bits as described in Section 3.2 of 850 this document. 852 o "PPR-PDE Type" - Types are an unsigned 8 bit numbers. Values are 853 as defined in Section 3.3 of this document. 855 o "PPR-PDE Flags" - 1 Octet. Bits as described in Section 3.3 of 856 this document. 858 o "PDE-ID Type" - Types are an unsigned 8 bit numbers. Values are 859 as defined in Section 3.3 of this document. 861 8. Security Considerations 863 Security concerns for IS-IS are addressed in [RFC5304] and [RFC5310]. 864 Further security analysis for IS-IS protocol is done in [RFC7645] 865 with detailed analysis of various security threats and why [RFC5304] 866 should not be used in the deployments. Advertisement of the 867 additional information defined in this document introduces no new 868 security concerns in IS-IS protocol. However, for extensions related 869 ro SR-MPLS and SRH data planes, those particular data plane security 870 considerations does apply here. 872 9. References 874 9.1. Normative References 876 [ISO.10589.1992] 877 International Organization for Standardization, 878 "Intermediate system to intermediate system intra-domain- 879 routing routine information exchange protocol for use in 880 conjunction with the protocol for providing the 881 connectionless-mode Network Service (ISO 8473)", 882 ISO Standard 10589, 1992. 884 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 885 Requirement Levels", BCP 14, RFC 2119, 886 DOI 10.17487/RFC2119, March 1997, 887 . 889 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 890 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 891 May 2017, . 893 9.2. Informative References 895 [I-D.bashandy-isis-srv6-extensions] 896 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 897 Z. Hu, "IS-IS Extensions to Support Routing over IPv6 898 Dataplane", draft-bashandy-isis-srv6-extensions-05 (work 899 in progress), March 2019. 901 [I-D.ietf-6man-segment-routing-header] 902 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 903 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 904 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 905 progress), October 2019. 907 [I-D.ietf-isis-encapsulation-cap] 908 Xu, X., Decraene, B., Raszuk, R., Chunduri, U., Contreras, 909 L., and L. Jalil, "Advertising Tunnelling Capability in 910 IS-IS", draft-ietf-isis-encapsulation-cap-01 (work in 911 progress), April 2017. 913 [I-D.ietf-isis-mpls-elc] 914 Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S., 915 and M. Bocci, "Signaling Entropy Label Capability and 916 Entropy Readable Label Depth Using IS-IS", draft-ietf- 917 isis-mpls-elc-13 (work in progress), May 2020. 919 [I-D.ietf-isis-segment-routing-extensions] 920 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 921 Gredler, H., and B. Decraene, "IS-IS Extensions for 922 Segment Routing", draft-ietf-isis-segment-routing- 923 extensions-25 (work in progress), May 2019. 925 [I-D.ietf-mpls-sfc] 926 Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based 927 Forwarding Plane for Service Function Chaining", draft- 928 ietf-mpls-sfc-07 (work in progress), March 2019. 930 [I-D.xuclad-spring-sr-service-chaining] 931 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 932 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 933 Henderickx, W., and S. Salsano, "Segment Routing for 934 Service Chaining", draft-xuclad-spring-sr-service- 935 chaining-01 (work in progress), March 2018. 937 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 938 Topology (MT) Routing in Intermediate System to 939 Intermediate Systems (IS-ISs)", RFC 5120, 940 DOI 10.17487/RFC5120, February 2008, 941 . 943 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 944 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 945 2008, . 947 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 948 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 949 2008, . 951 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 952 DOI 10.17487/RFC5308, October 2008, 953 . 955 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 956 and M. Fanto, "IS-IS Generic Cryptographic 957 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 958 2009, . 960 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 961 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 962 DOI 10.17487/RFC5440, March 2009, 963 . 965 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 966 and A. Bierman, Ed., "Network Configuration Protocol 967 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 968 . 970 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 971 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 972 RFC 6790, DOI 10.17487/RFC6790, November 2012, 973 . 975 [RFC7645] Chunduri, U., Tian, A., and W. Lu, "The Keying and 976 Authentication for Routing Protocol (KARP) IS-IS Security 977 Analysis", RFC 7645, DOI 10.17487/RFC7645, September 2015, 978 . 980 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 981 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 982 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 983 March 2016, . 985 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 986 Writing an IANA Considerations Section in RFCs", BCP 26, 987 RFC 8126, DOI 10.17487/RFC8126, June 2017, 988 . 990 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 991 Decraene, B., Litkowski, S., and R. Shakir, "Segment 992 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 993 July 2018, . 995 [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 996 "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, 997 DOI 10.17487/RFC8491, November 2018, 998 . 1000 Appendix A. Appendix 1002 A.1. Challenges with Increased SID Depth 1004 SR label stacks carried in the packet header create challenges in the 1005 design and deployment of networks and networking equipment. 1006 Following examples illustrates the need for increased SID depth in 1007 various use cases: 1009 (a). Consider the following network where SR-MPLS data plane is in 1010 use and with same SRGB (5000-6000) on all nodes i.e., A1 to A11 and 1011 B1 to B7 for illustration: 1013 SID:10 SID:20 SID:30 SID:40 SID:50 SID:300(Ax) SID:60 SID:70 1014 A1--------A2-------A3-------A4-------A5===============A6-- ----------A7 1015 | \ / \5 5/ \ SID:310(Ay) \ / 1016 | 5 \ 10 10/ +-A10-+ \ \10 10/ 1017 | \ SID:80 / |SID:100 \ \ / 1018 A11 SID:111 \A8-----A9/ | \ 40 \ / 1019 | / SID:90 \ +-----+ +---+ \ / 1020 | 5 /10 \10 5 \ \ \ / 1021 | /SID:125(B2x) \ \ \ \/ 1022 B1-------B2==============B3----B4------B5-------=B6----------B7 1023 SID:127(B2y) 1024 SID:110 SID:120 SID:130 SID:140 SID:150 SID:160 SID:170 1026 === = Path with Parallel Adjacencies and ADJ-SIDs 1027 --- = Shortest Path Nodal SID 1029 Figure 6: SR-MPLS Network 1031 Global ADJ-SIDs are provisioned between A5-A6 and B2-B3 (with 1032 parallel adjecencies). All other SIDs shown are nodal SID 1033 indices. 1035 All metrics of the links are set to 1, unless marked otherwise. 1037 Shortest Path from A1 to A7: A2-A3-A4-A5-A6-A7 1039 Path-x: From A1 to A7 - A2-A8-B2-B2x-A9-A10-Ax-A7; Pushed Label 1040 Stack @A1: 5020:5080:5120:5125:5090:5100:5300:5070 (where B2x is a 1041 local ADJ-SID and Ax is a global ADJ-SID). 1043 In this example, the traffic engineered path is represented with a 1044 combination of Adjacency and Node SIDs with a stack of 8 labels. 1045 However, this value can be larger, if the use of entropy label 1046 [RFC6790] is desired and based on the Readable Label Depth 1047 (Appendix A.2) capabilities of each node and additional labels 1048 required to insert ELI/EL at appropriate places. 1050 Though above network is shown with SR-MPLS data plane, if the 1051 network were to use SRv6 data plane, path size would be increased 1052 even more because of the size of the IPv6 SID (16 bytes) in SRH. 1054 (b). Apart from the TE case above, when deploying 1055 [I-D.ietf-mpls-sfc] or [I-D.xuclad-spring-sr-service-chaining], with 1056 the inclusion of services, or non-topological segments on the label 1057 stack, can also make the size of the stack much larger. 1059 Overall the additional path overhead in various SR deployments may 1060 cause the following issues: 1062 a. HW Capabilities: Not all nodes in the path can support the 1063 ability to push or read label stack (with additional non- 1064 topological and special labels) needed to satisfy user/operator 1065 requirements. Alternate paths, which meet these user/operator 1066 requirements may not be available. 1068 b. Line Rate: Potential performance issues in deployments, which use 1069 data plane with extension header as both size of the SIDs in the 1070 extension header and the fixed extension header size itself needs 1071 to be factored by the hardware. 1073 c. MTU: Larger SID stacks on the data packet can cause potential 1074 MTU/fragmentation issues (SRH). 1076 d. Header Tax: Some deployments, such as 5G, require minimal packet 1077 overhead in order to conserve network resources. Carrying 40 or 1078 50 octets of data in a packet with hundreds of octet of header 1079 would be an unacceptable use of available bandwidth. 1081 With the solution proposed in this document (Section 2), for Path-x 1082 in Figure 6 above, SID stack would be reduced from 8 SIDs to a single 1083 SID witout any additional overhead. 1085 A.2. Mitigation with MSD 1087 The number of SIDs in the stack a node can impose is referred as 1088 Maximum SID Depth (MSD) capability [RFC8491], which must be taken 1089 into consideration when computing a path to transport a data packet 1090 in a network implementing segment routing. [I-D.ietf-isis-mpls-elc] 1091 defines another MSD type, Readable Label Depth (RLD) that is used by 1092 a head-end to insert Entropy Label pair (ELI/EL) at appropriate 1093 depth, so it could be read by transit nodes. There are situations 1094 where the source routed path can be excessive as path represented by 1095 SR SIDs need to describe all the nodes and ELI/EL based on the 1096 readability of the nodes in that path. Registries setforth in 1097 [RFC8491] applicable for MPLS data plane and for IPv6 data plane with 1098 SRH. 1100 MSDs (and RLD type) capabilities advertisement help mitigate the 1101 problem for a central entity to create the right source routed path 1102 per application/operator requirements. However the availability of 1103 actual paths meeting these requirements are still limited by the 1104 underlying hardware and their MSD capabilities in the data path. 1106 Authors' Addresses 1108 Uma Chunduri 1109 Futurewei 1110 2330 Central Expressway 1111 Santa Clara, CA 95050 1112 USA 1114 Email: umac.ietf@gmail.com 1116 Richard Li 1117 Futurewei 1118 2330 Central Expressway 1119 Santa Clara, CA 95050 1120 USA 1122 Email: richard.li@futurewei.com 1124 Russ White 1125 Juniper Networks 1126 Oak Island, NC 28465 1127 USA 1129 Email: russ@riw.us 1131 Jeff Tantsura 1132 Apstra Inc. 1133 333 Middlefield Road 1134 Menlo Park, CA 94025 1135 USA 1137 Email: jefftant.ietf@gmail.com 1139 Luis M. Contreras 1140 Telefonica 1141 Sur-3 building, 3rd floor 1142 Madrid 28050 1143 Spain 1145 Email: luismiguel.contrerasmurillo@telefonica.com 1146 Yingzhen Qu 1147 Futurewei 1148 2330 Central Expressway 1149 Santa Clara, CA 95050 1150 USA 1152 Email: yingzhen.qu@futurewei.com