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> 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 > *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>, "Chris Bowers" < > cbo...@juniper.net>, "Les Ginsberg" <ginsb...@cisco.com>, "Parag > Kaneriya" <pkane...@juniper.net>, "Shraddha Hegde" <shrad...@juniper.net>, > "Tony Li" <tony...@tony.li>, "Tony Przygienda" <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 > https://www.ietf.org/mailman/listinfo/lsr >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
