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

Greg Mirsky <> Mon, 03 July 2017 19:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 71E8212ECC1 for <>; Mon, 3 Jul 2017 12:32:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.698
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OepT2mYldTcp for <>; Mon, 3 Jul 2017 12:32:48 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 68B88131741 for <>; Mon, 3 Jul 2017 12:32:46 -0700 (PDT)
Received: by with SMTP id v143so69336244qkb.0 for <>; Mon, 03 Jul 2017 12:32:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lfP0MGgKracVu75ZqXDHR6nxGkJpDVE0K4CIGf3KWk4=; b=f/d8XCjeGmPlJVuZxrImuFqIS8IxJ4yfbo63h70J8xfaCOv6lxi8cXKd3z8Vcw9xDN T0Ia5wqcnkiKhK7F8TtWujYXJl1+n8Q9T1Q/VNqMDOcq0dpMXEHrCqOYDntvduXkKiLL 6/8jt4Rz7Zd8/GKPxGwSJpDJnstQL/1HV4q0je3aAk5zAYi4vHtWdVOw0sCm5ZQ99wLa QJASn/lE5mIndfqonwQ/Mvm2TpL84BUpmgImRD77aA5T/sxsokRrUjNj45sAF6yDuKv7 NwyDZmWK20bdW5wxcjegm8kauAVOAts0YjOTtMZ6cUPEEaspO2Fzo7iYvRLE/KzeXQxt BJwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lfP0MGgKracVu75ZqXDHR6nxGkJpDVE0K4CIGf3KWk4=; b=r7FX3i3DWf/A6Wc6ysvWdpQhJCE43cjep0Opalcptxbaaqq2RleQVDXGU883PNjzrR wQXkmYTBG5LJKWThTGdsBx8Ilh0s1xHsLD9zUq+36AP8u7Iw+ePF+H6eTb+UfWLiELtt Vn0Fje+Jf+M6sxAJb7SE894cEIP8x8wRzIR1ynjRIuE/uPe81GeiQaKDiqgCXkEtX0jB JemJQc4is2/rFRu9owKr5XYpkUpsut2jRexgat8mxHoJI7BM/n+I2yxHD0ZPpvA/lwpW H+iREqlnXHVchpSDPNxINo6Nhld1zqSI83RqypPD0wBOWnlqEgs3aVe46CXhoZ6XS5O1 KtJw==
X-Gm-Message-State: AKS2vOwxHDLadB5y8tAsdW1H2vPOjoMzuyAwxqone82eo4CKpTqKSDvo UbMyOmTFOOMsm2dTCzlc3SrQr+RabWj+
X-Received: by with SMTP id n185mr44755653qkn.139.1499110365440; Mon, 03 Jul 2017 12:32:45 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 3 Jul 2017 12:32:44 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Greg Mirsky <>
Date: Mon, 3 Jul 2017 12:32:44 -0700
Message-ID: <>
Subject: Re: WGLC for BFD Multipoint documents (ending July 14, 2017)
To: Jeffrey Haas <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="94eb2c092da0cfad9305536ed46a"
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 03 Jul 2017 19:32:50 -0000

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
   - 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:


For multipoint LSP, MultipointTail MUST use destination UDP port
"3784" and IP "" range.


If IP/UDP encapsulation used by MultipointHead for multipoint LSP,
MultipointTail MUST use IP/UDP encapsulation of BFD destination UDP
port "3784" and IP "" 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



On Mon, Jun 19, 2017 at 12:39 PM, Jeffrey Haas <> wrote:

> Working Group,
> 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