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"

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

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

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

--

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

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

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"

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

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



*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"

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

--

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

[Image removed by sender.]

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

[Lsr] I-D Action: draft-ietf-lsr-algorithm-related-adjacency-sid-00.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.

Title   : Algorithm Related IGP-Adjacency SID Advertisement
Authors : Shaofu Peng
  Ran Chen
  Ketan Talaulikar
  Peter Psenak
Filename: draft-ietf-lsr-algorithm-related-adjacency-sid-00.txt
Pages   : 13
Date: 2021-06-10

Abstract:
   Segment Routing architecture supports the use of multiple routing
   algorithms, i.e, different constraint-based shortest-path
   calculations can be supported.  There are two standard algorithms:
   SPF and Strict-SPF, defined in Segment Routing architecture.  There
   are also other user defined algorithms according to Flex-algo
   applicaiton.  However, an algorithm identifier is often included as
   part of a Prefix-SID advertisement, that maybe not satisfy some
   scenarios where multiple algorithm share the same link resource.
   This document complement that the algorithm identifier can be also
   included as part of a Adjacency-SID advertisement


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-algorithm-related-adjacency-sid/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-algorithm-related-adjacency-sid-00


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
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]

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

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: 图像已被发件人删除。] 
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email gyan.s.mis...@verizon.com *
>
> *M 301 502-1347*
>
>
>
-- 



*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)]

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

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] On Behalf 
Of Gyan Mishra
Sent: Thursday, June 10, 2021 1:05 PM
To: Christian Hopps mailto:cho...@chopps.org>>
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 
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
https://www.ietf.org/mailman/listinfo/lsr
--

[图像已被发件人删除。]

Gyan Mishra

Network Solutions Architect

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

M 301 502-1347

--

[图像已被发件人删除。]

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]

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