idnits 2.17.1 draft-ietf-isis-reverse-metric-04.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 date (August 25, 2016) is 2794 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-01 -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' Summary: 0 errors (**), 0 flaws (~~), 2 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: February 26, 2017 Apple, Inc. 6 M. Abrahamsson 7 T-Systems Nordic 8 August 25, 2016 10 IS-IS Routing with Reverse Metric 11 draft-ietf-isis-reverse-metric-04 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 February 26, 2017. 38 Copyright Notice 40 Copyright (c) 2016 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. Mobility Cases . . . . . . . . . . . . . . . . . . . . . 3 59 1.4. Spine-Leaf Applications . . . . . . . . . . . . . . . . . 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. Operational Guidelines . . . . . . . . . . . . . . . . . 8 69 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 71 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 74 7.2. Informative References . . . . . . . . . . . . . . . . . 10 75 Appendix A. Node Isolation Challenges . . . . . . . . . . . . . 10 76 Appendix B. Link Isolation Challenges . . . . . . . . . . . . . 11 77 Appendix C. Use of Reverse Metric for LDP/IGP Synchronization on 78 LAN's . . . . . . . . . . . . . . . . . . . . . . . 12 79 Appendix D. 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. The IS- 106 IS adjacency may be established with a neighbor router long before 107 the entire BGP prefixes are downloaded to the forwarding table. It 108 is important to signal to the network not to use this particular IS- 109 IS adjacency inbound to this router if possible. Temporarily pushing 110 out the 'Reverse Metric' over this link to discourage the traffic 111 into this line-card will help to reduce the traffic loss in the 112 network. 114 1.3. Mobility Cases 116 When the IS-IS is run on some mobile devices, either in point-to- 117 point links or in broadcast networks, it is important to have the 118 routing metric to influence the traffic in both directions. When a 119 node is moving farther away, it not only needs to raise the cost for 120 traffic from this router to the network, but also it is important to 121 raise the cost for the traffic from the network towards the router. 122 When a node is moving closer, it can lower the cost on both metrics. 124 1.4. Spine-Leaf Applications 126 In the IS-IS Spine-Leaf extension [I-D.shen-isis-spine-leaf-ext], the 127 leaf nodes will perform equal-cost or unequal-cost load sharing 128 towards all the spine nodes. In certain operational cases, for 129 instance, when one of the backbone links on a spine node is 130 congested, this spine node can push a higher metric towards the 131 connected leaf nodes to reduce the transit traffic through this spine 132 node or link. 134 1.5. IS-IS Reverse Metric 136 This document proposes that the routing protocol itself be the 137 transport mechanism to allow one IS-IS router to advertise a "reverse 138 metric" in an IS-IS Hello (IIH) PDU to an adjacent node on a point- 139 to-point or multi-access LAN link. This would allow the provisioning 140 to be performed only on a single node, set a "reverse metric" on a 141 link and have traffic bidirectionally shift away from that link 142 gracefully to alternate, viable paths. 144 This Reverse Metric mechanism is to be used for both point-to-point 145 and multi-access LAN links. Unlike the point-to-point link, IS-IS 146 protocol does not have a way to influence the traffic towards a 147 particular node on LAN links. This proposal enables IS-IS routing 148 the capability of altering traffic in both directions on a multi- 149 access link of a node. 151 1.6. Specification of Requirements 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in [RFC2119]. 157 2. IS-IS Reverse Metric TLV 159 The Reverse Metric TLV is composed of a 1 octet field of Flags, a 3 160 octet field containing an IS-IS Metric, and a 1 octet Traffic 161 Engineering (TE) sub-TLV length field representing the length of a 162 variable number of Extended Intermediate System (IS) Reachability 163 sub-TLV's. If the 'S' bit in the Flags field is set to 1, then the 164 Value field MUST also contain data of 1 or more Extended IS 165 Reachability sub-TLV's. 167 The Reverse Metric TLV is optional. The Reverse Metric TLV may be 168 present in any IS-IS Hello PDU. A sender MUST only transmit a single 169 Reverse Metric TLV in a IS-IS Hello PDU. 171 0 1 2 3 172 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 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Type | Length | Flags | Metric 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 Metric (Continue) | sub-TLV Len |Optional sub-TLV 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 Reverse Metric TLV 181 TYPE: TBD 182 LENGTH: variable (5 - 255 octets) 183 VALUE: 185 Flags (1 octet) 186 Metric (3 octets) 187 TE sub-TLV length (1 octet) 188 TE sub-TLV data (0 - 250 octets) 189 0 1 2 3 4 5 6 7 190 +-+-+-+-+-+-+-+-+ 191 | Reserved |S|W| 192 +-+-+-+-+-+-+-+-+ 194 Figure 1: Flags 196 The Metric field contains a 24-bit unsigned integer of an IS-IS 197 metric that a neighbor SHOULD add to the existing, configured 198 "default metric" contained within its IS Neighbors TLV, Extended IS 199 Reachability TLV's for point-to-point links, or Pseudonode LSP by the 200 Designated Intermediate System (DIS) for multi-access LAN's, back 201 toward the router and the link that originated this Reverse Metric 202 TLV. Refer to "Elements of Procedure", in Section 3 for details on 203 how an IS-IS router should process the Metric field in a Reverse 204 Metric TLV. 206 There is currently only two Flag bits defined. 208 W bit (0x01): The "Whole LAN" bit is only used in the context of 209 multi-access LAN's. When a Reverse Metric TLV is transmitted from a 210 (non-DIS) node to the DIS, if the "Whole LAN" bit is set (1), then a 211 DIS SHOULD add the received Metric value in the Reverse Metric TLV to 212 each node's existing "default metric" in the Pseudonode LSP. If the 213 "Whole LAN" bit is not set (0), then a DIS SHOULD add the received 214 Metric value in the Reverse Metric TLV to the existing "default 215 metric" in the Pseudonode LSP for the single node from whom the 216 Reverse Metric TLV was received. Please refer to "Multi-Access LAN 217 Procedures", in Section 3.3, for additional details. The W bit MUST 218 be unset when a Reverse Metric TLV is transmitted in a IIH PDU onto a 219 point-to-point link to a neighbor, and the W bit MUST be ignored upon 220 receiving on a point-to-point link. 222 S bit (0x02): The "TE sub-TLV" bit MUST be set when an IS-IS router 223 wishes to signal that its neighbor alter parameters contained in the 224 neighbor's Traffic Engineering "Extended IS Reachability TLV", as 225 defined in [RFC5305]. This document defines that only the "Traffic 226 Engineering Default Metric" sub-TLV, sub-TLV Type 18, may be sent 227 toward neighbors in the Reverse Metric TLV, because that is used in 228 Constrained Shortest Path First (CSPF) computations. Upon receiving 229 this TE sub-TLV in a Reverse Metric TLV, a node SHOULD add the 230 received TE default metric to its existing, configured TE default 231 metric within its Extended IS Reachability TLV. Use of other sub- 232 TLV's is outside the scope of this document. The S bit MUST NOT be 233 set when an IS-IS router does not have TE sub-TLV's that it wishes to 234 send to its IS-IS neighbor. 236 3. Elements of Procedure 238 3.1. Processing Changes to Default Metric 240 The Metric field, in the Reverse Metric TLV, is a "default metric" 241 that will either be in the range of 0 - 63 when a "narrow" IS-IS 242 metric is used (IS Neighbors TLV, Pseudonode LSP) [RFC1195] or in the 243 range of 0 - (2^24 - 2) when a "wide" Traffic Engineering metric 244 value is used, (Extended IS Reachability TLV) [RFC5305]. It is 245 RECOMMENDED that implementations, by default, place the appropriate 246 maximum default metric value, 63 or (2^24 - 2), in the Metric field 247 and TE Default Metric sub-TLV of the Reverse Metric TLV, since the 248 most common use is to indicate the link of the router is overloaded 249 and to remove the link from the topology, except for use as a last- 250 resort path. 252 In order to ensure that an individual TE link is used as a link of 253 last resort during SPF computation, its metric MUST NOT be greater 254 than or equal to (2^24 - 1) [RFC5305]. Therefore, a receiver of a 255 Reverse Metric TLV MUST use the numerically smallest value of either 256 the sum of its existing default metric and the Metric value in the 257 Reverse Metric TLV or (2^24 - 2), as the default metric when updating 258 its Extended IS Reachability TLV and TE default-metric sub-TLV's that 259 it will then flood throughout the IS-IS domain, using normal IS-IS 260 procedures. Likewise, originators of a Pseudonode LSP or IS 261 Neighbors TLV MUST use the numerically smallest value of either the 262 sum of its existing default metric and the Metric value it receives 263 in a Reverse Metric TLV or 63 when updating the corresponding 264 Pseudonode LSP or IS Neighbor TLV before they are flooded. This also 265 applies when an IS-IS router is only configured or capable of sending 266 a "narrow" IS-IS default metric, in the range of 0 - 63, but receives 267 a "wide" Metric value in a Reverse Metric TLV, in the range of 64 - 268 (2^24 - 2). In this case, the receiving router MUST use the maximum 269 "narrow" IS-IS default metric, 63, as its IS-IS default metric value 270 in its updated IS Neighbor TLV or Pseudonode LSP that it floods. 272 If an IS-IS router is configured to originate a TE Default Metric 273 sub-TLV for a link, but receives a Reverse Metric TLV from its 274 neighbor that does not contain a TE Default Metric sub-TLV, then the 275 IS-IS router MUST add the value in the Metric field of the Reverse 276 Metric TLV to its own TE Default Metric sub-TLV for that link. The 277 IS-IS router should then flood the updated Extended IS Reachability 278 TLV, including its updated TE Default Metric sub-TLV, using normal 279 IS-IS procedures. 281 Routers MUST scan the Metric value and TE sub-TLV's in all 282 subsequently received Reverse Metric TLV's. If changes are observed 283 by a receiver of the Reverse Metric TLV in the Metric value or TE 284 Default Metric sub-TLV value, the receiving router MUST update its 285 advertised IS-IS default metric or Traffic Engineering parameters in 286 the appropriate TLV's, recompute its SPF tree and flood new LSP's to 287 other IS-IS routers. 289 If the router does not understand the Reverse Metric TLV or is 290 explicitly configured to ignore received Reverse Metric TLV's, then 291 it MUST NOT update the default metric in its IS Neighbors TLV, 292 Extended IS Reachability TLV, TE Default Metric sub-TLV, Multi- 293 Topology Intermediate Systems TLV, or Pseudonode LSP, nor execute 294 other procedures that would result from acting on a Reverse Metric 295 TLV, such as recomputing its SPF tree. 297 3.2. Processing Changes to Default Metric for Multi-Topology IS-IS 299 The Reverse Metric TLV is applicable to Multi-Topology IS-IS (M-ISIS) 300 [RFC5120] capable point-to-point links. If an IS-IS router is 301 configured for M-ISIS it MUST send only a single Reverse Metric TLV 302 in IIH PDU's toward its neighbor(s) on the designated link that is 303 about to undergo maintenance. When an M-ISIS router receives a 304 Reverse Metric TLV it MUST add the received Metric value to its 305 default metric in all Extended IS Reachability TLV's for all 306 topologies. If an M-ISIS router receives a Reverse Metric TLV with a 307 TE Default Metric sub-TLV, then the M-ISIS router MUST add the 308 received TE Default Metric value to each of its TE Default Metric 309 sub-TLV's in all of its MT Intermediate Systems TLV's. If an M-ISIS 310 router is configured to advertise TE Default Metric sub-TLV's for one 311 or more topologies, but does not receive a TE Default Metric sub-TLV 312 in a Reverse Metric TLV, then the M-ISIS router MUST add the value in 313 Metric field of the Reverse Metric TLV to each of the TE Default 314 Metric sub-TLV's for all topologies. The M-ISIS should flood its 315 newly updated MT IS TLV's and recompute its SPF/CSPF accordingly. 317 Multi-Topology IS-IS [RFC5120] specifies there is no change to 318 construction of the Pseudonode LSP, regardless of the Multi-Topology 319 capabilities of a multi-access LAN. If any MT capable node on the 320 LAN advertises the Reverse Metric TLV to the DIS, the DIS should act 321 according to the "Multi-Access LAN Procedures" in Section 3.3 to 322 update, as appropriate, the default metric contained in the 323 Pseudonode LSP. If the DIS updates the default metric in and floods 324 a new Pseudonode LSP, those default metric values will be applied to 325 all topologies during Multi-Topology SPF calculations. 327 3.3. Multi-Access LAN Procedures 329 On a Multi-Access LAN, only the DIS SHOULD act upon information 330 contained in a received Reverse Metric TLV. All non-DIS nodes MUST 331 silently ignore a received Reverse Metric TLV. 333 In the case of multi-access LAN's, the "W" Flags bit is used to 334 signal from a non-DIS to the DIS whether to change the metric and 335 optionally Traffic Engineering parameters for all nodes in the 336 Pseudonode LSP or a single node on the LAN, (the originator of the 337 Reverse Metric TLV). 339 A non-DIS node, e.g.: Router B, attached to a multi-access LAN will 340 send a Reverse Metric TLV with the W bit set to 0 to the DIS, when 341 Router B wishes the DIS to add the Metric value to the default metric 342 contained in the Pseudonode LSP specific to just Router B. Other 343 non-DIS nodes, i.e.: Routers C and D, may simultaneously send a 344 Reverse Metric TLV with the W bit set to 0 to request the DIS add 345 their own Metric value to their default metric contained in the 346 Pseudonode LSP. When the DIS receives a properly formatted Reverse 347 Metric TLV with the W bit set to 0, the DIS MUST only add the default 348 metric contained in its Pseudonode LSP for the specific neighbor that 349 sent the Reverse Metric TLV. 351 As long as at least one IS-IS node on the LAN sending the signal to 352 DIS with the W bit set, the DIS would add the metric value in the 353 Reverse Metric TLV to all neighbor adjacencies in the Pseudonode LSP, 354 regardless if some of the nodes on the LAN send the Reverse Metric 355 TLV without the W bit set. The DIS MUST use the metric of the 356 highest source MAC address of the node sending the TLV with the W bit 357 set. The DIS MUST use the metric value towards the nodes which 358 explicitly send the Reverse Metric TLV. 360 Local provisioning on the DIS to adjust the default metric(s) 361 contained in the Pseudonode LSP MUST take precedence over received 362 Reverse Metric TLV's. For instance, local policy of the DIS may be 363 provisioned to ignore the W bit signaling on a LAN. 365 3.4. Operational Guidelines 367 A router MUST advertise a Reverse Metric TLV toward a neighbor only 368 for the period during which it wants a neighbor to temporarily update 369 its IS-IS metric or TE parameters towards it. 371 During the period when a Reverse Metric TLV is used, IS-IS routers 372 that are generating and receiving a Reverse Metric TLV MUST NOT 373 change their existing IS-IS metric or Traffic Engineering parameters 374 in their persistent provisioning database, since those parameters are 375 carefully derived from off-line capacity planning tools and are 376 difficult to restore to their original values. 378 Routers that receive a Reverse Metric TLV MAY send a syslog message 379 or SNMP trap, in order to assist in rapidly identifying the node in 380 the network that is asserting an IS-IS metric or Traffic Engineering 381 parameters different from that which is configured locally on the 382 device. 384 It is RECOMMENDED that implementations provide a capability to 385 disable any changes to a node's, or individual interfaces of the 386 node, default metric or Traffic Engineering parameters based upon 387 receiving properly formatted Reverse Metric TLV's. 389 4. Security Considerations 391 The enhancement in this document makes it possible for one IS-IS 392 router to manipulate the IS-IS default metric or optionally Traffic 393 Engineering parameters of adjacent IS-IS neighbors. Although IS-IS 394 routers within a single Autonomous System nearly always reside under 395 the control of a single administrative authority, it is highly 396 RECOMMENDED that operators configure authentication of IS-IS PDU's to 397 mitigate use of the Reverse Metric TLV as a potential attack vector, 398 particularly on multi-access LAN's. 400 5. IANA Considerations 402 This document requests that IANA allocate from the IS-IS TLV 403 Codepoints Registry a new TLV, referred to as the "Reverse Metric" 404 TLV, with the following attributes: IIH = y, LSP = n, SNP = n, Purge 405 = n. 407 6. Acknowledgments 409 The authors would like to thank Mike Shand, Dave Katz, Guan Deng, 410 Ilya Varlashkin, Jay Chen, Les Ginsberg, Peter Ashwood-Smith, 411 Jonathan Harrison, Dave Ward, Himanshu Shah, Wes George, Danny 412 McPherson, Ed Crabbe, Russ White and Robert Razsuk for their 413 contributions. 415 This document was produced using Marshall Rose's xml2rfc tool. 417 7. References 419 7.1. Normative References 421 [I-D.shen-isis-spine-leaf-ext] 422 Shen, N. and S. Thyamagundalu, "IS-IS Routing for Spine- 423 Leaf Topology", draft-shen-isis-spine-leaf-ext-01 (work in 424 progress), April 2016. 426 [ISO10589] 427 ISO, "Intermediate system to Intermediate system routeing 428 information exchange protocol for use in conjunction with 429 the Protocol for providing the Connectionless-mode Network 430 Service (ISO 8473)", ISO/IEC 10589:2002. 432 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 433 dual environments", RFC 1195, DOI 10.17487/RFC1195, 434 December 1990, . 436 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 437 Requirement Levels", BCP 14, RFC 2119, 438 DOI 10.17487/RFC2119, March 1997, 439 . 441 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 442 Topology (MT) Routing in Intermediate System to 443 Intermediate Systems (IS-ISs)", RFC 5120, 444 DOI 10.17487/RFC5120, February 2008, 445 . 447 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 448 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 449 2008, . 451 7.2. Informative References 453 [RFC5919] Asati, R., Mohapatra, P., Chen, E., and B. Thomas, 454 "Signaling LDP Label Advertisement Completion", RFC 5919, 455 DOI 10.17487/RFC5919, August 2010, 456 . 458 Appendix A. Node Isolation Challenges 460 On rare occasions it is necessary for an operator to perform 461 disruptive network maintenance on an entire IS-IS router node, i.e.: 462 major software upgrades, power/cooling augments, etc. In these 463 cases, an operator will set the IS-IS Overload Bit (OL-bit) within 464 the Link State Protocol Data Units (LSP's) of the IS-IS router about 465 to undergo maintenance. The IS-IS router immediately floods the 466 updated LSP's to all IS-IS routers throughout the IS-IS domain. Upon 467 receipt of the updated LSP's, all IS-IS routers recalculate their 468 Shortest Path First (SPF) tree excluding IS-IS routers whose LSP's 469 have the OL-bit set. This effectively removes the IS-IS router about 470 to undergo maintenance from the topology, thus preventing it from 471 forwarding any transit traffic during the maintenance period. 473 After the maintenance activity is completed, the operator resets the 474 IS-IS Overload Bit within the LSP's of the original IS-IS router 475 causing it to flood updated IS-IS LSP's throughout the IS-IS domain. 476 All IS-IS routers recalculate their SPF tree and now include the 477 original IS-IS router in their topology calculations, allowing it to 478 be used for transit traffic again. 480 Isolating an entire IS-IS router from the topology can be especially 481 disruptive due to the displacement of a large volume of traffic 482 through an entire IS-IS router to other, sub-optimal paths, (i.e.: 483 those with significantly larger delay). Thus, in the majority of 484 network maintenance scenarios, where only a single link or LAN needs 485 to be augmented to increase its physical capacity or is experiencing 486 an intermittent failure, it is much more common and desirable to 487 gracefully remove just the targeted link or LAN from service, 488 temporarily, so that the least amount of user-data traffic is 489 affected while intrusive augment, diagnostic and/or replacement 490 procedures are being executed. 492 Appendix B. Link Isolation Challenges 494 Before network maintenance events are performed on individual 495 physical links or LAN's, operators substantially increase the IS-IS 496 metric simultaneously on both devices attached to the same link or 497 LAN. In doing so, the devices generate new Link State Protocol Data 498 Units (LSP's) that are flooded throughout the network and cause all 499 routers to gradually shift traffic onto alternate paths with very 500 little, to no, disruption to in-flight communications by applications 501 or end-users. When performed successfully, this allows the operator 502 to confidently perform disruptive augmentation, fault diagnosis or 503 repairs on a link without disturbing ongoing communications in the 504 network. 506 The challenge with the above solution are as follows. First, it is 507 quite common to have routers with several hundred interfaces onboard 508 and individual interfaces that are transferring several hundred 509 Gigabits/second to Terabits/second of traffic. Thus, it is 510 imperative that operators accurately identify the same point-to-point 511 link on two, separate devices in order to increase (and, afterward, 512 decrease) the IS-IS metric appropriately. Second, the aforementioned 513 solution is very time consuming and even more error-prone to perform 514 when its necessary to temporarily remove a multi-access LAN from the 515 network topology. Specifically, the operator needs to configure ALL 516 devices's that have interfaces attached to the multi-access LAN with 517 an appropriately high IS-IS metric, (and then decrease the IS-IS 518 metric to its original value afterward). Finally, with respect to 519 multi-access LAN's, there is currently no method to bidirectionally 520 isolate only a single node's interface on the LAN when performed more 521 fine-grained diagnosis and repairs to the multi-access LAN. 523 In theory, use of a Network Management System (NMS) could improve the 524 accuracy of identifying the appropriate subset of routers attached to 525 either a point-to-point link or a multi-access LAN as well as 526 signaling from the NMS to those devices, using a network management 527 protocol, to adjust the IS-IS metrics on the pertinent set of 528 interfaces. The reality is that NMS are, to a very large extent, not 529 used within Service Provider's networks for a variety of reasons. In 530 particular, NMS do not interoperate very well across different 531 vendors or even separate platform families within the same vendor. 533 The risks of misidentifying one side of a point-to-point link or one 534 or more interfaces attached to a multi-access LAN and subsequently 535 increasing its IS-IS metric are potentially increased latency, jitter 536 or packet loss. This is unacceptable given the necessary performance 537 requirements for a variety of applications, the customer perception 538 for near lossless operations and the associated, demanding Service 539 Level Agreement's (SLA's) for all network services. 541 Appendix C. Use of Reverse Metric for LDP/IGP Synchronization on LAN's 543 This document primarily outlines the use of IS-IS Reverse Metric TLV 544 for networks that use IP forwarding. However, it is also critical to 545 consider application of the IS-IS Reverse Metric TLV to networks that 546 use MPLS forwarding, specifically networks that use IS-IS as the IGP 547 and LDP for signaling MPLS labels used for forwarding. In these 548 networks, it is often the case that IS-IS will become operational and 549 determine the shortest path through a link or LAN prior to LDP 550 becoming operational (forming an adjacency with a LDP neighbor and 551 exchanging LDP labels), which results in temporary blackholing for 552 data traffic reliant on MPLS forwarding. 554 This scenario should be avoided in MPLS networks where IS-IS is the 555 IGP and LDP signaling is used to exchange tunnel labels over a LAN. 556 In these cases, it is recommended that the IS-IS Reverse Metric TLV 557 be utilized when IS-IS and LDP adjacencies are in the process of 558 becoming established among one, or several, routers attached to a 559 common multi-access LAN. 561 Specifically, when an IS-IS adjacency is being established from a 562 non-DIS node, the non-DIS should transmit a IS-IS Reverse Metric TLV 563 toward the DIS with the W-bit not set (0), as per 564 "Elements of Procedure" in Section 3 of this document, until the non- 565 DIS router either: a) completes transmission of a LDP End-of-LIB 566 marker [RFC5919] toward the DIS; or, b) expiration of a local (pre- 567 configured) timer that indicates that LDP adjacency should be fully 568 operational to the DIS. At this point, the non-DIS router should 569 cease advertisement of the IS-IS Reverse Metric TLV, which should 570 cause the (re-)advertisement of normal default metric(s) to itself in 571 the Pseudonode LSP. 573 Appendix D. Contributors' Addresses 575 Tony Li 577 Email: tony.li@tony.li 579 Authors' Addresses 581 Naiming Shen 582 Cisco Systems 583 560 McCarthy Blvd. 584 Milpitas, CA 95035 585 USA 587 Email: naiming@cisco.com 589 Shane Amante 590 Apple, Inc. 591 1 Infinite Loop 592 Cupertino, CA 95014 593 USA 595 Email: samante@apple.com 597 Mikael Abrahamsson 598 T-Systems Nordic 599 Kistagangen 26 600 Stockholm 601 SE 603 Email: Mikael.Abrahamsson@t-systems.se