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

Gyan Mishra <hayabusagsm@gmail.com> Sat, 16 April 2022 15:46 UTC

Return-Path: <hayabusagsm@gmail.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD913A17D3; Sat, 16 Apr 2022 08:46:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VT29q7OxtvOC; Sat, 16 Apr 2022 08:45:57 -0700 (PDT)
Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED0233A17D2; Sat, 16 Apr 2022 08:45:56 -0700 (PDT)
Received: by mail-pl1-x631.google.com with SMTP id q3so9267047plg.3; Sat, 16 Apr 2022 08:45:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/QnsrkNJgGgT7c0NidtSXAa1Xn+Yitol5O5pXHrjrKU=; b=iVAIZtkGkOGOgBGNlAesYRmJsRkH1r2MYoXZ43bnRw1mANHWDGFOwyjOiIOpdRg7hL DTMa4O0kVji2TMTEc0YOSco77LOqhjZlMZ5u3CVrnNzJBmGCY8PuwiPjn/f4X3V2uLHf 3aEcoAEOOhn6mdp4AVntIrOnIKjhgSL7pQf6bs3YmQvgj3p0SpOQSATRecdOxDNQ4mvd cOvybCLNz4NoNCpH20/eXRw4PhHH0b80LkoOGSY1zhxnsSIS6vQo15J1mfn+9aIzs1XE 207hoaQi41+kNASN2ij4+kc8wkLUIrGqpDeYg3Ci61BMzXVKUjH3OiL+X4Rh4tP4hxZy cctQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/QnsrkNJgGgT7c0NidtSXAa1Xn+Yitol5O5pXHrjrKU=; b=a7k7uVgK98Ad7LyIK97Y0wwIu6Cpm58SVPvh9doRgJkajEJ/+1c4R6t9UIyWrf2naJ tu1oJ7Uk/t7SwTax2qEw/g7e0q9bex2MF2wJxqktanE/H83O4j4kTqKNCsnxDHPCHSWl ybPlB0SlWuGydKeFootUqOikTdt/tmrA1dqujDEU0e4WJszKRjsSlxZRfu3oKxUyL3Io TPc1CCJ+0i0mNoz2fcEgYEO18AZ5duBShNQ7nNEneflrYy2bviIKS1UdZmc2sF9xffW7 CGAjJ6Y9dnTg4hoXMh0bvGhsczg9tJ7K/PCnsKyJxHcGMEsykan51HtUOT0AamrLSntY Jn5A==
X-Gm-Message-State: AOAM531Ct4wgMVay9pMerxvlXouwqQNyr5+GQgEB27xlL6pYnB9ezRqM YLa3laSrzJeEk/SCZK500WsRGwhsCnUZasGqzP0=
X-Google-Smtp-Source: ABdhPJypHRIiLAKeBL/cXRsMVUAIrmcxg1ERla7vKZnylJL557LuNqFb6w7G2aeQUMfXBYqRYwflPt6VhAP/gvcr0zc=
X-Received: by 2002:a17:90a:ee81:b0:1cb:ade8:6c61 with SMTP id i1-20020a17090aee8100b001cbade86c61mr4420371pjz.167.1650123955906; Sat, 16 Apr 2022 08:45:55 -0700 (PDT)
MIME-Version: 1.0
References: <CAH6gdPyXbPh0=k6KvZJyzyvapBrjjkby50MbmGNQOAG1GDX1OA@mail.gmail.com> <3FA9B00A-864D-464A-8BA5-368C1EDAC580@gmail.com> <CAH6gdPzQmuZAFvnDoUqH6ENNd5qCjLpgHidDhZ-etMt=Y5pqXw@mail.gmail.com>
In-Reply-To: <CAH6gdPzQmuZAFvnDoUqH6ENNd5qCjLpgHidDhZ-etMt=Y5pqXw@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Sat, 16 Apr 2022 11:45:45 -0400
Message-ID: <CABNhwV0hYRNzsvkbomzobGG79z738cv2J39Wx_tG55nL6QAfxA@mail.gmail.com>
To: Ketan Talaulikar <ketant.ietf@gmail.com>
Cc: "Acee Lindem (acee)" <acee@cisco.com>, "Peter Psenak (ppsenak)" <ppsenak@cisco.com>, draft-ietf-lsr-ip-flexalgo@ietf.org, lsr <lsr@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003a2c2f05dcc76c92"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/ouRJHIBA5c9GnHp7eIMUarh3hyY>
Subject: Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Apr 2022 15:46:03 -0000

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.ietf@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 <hayabusagsm@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.ietf@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 <hayabusagsm@gmail.com>
>> wrote:
>>
>>>
>>> Hi Acee
>>>
>>> Fixing a typo
>>>
>>> On Fri, Apr 15, 2022 at 10:34 PM Gyan Mishra <hayabusagsm@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) <acee@cisco.com>
>>>> wrote:
>>>>
>>>>> Gyan,
>>>>>
>>>>>
>>>>>
>>>>> What is your point here? Is this a trick question?
>>>>>
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Acee
>>>>>
>>>>>
>>>>>
>>>>> *From: *Gyan Mishra <hayabusagsm@gmail.com>
>>>>> *Date: *Friday, April 15, 2022 at 5:31 PM
>>>>> *To: *"Peter Psenak (ppsenak)" <ppsenak@cisco.com>
>>>>> *Cc: *Acee Lindem <acee@cisco.com>, Ketan Talaulikar <
>>>>> ketant.ietf@gmail.com>, "draft-ietf-lsr-ip-flexalgo@ietf.org" <
>>>>> draft-ietf-lsr-ip-flexalgo@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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*



*M 301 502-1347*