[c-nsp] MPLS Multi-AS options...

[Mark Tinka]

On Friday 06 November 2009 03:40:57 am Kenny Sallee wrote:

> I'm wondering if anyone is actually doing any flavor of
> Multi-AS backbone this in the real world?  Option A
> doesn't seem scalable at all.  Option B seems scalable,
> but the level of trust and lack of QoS may be a concern.
> Option AB - I'm trying to fully understand w/o a ton of
> lab time.  As I read the first Cisco link above, with
> Option AB - you must configure a sub-interface PER
> VPN/Client in it's own VRF on each SP's ASBR.  So if you
> have 100 different customers, on that interconnect
> between SP1 and SP2 you must configure 100
> sub-interfaces, VRF's with unique (agree'd upon)RD's.
> Then you configure a single MP-BGP session to carry the
> VPNv4 addresses for all VRF's.  So really you are only
> saving X number of BGP sessions with Option AB compared
> to say just Option A correct?

Yes, the difference between Option AB (a.k.a Option D) and 
Option A or Option B is that with Option AB, only a single 
eBGP session between the ASBR's is required. Furthermore, 
while forwarding can be based on MPLS, IP forwarding is also 
supported, which preserves QoS values that can be used for 
processing across the ASBR<=>ASBR link.

My suggestion; for any NNI option you choose, it should go a 
long way in making your life easy, i.e., you don't have 
create a sub-interface for each customer VPN, you don't have 
to create an eBGP session for each customer VPN.

While Option AB is in an IETF draft state, I only know of 
Cisco being the only vendor implementing it (there could be 
others, though - I haven't researched beyond the vendors we 
use in production). However, some of the other vendors are 
able to implement the methods Option AB uses to operate, but 
in such a manner that it may not necessarily be compatible 
to Cisco's, or if it is, implementing it may not be as 
scalable, requiring that a number of boxes in the end-to-end 
VPN connection be touched for co-ordination.

Personally, I think Option AB is rather complicated in its 
design, but based on Cisco's implementation, a lot of that 
complexity is hidden from the operators, with the routers 
doing all that automatically. It is an interesting option, 
but the need to configure a sub-interface for each VPN 
leaves a strange taste in my mouth.

One of the other vendors we're working with is able to 
implement Option B + IP processing, which is cool because we 
maintain a single interface for all VPN's, and a single eBGP 
session for all VPN's, without losing the ability to do QoS. 
Still checking with Cisco whether they can do this.

Things get a lot more interesting when you try to inter-op 
NNI relationships. If Cisco can't do Option B + IP 
processing, it may make sense for us to have both a Cisco 
and non-Cisco NNI router at each NNI site in order to have 
smooth NNI relationships depending on what platforms our 
partners can support. Of course, we can only support two 
platforms, so work becomes trickier if our NNI partner 
brings along an unsupported device - but, it won't be the 
end of the world :-).

Things get a lot more interesting if you want to NNI for 
l2vpn/VPLS services.

Cheers,

Mark.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20091107/c3b3e097/attachment.bin>