Hi Acee
Responses in-line
On Sat, Apr 16, 2022 at 5:53 PM Acee Lindem (acee) <a...@cisco.com> wrote:
> Again, speaking as WG member:
>
> Hi Gyan, Ketan,
>
> I agree since for the IGPs we’ve traditionally used “application” for
> control plane routing applications (shortest-path, RSVP TE, SR, etc.). I
> know Robert suggested “logical data plane”… What are the thoughts on this?
>
> Gyan> I read through the comments on the thread related to ASLA and
> confusion with the word application defining a data plane which I and I
> think most in the WG agree the term application being applied to a data
> plane is no doubt confusing.
>
I am good with “logical data plane”. Data plane instance, identifier,
slice or transport would work as well.
>
>
> Thanks,
> Acee
>
>
>
> *From: *Gyan Mishra <hayabusa...@gmail.com>
> *Date: *Saturday, April 16, 2022 at 11:46 AM
> *To: *Ketan Talaulikar <ketant.i...@gmail.com>
> *Cc: *Acee Lindem <a...@cisco.com>, "Peter Psenak (ppsenak)" <
> ppse...@cisco.com>, "draft-ietf-lsr-ip-flexa...@ietf.org" <
> draft-ietf-lsr-ip-flexa...@ietf.org>, lsr <lsr@ietf.org>
> *Subject: *Re: [Lsr] Working Group Last Call for
> draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm)
> In IP Networks"
>
>
>
> Thank you Ketan.
>
>
>
> Ack on convergence on new term for application.😃
>
>
>
> Thanks
>
>
>
> Gyan
>
>
>
> On Sat, Apr 16, 2022 at 10:01 AM Ketan Talaulikar <ketant.i...@gmail.com>
> wrote:
>
> Hi Gyan,
>
>
>
> Your proposal looks ok to me. Note though that we seem to be converging
> towards using an alternate term instead of "application" in this context.
>
>
>
> Thanks,
>
> Ketan
>
>
>
>
>
> On Sat, Apr 16, 2022 at 12:50 PM Gyan Mishra <hayabusa...@gmail.com>
> wrote:
>
>
>
> Hi Ketan
>
>
>
> My understanding was that IGP Flex Algo could only be used with SR-MPLS or
> SRv6 data plane using prefix SID or SRv6 locator to steer packets.
>
>
>
> So it was my understanding that the IP Flex Algo draft was providing a
> solution for IP based networks ( Non SR-MPLS or SRv6) networks which was
> valuable gap to be filled.
>
>
>
> However your editorial comments shed some light that IGP Flex Algo may be
> used in IP based ( Non SR-MPLD or SRv6) based networks. This is confusing
> to me however below paragraph makes it more clear to me as to why you
> stated IGP Flex Algo is open to beyond SR ( even though not yet developed).
>
>
>
> IGP Flex Algo draft Section 14 describes forwarding plane use cases for
> Flex Algo which are SR-MPLS and SRv6 and 14.3 mentions that any application
> that wants to use Flex Algo can use it but that application needs to be
> developed to install the Flex Algo entires into the forwarding plane such
> as for RSVP-TE or native IPv4 or IPv6 forwarding plane.
>
>
>
> I think if IGP Flex Algo was developed as part of the draft to support
> other applications such as RSVP-TE and native IPv4 or IPv6 forwarding plane
> I think we could say that IGP Flex Algo can be used outside of SR data
> plane but that development has not been done even though it maybe possible
> in the future once developed or it may never be developed based on industry
> demand. So I think it’s safe to say at this time IGP Flex Algo only
> supports SR-MPLS and SRv6 forwarding planes only. However now once IP Flex
> Algo is published and implemented we can safely say that it has been
> extended beyond SR data plane.
>
>
>
> I would change the verbiage slightly to make it more clear. You mention
> that the IGP Flex Algo draft is the base Flex Algo draft but I disagree as
> if it were then the IP Flex Algo draft or any other application of Flex
> Algo with a new data plane would be an update to the base Flex Algo draft
> but here in this case I don’t think so and even for any other application.
> Each data plane instance of Flex Algo starting with the IP Flex Algo draft
> and then maybe future RSVP Flex Algo draft would be their own independent
> “base” Flex Algo draft onto themselves. That is one option, to keep each
> data plane specification of Flex Algo independent specifications.
>
>
>
> If we think that IP Flex Algo and future data plane applications such as
> RSVP-TE and beyond will be extensions of the IGP Base specification, so
> then will be updates to the base specification, then I think we can call IP
> Flex Algo an extension to the base specification.
>
>
>
> This is what I think the verbiage should state which is a hybrid of yours
> and Peter’s verbiage.
>
>
>
> This is if each application is standalone per data plane and is not an
> extension and so IGP Flex Algo would not be a base specification.
>
>
>
> NEW
>
>
>
> > An IGP Flexible Algorithm (Flex-Algorithm) allows the IGP to compute
> > constraint-based paths. The IGP Flex-Algorithm specification
> > currently only supports the application Segment Routing with (SR)
> data planes - SR MPLS and
> > SRv6.
> >
> > This document specifies IGP Flex-Algorithm, so that it can be used
> in any IP network
> > for native IPv4 and IPv6 forwarding in the absence of SR.
>
>
>
>
>
> Verbiage if IGP Flex Algo is a base and this draft is an extension and
> updates the base. We don’t have to say IGP Flex Algo currently only
> supports dropping the word currently as we are now extending with IP Flex
> Algo.
>
>
>
> > NEW
> >
> > An IGP Flexible Algorithm (Flex-Algorithm) allows the IGP to compute
> > constraint-based paths. The base IGP Flex-Algorithm specification
> only supports the application Segment Routing with (SR) data planes - SR
> MPLS and SRv6.
> >
> > This document extends IGP Flex-Algorithm, so that it can be used
> > natively with IPv4 and IPv6 forwarding.
>
>
>
>
>
>
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
> Sent from my iPhone
>
>
>
> On Apr 16, 2022, at 12:21 AM, Ketan Talaulikar <ketant.i...@gmail.com>
> wrote:
>
> Hi Gyan,
>
>
>
> I am not sure what the confusion is here. The following is how Peter and I
> concluded this point. My comment was of editorial nature.
>
>
>
> Thanks,
>
> Ketan
>
>
>
> > > 3) This draft makes assertions that IGP FlexAlgo cannot be
> deployed
> > > without SR. This is not true since the base IGP FlexAlgo spec
> > explicitly
> > > opens it up for usage outside of the SR forwarding plane. We
> already
> > > have BIER and MLDP forwarding planes as users of the IGP
> > FlexAlgo. My
> > > suggestion is to remove such assertions from the document. It is
> > > sufficient to just say that the document enables the use of IGP
> > FlexAlgo
> > > for IP prefixes with native IP forwarding.
> >
> > ##PP
> > where do you see such assertion? Each flex-algo data-plane/app can be
> > deployed independently.
> >
> >
> > KT> Let me clarify what I meant by taking the example of the abstract.
> >
> > OLD
> >
> > An IGP Flexible Algorithm (Flex-Algorithm) allows IGP to compute
> > constraint-based paths. As currently defined, IGP Flex-Algorithm is
> > used with Segment Routing (SR) data planes - SR MPLS and SRv6.
> > Therefore, Flex-Algorithm cannot be deployed in the absence of SR.
> >
> > This document extends IGP Flex-Algorithm, so that it can be used for
> > regular IPv4 and IPv6 prefixes. This allows Flex-Algorithm to be
> > deployed in any IP network, even in the absence of SR.
> >
> >
> > NEW
> >
> > An IGP Flexible Algorithm (Flex-Algorithm) allows IGP to compute
> > constraint-based paths. The base IGP Flex-Algorithm document
> > specified use with Segment Routing (SR) data planes - SR MPLS and
> > SRv6.
> >
> > This document extends IGP Flex-Algorithm, so that it can be used with
> > regular IPv4 and IPv6 forwarding.
>
> ##PP2
> ok
>
>
>
> On Sat, Apr 16, 2022 at 8:07 AM Gyan Mishra <hayabusa...@gmail.com> wrote:
>
>
>
> Hi Acee
>
>
>
> Fixing a typo
>
>
>
> On Fri, Apr 15, 2022 at 10:34 PM Gyan Mishra <hayabusa...@gmail.com>
> wrote:
>
>
>
> Hi Acee
>
>
>
> My question cane up from the list of questions posed by Ketan and Peter’s
> response to question #3.
>
>
>
> See excerpt below.
>
>
>
> I am confused by what Ketan stated in his question below and also Peter’s
> response which is why I am asking the question again.
>
>
>
> I believe the goal of the draft is for Flex Ago to be deployed
> independently of SR filling the gap of IGP Flex Algo providing that
> solution. So based on what Ketan stated in his question that IGP Flex Algo
> is data plane agnostic and can be used with IP data plane then there is no
> gap to be filled by this draft.
>
>
>
> Maybe I am misreading Ketan’s question.
>
>
>
> So this is a very important point made by Ketan that if IGP Flex Algo is
> open to usage “outside of SR”, then it is very important to restate the
> goal of this draft, removing assertions in the draft that this draft is for
> non SR IP data planes, as that can be accomplished today by IGP Flex Algo,
> and the gap or new solution being filled by this draft is for IP prefix
> based Flex Algo with Native IP Forwarding.
>
>
>
> This as well is quite confusing to me as if IGP Flex Algo can be used
> outside of SR then can do everything that this draft is supposed to
> accomplish.
>
>
>
> So what then is the purpose of this draft?
>
>
>
> In Peter’s response is stated that each Flex Algo data plane / app can be
> deployed independently meaning this draft and IGP flex Algo can act as 2
> ships in the night. Also confusing.
>
>
>
> 3) This draft makes assertions that IGP FlexAlgo cannot be deployed
> > without SR. This is not true since the base IGP FlexAlgo spec explicitly
> > opens it up for usage outside of the SR forwarding plane. We already
> > have BIER and MLDP forwarding planes as users of the IGP FlexAlgo. My
> > suggestion is to remove such assertions from the document. It is
> > sufficient to just say that the document enables the use of IGP FlexAlgo
> > for IP prefixes with native IP forwarding.
>
> ##PP
> where do you see such assertion? Each flex-algo data-plane/app can be
> deployed independently.
>
>
>
>
>
>
>
> On Fri, Apr 15, 2022 at 7:51 PM Acee Lindem (acee) <a...@cisco.com> wrote:
>
> Gyan,
>
>
>
> What is your point here? Is this a trick question?
>
>
>
> Thanks,
>
> Acee
>
>
>
> *From: *Gyan Mishra <hayabusa...@gmail.com>
> *Date: *Friday, April 15, 2022 at 5:31 PM
> *To: *"Peter Psenak (ppsenak)" <ppse...@cisco.com>
> *Cc: *Acee Lindem <a...@cisco.com>, Ketan Talaulikar <
> ketant.i...@gmail.com>, "draft-ietf-lsr-ip-flexa...@ietf.org" <
> draft-ietf-lsr-ip-flexa...@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>
> *Subject: *Re: [Lsr] Working Group Last Call for
> draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm)
> In IP Networks"
>
>
>
>
>
> Hi Peter
>
>
>
> My understanding is that the main goal of this draft is to be able to use
> flex algo over IPv4 or IPv6 data plane as that is not possible with
> existing Flex Algo which can only be used on SR data plane.
>
>
>
> Is that correct or am I missing something?
>
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo
>
>
>
>
>
> Abstract
>
>
>
> An IGP Flexible Algorithm (Flex-Algorithm) allows IGP to compute
>
> constraint-based paths. As currently defined, IGP Flex-Algorithm is
>
> used with Segment Routing (SR) data planes - SR MPLS and SRv6.
>
> Therefore, Flex-Algorithm cannot be deployed in the absence of SR.
>
>
>
> This document extends IGP Flex-Algorithm, so that it can be used for
>
> regular IPv4 and IPv6 prefixes. This allows Flex-Algorithm to be
>
> deployed in any IP network, even in the absence of SR.
>
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-19
>
>
>
> Abstract
>
>
>
> IGP protocols traditionally compute best paths over the network based
>
> on the IGP metric assigned to the links. Many network deployments
>
> use RSVP-TE based or Segment Routing based Traffic Engineering to
>
> steer traffic over a path that is computed using different metrics or
>
> constraints than the shortest IGP path. This document proposes a
>
> solution that allows IGPs themselves to compute constraint-based
>
> paths over the network. This document also specifies a way of using
>
> Segment Routing (SR) Prefix-SIDs and SRv6 locators to steer packets
>
> along the constraint-based paths.
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
>
>
> --
>
> [image: Image removed by sender.] <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>*
>
> *M 301 502-1347*
>
>
>
--
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>*
*M 301 502-1347*
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
