Hi Tony, Thanks for the quick response.
I got the point that this document aims to provide the principle for applying the MP-TLV approach to many existing TLVs (listed in the IANA section). In reality vendors will not implement the proposed changes to all those TLVs, especially that for some TLVs, the behavior is not fully specified by this document. Can they still claim to comply to this document? And can operators be sure that these implementations are interoperable? Best regards, Jie From: Tony Li [mailto:[email protected]] On Behalf Of Tony Li Sent: Thursday, September 12, 2024 10:19 PM To: Dongjie (Jimmy) <[email protected]<mailto:[email protected]>> Cc: Bruno Decraene <[email protected]<mailto:[email protected]>>; Les Ginsberg <[email protected]<mailto:[email protected]>>; Yingzhen Qu <[email protected]<mailto:[email protected]>>; lsr <[email protected]<mailto:[email protected]>>; lsr-chairs <[email protected]<mailto:[email protected]>> Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024) Hi Jimmy, Thank you for your comments. The whole point of this document is to broadly define the MP-TLV rules for all appropriate TLVs. Regards, Tony On Sep 12, 2024, at 1:00 AM, Dongjie (Jimmy) <[email protected]<mailto:[email protected]>> wrote: Hi Bruno, Tony, Les and all, I fully understand the concern about interoperability, and would support approaches which can help to improve interoperability. In addition to making the text more strict by using “MUST”, I’d like to mention other points which can help to mitigate the risk for operators. In my view the main purpose of this document is to specify the usage of the Multi-part TLV approach to a few existing TLVs which are likely to exceed the limitation of 255 octets, such as TLV 22 and TLV 135. Although these two TLVs are just described as examples in the draft, the specifications about their key fields and the sending/receiving procedure are clear. With the new router capability information and operator’s control, their interoperability could be achieved. While for other TLVs as listed in the IANA with “Y” in the MP column, their key fields and the procedure are not explicitly specified in this document. IMO this leaves uncertainty on whether, when and how they will be implemented, and this would increase the possibility of interoperability issues for implementations which claim to support this document. And this cannot be reflected by the new router capability information. Due to such uncertainty, operators may choose not to use Multi-part TLV even for TLV 22 and 135. Thus if the purpose of the document is to promote the usage of Multi-part approach for TLVs which already show the needs, maybe it is better to narrow down the scope of this document and focus on the specification for a smaller group of TLVs. Best regards, Jie From: [email protected]<mailto:[email protected]> [mailto:[email protected]] Sent: Tuesday, September 10, 2024 10:41 PM To: Tony Li <[email protected]<mailto:[email protected]>> Cc: Les Ginsberg <[email protected]<mailto:[email protected]>>; Yingzhen Qu <[email protected]<mailto:[email protected]>>; lsr <[email protected]<mailto:[email protected]>>; lsr-chairs <[email protected]<mailto:[email protected]>> Subject: [Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024) Hi Tony, From: Tony Li <[email protected]<mailto:[email protected]>> On Behalf Of Tony Li Sent: Tuesday, September 10, 2024 4:15 PM To: DECRAENE Bruno INNOV/NET <[email protected]<mailto:[email protected]>> Cc: Les Ginsberg <[email protected]<mailto:[email protected]>>; Yingzhen Qu <[email protected]<mailto:[email protected]>>; lsr <[email protected]<mailto:[email protected]>>; lsr-chairs <[email protected]<mailto:[email protected]>> Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024) Hi Bruno, [Bruno2] I agree that everyone should already want to interoperable. But the unfortunate reality is that not everyone does. I believe that RC3107 is a relatively well-known example: some implementors have deliberately not implemented all (implicit) MUST at the cost of interop issues for network operators. Some details inhttps://datatracker.ietf.org/doc/html/rfc8277#section-1 I have other more recent examples but I’d rather avoid pointing to specific implementations. So you’re admitting that ‘MUST’ doesn’t guarantee interoperability. So why fight about it? MUST does not guarantee interoperability for implementations which are not compliant with the RFC. (i.e., implementation which does not respect the MUST. By design or bugs) Implementations which are compliant with RFC are interoperable. --Bruno T ____________________________________________________________________________________________________________ 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]<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]
