> On Feb 25, 2022, at 9:38 AM, Toerless Eckert <t...@cs.fau.de> wrote: > > I just ran against control plane resource limitations in products way more > often during the decades than i felt necessary knowing what control plane > performane would be possible with appropriately scaled CPU/memory.
Well, here’s the problem: Internet usage is decoupled from all other applications. Data centers, even some of the hyperscalars, do not have the resource requirements of Internet routing. And yes, this exacerbated by the policies and practices of ISPs. It’s to the point where the resource and cost differential between ’normal’ products and ISP products have forked into two separate product variants. And even then, continuing to scale the ISP products is challenging. As a vendor, I should be happy about this: it all goes to better margins. However, as an engineer, I’m aghast. Most of this is waste. If we paid more attention to efficiency, we would be in a much better place. Unfortunately, efficiency is not sexy and cool. > Maybe its not as bad now as it was in the recent past given how > Moore's law is changing, but my past experience was that dedicated > route processor boards could not compete in price and life-cycle agility > with general purpose data-center servers, but for Internet BGP, there > is IMHO no reason (other than desires for revenue), to NOT use general > purpose data center servers for Internet BGP routing tables. The volumes are ten orders of magnitude lower, so that’s no surprise. And just having routing without direct coupling to a forwarding plane restricts you to off-box applications, which is missing a key part of the problem. But while this is interesting, it is also irrelevant to the matter at hand: we can be more efficient in our routing if we want to. > If some of this is happening but in your opinion not a rational response > that would make it important IMHO to be dicussed in the document. The point is to make routing more efficient, not to talk about FIB compression mechanisms. > Or > at least add references to wherever this may already be discussed. Without > quantified numbers published to show how this does or does not help, > we can just believe or not believe your assessment. I’m not asking you to believe anything. I’m simply pointing out the capabilities that are available today for anyone to employ should they so choose. >> Actually doing the aggregation in the control plane is far preferable: it >> reduces processing and memory requirements for all upstream systems. > > The more aggregation you want to support, the more geographic structure > you introduce into the addressing space and the more you will also > run the risk of creating detriments against cross-geographic > shortcut links (oh no, a peering with you would raise the cost of > my routing table undesirably...). Aka we're trying to compare > capex cost for potentially overpriced CPU/RAM in routers with the > cost of operational processes in registries and operators. Thats > a difficult comparison. And I’m not trying to force anyone one way or another. I’m simply documenting the tool. > Hmm. Then i misread your draft. It did sound as if there is an ask > in your document against registries to improve how they assign address > block such that better geographic aggregation than today was enabled. Only for geographic addressing that is not already covered by per-registry block allocation. Largely, that means allocating blocks to Australia. :) >> That is simply not true. /8 is not somehow less optimal than /16. It depends >> on the topology, not the prefix length. > > The shorter the prefix length of an aggregate, the more longer aggregates it > could have, right ? That’s irrelevant. We are not concerned with potential downsides. The question is how can we improve efficiency. > In general we would not want a longer prefix because we want the aggregation > (with your proposal). We do not want to carry longer prefixes when they point to the same next hops. They add no value. And unfortunately, they are all too common. How about we stop carrying them? > So now _if_ someone wants a longer perfix to go > on path where it would violate the aggregation, we call it traffic > engineering. > But whats the operational mechanism by which one would decide this is > a permitted instance of traffic engineering or a bug / misconfiguration > in the aggregation scheme ? First off, this is not about defining laws or rules. This is not about ‘permitted’ or ‘bugs’. The point is that a single operator can look and see that all of the next hops of a prefix and its more specifics are aligned. That operator can then choose to aggregate. It’s that simple. Yes, traffic flow may be affected. The operator needs to decide whether or not that is problematic for them. Tony _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
