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 <jh...@pfrc.org> 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 <jh...@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 > > > >
