Subject: Re: RtgDir review: draft-ietf-bfd-multipoint-16

From: Greg Mirsky <[email-masked]>
Date: Mon, 14 May 2018 11:33:24 -0700

Now with corrected BFD WG list.

On Mon, May 14, 2018 at 11:15 AM, Greg Mirsky <[email-masked]> wrote:

> 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 <[email-masked]
> > 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 <[email-masked]>, Sandelman Software Works
>>  -= IPv6 IoT consulting =-
>>
>>
>>
>>
>

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 14 May 2018 16:09:38 -0700

Hi Michael,
thank you for the most expedient response. Both updates are in the new
working version.

Regards,
Greg

On Mon, May 14, 2018 at 3:58 PM, Michael Richardson <[email-masked]>
wrote:

>
> Greg Mirsky <[email-masked]> wrote:
>     > The text that follows the first sentence in section 4.13.1 is the
>     txt> The following procedure replaces the entire section 6.8.6 of
> [RFC5880].
>
>     txt> The following procedure replaces the entire section 6.8.7 of
> [RFC5880].
>
> That seems like good text.
>
> --
> ]               Never tell me the odds!                 | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works        | network
> architect  [
> ]     [email-masked]  http://www.sandelman.ca/        |   ruby on
> rails    [
>
>

---

From: Martin Vigoureux <[email-masked]>
Date: Fri, 18 May 2018 14:35:37 +0200

Greg,

looking back in the doc I found:
       Poll (P)

          Set to 1 if the local system is sending a Poll Sequence or is a
          session of type MultipointHead soliciting the identities of the
          tails, or 0 if not.

This looks to me as not being in line with the rest of the document, 
especially the part on "MultipointHead soliciting the identities of the 
tails".
Am I right in thinking that this anticipates on 
draft-ietf-bfd-multipoint-active-tail ?

If so, please clarify this in the doc; if not, please correct me.

Thanks
-m

Le 2018-05-15 à 1:09, Greg Mirsky a écrit :
> On Mon, May 14, 2018 at 3:58 PM, Michael Richardson 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>     Greg Mirsky <[email-masked] <mailto:[email-masked]>>
>     wrote:
>          > 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.:
> 
>          txt> 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:
> 
>          txt> The following procedure replaces the entire section 6.8.7
>     of [RFC5880].
> 
>     ] [email-masked] <mailto:[email-masked]>
>     http://www.sandelman.ca/        |   ruby on rails    [
> 
>

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 24 May 2018 19:56:34 -0700

Hi Martin,
apologies for the delay. Yes, this text left after active-tails document
was spawned. Would the following be acceptable:
      Poll (P)

         Set to 1 if the local system is sending a Poll Sequence, or 0 if
not.

Regards,
Greg

On Fri, May 18, 2018 at 5:35 AM, Martin Vigoureux <
[email-masked]> wrote:

>> On Mon, May 14, 2018 at 3:58 PM, Michael Richardson <
>> [email-masked] <mailto:[email-masked]>> wrote:
>>
>>
>>     --     ]               Never tell me the odds!                 | ipv6
>> mesh
>>     networks [

---

From: Martin Vigoureux <[email-masked]>
Date: Fri, 25 May 2018 09:58:06 +0200

good. thx.

Le 2018-05-25 à 4:56, Greg Mirsky a écrit :
>           Set to 1 if the local system is sending a Poll Sequence, or 0 
> if not.
> 
> Regards,
> Greg
> 
> On Fri, May 18, 2018 at 5:35 AM, Martin Vigoureux 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Greg,
> 
>     especially the part on "MultipointHead soliciting the identities of
>     the tails".
>         thank you for the most expedient response. Both updates are in
>         the new working version.
> 
>         Regards,
>         Greg
> 
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>
>         wrote:
> 
> 
>              Greg Mirsky <[email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>>
>              wrote:
>              --     ]               Never tell me the odds!             
>             | ipv6 mesh
>              networks [
>         <mailto:[email-masked] <mailto:[email-masked]>>