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

2018-11-29 Thread Les Ginsberg (ginsberg) 
https://tools.ietf.org/html/draft-ietf-lsr-isis-rfc7810bis-03 has been 
published. This addresses the inconsistency with RFC7471.

   Les


From: Les Ginsberg (ginsberg)
Sent: Wednesday, November 28, 2018 2:46 PM
To: Alvaro Retana ; John Scudder ; 
draft-ietf-lsr-isis-rfc7810...@ietf.org
Cc: Hares Susan ; idr-cha...@ietf.org; 
draft-ietf-idr-te-pm-...@ietf.org; idr@ietf. org ; lsr@ietf.org; 
lsr-cha...@ietf.org
Subject: RE: Available Bandwidth erratum 5486 [was: Re: AD Review of 
draft-ietf-idr-te-pm-bgp-14]

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 mailto:aretana.i...@gmail.com>>
Sent: Wednesday, November 28, 2018 2:35 PM
To: John Scudder mailto:j...@juniper.net>>; 
draft-ietf-lsr-isis-rfc7810...@ietf.org
Cc: Hares Susan mailto:sha...@ndzh.com>>; 
idr-cha...@ietf.org; 
draft-ietf-idr-te-pm-...@ietf.org; 
idr@ietf. org mailto:i...@ietf.org>>; 
lsr@ietf.org; 
lsr-cha...@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 
(j...@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 rally 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 
mailto:aretana.i...@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)
 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)
 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

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

2018-11-28 Thread Alvaro Retana 
On November 28, 2018 at 5:46:08 PM, Les Ginsberg (ginsberg) (
ginsb...@cisco.com) wrote:

Les:

Hi!

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 already requested the start of the IETF LC for rfc7810bis.  I don’t think
the potential changes we’re talking about will be that significant to delay.

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).

Yes, draft-ietf-idr-te-pm-bgp was simply first on my queue…so I read it
first.

It would have been less confusing – at least to me – if you had raised this
point in a separate email regarding rfc7810bis.

https://mailarchive.ietf.org/arch/msg/lsr/92-08uCr6-ctnRU9i3FHA-ucFEw

Thanks!

Alvaro.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

2018-11-28 Thread Les Ginsberg (ginsberg) 
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 
Sent: Wednesday, November 28, 2018 2:35 PM
To: John Scudder ; draft-ietf-lsr-isis-rfc7810...@ietf.org
Cc: Hares Susan ; idr-cha...@ietf.org; 
draft-ietf-idr-te-pm-...@ietf.org; idr@ietf. org ; lsr@ietf.org; 
lsr-cha...@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 
(j...@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 rally 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 
mailto:aretana.i...@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)
 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)
 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 
(j...@juniper.net) wrote:
+lsr to the cc

Hi Alvaro,

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

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

2018-11-28 Thread Alvaro Retana 
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 (j...@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 rally 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  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
)
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
)
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 (j...@juniper.net) wrote:

+lsr to the cc

Hi Alvaro,

On Nov 28, 2018, at 4:01 PM, Alvaro Retana  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



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

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

2018-11-28 Thread John Scudder 
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 rally 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 
mailto:aretana.i...@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)
 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)
 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 
(j...@juniper.net) wrote:

+lsr to the cc

Hi Alvaro,

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

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

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

2018-11-28 Thread Alvaro Retana 
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
)
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
)
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 (j...@juniper.net) wrote:

+lsr to the cc

Hi Alvaro,

On Nov 28, 2018, at 4:01 PM, Alvaro Retana  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



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

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

2018-11-28 Thread John E Drake 
Hi,

Comments inline

Yours Irrespectively,

John

From: Idr  On Behalf Of John Scudder
Sent: Wednesday, November 28, 2018 4:34 PM
To: Alvaro Retana 
Cc: lsr@ietf.org; idr@ietf. org ; 
draft-ietf-idr-te-pm-...@ietf.org; Hares Susan ; 
idr-cha...@ietf.org
Subject: [Idr] Available Bandwidth erratum 5486 [was: Re: AD Review of 
draft-ietf-idr-te-pm-bgp-14]

+lsr to the cc

Hi Alvaro,

On Nov 28, 2018, at 4:01 PM, Alvaro Retana 
mailto:aretana.i...@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=DwMFaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=hLt5iDJpw7ukqICc0hoT7A=pNTkxj6RjNdyIYjBZKCUjdk9QWVKbBBhnnfj9xq2jjU=QvXYEMqBgaIkuM7plcuybtDVxI3JTI-4EndPcX0ier8=>

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.



[JD]  John's suggestion, above, is correct.

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 e