idnits 2.17.1 draft-ietf-mpls-ldp-mrt-05.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 (February 17, 2017) is 2619 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: August 21, 2017 Juniper Networks 6 J. Tantsura 7 Individual 8 IJ. Wijnands 9 Cisco Systems, Inc. 10 February 17, 2017 12 LDP Extensions to Support Maximally Redundant Trees 13 draft-ietf-mpls-ldp-mrt-05 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 (Label Switching Routers) and 25 LERs (Label Edge Routers) advertising the MRT 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 August 21, 2017. 48 Copyright Notice 50 Copyright (c) 2017 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 to 109 be deployed so that the routers supporting MRT computation 110 consistently compute the same MRTs. LDP depends on an IGP for 111 computation of MRTs and alternates. Extensions to OSPF are defined 112 in [I-D.ietf-ospf-mrt]. Extension to IS-IS are defined in 113 [I-D.ietf-isis-mrt]. 115 MRT can also be used to protect multicast traffic (signalled via PIM 116 or mLDP) using either global protection or local protection as 117 described in [I-D.atlas-rtgwg-mrt-mc-arch]. An MRT path can be used 118 to provide node-protection for mLDP traffic via the mechanisms 119 described in [I-D.wijnands-mpls-mldp-node-protection]; an MRT path 120 can also be used to provide link protection for mLDP traffic. 122 For each destination, IP/LDP Fast-Reroute with MRT (MRT-FRR) creates 123 two alternate destination-based trees separate from the shortest path 124 forwarding used during stable operation. LDP uses the multi-topology 125 extensions [RFC7307] to signal Forwarding Equivalency Classes (FECs) 126 for these two sets of forwarding trees, MRT-Blue and MRT-Red. 128 In order to create MRT paths and support IP/LDP Fast-Reroute, a new 129 capability extension is needed for LDP. An LDP implementation 130 supporting MRT MUST also follow the rules described here for 131 originating and managing FECs related to MRT, as indicated by their 132 multi-topology ID. Network reconvergence is described in [RFC7812] 133 and the worst-case network convergence time can be flooded via the 134 extension in Section 7 of [I-D.ietf-ospf-mrt]. 136 IP/LDP Fast-Reroute using MRTs can provide 100% coverage for link and 137 node failures in an arbitrary network topology where the failure 138 doesn't partition the network. It can also be deployed 139 incrementally; an MRT Island is formed of connected supporting 140 routers and the MRTs are computed inside that island. 142 2. Requirements Language 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in [RFC2119] 148 3. Terminology 150 For ease of reading, some of the terminology defined in [RFC7812] is 151 repeated here. 153 Redundant Trees (RT): A pair of trees where the path from any node 154 X to the root R along the first tree is node-disjoint with the 155 path from the same node X to the root along the second tree. 156 Redundant trees can always be computed in 2-connected graphs. 158 Maximally Redundant Trees (MRT): A pair of trees where the path 159 from any node X to the root R along the first tree and the path 160 from the same node X to the root along the second tree share the 161 minimum number of nodes and the minimum number of links. Each 162 such shared node is a cut-vertex. Any shared links are cut-links. 163 In graphs that are not 2-connected, it is not possible to compute 164 RTs. However, it is possible to compute MRTs. MRTs are maximally 165 redundant in the sense that they are as redundant as possible 166 given the constraints of the network graph. 168 MRT-Red: MRT-Red is used to describe one of the two MRTs; it is 169 used to describe the associated forwarding topology and MPLS 170 Multi-Topology IDentifier (MT-ID). Specifically, MRT-Red is the 171 decreasing MRT where links in the GADAG are taken in the direction 172 from a higher topologically ordered node to a lower one. 174 MRT-Blue: MRT-Blue is used to describe one of the two MRTs; it is 175 used to described the associated forwarding topology and MPLS MT- 176 ID. Specifically, MRT-Blue is the increasing MRT where links in 177 the GADAG are taken in the direction from a lower topologically 178 ordered node to a higher one. 180 Rainbow MRT: It is useful to have an MPLS MT-ID that refers to the 181 multiple MRT forwarding topologies and to the default forwarding 182 topology. This is referred to as the Rainbow MRT MPLS MT-ID and 183 is used by LDP to reduce signaling and permit the same label to 184 always be advertised to all peers for the same (MT-ID, Prefix). 186 MRT Island: The set of routers that support a particular MRT 187 profile and the links connecting them that support MRT. 189 Island Border Router (IBR): A router that is not in the MRT Island 190 but is adjacent to an IBR and in the same area/level as the IBR. 192 Island Neighbor (IN): A router that is not in the MRT Island but is 193 adjacent to an IBR and in the same area/level as the IBR.. 195 4. Overview of LDP Signaling Extensions for MRT 197 Routers need to know which of their LDP neighbors support MRT. This 198 is communicated using the MRT Capability Advertisement. Supporting 199 MRT indicates several different aspects of behavior, as listed below. 201 1. Sending and receiving multi-topology FEC elements, as defined in 202 [RFC7307]. 204 2. Understanding the Rainbow MRT MT-ID and applying the associated 205 labels to all relevant MT-IDs. 207 3. Advertising the Rainbow MRT FEC to the appropriate neighbors for 208 the appropriate prefix. 210 4. If acting as LDP egress for a prefix in the default topology, 211 also acting as egress for the same prefix in MRT-Red and MRT- 212 Blue. 214 5. For a FEC learned from a neighbor that does not support MRT, 215 originating FECs for MRT-Red and MRT-Blue with the same prefix. 216 This MRT Island egress behavior is to support an MRT Island that 217 does not include all routers in the area/level. 219 4.1. MRT Capability Advertisement 221 A new MRT Capability Parameter TLV is defined in accordance with LDP 222 Capability definition guidelines[RFC5561]. 224 The LDP MRT capability can be advertised during LDP session 225 initialization or after the LDP session is established. 226 Advertisement of the MRT capability indicates support of the 227 procedures for establishing the MRT-Blue and MRT-Red LSP paths 228 detailed in this document. If the peer has not advertised the MRT 229 capability, then it indicates that LSR does not support MRT 230 procedures. 232 If a router advertises the LDP MRT capability to its peer, but the 233 peer has not advertised the MRT capability, then the router MUST NOT 234 advertise MRT-related FEC-label bindings to that peer. 236 The following is the format of the MRT Capability Parameter. 238 0 1 2 3 239 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 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 |U|F| MRT Capability (IANA) | Length (= 1) | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 |S| Reserved | 244 +-+-+-+-+-+-+-+-+ 246 MRT Capability TLV Format 248 Where: 250 U-bit: The unknown TLV bit MUST be 1. A router that does not 251 recognize the MRT Capability TLV will silently ignore the TLV and 252 process the rest of the message as if the unknown TLV did not 253 exist. 255 F-bit: The forward unknown TLV bit MUST be 0 as required by 256 Section 3 of [RFC5561]. 258 MRT Capability: TBD-MRT-LDP-1 (To Be Allocated by IANA) 260 Length: The length (in octets) of TLV. Its value is 1. 262 S-bit: The State bit MUST be 1 if used in LDP "Initialization" 263 message. MAY be set to 0 or 1 in dynamic "Capability" message to 264 advertise or withdraw the capability respectively, as described in 265 [RFC5561]. 267 4.1.1. Interaction of MRT Capability and MT Capability 269 An LSR advertising the LDP MRT Capability MUST also advertise the LDP 270 Multi-topology (MT) capability. If an LSR negotiates LDP MRT 271 Capability with an LDP neighbor without also negotiating the LDP MT 272 Capability, the LSR MUST behave as if LDP MRT Capability has not been 273 negotiated and respond with the "MRT Capability negotiated without MT 274 Capability" status code in the LDP Notification message (defined in 275 the document). The E-bit of this Notification should be set to 0 to 276 indicate that this is an Advisory Notification. The LDP session 277 SHOULD NOT be terminated. 279 4.1.2. Interaction of LDP MRT Capability with IPv4 and IPv6 281 The MRT LDP Capability Advertisement does not distinguish between 282 IPv4 and IPv6 address families. An LSR which advertises the MRT LDP 283 capability is expected to advertise MRT-related FEC-label bindings 284 for the same address families for which it advertises shortest-path 285 FEC-label bindings. Therefore, an LSR advertising MRT LDP capability 286 and shortest path FEC-label bindings for IPv4 only (or IPv6 only) 287 would be expected to advertise MRT-related FEC-label binding for IPv4 288 only (or IPv6 only). An LSR advertising the MRT LDP capability and 289 shortest-path FEC label bindings for BOTH IPv4 and IPv6 is expected 290 to advertise MRT-related FEC-label bindings for BOTH IPv4 and IPv6. 291 In this scenario, advertising MRT-related FEC-label bindings only for 292 IPv4 only (or only for IPv6) is not supported. 294 4.2. Use of the Rainbow MRT MT-ID 296 Section 10.1 of [RFC7812] describes the need for an area border 297 router (ABR) to have different neighbors use different MPLS labels 298 when sending traffic to the ABR for the same FEC. More detailed 299 discussion of the Rainbow MRT MT-ID is provided in Section 5.1.1 of 300 the current document. 302 Another use for the Rainbow MRT MT-ID is for an LSR to send the 303 Rainbow MRT MT-ID with an IMPLICIT_NULL label to indicate 304 penultimate-hop-popping for all three types of FECs (shortest path, 305 red, and blue). The EXPLICIT_NULL label advertised using the Rainbow 306 MRT MT-ID similarly applies to all the types of FECs. Note that the 307 only scenario in which it is generally useful to advertise the 308 implicit or explicit null label for all three FEC types is when the 309 FEC refers to the LSR itself. See Section 5.2.3 for more details. 311 The value of the Rainbow MRT MPLS MT-ID (TBD-MRT-LDP-3) will be 312 assigned by IANA from the MPLS MT-ID space. 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. Section 8 of this document 318 specifies code points for the MRT-Red and MRT-Blue MPLS MT-IDs 319 associated with the Default MRT Profile (TBD-MRT-LDP-4 and TBD-MRT- 320 LDP-5). 322 The MT Prefix FEC encoding is defined in [RFC7307] and is used 323 without alteration for advertising label mappings for MRT-Blue, MRT- 324 Red and Rainbow MRT FECs. 326 5. LDP MRT FEC Advertisements 328 This sections describes how and when labels for MRT-Red and MRT-Blue 329 FECs are advertised. The associated LSPs must be created before a 330 failure occurs, in order to provide protection paths which are 331 immediately usable by the point of local repair in the event of a 332 failure. 334 In this section, we will use the term "shortest path FEC" to refer to 335 the usual FEC associated with the shortest path destination-based 336 forwarding tree for a given prefix as determined by the IGP. We will 337 use the terms "red FEC" and "blue FEC" to refer to FECs associated 338 with the MRT-Red and MRT-Blue destination-based forwarding trees for 339 a given prefix as determined by a particular MRT algorithm. 341 We first describe label distribution behavior specific to MRT. Then 342 we provide the correct interpretation of several important concepts 343 in [RFC5036] in the context of MRT FEC label distribution. 345 5.1. MRT-specific behavior 347 5.1.1. ABR behavior and use of the Rainbow FEC 349 Section 10.1 of [RFC7812] describes the need for an area border 350 router (ABR) to have different neighbors use different MPLS labels 351 when sending traffic to the ABR for the same FEC. The method to 352 accomplish this using the Rainbow MRT MT-ID is described in detail in 353 [RFC7812]. Here we provide a brief summary. To those LDP peers in 354 the same area as the best route to the destination, the ABR 355 advertises two different labels corresponding to the MRT-Red and MRT- 356 Blue forwarding trees for the destination. An LDP peer receiving 357 these advertisements forwards MRT traffic to the ABR using these two 358 different labels, depending on the FEC of the traffic. We refer to 359 this as best-area advertising and forwarding behavior, which is 360 identical to normal MRT behavior. 362 For all other LDP peers supporting MRT, the ABR advertises a FEC- 363 label binding for the Rainbow MRT MT-ID scoped FEC with the label 364 corresponding to the default forwarding tree for the destination. An 365 LDP peer receiving this advertisement forwards MRT traffic to the ABR 366 using this label, for both MRT-Red and MRT-Blue traffic. We refer to 367 this as non-best-area advertising and forwarding behavior. 369 The use of the Rainbow-FEC by the ABR for non-best-area 370 advertisements is RECOMMENDED. An ABR MAY advertise the label for 371 the default topology in separate MRT-Blue and MRT-Red advertisements. 372 An LSR advertising the MRT capability MUST recognize the Rainbow MRT 373 MT-ID and associate the advertised label with the specific prefix 374 with the MRT-Red and MRT-Blue MT-IDs associated with all MRT Profiles 375 that advertise LDP as the forwarding mechanism. 377 Due to changes in topology or configuration, an ABR and a given LDP 378 peer may need to transition from best-area advertising and forwarding 379 behavior to non-best-area behavior for a given destination, and vice 380 versa. When the ABR requires best-area behavior for a red(blue) FEC, 381 it MUST withdraw any existing label mappings advertisements for the 382 corresponding rainbow FEC and advertise label mappings for the 383 red(blue) FEC. When the ABR requires non-best-area behavior for a 384 red(blue) FEC, it MUST withdraw any existing label mappings for both 385 red and blue FECs and advertise label mappings for the corresponding 386 Rainbow FEC label binding. 388 In this transition, an ABR should never advertise a red(blue) FEC 389 before withdrawing the corrsponding rainbow FEC (or vice versa). 390 However, should this situation occur, the expected behavior of an LSR 391 receiving these conflicting advertisements is defined as foll If an 392 LSR receives a label mapping advertisement for a rainbow FEC from an 393 MRT LDP peer while it still retains a label mapping for the 394 corresponding red or blue FEC, the LSR MUST continue to use the label 395 mapping for the red or blue FEC, and it MUST send a Label Release 396 Message corresponding to the rainbow FEC label advertisement. If an 397 LSR receives a label mapping advertisement for red or blue FEC while 398 it still retains a label mapping for the corresponding rainbow FEC, 399 the LSR MUST continue to use the label mapping for the rainbow FEC, 400 and it MUST send a Label Release Message corresponding to the red or 401 blue FEC label advertisement. 403 5.1.2. Proxy-node attachment router behavior 405 Section 11.2 of [RFC7812] describes how MRT provides FRR protection 406 for multi-homed prefixes using calculations involving a named proxy- 407 node. This covers the scenario where a prefix is originated by a 408 router in the same area as the MRT Island, but outside of the MRT 409 Island. It also covers the scenario of a prefix being advertised by 410 a multiple routers in the MRT Island. 412 In the named proxy-node calculation, each multi-homed prefix is 413 represented by a conceptual proxy-node which is attached to two real 414 proxy-node attachment routers. (A single proxy-node attachment 415 router is allowed in the case of a prefix advertised by a same area 416 router outside of the MRT Island which is singly connected to the MRT 417 Island.) All routers in the MRT Island perform the same calculations 418 to determine the same two proxy-node attachment routers for each 419 multi-homed prefix. [RFC7811] describes the procedure for 420 identifying one proxy-node attachment router as "red" and one as 421 "blue" with respect to the multi-homed prefix, and computing the MRT 422 red and blue next-hops to reach those red and blue proxy-node 423 attachment routers. 425 In terms of LDP behavior, a red proxy-node attachment router for a 426 given prefix MUST originate a label mapping for the red FEC for that 427 prefix, while the a blue proxy-node attachment router for a given 428 prefix MUST originate a label mapping for the blue FEC for that 429 prefix. If the red(blue) proxy-node attachment router is an Island 430 Border Router (IBR), then when it receives a packet with the label 431 corresponding to the red(blue) FEC for a prefix, it MUST forward the 432 packet to the Island Neighbor (IN) whose cost was used in the 433 selection of the IBR as a proxy-node attachment router. The IBR MUST 434 swap the incoming label for the outgoing label corresponding to the 435 shortest path FEC for the prefix advertised by the IN. In the case 436 where the IN does not support LDP, the IBR MUST pop the incoming 437 label and forward the packet to the IN. 439 If the proxy-node attachment router is not an IBR, then the packet 440 MUST be removed from the MRT forwarding topology and sent along the 441 interface(s) that caused the router to advertise the prefix. This 442 interface might be out of the area/level/AS. 444 5.2. LDP protocol procedures in the context of MRT label distribution 446 [RFC5036] specifies the LDP label distribution procedures for 447 shortest path FECs. In general, the same procedures can be applied 448 to the distribution of label mappings for red and blue FECs, provided 449 that the procedures are interpreted in the context of MRT FEC label 450 distribution. The correct interpretation of several important 451 concepts in [RFC5036] in the context of MRT FEC label distribution is 452 provided below. 454 5.2.1. LDP peer in RFC5036 456 In the context of distributing label mappings for red and blue FECs, 457 we restrict LDP peer in [RFC5036] to mean LDP peers for which the LDP 458 MRT capability has been negotiated. In order to make this 459 distinction clear, in this document we will use the term "MRT LDP 460 peer" to refer to an LDP peer for which the LDP MRT capability has 461 been negotiated. 463 5.2.2. Next hop in RFC5036 465 Several procedures in [RFC5036] use the next hop of a (shortest path) 466 FEC to determine behavior. The next hop of the shortest path FEC is 467 based on the shortest path forwarding tree to the prefix associated 468 with the FEC. When the procedures of [RFC5036] are used to 469 distribute label mapping for red and blue FECs, the next hop for the 470 red/blue FEC is based on the MRT-Red/Blue forwarding tree to the 471 prefix associated with the FEC. 473 For example, Appendix A.1.7. of [RFC5036] specifies the response by 474 an LSR to a change in the next hop for a FEC. For a shortest path 475 FEC, the next hop may change as the result of the LSR running a 476 shortest path computation on a modified IGP topology database. For 477 the red and blue FECs, the red and blue next hops may change as the 478 result of the LSR running a particular MRT algorithm on a modified 479 IGP topology database. 481 As another example, Section 2.6.1.2 of [RFC5036] specifies how that 482 when an LSR is using LSP Ordered Control, it may initiate the 483 transmission of a label mapping only for a (shortest path) FEC for 484 which it has a label mapping for the FEC next hop, or for which the 485 LSR is the egress. The FEC next hop for a shortest path FEC is based 486 on the shortest path forwarding tree to the prefix associated with 487 the FEC. In the context of distributing MRT LDP labels, this 488 procedure is understood to mean the following. When an LSR is using 489 LSP Ordered Control, it may initiate the transmission of a label 490 mapping only for a red(blue) FEC for which it has a label mapping for 491 the red(blue) FEC next hop, or for which the LSR is the egress. The 492 red or blue FEC next hop is based on the MRT-Red or Blue forwarding 493 tree to the prefix associated with the FEC. 495 5.2.3. Egress LSR in RFC5036 497 Procedures in [RFC5036] related to Ordered Control label distribution 498 mode rely on whether or not an LSR may act as an egress LSR for a 499 particular FEC in order to determine whether or not the LSR may 500 originate a label mapping for that FEC. The status of being an 501 egress LSR for a particular FEC is also used in loop detection 502 procedures in [RFC5036]. Section 2.6.1.2 of [RFC5036] specifies the 503 conditions under which an LSR may act as an egress LSR with respect 504 to a particular (shortest path) FEC. 506 1. The (shortest path) FEC refers to the LSR itself (including one 507 of its directly attached interfaces). 509 2. The next hop router for the (shortest path) FEC is outside of the 510 Label Switching Network. 512 3. (Shortest path) FEC elements are reachable by crossing a routing 513 domain boundary. 515 The conditions for determining an egress LSR with respect to a red or 516 blue FEC need to be modified. An LSR may act as an egress LSR with 517 respect to a particular red(blue) FEC under any of the following 518 conditions: 520 1. The prefix associated with the red(blue) FEC refers to the LSR 521 itself (including one of its directly attached interfaces). 523 2. The LSR is the red(blue) proxy-node attachment router with 524 respect to the multi-homed prefix associated with the red(blue) 525 FEC. This includes the degenerate case of a single red and blue 526 proxy-node attachment router for a single-homed prefix. 528 3. The LSR is an area border router (ABR) AND the MRT LDP peer 529 requires non-best-area advertising and forwarding behavior for 530 the prefix associated with the FEC. 532 Note that condition(3) scopes an LSR's status as an egress LSR with 533 respect to a particular FEC to a particular MRT LDP peer. Therefore, 534 the condition "Is LSR egress for FEC?" that occurs in several 535 procedures in [RFC5036] needs to be interpreted as "Is LSR egress for 536 FEC with respect to Peer?" 538 Also note that there is no explicit condition that allows an LSR to 539 be classified as an egress LSR with respect a red or blue FEC based 540 only on the primary next-hop for the shortest path FEC not supporting 541 LDP, or not supporting LDP MRT capability. These situations are 542 covered by the proxy-node attachment router and ABR conditions 543 (conditions 2 and 3). In particular, an Island Border Router is not 544 the egress LSR for a red(blue) FEC unless it is also the red(blue) 545 proxy-node attachment router for that FEC. 547 Also note that in general a proxy-node attachment router for a given 548 prefix should not advertise an implicit or explicit null label for 549 the corresponding red or blue FEC, even though it may be an egress 550 LSR for the shortest path FEC. In general, the proxy-node attachment 551 router needs to forward red or blue traffic for that prefix to a 552 particular loop free island neighbor, which may be different from the 553 shortest path next-hop. The proxy-node attachment router needs to 554 receive the red or blue traffic with a non-null label to correctly 555 forward it. 557 5.2.4. Use of Rainbow FEC to satisfy label mapping existence 558 requirements in RFC5036 560 Several procedures in [RFC5036] require the LSR to determine if it 561 has previously received and retained a label mapping for a FEC from 562 the next hop. In the case of an LSR that has received and retained a 563 label mapping for a Rainbow FEC from an ABR, the label mapping for 564 the Rainbow FEC satisfies the label mapping existence requirement for 565 the corresponding red and blue FECs. Label mapping existence 566 requirements in the context of MRT LDP label distribution are 567 modified as: "Has LSR previously received and retained a label 568 mapping for the red(blue) FEC (or the corresponding Rainbow FEC) from 569 the red(blue) next hop?" 571 As an example, this behavior allows an LSR which has received and 572 retained a label mapping for the Rainbow FEC to advertise label 573 mappings for the corresponding red and blue FECs when operating in 574 Ordered Control label distribution mode. 576 5.2.5. Validating FECs in routing table 578 In [RFC5036] an LSR uses its routing table to validate prefixes 579 associated with shortest path FECs. For example, section 3.5.7.1 of 580 [RFC5036] specifies that "an LSR receiving a Label Mapping message 581 from a downstream LSR for a Prefix SHOULD NOT use the label for 582 forwarding unless its routing table contains an entry that exactly 583 matches the FEC Element." In the context of MRT FECs, a red or blue 584 FEC element matches a routing table entry if the corresponding 585 shortest path FEC element matches a routing table entry. 587 5.2.6. Recognizing new FECs 589 Section A.1.6 of [RFC5036] describes the response of an LSR to the 590 "Recognize New FEC" event, which occurs when an LSR learns a new 591 (shortest path) FEC via the routing table. In the context of MRT 592 FECs, when MRT LDP capability has been enabled, when an LSR learns a 593 new shortest path FEC, it should generate "Recognize New FEC" events 594 for the corresponding red and blue FECs, in addition to the 595 "Recognize New FEC" event for the shortest path FEC. 597 5.2.7. Not propagating Rainbow FEC label mappings 599 A label mapping for the Rainbow FEC should only be originated by an 600 ABR under the conditions described in Section 5.1.1. A neighbor of 601 the ABR that receives a label mapping for the Rainbow FEC MUST NOT 602 propagate a label mapping for that Rainbow FEC. 604 6. Security Considerations 606 The labels distributed by the extensions in this document create 607 additional forwarding paths that do not follow shortest path routes. 608 The transit label swapping operations defining these alternative 609 forwarding paths are created during normal operations (before a 610 failure occurs). Therefore, a malicious packet with an appropriate 611 label injected into the network from a compromised location would be 612 forwarded to a destination along a non-shortest path. When this 613 technology is deployed, a network security design should not rely on 614 assumptions about potentially malicious traffic only following 615 shortest paths. 617 It should be noted that the creation of non-shortest forwarding paths 618 is not unique to MRT. For example, RSVP-TE [RFC3209] can be used to 619 construct forwarding paths that do not follow the shortest path. 621 7. Potential restrictions on MRT-related MT-ID values imposed by 622 RFC6420 624 As discussed in the introduction, in addition to unicast forwarding 625 applications, MRT can be used to provide disjoint trees for multicast 626 traffic distribution. In the case of PIM, this is accomplished by 627 using the MRT red and blue next-hops as the PIM RPF topology, the 628 collection of routes used by PIM to perform the RPF operation when 629 building source trees. The PIM Multi-Topology ID (MT-ID) Join 630 Attribute defined in section 5.2 of [RFC6420] can be used to 631 establish MRT-based multicast distribution trees. [RFC6420] limits 632 the values of the PIM MT-ID from 1 through 4095. 634 For the purpose of reducing management overhead and simplifying 635 troubleshooting, it is desirable to be able to use the same numerical 636 value for the PIM MT-ID as for the MPLS MT-ID, for multicast and 637 unicast application using MRT routes constructed using the same MRT 638 profile. In order to enable this simplification, the MPLS MT-ID 639 values assigned in this document need to fall in the range 1 through 640 4095. The IANA request below reflects this by requesting that the 641 MPLS MT-ID values from 3945 through 3995 be used for MRT-related MPLS 642 MT-ID values. This allows for 51 MRT-related MPLS MT-ID values which 643 can be directly mapped to PIM MT-ID values, which accommodates 25 MRT 644 profiles with red and blue MT-ID pairs, with one extra for the 645 rainbow MPLS MT-ID value. [RFC7307] designates the MPLS MT-ID range 646 6-3995 as "Unassigned(for future IGP topologies)". The IANA request 647 below changes the guidance for MT-ID range 3948-3995 to "Unassigned 648 (for future MRT-related values)". 650 8. IANA Considerations 652 IANA is requested to allocate a value for the new LDP Capability TLV 653 (the first free value in the range 0x0500 to 0x05FF) from the Label 654 Distribution Protocol (LDP) Parameters registry "TLV Type Name 655 Space": MRT Capability TLV (TBD-MRT-LDP-1). 657 Value Description Reference Notes / Reg. Date 658 ------------- ------------------ ------------ ----------------- 659 TBD-MRT-LDP-1 MRT Capability TLV [This draft] 661 IANA is requested to allocate a value for the new LDP Status Code 662 (the first free value in the range 0x00000032-0x00000036) from the 663 Label Distribution Protocol (LDP) Parameters registry "Status Code 664 Name Space": "MRT Capability negotiated without MT Capability" (TBD- 665 MRT-LDP-2). The Status Code E-bit is set to 0. 667 Value E Description Reference Notes / Reg. Date 668 -------------- - ------------------ ------------ ----------------- 669 TBD-MRT-LDP-2 0 MRT Capability [This draft] 670 negotiated without 671 MT Capability 673 IANA is requested to allocate three values from the MPLS Multi- 674 Topology Identifiers Registry [RFC7307]. 676 Rainbow MRT MPLS MT-ID (TBD-MRT-LDP-3) with suggested value: 3945 678 Default Profile MRT-Red MPLS MT-ID (TBD-MRT-LDP-4) with suggested 679 value: 3946 681 Default Profile MRT-Blue MPLS MT-ID (TBD-MRT-LDP-5) with suggested 682 value: 3947 684 IANA is also requested to change the purpose field of the MPLS Multi- 685 Topology Identifiers Registry for MT-ID range 3948-3995 to 686 "Unassigned (for future MRT-related values)", assuming the above 687 suggested values are assigned. The Registration procedure for the 688 entire registry remains "Standards Action". The entire registry 689 after implementing the above requests is shown below. 691 Value Purpose Reference 692 ------------- ---------------------- ------------ 693 0 Default/standard topology [RFC7307] 694 1 IPv4 in-band management [RFC7307] 695 2 IPv6 routing topology [RFC7307] 696 3 IPv4 multicast topology [RFC7307] 697 4 IPv6 multicast topology [RFC7307] 698 5 IPv6 in-band management [RFC7307] 699 6-3944 Unassigned (for future IGP topologies) 700 TBD-MRT-LDP-3 Rainbow MRT MPLS MT-ID [This draft] 701 TBD-MRT-LDP-4 Default Profile MRT-Red MPLS MT-ID [This draft] 702 TBD-MRT-LDP-5 Default Profile MRT-Blue MPLS MT-ID [This draft] 703 3948-3995 Unassigned (for future MRT-related values) [This draft] 704 3996-4095 Reserved for Experimental Use [RFC7307] 705 4096-65534 Unassigned (for MPLS topologies) 706 65535 Wildcard Topology [RFC7307] 708 9. Acknowledgements 710 The authors would like to thank Ross Callon, Loa Andersson, Stewart 711 Bryant, Mach Chen, Greg Mirsky, and Uma Chunduri for their comments 712 and suggestions. 714 10. References 716 10.1. Normative References 718 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 719 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 720 October 2007, . 722 [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. 723 Le Roux, "LDP Capabilities", RFC 5561, 724 DOI 10.17487/RFC5561, July 2009, 725 . 727 [RFC6420] Cai, Y. and H. Ou, "PIM Multi-Topology ID (MT-ID) Join 728 Attribute", RFC 6420, DOI 10.17487/RFC6420, November 2011, 729 . 731 [RFC7307] Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D. 732 King, "LDP Extensions for Multi-Topology", RFC 7307, 733 DOI 10.17487/RFC7307, July 2014, 734 . 736 [RFC7811] Enyedi, G., Csaszar, A., Atlas, A., Bowers, C., and A. 737 Gopalan, "An Algorithm for Computing IP/LDP Fast Reroute 738 Using Maximally Redundant Trees (MRT-FRR)", RFC 7811, 739 DOI 10.17487/RFC7811, June 2016, 740 . 742 [RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for 743 IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT- 744 FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016, 745 . 747 10.2. Informative References 749 [I-D.atlas-rtgwg-mrt-mc-arch] 750 Atlas, A., Kebler, R., Wijnands, I., Csaszar, A., and G. 751 Envedi, "An Architecture for Multicast Protection Using 752 Maximally Redundant Trees", draft-atlas-rtgwg-mrt-mc- 753 arch-02 (work in progress), July 2013. 755 [I-D.ietf-isis-mrt] 756 Li, Z., Wu, N., <>, Q., Atlas, A., Bowers, C., and J. 757 Tantsura, "Intermediate System to Intermediate System (IS- 758 IS) Extensions for Maximally Redundant Trees (MRT)", 759 draft-ietf-isis-mrt-02 (work in progress), May 2016. 761 [I-D.ietf-ospf-mrt] 762 Atlas, A., Hegde, S., Bowers, C., Tantsura, J., and Z. Li, 763 "OSPF Extensions to Support Maximally Redundant Trees", 764 draft-ietf-ospf-mrt-02 (work in progress), May 2016. 766 [I-D.wijnands-mpls-mldp-node-protection] 767 Wijnands, I., Rosen, E., Raza, K., Tantsura, J., Atlas, 768 A., and Q. Zhao, "mLDP Node Protection", draft-wijnands- 769 mpls-mldp-node-protection-04 (work in progress), June 770 2013. 772 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 773 Requirement Levels", BCP 14, RFC 2119, 774 DOI 10.17487/RFC2119, March 1997, 775 . 777 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 778 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 779 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 780 . 782 Authors' Addresses 784 Alia Atlas 785 Juniper Networks 786 10 Technology Park Drive 787 Westford, MA 01886 788 USA 790 Email: akatlas@juniper.net 792 Kishore Tiruveedhula 793 Juniper Networks 794 10 Technology Park Drive 795 Westford, MA 01886 796 USA 798 Email: kishoret@juniper.net 800 Chris Bowers 801 Juniper Networks 802 1194 N. Mathilda Ave. 803 Sunnyvale, CA 94089 804 USA 806 Email: cbowers@juniper.net 807 Jeff Tantsura 808 Individual 809 USA 811 Email: jefftant.ietf@gmail.com 813 IJsbrand Wijnands 814 Cisco Systems, Inc. 816 Email: ice@cisco.com