Benjamin Kaduk's Discuss on draft-ietf-bfd-multipoint-18: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-bfd-multipoint-18: 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-bfd-multipoint/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Section 5.13('s subsections) of this document replace sections 6.8.6 and
6.8.7 of RFC 5880.  I extracted the relevant text and performed a diff, and
think some discussion is needed of some portions present in RFC 5880 that
are not present in these new texts.  (The separation of the demultiplexing
procedure to a separate subsection is fine, though it does make the diff a
little nosier to read.)

In particular, from RFC 5880 Section 6.8.6, the paragraph:

%      If the Poll (P) bit is set, send a BFD Control packet to the
%      remote system with the Poll (P) bit clear, and the Final (F) bit
%      set (see section 6.8.7).

Does not appear to have any corresponding text in this document.

>From RFC 5880 Section 6.8.7, the first four paragraphs (too long for me to
include here) do not appear to have their substance covered in this
document, either (largely discussion about the pacing of BFD Control
packets and jitter in their scheduling).

Section 5.13.3's text now only covers how to set Min Echo Rx Interval
for MultipointHead and MultiplintTail sessions, which seems to remove
guidance on how to set it for other session types.

While it is permissible for a document that Updates another document to
perform this sort of deprecation of behavior, it is potentially confusing
for implementors to do so without mentioning the change in behavior.


Separately, I wonder if it is appropriate to Update RFC 7880 as well as
5880, given (e.g.) Section 5.4.1.

I also think that Section 6 should describe more clearly how asymmetric
message authentication relates to this work (i.e., whether it is entirely
incompatible with BFD or does it merely require additional specification).


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.