idnits 2.17.1 draft-ietf-ospf-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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 18, 2015) is 3106 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: 'RFC1584' is mentioned on line 560, but not defined == Missing Reference: 'RFC3101' is mentioned on line 561, but not defined == Unused Reference: 'RFC3137' is defined on line 680, but no explicit reference was found in the text == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-lsa-extend-08 == 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 ** Obsolete normative reference: RFC 4970 (Obsoleted by RFC 7770) -- Obsolete informational reference (is this intentional?): RFC 3137 (Obsoleted by RFC 6987) Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OSPF Working Group A. Atlas 3 Internet-Draft S. Hegde 4 Intended status: Standards Track C. Bowers 5 Expires: April 20, 2016 Juniper Networks 6 J. Tantsura 7 Ericsson 8 Z. Li 9 Huawei Technologies 10 October 18, 2015 12 OSPF Extensions to Support Maximally Redundant Trees 13 draft-ietf-ospf-mrt-01 15 Abstract 17 This document specifies extensions to OSPF to support the distributed 18 computation of Maximally Redundant Trees (MRT). Some example uses of 19 the MRTs include IP/LDP Fast-Reroute and global protection or live- 20 live for multicast traffic. The extensions indicate what MRT 21 profile(s) each router supports. Different MRT profiles can be 22 defined to support different uses and to allow transitioning of 23 capabilities. An extension is introduced to flood MRT-Ineligible 24 links, due to administrative policy. 26 The need for a mechanism to allow routers to advertise a worst-case 27 FIB compute/install time is well understood for controlling 28 convergence. This specification introduces the Controlled 29 Convergence TLV to be carried in the Router Information LSA. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 20, 2016. 48 Copyright Notice 50 Copyright (c) 2015 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 67 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 4. Overview of OSPF Extensions for MRT . . . . . . . . . . . . . 4 69 4.1. Supporting MRT Profiles . . . . . . . . . . . . . . . . . 4 70 4.2. GADAG Root Selection . . . . . . . . . . . . . . . . . . 5 71 4.3. Triggering an MRT Computation . . . . . . . . . . . . . . 5 72 5. MRT Capability Advertisement . . . . . . . . . . . . . . . . 6 73 5.1. Advertising MRT Capability in OSPFv2 . . . . . . . . . . 6 74 5.2. Advertising MRT Capability in OSPFv3 . . . . . . . . . . 7 75 5.3. MRT Profile TLV in Router Information LSA . . . . . . . . 8 76 6. Advertising MRT-ineligible links for MRT . . . . . . . . . . 10 77 6.1. MRT-Ineligible Link sub-TLV . . . . . . . . . . . . . . . 10 78 7. Worst-Case Network Convergence Time . . . . . . . . . . . . . 10 79 8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 11 80 8.1. Handling MRT Capability Changes . . . . . . . . . . . . . 12 81 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 12 82 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 83 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 84 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 85 12.1. M-bit . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 12.2. MRT Profile and Controlled Convergence TLVs . . . . . . 14 87 12.3. MRT-Ineligible Link sub-TLV . . . . . . . . . . . . . . 14 88 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 89 13.1. Normative References . . . . . . . . . . . . . . . . . . 14 90 13.2. Informative References . . . . . . . . . . . . . . . . . 15 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 93 1. Introduction 95 This document describes the OSPF extensions necessary to support the 96 architecture that defines how IP/LDP Fast-Reroute can use MRTs 97 [I-D.ietf-rtgwg-mrt-frr-architecture]. At least one common 98 standardized algorithm (such as the lowpoint algorithm explained and 99 fully documented in [I-D.ietf-rtgwg-mrt-frr-algorithm]) is required 100 so that the routers supporting MRT computation consistently compute 101 the same MRTs. MRT can also be used to protect multicast traffic via 102 either global protection or local 103 protection.[I-D.atlas-rtgwg-mrt-mc-arch] 105 IP/LDP Fast-Reroute using MRTs can provide 100% coverage for link and 106 node failures in an arbitrary network topology where the failure 107 doesn't split the network. It can also be deployed incrementally 108 inside an OSPF area; an MRT Island is formed of connected supporting 109 routers and the MRTs are computed inside that island. 111 In the default MRT profile, a supporting router both computes the 112 MRTs and creates the necessary transit forwarding state necessary to 113 provide the two additional forwarding topologies, known as MRT-Blue 114 and MRT-Red. 116 2. Requirements Language 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119] 122 3. Terminology 124 For ease of reading, some of the terminology defined in 125 [I-D.ietf-rtgwg-mrt-frr-architecture] is repeated here. 127 network graph: A graph that reflects the network topology where all 128 links connect exactly two nodes and broadcast links have been 129 transformed into the standard pseudo-node representation. 131 Redundant Trees (RT): A pair of trees where the path from any node 132 X to the root R along the first tree is node-disjoint with the 133 path from the same node X to the root along the second tree. 134 These can be computed in 2-connected graphs. 136 Maximally Redundant Trees (MRT): A pair of trees where the path 137 from any node X to the root R along the first tree and the path 138 from the same node X to the root along the second tree share the 139 minimum number of nodes and the minimum number of links. Each 140 such shared node is a cut-vertex. Any shared links are cut-links. 141 Any RT is an MRT but many MRTs are not RTs. 143 MRT Island: From the computing router, the set of routers that 144 support a particular MRT profile and are connected via MRT- 145 eligible links. 147 GADAG: Generalized Almost Directed Acyclic Graph - a graph that is 148 the combination of the ADAGs of all blocks. Transforming a 149 network graph into a GADAG is part of the MRT algorithm. 151 MRT-Red: MRT-Red is used to describe one of the two MRTs; it is 152 used to described the associated forwarding topology and MT-ID. 153 Specifically, MRT-Red is the decreasing MRT where links in the 154 GADAG are taken in the direction from a higher topologically 155 ordered node to a lower one. 157 MRT-Blue: MRT-Blue is used to describe one of the two MRTs; it is 158 used to described the associated forwarding topology and MT-ID. 159 Specifically, MRT-Blue is the increasing MRT where links in the 160 GADAG are taken in the direction from a lower topologically 161 ordered node to a higher one. 163 4. Overview of OSPF Extensions for MRT 165 There are two separate aspects that need to be advertised in OSPF. 166 Both derive from the need for all routers supporting an MRT profile 167 to compute the same pair of MRTs to each destination. By executing 168 the same algorithm on the same network graph, distributed routers 169 will compute the same MRTs. Convergence considerations are discussed 170 in [I-D.ietf-rtgwg-mrt-frr-architecture]. 172 The first aspect that must be advertised is which MRT profile(s) are 173 supported and the associated GADAG Root Selection Priority. The 174 second aspect that must be advertised is any links that are not 175 eligible, due to administrative policy, to be part of the MRTs. This 176 must be advertised consistently across the area so that all routers 177 in the MRT Island use the same network graph. 179 4.1. Supporting MRT Profiles 181 An MRT Profile defines the exact MRT Algorithm, the MRT-Red LDP MT- 182 ID, the MRT-Blue LDP MT-ID, and the forwarding mechanisms supported 183 for the transit MRT-Red and MRT-Blue forwarding topologies. Finally, 184 the MRT Profile defines exact behavioral rules such as: 186 o how reconvergence is handled, 187 o inter-area forwarding behavior, 189 A router that advertises support for an MRT Profile MUST provide the 190 specified forwarding mechanism for its MRT-Red and MRT-Blue 191 forwarding topologies. A router that advertises support for an MRT 192 Profile MUST implement an algorithm that produces the same set of 193 MRT-Red and MRT-Blue next-hops for its MRT-Red and MRT-Blue 194 topologies as is provided by the algorithm specified in the MRT 195 Profile. 197 A router MAY indicate support for multiple MRT Profiles. A router 198 computes its local MRT Island for each separate MRT Profile that the 199 router supports. Supporting multiple MRT Profiles also provides a 200 mechanism for transitioning from one profile to another. Different 201 uses of MRT forwarding topologies may behave better on different MRT 202 profiles. 204 The default MRT Profile is defined in 205 [I-D.ietf-rtgwg-mrt-frr-architecture]. Its behavior is intended to 206 support IP/LDP unicast and multicast fast-reroute. 208 4.2. GADAG Root Selection 210 One aspect of the MRT algorithms is that the selection of the GADAG 211 root can affect the alternates and the traffic through that GADAG 212 root. Therefore, it is important to provide an operator with control 213 over which router will play the role of GADAG root. A measure of the 214 centrality of a node may help determine how good a choice a 215 particular node is. 217 The GADAG Root Selection Policy (defined as part of an MRT profile) 218 may make use of the GADAG Root Selection Priority value advertised in 219 the MRT Profile TLV of the Router Information LSA. For example, the 220 GADAG Root Selection Policy for the default MRT profile is the 221 following: Among the routers in the MRT Island and with the highest 222 priority advertised, an implementation MUST pick the router with the 223 highest Router ID to be the GADAG root. 225 4.3. Triggering an MRT Computation 227 When an MRT Computation is triggered, it is triggered for a given MRT 228 Profile in a given area. First, the associated MRT Island is 229 determined. Then, the GADAG Root is selected. Finally, the actual 230 MRT algorithm is run to compute the transit MRT-Red and MRT-Blue 231 topologies. Additionally, the router MAY choose to compute MRT-FRR 232 alternates or make other use of the MRT computation results. 234 Prefixes can be attached and detached and have their associated MRT- 235 Red and MRT-Blue next-hops computed without requiring a new MRT 236 computation. 238 5. MRT Capability Advertisement 240 A router that supports MRT indicates this by setting a newly defined 241 M bit in the Router LSA. If the router provides no other information 242 via a separate MRT Profile TLV, then the router supports the default 243 MRT Profile with a GADAG Root Selection Priority of 128. 245 In addition, a router can advertise a newly-defined MRT Profile TLV 246 within the scope of the OSPF router information LSA [RFC4970]. This 247 TLV also includes the GADAG Root Selection Priority. 249 5.1. Advertising MRT Capability in OSPFv2 251 A new M-bit is defined in the Router-LSA (defined in [RFC2328] and 252 updated in [RFC4915]), as pictured below. 254 0 1 2 3 255 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | LS age | Options | 1 | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Link State ID | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Advertising Router | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | LS sequence number | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | LS checksum | length | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 |*|*|M|N|W|V|E|B| 0 | # links | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Link ID | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Link Data | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Type | # MT-ID | metric | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | MT-ID | 0 | MT-ID metric | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | ... | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | MT-ID | 0 | MT-ID metric | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Link ID | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Link Data | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | ... | 287 M-bit in OSPFv2 Router LSA 289 M bit: When set, the router supports MRT. If no separate MRT 290 Profile TLV is advertised in the associated Router Information 291 LSA, then the router supports the default MRT Profile for the 292 default MT topology and has a GADAG Root Selection Priority of 293 128. 295 5.2. Advertising MRT Capability in OSPFv3 297 Similarly, the M-bit is defined in the OSPFv3 Router LSA [RFC5340] as 298 shown below. Since there can be multiple router LSAs in OSPFv3, the 299 M-bit SHOULD be set in all of them. However, in the case of a 300 mismatch, the values in the LSA with the lowest Link State ID take 301 precedence. 303 0 1 2 3 304 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 305 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | LS Age |0|0|1| 1 | 307 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Link State ID | 309 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Advertising Router | 311 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | LS Sequence Number | 313 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | LS Checksum | Length | 315 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | 0|M|Nt|x|V|E|B| Options | 317 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Type | 0 | Metric | 319 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Interface ID | 321 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Neighbor Interface ID | 323 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Neighbor Router ID | 325 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | ... | 327 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Type | 0 | Metric | 329 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Interface ID | 331 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Neighbor Interface ID | 333 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Neighbor Router ID | 335 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | ... | 338 M-bit in OSPFv3 Router LSA 340 M bit: When set, the router supports MRT. If no separate MRT 341 Profile TLV is advertised in the associated Router Information 342 LSA, then the router supports the default MRT Profile for the 343 default MT topology and has a GADAG Root Selection Priority of 344 128. 346 5.3. MRT Profile TLV in Router Information LSA 348 A router may advertise an MRT Profile TLV to indicate support for 349 multiple MRT Profiles, for a non-default MRT Profile, and/or to 350 indicate a non-default GADAG Root Selection Priority. The MRT 351 Profile TLV is advertised within the OSPF router information LSA 352 which is defined for both OSPFv2 and OSPFv3 in [RFC4970]. The RI LSA 353 MUST have area scope. 355 Note that the presence of the MRT Profile TLV indicates support for a 356 given MRT profile in the default topology (MT-ID = 0). The 357 extensions in this document do not define a method to advertise 358 support for MRT profiles in topologies with non-zero MT-ID. 360 0 1 2 3 361 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Type | Length | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | Profile ID(1) |GADAG Priority | Reserved | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | .............. | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Profile ID(n) |GADAG Priority | Reserved | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 TYPE: TBA-MRT-OSPF-1 (To Be Allocated by IANA) 373 LENGTH: 4 * (number of Profiles) 374 Profile ID : 1 byte 375 GADAG Priority: 1 byte 377 MRT Profile TLV in Router Information LSA 379 Each Profile ID listed indicates support for a given MRT Profile, as 380 defined in [I-D.ietf-rtgwg-mrt-frr-architecture]. A Profile ID value 381 of 0 corresponds to the default MRT profile. 383 The GADAG Priority is the GADAG Root Selection Priority associated 384 with the advertising router in the MRT Island for the associated MRT 385 Profile, as indicated by the Profile ID. If multiple MRT Profiles 386 are supported, then the length of this TLV varies. The ordering of 387 the profiles inside the TLV is not significant. Multiple appearances 388 of this TLV is not an error. 390 Lack of support for the default MRT profile is indicated by the 391 presence of an MRT Profile TLV with a non-zero Profile ID value, and 392 the absence of an MRT Profile TLV with a zero Profile ID value. 394 6. Advertising MRT-ineligible links for MRT 396 Due to administrative policy, some otherwise eligible links in the 397 network topology may need to be excluded from the network graph upon 398 which the MRT algorithm is run. Since the same network graph must be 399 used across the area, it is critical for OSPF to flood which links to 400 exclude from the MRT calculation. This is done by introducing a new 401 MRT-Ineligible Link sub-TLV. For OSPFv2, this sub-TLV is carried in 402 the Extended Link TLV defined in [I-D.ietf-ospf-prefix-link-attr]. 403 For OSPFv3, this sub-TLV is carried in the Router-Link TLV defined in 404 [I-D.ietf-ospf-ospfv3-lsa-extend]. 406 If a link is marked by administrative policy as MRT-Ineligible, then 407 a router MUST flood the OSPFv2 Extended Link TLV (or OSPFv3 Router- 408 Link TLV) for that link, including the MRT-Ineligible Link sub-TLV. 409 The OSPVv2 Extended Link TLV and OSPFv3 Router-Link TLV have area 410 wide scope. 412 6.1. MRT-Ineligible Link sub-TLV 414 0 1 2 3 415 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Type | Length | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 TYPE: TBA-MRT-OSPF-2 in OSPFv2 Extended Link TLV 421 TBA-MRT-OSPF-3 in OSPFv3 Router-Link TLV 422 (To Be Allocated by IANA) 423 LENGTH: 0 425 MRT-Ineligible Link sub-TLV 427 This zero-length sub-TLV can appear in the OSPFv2 Extended Link TLV 428 or the OSPFv3 Router-Link TLV. Its presence indicates that the 429 associated link MUST NOT be used in the MRT calculation for all 430 profiles. 432 7. Worst-Case Network Convergence Time 434 As part of converging the network after a single failure, 435 Section 12.2 of [I-D.ietf-rtgwg-mrt-frr-architecture] describes the 436 need to wait for a configured or advertised period for all routers to 437 be using their new SPTs. Similarly, any work on avoiding micro- 438 forwarding loops during convergence[RFC5715] requires determining the 439 maximum among all routers in the area of the worst-case route 440 computation and FIB installation time. More details on the specific 441 reasoning and need for flooding it are given in 442 [I-D.atlas-bryant-shand-lf-timers]. 444 0 1 2 3 445 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | Type | Length | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | Reserved | FIB compute/install time | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 TYPE: TBA-MRT-OSPF-4 (To Be Allocated by IANA) 453 LENGTH: 4 454 FIB compute/install time: This is the worst-case time the router 455 may take to compute and install all OSPF routes in the area 456 after a change to a stable network. The value is 457 in milliseconds. 459 Controlled Convergence TLV in Router Information LSA 461 The Controlled Convergence TLV is carried in the Router Information 462 LSA and flooded with area-wide scope. The FIB compute/install time 463 value sent by a router SHOULD be an estimate taking into account 464 network scale or real-time measurements, or both. Advertisements 465 SHOULD be dampened to avoid frequent communication of small changes 466 in the FIB compute/install time. 468 A router receiving the Controlled Convergence sub-TLV SHOULD estimate 469 the network convergence time as the maximum of the FIB compute/ 470 install times advertised by the routers in an area, including itself. 471 In order to account for routers that do not advertise the Controlled 472 Convergence sub-TLV, a router MAY use a locally configured minimum 473 network convergence time as a lower bound on the computed network 474 convergence time. A router MAY use a locally configured maximum 475 network convergence time as an upper bound on the computed network 476 convergence time. 478 8. Backwards Compatibility 480 The MRT capability bit, the MRT Profile, the MRT-Ineligible Link, and 481 the OSPFv3 MRT-Ineligible Link TLVs are defined in this document. 482 They should not introduce any interoperability issues. Routers that 483 do not support the MRT capability bit in the router LSA SHOULD 484 silently ignore it. Routers that do not support the new MRT-related 485 TLVs SHOULD silently ignore them. 487 8.1. Handling MRT Capability Changes 489 When a router changes from supporting MRT to not supporting MRT, it 490 is possible that Router Information LSAs with MRT-related TLVs remain 491 in the neighbors' database briefly. Such MRT-related TLVs SHOULD be 492 ignored when the associated Router LSA from that router does not have 493 the M-bit set in its Router LSA. 495 When a router changes from not supporting MRT to supporting MRT, it 496 will flood its Router LSA(s) with the M-bit set and may send an 497 updated Router Information LSA. If a Router LSA is received with the 498 M-bit newly set, an MRT computation SHOULD be scheduled but MAY be 499 delayed up to 60 seconds to allow reception of updated related Router 500 Information LSAs. In general, when changes in MRT-related 501 information are received, an MRT computation SHOULD be triggered. 503 The rationale behind using the M-bit in the Router LSA is to properly 504 handle the MRT capability changes in case of software version 505 downgrade. Without the M-bit mechanism, routers would need to rely 506 only on the presence or absence of the MRT Profile TLV in the Router 507 Information LSA to determine which other routers support MRT. This 508 could lead the to following scenario. Router A is running a software 509 version supporting MRT and has MRT enabled with profile 0. 510 Therefore, router A advertises the MRT Profile TLV in the Router 511 Information LSA, and other routers in the network store that RI LSA. 512 Router A is downgraded to a version of software supporting neither 513 MRT nor the Router Information LSA. When router A restarts, it will 514 not originate the RI LSA, since it doesn't support it. However, the 515 other routers in the network will still have a RI LSA from router A 516 indicating support for MRT with profile 0. This is an undesirable 517 state. 519 Requiring the M-bit in the Router LSA avoids this scenario. Before 520 the software downgrade, router A originates a Router LSA with the 521 M-bit set. After the software downgrade, router A will originate a 522 new Router LSA with the M-bit unset. The M bit in router LSA ensures 523 the latest MRT capability information is available for computation 524 when there is a downgrade to a version that doesn't support MRT and 525 RI LSA. 527 9. Implementation Status 529 [RFC Editor: please remove this section prior to publication.] 531 Please see [I-D.ietf-rtgwg-mrt-frr-architecture] for details on 532 implementation status. 534 10. Security Considerations 536 This OSPF extension is not believed to introduce new security 537 concerns. It relies upon the security architecture already provided 538 for Router LSAs and Router Information LSAs. 540 11. Acknowledgements 542 The authors would like to thank Anil Kumar SN for his suggestions and 543 review. 545 12. IANA Considerations 547 12.1. M-bit 549 IANA is requested to allocate the M-bit(value 0x20 in the router 550 properties field of the Router-LSA) [RFC2328] [RFC4940] from the 551 OSPFv2 Router Properties Registry. The contents of the OSPFv2 Router 552 Properties Registry after implementing the above request is shown 553 below. 555 Value Description Reference 556 ----- ----------- --------- 557 0x01 B-bit [RFC2328] 558 0x02 E-bit [RFC2328] 559 0x04 V-bit [RFC2328] 560 0x08 W-bit [RFC1584] 561 0x10 Nt-bit [RFC3101] 562 0x20 M-bit [This draft] 564 This document also defines the corresponding M-bit for OSPFv3 Router- 565 LSAs. [RFC4940] created several IANA registries for OSPFv2 and 566 OSPFv3, including the OSPFv2 Router Properties Registry above. 567 However, it did not create a corresponding OSPFv3 Router Properties 568 Registry. [RFC5340] discusses the corresponding OSPFv2 bits which 569 were already defined at the time, and it indicates that those bits 570 have the same meaning in OSPFv3 as in OSPFv2. Therefore, it would be 571 reasonable to assume that the OSPFv2 Router Properties Registry also 572 applies to OSPFv3. This documents requests that IANA make this 573 assumption explicit in the following way. 575 IANA is requested to rename the "OSPFv2 Router Properties Registry" 576 to the "OSPF Router Properties Registry (both v2 and v3)". The 577 following text should remain in this document. 579 The IANA registry "OSPF Router Properties Registry (both v2 and v3)" 580 applies to the 8-bit field following the length field in the Router- 581 LSA in both OSPFv2 and OSPFv3. 583 12.2. MRT Profile and Controlled Convergence TLVs 585 IANA is requested to allocate values for the following OSPF Router 586 Information TLV Types [RFC4970]: MRT Profile TLV (TBA-MRT-OSPF-1), 587 and Controlled Convergence TLV (TBA-MRT-OSPF-4). The requested 588 entries in the OSPF Router Information (RI) TLVs registry are shown 589 below. 591 Type Value Capabilities Reference 592 ------------- ---------------------- ------------ 593 TBA-MRT-OSPF-1 MRT Profile TLV [This draft] 594 TBA-MRT-OSPF-4 Controlled Convergence TLV [This draft] 596 12.3. MRT-Ineligible Link sub-TLV 598 IANA is requested to allocate a value from the OSPF Extended Link TLV 599 sub-TLV registry defined in [I-D.ietf-ospf-prefix-link-attr] for the 600 MRT-Ineligible Link sub-TLV (TBA-MRT-OSPF-2). The OSPF Extended Link 601 TLV sub-TLV registry after implementing the above request is shown 602 below. 604 Value Description Reference 605 ------------- ---------------------- ------------ 606 0 Reserved [prefix-link-attr-draft] 607 TBA-MRT-OSPF-2 MRT-Ineligible Link sub-TLV [This draft] 608 2-32767 Unassigned [prefix-link-attr-draft] 609 32768-33023 Reserved for Experimental Use [prefix-link-attr-draft] 610 33024-65535 Reserved [prefix-link-attr-draft] 612 IANA is requested to allocate a value from the OSPFv3 Extended-LSA 613 sub-TLV registry [I-D.ietf-ospf-ospfv3-lsa-extend] for the MRT- 614 Ineligible Link sub-TLV (TBA-MRT-OSPF-3). The OSPFv3 Extended-LSA 615 sub-TLV registry has not yet been created by IANA. 617 13. References 619 13.1. Normative References 621 [I-D.ietf-ospf-ospfv3-lsa-extend] 622 Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3 623 LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-08 624 (work in progress), October 2015. 626 [I-D.ietf-ospf-prefix-link-attr] 627 Psenak, P., Gredler, H., rjs@rob.sh, r., Henderickx, W., 628 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 629 Advertisement", draft-ietf-ospf-prefix-link-attr-13 (work 630 in progress), August 2015. 632 [I-D.ietf-rtgwg-mrt-frr-algorithm] 633 Envedi, G., Csaszar, A., Atlas, A., Bowers, C., and A. 634 Gopalan, "Algorithms for computing Maximally Redundant 635 Trees for IP/LDP Fast- Reroute", draft-ietf-rtgwg-mrt-frr- 636 algorithm-06 (work in progress), October 2015. 638 [I-D.ietf-rtgwg-mrt-frr-architecture] 639 Atlas, A., Kebler, R., Bowers, C., Envedi, G., Csaszar, 640 A., Tantsura, J., and R. White, "An Architecture for IP/ 641 LDP Fast-Reroute Using Maximally Redundant Trees", draft- 642 ietf-rtgwg-mrt-frr-architecture-07 (work in progress), 643 October 2015. 645 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 646 DOI 10.17487/RFC2328, April 1998, 647 . 649 [RFC4940] Kompella, K. and B. Fenner, "IANA Considerations for 650 OSPF", BCP 130, RFC 4940, DOI 10.17487/RFC4940, July 2007, 651 . 653 [RFC4970] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 654 S. Shaffer, "Extensions to OSPF for Advertising Optional 655 Router Capabilities", RFC 4970, DOI 10.17487/RFC4970, July 656 2007, . 658 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 659 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 660 . 662 13.2. Informative References 664 [I-D.atlas-bryant-shand-lf-timers] 665 K, A. and S. Bryant, "Synchronisation of Loop Free Timer 666 Values", draft-atlas-bryant-shand-lf-timers-04 (work in 667 progress), February 2008. 669 [I-D.atlas-rtgwg-mrt-mc-arch] 670 Atlas, A., Kebler, R., Wijnands, I., Csaszar, A., and G. 671 Envedi, "An Architecture for Multicast Protection Using 672 Maximally Redundant Trees", draft-atlas-rtgwg-mrt-mc- 673 arch-02 (work in progress), July 2013. 675 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 676 Requirement Levels", BCP 14, RFC 2119, 677 DOI 10.17487/RFC2119, March 1997, 678 . 680 [RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D. 681 McPherson, "OSPF Stub Router Advertisement", RFC 3137, 682 DOI 10.17487/RFC3137, June 2001, 683 . 685 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 686 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 687 RFC 4915, DOI 10.17487/RFC4915, June 2007, 688 . 690 [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free 691 Convergence", RFC 5715, DOI 10.17487/RFC5715, January 692 2010, . 694 Authors' Addresses 696 Alia Atlas 697 Juniper Networks 698 10 Technology Park Drive 699 Westford, MA 01886 700 USA 702 Email: akatlas@juniper.net 704 Shraddha Hegde 705 Juniper Networks 706 Embassy Business Park 707 Bangalore, KA 560093 708 India 710 Email: shraddha@juniper.net 712 Chris Bowers 713 Juniper Networks 714 1194 N. Mathilda Ave. 715 Sunnyvale, CA 94089 716 USA 718 Email: cbowers@juniper.net 719 Jeff Tantsura 720 Ericsson 721 300 Holger Way 722 San Jose, CA 95134 723 USA 725 Email: jeff.tantsura@ericsson.com 727 Zhenbin Li 728 Huawei Technologies 729 Huawei Bld., No.156 Beiqing Rd. 730 Beijing 100095 731 China 733 Email: lizhenbin@huawei.com