RFC 8661
Segment Routing MPLS Interworking with LDP
RFC 8661: Segment Routing MPLS Interworking with LDP 🎀
Okay bestie, here's the title block tea ☕. This is RFC 8661, published in December 2019 as a Standards Track document, and it's part of the ISSN 2070-1721 series. The authors are A. Bashandy (Ed., Individual), C. Filsfils (Ed., Cisco Systems, Inc.), S. Previdi (Huawei Technologies), B. Decraene (Orange), and S. Litkowski (Orange) 🫶. The header doesn't list any Obsoletes or Updates entries, so this one isn't replacing or patching anything else 🧚.
Abstract
Okay so a Segment Routing (SR) node steers a packet through a controlled set of instructions called segments, and it does that by prepending the packet with an SR header 💅. A segment can represent any instruction, whether it's topological or service based ✨. SR lets you enforce a flow through any topological path while only keeping per-flow state at the ingress node to the SR domain. Main character energy, literally 👑.
The Segment Routing architecture can be applied directly to the MPLS data plane with no change in the forwarding plane 🦋. This document explains how Segment Routing MPLS operates in a network where LDP is deployed, and in the case where SR-capable and non-SR-capable nodes coexist 🌈.
Status of This Memo
This is an Internet Standards Track document 🎀.
It's a product of the Internet Engineering Task Force (IETF), so 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) 💖. If you want more info on Internet Standards, check Section 2 of RFC 7841 🍓.
Info about the current status of this document, any errata, and how to give feedback on it lives at https://www.rfc-editor.org/info/rfc8661 🔥.
Copyright Notice
Copyright (c) 2019 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, which you can find at https://trustee.ietf.org/license-info as in effect on the date of publication 📜. Please read these carefully, because they spell out your rights and restrictions for 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 they're provided without warranty as described in the Simplified BSD License ⚠️.
Table of Contents
1. Introduction
1.1. Requirements Language
2. SR-LDP Ships-in-the-Night Coexistence
2.1. MPLS2MPLS, MPLS2IP, and IP2MPLS Coexistence
3. SR and LDP Interworking
3.1. LDP to SR
3.1.1. LDP to SR Behavior
3.2. SR to LDP
3.2.1. Segment Routing Mapping Server (SRMS)
3.2.2. SR to LDP Behavior
3.2.3. Interoperability of Multiple SRMSes and Prefix-SID
Advertisements
4. SR-LDP Interworking Use Cases
4.1. SR Protection of LDP-Based Traffic
4.2. Eliminating Targeted LDP Sessions
4.3. Guaranteed FRR Coverage
4.4. Inter-AS Option C, Carrier's Carrier
5. IANA Considerations
6. Manageability Considerations
6.1. SR and LDP Coexistence
6.2. Data-Plane Verification
7. Security Considerations
8. References
8.1. Normative References
8.2. Informative References
Appendix A. Migration from LDP to SR
Acknowledgements
Contributors
Authors' Addresses1. Introduction ✨
Okay so Segment Routing, as described in [RFC8402], can ride on top of the MPLS data plane without any modification, as described in [RFC8660] 🦋.
The Segment Routing control plane can coexist with current label distribution protocols, like LDP [RFC5036] 💅.
This document lays out the mechanisms that let SR interwork with LDP in cases where a mix of SR-capable and non-SR-capable routers coexist within the same network, and more precisely within the same routing domain 🧚.
Section 2 covers how SR coexists with other MPLS control-plane protocols 🎀. Section 3 documents the interworking between SR and LDP when the deployment isn't homogeneous 🌸. Section 4 shows how a partial SR deployment can give SR benefits to LDP-based traffic, including a possible application of SR in the context of interdomain MPLS use cases 👑. Appendix A documents a method to migrate from LDP to SR-based MPLS tunneling 💖.
Typically, an implementation lets an operator select (through configuration) which of the described modes of SR and LDP coexistence to use 🫶.
1.1. 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 📜.
2. SR-LDP Ships-in-the-Night Coexistence 🌈
"MPLS Control-Plane Client (MCC)" refers to any control-plane protocol that installs forwarding entries in the MPLS data plane 💅. SR, LDP [RFC5036], RSVP-TE [RFC3209], BGP [RFC8277], etc., are all examples of MCCs ✨.
An MCC, operating at Node N, must ensure that the incoming label it installs in the MPLS data plane of Node N has been uniquely allocated to itself 🙈.
Segment Routing makes use of the Segment Routing Global Block (SRGB, as defined in [RFC8402]) for label allocation 🎀. Using the SRGB is what lets SR coexist with any other MCC 🦋.
This is clearly the case for the adjacency segment. It's a local label allocated by the label manager, the same as for any MCC 💖.
This is also clearly the case for the prefix segment. The label manager allocates the SRGB set of labels to the SR MCC client, and the operator makes sure each global prefix segment or label gets a unique allocation within the allocated SRGB set 🫶.
Here's the tea: this static label-allocation capability of the label manager has existed for many years across several vendors, so it isn't new 🍓. The label manager's ability to statically allocate a range of labels to a specific application isn't new either. This is required for MPLS-TP operation 🔥. In that case, the range is reserved by the label manager, and it's the MPLS-TP [RFC5960] Network Management System (acting as an MCC) that makes sure every label gets a unique allocation within the allocated range, and that the related MPLS forwarding entry gets created 💅.
Let's walk through an example of ship-in-the-night (SIN) coexistence 🧚.
PE2 PE4
\ /
PE1----A----B---C---PE3
Figure 1: SIN CoexistenceThe EVEN VPN service is supported by PE2 and PE4, while the ODD VPN service is supported by PE1 and PE3 🌸. The operator wants to tunnel the ODD service via LDP and the EVEN service via SR 👑.
This can be achieved in the following manner:
- The operator configures PE1, PE2, PE3, and PE4 with respective loopbacks 192.0.2.201/32, 192.0.2.202/32, 192.0.2.203/32, and 192.0.2.204/32. These PEs advertised their VPN routes with next hop set on their respective loopback address 💖.
- The operator configures A, B, C with respective loopbacks 192.0.2.1/32, 192.0.2.2/32, 192.0.2.3/32 🎀.
- The operator configures PE2, A, B, C, and PE4 with SRGB [100, 300] 🦋.
- The operator attaches the respective Node Segment Identifiers (Node SIDs, as defined in [RFC8402]), 202, 101, 102, 103, and 204, to the loopbacks of nodes PE2, A, B, C, and PE4. The Node SIDs are configured to request Penultimate Hop Popping 🫶.
- PE1, A, B, C, and PE3 are LDP capable 🍓.
- PE1 and PE3 are not SR capable 🙈.
PE3 sends an ODD VPN route to PE1 with next-hop 192.0.2.203 and VPN label 10001 💅.
From an LDP viewpoint, PE1 received an LDP label binding (1037) for a Forwarding Equivalence Class (FEC) 192.0.2.203/32 from its next-hop A. A received an LDP label binding (2048) for that FEC from its next-hop B. B received an LDP label binding (3059) for that FEC from its next-hop C. And C received an implicit NULL LDP binding from its next-hop PE3 🧚.
As a result, PE1 sends its traffic to the ODD service route advertised by PE3, to next-hop A, with two labels. The top label is 1037 and the bottom label is 10001. Node A swaps 1037 with 2048 and forwards to B. B swaps 2048 with 3059 and forwards to C. C pops 3059 and forwards to PE3 ✨.
PE4 sends an EVEN VPN route to PE2 with next-hop 192.0.2.204 and VPN label 10002 🌈.
From an SR viewpoint, PE2 maps the IGP route 192.0.2.204/32 onto Node SID 204. Node A swaps 204 with 204 and forwards to B. B swaps 204 with 204 and forwards to C. C pops 204 and forwards to PE4 🦋.
As a result, PE2 sends its traffic to the VPN service route advertised by PE4, to next-hop A, with two labels. The top label is 204 and the bottom label is 10002. Node A swaps 204 with 204 and forwards to B. B swaps 204 with 204 and forwards to C. C pops 204 and forwards to PE4 💜.
And just like that, the two modes of MPLS tunneling coexist 👑:
- The ODD service is tunneled from PE1 to PE3 through a continuous LDP LSP traversing A, B, and C 💖.
- The EVEN service is tunneled from PE2 to PE4 through a continuous SR node segment traversing A, B, and C 🎀.
2.1. MPLS2MPLS, MPLS2IP, and IP2MPLS Coexistence 🦋
MPLS2MPLS refers to the forwarding behavior where a router receives a labeled packet and switches it out as a labeled packet 🫶. Several MPLS2MPLS entries may be installed in the data plane for the same prefix 🍓.
Let's check out A's MPLS forwarding table as an example 🔥:
Incoming label: 1037
- Outgoing label: 2048
- Outgoing next hop: B
Note: This entry is programmed by LDP for 192.0.2.203/32.
Incoming label: 203
- Outgoing label: 203
- Outgoing next hop: B
Note: This entry is programmed by SR for 192.0.2.203/32.These two entries can coexist because their incoming labels are unique 💅. That uniqueness is guaranteed by the label manager allocation rules 🧚.
The same applies to the MPLS2IP forwarding entries 🌈. MPLS2IP is the forwarding behavior where a router receives a labeled IPv4/IPv6 packet with one label only, pops the label, and switches the packet out as IPv4/IPv6 ✨. For IP2MPLS coexistence, refer to Section 6.1 💖.
3. SR and LDP Interworking 🎀
This section analyzes the case where SR is available in one part of the network and LDP is available in another part 🌸. It describes how a continuous MPLS tunnel can be built throughout the network 👑.
PE2 PE4
\ /
PE1----P5--P6--P7--P8---PE3
<-----SR---->
<------LDP------>
Figure 2: SR and LDP InterworkingLet's analyze the following example 🦋:
- P6, P7, P8, PE4, and PE3 are LDP capable 💅.
- PE1, PE2, P5, and P6 are SR capable. PE1, PE2, P5, and P6 are configured with SRGB (100, 200) and with node segments 101, 102, 105, and 106, respectively 🫶.
- A service flow must be tunneled from PE1 to PE3 over a continuous MPLS tunnel encapsulation. Therefore, SR and LDP need to interwork 🔥.
3.1. LDP to SR 🦋
okay so this section is about the right-to-left traffic flow, aka the reverse direction 👀 PE3 has learned a service route whose next hop is PE1. PE3 also has an LDP label binding from its next hop, P8, for the FEC "PE1". So PE3 sends its service packet to P8 using classic LDP behavior 💅
P8 has an LDP label binding from its next hop, P7, for the FEC "PE1", so P8 forwards to P7 using classic LDP behavior ✨
P7 has an LDP label binding from its next hop, P6, for the FEC "PE1", so P7 forwards to P6 using classic LDP behavior 🌸
P6 does not have an LDP binding from its next hop, P5, for the FEC "PE1". BUT P6 has an SR node segment to the IGP route "PE1" 😭 So P6 forwards the packet to P5, and it swaps its local LDP label for FEC "PE1" with the equivalent node segment (i.e., 101) 🔥
P5 pops 101 (assuming PE1 advertised its node segment 101 with the penultimate-pop flag set) and forwards to PE1 🌈
PE1 receives the tunneled packet and processes the service label 🎀
The end-to-end MPLS tunnel is built by stitching an LDP LSP from PE3 to P6, plus the related node segment from P6 to PE1. Iconic teamwork 🫶
3.1.1. LDP to SR Behavior 💖
It has to be noted that no additional signaling or state is required in order to provide interworking in the direction LDP to SR. Zero extra vibes needed, lowkey amazing 🧚
An SR node having LDP neighbors MUST create LDP bindings for each Prefix-SID learned in the SR domain. It does this by treating SR-learned labels as if they were learned through an LDP neighbor. On top of that, for each FEC, the SR node stitches the incoming LDP label to the outgoing SR label. This has to be done in both LDP-independent and ordered label distribution control modes as defined in [RFC5036] 🦋
3.2. SR to LDP 🎀
okay now we flip it and look at the left-to-right traffic flow 💅
This section defines the Segment Routing Mapping Server (SRMS). The SRMS is an IGP node advertising mapping between Segment Identifiers (SID) and prefixes advertised by other IGP nodes. It uses a dedicated IGP extension (IS-IS, OSPFv2, and OSPFv3), which is protocol specific and defined in [RFC8665], [RFC8666], and [RFC8667] 🌸
The SRMS function of an SR-capable router lets it distribute mappings for prefixes that aren't locally attached to the advertising router. That means it can advertise mappings on behalf of non-SR-capable routers 🧚
The SRMS is a control-plane-only function that may be located anywhere in the IGP flooding scope. At least one SRMS server MUST exist in a routing domain to advertise Prefix-SIDs on behalf of non-SR nodes. That's what lets non-LDP routers send and receive labeled traffic from LDP-only routers 🔥 Multiple SRMSes may be present in the same network (for redundancy). This implies that there are multiple ways a prefix-to-SID mapping can be advertised. Conflicts resulting from inconsistent advertisements are addressed by [RFC8660] 👀
The example depicted in Figure 2 assumes that the operator configures P5 to act as a Segment Routing Mapping Server and advertises the following mappings: (P7, 107), (P8, 108), (PE3, 103), and (PE4, 104) 💖
The mappings advertised by one or more SRMSes result from local policy information configured by the operator 🦋
If PE3 had been SR capable, the operator would have configured PE3 with node segment 103. Instead, since PE3 is not SR capable, the operator configures that policy at the SRMS, and it is the SRMS that advertises the mapping 🙈
The Mapping Server Advertisements are only understood by SR-capable routers. The SR-capable routers install the related node segments in the MPLS data plane exactly like the node segments had been advertised by the nodes themselves ✨
For example, PE1 installs the node segment 103 with next hop P5 exactly as if PE3 had advertised node segment 103 💅
PE1 has a service route whose next hop is PE3. PE1 has a node segment for that IGP route: 103 with next hop P5. So PE1 sends its service packet to P5 with two labels: the bottom label is the service label and the top label is 103 🌈
P5 swaps 103 for 103 and forwards to P6 🫶
P6's next hop for the IGP route "PE3" is not SR capable (P7 does not advertise the SR capability). BUT P6 has an LDP label binding from that next hop for the same FEC (e.g., LDP label 1037). So P6 swaps 103 for 1037 and forwards to P7 😭
P7 swaps this label with the LDP label received from P8 and forwards to P8 🔥
P8 pops the LDP label and forwards to PE3 🎀
PE3 receives the tunneled packet and processes the service label 💜
The end-to-end MPLS tunnel is built by stitching an SR node segment from PE1 to P6, plus an LDP LSP from P6 to PE3. Main character energy 👑
SR-mapping advertisement for a given prefix provides no information about Penultimate Hop Popping. Other mechanisms, such as IGP-specific mechanisms ([RFC8665], [RFC8666], and [RFC8667]), MAY be used to determine the Penultimate Hop Popping in such case 🧚
💀 Note: In the previous example, Penultimate Hop Popping is not performed at the SR-LDP border for segment 103 (PE3), because none of the routers in the SR domain are Penultimate Hop for segment 103. In this case, P6 requires the presence of the segment 103 such as to map it to the LDP label 1037.
3.2.1. Segment Routing Mapping Server (SRMS) 🌈
This section specifies the concept and externally visible functionality of a Segment Routing Mapping Server (SRMS) 🦋
The purpose of SRMS functionality is to support the advertisement of Prefix-SIDs to a prefix without the need to explicitly advertise such assignment within a prefix reachability advertisement. Examples of explicit Prefix-SID Advertisement are the Prefix-SID sub-TLVs defined in [RFC8665], [RFC8666], and [RFC8667] 💖
The SRMS functionality allows assigning Prefix-SIDs to prefixes owned by non-SR-capable routers, as well as to prefixes owned by SR-capable nodes. It is the former capability that is essential to the SR-LDP interworking described later in this section 🫶
The SRMS functionality consists of two functional blocks: the Mapping Server (MS) and Mapping Client (MC) ✨
An MS is a node that advertises an SR mapping. Advertisements sent by an MS define the assignment of a Prefix-SID to a prefix, independent of the advertisement of reachability to the prefix itself. An MS MAY advertise SR mappings for any prefix, whether or not it advertises reachability for the prefix, and irrespective of whether that prefix is advertised by or even reachable through any router in the network 🙈
An MC is a node that receives and uses the MS mapping advertisements. Note that a node may be both an MS and an MC. An MC interprets the SR-mapping advertisement as an assignment of a Prefix-SID to a prefix. For a given prefix, if an MC receives an SR-mapping advertisement from a Mapping Server, and also has received a Prefix-SID Advertisement for that same prefix in a prefix reachability advertisement, then the MC MUST prefer the SID advertised in the prefix reachability advertisement over the Mapping Server Advertisement. In other words, the Mapping Server Advertisement MUST be ignored for that prefix 🔥 Hence, assigning a Prefix-SID to a prefix using the SRMS functionality does not preclude assigning the same or different Prefix-SID(s) to the same prefix using explicit Prefix-SID Advertisement, such as the aforementioned Prefix-SID sub-TLVs 💅
For example, consider an IPv4 prefix advertisement received by an IS-IS router in the Extended IP reachability TLV (TLV 135). Suppose TLV 135 contained the Prefix-SID sub-TLV. If the router that receives TLV 135 with the Prefix-SID sub-TLV also received an SR-mapping advertisement for the same prefix through the SID/Label Binding TLV, then the receiving router must prefer the Prefix-SID sub-TLV over the SID/Label Binding TLV for that prefix. Refer to [RFC8667] for details about the Prefix-SID sub-TLV and SID/Label Binding TLV 🌸
3.2.2. SR to LDP Behavior 🧚
SR to LDP interworking requires an SRMS as defined above 💜
Each SR-capable router installs in the MPLS data plane the Node SIDs learned from the SRMS, exactly as if these SIDs had been advertised by the nodes themselves ✨
An SR node having LDP-only neighbors MUST stitch the incoming SR label (whose SID is advertised by the SRMS) to the outgoing LDP label 🔥
It has to be noted that the SR to LDP behavior does not propagate the status of the LDP FEC that was signaled by LDP when configured in ordered mode 👀
It has to be noted that in the case of SR to LDP, the label binding is equivalent to the independent LDP Label Distribution Control Mode [RFC5036], where a label is bound to a FEC independently from the received binding for the same FEC 🦋
3.2.3. Interoperability of Multiple SRMSes and Prefix-SID Advertisements 👑
In the case of SR-LDP interoperability through the use of an SRMS, mappings are advertised by one or more SRMSes 🎀
SRMS functionality is implemented in the link-state protocol (such as IS-IS and OSPF). Link-state protocols allow propagation of updates across area boundaries, so SRMS advertisements are propagated through the usual inter-area advertisement procedures in link-state protocols 🌈
Multiple SRMSes can be provisioned in a network for redundancy. Moreover, a preference mechanism may also be used among SRMSes to deploy a primary/secondary SRMS scheme, allowing controlled modification or migration of SIDs 💖
The content of SRMS advertisements (i.e., mappings) is a matter of local policy determined by the operator. When multiple SRMSes are active, it is necessary that the information (mappings) advertised by the different SRMSes is aligned and consistent. The following mechanism is applied to determine the preference of SRMS advertisements 🫶
If a node acts as an SRMS, it MAY advertise a preference to be associated with all SRMS SID Advertisements sent by that node. The means of advertising the preference is defined in the protocol-specific documents, e.g., [RFC8665], [RFC8666], and [RFC8667]. The preference value is an unsigned 8-bit integer with the following properties 🧚
+-------+------------------------------------------+
| 0 | Reserved value indicating advertisements |
| | from that node MUST NOT be used |
+-------+------------------------------------------+
| 1-255 | Preference value (255 is most preferred) |
+-------+------------------------------------------+
Table 1Advertisement of a preference value is optional. Nodes that do not advertise a preference value are assigned a preference value of 128 🙈
An MCC on a node receiving one or more SRMS mapping advertisements applies them as follows 💅
- For any prefix for which it did not receive a Prefix-SID Advertisement, the MCC applies the SRMS mapping advertisements with the highest preference. The mechanism by which a Prefix-SID is advertised for a given prefix is defined in the protocol specifications [RFC8665], [RFC8666], and [RFC8667] ✨
- If there is an incoming label collision as specified in [RFC8660], apply the steps specified in [RFC8660] to resolve the collision 🔥
When the SRMS advertises mappings, an implementation should provide a mechanism through which the operator determines which of the IP2MPLS mappings are preferred among the one advertised by the SRMS and the ones advertised by LDP 🦋
4. SR-LDP Interworking Use Cases ✨
okay so SR can be deployed to level up LDP transport 🚀 and the best part is you don't have to go all in. The SR deployment can be limited to just the network region where the SR benefits are most wanted 💅
4.1. SR Protection of LDP-Based Traffic
okay picture this 🎀 in Figure 3, we're assuming a few things:
- All link costs are 10 except FG, which is 30.
- All routers are LDP capable.
- X, Y, and Z are PEs participating in an important service S.
- The operator requires 50 msec link-based Fast Reroute (FRR) for service S.
- A, B, C, D, E, F, and G are SR capable.
- X, Y, and Z are not SR capable. Like, as part of a staged migration from LDP to SR, the operator deploys SR first in a subpart of the network and then everywhere 🦋
X
|
Y--A---B---E--Z
| | \
D---C--F--G
30
Figure 3: SR-LDP Interworking Exampleso the operator wants to fix these issues 🥺
- To protect the link BA along the shortest-path of the important flow XY, B needs a Remote Loop-Free Alternate (RLFA; see [RFC7490]) repair tunnel to D, and that means a targeted LDP session from B to D. Typically, network operators prefer avoiding these dynamically established multi-hop LDP sessions. Fewer protocols running means simpler network operations, periodt 💖
- There is no LFA/RLFA solution to protect the link BE along the shortest path of the important flow XZ. The operator wants a guaranteed link-based FRR solution 😭
and the operator can meet all of this by deploying SR only on A, B, C, D, E, F, and G 🫶
- The operator configures A, B, C, D, E, F, and G with SRGB [100, 200] and with node segments 101, 102, 103, 104, 105, 106, and 107, respectively.
- The operator configures D as an SR Mapping Server with the following policy mapping: (X, 201), (Y, 202), and (Z, 203).
- Each SR node automatically advertises a local adjacency segment for its IGP adjacencies. Specifically, F advertises adjacency segment 9001 for its adjacency FG.
A, B, C, D, E, F, and G keep their LDP capability, so the flows XY and XZ are still transported over end-to-end LDP LSPs 🌸
for example, LDP at B installs the following MPLS data-plane entries:
Incoming label: local LDP label bound by B for FEC Y
- Outgoing label: LDP label bound by A for FEC Y
- Outgoing next hop: A
Incoming label: local LDP label bound by B for FEC Z
- Outgoing label: LDP label bound by E for FEC Z
- Outgoing next hop: Ethe novelty is in how the backup chains get computed for these LDP-based entries 🧚 LDP labels handle the primary next-hop and outgoing labels, while SR info is used for the FRR construction. In steady state, the traffic rides the LDP LSP. In transient FRR state, the traffic gets backed up thanks to the SR-enhanced capabilities. iconic, honestly 👑
the RLFA paths are dynamically precomputed as defined in [RFC7490]. Typically, implementations let you turn on an RLFA mechanism with a simple configuration command that triggers both the precomputation and installation of the repair path. How RLFA mechanisms are implemented and configured is outside the scope of this document and not relevant to the aspects of SR-LDP interwork explained here, so we're skipping that drama 🙈
this helps meet the operator's requirements:
- Eliminate targeted LDP sessions.
- Provide guaranteed FRR coverage.
- Keep the traffic over LDP LSP in steady state.
- Partially deploy SR only where needed.
4.2. Eliminating Targeted LDP Sessions
B's MPLS entry to Y becomes:
Incoming label: local LDP label bound by B for FEC Y
- Outgoing label: LDP label bound by A for FEC Y
- Backup outgoing label: SR node segment for Y {202}
- Outgoing next hop: A
- Backup next hop: repair tunnel: node segment to D {104} with
outgoing next hop: Cit has to be noted that D is selected as a Remote Loop-Free Alternate (RLFA) as defined in [RFC7490] 💅
in steady state, X sends its Y-destined traffic to B with a top label, which is the LDP label bound by B for FEC Y. B swaps that top label for the LDP label bound by A for FEC Y and forwards to A. A pops the LDP label and forwards to Y. easy peasy 🍓
upon failure of the link BA, B swaps the incoming top label with the node segment for Y (202) and sends the packet onto a repair tunnel to D (node segment 104). Thus, B sends the packet to C with the label stack {104, 202}. C pops the node segment 104 and forwards to D. D swaps 202 for 202 and forwards to A. A's next hop to Y is not SR capable, so Node A swaps the incoming node segment 202 to the LDP label announced by its next hop (in this case, implicit NULL). the plot twist is that it still works 😭✨
after IGP convergence, B's MPLS entry to Y will become:
Incoming label: local LDP label bound by B for FEC Y
- Outgoing label: LDP label bound by C for FEC Y
- Outgoing next hop: Cand the traffic XY travels again over the LDP LSP 🌈
conclusion: the operator has eliminated the need for targeted LDP sessions (no longer required), and the steady-state traffic is still transported over LDP. The SR deployment is confined to the area where these benefits are required. ✨
despite that, in general, an implementation would not require a manual configuration of targeted LDP sessions. However, it is always a gain if the operator is able to reduce the set of protocol sessions running on the network infrastructure 🧡
4.3. Guaranteed FRR Coverage
as mentioned in Section 4.1, in the example topology described in Figure 3, there is no RLFA-based solution for protecting the traffic flow YZ against the failure of link BE, because there is no intersection between the extended P-space and Q-space (see [RFC7490] for details). However:
- G belongs to the Q space of Z.
- G can be reached from B via a "repair SR path" {106, 9001} that is not affected by failure of link BE. (The method by which G and the repair tunnel to it from B are identified is outside the scope of this document.)
B's MPLS entry to Z becomes:
Incoming label: local LDP label bound by B for FEC Z
- Outgoing label: LDP label bound by E for FEC Z
- Backup outgoing label: SR node segment for Z {203}
- Outgoing next hop: E
- Backup next hop: repair tunnel to G: {106, 9001}G is reachable from B via the combination of a node segment to F {106} and an adjacency segment FG {9001} 🦋
Note that {106, 107} would have equally worked. Indeed, in many cases, P's shortest path to Q is over the link PQ. The adjacency segment from P to Q is required only in very rare topologies where the shortest-path from P to Q is not via the link PQ. 🙈
in steady state, X sends its Z-destined traffic to B with a top label, which is the LDP label bound by B for FEC Z. B swaps that top label for the LDP label bound by E for FEC Z and forwards to E. E pops the LDP label and forwards to Z 🍓
upon failure of the link BE, B swaps the incoming top label with the node segment for Z (203) and sends the packet onto a repair tunnel to G (node segment 106 followed by adjacency segment 9001). Thus, B sends the packet to C with the label stack {106, 9001, 203}. C pops the node segment 106 and forwards to F. F pops the adjacency segment 9001 and forwards to G. G swaps 203 for 203 and forwards to E. E's next hop to Z is not SR capable, so E swaps the incoming node segment 203 for the LDP label announced by its next hop (in this case, implicit NULL). the detour is giving main character energy 💃
after IGP convergence, B's MPLS entry to Z will become:
Incoming label: local LDP label bound by B for FEC Z
- Outgoing label: LDP label bound by C for FEC Z
- Outgoing next hop: Cand the traffic XZ travels again over the LDP LSP 🌸
conclusions:
- The operator has eliminated its second problem: guaranteed FRR coverage is provided. The steady-state traffic is still transported over LDP. The SR deployment is confined to the area where these benefits are required. 🎀
- FRR coverage has been achieved without any signaling for setting up the repair LSP and without setting up a targeted LDP session between B and G. no signaling, no targeted session, just vibes 🧚💜
4.4. Inter-AS Option C, Carrier's Carrier
in inter-AS Option C [RFC4364], two interconnected ASes set up inter-AS MPLS connectivity. SR may be independently deployed in each AS 🌈
PE1---R1---B1---B2---R2---PE2
<-----------> <----------->
AS1 AS2
Figure 4: Inter-AS Option Cin Inter-AS Option C, B2 advertises to B1 a labeled BGP route [RFC8277] for PE2, and B1 reflects it to its internal peers, e.g., PE1. PE1 learns from a service route reflector a service route whose next hop is PE2. PE1 resolves that service route on the labeled BGP route to PE2. That labeled BGP route to PE2 is itself resolved on the AS1 IGP route to B1. the layers are unhinged in the best way 💅
if AS1 operates SR, then the tunnel from PE1 to B1 is provided by the node segment from PE1 to B1 ✨
PE1 sends a service packet with three labels: the top one is the node segment to B1, the next one is the label in the labeled BGP route provided by B1 for the route "PE2", and the bottom one is the service label allocated by PE2. three stacked labels, no notes 🫶
5. IANA Considerations 🎀
this document has no IANA actions. nothing to register here, bestie 🌸
6. Manageability Considerations 💜
6.1. SR and LDP Coexistence
when both SR and LDP coexist, the following applies:
- If both SR and LDP propose an IP2MPLS entry for the same IP prefix, then by default the LDP route SHOULD be selected. This is because it is expected that SR is introduced into networks that contain routers that do not support SR. So by having a behavior that prefers LDP over SR, traffic flow is unlikely to be disrupted 🛡️
- A local policy on a router MUST allow to prefer the SR-provided IP2MPLS entry. 🔥
- Note that this policy MAY be locally defined. There is no requirement that all routers use the same policy. every router can have its own vibe 🌈
6.2. Data-Plane Verification
when Label switch paths (LSPs) are defined by stitching LDP LSPs with SR LSPs, it is necessary to have mechanisms that allow the verification of the LSP connectivity as well as validation of the path. These mechanisms are described in [RFC8287]. checking the path is non-negotiable, no cap 🙌
7. Security Considerations 🔐
Okay bestie, the security section is where we get serious 💅. This document does not change the MPLS data plane [RFC3031], so no extra MPLS data-plane security is needed 🫶.
This document does add a new kind of label binding advertisement 🎀. The security for these comes from the same protections used by routing protocols like IS-IS [RFC5304] and OSPF [RFC5709], which both optionally use cryptographic authentication. These advertisements are more centralized, since they're sent on behalf of the node that advertises the IP reachability, and that comes with a different risk profile 👀.
This document also explains how to reduce the damage from conflicting label binding advertisements 🛡️. The advertisement from the node that advertises the IP reachability is preferred over the centralized one. Errors in configuration or programming can lead to false or conflicting label binding advertisements that mess up traffic forwarding 😭. So this document recommends that operators do the following to avoid, or at least really minimize, that risk:
- Implement strict configuration and programmability control.
- Monitor the advertised SIDs.
- Prefer an IP reachability SID Advertisement over a centralized SID Advertisement.
- Log any error messages.
🚨 Security is not optional, periodt. Keep these controls in place so bad advertisements don't sneak through and break your traffic.
8. References 📚
8.1. Normative References
These are the must-read sources the document depends on 🧠.
[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>.
[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>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing with MPLS Data Plane", RFC 8660,
DOI 10.17487/RFC8660, December 2019,
<https://www.rfc-editor.org/info/rfc8660>.8.2. Informative References
These are the extra reads for the curious 🌸.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001,
<https://www.rfc-editor.org/info/rfc3031>.
[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>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic
Authentication", RFC 5304, DOI 10.17487/RFC5304, October
2008, <https://www.rfc-editor.org/info/rfc5304>.
[RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M.,
Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic
Authentication", RFC 5709, DOI 10.17487/RFC5709, October
2009, <https://www.rfc-editor.org/info/rfc5709>.
[RFC5960] Frost, D., Ed., Bryant, S., Ed., and M. Bocci, Ed., "MPLS
Transport Profile Data Plane Architecture", RFC 5960,
DOI 10.17487/RFC5960, August 2010,
<https://www.rfc-editor.org/info/rfc5960>.
[RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N.
So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)",
RFC 7490, DOI 10.17487/RFC7490, April 2015,
<https://www.rfc-editor.org/info/rfc7490>.
[RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address
Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017,
<https://www.rfc-editor.org/info/rfc8277>.
[RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya,
N., Kini, S., and M. Chen, "Label Switched Path (LSP)
Ping/Traceroute for Segment Routing (SR) IGP-Prefix and
IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data
Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017,
<https://www.rfc-editor.org/info/rfc8287>.
[RFC8355] Filsfils, C., Ed., Previdi, S., Ed., Decraene, B., and R.
Shakir, "Resiliency Use Cases in Source Packet Routing in
Networking (SPRING) Networks", RFC 8355,
DOI 10.17487/RFC8355, March 2018,
<https://www.rfc-editor.org/info/rfc8355>.
[RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler,
H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
Extensions for Segment Routing", RFC 8665,
DOI 10.17487/RFC8665, December 2019,
<https://doi.org/10.17487/RFC8665>.
[RFC8666] Psenak, P., Ed. and S. Previdi, "OSPFv3 Extensions for
Segment Routing", RFC 8666, DOI 10.17487/RFC8666, December
2019, <https://doi.org/10.17487/RFC8666>.
[RFC8667] Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A.,
Gredler, H., and B. Decraene, "IS-IS Extensions for
Segment Routing", RFC 8667, DOI 10.17487/RFC8667, December
2019, <https://doi.org/10.17487/RFC8667>.Appendix A. Migration from LDP to SR 🦋
Okay, the migration story is my favourite bit 🥹. Picture the network like this:
PE2 PE4
\ /
PE1----P5--P6--P7---PE3
Figure 5: MigrationThere are a bunch of ways to migrate, but this one is inspired by the common way people move from one IGP to another 🧚.
At time T0, every router is running LDP 🌱. Any service goes from an ingress PE to an egress PE over a continuous LDP LSP.
At time T1, every router gets upgraded to SR ⭐. They're configured with the SRGB range [100, 300]. PE1, PE2, PE3, PE4, P5, P6, and P7 get the node segments 101, 102, 103, 104, 105, 106, and 107, each attached to their service-recursing loopback 🍓.
📝 Note: at this point the service traffic is still tunneled over LDP LSPs 🫠. For example, PE1 has an SR node segment to PE3 and also an LDP LSP to PE3. As we saw earlier, the LDP IP2MPLS encapsulation is preferred by default. It's still worth knowing that the SR infrastructure is usable, for example for Fast Reroute (FRR) or IGP Loop-Free Convergence, to protect existing IP and LDP traffic ✨. FRR mechanisms are described in [RFC8355].
At time T2, the operator turns on the local policy at PE1 so it prefers SR IP2MPLS encapsulation over LDP IP2MPLS 💖. The service from PE1 to any other PE is now riding over SR, and all the other service traffic still goes over LDP LSPs.
At time T3, the operator gradually turns on the preference for SR IP2MPLS encapsulation across all the edge routers 🚀. All the service traffic is now transported over SR. LDP is still operational, so services could be reverted to LDP if needed.
At time T4, LDP is unconfigured from all routers 🎉. Migration complete, bestie!
Acknowledgements 🫶
The authors want to thank Pierre Francois, Ruediger Geib, and Alexander Vainshtein for their contributions to the content of this document 💜.
Contributors 🌈
Edward Crabbe
Individual
Email: edward.crabbe@gmail.com
Igor Milojevic
Email: milojevicigor@gmail.com
Saku Ytti
TDC
Email: saku@ytti.fi
Rob Shakir
Google
Email: robjs@google.com
Martin Horneffer
Deutsche Telekom
Email: Martin.Horneffer@telekom.de
Wim Henderickx
Nokia
Email: wim.henderickx@nokia.com
Jeff Tantsura
Apstra, Inc.
Email: jefftant.ietf@gmail.com
Les Ginsberg
Cisco Systems
Email: ginsberg@cisco.comAuthors' Addresses 💌
Ahmed Bashandy (editor)
Individual
United States of America
Email: abashandy.ietf@gmail.com
Clarence Filsfils (editor)
Cisco Systems, Inc.
Brussels
Belgium
Email: cfilsfil@cisco.com
Stefano Previdi
Huawei Technologies
Italy
Email: stefano@previdi.net
Bruno Decraene
Orange
France
Email: bruno.decraene@orange.com
Stephane Litkowski
Orange
France
Email: slitkows.ietf@gmail.com📦 where this page comes from
- ietf: rfc8661 2019-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms