RFC 6624
Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling
RFC 6624: Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling 🦋
Okay bestie, this is an Informational RFC, so it's published for information and isn't a Standards Track spec 🎀. It came out in May 2012 (ISSN 2070-1721) and was written by K. Kompella (Juniper Networks), B. Kothari (Cisco Systems), and R. Cherukuri (Juniper Networks) 👑. The title block has no Obsoletes or Updates lines, so it doesn't replace or change any other RFC. ✨
Abstract 💌
Layer 2 VPNs (L2VPNs) built on Frame Relay or ATM circuits have been around forever 🕰️. More recently, Ethernet VPNs have blown up, including Virtual Private LAN Service (VPLS). The traditional setups were a lot, though: they often needed a separate Service Provider infrastructure for each type, plus another one for the Internet and IP VPNs 💀. Provisioning an L2VPN was also a huge hassle 🙄.
This document offers a new way to do L2VPN services. The customer's experience is basically the same as with traditional L2VPNs, but the Service Provider can run one network for L2VPNs, IP VPNs, and the Internet, with one common provisioning method for all of them 💅.
Status of This Memo 📋
This document is not an Internet Standards Track specification. It's published for informational purposes 🌸.
It's a product of the Internet Engineering Task Force (IETF) and reflects the consensus of the IETF community. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for that 🧐.
For info on the current status of this document, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6624 🔗.
Copyright Notice ⚖️
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document 📖. Code Components pulled out of this document must include the Simplified BSD License text, 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 ....................................................3
1.1. Terminology ................................................6
1.1.1. Conventions Used in This Document ...................6
1.2. Advantages of Layer 2 VPNs .................................6
1.2.1. Separation of Administrative Responsibilities .......7
1.2.2. Migrating from Traditional Layer 2 VPNs .............7
1.2.3. Privacy of Routing ..................................7
1.2.4. Layer 3 Independence ................................7
1.2.5. PE Scaling ..........................................8
1.2.6. Ease of Configuration ...............................8
1.3. Advantages of Layer 3 VPNs .................................9
1.3.1. Layer 2 Independence ................................9
1.3.2. SP Routing as Added Value ..........................10
1.3.3. Class of Service ...................................10
1.4. Multicast Routing .........................................10
2. Operation of a Layer 2 VPN .....................................11
2.1. Network Topology ..........................................11
2.2. Configuration .............................................13
2.2.1. CE Configuration ...................................14
2.2.2. PE Configuration ...................................15
2.2.3. Adding a New Site ..................................15
2.2.4. Deleting a Site ....................................16
2.2.5. Managing CE ID Mappings ............................16
2.2.6. Managing Label Blocks ..............................16
2.3. Operations, Administration, and Maintenance (OAM) .........17
3. PE Information Exchange ........................................17
3.1. Circuit Status Vector .....................................19
3.2. Generalizing the VPN Topology .............................20
4. Layer 2 Interworking ...........................................21
5. Packet Transport ...............................................22
5.1. Layer 2 MTU ...............................................22
5.2. Layer 2 Frame Format ......................................22
5.3. IP-Only Layer 2 Interworking ..............................23
6. Security Considerations ........................................23
7. IANA Considerations ............................................23
8. Acknowledgments ................................................24
9. Contributors ...................................................24
10. References ....................................................24
10.1. Normative References .....................................24
10.2. Informative References ...................................251. Introduction ✨
The earliest Virtual Private Networks (VPNs) were built on Layer 2 circuits: X.25, Frame Relay, and ATM (see [Kosiur]) 🧚. More recently, multipoint VPNs built on Ethernet Virtual Local Area Networks (VLANs) and Virtual Private LAN Service (VPLS) [RFC4761][RFC4762] have gotten super popular 🔥. The VPNs in this document are different: they're point-to-point, and they're usually called Virtual Private Wire Service (VPWS) 🎀. They all fall under Layer 2 VPNs (L2VPNs), because the hand-off between the customer and the Service Provider happens at Layer 2 💜.
Two things made L2VPNs expensive to offer. The first is that the easiest way to offer an L2VPN of a given Layer 2 type was to run it over an infrastructure of that same type 😩. That meant the Service Provider had to build a separate infrastructure for each Layer 2 encapsulation, like an ATM infrastructure for ATM VPNs and an Ethernet infrastructure for Ethernet VPNs, and so on. On top of that, the Internet and IP VPNs [RFC4364] needed their own separate infrastructure, and voice services might need yet another one. Basically, networks were multiplying everywhere 🙈.
The second is that each of those networks had its own provisioning methodology. Provisioning an L2VPN was also pretty complicated 😭. It's important to tell apart a single Layer 2 circuit, which connects two customer sites, from a Layer 2 VPN, which is a set of circuits connecting sites that belong to the same customer. The fact that two circuits belonged to the same VPN was usually known only to the provisioning system, not to the switches providing the service. That made setting up and then troubleshooting an L2VPN way harder 🥴. Also, every switch offering the service had to be provisioned with the address of every other switch in the same VPN. For a full-mesh VPN, that means provisioning grows with the square of the number of sites, which made full-mesh L2VPN connectivity prohibitively expensive for the Service Provider (SP), and therefore for customers too 💸. Finally, even setting up one individual circuit often meant provisioning every switch along the path 😵💫.
There has been a lot of progress on network "convergence" lately 🌈. The idea is that Layer 2 traffic, Internet traffic, and IP VPN traffic can all run over one consolidated network infrastructure based on IP/MPLS tunnels. This works thanks to techniques like the ones described in [RFC4448], [RFC4618], [RFC4619], and [RFC4717] for Layer 2 traffic, and in [RFC4364] for IP VPN traffic. This development goes a long way toward fixing the network proliferation problem 🙌. This document goes one step further and shows how a Service Provider can offer Layer 2 VPNs using protocol and provisioning methods similar to those used for VPLS [RFC4761] and IP VPNs [RFC4364], which gives a significant degree of operational convergence too 🍓. All of these methods include a VPN identifier, which ties together the components of a given VPN, and auto-discovery, which simplifies provisioning of dense VPN topologies (a full mesh, for example) 💖. Similar techniques are also used across all of the above-mentioned VPN technologies to offer inter-AS and inter-provider VPNs, meaning VPNs whose sites connect to multiple Autonomous Systems (ASes) or Service Providers 🌸.
Technically, the approach here uses the concepts and solution from [RFC4761], which describes a method for VPLS, a specific form of Layer 2 VPN 🦋. That document borrowed a lot from [RFC4364], including using BGP for auto-discovery and "demultiplexor" exchange (more on that below), and the concepts of Route Distinguishers, which make VPN advertisements unique, and Route Targets, which control VPN topology 👑. All three documents also share the idea that routers not directly connected to VPN customers should carry no VPN state. That means individual connections only get provisioned on the edge devices 🫶. This works by using tunnels to carry the data, plus a demultiplexor that identifies individual VPN circuits. These tunnels could be based on MPLS, GRE, or any other tunnel technology that offers a demultiplexing field, and the signaling of those tunnels is outside the scope of this document 🤓. The specific approach here is to use an MPLS label as the demultiplexor 🏷️.
L2VPNs usually require that all sites in the VPN connect to the SP with the same Layer 2 encapsulation. To ease that restriction, this document proposes a limited form of Layer 2 interworking, which restricts the Layer 3 protocol to IP only (see Section 4) 🌷.
It may be worth comparing the approach in [RFC4447] and [RFC6074] with the one described here. Those are the IETF-approved technologies for the functions in this document, though they use two separate protocols 🧐. To comply with IETF standards, it is recommended that devices implementing the solution in this document also implement the approach in [RFC4447] and [RFC6074] 💅.
The rest of this section talks about the relative merits of Layer 2 and Layer 3 VPNs. Section 2 covers how a Layer 2 VPN operates. Section 3 covers PE information exchange. Section 4 covers IP-only Layer 2 interworking. Section 5 covers how the L2 packets are transported across the SP network. Stay tuned, because the next parts go deeper into all of this 🥰✨
1.1. Terminology ✨
okay so before we dive in, bestie, let's get the vocab straight 💅 the terms come from [RFC4761] and [RFC4364], and we're just briefly repeating them here 🎀 a "customer" is a customer of a Service Provider who wants to connect their various "sites" (each one an independent network) at Layer 2 through the SP's network, while keeping their communication and address space private 🔒 the device at a customer site that plugs into an SP router is called the CE (customer edge) device, and it can be a router or a switch 🦋 the SP router that a CE connects to is a PE (provider edge) 💖 and a router in the SP's network that doesn't connect directly to any CE is called P ("provider" device) 🧚 every pair of PEs is connected by a "tunnel", and inside a tunnel, VPN data is told apart by a "demultiplexor", which in this document is an MPLS label 🌈
each CE within a VPN gets a CE ID, a number that uniquely identifies a CE within an L2VPN 🍓 more precisely, the CE ID identifies a physical connection from the CE device to the PE, since a CE may be connected to multiple PEs (or multiply connected to a PE) 👑 in that case, the CE would have a CE ID for each connection ✨ a CE can also be part of many L2VPNs, so it would need one (or more) CE ID(s) for each L2VPN it's a member of 💜 the number space for CE IDs is scoped to a given VPN 🫶
for inter-provider L2VPNs, there needs to be some coordination of CE ID allocation 😭 one solution is to allocate ranges for each SP, and other solutions may be forthcoming 🔥
within each physical connection from a CE to a PE, there may be multiple virtual circuits 🌸 these are called Attachment Circuits (ACs), following [RFC3985] 💅 and the entity that connects two attachment circuits across the Service Provider network is called a pseudowire (PW) 🦋
1.1.1. Conventions Used in This Document 🎀
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] 🫶
1.2. Advantages of Layer 2 VPNs 💖
a Layer 2 VPN is one where a Service Provider gives the customer Layer 2 connectivity 🧚 the SP doesn't participate in the customer's Layer 3 network, especially the routing, and that gives several advantages to the SP as a whole and to PE routers in particular 👑
1.2.1. Separation of Administrative Responsibilities 💅
in a Layer 2 VPN, the SP is responsible for Layer 2 connectivity, and the customer is responsible for Layer 3 connectivity, which includes routing 🎀 if the customer says host x in site A can't reach host y in site B, the SP only needs to show that site A is connected to site B 🦋 how routes for host y reach host x is the customer's job 🙈
once a PE provides Layer 2 connectivity to its connected CE, its job is done ✨ a misbehaving CE can at worst flap its interface, and route flaps in the customer network have little effect on the SP network 🌈 but a misbehaving CE in a Layer 3 VPN can flap its routes, which can lead to instability of the PE router or even the entire SP network 😭 so when offering a Layer 3 VPN, an SP should proactively protect itself from Layer 3 instability in the CE network 🫶
1.2.2. Migrating from Traditional Layer 2 VPNs 🦋
"traditional" Layer 2 VPNs (aka real Frame Relay circuits connecting sites) look exactly the same as tunnel-based VPNs from the customer's point of view, so migrating from one to the other raises few issues 🌸 Layer 3 VPNs, on the other hand, need a considerable redesign of the customer's Layer 3 routing architecture 💀 and with Layer 3 VPNs, you have to be super careful that routes within the traditional VPN aren't preferred over the Layer 3 VPN routes (the so-called "backdoor routing" problem, whose solution requires protocol changes that are somewhat ad hoc) 🙈
1.2.3. Privacy of Routing 🔒
in an L2VPN, privacy of customer routing is a natural side effect of the SP not participating in routing 💜 SP routers don't need to do anything special to keep customer routes separate from other customers or from the Internet ✨ there's no need for per-VPN routing tables, and that extra complexity would be a lot for PE routers 🧚
1.2.4. Layer 3 Independence 🌈
since the SP just provides Layer 2 connectivity, the customer can run any Layer 3 protocols they choose 👑 if the SP were participating in customer routing, it would be vital that the customer and SP both use the same Layer 3 protocol(s) and routing protocols 💅
note that IP-only Layer 2 interworking doesn't have this benefit, since it restricts the Layer 3 to IP only 🥺
1.2.5. PE Scaling 🍓
in the Layer 2 VPN scheme described below, each PE sends a single small chunk of information about every CE it's connected to every other PE 🦋 so each PE only needs to keep a single chunk of information from each CE in each VPN, and a single "route" to every site in every VPN 🎀 that means both the Forwarding Information Base and the Routing Information Base scale well with the number of sites and number of VPNs 💖 the scaling properties are also independent of the customer, since the only quantity that matters is the total number of VPN sites 🫶
contrast that with Layer 3 VPNs, where each CE in a VPN may have an arbitrary number of routes that the SP needs to carry 😭 this causes two issues 💀 first, both the information stored at each PE and the number of routes installed by the PE for a CE in a VPN can be (in principle) unbounded, which means in practice that a PE has to restrict itself to installing routes for the VPNs it's currently a member of 🙈 second, a CE can send a huge number of routes to its PE, so the PE has to protect itself from that 🔥 which means the SP must enforce limits on the number of routes accepted from a CE, and that in turn requires the PE router to offer such control 💅
the scaling issues of Layer 3 VPNs come into sharp focus at a BGP route reflector (RR) 😱 an RR can't keep all the advertised routes in every VPN, since the number of routes would be way too large 💀 the following solutions/extensions are needed to address this:
- RRs could be partitioned so that each RR services a subset of VPNs, so no single RR has to carry all the routes 👑
- An RR could use a preconfigured list of Route Targets for its inbound route filtering 🧚 the RR may choose to perform Route Target Filtering, described in [RFC4684] 🌸
1.2.6. Ease of Configuration 🎀
configuring traditional Layer 2 VPNs with dense topologies was a burden mainly because of the O(n*n) nature of the task 😩 if there are n CEs in a Frame Relay VPN, say full-mesh connected, n*(n-1)/2 DLCI (Data Link Connection Identifier) Permanent Virtual Circuits (PVCs) must be provisioned across the SP network 💀 at each CE, (n-1) DLCIs must be configured to reach each of the other CEs 🙈 when a new CE is added, n new DLCI PVCs must be provisioned, and each existing CE must be updated with a new DLCI to reach the new CE 😭 finally, each PVC requires state in every transit switch 🔥
in our proposal, PVCs are tunneled across the SP network 🦋 the tunnels are provisioned independently of the L2VPNs, using signaling protocols (in the case of MPLS, LDP or RSVP - Traffic Engineering (RSVP-TE) can be used), or set up by configuration 🧚 the number of tunnels is independent of the number of L2VPNs, which cuts a big chunk of the provisioning burden 💖
we also assume that DLCIs at the CE edge are relatively cheap and that VPN labels in the SP network are cheap 🌈 this lets the SP "overprovision" VPNs, for example allocating 50 CEs to a VPN when only 20 are needed 💜 with this overprovisioning, adding a new CE to a VPN only requires configuring the new CE and its associated PE, and existing CEs and their PEs don't need reconfiguring 🫶 note that if DLCIs at the CE edge are expensive (e.g., if they're provisioned across a switched network), one could provision them as and when needed, at the expense of extra configuration 🙈 this need not still result in extra state in the SP network, i.e., an intelligent implementation can allow overprovisioning of the pool of VPN labels ✨
1.3. Advantages of Layer 3 VPNs 🌸
Layer 3 VPNs ([RFC4364] in particular) are a good solution when the customer traffic is wholly IP, customer routing is reasonably simple, and the customer sites connect to the SP with a variety of Layer 2 technologies 💅
1.3.1. Layer 2 Independence 🦋
one major restriction in a Layer 2 VPN is that the Layer 2 media that the various sites of a single VPN connect to the SP with must be uniform 😭 on the other hand, the various sites of a Layer 3 VPN can connect to the SP with any supported media, for example some sites might use Frame Relay circuits and others Ethernet 🎀
this restriction of Layer 2 VPN is eased by the IP-only Layer 2 interworking proposed in this document 💖 but it comes at the cost of losing Layer 3 independence 🙈
a corollary to this is that the number of sites that can be in a Layer 2 VPN is determined by the number of Layer 2 circuits the Layer 2 technology provides 🔥 for example, if the Layer 2 technology is Frame Relay with 2-octet DLCIs, a CE can at most connect to about a thousand other CEs in a VPN 🥹
1.3.2. SP Routing as Added Value 👑
another problem with Layer 2 VPNs is that the CE router in a VPN has to be able to deal with having N routing peers, where N is the number of sites in the VPN 😵 this can be eased by manipulating the topology of the VPN 💅 for example, a hub-and-spoke VPN architecture means only one CE router (the hub) needs to deal with N neighbors 🧚 however, in a Layer 3 VPN, a CE router only needs to deal with one neighbor, the PE router 💖 so the SP can offer Layer 3 VPNs as a value-added service to its customers 🌈
moreover, with Layer 2 VPNs, it's up to the customer to build and operate the whole network 😩 with Layer 3 VPNs, a customer is only responsible for building and operating routing within each site, which is likely to be much simpler than doing it for the whole VPN 🫶 that makes Layer 3 VPNs more suitable for customers who don't have sufficient routing expertise, again letting the SP provide added value 💜
as mentioned later, multicast routing and forwarding is another value-added service an SP can offer 🦋
1.3.3. Class of Service 💅
Class-of-Service (CoS) issues have been addressed for Layer 3 VPNs 🎀 since the PE router can see the network Layer (IP), it can take on the tasks of CoS classification and routing 🌸 this restriction on Layer 2 VPNs is again eased in the case of IP-only Layer 2 interworking, since the PE router can see the network Layer (IP) 🔥
1.4. Multicast Routing ✨
okay so multicast routing has two sides we need to look at, bestie 🎀. On the protocol front, supporting IP multicast in a Layer 3 VPN means PE routers have to join the customer's multicast routing instance, which means they have to hold some related state info 🧠.
In a Layer 2 VPN, the CE routers run native multicast routing themselves. The SP network is just pipes connecting the CEs, so the PEs don't even know whether the CEs are doing multicast or not. That means they don't have to take part in multicast protocols or store any multicast state 💅.
On the forwarding front, in a Layer 3 VPN, CE routers don't replicate multicast packets. So the CE-PE link only carries one copy of each multicast packet 🦋. Where the replication happens depends on how fancy the Layer 3 VPN multicast solution is. The simple approach, where a PE copies packets for each of its CEs, can put a lot of pressure on the PE 😭. The more complex solutions may need VPN multicast state in the SP network, but they can seriously cut down the traffic in the SP network by holding off on replication until it's actually needed ✨.
In a Layer 2 VPN, the replication happens at the CE. This is a big win because the replication work is spread across the CEs instead of piling onto the PE they're attached to, so it scales better 📈. The catch is that the CE-PE link has to carry multiple copies of multicast packets. BUT, for Virtual Private LAN Service (a specific type of L2VPN; see [RFC4761]), the CE-PE link only needs to transport one copy of a multicast packet 🫶.
So, just like with unicast routing, the SP gets to pick. They can offer a value-added service (multicast routing and forwarding) at some cost (multicast state and packet replication) using a Layer 3 VPN, or they can keep things simple and go with a Layer 2 VPN 👑.
2. Operation of a Layer 2 VPN 🌸
okay so this simple example is gonna walk you through how a Layer 2 VPN actually works 🧚. We've got a customer with four sites hooked up to three PE routers in a Service Provider network. To keep it simple, we're assuming they want a full-mesh topology 💜.
Quick heads up: in what follows, Frame Relay is the Layer 2 media. Each CE has multiple DLCIs going to its PE, and each one connects to a different CE in the VPN 🦋. If the Layer 2 media were ATM instead, each CE would have multiple VPIs/VCIs (Virtual Path Identifiers/Virtual Channel Identifiers) to reach the other CEs. For Point-to-Point Protocol (PPP) and Cisco High-Level Data Link Control (HDLC), each CE would have multiple physical interfaces to connect to the other CEs. And for IP-only Layer 2 interworking, a CE can mix and match one or more of those Layer 2 media to reach the other CEs 🌈.
2.1. Network Topology 🗺️
Picture a Service Provider network with edge routers PE0, PE1, and PE2. PE0 and PE1 are IGP neighbors, and PE2 is more than one hop away from PE0 💖.
Now, customer C has four sites: S0, S1, S2, and S3. C wants to connect through the Service Provider's network using Frame Relay 💅. Site S0 has CE0 and CE1 both connected to PE0. Site S1 has CE2 connected to PE0. Site S2 has CE3 connected to PE1 and CE4 connected to PE2. Site S3 has CE5 connected to PE2. (Check out Figure 1 below 👀.) C also wants to "overprovision" each current site, because they're expecting the number of sites to grow to at least 10 soon 📈. However, CE4 is only provisioned with nine DLCIs 😬. (Also, the signaling mechanism discussed in Section 3.2 of [RFC4761] lets a site grow its connectivity to other sites later on, at the cost of extra signaling. So overprovisioning isn't a must, it's just a recommendation 🫶.)
Finally, here's how the CEs have been provisioned with DLCIs:
CE# | Provisioned DLCIs
--------------------------------------------------------
0 | 100 through 109
1 | 200 through 209
2 | 100 through 109
3 | 200 through 209
4 | 107, 209, 265, 301, 414, 555, 654, 777, and 888
5 | 417 through 426 S0 S3
.............. ..............
. . . .
. +-----+ . . .
. | CE0 |-----------+ . +-----+ .
. +-----+ . | . | CE5 | .
. . | . +--+--+ .
. +-----+ . | . | .
. | CE1 |-------+ | .......|......
. +-----+ . | | /
. . | | /
.............. | | /
| | SP Network /
.....|...|.............................../.....
. | | / .
. +-+---+-+ +-------+ / .
. | PE0 |-------| P |-- | .
. +-+---+-+ +-------+ \ | .
. / \ \ +---+---+ .
. | -----+ --| PE2 | .
. | | +---+---+ .
. | +---+---+ / .
. | | PE1 | / .
. | +---+---+ / .
. | \ / .
...|.............|.............../.............
| | /
| | /
| | /
S1 | | S2 /
.............. | ........|........../......
. . | . | | .
. +-----+ . | . +--+--+ +--+--+ .
. | CE2 |-----+ . | CE3 | | CE4 | .
. +-----+ . . +-----+ +-----+ .
. . . .
.............. ..........................Figure 1: Example Network Topology
2.2. Configuration ⚙️
The next sub-sections spell out the configuration you need to set up the VPN above 💜. For the sake of this example, we're assuming the customer connects to the SP over Frame Relay circuits 🦋.
We're mostly focused on what the SP has to configure, but we'll touch on what the CEs need too 🎀. The big thing in CE-PE configuration is that both sides have to agree on the DLCIs used on the interface connecting them 🫶.
If the PE-CE connection is Frame Relay, it's recommended to run Link Management Interface (LMI) between the PE and CE 💅. For ATM VCs, Operations, Administration, and Maintenance (OAM) cells may be used. For PPP and Cisco HDLC, keepalives may be used directly between CEs, but then PEs wouldn't have any visibility into whether the customer's circuits are alive 😬.
Now for IP-only Layer 2 interworking: say CE1, attached to PE0, connects to CE3, attached to PE1, over an L2VPN circuit. The Layer 2 media between CE1 and PE0 is totally independent of the Layer 2 media between CE3 and PE1 🌈. Each side runs its own Layer-2-specific link management protocol, like LMI, Link Control Protocol (LCP), and so on. PE0 tells PE1 about the status of its local circuit to CE1 using the circuit status vector TLV defined in Section 3.1. And the same goes the other way: PE1 tells PE0 about the status of its local circuit to CE3 ✨.
2.2.1. CE Configuration 🎀
Every CE that belongs to a VPN gets a "CE ID". CE IDs must be unique within a VPN. For this example, we're assuming the CE ID for CE-k is k 🧚.
Each CE is set up to talk to its PE using the set of DLCIs listed above. For instance, CE0 is configured with DLCIs 100 through 109 🦋. In general, a CE gets a list of circuits, all with the same Layer 2 encapsulation type (like DLCIs, VCIs, or a physical PPP interface, etc.). (IP-only Layer 2 interworking lets you mix encapsulation types, though 🌈.) The size of this list or set decides how many remote CEs a given CE can talk to, and we'll call that size the CE's range 💖. A CE's range must be at least the number of remote CEs that CE will connect to in a given VPN. If the range is bigger than that, the CE is overprovisioned in anticipation of the VPN growing 📈.
Each CE also "knows" which DLCI connects it to every other CE 👀. The method in this example uses the CE ID of the other CE as an index into this CE's DLCI list (zero-based, so 0 is the first index). For example, CE0 reaches CE3 through its fourth DLCI, 103 💅. And CE4 reaches CE2 through the third DLCI in its list, which is 265 🫶. Just to be clear, this is only the method used in this description. The actual way the DLCI gets picked is a local matter 🙈. The key thing is that CE-k can talk to CE-m using a different DLCI than the one CE-m uses to talk back to CE-k. Basically, the SP network acts like a giant Frame Relay switch 🌸. This is a huge deal because it decouples the DLCIs used at each CE site, which makes provisioning way simpler 👑.
2.2.2. PE Configuration 🧚
Each PE is configured with the VPNs it takes part in 💜. Each VPN is tied to one or more Route Target communities [RFC4360], which define the topology of that VPN 🦋. For each VPN, the PE must determine a Route Distinguisher (RD) to use. That can be configured or chosen by the PE itself 🎀. RDs don't have to be unique across the VPN 🌈. For each CE attached to the PE in a given VPN, the PE must know the set of virtual circuits (DLCI, VCI/VPI, or VLAN) that connect it to the CE, plus a CE ID that identifies the CE within the VPN ✨. And CE IDs must be unique in the context of a given VPN 💖.
2.2.3. Adding a New Site 🎀
Okay so the first step in adding a new site is picking a fresh CE ID 💅. If every current VPN member is overprovisioned, meaning their range already covers the new CE ID, then adding the site is totally a local task ✨. If not, any site whose range doesn't include the new CE ID but still wants to talk directly to it has to get its range widened. You do that by allocating extra local circuits so the new CE ID fits in 🦋
Next up, the new site needs its connectivity sorted. That usually means adding a new virtual circuit between the PE and the CE, and in most cases that's limited to the PE in question 🧚
The rest is a local situation between the new CE and the PE it's attached to. At that point, the PE can tell the other PEs it has a new site by advertising a BGP Layer 2 route, and traffic connectivity gets set up 💖
It's worth repeating: the key to making additions easy is overprovisioning, plus the algorithm that maps a CE ID to the DLCI used for connecting to the matching CE 🫶 What's being overprovisioned is the number of DLCIs/VCIs that connect the CE to the PE. That's a local matter between the PE and CE, so it doesn't affect other PEs or CEs 🌸
2.2.4. Deleting a Site 🍓
Deleting a site starts with removing the site's CE ID from the configuration of the PE it's attached to 💀 The PE then signals to other PEs that it no longer has access to that site by withdrawing its previously advertised BGP Layer 2 route. Connectivity to the deleted site ceases ✨
The next steps are bookkeeping 📝 You decommission the attachment circuit from the PE to the CE that matched the removed site, and you note that the CE ID is now free for future allocation. Each PE is now (further) overprovisioned, and if you want, you can actively "reap" CE IDs 🧹
2.2.5. Managing CE ID Mappings 🦋
In the data plane, an attachment circuit (identified, say, by a DLCI) gets mapped to a label through the control plane abstraction of a CE ID. At the egress PE, the label gets mapped back to an attachment circuit via that same CE ID 🔁 The VPN administrator is responsible for:
- provisioning attachment circuits (e.g., DLCIs);
- allocating CE IDs; and
- keeping a clear mapping of CE IDs to attachment circuits (and reflecting this in PE configurations) 📋
The PEs manage the mappings between attachment circuits and labels, i.e., the data plane mappings 💜
Note that in the N-to-one modes listed in Table 1, a single attachment circuit may correspond to several Layer 2 virtual circuits 🌈 Even so, there's a one-to-one mapping between an attachment circuit and a CE ID (and therefore a label) 👑
2.2.6. Managing Label Blocks 🧚
Label blocks and label values are managed by the PEs 🏰 As sites get added and removed, labels get allocated and released. The easiest way to manage these is with fixed-size label blocks rather than variable-size blocks, although the signaling described here supports either ✨ If an implementation uses fixed-size blocks, allocating a label for a new site may need a new block to be allocated, and freeing a label may mean freeing a block too 🫧
If the implementation needs fixed-size blocks, there's probably a default block size, but the implementation SHOULD allow the administrator to choose a size 🎀 Bigger label blocks mean more potentially "wasted" labels but less signaling overhead, and that's a trade-off the administrator might want to control 💅
Also, as sites get added and deleted, a PE may receive packets with a label that reflects a site deleted locally but not yet processed by remote PEs, or one that reflects a new site added remotely but not yet processed locally 🙈 In either of these cases, the PE SHOULD silently discard the packet. It may choose to log the event once for each such label, but not for every single packet 📝
2.3. Operations, Administration, and Maintenance (OAM) 🛠️
Many Layer 2 mediums have OAM mechanisms 🔧 For example, PPP has Echo Request and Echo Reply messages, and Frame Relay has the Local Management Interface. Among other things, OAM is used for troubleshooting and as keepalives 🫶
There are two ways to carry OAM information across Layer 2 VPNs ✌️ The first is to convey OAM packets like any other Layer 2 packets across the VPN. This is the most general method: it maintains full Layer 2 transparency and preserves all OAM information 💎 The other method only applies to the link liveness aspect of OAM. It transmits the status of each attachment circuit across the control plane using the circuit status vector (Section 3.1) 📡
This second method is the only one that works for Layer 2 Interworking VPNs (Section 4), because OAM packets are not IP frames and so can't be transmitted across those Layer 2 VPNs 🚫
3. PE Information Exchange 📬
When a PE is configured with all the required information for a CE, it advertises to other PEs that it's participating in a VPN, via BGP messages, as per [RFC4761], Section 3 💌 BGP was chosen for exchanging L2VPN information for two reasons: it offers mechanisms for both auto-discovery and signaling, and it allows for operational convergence, as explained in Section 1 🧠 A bonus of using BGP is a robust inter-AS solution for L2VPNs 🌍
There are two modifications to the formatting of messages 🎀 The first is that the set of Encaps Types carried in the L2-info extended community has been expanded to include those from Table 1. The value of the Encaps Type field identifies the Layer 2 encapsulation, e.g., ATM, Frame Relay, etc. 🧩
+-----------+-------------------------------------------+-----------+
| Encaps | Description | Reference |
| Type | | |
+-----------+-------------------------------------------+-----------+
| 0 | Reserved | - |
| | | |
| 1 | Frame Relay | RFC 4446 |
| | | |
| 2 | ATM AAL5 SDU VCC transport | RFC 4446 |
| | | |
| 3 | ATM transparent cell transport | RFC 4816 |
| | | |
| 4 | Ethernet (VLAN) Tagged Mode | RFC 4448 |
| | | |
| 5 | Ethernet Raw Mode | RFC 4448 |
| | | |
| 6 | Cisco HDLC | RFC 4618 |
| | | |
| 7 | PPP | RFC 4618 |
| | | |
| 8 | SONET/SDH Circuit Emulation Service | RFC 4842 |
| | | |
| 9 | ATM n-to-one VCC cell transport | RFC 4717 |
| | | |
| 10 | ATM n-to-one VPC cell transport | RFC 4717 |
| | | |
| 11 | IP Layer 2 Transport | RFC 3032 |
| | | |
| 15 | Frame Relay Port mode | RFC 4619 |
| | | |
| 17 | Structure-agnostic E1 over packet | RFC 4553 |
| | | |
| 18 | Structure-agnostic T1 (DS1) over packet | RFC 4553 |
| | | |
| 19 | VPLS | RFC 4761 |
| | | |
| 20 | Structure-agnostic T3 (DS3) over packet | RFC 4553 |
| | | |
| 21 | Nx64kbit/s Basic Service using | RFC 5086 |
| | Structure-aware | |
| | | |
| 25 | Frame Relay DLCI | RFC 4619 |
| | | |
| 40 | Structure-agnostic E3 over packet | RFC 4553 |
| | | |
| 41 (1) | Octet-aligned payload for | RFC 4553 |
| | Structure-agnostic DS1 circuits | |
| | | |
| 42 (2) | E1 Nx64kbit/s with CAS using | RFC 5086 |
| | Structure-aware | |
| | | |
| 43 | DS1 (ESF) Nx64kbit/s with CAS using | RFC 5086 |
| | Structure-aware | |
| | | |
| 44 | DS1 (SF) Nx64kbit/s with CAS using | RFC 5086 |
| | Structure-aware | |
+-----------+-------------------------------------------+-----------+
Table 1: Encaps TypesNote (1): giving Encaps Type its own code point means you don't need the Time Division Multiplexer (TDM) payload size 🙌
Note (2): having separate code points for Encaps Types 42-44 lets you specify the trunk framing (E1, T1 ESF, or T1 SF) with Channel Associated Signaling (CAS) 📶
The second change is the introduction of TLVs (Type-Length-Value triplets) in the VPLS NLRI (Network Layer Reachability Information) 🎁 L2VPN TLVs can be added to extend the information carried in the NLRI, using the format shown in Figure 2 🖼️ In L2VPN TLVs, Type is 1 octet and Length is 2 octets, and Length represents the size of the Value field in bits 🔢 L2VPN TLVs, if present, occur as the last element of a VPLS NLRI. The length of the NLRI includes the total length of the TLVs, including their headers 💫
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (continued, if needed) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Format of TLVs3.1. Circuit Status Vector
okay so this sub-TLV is all about the status of an L2VPN PVC between a pair of PEs 🫶 and the thing to know is that a PVC is bidirectional, which means it's two simplex connections going in opposite directions 🦋 each simplex connection has three segments: 1) the local access circuit between the source CE and the ingress PE, 2) the tunnel Label Switched Path (LSP) between the ingress and egress PEs, and 3) the access circuit between the egress PE and the destination CE ✨
so to monitor a PVC, a PE needs to watch BOTH simplex connections 👀 it already knows its own access circuit status and the status of the tunnel to the remote PE, so it can tell the remote PE those two things. the remote PE does the same thing for its side (its access circuit to its local CE, plus the tunnel to the first PE) 💅 then when a PE puts the local and remote info together, it can figure out the status of the PVC. it's giving teamwork 🤝
the basic unit of advertisement for a given CE is a label block 🎀 each label in that block corresponds to a PVC on the CE. the local status for all the PVCs in a label block gets advertised along with the NLRI for that label block, using the status vector TLV. this TLV has Type field 1 🌸 its Length field tells you the length of the value field in bits, and the Value field is a bit-vector where each bit shows the status of the PVC tied to the matching label in the label block. bit value 0 is for the PVC tied to the first label in the block and means the local circuit AND the tunnel LSP to the remote PE are up ✅ a value of 1 means either or both of them are down ❌ and the Value field gets padded to the nearest octet boundary 🍓
now how does a PE figure out the status of a PVC from one of its CEs to a remote CE? say PE A has CE n in VPN X 🧚 and PE A gets an advertisement from PE B for remote CE m, also in VPN X. that advertisement includes a label block and a circuit status vector ✨ so to pick the right label for CE m, PE A MUST find the index that corresponds to CE m in the label block PE B advertised. then the status of the PVC between CE n and CE m is just the bit in the circuit status vector at that same index. literally that simple, bestie 💖
+----------+-----------------------+
| TLV Type | Description |
+----------+-----------------------+
| 1 | Circuit Status Vector |
+----------+-----------------------+
Table 2: TLV Types3.2. Generalizing the VPN Topology
so in everything above, we pretended the VPN was a full mesh to keep things simple 🙈 but real life has more general VPN topologies, and for those you can use a mechanism based on filtering of BGP extended communities 🌈
4. Layer 2 Interworking ✨
okay so as defined so far in this document, all CE-PE connections for a given Layer 2 VPN have to use the same Layer 2 encapsulation, like they all have to be Frame Relay 😩 that is often a burdensome restriction, ngl. one answer is to use an existing Layer 2 interworking mechanism, like Frame Relay-ATM interworking 🫠
BUT in this document we take a different approach 💅 we assume the network layer is IP and base Layer 2 interworking on that. so you get to choose between pure Layer 2 VPNs, which have a strict Layer 2 restriction but Layer 3 independence, OR Layer 2 interworking VPNs, which have no restriction on Layer 2 but require Layer 3 to be IP 🎀 a PE can also choose to implement Frame Relay-ATM interworking, of course 🦋 for example, an ATM Layer 2 VPN could have some CEs connected via Frame Relay links, as long as their PE can translate Frame Relay to ATM transparently to the rest of the VPN. that stays private to the CE-PE connection, and that kind of setup is outside the scope of this document 🙌
for Layer 2 interworking as defined here, when an IP packet arrives at a PE, its Layer 2 address gets noted, then all the Layer 2 overhead is stripped so you're left with just the IP packet 🧚 next, a VPN label gets added, and the packet is encapsulated in the PE-PE tunnel (as the tunnel technology requires) 🌸 then it's forwarded. the forwarding decision is made on the Layer 2 information, NOT the IP header 👀 at the egress, the VPN label tells you which CE the packet has to go to and over which virtual circuit, and from that the egress PE can also figure out the Layer 2 encapsulation to put on the packet once the VPN label is stripped ✨
an extra perk of restricting interworking to IP-only as the Layer 3 technology is that the provider's network can give the L2VPN customer IP Diffserv or any other IP-based QoS mechanism 💖 the ingress PE can set up IP/TCP/UDP-based classifiers to do Diffserv marking, plus other stuff like policing and shaping on the VPN customer's L2 circuits 🍓 and here's the division of labor, bestie: the CE decides the destination CE and encodes that in the Layer 2 address 🫶 the ingress PE then uses that Layer 2 address to figure out the egress PE and VPN label. the ingress PE can pick the tunnel to reach the egress PE (if there are different tunnels for each CoS/Diffserv code point) or pick the CoS bits to put in the tunnel (if a single tunnel carries multiple CoS/Diffserv code points), and it does this based on its own classification of the packet 🔥
5. Packet Transport 🚀
when a packet arrives at a PE from a CE in a Layer 2 VPN, the packet's Layer 2 address says which remote attachment circuit (and therefore which remote CE) it's headed to 🎯 the procedure from above installs a route that maps that Layer 2 address to a tunnel (which identifies the PE the destination CE is attached to) and a VPN label (which identifies the destination AC) 💜 and if the egress PE is the same as the ingress PE, you don't need a tunnel or a VPN label at all 🙈
the packet may then get modified, depending on the Layer 2 encapsulation 🎀 for IP-only Layer 2 interworking, the Layer 2 header is completely stripped off up to the IP header. then a VPN label and tunnel encapsulation get added as the route above says, and the packet gets sent to the egress PE 🦋
if the egress PE is the same as the ingress, the packet "arrives" with no labels 🌈 otherwise, it arrives with the VPN label, and that label is what tells the PE which CE is the destination CE 💅 the packet is then restored to a fully formed Layer 2 packet and sent on to the CE ✨
5.1. Layer 2 MTU
this document requires that the Layer 2 MTU configured on all the access circuits connecting CEs to PEs in an L2VPN be the same 📏 you can make sure of that by passing the configured Layer 2 MTU in the Layer2-info extended community when advertising L2VPN label blocks 🌸 when a PE gets an L2VPN label block from remote PEs in a VPN, the MTU value carried in the Layer2-info extended community should be compared against the configured value for the VPN. if they don't match, the label block should be ignored 🙅♀️
the MTU on the Layer 2 access links MUST be chosen so that the size of the L2 frames plus the L2VPN header does not exceed the MTU of the SP network 😤 Layer 2 frames that go over the MTU after encapsulation MUST be dropped, no exceptions 💀 for the case of IP-only Layer 2 interworking, the IP MTU on the Layer 2 access link must be chosen so that the size of the IP packet and the L2VPN header does not exceed the MTU of the SP network 🫶
5.2. Layer 2 Frame Format
the modification to the Layer 2 frame depends on the Layer 2 type 🧚 this document requires that the encapsulation methods used when transporting Layer 2 frames over tunnels be the same as described in [RFC4448], [RFC4618], [RFC4619], and [RFC4717], EXCEPT for IP-only Layer 2 Interworking, which is described next 🎀
5.3. IP-Only Layer 2 Interworking
+-----------------------------------+
| PSN Transport | VPN | IP | VPN label is the
| Header | Label | Packet | demultiplexing field
+-----------------------------------+
Figure 3: Format of IP-Only Layer 2 Interworking Packetat the ingress PE, an L2 frame's L2 header is completely stripped off and carried over as an IP packet within the SP network (see Figure 3) 🦋 the forwarding decision is still based on the L2 address of the incoming L2 frame 👀 at the egress PE, the IP packet gets encapsulated back into an L2 frame and transported over to the destination CE 💖 the forwarding decision at the egress PE is based on the VPN label, same as before 🌸 and the L2 technology between the egress PE and the CE is independent of the L2 technology between the ingress PE and the CE, so they don't have to match 🌈
6. Security Considerations 🔐
okay bestie, serious moment 😭 RFC 4761 [RFC4761], which this document is based on, has a detailed discussion of security considerations 📚 just like RFC 4761, the focus here is the privacy of customer VPN data (as opposed to confidentiality, integrity, or authentication of said data). if you want the latter, you can use the methods suggested in RFC 4761 🔒 the techniques RFC 4761 describes for securing the control plane and protecting the forwarding path apply equally to L2VPNs, and so do the remarks about multi-AS operation 🌐 the mitigation strategies and the analogies with RFC 4364 [RFC4364] also apply here 🛡️
RFC 4761 perhaps should have discussed Denial-of-Service attacks based on the fact that VPLS PEs have to learn Media Access Control (MAC) addresses and replicate packets (for flooding and multicast) 😱 however, those considerations don't apply here, because neither of those actions is required of PEs implementing the procedures in this document 🙌 phew 💜
7. IANA Considerations 📋
IANA has created two new registries 🎀 the first is for the one-octet Encaps Type field of the L2-info extended community. the name of the registry is "BGP Layer 2 Encapsulation Types", and the values already allocated are in Table 1 of Section 3 🌸 the allocation policy for new entries up to and including value 127 is "Expert Review" [RFC5226]. the allocation policy for values 128 through 251 is "First Come First Served". the values from 252 through 255 are for "Experimental Use" 🧚
the second registry is for the one-octet Type field of the TLVs of the VPLS NLRI 💖 the name of the registry is "BGP L2 TLV Types", and the sole allocated value is in Table 2 of Section 3 ✨ the allocation policy for new entries up to and including value 127 is "Expert Review". the allocation policy for values 128 through 251 is "First Come First Served". the values from 252 through 255 are for "Experimental Use" 🍓
8. Acknowledgments 🫶
the authors would like to thank Chaitanya Kodeboyina, Dennis Ferguson, Der-Hwa Gan, Dave Katz, Nischal Sheth, John Stewart, and Paul Traina for the enlightening discussions that helped shape the ideas here 🌟 the authors also thank Ross Callon for his valuable comments 💅
the idea of using extended communities for more general connectivity of a Layer 2 VPN was a contribution by Yakov Rekhter, who also gave many useful comments on the text 👑 many thanks to him, periodt 🥹✨
9. Contributors 🎀
okay so bestie, this section is basically the thank-you list 🫶 these are the people who helped write this doc, and I'm obsessed with how many of them are from Juniper Networks, lol. Here they are, no cap:
Manoj Leelanivas, Juniper Networks
Quaizar Vohra, Juniper Networks
Javier Achirica, Consultant
Ronald Bonica, Juniper Networks
Dave Cooper, Global Crossing
Chris Liljenstolpe, Telstra
Eduard Metz, KPN Dutch Telecom
Hamid Ould-Brahim, Nortel
Chandramouli Sargor
Himanshu Shah, Ciena
Vijay Srinivasan
Zhaohui Zhang, Juniper Networks10. References 📚
okay now the reference list, which is where all the docs this one leans on are listed. Every single one matters, so here they are in full ✨
10.1. Normative References 💖
these are the ones you really need to have read, bestie, because the spec depends on them 🧚
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge
Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron,
"Encapsulation Methods for Transport of Ethernet over MPLS
Networks", RFC 4448, April 2006.
[RFC4618] Martini, L., Rosen, E., Heron, G., and A. Malis,
"Encapsulation Methods for Transport of PPP/High-Level
Data Link Control (HDLC) over MPLS Networks", RFC 4618,
September 2006.
[RFC4619] Martini, L., Kawa, C., and A. Malis, "Encapsulation
Methods for Transport of Frame Relay over Multiprotocol
Label Switching (MPLS) Networks", RFC 4619,
September 2006.
[RFC4717] Martini, L., Jayakumar, J., Bocci, M., El-Aawar, N.,
Brayley, J., and G. Koleyni, "Encapsulation Methods for
Transport of Asynchronous Transfer Mode (ATM) over MPLS
Networks", RFC 4717, December 2006.
[RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service
(VPLS) Using BGP for Auto-Discovery and Signaling",
RFC 4761, January 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.10.2. Informative References 🌸
these ones are the extra reading, super helpful for context but not strictly needed to implement the thing 🦋
[Kosiur] Kosiur, D., "Building and Managing Virtual Private
Networks", Wiley Computer Publishing, 1998.
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
Edge (PWE3) Architecture", RFC 3985, March 2005.
[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.
[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
R., Patel, K., and J. Guichard, "Constrained Route
Distribution for Border Gateway Protocol/MultiProtocol
Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
Private Networks (VPNs)", RFC 4684, November 2006.
[RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service
(VPLS) Using Label Distribution Protocol (LDP) Signaling",
RFC 4762, January 2007.
[RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo,
"Provisioning, Auto-Discovery, and Signaling in Layer 2
Virtual Private Networks (L2VPNs)", RFC 6074,
January 2011.Authors' Addresses 🦋
these are the folks who wrote the doc, with their contact info so you can reach out, periodt 💅
Kireeti Kompella
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
USA
EMail: kireeti@juniper.net
Bhupesh Kothari
Cisco Systems
3750 Cisco Way
San Jose, CA 95134
USA
EMail: bhupesh@cisco.com
Rao Cherukuri
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
USA
EMail: cherukuri@juniper.netThat's the whole doc, bestie! 🌈👑 You made it through all six parts, and honestly we deserve a snack 🍓✨
📦 where this page comes from
- ietf: rfc6624 2012-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms