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.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
