Subject: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID Advertisement"

From: Christian Hopps <[email-masked]>
Date: Wed, 26 May 2021 16:56:42 -0400

Hi Folks,

This begins a 2 week WG Adoption Call for the following draft:

https://datatracker.ietf.org/doc/draft-peng-lsr-algorithm-related-adjacency-sid/

Please indicate your support or objections by June 9th, 2021

Authors, please respond to the list indicating whether you are aware of any IPR that applies to this draft.

Thanks,
Acee and Chris.

---

From: Peter Psenak <[email-masked]>
Date: Thu, 27 May 2021 10:20:36 +0200

Hi Acee and Chris,

I'm not aware of any undisclosed IPR related to this draft.

thanks,
Peter

On 26/05/2021 22:56, Christian Hopps wrote:
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
> 
>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 27 May 2021 13:27:12 +0000

Hello All,

I am not aware of any IPR associated with this document.

Thanks,
Ketan

-----Original Message-----
From: Lsr <[email-masked]> On Behalf Of Christian Hopps
Sent: 27 May 2021 02:27
To: [email-masked]
Cc: [email-masked]
Subject: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID Advertisement"

Hi Folks,

Thanks,
Acee and Chris.

---

From: <[email-masked]>
Date: Fri, 28 May 2021 11:30:35 +0800 (CST)

Hi Acee and Chris,

Support the adoption as co-author. 
And I'm not aware of any undisclosed IPR related to this draft.

Regards,
PSF

------------------原始邮件------------------
发件人：ChristianHopps
收件人：[email-masked];
抄送人：[email-masked];
日 期 ：2021年05月27日 05:00
主 题 ：[Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID Advertisement"

Hi Folks,

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 28 May 2021 03:39:48 +0000

Hi,

I don't support the adoption of this document. 

It seems this document aims to introduce per Flex-Algo Adj-SID to SR-MPLS, its typical use case is to provide protection path with Flex-Algo constraints for Adj-SID of a particular Flex-Algo, which is described in the case 3 of section 3. 

However, section 3 and section 5 shows that it also aims to introduce further changes to the usage and operation of Flex-Algo, which is to provide resource reservation based on Flex-Algo. IMO these changes to Flex-Algo deserves further discussion and is not only related to the per Flex-Algo Adj-SID extension.

Here are some comments about this change to Flex-Algo:

1. Flex-Algo defines the constraints for path computation in a distributed manner, it is not for resource reservation. 

2. Reserving resources for each Flex-Algo on a link does not make sense. The correlation between Flex-Algo and the network links is based on administrative groups (color), and the color of the link may or may not be included in the Flex-Algo definition. To follow the color based link correlation, a more practical approach would be to use Flex-Algo with L2 bundle as defined in draft-zhu-lsr-isis-sr-vtn-flexalgo, which uses color to correlate the L3 link and the L2 member link to a Flex-Algo, this avoids the extension for per-FlexAlgo resource reservation. 

3. The Flex-Algo link TE attributes are advertised using ASLA, the TE attributes are shared by all Flex-Algos which include the link according to the FAD, and based on previous discussion, it seems there is no intention to introduce per Flex-Algo ID link attributes.

Best regards,
Jie

> From: Lsr [mailto:[email-masked]] On Behalf Of Christian Hopps
> Sent: Thursday, May 27, 2021 4:57 AM
> To: [email-masked]
> Cc: [email-masked]

---

From: <[email-masked]>
Date: Fri, 28 May 2021 11:59:58 +0800 (CST)

Hi Jie,

Thanks for your comments.

In this document, there are not any extensions to describe resource reservation per algo. Are you aiming at another draft (https://datatracker.ietf.org/doc/draft-cp-lsr-fa-aware-te/) ?  Please find out what you are talking about first.
Adj-SID per algo can distinguish traffic behavior in local. You are welcome to add more usecases based on section 3.

Regards,
PSF

------------------原始邮件------------------
发件人：Dongjie(Jimmy)
收件人：Christian Hopps;[email-masked];
日 期 ：2021年05月28日 11:40
主 题 ：Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID Advertisement"
Hi,
I don't support the adoption of this document.
It seems this document aims to introduce per Flex-Algo Adj-SID to SR-MPLS, its typical use case is to provide protection path with Flex-Algo constraints for Adj-SID of a particular Flex-Algo, which is described in the case 3 of section 3.
However, section 3 and section 5 shows that it also aims to introduce further changes to the usage and operation of Flex-Algo, which is to provide resource reservation based on Flex-Algo. IMO these changes to Flex-Algo deserves further discussion and is not only related to the per Flex-Algo Adj-SID extension.
Here are some comments about this change to Flex-Algo:
1. Flex-Algo defines the constraints for path computation in a distributed manner, it is not for resource reservation.
2. Reserving resources for each Flex-Algo on a link does not make sense. The correlation between Flex-Algo and the network links is based on administrative groups (color), and the color of the link may or may not be included in the Flex-Algo definition. To follow the color based link correlation, a more practical approach would be to use Flex-Algo with L2 bundle as defined in draft-zhu-lsr-isis-sr-vtn-flexalgo, which uses color to correlate the L3 link and the L2 member link to a Flex-Algo, this avoids the extension for per-FlexAlgo resource reservation.
3. The Flex-Algo link TE attributes are advertised using ASLA, the TE attributes are shared by all Flex-Algos which include the link according to the FAD, and based on previous discussion, it seems there is no intention to introduce per Flex-Algo ID link attributes.
Best regards,
Jie

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 28 May 2021 06:24:06 +0000

Hi PSF,

Thanks for your pointer to another document which defines the encodings of per-Algo TE link attributes.

But my comments are related to the text in section 3 and 5 of this document, which describes new use cases and operation of Flex-Algo with per Flex-Algo resource reservation or per Flex-Algo QoS policy on the same link. These require extensions to the function of Flex-Algo, which IMO needs to be discussed and compared with other alternative mechanisms. And as you indicated, there are related encoding extensions proposed in other document, thus it may not be just a local behavior. 

So could you reply to the comments in my previous mail?

Best regards,
Jie

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, May 28, 2021 12:00 PM
> To: Dongjie (Jimmy) <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: Re:[Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency
> SID Advertisement"
> 
> Hi Jie,
> 
> In this document, there are not any extensions to describe resource reservation
> per algo. Are you aiming at another draft
> (https://datatracker.ietf.org/doc/draft-cp-lsr-fa-aware-te/) ?  Please find out
> what you are talking about first.
> It seems this document aims to introduce per Flex-Algo Adj-SID to SR-MPLS, its
> typical use case is to provide protection path with Flex-Algo constraints for
> Adj-SID of a particular Flex-Algo, which is described in the case 3 of section 3.
> However, section 3 and section 5 shows that it also aims to introduce further
> changes to the usage and operation of Flex-Algo, which is to provide resource
> reservation based on Flex-Algo. IMO these changes to Flex-Algo deserves
> further discussion and is not only related to the per Flex-Algo Adj-SID extension.
> 1. Flex-Algo defines the constraints for path computation in a distributed
> manner, it is not for resource reservation.
> 2. Reserving resources for each Flex-Algo on a link does not make sense. The
> correlation between Flex-Algo and the network links is based on administrative
> groups (color), and the color of the link may or may not be included in the
> Flex-Algo definition. To follow the color based link correlation, a more practical
> approach would be to use Flex-Algo with L2 bundle as defined in
> draft-zhu-lsr-isis-sr-vtn-flexalgo, which uses color to correlate the L3 link and
> the L2 member link to a Flex-Algo, this avoids the extension for per-FlexAlgo
> resource reservation.
> 3. The Flex-Algo link TE attributes are advertised using ASLA, the TE attributes
> are shared by all Flex-Algos which include the link according to the FAD, and
> based on previous discussion, it seems there is no intention to introduce per
> Flex-Algo ID link attributes.
> Best regards,
> Jie
> > https://datatracker.ietf.org/doc/draft-peng-lsr-algorithm-related-adja
> > cency-sid
> > /
> >

---

From: Peter Psenak <[email-masked]>
Date: Fri, 28 May 2021 10:10:20 +0200

Hi Jimmy,

please see inline:

> However, section 3 and section 5 shows that it also aims to introduce further changes to the usage and operation of Flex-Algo, which is to provide resource reservation based on Flex-Algo. IMO these…

personally, I consider use case 3 (per algo protected Adj SID) the main 
reason we need this draft.

I don't care much about the other use cases to be honest, but I see no 
reason why an implementation can not associate local resources on a per 
algo basis. Sure, algo is not in the packet, but there are various 
indirect ways of doing that. All local behavior.

> 2. Reserving resources for each Flex-Algo on a link does not make sense. The correlation between Flex-Algo and the network links is based on administrative groups (color), and the color of the link…

"correlation between Flex-Algo and the network links is based on 
administrative groups" - that's one way of doing so. There are others.

> 3. The Flex-Algo link TE attributes are advertised using ASLA, the TE attributes are shared by all Flex-Algos which include the link according to the FAD, and based on previous discussion, it seems…

that's right, but I see no direct relationship with the above.

Anyway, I'm not a big fun of IETF documents describing local behaviors 
which are not needed for interoperability, so keeping these things out 
of the draft would be fine with me.

thanks,
Peter

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 28 May 2021 10:07:19 +0000

Hi Peter,

Thanks for your reply. Please see inline:

> From: Peter Psenak [mailto:[email-masked]]
> Sent: Friday, May 28, 2021 4:10 PM
> To: Dongjie (Jimmy) <[email-masked]>; Christian Hopps
> <[email-masked]>; [email-masked]
> Subject: Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency
> SID Advertisement"
> 
> Hi Jimmy,
> 
> please see inline:
> 
> > It seems this document aims to introduce per Flex-Algo Adj-SID to SR-MPLS,
> its typical use case is to provide protection path with Flex-Algo constraints for
> personally, I consider use case 3 (per algo protected Adj SID) the main reason
> we need this draft.

I share the similar opinion with you. 

> I don't care much about the other use cases to be honest, but I see no reason
> why an implementation can not associate local resources on a per algo basis.
> Sure, algo is not in the packet, but there are various indirect ways of doing that.
> All local behavior.

If all of these are local behavior, IMO they do not need to be described in this draft. 

> administrative groups" - that's one way of doing so. There are others.

OK, my point is Flex-Algo uses link constraints (color, SRLG, bandwidth constraint, etc.) in the FAD to associate it with a set of links, rather than configuring the Flex-Algo ID explicitly on the links. 

> >
> > 3. The Flex-Algo link TE attributes are advertised using ASLA, the TE
> attributes are shared by all Flex-Algos which include the link according to the
> FAD, and based on previous discussion, it seems there is no intention to
> introduce per Flex-Algo ID link attributes.
> 

Thanks for confirming that there is no intention to introduce per Flex-Algo ID link attributes. Taking this and the above item into consideration, I assume the current Flex-Algo model does not support per Flex-Algo ID based queue and bandwidth configuration on a link.

> of the draft would be fine with me.

Agreed, removing those use cases and operation text which are not related to Flex-Algo interoperability would make this document simpler. 

Best regards,
Jie

> >> Subject: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency
> SID
> >> Advertisement"
> >>
> >>
> >> Hi Folks,
> >>
> https://datatracker.ietf.org/doc/draft-peng-lsr-algorithm-related-adjacency-si
> d
> >> /
> >>
> >> Authors, please respond to the list indicating whether you are aware of any
> IPR
> >> that applies to this draft.
> >>
> >> Thanks,
> >> Acee and Chris.
> >>

---

From: Lizhenbin <[email-masked]>
Date: Fri, 28 May 2021 11:08:55 +0000

Hi All,

I do not support the adoption. I am concerned that we are in the danger of re-inventing IGP multi-topology with Flex-Algo. I do not think it is necessary. If we have the requirements, we can either directly use the multi-topology or extend Flex-Algo without change its principle.

Best Regards,
Zhenbin (Robin)

-----Original Message-----
From: Lsr [mailto:[email-masked]] On Behalf Of Christian Hopps
Sent: Thursday, May 27, 2021 4:57 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID Advertisement"

Hi Folks,

Thanks,
Acee and Chris.

---

From: Peter Psenak <[email-masked]>
Date: Sun, 30 May 2021 13:59:10 +0200

Hi Robin,

> I do not support the adoption. I am concerned that we are in the danger of re-inventing IGP multi-topology with Flex-Algo. I do not think it is necessary. If we have the requirements, we can either…

we have absolutely no intention to make flex-algo closer to multi-topology.

The problem we are trying to address with this draft is the protection 
of the Ajd-SID which follows the constraint of the specific flex-algo.

SR policies could use algo specific prefix SIDs, but there is no 
algo-specific Adj-sid. As a result the backup path for the Adj-SID would 
always use an algo 0 path, something that may not be desirable for 
policies that suppose to follow flex-algo paths.

thanks,
Peter

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 30 May 2021 14:59:05 +0200

Hi,

I support WG adoption of this draft.

It seems clear to me that protection for any constrained topology should
use/prefer same constrains if available (with possible fallback to base if
operator wishes so).

Flexible algorithm based topologies should be no exception to this.

And as a side note if using flexible algorithm solves real problems even if
the same problems could be solved with MTR to me this is a feature not a
bug to use simpler technology to accomplish the goal(s).

Cheers,
R.

---

From: <[email-masked]>
Date: Mon, 31 May 2021 09:07:49 +0800 (CST)

Hi Acee and Chris,

I'm not aware of any undisclosed IPR related to this document., and I believe this draft is very useful and support WG adoption as co-author.

Best Regards,

Ran

原始邮件

发件人：ChristianHopps
收件人：[email-masked];
抄送人：[email-masked];
日 期 ：2021年05月27日 05:00

Hi Folks,

 

Thanks,
Acee and Chris.

---

From: <[email-masked]>
Date: Mon, 31 May 2021 09:40:32 +0800 (CST)

Hi Jie,

Thanks. 
Again, in this document we describe local behavior per algorithm thanks to adj-sid per algo, but not describe any resource reservatoin extensions to flex-algo. the later can be discussed in another thread.
IMO the local behavior can be any local policies, such as local repair path, local queue, local priority for entry installation, etc. Adj-sid per algo provides the basis for these local behavior. It is useful to describe how adj-sid per algo can satisfy these usecases, also to facilitate readers to understand its use.

You are very concerned about the extension of resource reservation. Although it is not related to this document and should be discussed in another thread, I will try to answer it in your previous email.

Regards,
PSF

------------------原始邮件------------------
发件人：Dongjie(Jimmy)
收件人：彭少富10053815;
抄送人：[email-masked];[email-masked];
日 期 ：2021年05月28日 14:24
主 题 ：RE: Re:[Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID Advertisement"
Hi PSF,
Thanks for your pointer to another document which defines the encodings of per-Algo TE link attributes.
But my comments are related to the text in section 3 and 5 of this document, which describes new use cases and operation of Flex-Algo with per Flex-Algo resource reservation or per Flex-Algo QoS policy on the same link. These require extensions to the function of Flex-Algo, which IMO needs to be discussed and compared with other alternative mechanisms. And as you indicated, there are related encoding extensions proposed in other document, thus it may not be just a local behavior.
So could you reply to the comments in my previous mail?
Best regards,
Jie

---

From: <[email-masked]>
Date: Mon, 31 May 2021 10:44:15 +0800 (CST)

Hi Jie,

See in-line [PSF], for resource reservation topic.

Regards,

PSF

原始邮件

发件人：Dongjie(Jimmy)

Hi,

 

1. Flex-Algo defines the constraints for path computation in a distributed manner, it is not for resource reservation.  
 [PSF] Not sure. If you look at it from a device point of view, that's OK. But if you look at it from the controller's point of view, the controller can centrally compute an SR-TE path in the flex-algo plane, and  maintain the resource reservation. This document actually introduce nothing to the distributed shortest path computation in the devices, instead, it is used for centralized traffic engineering path computation.

[PSF] To let each flex-algo monopolize its own link resources (here do you think resources per algo is introduced?) may have scalability issues. However, it is actually a possible way. Under this way, I really don't understand the difference between the draft draft-zhu-lsr-isis-sr-vtn-flexalgo you mentioned and draft-peng-lsr-flex-algo-l2bundles. IMO, draft-zhu-lsr-isis-sr-vtn-flexalgo repackaged a VTN concept on the basis of draft-peng-lsr-flex-algo-l2bundles. Both of them need further discussion in another thread and are not recommended to be expanded here.

3. The Flex-Algo link TE attributes are advertised using ASLA, the TE attributes are shared by all Flex-Algos which include the link according to the FAD, and based on previous discussion, it seems there is no intention to introduce per Flex-Algo ID link attributes.
 [PSF] Extend IGP to advertise resources per algorithm is optional, and need more discussions. Other ways are possible, e.g, configuration.

Best regards,
Jie

---

From: <[email-masked]>
Date: Mon, 31 May 2021 10:51:35 +0800 (CST)

Sorry, the body of the message seems to be encrypted. Just resend it.

Hi Jie,

Regards,
PSF
发件人：Dongjie(Jimmy)

Best regards,
Jie

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 31 May 2021 09:33:17 +0000

Hi PSF, 

Please see inline:

> Sent: Monday, May 31, 2021 9:41 AM
> Again, in this document we describe local behavior per algorithm thanks to
> adj-sid per algo, but not describe any resource reservatoin extensions to
> flex-algo. the later can be discussed in another thread.

Then it is reasonable to remove the text about use case 1, 2 and the operations in section 5 which are related to per flex-algo resource reservation or traffic treatment over the same link, as you said they are local behaviors thus do not require  interoperability.

> IMO the local behavior can be any local policies, such as local repair path, local
> queue, local priority for entry installation, etc. Adj-sid per algo provides the
> basis for these local behavior. It is useful to describe how adj-sid per algo can
> satisfy these usecases, also to facilitate readers to understand its use.

Local repair is different from the other cases you mentioned. Local repair results in the change of the path and the SID list, which is visible to the network. In addition, the computation of local repair path is based on the Flex-Algo constraints defined by the FAD. In contrast, the local queue or priority information is not reflected in the FAD. 

Before introducing the local queue and priority use cases to this draft, it is necessary to understand whether such local information need to be included in the FAD or not, and propose relevant Flex-Algo extensions for it, otherwise IMO they are local information and behaviors which are NOT related to Flex-Algo.

Best regards,
Jie

> You are very concerned about the extension of resource reservation. Although
> it is not related to this document and should be discussed in another thread, I
> will try to answer it in your previous email.
> 
> Regards,
> PSF
> 
> 
> 
> 
> But my comments are related to the text in section 3 and 5 of this document,
> which describes new use cases and operation of Flex-Algo with per Flex-Algo
> resource reservation or per Flex-Algo QoS policy on the same link. These require
> extensions to the function of Flex-Algo, which IMO needs to be discussed and
> compared with other alternative mechanisms. And as you indicated, there are
> related encoding extensions proposed in other document, thus it may not be
> just a local behavior.
> > Subject: Re:[Lsr] LSR WG Adoption Call for "Algorithm Related
> > IGP-Adjacency SID Advertisement"
> >
> > Hi Jie,
> >
> > In this document, there are not any extensions to describe resource
> > reservation per algo. Are you aiming at another draft
> > (https://datatracker.ietf.org/doc/draft-cp-lsr-fa-aware-te/) ?  Please
> > find out what you are talking about first.
> > Adj-SID per algo can distinguish traffic behavior in local. You are
> > welcome to add more usecases based on section 3.
> >
> > Regards,
> > PSF
> >
> >
> > It seems this document aims to introduce per Flex-Algo Adj-SID to
> > SR-MPLS, its typical use case is to provide protection path with
> > Flex-Algo constraints for Adj-SID of a particular Flex-Algo, which is described
> in the case 3 of section 3.
> > However, section 3 and section 5 shows that it also aims to introduce
> > further changes to the usage and operation of Flex-Algo, which is to
> > provide resource reservation based on Flex-Algo. IMO these changes to
> > Flex-Algo deserves further discussion and is not only related to the per
> Flex-Algo Adj-SID extension.
> > 1. Flex-Algo defines the constraints for path computation in a
> > distributed manner, it is not for resource reservation.
> > 2. Reserving resources for each Flex-Algo on a link does not make
> > sense. The correlation between Flex-Algo and the network links is
> > based on administrative groups (color), and the color of the link may
> > or may not be included in the Flex-Algo definition. To follow the
> > color based link correlation, a more practical approach would be to
> > use Flex-Algo with L2 bundle as defined in
> > draft-zhu-lsr-isis-sr-vtn-flexalgo, which uses color to correlate the
> > L3 link and the L2 member link to a Flex-Algo, this avoids the extension for
> per-FlexAlgo resource reservation.
> > attributes are shared by all Flex-Algos which include the link
> > according to the FAD, and based on previous discussion, it seems there
> > is no intention to introduce per Flex-Algo ID link attributes.
> > Best regards,
> > Jie

---

From: <[email-masked]>
Date: Mon, 31 May 2021 20:49:06 +0800 (CST)

Hi Jie,

Please see inline [PSF]

------------------原始邮件------------------
发件人：Dongjie(Jimmy)
收件人：彭少富10053815;
抄送人：[email-masked];[email-masked];
日 期 ：2021年05月31日 17:35
主 题 ：Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID Advertisement"
Hi PSF,

[PSF] I'm afraid we can't come to the conclusion that some description of local behavior that is  beneficial to understand the integrity of the whole scheme must not be contained in the document. It does not violate any iron law. The significance of their existence is to show that the local behavior related to the algorithm is possible, so the use of flex algo alone can be competent for some scenarios (e.g, network slicing).  I think the section of use case is open, and ajdacency backup use case is not the only case.
> satisfy these usecases, also to facilitate readers to understand its use.
Local repair is different from the other cases you mentioned. Local repair results in the change of the path and the SID list, which is visible to the network.

[PSF] I don't believe local repair path is visible to other nodes of the network. If you means that show the state of local repair path, you can also show the state of local queue. 

 In addition, the computation of local repair path is based on the Flex-Algo constraints defined by the FAD. In contrast, the local queue or priority information is not reflected in the FAD.

[PSF] Agree, you can also find that local queue is different with local priority. This difference is not our focus, we focus on the possibility of local policy per algo on nodes.
Before introducing the local queue and priority use cases to this draft, it is necessary to understand whether such local information need to be included in the FAD or not, and propose relevant Flex-Algo extensions for it, otherwise IMO they are local information and behaviors which are NOT related to Flex-Algo.

[PSF] See the first untenable conclusion.
Best regards,
Jie