idnits 2.17.1 draft-ietf-mpls-ldp-mrt-04.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 == Line 89 has weird spacing: '... values impos...' == 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 (September 29, 2016) is 2756 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 (-03) exists of draft-ietf-isis-mrt-02 == Outdated reference: A later version (-03) exists of draft-ietf-ospf-mrt-02 Summary: 0 errors (**), 0 flaws (~~), 5 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: April 2, 2017 Juniper Networks 6 J. Tantsura 7 Individual 8 IJ. Wijnands 9 Cisco Systems, Inc. 10 September 29, 2016 12 LDP Extensions to Support Maximally Redundant Trees 13 draft-ietf-mpls-ldp-mrt-04 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 MPLS 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 April 2, 2017. 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 . . . . . . . . . . . . . . . . . . . . . . . . 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. Potential restrictions on MRT-related MT-ID values imposed 90 by RFC6420 . . . . . . . . . . . . . . . . . . . . . . . . . 14 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 92 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 94 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 95 10.2. Informative References . . . . . . . . . . . . . . . . . 16 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 99 1. Introduction 101 This document describes the LDP signaling extension and associated 102 behavior necessary to support the architecture that defines how IP/ 103 LDP Fast-Reroute can use MRTs [RFC7812]. It is necessary to be 104 familiar with the architecture in [RFC7812] to understand how and why 105 the LDP extensions for behavior are needed. 107 At least one common standardized algorithm (e.g. the MRT Lowpoint 108 algorithm explained and fully documented in [RFC7811]) is required so 109 that the routers supporting MRT computation consistently compute the 110 same MRTs. LDP depends on an IGP for computation of MRTs and 111 alternates. Extensions to OSPF are defined in [I-D.ietf-ospf-mrt]. 112 Extension to IS-IS are defined in [I-D.ietf-isis-mrt]. 114 MRT can also be used to protect multicast traffic (signalled via PIM 115 or mLDP) using either global protection or local protection 116 [I-D.atlas-rtgwg-mrt-mc-arch]. An MRT path can be used to provide 117 node-protection for mLDP traffic via the mechanisms described in 118 [I-D.wijnands-mpls-mldp-node-protection]; an MRT path can also be 119 used to provide link protection for mLDP traffic. 121 For each destination, IP/LDP Fast-Reroute with MRT (MRT-FRR) creates 122 two alternate destination-based trees separate from the shortest path 123 forwarding used during stable operation. LDP uses the multi-topology 124 extensions [RFC7307] to signal Forwarding Equivalency Classes (FECs) 125 for these two sets of forwarding trees, MRT-Blue and MRT-Red. 127 In order to create MRT paths and support IP/LDP Fast-Reroute, a new 128 capability extension is needed for LDP. An LDP implementation 129 supporting MRT MUST also follow the rules described here for 130 originating and managing FECs related to MRT, as indicated by their 131 multi-topology ID. Network reconvergence is described in [RFC7812] 132 and the worst-case network convergence time can be flooded via the 133 extension in Section 7 of [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 [RFC7812] is 150 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 Redundant trees can always 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 In graphs that are not 2-connected, it is not possible to compute 163 RTs. However, it is possible to compute MRTs. MRTs are maximally 164 redundant in the sense that they are as redundant as possible 165 given the constraints of the network graph. 167 MRT-Red: MRT-Red is used to describe one of the two MRTs; it is 168 used to describe the associated forwarding topology and MPLS 169 Multi-Topology IDentifier (MT-ID). Specifically, MRT-Red is the 170 decreasing MRT where links in the GADAG are taken in the direction 171 from a higher topologically ordered node to a lower one. 173 MRT-Blue: MRT-Blue is used to describe one of the two MRTs; it is 174 used to described the associated forwarding topology and MPLS MT- 175 ID. Specifically, MRT-Blue is the increasing MRT where links in 176 the GADAG are taken in the direction from a lower topologically 177 ordered node to a higher one. 179 Rainbow MRT: It is useful to have an MPLS MT-ID that refers to the 180 multiple MRT forwarding topologies and to the default forwarding 181 topology. This is referred to as the Rainbow MRT MPLS MT-ID and 182 is used by LDP to reduce signaling and permit the same label to 183 always be advertised to all peers for the same (MT-ID, Prefix). 185 MRT Island: The set of routers that support a particular MRT 186 profile and the links connecting them that support MRT. 188 Island Border Router (IBR): A router that is not in the MRT Island 189 but is adjacent to an IBR and in the same area/level as the IBR. 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: TBD-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 [RFC7812] describes the need for an area border 296 router (ABR) to have different neighbors use different MPLS labels 297 when sending traffic to the ABR for the same FEC. More detailed 298 discussion of the Rainbow MRT MT-ID is provided in Section 5.1.1 of 299 the current document. 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 MPLS MT-ID (TBD-MRT-LDP-3) will be 311 assigned by IANA from the MPLS MT-ID space. Prototype experiments 312 have used 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. [RFC7812] 317 defines the Default MRT Profile. This document contains the IANA 318 request for the MRT-Red and MRT-Blue MPLS MT-IDs associated with the 319 Default MRT Profile (TBD-MRT-LDP-4 and TBD-MRT-LDP-5). 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 [RFC7812] describes the need for an area border 349 router (ABR) to have different neighbors use different MPLS labels 350 when sending traffic to the ABR for the same FEC. The method to 351 accomplish this using the Rainbow MRT MT-ID is described in detail in 352 [RFC7812]. Here we provide a brief summary. To those LDP peers in 353 the same area as the best route to the destination, the ABR 354 advertises two different labels corresponding to the MRT-Red and MRT- 355 Blue forwarding trees for the destination. An LDP peer receiving 356 these advertisements forwards MRT traffic to the ABR using these two 357 different labels, depending on the FEC of the traffic. We refer to 358 this as best-area advertising and forwarding behavior, which is 359 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 [RFC7812] describes how MRT provides FRR protection 401 for multi-homed prefixes using calculations involving a named proxy- 402 node. This covers the scenario where a prefix is originated by a 403 router in the same area as the MRT Island, but outside of the MRT 404 Island. It also covers the scenario of a prefix being advertised by 405 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. [RFC7811] describes the procedure for 415 identifying one proxy-node attachment router as "red" and one as 416 "blue" with respect to the multi-homed prefix, and computing the MRT 417 red and blue next-hops to reach those red and blue proxy-node 418 attachment routers. 420 In terms of LDP behavior, a red proxy-node attachment router for a 421 given prefix MUST originate a label mapping for the red FEC for that 422 prefix, while the a blue proxy-node attachment router for a given 423 prefix MUST originate a label mapping for the blue FEC for that 424 prefix. If the red(blue) proxy-node attachment router is an Island 425 Border Router (IBR), then when it receives a packet with the label 426 corresponding to the red(blue) FEC for a prefix, it MUST forward the 427 packet to the Island Neighbor (IN) whose whose cost was used in the 428 selection of the IBR as a proxy-node attachment router. The IBR MUST 429 swap the incoming label for the outgoing label corresponding to the 430 shortest path FEC for the prefix advertised by the IN. In the case 431 where the IN does not support LDP, the IBR MUST pop the incoming 432 label and forward the packet to the IN. 434 If the proxy-node attachment router is not an IBR, then the packet 435 MUST be removed from the MRT forwarding topology and sent along the 436 interface(s) that caused the router to advertise the prefix. This 437 interface might be out of the area/level/AS. 439 5.2. LDP protocol procedures in the context of MRT label distribution 441 [RFC5036] specifies the LDP label distribution procedures for 442 shortest path FECs. In general, the same procedures can be applied 443 to the distribution of label mappings for red and blue FECs, provided 444 that the procedures are interpreted in the context of MRT FEC label 445 distribution. The correct interpretation of several important 446 concepts in [RFC5036] in the context of MRT FEC label distribution is 447 provided below. 449 5.2.1. LDP peer in RFC5036 451 In the context of distributing label mappings for red and blue FECs, 452 we restrict LDP peer in [RFC5036] to mean LDP peers for which the LDP 453 MRT capability has been negotiated. In order to make this 454 distinction clear, in this document we will use the term "MRT LDP 455 peer" to refer to an LDP peer for which the LDP MRT capability has 456 been negotiated. 458 5.2.2. Next hop in RFC5036 460 Several procedures in [RFC5036] use the next hop of a (shortest path) 461 FEC to determine behavior. The next hop of the shortest path FEC is 462 based on the shortest path forwarding tree to the prefix associated 463 with the FEC. When the procedures of [RFC5036] are used to 464 distribute label mapping for red and blue FECs, the next hop for the 465 red/blue FEC is based on the MRT-Red/Blue forwarding tree to the 466 prefix associated with the FEC. 468 For example, Appendix A.1.7. of [RFC5036] specifies the response by 469 an LSR to a change in the next hop for a FEC. For a shortest path 470 FEC, the next hop may change as the result of the LSR running a 471 shortest path computation on a modified IGP topology database. For 472 the red and blue FECs, the red and blue next hops may change as the 473 result of the LSR running a particular MRT algorithm on a modified 474 IGP topology database. 476 As another example, Section 2.6.1.2 of [RFC5036] specifies how that 477 when an LSR is using LSP Ordered Control, it may initiate the 478 transmission of a label mapping only for a (shortest path) FEC for 479 which it has a label mapping for the FEC next hop, or for which the 480 LSR is the egress. The FEC next hop for a shortest path FEC is based 481 on the shortest path forwarding tree to the prefix associated with 482 the FEC. In the context of distributing MRT LDP labels, this 483 procedure is understood to mean the following. When an LSR is using 484 LSP Ordered Control, it may initiate the transmission of a label 485 mapping only for a red(blue) FEC for which it has a label mapping for 486 the red(blue) FEC next hop, or for which the LSR is the egress. The 487 red or blue FEC next hop is based on the MRT-Red or Blue forwarding 488 tree to the prefix associated with the FEC. 490 5.2.3. Egress LSR in RFC5036 492 Procedures in [RFC5036] related to Ordered Control label distribution 493 mode rely on whether or not an LSR may act as an egress LSR for a 494 particular FEC in order to determine whether or not the LSR may 495 originate a label mapping for that FEC. The status of being an 496 egress LSR for a particular FEC is also used in loop detection 497 procedures in [RFC5036]. Section 2.6.1.2 of [RFC5036] specifies the 498 conditions under which an LSR may act as an egress LSR with respect 499 to a particular (shortest path) FEC. 501 1. The (shortest path) FEC refers to the LSR itself (including one 502 of its directly attached interfaces). 504 2. The next hop router for the (shortest path) FEC is outside of the 505 Label Switching Network. 507 3. (Shortest path) FEC elements are reachable by crossing a routing 508 domain boundary. 510 The conditions for determining an egress LSR with respect to a red or 511 blue FEC need to be modified. An LSR may act as an egress LSR with 512 respect to a particular red(blue) FEC under any of the following 513 conditions: 515 1. The prefix associated with the red(blue) FEC refers to the LSR 516 itself (including one of its directly attached interfaces). 518 2. The LSR is the red(blue) proxy-node attachment router with 519 respect to the multi-homed prefix associated with the red(blue) 520 FEC. This includes the degenerate case of a single red and blue 521 proxy-node attachment router for a single-homed prefix. 523 3. The LSR is an area border router (ABR) AND the MRT LDP peer 524 requires non-best-area advertising and forwarding behavior for 525 the prefix associated with the FEC. 527 Note that condition(3) scopes an LSR's status as an egress LSR with 528 respect to a particular FEC to a particular MRT LDP peer. Therefore, 529 the condition "Is LSR egress for FEC?" that occurs in several 530 procedures in [RFC5036] needs to be interpreted as "Is LSR egress for 531 FEC with respect to Peer?" 533 Also note that there is no explicit condition that allows an LSR to 534 be classified as an egress LSR with respect a red or blue FEC based 535 only on the primary next-hop for the shortest path FEC not supporting 536 LDP, or not supporting LDP MRT capability. These situations are 537 covered by the proxy-node attachment router and ABR conditions 538 (conditions 2 and 3). In particular, an Island Border Router is not 539 the egress LSR for a red(blue) FEC unless it is also the red(blue) 540 proxy-node attachment router for that FEC. 542 Also note that in general a proxy-node attachment router for a given 543 prefix should not advertise an implicit or explicit null label for 544 the corresponding red or blue FEC, even though it may be an egress 545 LSR for the shortest path FEC. In general, the proxy-node attachment 546 router needs to forward red or blue traffic for that prefix to a 547 particular loop free island neighbor, which may be different from the 548 shortest path next-hop. The proxy-node attachment router needs to 549 receive the red or blue traffic with a non-null label to correctly 550 forward it. 552 5.2.4. Use of Rainbow FEC to satisfy label mapping existence 553 requirements in RFC5036 555 Several procedures in [RFC5036] require the LSR to determine if it 556 has previously received and retained a label mapping for a FEC from 557 the next hop. In the case of an LSR that has received and retained a 558 label mapping for a Rainbow FEC from an ABR, the label mapping for 559 the Rainbow FEC satisfies the label mapping existence requirement for 560 the corresponding red and blue FECs. Label mapping existence 561 requirements in the context of MRT LDP label distribution are 562 modified as: "Has LSR previously received and retained a label 563 mapping for the red(blue) FEC (or the corresponding Rainbow FEC) from 564 the red(blue) next hop?" 566 As an example, this behavior allows an LSR which has received and 567 retained a label mapping for the Rainbow FEC to advertise label 568 mappings for the corresponding red and blue FECs when operating in 569 Ordered Control label distribution mode. 571 5.2.5. Validating FECs in routing table 573 In [RFC5036] an LSR uses its routing table to validate prefixes 574 associated with shortest path FECs. For example, section 3.5.7.1 of 575 [RFC5036] specifies that "an LSR receiving a Label Mapping message 576 from a downstream LSR for a Prefix SHOULD NOT use the label for 577 forwarding unless its routing table contains an entry that exactly 578 matches the FEC Element." In the context of MRT FECs, a red or blue 579 FEC element matches a routing table entry if the corresponding 580 shortest path FEC element matches a routing table entry. 582 5.2.6. Recognizing new FECs 584 Section A.1.6 of [RFC5036] describes the response of an LSR to the 585 "Recognize New FEC" event, which occurs when an LSR learns a new 586 (shortest path) FEC via the routing table. In the context of MRT 587 FECs, when MRT LDP capability has been enabled, when an LSR learns a 588 new shortest path FEC, it should generate "Recognize New FEC" events 589 for the corresponding red and blue FECs, in addition to the 590 "Recognize New FEC" event for the shortest path FEC. 592 5.2.7. Not propagating Rainbow FEC label mappings 594 A label mapping for the Rainbow FEC should only be originated by an 595 ABR under the conditions described in Section 5.1.1. A neighbor of 596 the ABR that receives a label mapping for the Rainbow FEC MUST NOT 597 propagate a label mapping for that Rainbow FEC. 599 6. Security Considerations 601 The labels distributed by the extensions in this document create 602 additional forwarding paths that do not follow shortest path routes. 603 The transit label swapping operations defining these alternative 604 forwarding paths are created during normal operations (before a 605 failure occurs). Therefore, a malicious packet with an appropriate 606 label injected into the network from a compromised location would be 607 forwarded to a destination along a non-shortest path. When this 608 technology is deployed, a network security design should not rely on 609 assumptions about potentially malicious traffic only following 610 shortest paths. 612 It should be noted that the creation of non-shortest forwarding paths 613 is not unique to MRT. For example, RSVP-TE [RFC3209] can be used to 614 construct forwarding paths that do not follow the shortest path. 616 7. Potential restrictions on MRT-related MT-ID values imposed by 617 RFC6420 619 As discussed in the introduction, in addition to unicast forwarding 620 applications, MRT can be used to provide disjoint trees for multicast 621 traffic distribution. In the case of PIM, this is accomplished by 622 using the MRT red and blue next-hops as the PIM RPF topology, the 623 collection of routes used by PIM to perform the RPF operation when 624 building source trees. The PIM Multi-Topology ID (MT-ID) Join 625 Attribute defined in section 5.2 of [RFC6420] can be used to 626 establish MRT-based multicast distribution trees. [RFC6420] limits 627 the values of the PIM MT-ID from 1 through 4095. 629 For the purpose of reducing management overhead and simplifying 630 troubleshooting, it is desirable to be able to use the same numerical 631 value for the PIM MT-ID as for the MPLS MT-ID, for multicast and 632 unicast application using MRT routes constructed using the same MRT 633 profile. In order to enable this simplification, the MPLS MT-ID 634 values assigned in this document need to fall in the range 1 through 635 4095. The IANA request below reflects this by requesting that the 636 MPLS MT-ID values from 3945 through 3995 be used for MRT-related MPLS 637 MT-ID values. This allows for 51 MRT-related MPLS MT-ID values which 638 can be directly mapped to PIM MT-ID values, which accommodates 25 MRT 639 profiles with red and blue MT-ID pairs, with one extra for the 640 rainbow MPLS MT-ID value. [RFC7307] designates the MPLS MT-ID range 641 6-3995 as "Unassigned(for future IGP topologies)". The IANA request 642 below changes the guidance for MT-ID range 3948-3995 to "Unassigned 643 (for future MRT-related values)". 645 8. IANA Considerations 647 IANA is requested to allocate a value for the new LDP Capability TLV 648 (the first free value in the range 0x0500 to 0x05FF) from the Label 649 Distribution Protocol (LDP) Parameters registry "TLV Type Name 650 Space": MRT Capability TLV (TBD-MRT-LDP-1). 652 Value Description Reference Notes / Reg. Date 653 ------------- ------------------ ------------ ----------------- 654 TBD-MRT-LDP-1 MRT Capability TLV [This draft] 656 IANA is requested to allocate a value for the new LDP Status Code 657 (the first free value in the range 0x00000032-0x00000036) from the 658 Label Distribution Protocol (LDP) Parameters registry "Status Code 659 Name Space": "MRT Capability negotiated without MT Capability" (TBD- 660 MRT-LDP-2). The Status Code E-bit is set to 0. 662 Value E Description Reference Notes / Reg. Date 663 -------------- - ------------------ ------------ ----------------- 664 TBD-MRT-LDP-2 0 MRT Capability [This draft] 665 negotiated without 666 MT Capability 668 IANA is requested to allocate three values from the MPLS Multi- 669 Topology Identifiers Registry [RFC7307]. 671 Rainbow MRT MPLS MT-ID (TBD-MRT-LDP-3) with suggested value: 3945 673 Default Profile MRT-Red MPLS MT-ID (TBD-MRT-LDP-4) with suggested 674 value: 3946 676 Default Profile MRT-Blue MPLS MT-ID (TBD-MRT-LDP-5) with suggested 677 value: 3947 679 IANA is also requested to change the purpose field of the MPLS Multi- 680 Topology Identifiers Registry for MT-ID range 3948-3995 to 681 "Unassigned (for future MRT-related values)", assuming the above 682 suggested values are assigned. The Registration procedure for the 683 entire registry remains "Standards Action". The entire registry 684 after implementing the above requests is shown below. 686 Value Purpose Reference 687 ------------- ---------------------- ------------ 688 0 Default/standard topology [RFC7307] 689 1 IPv4 in-band management [RFC7307] 690 2 IPv6 routing topology [RFC7307] 691 3 IPv4 multicast topology [RFC7307] 692 4 IPv6 multicast topology [RFC7307] 693 5 IPv6 in-band management [RFC7307] 694 6-3944 Unassigned (for future IGP topologies) 695 TBD-MRT-LDP-3 Rainbow MRT MPLS MT-ID [This draft] 696 TBD-MRT-LDP-4 Default Profile MRT-Red MPLS MT-ID [This draft] 697 TBD-MRT-LDP-5 Default Profile MRT-Blue MPLS MT-ID [This draft] 698 3948-3995 Unassigned (for future MRT-related values) 699 3996-4095 Reserved for Experimental Use [RFC7307] 700 4096-65534 Unassigned (for MPLS topologies) 701 65535 Wildcard Topology [RFC7307] 703 9. Acknowledgements 705 The authors would like to thank Ross Callon, Loa Andersson, Stewart 706 Bryant, Mach Chen, and Greg Mirsky for their suggestions. 708 10. References 710 10.1. Normative References 712 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 713 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 714 October 2007, . 716 [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. 717 Le Roux, "LDP Capabilities", RFC 5561, 718 DOI 10.17487/RFC5561, July 2009, 719 . 721 [RFC6420] Cai, Y. and H. Ou, "PIM Multi-Topology ID (MT-ID) Join 722 Attribute", RFC 6420, DOI 10.17487/RFC6420, November 2011, 723 . 725 [RFC7307] Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D. 726 King, "LDP Extensions for Multi-Topology", RFC 7307, 727 DOI 10.17487/RFC7307, July 2014, 728 . 730 [RFC7811] Enyedi, G., Csaszar, A., Atlas, A., Bowers, C., and A. 731 Gopalan, "An Algorithm for Computing IP/LDP Fast Reroute 732 Using Maximally Redundant Trees (MRT-FRR)", RFC 7811, 733 DOI 10.17487/RFC7811, June 2016, 734 . 736 [RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for 737 IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT- 738 FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016, 739 . 741 10.2. Informative References 743 [I-D.atlas-rtgwg-mrt-mc-arch] 744 Atlas, A., Kebler, R., Wijnands, I., Csaszar, A., and G. 745 Envedi, "An Architecture for Multicast Protection Using 746 Maximally Redundant Trees", draft-atlas-rtgwg-mrt-mc- 747 arch-02 (work in progress), July 2013. 749 [I-D.ietf-isis-mrt] 750 Li, Z., Wu, N., <>, Q., Atlas, A., Bowers, C., and J. 751 Tantsura, "Intermediate System to Intermediate System (IS- 752 IS) Extensions for Maximally Redundant Trees (MRT)", 753 draft-ietf-isis-mrt-02 (work in progress), May 2016. 755 [I-D.ietf-ospf-mrt] 756 Atlas, A., Hegde, S., Bowers, C., Tantsura, J., and Z. Li, 757 "OSPF Extensions to Support Maximally Redundant Trees", 758 draft-ietf-ospf-mrt-02 (work in progress), May 2016. 760 [I-D.wijnands-mpls-mldp-node-protection] 761 Wijnands, I., Rosen, E., Raza, K., Tantsura, J., Atlas, 762 A., and Q. Zhao, "mLDP Node Protection", draft-wijnands- 763 mpls-mldp-node-protection-04 (work in progress), June 764 2013. 766 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 767 Requirement Levels", BCP 14, RFC 2119, 768 DOI 10.17487/RFC2119, March 1997, 769 . 771 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 772 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 773 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 774 . 776 Authors' Addresses 778 Alia Atlas 779 Juniper Networks 780 10 Technology Park Drive 781 Westford, MA 01886 782 USA 784 Email: akatlas@juniper.net 786 Kishore Tiruveedhula 787 Juniper Networks 788 10 Technology Park Drive 789 Westford, MA 01886 790 USA 792 Email: kishoret@juniper.net 794 Chris Bowers 795 Juniper Networks 796 1194 N. Mathilda Ave. 797 Sunnyvale, CA 94089 798 USA 800 Email: cbowers@juniper.net 801 Jeff Tantsura 802 Individual 803 USA 805 Email: jefftant.ietf@gmail.com 807 IJsbrand Wijnands 808 Cisco Systems, Inc. 810 Email: ice@cisco.com