idnits 2.17.1 draft-ietf-isis-mrt-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 18, 2016) is 2898 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 567, but not defined == Missing Reference: 'RFC5308' is mentioned on line 593, but not defined == Missing Reference: 'RFC2119' is mentioned on line 571, but not defined == Missing Reference: 'RFC4971' is mentioned on line 581, 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 562, but not defined == Missing Reference: 'RFC5120' is mentioned on line 587, but not defined == Missing Reference: 'RFC5715' is mentioned on line 597, but not defined == Missing Reference: 'I-D.atlas-bryant-shand-lf-timers' is mentioned on line 557, but not defined == Missing Reference: 'RFC4915' is mentioned on line 576, but not defined == Outdated reference: A later version (-09) exists of draft-ietf-rtgwg-mrt-frr-algorithm-06 == Outdated reference: A later version (-10) exists of draft-ietf-rtgwg-mrt-frr-architecture-07 ** 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: November 19, 2016 Huawei Technologies 6 A. Atlas 7 C. Bowers 8 Juniper Networks 9 J. Tantsura 10 Individual 11 May 18, 2016 13 Intermediate System to Intermediate System (IS-IS) Extensions for 14 Maximally Redundant Trees (MRT) 15 draft-ietf-isis-mrt-02 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 November 19, 2016. 47 Copyright Notice 49 Copyright (c) 2016 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 the future. However, this document restricts these extensions to 342 apply only to the default topology. The MRT Profile sub-TLV is 343 restricted by explicitly requiring the MT-ID field to be set to zero. 344 The MRT-Ineligible Link sub-TLV is restricted by only allowing it to 345 be included in the Extended IS Reachability TLV (TLV#22) which is 346 scoped to the default topology, and not allowing it to appear TLV#222 347 (the topology-scoped version of the Extended IS Reachability TLV). 349 Lifting these restrictions is for further study. Note that the MRT 350 signalling extensions in this document can co-exist with IS-IS multi- 351 topology routing, with the limitation that MRT Red and Blue 352 forwarding trees can only be built for the default topology. 354 The format of the Controlled Convergence sub-TLV (discussed below) 355 also contains an MT-ID field, allowing a Controlled Convergence sub- 356 TLV to be scoped to a particular topology. This document does not 357 place restrictions on the MT-ID field in the Controlled Convergence 358 sub-TLV. The Controlled Convergence sub-TLV has potential 359 applications that are not limited to MRT, and a topology-scoped FIB 360 compute/install time makes sense on its own. 362 6. Controlled Convergence sub-TLV in IS-IS Router CAPABILITY TLV 364 Section 12.2 of [I-D.ietf-rtgwg-mrt-frr-architecture] describes the 365 need to wait for a configured or advertised period after a network 366 failure to insure that all routers are using their new shortest path 367 trees. Similarly, avoiding micro-forwarding loops during convergence 368 [RFC5715] requires determining the maximum among all routers in the 369 area of the worst-case route computation and FIB installation time. 370 More details on the specific reasoning and need for flooding this 371 value are given in [I-D.atlas-bryant-shand-lf-timers]. 373 A new Controlled Convergence sub-TLV is introduced into the IS-IS 374 Router CAPABILITY TLV (TLV #242 defined in [RFC4971]) to advertise 375 the worst-case time for a router to compute and install all IS-IS 376 routes in the level after a change to a stable network. This 377 advertisement has per level scope, so the S-bit and D-bit of IS-IS 378 Router CAPABILITY TLV MUST be set to zero. The advertisement is 379 scoped by MT-ID, allowing a router supporting multi-topology routing 380 to advertise a different worst-case FIB compute/install time for each 381 topology. This makes sense as the SPF computations and FIB 382 installations for each IGP topology can potentially be done 383 independently of one another, and may have different worst-case 384 compute and install times. 386 The structure of the Controlled Convergence sub-TLV is shown below: 388 TYPE: TBA-MRT-ISIS-3 (To Be Allocated by IANA) 390 LENGTH: 3 392 VALUE: 394 MT-ID (2 octets with 4 bits reserved) 396 FIB compute/install time (1 octet) 398 Number of octets 399 +-------------------------------+ 400 |R |R |R |R | MT-ID | 2 401 +-------------------------------+ 402 | FIB compute/install time | 1 403 +-------------------------------+ 405 MT-ID is a 12-bit field containing the multi-topology ID. 407 The FIB compute/install time is the worst-case time the router may 408 take to compute and install all IS-IS routes in the level after a 409 change to a stable network. The value is an unsigned integer in 410 units of milliseconds. 412 The FIB compute/install time value sent by a router SHOULD be an 413 estimate taking into account network scale or real-time measurements, 414 or both. Advertisements SHOULD be dampened to avoid frequent 415 communication of small changes in the FIB compute/install time. 417 A router receiving the Controlled Convergence sub-TLV SHOULD estimate 418 the network convergence time as the maximum of the FIB compute/ 419 install times advertised by the routers in a level for a given MT-ID, 420 including itself. In order to account for routers that do not 421 advertise the Controlled Convergence sub-TLV, a router MAY use a 422 locally configured minimum network convergence time as a lower bound 423 on the computed network convergence time. A router MAY use a locally 424 configured maximum network convergence time as an upper bound on the 425 computed network convergence time. 427 7. Handling MRT Extensions 429 7.1. Advertising MRT extensions 431 MRT sub-TLVs are encapsulated in the Router Capability TLV and 432 advertised using the LS-PDU with level-wide scope. MRT sub-TLVs are 433 optional. If one router does not support MRT, it MUST NOT advertise 434 those sub-TLVs. 436 Since the advertisement scope of the MRT sub-TLV is level-wide, the 437 D-Bit and S-Bit of the Router Capability TLV MUST be set as 0 when it 438 is advertised. If other sub-TLVs in the Router Capability TLV need 439 different values for those two bits, then the router MUST originate 440 multiple Router Capability TLVs with different bit values. 442 When MRT-related information is changed for the router or existing 443 IS-IS LSP mechanisms are triggered for refreshing or updating, MRT 444 sub-TLVs MUST be advertised if the router is MRT-Capable. 446 Based on administrative policy, it may be desirable to exclude 447 certain links from the MRT computation. The MRT-Ineligible sub-TLV 448 is used to advertise which links should be excluded. Note that an 449 interface advertised as MRT-Ineligible by a router is ineligible with 450 respect to all profiles advertised by that router. 452 7.2. Processing MRT extensions 454 The processing associated with MRT extensions SHOULD NOT 455 significantly degrade IS-IS adjacency formation and maintenance or 456 the routing calculation for normal shortest path routes. 458 MRT sub-TLVs SHOULD be validated like other sub-TLVs when received. 459 MRT sub-TLVs SHOULD also be taken into account for checksum 460 calculations and authentication. 462 Links advertised as MRT-ineligible using the MRT-Ineligible sub-TLV 463 MUST be excluded from the MRT computation. The removal of individual 464 links from the MRT Island can partition an MRT Island or it can 465 significantly modify the construction of the GADAG and the result MRT 466 Red and Blue trees. Therefore, all routers must perform the same 467 computation using the same set of links. 469 8. Backward Compatibility 471 The MRT Profile sub-TLV, the MRT-Ineligible Link sub-TLV, and the 472 Controlled Convergence sub-TLV defined in this document are 473 compatible with existing implementations of IS-IS. Routers that do 474 not support these extensions are expected to silently ignore them. 476 Router that do support these extensions have mechanisms to recognize 477 routers that don't support these extensions (or are not configured to 478 participate in MRT) and behave accordingly. 480 9. Implementation Status 482 [RFC Editor: please remove this section prior to publication.] 484 Please see [I-D.ietf-rtgwg-mrt-frr-architecture] for details on 485 implementation status. 487 10. Security Considerations 489 The IS-IS extensions in this document do not introduce new security 490 concerns. 492 11. Acknowledgements 494 The authors would like to thank Shraddha Hegde for her useful 495 suggestions. 497 12. IANA Considerations 499 12.1. MRT Profile and Controlled Convergence sub-TLVs 501 IANA is requested to allocate values for the following sub-TLVs types 502 in the IS-IS Router CAPABILITY TLV defined in [RFC4971]: the MRT 503 Profile sub-TLV (TBA-MRT-ISIS-1) and Controlled Convergence sub-TLV 504 (TBA-MRT-ISIS-3). The IANA registry for these sub-TLV types is 505 displayed as "sub-TLVs for TLV 242" (http://www.iana.org/assignments/ 506 isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints- 507 242). The new entries in this registry are shown below. 509 Value Description Reference 510 -------------- ------------------------------ ------------ 511 TBA-MRT-ISIS-1 MRT Profile sub-TLV [This draft] 512 TBA-MRT-ISIS-3 Controlled Convergence sub-TLV [This draft] 514 12.2. MRT-Ineligible Link sub-TLV 516 IANA is requested to allocate a value for the following sub-TLVs type 517 in the Extended IS Reachability TLV defined in [RFC5305]: MRT- 518 Ineligible Link sub-TLV (TBA-MRT-ISIS-2). The IANA registry for 519 these sub-TLV types is displayed as "Sub-TLVs for TLVs 22, 23, 141, 520 222, and 223" (http://www.iana.org/assignments/isis-tlv-codepoints/ 521 isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-141-222-223). 522 The new entry in this registry is shown below. 524 Type Description 22 23 141 222 223 Ref. 525 -------------- --------------------------- -- -- --- --- --- -------- 526 TBA-MRT-ISIS-2 MRT-Ineligible Link sub-TLV y y n n n [This 527 draft] 529 13. References 531 13.1. Normative References 533 [I-D.ietf-rtgwg-mrt-frr-algorithm] 534 Envedi, G., Csaszar, A., Atlas, A., Bowers, C., and A. 535 Gopalan, "Algorithms for computing Maximally Redundant 536 Trees for IP/LDP Fast- Reroute", draft-ietf-rtgwg-mrt-frr- 537 algorithm-06 (work in progress), October 2015. 539 [I-D.ietf-rtgwg-mrt-frr-architecture] 540 Atlas, A., Kebler, R., Bowers, C., Envedi, G., Csaszar, 541 A., Tantsura, J., and R. White, "An Architecture for IP/ 542 LDP Fast-Reroute Using Maximally Redundant Trees", draft- 543 ietf-rtgwg-mrt-frr-architecture-07 (work in progress), 544 October 2015. 546 [RFC3787] Parker, J., Ed., "Recommendations for Interoperable IP 547 Networks using Intermediate System to Intermediate System 548 (IS-IS)", RFC 3787, DOI 10.17487/RFC3787, May 2004, 549 . 551 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 552 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 553 2008, . 555 13.2. Infomative References 557 [I-D.atlas-bryant-shand-lf-timers] 558 K, A. and S. Bryant, "Synchronisation of Loop Free Timer 559 Values", draft-atlas-bryant-shand-lf-timers-04 (work in 560 progress), February 2008. 562 [I-D.ietf-ospf-mrt] 563 Atlas, A., Hegde, S., Bowers, C., Tantsura, J., and Z. Li, 564 "OSPF Extensions to Support Maximally Redundant Trees", 565 draft-ietf-ospf-mrt-01 (work in progress), October 2015. 567 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 568 dual environments", RFC 1195, DOI 10.17487/RFC1195, 569 December 1990, . 571 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 572 Requirement Levels", BCP 14, RFC 2119, 573 DOI 10.17487/RFC2119, March 1997, 574 . 576 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 577 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 578 RFC 4915, DOI 10.17487/RFC4915, June 2007, 579 . 581 [RFC4971] Vasseur, JP., Ed., Shen, N., Ed., and R. Aggarwal, Ed., 582 "Intermediate System to Intermediate System (IS-IS) 583 Extensions for Advertising Router Information", RFC 4971, 584 DOI 10.17487/RFC4971, July 2007, 585 . 587 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 588 Topology (MT) Routing in Intermediate System to 589 Intermediate Systems (IS-ISs)", RFC 5120, 590 DOI 10.17487/RFC5120, February 2008, 591 . 593 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 594 DOI 10.17487/RFC5308, October 2008, 595 . 597 [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free 598 Convergence", RFC 5715, DOI 10.17487/RFC5715, January 599 2010, . 601 Authors' Addresses 603 Zhenbin Li 604 Huawei Technologies 605 Huawei Bld., No.156 Beiqing Rd. 606 Beijing 100095 607 China 609 Email: lizhenbin@huawei.com 611 Nan Wu 612 Huawei Technologies 613 Huawei Bld., No.156 Beiqing Rd. 614 Beijing 100095 615 China 617 Email: eric.wu@huawei.com 618 Quintin Zhao 619 Huawei Technologies 620 125 Nagog Technology Park 621 Acton, MA 01719 622 USA 624 Alia Atlas 625 Juniper Networks 626 10 Technology Park Drive 627 Westford, MA 01886 628 USA 630 Email: akatlas@juniper.net 632 Chris Bowers 633 Juniper Networks 634 1194 N. Mathilda Ave. 635 Sunnyvale, CA 94089 636 USA 638 Email: cbowers@juniper.net 640 Jeff Tantsura 641 Individual 642 USA 644 Email: jefftant.ietf@gmail.com