Re: AD review of draft-ietf-bfd-multipoint-14

Greg Mirsky <gregimirsky@gmail.com> Tue, 17 April 2018 16:34 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 4DB1F1200F1; Tue, 17 Apr 2018 09:34:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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, URIBL_BLOCKED=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 W7nGrDZ8uGTr; Tue, 17 Apr 2018 09:34:56 -0700 (PDT)
Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (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 E0F26127599; Tue, 17 Apr 2018 09:34:55 -0700 (PDT)
Received: by mail-lf0-x22f.google.com with SMTP id v207-v6so28256919lfa.10; Tue, 17 Apr 2018 09:34:55 -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=bjNauIQHPc1C2c3okMn2r8ug82EqFXU9v3qQ01HkKFY=; b=HLb/76wM3WKp413Gz5Nw8EzLOt0Aw4p+V2JInQ+9e7QYywPvAEHe5tFQAE6mAYv60v L17yOfjB8uKoYNQgVdYRkIHrFZWiaDxFI1niFBCdznwzTU8fxKBoZNwZgatKCCHAQ/eN /Et60Q6qFg54iVGsPqIJcTjWOSGFkMfHPRO8wY88xbZWb/DWlSJVghYLvihu8YT35OEu osWx51DFoE9pKDrdZPStDuZ59p6qZpTiiEfMeEmoeLNVbbOBTvq1Y/7wxDXId+46rdZk kQyQoq5BzrD0vVGGAxJ/pGt1T4hp/5VPAMrwM2MX9nc+Cmb90v8EvbeiFoGJ+1iGxcmz haXA==
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=bjNauIQHPc1C2c3okMn2r8ug82EqFXU9v3qQ01HkKFY=; b=ZoAOHtWKXXVp74/sp0mbYlccMY2/n8p0Pdsbco/6seFFd0CWolcNwrjOtBndeJwsZL mPN/TfJ5W+63bfLvdaz8qLu0cBRa19BfW3LW8bFeh9Ba7J5/sloYlAMcu7D0tlez72lj AAAy7ybdoVyn+z8FchoFZ6GIfUBjC4xOCuIAZQI2LHXtq5Qla3wjKqy+FM8yVga7r1RL T5F+4f+sjLrynQpCYlv0bwRqz9NaAVjWBE5/qiTl06ofwhdhM+Cg0ZMmpDnR0UXidwqk UpZxrTnn8fhV8RQplH3TuCVTYPNd+Or7atd2wJF2gPeHAvGpGRVdXVQoAXUmxF2ojmTC A+WA==
X-Gm-Message-State: ALQs6tCkB3wR61FGwzQAHBP+AQTP/wGYQK+LuM9dz+Xba834luz04SYb KxwJ7JnXiqf2QiFADucQOW+Fi1vAedGFO2WLHk0=
X-Google-Smtp-Source: AIpwx4/NNHS74EpWBCyL56fssk3cwDFcUEOTFjUJsTlPjNaXnz6/qVOujL+2w5PacBNDFnEFZzyZwVtB5j7q+436LEU=
X-Received: by 10.46.131.197 with SMTP id s5mr1961088ljh.72.1523982893811; Tue, 17 Apr 2018 09:34:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.46.73.66 with HTTP; Tue, 17 Apr 2018 09:34:53 -0700 (PDT)
In-Reply-To: <ef98cd8b-2e3a-40bc-42e9-82cb64d1f87d@nokia.com>
References: <ef98cd8b-2e3a-40bc-42e9-82cb64d1f87d@nokia.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Tue, 17 Apr 2018 09:34:53 -0700
Message-ID: <CA+RyBmUKiawoqi2G6Kz8wPYSeYG1L0hUk8zmDVK+kSCZaA_3Yw@mail.gmail.com>
Subject: Re: AD review of draft-ietf-bfd-multipoint-14
To: Martin Vigoureux <martin.vigoureux@nokia.com>
Cc: draft-ietf-bfd-multipoint@ietf.org, "Reshad Rahman (rrahman)" <rrahman@cisco.com>, bfd-chairs@ietf.org, rtg-bfd@ietf.org
Content-Type: multipart/alternative; boundary="f4f5e80c39dc078da7056a0deb9d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/u2uWYjD3QFwX7_krVoz4upY6ebk>
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: Tue, 17 Apr 2018 16:34:59 -0000

Hi Martin,
thank you for your thorough review, thoughtful comments and kind words.
Please find my answers to your questions in-line and tagged GIM>>.

Regards,
Greg

On Tue, Apr 17, 2018 at 8:06 AM, Martin Vigoureux <
martin.vigoureux@nokia.com> wrote:

> [resend, wrong bfd wg address in first attempt ...]
>
> Authors, WG,
>
> thank you for this document. It is clear and well written.
> I didn't find any technical comment to make so I've been nit picking :-)
> Please find those comments below.
>
> regards,
> martin
>
> ---
> Please check and address the nits:
> https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/
> draft-ietf-bfd-multipoint-14.txt
>
> On that aspect, does this document really update 7880 as the header says?
> The Introduction only refers to 5880 and it is not clear in the body of the
> Document what effectively impacts 7880. The only thing I saw is the
> addition of new session types but that does not require an update in my
> opinion. Could you clarify?
> GIM>> Yes, you'correct, the only connection to RFC 7880 are the new values
> of bfd.sessionType. The proposal to list RFC 7880 as updated by this
> specification was inteded to address Errata to RFC 7880
> <https://www.rfc-editor.org/errata_search.php?rfc=7880>.
>
>    i.e. existence of a path between the sender and the receiver.
> do you mean "forwarding path"?
> GIM>> Yes. Updated to
>
i.e. existence of a forwarding path between the sender and the receiver


> Section 2. and Section 3. seem a bit redundant. They both state the same
> thing but from a different angle. Not critical.
>
>
>    Although this document describes a single head and a set of tails
>    spanned by a single multipoint path, the protocol is capable of
>    supporting (and discriminating between) more than one multipoint path
>    at both heads and tails.
> There is no text to describe how one could achieve that. Wouldn't it be
> worth adding some?
>
GIM>> The question of applicability of this specification to mp2mp scenario
came up at BIER WG meeting in London. Perhaps we can say the these
questions are ouside the scope of this document and discuss whether there
are interested to work on mp2mp case as a separete document?

>
>
>    Point-to-point sessions, as described in [RFC5880], are of type
>    PointToPoint.
> Does this really fit in Section 4.2 which looks to be about the mpBFD
> session model.
>
GIM>> I think that this short reminder is helpful to explain why this
document adds value PointToPoint, section 4.4.1, to the defined in RFC 7880
bfd.sessionType variable.

>
>
>    Sessions of type MultipointHead MUST NOT send BFD control packets
>    with the State field being set to INIT, and MUST be ignored on
>    receipt.
> English is not my native language but I wonder if this really says what
> you want. It seems that "Sessions" is the subject of "MUST be ignored"
> while I think it's the packets which are the intended subject. So I'd write:
>    and those packets MUST be ignored on receipt.
>
>
>    Because there is no three-way handshake in Multipoint BFD, a newly
>    started head (that does not have any previous state information
>    available) SHOULD start with bfd.SessionState set to Down and with
>    bfd.RequiredMinRxInterval set to zero in the MultipointHead session.
>
>    To shut down a multipoint session a head MUST administratively set
>    bfd.SessionState in the MultipointHead session to either Down or
>    AdminDown and SHOULD set bfd.RequiredMinRxInterval to zero.  The
> In both these paragraphs one could read that the head "SHOULD set
> bfd.RequiredMinRxInterval to zero" while 4.4.2 says MUST. Clarification
> needed?
>
GIM>> Section 4.4.2 mandates initialization of  bfd.RequiredMinRxInterval and,
I think, applies to the first paragraph you've pointed. Would the following
be clear and consistent:
     Because there is no three-way handshake in Multipoint BFD, a newly
   started head (that does not have any previous state information
   available) SHOULD start with bfd.SessionState set to Down and
   bfd.RequiredMinRxInterval *MUST be* set to zero in the MultipointHead
session.
The second paragraph describes manipulation with the value of
bfd.RequiredMinRxInterval
which process, as noted in section 4.10, "is outside the scope of this
document". That may be reason to use SHOULD and not MUST.



> s/M, P bit/M and P bits/
>
GIM>> Thanks, done.

> ---
>