Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023)

[Gyan Mishra <[e-mail]>]

Hi Les

Question in-line about the configuration controls being a recommended
solution or must as Bruno pointed out.


Responses in-line Gyan>

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*



On Tue, Nov 21, 2023 at 1:25 PM Les Ginsberg (ginsberg) <ginsberg=
[e-mail]> wrote:

> Bruno –
>
>
>
> First, without dismissing your comments, this is a WG adoption call – not
> a Last Call to publish a draft as an RFC (as Tony has pointed out).
>
> Could you state unambiguously whether you support adoption or not?
>
>
>
> I am in agreement with Tony’s responses. I think my earlier reply to you
> is very much consistent with Tony’s reply.
>
>
>
> Some additional responses inline.
>
>
>
> *From:* [e-mail] <[e-mail]>
> *Sent:* Tuesday, November 21, 2023 9:27 AM
> *To:* Tony Li <[e-mail]>
>
> *Cc:* Yingzhen Qu <[e-mail]>;
> [e-mail]; lsr <[e-mail]>
> *Subject:* RE: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv
> (11/17/2023 - 12/09/2023)
>
>
>
> Hi Tony,
>
>
>
> Thanks for your replies. Much appreciated
>
>
>
> Please see inlines [Bruno]
>
> In any case, that’s fine to have a different perspective because we do
> (e.g., vendor vs operator)
>
>
>
>
>
> Orange Restricted
>
> *From:* Tony Li <[e-mail]> *On Behalf Of *Tony Li
> *Sent:* Tuesday, November 21, 2023 5:45 PM
> *To:* DECRAENE Bruno INNOV/NET <[e-mail]>
> *Cc:* Yingzhen Qu <[e-mail]>;
> [e-mail]; lsr <[e-mail]>
> *Subject:* Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv
> (11/17/2023 - 12/09/2023)
>
>
>
>
>
> Hi Bruno,
>
>
>
> Thank you for your comments.
>
>
>
>
>
> As a constructive proposal, and as mitigations, I would like the document
> be improved with the following changes:
>
> a.       Sending MUST be controlled by configuration [1]
>
> [1]
>
> OLD: It is RECOMMENDED that implementations which support the sending of
> MP-TLVs provide configuration controls to enable/disable generation of
> MP-TLVs.
>
> NEW: It is REQUIRED that implementations which support the sending of
> MP-TLVs provide configuration controls to enable/disable generation of
> MP-TLVs.
>
>
>
>
>
> As you know, some systems already generate multi-part TLVs. And they lack
> any controls for doing this today. The language that you’re suggesting
> would make these systems immediately out of compliance, thereby punishing
> them for providing leading technology.
>
>
>
> [Bruno] Personally, I’d prefer that the LSR WG works on making a good long
> term specification for people using it rather than accommodate short term
> aspects such as pre-standard implementations. (Plus some implementations
> have no problem with claiming support for an RFC while not following the
> spec (e.g., RFC 3107).)
>
> If we are to the point that 1) the argument to adopt MP-TLV is because
> it’s already implemented by some implementations, plus that 2) we can’t
> change anything in the draft because there are pre-standard implementations
> (even if agree that it would be better cf “[LES:] In principle I agree.”
> [A]) then let’s just rubberstamp those implementations and close the WG.
>
>
>
>
>
> Furthermore, it is highly unlikely that any implementation is going to
> actually comply just because of our choice of adjective here.
>
> [Bruno] Exactly my above point: existing implementations may not bother
> and claims compliancy anyway. So, what’s the problem with changing the text
> in the draft?
>
>
>
> The control is clearly not necessary for interoperability and we should
> not overuse our ability to place requirements on implementations. We all
> know that the real power comes from customers who place requirements on
> vendors and the requirements that we place in RFCs are only meaningful when
> describing the requirements for correct operation of our protocols.
> Overextending ourselves dilutes our interoperability requirements.
>
> [Bruno] In my perspective, the control is required to not break existing
> networks.
>
> I agree with you that this is not required for interoperability with other
> MP-TLV implementations, but to me this is required for interoperability
> with RFCs having specified the existing TLVs
>
> a.
>
> b.       For existing TLVs (and “any level of sub-TLVs”), details the TLV
> which could be advertised with no risks for the network and TLVs which must
> not be advertised before all nodes be upgraded.
>
>
>
>
>
> What is ’no risk’? We are not competent to make that assesment. That
> requires knowing everything about every implementation, past, present, and
> future and testing the full cross product of those implementations in all
> possible scenarios.
>
>
>
> [Bruno] I was referring to Les email [A], in particular “[LES:] Again,
> this depends on the codepoint. In the case of Neighbor/Prefix Reachability
> advertisements, the impact on forwarding is highly likely (as your wording
> states). “
>
> [A] https://mailarchive.ietf.org/arch/msg/lsr/jZJi3xe8BcEpmlAG-P_LfSf-FgY/
>
>
>
> *[LES:] It is out of scope for the MP draft to specify what risks may be
> associated with each and every codepoint that has the potential to require
> use of MP.*
>
> *Such an analysis would be lengthy and inaccurate and bloat the draft to
> no useful purpose. It took 20 years before MP usage for Neighbor/Prefix
> advertisements became a realistic deployment scenario. Do you believe that
> folks 20 years ago could have accurately predicted the risks for these two
> TLVs?*
>
> b.
>
> c.       Given this document typically may require global support before
> this be enabled, I think this draft would be a good candidate for the
> addition of the relevant yang module as per draft-qgp-lsr-isis-pics-yang
> [3]. I personally don’t see a problem with adding a normative reference to
> an individual draft, but if I’m wrong, an option for the chairs to consider
> would be to pause this adoption call and start an adoption call for
> draft-qgp-lsr-isis-pics-yang.
>
>
>
>
>
> That would stall this document indefinitely, pending progress on the YANG
> model. Please recall that this document is already two years old and that
> this is an adoption call, NOT WGLC.
>
>
>
> [Bruno] At worst that may only delay RFC publication. All other steps
> would not be delayed so I don’t think that this would delay the feature.
>
> Plus draft-qgp-lsr-isis-pics-yang seems short to me and could probably
> even be made even shorter if needed. So eventually it could be progressed
> quickly.
>
>
>
> *[LES:] While I would like to believe that progress on
> draft-qgp-lsr-isis-pics-yang will be swift, I think the initial feedback we
> have received suggests otherwise. There have already been a number of
> differences of opinion as to appropriate content and this is an important
> discussion to have because we are setting a template for many such drafts
> in the future.*
>
> *I also argue that the two drafts are logically not related. The PICS
> draft is addressing the need for operators to be able to obtain an accurate
> implementation report for the routers in a network. This isn’t specific to
> the use of MP and in fact isn’t directly related to MP at all.*
>
> *MP has only highlighted that in order to safely deploy features in a
> network operators need such information – which is an existing problem.*
>
>
>
> The question on the table is not whether this document is perfect. The
> question is whether this is worth continuing to work on and whether this
> document is the correct basis for that work. I would like to see this
> document published sometime this century.
>
> [Bruno] Indeed. And the related question is whether the WG is allowed to
> modify the content of that document or whether the document is as-is
> because there exist pre-standards implementations.
>
>
>
>
>
> *[LES:] I don’t understand your response. Further discussion of the
> content of the MP draft will happen post adoption – just as it has for
> every other document which has been adopted in the history of the IETF.*
>
> *Further, the heart of the document is explanatory/informational – not
> normative. I don’t see risk that “early implementations” will not
> interoperate with implementations based on later versions of the draft
> because the draft is not altering protocol behavior.*
>
> *There is only one new codepoint introduced in the document (capabilities
> advertisement) and that has been explicitly defined to not be required so
> as not to introduce interoperability issues.*
>
>
>
      Gyan> Good points.  So as you stated majority of what has been
implemented by vendors and deployed by operators protocol wise has been
static and more then likely will not be changing post adoption and maybe
even through publication.  So that being said configuration knobs such as
the must for the enable / disable of advertising the MP TLV that should not
be an issue since we are not changing the protocol specification in any way
shape or form.  I think the knob adds flexibility and configuration
controls for operators giving comfort in deploying the extension.

> *   Les*
>
>
>
>
>
> Regards,
>
> --Bruno
>
>
>
> Regards,
>
> Tony
>
>
>
> ____________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
>
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
>
> they should not be distributed, used or copied without authorisation.
>
> If you have received this email in error, please notify the sender and delete this message and its attachments.
>
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>
> Thank you.
>
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
>