Subject: [Yang-multicast] Hi; comments on last week's discussion

From: Pete McAllister <[email-masked]>
Date: Mon, 1 Jun 2015 17:04:42 +0000

Hi all,

I'm slowly getting up to speed on the progress that this design team has made so far.

To begin with, there were a few unresolved issues in the last meeting that I'd like to comment on.

-          It sounds like everyone agrees that optional pieces of function shouldn't be mandatory fields, but I think in particular we should be using yang features for large areas of function so that capabilities can be more easily negotiated. Different devices support different levels of PIM function: I'm particularly thinking of PIM-DM, Anycast-RP, BSR, SSM-only devices... (see RFC7063)

-          Having interface properties a child of address family sounds right.  The data paths and protocol operations of different address families are independent, so this is maybe a better way to model the configuration conceptually, as well as practical for cases of interface config dependent on AF.

-          On the top-level structure question, I agree that BIDIR should be a container at the same level as SM and DM.  Is there any particular reason why should not have a container for ASM-specific state?  There is plenty of it that is not relevant for SSM.  Also, why shouldn't GR be configurable per-AF?  So have the top level look something like:
augment /rt:routing/rt:routing-instance/rt:routing-protocols:
   +--rw pim
      +--rw address-family* [address-family]
         +--rw address-family    identityref
         +--rw graceful-restart {graceful-restart}?
         +--rw interfaces
         |  +--rw interface* [interface]
         |     +--rw interface         if:interface-ref
         |     +--rw dr-priority?      uint32
         |     +--rw hello-interval?   uint16
         |     +--rw pim-sm:sm!
         |        +--rw pim-sm:passive?   Empty
         +--rw pim-sm!
         |  +--rw pim-ssm!
         |  |  +--...
         |  +--rw pim-asm!
         |  |  +--rw pim-asm:anycast-rp!
         |  |  +--rw pim-asm:static-rp
         |  |  +--...
         +--rw pim-dm!
         +--rw pim-bidir!

-          On the subject of vendor-specific ranges and capabilities, wouldn't it be possible to use vendor augmentations to the model to express extra constraints caused by limitations of the implementation? Constrain interface properties to be consistent across AF if required, for example, or to restrict timer ranges?  Has this approach been considered already?

Thanks,
Pete

---

From: Xufeng Liu <[email-masked]>
Date: Tue, 2 Jun 2015 13:59:57 +0000

Hi Pete and All,

Some of my opinions below inline.

Thanks,

- Xufeng

From: Yang-multicast [mailto:[email-masked]] On Behalf Of Pete McAllister
Sent: Monday, June 01, 2015 1:05 PM
To: [email-masked]'
Subject: [Yang-multicast] Hi; comments on last week's discussion

Hi all,

[Xufeng] Agree.

[Xufeng] Agree with the structure in general. Will try to put it into the models to see if everyone is ok with it. We can discuss it on Wednesday.

[Xufeng] Vendor augmentation model can add extra constraints, but cannot lift any rang specified in the base model.

Thanks,
Pete

---

From: Xufeng Liu <[email-masked]>
Date: Tue, 2 Jun 2015 20:16:18 +0000

Hi All,

Attached please find the proposed model tree view, along with the YANG files.

The interface structure is still being discussed, so I have not changed it yet. Once we decide which option to use, the model can be easily updated.

Thanks,

- Xufeng

From: Xufeng Liu
Sent: Tuesday, June 02, 2015 10:00 AM
To: 'Pete McAllister'; [email-masked]'
Subject: RE: Hi; comments on last week's discussion

Hi Pete and All,

Thanks,

- Xufeng

Hi all,

[Xufeng] Agree.

Thanks,
Pete