Hi Reshad, thank you for your question. As I've noted, this draft has no relation to RFC 5883 BFD for Multi-hop paths. Also, it is not to update RFC 5884 BFD for MPLS LSPs as the latter describes only the use of BFD in Asynchronous mode. The draft describes procedures to use the Demand mode of BFD, which is beneficial in monitoring unidirectional MPLS paths, e.g. LSP or SR-MPLS tunnel. The draft proposes to update RFC 5880 in regard to the behavior of BFD system in Demand mode so that such system MAY start Poll sequence to inform the remote BFD system of the change in BFD session state, i.e. signal RDI.
Regards, Greg On Sat, Feb 16, 2019 at 2:20 PM Reshad Rahman (rrahman) <rrah...@cisco.com> wrote: > Hi Greg, > > I still don't understand what's the intended purpose of the draft. Does it > change/update any procedures in 5880/5883 and if so could you please > clarify why and how? > > Regards, > Reshad. > > > On 2019-02-16, 1:46 PM, "Rtg-bfd on behalf of Jeffrey Haas" < > rtg-bfd-boun...@ietf.org on behalf of jh...@pfrc.org> wrote: > > Greg, > > On Sat, Feb 16, 2019 at 09:38:08AM -0800, Greg Mirsky wrote: > > On Sat, Feb 16, 2019 at 8:33 AM Jeffrey Haas <jh...@pfrc.org> wrote: > > > 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. > > The IPR disclosure and the licensing terms are clear. > > The patent is still pending. The draft is against procedures largely > specified in 5880, 5883, and 5884. Presumably IPR has been filed > because > you're saying that you're doing something new against these documents.. > > > GIM>> The behavior of the system in Demand mode is introduced as > optional. > > And that is precisely the update to RFC 5880. > > I don't understand. > > Basically, 5880, 5884 leave demand as an option. It's built into the > specs. > It's unclear what you're suggesting being changed. > > -- Jeff > > > >
