Internal BGP as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)
updated by
Extracted elements (23)
A BGP/MPLS VPN is modeled as a provider-managed Internal BGP Route Server interconnecting customer sites. Routes learned by any PE are available to all other PEs importing the relevant Route Target, conceptually equivalent to a centralized route server with split-horizon to prevent loops.
External BGP PE-CE sessions require AS_PATH manipulation (AS remapping, loop suppression) that obscures the customer network topology. This document introduces iBGP PE-CE sessions with transparent carriage of customer BGP path attributes through the VPN core, eliminating the need for such workarounds.
NEXT_HOP is rewritten at the VRF import/export boundary rather than preserved, because customer and provider IGP metrics are incomparable. PE routers use the PE-PE IGP distance calculated by the customer network IGP when selecting between routes from different PEs, allowing independent per-site IGPs.
The Origin AS field in ATTR_SET is included specifically to prevent a route originating in one customer AS's iBGP from being silently leaked into a different AS without proper AS_PATH manipulation, enabling correct eBGP-like attribute construction when routes cross AS boundaries at VRF import.
ATTR_SET cannot include MP_REACH or MP_UNREACH attributes, limiting its use to IPv4 unicast path attributes that fit within a standard BGP UPDATE message. This constraint ensures compatibility with existing BGP UPDATE processing.
In all cases where a route containing ATTR_SET is imported, attributes present on the VPN route other than NEXT_HOP are ignored for both VRF route selection and CE advertisement; the ATTR_SET contents override VPN route attributes on vrf-import.
When interconnecting VRFs across a multi-AS VPN backbone using Inter-AS option b) or c) (RFC 4364 Section 10), provider networks can influence route attributes while presenting a transparent service to the customer AS. Option a) does not support full transparency because ASBR VRFs communicate via eBGP in the provider AS.
A CE-received route on a PE MUST be advertised to other VPN PEs that import the Route Targets associated with the route, regardless of whether the CE route was received as an external or internal BGP route.
For VRF route selection between routes from local CEs and remote PEs, customer network IGP metrics SHOULD always be considered higher (least preferred) than local site metrics, keeping provider-domain metric separation intact.
It is RECOMMENDED that different VRFs of the same VPN configured with iBGP PE-CE peering sessions use different Route Distinguisher (RD) values, to ensure the BGP/MPLS VPN infrastructure has access to the full per-path detail contained in ATTR_SET rather than selecting a single path per NLRI.
The AS_PATH and AGGREGATOR attributes contained within an ATTR_SET attribute MUST be encoded using 4-octet AS numbers per RFC 4893, regardless of the capabilities advertised by the BGP speaker receiving the ATTR_SET. BGP speakers supporting this document MUST also support RFC 4893.
The ATTR_SET attribute SHALL be considered malformed if its length is less than 4 octets, if the enclosed attributes include MP_REACH or MP_UNREACH, or if the included attributes are themselves malformed. A malformed ATTR_SET is treated as a route withdraw when the Partial flag is set and Neighbor-Complete is clear; otherwise Optional Attribute Error procedures of RFC 4271 MUST be followed.
The NEXT_HOP attribute SHOULD NOT be included in an ATTR_SET. When present, it SHOULD be ignored by the receiving PE. Future applications MAY define meaningful semantics for an included NEXT_HOP.
The Origin AS field in ATTR_SET SHOULD contain the autonomous-system number of the customer network originating the given set of attributes. It is encoded as a 32-bit unsigned integer in network byte order regardless of whether the originating PE supports 4-octet AS numbers.
When advertising a VRF route to an External BGP peer, a PE SHALL apply the AS mismatch attribute construction steps (discard iBGP attributes, prepend Origin AS, prepend VPN AS_PATH segment) and subsequently prepend its own AS number to AS_PATH.
When importing a route without ATTR_SET into a VRF configured in a different autonomous system, a PE MUST prepend the VPN provider AS number to AS_PATH.
When importing a VPN route containing ATTR_SET into a destination VRF, a PE MUST check that the Origin AS in ATTR_SET matches the AS associated with the VRF. On match, the route is imported with ATTR_SET attributes; on mismatch, the PE constructs new attributes by discarding iBGP-specific attributes (LOCAL_PREF, ORIGINATOR, CLUSTER_LIST) and prepending the Origin AS to AS_PATH per eBGP rules.
When the advertising PE performs a 'push' operation at vrf-export, it SHOULD initialize the attributes of the BGP IP VPN route advertisement as it would for a locally originated route from the respective VRF context.
ATTR_SET (BGP path attribute type code 128) is a new optional transitive BGP path attribute that carries a set of BGP path attributes. It is used by PE routers to push customer network BGP attributes into a stack at VRF export and pop them at VRF import, enabling transparent carriage of iBGP path attributes across the BGP/MPLS VPN core.
IANA has updated the BGP Path Attributes registry to assign type code 128 to the new ATTR_SET path attribute defined by this document.
From the VPN provider perspective, ATTR_SET improves security by enforcing separation between CE-advertised BGP attributes and provider network attributes. Without this mechanism, a CE can inject extended communities or other attributes with provider-network semantics unless explicitly filtered by PE configuration.
Implementations must apply input validation and resource management to the ATTR_SET attribute, as its content is derived from external (CE) systems. From the VPN customer perspective, the security profile is unchanged: the customer must still trust the service provider to deliver correct routing information, even though iBGP sessions allow additional attributes such as LOCAL_PREF.
ATTR_SET is encoded as: 1-octet Attr Flags (Optional|Transitive, code=128), 1 or 2 octet Attr Length (extended length bit determines size), 4-octet Origin AS (unsigned integer, network byte order), followed by variable-length BGP path attributes conforming to BGP UPDATE encoding rules. Total length is 4 plus the length of the enclosed attributes.