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

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 02 Jul 2018 08:38:22 -0700

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.

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 2 Jul 2018 16:51:58 -0700

Hi Benjamin,
thank you for the thorough review and the most detailed analysis of the
specification. Please find my answers in-line tagged GIM>>.

Regards,
Greg

> https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/
GIM>> Thank you for catching this one! Without getting into the history,
here's the new paragraph to be the next to the last para in section 5.13.1:

      If the Poll (P) bit is set, and bfd.SessionType is PointToPoint,
      send a BFD Control packet to the remote system with the Poll (P)
      bit clear, and the Final (F) bit set (see Section 5.13.3).

> for implementors to do so without mentioning the change in behavior.

GIM>> Thank you for pointing to these absent paragraphs. Some of
information being provided in the section but some, I agree, is not part of
the section. That information helps to understand packet transmission
timing and how it affects defect detection interval.

The forth paragraphs of section 6.8.7 RFC 5880:

   The transmit interval MUST be recalculated whenever
   bfd.DesiredMinTxInterval changes, or whenever bfd.RemoteMinRxInterval
   changes, and is equal to the greater of those two values.  See
   sections 6.8.2 and 6.8.3 for details on transmit timers.

used in section 5.13.3 of mpBFD specification:
   If bfd.SessionType is not MultipointHead, the transmit interval MUST
   be recalculated whenever bfd.DesiredMinTxInterval changes, or
   whenever bfd.RemoteMinRxInterval changes, and is equal to the greater
   of those two values.  See [RFC5880] sections 6.8.2 and 6.8.3 for
   details on transmit timers.

The first three paragraphs that are missing and I propose to use them as-is
in RFC 5880 to replace the second paragraph of mpBFD spec (new version and
diff attached).

> 5880, given (e.g.) Section 5.4.1.
GIM>> mpBFD specification adds new values to a variable defined in RFC 7880
but does not change anything specified in RFC 7880. I'm not sure that this
relationship between the RFC 7880 and mpBFD can be characterized as the
latter updating the former.

> incompatible with BFD or does it merely require additional specification).
GIM>> I believe it requires additional specification, i.e. outside the
scope and for future work.

GIM>> I see the scope of this specification similar to RFC 5880, in which
there's no discussion of how BFD Control packet must be encapsulated. For
"classic" BFD, encapsulation addressed in RFC 5881, RFC 5883, RFC 5884, and
RFC 5885. Non-IP encapsulation for MPLS-TP defined in RFC 6428.

> so it is not fully ignorant.)
GIM>> Thank you for text, accepted.

>    [I-D.ietf-bfd-multipoint-active-tail].
GIM>> Thanks, done.

> Presumably this is just a failing on my end, of course.
GIM>> The value of My Discriminator is locally assigned, i.e., assigned by
the head. Unless some system manages discriminator ranges amond heads, it
is probable that more than one use the same My Discriminator value.

> of", and "the control plane".
GIM>> More thanks, all accepted.

> distinguish from the case in the first paragraph (where a non-Up state
GIM>> I think that the two paragraphs correctly describe behavior options
for a MultipointTail session when it receives BFD Control packet with
Down/AdminDown state. The tail MAY close the session upon recieving packet
with Down/AdminDown state. The second para is related to section 5.12.1
that the MultipointHead SHOULD continue transmitting BFD control packets
with the new state, i.e., Down/AdminDown state.

Section 8
> or just move it to this section entirely.
GIM>> Merged sections 6 and 8 under Security Considerations.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 3 Jul 2018 16:37:19 -0500

>       bit clear, and the Final (F) bit set (see Section 5.13.3).

A natural translation to the new world order.

> in RFC 5880 to replace the second paragraph of mpBFD spec (new version and

That works for me.

> latter updating the former.

I'm not sure, either.  The case for Updating would mostly just be that
someone implementing 7880 would want to know if they see new/unexpected
values on their peer (and I've forgotten if this one is even wire-visible).

> scope and for future work.

Okay.  Do you want to add something like ", but integrating such
authentication mechanisms with BFD is outside the scope of the present
work"?
[edit: I see you did add something; that works for me]

> RFC 5885. Non-IP encapsulation for MPLS-TP defined in RFC 6428.

My question is entirely about the current connotations of a term in a
community where I am not active, so I really have to leave this question to
be answered by the authors/WG.

> is probable that more than one use the same My Discriminator value.

I was probably assuming that the discriminators were random values; thanks
for clarifying.

> with the new state, i.e., Down/AdminDown state.

I also agree that the paragraphs are correct behavior descriptions -- the
combination just made me do a double-take when I first read it.  But this
is basically editorial, so use your judgment.

> GIM>> Merged sections 6 and 8 under Security Considerations.

That combination seems to work pretty well.  (Full draft text trimmed.)

Thanks!

-Benjamin