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 <[email protected]> Sent: Friday, September 18, 2026 2:10 PM To: Acee Lindem <[email protected]> Cc: Les Ginsberg <[email protected]>; lsr <[email protected]> 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 <[email protected]<mailto:[email protected]>> wrote: Hey Tony, > On Sep 18, 2026, at 4:42 AM, Tony Przygienda > <[email protected]<mailto:[email protected]>> 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 > <[email protected]<mailto:[email protected]>> 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) >> <[email protected]<mailto:[email protected]>> >> 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 <[email protected]<mailto:[email protected]>> >> >Sent: Thursday, September 3, 2026 11:17 AM >> >To: Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>> >> >Cc: lsr <[email protected]<mailto:[email protected]>> >> >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) >> > > > >> <[email protected]<mailto:[email protected]>> >> >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 <[email protected]<mailto:[email protected]>> >> >>> Sent: Thursday, September 3, 2026 11:05 AM >> >>> To: Les Ginsberg (ginsberg) >> >>> <[email protected]<mailto:[email protected]>> >> >>> Cc: lsr <[email protected]<mailto:[email protected]>> >> >>> 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) >> >>> <[email protected]<mailto:[email protected]>> >> >>> 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: [email protected]<mailto:[email protected]> >> >>>> <[email protected]<mailto:[email protected]>> >> >>>> Sent: Thursday, September 3, 2026 7:30 AM >> >>>> To: Les Ginsberg (ginsberg) >> >>>> <[email protected]<mailto:[email protected]>>; Tony Przygienda >> >>> <[email protected]<mailto:[email protected]>> >> >>>> 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 -- [email protected]<mailto:[email protected]> >> >>>> To unsubscribe send an email to >> >>>> [email protected]<mailto:[email protected]> >> >> _______________________________________________ >> Lsr mailing list -- [email protected]<mailto:[email protected]> >> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
