idnits 2.17.1 draft-atlas-mpls-ldp-mrt-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 2 characters in excess of 72. 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 12, 2013) is 3935 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 439, but no explicit reference was found in the text == Unused Reference: 'RFC5715' is defined on line 443, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-mpls-ldp-multi-topology-08 == Outdated reference: A later version (-10) exists of draft-ietf-rtgwg-mrt-frr-architecture-03 == Outdated reference: A later version (-03) exists of draft-atlas-ospf-mrt-00 == Outdated reference: A later version (-04) exists of draft-enyedi-rtgwg-mrt-frr-algorithm-03 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). 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 Juniper Networks 5 Expires: January 13, 2014 J. Tantsura 6 Ericsson 7 IJ. Wijnands 8 Cisco Systems, Inc. 9 July 12, 2013 11 LDP Extensions to Support Maximally Redundant Trees 12 draft-atlas-mpls-ldp-mrt-00 14 Abstract 16 This document specifies extensions to LDP to support the creation of 17 label-switched paths for Maximally Redundant Trees (MRT). A prime 18 use of MRTs is for unicast and multicast IP/LDP Fast-Reroute (MRT- 19 FRR). 21 The sole protocol extension to LDP is simply the ability to advertise 22 an MRT Capability. This document describes that extension and the 23 associated behavior expected for LSRs and LERs advertising the MRT 24 Capability. 26 MRT-FRR uses LDP multi-topology extensions and requires three 27 different multi-topology IDs to be allocated from the LDP MT-ID 28 space. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 13, 2014. 47 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 65 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 4. Overview of LDP Signaling Extensions for MRT . . . . . . . . 4 67 4.1. MRT Capability Advertisement . . . . . . . . . . . . . . 5 68 4.2. Behavior Related to the Rainbow MRT MT-ID . . . . . . . . 6 69 4.3. MRT-Blue and MRT-Red FECs . . . . . . . . . . . . . . . . 6 70 5. LDP MRT FEC Advertisements . . . . . . . . . . . . . . . . . 7 71 5.1. Downstream Unsolicited Mode . . . . . . . . . . . . . . . 7 72 5.2. Downstream On Demand Mode . . . . . . . . . . . . . . . . 7 73 5.3. Inter-Area . . . . . . . . . . . . . . . . . . . . . . . 8 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 76 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 79 9.2. Informative References . . . . . . . . . . . . . . . . . 9 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 82 1. Introduction 84 This document describes the LDP signaling extension and associated 85 behavior necessary to support the architecture that defines how IP/ 86 LDP Fast-Reroute can use MRTs [I-D.ietf-rtgwg-mrt-frr-architecture]. 87 It is necessary to read the architecture in 88 [I-D.ietf-rtgwg-mrt-frr-architecture] to understand how and why the 89 LDP extensions for behavior are needed. 91 At least one common standardized algorithm, such as the lowpoint 92 algorithm explained and fully documented in 93 [I-D.enyedi-rtgwg-mrt-frr-algorithm], is required so that the routers 94 supporting MRT computation consistently compute the same MRTs. LDP 95 depends on the IGP to compute the MRTs and alternates; extensions to 96 OSPF are defined in [I-D.atlas-ospf-mrt]. 98 MRT can also be used to protect multicast traffic via either global 99 protection or local protection.[I-D.atlas-rtgwg-mrt-mc-arch] An MRT 100 path can be used to provide node-protection for mLDP traffic via the 101 mechanisms described in [I-D.wijnands-mpls-mldp-node-protection]; an 102 MRT path can also be use to provide link protection for mLDP traffic. 104 For each destination, IP/LDP Fast-Reroute with MRT (MRT-FRR) creates 105 two alternate destination-based trees separate from the primary next- 106 hop forwarding used during stable operation. LDP uses the multi- 107 topology extensions [I-D.ietf-mpls-ldp-multi-topology] to signal FECs 108 for these two new forwarding topologies, known as MRT-Blue and MRT- 109 Red. 111 In order to create MRT paths and support IP/LDP Fast-Reroute, a new 112 capability extension is needed for LDP. An LDP implementation 113 supporting MRT must also follow the described rules for originating 114 and managing FECs related to MRT, as indicated by their multi- 115 topology ID. Network reconvergence is described in 116 [I-D.ietf-rtgwg-mrt-frr-architecture] and the worst-cast network 117 convergence time can be flooded via the extension in Section 7 of 118 [I-D.atlas-ospf-mrt]. 120 IP/LDP Fast-Reroute using MRTs can provide 100% coverage for link and 121 node failures in an arbitrary network topology where the failure 122 doesn't split the network. It can also be deployed incrementally; an 123 MRT Island is formed of connected supporting routers and the MRTs are 124 computed inside that island. 126 2. Requirements Language 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in [RFC2119] 132 3. Terminology 134 For ease of reading, some of the terminology defined in 135 [I-D.ietf-rtgwg-mrt-frr-architecture] is repeated here. 137 Redundant Trees (RT): A pair of trees where the path from any node 138 X to the root R along the first tree is node-disjoint with the 139 path from the same node X to the root along the second tree. 140 These can be computed in 2-connected graphs. 142 Maximally Redundant Trees (MRT): A pair of trees where the path 143 from any node X to the root R along the first tree and the path 144 from the same node X to the root along the second tree share the 145 minimum number of nodes and the minimum number of links. Each 146 such shared node is a cut-vertex. Any shared links are cut-links. 147 Any RT is an MRT but many MRTs are not RTs. The two MRTs are 148 referred to as MRT-Blue and MRT-Red. 150 MRT Island: From the computing router, the set of routers that 151 support a particular MRT profile and are connected via MRT- 152 eligible links. 154 MRT-Red: MRT-Red is used to describe one of the two MRTs; it is 155 used to described the associated forwarding topology and MT-ID. 156 Specifically, MRT-Red is the decreasing MRT where links in the 157 GADAG are taken in the direction from a higher topologically 158 ordered node to a lower one. 160 MRT-Blue: MRT-Blue is used to describe one of the two MRTs; it is 161 used to described the associated forwarding topology and MT-ID. 162 Specifically, MRT-Blue is the increasing MRT where links in the 163 GADAG are taken in the direction from a lower topologically 164 ordered node to a higher one. 166 Rainbow MRT: It is useful to have an MT-ID that refers to the 167 multiple MRT topologies and to the default topology. This is 168 referred to as the Rainbow MRT MT-ID and is used by LDP to reduce 169 signaling and permit the same label to always be advertised to all 170 peers for the same (MT-ID, Prefix). 172 4. Overview of LDP Signaling Extensions for MRT 174 Routers need to know which of their neighbors support MRT. 175 Supporting MRT indicates several different aspects of behavior, as 176 listed below. 178 1. Support for Multi-Topology (MT) - this MAY also be indicated via 179 the Multi-Capability MT Capability 180 [I-D.ietf-mpls-ldp-multi-topology]. 182 2. Understand the Rainbow MRT MT-ID and apply the associated labels 183 to all relevant MT-IDs. 185 3. Advertise the Rainbow MRT MT-ID to the appropriate neighbors for 186 the associated prefix. 188 4. If acting as egress for a prefix in the default topology, also 189 advertise and act as egress for the same prefix in MRT-Red and 190 MRT-Blue. 192 5. For a FEC learned from a neighbor that does not support MRT, 193 originate FECS for MRT-Red and MRT-Blue with the same prefix. 195 4.1. MRT Capability Advertisement 197 It is not possible to support MRT without supporting the LDP multi- 198 topology extensions, but it is possible that the only use of the 199 multi-topology extensions is for MRT. In that case, a router MAY not 200 negotiate the multi-topology capability and only negotiate the MRT 201 Capability with its LDP peer. Negotiation of the MT capability is 202 not required with negotiation of the MRT capability. 204 [EDITOR NOTE: How do we deal with different abilities for IPv4 and 205 IPv6? The MT capability has the Wildcard FEC to indicate this. Do 206 we just assume??] 208 A new MRT Capability Parameter TLV is defined, which is defined in 209 accordance with LDP Capability definition guidelines[RFC5561]. 211 The LDP MRT capability can be advertised during the LDP session 212 initialization or after the LDP session is estblished. Advertisement 213 of the MRT capability indicates support of the procedures for 214 establishing the MRT-Blue and MRT-Red LSP paths detailed in this 215 document. If the peer has not advertised the corresponding 216 capability, then it indicates that LSR is not capable of supporting 217 MRT procedures. 219 The following is the format of the MRT Capability Parameter. 221 0 1 2 3 222 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 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 |U|F| MRT Capability (IANA) | Length (= 1) | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 |S| Reserved | 227 +-+-+-+-+-+-+-+-+ 229 MRT Capability TLV Format 231 Where: 233 U- and F-bits: MUST be 1 and 0, respectively, as per Section 3. 234 (Signaling Extensions) of LDP Capabilities [RFC5561]. 236 MRT Capability: Capability TLV type (IANA assigned) 238 S-bit: MUST be 1 if used in LDP "Initialization" message. MAY be 239 set to 0 or 1 in dynamic "Capability" message to advertise or 240 withdraw the capability respectively. 242 Length: The length (in octets) of TLV. Its value is 1. 244 4.2. Behavior Related to the Rainbow MRT MT-ID 246 In Section 9 of [I-D.ietf-rtgwg-mrt-frr-architecture], the need to 247 advertise different MPLS labels to different neighbors for the same 248 FEC is described. This can be shortly summarized as either 249 advertising MRT MT-ID differentiated labels to a neighbor or just 250 advertising the same MPLS label for the default topology, for MRT-Red 251 and MRT-Blue. MRT-supporting neighbors in the same domain as the 252 default SPT next-hop get the differentiated MPLS labels; all other 253 neighbors do not. 255 A second use for the Rainbow MRT MT-ID is for an egress LER to send 256 the Rainbow MRT MT-ID with an IMPLICIT_NULL label to indicate 257 penultimate-hop-popping for all three types of FECs (IP Prefix FEC, 258 MRT-Blue MT-IP Prefix FEC, and MRT-Red MT-IP Prefix FEC). 260 An LSR advertising the MRT capability MUST recognize the Rainbow MRT 261 MT-ID and associate the advertised label with the specific prefix for 262 the default topology (MT-ID 0) and with the MRT-Red and MRT-Blue MT- 263 IDs associated with all MRT Profiles that advertise LDP as the 264 forwarding mechanism. 266 An LSR is RECOMMENDED to use the Rainbow MRT MT-ID to reduce the 267 amount of state and signaling required. 269 As described in [I-D.ietf-rtgwg-mrt-frr-architecture], the 270 recommended experimental value for the Rainbow MRT MT-ID is 3999. 271 The final value will be assigned by IANA and allocated from the LDP 272 MT-ID space. 274 4.3. MRT-Blue and MRT-Red FECs 276 To provide MRT support in LDP, the MT Prefix FEC is used. For the 277 default MRT Profile, an MRT-Blue FEC uses the MRT-Blue MT-ID value 278 TBD3 allocated by IANA; for experimental purposes, the value 3998 is 279 suggested. For the default MRT Profile, an MRT-Red FEC uses the MRT- 280 Red MT-ID value TBD2 allocated by IANA; for experimental purposes, 281 the value 3997 is suggested. 283 The MT Prefix FEC encoding is defined in 284 [I-D.ietf-mpls-ldp-multi-topology] and is used without alternation 285 for signaling MRT-Blue, MRT-Red and Rainbow MRT FECs. 287 5. LDP MRT FEC Advertisements 289 This sections describes how and when labels for MRT-Red and MRT-Blue 290 FECs are advertised. The associated LSPs must be created before any 291 failure occurs. 293 5.1. Downstream Unsolicited Mode 295 If the upstream session is negotiated with the MRT capability, the 296 Egress LER advertises via a Rainbow MRT FEC an allocated MPLS label; 297 this may be Explicit Null, Implicit Null, or another value. 299 Based on the MRT algorithm [I-D.enyedi-rtgwg-mrt-frr-algorithm], the 300 IGP computes the MRT-Red and MRT-Blue disjoint paths at Ingress and 301 Transit LSRs. Once the IGP computes the MRT-Red and MRT-Blue next- 302 hops, LDP will advertise the Label Mapping for the MRT-Blue and MRT- 303 Red FECs. If a label is received from a downstream LSR for an MRT- 304 Red or MRT-Blue FEC where the downstream LSR is capable of MRT, the 305 MRT-Red FEC or MRT-Blue FEC label is swapped according to the 306 received downstream label. An LSR may also choose to use the MRT-Red 307 or MRT-Blue path as an alternative for doing fast-reroute for the 308 local traffic. 310 When a downstream router is not capable of MRT, the LSR is an MRT 311 Island Border Router (IBR) and SHOULD advertise Label Bindings for 312 the MRT-Red FEC and MRT-Blue FEC as well as the associated normal 313 topology. The normal topology's primary next-hops will be used to 314 forward traffic received for the MRT-Red FEC or the MRT-Blue FEC 315 where the FEC's destination is outside the MRT Island. This 316 functionality is critical for partial deployment scenarios. 318 5.2. Downstream On Demand Mode 320 After the IGP computes the MRT-Red and MRT-Blue paths, the IGP MAY 321 also decide to use either the MRT-Red or MRT-Blue path as a fast- 322 reroute alternate for the particular FEC. If so, then when in 323 Downstream On Demand Mode, the LSR sends a Label Request for either 324 the MRT-Red or MRT-Blue FEC to the downstream LSR. The downstream 325 LSR responds by either sending a Label Mapping if available or by 326 sending a Label Request to its downstream LSR. Once a Label Mapping 327 is received, the associated label may be used as a fast-reroute 328 alternative to forward IP and LDP traffic. 330 A Label Mapping may be available in the following circumstances: 332 o The LSR is acting as Egress 334 o A Label Mapping was already received from its downstream router 336 o A Label Mapping for the default topology FEC was received and the 337 downstream router is not capable of MRT or is in a different MRT 338 Island. 340 5.3. Inter-Area 342 As discussed in Section 4.2, the Rainbow MRT FEC is defined to 343 facilitate signaling the same label for multiple topologies. 344 Section 9 of [I-D.ietf-rtgwg-mrt-frr-architecture] recommends that 345 traffic leaving an OSPF area or IS-IS level SHOULD use the default 346 topology's shortest-path-tree next-hops instead of remaining on the 347 MRT-Red or MRT-Blue paths. If an LDP peer is in the same OSPF area 348 or IS-IS level as the primary next-hop, then LDP SHOULD advertise 349 different label values for a given set of MRT-Red FEC, MRT-Blue FEC, 350 and FEC, unless Explicit-Null or Implicit-Null is appropriate. If an 351 LDP peer is in a different OSPF area or IS-IS level from the primary 352 next-hop, then LDP SHOULD either advertise the same label value for 353 the given set of MRT-Red FEC, MRT-Blue FEC, and FEC or advertise a 354 single label for the Rainbow MRT FEC, whose behavior is defined in 355 Section 4.2. 357 6. Security Considerations 359 This LDP extension is not believed to introduce new security 360 concerns. It relies upon the security architecture already provided 361 for LDP. 363 7. IANA Considerations 365 New LDP Capability TLV: "MRT Capability" TLV (requested code point: 366 TBA from LDP registry "TLV Type Name Space"). For interoperable 367 experimental purposes, the value of ... is suggested. 369 Allocations from the "LDP Multi-Topology (MT) ID Name Space" 370 [I-D.ietf-mpls-ldp-multi-topology] under "LDP Parameter" namespace: 372 o Rainbow MRT MT-ID: TBD1 374 o default Profile MRT-Red MT-ID: TBD2 - requested under 4096 so it 375 can also be signaled in PIM 377 o default Profile MRT-Blue MT-ID: TBD3 - requested under 4096 so it 378 can also be signaled in PIM 380 For interoperable experiments, the following values are suggested for 381 experimentation: Rainbow MRT MT-ID 3999, default MRT Profile MRT-Blue 382 MT-ID 3998, default MRT Profile MRT-Red MT-ID 3997. The MT-IDs are 383 taken from the 3996-4096 range, which IS-IS defines as for private 384 use, and which [I-D.ietf-mpls-ldp-multi-topology] does not specify as 385 reserved (and MPLS list email suggests that range may be reserved for 386 private use mapping from the IS-IS space). 388 8. Acknowledgements 390 The authors would like to thank Ross Callon for his suggestions. 392 9. References 394 9.1. Normative References 396 [I-D.ietf-mpls-ldp-multi-topology] 397 Zhao, Q., Fang, L., Zhou, C., Li, L., and K. Raza, "LDP 398 Extensions for Multi Topology Routing", draft-ietf-mpls- 399 ldp-multi-topology-08 (work in progress), May 2013. 401 [I-D.ietf-rtgwg-mrt-frr-architecture] 402 Atlas, A., Kebler, R., Envedi, G., Csaszar, A., Tantsura, 403 J., Konstantynowicz, M., and R. White, "An 404 Architecture for IP/LDP Fast-Reroute Using Maximally 405 Redundant Trees", draft-ietf-rtgwg-mrt-frr-architecture-03 406 (work in progress), July 2013. 408 [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. 409 Le Roux, "LDP Capabilities", RFC 5561, July 2009. 411 9.2. Informative References 413 [I-D.atlas-ospf-mrt] 414 Atlas, A., Hegde, S., Chris, C., and J. Tantsura, "OSPF 415 Extensions to Support Maximally Redundant Trees", draft- 416 atlas-ospf-mrt-00 (work in progress), July 2013. 418 [I-D.atlas-rtgwg-mrt-mc-arch] 419 Atlas, A., Kebler, R., Wijnands, I., Csaszar, A., and G. 420 Envedi, "An Architecture for Multicast Protection Using 421 Maximally Redundant Trees", draft-atlas-rtgwg-mrt-mc- 422 arch-02 (work in progress), July 2013. 424 [I-D.enyedi-rtgwg-mrt-frr-algorithm] 425 Atlas, A., Envedi, G., Csaszar, A., Gopalan, A., and 426 C. Bowers, "Algorithms for computing Maximally Redundant 427 Trees for IP/LDP Fast- Reroute", draft-enyedi-rtgwg-mrt- 428 frr-algorithm-03 (work in progress), July 2013. 430 [I-D.wijnands-mpls-mldp-node-protection] 431 Wijnands, I., Rosen, E., Raza, K., Tantsura, J., Atlas, 432 A., and Q. Zhao, "mLDP Node Protection", draft-wijnands- 433 mpls-mldp-node-protection-04 (work in progress), June 434 2013. 436 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 437 Requirement Levels", BCP 14, RFC 2119, March 1997. 439 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 440 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 441 4915, June 2007. 443 [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free 444 Convergence", RFC 5715, January 2010. 446 Authors' Addresses 448 Alia Atlas 449 Juniper Networks 450 10 Technology Park Drive 451 Westford, MA 01886 452 USA 454 Email: akatlas@juniper.net 456 Kishore Tiruveedhula 457 Juniper Networks 458 10 Technology Park Drive 459 Westford, MA 01886 460 USA 462 Email: kishoret@juniper.net 464 Jeff Tantsura 465 Ericsson 466 300 Holger Way 467 San Jose, CA 95134 468 USA 470 Email: jeff.tantsura@ericsson.com 471 IJsbrand Wijnands 472 Cisco Systems, Inc. 474 Email: ice@cisco.com