summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8320.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8320.txt')
-rw-r--r--doc/rfc/rfc8320.txt1179
1 files changed, 1179 insertions, 0 deletions
diff --git a/doc/rfc/rfc8320.txt b/doc/rfc/rfc8320.txt
new file mode 100644
index 0000000..1e4dbe2
--- /dev/null
+++ b/doc/rfc/rfc8320.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) A. Atlas
+Request for Comments: 8320 K. Tiruveedhula
+Category: Standards Track C. Bowers
+ISSN: 2070-1721 Juniper Networks
+ J. Tantsura
+ Individual
+ IJ. Wijnands
+ Cisco Systems, Inc.
+ February 2018
+
+
+ LDP Extensions to Support Maximally Redundant Trees
+
+Abstract
+
+ This document specifies extensions to the Label Distribution Protocol
+ (LDP) to support the creation of Label Switched Paths (LSPs) for
+ Maximally Redundant Trees (MRTs). A prime use of MRTs is for unicast
+ and multicast IP/LDP Fast Reroute, which we will refer to as
+ "MRT-FRR".
+
+ The sole protocol extension to LDP is simply the ability to advertise
+ an MRT Capability. This document describes that extension and the
+ associated behavior expected for Label Switching Routers (LSRs) and
+ Label Edge Routers (LERs) advertising the MRT Capability.
+
+ MRT-FRR uses LDP multi-topology extensions, so three multi-topology
+ IDs have been allocated from the MPLS MT-ID space.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ https://www.rfc-editor.org/info/rfc8320.
+
+
+
+
+
+
+
+
+
+Atlas, et al. Standards Track [Page 1]
+
+RFC 8320 LDP Extensions to Support MRTs February 2018
+
+
+Copyright Notice
+
+ Copyright (c) 2018 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (https://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Atlas, et al. Standards Track [Page 2]
+
+RFC 8320 LDP Extensions to Support MRTs February 2018
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
+ 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 4. Overview of LDP Signaling Extensions for MRT . . . . . . . . 6
+ 4.1. MRT Capability Advertisement . . . . . . . . . . . . . . 6
+ 4.1.1. Interaction of MRT Capability and MT Capability . . . 7
+ 4.1.2. Interaction of LDP MRT Capability with IPv4 and IPv6 8
+ 4.2. Use of the Rainbow MRT MT-ID . . . . . . . . . . . . . . 8
+ 4.3. MRT-Blue and MRT-Red FECs . . . . . . . . . . . . . . . . 8
+ 4.4. Interaction of MRT-Related LDP Advertisements with the
+ MRT Topology and Computations . . . . . . . . . . . . . . 9
+ 5. LDP MRT FEC Advertisements . . . . . . . . . . . . . . . . . 10
+ 5.1. MRT-Specific Behavior . . . . . . . . . . . . . . . . . . 10
+ 5.1.1. ABR Behavior and Use of the Rainbow FEC . . . . . . . 10
+ 5.1.2. Proxy-Node Attachment Router Behavior . . . . . . . . 11
+ 5.2. LDP Protocol Procedures in the Context of MRT Label
+ Distribution . . . . . . . . . . . . . . . . . . . . . . 12
+ 5.2.1. LDP Peer in RFC 5036 . . . . . . . . . . . . . . . . 12
+ 5.2.2. Next Hop in RFC 5036 . . . . . . . . . . . . . . . . 13
+ 5.2.3. Egress LSR in RFC 5036 . . . . . . . . . . . . . . . 13
+ 5.2.4. Use of Rainbow FEC to Satisfy Label Mapping Existence
+ Requirements in RFC 5036 . . . . . . . . . . . . . . 15
+ 5.2.5. Validating FECs in the Routing Table . . . . . . . . 15
+ 5.2.6. Recognizing New FECs . . . . . . . . . . . . . . . . 15
+ 5.2.7. Not Propagating Rainbow FEC Label Mappings . . . . . 15
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
+ 7. Potential Restrictions on MRT-Related MT-ID Values Imposed by
+ RFC 6420 . . . . . . . . . . . . . . . . . . . . . . . . . . 16
+ 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
+ 9.1. Normative References . . . . . . . . . . . . . . . . . . 18
+ 9.2. Informative References . . . . . . . . . . . . . . . . . 19
+ Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Atlas, et al. Standards Track [Page 3]
+
+RFC 8320 LDP Extensions to Support MRTs February 2018
+
+
+1. Introduction
+
+ This document describes the LDP signaling extensions and associated
+ behavior necessary to support the architecture that defines how IP/
+ LDP Fast Reroute can use MRTs [RFC7812]. The current document
+ provides a brief description of the MRT-FRR architecture, focusing on
+ the aspects most directly related to LDP signaling. The complete
+ description and specification of the MRT-FRR architecture can be
+ found in [RFC7812].
+
+ At least one common standardized algorithm (e.g., the MRT Lowpoint
+ algorithm explained and fully documented in [RFC7811]) is required to
+ be deployed so that the routers supporting MRT computation
+ consistently compute the same MRTs. LDP depends on an IGP for
+ computation of MRTs and alternates. Extensions to OSPF are defined
+ in [OSPF-MRT]. Extensions to IS-IS are defined in [IS-IS-MRT].
+
+ MRT can also be used to protect multicast traffic (signaled via PIM
+ or Multipoint LDP (mLDP)) using either global protection or local
+ protection as described in [ARCH]. An MRT path can be used to
+ provide node-protection for mLDP traffic via the mechanisms described
+ in [RFC7715]; an MRT path can also be used to provide link protection
+ for mLDP traffic.
+
+ For each destination, IP/LDP Fast Reroute with MRT (MRT-FRR) creates
+ two alternate destination-based trees separate from the shortest-path
+ forwarding used during stable operation. LDP uses the multi-topology
+ extensions [RFC7307] to signal Forwarding Equivalency Classes (FECs)
+ for these two sets of forwarding trees, MRT-Blue and MRT-Red.
+
+ In order to create MRT paths and support IP/LDP Fast Reroute, a new
+ capability extension is needed for LDP. An LDP implementation
+ supporting MRT MUST also follow the rules described here for
+ originating and managing FECs related to MRT, as indicated by their
+ multi-topology ID. Network reconvergence is described in [RFC7812]
+ and the worst-case network convergence time can be flooded via the
+ extension in [PARAM-SYNC].
+
+ IP/LDP Fast Reroute using MRTs can provide 100% coverage for link and
+ node failures in an arbitrary network topology where the failure
+ doesn't partition the network. It can also be deployed
+ incrementally; an MRT Island is formed of connected supporting
+ routers and the MRTs are computed inside that island.
+
+
+
+
+
+
+
+
+Atlas, et al. Standards Track [Page 4]
+
+RFC 8320 LDP Extensions to Support MRTs February 2018
+
+
+2. Requirements Language
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+ capitals, as shown here.
+
+3. Terminology
+
+ For ease of reading, some of the terminology defined in [RFC7812] is
+ repeated here. Please refer to Section 3 of [RFC7812] for a more
+ complete list.
+
+ Redundant Trees (RTs): A pair of trees where the path from any node
+ X to the root R along the first tree is node-disjoint with the
+ path from the same node X to the root along the second tree.
+ Redundant trees can always be computed in 2-connected graphs.
+
+ Maximally Redundant Trees (MRTs): A pair of trees where the path
+ from any node X to the root R along the first tree and the path
+ from the same node X to the root along the second tree share the
+ minimum number of nodes and the minimum number of links. Each
+ such shared node is a cut-vertex. Any shared links are cut-links.
+ In graphs that are not 2-connected, it is not possible to compute
+ RTs. However, it is possible to compute MRTs. MRTs are maximally
+ redundant in the sense that they are as redundant as possible
+ given the constraints of the network graph.
+
+ MRT-Red: MRT-Red is used to describe one of the two MRTs; it is used
+ to describe the associated forwarding topology and MPLS Multi-
+ Topology Identifier (MT-ID).
+
+ MRT-Blue: MRT-Blue is used to describe one of the two MRTs; it is
+ used to described the associated forwarding topology and MPLS
+ MT-ID.
+
+ Rainbow MRT: It is useful to have an MPLS MT-ID that refers to the
+ multiple MRT forwarding topologies and to the default forwarding
+ topology. This is referred to as the "Rainbow MRT MPLS MT-ID" and
+ is used by LDP to reduce signaling and permit the same label to
+ always be advertised to all peers for the same (MT-ID, Prefix).
+
+ MRT Island: The set of routers that support a particular MRT Profile
+ and the links connecting them that support MRT.
+
+
+
+
+
+
+Atlas, et al. Standards Track [Page 5]
+
+RFC 8320 LDP Extensions to Support MRTs February 2018
+
+
+ Island Border Router (IBR): A router in the MRT Island that is
+ connected to a router not in the MRT Island, both of which are in
+ a common area or level.
+
+ Island Neighbor (IN): A router that is not in the MRT Island but is
+ adjacent to an IBR and in the same area/level as the IBR.
+
+ There are several places in this document where the construction
+ "red(blue) FEC" is used to cover the case of the red FEC and the case
+ of the blue FEC, independently. As an example, consider the sentence
+ "When the ABR requires best-area behavior for a red(blue) FEC, it
+ MUST withdraw any existing label mappings advertisements for the
+ corresponding Rainbow FEC and advertise label mappings for the
+ red(blue) FEC." This sentence should be read as applying to red
+ FECs. Then it should be read as applying to blue FECs.
+
+4. Overview of LDP Signaling Extensions for MRT
+
+ Routers need to know which of their LDP neighbors support MRT. This
+ is communicated using the MRT Capability Advertisement. Supporting
+ MRT indicates several different aspects of behavior, as listed below.
+
+ 1. Sending and receiving multi-topology FEC elements, as defined in
+ [RFC7307].
+
+ 2. Understanding the Rainbow MRT MT-ID and applying the associated
+ labels to all relevant MT-IDs.
+
+ 3. Advertising the Rainbow MRT FEC to the appropriate neighbors for
+ the appropriate prefix.
+
+ 4. If acting as LDP egress for a prefix in the default topology,
+ also acting as egress for the same prefix in MRT-Red and
+ MRT-Blue.
+
+ 5. For a FEC learned from a neighbor that does not support MRT,
+ originating FECs for MRT-Red and MRT-Blue with the same prefix.
+ This MRT Island egress behavior is to support an MRT Island that
+ does not include all routers in the area/level.
+
+4.1. MRT Capability Advertisement
+
+ A new MRT Capability Parameter TLV is defined in accordance with the
+ LDP Capability definition guidelines [RFC5561].
+
+ The LDP MRT Capability can be advertised during LDP session
+ initialization or after the LDP session is established.
+ Advertisement of the MRT Capability indicates support of the
+
+
+
+Atlas, et al. Standards Track [Page 6]
+
+RFC 8320 LDP Extensions to Support MRTs February 2018
+
+
+ procedures for establishing the MRT-Blue and MRT-Red Label Switched
+ Paths (LSPs) detailed in this document. If the peer has not
+ advertised the MRT Capability, then it indicates that LSR does not
+ support MRT procedures.
+
+ If a router advertises the LDP MRT Capability to its peer, but the
+ peer has not advertised the MRT Capability, then the router MUST NOT
+ advertise MRT-related FEC-label bindings to that peer.
+
+ The following is the format of the MRT Capability Parameter.
+
+ 0 1 2 3
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |U|F| MRT Capability (0x050E) | Length (= 1) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |S| Reserved |
+ +-+-+-+-+-+-+-+-+
+
+ MRT Capability TLV Format
+
+ Where:
+
+ U-bit: The unknown TLV bit MUST be 1. A router that does not
+ recognize the MRT Capability TLV will silently ignore the TLV and
+ process the rest of the message as if the unknown TLV did not
+ exist.
+
+ F-bit: The forward unknown TLV bit MUST be 0 as required by
+ Section 3 of [RFC5561].
+
+ MRT Capability: 0x050E
+
+ Length: The length (in octets) of the TLV. Its value is 1.
+
+ S-bit: The State bit MUST be 1 if used in the LDP Initialization
+ message. MAY be set to 0 or 1 in the dynamic Capability message
+ to advertise or withdraw the capability, respectively, as
+ described in [RFC5561].
+
+4.1.1. Interaction of MRT Capability and MT Capability
+
+ An LSR advertising the LDP MRT Capability MUST also advertise the LDP
+ Multi-Topology (MT) Capability. If an LSR negotiates the LDP MRT
+ Capability with an LDP neighbor without also negotiating the LDP MT
+ Capability, the LSR MUST behave as if the LDP MRT Capability was not
+ negotiated and respond with the "MRT Capability negotiated without MT
+ Capability" status code in the LDP Notification message (defined in
+
+
+
+Atlas, et al. Standards Track [Page 7]
+
+RFC 8320 LDP Extensions to Support MRTs February 2018
+
+
+ the document). The E-bit of this Notification should be set to 0 to
+ indicate that this is an Advisory Notification. The LDP session
+ SHOULD NOT be terminated.
+
+4.1.2. Interaction of LDP MRT Capability with IPv4 and IPv6
+
+ The MRT LDP Capability Advertisement does not distinguish between
+ IPv4 and IPv6 address families. An LSR that advertises the MRT LDP
+ Capability is expected to advertise MRT-related FEC-label bindings
+ for the same address families for which it advertises shortest-path
+ FEC-label bindings. Therefore, an LSR advertising MRT LDP Capability
+ and shortest-path FEC-label bindings for IPv4 only (or IPv6 only)
+ would be expected to advertise MRT-related FEC-label binding for IPv4
+ only (or IPv6 only). An LSR advertising the MRT LDP Capability and
+ shortest-path FEC-label bindings for BOTH IPv4 and IPv6 is expected
+ to advertise MRT-related FEC-label bindings for BOTH IPv4 and IPv6.
+ In this scenario, advertising MRT-related FEC-label bindings only for
+ IPv4 only (or only for IPv6) is not supported.
+
+4.2. Use of the Rainbow MRT MT-ID
+
+ Section 10.1 of [RFC7812] describes the need for an Area Border
+ Router (ABR) to have different neighbors use different MPLS labels
+ when sending traffic to the ABR for the same FEC. More detailed
+ discussion of the Rainbow MRT MT-ID is provided in Section 5.1.1.
+
+ Another use for the Rainbow MRT MT-ID is for an LSR to send the
+ Rainbow MRT MT-ID with an IMPLICIT_NULL label to indicate
+ penultimate-hop-popping for all three types of FECs (shortest path,
+ red, and blue). The EXPLICIT_NULL label advertised using the Rainbow
+ MRT MT-ID similarly applies to all the types of FECs. Note that the
+ only scenario in which it is generally useful to advertise the
+ implicit or explicit null label for all three FEC types is when the
+ FEC refers to the LSR itself. See Section 5.2.3 for more details.
+
+ The value of the Rainbow MRT MPLS MT-ID (3945) has been assigned by
+ IANA from the MPLS MT-ID space.
+
+4.3. MRT-Blue and MRT-Red FECs
+
+ To provide MRT support in LDP, the MT Prefix FEC is used. [RFC7812]
+ defines the Default MRT Profile. Section 8 specifies the values in
+ the "MPLS Multi-Topology Identifiers" registry for the MRT-Red and
+ MRT-Blue MPLS MT-IDs associated with the Default MRT Profile (3946
+ and 3947).
+
+
+
+
+
+
+Atlas, et al. Standards Track [Page 8]
+
+RFC 8320 LDP Extensions to Support MRTs February 2018
+
+
+ As described in Section 8.1 of [RFC7812], when a new MRT Profile is
+ defined, new and unique values should be allocated from the "MPLS
+ Multi-Topology Identifiers" registry, corresponding to the MRT-Red
+ and MRT-Blue MT-ID values for the new MRT Profile.
+
+ The MT Prefix FEC encoding is defined in [RFC7307] and is used
+ without alteration for advertising label mappings for MRT-Blue,
+ MRT-Red, and Rainbow MRT FECs.
+
+4.4. Interaction of MRT-Related LDP Advertisements with the MRT
+ Topology and Computations
+
+ [RFC7811] and [RFC7812] describe how the MRT topology is created
+ based on information in IGP advertisements. The MRT topology and
+ computations rely on IGP advertisements. The presence or absence of
+ MRT-related LDP advertisements does not affect the MRT topology or
+ the MRT-Red and MRT-Blue next hops computed for that topology.
+
+ As an example, consider a network where all nodes are running MRT IGP
+ extensions to determine the MRT topology, which is then used to
+ compute MRT-Red and MRT-Blue next hops. The network operator also
+ configures the nodes in this network to exchange MRT-related LDP
+ advertisements in order to distribute MPLS labels corresponding to
+ those MRT next hops. Suppose that, due to a misconfiguration on one
+ particular link, the MRT-related LDP advertisements are not being
+ properly exchanged for that link. Since the MRT-related IGP
+ advertisements for the link are still being distributed, the link is
+ still included in the MRT topology and computations. In this
+ scenario, there will be missing MPLS forwarding entries corresponding
+ to paths that use the misconfigured link.
+
+ Note that the situation is analogous to the interaction of normal LDP
+ advertisements and IGP advertisements for shortest-path forwarding.
+ Deactivating the distribution of labels for normal shortest-path FECs
+ on a link does not change the topology on which the Shortest Path
+ First (SPF) algorithm is run by the IGP.
+
+ "LDP IGP Synchronization" [RFC5443] addresses the issue of the LDP
+ topology not matching the IGP topology by advertising the maximum IGP
+ cost on links where LDP is not fully operational. This makes the IGP
+ topology match the LDP topology. As described in Section 7.3.1 of
+ [RFC7812], MRT is designed to be compatible with the LDP IGP
+ synchronization mechanism. When the IGP advertises the maximum cost
+ on a link where LDP is not fully operational, the link is excluded
+ from MRT Island formation, which prevents the MRT algorithm from
+ creating any paths using that link.
+
+
+
+
+
+Atlas, et al. Standards Track [Page 9]
+
+RFC 8320 LDP Extensions to Support MRTs February 2018
+
+
+5. LDP MRT FEC Advertisements
+
+ This sections describes how and when labels for MRT-Red and MRT-Blue
+ FECs are advertised. In order to provide protection paths that are
+ immediately usable by the point of local repair in the event of a
+ failure, the associated LSPs need to be created before a failure
+ occurs.
+
+ In this section, we will use the term "shortest-path FEC" to refer to
+ the usual FEC associated with the shortest-path destination-based
+ forwarding tree for a given prefix as determined by the IGP. We will
+ use the terms "red FEC" and "blue FEC" to refer to FECs associated
+ with the MRT-Red and MRT-Blue destination-based forwarding trees for
+ a given prefix as determined by a particular MRT algorithm.
+
+ We first describe label distribution behavior specific to MRT. Then,
+ we provide the correct interpretation of several important concepts
+ in [RFC5036] in the context of MRT FEC label distribution.
+
+ [RFC5036] specifies two different Label Distribution Control Modes
+ (Independent and Ordered), two different Label Retention Modes
+ (Conservative and Liberal), and two different Label Advertisement
+ Modes (Downstream Unsolicited and Downstream on Demand). The current
+ specification for LDP MRT requires that the same Label Distribution
+ Control, Label Retention, and Label Advertisement modes be used for
+ the shortest-path FECs and the MRT FECs.
+
+5.1. MRT-Specific Behavior
+
+5.1.1. ABR Behavior and Use of the Rainbow FEC
+
+ Section 10.1 of [RFC7812] describes the need for an ABR to have
+ different neighbors use different MPLS labels when sending traffic to
+ the ABR for the same FEC. The method to accomplish this using the
+ Rainbow MRT MT-ID is described in detail in [RFC7812]. Here we
+ provide a brief summary. To those LDP peers in the same area as the
+ best route to the destination, the ABR advertises two different
+ labels corresponding to the MRT-Red and MRT-Blue forwarding trees for
+ the destination. An LDP peer receiving these advertisements forwards
+ MRT traffic to the ABR using these two different labels, depending on
+ the FEC of the traffic. We refer to this as "best-area advertising
+ and forwarding behavior", which is identical to normal MRT behavior.
+
+ For all other LDP peers supporting MRT, the ABR advertises a FEC-
+ label binding for the FEC, which is in the Rainbow MRT MT-ID, with
+ the label that corresponds to that FEC in the default forwarding tree
+ for the destination. An LDP peer receiving this advertisement
+ forwards MRT traffic to the ABR using this label, for both MRT-Red
+
+
+
+Atlas, et al. Standards Track [Page 10]
+
+RFC 8320 LDP Extensions to Support MRTs February 2018
+
+
+ and MRT-Blue traffic. We refer to this as "non-best-area advertising
+ and forwarding behavior".
+
+ The use of the Rainbow-FEC by the ABR for non-best-area
+ advertisements is RECOMMENDED. An ABR MAY advertise the label for
+ the default topology in separate MRT-Blue and MRT-Red advertisements.
+ An LSR advertising the MRT Capability MUST recognize the Rainbow MRT
+ MT-ID and associate the advertised label with the specific prefix
+ with the MRT-Red and MRT-Blue MT-IDs associated with all MRT Profiles
+ that advertise LDP as the forwarding mechanism.
+
+ Due to changes in topology or configuration, an ABR and a given LDP
+ peer may need to transition from best-area advertising and forwarding
+ behavior to non-best-area behavior for a given destination, and vice
+ versa. When the ABR requires best-area behavior for a red(blue) FEC,
+ it MUST withdraw any existing label mappings advertisements for the
+ corresponding Rainbow FEC and advertise label mappings for the
+ red(blue) FEC. When the ABR requires non-best-area behavior for a
+ red(blue) FEC, it MUST withdraw any existing label mappings for both
+ red and blue FECs and advertise label mappings for the corresponding
+ Rainbow FEC label-binding.
+
+ In this transition, an ABR should never advertise a red(blue) FEC
+ before withdrawing the corresponding Rainbow FEC (or vice versa).
+ However, should this situation occur, the expected behavior of an LSR
+ receiving these conflicting advertisements is defined as follows:
+
+ - If an LSR receives a label mapping advertisement for a Rainbow FEC
+ from an MRT LDP peer while it still retains a label mapping for
+ the corresponding red or blue FEC, the LSR MUST continue to use
+ the label mapping for the red or blue FEC, and it MUST send a
+ Label Release message corresponding to the Rainbow FEC label
+ advertisement.
+
+ - If an LSR receives a label mapping advertisement for a red or blue
+ FEC while it still retains a label mapping for the corresponding
+ Rainbow FEC, the LSR MUST continue to use the label mapping for
+ the Rainbow FEC, and it MUST send a Label Release message
+ corresponding to the red or blue FEC label advertisement.
+
+5.1.2. Proxy-Node Attachment Router Behavior
+
+ Section 11.2 of [RFC7812] describes how MRT provides FRR protection
+ for multi-homed prefixes using calculations involving a named proxy-
+ node. This covers the scenario where a prefix is originated by a
+ router in the same area as the MRT Island, but outside of the MRT
+ Island. It also covers the scenario of a prefix being advertised by
+ multiple routers in the MRT Island.
+
+
+
+Atlas, et al. Standards Track [Page 11]
+
+RFC 8320 LDP Extensions to Support MRTs February 2018
+
+
+ In the named proxy-node calculation, each multi-homed prefix is
+ represented by a conceptual proxy-node that is attached to two real
+ proxy-node attachment routers. (A single proxy-node attachment
+ router is allowed in the case of a prefix advertised by a same area
+ router outside of the MRT Island, which is singly connected to the
+ MRT Island.) All routers in the MRT Island perform the same
+ calculations to determine the same two proxy-node attachment routers
+ for each multi-homed prefix. Section 5.9 of [RFC7811] describes the
+ procedure for identifying one proxy-node attachment router as "red"
+ and one as "blue" with respect to the multi-homed prefix, and
+ computing the MRT red and blue next hops to reach those red and blue
+ proxy-node attachment routers.
+
+ In terms of LDP behavior, a red proxy-node attachment router for a
+ given prefix MUST originate a label mapping for the red FEC for that
+ prefix, while the blue proxy-node attachment router for a given
+ prefix MUST originate a label mapping for the blue FEC for that
+ prefix. If the red(blue) proxy-node attachment router is an Island
+ Border Router (IBR), then when it receives a packet with the label
+ corresponding to the red(blue) FEC for a prefix, it MUST forward the
+ packet to the Island Neighbor (IN) whose cost was used in the
+ selection of the IBR as a proxy-node attachment router. The IBR MUST
+ swap the incoming label for the outgoing label corresponding to the
+ shortest-path FEC for the prefix advertised by the IN. In the case
+ where the IN does not support LDP, the IBR MUST pop the incoming
+ label and forward the packet to the IN.
+
+ If the proxy-node attachment router is not an IBR, then the packet
+ MUST be removed from the MRT forwarding topology and sent along the
+ interface(s) that caused the router to advertise the prefix. This
+ interface might be out of the area/level/AS.
+
+5.2. LDP Protocol Procedures in the Context of MRT Label Distribution
+
+ [RFC5036] specifies the LDP label distribution procedures for
+ shortest-path FECs. In general, the same procedures can be applied
+ to the distribution of label mappings for red and blue FECs, provided
+ that the procedures are interpreted in the context of MRT FEC label
+ distribution. The correct interpretation of several important
+ concepts in [RFC5036] in the context of MRT FEC label distribution is
+ provided below.
+
+5.2.1. LDP Peer in RFC 5036
+
+ In the context of distributing label mappings for red and blue FECs,
+ we restrict the LDP peer in [RFC5036] to mean LDP peers for which the
+ LDP MRT Capability has been negotiated. In order to make this
+ distinction clear, in this document we will use the term "MRT LDP
+
+
+
+Atlas, et al. Standards Track [Page 12]
+
+RFC 8320 LDP Extensions to Support MRTs February 2018
+
+
+ peer" to refer to an LDP peer for which the LDP MRT Capability has
+ been negotiated.
+
+5.2.2. Next Hop in RFC 5036
+
+ Several procedures in [RFC5036] use the next hop of a (shortest-path)
+ FEC to determine behavior. The next hop of the shortest-path FEC is
+ based on the shortest-path forwarding tree to the prefix associated
+ with the FEC. When the procedures of [RFC5036] are used to
+ distribute label mapping for red and blue FECs, the next hop for the
+ red(blue) FEC is based on the MRT-Red(Blue) forwarding tree to the
+ prefix associated with the FEC.
+
+ For example, Appendix A.1.7 of [RFC5036] specifies the response by an
+ LSR to a change in the next hop for a FEC. For a shortest-path FEC,
+ the next hop may change as the result of the LSR running a shortest-
+ path computation on a modified IGP topology database. For the red
+ and blue FECs, the red and blue next hops may change as the result of
+ the LSR running a particular MRT algorithm on a modified IGP topology
+ database.
+
+ As another example, Section 2.6.1.2 of [RFC5036] specifies that when
+ an LSR is using LSP Ordered Control, it may initiate the transmission
+ of a label mapping only for a (shortest-path) FEC for which it has a
+ label mapping for the FEC next hop, or for which the LSR is the
+ egress. The FEC next hop for a shortest-path FEC is based on the
+ shortest-path forwarding tree to the prefix associated with the FEC.
+ In the context of distributing MRT LDP labels, this procedure is
+ understood to mean the following. When an LSR is using LSP Ordered
+ Control, it may initiate the transmission of a label mapping only for
+ a red(blue) FEC for which it has a label mapping for the red(blue)
+ FEC next hop, or for which the LSR is the egress. The red or blue
+ FEC next hop is based on the MRT-Red or Blue forwarding tree to the
+ prefix associated with the FEC.
+
+5.2.3. Egress LSR in RFC 5036
+
+ Procedures in [RFC5036] related to Ordered Control label distribution
+ mode rely on whether or not an LSR may act as an egress LSR for a
+ particular FEC in order to determine whether or not the LSR may
+ originate a label mapping for that FEC. The status of being an
+ egress LSR for a particular FEC is also used in the loop detection
+ procedures described in [RFC5036]. Section 2.6.1.2 of [RFC5036]
+ specifies the conditions under which an LSR may act as an egress LSR
+ with respect to a particular (shortest-path) FEC:
+
+ 1. The (shortest-path) FEC refers to the LSR itself (including one
+ of its directly attached interfaces).
+
+
+
+Atlas, et al. Standards Track [Page 13]
+
+RFC 8320 LDP Extensions to Support MRTs February 2018
+
+
+ 2. The next hop router for the (shortest-path) FEC is outside of the
+ Label Switching Network.
+
+ 3. (Shortest-path) FEC elements are reachable by crossing a routing
+ domain boundary.
+
+ The conditions for determining an egress LSR with respect to a red or
+ blue FEC need to be modified. An LSR may act as an egress LSR with
+ respect to a particular red(blue) FEC under any of the following
+ conditions:
+
+ 1. The prefix associated with the red(blue) FEC refers to the LSR
+ itself (including one of its directly attached interfaces).
+
+ 2. The LSR is the red(blue) proxy-node attachment router with
+ respect to the multi-homed prefix associated with the red(blue)
+ FEC. This includes the degenerate case of a single red and blue
+ proxy-node attachment router for a single-homed prefix.
+
+ 3. The LSR is an ABR AND the MRT LDP peer requires non-best-area
+ advertising and forwarding behavior for the prefix associated
+ with the FEC.
+
+ Note that condition 3 scopes an LSR's status as an egress LSR with
+ respect to a particular FEC to a particular MRT LDP peer. Therefore,
+ the condition "Is LSR egress for FEC?" that occurs in several
+ procedures in [RFC5036] needs to be interpreted as "Is LSR egress for
+ FEC with respect to Peer?"
+
+ Also note that there is no explicit condition that allows an LSR to
+ be classified as an egress LSR with respect to a red or blue FEC
+ based only on the primary next hop for the shortest-path FEC not
+ supporting LDP or not supporting LDP MRT Capability. These
+ situations are covered by the proxy-node attachment router and ABR
+ conditions (conditions 2 and 3). In particular, an Island Border
+ Router is not the egress LSR for a red(blue) FEC unless it is also
+ the red(blue) proxy-node attachment router for that FEC.
+
+ Also note that, in general, a proxy-node attachment router for a
+ given prefix should not advertise an implicit or explicit null label
+ for the corresponding red or blue FEC, even though it may be an
+ egress LSR for the shortest-path FEC. In general, the proxy-node
+ attachment router needs to forward red or blue traffic for that
+ prefix to a particular loop-free island neighbor, which may be
+ different from the shortest-path next hop. The proxy-node attachment
+ router needs to receive the red or blue traffic with a non-null label
+ to correctly forward it.
+
+
+
+
+Atlas, et al. Standards Track [Page 14]
+
+RFC 8320 LDP Extensions to Support MRTs February 2018
+
+
+5.2.4. Use of Rainbow FEC to Satisfy Label Mapping Existence
+ Requirements in RFC 5036
+
+ Several procedures in [RFC5036] require the LSR to determine if it
+ has previously received and retained a label mapping for a FEC from
+ the next hop. In the case of an LSR that has received and retained a
+ label mapping for a Rainbow FEC from an ABR, the label mapping for
+ the Rainbow FEC satisfies the label mapping existence requirement for
+ the corresponding red and blue FECs. Label mapping existence
+ requirements in the context of MRT LDP label distribution are
+ modified as: "Has LSR previously received and retained a label
+ mapping for the red(blue) FEC (or the corresponding Rainbow FEC) from
+ the red(blue) next hop?"
+
+ As an example, this behavior allows an LSR that has received and
+ retained a label mapping for the Rainbow FEC to advertise label
+ mappings for the corresponding red and blue FECs when operating in
+ Ordered Control label distribution mode.
+
+5.2.5. Validating FECs in the Routing Table
+
+ In [RFC5036], an LSR uses its routing table to validate prefixes
+ associated with shortest-path FECs. For example, Section 3.5.7.1 of
+ [RFC5036] specifies that "an LSR receiving a Label Mapping message
+ from a downstream LSR for a Prefix SHOULD NOT use the label for
+ forwarding unless its routing table contains an entry that exactly
+ matches the FEC Element." In the context of MRT FECs, a red or blue
+ FEC element matches a routing table entry if the corresponding
+ shortest-path FEC element matches a routing table entry.
+
+5.2.6. Recognizing New FECs
+
+ Appendix A.1.6 of [RFC5036] describes the response of an LSR to the
+ "Recognize New FEC" event, which occurs when an LSR learns a new
+ (shortest-path) FEC via the routing table. In the context of MRT
+ FECs, if the MRT LDP Capability has been enabled, then when an LSR
+ learns a new shortest-path FEC, the LSR should generate "Recognize
+ New FEC" events for the corresponding Red and Blue FECS in addition
+ to the normally generated "Recognize New FEC" event for the shortest-
+ path FEC
+
+5.2.7. Not Propagating Rainbow FEC Label Mappings
+
+ A label mapping for the Rainbow FEC should only be originated by an
+ ABR under the conditions described in Section 5.1.1. A neighbor of
+ the ABR that receives a label mapping for the Rainbow FEC MUST NOT
+ propagate a label mapping for that Rainbow FEC.
+
+
+
+
+Atlas, et al. Standards Track [Page 15]
+
+RFC 8320 LDP Extensions to Support MRTs February 2018
+
+
+6. Security Considerations
+
+ The labels distributed by the extensions in this document create
+ additional forwarding paths that do not follow shortest-path routes.
+ The transit label swapping operations defining these alternative
+ forwarding paths are created during normal operations (before a
+ failure occurs). Therefore, a malicious packet with an appropriate
+ label injected into the network from a compromised location would be
+ forwarded to a destination along a non-shortest path. When this
+ technology is deployed, a network security design should not rely on
+ assumptions about potentially malicious traffic only following
+ shortest paths.
+
+ It should be noted that the creation of non-shortest forwarding paths
+ is not unique to MRT. For example, RSVP-TE [RFC3209] can be used to
+ construct forwarding paths that do not follow the shortest path.
+
+7. Potential Restrictions on MRT-Related MT-ID Values Imposed by
+ RFC 6420
+
+ As discussed in the introduction, in addition to unicast-forwarding
+ applications, MRT can be used to provide disjoint trees for multicast
+ traffic distribution. In the case of PIM, this is accomplished by
+ using the MRT red and blue next hops as the PIM Reverse Path
+ Forwarding (RPF) topology, the collection of routes used by PIM to
+ perform the RPF operation when building source trees. The PIM Multi-
+ Topology ID (MT-ID) Join Attribute defined in Section 5.2 of
+ [RFC6420] can be used to establish MRT-based multicast distribution
+ trees. [RFC6420] limits the values of the PIM MT-ID from 1 through
+ 4095.
+
+ For the purpose of reducing management overhead and simplifying
+ troubleshooting, it is desirable to be able to use the same numerical
+ value for the PIM MT-ID as for the MPLS MT-ID for multicast and
+ unicast applications using MRT routes constructed using the same MRT
+ Profile. In order to enable this simplification, the MPLS MT-ID
+ values assigned in this document fall in the range 1 through 4095.
+ The "MPLS Multi-Topology Identifiers" registry reflects this by
+ listing the values from 3948 through 3995 as for MRT-related MPLS
+ MT-ID values. This allows for 51 MRT-related MPLS MT-ID values that
+ can be directly mapped to PIM MT-ID values, which accommodates 25 MRT
+ Profiles with red and blue MT-ID pairs, with one extra for the
+ Rainbow MPLS MT-ID value. [RFC7307] designates the MT-ID range
+ 6-3995 as "Unassigned for future IGP topologies". As shown in the
+ IANA Considerations, the guidance for the range 3948-3995 has been
+ changed to "Unassigned (for future MRT-related values)".
+
+
+
+
+
+Atlas, et al. Standards Track [Page 16]
+
+RFC 8320 LDP Extensions to Support MRTs February 2018
+
+
+8. IANA Considerations
+
+ IANA has allocated a value for the new LDP Capability TLV from the
+ "Label Distribution Protocol (LDP) Parameters" registry under "TLV
+ Type Name Space": MRT Capability TLV (0x050E).
+
+ Value Description Reference Notes / Reg. Date
+ ------------- ------------------ ------------ -----------------
+ 0x050E MRT Capability TLV RFC 8320
+
+ IANA has allocated a value for the new LDP Status Code from the
+ "Label Distribution Protocol (LDP) Parameters" registry under "Status
+ Code Name Space": MRT Capability negotiated without MT Capability
+ (0x00000034). The Status Code E-bit is set to 0.
+
+ Value E Description Reference Notes / Reg. Date
+ ------------- - ------------------ ------------ -----------------
+ 0x00000034 0 MRT Capability RFC 8320
+ negotiated without
+ MT Capability
+
+ IANA has allocated three values from the "MPLS Multi-Topology
+ Identifiers" registry [RFC7307]:
+
+ 3945 Rainbow MRT MPLS MT-ID
+
+ 3946 Default Profile MRT-Red MPLS MT-ID
+
+ 3947 Default Profile MRT-Blue MPLS MT-ID
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Atlas, et al. Standards Track [Page 17]
+
+RFC 8320 LDP Extensions to Support MRTs February 2018
+
+
+ Also, IANA has changed the Purpose field of the "MPLS Multi-Topology
+ Identifiers" registry for MT-ID range 3948-3995 to "Unassigned (for
+ future MRT-related values)". The registration procedure for the
+ entire registry remains Standards Action [RFC8126]. The current
+ registry is shown below:
+
+ Value Purpose Reference
+ ------------ ---------------------- ------------
+ 0 Default/standard topology [RFC7307]
+ 1 IPv4 in-band management [RFC7307]
+ 2 IPv6 routing topology [RFC7307]
+ 3 IPv4 multicast topology [RFC7307]
+ 4 IPv6 multicast topology [RFC7307]
+ 5 IPv6 in-band management [RFC7307]
+ 6-3944 Unassigned (for future IGP topologies)
+ 3945 Rainbow MRT MPLS MT-ID RFC 8320
+ 3946 Default Profile MRT-Red MPLS MT-ID RFC 8320
+ 3947 Default Profile MRT-Blue MPLS MT-ID RFC 8320
+ 3948-3995 Unassigned (for future MRT-related values) RFC 8320
+ 3996-4095 Reserved for Experimental Use [RFC7307]
+ 4096-65534 Unassigned (for MPLS topologies)
+ 65535 Wildcard Topology [RFC7307]
+
+9. References
+
+9.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
+ "LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
+ October 2007, <https://www.rfc-editor.org/info/rfc5036>.
+
+ [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and
+ JL. Le Roux, "LDP Capabilities", RFC 5561,
+ DOI 10.17487/RFC5561, July 2009,
+ <https://www.rfc-editor.org/info/rfc5561>.
+
+ [RFC6420] Cai, Y. and H. Ou, "PIM Multi-Topology ID (MT-ID) Join
+ Attribute", RFC 6420, DOI 10.17487/RFC6420, November 2011,
+ <https://www.rfc-editor.org/info/rfc6420>.
+
+
+
+
+
+
+
+Atlas, et al. Standards Track [Page 18]
+
+RFC 8320 LDP Extensions to Support MRTs February 2018
+
+
+ [RFC7307] Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and
+ D. King, "LDP Extensions for Multi-Topology", RFC 7307,
+ DOI 10.17487/RFC7307, July 2014,
+ <https://www.rfc-editor.org/info/rfc7307>.
+
+ [RFC7811] Enyedi, G., Csaszar, A., Atlas, A., Bowers, C., and
+ A. Gopalan, "An Algorithm for Computing IP/LDP Fast
+ Reroute Using Maximally Redundant Trees (MRT-FRR)",
+ RFC 7811, DOI 10.17487/RFC7811, June 2016,
+ <https://www.rfc-editor.org/info/rfc7811>.
+
+ [RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for
+ IP/LDP Fast Reroute Using Maximally Redundant Trees
+ (MRT-FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016,
+ <https://www.rfc-editor.org/info/rfc7812>.
+
+ [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
+ Writing an IANA Considerations Section in RFCs", BCP 26,
+ RFC 8126, DOI 10.17487/RFC8126, June 2017,
+ <https://www.rfc-editor.org/info/rfc8126>.
+
+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+ 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+ May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+9.2. Informative References
+
+ [ARCH] Atlas, A., Kebler, R., Wijnands, IJ., Csaszar, A., and G.
+ Envedi, "An Architecture for Multicast Protection Using
+ Maximally Redundant Trees", Work in Progress,
+ draft-atlas-rtgwg-mrt-mc-arch-02, July 2013.
+
+ [IS-IS-MRT]
+ Li, Z., Wu, N., Zhao, Q., Atlas, A., Bowers, C., and
+ J. Tantsura, "Intermediate System to Intermediate System
+ (IS-IS) Extensions for Maximally Redundant Trees (MRTs)",
+ Work in Progress, draft-ietf-isis-mrt-03, June 2017.
+
+ [OSPF-MRT] Atlas, A., Hegde, S., Bowers, C., Tantsura, J., and Z. Li,
+ "OSPF Extensions to Support Maximally Redundant Trees",
+ Work in Progress, draft-ietf-ospf-mrt-03, June 2017.
+
+ [PARAM-SYNC]
+ Bryant, S., Atlas, A., and C. Bowers, "Routing Timer
+ Parameter Synchronization", Work in Progress,
+ draft-ietf-rtgwg-routing-timer-param-sync-00, October
+ 2017.
+
+
+
+
+Atlas, et al. Standards Track [Page 19]
+
+RFC 8320 LDP Extensions to Support MRTs February 2018
+
+
+ [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
+ and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
+ Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
+ <https://www.rfc-editor.org/info/rfc3209>.
+
+ [RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP
+ Synchronization", RFC 5443, DOI 10.17487/RFC5443, March
+ 2009, <https://www.rfc-editor.org/info/rfc5443>.
+
+ [RFC7715] Wijnands, IJ., Ed., Raza, K., Atlas, A., Tantsura, J., and
+ Q. Zhao, "Multipoint LDP (mLDP) Node Protection",
+ RFC 7715, DOI 10.17487/RFC7715, January 2016,
+ <https://www.rfc-editor.org/info/rfc7715>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Atlas, et al. Standards Track [Page 20]
+
+RFC 8320 LDP Extensions to Support MRTs February 2018
+
+
+Acknowledgements
+
+ The authors would like to thank Ross Callon, Loa Andersson, Stewart
+ Bryant, Mach Chen, Greg Mirsky, Uma Chunduri, and Tony Przygienda for
+ their comments and suggestions.
+
+Authors' Addresses
+
+ Alia Atlas
+ Juniper Networks
+ 10 Technology Park Drive
+ Westford, MA 01886
+ United States of America
+
+ Email: akatlas@juniper.net
+
+
+ Kishore Tiruveedhula
+ Juniper Networks
+ 10 Technology Park Drive
+ Westford, MA 01886
+ United States of America
+
+ Email: kishoret@juniper.net
+
+
+ Chris Bowers
+ Juniper Networks
+ 1194 N. Mathilda Ave.
+ Sunnyvale, CA 94089
+ United States of America
+
+ Email: cbowers@juniper.net
+
+
+ Jeff Tantsura
+ Individual
+ United States of America
+
+ Email: jefftant.ietf@gmail.com
+
+
+ IJsbrand Wijnands
+ Cisco Systems, Inc.
+
+ Email: ice@cisco.com
+
+
+
+
+
+Atlas, et al. Standards Track [Page 21]
+