Skip to main content

BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions
draft-ietf-idr-te-pm-bgp-18

Yes

(Alvaro Retana)

No Objection

(Adam Roach)
(Deborah Brungard)
(Eric Rescorla)
(Ignas Bagdonas)
(Suresh Krishnan)
(Terry Manderson)

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

Warren Kumari
No Objection
Comment (2018-12-19 for -17) Not sent
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...
Alvaro Retana Former IESG member
Yes
Yes (for -15) Unknown

                            
Adam Roach Former IESG member
No Objection
No Objection (for -17) Not sent

                            
Alexey Melnikov Former IESG member
No Objection
No Objection (2018-12-18 for -17) Not sent
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 IESG member
No Objection
No Objection (2018-12-17 for -17) Sent
I suspect NLRI should be expanded on first use.
Ben Campbell Former IESG member
No Objection
No Objection (2018-12-19 for -17) Sent
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.
Benjamin Kaduk Former IESG member
(was Discuss) No Objection
No Objection (2018-12-19 for -17) Sent for earlier
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!
Deborah Brungard Former IESG member
No Objection
No Objection (for -16) Not sent

                            
Eric Rescorla Former IESG member
No Objection
No Objection (for -17) Not sent

                            
Ignas Bagdonas Former IESG member
No Objection
No Objection (for -17) Not sent

                            
Martin Vigoureux Former IESG member
No Objection
No Objection (2018-12-20 for -17) Sent
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
Mirja Kühlewind Former IESG member
No Objection
No Objection (2018-12-14 for -16) Sent
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 IESG member
No Objection
No Objection (2018-12-17 for -17) Sent
Thanks for engaging with the TSV-ART reviewer.
Suresh Krishnan Former IESG member
No Objection
No Objection (for -17) Not sent

                            
Terry Manderson Former IESG member
No Objection
No Objection (for -17) Not sent