[c-nsp] Cisco Nexus as MetroE switch?

[Marian Ďurkovič]

On Mon, 2 Nov 2015 21:06:55 +0000, Tom Hill wrote
> But I do know that other vendors whom have had problems with egress
> link load-balancing for VPLS on Trident+, have also had the same
> issues with TRILL (Extreme X670V, in my case) and thus, struggle to
> suggest TRILL.

The reason for these issues was however completely different.

For the TRILL case, the whole problem was, that ASIC uses L2 headers by default.
Thus the fix was trivial - one ASIC register was set to non-default value and
the switch started to load-balance according to L3 & L4 headers in HW natively,
without any special provisions.

For MPLS/VPLS and SPB, tricky hacks with multiple MAC addresses and/or multiple
tunnels are the only solutions on Trident+, because of ASIC limitation.


> But in all honesty, I don't think TRILL suits the use-case of Metro-E
> aggregation - especially where E-LINE services are required (as per the
> OP). To a point, fine-grained Labels would provide an equivalent
> service separation to that of QinQ, but it isn't as segregated as the 'full'
> encapsulation of AToM, VPLS, or PBB/SPB-M, and FGL wasn't possible in
> Trident+ either (T2 only & above, I believe).

TRILL switch supports QinQ just fine. If the E-LINE customer wants to use 
its own VLAN tags, he will just send tagged packets to TRILL switch, which
will add a second tag and then encapsulate the frame into TRILL container. 

All you need to do is to configure customer-facing ports on TRILL switch as
dot1q-tunnel. 

As mentioned before, we’re using it in Bratislava MAN of academic network
without any problems (on Trident+)

On Mon, 2 Nov 2015 16:26:00 -0600, Chris Evans wrote
> I would avoid TRILL going forward IMHO.. Most vendors have abandoned future
> investment with it.  

OK, let’s take Cisco as an example. It indeed seems that their FabricPath
(proprietary TRILL implementation incompatible with RFC6325) is no
longer promoted and VXLAN+BGP is the new buzzword. But wait, multiple
posters mentioned here, that it’s even more complex than MPLS.
Is the ever-increasing complexity really something that customers want?

> Plus there are limitations with the Broadcom Trident
> asics where you can't decap & route natively (without doing some
> special packet looping to workaround this limitation)..

These limitations of Trident ASICs apply to all L2 encapsulations, i.e. TRILL,
VXLAN, SPB, VPLS… The problem is that Trident can’t preform L2 decapsulation
and L3 routing in a single pass, so packets need to be recirculated if both
functions are needed.

Anyway, for E-line services this is not relevant and Trident 2+ will remove all
these limitations AFAIK.

 With kind regards,

       M.