Bruno - Some responses inline - speaking only for myself - not necessarily for all of the co-authors...
From: Lsr <[email protected]> On Behalf Of [email protected] Sent: Thursday, December 1, 2022 6:04 AM To: Tony Li <[email protected]>; lsr <[email protected]> Subject: Re: [Lsr] Fwd: New Version Notification for draft-pkaneria-lsr-multi-tlv-02.txt 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: [LES:] There was never a choice here - the burden is on network operators - and would be even if an advertisement of MP support were provided. Why? Because there is no safe way for implementations to react to changes in the network state regarding MP support without risking flooding storms. And, repeating a point I have made in the past, suppressing advertisement of MP-TLVs when the current configuration requires sending them does not result in a working network. I don't think it is a productive discussion to try to determine which condition is worse: a)To send MP-TLVs in the presence of one or nodes which are unable to process them or b)To suppress sending of some information required by the existing configuration Either way, the network will not be working as expected. - 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. [LES:] I am fine either way. But as you are trying to apply normative language to a behavior which is not reflected "on the wire", it is hard to see that there is any ability to enforce this. SHOULD/RECOMMENDED seems appropriate to me. - 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?) [LES:] This makes sense to me. 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? [LES:] Initially, we did not target this draft to serve as "closing the gap" as regards existing TLVs where the relevant RFC is not explicit regarding MP support. However, I think the discussion in the WG has highlighted that some codepoints have explicit language regarding MP support and some do not - and that it would be useful to have a place where what is implicit is stated explicitly. This draft might be the right place to do that. Be interested in feedback from others on this point. Les Thanks Regards, --Bruno Orange Restricted From: Lsr <[email protected]<mailto:[email protected]>> On Behalf Of Tony Li Sent: Wednesday, November 30, 2022 7:52 PM To: lsr <[email protected]<mailto:[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
