idnits 2.17.1 draft-chunduri-lsr-isis-preferred-path-routing-01.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 69 lines == It seems as if not all pages are separated by form feeds - found 48 form feeds but 50 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances 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 (July 2, 2018) is 2124 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 (-19) exists of draft-ietf-isis-segment-routing-msd-12 == Outdated reference: A later version (-05) exists of draft-bashandy-isis-srv6-extensions-03 == 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: A later version (-26) exists of draft-ietf-6man-segment-routing-header-14 == Outdated reference: A later version (-13) exists of draft-ietf-isis-mpls-elc-03 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-18 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-sfc-01 Summary: 0 errors (**), 0 flaws (~~), 12 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: January 3, 2019 R. White 6 LinkedIn 7 J. Tantsura 8 Nuage Networks 9 L. Contreras 10 Telefonica 11 Y. Qu 12 Huawei USA 13 July 2, 2018 15 Preferred Path Routing (PPR) in IS-IS 16 draft-chunduri-lsr-isis-preferred-path-routing-01 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 January 3, 2019. 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 Scaling Considerations . . . . . . . . . . . . . . . . . 18 89 7. PPR Traffic Accounting . . . . . . . . . . . . . . . . . . . 19 90 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 91 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 92 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 93 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 94 11.1. Normative References . . . . . . . . . . . . . . . . . . 21 95 11.2. Informative References . . . . . . . . . . . . . . . . . 21 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 98 1. Introduction 100 In a network implementing Segment Routing (SR), packets are steered 101 through the network using Segment Identifiers (SIDs) carried in the 102 packet header. Each SID uniquely identifies a segment as defined in 103 [I-D.ietf-spring-segment-routing]. SR capabilities are defined for 104 MPLS and IPv6 data planes called SR-MPLS and SRv6 respectively. 106 In SR-MPLS, each segment is encoded as a label, and an ordered list 107 of segments are encoded as a stack of labels. This stack of labels 108 is carried as part of the packet header. In SRv6, a segment is 109 encoded as an IPv6 address, within a new type of IPv6 hop-by-hop 110 routing header/extension header (EH) called SRH 111 [I-D.ietf-6man-segment-routing-header]; an ordered list of IPv6 112 addresses/segments are encoded in SRH. 114 Section 1.2 and Section 1.3 describe performance, hardware 115 capabilities and various associated issues which may result in SR 116 deployments. These motivate the proposed solution, Preferred Path 117 Routing, which is specified in Section 2. 119 1.1. Acronyms 121 EL - Entropy Label 123 ELI - Entropy Label Indicator 125 LSP - IS-IS Link State PDU 127 MPLS - Multi Protocol Label Switching 129 MSD - Maximum SID Depth 131 MTU - Maximum Transferrable Unit 133 PPR - Preferred Path Routing/Route 135 PPR-ID - Preferred Path Route Identifier, a data plane identifier 137 SID - Segment Identifier 139 SPF - Shortest Path First 141 SR-MPLS - Segment Routing with MPLS data plane 143 SRH - Segment Routing Header - IPv6 routing Extension headr 145 SRv6 - Segment Routing with Ipv6 data plane with SRH 146 TE - Traffic Engineering 148 1.2. Challenges with Increased SID Depth 150 SR label stacks carried in the packet header create challenges in the 151 design and deployment of networks and networking equipment. 152 Following examples illustrates the need for increased SID depth in 153 various use cases: 155 (a). Consider the following network where SR-MPLS data plane is in 156 use and with same SRGB (5000-6000) on all nodes i.e., A1 to A7 and B1 157 to B7 for illustration: 159 SID:10 SID:20 SID:30 SID:40 SID:50 SID:300(Ax) SID:60 SID:70 160 A1-------A2-------A3-------A4-------A5===============A6----------A7 161 \ / \5 5/ \ SID:310(Ay) \ / 162 \ 10 10/ +-A10-+ \ \10 /10 163 \ / SID:100 \ \ / 164 SID:80 \A8-----A9/SID:90 \ 40 \ / 165 / \ +---+ \ / 166 /10 B2x:125 \10 \ \/ 167 B1--------B2============B3----B4--------B5-------B6----------B7 168 SID:110 SID:120 SID:130 SID:140 SID:150 SID:160 SID:170 170 Figure 1: SR-MPLS Network 172 Global ADJ SIDs are provisioned between A5-A6 and B2-B3. All 173 other SIDs shown are nodal SID indices. 175 All metrics of the links are set to 1, unless marked otherwise. 177 Shortest Path from A1 to A7: A2-A3-A4-A5-A6-A7 179 Path-x: From A1 to A7 - A2-A8-B2-B2x-A9-A10-Ax-A7; Pushed Label 180 Stack @A1: 5020:5080:5120:5125:5090:5100:5300:5070 (where B2x is a 181 local ADJ-SID and Ax is a global ADJ-SID). 183 In this example, the traffic engineered path is represented with a 184 combination of Adjacency and Node SIDs with a stack of 8 labels. 185 However, this value can be larger, if the use of entropy label 186 [RFC6790] is desired and based on the Readable Label Depth 187 (Section 1.3) capabilities of each node and additional labels 188 required to insert ELI/EL at appropriate places. 190 Though above network is shown with SR-MPLS data plane, if the 191 network were to use SR-IPv6 data plane, path size would be 192 increased even more because of the size of the IPv6 SID (16 bytes) 193 in SRH. 195 (b). Apart from the TE case above, when deploying 196 [I-D.ietf-mpls-sfc] or [I-D.xuclad-spring-sr-service-chaining], with 197 the inclusion of services, or non-topological segments on the label 198 stack, can also make the size of the stack much larger. 200 (c). Some SR-MPLS deployments need accounting statistics for path 201 monitoring and traffic re-optimizations. 202 [I-D.hegde-spring-traffic-accounting-for-sr-paths] and 203 [I-D.cheng-spring-mpls-path-segment] propose solutions with various 204 forms of path segments (either with special labels or PATH segment 205 encoded at the bottom of the stack respectively). However, these 206 proposals further increases the depth of SID stack, when it is 207 compounded with MSD/RLDs of various nodes in the path. 209 Overall the additional path overhead in various SR deployments may 210 cause the following issues: 212 a. HW Capabilities: Not all nodes in the path can support the 213 ability to push or read label stack needed 214 [I-D.ietf-isis-segment-routing-msd] to satisfy user/operator 215 requirements, Alternate paths which meet these user/operator 216 requirements may not be available. 218 b. Line Rate: Potential performance issues in deployments, which use 219 SRH data plane with the increased size of the SRH with 16 byte 220 SIDs. 222 c. MTU: Larger SID stacks on the data packet can cause potential 223 MTU/fragmentation issues. 225 d. Header Tax: Some deployments, such as 5G, require minimal packet 226 overhead in order to conserve network resources. Carrying 40 or 227 50 octets of data in a packet with hundreds of octet of header 228 would be an unacceptable use of available bandwidth. 230 With the solution proposed in this document (Section 5) and 231 Section 4), for Path-x in the example network Figure 1 above, SID 232 stack would be reduced from 8 SIDs to a single SID. 234 1.3. Mitigation with MSD 236 The number of SIDs in the stack a node can impose is referred as 237 Maximum SID Depth (MSD) capability 238 [I-D.ietf-isis-segment-routing-msd], which must be taken into 239 consideration when computing a path to transport a data packet in a 240 network implementing segment routing. [I-D.ietf-isis-mpls-elc] 241 defines another MSD type, Readable Label Depth (RLD) that is used by 242 a head-end to insert Entropy Label pair (ELI/EL) at appropriate 243 depth, so it could be read by transit nodes. There are situations 244 where the source routed path can be excessive as path represented by 245 SR SIDs need to describe all the nodes and ELI/EL based on the 246 readability of the nodes in that path. 248 MSDs (and RLD type) capabilities advertisement help mitigate the 249 problem for a central entity to create the right source routed path 250 per application/operator requirements. However the availability of 251 actual paths meeting these requirements are still limited by the 252 underlying hardware and their MSD capabilities in the data path. 254 2. Preferred Path Routing (PPR) 256 PPR mitigates the issues described in Section 1.2, while continuing 257 to allow the direction of traffic along an engineered path through 258 the network by replacing the label stack with a PPR-ID. The PPR-ID 259 can either be a single label or a native destination address. To 260 facilitate the use of a single label to describe an entire path, a 261 new TLV is added to IS-IS, as described below in Section 3. 263 A PPR could be an SR path, a traffic engineered path computed based 264 on some constraints, an explicitly provisioned Fast Re-Route (FRR) 265 path or a service chained path. A PPR can be signaled by any node, 266 computed by a central controller, or manually configured by an 267 operator. PPR extends the source routing and path steering 268 capabilities to native IP (IPv4 and IPv6) data planes without 269 hardware upgrades; see Section 5. 271 2.1. PPR-ID and PPR Path Description 273 The PPR-ID describes a path through the network. For SR- MPLS this 274 is an MPLS Label/SID and for SRv6 this is an IPv6-SID. For native IP 275 data planes this is either IPv4 or IPv6 address/prefix. 277 The path identified by the PPR-ID is described as a set of Path 278 Description Elements (PDEs), each of which represents a segment of 279 the path. Each node determines location in the path as described, 280 and forwards to the next segment/hop or label of the path description 281 (see the Forwarding Procedure Example later in this document). 283 These PPR-PDEs as defined in Section 3.3, like SR SIDs, can represent 284 topological elements like links/nodes, backup nodes, as well as non- 285 topological elements such as a service, function, or context on a 286 particular node. PPR-PDE optionally, can also have more information 287 as described with in their Sub-TLVs. 289 A PPR path can be described as a Strict-PPR or a Loose-PPR. In a 290 Strict-PPR all nodes/links on the path are described with SR SIDs for 291 SR data planes or IPv4/IPV6 addresses for native IP data planes. In 292 a Loose-PPR only some of the nodes/links from source to destination 293 are described. More specifics and restrictions around Strict/Loose 294 PPRs are described in respective data planes in Section 5. Each PDE 295 is described as either an MPLS label towards the next hop in MPLS 296 enabled networks, or as an IP next hop, in the case of either 297 "plain"/"native" IP or SRv6 enabled networks. A PPR path is related 298 to a set of PDEs using the following TLVs. 300 3. PPR Related TLVs 302 This section describes the encoding of PPR TLV. This TLV can be seen 303 as having 4 logical section viz., encoding of the PPR-Prefix (IS-IS 304 Prefix), encoding of PPR-ID, encoding of path description with an 305 ordered PDE Sub-TLVs and a set of optional PPR attribute Sub-TLVs, 306 which can be used to describe one or more parameters of the path. 307 Multiple instances of this TLV MAY be advertised in IS-IS LSPs with 308 different PPR-ID Type and with corresponding PDE Sub-TLVS. The PPR 309 TLV has Type TBD (suggested value xxx), and has the following format: 311 0 1 2 3 312 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 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Type | Length | PPR-Flags | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | PPR-Prefix Sub-TLV (variable size) | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | PPR-ID Sub-TLV (variable size) | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | PPR-PDE Sub-TLVs (variable) | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | PPR-Attribute Sub-TLVs (variable) | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 Figure 2: PPR TLV Format 327 o Type: TBD (IANA) from IS-IS top level TLV registry. 329 o Length: Total length of the value field in bytes. 331 o PPR-Flags: 2 Octet bit-field of flags for this TLV; described 332 below. 334 o PPR-Prefix: A variable size sub-TLV representing the destination 335 of the path being described. This is defined in Section 3.1. 337 o PPR-ID: A variable size Sub-TLV representing the data plane or 338 forwarding identifier of the PPR. Defined in Section 3.2. 340 o PPR-PDEs: Variable number of ordered PDE Sub-TLVs which represents 341 the path. This is defined in Section 3.3. 343 o PPR-Attributes: Variable number of PPR-Attribute Sub-TLVs which 344 represent the path attributes. These are defined in Section 3.4. 346 The Flags field has the following flag bits defined: 348 PPR TLV Flags Format 350 0 1 2 3 4 5 6 7 15 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 |S|D|A| Reserved | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 1. S: If set, the PPR TLV MUST be flooded across the entire routing 356 domain. If the S flag is not set, the PPR TLV MUST NOT be leaked 357 between IS-IS levels. This bit MUST NOT be altered during the 358 TLV leaking 360 2. D: When the PPR TLV is leaked from IS-IS level-2 to level-1, the 361 D bit MUST be set. Otherwise, this bit MUST be clear. PPR TLVs 362 with the D bit set MUST NOT be leaked from level-1 to level-2. 363 This is to prevent TLV looping across levels. 365 3. A: The originator of the PPR TLV MUST set the A bit in order to 366 signal that the prefixes and PPR-IDs advertised in the PPR TLV 367 are directly connected to the originators. If this bit is not 368 set, this allows any other node in the network advertise this TLV 369 on behalf of the originating node of the PPR-Prefix. If PPR TLV 370 is leaked to other areas/levels the A-flag MUST be cleared. In 371 case if the originating node of the prefix must be disambiguated 372 for any reason including, if it is a Multi Homed Prefix (MHP) or 373 leaked to a different IS-IS level or because [RFC7794] X-Flag is 374 set, then PPR-Attribute Sub-TLV Source Router ID SHOULD be 375 included. 377 4. Reserved: For future use; MUST be set to 0 on transmit and 378 ignored on receive. 380 The following sub-TLVs draw from a new registry for sub-TLV numbers; 381 this registry is to be created by IANA, and administered using the 382 first come first serve process. 384 3.1. PPR-Prefix Sub-TLV 386 The structure of PPR-Prefix is: 388 0 1 2 3 389 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 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Type | Length | MT-ID | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Prefix Length | Mask Length | IS-IS Prefix | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 // IS-IS Prefix (continued, variable) // 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | PPR-Prefix Sub-TLVs (variable) | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 Figure 3: PPR-Prefix Sub-TLV Format 402 o Type: TBD (IANA to assign from sub-TLV registry described above). 404 o Length: Total length of the value field in bytes. 406 o MT-ID: The multi-topology identifier defined in [RFC5120]; the 4 407 most significant bits MUST be set to 0 on transmit and ignored on 408 receive. The remaining 12-bit field contains the MT-ID. 410 o Prefix Length: The length of the prefix in bytes. For IPv4 it 411 MUST be 4 and IPv6 it MUST be 16 bytes. 413 o Mask Length: The length of the prefix in bits. Only the most 414 significant octets of the Prefix are encoded. 416 o IS-IS Prefix: The IS-IS prefix at the tail-end of the advertised 417 PPR. This corresponds to a routable prefix of the originating 418 node and it MAY have one of the [RFC7794] flags set (X-Flag/R- 419 Flag/N-Flag). Value of this field MUST be 4 octets for IPv4 420 Prefix and MUST be 16 octets for IPv6 Prefix. Encoding is similar 421 to TLV 135 [RFC5305] and TLV 236 [RFC5308] or MT-Capable [RFC5120] 422 IPv4 (TLV 235) and IPv6 Prefixes (TLV 237) respectively. 424 o PPR-Prefix Sub-TLVs - TBD. These have 1 octet type, 1 octet 425 length and value field is defined per the type field. 427 3.2. PPR-ID Sub-TLV 429 This is the actual data plane identifier in the packet header and 430 could be of any data plane as defined in PPR-ID Type field. Both 431 PPR-Prefix and PPR-ID MUST belong to a same node in the network. 433 0 1 2 3 434 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 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | Type | Length |PPR-ID Flags | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | PPR-ID Type | PPR-ID Length |PPR-ID Mask Len| Algo | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 // PPR-ID (variable size) // 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 Figure 4: PPR-ID Sub-TLV Format 445 o Type: TBD (IANA to assign from sub-TLV registry described above). 447 o Length: Total length of the value field in bytes. 449 o 451 * PPR-ID Flags: 2 Octet field for PPR-ID flags: 453 o 455 PPR-ID Flags Format 457 0 1 2 3 4 5 6 7.. 15 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 |L|A|Reserved | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 o 464 1. L: If set, the PPR path is a Loose-PPR. If the this flag is 465 unset, then the PPR path is a Strict-PPR. A Strict-PPR lists 466 every single node or adjacency in the path description from 467 source to the destination. 469 2. A: If set, all non-PPR path nodes in the IS-IS area/domain 470 MUST add a FIB entry for the PPR-ID with NH set to the 471 shortest path NH for the prefix being advertised. The use of 472 this is TBD. By default this flag MUST be unset. 474 3. Reserved: For future use; MUST be set to 0 on transmit and 475 ignored on receive. 477 o 478 * PPR-ID Type: Data plane type of PPR-ID. This is a new registry 479 (TBD IANA - Suggested values as below) for this Sub-TLV and the 480 defined types are as follows: 482 o 484 A. Type: 1 MPLS SID/Label 486 B. Type: 2 Native IPv4 Address/Prefix 488 C. Type: 3 Native IPv6 Address/Prefix 490 D. Type: 4 IPv6 SID in SRv6 with SRH 492 o PPR-ID Length: Length of the PPR-ID field in octets and this 493 depends on the PPR-ID type. See PPR-ID below for the length of 494 this field and other considerations. 496 o PPR-ID Mask Length: It is applicable for only for PPR-ID Type 2, 3 497 and 4. For Type 1 this value MUST be set to zero. It contains 498 the length of the PPR-ID Prefix in bits. Only the most 499 significant octets of the Prefix are encoded. This is needed, if 500 PPR-ID followed is an IPv4/IPv6 Prefix instead of 4/16 octet 501 Address respectively. 503 o Algo: 1 octet value represents the SPF algorithm. Algorithm 504 registry is as defined in 505 [I-D.ietf-isis-segment-routing-extensions]. 507 o PPR-ID: This is the Preferred Path forwarding identifier that 508 would be on the data packet. The value of this field is variable 509 and it depends on the PPR-ID Type - for Type 1, this is and MPLS 510 SID/Label. For Type 2 this is a 4 byte IPv4 address. For Type 3 511 this is a 16 byte IPv6 address. For Type 2 and Type 3 encoding is 512 similar to "IS-IS Prefix" as specified in Section 3.1. For Type 513 4, it is a 16 byte IPv6 SID. 515 For PPR-ID Type 2, 3 or 4, if the PPR-ID Len is set to non-zero 516 value, then the PPR-ID MUST NOT be advertised as a routable prefix in 517 TLV 135, TLV 235, TLV 236 and TLV 237. Also PPR-ID MUST belong to 518 the node where Prefix is advertised from. PPR-ID Len = 0 case is a 519 special case and is discussed in Section 4.1. 521 3.3. PPR-PDE Sub-TLV 523 This Sub-TLV represents the PPR Path Description Element (PDE). PPR- 524 PDEs are used to describe the path in the form of set of contiguous 525 and ordered Sub-TLVs, where first Sub-TLV represents (the top of the 526 stack in MPLS data plane or) first node/segment of the path. These 527 set of ordered Sub-TLVs can have both topological elements and non- 528 topological elements (e.g., service segments). 530 0 1 2 3 531 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 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | Type | Length | PPR-PDE Type | Reserved | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | PDE-ID Type | PDE-ID Len | PPR-PDE Flags | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 // PDE-ID Value (continued, variable size) // 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | PPR-PDE Sub-TLVs (variable) | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 Figure 5: PPR-PDE Sub-TLV Format 544 o Type: TBD (See IANA for suggested value) from IS-IS PPR TLV 545 Section 3 Sub-TLV registry. 547 o Length: Total length of the value field in bytes. 549 o PPR-PDE Type: A new registry (TBD IANA) for this Sub-TLV and the 550 defined types are as follows: 552 a. Type: 1 Topological 554 b. Type: 2 Non-Topological 556 o PDE-ID Type: 1 Octet PDE-forwarding IDentifier Type. A new 557 registry (TBD IANA) for this Sub-TLV and the defined types and 558 corresponding PDE-ID Len, PDE-ID Value are as follows: 560 a. Type 1: SID/Label type as defined in 561 [I-D.ietf-isis-segment-routing-extensions]. PDE-ID Len and PDE- 562 ID Value fields are per Section 2.3 of the referenced document. 564 b. Type 2: SR-MPLS Prefix SID. PDE-ID Len and PDE-ID Value are same 565 as Type 1. 567 c. Type 3: SR-MPLS Adjacency SID. PDE-ID Len and PDE-ID Value are 568 same as Type 1. 570 d. Type 4: IPv4 Address. PDE-ID Len is 4 bytes and PDE-ID Value is 571 4 bytes IPv4 address encoded similar to IPv4 Prefix described in 572 Section 3.1. 574 e. Type 5: IPv6 Address. PDE-ID Len is 16 bytes and PDE-ID Value is 575 16 bytes IPv6 address encoded similar to IPv6 Prefix described in 576 Section 3.1. 578 f. Type 6: SRv6 Node SID as defined in 579 [I-D.bashandy-isis-srv6-extensions]. PDE-ID Len and PDE-ID Value 580 are as defined in SRv6 SID from the refrenced draft. 582 g. Type 7: SRv6 Adjacency-SID. PDE-ID Len and PDE-ID Values are 583 similar to SRv6 Node SID above. 585 o PPR-PDE Flags: 2 Octet bit-field of flags; described below: 587 PPR-PDE Flags Format 589 0 1 2 3 4 5 6 7 .. 15 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 |L|D|Reserved | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 1. L: Loose Bit. Indicates the type of next "Topological PDE-ID" in 595 the path description and overrides the L bit in Section 3.2. If 596 set, the next PDE is Loose. If this flag is unset, the next 597 Topological PDE is Strict Type. 599 2. D: Destination bit. By default this bit MUST be unset. This bit 600 MUST be set only for PPR-PDE Type is 1 i.e., Topological and this 601 PDE represents the node PPR-Prefix Section 3.1 belongs to, if 602 there is no sub-sub-TLV to override PPR-Prefix and PPR-ID values. 604 3. Reserved: 1 Octet reserved bits for future use. Reserved bits 605 MUST be reset on transmission and ignored on receive. 607 o PPR-PDE Sub-TLVs: TBD. These have 1 octet type, 1 octet length 608 and value field is defined per the type field. 610 3.4. PPR-Attributes Sub-TLV 612 PPR-Attribute Sub-TLVs describe the attributes of the path. The 613 following sub-TLVs draw from a new registry for sub-TLV numbers; this 614 registry is to be created by IANA, and administered using the first 615 come first serve process: 617 o Type 1 (Suggested Value - IANA TBD): Packet Traffic accounting 618 Sub-TLV. Length 0 and no value field. Specifies to create a 619 counter to count number of packets forwarded on this PPR-ID on 620 each node in the path description. 622 o Type 2 (Suggested Value - IANA TBD): Traffic statistics in Bytes 623 Sub-TLV. Length 0 and no value field. Specifies to create a 624 counter to count number of bytes forwarded on this PPR-ID 625 specified in the network header (e.g. IPv4, IPv6) on each node in 626 the path description. 628 o Type 3 (Suggested Value - IANA TBD): PPR-Prefix originating node's 629 IPv4 Router ID Sub-TLV. Length and Value field are as specified 630 in [RFC7794]. 632 o Type 4 (Suggested Value - IANA TBD): PPR-Prefix originating node's 633 IPv6 Router ID Sub-TLV. Length and Value field are as specified 634 in [RFC7794]. 636 o Type 5 (Suggested Value - IANA TBD): PPR-Metric Sub-TLV. Length 4 637 bytes, and Value is metric of this path represented through the 638 PPR-ID. Different nodes can advertise the same PPR-ID for the 639 same Prefix with a different set of PPR-PDE Sub-TLVs and the 640 receiving node MUST consider the lowest metric value (TBD more, on 641 what happens when metric is same for two different set of PPR-PDE 642 Sub-TLVs). 644 4. PPR Processing Procedure Example 646 As specified in Section 2, a PPR can be a TE path, locally 647 provisioned by the operator or by a controller. Consider the 648 following IS-IS network to describe the operation of PPR TLV as 649 defined in Section 3: 651 1 652 _______ 653 / 1 \ 654 +---R2-------R3---+ 655 / \_______/ \ 656 / 1 \ 657 1 / \ 1 658 / 1__R13__1 \ 659 / / \ \ 660 R1------R6 R7-----------R4 661 \ 2 \__R14__/ 2 /\ 662 \ 2 2 / \ 663 3 \ / 3 \1 664 \ 4 / \ 665 +----R8------R9-----R10------R12 666 \ 1 / 667 1 \ / 1 668 +----R11---+ 670 Figure 6: IS-IS Network 672 In the (Figure 6) shown, consider node R1 as an ingress node, or a 673 head-end node, and the node R4 MAY be an egress node or another head- 674 end node. The numbers shown on links between nodes R1-R14 indicate 675 the bi-directional IS-IS metric as provisioned. R1 may be configured 676 to receive TE source routed path information from a central entity 677 (PCE [RFC5440], Netconf [RFC6241] or a Controller) that comprises of 678 PPR information which relates to sources that are attached to R1. It 679 is also possible to have a PPR provisioned locally by the operator 680 for non-TE needs (FRR or for chaining certain services). 682 The PPR TLV (as specified in Section 3) is encoded as an ordered list 683 of PPR-PDEs from source to a destination node in the network and is 684 represented with a PPR-ID Section 3.2. The PPR TLV includes PPR-PDE 685 Sub-TLVS Section 3.3, which represent both topological and non- 686 topological elements and specifies the actual path towards a PPR- 687 Prefix at R4. 689 o The shortest path towards R4 from R1 are through the following 690 sequence of nodes: R1-R2-R3-R4 based on the provisioned metrics. 692 o The central entity can define a few PPRs from R1 to R4 that 693 deviate from the shortest path based on other network 694 characteristic requirements as requested by an application or 695 service. For example, the network characteristics or performance 696 requirements may include bandwidth, jitter, latency, throughput, 697 error rate, etc. 699 o A first PPR may be identified by PPR-ID = 1 (value) and may 700 include the path of R1-R6-R7-R4 for a Prefix advertised by R4. 701 This is an example for a Loose-PPR and 'L' bit MUST be set on 702 Section 3.2. 704 o A second PPR may be identified by PPR-ID = 2 (value) and may 705 include the path of R1-R8-R9-R10-R4. This is an example for a 706 Strict-PPR and 'L' bit MUST be unset on Section 3.2. Though this 707 example shows PPR with all nodal SIDs, it is possible to have a 708 PPR with combination of node and adjacency SIDs (local or global) 709 or with PPR-PDE Type set to Non-Topological as defined in 710 Section 3.3 elements along with these. 712 4.1. PPR TLV Processing 714 The first topological sub-object or PDE (Section 3.3) relative to the 715 beginning of PPR Path contains the information about the first node 716 (e.g. in SR-MPLS it's the topmost label). The last topological sub- 717 object or PDE contains information about the last node (e.g. in SR- 718 MPLS it's the bottommost label). 720 Each receiving node, determine whether an advertised PPR includes 721 information regarding the receiving node. Before processing any 722 further, validation MUST be done to see if any PPR topological PDE is 723 seen more than once (possible loop), if yes, this PPR TLV MUST be 724 ignored. Processing of PPR TLVs can be done, during the end of the 725 SPF computation (for MTID that is advertised in this TLV) and for the 726 each prefix described through PPR TLV. For example, node R9 receives 727 the PPR information, and ignores the PPR-ID=1 (Section 4) because 728 this PPR TLV does not include node R9 in the path description/ordered 729 PPR-PDE list. 731 However, node R9 may determine that the second PPR identified by PPR- 732 ID = 2 does include the node R9 in its PDE list. Therefore, node R9 733 updates the local forwarding database to include an entry for the 734 destination address of R4 indicates, that when a data packet 735 comprising a PPR-ID of 2 is received, forward the data packet to node 736 R10 instead of R11. This is even though from R9 the shortest path to 737 reach R4 via R11 (Cost 3: R9-R11-R12-R4) it chooses the nexthop to 738 R10 to reach R4 as specified in the PPR path description. Same 739 process happens to all nodes or all topological PDEs as described in 740 the PPR TLV. 742 In summary, the receiving node checks first, if this node is on the 743 path by checking the node's topological elements (with PPR-PDE Type 744 set to Topological) in the path list. If yes, it adds/adjusts the 745 shortest path nexthop computed towards PPR Prefix to the shortest 746 path nexthop towards the next topological PDE in the PPR's Path. 748 For PPR-ID (Section 3.2) Type 2, 3 or 4, if the PPR-ID Len is set to 749 0, then Prefix would also become the PPR-ID (a special case). This 750 can be used for some situations, where certain optimizations are 751 required in the network. For this, path described in the PPR TLV 752 SHOULD be completely dis-joint from the shortest path route to the 753 prefix. If the disjoint-ness property is not maintained then the 754 traffic MAY not be using the PPR path, as and when it encounters any 755 node which is not in the path description. 757 5. PPR Data Plane aspects 759 Data plane for PPR-ID is selected by the entity (e.g., a controller, 760 locally provisioned by operator), which selects a particular PPR in 761 the network. Section 3.2 defines various data plane identifier types 762 and a corresponding data plane identifier is selected by the entity 763 which selects the PPR. Other data planes other than described below 764 can also use this TLV to describe the PPR. Further details TBD. 766 5.1. SR-MPLS with PPR 768 If PPR-ID Type is 1, then the PPR belongs to SR-MPLS data plane and 769 the complete PPR stack is represented with a unique SR SID/Label and 770 this gets programmed on the data plane of each node, with the 771 appropriate nexthop computed as specified in Section 4. PPR-ID here 772 is a label/index from the SRGB (like another node SID or global-ADJ 773 SID). PPR path description here is a set of ordered SIDs represented 774 with PPR-PDE (Section 3.2) Sub-TLVs. Non-Topological segments also 775 programmed in the forwarding to enable specific function/service, 776 when the data packet hits with corresponding PPR-ID. 778 Based on 'L' flag in PPR-ID Flags (Section 3.2), for SR-MPLS data 779 plane either 1 label or 2 labels need to be provisioned on individual 780 nodes on the path description. For the example network in Section 4, 781 for PPR-ID=1, which is a loose path, node R6 programs the bottom 782 label as PPR-ID and the top label as the next topological PPR-PDE in 783 the path, which is a node SID of R7. The NH computed at R6 would be 784 the shortest path towards R7 i.e., the interface towards R13. If 'L' 785 flag is unset only PPR-ID is programmed on the data plane with NH set 786 to the shortest path towards next topological PPR-PDE. 788 5.2. SRv6 with PPR 790 If PPR-ID Type is 4, the PPR belongs to SRv6 with SRH data plane and 791 the complete PPR stack is represented with IPv6 SIDs and this gets 792 programmed on the data plane with the appropriate nexthop computed as 793 specified in Section 4. PPR-ID here is a SRv6 SID. PPR path 794 description here is a set of ordered SID TLVs similar to as specified 795 in Section 5.1. One way PPR-ID would be used in this case is by 796 setting the same as the destination IPv6 address and SL field in SRH 797 would be set to 0; however SRH [I-D.ietf-6man-segment-routing-header] 798 can contain any other TLVs and non-topological SIDs as needed. 800 5.3. PPR Native IP Data Planes 802 If PPR-ID Type is 2 then source routing and packet steering can be 803 done in IPv4 data plane (PPR-IPv4), along the path as described in 804 PPR Path description. This is achieved by setting the destination IP 805 address as PPR-ID, which is an IPv4 address in the data packet 806 (tunneled/encapsulated). There is no data plane change or upgrade 807 needed to support this. However this is applicable to only Strict- 808 PPR paths ('L' bit as specified in Section 3.2 MUST be unset). 810 Similarly for PPR-ID Type is 3, then source routing and packet 811 steering can be done in IPv6 data plane (PPR-IPv6), along the path as 812 described in PPR Path description. Whatever specified above for IPv4 813 applies here too, except that destination IP address of the data 814 packet is IPv6 Address (PPR-ID). This doesn't require any IPv6 815 extension headers (EH), if there is no metadata/TLVs need to be 816 carried in the data packet. 818 6. PPR Scaling Considerations 820 In a network of N nodes O(N^2) total (unidirectional) paths are 821 necessary to establish any-to-any connectivity, and multiple (k) such 822 path sets may be desirable if multiple path policies are to be 823 supported (lowest latency, highest throughput etc.). 825 In many solutions and topologies, N may be small enough and/or only a 826 small set of paths need to be preferred paths, for example for high 827 value traffic (DetNet, some of the defined 5G slices), and then the 828 technology specified in this document can support these deployments. 830 However, to address the scale needed when a larger number of PPR 831 paths are required, the PPR TREE structure can be used [I-D.draft-ce- 832 ppr-graph-00]. Each PPR Tree uses one label/SID and defines paths 833 from any set of nodes to one destination, thus reduces the number of 834 entries needed in SRGB at each node (for SR-MPLS data plane 835 Section 5.1). These paths form a tree rooted in the destination. In 836 other word, PPR Tree identifiers are destination identifiers and PPR 837 Treed are path engineered destination routes (like IP routes) and it 838 scaling simplifies to linear in N i.e., O(k*N). 840 7. PPR Traffic Accounting 842 Section 3.4 defines few PPR-Attributes to indicate creation of 843 traffic accounting statistics in each node of the PPR path 844 description. Presence of "Packet Traffic Accounting" and "Traffic 845 Statistics" Sub-TLVs instruct to provision the hardware, to account 846 for the respective traffic statistics. Traffic accounting should 847 happen, when the actual data traffic hits for the PPR-ID in the 848 forwarding plane. This allows more granular and dynamic enablement 849 of traffic statistics for only certain PPRs as needed. 851 This approach, thus is more safe and secure than any mechanism that 852 involves creation of the state in the nodes with the data traffic 853 itself. This is because, creation and deletion of the traffic 854 accounting state for PPRs happen through IS-IS LSP processing and IS- 855 IS protocol control plane security Section 10 options are applicable 856 to this TLV. 858 How the traffic accounting is distributed to a central entity is out 859 of scope of this document. One can use any method (e.g. gRPC) to 860 extract the PPR-ID traffic stats from various nodes along the path. 862 8. Acknowledgements 864 Thanks to Alex Clemm, Lin Han, Toerless Eckert and Kiran Makhijani 865 for initial discussions on this topic. Thanks to Kevin Smith and 866 Stephen Johnson for various deployment scenarios applicability from 867 ETSI WGs perspective. Authors also acknowledge Alexander Vainshtein 868 for detailed discussions and suggestions on this topic. 870 Earlier versions of draft-ietf-isis-segment-routing-extensions have a 871 mechanism to advertise EROs through Binding SID. 873 9. IANA Considerations 875 This document requests the following new TLV in IANA IS-IS TLV code- 876 point registry. 878 TLV # Name 879 ----- -------------- 880 TBD PPR TLV 882 This document requests IANA to create a new Sub-TLV registry for PPR 883 TLV Section 3 with the following initial entries (suggested values): 885 Sub-TLV # Sub-TLV Name 886 --------- --------------------------------------------------------- 887 1 PPR-Prefix (Section 3.1) 889 2 PPR-ID (Section 3.2) 891 3 PPR-PDE (Section 3.3) 893 This document also requests IANA to create a new Sub-TLV registry for 894 PPR Path attributes with the following initial entries (suggested 895 values): 897 Sub-TLV # Sub-TLV Name 898 --------- --------------------------------------------------------- 900 1 Packet Traffic Accounting (Section 3.4) 902 2 Traffic Statistics (Section 3.4) 904 3 PPR-Prefix Source IPv4 Router ID (Section 3.4) 906 4 PPR-Prefix Source IPv6 Router ID (Section 3.4) 908 5 PPR-Metric (Section 3.4) 910 This document requests additional IANA registries in an IANA managed 911 registry "Interior Gateway Protocol (IGP) Parameters" for various PPR 912 TLV parameters. The registration procedure is based on the "Expert 913 Review" as defined in [RFC8126]. The suggested registry names are: 915 o "PPR-Type" - Types are an unsigned 8 bit numbers. Values are as 916 defined in Section 3 of this document. 918 o "PPR-Flags" - 1 Octet. Bits as described in Section 3 of this 919 document. 921 o "PPR-ID Type" - Types are an unsigned 8 bit numbers. Values are 922 as defined in Section 3.2 of this document. 924 o "PPR-ID Flags" - 1 Octet. Bits as described in Section 3.2 of 925 this document. 927 o "PPR-PDE Type" - Types are an unsigned 8 bit numbers. Values are 928 as defined in Section 3.3 of this document. 930 o "PPR-PDE Flags" - 1 Octet. Bits as described in Section 3.3 of 931 this document. 933 o "PDE-ID Type" - Types are an unsigned 8 bit numbers. Values are 934 as defined in Section 3.3 of this document. 936 10. Security Considerations 938 Security concerns for IS-IS are addressed in [RFC5304] and [RFC5310]. 939 Further security analysis for IS-IS protocol is done in [RFC7645] 940 with detailed analysis of various security threats and why [RFC5304] 941 should not be used in the deployments. Advertisement of the 942 additional information defined in this document introduces no new 943 security concerns in IS-IS protocol. However as this extension is 944 related to SR-MPLS and SRH data planes as defined in 945 [I-D.ietf-spring-segment-routing], those particular data plane 946 security considerations does apply here. 948 11. References 950 11.1. Normative References 952 [I-D.ietf-isis-segment-routing-msd] 953 Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 954 "Signaling MSD (Maximum SID Depth) using IS-IS", draft- 955 ietf-isis-segment-routing-msd-12 (work in progress), May 956 2018. 958 [I-D.ietf-spring-segment-routing] 959 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 960 Litkowski, S., and R. Shakir, "Segment Routing 961 Architecture", draft-ietf-spring-segment-routing-15 (work 962 in progress), January 2018. 964 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 965 Requirement Levels", BCP 14, RFC 2119, 966 DOI 10.17487/RFC2119, March 1997, 967 . 969 11.2. Informative References 971 [I-D.bashandy-isis-srv6-extensions] 972 Ginsberg, L., Psenak, P., Filsfils, C., Bashandy, A., 973 Decraene, B., and Z. Hu, "IS-IS Extensions to Support 974 Routing over IPv6 Dataplane", draft-bashandy-isis- 975 srv6-extensions-03 (work in progress), June 2018. 977 [I-D.cheng-spring-mpls-path-segment] 978 Cheng, W., Wang, L., Li, H., Chen, M., Zigler, R., and S. 979 Zhan, "Path Segment in MPLS Based Sement Routing Network", 980 draft-cheng-spring-mpls-path-segment-01 (work in 981 progress), March 2018. 983 [I-D.hegde-spring-traffic-accounting-for-sr-paths] 984 Hegde, S., "Traffic Accounting for MPLS Segment Routing 985 Paths", draft-hegde-spring-traffic-accounting-for-sr- 986 paths-01 (work in progress), October 2017. 988 [I-D.ietf-6man-segment-routing-header] 989 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 990 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 991 (SRH)", draft-ietf-6man-segment-routing-header-14 (work in 992 progress), June 2018. 994 [I-D.ietf-isis-mpls-elc] 995 Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S. 996 Litkowski, "Signaling Entropy Label Capability and 997 Readable Label-stack Depth Using IS-IS", draft-ietf-isis- 998 mpls-elc-03 (work in progress), January 2018. 1000 [I-D.ietf-isis-segment-routing-extensions] 1001 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 1002 Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura, 1003 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 1004 segment-routing-extensions-18 (work in progress), June 1005 2018. 1007 [I-D.ietf-mpls-sfc] 1008 Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based 1009 Forwarding Plane for Service Function Chaining", draft- 1010 ietf-mpls-sfc-01 (work in progress), May 2018. 1012 [I-D.xuclad-spring-sr-service-chaining] 1013 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 1014 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 1015 Henderickx, W., and S. Salsano, "Segment Routing for 1016 Service Chaining", draft-xuclad-spring-sr-service- 1017 chaining-01 (work in progress), March 2018. 1019 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1020 Topology (MT) Routing in Intermediate System to 1021 Intermediate Systems (IS-ISs)", RFC 5120, 1022 DOI 10.17487/RFC5120, February 2008, 1023 . 1025 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 1026 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 1027 2008, . 1029 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1030 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1031 2008, . 1033 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 1034 DOI 10.17487/RFC5308, October 2008, 1035 . 1037 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 1038 and M. Fanto, "IS-IS Generic Cryptographic 1039 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 1040 2009, . 1042 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1043 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1044 DOI 10.17487/RFC5440, March 2009, 1045 . 1047 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1048 and A. Bierman, Ed., "Network Configuration Protocol 1049 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1050 . 1052 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 1053 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 1054 RFC 6790, DOI 10.17487/RFC6790, November 2012, 1055 . 1057 [RFC7645] Chunduri, U., Tian, A., and W. Lu, "The Keying and 1058 Authentication for Routing Protocol (KARP) IS-IS Security 1059 Analysis", RFC 7645, DOI 10.17487/RFC7645, September 2015, 1060 . 1062 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 1063 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 1064 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 1065 March 2016, . 1067 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1068 Writing an IANA Considerations Section in RFCs", BCP 26, 1069 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1070 . 1072 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1073 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1074 May 2017, . 1076 Authors' Addresses 1078 Uma Chunduri 1079 Huawei USA 1080 2330 Central Expressway 1081 Santa Clara, CA 95050 1082 USA 1084 Email: uma.chunduri@huawei.com 1086 Richard Li 1087 Huawei USA 1088 2330 Central Expressway 1089 Santa Clara, CA 95050 1090 USA 1092 Email: renwei.li@huawei.com 1094 Russ White 1095 LinkedIn 1096 Oak Island, NC 28465 1097 USA 1099 Email: russ@riw.us 1101 Jeff Tantsura 1102 Nuage Networks 1103 755 Ravendale Drive 1104 Mountain View, CA 94043 1105 USA 1107 Email: jefftant.ietf@gmail.com 1109 Luis M. Contreras 1110 Telefonica 1111 Sur-3 building, 3rd floor 1112 Madrid 28050 1113 Spain 1115 Email: luismiguel.contrerasmurillo@telefonica.com 1116 Yingzhen Qu 1117 Huawei USA 1118 2330 Central Expressway 1119 Santa Clara, CA 95050 1120 USA 1122 Email: yingzhen.qu@huawei.com 1124 LSR Working Group U. Chunduri 1125 Internet-Draft R. Li 1126 Intended status: Standards Track Huawei USA 1127 Expires: January 3, 2019 R. White 1128 LinkedIn 1129 J. Tantsura 1130 Nuage Networks 1131 L. Contreras 1132 Telefonica 1133 Y. Qu 1134 Huawei USA 1135 July 2, 2018 1137 Preferred Path Routing (PPR) in IS-IS 1138 draft-chunduri-lsr-isis-preferred-path-routing-01 1140 Abstract 1142 This document specifies a Preferred Path Routing (PPR) mechanism to 1143 simplify the path description of data plane traffic in Segment 1144 Routing (SR) deployments. PPR aims to mitigate the MTU and data 1145 plane processing issues that may result from SR packet overheads; and 1146 also supports traffic measurement, accounting statistics and further 1147 attribute extensions along the paths. Preferred Path Routing is 1148 achieved through the addition of descriptions to IS-IS advertised 1149 prefixes, and mapping those to a PPR data-plane identifier. 1151 Requirements Language 1153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 1154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 1155 document are to be interpreted as described in RFC2119 [RFC2119], 1156 RFC8174 [RFC8174] when, and only when they appear in all capitals, as 1157 shown here. 1159 Status of This Memo 1161 This Internet-Draft is submitted in full conformance with the 1162 provisions of BCP 78 and BCP 79. 1164 Internet-Drafts are working documents of the Internet Engineering 1165 Task Force (IETF). Note that other groups may also distribute 1166 working documents as Internet-Drafts. The list of current Internet- 1167 Drafts is at https://datatracker.ietf.org/drafts/current/. 1169 Internet-Drafts are draft documents valid for a maximum of six months 1170 and may be updated, replaced, or obsoleted by other documents at any 1171 time. It is inappropriate to use Internet-Drafts as reference 1172 material or to cite them other than as "work in progress." 1174 This Internet-Draft will expire on January 3, 2019. 1176 Copyright Notice 1178 Copyright (c) 2018 IETF Trust and the persons identified as the 1179 document authors. All rights reserved. 1181 This document is subject to BCP 78 and the IETF Trust's Legal 1182 Provisions Relating to IETF Documents 1183 (https://trustee.ietf.org/license-info) in effect on the date of 1184 publication of this document. Please review these documents 1185 carefully, as they describe your rights and restrictions with respect 1186 to this document. Code Components extracted from this document must 1187 include Simplified BSD License text as described in Section 4.e of 1188 the Trust Legal Provisions and are provided without warranty as 1189 described in the Simplified BSD License. 1191 Table of Contents 1193 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1194 1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 1195 1.2. Challenges with Increased SID Depth . . . . . . . . . . . 4 1196 1.3. Mitigation with MSD . . . . . . . . . . . . . . . . . . . 5 1197 2. Preferred Path Routing (PPR) . . . . . . . . . . . . . . . . 6 1198 2.1. PPR-ID and PPR Path Description . . . . . . . . . . . . . 6 1199 3. PPR Related TLVs . . . . . . . . . . . . . . . . . . . . . . 7 1200 3.1. PPR-Prefix Sub-TLV . . . . . . . . . . . . . . . . . . . 9 1201 3.2. PPR-ID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 9 1202 3.3. PPR-PDE Sub-TLV . . . . . . . . . . . . . . . . . . . . . 11 1203 3.4. PPR-Attributes Sub-TLV . . . . . . . . . . . . . . . . . 13 1204 4. PPR Processing Procedure Example . . . . . . . . . . . . . . 14 1205 4.1. PPR TLV Processing . . . . . . . . . . . . . . . . . . . 16 1206 5. PPR Data Plane aspects . . . . . . . . . . . . . . . . . . . 17 1207 5.1. SR-MPLS with PPR . . . . . . . . . . . . . . . . . . . . 17 1208 5.2. SRv6 with PPR . . . . . . . . . . . . . . . . . . . . . . 17 1209 5.3. PPR Native IP Data Planes . . . . . . . . . . . . . . . . 18 1210 6. PPR Scaling Considerations . . . . . . . . . . . . . . . . . 18 1211 7. PPR Traffic Accounting . . . . . . . . . . . . . . . . . . . 19 1212 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 1213 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 1214 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 1215 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 1216 11.1. Normative References . . . . . . . . . . . . . . . . . . 21 1217 11.2. Informative References . . . . . . . . . . . . . . . . . 21 1218 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 1220 1. Introduction 1222 In a network implementing Segment Routing (SR), packets are steered 1223 through the network using Segment Identifiers (SIDs) carried in the 1224 packet header. Each SID uniquely identifies a segment as defined in 1225 [I-D.ietf-spring-segment-routing]. SR capabilities are defined for 1226 MPLS and IPv6 data planes called SR-MPLS and SRv6 respectively. 1228 In SR-MPLS, each segment is encoded as a label, and an ordered list 1229 of segments are encoded as a stack of labels. This stack of labels 1230 is carried as part of the packet header. In SRv6, a segment is 1231 encoded as an IPv6 address, within a new type of IPv6 hop-by-hop 1232 routing header/extension header (EH) called SRH 1233 [I-D.ietf-6man-segment-routing-header]; an ordered list of IPv6 1234 addresses/segments are encoded in SRH. 1236 Section 1.2 and Section 1.3 describe performance, hardware 1237 capabilities and various associated issues which may result in SR 1238 deployments. These motivate the proposed solution, Preferred Path 1239 Routing, which is specified in Section 2. 1241 1.1. Acronyms 1243 EL - Entropy Label 1245 ELI - Entropy Label Indicator 1247 LSP - IS-IS Link State PDU 1249 MPLS - Multi Protocol Label Switching 1251 MSD - Maximum SID Depth 1253 MTU - Maximum Transferrable Unit 1255 PPR - Preferred Path Routing/Route 1257 PPR-ID - Preferred Path Route Identifier, a data plane identifier 1259 SID - Segment Identifier 1261 SPF - Shortest Path First 1263 SR-MPLS - Segment Routing with MPLS data plane 1265 SRH - Segment Routing Header - IPv6 routing Extension headr 1267 SRv6 - Segment Routing with Ipv6 data plane with SRH 1268 TE - Traffic Engineering 1270 1.2. Challenges with Increased SID Depth 1272 SR label stacks carried in the packet header create challenges in the 1273 design and deployment of networks and networking equipment. 1274 Following examples illustrates the need for increased SID depth in 1275 various use cases: 1277 (a). Consider the following network where SR-MPLS data plane is in 1278 use and with same SRGB (5000-6000) on all nodes i.e., A1 to A7 and B1 1279 to B7 for illustration: 1281 SID:10 SID:20 SID:30 SID:40 SID:50 SID:300(Ax) SID:60 SID:70 1282 A1-------A2-------A3-------A4-------A5===============A6----------A7 1283 \ / \5 5/ \ SID:310(Ay) \ / 1284 \ 10 10/ +-A10-+ \ \10 /10 1285 \ / SID:100 \ \ / 1286 SID:80 \A8-----A9/SID:90 \ 40 \ / 1287 / \ +---+ \ / 1288 /10 B2x:125 \10 \ \/ 1289 B1--------B2============B3----B4--------B5-------B6----------B7 1290 SID:110 SID:120 SID:130 SID:140 SID:150 SID:160 SID:170 1292 Figure 1: SR-MPLS Network 1294 Global ADJ SIDs are provisioned between A5-A6 and B2-B3. All 1295 other SIDs shown are nodal SID indices. 1297 All metrics of the links are set to 1, unless marked otherwise. 1299 Shortest Path from A1 to A7: A2-A3-A4-A5-A6-A7 1301 Path-x: From A1 to A7 - A2-A8-B2-B2x-A9-A10-Ax-A7; Pushed Label 1302 Stack @A1: 5020:5080:5120:5125:5090:5100:5300:5070 (where B2x is a 1303 local ADJ-SID and Ax is a global ADJ-SID). 1305 In this example, the traffic engineered path is represented with a 1306 combination of Adjacency and Node SIDs with a stack of 8 labels. 1307 However, this value can be larger, if the use of entropy label 1308 [RFC6790] is desired and based on the Readable Label Depth 1309 (Section 1.3) capabilities of each node and additional labels 1310 required to insert ELI/EL at appropriate places. 1312 Though above network is shown with SR-MPLS data plane, if the 1313 network were to use SR-IPv6 data plane, path size would be 1314 increased even more because of the size of the IPv6 SID (16 bytes) 1315 in SRH. 1317 (b). Apart from the TE case above, when deploying 1318 [I-D.ietf-mpls-sfc] or [I-D.xuclad-spring-sr-service-chaining], with 1319 the inclusion of services, or non-topological segments on the label 1320 stack, can also make the size of the stack much larger. 1322 (c). Some SR-MPLS deployments need accounting statistics for path 1323 monitoring and traffic re-optimizations. 1324 [I-D.hegde-spring-traffic-accounting-for-sr-paths] and 1325 [I-D.cheng-spring-mpls-path-segment] propose solutions with various 1326 forms of path segments (either with special labels or PATH segment 1327 encoded at the bottom of the stack respectively). However, these 1328 proposals further increases the depth of SID stack, when it is 1329 compounded with MSD/RLDs of various nodes in the path. 1331 Overall the additional path overhead in various SR deployments may 1332 cause the following issues: 1334 a. HW Capabilities: Not all nodes in the path can support the 1335 ability to push or read label stack needed 1336 [I-D.ietf-isis-segment-routing-msd] to satisfy user/operator 1337 requirements, Alternate paths which meet these user/operator 1338 requirements may not be available. 1340 b. Line Rate: Potential performance issues in deployments, which use 1341 SRH data plane with the increased size of the SRH with 16 byte 1342 SIDs. 1344 c. MTU: Larger SID stacks on the data packet can cause potential 1345 MTU/fragmentation issues. 1347 d. Header Tax: Some deployments, such as 5G, require minimal packet 1348 overhead in order to conserve network resources. Carrying 40 or 1349 50 octets of data in a packet with hundreds of octet of header 1350 would be an unacceptable use of available bandwidth. 1352 With the solution proposed in this document (Section 5) and 1353 Section 4), for Path-x in the example network Figure 1 above, SID 1354 stack would be reduced from 8 SIDs to a single SID. 1356 1.3. Mitigation with MSD 1358 The number of SIDs in the stack a node can impose is referred as 1359 Maximum SID Depth (MSD) capability 1360 [I-D.ietf-isis-segment-routing-msd], which must be taken into 1361 consideration when computing a path to transport a data packet in a 1362 network implementing segment routing. [I-D.ietf-isis-mpls-elc] 1363 defines another MSD type, Readable Label Depth (RLD) that is used by 1364 a head-end to insert Entropy Label pair (ELI/EL) at appropriate 1365 depth, so it could be read by transit nodes. There are situations 1366 where the source routed path can be excessive as path represented by 1367 SR SIDs need to describe all the nodes and ELI/EL based on the 1368 readability of the nodes in that path. 1370 MSDs (and RLD type) capabilities advertisement help mitigate the 1371 problem for a central entity to create the right source routed path 1372 per application/operator requirements. However the availability of 1373 actual paths meeting these requirements are still limited by the 1374 underlying hardware and their MSD capabilities in the data path. 1376 2. Preferred Path Routing (PPR) 1378 PPR mitigates the issues described in Section 1.2, while continuing 1379 to allow the direction of traffic along an engineered path through 1380 the network by replacing the label stack with a PPR-ID. The PPR-ID 1381 can either be a single label or a native destination address. To 1382 facilitate the use of a single label to describe an entire path, a 1383 new TLV is added to IS-IS, as described below in Section 3. 1385 A PPR could be an SR path, a traffic engineered path computed based 1386 on some constraints, an explicitly provisioned Fast Re-Route (FRR) 1387 path or a service chained path. A PPR can be signaled by any node, 1388 computed by a central controller, or manually configured by an 1389 operator. PPR extends the source routing and path steering 1390 capabilities to native IP (IPv4 and IPv6) data planes without 1391 hardware upgrades; see Section 5. 1393 2.1. PPR-ID and PPR Path Description 1395 The PPR-ID describes a path through the network. For SR- MPLS this 1396 is an MPLS Label/SID and for SRv6 this is an IPv6-SID. For native IP 1397 data planes this is either IPv4 or IPv6 address/prefix. 1399 The path identified by the PPR-ID is described as a set of Path 1400 Description Elements (PDEs), each of which represents a segment of 1401 the path. Each node determines location in the path as described, 1402 and forwards to the next segment/hop or label of the path description 1403 (see the Forwarding Procedure Example later in this document). 1405 These PPR-PDEs as defined in Section 3.3, like SR SIDs, can represent 1406 topological elements like links/nodes, backup nodes, as well as non- 1407 topological elements such as a service, function, or context on a 1408 particular node. PPR-PDE optionally, can also have more information 1409 as described with in their Sub-TLVs. 1411 A PPR path can be described as a Strict-PPR or a Loose-PPR. In a 1412 Strict-PPR all nodes/links on the path are described with SR SIDs for 1413 SR data planes or IPv4/IPV6 addresses for native IP data planes. In 1414 a Loose-PPR only some of the nodes/links from source to destination 1415 are described. More specifics and restrictions around Strict/Loose 1416 PPRs are described in respective data planes in Section 5. Each PDE 1417 is described as either an MPLS label towards the next hop in MPLS 1418 enabled networks, or as an IP next hop, in the case of either 1419 "plain"/"native" IP or SRv6 enabled networks. A PPR path is related 1420 to a set of PDEs using the following TLVs. 1422 3. PPR Related TLVs 1424 This section describes the encoding of PPR TLV. This TLV can be seen 1425 as having 4 logical section viz., encoding of the PPR-Prefix (IS-IS 1426 Prefix), encoding of PPR-ID, encoding of path description with an 1427 ordered PDE Sub-TLVs and a set of optional PPR attribute Sub-TLVs, 1428 which can be used to describe one or more parameters of the path. 1429 Multiple instances of this TLV MAY be advertised in IS-IS LSPs with 1430 different PPR-ID Type and with corresponding PDE Sub-TLVS. The PPR 1431 TLV has Type TBD (suggested value xxx), and has the following format: 1433 0 1 2 3 1434 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 1435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1436 | Type | Length | PPR-Flags | 1437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1438 | PPR-Prefix Sub-TLV (variable size) | 1439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1440 | PPR-ID Sub-TLV (variable size) | 1441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1442 | PPR-PDE Sub-TLVs (variable) | 1443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1444 | PPR-Attribute Sub-TLVs (variable) | 1445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1447 Figure 2: PPR TLV Format 1449 o Type: TBD (IANA) from IS-IS top level TLV registry. 1451 o Length: Total length of the value field in bytes. 1453 o PPR-Flags: 2 Octet bit-field of flags for this TLV; described 1454 below. 1456 o PPR-Prefix: A variable size sub-TLV representing the destination 1457 of the path being described. This is defined in Section 3.1. 1459 o PPR-ID: A variable size Sub-TLV representing the data plane or 1460 forwarding identifier of the PPR. Defined in Section 3.2. 1462 o PPR-PDEs: Variable number of ordered PDE Sub-TLVs which represents 1463 the path. This is defined in Section 3.3. 1465 o PPR-Attributes: Variable number of PPR-Attribute Sub-TLVs which 1466 represent the path attributes. These are defined in Section 3.4. 1468 The Flags field has the following flag bits defined: 1470 PPR TLV Flags Format 1472 0 1 2 3 4 5 6 7 15 1473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1474 |S|D|A| Reserved | 1475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1477 1. S: If set, the PPR TLV MUST be flooded across the entire routing 1478 domain. If the S flag is not set, the PPR TLV MUST NOT be leaked 1479 between IS-IS levels. This bit MUST NOT be altered during the 1480 TLV leaking 1482 2. D: When the PPR TLV is leaked from IS-IS level-2 to level-1, the 1483 D bit MUST be set. Otherwise, this bit MUST be clear. PPR TLVs 1484 with the D bit set MUST NOT be leaked from level-1 to level-2. 1485 This is to prevent TLV looping across levels. 1487 3. A: The originator of the PPR TLV MUST set the A bit in order to 1488 signal that the prefixes and PPR-IDs advertised in the PPR TLV 1489 are directly connected to the originators. If this bit is not 1490 set, this allows any other node in the network advertise this TLV 1491 on behalf of the originating node of the PPR-Prefix. If PPR TLV 1492 is leaked to other areas/levels the A-flag MUST be cleared. In 1493 case if the originating node of the prefix must be disambiguated 1494 for any reason including, if it is a Multi Homed Prefix (MHP) or 1495 leaked to a different IS-IS level or because [RFC7794] X-Flag is 1496 set, then PPR-Attribute Sub-TLV Source Router ID SHOULD be 1497 included. 1499 4. Reserved: For future use; MUST be set to 0 on transmit and 1500 ignored on receive. 1502 The following sub-TLVs draw from a new registry for sub-TLV numbers; 1503 this registry is to be created by IANA, and administered using the 1504 first come first serve process. 1506 3.1. PPR-Prefix Sub-TLV 1508 The structure of PPR-Prefix is: 1510 0 1 2 3 1511 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 1512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1513 | Type | Length | MT-ID | 1514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1515 | Prefix Length | Mask Length | IS-IS Prefix | 1516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1517 // IS-IS Prefix (continued, variable) // 1518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1519 | PPR-Prefix Sub-TLVs (variable) | 1520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1522 Figure 3: PPR-Prefix Sub-TLV Format 1524 o Type: TBD (IANA to assign from sub-TLV registry described above). 1526 o Length: Total length of the value field in bytes. 1528 o MT-ID: The multi-topology identifier defined in [RFC5120]; the 4 1529 most significant bits MUST be set to 0 on transmit and ignored on 1530 receive. The remaining 12-bit field contains the MT-ID. 1532 o Prefix Length: The length of the prefix in bytes. For IPv4 it 1533 MUST be 4 and IPv6 it MUST be 16 bytes. 1535 o Mask Length: The length of the prefix in bits. Only the most 1536 significant octets of the Prefix are encoded. 1538 o IS-IS Prefix: The IS-IS prefix at the tail-end of the advertised 1539 PPR. This corresponds to a routable prefix of the originating 1540 node and it MAY have one of the [RFC7794] flags set (X-Flag/R- 1541 Flag/N-Flag). Value of this field MUST be 4 octets for IPv4 1542 Prefix and MUST be 16 octets for IPv6 Prefix. Encoding is similar 1543 to TLV 135 [RFC5305] and TLV 236 [RFC5308] or MT-Capable [RFC5120] 1544 IPv4 (TLV 235) and IPv6 Prefixes (TLV 237) respectively. 1546 o PPR-Prefix Sub-TLVs - TBD. These have 1 octet type, 1 octet 1547 length and value field is defined per the type field. 1549 3.2. PPR-ID Sub-TLV 1551 This is the actual data plane identifier in the packet header and 1552 could be of any data plane as defined in PPR-ID Type field. Both 1553 PPR-Prefix and PPR-ID MUST belong to a same node in the network. 1555 0 1 2 3 1556 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 1557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1558 | Type | Length |PPR-ID Flags | 1559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1560 | PPR-ID Type | PPR-ID Length |PPR-ID Mask Len| Algo | 1561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1562 // PPR-ID (variable size) // 1563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1565 Figure 4: PPR-ID Sub-TLV Format 1567 o Type: TBD (IANA to assign from sub-TLV registry described above). 1569 o Length: Total length of the value field in bytes. 1571 o 1573 * PPR-ID Flags: 2 Octet field for PPR-ID flags: 1575 o 1577 PPR-ID Flags Format 1579 0 1 2 3 4 5 6 7.. 15 1580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1581 |L|A|Reserved | 1582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1584 o 1586 1. L: If set, the PPR path is a Loose-PPR. If the this flag is 1587 unset, then the PPR path is a Strict-PPR. A Strict-PPR lists 1588 every single node or adjacency in the path description from 1589 source to the destination. 1591 2. A: If set, all non-PPR path nodes in the IS-IS area/domain 1592 MUST add a FIB entry for the PPR-ID with NH set to the 1593 shortest path NH for the prefix being advertised. The use of 1594 this is TBD. By default this flag MUST be unset. 1596 3. Reserved: For future use; MUST be set to 0 on transmit and 1597 ignored on receive. 1599 o 1600 * PPR-ID Type: Data plane type of PPR-ID. This is a new registry 1601 (TBD IANA - Suggested values as below) for this Sub-TLV and the 1602 defined types are as follows: 1604 o 1606 A. Type: 1 MPLS SID/Label 1608 B. Type: 2 Native IPv4 Address/Prefix 1610 C. Type: 3 Native IPv6 Address/Prefix 1612 D. Type: 4 IPv6 SID in SRv6 with SRH 1614 o PPR-ID Length: Length of the PPR-ID field in octets and this 1615 depends on the PPR-ID type. See PPR-ID below for the length of 1616 this field and other considerations. 1618 o PPR-ID Mask Length: It is applicable for only for PPR-ID Type 2, 3 1619 and 4. For Type 1 this value MUST be set to zero. It contains 1620 the length of the PPR-ID Prefix in bits. Only the most 1621 significant octets of the Prefix are encoded. This is needed, if 1622 PPR-ID followed is an IPv4/IPv6 Prefix instead of 4/16 octet 1623 Address respectively. 1625 o Algo: 1 octet value represents the SPF algorithm. Algorithm 1626 registry is as defined in 1627 [I-D.ietf-isis-segment-routing-extensions]. 1629 o PPR-ID: This is the Preferred Path forwarding identifier that 1630 would be on the data packet. The value of this field is variable 1631 and it depends on the PPR-ID Type - for Type 1, this is and MPLS 1632 SID/Label. For Type 2 this is a 4 byte IPv4 address. For Type 3 1633 this is a 16 byte IPv6 address. For Type 2 and Type 3 encoding is 1634 similar to "IS-IS Prefix" as specified in Section 3.1. For Type 1635 4, it is a 16 byte IPv6 SID. 1637 For PPR-ID Type 2, 3 or 4, if the PPR-ID Len is set to non-zero 1638 value, then the PPR-ID MUST NOT be advertised as a routable prefix in 1639 TLV 135, TLV 235, TLV 236 and TLV 237. Also PPR-ID MUST belong to 1640 the node where Prefix is advertised from. PPR-ID Len = 0 case is a 1641 special case and is discussed in Section 4.1. 1643 3.3. PPR-PDE Sub-TLV 1645 This Sub-TLV represents the PPR Path Description Element (PDE). PPR- 1646 PDEs are used to describe the path in the form of set of contiguous 1647 and ordered Sub-TLVs, where first Sub-TLV represents (the top of the 1648 stack in MPLS data plane or) first node/segment of the path. These 1649 set of ordered Sub-TLVs can have both topological elements and non- 1650 topological elements (e.g., service segments). 1652 0 1 2 3 1653 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 1654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1655 | Type | Length | PPR-PDE Type | Reserved | 1656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1657 | PDE-ID Type | PDE-ID Len | PPR-PDE Flags | 1658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1659 // PDE-ID Value (continued, variable size) // 1660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1661 | PPR-PDE Sub-TLVs (variable) | 1662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1664 Figure 5: PPR-PDE Sub-TLV Format 1666 o Type: TBD (See IANA for suggested value) from IS-IS PPR TLV 1667 Section 3 Sub-TLV registry. 1669 o Length: Total length of the value field in bytes. 1671 o PPR-PDE Type: A new registry (TBD IANA) for this Sub-TLV and the 1672 defined types are as follows: 1674 a. Type: 1 Topological 1676 b. Type: 2 Non-Topological 1678 o PDE-ID Type: 1 Octet PDE-forwarding IDentifier Type. A new 1679 registry (TBD IANA) for this Sub-TLV and the defined types and 1680 corresponding PDE-ID Len, PDE-ID Value are as follows: 1682 a. Type 1: SID/Label type as defined in 1683 [I-D.ietf-isis-segment-routing-extensions]. PDE-ID Len and PDE- 1684 ID Value fields are per Section 2.3 of the referenced document. 1686 b. Type 2: SR-MPLS Prefix SID. PDE-ID Len and PDE-ID Value are same 1687 as Type 1. 1689 c. Type 3: SR-MPLS Adjacency SID. PDE-ID Len and PDE-ID Value are 1690 same as Type 1. 1692 d. Type 4: IPv4 Address. PDE-ID Len is 4 bytes and PDE-ID Value is 1693 4 bytes IPv4 address encoded similar to IPv4 Prefix described in 1694 Section 3.1. 1696 e. Type 5: IPv6 Address. PDE-ID Len is 16 bytes and PDE-ID Value is 1697 16 bytes IPv6 address encoded similar to IPv6 Prefix described in 1698 Section 3.1. 1700 f. Type 6: SRv6 Node SID as defined in 1701 [I-D.bashandy-isis-srv6-extensions]. PDE-ID Len and PDE-ID Value 1702 are as defined in SRv6 SID from the refrenced draft. 1704 g. Type 7: SRv6 Adjacency-SID. PDE-ID Len and PDE-ID Values are 1705 similar to SRv6 Node SID above. 1707 o PPR-PDE Flags: 2 Octet bit-field of flags; described below: 1709 PPR-PDE Flags Format 1711 0 1 2 3 4 5 6 7 .. 15 1712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1713 |L|D|Reserved | 1714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1716 1. L: Loose Bit. Indicates the type of next "Topological PDE-ID" in 1717 the path description and overrides the L bit in Section 3.2. If 1718 set, the next PDE is Loose. If this flag is unset, the next 1719 Topological PDE is Strict Type. 1721 2. D: Destination bit. By default this bit MUST be unset. This bit 1722 MUST be set only for PPR-PDE Type is 1 i.e., Topological and this 1723 PDE represents the node PPR-Prefix Section 3.1 belongs to, if 1724 there is no sub-sub-TLV to override PPR-Prefix and PPR-ID values. 1726 3. Reserved: 1 Octet reserved bits for future use. Reserved bits 1727 MUST be reset on transmission and ignored on receive. 1729 o PPR-PDE Sub-TLVs: TBD. These have 1 octet type, 1 octet length 1730 and value field is defined per the type field. 1732 3.4. PPR-Attributes Sub-TLV 1734 PPR-Attribute Sub-TLVs describe the attributes of the path. The 1735 following sub-TLVs draw from a new registry for sub-TLV numbers; this 1736 registry is to be created by IANA, and administered using the first 1737 come first serve process: 1739 o Type 1 (Suggested Value - IANA TBD): Packet Traffic accounting 1740 Sub-TLV. Length 0 and no value field. Specifies to create a 1741 counter to count number of packets forwarded on this PPR-ID on 1742 each node in the path description. 1744 o Type 2 (Suggested Value - IANA TBD): Traffic statistics in Bytes 1745 Sub-TLV. Length 0 and no value field. Specifies to create a 1746 counter to count number of bytes forwarded on this PPR-ID 1747 specified in the network header (e.g. IPv4, IPv6) on each node in 1748 the path description. 1750 o Type 3 (Suggested Value - IANA TBD): PPR-Prefix originating node's 1751 IPv4 Router ID Sub-TLV. Length and Value field are as specified 1752 in [RFC7794]. 1754 o Type 4 (Suggested Value - IANA TBD): PPR-Prefix originating node's 1755 IPv6 Router ID Sub-TLV. Length and Value field are as specified 1756 in [RFC7794]. 1758 o Type 5 (Suggested Value - IANA TBD): PPR-Metric Sub-TLV. Length 4 1759 bytes, and Value is metric of this path represented through the 1760 PPR-ID. Different nodes can advertise the same PPR-ID for the 1761 same Prefix with a different set of PPR-PDE Sub-TLVs and the 1762 receiving node MUST consider the lowest metric value (TBD more, on 1763 what happens when metric is same for two different set of PPR-PDE 1764 Sub-TLVs). 1766 4. PPR Processing Procedure Example 1768 As specified in Section 2, a PPR can be a TE path, locally 1769 provisioned by the operator or by a controller. Consider the 1770 following IS-IS network to describe the operation of PPR TLV as 1771 defined in Section 3: 1773 1 1774 _______ 1775 / 1 \ 1776 +---R2-------R3---+ 1777 / \_______/ \ 1778 / 1 \ 1779 1 / \ 1 1780 / 1__R13__1 \ 1781 / / \ \ 1782 R1------R6 R7-----------R4 1783 \ 2 \__R14__/ 2 /\ 1784 \ 2 2 / \ 1785 3 \ / 3 \1 1786 \ 4 / \ 1787 +----R8------R9-----R10------R12 1788 \ 1 / 1789 1 \ / 1 1790 +----R11---+ 1792 Figure 6: IS-IS Network 1794 In the (Figure 6) shown, consider node R1 as an ingress node, or a 1795 head-end node, and the node R4 MAY be an egress node or another head- 1796 end node. The numbers shown on links between nodes R1-R14 indicate 1797 the bi-directional IS-IS metric as provisioned. R1 may be configured 1798 to receive TE source routed path information from a central entity 1799 (PCE [RFC5440], Netconf [RFC6241] or a Controller) that comprises of 1800 PPR information which relates to sources that are attached to R1. It 1801 is also possible to have a PPR provisioned locally by the operator 1802 for non-TE needs (FRR or for chaining certain services). 1804 The PPR TLV (as specified in Section 3) is encoded as an ordered list 1805 of PPR-PDEs from source to a destination node in the network and is 1806 represented with a PPR-ID Section 3.2. The PPR TLV includes PPR-PDE 1807 Sub-TLVS Section 3.3, which represent both topological and non- 1808 topological elements and specifies the actual path towards a PPR- 1809 Prefix at R4. 1811 o The shortest path towards R4 from R1 are through the following 1812 sequence of nodes: R1-R2-R3-R4 based on the provisioned metrics. 1814 o The central entity can define a few PPRs from R1 to R4 that 1815 deviate from the shortest path based on other network 1816 characteristic requirements as requested by an application or 1817 service. For example, the network characteristics or performance 1818 requirements may include bandwidth, jitter, latency, throughput, 1819 error rate, etc. 1821 o A first PPR may be identified by PPR-ID = 1 (value) and may 1822 include the path of R1-R6-R7-R4 for a Prefix advertised by R4. 1823 This is an example for a Loose-PPR and 'L' bit MUST be set on 1824 Section 3.2. 1826 o A second PPR may be identified by PPR-ID = 2 (value) and may 1827 include the path of R1-R8-R9-R10-R4. This is an example for a 1828 Strict-PPR and 'L' bit MUST be unset on Section 3.2. Though this 1829 example shows PPR with all nodal SIDs, it is possible to have a 1830 PPR with combination of node and adjacency SIDs (local or global) 1831 or with PPR-PDE Type set to Non-Topological as defined in 1832 Section 3.3 elements along with these. 1834 4.1. PPR TLV Processing 1836 The first topological sub-object or PDE (Section 3.3) relative to the 1837 beginning of PPR Path contains the information about the first node 1838 (e.g. in SR-MPLS it's the topmost label). The last topological sub- 1839 object or PDE contains information about the last node (e.g. in SR- 1840 MPLS it's the bottommost label). 1842 Each receiving node, determine whether an advertised PPR includes 1843 information regarding the receiving node. Before processing any 1844 further, validation MUST be done to see if any PPR topological PDE is 1845 seen more than once (possible loop), if yes, this PPR TLV MUST be 1846 ignored. Processing of PPR TLVs can be done, during the end of the 1847 SPF computation (for MTID that is advertised in this TLV) and for the 1848 each prefix described through PPR TLV. For example, node R9 receives 1849 the PPR information, and ignores the PPR-ID=1 (Section 4) because 1850 this PPR TLV does not include node R9 in the path description/ordered 1851 PPR-PDE list. 1853 However, node R9 may determine that the second PPR identified by PPR- 1854 ID = 2 does include the node R9 in its PDE list. Therefore, node R9 1855 updates the local forwarding database to include an entry for the 1856 destination address of R4 indicates, that when a data packet 1857 comprising a PPR-ID of 2 is received, forward the data packet to node 1858 R10 instead of R11. This is even though from R9 the shortest path to 1859 reach R4 via R11 (Cost 3: R9-R11-R12-R4) it chooses the nexthop to 1860 R10 to reach R4 as specified in the PPR path description. Same 1861 process happens to all nodes or all topological PDEs as described in 1862 the PPR TLV. 1864 In summary, the receiving node checks first, if this node is on the 1865 path by checking the node's topological elements (with PPR-PDE Type 1866 set to Topological) in the path list. If yes, it adds/adjusts the 1867 shortest path nexthop computed towards PPR Prefix to the shortest 1868 path nexthop towards the next topological PDE in the PPR's Path. 1870 For PPR-ID (Section 3.2) Type 2, 3 or 4, if the PPR-ID Len is set to 1871 0, then Prefix would also become the PPR-ID (a special case). This 1872 can be used for some situations, where certain optimizations are 1873 required in the network. For this, path described in the PPR TLV 1874 SHOULD be completely dis-joint from the shortest path route to the 1875 prefix. If the disjoint-ness property is not maintained then the 1876 traffic MAY not be using the PPR path, as and when it encounters any 1877 node which is not in the path description. 1879 5. PPR Data Plane aspects 1881 Data plane for PPR-ID is selected by the entity (e.g., a controller, 1882 locally provisioned by operator), which selects a particular PPR in 1883 the network. Section 3.2 defines various data plane identifier types 1884 and a corresponding data plane identifier is selected by the entity 1885 which selects the PPR. Other data planes other than described below 1886 can also use this TLV to describe the PPR. Further details TBD. 1888 5.1. SR-MPLS with PPR 1890 If PPR-ID Type is 1, then the PPR belongs to SR-MPLS data plane and 1891 the complete PPR stack is represented with a unique SR SID/Label and 1892 this gets programmed on the data plane of each node, with the 1893 appropriate nexthop computed as specified in Section 4. PPR-ID here 1894 is a label/index from the SRGB (like another node SID or global-ADJ 1895 SID). PPR path description here is a set of ordered SIDs represented 1896 with PPR-PDE (Section 3.2) Sub-TLVs. Non-Topological segments also 1897 programmed in the forwarding to enable specific function/service, 1898 when the data packet hits with corresponding PPR-ID. 1900 Based on 'L' flag in PPR-ID Flags (Section 3.2), for SR-MPLS data 1901 plane either 1 label or 2 labels need to be provisioned on individual 1902 nodes on the path description. For the example network in Section 4, 1903 for PPR-ID=1, which is a loose path, node R6 programs the bottom 1904 label as PPR-ID and the top label as the next topological PPR-PDE in 1905 the path, which is a node SID of R7. The NH computed at R6 would be 1906 the shortest path towards R7 i.e., the interface towards R13. If 'L' 1907 flag is unset only PPR-ID is programmed on the data plane with NH set 1908 to the shortest path towards next topological PPR-PDE. 1910 5.2. SRv6 with PPR 1912 If PPR-ID Type is 4, the PPR belongs to SRv6 with SRH data plane and 1913 the complete PPR stack is represented with IPv6 SIDs and this gets 1914 programmed on the data plane with the appropriate nexthop computed as 1915 specified in Section 4. PPR-ID here is a SRv6 SID. PPR path 1916 description here is a set of ordered SID TLVs similar to as specified 1917 in Section 5.1. One way PPR-ID would be used in this case is by 1918 setting the same as the destination IPv6 address and SL field in SRH 1919 would be set to 0; however SRH [I-D.ietf-6man-segment-routing-header] 1920 can contain any other TLVs and non-topological SIDs as needed. 1922 5.3. PPR Native IP Data Planes 1924 If PPR-ID Type is 2 then source routing and packet steering can be 1925 done in IPv4 data plane (PPR-IPv4), along the path as described in 1926 PPR Path description. This is achieved by setting the destination IP 1927 address as PPR-ID, which is an IPv4 address in the data packet 1928 (tunneled/encapsulated). There is no data plane change or upgrade 1929 needed to support this. However this is applicable to only Strict- 1930 PPR paths ('L' bit as specified in Section 3.2 MUST be unset). 1932 Similarly for PPR-ID Type is 3, then source routing and packet 1933 steering can be done in IPv6 data plane (PPR-IPv6), along the path as 1934 described in PPR Path description. Whatever specified above for IPv4 1935 applies here too, except that destination IP address of the data 1936 packet is IPv6 Address (PPR-ID). This doesn't require any IPv6 1937 extension headers (EH), if there is no metadata/TLVs need to be 1938 carried in the data packet. 1940 6. PPR Scaling Considerations 1942 In a network of N nodes O(N^2) total (unidirectional) paths are 1943 necessary to establish any-to-any connectivity, and multiple (k) such 1944 path sets may be desirable if multiple path policies are to be 1945 supported (lowest latency, highest throughput etc.). 1947 In many solutions and topologies, N may be small enough and/or only a 1948 small set of paths need to be preferred paths, for example for high 1949 value traffic (DetNet, some of the defined 5G slices), and then the 1950 technology specified in this document can support these deployments. 1952 However, to address the scale needed when a larger number of PPR 1953 paths are required, the PPR TREE structure can be used [I-D.draft-ce- 1954 ppr-graph-00]. Each PPR Tree uses one label/SID and defines paths 1955 from any set of nodes to one destination, thus reduces the number of 1956 entries needed in SRGB at each node (for SR-MPLS data plane 1957 Section 5.1). These paths form a tree rooted in the destination. In 1958 other word, PPR Tree identifiers are destination identifiers and PPR 1959 Treed are path engineered destination routes (like IP routes) and it 1960 scaling simplifies to linear in N i.e., O(k*N). 1962 7. PPR Traffic Accounting 1964 Section 3.4 defines few PPR-Attributes to indicate creation of 1965 traffic accounting statistics in each node of the PPR path 1966 description. Presence of "Packet Traffic Accounting" and "Traffic 1967 Statistics" Sub-TLVs instruct to provision the hardware, to account 1968 for the respective traffic statistics. Traffic accounting should 1969 happen, when the actual data traffic hits for the PPR-ID in the 1970 forwarding plane. This allows more granular and dynamic enablement 1971 of traffic statistics for only certain PPRs as needed. 1973 This approach, thus is more safe and secure than any mechanism that 1974 involves creation of the state in the nodes with the data traffic 1975 itself. This is because, creation and deletion of the traffic 1976 accounting state for PPRs happen through IS-IS LSP processing and IS- 1977 IS protocol control plane security Section 10 options are applicable 1978 to this TLV. 1980 How the traffic accounting is distributed to a central entity is out 1981 of scope of this document. One can use any method (e.g. gRPC) to 1982 extract the PPR-ID traffic stats from various nodes along the path. 1984 8. Acknowledgements 1986 Thanks to Alex Clemm, Lin Han, Toerless Eckert and Kiran Makhijani 1987 for initial discussions on this topic. Thanks to Kevin Smith and 1988 Stephen Johnson for various deployment scenarios applicability from 1989 ETSI WGs perspective. Authors also acknowledge Alexander Vainshtein 1990 for detailed discussions and suggestions on this topic. 1992 Earlier versions of draft-ietf-isis-segment-routing-extensions have a 1993 mechanism to advertise EROs through Binding SID. 1995 9. IANA Considerations 1997 This document requests the following new TLV in IANA IS-IS TLV code- 1998 point registry. 2000 TLV # Name 2001 ----- -------------- 2002 TBD PPR TLV 2004 This document requests IANA to create a new Sub-TLV registry for PPR 2005 TLV Section 3 with the following initial entries (suggested values): 2007 Sub-TLV # Sub-TLV Name 2008 --------- --------------------------------------------------------- 2009 1 PPR-Prefix (Section 3.1) 2011 2 PPR-ID (Section 3.2) 2013 3 PPR-PDE (Section 3.3) 2015 This document also requests IANA to create a new Sub-TLV registry for 2016 PPR Path attributes with the following initial entries (suggested 2017 values): 2019 Sub-TLV # Sub-TLV Name 2020 --------- --------------------------------------------------------- 2022 1 Packet Traffic Accounting (Section 3.4) 2024 2 Traffic Statistics (Section 3.4) 2026 3 PPR-Prefix Source IPv4 Router ID (Section 3.4) 2028 4 PPR-Prefix Source IPv6 Router ID (Section 3.4) 2030 5 PPR-Metric (Section 3.4) 2032 This document requests additional IANA registries in an IANA managed 2033 registry "Interior Gateway Protocol (IGP) Parameters" for various PPR 2034 TLV parameters. The registration procedure is based on the "Expert 2035 Review" as defined in [RFC8126]. The suggested registry names are: 2037 o "PPR-Type" - Types are an unsigned 8 bit numbers. Values are as 2038 defined in Section 3 of this document. 2040 o "PPR-Flags" - 1 Octet. Bits as described in Section 3 of this 2041 document. 2043 o "PPR-ID Type" - Types are an unsigned 8 bit numbers. Values are 2044 as defined in Section 3.2 of this document. 2046 o "PPR-ID Flags" - 1 Octet. Bits as described in Section 3.2 of 2047 this document. 2049 o "PPR-PDE Type" - Types are an unsigned 8 bit numbers. Values are 2050 as defined in Section 3.3 of this document. 2052 o "PPR-PDE Flags" - 1 Octet. Bits as described in Section 3.3 of 2053 this document. 2055 o "PDE-ID Type" - Types are an unsigned 8 bit numbers. Values are 2056 as defined in Section 3.3 of this document. 2058 10. Security Considerations 2060 Security concerns for IS-IS are addressed in [RFC5304] and [RFC5310]. 2061 Further security analysis for IS-IS protocol is done in [RFC7645] 2062 with detailed analysis of various security threats and why [RFC5304] 2063 should not be used in the deployments. Advertisement of the 2064 additional information defined in this document introduces no new 2065 security concerns in IS-IS protocol. However as this extension is 2066 related to SR-MPLS and SRH data planes as defined in 2067 [I-D.ietf-spring-segment-routing], those particular data plane 2068 security considerations does apply here. 2070 11. References 2072 11.1. Normative References 2074 [I-D.ietf-isis-segment-routing-msd] 2075 Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 2076 "Signaling MSD (Maximum SID Depth) using IS-IS", draft- 2077 ietf-isis-segment-routing-msd-12 (work in progress), May 2078 2018. 2080 [I-D.ietf-spring-segment-routing] 2081 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 2082 Litkowski, S., and R. Shakir, "Segment Routing 2083 Architecture", draft-ietf-spring-segment-routing-15 (work 2084 in progress), January 2018. 2086 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2087 Requirement Levels", BCP 14, RFC 2119, 2088 DOI 10.17487/RFC2119, March 1997, 2089 . 2091 11.2. Informative References 2093 [I-D.bashandy-isis-srv6-extensions] 2094 Ginsberg, L., Psenak, P., Filsfils, C., Bashandy, A., 2095 Decraene, B., and Z. Hu, "IS-IS Extensions to Support 2096 Routing over IPv6 Dataplane", draft-bashandy-isis- 2097 srv6-extensions-03 (work in progress), June 2018. 2099 [I-D.cheng-spring-mpls-path-segment] 2100 Cheng, W., Wang, L., Li, H., Chen, M., Zigler, R., and S. 2101 Zhan, "Path Segment in MPLS Based Sement Routing Network", 2102 draft-cheng-spring-mpls-path-segment-01 (work in 2103 progress), March 2018. 2105 [I-D.hegde-spring-traffic-accounting-for-sr-paths] 2106 Hegde, S., "Traffic Accounting for MPLS Segment Routing 2107 Paths", draft-hegde-spring-traffic-accounting-for-sr- 2108 paths-01 (work in progress), October 2017. 2110 [I-D.ietf-6man-segment-routing-header] 2111 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 2112 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 2113 (SRH)", draft-ietf-6man-segment-routing-header-14 (work in 2114 progress), June 2018. 2116 [I-D.ietf-isis-mpls-elc] 2117 Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S. 2118 Litkowski, "Signaling Entropy Label Capability and 2119 Readable Label-stack Depth Using IS-IS", draft-ietf-isis- 2120 mpls-elc-03 (work in progress), January 2018. 2122 [I-D.ietf-isis-segment-routing-extensions] 2123 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 2124 Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura, 2125 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 2126 segment-routing-extensions-18 (work in progress), June 2127 2018. 2129 [I-D.ietf-mpls-sfc] 2130 Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based 2131 Forwarding Plane for Service Function Chaining", draft- 2132 ietf-mpls-sfc-01 (work in progress), May 2018. 2134 [I-D.xuclad-spring-sr-service-chaining] 2135 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 2136 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 2137 Henderickx, W., and S. Salsano, "Segment Routing for 2138 Service Chaining", draft-xuclad-spring-sr-service- 2139 chaining-01 (work in progress), March 2018. 2141 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 2142 Topology (MT) Routing in Intermediate System to 2143 Intermediate Systems (IS-ISs)", RFC 5120, 2144 DOI 10.17487/RFC5120, February 2008, 2145 . 2147 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 2148 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2149 2008, . 2151 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 2152 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2153 2008, . 2155 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 2156 DOI 10.17487/RFC5308, October 2008, 2157 . 2159 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 2160 and M. Fanto, "IS-IS Generic Cryptographic 2161 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2162 2009, . 2164 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 2165 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 2166 DOI 10.17487/RFC5440, March 2009, 2167 . 2169 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2170 and A. Bierman, Ed., "Network Configuration Protocol 2171 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2172 . 2174 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 2175 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 2176 RFC 6790, DOI 10.17487/RFC6790, November 2012, 2177 . 2179 [RFC7645] Chunduri, U., Tian, A., and W. Lu, "The Keying and 2180 Authentication for Routing Protocol (KARP) IS-IS Security 2181 Analysis", RFC 7645, DOI 10.17487/RFC7645, September 2015, 2182 . 2184 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 2185 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 2186 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 2187 March 2016, . 2189 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2190 Writing an IANA Considerations Section in RFCs", BCP 26, 2191 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2192 . 2194 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2195 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2196 May 2017, . 2198 Authors' Addresses 2200 Uma Chunduri 2201 Huawei USA 2202 2330 Central Expressway 2203 Santa Clara, CA 95050 2204 USA 2206 Email: uma.chunduri@huawei.com 2208 Richard Li 2209 Huawei USA 2210 2330 Central Expressway 2211 Santa Clara, CA 95050 2212 USA 2214 Email: renwei.li@huawei.com 2216 Russ White 2217 LinkedIn 2218 Oak Island, NC 28465 2219 USA 2221 Email: russ@riw.us 2223 Jeff Tantsura 2224 Nuage Networks 2225 755 Ravendale Drive 2226 Mountain View, CA 94043 2227 USA 2229 Email: jefftant.ietf@gmail.com 2231 Luis M. Contreras 2232 Telefonica 2233 Sur-3 building, 3rd floor 2234 Madrid 28050 2235 Spain 2237 Email: luismiguel.contrerasmurillo@telefonica.com 2238 Yingzhen Qu 2239 Huawei USA 2240 2330 Central Expressway 2241 Santa Clara, CA 95050 2242 USA 2244 Email: yingzhen.qu@huawei.com