Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

Greg Mirsky <> Thu, 13 December 2018 13:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DF674127133 for <>; Thu, 13 Dec 2018 05:53:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Status: No, score=-1.989 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_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 E-V-g92DozPG for <>; Thu, 13 Dec 2018 05:53:33 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 14A441252B7 for <>; Thu, 13 Dec 2018 05:53:33 -0800 (PST)
Received: by with SMTP id v5so1614629lfe.7 for <>; Thu, 13 Dec 2018 05:53:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FgCweWx2v6znNlMyfpP9U29HsMb36QJPb7EfbVcAIb8=; b=V61YOjcyFCGDiHdfg3aGEFoc0/3Rl2xQ8SadjhL8rx/FkhBAcZ7buEdgHBCrLZ/eDQ HhPyWnq/CRXw3Olix8agRZdUR9ALQNUhVleZLUAThp4D9TI6RBtO/7ytbvayJJ9j6buA jc4BsJwutiGfkvAdeJaVTeLDHivABdIBwbfsw0ajE6oaS78THq/MNMx1Cck+TcgrVsqH z0tjZArJOx/jzUZZPgcCzOcVks20eD7Cf/rKmBKqLz34sz91gRdY5ZESF2iOcoo0HLfO PLAheliK6STR8LAdqWRhL0aL8UoQYWk8jluOnSsrjWO8MjE7je9ngy3/qfXV5sfdiRbL syCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FgCweWx2v6znNlMyfpP9U29HsMb36QJPb7EfbVcAIb8=; b=rAop2KyFHm7twmutAwvZOrzkubthgTFwI/1+7tSzVlu7n/qNzTQ/Tjbk4EPbojCKH1 Y6WTnk8AsA/Wsv43NraJwrRbvlhHAMolg8m+fgksOse4di2dzSTDBtiOvSwMAc8nMySG QqQhTncXm8aoOvmJeyyq74S+RZSwIvcoQvXskeBgMMf2uClFcHycuzw9yBrItmanijnC sDkxCcI2RahlHc4jk1m5gof2AVSsHY3X9ymHploTk9iGpMV8L+6e5EDEN493qSblAqrn 4oGAbEl96TdOQVyWbdrwT2r6C4WPHJpNQjFxuqGTeVXwTgkOdzj2eYFb4/OFGQxMmeZI z+9Q==
X-Gm-Message-State: AA+aEWYLMJE0OJSQTfwO8mJzYyx/azjk3IVkUZYHhvvhWmcAlZKIOiz3 77tL0t+y0PpFuAwJZCzWQgRsnZ4jwx8w3Nhs6bU=
X-Google-Smtp-Source: AFSGD/XYSc2poIHfm8OZTbEG1DWoGK90zOFrButl+JIgo1lLXnQNiKQcCN6dt2AGGJ21rV7Rf8GCRCXmoPkjYKPCPnQ=
X-Received: by 2002:a19:26ce:: with SMTP id m197mr13758618lfm.23.1544709210978; Thu, 13 Dec 2018 05:53:30 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Greg Mirsky <>
Date: Thu, 13 Dec 2018 13:53:19 +0000
Message-ID: <>
Subject: Re: WG Adoption request for draft-mirsky-bfd-mpls-demand
To: Jeffrey Haas <>
Cc: rtg-bfd WG <>, Martin Vigoureux <>
Content-Type: multipart/alternative; boundary="000000000000cd3f98057ce7a3f4"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 13 Dec 2018 13:53:36 -0000

Hi Jeff, et al.,
I now would like to comment on the point of "not satisfactory convergence"
of discussion. I assume that this is related to the discussion started by
the message
to Xiao Min, not to the author of the draft. Oddly enough. But I've
responded nevertheless. Two questions were raised and both were explained:
- BFD Demand mode may be used to monitor the continuity of a path in one
direction and we have two specifications, draft-ietf-bfd-multipoint and
draft-ietf-bfd-multipoint-active-tail, that describe how that can be done
without and with notification to the ingress BFD node;
- indeed, it is the liveliness of the path between the BFD systems that are
These were the questions and, in my opinion, both got answered. And now I
got to wonder what other questions need to be addressed? Plans to
implement? In my experience, evaluating a draft in WG AP I, explicitly or
not, answer to these questions:

   - whether the document is coherent;
   - is it likely to be actually useful in operational networks;
   - is the document technically sound?

And I cannot find any unaddressed question that falls into any of these
Much appreciate comments from BFD WG Chairs.


On Tue, Dec 11, 2018 at 8:52 AM Greg Mirsky <> wrote:

> Hi Jeff, et al.,
> thank you for the update. I wanted to clarify the second item, the
> question related to the IPR Disclosure. The first disclosure used the
> "covenant not to assert" language. The second was to only update the filing
> status, not the licensing terms. I believe I've clarified that at the time
> of asking for WG AP. I was informed that there's the update to IPR
> Disclosure on this work submitted that restores the "covenant not to
> assert" language. I hope that can be taken into consideration by you and
> Reshad.
> Regards,
> Greg
> On Mon, Dec 10, 2018 at 10:10 PM Jeffrey Haas <> wrote:
>> Greg,
>> Apologies for the long delay in reply.
>> On Wed, Nov 21, 2018 at 02:40:50PM -0800, Greg Mirsky wrote:
>> > I respectfully ask to summarize the comments that were shared with you
>> and
>> > to publish them to the WG without naming the authors.
>> Tersely:
>> - The document is not addressing fundamental issues.
>> - It is encumbered by IPR.
>> - Observed list traffic regarding question on the feature was not
>>   satisfactorily converging.
>> > And I have to admit that I don't understand your suggestion to use the
>> > Errata. The procedures to apply the Demand mode described in the draft
>> are
>> > not in contradiction with RFC 5880, so the suggestion to use Errata
>> > surprised me.
>> I will respond on my own analysis in detail hopefully this week.  I am
>> awaiting the resolution of a particular bit of correspondence before
>> determining the tenor of my response.
>> -- Jeff