Hi, Greg, It would be useful to understand uses of BFD Echo for on-demand scenarios.
It’s not clear how that would be: When a system is using the Echo function, it is advantageous to choose a sedate reception rate for Control packets, since liveness detection is being handled by the Echo packets. This can be Thanks, — Carlos. On Mar 24, 2017, at 2:50 PM, Greg Mirsky <[email protected]<mailto:[email protected]>> wrote: Hi Jeff, I'll be glad to put couple slides to help jumstart the discussion on BFD Echo. Regards, Greg On Fri, Mar 24, 2017 at 10:46 AM, Jeffrey Haas <[email protected]<mailto:[email protected]>> wrote: [continuing the top-posting heresy to preserve context] Greg, Our schedule is relatively open right now, and this matter is esoteric enough that it probably warrants a slide for the majority of the Working Group to follow this issue. Would you prepare a slide or two to use as a discussion point? I'll also use this opportunity to point out that in S-BFD scenarios, we have somewhat similar ambiguities since it's an on-demand service. -- Jeff On Mon, Feb 27, 2017 at 07:31:01AM -0800, Greg Mirsky wrote: > Hi Reshad, > thank you for providing the context to BFD Echo TX. Indeed, I'm familiar > with implementations that use BFD Echo as Echo request/reply and thus Tx > would be in RPC, not in configuration. I think that it would be good to > discuss this in Chicago unless we hear comments from others on the list. > > Regards, > Greg > > On Mon, Feb 27, 2017 at 5:56 AM, Reshad Rahman (rrahman) > <[email protected]<mailto:[email protected]>> > wrote: > > > Hi Greg, > > > > draft-zheng-mpls-ls-ping-yang-cfg defines transmit interval in RPC > > because all ping operations are done via RPC. I do not consider BFD echo > > to be “on demand” like LSP Ping (caveat: this is possibly due to the BFD > > configuration/implementation I am most familiar with).
