idnits 2.17.1 draft-ietf-ospf-mrt-02.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 (May 18, 2016) is 2899 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 517, but no explicit reference was found in the text == Unused Reference: 'RFC3137' is defined on line 544, but no explicit reference was found in the text == Unused Reference: 'RFC4915' is defined on line 549, but no explicit reference was found in the text == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-lsa-extend-09 == 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 informational reference (is this intentional?): RFC 3137 (Obsoleted by RFC 6987) Summary: 0 errors (**), 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: November 19, 2016 Juniper Networks 6 J. Tantsura 7 Individual 8 Z. Li 9 Huawei Technologies 10 May 18, 2016 12 OSPF Extensions to Support Maximally Redundant Trees 13 draft-ietf-ospf-mrt-02 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 November 19, 2016. 48 Copyright Notice 50 Copyright (c) 2016 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 . . . . . . . . . . 6 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 . . . . . . . . . . . . . 10 78 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 10 79 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 80 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 81 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 82 12.1. MRT Profile and Controlled Convergence TLVs . . . . . . 11 83 12.2. MRT-Ineligible Link sub-TLV . . . . . . . . . . . . . . 11 84 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 85 13.1. Normative References . . . . . . . . . . . . . . . . . . 11 86 13.2. Informative References . . . . . . . . . . . . . . . . . 12 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 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 Profile TLV in Router Information LSA 237 A router may advertise an MRT Profile TLV to indicate support for one 238 or more MRT Profiles. The MRT Profile TLV is advertised within the 239 OSPF router information LSA which is defined for both OSPFv2 and 240 OSPFv3 in [RFC7770]. The RI LSA MUST have area scope. 242 Note that the presence of the MRT Profile TLV indicates support for a 243 given MRT profile in the default topology (MT-ID = 0). The 244 extensions in this document do not define a method to advertise 245 support for MRT profiles in topologies with non-zero MT-ID. 247 0 1 2 3 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Type | Length | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Profile ID(1) |GADAG Priority | Reserved | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | .............. | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Profile ID(n) |GADAG Priority | Reserved | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 TYPE: TBA-MRT-OSPF-1 (To Be Allocated by IANA) 260 LENGTH: 4 * (number of Profiles) 261 Profile ID : 1 byte 262 GADAG Priority: 1 byte 264 MRT Profile TLV in Router Information LSA 266 Each Profile ID listed indicates support for a given MRT Profile, as 267 defined in [I-D.ietf-rtgwg-mrt-frr-architecture]. A Profile ID value 268 of 0 corresponds to the Default MRT profile. 270 The GADAG Priority is the GADAG Root Selection Priority associated 271 with the advertising router in the MRT Island for the associated MRT 272 Profile, as indicated by the Profile ID. An implementation SHOULD 273 send a default value of 128 for the GADAG Root Selection Priority if 274 another value is not explicitly configured. 276 The length of this TLV depends on the number of MRT profiles 277 supported. The ordering of the profiles inside the TLV is not 278 significant. Multiple appearances of this TLV is not an error. 280 An advertising router MUST NOT advertise the same Profile ID multiple 281 times in one or more TLVs. If a receiving router receives multiple 282 appearances of the same Profile ID for the same router, it MUST treat 283 the advertising router as NOT supporting the MRT Profile associated 284 with that Profile ID. This is the case even if the multiple 285 appearances of the same Profile ID have the same GADAG Priority 286 values. However, other Profile IDs advertised by the same 287 advertising router that are not repeated should continue to be 288 honored by the receiving router. The receiving router SHOULD also 289 log an error message regarding the multiple appearances of the same 290 Profile ID for the same router. 292 6. Advertising MRT-ineligible links for MRT 294 Due to administrative policy, some otherwise eligible links in the 295 network topology may need to be excluded from the network graph upon 296 which the MRT algorithm is run. Since the same network graph must be 297 used across the area, it is critical for OSPF to flood which links to 298 exclude from the MRT calculation. This is done by introducing a new 299 MRT-Ineligible Link sub-TLV. For OSPFv2, this sub-TLV is carried in 300 the Extended Link TLV defined in [I-D.ietf-ospf-prefix-link-attr]. 301 For OSPFv3, this sub-TLV is carried in the Router-Link TLV defined in 302 [I-D.ietf-ospf-ospfv3-lsa-extend]. 304 If a link is marked by administrative policy as MRT-Ineligible, then 305 a router MUST flood the OSPFv2 Extended Link TLV (or OSPFv3 Router- 306 Link TLV) for that link, including the MRT-Ineligible Link sub-TLV. 307 The OSPVv2 Extended Link TLV and OSPFv3 Router-Link TLV have area 308 wide scope. 310 Note that a router that advertises support for MRT with the MRT 311 Profile TLV MUST also support receipt of the MRT-Ineligible Link sub- 312 TLVs. This ensures that all routers participating in a given MRT 313 Island have the same view of the links included in the MRT Island. 315 6.1. MRT-Ineligible Link sub-TLV 316 0 1 2 3 317 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 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Type | Length | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 TYPE: TBA-MRT-OSPF-2 in OSPFv2 Extended Link TLV 323 TBA-MRT-OSPF-3 in OSPFv3 Router-Link TLV 324 (To Be Allocated by IANA) 325 LENGTH: 0 327 MRT-Ineligible Link sub-TLV 329 This zero-length sub-TLV can appear in the OSPFv2 Extended Link TLV 330 or the OSPFv3 Router-Link TLV. Its presence indicates that the 331 associated link MUST NOT be used in the MRT calculation for all 332 profiles. 334 7. Worst-Case Network Convergence Time 336 As part of converging the network after a single failure, 337 Section 12.2 of [I-D.ietf-rtgwg-mrt-frr-architecture] describes the 338 need to wait for a configured or advertised period for all routers to 339 be using their new SPTs. Similarly, some proposals to avoid micro- 340 forwarding loops during convergence[RFC5715] require determining the 341 maximum among all routers in the area of the worst-case route 342 computation and FIB installation time. More details on the specific 343 reasoning and need for flooding it are given in 344 [I-D.atlas-bryant-shand-lf-timers]. 346 0 1 2 3 347 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 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Type | Length | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Reserved | FIB compute/install time | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 TYPE: TBA-MRT-OSPF-4 (To Be Allocated by IANA) 355 LENGTH: 4 356 FIB compute/install time: This is the worst-case time the router 357 may take to compute and install all OSPF routes in the area 358 after a change to a stable network. The value is 359 in milliseconds. 361 Controlled Convergence TLV in Router Information LSA 363 The Controlled Convergence TLV is carried in the Router Information 364 LSA and flooded with area-wide scope. The FIB compute/install time 365 value sent by a router SHOULD be an estimate taking into account 366 network scale or real-time measurements, or both. Advertisements 367 SHOULD be dampened to avoid frequent communication of small changes 368 in the FIB compute/install time. 370 A router receiving the Controlled Convergence TLV SHOULD estimate the 371 network convergence time as the maximum of the FIB compute/install 372 times advertised by the routers in an area, including itself. In 373 order to account for routers that do not advertise the Controlled 374 Convergence TLV, a router MAY use a locally configured minimum 375 network convergence time as a lower bound on the computed network 376 convergence time. A router MAY use a locally configured maximum 377 network convergence time as an upper bound on the computed network 378 convergence time. 380 8. Backwards Compatibility 382 The MRT Profile TLV, the MRT-Ineligible Link sub-TLV, the OSPFv3 MRT- 383 Ineligible Link sub-TLV, and the Controlled Convergence TLV are 384 defined in this document. A router that does not understand the MRT 385 Profile TLV will ignore it. A router that does not advertise an MRT 386 Profile TLV with a Profile ID may do so either because it doesn't 387 understand the MRT Profile TLV, or because it understands these 388 extensions, but chooses not to advertise support for any MRT profile. 389 Routers that support the MRT Profile TLV will treat either case in 390 the same manner, by excluding the router not advertising the MRT 391 Profile from the particular MRT Island. 393 The MRT-Ineligible Link sub-TLVs will be ignored by a router that 394 doesn't understand MRT, and a router supporting MRT must support 395 receipt of the MRT-Ineligible Link sub-TLVs. 397 Finally, applications that utilize the Controlled Convergence TLV can 398 use local configuration to account for routers that do not understand 399 the Controlled Convergence TLV. 401 8.1. Handling MRT Capability Changes 403 When a router that is running a version of software supporting MRT is 404 downgraded to software that does not support MRT, it is important 405 that the routers still running MRT do not continue to use the Router 406 Information LSA (RI LSA) containing the MRT Profile TLV advertised by 407 the downgraded router before the downgrade. As long as the 408 downgraded router supports Opaque LSAs, the downgraded router will 409 purge the old RI LSA containing the MRT Profile TLV that it 410 originated before the downgrade. This will occur when the downgraded 411 router receives the self-originated RI LSA after restarting, as 412 described in Section 13.4 and 14.1 of [RFC2328]. This behavior is 413 clearly required when the downgraded router supports the RI LSA. 415 It is also reasonable to expect this behavior even when the software 416 on the downgraded router does not understand the RI LSA. Although 417 this precise behavior is not explicitly described in [RFC2328] , it 418 is reasonable to infer from the documents. As long as the downgraded 419 router supports Opaque LSAs, it is required to flood link-state type 420 10 (area-local scope) Opaque LSAs, even those that it does not 421 understand [RFC5250]. So, when a restarting router receives a self- 422 originated link-state type 10 Opaque LSA whose Option Type it does 423 not recognize, it can (in principle) flood it or purge it. Purging 424 an unknown self-originated Opaque LSA is the most reasonable thing to 425 do. 427 9. Implementation Status 429 [RFC Editor: please remove this section prior to publication.] 431 Please see [I-D.ietf-rtgwg-mrt-frr-architecture] for details on 432 implementation status. 434 10. Security Considerations 436 This OSPF extension is not believed to introduce new security 437 concerns. It relies upon the security architecture already provided 438 for Router LSAs and Router Information LSAs. 440 11. Acknowledgements 442 The authors would like to thank Anil Kumar SN for his suggestions and 443 review. 445 12. IANA Considerations 447 12.1. MRT Profile and Controlled Convergence TLVs 449 IANA is requested to allocate values for the following OSPF Router 450 Information TLV Types [RFC7770]: MRT Profile TLV (TBA-MRT-OSPF-1), 451 and Controlled Convergence TLV (TBA-MRT-OSPF-4). The requested 452 entries in the OSPF Router Information (RI) TLVs registry are shown 453 below. 455 Type Value Capabilities Reference 456 ------------- ---------------------- ------------ 457 TBA-MRT-OSPF-1 MRT Profile TLV [This draft] 458 TBA-MRT-OSPF-4 Controlled Convergence TLV [This draft] 460 12.2. MRT-Ineligible Link sub-TLV 462 IANA is requested to allocate a value from the OSPF Extended Link TLV 463 sub-TLV registry defined in [I-D.ietf-ospf-prefix-link-attr] for the 464 MRT-Ineligible Link sub-TLV (TBA-MRT-OSPF-2). The OSPF Extended Link 465 TLV sub-TLV registry after implementing the above request is shown 466 below. 468 Value Description Reference 469 ------------- ---------------------- ------------ 470 0 Reserved [prefix-link-attr-draft] 471 TBA-MRT-OSPF-2 MRT-Ineligible Link sub-TLV [This draft] 472 2-32767 Unassigned [prefix-link-attr-draft] 473 32768-33023 Reserved for Experimental Use [prefix-link-attr-draft] 474 33024-65535 Reserved [prefix-link-attr-draft] 476 IANA is requested to allocate a value from the OSPFv3 Extended-LSA 477 sub-TLV registry [I-D.ietf-ospf-ospfv3-lsa-extend] for the MRT- 478 Ineligible Link sub-TLV (TBA-MRT-OSPF-3). The OSPFv3 Extended-LSA 479 sub-TLV registry has not yet been created by IANA. 481 13. References 483 13.1. Normative References 485 [I-D.ietf-ospf-ospfv3-lsa-extend] 486 Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3 487 LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-09 488 (work in progress), November 2015. 490 [I-D.ietf-ospf-prefix-link-attr] 491 Psenak, P., Gredler, H., rjs@rob.sh, r., Henderickx, W., 492 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 493 Advertisement", draft-ietf-ospf-prefix-link-attr-13 (work 494 in progress), August 2015. 496 [I-D.ietf-rtgwg-mrt-frr-algorithm] 497 Envedi, G., Csaszar, A., Atlas, A., Bowers, C., and A. 498 Gopalan, "Algorithms for computing Maximally Redundant 499 Trees for IP/LDP Fast- Reroute", draft-ietf-rtgwg-mrt-frr- 500 algorithm-06 (work in progress), October 2015. 502 [I-D.ietf-rtgwg-mrt-frr-architecture] 503 Atlas, A., Kebler, R., Bowers, C., Envedi, G., Csaszar, 504 A., Tantsura, J., and R. White, "An Architecture for IP/ 505 LDP Fast-Reroute Using Maximally Redundant Trees", draft- 506 ietf-rtgwg-mrt-frr-architecture-07 (work in progress), 507 October 2015. 509 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 510 DOI 10.17487/RFC2328, April 1998, 511 . 513 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 514 OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, 515 July 2008, . 517 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 518 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 519 . 521 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 522 S. Shaffer, "Extensions to OSPF for Advertising Optional 523 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 524 February 2016, . 526 13.2. Informative References 528 [I-D.atlas-bryant-shand-lf-timers] 529 K, A. and S. Bryant, "Synchronisation of Loop Free Timer 530 Values", draft-atlas-bryant-shand-lf-timers-04 (work in 531 progress), February 2008. 533 [I-D.atlas-rtgwg-mrt-mc-arch] 534 Atlas, A., Kebler, R., Wijnands, I., Csaszar, A., and G. 535 Envedi, "An Architecture for Multicast Protection Using 536 Maximally Redundant Trees", draft-atlas-rtgwg-mrt-mc- 537 arch-02 (work in progress), July 2013. 539 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 540 Requirement Levels", BCP 14, RFC 2119, 541 DOI 10.17487/RFC2119, March 1997, 542 . 544 [RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D. 545 McPherson, "OSPF Stub Router Advertisement", RFC 3137, 546 DOI 10.17487/RFC3137, June 2001, 547 . 549 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 550 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 551 RFC 4915, DOI 10.17487/RFC4915, June 2007, 552 . 554 [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free 555 Convergence", RFC 5715, DOI 10.17487/RFC5715, January 556 2010, . 558 Authors' Addresses 560 Alia Atlas 561 Juniper Networks 562 10 Technology Park Drive 563 Westford, MA 01886 564 USA 566 Email: akatlas@juniper.net 568 Shraddha Hegde 569 Juniper Networks 570 Embassy Business Park 571 Bangalore, KA 560093 572 India 574 Email: shraddha@juniper.net 575 Chris Bowers 576 Juniper Networks 577 1194 N. Mathilda Ave. 578 Sunnyvale, CA 94089 579 USA 581 Email: cbowers@juniper.net 583 Jeff Tantsura 584 Individual 585 USA 587 Email: jefftant.ietf@gmail.com 589 Zhenbin Li 590 Huawei Technologies 591 Huawei Bld., No.156 Beiqing Rd. 592 Beijing 100095 593 China 595 Email: lizhenbin@huawei.com