idnits 2.17.1 draft-ietf-isis-wg-multi-topology-06.txt: ** The Status of Memo section seems to be numbered ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == 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 Introduction section. ** 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.) ** There are 8 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 4 instances of lines with control characters in the document. 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.) -- The document date (March 2003) is 7712 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) == Unused Reference: 'ISO10589' is defined on line 490, but no explicit reference was found in the text == Unused Reference: 'RFC1195' is defined on line 495, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' == Outdated reference: A later version (-05) exists of draft-ietf-isis-traffic-04 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-traffic (ref. 'LS01') == Outdated reference: A later version (-07) exists of draft-ietf-isis-ipv6-05 Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Tony Przygienda (Xebeo) 2 Internet Draft Naiming Shen (Redback) 3 Nischal Sheth (Juniper) 4 March 2003 5 Expires: September 2003 7 M-ISIS: Multi Topology (MT) Routing in IS-IS 9 1. Status of This Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at 19 any time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 2. Abstract 30 This draft describes an optional mechanism within ISIS used today 31 by many ISPs for IGP routing within their clouds. This draft 32 describes how to run within a single ISIS domain a set of 33 independent IP topologies that we call Multi-Topologies (MTs). 34 This MT extension can be used for variety of purposes such as an 35 in-band management network ``on top'' of the original IGP topology, 36 maintain separate IGP routing domains for isolated multicast or 37 IPv6 islands within the backbone, or force a subset of an address 38 space to follow a different topology. 40 3. Specification of Requirements 42 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 43 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 44 document are to be interpreted as described in RFC 2119 [RFC2119]. 46 4. Introduction 48 Maintaining multiple MTs for ISIS [ISO10589 , RFC1195] in a 49 backwards-compatible manner necessitates several extensions to the 50 packet encoding and additional SPF procedures. The problem can 51 be partitioned into forming of adjacencies, and advertising of 52 prefixes and reachable intermediate systems within each topology. 53 Having put all the necessary additional information in place, it 54 must be properly used by MT capable SPF computation. The following 55 sections describe each of the problems separately. To simplify the 56 text, ``standard'' ISIS topology is defined to be MT ID #0 (zero). 58 5. Maintaining MT Adjacencies 60 Each adjacency formed MUST be classified as belonging to a set of 61 MTs on the interface. This is achieved by adding a new TLV into 62 IIH packets that advertises which topologies the interface belongs 63 to. If MT #0 is the only MT on the interface, it is optional to 64 advertise it in the new TLV. Thus not including such a TLV in the 65 IIH implies MT ID #0 capability only. Through this exchange of MT 66 capabilities, a router is able to advertise the IS TLVs in LSPs 67 with common MT set over those adjacencies. 69 As a simplifying side-effect, boundaries between levels will be the 70 same for all MTs. 72 In the case of adjacency contains multiple MTs on an interface, and 73 if there exists overlapping IP address space among the topologies, 74 additional mechanism MAY be used to resolve the topology identity of 75 the incoming IP packets on the interface. 77 5.1. Forming Adjacencies on Point-to-Point Interfaces 79 Adjacencies on point-to-point interfaces are formed as usual with 80 ISIS routers not implementing MT extensions. If local router does 81 not participate in certain MTs, it will not advertise those MTIDs 82 in it's IIHs and thus will not include that neighbor within it's 83 topology based LSPs. On the other hand, if a MTID is not 84 detected in remote side's IIHs, the local router MUST NOT include 85 that neighbor within it's MT LSPs. The local router SHOULD NOT form 86 adjacency if they don't have at least one common MT set over the 87 interface. 89 5.2. Forming Adjacencies on Broadcast Interfaces 91 On a LAN, all the routers on the LAN which implement the MT 92 extension MAY advertise their MT capability TLV in their IIHs. 93 If there is at least one adjacency on the LAN interface which 94 belongs to this MT, the MT capable router MUST include according 95 MT IS Reachable TLV in its LSP, otherwise it MAY include this MT 96 IS Reachable TLV in it's LSP if the LAN interface participates in 97 this MT set. 99 Two Routers on a LAN SHALL always establish adjacency regardless 100 whether they have common MT set or not. This is to ensure all 101 the routers on the LAN can correctly elect the same DIS. The IS 102 SHOULD NOT include the MT IS TLV in its LSP if none of the 103 adjacencies on the LAN contains this MT. 105 The DIS, CSNP and PSNP functions are not changed by MT extension. 107 6. Advertising MT Reachable Intermediate Systems in LSPs 109 A router MUST include within its LSPs in the Reachable Intermediate 110 Systems TLVs only adjacent nodes that are participating in the 111 according topology and advertise such TLVs only if it participates 112 itself in the according topology. Standard Reachable Intermediate 113 Systems TLV is acting here as MT ID #0 equivalent of the newly 114 introduced MT Reachable Intermediate Systems TLV. A router MUST 115 announce the MT IS TLV when there is at least one adjacency on the 116 interface that belongs to this MT, otherwise it MAY announce the MT 117 IS TLV of an adjacency for a given MT if this interface participates 118 in the LAN. 120 Since it is not possible to prevent a router that does not understand 121 MT extensions from being responsible for generation of the according 122 pseudo-node, it is not possible either to introduce special TLVs in 123 the pseudo-node LSPs nor run distinct DIS elections per MT. 124 Therefore, a generated pseudo-node LSP by DIS MUST contain in its 125 IS Reachable TLV all nodes on the LAN as usual regardless of their 126 MT capabilities. In other words, there is no change to the 127 pseudo-node LSP construction. 129 7. MTs and Overload, Partition and Attached Bits 131 As stated earlier, all MTs share the same set of L1-L2 boundaries 132 and NETs. However, a router could for each of the MTs become 133 potentially partitioned, overloaded and attached independently. 134 To prevent unnecessary complexity, MT extensions does not support 135 partition repair. The overload, partition and attached bits in LSP 136 header only reflect the status of the default topology. 138 Attached bit and overload bit are part of the MT TLV being 139 distributed within a node's LSP fragment zero. Since each adjacency 140 can belong to different MTs, it is possible that some MTs are L2 141 attached, and others are not on the same router. The overload 142 bit in the MT TLV can be used to signal the topology being 143 overloaded. A MT based system is considered being overloaded if 144 the overload bit in the MT is set. 146 Route leaking between the levels SHOULD only be performed within 147 the same MT. 149 8. Advertising MT Specific IP Prefixes 151 Each of the MTs commands its own address space so a new TLV is 152 necessary for prefixes stored in MTs other than MT ID #0. To 153 make the encoding less confusing when same prefixes are present in 154 multiple MTs and accelerate SPF per MT, rather than adding a sub-TLV 155 in TE extensions, a new TLV is introduced for that purpose that 156 closely follows TE encoding [LS01]. 158 9. MT SPF Computation 160 Each MT MUST run its own instance of the decision process. 161 The LSP overload bit and pseudo-node LSPs are used by all 162 topologies during computation. Each topology MAY have it's 163 attached bit and overload bit set in the MT TLV. Reverse 164 connectivity check within SPF MUST follow the according MT to 165 assure the bi-directional reachability within the same MT. 167 The results of each computation SHOULD be stored in a separate RIB 168 in normal cases, otherwise overlapping addresses in different 169 topologies could lead to undesirable routing behavior such as 170 forwarding loops. The forwarding logic and configuration need to 171 ensure the same MT is traversed from the source to the destination 172 for packets. The nexthops derived from the MT SPF MUST belong to 173 the adjacencies conforming to the same MT for correct forwarding. 174 It is recommended for the administrators to ensure consistent 175 configuration of all routers in the domain to prevent undesirable 176 forwarding behavior. 178 10. LSP Flooding 180 An implementation MAY have the option to use additional MT 181 information in the LSP and on the adjacency to reduce some of the 182 unnecessary LSP flooding over the point-to-point links. If a 183 receiving interface and an outgoing interface don't share any 184 common MT set, the implementation MAY have the option not to flood 185 this LSP out on that interface. Since the fragment zero LSP 186 contains the MTID, the MT capability of any LSP can be identified. 187 If the LSP and the adjacencies of an outgoing interface do not 188 share any common MT capability, the implementation MAY have the 189 option not to flood this LSP out on that interface. An 190 implementation MAY want to have the operators to control those 191 optimization base on network topology and environment to ensure 192 the LSP flooding reliability. 194 When there is an adjacency MT set change over an point-to-point 195 link and the adjacency is in UP state, both sides SHOULD force an 196 exchange of one set of CSNPs over that link. 198 11. Packet Encoding 200 Three new TLVs are added to support MT extensions. One of them is 201 common for the LSPs and IIHs. Encoding of Intermediate System TLV 202 and IPv4 Reachable Prefixes is tied to traffic engineering 203 extensions [LS01] to simplify the implementation effort. The main 204 reasons we choose using new TLVs instead of using sub-TLVs inside 205 existing TLV type-22 and type-135 are: In many cases, 206 multi-topologies are non-congruent, using sub-TLV approach will 207 not save LSP space; Many sub-TLVs are already being used in TLV 208 type-22, and many more are being proposed while there is a maximum 209 limit on the TLV size, from the existing TLVs; If traffic 210 engineering or some other applications are being applied per 211 topology level later, the new TLVs can automatically inherit the 212 same attributes already defined for the ``standard'' IPv4 topology 213 without going through long standard process to redefine them per 214 topology. 216 11.1. Multi-Topology TLV 218 TLV number of this TLV is 229. It contains one or more MTs 219 the router is participating in the following structure: 221 x CODE - 229 222 x LENGTH - total length of the value field, it should be 2 223 times the number of MT components. 224 x VALUE - one or more 2-byte MT components, structured 225 as follows: 226 No. of Octets 227 +--------------------------------+ 228 |O |A |R |R | MT ID | 2 229 +--------------------------------+ 231 Bit O represents the OVERLOAD bit for the MT (only valid 232 in LSP fragment zero for MTs other than ID #0, otherwise 233 should be set to 0 on transmission and ignored on receipt.) 235 Bit A represents the ATTACH bit for the MT (only valid 236 in LSP fragment zero for MTs other than ID #0, otherwise 237 should be set to 0 on transmission and ignored on receipt.) 239 Bits R are reserved, should be set to 0 on transmission 240 and ignored on receipt. 242 MT ID is a 12-bit field containing the ID of the topology 243 being announced. 245 This MT TLV can advertise up to 127 MTs and it can occur multiple 246 times if needed within IIHs and LSP fragment zero. The result MT 247 set should be the union of all the MT TLV occurrence in the packet. 248 Any other ISIS PDU occurrence of this TLV MUST be ignored. Lack 249 of MT TLV in hellos and fragment zero LSP MUST be interpreted as 250 participation of the advertising interface or router in 251 MT ID #0 only. If a router advertises MT TLV, it has to advertise 252 all the MTs it participates in, specifically including topology 253 ID #0 also. 255 11.2. MT Intermediate Systems TLV 257 TLV number of this TLV is 222. It is aligned with extended IS 258 reachability TLV type 22 beside an additional two bytes in front at 259 the beginning of the TLV. 261 x CODE - 222 262 x LENGTH - total length of the value field 263 x VALUE - 2-byte MT membership plus the format of extended IS 264 reachability TLV, structured as follows: 266 No. of Octets 267 +--------------------------------+ 268 |R |R |R |R | MT ID | 2 269 +--------------------------------+ 270 | extended IS TLV format | 11 - 253 271 +--------------------------------+ 272 . . 273 . . 274 +--------------------------------+ 275 | extended IS TLV format | 11 - 253 276 +--------------------------------+ 278 Bits R are reserved, should be set to 0 on transmission 279 and ignored on receipt. 281 MT ID is a 12-bit field containing the non-zero MT ID of the 282 topology being announced. The TLV MUST be ignored if the ID 283 is zero. This is to ensure the consistent view of the standard 284 unicast topology. 286 After the 2-byte MT membership format, the MT IS content is 287 in the same format as extended IS TLV, type 22 [LS01]. It 288 can contain up to 23 neighbors of the same MT if no sub-TLVs 289 are used. 291 This TLV can occur multiple times. 293 11.3. Multi-Topology Reachable IPv4 Prefixes TLV 295 TLV number of this TLV is 235. It is aligned with extended IS 296 reachability TLV type 135 beside an additional two bytes in front. 298 x CODE - 235 299 x LENGTH - total length of the value field 300 x VALUE - 2-byte MT membership plus the format of extended 301 extended IP reachability TLV, structured as follows: 303 No. of Octets 304 +--------------------------------+ 305 |R |R |R |R | MT ID | 2 306 +--------------------------------+ 307 | extended IP TLV format | 5 - 253 308 +--------------------------------+ 309 . . 310 . . 311 +--------------------------------+ 312 | extended IP TLV format | 5 - 253 313 +--------------------------------+ 315 Bits R are reserved, should be set to 0 on transmission 316 and ignored on receipt. 318 MT ID is a 12-bit field containing the non-zero ID of the 319 topology being announced. The TLV MUST be ignored if the ID 320 is zero. This is to ensure the consistent view of the standard 321 unicast topology. 323 After the 2-byte MT membership format, the MT IPv4 content 324 is in the same format as extended IP reachability TLV, 325 type 135 [LS01]. 327 This TLV can occur multiple times. 329 No attempt is made in this draft to let the M-ISIS IPv6 topology to 330 understand the "normal" IPv6 prefix with TLV type 236. A network 331 SHOULD only run IS-IS either with IPv6 using type 236 or with M-ISIS 332 IPv6 using type 237. 334 11.4. Multi-Topology Reachable IPv6 Prefixes TLV 336 TLV number of this TLV is 237. It is aligned with IPv6 Reachability 337 TLV type 236 beside an additional two bytes in front. 339 x CODE - 237 340 x LENGTH - total length of the value field 341 x VALUE - 2-byte MT membership plus the format of IPv6 342 Reachability TLV, structured as follows: 344 No. of Octets 345 +--------------------------------+ 346 |R |R |R |R | MT ID | 2 347 +--------------------------------+ 348 | IPv6 Reachability format | 6 - 253 349 +--------------------------------+ 350 . . 351 . . 352 +--------------------------------+ 353 | IPv6 Reachability format | 6 - 253 354 +--------------------------------+ 356 Bits R are reserved, should be set to 0 on transmission 357 and ignored on receipt. 359 MT ID is a 12-bit field containing the ID of the topology 360 being announced. 362 After the 2-byte MT membership format, the MT IPv6 context 363 is in the same format as IPv6 Reachability TLV, 364 type 236 [H01]. 366 This TLV can occur multiple times. 368 11.5. Reserved MT ID Values 370 Certain MT topologies are assigned to serve pre-determined purposes: 372 - MT ID #0: Equivalent to the ``standard'' topology. 373 - MT ID #1: Reserved for IPv4 in-band management purposes. 374 - MT ID #2: Reserved for IPv6 routing topology. 375 - MT ID #3: Reserved for IPv4 multicast routing topology. 376 - MT ID #4: Reserved for IPv6 multicast routing topology. 377 - MT ID #5-#3995: Reserved for IETF consensus. 378 - MT ID #3996-#4095: Reserved for development, experimental and 379 proprietary features. 381 12. MT IP Forwarding Considerations 383 Using MT extension for ISIS routing can result in multiple RIBs 384 on the system. The implementation and configuration MUST make 385 sure the IP packets are only traversed through the nodes and links 386 intended for the topologies and applications. In this section we 387 list some of the known considerations for IP forwarding in various 388 MT scenario. Certain deployment scenarios presented here 389 imply different trade-offs in terms of deployment difficulties 390 and advantages obtained. 392 12.1. Each MT belong to a distinct address family 394 In this case, each MT related routes are installed into a 395 separate RIB. Multiple topologies can share the same ISIS interface 396 on detecting the incoming packet address family. As an example, 397 IPv4 and IPv6 can share the same interface without any further 398 considerations under MT ISIS. 400 12.2. Some MTs belong to the same address family 402 12.2.1. Each interface belongs to one and only one MT 404 In this case, MTs can be used to forward packets from the 405 same address family, even with overlapping addresses. Since the 406 MTs have their dedicated interfaces, and those interfaces can be 407 associated with certain MT RIBs and FIBs. 409 12.2.2. Multiple MTs share an interface with overlapping addresses 411 Some additional mechanism is needed to select the correct RIBs 412 for the incoming IP packets to determine the correct RIB to make 413 a forwarding decision. For example, if the topologies are 414 QoS partitioned, then the DSCP bits in the IP packet header can 415 be utilized to make the decision. Some IP header or even packet 416 data information may be checked to make the forwarding table 417 selection, such as source IP address in the header can be used 418 to determine the desired forwarding behavior. 420 The generic approach of packet to multiple MT RIB mapping over 421 the same inbound interface is outside the scope of this draft. 423 12.2.3. Multiple MTs share an interface with non-overlapping addresses 425 When there is no overlap in the address space among all the MTs, 426 strictly speaking the destination address space classifies the 427 topology a packet belongs to. It is possible to install routes 428 from different MTs into a shared RIB. As an example of such a 429 deployment, a special ISIS topology can be setup for certain 430 EBGP nexthop addresses. 432 12.3 Some MTs are not used for forwarding purpose 434 MT in ISIS may be used even if the resulting RIB is not used for 435 forwarding purposes. As an example, multicast RPF check can be 436 performed on a different RIB than the standard unicast RIB albeit 437 an entirely different RIB is used for the multicast forwarding. 438 However, an incoming packet must be still clearly identified as 439 belonging to a unique topology. 441 13. MT Network Management Considerations 443 When multiple ISIS topologies exist within a domain, some of the 444 routers can be configured to participate in a subset of the MTs 445 in the network. This section discusses some of the options we 446 have to enable operations or the network management stations to 447 access those routers. 449 13.1. Create dedicated management topology to include all the nodes 451 This approach is to setup a dedicated management topology or 452 'in-band' management topology. This 'mgmt' topology will include 453 all the routers need to be managed. The computed routes in the 454 topology will be installed into the 'mgmt' RIB. In the condition 455 of the 'mgmt' topology uses a set of non-overlapping address space 456 with the default topology, those 'mgmt' routes can also be 457 optionally installed into the default RIB. 458 The advantages of duplicate 'mgmt' routes in both RIBs include: 459 the network management utilities on the system does not have to be 460 modified to use specific RIB other than the default RIB; the 'mgmt' 461 topology can share the same link with the default topology if so 462 designed. 464 13.2. Extend the default topology to all the nodes 466 Even in the case default topology is not used on some of the nodes 467 in the IP forwarding, we may want to extend the default topology 468 to those nodes for the purpose of network management. Operators 469 SHOULD set high cost on the links which belong to the extended 470 portion of the default topology. This way the IP data traffic 471 will not be forwarded through those nodes during network topology 472 changes. 474 14. Acknowledgments 476 The authors would like to thank Andrew Partan, Dino Farinacci, 477 Derek Yeung, Alex Zinin, Stefano Previdi, Heidi Ou, Steve Luong, 478 and Mike Shand for the discussion, their review, comments and 479 contributions to this draft. 481 15. Security Consideration 483 ISIS security applies to the work presented. No specific security 484 issues with the proposed solutions are known. The authentication 485 procedure for ISIS PDUs is the same regardless of MT information 486 inside the ISIS PDUs. 488 16. Normative References 490 [ISO10589] ISO. Intermediate System to Intermediate System Routing 491 Exchange Protocol for Use in Conjunction with the Protocol 492 for Providing the Connectionless-Mode Network Service. 493 ISO 10589, 1992. 495 [RFC1195] R. Callon. Use of OSI ISIS for Routing in TCP/IP and 496 Dual Environments. RFC 1195, December 1990. 498 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 499 Requirement Levels", BCP 14, RFC 2119, March 1997. 501 [LS01] T. Li and H. Smit. IS-IS Extensions for Traffic 502 Engineering. draft-ietf-isis-traffic-04.txt, August 2001 503 (work in progress) 505 [H01] C. Hopps. Routing IPv6 with IS-IS. 506 draft-ietf-isis-ipv6-05.txt, January 2003 507 (work in progress) 509 17. Authors' Addresses 511 Tony Przygienda 512 Xebeo 513 One Cragwood Road 514 South Plainfield, NJ 07080 515 Phone: (908) 222 4225 516 prz@xebeo.com 518 Naiming Shen 519 Redback Networks 520 350 Holger Way 521 San Jose, CA, 95134 USA 522 naiming@redback.com 524 Nischal Sheth 525 Juniper Networks 526 1194 North Mathilda Avenue 527 Sunnyvale, CA 94089 USA 528 nsheth@juniper.net