Subject: Re: [pim] draft-ietf-pim-yang-02 WGLC

From: Stig Venaas <[email-masked]>
Date: Tue, 4 Oct 2016 14:05:59 -0700

Hi

On Fri, Sep 30, 2016 at 4:29 PM, Xufeng Liu <[email-masked]> wrote:
> Hi Stig and All,
>
> Thanks for the comments. I have updated the models and drafts based on these comments. The updated draft and model files are at: https://github.com/mcallisterjp/pim-yang. Any feedbacks will be appreciated.
>
> The update items include the responses to Stig's previous emails, and the comments below.

Great. I have one comment inline below though.

> Thanks,
>
> - Xufeng
>
>> -----Original Message-----
>> From: Stig Venaas [mailto:[email-masked]]
>> Sent: Friday, September 16, 2016 5:27 PM
>> To: Xufeng Liu <[email-masked]>
>> Cc: Michael McBride <[email-masked]>; [email-masked]
>> Subject: Re: [pim] draft-ietf-pim-yang-02 WGLC
>>
>> Hi
>>
>> I now took some time to review the draft more carefully. Here are comments in
>> addition to what I posted earlier for the WGLC.
>>
>> First some potential issues with the models.
>>
>> I see for hello-interval, jp-interval etc. the data type is timer-value which can
>> also be infinity and no-expiry. Isn't this type to be used for something counting
>> down? These intervals would always be some number of seconds and won't
>> change unless the configuration changes.
> [Xufeng] The "xxx-interval" leaves are the number of seconds that won't change unless the configuration changes.

Right, I understand they are fixed values. That is why I am wondering
whether timer-value is the correct type. Isn't timer-value used for
something that is counting down, and not for fixed values?

Stig

---

From: Xufeng Liu <[email-masked]>
Date: Wed, 5 Oct 2016 13:14:30 +0000

Hi Stig,

Thanks for the comments. Is there any reason why timer-value cannot be used for fixed value too? I think that it can be used for both cases. It is like an integer. In the fixed value case, the operator specifies a value, such as 10sec, the system saves timer-value=10sec. If the operator tries to retrieve the value of the attribute, the system will return 10sec. Is this a problem?

Thanks,

- Xufeng

> Sent: Tuesday, October 4, 2016 5:06 PM
> To: Xufeng Liu <[email-masked]>
> > Thanks for the comments. I have updated the models and drafts based on
> these comments. The updated draft and model files are at:
> https://github.com/mcallisterjp/pim-yang. Any feedbacks will be appreciated.
> >
> >> I now took some time to review the draft more carefully. Here are
> >> comments in addition to what I posted earlier for the WGLC.
> >>
> >> I see for hello-interval, jp-interval etc. the data type is
> >> timer-value which can also be infinity and no-expiry. Isn't this type
> >> to be used for something counting down? These intervals would always
> >> be some number of seconds and won't change unless the configuration
> changes.
> Right, I understand they are fixed values. That is why I am wondering whether
> timer-value is the correct type. Isn't timer-value used for something that is
> counting down, and not for fixed values?
> 
> Stig

---

From: Stig Venaas <[email-masked]>
Date: Wed, 5 Oct 2016 13:30:04 -0700

Hi, I don't know YANG that well, but at least here is the reason I am asking.

First, I see that integers are used for this purpose many places.
Secondly, timer-value is defined as

     typedef timer-value {
       type union {
         type uint16;
         type enumeration {
           enum "infinity" {
             description "The timer is set to infinity.";
           }
           enum "no-expiry" {
             description "The timer is not set.";
           }
         }
       }
       units seconds;
       description "Timer value type.";
     } // timer-value

For something that is a fixed value, infinity and no-expiry have no
meaning. Hence it seems that you would always make use of the the
uint16. In that case, why not just make the type uint16? Or would the
enum values be useful?

Stig

---

From: Xufeng Liu <[email-masked]>
Date: Thu, 6 Oct 2016 13:43:27 +0000

I think that there are two questions here:
1) Do we want to allow the timer configuration to be set to "infinity" and "no-expiry"?
2) Do we want to use the same type for configuration and operational state?

For 1), in our case, I think that most implementations do not allow "infinity" and "no-expiry". If these special settings are needed, it is possible to use special values or do augmentations. Originally our model used uint16. During the discussions, the enumeration was proposed to make the type more generic. We can decide which one to use now. I'm fine with uint16, but don't have strong opinion on this.

For 2), I'd prefer to keep the type same for both configuration and operational state. If the configuration does not support "infinity" and "no-expiry", I'd think that we don't need to show these values as operational state.

Thanks,

- Xufeng

> Sent: Wednesday, October 5, 2016 4:30 PM
> For something that is a fixed value, infinity and no-expiry have no meaning.
> Hence it seems that you would always make use of the the uint16. In that case,
> why not just make the type uint16? Or would the enum values be useful?
> 
> Stig
> 
> 
> > Thanks for the comments. Is there any reason why timer-value cannot be used
> for fixed value too? I think that it can be used for both cases. It is like an integer.
> In the fixed value case, the operator specifies a value, such as 10sec, the system
> saves timer-value=10sec. If the operator tries to retrieve the value of the
> attribute, the system will return 10sec. Is this a problem?
> >
> > Thanks,
> >
> > - Xufeng
> >
> >> > The update items include the responses to Stig's previous emails,
> >> > and the
> >> comments below.
> >>
> >> >> timer-value which can also be infinity and no-expiry. Isn't this
> >> >> type to be used for something counting down? These intervals would
> >> >> always be some number of seconds and won't change unless the
> >> >> configuration
> >> changes.
> >> > [Xufeng] The "xxx-interval" leaves are the number of seconds that
> >> > won't

---

From: Stig Venaas <[email-masked]>
Date: Mon, 10 Oct 2016 15:06:49 -0700

Hi

It might be best that you post a version that addresses the comments
so far. A YANG doctor is supposed to review it soon and I would like
to have the changes we agreed on to be addressed in that version.

Regarding this issue. I'm hoping you can discuss it in the DT. To me
it doesn't make sense that a value like say join/prune interval has
the value infinity or no-expiry. The configuration says how often a
join/prune should be sent. I do not see how infinity/no-expiry can
apply.

Stig

---

From: Xufeng Liu <[email-masked]>
Date: Tue, 11 Oct 2016 14:45:59 +0000

Hi Stig and All,

I have just posted a new version containing the updates that we have done so far.

We will discuss the interval type in the DT.

Also, do you have preference about the BFD configuration. Do we want to include only enable/disable, or multiplier too? During the DT discussions, we heard that some implementations (including Cisco) have the multiplier option on the protocol interface, and others prefer the multiplier specified in BFD model. The same debate occurred in BFD WG too.

Any further comments are welcome.

Thanks,

- Xufeng

> Sent: Monday, October 10, 2016 6:07 PM
> It might be best that you post a version that addresses the comments so far. A
> YANG doctor is supposed to review it soon and I would like to have the changes
> we agreed on to be addressed in that version.
> 
> Regarding this issue. I'm hoping you can discuss it in the DT. To me it doesn't
> make sense that a value like say join/prune interval has the value infinity or no-
> expiry. The configuration says how often a join/prune should be sent. I do not
> see how infinity/no-expiry can apply.
> 
> Stig
> 
> 
> > For 1), in our case, I think that most implementations do not allow "infinity"
> and "no-expiry". If these special settings are needed, it is possible to use special
> values or do augmentations. Originally our model used uint16. During the
> discussions, the enumeration was proposed to make the type more generic. We
> can decide which one to use now. I'm fine with uint16, but don't have strong
> opinion on this.
> >
> > For 2), I'd prefer to keep the type same for both configuration and operational
> state. If the configuration does not support "infinity" and "no-expiry", I'd think
> that we don't need to show these values as operational state.
> >
> > Thanks,
> >
> > - Xufeng
> >
> >> Hence it seems that you would always make use of the the uint16. In
> >> that case, why not just make the type uint16? Or would the enum values be
> useful?
> >>
> >> Stig
> >>
> >>
> >> In the fixed value case, the operator specifies a value, such as
> >> 10sec, the system saves timer-value=10sec. If the operator tries to
> >> retrieve the value of the attribute, the system will return 10sec. Is this a
> problem?
> >> >
> >> > Thanks,
> >> >
> >> > - Xufeng
> >> >
> >> >> > The update items include the responses to Stig's previous
> >> >> > emails, and the
> >> >> comments below.
> >> >>
> >> >> >> I now took some time to review the draft more carefully. Here
> >> >> >> are comments in addition to what I posted earlier for the WGLC.
> >> >> >>
> >> >> >> timer-value which can also be infinity and no-expiry. Isn't
> >> >> >> this type to be used for something counting down? These
> >> >> >> intervals would always be some number of seconds and won't
> >> >> > [Xufeng] The "xxx-interval" leaves are the number of seconds
> >> >> > that won't
> >> >> Right, I understand they are fixed values. That is why I am
> >> >> wondering whether timer-value is the correct type. Isn't
> >> >> timer-value used for something that is counting down, and not for fixed
> values?
> >> >>
> >> >> Stig

---

From: Stig Venaas <[email-masked]>
Date: Wed, 12 Oct 2016 10:53:04 -0700

Hi

I was wondering about BFD too, but I don't have any opinion I think.
We got a YANG doctor appointed, I'll let him know we just posted a new
version he can look at.

Stig