Folks -
I appreciate the good discussion that went on over the last couple weeks. There are three potential textual changes being considered: Section 4.1 "The set of link identifiers SHOULD be identical in all TLVs which are part of the MP-TLV set." Possibly changing "SHOULD" to MUST". Section 7.1 "It is RECOMMENDED that implementations which support the sending of MP-TLVs provide configuration controls to enable/disable generation of MP-TLVs. " Possibly changing RECOMMENDED to REQUIRED Section 7 "Providing appropriate controls to enable/disable the sending of MP-TLVs as discussed in Section 7.1 is essential to avoid interoperability issues." Changing "essential" to "important" Note: This is a consistency issue - if we do NOT use REQUIRED in Section 7.1 then it would be better NOT to use "essential" in Section 7. DISCUSSION Regarding Section 7/7.1 The argument is being made that using "REQUIRED/essential" reduces the potential for interoperability problems. This assumes that some vendors who might otherwise NOT implement the recommended practices would be more likely to do so if normative language were used. This in turn presumes that the chance of interoperability problems would be reduced as a result. I am sympathetic to the goal. Many of us have had real world experiences with interoperability issues and they are costly. But I believe mandating aspects of an implementation which are unenforceable and undetectable is not guaranteed to reduce interoperability issues. The incidence of interoperability issues is most effectively reduced by robustness in implementations. As Tony Li has stated: "You do not make the network safer by mandate. You make it safer by writing more forgiving code." What is REQUIRED in a protocol specification are normative statements about what is sent on the wire. But asserting that there is "one correct way" for an implementation to support enablement/disablement is not appropriate - not least because the benefits of a given approach may well depend upon the use case. Example: One can imagine a network where MP is the norm and a given operator might wish to NOT have to configure enablement in the interest of configuration simplification. I see no reason why this should be declared "illegal" just because others might not use that deployment strategy. Suggestions/recommendations as to how an implementation might ease deployment are valuable and these are discussed in the draft - and I believe we do have consensus as to recommended best practices. I therefore believe the current wording is appropriate and should not be changed. The only change that needs to be made to the draft is to change "essential" to "important" in Section 7 (for consistency). I appreciate the passion associated with this discussion - but I am hopeful that this resolution is acceptable to all. Regarding Section 4.1, any interoperability issues with link identifiers are not introduced by MP. If the WG feels there is an issue here, it should be taken up outside of MP as it could impact two-way connectivity checks even in non MP-TLV cases. I am not suggesting that such work is necessary - only indicating the correct context in which such work should be done if it is to be done at all. As far as the current wording in Section 4.1, it intentionally allows existing implementations which successfully interoperate sending a subset of link identifiers to continue to do so. Les
_______________________________________________ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
