Subject: Re: [Lime] Call for Adoption: draft-tissa-lime-yang-oam-model-06

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 7 Sep 2015 02:39:25 +0000

Hi, Mahesh,

Please find one comment inline.

> On Aug 26, 2015, at 9:56 PM, Qin Wu <[email-masked]> wrote:
> 
> Hi, Mahesh:
> -----邮件原件-----
> 发件人: Lime [mailto:[email-masked]] 代表 Mahesh Jethanandani
> 发送时间: 2015年8月27日 5:11
> 收件人: Tom Taylor
> 抄送: [email-masked]; [email-masked]
> 主题: Re: [Lime] Call for Adoption: draft-tissa-lime-yang-oam-model-06
> 
> [Adding BFD mailing list back because this decision affects them]
> 
> Tom,
> 
> I was hoping for a rational that went beyond  “and you shall …”

In addition to what Qin said below, the main rational is to provide higher-level abstractions, beyond the specifics of configuring individual protocols.

Thanks,

— Carlos, as individual.

> 
> Something along the lines of why /lime/bfd is better than /lime -> /bfd. Or why almost all configuration models for BFD that currently work just fine, now have to start supporting CFM like semantics in Maintenance Domain (MD), Maintenance Association (MA) or Maintenance Endpoint (MEP) configuration to realize a BFD session.
> 
> You might find a similar discussion around the devices YANG model germane to this thought process. In particular, the thread titled "issue Y34 - root node" on the netmod mailing list.
> 
> [Qin]: See
> http://www.ietf.org/mail-archive/web/netmod/current/msg12986.html
> http://www.ietf.org/mail-archive/web/netmod/current/msg13113.html
> 
> What device YANG model is applied to this WG is about the following substructure:
>     +--rw device
>          +--rw logical-network-elements
>                +--rw networking-instances
>                   +--rw networking-instance* [networking-instance-name]
>                      +--rw oam-protocols
>                      |  +--rw bfd
>                      |  +--rw cfm
>                      |  +--rw twamp
> Rather than the example quoted in Y-34 (http://www.ietf.org/mail-archive/web/netmod/current/msg12986.html)
>   +--rw device
>          +--rw info
>          |  +--rw device-type?   enumeration
>          +--rw hardware
>          +--rw interfaces
>          |  +--rw interface* [name]
>          |     ...
>          +--rw qos
> 
> So In my understanding, device model is more focusing on discussing organizing different type of models in a
>  comprehensive structure. For the same type of models(e.g., OAM type), we can find common structure to make different technology specific OAM models with same type (i.e.,OAM type)work together. The relationship between these models are described as several models are extension to one base model.
> 
> The debate on Y-34 is about whether we should add new top level node (device) on top of another existing top level node(e.g., interface). Device and interface are of two different types,
> 
> One interesting proposal raised by Lada in http://www.ietf.org/mail-archive/web/netmod/current/msg12986.html is:
> "Extend YANG so that a *specific* schema tree can be grafted at a given data node."
> One example given by Lada in the discussion is:
> "
> I believe there are other use cases in the existing modules. For
> example, the ietf-routing module could simply define the data model for
> a single routing instance (i.e. without "routing-instance" list at the
> top), and it can be then used without changes on simple devices, and
> more complex router implementations can graft it as a subtree under
> "routing-instance", "networking-instance" or whatever.
> 
> "
> I think this is something more relevant to what we are doing. I think we should consider to take this approach.
> 
> Cheers.
> 
>> On Aug 24, 2015, at 6:10 PM, Tom Taylor <[email-masked]> wrote:
>> 
>> It comes from making the making the draft Standards Track. If you claim to implement the ultimate RFC, this is a logical consequence, just as for any other Standards Track RFC.
>> 
>> Tom Taylor
>> 
>> On 24/08/2015 8:41 PM, Mahesh Jethanandani wrote:
>>> Agree with Greg.
>>> 
>>> I have particular concern about this statement in the draft:
>>> 
>>> All implementations that follow the YANG framework presented in this
>>>   document MUST implement the generic YANG model presented here.
>>> 
>>> 
>>> This seems to stipulate a requirement that neither YANG as a language
>>> nor any existing technology requires, except maybe CFM itself. Where
>>> is this stipulation coming from and why is it a MUST?
>>> 
>> 
>> _______________________________________________
>> Lime mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/lime
> 
> Mahesh Jethanandani
> [email-masked]
> 
> 
> 
> _______________________________________________
> Lime mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lime
> _______________________________________________
> Lime mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lime