[c-nsp] Virtual CPE as a service on Metro-E last mile - Suggestions/inputs required

[Bill Wichers]

OK, I see what you're asking now. You probably do need more than just q-in-q
but it will depend on how big your deployment actually is. Q-in-q can scale
to reasonable sizes in metro deployments, you just need to know the
limitations and be careful. Q-in-q does allow for the use of very
inexpensive CPE equipment.

802.1ad does the "MAC hiding" you're talking about by defining different MAC
address spaces for the customer's interfaces and the service provider's
devices which is different than just stacking multiple tags with q-in-q.
AFAIK, you'll need to use much more capable CPE devices to support this.
Cisco's ME series switches support this, and while I haven't tried them
myself, I see many carriers using small Ciena switches for similar purposes

Unless you have a very large deployment with thousands of sites I don't
think you'll need to use 802.1ah. 802.1ad uses a 12 bit field -- the same
size as that used for VLAN tags -- to support about 4,000 bridge sessions,
each of which can be a separate customer network from the service provider's
perspective. 802.1ah does the same thing but with a 24 bit field to allow
for far more sessions.

My system isn't large enough to need more than 802.1ad, and we use MPLS
after that anyway.

I have a really excellent article about carrier Ethernet protocols around
here somewhere that I can send you if you want. Email me off-list if you're
interested and I'll try to find it.

  -Bill


> -----Original Message-----
> From: Aaron [mailto:aaron1 at gvtc.com]
> Sent: Thursday, May 21, 2015 3:02 PM
> To: 'Bill Wichers'; cisco-nsp at puck.nether.net
> Subject: RE: [c-nsp] Virtual CPE as a service on Metro-E last mile -
> Suggestions/inputs required
> 
> You mentioned ... " I'm thinking q-in-q is what you mean when you say "MAC
> in MAC". "
> 
> I've read that 802.1ah PBB (Provider Backbone Bridging) is actually a
> technology that allows for MAC Hiding to address scalability issues
created
> from a previous technology known as 802.1ad PB (Provider Bridging).
> 
> It seems that there is more to it than just simply stacking up a couple
tags.
> 
> Just because you stack up a few tags, I don't believe that you get mac
hiding.
> 
> I think, as I previously mentioned, that you have to implement something
> like PBB to hide macs.
> 
> Aaron
> 
> 
> 
> 
> -----Original Message-----
> From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of
> Bill Wichers
> Sent: Thursday, May 21, 2015 1:15 PM
> To: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] Virtual CPE as a service on Metro-E last mile -
> Suggestions/inputs required
> 
> We just run q-in-q from a relatively inexpensive CPE switch back to our
> nearest node. The advantage to this is that it's simple, and we can run
either
> over our own fiber or tunnel through other carrier's networks if needed
for
> type-2 circuits. If you're tunneling you need to make sure your carrier
> supports q-in-q and jumbo (or at least larger than normal frames) to
> accommodate the tags. You can also support your customer's VLAN tags by
> running q-in-q yourself, your encapsulated tags just get encapsulated
again
> with the carrier's q-in-q and the tags stack. The frames get bigger
though,
> which is why the upstream devices need to support larger than normal
> Ethernet frames. I'm thinking q-in-q is what you mean when you say "MAC in
> MAC". We've successfully used this for three "layers" of stacked tags (our
> carrier, then us, then our customer).
> 
> For our type-2 circuits that run over other carrier's metro-E networks, we
> usually run an open network with the carrier that lets us run our own tags
> anywhere we want. The downside is that this becomes an any-to-any
> network so you have to be careful with broadcasts as the network grows.
> The upside is that you can control the far-end locations your POP sees by
> running your own VLAN layout since each carrier interface is a trunk port
*at
> each site*.
> This is how we usually do it. If you have each far end site presented to
you as
> a VLAN tag by your carrier at your POP then you will have added complexity
> trying to run q-in-q yourself.
> 
> You can also run MPLS from the CPE device. This usually necessitates a
more
> complex, and thus more expensive, CPE switch, but it's more flexible and
less
> prone to broadcast issues.
> 
>   -Bill
> 
> 
> 
> > Hi Pros,
> >
> > Thinking of Virtual CPE as a service to enterprise customers where CPE
> > is virtualized in POP and low cost device in customer premises as a
> > simple bridge device which bridges the traffic to v-CPE in POP. This
> > is to have
> cost
> > advantage to customers and in POP, any different service can be easily
> > enabled as required by customer solution - firewall, routing, wan
> acceleration
> > etc.
> >
> > But the challenge is the backhaul from customer premise to our POP is
> > on Metro-E Layer 2 switched network. Hence the Layer 2 cannot be
> > extended on Metro-E which can cause significant ARP broadcast as the
> > gateway for customer LAN is in v-CPE in POP.
> >
> > Couple of queries:
> >
> > a. Is there a way to configure MAC-in-MAC between a bridge device in
> > customer premises and a MAC-in-MAC gateway till our POP, so that
> > Metro-E backhaul can only see outer MAC address? Can this option be
> > possible, If
> yes,
> > what would be cost advantage gained when the bridge device costing is
> low?
> >
> > b. Sure other providers would be doing this kind of solution, but how
> > do
> they
> > achieve this and overcome the challenges of LAN extension over shared
> > Metro-E L2 switched network.
> >
> > Thanks in advance,
> > Arun
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/