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

[bruno . decraene]

Les,

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

From: Les Ginsberg (ginsberg) 
Sent: Friday, November 24, 2023 10:25 PM
To: DECRAENE Bruno INNOV/NET ; Tony Li 

Cc: draft-pkaneria-lsr-multi-...@ietf.org; lsr 
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:


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.


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 

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

[Les Ginsberg (ginsberg)]

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:


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.


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?

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.

   Les


From: bruno.decra...@orange.com 
Sent: Thursday, November 23, 2023 1:35 AM
To: Tony Li 
Cc: draft-pkaneria-lsr-multi-...@ietf.org; lsr 
Subject: RE: draft-pkaneria-lsr-multi-tlv

Hi Tony,



Orange Restricted
From: Tony Li mailto:tony1ath...@gmail.com>> On Behalf 
Of Tony Li
Sent: Wednesday, November 22, 2023 5:03 PM
To: DECRAENE Bruno INNOV/NET 
mailto:bruno.decra...@orange.com>>
Cc: 
draft-pkaneria-lsr-multi-...@ietf.org;
 lsr mailto:lsr@ietf.org>>
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 

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

[bruno . decraene]

Hi Tony,



Orange Restricted
From: Tony Li mailto:tony1ath...@gmail.com>> On Behalf 
Of Tony Li
Sent: Wednesday, November 22, 2023 5:03 PM
To: DECRAENE Bruno INNOV/NET 
mailto:bruno.decra...@orange.com>>
Cc: 
draft-pkaneria-lsr-multi-...@ietf.org;
 lsr mailto:lsr@ietf.org>>
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, 
bruno.decra...@orange.com 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 

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

[Tony Li]

Hi Bruno,

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

One might infer your intentions, but the chairs need it to be explicit.

Regards,
Tony


> On Nov 22, 2023, at 5:37 AM, bruno.decra...@orange.com 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' mailto:yingzhen.i...@gmail.com>>; 
> draft-pkaneria-lsr-multi-...@ietf.org 
> 
> Cc: lsr mailto:lsr@ietf.org>>
> 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 

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

[bruno . decraene]

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' mailto:yingzhen.i...@gmail.com>>; 
draft-pkaneria-lsr-multi-...@ietf.org
Cc: lsr mailto:lsr@ietf.org>>
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 

Re: [Lsr] draft-pkaneria-lsr-multi-tlv and "backwards compatibility"

[bruno . decraene]

Les,

Thanks for the reply.
Please see inline [Bruno2]



Orange Restricted
From: Les Ginsberg (ginsberg) 
Sent: Thursday, November 16, 2023 5:32 PM
To: DECRAENE Bruno INNOV/NET ; Christian Hopps 

Cc: lsr@ietf.org
Subject: RE: draft-pkaneria-lsr-multi-tlv and "backwards compatibility"

Bruno –

Thanx for the thoughtful comments.
Please see responses inline.

From: bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> 
mailto:bruno.decra...@orange.com>>
Sent: Thursday, November 16, 2023 6:40 AM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
Christian Hopps mailto:cho...@chopps.org>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: RE: draft-pkaneria-lsr-multi-tlv and "backwards compatibility"

Les, all

Please see my 2 cents (operator’s feedback) inline [Bruno]
(to be clear, I’m not doing any comparison with any other proposal)



Orange Restricted
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Les 
Ginsberg (ginsberg)
Sent: Monday, November 6, 2023 4:13 PM
To: Christian Hopps mailto:cho...@chopps.org>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] draft-pkaneria-lsr-multi-tlv and "backwards compatibility"


Chris -



Thanx for the reply - and glad to see we seem to be headed in the same 
direction.



Just wanted to clarify that the MP draft does NOT advocate partial deployment.



[Bruno] Speaking of clarity, I’d rephrase this as “does NOT support (enablement 
in) partial deployment”



[LES:] I think we need to pay attention to “scope” here.

The use cases related to Neighbor and Prefix Reachability TLVs are what has 
brought this issue to the forefront, but the scope of the MP-TLV draft is all 
codepoints to which MP applies.

For TLVs which are processed by all nodes in the network, partial deployment of 
MP support is simply not going to work.

But there are TLVs to which MP applies which may not be processed by all nodes 
in the network. In such cases, use of MP for those codepoints could be viable 
in the presence of nodes which don’t support MP so long as those nodes don’t 
need to process that codepoint at all.

Making a statement that partial deployment won’t work in all cases therefore 
isn’t accurate.



[Bruno2] You are correct of course. You are welcome to details those two cases 
in the draft.



No support of partial deployment makes this very difficult to deploy in certain 
environments.

You’d be surprised how old some platforms may be. And given that LSPs are 
flooded to all nodes (vs BGP attributes), in those environments, we are 
speaking of more than a decade between support on all implementation and 
deployment. Adding that some implementations may implement this latter, I’d say 
more than a decade (2 decades looks doable).



[LES:] Actually, I am not surprised by this at all. 

Part of my job is supporting old releases – even though I would wish that the 
customer would “just upgrade”.



[Bruno2] Yes, life would be simpler if customer would “just upgrade” or vendors 
would not move a platform to end of engineering . But obviously both sides 
have constraints and we need to live with that.





https://www.ietf.org/archive/id/draft-pkaneria-lsr-multi-tlv-04.html#name-deployment-considerations
 recommends:



· Implementations provide a knob to control the use of MP-TLV

· Implementations report an alarm if an MP-TLV is received when use of 
MP-TLVs is disabled.

· Implementations report an alarm if local LSP generation requires the 
use of MP-TLVs when generation of MP-TLVs is disabled.



[Bruno] Good. Or minimal given the issues brought in case of partial 
deployment. Given that some implementors tends to skips “SHOULD”, I’d rather 
call for REQUIRED. (and I believe REQUIRED is the right level, at least for the 
first item)



[LES:] In principle I agree. But making a configuration knob or an alarm 
mandatory has some practical limitations.

One can (for example) say that a TLV format MUST follow certain constraints and 
enforce this on the receiver by saying if a malformed TLV is received it MUST 
be ignored.

But there is no enforcement mechanism for configuration knobs/alarms.

It is possible that a given implementation might define an alternate 
configuration mechanism that the owners believe meets the intention of the 
statements above but does not match the definitions – so the use normative 
language here makes me think we are overstepping.

While I agree with you in spirit, I am not sure that making the change you 
suggest is justifiable.

Happy to listen to WG feedback on this.

[Bruno2] I’m happy to rephrase the first requirement so that both of us are 
happy. Eg., Implementations MUST provide a way to disable generation of MP-TLVs.



Following these guidelines, MP-TLVs would only be present in a network when the 
control is set to use them AND the operator enters a config which requires 
sending more than 255 bytes. A

Re: [Lsr] draft-pkaneria-lsr-multi-tlv and "backwards compatibility"

[Les Ginsberg (ginsberg)]

Bruno –

Thanx for the thoughtful comments.
Please see responses inline.

From: bruno.decra...@orange.com 
Sent: Thursday, November 16, 2023 6:40 AM
To: Les Ginsberg (ginsberg) ; Christian Hopps 

Cc: lsr@ietf.org
Subject: RE: draft-pkaneria-lsr-multi-tlv and "backwards compatibility"

Les, all

Please see my 2 cents (operator’s feedback) inline [Bruno]
(to be clear, I’m not doing any comparison with any other proposal)



Orange Restricted
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Les 
Ginsberg (ginsberg)
Sent: Monday, November 6, 2023 4:13 PM
To: Christian Hopps mailto:cho...@chopps.org>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] draft-pkaneria-lsr-multi-tlv and "backwards compatibility"


Chris -



Thanx for the reply - and glad to see we seem to be headed in the same 
direction.



Just wanted to clarify that the MP draft does NOT advocate partial deployment.



[Bruno] Speaking of clarity, I’d rephrase this as “does NOT support (enablement 
in) partial deployment”



[LES:] I think we need to pay attention to “scope” here.

The use cases related to Neighbor and Prefix Reachability TLVs are what has 
brought this issue to the forefront, but the scope of the MP-TLV draft is all 
codepoints to which MP applies.

For TLVs which are processed by all nodes in the network, partial deployment of 
MP support is simply not going to work.

But there are TLVs to which MP applies which may not be processed by all nodes 
in the network. In such cases, use of MP for those codepoints could be viable 
in the presence of nodes which don’t support MP so long as those nodes don’t 
need to process that codepoint at all.

Making a statement that partial deployment won’t work in all cases therefore 
isn’t accurate.



No support of partial deployment makes this very difficult to deploy in certain 
environments.

You’d be surprised how old some platforms may be. And given that LSPs are 
flooded to all nodes (vs BGP attributes), in those environments, we are 
speaking of more than a decade between support on all implementation and 
deployment. Adding that some implementations may implement this latter, I’d say 
more than a decade (2 decades looks doable).



[LES:] Actually, I am not surprised by this at all. 

Part of my job is supporting old releases – even though I would wish that the 
customer would “just upgrade”.





https://www.ietf.org/archive/id/draft-pkaneria-lsr-multi-tlv-04.html#name-deployment-considerations
 recommends:



· Implementations provide a knob to control the use of MP-TLV

· Implementations report an alarm if an MP-TLV is received when use of 
MP-TLVs is disabled.

· Implementations report an alarm if local LSP generation requires the 
use of MP-TLVs when generation of MP-TLVs is disabled.



[Bruno] Good. Or minimal given the issues brought in case of partial 
deployment. Given that some implementors tends to skips “SHOULD”, I’d rather 
call for REQUIRED. (and I believe REQUIRED is the right level, at least for the 
first item)



[LES:] In principle I agree. But making a configuration knob or an alarm 
mandatory has some practical limitations.

One can (for example) say that a TLV format MUST follow certain constraints and 
enforce this on the receiver by saying if a malformed TLV is received it MUST 
be ignored.

But there is no enforcement mechanism for configuration knobs/alarms.

It is possible that a given implementation might define an alternate 
configuration mechanism that the owners believe meets the intention of the 
statements above but does not match the definitions – so the use normative 
language here makes me think we are overstepping.

While I agree with you in spirit, I am not sure that making the change you 
suggest is justifiable.

Happy to listen to WG feedback on this.



Following these guidelines, MP-TLVs would only be present in a network when the 
control is set to use them AND the operator enters a config which requires 
sending more than 255 bytes. And violations of these conditions would be 
reported.



[Bruno] I don’t think that there is such “the operator enters a config which 
requires sending more than 255 bytes”. In my environment, a provisioning tool 
or a human would not know whether a given config would “require sending more 
than 255 bytes” or not. This would be too much complexity.

Not to mention that I guess that in the general case the config may be done on 
one node (e.g., a PE) and the advertisement requiring more than 255 octets 
could be done on a different node (e.g., ABR, L1/L2 router).

Finally, I would also assume that with zero config change from the operator, a 
software upgrade could have the limit being exceeded. (e.g., the new software 
advertising new sub-TLV, such as RFC 7794 “Prefix Attributes for Extended IPv4 
and IPv6 Reachability”).

IOW, let’s not put the blame on the operator when the issue is the spec (or 
feature) not supporting partial de

Re: [Lsr] draft-pkaneria-lsr-multi-tlv and "backwards compatibility"

[bruno . decraene]

Les, all

Please see my 2 cents (operator's feedback) inline [Bruno]
(to be clear, I'm not doing any comparison with any other proposal)



Orange Restricted
From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
Sent: Monday, November 6, 2023 4:13 PM
To: Christian Hopps 
Cc: lsr@ietf.org
Subject: Re: [Lsr] draft-pkaneria-lsr-multi-tlv and "backwards compatibility"


Chris -



Thanx for the reply - and glad to see we seem to be headed in the same 
direction.



Just wanted to clarify that the MP draft does NOT advocate partial deployment.



[Bruno] Speaking of clarity, I'd rephrase this as "does NOT support (enablement 
in) partial deployment"

No support of partial deployment makes this very difficult to deploy in certain 
environments.

You'd be surprised how old some platforms may be. And given that LSPs are 
flooded to all nodes (vs BGP attributes), in those environments, we are 
speaking of more than a decade between support on all implementation and 
deployment. Adding that some implementations may implement this latter, I'd say 
more than a decade (2 decades looks doable).





https://www.ietf.org/archive/id/draft-pkaneria-lsr-multi-tlv-04.html#name-deployment-considerations
 recommends:



* Implementations provide a knob to control the use of MP-TLV

* Implementations report an alarm if an MP-TLV is received when use of 
MP-TLVs is disabled.

* Implementations report an alarm if local LSP generation requires the 
use of MP-TLVs when generation of MP-TLVs is disabled.



[Bruno] Good. Or minimal given the issues brought in case of partial 
deployment. Given that some implementors tends to skips "SHOULD", I'd rather 
call for REQUIRED. (and I believe REQUIRED is the right level, at least for the 
first item)



Following these guidelines, MP-TLVs would only be present in a network when the 
control is set to use them AND the operator enters a config which requires 
sending more than 255 bytes. And violations of these conditions would be 
reported.



[Bruno] I don't think that there is such "the operator enters a config which 
requires sending more than 255 bytes". In my environment, a provisioning tool 
or a human would not know whether a given config would "require sending more 
than 255 bytes" or not. This would be too much complexity.

Not to mention that I guess that in the general case the config may be done on 
one node (e.g., a PE) and the advertisement requiring more than 255 octets 
could be done on a different node (e.g., ABR, L1/L2 router).

Finally, I would also assume that with zero config change from the operator, a 
software upgrade could have the limit being exceeded. (e.g., the new software 
advertising new sub-TLV, such as RFC 7794 "Prefix Attributes for Extended IPv4 
and IPv6 Reachability").

IOW, let's not put the blame on the operator when the issue is the spec (or 
feature) not supporting partial deployment.





Draft says "Sending of MP-TLVs in the presence of nodes which do not correctly 
process such advertisements can result in interoperablity issues, including 
incorrect forwarding of packets."



[Bruno]

While correct, I find the sentence a bit on the understatement side. In 
particular

:s/can result/is likely to result   (if not "will result")

:s/packets/a significant portion of the traffic resulting in persistent 
forwarding loops.



And thanks to Christian for the nice summary and bridging the communication gap.



--Bruno



   Les



> -Original Message-

> From: Christian Hopps mailto:cho...@chopps.org>>

> Sent: Monday, November 6, 2023 6:10 AM

> To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>

> Cc: Christian Hopps mailto:cho...@chopps.org>>; 
> lsr@ietf.org<mailto:lsr@ietf.org>

> Subject: Re: draft-pkaneria-lsr-multi-tlv and "backwards compatibility"

>

>

> My point is that people are not using the same definition of backward

> compatibility. This is why this argument over it is going in circles. I'm

> suggesting that when you consider each persons definition of backward

> compatibility, then neither side is wrong. So saying things like "No. You are

> wrong" etc, is not helpful to moving things forward.

>

> In both cases, when you actually need multi-part-tlv, you have to deploy the

> new software to all the routers that will use it; however the multi-part-tlv 
> draft

> allows for a messy sort of "it still works as long as you don't need 
> multi-part-

> tlv on routers that don't understand it" operation. So you hand craft your

> software deployment to match your network config to make that work.

>

> The Big TLV solution does not allow for this "messy but functioning

> deployment", and this is why I believe people prefer the multi-part TLV

> solution. That should be enough

Re: [Lsr] draft-pkaneria-lsr-multi-tlv and "backwards compatibility"

[Les Ginsberg (ginsberg)]

Chris -



Thanx for the reply - and glad to see we seem to be headed in the same 
direction.



Just wanted to clarify that the MP draft does NOT advocate partial deployment. 
https://www.ietf.org/archive/id/draft-pkaneria-lsr-multi-tlv-04.html#name-deployment-considerations
 recommends:



  *   Implementations provide a knob to control the use of MP-TLV
  *   Implementations report an alarm if an MP-TLV is received when use of 
MP-TLVs is disabled.
  *   Implementations report an alarm if local LSP generation requires the use 
of MP-TLVs when generation of MP-TLVs is disabled.



Following these guidelines, MP-TLVs would only be present in a network when the 
control is set to use them AND the operator enters a config which requires 
sending more than 255 bytes. And violations of these conditions would be 
reported.



   Les



> -Original Message-

> From: Christian Hopps 

> Sent: Monday, November 6, 2023 6:10 AM

> To: Les Ginsberg (ginsberg) 

> Cc: Christian Hopps ; lsr@ietf.org

> Subject: Re: draft-pkaneria-lsr-multi-tlv and "backwards compatibility"

>

>

> My point is that people are not using the same definition of backward

> compatibility. This is why this argument over it is going in circles. I'm

> suggesting that when you consider each persons definition of backward

> compatibility, then neither side is wrong. So saying things like "No. You are

> wrong" etc, is not helpful to moving things forward.

>

> In both cases, when you actually need multi-part-tlv, you have to deploy the

> new software to all the routers that will use it; however the multi-part-tlv 
> draft

> allows for a messy sort of "it still works as long as you don't need 
> multi-part-

> tlv on routers that don't understand it" operation. So you hand craft your

> software deployment to match your network config to make that work.

>

> The Big TLV solution does not allow for this "messy but functioning

> deployment", and this is why I believe people prefer the multi-part TLV

> solution. That should be enough to move things forward IMO.

>

> Thanks,

> Chris.

> [wg-member]

>

> "Les Ginsberg (ginsberg)" mailto:ginsb...@cisco.com>> 
> writes:

>

> > Chris (and everyone) -

> >

> >

> >

> > A more complete response to your comments regarding "backwards

> > compatibility", routing loops, etc.

> >

> >

> >

> > It is absolutely true that until all nodes in the network support

> > advertisement (meaning at least receive processing) of more than 255

> > bytes for a given object, that any attempt to deploy a configuration

> > which requires the advertisement of more than 255 bytes for that

> > object is likely to result in some type of failure.

> >

> > That failure could manifest itself as routing loops or blackholes or

> > in other ways. This is explicitly stated in https://www.ietf.org/

> > archive/id/draft-pkaneria-lsr-multi-tlv-04.html#

> > name-deployment-considerations :

> >

> >

> >

> > “Sending of MP-TLVs in the presence of nodes which do not correctly

> > process such advertisements can result in interoperability issues,

> > including incorrect forwarding of packets.”

> >

> >

> >

> > No one has ever tried to state otherwise.

> >

> >

> >

> > But it is also true that encodings other than MP suffer from the same

> > limitation. The authors of Big-TLV try to claim otherwise, but this

> > does not stand up to scrutiny – see my replies to Huaimo for more

> > details as to why.

> >

> >

> >

> > Would it be great if we could find a way to allow “incremental

> > deployment”? Sure – but it isn’t possible. As Tony Li stated at the

> > last IETF (paraphrasing):

> >

> >

> >

> > “This isn’t great – but it’s the best we can do.”

> >

> >

> >

> > As to why this particular problem is not amenable, it is because the

> > content that is being advertised consists of existing sub-TLVs that

> > all nodes in the network are required to process for correct

> > operation. There isn’t some information which is “old” and some

> > information which is “new”. It is all “old” – there is just more of

> > it.

> >

> >

> >

> > I honestly thought we had gotten past this point with our discussions

> > (both in the WG and some post WG 1-1 discussions) at IETF 117. But

> > now you have raised this point again.

> >

> > I share your angst, but there is an undeniable deployment need to

> > advertise more than 255 bytes per object – so we need to move

> > forward.

> >

> >

> >

> >Les

> >

> >

> >

> >

> >

> >

> >

> >

> >

> >


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-pkaneria-lsr-multi-tlv and "backwards compatibility"

[Christian Hopps]

My point is that people are not using the same definition of backward compatibility. This 
is why this argument over it is going in circles. I'm suggesting that when you consider 
each persons definition of backward compatibility, then neither side is wrong. So saying 
things like "No. You are wrong" etc, is not helpful to moving things forward.

In both cases, when you actually need multi-part-tlv, you have to deploy the new software 
to all the routers that will use it; however the multi-part-tlv draft allows for a messy 
sort of "it still works as long as you don't need multi-part-tlv on routers that 
don't understand it" operation. So you hand craft your software deployment to match 
your network config to make that work.

The Big TLV solution does not allow for this "messy but functioning 
deployment", and this is why I believe people prefer the multi-part TLV solution. 
That should be enough to move things forward IMO.

Thanks,
Chris.
[wg-member]

"Les Ginsberg (ginsberg)"  writes:


Chris (and everyone) -



A more complete response to your comments regarding "backwards
compatibility", routing loops, etc.



It is absolutely true that until all nodes in the network support
advertisement (meaning at least receive processing) of more than 255
bytes for a given object, that any attempt to deploy a configuration
which requires the advertisement of more than 255 bytes for that
object is likely to result in some type of failure.

That failure could manifest itself as routing loops or blackholes or
in other ways. This is explicitly stated in https://www.ietf.org/
archive/id/draft-pkaneria-lsr-multi-tlv-04.html#
name-deployment-considerations :



“Sending of MP-TLVs in the presence of nodes which do not correctly
process such advertisements can result in interoperability issues,
including incorrect forwarding of packets.”



No one has ever tried to state otherwise.



But it is also true that encodings other than MP suffer from the same
limitation. The authors of Big-TLV try to claim otherwise, but this
does not stand up to scrutiny – see my replies to Huaimo for more
details as to why.



Would it be great if we could find a way to allow “incremental
deployment”? Sure – but it isn’t possible. As Tony Li stated at the
last IETF (paraphrasing):



“This isn’t great – but it’s the best we can do.”



As to why this particular problem is not amenable, it is because the
content that is being advertised consists of existing sub-TLVs that
all nodes in the network are required to process for correct
operation. There isn’t some information which is “old” and some
information which is “new”. It is all “old” – there is just more of
it.



I honestly thought we had gotten past this point with our discussions
(both in the WG and some post WG 1-1 discussions) at IETF 117. But
now you have raised this point again.

I share your angst, but there is an undeniable deployment need to
advertise more than 255 bytes per object – so we need to move
forward.



   Les












___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] draft-pkaneria-lsr-multi-tlv and "backwards compatibility"

[Les Ginsberg (ginsberg)]

Chris (and everyone) -



A more complete response to your comments regarding "backwards compatibility", 
routing loops, etc.



It is absolutely true that until all nodes in the network support advertisement 
(meaning at least receive processing) of more than 255 bytes for a given 
object, that any attempt to deploy a configuration which requires the 
advertisement of more than 255 bytes for that object is likely to result in 
some type of failure.

That failure could manifest itself as routing loops or blackholes or in other 
ways. This is explicitly stated in 
https://www.ietf.org/archive/id/draft-pkaneria-lsr-multi-tlv-04.html#name-deployment-considerations
 :



“Sending of MP-TLVs in the presence of nodes which do not correctly process 
such advertisements can result in interoperability issues, including incorrect 
forwarding of packets.”



No one has ever tried to state otherwise.



But it is also true that encodings other than MP suffer from the same 
limitation. The authors of Big-TLV try to claim otherwise, but this does not 
stand up to scrutiny – see my replies to Huaimo for more details as to why.



Would it be great if we could find a way to allow “incremental deployment”? 
Sure – but it isn’t possible. As Tony Li stated at the last IETF (paraphrasing):



“This isn’t great – but it’s the best we can do.”



As to why this particular problem is not amenable, it is because the content 
that is being advertised consists of existing sub-TLVs that all nodes in the 
network are required to process for correct operation. There isn’t some 
information which is “old” and some information which is “new”. It is all “old” 
– there is just more of it.



I honestly thought we had gotten past this point with our discussions (both in 
the WG and some post WG 1-1 discussions) at IETF 117. But now you have raised 
this point again.

I share your angst, but there is an undeniable deployment need to advertise 
more than 255 bytes per object – so we need to move forward.



   Les










___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr