Re: [Lsr] draft-pkaneria-lsr-multi-tlv

[[e-mail]]

Les,

Thanks for your message and the clarifications.
I feel a bit obliged to answer. Please see inline.

From: Les Ginsberg (ginsberg) <[e-mail]>
Sent: Friday, November 24, 2023 10:25 PM
To: DECRAENE Bruno INNOV/NET <[e-mail]>; Tony Li <[e-mail]>
Cc: [e-mail]; lsr <[e-mail]>
Subject: RE: draft-pkaneria-lsr-multi-tlv

Bruno –

You began your comments in the context of the adoption thread (Subject: RE: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023)).
I note that you subsequently started a new thread with new (Subject: draft-pkaneria-lsr-multi-tlv).
But as the new thread continued the discussion of the comments which began in the previous thread, you might understand why we missed the distinction and assumed the discussion was in the context of WG adoption call.

OK – I get it now – you don’t want to comment on WG adoption – you just want to make comments on the draft.

The draft is almost 2 years old, has undergone multiple revisions of significance – partly in response to comments we received on the list.
The authors will certainly continue to listen to comments and incorporate them in the document based on discussion.
However, given that WG adoption is in progress, it would be pointless for us to continue to produce new versions of the document if the WG were to decide NOT to adopt the draft. So, I hope you can understand why we are waiting for the question of adoption to be settled before proceeding with further work.
This doesn’t obligate you to voice an opinion on WG adoption, but it certainly would be helpful if you did – and I encourage you to do so.

Many of your comments deserve further discussion – and that will certainly happen if work on the document continues, but for now I only want to respond to one remark you made:

<snip>
It seems that there are existing implementations and just like they did not consult the WG to enable this non-compatible feature, they will not change whatever one might say (not even change the control to enable this mechanism.
<end snip>

What multiple vendors did is try to address a problem that has resulted from the additional features that have been defined in recent RFCs – specifically (but not exclusively) Segment Routing and Flex Algo. These already standardized and deployed protocol extensions resulted in scenarios where it is necessary to send more than 255 bytes for IS Neighbors and Prefix Reachability TLVs – which in turn resulted in unpredictable behavior from implementations which did not know how to deal with such cases. Note that we did not define new extensions which were not standardized – we simply tried to deal with the requirements which came from protocol extensions which have already been standardized. In doing so, we followed the model which has been explicitly defined (and deployed) for some existing TLVs (such as Router Capability). In the process of doing so, we also clearly saw the problems associated with partial deployment – sending MP TLVs in the presence of nodes which don’t support them causes serious problems. We looked for solutions that allowed for safe partial deployment – but found there are none. Subsequent discussion in the WG has confirmed that. We then began work on draft-pkaneria-lsr-multi-tlv so that the full community was aware of the issues.

In short, we have not created a problem – we are trying to address a problem that already exists and which is going to be encountered with increasing frequency as greater scale is deployed.

I see this as a good thing – even being proactive – and I would have thought operators like yourself would be appreciative of this effort. But it seems this has made you angry – you seem to think the vendors involved are rogues who care nothing for operational stability. Which strikes me as “shooting the messenger” behavior.
Should we have done nothing and simply waited for operators to encounter problems – networks falling over in surprising ways?

To clarify my position and personal opinion:

  *   Addressing new requirements is good. Thank you.
  *   Posting the draft to the WG for discussion and standardization is good. Thank you.
  *   From your recollection of history, my personal opinion is that implementations compliant with RFCs defining the TLVs would not be allowed to send multiple TLVs. This would have avoided “unpredictable behavior”. And I don’t think the issue was “from implementations which did not know how to deal with such cases”. Yes, such restriction in sending additional TLVs means that some parts of the requirements/services were not fulfilled. But that was the max that was possible at the time.  To me, such advertisement is either a bug or a deliberate decision even though it was potentially deadly for some networks. To me the issue is there. Again, thank you for your effort to correct the issue by bringing the draft to the WG. (I had just wished it were before creating the issue. ).
  *   Implementation is good. Thank you.
  *   To me, using those existing implementations as an excuse to refuse normative change in the draft is not the way it should be. I’ll keep stating my points even if the more time passing, the less change I have to influence the draft. (if it’s already “too late” during adoption call, then WG discussion and last call is not likely to be useful)

Also, regarding your statement that the vendors who have tried to be proactive will ignore any recommendations that are placed in the draft – I am frankly offended by this statement. Speaking on behalf of one vendor, I can tell you we have already modified our implementation to conform to the best practices defined in the draft – and will continue to monitor the progress of the draft and make further changes as needed. Has your experience of vendor/operator interaction over the past decades really been so bad that your expectations are so low?? That is concerning if true.

I did not mean to offend you. In general implementations are doing very good. But, there has been cases where some implementations have deliberately sent _by default_ TLV with incorrect encodings (for so called innovations) causing surprises and harm in networks. I have a recent case with BGP. I would definitely like to avoid this for link state IGP, especially since for this draft this is well identified, and we all agree that this is harmful.
So let’s all work to avoid killing network by surprise.

--Bruno

   Les


From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, November 23, 2023 1:35 AM
To: Tony Li <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; lsr <[e-mail]<mailto:[e-mail]>>
Subject: RE: draft-pkaneria-lsr-multi-tlv

Hi Tony,



Orange Restricted
From: Tony Li <[e-mail]<mailto:[e-mail]>> On Behalf Of Tony Li
Sent: Wednesday, November 22, 2023 5:03 PM
To: DECRAENE Bruno INNOV/NET <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; lsr <[e-mail]<mailto:[e-mail]>>
Subject: Re: draft-pkaneria-lsr-multi-tlv


Hi Bruno,

We are still waiting to hear whether or not you are in favor of adopting this document.

Thank you (I guess). But where is this coming from?
I understand that:

-       You are waiting for the end of the adoption call

-       I MAY comment on the adoption call (until its end).
I don’t believe that I promised that I would comment on the adoption call, so I’m not sure why you are kind of complaining that I haven’t do it yet.


To clarify, so far:

-       I have reviewed the document and sent questions and comments

-       I have not stated any position on the adoption call

One might infer your intentions,

Really?? Definitely not me at least. And I’m not even capable of inferring what one would infer.

Following this line, one might infer the outcome. It seems that there are existing implementations and just like they did not consult the WG to enable this non-compatible feature, they will not change whatever one might say (not even change the control to enable this mechanism. Plus they would even feel been punished.). C’est la vie.

Draft does not really need a code point. The new column in the IANA registry is somewhat useful but probably not required (For past TLVs, history shows that it was not felt as required and this document can document it. For new TLVs, reading the spec should be just fine).

So, why not use the Independent Submission stream to document what is essentially a vendor-specific extension which has been defined independently of the IETF? E.g, à la RFC 7348 [1]. That’s probably the fastest way to publication at this point and will save time, work and frustration for everyone.

[1] https://datatracker.ietf.org/doc/html/rfc7348

Regards,
--Bruno
but the chairs need it to be explicit.

Regards,
Tony


On Nov 22, 2023, at 5:37 AM, [e-mail]<mailto:[e-mail]> wrote:

Hi authors,

Please find below some specific comments on the document.

Thank you for the effort put in the IANA section. (to indicate wo which (sub-) TLV MPL applies to).

§1
“However, this has not been done for many legacy TLVs, leaving the situation somewhat ambiguous.”
To me the current situation is not ambiguous. The behavior is defined in the spec/RFC. If a behavior is not defined, then it’ is not specified and not allowed.
Please rephrase.
--
“The intent of this document is to clarify and codify the situation by explicitly making multiple occurences of a TLV the mechanism for scaling TLV contents, except where otherwise explicitly stated.”
Similar comment. :s/clarify/specify

--
“The mechanism described in this document has not been documented for all TLVs previously”
Similar comment.
:s/documented/specified

--
OLD: so it is likely that some implementations would not interoperate correctly if these mechanisms were used without caution.
NEW: so non compliant implementations would not interoperate correctly with compliant implementations
(alternatively, that part could be just removed)

--
“The mechanism described in this document has been used explicitly by some implementations, so this document is not creating an unprecedented mechanism.”
Proprietary non-compliant implementations are not an excuse for RFC.
If you need an introduction, you could to the existing TLV specified with MP. (but since this is already stated at the beginning of this section IMO we can just remove that part)

--

§4.1
“It is RECOMMENDED that the link identifiers be the first sub-TLVs.”

For my information, why is so?

·         As currently formulated implementations MUST support any order

·         What the benefit of the ordering given that implementations MUST parse all sub-TLVs?

--
§4.1

“Optionally one or more of the following identifiers:”
[…]
“The key information MUST be replicated identically.”
Do you mean that all identifiers MUST be replicated?
If so, could you please make this point even more explicit  e.g., “(i.e., with all identifiers”)

--
5. Procedure for Receiving Multi-part TLVs

“If the internals of the TLV contain key information, then replication of the key information should be taken to indicate that subsequent data MUST be processed as if the subsequent data were concatenated after a single copy of the key information.”

Given that this section is the key normative part, I’m not found of the “should”. I would suggest :s/should be/is  (but “MUST” also works for me)
--
§6
“The lack of explicit indication of applicability of Multi-Part TLV procedures to all codepoints to which such procedures could be applied contributes to potential interoperability problems if/when the need arises to advertise more than 255 bytes of information for such a codepoint.”
Same comment. If it’s not specified in the existing RFC this is not supported/compliant. This is not a “lack of indication of applicability”.

--
“This document makes explicit the applicability of Multi-Part TLV procedures for all existing codepoints”
:s/makes explicit/specify

--
§7.2 MP-TLV Capability Advertisement

“It is presumed that if such support is provided that it applies to all relevant TLVs. It is understood that in reality, a given implementation might limit MP-TLV support to particular TLVs based on the needs of the deployment scenarios in which it is used.”

Let’s not presume anything. Let’s specify it. And we need to specify a clear meaning for the capability, otherwise it has limited value.
My preference would be that the meaning is “supports MP-TLV” for TLV x, y, z. (or all TLVs). Alternatively, the value would carry the list of TLV supporting MP-TLV (more complex but since it seems that no implementation will act on the content that seems easy to implement). Alternatively, if there is no clear meaning, let’s not bother with the capability.

Thanks,
Regards,
--Bruno


Orange Restricted
From: DECRAENE Bruno INNOV/NET
Sent: Tuesday, November 21, 2023 1:51 PM
To: 'Yingzhen Qu' <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: lsr <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023)

Hi all,


I have some concerns with regards to the deployment of this extension in brownfield multi-vendor networks as this could result in the formation of persistent forwarding loops.

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]
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.
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.

Some of those comments are not new and have already been expressed on this list [2]

I would welcome the feedback of authors on the above proposals before the end of this WG adoption call.

Thanks,
Regards
Bruno

[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.

[2] https://mailarchive.ietf.org/arch/msg/lsr/WIxRR2ZlOJHjxulfXP6Z8nZtKeU/

[3] https://datatracker.ietf.org/doc/html/draft-qgp-lsr-isis-pics-yang

From: Lsr <[e-mail]<mailto:[e-mail]>> On Behalf Of Yingzhen Qu
Sent: Friday, November 17, 2023 6:24 PM
To: [e-mail]<mailto:[e-mail]>; lsr <[e-mail]<mailto:[e-mail]>>
Subject: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023)

Hi,

This begins a WG adoption call for draft-pkaneria-lsr-multi-tlv: draft-pkaneria-lsr-multi-tlv-04 - Multi-part TLVs in IS-IS (ietf.org)<https://datatracker.ietf.org/doc/draft-pkaneria-lsr-multi-tlv/>

Please send your support or objection to the list before December 9th, 2023. An extra week is allowed for the US Thanksgiving holiday.

Thanks,
Yingzhen


Orange Restricted

____________________________________________________________________________________________________________

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.


____________________________________________________________________________________________________________

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.
Orange Restricted


____________________________________________________________________________________________________________
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.