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

Gyan Mishra <> Fri, 21 May 2021 22:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B9E773A09FC; Fri, 21 May 2021 15:59:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Status: No, score=-2.087 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YO_63m2URq9E; Fri, 21 May 2021 15:59:19 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::62a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 91DD13A09F5; Fri, 21 May 2021 15:59:19 -0700 (PDT)
Received: by with SMTP id e15so5119588plh.1; Fri, 21 May 2021 15:59:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gzmy/eIoj/QSLZbxU1ZjCWZrl72k62Z3K895Nn7Uf0k=; b=m/i6hyiTcY8XNpZYZ9OPTUf70lEbrI0dTMxTBl9NeGX4WljHw//+MKd4unJdbNKIsx zSW+FuMOamMEgQZtbnAWmwnWd5/EJbuexjU3jDPUAo7Mb5qjoe2LXLc1uKgd/T6XiX+3 ig66PpfTeua+c2pc4H9BKJ/OfPVPDh/wvOT7YzQNxkv/B4Zpe4R5REfBtfnQkyx7I4+M /eeDp8+653Yu6++eG4g2k/Fbo5uaywZVPqCAue+Kv10zFd1j4oY09V4tczJ9I5axHJW1 NW3aG+LDkJBllK6obKvK6yGHQgkK5PmSJM0Trp1+qDVRX6Y7bbBOL5aes05fbQlhcgkZ SKow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gzmy/eIoj/QSLZbxU1ZjCWZrl72k62Z3K895Nn7Uf0k=; b=UxbbaB1Hr96T7prcCewhQyLesnxZ1P+YcL+CpRCmlCK2nXf6Rx5Ee7SgbC/JbqX7vI SR0aj4XralsgSuOvPH+7zGzLpEDZSTNj/hjSP6cb3zRZKgSRFsJM5pnDPdB0D2Ign7+Y RGBOWdDeSkALWVrJhZFt3yAbH/zShdA4UehRtx1OCAgyMGG9cW5+KNXItpYI2I60McRD ZCETUMB/qQ+HYNSmbwZ7yhz0cqpBdm0gFpBCq+8K8Prsfo8L/h5YYocrBPCfLe8ll9ri xnCN0tkjKvkxM6ApMACTXUe4wiP5DLI601Am6bgze5NxjdWweKNa5hB1eSrCfN2+yNx3 jo0Q==
X-Gm-Message-State: AOAM530bn5N/VNbabait5ZG44tveUe67P26/nXCXUJC8hBTzWZI1HqaT jvjz7AUO70uI3HQhezhEr8Bv051qjIMWbZWTUKE=
X-Google-Smtp-Source: ABdhPJzwuF2Hnw2PYlukvB+t5i17FmoCjoyNcrTjbnKGCekT/8+MsqskLwcJeujpQ32SyCEbD+iUlWGXfckIQLKaGXw=
X-Received: by 2002:a17:90a:c68f:: with SMTP id n15mr12426285pjt.112.1621637958585; Fri, 21 May 2021 15:59:18 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Gyan Mishra <>
Date: Fri, 21 May 2021 18:59:07 -0400
Message-ID: <>
To: Tony Li <>
Cc: "Acee Lindem (acee)" <>, Aijun Wang <>,, lsr <>
Content-Type: multipart/alternative; boundary="00000000000079d78605c2df0250"
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 22:59:25 -0000


This is a similar concept to what exists today with most vendors CLI
configured reference bandwidth that can be overridden by manual metrics
link by link to skew traffic to avoid bottle necks, but now applying that
same concept that has existed historically to Flex Algo  new “bandwidth
metric” static generic metric TLV and new automatic reference bandwidth
based metric.

With this algorithm change the issue that has existed with IGP ECMP
parallel links is that they are all treated as individual and so the total
group bandwidth is not taken into account.  So this is a major benefit to
now being incorporated into Flex Algo.   Also the concept of being able to
exclude links based on minimum bandwidth is as well a benefit so traffic is
skewed to the higher bandwidth links.

This is basically another option for operators using Flex Algo in the
operators toolbox.

Kind Regards


On Fri, May 21, 2021 at 6:40 PM Tony Li <> wrote:

> Hi Aijun,
> With the introduce of additional constraint information, the problem
> described in “Introduction” part(Section 1) can be solved.
> Please say more.  Claims without rationale are not reasoning.
> [WAJ]  The introduction part talks mainly how to divert the elephant
> traffic away from the low bandwidth link. This can be achieved via the
> introduction of additional constraints information for Flex-ALGO
> Which is exactly what we’ve done: added bandwidth constraints.
> The usage of bandwidth metric in large network is not feasible.
> [WAJ] The main reason is that bandwidth metric is not cumulative.
> ??? What are you seeing that implies that?  That is not my understanding
> at all.
> And, would you like to explain more for the following statements(in
> Section
> “In the interface group mode, every node MUST identify the set of
>    parallel links between a pair of nodes based on IGP link
>    advertisements and MUST consider cumulative bandwidth of the parallel
>    links while arriving at the metric of each link.”
> based on example described in Figure 7?
> The paragraph immediately above explains exactly that. B->C has two
> parallel 10Gbps links, so it should be considered to be 20Gbps.
> How the cumulative bandwidth will be used to achieve the result that
> traffic from B to D will prefer B-C-F-D, not B-E-D?
> B-C-F-D is 20Gbps. B-E-D is 10Gbps.
> [WAJ] OK, let’s add two nodes between node B and C, say they are node M
> and N. They have also two parallel links to B and C respectively. The two
> possible path from B to D will be:
> Path 1: B-M-N-C-F-D
> Path 2: B-E-D
> If the “reference bandwidth” is 100G, then metric for each link in
> B-M-N-C-F-D will be 5, the cumulative metric from B-D for Path 1
> “B—N-C-F-D” will be 25, right?
> The metric for each link in B-E-D will be 10, the cumulative metric from
> B-D for Path 2 will be 20, right?
> How can you prefer to the high bandwidth path?
> Override the metric on B-E-D to be even higher.
> 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. Hops are still
> relevant. An operator can adjust the reference bandwidth and add manual
> metrics to achieve different effects, depending on their precise needs.
> Tony
> _______________________________________________
> Lsr mailing list


*Gyan Mishra*

*Network Solutions A**rchitect *

*Email <>*

*M 301 502-1347*