idnits 2.17.1 draft-ietf-isis-ext-lsp-frags-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '3' on line 465 -- Possible downref: Non-RFC (?) normative reference: ref. 'ISIS-ISO' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISIS-TE' -- Obsolete informational reference (is this intentional?): RFC 2966 (ref. 'DOMAIN-WIDE') (Obsoleted by RFC 5302) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Amir Hermelin 3 Internet Draft Charlotte's Web Networks 4 Expiration Date: February 2003 5 Stefano Previdi 6 Mike Shand 7 Cisco Systems 9 Extending the Number of IS-IS LSP Fragments Beyond the 256 Limit 11 draft-ietf-isis-ext-lsp-frags-02.txt 13 Status 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This document describes a mechanism that allows a system to originate 37 more than 256 LSP fragments, a limit set by the original Intermediate 38 System to Intermediate System (IS-IS) Routing protocol, as described 39 in ISO 10589. This mechanism can be used in IP-only, OSI-only, and 40 dual routers. 42 1. Introduction 44 In the IS-IS protocol, a system floods its link-state information in 45 Link State Protocol Data Units, or LSPs for short. These logical 46 LSPs can become quite large, therefore the protocol specifies a means 47 of fragmenting this information into multiple LSP fragments. The 48 number of fragments a system can generate is limited by ISO 10589 49 [ISIS-ISO] to 256 fragments, where each fragment's size is also 50 limited. Hence, there is a limit on the amount of link-state 51 information a system can generate. 53 A number of factors can contribute to exceeding this limit: 54 - Introduction of new TLVs and sub-TLVs to be included in LSPs. 55 - The use of LSPs to propagate various types of information (such 56 as traffic-engineering information). 57 - The increasing number of destinations and AS topologies. 58 - Finer granularity routing, and the ability to inject external 59 routes into areas [DOMAIN-WIDE]. 60 - Other emerging technologies, such as optical, IPv6, etc. 62 This document describes mechanisms to relax the limit on the number 63 of LSP fragments. 65 1.1 Keywords 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 69 document are to be interpreted as described in RFC 2119 [BCP14]. 71 1.2 Definitions of Commonly Used Terms 73 This section provides definitions for terms that are used throughout 74 the text. 76 Originating System 77 A router physically running the IS-IS protocol. As this 78 document describes methods allowing a single IS-IS process to 79 advertise its LSPs as multiple "virtual" routers, the 80 Originating System represents the single "physical" IS-IS 81 process. 83 Normal system-id 84 The system-id of an Originating System. 86 Additional system-id 87 An Additional system-id that is assigned by the network 88 administrator. Each Additional system-id allows generation of 89 256 additional, or extended, LSP fragments. The Additional 90 system-id, like the Normal system-id, must be unique throughout 91 the routing domain. 93 Virtual System 94 The system, identified by an Additional system-id, advertised as 95 originating the extended LSP fragments. These fragments specify 96 the Additional system-id in their LSP IDs. 98 Original LSP 99 An LSP using the Normal system-id in its LSP ID. 101 Extended LSP 102 An LSP using an Additional system-id in its LSP ID. 104 LSP set 105 Logical LSP. This term is used only to resolve the ambiguity 106 between a logical LSP and an LSP fragment, both of which are 107 sometimes termed "LSP". 109 Extended LSP set 110 A group of LSP fragments using an Additional system-id, and 111 originated by the Originating System. 113 Extension-capable IS 114 An IS implementing the mechanisms described in this document. 116 1.3 Operation Modes 118 Two administrative operation modes are provided: 120 - Operation Mode 1 provides behavior that allows implementations 121 that don't support this extension, to correctly process the 122 extended fragment information, without any modifications. This 123 mode has some restrictions on what may be advertised in the 124 extended LSP fragments. Namely, only leaf information may be 125 advertised in the extended LSPs. 127 - Operation Mode 2 extends the previous mode and relaxes its 128 advertisement restrictions. Any link-state information may be 129 advertised in the extended LSPs. However, it mandates a change 130 to the way LSPs are considered during the SPF algorithm, in a way 131 that isn't compatible with previous implementations. 133 These modes are configured on a per-level and area basis. That is, 134 all LSPs considered in the same SPF instance MUST use the same Mode. 135 There is no restriction that an L1/L2 IS operates in the same mode, 136 for both its L1 and L2 instances. It can use Mode 1 for its L1 LSPs, 137 and Mode 2 for its L2 LSPs, or vice versa. 139 Mode 1 has the only advantage of being backwards compatible with 140 older implementations. It does have restrictions which are considered 141 drawbacks. Therefore, routers should operate in Mode 1 only if 142 backwards compatibility is desired. Otherwise, it is recommended to 143 run in Mode 2. 145 Routers MAY implement Operational Mode 2 without supporting running 146 in Operational Mode 1. They will still interoperate correctly with 147 routers that support both modes. 149 1.4 Overview 151 Using Additional system-ids assigned by the administrator, the 152 Originating System can advertise the excess link-state information in 153 extended LSPs under these Additional system-ids. It would do so as 154 if other routers, or "Virtual Systems", were advertising this 155 information. These extended LSPs will also have the specified limit 156 on their LSP fragments; however, the Originating System may generate 157 extended LSPs under numerous Virtual Systems. 159 For Operation Mode 1, 0-cost adjacencies are advertised from the 160 Originating System to its Virtual System(s). No adjacencies (other 161 than back to the Originating System) are advertised in the extended 162 LSPs. As a consequence, the Virtual Systems are 'stub', meaning they 163 can only be reached through their Originating System. Therefore, 164 older implementations do not need modifications in order to correctly 165 process these extended LSPs. 167 For both modes, each LSP (set) created by a node will contain in its 168 fragment-0 a new TLV (IS Alias ID TLV) that contains the Normal 169 system-id and PN Number of the Original LSP created by the router. 170 Extension-capable ISs can then use this information and store the 171 original and extended LSPs as one logical LSP. 173 The only sections that deal only with Mode 1 additions are 3.2, 174 3.2.1, and 3.2.2. All other sections relate to both modes. 176 2.0 IS Alias ID TLV (IS-A) 177 The proposed IS-A TLV allows extension-capable ISs to recognize all 178 LSPs of an Originating System, and combine the original and extended 179 LSPs for the purpose of SPF computation. It identifies the Normal 180 system-id of the Originating System. 182 The proposed IS Alias ID TLV is type 24, and its format is as 183 follows: 185 x CODE - 24. 187 x LENGTH - total length of the value field. 189 x VALUE - 191 No. of Octets 192 +-------------------+ 193 | Normal system-id | 6 194 +-------------------+ 195 | Pseudonode number | 1 196 +-------------------+ 197 | Sub-TLVs length | 1 198 +-------------------+ 199 | | 0-247 200 : Sub-TLVs : 201 : : 202 | | 203 +-------------------+ 205 Normal system-id 206 The Normal system-id of the LSP set, as described in section 1.2 of 207 this document. 209 Pseudonode number 210 The Pseudonode number of the LSP set. LSPs with the same Normal 211 system-id and Pseudonode number are considered in SPF as one 212 logical LSP, as described in section 5 of this document. 214 Sub-Tlvs length 215 Total length of all sub-TLVs. 217 Sub-TLVs 218 A series of tuples with the following format: 220 No. of Octets 221 +-------------------+ 222 | Sub-type | 1 223 +-------------------+ 224 | Length | 1 225 +-------------------+ 226 | | 0-245 227 : Value : 228 : : 229 | | 230 +-------------------+ 232 Sub-type 233 Type of the sub-TLV 235 Length 236 Total length of the value field 238 Value 239 Type-specific TLV payload. 241 For an explanation on sub-TLV handling, see [ISIS-TE]. 243 Without sub-TLVs, this structure consumes 8 octets per LSP set. This 244 TLV MUST be included in fragment 0 of every LSP set belonging to an 245 Originating System running in either Mode 1 or Mode 2. Currently, 246 there are no sub-TLVs defined. 248 For a complete list of used IS-IS TLV numbers, see [ISIS-CODES]. 250 3.0 Generating LSPs 252 3.1 Both Operation Modes 254 Under both modes, the Originating System MUST include information 255 binding the Original LSP and the Extended ones. It can do this since 256 it is trivially an extension-capable IS. This is to ensure other 257 extension-capable routers correctly process the extra information in 258 their SPF calculation. This binding is advertised via a new IS Alias 259 ID TLV, which is advertised in all fragment 0 of Original and 260 Extended LSPs. 262 +---------------------------------------------+ 263 | Originating System | 264 | system-id = S | 265 | is-alias-id = S | 266 +---------------------------------------------+ 268 +-------------------+ +-------------------+ 269 | Virtual System | | Virtual System | 270 | system-id = S' | | system-id = S''| 271 | is-alias-id = S | | is-alias-id = S | 272 +-------------------+ +-------------------+ 274 Figure 1. Advertising binding between all of a system's LSPs (both 275 modes). S' and S'' are configured as Additional system-ids. 277 When new extended LSP fragments are generated, these fragments should 278 be generated as specified in ISO 10589 [ISIS-ISO]. Furthermore, a 279 system SHOULD treat its extended LSPs the same as it treats its 280 original LSPs, with the exceptions noted in the following sections. 281 Specifically, creating, flooding, renewing, purging and all other 282 operations are similar for both Original and Extended LSPs, unless 283 stated otherwise. The Extended LSPs will use one of the Additional 284 system-ids configured for the router, in their LSP ID. 286 Extended LSPs fragment zero should be regarded in the same special 287 manner as specified in 10589 for LSPs with number zero, and should 288 include the same type of extra information as specified in 10589 and 289 RFC 1195 [ISIS-IP]. So, for example, when a system reissues its LSP 290 fragemnt zero due to an area address change, it should reissue all 291 extended LSPs fragment zero as well. 293 An extended LSP fragment zero MUST be generated for every extended 294 LSP set, to allow a router's SPF calculation to consider those 295 fragments in that set. See section 5 for details. 297 3.1.1 The Attached Bits 299 The Attached (ATT) bits SHOULD be set to zero for all four metric 300 types, on all Extended LSPs. This is due to the following: if a 301 Virtual System is reachable, so is its Originating System. It is 302 preferable, then, that an L1 IS chooses the Originating System and 303 not the Virtual System as its nearest L2 exit point, as connectivity 304 to the Virtual System has a higher probability of being lost (as a 305 result of the extended LSP no longer being advertised). This could 306 cause unnecessary computations on some implementations. 308 3.1.2 The Partition Repair Bit 310 The Partition Repair (P) bit SHOULD be set to zero on all extended 311 LSPs. This is for the same reasons as for the Attached bits. 313 3.1.3 ES Neighbors TLV 315 ISO 10589 [ISIS-ISO] section 7.3.7 specifies inserting an ES Neighbor 316 TLV in L1 LSPs, with the system ID of the router. RFC 1195 [ISIS-IP] 317 relieves IP-only routers of this requirement. However, for routers 318 that do insert this ESN TLV in L1 LSPs (whether IP-only or OSI- 319 capable), then in an extended LSP, the ESN TLV should include the 320 relevant Additional system-id. Furthermore, OSI-capable routers 321 should accept packets destined for this Additional system-id. 323 3.1.4 Overload Bit 325 The overload bit should be set consistently across all LSPs, original 326 and extended, belonging to an Originating System, and should reflect 327 the Originating System's overload state. 329 3.1.5 Other Fields and TLVs 331 Other fields and TLVs not mentioned above remain the same, both for 332 original and extended LSPs. 334 3.2 Operation Mode 1 Additions 336 The following additions apply only to routers generating LSPs in Mode 337 1. Routers, which are configured to operate in Operation Mode 2, 338 SHOULD NOT apply these additions to their advertisements. 340 Under Operation Mode 1, adjacencies from the Originating System to 341 its Virtual Systems are advertised using the standard neighbor TLVs. 342 The metric for these connections MUST be zero, since the cost of 343 reaching a Virtual System is the same as the cost of reaching its 344 Originating System. 346 To older implementations, Virtual Systems would appear reachable only 347 through their Originating System, hence loss of connectivity to the 348 Originating System means loss of connectivity to all of its 349 information, including that advertised in its extended LSPs. 350 Furthermore, the cost of reaching information advertised in non- 351 extended LSPs is the same as the cost of reaching information 352 advertised in the new extended LSPs, with an additional hop. 354 +---------------------------------------------+ 355 | Originating System | 356 | system-id = S | 357 | is-alias-id = S | 358 +---------------------------------------------+ 359 | /\ | /\ 360 cost=0 | |cost=max-1 cost=0 | |cost=max-1 361 | | | | 362 \/ | \/ | 363 +-------------------+ +-------------------+ 364 | Virtual System | | Virtual System | 365 | system-id = S' | | system-id = S''| 366 | is-alias-id = S | | is-alias-id = S | 367 +-------------------+ +-------------------+ 369 Figure 2. Advertising connections to Virtual Systems under Operation 370 Mode 1. S' and S'' are configured as Additional system-ids. 372 Under Operation Mode 1, only "leaf" information, i.e. information 373 that serves only as leaves in a shortest path tree, can be advertised 374 in extended LSPs. 376 When an Extended LSP belonging to Additional system-id S' is first 377 created, the Original LSP MUST specify S' as a neighbor, with metric 378 set to zero. This in order to consider the cost of reaching the 379 Virtual System S' the same as the cost of reaching its Originating 380 System. Furthermore, the Extended LSP MUST specify the Normal 381 system-id as a neighbor. The metric SHOULD be set to MaxLinkMetric - 382 1 (this is only for uniformity purpose, any metric greater than zero 383 is ok). This in order to satisfy the two-way connectivity check on 384 other routers. Where relevant, this adjacency SHOULD be considered 385 as point-to-point. 387 Note, that the restriction specified in ISO 10589 section 7.2.5 388 holds: if an LSP Number zero of the Originating System is not 389 present, none of that system's neighbor entries would be processed 390 during SPF, hence none of its extended LSPs would be processed as 391 well. 393 3.2.1 IS Neighbors TLV (Mode 1 Only) 395 An Extended LSP must specify only the Originating System as a 396 neighbor, with the metric set to (MaxLinkMetric - 1). Where 397 relevant, this adjacency should be considered as point-to-point. 398 Other neighbors MUST NOT be specified in an Extended LSP, because 399 those other neighbors would only specify the Originating System and 400 not the Virtual System, and hence would not satisfy the bi- 401 directionality check in the SPF computation. 403 3.2.2 Originating System in the Overload State in (Mode 1 Only) 405 If the Originating System is in the overload state, information in 406 the extended LSPs will not be processed by other routers in their SPF 407 computation. This is because in Mode 1, extended LSPs are reachable 408 only through adjacencies from the Original LSP. If this LSP has set 409 its OL bit, adjacencies will not be processed in the SPF computation. 411 This side effect should be taken into consideration when operating in 412 Mode 1. 414 4. Purging Extended LSP Fragments 416 ISO 10589 [ISIS-ISO] section 7.3.4.4 note 21 suggests that an 417 implementation keeps the number of LSP fragments within a certain 418 limit based on the optimal (minimal) number of fragments needed. 419 Section 7.3.4.6 also recommends that an IS purge its empty LSPs to 420 conserve resources. These recommendations hold for the extended LSP 421 fragments as well. However, an extended LSP fragment zero should not 422 be purged until all of the fragments in its set (i.e. belonging to a 423 particular Additional system-id), are empty as well. This is to 424 ensure implementations consider the fragments in their SPF 425 computations, as specified in section 7.2.5. 427 In Operational Mode 1, when all the extended LSP fragments of a 428 particular Additional system-id S' have been purged, the Originating 429 System SHOULD remove the neighbor information to S' from its original 430 LSPs. 432 5. Modifications to LSP handling in SPF 434 This section describes modifications to the way extension-capable ISs 435 handle LSPs for the SPF computation. 437 When considering LSPs of an extension-capable IS (identified by the 438 inclusion of the IS Alias ID TLV), the original and extended LSPs are 439 combined to form one large logical LSP. If the LSP belongs to an IS 440 running Operational Mode 1, there might be adjacencies between the 441 original and extended LSPs. These are trivially ignored (since when 442 processing them the large logical LSP is already on PATHS), and 443 doesn't complicate the SPF. Furthermore, this check should already 444 be implemented (this scenario could occur on error, without this 445 extension). 447 If LSP fragment 0 of the Original LSP set is missing or its 448 RemainingLifetime is zero, all of the LSPs generated by that 449 Originating System (Extended as well) MUST NOT be considered in the 450 SPF. That is, the large logical LSP isn't considered in the SPF. 451 The original LSP fragments are identified when the is-alias-id value 452 is the same as the system-id of those LSPs. If an LSP fragment 0 of 453 an extended LSP set is missing or its RemainingLifetime is zero, only 454 that LSP set MUST NOT be considered in the SPF. These rules are 455 present to ensure consistent SPF results on Mode 1 and Mode 2 LSPs. 457 Note, that the above behavior is consistent with how previous 458 implementations will interpret Mode 1 LSPs. 460 6. Forming Adjacencies 462 It should be noted, that an IS MUST use the system-id of the LSP that 463 will include a neighbor, when forming an adjacency with that 464 neighbor. That is, if a neighbor is to be included in extended LSP 465 S', then S' should be used as the system-id in IS Hellos [3] and IS- 466 IS Hellos when forming an adjacency with that neighbor. This is 467 regardless of the Operational Mode. Of course, in Mode 1 this means 468 that only the Normal system-id will be used when sending hellos. 470 7. Interoperating between extension-capable and non-extension-capable 471 ISs. 473 In order to correctly advertise link-state information under 474 Operation Mode 2, all ISs in an area must be extension-capable. 475 However, it is possible to not upgrade every router in the network, 476 if the extended information is not routing information, but rather 477 data that is of use to only a subset of routers (e.g. optical 478 switches using ISIS could carry optical-specific information in 479 extended LSPs) 481 If a live network contains routers exceeding the 256 fragment limit, 482 and for some reason the upgrade has to be done incrementally, it is 483 possible to transition the network, using the following steps: 484 - Upgrade the routers, one-by-one, to run this extension in 485 Operation Mode 1. The other non-extension-capable routers will 486 interoperate correctly. 487 - When all routers are extension-capable, configure them one-by-one 488 to run in Operation Mode 2. All extension-capable routers 489 interoperate correctly, regardless of what mode they're run in. 491 Implementations SHOULD support a configuration parameter controlling 492 the LSP origination behavior. The default value of this parameter 493 SHOULD correspond to the behavior described in [ISIS-ISO], i.e. 494 neither of the two modes described in this document should be enabled 495 without explicit configuration when the router software is upgraded 496 with this extension. 498 8. Security Considerations 500 This document raises no new security issues for IS-IS. 502 9. Acknowledgments 504 The authors would like to thank Tony Li and Radia Perlman for helpful 505 comments and suggestions on the subject. 507 10. References 509 10.1 Normative References 511 [ISIS-ISO] ISO 10589, "Intermediate System to Intermediate System 512 Intra-Domain Routeing Exchange Protocol for use in Conjunction with 513 the Protocol for Providing the Connectionless-mode Network Service 514 (ISO 8473)" 516 [ISIS-IP] RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and dual 517 environments", R.W. Callon, Dec. 1990 519 [ISIS-TE] Work in progress, "IS-IS extensions for Traffic 520 Engineering", T. Li, H. Smit 522 [BCP14] RFC 2119, "Key words for use in RFCs to Indicate Requirement 523 Levels", S. Bradner, March 1997 525 10.2 Informative References 527 [DOMAIN-WIDE] RFC 2966, "Domain-wide Prefix Distribution with Two- 528 Level IS-IS", T. Li, T. Przygienda, H. Smit, October 2000 530 [ISIS-CODES] Work in progress, "Reserved TLV Codepoints in ISIS", T. 531 Przygienda 533 11. Authors' Addresses 535 Amir Hermelin Email: amir@cwnt.com 536 Charlotte's Web Networks, Inc. Phone: +972 4 9592203 537 2 Ha'mada St. Fax: +972 4 9593325 538 POB 650 539 Yokneam, 20692 540 ISRAEL 542 Mike Shand, Email: mshand@cisco.com 543 Cisco Systems, Phone: +44 020 8824 8690 544 4, The Square, 545 Stockley Park, 546 UXBRIDGE, 547 Middlesex, 548 UB11 1BN, 549 UK 551 Stefano Previdi email: sprevidi@cisco.com 552 Cisco Systems, Inc. Phone: +32 2 7046590 553 De Kleetlaan 6A 554 1831 Diegem 555 Belgium