Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Tony Li <> Fri, 21 May 2021 23:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 94D983A0CA2; Fri, 21 May 2021 16:35:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.502
X-Spam-Status: No, score=-1.502 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.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OOUBdeT_OLhN; Fri, 21 May 2021 16:35:24 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 194743A0CA0; Fri, 21 May 2021 16:35:23 -0700 (PDT)
Received: by with SMTP id k15so15417180pgb.10; Fri, 21 May 2021 16:35:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TExuKiH20GNDgvnY6kqu9mmTDUwUIuJ62O0nS+plVm8=; b=EFrtC0Jt3GNXrUh+O9V/u2WYLGOa67k5JyBGoDiQf4MoF3GYcQHSReyon8ki4acNqD Sh6CXMEVmtKMv0dwDTy2FjKnAwrrUL5YPRJ7Qn1Umh+spsBeX1Fnoh6ANDaderddFyR4 VOGrlY2QvDYPjVIh4s5FeBaPna0zOpwXg1JEDlCGVxcNxigu8SGiT9FLItS0cZ+6wZna LkLLuTVEuB3MVeio/xuhdCVtUTSqFqzAjaYAynn5eOBjSj709Lx2RG8iVUmStNnE+UM3 YSWiQLuUiw29vVsNAbgsLoJdobjCVDLiPGMst959+j/fBCQLi2md2mDFxlOtJIO7dW0v GAlg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=TExuKiH20GNDgvnY6kqu9mmTDUwUIuJ62O0nS+plVm8=; b=JdxByZ/G78giX9PWzScIirzA87yFWlcB563Uv0tKSvPO7+a0sBRWK8sDdbr06Z3YGa XpHSYSuk0eEVE9Yi/jEj3kxCt3b2QHuajKnLCIQF1+DD23rdh2utontNXDBLUmKiEZqG k6mVb9itSqlWblZngdCOv3aEVi6zG1orTmuMuQbCdHOrc6akHBQplP4FmdGH6tqEKeTg Jk1TuP1DsHClVXNxie5JGw63tjtPTB8UqHD2JLDa6H2rFqedhJMmRZdqLOBbGbXDpDaD 2Kg38LO0LMT7dJu5bQcDK+CV0n1Obz0G25ePUwCLUOaq8dWYwkXm5e6QMgNzdnVWe10Q iR5Q==
X-Gm-Message-State: AOAM5317IfkXisiUVYoxd6vN+zLNWPn9426LNJTtQngPOwdG2YSpAPuL k7ZTQ7zvgE71rH8zw2wwRcVd2VaPGDU=
X-Google-Smtp-Source: ABdhPJy9a8g4tc/6tUXdv1us4hmy8bMXc134D5jTi2lcLjS+WR8jEYf3lxmjaylM525b8UCzoQG5Ig==
X-Received: by 2002:a05:6a00:2163:b029:216:deaa:e386 with SMTP id r3-20020a056a002163b0290216deaae386mr12762824pff.72.1621640122807; Fri, 21 May 2021 16:35:22 -0700 (PDT)
Received: from ( []) by with ESMTPSA id a7sm4996997pfo.211.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 May 2021 16:35:22 -0700 (PDT)
Sender: Tony Li <>
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Tony Li <>
In-Reply-To: <>
Date: Fri, 21 May 2021 16:35:21 -0700
Cc: lsr <>,, "Acee Lindem (acee)" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Aijun Wang <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 21 May 2021 23:35:26 -0000

Hi Aijun,

> [WAJ] The operator must plan carefully for the metric assignment accordingly to their specific topology to let the traffic pass the necessary high bandwidth path as done in the following example.

That’s only if they have no concerns about the hop count.

Previous experience with other routing protocols that have a bandwidth based metric and do compute a cumulative metric does show that it is indeed possible to run many large networks this way and get
acceptable results.

> [WAJ] If such work must be done manually, it certainly weaken the necessary of the automatic metric calculations based on link bandwidth, also the introduction of bandwidth metric.

In many cases, that’s probably not necessary.

>> The point of the bandwidth metric (at least in this incarnation) is not to make hop count irrelevant. It is to set the metrics relative to the bandwidth so that traffic skews towards higher bandwidths.
> [WAJ] This can be done via the “bandwidth constraints sub TLV” that is introduced in this document.

No, that alone would exclude the hop count, resulting in a different path computation.

>> Hops are still relevant. An operator can adjust the reference bandwidth and add manual metrics to achieve different effects, depending on their precise needs.
> [WAJ] Is it more simple and easy to get determined results via setting the link metric based on the additive information?

I don’t understand what you’re asking.

Please remember that we are not trying to solve all problems for all people. We are trying to provide tools so that operators can drive traffic automatically in the way that they want. We’re trying to provide a variety of tools, with appropriate nerd knobs so that we can do useful traffic engineering without resorting to the very big hammer of having a centralized controller compute everything and program the entire network.