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

From: Huzhibo <[email-masked]>
Date: Tue, 1 Jun 2021 10:00:46 +0000

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

Hi Folks,

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
[email-masked]
https://www.ietf.org/mailman/listinfo/lsr

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 2 Jun 2021 11:50:37 +0800

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

Hi Folks,

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

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

Thanks,
Acee and Chris.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 2 Jun 2021 05:03:45 +0000

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

> From: Lsr <[email-masked]> On Behalf Of Christian Hopps
> Sent: Wednesday, May 26, 2021 1:57 PM
> To: [email-masked]
> Cc: [email-masked]

---

From: <[email-masked]>
Date: Thu, 3 Jun 2021 10:42:05 +0800 (CST)

Hi Aijun,

Thanks for your comments.
Please see inline [PSF]

Regards,
PSF

------------------原始邮件------------------
发件人：AijunWang
收件人：'Christian Hopps';[email-masked];
日 期 ：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.

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

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

[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

---

From: <[email-masked]>
Date: Thu, 3 Jun 2021 11:28:33 +0800 (CST)

Hi Les,

Please see inline [PSF].

Regards,
PSF

------------------原始邮件------------------
发件人：LesGinsberg(ginsberg)
收件人：Christian Hopps;[email-masked];
日 期 ：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.

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

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

Les

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 10 Jun 2021 01:04:59 -0400

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

-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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

*M 301 502-1347*

---

From: <[email-masked]>
Date: Thu, 10 Jun 2021 14:17:42 +0800 (CST)

Hi Gyan,

Thanks for your support.
Please see inline [PSF]

Regards,
PSF

------------------原始邮件------------------
发件人：GyanMishra
收件人：Christian Hopps;
抄送人：[email-masked];
日 期 ：2021年06月10日 13:05

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.

[PSF] Yes.

[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

Hi Folks,

Thanks,
Acee and Chris.

--

Gyan Mishra
Network Solutions Architect
Email [email-masked]
M 301 502-1347

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Thu, 10 Jun 2021 07:55:57 +0000

Hi authors,

I have reviewed the document and agree with Les.

Please remove the mechanisms that haven't been defined in the existing Flex-algo based on draft-ietf-lsr-flex-algo, including using algorithm related IGP-Adjacency SID to allocate resource/select queue/distinguish traffic/determine Qos Policy, which will make the readers confused and blur the theme of document.

Best

Xuesong

-----Original Message-----
From: Lsr [mailto:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Wednesday, June 2, 2021 1:04 PM
To: Christian Hopps <[email-masked]>; [email-masked]
Subject: Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID Advertisement"

   Les

> From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Christian Hopps

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

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

> Subject: [Lsr] LSR WG Adoption Call for "Algorithm Related

> IGP-Adjacency SID Advertisement"

> https://datatracker.ietf.org/doc/draft-peng-lsr-algorithm-related-adja

> cency-

> Authors, please respond to the list indicating whether you are aware

> of any IPR that applies to this draft.

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

Lsr mailing list

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

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 10 Jun 2021 08:20:00 +0000

Hi Gyan,

Please see some comments inline:

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

[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 <[email-masked]<mailto:[email-masked]>> wrote:

Hi Folks,

Thanks,
Acee and Chris.

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

Gyan Mishra

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

M 301 502-1347

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 10 Jun 2021 08:40:14 +0000

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 <[email-masked]> On Behalf Of [email-masked]
Sent: 10 June 2021 11:48
To: [email-masked]
Cc: [email-masked]; [email-masked]
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;
抄送人：[email-masked];
日 期 ：2021年06月10日 13:05

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

[PSF] Yes.

[PSF] No.

Kind Regards

Gyan

Hi Folks,

Thanks,
Acee and Chris.

--

Gyan Mishra

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 10 Jun 2021 09:24:13 -0400

Hi Ketan

See in-line

Thanks

Gyan

On Thu, Jun 10, 2021 at 4:40 AM Ketan Talaulikar (ketant) <[email-masked]>
wrote:

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

> [PSF] For SRv6, tt was born with this ability, since SRv6 END.X SID can be
> allocated from an algorithm specific Locator.
>
>
> [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
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 10 Jun 2021 15:08:54 +0000

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 <[email-masked]>
Sent: 10 June 2021 18:54
To: Ketan Talaulikar (ketant) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
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) <[email-masked]<mailto:[email-masked]>> wrote:
One quick clarification on the following:

    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 <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 10 June 2021 11:48
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
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;
抄送人：[email-masked]<mailto:[email-masked]>;
日 期 ：2021年06月10日 13:05

[PSF] Yes.

[PSF] No.

Kind Regards

Gyan

Hi Folks,

Thanks,
Acee and Chris.

--

Gyan Mishra

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

Gyan Mishra

M 301 502-1347

---

From: Christian Hopps <[email-masked]>
Date: Thu, 10 Jun 2021 11:11:25 -0400

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.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 10 Jun 2021 19:14:28 +0000

I agree with Ketan.
Thanks,
Acee

From: Lsr <[email-masked]> on behalf of "Ketan Talaulikar (ketant)" <ketant=[email-masked]>
Date: Thursday, June 10, 2021 at 11:10 AM
To: Gyan Mishra <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Christian Hopps <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID Advertisement"

Hi Gyan,

Thanks,
Ketan

Hi Ketan

See in-line

Thanks

Gyan

Thanks,
Ketan

-----Original Message-----
From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 10 June 2021 11:48
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
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;

[PSF] Yes.

[PSF] No.

Kind Regards

Gyan

Hi Folks,

Thanks,
Acee and Chris.

--

Gyan Mishra

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

Gyan Mishra

M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 10 Jun 2021 20:16:22 -0400

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) <[email-masked]>
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 <[email-masked]>
> *Sent:* 10 June 2021 18:54
> *To:* Ketan Talaulikar (ketant) <[email-masked]>
> *Cc:* [email-masked]; [email-masked]; [email-masked]
> *Subject:* Re: [Lsr] LSR WG Adoption Call for "Algorithm Related
> On Thu, Jun 10, 2021 at 4:40 AM Ketan Talaulikar (ketant) <
> [email-masked]> wrote:
>
> *Network Solutions Architect *
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 10 Jun 2021 21:36:58 -0400

Hi Jimmy

Please see my comments in-line:

Thanks

Gyan
On Thu, Jun 10, 2021 at 4:20 AM Dongjie (Jimmy) <[email-masked]> wrote:

> *From:* Lsr [mailto:[email-masked]] *On Behalf Of *Gyan Mishra
> *Sent:* Thursday, June 10, 2021 1:05 PM
> *To:* Christian Hopps <[email-masked]>
> *Cc:* [email-masked]
> [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
>
>
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 11 Jun 2021 02:25:14 +0000

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

Sent: 11 June 2021 05:46

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

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) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Gyan,

Thanks,
Ketan

From: Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Sent: 10 June 2021 18:54
To: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID Advertisement"

Hi Ketan

See in-line

Thanks

Gyan

Thanks,
Ketan

-----Original Message-----
From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 10 June 2021 11:48
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
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;

[PSF] Yes.

[PSF] No.

Kind Regards

Gyan

Hi Folks,

Thanks,
Acee and Chris.

--

Gyan Mishra

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 11 Jun 2021 02:42:42 +0000

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:[email-masked]] On Behalf Of Gyan Mishra
Sent: Friday, June 11, 2021 9:37 AM
To: Dongjie (Jimmy) <[email-masked]>
Cc: [email-masked]; Christian Hopps <[email-masked]>
Subject: Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID Advertisement"

Hi Jimmy

Thanks

Gyan
On Thu, Jun 10, 2021 at 4:20 AM Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Gyan,

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

[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

Hi Folks,

Thanks,
Acee and Chris.

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 10 Jun 2021 23:06:43 -0400

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) <[email-masked]>
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
>
>
>
> *Sent:* 11 June 2021 05:46
> On Thu, Jun 10, 2021 at 11:09 AM Ketan Talaulikar (ketant) <
> [email-masked]> wrote:
>
> Hi Gyan,
>
>
>
-- 

*Gyan Mishra*

*M 301 502-1347*