BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions

Note: This ballot was opened for revision 15 and is now closed.

Alvaro Retana Yes

(Ignas Bagdonas) No Objection

Deborah Brungard No Objection

(Ben Campbell) No Objection

Comment (2018-12-19 for -17)
Hi, thanks for the work on this. I just have a couple of editorial comments:

- abstract: Please expand BGP-LS on first mention here and in the introduction. While BGP is listed as a well-known abbreviation in the registry, BGP-LS is not.

§1: Please expand BGP-LS and NLRI on first mention.

Alissa Cooper No Objection

Comment (2018-12-17 for -17)
I suspect NLRI should be expanded on first use.

(Spencer Dawkins) No Objection

Comment (2018-12-17 for -17)
Thanks for engaging with the TSV-ART reviewer.

Benjamin Kaduk (was Discuss) No Objection

Comment (2018-12-19 for -17)
No email
send info
I will be interested to see what the RFC Editor thinks about "the semantics
[...] are described in [I-D.ietf-lsr-isis-rfc7810bis] and [RFC7471]", i.e.,
with both references containing the same content.  It's unclear that we
need to have a conversation about the apparent duplication at this point,

This is pretty clearly looking at the barn door when the horse is long
gone, but the referenced semantics talk about setting the A bit for when
one or more measured values "exceed a configiured maximum threshold", text
that seems to apply even to the field "min delay".  Is the "exceeds"
supposed to interpreted as "outside the expected range, whether that is 
numerically larger or smaller than the threshold value"?

Section 2.8

Would it help anyone to have the TLV tag values defined in this document
in the table as well?

Section 3

Thank you for adding the extra text recommended by the secdir reviewer!

(Suresh Krishnan) No Objection

Warren Kumari No Objection

Comment (2018-12-19 for -17)
No email
send info
I agree with Alexey (and Mirja?) - I had to go searching around to discover draft-ietf-lsr-isis-rfc7810bis -- a pointer would be helpful for those new to this...

(Mirja Kühlewind) No Objection

Comment (2018-12-14 for -16)
I know that this doc is only pointing to [I-D.ietf-lsr-isis-rfc7810bis] and [RFC7471] for the definition of the respective metrics, however, there are IPPM RFCs for each of these metrics that provide further insights on how the calculate them correctly, e.g. rfc3393 IP Packet Delay Variation. I guess it could have been good to provide pointers to these RFCs but it also seems that this doc is the wrong doc of the set of three...

Also thanks for addressing the comments of the TSV-ART review (and thanks Yoshi for the review!)!

(Terry Manderson) No Objection

(Alexey Melnikov) No Objection

Comment (2018-12-18 for -17)
No email
send info
The document is rather terse in definition of A and RESERVED, so I wish it would have made it clearer to casual reader that all of them are defined in draft-ietf-lsr-isis-rfc7810bis.

(Eric Rescorla) No Objection

(Adam Roach) No Objection

Martin Vigoureux No Objection

Comment (2018-12-20 for -17)

thank you for this document.
I only have caught nits.

s/Traffic Engineering Extensions/Traffic Engineering Metric Extensions/

To have a naming consistent with your references I'd do,
in section 2 and in IANA Section:
s/1120              Unidirectional Bandwidth Utilization/1120              Unidirectional Utilized Bandwidth/
and in Section 2.8:
s/| Unidirectional Bandwidth Utilization  |   39     |     33         |/| Unidirectional Utilized Bandwidth  |   39     |     33         |/

Not all figures are numbered. Either have numbering for all or for none. Since you never reference them, maybe you don't need numbering.
But if you keep it then:
                                 Figure X
   Type: xxxx

should become:
                                 Figure X
   Type: xxxx