idnits 2.17.1 draft-chunduri-lsr-isis-preferred-path-routing-02.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 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 (February 14, 2019) is 1898 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 (-05) exists of draft-bashandy-isis-srv6-extensions-04 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-16 == Outdated reference: A later version (-13) exists of draft-ietf-isis-mpls-elc-06 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-22 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-sfc-05 Summary: 0 errors (**), 0 flaws (~~), 8 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: August 18, 2019 R. White 6 Juniper Networks 7 J. Tantsura 8 Apstra Inc. 9 L. Contreras 10 Telefonica 11 Y. Qu 12 Huawei USA 13 February 14, 2019 15 Preferred Path Routing (PPR) in IS-IS 16 draft-chunduri-lsr-isis-preferred-path-routing-02 18 Abstract 20 This document specifies a Preferred Path Routing (PPR), a routing 21 protocol mechanism to simplify the path description of data plane 22 traffic in Segment Routing (SR) deployments. PPR aims to mitigate 23 the MTU and data plane processing issues that may result from SR 24 packet overheads; and also supports traffic measurement, accounting 25 statistics and further attribute extensions along the paths. 26 Preferred Path Routing is achieved through the addition of 27 descriptions to IS-IS advertised prefixes, and mapping those to a PPR 28 data-plane identifier. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 34 document are to be interpreted as described in RFC2119 [RFC2119], 35 RFC8174 [RFC8174] when, and only when they appear in all capitals, as 36 shown here. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on August 18, 2019. 55 Copyright Notice 57 Copyright (c) 2019 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (https://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 74 1.2. Challenges with Increased SID Depth . . . . . . . . . . . 4 75 1.3. Mitigation with MSD . . . . . . . . . . . . . . . . . . . 6 76 2. Preferred Path Routing (PPR) . . . . . . . . . . . . . . . . 6 77 2.1. PPR-ID and PPR Path Description . . . . . . . . . . . . . 7 78 3. PPR Related TLVs . . . . . . . . . . . . . . . . . . . . . . 7 79 3.1. PPR-Prefix Sub-TLV . . . . . . . . . . . . . . . . . . . 9 80 3.2. PPR-ID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 10 81 3.3. PPR-PDE Sub-TLV . . . . . . . . . . . . . . . . . . . . . 12 82 3.4. PPR-Attributes Sub-TLV . . . . . . . . . . . . . . . . . 14 83 4. PPR Processing Procedure Example . . . . . . . . . . . . . . 15 84 4.1. PPR TLV Processing . . . . . . . . . . . . . . . . . . . 17 85 4.2. Path Fragments . . . . . . . . . . . . . . . . . . . . . 18 86 5. PPR Data Plane aspects . . . . . . . . . . . . . . . . . . . 18 87 5.1. SR-MPLS with PPR . . . . . . . . . . . . . . . . . . . . 18 88 5.2. SRv6 with PPR . . . . . . . . . . . . . . . . . . . . . . 19 89 5.3. PPR Native IP Data Planes . . . . . . . . . . . . . . . . 19 90 6. PPR Scaling Considerations . . . . . . . . . . . . . . . . . 19 91 7. PPR Traffic Accounting . . . . . . . . . . . . . . . . . . . 20 92 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 93 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 94 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 95 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 96 11.1. Normative References . . . . . . . . . . . . . . . . . . 22 97 11.2. Informative References . . . . . . . . . . . . . . . . . 23 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 [I-D.ietf-spring-segment-routing]. SR capabilities are defined for 106 MPLS and IPv6 data planes called SR-MPLS and SRv6 respectively. 108 In SR-MPLS, each segment is encoded as a label, and an ordered list 109 of segments are encoded as a stack of labels. This stack of labels 110 is carried as part of the packet header. In SRv6, a segment is 111 encoded as an IPv6 address, within a new type of IPv6 hop-by-hop 112 routing header/extension header (EH) called SRH 113 [I-D.ietf-6man-segment-routing-header]; an ordered list of IPv6 114 addresses/segments are encoded in SRH. 116 Section 1.2 and Section 1.3 describe performance, hardware 117 capabilities and various associated issues which may result in SR 118 deployments. These motivate the proposed solution, Preferred Path 119 Routing, which is specified in Section 2. 121 1.1. Acronyms 123 EL - Entropy Label 125 ELI - Entropy Label Indicator 127 LSP - IS-IS Link State PDU 129 MPLS - Multi Protocol Label Switching 131 MSD - Maximum SID Depth 133 MTU - Maximum Transferrable Unit 135 PPR - Preferred Path Routing/Route 137 PPR-ID - Preferred Path Route Identifier, a data plane identifier 139 SID - Segment Identifier 141 SPF - Shortest Path First 143 SR-MPLS - Segment Routing with MPLS data plane 144 SRH - Segment Routing Header - IPv6 routing Extension headr 146 SRv6 - Segment Routing with Ipv6 data plane with SRH 148 TE - Traffic Engineering 150 1.2. Challenges with Increased SID Depth 152 SR label stacks carried in the packet header create challenges in the 153 design and deployment of networks and networking equipment. 154 Following examples illustrates the need for increased SID depth in 155 various use cases: 157 (a). Consider the following network where SR-MPLS data plane is in 158 use and with same SRGB (5000-6000) on all nodes i.e., A1 to A7 and B1 159 to B7 for illustration: 161 SID:10 SID:20 SID:30 SID:40 SID:50 SID:300(Ax) SID:60 SID:70 162 A1--------A2-------A3-------A4-------A5===============A6-- ----------A7 163 | \ / \5 5/ \ SID:310(Ay) \ / 164 | 5 \ 10 10/ +-A10-+ \ \10 10/ 165 | \ SID:80 / |SID:100 \ \ / 166 A11 SID:111 \A8-----A9/ | \ 40 \ / 167 | / SID:90 \ +-----+ +---+ \ / 168 | 5 /10 \10 5 \ \ \ / 169 | /SID:125(B2x) \ \ \ \/ 170 B1-------B2==============B3----B4------B5-------=B6----------B7 171 SID:127(B2y) 172 SID:110 SID:120 SID:130 SID:140 SID:150 SID:160 SID:170 174 === = Path with Parallel Adjecencies and ADJ-SIDs 175 --- = Shortest Path Nodal SID 177 Figure 1: SR-MPLS Network 179 Global ADJ-SIDs are provisioned between A5-A6 and B2-B3 (with 180 parallel adjecencies). All other SIDs shown are nodal SID 181 indices. 183 All metrics of the links are set to 1, unless marked otherwise. 185 Shortest Path from A1 to A7: A2-A3-A4-A5-A6-A7 187 Path-x: From A1 to A7 - A2-A8-B2-B2x-A9-A10-Ax-A7; Pushed Label 188 Stack @A1: 5020:5080:5120:5125:5090:5100:5300:5070 (where B2x is a 189 local ADJ-SID and Ax is a global ADJ-SID). 191 In this example, the traffic engineered path is represented with a 192 combination of Adjacency and Node SIDs with a stack of 8 labels. 193 However, this value can be larger, if the use of entropy label 194 [RFC6790] is desired and based on the Readable Label Depth 195 (Section 1.3) capabilities of each node and additional labels 196 required to insert ELI/EL at appropriate places. 198 Though above network is shown with SR-MPLS data plane, if the 199 network were to use SR-IPv6 data plane, path size would be 200 increased even more because of the size of the IPv6 SID (16 bytes) 201 in SRH. 203 (b). Apart from the TE case above, when deploying 204 [I-D.ietf-mpls-sfc] or [I-D.xuclad-spring-sr-service-chaining], with 205 the inclusion of services, or non-topological segments on the label 206 stack, can also make the size of the stack much larger. 208 (c). Some SR-MPLS deployments need accounting statistics for path 209 monitoring and traffic re-optimizations. 210 [I-D.hegde-spring-traffic-accounting-for-sr-paths] and 211 [I-D.cheng-spring-mpls-path-segment] propose solutions with various 212 forms of path segments (either with special labels or PATH segment 213 encoded at the bottom of the stack respectively). However, these 214 proposals further increases the depth of SID stack, when it is 215 compounded with MSD/RLDs of various nodes in the path. 217 Overall the additional path overhead in various SR deployments may 218 cause the following issues: 220 a. HW Capabilities: Not all nodes in the path can support the 221 ability to push or read label stack (with additional non- 222 topological and special labels) needed 223 [I-D.ietf-isis-segment-routing-msd] to satisfy user/operator 224 requirements. Alternate paths, which meet these user/operator 225 requirements may not be available. 227 b. Line Rate: Potential performance issues in deployments, which use 228 SRH data plane with the increased size of the SRH with 16 byte 229 SIDs. 231 c. MTU: Larger SID stacks on the data packet can cause potential 232 MTU/fragmentation issues (SRH). 234 d. Header Tax: Some deployments, such as 5G, require minimal packet 235 overhead in order to conserve network resources. Carrying 40 or 236 50 octets of data in a packet with hundreds of octet of header 237 would be an unacceptable use of available bandwidth (SRH). 239 With the solution proposed in this document (Section 5) and 240 Section 4), for Path-x in the example network Figure 1 above, SID 241 stack would be reduced from 8 SIDs to a single SID. 243 1.3. Mitigation with MSD 245 The number of SIDs in the stack a node can impose is referred as 246 Maximum SID Depth (MSD) capability 247 [I-D.ietf-isis-segment-routing-msd], which must be taken into 248 consideration when computing a path to transport a data packet in a 249 network implementing segment routing. [I-D.ietf-isis-mpls-elc] 250 defines another MSD type, Readable Label Depth (RLD) that is used by 251 a head-end to insert Entropy Label pair (ELI/EL) at appropriate 252 depth, so it could be read by transit nodes. There are situations 253 where the source routed path can be excessive as path represented by 254 SR SIDs need to describe all the nodes and ELI/EL based on the 255 readability of the nodes in that path. 256 [I-D.ietf-isis-segment-routing-msd] defines one registry element 257 applicable for MPLS data plane and this registry can be used for IPv6 258 data plane with SRH. 260 MSDs (and RLD type) capabilities advertisement help mitigate the 261 problem for a central entity to create the right source routed path 262 per application/operator requirements. However the availability of 263 actual paths meeting these requirements are still limited by the 264 underlying hardware and their MSD capabilities in the data path. 266 2. Preferred Path Routing (PPR) 268 PPR mitigates the issues described in Section 1.2, while continuing 269 to allow the direction of traffic along an engineered path through 270 the network by replacing the label stack with a PPR-ID. The PPR-ID 271 can either be a single label or a native destination address. To 272 facilitate the use of a single label to describe an entire path, a 273 new TLV is added to IS-IS, as described below in Section 3. 275 A PPR could be an SR path, a traffic engineered path computed based 276 on some constraints, an explicitly provisioned Fast Re-Route (FRR) 277 path or a service chained path. A PPR can be signaled by any node, 278 computed by a central controller, or manually configured by an 279 operator. PPR extends the source routing and path steering 280 capabilities to native IP (IPv4 and IPv6) data planes without 281 hardware upgrades; see Section 5. 283 2.1. PPR-ID and PPR Path Description 285 The PPR-ID describes a path through the network. For SR- MPLS this 286 is an MPLS Label/SID and for SRv6 this is an IPv6-SID. For native IP 287 data planes this is either IPv4 or IPv6 address/prefix. 289 The path identified by the PPR-ID is described as a set of Path 290 Description Elements (PDEs), each of which represents a segment of 291 the path. Each node determines its location in the path as 292 described, and forwards to the next segment/hop or label of the path 293 description (see the Forwarding Procedure Example later in this 294 document). 296 These PPR-PDEs as defined in Section 3.3, like SR SIDs, can represent 297 topological elements like links/nodes, backup nodes, as well as non- 298 topological elements such as a service, function, or context on a 299 particular node. PPR-PDE optionally, can also have more information 300 as described with in their Sub-TLVs. 302 A PPR path can be described as a Strict-PPR or a Loose-PPR. In a 303 Strict-PPR all nodes/links on the path are described with SR SIDs for 304 SR data planes or IPv4/IPV6 addresses for native IP data planes. In 305 a Loose-PPR only some of the nodes/links from source to destination 306 are described. More specifics and restrictions around Strict/Loose 307 PPRs are described in respective data planes in Section 5. Each PDE 308 is described as either an MPLS label towards the next hop in MPLS 309 enabled networks, or as an IP next hop, in the case of either 310 "plain"/"native" IP or SRv6 enabled networks. A PPR path is related 311 to a set of PDEs using the following TLVs. 313 3. PPR Related TLVs 315 This section describes the encoding of PPR TLV. This TLV can be seen 316 as having 4 logical sections viz., encoding of the PPR-Prefix (IS-IS 317 Prefix), encoding of PPR-ID, encoding of path description with an 318 ordered PDE Sub-TLVs and a set of optional PPR attribute Sub-TLVs, 319 which can be used to describe one or more parameters of the path. 320 Multiple instances of this TLV MAY be advertised in IS-IS LSPs with 321 different PPR-ID Type and with corresponding PDE Sub-TLVS. The PPR 322 TLV has Type TBD (suggested value xxx), and has the following format: 324 0 1 2 3 325 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 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Type | Length | PPR-Flags | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | PPR-Prefix Sub-TLV (variable size) | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | PPR-ID Sub-TLV (variable size) | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | PPR-PDE Sub-TLVs (variable) | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | PPR-Attribute Sub-TLVs (variable) | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 Figure 2: PPR TLV Format 340 o Type: TBD (IANA) from IS-IS top level TLV registry. 342 o Length: Total length of the value field in bytes. 344 o PPR-Flags: 2 Octet bit-field of flags for this TLV; described 345 below. 347 o PPR-Prefix: A variable size sub-TLV representing the destination 348 of the path being described. This is defined in Section 3.1. 350 o PPR-ID: A variable size Sub-TLV representing the data plane or 351 forwarding identifier of the PPR. Defined in Section 3.2. 353 o PPR-PDEs: Variable number of ordered PDE Sub-TLVs which represents 354 the path. This is defined in Section 3.3. 356 o PPR-Attributes: Variable number of PPR-Attribute Sub-TLVs which 357 represent the path attributes. These are defined in Section 3.4. 359 The Flags field has the following flag bits defined: 361 PPR TLV Flags Format 363 0 1 2 3 4 5 6 7 15 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 |S|D|A|L|Reserved | Fragment-ID | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 1. S: If set, the PPR TLV MUST be flooded across the entire routing 369 domain. If the S flag is not set, the PPR TLV MUST NOT be leaked 370 between IS-IS levels. This bit MUST NOT be altered during the 371 TLV leaking 373 2. D: When the PPR TLV is leaked from IS-IS level-2 to level-1, the 374 D bit MUST be set. Otherwise, this bit MUST be clear. PPR TLVs 375 with the D bit set MUST NOT be leaked from level-1 to level-2. 376 This is to prevent TLV looping across levels. 378 3. A: The originator of the PPR TLV MUST set the A bit in order to 379 signal that the prefixes and PPR-IDs advertised in the PPR TLV 380 are directly connected to the originators. If this bit is not 381 set, this allows any other node in the network advertise this TLV 382 on behalf of the originating node of the PPR-Prefix. If PPR TLV 383 is leaked to other areas/levels the A-flag MUST be cleared. In 384 case if the originating node of the prefix must be disambiguated 385 for any reason including, if it is a Multi Homed Prefix (MHP) or 386 leaked to a different IS-IS level or because [RFC7794] X-Flag is 387 set, then PPR-Attribute Sub-TLV Source Router ID SHOULD be 388 included. 390 4. L: L bit MUST be set if a path has only one fragment or if it is 391 the last Fragment of the path. PPR-ID value for all fragments of 392 the same path MUST be same. 394 5. Reserved: For future use; MUST be set to 0 on transmit and 395 ignored on receive. 397 6. Fragment-ID: This is a 7-bit Identifier value (0-127) of the 398 fragment. If fragments are not needed to represent the complete 399 path, L bit MUST be set and this value MUST be set to 0. 401 The following sub-TLVs draw from a new registry for sub-TLV numbers; 402 this registry is to be created by IANA, and administered using the 403 first come first serve process. 405 3.1. PPR-Prefix Sub-TLV 407 The structure of PPR-Prefix is: 409 0 1 2 3 410 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 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Type | Length | MT-ID | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Prefix Length | Mask Length | IS-IS Prefix | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 // IS-IS Prefix (continued, variable) // 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | PPR-Prefix Sub-TLVs (variable) | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 Figure 3: PPR-Prefix Sub-TLV Format 423 o Type: TBD (IANA to assign from sub-TLV registry described above). 425 o Length: Total length of the value field in bytes. 427 o MT-ID: The multi-topology identifier defined in [RFC5120]; the 4 428 most significant bits MUST be set to 0 on transmit and ignored on 429 receive. The remaining 12-bit field contains the MT-ID. 431 o Prefix Length: The length of the prefix in bytes. For IPv4 it 432 MUST be 4 and IPv6 it MUST be 16 bytes. 434 o Mask Length: The length of the prefix in bits. Only the most 435 significant octets of the Prefix are encoded. 437 o IS-IS Prefix: The IS-IS prefix at the tail-end of the advertised 438 PPR. This corresponds to a routable prefix of the originating 439 node and it MAY have one of the [RFC7794] flags set (X-Flag/R- 440 Flag/N-Flag). Value of this field MUST be 4 octets for IPv4 441 Prefix and MUST be 16 octets for IPv6 Prefix. Encoding is similar 442 to TLV 135 [RFC5305] and TLV 236 [RFC5308] or MT-Capable [RFC5120] 443 IPv4 (TLV 235) and IPv6 Prefixes (TLV 237) respectively. 445 o PPR-Prefix Sub-TLVs - TBD. These have 1 octet type, 1 octet 446 length and value field is defined per the type field. 448 3.2. PPR-ID Sub-TLV 450 This is the actual data plane identifier in the packet header and 451 could be of any data plane as defined in PPR-ID Type field. Both 452 PPR-Prefix and PPR-ID MUST belong to a same node in the network. 454 0 1 2 3 455 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 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Type | Length |PPR-ID Flags | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | PPR-ID Type | PPR-ID Length |PPR-ID Mask Len| Algo | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 // PPR-ID (variable size) // 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 Figure 4: PPR-ID Sub-TLV Format 466 o Type: TBD (IANA to assign from sub-TLV registry described above). 468 o Length: Total length of the value field in bytes. 470 o 472 * PPR-ID Flags: 2 Octet field for PPR-ID flags: 474 o 476 PPR-ID Flags Format 478 0 1 2 3 4 5 6 7.. 15 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 |L|A|Reserved | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 o 485 1. L: If set, the PPR path is a Loose-PPR. If the this flag is 486 unset, then the PPR path is a Strict-PPR. A Strict-PPR lists 487 every single node or adjacency in the path description from 488 source to the destination. 490 2. A: If set, all non-PPR path nodes in the IS-IS area/domain 491 MUST add a FIB entry for the PPR-ID with NH set to the 492 shortest path NH for the prefix being advertised. The use of 493 this is TBD. By default this flag MUST be unset. 495 3. Reserved: For future use; MUST be set to 0 on transmit and 496 ignored on receive. 498 o 499 * PPR-ID Type: Data plane type of PPR-ID. This is a new registry 500 (TBD IANA - Suggested values as below) for this Sub-TLV and the 501 defined types are as follows: 503 o 505 A. Type: 1 MPLS SID/Label 507 B. Type: 2 Native IPv4 Address/Prefix 509 C. Type: 3 Native IPv6 Address/Prefix 511 D. Type: 4 IPv6 SID in SRv6 with SRH 513 o PPR-ID Length: Length of the PPR-ID field in octets and this 514 depends on the PPR-ID type. See PPR-ID below for the length of 515 this field and other considerations. 517 o PPR-ID Mask Length: It is applicable for only for PPR-ID Type 2, 3 518 and 4. For Type 1 this value MUST be set to zero. It contains 519 the length of the PPR-ID Prefix in bits. Only the most 520 significant octets of the Prefix are encoded. This is needed, if 521 PPR-ID followed is an IPv4/IPv6 Prefix instead of 4/16 octet 522 Address respectively. 524 o Algo: 1 octet value represents the SPF algorithm. Algorithm 525 registry is as defined in 526 [I-D.ietf-isis-segment-routing-extensions]. 528 o PPR-ID: This is the Preferred Path forwarding identifier that 529 would be on the data packet. The value of this field is variable 530 and it depends on the PPR-ID Type - for Type 1, this is and MPLS 531 SID/Label. For Type 2 this is a 4 byte IPv4 address. For Type 3 532 this is a 16 byte IPv6 address. For Type 2 and Type 3 encoding is 533 similar to "IS-IS Prefix" as specified in Section 3.1. For Type 534 4, it is a 16 byte IPv6 SID. 536 For PPR-ID Type 2, 3 or 4, if the PPR-ID Len is set to non-zero 537 value, then the PPR-ID MUST NOT be advertised as a routable prefix in 538 TLV 135, TLV 235, TLV 236 and TLV 237. Also PPR-ID MUST belong to 539 the node where Prefix is advertised from. PPR-ID Len = 0 case is a 540 special case and is discussed in Section 4.1. 542 3.3. PPR-PDE Sub-TLV 544 This Sub-TLV represents the PPR Path Description Element (PDE). PPR- 545 PDEs are used to describe the path in the form of set of contiguous 546 and ordered Sub-TLVs, where first Sub-TLV represents (the top of the 547 stack in MPLS data plane or) first node/segment of the path. These 548 set of ordered Sub-TLVs can have both topological elements and non- 549 topological elements (e.g., service segments). 551 0 1 2 3 552 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 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | Type | Length | PPR-PDE Type | Reserved | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | PDE-ID Type | PDE-ID Len | PPR-PDE Flags | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 // PDE-ID Value (continued, variable size) // 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | PPR-PDE Sub-TLVs (variable) | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 Figure 5: PPR-PDE Sub-TLV Format 565 o Type: TBD (See IANA for suggested value) from IS-IS PPR TLV 566 Section 3 Sub-TLV registry. 568 o Length: Total length of the value field in bytes. 570 o PPR-PDE Type: A new registry (TBD IANA) for this Sub-TLV and the 571 defined types are as follows: 573 a. Type: 1 Topological 575 b. Type: 2 Non-Topological 577 o PDE-ID Type: 1 Octet PDE-forwarding IDentifier Type. A new 578 registry (TBD IANA) for this Sub-TLV and the defined types and 579 corresponding PDE-ID Len, PDE-ID Value are as follows: 581 a. Type 1: SID/Label type as defined in 582 [I-D.ietf-isis-segment-routing-extensions]. PDE-ID Len and PDE- 583 ID Value fields are per Section 2.3 of the referenced document. 585 b. Type 2: SR-MPLS Prefix SID. PDE-ID Len and PDE-ID Value are same 586 as Type 1. 588 c. Type 3: SR-MPLS Adjacency SID. PDE-ID Len and PDE-ID Value are 589 same as Type 1. 591 d. Type 4: IPv4 Address. PDE-ID Len is 4 bytes and PDE-ID Value is 592 4 bytes IPv4 address encoded similar to IPv4 Prefix described in 593 Section 3.1. 595 e. Type 5: IPv6 Address. PDE-ID Len is 16 bytes and PDE-ID Value is 596 16 bytes IPv6 address encoded similar to IPv6 Prefix described in 597 Section 3.1. 599 f. Type 6: SRv6 Node SID as defined in 600 [I-D.bashandy-isis-srv6-extensions]. PDE-ID Len and PDE-ID Value 601 are as defined in SRv6 SID from the refrenced draft. 603 g. Type 7: SRv6 Adjacency-SID. PDE-ID Len and PDE-ID Values are 604 similar to SRv6 Node SID above. 606 o PPR-PDE Flags: 2 Octet bit-field of flags; described below: 608 PPR-PDE Flags Format 610 0 1 2 3 4 5 6 7 .. 15 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 |L|D|Reserved | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 1. L: Loose Bit. Indicates the type of next "Topological PDE-ID" in 616 the path description and overrides the L bit in Section 3.2. If 617 set, the next PDE is Loose. If this flag is unset, the next 618 Topological PDE is Strict Type. 620 2. D: Destination bit. By default this bit MUST be unset. This bit 621 MUST be set only for PPR-PDE Type is 1 i.e., Topological and this 622 PDE represents the node PPR-Prefix Section 3.1 belongs to, if 623 there is no sub-sub-TLV to override PPR-Prefix and PPR-ID values. 625 3. Reserved: 1 Octet reserved bits for future use. Reserved bits 626 MUST be reset on transmission and ignored on receive. 628 o PPR-PDE Sub-TLVs: TBD. These have 1 octet type, 1 octet length 629 and value field is defined per the type field. 631 3.4. PPR-Attributes Sub-TLV 633 PPR-Attribute Sub-TLVs describe the attributes of the path. The 634 following sub-TLVs draw from a new registry for sub-TLV numbers; this 635 registry is to be created by IANA, and administered using the first 636 come first serve process: 638 o Type 1 (Suggested Value - IANA TBD): Packet Traffic accounting 639 Sub-TLV. Length 0 and no value field. Specifies to create a 640 counter to count number of packets forwarded on this PPR-ID on 641 each node in the path description. 643 o Type 2 (Suggested Value - IANA TBD): Traffic statistics in Bytes 644 Sub-TLV. Length 0 and no value field. Specifies to create a 645 counter to count number of bytes forwarded on this PPR-ID 646 specified in the network header (e.g. IPv4, IPv6) on each node in 647 the path description. 649 o Type 3 (Suggested Value - IANA TBD): PPR-Prefix originating node's 650 IPv4 Router ID Sub-TLV. Length and Value field are as specified 651 in [RFC7794]. 653 o Type 4 (Suggested Value - IANA TBD): PPR-Prefix originating node's 654 IPv6 Router ID Sub-TLV. Length and Value field are as specified 655 in [RFC7794]. 657 o Type 5 (Suggested Value - IANA TBD): PPR-Metric Sub-TLV. Length 4 658 bytes, and Value is metric of this path represented through the 659 PPR-ID. Different nodes can advertise the same PPR-ID for the 660 same Prefix with a different set of PPR-PDE Sub-TLVs and the 661 receiving node MUST consider the lowest metric value (TBD more, on 662 what happens when metric is same for two different set of PPR-PDE 663 Sub-TLVs). 665 4. PPR Processing Procedure Example 667 As specified in Section 2, a PPR can be a TE path, locally 668 provisioned by the operator or by a controller. Consider the 669 following IS-IS network to describe the operation of PPR TLV as 670 defined in Section 3: 672 1 673 _______ 674 / 1 \ 675 +---R2-------R3---+ 676 / \_______/ \ 677 / 1 \ 678 1 / \ 1 679 / 1__R13__1 \ 680 / / \ \ 681 R1------R6 R7-----------R4 682 \ 2 \__R14__/ 2 /\ 683 \ 2 2 / \ 684 3 \ / 3 \1 685 \ 4 / \ 686 +----R8------R9-----R10------R12 687 \ 1 / 688 1 \ / 1 689 +----R11---+ 691 Figure 6: IS-IS Network 693 In the (Figure 6) shown, consider node R1 as an ingress node, or a 694 head-end node, and the node R4 MAY be an egress node or another head- 695 end node. The numbers shown on links between nodes R1-R14 indicate 696 the bi-directional IS-IS metric as provisioned. R1 may be configured 697 to receive TE source routed path information from a central entity 698 (PCE [RFC5440], Netconf [RFC6241] or a Controller) that comprises of 699 PPR information which relates to sources that are attached to R1. It 700 is also possible to have a PPR provisioned locally by the operator 701 for non-TE needs (FRR or for chaining certain services). 703 The PPR TLV (as specified in Section 3) is encoded as an ordered list 704 of PPR-PDEs from source to a destination node in the network and is 705 represented with a PPR-ID Section 3.2. The PPR TLV includes PPR-PDE 706 Sub-TLVS Section 3.3, which represent both topological and non- 707 topological elements and specifies the actual path towards a PPR- 708 Prefix at R4. 710 o The shortest path towards R4 from R1 are through the following 711 sequence of nodes: R1-R2-R3-R4 based on the provisioned metrics. 713 o The central entity can define a few PPRs from R1 to R4 that 714 deviate from the shortest path based on other network 715 characteristic requirements as requested by an application or 716 service. For example, the network characteristics or performance 717 requirements may include bandwidth, jitter, latency, throughput, 718 error rate, etc. 720 o A first PPR may be identified by PPR-ID = 1 (value) and may 721 include the path of R1-R6-R7-R4 for a Prefix advertised by R4. 722 This is an example for a Loose-PPR and 'L' bit MUST be set on 723 Section 3.2. 725 o A second PPR may be identified by PPR-ID = 2 (value) and may 726 include the path of R1-R8-R9-R10-R4. This is an example for a 727 Strict-PPR and 'L' bit MUST be unset on Section 3.2. Though this 728 example shows PPR with all nodal SIDs, it is possible to have a 729 PPR with combination of node and adjacency SIDs (local or global) 730 or with PPR-PDE Type set to Non-Topological as defined in 731 Section 3.3 elements along with these. 733 4.1. PPR TLV Processing 735 The first topological sub-object or PDE (Section 3.3) relative to the 736 beginning of PPR Path contains the information about the first node 737 (e.g. in SR-MPLS it's the topmost label). The last topological sub- 738 object or PDE contains information about the last node (e.g. in SR- 739 MPLS it's the bottommost label). 741 Each receiving node, determines whether an advertised PPR includes 742 information regarding the receiving node. Before processing any 743 further, validation MUST be done to see if any PPR topological PDE is 744 seen more than once (possible loop), if yes, this PPR TLV MUST be 745 ignored. Processing of PPR TLVs can be done, during the end of the 746 SPF computation (for MTID that is advertised in this TLV) and for the 747 each prefix described through PPR TLV. For example, node R9 receives 748 the PPR information, and ignores the PPR-ID=1 (Section 4) because 749 this PPR TLV does not include node R9 in the path description/ordered 750 PPR-PDE list. 752 However, node R9 may determine that the second PPR identified by PPR- 753 ID = 2 does include the node R9 in its PDE list. Therefore, node R9 754 updates the local forwarding database to include an entry for the 755 destination address of R4 indicates, that when a data packet 756 comprising a PPR-ID of 2 is received, forward the data packet to node 757 R10 instead of R11. This is even though from R9 the shortest path to 758 reach R4 via R11 (Cost 3: R9-R11-R12-R4) it chooses the nexthop to 759 R10 to reach R4 as specified in the PPR path description. Same 760 process happens to all nodes or all topological PDEs as described in 761 the PPR TLV. 763 In summary, the receiving node checks first, if this node is on the 764 path by checking the node's topological elements (with PPR-PDE Type 765 set to Topological) in the path list. If yes, it adds/adjusts the 766 shortest path nexthop computed towards PPR Prefix to the shortest 767 path nexthop towards the next topological PDE in the PPR's Path. 769 For PPR-ID (Section 3.2) Type 2, 3 or 4, if the PPR-ID Len is set to 770 0, then Prefix would also become the PPR-ID (a special case). This 771 can be used for some situations, where certain optimizations are 772 required in the network. For this, path described in the PPR TLV 773 SHOULD be completely dis-joint from the shortest path route to the 774 prefix. If the disjoint-ness property is not maintained then the 775 traffic MAY not be using the PPR path, as and when it encounters any 776 node which is not in the path description. 778 4.2. Path Fragments 780 A complete PPR path may not fit into maximum allowable size of the 781 IS-IS TLV. To overcome this a 7 bit Fragment-ID field is defined in 782 Section 3 . With this, a single PPR path is represented via one or 783 more fragmented PPR path TLVs, with all having the same PPR-ID. Each 784 fragment carries the PPR-ID as well as a numeric Fragment-ID from 0 785 to (N-1), when N fragments are needed to describe the PPR Graph 786 (where N>1). In this case Fragment (N-1) MUST set the L bit to 787 indicate it is the last fragment. If Fragment-ID is non zero in the 788 TLV, then it MUST not carry PPR-Prefix Sub-TLV. The optional PPR 789 Attribute Sub-TLVs which describe the path overall MUST be included 790 in the last fragment only (i.e., when the L bit is set). 792 5. PPR Data Plane aspects 794 Data plane for PPR-ID is selected by the entity (e.g., a controller, 795 locally provisioned by operator), which selects a particular PPR in 796 the network. Section 3.2 defines various data plane identifier types 797 and a corresponding data plane identifier is selected by the entity 798 which selects the PPR. Other data planes other than described below 799 can also use this TLV to describe the PPR. Further details TBD. 801 5.1. SR-MPLS with PPR 803 If PPR-ID Type is 1, then the PPR belongs to SR-MPLS data plane and 804 the complete PPR stack is represented with a unique SR SID/Label and 805 this gets programmed on the data plane of each node, with the 806 appropriate nexthop computed as specified in Section 4. PPR-ID here 807 is a label/index from the SRGB (like another node SID or global ADJ- 808 SID). PPR path description here is a set of ordered SIDs represented 809 with PPR-PDE (Section 3.2) Sub-TLVs. Non-Topological segments also 810 programmed in the forwarding to enable specific function/service, 811 when the data packet hits with corresponding PPR-ID. 813 Based on 'L' flag in PPR-ID Flags (Section 3.2), for SR-MPLS data 814 plane either 1 label or 2 labels need to be provisioned on individual 815 nodes on the path description. For the example network in Section 4, 816 for PPR-ID=1, which is a loose path, node R6 programs the bottom 817 label as PPR-ID and the top label as the next topological PPR-PDE in 818 the path, which is a node SID of R7. The NH computed at R6 would be 819 the shortest path towards R7 i.e., the interface towards R13. If 'L' 820 flag is unset only PPR-ID is programmed on the data plane with NH set 821 to the shortest path towards next topological PPR-PDE. 823 5.2. SRv6 with PPR 825 If PPR-ID Type is 4, the PPR belongs to SRv6 with SRH data plane and 826 the complete PPR stack is represented with IPv6 SIDs and this gets 827 programmed on the data plane with the appropriate nexthop computed as 828 specified in Section 4. PPR-ID here is a SRv6 SID. PPR path 829 description here is a set of ordered SID TLVs similar to as specified 830 in Section 5.1. One way PPR-ID would be used in this case is by 831 setting the same as the destination IPv6 address and SL field in SRH 832 would be set to 0; however SRH [I-D.ietf-6man-segment-routing-header] 833 can contain any other TLVs and non-topological SIDs as needed. 835 5.3. PPR Native IP Data Planes 837 If PPR-ID Type is 2 then source routing and packet steering can be 838 done in IPv4 data plane (PPR-IPv4), along the path as described in 839 PPR Path description. This is achieved by setting the destination IP 840 address as PPR-ID, which is an IPv4 address in the data packet 841 (tunneled/encapsulated). There is no data plane change or upgrade 842 needed to support this. However this is applicable to only Strict- 843 PPR paths ('L' bit as specified in Section 3.2 MUST be unset). 845 Similarly for PPR-ID Type is 3, then source routing and packet 846 steering can be done in IPv6 data plane (PPR-IPv6), along the path as 847 described in PPR Path description. Whatever specified above for IPv4 848 applies here too, except that destination IP address of the data 849 packet is IPv6 Address (PPR-ID). This doesn't require any IPv6 850 extension headers (EH), if there is no metadata/TLVs need to be 851 carried in the data packet. 853 6. PPR Scaling Considerations 855 In a network of N nodes O(N^2) total (unidirectional) paths are 856 necessary to establish any-to-any connectivity, and multiple (k) such 857 path sets may be desirable if multiple path policies are to be 858 supported (lowest latency, highest throughput etc.). 860 In many solutions and topologies, N may be small enough and/or only a 861 small set of paths need to be preferred paths, for example for high 862 value traffic (DetNet, some of the defined 5G slices), and then the 863 technology specified in this document can support these deployments. 865 However, to address the scale needed when a larger number of PPR 866 paths are required, the PPR TREE structure can be used [I-D.draft-ce- 867 ppr-graph-00]. Each PPR Tree uses one label/SID and defines paths 868 from any set of nodes to one destination, thus reduces the number of 869 entries needed in SRGB at each node (for SR-MPLS data plane 870 Section 5.1). These paths form a tree rooted in the destination. In 871 other word, PPR Tree identifiers are destination identifiers and PPR 872 Treed are path engineered destination routes (like IP routes) and it 873 scaling simplifies to linear in N i.e., O(k*N). 875 7. PPR Traffic Accounting 877 Section 3.4 defines few PPR-Attributes to indicate creation of 878 traffic accounting statistics in each node of the PPR path 879 description. Presence of "Packet Traffic Accounting" and "Traffic 880 Statistics" Sub-TLVs instruct to provision the hardware, to account 881 for the respective traffic statistics. Traffic accounting should 882 happen, when the actual data traffic hits for the PPR-ID in the 883 forwarding plane. This allows more granular and dynamic enablement 884 of traffic statistics for only certain PPRs as needed. 886 This approach, thus is more safe and secure than any mechanism that 887 involves creation of the state in the nodes with the data traffic 888 itself. This is because, creation and deletion of the traffic 889 accounting state for PPRs happen through IS-IS LSP processing and IS- 890 IS protocol control plane security Section 10 options are applicable 891 to this TLV. 893 How the traffic accounting is distributed to a central entity is out 894 of scope of this document. One can use any method (e.g. gRPC) to 895 extract the PPR-ID traffic stats from various nodes along the path. 897 8. Acknowledgements 899 Thanks to Alex Clemm, Lin Han, Toerless Eckert, Stewart Bryant and 900 Kiran Makhijani for initial discussions on this topic. Thanks to 901 Kevin Smith and Stephen Johnson for various deployment scenarios 902 applicability from ETSI WGs perspective. Authors also acknowledge 903 Alexander Vainshtein for detailed discussions and few suggestions on 904 this topic. 906 Earlier versions of draft-ietf-isis-segment-routing-extensions have a 907 mechanism to advertise EROs through Binding SID. 909 9. IANA Considerations 911 This document requests the following new TLV in IANA IS-IS TLV code- 912 point registry. 914 TLV # Name 915 ----- -------------- 916 TBD PPR TLV 918 This document requests IANA to create a new Sub-TLV registry for PPR 919 TLV Section 3 with the following initial entries (suggested values): 921 Sub-TLV # Sub-TLV Name 922 --------- --------------------------------------------------------- 924 1 PPR-Prefix (Section 3.1) 926 2 PPR-ID (Section 3.2) 928 3 PPR-PDE (Section 3.3) 930 This document also requests IANA to create a new Sub-TLV registry for 931 PPR Path attributes with the following initial entries (suggested 932 values): 934 Sub-TLV # Sub-TLV Name 935 --------- --------------------------------------------------------- 937 1 Packet Traffic Accounting (Section 3.4) 939 2 Traffic Statistics (Section 3.4) 941 3 PPR-Prefix Source IPv4 Router ID (Section 3.4) 943 4 PPR-Prefix Source IPv6 Router ID (Section 3.4) 945 5 PPR-Metric (Section 3.4) 947 This document requests additional IANA registries in an IANA managed 948 registry "Interior Gateway Protocol (IGP) Parameters" for various PPR 949 TLV parameters. The registration procedure is based on the "Expert 950 Review" as defined in [RFC8126]. The suggested registry names are: 952 o "PPR-Type" - Types are an unsigned 8 bit numbers. Values are as 953 defined in Section 3 of this document. 955 o "PPR-Flags" - 1 Octet. Bits as described in Section 3 of this 956 document. 958 o "PPR-ID Type" - Types are an unsigned 8 bit numbers. Values are 959 as defined in Section 3.2 of this document. 961 o "PPR-ID Flags" - 1 Octet. Bits as described in Section 3.2 of 962 this document. 964 o "PPR-PDE Type" - Types are an unsigned 8 bit numbers. Values are 965 as defined in Section 3.3 of this document. 967 o "PPR-PDE Flags" - 1 Octet. Bits as described in Section 3.3 of 968 this document. 970 o "PDE-ID Type" - Types are an unsigned 8 bit numbers. Values are 971 as defined in Section 3.3 of this document. 973 10. Security Considerations 975 Security concerns for IS-IS are addressed in [RFC5304] and [RFC5310]. 976 Further security analysis for IS-IS protocol is done in [RFC7645] 977 with detailed analysis of various security threats and why [RFC5304] 978 should not be used in the deployments. Advertisement of the 979 additional information defined in this document introduces no new 980 security concerns in IS-IS protocol. However as this extension is 981 related to SR-MPLS and SRH data planes as defined in 982 [I-D.ietf-spring-segment-routing], those particular data plane 983 security considerations does apply here. 985 11. References 987 11.1. Normative References 989 [I-D.ietf-isis-segment-routing-msd] 990 Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 991 "Signaling MSD (Maximum SID Depth) using IS-IS", draft- 992 ietf-isis-segment-routing-msd-19 (work in progress), 993 October 2018. 995 [I-D.ietf-spring-segment-routing] 996 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 997 Litkowski, S., and R. Shakir, "Segment Routing 998 Architecture", draft-ietf-spring-segment-routing-15 (work 999 in progress), January 2018. 1001 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1002 Requirement Levels", BCP 14, RFC 2119, 1003 DOI 10.17487/RFC2119, March 1997, 1004 . 1006 11.2. Informative References 1008 [I-D.bashandy-isis-srv6-extensions] 1009 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 1010 Z. Hu, "IS-IS Extensions to Support Routing over IPv6 1011 Dataplane", draft-bashandy-isis-srv6-extensions-04 (work 1012 in progress), October 2018. 1014 [I-D.cheng-spring-mpls-path-segment] 1015 Cheng, W., Wang, L., Li, H., Chen, M., Gandhi, R., Zigler, 1016 R., and S. Zhan, "Path Segment in MPLS Based Segment 1017 Routing Network", draft-cheng-spring-mpls-path-segment-03 1018 (work in progress), October 2018. 1020 [I-D.hegde-spring-traffic-accounting-for-sr-paths] 1021 Hegde, S., "Traffic Accounting for MPLS Segment Routing 1022 Paths", draft-hegde-spring-traffic-accounting-for-sr- 1023 paths-02 (work in progress), October 2018. 1025 [I-D.ietf-6man-segment-routing-header] 1026 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 1027 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 1028 (SRH)", draft-ietf-6man-segment-routing-header-16 (work in 1029 progress), February 2019. 1031 [I-D.ietf-isis-mpls-elc] 1032 Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S. 1033 Litkowski, "Signaling Entropy Label Capability and Entropy 1034 Readable Label Depth Using IS-IS", draft-ietf-isis-mpls- 1035 elc-06 (work in progress), September 2018. 1037 [I-D.ietf-isis-segment-routing-extensions] 1038 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 1039 Gredler, H., and B. Decraene, "IS-IS Extensions for 1040 Segment Routing", draft-ietf-isis-segment-routing- 1041 extensions-22 (work in progress), December 2018. 1043 [I-D.ietf-mpls-sfc] 1044 Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based 1045 Forwarding Plane for Service Function Chaining", draft- 1046 ietf-mpls-sfc-05 (work in progress), February 2019. 1048 [I-D.xuclad-spring-sr-service-chaining] 1049 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 1050 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 1051 Henderickx, W., and S. Salsano, "Segment Routing for 1052 Service Chaining", draft-xuclad-spring-sr-service- 1053 chaining-01 (work in progress), March 2018. 1055 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1056 Topology (MT) Routing in Intermediate System to 1057 Intermediate Systems (IS-ISs)", RFC 5120, 1058 DOI 10.17487/RFC5120, February 2008, 1059 . 1061 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 1062 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 1063 2008, . 1065 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1066 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1067 2008, . 1069 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 1070 DOI 10.17487/RFC5308, October 2008, 1071 . 1073 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 1074 and M. Fanto, "IS-IS Generic Cryptographic 1075 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 1076 2009, . 1078 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1079 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1080 DOI 10.17487/RFC5440, March 2009, 1081 . 1083 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1084 and A. Bierman, Ed., "Network Configuration Protocol 1085 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1086 . 1088 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 1089 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 1090 RFC 6790, DOI 10.17487/RFC6790, November 2012, 1091 . 1093 [RFC7645] Chunduri, U., Tian, A., and W. Lu, "The Keying and 1094 Authentication for Routing Protocol (KARP) IS-IS Security 1095 Analysis", RFC 7645, DOI 10.17487/RFC7645, September 2015, 1096 . 1098 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 1099 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 1100 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 1101 March 2016, . 1103 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1104 Writing an IANA Considerations Section in RFCs", BCP 26, 1105 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1106 . 1108 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1109 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1110 May 2017, . 1112 Authors' Addresses 1114 Uma Chunduri 1115 Huawei USA 1116 2330 Central Expressway 1117 Santa Clara, CA 95050 1118 USA 1120 Email: uma.chunduri@huawei.com 1122 Richard Li 1123 Huawei USA 1124 2330 Central Expressway 1125 Santa Clara, CA 95050 1126 USA 1128 Email: renwei.li@huawei.com 1130 Russ White 1131 Juniper Networks 1132 Oak Island, NC 28465 1133 USA 1135 Email: russ@riw.us 1136 Jeff Tantsura 1137 Apstra Inc. 1138 333 Middlefield Road 1139 Menlo Park, CA 94025 1140 USA 1142 Email: jefftant.ietf@gmail.com 1144 Luis M. Contreras 1145 Telefonica 1146 Sur-3 building, 3rd floor 1147 Madrid 28050 1148 Spain 1150 Email: luismiguel.contrerasmurillo@telefonica.com 1152 Yingzhen Qu 1153 Huawei USA 1154 2330 Central Expressway 1155 Santa Clara, CA 95050 1156 USA 1158 Email: yingzhen.qu@huawei.com