Re: [trill] Alvaro Retana's No Objection on draft-ietf-trill-p2mp-bfd-08: (with COMMENT)

[Donald Eastlake <[e-mail]>]

Hi Alvaro,

On Tue, Jan 23, 2018 at 10:45 AM, Alvaro Retana <[e-mail]>
wrote:

> Alvaro Retana has entered the following ballot position for
> draft-ietf-trill-p2mp-bfd-08: No Objection
>
> ...
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> (1) The first reference to I-D.ietf-bfd-multipoint appears in Section 5;
> please
> add one in the Introduction when Multipoint BFD is initially mentioned.
>

Sounds reasonable.


> (2) I think that using Normative Language (without quotation marks) to
> mention
> what is specified somewhere else can result in confusion as to which is the
> authoritative document.  This seems to be the case in Section 4: "If the M
> bit
> of the TRILL Header of the RBridge channel packet containing a BFD Control
> packet is non-zero, the packet MUST be dropped [RFC7175]."  The sentence
> sounds
> as if the behavior is specified in rfc7175, but that document says (in
> Section
> 3.2 (BFD Control Frame Processing)): "The following tests SHOULD be
> performed...Is the M bit in the TRILL Header non-zero?  If so, discard the
> frame."  Note that the behavior specified in rfc7175 doesn't use a
> "MUST".  The
> text in this document seems to be used to explain why a new message is
> needed,
> and not in a Normative way -- please clarify the text so that there is no
> inconsistency with respect to rfc7175.
>

I think it can be re-worded fairly easily to avoid being normative.


> (3) Section 5 says that the "processing in Section 3.2 of [RFC7175]
> applies...If the M bit is zero, the packet is discarded."  Section 3.2 has
> that
> "SHOULD" that I mentioned above, and it also mentions potential security
> issues, which are not referenced in this document.  Are there reasons to
> keep
> the "SHOULD" and not use "MUST" instead (for the p2mp case)?  If the same
> semantics as in rfc7175 are kept, then the Security Considerations should
> include the concerns.


I'm pretty sure this was supposed to imply MUST given the inconsistency
with reference to Section 4 as above. The wording is unconditional. It
appears from your point (2) above that the authors were thinking that, in
RFC 7175, the discard if the M bit was "wrong" was a MUST. So I think it
can be changed to use MUST in this draft and that would avoid having to
tweak the Security Considerations.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] <(508)%20333-2270> (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]