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