idnits 2.17.1 draft-ietf-isis-wg-extlsp-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([IS-IS], [RFC3786]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- 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.) -- The document date (December 22, 2008) is 5597 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. 'IS-IS' -- Obsolete informational reference (is this intentional?): RFC 3786 (Obsoleted by RFC 5311) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Danny McPherson (Ed.) 2 Arbor Networks 3 Les Ginsberg 4 Stefano Previdi 5 Mike Shand 6 Cisco Systems 7 Expires: June 2009 December 22, 2008 8 Intended Status: Proposed Standard 9 Obseletes: 3786 11 Simplified Extension of LSP Space for IS-IS 12 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 Copyright Notice 37 Copyright (c) 2008 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. 47 Abstract 49 This draft describes a simplified method for extending the LSP space 50 beyond the 256 Link State PDU (LSP) limit defined in [IS-IS]. This 51 method is intended as a preferred replacement for the method defined 52 in [RFC 3786]. 54 Table of Contents 56 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Specification of Requirements. . . . . . . . . . . . . . . . . 4 58 3. Definition of Commonly Used Terms. . . . . . . . . . . . . . . 4 59 4. Utilizing Additional System IDs. . . . . . . . . . . . . . . . 5 60 4.1. Additional Information in Extended LSPs . . . . . . . . . . 6 61 4.2. Extended LSP Restrictions . . . . . . . . . . . . . . . . . 6 62 4.2.1. TLVs Which MUST NOT Appear . . . . . . . . . . . . . . . 6 63 4.2.2. Leaf Advertisements in Extended LSPs . . . . . . . . . . 6 64 4.2.3. IS Neigbor Advertisement Restrictions. . . . . . . . . . 7 65 4.2.4. Area Adresses. . . . . . . . . . . . . . . . . . . . . . 8 66 4.2.5. Overload, Attached, Partition Repair Bits. . . . . . . . 8 67 4.3. Originating LSP Requirements. . . . . . . . . . . . . . . . 8 68 4.4. IS Alias ID TLV (IS Alias ID) . . . . . . . . . . . . . . . 9 69 4.5. New TLVs in Support of IS Neighbor 70 Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 5. Comparison with the RFC 3786 Solution. . . . . . . . . . . . . 10 72 6. Deployment Considerations. . . . . . . . . . . . . . . . . . . 11 73 6.1. Advertising New TLVs in Extended LSPs . . . . . . . . . . . 11 74 6.2. Reachability and non-SPF TLV Staleness. . . . . . . . . . . 11 75 6.3. Normal LSP OL State and Use of Extended LSPs. . . . . . . . 12 76 6.4. Moving Neighbor Attribute INFO LSPs . . . . . . . . . . . . 12 77 6.5. Advertising Leaf INFO Extended LSPs . . . . . . . . . . . . 13 78 7. Security Considerations. . . . . . . . . . . . . . . . . . . . 13 79 8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 13 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 9.1. Normative References. . . . . . . . . . . . . . . . . . . . 14 82 9.2. Informative References. . . . . . . . . . . . . . . . . . . 14 83 10. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 14 85 1. Overview 87 [IS-IS] defines the set of LSP which may be originated by a system at 88 each level. This set is limited to 256 fragments. [IS-IS] also 89 defines a maximum value for an LSP fragment 90 (originatingLxLSPBufferSize) as 1492 bytes. The carrying capacity of 91 an LSP set, while bounded, has thus far been sufficient for 92 advertisements associated with an area/domain in existing deployment 93 scenarios. However, the definition of additional information to be 94 included in LSPs (e.g. multitopology support, traffic engineering 95 information, router capabilities, etc.) has the potential to exceed 96 the carrying capacity of an LSP set. 98 This issue first drew interest when traffic engineering extensions 99 were introduced. This interest resulted in the solution defined in 100 RFC 3786. However, that solution suffers from restrictions required 101 to maintain interoperability with systems which do not support the 102 extensions. 104 This document defines extensions which allow a system to exceed the 105 256 LSP limit and do so in a way which has no interoperability issues 106 with systems which do not support the extension. It is seen as a 107 simpler and therefore preferred solution to the problem. 109 2. Specification of Requirements 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC 2119 [BCP 14]. 115 3. Definition of Commonly Used Terms 117 This section provides definitions for terms that are used throughout 118 the text. The terminology is consistent with that used in RFC 3786. 120 Originating System: A physical IS running the IS-IS protocol. As 121 this document describes a method which allows a single physical IS to 122 originate LSPs on behalf of multiple virtual ISs, the Originating 123 System represents the single physical IS. 125 Normal system-id: The system-id of an Originating System as defined 126 by [IS-IS]. 128 Additional system-id: A system-id other than the "Normal system-id" 129 that is assigned by the network administrator to an Originating 130 System in order to allow the generation of extended LSPs. The 131 Additional system-id, like the Normal system-id, must be unique 132 throughout the routing area (Level-1) or domain (Level-2). 134 Original LSP: An LSP using the Normal system-id in its LSP ID. 136 Extended LSP: An LSP using an Additional system-id in its LSP ID. 138 LSP set: All LSPs of a given level having the same system ID and 139 Pseudonode ID. (The LSPID field then only varies in the LSP number 140 octet.) This constitutes the complete set of link state information 141 at a given level originated using that system ID/Pseudonode ID. This 142 term is defined to resolve the ambiguity between a logical LSP and a 143 single Link State PDU - which is sometimes called an LSP fragment. 144 The latter is the unit of information handled by the update process. 146 Extended LSP set: An LSP set consisting of LSPs using an Additional 147 system-id. 149 Extension-capable IS: An IS implementing the mechanisms described in 150 this document. 152 Virtual IS: The system, identified by an Additional system-id, 153 advertised as originating the extended LSPs. These LSPs specify the 154 Additional system-id in their LSP IDs. 156 4. Utilizing Additional System IDs 158 This extension allows an Originating System to be assigned additional 159 system-ids which may be used to generate additional LSP sets. The 160 additional system-ids are subject to the same restrictions as normal 161 system-ids i.e. when used at Level-1 the additional system-id MUST be 162 unique within the Level-1 area. When used at Level-2 the additional 163 system-id MUST be unique within the domain. 165 Extended LSPs are treated by the IS-IS Update Process in the same 166 manner as normal LSPs i.e. the same rules as to generation, flooding, 167 purging, etc. apply. In particular, if the Extended LSP with LSP 168 Number zero and remaining lifetime > 0 is not present for a 169 particular additional system-id then none of the extended LSPs in 170 that Extended LSP set shall be processed. 172 4.1. Additional Information in Extended LSPs 174 The LSP number zero of an Extended LSP Set MUST include the new IS 175 alias ID TLV defined in Section 4.4. This allows the Extended LSP set 176 to be associated with the Originating System which generated the 177 LSP(s). 179 4.2. Extended LSP Restrictions 181 The following restrictions on the information which may appear in an 182 Extended LSP are defined in order to avoid interoperability issues 183 with systems which do not support the extensions defined in this 184 document. All TLV references are based on the current definitions in 185 the IANA IS-IS TLV Codepoints Registry. 187 4.2.1. TLVs Which MUST NOT Appear 189 The following TLVs MUST NOT appear in an Extended LSP: 191 TLV Name (#) 192 ----------- 193 ES Neighbors (3) 194 Part. DIS (4) 195 Prefix Neighbors (5) 197 If any of the TLVs listed above appear in an Extended LSP, an 198 Extension Capable IS MUST ignore those TLVs on receipt and SHOULD 199 report an error. Other TLVs in that extended LSP set MUST be 200 processed normally. 202 4.2.2. Leaf Advertisements in Extended LSPs 204 Advertisement of leaf information in Extended LSPs is allowed. 205 Inclusion of such information requires the advertisement of a 206 neighbor between the Originating System and the Virutal IS associated 207 with the extended LSP set in which the leaf advertisements appear. 208 See section 4.2.3. 210 When leaf advertisements for multiple topologies (see [M-IS-IS]) are 211 included in an Extended LSP set, the multi-topology TLV (229) MUST 212 include all topologies for which a leaf advertisement is included. 214 The following TLVs fall into this category: 216 TLV Name (#) 217 ----------- 218 IP Int. Reach (128) 219 IP Ext. Address (130) 220 The extended IP reachability TLV (135) 221 MT IP Reach (235) 222 IPv6 IP Reach (236) 223 MT IPv6 IP Reach (237) 225 4.2.3. IS Neigbor Advertisement Restrictions 227 Advertisement of IS Neighbor Reachability in an Extended LSP is 228 restricted to advertisement of neighbor reachability to the 229 Originating System. A neighbor to the Originating System MUST be 230 advertised in Extended LSPs. If multi-topology capability [M-IS-IS] 231 is supported, an MT IS Neighbor advertisement to the Originating 232 System IS MUST be included for every topology advertised in the 233 Extended LSP set. Neighbor advertisement(s) to the Originating System 234 in an Extended LSP MUST use a non-zero metric and SHOULD use a metric 235 of MaxLinkMetric-1. 237 The restrictions defined here apply to all TLVs used to advertise 238 neighbor reachability. These include the following TLVs: 240 TLV Name (#) 241 ----------- 242 IS Neighbors (2) 243 The extended IS reachability TLV (22) 244 MT-ISN (222) 246 4.2.4. Area Adresses 248 LSP number zero of an Extended LSP set MUST include an Area Address 249 TLV. The set of area addresses advertised MUST be a subset of the 250 set of Area Addresses advertised in the normal LSP number zero at the 251 corresponding level. Preferably the advertisement SHOULD be 252 syntactically identical to that included in the normal LSP number 253 zero at the corresponding level. 255 4.2.5. Overload, Attached, Partition Repair Bits 257 The Overload (OL), Attached (ATT), and Partition Repair (P) bits MUST 258 be set to 0 in all Extended LSPs. 260 Note that ISs NOT supporting these extensions will interpret these 261 bits normally in Extended LSPs they receive. If the ATT bit were set 262 in an Extended LSP this could indicate that the Virtual IS is 263 attached to other areas when the Originating System is not. This 264 might cause legacy systems to use the Virtual IS as a default exit 265 point from the area. 267 4.3. Originating LSP Requirements 269 The Original LSP set MUST include a neighbor to the Virtual IS 270 associated with each Extended LSP set generated. If multi-topology 271 capability [M-IS-IS] is supported, an MT IS Neighbor advertisement to 272 the Virtual IS MUST be included for every topology advertised in the 273 Extended LSP set. The neighbor advertisement(s) in the Original LSP 274 MUST specify a metric of zero. This guarantees that the two way 275 connectivity check between Originating System and Virtual IS will 276 succeed and that the cost of reaching the Virtual IS is the same as 277 the cost to reach the Originating System. 279 4.4. IS Alias ID TLV (IS Alias ID) 281 The IS-Alias TLV allows extension-capable ISs to recognize the 282 Originating System of an Extended LSP set. It identifies the Normal 283 system-id of the Originating System. 285 Type 24 286 Length # of octets in the value field (7 to 255) 287 Value 289 No. of octets 290 +-----------------------+ 291 | Normal System-id | 6 292 +-----------------------+ 293 | Sub-TLV length | 1 294 +-----------------------+ 295 | Sub-TLVs (optional) | 0 to 248 296 +-----------------------+ 298 Normal system-id 300 The Normal system-id of the Originating System 302 Sub-TLVs length 304 Total length of all sub-TLVs. 306 Sub-TLVs 308 No subTLVs are defined in this document. Should future extensions 309 define subTLVs, the subTLVs MUST be formatted as described in [RFC 310 5305]. 312 4.5. New TLVs in Support of IS Neighbor Attributes 314 One of the major sources of additional information in LSPs is the 315 subTLV information associated with the extended IS reachability TLV 316 (22) and MT IS Neighbor TLV (222). This includes (but is not limited 317 to) information required in support of Traffic Engineering (TE) as 318 defined in [RFC 5305] and [RFC 5307]. The restrictions defined in 319 this document prohibit the presence of TLV 22 and/or TLV 222 in 320 Extended LSPs except to advertise the neighbor relationship to the 321 Originating System. In the event that there is a need to advertise in 322 Extended LSPs such information associated with neighbors of the 323 Originating System, it is necessary to define new TLVs to carry the 324 subTLV information. 326 Two new TLVs are therefore defined. 328 1) IS Neighbor Attribute TLV (23). It is identical in format to the 329 Extended IS Reachability TLV (22). 331 2) MT IS Neighbor Attribute TLV (223). It is identical in format to 332 the MT IS Neighbor TLV (222). 334 These new TLVs MAY be included in Original LSPs or Extended LSPs. 335 Regardless of the type of LSP in which the TLVs appear, the 336 information pertains to the neighbor relationship between the 337 Originating System and the IS identified in the TLV. 339 These TLVs MUST NOT be used to infer that a neighbor relationship 340 exists in the absence of TLV 22 or TLV 222 (whichever applies) in the 341 Originating LSP set for the specified neighbor. This restriction is 342 necessary in order to maintain compatibility with systems which do 343 not support these extensions. 345 5. Comparison with the RFC 3786 Solution 347 This document utilizes the same basic mechanism (additional system- 348 ids) as RFC 3786 to allow an originating system to generate more than 349 256 LSPs. It differs from RFC 3786 in that it restricts the content 350 of Extended LSPs to information which does NOT impact the building 351 of a Shortest Path Tree (SPT). 353 Legacy IS-IS implementations which do not support the extensions 354 defined in this document see the extended LSPs as information 355 associated with a system which is reachable only via the Originating 356 System. As no other systems are reachable via the Virtual ISs, the 357 SPF calculation in legacy ISs is therefore consistent with that 358 performed by extension capable ISs. There is therefore no need for 359 the two different operating modes defined in RFC 3786. 361 There is also no need for the special handling of the original LSP 362 set and the extended LSP set(s) as a single Logical LSP during the 363 SPF as specified in Section 5 of RFC 3786. 365 6. Deployment Considerations 367 There are a number of deployment considerations which limit the 368 usefulness of extended LSPs unless all systems are extension-capable 369 ISs. 371 6.1. Advertising New TLVs in Extended LSPs 373 As extended LSPs MAY be utilized to advertise TLVs associated with 374 other protocol extensions (definition of which is outside the scope 375 of this document) and/or the extensions defined in Section 4.4 of 376 this document, it is obvious that the utilization of the information 377 in extended LSPs by legacy IS-IS implementations will be limited. 378 The implication of this is that as implementations are revised to 379 support the protocol extensions which define new TLVs/subTLVs that 380 MAY be advertised in extended LSPs, the implementation SHOULD also be 381 revised to support the extensions defined in this document so that it 382 is capable of processing the new information whether it appears in 383 normal or extended LSPs. 385 6.2. Reachability and non-SPF TLV Staleness 387 In cases where non-SPF information is advertised in LSPs, it is 388 necessary to determine whether the system which originated the 389 advertisement is reachable in order to guarantee that a receiving IS 390 does not use or leak stale information. As long as the OL bit is NOT 391 set by the Originating System in normal LSPs, reachability to the 392 Virtual IS will be consistent with reachability to the Originating 393 System. Therefore, no special rules are required in this case. 395 6.3. Normal LSP OL State and Use of Extended LSPs 397 If the Originating System sets the OL bit in a normal LSP, legacy 398 systems will see the Virtual ISs associated with that Originating 399 System as unreachable and therefore will not use the information in 400 the corresponding Extended LSPs. Under these circumstances, Extension 401 capable ISs MUST also see the Virtual ISs as unreachable. This 402 avoids potential routing loops in cases where leaf information is 403 advertised in Extended LSPs. 405 6.4. Moving Neighbor Attribute INFO LSPs 407 Section 4.4 defines new TLVs which MAY be used to advertise neighbor 408 attribute information in extended LSPs. In cases where neighbor 409 attribute information associated with the same context (e.g. the same 410 link) appears in both an Original LSP and in one or more Extended LSP 411 Sets, the following rules apply for each attribute: 413 o If the attribute information does not conflict, it MUST be 414 considered additive 416 o If the attribute information conflicts, then the information in 417 the Original LSP, if present, MUST be used. If no information is 418 in the Original LSP, then the information from the Extended LSP 419 with the lowest system-id SHALL be preferred. 421 o In cases where information about the same neighbor/link/attribute 422 appears in both TLV 22 and TLV 23 (or TLV 222 and TLV 223 for the 423 same MTID) then the information in TLV 22 (or TLV 222) MUST be 424 used and the information in TLV 23 (or TLV 223) MUST be ignored. 426 Utilization of the new TLVs for neighbor attribute information would 427 provide additional benefits which include: 429 o Elimination of the need for redundant IS neighbor TLVs to be 430 processed as part of the SPF. 432 o Easier support for a set of TE information associated with a 433 single link which exceeds the 255 byte TLV limit by allowing the 434 interpretation of multiple TLVs to be considered additive rather 435 than mutually exclusive. 437 6.5. Advertising Leaf INFO Extended LSPs 439 The need to advertise leaf information in Extended LSPs may arise 440 because of extensive leaking of inter-level information or because of 441 the support of multiple topologies as described in [M-IS-IS]. When 442 leaf information is advertised in Extended LSPs, these LSPs now 443 contain information which MUST be processed in order to correctly 444 update the forwarding plane of an IS. This may increase the frequency 445 of events which trigger forwarding plane updates by ISs in the 446 network. It is therefore recommended that, when possible, leaf 447 information be restricted to the normal LSP set. 449 7. Security Considerations 451 This document raises no new security issues for IS-IS. 453 8. IANA Considerations 455 This document defines the following new ISIS TLVs that need to be 456 reflected in the ISIS TLV code-point registry: 458 Type Description IIH LSP SNP 459 ---- ----------------------------------- --- --- --- 460 23 IS Neighbor Attribute n y n 461 24 IS Alias ID n y n 462 223 MT IS Neighbor Attribute n y n 464 9. References 466 9.1. Normative References 468 [IS-IS] ISO, "Intermediate system to Intermediate system routeing 469 information exchange protocol for use in conjunction with the 470 Protocol for providing the Connectionless-mode Network Service (ISO 471 8473)," ISO/IEC 10589:2002, Second Edition. 473 [RFC 5305] Smit, H. and T. Li, "IS-IS Extensions for Traffic 474 Engineering", RFC 5305, October 2008. 476 [RFC 5307] Kompella, K. and Rehkter, Y., "IS-IS Extensions in Support 477 of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, 478 October 2008. 480 [BCP 14] Bradner, S., "Key words for use in RFCs to Indicate 481 Requirement Levels", BCP 14, RFC 2119, March 1997 483 9.2. Informative References 485 [RFC 3786] Hermelin, A., Previdi, S. and Shand, M., "Extending the 486 Number of Intermediate to Intermediate (IS-IS) Link State PDU (LSP) 487 Fragments Beyond the 256 Limit," RFC 3786, May 2004. 489 [M-IS-IS] Pryzgienda, T., Shen, N., and Sheth, N., "Multi Topology 490 (MT) Routing in IS-IS", RC 5120, February 2008. 492 10. Authors' Addresses 493 Les Ginsberg 494 Cisco Systems 495 Email: ginsberg@cisco.com 497 Stefano Previdi 498 Cisco Systems 499 Email: sprevidi@cisco.com 501 Mike Shand 502 Cisco Systems 503 Email: mshand@cisco.com 505 Danny McPherson 506 Arbor Networks, Inc. 507 Email: danny@arbor.net 509 Acknowledgment 511 Funding for the RFC Editor function is provided by the IETF 512 Administrative Support Activity (IASA).