Subject: Mirja Kühlewind's No Objection on draft-ietf-bfd-multipoint-active-tail-09: (with COMMENT)

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 03 Jul 2018 14:40:16 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-bfd-multipoint-active-tail-09: 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-active-tail/

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

1) I guess it makes sense to have section 6.2 before 6.1 as MultipointClient is
discussed in 6.1 but introduced in 6.2 currently.

2) sec 6.8 and 6.10 and later on: s/Required Min Rx
Interval/bfd.RequiredMinRxInterval/ ?

3) sec 6.9:
"The decision as to when to send a multipoint Poll is outside the
   scope of this specification.  However, it must never be sent more
   often than the regular multipoint BFD Control packet."
I think the doc should say more as when to send a poll. Also this should be an
upper case MUST. However, even sending it as often as the regular packets would
double the load and is therefore not desirable. I would like to see even
stricter requirements here.

4) In sec 6.10:
"This value can potentially be set much lower than in the multipoint
   case, in order to speed up a notification to the head, since the
   value will be used only by the single tail.  This value (and the lack
   of delay) are "sticky", in that once the tail receives it, it will
   continue to use it indefinitely. "
Given this value cannot be changed after initial sending, I would like to see a
minimum value of 1 sec to be specified.

5) 6.12:
"If the MultipointHead session is going down (which only happens
   administratively), all associated MultipointClient sessions SHOULD be
   destroyed as they are superfluous."
Not sure I understand why this requirement is normative. Also how does tail
know that the head was shut down (compared to connectivity is broken)...?

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 5 Jul 2018 14:07:42 -0700

Hi Mirja,
thank you for the review and comments. Please find my answers in-line
tagged GIM>>.

Regards,
Greg

> https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint-active-tail/
GIM>> This specification introduces the nex type of BFD session -
MultipointClient. The first three references are in section 5 while section
6 defines the new session type in details. Would adding more specifics to
the first paragraph of the Introduction section make the flow more logical:
   This application of BFD is an extension to Multipoint BFD
   [I-D.ietf-bfd-multipoint], which allows tails to notify the head of
   the lack of multipoint connectivity.  As a further option, heads can
   request a notification from the tails by means of a polling
   mechanism.  Notification to the head can be enabled for all tails, or
   for only a subset of the tails.  In order to achieve that, among
   several updates to [I-D.ietf-bfd-multipoint], the new state variables
   and new values for existing variables, e.g., the new session type
   MultipointClient, has been added.

> Interval/bfd.RequiredMinRxInterval/ ?
GIM>> These were defined in RFC 5880:

   - Required Min Rx Interval is the field in BFD Control message
   - bfd.RequiredMinRxInterval - BFD local variable

> stricter requirements here.
GIM>> Would the following be right use of the RFC 2119:

   However, it MUST NOT be sent more often
   than the regular multipoint BFD Control packet.

I believe that the text further in the paragraph suggests that because
multipoint poll messages are treated as regular BFD Control messages, the
former may be sent instead of non-poll:

   Since the tail will
   treat a multipoint Poll like any other multipoint BFD Control packet,
   Polls may be sent in lieu of non-Poll packets.

Intelligent implementation, I expect, will follow this note and thus avoid
duplication of BFD control packets on the wire.

> minimum value of 1 sec to be specified.
GIM>> The paragraph describes how the value of the Required Min RX Interval
field in the unicast Poll takes precedence over the value in the muticast
message. Because this value is used to determine the detection time,
setting it in the unicast Poll message to the lower value will result in
the shorter detection time for the particular tail. But this can be changed
to the value calculated based on multicast BFD packet by setting the value
of the Required Min RX Interval field in the unicast Poll the same as in
the multicast packet. Here's the text from the document:

   Therefore, if the head no longer
   wishes to single out the tail, it SHOULD reset the timer to the
   default by sending a Poll Sequence with the same value of Required
   Min Rx Interval as is carried in the multipoint packets, or it MAY
   reset the tail session by sending a Poll Sequence with state
   AdminDown (after the completion of which the session will come back
   up).

> know that the head was shut down (compared to connectivity is broken)...?
GIM>> I agree that "going down" is confusing. The text should be clear and
reference to Down/AdminDown state that the MultipointHead signals in BFD
Control packet. Please consider the new text:
   If the MultipointHead session is in Down/AdminDown state (which only
   happens administratively), all associated MultipointClient sessions
   SHOULD be destroyed as they are superfluous.