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