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

[Benjamin Kaduk <[e-mail]>]

On Wed, Apr 10, 2019 at 10:40:06PM +0000, Yemin (Amy) wrote:
> 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]".

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


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

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

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

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

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

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

> 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?

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

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

That's probably still worth saying explicitly.

Thanks,

Ben

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