RFC 7392
Explicit Path Routing for Dynamic Multi-Segment Pseudowires
RFC 7392: Explicit Path Routing for Dynamic Multi-Segment Pseudowires 🎀
okay bestie, this one is RFC 7392, titled Explicit Path Routing for Dynamic Multi-Segment Pseudowires. It's a Standards Track doc (ISSN 2070-1721), dated December 2014. The authors are P. Dutta and M. Bocci from Alcatel-Lucent, plus L. Martini from Cisco Systems. It doesn't list anything it obsoletes or updates. 💖
Abstract ✨
so picture this: when a dynamic Multi-Segment Pseudowire (MS-PW) gets set up along an explicit path, it can be the easy answer for 1:1 protection with diverse primary and backup MS-PWs for a service. It can also give you controlled signaling (strict or loose) for special MS-PWs. 🦋 This doc lays out the extensions and procedures needed to get dynamic MS-PWs established along explicit paths. iconic.
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 got public review and was approved for publication by the Internet Engineering Steering Group (IESG). if you want more on Internet Standards, check Section 2 of RFC 5741.
for the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7392. 💅
Copyright Notice 🌈
Copyright (c) 2014 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 in effect on the date of publication. please read those carefully, because they describe your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text, as 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 ....................................................2
2. Requirements Language and Terminology ...........................3
3. Explicit Path in MS-PW Signaling ................................3
3.1. S-PE Addressing ............................................3
3.2. Explicit Route TLV (ER-TLV) ................................3
3.3. Explicit Route Hop TLV (ER-Hop TLV) ........................4
3.4. ER-Hop Semantics ...........................................4
3.4.1. ER-Hop Type: IPv4 Prefix ............................4
3.4.2. ER-Hop Type: IPv6 Prefix ............................4
3.4.3. ER-Hop Type: L2 PW Address ..........................5
4. Explicit Route TLV Processing ...................................6
4.1. Next-Hop Selection .........................................6
4.2. Adding ER Hops to the Explicit Route TLV ...................8
5. IANA Considerations .............................................8
6. Security Considerations .........................................8
7. Normative References ............................................9
Acknowledgements ...................................................9
Authors' Addresses ................................................101. Introduction 🎀
okay so dynamic MS-PWs are set up with their paths figured out automatically by a dynamic routing protocol. that whole process is defined in [RFC7267]. 🧠
for 1:1 protection of MS-PWs with primary and backup paths, the MS-PWs have to go through a diverse set of Switching Provider Edges (S-PEs). that way there's no single point of failure at the PW level. [RFC7267] handles this with BGP-based mechanisms. 💜
this doc adds another option. it lets Source Terminating Provider Edges (ST-PEs) explicitly pick the path a PW takes through the S-PEs in the middle. explicit path routing for dynamic MS-PWs can also be useful for controlled setup and network resource management. ✨
bestie, heads up: in lots of deployments the ST-PE won't have a view of the S-PE topology. so the explicit route needs to come from a management application. how that app figures out the route is outside the scope of this doc. 🙈
2. Requirements Language and Terminology 🦋
here's the BCP 14 vibe: the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in [RFC2119]. 📖
this doc uses the terminology defined in [RFC7267], [RFC4447], and [RFC5036]. 🧚
there's also one extra term:
- Abstract Node: a group of nodes (S-PEs) that represents an explicit hop along the path of an MS-PW. an abstract node gets identified by an IPv4, IPv6, or S-PE address. 💅
3. Explicit Path in MS-PW Signaling 🌸
this section covers the Label Distribution Protocol (LDP) extensions you need to signal explicit paths in dynamic MS-PW setup messages. an explicitly routed MS-PW is set up with a Label Mapping message that carries an ordered list of the S-PEs the MS-PW is expected to traverse. that list gets encoded as a series of Explicit Route Hop TLVs (ER-Hop TLVs), wrapped in an ER-TLV, which rides inside a Label Mapping message. it's giving organized. 👑
3.1. S-PE Addressing 🌷
an S-PE address is how you identify a particular S-PE among the S-PEs in the Packet Switched Networks (PSNs) that an MS-PW might use. 🗺️
every S-PE MUST be assigned an address as specified in Section 3.2 of [RFC7267]. now, an S-PE that can do dynamic MS-PW signaling but hasn't been assigned an S-PE address, and that gets a Label Mapping message for a dynamic MS-PW, MUST follow the procedures in Section 3.2 of [RFC7267]. no skipping! 🙅♀️
3.2. Explicit Route TLV (ER-TLV) 💖
the ER-TLV describes the path the MS-PW being set up is going to take. each hop on that path is an abstract node, which is a group of one or more S-PEs, identified by an IPv4, IPv6, or S-PE address. the ER-TLV format follows Section 4.1 of [RFC3212]. 🎀
the ER-TLV holds one or more ER-Hop TLVs, as defined in Section 3.3. 🧁
3.3. Explicit Route Hop TLV (ER-Hop TLV) 🍭
the contents of an ER-TLV are a series of variable-length ER-Hop TLVs. each hop carries the identification of an "abstract node" representing the hop to traverse. the ER-Hop TLV format is the one specified in Section 4.2 of [RFC3212]. ✨
[RFC3212] defines four ER-Hop TLV Types: IPv4 Prefix, IPv6 Prefix, Autonomous System Number, and LSP-ID. this doc adds one new ER-Hop TLV Type:
Value Type
------ --------------------------------
0x0805 L2 PW Address of Switching Point ER-Hop TLVthe details of ER-Hop semantics are in Section 3.4. 🦋
3.4. ER-Hop Semantics 💜
this section covers the different semantics that go with the ER-Hop TLV. 🧠
3.4.1. ER-Hop Type: IPv4 Prefix 🌈
the semantics for the IPv4 ER-Hop TLV Type are specified in [RFC3212], Section 4.7.1. 🫶
3.4.2. ER-Hop Type: IPv6 Prefix 🌸
the semantics for the IPv6 ER-Hop TLV Type are specified in [RFC3212], Section 4.7.2. 💅
3.4.3. ER-Hop Type: L2 PW Address 🔥
the L2 PW Address ER-Hop TLV Type carries the L2 PW Address derived from the Generalized PWid Forwarding Equivalence Class (FEC) AII Type 2 structure, as defined in [RFC5003]. here's how it looks:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| ER-Hop Type | Length = 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Reserved | PreLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type=02 | Length | Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global ID (contd.) | Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix (contd.) | AC ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+here's what each field does:
- U/F: these bits MUST be set to zero, and the procedures of [RFC5036] MUST be followed when the TLV is not known to the receiving node. 🙈
- Type: a fourteen-bit field carrying the value of the ER-Hop 3, L2 PW Address, Value =
0x0805. - Length: specifies the length of the value field in bytes = 18.
- L Bit: set to indicate a loose hop. Cleared to indicate a strict hop. 🌟
- Reserved: zero on transmission. Ignored on receipt.
- PreLen: Prefix Length 1-96 (including the length of the Global ID, Prefix, and AC ID fields).
- Everything else (AII Type, Length, Global ID, Prefix, and AC ID) defines the L2 PW Address and is set and interpreted as defined in Section 3.2 of [RFC5003]. 🧚
4. Explicit Route TLV Processing 👑
the rest of section 4 (and everything after it) is coming up in part 2. stay tuned, bestie! 🫶
4.1. Next-Hop Selection 🛤️
okay so a PW Label Mapping message with an Explicit Route TLV is basically telling everyone the next stop on an MS-PW path 🚏. When the ST-PE or S-PE inserting the ER-Hop TLV picks that next hop, it might have to choose from a few alternatives 💅. How that choice gets made is implementation specific and outside the scope of this document 🤷. Same deal for how a particular path gets selected, which is also out of scope, but each node MUST determine a loop-free path if it is to signal the MS-PW 🔁. [RFC6073], Section 7.6 has a mechanism a node can use to check that the path taken by an MS-PW does not include loops ✅.
As noted in Section 1, in lots of deployments the ST-PE won't have a view of the S-PE topology, so the path will need to be supplied from a management application 📋.
If a loop-free path can't be found by an ST-PE or S-PE, then a node MUST NOT attempt to signal the MS-PW 🚫. For an S-PE, if it can't determine a loop-free path, the received Label Mapping message MUST be released with a status code of "PW Loop Detected" as per Section 4.2.3 of [RFC7267] 💀.
To work out the next hop for the MS-PW path, a node follows these steps 🧠. These procedures assume that a valid S-PE address has been assigned to the node, as per Section 3.1, above 🎀.
- The node receiving the Label Mapping message that contains an ER-TLV MUST evaluate the first ER-Hop. If the L bit is not set in the first ER-Hop and the node is not part of the abstract node described by the first ER-Hop (i.e., it does not lie within the prefix as determined by the prefix length specified in the ER-Hop TLV), it has received the message in error. Therefore, the node MUST reply with a Label Release message with a "Bad Initial ER-Hop Error" (0x04000004) status code 🙈. If the L bit is set and the local node is not part of the abstract node described by the first ER-Hop, the node selects a next hop that is along the path to the abstract node described by the first ER-Hop ✨. If there is no ER-Hop TLV contained in the ER-TLV, the message is also in error, and the node SHOULD return a "Bad Explicit Routing TLV Error" (0x04000001) status code in a Label Release message sent to the upstream node 😭. Note that this statement does not preclude a Label Mapping message with no ER-TLV. If a Label Mapping message with no ER-TLV is received, then it MUST be processed as per [RFC7267] 🫶.
- If there are no further ER-Hop TLVs following the first ER-Hop TLV, this means the end of the explicit route 🏁. The Explicit Route TLV MUST be removed from the Label Mapping message. This node may or may not be the end of the PW 🤷♀️. Processing continues as per Section 4.2, where a new Explicit Route TLV MAY be added to the Label Mapping message 🌸.
- If a second ER-Hop TLV does exist, and the node is also part of the abstract node described by the second ER-Hop, then the node deletes the first ER-Hop and continues processing with step 2, above 🦋. Note that this makes the second ER-Hop into the first ER-Hop for the iteration for the next PW segment 👑.
- The node determines if it is topologically adjacent to the abstract node described by the second ER-Hop. That is, it is directly connected to the next node by a PW control-plane adjacency 🔗. If so, the node selects a particular next hop that is a member of the abstract node. The node then deletes the first ER-Hop and continues processing as per Section 4.2, below 💖.
- Next, the node selects a next hop within the abstract node of the first ER-Hop that is along the path to the abstract node of the second ER-Hop 🗺️. If no such path exists, then there are two cases:
- A. If the second ER-Hop is a strict ER Hop, then there is an error, and the node MUST return a Label Release message to the upstream node with a "Bad Strict Node Error" (0x04000002) status code 🚨.
- B. Otherwise, if the second ER-Hop is a loose ER Hop, then the node selects any next hop that is along the path to the next abstract node. If no path exists within the MPLS domain, then there is an error, and the node MUST return a Label Release message to the upstream node with a "Bad Loose Node Error" (0x04000003) status code 🥲.
- Finally, the node replaces the first ER-Hop with any ER Hop that denotes an abstract node containing the next hop 💅. This is necessary so that when the explicit route is received by the next hop, it will be accepted 🎀.
- Progress the Label Mapping message to the next hop 🚀.
4.2. Adding ER Hops to the Explicit Route TLV 🧩
After selecting a next hop, the node MAY alter the explicit route in the following ways 💜.
If, as part of executing the algorithm in Section 4.1, the Explicit Route TLV is removed, then the node MAY add a new Explicit Route TLV 🌈.
Otherwise, if the node is a member of the abstract node for the first ER-Hop, then a series of ER Hops MAY be inserted before the First ER Hop, or the first ER-Hop MAY be replaced. Each ER Hop in this series MUST denote an abstract node that is a subset of the current abstract node 🍓.
Alternately, if the first ER-Hop is a loose ER Hop, an arbitrary series of ER Hops MAY be inserted prior to the first ER-Hop 🦄.
5. IANA Considerations 🎀
RFC 5036 [RFC5036] defines the LDP TLV name space, which is maintained by IANA, in the LDP "TLV Type Name Space" registry. TLV types for the Explicit Route TLV, the IPv4 Prefix ER-Hop TLV, and the IPv6 Prefix ER-Hop TLV are already defined in this registry 📒.
IANA has assigned a further code point from the IETF consensus portion of this registry as follows ✨:
TLV Type Value Reference
------------------------------------ ------ -------------
L2 PW Address of Switching Point 0x0805 This Document6. Security Considerations 💀
This is the serious bit, bestie, so read it carefully 🫣.
This document introduces no new security considerations beyond those discussed in [RFC5036], [RFC4447], and [RFC7267]. The security considerations detailed in those documents apply to the protocol extensions described in this RFC 🔐.
As with [RFC7267], it should be noted that the path selection mechanisms specified in this document enable the network to automatically select the S-PEs that are used to forward packets on the MS-PW 🤖. Appropriate tools, such as the Virtual Circuit Connectivity Verification (VCCV) trace mechanisms specified in [RFC6073], can be used by an operator of the network to verify the path taken by the MS-PW and therefore be satisfied that the path does not represent an additional security risk 🛡️✨.
7. Normative References 📚
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3212] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu,
L., Doolan, P., Worster, T., Feldman, N., Fredette, A.,
Girish, M., Gray, E., Heinanen, J., Kilty, T., and A.
Malis, "Constraint-Based LSP Setup using LDP", RFC 3212,
January 2002, <http://www.rfc-editor.org/info/rfc3212>.
[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,
<http://www.rfc-editor.org/info/rfc4447>.
[RFC5003] Metz, C., Martini, L., Balus, F., and J. Sugimoto,
"Attachment Individual Identifier (AII) Types for
Aggregation", RFC 5003, September 2007,
<http://www.rfc-editor.org/info/rfc5003>.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007,
<http://www.rfc-editor.org/info/rfc5036>.
[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M.
Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011,
<http://www.rfc-editor.org/info/rfc6073>.
[RFC7267] Martini, L., Bocci, M., and F. Balus, "Dynamic Placement
of Multi-Segment Pseudowires", RFC 7267, June 2014,
<http://www.rfc-editor.org/info/rfc7267>.Acknowledgements 🫶
The authors gratefully acknowledge the contribution of the RFC 3212 [RFC3212] authors for the specification of the ER TLV and the ER-Hop TLV, which are reused by this document. The authors also gratefully acknowledge the input of Lizhong Jin 💖.
Authors' Addresses 💌
Pranjal Kumar Dutta
Alcatel-Lucent
701 E. Middlefield Road
Mountain View, California 94043
United States
EMail: pranjal.dutta@alcatel-lucent.com
Matthew Bocci
Alcatel-Lucent
Voyager Place, Shoppenhangers Road
Maidenhead, Berks SL6 2PJ
United Kingdom
EMail: matthew.bocci@alcatel-lucent.com
Luca Martini
Cisco Systems
9155 East Nichols Avenue, Suite 400
Englewood, Colorado 80112
United States
EMail: lmartini@cisco.com📦 where this page comes from
- ietf: rfc7392 2014-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms