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 >>>> >>>> >>>> >>>>
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
