Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

[Ketan Talaulikar <[e-mail]>]

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 <[e-mail]> wrote:

>
> Hi Acee
>
> Fixing a typo
>
> On Fri, Apr 15, 2022 at 10:34 PM Gyan Mishra <[e-mail]>
> 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) <[e-mail]>
>> wrote:
>>
>>> Gyan,
>>>
>>>
>>>
>>> What is your point here? Is this a trick question?
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Acee
>>>
>>>
>>>
>>> *From: *Gyan Mishra <[e-mail]>
>>> *Date: *Friday, April 15, 2022 at 5:31 PM
>>> *To: *"Peter Psenak (ppsenak)" <[e-mail]>
>>> *Cc: *Acee Lindem <[e-mail]>, Ketan Talaulikar <
>>> [e-mail]>, "[e-mail]" <
>>> [e-mail]>, "[e-mail]" <[e-mail]>
>>> *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
>>>
>>>
>>>
>>>
>>>
>>