[c-nsp] LDPv6 Census Check

[Christian Meutes]

Salve,

On Thu, Jun 11, 2020 at 8:08 PM David Sinn <dsinn at dsinn.com> wrote:

Rewrites on MPLS is horrible from a memory perspective as maintaining the
> state and label transition to explore all possible discrete paths across
> the overall end-to-end path you are trying to take is hugely in-efficient.
> Applying circuit switching to a packet network was bad from the start. SR
> doesn't resolve that, as you are stuck with a global label problem and the
> associated lack of being able to engineer your paths, or a label stack
> problem on ingress that means you need a massive ASIC's and memories there.
>

I don't think rewrites are horrible, but just very flexible and this *can*
come up with a certain price. Irt to your memory argument that path
engineering takes in vanilla TE a lot of forwarding slots we should remind
us that this is not a design principle of MPLS. Discrete paths could also
be signalled in MPLS with shared link-labels so that you will end up with
the same big instructional headend packet as in SR. There are even
implementations offering this.

IP at least gives you rewrite sharing, so in a lite-core you have way
> better trade-off on resources, especially in a heavily ECMP'ed network.
> Such as one build of massive number of open small boxes vs. a small number
> of huge opaque ones. Pick your poison but saying one is inheriantly better
> then another in all cases is just plane false.
>

If I understand this argument correctly then it shouldn't be one because of
"rewrite sharing" being irrelevant for the addressability of single nodes
in a BGP network. Why a header lookup depth of 4B per label in engineered
and non-engineered paths should be a bad requisite for h/w designers of
modern networks is beyond me. In most MPLS networks (unengineered L3VPN)
you need to read less of headers than in a eg. VXLAN fabric to make ECMP
work (24B vs. 20B).