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]> wrote: > Hey Tony, > > > On Sep 18, 2026, at 4:42 AM, Tony Przygienda <[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]> > 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= > [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]> > >> >Sent: Thursday, September 3, 2026 11:17 AM > >> >To: Les Ginsberg (ginsberg) <[email protected]> > >> >Cc: lsr <[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]> > >> >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]> > >> >>> Sent: Thursday, September 3, 2026 11:05 AM > >> >>> To: Les Ginsberg (ginsberg) <[email protected]> > >> >>> Cc: lsr <[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]> 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] <[email protected]> > >> >>>> Sent: Thursday, September 3, 2026 7:30 AM > >> >>>> To: Les Ginsberg (ginsberg) <[email protected]>; Tony Przygienda > >> >>> <[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] > >> >>>> To unsubscribe send an email to [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]
