RFC 5195

BGP-Based Auto-Discovery for Layer-1 VPNs

📅 published June 2008, from ietf

RFC 5195: BGP-Based Auto-Discovery for Layer-1 VPNs 🎀

okay bestie, this is Part 1 of 2 and it's giving networking royalty 👑 It's a Standards Track doc from the Network Working Group, dated June 2008 📅. The authors are H. Ould-Brahim (Nortel), D. Fedyk (Nortel), and Y. Rekhter (Juniper Networks) 🫶. It doesn't obsolete or update any other RFC, so it's its own main character 🦋

Status of This Memo 📜

This doc is an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions to make it better 💬. If you want the official standardization state and status of this protocol, check the current edition of "Internet Official Protocol Standards" (STD 1) 🔍. Distribution of this memo is unlimited 🌈.

Abstract 💖

Okay so this doc defines a BGP-based auto-discovery mechanism for Layer-1 VPNs (L1VPNs) 🧚. The whole point is that provider network devices can dynamically find the set of Provider Edges (PEs) that have ports attached to Customer Edge (CE) members of the same VPN. That info is a must for finishing the signaling phase of L1VPN connections 💅. One big goal is supporting the "single-end provisioning" model, which is so iconic: adding a new port to an L1VPN only means config changes on the PE that has the port and on the CE connected to that PE through it ✨

1. Introduction ✨

Okay so the purpose here is still the same: a BGP-based auto-discovery mechanism for Layer-1 VPNs (L1VPNs) [L1VPN-FRMK] 💖. Provider devices find the PEs with ports on CE members of the same VPN, and that info powers the signaling phase of L1VPN connections. The main goal is again the "single-end provisioning" model. Adding a port to an L1VPN only touches the PE with that port and the CE hooked up to it 🫶

Here's how the auto-discovery works. Each PE advertises its own IP address to other PEs, plus at least a list of <private address, provider address> tuples that are local to that PE 📣. When remote PEs get that info, they figure out which VPN members they share with the advertising PE. Then they use the info in the discovery mechanism to do address resolution during the signaling phase of Layer-1 VPN connections 🦋

Check out the network reference in Figure 1 🎀. For auto-discovery, BGP only runs on the provider network. Each PE keeps per-VPN tables called Port Information Tables (PITs) that store <private address, provider address> info. More on PITs in Section 2 🔍

                   PE1                        PE2
               +---------+             +--------------+
   +--------+  | +------+|             | +----------+ | +--------+
   |  VPN-A |  | |VPN-A ||             | |  VPN-A   | | |  VPN-A |
   |   CE1  |--| |PIT   ||  BGP route  | |  PIT     | |-|   CE2  |
   +--------+  | |      ||<----------->| |          | | +--------+
               | +------+| Distribution| +----------+ |
               |         |             |              |
   +--------+  | +------+|             | +----------+ | +--------+
   | VPN-B  |  | |VPN-B ||  --------   | |   VPN-B  | | |  VPN-B |
   |  CE1   |--| |PIT   ||-(   GMPLS )-| |   PIT    | |-|   CE2  |
   +--------+  | |      || (Backbone ) | |          | | +--------+
               | +------+|  ---------  | +----------+ |
               |         |             |              |
   +--------+  | +-----+ |             | +----------+ | +--------+
   | VPN-C  |  | |VPN-C| |             | |   VPN-C  | | |  VPN-C |
   |  CE1   |--| |PIT  | |             | |   PIT    | |-|   CE2  |
   +--------+  | |     | |             | |          | | +--------+
               | +-----+ |             | +----------+ |
               +---------+             +--------------+

                   Figure 1: BGP Auto-Discovery for L1VPN

[L1VPN-FRMK] describes two modes of operation for an L1VPN: the basic mode and the enhanced mode 🌸. This doc only covers an auto-discovery mechanism for the basic mode, so the enhanced mode is a different story 🙈

1.1. Requirements Language

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. Procedures 💅

Okay so picture a CE hooked up to a PE through one or more ports, and each port might have one or more channels or sub-channels 🧩. Every port on a CE that connects to a PE has an identifier that's unique within that L1VPN (but it doesn't need to be unique across several L1VPNs). We call this the customer port identifier (CPI) 🎀. Every port on a PE also has an identifier that's unique within the provider network. That's the provider port identifier (PPI) 💜. Also, IP addresses used for CPIs or PPIs could be IPv4 or IPv6 addresses 🌈

For each L1VPN with at least one port configured on a PE, the PE keeps a Port Information Table (PIT) 🗂️. A PIT holds a list of <CPI, PPI> tuples for all the ports in its L1VPN. It may also hold routing info, like when CPIs are learnt through a routing protocol 🧚

A PIT on a PE gets filled with two kinds of info 👑

  • Info about the CEs' ports attached to the PE's ports. This could be configured locally on the PE, or it could come from the CEs.
  • Info received from other PEs through the auto-discovery mechanism.

The first one is local info, and the second is remote info 💖. Local info gets sent to other PEs using BGP multiprotocol extensions [RFC4760] 📣. To keep this info flowing only to PITs in the same L1VPN, we use BGP route filtering based on the Route Target Extended Community [BGP-COMM]. Here's how that works 🦋

Each PIT on a PE gets one or more Route Target Communities called "export Route Targets", which tag the local info when it's exported into the provider's BGP 🏷️. The tagging could be as fine-grained as a single <CPI, PPI> pair ✨. Each PIT on a PE is also configured (at provisioning time) with one or more Route Target Communities called "import Route Targets". These limit which routes can be imported from the provider's BGP into the PIT, so only routes with at least one of these Communities get in 🔒

Each of the following happens at provisioning time: if a service provider adds a new L1VPN port to a PE, that port gets associated with a PIT on that PE, and that PIT gets associated with the L1VPN 🎀

Here's a fun one. Since BGP fills a PIT with remote info, and BGP works across multiple autonomous systems (ASs), this mechanism could support L1VPNs that span multiple ASs 🌍

Multi-AS L1VPNs are currently out of scope for the Basic Mode 🙈. Still, the mechanisms here look pretty easy to apply to a multi-AS scenario if that ever comes up. If it does, more work might be needed to look at various aspects, including security 🔐

3. Carrying L1VPN Information in BGP 🦋

The <CPI, PPI> mapping rides along in the Multiprotocol Extensions to BGP [RFC4760] 🚀. [RFC4760] defines two BGP attributes, MP_REACH_NLRI and MP_UNREACH_NLRI, which can announce reachability info and withdraw those announcements 📣. This doc adds a new subsequent address family identifier called Layer-1 VPN auto-discovery information (value 69). It also adds a new Network Layer Reachability Information (NLRI) format for carrying the CPI and PPI info 💅

One or more <PPI, CPI> tuples could be carried in those BGP attributes 🧩

The NLRI format is in Figure 2 ✨

                   +---------------------------------------+

                   |     Length (1 octet)                  |

                   +---------------------------------------+

                   |     Auto-discovery info (variable)    |

                   +---------------------------------------+

                         Figure 2: Encoding of the NLRI

The encoding of the auto-discovery info is described in [L1VPN-BM] 📖. Also, if the Length of the Next Hop field (in the MP_REACH_NLRI attribute) is 4, then the Next Hop holds an IPv4 address. If that value is 16, then the Next Hop holds an IPv6 address 🌐

4. Carrying L1VPN Traffic Engineering Information in BGP 👑

The auto-discovery mechanism MAY also carry Traffic Engineering info that's used to pick egress paths 🛣️. For example, a PE may learn the switching capability and the maximum LSP bandwidth of remote L1VPN interfaces from the remote PEs 💅. This doc uses the BGP Traffic Engineering Attribute [BGP-TE-ATTRIBUTE] to carry that info ✨

5. Scalability ✨

okay so bestie, let's talk about how this whole thing scales 💅 Recall that the Service Provider network is made of (a) PEs, (b) BGP Route Reflectors, (c) P nodes (which are neither PEs nor Route Reflectors), and, if we're doing multi-provider VPNs, (d) Autonomous System Border Routers (ASBRs). 🧚

A PE router that isn't a Route Reflector doesn't keep L1VPN-related information unless it has at least one VPN with an import Route Target that matches one of the Route Target attributes on the VPN-related information. If a PE doesn't have a VPN with a matching import Route Target, it MUST then discard the received l1VPN information. Inbound filtering MUST be used to make sure that info gets discarded. 🗑️ If a new import Route Target gets added to one of the PE's VPNs (a "VPN Join" operation), it MUST then acquire the VPN-related information it had previously discarded. 🦋

In this case, the refresh mechanism described in [BGP-RFSH] MUST be used. The outbound route filtering mechanisms of [BGP-ORF] and [BGP-CONS] can also be used to advantage to make the filtering more dynamic. It's giving flexibility, periodt 🌈

Similarly, if a particular import Route Target is no longer present in any of a PE's VPNs (because of one or more "VPN Prune" operations), the PE MAY discard all the L1VPN BGP routes that, as a result, no longer have any of the PE's PIT's import Route Targets as one of their Route Target attributes. 🌸

Note that "VPN Join" and "VPN Prune" operations are non-disruptive, and they don't require any BGP connections to be brought down, as long as the refresh mechanism of [BGP-RFSH] is used. No drama, no disconnects 🫶

As a result of these distribution rules, no single PE ever needs to maintain all routes for all L1VPNs. This is a really important scalability consideration, bestie 👑

Route reflectors can be partitioned among VPNs so that each partition carries routes for only a subset of the L1VPNs supported by the Service Provider. So no single route reflector is required to maintain VPN-related information for all VPNs. Divide and conquer, iconic 💜

For inter-provider VPNs, if multi-hop External BGP (EBGP) is used, then the ASBRs don't need to maintain and distribute VPN-related information at all. P routers don't maintain any VPN-related information either. 🍓

So no single component in the Service Provider network has to maintain all the VPN-related information for all the VPNs. That means the total capacity of the network to support more and more VPNs isn't capped by the capacity of any one component. Literally infinite vibes, ngl ✨

Here's the lowkey subtle part 🙈 You can have any number of INDEPENDENT BGP systems carrying VPN-related information. This is unlike the Internet, where the Internet BGP system MUST carry all the Internet routes. So one big (but kinda subtle) difference between using BGP for Internet routing and using it to distribute VPN-related information, as described in this document, is that the Internet's BGP can't be partitioned, while the VPN one can. Partition it, slay 🎀

6. Security Considerations 🔐

Okay this section is SERIOUS, so pay attention 😭 This document describes a BGP-based auto-discovery mechanism that lets a PE attached to a particular L1VPN discover the set of other PE routers attached to the same VPN. Each PE router attached to a given VPN uses BGP to advertise that fact, and the other PEs on the same VPN receive those advertisements, which lets the whole set find each other. Note that a PE won't always get these advertisements directly from the remote PEs; they can come from "intermediate" BGP speakers. 🦋

It is of critical importance that a particular PE MUST NOT be "discovered" as attached to a particular VPN unless that PE really is attached to that VPN, and is properly authorized to be attached to it. 🚨 If any random node on the Internet could start sending these BGP advertisements, and those advertisements could reach the PE nodes, and the PE nodes accepted them, then anyone could add any site to any L1VPN. Chaos, bestie 💀 So the auto-discovery procedures here presuppose that a PE trusts its BGP peers to be who they appear to be, and further, that it can trust those peers to be properly securing their local attachments. (Basically, a PE MUST trust that its peers are attached to, and authorized to be attached to, the L1VPNs they claim to be attached to.) 🫶

If a remote PE is a BGP peer of the local PE, then the BGP authentication procedures of [RFC2385] SHOULD be used to make sure the remote PE is who it claims to be, i.e., that it's a PE that's trusted. 🔑

If a remote PE is not a BGP peer of the local PE, then the information it's advertising is reaching the local PE through a chain of BGP speakers. The local PE MUST trust that its peers only accept information from peers that they trust in turn, and this trust relation MUST be transitive. 🔗 BGP doesn't have a way to figure out whether a particular piece of received information came from a BGP speaker that was authorized to advertise it. So the procedures in this document MUST be used only in environments where adequate trust relationships exist among the BGP speakers (like using the auto-discovery mechanism inside a single provider network). Trust is everything, no cap 👑

7. IANA Considerations 🌈

This document assigns a new SAFI, called Layer-1 VPN auto-discovery information (see Section 3). The assignment was made in the Subsequent Address Family Identifier (SAFI) registry using the Standards Action allocation procedures. The value is 69. ⭐

8. References 📚

8.1. Normative References

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
  • [BGP-RFSH] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, September 2000.

8.2. Informative References

  • [BGP-TE-ATTRIBUTE] Ould-Brahim, H., Fedyk, D., and Rekhter, Y., "Traffic Engineering Attribute", Work in Progress, January 2008.
  • [BGP-ORF] Chen, E. and Y. Rekhter, "Outbound Route Filtering Capability for BGP-4", Work in Progress, September 2006.
  • [BGP-CONS] 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.
  • [BGP-COMM] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006.
  • [L1VPN-FRMK] Takeda, T., Ed., "Framework and Requirements for Layer 1 Virtual Private Networks", RFC 4847, April 2007.
  • [L1VPN-BM] Fedyk, D., Ed., Rekhter, Y., Ed., Papadimitriou, D., Rabbat, R., and L. Berger, "Layer 1 VPN Basic Mode", Work in Progress, February 2008.
  • [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.

9. Acknowledgment 🫶

We would like to thank Adrian Farrel for the useful comments. 💖

Authors' Addresses 🎀

Hamid Ould-Brahim Nortel PO Box 3511 Station C Ottawa ON K1Y 4H7 Canada

Phone: +1 (613) 763 4730 EMail: hbrahim@nortel.com

Yakov Rekhter Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089 USA

EMail: yakov@juniper.net

Don Fedyk Nortel 600 Technology Park Billerica, MA 01821 USA

Phone: +1 (978) 288 3041 Email: dwfedyk@nortel.com

Copyright (C) The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🌸

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

📦 where this page comes from