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

Tony Li <> Sat, 27 February 2021 01:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5A8FD3A164E for <>; Fri, 26 Feb 2021 17:56:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Status: No, score=-1.498 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 hy-nCYs8vWbu for <>; Fri, 26 Feb 2021 17:56:37 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C807A3A164B for <>; Fri, 26 Feb 2021 17:56:37 -0800 (PST)
Received: by with SMTP id m6so7461581pfk.1 for <>; Fri, 26 Feb 2021 17:56:37 -0800 (PST)
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=6NwnuYOfoAtB7arXqJQD1LM2TKVNW9QdvrK4jYTqroI=; b=kl0TtpJRavIRD7O370vjOXZ6kXffD0z0YpW+kUwlB2syIyh1og0UnGIP6nP5SZZ3hc fkUKhE94o/zqU0Iv44DI/kzrlKFtrUt0JW5mCwAp2XAo67/ZeLDHVjTYjLd3iVS4u4zn WVu9Q9JTHcz420+AqOq1TpSXfmPxvu2y0Vj6FGpVk/u9AiEOnX1sxbsP0WfPE9nbSIy1 6HVZak7kjhLnZV2mCV4qq4RBCcu6bJGjSM+ttBn0+P828wDVwZSgJnc8mzseglUHAVuD Rb0TqYSmepz+HWCumqqeoNRPo90NHhlTb4xXXwNfl1sNPYrFW+29rx4Qghg6+Jgf+8fI 052Q==
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=6NwnuYOfoAtB7arXqJQD1LM2TKVNW9QdvrK4jYTqroI=; b=CS0lYzHOpJ37hf4CVp2iJT0LPtiqsUf1AwKIJQbMZ5jfqx2LzyHiEVG5xypKCU29zC rq4jQuPHc/Aj5hXximUJGM0WR28vxPcxULV0xifGUQzBoKyWLmUkhFtG1DGnFB6pT8G9 vePNocgr1ocNDDeABSeg3ZM9h+awiym43lLrKk0kUaXrT/E1ODZB7eQk/Qc5mcBAHvZM PCsOn8pNinONBSsdT9GAaRVrW/vpsyx3fvoIPQl4nh0OW3uMuhZwrp71r7Wm7/WB/xtk UmbNJntYVK8Fx2yhPKRLDQqoH7At7kS6d/u4iJ1klcWXOCWoZY5sSID7y2Yx2kKu8Ykw MWAw==
X-Gm-Message-State: AOAM531gMvAhCL4Fp+ejDdW/Kz3c5EWPvk8OoezW8wvsJYSqSzJPh2Ts or6vLcFKgzjjBhudifuZrlM=
X-Google-Smtp-Source: ABdhPJzRoil1LPFZEUsEsQZsk3PLTcrqc8K1az5DPGwF1RZQYiaHo3y/UCw0KniIYESKJQNmrpLi4Q==
X-Received: by 2002:a65:4781:: with SMTP id e1mr5340151pgs.30.1614390997128; Fri, 26 Feb 2021 17:56:37 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id ch14sm9705472pjb.22.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Feb 2021 17:56:36 -0800 (PST)
Sender: Tony Li <>
From: Tony Li <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3470B5A0-2EB3-470A-B375-4E52CB0C1617"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Date: Fri, 26 Feb 2021 17:56:35 -0800
In-Reply-To: <>
Cc: "" <>, Rajesh M <>, Shraddha Hegde <>, DECRAENE Bruno IMT/OLN <>
To: William Britto A J <>
References: <> <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
Subject: Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints
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, 27 Feb 2021 01:56:40 -0000

Hi William & co-authors,

Thank you for your contribution. It’s definitely interesting. As bandwidth management is one area where FlexAlgo lags legacy traffic engineering, this is definitely one small step in the right direction.

But I have many comments…

1) I’ll start with the title: there is MUCH more here than bandwidth constraints. Perhaps this should be generalized somehow? Sorry, I don’t have a constructive suggestion.

2) Section 2: I concur that bandwidth is an important consideration in path computation. At a first reading, it is not at all clear to me that it is optimal to somehow transmogrify things into a metric. Why not simply deal with the bandwidth directly?  I did (eventually) realize that you did this because you want SPF to somehow select the path with the minimum product of (# links) * bandwidth.  I think you need to be explicit about this motivation and also mention that traditional SPF is not set up to deal with a floating point metric. Note that a bandwidth metric is STILL somewhat counter-intuitive to me, as I would expect that you’d mostly want to route things along the highest bandwidth paths, not the lowest ones. More motivation behind the bandwidth metric would be most welcome.

3) Section 2.1: To be consistent with the rest of FlexAlgo, shouldn’t this be advertised as part of the Application Specific Link Attributes?  

4) Sectiion 2.1: Why are there two octets reserved in this sub-TLV? If you’re hoping for alignment within an IS-IS LSP, you’ve already lost. Nothing in IS-IS is aligned.

5) Section 3.1.1: Here you have chosen to refer directly to subTLV 9.  To be consistent with the rest of FlexAlgo, should we use subTLV 9 inside of the Application Specific Link Attribute subTLV. Also, I believe that it would be more clear to call this the “Minimum Bandwidth subTLV”. The word ‘exclude’ doesn’t seem to add value here and every word makes our acronyms harder.

6) Section 3.1.2: I’m unclear on the utility of this. I can understand optimizing for path delay against the path metric. I can even understand putting an upper bound on the total path delay. I don’t understand why a bound on an individual link delay is important.  If my path delay budget is 100ms, then does it matter if it is exceeded in one hop or ten? Could you please provide more motivation here? Also, wouldn’t a FlexAlgo system be advertising the link delay in the Application Specific Link Attributes subTLV?

I’ll stop here for now, but I promise you more comments are still to come.


> On Feb 25, 2021, at 11:36 PM, William Britto A J < <>> wrote:
> All, 
> We would like to draw your attention to a new ID: <>
> The draft talks about introducing link bandwidth related constraints in Flex-Algorithm which can be used to define a Flex-Algorithm based on bandwidth based metric.
> Please review. Any questions and comments are welcome.
> Thanks,
> William
> From: <> < <>>
> Date: Monday, 22 February 2021 at 10:56 PM
> To: Bruno Decraene < <>>, Rajesh M < <>>, Rajesh M < <>>, Shraddha Hegde < <>>, William Britto A J < <>>, William Britto A J < <>>
> Subject: New Version Notification for draft-hegde-lsr-flex-algo-bw-con-00.txt
> [External Email. Be cautious of content]
> A new version of I-D, draft-hegde-lsr-flex-algo-bw-con-00.txt
> has been successfully submitted by Shraddha Hegde and posted to the
> IETF repository.
> Name:           draft-hegde-lsr-flex-algo-bw-con
> Revision:       00
> Title:          Flexible Algorithms Bandwidth Constraints
> Document date:  2021-02-22
> Group:          Individual Submission
> Pages:          21
> URL:  ;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD3v6TruoA$ <;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD3v6TruoA$>
> Status:;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD1VexjHPQ$ <;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD1VexjHPQ$>
> Htmlized:;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD3X5nPQbA$ <;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD3X5nPQbA$>
> Htmlized:;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD2aqSYcuQ$ <;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD2aqSYcuQ$>
> Abstract:
>    Many networks configure the link metric relative to the link
>    capacity.  High bandwidth traffic gets routed as per the link
>    capacity.  Flexible algorithms provides mechanisms to create
>    constraint based paths in IGP.  This draft documents a set of
>    bandwidth related constraints to be used in Flexible Algorithms.
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at <>.
> The IETF Secretariat
> Juniper Business Use Only
> _______________________________________________
> Lsr mailing list
> <>
> <>