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).
Regards, Reshad. From: Greg Mirsky <[email protected]<mailto:[email protected]>> Date: Monday, February 27, 2017 at 1:07 AM To: Mahesh Jethanandani <[email protected]<mailto:[email protected]>> Cc: Reshad <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: Correcting BFD Echo model Hi Mahesh, BFD Echo transmit interval is not part of RFC 5880, only Rx interval is. And Rx interval is sufficent to reflect whether local system is willing to receive BFD Echo messages from the particular BFD peer. Introduced desired-min-echo-tx-interval functionally overlaps with the standard-defined required-min-echo-rx-interval. Hence my suggestion to remove desired-min-echo-tx-interval from grouping bfd-grouping-echo-cfg-parms. But operators need a way to specify transmit interval for on-demand OAM command like BFD Echo, IP ping or LSP ping. I couldn't find YANG model proposal for IP ping but in draft-zheng-mpls-lsp-ping-yang-cfg transmit interval used in RPC, not as part of configuration. Regards, Greg On Sun, Feb 26, 2017 at 8:33 PM, Mahesh Jethanandani <[email protected]<mailto:[email protected]>> wrote: On Feb 26, 2017, at 4:39 PM, Greg Mirsky <[email protected]<mailto:[email protected]>> wrote: Hi Reshad, thank you for the question. Here's my reasoning: * only Required Min Echo RX Interval is present in RFC 5880 and it allows to indicate not only the smallest interval between consecutive BFD Echo packets but whether system supports BFD Echo function at all; * since BFD Echo may be transmitted only when the session state is Up, operator is fully equipped to learn the value of Required Min Echo RX Interval of its BFD peer and to set Echo transmit interval accordingly; * requesting BFD Echo, in my opinion, is no different from requesting IP ping or LSP ping. Hence my conclusion - transmit interval for BFD Echo is more suitable in RPC then as configuration parameter. I do not think that is reason enough for it to be a RPC. A RPC is an operation one defines in the YANG model specifying both input and output parameters. There are no operations to be had here. And the definition and desired behavior of desired-min-echo-tx-interval is not very different from required-min-echo-x-interval. It is as the definition says, a configuration parameter that can be set, with zero having a special meaning in both cases. Regards, Greg On Sun, Feb 26, 2017 at 2:52 PM, Reshad Rahman (rrahman) <[email protected]<mailto:[email protected]>> wrote: Hi Greg, Can you please explain why you believe this should go in RPC? Regards, Reshad. From: Greg Mirsky <[email protected]<mailto:[email protected]>> Date: Saturday, February 25, 2017 at 6:48 PM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Correcting BFD Echo model Resent-From: <[email protected]<mailto:[email protected]>> Resent-To: <[email protected]<mailto:[email protected]>>, Reshad <[email protected]<mailto:[email protected]>>, <[email protected]<mailto:[email protected]>>, <[email protected]<mailto:[email protected]>>, <[email protected]<mailto:[email protected]>> Resent-Date: Saturday, February 25, 2017 at 6:48 PM Dear All, I've reviewed the BFD YANG model and now I'm thinking that desired-min-echo-tx-interval and attributing to it the behavior, i.e. when the value is 0, of Required Min Echo RX Interval are not in the right place. I think that definition of desired transmit interval of BFD Echo should be in corresponding RPC definition, not in configuration part of the model. Appreciate your comments. Regards, Greg
