idnits 2.17.1 draft-previdi-isis-mi-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 369. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 395. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 402. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 408. 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 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 (May 2007) is 6183 days in the past. Is this intentional? Checking references for intended status: Full Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'BCP9' is defined on line 290, but no explicit reference was found in the text == Unused Reference: 'BCP26' is defined on line 296, but no explicit reference was found in the text == Unused Reference: 'BCP79' is defined on line 300, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' == Outdated reference: A later version (-12) exists of draft-ietf-isis-wg-multi-topology-11 ** Downref: Normative reference to an Proposed Standard draft: draft-ietf-isis-wg-multi-topology (ref. 'MT-IS-IS') ** Obsolete normative reference: RFC 2434 (ref. 'BCP26') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3979 (ref. 'BCP79') (Obsoleted by RFC 8179) -- Obsolete informational reference (is this intentional?): RFC 3567 (ref. 'HMAC-MD5') (Obsoleted by RFC 5304) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Previdi 2 Internet Draft L. Ginsberg 3 Intended Status: Standard M. Shand 4 Expiration Date: Nov 2007 A. Roy 5 D. Ward 6 Cisco Systems 7 May 2007 9 IS-IS Multi-instance 10 draft-previdi-isis-mi-00.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of 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 25 months and may be updated, replaced, or obsoleted by other documents 26 at any 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/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 Abstract 37 This draft describes a mechanism that allows a single router to 38 share one or more links among multiple IS-IS routing protocol 39 instances. 41 Multiple instances allow the isolation of resources associated with 42 each instance. Routers will form instance specific adjacencies, 43 exchange instance specific routing updates and compute paths 44 utilizing instance specific LSDB information. Each PDU will contain 45 a new TLV identifying the instance to which the PDU belongs. This 46 allows a network operator to deploy multiple IS-IS instances in 47 parallel, using the same set of links when required and still have 48 the capability of computing instance specific paths. This draft does 49 not address the forwarding paradigm that needs to be used in order 50 to ensure data PDUs are forwarded according to the paths computed by 51 a specific instance. 53 Table of Contents 55 1. Conventions used in this document..............................2 56 2. Introduction...................................................2 57 3. Elements Of Procedure..........................................3 58 3.1 Instance Identifier..........................................3 59 3.2 Instance Membership..........................................4 60 3.3 Adjacency Establishment......................................4 61 3.3.1 Point-to-Point Adjacencies................................4 62 3.3.2 Multi-Access Adjacencies..................................5 63 3.4 Interoperability Considerations..............................5 64 3.4.1 Interoperability Issues on Broadcast Networks.............5 65 3.4.2 Interoperability using p2p networks.......................6 66 4. Security Considerations........................................6 67 5. IANA Considerations............................................6 68 6. References.....................................................7 69 6.1 Normative References.........................................7 70 6.2 Informational References.....................................7 71 7. Acknowledgments................................................7 72 8. Authors' Addresses.............................................7 73 9. Full Copyright Statement.......................................8 75 1. Conventions used in this document 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in RFC-2119 [BCP14]. 81 2. Introduction 83 An existing limitation of the protocol defined by [IS-IS] is that 84 only one instance of the protocol can operate on a given link. This 85 document defines an extension to IS-IS to remove this restriction. 86 The extension is referred to as "multi-instance IS-IS" (MI-IS-IS). 88 Routers which support this extension are referred to as "multi- 89 instance capable routers" (MI-RTR). 91 The use of multiple instances enhances the ability to isolate the 92 resources associated with a given instance both within a router and 93 across the network. Instance specific prioritization for processing 94 PDUs and performing routing calculations within a router may be 95 specified. Instance specific flooding parameters may also be defined 96 so as to allow different instances to consume network wide resources 97 at different rates. 99 MI-IS-IS might be used to support IS-IS for multiple topologies. 100 When used for this purpose it is an alternative to [MT-IS-IS]. 102 MI-IS-IS might also be used to support an instance which advertises 103 information on behalf of applications. The advertisement of 104 information not directly related to the operation of the IS-IS 105 protocol can therefore be done in a manner which minimizes its 106 impact on the operation of routing. 108 The above are examples of how MI-IS-IS might be used. The 109 specification of uses of MI-IS-IS is outside the scope of this 110 document. 112 3. Elements Of Procedure 114 The protocol extension uses a new TLV called the Instance Identifier 115 (IID) that is included in each IS-IS PDU originated by an MI-RTR. 116 MI-RTRs form instance specific adjacencies and exchange instance 117 specific routing updates only for the instance IDs which are 118 supported both by the MI-RTR and its neighbor. 120 This also implies an instance specific flooding scheme, instance 121 specific LSDBs and instance specific routing calculations. It MAY 122 also imply instance specific routing and forwarding tables. However, 123 this aspect is outside the scope of this specification. When 124 multiple instances share the same link each instance will have a 125 separate set of adjacencies. Each IS-IS PDU is associated with only 126 one IS-IS instance. 128 The mechanisms used to implement support for the separation of IS-IS 129 instances within a router are outside the scope of this 130 specification. 132 3.1 Instance Identifier 134 A new TLV is defined in order to convey an instance identifier 135 (IID). The purpose of the IID is to identify the PDUs associated 136 with each IS-IS instance by a unique 16-bit number. The IID TLV is 137 carried in all IS-IS PDUs (IIH, SNP, LSP) originated by the router. 139 Multiple instances of IS-IS may co-exist on the same network and on 140 the same physical router. IIDs MUST be unique within the same 141 routing domain. 143 Instance identifier #0 is reserved for the standard instance 144 supported by legacy systems. 146 The following format is used for the IID: 148 Type 7 (TBA by IANA) 149 Length 2 150 Value Instance Identifier (0 to 65535) 152 3.2 Instance Membership 154 Each router is configured to be participating in one or more 155 instances of IS-IS. For each instance in which it participates, a 156 router marks all IS-IS PDUs (IIH, LSP or SNP) generated pertaining 157 to that instance by including the IID TLV with the appropriate 158 instance identifier. Note that this applies to the standard instance 159 (instance identifier #0). A PDU MUST NOT be generated with multiple 160 IID TLVs. PDUs received with multiple IID TLVs MUST be ignored. A 161 PDU without an IID TLV is assumed to belong to the standard instance 162 (#0). 164 3.3 Adjacency Establishment 166 In order to establish adjacencies, IS-IS routers exchange IIH PDUs. 167 Two types of adjacencies exist in IS-IS: point-to-point and 168 broadcast. The following sub-sections describe the additional rules 169 an MI-RTR MUST follow when establishing adjacencies. 171 3.3.1 Point-to-Point Adjacencies 173 MI-RTRs include the IID TLV in the p2p hello PDUs they originate. 174 Upon reception of an IIH, an MI-RTR inspects the received IID TLV 175 and if it matches any of the IIDs which the router supports on that 176 link, normal adjacency establishment procedures are used to 177 establish an instance specific adjacency. Note that the absence of 178 the IID TLV implies instance ID #0. 180 This extension allows an MI-RTR to establish multiple adjacencies to 181 the same physical neighbor over a p2p link. However, as the 182 instances are logically independent, the normal expectation of at 183 most one neighbor on a given p2p link still applies. 185 3.3.2 Multi-Access Adjacencies 187 Multi-Access (broadcast) networks behave differently than p2p in 188 that PDUs sent by one router are visible to all routers and all 189 routers must agree on the election of a DIS. 191 MI-RTRs will establish adjacencies and elect a DIS per IS-IS 192 instance. Each MI-RTR will form adjacencies only with routers which 193 advertise support for the instances which the local router has been 194 configured to support on that link. Since an MI-RTR is not required 195 to support all possible instances on a LAN, it's possible to elect a 196 different DIS for different instances. 198 3.4 Interoperability Considerations 200 [IS-IS] requires that any TLV that is not understood is silently 201 ignored without compromising the processing of the whole IS-IS PDU 202 (IIH, LSP, SNP). 204 To a router not implementing this extension, all IS-IS PDUs received 205 will appear to be associated with the standard instance regardless 206 of whether an IID TLV is present in those PDUs. This can cause 207 interoperability issues unless the mechanisms and procedures 208 discussed below are followed. 210 3.4.1 Interoperability Issues on Broadcast Networks 212 In order for routers to correctly interoperate with routers not 213 implementing this extension and in order not to cause disruption, a 214 specific and dedicated MAC address is used for multicasting IS-IS 215 PDUs with any non-zero IID. Each level will use a specific layer 2 216 multicast address. Such an address allows MI-RTRs to exchange IS-IS 217 PDUs with non-zero IIDs without these PDUs being processed by legacy 218 routers and therefore no disruption is caused. 220 An MI-RTR will use the AllL1IS and AllL2IS ISIS mac layer addresses 221 (as defined in [IS-IS]) when sending ISIS PDUs for the standard 222 instance (IID #0). An MI-RTR will use two new (TBD) dedicated layer 223 2 multicast addresses (one for each level) when sending IS-IS PDUs 224 for any non-zero IID. 226 MI-RTRs MUST discard IS-IS PDUs received if either of the following 227 is true: 229 . The destination multicast address is AllL1IS or AllL2IS and the 230 PDU contains an IID TLV with non-zero value. 232 . The destination multicast address is one of the two new 233 addresses and the PDU contains an IID TLV with a zero value or 234 has no IID TLV. 236 NOTE: If the multicast addresses AllL1IS and/or AllL2IS are 237 improperly used to send IS-IS PDUs for non-zero IIDs, legacy systems 238 will interpret these PDUs as being associated with IID #0. This will 239 cause inconsistencies in the LSDB in those routers, may incorrectly 240 maintain adjacencies, and may lead to inconsistent DIS election. 242 3.4.2 Interoperability using p2p networks 244 In order for an MI-RTR to interoperate over a p2p link with a router 245 which does NOT support this extension, the MI-RTR MUST NOT send IS- 246 IS PDUs for instances other than IID #0 over the p2p link as these 247 PDUs may affect the state of IID #0 in the neighbor. 249 The presence/absence of the IID TLV in an IIH indicates that the 250 neighbor does/does not support this extension. Once it is determined 251 that the neighbor does not support this extension, an MI-RTR MUST 252 NOT send PDUs (including IIHs) for instances other than IID #0. 254 Until an IIH is received from a neighbor, an MI-RTR MAY send IIHs 255 for a non-zero instance. However, once an IIH with no IID TLV has 256 been received - indicating that the neighbor is not an MI-RTR - the 257 MI-RTR MUST NOT send IIHs for a non-zero instance. The temporary 258 relaxation of the restriction on sending IIHs for non-zero instances 259 allows a non-zero instance adjacency to be established on an 260 interface on which an MI-RTR does NOT support instance #0. 262 4. Security Considerations 264 Security concerns for IS-IS are addressed in the IS-IS specification 265 [IS-IS], and accompanying specifications on [HMAC-MD5]. No 266 additional considerations need to be made for the extension. 268 5. IANA Considerations 270 This document requires the definition a new ISIS TLV that needs to 271 be reflected in the ISIS TLV code-point registry: 273 Type Description IIH LSP SNP 274 ---- ----------------------------------- --- --- --- 275 TBA MI-MT IID y y y 277 6. References 279 6.1 Normative References 281 [IS-IS] ISO, "Intermediate system to Intermediate system routeing 282 information exchange protocol for use in conjunction with the 283 Protocol for providing the Connectionless-mode Network Service 284 (ISO 8473)," ISO/IEC 10589:2002, Second Edition. 286 [MT-IS-IS] Pryzgienda, T., Shen, N., and Sheth, N., "Multi 287 Topology (MT) Routing in IS-IS", draft-ietf-isis-wg-multi- 288 topology-11.txt (work in progress), October 2005. 290 [BCP9] Bradner, S., "The Internet Standards Process -- Revision 291 3", BCP 9, RFC 2026, October 1996. 293 [BCP14] Bradner, S., "Key words for use in RFCs to Indicate 294 Requirement Levels", BCP 14, RFC 2119, March 1997 296 [BCP26] Narten, T. and Alvestrand, H., "Guidelines for Writing an 297 IANA Considerations Section in RFCs", BCP 26 , RFC 2434, October 298 1998 300 [BCP79] Bradner, S. Ed., "Intellectual Property Rights in IETF 301 Technology ", BCP 79 , RFC 3979, March 2005 303 6.2 Informational References 305 [HMAC-MD5] Li, T. and R. Atkinson, "Intermediate System to 306 Intermediate System (IS-IS) Cryptographic Authentication", RFC 307 3567, July 2003. 309 [MT-IS-IS] Pryzgienda, T., Shen, N., and Sheth, N., "Multi 310 Topology (MT) Routing in IS-IS", draft-ietf-isis-wg-multi- 311 topology-11.txt (work in progress), October 2005. 313 7. Acknowledgments 315 The authors would like to acknowledge contributions made by Dino 316 Farinacci and Tony Li. 318 8. Authors' Addresses 320 Stefano Previdi 321 CISCO Systems, Inc. 322 Via Del Serafico 200 323 00142 - Roma 324 ITALY 325 Email: sprevidi@cisco.com 327 Les Ginsberg 328 Cisco Systems 329 510 McCarthy Blvd. 330 Milpitas, Ca. 95035 USA 331 Email: ginsberg@cisco.com 333 Abhay Roy 334 Cisco Systems 335 170 W. Tasman Dr. 336 San Jose, CA 95134 USA 337 akr@cisco.com 339 Mike Shand 340 Cisco Systems 341 250 Longwater Avenue, 342 Reading, 343 Berkshire, 344 RG2 6GB 345 UK 346 Email: mshand@cisco.com 348 Dave Ward 349 Cisco Systems 350 170 W. Tasman Dr. 351 San Jose, CA 95134 USA 352 dward@cisco.com 354 9. Full Copyright Statement 356 Copyright (C) The IETF Trust (2007). 358 This document is subject to the rights, licenses and restrictions 359 contained in BCP 78, and except as set forth therein, the authors 360 retain all their rights. 362 This document and the information contained herein are provided on 363 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 364 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 365 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 366 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 367 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 368 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 369 FOR A PARTICULAR PURPOSE. 371 This document and translations of it may be copied and furnished to 372 others, and derivative works that comment on or otherwise explain it 373 or assist in its implementation may be prepared, copied, published 374 and distributed, in whole or in part, without restriction of any 375 kind, provided that the above copyright notice and this paragraph 376 are included on all such copies and derivative works. However, this 377 document itself may not be modified in any way, such as by removing 378 the copyright notice or references to the IETF Trust or other 379 Internet organizations, except as needed for the purpose of 380 developing Internet standards in which case the procedures for 381 copyrights defined in the Internet Standards process must be 382 followed, or as required to translate it into languages other than 383 English. 385 The limited permissions granted above are perpetual and will not be 386 revoked by the IETF Trust or its successors or assigns. 388 The IETF takes no position regarding the validity or scope of any 389 Intellectual Property Rights or other rights that might be claimed 390 to pertain to the implementation or use of the technology described 391 in this document or the extent to which any license under such 392 rights might or might not be available; nor does it represent that 393 it has made any independent effort to identify any such rights. 394 Information on the procedures with respect to rights in RFC 395 documents can be found in BCP 78 and BCP 79. 397 Copies of IPR disclosures made to the IETF Secretariat and any 398 assurances of licenses to be made available, or the result of an 399 attempt made to obtain a general license or permission for the use 400 of such proprietary rights by implementers or users of this 401 specification can be obtained from the IETF on-line IPR repository 402 at http://www.ietf.org/ipr. 404 The IETF invites any interested party to bring to its attention any 405 copyrights, patents or patent applications, or other proprietary 406 rights that may cover technology that may be required to implement 407 this standard. Please address the information to the IETF at ietf- 408 ipr@ietf.org.