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]
