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

[Xufeng Liu <[e-mail]>]

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

> -----Original Message-----
> From: Stig Venaas [mailto:[e-mail]]
> Sent: Monday, October 10, 2016 6:07 PM
> To: Xufeng Liu <[e-mail]>
> Cc: Michael McBride <[e-mail]>; [e-mail]
> Subject: Re: [pim] draft-ietf-pim-yang-02 WGLC
> 
> 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
> 
> 
> On Thu, Oct 6, 2016 at 6:43 AM, Xufeng Liu <[e-mail]> wrote:
> > 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
> >
> >> -----Original Message-----
> >> From: Stig Venaas [mailto:[e-mail]]
> >> Sent: Wednesday, October 5, 2016 4:30 PM
> >> To: Xufeng Liu <[e-mail]>
> >> Cc: Michael McBride <[e-mail]>; [e-mail]
> >> Subject: Re: [pim] draft-ietf-pim-yang-02 WGLC
> >>
> >> 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
> >>
> >>
> >> On Wed, Oct 5, 2016 at 6:14 AM, Xufeng Liu <[e-mail]> wrote:
> >> > 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
> >> >
> >> >> -----Original Message-----
> >> >> From: Stig Venaas [mailto:[e-mail]]
> >> >> Sent: Tuesday, October 4, 2016 5:06 PM
> >> >> To: Xufeng Liu <[e-mail]>
> >> >> Cc: Michael McBride <[e-mail]>; [e-mail]
> >> >> Subject: Re: [pim] draft-ietf-pim-yang-02 WGLC
> >> >>
> >> >> Hi
> >> >>
> >> >> On Fri, Sep 30, 2016 at 4:29 PM, Xufeng Liu <[e-mail]> 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:[e-mail]]
> >> >> >> Sent: Friday, September 16, 2016 5:27 PM
> >> >> >> To: Xufeng Liu <[e-mail]>
> >> >> >> Cc: Michael McBride <[e-mail]>; [e-mail]
> >> >> >> 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