Re: WGLC for BFD Multipoint documents (ending July 14, 2017)

Greg Mirsky <gregimirsky@gmail.com> Wed, 05 July 2017 18:10 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 7ED77131D80 for <rtg-bfd@ietfa.amsl.com>; Wed, 5 Jul 2017 11:10:40 -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 YzGnmFqdlEwQ for <rtg-bfd@ietfa.amsl.com>; Wed, 5 Jul 2017 11:10:38 -0700 (PDT)
Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (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 36F0C12EBF9 for <rtg-bfd@ietf.org>; Wed, 5 Jul 2017 11:10:38 -0700 (PDT)
Received: by mail-qk0-x22d.google.com with SMTP id d78so195966408qkb.1 for <rtg-bfd@ietf.org>; Wed, 05 Jul 2017 11:10:38 -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=RSiUPKUMx47nKTspdLBQc76HTZ1bGE23ykz5tjYHB4Y=; b=VlSVlcHg8qq96tP9uI3u0nx9Pv6KQVI9hRrTBAhY7FGuX1tr6xunCCd7+MSciKGfvj O7B6rXPANnsYKbJQyZlGhnC7gfgH6tlia90ex3tXAYo+gi41eD477FiGJvsON/FpdSQ8 VuJ8GcNHBN+otN0h9nNWEE9uiMavzO6fla/sNJ3maVJol9iCF5hiUbAeBE6+oRiSSAwv S+p76Lt1/cxA/mcRi/vz7V5Us9CuBpnoRBlFeJMI5gu/NFAQu5ojerF0XLMePv300RO1 Ixcft+62P/00ar37BFQSPYa4Pe54iNW6Kve5q3LBHz4d56n3gju+iF873wVPkHLzPHXx EOgg==
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=RSiUPKUMx47nKTspdLBQc76HTZ1bGE23ykz5tjYHB4Y=; b=i4jSNGcV+VeZPmBjEeETepZracLjBG+C+iR5bhof7CNDW1PYemMxbUVDqGMsfdxVSO de1X7Lv+5yJMtoRx6HvtaCPweYWKc+pcvIvffH8a2KH3rBWXCKFBcZS2cnaDmSj2o3ue 1DekkdK6WjBQQftNcFjox1grPO2loNNOIE/6xvMf7+Ebx5ijQQmDHGaFm9nH0MUZf53j c06tv0/HkCREBZidKgY4J1htQYAw1D+3hXPj7p2CQuYDd/eurqjE/2aUJsGDb13NP0zS 79ARtC7CXi49VrESqfhY290YkSLhVV3zdmqZUwGpNojCwJyRsltzuVUl9uuSuEWFWUPM pjhw==
X-Gm-Message-State: AKS2vOzW0tdw90EAtJndGhiQz9R1/7xv9/k5E/qh5zHgwg8TJQiWmTG5 lg2Vz9ezsex+QNcvaOtQiakYaejN2A==
X-Received: by 10.55.39.194 with SMTP id n185mr56680822qkn.139.1499278237085; Wed, 05 Jul 2017 11:10:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.22.227 with HTTP; Wed, 5 Jul 2017 11:10:36 -0700 (PDT)
In-Reply-To: <20170705162643.GS2289@pfrc.org>
References: <20170619193929.GE22146@pfrc.org> <CA+RyBmUfOe-1u7_MVwNt394B181XavLmTg4gA16v-4Mf1XWhGA@mail.gmail.com> <20170705162643.GS2289@pfrc.org>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Wed, 5 Jul 2017 11:10:36 -0700
Message-ID: <CA+RyBmWJdxepB3SyuBY+KU=-F=zMS62M6geUOa9x3s2sxHdp7g@mail.gmail.com>
Subject: Re: WGLC for BFD Multipoint documents (ending July 14, 2017)
To: Jeffrey Haas <jhaas@pfrc.org>
Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c092da0bdb3f9055395eac0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/hYFh2fcNROWTqu4WqiwVqJMrWmE>
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, 05 Jul 2017 18:10:40 -0000

Hi Jeff,
thank you for your kind consideration of my comments. Yes, after we agree
on how to address the comments, the document shall be advanced.

Regards,
Greg

On Wed, Jul 5, 2017 at 9:26 AM, Jeffrey Haas <jhaas@pfrc.org>; wrote:

> Greg,
>
> Thanks for your detailed feedback.
>
> A portion of your feedback seems to be mostly minor editorial changes.  A
> few of these items are discussion points that probably need to be resolved
> with some amount of WG discussion.
>
> What's your opinion about the ability to advance these documents once these
> issues have been addressed?
>
> -- Jeff
>
> On Mon, Jul 03, 2017 at 12:32:44PM -0700, Greg Mirsky wrote:
> > Dear Authors, WG chairs, et. al,
> > please kindly consider my comments to the latest version of the draft as
> > part of WGLC:
> >
> >    - Very general
> >       - I suggest to add note clarifying that all terms that include
> >       "connectivity" in the document are being used as alternative to
> >       "continuity", i.e. existence of a path between the sender and
> > the receiver,
> >       and should not be interpreted as "connectivity verification in
> terms of
> >       transport network".
> >    - Introduction
> >       - I find that characterization of BFD and unidirectional continuity
> >       verification as "natural fit" bit of stretching. Perhaps "capable
> of
> >       supporting this use case" is acceptable;
> >    - Goals
> >       - the last statement of non-goal seems little unclear. In fact, if
> >       there's only one tail, the BFD for multipoint network does verify
> >       connectivity, though unidirectional, between the head and the
> > tail. I think
> >       that the intention is to stress that p2p bi-directional
> connectivity
> >       verification is not supported by this document.
> >    - Section 4.7
> >       - the last paragraph notes that the discriminator value MUST NOT be
> >       changed. Since Your Discriminator MUST be set to 0 this refers to
> My
> >       Discriminator only. I think that explicit reference will make
> > the statement
> >       more clear. Thus suggest s/the discriminator values/the My
> Discriminator
> >       value/
> >    - Section 4.8
> >       - I believe that requiring use of IP/UDP encapsulation for BFD in
> >       multipoint networks over MPSL LSP is too restrictive. I suggest
> changing
> >       text as following:
> >
> > OLD:
> >
> > For multipoint LSP, MultipointTail MUST use destination UDP port
> > "3784" and IP "127.0.0.0/8" range.
> >
> >
> > NEW
> >
> > If IP/UDP encapsulation used by MultipointHead for multipoint LSP,
> > MultipointTail MUST use IP/UDP encapsulation of BFD destination UDP
> > port "3784" and IP "127.0.0.0/8" range.
> >
> > Use of other types of encapsulation for multipoint LSP is outside the
> > scope of this document.
> >
> >
> >    - Section 4.10
> >       - I cannot say what bfd.DetectMult packet is. It has not been
> > defined in RFC 5880, nor in this document. What is the scenario
> > described in the second paragraph? Is it when MultipointHead reduces
> > Desired Min TX  Interval thus making defect detection more aggressive?
> >    - Section 7
> >       - I think it should be plural in the first paragraph, i.e.
> > s/MultipointTail session/MultipointTail sessions/
> >       - I think that we can add another consideration to improve,
> > strengthen security of BFD for multipoint network by suggesting that
> > MultipointTail sessions created only for known combination of
> > MultipointHead and My Discriminator. Such information MAY be learned
> > from out-of-band and mechanisms are outside the scope of this
> > document.
> >
> >
> > Regards,
> >
> > Greg
> >
> >
> >
> > On Mon, Jun 19, 2017 at 12:39 PM, Jeffrey Haas <jhaas@pfrc.org>; wrote:
> >
> > > Working Group,
> > >
> > > https://tools.ietf.org/html/draft-ietf-bfd-multipoint-10
> > > https://tools.ietf.org/html/draft-ietf-bfd-multipoint-active-tail-04
> > >
> > >
> > > The BFD Multipoint documents have been stable for some time.  Prior
> > > discussion at meetings has suggested we have an implementation for the
> main
> > > protocol component.  Also per prior discussions, we split the
> active-tail
> > > component of the original multipoint document to permit implementors
> to not
> > > have to worry about implementing active-tail procedures if they weren't
> > > interested in that feature.
> > >
> > > We are starting an extended last call on these documents.  The WGLC
> will
> > > conclude on July 14.  This provides ample time for list discussion.  If
> > > necessary, the IETF-99 meeting may provide for opportunities to close
> any
> > > contentious technical points.  (BFD is not currently scheduled to
> meet.)
> > >
> > > One item I would like to kick off is the document status of the
> active-tail
> > > mechanism.  At this time, no one has implemented it that I am aware of.
> > > Discussion with our AD suggests that publishing the document with
> > > Experimental status may be reasonable to preserve the work that went
> into
> > > the proposal.
> > >
> > > -- Jeff
> > >
> > >
>