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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Tue, 09 Apr 2019 10:37:40 -0700

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.

---

From: "Yemin (Amy)" <[email-masked]>
Date: Wed, 10 Apr 2019 22:40:06 +0000

Hi Benjamin,

Thanks for the comments. Please see reply inline below.
Thanks.

BR,
Amy
________________________________________
发件人: Benjamin Kaduk via Datatracker [[email-masked]]
发送时间: 2019年4月10日 1:37
收件人: The IESG
抄送: [email-masked]; Daniele Ceccarelli; [email-masked]; [email-masked]; [email-masked]
主题: Benjamin Kaduk's Discuss on draft-ietf-ccamp-rsvp-te-bandwidth-availability-14: (with DISCUSS and COMMENT)

[Amy]
Serveral comments were received about the normative requirement here.
How about the following text:
When a node does not support the Availability TLV, the node should send a PathErr
message with Error Code "Unknown Attributes TLV[RFC 5420]".

Thanks for point it out, the "error code "Extended Class-Type Error" and the error value "Class-Type mismatch" (see [RFC2205])", the text is referenced from RFC6003.
After double check, they are not defined in the RFC2205, neither in some other RFC.
Unknown Attributes TLV from RFC 5420 should be better here.

[Amy] Yes, it's better to use the floating-point format in order to align with RFC8330.
IEEE754 will be added as a reference.

Section 1

Is this the behavior mandated by RFC 3209/etc., or a new description in
this document?
[Amy] Good point. How about change the text to:
the bandwidth may be reserved as

Section 3.1

Type (2 octets): 0x04

[Amy] will change as suggested.

[Amy] will change as suggested.

It's surprising to see this as a "SHOULD" (not "MUST")...
[Amy] will change to "MUST".

... 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.
[Amy] I think just one additional step.
First to judge if the index is 0, if yes, then apply the only availability value to all the bandwidth request;
if not, apply the availability values to each the bandwidth request.
A strict one-to-one matching surely is also possible. I don't have strong opinion here.

Section 3.2

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.
[Amy] Thanks, will use RFC 3471 instead.

Section 3.2

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?
[Amy] If strict one-to-one matching is applying, the error process should become simpler.
I see the point now.

[Amy] will fix the nits.

[Amy] How about change both to MUST/MUST NOT?

Section 4

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.
[Amy] If some/all of the nodes on the path do/don't support this extension,
it's still possible to set up the LSP as long as there's enough bandwidth along
the path. It's just that the availability level of the reserved bandwidth is
unknown along the path(or in some part of the path), which makes the
mechnism less useful.

Section 5.1

[Amy] Just follow the usual format in IANA section.

Section 7

[Amy]This is additional information to help understanding the availability better.
So it's as appendix.

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 11 Apr 2019 13:55:48 -0500

> Thanks for the comments. Please see reply inline below.

That's an improvement.  Might I suggest:

When a node does not support the Availability TLV, the node should send a
PathErr message with Error Code "Unknown Attributes TLV", as specified in
[RFC 5420].

> IEEE754 will be added as a reference.

Agreed.  (I saw all the discussion going on elsewhere and was confident the
right thing was going to happen, so this part was just to procedurally do
the right thing as well.)

I think I actually prefer the original version.  Maybe "will likely be
reserved", if that is accurate?

> A strict one-to-one matching surely is also possible. I don't have strong opinion here.

I don't have a strong opinion, either; this is just a non-blocking comment.

> [Amy] How about change both to MUST/MUST NOT?

That seems helpful, to me.  (The first comment is mostly just  an
observation, and I don't see any easy changes that would improve things.)

> unknown along the path(or in some part of the path), which makes the

That's probably still worth saying explicitly.

Thanks,

Ben