Re: [RTG-DIR] RtgDir review: draft-ietf-bfd-multipoint-16

[Greg Mirsky <[e-mail]>]

Hi Michael,
thank you for your thorough review, thoughtful and detailed comments and
suggestions.
Please find my answers, notes in-line tagged GIM>>.

Regards,
Greg

On Sat, May 12, 2018 at 4:04 PM, Michael Richardson <[e-mail]>
wrote:

>
> Hello,
>
> I have been selected as the Routing Directorate reviewer for this draft.
> The
> Routing Directorate seeks to review all routing or routing-related drafts
> as
> they pass through IETF last call and IESG review, and sometimes on special
> request. The purpose of the review is to provide assistance to the Routing
> ADs. For more information about the Routing Directorate, please see
> ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>
> Although these comments are primarily for the use of the Routing ADs, it
> would be helpful if you could consider them along with any other IETF Last
> Call comments that you receive, and strive to resolve them through
> discussion
> or by updating the draft.
>
> Document: draft-draft-ietf-bfd-multipoint-16.txt
> Reviewer: Michael Richardson
> Review Date: 2018-05-12
> IETF LC End Date: unknown
> Intended Status: Standards Track
>
> Summary:
>
> This document is basically ready for publication, but has presentation nits
> that should be considered prior to publication.
>
> Comments:
>
> It seems like a well written document, with an intelligent and
> well-throught
> out way to extend BFD to multicast uses.
>
GIM>> Thank you for your kind consideration and approval of our work.

>
> I found the document a bit too abstract as it attempted to apply itself to
> any place that BFD is used.  I would like to perhaps better
> understand how it is used in some real multicast situations (MPLS,
> PIM/IP-level multicast).
>
GIM>> BFD for Multipoint networks, also referred to as p2mp BFD, may be
used in single-hop and multi-hop scenarios. Already there are two
individual drafts,  draft-mirsky-bfd-p2mp-vrrp-use-case   and
draft-mirsky-pim-bfd-p2mp-use-case,
that demonstrate use of p2mp BFD in single-hop scenario. Will note that the
section 4.8 of the draft does explain encapsulation of the multipoint BFD
control packet over MPLS LSP using IP/UDP.

>
> I believe that my lack of familiarity with some of those technologies might
> be keeping me in the dark.
>
> I'm not generally happy with documents that say:
>     "The following procedure replaces section 6.8.6 of [RFC5880]."
>
> because it's difficult to know what is going on without having the two
> documents next to eachother.  For an implementer, I'm not sure that there
> is any savings by doing this either, it seems to be solely for the
> convenience of those writing it.
>
GIM>> The text that follows the first sentence in section 4.13.1 is the
replacement of the entire section 6.8.6 of RFC 5880. Would stressing that
make the relationship more clear, e.g.:

The following procedure replaces the entire section 6.8.6 of [RFC5880].

And the same can be applied to the first sentence in section 14.3.3:

The following procedure replaces the entire section 6.8.7 of [RFC5880].


> I would prefer to have section 4.13 actually number the steps of the
> pseudo-code.
> As far as I can see, all of the pseudo-code of 5880 is being replaced, so
> this is not as much as a patch, so I don't see why not to number the
> pseudo-code.  (Like BASIC if you want, or with numbered lists)
>
GIM>> I'll try but perhaps RFC Editor may help us here.

>
> I did not evaluate the pseudo-code to determine if it made logical sense,
> it
> seemed well written and understandable.
>
> Major Issues:
>
> No major issues found.
>
> Minor Issues:
>
> No minor issues found.
>
> Nits:
>
> "the tail declares the path to having failed."          <- s/having/have/
>
GIM>> Accepted to the new working version of the draft.

>
>
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
>