idnits 2.17.1 draft-atlas-mpls-ldp-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 (July 4, 2014) is 3576 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: 'RFC4915' is defined on line 436, but no explicit reference was found in the text == Unused Reference: 'RFC5715' is defined on line 440, but no explicit reference was found in the text -- 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' == Outdated reference: A later version (-03) exists of draft-atlas-ospf-mrt-02 -- No information found for draft-rtgwg-mrt-frr-algorithm - is the name correct? == Outdated reference: A later version (-02) exists of draft-li-isis-mrt-01 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group A. Atlas 3 Internet-Draft K. Tiruveedhula 4 Intended status: Standards Track C. Bowers 5 Expires: January 5, 2015 Juniper Networks 6 J. Tantsura 7 Ericsson 8 IJ. Wijnands 9 Cisco Systems, Inc. 10 July 4, 2014 12 LDP Extensions to Support Maximally Redundant Trees 13 draft-atlas-mpls-ldp-mrt-01 15 Abstract 17 This document specifies extensions to LDP to support the creation of 18 label-switched paths for Maximally Redundant Trees (MRT). A prime 19 use of MRTs is for unicast and multicast IP/LDP Fast-Reroute (MRT- 20 FRR). 22 The sole protocol extension to LDP is simply the ability to advertise 23 an MRT Capability. This document describes that extension and the 24 associated behavior expected for LSRs and LERs advertising the MRT 25 Capability. 27 MRT-FRR uses LDP multi-topology extensions and requires three 28 different multi-topology IDs to be allocated from the LDP MT-ID 29 space. 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 5, 2015. 48 Copyright Notice 50 Copyright (c) 2014 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 LDP Signaling Extensions for MRT . . . . . . . . 4 69 4.1. MRT Capability Advertisement . . . . . . . . . . . . . . 5 70 4.2. Behavior Related to the Rainbow MRT MT-ID . . . . . . . . 6 71 4.3. MRT-Blue and MRT-Red FECs . . . . . . . . . . . . . . . . 7 72 5. LDP MRT FEC Advertisements . . . . . . . . . . . . . . . . . 7 73 5.1. Downstream Unsolicited Mode . . . . . . . . . . . . . . . 7 74 5.2. Downstream On Demand Mode . . . . . . . . . . . . . . . . 8 75 5.3. Inter-Area . . . . . . . . . . . . . . . . . . . . . . . 8 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 81 9.2. Informative References . . . . . . . . . . . . . . . . . 9 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 84 1. Introduction 86 This document describes the LDP signaling extension and associated 87 behavior necessary to support the architecture that defines how IP/ 88 LDP Fast-Reroute can use MRTs [I-D.ietf-rtgwg-mrt-frr-architecture]. 89 It is necessary to read the architecture in 90 [I-D.ietf-rtgwg-mrt-frr-architecture] to understand how and why the 91 LDP extensions for behavior are needed. 93 At least one common standardized algorithm, such as the lowpoint 94 algorithm explained and fully documented in 95 [I-D.ietf-rtgwg-mrt-frr-algorithm], is required so that the routers 96 supporting MRT computation consistently compute the same MRTs. LDP 97 depends on the IGP to compute the MRTs and alternates. Extensions to 98 OSPF are defined in [I-D.atlas-ospf-mrt]. Extension to IS-IS are 99 defined in [I-D.li-isis-mrt] 101 MRT can also be used to protect multicast traffic via either global 102 protection or local protection.[I-D.atlas-rtgwg-mrt-mc-arch] An MRT 103 path can be used to provide node-protection for mLDP traffic via the 104 mechanisms described in [I-D.wijnands-mpls-mldp-node-protection]; an 105 MRT path can also be use to provide link protection for mLDP traffic. 107 For each destination, IP/LDP Fast-Reroute with MRT (MRT-FRR) creates 108 two alternate destination-based trees separate from the primary next- 109 hop forwarding used during stable operation. LDP uses the multi- 110 topology extensions [I-D.ietf-mpls-ldp-multi-topology] to signal FECs 111 for these two new forwarding topologies, known as MRT-Blue and MRT- 112 Red. 114 In order to create MRT paths and support IP/LDP Fast-Reroute, a new 115 capability extension is needed for LDP. An LDP implementation 116 supporting MRT must also follow the described rules for originating 117 and managing FECs related to MRT, as indicated by their multi- 118 topology ID. Network reconvergence is described in 119 [I-D.ietf-rtgwg-mrt-frr-architecture] and the worst-cast network 120 convergence time can be flooded via the extension in Section 7 of 121 [I-D.atlas-ospf-mrt]. 123 IP/LDP Fast-Reroute using MRTs can provide 100% coverage for link and 124 node failures in an arbitrary network topology where the failure 125 doesn't split the network. It can also be deployed incrementally; an 126 MRT Island is formed of connected supporting routers and the MRTs are 127 computed inside that island. 129 2. Requirements Language 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119] 135 3. Terminology 137 For ease of reading, some of the terminology defined in 138 [I-D.ietf-rtgwg-mrt-frr-architecture] is repeated here. 140 Redundant Trees (RT): A pair of trees where the path from any node 141 X to the root R along the first tree is node-disjoint with the 142 path from the same node X to the root along the second tree. 143 These can be computed in 2-connected graphs. 145 Maximally Redundant Trees (MRT): A pair of trees where the path 146 from any node X to the root R along the first tree and the path 147 from the same node X to the root along the second tree share the 148 minimum number of nodes and the minimum number of links. Each 149 such shared node is a cut-vertex. Any shared links are cut-links. 150 Any RT is an MRT but many MRTs are not RTs. The two MRTs are 151 referred to as MRT-Blue and MRT-Red. 153 MRT Island: From the computing router, the set of routers that 154 support a particular MRT profile and are connected via MRT- 155 eligible links. 157 MRT-Red: MRT-Red is used to describe one of the two MRTs; it is 158 used to described the associated forwarding topology and MT-ID. 159 Specifically, MRT-Red is the decreasing MRT where links in the 160 GADAG are taken in the direction from a higher topologically 161 ordered node to a lower one. 163 MRT-Blue: MRT-Blue is used to describe one of the two MRTs; it is 164 used to described the associated forwarding topology and MT-ID. 165 Specifically, MRT-Blue is the increasing MRT where links in the 166 GADAG are taken in the direction from a lower topologically 167 ordered node to a higher one. 169 Rainbow MRT: It is useful to have an MT-ID that refers to the 170 multiple MRT topologies and to the default topology. This is 171 referred to as the Rainbow MRT MT-ID and is used by LDP to reduce 172 signaling and permit the same label to always be advertised to all 173 peers for the same (MT-ID, Prefix). 175 4. Overview of LDP Signaling Extensions for MRT 177 Routers need to know which of their neighbors support MRT. 178 Supporting MRT indicates several different aspects of behavior, as 179 listed below. 181 1. Support for Multi-Topology (MT) - this MAY also be indicated via 182 the Multi-Capability MT Capability 183 [I-D.ietf-mpls-ldp-multi-topology]. 185 2. Understand the Rainbow MRT MT-ID and apply the associated labels 186 to all relevant MT-IDs. 188 3. Advertise the Rainbow MRT MT-ID to the appropriate neighbors for 189 the associated prefix. 191 4. If acting as LDP egress for a prefix in the default topology, 192 also advertise and act as egress for the same prefix in MRT-Red 193 and MRT-Blue. 195 5. For a FEC learned from a neighbor that does not support MRT, 196 originate FECS for MRT-Red and MRT-Blue with the same prefix. 197 This MRT Island egress behavior is to support an MRT Island that 198 does not include all routers in the area/level. 200 4.1. MRT Capability Advertisement 202 It is not possible to support MRT without supporting the LDP multi- 203 topology extensions, but it is possible that the only use of the 204 multi-topology extensions is for MRT. In that case, a router MAY not 205 negotiate the multi-topology capability and only negotiate the MRT 206 Capability with its LDP peer. Negotiation of the MT capability is 207 not required with negotiation of the MRT capability. 209 [EDITOR NOTE: How do we deal with different abilities for IPv4 and 210 IPv6? The MT capability has the Wildcard FEC to indicate this. Do 211 we just assume??] 213 A new MRT Capability Parameter TLV is defined, which is defined in 214 accordance with LDP Capability definition guidelines[RFC5561]. 216 The LDP MRT capability can be advertised during the LDP session 217 initialization or after the LDP session is established. 218 Advertisement of the MRT capability indicates support of the 219 procedures for establishing the MRT-Blue and MRT-Red LSP paths 220 detailed in this document. If the peer has not advertised the MRT 221 capability, then it indicates that LSR does not support MRT 222 procedures. 224 If a router advertises the LDP MRT capability to its peer, but the 225 peer has not advertised the MRT capability, then the router MUST NOT 226 advertise MRT-related FEC-label bindings to that peer, until that 227 peer starts to advertise the MRT capability. 229 The following is the format of the MRT Capability Parameter. 231 0 1 2 3 232 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 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 |U|F| MRT Capability (IANA) | Length (= 1) | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 |S| Reserved | 237 +-+-+-+-+-+-+-+-+ 239 MRT Capability TLV Format 241 Where: 243 U- and F-bits: MUST be 1 and 0, respectively, as per Section 3. 244 (Signaling Extensions) of LDP Capabilities [RFC5561]. 246 MRT Capability: TBA-MRT-LDP-1 (To Be Allocated by IANA) 248 S-bit: MUST be 1 if used in LDP "Initialization" message. MAY be 249 set to 0 or 1 in dynamic "Capability" message to advertise or 250 withdraw the capability respectively. 252 Length: The length (in octets) of TLV. Its value is 1. 254 4.2. Behavior Related to the Rainbow MRT MT-ID 256 In Section 10.1 of [I-D.ietf-rtgwg-mrt-frr-architecture], the need to 257 advertise different MPLS labels to different neighbors for the same 258 FEC is described. This can be shortly summarized as either 259 advertising MRT MT-ID differentiated labels to a neighbor or just 260 advertising the same MPLS label for the default topology, for MRT-Red 261 and MRT-Blue. MRT-supporting neighbors in the same domain as the 262 default SPT next-hop get the differentiated MPLS labels; all other 263 neighbors do not. 265 A second use for the Rainbow MRT MT-ID is for an egress LER to send 266 the Rainbow MRT MT-ID with an IMPLICIT_NULL label to indicate 267 penultimate-hop-popping for all three types of FECs (IP Prefix FEC, 268 MRT-Blue MT-IP Prefix FEC, and MRT-Red MT-IP Prefix FEC). 270 The use of the Rainbow-FEC by the ABR for non-best-area 271 advertisements is RECOMMENDED. An ABR MAY advertise the label for 272 the default topology in separate MRT-Blue and MRT-Red advertisements. 273 An LSR advertising the MRT capability MUST recognize the Rainbow MRT 274 MT-ID and associate the advertised label with the specific prefix 275 with the MRT-Red and MRT-Blue MT-IDs associated with all MRT Profiles 276 that advertise LDP as the forwarding mechanism. 278 The value of the Rainbow MRT MT-ID (TBA-MRT-LDP-2) will be assigned 279 by IANA from the LDP MT-ID space. Prototype experiments have used 280 the value 3999. 282 4.3. MRT-Blue and MRT-Red FECs 284 To provide MRT support in LDP, the MT Prefix FEC is used. 285 [I-D.ietf-rtgwg-mrt-frr-architecture] contains the IANA request for 286 the MRT-Red and MRT-Blue MT-IDs associated with the Default MRT 287 Profile. 289 The MT Prefix FEC encoding is defined in 290 [I-D.ietf-mpls-ldp-multi-topology] and is used without alteration for 291 signaling MRT-Blue, MRT-Red and Rainbow MRT FECs. 293 5. LDP MRT FEC Advertisements 295 This sections describes how and when labels for MRT-Red and MRT-Blue 296 FECs are advertised. The associated LSPs must be created before a 297 failure occurs, in order to provide protection paths which are 298 immediately usable by a PLR. 300 5.1. Downstream Unsolicited Mode 302 If the upstream session is negotiated with the MRT capability, the 303 Egress LER advertises via a Rainbow MRT FEC an allocated MPLS label; 304 this may be Explicit Null, Implicit Null, or another value. 306 Based on the MRT algorithm [I-D.ietf-rtgwg-mrt-frr-algorithm], the 307 IGP computes the MRT-Red and MRT-Blue disjoint paths at Ingress and 308 Transit LSRs. Once the IGP computes the MRT-Red and MRT-Blue next- 309 hops, LDP will advertise the Label Mapping for the MRT-Blue and MRT- 310 Red FECs. If a label is received from a downstream LSR for an MRT- 311 Red or MRT-Blue FEC where the downstream LSR is capable of MRT, the 312 MRT-Red FEC or MRT-Blue FEC label is swapped according to the 313 received downstream label. An LSR may also choose to use the MRT-Red 314 or MRT-Blue path as an alternate for doing fast-reroute for the local 315 traffic. 317 When a downstream router is not capable of MRT, the LSR is an MRT 318 Island Border Router (IBR) and SHOULD advertise Label Bindings for 319 the MRT-Red FEC and MRT-Blue FEC as well as the associated normal 320 topology. The normal topology's primary next-hops will be used to 321 forward traffic received for the MRT-Red FEC or the MRT-Blue FEC 322 where the FEC's destination is outside the MRT Island. This 323 functionality is critical for partial deployment scenarios. 325 5.2. Downstream On Demand Mode 327 After the IGP computes the MRT-Red and MRT-Blue paths, the IGP MAY 328 also decide to use either the MRT-Red or MRT-Blue path as a fast- 329 reroute alternate for the particular FEC. If so, then when in 330 Downstream On Demand Mode, the LSR sends a Label Request for either 331 the MRT-Red or MRT-Blue FEC to the downstream LSR. The downstream 332 LSR responds by either sending a Label Mapping if available or by 333 sending a Label Request to its downstream LSR. Once a Label Mapping 334 is received, the associated label may be used as a fast-reroute 335 alternate to forward IP and LDP traffic. 337 A Label Mapping may be available in the following circumstances: 339 o The LSR is acting as Egress 341 o A Label Mapping was already received from its downstream router 343 o A Label Mapping for the default topology FEC was received and the 344 downstream router is not capable of MRT or is in a different MRT 345 Island. 347 5.3. Inter-Area 349 As discussed in Section 4.2, the Rainbow MRT FEC is defined to 350 facilitate signaling the same label for multiple topologies. 351 Section 9 of [I-D.ietf-rtgwg-mrt-frr-architecture] recommends that 352 traffic leaving an OSPF area or IS-IS level SHOULD use the default 353 topology's shortest-path-tree next-hops instead of remaining on the 354 MRT-Red or MRT-Blue paths. If an LDP peer is in the same OSPF area 355 or IS-IS level as the primary next-hop, then LDP SHOULD advertise 356 different label values for a given set of MRT-Red FEC, MRT-Blue FEC, 357 and FEC, unless Explicit-Null or Implicit-Null is appropriate. If an 358 LDP peer is in a different OSPF area or IS-IS level from the primary 359 next-hop, then LDP SHOULD either advertise the same label value for 360 the given set of MRT-Red FEC, MRT-Blue FEC, and FEC or advertise a 361 single label for the Rainbow MRT FEC, whose behavior is defined in 362 Section 4.2. 364 6. Security Considerations 366 This LDP extension is not believed to introduce new security 367 concerns. It relies upon the security architecture already provided 368 for LDP. 370 7. IANA Considerations 372 Please allocate a value for the new LDP Capability TLV from the LDP 373 registry "TLV Type Name Space": MRT Capability TLV (TBA-MRT-LDP-1). 375 Please allocate a value from the LDP Multi-Topology (MT) ID Name 376 Space [I-D.ietf-mpls-ldp-multi-topology]: Rainbow MRT MT-ID (TBA-MRT- 377 LDP-2). 379 8. Acknowledgements 381 The authors would like to thank Ross Callon for his suggestions. 383 9. References 385 9.1. Normative References 387 [I-D.ietf-mpls-ldp-multi-topology] 388 Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D. 389 King, "LDP Extensions for Multi Topology", draft-ietf- 390 mpls-ldp-multi-topology-12 (work in progress), April 2014. 392 [I-D.ietf-rtgwg-mrt-frr-architecture] 393 Atlas, A., Kebler, R., Bowers, C., Enyedi, G., Csaszar, 394 A., Tantsura, J., Konstantynowicz, M., and R. White, "An 395 Architecture for IP/LDP Fast-Reroute Using Maximally 396 Redundant Trees", draft-rtgwg-mrt-frr-architecture-04 397 (work in progress), July 2014. 399 [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. 400 Le Roux, "LDP Capabilities", RFC 5561, July 2009. 402 9.2. Informative References 404 [I-D.atlas-ospf-mrt] 405 Atlas, A., Hegde, S., Bowers, C., and J. Tantsura, "OSPF 406 Extensions to Support Maximally Redundant Trees", draft- 407 atlas-ospf-mrt-02 (work in progress), July 2014. 409 [I-D.atlas-rtgwg-mrt-mc-arch] 410 Atlas, A., Kebler, R., Wijnands, I., Csaszar, A., and G. 411 Envedi, "An Architecture for Multicast Protection Using 412 Maximally Redundant Trees", draft-atlas-rtgwg-mrt-mc- 413 arch-02 (work in progress), July 2013. 415 [I-D.ietf-rtgwg-mrt-frr-algorithm] 416 Enyedi, G., Csaszar, A., Atlas, A., Bowers, C., and A. 417 Gopalan, "Algorithms for computing Maximally Redundant 418 Trees for IP/LDP Fast-Reroute", draft-rtgwg-mrt-frr- 419 algorithm-01 (work in progress), July 2014. 421 [I-D.li-isis-mrt] 422 Li, Z., Wu, N., Zhao, Q., Atlas, A., Bowers, C., and J. 423 Tantsura, "Intermediate System to Intermediate System (IS- 424 IS) Extensions for Maximally Redundant Trees(MRT)", draft- 425 li-isis-mrt-01 (work in progress), July 2014. 427 [I-D.wijnands-mpls-mldp-node-protection] 428 Wijnands, I., Rosen, E., Raza, K., Tantsura, J., Atlas, 429 A., and Q. Zhao, "mLDP Node Protection", draft-wijnands- 430 mpls-mldp-node-protection-04 (work in progress), June 431 2013. 433 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 434 Requirement Levels", BCP 14, RFC 2119, March 1997. 436 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 437 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 438 4915, June 2007. 440 [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free 441 Convergence", RFC 5715, January 2010. 443 Authors' Addresses 445 Alia Atlas 446 Juniper Networks 447 10 Technology Park Drive 448 Westford, MA 01886 449 USA 451 Email: akatlas@juniper.net 453 Kishore Tiruveedhula 454 Juniper Networks 455 10 Technology Park Drive 456 Westford, MA 01886 457 USA 459 Email: kishoret@juniper.net 460 Chris Bowers 461 Juniper Networks 462 1194 N. Mathilda Ave. 463 Sunnyvale, CA 94089 464 USA 466 Email: cbowers@juniper.net 468 Jeff Tantsura 469 Ericsson 470 300 Holger Way 471 San Jose, CA 95134 472 USA 474 Email: jeff.tantsura@ericsson.com 476 IJsbrand Wijnands 477 Cisco Systems, Inc. 479 Email: ice@cisco.com