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

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 21 Dec 2018 19:59:10 -0800

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?

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

   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"

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.

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

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*

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

It would be good to either refer to the bit about shared keys in Section 6
or just move it to this section entirely.

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 27 Dec 2018 15:05:37 -0800

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

> https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/
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.

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

>    [I-D.ietf-bfd-multipoint-active-tail].
GIM>> Thank you.

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

> of", and "the control plane".
GIM>> Thank you, agree to all three.

> distinguish from the case in the first paragraph (where a non-Up state
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?

> so great, but I won't block this work on updating the hash function
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.

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