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