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