idnits 2.17.00 (12 Aug 2021) /tmp/idnits35339/draft-amante-isis-reverse-metric-01.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 (November 29, 2010) is 4190 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO 10589' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IS-IS Working Group N. Shen 3 Internet-Draft T. Li 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: June 2, 2011 S. Amante 6 Level 3 Communications 7 M. Abrahamsson 8 Tele2 9 November 29, 2010 11 IS-IS Reverse Metric TLV for Network Maintenance Events 12 draft-amante-isis-reverse-metric-01 14 Abstract 16 This document describes an improved IS-IS neighbor management scheme 17 which can be used to enhance network performance by allowing 18 operators to quickly and accurately shift traffic away from a point- 19 to-point or multi-access LAN interface by allowing one IS-IS router 20 to signal to a second, adjacent IS-IS neighbor to adjust its IS-IS 21 metric that should be used to temporarily reach the first IS-IS 22 router during network maintenance events. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on June 2, 2011. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Link Isolation Challenges . . . . . . . . . . . . . . . . 3 60 1.2. IS-IS Reverse Metric . . . . . . . . . . . . . . . . . . . 4 61 1.3. Specification of Requirements . . . . . . . . . . . . . . 4 63 2. IS-IS Reverse Metric TLV . . . . . . . . . . . . . . . . . . . 4 65 3. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 6 66 3.1. Processing Changes to Default Metric . . . . . . . . . . . 6 67 3.2. Processing Changes to Default Metric for 68 Multi-Topology IS-IS . . . . . . . . . . . . . . . . . . . 7 69 3.3. Multi-Access LAN Procedures . . . . . . . . . . . . . . . 8 70 3.4. Order of Operations . . . . . . . . . . . . . . . . . . . 9 71 3.5. Operational Guidelines . . . . . . . . . . . . . . . . . . 9 73 4. Reverse Metric TLV Example Use Case . . . . . . . . . . . . . 10 75 5. Operational Considerations . . . . . . . . . . . . . . . . . . 11 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 85 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 89 1. Introduction 91 The IS-IS [ISO 10589] routing protocol has been widely used in 92 Internet Service Provider IP/MPLS networks. Operational experience 93 with the protocol, combined with ever increasing requirements for 94 lossless operations have demonstrated some operational issues. This 95 document describes one issue and a new mechanism for improving it. 97 1.1. Link Isolation Challenges 99 During network maintenance events, operators substantially increase 100 the IS-IS metric simultaneously on both devices attached to the same 101 link. In doing so, the devices generate new Link State Protocol Data 102 Units (LSP's) that are flooded throughout the network and cause all 103 routers to gradually shift traffic onto alternate paths with very 104 little, to no, disruption to in-flight communications by applications 105 or end-users. When performed successfully, this allows the operator 106 to confidently perform disruptive fault diagnosis and restoration on 107 a link without disturbing ongoing communications in the network. 109 The challenge with the above solution are as follows. First, it is 110 quite common to have routers with several hundred interfaces onboard 111 and individual interfaces that are transferring several hundred 112 Gigabits/second to Terabits/second of traffic. Thus, it is 113 imperative that operators accurately identify the same point-to-point 114 link on two, separate devices in order to increase (and, afterward, 115 decrease) the IS-IS metric appropriately. Second, the aforementioned 116 solution is very time consuming and even more error-prone to perform 117 when its necessary to temporarily remove a multi-access LAN from the 118 network topology. Specifically, the operator needs to configure ALL 119 devices's that have interfaces attached to the multi-access LAN with 120 an appropriately high IS-IS metric, (and then decrease the IS-IS 121 metric to its original value afterward). Finally, with respect to 122 multi-access LAN's, there is currently no method to bidirectionally 123 isolate only a single node's interface on the LAN when performed more 124 fine-grained diagnosis and repairs to the multi-access LAN. 126 In theory, use of a Network Management System (NMS) could improve the 127 accuracy of identifying the appropriate subset of routers attached to 128 either a point-to-point link or a multi-access LAN as well as 129 signaling from the NMS to those devices, using a network management 130 protocol, to adjust the IS-IS metrics on the pertinent set of 131 interfaces. The reality is that NMS are, to a very large extent, not 132 used within Service Provider's networks for a variety of reasons. In 133 particular, NMS do not interoperate very well across different 134 vendors or even separate platform families within the same vendor. 136 The risks of misidentifying one side of a point-to-point link or one 137 or more interfaces attached to a multi-access LAN and subsequently 138 increasing its IS-IS metric are potentially increased latency, jitter 139 or packet loss. This is unacceptable given the necessary performance 140 requirements for a variety of applications, the customer perception 141 for near lossless operations and the associated, demanding Service 142 Level Agreement's (SLA's) for all network services. 144 1.2. IS-IS Reverse Metric 146 This document proposes that the routing protocol itself be the 147 transport mechanism to allow one IS-IS router to advertise to an 148 adjacent node on a point-to-point or multi-access LAN link a "reverse 149 metric" in a IS-IS Hello (IIH) PDU. This would allow an operator to 150 only configure a single router, set a "reverse metric" on a link and 151 have traffic bidirectionally shift away from that link gracefully to 152 alternate, viable paths. 154 1.3. Specification of Requirements 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in [RFC2119]. 160 2. IS-IS Reverse Metric TLV 162 The Reverse Metric TLV is composed of 1 octet for the Type, 1 octet 163 that specifies the number of bytes in the Value field and a variable- 164 length Value field. The Value field starts with a 1 octet field of 165 Flags followed by a 3 octet field containing an IS-IS Metric and, 166 lastly, a 1 octet Traffic Engineering (TE) sub-TLV length field 167 representing the length of a variable number of Extended Intermediate 168 System (IS) Reachability sub-TLV's. If the 'S' bit in the Flags 169 field is set to 1, then the Value field MUST also contain data of 1 170 or more Extended IS Reachability sub-TLV's. 172 The Reverse Metric TLV is optional. The Reverse Metric TLV may be 173 present in any IS-IS Hello PDU. A sender MUST only transmit a single 174 Reverse Metric TLV in a IS-IS Hello PDU. 176 TYPE: TBD 177 LENGTH: variable (5 - 255 octets) 178 VALUE: 179 Flags (1 octet) 180 Metric (3 octets) 181 TE sub-TLV length (1 octet) 182 TE sub-TLV data (0 - 250 octets) 184 Flags 186 0 1 2 3 4 5 6 7 187 +-+-+-+-+-+-+-+-+ 188 | Reserved |S|W| 189 +-+-+-+-+-+-+-+-+ 191 Figure 1: Flags 193 The Reverse Metric TLV Type is TBD. Please refer to IANA 194 Considerations, in Section 7, for more details. 196 The Metric field contains a 24-bit unsigned integer of an IS-IS 197 metric a neighbor SHOULD add to the existing, configured "default 198 metric" contained within its IS Neighbors TLV or Extended IS 199 Reachability TLV's for point-to-point links, or Pseudonode LSP by the 200 Designated Intermediate System (DIS) for multi-access LAN's, back 201 toward the router that originated this Reverse Metric TLV. Refer to 202 "Elements of Procedure", below in Section 3, for details of how an 203 IS-IS router should process the Metric field in a Reverse Metric TLV. 205 There is currently only two Flag bits defined. 207 W bit (0x01): The "Whole LAN" bit is only used in the context of 208 multi-access LAN's. When a Reverse Metric TLV is transmitted from a 209 (non-DIS) node to the DIS, if the "Whole LAN" bit is set (1), then a 210 DIS SHOULD add the received Metric value in the Reverse Metric TLV to 211 each node's existing "default metric" in the Pseudonode LSP. If the 212 "Whole LAN" bit is not set (0), then a DIS SHOULD add the received 213 Metric value in the Reverse Metric TLV to the existing "default 214 metric" in the Pseudonode LSP for the single node from whom the 215 Reverse Metric TLV was received. Please refer to "Multi-Access LAN 216 Procedures", in Section 3.3, for additional details. The W bit MUST 217 be unset (0) when a Reverse Metric TLV is transmitted in a IIH PDU 218 onto a point-to-point link to an IS-IS neighbor. 220 S bit (0x02): The "TE sub-TLV" bit MUST be set (1) when an IS-IS 221 router wishes to signal that its neighbor alter parameters contained 222 in the neighbor's Traffic Engineering "Extended IS Reachability TLV", 223 as defined in [RFC5305]. This document defines that only the 224 "Traffic Engineering Default Metric" sub-TLV, sub-TLV Type 18, may be 225 sent toward neighbors in the Reverse Metric TLV, because that is used 226 in Constrained Shortest Path First (CSPF) computations. Upon receipt 227 of this TE sub-TLV in a Reverse Metric TLV, a node SHOULD add the 228 received TE default metric to its existing, configured TE default 229 metric within its Extended IS Reachability TLV. Use of other sub- 230 TLV's is outside the scope of this document. 232 The S bit MUST NOT be set (0) when an IS-IS router does not have TE 233 sub-TLV's that it wishes to send to its IS-IS neighbor. 235 3. Elements of Procedure 237 3.1. Processing Changes to Default Metric 239 The Metric field, in the Reverse Metric TLV, is a "default metric" 240 that will either be in the range of 0 - 63 when a "narrow" IS-IS 241 metric is used (IS Neighbors TLV, Pseudonode LSP) [RFC1195] or in the 242 range of 0 - (2^24 - 2) when a "wide" Traffic Engineering metric 243 value is used, (Extended IS Reachability TLV) [RFC5305]. It is 244 RECOMMENDED that implementations, by default, place the appropriate 245 maximum default metric value, 63 or (2^24 - 2), in the Metric field 246 and TE Default Metric sub-TLV of the Reverse Metric TLV, since the 247 most common use is to remove the link from the topology, except for 248 use as a last-resort path. 250 In order to ensure that an individual TE link is used as a link of 251 last resort during SPF computation, its metric MUST NOT be greater 252 than or equal to (2^24 - 1) [RFC5305]. Therefore, a receiver of a 253 Reverse Metric TLV MUST use the numerically smallest value of either 254 the sum of its existing default metric and the Metric value in the 255 Reverse Metric TLV or (2^24 - 2), as the default metric when updating 256 its Extended IS Reachability TLV and TE default-metric sub-TLV's that 257 it will then flood throughout the IS-IS domain, using normal IS-IS 258 procedures. Likewise, originators of a Pseudonode LSP or IS 259 Neighbors TLV MUST use the numerically smallest value of either the 260 sum of its existing default metric and the Metric value it receives 261 in a Reverse Metric TLV or 63 when updating the corresponding 262 Pseudonode LSP or IS Neighbor TLV before they are flooded. This also 263 applies when an IS-IS router is only configured or capable of sending 264 a "narrow" IS-IS default metric, in the range of 0 - 63, but receives 265 a "wide" Metric value in a Reverse Metric TLV, in the range of 64 - 266 (2^24 - 2). In this case, the receiving router MUST use the maximum 267 "narrow" IS-IS default metric, 63, as its IS-IS default metric value 268 in its updated IS Neighbor TLV or Pseudonode LSP that it floods. 270 If an IS-IS router is configured to originate a TE Default Metric 271 sub-TLV for a link, but receives a Reverse Metric TLV from its 272 neighbor that does not contain a TE Default Metric sub-TLV, then the 273 IS-IS router MUST add the value in the Metric field of the Reverse 274 Metric TLV to its own TE Default Metric sub-TLV for that link. The 275 IS-IS router should then flood the updated Extended IS Reachability 276 TLV, including its updated TE Default Metric sub-TLV, using normal 277 IS-IS procedures. 279 Routers MUST scan the Metric value and TE sub-TLV's in all 280 subsequently received Reverse Metric TLV's. If changes are observed 281 by a receiver of the Reverse Metric TLV in the Metric value or TE 282 Default Metric sub-TLV value, the receiving router MUST update its 283 advertised IS-IS default metric or Traffic Engineering parameters in 284 the appropriate TLV's, recompute its SPF tree and flood new LSP's to 285 other IS-IS routers, according to the recommendations outlined in 286 Section 3.4, Order of Operations, below. 288 If the router does not understand the Reverse Metric TLV or is 289 explicitly configured to ignore received Reverse Metric TLV's, then 290 it MUST NOT update the default metric in its IS Neighbors TLV, 291 Extended IS Reachability TLV, TE Default Metric sub-TLV, Multi- 292 Topology Intermediate Systems TLV or Pseudonode LSP nor execute other 293 procedures that would result from acting on a Reverse Metric TLV, 294 such as recomputing its SPF tree. 296 3.2. Processing Changes to Default Metric for Multi-Topology IS-IS 298 The Reverse Metric TLV is applicable to Multi-Topology IS-IS (M-ISIS) 299 [RFC5120] capable point-to-point links. If an IS-IS router is 300 configured for M-ISIS it MUST send only a single Reverse Metric TLV 301 in IIH PDU's toward its neighbor(s) on the designated link that is 302 about to undergo maintenance. When an M-ISIS router receives a 303 Reverse Metric TLV it MUST add the received Metric value to its 304 default metric in all Extended IS Reachability TLV's for all 305 topologies. If an M-ISIS router receives a Reverse Metric TLV with a 306 TE Default Metric sub-TLV, then the M-ISIS router MUST add the 307 received TE Default Metric value to each of its TE Default Metric 308 sub-TLV's in all of its MT Intermediate Systems TLV's. If an M-ISIS 309 router is configured to advertise TE Default Metric sub-TLV's for one 310 or more topologies, but does not receive a TE Default Metric sub-TLV 311 in a Reverse Metric TLV, then the M-ISIS router MUST add the value in 312 Metric field of the Reverse Metric TLV to each of the TE Default 313 Metric sub-TLV's for all topologies. The M-ISIS should flood its 314 newly updated MT IS TLV's and recompute its SPF/CSPF accordingly. 316 Multi-Topology IS-IS [RFC5120] specifies there is no change to 317 construction of the Pseudonode LSP, regardless of the Multi-Topology 318 capabilities of a multi-access LAN. If any MT capable node on the 319 LAN advertises the Reverse Metric TLV to the DIS, the DIS should act 320 according to the "Multi-Access LAN Procedures" in Section 3.3 to 321 update, as appropriate, the default metric contained in the 322 Pseudonode LSP. If the DIS updates the default metric in and floods 323 a new Pseudonode LSP, those default metric values will be applied to 324 all topologies during Multi-Topology SPF calculations. 326 3.3. Multi-Access LAN Procedures 328 On a Multi-Access LAN, only the DIS SHOULD act upon information 329 contained in a received Reverse Metric TLV. All non-DIS nodes MUST 330 silently ignore a received Reverse Metric TLV. 332 In the case of multi-access LAN's, the "W" Flags bit is used to 333 signal from a non-DIS to the DIS whether to change the metric and 334 optionally Traffic Engineering parameters for all nodes in the 335 Pseudonode LSP or a single node on the LAN, (the originator of the 336 Reverse Metric TLV). 338 A non-DIS node, e.g.: Router B, attached to a multi-access LAN will 339 send a Reverse Metric TLV with the W bit set to 0 to the DIS, when 340 Router B wishes the DIS to add the Metric value to the default metric 341 contained in the Pseudonode LSP specific to just Router B. Other non- 342 DIS nodes, i.e.: Routers C and D, may simultaneously send a Reverse 343 Metric TLV with the W bit set to 0 to request the DIS add their own 344 Metric value to their default metric contained in the Pseudonode LSP. 345 When the DIS receives a properly formatted Reverse Metric TLV with 346 the W bit set to 0, the DIS MUST only add the default metric 347 contained in its Pseudonode LSP for the specific neighbor that sent 348 the Reverse Metric TLV. 350 It is possible for one node, Router A, to signal to the DIS with the 351 W bit set to 1, in which case the DIS would add the Metric value in 352 the Reverse Metric TLV to all neighbor adjacencies in the Pseudonode 353 LSP and transmit a new Pseudonode LSP to all nodes in the IS-IS 354 domain. Later, a second node on the LAN, Router B, could signal to 355 the DIS with the W bit also set to 1. In this case, the DIS MUST use 356 the highest source MAC address from IIH PDU's containing Reverse 357 Metric TLV's it receives as the tie-breaker to determine the sole 358 Reverse Metric TLV used as the source for the Metric value that will 359 be added to the default metric for all nodes in the Pseudonode LSP. 360 If the source MAC address was highest in IIH PDU's containing a 361 Reverse Metric TLV received from Router B, then the DIS MUST add the 362 Metric value to the default metric of all neighbors in its Pseudonode 363 LSP and flood the LSP to all nodes in the IS-IS domain. On the other 364 hand, if the DIS determines that Router A's IIH PDU's, containing 365 Reverse Metric TLV's, have the highest source MAC address, then the 366 DIS will ignore Router B's Reverse Metric TLV and continue to use the 367 Metric value found in Router A's Reverse Metric TLV to add to the 368 default metric of all neighbors in the Pseudonode LSP. When this 369 occurs, the DIS MAY send a single syslog message or SNMP trap 370 indicating that it has received a Reverse Metric TLV from a neighbor, 371 but is ignoring it due to it being received from a neighbor with a 372 lower MAC address. 374 Another scenario is that one node, Router A, may signal the DIS with 375 the W bit set to 1. The DIS would add the Metric value to the 376 default metric for all neighbors in the Pseudonode LSP and flood the 377 LSP. Later, a second node on the LAN, Router B, could signal the DIS 378 with the W bit set to 0, which indicates to the DIS that Router B is 379 requesting the DIS only add the Metric value in the Reverse Metric 380 TLV from Router B to the default metric for Router B in the 381 Pseudonode LSP. The DIS MUST honor a neighbor's Reverse Metric TLV 382 to update its individual default metric in the Pseudonode LSP even if 383 the DIS receives prior or later requests to assert a Whole LAN metric 384 from other nodes on the same LAN. 386 In all cases above, the DIS is MUST use 0 as the base default-metric 387 value for each neighbor contained in the Pseudonode LSP to which the 388 DIS will add the Metric value in the Reverse Metric TLV(s) it 389 receives from neighbors on the LAN. 391 Local configuration on the DIS to adjust the default metric(s) 392 contained in the Pseudonode LSP, as documented in 393 [I-D.shen-isis-oper-enhance] MUST take precedence over received 394 Reverse Metric TLV's. 396 3.4. Order of Operations 398 When an IS-IS router starts or stops generating a Reverse Metric TLV, 399 it will go through a process of updating its own IS-IS metric and 400 optionally Traffic Engineering parameters in its IS Neighbors TLV, 401 Extended IS Reachbaility TLV or Pseudonode LSP, flooding updated 402 LSP's (using normal IS-IS mechanisms), recompute its SPF/CSPF tree 403 plus corresponding metrics to IP prefixes, update its FIB and begin 404 advertising the Reverse Metric TLV in IIH PDU's toward its 405 corresponding neighbor(s) on the appropriate link or LAN. Likewise, 406 when IS-IS neighbor(s) start or stop receiving a Reverse Metric TLV, 407 they will go through a similar process. It is critical that devices 408 which implement the Reverse Metric TLV conduct this process in a 409 deterministic order that minimizes the possibilities to generate 410 temporary micro forwarding loops during a metric increase and 411 decrease. 413 3.5. Operational Guidelines 415 A router MUST advertise a Reverse Metric TLV toward a neighbor only 416 for the period during which it wants a neighbor to temporarily update 417 its IS-IS metric or TE parameters. 419 During the period when a Reverse Metric TLV is used, IS-IS routers 420 that are generating and receiving a Reverse Metric TLV MUST NOT 421 change their existing IS-IS metric or Traffic Engineering parameters 422 in their stored (e.g.: hard disk, etc.) configurations, since those 423 parameters are carefully derived from off-line capacity planning 424 tools and are difficult to restore to their original values. 426 Routers that receive a Reverse Metric TLV MAY send a syslog message 427 or SNMP trap, in order to assist in rapidly identifying the node in 428 the network that is asserting an IS-IS metric or Traffic Engineering 429 parameters different from that which is configured locally on the 430 device. 432 It is RECOMMENDED that implementations provide a capability to 433 disable any changes to a node's, or individual interfaces of the 434 node, default metric or Traffic Engineering parameters based upon 435 receipt of properly formatted Reverse Metric TLV's. 437 4. Reverse Metric TLV Example Use Case 439 The following is a brief example illustrating one use case of the 440 Reverse Metric TLV. In order to isolate a point-to-point link from 441 the IS-IS network, an operator would configure one router, Router A, 442 attached to a point-to-point link with a "Reverse Metric". This 443 should not affect the configuration of the existing IS-IS default 444 metric previously configured on the router's interface. Assuming 445 Router A is using IS-IS Extensions for Traffic Engineering [RFC5305], 446 this should trigger Router A to update its Traffic Engineering 447 Default Metric sub-TLV in its own Extended IS Reachability TLV, 448 recompute its SPF tree and corresponding metrics to IP prefixes in 449 the IS-IS domain and begin the process of flooding a new LSP 450 throughout the network. Router A would also begin transmitting a 451 Reverse Metric TLV, with an appropriate Metric value, in an IIH PDU, 452 to its adjacent neighbor, Router B. Upon receipt of the Reverse 453 Metric TLV, Router B would add the received Metric or TE default 454 metric sub-TLV value to its own Traffic Engineering Default Metric 455 sub-TLV, recalculate its SPF tree and associated route topology as 456 well as start flooding a new LSP containing the updated Extended IS 457 Reachability TLV throughout the network. As nodes in the network 458 receive the associated LSP's from Router A and B and recalculate a 459 new SPF tree, and route topology, traffic should gracefully shift 460 onto alternate paths away from the A-B link; ultimately, after all 461 nodes in the network recompute their SPF tree link A-B should only be 462 used as a link of last-resort. The operator can inspect traffic 463 counters on the A-B interface to determine if the link was 464 successfully isolated from the topology and proceed with necessary 465 fault diagnosis or maintenance of the associated link. 467 When the maintenance activity is complete, the operator would remove 468 the reverse metric configuration from Router A, which would cease 469 advertisement of the Reverse Metric TLV in IIH PDU's to Router B. 470 Both routers would revert to their originally configured IS-IS 471 metric, recompute new SPF trees and corresponding metrics to IP 472 prefixes and originate new LSP's. As the new LSP's are received and 473 SPF is recalculated by nodes in the IS-IS domain, traffic should 474 gradually shift back onto link A-B. 476 5. Operational Considerations 478 Since the Reverse Metric TLV may not be recognized by adjacent IS-IS 479 neighbors, operators should inspect input and output traffic 480 throughput counters on the local router to ensure that traffic has 481 bidirectionally shifted away from a link before starting any 482 maintenance activities. 484 6. Security Considerations 486 The enhancement in this document makes it possible for one IS-IS 487 router to manipulate the IS-IS default metric or optionally Traffic 488 Engineering parameters of adjacent IS-IS neighbors. Although IS-IS 489 routers within a single Autonomous System nearly always reside under 490 the control of a single administrative authority, it is highly 491 RECOMMENDED that operators configure authentication of IS-IS PDU's to 492 mitigate use of the Reverse Metric TLV as a potential attack vector, 493 particularly on multi-access LAN's. 495 7. IANA Considerations 497 This document requests that IANA allocate from the IS-IS TLV 498 Codepoints Registry a new TLV, referred to as the "Reverse Metric" 499 TLV, with the following attributes: IIH = y, LSP = n, SNP = n, Purge 500 = n. 502 8. Acknowledgements 504 The authors would like to thank Mike Shand, Dave Katz, Guan Deng, 505 Ilya Varlashkin, Jay Chen, Les Ginsberg and Peter Ashwood-Smith, 506 Jonathan Harrison, Dave Ward and Himanshu Shah for their 507 contributions. 509 9. References 510 9.1. Normative References 512 [ISO 10589] 513 ISO, "Intermediate system to Intermediate system routeing 514 information exchange protocol for use in conjunction with 515 the Protocol for providing the Connectionless-mode Network 516 Service (ISO 8473)", ISO/IEC 10589:2002. 518 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 519 dual environments", RFC 1195, December 1990. 521 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 522 Requirement Levels", BCP 14, RFC 2119, March 1997. 524 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 525 Topology (MT) Routing in Intermediate System to 526 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 528 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 529 Engineering", RFC 5305, October 2008. 531 9.2. Informative References 533 [I-D.shen-isis-oper-enhance] 534 Shen, N., Li, T., Amante, S., and M. Abrahamsson, "IS-IS 535 Operational Enhancements for Network Maintenance Events", 536 draft-shen-isis-oper-enhance-00 (work in progress), 537 October 2010. 539 Authors' Addresses 541 Naiming Shen 542 Cisco Systems, Inc. 543 225 West Tasman Drive 544 San Jose, CA 95134 545 USA 547 Email: naiming@cisco.com 548 Tony Li 549 Cisco Systems, Inc. 550 225 West Tasman Drive 551 San Jose, CA 95134 552 USA 554 Email: tli@cisco.com 556 Shane Amante 557 Level 3 Communications 558 1025 Eldorado Blvd 559 Broomfield, CO 80021 560 USA 562 Email: shane@level3.net 564 Mikael Abrahamsson 565 Tele2 567 Email: swmike@swm.pp.se