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 
<[email protected]<mailto:[email protected]>> 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 
([email protected]<mailto:[email protected]>) wrote:

+lsr to the cc

Hi Alvaro,

On Nov 28, 2018, at 4:01 PM, Alvaro Retana 
<[email protected]<mailto:[email protected]>> 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.

_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to