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 in > https://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 > <https://www.ietf.org/archive/id/draft-prz-lsr-interop-flood-reduction-architecture-01.html#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]
