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>
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>
> *Sent:* 10 June 2021 18:54
> *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
>
>
>
> See in-line
>
>
>
> Thanks
>
>
>
> Gyan
>
>
>
> On Thu, Jun 10, 2021 at 4:40 AM Ketan Talaulikar (ketant) <
> 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> On Behalf Of peng.shaofu@zte.com.cn
> Sent: 10 June 2021 11:48
> To: hayabusagsm@gmail.com
> Cc: lsr@ietf.org; 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;
> 日 期 ：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 <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
> https://www.ietf.org/mailman/listinfo/lsr
>
> --
>
> Gyan Mishra
> Network Solutions Architect
> Email gyan.s.mishra@verizon.com
> M 301 502-1347
>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>
> *M 301 502-1347*
>
>
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*

*M 301 502-1347*