Hi Tony, > Comments or questions?
Thanks for the update Just looking at the diff, 2 comments 1. "Network operators should not enable Multi-part TLVs until ensuring that all implementations that will receive the Multi-part TLVs are capable of interpreting them correctly." I would rather call for a < must not >. >From a manageability standpoint, since the burden is now on the network >operators to ensure that this will work/not break the network, for existing >TLV, this seem to call: - for a MUST implement knob to enable/disable (MAY/SHOULD on a per TLV basis?). And possibly a SHOULD NOT be enabled by default. Current text says RECOMMENDED and I don't feel that this is enough given that this involves an interop issue, and that some vendors/implementers tends to only implements MUST. - a CLI and I would also suggest the document to specify a YANG extension to allow network operators to know whether a given implementation support this or not (on a per TLV basis?) 2) "the key information MUST be replicated in additional TLV instances so that all contents specific to that key can be identified" Are we all certain that for all TLVs and sub-TLVs, everyone/implementation will agree on what the key is? (especially if the key were to be spread over multiple fields or if a sub-TLV were to contain both a key and non-key data). In order to err on the safe side, I would prefer that this doc specifies the key for all existing TLVs. e.g. "4.1<https://datatracker.ietf.org/doc/html/draft-pkaneria-lsr-multi-tlv-02.txt#section-4.1>. Example: Extended IS Reachability" "Optionally one or more of the following identifiers: - IPv4 interface address and IPv4 neighbor address as specified in [RFC5305<https://datatracker.ietf.org/doc/html/rfc5305>] - IPv6 interface address and IPv6 neighbor address as specified in [RFC6119<https://datatracker.ietf.org/doc/html/rfc6119>] > If multiple (N) IPv6 interface addresses are advertised, these N sub-TLVs are part of the key and must be advertised in all instances./part? Or is a single common ID enough to be used as a key of the interface? Thanks Regards, --Bruno Orange Restricted From: Lsr <[email protected]> On Behalf Of Tony Li Sent: Wednesday, November 30, 2022 7:52 PM To: lsr <[email protected]> Subject: [Lsr] Fwd: New Version Notification for draft-pkaneria-lsr-multi-tlv-02.txt Hi all, This is an update on the multi-part TLV draft. This irons out the nits in the previous version and removes the capability advertisement. Comments or questions? Tony Begin forwarded message: From: [email protected]<mailto:[email protected]> Subject: New Version Notification for draft-pkaneria-lsr-multi-tlv-02.txt Date: November 30, 2022 at 10:49:51 AM PST To: "Antoni Przygienda" <[email protected]<mailto:[email protected]>>, "Chris Bowers" <[email protected]<mailto:[email protected]>>, "Les Ginsberg" <[email protected]<mailto:[email protected]>>, "Parag Kaneriya" <[email protected]<mailto:[email protected]>>, "Shraddha Hegde" <[email protected]<mailto:[email protected]>>, "Tony Li" <[email protected]<mailto:[email protected]>>, "Tony Przygienda" <[email protected]<mailto:[email protected]>> A new version of I-D, draft-pkaneria-lsr-multi-tlv-02.txt has been successfully submitted by Tony Li and posted to the IETF repository. Name: draft-pkaneria-lsr-multi-tlv Revision: 02 Title: Multi-part TLVs in IS-IS Document date: 2022-11-30 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/archive/id/draft-pkaneria-lsr-multi-tlv-02.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-02 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 exist that 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 _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
