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

Greg Mirsky <gregimirsky@gmail.com> Wed, 18 April 2018 16:47 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 3D2A0126C2F; Wed, 18 Apr 2018 09:47:33 -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 x_WtiKfVn3f5; Wed, 18 Apr 2018 09:47:29 -0700 (PDT)
Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 39B821242F7; Wed, 18 Apr 2018 09:47:29 -0700 (PDT)
Received: by mail-lf0-x22c.google.com with SMTP id i18-v6so3632680lfc.7; Wed, 18 Apr 2018 09:47:29 -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=WiHE7TU6Q2bk87O60pU3SVDzUwBNQ8dht0rUoxRLFGo=; b=Ihd8aSo+sSu0a7etsnb+eBMo1aRziY2gTxxqyr7BKo/6TIR3IltENOgSCNP1yPVfF1 s1gAh18wpp/VEBt9PgyXBmQwEccbpQSzklQAaBOVlQC4wLXhEfdp1IoyiEUyxcu4IZTz mas8kDbUIunMxYJ5wPONH7eiV+/PpJ3ixGpOTcz2euV+eN5ooB0XnHNBNJHwjAwi/kqC 2WXI/pM6NaskmTTnnSRfI9Jpl4heX3nbZB/6aTJvp3O22+jGoC76l2FGSzlh2MnQA0V9 dNhFOAox4rOnFgJ/p0QVU2Y/HpyuCoZ7EEws1Vj/ezPKTRHwuZruEwwJCYkz4X1FzRCE p0zw==
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=WiHE7TU6Q2bk87O60pU3SVDzUwBNQ8dht0rUoxRLFGo=; b=iXYHGMAkaDKPQJtY591ehyM5x8OCJtklEG4QFkJk5ZKnCQjVwXw06eroeZ1EtUWxib 8fxw8JxuAmScAyYu4J2pYtQDjqajUirbase1nZCgonwPgCpM9tPZE65Z95G+KayTSYxx 7x5eqKHVgLRV+c7Ua56nYMpylwNgtxeZD5u/B7y68tZ1Ntp81Hqkog9mqh/J2wqg727i GDKACidgiLB8Mb3gKAGtzT1FaXAAti9eIoaK/ANowpf9iSZE+jH4ZXnf4mTtDrAMY9H1 9xREZuAvNbSmiP0ZmavRHIh0HjCk+57OQU6APfBxSBcTpmnISWkrkt11edDG0vaOC4qc 1VZw==
X-Gm-Message-State: ALQs6tBsSZgt6xaWnJ003Sx2yzW1rM+Bmz5EdB03WV3Q5GK0xTqBAmfU LAlJWKCPpOuhbjiaDbtL83UnjunfpKmZ8ko0OORUrYWyZwA=
X-Google-Smtp-Source: AIpwx4/gBU0A5n5vurvnBTuT495TziX5Ru2pniRZ5XjYXk+Yv3/zxCOskFuFUlPQsBH1c4qW0CkuO9t0qKH5AIrJ6Lw=
X-Received: by 2002:a19:1398:: with SMTP id 24-v6mr2117859lft.106.1524070046806; Wed, 18 Apr 2018 09:47:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.46.73.66 with HTTP; Wed, 18 Apr 2018 09:47:25 -0700 (PDT)
In-Reply-To: <bbaab4ef-6e0e-de41-f751-32f12db4672b@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> <CA+RyBmUKuV=YsLckqj8NBVXxtRw1i0VPxiy1zc4ucb+tGxtcrw@mail.gmail.com> <bbaab4ef-6e0e-de41-f751-32f12db4672b@nokia.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Wed, 18 Apr 2018 09:47:25 -0700
Message-ID: <CA+RyBmWhpXaPw5AAPkyTkm41u8O1ZgY4BD+S1-aOu1XTeYh3-A@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="000000000000c0be92056a22355f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/arH7n7a-fZ5r9Rlua8YtWv0Tn3o>
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: Wed, 18 Apr 2018 16:47:33 -0000

Hi Martin,
thank you for catching this empty reference. I've looked back and couldn't
find any text that describes the initialization of the state variable. The
new text simply states:

This variable MUST be initialized to the appropriate type when the session
is created.


Will upload the new version shortly.

Regards,
Greg


On Wed, Apr 18, 2018 at 6:22 AM, Martin Vigoureux <
martin.vigoureux@nokia.com> wrote:

> Greg,
>
> thanks. Sorry, but reading again the document I found:
>          This variable MUST be initialized to the appropriate type when
>          the session is created, according to the rules in Section 4.13
> I might have parsed 4.13 (and subsections) too quickly but I did not find
> any rule regarding the initalization of this variable. Is that indeed the
> case? If so then I would suggest to simply remove the pointer.
>
> -m
>
>
> Le 2018-04-17 à 22:20, Greg Mirsky a écrit :
>
>> 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.
>>>>
>>>>               ---
>>>>
>>>>
>>>>
>>>>
>>>
>>