[c-nsp] MPLS down to the CPE

[Adam Vitkovsky]

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:philxor at gmail.com] 
Sent: Thursday, July 11, 2013 3:48 AM
To: Adam Vitkovsky; mark.tinka at seacom.mu
Cc: 'Andrew Miehs'; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] MPLS down to the CPE



On 7/10/13 4:16 AM, "Adam Vitkovsky" <adam.vitkovsky at swan.sk> 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
>