idnits 2.17.1 draft-ietf-isis-reverse-metric-07.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 (October 30, 2017) is 2369 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: May 3, 2018 Apple, Inc. 6 M. Abrahamsson 7 T-Systems Nordic 8 October 30, 2017 10 IS-IS Routing with Reverse Metric 11 draft-ietf-isis-reverse-metric-07 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 May 3, 2018. 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. Spine-Leaf Applications . . . . . . . . . . . . . . . . . 3 59 1.4. LDP IGP Synchronization . . . . . . . . . . . . . . . . . 3 60 1.5. IS-IS Reverse Metric . . . . . . . . . . . . . . . . . . 3 61 1.6. Specification of Requirements . . . . . . . . . . . . . . 4 62 2. IS-IS Reverse Metric TLV . . . . . . . . . . . . . . . . . . 4 63 3. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 6 64 3.1. Processing Changes to Default Metric . . . . . . . . . . 6 65 3.2. Processing Changes to Default Metric for Multi-Topology 66 IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 3.3. Multi-Access LAN Procedures . . . . . . . . . . . . . . . 7 68 3.4. Point-To-Point Link Procedures . . . . . . . . . . . . . 8 69 3.5. LDP/IGP Synchronization on LAN's . . . . . . . . . . . . 9 70 3.6. Link Overload Attribute Bit . . . . . . . . . . . . . . . 9 71 3.7. Operational Guidelines . . . . . . . . . . . . . . . . . 9 72 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 77 7.2. Informative References . . . . . . . . . . . . . . . . . 11 78 Appendix A. Node Isolation Challenges . . . . . . . . . . . . . 12 79 Appendix B. Link Isolation Challenges . . . . . . . . . . . . . 12 80 Appendix C. 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, in 107 particular if the router is a PE (Provider Edge) router in ISP's MPLS 108 VPN. The IS-IS adjacency may be established with a neighbor router 109 long before the entire BGP VPN prefixes are downloaded to the 110 forwarding table. It is important to signal to the network not to 111 use this particular IS-IS adjacency inbound to this router if 112 possible. Temporarily pushing out the 'Reverse Metric' over this 113 link to discourage the traffic into this line-card will help to 114 reduce the traffic loss in the network. At the meantime, the remote 115 PE routers will select a different set of PE routers for the BGP best 116 path calculation or use a different link towards the same PE router 117 on which another line-card is recovering. 119 1.3. Spine-Leaf Applications 121 In the IS-IS Spine-Leaf extension [I-D.shen-isis-spine-leaf-ext], the 122 leaf nodes will perform equal-cost or unequal-cost load sharing 123 towards all the spine nodes. In certain operational cases, for 124 instance, when one of the backbone links on a spine node is 125 congested, this spine node can push a higher metric towards the 126 connected leaf nodes to reduce the transit traffic through this spine 127 node or link. 129 1.4. LDP IGP Synchronization 131 In the [RFC5443], a mechanism is described to achieve LDP IGP 132 synchronization by using the maximum link metric value on the 133 interface. But in the case of a new IS-IS node joining the broadcast 134 network (LAN), it is not optimal to change all the nodes on the LAN 135 to the maximum link metric value, as described in [RFC6138]. This 136 Reverse Metric can be used in this case to discourage both outbound 137 and inbound traffic without affecting the traffic of other existing 138 IS-IS nodes on the LAN. 140 1.5. IS-IS Reverse Metric 142 This document proposes that the routing protocol itself be the 143 transport mechanism to allow one IS-IS router to advertise a "reverse 144 metric" in an IS-IS Hello (IIH) PDU to an adjacent node on a point- 145 to-point or multi-access LAN link. This would allow the provisioning 146 to be performed only on a single node, set a "reverse metric" on a 147 link and have traffic bidirectionally shift away from that link 148 gracefully to alternate, viable paths. 150 This Reverse Metric mechanism is to be used for both point-to-point 151 and multi-access LAN links. Unlike the point-to-point link, IS-IS 152 protocol currently does not have a way to influence the traffic 153 towards a particular node on LAN links. This proposal enables IS-IS 154 routing the capability of altering traffic in both directions on 155 either a point-to-point link or on a multi-access link of a node. 157 1.6. Specification of Requirements 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in [RFC2119]. 163 2. IS-IS Reverse Metric TLV 165 The Reverse Metric TLV is composed of a 1 octet field of Flags, a 3 166 octet field containing an IS-IS Metric, and a 1 octet Traffic 167 Engineering (TE) sub-TLV length field representing the length of a 168 variable number of Extended Intermediate System (IS) Reachability 169 sub-TLV's. If the 'S' bit in the Flags field is set to 1, then the 170 Value field MUST also contain data of 1 or more Extended IS 171 Reachability sub-TLV's. 173 The Reverse Metric TLV is optional. The Reverse Metric TLV may be 174 present in any IS-IS Hello PDU. A sender MUST only transmit a single 175 Reverse Metric TLV in a IS-IS Hello PDU. 177 0 1 2 3 178 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 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Type | Length | Flags | Metric Offset 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 Metric Offset (Continue) | sub-TLV Len |Optional sub-TLV 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 Reverse Metric TLV 187 TYPE: TBD 188 LENGTH: variable (5 - 255 octets) 189 VALUE: 191 Flags (1 octet) 192 Metric Offset (3 octets) 193 sub-TLV length (1 octet) 194 sub-TLV data (0 - 250 octets) 196 0 1 2 3 4 5 6 7 197 +-+-+-+-+-+-+-+-+ 198 | Reserved |W| 199 +-+-+-+-+-+-+-+-+ 201 Figure 1: Flags 203 The Metric Offset field contains a 24-bit unsigned integer of an IS- 204 IS metric that a neighbor SHOULD add to the existing, configured 205 "default metric" contained within its IS Neighbors TLV, Extended IS 206 Reachability TLV's for point-to-point links, or Pseudonode LSP by the 207 Designated Intermediate System (DIS) for multi-access LAN's, back 208 toward the router and the link that originated this Reverse Metric 209 TLV. Refer to "Elements of Procedure", in Section 3 for details on 210 how an IS-IS router should process the Metric Offset field in a 211 Reverse Metric TLV. 213 There is currently only two Flag bits defined. 215 W bit (0x01): The "Whole LAN" bit is only used in the context of 216 multi-access LAN's. When a Reverse Metric TLV is transmitted from a 217 (non-DIS) node to the DIS, if the "Whole LAN" bit is set (1), then a 218 DIS SHOULD add the received Metric Offset value in the Reverse Metric 219 TLV to each node's existing "default metric" in the Pseudonode LSP. 220 If the "Whole LAN" bit is not set (0), then a DIS SHOULD add the 221 received Metric Offset value in the Reverse Metric TLV to the 222 existing "default metric" in the Pseudonode LSP for the single node 223 from whom the Reverse Metric TLV was received. Please refer to 224 "Multi-Access LAN Procedures", in Section 3.3, for additional 225 details. The W bit MUST be unset when a Reverse Metric TLV is 226 transmitted in a IIH PDU onto a point-to-point link to a neighbor, 227 and the W bit MUST be ignored upon receiving on a point-to-point 228 link. 230 The "sub-TLV Len" value is non-zero when an IS-IS router wishes to 231 signal that its neighbor alter parameters contained in the neighbor's 232 Traffic Engineering "Extended IS Reachability TLV", as defined in 233 [RFC5305]. This document defines that only the "Traffic Engineering 234 Default Metric" sub-TLV, sub-TLV Type 18, may be sent toward 235 neighbors in the Reverse Metric TLV, because that is used in 236 Constrained Shortest Path First (CSPF) computations. Upon receiving 237 this TE sub-TLV in a Reverse Metric TLV, a node SHOULD add the 238 received TE default metric to its existing, configured TE default 239 metric within its Extended IS Reachability TLV. Use of other sub- 240 TLV's is outside the scope of this document. The "sub-TLV Len" value 241 MUST be set to zero when an IS-IS router does not have TE sub-TLV's 242 that it wishes to send to its IS-IS neighbor. 244 3. Elements of Procedure 246 3.1. Processing Changes to Default Metric 248 The Metric Offset field, in the Reverse Metric TLV, is a "default 249 metric" that will either be in the range of 0 - 63 when a "narrow" 250 IS-IS metric is used (IS Neighbors TLV, Pseudonode LSP) [RFC1195] or 251 in the range of 0 - (2^24 - 2) when a "wide" Traffic Engineering 252 metric value is used, (Extended IS Reachability TLV) [RFC5305]. It 253 is RECOMMENDED that implementations, by default, place the 254 appropriate maximum default metric value, 63 or (2^24 - 2), in the 255 Metric Offset field and TE Default Metric sub-TLV of the Reverse 256 Metric TLV, since the most common use is to indicate the link of the 257 router is overloaded and to remove the link from the topology, except 258 for use as a last-resort path. 260 In order to ensure that an individual TE link is used as a link of 261 last resort during SPF computation, its metric MUST NOT be greater 262 than or equal to (2^24 - 1) [RFC5305]. Therefore, a receiver of a 263 Reverse Metric TLV MUST use the numerically smallest value of either 264 the sum of its existing default metric and the Metric Offset value in 265 the Reverse Metric TLV or (2^24 - 2), as the default metric when 266 updating its Extended IS Reachability TLV and TE default-metric sub- 267 TLV's that it will then flood throughout the IS-IS domain, using 268 normal IS-IS procedures. Likewise, originators of a Pseudonode LSP 269 or IS Neighbors TLV MUST use the numerically smallest value of either 270 the sum of its existing default metric and the Metric Offset value it 271 receives in a Reverse Metric TLV or 63 when updating the 272 corresponding Pseudonode LSP or IS Neighbor TLV before they are 273 flooded. This also applies when an IS-IS router is only configured 274 or capable of sending a "narrow" IS-IS default metric, in the range 275 of 0 - 63, but receives a "wide" Metric value in a Reverse Metric 276 TLV, in the range of 64 - (2^24 - 2). In this case, the receiving 277 router MUST use the maximum "narrow" IS-IS default metric, 63, as its 278 IS-IS default metric value in its updated IS Neighbor TLV or 279 Pseudonode LSP that it floods. 281 If an IS-IS router is configured to originate a TE Default Metric 282 sub-TLV for a link, but receives a Reverse Metric TLV from its 283 neighbor that does not contain a TE Default Metric sub-TLV, then the 284 IS-IS router MUST add the value in the Metric Offset field of the 285 Reverse Metric TLV to its own TE Default Metric sub-TLV for that 286 link. The IS-IS router should then flood the updated Extended IS 287 Reachability TLV, including its updated TE Default Metric sub-TLV, 288 using normal IS-IS procedures. 290 Routers MUST scan the Metric Offset value and TE sub-TLV's in all 291 subsequently received Reverse Metric TLV's. If changes are observed 292 by a receiver of the Reverse Metric TLV in the Metric Offset value or 293 TE Default Metric sub-TLV value, the receiving router MUST update its 294 advertised IS-IS default metric or Traffic Engineering parameters in 295 the appropriate TLV's, recompute its SPF tree and flood new LSP's to 296 other IS-IS routers. 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 Offset value to 306 its 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 Offset field of the Reverse Metric TLV to each of the TE 315 Default Metric sub-TLV's for all topologies. The M-ISIS should flood 316 its 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. The decision process 333 of the routers on this LAN MUST follow the procedure in section 334 7.2.8.2 of [ISO10589], and use the "Two-way connectivity check" 335 during the topology and route calculation. 337 In the case of multi-access LAN's, the "W" Flags bit is used to 338 signal from a non-DIS to the DIS whether to change the metric and 339 optionally Traffic Engineering parameters for all nodes in the 340 Pseudonode LSP or a single node on the LAN, (the originator of the 341 Reverse Metric TLV). 343 A non-DIS node, e.g.: Router B, attached to a multi-access LAN will 344 send a Reverse Metric TLV with the W bit set to 0 to the DIS, when 345 Router B wishes the DIS to add the Metric Offset value to the default 346 metric contained in the Pseudonode LSP specific to just Router B. 347 Other non-DIS nodes, i.e.: Routers C and D, may simultaneously send a 348 Reverse Metric TLV with the W bit set to 0 to request the DIS add 349 their own Metric Offset value to their default metric contained in 350 the Pseudonode LSP. When the DIS receives a properly formatted 351 Reverse Metric TLV with the W bit set to 0, the DIS MUST only add the 352 default metric contained in its Pseudonode LSP for the specific 353 neighbor that sent the Reverse Metric TLV. 355 As long as at least one IS-IS node on the LAN sending the signal to 356 DIS with the W bit set, the DIS would add the metric value in the 357 Reverse Metric TLV to all neighbor adjacencies in the Pseudonode LSP, 358 regardless if some of the nodes on the LAN send the Reverse Metric 359 TLV without the W bit set. The DIS MUST use the metric of the 360 highest source MAC address of the node sending the TLV with the W bit 361 set. The DIS MUST use the metric value towards the nodes which 362 explicitly send the Reverse Metric TLV. 364 Local provisioning on the DIS to adjust the default metric(s) 365 contained in the Pseudonode LSP MUST take precedence over received 366 Reverse Metric TLV's. For instance, local policy of the DIS may be 367 provisioned to ignore the W bit signaling on a LAN. 369 3.4. Point-To-Point Link Procedures 371 On a point-to-point link, there is already a "configured" IS-IS 372 interface metric to be applied over the link towards the IS-IS 373 neighbor. 375 When IS-IS receives the IIH PDU with the "Reverse Metric" on a point- 376 to-point link and if the local policy allows the supporting of 377 "Reverse Metric", it MUST add the metric value in the "Metric" field 378 of the TLV to the locally configured interface metric value to be the 379 metric for this IS-IS adjacency. The metric MUST NOT exceed the 380 maximum allowed value used in either "narrow" (63) or "wide" (2^24 - 381 2) metric mode. 383 3.5. LDP/IGP Synchronization on LAN's 385 As described in [RFC6138] when a new IS-IS node joins a broadcast 386 network, it is unnecessary and sometimes even harmful to put IS-IS 387 maximum link metric on all the nodes. [RFC6138] proposes a solution 388 to have the new node not advertising the adjacency towards the 389 pseudo-node when it is not in a "cut-edge" position. 391 With the introduction of Reverse Metric in this document, a simpler 392 alternative solution to the above mentioned problem can be used. The 393 Reverse Metric allows the new node on the LAN to have the inbound 394 metric value to be the maximum and this puts the link of this new 395 node in the last resort position without impacting the other IS-IS 396 nodes on the same LAN. 398 Specifically, when IS-IS adjacencies are being established by the new 399 node on the LAN, besides setting the maximum link metric value (2^24 400 - 2) on the interface of the LAN for the LDP IGP synchronization as 401 described in [RFC5443], it SHOULD advertise the maximum metric offset 402 value in the Reverse Metric TLV in its IIH PDU to the LAN. It SHOULD 403 continue this advertisement until it completes all the LDP label 404 binding exchanges with all the neighbors over this LAN, either by 405 receiving the LDP End-of-LIB [RFC5919] for all the sessions or by 406 exceeding the provisioned timeout value on the node. 408 3.6. Link Overload Attribute Bit 410 Not every TE tunnel is setup using IS-IS link metric or IS-IS link TE 411 metric across the domain. Although the larger than normal link 412 metric or TE metric can be one way to indicate to the PCE controller 413 that the node on the other side of the link is trying to reduce the 414 inbound traffic, but a more explicit way is to have the router set a 415 bit in the "link-attribute" sub-TLV [RFC5029] to express this link is 416 currently overloaded. How the controller or the source of the TE 417 tunnel use the "link overload" information in altering the TE tunnel 418 path is outside the scope of this document. 420 3.7. Operational Guidelines 422 A router MUST advertise a Reverse Metric TLV toward a neighbor only 423 for the period during which it wants a neighbor to temporarily update 424 its IS-IS metric or TE parameters towards it. 426 The use of Reverse Metric does not alter IS-IS metric parameters 427 stored in a router's persistent provisioning database. 429 Routers that receive a Reverse Metric TLV MAY send a syslog message 430 or SNMP trap, in order to assist in rapidly identifying the node in 431 the network that is asserting an IS-IS metric or Traffic Engineering 432 parameters different from that which is configured locally on the 433 device. 435 It is RECOMMENDED that implementations provide a capability to 436 disable any changes to a node's, or individual interfaces of the 437 node, default metric or Traffic Engineering parameters based upon 438 receiving properly formatted Reverse Metric TLV's. 440 4. Security Considerations 442 The enhancement in this document makes it possible for one IS-IS 443 router to manipulate the IS-IS default metric or optionally Traffic 444 Engineering parameters of adjacent IS-IS neighbors. Although IS-IS 445 routers within a single Autonomous System nearly always reside under 446 the control of a single administrative authority, it is highly 447 RECOMMENDED that operators configure authentication of IS-IS PDU's to 448 mitigate use of the Reverse Metric TLV as a potential attack vector, 449 particularly on multi-access LAN's. 451 5. IANA Considerations 453 This document requests that IANA allocate from the IS-IS TLV 454 Codepoints Registry a new TLV, referred to as the "Reverse Metric" 455 TLV, with the following attributes: IIH = y, LSP = n, SNP = n, Purge 456 = n. 458 This document also request that IANA allocate from the link-attribute 459 bit value for sub-TLV 19 of TLV 22. This new bit is referred to as 460 the "Link Overload" bit. 462 6. Acknowledgments 464 The authors would like to thank Mike Shand, Dave Katz, Guan Deng, 465 Ilya Varlashkin, Jay Chen, Les Ginsberg, Peter Ashwood-Smith, Uma 466 Chunduri, Alexander Okonnikov, Jonathan Harrison, Dave Ward, Himanshu 467 Shah, Wes George, Danny McPherson, Ed Crabbe, Russ White and Robert 468 Razsuk for their contributions. 470 This document was produced using Marshall Rose's xml2rfc tool. 472 7. References 474 7.1. Normative References 476 [I-D.shen-isis-spine-leaf-ext] 477 Shen, N., Ginsberg, L., and S. Thyamagundalu, "IS-IS 478 Routing for Spine-Leaf Topology", draft-shen-isis-spine- 479 leaf-ext-03 (work in progress), March 2017. 481 [ISO10589] 482 ISO, "Intermediate system to Intermediate system routeing 483 information exchange protocol for use in conjunction with 484 the Protocol for providing the Connectionless-mode Network 485 Service (ISO 8473)", ISO/IEC 10589:2002. 487 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 488 dual environments", RFC 1195, DOI 10.17487/RFC1195, 489 December 1990, . 491 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 492 Requirement Levels", BCP 14, RFC 2119, 493 DOI 10.17487/RFC2119, March 1997, . 496 [RFC5029] Vasseur, JP. and S. Previdi, "Definition of an IS-IS Link 497 Attribute Sub-TLV", RFC 5029, DOI 10.17487/RFC5029, 498 September 2007, . 500 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 501 Topology (MT) Routing in Intermediate System to 502 Intermediate Systems (IS-ISs)", RFC 5120, 503 DOI 10.17487/RFC5120, February 2008, . 506 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 507 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 508 2008, . 510 7.2. Informative References 512 [RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP 513 Synchronization", RFC 5443, DOI 10.17487/RFC5443, March 514 2009, . 516 [RFC5919] Asati, R., Mohapatra, P., Chen, E., and B. Thomas, 517 "Signaling LDP Label Advertisement Completion", RFC 5919, 518 DOI 10.17487/RFC5919, August 2010, . 521 [RFC6138] Kini, S., Ed. and W. Lu, Ed., "LDP IGP Synchronization for 522 Broadcast Networks", RFC 6138, DOI 10.17487/RFC6138, 523 February 2011, . 525 Appendix A. Node Isolation Challenges 527 On rare occasions it is necessary for an operator to perform 528 disruptive network maintenance on an entire IS-IS router node, i.e.: 529 major software upgrades, power/cooling augments, etc. In these 530 cases, an operator will set the IS-IS Overload Bit (OL-bit) within 531 the Link State Protocol Data Units (LSP's) of the IS-IS router about 532 to undergo maintenance. The IS-IS router immediately floods the 533 updated LSP's to all IS-IS routers throughout the IS-IS domain. Upon 534 receipt of the updated LSP's, all IS-IS routers recalculate their 535 Shortest Path First (SPF) tree excluding IS-IS routers whose LSP's 536 have the OL-bit set. This effectively removes the IS-IS router about 537 to undergo maintenance from the topology, thus preventing it from 538 forwarding any transit traffic during the maintenance period. 540 After the maintenance activity is completed, the operator resets the 541 IS-IS Overload Bit within the LSP's of the original IS-IS router 542 causing it to flood updated IS-IS LSP's throughout the IS-IS domain. 543 All IS-IS routers recalculate their SPF tree and now include the 544 original IS-IS router in their topology calculations, allowing it to 545 be used for transit traffic again. 547 Isolating an entire IS-IS router from the topology can be especially 548 disruptive due to the displacement of a large volume of traffic 549 through an entire IS-IS router to other, sub-optimal paths, (i.e.: 550 those with significantly larger delay). Thus, in the majority of 551 network maintenance scenarios, where only a single link or LAN needs 552 to be augmented to increase its physical capacity or is experiencing 553 an intermittent failure, it is much more common and desirable to 554 gracefully remove just the targeted link or LAN from service, 555 temporarily, so that the least amount of user-data traffic is 556 affected while intrusive augment, diagnostic and/or replacement 557 procedures are being executed. 559 Appendix B. Link Isolation Challenges 561 Before network maintenance events are performed on individual 562 physical links or LAN's, operators substantially increase the IS-IS 563 metric simultaneously on both devices attached to the same link or 564 LAN. In doing so, the devices generate new Link State Protocol Data 565 Units (LSP's) that are flooded throughout the network and cause all 566 routers to gradually shift traffic onto alternate paths with very 567 little, to no, disruption to in-flight communications by applications 568 or end-users. When performed successfully, this allows the operator 569 to confidently perform disruptive augmentation, fault diagnosis or 570 repairs on a link without disturbing ongoing communications in the 571 network. 573 The challenge with the above solution are as follows. First, it is 574 quite common to have routers with several hundred interfaces onboard 575 and individual interfaces that are transferring several hundred 576 Gigabits/second to Terabits/second of traffic. Thus, it is 577 imperative that operators accurately identify the same point-to-point 578 link on two, separate devices in order to increase (and, afterward, 579 decrease) the IS-IS metric appropriately. Second, the aforementioned 580 solution is very time consuming and even more error-prone to perform 581 when its necessary to temporarily remove a multi-access LAN from the 582 network topology. Specifically, the operator needs to configure ALL 583 devices's that have interfaces attached to the multi-access LAN with 584 an appropriately high IS-IS metric, (and then decrease the IS-IS 585 metric to its original value afterward). Finally, with respect to 586 multi-access LAN's, there is currently no method to bidirectionally 587 isolate only a single node's interface on the LAN when performed more 588 fine-grained diagnosis and repairs to the multi-access LAN. 590 In theory, use of a Network Management System (NMS) could improve the 591 accuracy of identifying the appropriate subset of routers attached to 592 either a point-to-point link or a multi-access LAN as well as 593 signaling from the NMS to those devices, using a network management 594 protocol, to adjust the IS-IS metrics on the pertinent set of 595 interfaces. The reality is that NMS are, to a very large extent, not 596 used within Service Provider's networks for a variety of reasons. In 597 particular, NMS do not interoperate very well across different 598 vendors or even separate platform families within the same vendor. 600 The risks of misidentifying one side of a point-to-point link or one 601 or more interfaces attached to a multi-access LAN and subsequently 602 increasing its IS-IS metric are potentially increased latency, jitter 603 or packet loss. This is unacceptable given the necessary performance 604 requirements for a variety of applications, the customer perception 605 for near lossless operations and the associated, demanding Service 606 Level Agreement's (SLA's) for all network services. 608 Appendix C. Contributors' Addresses 610 Tony Li 612 Email: tony.li@tony.li 614 Authors' Addresses 615 Naiming Shen 616 Cisco Systems 617 560 McCarthy Blvd. 618 Milpitas, CA 95035 619 USA 621 Email: naiming@cisco.com 623 Shane Amante 624 Apple, Inc. 625 1 Infinite Loop 626 Cupertino, CA 95014 627 USA 629 Email: samante@apple.com 631 Mikael Abrahamsson 632 T-Systems Nordic 633 Kistagangen 26 634 Stockholm 635 SE 637 Email: Mikael.Abrahamsson@t-systems.se