[c-nsp] LDPv6 Census Check

[David Sinn]

> On Jun 11, 2020, at 8:41 AM, Saku Ytti <saku at ytti.fi> wrote:
> 
> On Thu, 11 Jun 2020 at 18:32, David Sinn <dsinn at dsinn.com> wrote:
> 
>> However if you move away from large multi-chip systems, which hide internal links which can only be debugged and monitored if you know the the obscure, often different ways in which they are partially exposed to the operator, and to a system of fixed form-factor, single chip systems, labels fall apart at scale with high ECMP. Needing to enumerate every possible path within the network or having to have a super-deep label stack removes all of the perceived benefits of cheap and simple. The arguments about IP lookups being slow is one best left to the 1990's when it was true. Fixed pipeline systems have proven this to be false.
> 
> It continues to be very much true. IP lookups require external memory,
> which takes SERDES, which could be used for revenue otherwise. IP
> lookups are slow, expensive and complex, fundamentally, no amount of
> advancement will change this fundamental nature.
> Sure we can come up with all kind of implementations which bridge the
> gap, but the gap is there.

But now you are comparing apples and oranges. You're asserting that all IP lookups require external memory. But your talking about comparing a lite-core to a heavy-core. As I said, it depend on deployments. If you have a lite-IP core you don't need external memories. So there isn't a lag question going out to massive memories needed for 2M+ entires. So it is not always that lookups are slow, expensive, complex. Sure, you can build a network around a heavy core but you can also build one without. Sweeping generalizations that MPLS is always better than all other technologies is just that, a sweeping generalization. It misses a ton of points.

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.

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 we take say JNPR MX, your lookup speed isn't limited by the
> instruction count on the PPE, the PPE spends most of its time
> sleeping, when the platform is fully PPS congested, the PPE is waiting
> for the memory to return!

You've made my point for me. If you are building the core of your network out of MX's, to turn a phrase, in a past life "I fully support my competitors to do so". Large numbers of small boxes, as they have already shown in the data-center, have major cost, control and operational advantages over a small number of large ones. They also expose the inherent problems of label-switching and where IP has it's merits.

David

> 
> -- 
>  ++ytti