Hi Jeff, thank you for your quick response to my comments. I appreciate the update you added to the Write-up.
Regards, Greg On Mon, Jan 15, 2024 at 2:47 PM Jeffrey Haas <[email protected]> wrote: > Greg, > > > On Jan 15, 2024, at 5:15 PM, Greg Mirsky <[email protected]> wrote: > > - For several years I've actively participated in the work at BBF, > including the Working Area that published TR-146. I cannot recall that any > member company reported TR-146 implementation. Were there any on the BFD > mailing list that led to the following summary in the write-up: > > There are multiple implementations that claim some deployment of BBF > TR-146 implementation behavior. > > > If you're reading this as "claiming conformance to tr-146", that's not > what is written here. Mostly because tr-146 was missing enough detail to > make it difficult for a BFD implementation to claim actual conformance. > That's to a great extent what the authors are attempting to rectify. > > In terms of the "BFD talking to itself over Echo", which is the > implementation behavior in question, we can publicly say that the Broadcom > implementation is certainly in the same family. Juniper's BFD-Lite feature > is also in the same family. > > Having not asked for a conformance report vs. this document, I'm not > pointing out other vendors who have similar behaviors. Certainly I'd > encourage others with information on their implementations to respond to > this thread. > > > - In the course of discussing this draft, I commented many times that > the proposed mechanism doesn't require any action from a BFD system outside > of a node that transmits and processes a probe. I suggested that, if > there's interest in publishing this draft, it be published as Experimental > or Informational, but not a Standard track document. I don't find that > point of the discussion reflected in the Shepherd write-up, or > affecting the intended status. > > > I've added the following point to the shepherds report. Hopefully this > addresses your concern: > > 5. In discussion over the document's intended status, Greg has expressed an > opinion > that the document should be Experimental rather than Proposed Standard. As > noted > in the IETF webpage, "Choosing between Informational and Experimental > Status", it is > the Shepherd's opinion that Experimental is inappropriate. "The > "Experimental" > designation typically denotes a specification that is part of some research or > development effort". In this case, implementations are commercially available > utilizing mechanisms largely similar to those being codified in this > Internet-Draft. > > While the procedures in this draft are purely local (the implementation > "talks to itself"), > the behavior requires a violation of RFC 5880 > <https://datatracker.ietf.org/doc/rfc5880/> with regard to Echo procedures > only > being available after the Up state has been achieved in Asynchronous mode. > It is thus the Chairs' opinion that the text permitting the relaxation of that > requirement is appropriate to standardize for this document, and thus an > appropriate > change of status requiring an update to RFC 5880 > <https://datatracker.ietf.org/doc/rfc5880/>. > > > -- Jeff > >
