[Idr] Comments on draft-li-idr-link-bandwidth-ext

Jeffrey Haas <jhaas@pfrc.org> Mon, 15 November 2021 20:54 UTC

Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 69F6D3A0967; Mon, 15 Nov 2021 12:54:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id NDtLUNQzEYko; Mon, 15 Nov 2021 12:54:28 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org []) by ietfa.amsl.com (Postfix) with ESMTP id 23E333A0966; Mon, 15 Nov 2021 12:54:25 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 247E41E2D8; Mon, 15 Nov 2021 15:54:24 -0500 (EST)
Date: Mon, 15 Nov 2021 15:54:23 -0500
From: Jeffrey Haas <jhaas@pfrc.org>
To: draft-li-idr-link-bandwidth-ext@ietf.org, idr@ietf.org
Message-ID: <20211115205423.GF25878@pfrc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/nQCJe-QGCUEsa6zAHyiunYMI__c>
Subject: [Idr] Comments on draft-li-idr-link-bandwidth-ext
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Nov 2021 20:54:33 -0000

[Speaking as an individual contributor.]


Thanks for your presentation of draft-li-idr-link-bandwidth-ext at IETF 112.
Microphone discussion captured many of the key points about your draft.  I'd
like to take this opportunity to list some of those points and add others.

It is understood that a 32-bit floating point value has issues with
granularity.  This often leads to interesting mismatches in configured
intent vs. the number encoded in a BGP link-bandwidth community.

This granularity issue in particular makes policy challenging to write.
Even simple algebraic comparisons such as greater-than/lesser-than may be a
mis-match based on these granularities.

For the simple case that link-bandwith is typically used for, it's been
"good enough".  This is typically for providing a general weight for BGP ECMP.

Currently, we already have an industry mismatch regarding link-bandwidth
extended community encoding IDR needs to address: The draft lists
non-transitive encoding, but there also exists transitive encodings.  Due to
how BGP extended communities are encoded, these aren't compatible.

Adding additional encodings for link-bandwith, transitive or not, will add
to this confusion.  This isn't to say the work isn't worth doing, it simply
means it is a necessary discussion point.

I do wish to contribute a small thing that may address a complexity in your
proposal.  With the encodings in your draft, it is possible to have
encodings for the same value using different SubTypes.  This isn't

IEEE 754 has a format, "decimal32"[1] that addresses part of the
considerations in your draft.  Values are available in base 10 and not
subject to some of the forms of rounding error, the impacts of which are
discussed above.

It doesn't solve the one single format on the wire for a number.  There may
be some opportunity to pick specific encoding rules for something like
decimal 32 such that the on-the-wire format gains consistency.  We would
want that with your proposal as well.

-- Jeff

[1] https://en.wikipedia.org/wiki/Decimal32_floating-point_format