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

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

Alvaro Retana Yes

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,
though.


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!

Martin Vigoureux No Objection

Comment (2018-12-20 for -17)
Hello,

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

Abstract:
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:
   where:
                                 Figure X
   Type: xxxx

should become:
                                 Figure X
   where:
   Type: xxxx

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

(Adam Roach; former steering group member) No Objection

No Objection ( for -17)
No email
send info

(Alexey Melnikov; former steering group member) No Objection

No Objection (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.

(Alissa Cooper; former steering group member) No Objection

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

(Ben Campbell; former steering group member) No Objection

No Objection (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.

(Deborah Brungard; former steering group member) No Objection

No Objection ( for -16)
No email
send info

(Eric Rescorla; former steering group member) No Objection

No Objection ( for -17)
No email
send info

(Ignas Bagdonas; former steering group member) No Objection

No Objection ( for -17)
No email
send info

(Mirja Kühlewind; former steering group member) No Objection

No Objection (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!)!

(Spencer Dawkins; former steering group member) No Objection

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

(Suresh Krishnan; former steering group member) No Objection

No Objection ( for -17)
No email
send info

(Terry Manderson; former steering group member) No Objection

No Objection ( for -17)
No email
send info