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

"li_zhenqiang@hotmail.com" <li_zhenqiang@hotmail.com> Fri, 04 December 2020 04:26 UTC

Return-Path: <li_zhenqiang@hotmail.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 75FED3A1302 for <lsr@ietfa.amsl.com>; Thu, 3 Dec 2020 20:26:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.089
X-Spam-Level:
X-Spam-Status: No, score=-1.089 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 OdGG0Ma7Jgkm for <lsr@ietfa.amsl.com>; Thu, 3 Dec 2020 20:26:19 -0800 (PST)
Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-oln040092254047.outbound.protection.outlook.com [40.92.254.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57EDE3A1301 for <lsr@ietf.org>; Thu, 3 Dec 2020 20:26:19 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BMQupvvphTBsNtdWc6rKDK5cJTCK3gWB2eRNw7w1mKg8acUfCcLD+40ivtcO/3Hw0Wuq9J3vy4koPKJxhHPTOhHlG7BNQzYNPI+g03ktzBueSuEjpHI/HaShcdZF/mZ4UKHKpvOJ4Siu/XVNYv2juWUDTzNiuC9rmggp781Y81Q7bdBdpLogQppYi3ayANNFvgvdKhIuVd9XGlPE3635eV9cHYo/JDghCVaREyV42ZulfAcP7qpeYLoCQy/Q2LUSKvqquWTrTUKKnFPGRvaJoCaD8OJ+9kEZpnxY0HKzWaWhehMrggK5b/Y9T2af6vOF7weprNoafgwHv9juJjxkyg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lhxG2BENTgi6dkMIH3ecWl8Dccu0qJq3loH0yqPkJbM=; b=KU4KVMsqtYi/8NfhGNUC+HB0gXunAfjTbRz8ZORj4PEFz6+dpzYkwdX6+mCaodhSUAaUtVRXGpcshVvfwDI45H1/1AAyNh0xvLhLeNlG4JKJ7LivMA6hSP+iVLn76lcIr1i6gBpiijVNhu6+KOpROUPvlp3goqkNzSqdeFUC3/7U+Rjh9Ypz6duXjFGrZ96FDMyUT4I1LVOl9OwIQ/8dQvkuoCnepa1cI68nXQTZb/NweYwNIaXN2Cy+kZo65eIVLzUeT7/ah5oWufGqtYsondFLh1wJ2DzzucxOsVsI+9lPxjXVZcwmi7l6wsKBXmwPJeS2CF9yMbuISVDYhQDnfg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lhxG2BENTgi6dkMIH3ecWl8Dccu0qJq3loH0yqPkJbM=; b=IREJcGDrLtbnxHxyzet/SJLbi1HYM9T7TgrEn0mxNQHs5uwCgF+HP6JGT9ywSRMcOpO/hHJvMK4jPckAdt70PC7LqA6RqEdJSysmOYMlAoGJGGeYE9ZpM8+IUg6Yw2VlX2jYWmFHQnOu8tTSc1hhlqA4f+XVJgaOyUMC5mI6VDufrCNEFU1lm9VISDMkMkmQo23aSbgh1yU3bh0ZTGnG1zVSL8BIQiCPqQcXsMSaNVGosbtfFbjnxfdWSNieSR1TYEBffmeSdT1VqrmUOScAm+1QJ3/SWTK3sxQ5XNJbi8D7/ajag6TCVN/1+h470yVEnoVfiVl5u4zGDrjE9vVKbA==
Received: from HK2APC01FT024.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebc::50) by HK2APC01HT065.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebc::402) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.17; Fri, 4 Dec 2020 04:26:12 +0000
Received: from MEYP282MB2022.AUSP282.PROD.OUTLOOK.COM (2a01:111:e400:7ebc::4e) by HK2APC01FT024.mail.protection.outlook.com (2a01:111:e400:7ebc::147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.17 via Frontend Transport; Fri, 4 Dec 2020 04:26:12 +0000
X-IncomingTopHeaderMarker: OriginalChecksum:A0BE9187EC214718198C55D28975291BA2CC65E45151DE39885C9BF6D5C0B464; UpperCasedChecksum:2CB25F3573BD52D286372547BEE09EC0D411CDAAA1AFF9546979E202EDFB631F; SizeAsReceived:8964; Count:46
Received: from MEYP282MB2022.AUSP282.PROD.OUTLOOK.COM ([fe80::ac76:b4ee:c4c3:c24a]) by MEYP282MB2022.AUSP282.PROD.OUTLOOK.COM ([fe80::ac76:b4ee:c4c3:c24a%3]) with mapi id 15.20.3632.017; Fri, 4 Dec 2020 04:26:12 +0000
Date: Fri, 04 Dec 2020 12:26:53 +0800
From: "li_zhenqiang@hotmail.com" <li_zhenqiang@hotmail.com>
To: 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>
X-Has-Attach: no
X-Mailer: Foxmail 7.2.9.156[cn]
Message-ID: <MEYP282MB20221971137C429BF2A10F07FCF10@MEYP282MB2022.AUSP282.PROD.OUTLOOK.COM>
Content-Type: multipart/alternative; boundary="----=_001_NextPart458673320488_=----"
X-TMN: [+h6F1f3trKhLDjbXCc36ye4EvXYEvsGf]
X-ClientProxiedBy: HK0PR03CA0104.apcprd03.prod.outlook.com (2603:1096:203:b0::20) To MEYP282MB2022.AUSP282.PROD.OUTLOOK.COM (2603:10c6:220:b4::7)
X-Microsoft-Original-Message-ID: <2020120412264964187223@hotmail.com>
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from cmcc-PC (223.72.105.28) by HK0PR03CA0104.apcprd03.prod.outlook.com (2603:1096:203:b0::20) with Microsoft SMTP Server (version=TLS1_1, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA) id 15.20.3632.17 via Frontend Transport; Fri, 4 Dec 2020 04:26:10 +0000
X-MS-PublicTrafficType: Email
X-IncomingHeaderCount: 46
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-Correlation-Id: 98f4f0e7-f3d2-4be1-7f52-08d8980cbae3
X-MS-TrafficTypeDiagnostic: HK2APC01HT065:
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: mNalAMT7XbuNJE1QXGoEN+Pa/HgWauUzPkBpRbtXMnY6HLi7Ok5+Kq7bXsG2rYp7ft4HWSFJR0UWjM/2cjQMwLjDNcR1il6lq66UT5HomO49aqs1DnEyzr3Wx0wsojgE2Dtf0YmUZ36vuZJojVyhjHjmZi6gg+xc+mMXf/+NH9kUDVZb50abUe2JLXFbMOlzoCeiAig9mvwjtqUBA6Fgc8iwhrTmZA8Xf9rdV5uOxY6HA7gEPA6Zs3K9bLbjACwY
X-MS-Exchange-AntiSpam-MessageData: mNe7PbDh3z7PYliQR1nrOGuqEa48TBHuFoD15vM4JDIRwjOvsv9zvtj8byYhADp1mzte7KHbYqNOyUymOhZfMg8q6B9kz0ulqqYe0WUAsCHIe8mgkmnzhoJnNoZYBCmsE+DObjK9iLfIC7jiLHeYag==
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 98f4f0e7-f3d2-4be1-7f52-08d8980cbae3
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Dec 2020 04:26:12.2733 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-AuthSource: HK2APC01FT024.eop-APC01.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: Internet
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK2APC01HT065
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/Bz5Mwh_YyhtiO8yGf0oqaEF3KAQ>
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 04:26:21 -0000

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

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? I wonder we can guarantee the loop free  path with IP Flex-Algorithm especially when the path is calculated distributedly?

Best Regards,
Zhenqiang Li


li_zhenqiang@hotmail.com
 
From: Jeff Tantsura
Date: 2020-12-04 09:18
To: Tony Li; Robert Raszuk
CC: lsr; Acee Lindem \(acee\)
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>, 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> 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