The key point that this draft SHOULD NOT(or MUST not?) be forwarded, is not the tweak of these nuances words, but its false declaration that “This document codifies the common mechanism of extending the TLV content space through multiple TLVs.”.
Actually, it codifies at most only two TLVs (“Extended IS Reachability” and “Extended IP Reachability”), and leaves many unsolved, or in chaos states/possibilities. I am wondering how the WG chairs can put forward this document in current content. Best Regards Aijun Wang China Telecom 发件人: [email protected] [mailto:[email protected]] 代表 Robert Raszuk 发送时间: 2024年9月26日 2:10 收件人: Les Ginsberg (ginsberg) <[email protected]> 抄送: [email protected]; Tony Li <[email protected]>; Yingzhen Qu <[email protected]>; lsr <[email protected]>; lsr-chairs <[email protected]> 主题: [Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024) 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] <mailto:[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 < <mailto:[email protected]> [email protected]> Sent: Wednesday, September 25, 2024 8:43 AM To: Les Ginsberg (ginsberg) < <mailto:[email protected]> [email protected]> Cc: <mailto:[email protected]> [email protected]; Tony Li < <mailto:[email protected]> [email protected]>; Yingzhen Qu < <mailto:[email protected]> [email protected]>; lsr < <mailto:[email protected]> [email protected]>; lsr-chairs < <mailto:[email protected]> [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) <[email protected] <mailto:[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] <mailto:[email protected]> To unsubscribe send an email to [email protected] <mailto:[email protected]>
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
