RFC 6074

Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)

📅 published January 2011, from ietf

RFC 6074: Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs) 💖

okay so, the title block first 🎀 This one is an IETF doc (Internet Engineering Task Force). It's RFC 6074, and it's filed as a Standards Track document, so it's an actual protocol spec, not just a chill FYI. The authors are E. Rosen and B. Davie from Cisco Systems, Inc., plus V. Radoaca from Alcatel-Lucent and W. Luo. The ISSN is 2070-1721, and it's dated January 2011 📅. The title block doesn't list anything it obsoletes or updates, so no drama there ✨.

Abstract 🌸

Okay, so provider-provisioned Layer 2 VPNs (L2VPNs) can have different "provisioning models" 🧩. That's just a fancy way of saying models for what info needs to get configured, and in which entities. Once it's configured, the info gets spread around by a "discovery process" 📣. When discovery wraps up, a signaling protocol gets triggered automatically to build the mesh of pseudowires (PWs) that makes up the (virtual) backbone of the L2VPN. This doc specifies a bunch of L2VPN provisioning models, and it also spells out the semantic structure of the endpoint identifiers each model needs 💅. It talks about how those identifiers get distributed by discovery, especially when discovery runs over the Border Gateway Protocol (BGP) 🦋. Then it explains how those identifiers ride along in the two signaling protocols used to set up PWs: the Label Distribution Protocol (LDP) and the Layer 2 Tunneling Protocol version 3 (L2TPv3) 🔥.

Status of This Memo 📝

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6074.

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, since they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English 🙈.

Table of Contents 🗂️

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Signaling Protocol Framework . . . . . . . . . . . . . . . . .  5
     2.1.  Endpoint Identification  . . . . . . . . . . . . . . . . .  5
     2.2.  Creating a Single Bidirectional Pseudowire . . . . . . . .  7
     2.3.  Attachment Identifiers and Forwarders  . . . . . . . . . .  7
   3.  Applications . . . . . . . . . . . . . . . . . . . . . . . . .  9
     3.1.  Individual Point-to-Point Pseudowires  . . . . . . . . . .  9
       3.1.1.  Provisioning Models  . . . . . . . . . . . . . . . . .  9
         3.1.1.1.  Double-Sided Provisioning  . . . . . . . . . . . .  9
         3.1.1.2.  Single-Sided Provisioning with Discovery . . . . .  9
       3.1.2.  Signaling  . . . . . . . . . . . . . . . . . . . . . . 10
     3.2.  Virtual Private LAN Service  . . . . . . . . . . . . . . . 11
       3.2.1.  Provisioning . . . . . . . . . . . . . . . . . . . . . 11
       3.2.2.  Auto-Discovery . . . . . . . . . . . . . . . . . . . . 12
         3.2.2.1.  BGP-Based Auto-Discovery . . . . . . . . . . . . . 12
       3.2.3.  Signaling  . . . . . . . . . . . . . . . . . . . . . . 14
       3.2.4.  Pseudowires as VPLS Attachment Circuits  . . . . . . . 15
     3.3.  Colored Pools: Full Mesh of Point-to-Point Pseudowires . . 15
       3.3.1.  Provisioning . . . . . . . . . . . . . . . . . . . . . 15
       3.3.2.  Auto-Discovery . . . . . . . . . . . . . . . . . . . . 16
         3.3.2.1.  BGP-Based Auto-Discovery . . . . . . . . . . . . . 16
       3.3.3.  Signaling  . . . . . . . . . . . . . . . . . . . . . . 18
     3.4.  Colored Pools: Partial Mesh  . . . . . . . . . . . . . . . 19
     3.5.  Distributed VPLS . . . . . . . . . . . . . . . . . . . . . 19
       3.5.1.  Signaling  . . . . . . . . . . . . . . . . . . . . . . 21
       3.5.2.  Provisioning and Discovery . . . . . . . . . . . . . . 23
       3.5.3.  Non-Distributed VPLS as a Sub-Case . . . . . . . . . . 23
       3.5.4.  Splicing and the Data Plane  . . . . . . . . . . . . . 24
   4.  Inter-AS Operation . . . . . . . . . . . . . . . . . . . . . . 24
     4.1.  Multihop EBGP Redistribution of L2VPN NLRIs  . . . . . . . 24
     4.2.  EBGP Redistribution of L2VPN NLRIs with Multi-Segment
           Pseudowires  . . . . . . . . . . . . . . . . . . . . . . . 25
     4.3.  Inter-Provider Application of Distributed VPLS
           Signaling  . . . . . . . . . . . . . . . . . . . . . . . . 26
     4.4.  RT and RD Assignment Considerations  . . . . . . . . . . . 27
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 28
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 28
   7.  BGP-AD and VPLS-BGP Interoperability . . . . . . . . . . . . . 29
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 30
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 30
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 31

1. Introduction ✨

Okay so [RFC4664] breaks down all the different ways sets of pseudowires can get combined into "Provider Provisioned Layer 2 VPNs" (L2 PPVPNs, or L2VPNs) 🦋, and that means there are lots of different kinds of L2VPN. Different kinds can have different "provisioning models", aka different models for what info needs to get configured in what entities. Once everything's configured, the provisioning info gets distributed by a "discovery process", and once it's discovered, the signaling protocol gets automatically invoked to set up the required pseudowires 🔥. The semantics of the endpoint identifiers that the signaling protocol uses for a certain type of L2VPN are decided by the provisioning model. So different kinds of L2VPN, with different provisioning models, need different kinds of endpoint identifiers 💖. This document specifies a bunch of L2VPN provisioning models and the semantic structure of the endpoint identifiers each model requires.

Either LDP (as specified in [RFC5036] and extended in [RFC4447]) or L2TP version 3 (as specified in [RFC3931] and extended in [RFC4667]) can be used as signaling protocols to set up and maintain PWs [RFC3985]. Any protocol that sets up connections has to give each endpoint a way to identify the other one, so each PW signaling protocol gives a way to identify the PW endpoints 🧚. Since each signaling protocol has to support all the different kinds of L2VPN and provisioning models, the signaling protocol must have a super general way of representing endpoint identifiers, and it's necessary to have rules for encoding each particular kind of endpoint identifier into the relevant fields of each signaling protocol 🫶. This document specifies how to encode the endpoint identifiers of each provisioning model into the LDP and L2TPv3 signaling protocols.

We make free use of terminology from [RFC3985], [RFC4026], [RFC4664], and [RFC5659] -- in particular, the terms "Attachment Circuit", "pseudowire", "PE" (provider edge), "CE" (customer edge), and "multi-segment pseudowire" 🌈.

Section 2 gives you an overview of the relevant parts of [RFC4447] and [RFC4667] 🍓.

Section 3 goes through the various provisioning models and connects them to the signaling process and the discovery process 💜. The way signaling mechanisms can be integrated with BGP-based auto-discovery gets covered in pretty good detail.

Section 4 explains how the discovery and signaling procedures can be applied in a multi-AS environment, and it outlines several options for setting up multi-AS L2VPNs 👑.

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. Signaling Protocol Framework 🎀

2.1. Endpoint Identification

Okay bestie, so per [RFC4664] 🎀, a pseudowire is basically a relationship between a pair of "Forwarders" ✨. In simple VPWS (Virtual Private Wire Service) 💅, a Forwarder binds a pseudowire to one single Attachment Circuit, so frames that come in on one get sent out the other, and vice versa 🦋. In VPLS (Virtual Private LAN Service) 🌸, a Forwarder binds a whole set of pseudowires to a set of Attachment Circuits. When a frame shows up from any member of that set, the Forwarder checks a MAC (Media Access Control) address table and runs various 802.1d procedures to figure out which member or members the frame goes out on 😭. It gets even more fancy 👑 when Forwarders bind PWs to PWs, "splicing" two PWs together. You need that for things like distributed VPLS and some inter-AS setups 🔥.

In simple VPWS, where a Forwarder binds exactly one PW to exactly one Attachment Circuit, you can identify the Forwarder by identifying its Attachment Circuit 🧚. In simple VPLS, you identify a Forwarder by its PE device and its VPN 💜.

To set up a PW between a pair of Forwarders, the signaling protocol has to let the Forwarder at one end identify the Forwarder at the other end 🫶. [RFC4447] calls the quantity that does this job the "Attachment Identifier", or "AI". [RFC4667] calls the same thing the "Forwarder Identifier". In this document, those two terms are totally interchangeable 🌈.

[RFC4447] gives us two Forwarding Equivalence Class (FEC) elements for setting up pseudowires: the PWid FEC element and the Generalized ID FEC element 🍓. The PWid FEC element only carries one Forwarder identifier, so it can only be used when both Forwarders have the same identifier and that identifier can be coded as a 32-bit quantity. The Generalized ID FEC element carries two Forwarder identifiers, one for each of the two Forwarders being connected. Each one is known as an Attachment Identifier, and a signaling message carries both a "Source Attachment Identifier" (SAI) and a "Target Attachment Identifier" (TAI) 💖.

The Generalized ID FEC element also gives the identifiers some extra structure ✨. The SAI and TAI will sometimes have a common part, called the "Attachment Group Identifier" (AGI), so each one can be thought of as the AGI plus an "Attachment Individual Identifier" (AII) 🧩. That means the pair gets encoded into three fields: AGI, Source AII (SAII), and Target AII (TAII). The SAI is the AGI concatenated with the SAII, and the TAI is the AGI concatenated with the TAII.

[RFC4667] lets you use one or two Forwarder Identifiers to set up pseudowires 🦋. If only the target Forwarder Identifier is used in L2TP signaling messages, both the source and target Forwarders are assumed to have the same value. If both the source and target Forwarder Identifiers are carried in L2TP signaling messages, each Forwarder uses a locally significant identifier value.

The Forwarder Identifier in [RFC4667] is an equivalent term to the Attachment Identifier in [RFC4447] 🎀. A Forwarder Identifier also consists of an AGI and an AII. The difference is that, unlike the Generalized ID FEC element, the AGI and AII get carried in distinct L2TP Attribute-Value Pairs (AVPs) 🌸. The AGI is encoded in the AGI AVP, and the SAII and TAII are encoded in the Local End ID AVP and the Remote End ID AVP, respectively. The source Forwarder Identifier is the AGI concatenated with the SAII, and the target Forwarder Identifier is the AGI concatenated with the TAII.

In applications that group sets of PWs into "Layer 2 Virtual Private Networks", the AGI can be thought of as a "VPN Identifier" 💜.

👀 Heads up: even though different forwarders support different applications, the type of application (like VPLS vs. VPWS) cannot necessarily be inferred from the forwarders' identifiers 🙈. A router that receives a signaling message with a particular TAI has to be able to work out which of its local forwarders that TAI identifies, and what application that forwarder provides. But other nodes may not be able to infer the application just by inspecting the signaling messages.

In this document, some further structure for the AGI and AII is proposed for certain L2VPN applications 🌈. [RFC4447] already defines a TLV structure for AGI and AII fields. So an operator who chooses to use the AII structure defined here could still use different AGI or AII types if they wanted a different structure for these identifiers for some other application ✨. For example, the long prefix type of [RFC5003] could be used to enable the communication of administrative information, perhaps combined with information learned during auto-discovery 🧚.

2.2. Creating a Single Bidirectional Pseudowire

In any form of LDP-based signaling, each PW endpoint must initiate the creation of a unidirectional LSP. A PW is a pair of such LSPs 💖. In most of the L2VPN provisioning models, the two endpoints of a given PW can simultaneously initiate the signaling for it. So they need some way to determine when a given pair of LSPs is intended to be associated together as a single PW 🫠.

The way this association is done is different for the various L2VPN services and provisioning models 💅. The details appear in later sections.

L2TP signaling inherently establishes a bidirectional session that carries a PW between two PW endpoints ✨. The two endpoints can also simultaneously initiate the signaling for a given PW 👯. It is possible that two PWs can be established for a pair of Forwarders.

In order to avoid setting up duplicated pseudowires between two Forwarders, each PE must be able to independently detect such a pseudowire tie 🚫. The procedures for detecting a pseudowire tie are described in [RFC4667] 🔍.

2.3. Attachment Identifiers and Forwarders

Every Forwarder in a PE must be associated with an Attachment Identifier (AI), either through configuration or through some algorithm 🎀. The Attachment Identifier must be unique in the context of the PE router in which the Forwarder resides. The combination <PE router, AI> must be globally unique 🌍.

As specified in [RFC4447], the Attachment Identifier may consist of an Attachment Group Identifier (AGI) plus an Attachment Individual Identifier (AII) 💅. In the context of this document, an AGI may be thought of as a VPN-ID, or some attribute that is shared by all the Attachment Circuits that are allowed to be connected 🫶.

It is sometimes helpful to consider a set of attachment circuits at a single PE to belong to a common "pool" 🧺. For example, a set of attachment circuits that connect a single CE to a given PE may be considered a pool. The use of pools is described in detail in Section 3.3 📖.

The details for how to construct the AGI and AII fields identifying the pseudowire endpoints in particular provisioning models are discussed later in this document 🔜.

We can now consider an LSP for one direction of a pseudowire to be identified by:

  • <PE1, <AGI, AII1>, PE2, <AGI, AII2>>

and the LSP in the opposite direction of the pseudowire will be identified by:

  • <PE2, <AGI, AII2>, PE1, <AGI, AII1>>

A pseudowire is a pair of such LSPs. In the case of using L2TP signaling, these refer to the two directions of an L2TP session 🦋.

When a signaling message is sent from PE1 to PE2, and PE1 needs to refer to an Attachment Identifier that has been configured on one of its own Attachment Circuits (or pools), the Attachment Identifier is called a "Source Attachment Identifier" 📤. If PE1 needs to refer to an Attachment Identifier that has been configured on one of PE2's Attachment Circuits (or pools), the Attachment Identifier is called a "Target Attachment Identifier" 📥. (So an SAI at one endpoint is a TAI at the remote endpoint, and vice versa 🔁.)

In the signaling protocol, we define encodings for the following three fields:

  • Attachment Group Identifier (AGI)
  • Source Attachment Individual Identifier (SAII)
  • Target Attachment Individual Identifier (TAII)

If the AGI is non-null, then the SAI consists of the AGI together with the SAII, and the TAI consists of the TAII together with the AGI. If the AGI is null, then the SAII and TAII are the SAI and TAI, respectively 🧩.

The intention is that the PE that receives an LDP Label Mapping message or an L2TP Incoming Call Request (ICRQ) message containing a TAI will be able to map that TAI uniquely to one of its Attachment Circuits (or pools) 🎯. The way in which a PE maps a TAI to an Attachment Circuit (or pool) should be a local matter (including the choice of whether to use some or all of the bytes in the TAI for the mapping). So as far as the signaling procedures are concerned, the TAI is really just an arbitrary string of bytes, a "cookie" 🍪.

3. Applications 🌷

In this section, we specify the way in which the pseudowire signaling using the notion of source and target Forwarder is applied for a number of different applications 🧁. For some of the applications, we specify the way in which different provisioning models can be used. However, this is not meant to be an exhaustive list of the applications, or an exhaustive list of the provisioning models that can be applied to each application 🙈.

3.1. Individual Point-to-Point Pseudowires

The signaling specified in this document can be used to set up individually provisioned point-to-point pseudowires 💖. In this application, each Forwarder binds a single PW to a single Attachment Circuit. Each PE must be provisioned with the necessary set of Attachment Circuits, and then certain parameters must be provisioned for each Attachment Circuit 🎀.

3.1.1. Provisioning Models

3.1.1.1. Double-Sided Provisioning

In this model, the Attachment Circuit must be provisioned with a local name, a remote PE address, and a remote name 🌸. During signaling, the local name is sent as the SAII, the remote name as the TAII, and the AGI is null 💜. If two Attachment Circuits are to be connected by a PW, the local name of each must be the remote name of the other 🫶.

👀 Note that if the local name and the remote name are the same, the PWid FEC element can be used instead of the Generalized ID FEC element in the LDP-based signaling.

With L2TP signaling, the local name is sent in the Local End ID AVP, and the remote name in the Remote End ID AVP 🧚. The AGI AVP is optional. If present, it contains a zero-length AGI value 🍓. If the local name and the remote name are the same, the Local End ID AVP can be omitted from L2TP signaling messages ✨.

3.1.1.2. Single-Sided Provisioning with Discovery ✨

okay so in this model, every Attachment Circuit must be provisioned with a local name 🎀 The local name is made of a VPN-ID (signaled as the AGI) and an Attachment Individual Identifier that is unique relative to the AGI 💅 If two Attachment Circuits are going to be connected by a PW, only one of them needs a remote name, and that remote name is just the local name of the other Attachment Circuit 🦋 Neither one needs the address of the remote PE, but both must have the same VPN-ID 🫶

Auto-discovery is where the magic happens ✨ Each PE advertises its <VPN-id, local AII> pairs. Then each PE compares its own local <VPN-id, remote AII> pairs with the <VPN-id, local AII> pairs that the other PEs advertised 👀 Say PE1 has a local <VPN-id, remote AII> pair with value <V, fred>, and PE2 has a local <VPN-id, local AII> pair with value <V, fred>. PE1 can then figure out that it needs to connect to PE2 😭 When it signals, it uses "fred" as the TAII and V as the AGI. PE1's local name for its Attachment Circuit gets sent as the SAII 🌸

The big perk of this provisioning model, compared to Double-Sided Provisioning, is that you can move an Attachment Circuit from one PE to another without reconfiguring the remote endpoint 🧚 The catch is that compared to the approach in Section 3.3 below, it puts more pressure on the discovery mechanism, because each Attachment Circuit's name has to be advertised individually. There's no aggregation of Attachment Circuit names in this simple scheme 💀

3.1.2. Signaling

The LDP-based signaling follows the procedures in [RFC4447] 💜 So basically, one PE (PE1) sends a Label Mapping message to another PE (PE2) to set up an LSP in one direction. If that message gets processed successfully, and there isn't yet an LSP for the pseudowire in the opposite (PE1->PE2) direction, then PE2 sends a Label Mapping message back to PE1 🔥

On top of the procedures in [RFC4447], when a PE receives a Label Mapping message and the TAI identifies a particular Attachment Circuit that is configured to be bound to a point-to-point PW, the following checks must be made 🍓

If the Attachment Circuit is already bound to a pseudowire (this includes the case where only one of the two LSPs currently exists), and the remote endpoint is not PE1, then PE2 sends a Label Release message to PE1 with a Status Code meaning "Attachment Circuit bound to different PE". The processing of the Mapping message is then complete 🙈

If the Attachment Circuit is already bound to a pseudowire (again, this includes the case where only one of the two LSPs currently exists), but the AI at PE1 is different than the one specified in the AGI/SAII fields of the Mapping message, then PE2 sends a Label Release message to PE1 with a Status Code meaning "Attachment Circuit bound to different remote Attachment Circuit". The processing of the Mapping message is complete at that point ⭐

Now for the L2TP-based signaling, which is kind of the same energy 🌈 When a PE receives an ICRQ message and the TAI identifies a particular Attachment Circuit configured to be bound to a point-to-point PW, it runs the following checks 👑

If the Attachment Circuit is already bound to a pseudowire, and the remote endpoint is not PE1, then PE2 sends a Call Disconnect Notify (CDN) message to PE1 with a Status Code meaning "Attachment Circuit bound to different PE". The processing of the ICRQ message is complete 💖

If the Attachment Circuit is already bound to a pseudowire, but that pseudowire is bound to a Forwarder on PE1 whose AI is different than the one specified in the SAI fields of the ICRQ message, then PE2 sends a CDN message to PE1 with a Status Code meaning "Attachment Circuit bound to different remote Attachment Circuit". Then the processing of the ICRQ message is complete 🦋

These errors could happen as the result of misconfigurations 😬

3.2. Virtual Private LAN Service

In the VPLS application [RFC4762], the Attachment Circuits can be thought of as LAN interfaces that plug into "virtual LAN switches" 🌸 or, in the terminology of [RFC4664], "Virtual Switching Instances" (VSIs). Each Forwarder is a VSI that attaches to a bunch of PWs and a bunch of Attachment Circuits 🧚 The VPLS service requires that a single pseudowire be created between each pair of VSIs that are in the same VPLS. And each PE device can have multiple VSIs, where each VSI belongs to a different VPLS 💅

3.2.1. Provisioning

Every VPLS needs a globally unique identifier, which [RFC4762] calls the VPLS identifier (or VPLS-id) 🔑 Every VSI must be configured with the VPLS-id of the VPLS it belongs to 🫶

Each VSI also needs its own unique identifier, which we call a VSI-ID ✨ This can be formed automatically by concatenating its VPLS-id with an IP address of its PE router. (Note that the PE address is only being used as a form of unique identifier here. A service provider could pick some other numbering scheme if they want, as long as each VSI gets an identifier that is unique within the VPLS instance. See Section 4.4 for a discussion of identifier assignment when there are multiple providers 🍓)

3.2.2. Auto-Discovery

3.2.2.1. BGP-Based Auto-Discovery

This section specifies how BGP can be used to discover the information needed to build VPLS instances 🌈

When BGP-based auto-discovery is used for VPLS, the AFI/SAFI (Address Family Identifier / Subsequent Address Family Identifier) [RFC4760] will be:

  • An AFI (25) for L2VPN. (This is the same for all L2VPN schemes.)
  • A SAFI (65) specifically for an L2VPN service whose pseudowires are set up using the procedures described in the current document.

See Section 6 for further discussion of AFI/SAFI assignment 💜

To use BGP-based auto-discovery, there must be at least one globally unique identifier associated with a VPLS, and each such identifier must be encodable as an 8-byte Route Distinguisher (RD) 👑 Any method of assigning one or more unique identifiers to a VPLS and encoding each of them as an RD (using the encoding techniques of [RFC4364]) will do 🙌

Each VSI needs a unique identifier that is encodable as a BGP Network Layer Reachability Information (NLRI) 🦋 This is formed by prepending the RD (from the previous paragraph) to an IP address of the PE containing the VSI. The address here is simply a handy unique identifier for the VSIs within a VPN. It does not need to be globally routable, but it must be unique within the VPLS instance 💅 An alternate scheme for giving each VSI within a VPLS instance a unique identifier (for example, numbering the VSIs of a single VPN from 1 to n) could be used if you prefer it 🎀

When using the procedures in this document, it is necessary to assign a single, globally unique VPLS-id to each VPLS instance [RFC4762] 💖 This VPLS-id must be encodable as a BGP Extended Community [RFC4360]. As described in Section 6, this document defines two Extended Community subtypes for this purpose. The Extended Community MUST be transitive 🔥

The first Extended Community subtype is a Two-octet AS Specific Extended Community. The second is an IPv4 Address Specific Extended Community. The encodings of these Communities are defined in [RFC4360]. These encodings make sure a service provider can allocate a VPLS-id without risking a collision with another provider 🫶 However, coordination of VPLS-ids among providers is still necessary for inter-provider L2VPNs, as described in Section 4.4 ⭐

Each VSI also needs to be associated with one or more Route Target (RT) Extended Communities. These control the distribution of the NLRI, and so they control how the overlay topology of pseudowires that makes up a particular VPLS gets formed 🌸

Auto-discovery works like this: each PE distributes, via BGP, the NLRI for each of its VSIs, with itself as the BGP next hop, and with the appropriate RT for each such NLRI 🧚 Typically, each PE is a client of a small set of BGP route reflectors, which redistribute this information to the other clients 💜

If a PE receives a BGP update that is missing any of the elements specified above, the update should be ignored 🙈

If a PE has a VSI with a particular RT, it can import all the NLRIs that carry that same RT. From the BGP next hop attribute of those NLRIs, it learns the IP addresses of the other PE routers that have VSIs with the same RT 👀 The considerations in Section 4.3.3 of [RFC4364] on the use of route reflectors apply here too 💅

If a particular VPLS is meant to be a single fully connected LAN, all its VSIs will have the same RT. In that case the RT could be (though it doesn't have to be) an encoding of the VPN-id 🍓 A VSI can be placed in multiple VPLSes by giving it multiple RTs 🌈

Hierarchical VPLS can be set up by assigning multiple RTs to some of the VSIs, since the RT mechanism lets you have complete control over the pseudowire overlay that makes up the VPLS topology 👑

If Distributed VPLS (described in Section 3.5) is deployed, only the Network-facing PEs (N-PEs) take part in BGP-based auto-discovery. That means an N-PE needs to advertise reachability to each of the VSIs it supports, including the ones located in User-facing PEs (U-PEs) that connect to it. To create a unique identifier for each such VSI, an IP address of each U-PE combined with the RD for the VPLS instance could be used 🦋

In summary, the BGP advertisement for a particular VSI at a given PE contains:

  • an NLRI of AFI = L2VPN, SAFI = VPLS, encoded as RD:PE_addr
  • a BGP next hop equal to the loopback address of the PE
  • an Extended Community Attribute containing the VPLS-id
  • an Extended Community Attribute containing one or more RTs

See Section 6 for discussion of the AFI and SAFI values. The format for the NLRI encoding is:

     +------------------------------------+
     |  Length (2 octets)                 |
     +------------------------------------+
     |  Route Distinguisher (8 octets)    |
     +------------------------------------+
     |  PE_addr (4 octets)                |
     +------------------------------------+

Note that this advertisement is pretty similar to the NLRI format defined in [RFC4761]. The main difference is that [RFC4761] also includes a label block in the NLRI. Interoperability between the VPLS scheme defined here and the one defined in [RFC4761] is beyond the scope of this document 🥹

3.2.3. Signaling 🎀

okay so bestie, we need Attachment Identifiers that identify the VSIs 🦋. Back in the last section, a VSI-ID was encoded as RD:PE_addr, and the VPLS-id rode along in a BGP Extended Community 💅. For signaling, we flip that info around like this: the VPLS-id goes in the AGI field, and the PE_addr (or, more precisely, the VSI-ID that was in the BGP NLRI, minus the RD) goes in the TAII field 🧚. AGI plus TAII is enough to fully pin down the VSI the pseudowire should connect to, in both single AS and inter-AS setups ✨. The SAII MUST be set to the PE_addr of the sending PE (or, more precisely, the VSI-ID, without the RD, of the VSI tied to this VPLS on the sending PE) so the reverse half of the PW can get signaled if needed 💜. ngl this is giving very "label the envelope both ways" energy 💌.

The structure of the AGI and AII fields for the Generalized ID FEC in LDP is defined in [RFC4447] 🌸. The AGI field here is a Type of 1, a length field of value 8, and the 8 bytes of the VPLS-id 🍓. The AIIs are a Type of 1, a length field of value 4, followed by the 4-byte PE address (or other 4-byte identifier) 🫶. See Section 6 for the AGI and AII Type assignment, because that's where the details live 🔥.

The encoding of the AGI and AII in L2TP is specified in [RFC4667] 🌈.

Note that with this technique you cannot set up more than one PW per pair of VSIs 🙈. Literally one per pair, no more 💀.

3.2.4. Pseudowires as VPLS Attachment Circuits

It is also possible with this technique to set up a PW that attaches to a VSI at one endpoint, but only to an Attachment Circuit at the other endpoint 🦋. There may be more than one PW terminating on a given VSI, and those have to be told apart somehow, so each PW MUST have an SAII that is unique relative to the VSI-ID ✨. iykyk, the uniqueness is the whole point 👑.

3.3. Colored Pools: Full Mesh of Point-to-Point Pseudowires

The "Colored Pools" model is an automated way to deliver VPWS 🌸. Each PE can hold several pools of Attachment Circuits, and each pool is tied to a particular VPN 💖. A PE can have multiple pools per VPN, since each pool may correspond to a particular CE device 🧚. You might want one pseudowire between each pair of pools in the same VPN, which basically gives you a full mesh of CE-CE Virtual Circuits for each VPN 🕸️✨.

3.3.1. Provisioning

Each pool gets configured and associated with:

  • a set of Attachment Circuits;
  • a "color", which is basically a VPN-id of some sort;
  • a relative pool identifier, which is unique relative to the color.
[Note: depending on the technology used for Attachment Circuits (ACs), it may or may not be necessary to provision these circuits as well. For example, if the ACs are frame relay circuits, there may be some separate provisioning system to set up such circuits. Alternatively, "provisioning" an AC may be as simple as allocating an unused VLAN ID on an interface and communicating the choice to the customer. These issues are independent of the procedures described in this document.]

The pool identifier and color together make a globally unique identifier for the pool 💅. So if there are n pools of a given color, their pool identifiers can be (though they don't have to be) the numbers 1-n 🔢.

The semantics: a pseudowire gets created between every pair of pools with the same color, and each of those pseudowires is bound to one Attachment Circuit from each of the two pools 🫶.

If each pool is a set of Attachment Circuits leading to a single CE device, then the Layer 2 connectivity among the CEs is controlled by how the colors get assigned to the pools 🎀. To make a full mesh, the "color" would just be a VPN-id 💜.

Optionally, a particular Attachment Circuit may be configured with the relative pool identifier of a remote pool 🦋. Then that Attachment Circuit gets bound to a particular pseudowire only if that pseudowire's remote endpoint is the pool with that relative pool identifier 🔥. With this option, the same pairs of Attachment Circuits will always be bound via pseudowires 👑.

3.3.2. Auto-Discovery

3.3.2.1. BGP-Based Auto-Discovery

This section specifies how BGP can be used to discover the info needed to build VPWS instances 🌈.

When BGP-based auto-discovery is used for VPWS, the AFI/SAFI will be:

  • An AFI specified by IANA for L2VPN. (This is the same for all L2VPN schemes.)
  • A SAFI specified by IANA specifically for an L2VPN service whose pseudowires are set up using the procedures described in the current document.

See Section 6 for further discussion of AFI/SAFI assignment 💖.

To use BGP-based auto-discovery, there MUST be one or more unique identifiers associated with a particular VPWS instance 🧚. Each identifier MUST be encodable as an RD (Route Distinguisher) 💅. The globally unique identifier of a pool MUST be encodable as NLRI; the pool identifier, which we define to be a 4-byte quantity, gets appended to the RD to create the NLRI ✨.

When using the procedures in this document, it is necessary to assign a single, globally unique identifier to each VPWS instance 🫶.

This identifier MUST be encodable as a BGP Extended Community [RFC4360] 🎀. As described in Section 6, this document defines two Extended Community subtypes for this purpose 🦋. The Extended Community MUST be transitive 💜.

The first Extended Community subtype is a Two-octet AS Specific Extended Community. The second is an IPv4 Address Specific Extended Community. The encodings of these Communities are defined in [RFC4360] 🌸. These encodings ensure a service provider can allocate a VPWS identifier without risk of collision with another provider 👑. However, co-ordination of VPWS identifiers among providers IS necessary for inter-provider L2VPNs, as described in Section 4.4 🔥.

Each pool MUST also be associated with an RT (route target), which may also be an encoding of the color 💅. If the desired topology is a full mesh of pseudowires, all pools may have the same RT. See Section 3.4 for other topologies 🧚.

Auto-discovery works like this: each PE distributes, via BGP, the NLRI for each of its pools, with itself as the BGP next hop, and with the RT that encodes the pool's color 🦋. If a given PE has a pool with a particular color (RT), it MUST receive, via BGP, all NLRI with that same color (RT) 🫶. Typically, each PE would be a client of a small set of BGP route reflectors, which redistribute this info to the other clients 🌈.

If a PE receives a BGP update that is missing any of the elements specified above, the update SHOULD be ignored 🙈.

If a PE has a pool with a particular color, it can receive all the NLRI with that same color. From the BGP next hop attribute of these NLRI, it learns the IP addresses of the other PE routers that have pools with the same color ✨. It also learns the unique identifier of each such remote pool, since that's encoded in the NLRI 💖. The remote pool's relative identifier can be pulled out of the NLRI and used in the signaling, as specified below 🎀.

In summary, the BGP advertisement for a particular pool of attachment circuits at a given PE contains:

  • an NLRI of AFI = L2VPN, SAFI = VPLS, encoded as RD:pool_num;
  • a BGP next hop equal to the loopback address of the PE;
  • an Extended Community Attribute containing the VPWS identifier;
  • an Extended Community Attribute containing one or more RTs.

See Section 6 for discussion of the AFI and SAFI values 💜.

3.3.3. Signaling

LDP-based signaling follows the procedures in [RFC4447] 🔥. One PE (PE1) sends a Label Mapping message to another PE (PE2) to set up an LSP in one direction 🌸. The address of PE2 is the next-hop address learned via BGP, as described above 💅. If that message is processed successfully and there is not yet an LSP for the pseudowire in the opposite (PE1->PE2) direction, then PE2 sends a Label Mapping message back to PE1 👑. L2TPv3-based signaling similarly follows the procedures of [RFC4667] 🦋. More details on using these signaling protocols follow ✨.

When a PE sends a Label Mapping message or an ICRQ message to set up a PW between two pools, it encodes the VPWS identifier (as distributed in the Extended Community Attribute by BGP) as the AGI, the local pool's relative identifier as the SAII, and the remote pool's relative identifier as the TAII 🧚.

The structure of the AGI and AII fields for the Generalized ID FEC in LDP is defined in [RFC4447] 🌈. The AGI field here is a Type of 1, a length field of value 8, and the 8 bytes of the VPWS identifier 🍓. The TAII is a Type of 1, a length field of value 4, followed by the 4-byte remote pool number 🫶. The SAII is a Type of 1, a length field of value 4, followed by the 4-byte local pool number 💜. See Section 6 for the AGI and AII Type assignment 🔥. Note that the VPLS and VPWS procedures in this document can share the same AGI Type (1) and the same AII Type (1) 🎀.

The encoding of the AGI and AII in L2TP is specified in [RFC4667] 🌸.

When PE2 receives a Label Mapping message or an ICRQ message from PE1, and the TAI identifies a pool, and there is already a pseudowire connecting an Attachment Circuit in that pool to an Attachment Circuit at PE1, and the AI at PE1 of that pseudowire is the same as the SAI of the Label Mapping or ICRQ message, then PE2 MUST send a Label Release or CDN message to PE1, with a Status Code meaning "Attachment Circuit already bound to remote Attachment Circuit" 🙅. This prevents creating multiple pseudowires between a given pair of pools 💀.

Note that the signaling itself only identifies the remote pool the pseudowire is supposed to lead to, not the remote Attachment Circuit that's supposed to be bound to it 🦋. However, the remote PE MAY examine the SAII field to figure out which Attachment Circuit should be bound to the pseudowire 👑.

3.4. Colored Pools: Partial Mesh

Setting up a partial mesh of pseudowires among a set of colored pools is basically the same as a full mesh, with these exceptions 🌈:

  • Each pool is optionally configured with a set of "import RTs" and "export RTs";
  • During BGP-based auto-discovery, the pool color is still encoded in the RD, but if the pool is configured with a set of "export RTs", those get encoded in the RTs of the BGP Update messages INSTEAD of the color 💅;
  • If a pool has a particular "import RT" value X, it will create a PW to every other pool that has X as one of its "export RTs" 🫶. The signaling messages and procedures themselves are as in Section 3.3.3 ✨.

As a simple example, picture a hub-and-spoke topology with a single hub 🍓. One pool, the "hub" pool, is configured with an export RT of RT_hub and an import RT of RT_spoke. All other pools (the spokes) are configured with an export RT of RT_spoke and an import RT of RT_hub 🎀. So the hub pool connects to the spokes and vice-versa, but the spoke pools will NOT connect to each other 💖.

3.5. Distributed VPLS ✨

okay so Distributed VPLS ([RFC4664]) is giving "split the job between two friends" 🫶. The VPLS stuff a PE router does gets divided between two systems, a U-PE and an N-PE. The U-PE sits between the user and the N-PE, and it's the one doing the VSI work (MAC address learning and bridging) 🧚. Lots of U-PEs can attach to a single N-PE. For each VPLS a U-PE supports, it keeps a pseudowire to every other U-PE in that same VPLS 💖.

Here's the lowkey genius part: the U-PEs don't talk to each other over signaling control connections. Each U-PE has just one signaling connection, and that's to its N-PE 🎀. So every U-PE-to-U-PE pseudowire is really three pseudowires glued together: U-PE to N-PE, N-PE to N-PE, and N-PE back to U-PE. In the terms of [RFC5659], the N-PEs do the pseudowire switching function to build multi-segment PWs from U-PE to U-PE 🦋.

Let's look at an example topology, because pictures make everything make sense 🌸:

        U-PE A-----|             |----U-PE C
                   |             |
                   |             |
                 N-PE E--------N-PE F
                   |             |
                   |             |
        U-PE B-----|             |-----U-PE D

All four U-PEs are in a common VPLS. Now let's see how the PWs get spliced in this setup so U-PE A can reach everyone else 👑.

There are three PWs from A to E: A-E/1, A-E/2, and A-E/3. To properly connect A to the other U-PEs, we also need two PWs from E to F (E-F/1 and E-F/2), one PW from E to B (E-B/1), one from F to C (F-C/1), and one from F to D (F-D/1) 🍓.

Then the N-PEs splice these pseudowires together to get what the non-distributed VPLS signaling mechanism would've given us ✨:

  • PW from A to B: A-E/1 gets spliced to E-B/1.
  • PW from A to C: A-E/2 gets spliced to E-F/1 gets spliced to F-C/1.
  • PW from A to D: A-E/3 gets spliced to E-F/2 gets spliced to F-D/1.

Which PWs get spliced together doesn't matter, as long as the end result is one PW from A to each of B, C, and D 💅.

There are more PWs that need splicing too, to link U-PE B with U-PEs C and D, and to link U-PE C with U-PE D 🫧.

This figure shows the PWs from A to C and from B to D. The other four PWs aren't drawn so the picture stays clean 🦋:

                   splicing points
                    |           |
                    V           V
   A-C PW    <-----><-----------><------>


        U-PE A-----|             |----U-PE C
                   |             |
                   |             |
                 N-PE E--------N-PE F
                   |             |
                   |             |
        U-PE B-----|             |-----U-PE D


   B-D PW    <-----><-----------><------>
                    ^           ^
                    |           |
                   splicing points

Real talk: distributed VPLS doesn't reduce the number of pseudowires per U-PE. What it does reduce is the number of control connections per U-PE 🥹. Whether that's worth it depends entirely on what your bottleneck is 🤷‍♀️.

3.5.1. Signaling 🎀

The signaling for Distributed VPLS can use the mechanisms described in this document. But the VPLS procedures (Section 3.2.3) need some extra machinery so that the right number of PWs gets set up between the various N-PEs and U-PEs, and among the N-PEs too 💜.

At a given N-PE, the U-PEs directly attached to it in a given VPLS can be numbered from 1 to n. That number identifies the U-PE relative to a particular VPN-id and a particular N-PE. (So to uniquely identify a U-PE, you need to know the N-PE, the VPN-id, and the U-PE number, all together 🙈.)

Through configuration or discovery, each U-PE is given a list of <j, IP address> pairs. Each element tells the U-PE to set up j PWs to that IP address. When the U-PE signals to the N-PE, it sets the AGI to the proper-VPN-id, sets the SAII to the PW number, and sets the TAII to null 🦋.

In the example above, U-PE A gets told <3, E>, which means it should set up 3 PWs to E. When it signals, A sets the AGI to the proper VPN-id and sets the SAII to 1, 2, or 3, depending on which of the three PWs it's signaling 🌈.

Also through configuration or discovery, each N-PE needs the following info for each VPLS ✨:

  • A "Local" list: {<j, IP address>}. Each element tells the N-PE to set up j PWs to the locally attached U-PE at that address. The number of elements in this list will be n, the number of locally attached U-PEs in this VPLS. In the example, E gets the local list {<3, A>, <3, B>}, which means 3 PWs to A and 3 PWs to B 🍓.
  • A local numbering of its U-PEs, relative to the particular VPLS and the particular N-PE. In the example, E could be told that U-PE A is 1 and U-PE B is 2 🎀.
  • A "Remote" list: {<IP address, k>}. This tells the N-PE to set up k PWs, for each U-PE, to the specified IP address. Each of these IP addresses identifies an N-PE, and k is the number of U-PEs at that N-PE that are in the VPLS. In the example, E gets the remote list {<2, F>}. Since E has 2 U-PEs, that means 4 PWs to N-PE F, 2 for each of E's U-PEs 💅.

Signaling a PW from an N-PE to a U-PE is based on the local list and the local numbering of U-PEs. When an N-PE signals a particular PW to a U-PE, the AGI is set to the proper VPN-id, the SAII is set to null, and the TAII is set to the PW number (relative to that VPLS and that U-PE). In the example, when E signals to A, it sets the TAII to 1, 2, or 3 for the 3 PWs it needs to set up to A. It signals 3 PWs to B in the same way 🧚.

The LSP signaled from the U-PE to the N-PE is associated with an LSP from the N-PE to the U-PE in the usual manner. A PW between a U-PE and an N-PE is called a "U-PW" 🦋.

Signaling the right set of PWs from N-PE to N-PE is based on the remote list. The PWs between N-PEs can all be considered equivalent. As long as the correct total number of PWs is set up, the N-PEs can splice these PWs to the appropriate U-PWs ✨. The remote list tells you how many PWs to set up, per local U-PE, to a particular remote N-PE 💖.

When an N-PE signals a particular PW to another N-PE, the AGI is set to the appropriate VPN-id. The TAII identifies the remote N-PE, same as in the non-distributed case. That means it contains an IP address of the remote N-PE. If there are n such PWs, they're told apart by the setting of the SAII. To allow multiple different SAII values in a single VPLS, the sending N-PE needs as many VSI-IDs as it has U-PEs. As noted above in Section 3.2.2, this can be done by using an IP address of each attached U-PE, for example 🌸. A PW between two N-PEs is called an "N-PW" 🫶.

Each U-PW has to be "spliced" to an N-PW, and this is based on the remote list. If the remote list contains an element <i, F>, then i U-PWs from each local U-PE must be spliced to i N-PWs from the remote N-PE F. It doesn't matter which U-PWs get spliced to which N-PWs, as long as that constraint is met 💅.

If an N-PE has more than one local U-PE for a given VPLS, it must also make sure that a U-PW from each of those U-PEs is spliced to a U-PW from each of the other U-PEs 👑.

3.5.2. Provisioning and Discovery 🍓

Every N-PE must be provisioned with the set of VPLS instances it supports, a VPN-id for each one, and a list of local U-PEs for each of those VPLSs. As part of the discovery procedure, the N-PE advertises the number of U-PEs for each VPLS. See Section 3.2.2 for details 🧚.

Auto-discovery (for example, BGP-based) can be used to find all the other N-PEs in the VPLS and, for each one, the number of U-PEs local to that N-PE. From that info you can work out the total number of U-PEs in the VPLS. That's enough to compute the local list and the remote list for each N-PE 🎀.

3.5.3. Non-Distributed VPLS as a Sub-Case 🦋

A PE providing "non-distributed VPLS" (meaning a PE that does both the U-PE and N-PE functions) can interoperate with N-PE/U-PE pairs that are providing distributed VPLS 💜. The "non-distributed PE" just advertises, during discovery, that it has one local U-PE per VPLS. And of course, the non-distributed PE doesn't do any PW switching 🌈.

If every PE in a VPLS is providing non-distributed VPLS, and so every PE advertises itself as an N-PE with one local U-PE, the resulting signaling is exactly the same as what's specified in Section 3.2.3 above ✨.

3.5.4. Splicing and the Data Plane 💅

Splicing two PWs together is pretty straightforward in the MPLS data plane. Moving a packet from one PW straight to another is just a 'label replace' operation on the PW label 🫧. When a PW is made up of two or more PWs spliced together, the data is assumed to go to the node where the splicing happens. In other words, the data path passes through the nodes that take part in PW signaling 🔥.

More details on splicing are covered in [RFC6073] 📚.

4. Inter-AS Operation ✨

The provisioning, auto-discovery, and signaling mechanisms described above can all be applied in an inter-AS environment 🌍. As in [RFC4364], there are a number of options for inter-AS operation 🫶.

4.1. Multihop EBGP Redistribution of L2VPN NLRIs 💖

okay so this option is giving option (c) in [RFC4364] 🎀 we use multihop External BGP (EBGP) to redistribute L2VPN NLRIs between the source and destination ASes, and then regular EBGP redistributes labeled IPv4 or IPv6 routes from each AS to its neighbor AS ✨

an Autonomous System Border Router (ASBR) has to keep labeled IPv4 /32 (or IPv6 /128) routes to the PE routers inside its own AS 🧚 it uses EBGP to pass those routes on to other ASes and sets itself as the BGP next hop for them. ASBRs in any transit ASes have to use EBGP to pass along the labeled /32 (or /128) routes too 🫶 the end result is a set of label switched paths from every ingress PE to every egress PE. so now PE routers in different ASes can set up multihop EBGP sessions with each other and swap L2VPN NLRIs over them 💅 after that, a pair of PEs in different ASes can set up an LDP session to signal PWs between themselves 🦋

for VPLS, the BGP advertisement and PW signaling work exactly like they do in Section 3.2 🌸 because of the multihop EBGP session between the source and destination AS, PEs in one AS that have VSIs for a certain VPLS can find the PEs in the other AS that have VSIs for that same VPLS 😭 those PEs can then open the right PW signaling protocol session and build the full mesh of VSI-VSI pseudowires that makes up the VPLS, just like Section 3.2.3 describes 👑

for VPWS, the BGP advertisement and PW signaling work exactly like they do in Section 3.3 💜 same deal with the multihop EBGP session: PEs in one AS that have pools of a certain color (VPN) can discover PEs in another AS with pools of the same color 🌈 they can then set up the right PW signaling protocol session and build the full mesh of pseudowires from Section 3.2.3. a partial mesh can be built the same way using the procedures in Section 3.4 🍓

just like with Layer 3 VPNs, building an L2VPN that spans more than one provider's network takes some co-ordination around RTs and RDs 🔥 we go deeper on that in Section 4.4 ✨

4.2. EBGP Redistribution of L2VPN NLRIs with Multi-Segment Pseudowires 🦋

okay, real talk: the approach in the last section has a bit of a drawback 🙈 it creates PW signaling sessions between all the PEs of a given L2VPN (VPLS or VPWS). that means a potentially huge number of LDP or L2TPv3 sessions crossing the AS boundary, and those sessions hitting lots of devices inside an AS 💀 if the ASes belong to different providers, the providers would probably love fewer signaling sessions crossing the boundary, and they'd want the endpoints restricted to a smaller set of devices 🫶 plus, if you force the LDP or L2TPv3 signaling sessions to end on a small set of ASBRs, a provider can use standard authentication procedures on just that small set of inter-provider sessions 🔐 that's the whole motivation for this approach ✨

[RFC6073] describes a way of "switching" packets from one pseudowire to another at a particular node 🧚 this lets you build an end-to-end, multi-segment pseudowire out of several PW segments, without keeping up an end-to-end control connection 🎀 we can use that to make an inter-AS solution that looks a lot more like option (b) in [RFC4364] 👑

in this model, we use EBGP to redistribute L2VPN NLRI from AS to neighboring AS 💖 first, the PE routers use Internal BGP (IBGP) to redistribute L2VPN NLRI either to an ASBR, or to a route reflector that has an ASBR as a client 🌸 the ASBR then uses EBGP to pass those L2VPN NLRIs to an ASBR in another AS. that ASBR distributes them to the PE routers in its AS, or to yet another ASBR that does the same, and so on 🍓

so in this case, a PE can learn the address of an ASBR it could use to reach another PE it wants a PW with ✨ specifically, a local PE gets a BGP advertisement containing L2VPN NLRI for an L2VPN instance where the local PE has some attached members 💅 the BGP next hop for that NLRI is an ASBR in the local AS. instead of building a control connection all the way to the remote PE, the local PE only builds one to that ASBR 🦋 a pseudowire segment can then be set up from the PE to the ASBR 🫶 the ASBR can in turn set up a PW to the ASBR of the next AS, and splice that PW to the PW from the PE, as described in Section 3.5.4 and [RFC6073] 😭 repeat that at each ASBR and you get a sequence of PW segments that, when spliced together, connects the two PEs 🌈

heads up, though: with this approach, the local PE may never learn the IP address of the remote PE 🙈 it learns the L2VPN NLRI that the remote PE advertised, and that NLRI doesn't have to contain the remote PE's address. what it does learn is the IP address of the ASBR that's the BGP next hop for that NLRI 💜

when this approach is used for VPLS, or for full-mesh VPWS, you still end up with a full mesh of pseudowires among the PEs, just like in the last section 💖 the difference is that you don't need a full mesh of control connections (LDP or L2TPv3 sessions) 🎀 instead, the control connections inside a single AS run among all the PEs of that AS and the ASBRs of that AS 👑 and a single control connection between the ASBRs of adjacent ASes can support however many AS-to-AS pseudowire segments are needed ✨

the procedures here mean the splicing points (PW Switching PEs (S-PEs) in the terminology of [RFC5659]) end up co-located with the ASBRs 🧚 of course, it's possible to have multiple ASBR-ASBR connections between a given pair of ASes. in that case, a given PE could pick among the available ASBRs based on a range of criteria, such as IGP metric, local configuration, etc., which is kind of like choosing an exit point in normal IP routing 🔥 using multiple ASBRs gives you greater resiliency (on the timescale of BGP routing convergence), because a PE can select a new ASBR if the one it's using fails 🫶

just like in layer 3 VPNs, building an L2VPN that spans more than one provider's network requires some co-ordination in the use of RTs and RDs 💅 that's covered in more detail in Section 4.4 🦋

4.3. Inter-Provider Application of Distributed VPLS Signaling 🌸

there's another way to do inter-provider VPLS, and it comes from the Distributed VPLS approach we covered above 🍓 check out this topology:

PE A --- Network 1 ----- Border ----- Border ----- Network 2 --- PE B
                         Router 12    Router 21       |
                                                      |
                                                     PE C

A, B, and C are PEs in a common VPLS, but Networks 1 and 2 belong to different service providers 🌈 Border Router 12 is Network 1's border router to Network 2, and Border Router 21 is Network 2's border router to Network 1 ✨ we're also assuming the PEs are not "distributed", i.e., each one provides both the U-PE and N-PE functions 💜

in this topology, you need two inter-provider pseudowires: A-B and A-C 🔥

now, suppose a service provider decides, for whatever reason, that it doesn't want each of its PEs to have a control connection to any PEs in the other network 🙈 it'd rather have the inter-provider control connections run only between the two border routers 🫶

this can be done with the techniques in Section 3.5, where the PEs behave like U-PEs and the BRs behave like N-PEs 👑 in the example topology, PE A would behave like a U-PE locally attached to BR12. PEs B and C would behave like U-PEs locally attached to BR21, and the two BRs would behave like N-PEs 💖

as a result, the PW from A to B would consist of three segments: A-BR12, BR12-BR21, and BR21-B 😭 the border routers would have to splice the corresponding segments together 🦋

this requires the PEs within a VPLS to be numbered from 1-n (relative to that VPLS) within a given network 🎀

4.4. RT and RD Assignment Considerations 👑

okay so for any of the inter-AS procedures above to work correctly, the two ASes have to use RTs and RDs consistently, just like in Layer 3 VPNs [RFC4364] ✨ the structure of RTs and RDs means there isn't a big risk of accidental collisions 🌸 the real challenge is that the operator of one AS needs to know which RT or RTs were chosen in another AS for any VPN that has sites in both ASes 😭 just like Layer 3 VPNs, there are lots of ways to make this work, but they all need some co-operation among the providers 🫶

for example, provider A might tag all the NLRI for a given VPN with a single RT, say RT_A, and provider B can then configure the PEs that connect to that VPN's sites to import NLRI carrying that RT 💅 provider B can pick a different RT, RT_B, tag all NLRI for this VPN with that one, and then provider A can import NLRI with that RT at the right PEs 🦋 but this does mean both providers have to tell each other which RTs they chose for each VPN 🙈 alternatively, both providers could agree to use a common RT for a given VPN 💜 either way, communicating RTs between the providers is essential 🔥 and just like in Layer 3 VPNs, providers may configure RT filtering so that only coordinated RT values get through the AS boundary 🍓

one more thing: a single VPN identifier (carried in a BGP Extended Community) is required for each VPLS or VPWS instance 🧚 the encoding rules for these identifiers in [RFC4360] make sure collisions don't happen with other providers 🎀 but for a single VPLS or VPWS instance that spans the networks of two or more providers, one provider has to allocate the identifier and tell the other provider(s) what it picked, and they must use the same value for sites in that same VPLS or VPWS instance 🌈

5. Security Considerations 🔐

this doc describes a bunch of different L2VPN provisioning models, and it specifies the endpoint identifiers that each provisioning model needs 💖 it also specifies how those endpoint identifiers get mapped into fields of auto-discovery protocols and signaling protocols 🫶

the security considerations for the signaling protocols are covered in their own protocol specs ([RFC5036], [RFC4447], [RFC3931], and [RFC4667]) 🔥

the security considerations for BGP-based auto-discovery, including inter-AS issues, are covered in [RFC4364] 🌸 L2VPNs that use BGP-based auto-discovery might also automate the setup of security mechanisms 👑 but specifying those automated security mechanisms is outside the scope of this document, although it's recommended as a future work item 😭

the security considerations for the particular kind of L2VPN service being supported are covered in [RFC4664], [RFC4665], and [RFC4762] 🦋

finally, the way endpoint identifiers get mapped into protocol fields does not create any additional security issues 💅

6. IANA Considerations ✨

okay so IANA already gave us an AFI and a SAFI for L2VPN NLRI 💖 and they're the exact same numbers that [RFC4761] got. so the AFI is 25 (L2VPN) and the SAFI is 65 (already allocated for VPLS) 🎀. both VPLS and VPWS auto-discovery use this same AFI and SAFI, as described in this doc 🦋.

[RFC4446] defines the registries for "Attachment Group Identifier (AGI) Type" and "Attachment Individual Identifier (AII) Type" 🌸. Type 1 in each registry is now claimed by the AGI and AII formats from this doc 👑.

IANA also gave us two new LDP status codes ✨. they live in the "STATUS CODE NAME SPACE" registry that [RFC5036] set up, and the values are:

  • 0x00000030 Attachment Circuit bound to different PE
  • 0x0000002D Attachment Circuit bound to different remote Attachment Circuit

two new L2TP Result Codes were registered for the CDN message too 🔥. the registry is the L2TP Result Code Values one for the CDN message, from [RFC3438], and the new values are:

  • 27: Attachment Circuit bound to different PE
  • 28: Attachment Circuit bound to different remote Attachment Circuit

[RFC4360] defines a registry called "Two-octet AS Specific Extended Community" 🧚. IANA gave us a value from the "transitive" range (0x0000-0x00FF), and it's:

  • o 0x000A Two-octet AS specific Layer 2 VPN Identifier

last one from [RFC4360]: the "IPv4 Address Specific Extended Community" registry 🌈. this time the value comes from the "transitive" range (0x0100-0x01FF), and it's:

  • o 0x010A Layer 2 VPN Identifier

7. BGP-AD and VPLS-BGP Interoperability

okay this part is so important bestie 🙈. BGP-AD and VPLS-BGP [RFC4761] use the same AFI/SAFI, so they need a way to tell each other apart 😭. for both of them to co-exist, the NLRI length must be used as a demultiplexer 💅.

the BGP-AD NLRI has an NLRI length of 12 bytes, and it only holds an 8-byte RD and a 4-byte VSI-ID 🍓. VPLS-BGP [RFC4761] uses a 17-byte NLRI length 💜. so, implementations of BGP-AD must ignore NLRI that are greater than 12 bytes 🫶. that's the whole trick, periodt ✨.

8. Acknowledgments

big thank yous to Dan Tappan, Ted Qian, Ali Sajassi, Skip Booth, Luca Martini, Dave McDysan, Francois Le Faucheur, Russ Gardo, Keyur Patel, Sam Henderson, and Matthew Bocci for their comments, criticisms, and helpful suggestions 🫶💖.

also thanks to Tissa Senevirathne, Hamid Ould-Brahim, and Yakov Rekhter for talking through the auto-discovery issues 🧚.

and thanks to Vach Kompella for a continuing discussion of the proper semantics of the generalized identifiers 🌸.

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.
  • [RFC3438] Townsley, W., "Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update", BCP 68, RFC 3438, December 2002.
  • [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
  • [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006.
  • [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.
  • [RFC4667] Luo, W., "Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP)", RFC 4667, September 2006.
  • [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
  • [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007.
  • [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011.

9.2. Informative References

  • [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
  • [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, March 2005.
  • [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
  • [RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006.
  • [RFC4665] Augustyn, W. and Y. Serbest, "Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks", RFC 4665, September 2006.
  • [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, January 2007.
  • [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, January 2007.
  • [RFC5003] Metz, C., Martini, L., Balus, F., and J. Sugimoto, "Attachment Individual Identifier (AII) Types for Aggregation", RFC 5003, September 2007.
  • [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, October 2009.

Authors' Addresses 🎀

Eric Rosen
Cisco Systems, Inc.
1414 Mass. Ave.
Boxborough, MA  01719
USA

EMail: erosen@cisco.com


Bruce Davie
Cisco Systems, Inc.
1414 Mass. Ave.
Boxborough, MA  01719
USA

EMail: bsd@cisco.com


Vasile Radoaca
Alcatel-Lucent
Think Park Tower 6F
2-1-1 Osaki, Tokyo, 141-6006
Japan

EMail: vasile.radoaca@alcatel-lucent.com


Wei Luo

EMail: luo@weiluo.net
📦 where this page comes from