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

Jeffrey Haas <jhaas@pfrc.org> Mon, 25 February 2019 03:24 UTC

Return-Path: <jhaas@slice.pfrc.org>
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 CAD02130EC6 for <rtg-bfd@ietfa.amsl.com>; Sun, 24 Feb 2019 19:24:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 xf1TmO_lqDby for <rtg-bfd@ietfa.amsl.com>; Sun, 24 Feb 2019 19:24:14 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 68B0712D4ED for <rtg-bfd@ietf.org>; Sun, 24 Feb 2019 19:24:14 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id DF13A1E2D8; Sun, 24 Feb 2019 22:23:17 -0500 (EST)
Date: Sun, 24 Feb 2019 22:23:17 -0500
From: Jeffrey Haas <jhaas@pfrc.org>
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: "Reshad Rahman (rrahman)" <rrahman@cisco.com>, Martin Vigoureux <martin.vigoureux@nokia.com>, rtg-bfd WG <rtg-bfd@ietf.org>
Subject: Re: WG Adoption request for draft-mirsky-bfd-mpls-demand
Message-ID: <20190225032316.GA28974@pfrc.org>
References: <20190218162350.GH28950@pfrc.org> <CA+RyBmUs-C6JC=O-k-hyRtNeJ-CTR++syEs6vteGDmcAotTw6g@mail.gmail.com> <20190218173351.GI28950@pfrc.org> <CA+RyBmXN=0FYoHWt4TzPg05_ZoC9RbsOSvoFAte9doDY8_JDgg@mail.gmail.com> <542FBF1D-4D61-4E45-8CD2-CE9EC8BF6A38@cisco.com> <CA+RyBmVtLXSZfADQ9YgBEWj+d_X=zXh6SwSfqrUSNWiVNTwNXA@mail.gmail.com> <20190219174109.GN28950@pfrc.org> <CA+RyBmXresOc+i75O7=u5COG3q70s_fX4rK0mQw5LLdak6dxug@mail.gmail.com> <20190220044330.GA14326@pfrc.org> <CA+RyBmWhd7SDArpcrXABnm2GXGd2f3+jWOG2x2+Dgi_VNcWm0g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CA+RyBmWhd7SDArpcrXABnm2GXGd2f3+jWOG2x2+Dgi_VNcWm0g@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/ZITdGqyL1dYbRRVHu19mxA7ZUgY>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 25 Feb 2019 03:24:16 -0000

Greg,

On Sun, Feb 24, 2019 at 09:53:20AM -0800, Greg Mirsky wrote:
> Hi Jeff,
> I'm glad that you feel that our discussion is helpful. I want to point that
> the use of the Poll sequence to communicate to the remote BFD system in the
> Concatenated Paths section is to relay the failure detected in the
> downstream segment of the multi-segment OAM domain. Also, section 6.8.17
> does not specify how the upstream BFD system responds to the situation:
>    Note that if the BFD session subsequently fails, the diagnostic code will
>    be overwritten with a code detailing the cause of the failure.  It is
>    up to the interworking agent to perform the above procedure again,
>    once the BFD session reaches Up state, if the propagation of the
>    concatenated path failure is to resume.

Correct.  That is up to the upstream to determine its behavior.

> And so far we were discussing RFC 5880 though the scope of the draft is on
> the use of Demand mode over MPLS LSP.

MPLS does not magically change the behavior of demand mode specified in the
core RFC.

> And the draft does describe how the
> BFD system acts after it receives the control message with Diag field set
> to Control Detection Time Expired, a.k.a. RDI, and the Poll flag set. In
> that, I consider, the draft is complimentary to RFC 5884 whose scope is on
> the Asynchronous mode only.

I continue to have problems understanding how the text in your draft is
intended to be different than 6.8.4 of RFC 5880.  Simply saying "we're
allowed to use demand mode" can't be it?

It will help clear this conversation if you simply state your changes in
behavior vs. 5880 and 5884. 

> I believe that the draft addresses practical scenario with the technical
> and innovative solution. And it was recognized as such by several WG
> participants during the WG AP. Much appreciate your consideration.

A reminder that we don't vote.  C.f. RFC 7282, section 6.

-- Jeff