Subject: [Yang-multicast] Thoughts on high level design of pim model

From: Stig Venaas <[email-masked]>
Date: Fri, 15 May 2015 15:48:09 -0700

Hi

I'm trying to start a discussion on the generic design.

Would something like this make sense? As I understand it this would
be routing instance (VRF) centric which is what IETF routing wants
to use.

For interface config I suggest defining it with address family as
a key. I know some other models have used this too. I think it makes
sense since most of the leaves would be meaningful for all address
families. In the few cases where they don't, it is possible to say
that a certain leaf is only allowed for a certain family.

+--ro routing-state
       +--ro routing-instance* [name]
          +--rw routing-protocols
             +--rw pim
                +--rw pim-interfaces
                   +--rw pim-interface* [address-family if-name]
                      +--rw address-family           enumeration
                      +--rw if-name                  if-name
                      +--rw hello-interval?      uint32
                      +--rw dr-priority?         uint32
                      ...

Stig

---

From: Xufeng Liu <[email-masked]>
Date: Sun, 17 May 2015 00:22:43 +0000

Hi Stig,

Yes. I think that the structure generally makes sense. Agree to use address-family as a key. Since Yang support hierarchical structures, so we don't need to use composite key <address-family, if-name>. We can adjust the structure as:

              +--rw address-family* [address-family]
                +--rw address-family           enumeration
                +--rw pim-interfaces
                   +--rw pim-interface* [if-name]
                      +--rw if-name                  if-name
                      +--rw hello-interval?      uint32
                      +--rw dr-priority?         uint32

Another question is that the following structure

+--rw routing
       +--rw routing-instance* [name]
          +--rw routing-protocols
             +--rw pim

allows multiple instances of pim:

<routing>
  <routing-instance>
    <name>pim1</name>
    <routing-protocols>
      <routing-protocol>
        <pim>
        ......
        </pim>
      <routing-protocol>
    </routing-protocols>
  </routing-instance>
  <routing-instance>
    <name>pim2</name>
    <routing-protocols>
      <routing-protocol>
        <pim>
        ......
        </pim>
      <routing-protocol>
    </routing-protocols>
  </routing-instance>
</routing>

Should we allow this? 

Thanks,

- Xufeng

> -----Original Message-----
> From: Yang-multicast [mailto:[email-masked]] On Behalf Of
> Stig Venaas
> Sent: Friday, May 15, 2015 6:48 PM
> To: [email-masked]
> Subject: [Yang-multicast] Thoughts on high level design of pim model
> 
> Hi
> 
> Would something like this make sense? As I understand it this would be routing
> instance (VRF) centric which is what IETF routing wants to use.
> 
> For interface config I suggest defining it with address family as a key. I know
> some other models have used this too. I think it makes sense since most of the
> leaves would be meaningful for all address families. In the few cases where they
> don't, it is possible to say that a certain leaf is only allowed for a certain family.
> 
> +--ro routing-state
> _______________________________________________
> Yang-multicast mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/yang-multicast

---

From: Anish Peter <[email-masked]>
Date: Tue, 19 May 2015 15:55:28 +0530

Hi,

  Few implementations may not have af specific segregation of all the 
config parameters. It will be confusing if those configs differ under 
different af's. On the other hand the config applied outside the af 
could be applied for all the af's in an implementation. I would prefer a 
model similar to isis.

Thanks,
Anish

On 5/16/15 4:18 AM, Stig Venaas wrote:
> .

---

From: Anish Peter <[email-masked]>
Date: Tue, 19 May 2015 16:01:55 +0530

Hi Xufeng,
   Isn't it a requirement to be able to configure pim under each vrf (Be 
it mvpn vrf, virtual router,  etc...)? In that case this below tree 
looks alright.
Thanks,
Anish

---

From: Xufeng Liu <[email-masked]>
Date: Tue, 19 May 2015 13:56:42 +0000

Hi Anish and all,

Yes. Agree that this is the way to support VRF.

I'd like to clarify that we augment " /routing/routing-instance/routing-protocols" here instead of "/routing/routing-instance/routing-protocols/routing-protocol", and we all agree with it.

Based on this structure and our discussions about the separation of modules (pim-base, pim-sm, and pim-dm), I have combined the available models and got the attached brief models. Any comments are appreciated.

Thanks,

- Xufeng

> Anish Peter
> Sent: Tuesday, May 19, 2015 6:32 AM
> Cc: [email-masked]
> Subject: Re: [Yang-multicast] Thoughts on high level design of pim model
> 
> Hi Xufeng,
>    Isn't it a requirement to be able to configure pim under each vrf (Be it mvpn
> vrf, virtual router,  etc...)? In that case this below tree looks alright.
> Thanks,
> Anish
>

---

From: Stig Venaas <[email-masked]>
Date: Tue, 19 May 2015 09:36:29 -0700

Hi

> I'd like to clarify that we augment " /routing/routing-instance/routing-protocols" here instead of "/routing/routing-instance/routing-protocols/routing-protocol", and we all agree with it.

I'm wondering a bit whether it makes sense to augment routing-protocols.
PIM is quite different from unicast routing protocols. And there is for
instance no route preference which is mandatory in routing-protocols?

Stig

---

From: "Mahesh Sivakumar (masivaku)" <[email-masked]>
Date: Tue, 19 May 2015 21:21:47 +0000

Stig/Xufeng,

We already have interfaces under the routing instance

+--rw routing
   +‹rw routing-instance* [name]
     +‹rw name       string
     .
     +‹rw interfaces
       +‹rw interface* [name]
         +‹rw name            if:interface-ref

Why should we define the pim-interfaces under the routing protocol. Should
we have PIM specific properties either under the interface

How about the option of augmenting

/if:interfaces/if:interface:

and adding PIM specific properties per address-family

Thanks
Mahesh

On 5/16/15, 7:22 PM, "Xufeng Liu" <[email-masked]> wrote:

>Hi Stig,
>
>Yes. I think that the structure generally makes sense. Agree to use
>address-family as a key. Since Yang support hierarchical structures, so
>we don't need to use composite key <address-family, if-name>. We can
>adjust the structure as:
>

---

From: Anish Peter <[email-masked]>
Date: Wed, 20 May 2015 11:24:55 +0530

Hi Xufeng,

> I'd like to clarify that we augment " /routing/routing-instance/routing-protocols" here instead of "/routing/routing-instance/routing-protocols/routing-protocol", and we all agree with it.
  Yes I agree to this.

Thanks,
Anish