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

Greg Mirsky <gregimirsky@gmail.com> Mon, 14 May 2018 18:33 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE284127601; Mon, 14 May 2018 11:33:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emuk1sGxt9Fu; Mon, 14 May 2018 11:33:27 -0700 (PDT)
Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3210C1273E2; Mon, 14 May 2018 11:33:27 -0700 (PDT)
Received: by mail-lf0-x235.google.com with SMTP id j193-v6so19501535lfg.6; Mon, 14 May 2018 11:33:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uviZrwLu3Ptscfw5Sk6VuojajoZNeR3wkZPcDgIJ3jA=; b=cOPShZij0H/6kLVFpXQo+J4MFBM220jO4hUvbf4DaoetnrW046aAAeDAHI4g48Xe/X sLnUXbiyFt456hPUr7MeUzFkOei+WRngtNdsexmnx9nqkSbl7VXmfUq2EdoTEwIJYleS /2Sd7ym7WrKOrDGd0tX9ox73WClG3biKFwkzphxOfuLCBRmTCYJF/wdFK7/jc1616tS4 V99vEzfdZmVtfJgs0heirmVDqjADlafNcjzl5bUqDXDR8+Kt9Riy3Fbi47oiLMJ+uQlx Gt3dkP0OWaOTkyFdkR6beag6fwbiJ4Wp8kntB+YDYPa2d2FWgNpeoPYZWITjlJzfNbx0 Gi0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uviZrwLu3Ptscfw5Sk6VuojajoZNeR3wkZPcDgIJ3jA=; b=DRfJPzKBL+trH68HaQwDoYq/2g1K4N7+nTLP9UJjvRzMVGv31zRPUg8L6ZfrHRMwoz L5dZdTsl74ByH/BT7IouN7z5BUITUQcRBKaDhX5JJmHhRLaQPEXlvD5CjUExYjPC3NYf MP68acPjsR6k6D2VaIfxGX/29PP8kAKyoNhUxOTWclDPMdSgBRV8K785YU9Hqw+1tlST ywJfuCosKyDKvaclQIwjsoDUrURJnt5mxwVwtRj631eAz46R43uEFsIWsLPx6YZZF2j4 H7jT4ySKaK70YXaftVxMF7g71YGqyE5P5j+NAX1Sk/aAxzCHGHzltT/vEfLe75h04A9b azLQ==
X-Gm-Message-State: ALKqPwfS6w94aw9rDpk279byWSvx8DkGS0pSE/vpDH51HAWr+fSu315M nmokjAAe83VzFh5dEYOBp2hExhYT8uJCFdErscA=
X-Google-Smtp-Source: AB8JxZp3t3+MT8iVzctiq9M4PFQKjn6P4T61v0RbAQPPsGDkRghCKQjTIVVAf3H78+X1ITz3SNXWdvBdI+qNf/XnLLs=
X-Received: by 2002:a2e:98c5:: with SMTP id s5-v6mr5224551ljj.19.1526322805419; Mon, 14 May 2018 11:33:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.46.133.13 with HTTP; Mon, 14 May 2018 11:33:24 -0700 (PDT)
In-Reply-To: <CA+RyBmWKAfqvpRzrrBmpcJsebqmA+OXB_URfuizFh+k9UK_GgA@mail.gmail.com>
References: <9C5FD3EFA72E1740A3D41BADDE0B461FCF003008@dggema521-mbs.china.huawei.com> <28935.1526166269@localhost> <CA+RyBmWKAfqvpRzrrBmpcJsebqmA+OXB_URfuizFh+k9UK_GgA@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Mon, 14 May 2018 11:33:24 -0700
Message-ID: <CA+RyBmUmGMQwa8g7XajmvYtc_d-8Q877yjQewm5JPRmz1S8OvA@mail.gmail.com>
Subject: Re: RtgDir review: draft-ietf-bfd-multipoint-16
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: "<rtg-ads@ietf.org>" <rtg-ads@ietf.org>, rtg-dir@ietf.org, draft-ietf-bfd-multipoint.all@ietf.org, rtg-bfd@ietf.org
Content-Type: multipart/alternative; boundary="000000000000a1363b056c2eb8f0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/oYkYSpeTSisPKEM9N5lXk66Iq5k>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 May 2018 18:33:31 -0000

Now with corrected BFD WG list.

On Mon, May 14, 2018 at 11:15 AM, Greg Mirsky <gregimirsky@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+ietf@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+IETF@sandelman.ca>, Sandelman Software Works
>>  -= IPv6 IoT consulting =-
>>
>>
>>
>>
>