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

[Gyan Mishra]

Thanks Ketan for your thoughts on this topic.

Understood as this “update” / “obsolete” topic is an important IETF topic
that should be uniform across all WGs.

Kind Regards

Gyan


On Thu, Jun 10, 2021 at 10:25 PM Ketan Talaulikar (ketant) 
wrote:

> Hi Gyan,
>
>
>
> By the logic that you have shared, almost all OSPF RFCs after 2328 would
> have been mentioned as “updates” for it. However, there is only a select
> few that “update” RFC 2328 and if we look at them closely, they
> alter/change the contents of behavior in RFC 2328 in some way. At least
> that is my understanding.
>
>
>
> From what I’ve seen, there does not seem to be a notion of “add on
> update”; only “change update”. Again, just my understanding.
>
>
>
> In any case, we’ve recently seen another debate on “updates” in this WG
> that also included the IESG members. Hopefully something more formal will
> emerge from the community to clarify the use of “updates”.
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* Gyan Mishra 
> *Sent:* 11 June 2021 05:46
> *To:* Ketan Talaulikar (ketant) 
> *Cc:* cho...@chopps.org; lsr@ietf.org; peng.sha...@zte.com.cn
> *Subject:* Re: [Lsr] LSR WG Adoption Call for "Algorithm Related
> IGP-Adjacency SID Advertisement"
>
>
>
>
>
> Hi Ketan
>
>
>
> In some cases an RFC can update an existing RFC making the other obsolete
> if the specification changes completely rewrite in the update, however an
> update could also as you pointed out in this case be an add on feature to a
> base specification that is not changing and so in this case the Flex Algo
> base specification and this draft is an add on update not a change update
>  to the base specification.
>
>
>
> Example
>
>
>
> OSPFv2
>
>
>
> RFC 1583 2178 2328 - 2328 is updated base that obsoletes the previous
> specifications
>
>
>
> RFC add on updates to base 2328
>
> 5709 6549 6845 6860 7074 8042
>
>
>
> So in this case this draft would be an add on update to the base Flex Algo
> draft is what I was thinking.
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
> On Thu, Jun 10, 2021 at 11:09 AM Ketan Talaulikar (ketant) <
> ket...@cisco.com> wrote:
>
> Hi Gyan,
>
>
>
> This document does not even “update” the LSR Flex-Algo draft since it is
> introducing something new and on top. It does not change what’s in the LSR
> Flex-Algo draft.
>
>
>
> This document would be pretty much independent and an optional/add-on
> element on top of the LSR Flex-Algo solution.
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* Gyan Mishra 
> *Sent:* 10 June 2021 18:54
> *To:* Ketan Talaulikar (ketant) 
> *Cc:* cho...@chopps.org; lsr@ietf.org; peng.sha...@zte.com.cn
> *Subject:* Re: [Lsr] LSR WG Adoption Call for "Algorithm Related
> IGP-Adjacency SID Advertisement"
>
>
>
>
>
> Hi Ketan
>
>
>
> See in-line
>
>
>
> Thanks
>
>
>
> Gyan
>
>
>
> On Thu, Jun 10, 2021 at 4:40 AM Ketan Talaulikar (ketant) <
> ket...@cisco.com> wrote:
>
> One quick clarification on the following:
>
> Does this draft update the SR IGP extensions for SR-MPLS RFC 8665 8666
> 8667.
> [PSF] Yes.
> KT> This draft proposes something new (an Algo-specific Adj-SID) and their
> relevant signalling extensions for the IGPs. It does not change anything in
> the RFCs referred to above. Hence there is no "updates" consideration here.
>
>
>
> Gyan>This is a confusing point and maybe something the authors can
> clarify in the text.  So this  draft defines a new Adj-Sid that has an Algo
> identifier specifically for Flex Algo and if that’s the case I agree it
> does not update the SR-MPLS IGP extensions, but instead should update the
> Flex Algo extensions.
>
>
>
> Thanks,
> Ketan
>
> -Original Message-
> From: Lsr  On Behalf Of peng.sha...@zte.com.cn
> Sent: 10 June 2021 11:48
> To: hayabusa...@gmail.com
> Cc: lsr@ietf.org; cho...@chopps.org
> Subject: Re: [Lsr] LSR WG Adoption Call for "Algorithm Related
> IGP-Adjacency SID Advertisement"
>
> Hi Gyan,
>
> Thanks for your support.
> Please see inline [PSF]
>
> Regards,
> PSF
>
>
> --原始邮件--
> 发件人：GyanMishra
> 收件人：Christian Hopps;
> 抄送人：lsr@ietf.org;
> 日 期 ：2021年06月10日 13:05
> 主 题 ：Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency
> SID Advertisement"
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
>
> I support WG adoptio

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

[Dongjie (Jimmy)]

Hi Gyan,

Thanks for your reply. So we (and others) are on the same page about the 
resources related functionality introduced to Flex-Algo: it need to be 
discussed separately from this draft.

If the authors agree with this, can this be reflected in an update of this 
draft?

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Gyan Mishra
Sent: Friday, June 11, 2021 9:37 AM
To: Dongjie (Jimmy) 
Cc: lsr@ietf.org; Christian Hopps 
Subject: Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency 
SID Advertisement"


Hi Jimmy

Please see my comments in-line:

Thanks

Gyan
On Thu, Jun 10, 2021 at 4:20 AM Dongjie (Jimmy) 
mailto:jie.d...@huawei.com>> wrote:
Hi Gyan,

Please see some comments inline:

From: Lsr [mailto:lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>] On Behalf 
Of Gyan Mishra
Sent: Thursday, June 10, 2021 1:05 PM
To: Christian Hopps mailto:cho...@chopps.org>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency 
SID Advertisement"


I support WG adoption of this draft.

This draft fills the gap where multiple algorithm identifiers are associated 
with a link applied to prefix sid and to add parity as now this draft provides 
Algo association with the adjacency SID as well.  At the end of the 
introduction is stated that the algorithm identifier should be included as part 
of the adjacency SID advertisement for SR-MPLS.   What about SRv6?

Does this draft update the SR IGP extensions for
SR-MPLS RFC 8665 8666 8667.

Also does it update the Flex Algo draft?

https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-16

In section 5 operations describes how flex Algo plane can now be differentiated 
on the same  adjacency link with the Algo identifier adjacency sid to Algo 
plane can now have QOS and link resources characteristics defined which maybe 
beneficial to TEAS network slicing application as well as used in conjunction 
with a resource sid for underlay resource provisioning for Enhanced VPN overlay.

[Jie] I see this may be related to the resource-aware SID and its usage for 
enhanced VPN. While as mentioned in several mails in this thread, the use cases 
of associating Flex-Algos with different link resources/QoS policy/etc. require 
new functionality to Flex-Algo, which needs to be discussed separately from 
this document.
 Gyan> I agree as Les and others have mentioned any resources related 
functionality must first be reviewed and accepted by the WG as a separate 
document. I agree as others mentioned the main use case is for TI-LFA local 
protection of backup path so it can use other than default Algo 0.
Best regards,
Jie

Kind Regards

Gyan

On Wed, May 26, 2021 at 5:00 PM Christian Hopps 
mailto:cho...@chopps.org>> wrote:

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.

___
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr
--

[图像已被发件人删除。]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com>

M 301 502-1347

--

[图像已被发件人删除。]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com>

M 301 502-1347

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

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

[Ketan Talaulikar (ketant)]

Hi Gyan,

By the logic that you have shared, almost all OSPF RFCs after 2328 would have 
been mentioned as “updates” for it. However, there is only a select few that 
“update” RFC 2328 and if we look at them closely, they alter/change the 
contents of behavior in RFC 2328 in some way. At least that is my understanding.

From what I’ve seen, there does not seem to be a notion of “add on update”; 
only “change update”. Again, just my understanding.

In any case, we’ve recently seen another debate on “updates” in this WG that 
also included the IESG members. Hopefully something more formal will emerge 
from the community to clarify the use of “updates”.

Thanks,
Ketan

From: Gyan Mishra 
Sent: 11 June 2021 05:46
To: Ketan Talaulikar (ketant) 
Cc: cho...@chopps.org; lsr@ietf.org; peng.sha...@zte.com.cn
Subject: Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency 
SID Advertisement"


Hi Ketan

In some cases an RFC can update an existing RFC making the other obsolete if 
the specification changes completely rewrite in the update, however an update 
could also as you pointed out in this case be an add on feature to a base 
specification that is not changing and so in this case the Flex Algo base 
specification and this draft is an add on update not a change update  to the 
base specification.

Example

OSPFv2

RFC 1583 2178 2328 - 2328 is updated base that obsoletes the previous 
specifications

RFC add on updates to base 2328
5709 6549 6845 6860 7074 8042

So in this case this draft would be an add on update to the base Flex Algo 
draft is what I was thinking.

Kind Regards

Gyan

On Thu, Jun 10, 2021 at 11:09 AM Ketan Talaulikar (ketant) 
mailto:ket...@cisco.com>> wrote:
Hi Gyan,

This document does not even “update” the LSR Flex-Algo draft since it is 
introducing something new and on top. It does not change what’s in the LSR 
Flex-Algo draft.

This document would be pretty much independent and an optional/add-on element 
on top of the LSR Flex-Algo solution.

Thanks,
Ketan

From: Gyan Mishra mailto:hayabusa...@gmail.com>>
Sent: 10 June 2021 18:54
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Cc: cho...@chopps.org<mailto:cho...@chopps.org>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn>
Subject: Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency 
SID Advertisement"


Hi Ketan

See in-line

Thanks

Gyan

On Thu, Jun 10, 2021 at 4:40 AM Ketan Talaulikar (ketant) 
mailto:ket...@cisco.com>> wrote:
One quick clarification on the following:

Does this draft update the SR IGP extensions for SR-MPLS RFC 8665 8666 8667.
[PSF] Yes.
KT> This draft proposes something new (an Algo-specific Adj-SID) and their 
relevant signalling extensions for the IGPs. It does not change anything in the 
RFCs referred to above. Hence there is no "updates" consideration here.

Gyan>This is a confusing point and maybe something the authors can clarify 
in the text.  So this  draft defines a new Adj-Sid that has an Algo identifier 
specifically for Flex Algo and if that’s the case I agree it does not update 
the SR-MPLS IGP extensions, but instead should update the Flex Algo extensions.


Thanks,
Ketan

-Original Message-
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn>
Sent: 10 June 2021 11:48
To: hayabusa...@gmail.com<mailto:hayabusa...@gmail.com>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; 
cho...@chopps.org<mailto:cho...@chopps.org>
Subject: Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency 
SID Advertisement"

Hi Gyan,

Thanks for your support.
Please see inline [PSF]

Regards,
PSF


--原始邮件--------------
发件人：GyanMishra
收件人：Christian Hopps;
抄送人：lsr@ietf.org<mailto:lsr@ietf.org>;
日 期 ：2021年06月10日 13:05
主 题 ：Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID 
Advertisement"
___
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr


I support WG adoption of this draft.

This draft fills the gap where multiple algorithm identifiers are associated 
with a link applied to prefix sid and to add parity as now this draft provides 
Algo association with the adjacency SID as well.  At the end of the 
introduction is stated that the algorithm identifier should be included as part 
of the adjacency SID advertisement for SR-MPLS.   What about SRv6?

[PSF] For SRv6, tt was born with this ability, since SRv6 END.X SID can be 
allocated from an algorithm specific Locator.


Does this draft update the SR IGP extensions for SR-MPLS RFC 8665 8666 8667.

[PSF] Yes.


Also does it update the Flex Algo draft?
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-16

[PSF] No.


In section 5 operations describes how f

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

[Gyan Mishra]

Hi Jimmy

Please see my comments in-line:

Thanks

Gyan
On Thu, Jun 10, 2021 at 4:20 AM Dongjie (Jimmy)  wrote:

> Hi Gyan,
>
>
>
> Please see some comments inline:
>
>
>
> *From:* Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *Gyan Mishra
> *Sent:* Thursday, June 10, 2021 1:05 PM
> *To:* Christian Hopps 
> *Cc:* lsr@ietf.org
> *Subject:* Re: [Lsr] LSR WG Adoption Call for "Algorithm Related
> IGP-Adjacency SID Advertisement"
>
>
>
>
>
> I support WG adoption of this draft.
>
>
>
> This draft fills the gap where multiple algorithm identifiers are
> associated with a link applied to prefix sid and to add parity as now this
> draft provides Algo association with the adjacency SID as well.  At the end
> of the introduction is stated that the algorithm identifier should be
> included as part of the adjacency SID advertisement for SR-MPLS.   What
> about SRv6?
>
>
>
> Does this draft update the SR IGP extensions for
>
> SR-MPLS RFC 8665 8666 8667.
>
>
>
> Also does it update the Flex Algo draft?
>
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-16
>
>
>
> In section 5 operations describes how flex Algo plane can now be
> differentiated on the same  adjacency link with the Algo identifier
> adjacency sid to Algo plane can now have QOS and link resources
> characteristics defined which maybe beneficial to TEAS network slicing
> application as well as used in conjunction with a resource sid for underlay
> resource provisioning for Enhanced VPN overlay.
>
>
>
> [Jie] I see this may be related to the resource-aware SID and its usage
> for enhanced VPN. While as mentioned in several mails in this thread, the
> use cases of associating Flex-Algos with different link resources/QoS
> policy/etc. require new functionality to Flex-Algo, which needs to be
> discussed separately from this document.
>
>  Gyan> I agree as Les and others have mentioned any resources related
> functionality must first be reviewed and accepted by the WG as a separate
> document. I agree as others mentioned the main use case is for TI-LFA local
> protection of backup path so it can use other than default Algo 0.
>
> Best regards,
>
> Jie
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
> On Wed, May 26, 2021 at 5:00 PM Christian Hopps  wrote:
>
>
> 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.
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
> --
>
> [image: 图像已被发件人删除。] <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email gyan.s.mis...@verizon.com *
>
> *M 301 502-1347*
>
>
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Gyan Mishra]

Hi Ketan

In some cases an RFC can update an existing RFC making the other obsolete
if the specification changes completely rewrite in the update, however an
update could also as you pointed out in this case be an add on feature to a
base specification that is not changing and so in this case the Flex Algo
base specification and this draft is an add on update not a change update
 to the base specification.

Example

OSPFv2

RFC 1583 2178 2328 - 2328 is updated base that obsoletes the previous
specifications

RFC add on updates to base 2328
5709 6549 6845 6860 7074 8042

So in this case this draft would be an add on update to the base Flex Algo
draft is what I was thinking.

Kind Regards

Gyan

On Thu, Jun 10, 2021 at 11:09 AM Ketan Talaulikar (ketant) 
wrote:

> Hi Gyan,
>
>
>
> This document does not even “update” the LSR Flex-Algo draft since it is
> introducing something new and on top. It does not change what’s in the LSR
> Flex-Algo draft.
>
>
>
> This document would be pretty much independent and an optional/add-on
> element on top of the LSR Flex-Algo solution.
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* Gyan Mishra 
> *Sent:* 10 June 2021 18:54
> *To:* Ketan Talaulikar (ketant) 
> *Cc:* cho...@chopps.org; lsr@ietf.org; peng.sha...@zte.com.cn
> *Subject:* Re: [Lsr] LSR WG Adoption Call for "Algorithm Related
> IGP-Adjacency SID Advertisement"
>
>
>
>
>
> Hi Ketan
>
>
>
> See in-line
>
>
>
> Thanks
>
>
>
> Gyan
>
>
>
> On Thu, Jun 10, 2021 at 4:40 AM Ketan Talaulikar (ketant) <
> ket...@cisco.com> wrote:
>
> One quick clarification on the following:
>
> Does this draft update the SR IGP extensions for SR-MPLS RFC 8665 8666
> 8667.
> [PSF] Yes.
> KT> This draft proposes something new (an Algo-specific Adj-SID) and their
> relevant signalling extensions for the IGPs. It does not change anything in
> the RFCs referred to above. Hence there is no "updates" consideration here.
>
>
>
> Gyan>This is a confusing point and maybe something the authors can
> clarify in the text.  So this  draft defines a new Adj-Sid that has an Algo
> identifier specifically for Flex Algo and if that’s the case I agree it
> does not update the SR-MPLS IGP extensions, but instead should update the
> Flex Algo extensions.
>
>
>
> Thanks,
> Ketan
>
> -Original Message-
> From: Lsr  On Behalf Of peng.sha...@zte.com.cn
> Sent: 10 June 2021 11:48
> To: hayabusa...@gmail.com
> Cc: lsr@ietf.org; cho...@chopps.org
> Subject: Re: [Lsr] LSR WG Adoption Call for "Algorithm Related
> IGP-Adjacency SID Advertisement"
>
> Hi Gyan,
>
> Thanks for your support.
> Please see inline [PSF]
>
> Regards,
> PSF
>
>
> --原始邮件--
> 发件人：GyanMishra
> 收件人：Christian Hopps;
> 抄送人：lsr@ietf.org;
> 日 期 ：2021年06月10日 13:05
> 主 题 ：Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency
> SID Advertisement"
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
>
> I support WG adoption of this draft.
>
> This draft fills the gap where multiple algorithm identifiers are
> associated with a link applied to prefix sid and to add parity as now this
> draft provides Algo association with the adjacency SID as well.  At the end
> of the introduction is stated that the algorithm identifier should be
> included as part of the adjacency SID advertisement for SR-MPLS.   What
> about SRv6?
>
> [PSF] For SRv6, tt was born with this ability, since SRv6 END.X SID can be
> allocated from an algorithm specific Locator.
>
>
> Does this draft update the SR IGP extensions for SR-MPLS RFC 8665 8666
> 8667.
>
> [PSF] Yes.
>
>
> Also does it update the Flex Algo draft?
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-16
>
> [PSF] No.
>
>
> In section 5 operations describes how flex Algo plane can now be
> differentiated on the same  adjacency link with the Algo identifier
> adjacency sid to Algo plane can now have QOS and link resources
> characteristics defined which maybe beneficial to TEAS network slicing
> application as well as used in conjunction with a resource sid for underlay
> resource provisioning for Enhanced VPN overlay.
>
> [PSF] Agree. Flex-algo can be used alone as a network slicing mechanism
> for some limited scenarios, and adj-sid per algo provide a basis for this
> purpose. However this is outside the scope of this document, so it is not
> described in detailed.
>
>
> Kind Regards
>
> Gyan
>
> On Wed, May 26, 2021 at 5:00 PM Christian Hopps  wr

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

[Acee Lindem (acee)]

I agree with Ketan.
Thanks,
Acee

From: Lsr  on behalf of "Ketan Talaulikar (ketant)" 

Date: Thursday, June 10, 2021 at 11:10 AM
To: Gyan Mishra 
Cc: "lsr@ietf.org" , Christian Hopps , 
"peng.sha...@zte.com.cn" 
Subject: Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency 
SID Advertisement"

Hi Gyan,

This document does not even “update” the LSR Flex-Algo draft since it is 
introducing something new and on top. It does not change what’s in the LSR 
Flex-Algo draft.

This document would be pretty much independent and an optional/add-on element 
on top of the LSR Flex-Algo solution.

Thanks,
Ketan

From: Gyan Mishra 
Sent: 10 June 2021 18:54
To: Ketan Talaulikar (ketant) 
Cc: cho...@chopps.org; lsr@ietf.org; peng.sha...@zte.com.cn
Subject: Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency 
SID Advertisement"


Hi Ketan

See in-line

Thanks

Gyan

On Thu, Jun 10, 2021 at 4:40 AM Ketan Talaulikar (ketant) 
mailto:ket...@cisco.com>> wrote:
One quick clarification on the following:

Does this draft update the SR IGP extensions for SR-MPLS RFC 8665 8666 8667.
[PSF] Yes.
KT> This draft proposes something new (an Algo-specific Adj-SID) and their 
relevant signalling extensions for the IGPs. It does not change anything in the 
RFCs referred to above. Hence there is no "updates" consideration here.

Gyan>This is a confusing point and maybe something the authors can clarify 
in the text.  So this  draft defines a new Adj-Sid that has an Algo identifier 
specifically for Flex Algo and if that’s the case I agree it does not update 
the SR-MPLS IGP extensions, but instead should update the Flex Algo extensions.


Thanks,
Ketan

-Original Message-
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn>
Sent: 10 June 2021 11:48
To: hayabusa...@gmail.com<mailto:hayabusa...@gmail.com>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; 
cho...@chopps.org<mailto:cho...@chopps.org>
Subject: Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency 
SID Advertisement"

Hi Gyan,

Thanks for your support.
Please see inline [PSF]

Regards,
PSF


--原始邮件----------
发件人：GyanMishra
收件人：Christian Hopps;
抄送人：lsr@ietf.org<mailto:lsr@ietf.org>;
日 期 ：2021年06月10日 13:05
主 题 ：Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID 
Advertisement"
___
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr


I support WG adoption of this draft.

This draft fills the gap where multiple algorithm identifiers are associated 
with a link applied to prefix sid and to add parity as now this draft provides 
Algo association with the adjacency SID as well.  At the end of the 
introduction is stated that the algorithm identifier should be included as part 
of the adjacency SID advertisement for SR-MPLS.   What about SRv6?

[PSF] For SRv6, tt was born with this ability, since SRv6 END.X SID can be 
allocated from an algorithm specific Locator.


Does this draft update the SR IGP extensions for SR-MPLS RFC 8665 8666 8667.

[PSF] Yes.


Also does it update the Flex Algo draft?
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-16

[PSF] No.


In section 5 operations describes how flex Algo plane can now be differentiated 
on the same  adjacency link with the Algo identifier adjacency sid to Algo 
plane can now have QOS and link resources characteristics defined which maybe 
beneficial to TEAS network slicing application as well as used in conjunction 
with a resource sid for underlay resource provisioning for Enhanced VPN overlay.

[PSF] Agree. Flex-algo can be used alone as a network slicing mechanism for 
some limited scenarios, and adj-sid per algo provide a basis for this purpose. 
However this is outside the scope of this document, so it is not described in 
detailed.


Kind Regards

Gyan

On Wed, May 26, 2021 at 5:00 PM Christian Hopps 
mailto:cho...@chopps.org>> wrote:

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.

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

--

Gyan Mishra
Network Solutions Architect
Email gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com>
M 301 502-1347
--

[Image removed by sender.]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com>

M 301 502-1347

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

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

[Christian Hopps]

The document is adopted. We have enough support, and given the development 
email on the adoption call thread clearly people willing to work on the 
document.

Authors please resubmit as draft-ietf-lsr-algorithm-related-adjacency-sid-00

Thanks,
Acee & Chris.


Christian Hopps  writes:


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.

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


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

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

[Ketan Talaulikar (ketant)]

Hi Gyan,

This document does not even “update” the LSR Flex-Algo draft since it is 
introducing something new and on top. It does not change what’s in the LSR 
Flex-Algo draft.

This document would be pretty much independent and an optional/add-on element 
on top of the LSR Flex-Algo solution.

Thanks,
Ketan

From: Gyan Mishra 
Sent: 10 June 2021 18:54
To: Ketan Talaulikar (ketant) 
Cc: cho...@chopps.org; lsr@ietf.org; peng.sha...@zte.com.cn
Subject: Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency 
SID Advertisement"


Hi Ketan

See in-line

Thanks

Gyan

On Thu, Jun 10, 2021 at 4:40 AM Ketan Talaulikar (ketant) 
mailto:ket...@cisco.com>> wrote:
One quick clarification on the following:

Does this draft update the SR IGP extensions for SR-MPLS RFC 8665 8666 8667.
[PSF] Yes.
KT> This draft proposes something new (an Algo-specific Adj-SID) and their 
relevant signalling extensions for the IGPs. It does not change anything in the 
RFCs referred to above. Hence there is no "updates" consideration here.

Gyan>This is a confusing point and maybe something the authors can clarify 
in the text.  So this  draft defines a new Adj-Sid that has an Algo identifier 
specifically for Flex Algo and if that’s the case I agree it does not update 
the SR-MPLS IGP extensions, but instead should update the Flex Algo extensions.


Thanks,
Ketan

-Original Message-
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn>
Sent: 10 June 2021 11:48
To: hayabusa...@gmail.com<mailto:hayabusa...@gmail.com>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; 
cho...@chopps.org<mailto:cho...@chopps.org>
Subject: Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency 
SID Advertisement"

Hi Gyan,

Thanks for your support.
Please see inline [PSF]

Regards,
PSF


--原始邮件--
发件人：GyanMishra
收件人：Christian Hopps;
抄送人：lsr@ietf.org<mailto:lsr@ietf.org>;
日 期 ：2021年06月10日 13:05
主 题 ：Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID 
Advertisement"
___
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr


I support WG adoption of this draft.

This draft fills the gap where multiple algorithm identifiers are associated 
with a link applied to prefix sid and to add parity as now this draft provides 
Algo association with the adjacency SID as well.  At the end of the 
introduction is stated that the algorithm identifier should be included as part 
of the adjacency SID advertisement for SR-MPLS.   What about SRv6?

[PSF] For SRv6, tt was born with this ability, since SRv6 END.X SID can be 
allocated from an algorithm specific Locator.


Does this draft update the SR IGP extensions for SR-MPLS RFC 8665 8666 8667.

[PSF] Yes.


Also does it update the Flex Algo draft?
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-16

[PSF] No.


In section 5 operations describes how flex Algo plane can now be differentiated 
on the same  adjacency link with the Algo identifier adjacency sid to Algo 
plane can now have QOS and link resources characteristics defined which maybe 
beneficial to TEAS network slicing application as well as used in conjunction 
with a resource sid for underlay resource provisioning for Enhanced VPN overlay.

[PSF] Agree. Flex-algo can be used alone as a network slicing mechanism for 
some limited scenarios, and adj-sid per algo provide a basis for this purpose. 
However this is outside the scope of this document, so it is not described in 
detailed.


Kind Regards

Gyan

On Wed, May 26, 2021 at 5:00 PM Christian Hopps 
mailto:cho...@chopps.org>> wrote:

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.

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

--

Gyan Mishra
Network Solutions Architect
Email gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com>
M 301 502-1347
--

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

Gyan Mishra

Network Solutions Architect

Email gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com>

M 301 502-1347

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

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

[Gyan Mishra]

Hi Ketan

See in-line

Thanks

Gyan

On Thu, Jun 10, 2021 at 4:40 AM Ketan Talaulikar (ketant) 
wrote:

> One quick clarification on the following:
>
> Does this draft update the SR IGP extensions for SR-MPLS RFC 8665 8666
> 8667.
> [PSF] Yes.
> KT> This draft proposes something new (an Algo-specific Adj-SID) and their
> relevant signalling extensions for the IGPs. It does not change anything in
> the RFCs referred to above. Hence there is no "updates" consideration here.


Gyan>This is a confusing point and maybe something the authors can
clarify in the text.  So this  draft defines a new Adj-Sid that has an Algo
identifier specifically for Flex Algo and if that’s the case I agree it
does not update the SR-MPLS IGP extensions, but instead should update the
Flex Algo extensions.

>
>
> Thanks,
> Ketan
>
> -Original Message-
> From: Lsr  On Behalf Of peng.sha...@zte.com.cn
> Sent: 10 June 2021 11:48
> To: hayabusa...@gmail.com
> Cc: lsr@ietf.org; cho...@chopps.org
> Subject: Re: [Lsr] LSR WG Adoption Call for "Algorithm Related
> IGP-Adjacency SID Advertisement"
>
> Hi Gyan,
>
> Thanks for your support.
> Please see inline [PSF]
>
> Regards,
> PSF
>
>
> ------原始邮件----------
> 发件人：GyanMishra
> 收件人：Christian Hopps;
> 抄送人：lsr@ietf.org;
> 日 期 ：2021年06月10日 13:05
> 主 题 ：Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency
> SID Advertisement"
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
>
> I support WG adoption of this draft.
>
> This draft fills the gap where multiple algorithm identifiers are
> associated with a link applied to prefix sid and to add parity as now this
> draft provides Algo association with the adjacency SID as well.  At the end
> of the introduction is stated that the algorithm identifier should be
> included as part of the adjacency SID advertisement for SR-MPLS.   What
> about SRv6?
>
> [PSF] For SRv6, tt was born with this ability, since SRv6 END.X SID can be
> allocated from an algorithm specific Locator.
>
>
> Does this draft update the SR IGP extensions for SR-MPLS RFC 8665 8666
> 8667.
>
> [PSF] Yes.
>
>
> Also does it update the Flex Algo draft?
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-16
>
> [PSF] No.
>
>
> In section 5 operations describes how flex Algo plane can now be
> differentiated on the same  adjacency link with the Algo identifier
> adjacency sid to Algo plane can now have QOS and link resources
> characteristics defined which maybe beneficial to TEAS network slicing
> application as well as used in conjunction with a resource sid for underlay
> resource provisioning for Enhanced VPN overlay.
>
> [PSF] Agree. Flex-algo can be used alone as a network slicing mechanism
> for some limited scenarios, and adj-sid per algo provide a basis for this
> purpose. However this is outside the scope of this document, so it is not
> described in detailed.
>
>
> Kind Regards
>
> Gyan
>
> On Wed, May 26, 2021 at 5:00 PM Christian Hopps  wrote:
>
> 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.
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
> --
>
> Gyan Mishra
> Network Solutions Architect
> Email gyan.s.mis...@verizon.com
> M 301 502-1347
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Ketan Talaulikar (ketant)]

One quick clarification on the following:

Does this draft update the SR IGP extensions for SR-MPLS RFC 8665 8666 8667.
[PSF] Yes.
KT> This draft proposes something new (an Algo-specific Adj-SID) and their 
relevant signalling extensions for the IGPs. It does not change anything in the 
RFCs referred to above. Hence there is no "updates" consideration here.

Thanks,
Ketan

-Original Message-
From: Lsr  On Behalf Of peng.sha...@zte.com.cn
Sent: 10 June 2021 11:48
To: hayabusa...@gmail.com
Cc: lsr@ietf.org; cho...@chopps.org
Subject: Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency 
SID Advertisement"

Hi Gyan,

Thanks for your support.
Please see inline [PSF]

Regards,
PSF


--原始邮件--
发件人：GyanMishra
收件人：Christian Hopps;
抄送人：lsr@ietf.org;
日 期 ：2021年06月10日 13:05
主 题 ：Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID 
Advertisement"
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


I support WG adoption of this draft.

This draft fills the gap where multiple algorithm identifiers are associated 
with a link applied to prefix sid and to add parity as now this draft provides 
Algo association with the adjacency SID as well.  At the end of the 
introduction is stated that the algorithm identifier should be included as part 
of the adjacency SID advertisement for SR-MPLS.   What about SRv6?

[PSF] For SRv6, tt was born with this ability, since SRv6 END.X SID can be 
allocated from an algorithm specific Locator.


Does this draft update the SR IGP extensions for SR-MPLS RFC 8665 8666 8667.

[PSF] Yes.


Also does it update the Flex Algo draft?
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-16

[PSF] No.


In section 5 operations describes how flex Algo plane can now be differentiated 
on the same  adjacency link with the Algo identifier adjacency sid to Algo 
plane can now have QOS and link resources characteristics defined which maybe 
beneficial to TEAS network slicing application as well as used in conjunction 
with a resource sid for underlay resource provisioning for Enhanced VPN overlay.

[PSF] Agree. Flex-algo can be used alone as a network slicing mechanism for 
some limited scenarios, and adj-sid per algo provide a basis for this purpose. 
However this is outside the scope of this document, so it is not described in 
detailed. 


Kind Regards

Gyan

On Wed, May 26, 2021 at 5:00 PM Christian Hopps  wrote:

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.

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

--

Gyan Mishra
Network Solutions Architect
Email gyan.s.mis...@verizon.com
M 301 502-1347
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Dongjie (Jimmy)]

Hi Gyan,

Please see some comments inline:

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Gyan Mishra
Sent: Thursday, June 10, 2021 1:05 PM
To: Christian Hopps 
Cc: lsr@ietf.org
Subject: Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency 
SID Advertisement"


I support WG adoption of this draft.

This draft fills the gap where multiple algorithm identifiers are associated 
with a link applied to prefix sid and to add parity as now this draft provides 
Algo association with the adjacency SID as well.  At the end of the 
introduction is stated that the algorithm identifier should be included as part 
of the adjacency SID advertisement for SR-MPLS.   What about SRv6?

Does this draft update the SR IGP extensions for
SR-MPLS RFC 8665 8666 8667.

Also does it update the Flex Algo draft?

https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-16

In section 5 operations describes how flex Algo plane can now be differentiated 
on the same  adjacency link with the Algo identifier adjacency sid to Algo 
plane can now have QOS and link resources characteristics defined which maybe 
beneficial to TEAS network slicing application as well as used in conjunction 
with a resource sid for underlay resource provisioning for Enhanced VPN overlay.

[Jie] I see this may be related to the resource-aware SID and its usage for 
enhanced VPN. While as mentioned in several mails in this thread, the use cases 
of associating Flex-Algos with different link resources/QoS policy/etc. require 
new functionality to Flex-Algo, which needs to be discussed separately from 
this document.

Best regards,
Jie

Kind Regards

Gyan

On Wed, May 26, 2021 at 5:00 PM Christian Hopps 
mailto:cho...@chopps.org>> wrote:

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.

___
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr
--

[图像已被发件人删除。]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com>

M 301 502-1347

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

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

[peng.shaofu]

Hi Gyan,

Thanks for your support.
Please see inline [PSF]

Regards,
PSF


--原始邮件--
发件人：GyanMishra
收件人：Christian Hopps;
抄送人：lsr@ietf.org;
日 期 ：2021年06月10日 13:05
主 题 ：Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID 
Advertisement"
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


I support WG adoption of this draft.

This draft fills the gap where multiple algorithm identifiers are associated 
with a link applied to prefix sid and to add parity as now this draft provides 
Algo association with the adjacency SID as well.  At the end of the 
introduction is stated that the algorithm identifier should be included as part 
of the adjacency SID advertisement for SR-MPLS.   What about SRv6?

[PSF] For SRv6, tt was born with this ability, since SRv6 END.X SID can be 
allocated from an algorithm specific Locator.


Does this draft update the SR IGP extensions for
SR-MPLS RFC 8665 8666 8667.

[PSF] Yes.


Also does it update the Flex Algo draft?
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-16

[PSF] No.


In section 5 operations describes how flex Algo plane can now be differentiated 
on the same  adjacency link with the Algo identifier adjacency sid to Algo 
plane can now have QOS and link resources characteristics defined which maybe 
beneficial to TEAS network slicing application as well as used in conjunction 
with a resource sid for underlay resource provisioning for Enhanced VPN overlay.

[PSF] Agree. Flex-algo can be used alone as a network slicing mechanism for 
some limited scenarios, and adj-sid per algo provide a basis for this purpose. 
However this is outside the scope of this document, so it is not described in 
detailed. 


Kind Regards

Gyan

On Wed, May 26, 2021 at 5:00 PM Christian Hopps  wrote:

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.

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

--

Gyan Mishra
Network Solutions Architect
Email gyan.s.mis...@verizon.com
M 301 502-1347___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Gyan Mishra]

I support WG adoption of this draft.

This draft fills the gap where multiple algorithm identifiers are
associated with a link applied to prefix sid and to add parity as now this
draft provides Algo association with the adjacency SID as well.  At the end
of the introduction is stated that the algorithm identifier should be
included as part of the adjacency SID advertisement for SR-MPLS.   What
about SRv6?

Does this draft update the SR IGP extensions for
SR-MPLS RFC 8665 8666 8667.

Also does it update the Flex Algo draft?

https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-16

In section 5 operations describes how flex Algo plane can now be
differentiated on the same  adjacency link with the Algo identifier
adjacency sid to Algo plane can now have QOS and link resources
characteristics defined which maybe beneficial to TEAS network slicing
application as well as used in conjunction with a resource sid for underlay
resource provisioning for Enhanced VPN overlay.

Kind Regards

Gyan

On Wed, May 26, 2021 at 5:00 PM Christian Hopps  wrote:

>
> 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.
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
-- 



*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[peng.shaofu]

Hi Les,

Thanks for your comments.
Please see inline [PSF].

Regards,
PSF


--原始邮件--
发件人：LesGinsberg(ginsberg)
收件人：Christian Hopps;lsr@ietf.org;
日 期 ：2021年06月02日 13:04
主 题 ：Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID 
Advertisement"
I support adoption of this draft.
I believe that there are use cases for algorithm specific adjacency-sids - 
primarily (and non-controversially) to provide algorithm specific repair paths.
As others have commented, other use cases mentioned in this draft involve 
introducing significant new functionality which has not been discussed or 
accepted by the WG (e.g., resource allocation). This topic deserves to be 
reviewed by the WG on its own merit in a separate draft.

[PSF] OK. Indeed, we should agree on use-case 2/3, because an adjacency-sid of 
TI-LFA path need further adjacency backup path for protection. And, put aside 
resource reservation, based on use-case 2, we can also do more things, for 
example, statistics of traffic of different algorithms on the same link.


This draft should confine itself to defining the new advertisements required to 
support algorithm specific adjacency-sids and discussing the repair path use 
case.
I would also like to see some discussion of deployment considerations including:
a)When to allocate/advertise algorithm specific adjacency-sids vs when to 
continue to use algorithm independent adjacency sids.
b)Strict-SID algo-sids are not useful
c)Use case should drive the type(s) of algorithm specific adjacency-sids 
allocated/advertised. For example,  if primary use case is for algorithm 
specific repair paths, then only sids with B flag set ("eligible for 
protection") are required.

[PSF] Thanks for these  constructive suggestions. We will improve it in later 
versions. : )


Simply allocating algorithm specific adjacency SIDs for all supported 
algorithms all the time is a recipe for bloating the protocol link 
advertisements unnecessarily.

[PSF] OK, we will give the recommended option.


Les
> -Original Message-
> From: Lsr  On Behalf Of Christian Hopps
> Sent: Wednesday, May 26, 2021 1:57 PM
> To: lsr@ietf.org
> Cc: cho...@chopps.org
> Subject: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID
> Advertisement"
>
>
> 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.
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[peng.shaofu]

Hi Aijun,

Thanks for your comments.
Please see inline [PSF]

Regards,
PSF


--原始邮件--
发件人：AijunWang
收件人：'Christian Hopps';lsr@ietf.org;
日 期 ：2021年06月02日 11:51
主 题 ：Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID 
Advertisement"
Hi, All:
Again, I support part of this draft be adopted.


The deployment of Flex-Algo should be separated from the SR-TE Policy. Then
the use-case 1, 3 in section 3 should be pulled out, this can keep the
original design principle of Flex-Algo.
Adjacency-SID will only be included in the data packet when the packets need
pass a TI-LFA path, which is described in case-2 of section 3.

[PSF] If I get your point, it is use-case 1 that should be pulled out. Since 
use-case 3 is just the primary case with consensus.
[PSF] And, use-case 2 is related with TI-LFA path to a remote destination node. 
As we know an adjacency segment can be contained in the TI-LFA path. So that an 
algorithm specific TI-LFA path should also possibly contain algorithm related 
adjacency-sid. Only in this way can this adjacence-sid can be protected by the 
algorithm specific local repair path. Therefore, we also agree on use-case 2.


And, I saw there was contentions for the following paragraph in section 5:
"The endpoint of a link shared by multiple flex-algo plane can reserve
different queue resources for different algorithms locally, and
perform priority based queue scheduling and traffic shaping.  This
algorithm related reserved information can be advertised to other
nodes in the network through some mechanism, therefore it has an
impact on the constraint based path calculation of the flex-algo
plane.  How to allocate algorithm related resouce and advertise it in
the network is out the scope of this document."
Since Flex-Algo doesn't consider the resource reservation, then such
reservation information needs not be advertised out of the node itself for
Flex-algo calculation.

[PSF] Agree. Flex-algo itself doesn't consider the resource reservation during 
constraint SPF computation. 
[PSF] My means is that other computation engine (e.g, an SDN controller) can 
possibly compute a TE path within the scope of specific flex-algo plane. This 
document doesn't discuss this topic in detail, just mentions it as a use case 
(i.e., use-case 1). This topic can refer to "algorithm constraints" in 
https://datatracker.ietf.org/doc/draft-peng-pce-te-constraints/


The local behavior based on the flex-algo related Adjacency-SID can be
described if the authors prefer.

[PSF] Yes, they just help to describe the purpose of algorithm related adj-sid. 
It is free for an implementation to organize its local table, forwarding 
resource, based on algorithm directly or indirectly.


SR-TE and Flex-Algo both can achieve the same goal, we need not mix them
together.
[PSF] This opinion is actually related to use-case 1.  I don't insist on my own 
view that use-case 1, i.e., SR-TE path within flex-algo plane, is kept in this 
document. We can discuss it in another documents.


Best Regards
Aijun Wang
China Telecom
-Original Message-
From: lsr-boun...@ietf.org  On Behalf Of Christian
Hopps
Sent: Thursday, May 27, 2021 4:57 AM
To: lsr@ietf.org
Cc: cho...@chopps.org
Subject: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID
Advertisement"
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.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Les Ginsberg (ginsberg)]

I support adoption of this draft.

I believe that there are use cases for algorithm specific adjacency-sids - 
primarily (and non-controversially) to provide algorithm specific repair paths.

As others have commented, other use cases mentioned in this draft involve 
introducing significant new functionality which has not been discussed or 
accepted by the WG (e.g., resource allocation). This topic deserves to be 
reviewed by the WG on its own merit in a separate draft.

This draft should confine itself to defining the new advertisements required to 
support algorithm specific adjacency-sids and discussing the repair path use 
case.

I would also like to see some discussion of deployment considerations including:

a)When to allocate/advertise algorithm specific adjacency-sids vs when to 
continue to use algorithm independent adjacency sids.
b)Strict-SID algo-sids are not useful
c)Use case should drive the type(s) of algorithm specific adjacency-sids 
allocated/advertised. For example,  if primary use case is for algorithm 
specific repair paths, then only sids with B flag set ("eligible for 
protection") are required.

Simply allocating algorithm specific adjacency SIDs for all supported 
algorithms all the time is a recipe for bloating the protocol link 
advertisements unnecessarily.

   Les

> -Original Message-
> From: Lsr  On Behalf Of Christian Hopps
> Sent: Wednesday, May 26, 2021 1:57 PM
> To: lsr@ietf.org
> Cc: cho...@chopps.org
> Subject: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID
> Advertisement"
> 
> 
> 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.
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

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

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

[Aijun Wang]

Hi, All:

Again, I support part of this draft be adopted. 

The deployment of Flex-Algo should be separated from the SR-TE Policy. Then
the use-case 1, 3 in section 3 should be pulled out, this can keep the
original design principle of Flex-Algo.
Adjacency-SID will only be included in the data packet when the packets need
pass a TI-LFA path, which is described in case-2 of section 3.

And, I saw there was contentions for the following paragraph in section 5:
"The endpoint of a link shared by multiple flex-algo plane can reserve
   different queue resources for different algorithms locally, and
   perform priority based queue scheduling and traffic shaping.  This
   algorithm related reserved information can be advertised to other
   nodes in the network through some mechanism, therefore it has an
   impact on the constraint based path calculation of the flex-algo
   plane.  How to allocate algorithm related resouce and advertise it in
   the network is out the scope of this document."

Since Flex-Algo doesn't consider the resource reservation, then such
reservation information needs not be advertised out of the node itself for
Flex-algo calculation.
The local behavior based on the flex-algo related Adjacency-SID can be
described if the authors prefer. 

SR-TE and Flex-Algo both can achieve the same goal, we need not mix them
together.


Best Regards

Aijun Wang
China Telecom

-Original Message-
From: lsr-boun...@ietf.org  On Behalf Of Christian
Hopps
Sent: Thursday, May 27, 2021 4:57 AM
To: lsr@ietf.org
Cc: cho...@chopps.org
Subject: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID
Advertisement"


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.

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

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

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

[Huzhibo]

Hi:
I don't support the adoption of this document.Reserve different queue 
resources 
for different algorithms is not a existing feature of Flexalgo, I don't think 
it's appropriate to include it in this document. 
if needed it should be discussed separately from the per flexalgo adj sid 
extension

Best regards,
Zhibo

-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
Sent: Thursday, May 27, 2021 4:57 AM
To: lsr@ietf.org
Cc: cho...@chopps.org
Subject: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID 
Advertisement"


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.

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

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

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

[peng.shaofu]

Hi Jie,

Please see inline [PSF]


--原始邮件--
发件人：Dongjie(Jimmy)
收件人：彭少富10053815;
抄送人：lsr@ietf.org;cho...@chopps.org;
日 期 ：2021年05月31日 17:35
主 题 ：Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID 
Advertisement"
Hi PSF,
Please see inline:
> -Original Message-
> From: peng.sha...@zte.com.cn [mailto:peng.sha...@zte.com.cn]
> Sent: Monday, May 31, 2021 9:41 AM
> To: Dongjie (Jimmy) 
> Cc: cho...@chopps.org; lsr@ietf.org
> Subject: Re:[Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency
> SID Advertisement"
>
> 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.
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.

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

[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
> 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;
> 抄送人：cho...@chopps.org;lsr@ietf.org;
> 日 期 ：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
> > -Original Message-----
> > From: peng.sha...@zte.com.cn [mailto:peng.sha...@zte.com.cn]
> > Sent: Friday, May 28, 2021 12:00 PM
> > To: Dongjie (Jimmy) 
> > Cc: cho...@chopps.org; lsr@ietf.org
> > Subject: Re:[Lsr] LSR WG Adoption Call for "Algorithm Related
> > IGP-Adjacency SID Advertisement"
> >
> > Hi Jie,
> >
> > Thanks for your comments.
> >
> > In this document, there are not any extensions to describe resource
> > reservation per algo. Are you aiming at an

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

[Dongjie (Jimmy)]

Hi PSF, 

Please see inline:

> -Original Message-
> From: peng.sha...@zte.com.cn [mailto:peng.sha...@zte.com.cn]
> Sent: Monday, May 31, 2021 9:41 AM
> To: Dongjie (Jimmy) 
> Cc: cho...@chopps.org; lsr@ietf.org
> Subject: Re:[Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency
> SID Advertisement"
> 
> 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.

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
> 
> 
> 
> 
> --原始邮件--
> 发件人：Dongjie(Jimmy)
> 收件人：彭少富10053815;
> 抄送人：cho...@chopps.org;lsr@ietf.org;
> 日 期 ：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
> > -Original Message-
> > From: peng.sha...@zte.com.cn [mailto:peng.sha...@zte.com.cn]
> > Sent: Friday, May 28, 2021 12:00 PM
> > To: Dongjie (Jimmy) 
> > Cc: cho...@chopps.org; lsr@ietf.org
> > Subject: Re:[Lsr] LSR WG Adoption Call for "Algorithm Related
> > IGP-Adjacency SID Advertisement"
> >
> > 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;lsr@ietf.org;
> > 日 期 ：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.

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

[peng.shaofu]

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

Hi Jie,

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

Regards,
PSF
发件人：Dongjie(Jimmy)
收件人：Christian Hopps;lsr@ietf.org;
日 期 ：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.
[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.

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.
[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
> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
> Sent: Thursday, May 27, 2021 4:57 AM
> To: lsr@ietf.org
> Cc: cho...@chopps.org
> Subject: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID
> Advertisement"
>
>
> 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.
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[peng.shaofu]

Hi Jie,






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






Regards,


PSF












原始邮件



发件人：Dongjie(Jimmy)
收件人：Christian Hopps;lsr@ietf.org;
日 期 ：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.  
 [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.




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. 

[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
 
> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
> Sent: Thursday, May 27, 2021 4:57 AM
> To: lsr@ietf.org
> Cc: cho...@chopps.org
> Subject: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID
> Advertisement" 
>  
>  
> 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.
>  
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
 
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[peng.shaofu]

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;
抄送人：cho...@chopps.org;lsr@ietf.org;
日 期 ：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
> -Original Message-
> From: peng.sha...@zte.com.cn [mailto:peng.sha...@zte.com.cn]
> Sent: Friday, May 28, 2021 12:00 PM
> To: Dongjie (Jimmy) 
> Cc: cho...@chopps.org; lsr@ietf.org
> Subject: Re:[Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency
> SID Advertisement"
>
> 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;lsr@ietf.org;
> 日 期 ：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
> > -Original Message-
> > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
> > Sent: Thursday, May 27, 2021 4:57 AM
> > To: lsr@ietf.org
> > Cc: cho...@chopps.org
> > Subject: [Lsr] LSR WG Adoption Call for "Algorithm Related
> > IGP-Adjacency SID Advertisement"
> >
> >
> > Hi Folks,
> >
> > This begins a 2 week WG Adoption Call for the follo

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

[chen.ran]

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
收件人：lsr@ietf.org;
抄送人：cho...@chopps.org;
日 期 ：2021年05月27日 05:00
主 题 ：[Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID 
Advertisement"



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.
 
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Robert Raszuk]

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.

On Wed, May 26, 2021 at 10:59 PM Christian Hopps  wrote:

>
> 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.
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Peter Psenak]

Hi Robin,

On 28/05/2021 13:08, Lizhenbin wrote:

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.


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




Best Regards,
Zhenbin (Robin)




-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
Sent: Thursday, May 27, 2021 4:57 AM
To: lsr@ietf.org
Cc: cho...@chopps.org
Subject: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID 
Advertisement"


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.

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

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




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

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

[Lizhenbin]

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:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
Sent: Thursday, May 27, 2021 4:57 AM
To: lsr@ietf.org
Cc: cho...@chopps.org
Subject: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID 
Advertisement"


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.

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

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

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

[Dongjie (Jimmy)]

Hi Peter,

Thanks for your reply. Please see inline:

> -Original Message-
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Friday, May 28, 2021 4:10 PM
> To: Dongjie (Jimmy) ; Christian Hopps
> ; lsr@ietf.org
> Subject: Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency
> SID Advertisement"
> 
> Hi Jimmy,
> 
> please see inline:
> 
> On 28/05/2021 05:39, Dongjie (Jimmy) wrote:
> > 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.
> 
> 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. 

> > 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.
> 
> "correlation between Flex-Algo and the network links is based on
> 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.
> 
> that's right, but I see no direct relationship with the above.

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.

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

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

Best regards,
Jie

> 
> 
> 
> thanks,
> Peter
> 
> >
> > Best regards,
> > Jie
> >
> >> -Original Message-
> >> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
> >> Sent: Thursday, May 27, 2021 4:57 AM
> >> To: lsr@ietf.org
> >> Cc: cho...@chopps.org
> >> Subject: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency
> SID
> >> Advertisement"
> >>
> >>
> >> 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-si
> d
> >> /
> >>
> >> 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.
> >>
> >> ___
> >> Lsr mailing list
> >> Lsr@ietf.org
> >> https://www.ietf.org/mailman/listinfo/lsr
> >
> > ___
> > Lsr mailing list
> > Lsr@ietf.org
> > https://www.ietf.org/mailman/listinfo/lsr
> >
> >

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

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

[Peter Psenak]

Hi Jimmy,

please see inline:

On 28/05/2021 05:39, Dongjie (Jimmy) wrote:

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.


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.





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.


"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 there is no intention to 
introduce per Flex-Algo ID link attributes.


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



Best regards,
Jie


-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
Sent: Thursday, May 27, 2021 4:57 AM
To: lsr@ietf.org
Cc: cho...@chopps.org
Subject: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID
Advertisement"


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.

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


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




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

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

[Dongjie (Jimmy)]

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

> -Original Message-
> From: peng.sha...@zte.com.cn [mailto:peng.sha...@zte.com.cn]
> Sent: Friday, May 28, 2021 12:00 PM
> To: Dongjie (Jimmy) 
> Cc: cho...@chopps.org; lsr@ietf.org
> Subject: Re:[Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency
> SID Advertisement"
> 
> 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;lsr@ietf.org;
> 日 期 ：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
> > -Original Message-
> > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
> > Sent: Thursday, May 27, 2021 4:57 AM
> > To: lsr@ietf.org
> > Cc: cho...@chopps.org
> > Subject: [Lsr] LSR WG Adoption Call for "Algorithm Related
> > IGP-Adjacency SID Advertisement"
> >
> >
> > Hi Folks,
> >
> > This begins a 2 week WG Adoption Call for the following draft:
> >
> > https://datatracker.ietf.org/doc/draft-peng-lsr-algorithm-related-adja
> > cency-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.
> >
> > ___
> > Lsr mailing list
> > Lsr@ietf.org
> > https://www.ietf.org/mailman/listinfo/lsr
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[peng.shaofu]

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;lsr@ietf.org;
日 期 ：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
> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
> Sent: Thursday, May 27, 2021 4:57 AM
> To: lsr@ietf.org
> Cc: cho...@chopps.org
> Subject: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID
> Advertisement"
>
>
> 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.
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Dongjie (Jimmy)]

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

> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
> Sent: Thursday, May 27, 2021 4:57 AM
> To: lsr@ietf.org
> Cc: cho...@chopps.org
> Subject: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID
> Advertisement"
> 
> 
> 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.
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

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

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

[peng.shaofu]

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
收件人：lsr@ietf.org;
抄送人：cho...@chopps.org;
日 期 ：2021年05月27日 05:00
主 题 ：[Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID 
Advertisement"

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.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Ketan Talaulikar (ketant)]

Hello All,

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

Thanks,
Ketan

-Original Message-
From: Lsr  On Behalf Of Christian Hopps
Sent: 27 May 2021 02:27
To: lsr@ietf.org
Cc: cho...@chopps.org
Subject: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID 
Advertisement"


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.

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

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

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

[Peter Psenak]

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:


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.

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




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