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

[Ballot comment]
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.

[Ballot comment]
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  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.

[Ballot discuss]
Thanks for everyone's work on this document.

§3.1:

>    Availability (4 octets): a 32-bit floating point number describes
>    the decimal value of availability requirement for this bandwidth
>    request. The value MUST be less than 1and is usually expressed in
>    the value of 0.99/0.999/0.9999/0.99999.

"32-bit floating point number" is not sufficiently precise to specify the
encoding of this field. Presumably, this is intended to use IEEE 754-2008
32-bit binary interchange format. Please specify this, and add a normative
citation for IEEE 754-2008.

[Ballot comment]
§3.2:

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

Presumably, this "SHOULD" is a restatement of behavior defined in RFC 2205? (I
presume this because there's no way for this specification to retroactively
impose requirements on implementations that don't support it.) If so, please
remove the RFC-2119 language (or include it only as a direct quote from the RFC
that defines the requirement in the first place).

[Ballot comment]
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%

[Ballot comment]
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.

[Ballot comment]
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).

[Ballot comment]
(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.

[Ballot discuss]
As the genart review notes, when Section 3.2 says:

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

is attempting to place a normative requirement on implementations that
do not implement this specification, which cannot possibly work.
The appropriate thing to do here is to say something like "as described
in Section Y of [RFC XXXX], a node that does not support the
Availability TLV will [behave in this fashion]", with no normative
language.  (Also, the RFC 2205 reference is not very helpful to me; as
far as I can tell it is just providing information about how to encode a
PathErr but does not tell me anything about the specific error code and
value indicated.)

I'll also hold a placeholder discuss point to wait for the [IEEE754]
reference for the floating-point format.  (I think that format is not a
great fit for this application, for many of the reasons that Magnus
notes, but RFC 8330 has kind of forced us into keeping it.)

[Ballot comment]
Section 1

  If the bandwidth availability requirement is not specified in the
  signaling message, the bandwidth will be reserved as the highest
  bandwidth availability. [...]

Is this the behavior mandated by RFC 3209/etc., or a new description in
this document?

Section 3.1

      Type (2 octets): 0x04

I think this should really have been "0x04 (suggested; TBD by IANA)".
The current text (both here and in Section 5.1) is very close to
codepoint squatting.  I have entered DISCUSS positions on documents in
the past for codepoint squatting, but relucantly decline to do so here,
since the IANA considerations do state that the indicated value is only
a suggestion, and the registration procedure of Standards Action
strongly limits the potential for a conflicting registration to be
processing in parallel.

      When the Availability TLV is included, it MUST be present along
      with the Ethernet Bandwidth Profile TLV. If the bandwidth
      requirements in the multiple Ethernet Bandwidth Profile TLVs have

nit: this is the first time we talk about "the multiple" TLVs; should we
give it a less-subtle introduction, like "If there are multiple
bandwidth requirements present (in multiple Ethernet Bandwidth Profile
TLVs) and they have different [...]"?

      different Availability requirements, multiple Availability TLVs
      SHOULD be carried. In such a case, the Availability TLV has a one

It's surprising to see this as a "SHOULD" (not "MUST")...

      to one correspondence with the Ethernet Bandwidth Profile TLV by
      having the same value of Index field. If all the bandwidth
      requirements in the Ethernet Bandwidth Profile have the same
      Availability requirement, one Availability TLV SHOULD be carried.
      In this case, the Index field is set to 0.

... and this extra complication seems like it might be premature
optimization.  A strict one-to-one matching requirement is easy to
implement and easy to verify; the logic needed for this is more
complicated and prone to error.

Section 3.2

  When two LSPs request bandwidth with the same availability
  requirement, contention MUST be resolved by comparing the node IDs,
  with the LSP with the higher node ID being assigned the reservation.
  This is consistent with general contention resolution mechanism
  provided in section 3.2 of [RFC3473].

It seems to me that Section 4.2 of RFC 3471 may be a better reference
than Section 3.2 of RFC 3473, since the latter does not actually say
anything about the higher node ID winning.

Section 3.2

  When a node receives Availability TLVs which mixed of zero index and
  non-zero index, the message MAY be ignored and SHOULD NOT be
  propagated. [...]

How would such a message be processed if the MAY is ignored (i.e., the
message is processed)?  Perhaps this is better as a MUST?

  MAY be ignored and SHOULD NOT be propagated. When a node receives
  several  pairs, but there're are extra

nit: s/there're are/there are/

  bandwidth-TLVs without matching index Availability-TLV, the extra
  bandwidth-TLVs MAY be ignored and SHOULD NOT be propagated.

This is perhaps an interesting recommendation to make, since it means
that implementations that support this document will ignore the
bandwidth-TLVs but implementations that do not support this document
will process them, leading to different behavior in terms of how many
reservations are actually made.  (And the "SHOULD NOT be propagated"
makes things highly path-dependent and possibly exciting to debug.)

Section 4

Thank you for removing the "does not introduce any new security
considerations" text as requested by the secdir reviewer, and adding the
"closed network" discussion.

That said, I expected to see some discussion about how the mechanisms
defined in this document impose consistency requirements between
Bandwidth TLVs and the newly defined Availability TLVs that can increase
the risk of reservation requests being rejected.

There could also be some text about the edge cases where behavior will
differ, for a given request, when some/all of the nodes on the path
do/don't support this extension.

Section 5.1

I'm not sure why we need to mention the registration procedure for the
registry -- we're not creating the registry, just allocating a
codepoint from it.  IANA will check/follow the required procedure, but
the reader of this document doesn't need to care.

Section 7

Thank you for this example, which really helps to clarify that the total
bandwidth is allocated into *non-overlapping* segments with different
max-availability metrics.  (That is, that even though there is 400 Mbps
capacity in clear weather, we don't report 400 Mbps at 99.99%
availability, since we need to use some of that capacity for the higher
availability levels.)  I a little bit wonder if this could be reiterated
in prose earlier in the document, but don't have any concrete
suggestions for how to do so.

[Ballot comment]
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.

[Ballot discuss]
Section 3.1:

      Availability (4 octets): a 32-bit floating point number describes
      the decimal value of availability requirement for this bandwidth
      request. The value MUST be less than 1and is usually expressed in
      the value of 0.99/0.999/0.9999/0.99999.

It appears that this format has some very clear limitations when it comes to store availability numbers. Assuming that this 32-bit float is an IEEE-754 representation which should be explicitly stated.

In that case representing availabilities higher than 0.999999 starts to introduce significant errors in relation to intended precision.
Intended value Error                                            Actual value
0.999999          -1.3278961181640625E-8              0.999998986721038818359375
0.9999999        -1.920928955078125E-8                0.99999988079071044921875
0.99999999      1E-8                                                  1 (Which is not allowed)

So at a minimal the limitations for what is practical to express needs to be provided. Secondly, are this range sufficient in all cases?

[Ballot comment]
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/

[Ballot comment]
— 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”.

[Ballot comment]
Just one quick question I was wondering about in section 3.2.:
"When a node receives
  several  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?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-ccamp-rsvp-te-bandwidth-availability-13. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the Ethernet Sender TSpec TLVs/Ethernet Flowspec TLVs on the Generalized Multi-Protocol Label Switching (GMPLS) Signaling Parameters registry page located at:

https://www.iana.org/assignments/gmpls-sig-parameters/

a single, new value is to be registered as follows:

Type: [ TBD-at-Registration ]
Description: Availability
Reference: [ RFC-to-be ]

IANA notes that the authors have suggested the value 0x04 for this value.

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-01-31):

From: The IESG
To: IETF-Announce
CC: Daniele Ceccarelli , ccamp-chairs@ietf.org, db3546@att.com, ccamp@ietf.org, daniele.ceccarelli@ericsson.com, draft-ietf-ccamp-rsvp-te-bandwidth-availability@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Ethernet Traffic Parameters with Availability Information) to Proposed Standard


The IESG has received a request from the Common Control and Measurement Plane
WG (ccamp) to consider the following document: - 'Ethernet Traffic Parameters
with Availability Information'
  as Proposed
  Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-01-31. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  A packet switching network may contain links with variable
  bandwidth, e.g., copper, radio, etc. The bandwidth of such links is
  sensitive to external environment (e.g., climate). Availability is
  typically used for describing these links when during network
  planning. This document introduces an optional Availability TLV in
  Resource ReSerVation Protocol - Traffic Engineer (RSVP-TE)
  signaling. This extension can be used to set up a Generalized Multi-
  Protocol Label Switching (GMPLS) Label Switched Path (LSP) using the
  Ethernet SENDER_TSPEC object.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-bandwidth-availability/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-bandwidth-availability/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2414/

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

>Proposed Standard. This is appropriate as extensions to RSVP-TE are defined and it is correctly indicated in the title page hearder.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  A packet switching network may contain links with variable bandwidth,
  e.g., copper, radio, etc. The bandwidth of such links is sensitive
  to external environment. Availability is typically used for
  describing the link during network planning. This document
  introduces an optional Availability TLV in Resource ReSerVation
  Protocol - Traffic Engineer (RSVP-TE) signaling. This extension can
  be used to set up a Generalized Multi-Protocol Label Switching
  (GMPLS) Label Switched Path (LSP) using the Ethernet SENDER_TSPEC
  object.

Working Group Summary

The document followed the regular process and no particular controversy was raised by any WG member. 

Document Quality

The document is supported both by vendors and operators active in the working group.

Personnel

Document Shepherd: Daniele Ceccarelli
Responsible Area Director: Deborah Brungard

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document is ready to be submitted to the IESG.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

None

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No. The document defines extensions to the RSVP-TE protocol. A routing area directorate review as per standard process should be sufficient.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.
Yes. All IPR declarations have been collected and stored in the history of the document: https://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-bandwidth-availability/history/

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

An IPR has been disclosed against the document in accordance with the process. No objection or issued raised by the WG.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The document is relevant to particular area which is of interest of a portion of the working group. All the members of the WG interested in that area showed support for the document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No such a threat.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

The document is clean.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

NO such reviews are needed for this document.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

The publication of this document will not change the status of any existing RFC.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

All the protocol extensions are correctly associated with the appropriate IANA registry reservations.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  The registration procedure for this registry is Standards Action as  defined in [RFC8126].

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

No such checks needed/performed.

Last call IPR poll (Daniele) https://mailarchive.ietf.org/arch/msg/ccamp/CljellvvYUya4k_aBhbhI4tfbQY

AUTHORS
Hao Long   Email: longhao@huawei.com https://mailarchive.ietf.org/arch/msg/ccamp/0D1XDhyHYnbVXkdlzSPvhHF-5W4
Min Ye   Email: amy.yemin@huawei.com https://mailarchive.ietf.org/arch/msg/ccamp/DltIhTLF-QOeobq6AKq2OIbQlqk
Greg Mirsky   Email: gregimirsky@gmail.com https://mailarchive.ietf.org/arch/msg/ccamp/Z86kjKth6-g3IV4EZtna7_QKlcM
Alessandro D'Alessandro   Email: alessandro.dalessandro@telecomitalia.it https://mailarchive.ietf.org/arch/msg/ccamp/Q_qvDEkImaqPAQvuWTcvIM2NIrI
Himanshu Shah   Email: hshah@ciena.com https://mailarchive.ietf.org/arch/msg/ccamp/NsJMLy4usqEVco-Obmta6YKNKXE

IPR poll (Deborah) http://www.ietf.org/mail-archive/web/ccamp/current/msg16390.html

Hao Long   Email: longhao@huawei.com http://www.ietf.org/mail-archive/web/ccamp/current/msg16411.html
  Min Ye   Email: amy.yemin@huawei.com http://www.ietf.org/mail-archive/web/ccamp/current/msg16409.html
  Greg Mirsky   Email: gregory.mirsky@ericsson.com http://www.ietf.org/mail-archive/web/ccamp/current/msg16408.html
  Alessandro D'Alessandro   Email: alessandro.dalessandro@telecomitalia.it http://www.ietf.org/mail-archive/web/ccamp/current/msg16413.html
  Himanshu Shah   Email: hshah@ciena.com http://www.ietf.org/mail-archive/web/ccamp/current/msg16406.html