rfc-5195

BGP-Based Auto-Discovery for Layer-1 VPNs

H. Ould-Brahim, D. Fedyk, Y. Rekhter
date2008-06 streamIETF areartg wgl1vpn statusPROPOSED STANDARD pages10 canonicalhttps://www.rfc-editor.org/rfc/rfc5195 doi10.17487/RFC5195
The purpose of this document is to define a BGP-based auto-discovery mechanism for Layer-1 VPNs (L1VPNs). The auto-discovery mechanism for L1VPNs allows the provider network devices to dynamically discover the set of Provider Edges (PEs) having ports attached to Customer Edge (CE) members of the same VPN. That information is necessary for completing the signaling phase of L1VPN connections. One main objective of a L1VPN auto-discovery mechanism is to support the "single-end provisioning" model, where addition of a new port to a given L1VPN would involve configuration changes only on the PE that has this port and on the CE that is connected to the PE via this port. [STANDARDS-TRACK]

Extracted elements (16)

design-rationale §2

BGP is used as the auto-discovery protocol because it operates across multiple autonomous systems, enabling L1VPNs that span multiple ASes. Although multi-AS L1VPNs are out of scope for the Basic Mode, the mechanism is designed to be extensible to that scenario.

bgp, vpn, routing

design-rationale §5

The distribution rules ensure no single PE ever needs to maintain all routes for all L1VPNs, and no single route reflector is required to hold all VPN-related information. Route reflectors can be partitioned among VPNs, enabling the total network capacity to support VPNs without being limited by any single component.

bgp, vpn, routing

design-rationale §5

Unlike Internet BGP, the BGP system for L1VPN auto-discovery is amenable to partitioning: one may have any number of independent BGP systems each carrying only a subset of VPN-related information. This is a key scalability distinction from Internet routing.

bgp, vpn, routing

normative-requirement §5 MUST

A PE that has no VPN with an import Route Target matching received L1VPN information MUST discard that information, and MUST use inbound filtering to enforce this. This prevents PEs from retaining irrelevant VPN state.

bgp, vpn, routing

normative-requirement §5 MUST

When a new import Route Target is added to a PE's VPN ('VPN Join'), the PE MUST acquire previously discarded VPN-related information using the BGP route refresh mechanism defined in RFC 2918.

bgp, vpn, routing

normative-requirement §5 MAY

When a particular import Route Target is no longer present in any of a PE's VPNs ('VPN Prune'), the PE MAY discard all L1VPN BGP routes that no longer match any of its PIT import Route Targets.

bgp, vpn, routing

protocol-element §3

A new BGP Subsequent Address Family Identifier (SAFI) value 69 is defined, called 'Layer-1 VPN auto-discovery information', carried via the MP_REACH_NLRI and MP_UNREACH_NLRI attributes defined in RFC 4760.

bgp, vpn, registry

protocol-element §2

BGP Route Target Extended Communities are used for PIT route filtering. Each PIT is configured with 'export Route Targets' for tagging local information advertised into the provider BGP, and 'import Route Targets' that restrict which remote routes may be imported into the PIT.

bgp, vpn, routing

protocol-element §2

Each PE maintains a Port Information Table (PIT) per L1VPN containing a list of <CPI, PPI> tuples for all ports within that L1VPN. The CPI (customer port identifier) is unique within the L1VPN; the PPI (provider port identifier) is unique within the provider network. CPIs and PPIs may be either IPv4 or IPv6 addresses.

vpn, bgp, routing

protocol-element §3

If the Next Hop field length of the MP_REACH_NLRI attribute is 4, the Next Hop contains an IPv4 address; if 16, it contains an IPv6 address. This determines the address family of the PE's reachability information.

bgp, vpn, ip

protocol-element §4 MAY

The auto-discovery mechanism MAY carry Traffic Engineering information (such as switching capability and maximum LSP bandwidth of remote L1VPN interfaces) using the BGP Traffic Engineering Attribute, to support egress path selection.

bgp, vpn, routing

registry §7

SAFI value 69 ('Layer-1 VPN auto-discovery information') is assigned in the BGP Subsequent Address Family Identifier (SAFI) registry via the Standards Action allocation procedure.

registry, bgp, vpn

security-consideration §6 MUST NOT

It is critically important that a PE MUST NOT be discovered as attached to an L1VPN unless it is truly authorized to be attached. If arbitrary Internet nodes could inject BGP advertisements accepted by PE nodes, any site could be fraudulently added to any L1VPN. The mechanism presupposes that PEs trust their BGP peers to be correctly identified and properly authorized.

security, bgp, vpn

security-consideration §6 SHOULD

When a remote PE is a direct BGP peer of the local PE, the BGP authentication procedures of RFC 2385 (TCP MD5 Signature) SHOULD be used to verify the peer's identity.

security, bgp, vpn

security-consideration §6 MUST

When a remote PE is not a direct BGP peer, its information is relayed through a chain of BGP speakers. The trust relation MUST be transitive: each PE must trust its peers to only accept information from peers they themselves trust. BGP provides no mechanism to verify the original advertiser's authorization, so this mechanism MUST only be used in environments with adequate trust relationships (e.g., a single provider network).

security, bgp, vpn

wire-format §3

The BGP NLRI for L1VPN auto-discovery consists of a 1-octet Length field followed by a variable-length Auto-discovery info field encoding one or more <PPI, CPI> tuples. The encoding of the auto-discovery information itself is defined in the L1VPN Basic Mode specification.

bgp, vpn