idnits 2.17.1 draft-amante-isis-reverse-metric-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 13, 2011) is 4783 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: September 14, 2011 S. Amante 6 Level 3 Communications 7 M. Abrahamsson 8 Tele2 9 March 13, 2011 11 IS-IS Reverse Metric TLV for Network Maintenance Events 12 draft-amante-isis-reverse-metric-02 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 September 14, 2011. 41 Copyright Notice 43 Copyright (c) 2011 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. Node Isolation Challenges . . . . . . . . . . . . . . . . 3 60 1.2. Link Isolation Challenges . . . . . . . . . . . . . . . . 3 61 1.3. IS-IS Reverse Metric . . . . . . . . . . . . . . . . . . . 4 62 1.4. Specification of Requirements . . . . . . . . . . . . . . 5 64 2. IS-IS Reverse Metric TLV . . . . . . . . . . . . . . . . . . . 5 66 3. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 6 67 3.1. Processing Changes to Default Metric . . . . . . . . . . . 6 68 3.2. Processing Changes to Default Metric for 69 Multi-Topology IS-IS . . . . . . . . . . . . . . . . . . . 8 70 3.3. Multi-Access LAN Procedures . . . . . . . . . . . . . . . 8 71 3.4. Order of Operations . . . . . . . . . . . . . . . . . . . 10 72 3.5. Operational Guidelines . . . . . . . . . . . . . . . . . . 10 74 4. Reverse Metric TLV Example Use Cases . . . . . . . . . . . . . 11 76 5. Operational Considerations . . . . . . . . . . . . . . . . . . 11 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 82 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 86 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 90 1. Introduction 92 The IS-IS [ISO 10589] routing protocol has been widely used in 93 Internet Service Provider IP/MPLS networks. Operational experience 94 with the protocol, combined with ever increasing requirements for 95 lossless operations have demonstrated some operational issues. This 96 document describes one issue and a new mechanism for improving it. 98 1.1. Node Isolation Challenges 100 On rare occasions it is necessary for an operator to perform 101 disruptive network maintenance on an entire IS-IS router node, i.e.: 102 major software upgrades, power/cooling augments, etc. In these 103 cases, an operator will set the IS-IS Overload Bit (OL-bit) within 104 the Link State Protocol Data Units (LSP's) of the IS-IS router about 105 to undergo maintenance. The IS-IS router immediately floods the 106 updated LSP's to all IS-IS routers throughout the IS-IS domain. Upon 107 receipt of the updated LSP's, all IS-IS routers recalculate their 108 Shortest Path First (SPF) tree excluding IS-IS routers whose LSP's 109 have the OL-bit set. This effectively removes the IS-IS router about 110 to undergo maintenance from the topology, thus preventing it from 111 forwarding any transit traffic during the maintenance period. 113 After the maintenance activity is completed, the operator resets the 114 IS-IS Overload Bit within the LSP's of the original IS-IS router 115 causing it to flood updated IS-IS LSP's throughout the IS-IS domain. 116 All IS-IS routers recalculate their SPF tree and now include the 117 original IS-IS router in their topology calculations, allowing it to 118 be used for transit traffic again. 120 Isolating an entire IS-IS router from the topology can be especially 121 disruptive due to the displacement of a large volume of traffic 122 through an entire IS-IS router to other, sub-optimal paths, (i.e.: 123 those with significantly larger delay). Thus, in the majority of 124 network maintenance scenarios, where only a single link or LAN needs 125 to be augmented to increase its physical capacity or is experiencing 126 an intermittent failure, it is much more common and desirable to 127 gracefully remove just the targeted link or LAN from service, 128 temporarily, so that the least amount of user-data traffic is 129 affected while intrusive augment, diagnostic and/or replacement 130 procedures are being executed. 132 1.2. Link Isolation Challenges 134 Before network maintenance events are performed on individual 135 physical links or LAN's, operators substantially increase the IS-IS 136 metric simultaneously on both devices attached to the same link or 137 LAN. In doing so, the devices generate new Link State Protocol Data 138 Units (LSP's) that are flooded throughout the network and cause all 139 routers to gradually shift traffic onto alternate paths with very 140 little, to no, disruption to in-flight communications by applications 141 or end-users. When performed successfully, this allows the operator 142 to confidently perform disruptive augmentation, fault diagnosis or 143 repairs on a link without disturbing ongoing communications in the 144 network. 146 The challenge with the above solution are as follows. First, it is 147 quite common to have routers with several hundred interfaces onboard 148 and individual interfaces that are transferring several hundred 149 Gigabits/second to Terabits/second of traffic. Thus, it is 150 imperative that operators accurately identify the same point-to-point 151 link on two, separate devices in order to increase (and, afterward, 152 decrease) the IS-IS metric appropriately. Second, the aforementioned 153 solution is very time consuming and even more error-prone to perform 154 when its necessary to temporarily remove a multi-access LAN from the 155 network topology. Specifically, the operator needs to configure ALL 156 devices's that have interfaces attached to the multi-access LAN with 157 an appropriately high IS-IS metric, (and then decrease the IS-IS 158 metric to its original value afterward). Finally, with respect to 159 multi-access LAN's, there is currently no method to bidirectionally 160 isolate only a single node's interface on the LAN when performed more 161 fine-grained diagnosis and repairs to the multi-access LAN. 163 In theory, use of a Network Management System (NMS) could improve the 164 accuracy of identifying the appropriate subset of routers attached to 165 either a point-to-point link or a multi-access LAN as well as 166 signaling from the NMS to those devices, using a network management 167 protocol, to adjust the IS-IS metrics on the pertinent set of 168 interfaces. The reality is that NMS are, to a very large extent, not 169 used within Service Provider's networks for a variety of reasons. In 170 particular, NMS do not interoperate very well across different 171 vendors or even separate platform families within the same vendor. 173 The risks of misidentifying one side of a point-to-point link or one 174 or more interfaces attached to a multi-access LAN and subsequently 175 increasing its IS-IS metric are potentially increased latency, jitter 176 or packet loss. This is unacceptable given the necessary performance 177 requirements for a variety of applications, the customer perception 178 for near lossless operations and the associated, demanding Service 179 Level Agreement's (SLA's) for all network services. 181 1.3. IS-IS Reverse Metric 183 This document proposes that the routing protocol itself be the 184 transport mechanism to allow one IS-IS router to advertise to an 185 adjacent node on a point-to-point or multi-access LAN link a "reverse 186 metric" in a IS-IS Hello (IIH) PDU. This would allow an operator to 187 only configure a single router, set a "reverse metric" on a link and 188 have traffic bidirectionally shift away from that link gracefully to 189 alternate, viable paths. 191 1.4. Specification of Requirements 193 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 194 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 195 document are to be interpreted as described in [RFC2119]. 197 2. IS-IS Reverse Metric TLV 199 The Reverse Metric TLV is composed of 1 octet for the Type, 1 octet 200 that specifies the number of bytes in the Value field and a variable- 201 length Value field. The Value field starts with a 1 octet field of 202 Flags followed by a 3 octet field containing an IS-IS Metric and, 203 lastly, a 1 octet Traffic Engineering (TE) sub-TLV length field 204 representing the length of a variable number of Extended Intermediate 205 System (IS) Reachability sub-TLV's. If the 'S' bit in the Flags 206 field is set to 1, then the Value field MUST also contain data of 1 207 or more Extended IS Reachability sub-TLV's. 209 The Reverse Metric TLV is optional. The Reverse Metric TLV may be 210 present in any IS-IS Hello PDU. A sender MUST only transmit a single 211 Reverse Metric TLV in a IS-IS Hello PDU. 213 TYPE: TBD 214 LENGTH: variable (5 - 255 octets) 215 VALUE: 216 Flags (1 octet) 217 Metric (3 octets) 218 TE sub-TLV length (1 octet) 219 TE sub-TLV data (0 - 250 octets) 221 Flags 223 0 1 2 3 4 5 6 7 224 +-+-+-+-+-+-+-+-+ 225 | Reserved |S|W| 226 +-+-+-+-+-+-+-+-+ 228 Figure 1: Flags 230 The Reverse Metric TLV Type is TBD. Please refer to IANA 231 Considerations, in Section 7, for more details. 233 The Metric field contains a 24-bit unsigned integer of an IS-IS 234 metric a neighbor SHOULD add to the existing, configured "default 235 metric" contained within its IS Neighbors TLV or Extended IS 236 Reachability TLV's for point-to-point links, or Pseudonode LSP by the 237 Designated Intermediate System (DIS) for multi-access LAN's, back 238 toward the router that originated this Reverse Metric TLV. Refer to 239 "Elements of Procedure", below in Section 3, for details of how an 240 IS-IS router should process the Metric field in a Reverse Metric TLV. 242 There is currently only two Flag bits defined. 244 W bit (0x01): The "Whole LAN" bit is only used in the context of 245 multi-access LAN's. When a Reverse Metric TLV is transmitted from a 246 (non-DIS) node to the DIS, if the "Whole LAN" bit is set (1), then a 247 DIS SHOULD add the received Metric value in the Reverse Metric TLV to 248 each node's existing "default metric" in the Pseudonode LSP. If the 249 "Whole LAN" bit is not set (0), then a DIS SHOULD add the received 250 Metric value in the Reverse Metric TLV to the existing "default 251 metric" in the Pseudonode LSP for the single node from whom the 252 Reverse Metric TLV was received. Please refer to "Multi-Access LAN 253 Procedures", in Section 3.3, for additional details. The W bit MUST 254 be unset (0) when a Reverse Metric TLV is transmitted in a IIH PDU 255 onto a point-to-point link to an IS-IS neighbor. 257 S bit (0x02): The "TE sub-TLV" bit MUST be set (1) when an IS-IS 258 router wishes to signal that its neighbor alter parameters contained 259 in the neighbor's Traffic Engineering "Extended IS Reachability TLV", 260 as defined in [RFC5305]. This document defines that only the 261 "Traffic Engineering Default Metric" sub-TLV, sub-TLV Type 18, may be 262 sent toward neighbors in the Reverse Metric TLV, because that is used 263 in Constrained Shortest Path First (CSPF) computations. Upon receipt 264 of this TE sub-TLV in a Reverse Metric TLV, a node SHOULD add the 265 received TE default metric to its existing, configured TE default 266 metric within its Extended IS Reachability TLV. Use of other sub- 267 TLV's is outside the scope of this document. 269 The S bit MUST NOT be set (0) when an IS-IS router does not have TE 270 sub-TLV's that it wishes to send to its IS-IS neighbor. 272 3. Elements of Procedure 274 3.1. Processing Changes to Default Metric 276 The Metric field, in the Reverse Metric TLV, is a "default metric" 277 that will either be in the range of 0 - 63 when a "narrow" IS-IS 278 metric is used (IS Neighbors TLV, Pseudonode LSP) [RFC1195] or in the 279 range of 0 - (2^24 - 2) when a "wide" Traffic Engineering metric 280 value is used, (Extended IS Reachability TLV) [RFC5305]. It is 281 RECOMMENDED that implementations, by default, place the appropriate 282 maximum default metric value, 63 or (2^24 - 2), in the Metric field 283 and TE Default Metric sub-TLV of the Reverse Metric TLV, since the 284 most common use is to remove the link from the topology, except for 285 use as a last-resort path. 287 In order to ensure that an individual TE link is used as a link of 288 last resort during SPF computation, its metric MUST NOT be greater 289 than or equal to (2^24 - 1) [RFC5305]. Therefore, a receiver of a 290 Reverse Metric TLV MUST use the numerically smallest value of either 291 the sum of its existing default metric and the Metric value in the 292 Reverse Metric TLV or (2^24 - 2), as the default metric when updating 293 its Extended IS Reachability TLV and TE default-metric sub-TLV's that 294 it will then flood throughout the IS-IS domain, using normal IS-IS 295 procedures. Likewise, originators of a Pseudonode LSP or IS 296 Neighbors TLV MUST use the numerically smallest value of either the 297 sum of its existing default metric and the Metric value it receives 298 in a Reverse Metric TLV or 63 when updating the corresponding 299 Pseudonode LSP or IS Neighbor TLV before they are flooded. This also 300 applies when an IS-IS router is only configured or capable of sending 301 a "narrow" IS-IS default metric, in the range of 0 - 63, but receives 302 a "wide" Metric value in a Reverse Metric TLV, in the range of 64 - 303 (2^24 - 2). In this case, the receiving router MUST use the maximum 304 "narrow" IS-IS default metric, 63, as its IS-IS default metric value 305 in its updated IS Neighbor TLV or Pseudonode LSP that it floods. 307 If an IS-IS router is configured to originate a TE Default Metric 308 sub-TLV for a link, but receives a Reverse Metric TLV from its 309 neighbor that does not contain a TE Default Metric sub-TLV, then the 310 IS-IS router MUST add the value in the Metric field of the Reverse 311 Metric TLV to its own TE Default Metric sub-TLV for that link. The 312 IS-IS router should then flood the updated Extended IS Reachability 313 TLV, including its updated TE Default Metric sub-TLV, using normal 314 IS-IS procedures. 316 Routers MUST scan the Metric value and TE sub-TLV's in all 317 subsequently received Reverse Metric TLV's. If changes are observed 318 by a receiver of the Reverse Metric TLV in the Metric value or TE 319 Default Metric sub-TLV value, the receiving router MUST update its 320 advertised IS-IS default metric or Traffic Engineering parameters in 321 the appropriate TLV's, recompute its SPF tree and flood new LSP's to 322 other IS-IS routers, according to the recommendations outlined in 323 Section 3.4, Order of Operations, below. 325 If the router does not understand the Reverse Metric TLV or is 326 explicitly configured to ignore received Reverse Metric TLV's, then 327 it MUST NOT update the default metric in its IS Neighbors TLV, 328 Extended IS Reachability TLV, TE Default Metric sub-TLV, Multi- 329 Topology Intermediate Systems TLV or Pseudonode LSP nor execute other 330 procedures that would result from acting on a Reverse Metric TLV, 331 such as recomputing its SPF tree. 333 3.2. Processing Changes to Default Metric for Multi-Topology IS-IS 335 The Reverse Metric TLV is applicable to Multi-Topology IS-IS (M-ISIS) 336 [RFC5120] capable point-to-point links. If an IS-IS router is 337 configured for M-ISIS it MUST send only a single Reverse Metric TLV 338 in IIH PDU's toward its neighbor(s) on the designated link that is 339 about to undergo maintenance. When an M-ISIS router receives a 340 Reverse Metric TLV it MUST add the received Metric value to its 341 default metric in all Extended IS Reachability TLV's for all 342 topologies. If an M-ISIS router receives a Reverse Metric TLV with a 343 TE Default Metric sub-TLV, then the M-ISIS router MUST add the 344 received TE Default Metric value to each of its TE Default Metric 345 sub-TLV's in all of its MT Intermediate Systems TLV's. If an M-ISIS 346 router is configured to advertise TE Default Metric sub-TLV's for one 347 or more topologies, but does not receive a TE Default Metric sub-TLV 348 in a Reverse Metric TLV, then the M-ISIS router MUST add the value in 349 Metric field of the Reverse Metric TLV to each of the TE Default 350 Metric sub-TLV's for all topologies. The M-ISIS should flood its 351 newly updated MT IS TLV's and recompute its SPF/CSPF accordingly. 353 Multi-Topology IS-IS [RFC5120] specifies there is no change to 354 construction of the Pseudonode LSP, regardless of the Multi-Topology 355 capabilities of a multi-access LAN. If any MT capable node on the 356 LAN advertises the Reverse Metric TLV to the DIS, the DIS should act 357 according to the "Multi-Access LAN Procedures" in Section 3.3 to 358 update, as appropriate, the default metric contained in the 359 Pseudonode LSP. If the DIS updates the default metric in and floods 360 a new Pseudonode LSP, those default metric values will be applied to 361 all topologies during Multi-Topology SPF calculations. 363 3.3. Multi-Access LAN Procedures 365 On a Multi-Access LAN, only the DIS SHOULD act upon information 366 contained in a received Reverse Metric TLV. All non-DIS nodes MUST 367 silently ignore a received Reverse Metric TLV. 369 In the case of multi-access LAN's, the "W" Flags bit is used to 370 signal from a non-DIS to the DIS whether to change the metric and 371 optionally Traffic Engineering parameters for all nodes in the 372 Pseudonode LSP or a single node on the LAN, (the originator of the 373 Reverse Metric TLV). 375 A non-DIS node, e.g.: Router B, attached to a multi-access LAN will 376 send a Reverse Metric TLV with the W bit set to 0 to the DIS, when 377 Router B wishes the DIS to add the Metric value to the default metric 378 contained in the Pseudonode LSP specific to just Router B. Other non- 379 DIS nodes, i.e.: Routers C and D, may simultaneously send a Reverse 380 Metric TLV with the W bit set to 0 to request the DIS add their own 381 Metric value to their default metric contained in the Pseudonode LSP. 382 When the DIS receives a properly formatted Reverse Metric TLV with 383 the W bit set to 0, the DIS MUST only add the default metric 384 contained in its Pseudonode LSP for the specific neighbor that sent 385 the Reverse Metric TLV. 387 It is possible for one node, Router A, to signal to the DIS with the 388 W bit set to 1, in which case the DIS would add the Metric value in 389 the Reverse Metric TLV to all neighbor adjacencies in the Pseudonode 390 LSP and transmit a new Pseudonode LSP to all nodes in the IS-IS 391 domain. Later, a second node on the LAN, Router B, could signal to 392 the DIS with the W bit also set to 1. In this case, the DIS MUST use 393 the highest source MAC address from IIH PDU's containing Reverse 394 Metric TLV's it receives as the tie-breaker to determine the sole 395 Reverse Metric TLV used as the source for the Metric value that will 396 be added to the default metric for all nodes in the Pseudonode LSP. 397 If the source MAC address was highest in IIH PDU's containing a 398 Reverse Metric TLV received from Router B, then the DIS MUST add the 399 Metric value to the default metric of all neighbors in its Pseudonode 400 LSP and flood the LSP to all nodes in the IS-IS domain. On the other 401 hand, if the DIS determines that Router A's IIH PDU's, containing 402 Reverse Metric TLV's, have the highest source MAC address, then the 403 DIS will ignore Router B's Reverse Metric TLV and continue to use the 404 Metric value found in Router A's Reverse Metric TLV to add to the 405 default metric of all neighbors in the Pseudonode LSP. When this 406 occurs, the DIS MAY send a single syslog message or SNMP trap 407 indicating that it has received a Reverse Metric TLV from a neighbor, 408 but is ignoring it due to it being received from a neighbor with a 409 lower MAC address. 411 Another scenario is that one node, Router A, may signal the DIS with 412 the W bit set to 1. The DIS would add the Metric value to the 413 default metric for all neighbors in the Pseudonode LSP and flood the 414 LSP. Later, a second node on the LAN, Router B, could signal the DIS 415 with the W bit set to 0, which indicates to the DIS that Router B is 416 requesting the DIS only add the Metric value in the Reverse Metric 417 TLV from Router B to the default metric for Router B in the 418 Pseudonode LSP. The DIS MUST honor a neighbor's Reverse Metric TLV 419 to update its individual default metric in the Pseudonode LSP even if 420 the DIS receives prior or later requests to assert a Whole LAN metric 421 from other nodes on the same LAN. 423 In all cases above, the DIS is MUST use 0 as the base default-metric 424 value for each neighbor contained in the Pseudonode LSP to which the 425 DIS will add the Metric value in the Reverse Metric TLV(s) it 426 receives from neighbors on the LAN. 428 Local configuration on the DIS to adjust the default metric(s) 429 contained in the Pseudonode LSP, as documented in 430 [I-D.shen-isis-oper-enhance] MUST take precedence over received 431 Reverse Metric TLV's. 433 3.4. Order of Operations 435 When an IS-IS router starts or stops generating a Reverse Metric TLV, 436 it will go through a process of updating its own IS-IS metric and 437 optionally Traffic Engineering parameters in its IS Neighbors TLV, 438 Extended IS Reachbaility TLV or Pseudonode LSP, flooding updated 439 LSP's (using normal IS-IS mechanisms), recompute its SPF/CSPF tree 440 plus corresponding metrics to IP prefixes, update its FIB and begin 441 advertising the Reverse Metric TLV in IIH PDU's toward its 442 corresponding neighbor(s) on the appropriate link or LAN. Likewise, 443 when IS-IS neighbor(s) start or stop receiving a Reverse Metric TLV, 444 they will go through a similar process. It is critical that devices 445 which implement the Reverse Metric TLV conduct this process in a 446 deterministic order that minimizes the possibilities to generate 447 temporary micro forwarding loops during a metric increase and 448 decrease. 450 3.5. Operational Guidelines 452 A router MUST advertise a Reverse Metric TLV toward a neighbor only 453 for the period during which it wants a neighbor to temporarily update 454 its IS-IS metric or TE parameters. 456 During the period when a Reverse Metric TLV is used, IS-IS routers 457 that are generating and receiving a Reverse Metric TLV MUST NOT 458 change their existing IS-IS metric or Traffic Engineering parameters 459 in their stored (e.g.: hard disk, etc.) configurations, since those 460 parameters are carefully derived from off-line capacity planning 461 tools and are difficult to restore to their original values. 463 Routers that receive a Reverse Metric TLV MAY send a syslog message 464 or SNMP trap, in order to assist in rapidly identifying the node in 465 the network that is asserting an IS-IS metric or Traffic Engineering 466 parameters different from that which is configured locally on the 467 device. 469 It is RECOMMENDED that implementations provide a capability to 470 disable any changes to a node's, or individual interfaces of the 471 node, default metric or Traffic Engineering parameters based upon 472 receipt of properly formatted Reverse Metric TLV's. 474 4. Reverse Metric TLV Example Use Cases 476 The following is a brief example illustrating one use case of the 477 Reverse Metric TLV. In order to isolate a point-to-point link from 478 the IS-IS network, an operator would configure one router, Router A, 479 attached to a point-to-point link with a "Reverse Metric". This 480 should not affect the configuration of the existing IS-IS default 481 metric previously configured on the router's interface. Assuming 482 Router A is using IS-IS Extensions for Traffic Engineering [RFC5305], 483 this should trigger Router A to update its Traffic Engineering 484 Default Metric sub-TLV in its own Extended IS Reachability TLV, 485 recompute its SPF tree and corresponding metrics to IP prefixes in 486 the IS-IS domain and begin the process of flooding a new LSP 487 throughout the network. Router A would also begin transmitting a 488 Reverse Metric TLV, with an appropriate Metric value, in an IIH PDU, 489 to its adjacent neighbor, Router B. Upon receipt of the Reverse 490 Metric TLV, Router B would add the received Metric or TE default 491 metric sub-TLV value to its own Traffic Engineering Default Metric 492 sub-TLV, recalculate its SPF tree and associated route topology as 493 well as start flooding a new LSP containing the updated Extended IS 494 Reachability TLV throughout the network. As nodes in the network 495 receive the associated LSP's from Router A and B and recalculate a 496 new SPF tree, and route topology, traffic should gracefully shift 497 onto alternate paths away from the A-B link; ultimately, after all 498 nodes in the network recompute their SPF tree link A-B should only be 499 used as a link of last-resort. The operator can inspect traffic 500 counters on the A-B interface to determine if the link was 501 successfully isolated from the topology and proceed with necessary 502 fault diagnosis or maintenance of the associated link. 504 When the maintenance activity is complete, the operator would remove 505 the reverse metric configuration from Router A, which would cease 506 advertisement of the Reverse Metric TLV in IIH PDU's to Router B. 507 Both routers would revert to their originally configured IS-IS 508 metric, recompute new SPF trees and corresponding metrics to IP 509 prefixes and originate new LSP's. As the new LSP's are received and 510 SPF is recalculated by nodes in the IS-IS domain, traffic should 511 gradually shift back onto link A-B. 513 5. Operational Considerations 515 Since the Reverse Metric TLV may not be recognized by adjacent IS-IS 516 neighbors, operators should inspect input and output traffic 517 throughput counters on the local router to ensure that traffic has 518 bidirectionally shifted away from a link before starting any 519 maintenance activities. 521 6. Security Considerations 523 The enhancement in this document makes it possible for one IS-IS 524 router to manipulate the IS-IS default metric or optionally Traffic 525 Engineering parameters of adjacent IS-IS neighbors. Although IS-IS 526 routers within a single Autonomous System nearly always reside under 527 the control of a single administrative authority, it is highly 528 RECOMMENDED that operators configure authentication of IS-IS PDU's to 529 mitigate use of the Reverse Metric TLV as a potential attack vector, 530 particularly on multi-access LAN's. 532 7. IANA Considerations 534 This document requests that IANA allocate from the IS-IS TLV 535 Codepoints Registry a new TLV, referred to as the "Reverse Metric" 536 TLV, with the following attributes: IIH = y, LSP = n, SNP = n, Purge 537 = n. 539 8. Acknowledgements 541 The authors would like to thank Mike Shand, Dave Katz, Guan Deng, 542 Ilya Varlashkin, Jay Chen, Les Ginsberg and Peter Ashwood-Smith, 543 Jonathan Harrison, Dave Ward, Himanshu Shah and Wes George for their 544 contributions. 546 9. References 548 9.1. Normative References 550 [ISO 10589] 551 ISO, "Intermediate system to Intermediate system routeing 552 information exchange protocol for use in conjunction with 553 the Protocol for providing the Connectionless-mode Network 554 Service (ISO 8473)", ISO/IEC 10589:2002. 556 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 557 dual environments", RFC 1195, December 1990. 559 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 560 Requirement Levels", BCP 14, RFC 2119, March 1997. 562 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 563 Topology (MT) Routing in Intermediate System to 564 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 566 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 567 Engineering", RFC 5305, October 2008. 569 9.2. Informative References 571 [I-D.shen-isis-oper-enhance] 572 Shen, N., Li, T., Amante, S., and M. Abrahamsson, "IS-IS 573 Operational Enhancements for Network Maintenance Events", 574 draft-shen-isis-oper-enhance-00 (work in progress), 575 October 2010. 577 Authors' Addresses 579 Naiming Shen 580 Cisco Systems, Inc. 581 225 West Tasman Drive 582 San Jose, CA 95134 583 USA 585 Email: naiming@cisco.com 587 Tony Li 588 Cisco Systems, Inc. 589 225 West Tasman Drive 590 San Jose, CA 95134 591 USA 593 Email: tli@cisco.com 595 Shane Amante 596 Level 3 Communications 597 1025 Eldorado Blvd 598 Broomfield, CO 80021 599 USA 601 Email: shane@level3.net 602 Mikael Abrahamsson 603 Tele2 605 Email: swmike@swm.pp.se