Re: [netmod] Interface Extensions YANG draft

[Robert Wilton <[e-mail]>]

Hi Qin,

Please see inline ...

On 15/07/2015 12:21, Qin Wu wrote:
> -----邮件原件-----
> 发件人: Robert Wilton [mailto:[e-mail]]
> 发送时间: 2015年7月15日 17:40
> 收件人: Qin Wu; wangzitao; [e-mail]
> 主题: Re: [netmod] Interface Extensions YANG draft
>
> Hi Qin,
>
> <snip>
>
> The parent interface leaf is just one of the augmentations and is effectively the minimal information that you need to have a logical sub-interface.
>
> [Qin]: I see, sounds like tunnel interface defined in the draft-wwz-netmod-yang-tunnel-cfg-00 also intends to support several similar properties which make me believe you guys has some same goal. Both augment if:interface with interface specific, I am wondering which one draft has better model design, one is to place all common properties in one place while the other is distribute common properties in several places within if:interface.
Yes, there is some overlap here, and I agree that there is a question of 
direction.  It is the requirement to use XML namespaces that made me 
think that defining a given property in single place that spans across 
interfaces is easier to use.

If you take the MTU lead as an example - this has been defined by both 
models.

If you follow the way that I have proposed then the path 
"/if:interfaces/if:interface[if:name = XXX]/if-cmn:l2-mtu" is valid for 
any interface (that implements the interfaces-common YANG module).  E.g. 
a YANG client has a well defined path to access the MTU item for any 
interface.

An alternative approach, is for each type of interface to define an mtu 
leaf for that given interface type.  With a bit of effort you could get 
the MTU node to have the same name and semantics for all interface 
types, but it would always have a different namespace for each interface 
type.  Hence, to write a client function that generically gets/sets the 
MTU on an interface you need to know the interface type to be able to 
map it to the appropriate namespace that the MTU leaf has been defined 
in.  I thought that this would be awkward and hence better to just 
define it in a single place.

So if an approach like draft-wilton-netmod-intf-ext-yang-00 is agreed 
then I think that it might somewhat change the structure of 
draft-wwz-netmod-yang-tunnel-cfg-00 in the following way:
  - ip-address would be defined by the ip-cfg YANG module.
  - encapsulation method could potentially augment from the 
encapsulation choice node that has been defined in 
draft-wilton-netmod-intf-ext-yang-00
  - MTU would be defined by l2-mtu in draft-wilton-netmod-intf-ext-yang-00
  - QoS I would suggest would be defined by DiffServ or other QoS 
feature implementation.

I.e. in essence I would think that perhaps gen-tunnel should only define 
properties that are strictly common to all tunnel interfaces, but that 
are not more widely common across all/most interfaces.

Thanks,
Rob