I see so the islands are stitched together over the CsC L3VPN, since all islands have the same AS together they act like a common AS. And the CsC L3VPN is provided by the underlying common backbone Inter-AS-MPLS optC style. Right?
So all access nodes within a particular island have RSVP-TE tunnels to ABRs/ASBRs within the island (ASBRs than provide connectivity to other islands). And there's a full mesh of tunnels between all ASBRs. Right? I'd like to ask is there a full mesh of iBGP sessions between the ASBRs or some of the ASBRs have a role of RRs please? So you have decided to create this sort of overlay AS dedicated for L2 services. I think I understand your reasoning behind the setup and must say it's very bold and creative. See this is what I was talking about before, back in the old days engineers would have to get very creative and bold to create something extraordinary with such a limited set of features. With today's boxes you could all stack it up into a single AS not ever worrying about scalability or convergence times. Thank you very much for sharing the design with us adam -----Original Message----- From: Phil Bedard [mailto:[email protected]] Sent: Thursday, July 11, 2013 3:48 AM To: Adam Vitkovsky; [email protected] Cc: 'Andrew Miehs'; [email protected] Subject: Re: [c-nsp] MPLS down to the CPE On 7/10/13 4:16 AM, "Adam Vitkovsky" <[email protected]> wrote: >> the different network islands are tied together using CsC over a >> common MPLS core. >You got me scared for a moment CsC would mean to run a separate >OSPF/LDP/BGP-ASN for each area and doing MP-eBGP between ASBRs within >each >area(OptB) or between RRs in each area(optC) with core area/AS acting >as a labeled relay for ASBRs loopback addresses, though I believe by >common MPLS core you mean a single AS right please? The islands are actually all in the same ASN, the common core is not the same ASN. Could have been the same ASN, more political reasons for it not being the same than technical. In the end it looks like Option C, the CsC L3VPN only carries loopbacks and aggregate IP prefixes. The common core is RSVP-TE based, if I had my preference today I would build TE tunnels across it between the islands and then use RFC3107 as a way to tie it all together end to end. Years ago when we first built it some of the feature support wasn't there to do that. > >> 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. >I see, right that's a clever way to save some money by pushing the >L3VPN stuff to only a few powerful boxes with high-queue line cards and >L3VPN licenses. Though the PWHE -a setup where you can actually >terminate the PW into L3 interface on the same box was introduced to >Cisco boxes only recently so prior to that you'd have to have a >separate box bridging the PW to sub-int/serv-inst on a QinQ trunk where >the L3VPN box would be connected to. > >I'm still confused about the TE part. >So I believe you are pushing PW directly into TE tunnels what gives you >the ability to balance the PWs around the ring as well as to use a >backup tunnel via the opposite leg of the circuit. So the TE tunnels >are actually terminated on the PWHE nodes right? Or do they actually >continue into the backbone area please? The tunnels from the access boxes terminate on the PWHE nodes, they do not extend beyond that boundary. There is another set of tunnels which connect the PWHE nodes together. This isn't a one-off deployment or anything, there are other folks out there with basically the same type of deployment. Phil > > >adam > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
