[Lsr] Re: New Version Notification for draft-ginsberg-lsr-hello-capability-00.txt

[Tony Przygienda]

I have no particular opinion on that, and as far as I see we can define ash as working on both levels always if present. But I fear we’ll end up in the future with something, the negotiation of a capability per level will become a real ask Having a level specific TLV will need definition of how to treat a TLV that is not supposed to be at an IIH at this level. But that’s doable for sure Sent from my iPad On Sep 22, 2026, at 07:39, Les Ginsberg (ginsberg) <ginsb...@cisco.com> wrote:  Folks –   If it is needed to signal a per level capability, there are two ways this can be done:   1)Define two bits – one for each level   2)(somewhat less efficiently) Use a sub-TLV and include level in the encoding   As the capability draft is simply defining the generic container, we can’t specify exactly what should be used in a specific case – but we can add a discussion as to how this can be addressed. Will add that to the next revision.   For the ASH example, I will leave it to the draft authors to decide whether a per level indication is needed or not – but retain my right as a WG member to comment on their decision. 😊 It would seem odd to me that an implementation would only implement the support for one level – but…      Les     From: Tony Przygienda <tonysi...@gmail.com> Sent: Friday, September 18, 2026 2:10 PM To: Acee Lindem <acee.i...@gmail.com> Cc: Les Ginsberg <ginsberg=40cisco....@dmarc.ietf.org>; lsr <lsr@ietf.org> Subject: [Lsr] Re: New Version Notification for draft-ginsberg-lsr-hello-capability-00.txt   we could but it won't express the full semantics we may want here. if the adjacency shows L1/L2 but we want to say specifically let's say ASH works only in L1 we cannot do that on P2P right now.    -- tony    On Fri, Sep 18, 2026 at 2:06 PM Acee Lindem <acee.i...@gmail.com> wrote: Hey Tony, > On Sep 18, 2026, at 4:42 AM, Tony Przygienda <tonysi...@gmail.com> wrote: > > here's an interesting observation. the capability does not distinguish L1/L2 and on P2P we have a single IIH so it's implicitly "capability is for both levels" and that presents implications for e.g. ASH where on broadcast it will separate per level but on P2P both levels are implied. > > not sure we should do anything about it but just factual observation Wouldn't the capability scoping just follow the IS-IS adjaceny, L1, L2, of L1/L2? Thanks, Acee > > -- tony > > On Sun, Sep 6, 2026 at 4:56 PM Tony Przygienda <tonysi...@gmail.com> wrote: > Plus one obviously here and it was Les’ suggestion to pull that out from the ash  draft which I fully support. this will prove useful for lots of other stuff I can imagine > > I’m working currently on something else, but we’ll rewrite the ash draft to point to that one > > Sent from my iPhone > >> On 3 Sep 2026, at 20:31, Les Ginsberg (ginsberg) <ginsberg=40cisco....@dmarc.ietf.org> wrote: >> >>  Acee - >>  The immediate driver for this draft comes from  https://datatracker.ietf.org/doc/draft-prz-lsr-ash-packets/ which needs to signal support for the new PDUs. >> That draft currently proposes a mechanism specific to that use case. >> But I had commented - and Tony P agreed - that it would be more forward looking to define something more generic - which is what this draft does. >>  I absolutely do NOT want to include the ash-packet use case in this draft as that would create a circular dependency between the two drafts. >> I would hope you see the wisdom in that. >>  I also have another use case in mind - but that draft has yet to be written. >>  But if you are worried that we are defining something that will never get used - relax - not the case. 😊 >>     Les >>    >-----Original Message----- >> >From: Acee Lindem <acee.i...@gmail.com> >> >Sent: Thursday, September 3, 2026 11:17 AM >> >To: Les Ginsberg (ginsberg) <ginsb...@cisco.com> >> >Cc: lsr <lsr@ietf.org> >> >Subject: Re: [Lsr] New Version Notification for draft-ginsberg-lsr-hello- >> >capability-00.txt >> > > > >> On Sep 3, 2026, at 2:12 PM, Les Ginsberg (ginsberg) <ginsb...@cisco.com> >> >wrote: >> >> >> Acee - >> >> >> Nothing is being hidden. There are no features defined as of yet. >> >> >> That said, in the context of other drafts - some existing - some yet to be >> >published - use cases will be defined. >> >> >> This draft is intentionally just the "plumbing". >> > >And in that sense, this is the "pipe to nowhere"... I wouldn't think we'd adopt a >> >draft without at least one compelling use case. >> > >Acee >> > > > >> >>    Les >> >> >>> -----Original Message----- >> >>> From: Acee Lindem <acee.i...@gmail.com> >> >>> Sent: Thursday, September 3, 2026 11:05 AM >> >>> To: Les Ginsberg (ginsberg) <ginsb...@cisco.com> >> >>> Cc: lsr <lsr@ietf.org> >> >>> Subject: Re: [Lsr] New Version Notification for draft-ginsberg-lsr-hello- >> >>> capability-00.txt >> >>> >>> Speaking as WG member: >> >>> >>>> On Sep 3, 2026, at 10:33 AM, Les Ginsberg (ginsberg) >> >>> <ginsberg=40cisco....@dmarc.ietf.org> wrote: >> >>>> >>>> Folks - >> >>>> >>>> Tony P and I have posted a new document defining a new TLV to be >> >included >> >>> in hellos. The new TLV  supports advertisement of optional features useful in >> >>> establishing/maintaining adjacencies. >> >>> >>> It seems the draft should include these useful optional features that need to >> >>> discovered prior to establishing an adjacency. >> >>> >>> Thanks, >> >>> Acee >> >>> >>> >>>> >>>> Comments welcomed. >> >>>> >>>>  Les >> >>>> >>>> -----Original Message----- >> >>>> From: internet-dra...@ietf.org <internet-dra...@ietf.org> >> >>>> Sent: Thursday, September 3, 2026 7:30 AM >> >>>> To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; Tony Przygienda >> >>> <antoni.przygie...@hpe.com> >> >>>> Subject: New Version Notification for draft-ginsberg-lsr-hello-capability- >> >00.txt >> >>>> >>>> A new version of Internet-Draft draft-ginsberg-lsr-hello-capability-00.txt >> >has >> >>>> been successfully submitted by Les Ginsberg and posted to the >> >>>> IETF repository. >> >>>> >>>> Name:     draft-ginsberg-lsr-hello-capability >> >>>> Revision: 00 >> >>>> Title:    IS-IS Hello Capability >> >>>> Date:     2026-09-03 >> >>>> Group:    Individual Submission >> >>>> Pages:    6 >> >>>> URL:      https://www.ietf.org/archive/id/draft-ginsberg-lsr-hello-capability- >> >>> 00.txt >> >>>> Status:   https://datatracker.ietf.org/doc/draft-ginsberg-lsr-hello- >> >capability/ >> >>>> HTMLized: https://datatracker.ietf.org/doc/html/draft-ginsberg-lsr-hello- >> >>> capability >> >>>> >>>> >>>> Abstract: >> >>>> >>>>  Advertisement of capabilities in Hellos is useful to allow support of >> >>>>  optional features in establishing and maintaining adjacencies.  This >> >>>>  document defines a new TLV to be sent in hellos to advertise such >> >>>>  capabilities. >> >>>> >>>> >>>> >>>> The IETF Secretariat >> >>>> >>>> >>>> _______________________________________________ >> >>>> Lsr mailing list -- lsr@ietf.org >> >>>> To unsubscribe send an email to lsr-le...@ietf.org >> >>   _______________________________________________ >> Lsr mailing list -- lsr@ietf.org >> To unsubscribe send an email to lsr-le...@ietf.org

_______________________________________________
Lsr mailing list -- lsr@ietf.org
To unsubscribe send an email to lsr-le...@ietf.org