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 protected]> 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 <[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]> 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]> > *Sent:* 10 June 2021 18:54 > *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 > > > > See in-line > > > > Thanks > > > > Gyan > > > > On Thu, Jun 10, 2021 at 4:40 AM Ketan Talaulikar (ketant) < > [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]> On Behalf Of [email protected] > Sent: 10 June 2021 11:48 > To: [email protected] > Cc: [email protected]; [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]; > 日 期 ：2021年06月10日 13:05 > 主 题 ：Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency > SID Advertisement" > _______________________________________________ > Lsr mailing list > [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]> 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] > https://www.ietf.org/mailman/listinfo/lsr > > -- > > Gyan Mishra > Network Solutions Architect > Email [email protected] > M 301 502-1347 > > -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email [email protected] <[email protected]>* > > *M 301 502-1347* > > > > -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email [email protected] <[email protected]>* > > *M 301 502-1347* > > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347*
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
