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

[Greg Mirsky <[e-mail]>]

Hi Jeff,
thank you for your detailed analysis of the mechanism proposed in the
draft. I've in-lined one question and one note under tag GIM>>.

Regards,
Greg

On Sat, Feb 16, 2019 at 8:33 AM Jeffrey Haas <[e-mail]> wrote:

> 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.
>
GIM>> My understanding of the legal side of IPR Disclosures is that the
last overwrites, including in regard to the licensing terms, previous
disclosures.

>
> 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.
>
GIM>> The behavior of the system in Demand mode is introduced as optional.
And that is precisely the update to RFC 5880.

>
> Am I missing something?
>
> -- Jeff
>
> >
> > Regards,
> > Greg
> >
> > On Mon, Dec 10, 2018 at 2:10 PM Jeffrey Haas <[e-mail]> 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
> > >
>