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