idnits 2.17.1 draft-ietf-isis-mi-03.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, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, 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 (July 12, 2010) is 5030 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) -- Obsolete informational reference (is this intentional?): RFC 3567 (ref. 'HMAC-MD5') (Obsoleted by RFC 5304) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Previdi 3 Internet-Draft L. Ginsberg 4 Intended status: Standards Track M. Shand 5 Expires: January 12, 2011 A. Roy 6 Cisco Systems 7 D. Ward 8 Juniper Networks 9 July 12, 2010 11 IS-IS Multi-Instance 12 draft-ietf-isis-mi-03 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. This document may contain material 18 from IETF Documents or IETF Contributions published or made publicly 19 available before November 10, 2008. The person(s) controlling the 20 copyright in some of this material may not have granted the IETF 21 Trust the right to allow modifications of such material outside the 22 IETF Standards Process. Without obtaining an adequate license from 23 the person(s) controlling the copyright in such materials, this 24 document may not be modified outside the IETF Standards Process, and 25 derivative works of it may not be created outside the IETF Standards 26 Process, except to format it for publication as an RFC or to 27 translate it into languages other than English. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on January 12, 2011. 47 Copyright Notice 49 Copyright (c) 2010 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Abstract 64 This draft describes a mechanism that allows a single router to share 65 one or more links among multiple IS-IS routing protocol instances. 67 Multiple instances allow the isolation of resources associated with 68 each instance. Routers will form instance specific adjacencies, 69 exchange instance specific routing updates and compute paths 70 utilizing instance specific LSDB information. Each PDU will contain 71 a new TLV identifying the instance to which the PDU belongs. This 72 allows a network operator to deploy multiple IS-IS instances in 73 parallel, using the same set of links when required and still have 74 the capability of computing instance specific paths. This draft does 75 not address the forwarding paradigm that needs to be used in order to 76 ensure data PDUs are forwarded according to the paths computed by a 77 specific instance. 79 Requirements Language 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in RFC 2119 [RFC2119]. 85 Table of Contents 87 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 88 2. Elements Of Procedure . . . . . . . . . . . . . . . . . . . . . 4 89 2.1. Instance Identifier . . . . . . . . . . . . . . . . . . . . 5 90 2.2. Instance Membership . . . . . . . . . . . . . . . . . . . . 5 91 2.3. Adjacency Establishment . . . . . . . . . . . . . . . . . . 6 92 2.3.1. Point-to-Point Adjacencies . . . . . . . . . . . . . . 6 93 2.3.2. Multi-Access Adjacencies . . . . . . . . . . . . . . . 6 94 2.4. Interoperability Considerations . . . . . . . . . . . . . . 6 95 2.4.1. Interoperability Issues on Broadcast Networks . . . . . 7 96 2.4.2. Interoperability using p2p networks . . . . . . . . . . 7 97 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 98 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 99 5. Informational References . . . . . . . . . . . . . . . . . . . 8 100 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 101 7. Normative References . . . . . . . . . . . . . . . . . . . . . 8 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 104 1. Introduction 106 An existing limitation of the protocol defined by [IS-IS] is that 107 only one instance of the protocol can operate on a given link. This 108 document defines an extension to IS-IS to remove this restriction. 109 The extension is referred to as "multi-instance IS-IS" (MI-IS-IS). 111 Routers which support this extension are referred to as "multi- 112 instance capable routers" (MI-RTR). 114 The use of multiple instances enhances the ability to isolate the 115 resources associated with a given instance both within a router and 116 across the network. Instance specific prioritization for processing 117 PDUs and performing routing calculations within a router may be 118 specified. Instance specific flooding parameters may also be defined 119 so as to allow different instances to consume network wide resources 120 at different rates. 122 MI-IS-IS might be used to support IS-IS for multiple topologies. 123 When used for this purpose it is an alternative to [MT-IS-IS]. 125 MI-IS-IS might also be used to support an instance which advertises 126 information on behalf of applications. The advertisement of 127 information not directly related to the operation of the IS-IS 128 protocol can therefore be done in a manner which minimizes its impact 129 on the operation of routing. 131 The above are examples of how MI-IS-IS might be used. The 132 specification of uses of MI-IS-IS is outside the scope of this 133 document. 135 2. Elements Of Procedure 137 The protocol extension uses a new TLV called the Instance Identifier 138 (IID) that is included in each IS-IS PDU originated by an MI-RTR. 139 MI-RTRs form instance specific adjacencies and exchange instance 140 specific routing updates only for the instance IDs which are 141 supported both by the MI-RTR and its neighbor. 143 This also implies an instance specific flooding scheme, instance 144 specific LSDBs and instance specific routing calculations. It MAY 145 also imply instance specific routing and forwarding tables. However, 146 this aspect is outside the scope of this specification. When 147 multiple instances share the same link each instance will have a 148 separate set of adjacencies. Each IS-IS PDU is associated with only 149 one IS-IS instance. 151 The mechanisms used to implement support for the separation of IS-IS 152 instances within a router are outside the scope of this 153 specification. 155 2.1. Instance Identifier 157 A new TLV is defined in order to convey an instance identifier (IID). 158 The purpose of the IID is to identify the PDUs associated with each 159 IS-IS instance using a unique 16-bit number. The IID TLV is carried 160 in all IS-IS PDUs (IIHs, SNPs and LSPs) originated by the router. 162 Multiple instances of IS-IS may co-exist on the same network and on 163 the same physical router. IIDs MUST be unique within the same 164 routing domain. 166 Instance identifier #0 is reserved for the standard instance 167 supported by legacy systems. 169 The following format is used for the IID: 171 Type: 7 172 Length: 2 173 Value: Instance Identifier (0 to 65535) 175 When an LSP purge is initiated, the Instance Identifier TLV, if 176 present, MUST be retained but the remainder of the body of the LSP 177 SHOULD be removed. 179 2.2. Instance Membership 181 Each router is configured to be participating in one or more 182 instances of IS-IS. For each instance in which it participates, a 183 router marks all IS-IS PDUs (IIHs, LSPs or SNPs) generated pertaining 184 to that instance by including the IID TLV with the appropriate 185 instance identifier. Note that this applies to the standard instance 186 (instance identifier #0). A PDU MUST NOT be generated with multiple 187 IID TLVs. PDUs received with multiple IID TLVs MUST be ignored. A 188 PDU without an IID TLV is assumed to belong to the standard instance 189 (#0). 191 2.3. Use of Authentication 193 When authentication is in use, the Instance Identifier TLV, if 194 present, is first used to select the authentication configuration 195 which is applicable. The authentication check is then performed as 196 normal. 198 2.4. Adjacency Establishment 200 In order to establish adjacencies, IS-IS routers exchange IIH PDUs. 201 Two types of adjacencies exist in IS-IS: point-to-point and 202 broadcast. The following sub-sections describe the additional rules 203 an MI-RTR MUST follow when establishing adjacencies. 205 2.4.1. Point-to-Point Adjacencies 207 MI-RTRs include the IID TLV in the p2p hello PDUs they originate. 208 Upon reception of an IIH, an MI-RTR inspects the received IID TLV and 209 if it matches any of the IIDs which the router supports on that link, 210 normal adjacency establishment procedures are used to establish an 211 instance specific adjacency. Note that the absence of the IID TLV 212 implies instance ID #0. 214 This extension allows an MI-RTR to establish multiple adjacencies to 215 the same physical neighbor over a p2p link. However, as the 216 instances are logically independent, the normal expectation of at 217 most one neighbor on a given p2p link still applies. 219 2.4.2. Multi-Access Adjacencies 221 Multi-Access (broadcast) networks behave differently than p2p in that 222 PDUs sent by one router are visible to all routers and all routers 223 must agree on the election of a DIS. 225 MI-RTRs will establish adjacencies and elect a DIS per IS-IS 226 instance. Each MI-RTR will form adjacencies only with routers which 227 advertise support for the instances which the local router has been 228 configured to support on that link. Since an MI-RTR is not required 229 to support all possible instances on a LAN, it's possible to elect a 230 different DIS for different instances. 232 2.5. Interoperability Considerations 234 [IS-IS] requires that any TLV that is not understood is silently 235 ignored without compromising the processing of the whole IS-IS PDU 236 (IIH, LSP, SNP). 238 To a router not implementing this extension, all IS-IS PDUs received 239 will appear to be associated with the standard instance regardless of 240 whether an IID TLV is present in those PDUs. This can cause 241 interoperability issues unless the mechanisms and procedures 242 discussed below are followed. 244 2.5.1. Interoperability Issues on Broadcast Networks 246 In order for routers to correctly interoperate with routers not 247 implementing this extension and in order not to cause disruption, a 248 specific and dedicated MAC address is used for multicasting IS-IS 249 PDUs with any non-zero IID. Each level will use a specific layer 2 250 multicast address. Such an address allows MI-RTRs to exchange IS-IS 251 PDUs with non-zero IIDs without these PDUs being processed by legacy 252 routers and therefore no disruption is caused. 254 An MI-RTR will use the AllL1IS and AllL2IS ISIS mac layer addresses 255 (as defined in [IS-IS]) when sending ISIS PDUs for the standard 256 instance (IID #0). An MI-RTR will use two new (TBD) dedicated layer 257 2 multicast addresses (one for each level) when sending IS-IS PDUs 258 for any non-zero IID. 260 MI-RTRs MUST discard IS-IS PDUs received if either of the following 261 is true: 263 o The destination multicast address is AllL1IS or AllL2IS and the 264 PDU contains an IID TLV with non-zero value 265 o The destination multicast address is one of the two new addresses 266 and the PDU contains an IID TLV with a zero value or has no IID 267 TLV. 268 NOTE: If the multicast addresses AllL1IS and/or AllL2IS are 269 improperly used to send IS-IS PDUs for non-zero IIDs, legacy systems 270 will interpret these PDUs as being associated with IID #0. This will 271 cause inconsistencies in the LSDB in those routers, may incorrectly 272 maintain adjacencies, and may lead to inconsistent DIS election. 274 2.5.2. Interoperability using p2p networks 276 In order for an MI-RTR to interoperate over a p2p link with a router 277 which does NOT support this extension, the MI-RTR MUST NOT send IS- 278 IS PDUs for instances other than IID #0 over the p2p link as these 279 PDUs may affect the state of IID #0 in the neighbor. 281 The presence/absence of the IID TLV in an IIH indicates that the 282 neighbor does/does not support this extension. Once it is determined 283 that the neighbor does not support this extension, an MI-RTR MUST NOT 284 send PDUs (including IIHs) for instances other than IID #0. 286 Until an IIH is received from a neighbor, an MI-RTR MAY send IIHs for 287 a non-zero instance. However, once an IIH with no IID TLV has been 288 received - indicating that the neighbor is not an MI-RTR - the MI-RTR 289 MUST NOT send IIHs for a non-zero instance. The temporary relaxation 290 of the restriction on sending IIHs for non-zero instances allows a 291 non-zero instance adjacency to be established on an interface on 292 which an MI-RTR does NOT support instance #0. 294 3. IANA Considerations 296 This document requires the definition a new ISIS TLV that needs to be 297 reflected in the ISIS TLV code-point registry: 299 Type Description IIH LSP SNP 300 ---- ----------------------------------- --- --- --- 301 TBA MI IID y y y 303 4. Security Considerations 305 Security concerns for IS-IS are addressed in the IS-IS specification 306 [IS-IS], and accompanying specifications on [HMAC-MD5]. No 307 additional considerations need to be made for the extension. 309 5. Informational References 311 [IS-IS] ISO, "Intermediate system to Intermediate system routeing 312 information exchange protocol for use in conjunction with the 313 Protocol for providing the Connectionless-mode Network Service (ISO 314 8473)," ISO/IEC 10589:2002, Second Edition. 316 [HMAC-MD5] Li, T. and R. Atkinson, "Intermediate System to 317 Intermediate System (IS-IS) Cryptographic Authentication", RFC 3567, 318 July 2003. 320 [MT-IS-IS] Pryzgienda, T., Shen, N., and Sheth, N., "Multi Topology 321 (MT) Routing in IS-IS", RFC5120, February 2008. 323 6. Acknowledgements 325 The authors would like to acknowledge contributions made by Dino 326 Farinacci and Tony Li. 328 7. Normative References 330 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 331 Requirement Levels", BCP 14, RFC 2119, March 1997. 333 Authors' Addresses 335 Stefano Previdi 336 Cisco Systems 337 Via Del Serafico 200 338 Roma, RM 00142 339 Italy 341 Email: sprevidi@cisco.com 343 Les Ginsberg 344 Cisco Systems 345 510 McCarthy Blvd. 346 Milpitas, CA 95035 347 USA 349 Email: ginsberg@cisco.com 351 Mike Shand 352 Cisco Systems 353 250 Longwater Avenue 354 Reading, Berkshire RG2 6GB 355 UK 357 Email: mshand@cisco.com 359 Dave Ward 360 Juniper Networks 361 1194 N. Mathilda Ave. 362 Sunnyvale, California 94089-1206 USA 364 Email: dward@juniper.net 366 Abhay Roy 367 Cisco Systems 368 170 W. Tasman Dr. 369 San Jose, CA 95134 370 USA 372 Email: akr@cisco.com