idnits 2.17.1 draft-ietf-mpls-ldp-mrt-03.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 (May 18, 2016) is 2899 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 (~~), 7 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: November 19, 2016 Juniper Networks 6 J. Tantsura 7 Individual 8 IJ. Wijnands 9 Cisco Systems, Inc. 10 May 18, 2016 12 LDP Extensions to Support Maximally Redundant Trees 13 draft-ietf-mpls-ldp-mrt-03 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 November 19, 2016. 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 [I-D.ietf-rtgwg-mrt-frr-architecture]. 104 It is necessary to be familiar with the architecture in 105 [I-D.ietf-rtgwg-mrt-frr-architecture] to understand how and why the 106 LDP extensions for behavior are needed. 108 At least one common standardized algorithm (e.g. the MRT Lowpoint 109 algorithm explained and fully documented in 110 [I-D.ietf-rtgwg-mrt-frr-algorithm]) is required so that the routers 111 supporting MRT computation consistently compute the same MRTs. LDP 112 depends on an IGP for computation of MRTs and alternates. Extensions 113 to OSPF are defined in [I-D.ietf-ospf-mrt]. Extension to IS-IS are 114 defined in [I-D.ietf-isis-mrt]. 116 MRT can also be used to protect multicast traffic (signalled via PIM 117 or mLDP) using either global protection or local protection 118 [I-D.atlas-rtgwg-mrt-mc-arch]. An MRT path can be used to provide 119 node-protection for mLDP traffic via the mechanisms described in 120 [I-D.wijnands-mpls-mldp-node-protection]; an MRT path can also be 121 used to provide link protection for mLDP traffic. 123 For each destination, IP/LDP Fast-Reroute with MRT (MRT-FRR) creates 124 two alternate destination-based trees separate from the shortest path 125 forwarding used during stable operation. LDP uses the multi-topology 126 extensions [RFC7307] to signal Forwarding Equivalency Classes (FECs) 127 for these two sets of forwarding trees, MRT-Blue and MRT-Red. 129 In order to create MRT paths and support IP/LDP Fast-Reroute, a new 130 capability extension is needed for LDP. An LDP implementation 131 supporting MRT MUST also follow the rules described here for 132 originating and managing FECs related to MRT, as indicated by their 133 multi-topology ID. Network reconvergence is described in 134 [I-D.ietf-rtgwg-mrt-frr-architecture] and the worst-case network 135 convergence time can be flooded via the extension in Section 7 of 136 [I-D.ietf-ospf-mrt]. 138 IP/LDP Fast-Reroute using MRTs can provide 100% coverage for link and 139 node failures in an arbitrary network topology where the failure 140 doesn't partition the network. It can also be deployed 141 incrementally; an MRT Island is formed of connected supporting 142 routers and the MRTs are computed inside that island. 144 2. Requirements Language 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in [RFC2119] 150 3. Terminology 152 For ease of reading, some of the terminology defined in 153 [I-D.ietf-rtgwg-mrt-frr-architecture] is repeated here. 155 Redundant Trees (RT): A pair of trees where the path from any node 156 X to the root R along the first tree is node-disjoint with the 157 path from the same node X to the root along the second tree. 158 These can be computed in 2-connected graphs. 160 Maximally Redundant Trees (MRT): A pair of trees where the path 161 from any node X to the root R along the first tree and the path 162 from the same node X to the root along the second tree share the 163 minimum number of nodes and the minimum number of links. Each 164 such shared node is a cut-vertex. Any shared links are cut-links. 165 Any RT is an MRT but many MRTs are not RTs. The two MRTs are 166 referred to as MRT-Blue and MRT-Red. 168 MRT-Red: MRT-Red is used to describe one of the two MRTs; it is 169 used to described the associated forwarding topology and MT-ID. 170 Specifically, MRT-Red is the decreasing MRT where links in the 171 GADAG are taken in the direction from a higher topologically 172 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 MT-ID. 176 Specifically, MRT-Blue is the increasing MRT where links in the 177 GADAG are taken in the direction from a lower topologically 178 ordered node to a higher one. 180 Rainbow MRT MT-ID: It is useful to have an MT-ID that refers to the 181 multiple MRT topologies and to the default topology. This is 182 referred to as the Rainbow MRT MT-ID and is used by LDP to reduce 183 signaling and permit the same label to always be advertised to all 184 peers for the same (MT-ID, Prefix). 186 MRT Island: From the computing router, the set of routers that 187 support a particular MRT profile and are connected via MRT- 188 eligible links. 190 Island Border Router (IBR): A router in the MRT Island that is 191 connected to a router not in the MRT Island and both routers are 192 in a common area or level. 194 Island Neighbor (IN): A router that is not in the MRT Island but is 195 adjacent to an IBR and in the same area/level as the IBR.. 197 4. Overview of LDP Signaling Extensions for MRT 199 Routers need to know which of their LDP neighbors support MRT. This 200 is communicated using the MRT Capability Advertisement. Supporting 201 MRT indicates several different aspects of behavior, as listed below. 203 1. Sending and receiving multi-topology FEC elements, as defined in 204 [RFC7307]. 206 2. Understanding the Rainbow MRT MT-ID and applying the associated 207 labels to all relevant MT-IDs. 209 3. Advertising the Rainbow MRT FEC to the appropriate neighbors for 210 the appropriate prefix. 212 4. If acting as LDP egress for a prefix in the default topology, 213 also acting as egress for the same prefix in MRT-Red and MRT- 214 Blue. 216 5. For a FEC learned from a neighbor that does not support MRT, 217 originating FECs for MRT-Red and MRT-Blue with the same prefix. 218 This MRT Island egress behavior is to support an MRT Island that 219 does not include all routers in the area/level. 221 4.1. MRT Capability Advertisement 223 A new MRT Capability Parameter TLV is defined in accordance with LDP 224 Capability definition guidelines[RFC5561]. 226 The LDP MRT capability can be advertised during LDP session 227 initialization or after the LDP session is established. 228 Advertisement of the MRT capability indicates support of the 229 procedures for establishing the MRT-Blue and MRT-Red LSP paths 230 detailed in this document. If the peer has not advertised the MRT 231 capability, then it indicates that LSR does not support MRT 232 procedures. 234 If a router advertises the LDP MRT capability to its peer, but the 235 peer has not advertised the MRT capability, then the router MUST NOT 236 advertise MRT-related FEC-label bindings to that peer. 238 The following is the format of the MRT Capability Parameter. 240 0 1 2 3 241 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 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 |U|F| MRT Capability (IANA) | Length (= 1) | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 |S| Reserved | 246 +-+-+-+-+-+-+-+-+ 248 MRT Capability TLV Format 250 Where: 252 U-bit: The unknown TLV bit MUST be 1. A router that does not 253 recognize the MRT Capability TLV will silently ignore the TLV and 254 process the rest of the message as if the unknown TLV did not 255 exist. 257 F-bit: The forward unknown TLV bit MUST be 0 as required by 258 Section 3 of [RFC5561]. 260 MRT Capability: TBD-MRT-LDP-1 (To Be Allocated by IANA) 262 Length: The length (in octets) of TLV. Its value is 1. 264 S-bit: The State bit MUST be 1 if used in LDP "Initialization" 265 message. MAY be set to 0 or 1 in dynamic "Capability" message to 266 advertise or withdraw the capability respectively, as described in 267 [RFC5561]. 269 4.1.1. Interaction of MRT Capability and MT Capability 271 An LSR advertising the LDP MRT Capability MUST also advertise the LDP 272 Multi-topology (MT) capability. If an LSR negotiates LDP MRT 273 Capability with an LDP neighbor without also negotiating the LDP MT 274 Capability, the LSR MUST behave as if LDP MRT Capability has not been 275 negotiated and respond with the "MRT Capability negotiated without MT 276 Capability" status code in the LDP Notification message (defined in 277 the document). The E-bit of this Notification should be set to 0 to 278 indicate that this is an Advisory Notification. The LDP session 279 SHOULD NOT be terminated. 281 4.1.2. Interaction of LDP MRT Capability with IPv4 and IPv6 283 The MRT LDP Capability Advertisement does not distinguish between 284 IPv4 and IPv6 address families. An LSR which advertises the MRT LDP 285 capability is expected to advertise MRT-related FEC-label bindings 286 for the same address families for which it advertises shortest-path 287 FEC-label bindings. Therefore, an LSR advertising MRT LDP capability 288 and shortest path FEC-label bindings for IPv4 only (or IPv6 only) 289 would be expected to advertise MRT-related FEC-label binding for IPv4 290 only (or IPv6 only). An LSR advertising the MRT LDP capability and 291 shortest-path FEC label bindings for BOTH IPv4 and IPv6 is expected 292 to advertise MRT-related FEC-label bindings for BOTH IPv4 and IPv6. 293 In this scenario, advertising MRT-related FEC-label bindings only for 294 IPv4 only (or only for IPv6) is not supported. 296 4.2. Use of the Rainbow MRT MT-ID 298 Section 10.1 of [I-D.ietf-rtgwg-mrt-frr-architecture] describes the 299 need for an area border router (ABR) to have different neighbors use 300 different MPLS labels when sending traffic to the ABR for the same 301 FEC. More detailed discussion of the Rainbow MRT MT-ID is provided 302 in Section 5.1.1. 304 Another use for the Rainbow MRT MT-ID is for an LSR to send the 305 Rainbow MRT MT-ID with an IMPLICIT_NULL label to indicate 306 penultimate-hop-popping for all three types of FECs (shortest path, 307 red, and blue). The EXPLICIT_NULL label advertised using the Rainbow 308 MRT MT-ID similarly applies to all the types of FECs. Note that the 309 only scenario in which it is generally useful to advertise the 310 implicit or explicit null label for all three FEC types is when the 311 FEC refers to the LSR itself. See Section 5.2.3 for more details. 313 The value of the Rainbow MRT MPLS MT-ID (TBD-MRT-LDP-3) will be 314 assigned by IANA from the MPLS MT-ID space. Prototype experiments 315 have used the value 3999. 317 4.3. MRT-Blue and MRT-Red FECs 319 To provide MRT support in LDP, the MT Prefix FEC is used. 320 [I-D.ietf-rtgwg-mrt-frr-architecture] defines the Default MRT 321 Profile. This document contains the IANA request for the MRT-Red and 322 MRT-Blue MPLS MT-IDs associated with the Default MRT Profile (TBD- 323 MRT-LDP-4 and TBD-MRT-LDP-5). 325 The MT Prefix FEC encoding is defined in [RFC7307] and is used 326 without alteration for advertising label mappings for MRT-Blue, MRT- 327 Red and Rainbow MRT FECs. 329 5. LDP MRT FEC Advertisements 331 This sections describes how and when labels for MRT-Red and MRT-Blue 332 FECs are advertised. The associated LSPs must be created before a 333 failure occurs, in order to provide protection paths which are 334 immediately usable by the point of local repair in the event of a 335 failure. 337 In this section, we will use the term "shortest path FEC" to refer to 338 the usual FEC associated with the shortest path destination-based 339 forwarding tree for a given prefix as determined by the IGP. We will 340 use the terms "red FEC" and "blue FEC" to refer to FECs associated 341 with the MRT-Red and MRT-Blue destination-based forwarding trees for 342 a given prefix as determined by a particular MRT algorithm. 344 We first describe label distribution behavior specific to MRT. Then 345 we provide the correct interpretation of several important concepts 346 in [RFC5036] in the context of MRT FEC label distribution. 348 5.1. MRT-specific behavior 350 5.1.1. ABR behavior and use of the Rainbow FEC 352 Section 10.1 of [I-D.ietf-rtgwg-mrt-frr-architecture] describes the 353 need for an area border router (ABR) to have different neighbors use 354 different MPLS labels when sending traffic to the ABR for the same 355 FEC. The method to accomplish this using the Rainbow MRT MT-ID is 356 described in detail in [I-D.ietf-rtgwg-mrt-frr-architecture]. Here 357 we provide a brief summary. To those LDP peers in the same area as 358 the best route to the destination, the ABR advertises two different 359 labels corresponding to the MRT-Red and MRT-Blue forwarding trees for 360 the destination. An LDP peer receiving these advertisements forwards 361 MRT traffic to the ABR using these two different labels, depending on 362 the FEC of the traffic. We refer to this as best-area advertising 363 and forwarding behavior, which is identical to normal MRT behavior. 365 For all other LDP peers supporting MRT, the ABR advertises a FEC- 366 label binding for the Rainbow MRT MT-ID scoped FEC with the label 367 corresponding to the default forwarding tree for the destination. An 368 LDP peer receiving this advertisement forwards MRT traffic to the ABR 369 using this label, for both MRT Red and MRT Blue traffic. We refer to 370 this as non-best-area advertising and forwarding behavior. 372 The use of the Rainbow-FEC by the ABR for non-best-area 373 advertisements is RECOMMENDED. An ABR MAY advertise the label for 374 the default topology in separate MRT-Blue and MRT-Red advertisements. 375 An LSR advertising the MRT capability MUST recognize the Rainbow MRT 376 MT-ID and associate the advertised label with the specific prefix 377 with the MRT-Red and MRT-Blue MT-IDs associated with all MRT Profiles 378 that advertise LDP as the forwarding mechanism. 380 Due to changes in topology or configuration, an ABR and a given LDP 381 peer may need to transition from best-area advertising and forwarding 382 behavior to non-best-area behavior for a given destination, and vice 383 versa. When the ABR requires best-area behavior for a red(blue) FEC, 384 it MUST withdraw any existing label mappings advertisements for the 385 corresponding rainbow FEC and advertise label mappings for the 386 red(blue) FEC. When the ABR requires non-best-area behavior for a 387 red(blue) FEC, it MUST withdraw any existing label mappings for both 388 red and blue FECs and advertise label mappings for the corresponding 389 Rainbow FEC label binding. 391 If an LSR receives a label mapping advertisement for a rainbow FEC 392 from an MRT LDP peer while it still retains a label mapping for the 393 corresponding red or blue FEC, the LSR MUST continue to use the label 394 mapping for the red or blue FEC, and it MUST send a Label Release 395 Message corresponding to the rainbow FEC label advertisement. If an 396 LSR receives a label mapping advertisement for red or blue FEC while 397 it still retains a label mapping for the corresponding rainbow FEC, 398 the LSR MUST continue to use the label mapping for the rainbow FEC, 399 and it MUST send a Label Release Message corresponding to the red or 400 blue FEC label advertisement. 402 5.1.2. Proxy-node attachment router behavior 404 Section 11.2 of [I-D.ietf-rtgwg-mrt-frr-architecture] describes how 405 MRT provides FRR protection for multi-homed prefixes using 406 calculations involving a named proxy-node. This covers the scenario 407 where a prefix is originated by a router in the same area as the MRT 408 Island, but outside of the MRT Island. It also covers the scenario 409 of a prefix being advertised by a multiple routers in the MRT Island. 411 In the named proxy-node calculation, each multi-homed prefix is 412 represented by a conceptual proxy-node which is attached to two real 413 proxy-node attachment routers. (A single proxy-node attachment 414 router is allowed in the case of a prefix advertised by a same area 415 router outside of the MRT Island which is singly connected to the MRT 416 Island.) All routers in the MRT Island perform the same calculations 417 to determine the same two proxy-node attachment routers for each 418 multi-homed prefix. [I-D.ietf-rtgwg-mrt-frr-algorithm] describes the 419 procedure for identifying one proxy-node attachment router as "red" 420 and one as "blue" with respect to the multi-homed prefix, and 421 computing the MRT red and blue next-hops to reach those red and blue 422 proxy-node attachment routers. 424 In terms of LDP behavior, a red proxy-node attachment router for a 425 given prefix MUST originate a label mapping for the red FEC for that 426 prefix, while the a blue proxy-node attachment router for a given 427 prefix MUST originate a label mapping for the blue FEC for that 428 prefix. If the red(blue) proxy-node attachment router is an Island 429 Border Router (IBR), then when it receives a packet with the label 430 corresponding to the red(blue) FEC for a prefix, it MUST forward the 431 packet to the Island Neighbor (IN) whose whose cost was used in the 432 selection of the IBR as a proxy-node attachment router. The IBR MUST 433 swap the incoming label for the outgoing label corresponding to the 434 shortest path FEC for the prefix advertised by the IN. In the case 435 where the IN does not support LDP, the IBR MUST pop the incoming 436 label and forward the packet to the IN. 438 If the proxy-node attachment router is not an IBR, then the packet 439 MUST be removed from the MRT forwarding topology and sent along the 440 interface(s) that caused the router to advertise the prefix. This 441 interface might be out of the area/level/AS. 443 5.2. LDP protocol procedures in the context of MRT label distribution 445 [RFC5036] specifies the LDP label distribution procedures for 446 shortest path FECs. In general, the same procedures can be applied 447 to the distribution of label mappings for red and blue FECs, provided 448 that the procedures are interpreted in the context of MRT FEC label 449 distribution. The correct interpretation of several important 450 concepts in [RFC5036] in the context of MRT FEC label distribution is 451 provided below. 453 5.2.1. LDP peer in RFC5036 455 In the context of distributing label mappings for red and blue FECs, 456 we restrict LDP peer in [RFC5036] to mean LDP peers for which the LDP 457 MRT capability has been negotiated. In order to make this 458 distinction clear, in this document we will use the term "MRT LDP 459 peer" to refer to an LDP peer for which the LDP MRT capability has 460 been negotiated. 462 5.2.2. Next hop in RFC5036 464 Several procedures in [RFC5036] use the next hop of a (shortest path) 465 FEC to determine behavior. The next hop of the shortest path FEC is 466 based on the shortest path forwarding tree to the prefix associated 467 with the FEC. When the procedures of [RFC5036] are used to 468 distribute label mapping for red and blue FECs, the next hop for the 469 red/blue FEC is based on the MRT-Red/Blue forwarding tree to the 470 prefix associated with the FEC. 472 For example, Appendix A.1.7. of [RFC5036] specifies the response by 473 an LSR to a change in the next hop for a FEC. For a shortest path 474 FEC, the next hop may change as the result of the LSR running a 475 shortest path computation on a modified IGP topology database. For 476 the red and blue FECs, the red and blue next hops may change as the 477 result of the LSR running a particular MRT algorithm on a modified 478 IGP topology database. 480 As another example, Section 2.6.1.2 of [RFC5036] specifies how that 481 when an LSR is using LSP Ordered Control, it may initiate the 482 transmission of a label mapping only for a (shortest path) FEC for 483 which it has a label mapping for the FEC next hop, or for which the 484 LSR is the egress. The FEC next hop for a shortest path FEC is based 485 on the shortest path forwarding tree to the prefix associated with 486 the FEC. In the context of distributing MRT LDP labels, this 487 procedure is understood to mean the following. When an LSR is using 488 LSP Ordered Control, it may initiate the transmission of a label 489 mapping only for a red(blue) FEC for which it has a label mapping for 490 the red(blue) FEC next hop, or for which the LSR is the egress. The 491 red or blue FEC next hop is based on the MRT-Red or Blue forwarding 492 tree to the prefix associated with the FEC. 494 5.2.3. Egress LSR in RFC5036 496 Procedures in [RFC5036] related to Ordered Control label distribution 497 mode rely on whether or not an LSR may act as an egress LSR for a 498 particular FEC in order to determine whether or not the LSR may 499 originate a label mapping for that FEC. The status of being an 500 egress LSR for a particular FEC is also used in loop detection 501 procedures in [RFC5036]. Section 2.6.1.2 of [RFC5036] specifies the 502 conditions under which an LSR may act as an egress LSR with respect 503 to a particular (shortest path) FEC. 505 1. The (shortest path) FEC refers to the LSR itself (including one 506 of its directly attached interfaces). 508 2. The next hop router for the (shortest path) FEC is outside of the 509 Label Switching Network. 511 3. (Shortest path) FEC elements are reachable by crossing a routing 512 domain boundary. 514 The conditions for determining an egress LSR with respect to a red or 515 blue FEC need to be modified. An LSR may act as an egress LSR with 516 respect to a particular red(blue) FEC under any of the following 517 conditions: 519 1. The prefix associated with the red(blue) FEC refers to the LSR 520 itself (including one of its directly attached interfaces). 522 2. The LSR is the red(blue) proxy-node attachment router with 523 respect to the multi-homed prefix associated with the red(blue) 524 FEC. This includes the degenerate case of a single red and blue 525 proxy-node attachment router for a single-homed prefix. 527 3. The LSR is an area border router (ABR) AND the MRT LDP peer 528 requires non-best-area advertising and forwarding behavior for 529 the prefix associated with the FEC. 531 Note that condition(3) scopes an LSR's status as an egress LSR with 532 respect to a particular FEC to a particular MRT LDP peer. Therefore, 533 the condition "Is LSR egress for FEC?" that occurs in several 534 procedures in [RFC5036] needs to be interpreted as "Is LSR egress for 535 FEC with respect to Peer?" 537 Also note that there is no explicit condition that allows an LSR to 538 be classified as an egress LSR with respect a red or blue FEC based 539 only on the primary next-hop for the shortest path FEC not supporting 540 LDP, or not supporting LDP MRT capability. These situations are 541 covered by the proxy-node attachment router and ABR conditions 542 (conditions 2 and 3). In particular, an Island Border Router is not 543 the egress LSR for a red(blue) FEC unless it is also the red(blue) 544 proxy-node attachment router for that FEC. 546 Also note that in general a proxy-node attachment router for a given 547 prefix should not advertise an implicit or explicit null label for 548 the corresponding red or blue FEC, even though it may be an egress 549 LSR for the shortest path FEC. In general, the proxy-node attachment 550 router needs to forward red or blue traffic for that prefix to a 551 particular loop free island neighbor, which may be different from the 552 shortest path next-hop. The proxy-node attachment router needs to 553 receive the red or blue traffic with a non-null label to correctly 554 forward it. 556 5.2.4. Use of Rainbow FEC to satisfy label mapping existence 557 requirements in RFC5036 559 Several procedures in [RFC5036] require the LSR to determine if it 560 has previously received and retained a label mapping for a FEC from 561 the next hop. In the case of an LSR that has received and retained a 562 label mapping for a Rainbow FEC from an ABR, the label mapping for 563 the Rainbow FEC satisfies the label mapping existence requirement for 564 the corresponding red and blue FECs. Label mapping existence 565 requirements in the context of MRT LDP label distribution are 566 modified as: "Has LSR previously received and retained a label 567 mapping for the red(blue) FEC (or the corresponding Rainbow FEC) from 568 the red(blue) next hop?" 570 As an example, this behavior allows an LSR which has received and 571 retained a label mapping for the Rainbow FEC to advertise label 572 mappings for the corresponding red and blue FECs when operating in 573 Ordered Control label distribution mode. 575 5.2.5. Validating FECs in routing table 577 In [RFC5036] an LSR uses its routing table to validate prefixes 578 associated with shortest path FECs. For example, section 3.5.7.1 of 579 [RFC5036] specifies that "an LSR receiving a Label Mapping message 580 from a downstream LSR for a Prefix SHOULD NOT use the label for 581 forwarding unless its routing table contains an entry that exactly 582 matches the FEC Element." In the context of MRT FECs, a red or blue 583 FEC element matches a routing table entry if the corresponding 584 shortest path FEC element matches a routing table entry. 586 5.2.6. Recognizing new FECs 588 Section A.1.6 of [RFC5036] describes the response of an LSR to the 589 "Recognize New FEC" event, which occurs when an LSR learns a new 590 (shortest path) FEC via the routing table. In the context of MRT 591 FECs, when MRT LDP capability has been enabled, when an LSR learns a 592 new shortest path FEC, it should generate "Recognize New FEC" events 593 for the corresponding red and blue FECs, in addition to the 594 "Recognize New FEC" event for the shortest path FEC. 596 5.2.7. Not propagating Rainbow FEC label mappings 598 A label mapping for the Rainbow FEC should only be originated by an 599 ABR under the conditions described in Section 5.1.1. A neighbor of 600 the ABR that receives a label mapping for the Rainbow FEC MUST NOT 601 propagate a label mapping for that Rainbow FEC. 603 6. Security Considerations 605 The labels distributed by the extensions in this document create 606 additional forwarding paths that do not following shortest path 607 routes. The transit label swapping operations defining these 608 alternative forwarding paths are created during normal operations 609 (before a failure occurs). Therefore, a malicious packet with an 610 appropriate label injected into the network from a compromised 611 location would be forwarded to a destination along a non-shortest 612 path. When this technology is deployed, a network security design 613 should not rely on assumptions about potentially malicious traffic 614 only following shortest paths. 616 It should be noted that the creation of non-shortest forwarding paths 617 is not unique to MRT. 619 7. Potential restrictions on MRT-related MT-ID values imposed by 620 RFC6420 622 As discussed in the introduction, in addition to unicast forwarding 623 applications, MRT can be used to provide disjoint trees for multicast 624 traffic distribution. In the case of PIM, this is accomplished by 625 using the MRT red and blue next-hops as the PIM RPF topology, the 626 collection of routes used by PIM to perform the RPF operation when 627 building source trees. The PIM Multi-Topology ID (MT-ID) Join 628 Attribute defined in section 5.2 of [RFC6420] can be used to 629 establish MRT-based multicast distribution trees. [RFC6420] limits 630 the values of the PIM MT-ID from 1 through 4095. 632 For the purpose of reducing management overhead and simplifying 633 troubleshooting, it is desirable to be able to use the same numerical 634 value for the PIM MT-ID as for the MPLS MT-ID, for multicast and 635 unicast application using MRT routes constructed using the same MRT 636 profile. In order to enable this simplification, the MPLS MT-ID 637 values assigned in this document need to fall in the range 1 through 638 4095. The IANA request below reflects this by requesting that the 639 MPLS MT-ID values from 3945 through 3995 be used for MRT-related MPLS 640 MT-ID values. This allows for 51 MRT-related MPLS MT-ID values which 641 can be directly mapped to PIM MT-ID values, which accommodates 25 MRT 642 profiles with red and blue MT-ID pairs, with one extra for the 643 rainbow MPLS MT-ID value. [RFC7307] designates the MPLS MT-ID range 644 6-3995 as "Unassigned(for future IGP topologies)". The IANA request 645 below changes the guidance for MT-ID range 3948-3995 to "Unassigned 646 (for future MRT-related values)". 648 8. IANA Considerations 650 IANA is requested to allocate a value for the new LDP Capability TLV 651 (the first free value in the range 0x0500 to 0x05FF) from the Label 652 Distribution Protocol (LDP) Parameters registry "TLV Type Name 653 Space": MRT Capability TLV (TBD-MRT-LDP-1). 655 Value Description Reference Notes / Reg. Date 656 ------------- ------------------ ------------ ----------------- 657 TBD-MRT-LDP-1 MRT Capability TLV [This draft] 659 IANA is requested to allocate a value for the new LDP Status Code 660 (the first free value in the range 0x00000032-0x00000036) from the 661 Label Distribution Protocol (LDP) Parameters registry "Status Code 662 Name Space": "MRT Capability negotiated without MT Capability" (TBD- 663 MRT-LDP-2). The Status Code E-bit is set to 0. 665 Value E Description Reference Notes / Reg. Date 666 -------------- - ------------------ ------------ ----------------- 667 TBD-MRT-LDP-2 0 MRT Capability [This draft] 668 negotiated without 669 MT Capability 671 IANA is requested to allocate three values from the MPLS Multi- 672 Topology Identifiers Registry [RFC7307]. 674 Rainbow MRT MPLS MT-ID (TBD-MRT-LDP-3) with suggested value: 3945 676 Default Profile MRT-Red MPLS MT-ID (TBD-MRT-LDP-4) with suggested 677 value: 3946 679 Default Profile MRT-Blue MPLS MT-ID (TBD-MRT-LDP-5) with suggested 680 value: 3947 682 IANA is also requested to change the purpose field of the MPLS Multi- 683 Topology Identifiers Registry for MT-ID range 3948-3995 to 684 "Unassigned (for future MRT-related values)", assuming the above 685 suggested values are assigned. The Registration procedure for the 686 entire registry remains "Standards Action". The entire registry 687 after implementing the above requests is shown below. 689 Value Purpose Reference 690 ------------- ---------------------- ------------ 691 0 Default/standard topology [RFC7307] 692 1 IPv4 in-band management [RFC7307] 693 2 IPv6 routing topology [RFC7307] 694 3 IPv4 multicast topology [RFC7307] 695 4 IPv6 multicast topology [RFC7307] 696 5 IPv6 in-band management [RFC7307] 697 6-3944 Unassigned (for future IGP topologies) 698 TBD-MRT-LDP-3 Rainbow MRT MPLS MT-ID [This draft] 699 TBD-MRT-LDP-4 Default Profile MRT-Red MPLS MT-ID [This draft] 700 TBD-MRT-LDP-5 Default Profile MRT-Blue MPLS MT-ID [This draft] 701 3948-3995 Unassigned (for future MRT-related values) 702 3996-4095 Reserved for Experimental Use [RFC7307] 703 4096-65534 Unassigned (for MPLS topologies) 704 65535 Wildcard Topology [RFC7307] 706 9. Acknowledgements 708 The authors would like to thank Ross Callon, Loa Andersson, Stewart 709 Bryant, Mach Chen, and Greg Mirsky for their suggestions. 711 10. References 713 10.1. Normative References 715 [I-D.ietf-rtgwg-mrt-frr-algorithm] 716 Envedi, G., Csaszar, A., Atlas, A., Bowers, C., and A. 717 Gopalan, "Algorithms for computing Maximally Redundant 718 Trees for IP/LDP Fast- Reroute", draft-ietf-rtgwg-mrt-frr- 719 algorithm-05 (work in progress), July 2015. 721 [I-D.ietf-rtgwg-mrt-frr-architecture] 722 Atlas, A., Kebler, R., Bowers, C., Envedi, G., Csaszar, 723 A., Tantsura, J., and R. White, "An Architecture for IP/ 724 LDP Fast-Reroute Using Maximally Redundant Trees", draft- 725 ietf-rtgwg-mrt-frr-architecture-05 (work in progress), 726 January 2015. 728 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 729 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 730 October 2007, . 732 [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. 733 Le Roux, "LDP Capabilities", RFC 5561, 734 DOI 10.17487/RFC5561, July 2009, 735 . 737 [RFC6420] Cai, Y. and H. Ou, "PIM Multi-Topology ID (MT-ID) Join 738 Attribute", RFC 6420, DOI 10.17487/RFC6420, November 2011, 739 . 741 [RFC7307] Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D. 742 King, "LDP Extensions for Multi-Topology", RFC 7307, 743 DOI 10.17487/RFC7307, July 2014, 744 . 746 10.2. Informative References 748 [I-D.atlas-rtgwg-mrt-mc-arch] 749 Atlas, A., Kebler, R., Wijnands, I., Csaszar, A., and G. 750 Envedi, "An Architecture for Multicast Protection Using 751 Maximally Redundant Trees", draft-atlas-rtgwg-mrt-mc- 752 arch-02 (work in progress), July 2013. 754 [I-D.ietf-isis-mrt] 755 Li, Z., Wu, N., Zhao, Q., Atlas, A., Bowers, C., and J. 756 Tantsura, "Intermediate System to Intermediate System (IS- 757 IS) Extensions for Maximally Redundant Trees (MRT)", 758 draft-ietf-isis-mrt-00 (work in progress), February 2015. 760 [I-D.ietf-ospf-mrt] 761 Atlas, A., Hegde, S., Bowers, C., Tantsura, J., and Z. Li, 762 "OSPF Extensions to Support Maximally Redundant Trees", 763 draft-ietf-ospf-mrt-00 (work in progress), January 2015. 765 [I-D.wijnands-mpls-mldp-node-protection] 766 Wijnands, I., Rosen, E., Raza, K., Tantsura, J., Atlas, 767 A., and Q. Zhao, "mLDP Node Protection", draft-wijnands- 768 mpls-mldp-node-protection-04 (work in progress), June 769 2013. 771 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 772 Requirement Levels", BCP 14, RFC 2119, 773 DOI 10.17487/RFC2119, March 1997, 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