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

Tony Li <> Sat, 22 May 2021 00:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B7ADC3A100A; Fri, 21 May 2021 17:24:38 -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, 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 ITlQ9yaNi01P; Fri, 21 May 2021 17:24:36 -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 3FAA43A1009; Fri, 21 May 2021 17:24:36 -0700 (PDT)
Received: by with SMTP id j12so15495158pgh.7; Fri, 21 May 2021 17:24:36 -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=lmaFc1KkOb3IUwu+pjfrCWstnIrCyHZtNK4cVaY6QUg=; b=kWRRYILwnmGoQ7/N0LVy8SUkI27G3K86hxw7+W/30J0b/os3Xy8URIAAT6ZGbLoy5r Mwu1VQtXxDCQvEk9/GXzHD5AOLxOoRx8Zf64k+B6UupB7JpzXNnbg01otfVpKsEWQP52 FWfmD8F5bd7graL7ea3CPzJ2gvYbLVH082al+zr32REOZ6Sk3C0pGz36xYcmNdq5EOF7 hiusTzeetkK9UO2Bjg4+H5qsQXm9++xYLeYjMq0zQI7N8yXVr+I/7JpHpI5mAPz+Ku0F WwLKrXQLAGjXLfCJcCNgBzAhKu5/jCQnBx4VCIs+EapZlvBcG2Y56ygOFIinzcINKE5/ iEZA==
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=lmaFc1KkOb3IUwu+pjfrCWstnIrCyHZtNK4cVaY6QUg=; b=gBuSkKxpwRL+qH3UX1gpGbl6RTGEmoyUcq2F3mhKVlqT4J4kp0sjqBL2EzeZhCjYVh IC+GnKMwGmM6knEp7leMquyyu7R+3W5mJzPCweUVpN9gbV52F4uevbhUpiIxyJ/TDV9a Zf25QeO4uh/k8SajoDGNDezoNr0uYVY3xw2X7QM+YepNQ/iIo/TpH145gYG/fLq49hOf MtpcURAutIMcBmdJqkxR2F0IEnhkozPTevgQgAA3mzqp/YhFtkyGjk1GtdJzCPqmQ4Kz W610wr2OCoEG16fZ0ldthu/+N44iHUfkV6Lm+cgbe8OEhH+S+TVKSAeCpLr+N3crGv/O XFpQ==
X-Gm-Message-State: AOAM531KjcLQb7Aoor4en6HBjU0PCujv45sk/t78WEwvCq/JSkJHPBXA XwBh+hiqGVYbbfzpycQV8bmnef/Q47A=
X-Google-Smtp-Source: ABdhPJwKR9GA/wPOklaN4zliuJBzHIdBchdjN5w1HORU4Mj78mItNVf+MN2vsXgolQS8LrhocG7J6g==
X-Received: by 2002:a63:b247:: with SMTP id t7mr1343758pgo.408.1621643074399; Fri, 21 May 2021 17:24:34 -0700 (PDT)
Received: from ( []) by with ESMTPSA id y17sm4998810pfb.183.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 May 2021 17:24:34 -0700 (PDT)
Sender: Tony Li <>
From: Tony Li <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_57569FEF-BAC7-47C5-B895-855E9239913C"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Date: Fri, 21 May 2021 17:24:33 -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: Sat, 22 May 2021 00:24:39 -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.
> [WAJ] Hop count have little influence on the application performance. Nearly every router can forward traffic in line speed as declared by every device vendor?

Yes, but hop count has a significant impact on the bits * miles/km product that represents ISP cost.

>> 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] We prefer to the solution that can get determined results under various scenarios, not just fit part of them.

There are no solutions that fit all scenarios. Otherwise, we would not have traffic engineering and interesting 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.
> [WAJ] For example, if we set the metric based on the distance between two nodes, we can certainly say that the best path will have the shortest E2E distance; if we set the metric based on the link delay, we can assure the traffic will be forwarded in least delay path. 
> But if we set the metric based on the link bandwidth, I think you cannot assure the E2E traffic will always pass the expected high bandwidth path. Is it right?

Not per the current formulation, but then that’s not what we’re after.

>> 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.
> [WAJ] My observation is that the operator will need more judgment works in their centralized controller to utilize such tools, especially in some complex topology (because you need even manual intervention in some common topology scenarios)
> I am also prefer to more automatic work been done in distributed manner. But shouldn’t such work/tools get determined expected results automatically even in some simple topology?

As I alluded to previously, bandwidth based metrics that have some respect for hop count have been found to be automatically helpful in MANY, MANY, MANY networks in previous routing protocols.  Perhaps one of my competitors would be willing to say the name that I am unable to mention.