Les, You clearly said:
*> and a given operator might wish to NOT have to configure enablement in the interest of configuration simplification.* So let me restate that NO ONE including Bruno nor myself are asking for making configuration mandatory to *enable* sending of MP-TLVs *and keeping as default MP-TLV generation disabled. * The entire topic of contention is about making it mandatory == REQUIRED to have a knob to *disable* MP-TLV generation (likely on a per TLV basis). If you take time to read my mail 3rd time perhaps you will find post helpful ... Cheers, R. On Wed, Sep 25, 2024 at 6:42 PM Les Ginsberg (ginsberg) <[email protected]> wrote: > Robert – > > > > I have read your email twice and it makes no sense to me. > > > > I stated – and Bruno agreed – that one of the points of discussion was: > > > > <snip> > > 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 > > <end snip> > > > > So enabling/disabling MP via configuration is a point of discussion. > > > > Given that Bruno and I understand each other (even if we do not agree) – I > do not find your post helpful – just confusing. > > > > Les > > > > *From:* Robert Raszuk <[email protected]> > *Sent:* Wednesday, September 25, 2024 8:43 AM > *To:* Les Ginsberg (ginsberg) <[email protected]> > *Cc:* [email protected]; Tony Li <[email protected]>; Yingzhen Qu < > [email protected]>; lsr <[email protected]>; lsr-chairs < > [email protected]> > *Subject:* Re: [Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv > (7/1/2024 - 7/15/2024) > > > > 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]
