Re: Benjamin Kaduk's No Objection on draft-ietf-bfd-multipoint-19: (with COMMENT)

[Greg Mirsky <[e-mail]>]

Hi Benjamin,
thank you for the comments and suggestions. Please find my answers, notes
in-line and tagged GIM>>. Would you agree I roll them in when working with
the RFC Editor?

Happy New Year to All!

Regards,
Greg

On Fri, Dec 21, 2018 at 7:59 PM Benjamin Kaduk <[e-mail]> wrote:

> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-bfd-multipoint-19: No Objection
>
> 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-bfd-multipoint/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thank you for addressing my Discuss points!  The original Comment portion
> of my ballot is preserved below for posterity.
>
> I am told that the normal usage of the bare term "BFD" has the connotation
> of refering only to usages in an IP/UDP/MPLS encapsulation (exclusing
> pseudowires and other more "exotic" encapsulations), so I am not including
> this in my DISCUSS section.  However, it seems unusual to limit the scope
> of a document in some "random" subsection (here, Section 5.8) with no
> mention in the general Introduction or Abstract.  Is there an improvement
> to make here?
>
GIM>> Will add the following in the Introduction:
This document defines IP/UDP encapsulation of BFD Control message in
multipoint networks. Use of other types of encapsulation of the BFD Control
message are outside the scope of this document.

>
> Section 4
>
>    [...] If no
>    BFD Control packets are received by a tail for a detection time, the
>    tail declares the path to having failed.  For some applications this
>    is the only mechanism necessary; the head can remain ignorant of the
>    tails.
>
> It sounds like this might be better said as "the head can remain ignorant
> of the status of connectivity to the tails"?  (That is, the head needs to
> know at least something about the tails in order to send anything to them,
> so it is not fully ignorant.)
>
GIM>> Yes, agree. Would imagine that the head would stop sending BFD
control messages if there's no, at least, one tail.
Will update.

>
>    The head of a multipoint BFD session may wish to be alerted to the
>    tails' connectivity (or lack thereof).  Details of how the head keeps
>    track of tails and how tails alert their connectivity to the head are
>    outside scope of this document and are discussed in
>    [I-D.ietf-bfd-multipoint-active-tail].
>
> nit: "outside the scope"
>
GIM>> Thank you.

>
> Section 5.7
>
> It's a little unclear to me why tails must demultiplex on the identity of
> the
> multipoint path; (that is, why My Discriminator isinsufficient).
> Presumably this is just a failing on my end, of course.
>
GIM>> My Discriminator is not globally unique as it is allocated per
MultipointHead. Thus, it is possible, that a tail that belongs to several
multipoint paths, will receive BFD control packets from different heads but
with the same My Discriminator value.

>
>    [...] Bootstrapping BFD session to multipoint MPLS LSP in
>    case of penultimate hop popping may use control plane, e.g., as
>    described in [I-D.ietf-bess-mvpn-fast-failover], and is outside the
>    scope of this document.
>
> nit: some articles are missing here; maybe "a BFD session", "in the case
> of", and "the control plane".
>
GIM>> Thank you, agree to all three.

>
> Section 5.12.2
>
>    MultipointTail sessions MAY be destroyed immediately upon leaving Up
>    state, since tail will transmit no packets.
>
>    Otherwise, MultipointTail sessions SHOULD be maintained as long as
>    BFD Control packets are being received by it (which by definition
>    will indicate that the head is not Up).
>
> Would it be more clear to say "indicate that the head is not Up yet" to
> distinguish from the case in the first paragraph (where a non-Up state
> *transition*
>
GIM>> The second paragraph is to explain the behavior of a MultipointTail
if the MultipointHead acts as described in section 5.12.1. Perhaps we can
leave the text as is?

>
> Section 8
>
> It may be appropriate to make stronger statements about the weakness of MD5
> than were valid at the time of 5880's publication.  (SHA1 is also not doing
> so great, but I won't block this work on updating the hash function
> options.)
>
GIM>> Would the following text be acceptable (with both RFCs as
Informational reference):
  Updated Security Considerations for the MD5 Message-Digest and the
HMAC-MD5
   Algorithm [RFC6151] and Security Considerations for the SHA-0 and
   SHA-1 Message-Digest Algorithm [RFC6194] refer to the recent escalating
series of
   attacks on MD5 and SHA-1 as the reason to consider stronger algorithms.

It would be good to either refer to the bit about shared keys in Section 6
> or just move it to this section entirely.
>
GIM>> Merge sections 6 and 8? Section 7 will be removed in the final text
and these sections become adjacent. Perhaps can leave them as is, would you
agree?