idnits 2.17.1 draft-ietf-ospf-mrt-03.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 (June 30, 2017) is 2492 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 (-23) exists of draft-ietf-ospf-ospfv3-lsa-extend-14 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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: January 1, 2018 Juniper Networks 6 J. Tantsura 7 Individual 8 Z. Li 9 Huawei Technologies 10 June 30, 2017 12 OSPF Extensions to Support Maximally Redundant Trees 13 draft-ietf-ospf-mrt-03 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 January 1, 2018. 48 Copyright Notice 50 Copyright (c) 2017 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 Profile TLV in Router Information LSA . . . . . . . . . . 5 73 6. Advertising MRT-ineligible links for MRT . . . . . . . . . . 7 74 6.1. MRT-Ineligible Link sub-TLV . . . . . . . . . . . . . . . 7 75 7. Worst-Case Network Convergence Time . . . . . . . . . . . . . 8 76 8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 9 77 8.1. Handling MRT Capability Changes . . . . . . . . . . . . . 9 78 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 10 79 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 80 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 81 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 82 12.1. MRT Profile and Controlled Convergence TLVs . . . . . . 10 83 12.2. MRT-Ineligible Link sub-TLV . . . . . . . . . . . . . . 10 84 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 85 13.1. Normative References . . . . . . . . . . . . . . . . . . 11 86 13.2. Informative References . . . . . . . . . . . . . . . . . 12 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 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 [RFC7812]. At least one common standardized algorithm (such as the 94 lowpoint algorithm explained and fully documented in [RFC7811]) is 95 required so that the routers supporting MRT computation consistently 96 compute the same MRTs. MRT can also be used to protect multicast 97 traffic via either global protection or local 98 protection.[I-D.atlas-rtgwg-mrt-mc-arch] 100 IP/LDP Fast-Reroute using MRTs can provide 100% coverage for link and 101 node failures in an arbitrary network topology where the failure 102 doesn't split the network. It can also be deployed incrementally 103 inside an OSPF area; an MRT Island is formed of connected supporting 104 routers and the MRTs are computed inside that island. 106 In the default MRT profile, a supporting router both computes the 107 MRTs and creates the necessary transit forwarding state necessary to 108 provide the two additional forwarding topologies, known as MRT-Blue 109 and MRT-Red. 111 2. Requirements Language 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119] 117 3. Terminology 119 For ease of reading, some of the terminology defined in [RFC7812] is 120 repeated here. 122 network graph: A graph that reflects the network topology where all 123 links connect exactly two nodes and broadcast links have been 124 transformed into the standard pseudo-node representation. 126 Redundant Trees (RT): A pair of trees where the path from any node 127 X to the root R along the first tree is node-disjoint with the 128 path from the same node X to the root along the second tree. 129 These can be computed in 2-connected graphs. 131 Maximally Redundant Trees (MRT): A pair of trees where the path 132 from any node X to the root R along the first tree and the path 133 from the same node X to the root along the second tree share the 134 minimum number of nodes and the minimum number of links. Each 135 such shared node is a cut-vertex. Any shared links are cut-links. 136 Any RT is an MRT but many MRTs are not RTs. 138 MRT Island: From the computing router, the set of routers that 139 support a particular MRT profile and are connected via MRT- 140 eligible links. 142 GADAG: Generalized Almost Directed Acyclic Graph - a graph that is 143 the combination of the ADAGs of all blocks. Transforming a 144 network graph into a GADAG is part of the MRT algorithm. 146 MRT-Red: MRT-Red is used to describe one of the two MRTs; it is 147 used to described the associated forwarding topology and MT-ID. 148 Specifically, MRT-Red is the decreasing MRT where links in the 149 GADAG are taken in the direction from a higher topologically 150 ordered node to a lower one. 152 MRT-Blue: MRT-Blue is used to describe one of the two MRTs; it is 153 used to described the associated forwarding topology and MT-ID. 154 Specifically, MRT-Blue is the increasing MRT where links in the 155 GADAG are taken in the direction from a lower topologically 156 ordered node to a higher one. 158 4. Overview of OSPF Extensions for MRT 160 There are two separate aspects that need to be advertised in OSPF. 161 Both derive from the need for all routers supporting an MRT profile 162 to compute the same pair of MRTs to each destination. By executing 163 the same algorithm on the same network graph, distributed routers 164 will compute the same MRTs. Convergence considerations are discussed 165 in [RFC7812]. 167 The first aspect that must be advertised is which MRT profile(s) are 168 supported and the associated GADAG Root Selection Priority. The 169 second aspect that must be advertised is any links that are not 170 eligible, due to administrative policy, to be part of the MRTs. This 171 must be advertised consistently across the area so that all routers 172 in the MRT Island use the same network graph. 174 4.1. Supporting MRT Profiles 176 An MRT Profile defines the exact MRT Algorithm, the MRT-Red LDP MT- 177 ID, the MRT-Blue LDP MT-ID, and the forwarding mechanisms supported 178 for the transit MRT-Red and MRT-Blue forwarding topologies. Finally, 179 the MRT Profile defines exact behavioral rules such as: 181 o how reconvergence is handled, 183 o inter-area forwarding behavior, 185 A router that advertises support for an MRT Profile MUST provide the 186 specified forwarding mechanism for its MRT-Red and MRT-Blue 187 forwarding topologies. A router that advertises support for an MRT 188 Profile MUST implement an algorithm that produces the same set of 189 MRT-Red and MRT-Blue next-hops for its MRT-Red and MRT-Blue 190 topologies as is provided by the algorithm specified in the MRT 191 Profile. 193 A router MAY indicate support for multiple MRT Profiles. A router 194 computes its local MRT Island for each separate MRT Profile that the 195 router supports. Supporting multiple MRT Profiles also provides a 196 mechanism for transitioning from one profile to another. Different 197 uses of MRT forwarding topologies may behave better on different MRT 198 profiles. 200 The default MRT Profile is defined in [RFC7812]. Its behavior is 201 intended to 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 The GADAG Root Selection Policy (defined as part of an MRT profile) 213 may make use of the GADAG Root Selection Priority value advertised in 214 the MRT Profile TLV of the Router Information LSA. For example, the 215 GADAG Root Selection Policy for the default MRT profile is the 216 following: Among the routers in the MRT Island and with the highest 217 priority advertised, an implementation MUST pick the router with the 218 highest Router ID to be the GADAG root. 220 4.3. Triggering an MRT Computation 222 When an MRT Computation is triggered, it is triggered for a given MRT 223 Profile in a given area. First, the associated MRT Island is 224 determined. Then, the GADAG Root is selected. Finally, the actual 225 MRT algorithm is run to compute the transit MRT-Red and MRT-Blue 226 topologies. Additionally, the router MAY choose to compute MRT-FRR 227 alternates or make other use of the MRT computation results. 229 Prefixes can be attached and detached and have their associated MRT- 230 Red and MRT-Blue next-hops computed without requiring a new MRT 231 computation. 233 5. MRT Profile TLV in Router Information LSA 235 A router may advertise an MRT Profile TLV to indicate support for one 236 or more MRT Profiles. The MRT Profile TLV is advertised within the 237 OSPF router information LSA which is defined for both OSPFv2 and 238 OSPFv3 in [RFC7770]. The RI LSA MUST have area scope. 240 Note that the presence of the MRT Profile TLV indicates support for a 241 given MRT profile in the default topology (MT-ID = 0). The 242 extensions in this document do not define a method to advertise 243 support for MRT profiles in topologies with non-zero MT-ID. 245 0 1 2 3 246 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 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Type | Length | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Profile ID(1) |GADAG Priority | Reserved | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | .............. | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Profile ID(n) |GADAG Priority | Reserved | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 TYPE: TBA-MRT-OSPF-1 (To Be Allocated by IANA) 258 LENGTH: 4 * (number of Profiles) 259 Profile ID : 1 byte 260 GADAG Priority: 1 byte 262 MRT Profile TLV in Router Information LSA 264 Each Profile ID listed indicates support for a given MRT Profile, as 265 defined in [RFC7812]. A Profile ID value of 0 corresponds to the 266 Default MRT profile. 268 The GADAG Priority is the GADAG Root Selection Priority associated 269 with the advertising router in the MRT Island for the associated MRT 270 Profile, as indicated by the Profile ID. An implementation SHOULD 271 send a default value of 128 for the GADAG Root Selection Priority if 272 another value is not explicitly configured. 274 The length of this TLV depends on the number of MRT profiles 275 supported. The ordering of the profiles inside the TLV is not 276 significant. Multiple appearances of this TLV is not an error. 278 An advertising router MUST NOT advertise the same Profile ID multiple 279 times in one or more TLVs. If a receiving router receives multiple 280 appearances of the same Profile ID for the same router, it MUST treat 281 the advertising router as NOT supporting the MRT Profile associated 282 with that Profile ID. This is the case even if the multiple 283 appearances of the same Profile ID have the same GADAG Priority 284 values. However, other Profile IDs advertised by the same 285 advertising router that are not repeated should continue to be 286 honored by the receiving router. The receiving router SHOULD also 287 log an error message regarding the multiple appearances of the same 288 Profile ID for the same router. 290 6. Advertising MRT-ineligible links for MRT 292 Due to administrative policy, some otherwise eligible links in the 293 network topology may need to be excluded from the network graph upon 294 which the MRT algorithm is run. Since the same network graph must be 295 used across the area, it is critical for OSPF to flood which links to 296 exclude from the MRT calculation. This is done by introducing a new 297 MRT-Ineligible Link sub-TLV. For OSPFv2, this sub-TLV is carried in 298 the Extended Link TLV defined in [I-D.ietf-ospf-prefix-link-attr]. 299 For OSPFv3, this sub-TLV is carried in the Router-Link TLV defined in 300 [I-D.ietf-ospf-ospfv3-lsa-extend]. 302 If a link is marked by administrative policy as MRT-Ineligible, then 303 a router MUST flood the OSPFv2 Extended Link TLV (or OSPFv3 Router- 304 Link TLV) for that link, including the MRT-Ineligible Link sub-TLV. 305 The OSPVv2 Extended Link TLV and OSPFv3 Router-Link TLV have area 306 wide scope. 308 Note that a router that advertises support for MRT with the MRT 309 Profile TLV MUST also support receipt of the MRT-Ineligible Link sub- 310 TLVs. This ensures that all routers participating in a given MRT 311 Island have the same view of the links included in the MRT Island. 313 6.1. MRT-Ineligible Link sub-TLV 315 0 1 2 3 316 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 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Type | Length | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 TYPE: TBA-MRT-OSPF-2 in OSPFv2 Extended Link TLV 322 TBA-MRT-OSPF-3 in OSPFv3 Router-Link TLV 323 (To Be Allocated by IANA) 324 LENGTH: 0 326 MRT-Ineligible Link sub-TLV 328 This zero-length sub-TLV can appear in the OSPFv2 Extended Link TLV 329 or the OSPFv3 Router-Link TLV. Its presence indicates that the 330 associated link MUST NOT be used in the MRT calculation for all 331 profiles. 333 7. Worst-Case Network Convergence Time 335 As part of converging the network after a single failure, 336 Section 12.2 of [RFC7812] describes the need to wait for a configured 337 or advertised period for all routers to be using their new SPTs. 338 Similarly, some proposals to avoid micro-forwarding loops during 339 convergence[RFC5715] require determining the maximum among all 340 routers in the area of the worst-case route computation and FIB 341 installation time. More details on the specific reasoning and need 342 for flooding it are given in [I-D.atlas-bryant-shand-lf-timers]. 344 0 1 2 3 345 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 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Type | Length | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Reserved | FIB compute/install time | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 TYPE: TBA-MRT-OSPF-4 (To Be Allocated by IANA) 353 LENGTH: 4 354 FIB compute/install time: This is the worst-case time the router 355 may take to compute and install all OSPF routes in the area 356 after a change to a stable network. The value is 357 in milliseconds. 359 Controlled Convergence TLV in Router Information LSA 361 The Controlled Convergence TLV is carried in the Router Information 362 LSA and flooded with area-wide scope. The FIB compute/install time 363 value sent by a router SHOULD be an estimate taking into account 364 network scale or real-time measurements, or both. Advertisements 365 SHOULD be dampened to avoid frequent communication of small changes 366 in the FIB compute/install time. 368 A router receiving the Controlled Convergence TLV SHOULD estimate the 369 network convergence time as the maximum of the FIB compute/install 370 times advertised by the routers in an area, including itself. In 371 order to account for routers that do not advertise the Controlled 372 Convergence TLV, a router MAY use a locally configured minimum 373 network convergence time as a lower bound on the computed network 374 convergence time. A router MAY use a locally configured maximum 375 network convergence time as an upper bound on the computed network 376 convergence time. 378 8. Backwards Compatibility 380 The MRT Profile TLV, the MRT-Ineligible Link sub-TLV, the OSPFv3 MRT- 381 Ineligible Link sub-TLV, and the Controlled Convergence TLV are 382 defined in this document. A router that does not understand the MRT 383 Profile TLV will ignore it. A router that does not advertise an MRT 384 Profile TLV with a Profile ID may do so either because it doesn't 385 understand the MRT Profile TLV, or because it understands these 386 extensions, but chooses not to advertise support for any MRT profile. 387 Routers that support the MRT Profile TLV will treat either case in 388 the same manner, by excluding the router not advertising the MRT 389 Profile from the particular MRT Island. 391 The MRT-Ineligible Link sub-TLVs will be ignored by a router that 392 doesn't understand MRT, and a router supporting MRT must support 393 receipt of the MRT-Ineligible Link sub-TLVs. 395 Finally, applications that utilize the Controlled Convergence TLV can 396 use local configuration to account for routers that do not understand 397 the Controlled Convergence TLV. 399 8.1. Handling MRT Capability Changes 401 When a router that is running a version of software supporting MRT is 402 downgraded to software that does not support MRT, it is important 403 that the routers still running MRT do not continue to use the Router 404 Information LSA (RI LSA) containing the MRT Profile TLV advertised by 405 the downgraded router before the downgrade. As long as the 406 downgraded router supports Opaque LSAs, the downgraded router will 407 purge the old RI LSA containing the MRT Profile TLV that it 408 originated before the downgrade. This will occur when the downgraded 409 router receives the self-originated RI LSA after restarting, as 410 described in Section 13.4 and 14.1 of [RFC2328]. This behavior is 411 clearly required when the downgraded router supports the RI LSA. 413 It is also reasonable to expect this behavior even when the software 414 on the downgraded router does not understand the RI LSA. Although 415 this precise behavior is not explicitly described in [RFC2328] , it 416 is reasonable to infer from the documents. As long as the downgraded 417 router supports Opaque LSAs, it is required to flood link-state type 418 10 (area-local scope) Opaque LSAs, even those that it does not 419 understand [RFC5250]. So, when a restarting router receives a self- 420 originated link-state type 10 Opaque LSA whose Option Type it does 421 not recognize, it can (in principle) flood it or purge it. Purging 422 an unknown self-originated Opaque LSA is the most reasonable thing to 423 do. 425 9. Implementation Status 427 [RFC Editor: please remove this section prior to publication.] 429 Please see [RFC7812] for details on implementation status. 431 10. Security Considerations 433 This OSPF extension is not believed to introduce new security 434 concerns. It relies upon the security architecture already provided 435 for Router LSAs and Router Information LSAs. 437 11. Acknowledgements 439 The authors would like to thank Anil Kumar SN for his suggestions and 440 review. 442 12. IANA Considerations 444 12.1. MRT Profile and Controlled Convergence TLVs 446 IANA is requested to allocate values for the following OSPF Router 447 Information TLV Types [RFC7770]: MRT Profile TLV (TBA-MRT-OSPF-1), 448 and Controlled Convergence TLV (TBA-MRT-OSPF-4). The requested 449 entries in the OSPF Router Information (RI) TLVs registry are shown 450 below. 452 Type Value Capabilities Reference 453 ------------- ---------------------- ------------ 454 TBA-MRT-OSPF-1 MRT Profile TLV [This draft] 455 TBA-MRT-OSPF-4 Controlled Convergence TLV [This draft] 457 12.2. MRT-Ineligible Link sub-TLV 459 IANA is requested to allocate a value from the OSPF Extended Link TLV 460 sub-TLV registry defined in [I-D.ietf-ospf-prefix-link-attr] for the 461 MRT-Ineligible Link sub-TLV (TBA-MRT-OSPF-2). The OSPF Extended Link 462 TLV sub-TLV registry after implementing the above request is shown 463 below. 465 Value Description Reference 466 ------------- ---------------------- ------------ 467 0 Reserved [prefix-link-attr-draft] 468 TBA-MRT-OSPF-2 MRT-Ineligible Link sub-TLV [This draft] 469 2-32767 Unassigned [prefix-link-attr-draft] 470 32768-33023 Reserved for Experimental Use [prefix-link-attr-draft] 471 33024-65535 Reserved [prefix-link-attr-draft] 473 IANA is requested to allocate a value from the OSPFv3 Extended-LSA 474 sub-TLV registry [I-D.ietf-ospf-ospfv3-lsa-extend] for the MRT- 475 Ineligible Link sub-TLV (TBA-MRT-OSPF-3). The OSPFv3 Extended-LSA 476 sub-TLV registry has not yet been created by IANA. 478 13. References 480 13.1. Normative References 482 [I-D.ietf-ospf-ospfv3-lsa-extend] 483 Lindem, A., Roy, A., Goethals, D., Vallem, V., and F. 484 Baker, "OSPFv3 LSA Extendibility", draft-ietf-ospf-ospfv3- 485 lsa-extend-14 (work in progress), April 2017. 487 [I-D.ietf-ospf-prefix-link-attr] 488 Psenak, P., Gredler, H., rjs@rob.sh, r., Henderickx, W., 489 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 490 Advertisement", draft-ietf-ospf-prefix-link-attr-13 (work 491 in progress), August 2015. 493 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 494 DOI 10.17487/RFC2328, April 1998, 495 . 497 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 498 OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, 499 July 2008, . 501 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 502 S. Shaffer, "Extensions to OSPF for Advertising Optional 503 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 504 February 2016, . 506 [RFC7811] Enyedi, G., Csaszar, A., Atlas, A., Bowers, C., and A. 507 Gopalan, "An Algorithm for Computing IP/LDP Fast Reroute 508 Using Maximally Redundant Trees (MRT-FRR)", RFC 7811, 509 DOI 10.17487/RFC7811, June 2016, 510 . 512 [RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for 513 IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT- 514 FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016, 515 . 517 13.2. Informative References 519 [I-D.atlas-bryant-shand-lf-timers] 520 K, A. and S. Bryant, "Synchronisation of Loop Free Timer 521 Values", draft-atlas-bryant-shand-lf-timers-04 (work in 522 progress), February 2008. 524 [I-D.atlas-rtgwg-mrt-mc-arch] 525 Atlas, A., Kebler, R., Wijnands, I., Csaszar, A., and G. 526 Envedi, "An Architecture for Multicast Protection Using 527 Maximally Redundant Trees", draft-atlas-rtgwg-mrt-mc- 528 arch-02 (work in progress), July 2013. 530 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 531 Requirement Levels", BCP 14, RFC 2119, 532 DOI 10.17487/RFC2119, March 1997, 533 . 535 [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free 536 Convergence", RFC 5715, DOI 10.17487/RFC5715, January 537 2010, . 539 Authors' Addresses 541 Alia Atlas 542 Juniper Networks 543 10 Technology Park Drive 544 Westford, MA 01886 545 USA 547 Email: akatlas@juniper.net 549 Shraddha Hegde 550 Juniper Networks 551 Embassy Business Park 552 Bangalore, KA 560093 553 India 555 Email: shraddha@juniper.net 556 Chris Bowers 557 Juniper Networks 558 1194 N. Mathilda Ave. 559 Sunnyvale, CA 94089 560 USA 562 Email: cbowers@juniper.net 564 Jeff Tantsura 565 Individual 566 USA 568 Email: jefftant.ietf@gmail.com 570 Zhenbin Li 571 Huawei Technologies 572 Huawei Bld., No.156 Beiqing Rd. 573 Beijing 100095 574 China 576 Email: lizhenbin@huawei.com