While this is probably not a big deal for ASH, the issue should be considered for other capabilities in the future.
Tony > On Sep 18, 2026, at 2:09 PM, Tony Przygienda - tonysietf at gmail.com > <[email protected]> wrote: > > 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]
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
