[c-nsp] LDPv6 Census Check

Thu Jun 11 10:15:16 UTC 2020

On 11/Jun/20 11:57, Robert Raszuk wrote:

>
> Nope that was not the main reason. 
>
> Main reason was the belief that labels MUST be locally significant -
> and not domain wide unique. Just look at Juniper's SRm6 or now SRH ...
> they keep this notion of locally significant SIDs. It is deep in their
> DNA ... still. 
>
> We argued about it a lot in cisco back in TDP days - and we lost.

I get this for VLAN's, being only 4,096 per broadcast domain and all.

But are we struggling with scaling label space?

Just my 1+1, since I may be over-simplifying the issue.

>
> - - -
>
> Now to your runt that MPLS is great because of exact match perhaps you
> missed it but number of solutions on the table (including RbR[**] I
> recently proposed) use exact match 4B locator based lookup in the v6
> packets to get from segment end to segment end. 
>
> On the other hand your comments about greatness of MPLS ... simplified
> data plane and depending on the hardware difference in jitter (in sub
> ms ranges - if that even matters) comes up with a lot of control plane
> complexity when you want to build a network across all continents, yet
> keep it scoped from IGP to areas or levels. No summarization in MPLS
> in FECs is something we should not sweep under the carpet.

I found multi-level IS-IS to be useless in an MPLS network because you
still need to leak routes between L2 and L1 in order to form MPLS FEC's.
So you simplify the network by having a single L2 (or just Area 0 in
OSPF), because today's control planes can handle it. And yes, some are
brave enough to run RFC 3107 if it becomes a problem, but if you can
afford to string a network together across all continents, I doubt an
x86-based control plane with 64GB of RAM is topping the list of your
problems.

Mark.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20200611/3ab522ac/attachment.html>