Xiao Min, On Fri, Nov 19, 2021 at 10:15:08AM +0800, xiao.m...@zte.com.cn wrote: > Thank you Jeff! A very clear description on the core motivation and current > situation. > From the author's perspective, I'd like to remove the reference to BBF TR-146 > if it's becoming a blocking issue instead of a supporting argument.
My recommendation is we leave that text alone for the time being. Since the feature is inspired by it, we'll likely want to discuss it in the document long term - even if to contrast how it's both similar and different. BBF as an organization may request us to remove the text, or perhaps offer other positions on the document's fate. We'll be sending a liaison statement to BBF probably next week. Thanks to Greg and Joel for motivating this past-due bit of followup. -- Jeff > > Best Regards, > Xiao Min > ------------------原始邮件------------------ > 发件人：JeffreyHaas > 收件人：肖敏10093570; > 抄送人：gregimir...@gmail.com;rtg-bfd@ietf.org;draft-ietf-bfd-unaffiliated-e...@ietf.org; > 日 期 ：2021年11月18日 22:29 > 主 题 ：Re: Several questions about the draft-ietf-bfd-unaffiliated-echo > I owe the commenters in this thread a detailed response in the near future. > However, I did want to highlight the underlying motivation the Working Group > had to pick up this work. > On Wed, Nov 17, 2021 at 05:00:09PM +0800, xiao.m...@zte.com.cn wrote: > > As you may have known or not, before this draft was posted, we ever tried > > to submit an errata instead of an I-D. However, under the direction of the > > responsible AD and WG chairs, we realized that an informational draft > > might be the proper way to record our implementation and deployment. And > > then, during the adoption poll of this draft, there was rough consensus > > that this draft should be adopted as standards track document, so we > > changed the intended status from informational to standards track. > A core motivation for this work is to provide an IETF standardized profile > of what is typically shipped as Broadband Forum (BBF) TR-146. That > mechanism, effectively running a BFD-aware system with a system that does > NOT implement BFD but able to provide BFD Echo loopback mode. Arguably, > this is one step better than running ping and significantly better from a > monitoring standpoint since BFD machinery can be leveraged on the side that > supports it for creating events. > TR-146 wasn't as clearly specified as we tend to like in IETF BFD work, so > we're doing a flavor of that here. > Prior discussion with our AD of the time suggested that this is targeted > toward Standards Track. But like all IETF work, once we've completed the > draft, we may consider whether that classification remains correct. > -- Jeff
