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

From: Eric Rescorla <[email-masked]>
Date: Tue, 03 Jul 2018 17:17:40 -0700

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?

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.

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.

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"

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 5 Jul 2018 16:04:15 -0700

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

Regards,
Greg

> https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint-active-tail/
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).

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

> >      If the head wishes to know of active the tails, it sends multipoint
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).

> >      for a session of type MultipointClient is same and the diagram is
GIM>> Thank you, Done.