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

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Wed, 2 Mar 2022 06:23:18 +0000

Hi Tony,

Interesting write-up. The proposal seems more operation friendly at first sight as the alternate solutions.

A while ago I was bumping into limitation of advertising a flex-algo FAD, and realized that only one is allowed and more seem to be forbidden by the draft https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo#section-5.1

   The IS-IS FAD Sub-TLV MAY be advertised in an LSP of any number, but
   a router MUST NOT advertise more than one IS-IS FAD Sub-TLV for a
   given Flexible-Algorithm.  A router receiving multiple IS-IS FAD Sub-
   TLVs for a given Flexible-Algorithm from the same originator MUST
   select the first advertisement in the lowest numbered LSP.

Is draft-pkaneria-lsr-multi-tlv intending to look TLVs that are explicitly restricted to only a single entry?

G/

From: Lsr <[email-masked]> On Behalf Of Tony Li
Sent: Saturday, January 22, 2022 1:57 AM
To: lsr <[email-masked]>
Subject: [Lsr] Fwd: New Version Notification for draft-pkaneria-lsr-multi-tlv-00.txt

Hi all,

This draft attempts to codify existing practice. If you run out of space in a TLV, generate another TLV of the same type and continue. Ditto sub-TLVs and sub-sub-TLVs.

Comments welcome.

T

Begin forwarded message:

From: [email-masked]<mailto:[email-masked]>
Subject: New Version Notification for draft-pkaneria-lsr-multi-tlv-00.txt
Date: January 21, 2022 at 4:55:01 PM PST
To: <[email-masked]<mailto:[email-masked]>>, "Chris Bowers" <[email-masked]<mailto:[email-masked]>>, "Les Ginsberg" <[email-masked]<mailto:[email-masked]>>, "Parag Kaneriya" <[email-masked]<mailto:[email-masked]>>, "Shraddha Hegde" <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, "Tony Li" <[email-masked]<mailto:[email-masked]>>, "Tony Przygienda" <[email-masked]<mailto:[email-masked]>>

A new version of I-D, draft-pkaneria-lsr-multi-tlv-00.txt
has been successfully submitted by Tony Li, and posted to the
IETF repository.

Name:                  draft-pkaneria-lsr-multi-tlv
Revision:              00
Title:                      Multiple TLV Instances in IS-IS
Document date:               2022-01-21
Group:                  Individual Submission
Pages:                   7
URL:            https://www.ietf.org/archive/id/draft-pkaneria-lsr-multi-tlv-00.txt
Status:         https://datatracker.ietf.org/doc/draft-pkaneria-lsr-multi-tlv/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-pkaneria-lsr-multi-tlv

Abstract:
  Emerging technologies are adding information into IS-IS TLVs at a
  steady pace while deployment scales are simultaneously increasing.
  This causes the contents of many critical TLVs to exceed the
  currently supported limit of 255 octets.  Extensions such as
  [RFC7356] require significant IS-IS changes that could help address
  the problem, but a less drastic solution would be beneficial.  This
  document codifies the common mechanism of extending the TLV space
  through multiple TLV instances.

The IETF Secretariat

---

From: Peter Psenak <[email-masked]>
Date: Wed, 2 Mar 2022 08:39:55 +0100

Gunter,

I'm afraid you are mixing two different things.

Flex-algo draft limits the FAD advertisement for a SINGLE algo to one on 
any originator.

It DOES NOT limit in any way how many FADs for DIFFERENT algos any 
originator can send.

There are implementations that already support more FADs than can fit in 
a single TLV-242, in which case FADs are sent in multiple of them.

thanks,
Peter

On 02/03/2022 07:23, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:
> A while ago I was bumping into limitation of advertising a flex-algo 
> FAD, and realized that only one is allowed and more seem to be forbidden 
> by the draft 
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo#section-5.1 
> <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo#section-5.1>
> 
> Is draft-pkaneria-lsr-multi-tlv intending to look TLVs that are 
> explicitly restricted to only a single entry?
> 
> G/
> 
> *From:*Lsr <[email-masked]> *On Behalf Of *Tony Li
> *Sent:* Saturday, January 22, 2022 1:57 AM
> *To:* lsr <[email-masked]>
> *Subject:* [Lsr] Fwd: New Version Notification for 
> draft-pkaneria-lsr-multi-tlv-00.txt
> 
> Hi all,
> 
> This draft attempts to codify existing practice. If you run out of space 
> in a TLV, generate another TLV of the same type and continue. Ditto 
> sub-TLVs and sub-sub-TLVs.
> 
> Comments welcome.
> 
> T
> 
> 
> 
>     Begin forwarded message:
> 
>     *From: [email-masked] <mailto:[email-masked]>
> 
>     *Subject: New Version Notification for
>     draft-pkaneria-lsr-multi-tlv-00.txt*
> 
>     *Date: *January 21, 2022 at 4:55:01 PM PST
> 
>     *To: *<[email-masked] <mailto:[email-masked]>>, "Chris
>     Bowers" <[email-masked] <mailto:[email-masked]>>, "Les
>     Ginsberg" <[email-masked] <mailto:[email-masked]>>, "Parag
>     Kaneriya" <[email-masked] <mailto:[email-masked]>>,
>     "Shraddha Hegde" <[email-masked]
>     <mailto:[email-masked]>>, <[email-masked]
>     <mailto:[email-masked]>>, "Tony Li" <[email-masked]
>     <mailto:[email-masked]>>, "Tony Przygienda" <[email-masked]
>     <mailto:[email-masked]>>
> 
> 
>     Name:draft-pkaneria-lsr-multi-tlv
>     Revision:00
>     Title:Multiple TLV Instances in IS-IS
>     Document date:2022-01-21
>     Group:Individual Submission
>     Pages:7
>     URL:
>     https://www.ietf.org/archive/id/draft-pkaneria-lsr-multi-tlv-00.txt
>     <https://www.ietf.org/archive/id/draft-pkaneria-lsr-multi-tlv-00.txt>
>     Status:
>     https://datatracker.ietf.org/doc/draft-pkaneria-lsr-multi-tlv/
>     <https://datatracker.ietf.org/doc/draft-pkaneria-lsr-multi-tlv/>
>     Htmlized:
>     https://datatracker.ietf.org/doc/html/draft-pkaneria-lsr-multi-tlv
>     <https://datatracker.ietf.org/doc/html/draft-pkaneria-lsr-multi-tlv>
> 
> 
>     Abstract:

---

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Wed, 2 Mar 2022 09:02:48 +0000

My point to Tony was that there may be subTLVs out there that normative prescribe a restriction that only a single occurrence may exist. For flex-algo that is exactly one FAD for each algorithm.

Coming back to flex-algo FAD. It is indeed easy to mix things up sometimes, however this time maybe I am not?

I believe that your assumption is that the FAD for a single algorithm can never grow bigger as a 256 octets.
While that is a realistic and pragmatic assumption, it may not necessary be 100% correct in all use-cases.

What if the FAD use SRLGs? Each of these SRLGs are big (4 octets) in size and will consume significant subTLV space resources and many of those may overrun the size of the FAD. So if we have a theoretical network with a theoretical use-case that wants to exclude, lets say 64, SRLGs, then how would that fit into a single FAD for a single algorithm?

Anyway, my point was that draft-pkaneria-lsr-multi-tlv may benefit to call-out subTLVs that by normative reference can only exist one time, in one place, like for example the flex-algo FAD.

G/

-----Original Message-----
From: Peter Psenak <[email-masked]> 
Sent: Wednesday, March 2, 2022 8:40 AM
To: Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]>; Tony Li <[email-masked]>; lsr <[email-masked]>
Subject: Re: [Lsr] Fwd: New Version Notification for draft-pkaneria-lsr-multi-tlv-00.txt

Gunter,

Flex-algo draft limits the FAD advertisement for a SINGLE algo to one on any originator.

It DOES NOT limit in any way how many FADs for DIFFERENT algos any originator can send.

There are implementations that already support more FADs than can fit in a single TLV-242, in which case FADs are sent in multiple of them.

thanks,
Peter

On 02/03/2022 07:23, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:
> FAD, and realized that only one is allowed and more seem to be 
> forbidden by the draft
> This draft attempts to codify existing practice. If you run out of 
> space in a TLV, generate another TLV of the same type and continue. 
> Ditto sub-TLVs and sub-sub-TLVs.
> 
> Comments welcome.
> 
> T
> 
> 
> 
>     Begin forwarded message:
>

---

From: Peter Psenak <[email-masked]>
Date: Wed, 2 Mar 2022 10:10:41 +0100

Gunter,

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

> While that is a realistic and pragmatic assumption, it may not necessary be 100% correct in all use-cases.

true.

> What if the FAD use SRLGs? Each of these SRLGs are big (4 octets) in size and will consume significant subTLV space resources and many of those may overrun the size of the FAD. So if we have a theo…

you would not be able to do that. Realistically, it looks like an 
academical problem to me.

> Anyway, my point was that draft-pkaneria-lsr-multi-tlv may benefit to call-out subTLVs that by normative reference can only exist one time, in one place, like for example the flex-algo FAD.

I don't believe draft-pkaneria-lsr-multi-tlv should go into business of 
specifying the restriction of any particular Sub-TLVs. These 
restrictions are specific to Sub-TLV itself and should be covered by the 
specification that defines the Sub-TLV.

thanks,
Peter

> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>

---

From: Tony Li <[email-masked]>
Date: Wed, 2 Mar 2022 07:15:02 -0800

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

What we are attempting to do is to cover cases where no explicit restriction has been stated, plus define a default behavior for how multiple TLVs should be handled by all implementations.

Tony

---

From: Tony Li <[email-masked]>
Date: Wed, 2 Mar 2022 07:22:20 -0800

Hi Peter,

> 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 yet or not.

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.

> you would not be able to do that. Realistically, it looks like an academical problem to me.

Actually, what’s academic is your objection. Implementations are going to handle overflows and they will do it by generating multiple sub-TLVs. The problem is not going to go away just because you deny that it exists.

> I don't believe draft-pkaneria-lsr-multi-tlv should go into business of specifying the restriction of any particular Sub-TLVs. These restrictions are specific to Sub-TLV itself and should be covered by the specification that defines the Sub-TLV.

Except that many things didn’t define how they can and should be extended. Admittedly, that’s a bug in those specifications that we’re attempting to address.

Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 2 Mar 2022 17:47:53 +0000

Gunter -

In regards to:

> Anyway, my point was that draft-pkaneria-lsr-multi-tlv may benefit to call-
> out subTLVs that by normative reference can only exist one time, in one
> place, like for example the flex-algo FAD.
>

I believe this is out of scope for draft-pkaneria-lsr-multi-tlv.
As clearly stated in the draft, the goal is:

"The intent of this document is to clarify the situation by explicitly defining the use of multiple instances of TLVs as the mechanism for scaling TLV contents, except where explicitly prohibited."

Any issues specific to a particular TLV/sub-TLV codepoint are out of scope and should be addressed (if need be) in the document which defines the code point.

   Les

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 2 Mar 2022 20:23:43 +0100

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 bit of a different view on this one.

If we keep networks simple (which is what IMHO we should do) I don't see
that we are any close to exceeding FAD limits as per today's encoding.

Now if on the other hand we load tons of application awareness into the
network and flatten all of this to the IGP transport layer - sure you are
right. That limit and what's worse today's REs CPU and RAM capacity will be
off limits. But do we really want this ? Would you call this a FlexAlgo
success ?

Isn't it better to keep all of the smartness as the overlay ? After all,
wherever you look around everything is transported encapsulated already.

Thx,
Robert

---

From: Tony Li <[email-masked]>
Date: Wed, 2 Mar 2022 11:30:08 -0800

Robert,

> If we keep networks simple (which is what IMHO we should do) I don't see that we are any close to exceeding FAD limits as per today's encoding. 
> 
> Now if on the other hand we load tons of application awareness into the network and flatten all of this to the IGP transport layer - sure you are right. That limit and what's worse today's REs CPU and RAM capacity will be off limits. But do we really want this ? Would you call this a FlexAlgo success ? 
> 
> Isn't it better to keep all of the smartness as the overlay ? After all, wherever you look around everything is transported encapsulated already. 

I believe that I am the loudest voice asking people to not use the IGP as a dump truck. Unfortunately, I don’t believe that message resonates with people. As a result, we see people overburdening protocols when we need new subsystems. 

So yes, I would like us to not add more complexity to the IGP. But I expect that we will. And when we do, it would be best if our implementations didn’t implode.

Tony

---

From: Peter Psenak <[email-masked]>
Date: Thu, 3 Mar 2022 15:56:34 +0100

Hi Tony, Gunter,

> 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…

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 flex-algo 
draft accordingly.

b) Gunter says that a particular Sub-TLV of the FAD Sub-TLV, on its own, 
may not fit into a single FAD Sub-TLV. Although theoretically possible 
(with SRLGs only for now, I believe), I don't feel like it's very realistic.

I agree to address (a),  not very enthusiastic about addressing (b).

Please let me know what do you think.

thanks,
Peter

---

From: Tony Li <[email-masked]>
Date: Thu, 3 Mar 2022 07:06:52 -0800

Peter,

> 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 flex-algo draft accordingly.
> 
> b) Gunter says that a particular Sub-TLV of the FAD Sub-TLV, on its own, may not fit into a single FAD Sub-TLV. Although theoretically possible (with SRLGs only for now, I believe), I don't feel like it's very realistic.
> 

Thank you for bringing out that distinction. Yes, that’s accurate and an important distinction that I had completely missed. 

I think that both issues are worth addressing. I am thrilled that you’re willing to address (a). 

On (b), I agree that it’s an issue and one that is unlikely to be seen in practice. Still, someone has to write code. As my friend Fletch has always said: “The programmer has to fill in that else clause.” So I would like to encourage you to address it as well. Yes, I realize that it’s no fun, but it does deserve to be written down. Please feel free to borrow language from the multi-tlv draft. :)

Regards,
Tony

---

From: Peter Psenak <[email-masked]>
Date: Fri, 4 Mar 2022 09:28:38 +0100

Tony,

On 03/03/2022 16:06, Tony Li wrote:
> On (b), I agree that it’s an issue and one that is unlikely to be seen in practice. Still, someone has to write code. As my friend Fletch has always said: “The programmer has to fill in that else clause.” 

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 occurrence in the lowest numbered LSP from a given 
source MUST be preferred.

Above does not support the "merge" of the values from multiple FAD 
sub-TLVs, but as we all agree that is unlikely a requirement.

thanks,
Peter

So I would like to encourage you to address it as well. Yes, I realize 
that it’s no fun, but it does deserve to be written down. Please feel 
free to borrow language from the multi-tlv draft. :)

---

From: Tony Li <[email-masked]>
Date: Fri, 4 Mar 2022 08:36:21 -0800

Hi Peter,

> 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 occurrence in the lowest numbered LSP from a given source MUST be preferred.
> 
> 
> Above does not support the "merge" of the values from multiple FAD sub-TLVs, but as we all agree that is unlikely a requirement.

So, you’re in favor of mandating that FlexAlgo has fixed limitations on the scale and complexity of its definitions?

Will you be taking the phone calls from our irate customers?  

Tony

---

From: Peter Psenak <[email-masked]>
Date: Fri, 4 Mar 2022 17:50:51 +0100

Hi Tony,

On 04/03/2022 17:36, Tony Li wrote:
>> sub-TLV in the first occurrence in the lowest numbered LSP from a 
>> given source MUST be preferred.
>>
>>
> So, you’re in favor of mandating that FlexAlgo has fixed limitations on 
> the scale and complexity of its definitions?

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 FAD does not seem like a realistic case to me.

thanks,
Peter

---

From: Tony Li <[email-masked]>
Date: Fri, 4 Mar 2022 08:53:34 -0800

> On Mar 4, 2022, at 8:50 AM, Peter Psenak <[email-masked]> 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 FAD does not seem like a realistic case to me.

Then how do we deal with subTLV overflow?

T

---

From: Peter Psenak <[email-masked]>
Date: Fri, 4 Mar 2022 18:06:51 +0100

Tony,

On 04/03/2022 17:53, Tony Li wrote:
> 
> 
>> On Mar 4, 2022, at 8:50 AM, Peter Psenak <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> not at all.
>>
>> do so? So far I have not seen any. Asking for 100s of excluded SRLGs 
>> in the FAD does not seem like a realistic case to me.
> 
> 

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 with adding extra complexity, but at least I would like to see 
some practical use case behind it.

thanks,
Peter

---

From: Tony Li <[email-masked]>
Date: Fri, 4 Mar 2022 09:30:31 -0800

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 with adding extra complexity, but at least I would like to see some practical use case behind it.

We are defining a mechanism right now that we would like to have be functional in perpetuity. We should not wait to redefine it when a P1 case comes in or when we get a billion dollar RFP.

Right now, we have the following subsubTLVs in the FlexAlgo draft:

	Exclude Admin Group Sub-TLV
    Include-Any Admin Group Sub-TLV
    Include-All Admin Group Sub-TLV
    Flags Sub-TLV
    Exclude SRLG Sub-TLV

We can and should expect more in the future.  We cannot predict how many octets the future subsubTLVs will hold.

Each of the Admin Group subsubTLVs can hold an extended admin group. There is no hard bound to the number of bits 
in the extended admin group and thus each subsubTLV could, theoretically, fill the FAD subTLV. Obviously, the
combination of multiple ones could as well.

The flags subsubTLV is only one octet of contents today, but is also unbounded.

And the SRLG subsubTLV is, as noted, unbounded.

I submit that we are already in the overflow business, right now, and that not specifying how to deal with overflow is an egregious 
under-specification of the mechanism and a disservice to all of our implementors.

Tony

---

From: Peter Psenak <[email-masked]>
Date: Fri, 4 Mar 2022 18:47:15 +0100

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 candidate for multiple.
>>
> We are defining a mechanism right now that we would like to have be 
> functional in perpetuity. We should not wait to redefine it when a P1 
> case comes in or when we get a billion dollar RFP.
> 
> in the extended admin group and thus each subsubTLV could, theoretically, fill the FAD subTLV. 

the single Admin Group sub-TLV allows you to advertise almost 2k groups. 
Let's be realistic, how much more do we need?

> Obviously, the combination of multiple ones could as well.

the combination is the (a) problem and that will be fixed. We are 
talking problem (b) only now.

> The flags subsubTLV is only one octet of contents today, but is also unbounded.

same as with admin groups, we have more then enough flags in a single 
sub-TLV.

> And the SRLG subsubTLV is, as noted, unbounded.

yes, but it's a theoretical problem IMHO.

> under-specification of the mechanism and a disservice to all of our implementors.

I'm not trying under-specify how to deal with overflow - we need to 
specify it, no disagreement there.

What I'm trying to see of we need to support the "merge" at FAD sub-TLV 
level.

thanks,
Peter

---

From: Tony Li <[email-masked]>
Date: Fri, 4 Mar 2022 10:03:14 -0800

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 look forward to seeing a proposal. I propose allowing multiple FAD and concatenation of the contents.

> What I'm trying to see of we need to support the "merge" at FAD sub-TLV level.

I’ll agree that that’s lower priority.  I think we should, as a matter of completeness.

Tony

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 9 Mar 2022 23:05:20 -0500

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 3 different ASLA apps if used on the
same link.

For SR-MPLS, SR forwarding plane you could use RSVP-TE SRLG protection or
SR-TE protection schemes.

I don’t think the RSVP-TE FRR SRLG protection would apply to SR-TE
protection to use the concept of SRLG  with SR-MPLS with Flex Algo or would
it apply.

Kind Regards

Gyan

-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Fri, 11 Mar 2022 09:48:42 +0000

Hi Gyan,

I was talking about the use-case where we create two flex-algo’s and the desire is that they for example avoid congruent optical paths to avoid that a single fiber cut, would impact both streams. For some high value live-live streams or financials this may be an important service property. This type of flex-algo capability was a use-case about 1.5 a 2 years ago and caused the flex-algo to add exclude-srlg into the FAD to support such use-case.

The use-case was not about FRR, or RSVP-TE or anything similar. Advertising link properties is taken care of by the legacy and ASLA TE IGP attributes.  The requested ‘avoid congruent optical paths’ use-case added the exclude-srlg subTLV within the flex-algo FAD, but unlike the EAG, the SRLG can theoretically cause overflow of 255 octet subTLV under certain (mostly theoretical) circumstance.

I am in full agreement with Peter, that excluding 100s of SRLG is a something we will unlikely encounter, but then again, I see sometimes mythical oddness in use-case requests and I can not predict what requests future will bring. I am not asking for bigger or multiple SRLG subTLVs, but hope to find guidance to have implementation X behave identical/similar as implementation Y when such condition occurs.

G/

From: Gyan Mishra <[email-masked]>
Sent: Thursday, March 10, 2022 5:05 AM
To: Tony Li <[email-masked]>
Cc: Peter Psenak <[email-masked]>; Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]>; lsr <[email-masked]>
Subject: 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 3 different ASLA apps if used on the same link.

For SR-MPLS, SR forwarding plane you could use RSVP-TE SRLG protection or SR-TE protection schemes.

I don’t think the RSVP-TE FRR SRLG protection would apply to SR-TE protection to use the concept of SRLG  with SR-MPLS with Flex Algo or would it apply.

Kind Regards

Gyan

On Fri, Mar 4, 2022 at 1:03 PM Tony Li <[email-masked]<mailto:[email-masked]>> wrote:

Peter,

Tony

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr
--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 11 Mar 2022 16:55:41 -0500

Hi Gunter

Understood.  Thanks for the explanation.

I agree it is difficult to design for every overflow condition, however it
is difficult to predict future requests that may arise.  I agree we should
find a common ground would work for all implementations.

Kind Regards

Gyan

On Fri, Mar 11, 2022 at 4:48 AM Van De Velde, Gunter (Nokia - BE/Antwerp) <
[email-masked]> wrote:

> Hi Gyan,
>
>
>
> I was talking about the use-case where we create two flex-algo’s and the
> desire is that they for example avoid congruent optical paths to avoid that
> a single fiber cut, would impact both streams. For some high value
> live-live streams or financials this may be an important service property.
> This type of flex-algo capability was a use-case about 1.5 a 2 years ago
> and caused the flex-algo to add exclude-srlg into the FAD to support such
> use-case.
>
>
>
> The use-case was not about FRR, or RSVP-TE or anything similar.
> Advertising link properties is taken care of by the legacy and ASLA TE IGP
> attributes.  The requested ‘avoid congruent optical paths’ use-case added
> the exclude-srlg subTLV within the flex-algo FAD, but unlike the EAG, the
> SRLG can theoretically cause overflow of 255 octet subTLV under certain
> (mostly theoretical) circumstance.
>
>
>
> I am in full agreement with Peter, that excluding 100s of SRLG is a
> something we will unlikely encounter, but then again, I see sometimes
> mythical oddness in use-case requests and I can not predict what requests
> future will bring. I am not asking for bigger or multiple SRLG subTLVs, but
> hope to find guidance to have implementation X behave identical/similar as
> implementation Y when such condition occurs.
>
>
>
> G/
>
>
>
> *From:* Gyan Mishra <[email-masked]>
> *Sent:* Thursday, March 10, 2022 5:05 AM
> *To:* Tony Li <[email-masked]>
> *Cc:* Peter Psenak <[email-masked]>; Van De Velde, Gunter (Nokia -
> BE/Antwerp) <[email-masked]>; lsr <[email-masked]>
> *Subject:* Re: [Lsr] New Version Notification for
> *Network Solutions Architect *
>
-- 

*Gyan Mishra*

*M 301 502-1347*