Re: Eric Rescorla's No Objection on draft-ietf-bfd-multipoint-active-tail-09: (with COMMENT)

[Greg Mirsky <[e-mail]>]

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

Regards,
Greg

On Tue, Jul 3, 2018 at 5:17 PM, Eric Rescorla <[e-mail]> wrote:

> Eric Rescorla 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:
> ----------------------------------------------------------------------
>
> Rich version of this review at:
> https://mozphab-ietf.devsvcdev.mozaws.net/D3976
>
>
>
> COMMENTS
> S 5.2.3.
> >      (regardless of the state of the forward unicast path), the tail will
> >      detect the failure but the head will remain unaware of this fact.
> >
> >      The head will detect a BFD session failure to the tail but cannot
> >      make a determination about the state of the tail's multipoint
> >      connectivity.
>
> This seems to contradict the paragraph two above "If the multipoint
> path fails". Or am I misreading?
>
GIM>> The head will not receive Final from the tail and thus conclude that
the session had failed. The state of the multicast path is uncertain for
the head as both multicast and unicast Polls fail (note that forward unicast
path is expected to be fully disjoint with the multicast path).

>
>
> S 5.2.3.
> >      connectivity.
> >
> >      If the forward unicast path fails but the reverse unicast path stays
> >      up, the head will detect a BFD session failure to the tail if it
> >      happens to send a unicast Poll sequence, but cannot make a
> >      determination about the state of the tail's multipoint connectivity.
>
> This doesn't seem right if the multicast path works.
>
GIM>> This case is when the multicast path fails. Do you find the text
correct when the failure is in on the multicast tree?

>
>
> S 6.4.
> >      [I-D.ietf-bfd-multipoint], in which BFD Control packets flow only
> >      from the head and no tracking is desired of tail state at the head,
> >      is accomplished by setting bfd.ReportTailDown to 0 in the
> >      MultipointHead session (Section 5.1).
> >
> >      If the head wishes to know of active the tails, it sends multipoint
>
> This is ungrammatical.
>
GIM>> Would this re-wording improve the text:
   The most basic form of the operation of BFD in multipoint networks
   explained in [I-D.ietf-bfd-multipoint].  In this scenario, BFD
   Control packets flow only from the head and no tracking of tail state
   at the head is desired.  That can be accomplished by setting
   bfd.ReportTailDown to 0 in the MultipointHead session (Section 5.1).

>
>
> S 6.5.
> >   6.5.  State Machine
> >
> >      Though the state transitions for the state machine, as defined in
> >      section 5.5 of [I-D.ietf-bfd-multipoint], for a session type
> >      MultipointHead are only administratively driven, the state machine
> >      for a session of type MultipointClient is same and the diagram is
>
> "is the same"
>
GIM>> Thank you, Done.