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

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Wed, 28 November 2018 22:46 UTC

Return-Path: <ginsberg@cisco.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 49E451277C8; Wed, 28 Nov 2018 14:46:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.969
X-Spam-Level:
X-Spam-Status: No, score=-8.969 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=5, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 PkxRYPo9rCZc; Wed, 28 Nov 2018 14:46:08 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23C6D126F72; Wed, 28 Nov 2018 14:46:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=53522; q=dns/txt; s=iport; t=1543445168; x=1544654768; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=B5xSnJ35t34qFpuuaPwYyLcupRdLMr6LycOnq3gyyAo=; b=Rel6CEgISQI1DA2DMXR479H+m+LY4HWwtCexRDJFo+TlC5NDTYoHQeRK 5aq1Ci2+lsJdudmBLhIiK/2Jr1fSWGLvQvTLu0dvi5hA7tlIwrReSEZ76 1L9UXL0rLlRFMNDohhKxAjkvgZKM4YDI+tBAhKdQymQii+PSwbf+yI7Ht s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AFAAAMGv9b/4kNJK1kGQEBAQEBAQEBAQEBAQcBAQEBAQGBUgMBAQEBAQsBgQ12ZoECJwqDb4FfkkKCDXyIFI4yFIFmCwEBIoRKAheDFSI1CA0BAwEBAgEBAm0cDIU8AQEBAQMjCjoSEAIBCA4DBAEBIQEGAwICAh8RFAkIAgQBDQUIgxqBHUwDFQ+nBYEvhDECg08NghyMFheBQD+BEAGCXTWCV0cBAQIBF4EUARIBRRAIgkaCVwKGZoIfghKDdYY5iiguCQKGe4ZLPYMkIIFaTYRDiiuIdoEDg1uBC4lCAhEUgSchAjRkcXAVgycJgW4tAxcSgziFFIU/QTEBAQGMKYEfgR8BAQ
X-IronPort-AV: E=Sophos;i="5.56,292,1539648000"; d="scan'208,217";a="489052577"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Nov 2018 22:46:06 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id wASMk6Ml015640 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 28 Nov 2018 22:46:06 GMT
Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 28 Nov 2018 16:46:05 -0600
Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1395.000; Wed, 28 Nov 2018 16:46:05 -0600
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Alvaro Retana <aretana.ietf@gmail.com>, John Scudder <jgs@juniper.net>, "draft-ietf-lsr-isis-rfc7810bis@ietf.org" <draft-ietf-lsr-isis-rfc7810bis@ietf.org>
CC: Hares Susan <shares@ndzh.com>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "draft-ietf-idr-te-pm-bgp@ietf.org" <draft-ietf-idr-te-pm-bgp@ietf.org>, "idr@ietf. org" <idr@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>
Thread-Topic: Available Bandwidth erratum 5486 [was: Re: AD Review of draft-ietf-idr-te-pm-bgp-14]
Thread-Index: AQHUh2IUrBnuVadtQ0WJMfZeIBYRAqVmJa2AgAAC0QCAAAJ8gP//nLSw
Date: Wed, 28 Nov 2018 22:46:05 +0000
Message-ID: <0036030cefb74a5385c47470e8e71250@XCH-ALN-001.cisco.com>
References: <CAMMESsyXWjVrCMG83HUUmMrSNzUvPvdRE6PSa7OAmOJgNtzMpg@mail.gmail.com> <130DB3CF-2B31-4CAE-ABE6-E1B79A330820@juniper.net> <CAMMESsxSkg-Gqrn3ny_4ntp=AxfZGRvN0_ah+1sLPsyq1wdbNQ@mail.gmail.com> <EA69FF7A-F255-4735-8BFA-6E02EF0025AA@juniper.net> <CAMMESswRVQVMQKOMD07kPZZH3=wV63k7n+CqhTnyKPHkw9-+0g@mail.gmail.com>
In-Reply-To: <CAMMESswRVQVMQKOMD07kPZZH3=wV63k7n+CqhTnyKPHkw9-+0g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.67.88]
Content-Type: multipart/alternative; boundary="_000_0036030cefb74a5385c47470e8e71250XCHALN001ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com
X-Outbound-Node: alln-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/uMo_l7N3NqfiyObanXo7iOEY_WI>
Subject: Re: [Lsr] Available Bandwidth erratum 5486 [was: Re: AD Review of draft-ietf-idr-te-pm-bgp-14]
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: Wed, 28 Nov 2018 22:46:13 -0000

Alvaro –

As lead author on rfc7810bis I am happy to modify the language to be consistent with RFC7471. That seems like the far easier pathway so long as we have your assurance (which it seems we do) that this will not unduly delay progress of rfc7810bis.

I do find that the fact that you raised this issue in the context of draft-ietf-idr-te-pm-bgp rather confusing (though I can appreciate that it was your review of the idr draft that brought the discrepancy to your attention).
It would have been less confusing – at least to me – if you had raised this point in a separate email regarding rfc7810bis.

That said, it is good to have caught this before publication. I will publish an rfc7810bis update in the next couple of days.

   Les


From: Alvaro Retana <aretana.ietf@gmail.com>
Sent: Wednesday, November 28, 2018 2:35 PM
To: John Scudder <jgs@juniper.net>; draft-ietf-lsr-isis-rfc7810bis@ietf.org
Cc: Hares Susan <shares@ndzh.com>; idr-chairs@ietf.org; draft-ietf-idr-te-pm-bgp@ietf.org; idr@ietf. org <idr@ietf.org>; lsr@ietf.org; lsr-chairs@ietf.org
Subject: Re: Available Bandwidth erratum 5486 [was: Re: AD Review of draft-ietf-idr-te-pm-bgp-14]

I am explicitly copying the authors of rfc7810bis to get them involved in this discussion.  Also cc’d lsr-chairs.

Even if the two versions are algebraically identical, and because the definitions in draft-ietf-idr-te-pm-bgp depend on *both* documents, I would prefer it if the text was the same to avoid any confusion.  We are still in time to make changes to either rfc7471 (erratum) or rfc7810bis.

Thanks!

Alvaro.


On November 28, 2018 at 5:26:06 PM, John Scudder (jgs@juniper.net<mailto:jgs@juniper.net>) wrote:
Ah, I was looking at an old version of 7810bis, sorry about that.

ISTM that:

- if the two versions are actually algebraically identical (as I speculated but do not insist) then it would be nicer to adopt the "available bandwidth is defined to be the sum of the component link available bandwidths" version since it matches the language in RFC 7471 and is less confusing that way, but if they're logically identical it doesn't reeeeally matter.
- if John Drake is correct in his reply that the "available bandwidth is defined to be the sum of the component link available bandwidths" is correct (implying the other version isn't, for some reason), then 7810bis is wrong and needs to be changed.
- If 7810bis is correct, and John is wrong, then there needs to be an erratum against RFC 7471.

I think that covers the universe of possibilities. I still don't know which is right, though.

No additional charge,

--John
On Nov 28, 2018, at 5:15 PM, Alvaro Retana <aretana.ietf@gmail.com<mailto:aretana.ietf@gmail.com>> wrote:

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://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dlsr-2Disis-2Drfc7810bis-2D02-23section-2D4.5&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=UIR3n8QFqMcpIKK1NmO9BrP-njmMKHptlvEREQcIxuo&s=0daHEmhaKMcCIi-F__AxqMzBxXWku3wzPDTyxUtIXRo&e=>) 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://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dlsr-2Disis-2Drfc7810bis-2D02-23section-2D4.5&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=UIR3n8QFqMcpIKK1NmO9BrP-njmMKHptlvEREQcIxuo&s=0daHEmhaKMcCIi-F__AxqMzBxXWku3wzPDTyxUtIXRo&e=>) 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dlsr-2Disis-2Drfc7810bis-2D02&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=UIR3n8QFqMcpIKK1NmO9BrP-njmMKHptlvEREQcIxuo&s=aovcawRyAFXXQOnv4OtrmiyQVPjHYoFO_XMm1CjdKuA&e=>



On November 28, 2018 at 4:33:54 PM, John Scudder (jgs@juniper.net<mailto:jgs@juniper.net>) wrote:
+lsr to the cc

Hi Alvaro,

On Nov 28, 2018, at 4:01 PM, Alvaro Retana <aretana.ietf@gmail.com<mailto: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.