RFC 7032
LDP Downstream-on-Demand in Seamless MPLS
RFC 7032: LDP Downstream-on-Demand in Seamless MPLS 🦋
Okay bestie, let's get the basics out of the way first 💅. This is an Internet Standards Track document, which means it's a real spec that implementers have to follow. It came out in October 2013 with ISSN 2070-1721. The editors are T. Beckhaus (Ed.) from Deutsche Telekom AG and M. Konstantynowicz (Ed.) from Cisco Systems, Inc. The other authors are B. Decraene from Orange, K. Tiruveedhula from Juniper Networks, and L. Martini from Cisco Systems, Inc. The title block doesn't list anything it obsoletes or updates, so it doesn't mess with any earlier RFCs 🎀.
Abstract ✨
Okay so Seamless MPLS is giving "one network to rule them all" 👑. A single IP/MPLS network can scale across the core, metro, and access parts of a big packet network, all using standardized IP/MPLS protocols. A huge goal here is handling the access network's needs, like a ton of devices, where each device sits in the topology, and the fact that access devices don't have a lot of compute or memory to hold state 🥺. The fix is LDP Downstream-on-Demand (DoD) label advertisement. This doc covers the LDP DoD use cases and lists the LDP DoD procedures it needs in the Seamless MPLS context 💖.
It also defines a brand-new optional TLV type in the LDP Label Request message for fast-up convergence ⚡.
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 went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check out Section 2 of RFC 5741 🌸.
You can find the current status of this document, any errata, and how to send feedback at http://www.rfc-editor.org/info/rfc7032.
Copyright Notice 🧚
Copyright (c) 2013 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) as they are in effect on the date this document was published. Please read these documents carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License.
Table of Contents 🍓
1. Introduction ....................................................4
2. Reference Topologies ............................................6
2.1. Access Topologies with Static Routing ......................6
2.2. Access Topologies with Access IGP .........................10
3. LDP DoD Use Cases ..............................................11
3.1. Initial Network Setup .....................................12
3.1.1. AN with Static Routing .............................12
3.1.2. AN with Access IGP .................................13
3.2. Service Provisioning and Activation .......................14
3.3. Service Changes and Decommissioning .......................16
3.4. Service Failure ...........................................17
3.5. Network Transport Failure .................................17
3.5.1. General Notes ......................................17
3.5.2. AN Failure .........................................18
3.5.3. AN/AGN Link Failure ................................19
3.5.4. AGN Failure ........................................20
3.5.5. AGN Network-Side Reachability Failure ..............20
4. LDP DoD Procedures .............................................20
4.1. LDP Label Distribution Control and Retention Modes ........21
4.2. LDP DoD Session Negotiation ...............................23
4.3. Label Request Procedures ..................................23
4.3.1. Access LSR/ABR Label Request .......................23
4.3.2. Label Request Retry ................................24
4.4. Label Withdraw ............................................25
4.5. Label Release .............................................26
4.6. Local-Repair ..............................................27
5. LDP Extension for LDP DoD Fast-Up Convergence ..................27
6. IANA Considerations ............................................29
6.1. LDP TLV Type ..............................................29
7. Security Considerations ........................................29
7.1. LDP DoD Native Security Properties ........................30
7.2. Data-Plane Security .......................................31
7.3. Control-Plane Security ....................................31
8. Acknowledgements ...............................................32
9. References .....................................................33
9.1. Normative References ......................................33
9.2. Informative References ....................................331. Introduction 💅
Seamless MPLS design [SEAMLESS-MPLS] lets a single IP/MPLS network scale across the core, metro, and access parts of a large packet network infrastructure, using standardized IP/MPLS protocols. One of its big goals is meeting the requirements specific to access, like a high number of devices, where each device sits in the topology, and compute and memory limits that cap how much state access devices can hold 🫶.
Generally, MPLS Label Switching Routers (LSRs) use either LDP or RSVP for MPLS label distribution 🔥.
This doc focuses on LDP, because Seamless MPLS design doesn't need general-purpose explicit traffic engineering or bandwidth reservation. It only looks at unicast connectivity. Multicast connectivity is saved for further study 🌈.
In Seamless MPLS design [SEAMLESS-MPLS], IP/MPLS protocol optimization is possible because the access network topologies are relatively simple ✨. Some examples of these topologies, which include access nodes (ANs) and aggregation nodes (AGNs), are:
a. A single AN homed to a single AGN.
b. A single AN dual-homed to two AGNs.
c. Multiple ANs daisy-chained via a hub-AN to a single AGN.
d. Multiple ANs daisy-chained via a hub-AN to two AGNs.
e. Two ANs dual-homed to two AGNs.
f. Multiple ANs chained in a ring and dual-homed to two AGNs.
In all of these topologies, the amount of IP Routing Information Base (RIB) and Forwarding Information Base (FIB) state on ANs is easy to control with simple IP routing config, using either static routes or a dedicated access IGP 🎀. Notice that AGNs act as the access area border routers (access ABRs) that connect the access topology to the rest of the network in every one of these cases. So in lots of situations, it's enough for ANs to have a default route pointing toward the AGNs to get full network connectivity 🦋.
The MPLS forwarding state is a different story and needs more thought 🙈. MPLS routers usually use LDP Downstream Unsolicited (LDP DU) label advertisements [RFC5036] and advertise MPLS labels for every valid route in their RIB tables. For ANs, that's inadequate, because they only need a small subset of the total routes (and their labels), based on the connectivity the provisioned services require. You can apply filters to those LDP DU label advertisements, but filters aren't a good tool for enabling any-to-any AN-driven connectivity between the access and the rest of the MPLS network 😭.
This document describes an AN-driven "subscription model" for label distribution in the access network 💜. The approach uses the standard LDP DoD label advertisements specified in [RFC5036]. LDP DoD makes label distribution on-demand, so only the labels that are needed get requested, provided, and installed ✨. The procedures in this document apply equally to the LDP IPv4 and IPv6 address families. For simplicity, the examples use the LDP IPv4 address family 🧚.
The next sections describe a set of reference access topologies considered for LDP DoD usage, along with their IP routing configurations. After that come the LDP DoD use cases and LDP DoD procedures in the context of Seamless MPLS design 💖.
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] 🔥.
2. Reference Topologies 🌸
LDP DoD use cases are described in the context of a generic reference end-to-end network topology based on Seamless MPLS design [SEAMLESS-MPLS], as shown in Figure 1 👑.
+-------+ +-------+ +------+ +------+
---+ AGN11 +--+ AGN21 +--+ ABR1 +--+ LSR1 +--> to LSR/AGN
+--------+/ +-------+ +-------+ +------+ +------+
| Access | \/ \/
| Network| /\ /\
+--------+ +-------+ +-------+ +------+ +------+
\---+ AGN12 +--+ AGN22 +--+ ABR2 +--+ LSR2 +--> to LSR/AGN
+-------+ +-------+ +------+ +------+
static routes
or access IGP IGP area IGP area
<----Access----><--Aggregation Domain--><----Core----->
<------------------------- MPLS ---------------------->Figure 1: Seamless MPLS End-to-End Reference Network Topology
The access network is either single- or dual-homed to AGN1x, with either a single parallel link or multiple parallel links to AGN1x 🦋.
Seamless MPLS access network topologies can go from a single- or dual-homed access node all the way to a chain or ring of access nodes. They can use either static routing or an access IGP (IS-IS or OSPF) 💅. The following sections walk through these reference access topologies in more detail 🫶.
2.1. Access Topologies with Static Routing ✨
Okay so, most of the time access nodes hook up to the rest of the network using really simple topologies 🎀. Static routing is enough for them to get the IP connectivity they need 💖. These are the topologies that work with static routing and LDP DoD:
a. [I1] topology - a single AN homed to a single AGN.
b. [I] topology - multiple ANs daisy-chained to a single AGN.
c. [V] topology - a single AN dual-homed to two AGNs.
d. [U2] topology - two ANs dual-homed to two AGNs.
e. [Y] topology - multiple ANs daisy-chained to two AGNs.
The reference static routing and LDP configuration for the [V] access topology is shown in Figure 2 🦋. The same static routing and LDP configuration also works for the [I1] topology, so it's giving double value 👑.
+----+ +-------+
|AN1 +------------------------+ AGN11 +-------
| +-------\ /-----------+ +-\ /
+----+ \ / +-------+ \ /
\/ \/
/\ /\
+----+ / \ +-------+ / \
|AN2 +-------/ \-----------+ AGN12 +-/ \
| +------------------------+ +-------
+----+ +-------+
--(u)-> <-(d)--
<----- static routing -------> <------ IGP ------>
<---- LDP DU ----->
<--------- LDP DoD ----------> <-- labeled BGP -->
(u) static routes: 0/0 default, (optional) /32 routes
(d) static routes: AN loopbacks
Figure 2: [V] Access Topology with Static RoutesIn line with the Seamless MPLS design, static routes configured on AGN1x that point towards the access network get redistributed into either IGP or BGP labeled IP routes [RFC3107] 🌸.
The reference static routing and LDP configuration for the [U2] access topology is shown in Figure 3 🧚.
+----+ +-------+
(d1) |AN1 +------------------------+ AGN11 +-------
| | + + +-\ /
v +-+--+ +-------+ \ /
| \/
| /\
^ +-+--+ +-------+ / \
| |AN2 + + AGN12 +-/ \
(d2) | +------------------------+ +-------
+----+ +-------+
--(u)-> <-(d)--
<----- static routing -------> <------ IGP ------>
<---- LDP DU ----->
<--------- LDP DoD ----------> <-- labeled BGP -->
(u) static route 0/0 default, (optional) /32 routes
(d) static route for AN loopbacks
(d1) static route for AN2 loopback and 0/0 default with
lower preference
(d2) static route for AN1 loopback and 0/0 default with
lower preference
Figure 3: [U2] Access Topology with Static RoutesThe reference static routing and LDP configuration for the [Y] access topology is shown in Figure 4 💜. The same static routing and LDP configuration also applies to the [I] topology too 🍓.
+-------+
| |---/
/----+ AGN11 |
+----+ +----+ +----+ / | |---\
| | | | | +----/ +-------+
|ANn +...|AN2 +---+AN1 |
| | | | | +----\ +-------+
+----+ +----+ +----+ \ | |---/
\----+ AGN12 |
<-(d2)-- <-(d1)-- | |---\
--(u)-> --(u)-> --(u)-> +-------+
<-(d)--
<------- static routing --------> <------ IGP ------>
<---- LDP DU ----->
<----------- LDP DoD -----------> <-- labeled BGP -->
(u) static routes: 0/0 default, (optional) /32 routes
(d) static routes: AN loopbacks [1..n]
(d1) static routes: AN loopbacks [2..n]
(d2) static routes: AN loopbacks [3..n]
Figure 4: [Y] Access Topology with Static RoutesNote that in all of the above topologies, parallel Equal-Cost Multipath (ECMP) (or Layer 2 Link Aggregation Group (L2 LAG)) links can be used between the nodes 🔥.
ANs support Inter-area LDP [RFC5283] so they can use the IP default route to match the LDP Forwarding Equivalence Class (FEC) advertised by AGN1x and other ANs ✨.
2.2. Access Topologies with Access IGP
A dedicated access IGP instance is used in the access network to handle the internal routing between AGN1x and connected AN devices 🌈. Examples of such an IGP could be IS-IS, OSPFv2 and v3, or RIPv2 and RIPng. This access IGP instance is separate from the IGP of the aggregation domain, so they don't mix 🫶.
The following topologies are considered for use with access IGP routing and LDP DoD:
a. [U] topology - multiple ANs chained in an open ring and dual-homed to two AGNs.
b. [Y] topology - multiple ANs daisy-chained via a hub-AN to two AGNs.
The reference access IGP and LDP configuration for the [U] access topology is shown in Figure 5 💅.
+-------+
+-----+ +-----+ +----+ | +---/
| AN3 |---| AN2 |---|AN1 +-----+ AGN11 |
+-----+ +-----+ +----+ | +---\
. +-------+
.
. +-------+
+-----+ +-----+ +----+ | +---/
|ANn-2|---|ANn-1|---|ANn +-----+ AGN12 |
+-----+ +-----+ +----+ | +---\
+-------+
<---------- access IGP ------------> <------ IGP ------>
<---- LDP DU ----->
<------------ LDP DoD -------------> <-- labeled BGP -->
Figure 5: [U] Access Topology with Access IGPThe reference access IGP and LDP configuration for the [Y] access topology is shown in Figure 6 🦋.
+-------+
| |---/
/----+ AGN11 |2
+----+ +----+ +----+ / | |---\
| | | | | +----/ +-------+
|ANn +...|AN2 +---+AN1 |
| | | | | +----\ +-------+
+----+ +----+ +----+ \ | |---/
\----+ AGN12 |
| |---\
+-------+
<---------- access IGP ------------> <------ IGP ------>
<---- LDP DU ----->
<------------ LDP DoD -------------> <-- labeled BGP -->
Figure 6: [Y] Access Topology with Access IGPNote that in all of the above topologies, parallel ECMP (or L2 LAG) links can be used between the nodes 💖.
In both of the above topologies, ANs (ANn ... AN1) and AGN1x share the access IGP and advertise their IPv4 and IPv6 loopbacks and link addresses 🌸. AGN1x advertises a default route into the access IGP 🧚.
ANs support Inter-area LDP [RFC5283] so they can use the IP default route for matching the LDP FECs advertised by AGN1x or other ANs 👑.
3. LDP DoD Use Cases ✨
The LDP DoD use cases described in this document are based on the Seamless MPLS scenarios listed in Seamless MPLS design [SEAMLESS-MPLS] 🎀. This section illustrates these use cases, focusing on services provisioned on the access nodes, and clarifies the expected LDP DoD operation on the AN and AGN1x devices 💜. Two representative service types are used to illustrate the use cases: MPLS Pseudowire Edge-to-Edge (PWE3) [RFC4447] and BGP/MPLS IP VPN [RFC4364] 🍓.
The LDP DoD operations described here apply equally to all of the reference access topologies described in Section 2. Operations that are specific to certain access topologies are called out explicitly 🔥.
References to upstream and downstream nodes are made in line with the definition of upstream and downstream LSRs [RFC3031] 🌈.
3.1. Initial Network Setup
An access node is commissioned without any services provisioned on it 🫶. The AN can request labels for loopback addresses of any AN, AGN, or other nodes within the Seamless MPLS network, for operational and management purposes 💅. It is assumed that AGN1x has the required IP/MPLS configuration for network-side connectivity, in line with Seamless MPLS design [SEAMLESS-MPLS] 🦋.
LDP sessions are configured between adjacent ANs and AGN1x using their respective loopback addresses 💖.
3.1.1. AN with Static Routing
okay bestie, so if access static routing is in use, the ANs get set up with these static IP routing entries 🎀 (the topology references from Section 2 are in square brackets, so you can follow the breadcrumbs ✨):
a. [I1, V, U2] - Static default route 0/0 pointing to links connected to AGN1x. Requires support for Inter-area LDP [RFC5283].
b. [U2] - Static /32 routes pointing to the other AN. Lower preference static default route 0/0 pointing to links connected to the other AN. Requires support for Inter-area LDP [RFC5283].
c. [I, Y] - Static default route 0/0 pointing to links leading towards AGN1x. Requires support for Inter-area LDP [RFC5283].
d. [I, Y] - Static /32 routes to all ANs in the daisy-chain pointing to links towards those ANs.
e. [I1, V, U2] - Optional - Static /32 routes for specific nodes within the Seamless MPLS network, pointing to links connected to AGN1x.
f. [I, Y] - Optional - Static /32 routes for specific nodes within the Seamless MPLS network, pointing to links leading towards AGN1x.
The upstream AN/AGN1x requests labels over an LDP DoD session(s) from downstream AN/AGN1x for configured static routes 🧚 if those static routes are configured with an LDP DoD request policy and if they are pointing to a next hop selected by routing. It is expected that all configured /32 static routes to be used for LDP DoD are configured with such a policy on an AN/AGN1x. Main character rules, honestly 💅
The downstream AN/AGN1x responds to the Label Request from the upstream AN/AGN1x with a label mapping if the requested route is present in its RIB and there is a valid label binding from its downstream neighbor, or if it is the egress node. In such a case, the downstream AN/AGN1x installs the advertised label as an incoming label in its label information base (LIB) and its label forwarding information base (LFIB). The upstream AN/AGN1x also installs the received label as an outgoing label in its LIB and LFIB. If the downstream AN/AGN1x does have the route present in its RIB, but does not have a valid label binding from its downstream neighbor, it forwards the request to its downstream neighbor. Passing the baton, iykyk 🫶
In order to facilitate ECMP and IP Fast Reroute (IPFRR) Loop-Free Alternate (LFA) local-repair [RFC5286], the upstream AN/AGN1x also sends LDP DoD Label Requests to alternate next hops per its RIB, and installs received labels as alternate entries in its LIB and LFIB. Backup plans are literally everything 😭🌈
The AGN1x on the network side can use BGP labeled IP routes [RFC3107] in line with the Seamless MPLS design [SEAMLESS-MPLS]. In such a case, AGN1x will redistribute its static routes pointing to local ANs into BGP labeled IP routes to facilitate network-to-access traffic flows. Likewise, to facilitate access-to-network traffic flows, AGN1x will respond to access-originated LDP DoD Label Requests with label mappings based on its BGP labeled IP routes reachability for requested FECs. Two-way traffic, the way that's iconic 💜
3.1.2. AN with Access IGP
okay so if access IGP is used, an AN(s) advertises its loopbacks over the access IGP with configured metrics 🌸 and the AGN1x advertises a default route over the access IGP. Simple, clean, no drama.
Routers request labels over LDP DoD session(s) according to their needs for MPLS connectivity (via Label Switching Paths (LSPs)) ✨. In particular, if AGNs, as per Seamless MPLS design [SEAMLESS-MPLS], redistribute routes from the IGP into BGP labeled IP routes [RFC3107], they request labels over LDP DoD session(s) for those routes. They're literally asking for what they need, that's so iconic 👑
Identical to the static route case, the downstream AN/AGN1x responds to the Label Request from the upstream AN/AGN1x with a label mapping (if the requested route is present in its RIB and there is a valid label binding from its downstream neighbor), and installs the advertised label as an incoming label in its LIB and LFIB. The upstream AN/AGN1x also installs the received label as an outgoing label in its LIB and LFIB. Same energy as the static case, no notes 🍓
Identical to the static route case, in order to facilitate ECMP and IPFRR LFA local-repair, the upstream AN/AGN1x also sends LDP DoD Label Requests to alternate next hops per its RIB, and it installs received labels as alternate entries in its LIB and LFIB. Redundancy is giving security blanket 🦋
The AGN1x on the network side can use labeled BGP [RFC3107] in line with Seamless MPLS design [SEAMLESS-MPLS]. In such a case, AGN1x will redistribute routes received over the access IGP (and pointing to local ANs) into BGP labeled IP routes to facilitate network-to-access traffic flows. Likewise, to facilitate access-to-network traffic flows, the AGN1x will respond to access-originated LDP DoD Label Requests with label mappings based on its BGP labeled IP routes reachability for requested FECs. Bidirectional slay, periodt 💖
3.2. Service Provisioning and Activation
okay so following the initial setup phase described in Section 3.1, a specific access node, referred to as AN*, gets provisioned with a network service 🧚♀️ AN* relies on LDP DoD to request the required MPLS LSP(s) label(s) from the downstream AN/AGN1x node(s). Note that LDP DoD operations are service agnostic; that is, they are the same independently of the services provisioned on the AN*. Serving consistency, no matter what service it is 💅
For illustration purposes, two service types are described: MPLS PWE3 [RFC4447] service and BGP/MPLS IPVPN [RFC4364].
MPLS PWE3 service: For description simplicity, it is assumed that a single segment pseudowire is signaled using targeted LDP (tLDP) FEC128 (0x80), and it is provisioned with the pseudowire ID and the loopback IPv4 address of the destination node. The following IP/MPLS operations need to be completed on the AN* to successfully establish such PWE3 service:
a. LSP labels for destination /32 FEC (outgoing label) and the local /32 loopback (incoming label) need to be signaled using LDP DoD.
b. A tLDP session over an associated TCP/IP connection needs to be established to the PWE3 destination Provider Edge (PE). This is triggered either by an explicit tLDP session configuration on the AN* or automatically at the time of provisioning the PWE3 instance.
c. Local and remote PWE3 labels for specific FEC128 PW ID need to be signaled using tLDP and PWE3 signaling procedures [RFC4447].
d. Upon successful completion of the above operations, AN* programs its RIB/LIB and LFIB tables and activates the MPLS PWE3 service. Glow-up complete ✨
Note: Only minimum operations applicable to service connectivity have been listed. Other non-IP/non-MPLS connectivity operations that are required for successful service provisioning and activation are out of scope in this document.
BGP/MPLS IPVPN service: For description simplicity, it is assumed that the AN* is provisioned with a unicast IPv4 IPVPN service (VPNv4 for short) [RFC4364]. The following IP/MPLS operations need to be completed on the AN* to successfully establish VPNv4 service:
a. BGP peering sessions with associated TCP/IP connections need to be established with the remote destination VPNv4 PEs or Route Reflectors.
b. Based on configured BGP policies, VPNv4 BGP Network Layer Reachability Information (NLRI) needs to be exchanged between AN* and its BGP peers.
c. Based on configured BGP policies, VPNv4 routes need to be installed in the AN* VPN Routing and Forwarding (VRF) RIB and FIB, with corresponding BGP next hops.
d. LSP labels for destination BGP next-hop /32 FEC (outgoing label) and the local /32 loopback (incoming label) need to be signaled using LDP DoD.
e. Upon successful completion of above operations, AN* programs its RIB/LIB and LFIB tables, and activates the BGP/MPLS IPVPN service. Served 🍰
Note: Only minimum operations applicable to service connectivity have been listed. Other non-IP/-MPLS connectivity operations that are required for successful service provisioning are out of scope in this document.
To establish an LSP for destination /32 FEC for any of the above services, AN* looks up its local routing table for a matching route and selects the best next hop(s) and associated outgoing link(s). Route hunting, but make it cute 🔍
If a label for this /32 FEC is not already installed based on the configured static route with LDP DoD request policy or access IGP RIB entry, AN* sends an LDP DoD label mapping request. A downstream AN/AGN1x LSR(s) checks its RIB for presence of the requested /32 and associated valid outgoing label binding, and if both are present, replies with its label for this FEC and installs this label as incoming in its LIB and LFIB. Upon receiving the label mapping, the AN* accepts this label based on the exact route match of the advertised FEC and route entry in its RIB or based on the longest match in line with Inter-area LDP [RFC5283]. If the AN* accepts the label, it installs it as an outgoing label in its LIB and LFIB. Label handshake, bestie 🤝
In access topologies [V] and [Y], if AN* is dual-homed to two AGN1x and routing entries for these AGN1x's are configured as equal-cost paths, AN* sends LDP DoD Label Requests to both AGN1x devices and installs all received labels in its LIB and LFIB. Double the backup, double the vibes 👯♀️
In order for AN* to implement IPFRR LFA local-repair, AN* also sends LDP DoD Label Requests to alternate next hops per its RIB, and installs received labels as alternate entries in its LIB and LFIB. Plan B is always ready 🫶
When forwarding PWE3 or VPNv4 packets, AN* chooses the LSP label based on the locally configured static /32 or default route or default route signaled via access IGP. If a route is reachable via multiple interfaces to AGN1x nodes and the route has multiple equal-cost paths, AN* implements ECMP functionality. This involves AN* using a hash-based load-balancing mechanism and sending the PWE3 or VPNv4 packets in a flow-aware manner with appropriate LSP labels via all equal-cost links. Spreading the load so nothing gets overwhelmed 💅
The ECMP mechanism is applicable in an equal manner to parallel links between two network elements and multiple paths towards the destination. The traffic demand is distributed over the available paths. Fair share, no favourites 🌈
The AGN1x on the network side can use labeled BGP [RFC3107] in line with Seamless MPLS design [SEAMLESS-MPLS]. In such a case, the AGN1x will redistribute its static routes (or routes received from the access IGP) pointing to local ANs into BGP labeled IP routes to facilitate network-to-access traffic flows. Likewise, to facilitate access-to-network traffic flows, the AGN1x will respond to access-originated LDP DoD Label Requests with label mappings based on its BGP labeled IP routes reachability for requested FECs. 🦋
3.3. Service Changes and Decommissioning 🧹
Whenever the AN* service gets decommissioned or changed and connectivity to a specific destination is no longer required, the associated MPLS LSP label resources are to be released on AN*. 💅
MPLS PWE3 service: If the PWE3 service gets decommissioned and it is the last PWE3 to a specific destination node, the tLDP session is no longer needed and is to be terminated (automatically or by configuration). The MPLS LSP(s) to that destination is no longer needed either. 🦋
BGP/MPLS IPVPN service: Deletion of a specific VPNv4 (VRF) instance via local or remote reconfiguration can result in a specific BGP next hop(s) no longer being needed. The MPLS LSP(s) to that destination is no longer needed either. 🌸
In all of the above cases, the following operations related to LDP DoD apply: ✨
- If the
/32FEC label for the aforementioned destination node was originally requested based on either tLDP session configuration and default route or required BGP next hop and default route, AN* deletes the label from its LIB and LFIB, and releases it from the downstream AN/AGN1x by using LDP DoD procedures. 💖 - If the
/32FEC label was originally requested based on the static/32route configuration with LDP DoD request policy, the label is retained by AN*. 🫶
3.4. Service Failure 💀
A service instance can stop being operational due to a local or remote service failure event. 😭
In general, unless the service failure event modifies required MPLS connectivity, there is no impact on the LDP DoD operation. Totally chill. 🌈
If the service failure event does modify the required MPLS connectivity, LDP DoD operations apply as described in Sections 3.2 and 3.3. 🔥
3.5. Network Transport Failure 🌪️
A number of different network events can impact services on AN*. The following sections describe network event types that impact LDP DoD operation on AN and AGN1x nodes. Buckle up, bestie. 🎢
3.5.1. General Notes 📝
If service on any of the ANs is affected by any network failure and there is no network redundancy, the service goes into a failure state. Upon recovery from network failure, the service is to be re-established automatically. ✨
The following additional LDP-related functions need to be supported to comply with Seamless MPLS [SEAMLESS-MPLS] fast service restoration requirements: 👑
- a. Local-repair: AN and AGN1x support local-repair for adjacent link or node failure for access-to-network, network-to-access, and access-to-access traffic flows. Local-repair is to be implemented by using either IPFRR LDP LFA, simple ECMP, or primary/backup switchover upon failure detection. 🔁
- b. LDP session protection: LDP sessions are configured with LDP session protection to avoid delay upon the recovery from link failure. LDP session protection ensures that FEC label binding is maintained in the control plane as long as the LDP session stays up. 🛡️
- c. IGP-LDP synchronization: If access IGP is used, LDP sessions between ANs, and between ANs and AGN1x, are configured with IGP-LDP synchronization to avoid unnecessary traffic loss in case the access IGP converged before LDP and there is no LDP label binding to the best downstream next hop. 🧠
3.5.2. AN Failure 🚨
If the AN fails, adjacent AN/AGN1x nodes remove all routes pointing to the failed node from their RIB tables (including /32 loopback belonging to the failed AN and any other routes reachable via the failed AN). In turn, this triggers the removal of associated outgoing /32 FEC labels from their LIB and LFIB tables. Oof. 😵💫
If access IGP is used, the AN failure will be propagated via IGP link updates across the access topology. 📡
If a specific /32 FEC(s) is no longer reachable from those ANs/AGN1x's, they also send LDP Label Withdraw messages to their upstream LSRs to notify them about the failure, and remove the associated incoming label(s) from their LIB and LFIB tables. Upstream LSRs, upon receiving a Label Withdraw, remove the signaled labels from their LIB/LFIB tables, and propagate LDP Label Withdraws across their upstream LDP DoD sessions. It's a whole chain reaction, periodt. 🔗
In the [U] topology, there may be an alternative path to routes previously reachable via the failed AN. In this case, adjacent AN/AGN1x pairs invoke local-repair (IPFRR LFA, ECMP) and switch over to an alternate next hop to reach those routes. Plot twist, there's a backup. 🎭
AGN1x is notified about the AN failure via access IGP (if used) and/or cascaded LDP DoD Label Withdraw(s). AGN1x implements all relevant global-repair IP/MPLS procedures to propagate the AN failure towards the core network. This involves removing associated routes (in the access IGP case) and labels from its LIB and LFIB tables, and propagating the failure on the network side using labeled BGP and/or core IGP/LDP DU procedures. The AGN1x is the main character here. 🌟
Upon the AN coming back up, adjacent AN/AGN1x nodes automatically add routes pointing to recovered links based on the configured static routes or access IGP adjacency and link state updates. This is then followed by LDP DoD label signaling and subsequent binding and installation of labels in LIB and LFIB tables. Welcome back, queen. 👸
3.5.3. AN/AGN Link Failure ⛓️
Depending on the access topology and the failed link location, different cases apply to the network operation after AN link failure (topology references from Section 2 in square brackets): 🗺️
- a.
[all]- link failed, but at least one ECMP parallel link remains. Nodes on both sides of the failed link stop using the failed link immediately (local-repair) and keep using the remaining ECMP parallel links. 🙌 - b.
[I1, I, Y]- link failed, and there are no ECMP or alternative links and paths. Nodes on both sides of the failed link remove routes pointing to the failed link immediately from the RIB, remove associated labels from their LIB and LFIB tables, and send LDP Label Withdraw(s) to their upstream LSRs. Rough day, no backup. 😭 - c.
[U2, U, V, Y]- link failed, but at least one ECMP or alternate path remains. The AN/AGN1x node stops using the failed link and immediately switches over (local-repair) to the remaining ECMP path or alternate path. The AN/AGN1x removes affected next hops and labels. If there is an AGN1x terminating the failed link, it immediately removes routes pointing to the failed link from the RIB, removes any associated labels from the LIB and LFIB tables, and propagates the failure on the network side using labeled BGP and/or core IGP procedures. 🧃
If access IGP is used, AN/AGN1x link failure will be propagated via IGP link updates across the access topology. 📶
LDP DoD will also propagate the link failure by sending Label Withdraws to upstream AN/AGN1x nodes, and Label Release messages to downstream AN/AGN1x nodes. Everyone gets the memo. 📬
3.5.4. AGN Failure 🏚️
If an AGN1x fails adjacent access then, depending on the access topology, the following cases apply to the network operation (topology references from Section 2 are shown in square brackets): 🧭
- a.
[I1, I]- ANs are isolated from the network - An AN adjacent to the failure immediately removes routes pointing to the failed AGN1x from the RIB, removes associated labels from the LIB and LFIB tables, and sends LDP Label Withdraw message(s) to its upstream neighbors. If access IGP is used, an IGP link update is sent. Isolated, but honest. 🥺 - b.
[U2, U, V, Y]- at least one ECMP or alternate path remains. AN adjacent to failed AGN1x stops using the failed link and immediately switches over (local-repair) to the remaining ECMP path or alternate path by following LDP [RFC5036] procedures. (Appendix A.1.7 "Detect Change in FEC Next Hop") 🪄
Network-side procedures for handling AGN1x failure have been described in Seamless MPLS [SEAMLESS-MPLS]. Go read that one too, it's giving thorough. 📚
3.5.5. AGN Network-Side Reachability Failure 🌐
If AGN1x loses network reachability to a specific destination or set of network-side destinations, AGN1x sends LDP Label Withdraw messages to its upstream ANs, withdrawing labels for all affected /32 FECs. Upon receiving those messages, ANs remove those labels from their LIB and LFIB tables, and use alternative LSPs instead (if available) as part of global-repair. 🛤️
If access IGP is used, and AGN1x gets completely isolated from the core network, it stops advertising the default route 0/0 into the access IGP. Lights out, but make it cute. 🕯️
4. LDP DoD Procedures 🎀
All LDP Downstream-on-Demand implementations follow the Label Distribution Protocol as specified in [RFC5036]. This section does not update [RFC5036] procedures, but illustrates LDP DoD operations in the context of use cases identified in Section 3 in this document, for information only. Think of it as the behind-the-scenes tea. ☕
In the MPLS architecture [RFC3031], network traffic flows from the upstream LSR to the downstream LSR. The use cases in this document rely on the downstream assignment of labels, where labels are assigned by the downstream LSR and signaled to the upstream LSR as shown in Figure 7. Picture it like this: 👇
+----------+ +------------+
| upstream | | downstream |
------+ LSR +------+ LSR +----
traffic | | | | address
source +----------+ +------------+ (/32 for IPv4)
traffic
label distribution for IPv4 FEC destination
<-------------------------
traffic flow
------------------------->
Figure 7: LDP Label Assignment Direction4.1. LDP Label Distribution Control and Retention Modes ✨
Okay so the LDP spec [RFC5036] defines two modes for label distribution control, borrowing the definitions from the MPLS architecture [RFC3031] 🎀:
- Independent mode: An LSR recognizes a FEC and decides to bind a label to it on its own, without waiting to share that label binding with its label distribution peers. A brand-new FEC gets recognized the moment a new route becomes valid on the LSR 🦋
- Ordered mode: An LSR has to bind a label to a FEC if it knows how to forward packets for that FEC (meaning it has a route matching that FEC) and it has already received at least one Label Request message from an upstream LSR 💅
Using independent label distribution control with LDP DoD and access static routing would stop the access LSRs from passing label binding failures along the access topology. That means an upstream LSR could never find out about a downstream failure, and an application using the LSP couldn't switch over to an alternate path, even if one exists 😭
The LDP spec [RFC5036] also defines two modes for label retention, again following the MPLS architecture [RFC3031] 🌸:
- Conservative label retention mode: If you're operating in DoD mode, an LSR only requests label mappings from the next-hop LSR chosen by routing. The big perk is that only the labels needed for forwarding data get allocated and kept around. That matters a lot on LSRs with a limited label space, like an ATM switch 🫶 The catch is that if routing changes the next hop for a destination, a new label has to be obtained from the new next hop before labeled packets can be forwarded 💀
- Liberal label retention mode: When you're in DoD mode with liberal label retention, an LSR might ask for label mappings for all known prefixes from all peer LSRs. The upside is that reacting to routing changes is super quick, because the labels already exist 🚀 The downside is that unneeded label mappings get distributed and maintained too 🙈
Heads up on the conservative mode: it would stop LSRs from requesting and keeping label mappings for backup routes that aren't used for forwarding. That would block the access LSRs (AN and AGN1x nodes) from running any local protection schemes that rely on alternate next hops when the primary next hop fails. Examples include IPFRR LFA when access IGP is used, or a primary and backup static route configuration 🧚 Pairing LDP DoD with liberal label retention lets the LSR request labels for the specific FEC from the primary next-hop LSR(s) and the alternate next-hop LSR(s) for that FEC ✨
Even with LDP DoD running in liberal label retention mode, if access IGP is used and there's no LFA, LDP DoD adds some extra delay to traffic restoration. The reason is that labels for the new next hop only get requested after access IGP convergence 🐢
To hit the overall goals of Seamless MPLS [SEAMLESS-MPLS], which means a large network scale without giving up fast service restoration, every access LSR (AN and AGN1x nodes) uses LDP DoD advertisement mode with:
- Ordered label distribution control: This enables propagation of label binding failure within the access topology 🔥
- Liberal label retention mode: This enables pre-programming of alternate next hops with their associated FEC labels 👑
In Seamless MPLS [SEAMLESS-MPLS], an AGN1x acts as an access ABR connecting the access and metro domains. To allow failure propagation between those domains, the access ABR uses ordered label distribution control whenever it redistributes routes/FECs between the access side (using LDP DoD and static or access IGP) and the network side (using labeled BGP [RFC3107], or a core IGP with LDP Downstream Unsolicited label advertisements) 🌈
4.2. LDP DoD Session Negotiation 🎀
An access LSR/ABR proposes DoD label advertisement by setting the A value to 1 in the Common Session Parameters TLV of the Initialization message 💖 The rules for negotiating the label advertisement mode live in the LDP spec [RFC5036], so go check there for the full details.
To set up a DoD session between two access LSR/ABRs, both sides propose the DoD label advertisement mode in their Initialization message. If the access LSR only supports LDP DoD and the access ABR proposes Downstream Unsolicited mode, the access LSR sends a Notification message with the status Session Rejected/Parameters Advertisement Mode and then closes the LDP session, as specified in the LDP spec [RFC5036] 🙅♀️
If an access LSR is in an active role, it re-attempts the LDP session right away. If it gets the same Downstream Unsolicited mode again, it follows the exponential backoff algorithm from the LDP spec [RFC5036]. The delay starts at 15 seconds and grows in later attempts up to a maximum of 2 minutes ⏳
If a PWE3 service is needed between adjacent access LSR/ABRs, and LDP DoD has been negotiated for IPv4 and IPv6 FECs, the same LDP session gets used for PWE3 FECs too 🧚♀️ Even though LDP DoD label advertisement was negotiated for IPv4 and IPv6 LDP FECs like we just covered, the LDP session uses a Downstream Unsolicited label advertisement for PWE3 FECs, as specified in PWE3 LDP [RFC4447] 🍓
4.3. Label Request Procedures 🦋
4.3.1. Access LSR/ABR Label Request 💌
The upstream access LSR/ABR requests label bindings from an adjacent downstream access LSR/ABR based on these trigger events:
- a. An access LSR/ABR is configured with a /32 static route with an LDP DoD Label Request policy, matching the initial network setup use case described in Section 3.1 🌱
- b. An access LSR/ABR is configured with a service matching the service use cases described in Sections 3.2 and 3.3 🎁
- c. Configuration with access static routes: An access LSR/ABR link to an adjacent node comes up and an LDP DoD session is established. In this case, the access LSR sends Label Request messages for all /32 static routes configured with an LDP DoD policy, plus all /32 routes related to provisioned services that are covered by the default route 🛣️
- d. Configuration with access IGP: An access LSR/ABR link to an adjacent node comes up and an LDP DoD session is established. In this case, the access LSR sends Label Request messages for all /32 routes learned over the access IGP, plus all /32 routes related to provisioned services that are covered by access IGP routes 🌷
- e. In all the cases above, requests go to any next-hop LSRs and alternate LSRs 🫧
The downstream access LSR/ABR responds with a Label Mapping message carrying a non-null label if any of these conditions are met:
- a. Downstream access LSR/ABR: The requested FEC is an IGP or static route, and there's an LDP label already learned from the next-next-hop downstream LSR (via LDP DoD or LDP DU). If there's no label for the requested FEC and there's an LDP DoD session to the next-next-hop downstream LSR, the downstream LSR sends a Label Request message for the same FEC to that next-next-hop downstream LSR. In that case, it only replies to the requesting upstream access LSR after getting a label from the next-next-hop downstream LSR peer 🔁
- b. Downstream access ABR only: The requested FEC is a BGP labeled IP route [RFC3107], and this BGP route is the best one selected for that FEC 👑
The downstream access LSR/ABR can reply with a label mapping using an explicit-null or implicit-null label if it's acting as the egress for the requested FEC. Or it can reply with a No Route notification if no route exists 🙃
4.3.2. Label Request Retry 🔄
Following the LDP spec [RFC5036], if an access LSR/ABR gets a No Route notification in response to its Label Request message, it retries using an exponential backoff algorithm similar to the one used for LDP session negotiation in Section 4.2 ⏱️
If there's no response to a Label Request message, the LDP spec [RFC5036] (Section A.1.1) says the LSR doesn't send another request for the same label to that peer. It also says a duplicate Label Request counts as a protocol error and gets dropped by the receiving LSR, which sends a Notification message back 🚫
So if there's no response from the downstream peer, the access LSR/ABR doesn't send a duplicate Label Request message. Period 💅
If the static route for the FEC gets deleted, or the DoD request policy gets changed to reject the FEC before the Label Mapping message arrives, then the access LSR/ABR sends a Label Abort message to the downstream LSR 🧹
To deal with the slower convergence caused by this LDP behavior described in the LDP spec [RFC5036], a new LDP TLV extension is proposed and described in Section 5 ✨🎀
4.4. Label Withdraw 💔
okay so, if an MPLS label on the downstream access LSR/ABR stops being valid, that downstream box has to pull the FEC/label binding back from the upstream access LSR/ABR. It does this with the Label Withdraw message [RFC5036], either with a specified label TLV or with an empty label TLV. 🫶
The downstream access LSR/ABR withdraws a label for a specific FEC in these cases:
a. If an LDP DoD ingress label is tied to an outgoing label that a labeled BGP route handed out, and that route gets withdrawn. 🦋
b. If an LDP DoD ingress label is tied to an outgoing label that LDP handed out (DoD or DU), and the IGP route gets withdrawn from the RIB or the downstream LDP session is lost. 😭
c. If an LDP DoD ingress label is tied to an outgoing label that LDP handed out (DoD or DU), and the downstream LSR withdraws that outgoing label. 💅
d. If an LDP DoD ingress label is tied to an outgoing label that LDP handed out (DoD or DU), the next hop in the route has changed, and:
- there is no LDP session to the new next hop. To lower the odds of this, the access LSR/ABR implements LDP-IGP synchronization procedures as specified in [RFC5443]. 🧚
- there is an LDP session but no label from a downstream LSR. See note below. 👀
e. If an access LSR/ABR is configured with a policy to reject exporting label mappings to an upstream LSR. 🙈
The upstream access LSR/ABR answers the Label Withdraw message with the Label Release message [RFC5036]. 💜
After it sends that Label Release message to the downstream access LSR/ABR, the upstream access LSR/ABR sends the Label Request message again, as long as it still needs the label. 🔁
The downstream access LSR/ABR also withdraws a label if the local route configuration (e.g., /32 loopback) is deleted. 🌸
Note: For any events that cause a next-hop change, a downstream access LSR/ABR tries to converge the LSP locally before it withdraws the label from an upstream access LSR/ABR. ✨ For example, if the next hop changes for a particular FEC and the new next hop hands out labels over the LDP DoD session, then the downstream access LSR/ABR sends a Label Request on the new next-hop session. If the downstream access LSR/ABR doesn't get a label mapping for some duration, then and only then does it withdraw the upstream label. 🫣
4.5. Label Release 🎀
If an access LSR/ABR no longer needs a label for a FEC, it sends a Label Release message [RFC5036] to the downstream access LSR/ABR, with or without the label TLV. 🍓
If an upstream access LSR/ABR gets an unsolicited label mapping on a DoD session, it releases that label by sending a Label Release message. 🙅♀️
The access LSR/ABR sends a Label Release message to the downstream LSR in these cases:
a. If it receives a Label Withdraw from the downstream access LSR/ABR. 💀
b. If the /32 static route with LDP DoD Label Request policy is deleted. 🗑️
c. If the service gets decommissioned and there is no matching /32 static route with LDP DoD Label Request policy configured. 🪦
d. If the next hop in the route has changed and the label does not point to the best or alternate next hop. 🔀
e. If it receives a Label Withdraw from a downstream DoD session. 🌈
4.6. Local-Repair 🛟
To support local-repair with ECMP and IPFRR LFA, the access LSR/ABR requests labels on both the best next-hop and the alternate next-hop LDP DoD sessions, as laid out in the Label Request procedures in Section 4.3. 🫶 If remote LFA is enabled, the access LSR/ABR needs a label from its alternate next hop toward the PQ node, and it needs a label from the remote PQ node toward its FEC/destination [RLFA]. If the access LSR/ABR doesn't already know those labels, it asks for them. 🙋♀️
This lets the access LSR/ABR pre-program the alternate forwarding path with the alternate label(s), so it can trigger the IPFRR LFA switchover procedure if the primary next-hop link fails. 🔥
5. LDP Extension for LDP DoD Fast-Up Convergence ⚡
okay this part is so clever 🧠. In some conditions, the exponential backoff algorithm from Section 4.3.2 can make you wait longer than you'd like to get a successful LDP label-to-route mapping. 😩 One example is when a specific route is unavailable on the downstream LSR when the upstream's label mapping request comes in, but then the route comes right back. In that case, the exponential backoff can mean a max delay wait before the upstream LSR sends another LDP Label Request. 🐌
This section describes an extension to the LDP DoD procedure that targets fast-up convergence, and it is to be treated as a normative reference. 📌 The downstream and upstream LSRs SHOULD implement this extension if fast-up convergence is desired. 🚀
The extension works like this: the upstream LSR tells the downstream LSR that the Label Request SHOULD be queued on the downstream LSR until the requested route is available. 🎟️
To make this happen, a new Optional Parameter is defined for use in the Label Request message:
Optional Parameter Length Value
Queue Request TLV 0 see below 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| Queue Request (0x0971) | Length (0x00) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's the breakdown of the fields. 👀
U-bit = 1: this is the Unknown TLV bit. When an unknown TLV arrives and the U-bit is set (=1), the unknown TLV MUST be silently ignored, and the rest of the message gets processed as if that unknown TLV didn't exist. If the requested route isn't available, the downstream LSR MUST ignore this unknown TLV and send a "No Route" notification back. This keeps things backward compatible. 🤝
F-bit = 0: this is the Forward unknown TLV bit. It only applies when the U-bit is set and the LDP message containing the unknown TLV is going to be forwarded. Since the F-bit is clear (=0), the unknown TLV is not forwarded with the message. 🚫
Type = 0x0971: this is the Queue Request TLV (allocated by IANA). 🏷️
Length = 0x00: this specifies the length of the Value field in octets. 📏
Here's how the operation goes. ✨
To get the fast-up convergence boost, the upstream LSR sends a Label Request message with a Queue Request TLV. 💖
If the downstream LSR supports the Queue Request TLV, it checks whether a route is available. If it is, the LSR replies with a label mapping as per existing LDP procedures. If the route isn't available, the downstream LSR queues the request and replies as soon as the route shows up. In the meantime, it does not send a "No Route" notification back. 🕰️ When the upstream LSR sends a Label Request with the Queue Request TLV, it does not retry the Label Request message if it doesn't get a reply from its downstream peer. 🛑
If the upstream LSR wants to abort an outstanding Label Request while it's queued in the downstream LSR, it sends a Label Abort Request message. That makes the downstream LSR remove the original request from the queue and send back a Label Request Aborted notification [RFC5036]. 🙅♂️
If the downstream LSR doesn't support the Queue Request TLV, and the requested route is not available, it ignores this unknown TLV and sends a "No Route" notification back, in line with [RFC5036]. 🙃 In this case, the upstream LSR invokes the exponential backoff algorithm described in Section 4.3.2, following the LDP specification [RFC5036]. 🔁
This procedure keeps backward compatibility intact. 🫶
6. IANA Considerations 📋
6.1. LDP TLV Type 🔢
This document uses a new Optional Parameter, the Queue Request TLV, in the Label Request message defined in Section 5. IANA already maintains a registry of LDP parameters called the "TLV Type Name Space" registry, as defined by RFC 5036. The following assignment has been made: 🗂️
TLV type Description
0x0971 Queue Request TLV7. Security Considerations 🔐
MPLS LDP DoD deployment in the access network faces the same security threats as any MPLS LDP deployment. 😬 It is recommended that baseline security measures be considered, as described in "Security Framework for MPLS and GMPLS Networks" [RFC5920] and the LDP specification [RFC5036]. That includes making sure LDP messages are authentic and have integrity, and protecting against spoofing and denial-of-service attacks. 🛡️
⚠️ Some deployments need stronger network security if a subset of access nodes sits in places with lower physical security, e.g., street cabinets (a common practice for Very high bit-rate Digital Subscriber Line (VDSL) access). In those cases, it is the responsibility of the system designer to account for physical security measures (environmental design, mechanical or electronic access control, intrusion detection), as well as monitoring and auditing measures (configuration and Operating System changes, reloads, route advertisements). 🚨
But even with all of that in mind, the designer still needs to consider network security risks and adequate measures that come from the lower level of physical security at those locations. 💀🔐
7.1. LDP DoD Native Security Properties 🔒
okay so MPLS LDP DoD is request driven 🎀, which means upstream LSRs just don't accept unsolicited label mappings. That's by design, not an accident! It inherently limits the chances of an unauthorized third party injecting unsolicited label mappings onto the wire ✨
This native security property lets an ABR LSR act as a gateway to the MPLS network 🚪. It can control the requests coming from any access LSR, and prevent the access LSR from getting access to an unauthorized FEC or remote LSR after it's been compromised. main character energy for the ABR, honestly 👑
In the event that an access LSR gets compromised and manages to advertise a FEC belonging to another LSR (e.g., in order to 'steal' third-party data flows, or breach the privacy of a VPN) 💀, that access LSR would also have to influence the routing decision for affected FECs on the ABR LSR to attract the flows. The following measures need to be considered on an ABR LSR to prevent such an event from occurring:
a. Access with static routes: An access LSR cannot influence ABR LSR routing decisions due to the static nature of routing configuration, a native property of the design. 🧊
b. Access with IGP - access FEC "stealing": If the compromised access LSR is a leaf in the access topology (leaf node in topologies I1, I, V, Y described earlier), this will not have any adverse effect, due to the leaf IGP metrics being configured on the ABR LSR. If the compromised access LSR is a transit LSR in the access topology (transit node in topologies I, Y, U), it is only possible for this access LSR to attract traffic destined to the nodes upstream from it. Such a 'man-in-the-middle attack' can quickly be detected by upstream access LSRs not receiving traffic and by the LDP TCP session being lost. 🚨
c. Access with IGP - network FEC "stealing": The compromised access LSR can use IGP to advertise a "stolen" FEC prefix belonging to the network side. This case can be prevented by giving a better administrative preference to the BGP labeled IP routes versus access IGP routes. 🛡️
In summary, the native properties of MPLS in access design with LDP DoD prevent a number of security attacks and make their detection quick and straightforward. so that's the big win 🦋
The following two sections describe other security considerations applicable to general MPLS deployments in the access network.
7.2. Data-Plane Security 🌸
Data-plane security risks applicable to the access MPLS network include:
a. Labeled packets from a specific access LSR that are sent to an unauthorized destination.
b. Unlabeled packets that are sent by an access LSR to remote network nodes.
The following mechanisms apply to MPLS access design with LDP DoD that address the listed data-plane security risks:
- addressing (a): Access and ABR LSRs do not accept labeled packets over a particular data link, unless from the access or ABR LSR perspective this data link is known to attach to a trusted system based on control-plane security as described in Section 7.3 and the top label has been distributed to the upstream neighbor by the receiving access or ABR LSR. 🔐
- addressing (a) - The ABR LSR restricts network reachability for access devices to a subset of remote network LSRs, based on control-plane security as described in Section 7.3, FEC filters, and routing policy. 🚧
- addressing (a): Control-plane authentication as described in Section 7.3 is used. 🪪
- addressing (b): The ABR LSR restricts IP network reachability to and from the access LSR. 🙅♀️
7.3. Control-Plane Security 💜
Similar to Inter-AS MPLS/VPN deployments [RFC4364], control-plane security is a prerequisite for data-plane security. it's literally the foundation, bestie 🧱
To ensure control-plane security access, LDP DoD sessions are established only with LDP peers that are considered trusted from the local LSR perspective, meaning they are reachable over a data link that is known to attach to a trusted system based on employed authentication mechanism(s) on the local LSR. ✨
The security of LDP sessions is analyzed in the LDP specification [RFC5036] and in [RFC6952] ("Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide"). Both documents state that LDP is subject to two different types of attacks: spoofing and denial-of-service attacks. 👀
The threat of spoofed LDP Hello messages can be reduced by following guidelines listed in the LDP specification [RFC5036]: accepting Basic Hellos only on interfaces connected to trusted LSRs, ignoring Basic Hellos that are not addressed to all routers in this subnet multicast group, and using access lists. LDP Hello messages can also be secured using an optional Cryptographic Authentication TLV as specified in "LDP Hello Cryptographic Authentication" [CRYPTO-AUTH] that further reduces the threat of spoofing during the LDP discovery phase. 🧾
Spoofing during the LDP session communication phase can be prevented by using the TCP Authentication Option (TCP-AO) [RFC5925], which uses a stronger hashing algorithm, e.g., SHA1 as compared to the traditionally used MD5 authentication. TCP-AO is recommended as being more secure as compared to the TCP/IP MD5 authentication option [RFC5925]. it's giving stronger hashing energy 🔥
The threat of a denial-of-service attack targeting a well-known UDP port for LDP discovery or a TCP port for LDP session establishment can be reduced by following the guidelines listed in [RFC5036] and in [RFC6952]. 🚫
Access IGP (if used) and any routing protocols used in the access network for signaling service routes also need to be secured following best practices in routing protocol security. Refer to the KARP IS-IS security analysis document [KARP-ISIS] and to [RFC6863] ("Analysis of OSPF Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guide") for further analysis of security properties of IS-IS and OSPF IGP routing protocols. 🧠
8. Acknowledgements 🫶
The authors would like to thank Nischal Sheth, Nitin Bahadur, Nicolai Leymann, George Swallow, Geraldine Calvignac, Ina Minei, Eric Gray, and Lizhong Jin for their suggestions and review. Additional thanks go to Adrian Farrel for thorough pre-publication review, and to Stephen Kent for review and guidance specifically for the security section. the squad really showed up 💖
9. References 📚
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007.
[RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension for Inter-Area Label Switched Paths (LSPs)", RFC 5283, July 2008.
9.2. Informative References
[CRYPTO-AUTH] Zheng, L., Chen, M., and M. Bhatia, "LDP Hello Cryptographic Authentication", Work in Progress, August 2013.
[KARP-ISIS] Chunduri, U., Tian, A., and W. Lu, "KARP IS-IS security analysis", Work in Progress, March 2013.
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001.
[RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, September 2008.
[RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP Synchronization", RFC 5443, March 2009.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
[RFC6863] Hartman, S. and D. Zhang, "Analysis of OSPF Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6863, March 2013.
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6952, May 2013.
[RLFA] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. So, "Remote LFA FRR", Work in Progress, May 2013.
[SEAMLESS-MPLS] Leymann, N., Ed., Decraene, B., Filsfils, C., Konstantynowicz, M., Ed., and D. Steinberg, "Seamless MPLS Architecture", Work in Progress, July 2013.
Authors' Addresses 💌
Thomas Beckhaus (editor), the Deutsche Telekom bestie 📮
Thomas Beckhaus (editor)
Deutsche Telekom AG
Heinrich-Hertz-Strasse 3-7
Darmstadt 64307
Germany
Phone: +49 6151 58 12825
EMail: thomas.beckhaus@telekom.deBruno Decraene, from Orange 🍊
Bruno Decraene
Orange
38-40 rue du General Leclerc
Issy Moulineaux cedex 9 92794
France
EMail: bruno.decraene@orange.comKishore Tiruveedhula, from Juniper Networks 🌈
Kishore Tiruveedhula
Juniper Networks
10 Technology Park Drive
Westford, Massachusetts 01886
USA
Phone: 1-(978)-589-8861
EMail: kishoret@juniper.netMaciek Konstantynowicz (editor), from Cisco Systems 🦄
Maciek Konstantynowicz (editor)
Cisco Systems, Inc.
10 New Square Park, Bedfont Lakes
London
United Kingdom
EMail: maciek@cisco.comLuca Martini, also from Cisco Systems 🧚
Luca Martini
Cisco Systems, Inc.
9155 East Nichols Avenue, Suite 400
Englewood, CO 80112
USA
EMail: lmartini@cisco.com📦 where this page comes from
- ietf: rfc7032 2013-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms