Hi Les, The dynamic nature of capabilities comes usually handy when operator enables or disables capabilities by configuration ... not when we sent what is implemented.
So with the former (cfg based) I asked as I was not sure what are the consequences of Hellos format changing on the fly. Example: Imagine two routers start and establish adj. Now some time later operator configures one side to work with BFD. I know in ISIS there is RFC6213 which handles that however it could be assumed that if capabilities were defined before instead of defining new TLV for IIHs capabilities could be used. Honestly it seems that even for ASH there could be just new dedicated TLV instead of nesting it under capability umbrella ? Maybe some clarification here would be nice. Cheers, Robert On Tue, Sep 22, 2026 at 7:51 AM Les Ginsberg (ginsberg) <[email protected]> wrote: > Robert – > > > > RFC 5306 (now RFC 8706) is not relevant here. That is associated with a > router restart. > > > > I would not expect the capabilities advertised here to be dynamic. A node > either supports them or doesn’t. > > But it is a fair point to raise and perhaps deserves some discussion in > the draft. > > Note that we aren’t defining a change in the adjacency formation logic – > so even if the advertised support changes this would not cause an > established adjacency to come down – though it might affect how information > is exchanged (ASH being a possible example). > > > > Les > > > > *From:* Robert Raszuk <[email protected]> > *Sent:* Friday, September 18, 2026 3:38 PM > *To:* Les Ginsberg (ginsberg) <[email protected]> > *Cc:* lsr <[email protected]> > *Subject:* [Lsr] Re: FW: New Version Notification for > draft-ginsberg-lsr-hello-capability-00.txt > > > > Hi Les, > > > > Can you change advertised capabilities in Hellos during the lifetime of > the adjacency ? > > > > Yes, my question is a bit influenced by BGP dynamic capabilities & years > of struggle on how to do that without resetting the BGP session. So analogy > to IGP would be how to advertise different capabilities without bouncing > the adjacency. > > > > Maybe the answer here is to use rfc5306 and gracefully restart the adj ? > > > > Thx, > > Robert > > > > On Thu, Sep 3, 2026 at 4:34 PM Les Ginsberg (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. > > 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]
