Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)
updates
- rfc-4364 — BGP/MPLS IP Virtual Private Networks (VPNs)
Extracted elements (23)
An alternative design using per-PE NLRIs of the form {originator-id, route-target} aggregated at the network edge was rejected because the adopted {origin-as#, route-target} approach requires less routing information within a given AS.
MP-BGP UPDATE messages were chosen to propagate RT membership information rather than extending the existing extended-community ORF encoding. This reuses BGP's existing machinery for loop-free dissemination—including route reflection, confederations, and inter-AS loop detection—both within and across autonomous systems.
The RT membership NLRI is structured as {origin-as#, route-target} rather than per-PE identifiers. Including the originating AS number provides uniqueness across ASes sourcing the same route-target and allows standard BGP path selection (AS-path length and policy) to prune duplicate paths in the RT membership flooding graph while maintaining reachability to all advertising ASes.
VPN NLRI routing information flows in the inverse direction of Route Target membership information advertisements, mirroring the BGP invariant that a valid forwarding path exists in the inverse direction of received routing updates.
RT translation at an external border router boundary is considered a local implementation decision and should not affect inter-operability. The document assumes that autonomous systems agree on an RT assignment convention.
The route reflection topology within an autonomous system must be configured such that IPv4 unicast routing works correctly (e.g., route reflection clusters must be contiguous) for the intra-AS RT membership procedures to function correctly.
This mechanism is applicable to any BGP NLRI that controls route distribution using Route Targets, such as VPLS, not only BGP/MPLS IP VPNs.
A BGP speaker MAY participate in RT membership information distribution without using the learned information to filter VPN NLRI output routes, although this is discouraged.
A BGP speaker that wishes to exchange Route Target membership information MUST use the Multiprotocol Extensions Capability Code (RFC 2858) to advertise the (AFI=1, SAFI=132) pair to its peers.
A VPN NLRI route should be advertised to a peer that participates in RT membership exchange if that peer has advertised either the default Route Target membership NLRI or an RT membership NLRI containing any of the targets in the VPN route's extended communities attribute.
If a BGP speaker delays advertising BGP VPN route updates until receipt of the End-of-RIB marker, it MUST limit that delay to an upper bound; the default value is 60 seconds.
Implementations SHOULD generate an End-of-RIB marker for the Route Target membership (AFI, SAFI) upon completing initial RT membership exchange, regardless of whether graceful-restart is enabled, allowing the receiver to know when it has received the full RT membership contents before exchanging VPN NLRI.
When a BGP speaker receives an UPDATE advertising or withdrawing a given RT 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, generating the minimum set of VPN route updates necessary to transition between the previous and current distribution graph state.
When advertising a locally sourced RT membership NLRI to a non-client iBGP peer, if the best path is received from a non-client peer but an alternative path from a client exists, the attributes of the client path shall be advertised. This allows a BGP speaker to signal its clients' interest in VPN routes for a given target.
When advertising an RT membership NLRI sourced by the local AS 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 to the local address for that session.
When processing RT membership NLRIs received from internal iBGP peers, a BGP speaker must consider all available iBGP paths for a given RT prefix when building its outbound route filter, not just the best path, to ensure every PE importing the route-target is reachable.
Route Target membership NLRI is advertised using MP_REACH_NLRI and MP_UNREACH_NLRI attributes with the (AFI=1, SAFI=132) value pair. This AFI/SAFI pair uniquely identifies RT membership information within the BGP UPDATE message.
The default route target is encoded as a zero-length prefix and signals willingness to receive all VPN route advertisements—for instance, a route reflector advertising to its PE router clients. Non-default route targets may be expressed as prefixes to encompass all RTs assigned by a given Global Administrator.
The Next Hop field of the MP_REACH_NLRI attribute for RT membership NLRI is interpreted as an IPv4 address when the NextHop length is 4 octets, and as an IPv6 address when the length is 16 octets.
This document uses SAFI value 132 for Route Target membership NLRI, used with AFI=1 (IPv4). This SAFI was assigned by IANA for constrained route distribution of RT membership information.
Implementations SHOULD provide means to filter RT membership information itself, in addition to any filtering applied to VPN NLRIs.
Output route filters built from RT membership information NLRIs are not intended for security purposes. When exchanging routing information between separate administrative domains, NLRIs should be filtered by additional means beyond RT membership information.
The RT membership NLRI is a prefix of 0 to 96 bits structured as: origin-as (4 octets) followed by route-target (8 octets), encoded as a BGP prefix per RFC 2858 Section 4. The minimum non-default prefix length is 32 bits, as the origin-as field cannot itself be interpreted as a prefix.