Hi All. What is the expected action if all routers in the area do not support multi-part TLVs? Does the advertising router simply not advertise the information that doesn’t fit? This needs to be specified.
In general, I’m not a fan of these all or none IGP capabilities but sometimes they can’t be avoided. Thanks, Acee From: Lsr <lsr-boun...@ietf.org> on behalf of Ketan Talaulikar <ketant.i...@gmail.com> Date: Friday, July 22, 2022 at 11:20 AM To: Tony Li <tony...@tony.li> Cc: lsr <lsr@ietf.org> Subject: Re: [Lsr] Fwd: New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt Hi Tony & Co-authors, The introduction of the capabilities (at this stage) might be a challenge given existing implementations that do multi-part TLVs and are shipping and deployed. If this was intended mainly to aid debugging and for the operator to evaluate the capabilities in the network, it might be helpful. However, triggering anything based on network-wide capability determination might turn out to be problematic. There was this text in v00 of the draft in sec 3 (perhaps it should have been in sec 4). Note: If the fixed portion of a TLV includes information that is NOT part of the key and the non-key elements of the fixed portion of the TLV (metric and other bits in the control octet in the example below) differ, the values in the first TLV present in the lowest numbered LSP MUST be used. This seems to have been omitted from v01. Not sure if this was specifically intended and if so, I think the above text is important to clarify. There is also this more general thing about sub-TLVs that are supposed to be advertised only once and if there are multiple instances of them (this might happen in transient situations), then the instance in the lowest number/fragment is considered valid and others ignored. There are specs that say this, but perhaps there are others that don't? So can this be also considered for addition as a "general" rule even though it is slightly different from the multi-part TLV focus of the draft? And thanks for keeping the discussion on clarifications of keys (at least for a few important sub-TLV/TLV) still on the table :-) Thanks, Ketan On Tue, Jul 5, 2022 at 6:39 AM Tony Li <tony...@tony.li<mailto:tony...@tony.li>> wrote: Hi all, This is an update to reflect some of the discussions to date. A diff is attached. Most of this is a change to terminology to stop using the word ‘instance’ and shift to using ‘multi-part TLV’. We have been having a discussion about adding more discussion of keys in this document. We have not done that yet. This is not an indication of refusal, just making one baby step forward. More to come… Text contributions are more than welcome. Other comments? Regards, Tony Begin forwarded message: From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> Subject: New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt Date: July 4, 2022 at 6:04:37 PM PDT To: "Antoni Przygienda" <p...@juniper.net<mailto:p...@juniper.net>>, "Chris Bowers" <cbo...@juniper.net<mailto:cbo...@juniper.net>>, "Les Ginsberg" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>, "Parag Kaneriya" <pkane...@juniper.net<mailto:pkane...@juniper.net>>, "Shraddha Hegde" <shrad...@juniper.net<mailto:shrad...@juniper.net>>, "Tony Li" <tony...@tony.li<mailto:tony...@tony.li>>, "Tony Przygienda" <p...@juniper.net<mailto:p...@juniper.net>> A new version of I-D, draft-pkaneria-lsr-multi-tlv-01.txt has been successfully submitted by Tony Li and posted to the IETF repository. Name: draft-pkaneria-lsr-multi-tlv Revision: 01 Title: Multi-part TLVs in IS-IS Document date: 2022-07-04 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/archive/id/draft-pkaneria-lsr-multi-tlv-01.txt Status: https://datatracker.ietf.org/doc/draft-pkaneria-lsr-multi-tlv/ Htmlized: https://datatracker.ietf.org/doc/html/draft-pkaneria-lsr-multi-tlv Diff: https://www.ietf.org/rfcdiff?url2=draft-pkaneria-lsr-multi-tlv-01 Abstract: New technologies are adding new information into IS-IS while deployment scales are simultaneously increasing, causing the contents of many critical TLVs to exceed the currently supported limit of 255 octets. Extensions such as [RFC7356] require significant IS-IS changes that could help address the problem, but a less drastic solution would be beneficial. This document codifies the common mechanism of extending the TLV content space through multiple TLVs. The IETF Secretariat _______________________________________________ Lsr mailing list Lsr@ietf.org<mailto:Lsr@ietf.org> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
