Subject: Alvaro Retana's No Objection on draft-ietf-bfd-multipoint-18: (with COMMENT)

From: Alvaro Retana <[email-masked]>
Date: Wed, 04 Jul 2018 11:56:28 -0700

Alvaro Retana has entered the following ballot position for
draft-ietf-bfd-multipoint-18: 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/

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

(1) This document is marked as Updating rfc5880, buy §4.1 (in rfc5880), still
has this text:

Multipoint (M)

   This bit is reserved for future point-to-multipoint extensions to
   BFD.  It MUST be zero on both transmit and receipt.

...which should also be addressed in this document.

(2) §5.3. (Session Failure Semantics): "If a MultipointTail session fails...the
tail should take appropriate action."  What is an "appropriate action"?  I'm
guessing that this has to do with I-D.ietf-bfd-multipoint-active-tail, but that
only applies if a return path exists.  In the general case, should the tail
take any action?  Please clarify.

(3) §5.7 and §5.13.2 talk about "the identity of the multipoint path" -- what
is that?

(4) §5.13.2:

   If a session is not found, a new session of type
   MultipointTail MAY be created, or the packet MAY be
   discarded.  This choice MAY be controlled by the local
   policy, e.g. a maximum number of MultipointTail sessions and
   number of active MultipointTail sessions, and is outside the
   scope of this specification.

I think the last "MAY" above is out of place (s/MAY/may): if local policy
doesn't exist, what is the option?  The text says that this topic is outside
the scope...but I'm not sure if that means the local policy or the choice
itself.  §8 (Security Considerations) offers some more insight...but it doesn't
explicitly specify a limit to the number of MultipointTail sessions -- should
one exist?

The text above also calls out the "number of active MultipointTail sessions" as
if it were something different (from simply the number of MultipointTail
sessions), but this difference is not explained or mentioned anywhere else.  Is
there a difference?  Is there a need to call this out?

(5) Nit:  Please don't abbreviate to "My Discr" and "Your Discr".

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 6 Jul 2018 13:48:16 -0700

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

Regards,
Greg

> https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/
GIM>> Section 5.13.3 of the specification states:
      Multipoint (M)

         Set to 1 if bfd.SessionType is MultipointHead.  Otherwise, it
         is set to 0.

> take any action?  Please clarify.
GIM>> Great question, thank you. Would this text be acceptable:
    If a MultipointTail session fails, it means that the tail definitely
   has lost contact with the head (or the head has been administratively
   disabled) and the tail may use mechanisms other than BFD, e.g.,
   logging or NETCONF [RFC6241], to send a notification to the user.

> (3) §5.7 and §5.13.2 talk about "the identity of the multipoint path" --
GIM>> I think that will depend on the use case. In general, it is the
destination address, IP or the top MPLS label. In case of VRRP, as
discussed in draft-mirsky-bfd-p2mp-vrrp-use-case
<https://datatracker.ietf.org/doc/draft-mirsky-bfd-p2mp-vrrp-use-case/>,
VRRP group address or network broadcast address/ink-local all nodes
multicast group. For use of mpBFD to monitor PIM-SM DR on the shared-media
link
<https://datatracker.ietf.org/doc/draft-mirsky-pim-bfd-p2mp-use-case/?include_text=1>
the identity could be ALL-PIM-ROUTERS or, as for VRRP,  etwork broadcast
address/ink-local all nodes multicast group.

> itself.

GIM>> Applied s/MAY/can/ and re-worded as:
            If a session is not found, a new session of type
            MultipointTail MAY be created, or the packet MAY be
            discarded.  This choice can be controlled by the local
            policy, e.g., by settinga maximum number of MultipointTail
            sessions.  Use of the local policy and the exact mechanism
            of it are outside the scope of this specification.

§8 (Security Considerations) offers some more insight...but it doesn't
> explicitly specify a limit to the number of MultipointTail sessions --
GIM>> I think it it may be either too liberal or too restrictive, depending
on the HW capabilities of the box.

> there a difference?  Is there a need to call this out?
GIM>> Thank you for pointing to thsi duplication. Removed (see above the
new text).

> (5) Nit:  Please don't abbreviate to "My Discr" and "Your Discr".
GIM>> Expanded on all occurences (and in active tails spec as well).