Thank you Ketan. Ack on convergence on new term for application.š
Thanks Gyan On Sat, Apr 16, 2022 at 10:01 AM Ketan Talaulikar <[email protected]> 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 <[email protected]> > 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 <[email protected]> >> 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 <[email protected]> >> wrote: >> >>> >>> Hi Acee >>> >>> Fixing a typo >>> >>> On Fri, Apr 15, 2022 at 10:34 PM Gyan Mishra <[email protected]> >>> 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) <[email protected]> >>>> wrote: >>>> >>>>> Gyan, >>>>> >>>>> >>>>> >>>>> What is your point here? Is this a trick question? >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Acee >>>>> >>>>> >>>>> >>>>> *From: *Gyan Mishra <[email protected]> >>>>> *Date: *Friday, April 15, 2022 at 5:31 PM >>>>> *To: *"Peter Psenak (ppsenak)" <[email protected]> >>>>> *Cc: *Acee Lindem <[email protected]>, Ketan Talaulikar < >>>>> [email protected]>, "[email protected]" < >>>>> [email protected]>, "[email protected]" <[email protected]> >>>>> *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 >>>>> >>>>> >>>>> >>>>> >>>>> >>>> -- <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
