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

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:

Re: [Lsr] 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

Re: [Lsr] 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;

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

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

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

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

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

roposal) 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-mult

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

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

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

: [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 thi

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. https://www.ietf.org/archive/id/draft-pkaneria-lsr-multi-tlv-04.html#name-deployment-considerations recommends: *

Re: [Lsr] 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

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

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