idnits 2.17.1 draft-ietf-mpls-ldp-mrt-06.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 91 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 (August 17, 2017) is 2444 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: February 18, 2018 Juniper Networks 6 J. Tantsura 7 Individual 8 IJ. Wijnands 9 Cisco Systems, Inc. 10 August 17, 2017 12 LDP Extensions to Support Maximally Redundant Trees 13 draft-ietf-mpls-ldp-mrt-06 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 February 18, 2018. 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 4.4. Interaction of MRT-related LDP advertisements with the 75 MRT topology and computations . . . . . . . . . . . . . . 8 76 5. LDP MRT FEC Advertisements . . . . . . . . . . . . . . . . . 8 77 5.1. MRT-specific behavior . . . . . . . . . . . . . . . . . . 9 78 5.1.1. ABR behavior and use of the Rainbow FEC . . . . . . . 9 79 5.1.2. Proxy-node attachment router behavior . . . . . . . . 10 80 5.2. LDP protocol procedures in the context of MRT label 81 distribution . . . . . . . . . . . . . . . . . . . . . . 11 82 5.2.1. LDP peer in RFC5036 . . . . . . . . . . . . . . . . . 11 83 5.2.2. Next hop in RFC5036 . . . . . . . . . . . . . . . . . 11 84 5.2.3. Egress LSR in RFC5036 . . . . . . . . . . . . . . . . 12 85 5.2.4. Use of Rainbow FEC to satisfy label mapping existence 86 requirements in RFC5036 . . . . . . . . . . . . . . . 13 87 5.2.5. Validating FECs in routing table . . . . . . . . . . 14 88 5.2.6. Recognizing new FECs . . . . . . . . . . . . . . . . 14 89 5.2.7. Not propagating Rainbow FEC label mappings . . . . . 14 90 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 91 7. Potential restrictions on MRT-related MT-ID values imposed 92 by RFC6420 . . . . . . . . . . . . . . . . . . . . . . . . . 15 93 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 94 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 95 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 96 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 97 10.2. Informative References . . . . . . . . . . . . . . . . . 17 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 100 1. Introduction 102 This document describes the LDP signaling extension and associated 103 behavior necessary to support the architecture that defines how IP/ 104 LDP Fast-Reroute can use MRTs [RFC7812]. It is necessary to be 105 familiar with the architecture in [RFC7812] to understand how and why 106 the 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 [RFC7811]) is required to 110 be deployed so that the routers supporting MRT computation 111 consistently compute the same MRTs. LDP depends on an IGP for 112 computation of MRTs and alternates. Extensions to OSPF are defined 113 in [I-D.ietf-ospf-mrt]. Extension to IS-IS are defined in 114 [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 as 118 described in [I-D.atlas-rtgwg-mrt-mc-arch]. An MRT path can be used 119 to provide node-protection for mLDP traffic via the mechanisms 120 described in [I-D.wijnands-mpls-mldp-node-protection]; an MRT path 121 can also be 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 [RFC7812] 134 and the worst-case network convergence time can be flooded via the 135 extension in Section 7 of [I-D.ietf-ospf-mrt]. 137 IP/LDP Fast-Reroute using MRTs can provide 100% coverage for link and 138 node failures in an arbitrary network topology where the failure 139 doesn't partition the network. It can also be deployed 140 incrementally; an MRT Island is formed of connected supporting 141 routers and the MRTs are computed inside that island. 143 2. Requirements Language 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in RFC 2119[RFC2119] 149 3. Terminology 151 For ease of reading, some of the terminology defined in [RFC7812] is 152 repeated here. Please refer to the Section 3 of [RFC7812] for a more 153 complete list. 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 Redundant trees can always 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 In graphs that are not 2-connected, it is not possible to compute 166 RTs. However, it is possible to compute MRTs. MRTs are maximally 167 redundant in the sense that they are as redundant as possible 168 given the constraints of the network graph. 170 MRT-Red: MRT-Red is used to describe one of the two MRTs; it is 171 used to describe the associated forwarding topology and MPLS 172 Multi-Topology IDentifier (MT-ID). 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. 178 Rainbow MRT: It is useful to have an MPLS MT-ID that refers to the 179 multiple MRT forwarding topologies and to the default forwarding 180 topology. This is referred to as the Rainbow MRT MPLS MT-ID and 181 is used by LDP to reduce signaling and permit the same label to 182 always be advertised to all peers for the same (MT-ID, Prefix). 184 MRT Island: The set of routers that support a particular MRT 185 profile and the links connecting them that support MRT. 187 Island Border Router (IBR): A router that is not in the MRT Island 188 but is adjacent to an IBR and in the same area/level as the IBR. 190 Island Neighbor (IN): A router that is not in the MRT Island but is 191 adjacent to an IBR and in the same area/level as the IBR.. 193 4. Overview of LDP Signaling Extensions for MRT 195 Routers need to know which of their LDP neighbors support MRT. This 196 is communicated using the MRT Capability Advertisement. Supporting 197 MRT indicates several different aspects of behavior, as listed below. 199 1. Sending and receiving multi-topology FEC elements, as defined in 200 [RFC7307]. 202 2. Understanding the Rainbow MRT MT-ID and applying the associated 203 labels to all relevant MT-IDs. 205 3. Advertising the Rainbow MRT FEC to the appropriate neighbors for 206 the appropriate prefix. 208 4. If acting as LDP egress for a prefix in the default topology, 209 also acting as egress for the same prefix in MRT-Red and MRT- 210 Blue. 212 5. For a FEC learned from a neighbor that does not support MRT, 213 originating FECs for MRT-Red and MRT-Blue with the same prefix. 214 This MRT Island egress behavior is to support an MRT Island that 215 does not include all routers in the area/level. 217 4.1. MRT Capability Advertisement 219 A new MRT Capability Parameter TLV is defined in accordance with LDP 220 Capability definition guidelines[RFC5561]. 222 The LDP MRT capability can be advertised during LDP session 223 initialization or after the LDP session is established. 224 Advertisement of the MRT capability indicates support of the 225 procedures for establishing the MRT-Blue and MRT-Red LSP paths 226 detailed in this document. If the peer has not advertised the MRT 227 capability, then it indicates that LSR does not support MRT 228 procedures. 230 If a router advertises the LDP MRT capability to its peer, but the 231 peer has not advertised the MRT capability, then the router MUST NOT 232 advertise MRT-related FEC-label bindings to that peer. 234 The following is the format of the MRT Capability Parameter. 236 0 1 2 3 237 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 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 |U|F| MRT Capability (IANA) | Length (= 1) | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 |S| Reserved | 242 +-+-+-+-+-+-+-+-+ 244 MRT Capability TLV Format 246 Where: 248 U-bit: The unknown TLV bit MUST be 1. A router that does not 249 recognize the MRT Capability TLV will silently ignore the TLV and 250 process the rest of the message as if the unknown TLV did not 251 exist. 253 F-bit: The forward unknown TLV bit MUST be 0 as required by 254 Section 3 of [RFC5561]. 256 MRT Capability: TBD-MRT-LDP-1 (To Be Allocated by IANA) 258 Length: The length (in octets) of TLV. Its value is 1. 260 S-bit: The State bit MUST be 1 if used in LDP "Initialization" 261 message. MAY be set to 0 or 1 in dynamic "Capability" message to 262 advertise or withdraw the capability respectively, as described in 263 [RFC5561]. 265 4.1.1. Interaction of MRT Capability and MT Capability 267 An LSR advertising the LDP MRT Capability MUST also advertise the LDP 268 Multi-topology (MT) capability. If an LSR negotiates LDP MRT 269 Capability with an LDP neighbor without also negotiating the LDP MT 270 Capability, the LSR MUST behave as if LDP MRT Capability has not been 271 negotiated and respond with the "MRT Capability negotiated without MT 272 Capability" status code in the LDP Notification message (defined in 273 the document). The E-bit of this Notification should be set to 0 to 274 indicate that this is an Advisory Notification. The LDP session 275 SHOULD NOT be terminated. 277 4.1.2. Interaction of LDP MRT Capability with IPv4 and IPv6 279 The MRT LDP Capability Advertisement does not distinguish between 280 IPv4 and IPv6 address families. An LSR which advertises the MRT LDP 281 capability is expected to advertise MRT-related FEC-label bindings 282 for the same address families for which it advertises shortest-path 283 FEC-label bindings. Therefore, an LSR advertising MRT LDP capability 284 and shortest path FEC-label bindings for IPv4 only (or IPv6 only) 285 would be expected to advertise MRT-related FEC-label binding for IPv4 286 only (or IPv6 only). An LSR advertising the MRT LDP capability and 287 shortest-path FEC label bindings for BOTH IPv4 and IPv6 is expected 288 to advertise MRT-related FEC-label bindings for BOTH IPv4 and IPv6. 289 In this scenario, advertising MRT-related FEC-label bindings only for 290 IPv4 only (or only for IPv6) is not supported. 292 4.2. Use of the Rainbow MRT MT-ID 294 Section 10.1 of [RFC7812] describes the need for an area border 295 router (ABR) to have different neighbors use different MPLS labels 296 when sending traffic to the ABR for the same FEC. More detailed 297 discussion of the Rainbow MRT MT-ID is provided in Section 5.1.1 of 298 the current document. 300 Another use for the Rainbow MRT MT-ID is for an LSR to send the 301 Rainbow MRT MT-ID with an IMPLICIT_NULL label to indicate 302 penultimate-hop-popping for all three types of FECs (shortest path, 303 red, and blue). The EXPLICIT_NULL label advertised using the Rainbow 304 MRT MT-ID similarly applies to all the types of FECs. Note that the 305 only scenario in which it is generally useful to advertise the 306 implicit or explicit null label for all three FEC types is when the 307 FEC refers to the LSR itself. See Section 5.2.3 for more details. 309 The value of the Rainbow MRT MPLS MT-ID (TBD-MRT-LDP-3) will be 310 assigned by IANA from the MPLS MT-ID space. 312 4.3. MRT-Blue and MRT-Red FECs 314 To provide MRT support in LDP, the MT Prefix FEC is used. [RFC7812] 315 defines the Default MRT Profile. Section 8 of the current document 316 specifies the values in the MPLS Multi-Topology Identifiers Registry 317 for the MRT-Red and MRT-Blue MPLS MT-IDs associated with the Default 318 MRT Profile (TBD-MRT-LDP-4 and TBD-MRT-LDP-5). 320 As described in Section 8.1 of [RFC7812], when a new MRT Profile is 321 defined, new and unique values should be allocated from the "MPLS 322 Multi-Topology Identifiers Registry", corresponding to the MRT-Red 323 and MRT-Blue MT-ID values for the new MRT Profile. 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 4.4. Interaction of MRT-related LDP advertisements with the MRT 330 topology and computations 332 [RFC7811] and [RFC7812] describe how the MRT topology is created 333 based on information in IGP advertisements. The MRT topology and 334 computations rely on on IGP advertisements. The presence or absence 335 of MRT-related LDP advertisements does not affect the MRT topology or 336 the MRT-Red and MRT-Blue next-hops computed for that topology. 338 As an example, consider a network where all nodes are running MRT IGP 339 extensions to determine the MRT-topology, which is then used to 340 compute MRT-Red and MRT-Blue next-hops. The network operator also 341 configures the nodes in this network to exchange MRT-related LDP 342 advertisements in order to distribute MPLS labels corresponding to 343 those MRT next-hops. Suppose that, due to a misconfiguration on one 344 particular link, the MRT-related LDP advertisements are not being 345 properly exchanged for that link. Since the MRT-related IGP 346 advertisements for the link are still being distributed, the link is 347 still included in the MRT topology and computations, In this 348 scenario, there will be missing MPLS forwarding entries corresponding 349 to paths that use the misconfigured link. 351 Note that the situation is analogous to the interaction of normal LDP 352 advertisements and IGP advertisements for shortest path forwarding. 353 Deactivating the distribution of labels for normal shortest path FECs 354 on a link does not change the topology on which the SPF algorithm is 355 run by the IGP. 357 5. LDP MRT FEC Advertisements 359 This sections describes how and when labels for MRT-Red and MRT-Blue 360 FECs are advertised. The associated LSPs must be created before a 361 failure occurs, in order to provide protection paths which are 362 immediately usable by the point of local repair in the event of a 363 failure. 365 In this section, we will use the term "shortest path FEC" to refer to 366 the usual FEC associated with the shortest path destination-based 367 forwarding tree for a given prefix as determined by the IGP. We will 368 use the terms "red FEC" and "blue FEC" to refer to FECs associated 369 with the MRT-Red and MRT-Blue destination-based forwarding trees for 370 a given prefix as determined by a particular MRT algorithm. 372 We first describe label distribution behavior specific to MRT. Then 373 we provide the correct interpretation of several important concepts 374 in [RFC5036] in the context of MRT FEC label distribution. 376 [RFC5036] specifies two different Label Distribution Control Modes 377 (Independent and Ordered), two different Label Retention Modes 378 (Conservative and Liberal), and two different Label Advertisement 379 Modes (Downstream Unsolicited and Downstream on Demand). The current 380 specification for LDP MRT requires that the same Label Distribution 381 Control, Label Retention, and Label Advertisement modes be used for 382 the shortest path FECs and the MRT FECs. 384 5.1. MRT-specific behavior 386 5.1.1. ABR behavior and use of the Rainbow FEC 388 Section 10.1 of [RFC7812] describes the need for an area border 389 router (ABR) to have different neighbors use different MPLS labels 390 when sending traffic to the ABR for the same FEC. The method to 391 accomplish this using the Rainbow MRT MT-ID is described in detail in 392 [RFC7812]. Here we provide a brief summary. To those LDP peers in 393 the same area as the best route to the destination, the ABR 394 advertises two different labels corresponding to the MRT-Red and MRT- 395 Blue forwarding trees for the destination. An LDP peer receiving 396 these advertisements forwards MRT traffic to the ABR using these two 397 different labels, depending on the FEC of the traffic. We refer to 398 this as best-area advertising and forwarding behavior, which is 399 identical to normal MRT behavior. 401 For all other LDP peers supporting MRT, the ABR advertises a FEC- 402 label binding for the Rainbow MRT MT-ID scoped FEC with the label 403 corresponding to the default forwarding tree for the destination. An 404 LDP peer receiving this advertisement forwards MRT traffic to the ABR 405 using this label, for both MRT-Red and MRT-Blue traffic. We refer to 406 this as non-best-area advertising and forwarding behavior. 408 The use of the Rainbow-FEC by the ABR for non-best-area 409 advertisements is RECOMMENDED. An ABR MAY advertise the label for 410 the default topology in separate MRT-Blue and MRT-Red advertisements. 411 An LSR advertising the MRT capability MUST recognize the Rainbow MRT 412 MT-ID and associate the advertised label with the specific prefix 413 with the MRT-Red and MRT-Blue MT-IDs associated with all MRT Profiles 414 that advertise LDP as the forwarding mechanism. 416 Due to changes in topology or configuration, an ABR and a given LDP 417 peer may need to transition from best-area advertising and forwarding 418 behavior to non-best-area behavior for a given destination, and vice 419 versa. When the ABR requires best-area behavior for a red(blue) FEC, 420 it MUST withdraw any existing label mappings advertisements for the 421 corresponding rainbow FEC and advertise label mappings for the 422 red(blue) FEC. When the ABR requires non-best-area behavior for a 423 red(blue) FEC, it MUST withdraw any existing label mappings for both 424 red and blue FECs and advertise label mappings for the corresponding 425 Rainbow FEC label binding. 427 In this transition, an ABR should never advertise a red(blue) FEC 428 before withdrawing the corresponding rainbow FEC (or vice versa). 429 However, should this situation occur, the expected behavior of an LSR 430 receiving these conflicting advertisements is defined as foll If an 431 LSR receives a label mapping advertisement for a rainbow FEC from an 432 MRT LDP peer while it still retains a label mapping for the 433 corresponding red or blue FEC, the LSR MUST continue to use the label 434 mapping for the red or blue FEC, and it MUST send a Label Release 435 Message corresponding to the rainbow FEC label advertisement. If an 436 LSR receives a label mapping advertisement for red or blue FEC while 437 it still retains a label mapping for the corresponding rainbow FEC, 438 the LSR MUST continue to use the label mapping for the rainbow FEC, 439 and it MUST send a Label Release Message corresponding to the red or 440 blue FEC label advertisement. 442 5.1.2. Proxy-node attachment router behavior 444 Section 11.2 of [RFC7812] describes how MRT provides FRR protection 445 for multi-homed prefixes using calculations involving a named proxy- 446 node. This covers the scenario where a prefix is originated by a 447 router in the same area as the MRT Island, but outside of the MRT 448 Island. It also covers the scenario of a prefix being advertised by 449 a multiple routers in the MRT Island. 451 In the named proxy-node calculation, each multi-homed prefix is 452 represented by a conceptual proxy-node which is attached to two real 453 proxy-node attachment routers. (A single proxy-node attachment 454 router is allowed in the case of a prefix advertised by a same area 455 router outside of the MRT Island which is singly connected to the MRT 456 Island.) All routers in the MRT Island perform the same calculations 457 to determine the same two proxy-node attachment routers for each 458 multi-homed prefix. Section 5.9 of [RFC7811] describes the procedure 459 for identifying one proxy-node attachment router as "red" and one as 460 "blue" with respect to the multi-homed prefix, and computing the MRT 461 red and blue next-hops to reach those red and blue proxy-node 462 attachment routers. 464 In terms of LDP behavior, a red proxy-node attachment router for a 465 given prefix MUST originate a label mapping for the red FEC for that 466 prefix, while the a blue proxy-node attachment router for a given 467 prefix MUST originate a label mapping for the blue FEC for that 468 prefix. If the red(blue) proxy-node attachment router is an Island 469 Border Router (IBR), then when it receives a packet with the label 470 corresponding to the red(blue) FEC for a prefix, it MUST forward the 471 packet to the Island Neighbor (IN) whose cost was used in the 472 selection of the IBR as a proxy-node attachment router. The IBR MUST 473 swap the incoming label for the outgoing label corresponding to the 474 shortest path FEC for the prefix advertised by the IN. In the case 475 where the IN does not support LDP, the IBR MUST pop the incoming 476 label and forward the packet to the IN. 478 If the proxy-node attachment router is not an IBR, then the packet 479 MUST be removed from the MRT forwarding topology and sent along the 480 interface(s) that caused the router to advertise the prefix. This 481 interface might be out of the area/level/AS. 483 5.2. LDP protocol procedures in the context of MRT label distribution 485 [RFC5036] specifies the LDP label distribution procedures for 486 shortest path FECs. In general, the same procedures can be applied 487 to the distribution of label mappings for red and blue FECs, provided 488 that the procedures are interpreted in the context of MRT FEC label 489 distribution. The correct interpretation of several important 490 concepts in [RFC5036] in the context of MRT FEC label distribution is 491 provided below. 493 5.2.1. LDP peer in RFC5036 495 In the context of distributing label mappings for red and blue FECs, 496 we restrict LDP peer in [RFC5036] to mean LDP peers for which the LDP 497 MRT capability has been negotiated. In order to make this 498 distinction clear, in this document we will use the term "MRT LDP 499 peer" to refer to an LDP peer for which the LDP MRT capability has 500 been negotiated. 502 5.2.2. Next hop in RFC5036 504 Several procedures in [RFC5036] use the next hop of a (shortest path) 505 FEC to determine behavior. The next hop of the shortest path FEC is 506 based on the shortest path forwarding tree to the prefix associated 507 with the FEC. When the procedures of [RFC5036] are used to 508 distribute label mapping for red and blue FECs, the next hop for the 509 red/blue FEC is based on the MRT-Red/Blue forwarding tree to the 510 prefix associated with the FEC. 512 For example, Appendix A.1.7. of [RFC5036] specifies the response by 513 an LSR to a change in the next hop for a FEC. For a shortest path 514 FEC, the next hop may change as the result of the LSR running a 515 shortest path computation on a modified IGP topology database. For 516 the red and blue FECs, the red and blue next hops may change as the 517 result of the LSR running a particular MRT algorithm on a modified 518 IGP topology database. 520 As another example, Section 2.6.1.2 of [RFC5036] specifies how that 521 when an LSR is using LSP Ordered Control, it may initiate the 522 transmission of a label mapping only for a (shortest path) FEC for 523 which it has a label mapping for the FEC next hop, or for which the 524 LSR is the egress. The FEC next hop for a shortest path FEC is based 525 on the shortest path forwarding tree to the prefix associated with 526 the FEC. In the context of distributing MRT LDP labels, this 527 procedure is understood to mean the following. When an LSR is using 528 LSP Ordered Control, it may initiate the transmission of a label 529 mapping only for a red(blue) FEC for which it has a label mapping for 530 the red(blue) FEC next hop, or for which the LSR is the egress. The 531 red or blue FEC next hop is based on the MRT-Red or Blue forwarding 532 tree to the prefix associated with the FEC. 534 5.2.3. Egress LSR in RFC5036 536 Procedures in [RFC5036] related to Ordered Control label distribution 537 mode rely on whether or not an LSR may act as an egress LSR for a 538 particular FEC in order to determine whether or not the LSR may 539 originate a label mapping for that FEC. The status of being an 540 egress LSR for a particular FEC is also used in loop detection 541 procedures in [RFC5036]. Section 2.6.1.2 of [RFC5036] specifies the 542 conditions under which an LSR may act as an egress LSR with respect 543 to a particular (shortest path) FEC. 545 1. The (shortest path) FEC refers to the LSR itself (including one 546 of its directly attached interfaces). 548 2. The next hop router for the (shortest path) FEC is outside of the 549 Label Switching Network. 551 3. (Shortest path) FEC elements are reachable by crossing a routing 552 domain boundary. 554 The conditions for determining an egress LSR with respect to a red or 555 blue FEC need to be modified. An LSR may act as an egress LSR with 556 respect to a particular red(blue) FEC under any of the following 557 conditions: 559 1. The prefix associated with the red(blue) FEC refers to the LSR 560 itself (including one of its directly attached interfaces). 562 2. The LSR is the red(blue) proxy-node attachment router with 563 respect to the multi-homed prefix associated with the red(blue) 564 FEC. This includes the degenerate case of a single red and blue 565 proxy-node attachment router for a single-homed prefix. 567 3. The LSR is an area border router (ABR) AND the MRT LDP peer 568 requires non-best-area advertising and forwarding behavior for 569 the prefix associated with the FEC. 571 Note that condition(3) scopes an LSR's status as an egress LSR with 572 respect to a particular FEC to a particular MRT LDP peer. Therefore, 573 the condition "Is LSR egress for FEC?" that occurs in several 574 procedures in [RFC5036] needs to be interpreted as "Is LSR egress for 575 FEC with respect to Peer?" 577 Also note that there is no explicit condition that allows an LSR to 578 be classified as an egress LSR with respect a red or blue FEC based 579 only on the primary next-hop for the shortest path FEC not supporting 580 LDP, or not supporting LDP MRT capability. These situations are 581 covered by the proxy-node attachment router and ABR conditions 582 (conditions 2 and 3). In particular, an Island Border Router is not 583 the egress LSR for a red(blue) FEC unless it is also the red(blue) 584 proxy-node attachment router for that FEC. 586 Also note that in general a proxy-node attachment router for a given 587 prefix should not advertise an implicit or explicit null label for 588 the corresponding red or blue FEC, even though it may be an egress 589 LSR for the shortest path FEC. In general, the proxy-node attachment 590 router needs to forward red or blue traffic for that prefix to a 591 particular loop free island neighbor, which may be different from the 592 shortest path next-hop. The proxy-node attachment router needs to 593 receive the red or blue traffic with a non-null label to correctly 594 forward it. 596 5.2.4. Use of Rainbow FEC to satisfy label mapping existence 597 requirements in RFC5036 599 Several procedures in [RFC5036] require the LSR to determine if it 600 has previously received and retained a label mapping for a FEC from 601 the next hop. In the case of an LSR that has received and retained a 602 label mapping for a Rainbow FEC from an ABR, the label mapping for 603 the Rainbow FEC satisfies the label mapping existence requirement for 604 the corresponding red and blue FECs. Label mapping existence 605 requirements in the context of MRT LDP label distribution are 606 modified as: "Has LSR previously received and retained a label 607 mapping for the red(blue) FEC (or the corresponding Rainbow FEC) from 608 the red(blue) next hop?" 610 As an example, this behavior allows an LSR which has received and 611 retained a label mapping for the Rainbow FEC to advertise label 612 mappings for the corresponding red and blue FECs when operating in 613 Ordered Control label distribution mode. 615 5.2.5. Validating FECs in routing table 617 In [RFC5036] an LSR uses its routing table to validate prefixes 618 associated with shortest path FECs. For example, section 3.5.7.1 of 619 [RFC5036] specifies that "an LSR receiving a Label Mapping message 620 from a downstream LSR for a Prefix SHOULD NOT use the label for 621 forwarding unless its routing table contains an entry that exactly 622 matches the FEC Element." In the context of MRT FECs, a red or blue 623 FEC element matches a routing table entry if the corresponding 624 shortest path FEC element matches a routing table entry. 626 5.2.6. Recognizing new FECs 628 Section A.1.6 of [RFC5036] describes the response of an LSR to the 629 "Recognize New FEC" event, which occurs when an LSR learns a new 630 (shortest path) FEC via the routing table. In the context of MRT 631 FECs, when MRT LDP capability has been enabled, when an LSR learns a 632 new shortest path FEC, it should generate "Recognize New FEC" events 633 for the corresponding red and blue FECs, in addition to the 634 "Recognize New FEC" event for the shortest path FEC. 636 5.2.7. Not propagating Rainbow FEC label mappings 638 A label mapping for the Rainbow FEC should only be originated by an 639 ABR under the conditions described in Section 5.1.1. A neighbor of 640 the ABR that receives a label mapping for the Rainbow FEC MUST NOT 641 propagate a label mapping for that Rainbow FEC. 643 6. Security Considerations 645 The labels distributed by the extensions in this document create 646 additional forwarding paths that do not follow shortest path routes. 647 The transit label swapping operations defining these alternative 648 forwarding paths are created during normal operations (before a 649 failure occurs). Therefore, a malicious packet with an appropriate 650 label injected into the network from a compromised location would be 651 forwarded to a destination along a non-shortest path. When this 652 technology is deployed, a network security design should not rely on 653 assumptions about potentially malicious traffic only following 654 shortest paths. 656 It should be noted that the creation of non-shortest forwarding paths 657 is not unique to MRT. For example, RSVP-TE [RFC3209] can be used to 658 construct forwarding paths that do not follow the shortest path. 660 7. Potential restrictions on MRT-related MT-ID values imposed by 661 RFC6420 663 As discussed in the introduction, in addition to unicast forwarding 664 applications, MRT can be used to provide disjoint trees for multicast 665 traffic distribution. In the case of PIM, this is accomplished by 666 using the MRT red and blue next-hops as the PIM RPF topology, the 667 collection of routes used by PIM to perform the RPF operation when 668 building source trees. The PIM Multi-Topology ID (MT-ID) Join 669 Attribute defined in section 5.2 of [RFC6420] can be used to 670 establish MRT-based multicast distribution trees. [RFC6420] limits 671 the values of the PIM MT-ID from 1 through 4095. 673 For the purpose of reducing management overhead and simplifying 674 troubleshooting, it is desirable to be able to use the same numerical 675 value for the PIM MT-ID as for the MPLS MT-ID, for multicast and 676 unicast application using MRT routes constructed using the same MRT 677 profile. In order to enable this simplification, the MPLS MT-ID 678 values assigned in this document need to fall in the range 1 through 679 4095. The IANA request below reflects this by requesting that the 680 MPLS MT-ID values from 3945 through 3995 be used for MRT-related MPLS 681 MT-ID values. This allows for 51 MRT-related MPLS MT-ID values which 682 can be directly mapped to PIM MT-ID values, which accommodates 25 MRT 683 profiles with red and blue MT-ID pairs, with one extra for the 684 rainbow MPLS MT-ID value. [RFC7307] designates the MPLS MT-ID range 685 6-3995 as "Unassigned(for future IGP topologies)". The IANA request 686 below changes the guidance for MT-ID range 3948-3995 to "Unassigned 687 (for future MRT-related values)". 689 8. IANA Considerations 691 IANA is requested to allocate a value for the new LDP Capability TLV 692 (the first free value in the range 0x0500 to 0x05FF) from the Label 693 Distribution Protocol (LDP) Parameters registry "TLV Type Name 694 Space": MRT Capability TLV (TBD-MRT-LDP-1). 696 Value Description Reference Notes / Reg. Date 697 ------------- ------------------ ------------ ----------------- 698 TBD-MRT-LDP-1 MRT Capability TLV [This draft] 700 IANA is requested to allocate a value for the new LDP Status Code 701 (the first free value in the range 0x00000032-0x00000036) from the 702 Label Distribution Protocol (LDP) Parameters registry "Status Code 703 Name Space": "MRT Capability negotiated without MT Capability" (TBD- 704 MRT-LDP-2). The Status Code E-bit is set to 0. 706 Value E Description Reference Notes / Reg. Date 707 -------------- - ------------------ ------------ ----------------- 708 TBD-MRT-LDP-2 0 MRT Capability [This draft] 709 negotiated without 710 MT Capability 712 IANA is requested to allocate three values from the MPLS Multi- 713 Topology Identifiers Registry [RFC7307]. 715 Rainbow MRT MPLS MT-ID (TBD-MRT-LDP-3) with suggested value: 3945 717 Default Profile MRT-Red MPLS MT-ID (TBD-MRT-LDP-4) with suggested 718 value: 3946 720 Default Profile MRT-Blue MPLS MT-ID (TBD-MRT-LDP-5) with suggested 721 value: 3947 723 IANA is also requested to change the purpose field of the MPLS Multi- 724 Topology Identifiers Registry for MT-ID range 3948-3995 to 725 "Unassigned (for future MRT-related values)", assuming the above 726 suggested values are assigned. The Registration procedure for the 727 entire registry remains "Standards Action". The entire registry 728 after implementing the above requests is shown below. 730 Value Purpose Reference 731 ------------- ---------------------- ------------ 732 0 Default/standard topology [RFC7307] 733 1 IPv4 in-band management [RFC7307] 734 2 IPv6 routing topology [RFC7307] 735 3 IPv4 multicast topology [RFC7307] 736 4 IPv6 multicast topology [RFC7307] 737 5 IPv6 in-band management [RFC7307] 738 6-3944 Unassigned (for future IGP topologies) 739 TBD-MRT-LDP-3 Rainbow MRT MPLS MT-ID [This draft] 740 TBD-MRT-LDP-4 Default Profile MRT-Red MPLS MT-ID [This draft] 741 TBD-MRT-LDP-5 Default Profile MRT-Blue MPLS MT-ID [This draft] 742 3948-3995 Unassigned (for future MRT-related values) [This draft] 743 3996-4095 Reserved for Experimental Use [RFC7307] 744 4096-65534 Unassigned (for MPLS topologies) 745 65535 Wildcard Topology [RFC7307] 747 9. Acknowledgements 749 The authors would like to thank Ross Callon, Loa Andersson, Stewart 750 Bryant, Mach Chen, Greg Mirsky, Uma Chunduri and Tony Przygienda for 751 their comments and suggestions. 753 10. References 755 10.1. Normative References 757 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 758 Requirement Levels", BCP 14, RFC 2119, 759 DOI 10.17487/RFC2119, March 1997, 760 . 762 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 763 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 764 October 2007, . 766 [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. 767 Le Roux, "LDP Capabilities", RFC 5561, 768 DOI 10.17487/RFC5561, July 2009, . 771 [RFC6420] Cai, Y. and H. Ou, "PIM Multi-Topology ID (MT-ID) Join 772 Attribute", RFC 6420, DOI 10.17487/RFC6420, November 2011, 773 . 775 [RFC7307] Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D. 776 King, "LDP Extensions for Multi-Topology", RFC 7307, 777 DOI 10.17487/RFC7307, July 2014, . 780 [RFC7811] Enyedi, G., Csaszar, A., Atlas, A., Bowers, C., and A. 781 Gopalan, "An Algorithm for Computing IP/LDP Fast Reroute 782 Using Maximally Redundant Trees (MRT-FRR)", RFC 7811, 783 DOI 10.17487/RFC7811, June 2016, . 786 [RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for 787 IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT- 788 FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016, 789 . 791 10.2. Informative References 793 [I-D.atlas-rtgwg-mrt-mc-arch] 794 Atlas, A., Kebler, R., Wijnands, I., Csaszar, A., and G. 795 Envedi, "An Architecture for Multicast Protection Using 796 Maximally Redundant Trees", draft-atlas-rtgwg-mrt-mc- 797 arch-02 (work in progress), July 2013. 799 [I-D.ietf-isis-mrt] 800 Li, Z., Wu, N., <>, Q., Atlas, A., Bowers, C., and J. 801 Tantsura, "Intermediate System to Intermediate System (IS- 802 IS) Extensions for Maximally Redundant Trees (MRT)", 803 draft-ietf-isis-mrt-02 (work in progress), May 2016. 805 [I-D.ietf-ospf-mrt] 806 Atlas, A., Hegde, S., Bowers, C., Tantsura, J., and Z. Li, 807 "OSPF Extensions to Support Maximally Redundant Trees", 808 draft-ietf-ospf-mrt-02 (work in progress), May 2016. 810 [I-D.wijnands-mpls-mldp-node-protection] 811 Wijnands, I., Rosen, E., Raza, K., Tantsura, J., Atlas, 812 A., and Q. Zhao, "mLDP Node Protection", draft-wijnands- 813 mpls-mldp-node-protection-04 (work in progress), June 814 2013. 816 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 817 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 818 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 819 . 821 Authors' Addresses 823 Alia Atlas 824 Juniper Networks 825 10 Technology Park Drive 826 Westford, MA 01886 827 USA 829 Email: akatlas@juniper.net 831 Kishore Tiruveedhula 832 Juniper Networks 833 10 Technology Park Drive 834 Westford, MA 01886 835 USA 837 Email: kishoret@juniper.net 838 Chris Bowers 839 Juniper Networks 840 1194 N. Mathilda Ave. 841 Sunnyvale, CA 94089 842 USA 844 Email: cbowers@juniper.net 846 Jeff Tantsura 847 Individual 848 USA 850 Email: jefftant.ietf@gmail.com 852 IJsbrand Wijnands 853 Cisco Systems, Inc. 855 Email: ice@cisco.com