idnits 2.17.1 draft-ietf-ospf-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 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 (January 19, 2015) is 3378 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) == Unused Reference: 'RFC5340' is defined on line 559, but no explicit reference was found in the text == Unused Reference: 'RFC3137' is defined on line 578, but no explicit reference was found in the text == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-lsa-extend-05 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-03 -- 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 4970 (Obsoleted by RFC 7770) -- Obsolete informational reference (is this intentional?): RFC 3137 (Obsoleted by RFC 6987) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 6 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: July 23, 2015 Juniper Networks 6 J. Tantsura 7 Ericsson 8 Z. Li 9 Huawei Technologies 10 January 19, 2015 12 OSPF Extensions to Support Maximally Redundant Trees 13 draft-ietf-ospf-mrt-00 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 July 23, 2015. 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 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 . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . 12 83 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 84 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 85 12.1. Normative References . . . . . . . . . . . . . . . . . . 13 86 12.2. Informative References . . . . . . . . . . . . . . . . . 13 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 89 1. Introduction 91 This document describes the OSPF extensions necessary to support the 92 architecture that defines how IP/LDP Fast-Reroute can use MRTs 93 [I-D.ietf-rtgwg-mrt-frr-architecture]. At least one common 94 standardized algorithm (such as the lowpoint algorithm explained and 95 fully documented in [I-D.ietf-rtgwg-mrt-frr-algorithm]) is required 96 so that the routers supporting MRT computation consistently compute 97 the same MRTs. MRT can also be used to protect multicast traffic via 98 either global protection or local 99 protection.[I-D.atlas-rtgwg-mrt-mc-arch] 101 IP/LDP Fast-Reroute using MRTs can provide 100% coverage for link and 102 node failures in an arbitrary network topology where the failure 103 doesn't split the network. It can also be deployed incrementally 104 inside an OSPF area; an MRT Island is formed of connected supporting 105 routers and the MRTs are computed inside that island. 107 In the default MRT profile, a supporting router both computes the 108 MRTs and creates the necessary transit forwarding state necessary to 109 provide the two additional forwarding topologies, known as MRT-Blue 110 and MRT-Red. 112 2. Requirements Language 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119] 118 3. Terminology 120 For ease of reading, some of the terminology defined in 121 [I-D.ietf-rtgwg-mrt-frr-architecture] is repeated here. 123 network graph: A graph that reflects the network topology where all 124 links connect exactly two nodes and broadcast links have been 125 transformed into the standard pseudo-node representation. 127 Redundant Trees (RT): A pair of trees where the path from any node 128 X to the root R along the first tree is node-disjoint with the 129 path from the same node X to the root along the second tree. 130 These can be computed in 2-connected graphs. 132 Maximally Redundant Trees (MRT): A pair of trees where the path 133 from any node X to the root R along the first tree and the path 134 from the same node X to the root along the second tree share the 135 minimum number of nodes and the minimum number of links. Each 136 such shared node is a cut-vertex. Any shared links are cut-links. 137 Any RT is an MRT but many MRTs are not RTs. 139 MRT Island: From the computing router, the set of routers that 140 support a particular MRT profile and are connected via MRT- 141 eligible links. 143 GADAG: Generalized Almost Directed Acyclic Graph - a graph that is 144 the combination of the ADAGs of all blocks. Transforming a 145 network graph into a GADAG is part of the MRT algorithm. 147 MRT-Red: MRT-Red is used to describe one of the two MRTs; it is 148 used to described the associated forwarding topology and MT-ID. 149 Specifically, MRT-Red is the decreasing MRT where links in the 150 GADAG are taken in the direction from a higher topologically 151 ordered node to a lower one. 153 MRT-Blue: MRT-Blue is used to describe one of the two MRTs; it is 154 used to described the associated forwarding topology and MT-ID. 155 Specifically, MRT-Blue is the increasing MRT where links in the 156 GADAG are taken in the direction from a lower topologically 157 ordered node to a higher one. 159 4. Overview of OSPF Extensions for MRT 161 There are two separate aspects that need to be advertised in OSPF. 162 Both derive from the need for all routers supporting an MRT profile 163 to compute the same pair of MRTs to each destination. By executing 164 the same algorithm on the same network graph, distributed routers 165 will compute the same MRTs. Convergence considerations are discussed 166 in [I-D.ietf-rtgwg-mrt-frr-architecture]. 168 The first aspect that must be advertised is which MRT profile(s) are 169 supported and the associated GADAG Root Selection Priority. The 170 second aspect that must be advertised is any links that are not 171 eligible, due to administrative policy, to be part of the MRTs. This 172 must be advertised consistently across the area so that all routers 173 in the MRT Island use the same network graph. 175 4.1. Supporting MRT Profiles 177 An MRT Profile defines the exact MRT Algorithm, the MRT-Red LDP MT- 178 ID, the MRT-Blue LDP MT-ID, and the forwarding mechanisms supported 179 for the transit MRT-Red and MRT-Blue forwarding topologies. Finally, 180 the MRT Profile defines exact behavioral rules such as: 182 o how reconvergence is handled, 184 o inter-area forwarding behavior, 186 A router that advertises support for an MRT Profile MUST provide the 187 specified forwarding mechanism for its MRT-Red and MRT-Blue 188 forwarding topologies. A router that advertises support for an MRT 189 Profile MUST implement an algorithm that produces the same set of 190 MRT-Red and MRT-Blue next-hops for its MRT-Red and MRT-Blue 191 topologies as is provided by the algorithm specified in the MRT 192 Profile. 194 A router MAY indicate support for multiple MRT Profiles. A router 195 computes its local MRT Island for each separate MRT Profile that the 196 router supports. Supporting multiple MRT Profiles also provides a 197 mechanism for transitioning from one profile to another. Different 198 uses of MRT forwarding topologies may behave better on different MRT 199 profiles. 201 The default MRT Profile is defined in 202 [I-D.ietf-rtgwg-mrt-frr-architecture]. Its behavior is intended to 203 support IP/LDP unicast and multicast fast-reroute. 205 4.2. GADAG Root Selection 207 One aspect of the MRT algorithms is that the selection of the GADAG 208 root can affect the alternates and the traffic through that GADAG 209 root. Therefore, it is important to provide an operator with control 210 over which router will play the role of GADAG root. A measure of the 211 centrality of a node may help determine how good a choice a 212 particular node is. 214 The GADAG Root Selection Policy (defined as part of an MRT profile) 215 may make use of the GADAG Root Selection Priority value advertised in 216 the MRT Profile TLV of the Router Information LSA. For example, the 217 GADAG Root Selection Policy for the default MRT profile is the 218 following: Among the routers in the MRT Island and with the highest 219 priority advertised, an implementation MUST pick the router with the 220 highest Router ID to be the GADAG root. 222 4.3. Triggering an MRT Computation 224 When an MRT Computation is triggered, it is triggered for a given MRT 225 Profile in a given area. First, the associated MRT Island is 226 determined. Then, the GADAG Root is selected. Finally, the actual 227 MRT algorithm is run to compute the transit MRT-Red and MRT-Blue 228 topologies. Additionally, the router MAY choose to compute MRT-FRR 229 alternates or make other use of the MRT computation results. 231 Prefixes can be attached and detached and have their associated MRT- 232 Red and MRT-Blue next-hops computed without requiring a new MRT 233 computation. 235 5. MRT Capability Advertisement 237 A router that supports MRT indicates this by setting a newly defined 238 M bit in the Router LSA. If the router provides no other information 239 via a separate MRT Profile TLV, then the router supports the default 240 MRT Profile with a GADAG Root Selection Priority of 128. 242 In addition, a router can advertise a newly-defined MRT Profile TLV 243 within the scope of the OSPF router information LSA [RFC4970]. This 244 TLV also includes the GADAG Root Selection Priority. 246 5.1. Advertising MRT Capability in OSPFv2 248 A new M-bit is defined in the Router-LSA (defined in [RFC2328] and 249 updated in [RFC4915]), as pictured below. 251 0 1 2 3 252 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 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | LS age | Options | 1 | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Link State ID | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Advertising Router | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | LS sequence number | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | LS checksum | length | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 |*|*|M|N|W|V|E|B| 0 | # links | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Link ID | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Link Data | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Type | # MT-ID | metric | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | MT-ID | 0 | MT-ID metric | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | ... | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | MT-ID | 0 | MT-ID metric | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Link ID | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Link Data | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | ... | 284 M-bit in OSPFv2 Router LSA 286 M bit: When set, the router supports MRT. If no separate MRT 287 Profile TLV is advertised in the associated Router Information 288 LSA, then the router supports the default MRT Profile and has a 289 GADAG Root Selection Priority of 128. 291 5.2. Advertising MRT Capability in OSPFv3 293 Similarly, the M-bit is defined in the OSPFv3 Router LSA as shown 294 below. Since there can be multiple router LSAs, the M-bit needs to 295 be set on all of them. 297 0 1 2 3 298 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 299 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | LS Age |0|0|1| 1 | 301 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Link State ID | 303 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Advertising Router | 305 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | LS Sequence Number | 307 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | LS Checksum | Length | 309 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | 0|M|Nt|x|V|E|B| Options | 311 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Type | 0 | Metric | 313 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Interface ID | 315 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Neighbor Interface ID | 317 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Neighbor Router ID | 319 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | ... | 321 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Type | 0 | Metric | 323 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Interface ID | 325 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Neighbor Interface ID | 327 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Neighbor Router ID | 329 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | ... | 332 M-bit in OSPFv3 Router LSA 334 M bit: When set, the router supports MRT. If no separate MRT 335 Profile TLV is advertised in the associated Router Information 336 LSA, then the router supports the default MRT Profile and has a 337 GADAG Root Selection Priority of 128. 339 5.3. MRT Profile TLV in Router Information LSA 341 A router may advertise an MRT Profile TLV to indicate support for 342 multiple MRT Profiles, for a non-default MRT Profile, and/or to 343 indicate a non-default GADAG Root Selection Priority. The MRT 344 Profile TLV is advertised within the OSPF router information LSA 345 which is defined for both OSPFv2 and OSPFv3 in [RFC4970]. The RI LSA 346 MUST have area scope. 348 0 1 2 3 349 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 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Type | Length | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Profile ID(1) |GADAG Priority | Reserved | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | .............. | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Profile ID(n) |GADAG Priority | Reserved | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 TYPE: TBA-MRT-OSPF-1 (To Be Allocated by IANA) 361 LENGTH: 4 * (number of Profiles) 362 Profile ID : 1 byte 363 GADAG Priority: 1 byte 365 MRT Profile TLV in Router Information LSA 367 Each Profile ID listed indicates support for a given MRT Profile, as 368 defined in [I-D.ietf-rtgwg-mrt-frr-architecture]. A Profile ID value 369 of 0 corresponds to the default MRT profile. 371 The GADAG Priority is the GADAG Root Selection Priority associated 372 with the advertising router in the MRT Island for the associated MRT 373 Profile, as indicated by the Profile ID. If multiple MRT Profiles 374 are supported, then the length of this TLV varies. The ordering of 375 the profiles inside the TLV is not significant. Multiple appearances 376 of this TLV is not an error. 378 Lack of support for the default MRT profile is indicated by the 379 presence of an MRT Profile TLV with a non-zero Profile ID value, and 380 the absence of an MRT Profile TLV with a zero Profile ID value. 382 6. Advertising MRT-ineligible links for MRT 384 Due to adminstrative policy, some otherwise eligible links in the 385 network topology may need to be excluded from the network graph upon 386 which the MRT algorithm is run. Since the same network graph must be 387 used across the area, it is critical for OSPF to flood which links to 388 exclude from the MRT calculation. This is done by introducing a new 389 MRT-Ineligible Link sub-TLV. For OSPFv2, this sub-TLV is carried in 390 the Extended Link TLV defined in 391 [I-D.ietf-ospf-segment-routing-extensions]. For OSPFv3, this sub-TLV 392 is carried in the Router-Link TLV defined in 393 [I-D.ietf-ospf-ospfv3-lsa-extend]. 395 If a link is marked by administrative policy as MRT-Ineligible, then 396 a router MUST flood the OSPFv2 Extended Link TLV (or OSPFv3 Router- 397 Link TLV) for that link, including the MRT-Ineligible Link sub-TLV. 398 The OSPVv2 Extended Link TLV and OSPFv3 Router-Link TLV have area 399 wide scope. 401 6.1. MRT-Ineligible Link sub-TLV 403 0 1 2 3 404 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 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Type | Length | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 TYPE: TBA-MRT-OSPF-2 in OSPFv2 Extended Link TLV 410 TBA-MRT-OSPF-3 in OSPFv3 Router-Link TLV 411 (To Be Allocated by IANA) 412 LENGTH: 0 414 MRT-Ineligible Link sub-TLV 416 This zero-length sub-TLV can appear in the OSPFv2 Extended Link TLV 417 or the OSPFv3 Router-Link TLV. Its presence indicates that the 418 associated link MUST NOT be used in the MRT calculation for all 419 profiles. 421 7. Worst-Case Network Convergence Time 423 As part of converging the network after a single failure, 424 Section 12.2 of [I-D.ietf-rtgwg-mrt-frr-architecture] describes the 425 need to wait for a configured or advertised period for all routers to 426 be using their new SPTs. Similarly, any work on avoiding micro- 427 forwarding loops during convergence[RFC5715] requires determining the 428 maximum among all routers in the area of the worst-case route 429 computation and FIB installation time. More details on the specific 430 reasoning and need for flooding it are given in 431 [I-D.atlas-bryant-shand-lf-timers]. 433 0 1 2 3 434 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 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | Type | Length | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | Reserved | FIB compute/install time | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 TYPE: TBA-MRT-OSPF-4 (To Be Allocated by IANA) 442 LENGTH: 4 443 FIB compute/install time: This is the worst-case time the router 444 may take to compute and install all OSPF routes in the area 445 after a change to a stable network. The value is 446 in milliseconds. 448 Controlled Convergence TLV in Router Information LSA 450 The Controlled Convergence TLV is carried in the Router Information 451 LSA and flooded with area-wide scope. The FIB compute/install time 452 value sent by a router SHOULD be an estimate taking into account 453 network scale or real-time measurements, or both. Advertisements 454 SHOULD be dampened to avoid frequent communication of small changes 455 in the FIB compute/install time. 457 A router receiving the Controlled Convergence sub-TLV SHOULD estimate 458 the network convergence time as the maximum of the FIB compute/ 459 install times advertised by the routers in an area, including itself. 460 In order to account for routers that do not advertise the Controlled 461 Convergence sub-TLV, a router MAY use a locally configured minimum 462 network convergence time as a lower bound on the computed network 463 convergence time. A router MAY use a locally configured maximum 464 network convergence time as an upper bound on the computed network 465 convergence time. 467 8. Backwards Compatibility 469 The MRT capability bit, the MRT Profile, the MRT-Ineligible Link, and 470 the OSPFv3 MRT-Ineligible Link TLVs are defined in this document. 471 They should not introduce any interoperability issues. Routers that 472 do not support the MRT capability bit in the router LSA SHOULD 473 silently ignore it. Routers that do not support the new MRT-related 474 TLVs SHOULD silently ignore them. 476 8.1. Handling MRT Capability Changes 478 When a router changes from supporting MRT to not supporting MRT, it 479 is possible that Router Information LSAs with MRT-related TLVs remain 480 in the neighbors' database briefly. Such MRT-related TLVs SHOULD be 481 ignored when the associated Router LSA from that router does not have 482 the MRT capability set in its Router LSA. 484 When a router changes from not supporting MRT to supporting MRT, it 485 will flood its Router LSA(s) with the M-bit set and may send an 486 updated Router Information LSA. If a Router LSA is received with the 487 M-bit newly set, an MRT computation SHOULD be scheduled but MAY be 488 delayed up to 60 seconds to allow reception of updated related Router 489 Information LSAs. In general, when changes in MRT-related 490 information is received, an MRT computation SHOULD be triggered. 492 The rationale behind using the M bit in router LSA is to handle the 493 MRT capability changes gracefully in case of version upgrade/ 494 downgrade. The M bit in router LSA ensures the latest "MRT 495 capability" information is available for computation when there is a 496 downgrade to the version that doesn't support MRT and RI LSA. 498 9. Implementation Status 500 [RFC Editor: please remove this section prior to publication.] 502 Please see [I-D.ietf-rtgwg-mrt-frr-architecture] for details on 503 implementation status. 505 10. Security Considerations 507 This OSPF extension is not believed to introduce new security 508 concerns. It relies upon the security architecture already provided 509 for Router LSAs and Router Information LSAs. 511 11. IANA Considerations 513 IANA is requested to allocate values for the following OSPF Router 514 Information TLV Types [RFC4970]: MRT Profile TLV (TBA-MRT-OSPF-1), 515 and Controlled Convergence TLV (TBA-MRT-OSPF-4). 517 IANA is requested to allocate a value from the OSPF Extended Link LSA 518 sub-TLV registry [I-D.ietf-ospf-segment-routing-extensions] for the 519 MRT-Ineligible Link sub-TLV (TBA-MRT-OSPF-2). 521 IANA is requested to allocate a value from the OSPFv3 Extended-LSA 522 sub-TLV registry [I-D.ietf-ospf-ospfv3-lsa-extend] for the MRT- 523 Ineligible Link sub-TLV (TBA-MRT-OSPF-3). 525 12. References 527 12.1. Normative References 529 [I-D.ietf-ospf-ospfv3-lsa-extend] 530 Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3 531 LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-05 532 (work in progress), November 2014. 534 [I-D.ietf-ospf-segment-routing-extensions] 535 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 536 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 537 Extensions for Segment Routing", draft-ietf-ospf-segment- 538 routing-extensions-03 (work in progress), December 2014. 540 [I-D.ietf-rtgwg-mrt-frr-algorithm] 541 Enyedi, G., Csaszar, A., Atlas, A., Bowers, C., and A. 542 Gopalan, "Algorithms for computing Maximally Redundant 543 Trees for IP/LDP Fast-Reroute", draft-rtgwg-mrt-frr- 544 algorithm-01 (work in progress), July 2014. 546 [I-D.ietf-rtgwg-mrt-frr-architecture] 547 Atlas, A., Kebler, R., Bowers, C., Enyedi, G., Csaszar, 548 A., Tantsura, J., Konstantynowicz, M., and R. White, "An 549 Architecture for IP/LDP Fast-Reroute Using Maximally 550 Redundant Trees", draft-rtgwg-mrt-frr-architecture-04 551 (work in progress), July 2014. 553 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 555 [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. 556 Shaffer, "Extensions to OSPF for Advertising Optional 557 Router Capabilities", RFC 4970, July 2007. 559 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 560 for IPv6", RFC 5340, July 2008. 562 12.2. Informative References 564 [I-D.atlas-bryant-shand-lf-timers] 565 K, A. and S. Bryant, "Synchronisation of Loop Free Timer 566 Values", draft-atlas-bryant-shand-lf-timers-04 (work in 567 progress), February 2008. 569 [I-D.atlas-rtgwg-mrt-mc-arch] 570 Atlas, A., Kebler, R., Wijnands, I., Csaszar, A., and G. 571 Envedi, "An Architecture for Multicast Protection Using 572 Maximally Redundant Trees", draft-atlas-rtgwg-mrt-mc- 573 arch-02 (work in progress), July 2013. 575 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 576 Requirement Levels", BCP 14, RFC 2119, March 1997. 578 [RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D. 579 McPherson, "OSPF Stub Router Advertisement", RFC 3137, 580 June 2001. 582 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 583 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 584 4915, June 2007. 586 [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free 587 Convergence", RFC 5715, January 2010. 589 Authors' Addresses 591 Alia Atlas 592 Juniper Networks 593 10 Technology Park Drive 594 Westford, MA 01886 595 USA 597 Email: akatlas@juniper.net 599 Shraddha Hegde 600 Juniper Networks 601 Embassy Business Park 602 Bangalore, KA 560093 603 India 605 Email: shraddha@juniper.net 607 Chris Bowers 608 Juniper Networks 609 1194 N. Mathilda Ave. 610 Sunnyvale, CA 94089 611 USA 613 Email: cbowers@juniper.net 614 Jeff Tantsura 615 Ericsson 616 300 Holger Way 617 San Jose, CA 95134 618 USA 620 Email: jeff.tantsura@ericsson.com 622 Zhenbin Li 623 Huawei Technologies 624 Huawei Bld., No.156 Beiqing Rd. 625 Beijing 100095 626 China 628 Email: lizhenbin@huawei.com