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 <[email protected]> Sent: 11 June 2021 05:46 To: Ketan Talaulikar (ketant) <[email protected]> Cc: [email protected]; [email protected]; [email protected] 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) <[email protected]<mailto:[email protected]>> 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 protected]<mailto:[email protected]>> Sent: 10 June 2021 18:54 To: Ketan Talaulikar (ketant) <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> 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 protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> On Behalf Of [email protected]<mailto:[email protected]> Sent: 10 June 2021 11:48 To: [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> 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 protected]<mailto:[email protected]>; 日 期 ：2021年06月10日 13:05 主 题 ：Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID Advertisement" _______________________________________________ Lsr mailing list [email protected]<mailto:[email protected]> 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 <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/lsr -- Gyan Mishra Network Solutions Architect Email [email protected]<mailto:[email protected]> M 301 502-1347 -- [http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/> Gyan Mishra Network Solutions Architect Email [email protected]<mailto:[email protected]> M 301 502-1347 -- [http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/> Gyan Mishra Network Solutions Architect Email [email protected]<mailto:[email protected]> M 301 502-1347
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
