idnits 2.17.1 draft-ct-isis-nspfid-for-sr-paths-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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 5. NSPF-ID: This is the NSP forwarding identifier that would be on the data packet. The value of this field is variable and it depends on the NSPF-ID Type. For Type 1, this is and MPLS SID/ Label. For Type 2 this is a 4 byte IPv4 address. For Type 3 and Type 4, it is a 16 byte IPv6 address. For NSPF-ID Type 2, 3 or 4, if the NSPF-ID Len is set to 0, then FEC Prefix would also become the NSPF-ID. In the case when NSPF-ID Len is 0 and NSPF-ID Type is 2, then FEC Prefix length MUST be a 4 byte IPv4 address. Similarly, if NSPF-ID Type is 3 or 4 with NSPF-ID Len is set to 0, then FEC Prefix MUST be of a 16 byte IPv6 Address. For NSPF-ID Type 2, 3 or 4, if the NSPF-ID Len is set to non zero value, then the NSPF-ID MUST not be advertised as a routable prefix in TLV 135, TLV 235, TLV 236 and TLV 237, but that MUST belog to the node where "FEC Prefix" is advertised. -- The document date (March 23, 2018) is 2225 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) == Unused Reference: 'RFC7413' is defined on line 662, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-bashandy-isis-srv6-extensions-02 == 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-10 == Outdated reference: A later version (-24) exists of draft-ietf-dmm-srv6-mobile-uplane-01 == 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-15 == Outdated reference: A later version (-19) exists of draft-ietf-isis-segment-routing-msd-09 Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LSR Working Group U. Chunduri, Ed. 3 Internet-Draft Huawei USA 4 Intended status: Standards Track J. Tantsura 5 Expires: September 24, 2018 Nuage Networks 6 Y. Qu 7 Huawei USA 8 March 23, 2018 10 Usage of Non Shortest Path Forwarding (NSPF) IDs in IS-IS 11 draft-ct-isis-nspfid-for-sr-paths-01 13 Abstract 15 This document specifies the advertisement of Non Shortest Path 16 Forwarding IDentifier (NSPF ID) TLV and the computation procedures 17 for the same in IS-IS protocol. NSPF ID allows to simplify the data 18 plane path description of data traffic in SR deployments. This helps 19 mitigate the MTU issues that are caused by additional SR overhead of 20 the packet and allows traffic statistics. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC2119 [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 24, 2018. 45 Copyright Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Mitigation with MSD and RLD . . . . . . . . . . . . . . . 3 64 1.2. Issues with Increased SID Depth . . . . . . . . . . . . . 3 65 1.3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 5 66 2. Non Shortest Path Forwarding IDentifier TLV . . . . . . . . . 6 67 2.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 2.2. NSPF-ID Fields . . . . . . . . . . . . . . . . . . . . . 8 69 2.3. NSP sub-TLVs . . . . . . . . . . . . . . . . . . . . . . 9 70 2.4. Non-NSP sub-TLVs . . . . . . . . . . . . . . . . . . . . 9 71 3. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 10 72 4. NSPF ID Data Plane aspects . . . . . . . . . . . . . . . . . 12 73 4.1. MPLS Data Plane . . . . . . . . . . . . . . . . . . . . . 12 74 4.2. SRv6 Data Plane . . . . . . . . . . . . . . . . . . . . . 12 75 5. NSP Traffic Accounting . . . . . . . . . . . . . . . . . . . 12 76 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 81 9.2. Informative References . . . . . . . . . . . . . . . . . 13 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 84 1. Introduction 86 In a network implementing source routing, packets may be transported 87 through the use of segment identifiers (SIDs), where a SID uniquely 88 identifies a segment as defined in [I-D.ietf-spring-segment-routing]. 89 In SR-MPLS, a segment is encoded as a label and an ordered list of 90 segments is encoded as a stack of labels. In SRv6, a segment is 91 encoded as an IPv6 address, with a new type of IPv6 routing header 92 called SRH. An ordered list of segments is encoded as an ordered 93 list of IPv6 addresses in SRH [I-D.ietf-6man-segment-routing-header]. 95 The segment may include one or more nodes, unidirectional adjacencies 96 between two nodes or service instruction by a particular node in the 97 network. A Non Shortest Path (NSP) could be a Traffic Engineered 98 (TE) path or an explicitly provisioned FRR path or a service chained 99 path. NSP can be described using list of segments in SR. However, 100 this creates a problem of having a relatively large stack imposed on 101 the data packet. A path that is encoded with SIDs can be a loose or 102 strict path. In a strict path all the nodes/links on the path are 103 encoded as SIDs, with the expense of number of total SIDs in the 104 stack. 106 1.1. Mitigation with MSD and RLD 108 The number of SIDs in the stack a node can impose is referred as 109 Maximum SID Depth (MSD) capability 110 [I-D.ietf-isis-segment-routing-msd], which must be taken into 111 consideration when computing a path to transport a data packet in a 112 network implementing segment routing. [I-D.ietf-isis-mpls-elc] 113 defines Readable Label Depth (RLD) that is used by a head-end to 114 insert Entropy Label pair (ELI/EL) at appropriate depth, so it could 115 be read by transit nodes. There are situations where the source 116 routed path can be excessive as path represented by SR SIDs need to 117 describe all the nodes and ELI/EL based on the readability of the 118 nodes in that path. 120 While MSD (and RLD) capabilities advertisement help mitigate the 121 problem for a central entity to create the right source routed path 122 per application/operator requirements; actual depth is still limited 123 by the underlying hardware in the data path. 125 1.2. Issues with Increased SID Depth 127 Consider the following network where SR-MPLS data plane is in use and 128 with same SRGB (5000-6000) on all nodes i.e., A1 to A7 and B1 to B7 129 for illustration: 131 SID:10 SID:20 SID:30 SID:40 SID:50 SID:300(Ax) SID:60 SID:70 132 A1-------A2-------A3-------A4-------A5===============A6----------A7 133 \ / \5 5/ \ SID:310(Ay) \ / 134 \ 10 10/ +-A10-+ \ \10 /10 135 \ / SID:100 \ \ / 136 SID:80 \A8-----A9/SID:90 \ 40 \ / 137 / \ +---+ \ / 138 /10 B2x:125 \10 \ \/ 139 B1--------B2============B3----B4--------B5-------B6----------B7 140 SID:110 SID:120 SID:130 SID:140 SID:150 SID:160 SID:170 142 Figure 1: SR-MPLS Network 144 Global ADJ SIDs are provisioned between A5 and A6 .All other SIDs 145 shown are nodal SID indices. 147 All metrics of the links are set to 1, other values as configured. 149 Shortest Path from A1 to A7: A2-A3-A4-A5-A6-A7 151 NSP1: From A1 to A7 - A2-A8-B2-B2x-A9-A10-Ax-A7; Pushed Label 152 Stack @A1: 5020:5080:5120:5125:5090:5100:5300:5070 (where B2x is a 153 local ADJ-SID and Ax is a global ADJ-SID) 155 In the above example NSP1 is represented with a combination of 156 Adjacency and Node SIDs with a stack of 8 labels each. However, this 157 value can be larger, if the use of entropy label is desired and based 158 on the RLD capabilities of each node and additional labels required 159 to insert ELI/EL at appropriate places. Though above network is 160 shown with SR-MPLS data plane, problem is similar if the network were 161 a SR-IPv6 network with all SIDs encoded as IPv6 SIDs in SRH. 163 In various SR deployments, the following issues may arise: 165 a. Not all nodes in the path can support MSD or RLD needed to 166 satisfy user/operator requirements, when the number of SIDs 167 increased to describe the source routed path. This problem gets 168 multiplied by four times in SRH compared to MPLS data plane 169 because of the SID size (16 bytes) in SRH. 171 b. Even if all nodes can support the required MSD or RLD, the bigger 172 label stack/depth can cause potential MTU/fragmentation issues. 174 c. In some deployments, it is also required reducing the overhead in 175 the network layer, especially for low packet size packets, where 176 the actual data can be way lesser than all encapsulations and SR 177 path overheads. 179 Apart from the above some deployments need path accounting statistics 180 for path monitoring and traffic re-optimizations. 181 [I-D.hegde-spring-traffic-accounting-for-sr-paths] proposes a 182 solution, however this further increases the depth of SID stack. The 183 approach could be counter productive in the environments, where SID 184 depth is already causing deployment issues as listed above. 186 To mitigate the above issues, and also to facilitate forwarding plane 187 a mechanism to identify the SR path with a corresponding data plane 188 identifier for accounting of traffic for SR paths, this draft 189 proposes a new IS-IS TLV (Section 2) to advertise the NSPs with Non 190 Shortest Path Forwarding IDentifier (NSPF ID). 192 This draft lays out procedure for IS-IS nodes to how to use NSPF ID 193 TLV in Section 3. With corresponding data plane, Section 3 194 mechanism, reduces the SID stack in the data plane from 8 SIDs shown 195 in SR-PATH-1 and SR-PATH-2 with a single NSPF ID. This draft also 196 introduce source routed paths with NSPF ID types defined for native 197 IPv4 and IPv6 data planes as defined in Section 2.2. 199 1.3. Acronyms 201 EL - Entropy Label 203 ELI - Entropy Label Indicator 205 MPLS - Multi Protocol Label Switching 207 MSD - Maximum SID Depth 209 MTU - Maximum Transferrable Unit 211 NSP - Non Shortest Path 213 SID - Segment Identifier 215 SPF - Shortest Path First 217 SR - Segment Routing 219 SRH - Segment Routing Header 221 SR-MPLS - Segment Routing with MPLS data plane 223 SRv6 - Segment Routing with Ipv6 data plane with SRH 225 SRH - IPv6 Segment Routing Header 226 TE - Traffic Engineering 228 2. Non Shortest Path Forwarding IDentifier TLV 230 This section describes the encoding of NSPF ID TLV. This TLV can be 231 seen as having 3 logical section viz., encoding od FEC Prefix, 232 encoding of NSPF-ID with description of ordered path with sub-TLVs 233 and a set of optional non-NSP sub-TLVs which can be used to describe 234 one or more parameters of the path. Multiple instances of this TLV 235 MAY be advertised in IS-IS LSPs with different NSPF-ID Type and with 236 corresponding path description sub-TLVS. The NSPF-ID TLV has Type 237 TBD (suggested value xxx), and has the following format: 239 0 1 2 3 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Type | Length | Reserved | Flags | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | MT-ID | Prefix Len | FEC Prefix | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 // FEC Prefix (continued, variable) // 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | NSPF-ID Type | NSPF-ID Len | NSPF-ID Flags | NSPF-ID Algo | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 // NSPF-ID (continued, variable) // 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 |No.of NSP-STs | NSP sub-TLVs (Variable) // 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 |No.of Other-STs| Non-NSP sub-TLVs(variable) // 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 Figure 2: NSPF ID TLV Format 259 Type - TBD from IS-IS top level TLV registry. 261 Length - Total length of the value field in bytes (variable). 263 Reserved - 1 Octet reserved bits for future use. Reserved bits 264 MUST be reset on transmission and ignored on receive. 266 Flags - Flags for this TLV are described in Section 2.1. 268 MT-ID - is the multi-topology identifier defined in [RFC5120] with 269 4 most significant bits reset on transmission and ignored on 270 receive. The remaining 12-bit field contains the MT-ID. 272 Prefix Len - contains the length of the prefix in bits. Only the 273 most significant octets of the Prefix are encoded. 275 FEC Prefix - represents the Forwarding Equivalence Class at the 276 tail-end of the advertised NSP. The "FEC Prefix" corresponds to a 277 routable prefix of the originating node and it MAY have one of the 278 [RFC7794] flags set (X-Flag/R-Flag/N-Flag). Value of this field 279 MUST be 4 octets for IPv4 "FEC Prefix". Value of this field MUST 280 be 16 octets for IPv6 "FEC Prefix". Encoding is similar to TLV 281 135 and TLV 236 or MT-Capable [RFC5120] IPv4 (TLV 235) and IPv6 282 Prefixes (TLV 237) respectively. 284 2.1. Flags 286 Flags: 1 octet field of NSPD ID TLV has following flags defined. 287 These flags mostly related to applicability of this TLV in an L1 area 288 or entire IS-IS domain: 290 NSPF ID Flags Format 292 0 1 2 3 4 5 6 7 293 +-+-+-+-+-+-+-+-+ 294 |S|D|A| Rsrvd | 295 +-+-+-+-+-+-+-+-+ 297 S - If set, the NSPF ID TLV MUST be flooded across the entire 298 routing domain. If the S flag is not set, the NSPF ID TLV MUST 299 NOT be leaked between IS-IS levels. This bit MUST NOT be altered 300 during the TLV leaking 302 D - when the NSPF ID TLV is leaked from IS-IS level-2 to level-1, 303 the D bit MUST be set. Otherwise, this bit MUST be clear. NSPF 304 ID TLVs with the D bit set MUST NOT be leaked from level-1 to 305 level-2. This is to prevent TLV looping across levels. 307 A - The originator of the NSPF ID TLV MUST set the A bit in order 308 to signal that the prefixes and NSPF-IDs advertised in the NSPF ID 309 TLV are directly connected to their originators. If this bit is 310 not set, this allows any other node in the network advertise this 311 TLV on behalf of the originating node of the "FEC Prefix". If the 312 NSPF ID TLV is leaked to other areas/levels the A-flag MUST be 313 cleared. 315 Rsrvd - reserved bits for future use. Reserved bits MUST be reset 316 on transmission and ignored on receive. 318 2.2. NSPF-ID Fields 320 This represents the actual data plane identifier in the packet and 321 could be of any data plane as defined in type field. Both "FEC 322 Prefix" and NSPF-ID MUST belong to a same node in the network. 324 1. NSPF-ID Type: This is a new registry (TBD IANA) for this TLV and 325 the defined types are as follows. Type: 1 - MPLS SID/Label Type: 326 2 Native IPv4 Address Type: 3 Native IPv6 Address Type 4: IPv6 327 SID in SRv6 with SRH 329 2. NSPF-ID Len: Length of the NSPF Identifier field in octets and 330 this depends on the NSPF-ID type. See NSPF-ID below for the 331 length of this field and other considerations. 333 3. NSPF-ID Flags: 1 Octet field for NSPF-ID flags. Some of the bits 334 could be NSPF-ID type specific and each new type MUST define the 335 flags applicable to the NSPF-ID type. For NSPF-ID Type 1, the 336 flags are same as Section 2.1 definition in 337 [I-D.ietf-isis-segment-routing-extensions]. For NSPF-ID Type 2, 338 3 and NSPF-ID Type 4 only 'R' flag is applicable. Undefined 339 flags for each NSPF-ID type MUST be considered as reserved. 340 Reserved flag bits in each NSPF-ID type specific flags MUST be 341 reset on transmission and ignored on receive. 343 4. NSPF-ID Algo: 1 octet value represents the SPF algorithm. 344 Algorithm registry is as defined in 345 [I-D.ietf-isis-segment-routing-extensions]. 347 5. NSPF-ID: This is the NSP forwarding identifier that would be on 348 the data packet. The value of this field is variable and it 349 depends on the NSPF-ID Type. For Type 1, this is and MPLS SID/ 350 Label. For Type 2 this is a 4 byte IPv4 address. For Type 3 and 351 Type 4, it is a 16 byte IPv6 address. For NSPF-ID Type 2, 3 or 352 4, if the NSPF-ID Len is set to 0, then FEC Prefix would also 353 become the NSPF-ID. In the case when NSPF-ID Len is 0 and NSPF- 354 ID Type is 2, then FEC Prefix length MUST be a 4 byte IPv4 355 address. Similarly, if NSPF-ID Type is 3 or 4 with NSPF-ID Len 356 is set to 0, then FEC Prefix MUST be of a 16 byte IPv6 Address. 357 For NSPF-ID Type 2, 3 or 4, if the NSPF-ID Len is set to non zero 358 value, then the NSPF-ID MUST not be advertised as a routable 359 prefix in TLV 135, TLV 235, TLV 236 and TLV 237, but that MUST 360 belog to the node where "FEC Prefix" is advertised. 362 6. No.of NSP-STs: Total number of the NSP sub-TLVs are defined with 363 this 1-octet field. The value MUST NOT be zero. 365 2.3. NSP sub-TLVs 367 A new sub-TLV registry is created (TBD IANA) called NSP sub-TLVs. 368 These are used to describe the path in the form of set of contiguous 369 and ordered sub-TLVs, with first sub-TLV representing the top of the 370 stack or first segment. These set of ordered TLVs can have both 371 topological SIDs and non-topological SIDs (e.g., service segments). 373 Type 1: SID/Label sub-TLV as defined in 374 [I-D.ietf-isis-segment-routing-extensions]. Only Type is defined 375 and Length/Value fields are per Section 2.3 of the referenced 376 document. 378 Type 2: Prefix SID sub-TLV as defined in 379 [I-D.ietf-isis-segment-routing-extensions]. Only Type is defined 380 and Length/Value fields are per Section 2.1 of the referenced 381 document. 383 Type 3: Adjacency SID sub-TLV as defined in 384 [I-D.ietf-isis-segment-routing-extensions]. Only Type is defined 385 and Length/Value fields are per Section 2.2 of the referenced 386 document. 388 Type 4: Length 4 bytes, value is 4 bytes IPv4 address encoded 389 similar to IPv4 FEC Prefix described above. 391 Type 5: Length 16 bytes; value is 16 bytes IPv6 address encoded 392 similar to IPv6 FEC Prefix described above. 394 Type 6: SRv6 Node SID TLV as defined in 395 [I-D.bashandy-isis-srv6-extensions]. Only Type is defined and 396 Length/Value fields are per Section 4 of the referenced document. 398 Type 7: SRv6 Adjacency-SID sub-TLV as defined in 399 [I-D.bashandy-isis-srv6-extensions]. Only Type is defined and 400 Length/Value fields are per Section 6.1 of the referenced 401 document. 403 Type 8: SRv6 LAN Adjacency-SID sub-TLV as defined in 404 [I-D.bashandy-isis-srv6-extensions]. Only Type is defined and 405 Length/Value fields are per Section 6.2 of the referenced 406 document. 408 2.4. Non-NSP sub-TLVs 410 NSPF ID TLV also defines a new sub-TLV registry (TBD IANA) for 411 defining extensible set of sub-TLVs other than describing the path 412 sub-TLVs. Total number of the path sub-TLVs to describe the path are 413 defined in 1-octet field "No.of Other-STs" just before the Non-NSP 414 sub-TLVs. This field serves as a demarcation for set of ordered NSP 415 sub-TLVs and Non-NSP sub-TLVs. 417 Type 1: Length 0 No value field. Specifies a counter to count 418 number of packets forwarded on this NSPF-ID. 420 Type 2: Length 0 No value field. Specifies a counter to count 421 number of bytes forwarded on this NSPF-ID specified in the network 422 header (e.g. IPv4, IPv6). 424 Type 3: Length 4 bytes, and Value is metric of this path 425 represented through the NSPF-ID. Different nodes can advertise 426 the same NSPF-ID for the same FEC-Prefix with a different set of 427 NSP sub-TLVs and the receiving node MUST consider the lowest 428 metric value (TBD more, what happens when metric is same for two 429 different set of NSP sub-TLVs). 431 3. Elements of Procedure 433 As specified in Section 1, a NSP can be a TE path, locally 434 provisioned by the operator. Consider the following IS-IS network to 435 describe the operation of NSPF ID TLV as defined in Section 2: 437 1 438 _______ 439 / 1 \ 440 +---R2-------R3---+ 441 / \_______/ \ 442 / 1 \ 443 1 / 2 \ 1 444 / ______ \ 445 / / \ \ 446 R1------R6 R7-----------R4 447 \ 2 \______/ 2 /\ 448 \ 2 / \ 449 3 \ / 3 \1 450 \ 4 / \ 451 +----R8------R9-----R10------R12 452 \ 1 / 453 1 \ / 1 454 +----R11---+ 456 Figure 3: IS-IS Network 458 In the above diagram (Figure 3) node R1 is an ingress node, or a 459 head-end node, and the node R4 may be an egress node or another head- 460 end node. The numbers shown on each of the links between nodes 461 R1-R11 indicate a IS-IS metric as provisioned by the operator. R1 462 may be configured to receive TE source routed path information from a 463 central entity (PCE or Controller) that comprise NSP information 464 which relates to sources that are attached to R1. It is also 465 possible to have an NSP provisioned locally by the operator for non- 466 TE needs (FRR or for chaining certain services). The NSP information 467 is encoded as an ordered list of segments from source to a 468 destination node in the network and is represented with an NSPF-ID. 469 The NSP information includes NSP sub-TLVS which represents both 470 topological and non-topological segments and specifies the actual 471 path towards a FEC/Prefix by R4. 473 The shortest path towards R4 from R1 are through the following 474 sequence of nodes: R1-R2-R3-R4 based on the configured metrics. The 475 central entity may define a few NSPs from R1 to R4 that deviate from 476 the shortest path based on other network characteristic requirements 477 as requested by an application or service. For example, the network 478 characteristics or performance requirements may include bandwidth, 479 jitter, latency, throughput, error rate, etc. A first NSP may be 480 identified by NSPF ID = 2 and may include the path of R1-R6-R7-R4 for 481 a FEC Prefix advertised by R4. A second NSP may be identified by 482 NSPF ID = 3 and may include the path of R1-R8-R9-R10-R4. Though 483 these example shows NSP with all nodal SIDs, it is possible to have 484 an NSP with combination of node and adjacency SIDS (local or global) 485 or with non-topological segments along with these. 487 Each receiving node, determine whether an advertised NSP includes 488 information regarding the receiving node. This MAY be done, during 489 the end of the SPF computation for MTID that is advertised in this 490 TLV and for the FEC/Prefix. For example, node R9 receives the NSP 491 information, and ignores the first NSP identified by NSPF ID = 2 492 because this NSP does not include node R9. 494 However, node R9 may determine that the second NSP identified by NSPF 495 ID = 3 does include the node R9 for the FEC prefix advertised by R4. 496 Therefore, node R9 updates the local forwarding database to include 497 an entry for the destination address of R4 that indicates, that when 498 a data packet comprising a NSPF-ID of 3 is received, forward the data 499 packet to node R10 instead of R11. This is even though from R9 the 500 shortest path cost to reach R4 via R11 is 3 (R9-R11-R12-R4) it 501 chooses the nexthop to R10 to reach R4 as specified in the NSP. Same 502 process happens to all the nodes on the NSP. 504 In summary, the receiving node checks if this node is on the path, if 505 yes, it adjusts the shortest path nexthop computed towards "FEC 506 Prefix" to the shortest path nexthop towards the next segment as 507 specified in the NSP. 509 4. NSPF ID Data Plane aspects 511 Data plane NSPF ID is selected by the entity (e.g., a controller, 512 locally provisioned) which selects a particular NSP in the network. 513 Section 2.2 defines various data plane identifier types and a 514 corresponding data plane identifier type and identifier is selected 515 by the entity which selects the NSP. Other data planes other than 516 described below can also use this TLV to describe the NSP. Further 517 details TBD. 519 4.1. MPLS Data Plane 521 If NSPF-ID Type is 1, the NSP belongs to SR-MPLS data plane and the 522 complete NSP stack is represented with a unique SR SID/Label and this 523 gets programmed on the data plane with the appropriate nexthop 524 computed as specified in Section 3 . NSP path description here is a 525 set of ordered SID TLVs and MAY contain both topological and non- 526 topological segments. 528 4.2. SRv6 Data Plane 530 If NSPF-ID Type is 4, the NSP belongs to SRv6 with SRH data plane and 531 the complete NSP stack is represented with IPv6 SIDs and this gets 532 programmed on the data plane with the appropriate nexthop computed as 533 specified in Section 3. NSP path description here is a set of 534 ordered SID TLVs and MAY contain both topological and non-topological 535 segments (e.g. network functions, service functions). If NSPF-ID 536 Type is 3 this is the traditional IPv6 mode 537 ([I-D.ietf-dmm-srv6-mobile-uplane]) and this doesn't include SRH and 538 NSP stack description is similar to NSPF-ID Type 4 as described. 540 5. NSP Traffic Accounting 542 As described in Section 2.4, each node described in the NSP optional 543 sub-TLVs can provision the hardware to account the traffic statistics 544 as indicated in the non-NSP sub-TLVs for the actual data traffic. 545 with this more granular and dynamic enablement of traffic statistics 546 for only certain NSPs would be possible. This approach, thus is more 547 safe and secure than any mechanism that involves creating state in 548 the nodes with data traffic itself. This is because creation and 549 deletion of the traffic accounting state for NSPs happen through IS- 550 IS LSP processing and IS-IS security Section 8 options are applicable 551 to this TLV. 553 How the traffic accounting is distributed to a central entity is out 554 of scope of this document. One can use any method (e.g. gRPC) to 555 extract the NSPF-ID traffic stats from various nodes along the path. 557 6. Acknowledgements 559 Thanks to Richard Li, Alex Clemm, Kiran Makhijani and Lin Han for 560 initial discussions on this topic. 562 Earlier versions of draft-ietf-isis-segment-routing-extensions have a 563 mechanism to advertise EROs through Binding SID. 565 7. IANA Considerations 567 This document requests the following new TLVin IANA IS-IS TLV code- 568 point registry. 570 TLV # Name 571 ----- -------------- 572 TBD NSPF ID TLV 574 This document also requests IANA to create new registries for NSPF-ID 575 Type, NSP sub-TLVs and Non-NSP sub-TLVs in NSPF ID TLV as described 576 in Section 2. 578 8. Security Considerations 580 Security concerns for IS-IS are addressed in [RFC5304] and [RFC5310]. 581 Further security analysis for IS-IS protocol is done in [RFC7645]. 582 Advertisement of the additional information defined in this document 583 introduces no new security concerns in IS-IS protocol. However as 584 this extension is related to SR-MPLS and SRH data planes as defined 585 in [I-D.ietf-spring-segment-routing], those particular data plane 586 security considerations does apply here. 588 9. References 590 9.1. Normative References 592 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 593 Requirement Levels", BCP 14, RFC 2119, 594 DOI 10.17487/RFC2119, March 1997, 595 . 597 9.2. Informative References 599 [I-D.bashandy-isis-srv6-extensions] 600 Ginsberg, L., Bashandy, A., Filsfils, C., Decraene, B., 601 and Z. Hu, "IS-IS Extensions to Support Routing over IPv6 602 Dataplane", draft-bashandy-isis-srv6-extensions-02 (work 603 in progress), March 2018. 605 [I-D.hegde-spring-traffic-accounting-for-sr-paths] 606 Hegde, S., "Traffic Accounting for MPLS Segment Routing 607 Paths", draft-hegde-spring-traffic-accounting-for-sr- 608 paths-01 (work in progress), October 2017. 610 [I-D.ietf-6man-segment-routing-header] 611 Previdi, S., Filsfils, C., Leddy, J., Matsushima, S., and 612 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 613 (SRH)", draft-ietf-6man-segment-routing-header-10 (work in 614 progress), March 2018. 616 [I-D.ietf-dmm-srv6-mobile-uplane] 617 Matsushima, S., Filsfils, C., Kohno, M., Camarillo, P., 618 daniel.voyer@bell.ca, d., and C. Perkins, "Segment Routing 619 IPv6 for Mobile User Plane", draft-ietf-dmm-srv6-mobile- 620 uplane-01 (work in progress), March 2018. 622 [I-D.ietf-isis-mpls-elc] 623 Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S. 624 Litkowski, "Signaling Entropy Label Capability and 625 Readable Label-stack Depth Using IS-IS", draft-ietf-isis- 626 mpls-elc-03 (work in progress), January 2018. 628 [I-D.ietf-isis-segment-routing-extensions] 629 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 630 Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura, 631 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 632 segment-routing-extensions-15 (work in progress), December 633 2017. 635 [I-D.ietf-isis-segment-routing-msd] 636 Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 637 "Signaling MSD (Maximum SID Depth) using IS-IS", draft- 638 ietf-isis-segment-routing-msd-09 (work in progress), 639 January 2018. 641 [I-D.ietf-spring-segment-routing] 642 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 643 Litkowski, S., and R. Shakir, "Segment Routing 644 Architecture", draft-ietf-spring-segment-routing-15 (work 645 in progress), January 2018. 647 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 648 Topology (MT) Routing in Intermediate System to 649 Intermediate Systems (IS-ISs)", RFC 5120, 650 DOI 10.17487/RFC5120, February 2008, 651 . 653 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 654 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 655 2008, . 657 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 658 and M. Fanto, "IS-IS Generic Cryptographic 659 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 660 2009, . 662 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 663 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 664 . 666 [RFC7645] Chunduri, U., Tian, A., and W. Lu, "The Keying and 667 Authentication for Routing Protocol (KARP) IS-IS Security 668 Analysis", RFC 7645, DOI 10.17487/RFC7645, September 2015, 669 . 671 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 672 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 673 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 674 March 2016, . 676 Authors' Addresses 678 Uma Chunduri (editor) 679 Huawei USA 680 2330 Central Expressway 681 Santa Clara, CA 95050 682 USA 684 Email: uma.chunduri@huawei.com 686 Jeff Tantsura 687 Nuage Networks 688 755 Ravendale Drive 689 Mountain View, CA 94043 690 USA 692 Email: jefftant.ietf@gmail.com 693 Yingzhen Qu 694 Huawei USA 695 2330 Central Expressway 696 Santa Clara, CA 95050 697 USA 699 Email: yingzhen.qu@huawei.com