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

Tony Li <tony.li@tony.li> Tue, 02 March 2021 23:59 UTC

Return-Path: <tony1athome@gmail.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 234443A14AC for <lsr@ietfa.amsl.com>; Tue, 2 Mar 2021 15:59:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.5
X-Spam-Level: ***
X-Spam-Status: No, score=3.5 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, GB_SUMOF=5, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PXVqKqZ1K_Q for <lsr@ietfa.amsl.com>; Tue, 2 Mar 2021 15:59:47 -0800 (PST)
Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32F823A14AB for <lsr@ietf.org>; Tue, 2 Mar 2021 15:59:47 -0800 (PST)
Received: by mail-pg1-x52c.google.com with SMTP id h4so14964315pgf.13 for <lsr@ietf.org>; Tue, 02 Mar 2021 15:59:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UehGujqcL59nFpUYspDdkRfVM3ddt4C0L9bjClzASTM=; b=Era7TyxQRfha5wdnQyVbBx1BLD4EMb1AAepSwvd7Qwoyb90v6M27liuCwBx2Yq/mUC s2a6KG+BV/CsSoQApDTZL9OKeInDVt/Dp2Wz7Ln4yUdO7UNLn+zv/HdptuXmcm2OrTwj ozeuIoQxHYgFZ6h1aZaAhPeVu0PSDekDiOfRa9tbLo1Oc43LaIetgm6pE5KoVQsDLvCM O91+Eu2ZJWinembAjbN2DlxfoBLNXNWYN8JqVNETjHgM/mPFXYl7+eQGN/FBjBCJ3mx/ FR1XtHMwMVBNzXc2zxc7x5OVhkbK57k3gLZCJDkVtXvrpdDR9YJE1Fha4pnARnTkyZTk GEaA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=UehGujqcL59nFpUYspDdkRfVM3ddt4C0L9bjClzASTM=; b=qAjsSj1WrNajW/ql568y3n1/9yl1VOZr3jxqmukKuUHjfjfX7J9SHO0tMuuYd96vga IXu3Np2m7P912Wv5Bryo7QgRA5zHT4IlQLFdI7LMfPszHp8X7IDK6RjJrxK3Lv9Ww9OZ ntJSGWRbkXSaYQ11QHRVWdXBtJe3jztV5c5LOMxkQDf9EwXyoQNBRcpOnDsG5fGt+2dU 9xEXGnqWSbX52SeponGzVJ2E7HnM1o1WmzQTHWwUy693WESolVYAnVGIyc0pU1e05RGP hh85Egm1EGFpxCogunxop9lGPXqabxSRcBcCs4rla+rcKYnaQ/8Z7v+de8fPjQ+gBaGt xTtw==
X-Gm-Message-State: AOAM533iPsWkReRNfI+OstZuge7Rft5o5fn9URmRdrxhiKBRcrtkvkmr jU2l9X4qyF1t/Emo5mavjhU=
X-Google-Smtp-Source: ABdhPJwjP9nn+NyR8SfnPjaZRn4zGp7vRAJNrB/ols1EpvpyamaPvjdJgdAZ2OrhPQ2z+UNe3zZ0gQ==
X-Received: by 2002:a62:3246:0:b029:1d5:db64:4b06 with SMTP id y67-20020a6232460000b02901d5db644b06mr5430310pfy.64.1614729583632; Tue, 02 Mar 2021 15:59:43 -0800 (PST)
Received: from [192.168.4.41] (c-67-169-103-239.hsd1.ca.comcast.net. [67.169.103.239]) by smtp.gmail.com with ESMTPSA id y20sm11078226pfb.138.2021.03.02.15.59.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Mar 2021 15:59:42 -0800 (PST)
Sender: Tony Li <tony1athome@gmail.com>
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\))
From: Tony Li <tony.li@tony.li>
In-Reply-To: <DM5PR0501MB3800B7976376E6167378FFB2CD9C9@DM5PR0501MB3800.namprd05.prod.outlook.com>
Date: Tue, 2 Mar 2021 15:59:40 -0800
Cc: "lsr@ietf.org" <lsr@ietf.org>, Rajesh M <mrajesh@juniper.net>, Shraddha Hegde <shraddha@juniper.net>, DECRAENE Bruno IMT/OLN <bruno.decraene@orange.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <23144FD9-0CE9-40DA-94FD-DE5611D24911@tony.li>
References: <161401476623.19237.3808413288895066510@ietfa.amsl.com> <DM5PR0501MB380079CFD75C78610130D81BCD9D9@DM5PR0501MB3800.namprd05.prod.outlook.com> <AEEC6707-7E76-41FF-9388-EA2AFE9FF5D1@tony.li> <DM5PR0501MB3800B7976376E6167378FFB2CD9C9@DM5PR0501MB3800.namprd05.prod.outlook.com>
To: William Britto A J <bwilliam@juniper.net>
X-Mailer: Apple Mail (2.3654.40.0.2.32)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/3gSwwaSIQMLY47-LACO6mMgXDH0>
Subject: Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Mar 2021 23:59:49 -0000

Hi William,


> 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.
> [William] Agree. We are introducing few ‘definitions’ for a bandwidth based Flex-Algo, along with couple of link constraints which can be used for any type of flex-algo. Any suggestions are welcome.


In the hopes of inspiring others with better thoughts:

“Flexible Algorithms: Bandwidth Management Part 1”
“Flexible Algorithms: Some Stuff We Forgot”
“Flexible Algorithms: Bandwidth and Delay, Metrics and Constraints”
“Flexible Algorithms: A Few More Bits”

 
> 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.
> [William] Apologies. This was an error in the figure. Intention was one octet for Reserved/future flags, hence the Length of 5 octets. Will correct this in the next version.


And if you agree with a more general metric, maybe a few of those reserved bits could be used as the index for the user defined metric.


> 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.
> [William] Shouldn’t there be only one Max link BW per link applicable for all applications? However, agree that it could still be in a common ASLA. Will add relevant text to clarify this.


That argument might well apply to all of our other link attributes as well.  Why do we need a separate administrative group for FlexAlgo?  Why do we need a separate set of SRLGs?  I have to confess that we have added a bit of complexity that I don’t think is very valuable. However, what’s done is done and there’s no point in arguing about it now.  We should simply strive to be consistent with what’s already in place so that we don’t create even MORE complexity.

 
> 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?
> [William] This constraint could be useful in a Flex-Algo whose Metric-type is anything but Link-delay. Here, Link-delay doesn’t influence the ‘cost’ of a link in that Flex-Algo, but can be used to prune out certain links with very high delay from that Flex-Algo. 


Thank you, that’s helpful motivation.  Please add something like this to the draft.

Continuing on from there…

7) Section 4. You’ve hidden a big part of what you want to do down here, 9 pages into the document.  You’ve got one whole sentence in the introduction to motivate it.  It deserves a good bit more.

8) Section 4.2. You write that an implementation "considers cumulative bandwidth of the parallel links while arriving at the metric for the link”. This seems a bit vague.  I think you’re trying to say that in interface group mode the bandwidth of an adjacency is the sum of the bandwidths of the individual links.  Typically today, if we have L3 parallel links they are encoded as separate adjacencies, complete with unique interface addresses.  How does interface group mode work with that? Does each adjacency advertise the same metric based on the total bandwidth of all of the links?  The discussion about reference bandwidths and the staircase mapping seems a bit confusing and redundant.  It appears to be orthogonal to the mode, correct? Why not describe it independently? More proofreading is necessary here.


9) Section 4.3.1. The reserved byte is wasteful. Your explanation of the round-off bandwidth is unclear.  Are we expecting dynamic bandwidth changes?  If so, that is an entire discussion unto itself.

10) Section 4.3.1. The reserved byte here is also wasteful.  Your explanation of how to use this is a bit unclear.  Are bandwidth ranges allowed to overlap?  I hope not. Is max[1] == min[2]?  I hope so, otherwise there is a gap in the ranges.  If there is a gap, and a link bandwidth falls in the gap, then what do we do?  Assuming that max[i] == min[i+1], then is there a point in carrying both values all of the time? What happens when a bandwidth exceeeds the highest max? Is below the smallest min?

Regards,
Tony