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

Tony Li <tony.li@tony.li> Mon, 01 March 2021 20:47 UTC

Return-Path: <tony1athome@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 BF5CA3A22AC for <lsr@ietfa.amsl.com>; Mon, 1 Mar 2021 12:47:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.5
X-Spam-Level:
X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 MjVuxDP5mwKu for <lsr@ietfa.amsl.com>; Mon, 1 Mar 2021 12:47:56 -0800 (PST)
Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (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 1C6303A22AA for <lsr@ietf.org>; Mon, 1 Mar 2021 12:47:56 -0800 (PST)
Received: by mail-pg1-x52b.google.com with SMTP id g4so12408017pgj.0 for <lsr@ietf.org>; Mon, 01 Mar 2021 12:47:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=O6p380/fgieBBls2GDGOTO70mYKZA8E87QtGPDSdT3g=; b=owB6GcPf6bobQH1alrWmlGUJs9HpdQO4PUisn/oMCBbqMzz28l5KpGKt0zDIRomjxh JdTTd1IJOVCW00Hfbtm/KLqgFB4+8muLaDsQomzve27PuAAKyB2b+nQUNfZCHY5Bz8Yp J260vP29ZoBz9y9aVP3JX2EvUHEo+ulBnBHerTlnzG2wAtxl54O/EAYUS41Y5hr4NRC1 FkP9GlVNAgzgoGeqiR0m9GghvjO8BDrjktuq7qeGkLcqRLditR+c+gkOw3fQ7jnAbmUw 59HpdrUNCqjmNKrA6ksHLTlo8ldXIzUtjb9cuN7XnaH9WK2Hdz5uTU728gMEZba4YSX6 wKEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=O6p380/fgieBBls2GDGOTO70mYKZA8E87QtGPDSdT3g=; b=mId0VFuS05VFW7wr+NCWb46z/2BzQn3t8RQ5RSv2ONN+t560a/6iSISBVLdxXw6BpG yi+6Nc+PCc8/HW+2eAIiI6wltQvVveR8f/KhJeHKFcdBG42cK9uHDh94Venx6om8yv9M 26Cg2UTgkaf80mmQek8BOl9XKG4nZ5kZhE4OI3ydM16XePR+oR363MNuJ6dndjxA5Tki NWhilUCqy8pBbegSFTAn1B9txv04o9bmdRZGP0mXrziTcoU3QPrQzrnnwGWUqxMI0MEj vi9wx0Bu7erGrInqALpLpEv1PdRJetfC64oodxxsggSctjbtjWSTyXPg20nBTvbnooMd WJYw==
X-Gm-Message-State: AOAM532bVGJhd5J7itx7YBNZLxdOpWvEbDwAOssQIIEnkzUuxgFwzSv5 n3LqPEO0ZfEX84AmvpnWkLA=
X-Google-Smtp-Source: ABdhPJxUniPu9KoU19UnSH0YCfkeN4Gnw+vaZOpqfx0+JblDlPw9QoLLeJDHFRthRHWo78N7YGAW7Q==
X-Received: by 2002:a63:1843:: with SMTP id 3mr15522072pgy.253.1614631674804; Mon, 01 Mar 2021 12:47:54 -0800 (PST)
Received: from [192.168.4.41] (c-67-169-103-239.hsd1.ca.comcast.net. [67.169.103.239]) by smtp.gmail.com with ESMTPSA id w1sm269312pjq.38.2021.03.01.12.47.53 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Mar 2021 12:47:54 -0800 (PST)
Sender: Tony Li <tony1athome@gmail.com>
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\))
From: Tony Li <tony.li@tony.li>
In-Reply-To: <CAOj+MMGZppwYtNr4t0rJoy3BKWaBYqHiJ_esM1XNFTNxbm8c5w@mail.gmail.com>
Date: Mon, 1 Mar 2021 12:47:52 -0800
Cc: William Britto A J <bwilliam=40juniper.net@dmarc.ietf.org>, Gyan Mishra <hayabusagsm@gmail.com>, "lsr@ietf.org" <lsr@ietf.org>, DECRAENE Bruno IMT/OLN <bruno.decraene@orange.com>, Shraddha Hegde <shraddha@juniper.net>, Rajesh M <mrajesh@juniper.net>
Content-Transfer-Encoding: quoted-printable
Message-Id: <08882555-009B-4068-ABB0-20B0D165D722@tony.li>
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>
To: Robert Raszuk <robert@raszuk.net>
X-Mailer: Apple Mail (2.3654.40.0.2.32)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/9pIHAmWXyMf_8iuuA-b83L9g9gI>
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: Mon, 01 Mar 2021 20:47:58 -0000

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.

Regards,
Tony