[Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

Fri, 13 Sep 2024 02:58:53 -0700

Hi, Tony:

The aim of the standard is to improve and assure the interoperability, and correct the vendor that doesn’t comply it.
If the proposed document can’t achieve such goal, what’s the gain to forward the document to RFC?

Aijun Wang
China Telecom

On Sep 13, 2024, at 14:13, Tony Li <[email protected]> wrote:



Hi Jimmy,

I do think that implementors will implement multi-TLV when they have need of it, which generally means that they have some feature that’s going to generate that much data or when some customer asks for it. I think that the document is quite clear about how to implement it. Determining the key is quite obvious and needs no further elucidation. 

Anyone can claim to comply with any document at any time. Claims are cheap and not necessarily meaningful.

You can never be sure of interoperability, just as you can never be sure that you’ve caught the last bug.  The only way is to test.  Operators and vendors know this.

Tony


On Sep 12, 2024, at 8:43 PM, Dongjie (Jimmy) - jie.dong at huawei.com <[email protected]> wrote:

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]>
Cc: Bruno Decraene <[email protected]>; Les Ginsberg <[email protected]>; Yingzhen Qu <[email protected]>; lsr <[email protected]>; lsr-chairs <[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]> 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]]
Sent: Tuesday, September 10, 2024 10:41 PM
To: Tony Li <[email protected]>
Cc: Les Ginsberg <[email protected]>; Yingzhen Qu <[email protected]>; lsr <[email protected]>; lsr-chairs <[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]> On Behalf Of Tony Li
Sent: Tuesday, September 10, 2024 4:15 PM
To: DECRAENE Bruno INNOV/NET <[email protected]>
Cc: Les Ginsberg <[email protected]>; Yingzhen Qu <[email protected]>; lsr <[email protected]>; lsr-chairs <[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]
To unsubscribe send an email to [email protected]

_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to