idnits 2.17.1 draft-ietf-isis-fs-lsp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 4, 2014) is 3613 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEEaq' -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' ** Obsolete normative reference: RFC 4971 (Obsoleted by RFC 7981) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5306 (Obsoleted by RFC 8706) ** Obsolete normative reference: RFC 6822 (Obsoleted by RFC 8202) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group L. Ginsberg 3 Internet-Draft S. Previdi 4 Intended status: Standards Track Y. Yang 5 Expires: December 6, 2014 Cisco Systems 6 June 4, 2014 8 IS-IS Flooding Scope LSPs 9 draft-ietf-isis-fs-lsp-02.txt 11 Abstract 13 Intermediate System To Intermediate System (IS-IS) provides efficient 14 and reliable flooding of information to its peers. However the 15 current flooding scopes are limited to either area wide scope or 16 domain wide scope. There are existing use cases where support of 17 other flooding scopes are desirable. This document defines new 18 Protocol Data Units (PDUs) which provide support for new flooding 19 scopes as well as additional space for advertising information 20 targeted for the currently supported flooding scopes. This document 21 also defines extended TLVs and sub-TLVs which are encoded using 16 22 bit fields for type and length. 24 The protocol extensions defined in this document are not backwards 25 compatible with existing implementations and so must be deployed with 26 care. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119 [RFC2119]. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on December 6, 2014. 50 Copyright Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 This document may contain material from IETF Documents or IETF 66 Contributions published or made publicly available before November 67 10, 2008. The person(s) controlling the copyright in some of this 68 material may not have granted the IETF Trust the right to allow 69 modifications of such material outside the IETF Standards Process. 70 Without obtaining an adequate license from the person(s) controlling 71 the copyright in such materials, this document may not be modified 72 outside the IETF Standards Process, and derivative works of it may 73 not be created outside the IETF Standards Process, except to format 74 it for publication as an RFC or to translate it into languages other 75 than English. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 80 2. Extended TLVs . . . . . . . . . . . . . . . . . . . . . . . . 4 81 2.1. Use of Extended TLVs and Extended sub-TLVs . . . . . . . 5 82 2.2. Use of Standard Code Points in Extended TLVs and Extended 83 sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . 5 84 3. Definition of New PDUs . . . . . . . . . . . . . . . . . . . 6 85 3.1. Flooding Scoped LSP Format . . . . . . . . . . . . . . . 6 86 3.2. Flooding Scoped CSNP Format . . . . . . . . . . . . . . . 9 87 3.3. Flooding Scope PSNP Format . . . . . . . . . . . . . . . 10 88 4. Flooding Scope Update Process Operation . . . . . . . . . . . 12 89 4.1. Scope Types . . . . . . . . . . . . . . . . . . . . . . . 12 90 4.2. Operation on Point-to-Point Circuits . . . . . . . . . . 12 91 4.3. Operation on Broadcast Circuits . . . . . . . . . . . . . 13 92 4.4. Use of Authentication . . . . . . . . . . . . . . . . . . 13 93 4.5. Priority Flooding . . . . . . . . . . . . . . . . . . . . 13 94 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 14 95 6. Graceful Restart Interactions . . . . . . . . . . . . . . . . 14 96 7. Multi-instance Interactions . . . . . . . . . . . . . . . . . 14 97 8. Circuit Scoped Flooding . . . . . . . . . . . . . . . . . . . 14 98 9. Extending LSP Set Capacity . . . . . . . . . . . . . . . . . 15 99 10. Domain Scoped Flooding . . . . . . . . . . . . . . . . . . . 16 100 11. Announcing Support for Flooding Scopes . . . . . . . . . . . 17 101 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 102 13. Security Considerations . . . . . . . . . . . . . . . . . . . 19 103 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 104 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 105 15.1. Normative References . . . . . . . . . . . . . . . . . . 20 106 15.2. Informational References . . . . . . . . . . . . . . . . 21 107 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 21 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 110 1. Introduction 112 The Update Process as defined by [IS-IS] provides reliable and 113 efficient flooding of information to all routers in a given flooding 114 scope. Currently the protocol supports two flooding scopes and 115 associated Protocol Data Units (PDUs). Level 1 (L1) Link State PDUs 116 (LSPs) are flooded to all routers in an area. Level 2 (L2) LSPs are 117 flooded to all routers in the Level 2 sub-domain. The basic 118 operation of the Update Process can be applied to any subset of the 119 routers in a given topology so long as that topology is not 120 partitioned. It is therefore possible to introduce new PDUs in 121 support of other flooding scopes and utilize the same Update Process 122 machinery to provide the same reliability and efficiency which the 123 Update Process currently provides for L1 and L2 scopes. This 124 document defines these new PDUs and the modified Update Process rules 125 which are to be used in supporting new flooding scopes. 127 New deployment cases have introduced the need for reliable and 128 efficient circuit scoped flooding. For example, Appointed Forwarder 129 information as defined in [RFC7176] needs to be flooded reliably and 130 efficiently to all RBridges on a broadcast circuit. Currently, only 131 Intermediate System to Intermediate System Hellos (IIHs) have the 132 matching scope - but IIHs are unreliable i.e. individual IIHs may be 133 lost without affecting correct operation of the protocol. To provide 134 reliability in cases where the set of information to be flooded 135 exceeds the carrying capacity of a single PDU requires sending the 136 information periodically even when no changes in the content have 137 occurred. When the information content is large this is inefficient 138 and still does not provide a guarantee of reliability. This document 139 defines circuit scoped flooding in order to provide a solution for 140 such cases. 142 Another existing limitation of [IS-IS] is the carrying capacity of an 143 LSP set. It has been noted in [RFC5311] that the set of LSPs that 144 may be originated by a system at each level is limited to 256 LSPs 145 and the maximum size of each LSP is limited by the minimum Maximum 146 Transmission Unit (MTU) of any link used to flood LSPs. [RFC5311] 147 has defined a backwards compatible protocol extension which can be 148 used to overcome this limitation if needed. While the [RFC5311] 149 solution is viable, in order to be interoperable with routers which 150 do not support the extension it imposes some restrictions on what 151 can/cannot be advertised in the Extended LSPs and requires allocation 152 of multiple unique system IDs to a given router. A more flexible and 153 less constraining solution is possible if interoperability with 154 legacy routers is not a requirement. As the introduction of new PDUs 155 required to support new flooding scopes is by definition not 156 interoperable with legacy routers, it is possible to simultaneously 157 introduce an alternative solution to the limited LSP set carrying 158 capacity of Level 1 and Level 2 LSPs as part of the extensions 159 defined in this document. This capability is also defined in this 160 document. 162 Standard IS-IS TLVs (Type/Length/Value) are encoded using an eight 163 bit type and an 8 bit length. In cases where the set of information 164 about a single object exceeds 255 octets multiple TLVs are required 165 to encode all of the relevant information. This document introduces 166 extended TLVs and extended sub-TLVs which use a 16 bit type field and 167 a 16 bit length field. 169 The PDU type field in the common header for all IS-IS PDUs is a 5 bit 170 field. The possible PDU types supported by the protocol are 171 therefore limited to a maximum of 32. In order to minimize the need 172 to introduce additional PDU types in the future, the new PDUs 173 introduced in this document are defined so as to allow multiple 174 flooding scopes to be associated with the same PDU type. This means 175 if new flooding scopes are required in the future the same PDU type 176 can be used. 178 2. Extended TLVs 180 Standard TLVs as defined in [IS-IS] as well as standard sub-TLVs 181 (first introduced in [RFC5305]) have an eight bit type field and an 182 eight bit length field. This constrains the information included in 183 a single TLV or sub-TLV to 255 octets. With the increasing use of 184 sub-TLVs it becomes more likely that the amount of information about 185 a single object which needs to be advertised may exceed 255 octets. 186 In such cases the information is encoded in multiple TLVs. This 187 leads to less efficient encoding since the information which uniquely 188 identifies the object must be repeated in each TLV and requires 189 additional implementation complexity when receiving the information 190 to ensure that all information about the object is correctly 191 collected from the multiple TLVs. 193 This document introduces extended TLVs and extended sub-TLVs. These 194 are encoded using a 16 bit type field and a 16 bit length field. 196 2.1. Use of Extended TLVs and Extended sub-TLVs 198 The following restrictions apply to the use of extended TLVs and 199 extended sub-TLVs: 201 o Extended TLVs and extended sub-TLVs are permitted only in Flooding 202 Scoped PDUs which have a flooding scope designated for their use 203 (defined later in this document) 205 o A given flooding scope supports the use of either standard TLVs 206 and standard sub-TLVs or the use of extended TLVs and extended 207 sub-TLVs but not both 209 o Extended TLVs and extended sub-TLVs MUST be used together i.e., 210 using Standard sub-TLVs within an Extended TLV or using Extended 211 sub-TLVs within a Standard TLV is invalid 213 o If additional levels of TLVs (e.g., sub-sub-TLVs) are introduced 214 in the future then the size of the type/length fields in these new 215 sub-types MUST match the size used in the parent 217 o The 16 bit type and length fields are encoded in network byte 218 order 220 o Use of extended TLVs and extended sub-TLVs does not alter in any 221 way the maximum size of PDUs which may sent or received 223 2.2. Use of Standard Code Points in Extended TLVs and Extended sub-TLVs 225 Standard TLV and standard sub-TLV code points as defined in the IANA 226 IS-IS TLV Codepoints Registry MAY be used in extended TLVs and 227 extended sub-TLVs. Encoding is as specified for each of the standard 228 TLVs and standard sub-TLVs with the following differences: 230 o The eight bit type is encoded as an unsigned 16 bit integer where 231 the 8 MSBs are all 0 233 o The eight bit length field is replaced by the 16 bit length field 235 o The length MAY take on values greater than 255 237 3. Definition of New PDUs 239 In support of new flooding scopes the following new PDUs are 240 required: 242 o Flooding Scoped LSPs (FS-LSPs) 244 o Flooding Scoped Complete Sequence Number PDUs (FS-CSNPs) 246 o Flooding Scoped Partial Sequence Number PDUs (FS-PSNPs) 248 Each of these PDUs is intentionally defined with a header as similar 249 in format as possible to the corresponding PDU types currently 250 defined in [IS-IS]. Although it might have been possible to 251 eliminate or redefine PDU header fields in a new way the existing 252 formats are retained in order to allow maximum reuse of existing PDU 253 processing logic in an implementation. 255 Note that in the case of all FS PDUs, the Maximum Area Addresses 256 field in the header of the corresponding standard PDU has been 257 replaced with a Scope field. The maximum area addresses checks 258 specified in [IS-IS] are therefore not performed on FS PDUs. 260 3.1. Flooding Scoped LSP Format 262 An FS-LSP has the following format: 264 No. of octets 265 +-------------------------+ 266 | Intradomain Routeing | 1 267 | Protocol Discriminator | 268 +-------------------------+ 269 | Length Indicator | 1 270 +-------------------------+ 271 | Version/Protocol ID | 1 272 | Extension | 273 +-------------------------+ 274 | ID Length | 1 275 +-------------------------+ 276 |R|R|R| PDU Type | 1 277 +-------------------------+ 278 | Version | 1 279 +-------------------------+ 280 | Reserved | 1 281 +-------------------------+ 282 |P| Scope | 1 283 +-------------------------+ 284 | PDU Length | 2 285 +-------------------------+ 286 | Remaining Lifetime | 2 287 +-------------------------+ 288 | FS LSP ID | ID Length + 2 289 +-------------------------+ 290 | Sequence Number | 4 291 +-------------------------+ 292 | Checksum | 2 293 +-------------------------+ 294 |Reserved|LSPDBOL|IS Type | 1 295 +-------------------------+ 296 : Variable Length Fields : Variable 297 +-------------------------+ 299 Intradomain Routeing Protocol Discriminator - 0x83 300 (as defined in [IS-IS]) 302 Length Indicator - Length of the Fixed Header in octets 304 Version/Protocol ID Extension - 1 306 ID Length - As defined in [IS-IS] 308 PDU Type - 10 (Subject to assignment by IANA) Format as 309 defined in [IS-IS] 311 Version - 1 313 Reserved - transmitted as zero, ignored on receipt 315 Scope - Bits 1-7 define the flooding scope. 316 The value 0 is reserved and MUST NOT be used. Received 317 FS-LSPs with a scope of 0 MUST be ignored and MUST NOT 318 be flooded. 319 P - Bit 8 - Priority Bit. If set to 1 this LSP SHOULD be flooded 320 at high priority. 321 Scopes (1 - 63) are reserved for use with standard TLVs and 322 standard sub-TLVs. 323 Scopes (64 - 127) are reserved for use with extended TLV and 324 extended sub-TLVs. 326 PDU Length - Entire Length of this PDU, in octets, including the 327 header. 329 Remaining Lifetime - Number of seconds before this FS-LSP is 330 considered expired. 332 FS LSP ID - the system ID of the source of the FS-LSP. One of 333 the following two formats is used: 335 FS LSP ID Standard Format 337 +-------------------------+ 338 | Source ID | ID Length 339 +-------------------------+ 340 | Pseudonode ID | 1 341 +-------------------------+ 342 | FS LSP Number | 1 343 +-------------------------+ 345 FS LSP ID Extended Format 347 +-------------------------+ 348 | Source ID | ID Length 349 +-------------------------+ 350 | Extended FS LSP Number | 2 351 +-------------------------+ 353 Which format is used is specific to the Scope and MUST be defined 354 when the specific flooding scope is defined. 356 Sequence Number - sequence number of this FS-LSP 358 Checksum - Checksum of contents of FS-LSP from Source ID to end. 359 Checksum is computed as defined in [IS-IS]. 361 Reserved/LSPDBOL/IS Type 363 Bits 4-8 are reserved, which means they are transmitted as 0 and 364 ignored on receipt. 366 LSPDBOL - Bit 3 - A value of 0 indicates no FS-LSP Database 367 Overload and a value of 1 indicates that the FS-LSP Database is 368 overloaded. The overload condition is specific to FS-LSPs with the 369 scope specified in the scope field. 371 IS Type - Bits 1 and 2. The type of Intermediate System as defined 372 in [IS-IS]. 374 Variable Length Fields which are allowed in an FS-LSP are specific to 375 the defined scope. 377 3.2. Flooding Scoped CSNP Format 379 An FS-CSNP has the following format: 381 No. of octets 382 +-------------------------+ 383 | Intradomain Routeing | 1 384 | Protocol Discriminator | 385 +-------------------------+ 386 | Length Indicator | 1 387 +-------------------------+ 388 | Version/Protocol ID | 1 389 | Extension | 390 +-------------------------+ 391 | ID Length | 1 392 +-------------------------+ 393 |R|R|R| PDU Type | 1 394 +-------------------------+ 395 | Version | 1 396 +-------------------------+ 397 | Reserved | 1 398 +-------------------------+ 399 |R| Scope | 1 400 +-------------------------+ 401 | PDU Length | 2 402 +-------------------------+ 403 | Source ID | ID Length + 1 404 +-------------------------+ 405 | Start FS-LSP ID | ID Length + 2 406 +-------------------------+ 407 | End FS-LSP ID | ID Length + 2 408 +-------------------------+ 409 : Variable Length Fields : Variable 410 +-------------------------+ 412 Intradomain Routeing Protocol Discriminator - 0x83 413 (as defined in [IS-IS] 415 Length Indicator - Length of the Fixed Header in octets 417 Version/Protocol ID Extension - 1 419 ID Length - As defined in [IS-IS] 420 PDU Type - 11 (Subject to assignment by IANA) Format as defined in 421 [IS-IS] 423 Version - 1 425 Reserved - transmitted as zero, ignored on receipt 427 Scope - Bits 1-7 define the flooding scope. 428 The value 0 is reserved and MUST NOT be used. Received 429 FS-CSNPs with a scope of 0 MUST be ignored. 430 Bit 8 is Reserved which means it is transmitted as 0 and 431 ignored on receipt. 432 Scopes (1 - 63) are reserved for use with standard TLVs and 433 standard sub-TLVs. 434 Scopes (64 - 127) are reserved for use with extended TLV and 435 extended sub-TLVs. 437 PDU Length - Entire Length of this PDU, in octets, including the 438 header. 440 Source ID - the system ID of the Intermediate System 441 (with zero Circuit ID) generating this Sequence Numbers PDU 443 Start FS-LSP ID - The FS-LSP ID of the first FS-LSP with the 444 specified scope in the range covered by this FS-CSNP. 446 End FS-LSP ID - The FS-LSP ID of the last FS-LSP with the 447 specified scope in the range covered by this FS-CSNP. 449 Variable Length Fields which are allowed in an FS-CSNP are 450 limited to those TLVs which are supported by standard CSNP. 452 3.3. Flooding Scope PSNP Format 454 An FS-PSNP has the following format: 456 No. of octets 457 +-------------------------+ 458 | Intradomain Routeing | 1 459 | Protocol Discriminator | 460 +-------------------------+ 461 | Length Indicator | 1 462 +-------------------------+ 463 | Version/Protocol ID | 1 464 | Extension | 465 +-------------------------+ 466 | ID Length | 1 467 +-------------------------+ 468 |R|R|R| PDU Type | 1 469 +-------------------------+ 470 | Version | 1 471 +-------------------------+ 472 | Reserved | 1 473 +-------------------------+ 474 |U| Scope | 1 475 +-------------------------+ 476 | PDU Length | 2 477 +-------------------------+ 478 | Source ID | ID Length + 1 479 +-------------------------+ 480 : Variable Length Fields : Variable 481 +-------------------------+ 483 Intradomain Routeing Protocol Discriminator - 0x83 484 (as defined in [IS-IS] 486 Length Indicator - Length of the Fixed Header in octets 488 Version/Protocol ID Extension - 1 490 ID Length - As defined in [IS-IS] 492 PDU Type - 12 (Subject to assignment by IANA) Format 493 as defined in [IS-IS] 495 Version - 1 497 Reserved - transmitted as zero, ignored on receipt 499 Scope - Bits 1-7 define the flooding scope. 500 The value 0 is reserved and MUST NOT be used. Received 501 FS-PSNPs with a scope of 0 MUST be ignored. 502 U - Bit 8 - A value of 0 indicates that the specified 503 flooding scope is supported. A value of 1 indicates 504 that the specified flooding scope is unsupported. When 505 U = 1, variable length fields other than authentication 506 MUST NOT be included in the PDU. 507 Scopes (1 - 63) are reserved for use with standard TLVs and 508 standard sub-TLVs. 509 Scopes (64 - 127) are reserved for use with extended TLV and 510 extended sub-TLVs. 512 PDU Length - Entire Length of this PDU, in octets, including 513 the header. 515 Source ID - the system ID of the Intermediate System 516 (with zero Circuit ID) generating this Sequence Numbers PDU 518 Variable Length Fields which are allowed in an FS-PSNP are 519 limited to those TLVs which are supported by standard PSNPs. 521 4. Flooding Scope Update Process Operation 523 The Update Process as defined in [IS-IS] maintains a Link State 524 Database (LSDB) for each level supported. Each level specific LSDB 525 contains the full set of LSPs generated by all routers operating in 526 that level specific scope. The introduction of FS-LSPs creates 527 additional LSDBs (FS-LSDBs) for each additional scope supported. The 528 set of FS-LSPs in each FS-LSDB consists of all FS-LSPs generated by 529 all routers operating in that scope. There is therefore an 530 additional instance of the Update Process for each supported flooding 531 scope. 533 Operation of the scope specific Update Process follows the Update 534 Process specification in [IS-IS]. The circuit(s) on which FS-LSPs 535 are flooded are limited to those circuits which are participating in 536 the given scope. Similarly the sending/receiving of FS-CSNPs and FS- 537 PSNPs is limited to the circuits participating in the given scope. 539 Consistent support of a given flooding scope on a circuit by all 540 routers operating on that circuit is required. 542 4.1. Scope Types 544 A flooding scope may be limited to a single circuit (circuit scope). 545 Circuit scopes may be further limited by level (L1 circuit scope/L2 546 circuit scope). 548 A flooding scope may be limited to all circuits enabled for L1 549 routing (area scope). 551 A flooding scope may be limited to all circuits enabled for L2 552 routing (L2 sub-domain scope). 554 Additional scopes may be defined which include all circuits enabled 555 for either L1 or L2 routing (domain-wide scope). 557 4.2. Operation on Point-to-Point Circuits 559 When a new adjacency is formed, synchronization of all FS-LSDBs 560 supported on that circuit is required. Therefore FS-CSNPs for all 561 supported scopes MUST be sent when a new adjacency reaches the UP 562 state. Send Receive Message (SRM) bit MUST be set for all FS-LSPs 563 associated with the scopes supported on that circuit. Receipt of an 564 FS-PSNP with the U bit equal to 1 indicates that the neighbor does 565 not support that scope (although it does support FS PDUs). This MUST 566 cause SRM bit to be cleared for all FS-LSPs with the matching scope 567 which are currently marked for flooding on that circuit. 569 4.3. Operation on Broadcast Circuits 571 FS PDUs are sent to the same destination address(es) as standard PDUs 572 for the given protocol instance. For specification of the defined 573 destination addresses consult [IS-IS], [IEEEaq], [RFC6822], and 574 [RFC6325]. 576 The Designated Intermediate System (DIS) for a broadcast circuit has 577 the responsibility to generate periodic scope specific FS-CSNPs for 578 all supported scopes. A scope specific DIS is NOT elected as all 579 routers on a circuit MUST support a consistent set of flooding 580 scopes. 582 It is possible that a scope may be defined which is not level 583 specific. In such a case the DIS for each level enabled on a 584 broadcast circuit MUST independently send FS PDUs for that scope to 585 the appropriate level specific destination address. This may result 586 in redundant flooding of FS-LSPs for that scope. 588 4.4. Use of Authentication 590 Authentication TLVs MAY be included in FS PDUs. When authentication 591 is in use, the scope is first used to select the authentication 592 configuration that is applicable. The authentication check is then 593 performed as normal. Although scope specific authentication MAY be 594 used, sharing of authentication among multiple scopes and/or with the 595 standard LSP/CSNP/PSNP PDUs is considered sufficient. 597 4.5. Priority Flooding 599 When the FS LSP ID Extended Format is used the set of LSPs generated 600 by an IS may be quite large. It may be useful to identify those LSPs 601 in the set which contain information of higher priority. Such LSPs 602 will have the P bit set to 1 in the Scope field in the LSP header. 603 Such LSPs SHOULD be flooded at a higher priority than LSPs with the P 604 bit set to 0. This is a suggested behavior on the part of the 605 originator of the LSP. When an LSP is purged the original state of 606 the P bit MUST be preserved. 608 5. Deployment Considerations 610 Introduction of new PDU types is incompatible with legacy 611 implementations. Legacy implementations do not support the FS 612 specific Update process(es) and therefore flooding of the FS-LSPs 613 throughout the defined scope is unreliable when not all routers in 614 the defined scope support FS PDUs. Further, legacy implementations 615 will likely treat the reception of an FS PDUs as an error. Even when 616 all routers in a given scope support FS PDUs, if not all routers in 617 the flooding domain for a given scope support that scope, then 618 flooding of the FS-LSPs may be compromised. Therefore all routers in 619 the flooding domain for a given scope SHOULD support both FS PDUs and 620 the specified scope before use of that scope can be enabled. 622 The U bit in FS-PSNPs provides a means to suppress retransmissions of 623 unsupported scopes. Routers which support FS PDUs SHOULD support the 624 sending of PSNPs with the U bit equal to 1 when an FS-LSP is received 625 with a scope which is unsupported. Routers which support FS PDUs 626 SHOULD trigger management notifications when FS PDUs are received for 627 unsupported scopes and when PSNPs with the U bit equal to 1 are 628 received. 630 6. Graceful Restart Interactions 632 [RFC5306] defines protocol extensions in support of graceful restart 633 of a routing instance. Synchronization of all supported FS-LSDBs is 634 required in order for database synchronization to be complete. This 635 involves the use of additional T2 timers. Receipt of a PSNP with the 636 U bit equal to 1 will cause FS-LSDB synchronization with that 637 neighbor to be considered complete for that scope. See [RFC5306] for 638 further details. 640 7. Multi-instance Interactions 642 In cases where FS-PDUs are associated with a non-zero instance the 643 use of IID-TLVs in FS-PDUs follows the rules for use in LSPs, CSNPs, 644 PSNPs as defined in [RFC6822]. 646 8. Circuit Scoped Flooding 648 This document defines four circuit scoped flooding identifiers: 650 o Level 1 circuit scope (L1CS) - this uses standard TLVs and 651 standard sub-TLVs 653 o Level 2 circuit scope (L2CS) - this uses standard TLVs and 654 standard sub-TLVs 656 o Extended Level 1 circuit scope (E-L1CS) - this uses extended TLVs 657 and extended sub-TLVs 659 o Extended Level 2 circuit scope (E-L1CS) - this uses extended TLVs 660 and extended sub-TLVs 662 FS-LSPs with the scope field set to one of these values contain 663 information specific to the circuit on which they are flooded. When 664 received, such FS-LSPs MUST NOT be flooded on any other circuit. The 665 FS LSP ID Extended format is used in these PDUs. The FS-LSDB 666 associated with circuit scoped FS-LSPs consists of the set of FS-LSPs 667 which both have matching circuit scope and are transmitted (locally 668 generated) or received on a specific circuit. 670 The set of TLVs which may be included in such FS-LSPs is specific to 671 the given use case and is outside the scope of this document. 673 9. Extending LSP Set Capacity 675 The need for additional space in the set of LSPs generated by a 676 single IS has been articulated in [RFC5311]. When legacy 677 interoperability is not a requirement, the use of FS-LSPs meets that 678 need without requiring the assignment of alias system-ids to a single 679 IS. Four flooding scopes are defined for this purpose: 681 o Level 1 Scope (L1FS) - this uses standard TLVs and standard sub- 682 TLVs 684 o Level 2 Scope (L2FS) - this uses standard TLVs and standard sub- 685 TLVs 687 o Extended Level 1 Scope (E-L1FS) - this uses extended TLVs and 688 extended sub-TLVs 690 o Extended Level 2 Scope (E-L2FS) - this uses extended TLVs and 691 extended sub-TLVs 693 L1FS and E-L1FS LSPs are flooded on all L1 circuits. L2FS and E-L2FS 694 LSPs are flooded on all L2 circuits. 696 The FS LSP ID Extended format is used in these PDUs. This provides 697 64K of additional LSPs which may be generated by a single system at 698 each level. 700 LxFS LSPs are used by the level specific Decision Process (defined in 701 [IS-IS]) in the same manner as standard LSPs (i.e. as additional 702 information sourced by the same IS) subject to the following 703 restrictions: 705 o A valid version of standard LSP #0 from the same IS at the 706 corresponding Level MUST be present in the LSDB in order for the 707 LxFS set to be usable 709 o Information in an LxFS LSP (e.g. IS-Neighbor information) which 710 supports using the originating IS as a transit node MUST NOT be 711 used when the Overload bit is set in the corresponding standard 712 LSP #0 714 o TLVs which are restricted to standard LSP #0 MUST NOT appear in 715 LxFS LSPs. 717 There are no further restrictions as to what TLVs may be advertised 718 in FS-LSPs. 720 10. Domain Scoped Flooding 722 Existing support for flooding information domain wide (i.e. to L1 723 routers in all areas as well as to routers in the Level 2 sub-domain) 724 requires the use of leaking procedures between levels. For further 725 details see [RFC4971]. This is sufficient when the data being 726 flooded domain-wide consists of individual TLVs. If it is desired to 727 retain the identity of the originating IS for the complete contents 728 of a PDU, then support for flooding the unchanged PDU is desirable. 729 This document therefore defines two flooding scopes in support of 730 domain-wide flooding. FS-LSPs with this scope MUST be flooded on all 731 circuits regardless of what level(s) are supported on that circuit. 733 o Domain Scope (DSFS) - this uses standard TLVs and standard sub- 734 TLVs 736 o Extended Domain Scope (E-DSFS) - this uses extended TLVs and 737 extended sub-TLVs 739 The FS LSP ID Extended format is used in these PDUs. 741 Use of information in FS-LSPs for a given scope depends on 742 determining the reachability to the IS originating the FS-LSP. This 743 presents challenges for FS-LSPs with domain-scopes because no single 744 IS has the full view of the topology across all areas. It is 745 therefore necessary for the originator of domain scoped DSFS and 746 E-DSFS LSPs to advertise an identifier which will allow an IS who 747 receives such an FS-LSP to determine whether the source of the FS-LSP 748 is currently reachable. The identifier required depends on what 749 "address-families" are being advertised. 751 When IS-IS is deployed in support of Layer 3 routing for IPv4 and/or 752 IPv6 then FS-LSP #0 with domain-wide scope MUST include at least one 753 of the following TLVs: 755 o IPv4 Traffic Engineering Router ID (TLV 134) 757 o IPv6 Traffic Engineering Router ID (TLV 140) 759 When IS-IS is deployed in support of Layer 2 routing, current 760 standards (e.g. [RFC6325]) only support a single area. Therefore 761 domain-wide scope is not yet applicable. When the Layer 2 standards 762 are updated to include multi-area support the identifiers which can 763 be used to support inter-area reachability will be defined - at which 764 point the use of domain-wide scope for Layer 2 can be fully defined. 766 11. Announcing Support for Flooding Scopes 768 Announcements of support for flooding scope may be useful in 769 validating that full support has been deployed and/or in isolating 770 the reasons for incomplete flooding of FS-LSPs for a given scope. 772 ISs supporting FS-PDUs MAY announce supported scopes in IIH PDUs. To 773 do so a new TLV is defined. 775 Scoped Flooding Support 776 Type: 243 (suggested - to be assigned by IANA) 777 Length: 1 - 127 778 Value 779 No of octets 780 +----------------------+ 781 |R| Supported Scope | 1 782 +----------------------+ 783 : : 784 +----------------------+ 785 |R| Supported Scope | 1 786 +----------------------+ 788 A list of the circuit scopes supported on this circuit and 789 other non-circuit flooding scopes supported. 790 R bit MUST be 0 and is ignored on receipt. 792 In a Point-Point IIH L1, L2, domain-wide, and all circuit scopes 793 MAY be advertised. 795 In Level 1 LAN IIHs L1, domain-wide, and L1 circuit scopes MAY be 796 advertised. L2 scopes and L2 circuit scopes MUST NOT be advertised. 798 In Level 2 LAN IIHs L2, domain-wide, and L2 circuit scopes MAY be 799 advertised. L1 scopes and L1 circuit scopes MUST NOT be advertised. 801 Information in this TLV MUST NOT be considered in adjacency 802 formation. 804 Whether information in this TLV is used to determine when FS-LSPs 805 associated with a locally supported scope are flooded is an 806 implementation choice. 808 12. IANA Considerations 810 This document requires the definition of three new PDU types that 811 need to be reflected in the ISIS PDU registry. Values below are 812 suggested values subject to assignment by IANA. 814 Value Description 815 ---- --------------------- 816 10 FS-LSP 817 11 FS-CSNP 818 12 FS-PSNP 820 This document requires that a new IANA registry be created to control 821 the assignment of scope identifiers in FS-PDUs. The registration 822 procedure is "Expert Review" as defined in [RFC5226]. Suggested 823 registry name is "LSP Flooding Scoped Identifier Registry". A scope 824 identifier is a number from 1-127 inclusive. Values 1 - 63 are 825 reserved for PDUs which use standard TLVs and standard sub-TLVs. 826 Values 64 - 127 are reserved for PDUs which use extended TLVs and 827 extended sub-TLVs. The list of hello PDUs in which support for a 828 given scope MAY be announced (using Scope Flooding Support TLV) is 829 specified for each defined scope. 831 The following scope identifiers are defined by this document. Values 832 are suggested values subject to assignment by IANA. 834 FS LSP ID Format/ IIH Announce 835 Value Description TLV Format P2P L1LAN L2LAN 836 ----- ------------------------------ ----------------- --------------- 837 1 Level 1 Circuit Flooding Scope Extended/Standard Y Y N 838 2 Level 2 Circuit Flooding Scope Extended/Standard Y N Y 839 3 Level 1 Flooding Scope Extended/Standard Y Y N 840 4 Level 2 Flooding Scope Extended/Standard Y N Y 841 5 Domain-wide Flooding Scope Extended/Standard Y Y Y 842 (6-63)Unassigned 844 64 Level 1 Circuit Flooding Scope Extended/Extended Y Y N 845 65 Level 2 Circuit Flooding Scope Extended/Extended Y N Y 846 66 Level 1 Flooding Scope Extended/Extended Y Y N 847 67 Level 2 Flooding Scope Extended/Extended Y N Y 848 68 Domain-wide Flooding Scope Extended/Extended Y Y Y 849 (69-127) Unassigned 851 This document requires the definition of a new IS-IS TLV to be 852 reflected in the "IS-IS TLV Codepoints" registry: 854 Type Description IIH LSP SNP Purge 855 ---- ------------ --- --- --- ----- 856 243 Circuit Scoped Flooding Support Y N N N 858 The IANA TLV codepoints registry is extended to allow definition of 859 codepoints less than or equal to 65535. Codepoints greater than 255 860 can only be used in PDUs designated to support extended TLVs. 862 13. Security Considerations 864 Security concerns for IS-IS are addressed in [IS-IS], [RFC5304], and 865 [RFC5310]. 867 The new PDUs introduced are subject to the same security issues 868 associated with their standard LSP/CSNP/PSNP counterparts. To the 869 extent that additional PDUs represent additional load for routers in 870 the network this increases the opportunity for denial of service 871 attacks. 873 14. Acknowledgements 875 The authors wish to thank Ayan Banerjee, Donald Eastlake, Hannes 876 Gredler, and Mike Shand for their comments. 878 15. References 880 15.1. Normative References 882 [IEEEaq] "Standard for Local and metropolitan area networks: Media 883 Access Control (MAC) Bridges and Virtual Bridged Local 884 Area Networks - Amendment 20: Shortest Path Bridging", 885 IEEE Std 802.1aq-2012, 29 June 2012.", 2012. 887 [IS-IS] "Intermediate system to Intermediate system intra-domain 888 routeing information exchange protocol for use in 889 conjunction with the protocol for providing the 890 connectionless-mode Network Service (ISO 8473), ISO/IEC 891 10589:2002, Second Edition.", Nov 2002. 893 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 894 Requirement Levels", BCP 14, RFC 2119, March 1997. 896 [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate 897 System to Intermediate System (IS-IS) Extensions for 898 Advertising Router Information", RFC 4971, July 2007. 900 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 901 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 902 May 2008. 904 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 905 Authentication", RFC 5304, October 2008. 907 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 908 Engineering", RFC 5305, October 2008. 910 [RFC5306] Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS", 911 RFC 5306, October 2008. 913 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 914 and M. Fanto, "IS-IS Generic Cryptographic 915 Authentication", RFC 5310, February 2009. 917 [RFC6822] Previdi, S., Ginsberg, L., Shand, M., Roy, A., and D. 918 Ward, "IS-IS Multi-Instance", RFC 6822, December 2012. 920 15.2. Informational References 922 [RFC5311] McPherson, D., Ginsberg, L., Previdi, S., and M. Shand, 923 "Simplified Extension of Link State PDU (LSP) Space for 924 IS-IS", RFC 5311, February 2009. 926 [RFC6325] Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A. 927 Ghanwani, "Routing Bridges (RBridges): Base Protocol 928 Specification", RFC 6325, July 2011. 930 [RFC7176] Eastlake, D., Senevirathne, T., Ghanwani, A., Dutt, D., 931 and A. Banerjee, "Transparent Interconnection of Lots of 932 Links (TRILL) Use of IS-IS", RFC 7176, May 2014. 934 Appendix A. Change History 936 Changes from 01 to 02 version 938 o Updated Section 11 to state what scopes MUST NOT be announced in a 939 given IIH PDU 941 o Updated IANA section for new "LSP Flooding Scoped Identifier 942 Registry" to include the hello PDUs in which a given scope may be 943 announced. 945 Authors' Addresses 947 Les Ginsberg 948 Cisco Systems 949 510 McCarthy Blvd. 950 Milpitas, CA 95035 951 USA 953 Email: ginsberg@cisco.com 954 Stefano Previdi 955 Cisco Systems 956 Via Del Serafico 200 957 Rome 0144 958 Italy 960 Email: sprevidi@cisco.com 962 Yi Yang 963 Cisco Systems 964 7100-9 Kit Creek Road 965 Research Triangle Park, North Carolina 27709-4987 966 USA 968 Email: yiya@cisco.com