idnits 2.17.1 draft-ietf-mpls-ldp-mrt-07.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 (November 15, 2017) is 2347 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: May 19, 2018 Juniper Networks 6 J. Tantsura 7 Individual 8 IJ. Wijnands 9 Cisco Systems, Inc. 10 November 15, 2017 12 LDP Extensions to Support Maximally Redundant Trees 13 draft-ietf-mpls-ldp-mrt-07 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 https://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 May 19, 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 (https://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 7 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 RFC 5036 . . . . . . . . . . . . . . . . 11 83 5.2.2. Next hop in RFC 5036 . . . . . . . . . . . . . . . . 12 84 5.2.3. Egress LSR in RFC 5036 . . . . . . . . . . . . . . . 12 85 5.2.4. Use of Rainbow FEC to satisfy label mapping existence 86 requirements in RFC 5036 . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . . 15 91 7. Potential restrictions on MRT-related MT-ID values imposed 92 by RFC 6420 . . . . . . . . . . . . . . . . . . . . . . . . . 15 93 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 94 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 95 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 96 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 97 10.2. Informative References . . . . . . . . . . . . . . . . . 18 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 100 1. Introduction 102 This document describes the LDP signaling extensions and associated 103 behavior necessary to support the architecture that defines how IP/ 104 LDP Fast-Reroute can use MRTs [RFC7812]. The current document 105 provides a brief description of the MRT-FRR architecture, focusing on 106 the aspects most directly related to LDP signaling. The complete 107 description and specification of the MRT-FRR architecture can be 108 found in [RFC7812]. 110 At least one common standardized algorithm (e.g., the MRT Lowpoint 111 algorithm explained and fully documented in [RFC7811]) is required to 112 be deployed so that the routers supporting MRT computation 113 consistently compute the same MRTs. LDP depends on an IGP for 114 computation of MRTs and alternates. Extensions to OSPF are defined 115 in [I-D.ietf-ospf-mrt]. Extensions to IS-IS are defined in 116 [I-D.ietf-isis-mrt]. 118 MRT can also be used to protect multicast traffic (signalled via PIM 119 or mLDP) using either global protection or local protection as 120 described in [I-D.atlas-rtgwg-mrt-mc-arch]. An MRT path can be used 121 to provide node-protection for mLDP traffic via the mechanisms 122 described in [RFC7715]; an MRT path can also be used to provide link 123 protection for mLDP traffic. 125 For each destination, IP/LDP Fast-Reroute with MRT (MRT-FRR) creates 126 two alternate destination-based trees separate from the shortest path 127 forwarding used during stable operation. LDP uses the multi-topology 128 extensions [RFC7307] to signal Forwarding Equivalency Classes (FECs) 129 for these two sets of forwarding trees, MRT-Blue and MRT-Red. 131 In order to create MRT paths and support IP/LDP Fast-Reroute, a new 132 capability extension is needed for LDP. An LDP implementation 133 supporting MRT MUST also follow the rules described here for 134 originating and managing FECs related to MRT, as indicated by their 135 multi-topology ID. Network reconvergence is described in [RFC7812] 136 and the worst-case network convergence time can be flooded via the 137 extension in Section 7 of [I-D.ietf-ospf-mrt]. 139 IP/LDP Fast-Reroute using MRTs can provide 100% coverage for link and 140 node failures in an arbitrary network topology where the failure 141 doesn't partition the network. It can also be deployed 142 incrementally; an MRT Island is formed of connected supporting 143 routers and the MRTs are computed inside that island. 145 2. Requirements Language 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC 2119[RFC2119] 151 3. Terminology 153 For ease of reading, some of the terminology defined in [RFC7812] is 154 repeated here. Please refer to the Section 3 of [RFC7812] for a more 155 complete list. 157 Redundant Trees (RT): A pair of trees where the path from any node 158 X to the root R along the first tree is node-disjoint with the 159 path from the same node X to the root along the second tree. 160 Redundant trees can always be computed in 2-connected graphs. 162 Maximally Redundant Trees (MRT): A pair of trees where the path 163 from any node X to the root R along the first tree and the path 164 from the same node X to the root along the second tree share the 165 minimum number of nodes and the minimum number of links. Each 166 such shared node is a cut-vertex. Any shared links are cut-links. 167 In graphs that are not 2-connected, it is not possible to compute 168 RTs. However, it is possible to compute MRTs. MRTs are maximally 169 redundant in the sense that they are as redundant as possible 170 given the constraints of the network graph. 172 MRT-Red: MRT-Red is used to describe one of the two MRTs; it is 173 used to describe the associated forwarding topology and MPLS 174 Multi-Topology IDentifier (MT-ID). 176 MRT-Blue: MRT-Blue is used to describe one of the two MRTs; it is 177 used to described the associated forwarding topology and MPLS MT- 178 ID. 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 in the MRT Island that is 190 connected to a router not in the MRT Island, both of which are in 191 a common area or level. 193 Island Neighbor (IN): A router that is not in the MRT Island but is 194 adjacent to an IBR and in the same area/level as the IBR.. 196 There are several places in this document where the construction 197 "red(blue) FEC" is used to cover the case of the red FEC and the case 198 of the blue FEC, independently. As an example, consider the sentence 199 "When the ABR requires best-area behavior for a red(blue) FEC, it 200 MUST withdraw any existing label mappings advertisements for the 201 corresponding rainbow FEC and advertise label mappings for the 202 red(blue) FEC." This sentence should be read as applying to red 203 FECs. Then it should be read as applying to blue FECs. 205 4. Overview of LDP Signaling Extensions for MRT 207 Routers need to know which of their LDP neighbors support MRT. This 208 is communicated using the MRT Capability Advertisement. Supporting 209 MRT indicates several different aspects of behavior, as listed below. 211 1. Sending and receiving multi-topology FEC elements, as defined in 212 [RFC7307]. 214 2. Understanding the Rainbow MRT MT-ID and applying the associated 215 labels to all relevant MT-IDs. 217 3. Advertising the Rainbow MRT FEC to the appropriate neighbors for 218 the appropriate prefix. 220 4. If acting as LDP egress for a prefix in the default topology, 221 also acting as egress for the same prefix in MRT-Red and MRT- 222 Blue. 224 5. For a FEC learned from a neighbor that does not support MRT, 225 originating FECs for MRT-Red and MRT-Blue with the same prefix. 226 This MRT Island egress behavior is to support an MRT Island that 227 does not include all routers in the area/level. 229 4.1. MRT Capability Advertisement 231 A new MRT Capability Parameter TLV is defined in accordance with LDP 232 Capability definition guidelines[RFC5561]. 234 The LDP MRT capability can be advertised during LDP session 235 initialization or after the LDP session is established. 236 Advertisement of the MRT capability indicates support of the 237 procedures for establishing the MRT-Blue and MRT-Red LSP paths 238 detailed in this document. If the peer has not advertised the MRT 239 capability, then it indicates that LSR does not support MRT 240 procedures. 242 If a router advertises the LDP MRT capability to its peer, but the 243 peer has not advertised the MRT capability, then the router MUST NOT 244 advertise MRT-related FEC-label bindings to that peer. 246 The following is the format of the MRT Capability Parameter. 248 0 1 2 3 249 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 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 |U|F| MRT Capability (IANA) | Length (= 1) | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 |S| Reserved | 254 +-+-+-+-+-+-+-+-+ 256 MRT Capability TLV Format 258 Where: 260 U-bit: The unknown TLV bit MUST be 1. A router that does not 261 recognize the MRT Capability TLV will silently ignore the TLV and 262 process the rest of the message as if the unknown TLV did not 263 exist. 265 F-bit: The forward unknown TLV bit MUST be 0 as required by 266 Section 3 of [RFC5561]. 268 MRT Capability: TBD-MRT-LDP-1 (To Be Allocated by IANA) 270 Length: The length (in octets) of TLV. Its value is 1. 272 S-bit: The State bit MUST be 1 if used in LDP "Initialization" 273 message. MAY be set to 0 or 1 in dynamic "Capability" message to 274 advertise or withdraw the capability respectively, as described in 275 [RFC5561]. 277 4.1.1. Interaction of MRT Capability and MT Capability 279 An LSR advertising the LDP MRT Capability MUST also advertise the LDP 280 Multi-topology (MT) capability. If an LSR negotiates LDP MRT 281 Capability with an LDP neighbor without also negotiating the LDP MT 282 Capability, the LSR MUST behave as if LDP MRT Capability has not been 283 negotiated and respond with the "MRT Capability negotiated without MT 284 Capability" status code in the LDP Notification message (defined in 285 the document). The E-bit of this Notification should be set to 0 to 286 indicate that this is an Advisory Notification. The LDP session 287 SHOULD NOT be terminated. 289 4.1.2. Interaction of LDP MRT Capability with IPv4 and IPv6 291 The MRT LDP Capability Advertisement does not distinguish between 292 IPv4 and IPv6 address families. An LSR which advertises the MRT LDP 293 capability is expected to advertise MRT-related FEC-label bindings 294 for the same address families for which it advertises shortest-path 295 FEC-label bindings. Therefore, an LSR advertising MRT LDP capability 296 and shortest path FEC-label bindings for IPv4 only (or IPv6 only) 297 would be expected to advertise MRT-related FEC-label binding for IPv4 298 only (or IPv6 only). An LSR advertising the MRT LDP capability and 299 shortest-path FEC label bindings for BOTH IPv4 and IPv6 is expected 300 to advertise MRT-related FEC-label bindings for BOTH IPv4 and IPv6. 301 In this scenario, advertising MRT-related FEC-label bindings only for 302 IPv4 only (or only for IPv6) is not supported. 304 4.2. Use of the Rainbow MRT MT-ID 306 Section 10.1 of [RFC7812] describes the need for an area border 307 router (ABR) to have different neighbors use different MPLS labels 308 when sending traffic to the ABR for the same FEC. More detailed 309 discussion of the Rainbow MRT MT-ID is provided in Section 5.1.1 of 310 the current document. 312 Another use for the Rainbow MRT MT-ID is for an LSR to send the 313 Rainbow MRT MT-ID with an IMPLICIT_NULL label to indicate 314 penultimate-hop-popping for all three types of FECs (shortest path, 315 red, and blue). The EXPLICIT_NULL label advertised using the Rainbow 316 MRT MT-ID similarly applies to all the types of FECs. Note that the 317 only scenario in which it is generally useful to advertise the 318 implicit or explicit null label for all three FEC types is when the 319 FEC refers to the LSR itself. See Section 5.2.3 for more details. 321 The value of the Rainbow MRT MPLS MT-ID (TBD-MRT-LDP-3) will be 322 assigned by IANA from the MPLS MT-ID space. 324 4.3. MRT-Blue and MRT-Red FECs 326 To provide MRT support in LDP, the MT Prefix FEC is used. [RFC7812] 327 defines the Default MRT Profile. Section 8 of the current document 328 specifies the values in the MPLS Multi-Topology Identifiers Registry 329 for the MRT-Red and MRT-Blue MPLS MT-IDs associated with the Default 330 MRT Profile (TBD-MRT-LDP-4 and TBD-MRT-LDP-5). 332 As described in Section 8.1 of [RFC7812], when a new MRT Profile is 333 defined, new and unique values should be allocated from the "MPLS 334 Multi-Topology Identifiers Registry", corresponding to the MRT-Red 335 and MRT-Blue MT-ID values for the new MRT Profile. 337 The MT Prefix FEC encoding is defined in [RFC7307] and is used 338 without alteration for advertising label mappings for MRT-Blue, MRT- 339 Red and Rainbow MRT FECs. 341 4.4. Interaction of MRT-related LDP advertisements with the MRT 342 topology and computations 344 [RFC7811] and [RFC7812] describe how the MRT topology is created 345 based on information in IGP advertisements. The MRT topology and 346 computations rely on IGP advertisements. The presence or absence of 347 MRT-related LDP advertisements does not affect the MRT topology or 348 the MRT-Red and MRT-Blue next-hops computed for that topology. 350 As an example, consider a network where all nodes are running MRT IGP 351 extensions to determine the MRT-topology, which is then used to 352 compute MRT-Red and MRT-Blue next-hops. The network operator also 353 configures the nodes in this network to exchange MRT-related LDP 354 advertisements in order to distribute MPLS labels corresponding to 355 those MRT next-hops. Suppose that, due to a misconfiguration on one 356 particular link, the MRT-related LDP advertisements are not being 357 properly exchanged for that link. Since the MRT-related IGP 358 advertisements for the link are still being distributed, the link is 359 still included in the MRT topology and computations. In this 360 scenario, there will be missing MPLS forwarding entries corresponding 361 to paths that use the misconfigured link. 363 Note that the situation is analogous to the interaction of normal LDP 364 advertisements and IGP advertisements for shortest path forwarding. 365 Deactivating the distribution of labels for normal shortest path FECs 366 on a link does not change the topology on which the SPF algorithm is 367 run by the IGP. 369 [RFC5443] "LDP IGP Synchronization" addresses the issue of the LDP 370 topology not matching the IGP topology by the advertising the maximum 371 IGP cost on links where LDP is not fully operational. This makes the 372 IGP topology match the LDP topology. As described in Section 7.3.1 373 of [RFC7812], MRT is designed to be compatible with the LDP IGP 374 synchronization mechanism. When the IGP advertises the maximum cost 375 on a link where LDP is not fully operational, the link is excluded 376 from MRT Island formation, which prevents the MRT algorithm from 377 creating any paths using that link. 379 5. LDP MRT FEC Advertisements 381 This sections describes how and when labels for MRT-Red and MRT-Blue 382 FECs are advertised. In order to provide protection paths which are 383 immediately usable by the point of local repair in the event of a 384 failure, the associated LSPs need to be created before a failure 385 occurs. 387 In this section, we will use the term "shortest path FEC" to refer to 388 the usual FEC associated with the shortest path destination-based 389 forwarding tree for a given prefix as determined by the IGP. We will 390 use the terms "red FEC" and "blue FEC" to refer to FECs associated 391 with the MRT-Red and MRT-Blue destination-based forwarding trees for 392 a given prefix as determined by a particular MRT algorithm. 394 We first describe label distribution behavior specific to MRT. Then 395 we provide the correct interpretation of several important concepts 396 in [RFC5036] in the context of MRT FEC label distribution. 398 [RFC5036] specifies two different Label Distribution Control Modes 399 (Independent and Ordered), two different Label Retention Modes 400 (Conservative and Liberal), and two different Label Advertisement 401 Modes (Downstream Unsolicited and Downstream on Demand). The current 402 specification for LDP MRT requires that the same Label Distribution 403 Control, Label Retention, and Label Advertisement modes be used for 404 the shortest path FECs and the MRT FECs. 406 5.1. MRT-specific behavior 408 5.1.1. ABR behavior and use of the Rainbow FEC 410 Section 10.1 of [RFC7812] describes the need for an area border 411 router (ABR) to have different neighbors use different MPLS labels 412 when sending traffic to the ABR for the same FEC. The method to 413 accomplish this using the Rainbow MRT MT-ID is described in detail in 414 [RFC7812]. Here we provide a brief summary. To those LDP peers in 415 the same area as the best route to the destination, the ABR 416 advertises two different labels corresponding to the MRT-Red and MRT- 417 Blue forwarding trees for the destination. An LDP peer receiving 418 these advertisements forwards MRT traffic to the ABR using these two 419 different labels, depending on the FEC of the traffic. We refer to 420 this as best-area advertising and forwarding behavior, which is 421 identical to normal MRT behavior. 423 For all other LDP peers supporting MRT, the ABR advertises a FEC- 424 label binding for the Rainbow MRT MT-ID scoped FEC with the label 425 corresponding to the default forwarding tree for the destination. An 426 LDP peer receiving this advertisement forwards MRT traffic to the ABR 427 using this label, for both MRT-Red and MRT-Blue traffic. We refer to 428 this as non-best-area advertising and forwarding behavior. 430 The use of the Rainbow-FEC by the ABR for non-best-area 431 advertisements is RECOMMENDED. An ABR MAY advertise the label for 432 the default topology in separate MRT-Blue and MRT-Red advertisements. 433 An LSR advertising the MRT capability MUST recognize the Rainbow MRT 434 MT-ID and associate the advertised label with the specific prefix 435 with the MRT-Red and MRT-Blue MT-IDs associated with all MRT Profiles 436 that advertise LDP as the forwarding mechanism. 438 Due to changes in topology or configuration, an ABR and a given LDP 439 peer may need to transition from best-area advertising and forwarding 440 behavior to non-best-area behavior for a given destination, and vice 441 versa. When the ABR requires best-area behavior for a red(blue) FEC, 442 it MUST withdraw any existing label mappings advertisements for the 443 corresponding rainbow FEC and advertise label mappings for the 444 red(blue) FEC. When the ABR requires non-best-area behavior for a 445 red(blue) FEC, it MUST withdraw any existing label mappings for both 446 red and blue FECs and advertise label mappings for the corresponding 447 Rainbow FEC label binding. 449 In this transition, an ABR should never advertise a red(blue) FEC 450 before withdrawing the corresponding rainbow FEC (or vice versa). 451 However, should this situation occur, the expected behavior of an LSR 452 receiving these conflicting advertisements is defined as follows. If 453 an LSR receives a label mapping advertisement for a rainbow FEC from 454 an MRT LDP peer while it still retains a label mapping for the 455 corresponding red or blue FEC, the LSR MUST continue to use the label 456 mapping for the red or blue FEC, and it MUST send a Label Release 457 Message corresponding to the rainbow FEC label advertisement. If an 458 LSR receives a label mapping advertisement for red or blue FEC while 459 it still retains a label mapping for the corresponding rainbow FEC, 460 the LSR MUST continue to use the label mapping for the rainbow FEC, 461 and it MUST send a Label Release Message corresponding to the red or 462 blue FEC label advertisement. 464 5.1.2. Proxy-node attachment router behavior 466 Section 11.2 of [RFC7812] describes how MRT provides FRR protection 467 for multi-homed prefixes using calculations involving a named proxy- 468 node. This covers the scenario where a prefix is originated by a 469 router in the same area as the MRT Island, but outside of the MRT 470 Island. It also covers the scenario of a prefix being advertised by 471 a multiple routers in the MRT Island. 473 In the named proxy-node calculation, each multi-homed prefix is 474 represented by a conceptual proxy-node which is attached to two real 475 proxy-node attachment routers. (A single proxy-node attachment 476 router is allowed in the case of a prefix advertised by a same area 477 router outside of the MRT Island which is singly connected to the MRT 478 Island.) All routers in the MRT Island perform the same calculations 479 to determine the same two proxy-node attachment routers for each 480 multi-homed prefix. Section 5.9 of [RFC7811] describes the procedure 481 for identifying one proxy-node attachment router as "red" and one as 482 "blue" with respect to the multi-homed prefix, and computing the MRT 483 red and blue next-hops to reach those red and blue proxy-node 484 attachment routers. 486 In terms of LDP behavior, a red proxy-node attachment router for a 487 given prefix MUST originate a label mapping for the red FEC for that 488 prefix, while the a blue proxy-node attachment router for a given 489 prefix MUST originate a label mapping for the blue FEC for that 490 prefix. If the red(blue) proxy-node attachment router is an Island 491 Border Router (IBR), then when it receives a packet with the label 492 corresponding to the red(blue) FEC for a prefix, it MUST forward the 493 packet to the Island Neighbor (IN) whose cost was used in the 494 selection of the IBR as a proxy-node attachment router. The IBR MUST 495 swap the incoming label for the outgoing label corresponding to the 496 shortest path FEC for the prefix advertised by the IN. In the case 497 where the IN does not support LDP, the IBR MUST pop the incoming 498 label and forward the packet to the IN. 500 If the proxy-node attachment router is not an IBR, then the packet 501 MUST be removed from the MRT forwarding topology and sent along the 502 interface(s) that caused the router to advertise the prefix. This 503 interface might be out of the area/level/AS. 505 5.2. LDP protocol procedures in the context of MRT label distribution 507 [RFC5036] specifies the LDP label distribution procedures for 508 shortest path FECs. In general, the same procedures can be applied 509 to the distribution of label mappings for red and blue FECs, provided 510 that the procedures are interpreted in the context of MRT FEC label 511 distribution. The correct interpretation of several important 512 concepts in [RFC5036] in the context of MRT FEC label distribution is 513 provided below. 515 5.2.1. LDP peer in RFC 5036 517 In the context of distributing label mappings for red and blue FECs, 518 we restrict LDP peer in [RFC5036] to mean LDP peers for which the LDP 519 MRT capability has been negotiated. In order to make this 520 distinction clear, in this document we will use the term "MRT LDP 521 peer" to refer to an LDP peer for which the LDP MRT capability has 522 been negotiated. 524 5.2.2. Next hop in RFC 5036 526 Several procedures in [RFC5036] use the next hop of a (shortest path) 527 FEC to determine behavior. The next hop of the shortest path FEC is 528 based on the shortest path forwarding tree to the prefix associated 529 with the FEC. When the procedures of [RFC5036] are used to 530 distribute label mapping for red and blue FECs, the next hop for the 531 red(blue) FEC is based on the MRT-Red(Blue) forwarding tree to the 532 prefix associated with the FEC. 534 For example, Appendix A.1.7 of [RFC5036] specifies the response by an 535 LSR to a change in the next hop for a FEC. For a shortest path FEC, 536 the next hop may change as the result of the LSR running a shortest 537 path computation on a modified IGP topology database. For the red 538 and blue FECs, the red and blue next hops may change as the result of 539 the LSR running a particular MRT algorithm on a modified IGP topology 540 database. 542 As another example, Section 2.6.1.2 of [RFC5036] specifies that when 543 an LSR is using LSP Ordered Control, it may initiate the transmission 544 of a label mapping only for a (shortest path) FEC for which it has a 545 label mapping for the FEC next hop, or for which the LSR is the 546 egress. The FEC next hop for a shortest path FEC is based on the 547 shortest path forwarding tree to the prefix associated with the FEC. 548 In the context of distributing MRT LDP labels, this procedure is 549 understood to mean the following. When an LSR is using LSP Ordered 550 Control, it may initiate the transmission of a label mapping only for 551 a red(blue) FEC for which it has a label mapping for the red(blue) 552 FEC next hop, or for which the LSR is the egress. The red or blue 553 FEC next hop is based on the MRT-Red or Blue forwarding tree to the 554 prefix associated with the FEC. 556 5.2.3. Egress LSR in RFC 5036 558 Procedures in [RFC5036] related to Ordered Control label distribution 559 mode rely on whether or not an LSR may act as an egress LSR for a 560 particular FEC in order to determine whether or not the LSR may 561 originate a label mapping for that FEC. The status of being an 562 egress LSR for a particular FEC is also used in loop detection 563 procedures in [RFC5036]. Section 2.6.1.2 of [RFC5036] specifies the 564 conditions under which an LSR may act as an egress LSR with respect 565 to a particular (shortest path) FEC. 567 1. The (shortest path) FEC refers to the LSR itself (including one 568 of its directly attached interfaces). 570 2. The next hop router for the (shortest path) FEC is outside of the 571 Label Switching Network. 573 3. (Shortest path) FEC elements are reachable by crossing a routing 574 domain boundary. 576 The conditions for determining an egress LSR with respect to a red or 577 blue FEC need to be modified. An LSR may act as an egress LSR with 578 respect to a particular red(blue) FEC under any of the following 579 conditions: 581 1. The prefix associated with the red(blue) FEC refers to the LSR 582 itself (including one of its directly attached interfaces). 584 2. The LSR is the red(blue) proxy-node attachment router with 585 respect to the multi-homed prefix associated with the red(blue) 586 FEC. This includes the degenerate case of a single red and blue 587 proxy-node attachment router for a single-homed prefix. 589 3. The LSR is an area border router (ABR) AND the MRT LDP peer 590 requires non-best-area advertising and forwarding behavior for 591 the prefix associated with the FEC. 593 Note that condition(3) scopes an LSR's status as an egress LSR with 594 respect to a particular FEC to a particular MRT LDP peer. Therefore, 595 the condition "Is LSR egress for FEC?" that occurs in several 596 procedures in [RFC5036] needs to be interpreted as "Is LSR egress for 597 FEC with respect to Peer?" 599 Also note that there is no explicit condition that allows an LSR to 600 be classified as an egress LSR with respect to a red or blue FEC 601 based only on the primary next-hop for the shortest path FEC not 602 supporting LDP, or not supporting LDP MRT capability. These 603 situations are covered by the proxy-node attachment router and ABR 604 conditions (conditions 2 and 3). In particular, an Island Border 605 Router is not the egress LSR for a red(blue) FEC unless it is also 606 the red(blue) proxy-node attachment router for that FEC. 608 Also note that in general a proxy-node attachment router for a given 609 prefix should not advertise an implicit or explicit null label for 610 the corresponding red or blue FEC, even though it may be an egress 611 LSR for the shortest path FEC. In general, the proxy-node attachment 612 router needs to forward red or blue traffic for that prefix to a 613 particular loop free island neighbor, which may be different from the 614 shortest path next-hop. The proxy-node attachment router needs to 615 receive the red or blue traffic with a non-null label to correctly 616 forward it. 618 5.2.4. Use of Rainbow FEC to satisfy label mapping existence 619 requirements in RFC 5036 621 Several procedures in [RFC5036] require the LSR to determine if it 622 has previously received and retained a label mapping for a FEC from 623 the next hop. In the case of an LSR that has received and retained a 624 label mapping for a Rainbow FEC from an ABR, the label mapping for 625 the Rainbow FEC satisfies the label mapping existence requirement for 626 the corresponding red and blue FECs. Label mapping existence 627 requirements in the context of MRT LDP label distribution are 628 modified as: "Has LSR previously received and retained a label 629 mapping for the red(blue) FEC (or the corresponding Rainbow FEC) from 630 the red(blue) next hop?" 632 As an example, this behavior allows an LSR which has received and 633 retained a label mapping for the Rainbow FEC to advertise label 634 mappings for the corresponding red and blue FECs when operating in 635 Ordered Control label distribution mode. 637 5.2.5. Validating FECs in routing table 639 In [RFC5036] an LSR uses its routing table to validate prefixes 640 associated with shortest path FECs. For example, section 3.5.7.1 of 641 [RFC5036] specifies that "an LSR receiving a Label Mapping message 642 from a downstream LSR for a Prefix SHOULD NOT use the label for 643 forwarding unless its routing table contains an entry that exactly 644 matches the FEC Element." In the context of MRT FECs, a red or blue 645 FEC element matches a routing table entry if the corresponding 646 shortest path FEC element matches a routing table entry. 648 5.2.6. Recognizing new FECs 650 Section A.1.6 of [RFC5036] describes the response of an LSR to the 651 "Recognize New FEC" event, which occurs when an LSR learns a new 652 (shortest path) FEC via the routing table. In the context of MRT 653 FECs, when MRT LDP capability has been enabled, when an LSR learns a 654 new shortest path FEC, it should generate "Recognize New FEC" events 655 for the corresponding red and blue FECs, in addition to the 656 "Recognize New FEC" event for the shortest path FEC. 658 5.2.7. Not propagating Rainbow FEC label mappings 660 A label mapping for the Rainbow FEC should only be originated by an 661 ABR under the conditions described in Section 5.1.1. A neighbor of 662 the ABR that receives a label mapping for the Rainbow FEC MUST NOT 663 propagate a label mapping for that Rainbow FEC. 665 6. Security Considerations 667 The labels distributed by the extensions in this document create 668 additional forwarding paths that do not follow shortest path routes. 669 The transit label swapping operations defining these alternative 670 forwarding paths are created during normal operations (before a 671 failure occurs). Therefore, a malicious packet with an appropriate 672 label injected into the network from a compromised location would be 673 forwarded to a destination along a non-shortest path. When this 674 technology is deployed, a network security design should not rely on 675 assumptions about potentially malicious traffic only following 676 shortest paths. 678 It should be noted that the creation of non-shortest forwarding paths 679 is not unique to MRT. For example, RSVP-TE [RFC3209] can be used to 680 construct forwarding paths that do not follow the shortest path. 682 7. Potential restrictions on MRT-related MT-ID values imposed by RFC 683 6420 685 As discussed in the introduction, in addition to unicast forwarding 686 applications, MRT can be used to provide disjoint trees for multicast 687 traffic distribution. In the case of PIM, this is accomplished by 688 using the MRT red and blue next-hops as the PIM RPF topology, the 689 collection of routes used by PIM to perform the RPF operation when 690 building source trees. The PIM Multi-Topology ID (MT-ID) Join 691 Attribute defined in section 5.2 of [RFC6420] can be used to 692 establish MRT-based multicast distribution trees. [RFC6420] limits 693 the values of the PIM MT-ID from 1 through 4095. 695 For the purpose of reducing management overhead and simplifying 696 troubleshooting, it is desirable to be able to use the same numerical 697 value for the PIM MT-ID as for the MPLS MT-ID, for multicast and 698 unicast application using MRT routes constructed using the same MRT 699 profile. In order to enable this simplification, the MPLS MT-ID 700 values assigned in this document need to fall in the range 1 through 701 4095. The IANA request below reflects this by requesting that the 702 MPLS MT-ID values from 3945 through 3995 be used for MRT-related MPLS 703 MT-ID values. This allows for 51 MRT-related MPLS MT-ID values which 704 can be directly mapped to PIM MT-ID values, which accommodates 25 MRT 705 profiles with red and blue MT-ID pairs, with one extra for the 706 rainbow MPLS MT-ID value. [RFC7307] designates the MPLS MT-ID range 707 6-3995 as "Unassigned(for future IGP topologies)". The IANA request 708 below changes the guidance for MT-ID range 3948-3995 to "Unassigned 709 (for future MRT-related values)". 711 8. IANA Considerations 713 IANA is requested to allocate a value for the new LDP Capability TLV 714 (the first free value in the range 0x0500 to 0x05FF) from the Label 715 Distribution Protocol (LDP) Parameters registry "TLV Type Name 716 Space": MRT Capability TLV (TBD-MRT-LDP-1). 718 Value Description Reference Notes / Reg. Date 719 ------------- ------------------ ------------ ----------------- 720 TBD-MRT-LDP-1 MRT Capability TLV [This draft] 722 IANA is requested to allocate a value for the new LDP Status Code 723 (the first free value in the range 0x00000032-0x00000036) from the 724 Label Distribution Protocol (LDP) Parameters registry "Status Code 725 Name Space": "MRT Capability negotiated without MT Capability" (TBD- 726 MRT-LDP-2). The Status Code E-bit is set to 0. 728 Value E Description Reference Notes / Reg. Date 729 -------------- - ------------------ ------------ ----------------- 730 TBD-MRT-LDP-2 0 MRT Capability [This draft] 731 negotiated without 732 MT Capability 734 IANA is requested to allocate three values from the MPLS Multi- 735 Topology Identifiers Registry [RFC7307]. 737 Rainbow MRT MPLS MT-ID (TBD-MRT-LDP-3) with suggested value: 3945 739 Default Profile MRT-Red MPLS MT-ID (TBD-MRT-LDP-4) with suggested 740 value: 3946 742 Default Profile MRT-Blue MPLS MT-ID (TBD-MRT-LDP-5) with suggested 743 value: 3947 745 IANA is also requested to change the purpose field of the MPLS Multi- 746 Topology Identifiers Registry for MT-ID range 3948-3995 to 747 "Unassigned (for future MRT-related values)", assuming the above 748 suggested values are assigned. The Registration procedure for the 749 entire registry remains "Standards Action". The entire registry 750 after implementing the above requests is shown below. 752 Value Purpose Reference 753 ------------- ---------------------- ------------ 754 0 Default/standard topology [RFC7307] 755 1 IPv4 in-band management [RFC7307] 756 2 IPv6 routing topology [RFC7307] 757 3 IPv4 multicast topology [RFC7307] 758 4 IPv6 multicast topology [RFC7307] 759 5 IPv6 in-band management [RFC7307] 760 6-3944 Unassigned (for future IGP topologies) 761 TBD-MRT-LDP-3 Rainbow MRT MPLS MT-ID [This draft] 762 TBD-MRT-LDP-4 Default Profile MRT-Red MPLS MT-ID [This draft] 763 TBD-MRT-LDP-5 Default Profile MRT-Blue MPLS MT-ID [This draft] 764 3948-3995 Unassigned (for future MRT-related values) [This draft] 765 3996-4095 Reserved for Experimental Use [RFC7307] 766 4096-65534 Unassigned (for MPLS topologies) 767 65535 Wildcard Topology [RFC7307] 769 9. Acknowledgements 771 The authors would like to thank Ross Callon, Loa Andersson, Stewart 772 Bryant, Mach Chen, Greg Mirsky, Uma Chunduri and Tony Przygienda for 773 their comments and suggestions. 775 10. References 777 10.1. Normative References 779 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 780 Requirement Levels", BCP 14, RFC 2119, 781 DOI 10.17487/RFC2119, March 1997, 782 . 784 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 785 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 786 October 2007, . 788 [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. 789 Le Roux, "LDP Capabilities", RFC 5561, 790 DOI 10.17487/RFC5561, July 2009, 791 . 793 [RFC6420] Cai, Y. and H. Ou, "PIM Multi-Topology ID (MT-ID) Join 794 Attribute", RFC 6420, DOI 10.17487/RFC6420, November 2011, 795 . 797 [RFC7307] Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D. 798 King, "LDP Extensions for Multi-Topology", RFC 7307, 799 DOI 10.17487/RFC7307, July 2014, 800 . 802 [RFC7811] Enyedi, G., Csaszar, A., Atlas, A., Bowers, C., and A. 803 Gopalan, "An Algorithm for Computing IP/LDP Fast Reroute 804 Using Maximally Redundant Trees (MRT-FRR)", RFC 7811, 805 DOI 10.17487/RFC7811, June 2016, 806 . 808 [RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for 809 IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT- 810 FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016, 811 . 813 10.2. Informative References 815 [I-D.atlas-rtgwg-mrt-mc-arch] 816 Atlas, A., Kebler, R., Wijnands, I., Csaszar, A., and G. 817 Envedi, "An Architecture for Multicast Protection Using 818 Maximally Redundant Trees", draft-atlas-rtgwg-mrt-mc- 819 arch-02 (work in progress), July 2013. 821 [I-D.ietf-isis-mrt] 822 Li, Z., Wu, N., <>, Q., Atlas, A., Bowers, C., and J. 823 Tantsura, "Intermediate System to Intermediate System (IS- 824 IS) Extensions for Maximally Redundant Trees (MRT)", 825 draft-ietf-isis-mrt-02 (work in progress), May 2016. 827 [I-D.ietf-ospf-mrt] 828 Atlas, A., Hegde, S., Bowers, C., Tantsura, J., and Z. Li, 829 "OSPF Extensions to Support Maximally Redundant Trees", 830 draft-ietf-ospf-mrt-02 (work in progress), May 2016. 832 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 833 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 834 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 835 . 837 [RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP 838 Synchronization", RFC 5443, DOI 10.17487/RFC5443, March 839 2009, . 841 [RFC7715] Wijnands, IJ., Ed., Raza, K., Atlas, A., Tantsura, J., and 842 Q. Zhao, "Multipoint LDP (mLDP) Node Protection", 843 RFC 7715, DOI 10.17487/RFC7715, January 2016, 844 . 846 Authors' Addresses 848 Alia Atlas 849 Juniper Networks 850 10 Technology Park Drive 851 Westford, MA 01886 852 USA 854 Email: akatlas@juniper.net 856 Kishore Tiruveedhula 857 Juniper Networks 858 10 Technology Park Drive 859 Westford, MA 01886 860 USA 862 Email: kishoret@juniper.net 864 Chris Bowers 865 Juniper Networks 866 1194 N. Mathilda Ave. 867 Sunnyvale, CA 94089 868 USA 870 Email: cbowers@juniper.net 872 Jeff Tantsura 873 Individual 874 USA 876 Email: jefftant.ietf@gmail.com 878 IJsbrand Wijnands 879 Cisco Systems, Inc. 881 Email: ice@cisco.com