On 7/10/13 6:14 AM, "Mark Tinka" <[email protected]> wrote:
>On Tuesday, July 09, 2013 07:02:56 PM Phil Bedard wrote: > >> In our case we are using separate OSPF areas for the >> access elements, IS-IS wasn't supported when we started >> doing the deployments. Depending on scale sometimes an >> entire agg location may use the same subtending area, >> sometimes there are more than one, sometimes an area per >> access ring. The agg/core nodes of each local network >> sits in OSPF Area 0, and the different network islands >> are tied together using CsC over a common MPLS core. > >That sounds hectic, Phil, but I guess it is better than >virtual links :-). Like I told Adam, it's basically Inter-AS Option C but it's contained within a L3VPN on the carrier side. It's not really all that complicated. > >> I've never liked the >> idea of doing inter-as RSVP-TE except in unique >> situations, I'd rather use areas/levels and hierarchy >> than a stateful session across boundaries. > >You're forced to do this when things like p2mp RSVP-TE don't >support inter-area LSP's. > >As always, things will improve to break restrictions, over >time. >Two. >> At the ABR >> all of the L2VPN services are "stitched" since you are >> entering a different RSVP-TE/MPLS domain, the L3VPN >> configuration exists on these nodes with the access >> nodes using L2 pseudowires into virtual L3 interfaces. >> Cisco talks about a similar architecture in their >> "Unified MPLS for Mobile" presentation from the last >> Cisco Live. Cisco has always called these ABR/agg nodes >> the "PWHE" or pseudowire headend since they aggregate a >> large number of pseudowires. >> >> Long-term there are various options to eliminate the >> stitching and associated configuration, although we've >> got it pretty automated at this point. > >I will concede that your setup is very, very kinky, but if >you have it all automated with fluff, then I suppose that is >okay :-). It's not really all that complicated once you get used to how things are provisioned for a multi-segment pseudowire. For an end to end service you have configuration on six boxes instead of two if it crosses boundaries and is built redundantly. With templates it's all automated and the config on the "stitching" boxes is about four lines. It also gives you another point to perform OAM functions along the service path. There is a draft ready to become an RFC on dynamic multi-segment pseudowires, it's been kicking around for a long long time now and ALU recently implemented it on their larger boxes. However it's complicated and tantamount to running another routing protocol... In the end I think most would rather segment the underlying MPLS transport path than the service itself. I'd really like to see EVPN implemented everywhere, but I worry about BGP scale again as an end to end solution. >Cheers, > >Mark. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
