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

[jimmi]

Folks.

I read these papers long time ago, so I do not remember anymore exactly what
this options labels (A, B, AB,...) definition means.

What I can tell you guys is that I operate a network which has a Inter-AS
peering were we exchange IPv4 & VPNv4 prefixes and traffic while  maintaining
QoS services compability at both sides (ASs) for long time, and customers
which VPNs have sites serviced by both ASs have their QoS requirements honored 
at both ASs Backbones and last mile connections. 

I already had real "Inter-AS + QoS compatibility" experience with Cisco being
the only platform, and where Cisco interoperate with (two) different vendors,
and that worked just fine. 

This deployment where you just had to establish a single eBGP peering at VPNv4
address-family to exchange VPNv4 prefixes and traffic (of course you may
exchange IPv4 also, and may establish redundant peerings) brings lots of
benefits. It does not impact at your ASBR resources, reduces the number of
connections between ASBRs & routing gets simplified, allows oversubscription
between ASBRs, does not require your to act at the borders (ASBRs) each time a 
"site" is added or removed from a customer VPN (despite where this site is
connected). 

[]s.

Jimmi.


---------- Original Message -----------
From: Mark Tinka <mtinka at globaltransit.net>
To: cisco-nsp at puck.nether.net
Sent: Sat, 7 Nov 2009 15:34:29 +0800
Subject: Re: [c-nsp] MPLS Multi-AS options...

> 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.
------- End of Original Message -------