[CCAMP] Benjamin Kaduk's Discuss on draft-ietf-ccamp-rsvp-te-bandwidth-availability-14: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-ccamp-rsvp-te-bandwidth-availability-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-bandwidth-availability/



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


----------------------------------------------------------------------
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 <bandwidth, availability> 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.