idnits 2.17.1 draft-ietf-isis-mrt-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 (June 30, 2017) is 2491 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) == Missing Reference: 'ISO10589' is mentioned on line 96, but not defined == Missing Reference: 'RFC1195' is mentioned on line 562, but not defined == Missing Reference: 'RFC5308' is mentioned on line 583, but not defined == Missing Reference: 'RFC2119' is mentioned on line 566, but not defined == Missing Reference: 'RFC4971' is mentioned on line 571, but not defined ** Obsolete undefined reference: RFC 4971 (Obsoleted by RFC 7981) -- Looks like a reference, but probably isn't: '0' on line 274 -- Looks like a reference, but probably isn't: '255' on line 274 == Missing Reference: 'I-D.ietf-ospf-mrt' is mentioned on line 557, but not defined == Missing Reference: 'RFC5120' is mentioned on line 577, but not defined == Missing Reference: 'RFC5715' is mentioned on line 587, but not defined == Missing Reference: 'I-D.atlas-bryant-shand-lf-timers' is mentioned on line 552, but not defined ** Downref: Normative reference to an Informational RFC: RFC 3787 Summary: 2 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Li 3 Internet-Draft N. Wu 4 Intended status: Standards Track Q. Zhao 5 Expires: January 1, 2018 Huawei Technologies 6 A. Atlas 7 C. Bowers 8 Juniper Networks 9 J. Tantsura 10 Individual 11 June 30, 2017 13 Intermediate System to Intermediate System (IS-IS) Extensions for 14 Maximally Redundant Trees (MRT) 15 draft-ietf-isis-mrt-03 17 Abstract 19 This document describes extensions to IS-IS to support the 20 distributed computation of Maximally Redundant Trees (MRT). Example 21 uses of MRT include IP/LDP Fast-Reroute and global protection or 22 live-live for multicast traffic. The extensions indicate what MRT 23 profile(s) each router supports. Different MRT profiles can be 24 defined to support different uses and to allow transition of 25 capabilities. An extension is introduced to flood MRT-Ineligible 26 links, due to administrative policy. This document also defines the 27 Controlled Convergence sub-TLV, which is useful for MRT FRR as well 28 as other applications. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 1, 2018. 47 Copyright Notice 49 Copyright (c) 2017 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 66 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 4. Overview of IS-IS Signalling Extensions for MRT . . . . . . . 4 68 4.1. Supporting MRT Profiles . . . . . . . . . . . . . . . . . 4 69 4.2. Selecting the GADAG Root . . . . . . . . . . . . . . . . 4 70 4.3. Advertising MRT-Ineligible Links for MRT . . . . . . . . 5 71 4.4. Triggering an MRT Computation . . . . . . . . . . . . . . 5 72 5. MRT Capability Advertisement . . . . . . . . . . . . . . . . 5 73 5.1. MRT Profile sub-TLV in the IS-IS Router CAPABILITY TLV . 6 74 5.1.1. A note on the M-bit in OSPF . . . . . . . . . . . . . 7 75 5.2. MRT-Ineligible Link sub-TLV in the Extended IS 76 Reachability TLV . . . . . . . . . . . . . . . . . . . . 7 77 5.3. A Note on Multi-Topology Routing . . . . . . . . . . . . 8 78 6. Controlled Convergence sub-TLV in IS-IS Router CAPABILITY TLV 8 79 7. Handling MRT Extensions . . . . . . . . . . . . . . . . . . . 10 80 7.1. Advertising MRT extensions . . . . . . . . . . . . . . . 10 81 7.2. Processing MRT extensions . . . . . . . . . . . . . . . . 10 82 8. Backward Compatibility . . . . . . . . . . . . . . . . . . . 10 83 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 11 84 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 85 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 86 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 87 12.1. MRT Profile and Controlled Convergence sub-TLVs . . . . 11 88 12.2. MRT-Ineligible Link sub-TLV . . . . . . . . . . . . . . 11 89 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 90 13.1. Normative References . . . . . . . . . . . . . . . . . . 12 91 13.2. Infomative References . . . . . . . . . . . . . . . . . 12 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 94 1. Introduction 96 The IS-IS protocol is specified in [ISO10589], with extensions for 97 supporting IPv4 and IPv6 specified in [RFC1195] and [RFC5308]. Each 98 Intermediate System (IS) (router) advertises one or more IS-IS Link 99 State Protocol Data Units (LSPs) with routing information. Each LSP 100 is composed of a fixed header and a number of tuples, each consisting 101 of a Type, a Length, and a Value. Such tuples are commonly known as 102 TLVs, and are a good way of encoding information in a flexible and 103 extensible format. 105 [RFC7812] gives a complete solution for IP/LDP fast-reroute using 106 Maximally Redundant Trees (MRT) to provide alternates. This document 107 describes signalling extensions for supporting MRT-FRR in an IS-IS 108 routing domain. 110 2. Requirements Language 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 3. Terminology 118 Redundant Trees (RT): A pair of trees where the path from any node X 119 to the root R along the first tree is node-disjoint with the path 120 from the same node X to the root R along the second tree. These can 121 be computed in 2-connected graphs. 123 Maximally Redundant Trees (MRT): A pair of trees where the path from 124 any node X to the root R along the first tree and the path from the 125 same node X to the root R along the second tree share the minimum 126 number of nodes and the minimum number of links. Each such shared 127 node is a cut-vertex. Any shared links are cut-links. Any RT is an 128 MRT but many MRTs are not RTs. 130 MRT Island: From the computing router, the set of routers that 131 support a particular MRT profile and are connected via MRT- eligible 132 links. 134 GADAG: Generalized Almost Directed Acyclic Graph - a graph which is 135 the combination of the ADAGs of all blocks. Transforming a network 136 graph into a GADAG is part of the MRT algorithm. 138 MRT-Red: MRT-Red is used to describe one of the two MRTs; it is used 139 to describe the associated forwarding topology and MT-ID. 140 Specifically, MRT-Red is the decreasing MRT where links in the GADAG 141 are taken in the direction from a higher topologically ordered node 142 to a lower one. 144 MRT-Blue: MRT-Blue is used to describe one of the two MRTs; it is 145 used to describe the associated forwarding topology and MT-ID. 146 Specifically, MRT-Blue is the increasing MRT where links in the GADAG 147 are taken in the direction from a lower topologically ordered node to 148 a higher one. 150 4. Overview of IS-IS Signalling Extensions for MRT 152 As stated in [RFC7811], it is necessary for each MRT-Capable router 153 to compute MRT next hops in a consistent fashion. This is achieved 154 by using the same MRT profile and selecting a common and unique GADAG 155 root in the MRT Island which is connected by MRT-Eligible links. 156 Each of these issues will be discussed in the following sections 157 separately. 159 4.1. Supporting MRT Profiles 161 The contents and requirements of an MRT profile has been defined in 162 [RFC7812]. The parameters and behavioral rules contained in an MRT 163 profile define one router's MRT capabilities. Based on common 164 capabilities, one unified MRT Island is built. 166 The MRT-Capable router MUST advertise its corresponding MRT profiles 167 by IS-IS protocol extension within IS-IS routing domain. The 168 capabilities of the advertiser MUST completely conform to the profile 169 it claimed, including the MT-IDs, the algorithm and the corresponding 170 forwarding mechanism. This advertisement MUST have level scope. A 171 given router MAY support multiple MRT profiles. If so, it MUST 172 advertise each of these profiles in the corresponding IS-IS level. 174 The default MRT Profile is defined in [RFC7812]. Its behavior is 175 intended to support IP/LDP unicast and multicast Fast-Reroute. MRT- 176 Capable routers SHOULD support the default MRT profile. 178 4.2. Selecting the GADAG Root 180 As per [RFC7811], a GADAG root MUST be selected for one MRT Island. 181 An unique GADAG root in common among MRT Island routers is a 182 necessity to do MRT computation. Since the selection of the GADAG 183 root can affect the quality of paths for traffic sent over MRT Red 184 and Blue trees, the GADAG Root Selection Priority and the GADAG Root 185 Selection Policy gives a network operator the ability to influence 186 the selection of the GADAG root. 188 Each MRT-Capable router MUST advertise its priority for GADAG root 189 selection. A router can only have one priority in a given MRT 190 Island. It can have multiple priorities for different MRT Islands it 191 supports. Routers that are marked as overloaded([RFC3787]) are not 192 qualified as candidate for root selection. 194 The GADAG Root Selection Policy (defined as part of an MRT profile) 195 may make use of the GADAG Root Selection Priority value advertised in 196 the MRT Profile in the IS-IS Router CAPABILITY TLV. For example, the 197 GADAG Root Selection Policy for the default MRT profile is the 198 following: Among the routers in the MRT Island and with the highest 199 priority advertised, an implementation MUST pick the router with the 200 highest Router ID to be the GADAG root. 202 When the current root is out of service or new router with higher 203 priority joined into the MRT Island, the GADAG root MUST be re- 204 selected. A new MRT computation will be triggered because of such a 205 topology change. 207 4.3. Advertising MRT-Ineligible Links for MRT 209 For administrative or management reasons, it may be desirable to 210 exclude some links from the MRT computation. In this scenario, MRT- 211 Capable router MUST claim those MRT-Ineligible links are out of MRT 212 Island scope. If such claim splits current MRT Island then MRT 213 computation has to be done inside the modified MRT Island which the 214 computing router belongs to. 216 4.4. Triggering an MRT Computation 218 A MRT Computation can be triggered through topology changes or MRT 219 capability changes of any router in the MRT Island. It is always 220 triggered for a given MRT Profile in the corresponding level. First, 221 the associated MRT Island is determined. Then, the GADAG Root is 222 selected. Finally, the actual MRT algorithm is run to compute the 223 transit MRT-Red and MRT-Blue topologies. Additionally, the router 224 MAY choose to compute MRT-FRR alternates or make other use of the MRT 225 computation results. 227 Prefixes can be attached and detached and have their associated MRT- 228 Red and MRT-Blue next-hops computed without requiring a new MRT 229 computation. 231 5. MRT Capability Advertisement 233 An MRT-Capable router MUST identify its MRT capabilities through IS- 234 IS Link State Packets(LSPs) in level scope. 236 5.1. MRT Profile sub-TLV in the IS-IS Router CAPABILITY TLV 238 A new MRT Profile sub-TLV is introduced into the IS-IS Router 239 CAPABILITY TLV (TLV #242 defined in [RFC4971]) to advertise MRT 240 capabilities. Since MRT has per level scope, the S-bit and D-bit of 241 IS-IS Router CAPABILITY TLV MUST be set to zero. The structure of 242 the MRT Profile sub-TLV is shown below: 244 TYPE: TBA-MRT-ISIS-1 (To Be Allocated by IANA) 246 LENGTH: 4 248 VALUE: 250 MT-ID (2 octets with 4 bits reserved) 252 MRT Profile ID (1 octet) 254 GADAG Root Selection Priority (1 octet) 256 Number of octets 257 +-------------------------------+ 258 |R |R |R |R | MT-ID | 2 259 +-------------------------------+ 260 | MRT Profile ID | 1 261 +-------------------------------+ 262 | GADAG Root Selection Priority | 1 263 +-------------------------------+ 265 MT-ID is a 12-bit field containing the multi-topology ID. As 266 discussed in Section 5.3, this document specifies that the MT-ID 267 field MUST be set to zero. 269 The MRT Profile ID represents the MRT profile this router supports. 271 The GADAG Root Selection Priority is the priority for selection as 272 GADAG root. A router advertising the MRT Profile sub-TLV MUST 273 specify a GADAG Root Selection Priority. The range of this priority 274 is [0, 255]. The RECOMMENDED default value of the GADAG Root 275 Selection Priority is 128. The GADAG Root Selection Policy defined 276 as part of a given MRT profile determines how the GADAG Root 277 Selection Priority value is used. 279 This sub-TLV can occur multiple times if a router supports multiple 280 MRT profiles. This can happen during a network transition. Or it 281 can be used to support different uses of MRT within the same network 282 which may perform better with different profiles. 284 A given router SHOULD NOT advertise multiple MRT Profile sub-TLVs 285 with the same MRT profile ID. If a router receives multiple MRT 286 Profile sub-TLVs with the same MRT profile ID from the same 287 originator, it MUST use one with the lowest value of GADAG Root 288 Selection Priority. 290 5.1.1. A note on the M-bit in OSPF 292 [I-D.ietf-ospf-mrt] defines MRT signalling extensions for OSPF. In 293 addition to the OSPF version of MRT Profile sub-TLV (which is carried 294 in the OSPF Router Information LSA), it also defines the M-bit (which 295 is carried in the OSPF Router-LSA.) As discussed in 296 [I-D.ietf-ospf-mrt], the M-bit in the Router-LSA ensures that all 297 routers in the area have up-to-date information if a router is 298 downgraded to a software version that does not support MRT and the 299 Router Information LSA. 301 The problematic scenario that requires the M-bit in the OSPF Router- 302 LSA does not occur in IS-IS. The presence or absence of an IS-IS 303 Router CAPABILITY TLV containing a given MRT Profile sub-TLV in the 304 IS-IS Link State PDU provides enough information for all routers to 305 determine which remote routers support MRT, even after a software 306 version downgrade of remote routers. Therefore, this document does 307 not define a corresponding M-bit for IS-IS. 309 5.2. MRT-Ineligible Link sub-TLV in the Extended IS Reachability TLV 311 As a matter of policy, an operator may choose to mark some links as 312 ineligible for carrying MRT traffic. For instance, policy can be 313 made to prevent fast-rerouted traffic from taking those links. 315 For a link to be marked as ineligible for use in the MRT calculation, 316 it MUST be advertised including the MRT-Ineligible Link sub-TLV in 317 the Extended IS Reachability TLV (TLV #22 defined in [RFC5305] ) 318 corresponding to the ineligible link. The MRT-Ineligible Link sub- 319 TLV is a zero-length sub-TLV as shown below: 321 TYPE: TBA-MRT-ISIS-2 (To Be Allocated by IANA) 323 LENGTH: 0 325 VALUE: None 327 The presence of the zero-length MRT-Ineligible Link sub-TLV in the 328 Extended IS Reachability TLV indicates that the associated link MUST 329 NOT be used in the MRT calculation for the default topology for all 330 profiles. 332 5.3. A Note on Multi-Topology Routing 334 [RFC5120] specifies how to support multi-topology routing in IS-IS. 335 The current document specifies how to signal support for MRT in the 336 default routing topology only. The format of the extensions in this 337 document allows the MRT Profile sub-TLV and the MRT-Ineligible Link 338 sub-TLV to be scoped to topologies with non-zero MT-ID at some point 339 in the future. However, this document restricts these extensions to 340 apply only to the default topology. The MRT Profile sub-TLV is 341 restricted by explicitly requiring the MT-ID field to be set to zero. 342 The MRT-Ineligible Link sub-TLV is restricted by only allowing it to 343 be included in the Extended IS Reachability TLV (TLV#22) which is 344 scoped to the default topology, and not allowing it to appear TLV#222 345 (the topology-scoped version of the Extended IS Reachability TLV). 347 Lifting these restrictions is for further study. Note that the MRT 348 signalling extensions in this document can co-exist with IS-IS multi- 349 topology routing, with the limitation that MRT Red and Blue 350 forwarding trees can only be built for the default topology. 352 The format of the Controlled Convergence sub-TLV (discussed below) 353 also contains an MT-ID field, allowing a Controlled Convergence sub- 354 TLV to be scoped to a particular topology. This document does not 355 place restrictions on the MT-ID field in the Controlled Convergence 356 sub-TLV. The Controlled Convergence sub-TLV has potential 357 applications that are not limited to MRT, and a topology-scoped FIB 358 compute/install time makes sense on its own. 360 6. Controlled Convergence sub-TLV in IS-IS Router CAPABILITY TLV 362 Section 12.2 of [RFC7812] describes the need to wait for a configured 363 or advertised period after a network failure to insure that all 364 routers are using their new shortest path trees. Similarly, avoiding 365 micro-forwarding loops during convergence [RFC5715] requires 366 determining the maximum among all routers in the area of the worst- 367 case route computation and FIB installation time. More details on 368 the specific reasoning and need for flooding this value are given in 369 [I-D.atlas-bryant-shand-lf-timers]. 371 A new Controlled Convergence sub-TLV is introduced into the IS-IS 372 Router CAPABILITY TLV (TLV #242 defined in [RFC4971]) to advertise 373 the worst-case time for a router to compute and install all IS-IS 374 routes in the level after a change to a stable network. This 375 advertisement has per level scope, so the S-bit and D-bit of IS-IS 376 Router CAPABILITY TLV MUST be set to zero. The advertisement is 377 scoped by MT-ID, allowing a router supporting multi-topology routing 378 to advertise a different worst-case FIB compute/install time for each 379 topology. This makes sense as the SPF computations and FIB 380 installations for each IGP topology can potentially be done 381 independently of one another, and may have different worst-case 382 compute and install times. 384 The structure of the Controlled Convergence sub-TLV is shown below: 386 TYPE: TBA-MRT-ISIS-3 (To Be Allocated by IANA) 388 LENGTH: 3 390 VALUE: 392 MT-ID (2 octets with 4 bits reserved) 394 FIB compute/install time (1 octet) 396 Number of octets 397 +-------------------------------+ 398 |R |R |R |R | MT-ID | 2 399 +-------------------------------+ 400 | FIB compute/install time | 1 401 +-------------------------------+ 403 MT-ID is a 12-bit field containing the multi-topology ID. 405 The FIB compute/install time is the worst-case time the router may 406 take to compute and install all IS-IS routes in the level after a 407 change to a stable network. The value is an unsigned integer in 408 units of milliseconds. 410 The FIB compute/install time value sent by a router SHOULD be an 411 estimate taking into account network scale or real-time measurements, 412 or both. Advertisements SHOULD be dampened to avoid frequent 413 communication of small changes in the FIB compute/install time. 415 A router receiving the Controlled Convergence sub-TLV SHOULD estimate 416 the network convergence time as the maximum of the FIB compute/ 417 install times advertised by the routers in a level for a given MT-ID, 418 including itself. In order to account for routers that do not 419 advertise the Controlled Convergence sub-TLV, a router MAY use a 420 locally configured minimum network convergence time as a lower bound 421 on the computed network convergence time. A router MAY use a locally 422 configured maximum network convergence time as an upper bound on the 423 computed network convergence time. 425 7. Handling MRT Extensions 427 7.1. Advertising MRT extensions 429 MRT sub-TLVs are encapsulated in the Router Capability TLV and 430 advertised using the LS-PDU with level-wide scope. MRT sub-TLVs are 431 optional. If one router does not support MRT, it MUST NOT advertise 432 those sub-TLVs. 434 Since the advertisement scope of the MRT sub-TLV is level-wide, the 435 D-Bit and S-Bit of the Router Capability TLV MUST be set as 0 when it 436 is advertised. If other sub-TLVs in the Router Capability TLV need 437 different values for those two bits, then the router MUST originate 438 multiple Router Capability TLVs with different bit values. 440 When MRT-related information is changed for the router or existing 441 IS-IS LSP mechanisms are triggered for refreshing or updating, MRT 442 sub-TLVs MUST be advertised if the router is MRT-Capable. 444 Based on administrative policy, it may be desirable to exclude 445 certain links from the MRT computation. The MRT-Ineligible sub-TLV 446 is used to advertise which links should be excluded. Note that an 447 interface advertised as MRT-Ineligible by a router is ineligible with 448 respect to all profiles advertised by that router. 450 7.2. Processing MRT extensions 452 The processing associated with MRT extensions SHOULD NOT 453 significantly degrade IS-IS adjacency formation and maintenance or 454 the routing calculation for normal shortest path routes. 456 MRT sub-TLVs SHOULD be validated like other sub-TLVs when received. 457 MRT sub-TLVs SHOULD also be taken into account for checksum 458 calculations and authentication. 460 Links advertised as MRT-ineligible using the MRT-Ineligible sub-TLV 461 MUST be excluded from the MRT computation. The removal of individual 462 links from the MRT Island can partition an MRT Island or it can 463 significantly modify the construction of the GADAG and the result MRT 464 Red and Blue trees. Therefore, all routers must perform the same 465 computation using the same set of links. 467 8. Backward Compatibility 469 The MRT Profile sub-TLV, the MRT-Ineligible Link sub-TLV, and the 470 Controlled Convergence sub-TLV defined in this document are 471 compatible with existing implementations of IS-IS. Routers that do 472 not support these extensions are expected to silently ignore them. 474 Router that do support these extensions have mechanisms to recognize 475 routers that don't support these extensions (or are not configured to 476 participate in MRT) and behave accordingly. 478 9. Implementation Status 480 [RFC Editor: please remove this section prior to publication.] 482 Please see [RFC7812] for details on implementation status. 484 10. Security Considerations 486 The IS-IS extensions in this document do not introduce new security 487 concerns. 489 11. Acknowledgements 491 The authors would like to thank Shraddha Hegde for her useful 492 suggestions. 494 12. IANA Considerations 496 12.1. MRT Profile and Controlled Convergence sub-TLVs 498 IANA is requested to allocate values for the following sub-TLVs types 499 in the IS-IS Router CAPABILITY TLV defined in [RFC4971]: the MRT 500 Profile sub-TLV (TBA-MRT-ISIS-1) and Controlled Convergence sub-TLV 501 (TBA-MRT-ISIS-3). The IANA registry for these sub-TLV types is 502 displayed as "sub-TLVs for TLV 242" (http://www.iana.org/assignments/ 503 isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints- 504 242). The new entries in this registry are shown below. 506 Value Description Reference 507 -------------- ------------------------------ ------------ 508 TBA-MRT-ISIS-1 MRT Profile sub-TLV [This draft] 509 TBA-MRT-ISIS-3 Controlled Convergence sub-TLV [This draft] 511 12.2. MRT-Ineligible Link sub-TLV 513 IANA is requested to allocate a value for the following sub-TLVs type 514 in the Extended IS Reachability TLV defined in [RFC5305]: MRT- 515 Ineligible Link sub-TLV (TBA-MRT-ISIS-2). The IANA registry for 516 these sub-TLV types is displayed as "Sub-TLVs for TLVs 22, 23, 141, 517 222, and 223" (http://www.iana.org/assignments/isis-tlv-codepoints/ 518 isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-141-222-223). 519 The new entry in this registry is shown below. 521 Type Description 22 23 141 222 223 Ref. 522 -------------- --------------------------- -- -- --- --- --- -------- 523 TBA-MRT-ISIS-2 MRT-Ineligible Link sub-TLV y y n n n [This 524 draft] 526 13. References 528 13.1. Normative References 530 [RFC3787] Parker, J., Ed., "Recommendations for Interoperable IP 531 Networks using Intermediate System to Intermediate System 532 (IS-IS)", RFC 3787, DOI 10.17487/RFC3787, May 2004, 533 . 535 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 536 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 537 2008, . 539 [RFC7811] Enyedi, G., Csaszar, A., Atlas, A., Bowers, C., and A. 540 Gopalan, "An Algorithm for Computing IP/LDP Fast Reroute 541 Using Maximally Redundant Trees (MRT-FRR)", RFC 7811, 542 DOI 10.17487/RFC7811, June 2016, 543 . 545 [RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for 546 IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT- 547 FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016, 548 . 550 13.2. Infomative References 552 [I-D.atlas-bryant-shand-lf-timers] 553 K, A. and S. Bryant, "Synchronisation of Loop Free Timer 554 Values", draft-atlas-bryant-shand-lf-timers-04 (work in 555 progress), February 2008. 557 [I-D.ietf-ospf-mrt] 558 Atlas, A., Hegde, S., Bowers, C., Tantsura, J., and Z. Li, 559 "OSPF Extensions to Support Maximally Redundant Trees", 560 draft-ietf-ospf-mrt-01 (work in progress), October 2015. 562 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 563 dual environments", RFC 1195, DOI 10.17487/RFC1195, 564 December 1990, . 566 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 567 Requirement Levels", BCP 14, RFC 2119, 568 DOI 10.17487/RFC2119, March 1997, 569 . 571 [RFC4971] Vasseur, JP., Ed., Shen, N., Ed., and R. Aggarwal, Ed., 572 "Intermediate System to Intermediate System (IS-IS) 573 Extensions for Advertising Router Information", RFC 4971, 574 DOI 10.17487/RFC4971, July 2007, 575 . 577 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 578 Topology (MT) Routing in Intermediate System to 579 Intermediate Systems (IS-ISs)", RFC 5120, 580 DOI 10.17487/RFC5120, February 2008, 581 . 583 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 584 DOI 10.17487/RFC5308, October 2008, 585 . 587 [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free 588 Convergence", RFC 5715, DOI 10.17487/RFC5715, January 589 2010, . 591 Authors' Addresses 593 Zhenbin Li 594 Huawei Technologies 595 Huawei Bld., No.156 Beiqing Rd. 596 Beijing 100095 597 China 599 Email: lizhenbin@huawei.com 601 Nan Wu 602 Huawei Technologies 603 Huawei Bld., No.156 Beiqing Rd. 604 Beijing 100095 605 China 607 Email: eric.wu@huawei.com 608 Quintin Zhao 609 Huawei Technologies 610 125 Nagog Technology Park 611 Acton, MA 01719 612 USA 614 Alia Atlas 615 Juniper Networks 616 10 Technology Park Drive 617 Westford, MA 01886 618 USA 620 Email: akatlas@juniper.net 622 Chris Bowers 623 Juniper Networks 624 1194 N. Mathilda Ave. 625 Sunnyvale, CA 94089 626 USA 628 Email: cbowers@juniper.net 630 Jeff Tantsura 631 Individual 632 USA 634 Email: jefftant.ietf@gmail.com