Subject: Re: [Yang-multicast] Few questions related to Yang base model table update.

From: Xufeng Liu <[email-masked]>
Date: Mon, 1 Jun 2015 21:19:04 +0000

Hi,

I have put some of my opinions inline below.

Thanks,

- Xufeng

> -----Original Message-----
> From: Yang-multicast [mailto:[email-masked]] On Behalf Of
> Stig Venaas
> Sent: Thursday, May 28, 2015 10:49 AM
> To: Mahesh Sivakumar (masivaku); KUNDU, Tanmoy (Tanmoy); yang-
> [email-masked]
> Subject: Re: [Yang-multicast] Few questions related to Yang base model table
> update.
> 
> 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]>>
> > 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
> >
> >         leaf retransmit-interval {
> >
> >           type uint16 {
> >
> >             range "1..65535";
> 
> Maybe it is OK to omit the range if all possible values are accepted, here 0 is
> excluded though.

[Xufeng] Agree. Omitting the range is ok, unless we are absolutely sure that the excluded value is invalid. Once the range is specified, we cannot take it out or change it even by "deviation" statement. If no range is specified, a vendor can add restrictions to the value if needed.

> 
> >           }
> >
> >           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.";
> >
> >       }
> >
> > <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.
> 
[Xufeng] All three options are implementable, but with different user experiences. I have put some examples below. Besides the implementation aspect, we should (probably more importantly) consider the usability aspect.

> 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.
> 

[Xufeng] Using this option, IPv4 and IPv6 interfaces are mixed together:

"interface": [
{
  "interface": "if-a-v4",
  "dr-priority": 1,
  "ipv4": 
  {
    "hello-interval": 11
  }
},
{
  "interface": "if-b-v6",
  "dr-priority": 2,
  "ipv6": 
  {
    "hello-interval": 12
  }
}
{
  "interface": "if-c-v4",
  "dr-priority": 3,
  "ipv4": 
  {
    "hello-interval": 13
  }
}
]

> 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.
> 
[Xufeng] Using this option, IPv4 interfaces are grouped together:

"ipv4": 
{
  "interface": [
  {
    "interface": "if-a-v4",
    "dr-priority": 1,
    "hello-interval": 11
  },
  {
    "interface": "if-c-v4",
    "dr-priority": 3,
    "ipv4": 
    "hello-interval": 13
  }
],
"ipv6":
{
  "interface": [
  {
    "interface": "if-b-v6",
    "dr-priority": 2,
    "hello-interval": 12
  }
]
}

>     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.

[Xufeng] I'd prefer this option, from usability perspective. When I build or check a multicast network, I know it is IPv4 or IPv6. I'd prefer to see all IPv4 interfaces grouped together, not mixed with IPv6 interfaces. For option 1, I can apply filters to retrieve these related interfaces, but it is less convenient.

> 
> 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,
> >
> > 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.
> >
> > <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).
> >
> > 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] <mailto:[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
> >
> > On 5/22/2015 1:09 PM, Stig Venaas wrote:
> >
> >> Hi
> >
> >>
> >
> >> Our wiki is at
> >
> >>
> >
> >>http://trac.tools.ietf.org/wg/pim/trac/wiki/yang
> >
> >>
> >
> >> 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 athttps://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
> >
> >>
> >
> >> _______________________________________________
> >
> >> Yang-multicast mailing list
> >
> >>[email-masked] <mailto:[email-masked]>
> >
> >>https://www.ietf.org/mailman/listinfo/yang-multicast
> >
> > _______________________________________________
> >
> > Yang-multicast mailing list
> >
> > [email-masked] <mailto:[email-masked]>
> >
> > https://www.ietf.org/mailman/listinfo/yang-multicast
> >
> 
> _______________________________________________
> Yang-multicast mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/yang-multicast

---

From: "KUNDU, Tanmoy (Tanmoy)" <[email-masked]>
Date: Mon, 1 Jun 2015 21:40:12 +0000

Hi Xufeng,

For me the more convenient option seems like below , where all interface parameters are grouped inside a single Leaf (interface configuration) and each AF and AF based configuration becomes a leaf to the interface configuration. As you mentioned the usability should be more preferred than implementation, this organization looks compact and easy to understand.

Do let me know your/others point of view.

"interface": [

{

  "interface": "if-a",                         //name and description

  "dr-priority": 1,                            //af independent parameters

  "ipv4":                                      //IPv4 af dependent parameters

  {

    "hello-interval" : 123,

    "bfd":true

  }

  "ipv6":                                       //IPv6 af dependent parameters

  {

    "hello-interval" : 234,

    "bfd":false;

  }

},

]

P.S. the elements are just for illustration purpose, which configuration should be inside AF and outside AF sub-leaf is not the point of interest here. My intention is to provide the organization of the interface leaf and AF sub-leaf inside interface.

Thanks,

Tanmoy

-----Original Message-----
From: Xufeng Liu [mailto:[email-masked]]
Sent: Monday, June 01, 2015 2:19 PM
To: Stig Venaas; Mahesh Sivakumar (masivaku); KUNDU, Tanmoy (Tanmoy); [email-masked]
Subject: RE: [Yang-multicast] Few questions related to Yang base model table update.

Hi,

Thanks,

- Xufeng

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

> Subject: Re: [Yang-multicast] Few questions related to Yang base model

> > To: Cisco Employee <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>,

> > Stig Venaas <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>,

> > "[email-masked] <mailto:[email-masked]><mailto:[email-masked]%20%3cmailto:[email-masked]%3e>"

> > <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>

> > Subject: RE: [Yang-multicast] Few questions related to Yang base

> > the ranges mentioned. I believe we should also have a range

> > otherwise the Yang model by itself won't be complete. For e.g.

> Maybe it is OK to omit the range if all possible values are accepted,

> here 0 is excluded though.

> > 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.

> > 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.

> > 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.

"interface": [

{

  "interface": "if-a-v4",

  "dr-priority": 1,

  "ipv4":

  {

    "hello-interval": 11

  }

},

{

  "interface": "if-b-v6",

  "dr-priority": 2,

  "ipv6":

  {

    "hello-interval": 12

  }

}

{

  "interface": "if-c-v4",

  "dr-priority": 3,

  "ipv4":

  {

    "hello-interval": 13

  }

}

]

"ipv4":

{

  "interface": [

  {

    "interface": "if-a-v4",

    "dr-priority": 1,

    "hello-interval": 11

  },

  {

    "interface": "if-c-v4",

    "dr-priority": 3,

    "ipv4":

    "hello-interval": 13

  }

],

"ipv6":

{

  "interface": [

  {

    "interface": "if-b-v6",

    "dr-priority": 2,

    "hello-interval": 12

  }

]

}

> 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.

> > *To:* KUNDU, Tanmoy (Tanmoy); Stig Venaas; [email-masked]<mailto:[email-masked]>

> > *To: *Stig Venaas <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>,

> > "[email-masked] <mailto:[email-masked]><mailto:[email-masked]%20%3cmailto:[email-masked]%3e>"

> > <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>

> > 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.

> > <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

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

> > Subject: [Yang-multicast] Please add what interface config you

> > support to multicast YANG wiki

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

> >> have

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

> >> a

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

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

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

---

From: Anish Peter <[email-masked]>
Date: Tue, 2 Jun 2015 09:10:29 +0530

Hi all,
  Enforcing af specific config forces config duplication. It will be 
better to have a model that supports leaner config.
  Also it may be worth to know if there really exists use case for 
having different values for different af's. As such I am wondering what 
would motivate different hello-intervals for v4 and v6.
  For implementation that supports only af specific config, the 
implementation could interpret this as two statements for v4 and v6. 
Different values for af's could still be supported by augmentation. This 
way we have a model that is compatible with all. Hence I would favor the 
model given below as its leaner and could work with all implementations. 
This is inline with the existing isis yang model for interface config.

Thanks,
Anish

On 6/2/15 3:10 AM, KUNDU, Tanmoy (Tanmoy) wrote:
>
> Hi Xufeng,
>
> For me the more convenient option seems like below , where all 
> interface parameters are grouped inside a single Leaf (interface 
> configuration) and each AF and AF based configuration becomes a leaf 
> to the interface configuration. As you mentioned the usability should 
> be more preferred than implementation, this organization looks compact 
> and easy to understand.
>
>     “hello-interval” : 123,
>     “bfd”:true
>   “ipv6”:                                       //IPv6 af dependent 
> parameters
>
>   {
>
>     “hello-interval” : 234,
>
>     “bfd”:false;
>
>   }
>
> },
>
> ]
>
> P.S. the elements are just for illustration purpose, which 
> configuration should be inside AF and outside AF sub-leaf is not the 
> point of interest here. My intention is to provide the organization of 
> the interface leaf and AF sub-leaf inside interface.
>
> Thanks,
>
> Tanmoy
>
>

---

From: "Mahesh Sivakumar (masivaku)" <[email-masked]>
Date: Tue, 2 Jun 2015 04:10:30 +0000

Anish,

I do agree with the overall structure (having AF inside the interface).
But forcing specific config outside AF doesn’t allow the flexibility to have different values for each AF.
If an implementation were to support different values for a config per AF, we would need to define it again inside the AF.

On the other hand, the impression I got from our discussion is that most of the implementations support AF specific values.
I was thinking that we should keep it under the AF and the implementations that do not allow different values have the following choices
(1) Either reject the config if they configure different values for each AF
(2) Use the value configured under IPv4 for both Afs.
(3) Augment the base model and have those configs outside the AF

Thanks
Mahesh

From: Anish Peter <[email-masked]<mailto:[email-masked]>>
Date: Monday, June 1, 2015 at 8:40 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Yang-multicast] Few questions related to Yang base model table update.

Hi all,
 Enforcing af specific config forces config duplication. It will be better to have a model that supports leaner config.
 Also it may be worth to know if there really exists use case for having different values for different af's. As such I am wondering what would motivate different hello-intervals for v4 and v6.
 For implementation that supports only af specific config, the implementation could interpret this as two statements for v4 and v6. Different values for af's could still be supported by augmentation. This way we have a model that is compatible with all. Hence I would favor the model given below as its leaner and could work with all implementations. This is inline with the existing isis yang model for interface config.

Thanks,
Anish

Hi Xufeng,

"interface": [

{

  {

    “hello-interval” : 123,

    “bfd”:true

  }

  “ipv6”:                                       //IPv6 af dependent parameters

  {

    “hello-interval” : 234,

    “bfd”:false;

  }

},

]

Thanks,

Tanmoy