Ballot for draft-ietf-ccamp-rsvp-te-bandwidth-availability
Yes
No Objection
Note: This ballot was opened for revision 14 and is now closed.
(1) Section 3.2. Nit. s/When a node receives Availability TLVs which mixed of zero index and non-zero index/ When a node receives Availability TLVs with both zero and non-zero indexes/ s/there’re are/there are/ (2) Section 4.0. Nit. s/Especially section 7.1.2 of [RFC5920] discuss/Section 7.1.2 of [RFC5902] discusses/ (3) Concur with secdir review/Magnus on the need to clarify the format of the availability field (is it IEEE754-2008?) If IEEE754 is used (as Ben/Ignas notes due to RFC8330), then the text should explicitly cite the constraints of the precision referenced by Magnus.
I must admit that I'm having a hard time understanding the utility of this, and how exactly systems are supposed to make a reasonable decision based upon the information -- I don't **really** care that the probability of the link being at 100Mbps is 99.995%, what I care about is what the available bandwidth is *now*. When my device has a 123Mbps flow, it needs to decide what to do with it -- I get that this document describes how the bandwidth probability can be transmitted, but how should my device use this information? I'm also confused by the table: Sub-bandwidth (Mbps) Availability ------------------ ------------ 200 99.99% 100 99.995% 100 99.999% Is there an error here? I also support the DISCUSS on the floating-point issue -- perhaps this could be much more simply encoded with a table and some bits? E.G: 25%, 50%, 75%, 80%, 90%, 91%, 92%.. 99%. If > 99%, then the remaining gets used to encode the "number of nines" availability (5 == 5 nines). Edit: Also, thank you to Shwetha Bhandari for the useful OpsDir review.
COMMENTS ======== C1) Section 3.1 "Availability TLV" is a little too generic IMHO, should rather be named "Bandwidth availability TLV" C2) Section 3.1, the availability encoding by a float is possibly not the optimum one esp with 3 bytes 'reserved'. I would have expected something (perhaps too simple ?) such as one byte where 'n' means availability of 1-10**n (for example, 3 means 1-10**-3 == 0.999). But, this is a detail. NITS ==== N1) Section 3.1, s/MUST be less than 1and/MUST be less than 1 and/
Thanks for addressing my DISCUSS!
Thank you for a well written document. I have a few easy to address comments. Other people already commented on the lack of reference for the float format. In the following text: When a node does not support the Availability TLV, the node SHOULD generate a PathErr message with the error code "Extended Class-Type Error" and the error value "Class-Type mismatch" (see [RFC2205]). When a node receives Availability TLVs which mixed of zero index and non-zero index, the message MAY be ignored and SHOULD NOT be What does “MAY ignore” mean here and what are the implications of not ignoring? I tend to think that this shoukd be MUST for interoperability, so either changing this to MUST or adding explanatory text for MAY would address my concern. propagated. When a node receives Availability TLVs (non-zero index) with no matching index value among the bandwidth-TLVs, the message MAY be ignored and SHOULD NOT be propagated. When a node receives Same comment as above. several <bandwidth, availability> pairs, but there're are extra bandwidth-TLVs without matching index Availability-TLV, the extra bandwidth-TLVs MAY be ignored and SHOULD NOT be propagated.
I support Benjamin's DISCUSS point about the error handling.
I also support Benjamin's DISCUSS.
— Section 3.1 — When the Availability TLV is included, it MUST be present along with the Ethernet Bandwidth Profile TLV. I had to read this a couple of time to get it. I suggest that this reads a bit better: NEW When the Availability TLV is included, the Ethernet Bandwidth Profile TLV MUST also be included. END There’s also a nit in the description of “Availability”: “1and” is missing a space. — Section 3.2 — When a node receives Availability TLVs which mixed of zero index and non-zero index, Nit: “...TLVs with a mix of zero index...” Nit later in the section: change “there're are” to “there are”.
Thank you for resolving my discuss point about imposing requirements on implementations that do not implement this specification. I trust Adam to get the details right of the IEEE754 binary floating-point format language, and will clear on that point as well.
A few nits: s3.1: Please indicate that float encoding is IEEE745 SP, same as in other GMPLS documents. s7: "demodulating to a lower modulation level" - maybe change to "moving to a lower demodulation level", as it is the sender modulation scheme that defines what and how can be demodulated on the receiver side.
Just one quick question I was wondering about in section 3.2.: "When a node receives several <bandwidth, availability> pairs, but there're are extra bandwidth-TLVs without matching index Availability-TLV, the extra bandwidth-TLVs MAY be ignored and SHOULD NOT be propagated." Why is that? Is it not valid to also send some requests without availability? I thought that would make sense because it's basically saying, "just give me whatever you have because I don't know the availability requirements anyway", no?
I support Ben's DISCUSS as well. * In addition, I could not find any reference to the Extended Class-Type Error and the error value Class-Type mismatch even in the IANA registry at https://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xhtml Is this something you are defining in this document? If so, an entry in the IANA consideration section is warranted. * Section 7 The table seems to be off. Shouldn't this be? 400 99.99% 200 99.995% 100 99.999%