Re: [Idr] Available Bandwidth erratum 5486 [was: Re: AD Review of draft-ietf-idr-te-pm-bgp-14]

Alvaro Retana <aretana.ietf@gmail.com> Wed, 28 November 2018 22:15 UTC

Return-Path: <aretana.ietf@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50D46130E27; Wed, 28 Nov 2018 14:15:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.992
X-Spam-Level: ****
X-Spam-Status: No, score=4.992 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_SUMOF=5, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 uGcw-3GL8i6K; Wed, 28 Nov 2018 14:15:57 -0800 (PST)
Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 48532126F72; Wed, 28 Nov 2018 14:15:57 -0800 (PST)
Received: by mail-ot1-x336.google.com with SMTP id 40so25091637oth.4; Wed, 28 Nov 2018 14:15:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=aBC0SsAdDb4HbH+/DynY7YTGGCxbDDD2I4VYsM1auOE=; b=gt6JdYoIVWEy/6nAl2NT9vsB6veQz+frr4yQHnPSxxqPb+6mqzhLNXJ55Cr0ndSGxe naQeE+dSlfK+nJqDrZTcVzkMmr3cMy6mDgl1WzaHu6HI42xZiOsCQ/0oQJriT9QRfZ+1 AR8nMwiy4EqdvWO6qfBWPLKBl/+MD9l+YQ3k4kW8rARFTUK3oh9hVC3lt23iCceAz3Cl bGQ5ZRKsswoCyws2ZEUoUcqENDUW6UMKqTVsMbLem8fHpW4fJhLc2lveRg0zjJvMFtrc 3rm+NtOMklnWv4kEBYF/Ephf9TswDDtMWih2WZetSfVD5wvyXqa7gO5Cc0Gx2DBc+Gad KPeQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=aBC0SsAdDb4HbH+/DynY7YTGGCxbDDD2I4VYsM1auOE=; b=cSHMfraYkSG8FooU3rz58skYqus4QGTjdBRVK1wcAI4fnDMutq5mpYS6sEVSPGvjvO cLubF40S4qJEt1wCRmleiYWskFeEU8+ztcSVqQjOK/4ibSUPUQdvNvNWaNmNHSgm29zt j9AtXqc9uJn8kYpH9mDxyjqj60u6wzxNZnIdsnl+2ZX2jFL+O/fCmaGIh5T9EuQCmRua L5ua0bhibTOoTEshoiXaaB1Wv7jmSLmDXbPywMdg+NpQ2mwwHYjZJcDS6skmT3AgU5Q5 8fkh19nzJ3A5s87SXrGBikDCSkna8qA1W1dTF3viKIm04AfE9crekHP32i9qdVTYqXyw 88ig==
X-Gm-Message-State: AA+aEWYcUa2G9/xi7Ea0KNhiOtNRY158u5ZWUGXg+hf2KtIe7F4+6BR3 9k5D7zTDjhhtTXY95euCu6/+DbXcL0r29PjbdBY=
X-Google-Smtp-Source: AFSGD/Uo4oJH4p079r1wMw/H/ZGESIAS7FxeZSXsmxG0wePYX8wZ/gVK8ItINP0Ar3TccTN9GPQLBNjgXibNV/f/P5U=
X-Received: by 2002:a9d:2269:: with SMTP id o96mr23318869ota.45.1543443356574; Wed, 28 Nov 2018 14:15:56 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 28 Nov 2018 14:15:55 -0800
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <130DB3CF-2B31-4CAE-ABE6-E1B79A330820@juniper.net>
References: <CAMMESsyXWjVrCMG83HUUmMrSNzUvPvdRE6PSa7OAmOJgNtzMpg@mail.gmail.com> <130DB3CF-2B31-4CAE-ABE6-E1B79A330820@juniper.net>
X-Mailer: Airmail (528)
MIME-Version: 1.0
Date: Wed, 28 Nov 2018 14:15:55 -0800
Message-ID: <CAMMESsxSkg-Gqrn3ny_4ntp=AxfZGRvN0_ah+1sLPsyq1wdbNQ@mail.gmail.com>
To: John Scudder <jgs@juniper.net>
Cc: Hares Susan <shares@ndzh.com>, "draft-ietf-idr-te-pm-bgp@ietf.org" <draft-ietf-idr-te-pm-bgp@ietf.org>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "idr@ietf. org" <idr@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ffe81f057bc0e8ee"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/ibG7lzf34poaEoYsG_oyDLTu5AY>
Subject: Re: [Idr] Available Bandwidth erratum 5486 [was: Re: AD Review of draft-ietf-idr-te-pm-bgp-14]
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: Wed, 28 Nov 2018 22:15:59 -0000

John:

Hi!

I should have pointed to the current version of rfc7810bis [1], which now
reads:

   Available Bandwidth: This field carries the available bandwidth on a
   link, forwarding adjacency, or bundled link in IEEE floating-point
   format with units of bytes per second.  For a link or forwarding
   adjacency, available bandwidth is defined to be residual bandwidth
   (see Section 4.5
<https://tools.ietf.org/html/draft-ietf-lsr-isis-rfc7810bis-02#section-4.5>)
minus the measured bandwidth used for the actual
   forwarding of non-RSVP-TE label switched path packets.  For a bundled
   link, available bandwidth is defined to be the sum of the component
   link residual bandwidths (see Section 4.5
<https://tools.ietf.org/html/draft-ietf-lsr-isis-rfc7810bis-02#section-4.5>)
minus the sum of the
   measured bandwidth used for the actual forwarding of non-RSVP-TE
   label switched path packets on all component links.

This version gets rid of the duplication and uses “residual”.  Because it’s
been through WGLC I am assuming it is correct.  If not, please let me know
*now*, as I am about to start the IETF LC.

Thanks!

Alvaro.

[1] https://tools.ietf.org/html/draft-ietf-lsr-isis-rfc7810bis-02

On November 28, 2018 at 4:33:54 PM, John Scudder (jgs@juniper.net) wrote:

+lsr to the cc

Hi Alvaro,

On Nov 28, 2018, at 4:01 PM, Alvaro Retana <aretana.ietf@gmail.com> wrote:

[major] AFAICT, Available Bandwidth is the only definition that is
different between rfc7810/draft-ietf-lsr-isis-rfc7810bis and rfc7471.  The
difference comes from the correction made to address this report [1].
Instead of trying to fix the definition here, I think that a similar report
should be filed against rfc7471.  Please submit it and I will approve.

[1] https://www.rfc-editor.org/errata/eid5486
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_errata_eid5486&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=pNTkxj6RjNdyIYjBZKCUjdk9QWVKbBBhnnfj9xq2jjU&s=QvXYEMqBgaIkuM7plcuybtDVxI3JTI-4EndPcX0ier8&e=>


Maybe I'm missing something but isn't that erratum all wrong?

Here is why I think so. I agree that there is a problem with the RFC 7810
paragraph in question:

Available Bandwidth: This field carries the available bandwidth on a
   link, forwarding adjacency, or bundled link in IEEE floating-point
   format with units of bytes per second.  For a link or forwarding
   adjacency, available bandwidth is defined to be residual bandwidth
   (see Section 4.5) minus the measured bandwidth used for the actual
   forwarding of non-RSVP-TE label switched path packets.  *For a bundled
   link, available bandwidth is defined to be the sum of the component
   link available bandwidths minus the measured bandwidth used for the
   actual forwarding of non-RSVP-TE label switched path packets.  For a
   bundled link, available bandwidth is defined to be the sum of the
   component link available bandwidths.*


It seems obvious that there was a cut-and-paste problem or similar, since
the same sentence is duplicated with minor changes. But the erratum leaves
the duplication! The erratum wants it to be:

Available Bandwidth: This field carries the available bandwidth on a
   link, forwarding adjacency, or bundled link in IEEE floating-point
   format with units of bytes per second.  For a link or forwarding
   adjacency, available bandwidth is defined to be residual bandwidth
   (see Section 4.5) minus the measured bandwidth used for the actual
   forwarding of non-RSVP-TE label switched path packets.  *For a bundled
   link, available bandwidth is defined to be the sum of the component
   link (residual) bandwidths minus the measured bandwidth used for the
   actual forwarding of non-RSVP-TE label switched path packets.For a
   bundled link, available bandwidth is defined to be the sum of the
   component link available bandwidths.
*


So the proposed "fix" is to leave the sentence duplicated, but change
"available" to "(residual)" in the first copy? I don't think that could
possibly be right. Just eyeballing it, it seems to me as though the correct
fix would be to change the paragraph to be:

Available Bandwidth: This field carries the available bandwidth on a
   link, forwarding adjacency, or bundled link in IEEE floating-point
   format with units of bytes per second.  For a link or forwarding
   adjacency, available bandwidth is defined to be residual bandwidth
   (see Section 4.5) minus the measured bandwidth used for the actual
   forwarding of non-RSVP-TE label switched path packets.  For a bundled
   link, available bandwidth is defined to be the sum of the component
   link available bandwidths minus the measured bandwidth used for the
   actual forwarding of non-RSVP-TE label switched path packets.  For a
   bundled link, available bandwidth is defined to be the sum of the
   component link available bandwidths.


in which case it would match RFC 7471. Or possibly:

Available Bandwidth: This field carries the available bandwidth on a
   link, forwarding adjacency, or bundled link in IEEE floating-point
   format with units of bytes per second.  For a link or forwarding
   adjacency, available bandwidth is defined to be residual bandwidth
   (see Section 4.5) minus the measured bandwidth used for the actual
   forwarding of non-RSVP-TE label switched path packets.  For a bundled
   link, available bandwidth is defined to be the sum of the component
   link available *residual* bandwidths minus the measured bandwidth
used for the
   actual forwarding of non-RSVP-TE label switched path packets.  For a
   bundled link, available bandwidth is defined to be the sum of the
   component link available bandwidths.


I have no idea which of these is right, but the erratum can't be right.
Naively, they look algebraically the same, it's just a matter of where in
the equation you subtract the measured bandwidth. Maybe they truly are
exactly equivalent or maybe there is some subtlety that makes one right and
one wrong.

If the first option above is right, then RFC 7471 looks to be correct as
written. If the first option is wrong, then RFC 7471 would need its own
erratum as you suggest, I guess.

$0.02,

--John

P.S.: I see the defect remains in draft-ginsberg-lsr-isis-rfc7810bis-00.