One of the most useful and popular application of MPLS technology is MPLS L3 VPN service. The architecture defines a VPN peer model in which customers send their routes to the SP in order to transport them to remote locations. In this model, the complexity of route transportation is offloaded by the customer to the SP offering the service.
When the customer has dispersed remote locations that want to interconnect and there is not a unique SP that has full coverage to be able to interconnect by its own resources that locations, some help may be needed by a third (or more) SPs.
The basic methods for chaining SPs together are defined in RFC 4364 as Inter-AS options A, B and C. This discussion covers basic aspects of Option A, with its main advantages, disadvantages and applicability.
Option A is the simplest of the interconnection options. The ASBR of each AS defines an interface or sub-interface per VRF. Once defined, the ASBR will instantiate the VRF assigning the sub-interface to the VPN. This need to be done per VPN requiring Inter-AS service.
The sub-interfaces facing the other AS doesn’t transport labeled traffic, only regular IP traffic. In order to exchange routing information with the remote ASBR, any routing protocol can be used.
From the ASBR point of view, the remote AS is seen like any other regular CE device.
In this case, the MPLS L3 VPN service is not extended, it’s simply chained. Each AS of the Inter-AS interconnection can select freely the IGP and label distribution protocol of their choice.
This solution works very well when the number of VPN and number of routes to transfer are small. Some of the Option A advantages are:
- Easy to understand, deploy and troubleshoot
- Clearly defined demarcation points between providers (SLA demarcation)
- Policing, filtering and accounting per-VPN over one single point (sub-interface VRF)
- Flexibility in the protocol selection per-AS and between ASBR
But, the real limitation of Option A is the scalability of the solution. The isolation of VRFs per VPN at the ASBR is accomplished by defining:
- One sub-interface per VRF
- One VRF per VPN (the VRF needs to be instantiated on the ASBR)
- One EBGP (if BGP is used) routing session per VRF
…and that has a HUGE impact on scalability as the number of VPNs to extend grows.
Control and Data planes
In order to keep things as simple as possible, the next figure illustrates the fundamental control and data plane operation for a route advertised by customer GREEN site CE5 (AS #65002) to site CE2 (AS #65001).
- The two MPLS L3 VPN services are chained together to provide end-to-end service
- Neither LSPs neither VPN labels used by the two SP need to be the same
- The link between ASBR transports regular IP traffic
- The extended communities must be removed in the BGP peering between ASBRs to avoid importing routing information in the wrong remote VRF (RT)
Inter-AS option A has some advantages that make this option very popular:
- Defines clear demarcation points between MPLS L3 VPN service providers
- Easy of deployment
But it has as well some disadvantages that may lead to consider using another option that better suits your needs:
- Poor scalability
- Hard to support enterprise QoS transparency
I hope you find it useful.