Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-00.txt

on occurs. > > > > G/ > > > > *From:* Gyan Mishra > *Sent:* Thursday, March 10, 2022 5:05 AM > *To:* Tony Li > *Cc:* Peter Psenak ; Van De Velde, Gunter (Nokia - > BE/Antwerp) ; lsr > *Subject:* Re: [Lsr] New Version Notification for > draft-pkaneri

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-00.txt

implementation X behave identical/similar as implementation Y when such condition occurs. G/ From: Gyan Mishra Sent: Thursday, March 10, 2022 5:05 AM To: Tony Li Cc: Peter Psenak ; Van De Velde, Gunter (Nokia - BE/Antwerp) ; lsr Subject: Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-00.txt

Gunter The use case for SRLG is only related to RSVP-TE FRR protection is my understanding. However, Flex Algo is only applicable to SR forwarding plane SR-MPLS and SRv6? Correct? RSVP-TE FRR SRLG protection application can be used in parallel to SR-MPLS or SRv6 but in that case they would be

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-00.txt

Peter, > the combination is the (a) problem and that will be fixed. We are talking > problem (b) only now. Ah, my apologies, I was unclear on the applicability of your statements. > I'm not trying under-specify how to deal with overflow - we need to specify > it, no disagreement there. I

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-00.txt

Tony, On 04/03/2022 18:30, Tony Li wrote: Peter, Once we get into FAD Sub-TLV overflow business, we would have to define, for each FAD sub-TLV, whether multiple of them can exist and how to resolve conflicts if only one is allowed. For all existing ones, I can only think of SRLG to be the

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-00.txt

Peter, > Once we get into FAD Sub-TLV overflow business, we would have to define, for > each FAD sub-TLV, whether multiple of them can exist and how to resolve > conflicts if only one is allowed. For all existing ones, I can only think of > SRLG to be the candidate for multiple. > > I'm fine

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-00.txt

Tony, On 04/03/2022 17:53, Tony Li wrote: On Mar 4, 2022, at 8:50 AM, Peter Psenak > wrote: not at all. I just don't want to get into business of merging info from several FAD's sub-TLVs of the same type unless there is a compelling reason to do so? So far I

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-00.txt

> On Mar 4, 2022, at 8:50 AM, Peter Psenak wrote: > > not at all. > > I just don't want to get into business of merging info from several FAD's > sub-TLVs of the same type unless there is a compelling reason to do so? So > far I have not seen any. Asking for 100s of excluded SRLGs in the

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-00.txt

Hi Tony, On 04/03/2022 17:36, Tony Li wrote: Hi Peter, I would prefer to address the "else clause"  in a following way: a) any FAD sub-TLV MUST only appear once in a the FAD definition for a given algorithm from a given source b) in case the FAD sub-TLV appear multiple times, the values

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-00.txt

Hi Peter, > I would prefer to address the "else clause" in a following way: > > a) any FAD sub-TLV MUST only appear once in a the FAD definition for a given > algorithm from a given source > > b) in case the FAD sub-TLV appear multiple times, the values in the sub-TLV > in the first

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-00.txt

Tony, On 03/03/2022 16:06, Tony Li wrote: Peter, I believe there is a subtle difference between what each of you is saying: a) Tony says that there may be many constraints used for a particular flex-algo, so that we may not be able to fit them in a single FAD Sub-TLV. I agree, we better

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-00.txt

Peter, > I believe there is a subtle difference between what each of you is saying: > > a) Tony says that there may be many constraints used for a particular > flex-algo, so that we may not be able to fit them in a single FAD Sub-TLV. I > agree, we better address that. I will update the

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-00.txt

Hi Tony, Gunter, On 02/03/2022 16:22, Tony Li wrote: Hi Peter, I believe that your assumption is that the FAD for a single algorithm can never grow bigger as a 256 octets. yes, that is indeed a limitation. Perhaps we should address it somehow? Coders have to deal with overflow

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-00.txt

Robert, > If FlexAlgo is adopted, then we should expect that it will get stressed and > that further conditions will be added to a FAD. The problem will only become > worse the more success that FlexAlgo has. It sounds to me like you want > FlexAlgo to fail, which seems strange. > > Well I

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-00.txt

Hi Tony, > If FlexAlgo is adopted, then we should expect that it will get stressed > and that further conditions will be added to a FAD. The problem will only > become worse the more success that FlexAlgo has. It sounds to me like you > want FlexAlgo to fail, which seems strange. Well I have a

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-00.txt

Hi Peter, >> I believe that your assumption is that the FAD for a single algorithm can >> never grow bigger as a 256 octets. > > yes, that is indeed a limitation. Perhaps we should address it somehow? Coders have to deal with overflow conditions on day one, whether people are hitting them

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-00.txt

Hi Gunter, > Is draft-pkaneria-lsr-multi-tlv intending to look TLVs that are explicitly > restricted to only a single entry? Usually, if a TLV has been defined to only have a single entry, it’s for a good reason. We are not intending to override an author’s explicit and sensible