idnits 2.17.00 (12 Aug 2021) /tmp/idnits7917/draft-ietf-isis-mrt-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 (October 19, 2015) is 2406 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 568, but not defined == Missing Reference: 'RFC5308' is mentioned on line 594, but not defined == Missing Reference: 'RFC2119' is mentioned on line 572, but not defined == Missing Reference: 'RFC4971' is mentioned on line 582, but not defined ** Obsolete undefined reference: RFC 4971 (Obsoleted by RFC 7981) -- Looks like a reference, but probably isn't: '0' on line 276 -- Looks like a reference, but probably isn't: '255' on line 276 == Missing Reference: 'I-D.ietf-ospf-mrt' is mentioned on line 563, but not defined == Missing Reference: 'RFC5120' is mentioned on line 588, but not defined == Missing Reference: 'RFC5715' is mentioned on line 598, but not defined == Missing Reference: 'I-D.atlas-bryant-shand-lf-timers' is mentioned on line 558, but not defined == Missing Reference: 'RFC4915' is mentioned on line 577, but not defined == Outdated reference: draft-ietf-rtgwg-mrt-frr-algorithm has been published as RFC 7811 == Outdated reference: draft-ietf-rtgwg-mrt-frr-architecture has been published as RFC 7812 ** Downref: Normative reference to an Informational RFC: RFC 3787 Summary: 2 errors (**), 0 flaws (~~), 13 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: April 21, 2016 Huawei Technologies 6 A. Atlas 7 C. Bowers 8 Juniper Networks 9 J. Tantsura 10 Ericsson 11 October 19, 2015 13 Intermediate System to Intermediate System (IS-IS) Extensions for 14 Maximally Redundant Trees (MRT) 15 draft-ietf-isis-mrt-01 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 April 21, 2016. 47 Copyright Notice 49 Copyright (c) 2015 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 [I-D.ietf-rtgwg-mrt-frr-architecture] gives a complete solution for 106 IP/LDP fast-reroute using Maximally Redundant Trees (MRT) to provide 107 alternates. This document describes signalling extensions for 108 supporting MRT-FRR in an IS-IS 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 [I-D.ietf-rtgwg-mrt-frr-algorithm], it is necessary for 153 each MRT-Capable router to compute MRT next hops in a consistent 154 fashion. This is achieved by using the same MRT profile and 155 selecting a common and unique GADAG root in the MRT Island which is 156 connected by MRT-Eligible links. Each of these issues will be 157 discussed in the following sections separately. 159 4.1. Supporting MRT Profiles 161 The contents and requirements of an MRT profile has been defined in 162 [I-D.ietf-rtgwg-mrt-frr-architecture]. The parameters and behavioral 163 rules contained in an MRT profile define one router's MRT 164 capabilities. Based on common capabilities, one unified MRT Island 165 is built. 167 The MRT-Capable router MUST advertise its corresponding MRT profiles 168 by IS-IS protocol extension within IS-IS routing domain. The 169 capabilities of the advertiser MUST completely conform to the profile 170 it claimed, including the MT-IDs, the algorithm and the corresponding 171 forwarding mechanism. This advertisement MUST have level scope. A 172 given router MAY support multiple MRT profiles. If so, it MUST 173 advertise each of these profiles in the corresponding IS-IS level. 175 The default MRT Profile is defined in 176 [I-D.ietf-rtgwg-mrt-frr-architecture]. Its behavior is intended to 177 support IP/LDP unicast and multicast Fast-Reroute. MRT-Capable 178 routers SHOULD support the default MRT profile. 180 4.2. Selecting the GADAG Root 182 As per [I-D.ietf-rtgwg-mrt-frr-algorithm], a GADAG root MUST be 183 selected for one MRT Island. An unique GADAG root in common among 184 MRT Island routers is a necessity to do MRT computation. Since the 185 selection of the GADAG root can affect the quality of paths for 186 traffic sent over MRT Red and Blue trees, the GADAG Root Selection 187 Priority and the GADAG Root Selection Policy gives a network operator 188 the ability to influence the selection of the GADAG root. 190 Each MRT-Capable router MUST advertise its priority for GADAG root 191 selection. A router can only have one priority in a given MRT 192 Island. It can have multiple priorities for different MRT Islands it 193 supports. Routers that are marked as overloaded([RFC3787]) are not 194 qualified as candidate for root selection. 196 The GADAG Root Selection Policy (defined as part of an MRT profile) 197 may make use of the GADAG Root Selection Priority value advertised in 198 the MRT Profile in the IS-IS Router CAPABILITY TLV. For example, the 199 GADAG Root Selection Policy for the default MRT profile is the 200 following: Among the routers in the MRT Island and with the highest 201 priority advertised, an implementation MUST pick the router with the 202 highest Router ID to be the GADAG root. 204 When the current root is out of service or new router with higher 205 priority joined into the MRT Island, the GADAG root MUST be re- 206 selected. A new MRT computation will be triggered because of such a 207 topology change. 209 4.3. Advertising MRT-Ineligible Links for MRT 211 For administrative or management reasons, it may be desirable to 212 exclude some links from the MRT computation. In this scenario, MRT- 213 Capable router MUST claim those MRT-Ineligible links are out of MRT 214 Island scope. If such claim splits current MRT Island then MRT 215 computation has to be done inside the modified MRT Island which the 216 computing router belongs to. 218 4.4. Triggering an MRT Computation 220 A MRT Computation can be triggered through topology changes or MRT 221 capability changes of any router in the MRT Island. It is always 222 triggered for a given MRT Profile in the corresponding level. First, 223 the associated MRT Island is determined. Then, the GADAG Root is 224 selected. Finally, the actual MRT algorithm is run to compute the 225 transit MRT-Red and MRT-Blue topologies. Additionally, the router 226 MAY choose to compute MRT-FRR alternates or make other use of the MRT 227 computation results. 229 Prefixes can be attached and detached and have their associated MRT- 230 Red and MRT-Blue next-hops computed without requiring a new MRT 231 computation. 233 5. MRT Capability Advertisement 235 An MRT-Capable router MUST identify its MRT capabilities through IS- 236 IS Link State Packets(LSPs) in level scope. 238 5.1. MRT Profile sub-TLV in the IS-IS Router CAPABILITY TLV 240 A new MRT Profile sub-TLV is introduced into the IS-IS Router 241 CAPABILITY TLV (TLV #242 defined in [RFC4971]) to advertise MRT 242 capabilities. Since MRT has per level scope, the S-bit and D-bit of 243 IS-IS Router CAPABILITY TLV MUST be set to zero. The structure of 244 the MRT Profile sub-TLV is shown below: 246 TYPE: TBA-MRT-ISIS-1 (To Be Allocated by IANA) 248 LENGTH: 4 250 VALUE: 252 MT-ID (2 octets with 4 bits reserved) 254 MRT Profile ID (1 octet) 256 GADAG Root Selection Priority (1 octet) 258 Number of octets 259 +-------------------------------+ 260 |R |R |R |R | MT-ID | 2 261 +-------------------------------+ 262 | MRT Profile ID | 1 263 +-------------------------------+ 264 | GADAG Root Selection Priority | 1 265 +-------------------------------+ 267 MT-ID is a 12-bit field containing the multi-topology ID. As 268 discussed in Section 5.3, this document specifies that the MT-ID 269 field MUST be set to zero. 271 The MRT Profile ID represents the MRT profile this router supports. 273 The GADAG Root Selection Priority is the priority for selection as 274 GADAG root. A router advertising the MRT Profile sub-TLV MUST 275 specify a GADAG Root Selection Priority. The range of this priority 276 is [0, 255]. The RECOMMENDED default value of the GADAG Root 277 Selection Priority is 128. The GADAG Root Selection Policy defined 278 as part of a given MRT profile determines how the GADAG Root 279 Selection Priority value is used. 281 This sub-TLV can occur multiple times if a router supports multiple 282 MRT profiles. This can happen during a network transition. Or it 283 can be used to support different uses of MRT within the same network 284 which may perform better with different profiles. 286 A given router SHOULD NOT advertise multiple MRT Profile sub-TLVs 287 with the same MRT profile ID. If a router receives multiple MRT 288 Profile sub-TLVs with the same MRT profile ID from the same 289 originator, it MUST use one with the lowest value of GADAG Root 290 Selection Priority. 292 5.1.1. A note on the M-bit in OSPF 294 [I-D.ietf-ospf-mrt] defines MRT signalling extensions for OSPF. In 295 addition to the OSPF version of MRT Profile sub-TLV (which is carried 296 in the OSPF Router Information LSA), it also defines the M-bit (which 297 is carried in the OSPF Router-LSA.) As discussed in 298 [I-D.ietf-ospf-mrt], the M-bit in the Router-LSA ensures that all 299 routers in the area have up-to-date information if a router is 300 downgraded to a software version that does not support MRT and the 301 Router Information LSA. 303 The problematic scenario that requires the M-bit in the OSPF Router- 304 LSA does not occur in IS-IS. The presence or absence of an IS-IS 305 Router CAPABILITY TLV containing a given MRT Profile sub-TLV in the 306 IS-IS Link State PDU provides enough information for all routers to 307 determine which remote routers support MRT, even after a software 308 version downgrade of remote routers. Therefore, this document does 309 not define a corresponding M-bit for IS-IS. 311 5.2. MRT-Ineligible Link sub-TLV in the Extended IS Reachability TLV 313 As a matter of policy, an operator may choose to mark some links as 314 ineligible for carrying MRT traffic. For instance, policy can be 315 made to prevent fast-rerouted traffic from taking those links. 317 For a link to be marked as ineligible for use in the MRT calculation, 318 it MUST be advertised including the MRT-Ineligible Link sub-TLV in 319 the Extended IS Reachability TLV (TLV #22 defined in [RFC5305] ) 320 corresponding to the ineligible link. The MRT-Ineligible Link sub- 321 TLV is a zero-length sub-TLV as shown below: 323 TYPE: TBA-MRT-ISIS-2 (To Be Allocated by IANA) 325 LENGTH: 0 327 VALUE: None 329 The presence of the zero-length MRT-Ineligible Link sub-TLV in the 330 Extended IS Reachability TLV indicates that the associated link MUST 331 NOT be used in the MRT calculation for the default topology for all 332 profiles. 334 5.3. A Note on Multi-Topology Routing 336 [RFC5120] specifies how to support multi-topology routing in IS-IS. 337 The current document specifies how to signal support for MRT in the 338 default routing topology only. The format of the extensions in this 339 document allows the MRT Profile sub-TLV and the MRT-Ineligible Link 340 sub-TLV to be scoped to topologies with non-zero MT-ID at some point 341 in future. However, this document restricts these extensions to 342 apply only to the default topology. The MRT Profile sub-TLV is 343 restricting by explicitly requiring the MT-ID field to be set to 344 zero. The MRT-Ineligible Link sub-TLV is restricted by only allowing 345 it to be included in the Extended IS Reachability TLV (TLV#22) which 346 is scoped to the default topology, and not allowing it to appear 347 TLV#222 (the topology-scoped version of the Extended IS Reachability 348 TLV). 350 Lifting these restrictions is for further study. Note that the MRT 351 signalling extensions in this document can co-exist with IS-IS multi- 352 topology routing, with the limitation that MRT Red and Blue 353 forwarding trees can only be built for the default topology. 355 The format of the Controlled Convergence sub-TLV (discussed below) 356 also contains an MT-ID field, allowing a Controlled Convergence sub- 357 TLV to be scoped to a particular topology. This document does not 358 place restrictions on the MT-ID field in the Controlled Convergence 359 sub-TLV. The Controlled Convergence sub-TLV has potential 360 applications that are not limited to MRT, and a topology-scoped FIB 361 compute/install time makes sense on its own. 363 6. Controlled Convergence sub-TLV in IS-IS Router CAPABILITY TLV 365 Section 12.2 of [I-D.ietf-rtgwg-mrt-frr-architecture] describes the 366 need to wait for a configured or advertised period after a network 367 failure to insure that all routers are using their new shortest path 368 trees. Similarly, avoiding micro-forwarding loops during convergence 369 [RFC5715] requires determining the maximum among all routers in the 370 area of the worst-case route computation and FIB installation time. 371 More details on the specific reasoning and need for flooding this 372 value are given in [I-D.atlas-bryant-shand-lf-timers]. 374 A new Controlled Convergence sub-TLV is introduced into the IS-IS 375 Router CAPABILITY TLV (TLV #242 defined in [RFC4971]) to advertise 376 the worst-case time for a router to compute and install all IS-IS 377 routes in the level after a change to a stable network. This 378 advertisement has per level scope, so the S-bit and D-bit of IS-IS 379 Router CAPABILITY TLV MUST be set to zero. The advertisement is 380 scoped by MT-ID, allowing a router supporting multi-topology routing 381 to advertise a different worst-case FIB compute/install time for each 382 topology. This makes sense as the SPF computations and FIB 383 installations for each IGP topology can potentially be done 384 independently of one another, and may have different worst-case 385 compute and install times. 387 The structure of the Controlled Convergence sub-TLV is shown below: 389 TYPE: TBA-MRT-ISIS-3 (To Be Allocated by IANA) 391 LENGTH: 3 393 VALUE: 395 MT-ID (2 octets with 4 bits reserved) 397 FIB compute/install time (1 octet) 399 Number of octets 400 +-------------------------------+ 401 |R |R |R |R | MT-ID | 2 402 +-------------------------------+ 403 | FIB compute/install time | 1 404 +-------------------------------+ 406 MT-ID is a 12-bit field containing the multi-topology ID. 408 The FIB compute/install time is the worst-case time the router may 409 take to compute and install all IS-IS routes in the level after a 410 change to a stable network. The value is an unsigned integer in 411 units of milliseconds. 413 The FIB compute/install time value sent by a router SHOULD be an 414 estimate taking into account network scale or real-time measurements, 415 or both. Advertisements SHOULD be dampened to avoid frequent 416 communication of small changes in the FIB compute/install time. 418 A router receiving the Controlled Convergence sub-TLV SHOULD estimate 419 the network convergence time as the maximum of the FIB compute/ 420 install times advertised by the routers in a level for a given MT-ID, 421 including itself. In order to account for routers that do not 422 advertise the Controlled Convergence sub-TLV, a router MAY use a 423 locally configured minimum network convergence time as a lower bound 424 on the computed network convergence time. A router MAY use a locally 425 configured maximum network convergence time as an upper bound on the 426 computed network convergence time. 428 7. Handling MRT Extensions 430 7.1. Advertising MRT extensions 432 MRT sub-TLVs are encapsulated in the Router Capability TLV and 433 advertised using the LS-PDU with level-wide scope. MRT sub-TLVs are 434 optional. If one router does not support MRT, it MUST NOT advertise 435 those sub-TLVs. 437 Since the advertisement scope of the MRT sub-TLV is level-wide, the 438 D-Bit and S-Bit of the Router Capability TLV MUST be set as 0 when it 439 is advertised. If other sub-TLVs in the Router Capability TLV need 440 different values for those two bits, then the router MUST originate 441 multiple Router Capability TLVs with different bit values. 443 When MRT-related information is changed for the router or existing 444 IS-IS LSP mechanisms are triggered for refreshing or updating, MRT 445 sub-TLVs MUST be advertised if the router is MRT-Capable. 447 Based on administrative policy, it may be desirable to exclude 448 certain links from the MRT computation. The MRT-Ineligible sub-TLV 449 is used to advertise which links should be excluded. Note that an 450 interface advertised as MRT-Ineligible by a router is ineligible with 451 respect to all profiles advertised by that router. 453 7.2. Processing MRT extensions 455 The processing associated with MRT extensions SHOULD NOT 456 significantly degrade IS-IS adjacency formation and maintenance or 457 the routing calculation for normal shortest path routes. 459 MRT sub-TLVs SHOULD be validated like other sub-TLVs when received. 460 MRT sub-TLVs SHOULD also be taken into account for checksum 461 calculations and authentication. 463 Links advertised as MRT-ineligible using the MRT-Ineligible sub-TLV 464 MUST be excluded from the MRT computation. The removal of individual 465 links from the MRT Island can partition an MRT Island or it can 466 significantly modify the construction of the GADAG and the result MRT 467 Red and Blue trees. Therefore, all routers must perform the same 468 computation using the same set of links. 470 8. Backward Compatibility 472 The MRT Profile sub-TLV, the MRT-Ineligible Link sub-TLV, and the 473 Controlled Convergence sub-TLV defined in this document are 474 compatible with existing implementations of IS-IS. Routers that do 475 not support these extensions are expected to silently ignore them. 477 Router that do support these extensions have mechanisms to recognize 478 routers that don't support these extensions (or are not configured to 479 participate in MRT) and behave accordingly. 481 9. Implementation Status 483 [RFC Editor: please remove this section prior to publication.] 485 Please see [I-D.ietf-rtgwg-mrt-frr-architecture] for details on 486 implementation status. 488 10. Security Considerations 490 The IS-IS extensions in this document do not introduce new security 491 concerns. 493 11. Acknowledgements 495 The authors would like to thank Shraddha Hegde for her useful 496 suggestions. 498 12. IANA Considerations 500 12.1. MRT Profile and Controlled Convergence sub-TLVs 502 IANA is requested to allocate values for the following sub-TLVs types 503 in the IS-IS Router CAPABILITY TLV defined in [RFC4971]: the MRT 504 Profile sub-TLV (TBA-MRT-ISIS-1) and Controlled Convergence sub-TLV 505 (TBA-MRT-ISIS-3). The IANA registry for these sub-TLV types is 506 displayed as "sub-TLVs for TLV 242" (http://www.iana.org/assignments/ 507 isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints- 508 242). The new entries in this registry are shown below. 510 Value Description Reference 511 -------------- ------------------------------ ------------ 512 TBA-MRT-ISIS-1 MRT Profile sub-TLV [This draft] 513 TBA-MRT-ISIS-3 Controlled Convergence sub-TLV [This draft] 515 12.2. MRT-Ineligible Link sub-TLV 517 IANA is requested to allocate a value for the following sub-TLVs type 518 in the Extended IS Reachability TLV defined in [RFC5305]: MRT- 519 Ineligible Link sub-TLV (TBA-MRT-ISIS-2). The IANA registry for 520 these sub-TLV types is displayed as "Sub-TLVs for TLVs 22, 23, 141, 521 222, and 223" (http://www.iana.org/assignments/isis-tlv-codepoints/ 522 isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-141-222-223). 523 The new entry in this registry is shown below. 525 Type Description 22 23 141 222 223 Ref. 526 -------------- --------------------------- -- -- --- --- --- -------- 527 TBA-MRT-ISIS-2 MRT-Ineligible Link sub-TLV y y n n n [This 528 draft] 530 13. References 532 13.1. Normative References 534 [I-D.ietf-rtgwg-mrt-frr-algorithm] 535 Envedi, G., Csaszar, A., Atlas, A., Bowers, C., and A. 536 Gopalan, "Algorithms for computing Maximally Redundant 537 Trees for IP/LDP Fast- Reroute", draft-ietf-rtgwg-mrt-frr- 538 algorithm-06 (work in progress), October 2015. 540 [I-D.ietf-rtgwg-mrt-frr-architecture] 541 Atlas, A., Kebler, R., Bowers, C., Envedi, G., Csaszar, 542 A., Tantsura, J., and R. White, "An Architecture for IP/ 543 LDP Fast-Reroute Using Maximally Redundant Trees", draft- 544 ietf-rtgwg-mrt-frr-architecture-07 (work in progress), 545 October 2015. 547 [RFC3787] Parker, J., Ed., "Recommendations for Interoperable IP 548 Networks using Intermediate System to Intermediate System 549 (IS-IS)", RFC 3787, DOI 10.17487/RFC3787, May 2004, 550 . 552 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 553 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 554 2008, . 556 13.2. Infomative References 558 [I-D.atlas-bryant-shand-lf-timers] 559 K, A. and S. Bryant, "Synchronisation of Loop Free Timer 560 Values", draft-atlas-bryant-shand-lf-timers-04 (work in 561 progress), February 2008. 563 [I-D.ietf-ospf-mrt] 564 Atlas, A., Hegde, S., Bowers, C., Tantsura, J., and Z. Li, 565 "OSPF Extensions to Support Maximally Redundant Trees", 566 draft-ietf-ospf-mrt-01 (work in progress), October 2015. 568 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 569 dual environments", RFC 1195, DOI 10.17487/RFC1195, 570 December 1990, . 572 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 573 Requirement Levels", BCP 14, RFC 2119, 574 DOI 10.17487/RFC2119, March 1997, 575 . 577 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 578 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 579 RFC 4915, DOI 10.17487/RFC4915, June 2007, 580 . 582 [RFC4971] Vasseur, JP., Ed., Shen, N., Ed., and R. Aggarwal, Ed., 583 "Intermediate System to Intermediate System (IS-IS) 584 Extensions for Advertising Router Information", RFC 4971, 585 DOI 10.17487/RFC4971, July 2007, 586 . 588 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 589 Topology (MT) Routing in Intermediate System to 590 Intermediate Systems (IS-ISs)", RFC 5120, 591 DOI 10.17487/RFC5120, February 2008, 592 . 594 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 595 DOI 10.17487/RFC5308, October 2008, 596 . 598 [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free 599 Convergence", RFC 5715, DOI 10.17487/RFC5715, January 600 2010, . 602 Authors' Addresses 604 Zhenbin Li 605 Huawei Technologies 606 Huawei Bld., No.156 Beiqing Rd. 607 Beijing 100095 608 China 610 Email: lizhenbin@huawei.com 612 Nan Wu 613 Huawei Technologies 614 Huawei Bld., No.156 Beiqing Rd. 615 Beijing 100095 616 China 618 Email: eric.wu@huawei.com 619 Quintin Zhao 620 Huawei Technologies 621 125 Nagog Technology Park 622 Acton, MA 01719 623 USA 625 Alia Atlas 626 Juniper Networks 627 10 Technology Park Drive 628 Westford, MA 01886 629 USA 631 Email: akatlas@juniper.net 633 Chris Bowers 634 Juniper Networks 635 1194 N. Mathilda Ave. 636 Sunnyvale, CA 94089 637 USA 639 Email: cbowers@juniper.net 641 Jeff Tantsura 642 Ericsson 643 300 Holger Way 644 San Jose, CA 95134 645 USA 647 Email: jeff.tantsura@ericsson.com