[c-nsp] LDPv6 Census Check

adamv0025 at netconsultings.com adamv0025 at netconsultings.com
Mon Jun 15 09:45:59 UTC 2020

> From: Saku Ytti <saku at ytti.fi>
> Sent: Monday, June 15, 2020 10:31 AM
> On Mon, 15 Jun 2020 at 12:24, <adamv0025 at netconsultings.com> wrote:
> > Yes this is where each node needs to have a label uniquely identifying
> > every LSP passing through it.
> > Saku,
> > With IP header you don't need this,
> > Consider this:
> > PE1 to PE2 via 3 P-core nodes
> > With ECMP in IP, then PE1 just needs single FEC the DST-IP of PE2,
> > which will be load-shared across all 3 paths.
> > Using MPLS If you need to uniquely identify each path you need 3 FECs
> > (3 LSPs one via each P core node), now imagine you have 100K possible
> > paths across the fabric  -that's a lot of FECs on PE1 or any node in
> > the fabric where each has to have a unique label for every possible
> > unique path via the core that the particular node is part of.
> Are we talking about specific implementations of fundamentals? It sounds
> like we are talking about a specific case where IP next-hop is unilist of N next-
> hops, and MPLS next-hop is a single item without indirection? This is not a
> fundamental difference, this is implementation detail.
> There is no particular reason MPLS next-hop couldn't be unilist of N
> destinations.
Yes it can indeed, and that's moving towards the centre between the extreme cases that David laid out.
It's about how granular one wants to be in identifying an end-to-end path between a pair of edge nodes.
I agree with you that MPLS is still better than IP, 
and I tried to illustrate that even enumerating every possible paths using deep label stack is not a problem (and even that can be alleviated using hierarchy of LSPs). 

More information about the NANOG mailing list