| MPLS Working Group | A. Atlas |
| Internet-Draft | K. Tiruveedhula |
| Intended status: Standards Track | C. Bowers |
| Expires: August 21, 2017 | Juniper Networks |
| J. Tantsura | |
| Individual | |
| IJ. Wijnands | |
| Cisco Systems, Inc. | |
| February 17, 2017 |
LDP Extensions to Support Maximally Redundant Trees
draft-ietf-mpls-ldp-mrt-05
This document specifies extensions to the Label Distribution Protocol(LDP) to support the creation of label-switched paths for Maximally Redundant Trees (MRT). 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 LSRs (Label Switching Routers) and LERs (Label Edge Routers) advertising the MRT Capability.
MRT-FRR uses LDP multi-topology extensions and requires three different multi-topology IDs to be allocated from the MPLS MT-ID space.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 21, 2017.
Copyright (c) 2017 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 (http://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.
This document describes the LDP signaling extension and associated behavior necessary to support the architecture that defines how IP/LDP Fast-Reroute can use MRTs [RFC7812]. It is necessary to be familiar with the architecture in [RFC7812] to understand how and why the LDP extensions for behavior are needed.
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 [I-D.ietf-ospf-mrt]. Extension to IS-IS are defined in [I-D.ietf-isis-mrt].
MRT can also be used to protect multicast traffic (signalled via PIM or mLDP) using either global protection or local protection as described in [I-D.atlas-rtgwg-mrt-mc-arch]. An MRT path can be used to provide node-protection for mLDP traffic via the mechanisms described in [I-D.wijnands-mpls-mldp-node-protection]; 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 Section 7 of [I-D.ietf-ospf-mrt].
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.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]
For ease of reading, some of the terminology defined in [RFC7812] is repeated here.
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.
A new MRT Capability Parameter TLV is defined in accordance with 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 procedures for establishing the MRT-Blue and MRT-Red LSP paths 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 (IANA) | Length (= 1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| Reserved | +-+-+-+-+-+-+-+-+
MRT Capability TLV Format
Where:
An LSR advertising the LDP MRT Capability MUST also advertise the LDP Multi-topology (MT) capability. If an LSR negotiates LDP MRT Capability with an LDP neighbor without also negotiating the LDP MT Capability, the LSR MUST behave as if LDP MRT Capability has not been negotiated and respond with the "MRT Capability negotiated without MT Capability" status code in the LDP Notification message (defined in 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.
The MRT LDP Capability Advertisement does not distinguish between IPv4 and IPv6 address families. An LSR which 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.
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 of the current document.
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 (TBD-MRT-LDP-3) will be assigned by IANA from the MPLS MT-ID space.
To provide MRT support in LDP, the MT Prefix FEC is used. [RFC7812] defines the Default MRT Profile. Section 8 of this document specifies code points for the MRT-Red and MRT-Blue MPLS MT-IDs associated with the Default MRT Profile (TBD-MRT-LDP-4 and TBD-MRT-LDP-5).
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.
This sections describes how and when labels for MRT-Red and MRT-Blue FECs are advertised. The associated LSPs must be created before a failure occurs, in order to provide protection paths which are immediately usable by the point of local repair in the event of a failure.
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.
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. 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 Rainbow MRT MT-ID scoped FEC with the label corresponding to 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 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 corrsponding rainbow FEC (or vice versa). However, should this situation occur, the expected behavior of an LSR receiving these conflicting advertisements is defined as foll 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 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.
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 a multiple routers in the MRT Island.
In the named proxy-node calculation, each multi-homed prefix is represented by a conceptual proxy-node which 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. [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 a 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.
[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.
In the context of distributing label mappings for red and blue FECs, we restrict 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 peer" to refer to an LDP peer for which the LDP MRT capability has been negotiated.
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 how 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.
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 loop detection procedures 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.
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:
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 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.
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 which 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.
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.
Section 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, when MRT LDP capability has been enabled, when an LSR learns a new shortest path FEC, it should generate "Recognize New FEC" events for the corresponding red and blue FECs, in addition to the "Recognize New FEC" event for the shortest path FEC.
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.
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.
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 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 application using MRT routes constructed using the same MRT profile. In order to enable this simplification, the MPLS MT-ID values assigned in this document need to fall in the range 1 through 4095. The IANA request below reflects this by requesting that the MPLS MT-ID values from 3945 through 3995 be used for MRT-related MPLS MT-ID values. This allows for 51 MRT-related MPLS MT-ID values which 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 MPLS MT-ID range 6-3995 as "Unassigned(for future IGP topologies)". The IANA request below changes the guidance for MT-ID range 3948-3995 to "Unassigned (for future MRT-related values)".
IANA is requested to allocate a value for the new LDP Capability TLV (the first free value in the range 0x0500 to 0x05FF) from the Label Distribution Protocol (LDP) Parameters registry "TLV Type Name Space": MRT Capability TLV (TBD-MRT-LDP-1).
Value Description Reference Notes / Reg. Date ------------- ------------------ ------------ ----------------- TBD-MRT-LDP-1 MRT Capability TLV [This draft]
IANA is requested to allocate a value for the new LDP Status Code (the first free value in the range 0x00000032-0x00000036) from the Label Distribution Protocol (LDP) Parameters registry "Status Code Name Space": "MRT Capability negotiated without MT Capability" (TBD-MRT-LDP-2). The Status Code E-bit is set to 0.
Value E Description Reference Notes / Reg. Date
-------------- - ------------------ ------------ -----------------
TBD-MRT-LDP-2 0 MRT Capability [This draft]
negotiated without
MT Capability
IANA is requested to allocate three values from the MPLS Multi-Topology Identifiers Registry [RFC7307].
IANA is also requested to change the purpose field of the MPLS Multi-Topology Identifiers Registry for MT-ID range 3948-3995 to "Unassigned (for future MRT-related values)", assuming the above suggested values are assigned. The Registration procedure for the entire registry remains "Standards Action". The entire registry after implementing the above requests 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) TBD-MRT-LDP-3 Rainbow MRT MPLS MT-ID [This draft] TBD-MRT-LDP-4 Default Profile MRT-Red MPLS MT-ID [This draft] TBD-MRT-LDP-5 Default Profile MRT-Blue MPLS MT-ID [This draft] 3948-3995 Unassigned (for future MRT-related values) [This draft] 3996-4095 Reserved for Experimental Use [RFC7307] 4096-65534 Unassigned (for MPLS topologies) 65535 Wildcard Topology [RFC7307]
The authors would like to thank Ross Callon, Loa Andersson, Stewart Bryant, Mach Chen, Greg Mirsky, and Uma Chunduri for their comments and suggestions.
| [RFC5036] | Andersson, L., Minei, I. and B. Thomas, "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007. |
| [RFC5561] | Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R. and JL. Le Roux, "LDP Capabilities", RFC 5561, DOI 10.17487/RFC5561, July 2009. |
| [RFC6420] | Cai, Y. and H. Ou, "PIM Multi-Topology ID (MT-ID) Join Attribute", RFC 6420, DOI 10.17487/RFC6420, November 2011. |
| [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. |
| [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. |
| [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. |