Subject: [Yang-multicast] Wiki update, slides and recordings

From: Stig Venaas <[email-masked]>
Date: Wed, 13 May 2015 14:33:30 -0700

Hi

Please see the wiki at
http://trac.tools.ietf.org/wg/pim/trac/wiki/yang

I added the list of people in the team. Are you OK with this? Is
the info correct? Note that you can all get access and edit this
info. Let me know if you have questions how to do this.

I also added slides and recordings from our meetings so far.

Sorry for being a bit slow on this. Next thing is for me to send
some of the emails I promised last meeting to get some discussion
going on the list.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Fri, 22 May 2015 13:09:17 -0700

Hi

Our wiki is at

I hope you can all help update that. As we discussed I will try to
create some matrix of pim interface config leaves and you can help
fill in what each of your implementations support.

To update the wiki you need an IETF tools account. If you don't
have one, create one at https://tools.ietf.org/newlogin

I'm updating the wiki with slides and recording of last meeting
in a few minutes. Then I'll see what I can do about that matrix.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Tue, 26 May 2015 12:01:35 -0700

Hi, I have now created a matrix where you can add what
interface config you support. Please update at
http://trac.tools.ietf.org/wg/pim/trac/wiki/yang

Stig

On 5/22/2015 1:09 PM, Stig Venaas wrote:
> _______________________________________________
> Yang-multicast mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/yang-multicast

---

From: "KUNDU, Tanmoy (Tanmoy)" <[email-masked]>
Date: Wed, 27 May 2015 18:53:38 +0000

Hi,

I have few questions, can we discuss them on next week meeting?

1.   What happens if the parameter ranges differ from vendor to vendor ? for e.g. Hello interval in the current table of Yang wiki. I propose that Yang Base model should take the highest value and lowest value in among all vendors and Base Yang model should incorporate them as range. Every vendor may either choose to support according to the range in Yang Base model. Otherwise it may dis-allow the configuration and throw appropriate error if configuration is outside of "their" range.

2.   What happens if some configuration parameter is supported/not-supported by "most" of the vendors ?

     a. If it's outside of the scope of RFC and implantation specific, then we should not incorporate it in base Yang model. Such implementation specific configuration, vender should use augmented table and provide.

     b. If most of the vendors supports then it should be there in base yang model itself, even though its implementation specific. But to identify them we at least add the supported configuration parameters on the table, isn't it ? I added couple of them to the table but there are more.

3.   Not sure how to put the AF based configurations on the table ? for e.g. IPv6 PIM disable on PIM interface.

Thanks,

Tanmoy

-----Original Message-----
From: Yang-multicast [mailto:[email-masked]] On Behalf Of Stig Venaas
Sent: Tuesday, May 26, 2015 12:02 PM
To: [email-masked]
Subject: [Yang-multicast] Please add what interface config you support to multicast YANG wiki

Hi, I have now created a matrix where you can add what interface config you support. Please update at http://trac.tools.ietf.org/wg/pim/trac/wiki/yang

Stig

> To update the wiki you need an IETF tools account. If you don't have

> one, create one at https://tools.ietf.org/newlogin

> I'm updating the wiki with slides and recording of last meeting in a

> few minutes. Then I'll see what I can do about that matrix.

> [email-masked]<mailto:[email-masked]>

[email-masked]<mailto:[email-masked]>

---

From: "Mahesh Sivakumar (masivaku)" <[email-masked]>
Date: Wed, 27 May 2015 19:37:26 +0000

See inline <Mahesh>

Thanks
Mahesh

From: <KUNDU>, "Tanmoy (Tanmoy)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, May 27, 2015 at 11:53 AM
To: Stig Venaas <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Yang-multicast] Few questions related to Yang base model table update.

Hi,

1.   What happens if the parameter ranges differ from vendor to vendor ? for e.g. Hello interval in the current table of Yang wiki. I propose that Yang Base model should take the highest value and lowest value in among all vendors and Base Yang model should incorporate them as range. Every vendor may either choose to support according to the range in Yang Base model. Otherwise it may dis-allow the configuration and throw appropriate error if configuration is outside of “their” range.

<Mahesh> We discussed this briefly in our last meeting. The idea was to not specify a range for any parameter in the base model and have the vendors augment the base model to specify appropriate ranges.

     a. If it’s outside of the scope of RFC and implantation specific, then we should not incorporate it in base Yang model. Such implementation specific configuration, vender should use augmented table and provide.

<Mahesh> Agree. We should not have something outside the scope of the RFC in the base model even if it is implemented by some vendors

     b. If most of the vendors supports then it should be there in base yang model itself, even though its implementation specific. But to identify them we at least add the supported configuration parameters on the table, isn’t it ? I added couple of them to the table but there are more.

<Mahesh> Agree. If applicable to the RFC and even if not all vendors support it, it can be made part of the base model. However, it will have to be an optional parameter (feature).

Thanks,

Tanmoy

-----Original Message-----
From: Yang-multicast [mailto:[email-masked]] On Behalf Of Stig Venaas
Sent: Tuesday, May 26, 2015 12:02 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Yang-multicast] Please add what interface config you support to multicast YANG wiki

Stig

---

From: "KUNDU, Tanmoy (Tanmoy)" <[email-masked]>
Date: Wed, 27 May 2015 23:53:14 +0000

Hi Mahesh,

Thanks for replying.

1. I have just checked the OSPF/ISIS yang model and they indeed have the ranges mentioned. I believe we should also have a range otherwise the Yang model by itself won't be complete. For e.g.

OSPF

       leaf retransmit-interval {

         type uint16 {

           range "1..65535";

         }

         units seconds;

         description

           "Time between retransmitting unacknowledged Link State

            Advertisements (LSAs).";

ISIS Yang

typedef wide-metric {

       type uint32 {

         range "0 .. 16777215";

       }

       description

        "This type defines wide style format

         of ISIS metric.";

     }

2.   How do we put AF based configurations on the interface ? We need to agree on that. Last meeting we could not come up to a final conclusion. I liked the idea of having AF as a list(like ISIS) inside interface and each AF based configs should be inside this AF leaf.

As I see in the current table in PIM Yang, parameters such as Hello, DR-priority etc is not AF based(at least not mentioned in the table), hence we can keep it outside of AF list.

At the same time as Stig pointed(and I totally agree with Stig) it is more logical to put hello and DR-priority per AF and each vendor can have their back-end to handle such config. But since no vendor is allowing such configuration today, perhaps we can put it outside of AF but inside the interface leaf.

Thanks,

Tanmoy

From: Mahesh Sivakumar (masivaku) [mailto:[email-masked]]
Sent: Wednesday, May 27, 2015 12:37 PM
To: KUNDU, Tanmoy (Tanmoy); Stig Venaas; [email-masked]
Subject: Re: [Yang-multicast] Few questions related to Yang base model table update.

See inline <Mahesh>

Thanks
Mahesh

Hi,

Thanks,

Tanmoy

-----Original Message-----
From: Yang-multicast [mailto:[email-masked]] On Behalf Of Stig Venaas
Sent: Tuesday, May 26, 2015 12:02 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Yang-multicast] Please add what interface config you support to multicast YANG wiki

Stig

---

From: "Mahesh Sivakumar (masivaku)" <[email-masked]>
Date: Thu, 28 May 2015 00:08:17 +0000

Inline <Mahesh>

From: <KUNDU>, "Tanmoy (Tanmoy)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, May 27, 2015 at 4:53 PM
To: Cisco Employee <[email-masked]<mailto:[email-masked]>>, Stig Venaas <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Yang-multicast] Few questions related to Yang base model table update.

Hi Mahesh,

Thanks for replying.

1.I have just checked the OSPF/ISIS yang model and they indeed have the ranges mentioned. I believe we should also have a range otherwise the Yang model by itself won’t be complete. For e.g.

OSPF

         type uint16 {

           range "1..65535";

         }

         units seconds;

         description

            Advertisements (LSAs).";

ISIS Yang

typedef wide-metric {

       type uint32 {

         range "0 .. 16777215";

       }

       description

         of ISIS metric.";

     }

<Mahesh> There are two options as I see. Either have a range which accounts for the minimum and maximum across all vendors. The second option is to not have a range. In either case, the vendor needs to augment to fine-tune the range. So, I don’t see a need to specify the range. It could just be the maximum value specified by the type.

<Mahesh> I don’t think it is the case that no vendor allows such configuration. I thought (at least from the last discussion) the majority of the vendors have parameters such as Hello, DR-priority under the AF which would mean each AF can define different values for them. I agree with Stig that it makes sense to have them under the AF and if a specific vendor needs it to be the same across AF can augment it to have it under the interface. Those parameters under the AF will be marked optional (features) in the base model so as to allow some vendors to not support it under the AF.

Thanks,

Tanmoy

From: Mahesh Sivakumar (masivaku) [mailto:[email-masked]]
Sent: Wednesday, May 27, 2015 12:37 PM
To: KUNDU, Tanmoy (Tanmoy); Stig Venaas; [email-masked]<mailto:[email-masked]>
Subject: Re: [Yang-multicast] Few questions related to Yang base model table update.

See inline <Mahesh>

Thanks
Mahesh

Hi,

Thanks,

Tanmoy

-----Original Message-----
From: Yang-multicast [mailto:[email-masked]] On Behalf Of Stig Venaas
Sent: Tuesday, May 26, 2015 12:02 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Yang-multicast] Please add what interface config you support to multicast YANG wiki

Stig

---

From: Stig Venaas <[email-masked]>
Date: Thu, 28 May 2015 07:48:43 -0700

Hi

Thanks for following up on this.

Inline

On 5/27/2015 5:08 PM, Mahesh Sivakumar (masivaku) wrote:
> Inline <Mahesh>
>
> From: <KUNDU>, "Tanmoy (Tanmoy)" <[email-masked]
> <mailto:[email-masked]>>
> To: Cisco Employee <[email-masked] <mailto:[email-masked]>>,
> Stig Venaas <[email-masked] <mailto:[email-masked]>>,
> "[email-masked] <mailto:[email-masked]>"
> <[email-masked] <mailto:[email-masked]>>
> 1.I have just checked the OSPF/ISIS yang model and they indeed have the
> ranges mentioned. I believe we should also have a range otherwise the
> Yang model by itself won’t be complete. For e.g.
>
> OSPF
>

Maybe it is OK to omit the range if all possible values are
accepted, here 0 is excluded though.

> <Mahesh> There are two options as I see. Either have a range which
> accounts for the minimum and maximum across all vendors. The second
> option is to not have a range. In either case, the vendor needs to
> augment to fine-tune the range. So, I don’t see a need to specify the
> range. It could just be the maximum value specified by the type.
>
>
> 2.How do we put AF based configurations on the interface ? We need to
> agree on that. Last meeting we could not come up to a final conclusion.
> I liked the idea of having AF as a list(like ISIS) inside interface and
> each AF based configs should be inside this AF leaf.

I like this too.

> As I see in the current table in PIM Yang, parameters such as Hello,
> DR-priority etc is not AF based(at least not mentioned in the table),
> hence we can keep it outside of AF list.

Most implementations I believe have this per address family.
Question is how to cope with those that don't.

> At the same time as Stig pointed(and I totally agree with Stig) it is
> more logical to put hello and DR-priority per AF and each vendor can
> have their back-end to handle such config. But since no vendor is
> allowing such configuration today, perhaps we can put it outside of AF
> but inside the interface leaf.
>
> <Mahesh> I don’t think it is the case that no vendor allows such
> configuration. I thought (at least from the last discussion) the
> majority of the vendors have parameters such as Hello, DR-priority under
> the AF which would mean each AF can define different values for them. I
> agree with Stig that it makes sense to have them under the AF and if a
> specific vendor needs it to be the same across AF can augment it to have
> it under the interface. Those parameters under the AF will be marked
> optional (features) in the base model so as to allow some vendors to not
> support it under the AF.

Yes, so here are the options I see.

1. Have the model provide objects both for AF independent and per AF
    config.

    In this case all the objects could perhaps be features so that
    vendors can choose. There are several ways this could be done,
    but it seems a bit complex to me.

2. Only have AF independent objects.

    This means that on implementations that allow per AF config, the
    current config can not be properly represented, and when configuring
    a device, one cannot do per AF config even if the implementation
    supports it.

3. Only per AF objects.

    On implementations that allow only AF independent config, this
    means that when reading one can populate objects for one AF, or
    maybe for all AFs, all having the AF independent values. When
    writing a config that has objects for one AF, those can update
    the AF independent configs. If the config has multiple AFs with
    potentially different values one could either not accept the
    config, or choose to only use values for one family. E.g. one
    could when reading provide either only IPv4 config, or both IPv4
    and IPv6. When writing, one can either use just IPv4 or IPv6, but
    if both are present with different values, maybe say that always
    prefer the IPv4 config.

I prefer option 3, at least it seems AF independent config is not
that common, and it allows a way for both representing the current
config and configuration of all the capabilities of all
implementations.

Option 2 would not be able to represent the current config on many
implementations, and not all full config capabilities.

Option 1 could be done, but I'm a bit worried that we end up with
too complicated models with too many options and hard to use.

Stig

> Thanks,
>
> Tanmoy
>
> *From:*Mahesh Sivakumar (masivaku) [mailto:[email-masked]]
> *Sent:* Wednesday, May 27, 2015 12:37 PM
> *To:* KUNDU, Tanmoy (Tanmoy); Stig Venaas; [email-masked]
> <mailto:[email-masked]>
> *Subject:* Re: [Yang-multicast] Few questions related to Yang base model
> table update.
>
> See inline <Mahesh>
>
> Thanks
>
> Mahesh
>
> *From: *<KUNDU>, "Tanmoy (Tanmoy)" <[email-masked]
> <mailto:[email-masked]>>
> *Date: *Wednesday, May 27, 2015 at 11:53 AM
> *To: *Stig Venaas <[email-masked] <mailto:[email-masked]>>,
> "[email-masked] <mailto:[email-masked]>"
> <[email-masked] <mailto:[email-masked]>>
> *Subject: *[Yang-multicast] Few questions related to Yang base model
> table update.
>
> Hi,
>
> 1.   What happens if the parameter ranges differ from vendor to vendor ?
> for e.g. Hello interval in the current table of Yang wiki. I propose
> that Yang Base model should take the highest value and lowest value in
> among all vendors and Base Yang model should incorporate them as range.
> Every vendor may either choose to support according to the range in Yang
> Base model. Otherwise it may dis-allow the configuration and throw
> appropriate error if configuration is outside of “their” range.
>
> <Mahesh> We discussed this briefly in our last meeting. The idea was to
> not specify a range for any parameter in the base model and have the
> vendors augment the base model to specify appropriate ranges.
>
> 2.   What happens if some configuration parameter is
> supported/not-supported by "most" of the vendors ?
>
>       a. If it’s outside of the scope of RFC and implantation specific,
> then we should not incorporate it in base Yang model. Such
> implementation specific configuration, vender should use augmented table
> and provide.
>
> <Mahesh> Agree. We should not have something outside the scope of the
> RFC in the base model even if it is implemented by some vendors
>
>       b. If most of the vendors supports then it should be there in base
> yang model itself, even though its implementation specific. But to
> identify them we at least add the supported configuration parameters on
> the table, isn’t it ? I added couple of them to the table but there are
> more.
>
> <Mahesh> Agree. If applicable to the RFC and even if not all vendors
> support it, it can be made part of the base model. However, it will have
> to be an optional parameter (feature).
>
> To: [email-masked] <mailto:[email-masked]>
> Hi, I have now created a matrix where you can add what interface config
> you support. Please update at
>> one, create one athttps://tools.ietf.org/newlogin
>
>>
>
>>[email-masked] <mailto:[email-masked]>
>
> [email-masked] <mailto:[email-masked]>
>