idnits 2.17.1 draft-ietf-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, 2015) is 3218 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 (-09) exists of draft-ietf-rtgwg-mrt-frr-algorithm-05 == Outdated reference: A later version (-10) exists of draft-ietf-rtgwg-mrt-frr-architecture-05 == Outdated reference: A later version (-03) exists of draft-ietf-isis-mrt-00 == Outdated reference: A later version (-03) exists of draft-ietf-ospf-mrt-00 Summary: 0 errors (**), 0 flaws (~~), 6 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 C. Bowers 5 Expires: January 5, 2016 Juniper Networks 6 J. Tantsura 7 Ericsson 8 IJ. Wijnands 9 Cisco Systems, Inc. 10 July 4, 2015 12 LDP Extensions to Support Maximally Redundant Trees 13 draft-ietf-mpls-ldp-mrt-01 15 Abstract 17 This document specifies extensions to the Label Distribution 18 Protocol(LDP) to support the creation of label-switched paths for 19 Maximally Redundant Trees (MRT). A prime use of MRTs is for unicast 20 and multicast IP/LDP Fast-Reroute, which we will refer to as MRT-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, 2016. 48 Copyright Notice 50 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 67 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 4. Overview of LDP Signaling Extensions for MRT . . . . . . . . 5 69 4.1. MRT Capability Advertisement . . . . . . . . . . . . . . 5 70 4.1.1. Interaction of MRT Capability and MT Capability . . . 6 71 4.1.2. Interaction of LDP MRT Capability with IPv4 and IPv6 6 72 4.2. Use of the Rainbow MRT MT-ID . . . . . . . . . . . . . . 7 73 4.3. MRT-Blue and MRT-Red FECs . . . . . . . . . . . . . . . . 7 74 5. LDP MRT FEC Advertisements . . . . . . . . . . . . . . . . . 7 75 5.1. MRT-specific behavior . . . . . . . . . . . . . . . . . . 8 76 5.1.1. ABR behavior and use of the Rainbow FEC . . . . . . . 8 77 5.1.2. Proxy-node attachment router behavior . . . . . . . . 9 78 5.2. LDP protocol procedures in the context of MRT label 79 distribution . . . . . . . . . . . . . . . . . . . . . . 10 80 5.2.1. LDP peer in RFC5036 . . . . . . . . . . . . . . . . . 10 81 5.2.2. Next hop in RFC5036 . . . . . . . . . . . . . . . . . 10 82 5.2.3. Egress LSR in RFC5036 . . . . . . . . . . . . . . . . 11 83 5.2.4. Use of Rainbow FEC to satisfy label mapping existence 84 requirements in RFC5036 . . . . . . . . . . . . . . . 12 85 5.2.5. Validating FECs in routing table . . . . . . . . . . 13 86 5.2.6. Recognizing new FECs . . . . . . . . . . . . . . . . 13 87 5.2.7. Not propagating Rainbow FEC label mappings . . . . . 13 88 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 90 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 92 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 93 9.2. Informative References . . . . . . . . . . . . . . . . . 15 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 96 1. Introduction 98 This document describes the LDP signaling extension and associated 99 behavior necessary to support the architecture that defines how IP/ 100 LDP Fast-Reroute can use MRTs [I-D.ietf-rtgwg-mrt-frr-architecture]. 101 It is necessary to be familiar with the architecture in 102 [I-D.ietf-rtgwg-mrt-frr-architecture] to understand how and why the 103 LDP extensions for behavior are needed. 105 At least one common standardized algorithm (e.g. the MRT Lowpoint 106 algorithm explained and fully documented in 107 [I-D.ietf-rtgwg-mrt-frr-algorithm]) is required so that the routers 108 supporting MRT computation consistently compute the same MRTs. LDP 109 depends on an IGP for computation of MRTs and alternates. Extensions 110 to OSPF are defined in [I-D.ietf-ospf-mrt]. Extension to IS-IS are 111 defined in [I-D.ietf-isis-mrt]. 113 MRT can also be used to protect multicast traffic (signalled via PIM 114 or mLDP) using either global protection or local protection 115 [I-D.atlas-rtgwg-mrt-mc-arch]. An MRT path can be used to provide 116 node-protection for mLDP traffic via the mechanisms described in 117 [I-D.wijnands-mpls-mldp-node-protection]; an MRT path can also be 118 used to provide link protection for mLDP traffic. 120 For each destination, IP/LDP Fast-Reroute with MRT (MRT-FRR) creates 121 two alternate destination-based trees separate from the shortest path 122 forwarding used during stable operation. LDP uses the multi-topology 123 extensions [RFC7307] to signal Forwarding Equivalency Classes (FECs) 124 for these two sets of forwarding trees, MRT-Blue and MRT-Red. 126 In order to create MRT paths and support IP/LDP Fast-Reroute, a new 127 capability extension is needed for LDP. An LDP implementation 128 supporting MRT MUST also follow the rules described here for 129 originating and managing FECs related to MRT, as indicated by their 130 multi-topology ID. Network reconvergence is described in 131 [I-D.ietf-rtgwg-mrt-frr-architecture] and the worst-case network 132 convergence time can be flooded via the extension in Section 7 of 133 [I-D.ietf-ospf-mrt]. 135 IP/LDP Fast-Reroute using MRTs can provide 100% coverage for link and 136 node failures in an arbitrary network topology where the failure 137 doesn't partition the network. It can also be deployed 138 incrementally; an MRT Island is formed of connected supporting 139 routers and the MRTs are computed inside that island. 141 2. Requirements Language 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [RFC2119] 147 3. Terminology 149 For ease of reading, some of the terminology defined in 150 [I-D.ietf-rtgwg-mrt-frr-architecture] is repeated here. 152 Redundant Trees (RT): A pair of trees where the path from any node 153 X to the root R along the first tree is node-disjoint with the 154 path from the same node X to the root along the second tree. 155 These can be computed in 2-connected graphs. 157 Maximally Redundant Trees (MRT): A pair of trees where the path 158 from any node X to the root R along the first tree and the path 159 from the same node X to the root along the second tree share the 160 minimum number of nodes and the minimum number of links. Each 161 such shared node is a cut-vertex. Any shared links are cut-links. 162 Any RT is an MRT but many MRTs are not RTs. The two MRTs are 163 referred to as MRT-Blue and MRT-Red. 165 MRT-Red: MRT-Red is used to describe one of the two MRTs; it is 166 used to described the associated forwarding topology and MT-ID. 167 Specifically, MRT-Red is the decreasing MRT where links in the 168 GADAG are taken in the direction from a higher topologically 169 ordered node to a lower one. 171 MRT-Blue: MRT-Blue is used to describe one of the two MRTs; it is 172 used to described the associated forwarding topology and MT-ID. 173 Specifically, MRT-Blue is the increasing MRT where links in the 174 GADAG are taken in the direction from a lower topologically 175 ordered node to a higher one. 177 Rainbow MRT MT-ID: It is useful to have an MT-ID that refers to the 178 multiple MRT topologies and to the default topology. This is 179 referred to as the Rainbow MRT MT-ID and is used by LDP to reduce 180 signaling and permit the same label to always be advertised to all 181 peers for the same (MT-ID, Prefix). 183 MRT Island: From the computing router, the set of routers that 184 support a particular MRT profile and are connected via MRT- 185 eligible links. 187 Island Border Router (IBR): A router in the MRT Island that is 188 connected to a router not in the MRT Island and both routers are 189 in a common area or level. 191 Island Neighbor (IN): A router that is not in the MRT Island but is 192 adjacent to an IBR and in the same area/level as the IBR.. 194 4. Overview of LDP Signaling Extensions for MRT 196 Routers need to know which of their LDP neighbors support MRT. This 197 is communicated using the MRT Capability Advertisement. Supporting 198 MRT indicates several different aspects of behavior, as listed below. 200 1. Sending and receiving multi-topology FEC elements, as defined in 201 [RFC7307]. 203 2. Understanding the Rainbow MRT MT-ID and applying the associated 204 labels to all relevant MT-IDs. 206 3. Advertising the Rainbow MRT FEC to the appropriate neighbors for 207 the appropriate prefix. 209 4. If acting as LDP egress for a prefix in the default topology, 210 also acting as egress for the same prefix in MRT-Red and MRT- 211 Blue. 213 5. For a FEC learned from a neighbor that does not support MRT, 214 originating FECs for MRT-Red and MRT-Blue with the same prefix. 215 This MRT Island egress behavior is to support an MRT Island that 216 does not include all routers in the area/level. 218 4.1. MRT Capability Advertisement 220 A new MRT Capability Parameter TLV is defined in accordance with LDP 221 Capability definition guidelines[RFC5561]. 223 The LDP MRT capability can be advertised during LDP session 224 initialization or after the LDP session is established. 225 Advertisement of the MRT capability indicates support of the 226 procedures for establishing the MRT-Blue and MRT-Red LSP paths 227 detailed in this document. If the peer has not advertised the MRT 228 capability, then it indicates that LSR does not support MRT 229 procedures. 231 If a router advertises the LDP MRT capability to its peer, but the 232 peer has not advertised the MRT capability, then the router MUST NOT 233 advertise MRT-related FEC-label bindings to that peer. 235 The following is the format of the MRT Capability Parameter. 237 0 1 2 3 238 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 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 |U|F| MRT Capability (IANA) | Length (= 1) | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 |S| Reserved | 243 +-+-+-+-+-+-+-+-+ 245 MRT Capability TLV Format 247 Where: 249 U-bit: The unknown TLV bit MUST be 1. A router that does not 250 recognize the MRT Capability TLV will silently ignore the TLV and 251 process the rest of the message as if the unknown TLV did not 252 exist. 254 F-bit: The forward unknown TLV bit MUST be 0 as required by 255 Section 3 of [RFC5561]. 257 MRT Capability: TBA-MRT-LDP-1 (To Be Allocated by IANA) 259 Length: The length (in octets) of TLV. Its value is 1. 261 S-bit: The State bit MUST be 1 if used in LDP "Initialization" 262 message. MAY be set to 0 or 1 in dynamic "Capability" message to 263 advertise or withdraw the capability respectively, as described in 264 [RFC5561]. 266 4.1.1. Interaction of MRT Capability and MT Capability 268 An LSR advertising the LDP MRT Capability MUST also advertise the LDP 269 Multi-topology (MT) capability. If an LSR negotiates LDP MRT 270 Capability with an LDP neighbor without also negotiating the LDP MT 271 Capability, the LSR MUST behave as if LDP MRT Capability has not been 272 negotiated and respond with the "MRT Capability negotiated without MT 273 Capability" status code in the LDP Notification message (defined in 274 the document). The E-bit of this Notification should be set to 0 to 275 indicate that this is an Advisory Notification. The LDP session 276 SHOULD NOT be terminated. 278 4.1.2. Interaction of LDP MRT Capability with IPv4 and IPv6 280 The MRT LDP Capability Advertisement does not distinguish between 281 IPv4 and IPv6 address families. An LSR which advertises the MRT LDP 282 capability is expected to advertise MRT-related FEC-label bindings 283 for the same address families for which it advertises shortest-path 284 FEC-label bindings. Therefore, an LSR advertising MRT LDP capability 285 and shortest path FEC-label bindings for IPv4 only (or IPv6 only) 286 would be expected to advertise MRT-related FEC-label binding for IPv4 287 only (or IPv6 only). An LSR advertising the MRT LDP capability and 288 shortest-path FEC label bindings for BOTH IPv4 and IPv6 is expected 289 to advertise MRT-related FEC-label bindings for BOTH IPv4 and IPv6. 290 In this scenario, advertising MRT-related FEC-label bindings only for 291 IPv4 only (or only for IPv6) is not supported. 293 4.2. Use of the Rainbow MRT MT-ID 295 Section 10.1 of [I-D.ietf-rtgwg-mrt-frr-architecture] describes the 296 need for an area border router (ABR) to have different neighbors use 297 different MPLS labels when sending traffic to the ABR for the same 298 FEC. More detailed discussion of the Rainbow MRT MT-ID is provided 299 in Section 5.1.1. 301 Another use for the Rainbow MRT MT-ID is for an LSR to send the 302 Rainbow MRT MT-ID with an IMPLICIT_NULL label to indicate 303 penultimate-hop-popping for all three types of FECs (shortest path, 304 red, and blue). The EXPLICIT_NULL label advertised using the Rainbow 305 MRT MT-ID similarly applies to all the types of FECs. Note that the 306 only scenario in which it is generally useful to advertise the 307 implicit or explicit null label for all three FEC types is when the 308 FEC refers to the LSR itself. See Section 5.2.3 for more details. 310 The value of the Rainbow MRT MT-ID (TBA-MRT-LDP-2) will be assigned 311 by IANA from the LDP MT-ID space. Prototype experiments have used 312 the value 3999. 314 4.3. MRT-Blue and MRT-Red FECs 316 To provide MRT support in LDP, the MT Prefix FEC is used. 317 [I-D.ietf-rtgwg-mrt-frr-architecture] contains the IANA request for 318 the MRT-Red and MRT-Blue MT-IDs associated with the Default MRT 319 Profile. 321 The MT Prefix FEC encoding is defined in [RFC7307] and is used 322 without alteration for advertising label mappings for MRT-Blue, MRT- 323 Red and Rainbow MRT FECs. 325 5. LDP MRT FEC Advertisements 327 This sections describes how and when labels for MRT-Red and MRT-Blue 328 FECs are advertised. The associated LSPs must be created before a 329 failure occurs, in order to provide protection paths which are 330 immediately usable by the point of local repair in the event of a 331 failure. 333 In this section, we will use the term "shortest path FEC" to refer to 334 the usual FEC associated with the shortest path destination-based 335 forwarding tree for a given prefix as determined by the IGP. We will 336 use the terms "red FEC" and "blue FEC" to refer to FECs associated 337 with the MRT-Red and MRT-Blue destination-based forwarding trees for 338 a given prefix as determined by a particular MRT algorithm. 340 We first describe label distribution behavior specific to MRT. Then 341 we provide the correct interpretation of several important concepts 342 in [RFC5036] in the context of MRT FEC label distribution. 344 5.1. MRT-specific behavior 346 5.1.1. ABR behavior and use of the Rainbow FEC 348 Section 10.1 of [I-D.ietf-rtgwg-mrt-frr-architecture] describes the 349 need for an area border router (ABR) to have different neighbors use 350 different MPLS labels when sending traffic to the ABR for the same 351 FEC. The method to accomplish this using the Rainbow MRT MT-ID is 352 described in detail in [I-D.ietf-rtgwg-mrt-frr-architecture]. Here 353 we provide a brief summary. To those LDP peers in the same area as 354 the best route to the destination, the ABR advertises two different 355 labels corresponding to the MRT-Red and MRT-Blue forwarding trees for 356 the destination. An LDP peer receiving these advertisements forwards 357 MRT traffic to the ABR using these two different labels, depending on 358 the FEC of the traffic. We refer to this as best-area advertising 359 and forwarding behavior, which is identical to normal MRT behavior. 361 For all other LDP peers supporting MRT, the ABR advertises a FEC- 362 label binding for the Rainbow MRT MT-ID scoped FEC with the label 363 corresponding to the default forwarding tree for the destination. An 364 LDP peer receiving this advertisement forwards MRT traffic to the ABR 365 using this label, for both MRT Red and MRT Blue traffic. We refer to 366 this as non-best-area advertising and forwarding behavior. 368 The use of the Rainbow-FEC by the ABR for non-best-area 369 advertisements is RECOMMENDED. An ABR MAY advertise the label for 370 the default topology in separate MRT-Blue and MRT-Red advertisements. 371 An LSR advertising the MRT capability MUST recognize the Rainbow MRT 372 MT-ID and associate the advertised label with the specific prefix 373 with the MRT-Red and MRT-Blue MT-IDs associated with all MRT Profiles 374 that advertise LDP as the forwarding mechanism. 376 Due to changes in topology or configuration, an ABR and a given LDP 377 peer may need to transition from best-area advertising and forwarding 378 behavior to non-best-area behavior for a given destination, and vice 379 versa. When the ABR requires best-area behavior for a red(blue) FEC, 380 it MUST withdraw any existing label mappings advertisements for the 381 corresponding rainbow FEC and advertise label mappings for the 382 red(blue) FEC. When the ABR requires non-best-area behavior for a 383 red(blue) FEC, it MUST withdraw any existing label mappings for both 384 red and blue FECs and advertise label mappings for the corresponding 385 Rainbow FEC label binding. 387 If an LSR receives a label mapping advertisement for a rainbow FEC 388 from an MRT LDP peer while it still retains a label mapping for the 389 corresponding red or blue FEC, the LSR MUST continue to use the label 390 mapping for the red or blue FEC, and it MUST send a Label Release 391 Message corresponding to the rainbow FEC label advertisement. If an 392 LSR receives a label mapping advertisement for red or blue FEC while 393 it still retains a label mapping for the corresponding rainbow FEC, 394 the LSR MUST continue to use the label mapping for the rainbow FEC, 395 and it MUST send a Label Release Message corresponding to the red or 396 blue FEC label advertisement. 398 5.1.2. Proxy-node attachment router behavior 400 Section 11.2 of [I-D.ietf-rtgwg-mrt-frr-architecture] describes how 401 MRT provides FRR protection for multi-homed prefixes using 402 calculations involving a named proxy-node. This covers the scenario 403 where a prefix is originated by a router in the same area as the MRT 404 Island, but outside of the MRT Island. It also covers the scenario 405 of a prefix being advertised by a multiple routers in the MRT Island. 407 In the named proxy-node calculation, each multi-homed prefix is 408 represented by a conceptual proxy-node which is attached to two real 409 proxy-node attachment routers. (A single proxy-node attachment 410 router is allowed in the case of a prefix advertised by a same area 411 router outside of the MRT Island which is singly connected to the MRT 412 Island.) All routers in the MRT Island perform the same calculations 413 to determine the same two proxy-node attachment routers for each 414 multi-homed prefix. The resulting graph in the computation consists 415 of the MRT Island with the proxy-node representing the multi-homed 416 prefix directly attached to the two proxy-node attachment routers. 417 Conceptually, one then runs the MRT algorithm on this simplified 418 graph to determine the MRT-red and blue next-hops to reach the proxy- 419 node, which gives the next-hops to reach the prefix. In this manner, 420 one can see that one of the two proxy-node attachment routers will 421 always have a MRT-red next-hop to the proxy-node while the other will 422 always have the MRT-blue next-hop to the proxy-node. We will refer 423 to these as the red and blue proxy-node attachment routers 424 respectively. (In practice, the MRT-red and blue next-hops to reach 425 the proxy-node can then be determined in a more computationally 426 efficient manner based on the MRT-red and blue next-hops to reach the 427 proxy-node attachment routers, as described in 428 [I-D.ietf-rtgwg-mrt-frr-algorithm].) 430 In terms of LDP behavior, a red proxy-node attachment router for a 431 given prefix MUST originate a label mapping for the red FEC for that 432 prefix, while the a blue proxy-node attachment router for a given 433 prefix MUST originate a label mapping for the blue FEC for that 434 prefix. If the red(blue) proxy-node attachment router is an Island 435 Border Router (IBR), then when it receives a packet with the label 436 corresponding to the red(blue) FEC for a prefix, it MUST forward the 437 packet to the Island Neighbor (IN) whose whose cost was used in the 438 selection of the IBR as a proxy-node attachment router. The IBR MUST 439 swap the incoming label for the outgoing label corresponding to the 440 shortest path FEC for the prefix advertised by the IN. In the case 441 where the IN does not support LDP, the IBR MUST pop the incoming 442 label and forward the packet to the IN. 444 If the proxy-node attachment router is not an IBR, then the packet 445 MUST be removed from the MRT forwarding topology and sent along the 446 interface(s) that caused the router to advertise the prefix. This 447 interface might be out of the area/level/AS. 449 5.2. LDP protocol procedures in the context of MRT label distribution 451 [RFC5036] specifies the LDP label distribution procedures for 452 shortest path FECs. In general, the same procedures can be applied 453 to the distribution of label mappings for red and blue FECs, provided 454 that the procedures are interpreted in the context of MRT FEC label 455 distribution. The correct interpretation of several important 456 concepts in [RFC5036] in the context of MRT FEC label distribution is 457 provided below. 459 5.2.1. LDP peer in RFC5036 461 In the context of distributing label mappings for red and blue FECs, 462 we restrict LDP peer in [RFC5036] to mean LDP peers for which the LDP 463 MRT capability has been negotiated. In order to make this 464 distinction clear, in this document we will use the term "MRT LDP 465 peer" to refer to an LDP peer for which the LDP MRT capability has 466 been negotiated. 468 5.2.2. Next hop in RFC5036 470 Several procedures in [RFC5036] use the next hop of a (shortest path) 471 FEC to determine behavior. The next hop of the shortest path FEC is 472 based on the shortest path forwarding tree to the prefix associated 473 with the FEC. When the procedures of [RFC5036] are used to 474 distribute label mapping for red and blue FECs, the next hop for the 475 red/blue FEC is based on the MRT-Red/Blue forwarding tree to the 476 prefix associated with the FEC. 478 For example, Appendix A.1.7. of [RFC5036] specifies the response by 479 an LSR to a change in the next hop for a FEC. For a shortest path 480 FEC, the next hop may change as the result of the LSR running a 481 shortest path computation on a modified IGP topology database. For 482 the red and blue FECs, the red and blue next hops may change as the 483 result of the LSR running a particular MRT algorithm on a modified 484 IGP topology database. 486 As another example, Section 2.6.1.2 of [RFC5036] specifies how that 487 when an LSR is using LSP Ordered Control, it may initiate the 488 transmission of a label mapping only for a (shortest path) FEC for 489 which it has a label mapping for the FEC next hop, or for which the 490 LSR is the egress. The FEC next hop for a shortest path FEC is based 491 on the shortest path forwarding tree to the prefix associated with 492 the FEC. In the context of distributing MRT LDP labels, this 493 procedure is understood to mean the following. When an LSR is using 494 LSP Ordered Control, it may initiate the transmission of a label 495 mapping only for a red(blue) FEC for which it has a label mapping for 496 the red(blue) FEC next hop, or for which the LSR is the egress. The 497 red or blue FEC next hop is based on the MRT-Red or Blue forwarding 498 tree to the prefix associated with the FEC. 500 5.2.3. Egress LSR in RFC5036 502 Procedures in [RFC5036] related to Ordered Control label distribution 503 mode rely on whether or not an LSR may act as an egress LSR for a 504 particular FEC in order to determine whether or not the LSR may 505 originate a label mapping for that FEC. The status of being an 506 egress LSR for a particular FEC is also used in loop detection 507 procedures in [RFC5036]. Section 2.6.1.2 of [RFC5036] specifies the 508 conditions under which an LSR may act as an egress LSR with respect 509 to a particular (shortest path) FEC. 511 1. The (shortest path) FEC refers to the LSR itself (including one 512 of its directly attached interfaces). 514 2. The next hop router for the (shortest path) FEC is outside of the 515 Label Switching Network. 517 3. (Shortest path) FEC elements are reachable by crossing a routing 518 domain boundary. 520 The conditions for determining an egress LSR with respect to a red or 521 blue FEC need to be modified. An LSR may act as an egress LSR with 522 respect to a particular red(blue) FEC under any of the following 523 conditions: 525 1. The prefix associated with the red(blue) FEC refers to the LSR 526 itself (including one of its directly attached interfaces). 528 2. The LSR is the red(blue) proxy-node attachment router with 529 respect to the multi-homed prefix associated with the red(blue) 530 FEC. This includes the degenerate case of a single red and blue 531 proxy-node attachment router for a single-homed prefix. 533 3. The LSR is an area border router (ABR) AND the MRT LDP peer 534 requires non-best-area advertising and forwarding behavior for 535 the prefix associated with the FEC. 537 Note that condition(3) scopes an LSR's status as an egress LSR with 538 respect to a particular FEC to a particular MRT LDP peer. Therefore, 539 the condition "Is LSR egress for FEC?" that occurs in several 540 procedures in [RFC5036] needs to be interpreted as "Is LSR egress for 541 FEC with respect to Peer?" 543 Also note that there is no explicit condition that allows an LSR to 544 be classified as an egress LSR with respect a red or blue FEC based 545 only on the primary next-hop for the shortest path FEC not supporting 546 LDP, or not supporting LDP MRT capability. These situations are 547 covered by the proxy-node attachment router and ABR conditions 548 (conditions 2 and 3). In particular, an Island Border Router is not 549 the egress LSR for a red(blue) FEC unless it is also the red(blue) 550 proxy-node attachment router for that FEC. 552 Also note that in general a proxy-node attachment router for a given 553 prefix should not advertise an implicit or explicit null label for 554 the corresponding red or blue FEC, even though it may be an egress 555 LSR for the shortest path FEC. In general, the proxy-node attachment 556 router needs to forward red or blue traffic for that prefix to a 557 particular loop free island neighbor, which may be different from the 558 shortest path next-hop. The proxy-node attachment router needs to 559 receive the red or blue traffic with a non-null label to correctly 560 forward it. 562 5.2.4. Use of Rainbow FEC to satisfy label mapping existence 563 requirements in RFC5036 565 Several procedures in [RFC5036] require the LSR to determine if it 566 has previously received and retained a label mapping for a FEC from 567 the next hop. In the case of an LSR that has received and retained a 568 label mapping for a Rainbow FEC from an ABR, the label mapping for 569 the Rainbow FEC satisfies the label mapping existence requirement for 570 the corresponding red and blue FECs. Label mapping existence 571 requirements in the context of MRT LDP label distribution are 572 modified as: "Has LSR previously received and retained a label 573 mapping for the red(blue) FEC (or the corresponding Rainbow FEC) from 574 the red(blue) next hop?" 576 As an example, this behavior allows an LSR which has received and 577 retained a label mapping for the Rainbow FEC to advertise label 578 mappings for the corresponding red and blue FECs when operating in 579 Ordered Control label distribution mode. 581 5.2.5. Validating FECs in routing table 583 In [RFC5036] an LSR uses its routing table to validate prefixes 584 associated with shortest path FECs. For example, section 3.5.7.1 of 585 [RFC5036] specifies that "an LSR receiving a Label Mapping message 586 from a downstream LSR for a Prefix SHOULD NOT use the label for 587 forwarding unless its routing table contains an entry that exactly 588 matches the FEC Element." In the context of MRT FECs, a red or blue 589 FEC element matches a routing table entry if the corresponding 590 shortest path FEC element matches a routing table entry. 592 5.2.6. Recognizing new FECs 594 Section A.1.6 of [RFC5036] describes the response of an LSR to the 595 "Recognize New FEC" event, which occurs when an LSR learns a new 596 (shortest path) FEC via the routing table. In the context of MRT 597 FECs, when MRT LDP capability has been enabled, when an LSR learns a 598 new shortest path FEC, it should generate "Recognize New FEC" events 599 for the corresponding red and blue FECs, in addition to the 600 "Recognize New FEC" event for the shortest path FEC. 602 5.2.7. Not propagating Rainbow FEC label mappings 604 A label mapping for the Rainbow FEC should only be originated by an 605 ABR under the conditions described in Section 5.1.1. A neighbor of 606 the ABR that receives a label mapping for the Rainbow FEC MUST NOT 607 propagate a label mapping for that Rainbow FEC. 609 6. Security Considerations 611 The labels distributed by the extensions in this document create 612 additional forwarding paths that do not following shortest path 613 routes. The transit label swapping operations defining these 614 alternative forwarding paths are created during normal operations 615 (before a failure occurs). Therefore, a malicious packet with an 616 appropriate label injected into the network from a compromised 617 location would be forwarded to a destinations along a non-shortest 618 path. When this technology is deployed, a network security design 619 should not rely on assumptions about potentially malicious traffic 620 only following shortest paths. 622 It should be noted that the creation of non-shortest forwarding paths 623 is not unique to MRT. 625 7. IANA Considerations 627 IANA is requested to allocate a value for the new LDP Capability TLV 628 (the first free value in the range 0x0500 to 0x05FF) from the LDP 629 registry "TLV Type Name Space": MRT Capability TLV (TBA-MRT-LDP-1). 631 Value Description Reference Notes / Reg. Date 632 ------------- ------------------ ------------ ----------------- 633 TBA-MRT-LDP-1 MRT Capability TLV [This draft] 635 IANA is requested to allocate a value for the new LDP Status Code 636 (the first free value in the range 0x00000032-0x00000036) from the 637 LDP registry "Status Code Name Space": "MRT Capability negotiated 638 without MT Capability" (TBA-MRT-LDP-3). 640 Value E Description Reference Notes / Reg. Date 641 ------------- - ------------------ ------------ ----------------- 642 TBA-MRT-LDP-3 0 MRT Capability [This draft] 643 negotiated without 644 MT Capability 646 IANA is requested to allocate a value from the MPLS Multi-Topology 647 Identifiers Name Space [RFC7307]: Rainbow MRT MT-ID (TBA-MRT-LDP-2). 649 Value Purpose Reference 650 ------------- ------------------ ------------ 651 TBA-MRT-LDP-2 Rainbow MRT MT-ID [This draft] 653 8. Acknowledgements 655 The authors would like to thank Ross Callon, Loa Andersson, Stewart 656 Bryant, Mach Chen, and Greg Mirsky for their suggestions. 658 9. References 660 9.1. Normative References 662 [I-D.ietf-rtgwg-mrt-frr-algorithm] 663 Envedi, G., Csaszar, A., Atlas, A., Bowers, C., and A. 664 Gopalan, "Algorithms for computing Maximally Redundant 665 Trees for IP/LDP Fast- Reroute", draft-ietf-rtgwg-mrt-frr- 666 algorithm-05 (work in progress), July 2015. 668 [I-D.ietf-rtgwg-mrt-frr-architecture] 669 Atlas, A., Kebler, R., Bowers, C., Envedi, G., Csaszar, 670 A., Tantsura, J., and R. White, "An Architecture for IP/ 671 LDP Fast-Reroute Using Maximally Redundant Trees", draft- 672 ietf-rtgwg-mrt-frr-architecture-05 (work in progress), 673 January 2015. 675 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 676 Specification", RFC 5036, October 2007. 678 [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. 679 Le Roux, "LDP Capabilities", RFC 5561, July 2009. 681 [RFC7307] Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D. 682 King, "LDP Extensions for Multi-Topology", RFC 7307, July 683 2014. 685 9.2. Informative References 687 [I-D.atlas-rtgwg-mrt-mc-arch] 688 Atlas, A., Kebler, R., Wijnands, I., Csaszar, A., and G. 689 Envedi, "An Architecture for Multicast Protection Using 690 Maximally Redundant Trees", draft-atlas-rtgwg-mrt-mc- 691 arch-02 (work in progress), July 2013. 693 [I-D.ietf-isis-mrt] 694 Li, Z., Wu, N., Zhao, Q., Atlas, A., Bowers, C., and J. 695 Tantsura, "Intermediate System to Intermediate System (IS- 696 IS) Extensions for Maximally Redundant Trees (MRT)", 697 draft-ietf-isis-mrt-00 (work in progress), February 2015. 699 [I-D.ietf-ospf-mrt] 700 Atlas, A., Hegde, S., Bowers, C., Tantsura, J., and Z. Li, 701 "OSPF Extensions to Support Maximally Redundant Trees", 702 draft-ietf-ospf-mrt-00 (work in progress), January 2015. 704 [I-D.wijnands-mpls-mldp-node-protection] 705 Wijnands, I., Rosen, E., Raza, K., Tantsura, J., Atlas, 706 A., and Q. Zhao, "mLDP Node Protection", draft-wijnands- 707 mpls-mldp-node-protection-04 (work in progress), June 708 2013. 710 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 711 Requirement Levels", BCP 14, RFC 2119, March 1997. 713 Authors' Addresses 715 Alia Atlas 716 Juniper Networks 717 10 Technology Park Drive 718 Westford, MA 01886 719 USA 721 Email: akatlas@juniper.net 723 Kishore Tiruveedhula 724 Juniper Networks 725 10 Technology Park Drive 726 Westford, MA 01886 727 USA 729 Email: kishoret@juniper.net 731 Chris Bowers 732 Juniper Networks 733 1194 N. Mathilda Ave. 734 Sunnyvale, CA 94089 735 USA 737 Email: cbowers@juniper.net 739 Jeff Tantsura 740 Ericsson 741 300 Holger Way 742 San Jose, CA 95134 743 USA 745 Email: jeff.tantsura@ericsson.com 747 IJsbrand Wijnands 748 Cisco Systems, Inc. 750 Email: ice@cisco.com