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]
