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. > 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. > 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. T
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
