Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

Peter Psenak <ppsenak@cisco.com> Wed, 03 March 2021 09:34 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 5A7833A1DD2 for <lsr@ietfa.amsl.com>; Wed, 3 Mar 2021 01:34:15 -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 O-rrcfaCPc_j for <lsr@ietfa.amsl.com>; Wed, 3 Mar 2021 01:34:12 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D0E03A1DCE for <lsr@ietf.org>; Wed, 3 Mar 2021 01:34:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2582; q=dns/txt; s=iport; t=1614764052; x=1615973652; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=XVyYzeoqwINfXGOeWeuEtZ10nMqLIR46i7ZI6Sar/mM=; b=hlEYahpx8Y88UaPV68FgEVxjPb/2zaYXy6vv9Ck+FdhN2PLQUwJDGrBB 8w5ICTmQS5GVR0a1+bxKtpy/0hnJ7AbH0ImAWSKaJsBSZKLkFfmVpPZrC GPV5fEyc/xQS1gKNryCqgOW2cSrp8Qe+NEhq7SNlUrxW3tEx6vsPqIEeB Y=;
X-IPAS-Result: =?us-ascii?q?A0AKBADlVj9glxbLJq1iHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?U+DIVYBJxIxhEGJBIgpLQOcSwsBAQEPHQsMBAEBhE0CgXsmOBMCAwEBAQMCA?= =?us-ascii?q?wEBAQEFAQEBAgEGBBQBAQEBAQEBAYY2DYZEAQEBAwEBASEPAQU2CxALGAICJ?= =?us-ascii?q?gICJzAGAQwGAgEBgmwBgmYhD6xsdoEyhViDSYE+BoEOKolQg3NCgUlCgREng?= =?us-ascii?q?kUuPoJcAQGEdoJfBIFlWw03KlNQBwQgSRWBG5MVAaUUgRSDBoMvmGUFBwMfk?= =?us-ascii?q?1WQAZRVnUiEfoFrIYFZMxoIGxU7gmlQGQ2OOIhqhUZAAy84AgYBCQEBAwmME?= =?us-ascii?q?wEB?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.81,219,1610409600"; d="scan'208";a="33872104"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Mar 2021 09:34:08 +0000
Received: from [10.60.140.52] (ams-ppsenak-nitro3.cisco.com [10.60.140.52]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id 1239Y7wp005370; Wed, 3 Mar 2021 09:34:07 GMT
To: Tony Li <tony.li@tony.li>, Robert Raszuk <robert@raszuk.net>
Cc: Gyan Mishra <hayabusagsm@gmail.com>, DECRAENE Bruno IMT/OLN <bruno.decraene@orange.com>, Shraddha Hegde <shraddha@juniper.net>, Rajesh M <mrajesh@juniper.net>, "lsr@ietf.org" <lsr@ietf.org>, William Britto A J <bwilliam=40juniper.net@dmarc.ietf.org>
References: <161401476623.19237.3808413288895066510@ietfa.amsl.com> <DM5PR0501MB380079CFD75C78610130D81BCD9D9@DM5PR0501MB3800.namprd05.prod.outlook.com> <CAOj+MMHKazMG3wnUA+Kd2wg2hfr01CdF5w5YYKdFaHU4_V+0SA@mail.gmail.com> <CABNhwV0UKB=HaMs9eLvvp4fVLPsEtJhQ2xFmwY80sqBNDFRudQ@mail.gmail.com> <DM5PR0501MB38006C4B638AD2AB6A7731B5CD9A9@DM5PR0501MB3800.namprd05.prod.outlook.com> <7C67D01F-24DB-4450-8587-E004CAFBBEBC@tony.li> <CAOj+MMGZppwYtNr4t0rJoy3BKWaBYqHiJ_esM1XNFTNxbm8c5w@mail.gmail.com> <08882555-009B-4068-ABB0-20B0D165D722@tony.li>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <2c2605a8-95c6-a477-b1b5-5ae4d4de222a@cisco.com>
Date: Wed, 3 Mar 2021 10:34:06 +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: <08882555-009B-4068-ABB0-20B0D165D722@tony.li>
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-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/hc_c9JbXcveAb11maRWI0mEMlWY>
Subject: Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints
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: Wed, 03 Mar 2021 09:34:15 -0000

Hi Tony,

On 01/03/2021 21:47, Tony Li wrote:
> Robert,
> 
>> Constructing arbitrary topologies with bw constrain is useful work. For example I want to create a topology without links of the capacity less then 1 Gbps. All cool. Of course if I have a case where two nodes have 10 L3 1Gbps links nicely doing ECMP I will not include those which may be a problem.
> 
> 
> I agree that it may be a problem. Maybe it’s not the right tool for the job at hand. That doesn’t make it a bad tool, just the wrong one. I try not to turn screws with a hammer. And I try not to drive nails with a screwdriver.
> 
> I will happily stipulate that we need more tools and that these are not enough.  We should not reject a tool simply because it doesn’t solve all problems. Let’s work towards the right set of tools. Linear algebra tells us that we want an orthogonal set of basis vectors. What are they? Adding them one at a time is not horrible progress.
> 
> 
>> However my observation is precisely related to your last sentence.
>>
>> Is this extension to be used with static or dynamic data ? If static all fine. But as William replied to me earlier link delay may be dynamically computed and may include queue wait time. That to me means something much different if Flex-Algo topologies will become dynamically adjustable. And I am not saying this is not great idea .. My interest here is just to understand the current scope.
> 
> 
> Link delay was dynamic before this draft.  As William mentioned, TWAMP can already be used to provide a dynamic measurement of link delay.  That, coupled with the link delay metric already gave us dynamic path computation requirements and the possibilities of oscillation and instability. We have chosen to charge ahead, without addressing those concerns already.

TWAMP provided Min Unidirectional Link Delay is a dynamic one. On the 
other side this value is calculated based on multiple measurements over 
period of time and an average is used. Also, smart implementations can 
normalize the value so that a small fluctuation of the delay is not 
causing the traffic to shift or cause ECMP loss.

What is important here is that the Min Unidirectional Link Delay is a 
link characteristic, not something that is affected by the amount of 
traffic on the link or subject to queuing delay. Same applies to Maximum 
link bandwidth.

thanks,
Peter


> 
> Regards,
> Tony
> 
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
> 
>