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

[Greg Mirsky <[e-mail]>]

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

Regards,
Greg

On Wed, Jul 4, 2018 at 11:56 AM, Alvaro Retana <[e-mail]>
wrote:

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

>
> (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.
>
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" --
> what
> is that?
>
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.

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

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 --
> should
> one exist?
>
GIM>> I think it it may be either too liberal or too restrictive, depending
on the HW capabilities of the box.

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