Les,
> 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. Wrong example .. or not related to this discussion. There is no mandate to enable MP-TLVs by configuration. It can be enabled by default and perhaps you can even put this into the text of the draft. The discussion is about ALWAYS having ability to disable MP-TLV by complient with the draft/rfc implementations. Thx, R On Tue, Sep 24, 2024 at 7:41 AM Les Ginsberg (ginsberg) <ginsberg= [email protected]> wrote: > 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 -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
