idnits 2.17.00 (12 Aug 2021) /tmp/idnits48973/draft-ct-isis-nspfid-for-sr-paths-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == 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 (March 5, 2018) is 1538 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 581, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-hegde-spring-traffic-accounting-for-sr-paths-01 == Outdated reference: draft-ietf-6man-segment-routing-header has been published as RFC 8754 == Outdated reference: draft-ietf-isis-mpls-elc has been published as RFC 9088 == Outdated reference: draft-ietf-isis-segment-routing-extensions has been published as RFC 8667 == Outdated reference: draft-ietf-isis-segment-routing-msd has been published as RFC 8491 == Outdated reference: draft-ietf-spring-segment-routing has been published as RFC 8402 Summary: 1 error (**), 0 flaws (~~), 9 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 6, 2018 Nuage Networks 6 Y. Qu 7 Huawei Technologies 8 March 5, 2018 10 Usage of Non Shortest Path Forwarding (NSPF) Ids in IS-IS 11 draft-ct-isis-nspfid-for-sr-paths-00 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 6, 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 . . . . . . . . . 5 67 2.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 2.2. NSPF-ID Fields . . . . . . . . . . . . . . . . . . . . . 7 69 2.3. NSP sub-TLVs . . . . . . . . . . . . . . . . . . . . . . 8 70 2.4. Non-NSP sub-TLVs . . . . . . . . . . . . . . . . . . . . 9 71 3. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 9 72 4. NSPF ID Data plane aspects . . . . . . . . . . . . . . . . . 11 73 5. NSP Traffic Accounting . . . . . . . . . . . . . . . . . . . 11 74 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 79 9.2. Informative References . . . . . . . . . . . . . . . . . 12 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 82 1. Introduction 84 In a network implementing source routing, packets may be transported 85 through the use of segment identifiers (SIDs), where a SID uniquely 86 identifies a segment as defined in [I-D.ietf-spring-segment-routing]. 87 In SR-MPLS, a segment is encoded as a label and an ordered list of 88 segments is encoded as a stack of labels. In SRv6, a segment is 89 encoded as an IPv6 address, with a new type of IPv6 routing header 90 called SRH. An ordered list of segments is encoded as an ordered 91 list of IPv6 addresses in SRH [I-D.ietf-6man-segment-routing-header]. 93 The segment may include one or more nodes, unidirectional adjecencies 94 between two nodes or service instruction by a particular node in the 95 network. A Non Shortest Path (NSP) may be described using list of 96 segments in SR. However, this creates a problem of having a 97 relatively large stack imposed on the data packet. A path that is 98 encoded with SIDs can be a loose or strict path. In a strict path 99 all the nodes/links on the path are encoded as SIDs, with the expense 100 of number of total SIDs in the stack. 102 1.1. Mitigation with MSD and RLD 104 The number of SIDs in the stack a node can impose is referred as 105 Maximum SID Depth (MSD) capability 106 [I-D.ietf-isis-segment-routing-msd], which must be taken into 107 consideration when computing a path to transport a data packet in a 108 network implementing segment routing. [I-D.ietf-isis-mpls-elc] 109 defines Readable Label Depth (RLD) that is used by a head-end to 110 insert Entropy Label pair (ELI/EL) at appropriate depth, so it could 111 be read by transit nodes. There are situations where the source 112 routed path can be excessive as path represented by SR SIDs need to 113 describe all the nodes and ELI/EL based on the readability of the 114 nodes in that path. 116 While MSD (and RLD) capabilities advertisement help mitigate the 117 problem for a central entity to create the right source routed path 118 per application/operator requirements; actual depth is still limited 119 by the underlying hardware in the data path. 121 1.2. Issues with Increased SID Depth 123 Consider the following network where SR-MPLS data plane is in use and 124 with same SRGB (5000-6000) on all nodes i.e., A1 to A7 and B1 to B7 125 for illustration: 127 SID:10 SID:20 SID:30 SID:40 SID:50 SID:300(Ax) SID:60 SID:70 128 A1-------A2-------A3-------A4-------A5===============A6----------A7 129 \ / \ SID:310(Ay) \ / 130 \ 10 10/ \ \10 /10 131 \ / \ \ / 132 SID:80 \A8-----A9/SID:90 \ 40 \ / 133 / \ +-----+ \ / 134 /10 \10 \ \/ 135 B1--------B2-----------B3----B4--------B5-------B6----------B7 136 SID:110 SID:120 SID:130 SID:140 SID:150 SID:160 SID:170 138 Figure 1: SR-MPLS Network 140 Global ADJ SIDs are provisioned between A5 and A6 .All other SIDs 141 shown are nodal SID indices. 143 All metrics of the links are set to 1, other values as configured. 145 Shortest Path from A1 to A7: A2-A3-A4-A5-A6-A7 147 Shortest Path from B1 to B7: B2-B3-B4-B5-B6-B7 149 SR-PATH-1: From A1 to A7 - A2-A8-B2-B3-A9-A5-Ax-A7; Pushed Label 150 Stack @A1: 5070:5300:5050:5090:5130:5120:5080:5020 152 SR-PATH-2: From B1 to B7 - B2-A8-A2-A4-A9-B4-B6-B7; Pushed Label 153 Stack @B1: 5170:5160:5140:5090:5040:5020:5080:5120 155 In the above example both SR-PATH-1 and SR-PATH-2 are represented 156 with a combination of Adjacency and Node SIDs with a stack of 8 157 labels each. However, this value can be larger, if the use of 158 entropy label is desired and based on the RLD capabilities of each 159 node and additional labels required to insert ELI/EL at appropriate 160 places. Though above network is shown with SR-MPLS data plane, 161 problem is similar if the network were a SR-IPv6 network with all 162 SIDs encoded as IPv6 SIDs in SRH. 164 In various SR deployments, the following issues may arise: 166 Not all nodes in the path can support MSD or RLD needed to satisfy 167 user/operator requirements, when the number of SIDs increased to 168 describe the source routed path. This problem gets multiplied by 169 four times in SRH compared to MPLS data plane because of the SID 170 size (16 bytes) in SRH. 172 Even if all nodes can support the required MSD or RLD, the bigger 173 label stack/depth can cause potential MTU/fragmentation issues. 175 In some deployments, it is also required reducing the overhead in 176 the network layer, especially for low packet size packets, where 177 the actual data can be way lesser than all encapsulations and SR 178 path overheads. 180 Apart from the above some deployments need path accounting statistics 181 for path monitoring and traffic re-optimizations. 182 [I-D.hegde-spring-traffic-accounting-for-sr-paths] proposes a 183 solution, however this further increases the depth of SID stack. The 184 approach could be counter productive in the environments, where SID 185 depth is already causing deployment issues as listed above. 187 To mitigate the above issues, and also to facilitate forwarding plane 188 a mechanism to identify the SR path with a corresponding data plane 189 identifier for accounting of traffic for SR paths, this draft 190 proposes a new IS-IS TLV (Section 2) to advertise the NSPs with Non 191 Shortest Path Forwarding IDentifier (NSPF ID). 193 This draft lays out procedure for IS-IS nodes to how to use NSPF ID 194 TLV in Section 3. With corresponding data plane, Section 3 195 mechanism, reduces the SID stack in the data plane from 8 SIDs shown 196 in SR-PATH-1 and SR-PATH-2 with a single NSPF ID. This draft also 197 introduce source routed paths with NSPF ID types defined for native 198 IPv4 and IPv6 data planes as defined in Section 2.2. 200 1.3. Acronyms 202 EL - Entropy Label 204 ELI - Entropy Label Indicator 206 MPLS - Multi Protocol Label Switching 208 MSD - Maximum SID Depth 210 MTU - Maximum Transferrable Unit 212 SID - Segment Identifier 214 SPF - Shortest Path First 216 SR - Segment Routing 218 SRH - Segment Routing Header 220 SR-MPLS - Segment Routing with MPLS data plane 222 SRv6 - Segment Routing with Ipv6 data plane with SRH 224 SRH - IPv6 Segment Routing Header 226 TE - Traffic Engineering 228 2. Non Shortest Path Forwarding IDentifier TLV 230 The NSPF-ID TLV has Type TBD (suggested value xxx), and has the 231 following format: 233 0 1 2 3 234 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 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Type | Length | Reserved | Flags | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | MT-ID | Prefix Len | FEC Prefix | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 // FEC Prefix (continued, variable) // 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | NSPF-ID Type | NSPF-ID Len | NSPF-ID Flags | NSPF-ID Algo | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 // NSPF-ID (continued, variable) // 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 |No.of NSP-STs | NSP sub-TLVs (Variable) // 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 |No.of Other-STs| Non-NSP sub-TLVs(variable) // 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 Figure 2: NSPF ID TLV Format 253 Type - TBD from IS-IS top level TLV registry. 255 Length - Total length of the value field in bytes (variable). 257 Reserved - 1 Octet reserved bits for future use. Reserved bits 258 MUST be reset on transmission and ignored on receive. 260 Flags - Flags for this TLV are described in Section 2. 262 MT-ID - is the multi-topology identifier defined in [RFC5120] with 263 4 most significant bits reset on transmission and ignored on 264 receive. The remaining 12-bit field contains the MT-ID. 266 Prefix Len - contains the length of the prefix in bits. Only the 267 most significant octets of the Prefix are encoded. (i.e., 1 octet 268 for prefix length 1 up to 8, 2 octets for prefix length 9 to 16, 3 269 octets for prefix length 17 up to 24 and 4 octets for prefix 270 length 25 up to 32, ...., 16 octets for prefix length 113 up to 271 128). 273 FEC Prefix - represents the Forwarding Equivalence Class at the 274 tail-end of the advertised NSP. The 'FEC Prefix' corresponds to a 275 routable prefix of the originating node, meaning one of the 276 [RFC7794] flags MUST be set (X-Flag/R-Flag/N-Flag). Value of this 277 field can be 4 or 16 octets and encoding is similar to TLV 135 and 278 TLV 236 or MT-Capable [RFC5120] IPv4 (TLV 235) and IPv6 Prefixes 279 (TLV 237) respectively. 281 2.1. Flags 283 Flags: 1 octet field of NSPD ID TLV has following flags defined. 284 These flags mostly related to applicability of this TLV in an L1 area 285 or entire IS-IS domain: 287 NSPF ID Flags Format 289 0 1 2 3 4 5 6 7 290 +-+-+-+-+-+-+-+-+ 291 |S|D|A| Rsrvd | 292 +-+-+-+-+-+-+-+-+ 294 S - If set, the NSPF ID TLV SHOULD be flooded across the entire 295 routing domain. If the S flag is not set, the NSPF ID TLV MUST 296 NOT be leaked between IS-IS levels. This bit MUST NOT be altered 297 during the TLV leaking 299 D - when the NSPF ID TLV is leaked from IS-IS level-2 to level-1, 300 the D bit MUST be set. Otherwise, this bit MUST be clear. NSPF 301 ID TLVs with the D bit set MUST NOT be leaked from level-1 to 302 level-2. This is to prevent TLV looping across levels. 304 A - The originator of the NSPF ID TLV MAY set the A bit in order 305 to signal that the prefixes and NSPF-IDs advertised in the NSPF ID 306 TLV are directly connected to their originators. The mechanisms 307 through which the originator of the NSPF ID TLV can figure out if 308 a prefix is attached or not are outside the scope of this document 309 (e.g.: through explicit configuration). If the NSPF ID TLV is 310 leaked to other areas/levels the A-flag MUST be cleared. 312 Rsrvd - reserved bits for future use. Reserved bits MUST be reset 313 on transmission and ignored on receive. 315 Flags defined above are similar to 316 [I-D.ietf-isis-segment-routing-extensions] and section 2.4.1 317 restrictions apply here. 319 2.2. NSPF-ID Fields 321 This represents the actual data plane identifier in the packet and 322 could be of any data plane as defined in type field. As with "FEC 323 Prefix", NSPF-ID also need not be from the advertising node of NSPF 324 ID itself. However, both MUST belong to a same node in the network. 326 NSPF-ID Type: This is a new registry (TBD IANA) for this TLV and 327 the defined types are as follows. Type: 1 - MPLS SID/Label Type: 329 2 Native IPv4 Address Type: 3 Native IPv6 Address Type 4: IPv6 SID 330 in SRv6 with SRH 332 NSPF-ID Len: Length of the NSPF Identifier field in octets and 333 this depends on the NSPF-ID type. 335 NSPF-ID Flags: 1 Octet field for NSPF-ID flags. Some of the bits 336 could be NSPF-ID type specific and each new type MUST define the 337 flags applicable to the NSPF-ID type. For NSPF-ID Type 1, the 338 flags are same as Section 2.1 definition in 339 [I-D.ietf-isis-segment-routing-extensions]. For NSPF-ID Type 2, 3 340 and NSPF-ID Type 4 only 'R' flag is applicable. Undefined flags 341 for each NSPF-ID type MUST be considered as RESERVED. RESERVED 342 flag bits in each NSPF-ID type specific flags MUST be reset on 343 transmission and ignored on receive. 345 NSPF-ID Algo: 1 octet value represents the SPF algorithm 347 2.3. NSP sub-TLVs 349 A new sub-TLV registry is created (TBD IANA) called NSP sub-TLVs. 350 These are used to describe the path in the form of set of contiguous 351 sub-TLVs. Total number of the non-NSP sub-TLVs are defined in 352 1-octet field "No.of NSP-STs" just before the NSP sub-TLVs. 354 Type 1: SID/Lable sub-TLV as defined in Section 2.3 of 355 [I-D.ietf-isis-segment-routing-extensions]. Only Type is defined 356 and Length/Value fields are per Section 2.3 of the referenced 357 document. 359 Type 2: Prefix SID sub-TLV as defined in Section 2.1 360 of[I-D.ietf-isis-segment-routing-extensions]. Only Type is 361 defined and Length/Value fields are per Section 2.1 of the 362 referenced document. 364 Type 3: Adjacency SID sub-TLV as defined in Section 2.2 of 365 [I-D.ietf-isis-segment-routing-extensions]. Only Type is defined 366 and Length/Value fields are per Section 2.2 of the referenced 367 document. 369 Type 4: Length 4 bytes, value is 4 bytes IPv4 address encoded 370 similar to IPv4 FEC Prefix described above. 372 Type 5: Length 16 bytes, value is 16 bytes IPv6 address encoded 373 similar to IPv4 FEC Prefix described above. 375 2.4. Non-NSP sub-TLVs 377 NSPF ID TLV also defines a new sub-TLV registry (TBD IANA) for 378 defining extensible set of sub-TLVs other than describing the path 379 sub-TLVs. Total number of the path sub-TLVs to describe the path are 380 defined in 1-octet field "No.of Other-STs" just before the Non-NSP 381 sub-TLVs. This field serves as a demarcation for set of NSP sub-TLVs 382 and Non-NSP sub-TLVs. 384 Type 1: Length 0 No value field. Specifies a counter to count 385 number of packets forwarded on this NSPF-ID. 387 Type 2: Length 0 No value field. Specifies a counter to count 388 number of bytes forwarded on this NSPF-ID specified in the network 389 header (e.g. IPv4, IPv6). 391 Type 3: Length 4 bytes, and Value is metric of this path 392 represented through the NSPF-ID. Different nodes can advertise 393 the same NSPF-ID for the same FEC-Prefix with a different set of 394 NSP sub-TLVs and the receiving node MUST consider the lowest 395 metric value (TBD more, what happens when metric is same for two 396 different set of NSP sub-TLVs). 398 3. Elements of Procedure 400 Consider the following IS-IS network to describe the operation of 401 NSPF ID TLV as defined in Section 2: 403 1 404 _______ 405 / 1 \ 406 +---R2-------R3---+ 407 / \_______/ \ 408 / 1 \ 409 1 / 2 \ 1 410 / ______ \ 411 / / \ \ 412 R1------R6 R7-----------R4 413 \ 2 \______/ 2 / 414 \ 2 / 415 3 \ / 3 416 \ 3 / 417 +----R8------R9-----R10--+ 418 3 \ / 419 1 \ / 1 420 +-R11-+ 422 Figure 3: IS-IS Network 424 In the above diagram (Figure 3) node R1 is an ingress node, or a 425 head-end node, and the node R4 may be an egress node or another head- 426 end node. The numbers shown on each of the links between nodes 427 R1-R11 indicate a IS-IS metric as provisioned by the operator. R1 428 may be configured to receive TE source routed path information from a 429 central entity that comprise NSP information which relates to sources 430 that are attached to R1. The NSP information includes the stack or 431 list of nodes in the NSPs from the source to a destination in the 432 network and the NSPF ID. For example, the NSP information may 433 include a sequential ordering of NSP Sub-TLVS as defined by NSPF-ID 434 type, which specifies the actual path toward a FEC/Prefix by R4. 436 The shortest path may be defined by the following sequence of nodes: 437 R1-R2-R3-R4 based on the configured metrics. The central entity MAY 438 define a few NSPs from R1 to R4 that deviate from the shortest path 439 based on other network characteristic requirements as requested by an 440 application or service. For example, the network characteristics or 441 performance requirements may include bandwidth, jitter, latency, 442 throughput, error rate, etc. A first NSP may be identified by NSPF 443 ID = 2 and may include the path of R1-R6-R7-R4 for a FEC Prefix 444 advertised by R4. A second NSP may be identified by NSPF ID = 3 and 445 may include the path of R1-R8-R9-R10-R4. 447 Each receiving node, determine whether an advertised NSP includes 448 information regarding the receiving node. This MAY be done, during 449 the end of the SPF computation for MTID that is advertised in this 450 TLV and for the FEC/Prefix. For example, suppose node R9 receives 451 the NSP information, node R9 may ignore the first NSP identified by 452 NSPF ID = 2 because this NSP does not include node R9. 454 However, node R9 may determine that the second NSP identified by NSPF 455 ID = 3 does include the node R9 for the FEC prefix advertised by R4. 456 Therefore, node R9 updates the local forwarding database to include 457 an entry for the destination address of R4 that indicates that when a 458 data packet comprising a NSPF ID of 3 is received, node R9 is now 459 configured to forward the data packet to node R10 instead of R11. 460 This is even though the link to node R10 is associated with a higher 461 cost of 3 than the link to node R11, which is associated with a cost 462 of 1. 464 4. NSPF ID Data plane aspects 466 Data plane NSPF ID is selected by the entity (e.g., a controller) 467 which selects a particular NSP in the network. Section 2.2 defines 468 various data plane identifier types and a corresponding data plane 469 identifier type and identifier is selected by the entity which 470 selects the NSP. For example if NSPF-ID Type is 1, the NSP belongs 471 to SR-MPLS data plane and the complete NSP stack is represented with 472 a unique SR SID/Label. And same logic applies to other NSPF-ID 473 types. 475 5. NSP Traffic Accounting 477 As described in Section 2.4, each node described in the NSP sub-TLVs 478 SHOULD provision the hardware to account the traffic statistics as 479 indicated in the non-NSP sub-TLVs for the actual data traffic. When 480 NSP is withdrawn from the originating node, rest of the nodes in the 481 NSP MUST remove the state in respective nodes. This approach, thus 482 is more safe and secure than any mechanism that involves creating 483 state in the nodes with data traffic itself. This is because 484 creation and deletion of the traffic accounting state for NSPs happen 485 through IS-IS LSP processing and IS-IS security Section 8 options are 486 applicable to this TLV. 488 6. Acknowledgements 490 Thanks to Richard Li, Alex Clemm, Kiran Makhijani and Lin Han for 491 initial discussions on this topic. 493 Earlier versions of draft-ietf-isis-segment-routing-extensions have a 494 mechanism to advertise EROs through Binding SID. 496 7. IANA Considerations 498 This document requests the following new TLVin IANA IS-IS TLV code- 499 point registry. 501 TLV # Name 502 ----- -------------- 503 TBD NSPF ID TLV 505 This document also requests IANA to create new registries for NSPF ID 506 TLV Flags field, NSPF-ID Type, NSPF-ID Flags, NSP sub-TLVs and Non- 507 NSP sub-TLVs in NSPF ID TLV as described in Section 2. 509 8. Security Considerations 511 Security concerns for IS-IS are addressed in [RFC5304] and [RFC5310]. 512 Further security analysis for IS-IS protocol is done in [RFC7645]. 513 Advertisement of the additional information defined in this document 514 introduces no new security concerns. 516 9. References 518 9.1. Normative References 520 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 521 Requirement Levels", BCP 14, RFC 2119, 522 DOI 10.17487/RFC2119, March 1997, 523 . 525 9.2. Informative References 527 [I-D.hegde-spring-traffic-accounting-for-sr-paths] 528 Hegde, S., "Traffic Accounting for MPLS Segment Routing 529 Paths", draft-hegde-spring-traffic-accounting-for-sr- 530 paths-01 (work in progress), October 2017. 532 [I-D.ietf-6man-segment-routing-header] 533 Previdi, S., Filsfils, C., Raza, K., Dukes, D., Leddy, J., 534 Field, B., daniel.voyer@bell.ca, d., 535 daniel.bernier@bell.ca, d., Matsushima, S., Leung, I., 536 Linkova, J., Aries, E., Kosugi, T., Vyncke, E., Lebrun, 537 D., Steinberg, D., and R. Raszuk, "IPv6 Segment Routing 538 Header (SRH)", draft-ietf-6man-segment-routing-header-08 539 (work in progress), January 2018. 541 [I-D.ietf-isis-mpls-elc] 542 Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S. 543 Litkowski, "Signaling Entropy Label Capability and 544 Readable Label-stack Depth Using IS-IS", draft-ietf-isis- 545 mpls-elc-03 (work in progress), January 2018. 547 [I-D.ietf-isis-segment-routing-extensions] 548 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 549 Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura, 550 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 551 segment-routing-extensions-15 (work in progress), December 552 2017. 554 [I-D.ietf-isis-segment-routing-msd] 555 Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 556 "Signaling MSD (Maximum SID Depth) using IS-IS", draft- 557 ietf-isis-segment-routing-msd-09 (work in progress), 558 January 2018. 560 [I-D.ietf-spring-segment-routing] 561 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 562 Litkowski, S., and R. Shakir, "Segment Routing 563 Architecture", draft-ietf-spring-segment-routing-15 (work 564 in progress), January 2018. 566 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 567 Topology (MT) Routing in Intermediate System to 568 Intermediate Systems (IS-ISs)", RFC 5120, 569 DOI 10.17487/RFC5120, February 2008, 570 . 572 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 573 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 574 2008, . 576 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 577 and M. Fanto, "IS-IS Generic Cryptographic 578 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 579 2009, . 581 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 582 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 583 . 585 [RFC7645] Chunduri, U., Tian, A., and W. Lu, "The Keying and 586 Authentication for Routing Protocol (KARP) IS-IS Security 587 Analysis", RFC 7645, DOI 10.17487/RFC7645, September 2015, 588 . 590 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 591 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 592 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 593 March 2016, . 595 Authors' Addresses 597 Uma Chunduri (editor) 598 Huawei USA 599 2330 Central Expressway 600 Santa Clara, CA 95050 601 USA 603 Email: uma.chunduri@huawei.com 605 Jeff Tantsura 606 Nuage Networks 607 755 Ravendale Drive 608 Mountain View, CA 94043 609 USA 611 Email: jefftant.ietf@gmail.com 613 Yingzhen Qu 614 Huawei Technologies 615 2330 Central Expressway 616 Santa Clara, CA 95050 617 USA 619 Email: yingzhen.qu@huawei.com