Hi Tony, From: Tony Li <[email protected]> On Behalf Of Tony Li Sent: Monday, September 9, 2024 7:53 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, First off, link identifiers are a sore spot. Mistakes were made. However, we have, after many tweaks, achieved interoperability in the field. We are now just trying to formally document how to extend this into the MP-TLV space. We do not want to upset the delicate balance of existing implementations. By documenting this as a 'SHOULD', we encourage all implementations along a certain direction without discrediting interoperable implementations that do not precisely follow the letter of the spec. Please understand that as soon as we say 'MUST', it becomes a highly competitive issue and someone's sales team uses it as a lever to bash someone else's sales team. If, in fact, things are interoperable, there is no practical problem. Why pick a fight when we don't have to? [Bruno] There _is_ an interop issue. I believe Les has acknowledged this. "we are at risk that some implementation which does not support Link IDs would not be able to correctly match the two TLVs. I think this is a valid point and I will modify the draft to address this." https://mailarchive.ietf.org/arch/msg/lsr/qRiLP_XqhQqmTKWtM4B2EIPPAyM/ I believe that Les has already addressed this issue in -05. [Bruno2] Ack. As already stated, I believe that the current SHOULD is not enough as an implementation not implementing the SHOULD can trigger an interop issue. Let's wait for Les. As for sales team speech, I sympathize but I can't change sale teams behavior (at my level I try to keep them honest, but I'm afraid that money seems a bigger incentive). Plus it seems like sales teams would have a much bigger lever by saying that an implementation not supporting the knob to disable the sending of MP-TLV creates a risk for the network. So I'm not sure that the "SHOULD" path is that much safer. The "SHOULD" path completely disarms the sales team abuse. Again, everyone should already want to interoperate. That's why we're all here. [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 in https://datatracker.ietf.org/doc/html/rfc8277#section-1 I have other more recent examples but I'd rather avoid pointing to specific implementations. I understand the vendor position to protect the pre-standard implementation. But I'm in the network operator position and I'm trying to make the network as safe as possible. We'll see what position the IETF will take. You do not make the network safer by mandate. You make it safer by writing more forgiving code. More philosophically, interoperability occurs because all parties see the benefits of mutual interoperability, not because of the wording of the spec. We are not lawmakers and there is no enforcement mechanism. It behooves us to write specs that gently encourage everyone to be interoperable. Despite recent musing by the IAB, Postel's law is still the best way forward. [Bruno] RFC 2119 defines keywords for a reason. (to indicate Requirement Levels). Yes, clarity of intent. None of it has the power of law. [Bruno2] So let's just do that: clarify the intent. There is no power of police or justice. There is just interop between implementations supporting the RFC. If your point is that some vendors may incorrectly report support of an RFC, I agree with you. That's a different topic. Not an IETF one. --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]
