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: bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> [mailto:bruno.decra...@orange.com] Sent: Tuesday, September 10, 2024 10:41 PM To: Tony Li <tony...@tony.li<mailto:tony...@tony.li>> Cc: Les Ginsberg <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>; Yingzhen Qu <yingzhen.i...@gmail.com<mailto:yingzhen.i...@gmail.com>>; lsr <lsr@ietf.org<mailto:lsr@ietf.org>>; lsr-chairs <lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>> Subject: [Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024) Hi Tony, From: Tony Li <tony1ath...@gmail.com<mailto:tony1ath...@gmail.com>> On Behalf Of Tony Li Sent: Tuesday, September 10, 2024 4:15 PM To: DECRAENE Bruno INNOV/NET <bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>> Cc: Les Ginsberg <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>; Yingzhen Qu <yingzhen.i...@gmail.com<mailto:yingzhen.i...@gmail.com>>; lsr <lsr@ietf.org<mailto:lsr@ietf.org>>; lsr-chairs <lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>> 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 -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
