On Tue, 9 Jun 2020 at 02:22, Josh Hoppes <josh.hoppes@gmail.com> wrote:
Juniper Networks has also tried using Bloom filters.
https://patents.google.com/patent/US20170187624
I think the QFX10002 was the first product they made which used this approach.
https://forums.juniper.net/t5/Archive/Juniper-QFX10002-Technical-Overview/ba...
How they use it is not clear and it's not communicated in the article. Bloom filter of course only answers to you 'maybe' or 'no', which is not sufficient for egress rewrite information. The article also implies the bloom filter is in HMC, which I don't believe. I suspect roughly what is happening a) there are N bloom filters on-chip b) lookup is ran parallel to all N bloom filters c) bloom filters which give 'maybe' answer, cause lookup to off-chip HMC The naive approach would be 1 bloom filter per-netmask, so you have LEM only lookups in HMC, and on-chip tells which LEM lookups to do, to reduce LEM count from 32 to something rather less. But this surely isn't what they are doing, because the hash population is very different for /1 than it is to /24 and you want a reasonably fair balance, while guaranteeing LEM to off-chip. But I'm sure this is the gist of it, imprecise fast on-chip allowing LEM only off-chip. -- ++ytti