Re: [Lsr] Questions on draft-white-lsr-distoptflood

["Les Ginsberg (ginsberg)" <[e-mail]>]

Tony -

From: Tony Przygienda <[e-mail]>
Sent: Monday, November 28, 2022 10:06 AM
To: Les Ginsberg (ginsberg) <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: Re[2]: [Lsr] Questions on draft-white-lsr-distoptflood



On Mon, Nov 28, 2022 at 6:22 PM Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>> wrote:
Hi Russ!

> -----Original Message-----
> From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
> Sent: Monday, November 28, 2022 4:56 AM
> To: Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>>; Tony Przygienda
> <[e-mail]<mailto:[e-mail]>>
> Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
> 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
.