> On Jun 11, 2020, at 8:41 AM, Saku Ytti <[email protected]> wrote: > > On Thu, 11 Jun 2020 at 18:32, David Sinn <[email protected]> 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 _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
