idnits 2.17.1 draft-ietf-isis-reverse-metric-08.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 8, 2018) is 2299 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) == Outdated reference: A later version (-07) exists of draft-shen-isis-spine-leaf-ext-03 -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group N. Shen 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track S. Amante 5 Expires: July 12, 2018 Apple, Inc. 6 M. Abrahamsson 7 T-Systems Nordic 8 January 8, 2018 10 IS-IS Routing with Reverse Metric 11 draft-ietf-isis-reverse-metric-08 13 Abstract 15 This document describes the mechanism to allow IS-IS routing to 16 quickly and accurately shift traffic away from either a point-to- 17 point or multi-access LAN interface by signaling to an adjacent IS-IS 18 neighbor with the metric towards itself during network maintenance or 19 other operational events. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on July 12, 2018. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Node and Link Isolation . . . . . . . . . . . . . . . . . 2 57 1.2. Distributed Forwarding Planes . . . . . . . . . . . . . . 3 58 1.3. Spine-Leaf Applications . . . . . . . . . . . . . . . . . 3 59 1.4. LDP IGP Synchronization . . . . . . . . . . . . . . . . . 3 60 1.5. IS-IS Reverse Metric . . . . . . . . . . . . . . . . . . 3 61 1.6. Specification of Requirements . . . . . . . . . . . . . . 4 62 2. IS-IS Reverse Metric TLV . . . . . . . . . . . . . . . . . . 4 63 3. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 6 64 3.1. Processing Changes to Default Metric . . . . . . . . . . 6 65 3.2. Processing Changes to Default Metric for Multi-Topology 66 IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 3.3. Multi-Access LAN Procedures . . . . . . . . . . . . . . . 7 68 3.4. Point-To-Point Link Procedures . . . . . . . . . . . . . 8 69 3.5. LDP/IGP Synchronization on LANs . . . . . . . . . . . . . 8 70 3.6. Operational Guidelines . . . . . . . . . . . . . . . . . 9 71 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 73 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 76 7.2. Informative References . . . . . . . . . . . . . . . . . 11 77 Appendix A. Node Isolation Challenges . . . . . . . . . . . . . 11 78 Appendix B. Link Isolation Challenges . . . . . . . . . . . . . 12 79 Appendix C. Contributors' Addresses . . . . . . . . . . . . . . 13 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 82 1. Introduction 84 The IS-IS [ISO10589] routing protocol has been widely used in 85 Internet Service Provider IP/MPLS networks. Operational experience 86 with the protocol, combined with ever increasing requirements for 87 lossless operations have demonstrated some operational issues. This 88 document describes the issues and a new mechanism for improving it. 90 1.1. Node and Link Isolation 92 IS-IS routing mechanism has the overload-bit, which can be used by 93 operators to perform disruptive maintenance on the router. But in 94 many operational maintenance cases, it is not necessary to displace 95 all the traffic away from this node. It is useful to augment only a 96 single link or LAN for the maintenance. More detailed descriptions 97 of the challenges can be found in Appendix A and Appendix B of this 98 document. 100 1.2. Distributed Forwarding Planes 102 In a distributed forwarding platform, different forwarding line-cards 103 may have interfaces and IS-IS connections to neighbor routers. If 104 one of the line-card's software resets, it may take some time for the 105 forwarding entries to be fully populated on this line-card, in 106 particular if the router is a PE (Provider Edge) router in ISP's MPLS 107 VPN. The IS-IS adjacency may be established with a neighbor router 108 long before the entire BGP VPN prefixes are downloaded to the 109 forwarding table. It is important to signal to the network not to 110 use this particular IS-IS adjacency inbound to this router if 111 possible. Temporarily pushing out the 'Reverse Metric' over this 112 link to discourage the traffic into this line-card will help to 113 reduce the traffic loss in the network. At the meantime, the remote 114 PE routers will select a different set of PE routers for the BGP best 115 path calculation or use a different link towards the same PE router 116 on which another line-card is recovering. 118 1.3. Spine-Leaf Applications 120 In the IS-IS Spine-Leaf extension [I-D.shen-isis-spine-leaf-ext], the 121 leaf nodes will perform equal-cost or unequal-cost load sharing 122 towards all the spine nodes. In certain operational cases, for 123 instance, when one of the backbone links on a spine node is 124 congested, this spine node can push a higher metric towards the 125 connected leaf nodes to reduce the transit traffic through this spine 126 node or link. 128 1.4. LDP IGP Synchronization 130 In the [RFC5443], a mechanism is described to achieve LDP IGP 131 synchronization by using the maximum link metric value on the 132 interface. But in the case of a new IS-IS node joining the broadcast 133 network (LAN), it is not optimal to change all the nodes on the LAN 134 to the maximum link metric value, as described in [RFC6138]. This 135 Reverse Metric can be used in this case to discourage both outbound 136 and inbound traffic without affecting the traffic of other existing 137 IS-IS nodes on the LAN. 139 1.5. IS-IS Reverse Metric 141 This document proposes that the routing protocol itself be the 142 transport mechanism to allow one IS-IS router to advertise a "reverse 143 metric" in an IS-IS Hello (IIH) PDU to an adjacent node on a point- 144 to-point or multi-access LAN link. This would allow the provisioning 145 to be performed only on a single node, set a "reverse metric" on a 146 link and have traffic bidirectionally shift away from that link 147 gracefully to alternate, viable paths. 149 This Reverse Metric mechanism is to be used for both point-to-point 150 and multi-access LAN links. Unlike the point-to-point link, IS-IS 151 protocol currently does not have a way to influence the traffic 152 towards a particular node on LAN links. This proposal enables IS-IS 153 routing the capability of altering traffic in both directions on 154 either a point-to-point link or on a multi-access link of a node. 156 The metric value in the "reverse metric" TLV and the TE metric in the 157 sub-TLV being advertised is an offset or relative metric to be added 158 on top of the existing local link and TE metric value of the 159 receiver. 161 1.6. Specification of Requirements 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in [RFC2119]. 167 2. IS-IS Reverse Metric TLV 169 The Reverse Metric TLV is composed of a 1 octet field of Flags, a 3 170 octet field containing an IS-IS Metric, and a 1 octet Traffic 171 Engineering (TE) sub-TLV length field representing the length of a 172 variable number of Extended Intermediate System (IS) Reachability 173 sub-TLVs. If the "sub-TLV len" is non-zero, then the Value field 174 MUST also contain data of 1 or more Extended IS Reachability sub- 175 TLVs. 177 The Reverse Metric TLV is optional. The Reverse Metric TLV may be 178 present in any IS-IS Hello PDU. A sender MUST only transmit a single 179 Reverse Metric TLV in a IS-IS Hello PDU. If a received IS-IS Hello 180 PDU contains more than one Reverse Metric TLV, an implementation 181 SHOULD ignore all the Reverse Metric TLVs in this error condition. 183 0 1 2 3 184 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Type | Length | Flags | Metric Offset 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 Metric Offset (Continue) | sub-TLV Len |Optional sub-TLV 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 Reverse Metric TLV 193 TYPE: TBD (be replaced by the value that IANA allocates) 194 LENGTH: variable (5 - 255 octets) 195 VALUE: 197 Flags (1 octet) 198 Metric Offset (3 octets) 199 sub-TLV length (1 octet) 200 sub-TLV data (0 - 250 octets) 202 0 1 2 3 4 5 6 7 203 +-+-+-+-+-+-+-+-+ 204 | Reserved |U|W| 205 +-+-+-+-+-+-+-+-+ 207 Figure 1: Flags 209 The Metric Offset field contains a 24-bit unsigned integer of an IS- 210 IS metric that a neighbor SHOULD add to the existing, configured 211 "default metric" of the IS-IS link. Refer to "Elements of 212 Procedure", in Section 3 for details on how an IS-IS router should 213 process the Metric Offset field in a Reverse Metric TLV. 215 There is currently only two Flag bits defined. 217 W bit (0x01): The "Whole LAN" bit is only used in the context of 218 multi-access LANs. When a Reverse Metric TLV is transmitted from a 219 (non-DIS) node to the DIS, if the "Whole LAN" bit is set (1), then a 220 DIS SHOULD add the received Metric Offset value in the Reverse Metric 221 TLV to each node's existing "default metric" in the Pseudonode LSP. 222 If the "Whole LAN" bit is not set (0), then a DIS SHOULD add the 223 received Metric Offset value in the Reverse Metric TLV to the 224 existing "default metric" in the Pseudonode LSP for the single node 225 from whom the Reverse Metric TLV was received. Please refer to 226 "Multi-Access LAN Procedures", in Section 3.3, for additional 227 details. The W bit MUST be unset when a Reverse Metric TLV is 228 transmitted in a IIH PDU onto a point-to-point link to a neighbor, 229 and the W bit MUST be ignored upon receiving on a point-to-point 230 link. 232 U bit (0x02): The "Unreachable" bit is used by the IS-IS node to 233 request the neighbor for setting the accumulated metric value to be 234 limited to (2^24-1). This "U" bit applies to both the default metric 235 of Extended IS Reachability TLV and the TE default-metric sub-TLV of 236 the link. This is only relevant to the IS-IS "wide" metric mode. 238 The "sub-TLV Len" value is non-zero when an IS-IS router wishes to 239 signal that its neighbor alter parameters contained in the neighbor's 240 Traffic Engineering "Extended IS Reachability TLV", as defined in 242 [RFC5305]. This document defines that only the "Traffic Engineering 243 Default Metric" sub-TLV, sub-TLV Type 18, may be sent toward 244 neighbors in the Reverse Metric TLV, because that is used in 245 Constrained Shortest Path First (CSPF) computations. Upon receiving 246 this TE sub-TLV in a Reverse Metric TLV, a node SHOULD add the 247 received TE default metric to its existing, configured TE default 248 metric within its Extended IS Reachability TLV. Use of other sub- 249 TLVs is outside the scope of this document. The "sub-TLV Len" value 250 MUST be set to zero when an IS-IS router does not have TE sub-TLVs 251 that it wishes to send to its IS-IS neighbor. 253 3. Elements of Procedure 255 3.1. Processing Changes to Default Metric 257 The Metric Offset field, in the Reverse Metric TLV, is a "default 258 metric" that will either be in the range of 0 - 63 when a "narrow" 259 IS-IS metric is used (IS Neighbors TLV, Pseudonode LSP) [RFC1195] or 260 in the range of 0 - (2^24 - 2) when a "wide" Traffic Engineering 261 metric value is used, (Extended IS Reachability TLV) [RFC5305] 262 [RFC5817]. It is important to use the same IS-IS metric mode in both 263 ends of the link. On the receiving side of the 'reverse-metric' TLV, 264 the accumulated value of configured metric and the reverse-metric 265 needs to be limited to 63 in "narrow" metric mode and to (2^24 - 2) 266 in "wide" metric mode. This applies to both the default metric of 267 Extended IS Reachability TLV and the TE default-metric sub-TLV in LSP 268 or Pseudonode LSP with the "wide" metric mode case. If the "U" bit 269 is present in the flag, the accumulated metric value is to be limited 270 to (2^24 - 1) instead, and this applies to both the normal link 271 metric and TE metric in IS-IS "wide" metric mode. 273 If an IS-IS router is configured to originate a TE Default Metric 274 sub-TLV for a link, but receives a Reverse Metric TLV from its 275 neighbor that does not contain a TE Default Metric sub-TLV, then the 276 IS-IS router MUST NOT change the value of its TE Default Metric sub- 277 TLV for that link. 279 Routers MUST scan the Metric Offset value and TE sub-TLVs in all 280 subsequently received Reverse Metric TLVs. If changes are observed 281 by a receiver of the Reverse Metric TLV in the Metric Offset value or 282 TE Default Metric sub-TLV value, the receiving router MUST update its 283 advertised IS-IS default metric or Traffic Engineering parameters in 284 the appropriate TLVs, recompute its SPF tree and flood new LSPs to 285 other IS-IS routers. 287 3.2. Processing Changes to Default Metric for Multi-Topology IS-IS 289 The Reverse Metric TLV is applicable to Multi-Topology IS-IS (M-ISIS) 290 [RFC5120] capable point-to-point links. If an IS-IS router is 291 configured for M-ISIS it MUST send only a single Reverse Metric TLV 292 in IIH PDUs toward its neighbor(s) on the designated link that is 293 about to undergo maintenance. When an M-ISIS router receives a 294 Reverse Metric TLV it MUST add the received Metric Offset value to 295 its default metric in all Extended IS Reachability TLVs for all 296 topologies. If an M-ISIS router receives a Reverse Metric TLV with a 297 TE Default Metric sub-TLV, then the M-ISIS router MUST add the 298 received TE Default Metric value to each of its TE Default Metric 299 sub-TLVs in all of its MT Intermediate Systems TLVs. If an M-ISIS 300 router is configured to advertise TE Default Metric sub-TLVs for one 301 or more topologies, but does not receive a TE Default Metric sub-TLV 302 in a Reverse Metric TLV, then the M-ISIS router MUST add the value in 303 Metric Offset field of the Reverse Metric TLV to each of the TE 304 Default Metric sub-TLVs for all topologies. The M-ISIS should flood 305 its newly updated MT IS TLVs and recompute its SPF/CSPF accordingly. 307 Multi-Topology IS-IS [RFC5120] specifies there is no change to 308 construction of the Pseudonode LSP, regardless of the Multi-Topology 309 capabilities of a multi-access LAN. If any MT capable node on the 310 LAN advertises the Reverse Metric TLV to the DIS, the DIS should act 311 according to the "Multi-Access LAN Procedures" in Section 3.3 to 312 update, as appropriate, the default metric contained in the 313 Pseudonode LSP. If the DIS updates the default metric in and floods 314 a new Pseudonode LSP, those default metric values will be applied to 315 all topologies during Multi-Topology SPF calculations. 317 3.3. Multi-Access LAN Procedures 319 On a Multi-Access LAN, only the DIS SHOULD act upon information 320 contained in a received Reverse Metric TLV. All non-DIS nodes MUST 321 silently ignore a received Reverse Metric TLV. The decision process 322 of the routers on this LAN MUST follow the procedure in section 323 7.2.8.2 of [ISO10589], and use the "Two-way connectivity check" 324 during the topology and route calculation. 326 The Reverse Metric TE sub-TLV also applies to the DIS. If a DIS is 327 configured to apply TE over the link and it receives TE metric sub- 328 TLV in Reverse Metric TLV, it should update TE Default Metric sub-TLV 329 value of corresponding Extended IS Reachability TLV or insert new one 330 if it was not present there. 332 In the case of multi-access LANs, the "W" Flags bit is used to signal 333 from a non-DIS to the DIS whether to change the metric and optionally 334 Traffic Engineering parameters for all nodes in the Pseudonode LSP or 335 a single node on the LAN, (the originator of the Reverse Metric TLV). 337 A non-DIS node, e.g.: Router B, attached to a multi-access LAN will 338 send a Reverse Metric TLV with the W bit set to 0 to the DIS, when 339 Router B wishes the DIS to add the Metric Offset value to the default 340 metric contained in the Pseudonode LSP specific to just Router B. 341 Other non-DIS nodes, i.e.: Routers C and D, may simultaneously send a 342 Reverse Metric TLV with the W bit set to 0 to request the DIS add 343 their own Metric Offset value to their default metric contained in 344 the Pseudonode LSP. When the DIS receives a properly formatted 345 Reverse Metric TLV with the W bit set to 0, the DIS MUST only add the 346 default metric contained in its Pseudonode LSP for the specific 347 neighbor that sent the Reverse Metric TLV. 349 As long as at least one IS-IS node on the LAN sending the signal to 350 DIS with the W bit set, the DIS would add the metric value in the 351 Reverse Metric TLV to all neighbor adjacencies in the Pseudonode LSP, 352 regardless if some of the nodes on the LAN send the Reverse Metric 353 TLV without the W bit set. The DIS MUST use the metric of the 354 highest source MAC address of the node sending the TLV with the W bit 355 set. The DIS MUST use the metric value towards the nodes which 356 explicitly send the Reverse Metric TLV. 358 Local provisioning on the DIS to adjust the default metric(s) 359 contained in the Pseudonode LSP MUST take precedence over received 360 Reverse Metric TLVs. For instance, local policy of the DIS may be 361 provisioned to ignore the W bit signaling on a LAN. 363 3.4. Point-To-Point Link Procedures 365 On a point-to-point link, there is already a "configured" IS-IS 366 interface metric to be applied over the link towards the IS-IS 367 neighbor. 369 When IS-IS receives the IIH PDU with the "Reverse Metric" on a point- 370 to-point link and if the local policy allows the supporting of 371 "Reverse Metric", it MUST add the metric value in the "Metric" field 372 of the TLV to the locally configured interface metric value to be the 373 metric for this IS-IS adjacency. 375 3.5. LDP/IGP Synchronization on LANs 377 As described in [RFC6138] when a new IS-IS node joins a broadcast 378 network, it is unnecessary and sometimes even harmful to put IS-IS 379 maximum link metric on all the nodes. [RFC6138] proposes a solution 380 to have the new node not advertising the adjacency towards the 381 pseudo-node when it is not in a "cut-edge" position. 383 With the introduction of Reverse Metric in this document, a simpler 384 alternative solution to the above mentioned problem can be used. The 385 Reverse Metric allows the new node on the LAN to have the inbound 386 metric value to be the maximum and this puts the link of this new 387 node in the last resort position without impacting the other IS-IS 388 nodes on the same LAN. 390 Specifically, when IS-IS adjacencies are being established by the new 391 node on the LAN, besides setting the maximum link metric value (2^24 392 - 2) on the interface of the LAN for the LDP IGP synchronization as 393 described in [RFC5443], it SHOULD advertise the maximum metric offset 394 value in the Reverse Metric TLV in its IIH PDU to the LAN. It SHOULD 395 continue this advertisement until it completes all the LDP label 396 binding exchanges with all the neighbors over this LAN, either by 397 receiving the LDP End-of-LIB [RFC5919] for all the sessions or by 398 exceeding the provisioned timeout value on the node. 400 3.6. Operational Guidelines 402 A router MUST advertise a Reverse Metric TLV toward a neighbor only 403 for the period during which it wants a neighbor to temporarily update 404 its IS-IS metric or TE parameters towards it. 406 The use of Reverse Metric does not alter IS-IS metric parameters 407 stored in a router's persistent provisioning database. 409 Routers that receive a Reverse Metric TLV MAY send a syslog message 410 or SNMP trap, in order to assist in rapidly identifying the node in 411 the network that is asserting an IS-IS metric or Traffic Engineering 412 parameters different from that which is configured locally on the 413 device. 415 It is RECOMMENDED that implementations provide a capability to 416 disable any changes to a node's, or individual interfaces of the 417 node, default metric or Traffic Engineering parameters based upon 418 receiving properly formatted Reverse Metric TLVs. 420 4. Security Considerations 422 The enhancement in this document makes it possible for one IS-IS 423 router to manipulate the IS-IS default metric or optionally Traffic 424 Engineering parameters of adjacent IS-IS neighbors. Although IS-IS 425 routers within a single Autonomous System nearly always reside under 426 the control of a single administrative authority, it is highly 427 RECOMMENDED that operators configure authentication of IS-IS PDUs to 428 mitigate use of the Reverse Metric TLV as a potential attack vector, 429 particularly on multi-access LANs. 431 5. IANA Considerations 433 This document requests that IANA allocate from the IS-IS TLV 434 Codepoints Registry a new TLV, referred to as the "Reverse Metric" 435 TLV, possibly from the "Unassigned" range of 244-250, with the 436 following attributes: IIH = y, LSP = n, SNP = n, Purge = n. 438 6. Acknowledgments 440 The authors would like to thank Mike Shand, Dave Katz, Guan Deng, 441 Ilya Varlashkin, Jay Chen, Les Ginsberg, Peter Ashwood-Smith, Uma 442 Chunduri, Alexander Okonnikov, Jonathan Harrison, Dave Ward, Himanshu 443 Shah, Wes George, Danny McPherson, Ed Crabbe, Russ White, Robert 444 Razsuk and Tom Petch for their comments and contributions. 446 This document was produced using Marshall Rose's xml2rfc tool. 448 7. References 450 7.1. Normative References 452 [I-D.shen-isis-spine-leaf-ext] 453 Shen, N., Ginsberg, L., and S. Thyamagundalu, "IS-IS 454 Routing for Spine-Leaf Topology", draft-shen-isis-spine- 455 leaf-ext-03 (work in progress), March 2017. 457 [ISO10589] 458 ISO, "Intermediate system to Intermediate system routeing 459 information exchange protocol for use in conjunction with 460 the Protocol for providing the Connectionless-mode Network 461 Service (ISO 8473)", ISO/IEC 10589:2002. 463 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 464 dual environments", RFC 1195, DOI 10.17487/RFC1195, 465 December 1990, . 467 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 468 Requirement Levels", BCP 14, RFC 2119, 469 DOI 10.17487/RFC2119, March 1997, . 472 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 473 Topology (MT) Routing in Intermediate System to 474 Intermediate Systems (IS-ISs)", RFC 5120, 475 DOI 10.17487/RFC5120, February 2008, . 478 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 479 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 480 2008, . 482 7.2. Informative References 484 [RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP 485 Synchronization", RFC 5443, DOI 10.17487/RFC5443, March 486 2009, . 488 [RFC5817] Ali, Z., Vasseur, JP., Zamfir, A., and J. Newton, 489 "Graceful Shutdown in MPLS and Generalized MPLS Traffic 490 Engineering Networks", RFC 5817, DOI 10.17487/RFC5817, 491 April 2010, . 493 [RFC5919] Asati, R., Mohapatra, P., Chen, E., and B. Thomas, 494 "Signaling LDP Label Advertisement Completion", RFC 5919, 495 DOI 10.17487/RFC5919, August 2010, . 498 [RFC6138] Kini, S., Ed. and W. Lu, Ed., "LDP IGP Synchronization for 499 Broadcast Networks", RFC 6138, DOI 10.17487/RFC6138, 500 February 2011, . 502 Appendix A. Node Isolation Challenges 504 On rare occasions it is necessary for an operator to perform 505 disruptive network maintenance on an entire IS-IS router node, i.e.: 506 major software upgrades, power/cooling augments, etc. In these 507 cases, an operator will set the IS-IS Overload Bit (OL-bit) within 508 the Link State Protocol Data Units (LSPs) of the IS-IS router about 509 to undergo maintenance. The IS-IS router immediately floods the 510 updated LSPs to all IS-IS routers throughout the IS-IS domain. Upon 511 receipt of the updated LSPs, all IS-IS routers recalculate their 512 Shortest Path First (SPF) tree excluding IS-IS routers whose LSPs 513 have the OL-bit set. This effectively removes the IS-IS router about 514 to undergo maintenance from the topology, thus preventing it from 515 forwarding any transit traffic during the maintenance period. 517 After the maintenance activity is completed, the operator resets the 518 IS-IS Overload Bit within the LSPs of the original IS-IS router 519 causing it to flood updated IS-IS LSPs throughout the IS-IS domain. 520 All IS-IS routers recalculate their SPF tree and now include the 521 original IS-IS router in their topology calculations, allowing it to 522 be used for transit traffic again. 524 Isolating an entire IS-IS router from the topology can be especially 525 disruptive due to the displacement of a large volume of traffic 526 through an entire IS-IS router to other, sub-optimal paths, (i.e.: 527 those with significantly larger delay). Thus, in the majority of 528 network maintenance scenarios, where only a single link or LAN needs 529 to be augmented to increase its physical capacity or is experiencing 530 an intermittent failure, it is much more common and desirable to 531 gracefully remove just the targeted link or LAN from service, 532 temporarily, so that the least amount of user-data traffic is 533 affected while intrusive augment, diagnostic and/or replacement 534 procedures are being executed. 536 Appendix B. Link Isolation Challenges 538 Before network maintenance events are performed on individual 539 physical links or LANs, operators substantially increase the IS-IS 540 metric simultaneously on both devices attached to the same link or 541 LAN. In doing so, the devices generate new Link State Protocol Data 542 Units (LSPs) that are flooded throughout the network and cause all 543 routers to gradually shift traffic onto alternate paths with very 544 little, to no, disruption to in-flight communications by applications 545 or end-users. When performed successfully, this allows the operator 546 to confidently perform disruptive augmentation, fault diagnosis or 547 repairs on a link without disturbing ongoing communications in the 548 network. 550 The challenge with the above solution are as follows. First, it is 551 quite common to have routers with several hundred interfaces onboard 552 and individual interfaces that are transferring several hundred 553 Gigabits/second to Terabits/second of traffic. Thus, it is 554 imperative that operators accurately identify the same point-to-point 555 link on two, separate devices in order to increase (and, afterward, 556 decrease) the IS-IS metric appropriately. Second, the aforementioned 557 solution is very time consuming and even more error-prone to perform 558 when its necessary to temporarily remove a multi-access LAN from the 559 network topology. Specifically, the operator needs to configure ALL 560 devices's that have interfaces attached to the multi-access LAN with 561 an appropriately high IS-IS metric, (and then decrease the IS-IS 562 metric to its original value afterward). Finally, with respect to 563 multi-access LANs, there is currently no method to bidirectionally 564 isolate only a single node's interface on the LAN when performed more 565 fine-grained diagnosis and repairs to the multi-access LAN. 567 In theory, use of a Network Management System (NMS) could improve the 568 accuracy of identifying the appropriate subset of routers attached to 569 either a point-to-point link or a multi-access LAN as well as 570 signaling from the NMS to those devices, using a network management 571 protocol, to adjust the IS-IS metrics on the pertinent set of 572 interfaces. The reality is that NMS are, to a very large extent, not 573 used within Service Provider's networks for a variety of reasons. In 574 particular, NMS do not interoperate very well across different 575 vendors or even separate platform families within the same vendor. 577 The risks of misidentifying one side of a point-to-point link or one 578 or more interfaces attached to a multi-access LAN and subsequently 579 increasing its IS-IS metric are potentially increased latency, jitter 580 or packet loss. This is unacceptable given the necessary performance 581 requirements for a variety of applications, the customer perception 582 for near lossless operations and the associated, demanding Service 583 Level Agreement's (SLAs) for all network services. 585 Appendix C. Contributors' Addresses 587 Tony Li 589 Email: tony.li@tony.li 591 Authors' Addresses 593 Naiming Shen 594 Cisco Systems 595 560 McCarthy Blvd. 596 Milpitas, CA 95035 597 USA 599 Email: naiming@cisco.com 601 Shane Amante 602 Apple, Inc. 603 1 Infinite Loop 604 Cupertino, CA 95014 605 USA 607 Email: samante@apple.com 609 Mikael Abrahamsson 610 T-Systems Nordic 611 Kistagangen 26 612 Stockholm 613 SE 615 Email: Mikael.Abrahamsson@t-systems.se