RFC 4684
Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)
RFC 4684 💖 Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)
- Authors: P. Marques, R. Bonica (Juniper Networks), L. Fang, L. Martini, R. Raszuk, K. Patel, J. Guichard (Cisco Systems, Inc.) 🎀
- Category: Standards Track 🦋
- Date: November 2006 🌸
- Updates: RFC 4364 ✨
- Obsoletes: nothing listed 🧚
Status of This Memo
okay so this one is an Internet standards track protocol for the Internet community, and it's literally asking everyone to chat about it and send suggestions for improvements 🫶 For the current standardization state and status, check the "Internet Official Protocol Standards" (STD 1) doc. And the memo can be distributed with no limits, so share away 💅
Copyright Notice
Copyright (C) The IETF Trust (2006). 🌈
Abstract
this doc defines Multi-Protocol BGP (MP-BGP) procedures that let BGP speakers swap Route Target reachability info 🔥 That info can be used to build a route distribution graph, which is lowkey the whole point, because it limits how far Virtual Private Network (VPN) Network Layer Reachability Information (NLRI) gets passed around between different autonomous systems or separate clusters inside the same autonomous system 👑 This document updates RFC 4364.
Table of Contents
1. Introduction ....................................................2
1.1. Terminology ................................................3
2. Specification of Requirements ...................................4
3. NLRI Distribution ...............................................4
3.1. Inter-AS VPN Route Distribution ............................4
3.2. Intra-AS VPN Route Distribution ............................6
4. Route Target Membership NLRI Advertisements .....................8
5. Capability Advertisement ........................................9
6. Operation .......................................................9
7. Deployment Considerations ......................................10
8. Security Considerations ........................................11
9. Acknowledgements ...............................................11
10. References ....................................................11
10.1. Normative References .....................................11
10.2. Informative References ...................................121. Introduction ✨
okay so in BGP/MPLS IP VPNs, PE routers use Route Target (RT) extended communities to decide which routes get pushed into VRFs 💖 Inside a single iBGP mesh, PE routers only need to hold onto routes tagged with Route Targets for VRFs that have local CE attachments. Super efficient, no notes 🍓
It's super common, though, for an autonomous system to use route reflection [2] 🧚 That makes it way easier to bring up a new PE router and keeps the iBGP peering mesh from getting out of hand.
In that kind of setup, and also when a VPN has members in more than one autonomous system, the number of routes that the inter-cluster or inter-as distribution routers carry becomes a big deal 😭
To keep the VPN routing info that a given route reflector has to maintain under control, RFC 4364 [3] suggests, in Section 4.3.3, using "Cooperative Route Filtering" [7] between route reflectors. This document extends the Outbound Route Filtering (ORF) work from RFC 4364 [3] so it also works across multiple autonomous systems and asymmetric VPN topologies, like hub-and-spoke 🎀
We could extend the encoding that's already defined for the extended-community ORF to do this. BUT BGP already has all the machinery it needs to spread arbitrary information around in a loop-free way, both inside one autonomous system and across several of them 🧠 So why reinvent the wheel? 💅
This document builds on the model from RFC 4364 [3] and on the idea of cooperative route filtering, and adds the ability to pass Route Target membership info between iBGP meshes 🦋 It's designed to supersede "cooperative route filtering" for VPN-related applications.
By sending Route Target membership info in MP-BGP UPDATE messages, we get to reuse all of that machinery, including route reflection, confederations, and inter-as information loop detection ✨ Iconic reuse energy.
Received Route Target membership info can then be used to limit advertisement of VPN NLRI to peers that have advertised their respective Route Targets, which effectively builds a route distribution graph 🌈 In this model, VPN NLRI routing info flows in the opposite direction from Route Target membership info. Main character flow 👑
This mechanism applies to any BGP NLRI that uses Route Targets to control how routing info gets distributed, such as VPLS [9] 🫶
Throughout this document, the term NLRI, which expands to "Network Layer Reachability Information", is used to describe routing info carried in MP-BGP updates without assuming any particular semantics 🌸
An NLRI made up of {origin-as#, route-target} is called RT membership information for the purposes of this document 💜
1.1. Terminology
this doc uses a bunch of terms and acronyms that are specific to Provider-Provisioned VPNs, including the ones for L2VPNs, L3VPNs, and BGP 🧚 Definitions for lots of these can be found in the VPN terminology document [10]. This section also has some quick acronym expansions and terms to help you out 🍓
AFI Address Family Identifier (a BGP address type)
BGP Border Gateway Protocol
BGP/MPLS VPN A Layer 3 VPN implementation based upon BGP and MPLS
CE Customer Edge (router)
iBGP Internal BGP (i.e., a BGP peering session that
connects two routers within an autonomous system)
L2VPN Layer 2 Virtual Private Network
L3VPN Layer 3 Virtual Private Network
MP-BGP MultiProtocol-Border Gateway Protocol
MPLS MultiProtocol Label Switching
NLRI Network Layer Reachability Information
ORF Outbound Route Filtering
PE Provider Edge (router)
RT Route Target (i.e., a BGP extended community that
conditions network layer reachability information with
VPN membership)
SAFI Subsequence Address Family Identifier (a BGP address
sub-type)
VPLS Virtual Private LAN Service
VPN Virtual Private Network2. Specification of Requirements 💅
the key words for this doc are the ones in the sentence below, and they're meant to be read the way RFC 2119 [1] describes 🫶
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
3. NLRI Distribution 🦋
3.1. Inter-AS VPN Route Distribution
okay this part is about splitting the problem into its inter-Autonomous System (AS) and intra-AS pieces, because that makes it way less confusing 🌈 Figure 1 shows an arbitrary graph of autonomous systems (a through j) that are connected in an ad hoc way. The discussion below ignores how complicated intra-AS route distribution is.
+----------------------------------+
| +---+ +---+ +---+ |
| | a | -- | b | -- | c | |
| +---+ +---+ +---+ |
| | | |
| | | |
| +---+ +---+ +---+ +---+ |
| | d | -- | e | -- | f | -- | j | |
| +---+ +---+ +---+ +---+ |
| / | |
| / | |
| +---+ +---+ +---+ |
| | g | -- | h | -- | i | |
| +---+ +---+ +---+ |
+----------------------------------+Figure 1. Topology of autonomous systems
Let's start with the simple case of a VPN that has CE attachments in ASes a and i and uses a single Route Target to control VPN route distribution 🎀 Ideally we'd build a flooding graph for those VPN routes that doesn't include nodes (c, g, h, j). Nodes (c, j) are leaf ASes that don't need this info, and nodes (g, h) aren't on the shortest inter-as path between (e) and (i), so they should get excluded through standard BGP path selection 💖
To make that happen, we rely on ASa and ASi generating an NLRI made up of {origin-as#, route-target} (RT membership information) ✨ When one of the ASes in the network receives an advertisement like that, it knows it needs to distribute VPN routes carrying that Route Target community to the peer that advertised the route 🧚
Using RT membership information that includes both the route-target and the originator AS number lets BGP speakers use standard path selection rules around as-path length (and other policy mechanisms) to prune duplicate paths in the RT membership information flooding graph 🔥 It still keeps the info needed to reach every autonomous system that advertises the Route Target 🫶
In the example above, AS e has to keep a path to AS a so it can flood VPN routing info that comes from AS i, and vice versa 🌸 It should, however, as default policy, prune the less preferred paths, like the longer path to ASi with as-path (g h i) 👑
Now, if we add AS j as a member of the VPN distribution graph, AS f would advertise 2 RT Membership NLRIs to AS e, one containing origin AS i and one containing origin AS j 😭 Advertising a single path would be enough to guarantee that VPN info reaches every VPN member AS, but that isn't enough for the path selection choices we want. In the example above, say (f j) is selected and advertised. If that happened, the information about the path (f i) would be missing, and that's the info needed to prune the arc (e g h i) from the route distribution graph 💀
Like with other approaches for building distribution graphs, how much this mechanism helps depends directly on how "sparse" the VPN membership is 🍓 Standard RFC2547 inter-AS behavior can be seen as a dense-mode approach, if you want to compare it to multicast routing protocols 🦋
3.2. Intra-AS VPN Route Distribution ✨
Okay so, like I said before, the inter-AS VPN route distribution graph for a given route-target gets built by making a directed arc on the inverse direction of the received Route Target membership UPDATEs that carry an NLRI shaped like {origin-as#, route-target}. 🧩
Inside the BGP topology of one autonomous-system, when we're talking about external RT membership info (route-targets where the as# is not the local AS), it's honestly easy to see that standard BGP route selection and advertisement rules [4] let a transit AS build the flooding state it needs. 💅
Picture an IPv4 NLRI prefix sourced by a single AS and distributed via BGP inside a transit AS. BGP protocol rules guarantee that a BGP speaker has a valid route it can use to forward data packets for that destination prefix, following the inverse path of the routing updates it received. 🦋
By the same token, since an {origin-as#, route-target} key provides uniqueness between the several ASes that might be sourcing the same route-target, BGP route selection and advertisement procedures guarantee that a valid VPN route distribution path exists to the origin of the Route Target membership information advertisement. 💖
Route Target membership info that's originated within the autonomous-system, though? That one needs more careful examination 👀. Several PE routers in one AS may source the same NLRI {origin-as#, route-target}, so default route advertisement rules are no longer enough to guarantee that within the AS, every node in the distribution graph has selected a feasible path to each of the PEs that import the given route-target. 🙈
When processing RT membership NLRIs received from internal iBGP peers, you have to consider all available iBGP paths for a given RT prefix when building the outbound route filter, and not just the best path. 🎯
Also, when advertising Route Target membership information sourced by the local autonomous system to an iBGP peer, a BGP speaker shall modify its procedure to calculate the BGP attributes so that the following apply:
i. When advertising RT membership NLRI to a route-reflector client, the Originator attribute shall be set to the router-id of the advertiser, and the Next-hop attribute shall be set of the local address for that session.
ii. When advertising an RT membership NLRI to a non-client peer, if the best path as selected by the path selection procedure described in Section 9.1 of the base BGP specification [4] is a route received from a non-client peer, and if there is an alternative path to the same destination from a client, the attributes of the client path are advertised to the peer.
The first of these rules is designed so the originator of an RT membership NLRI doesn't drop an RT membership NLRI that gets reflected back to it. That lets the route reflector use this NLRI to signal the client that it should distribute VPN routes with the specific target towards the reflector. 🔁
The second rule lets any BGP speaker in an iBGP mesh signal the interest of its route reflection clients in receiving VPN routes for that target. 📣
These procedures assume the autonomous-system route reflection topology is configured so IPv4 unicast routing would work correctly. For instance, route reflection clusters must be contiguous. 🧠
An alternative solution would have been to source different routes per PE, like NLRI of the form {originator-id, route-target}, and aggregate them at the edge of the network. The adopted solution is considered advantageous over the former because it requires less routing-information within a given AS. 🌈
4. Route Target Membership NLRI Advertisements 🎀
Route Target membership NLRI is advertised in BGP UPDATE messages using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes [5]. The [AFI, SAFI] value pair used to identify this NLRI is (AFI=1, SAFI=132). 💕
The Next Hop field of the MP_REACH_NLRI attribute shall be interpreted as an IPv4 address whenever the length of the NextHop address is 4 octets, and as an IPv6 address whenever the length of the NextHop address is 16 octets. 🌐
The NLRI field in MP_REACH_NLRI and MP_UNREACH_NLRI is a prefix of 0 to 96 bits, encoded as defined in Section 4 of [5]. 📦
This prefix is structured like this:
+-------------------------------+
| origin as (4 octets) |
+-------------------------------+
| route target (8 octets) |
+ +
| |
+-------------------------------+Except for the default route target, which is encoded as a zero-length prefix, the minimum prefix length is 32 bits, because the origin-as field cannot be interpreted as a prefix. 🙅♀️
Route targets can also be expressed as prefixes. For instance, one prefix could cover all route target extended communities assigned by a given Global Administrator [6]. 🧁
The default route target can be used to indicate to a peer the willingness to receive all VPN route advertisements, such as the case of a route reflector speaking to one of its PE router clients. 🫧
5. Capability Advertisement 💅
A BGP speaker that wishes to exchange Route Target membership information must use the Multiprotocol Extensions Capability Code, as defined in RFC 2858 [5], to advertise the corresponding (AFI, SAFI) pair. 📣
A BGP speaker MAY participate in the distribution of Route Target information without using the learned information for purposes of VPN NLRI output route filtering, although this is discouraged. 🤷♀️
6. Operation 🦋
A VPN NLRI route should be advertised to a peer that participates in the exchange of Route Target membership information if that peer has advertised either the default Route Target membership NLRI or a Route Target membership NLRI containing any of the targets contained in the extended communities attribute of the VPN route in question. 🎀
When a BGP speaker receives a BGP UPDATE that advertises or withdraws a given Route Target membership NLRI, it should examine the RIB-OUTs of VPN NLRIs and re-evaluate the advertisement status of routes that match the Route Target in question. 👀
A BGP speaker should generate the minimum set of BGP VPN route updates (advertisements and/or withdrawals) necessary to transition between the previous and current state of the route distribution graph that is derived from Route Target membership information. ✨
As a hint that initial RT membership exchange is complete, implementations SHOULD generate an End-of-RIB marker, as defined in [8], for the Route Target membership (afi, safi), regardless of whether graceful-restart is enabled on the BGP session. This allows the receiver to know when it has received the full contents of the peer's membership information. The exchange of VPN NLRI should follow the receipt of the End-of-RIB markers. 🏁
If a BGP speaker chooses to delay the advertisement of BGP VPN route updates until it receives this End-of-RIB marker, it MUST limit that delay to an upper bound. By default, a 60 second value should be used. ⏱️
7. Deployment Considerations 🌸
This mechanism reduces the scaling requirements imposed on route reflectors by limiting the number of VPN routes and events that a reflector has to process to the VPN routes used by its direct clients. By default, a reflector must scale in terms of the total number of VPN routes present on the network. 📉
It's also now possible to reduce the load on a given reflector by dividing the PE routers present on its cluster into a new set of clusters. This is a localized configuration change that need not affect any system outside this cluster. 🧩
The effectiveness of RT-based filtering depends on how sparse the VPN membership is. 🌿
The same policy mechanisms that apply to other NLRIs also apply to RT membership information. This gives a network operator the option of controlling which VPN routes get advertised in an inter-domain border by filtering the acceptable RT membership advertisements inbound. 🛂
For instance, in the inter-as case, it is likely that a given VPN is connected only to a subset of all participating ASes. The only current mechanism to limit the scope of VPN route flooding is manual filtering on the external BGP border routers. With the current proposal, such filtering can be performed according to the dynamic Route Target membership information. 🪄
In some inter-as deployments, not all RTs used for a given VPN have external significance. For example, a VPN can use a hub RT and a spoke RT internally to an autonomous-system. The spoke RT does not have meaning outside this AS, so it may be stripped at an external border router. The same policy rules that result in extended community filtering can be applied to RT membership information in order to avoid advertising an RT membership NLRI for the spoke-RT in the example above. 🌀
Throughout this document, we assume that autonomous-systems agree on an RT assignment convention. RT translation at the external border router boundary is considered a local implementation decision, as it should not affect inter-operability. 🤝
8. Security Considerations 🚨
This document does not alter the security properties of BGP-based VPNs. However, note that output route filters built from RT membership information NLRIs are not intended for security purposes.
Seriously, bestie, do not treat these filters as a security boundary. 💀 Output route filters built from RT membership information NLRIs are not intended for security purposes, so they are not a substitute for real protection.
When exchanging routing information between separate administrative domains, it is a good practice to filter all incoming and outgoing NLRIs by some other means in addition to RT membership information. Implementations SHOULD also provide means to filter RT membership information. 🛡️
9. Acknowledgements 🫶
This proposal is based on the extended community route filtering mechanism defined in [7]. 💜
Ahmed Guetari was instrumental in defining requirements for this proposal. 👑
The authors would also like to thank Yakov Rekhter, Dan Tappan, Dave Ward, John Scudder, and Jerry Ash for their comments and suggestions. 🌷
10. References 📚
10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, April 2006.
[3] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[4] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[5] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[6] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006.
10.2. Informative References 📚
okay so these are the bonus reads 💅 you don't need them to implement anything, but they give you the backstory. heads up that the "Work in Progress" ones were drafts when this was written, so they've probably moved on since 😭
- [7] Chen, E. and Y. Rekhter, "Cooperative Route Filtering Capability for BGP-4", Work in Progress, December 2004.
- [8] Sangli, S., Rekhter, Y., Fernando, R., Scudder, J., and E. Chen, "Graceful Restart Mechanism for BGP", Work in Progress, June 2004.
- [9] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service", Work in Progress, April 2005.
- [10] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, March 2005.
Authors' Addresses 🫶
the squad who made this happen, with their addresses and emails, all exactly as they were written 🎀
Pedro Marques
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
US
EMail: roque@juniper.net
Ronald Bonica
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
US
EMail: rbonica@juniper.net
Luyuan Fang
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, MA 01719
US
EMail: lufang@cisco.com
Luca Martini
Cisco Systems, Inc.
9155 East Nichols Avenue, Suite 400
Englewood, CO 80112
US
EMail: lmartini@cisco.com
Robert Raszuk
Cisco Systems, Inc.
170 West Tasman Dr
San Jose, CA 95134
US
EMail: rraszuk@cisco.com
Keyur Patel
Cisco Systems, Inc.
170 West Tasman Dr
San Jose, CA 95134
US
EMail: keyupate@cisco.com
Jim Guichard
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, MA 01719
US
EMail: jguichar@cisco.comFull Copyright Statement 🌈
the legal stuff, but make it cute 💅
Copyright (C) The IETF Trust (2006). The document is subject to the rights, licenses and restrictions in BCP 78, and apart from what's set out there, the authors keep all their rights.
the disclaimer below is the official legal wording, so it's copied word for word 🙈
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 doesn't say whether any patents or other rights apply to the tech in here, or whether you could get a license for them. it also hasn't checked for any of those rights itself 🫠 the rules about rights in RFCs live in BCP 78 and BCP 79.
IPR disclosures sent to the IETF Secretariat, plus any promised licenses or results from trying to get a general permission for implementers or users, are all in the IETF online IPR repository at http://www.ietf.org/ipr.
the IETF also invites anyone to flag copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard. send that to the IETF at ietf-ipr@ietf.org 💜
Acknowledgement 💖
the RFC Editor function is currently funded by the Internet Society, so a big thank you to them 🫶
📦 where this page comes from
- ietf: rfc4684 2006-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms