idnits 2.17.1 draft-atlas-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 21, 2013) is 3833 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) == Outdated reference: A later version (-04) exists of draft-enyedi-rtgwg-mrt-frr-algorithm-03 ** Downref: Normative reference to an Informational draft: draft-enyedi-rtgwg-mrt-frr-algorithm (ref. 'I-D.enyedi-rtgwg-mrt-frr-algorithm') == Outdated reference: A later version (-10) exists of draft-ietf-rtgwg-mrt-frr-architecture-03 ** Obsolete normative reference: RFC 4970 (Obsoleted by RFC 7770) -- Obsolete informational reference (is this intentional?): RFC 3137 (Obsoleted by RFC 6987) Summary: 2 errors (**), 0 flaws (~~), 4 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 24, 2014 Juniper Networks 6 J. Tantsura 7 Ericsson 8 October 21, 2013 10 OSPF Extensions to Support Maximally Redundant Trees 11 draft-atlas-ospf-mrt-01 13 Abstract 15 This document specifies extensions to OSPF to support the distributed 16 computation of Maximally Redundant Trees (MRT). Some example uses of 17 the MRTs include IP/LDP Fast-Reroute and global protection or live- 18 live for multicast traffic. The extensions indicate what MRT 19 profile(s) each router supports. Different MRT profiles can be 20 defined to support different uses and to allow transitioning of 21 capabilities. An extension is introduced to flood MRT-Ineligible 22 links, due to administrative policy. 24 The need for a mechanism to allow routers to advertise a worst-case 25 FIB compute/install time is well understood for controlling 26 convergence. This specification introduces the Controlled 27 Convergence TLV to be carried in the Router Information LSA. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on April 24, 2014. 46 Copyright Notice 47 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 64 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 4. Overview of OSPF Extensions for MRT . . . . . . . . . . . . . 4 66 4.1. Supporting MRT Profiles . . . . . . . . . . . . . . . . . 4 67 4.2. GADAG Root Selection . . . . . . . . . . . . . . . . . . 5 68 4.3. Triggering an MRT Computation . . . . . . . . . . . . . . 5 69 5. MRT Capability Advertisement . . . . . . . . . . . . . . . . 5 70 5.1. Advertising MRT Capability in OSPFv2 . . . . . . . . . . 6 71 5.2. Advertising MRT Capability in OSPFv3 . . . . . . . . . . 7 72 5.3. MRT Profile TLV in Router Information LSA . . . . . . . . 8 73 6. Advertising MRT-ineligible links for MRT . . . . . . . . . . 8 74 6.1. MRT-Ineligible Links TLV for OSPFv2 . . . . . . . . . . . 9 75 6.2. MRT-Ineligible Link TLV for OSPFv3 . . . . . . . . . . . 9 76 7. Worst-Case Network Convergence Time . . . . . . . . . . . . . 10 77 8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 10 78 8.1. Handling MRT Capability Changes . . . . . . . . . . . . . 11 79 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 80 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 81 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 83 11.2. Informative References . . . . . . . . . . . . . . . . . 12 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 86 1. Introduction 88 This document describes the OSPF extensions necessary to support the 89 architecture that defines how IP/LDP Fast-Reroute can use MRTs 90 [I-D.ietf-rtgwg-mrt-frr-architecture]. At least one common 91 standardized algorithm (such as the lowpoint algorithm explained and 92 fully documented in [I-D.enyedi-rtgwg-mrt-frr-algorithm]) is required 93 so that the routers supporting MRT computation consistently compute 94 the same MRTs. MRT can also be used to protect multicast traffic via 95 either global protection or local 96 protection.[I-D.atlas-rtgwg-mrt-mc-arch] 98 IP/LDP Fast-Reroute using MRTs can provide 100% coverage for link and 99 node failures in an arbitrary network topology where the failure 100 doesn't split the network. It can also be deployed incrementally 101 inside an OSPF area; an MRT Island is formed of connected supporting 102 routers and the MRTs are computed inside that island. 104 In the default MRT profile, a supporting router both computes the 105 MRTs and creates the necessary transit forwarding state necessary to 106 provide the two additional forwarding topologies, known as MRT-Blue 107 and MRT-Red. 109 2. Requirements Language 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119] 115 3. Terminology 117 For ease of reading, some of the terminology defined in 118 [I-D.ietf-rtgwg-mrt-frr-architecture] is repeated here. 120 network graph: A graph that reflects the network topology where all 121 links connect exactly two nodes and broadcast links have been 122 transformed into the standard pseudo-node representation. 124 Redundant Trees (RT): A pair of trees where the path from any node 125 X to the root R along the first tree is node-disjoint with the 126 path from the same node X to the root along the second tree. 127 These can be computed in 2-connected graphs. 129 Maximally Redundant Trees (MRT): A pair of trees where the path 130 from any node X to the root R along the first tree and the path 131 from the same node X to the root along the second tree share the 132 minimum number of nodes and the minimum number of links. Each 133 such shared node is a cut-vertex. Any shared links are cut-links. 134 Any RT is an MRT but many MRTs are not RTs. 136 MRT Island: From the computing router, the set of routers that 137 support a particular MRT profile and are connected via MRT- 138 eligible links. 140 GADAG: Generalized Almost Directed Acyclic Graph - a graph that is 141 the combination of the ADAGs of all blocks. Transforming a 142 network graph into a GADAG is part of the MRT algorithm. 144 MRT-Red: MRT-Red is used to describe one of the two MRTs; it is 145 used to described the associated forwarding topology and MT-ID. 146 Specifically, MRT-Red is the decreasing MRT where links in the 147 GADAG are taken in the direction from a higher topologically 148 ordered node to a lower one. 150 MRT-Blue: MRT-Blue is used to describe one of the two MRTs; it is 151 used to described the associated forwarding topology and MT-ID. 152 Specifically, MRT-Blue is the increasing MRT where links in the 153 GADAG are taken in the direction from a lower topologically 154 ordered node to a higher one. 156 4. Overview of OSPF Extensions for MRT 158 There are two separate aspects that need to be advertised in OSPF. 159 Both derive from the need for all routers supporting an MRT profile 160 to compute the same pair of MRTs to each destination. By executing 161 the same algorithm on the same network graph, distributed routers 162 will compute the same MRTs. Convergence considerations are discussed 163 in [I-D.ietf-rtgwg-mrt-frr-architecture]. 165 The first aspect that must be advertised is which MRT profile(s) are 166 supported and the associated GADAG Root Selection Priority. The 167 second aspect that must be advertised is any links that are not 168 eligible, due to administrative policy, to be part of the MRTs. This 169 must be advertised consistently across the area so that all routers 170 in the MRT Island use the same network graph. 172 4.1. Supporting MRT Profiles 174 An MRT Profile defines the exact MRT Algorithm, the MRT-Red MT-ID, 175 the MRT-Blue MT-ID, and the forwarding mechanisms supported for the 176 transit MRT-Red and MRT-Blue forwarding topologies. Finally, the MRT 177 Profile defines exact behavioral rules such as: 179 o how reconvergence is handled, 181 o inter-area forwarding behavior, 183 A router that advertises support for an MRT Profile MUST provide the 184 specified forwarding mechanism for its MRT-Red and MRT-Blue 185 forwarding topologies. A router that advertises support for an MRT 186 Profile MUST implement an algorithm that produces the same set of 187 MRT-Red and MRT-Blue next-hops for its MRT-Red and MRT-Blue 188 topologies as is provided by the algorithm specified in the MRT 189 Profile. 191 A router MAY indicate support for multiple MRT Profiles. A router 192 computes its local MRT Island for each separate MRT Profile that the 193 router supports. The MT-IDs used in one supported MRT Profile MUST 194 NOT overlap with those MT-IDs used in a different supported MRT 195 Profile. Supporting multiple MRT Profiles provides a mechanism for 196 transitioning from one profile to another. Different uses of MRT 197 forwarding topologies may behave better on different MRT profiles. 199 The default MRT Profile is defined in 200 [I-D.ietf-rtgwg-mrt-frr-architecture]. Its behavior is intended to 201 support IP/LDP unicast and multicast fast-reroute. 203 4.2. GADAG Root Selection 205 One aspect of the MRT algorithms is that the selection of the GADAG 206 root can affect the alternates and the traffic through that GADAG 207 root. Therefore, it is important to provide an operator with control 208 over which router will play the role of GADAG root. A measure of the 209 centrality of a node may help determine how good a choice a 210 particular node is. 212 GADAG Root selection is done using the GADAG Root Selection Priority 213 advertised in the MRT Profile TLV of the Router Information LSA. 214 When the MRTs need to be recalculated, the MRT Island is determined. 215 Inside the set of routers identified as in the MRT Island, routers 216 that are marked as unusable or overloaded (e.g. [RFC3137]) are 217 removed from consideration. Among the remaining routers, the router 218 with the highest GADAG Root Selection Priority is picked to be the 219 GADAG Root. If there are multiple at the same priority, then the 220 router with the highest Router ID is selected. 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 100. 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 100. 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 100. 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 [RFC4970]; the RI LSA MUST have area scope. 347 TYPE: To Be Allocated by IANA; experimental is 32772 348 LENGTH: 4 * (number of Profiles) 349 VALUE: 351 0 1 2 3 352 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 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Profile ID | GADAG Priority | Reserved | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 Profile ID 0: default MRT Profile 359 MRT Profile TLV in Router Information LSA 361 The GADAG Priority is the GADAG Root Selection Priority associated 362 with the advertising router in the MRT Island for the associated MRT 363 Profile, as indicated by the Profile ID. If multiple MRT Profiles 364 are supported, then the length of this TLV varies. The ordering of 365 the profiles inside the TLV is not significant. Multiple appearances 366 of this TLV is not an error. 368 6. Advertising MRT-ineligible links for MRT 370 Due to adminstrative policy, some otherwise eligible links in the 371 network topology may need to be excluded from the network graph upon 372 which the MRT algorithm is run. Since the same network graph must be 373 used across the area, it is critical for OSPF to flood which links to 374 exclude from the MRT calculation. This is done by introducing a new 375 MRT-Ineligible Links TLV to be carried in the Router Information LSA. 377 If a link is marked by administrative policy as MRT-Ineligible, then 378 a router MUST flood that link in either the MRT-Ineligible TLV or 379 OSPFv3 MRT-Ineligible TLV in the Router Information LSA. 381 6.1. MRT-Ineligible Links TLV for OSPFv2 383 MRT-Ineligible links are specified by the Link ID, Link Data, and 384 Type fields, as normally sent in the Router-LSA. See Section A4.1.2 385 of [RFC2328] for descriptions of these fields. 387 TYPE: To Be Allocated by IANA; experimental is 32773 388 LENGTH: 12 * (# of links) 389 VALUE: 390 0 1 2 3 391 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 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Link ID | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Link Data | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Type | Reserved | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 MRT-Ineligible Links TLV in Router Information LSA 402 Multiple links can be flooded as MRT-ineligible by listing them 403 inside the same TLV. The ordering of the links in the TLV is not 404 relevant. Multiple appearances of this TLV is not an error. 406 6.2. MRT-Ineligible Link TLV for OSPFv3 408 Since links are differently represented in OSPFv2 and OSPFv3, an 409 OSPFv3 MRT-Ineligible Link TLV is defined. 411 An OSPFv3 MRT-Ineligible Link is defined by its Interface ID, 412 Neighbor Interface ID, Neighbor Router ID, and Type fields. See 413 Appendix A4.1.3 [RFC5340] for the description of these fields. 415 TYPE: To Be Allocated by IANA; experimental is 32774 416 LENGTH: 16 * (# of links) 417 VALUE: 418 0 1 2 3 419 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 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Type | Reserved | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Interface ID | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Neighbor Interface ID | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Neighbor Router ID | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 MRT Profile TLV in Router Information LSA 432 Multiple links can be flooded as MRT-ineligible by listing them 433 inside the same TLV. The ordering of the links in the TLV is not 434 relevant. Multiple appearances of this TLV is not an error. 436 7. Worst-Case Network Convergence Time 438 As part of converging the network after a single failure, 439 Section 11.2 of [I-D.ietf-rtgwg-mrt-frr-architecture] describes the 440 need to wait for a configured or advertised period for all routers to 441 be using their new SPTs. Similarly, any work on avoiding micro- 442 forwarding loops during convergence[RFC5715] requires determining the 443 maximum among all routers in the area of the worst-case route 444 computation and FIB installation time. More details on the specific 445 reasoning and need for flooding it are given in 446 [I-D.atlas-bryant-shand-lf-timers]. 448 TYPE: To Be Allocated by IANA; experimental is 32775 449 LENGTH: 4 450 VALUE: 452 0 1 2 3 453 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 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Reserved | FIB compute/install time | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 FIB compute/install time: This is the worst-case time the router 459 may take to compute and install all OSPF routes in the area 460 after a change to a stable network. The value is 461 in milliseconds. 463 Controlled Convergence TLV in Router Information LSA 465 The Controlled Convergence TLV is carried in the Router Information 466 LSA and flooded with area-wide scope. A router MUST compute the 467 maximum FIB compute/install time from those flooded in the area. A 468 router MAY use a configured maximum time instead of using and 469 flooding the Controlled Convergence TLV. 471 8. Backwards Compatibility 472 The MRT capability bit, the MRT Profile, the MRT-Ineligible Link, and 473 the OSPFv3 MRT-Ineligible Link TLVs are defined in this document. 474 They should not introduce any interoperability issues. Routers that 475 do not support the MRT capability bit in the router LSA SHOULD 476 silently ignore it. Routers that do not support the new MRT-related 477 TLVs SHOULD silently ignore them. 479 8.1. Handling MRT Capability Changes 481 When a router changes from supporting MRT to not supporting MRT, it 482 is possible that Router Information LSAs with MRT-related TLVs remain 483 in the neighbors' database briefly. Such MRT-related TLVs SHOULD be 484 ignored when the associated Router LSA from that router does not have 485 the MRT capability set in its Router LSA. 487 When a router changes from not supporting MRT to supporting MRT, it 488 will flood its Router LSA(s) with the M-bit set and may send an 489 updated Router Information LSA. If a Router LSA is received with the 490 M-bit newly set, an MRT computation SHOULD be scheduled but MAY be 491 delayed up to 60 seconds to allow reception of updated related Router 492 Information LSAs. In general, when changes in MRT-related 493 information is received, an MRT computation SHOULD be triggered. 495 The rationale behind using the M bit in router LSA is to handle the 496 MRT capability changes gracefully in case of version upgrade/ 497 downgrade. The M bit in router LSA ensures the latest "MRT 498 capability" information is available for computation when there is a 499 downgrade to the version that doesn't support MRT and RI LSA. 501 9. Security Considerations 503 This OSPF extension is not believed to introduce new security 504 concerns. It relies upon the security architecture already provided 505 for Router LSAs and Router Information LSAs. 507 10. IANA Considerations 509 Please allocate a value from the OSPF Router Information TLV Types 510 [RFC4970] for the MRT Profile TLV, for the MRT-Ineligible Link TLV, 511 and for the OSPFv3 MRT-Ineligible Link TLV. 513 Please create an MRT Profile registry for the MRT Profile TLV. The 514 range is 0 to 255. The default MRT Profile has value 0. Values 515 1-200 are by Standards Action. Values 201-220 are for 516 experimentation. Values 221-255 are for vendor private use. 518 11. References 519 11.1. Normative References 521 [I-D.enyedi-rtgwg-mrt-frr-algorithm] 522 Envedi, G., Csaszar, A., Atlas, A., cbowers@juniper.net, 523 c., and A. Gopalan, "Algorithms for computing Maximally 524 Redundant Trees for IP/LDP Fast- Reroute", draft-enyedi- 525 rtgwg-mrt-frr-algorithm-03 (work in progress), July 2013. 527 [I-D.ietf-rtgwg-mrt-frr-architecture] 528 Atlas, A., Kebler, R., Envedi, G., Csaszar, A., Tantsura, 529 J., Konstantynowicz, M., and R. White, "An Architecture 530 for IP/LDP Fast-Reroute Using Maximally Redundant Trees", 531 draft-ietf-rtgwg-mrt-frr-architecture-03 (work in 532 progress), July 2013. 534 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 536 [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. 537 Shaffer, "Extensions to OSPF for Advertising Optional 538 Router Capabilities", RFC 4970, July 2007. 540 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 541 for IPv6", RFC 5340, July 2008. 543 11.2. Informative References 545 [I-D.atlas-bryant-shand-lf-timers] 546 K, A. and S. Bryant, "Synchronisation of Loop Free Timer 547 Values", draft-atlas-bryant-shand-lf-timers-04 (work in 548 progress), February 2008. 550 [I-D.atlas-rtgwg-mrt-mc-arch] 551 Atlas, A., Kebler, R., Wijnands, I., Csaszar, A., and G. 552 Envedi, "An Architecture for Multicast Protection Using 553 Maximally Redundant Trees", draft-atlas-rtgwg-mrt-mc- 554 arch-02 (work in progress), July 2013. 556 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 557 Requirement Levels", BCP 14, RFC 2119, March 1997. 559 [RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D. 560 McPherson, "OSPF Stub Router Advertisement", RFC 3137, 561 June 2001. 563 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 564 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 565 4915, June 2007. 567 [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free 568 Convergence", RFC 5715, January 2010. 570 Authors' Addresses 572 Alia Atlas 573 Juniper Networks 574 10 Technology Park Drive 575 Westford, MA 01886 576 USA 578 Email: akatlas@juniper.net 580 Shraddha Hegde 581 Juniper Networks 583 Email: shraddha@juniper.net 585 Chris Bowers 586 Juniper Networks 588 Email: cbowers@juniper.net 590 Jeff Tantsura 591 Ericsson 592 300 Holger Way 593 San Jose, CA 95134 594 USA 596 Email: jeff.tantsura@ericsson.com