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

["Yemin (Amy)" <[e-mail]>]

Hi Benjamin,

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

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

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

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

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

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

----------------------------------------------------------------------
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?
[Amy] Good point. How about change the text to:
the bandwidth may be reserved as

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.
[Amy] will change as suggested.

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 [...]"?
[Amy] will change as suggested.

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")...
[Amy] will change to "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.
[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

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

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

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/
[Amy] will fix the nits.

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.)
[Amy] How about change both to MUST/MUST NOT?

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

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.
[Amy] Just follow the usual format in IANA section.

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.
[Amy]This is additional information to help understanding the availability better.
So it's as appendix.