Now with corrected BFD WG list. On Mon, May 14, 2018 at 11:15 AM, Greg Mirsky <gregimir...@gmail.com> 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 <mcr+i...@sandelman.ca > > 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 <mcr+i...@sandelman.ca>, Sandelman Software Works >> -= IPv6 IoT consulting =- >> >> >> >> >
