Robert - From: Robert Raszuk <[email protected]> Sent: Tuesday, September 22, 2026 3:02 AM To: Les Ginsberg (ginsberg) <[email protected]> Cc: Les Ginsberg (ginsberg) <[email protected]>; lsr <[email protected]> Subject: Re: [Lsr] Re: FW: New Version Notification for draft-ginsberg-lsr-hello-capability-00.txt
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. [LES:] RFC 6213 defines how to handle transitions – see https://www.rfc-editor.org/rfc/rfc6213.html#section-4 But the BFD case differs from what we are discussing here because the point of RFC 6213 was to modify the adjacency state machine. It is not expected that the capabilities advertised using the new TLV will modify the adjacency state machine. If they do, it is the responsibility of the RFC which defines that new capability to discuss those changes – which would likely introduce backwards compatibility issues. Here we simply depend on the base protocol rule that unknown codepoints are silently ignored. Honestly it seems that even for ASH there could be just new dedicated TLV instead of nesting it under capability umbrella ? [LES:] Yes – there could be. But as TLV codepoints are a limited resource in IS-IS, we believe defining a generic container is a better option. The analogy here is to the Router Capability TLV. That could have been done by defining a new TLV every time we needed to advertise a new capability – but it would have consumed many more top level codepoints (over 30 at present). Les Maybe some clarification here would be nice. Cheers, Robert On Tue, Sep 22, 2026 at 7:51 AM Les Ginsberg (ginsberg) <[email protected]<mailto:[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]<mailto:[email protected]>> Sent: Friday, September 18, 2026 3:38 PM To: Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>> Cc: lsr <[email protected]<mailto:[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) <[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. 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] To unsubscribe send an email to [email protected]
