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

[Benjamin Kaduk <[e-mail]>]

On Mon, Jul 02, 2018 at 04:51:58PM -0700, Greg Mirsky wrote:
> 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
> 
> On Mon, Jul 2, 2018 at 8:38 AM, Benjamin Kaduk <[e-mail]> wrote:
> 
> > 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.
> >
> 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).

A natural translation to the new world order.

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

That works for me.

> 
> >
> > Separately, I wonder if it is appropriate to Update RFC 7880 as well as
> > 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.

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

> >
> > 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).
> >
> GIM>> I believe it requires additional specification, i.e. outside the
> 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]

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

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.

> >
> > 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>> Thank you for text, accepted.
> 
> >
> >    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>> Thanks, done.
> 
> >
> > 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>> 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.

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

> >
> >    [...] 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>> More thanks, all accepted.
> 
> >
> > 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>> 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.

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.

> 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.
> >
> GIM>> Merged sections 6 and 8 under Security Considerations.

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

Thanks!

-Benjamin