Ethernet Traffic Parameters with Availability Information
draft-ietf-ccamp-rsvp-te-bandwidth-availability-16

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