idnits 2.17.1 draft-ietf-isis-reverse-metric-09.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 24, 2018) is 2285 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 28, 2018 Apple, Inc. 6 M. Abrahamsson 7 T-Systems Nordic 8 January 24, 2018 10 IS-IS Routing with Reverse Metric 11 draft-ietf-isis-reverse-metric-09 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 28, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . 9 73 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 76 7.2. Informative References . . . . . . . . . . . . . . . . . 10 77 Appendix A. Node Isolation Challenges . . . . . . . . . . . . . 11 78 Appendix B. Link Isolation Challenges . . . . . . . . . . . . . 11 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 3.2. Processing Changes to Default Metric for Multi-Topology IS-IS 281 The Reverse Metric TLV is applicable to Multi-Topology IS-IS (M-ISIS) 282 [RFC5120] capable point-to-point links. If an IS-IS router is 283 configured for M-ISIS it MUST send only a single Reverse Metric TLV 284 in IIH PDUs toward its neighbor(s) on the designated link. When an 285 M-ISIS router receives a Reverse Metric TLV it MUST add the received 286 Metric Offset value to its default metric in all Extended IS 287 Reachability TLVs for all topologies. If an M-ISIS router receives a 288 Reverse Metric TLV with a TE Default Metric sub-TLV, then the M-ISIS 289 router MUST add the received TE Default Metric value to each of its 290 TE Default Metric sub-TLVs in all of its MT Intermediate Systems 291 TLVs. If an M-ISIS router is configured to advertise TE Default 292 Metric sub-TLVs for one or more topologies, but does not receive a TE 293 Default Metric sub-TLV in a Reverse Metric TLV, then the M-ISIS 294 router MUST NOT change the value in each of the TE Default Metric 295 sub-TLVs for all topologies. 297 Multi-Topology IS-IS [RFC5120] specifies there is no change to 298 construction of the Pseudonode LSP, regardless of the Multi-Topology 299 capabilities of a multi-access LAN. If any MT capable node on the 300 LAN advertises the Reverse Metric TLV to the DIS, the DIS should act 301 according to the "Multi-Access LAN Procedures" in Section 3.3 to 302 update, as appropriate, the default metric contained in the 303 Pseudonode LSP. If the DIS updates the default metric in and floods 304 a new Pseudonode LSP, those default metric values will be applied to 305 all topologies during Multi-Topology SPF calculations. 307 3.3. Multi-Access LAN Procedures 309 On a Multi-Access LAN, only the DIS SHOULD act upon information 310 contained in a received Reverse Metric TLV. All non-DIS nodes MUST 311 silently ignore a received Reverse Metric TLV. The decision process 312 of the routers on this LAN MUST follow the procedure in section 313 7.2.8.2 of [ISO10589], and use the "Two-way connectivity check" 314 during the topology and route calculation. 316 The Reverse Metric TE sub-TLV also applies to the DIS. If a DIS is 317 configured to apply TE over the link and it receives TE metric sub- 318 TLV in Reverse Metric TLV, it should update TE Default Metric sub-TLV 319 value of corresponding Extended IS Reachability TLV or insert new one 320 if it was not present there. 322 In the case of multi-access LANs, the "W" Flags bit is used to signal 323 from a non-DIS to the DIS whether to change the metric and optionally 324 Traffic Engineering parameters for all nodes in the Pseudonode LSP or 325 a single node on the LAN, (the originator of the Reverse Metric TLV). 327 A non-DIS node, e.g.: Router B, attached to a multi-access LAN will 328 send a Reverse Metric TLV with the W bit set to 0 to the DIS, when 329 Router B wishes the DIS to add the Metric Offset value to the default 330 metric contained in the Pseudonode LSP specific to just Router B. 331 Other non-DIS nodes, i.e.: Routers C and D, may simultaneously send a 332 Reverse Metric TLV with the W bit set to 0 to request the DIS add 333 their own Metric Offset value to their default metric contained in 334 the Pseudonode LSP. When the DIS receives a properly formatted 335 Reverse Metric TLV with the W bit set to 0, the DIS MUST only add the 336 default metric contained in its Pseudonode LSP for the specific 337 neighbor that sent the Reverse Metric TLV. 339 As long as at least one IS-IS node on the LAN sending the signal to 340 DIS with the W bit set, the DIS would add the metric value in the 341 Reverse Metric TLV to all neighbor adjacencies in the Pseudonode LSP, 342 regardless if some of the nodes on the LAN send the Reverse Metric 343 TLV without the W bit set. The DIS MUST use the metric of the 344 highest source MAC address of the node sending the TLV with the W bit 345 set. The DIS MUST use the metric value towards the nodes which 346 explicitly send the Reverse Metric TLV. 348 Local provisioning on the DIS to adjust the default metric(s) 349 contained in the Pseudonode LSP MUST take precedence over received 350 Reverse Metric TLVs. For instance, local policy of the DIS may be 351 provisioned to ignore the W bit signaling on a LAN. 353 3.4. Point-To-Point Link Procedures 355 On a point-to-point link, there is already a "configured" IS-IS 356 interface metric to be applied over the link towards the IS-IS 357 neighbor. 359 When IS-IS receives the IIH PDU with the "Reverse Metric" on a point- 360 to-point link and if the local policy allows the supporting of 361 "Reverse Metric", it must add the metric value in "reverse metric" 362 TLV according to the rules described in Section 3.1 and Section 3.2. 364 3.5. LDP/IGP Synchronization on LANs 366 As described in [RFC6138] when a new IS-IS node joins a broadcast 367 network, it is unnecessary and sometimes even harmful to put IS-IS 368 maximum link metric on all the nodes. [RFC6138] proposes a solution 369 to have the new node not advertising the adjacency towards the 370 pseudo-node when it is not in a "cut-edge" position. 372 With the introduction of Reverse Metric in this document, a simpler 373 alternative solution to the above mentioned problem can be used. The 374 Reverse Metric allows the new node on the LAN to have the inbound 375 metric value to be the maximum and this puts the link of this new 376 node in the last resort position without impacting the other IS-IS 377 nodes on the same LAN. 379 Specifically, when IS-IS adjacencies are being established by the new 380 node on the LAN, besides setting the maximum link metric value (2^24 381 - 2) on the interface of the LAN for the LDP IGP synchronization as 382 described in [RFC5443], it SHOULD advertise the maximum metric offset 383 value in the Reverse Metric TLV in its IIH PDU to the LAN. It SHOULD 384 continue this advertisement until it completes all the LDP label 385 binding exchanges with all the neighbors over this LAN, either by 386 receiving the LDP End-of-LIB [RFC5919] for all the sessions or by 387 exceeding the provisioned timeout value on the node. 389 3.6. Operational Guidelines 391 A router MUST advertise a Reverse Metric TLV toward a neighbor only 392 for the period during which it wants a neighbor to temporarily update 393 its IS-IS metric or TE parameters towards it. 395 The use of Reverse Metric does not alter IS-IS metric parameters 396 stored in a router's persistent provisioning database. 398 Routers that receive a Reverse Metric TLV MAY send a syslog message 399 or SNMP trap, in order to assist in rapidly identifying the node in 400 the network that is asserting an IS-IS metric or Traffic Engineering 401 parameters different from that which is configured locally on the 402 device. 404 It is RECOMMENDED that implementations provide a capability to 405 disable any changes to a node's, or individual interfaces of the 406 node, default metric or Traffic Engineering parameters based upon 407 receiving properly formatted Reverse Metric TLVs. 409 4. Security Considerations 411 The enhancement in this document makes it possible for one IS-IS 412 router to manipulate the IS-IS default metric or optionally Traffic 413 Engineering parameters of adjacent IS-IS neighbors. Although IS-IS 414 routers within a single Autonomous System nearly always reside under 415 the control of a single administrative authority, it is highly 416 RECOMMENDED that operators configure authentication of IS-IS PDUs to 417 mitigate use of the Reverse Metric TLV as a potential attack vector, 418 particularly on multi-access LANs. 420 5. IANA Considerations 422 This document requests that IANA allocate from the IS-IS TLV 423 Codepoints Registry a new TLV, referred to as the "Reverse Metric" 424 TLV, possibly from the "Unassigned" range of 244-250, with the 425 following attributes: IIH = y, LSP = n, SNP = n, Purge = n. 427 6. Acknowledgments 429 The authors would like to thank Mike Shand, Dave Katz, Guan Deng, 430 Ilya Varlashkin, Jay Chen, Les Ginsberg, Peter Ashwood-Smith, Uma 431 Chunduri, Alexander Okonnikov, Jonathan Harrison, Dave Ward, Himanshu 432 Shah, Wes George, Danny McPherson, Ed Crabbe, Russ White, Robert 433 Razsuk and Tom Petch for their comments and contributions. 435 This document was produced using Marshall Rose's xml2rfc tool. 437 7. References 439 7.1. Normative References 441 [I-D.shen-isis-spine-leaf-ext] 442 Shen, N., Ginsberg, L., and S. Thyamagundalu, "IS-IS 443 Routing for Spine-Leaf Topology", draft-shen-isis-spine- 444 leaf-ext-03 (work in progress), March 2017. 446 [ISO10589] 447 ISO, "Intermediate system to Intermediate system routeing 448 information exchange protocol for use in conjunction with 449 the Protocol for providing the Connectionless-mode Network 450 Service (ISO 8473)", ISO/IEC 10589:2002. 452 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 453 dual environments", RFC 1195, DOI 10.17487/RFC1195, 454 December 1990, . 456 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 457 Requirement Levels", BCP 14, RFC 2119, 458 DOI 10.17487/RFC2119, March 1997, . 461 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 462 Topology (MT) Routing in Intermediate System to 463 Intermediate Systems (IS-ISs)", RFC 5120, 464 DOI 10.17487/RFC5120, February 2008, . 467 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 468 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 469 2008, . 471 7.2. Informative References 473 [RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP 474 Synchronization", RFC 5443, DOI 10.17487/RFC5443, March 475 2009, . 477 [RFC5817] Ali, Z., Vasseur, JP., Zamfir, A., and J. Newton, 478 "Graceful Shutdown in MPLS and Generalized MPLS Traffic 479 Engineering Networks", RFC 5817, DOI 10.17487/RFC5817, 480 April 2010, . 482 [RFC5919] Asati, R., Mohapatra, P., Chen, E., and B. Thomas, 483 "Signaling LDP Label Advertisement Completion", RFC 5919, 484 DOI 10.17487/RFC5919, August 2010, . 487 [RFC6138] Kini, S., Ed. and W. Lu, Ed., "LDP IGP Synchronization for 488 Broadcast Networks", RFC 6138, DOI 10.17487/RFC6138, 489 February 2011, . 491 Appendix A. Node Isolation Challenges 493 On rare occasions it is necessary for an operator to perform 494 disruptive network maintenance on an entire IS-IS router node, i.e.: 495 major software upgrades, power/cooling augments, etc. In these 496 cases, an operator will set the IS-IS Overload Bit (OL-bit) within 497 the Link State Protocol Data Units (LSPs) of the IS-IS router about 498 to undergo maintenance. The IS-IS router immediately floods the 499 updated LSPs to all IS-IS routers throughout the IS-IS domain. Upon 500 receipt of the updated LSPs, all IS-IS routers recalculate their 501 Shortest Path First (SPF) tree excluding IS-IS routers whose LSPs 502 have the OL-bit set. This effectively removes the IS-IS router about 503 to undergo maintenance from the topology, thus preventing it from 504 forwarding any transit traffic during the maintenance period. 506 After the maintenance activity is completed, the operator resets the 507 IS-IS Overload Bit within the LSPs of the original IS-IS router 508 causing it to flood updated IS-IS LSPs throughout the IS-IS domain. 509 All IS-IS routers recalculate their SPF tree and now include the 510 original IS-IS router in their topology calculations, allowing it to 511 be used for transit traffic again. 513 Isolating an entire IS-IS router from the topology can be especially 514 disruptive due to the displacement of a large volume of traffic 515 through an entire IS-IS router to other, sub-optimal paths, (i.e.: 516 those with significantly larger delay). Thus, in the majority of 517 network maintenance scenarios, where only a single link or LAN needs 518 to be augmented to increase its physical capacity or is experiencing 519 an intermittent failure, it is much more common and desirable to 520 gracefully remove just the targeted link or LAN from service, 521 temporarily, so that the least amount of user-data traffic is 522 affected while intrusive augment, diagnostic and/or replacement 523 procedures are being executed. 525 Appendix B. Link Isolation Challenges 527 Before network maintenance events are performed on individual 528 physical links or LANs, operators substantially increase the IS-IS 529 metric simultaneously on both devices attached to the same link or 530 LAN. In doing so, the devices generate new Link State Protocol Data 531 Units (LSPs) that are flooded throughout the network and cause all 532 routers to gradually shift traffic onto alternate paths with very 533 little, to no, disruption to in-flight communications by applications 534 or end-users. When performed successfully, this allows the operator 535 to confidently perform disruptive augmentation, fault diagnosis or 536 repairs on a link without disturbing ongoing communications in the 537 network. 539 The challenge with the above solution are as follows. First, it is 540 quite common to have routers with several hundred interfaces onboard 541 and individual interfaces that are transferring several hundred 542 Gigabits/second to Terabits/second of traffic. Thus, it is 543 imperative that operators accurately identify the same point-to-point 544 link on two, separate devices in order to increase (and, afterward, 545 decrease) the IS-IS metric appropriately. Second, the aforementioned 546 solution is very time consuming and even more error-prone to perform 547 when its necessary to temporarily remove a multi-access LAN from the 548 network topology. Specifically, the operator needs to configure ALL 549 devices's that have interfaces attached to the multi-access LAN with 550 an appropriately high IS-IS metric, (and then decrease the IS-IS 551 metric to its original value afterward). Finally, with respect to 552 multi-access LANs, there is currently no method to bidirectionally 553 isolate only a single node's interface on the LAN when performed more 554 fine-grained diagnosis and repairs to the multi-access LAN. 556 In theory, use of a Network Management System (NMS) could improve the 557 accuracy of identifying the appropriate subset of routers attached to 558 either a point-to-point link or a multi-access LAN as well as 559 signaling from the NMS to those devices, using a network management 560 protocol, to adjust the IS-IS metrics on the pertinent set of 561 interfaces. The reality is that NMS are, to a very large extent, not 562 used within Service Provider's networks for a variety of reasons. In 563 particular, NMS do not interoperate very well across different 564 vendors or even separate platform families within the same vendor. 566 The risks of misidentifying one side of a point-to-point link or one 567 or more interfaces attached to a multi-access LAN and subsequently 568 increasing its IS-IS metric are potentially increased latency, jitter 569 or packet loss. This is unacceptable given the necessary performance 570 requirements for a variety of applications, the customer perception 571 for near lossless operations and the associated, demanding Service 572 Level Agreement's (SLAs) for all network services. 574 Appendix C. Contributors' Addresses 576 Tony Li 578 Email: tony.li@tony.li 580 Authors' Addresses 582 Naiming Shen 583 Cisco Systems 584 560 McCarthy Blvd. 585 Milpitas, CA 95035 586 USA 588 Email: naiming@cisco.com 590 Shane Amante 591 Apple, Inc. 592 1 Infinite Loop 593 Cupertino, CA 95014 594 USA 596 Email: samante@apple.com 598 Mikael Abrahamsson 599 T-Systems Nordic 600 Kistagangen 26 601 Stockholm 602 SE 604 Email: Mikael.Abrahamsson@t-systems.se