Tony - From: Tony Przygienda <[email protected]> Sent: Monday, November 28, 2022 10:06 AM To: Les Ginsberg (ginsberg) <[email protected]> Cc: [email protected]; [email protected]; [email protected] Subject: Re: Re[2]: [Lsr] Questions on draft-white-lsr-distoptflood
On Mon, Nov 28, 2022 at 6:22 PM Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>> wrote: Hi Russ! > -----Original Message----- > From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> > Sent: Monday, November 28, 2022 4:56 AM > To: Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>>; > Tony Przygienda > <[email protected]<mailto:[email protected]>> > Cc: > [email protected]<mailto:[email protected]>; > [email protected]<mailto:[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 ;-) [LES:] What is needed is for you to request IANA to assign an algorithm identifier in the registry defined by https://www.ietf.org/archive/id/draft-ietf-lsr-dynamic-flooding-11.html#section-7.3 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) [LES:] If you want to discuss this, please start a separate thread. What I will say here is that dynamic-flooding is defining advertisements which are actually used by the protocol implementation. What was proposed in the context of MP-TLV is an advertisement which could not be used by the protocol – it was intended only as information for the operator. BIG DIFFERENCE!! Les --- tny .
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
