Hi Russ! > -----Original Message----- > From: r...@riw.us <r...@riw.us> > Sent: Monday, November 28, 2022 4:56 AM > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; Tony Przygienda > <tonysi...@gmail.com> > Cc: draft-white-lsr-distoptflood.auth...@ietf.org; lsr@ietf.org > Subject: Re[2]: [Lsr] Questions on draft-white-lsr-distoptflood > > > >1)You can successfully deploy this algorithm in the presence of nodes > >which do NOT support this algorithm. But you cannot successfully deploy > >this algorithm in the presence of nodes which enable a different > >flooding reduction algorithm. > > This is correct. There seem to be two sides to this situation, however. > Some operators will likely not want to deploy > draft-ietf-lsr-dynamic-flooding to deploy flooding reduction because it > is "something else to break," or it interferes in some way with > incremental deployment. I'm sympathetic to this point of view, so I'm a > little skittish about making the signaling in dynamic-flooding a > MUST--but I'm perfectly happy to make it a MAY, or perhaps a SHOULD, if > folks think that is useful. > [LES:] The question I am raising is whether you think it is important to support a means of determining that one and only one flooding reduction algorithm is active at a given time. This would seem to be desirable and is what draft-ietf-lsr-dynamic-flooding provides.
If you, as a protocol vendor, want to provide a proprietary way of enabling draft-white-lsr-distoptflood and telling your customers "to be careful not to enable some other flooding reduction algorithm" that's out of scope for this discussion and for the draft. That's a matter between you and your customers. And you could still do that while also providing support for draft-ietf-lsr-dynamic-flooding. > >2)Regarding the use of PSNPs…you propose to send a PSNP (once > >apparently) which has the LSP entries for all the LSPs which you chose > >NOT to flood to a given node (minus any LSPs for which you may have > >received an explicit ack) in the most recent time interval - suggested > >to be one second. > Correct. This was intended as a compromise towards initial criticisms of > the mechanism that "flooding could fail, so there needs to be some way > to ensure no-one dropped anything." The original draft suggested a CSNP > one second after the partial flood, with a operator-configurable timer. > The original intent was not to disturb existing periodic CSNPs. PSNPs > are, however, lighter weight. > > >What then do these special PSNPs provide? It could be argued that they > >provide a lower cost and more targeted recovery mechanism in some > >circumstances – and that using them in conjunction with periodic CSNPs > >may speed convergence. However, I think the existing proposal discussed > >in Section 2.3 of the draft lacks detail and is unlikely to achieve > >this goal in most circumstances. > > In the initial stages of this work, I was fine leaving flooding > reliability to periodic CSNPs. Flooding failures are just what the > periodic CSNPs are supposed to account for. Flooding reduction might, in > some situations, increase the odds of a flooding failure occurring, but > it seems flooding failures are pretty rare, so the additional overhead > probably isn't needed. > > This really comes down to assessing the trade-off between ensuring > proper flooding as quickly as possible and the additional processing > overhead of the "quick check" PSNP/CSNP. I don't know if there is going > to be a "universal answer" for everyone (?). Some folks are going to be > more comfortable with some sort of "quick check," others are going to > see (as your analysis shows) that such a check isn't really needed. > > Suggestion--what if we changed this implementations MAY bring their > existing timer up so the next CSNP is sent more quickly, or > implementations MAY send a following PSNP. These should SHOULD be > operator configurable. I don't see that choosing any of these options > would impact interoperability between implementations, and it would give > different folks with different comfort levels options? > [LES:] Either your algorithm works or it doesn't. 😊 If it works (and I am not suggesting that it doesn't), then there should be no flooding unreliability/failures in normal operation. We are then left with prudence and an abundance of caution to ensure we can recover from transient events/implementation bugs. Periodic CSNPs should be sufficient. Optimizations in this area should be done with caution as you are optimizing for the unlikely cases and therefore need to ensure that the goodness such an optimization may provide is not outweighed by the cost. I see no need for additional mechanisms. But if you are going to propose them, please do more diligence both in analyzing when they are helpful and when they aren't and do a better job of explaining when/how they should be used. Les > :-) /r _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
