All, > On Dec 9, 2025, at 11:04 PM, Les Ginsberg (ginsberg) <[email protected]> > wrote: > > Tony – > <snip> > I have suggested “Flooding Algorithm Leaderless Mode” – but if you have a > different preference, I would be happy to consider it. > ok, what about "Active flood reduction algorithm" ? <end snip>
The latter sounds good to me. Thanks, Acee > Sure. > Les > From: Tony Przygienda <[email protected]> > Sent: Tuesday, December 9, 2025 11:56 AM > To: Les Ginsberg (ginsberg) <[email protected]> > Cc: Acee Lindem <[email protected]>; shraddha <[email protected]>; lsr > <[email protected]> > Subject: Re: [Lsr] Re: WG Adoption IPR Poll for "Flooding Reduction > Algorithms Framework" - draft-prz-lsr-interop-flood-reduction-architecture-01 > On Tue, Dec 9, 2025 at 1:02 AM Les Ginsberg (ginsberg) > <[email protected]> wrote: > Tony – > Thanx for the reply. > My request here is simple. > We now have two sub-TLVs of the Router Capability TV – both of which > advertise supported flooding algorithm(s). > But as used they have different semantics. > The existing sub-TLV defined by RFC 9667 advertises a (set of) supported > flooding algorithms which can potentially be used by the area leader when > choosing what algorithm to enable (distributed mode). It is named “IS-IS > Dynamic Flooding”. > The new sub-TLV advertises a single algorithm which indicates what the > advertising node has actually enabled. It currently does not have a name – > but IANA will require one. > I am simply asking that you choose a string which allows for an intuitive > recognition of the difference between the two sub-TLVs. > I have suggested “Flooding Algorithm Leaderless Mode” – but if you have a > different preference, I would be happy to consider it. > ok, what about "Active flood reduction algorithm" ? > Although there will be a clear reference in the IANA registry to the > document which defines the sub-TLV, it seems helpful to choose a name which > facilitates the reader being able to recall the functional difference between > the two sub-TLVs w/o having to go reread(sic) the relevant documents. > I am not asking or suggesting that the draft should discuss how leader > based(RFC 9667) and leaderless based flooding can coexist. > I agree this is possible, but I see no reason why the > flood-reduction-architecture draft needs to discuss it. As you have pointed > out, we agreed that was out of scope for the draft – and I still think that > it is the correct choice. > ok > As for OSPF codepoints, I mentioned that as a simple review comment. > ok > Hope we are in sync now. > Les > From: Tony Przygienda <[email protected]> > Sent: Monday, December 8, 2025 12:34 AM > To: Les Ginsberg (ginsberg) <[email protected]> > Cc: Acee Lindem <[email protected]>; shraddha <[email protected]>; lsr > <[email protected]> > Subject: Re: [Lsr] Re: WG Adoption IPR Poll for "Flooding Reduction > Algorithms Framework" - draft-prz-lsr-interop-flood-reduction-architecture-01 > Les, inline ... > On Sun, Dec 7, 2025 at 6:36 PM Les Ginsberg (ginsberg) <[email protected]> > wrote: > Tony – > My bad – you are right. Apologies. > The new signaling is needed. > The reason the new signaling is needed is because what is defined in this > document is a leaderless deployment whereas RFC 9667 defines a leader-based > deployment. > I forgot about this (which had been discussed along the way). > I am wondering if a name could be assigned to the new sub-TLV to make it > easier to identify the difference between it and the existing sub-TLV defined > by RFC 9667? > Perhaps “Flooding Algorithm Leaderless Mode” ?? > (Open to other suggestions.) > actually this architecture and signalling works fine for leaderless _and_ > leader based. Imagine two components X and Y both running different leader > based algorithms. Perfectly fine stuff. > X can signal something specific to X saying "here we are in a partition > \alpha and if you're in partition \alpha there is a leader that says > 'everyone in X runs X now'". Y can > do the same stuff as \beta using the same algorithm or even with a different > one. > As long everyone in both components indicates via this signalling (as they > must) that they run _an algorithm_ so all components can compare and follow > the framework then leader, no leader or even astral ascendancy determining > what all nodes in a component do is a private matter. > This will help when folks look at the codepoint registry (in years to come) > to intuit the difference. > As you know I thought mashing the things together in the 9667 registry was > never a particularly good idea since it's not necessary (registries are > cheaper than cheap to create) and only leads to a ball of yarn and then > "intuiting the difference" means that we start to introduce some funny stuff > because things that have different semantics are being mixed together. > Especially since, AFAIR on your suggestion the draft now also says > " > Dealing with interoperability or lack thereof between this framework > and other published frameworks such as e.g. [RFC9667] is explicitly > outside the scope of this document. > " > Though ultimately your comment/suggestion of moving the signalling from > disttopo to -arch draft was spot on ... > BTW, now that you have made this applicable to OSPF, you need to define > codepoints for OSPFv2/v3 as well. > yes. Acee I think prefers another document for OSPF. I'm not religious > either way and see what falls out. Rather trivial addition AFAIS. > --- tony > Les > From: Tony Przygienda <[email protected]> > Sent: Friday, December 5, 2025 11:18 PM > To: Les Ginsberg (ginsberg) <[email protected]> > Cc: Acee Lindem <[email protected]>; shraddha <[email protected]>; lsr > <[email protected]> > Subject: Re: [Lsr] Re: WG Adoption IPR Poll for "Flooding Reduction > Algorithms Framework" - draft-prz-lsr-interop-flood-reduction-architecture-01 > On Tue, Dec 2, 2025 at 1:06 AM Les Ginsberg (ginsberg) > <[email protected]> wrote: > Tony – > I agree with you that this is applicable to OSPF as well. > good > Related to that, I just noticed that in the new IETF version of this draft > you introduced new signaling > inhttps://www.ietf.org/archive/id/draft-ietf-lsr-isis-flood-reduction-arch-00.html#name-signaling > defining a new sub-TLV in Router Capability TLV. > The signalling is not new and nothing has been "introduced" here. All of > > https://www.ietf.org/archive/id/draft-lsr-interop-flood-reduction-architecture-00.txt > https://datatracker.ietf.org/doc/draft-prz-lsr-interop-flood-reduction-architecture/00/ > https://www.ietf.org/archive/id/draft-prz-lsr-interop-flood-reduction-architecture-01.html > (on which this call is extended!) > contain it already. > But this is not necessary. You should be able to use the signaling already > defined in RFC 9667: > https://www.rfc-editor.org/rfc/rfc9667.html#name-is-is-dynamic-flooding-sub- > RFC 9667 also defines signaling for OSPF – so you will be covered in this > regard when you expand the scope of the draft to both protocols. > It is absolutely and perfectly necessary and the argument has been made > previously AFAIR. I repeat them to keep the list straight. > RFC9667 TLV is simply unfit for the purpose. It says > "Indicate that it supports dynamic flooding. This is indicated by the > advertisement of this sub-TLV. > Indicate the set of algorithms that it supports." > The TLV necessary for > https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-flood-reduction-arch/ > has totally different semantics, it indicates the algorithm that is _actively > running_ on the node and it can announce _one and only one_. > Additionally, RFC9667 TLV lacks any normative language as to mandating its > advertisement. > https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-flood-reduction-arch/ > clearly says that such a TLV MUST be announced for things to work properly > "The Sub-TLV MUST be advertised by a node that is actively running any pruner > except a zero-pruner." > Ultimately, I think based on your comment/requirement the draft specifically > ended up saying > "Dealing with interoperability or lack thereof between this framework and > other published frameworks such as e.g. [RFC9667] is explicitly outside the > scope of this document." > and hence intertwining the stuff with 9667 given its differing and > underspecified semantics makes zero sense overall. > --- tony > Les > From: Tony Przygienda <[email protected]> > Sent: Thursday, November 27, 2025 7:16 AM > To: Acee Lindem <[email protected]> > Cc: shraddha <[email protected]>; lsr <[email protected]> > Subject: [Lsr] Re: WG Adoption IPR Poll for "Flooding Reduction Algorithms > Framework" - draft-prz-lsr-interop-flood-reduction-architecture-01 > back from some days off and starting to track down all the > comments/updating. Wouldn't it be more natural to leave out the -isis- out > here, this stuff applies to ospf or anything in LSR space really w/o being > specific ? > And I'll knuckle down and do some !primitive! ascii figures ;-) > -- tony > On Wed, Jun 4, 2025 at 1:38 PM Acee Lindem <[email protected]> wrote: > Hi Tony, > > Sounds good. Can you republish the document as > draft-ietf-lsr-isis-flood-reduction-arch-00.txt? > > Thanks, > Acee > > > On Jun 4, 2025, at 4:24 AM, Tony Przygienda <[email protected]> wrote: > > > > No sorry, it took us a bit internally to finally push out the disclosure > > that's why the thread was hanging > > > > I read the threads/comments and see no need to update > > -flood-reduction-architecture- right now AFAIS. The comment you had on the > > lack of ASCII figure is correct but that's work once adopted. I'm still > > open to better terms/language but that's probably best over a beer in > > madrid > > > > on the other hand, dist topo will be rev'ed once more before IETF mostly > > based on implementation/testing experience > > > > thanks > > > > -- tony > > > > On Tue, Jun 3, 2025 at 5:41 PM Acee Lindem <[email protected]> wrote: > > Thanks Tony - Sorry, we had so much "noise" on the LSR list related to LSR > > drafts in WG last call that I neglected to complete the adoption call. > > > > Are you ready for adoption of the current version or were you going to make > > some modifications based not the comments? > > > > Thanks, > > Acee > > > > > On Jun 3, 2025, at 11:18 AM, Tony Przygienda <[email protected]> wrote: > > > > > > Acee, all the relevant IPR I am aware of has been disclosed now > > > > > > thanks > > > > > > -- tony > > > > > > > > > On Mon, Apr 28, 2025 at 8:02 AM Shraddha Hegde <[email protected]> > > > wrote: > > > Juniper is in the process of declaring IPR. > > > I am not aware of any other IPR related to this draft. > > > Rgds > > > Shraddha > > > > > > Juniper Business Use Only > > > From: Tony Przygienda <[email protected]> > > > Sent: 28 April 2025 01:01 > > > To: Acee Lindem <[email protected]> > > > Cc: Shraddha Hegde <[email protected]>; lsr <[email protected]> > > > Subject: Re: WG Adoption IPR Poll for "Flooding Reduction Algorithms > > > Framework" - draft-prz-lsr-interop-flood-reduction-architecture-01 > > > [External Email. Be cautious of content] > > > we are in the process of disclosing the IPR. thanks. tony On Sun, Apr > > > 27, 2025 at 4:40 PM Acee Lindem <[email protected]> wrote: > > > Co-Authors, > > > > > > Are you aware of any IPR that applies to > > > draft-prz-lsr-interop-flood-reduction-architecture-01? > > > > > > If so, has this IPR been disclosed in compliance with IETF IPR rules > > > (see RFCs 3979, 4879, 3669 and 5378 for more details). > > > > > > There currently aren’t any IPR declarations on this simple protocol > > > extension - > > > https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-chen-lsr-prefix-extended-flags > > > > > > If you are listed as a document author or contributor please respond > > > to this email regardless of whether or not you are aware of any > > > relevant IPR. *The response needs to be sent to the LSR WG mailing > > > list.* The document will not advance to the next stage until a > > > response has been received from each author and contributor. > > > > > > If you are on the LSR WG email list but are not listed as an author or > > > contributor, then please explicitly respond only if you are aware of > > > any IPR that has not yet been disclosed in conformance with IETF rules. > > > > > > There currently aren’t any IPR declarations on this draft: > > > > > > https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-prz-lsr-interop-flood-reduction-architecture > > > > > > Thanks, > > > Acee > > _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
