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 22:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ABF333A07F6; Fri, 21 May 2021 15:40:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.501
X-Spam-Status: No, score=-1.501 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 XMtDm7v7hs_4; Fri, 21 May 2021 15:40:49 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9D14F3A07FF; Fri, 21 May 2021 15:40:49 -0700 (PDT)
Received: by with SMTP id b7so7573269plg.0; Fri, 21 May 2021 15:40:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=8TsF5FauPsTrGxc1OHSnZ6/Oug3WPJgK8TFzobCZfTE=; b=nT2AKmbLxAxfi+tkx58oXC2mATZ8lx25aUGZ8PC3EIhIL8JgVuUR82DA2VSA+Cdl8X H4wEEgUPy566BvgJDmnCxlcnGuVdftcH2kUg6gAQ9DMmbguoRB0y+N/gzgoFvj5xMkW+ r5aMTGTU1ulxVkV7oUdsT+/7ITnCQPnnblji9PGaGpkZ8kGYg7p8tPMs/PAojsS2e5n1 C8BQDZZUKZX/kvKYxxMxZub7NB68Xcne2qUa1S1qtdzXqdlf/ssy6gyls72dsmnnTiys +YOPKdjV56DnV1JagaTymseUdMfJRz3qshwKbV7E6uibKi1oXJp1TTdXxrzI0bM+tzzF Jrtw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=8TsF5FauPsTrGxc1OHSnZ6/Oug3WPJgK8TFzobCZfTE=; b=YgCp0+kUjogakNYy1OXkhXzwY+Q2X3OxQbmSwAGr1k1NkN6KJhutCUG4wP4xfXw5ER G0Qq2GKAvOLrvbP3+ZnAGoZnDxMld7+od001W9181DpfWQy1kq+InlDVzwReDfQo3EMk UoJZzNrTEqsy1SCjBPx0/oHJnAGo+d1POos2q56eG7/uewlT5Vye/V70YWXUf6l0LWCv AJRUoQcVHKS1CWJPD+OTRGhU2FGRr0qs4zGZNpffzcUaZCHuz8LIJjgx4NWNT7mUYMDJ cqkbNznAmD0l4q/QEoXSQ4FzXAMuuVMk86dOeYi8MfMq0Qpm2JXShDl+KccViDvqzXkh s7QA==
X-Gm-Message-State: AOAM530M63VDelHOiM6WI0eQORqK1ejr6IMQMKV/FWRdQvFbBzdiTUjD 0EZN1Xy5o6Tf5B++Zcbp7iTSjbkSQmI=
X-Google-Smtp-Source: ABdhPJz4pWPxBk7lAGPlc0SADp0Jv8WrwnUMjra/t4UJUx2NN8oBaUL/WRKXXwdZQN4Ppmlsdmk1Zw==
X-Received: by 2002:a17:90a:f85:: with SMTP id 5mr12768552pjz.64.1621636848054; Fri, 21 May 2021 15:40:48 -0700 (PDT)
Received: from ( []) by with ESMTPSA id a190sm5286362pfb.185.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 May 2021 15:40:47 -0700 (PDT)
Sender: Tony Li <>
From: Tony Li <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_CEA04FD2-F682-4F24-A678-ED9E534C363D"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Date: Fri, 21 May 2021 15:40:46 -0700
In-Reply-To: <>
Cc: lsr <>,, "Acee Lindem (acee)" <>
To: Aijun Wang <>
References: <> <>
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 22:40:52 -0000

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.