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

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 <hayabusagsm@gmail.com>
Sent: 11 June 2021 05:46
To: Ketan Talaulikar (ketant) <ketant@cisco.com>
Cc: chopps@chopps.org; lsr@ietf.org; peng.shaofu@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) <ketant@cisco.com<mailto:ketant@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 <hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com>>
Sent: 10 June 2021 18:54
To: Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>>
Cc: chopps@chopps.org<mailto:chopps@chopps.org>; lsr@ietf.org<mailto:lsr@ietf.org>; peng.shaofu@zte.com.cn<mailto:peng.shaofu@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) <ketant@cisco.com<mailto:ketant@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 <lsr-bounces@ietf.org<mailto:lsr-bounces@ietf.org>> On Behalf Of peng.shaofu@zte.com.cn<mailto:peng.shaofu@zte.com.cn>
Sent: 10 June 2021 11:48
To: hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; chopps@chopps.org<mailto:chopps@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 <chopps@chopps.org<mailto:chopps@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.mishra@verizon.com<mailto:gyan.s.mishra@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.mishra@verizon.com<mailto:gyan.s.mishra@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.mishra@verizon.com<mailto:gyan.s.mishra@verizon.com>

M 301 502-1347