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

Greg Mirsky <gregimirsky@gmail.com> Tue, 17 April 2018 20:20 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 36FFB126D05; Tue, 17 Apr 2018 13:20:58 -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, 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 7lozvqq8CE4z; Tue, 17 Apr 2018 13:20:55 -0700 (PDT)
Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (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 2D4B4126CD6; Tue, 17 Apr 2018 13:20:55 -0700 (PDT)
Received: by mail-lf0-x22a.google.com with SMTP id d79-v6so3453523lfd.0; Tue, 17 Apr 2018 13:20: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:content-transfer-encoding; bh=J7Zx+LnvyHHHktBEgY9DErpsRMvaF3rtlvwglMyUWow=; b=laVPrJjkMgFrTzfECzicIjC/vOscO6M1Afssmz1At1wjN4DojU2L89nBtz109vtghN M6crS/R5NA317V9kRiKElAQsG3FsQjZHSU+U0DGG19QDxyqMLMVvRU6jyZ86q/LIPOxD appYg+/ztfBLmpinUvPLlCPiZYeMYFXXnUSdyF4kxRXQqorOC9vC0NQyEV63E4OkiuZJ oCKpqGDsacW8YfldPzSajlx8obQ/8QZhYqjCNvyQsLMkDxQJnoZ+yHFC1qUylPA4WzkE 1Shi4JpkMUpfaPay3GzAHWci/8Nk2eqLyTqmRclNj7xZIxqLEjVhS174lhoNHPNF80l5 dUSg==
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:content-transfer-encoding; bh=J7Zx+LnvyHHHktBEgY9DErpsRMvaF3rtlvwglMyUWow=; b=tgzYZJhI/65NydYYg9v2kIozQnhWSJrsJWEiOW1hF9ZHWmB6iuRTLuxTtrX91FQRPI 5ma44IGVQ1ybKBxvU/Q9WuDbuD8DDMOvhpTKcf4mTtUBuYP5gz1Q/y/Rsfe4JO7auYgy 3WOeWtLLuB93zB9l2hRSN15l/pUz67vRE9xsG50RdG9XI4/1JEIqeAZrN78itlALMhyi H7mceFNhyInrZNPx3c8lmzLerKnr9LYv1WdKb1ydmfWqm2ZwxNQr1Ic1IdP0F86hSV9U iKXrDSd9o+B1L7bikJaCsvG4KBkmJ2r/c4I1N9iJiiYcpQ29fhpSHP44CnY+j4pWk/Dr TFwQ==
X-Gm-Message-State: ALQs6tCwgn6Aa7G8gJ6uNhG22r7rAV0uG8AsNCJAUZPAr7H/kNxbs4BY /z69WTyxYLDNB6vmMfqkQJ6hXl7mBmViyU+MaiU=
X-Google-Smtp-Source: AIpwx49GXOD8TQIR4+kd4tplYmyHGXcdzfO+1WPZE8AtlIL8hp5JvRCHnXEdSuh9fcmjgjW/bFR1yWu145FKnqKpvB4=
X-Received: by 2002:a19:5513:: with SMTP id n19-v6mr2597863lfe.100.1523996453045; Tue, 17 Apr 2018 13:20:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.46.73.66 with HTTP; Tue, 17 Apr 2018 13:20:52 -0700 (PDT)
In-Reply-To: <ab28a63b-3da5-fc3d-a48a-44640bce385d@nokia.com>
References: <ef98cd8b-2e3a-40bc-42e9-82cb64d1f87d@nokia.com> <CA+RyBmUKiawoqi2G6Kz8wPYSeYG1L0hUk8zmDVK+kSCZaA_3Yw@mail.gmail.com> <b160454c-5fec-4c57-2c37-20ccf3b8dceb@nokia.com> <CA+RyBmXkVuo=yb1ivdf2-MPfPw-UAYHfP83d0RnZnxn-jkQN2A@mail.gmail.com> <ab28a63b-3da5-fc3d-a48a-44640bce385d@nokia.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Tue, 17 Apr 2018 13:20:52 -0700
Message-ID: <CA+RyBmUKuV=YsLckqj8NBVXxtRw1i0VPxiy1zc4ucb+tGxtcrw@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: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/c2VG9ghWkuusblw8fY1Ch9MzmYc>
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 20:20:58 -0000

Hi Martin,
I've added references to 4.7 and 4.13.2. The new version -15 has been published.
Thank you for your help and support.

Regards,
Greg

On Tue, Apr 17, 2018 at 12:31 PM, Martin Vigoureux
<martin.vigoureux@nokia.com> wrote:
> Greg,
>
> I'm fine your proposal below.
> Please post the final update whenever you can.
> Thx
>
> -m
>
>
> Le 2018-04-17 à 20:40, Greg Mirsky a écrit :
>>
>> Hi Martin,
>> I have not ignored that comment but missed to ack its acceptance. Two
>> other outstanding questions:
>>
>>   * the text, that I've misinterpreted earlier, is in the Overview
>> section:
>>
>>                  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?
>>
>>     I don't read this part of the document as talking about mp2mp but
>>     rather as talking about multiple p2mp trees.
>>
>>     Sections 4.7 and 4.13.2 provides details on demultiplexing BFD
>>     control packets at a MultipointTail. Would the reference to these
>>     sections be sufficient?
>>   * yes, moved the reference to Point-to-Point session to section 4.4.1
>>
>> Attached please find the diff between -14 and the working version of the
>> draft. Please let me know if the changes address your comments. Will upload
>> the new version promptly.
>>
>> Regards,
>> Greg
>>
>> On Tue, Apr 17, 2018 at 9:49 AM, Martin Vigoureux
>> <martin.vigoureux@nokia.com <mailto:martin.vigoureux@nokia.com>> wrote:
>>
>>     Greg,
>>
>>     thanks. please see in-line.
>>
>>     once I see the update published I will request IETF LC.
>>
>>     -m
>>
>>     Le 2018-04-17 à 18:34, Greg Mirsky a écrit :
>>
>>         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 <mailto:martin.vigoureux@nokia.com>
>>         <mailto:martin.vigoureux@nokia.com
>>
>>         <mailto: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
>>
>> <https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-bfd-multipoint-14.txt>
>>
>> <https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-bfd-multipoint-14.txt
>>
>> <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
>>         <https://www.rfc-editor.org/errata_search.php?rfc=7880>>.
>>
>>     I am not sure how this document relates to or addresses the errata.
>>     So I still think it does not update 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
>>
>>     thx
>>
>>
>>              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?
>>
>>     I don't read this part of the document as talking about mp2mp but
>>     rather as talking about multiple p2mp trees.
>>
>>
>>
>>
>>                  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.
>>
>>     Well, I would move the text to 4.4.1 then, but not critical.
>>
>>
>>
>>
>>                  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.
>>
>>     You chose to ignore that one or simply missed it?
>>
>>
>>
>>                  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.
>>
>>     Yes, i'd live with that. But then you might also want to clarify in
>>     4.4.2. <http://4.4.2.>:
>>     OLD:
>>               This variable MUST be set to 0 for session type
>>     MultipointHead.
>>     NEW:
>>               This variable MUST be initialized to 0 for session type
>>               MultipointHead.
>>
>>
>>
>>
>>
>>
>>              s/M, P bit/M and P bits/
>>
>>         GIM>> Thanks, done.
>>
>>              ---
>>
>>
>>
>