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

Jeffrey Haas <jhaas@pfrc.org> Sat, 16 February 2019 16:33 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 951AF130F04 for <rtg-bfd@ietfa.amsl.com>; Sat, 16 Feb 2019 08:33:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 F__EW6QlIxdu for <rtg-bfd@ietfa.amsl.com>; Sat, 16 Feb 2019 08:33:00 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id A54BF130EFF for <rtg-bfd@ietf.org>; Sat, 16 Feb 2019 08:33:00 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 4A80F1E2D8; Sat, 16 Feb 2019 11:31:55 -0500 (EST)
Date: Sat, 16 Feb 2019 11:31:55 -0500
From: Jeffrey Haas <jhaas@pfrc.org>
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: rtg-bfd WG <rtg-bfd@ietf.org>
Subject: Re: WG Adoption request for draft-mirsky-bfd-mpls-demand
Message-ID: <20190216163154.GC28950@pfrc.org>
References: <20181017222431.GK17157@pfrc.org> <20181121222755.GC23096@pfrc.org> <CA+RyBmWeRoySs4a8he5ZGMz-_FDjzTeHMCd_4WksDSCqB5aEYw@mail.gmail.com> <20181210220953.GA6053@pfrc.org> <CA+RyBmW+pxqk6OmT4H1233XY-T7O06azGodUNu24Pu22aqhtMg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CA+RyBmW+pxqk6OmT4H1233XY-T7O06azGodUNu24Pu22aqhtMg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/b6LfMhQfjdvBEeGGWHQrxcw7OCs>
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: Sat, 16 Feb 2019 16:33:03 -0000

Greg,

On Wed, Feb 06, 2019 at 08:56:12AM -0800, Greg Mirsky wrote:
> Hi Jeff, Reshad, et al.,
> now I can confirm that the IPR licensing terms to this draft were updated
> by this IPR Disclosure <https://datatracker.ietf.org/ipr/3359/> submitted
> on December 11, 2018. Much appreciate your consideration and welcome
> technical comments on the draft.

Thanks for the update on the IPR declaration.  It's good to see that the
terms of the licensing have shifted such that open source implementations
would be able to be done.  I'll note that we're still in that limbo phase
wherein it's not possible for the Working Group, or holders of IPR against
the impacted RFCs 5880, 5883, and 5884, know what is being asserted that is
distinct vs. previously published IPR declarations.

And my apologies for not providing my technical comments more quickly.  The
last month and a half has been particularly challenging at the day job.
(Englightening, but challenging.)

draft-mirsky-bfd-mpls-demand seems to be an attempt to provide a profile
against which BFD, in a MPLS network, can use demand mode.  What I (and some
others) have found puzzling is why there's any perceived need for this
document.

Working through your document beginning in section 3:
- It is pointed out that demand mode exists.  Its procedures are documented
  as part of the core BFD RFC 5880.
- It points out in the case of MPLS as a transport that LSP Ping is
  necessary to bootstrap the BFD session.  These procedures are defined in
  RFC 5884.
- It points out that we can shift to demand mode.  Again, this procedure is
  documented in RFC 5880; see section 6.6.
- It points out that we can test liveness using a poll sequence.  Again,
  this procedure is documented in third paragaph of section 6.6 in RFC 5880.
- The procedures for declaring a session down when in demand mode and a poll
  sequence is in progress is covered in paragraph 6 of section 6.8.4 of RFC
  5880.
- The procedure for a down system reporting its state once per second is
  covered by paragraph 5 of section 6.8.3 of RFC 5880.  I don't believe I
  agree with your procedure that a system in demand mode must initiate a poll
  sequence to declare that it is down.

Am I missing something?

-- Jeff

> 
> Regards,
> Greg
> 
> On Mon, Dec 10, 2018 at 2:10 PM Jeffrey Haas <jhaas@pfrc.org> 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
> >