idnits 2.17.1 draft-chunduri-lsr-isis-preferred-path-routing-03.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 L 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 L bit is set). -- The document date (May 16, 2019) is 1807 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 (-26) exists of draft-ietf-6man-segment-routing-header-18 == Outdated reference: A later version (-13) exists of draft-ietf-isis-mpls-elc-07 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-24 Summary: 0 errors (**), 0 flaws (~~), 6 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 Huawei USA 5 Expires: November 17, 2019 R. White 6 Juniper Networks 7 J. Tantsura 8 Apstra Inc. 9 L. Contreras 10 Telefonica 11 Y. Qu 12 Huawei USA 13 May 16, 2019 15 Preferred Path Routing (PPR) in IS-IS 16 draft-chunduri-lsr-isis-preferred-path-routing-03 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 November 17, 2019. 51 Copyright Notice 53 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . 18 91 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 92 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 93 9.1. Normative References . . . . . . . . . . . . . . . . . . 20 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 | 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: 1555555 (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, L bit MUST be set and this value MUST be set to 0. 272 o PPR-Prefix: A variable size Sub-TLV representing the destination 273 of the path being described. This is defined in Section 3.1. 275 o PPR-ID: A variable size Sub-TLV representing the data plane or 276 forwarding identifier of the PPR. Defined in Section 3.2. 278 o PPR-PDEs: Variable number of ordered PDE Sub-TLVs which represents 279 the path. This is defined in Section 3.3. 281 o PPR-Attributes: Variable number of PPR-Attribute Sub-TLVs which 282 represent the path attributes. These are defined in Section 3.4. 284 The Flags field has the following flag bits defined: 286 PPR TLV Flags Format 288 0 1 2 3 4 5 6 7 15 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 |S|D|A|L|Reserved | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 1. S: If set, the PPR TLV MUST be flooded across the entire routing 294 domain. If the S flag is not set, the PPR TLV MUST NOT be leaked 295 between IS-IS levels. This bit MUST NOT be altered during the 296 TLV leaking 298 2. D: When the PPR TLV is leaked from IS-IS level-2 to level-1, the 299 D bit MUST be set. Otherwise, this bit MUST be clear. PPR TLVs 300 with the D bit set MUST NOT be leaked from level-1 to level-2. 301 This is to prevent TLV looping across levels. 303 3. A: The originator of the PPR TLV MUST set the A bit in order to 304 signal that the prefixes and PPR-IDs advertised in the PPR TLV 305 are directly connected to the originators. If this bit is not 306 set, this allows any other node in the network to advertise this 307 TLV on behalf of the originating node of the PPR-Prefix. If PPR 308 TLV is leaked to other areas/levels the A-flag MUST be cleared. 309 In case if the originating node of the prefix must be 310 disambiguated for any reason including, if it is a Multi Homed 311 Prefix (MHP) or leaked to a different IS-IS level or because 312 [RFC7794] X-Flag is set, then PPR-Attribute Sub-TLV Source Router 313 ID SHOULD be included. 315 4. L: L bit MUST be set if a path has only one fragment or if it is 316 the last Fragment of the path. PPR-ID value for all fragments of 317 the same path MUST be same. 319 5. Reserved: For future use; MUST be set to 0 on transmit and 320 ignored on receive. 322 PPR path description for each IS-IS level is computed and given to 323 one of the nodes for L1 and L2 respectively. Similarly path 324 information when crossing the level boundaries MUST be relevant to 325 the destination level. If there is no path information available for 326 the destination level PPR TLV MUST NOT be leaked regardless of S and 327 D bits as defined above. 329 The following Sub-TLVs draw from a new registry for Sub-TLV numbers 330 as specified in Section 7.1 and Section 7.2. 332 3.1. PPR-Prefix Sub-TLV 334 The structure of PPR-Prefix is: 336 0 1 2 3 337 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 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Type | Length | MT-ID | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Prefix Length | Mask Length | IS-IS Prefix | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 // IS-IS Prefix (continued, variable) // 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | PPR-Prefix Sub-TLVs (variable) | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 Figure 2: PPR-Prefix Sub-TLV Format 350 o Type: 1 (IANA to assign from Sub-TLV registry described above). 352 o Length: Total length of the value field in bytes. 354 o MT-ID: The multi-topology identifier defined in [RFC5120]; the 4 355 most significant bits MUST be set to 0 on transmit and ignored on 356 receive. The remaining 12-bit field contains the MT-ID. 358 o Prefix Length: The length of the IS-IS Prefix being encoded in 359 bytes. For IPv4 it MUST be 4 and IPv6 it MUST be 16 bytes. 361 o Mask Length: The length of the prefix in bits. Only the most 362 significant octets of the Prefix are encoded. 364 o IS-IS Prefix: The IS-IS prefix at the tail-end of the advertised 365 PPR. This corresponds to a routable prefix of the originating 366 node and it MAY have one of the [RFC7794] flags set (X-Flag/R- 367 Flag/N-Flag) in the IS-IS reachability TLVs. Length of this field 368 MUST be as per "Prefix Length". Encoding is same as TLV 135 369 [RFC5305] and TLV 236 [RFC5308] or MT-Capable [RFC5120] IPv4 (TLV 370 235) and IPv6 Prefixes (TLV 237) respectively. 372 o PPR-Prefix Sub-TLVs have 1 octet type, 1 octet length and value 373 field is defined per the type field. 375 3.2. PPR-ID Sub-TLV 377 This is the actual data plane identifier in the packet header and 378 could be of any data plane as defined in PPR-ID Type field. Both 379 PPR-Prefix and PPR-ID belongs to a same node in the network. 381 0 1 2 3 382 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 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Type | Length |PPR-ID Flags | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | PPR-ID Type | PPR-ID Length |PPR-ID Mask Len| Algo | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 // PPR-ID (variable size) // 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 Figure 3: PPR-ID Sub-TLV Format 393 o Type: 2 (IANA to assign from Sub-TLV registry described above). 395 o Length: Total length of the value field in bytes. 397 o PPR-ID Flags: 2 Octet field for PPR-ID flags: 399 PPR-ID Flags Format 401 0 1 2 3 4 5 6 7.. 15 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Reserved | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 Reserved: For future use; MUST be set to 0 on transmit and 407 ignored on receive. 409 o PPR-ID Type: Data plane type of PPR-ID. This is a new registry 410 (TBD IANA - Suggested values as below) for this Sub-TLV and the 411 defined types are as follows: 413 Type: 1 SR-MPLS SID/Label 415 Type: 2 Native IPv4 Address/Prefix 417 Type: 3 Native IPv6 Address/Prefix 419 Type: 4 IPv6 SID in SRv6 with SRH 421 o PPR-ID Length: Length of the PPR-ID field in octets and this 422 depends on the PPR-ID type. See PPR-ID below for the length of 423 this field and other considerations. 425 o PPR-ID Mask Length: It is applicable for only for PPR-ID Type 2, 3 426 and 4. For Type 1 this value MUST be set to zero. It contains 427 the length of the PPR-ID Prefix in bits. Only the most 428 significant octets of the Prefix are encoded. This is needed, if 429 PPR-ID followed is an IPv4/IPv6 Prefix instead of 4/16 octet 430 Address respectively. 432 o Algo: 1 octet value represents the SPF algorithm. Algorithm 433 registry is as defined in 434 [I-D.ietf-isis-segment-routing-extensions]. 436 o PPR-ID: This is the Preferred Path forwarding identifier that 437 would be on the data packet. The value of this field is variable 438 and it depends on the PPR-ID Type - for Type 1, this is encoded as 439 SR-MPLS SID/Label. For Type 2 this is a 4 byte IPv4 address. For 440 Type 3 this is a 16 byte IPv6 address. For Type 2 and Type 3 441 encoding is similar to "IS-IS Prefix" as specified in Section 3.1. 442 For Type 4, this is encoded as 16 byte SRv6 SID. 444 For PPR-ID Type 2, 3 or 4, if the PPR-ID Len is set to non-zero 445 value, then the PPR-ID MUST NOT be advertised as a routable prefix in 446 TLV 135, TLV 235, TLV 236 and TLV 237. Also PPR-ID MUST belong to 447 the node where Prefix is advertised from. PPR-ID Len = 0 case is a 448 special case and is discussed in Section 4.1. 450 3.3. PPR-PDE Sub-TLV 452 This Sub-TLV represents the PPR Path Description Element (PDE). PPR- 453 PDEs are used to describe the path in the form of set of contiguous 454 and ordered Sub-TLVs, where first Sub-TLV represents (the top of the 455 stack in MPLS data plane or) first node/segment of the path. These 456 set of ordered Sub-TLVs can have both topological elements and non- 457 topological elements (e.g., service segments). 459 0 1 2 3 460 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 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Type | Length | PPR-PDE Type | Reserved | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | PDE-ID Type | PDE-ID Len | PPR-PDE Flags | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 // PDE-ID Value (continued, variable size) // 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | PPR-PDE Sub-TLVs (variable) | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 Figure 4: PPR-PDE Sub-TLV Format 473 o Type: 3 (See IANA for suggested value) from IS-IS PPR TLV 474 Section 3 Sub-TLV registry. 476 o Length: Total length of the value field in bytes. 478 o PPR-PDE Type: A new registry (TBD IANA) for this Sub-TLV and the 479 defined types are as follows: 481 Type: 1 Topological 483 Type: 2 Non-Topological 485 o PDE-ID Type: 1 Octet PDE-forwarding IDentifier Type. A new 486 registry (Suggested Values as listed, IANA TBD) for this Sub-TLV 487 and the defined types and corresponding PDE-ID Len, PDE-ID Value 488 are as follows: 490 Type 0: This value MUST be set only when PPR-PDE Type is Non- 491 Topological. PDE-ID Len specified in bytes and encoded in NBO 492 in PDE-ID Value field which can represent a service/function. 493 This information is provisioned on the immediate topological PDE 494 preceding to this PDE based on the 'E' bit. 496 Type 1: SID/Label type as defined in 497 [I-D.ietf-isis-segment-routing-extensions]. PDE-ID Len and PDE- 498 ID Value fields are per Section 2.3 of the referenced document. 500 Type 2: SR-MPLS Prefix SID. PDE-ID Len and PDE-ID Value are 501 same as Type 1. 503 Type 3: SR-MPLS Adjacency SID. PDE-ID Len and PDE-ID Value are 504 same as Type 1. 506 Type 4: IPv4 Node Address. PDE-ID Len is 4 bytes and PDE-ID 507 Value is 4 bytes IPv4 address encoded similar to IPv4 Prefix 508 described in Section 3.1. 510 Type 5: IPv4 P2P interface Address. PDE-ID Len is 4 bytes and 511 PDE-ID Value is 4 bytes IPv4 address encoded similar to IPv4 512 Prefix described in Section 3.1. 514 Type 6: IPv4 LAN interface Address. PDE-ID Len is 4 bytes and 515 PDE-ID Value is 4 bytes IPv4 address encoded similar to IPv4 516 Prefix described in Section 3.1. This type MUST have IS-IS 517 System-ID Sub-TLV in the PDE. 519 Type 7: IPv6 Node Address. PDE-ID Len is 16 bytes and PDE-ID 520 Value is 16 bytes IPv6 address encoded similar to IPv6 Prefix 521 described in Section 3.1. 523 Type 8: IPv6 P2P interface Address. PDE-ID Len is 16 bytes and 524 PDE-ID Value is 16 bytes IPv6 address encoded similar to IPv6 525 Prefix described in Section 3.1. 527 Type 9: IPv6 LAN interface Address. PDE-ID Len is 16 bytes and 528 PDE-ID Value is 16 bytes IPv6 address encoded similar to IPv6 529 Prefix described in Section 3.1. This type MUST have IS-IS 530 System-ID Sub-TLV in the PDE. 532 Type 10: SRv6 Node SID as defined in 533 [I-D.bashandy-isis-srv6-extensions]. PDE-ID Len and PDE-ID 534 Value are as defined in SRv6 SID from the referenced draft. 536 Type 11: SRv6 Adjacency-SID. PDE-ID Len and PDE-ID Values are 537 similar to SRv6 Node SID above. 539 o PPR-PDE Flags: 2 Octet bit-field of flags; described below: 541 PPR-PDE Flags Format 543 0 1 2 3 4 5 6 7 .. 15 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 |L|D|E|Reserved | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 L: Loose Bit. Indicates the type of next "Topological PDE-ID" in 549 the path description. If set, the next Topological PDE is 550 Loose. If this flag is unset, the next Topological PDE is 551 Strict Type. 553 D: Destination Bit. By default this bit MUST be unset. This bit 554 MUST be set only for PPR-PDE Type is 1 i.e., Topological and 555 this PDE represents the node PPR-Prefix Section 3.1 belongs to, 556 if there is no further PDE specific Sub-TLVs to override PPR- 557 Prefix and PPR-ID values. 559 E: Egress Bit. By default this bit MUST be unset. This bit MUST 560 be set only for PPR-PDE Type is 2 i.e., Non-Topological and the 561 service needs to be applied on the egress side of the 562 topological PDE preceding this PDE. 564 Reserved: Reserved bits for future use. Reserved bits MUST be 565 reset on transmission and ignored on receive. 567 o PPR-PDE Sub-TLVs: These have 1 octet type, 1 octet length and 568 value field is defined per the type field. Types are as defined 569 in Section 7 and the length field represents the length of the 570 value field in bytes. 572 PPR-PDE Sub-TLV: Type 4 (IANA TBD), Length Total length of value 573 field in bytes, Value: IS-IS System-ID of length "ID Length" as 574 defined in [ISO.10589.1992]. This Sub-TLV MUST NOT be present, 575 if the PPR-PDE Type is not equal to 1 i.e, Topological PDE. 577 3.4. PPR-Attributes Sub-TLV 579 PPR-Attribute Sub-TLVs describe the attributes of the path. The 580 following Sub-TLVs draw from a new registry for Sub-TLV numbers; this 581 registry is to be created by IANA, and administered using the first 582 come first serve process: 584 o Type 1 (Suggested Value - IANA TBD): PPR-Prefix originating node's 585 IPv4 Router ID Sub-TLV. Length and Value field are as specified 586 in [RFC7794]. 588 o Type 2 (Suggested Value - IANA TBD): PPR-Prefix originating node's 589 IPv6 Router ID Sub-TLV. Length and Value field are as specified 590 in [RFC7794]. 592 o Type 3 (Suggested Value - IANA TBD): PPR-Metric Sub-TLV. Length 4 593 bytes, and Value is metric of this path represented through the 594 PPR-ID. Different nodes can advertise the same PPR-ID for the 595 same Prefix with a different set of PPR-PDE Sub-TLVs and the 596 receiving node MUST consider the lowest metric value. 598 4. PPR Processing Procedure Example 600 As specified in Section 2, a PPR can be a TE path, locally 601 provisioned by the operator or by a controller. Consider the 602 following IS-IS network to describe the operation of PPR TLV as 603 defined in Section 3: 605 1 606 _______ 607 / 1 \ 608 +---R2-------R3---+ 609 / \_______/ \ 610 / 1 \ 611 1 / \ 1 612 / 1__R13__1 \ 613 / / \ \ 614 R1------R6 R7-----------R4 615 \ 2 \__R14__/ 2 /\ 616 \ 2 2 / \ 617 3 \ / 3 \1 618 \ 4 / \ 619 +----R8------R9-----R10------R12 620 \ 1 / 621 1 \ / 1 622 +----R11---+ 624 Figure 5: IS-IS Network 626 In the (Figure 5), consider node R1 as an ingress node, or a head-end 627 node, and the node R4 may be an egress node or another head-end node. 628 The numbers shown on links between nodes indicate the bi-directional 629 IS-IS metric as provisioned. R1 may be configured to receive TE 630 source routed path information from a central entity (PCE [RFC5440], 631 Netconf [RFC6241] or a Controller) that comprises of PPR information 632 which relates to sources that are attached to R1. It is also 633 possible to have a PPR provisioned locally by the operator for non-TE 634 needs (e.g. FRR or for chaining certain services). 636 The PPR TLV (as specified in Section 3) is encoded as an ordered list 637 of PPR-PDEs from source to a destination node in the network and is 638 represented with a PPR-ID (Section 3.2). The PPR TLV includes PPR- 639 PDE Sub-TLVS Section 3.3, which represent both topological and non- 640 topological elements and specifies the actual path towards a PPR- 641 Prefix at R4. 643 o The shortest path towards R4 from R1 are through the following 644 sequence of nodes: R1-R2-R3-R4 based on the provisioned metrics. 646 o The central entity can define a few PPRs from R1 to R4 that 647 deviate from the shortest path based on other network 648 characteristic requirements as requested by an application or 649 service. For example, the network characteristics or performance 650 requirements may include bandwidth, jitter, latency, throughput, 651 error rate, etc. 653 o A first PPR may be identified by PPR-ID = 1 (value) and may 654 include the path of R1-R6-R7-R4 for a Prefix advertised by R4. 655 This is an example for a Loose-PPR and 'L' bit MUST be set 656 appropriately at Section 3.3. 658 o A second PPR may be identified by PPR-ID = 2 (value) and may 659 include the path of R1-R8-R9-R10-R4. This is an example for a 660 Strict-PPR and 'L' bit MUST be unset appropriately at Section 3.3. 661 Though this example shows PPR with all nodal SIDs, it is possible 662 to have a PPR with combination of node and adjacency SIDs (local 663 or global) or with PPR-PDE Type set to Non-Topological as defined 664 in Section 3.3 elements along with these. 666 4.1. PPR TLV Processing 668 The first topological sub-object or PDE (Section 3.3) relative to the 669 beginning of PPR Path contains the information about the first node 670 (e.g. in SR-MPLS it's the topmost label). The last topological sub- 671 object or PDE contains information about the last node (e.g. in SR- 672 MPLS it's the bottommost label). 674 Each receiving node, determines whether an advertised PPR includes 675 information regarding the receiving node. Before processing any 676 further, validation MUST be done to see if any PPR topological PDE is 677 seen more than once (possible loop), if yes, this PPR TLV MUST be 678 ignored. Processing of PPR TLVs may be done, during the end of the 679 SPF computation (for MTID that is advertised in this TLV) and for 680 each prefix described through PPR TLV. For example, node R9 receives 681 the PPR information, and ignores the PPR-ID=1 (Section 4) because 682 this PPR TLV does not include node R9 in the path description/ordered 683 PPR-PDE list. 685 However, node R9 may determine that the second PPR identified by PPR- 686 ID = 2 does include the node R9 in its PDE list. Therefore, node R9 687 updates the local forwarding database to include an entry for the 688 destination address that R4 indicates, so that when a data packet 689 comprising a PPR-ID of 2 is received, forward the data packet to node 690 R10 instead of R11. This is done, even though from R9 the shortest 691 path to reach R4 via R11 (Cost 3: R9-R11-R12-R4) it chooses the NH to 692 R10 to reach R4 as specified in the PPR path description. Same 693 process happens to all nodes or all topological PDEs as described in 694 the PPR TLV. 696 In summary, the receiving node checks first, if this node is on the 697 path by checking the node's topological elements (with PPR-PDE Type 698 set to Topological) in the path list. If yes, it adds/adjusts the 699 PPR-ID's shortest path NH towards the next topological PDE in the 700 PPR's Path. 702 For PPR-ID (Section 3.2) Type 2, 3 or 4, if the PPR-ID Len is set to 703 0, then Prefix would also become the PPR-ID (a special case). This 704 can be used for some situations, where certain optimizations are 705 required in the network. For this, path described in the PPR TLV 706 SHOULD be completely disjoint from the shortest path route to the 707 prefix. If the disjoint-ness property is not maintained then the 708 traffic may not be using the PPR path, as and when it encounters any 709 node which is not in the path description. 711 4.2. Path Fragments 713 A complete PPR path may not fit into maximum allowable size of the 714 IS-IS TLV. To overcome this a 7 bit Fragment-ID field is defined in 715 Section 3 . With this, a single PPR path is represented via one or 716 more fragmented PPR path TLVs, with all having the same PPR-ID. Each 717 fragment carries the PPR-ID as well as a numeric Fragment-ID from 0 718 to (N-1), when N fragments are needed to describe the PPR Graph 719 (where N>1). In this case Fragment (N-1) MUST set the L bit (PPR- 720 Flags) to indicate it is the last fragment. If Fragment-ID is non 721 zero in the TLV, then it MUST not carry PPR-Prefix Sub-TLV. The 722 optional PPR Attribute Sub-TLVs which describe the path overall MUST 723 be included in the last fragment only (i.e., when the L bit is set). 725 5. PPR Data Plane aspects 727 Data plane for PPR-ID is selected by the entity (e.g., a controller, 728 locally provisioned by operator), which selects a particular PPR in 729 the network. Section 3.2 defines various data plane identifier types 730 and a corresponding data plane identifier is selected by the entity 731 which selects the PPR. 733 5.1. SR-MPLS with PPR 735 If PPR-ID Type is 1, then the PPR belongs to SR-MPLS data plane and 736 the complete PPR stack is represented with a unique SR SID/Label and 737 this gets programmed on the data plane of each node, with the 738 appropriate NH computed as specified in Section 4. PPR-ID here is a 739 label/index from the SRGB (like another node SID or global ADJ-SID). 740 PPR path description here is a set of ordered SIDs represented with 741 PPR-PDE (Section 3.2) Sub-TLVs. Non-Topological segments also 742 programmed in the forwarding to enable specific function/service, 743 when the data packet hits with corresponding PPR-ID. 745 Based on 'L' flag in PPR-ID Flags (Section 3.2), for SR-MPLS data 746 plane either 1 label or 2 labels need to be provisioned on individual 747 nodes on the path description. For the example network in Section 4, 748 for PPR-ID=1, which is a loose path, node R6 programs the bottom 749 label as PPR-ID and the top label as the next topological PPR-PDE in 750 the path, which is a node SID of R7. The NH computed at R6 would be 751 the shortest path towards R7 i.e., the interface towards R13. If 'L' 752 flag is unset only PPR-ID is programmed on the data plane with NH set 753 to the shortest path towards next topological PPR-PDE. 755 5.2. PPR Native IP Data Planes 757 If PPR-ID Type is 2 then source routing and packet steering can be 758 done in IPv4 data plane (PPR-IPv4), along the path as described in 759 PPR Path description. This is achieved by setting the destination IP 760 address as PPR-ID, which is an IPv4 address in the data packet 761 (tunneled/encapsulated). There is no data plane change or upgrade 762 needed to support this. 764 Similarly for PPR-ID Type is 3, then source routing and packet 765 steering can be done in IPv6 data plane (PPR-IPv6), along the path as 766 described in PPR Path description. Whatever specified above for IPv4 767 applies here too, except that destination IP address of the data 768 packet is an IPv6 Address (PPR-ID). This doesn't require any IPv6 769 extension headers (EH), if there is no metadata/TLVs need to be 770 carried in the data packet. 772 Based on 'L' flag in PPR-ID Flags (Section 3.2), for PPR-ID Type 2 or 773 3 (Native IPv4 or IPv6 data planes respectively) the packet has to be 774 encapsulated using the capabilities (either dynamically signaled 775 through [I-D.ietf-isis-encapsulation-cap] or statically provisioned 776 on the nodes) of the next loose PDE in the path description. 778 For the example network in Section 4, for PPR-ID=1, which is a loose 779 path, node R6 programs to encapsulate the data packet towards the 780 next loose topological PPR-PDE in the path, which is R7. The NH 781 computed at R6 would be the shortest path towards R7 i.e., the 782 interface towards R13. If 'L' flag is unset only PPR-ID is 783 programmed on the data plane with NH set to the shortest path towards 784 next topological PPR-PDE, with no further encapsulation of the data 785 packet. 787 5.3. SRv6 with PPR 789 If PPR-ID Type is 4, the PPR belongs to SRv6 with SRH data plane and 790 the complete PPR stack is represented with IPv6 SIDs and this gets 791 programmed on the data plane with the appropriate NH computed as 792 specified in Section 4. PPR-ID here is a SRv6 SID. PPR path 793 description here is a set of ordered SID TLVs similar to as specified 794 in Section 5.1. One way PPR-ID would be used in this case is by 795 setting it as the destination IPv6 address and SL field in SRH would 796 be set to 0; however SRH [I-D.ietf-6man-segment-routing-header] can 797 contain any other TLVs and non-topological SIDs as needed. 799 6. Acknowledgements 801 Thanks to Alex Clemm, Lin Han, Toerless Eckert, Asit Chakraborti, 802 Stewart Bryant and Kiran Makhijani for initial discussions on this 803 topic. Thanks to Kevin Smith and Stephen Johnson for various 804 deployment scenarios applicability from ETSI WGs perspective. 805 Authors also acknowledge Alexander Vainshtein for detailed 806 discussions and few suggestions on this topic. 808 Earlier versions of draft-ietf-isis-segment-routing-extensions have a 809 mechanism to advertise EROs through Binding SID. 811 7. IANA Considerations 813 This document requests the following new TLV in IANA IS-IS TLV code- 814 point registry. 816 TLV # Name 817 ----- -------------- 818 155 PPR TLV (Suggested Value, IANA TBD) 820 7.1. PPR Sub-TLVs 822 This document requests IANA to create a new Sub-TLV registry for PPR 823 TLV Section 3 with the following initial entries (suggested values): 825 Sub-TLV # Sub-TLV Name 826 --------- --------------------------------------------------------- 828 1 PPR-Prefix (Section 3.1) 830 2 PPR-ID (Section 3.2) 832 3 PPR-PDE (Section 3.3) 834 4 IS-IS System-ID (Section 3.3) 836 7.2. IGP Parameters 838 This document requests additional IANA registries in an IANA managed 839 registry "Interior Gateway Protocol (IGP) Parameters" for various PPR 840 TLV parameters. The registration procedure is based on the "Expert 841 Review" as defined in [RFC8126]. The suggested registry names are: 843 o "PPR-Type" - Types are an unsigned 8 bit numbers. Values are as 844 defined in Section 3 of this document. 846 o "PPR-Flags" - 1 Octet. Bits as described in Section 3 of this 847 document. 849 o "PPR-ID Type" - Types are an unsigned 8 bit numbers. Values are 850 as defined in Section 3.2 of this document. 852 o "PPR-ID Flags" - 1 Octet. Bits as described in Section 3.2 of 853 this document. 855 o "PPR-PDE Type" - Types are an unsigned 8 bit numbers. Values are 856 as defined in Section 3.3 of this document. 858 o "PPR-PDE Flags" - 1 Octet. Bits as described in Section 3.3 of 859 this document. 861 o "PDE-ID Type" - Types are an unsigned 8 bit numbers. Values are 862 as defined in Section 3.3 of this document. 864 This document also requests IANA to create a new Sub-TLV registry in 865 "Interior Gateway Protocol (IGP) Parameters" for PPR Path attributes 866 with the following initial entries (suggested values): 868 Sub-TLV # Sub-TLV Name 869 --------- --------------------------------------------------------- 871 1 PPR-Prefix Source IPv4 Router ID (Section 3.4) 873 2 PPR-Prefix Source IPv6 Router ID (Section 3.4) 875 3 PPR-Metric (Section 3.4) 877 8. Security Considerations 879 Security concerns for IS-IS are addressed in [RFC5304] and [RFC5310]. 880 Further security analysis for IS-IS protocol is done in [RFC7645] 881 with detailed analysis of various security threats and why [RFC5304] 882 should not be used in the deployments. Advertisement of the 883 additional information defined in this document introduces no new 884 security concerns in IS-IS protocol. However, for extensions related 885 ro SR-MPLS and SRH data planes, those particular data plane security 886 considerations does apply here. 888 9. References 889 9.1. Normative References 891 [ISO.10589.1992] 892 International Organization for Standardization, 893 "Intermediate system to intermediate system intra-domain- 894 routing routine information exchange protocol for use in 895 conjunction with the protocol for providing the 896 connectionless-mode Network Service (ISO 8473)", 897 ISO Standard 10589, 1992. 899 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 900 Requirement Levels", BCP 14, RFC 2119, 901 DOI 10.17487/RFC2119, March 1997, 902 . 904 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 905 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 906 May 2017, . 908 9.2. Informative References 910 [I-D.bashandy-isis-srv6-extensions] 911 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 912 Z. Hu, "IS-IS Extensions to Support Routing over IPv6 913 Dataplane", draft-bashandy-isis-srv6-extensions-05 (work 914 in progress), March 2019. 916 [I-D.ietf-6man-segment-routing-header] 917 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 918 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 919 (SRH)", draft-ietf-6man-segment-routing-header-18 (work in 920 progress), April 2019. 922 [I-D.ietf-isis-encapsulation-cap] 923 Xu, X., Decraene, B., Raszuk, R., Chunduri, U., Contreras, 924 L., and L. Jalil, "Advertising Tunnelling Capability in 925 IS-IS", draft-ietf-isis-encapsulation-cap-01 (work in 926 progress), April 2017. 928 [I-D.ietf-isis-mpls-elc] 929 Xu, X., Kini, S., Psenak, P., Filsfils, C., and S. 930 Litkowski, "Signaling Entropy Label Capability and Entropy 931 Readable Label Depth Using IS-IS", draft-ietf-isis-mpls- 932 elc-07 (work in progress), May 2019. 934 [I-D.ietf-isis-segment-routing-extensions] 935 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 936 Gredler, H., and B. Decraene, "IS-IS Extensions for 937 Segment Routing", draft-ietf-isis-segment-routing- 938 extensions-24 (work in progress), April 2019. 940 [I-D.ietf-mpls-sfc] 941 Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based 942 Forwarding Plane for Service Function Chaining", draft- 943 ietf-mpls-sfc-07 (work in progress), March 2019. 945 [I-D.xuclad-spring-sr-service-chaining] 946 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 947 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 948 Henderickx, W., and S. Salsano, "Segment Routing for 949 Service Chaining", draft-xuclad-spring-sr-service- 950 chaining-01 (work in progress), March 2018. 952 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 953 Topology (MT) Routing in Intermediate System to 954 Intermediate Systems (IS-ISs)", RFC 5120, 955 DOI 10.17487/RFC5120, February 2008, 956 . 958 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 959 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 960 2008, . 962 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 963 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 964 2008, . 966 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 967 DOI 10.17487/RFC5308, October 2008, 968 . 970 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 971 and M. Fanto, "IS-IS Generic Cryptographic 972 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 973 2009, . 975 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 976 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 977 DOI 10.17487/RFC5440, March 2009, 978 . 980 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 981 and A. Bierman, Ed., "Network Configuration Protocol 982 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 983 . 985 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 986 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 987 RFC 6790, DOI 10.17487/RFC6790, November 2012, 988 . 990 [RFC7645] Chunduri, U., Tian, A., and W. Lu, "The Keying and 991 Authentication for Routing Protocol (KARP) IS-IS Security 992 Analysis", RFC 7645, DOI 10.17487/RFC7645, September 2015, 993 . 995 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 996 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 997 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 998 March 2016, . 1000 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1001 Writing an IANA Considerations Section in RFCs", BCP 26, 1002 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1003 . 1005 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1006 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1007 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1008 July 2018, . 1010 [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 1011 "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, 1012 DOI 10.17487/RFC8491, November 2018, 1013 . 1015 Appendix A. Appendix 1017 A.1. Challenges with Increased SID Depth 1019 SR label stacks carried in the packet header create challenges in the 1020 design and deployment of networks and networking equipment. 1021 Following examples illustrates the need for increased SID depth in 1022 various use cases: 1024 (a). Consider the following network where SR-MPLS data plane is in 1025 use and with same SRGB (5000-6000) on all nodes i.e., A1 to A11 and 1026 B1 to B7 for illustration: 1028 SID:10 SID:20 SID:30 SID:40 SID:50 SID:300(Ax) SID:60 SID:70 1029 A1--------A2-------A3-------A4-------A5===============A6-- ----------A7 1030 | \ / \5 5/ \ SID:310(Ay) \ / 1031 | 5 \ 10 10/ +-A10-+ \ \10 10/ 1032 | \ SID:80 / |SID:100 \ \ / 1033 A11 SID:111 \A8-----A9/ | \ 40 \ / 1034 | / SID:90 \ +-----+ +---+ \ / 1035 | 5 /10 \10 5 \ \ \ / 1036 | /SID:125(B2x) \ \ \ \/ 1037 B1-------B2==============B3----B4------B5-------=B6----------B7 1038 SID:127(B2y) 1039 SID:110 SID:120 SID:130 SID:140 SID:150 SID:160 SID:170 1041 === = Path with Parallel Adjacencies and ADJ-SIDs 1042 --- = Shortest Path Nodal SID 1044 Figure 6: SR-MPLS Network 1046 Global ADJ-SIDs are provisioned between A5-A6 and B2-B3 (with 1047 parallel adjecencies). All other SIDs shown are nodal SID 1048 indices. 1050 All metrics of the links are set to 1, unless marked otherwise. 1052 Shortest Path from A1 to A7: A2-A3-A4-A5-A6-A7 1054 Path-x: From A1 to A7 - A2-A8-B2-B2x-A9-A10-Ax-A7; Pushed Label 1055 Stack @A1: 5020:5080:5120:5125:5090:5100:5300:5070 (where B2x is a 1056 local ADJ-SID and Ax is a global ADJ-SID). 1058 In this example, the traffic engineered path is represented with a 1059 combination of Adjacency and Node SIDs with a stack of 8 labels. 1060 However, this value can be larger, if the use of entropy label 1061 [RFC6790] is desired and based on the Readable Label Depth 1062 (Appendix A.2) capabilities of each node and additional labels 1063 required to insert ELI/EL at appropriate places. 1065 Though above network is shown with SR-MPLS data plane, if the 1066 network were to use SRv6 data plane, path size would be increased 1067 even more because of the size of the IPv6 SID (16 bytes) in SRH. 1069 (b). Apart from the TE case above, when deploying 1070 [I-D.ietf-mpls-sfc] or [I-D.xuclad-spring-sr-service-chaining], with 1071 the inclusion of services, or non-topological segments on the label 1072 stack, can also make the size of the stack much larger. 1074 Overall the additional path overhead in various SR deployments may 1075 cause the following issues: 1077 a. HW Capabilities: Not all nodes in the path can support the 1078 ability to push or read label stack (with additional non- 1079 topological and special labels) needed to satisfy user/operator 1080 requirements. Alternate paths, which meet these user/operator 1081 requirements may not be available. 1083 b. Line Rate: Potential performance issues in deployments, which use 1084 data plane with extension header as both size of the SIDs in the 1085 extension header and the fixed extension header size itself needs 1086 to be factored by the hardware. 1088 c. MTU: Larger SID stacks on the data packet can cause potential 1089 MTU/fragmentation issues (SRH). 1091 d. Header Tax: Some deployments, such as 5G, require minimal packet 1092 overhead in order to conserve network resources. Carrying 40 or 1093 50 octets of data in a packet with hundreds of octet of header 1094 would be an unacceptable use of available bandwidth. 1096 With the solution proposed in this document (Section 2), for Path-x 1097 in Figure 6 above, SID stack would be reduced from 8 SIDs to a single 1098 SID witout any additional overhead. 1100 A.2. Mitigation with MSD 1102 The number of SIDs in the stack a node can impose is referred as 1103 Maximum SID Depth (MSD) capability [RFC8491], which must be taken 1104 into consideration when computing a path to transport a data packet 1105 in a network implementing segment routing. [I-D.ietf-isis-mpls-elc] 1106 defines another MSD type, Readable Label Depth (RLD) that is used by 1107 a head-end to insert Entropy Label pair (ELI/EL) at appropriate 1108 depth, so it could be read by transit nodes. There are situations 1109 where the source routed path can be excessive as path represented by 1110 SR SIDs need to describe all the nodes and ELI/EL based on the 1111 readability of the nodes in that path. Registries setforth in 1112 [RFC8491] applicable for MPLS data plane and for IPv6 data plane with 1113 SRH. 1115 MSDs (and RLD type) capabilities advertisement help mitigate the 1116 problem for a central entity to create the right source routed path 1117 per application/operator requirements. However the availability of 1118 actual paths meeting these requirements are still limited by the 1119 underlying hardware and their MSD capabilities in the data path. 1121 Authors' Addresses 1123 Uma Chunduri 1124 Huawei USA 1125 2330 Central Expressway 1126 Santa Clara, CA 95050 1127 USA 1129 Email: uma.chunduri@huawei.com 1131 Richard Li 1132 Huawei USA 1133 2330 Central Expressway 1134 Santa Clara, CA 95050 1135 USA 1137 Email: renwei.li@huawei.com 1139 Russ White 1140 Juniper Networks 1141 Oak Island, NC 28465 1142 USA 1144 Email: russ@riw.us 1146 Jeff Tantsura 1147 Apstra Inc. 1148 333 Middlefield Road 1149 Menlo Park, CA 94025 1150 USA 1152 Email: jefftant.ietf@gmail.com 1154 Luis M. Contreras 1155 Telefonica 1156 Sur-3 building, 3rd floor 1157 Madrid 28050 1158 Spain 1160 Email: luismiguel.contrerasmurillo@telefonica.com 1161 Yingzhen Qu 1162 Huawei USA 1163 2330 Central Expressway 1164 Santa Clara, CA 95050 1165 USA 1167 Email: yingzhen.qu@huawei.com