idnits 2.17.1 draft-ietf-isis-mrt-00.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 9, 2015) is 3357 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 91, but not defined == Missing Reference: 'RFC1195' is mentioned on line 612, but not defined == Missing Reference: 'RFC5308' is mentioned on line 630, but not defined == Missing Reference: 'RFC2119' is mentioned on line 615, but not defined == Missing Reference: 'RFC5120' is mentioned on line 626, but not defined == Missing Reference: 'RFC4915' is mentioned on line 618, but not defined == Missing Reference: 'RFC4971' is mentioned on line 622, but not defined ** Obsolete undefined reference: RFC 4971 (Obsoleted by RFC 7981) -- Looks like a reference, but probably isn't: '0' on line 380 -- Looks like a reference, but probably isn't: '255' on line 380 == Missing Reference: 'RFC5715' is mentioned on line 633, but not defined == Missing Reference: 'I-D.atlas-bryant-shand-lf-timers' is mentioned on line 607, but not defined == Unused Reference: 'RFC3137' is defined on line 597, but no explicit reference was found in the text -- No information found for draft-rtgwg-mrt-frr-algorithm - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-rtgwg-mrt-frr-algorithm' -- No information found for draft-rtgwg-mrt-frr-architecture - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-rtgwg-mrt-frr-architecture' ** Obsolete normative reference: RFC 3137 (Obsoleted by RFC 6987) ** Downref: Normative reference to an Informational RFC: RFC 3787 Summary: 3 errors (**), 0 flaws (~~), 11 warnings (==), 7 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: August 13, 2015 Huawei Technologies 6 A. Atlas 7 C. Bowers 8 Juniper Networks 9 J. Tantsura 10 Ericsson 11 February 9, 2015 13 Intermediate System to Intermediate System (IS-IS) Extensions for 14 Maximally Redundant Trees (MRT) 15 draft-ietf-isis-mrt-00 17 Abstract 19 This document describes necessary extensions to IS-IS to support the 20 distributed computation of Maximally Redundant Trees (MRT). Some 21 example uses of the MRTs include IP/LDP Fast-Reroute and global 22 protection or live-live for multicast traffic. The extensions 23 indicate what MRT profile(s) each router supports. Different MRT 24 profiles can be defined to support different uses and to allow 25 transition of capabilities. An extension is introduced to flood MRT- 26 Ineligible links, due to administrative policy. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on August 13, 2015. 45 Copyright Notice 47 Copyright (c) 2015 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 64 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 4. Using MRT with Multi-Topology IGP Routing . . . . . . . . . . 4 66 5. Overview of IS-IS Signaling Extensions for MRT . . . . . . . 5 67 5.1. Supporting MRT Profiles . . . . . . . . . . . . . . . . . 6 68 5.2. Electing GADAG Root . . . . . . . . . . . . . . . . . . . 6 69 5.3. Advertising MRT-Ineligible Links for MRT . . . . . . . . 7 70 5.4. Triggering an MRT Computation . . . . . . . . . . . . . . 7 71 6. MRT Capability Advertisement . . . . . . . . . . . . . . . . 7 72 6.1. Advertising MRT Capability in IS-IS LSP . . . . . . . . . 7 73 6.2. MRT Profile sub-TLV in IS-IS Router CAPABILITY TLV . . . 8 74 6.3. MRT-Ineligible Links sub-TLV in IS-IS Router CAPABILITY 75 TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 7. Controlled Convergence sub-TLV in IS-IS Router CAPABILITY TLV 10 77 8. Handling MRT Capability Sending and Receiving . . . . . . . . 11 78 8.1. Advertising MRT extension . . . . . . . . . . . . . . . . 12 79 8.2. Parsing MRT extension . . . . . . . . . . . . . . . . . . 12 80 9. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 12 81 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 13 82 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 83 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 84 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 85 13.1. Normative References . . . . . . . . . . . . . . . . . . 13 86 13.2. Infomative References . . . . . . . . . . . . . . . . . 14 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 89 1. Introduction 91 The IS-IS protocol is specified in [ISO10589], with extensions for 92 supporting IPv4 and IPv6 specified in [RFC1195] and [RFC5308]. Each 93 Intermediate System (IS) (router) advertises one or more IS-IS Link 94 State Protocol Data Units (LSPs) with routing information. Each LSP 95 is composed of a fixed header and a number of tuples, each consisting 96 of a Type, a Length, and a Value. Such tuples are commonly known as 97 TLVs, and are a good way of encoding information in a flexible and 98 extensible format. 100 [I-D.ietf-rtgwg-mrt-frr-architecture] gives a complete solution for 101 IP/LDP fast-reroute using Maximally Redundant Trees (MRT) to provide 102 alternates. This document describes the necessary signaling 103 extensions for supporting MRT-FRR used in IS-IS routing domain. 105 2. Requirements Language 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in [RFC2119]. 111 3. Terminology 113 Redundant Trees (RT): A pair of trees where the path from any node X 114 to the root R along the first tree is node-disjoint with the path 115 from the same node X to the root R along the second tree. These can 116 be computed in 2-connected graphs. 118 Maximally Redundant Trees (MRT): A pair of trees where the path from 119 any node X to the root R along the first tree and the path from the 120 same node X to the root R along the second tree share the minimum 121 number of nodes and the minimum number of links. Each such shared 122 node is a cut-vertex. Any shared links are cut-links. Any RT is an 123 MRT but many MRTs are not RTs. 125 MRT Island: From the computing router, the set of routers that 126 support a particular MRT profile and are connected via MRT- eligible 127 links. 129 GADAG: Generalized Almost Directed Acyclic Graph - a graph which is 130 the combination of the ADAGs of all blocks. Transforming a network 131 graph into a GADAG is part of the MRT algorithm. 133 MRT-Red: MRT-Red is used to describe one of the two MRTs; it is used 134 to describe the associated forwarding topology and MT-ID. 135 Specifically, MRT-Red is the decreasing MRT where links in the GADAG 136 are taken in the direction from a higher topologically ordered node 137 to a lower one. 139 MRT-Blue: MRT-Blue is used to describe one of the two MRTs; it is 140 used to describe the associated forwarding topology and MT-ID. 141 Specifically, MRT-Blue is the increasing MRT where links in the GADAG 142 are taken in the direction from a lower topologically ordered node to 143 a higher one. 145 4. Using MRT with Multi-Topology IGP Routing 147 Both IS-IS and OSPF have support for multi-topology routing (see 148 [RFC5120] for ISIS and [RFC4915] for OSPF.) In addition to the 149 standard topology (identified by MT-ID=0), these extensions allow the 150 IGP to identify particular links and nodes as participating in 151 additional topologies (identified by MT-ID!=0). A given link can 152 belong to several topologies and be assigned different metrics in 153 each topology. The IGP runs an independent SPF computation for each 154 topology, finding independent shortest paths to prefixes in each 155 topology. 157 It is straightforward to extend the MRT computations to multi- 158 topology IGP routing. For each IGP topology identified by an IGP MT- 159 ID, we need to identify the node and links belonging to an MRT Island 160 for that IGP MT-ID. This process creates a graph for the MRT Island 161 for that specific IGP MT-ID, which can then be used to compute the 162 transit next-hops and alternate next-hops for MRT-Red and MRT-Blue 163 for that specific IGP MT-ID. 165 We expect that initial implementation and deployments of MRT will be 166 primarily concerned with computing MRT-Red and Blue trees for the 167 standard topology (IGP MT-ID=0). However, we have chosen to specify 168 the IS-IS MRT extensions to accommodate the computation of MRT-Red 169 and MRT-Blue in a multi-topology IS-IS environment. This comes at 170 the expense of 2-6 octets per TLV for MT-ID values, but it will allow 171 for standards-based multi-topology aware MRT implementations for ISIS 172 without any future standards work. 174 Using MRT in a multi-topology IGP environment does have one 175 complication which should be discussed. Forwarding LDP traffic over 176 MRT paths in the standard IGP topology requires the use of labels 177 bound to topology-scoped FECs to identify traffic on MRT-Red and Blue 178 trees. This is described in Section 6 of 179 [I-D.ietf-rtgwg-mrt-frr-architecture]. To facilitate this, an MRT 180 profile specifies IANA-assigned MRT-Red and MRT-Blue LDP MT-ID 181 values, which are then used by LDP to advertise labels for the MRT- 182 Red and Blue forwarding topologies. Note that the MRT-Red and MRT- 183 Blue LDP MT-ID values assigned by IANA for a given MRT profile 184 correspond to the MRT-Red and Blue forwarding trees associated with 185 the standard IGP topology with IGP MT-ID=0. For example, suppose 186 that a future MRT profile X is assigned (hypothetical) MRT-Red and 187 MRT-Blue LDP MT-ID values of 2001 and 2002. Then labels for shortest 188 path forwarding trees associated with the standard IGP topology will 189 be advertised using FECs with MT-ID=0, while the labels for the MRT- 190 Red and Blue forwarding trees for profile X will be advertised using 191 FECS with MT-ID=2001 and 2002, respectively. In the absence of 192 multi-topology IGP routing, all MT-IDs used by LDP for MRT are 193 assigned by IANA, so there are no potential conflicts in LDP MT-ID 194 usage. 196 When MRT is used together with multi-topology IGP routing, additional 197 LDP MT-IDs need to be specified for carrying traffic on the MRT-Red 198 and Blue forwarding trees associated with the additional IGP routing 199 topologies. Building on the previous example, suppose that a network 200 is configured with an additional IGP routing topology using MT-ID=20, 201 in addition to the standard topology with MT-ID=0. The router 202 advertises support for MRT with respect to MT-ID=20 with profile X, 203 as well as support for MRT with respect to MT-ID=0 with profile X. 204 The MRT-Red and Blue LDP MT-IDs for MT-ID=0 with profile X are still 205 inherited from profile X, as in the previous example. In order to 206 use LDP to create the MRT-Red and Blue forwarding trees for the IGP 207 topology with MT-ID=20, the router could, for example, advertise MRT- 208 Red and MRT-Blue LDP MT-ID values of 21 and 22 for IGP MT-ID=20 and 209 profile X. This overrides the (hypothetical) IANA-assigned values 210 MRT-Red and MRT-Blue LDP MT-ID values for profile X, but maintains 211 all other properties of profile X. Care must be taken to avoid 212 advertising LDP MT-ID values that conflict with implicitly advertised 213 IANA-assigned values LDP MT-ID. 215 The semantics of the IS-IS MRT extensions in this document are 216 designed to handle the most common case (MRT in the absence of multi- 217 topology IGP routing) in a simple manner. Setting the IGP MT-ID 218 field as well as the MRT-Blue and MRT-Red LDP MT-ID fields to 0 in 219 the TLV and sub-TLVs in this document results in the desired behavior 220 for the standard IGP topology. 222 5. Overview of IS-IS Signaling Extensions for MRT 224 As stated in [I-D.ietf-rtgwg-mrt-frr-algorithm], it is necessary for 225 each MRT-Capable router to compute MRT next hops in a consistent 226 fashion. This is achieved by using same MRT profile and selecting 227 the unique root in a MRT Island which is connected by MRT-Eligible 228 links. Each of these issues will be discussed in following sections 229 separately. 231 5.1. Supporting MRT Profiles 233 The contents and requirements of an MRT profile has been defined in 234 [I-D.ietf-rtgwg-mrt-frr-architecture]. The parameters and behavioral 235 rules contained in an MRT profile define one router's MRT 236 capabilities. Based on common capabilities, one unified MRT Island 237 is built. 239 The MRT-Capable router MUST advertise its corresponding MRT profiles 240 by IS-IS protocol extension within IS-IS routing domain. The 241 capabilities of advertiser MUST conform to the profile it claimed 242 completely, especially the MT-IDs, the algorithm and the 243 corresponding forwarding mechanism. This advertisement MUST have 244 level scope. One router MAY support multiple MRT profiles and it 245 MUST advertise these profiles in corresponding IS-IS level. The MT- 246 IDs used in one supported MRT Profile MUST NOT overlap with those MT- 247 IDs used in a different supported MRT Profile. 249 The default MRT Profile is defined in 250 [I-D.ietf-rtgwg-mrt-frr-architecture]. Its behavior is intended to 251 support IP/LDP unicast and multicast Fast-Reroute. MRT-Capable 252 routers SHOULD support the default MRT profile. 254 5.2. Electing GADAG Root 256 As per [I-D.ietf-rtgwg-mrt-frr-algorithm], a GADAG root MUST be 257 selected for one MRT Island. An unique GADAG root in common-sense 258 among MRT Island routers is a necessity to do MRT computation. Since 259 the selection of the GADAG root can affect the alternates and the 260 traffic through it, the selection rules give network operator a knob 261 to control the alternates and the traffic inside the MRT Island. 262 Relevant discussion for the relationship between GADAG root role and 263 MRT Island alternates is out of the scope of this document. 265 Each MRT-Capable router MUST advertise its priority for GADAG root 266 selection. One router can only have one priority in the same MRT 267 Island. It can have multiple priorities for different MRT Islands it 268 supports. Routers that are marked as overloaded([RFC3787]) are not 269 qualified as candidate for root selection. 271 The GADAG Root Selection Policy (defined as part of an MRT profile) 272 may make use of the GADAG Root Selection Priority value advertised in 273 the MRT Profile in the IS-IS Router CAPABILITY TLV. For example, the 274 GADAG Root Selection Policy for the default MRT profile is the 275 following: Among the routers in the MRT Island and with the highest 276 priority advertised, an implementation MUST pick the router with the 277 highest Router ID to be the GADAG root. 279 When the current root is out of service or new router with higher 280 priority joined into the MRT Island, the GADAG root MUST be re- 281 selected. A new MRT computation will be triggered because of such a 282 topology change. 284 5.3. Advertising MRT-Ineligible Links for MRT 286 For certain administrative or management reason, some links may not 287 be involved into MRT computation. In this scenario, MRT-Capable 288 router MUST claim those MRT-Ineligible links are out of MRT Island 289 scope. If such claim splits current MRT Island then MRT computation 290 has to be done inside the modified MRT Island which the computing 291 router belongs to. 293 5.4. Triggering an MRT Computation 295 A MRT Computation can be triggered through topology changes or MRT 296 capability changes of any router in the MRT Island. It is always 297 triggered for a given MRT Profile in the corresponding level. First, 298 the associated MRT Island is determined. Then, the GADAG Root is 299 selected. Finally, the actual MRT algorithm is run to compute the 300 transit MRT-Red and MRT-Blue topologies. Additionally, the router 301 MAY choose to compute MRT-FRR alternates or make other use of the MRT 302 computation results. 304 Prefixes can be attached and detached and have their associated MRT- 305 Red and MRT-Blue next-hops computed without requiring a new MRT 306 computation. 308 6. MRT Capability Advertisement 310 MRT-Capable router MUST identify its MRT capabilities through IS-IS 311 Link State Packet(LSP) in level scope. 313 6.1. Advertising MRT Capability in IS-IS LSP 315 One new M-bit is introduced into TLV 229 to identify router is MRT- 316 Capable. Structure of TLV 229 is stated in [RFC5120] as pictured 317 below: 319 TYPE: 229 321 LENGTH: total length of the value field, it SHOULD be 2 times the 322 number of MT components. 324 VALUE: one or more 2-byte MT components, structured as follows: 326 No. of Octets 327 +--------------------------------+ 328 |O |A |M |R | MT ID | 2 329 +--------------------------------+ 331 Bit M identifies the originator is of MRT-Capable. The MRT-Blue and 332 the MRT-Red alternates will be calculated for the MT identified by 333 MT-ID. 335 This M-bit MUST be set and checked in LSP fragment 0. A MRT-Capable 336 router MUST advertise this TLV with M-bit set for corresponding MT. 337 For instance, if M-bit is set for MT-ID #0, MRT alternates will be 338 calculated for standard topology. 340 If only M-bit is advertised for MRT-Capabilities without any other 341 MRT information then the router is regarded as supporting default MRT 342 profile with default GADAG root selection priority. 344 6.2. MRT Profile sub-TLV in IS-IS Router CAPABILITY TLV 346 A new MRT Profile sub-TLV is introduced into IS-IS Router CAPABILITY 347 TLV[RFC4971] to advertise MRT capabilities. Since MRT is per level 348 scope, the S-bit and D-bit of IS-IS Router CAPABILITY TLV MUST be set 349 to zero. The structure of the MRT Profile sub-TLV is pictured as 350 below: 352 TYPE: TBA-MRT-ISIS-1 (To Be Allocated by IANA) 354 LENGTH: 8 356 VALUE: 358 MT ID (2 octet with 4 bits reserved) 360 Profile ID (1 octet) 362 MRT-Red LDP MT-ID (2 octet) 364 MRT-Blue LDP MT-ID (2 octet) 365 +--------------------------------+ 366 |R |R |R |R | MT ID | 2 367 +----------------+---------------+ 368 | Profile ID | 1 369 +----------------+ 370 | GADAG Priority | 1 371 +----------------+---------------+ 372 | MRT-Red LDP MT-ID | 2 373 +--------------------------------+ 374 | MRT-Blue LDP MT-ID | 2 375 +--------------------------------+ 377 12-bit MT ID represents the base MT topology which MRT computation is 378 based on. Profile ID represents the MRT profile this router supports 379 and GADAG Root Selection Priority is the priority for root selection. 380 The range of this priority is [0, 255] with 128 as the default value. 381 The GADAG Root Selection Policy defined as part of a given MRT 382 profile determine how the GADAG Root Selection Priority value is 383 used. 385 If the MRT-Blue LDP MT-ID is 0, then the value specified in the 386 associated MRT Profile is assumed. If the MRT-Red LDP MT-ID is 0, 387 then the value specified in the associated MRT profile is assumed. 388 The MRT-Blue LDP MT-ID and MRT-Red LDP MT-ID MUST NOT be the reserved 389 values for LDP MT-IDs ([I-D.ietf-mpls-ldp-multi-topology] ). The 390 value for MRT-Blue LDP MT-ID and MRT-Red LDP MT-ID MUST be different 391 except for 0. As stated above, the MRT-Blue LDP MT-ID and MRT-Red 392 LDP MT-ID MUST NOT overlap among profiles if multiple MRT-Profile 393 sub-TLVs are advertised. 395 This sub-TLV can occur multiple times if this router support multiple 396 MRT profiles. This can happen during transition or to support 397 multiple uses of MRT which prefer different profiles. 399 6.3. MRT-Ineligible Links sub-TLV in IS-IS Router CAPABILITY TLV 401 As a matter of policy, some links may not be available for the MRT 402 computation, which can prevent alternates or traffic using these 403 links. For instance, policy can be made to prevent fast-rerouted 404 traffic from taking those links. 406 For a link to be excluded from the MRT computation, it MUST be 407 advertised as sub-TLV in IS-IS Router CAPABILITY TLV which is in 408 level scope with S-bit and D-bit unset. The MRT-Ineligible Link sub- 409 TLV is structured as below: 411 TYPE: TBA-MRT-ISIS-2 (To Be Allocated by IANA) 412 LENGTH: from 9 to 255 octets 414 VALUE: 416 MT ID (2 octet with 4 bits reserved) 418 System ID and pseudo-node number (7 octet for each MRT-Ineligible 419 Link) 421 No. of Octets 422 +--------------------------------+ 423 |R |R |R |R | MT ID | 2 424 +--------------------------------+ 425 |System ID and pseudonode number | 7 426 +--------------------------------+ 427 | Default metric | 3 428 +--------------------------------+ 429 . . 430 . . 431 +--------------------------------+ 432 |System ID and pseudonode number | 7 433 +--------------------------------+ 434 | Default metric | 3 435 +--------------------------------+ 437 Each MRT-Ineligible Link is identified by neighbor's System ID and 438 pseudo-node number and Default metric, same as IS Reachability TLV. 439 This sub-TLV MAY occur multiple times if multiple links are 440 ineligible. 442 7. Controlled Convergence sub-TLV in IS-IS Router CAPABILITY TLV 444 Section 12.2 of [I-D.ietf-rtgwg-mrt-frr-architecture] describes the 445 need to wait for a configured or advertised period after a network 446 failure to insure that all routers are using their new SPTs. 447 Similarly, avoiding micro-forwarding loops during convergence 448 [RFC5715] requires determining the maximum among all routers in the 449 area of the worst-case route computation and FIB installation time. 450 More details on the specific reasoning and need for flooding this 451 value are given in [I-D.atlas-bryant-shand-lf-timers]. 453 A new Controlled Convergence sub-TLV is introduced into the IS-IS 454 Router CAPABILITY TLV [RFC4971] to advertise the worst-case time for 455 a router to compute and install all IS-IS routes in the level after a 456 change to a stable network. This advertisement has per level scope, 457 so the S-bit and D-bit of IS-IS Router CAPABILITY TLV MUST be set to 458 zero. The advertisement is scoped by IGP MT-ID, allowing a router 459 supporting multi-topology IGP routing to advertise a different worst- 460 case compute and install time for each IGP topology. This make sense 461 as the SPF computations for each IGP topology are independent of one 462 another, and may have different worst-case compute and install times. 464 The structure of the Controlled Convergence sub-TLV is shown below: 466 TYPE: TBA-MRT-ISIS-3 (To Be Allocated by IANA) 468 LENGTH: 3 470 VALUE: 472 MT ID (2 octet with 4 bits reserved) 474 FIB compute/install time (1 octet) 476 +--------------------------------+ 477 |R |R |R |R | MT ID | 2 478 +----------------+---------------+ 479 |FIB comp/in time| 1 480 +----------------+ 482 The FIB compute/install time is the worst-case time the router may 483 take to compute and install all IS-IS routes in the level after a 484 change to a stable network. The value is in milliseconds. 486 The FIB compute/install time value sent by a router SHOULD be an 487 estimate taking into account network scale or real-time measurements, 488 or both. Advertisements SHOULD be dampened to avoid frequent 489 communication of small changes in the FIB compute/install time. 491 A router receiving the Controlled Convergence sub-TLV SHOULD estimate 492 the network convergence time as the maximum of the FIB compute/ 493 install times advertised by the routers in a level, including itself. 494 In order to account for routers that do not advertise the Controlled 495 Convergence sub-TLV, a router MAY use a locally configured minimum 496 network convergence time as a lower bound on the computed network 497 convergence time. A router MAY use a locally configured maximum 498 network convergence time as an upper bound on the computed network 499 convergence time. 501 8. Handling MRT Capability Sending and Receiving 503 The M-bit which identifies router's MRT capability MUST be advertised 504 in LSP fragment 0. Those MRT related sub-TLVs SHOULD be ignored when 505 MRT Capability bit is unset. When changes in MRT capabilities are 506 received, a MRT computation SHOULD be triggered but MAY be delayed 507 for a while to allow reception of all MRT-related information. 509 8.1. Advertising MRT extension 511 MRT sub-TLVs are encapsulated in the Router Capability TLV and 512 advertised through LSP PDU for the level-wide. MRT sub-TLVs are 513 optional. If one router does not support MRT, it MUST NOT advertise 514 those sub-TLVs. 516 Since the advertisement scope of the MRT sub-TLV is level-wide, the 517 D-Bit and S-Bit of the Router Capability TLV MUST be set as 0 when it 518 is advertised. If other sub-TLVs in the Router Capability TLV need 519 different values for those two bits, there MUST be an independent 520 Router Capability TLV for MRT sub-TLVs. 522 When MRT related information is changed for the router or existing 523 IS-IS LSP mechanisms are triggered for refreshing or updating, MRT 524 sub-TLVs MUST be advertised if the router is MRT-Capable. 526 For administrative policies or reasons, it may be desirable to 527 exclude certain links from the MRT computation. MRT-Ineligible sub- 528 TLV is used to advertise which links should be excluded. Note that 529 an interface advertised as MRT-Ineligigle by a router is ineligible 530 with respect to all profiles advertised by that router. 532 8.2. Parsing MRT extension 534 MRT extension MUST NOT affect the peer setup and the routing 535 calculation of the standard topology. 537 MRT sub-TLVs SHOULD be validated like other sub-TLVs when received. 538 MRT sub-TLVs SHOULD also be taken for the checksum calculation and 539 authentication. 541 If MT-ID conflict is found for MRT-Red or MRT-blue from multiple sub- 542 TLVs then those associated sub-TLVs MUST be ignored. 544 Links advertised in MRT-Ineligible sub-TLV MUST be precluded from MRT 545 Computation. The removal of those links may change the computing 546 router's MRT Island significantly. 548 9. Backwards Compatibility 550 The M-bit for MRT capability, the MRT Profile sub-TLV and the MRT- 551 Ineligible Link sub-TLV defined in this document SHOULD NOT introduce 552 any interoperability issues. Routers that do not support these MRT 553 extensions SHOULD silently ignore them. Alternates or traffic MUST 554 NOT be affected in current IS-IS routing domain. 556 10. Implementation Status 558 [RFC Editor: please remove this section prior to publication.] 560 Please see [I-D.ietf-rtgwg-mrt-frr-architecture] for details on 561 implementation status. 563 11. Security Considerations 565 This IS-IS extension is not believed to introduce new security 566 concerns. 568 12. IANA Considerations 570 Please allocate values for the following IS-IS Router CAPABILITY TLV 571 Types [RFC4971]: MRT Profile sub-TLV (TBA-MRT-ISIS-1), MRT-Ineligible 572 Link sub-TLV (TBA-MRT-ISIS-2), and Controlled Convergence sub-TLV 573 (TBA-MRT-ISIS-3). 575 13. References 577 13.1. Normative References 579 [I-D.ietf-mpls-ldp-multi-topology] 580 Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D. 581 King, "LDP Extensions for Multi Topology", draft-ietf- 582 mpls-ldp-multi-topology-12 (work in progress), April 2014. 584 [I-D.ietf-rtgwg-mrt-frr-algorithm] 585 Enyedi, G., Csaszar, A., Atlas, A., Bowers, C., and A. 586 Gopalan, "Algorithms for computing Maximally Redundant 587 Trees for IP/LDP Fast-Reroute", draft-rtgwg-mrt-frr- 588 algorithm-01 (work in progress), July 2014. 590 [I-D.ietf-rtgwg-mrt-frr-architecture] 591 Atlas, A., Kebler, R., Bowers, C., Enyedi, G., Csaszar, 592 A., Tantsura, J., Konstantynowicz, M., and R. White, "An 593 Architecture for IP/LDP Fast-Reroute Using Maximally 594 Redundant Trees", draft-rtgwg-mrt-frr-architecture-04 595 (work in progress), July 2014. 597 [RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D. 598 McPherson, "OSPF Stub Router Advertisement", RFC 3137, 599 June 2001. 601 [RFC3787] Parker, J., "Recommendations for Interoperable IP Networks 602 using Intermediate System to Intermediate System (IS-IS)", 603 RFC 3787, May 2004. 605 13.2. Infomative References 607 [I-D.atlas-bryant-shand-lf-timers] 608 K, A. and S. Bryant, "Synchronisation of Loop Free Timer 609 Values", draft-atlas-bryant-shand-lf-timers-04 (work in 610 progress), February 2008. 612 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 613 dual environments", RFC 1195, December 1990. 615 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 616 Requirement Levels", BCP 14, RFC 2119, March 1997. 618 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 619 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 620 4915, June 2007. 622 [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate 623 System to Intermediate System (IS-IS) Extensions for 624 Advertising Router Information", RFC 4971, July 2007. 626 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 627 Topology (MT) Routing in Intermediate System to 628 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 630 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 631 2008. 633 [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free 634 Convergence", RFC 5715, January 2010. 636 Authors' Addresses 638 Zhenbin Li 639 Huawei Technologies 640 Huawei Bld., No.156 Beiqing Rd. 641 Beijing 100095 642 China 644 Email: lizhenbin@huawei.com 645 Nan Wu 646 Huawei Technologies 647 Huawei Bld., No.156 Beiqing Rd. 648 Beijing 100095 649 China 651 Email: eric.wu@huawei.com 653 Quintin Zhao 654 Huawei Technologies 655 125 Nagog Technology Park 656 Acton, MA 01719 657 USA 659 Alia Atlas 660 Juniper Networks 661 10 Technology Park Drive 662 Westford, MA 01886 663 USA 665 Email: akatlas@juniper.net 667 Chris Bowers 668 Juniper Networks 669 1194 N. Mathilda Ave. 670 Sunnyvale, CA 94089 671 USA 673 Email: cbowers@juniper.net 675 Jeff Tantsura 676 Ericsson 677 300 Holger Way 678 San Jose, CA 95134 679 USA 681 Email: jeff.tantsura@ericsson.com