Subject: [Idr] AD Review of draft-ietf-idr-te-pm-bgp-14

From: Alvaro Retana <[email-masked]>
Date: Wed, 28 Nov 2018 13:01:29 -0800

Dear authors:

I just finished reading this document.  Please see the comments in-line
below.

I found only one significant issue with the definition of Available
Bandwidth (see my comment in §3.6).  This issue, along with my other
comments (mostly nits), should be easy to address.  I am then starting the
IETF Last Call.

Thanks!

Alvaro.

[Note: the line numbers come from idnits.]

...
17 Abstract

19   This document defines new BGP-LS TLVs in order to carry the IGP
20   Traffic Engineering Extensions defined in IS-IS and OSPF protocols.

[nit] s/defined in IS-IS and OSPF protocols/defined in the IS-IS and OSPF
protocols

22 Requirements Language

24   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
25   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
26   "OPTIONAL" in this document are to be interpreted as described in BCP
27   14 [RFC2119] [RFC8174] when, and only when, they appear in all
28   capitals, as shown here.

[major] No Normative language is used -- which is not a bad thing.  Please
remove the boilerplate text and the appropriate references.

...
90 2.  Link Attribute TLVs for TE Metric Extensions

92   The following new Link Attribute TLVs are defined:

94      TLV Name
95   ------------------------------------------
96    Unidirectional Link Delay

98    Min/Max Unidirectional Link Delay

100    Unidirectional Delay Variation

102    Unidirectional Link Loss

104    Unidirectional Residual Bandwidth

106    Unidirectional Available Bandwidth

108    Unidirectional Bandwidth Utilization

[nit] This is weird seemingly-stub section.  Consider renaming §3 "Link
Attribute TLVs for TE Metric Extensions", moving the contents there and
turning the list above into a table including the new TLV types...

110 3.  TLV Details

112 3.1.  Unidirectional Link Delay TLV

114   This TLV advertises the average link delay between two directly
115   connected IGP link-state neighbors.  The semantic of the TLV is
116   described in [RFC7810] and [RFC7471].

[nit] s/semantic/semantics

[minor nit] In rfc7810, the Type and Length fields are 1-byte each...so in
reality rfc7810/rfc7471 describe the semantics of the Value field (not the
whole TLV).  Maybe some short text in §3 about the TLV format following the
specification in rfc7752 would help.

...
220 3.6.  Unidirectional Available Bandwidth TLV

222   This sub-TLV advertises the available bandwidth between two directly
223   connected IGP link-state neighbors.  The semantic of the TLV is
224   described in [RFC7810] and [RFC7471].

226    0                   1                   2                   3
227    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
228   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
229   |   Type                      |           Length                |
230   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
231   |                      Available Bandwidth                      |
232   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

[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

...
284 5.  IANA Considerations

286   This document requests assigning code-points from the registry "BGP-
287   LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute
288   TLVs" for the new Link Attribute TLVs defined in the table below:

290    TLV code-point                 Value
291   --------------------------------------------------------
292    1114              Unidirectional Link Delay

294    1115              Min/Max Unidirectional Link Delay

296    1116              Unidirectional Delay Variation

298    1117              Unidirectional Link Loss

300    1118              Unidirectional Residual Bandwidth

302    1119              Unidirectional Available Bandwidth

304    1120              Unidirectional Bandwidth Utilization

[major] This document doesn't request the assignments, but IANA has done
the early allocation...  Please correct.

...
325 8.1.  Normative References
...
332   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
333              Border Gateway Protocol 4 (BGP-4)", RFC 4271,
334              DOI 10.17487/RFC4271, January 2006,
335              <https://www.rfc-editor.org/info/rfc4271>.

[minor] I think this can be an Informative reference: just like rfc4272 and
rfc6952 are.

...
348   [RFC7810]  Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and
349              Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions",
350              RFC 7810, DOI 10.17487/RFC7810, May 2016,
351              <https://www.rfc-editor.org/info/rfc7810>.

[major] Please use draft-ietf-lsr-isis-rfc7810bis as the reference.

---

From: John Scudder <[email-masked]>
Date: Wed, 28 Nov 2018 21:33:48 +0000

+lsr to the cc

Hi Alvaro,

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

---

From: John E Drake <[email-masked]>
Date: Wed, 28 Nov 2018 22:05:04 +0000

Hi,

Comments inline

Yours Irrespectively,

John

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

+lsr to the cc

Hi Alvaro,

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

$0.02,

--John

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 28 Nov 2018 14:15:55 -0800

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

+lsr to the cc

Hi Alvaro,

On Nov 28, 2018, at 4:01 PM, Alvaro Retana <[email-masked]> wrote:

[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=>

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

   forwarding of non-RSVP-TE label switched path packets.  *For a bundled
   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:

   forwarding of non-RSVP-TE label switched path packets.  *For a bundled
*

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:

   link available *residual* bandwidths minus the measured bandwidth
used for the

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

---

From: John Scudder <[email-masked]>
Date: Wed, 28 Nov 2018 22:26:00 +0000

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-masked]<mailto:[email-masked]>> wrote:

John:

Hi!

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

   (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
   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

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

+lsr to the cc

Hi Alvaro,

$0.02,

--John

---

From: John E Drake <[email-masked]>
Date: Wed, 28 Nov 2018 22:29:54 +0000

Alvaro,

As I said, John’s suggestion is correct and it does match 7471, which is also correct.

Yours Irrespectively,

John

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

John:

Hi!

   (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=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=yVSlstlwtIdGa4qM-eRQ34GeMj3p0oJ-3o1oowPEliM&s=oT_lg8iuCpiS6QvtFpdsRsCB5JfciH-CfY-WoN62KBI&e=>) minus the measured bandwidth used for the actual

   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=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=yVSlstlwtIdGa4qM-eRQ34GeMj3p0oJ-3o1oowPEliM&s=oT_lg8iuCpiS6QvtFpdsRsCB5JfciH-CfY-WoN62KBI&e=>) minus the sum of the

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=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=yVSlstlwtIdGa4qM-eRQ34GeMj3p0oJ-3o1oowPEliM&s=lXqn9HIHadpGZfWJux2kr2WUCFsp-XXM1Epmv4uxNjU&e=>

Hi Alvaro,

On Nov 28, 2018, at 4:01 PM, Alvaro Retana <aretana.ietf@gmail..com<mailto:[email-masked]>> wrote:

$0.02,

--John

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 28 Nov 2018 14:34:53 -0800

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

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-masked]> wrote:

John:

Hi!

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

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=>

+lsr to the cc

Hi Alvaro,

$0.02,

--John

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 28 Nov 2018 22:46:05 +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 <[email-masked]>
Sent: Wednesday, November 28, 2018 2:35 PM
To: John Scudder <[email-masked]>; [email-masked]
Cc: Hares Susan <[email-masked]>; [email-masked]; [email-masked]; idr@ietf. org <[email-masked]>; [email-masked]; [email-masked]
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 ([email-masked]<mailto:[email-masked]>) wrote:
Ah, I was looking at an old version of 7810bis, sorry about that.

ISTM that:

No additional charge,

--John

John:

Hi!

Thanks!

Alvaro.

Hi Alvaro,

$0.02,

--John

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 28 Nov 2018 18:01:02 -0500

On November 28, 2018 at 5:46:08 PM, Les Ginsberg (ginsberg) (
[email-masked]) 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.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 29 Nov 2018 17:58:38 +0000

Alvaro –

Thanx for the review.
I am fine with all of your comments – but I do have one concern.

You suggest replacing the reference to RFC7810 with a reference to draft-ietf-lsr-isis-rfc7810bis.
If we do that then the publication of this document will be blocked on the publication of draft-ietf-lsr-isis-rfc7810bis. But the changes being made in the bis draft do not affect the content of this document in any way. So it makes more sense to me to continue to reference RFC 7810.

I’ll go with whatever you decide, but wanted to raise this point before making the suggested change.
???

    Les

From: Alvaro Retana <[email-masked]>
Sent: Wednesday, November 28, 2018 1:01 PM
To: [email-masked]
Cc: Susan Hares <[email-masked]>; idr@ietf. org <[email-masked]>; [email-masked]
Subject: AD Review of draft-ietf-idr-te-pm-bgp-14

Dear authors:

I just finished reading this document.  Please see the comments in-line below.

I found only one significant issue with the definition of Available Bandwidth (see my comment in §3.6).  This issue, along with my other comments (mostly nits), should be easy to address.  I am then starting the IETF Last Call.

Thanks!

Alvaro.

...
17       Abstract

[nit] s/defined in IS-IS and OSPF protocols/defined in the IS-IS and OSPF protocols

22       Requirements Language

[major] No Normative language is used -- which is not a bad thing.  Please remove the boilerplate text and the appropriate references.

...

94            TLV Name

[nit] This is weird seemingly-stub section.  Consider renaming §3 "Link Attribute TLVs for TE Metric Extensions", moving the contents there and turning the list above into a table including the new TLV types...

110     3.  TLV Details

[minor nit] In rfc7810, the Type and Length fields are 1-byte each...so in reality rfc7810/rfc7471 describe the semantics of the Value field (not the whole TLV).  Maybe some short text in §3 about the TLV format following the specification in rfc7752 would help.

...

226        0                   1                   2                   3

...

290        TLV code-point                 Value

[major] This document doesn't request the assignments, but IANA has done the early allocation...  Please correct.

...

[minor] I think this can be an Informative reference: just like rfc4272 and rfc6952 are.

...

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 29 Nov 2018 19:31:55 +0000

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 <[email-masked]>; John Scudder <[email-masked]>; [email-masked]
Cc: Hares Susan <[email-masked]>; [email-masked]; [email-masked]; idr@ietf. org <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: Available Bandwidth erratum 5486 [was: Re: AD Review of draft-ietf-idr-te-pm-bgp-14]

Alvaro –

   Les

From: Alvaro Retana <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, November 28, 2018 2:35 PM
To: John Scudder <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: Hares Susan <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; idr@ietf. org <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: Available Bandwidth erratum 5486 [was: Re: AD Review of draft-ietf-idr-te-pm-bgp-14]

Thanks!

Alvaro.

ISTM that:

No additional charge,

--John

John:

Hi!

Thanks!

Alvaro.

Hi Alvaro,

$0.02,

--John

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 30 Nov 2018 13:36:39 -0500

Hi!

Please change the reference.

I don’t foresee any delays in the processing
of draft-ietf-lsr-isis-rfc7810bis.  Do you (you are the lead Editor)?

Thanks!

Alvaro.

On November 29, 2018 at 12:58:40 PM, Les Ginsberg (ginsberg) (
[email-masked]) wrote:

You suggest replacing the reference to RFC7810 with a reference to
draft-ietf-lsr-isis-rfc7810bis.

If we do that then the publication of this document will be blocked on the
publication of draft-ietf-lsr-isis-rfc7810bis. But the changes being made
in the bis draft do not affect the content of this document in any way. So
it makes more sense to me to continue to reference RFC 7810.

I’ll go with whatever you decide, but wanted to raise this point before
making the suggested change.

???

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 30 Nov 2018 20:10:46 +0000

Alvaro –

V15 has been posted – I believe it addresses all of your comments.

I NEVER make assumptions about how long a process which is mostly out of my control will take. ☺

   Les

From: Alvaro Retana <[email-masked]>
Sent: Friday, November 30, 2018 10:37 AM
To: Les Ginsberg (ginsberg) <[email-masked]>; [email-masked]
Cc: Susan Hares <[email-masked]>; idr@ietf. org <[email-masked]>; [email-masked]
Subject: RE: AD Review of draft-ietf-idr-te-pm-bgp-14

Hi!

I don’t foresee any delays in the processing of draft-ietf-lsr-isis-rfc7810bis.  Do you (you are the lead Editor)?

Thanks!

Alvaro.

On November 29, 2018 at 12:58:40 PM, Les Ginsberg (ginsberg) ([email-masked]<mailto:[email-masked]>) wrote:
I am fine with all of your comments – but I do have one concern.