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

[Greg Mirsky <[e-mail]>]

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

Regards,
Greg

On Tue, Jul 3, 2018 at 2:40 PM, Mirja Kühlewind <[e-mail]> wrote:

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

>
> 2) sec 6.8 and 6.10 and later on: s/Required Min Rx
> 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


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

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


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