Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling
updated by
Extracted elements (27)
BGP Route Reflectors are used purely as a control plane technique for VPLS scaling; they introduce no data plane state or forwarding requirements on the RRs and do not change the forwarding path of VPLS traffic, in contrast to Hierarchical VPLS with LDP.
Label blocks allow a PE to send a single BGP Update containing demultiplexors for all remote PEs, rather than N individual messages. This reduces control plane load on originating PEs and on BGP Route Reflectors that distribute the updates.
No MAC addresses are exchanged via BGP; all MAC address learning and aging is done in the data plane individually by each PE. BGP VPLS message exchange is limited to auto-discovery and label exchange, making it relatively infrequent and scalable.
In multi-AS VPLS Method (b), ASBR label swap operations must be installed for each label in the label block: swap L2+n with L1+n and push tunnel label T, for n from 0 to N-1. ASBR2 may omit the tunnel label if directly connected to ASBR1.
RFC 4761 (BGP-based VPLS) and RFC 4762 (LDP-based VPLS) perform similar functions but are distinct and incompatible with one another; both are commonly referred to as 'VPLS'.
An implementation MUST maintain a separate routing storage for each service (VPLS and IP VPN), since the NLRI used for each service has different AFIs and SAFIs.
Any VPLS implementation that uses MPLS-in-IP or MPLS-in-GRE tunneling MUST implement IPsec as specified in RFC 4023. If IPsec is not used, the implementation MUST allow egress PEs to validate the IP source address of tunneled packets against a list of valid tunnel head addresses.
Control Flags bits designated MBZ (Must Be Zero) MUST be set to zero when sending and MUST be ignored when receiving the Layer2 Info Extended Community.
If a PE withdraws an NLRI for VE ID V that another PE X was using, then X MUST tear down its ends of the pseudowire between X and the withdrawing PE.
If a VE learns source MAC address S on port P and later sees S on a different port P', the VE MUST update its FIB to reflect the new port P'.
If PE-a's configuration is changed to remove VE ID V from VPLS foo, PE-a MUST withdraw all its BGP announcements for VPLS foo that contain VE ID V.
If PE-b's VE ID V is not part of any remote VE set that PE-b announced, PE-b MUST make a new BGP announcement covering VE ID V so that PE-a can set up its end of the pseudowire.
In Method (b) inter-AS VPLS, the Length, Route Distinguisher, VE ID, VE Block Offset, and VE Block Size in the redistributed VPLS NLRI MUST be the same as in the original; only the Label Base may differ.
Split horizon forwarding: a PE that receives a broadcast/unknown-destination frame from another PE MUST NOT forward it to other PEs; it MUST send copies only to its attached CEs.
Two PEs assigned the same VE ID in a VPLS MUST use the same Route Distinguisher, and SHOULD announce the same VE Block Size for a given VE Block Offset.
VPLS PEs SHOULD implement aging to remove stale MAC address entries from the FIB; if the age of a MAC address on a port exceeds aging time T, it MUST be flushed.
When a BGP speaker receives two equivalent VPLS NLRIs (same RD, VE ID, and VE Block Offset) for multi-homing, it MUST pick only one via standard BGP path selection criteria.
Auto-discovery uses BGP Route Target extended communities (RFC 4360) to identify VPLS membership. A PE announces membership in VPLS V by annotating its NLRIs with Route Target RT, and withdraws all such NLRIs to leave the VPLS.
Label blocks are the signaling primitive for VPLS pseudowire setup. A label block defined by <LB, VBO, VBS> represents labels {LB+VBO, LB+VBO+1, ..., LB+VBO+VBS-1}; each receiving PE computes its unique demultiplexor label by adding its VE ID to the label base.
VPLS BGP NLRI uses AFI=25 (L2VPN) and SAFI=65 (VPLS) and contains: Length (2 octets), Route Distinguisher (8 octets), VE ID (2 octets), VE Block Offset (2 octets), VE Block Size (2 octets), and Label Base (3 octets).
IANA allocated AFI value 25 for L2VPN information, shared with the BGP auto-discovery mechanism for VR-based Layer-3 VPNs. IANA also allocated extended community value 0x800A for the Layer2 Info Extended Community used to signal VPLS pseudowire capabilities.
Compromise of the BGP control plane can divert VPLS traffic to the wrong VPLS or blackhole it. TCP MD5 (RFC 2385) helps authenticate BGP messages; inter-AS BGP sessions between ASBRs, PEs, and Route Reflectors must also be protected in multi-AS deployments.
VPLS does not provide confidentiality, integrity, or authentication; packets are sent in the clear and are vulnerable to man-in-the-middle eavesdropping and injection. PE-to-PE IPsec tunnels or end-system encryption are recommended if security is required.
VPLS labels must be accepted only from valid interfaces: for a PE, links from P routers; for an ASBR, links from ASBRs in ASes that are part of the given VPLS. This is especially critical for multi-AS VPLS deployments.
PW Setup on receipt of a VPLS NLRI: (1) check if the receiving PE's VE ID W is in the advertiser's remote VE set; (2) if yes, compute demultiplexor label as LB+W-VBO and set up PW to advertiser; (3) check if advertiser's VE ID V is covered by any previously announced remote VE set; (4) if not, make a new BGP announcement; (5) set up expected ingress label for traffic from advertiser.
The Layer2 Info Extended Community encodes: Extended community type (2 octets), Encaps Type (1 octet), Control Flags (1 octet), Layer-2 MTU (2 octets), Reserved (2 octets). The Encaps Type for VPLS is 19; Control Flags bit C indicates control word requirement, bit S indicates sequenced delivery requirement.
The VPLS BGP NLRI wire format is: Length (2 octets), Route Distinguisher (8 octets), VE ID (2 octets), VE Block Offset (2 octets), VE Block Size (2 octets), Label Base (3 octets). Total minimum size is 19 octets plus the 2-octet length field.