MPLS in the campus Network?

Mark Tinka mark.tinka at seacom.mu
Sat Oct 22 22:38:47 UTC 2016



On 22/Oct/16 23:59, Marian Ďurkovič wrote:

>
> The question here is, whether MPLS is the *optimal* solution for campus needs.
>
> The same functionality could be obviously achived by multiple technologies,
> and while MPLS is well supported on high-end SP routers, various limitations
> appear when people try to use it on commodity ASICs which typically empower
> today's ethernet switches - one of them being e.g. limited ability to
> effectively load-balance traffic over multiple parallel links.
>
> Yes, in theory we could build all campus LANs using high-end SP routers, but
> when 100GE backbone is desired (which is often the case in EDU/NREN sector), 
> the costs of such solution jump to unacceptable heights.
>
> Thus we looked for another technology, which doesn't have the usual L2 problems
> and is able to provide services we need (including L2 extensions to remote
> campuses) at reasonable costs and with enough simplicity. 
>
> To avoid typical L2 problems, you clearly need a solution based on L3 routing.
> And TRILL is exactly that - although it maintains L2 interface to the outside
> world, internally it performs dynamic L3 routing by IS-IS protocol with all
> safety belts like TTL check, RPF check etc. 
>
> IMHO, TRILL is much better fit for campus needs, since it was specifically
> designed for this networking space - and our 6-months production fully confirms
> that view (of course, YMMV).

I don't consider the ASR920 or CES2000 to be particularly high-end
routers, but YMMV.

True, merchant silicon presents a number of data plane challenges that
may, at first, seem non-trivial or completely go unnoticed. That is why
we stay away from the ACX5000, for example. I expect improvements to
come with newer-generation ASIC's/NP's, but that tests one's patience.

But, like I said, I have not run TRILL myself, so I'm not going to tell
you that it's not an ideal technology for this use-case. All I'll say is
that MPLS is not limited to high-end platforms, even when custom silicon
is involved.

Mark.



More information about the NANOG mailing list