> I agree with Les. While you might get some flooding reduction out of > this, it wouldn’t be hard to better with a flooding next-neighbor > algorithm that was more well-thought (e.g., RFC 5614). Here are my > concerns:
We are trying to avoid the LLS work in OSPF ... In testing, this shows a dramatic decrease in the amount of flooding in 3 and 5 stage fabrics. Of course, this would also work for any random topology (even MANET networks), so it's not really limited to DC fabric use. > 1. It seems that while it is a distributed algorithm, the change of > flooding scope makes it somewhat quasi-centralized as you are making the > flooding decision for your neighbor. Perhaps, these parts of the > algorithm were developed with different Email addresses 😉 I switched off gmail ... which is probably a good thing. 😊 > 2. I don’t like the fact that IS-IS routers are changing the > flooding scope of an LSP that they didn’t originate themselves (Les’s > concern). This flooding scope modification could be removed but then > that would take away the novelty of the algorithm. This, it seems to me, is always going to be true of any flooding optimization -- unless you have the originator "mark" where each LSP "should go," something like a BIER bitfield embedded in the packet. This is true, btw, of the centralized flood reduction mechanisms I've seen, and is even true of 5614. > 3. The mechanisms for recovering from flooding failures is pretty > brute force…. A CNSP with every neighbor at sub-second intervals? Seems > this could negate much of what you are saving in flooding. It's not constant subsecond CSNPs, but rather a single additional CSNP. > 4. The way the document is written, the flooding decision is made > independently for every LSP. This seems unnecessary and it be per > neighbor (or even less granular) with no loss of optimization. I don't think it's implemented this way ... perhaps Shraddha can comment on how she implemented it. The FR/R implementation is not per LSP, either, AFAIK, but I can poke at the code again. 😊 /r _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
