Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

Peter Psenak <ppsenak@cisco.com> Fri, 04 December 2020 09:18 UTC

Return-Path: <ppsenak@cisco.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 7E1403A0C20 for <lsr@ietfa.amsl.com>; Fri, 4 Dec 2020 01:18:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.602
X-Spam-Level:
X-Spam-Status: No, score=-9.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 77hOJvK0F_sE for <lsr@ietfa.amsl.com>; Fri, 4 Dec 2020 01:18:19 -0800 (PST)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B2273A1224 for <lsr@ietf.org>; Fri, 4 Dec 2020 01:18:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4884; q=dns/txt; s=iport; t=1607073499; x=1608283099; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=RqPKw806POWlX/pEAPBBClDQPlM980Gd7ui0IUBkcys=; b=lAFwI/nQqlSarn3g0farhDBW8DaNMpMeDqNNt3lO7PpCLk5TvNusRtqT 41u8i0KjakDXH5+6FY6J97NnzjvTMoCS2bIiux89m1bGZnrIW9VHAFgt4 oaeh7j+dx3wPiVf1pruuBGQr1b1PRFH+sI0s+oLZklRODygfoV9EYokzY g=;
X-IPAS-Result: =?us-ascii?q?A0CbAABH/slf/xbLJq1iGgEBAQEBAQEBAQEDAQEBARIBA?= =?us-ascii?q?QEBAgIBAQEBQIFPgx9XASASLoQ8iQSHdC0DgnCHJ5AzgWgLAQEBDxgLDAQBA?= =?us-ascii?q?YRKAoIWJjgTAgMBAQEDAgMBAQEBBQEBAQIBBgRxhWEMhXIBAQEBAgEBARsGD?= =?us-ascii?q?wEFNgsQCxEDAQIBAgIRDgQDAgIhBh8JCAYBDAYCAQGDIgGCVQMOIA+qYXaBM?= =?us-ascii?q?oRSQUSCZw1igTwGgQ4qhVlOgUiBPoQugUE/gRABJ4Fzfj6CG0IBAQIBAYEUb?= =?us-ascii?q?RmCWIJfBIFVEIEyCAciGQgQTQILIBxtK49oinicWVeCfIMehXuNBAGFCwUHA?= =?us-ascii?q?x+DIYohhSsqjw6GEI1iiwiCdY5IhHiBbSOBVzMaCBsVO4JpUBkNji0XFIhOh?= =?us-ascii?q?UVAAzACNQIGAQkBAQMJkDwBAQ?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.78,392,1599523200"; d="scan'208";a="29205818"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Dec 2020 09:18:15 +0000
Received: from [10.60.140.52] (ams-ppsenak-nitro3.cisco.com [10.60.140.52]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id 0B49IEJ4010932; Fri, 4 Dec 2020 09:18:14 GMT
To: "li_zhenqiang@hotmail.com" <li_zhenqiang@hotmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Tony Li <tony1athome@gmail.com>, Robert Raszuk <robert@raszuk.net>
Cc: lsr <lsr@ietf.org>, "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>
References: <777B2AC4-CACF-4AB0-BFC7-B0CFFA881EEB@cisco.com> <CAOj+MMEmmFfN228okgFGM09qaiB8s0nS_8rQEqwBVsdJidy8XA@mail.gmail.com> <F1AE46BD-5809-467A-9CE1-69C08406CB40@gmail.com> <CAOj+MMED+kWaT8Hr-ohq8U1ADYrcNCQDX-svADzVjbo81urJ8A@mail.gmail.com> <5ec998de-115b-4a0a-818d-5df893082d49@Spark> <MEYP282MB20221971137C429BF2A10F07FCF10@MEYP282MB2022.AUSP282.PROD.OUTLOOK.COM>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <ff2a1d71-ca74-75f9-8c2f-91338b2f1213@cisco.com>
Date: Fri, 4 Dec 2020 10:18:14 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <MEYP282MB20221971137C429BF2A10F07FCF10@MEYP282MB2022.AUSP282.PROD.OUTLOOK.COM>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.60.140.52, ams-ppsenak-nitro3.cisco.com
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/yQALoRle3bIdDiur8GGoFoDlqiQ>
Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
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: Fri, 04 Dec 2020 09:18:22 -0000

Zhenqiang,

On 04/12/2020 05:26, li_zhenqiang@hotmail.com wrote:
> Hello All,
> 
> I've read the draft and support its adoption. I have some comments as 
> follows.
> 
> 1. I agree with Jeff that Flex Algo represents a sub- topology 
> consisting of the participating nodes, which we can also call a virtual 
> network. In this specific virtual network that the corresponding flex 
> algo calculation is applied.
> 
> 2. For section three, why do we need one loopback address for 
> one Flex-Algorithm? 

that's how you represent an algo specific path.

Can't we associate multiple Flex-Algorithms with one
> loopback address, which means we want to reach the loopback address 
> through different paths?

no. You need some data-plane separation. In SR it's a SID, here, given 
it's IP based, you need a separate IP prefix.


> 
> 3. The second paragraph in section 3 does not describe Egress Node 
> Procedures. This paragraph should be put in a seperate section.
> 
> 4. I want to know the path for a specific IP Flex-Algorithm is 
> calculated distributedly by each nodes paticipating this Flex-Algorithm 
> or calculated centralized by an controller? 

it's a distributed calculation.

I wonder we can guarantee
> the loop free  path with IP Flex-Algorithm especially when the path is 
> calculated distributedly?

we MUST guarantee the consistency and it's done via FAD. Please look at 
the original FA draft:

https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/



thanks,
Peter

> 
> Best Regards,
> Zhenqiang Li
> ------------------------------------------------------------------------
> li_zhenqiang@hotmail.com
> 
>     *From:* Jeff Tantsura <mailto:jefftant.ietf@gmail.com>
>     *Date:* 2020-12-04 09:18
>     *To:* Tony Li <mailto:tony1athome@gmail.com>; Robert Raszuk
>     <mailto:robert@raszuk.net>
>     *CC:* lsr <mailto:lsr@ietf.org>; Acee Lindem \(acee\)
>     <mailto:acee=40cisco.com@dmarc.ietf.org>
>     *Subject:* Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms
>     (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
>     Anything else than IGP metric based SPT is considered TE. Looking
>     holistically - topology virtualization (or similar) could have been
>     a better name.
> 
>     Cheers,
>     Jeff
>     On Dec 3, 2020, 4:25 PM -0800, Robert Raszuk <robert@raszuk.net>et>, wrote:
>>     Hi Tony,
>>
>>     The moment I hit "Send" I knew that this response may be coming as
>>     it really depends what is one's definition of TE.
>>
>>     If indeed IGP TE is anything more then SPF - then sure we can call
>>     it a TE feature.
>>
>>     However, while a very useful and really cool proposal, my point is
>>     to make sure this is not oversold - that's all.
>>
>>     Best,
>>     R.
>>
>>
>>     On Fri, Dec 4, 2020 at 1:13 AM Tony Li <tony1athome@gmail.com
>>     <mailto:tony1athome@gmail.com>> wrote:
>>
>>
>>         Hi Robert,
>>
>>
>>         > However I really do not think that what Flexible Algorithm
>>         offers can be compared or even called as Traffic Engineering
>>         (MPLS or SR).
>>         >
>>         > Sure Flex Algo can accomplish in a very elegant way with
>>         little cost multi topology routing but this is not full TE. It
>>         can also direct traffic based on static or dynamic network
>>         preferences (link colors, rtt drops etc ... ),  but again it
>>         is not taking into account load of the entire network and IMHO
>>         has no way of accomplish TE level traffic distribution.
>>         >
>>         > Just to make sure the message here is proper.
>>
>>
>>         It’s absolutely true that FlexAlgo (IP or SR) has limitations.
>>         There’s no bandwidth reservation. There’s no dynamic load
>>         balancing. No, it’s not a drop in replacement for RSVP. No, it
>>         does not supplant SR-TE and a good controller. Etc., etc., etc….
>>
>>         However I don’t feel that it’s fair to say that FlexAlgo can’t
>>         be called Traffic Engineering.  After all TE is a very broad
>>         topic. Everything that we’ve done that’s more sophisticated
>>         than simple SPF falls in the area of Traffic Engineering. 
>>         Link coloring and SRLG alone clearly fall into that bucket.
>>
>>         I’ll grant you that it may not have the right TE features for
>>         your application, but that doesn’t mean that it’s not
>>         sufficient for some.  Please don’t mislead people by saying
>>         that it’s not Traffic Engineering.
>>
>>         Regards,
>>         Tony
>>
>>
>>     _______________________________________________
>>     Lsr mailing list
>>     Lsr@ietf.org
>>     https://www.ietf.org/mailman/listinfo/lsr
>