-----邮件原件----- 发件人: Robert Wilton [mailto:[email protected]] 发送时间: 2015年7月15日 22:15 收件人: Qin Wu; wangzitao; [email protected] 主题: Re: [netmod] Interface Extensions YANG draft
Hi Qin, Please see inline ... On 15/07/2015 12:21, Qin Wu wrote: > -----邮件原件----- > 发件人: Robert Wilton [mailto:[email protected]] > 发送时间: 2015年7月15日 17:40 > 收件人: Qin Wu; wangzitao; [email protected] > 主题: 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. [Qin]: If there is any overlap, it is better to fix this in the first place. 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. [Qin]: I am not convincing that l2-mtu is common to 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. [Qin]: This is what draft-wwz-netmod-yang-tunnel-cfg proposed, I believe. - encapsulation method could potentially augment from the encapsulation choice node that has been defined in draft-wilton-netmod-intf-ext-yang-00 [Qin]: I think encapsulation method is one property that is common to all tunnel interface, is encapsulation method common to both VLAN interface and Tunnel interface? - MTU would be defined by l2-mtu in draft-wilton-netmod-intf-ext-yang-00 [Qin]: what about IP MTU, suppose tunnel interface is defined as Layer 3 interface, IP MTU should be used. - QoS I would suggest would be defined by DiffServ or other QoS feature implementation. [Qin]: Agree with you. 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. [Qin]: Agree, I think at first we should understand the clear relation between subinterface, VLAN interface and Tunnel interface, Loopback interface and then we can decide what kind of model structure is more fit for tunnel interface. Thanks, Rob _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
