idnits 2.17.00 (12 Aug 2021) /tmp/idnits29651/draft-chunduri-lsr-isis-preferred-path-routing-00.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 -- The document date (June 18, 2018) is 1433 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: draft-ietf-isis-segment-routing-msd has been published as RFC 8491 == Outdated reference: draft-ietf-spring-segment-routing has been published as RFC 8402 == Outdated reference: A later version (-05) exists of draft-bashandy-isis-srv6-extensions-02 == Outdated reference: A later version (-03) exists of draft-cheng-spring-mpls-path-segment-01 == Outdated reference: A later version (-02) exists of draft-hegde-spring-traffic-accounting-for-sr-paths-01 == Outdated reference: draft-ietf-6man-segment-routing-header has been published as RFC 8754 == Outdated reference: draft-ietf-isis-mpls-elc has been published as RFC 9088 == Outdated reference: draft-ietf-isis-segment-routing-extensions has been published as RFC 8667 == Outdated reference: draft-ietf-mpls-sfc has been published as RFC 8595 Summary: 0 errors (**), 0 flaws (~~), 11 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: December 20, 2018 R. White 6 LinkedIn 7 J. Tantsura 8 Nuage Networks 9 L. Contreras 10 Telefonica 11 Y. Qu 12 Huawei USA 13 June 18, 2018 15 Preferred Path Routing (PPR) in IS-IS 16 draft-chunduri-lsr-isis-preferred-path-routing-00 18 Abstract 20 This document specifies a Preferred Path Routing (PPR) mechanism to 21 simplify the path description of data plane traffic in Segment 22 Routing (SR) deployments. PPR aims to mitigate the MTU and data 23 plane processing issues that may result from SR packet overheads; and 24 also supports traffic measurement, accounting statistics and further 25 attribute extensions along the paths. Preferred Path Routing is 26 achieved through the addition of descriptions to IS-IS advertised 27 prefixes, and mapping those to a PPR data-plane identifier. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC2119 [RFC2119], 34 RFC8174 [RFC8174] when, and only when they appear in all capitals, as 35 shown here. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on December 20, 2018. 54 Copyright Notice 56 Copyright (c) 2018 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 73 1.2. Challenges with Increased SID Depth . . . . . . . . . . . 4 74 1.3. Mitigation with MSD . . . . . . . . . . . . . . . . . . . 5 75 2. Preferred Path Routing (PPR) . . . . . . . . . . . . . . . . 6 76 2.1. PPR-ID and PPR Path Description . . . . . . . . . . . . . 6 77 3. PPR Related TLVs . . . . . . . . . . . . . . . . . . . . . . 7 78 3.1. PPR-Prefix Sub-TLV . . . . . . . . . . . . . . . . . . . 9 79 3.2. PPR-ID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 9 80 3.3. PPR-PDE Sub-TLV . . . . . . . . . . . . . . . . . . . . . 11 81 3.4. PPR-Attributes Sub-TLV . . . . . . . . . . . . . . . . . 13 82 4. PPR Processing Procedure Example . . . . . . . . . . . . . . 14 83 4.1. PPR TLV Processing . . . . . . . . . . . . . . . . . . . 16 84 5. PPR Data Plane aspects . . . . . . . . . . . . . . . . . . . 17 85 5.1. SR-MPLS with PPR . . . . . . . . . . . . . . . . . . . . 17 86 5.2. SRv6 with PPR . . . . . . . . . . . . . . . . . . . . . . 17 87 5.3. PPR Native IP Data Planes . . . . . . . . . . . . . . . . 18 88 6. PPR Traffic Accounting . . . . . . . . . . . . . . . . . . . 18 89 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 90 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 91 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 93 10.1. Normative References . . . . . . . . . . . . . . . . . . 20 94 10.2. Informative References . . . . . . . . . . . . . . . . . 21 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 97 1. Introduction 99 In a network implementing Segment Routing (SR), packets are steered 100 through the network using Segment Identifiers (SIDs) carried in the 101 packet header. Each SID uniquely identifies a segment as defined in 102 [I-D.ietf-spring-segment-routing]. SR capabilities are defined for 103 MPLS and IPv6 data planes called SR-MPLS and SRv6 respectively. 105 In SR-MPLS, each segment is encoded as a label, and an ordered list 106 of segments are encoded as a stack of labels. This stack of labels 107 is carried as part of the packet header. In SRv6, a segment is 108 encoded as an IPv6 address, within a new type of IPv6 hop-by-hop 109 routing header/extension header (EH) called SRH 110 [I-D.ietf-6man-segment-routing-header]; an ordered list of IPv6 111 addresses/segments are encoded in SRH. 113 Section 1.2 and Section 1.3 describe performance, hardware 114 capabilities and various associated issues which may result in SR 115 deployments. These motivate the proposed solution, Preferred Path 116 Routing, which is specified in Section 2. 118 1.1. Acronyms 120 EL - Entropy Label 122 ELI - Entropy Label Indicator 124 LSP - IS-IS Link State PDU 126 MPLS - Multi Protocol Label Switching 128 MSD - Maximum SID Depth 130 MTU - Maximum Transferrable Unit 132 PPR - Preferred Path Routing/Route 134 PPR-ID - Preferred Path Route Identifier, a data plane identifier 136 SID - Segment Identifier 138 SPF - Shortest Path First 140 SR-MPLS - Segment Routing with MPLS data plane 142 SRH - Segment Routing Header - IPv6 routing Extension headr 144 SRv6 - Segment Routing with Ipv6 data plane with SRH 145 TE - Traffic Engineering 147 1.2. Challenges with Increased SID Depth 149 SR label stacks carried in the packet header create challenges in the 150 design and deployment of networks and networking equipment. 151 Following examples illustrates the need for increased SID depth in 152 various use cases: 154 (a). Consider the following network where SR-MPLS data plane is in 155 use and with same SRGB (5000-6000) on all nodes i.e., A1 to A7 and B1 156 to B7 for illustration: 158 SID:10 SID:20 SID:30 SID:40 SID:50 SID:300(Ax) SID:60 SID:70 159 A1-------A2-------A3-------A4-------A5===============A6----------A7 160 \ / \5 5/ \ SID:310(Ay) \ / 161 \ 10 10/ +-A10-+ \ \10 /10 162 \ / SID:100 \ \ / 163 SID:80 \A8-----A9/SID:90 \ 40 \ / 164 / \ +---+ \ / 165 /10 B2x:125 \10 \ \/ 166 B1--------B2============B3----B4--------B5-------B6----------B7 167 SID:110 SID:120 SID:130 SID:140 SID:150 SID:160 SID:170 169 Figure 1: SR-MPLS Network 171 Global ADJ SIDs are provisioned between A5-A6 and B2-B3. All 172 other SIDs shown are nodal SID indices. 174 All metrics of the links are set to 1, unless marked otherwise. 176 Shortest Path from A1 to A7: A2-A3-A4-A5-A6-A7 178 Path-x: From A1 to A7 - A2-A8-B2-B2x-A9-A10-Ax-A7; Pushed Label 179 Stack @A1: 5020:5080:5120:5125:5090:5100:5300:5070 (where B2x is a 180 local ADJ-SID and Ax is a global ADJ-SID). 182 In this example, the traffic engineered path is represented with a 183 combination of Adjacency and Node SIDs with a stack of 8 labels. 184 However, this value can be larger, if the use of entropy label 185 [RFC6790] is desired and based on the Readable Label Depth 186 (Section 1.3) capabilities of each node and additional labels 187 required to insert ELI/EL at appropriate places. 189 Though above network is shown with SR-MPLS data plane, if the 190 network were to use SR-IPv6 data plane, path size would be 191 increased even more because of the size of the IPv6 SID (16 bytes) 192 in SRH. 194 (b). Apart from the TE case above, when deploying 195 [I-D.ietf-mpls-sfc] or [I-D.xuclad-spring-sr-service-chaining], with 196 the inclusion of services, or non-topological segments on the label 197 stack, can also make the size of the stack much larger. 199 (c). Some SR-MPLS deployments need accounting statistics for path 200 monitoring and traffic re-optimizations. 201 [I-D.hegde-spring-traffic-accounting-for-sr-paths] and 202 [I-D.cheng-spring-mpls-path-segment] propose solutions with various 203 forms of path segments (either with special labels or PATH segment 204 encoded at the bottom of the stack respectively). However, these 205 proposals further increases the depth of SID stack, when it is 206 compounded with MSD/RLDs of various nodes in the path. 208 Overall the additional path overhead in various SR deployments may 209 cause the following issues: 211 a. HW Capabilities: Not all nodes in the path can support the 212 ability to push or read label stack needed 213 [I-D.ietf-isis-segment-routing-msd] to satisfy user/operator 214 requirements, Alternate paths which meet these user/operator 215 requirements may not be available. 217 b. Line Rate: Potential performance issues in deployments, which use 218 SRH data plane with the increased size of the SRH with 16 byte 219 SIDs. 221 c. MTU: Larger SID stacks on the data packet can cause potential 222 MTU/fragmentation issues. 224 d. Header Tax: Some deployments, such as 5G, require minimal packet 225 overhead in order to conserve network resources. Carrying 40 or 226 50 octets of data in a packet with hundreds of octet of header 227 would be an unacceptable use of available bandwidth. 229 With the solution proposed in this document (Section 5) and 230 Section 4), for Path-x in the example network Figure 1 above, SID 231 stack would be reduced from 8 SIDs to a single SID. 233 1.3. Mitigation with MSD 235 The number of SIDs in the stack a node can impose is referred as 236 Maximum SID Depth (MSD) capability 237 [I-D.ietf-isis-segment-routing-msd], which must be taken into 238 consideration when computing a path to transport a data packet in a 239 network implementing segment routing. [I-D.ietf-isis-mpls-elc] 240 defines another MSD type, Readable Label Depth (RLD) that is used by 241 a head-end to insert Entropy Label pair (ELI/EL) at appropriate 242 depth, so it could be read by transit nodes. There are situations 243 where the source routed path can be excessive as path represented by 244 SR SIDs need to describe all the nodes and ELI/EL based on the 245 readability of the nodes in that path. 247 MSDs (and RLD type) capabilities advertisement help mitigate the 248 problem for a central entity to create the right source routed path 249 per application/operator requirements. However the availability of 250 actual paths meeting these requirements are still limited by the 251 underlying hardware and their MSD capabilities in the data path. 253 2. Preferred Path Routing (PPR) 255 PPR mitigates the issues described in Section 1.2, while continuing 256 to allow the direction of traffic along an engineered path through 257 the network by replacing the label stack with a PPR-ID. The PPR-ID 258 can either be a single label or a native destination address. To 259 facilitate the use of a single label to describe an entire path, a 260 new TLV is added to IS-IS, as described below in Section 3. 262 A PPR could be an SR path, a traffic engineered path computed based 263 on some constraints, an explicitly provisioned Fast Re-Route (FRR) 264 path or a service chained path. A PPR can be signaled by any node, 265 computed by a central controller, or manually configured by an 266 operator. PPR extends the source routing and path steering 267 capabilities to native IP (IPv4 and IPv6) data planes without 268 hardware upgrades; see Section 5. 270 2.1. PPR-ID and PPR Path Description 272 The PPR-ID describes a path through the network. For SR- MPLS this 273 is an MPLS Label/SID and for SRv6 this is an IPv6-SID. For native IP 274 data planes this is either IPv4 or IPv6 address/prefix. 276 The path identified by the PPR-ID is described as a set of Path 277 Description Elements (PDEs), each of which represents a segment of 278 the path. Each node determines location in the path as described, 279 and forwards to the next segment/hop or label of the path description 280 (see the Forwarding Procedure Example later in this document). 282 These PPR-PDEs as defined in Section 3.3, like SR SIDs, can represent 283 topological elements like links/nodes, backup nodes, as well as non- 284 topological elements such as a service, function, or context on a 285 particular node. PPR-PDE optionally, can also have more information 286 as described with in their Sub-TLVs. 288 A PPR path can be described as a Strict-PPR or a Loose-PPR. In a 289 Strict-PPR all nodes/links on the path are described with SR SIDs for 290 SR data planes or IPv4/IPV6 addresses for native IP data planes. In 291 a Loose-PPR only some of the nodes/links from source to destination 292 are described. More specifics and restrictions around Strict/Loose 293 PPRs are described in respective data planes in Section 5. Each PDE 294 is described as either an MPLS label towards the next hop in MPLS 295 enabled networks, or as an IP next hop, in the case of either 296 "plain"/"native" IP or SRv6 enabled networks. A PPR path is related 297 to a set of PDEs using the following TLVs. 299 3. PPR Related TLVs 301 This section describes the encoding of PPR TLV. This TLV can be seen 302 as having 4 logical section viz., encoding of the PPR-Prefix (IS-IS 303 Prefix), encoding of PPR-ID, encoding of path description with an 304 ordered PDE Sub-TLVs and a set of optional PPR attribute Sub-TLVs, 305 which can be used to describe one or more parameters of the path. 306 Multiple instances of this TLV MAY be advertised in IS-IS LSPs with 307 different PPR-ID Type and with corresponding PDE Sub-TLVS. The PPR 308 TLV has Type TBD (suggested value xxx), and has the following format: 310 0 1 2 3 311 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 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Type | Length | PPR-Flags | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | PPR-Prefix Sub-TLV (variable size) | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | PPR-ID Sub-TLV (variable size) | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | PPR-PDE Sub-TLVs (variable) | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | PPR-Attribute Sub-TLVs (variable) | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 Figure 2: PPR TLV Format 326 o Type: TBD (IANA) from IS-IS top level TLV registry. 328 o Length: Total length of the value field in bytes. 330 o PPR-Flags: 2 Octet bit-field of flags for this TLV; described 331 below. 333 o PPR-Prefix: A variable size sub-TLV representing the destination 334 of the path being described. This is defined in Section 3.1. 336 o PPR-ID: A variable size Sub-TLV representing the data plane or 337 forwarding identifier of the PPR. Defined in Section 3.2. 339 o PPR-PDEs: Variable number of ordered PDE Sub-TLVs which represents 340 the path. This is defined in Section 3.3. 342 o PPR-Attributes: Variable number of PPR-Attribute Sub-TLVs which 343 represent the path attributes. These are defined in Section 3.4. 345 The Flags field has the following flag bits defined: 347 PPR TLV Flags Format 349 0 1 2 3 4 5 6 7 15 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 |S|D|A| Reserved | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 1. S: If set, the PPR TLV MUST be flooded across the entire routing 355 domain. If the S flag is not set, the PPR TLV MUST NOT be leaked 356 between IS-IS levels. This bit MUST NOT be altered during the 357 TLV leaking 359 2. D: When the PPR TLV is leaked from IS-IS level-2 to level-1, the 360 D bit MUST be set. Otherwise, this bit MUST be clear. PPR TLVs 361 with the D bit set MUST NOT be leaked from level-1 to level-2. 362 This is to prevent TLV looping across levels. 364 3. A: The originator of the PPR TLV MUST set the A bit in order to 365 signal that the prefixes and PPR-IDs advertised in the PPR TLV 366 are directly connected to the originators. If this bit is not 367 set, this allows any other node in the network advertise this TLV 368 on behalf of the originating node of the PPR-Prefix. If PPR TLV 369 is leaked to other areas/levels the A-flag MUST be cleared. In 370 case if the originating node of the prefix must be disambiguated 371 for any reason including, if it is a Multi Homed Prefix (MHP) or 372 leaked to a different IS-IS level or because [RFC7794] X-Flag is 373 set, then PPR-Attribute Sub-TLV Source Router ID SHOULD be 374 included. 376 4. Reserved: For future use; MUST be set to 0 on transmit and 377 ignored on receive. 379 The following sub-TLVs draw from a new registry for sub-TLV numbers; 380 this registry is to be created by IANA, and administered using the 381 first come first serve process. 383 3.1. PPR-Prefix Sub-TLV 385 The structure of PPR-Prefix is: 387 0 1 2 3 388 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 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Type | Length | MT-ID | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Prefix Length | Mask Length | IS-IS Prefix | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 // IS-IS Prefix (continued, variable) // 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | PPR-Prefix Sub-TLVs (variable) | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 Figure 3: PPR-Prefix Sub-TLV Format 401 o Type: TBD (IANA to assign from sub-TLV registry described above). 403 o Length: Total length of the value field in bytes. 405 o MT-ID: The multi-topology identifier defined in [RFC5120]; the 4 406 most significant bits MUST be set to 0 on transmit and ignored on 407 receive. The remaining 12-bit field contains the MT-ID. 409 o Prefix Length: The length of the prefix in bytes. For IPv4 it 410 MUST be 4 and IPv6 it MUST be 16 bytes. 412 o Mask Length: The length of the prefix in bits. Only the most 413 significant octets of the Prefix are encoded. 415 o IS-IS Prefix: The IS-IS prefix at the tail-end of the advertised 416 PPR. This corresponds to a routable prefix of the originating 417 node and it MAY have one of the [RFC7794] flags set (X-Flag/R- 418 Flag/N-Flag). Value of this field MUST be 4 octets for IPv4 419 Prefix and MUST be 16 octets for IPv6 Prefix. Encoding is similar 420 to TLV 135 [RFC5305] and TLV 236 [RFC5308] or MT-Capable [RFC5120] 421 IPv4 (TLV 235) and IPv6 Prefixes (TLV 237) respectively. 423 o PPR-Prefix Sub-TLVs - TBD. These have 1 octet type, 1 octet 424 length and value field is defined per the type field. 426 3.2. PPR-ID Sub-TLV 428 This is the actual data plane identifier in the packet header and 429 could be of any data plane as defined in PPR-ID Type field. Both 430 PPR-Prefix and PPR-ID MUST belong to a same node in the network. 432 0 1 2 3 433 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 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Type | Length |PPR-ID Flags | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | PPR-ID Type | PPR-ID Length |PPR-ID Mask Len| Algo | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 // PPR-ID (variable size) // 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 Figure 4: PPR-ID Sub-TLV Format 444 o Type: TBD (IANA to assign from sub-TLV registry described above). 446 o Length: Total length of the value field in bytes. 448 o 450 * PPR-ID Flags: 2 Octet field for PPR-ID flags: 452 o 454 PPR-ID Flags Format 456 0 1 2 3 4 5 6 7.. 15 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 |L|A|Reserved | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 o 463 1. L: If set, the PPR path is a Loose-PPR. If the this flag is 464 unset, then the PPR path is a Strict-PPR. A Strict-PPR lists 465 every single node or adjacency in the path description from 466 source to the destination. 468 2. A: If set, all non-PPR path nodes in the IS-IS area/domain 469 MUST add a FIB entry for the PPR-ID with NH set to the 470 shortest path NH for the prefix being advertised. The use of 471 this is TBD. By default this flag MUST be unset. 473 3. Reserved: For future use; MUST be set to 0 on transmit and 474 ignored on receive. 476 o 477 * PPR-ID Type: Data plane type of PPR-ID. This is a new registry 478 (TBD IANA - Suggested values as below) for this Sub-TLV and the 479 defined types are as follows: 481 o 483 A. Type: 1 MPLS SID/Label 485 B. Type: 2 Native IPv4 Address/Prefix 487 C. Type: 3 Native IPv6 Address/Prefix 489 D. Type: 4 IPv6 SID in SRv6 with SRH 491 o PPR-ID Length: Length of the PPR-ID field in octets and this 492 depends on the PPR-ID type. See PPR-ID below for the length of 493 this field and other considerations. 495 o PPR-ID Mask Length: It is applicable for only for PPR-ID Type 2, 3 496 and 4. For Type 1 this value MUST be set to zero. It contains 497 the length of the PPR-ID Prefix in bits. Only the most 498 significant octets of the Prefix are encoded. This is needed, if 499 PPR-ID followed is an IPv4/IPv6 Prefix instead of 4/16 octet 500 Address respectively. 502 o Algo: 1 octet value represents the SPF algorithm. Algorithm 503 registry is as defined in 504 [I-D.ietf-isis-segment-routing-extensions]. 506 o PPR-ID: This is the Preferred Path forwarding identifier that 507 would be on the data packet. The value of this field is variable 508 and it depends on the PPR-ID Type - for Type 1, this is and MPLS 509 SID/Label. For Type 2 this is a 4 byte IPv4 address. For Type 3 510 this is a 16 byte IPv6 address. For Type 2 and Type 3 encoding is 511 similar to "IS-IS Prefix" as specified in Section 3.1. For Type 512 4, it is a 16 byte IPv6 SID. 514 For PPR-ID Type 2, 3 or 4, if the PPR-ID Len is set to non-zero 515 value, then the PPR-ID MUST NOT be advertised as a routable prefix in 516 TLV 135, TLV 235, TLV 236 and TLV 237. Also PPR-ID MUST belong to 517 the node where Prefix is advertised from. PPR-ID Len = 0 case is a 518 special case and is discussed in Section 4.1. 520 3.3. PPR-PDE Sub-TLV 522 This Sub-TLV represents the PPR Path Description Element (PDE). PPR- 523 PDEs are used to describe the path in the form of set of contiguous 524 and ordered Sub-TLVs, where first Sub-TLV represents (the top of the 525 stack in MPLS data plane or) first node/segment of the path. These 526 set of ordered Sub-TLVs can have both topological elements and non- 527 topological elements (e.g., service segments). 529 0 1 2 3 530 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 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | Type | Length | PPR-PDE Type | Reserved | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | PDE-ID Type | PDE-ID Len | PPR-PDE Flags | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 // PDE-ID Value (continued, variable size) // 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | PPR-PDE Sub-TLVs (variable) | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 Figure 5: PPR-PDE Sub-TLV Format 543 o Type: TBD (See IANA for suggested value) from IS-IS PPR TLV 544 Section 3 Sub-TLV registry. 546 o Length: Total length of the value field in bytes. 548 o PPR-PDE Type: A new registry (TBD IANA) for this Sub-TLV and the 549 defined types are as follows: 551 a. Type: 1 Topological 553 b. Type: 2 Non-Topological 555 o PDE-ID Type: 1 Octet PDE-forwarding IDentifier Type. A new 556 registry (TBD IANA) for this Sub-TLV and the defined types and 557 corresponding PDE-ID Len, PDE-ID Value are as follows: 559 a. Type 1: SID/Label type as defined in 560 [I-D.ietf-isis-segment-routing-extensions]. PDE-ID Len and PDE- 561 ID Value fields are per Section 2.3 of the referenced document. 563 b. Type 2: SR-MPLS Prefix SID. PDE-ID Len and PDE-ID Value are same 564 as Type 1. 566 c. Type 3: SR-MPLS Adjacency SID. PDE-ID Len and PDE-ID Value are 567 same as Type 1. 569 d. Type 4: IPv4 Address. PDE-ID Len is 4 bytes and PDE-ID Value is 570 4 bytes IPv4 address encoded similar to IPv4 Prefix described in 571 Section 3.1. 573 e. Type 5: IPv6 Address. PDE-ID Len is 16 bytes and PDE-ID Value is 574 16 bytes IPv6 address encoded similar to IPv6 Prefix described in 575 Section 3.1. 577 f. Type 6: SRv6 Node SID as defined in 578 [I-D.bashandy-isis-srv6-extensions]. PDE-ID Len and PDE-ID Value 579 are as defined in SRv6 SID from the refrenced draft. 581 g. Type 7: SRv6 Adjacency-SID. PDE-ID Len and PDE-ID Values are 582 similar to SRv6 Node SID above. 584 o PPR-PDE Flags: 2 Octet bit-field of flags; described below: 586 PPR-PDE Flags Format 588 0 1 2 3 4 5 6 7 .. 15 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 |L|D|Reserved | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 1. L: Loose Bit. Indicates the type of next "Topological PDE-ID" in 594 the path description and overrides the L bit in Section 3.2. If 595 set, the next PDE is Loose. If this flag is unset, the next 596 Topological PDE is Strict Type. 598 2. D: Destination bit. By default this bit MUST be unset. This bit 599 MUST be set only for PPR-PDE Type is 1 i.e., Topological and this 600 PDE represents the node PPR-Prefix Section 3.1 belongs to, if 601 there is no sub-sub-TLV to override PPR-Prefix and PPR-ID values. 603 3. Reserved: 1 Octet reserved bits for future use. Reserved bits 604 MUST be reset on transmission and ignored on receive. 606 o PPR-PDE Sub-TLVs: TBD. These have 1 octet type, 1 octet length 607 and value field is defined per the type field. 609 3.4. PPR-Attributes Sub-TLV 611 PPR-Attribute Sub-TLVs describe the attributes of the path. The 612 following sub-TLVs draw from a new registry for sub-TLV numbers; this 613 registry is to be created by IANA, and administered using the first 614 come first serve process: 616 o Type 1 (Suggested Value - IANA TBD): Packet Traffic accounting 617 Sub-TLV. Length 0 and no value field. Specifies to create a 618 counter to count number of packets forwarded on this PPR-ID on 619 each node in the path description. 621 o Type 2 (Suggested Value - IANA TBD): Traffic statistics in Bytes 622 Sub-TLV. Length 0 and no value field. Specifies to create a 623 counter to count number of bytes forwarded on this PPR-ID 624 specified in the network header (e.g. IPv4, IPv6) on each node in 625 the path description. 627 o Type 3 (Suggested Value - IANA TBD): PPR-Prefix originating node's 628 IPv4 Router ID Sub-TLV. Length and Value field are as specified 629 in [RFC7794]. 631 o Type 4 (Suggested Value - IANA TBD): PPR-Prefix originating node's 632 IPv6 Router ID Sub-TLV. Length and Value field are as specified 633 in [RFC7794]. 635 o Type 5 (Suggested Value - IANA TBD): PPR-Metric Sub-TLV. Length 4 636 bytes, and Value is metric of this path represented through the 637 PPR-ID. Different nodes can advertise the same PPR-ID for the 638 same Prefix with a different set of PPR-PDE Sub-TLVs and the 639 receiving node MUST consider the lowest metric value (TBD more, on 640 what happens when metric is same for two different set of PPR-PDE 641 Sub-TLVs). 643 4. PPR Processing Procedure Example 645 As specified in Section 2, a PPR can be a TE path, locally 646 provisioned by the operator or by a controller. Consider the 647 following IS-IS network to describe the operation of PPR TLV as 648 defined in Section 3: 650 1 651 _______ 652 / 1 \ 653 +---R2-------R3---+ 654 / \_______/ \ 655 / 1 \ 656 1 / \ 1 657 / 1__R13__1 \ 658 / / \ \ 659 R1------R6 R7-----------R4 660 \ 2 \__R14__/ 2 /\ 661 \ 2 2 / \ 662 3 \ / 3 \1 663 \ 4 / \ 664 +----R8------R9-----R10------R12 665 \ 1 / 666 1 \ / 1 667 +----R11---+ 669 Figure 6: IS-IS Network 671 In the (Figure 6) shown, consider node R1 as an ingress node, or a 672 head-end node, and the node R4 MAY be an egress node or another head- 673 end node. The numbers shown on links between nodes R1-R14 indicate 674 the bi-directional IS-IS metric as provisioned. R1 may be configured 675 to receive TE source routed path information from a central entity 676 (PCE [RFC5440], Netconf [RFC6241] or a Controller) that comprises of 677 PPR information which relates to sources that are attached to R1. It 678 is also possible to have a PPR provisioned locally by the operator 679 for non-TE needs (FRR or for chaining certain services). 681 The PPR TLV (as specified in Section 3) is encoded as an ordered list 682 of PPR-PDEs from source to a destination node in the network and is 683 represented with a PPR-ID Section 3.2. The PPR TLV includes PPR-PDE 684 Sub-TLVS Section 3.3, which represent both topological and non- 685 topological elements and specifies the actual path towards a PPR- 686 Prefix at R4. 688 o The shortest path towards R4 from R1 are through the following 689 sequence of nodes: R1-R2-R3-R4 based on the provisioned metrics. 691 o The central entity can define a few PPRs from R1 to R4 that 692 deviate from the shortest path based on other network 693 characteristic requirements as requested by an application or 694 service. For example, the network characteristics or performance 695 requirements may include bandwidth, jitter, latency, throughput, 696 error rate, etc. 698 o A first PPR may be identified by PPR-ID = 1 (value) and may 699 include the path of R1-R6-R7-R4 for a Prefix advertised by R4. 700 This is an example for a Loose-PPR and 'L' bit MUST be set on 701 Section 3.2. 703 o A second PPR may be identified by PPR-ID = 2 (value) and may 704 include the path of R1-R8-R9-R10-R4. This is an example for a 705 Strict-PPR and 'L' bit MUST be unset on Section 3.2. Though this 706 example shows PPR with all nodal SIDs, it is possible to have a 707 PPR with combination of node and adjacency SIDs (local or global) 708 or with PPR-PDE Type set to Non-Topological as defined in 709 Section 3.3 elements along with these. 711 4.1. PPR TLV Processing 713 The first topological sub-object or PDE (Section 3.3) relative to the 714 beginning of PPR Path contains the information about the first node 715 (e.g. in SR-MPLS it's the topmost label). The last topological sub- 716 object or PDE contains information about the last node (e.g. in SR- 717 MPLS it's the bottommost label). 719 Each receiving node, determine whether an advertised PPR includes 720 information regarding the receiving node. Before processing any 721 further, validation MUST be done to see if any PPR topological PDE is 722 seen more than once (possible loop), if yes, this PPR TLV MUST be 723 ignored. Processing of PPR TLVs can be done, during the end of the 724 SPF computation (for MTID that is advertised in this TLV) and for the 725 each prefix described through PPR TLV. For example, node R9 receives 726 the PPR information, and ignores the PPR-ID=1 (Section 4) because 727 this PPR TLV does not include node R9 in the path description/ordered 728 PPR-PDE list. 730 However, node R9 may determine that the second PPR identified by PPR- 731 ID = 2 does include the node R9 in its PDE list. Therefore, node R9 732 updates the local forwarding database to include an entry for the 733 destination address of R4 indicates, that when a data packet 734 comprising a PPR-ID of 2 is received, forward the data packet to node 735 R10 instead of R11. This is even though from R9 the shortest path to 736 reach R4 via R11 (Cost 3: R9-R11-R12-R4) it chooses the nexthop to 737 R10 to reach R4 as specified in the PPR path description. Same 738 process happens to all nodes or all topological PDEs as described in 739 the PPR TLV. 741 In summary, the receiving node checks first, if this node is on the 742 path by checking the node's topological elements (with PPR-PDE Type 743 set to Topological) in the path list. If yes, it adds/adjusts the 744 shortest path nexthop computed towards PPR Prefix to the shortest 745 path nexthop towards the next topological PDE in the PPR's Path. 747 For PPR-ID (Section 3.2) Type 2, 3 or 4, if the PPR-ID Len is set to 748 0, then Prefix would also become the PPR-ID (a special case). This 749 can be used for some situations, where certain optimizations are 750 required in the network. For this, path described in the PPR TLV 751 SHOULD be completely dis-joint from the shortest path route to the 752 prefix. If the disjoint-ness property is not maintained then the 753 traffic MAY not be using the PPR path, as and when it encounters any 754 node which is not in the path description. 756 5. PPR Data Plane aspects 758 Data plane for PPR-ID is selected by the entity (e.g., a controller, 759 locally provisioned by operator), which selects a particular PPR in 760 the network. Section 3.2 defines various data plane identifier types 761 and a corresponding data plane identifier is selected by the entity 762 which selects the PPR. Other data planes other than described below 763 can also use this TLV to describe the PPR. Further details TBD. 765 5.1. SR-MPLS with PPR 767 If PPR-ID Type is 1, then the PPR belongs to SR-MPLS data plane and 768 the complete PPR stack is represented with a unique SR SID/Label and 769 this gets programmed on the data plane of each node, with the 770 appropriate nexthop computed as specified in Section 4. PPR-ID here 771 is a label/index from the SRGB (like another node SID or global-ADJ 772 SID). PPR path description here is a set of ordered SIDs represented 773 with PPR-PDE (Section 3.2) Sub-TLVs. Non-Topological segments also 774 programmed in the forwarding to enable specific function/service, 775 when the data packet hits with corresponding PPR-ID. 777 Based on 'L' flag in PPR-ID Flags (Section 3.2), for SR-MPLS data 778 plane either 1 label or 2 labels need to be provisioned on individual 779 nodes on the path description. For the example network in Section 4, 780 for PPR-ID=1, which is a loose path, node R6 programs the bottom 781 label as PPR-ID and the top label as the next topological PPR-PDE in 782 the path, which is a node SID of R7. The NH computed at R6 would be 783 the shortest path towards R7 i.e., the interface towards R13. If 'L' 784 flag is unset only PPR-ID is programmed on the data plane with NH set 785 to the shortest path towards next topological PPR-PDE. 787 5.2. 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 nexthop 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 the same as the destination IPv6 address and SL field in SRH 796 would be set to 0; however SRH [I-D.ietf-6man-segment-routing-header] 797 can contain any other TLVs and non-topological SIDs as needed. 799 5.3. PPR Native IP Data Planes 801 If PPR-ID Type is 2 then source routing and packet steering can be 802 done in IPv4 data plane (PPR-IPv4), along the path as described in 803 PPR Path description. This is achieved by setting the destination IP 804 address as PPR-ID, which is an IPv4 address in the data packet 805 (tunneled/encapsulated). There is no data plane change or upgrade 806 needed to support this. However this is applicable to only Strict- 807 PPR paths ('L' bit as specified in Section 3.2 MUST be unset). 809 Similarly for PPR-ID Type is 3, then source routing and packet 810 steering can be done in IPv6 data plane (PPR-IPv6), along the path as 811 described in PPR Path description. Whatever specified above for IPv4 812 applies here too, except that destination IP address of the data 813 packet is IPv6 Address (PPR-ID). This doesn't require any IPv6 814 extension headers (EH), if there is no metadata/TLVs need to be 815 carried in the data packet. 817 6. PPR Traffic Accounting 819 Section 3.4 defines few PPR-Attributes to indicate creation of 820 traffic accounting statistics in each node of the PPR path 821 description. Presence of "Packet Traffic Accounting" and "Traffic 822 Statistics" Sub-TLVs instruct to provision the hardware, to account 823 for the respective traffic statistics. Traffic accounting should 824 happen, when the actual data traffic hits for the PPR-ID in the 825 forwarding plane. This allows more granular and dynamic enablement 826 of traffic statistics for only certain PPRs as needed. 828 This approach, thus is more safe and secure than any mechanism that 829 involves creation of the state in the nodes with the data traffic 830 itself. This is because, creation and deletion of the traffic 831 accounting state for PPRs happen through IS-IS LSP processing and IS- 832 IS protocol control plane security Section 9 options are applicable 833 to this TLV. 835 How the traffic accounting is distributed to a central entity is out 836 of scope of this document. One can use any method (e.g. gRPC) to 837 extract the PPR-ID traffic stats from various nodes along the path. 839 7. Acknowledgements 841 Thanks to Alex Clemm, Lin Han, Toerless Eckert and Kiran Makhijani 842 for initial discussions on this topic. Thanks to Kevin Smith and 843 Stephen Johnson for various deployment scenarios applicability from 844 ETSI WGs perspective. Authors also acknowledge Alexander Vainshtein 845 for detailed discussions and suggestions on this topic. 847 Earlier versions of draft-ietf-isis-segment-routing-extensions have a 848 mechanism to advertise EROs through Binding SID. 850 8. IANA Considerations 852 This document requests the following new TLV in IANA IS-IS TLV code- 853 point registry. 855 TLV # Name 856 ----- -------------- 857 TBD PPR TLV 859 This document requests IANA to create a new Sub-TLV registry for PPR 860 TLV Section 3 with the following initial entries (suggested values): 862 Sub-TLV # Sub-TLV Name 863 --------- --------------------------------------------------------- 865 1 PPR-Prefix (Section 3.1) 867 2 PPR-ID (Section 3.2) 869 3 PPR-PDE (Section 3.3) 871 This document also requests IANA to create a new Sub-TLV registry for 872 PPR Path attributes with the following initial entries (suggested 873 values): 875 Sub-TLV # Sub-TLV Name 876 --------- --------------------------------------------------------- 878 1 Packet Traffic Accounting (Section 3.4) 880 2 Traffic Statistics (Section 3.4) 882 3 PPR-Prefix Source IPv4 Router ID (Section 3.4) 884 4 PPR-Prefix Source IPv6 Router ID (Section 3.4) 885 5 PPR-Metric (Section 3.4) 887 This document requests additional IANA registries in an IANA managed 888 registry "Interior Gateway Protocol (IGP) Parameters" for various PPR 889 TLV parameters. The registration procedure is based on the "Expert 890 Review" as defined in [RFC8126]. The suggested registry names are: 892 o "PPR-Type" - Types are an unsigned 8 bit numbers. Values are as 893 defined in Section 3 of this document. 895 o "PPR-Flags" - 1 Octet. Bits as described in Section 3 of this 896 document. 898 o "PPR-ID Type" - Types are an unsigned 8 bit numbers. Values are 899 as defined in Section 3.2 of this document. 901 o "PPR-ID Flags" - 1 Octet. Bits as described in Section 3.2 of 902 this document. 904 o "PPR-PDE Type" - Types are an unsigned 8 bit numbers. Values are 905 as defined in Section 3.3 of this document. 907 o "PPR-PDE Flags" - 1 Octet. Bits as described in Section 3.3 of 908 this document. 910 o "PDE-ID Type" - Types are an unsigned 8 bit numbers. Values are 911 as defined in Section 3.3 of this document. 913 9. Security Considerations 915 Security concerns for IS-IS are addressed in [RFC5304] and [RFC5310]. 916 Further security analysis for IS-IS protocol is done in [RFC7645] 917 with detailed analysis of various security threats and why [RFC5304] 918 should not be used in the deployments. Advertisement of the 919 additional information defined in this document introduces no new 920 security concerns in IS-IS protocol. However as this extension is 921 related to SR-MPLS and SRH data planes as defined in 922 [I-D.ietf-spring-segment-routing], those particular data plane 923 security considerations does apply here. 925 10. References 927 10.1. Normative References 929 [I-D.ietf-isis-segment-routing-msd] 930 Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 931 "Signaling MSD (Maximum SID Depth) using IS-IS", draft- 932 ietf-isis-segment-routing-msd-12 (work in progress), May 933 2018. 935 [I-D.ietf-spring-segment-routing] 936 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 937 Litkowski, S., and R. Shakir, "Segment Routing 938 Architecture", draft-ietf-spring-segment-routing-15 (work 939 in progress), January 2018. 941 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 942 Requirement Levels", BCP 14, RFC 2119, 943 DOI 10.17487/RFC2119, March 1997, 944 . 946 10.2. Informative References 948 [I-D.bashandy-isis-srv6-extensions] 949 Ginsberg, L., Bashandy, A., Filsfils, C., Decraene, B., 950 and Z. Hu, "IS-IS Extensions to Support Routing over IPv6 951 Dataplane", draft-bashandy-isis-srv6-extensions-02 (work 952 in progress), March 2018. 954 [I-D.cheng-spring-mpls-path-segment] 955 Cheng, W., Wang, L., Li, H., Chen, M., Zigler, R., and S. 956 Zhan, "Path Segment in MPLS Based Sement Routing Network", 957 draft-cheng-spring-mpls-path-segment-01 (work in 958 progress), March 2018. 960 [I-D.hegde-spring-traffic-accounting-for-sr-paths] 961 Hegde, S., "Traffic Accounting for MPLS Segment Routing 962 Paths", draft-hegde-spring-traffic-accounting-for-sr- 963 paths-01 (work in progress), October 2017. 965 [I-D.ietf-6man-segment-routing-header] 966 Previdi, S., Filsfils, C., Leddy, J., Matsushima, S., and 967 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 968 (SRH)", draft-ietf-6man-segment-routing-header-13 (work in 969 progress), May 2018. 971 [I-D.ietf-isis-mpls-elc] 972 Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S. 973 Litkowski, "Signaling Entropy Label Capability and 974 Readable Label-stack Depth Using IS-IS", draft-ietf-isis- 975 mpls-elc-03 (work in progress), January 2018. 977 [I-D.ietf-isis-segment-routing-extensions] 978 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 979 Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura, 980 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 981 segment-routing-extensions-17 (work in progress), June 982 2018. 984 [I-D.ietf-mpls-sfc] 985 Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based 986 Forwarding Plane for Service Function Chaining", draft- 987 ietf-mpls-sfc-01 (work in progress), May 2018. 989 [I-D.xuclad-spring-sr-service-chaining] 990 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 991 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 992 Henderickx, W., and S. Salsano, "Segment Routing for 993 Service Chaining", draft-xuclad-spring-sr-service- 994 chaining-01 (work in progress), March 2018. 996 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 997 Topology (MT) Routing in Intermediate System to 998 Intermediate Systems (IS-ISs)", RFC 5120, 999 DOI 10.17487/RFC5120, February 2008, 1000 . 1002 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 1003 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 1004 2008, . 1006 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1007 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1008 2008, . 1010 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 1011 DOI 10.17487/RFC5308, October 2008, 1012 . 1014 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 1015 and M. Fanto, "IS-IS Generic Cryptographic 1016 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 1017 2009, . 1019 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1020 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1021 DOI 10.17487/RFC5440, March 2009, 1022 . 1024 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1025 and A. Bierman, Ed., "Network Configuration Protocol 1026 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1027 . 1029 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 1030 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 1031 RFC 6790, DOI 10.17487/RFC6790, November 2012, 1032 . 1034 [RFC7645] Chunduri, U., Tian, A., and W. Lu, "The Keying and 1035 Authentication for Routing Protocol (KARP) IS-IS Security 1036 Analysis", RFC 7645, DOI 10.17487/RFC7645, September 2015, 1037 . 1039 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 1040 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 1041 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 1042 March 2016, . 1044 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1045 Writing an IANA Considerations Section in RFCs", BCP 26, 1046 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1047 . 1049 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1050 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1051 May 2017, . 1053 Authors' Addresses 1055 Uma Chunduri 1056 Huawei USA 1057 2330 Central Expressway 1058 Santa Clara, CA 95050 1059 USA 1061 Email: uma.chunduri@huawei.com 1063 Richard Li 1064 Huawei USA 1065 2330 Central Expressway 1066 Santa Clara, CA 95050 1067 USA 1069 Email: richard.li@huawei.com 1070 Russ White 1071 LinkedIn 1072 Oak Island, NC 28465 1073 USA 1075 Email: russ@riw.us 1077 Jeff Tantsura 1078 Nuage Networks 1079 755 Ravendale Drive 1080 Mountain View, CA 94043 1081 USA 1083 Email: jefftant.ietf@gmail.com 1085 Luis M. Contreras 1086 Telefonica 1087 Sur-3 building, 3rd floor 1088 Madrid 28050 1089 Spain 1091 Email: luismiguel.contrerasmurillo@telefonica.com 1093 Yingzhen Qu 1094 Huawei USA 1095 2330 Central Expressway 1096 Santa Clara, CA 95050 1097 USA 1099 Email: yingzhen.qu@huawei.com