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.) This will help when folks look at the codepoint registry (in years to come) to intuit the difference. BTW, now that you have made this applicable to OSPF, you need to define codepoints for OSPFv2/v3 as well. 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]<mailto:[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]<mailto:[email protected]>> Sent: Thursday, November 27, 2025 7:16 AM To: Acee Lindem <[email protected]<mailto:[email protected]>> Cc: shraddha <[email protected]<mailto:[email protected]>>; lsr <[email protected]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[email protected]>> > > Sent: 28 April 2025 01:01 > > To: Acee Lindem <[email protected]<mailto:[email protected]>> > > Cc: Shraddha Hegde <[email protected]<mailto:[email protected]>>; lsr > > <[email protected]<mailto:[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]<mailto:[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]
