Re: I-D Action: draft-ietf-bfd-yang-06.txt

[Mahesh Jethanandani <[e-mail]>]

> On Aug 1, 2017, at 9:33 AM, Jeffrey Haas <[e-mail]> wrote:
> 
> On Tue, Aug 01, 2017 at 08:33:38AM -0700, Mahesh Jethanandani wrote:
>>> I'm ambivalent.  This depends really on real world behavior.
>>> 
>>> As we saw from some brief googling yesterday on Cisco IOS/IOS-XR docs, that
>>> implementation doesn't appear to expose echo intervals as a separably
>>> configurable item.  It did, however, expose a boolean to disable echo.
>> 
>> True. But the standard seems to imply the ability to configure echo values separately. Worst case implementations would have to set both the values to be the same. 
> 
> The protocol does. But that doesn't mean the config model should.

Ok. I have removed the separate configuration values for tx/rx min intervals for echo model. Now, there is only one set of tx/rx values.

> 
>>> This minimally suggests that there should be a "use echo mode" flag.
>> 
>> Will add a boolean to enable/disable echo mode.
> 
> I think that's a good start.

This is what we have now in client-cfg-parms

    container echo-mode {
      if-feature echo-mode;
      leaf echo-mode-enabled {
        type boolean;
        default false;
        description
          "Should be set to true if echo-mode is enabled for this
           session. Set to false by default because defining the
           feature should not enable echo-mode by default.";
      }
    }


Yingzhen, there is one other change that you should be aware of. There is no longer a choice between configuring tx/rx values and a single value for both. Even if the values are the same for tx and rx, you need to configure each of them explicitly. 

I will be uploading the changes shortly.

Thanks.

> 
>>> The remaining homework is to figure out whether we should expose
>>> configuration state for echo directly in this version of the yang.
>> 
>> Per NMDA guidelines, unless the configuration state values are different from config, we do not need to model them as separate attributes.
> 
> Right.  So, again need to check real world implementations.
> 
> If it's the case that implementations supporting echo only use a single set
> of the intervals for echo or not, then we only need that in the model.  
> 
> If it becomes the case that an implementation supports echo intervals
> differently, a vendor *could* augment the model to support such values.
> However, since this is imported via grouping, it means that the augmentation
> has to be done in each module that uses the grouping.
> 
> I hate yang grouping augmentation rules. :-P
> 
> -- Jeff

Mahesh Jethanandani
[e-mail]