On Mon, Nov 28, 2022 at 6:22 PM Les Ginsberg (ginsberg) <[email protected]> wrote:
> Hi Russ! > > > -----Original Message----- > > From: [email protected] <[email protected]> > > Sent: Monday, November 28, 2022 4:56 AM > > To: Les Ginsberg (ginsberg) <[email protected]>; Tony Przygienda > > <[email protected]> > > Cc: [email protected]; [email protected] > > 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. > Your point, now that you make it more clear, is fair and as I said, I'm against trying to figure out based on some indication of reduction/algorithm used and mismatches _what_ to do (i.e. procedures). I'm not against indicating that flood reduction is used, i.e. this draft sending a TLV (or maybe some variant of the TLV used in the dynamic-flooding draft which this draft could refer). A SHOULD seems fine here unless you argue eloquently why you think a MUST is needed ;-) So, yes, if your concern is to detect that _different_ algoirthms/drafts are used and alert the deployment of the problematic situation, I'm for it Footnote: I remain still baffled a bit that this is the same problem in my eyes we have in multi-TLV and there you argued the opposite (i.e. not sending indication) --- tny .
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
