Subject: [netmod] Interface Extensions YANG draft

From: Robert Wilton <[email-masked]>
Date: Wed, 08 Jul 2015 17:11:13 +0100

Hi,

I have submitted a new draft for provides several augmentations to the 
ietf if:interfaces to define configuration YANG for basic interface 
parameters that are commonly supported on network devices.  E.g. it is 
includes leaves such as bandwidth, carrier delay, dampening, loopback, 
mtu, & sub-interface parent ref, and configurable interface MAC 
addresses.  I am hoping that this draft could be adopted and 
standardized by the netmod WG.

https://datatracker.ietf.org/doc/draft-wilton-netmod-intf-ext-yang/

Any comments or feedback is appreciated.

Potential points of interest/discussion may be:
  - Is it acceptable to define standard YANG for features that are not 
backed by any formal standard if they are commonly implemented?
  - We've tried to restrict the leaves to just the interface types 
(using when if:type = ...) that the configuration applies to rather than 
adding them to all interfaces.  Feedback would be welcome on whether 
this approach is a good idea/maintainable.
  - For MTU, I've defined two different MTU leaves because devices 
program interface MTU in different ways based on whether the configured 
MTU value includes the L2 header overhead or not.  Is this a reasonable 
approach?

Thanks,
Rob

---

From: wangzitao <[email-masked]>
Date: Mon, 13 Jul 2015 08:42:24 +0000

Dear Authors,

I've read your draft-wilton-netmod-intf-ext-yang-00 and have a question: 
What is the difference between encaps-type in your yang model and interface types in RFC7224?

I also read your draft-wilton-netmod-intf-vlan-yangwhich augment the if-cmn as:

 augment /if:interfaces/if:interface/if-cmn:encapsulation/
 if-cmn:encaps-type:
      +--:(vlan)
         +--rw vlan
            +--rw tags
            ......
  
  But the vlan type have already defined in the RFC7224:

     identity l2vlan {
       base iana-interface-type;
       description
         "Layer 2 Virtual LAN using 802.1Q.";
     }
     identity l3ipvlan {
       base iana-interface-type;
       description
         "Layer 3 Virtual LAN using IP.";
     }
     identity l3ipxvlan {
       base iana-interface-type;
       description
         "Layer 3 Virtual LAN using IPX.";
     }
  
  Why not reuse the vlan types definding in RFC7224? And it may simplify the augment target path such as:

    augment /if:interfaces/if:interface:
         +--rw encaps-type   identityref
         +--rw vlan
            +--rw tags
            ......

Best Regards!
-Michael

-----邮件原件-----
发件人: netmod [mailto:[email-masked]] 代表 Robert Wilton
发送时间: 2015年7月9日 0:11
收件人: [email-masked]
主题: [netmod] Interface Extensions YANG draft

Hi,

I have submitted a new draft for provides several augmentations to the ietf if:interfaces to define configuration YANG for basic interface parameters that are commonly supported on network devices.  E.g. it is includes leaves such as bandwidth, carrier delay, dampening, loopback, mtu, & sub-interface parent ref, and configurable interface MAC addresses.  I am hoping that this draft could be adopted and standardized by the netmod WG.

Potential points of interest/discussion may be:
  - Is it acceptable to define standard YANG for features that are not backed by any formal standard if they are commonly implemented?
  - We've tried to restrict the leaves to just the interface types (using when if:type = ...) that the configuration applies to rather than adding them to all interfaces.  Feedback would be welcome on whether this approach is a good idea/maintainable.
  - For MTU, I've defined two different MTU leaves because devices program interface MTU in different ways based on whether the configured MTU value includes the L2 header overhead or not.  Is this a reasonable approach?

Thanks,
Rob

_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Robert Wilton <[email-masked]>
Date: Mon, 13 Jul 2015 12:24:28 +0100

Hi Michael,

Thank you for your comments and review.

I think that the definition of interface type is a bit vague in that 
there is a long list of interface types that seem to apply at quite a 
few different OSI layers!

But in brief, the way that I perceive interface type is as a static 
property of an interface, fixed when an interface is created, that 
defines the flavour of an interface.  Where appropriate I would normally 
relate the ifType to the underlying hardware (e.g. POS, Ethernet, ATM, 
etc), but there are other software interfaces where the interface type 
is defining a higher level construct (e.g. a tunnel, or sub-interface, 
or LAG group interface).

My definition of encapsulation is that it provided a generic container 
for holding layer-2 related header information, where that is 
configurable.  In the model that I have defined so far I have only 
defined the encapsulation node for Ethernet/VLAN sub-interfaces, but the 
intention is that it would be augmented for cHDLC, PPP, FR and ATM.  The 
example is potentially better illustrated for POS interfaces where the 
choice of encapsulation can be configured.

So, if you take a POS interface as an example, then I would expect that 
the ifType would be fixed as ifType:pos, but the encapsulation of that 
interface could be cHDLC, PPP or Frame Relay.  The layer 2 encapsulation 
information (such as timers, keepalive settings, crc settings, FR 
circuit ids) would live under the datalink protocol specific 
encapsulation node.  The encapsulation node itself can be used to 
determine what layer 2 encapsulation is being used.

Of course you could put ppp/chdlc/fr under separate containers, but it 
makes it slightly harder to ensure that an interface only has a single 
encapsulation configured.  Although you could add a must statement to 
restrict the allowed encapsulations to those known today, it doesn't 
extend to other encaps types added in future. Having a choice statement 
effectively enforces the restriction that there can be only one 
encapsulation on an interface for you.

Does that alleviate your concern?

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 13 Jul 2015 13:30:06 +0200

Hi,

did we not solve this problem with interface layering (or stacking) in
the MIB world? If so, why would we depart from that model?

/js

On Mon, Jul 13, 2015 at 12:24:28PM +0100, Robert Wilton wrote:
> >mtu, & sub-interface parent ref, and configurable interface MAC addresses. 
> >I am hoping that this draft could be adopted and standardized by the 
> >netmod WG.
> >
> >   - We've tried to restrict the leaves to just the interface types (using 
> >   when if:type = ...) that the configuration applies to rather than 

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Robert Wilton <[email-masked]>
Date: Mon, 13 Jul 2015 15:43:59 +0100

Hi Juergen,

If I understand your comment correctly, this would imply that you have a 
separate interface representing the basecaps independently from the 
interface itself.  As far as I know this isn't widely done even if it 
supported by ifStack.

More naturally it feels that the interface layering is more useful to 
represent LAG interfaces or VLAN sub-interfaces, which can be done, but 
section 3.3 Interface Layering from YANG Interface Management indicates 
that the layering attributes are read only, so you still need separate 
configuration leaves to set up the parent<->child relationship.

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 13 Jul 2015 16:52:29 +0200

> interface itself.  As far as I know this isn't widely done even if it 

Whatever basecaps are...
 
> configuration leaves to set up the parent<->child relationship.

See Appendix C in RFC 7223 how this was envisioned to be done.

/js

---

From: Robert Wilton <[email-masked]>
Date: Mon, 13 Jul 2015 18:02:19 +0100

Hi Juergen,

>> interface itself.  As far as I know this isn't widely done even if it
Apologies, I was lax with my terminology - I meant the datalink layer 
encapsulation (e.g. PPP, cHDLC, etc for a Packet-over-Sonet interface).
> See Appendix C in RFC 7223 how this was envisioned to be done.
Yes, I believe that the approach that we have proposed is broadly 
consistent with that, but defined in a slightly more generic way and 
without the need for the vlan-tagging leaf on the parent.

However, in the model that we have proposed, it is likely that the 
"parent-interface" interface-ref that we define on a sub-interface has 
to be an optional leaf because you are not allowed to augment with a 
mandatory node.  So, this would come down to implementations being 
expected to reject sub-interface configurations if the parent-interface 
hasn't been correctly populated.  In some ways this is not ideal - but I 
can appreciate why the YANG rules are how they are.

Thanks,
Rob

---

From: wangzitao <[email-masked]>
Date: Tue, 14 Jul 2015 07:59:17 +0000

Rob,

What makes me confuse before is that why not directly use the encapsulation type in iana-if-type? The iana-if-type also provide a lot of encapsulation type such as PPP, Frame Relay, etc. 
Now I understood a bit. You want to provide an explicit encapsulation information. For example, for pos interface, you may define the yang model as:

  augment "/if:interfaces/if:interface/if-cmn:encapsulation/" +
             "if-cmn:encaps-type" {
       when "../../if:type = 'ianaift:pos'" {
       case PPP{
          foo;}
         .....

Which indicate this is a pos interface and it encapsulation is PPP... 
Is my understood right?

Best Regards!
-Michael

-----邮件原件-----
发件人: Robert Wilton [mailto:[email-masked]] 
发送时间: 2015年7月13日 19:24
收件人: wangzitao; [email-masked]
主题: Re: [netmod] Interface Extensions YANG draft

Hi Michael,

I think that the definition of interface type is a bit vague in that there is a long list of interface types that seem to apply at quite a few different OSI layers!

But in brief, the way that I perceive interface type is as a static property of an interface, fixed when an interface is created, that defines the flavour of an interface.  Where appropriate I would normally relate the ifType to the underlying hardware (e.g. POS, Ethernet, ATM, etc), but there are other software interfaces where the interface type is defining a higher level construct (e.g. a tunnel, or sub-interface, or LAG group interface).

My definition of encapsulation is that it provided a generic container for holding layer-2 related header information, where that is configurable.  In the model that I have defined so far I have only defined the encapsulation node for Ethernet/VLAN sub-interfaces, but the intention is that it would be augmented for cHDLC, PPP, FR and ATM.  The example is potentially better illustrated for POS interfaces where the choice of encapsulation can be configured.

So, if you take a POS interface as an example, then I would expect that the ifType would be fixed as ifType:pos, but the encapsulation of that interface could be cHDLC, PPP or Frame Relay.  The layer 2 encapsulation information (such as timers, keepalive settings, crc settings, FR circuit ids) would live under the datalink protocol specific encapsulation node.  The encapsulation node itself can be used to determine what layer 2 encapsulation is being used.

Of course you could put ppp/chdlc/fr under separate containers, but it makes it slightly harder to ensure that an interface only has a single encapsulation configured.  Although you could add a must statement to restrict the allowed encapsulations to those known today, it doesn't extend to other encaps types added in future. Having a choice statement effectively enforces the restriction that there can be only one encapsulation on an interface for you.

Thanks,
Rob

---

From: Robert Wilton <[email-masked]>
Date: Tue, 14 Jul 2015 11:52:21 +0100

Hi Michael,

Yes, your understanding is right.  I've extended your example to 
hopefully give a bit more clarity.

In the PPP module:

   augment "/if:interfaces/if:interface/if-cmn:encapsulation/" +
              "if-cmn:encaps-type" {
        when "../../if:type = 'ianaift:pos'" { // + any other interface types that PPP is supported on.
        case PPP {
           container PPP {
              // All PPP specific configuration goes here.
           }

In the cHDLC module:

   augment "/if:interfaces/if:interface/if-cmn:encapsulation/" +
              "if-cmn:encaps-type" {
        when "../../if:type = 'ianaift:pos'" { // + any other interface types that cHDLC is supported on.
        case CHDLC {
           container CHDLC {
              // All CHDLC specific configuration goes here.
           }

In the Frame Relay module: ... similar to above ...

Our aim is:
  (1) to have a well defined node that indicates what the layer 2 
encapsulation is for any interfaces where it may changed/configured.
  (2) to ensures that an interface only has a single primary layer 2 
encapsulation (i.e. an interface cannot be both encaps PPP and CHDLC at 
the same time).
  (3) to provide a container to store the layer 2 encapsulation 
information that reflects the encapsulation that is in effect. (I.e. the 
model prevents you having PPP configuration on an interface with a CHDLC 
encapsulation.)

Thanks,
Rob

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 14 Jul 2015 09:21:30 -0700

Robert,

I have read your draft and consider it useful for folks who are trying to use/configure/monitor particular characteristics of a physical interface. While it is an extension of the interfaces module, a lot of modules are extensions of the interface module. A more appropriate name would probably help convey the contents of the module. How about physical-interface-extensions or phys-intr-ext for short?

More comments on the draft.

3.2.

Is there a counter kept for the actual short transition changes that were suppressed?

3.6

The general suggestion in YANG is to provide for one way to do things, and leave other ways of specifying or configuring to extensions/deviations etc. With that in mind, I would think keeping one leaf for MTU that is the max. size of the layer 2 frame including header and payload would make sense.

4.

I am not a particular fan of creating yet another module for ethernet-like interfaces, when I assume there is going to be a ethernet-interface module. Is there something in this module that cannot be minimally represented by a more general IEEE ethernet-interface module?

Thanks.

> On Jul 8, 2015, at 9:11 AM, Robert Wilton <[email-masked]> wrote:
> 
> Hi,
> 

Mahesh Jethanandani
[email-masked]

---

From: Robert Wilton <[email-masked]>
Date: Tue, 14 Jul 2015 18:29:08 +0100

Hi Mahesh,

Thanks for the comments.  Please see inline ...

On 14/07/2015 17:21, Mahesh Jethanandani wrote:
> Robert,
>
> I have read your draft and consider it useful for folks who are trying 
> to use/configure/monitor particular characteristics of a physical 
> interface. While it is an extension of the interfaces module, a lot of 
> modules are extensions of the interface module. A more appropriate 
> name would probably help convey the contents of the module. How about 
> physical-interface-extensions or phys-intr-ext for short?

Yes, I agree that a better name would be helpful, and definitely welcome 
suggestions.  The problem is that the module doesn't just apply to 
physical interfaces.  Quite a lot of the properties apply to any 
interface on a router/switch, and some of the properties I would think 
could apply to any network interface (e.g. MTU). Perhaps something 
related to lower-layer-interface-extensions?

> Is there a counter kept for the actual short transition changes that 

Yes, there should be.  I had initially concentrated on the config side, 
but probably operation data needs to be considered as well.

>
>
> 3.6
>
> The general suggestion in YANG is to provide for one way to do things, 
> and leave other ways of specifying or configuring to 
> extensions/deviations etc. With that in mind, I would think keeping 
> one leaf for MTU that is the max. size of the layer 2 frame including 
> header and payload would make sense.
OK.  Yes, I think that I'm coming to the same conclusion: Although 
having a single MTU value will make it harder to implement for some 
vendors, it makes it easier for users of the YANG module.

>
> 4.
>
> I am not a particular fan of creating yet another module for 
> ethernet-like interfaces, when I assume there is going to be a 
> ethernet-interface module. Is there something in this module that 
> cannot be minimally represented by a more general IEEE 
> ethernet-interface module?

I don't envisage there needing to be any additional configuration in the 
Ethernet-like module beyond what is already there - possibly some 
Ethernet framing related statistics.

There are a few reasons that I put this in a separate module to ethernet:
  1) It doesn't just apply to 802.3 Ethernet interfaces, but any 
interfaces that use Ethernet framing.
  2) I wasn't sure whether the IEEE 802.3 WG would want to standardize a 
module that covers other interface types beyond native Ethernet.
  3) There is already an etherlike.mib (although that only covers stats 
that applies to any Ethernet framed interfaces).

Is your primary concern over the fact that this module is too small to 
justify its independent existence?

Thanks,
Rob

>
> Thanks.
>
>> On Jul 8, 2015, at 9:11 AM, Robert Wilton <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hi,
>>
>> I have submitted a new draft for provides several augmentations to 
>> the ietf if:interfaces to define configuration YANG for basic 
>> interface parameters that are commonly supported on network devices. 
>>  E.g. it is includes leaves such as bandwidth, carrier delay, 
>> dampening, loopback, mtu, & sub-interface parent ref, and 
>> configurable interface MAC addresses.  I am hoping that this draft 
>> could be adopted and standardized by the netmod WG.
>>
>> (using when if:type = ...) that the configuration applies to rather 
>> than adding them to all interfaces.  Feedback would be welcome on 
>> whether this approach is a good idea/maintainable.
>> program interface MTU in different ways based on whether the 
>> configured MTU value includes the L2 header overhead or not.  Is this 
>> a reasonable approach?
>>
>> Thanks,
>> Rob
>>
> [email-masked] <mailto:[email-masked]>
>
>
>
>
>

---

From: Qin Wu <[email-masked]>
Date: Wed, 15 Jul 2015 01:57:43 +0000

>> represent LAG interfaces or VLAN sub-interfaces, which can be done, 

[Qin]: Is your proposal about interface extension for L2 sub-interface?
>> but section 3.3 Interface Layering from YANG Interface Management 
>> indicates that the layering attributes are read only, so you still 
>> need separate configuration leaves to set up the parent<->child relationship.

[Qin]: Based on RFC7223, only state leaves are required to represent interface
layering hierarchy, if my understanding is correct.

> See Appendix C in RFC 7223 how this was envisioned to be done.
Yes, I believe that the approach that we have proposed is broadly consistent with that, but defined in a slightly more generic way and without the need for the vlan-tagging leaf on the parent.

However, in the model that we have proposed, it is likely that the "parent-interface" interface-ref that we define on a sub-interface has to be an optional leaf because you are not allowed to augment with a mandatory node.  So, this would come down to implementations being expected to reject sub-interface configurations if the parent-interface hasn't been correctly populated.  In some ways this is not ideal - but I can appreciate why the YANG rules are how they are.

[Qin]: How is "parent-interface" define in the interface extensions different from base-interface defined in the example of Appendix C in RFC7223? It looks you both using "interface-ref" types to reference lower layers.

Thanks,
Rob

---

From: Robert Wilton <[email-masked]>
Date: Wed, 15 Jul 2015 10:40:21 +0100

Hi Qin,

> [Qin]: Is your proposal about interface extension for L2 sub-interface?
Not just L2 sub-interfaces.

draft-wilton-netmod-intf-ext-yang-00 covers general interface properties 
that are common to many interface types on network devices.
I.e. (from the draft) it provides the following augmentations to 
if:interfaces:

    o  A bandwidth configuration leaf to specify the bandwidth available
       on an interface to control routing metrics.

    o  A carrier delay feature used to provide control over short lived
       link state flaps.

    o  An interface link state dampening feature that is used to provide
       control over longer lived link state flaps.

    o  An encapsulation container and extensible choice statement for use
       by any interface types that allow for configurable L2
       encapsulations.

    o  A loopback configuration leaf that is primarily aimed at loopback
       at the physical layer.

    o  MTU configuration leaves applicable to all packet/frame based
       interfaces.

    o  A transport layer leaf to indicate whether the interface handles
       traffic at L1, L2 or L3.

    o  A parent interface leaf useable for all types of sub-interface
       that are children of parent interfaces.

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.

I have also posted a separate draft 
(draft-wilton-netmod-intf-vlan-yang-00) that augments the encapsulation 
container described above, and uses the parent interface leaf to define 
how traffic is matched and classified to layer-2 and layer-3 sub-interfaces.

> layering hierarchy, if my understanding is correct.
My interpretation of RFC7223 is a bit different, it states:
"

    There is no generic mechanism for how an interface is configured to
    be layered on top of some other interface.  It is expected that
    interface-type-specific models define their own data nodes for
    interface layering by using "interface-ref" types to reference
    lower layers.
"

I.e. you need a model specific way to specify the relationship between 
the nodes.

E.g. parent-interface is a such configuration item.  This leaf is 
needed/useful for several reasons:
(1) To cleanly specify the relationship between the two interfaces. If 
you don't have this leaf then you would have no way of specifying the 
relationship between a child sub-interface and its parent is unless it 
is possible to infer that from the name of the child sub-interface.  
Whilst this is possible on the sub-interface naming scheme for some 
network devices, I don't think that this is universally true, and 
probably shouldn't be relied on.
(2) If you want to define 'must' statements on the model , e.g. to 
ensure that a particular VLAN Id is only used on a single child 
sub-interface of a given parent, then having the parent leaf defined in 
the config namespace makes this easier.  I don't think that a must 
statement is allowed to check against operational leaves, so it either 
needs a node in the config namespace, or again would have to extract it 
from the sub-interface name (if that is even possible).

> [Qin]: How is "parent-interface" define in the interface extensions different from base-interface defined in the example of Appendix C in RFC7223? It looks you both using "interface-ref" types to r…
They are pretty much equivalent.  The main difference is that the 
Appendix C requires a "vlan-tagging" leaf to be configured on the parent 
interface, whereas the "parent-interface" leaf that I have defined does 
not, but has the restriction that it cannot be marked as being mandatory.

Thanks,
Rob

---

From: Qin Wu <[email-masked]>
Date: Wed, 15 Jul 2015 11:21:35 +0000

-----邮件原件-----
发件人: Robert Wilton [mailto:[email-masked]] 
发送时间: 2015年7月15日 17:40
收件人: Qin Wu; wangzitao; [email-masked]
主题: Re: [netmod] Interface Extensions YANG draft

Hi Qin,

On 15/07/2015 02:57, Qin Wu wrote:
>>> More naturally it feels that the interface layering is more useful 
>>> to represent LAG interfaces or VLAN sub-interfaces, which can be 
>>> done,

draft-wilton-netmod-intf-ext-yang-00 covers general interface properties that are common to many interface types on network devices.
I.e. (from the draft) it provides the following augmentations to
if:interfaces:

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.

I have also posted a separate draft
(draft-wilton-netmod-intf-vlan-yang-00) that augments the encapsulation container described above, and uses the parent interface leaf to define how traffic is matched and classified to layer-2 and layer-3 sub-interfaces.

[Qin]: I will take a look at it and thanks for the pointer.

> [Qin]: Based on RFC7223, only state leaves are required to represent 
> interface layering hierarchy, if my understanding is correct.

I.e. you need a model specific way to specify the relationship between the nodes.

[Qin]: that's my misunderstanding on RFC7223, sorry about that, by reading appendix C of RFC7223,
I believe what RFc7223 propose is to define parent interface or base interface in the interface extension model to specify relationship between interfaces in two different layers.

E.g. parent-interface is a such configuration item.  This leaf is needed/useful for several reasons:
(1) To cleanly specify the relationship between the two interfaces. If you don't have this leaf then you would have no way of specifying the relationship between a child sub-interface and its parent is unless it is possible to infer that from the name of the child sub-interface.  
Whilst this is possible on the sub-interface naming scheme for some network devices, I don't think that this is universally true, and probably shouldn't be relied on.

[Qin]:Yes, parent-interface is needed just like why base interface is needed in the interface extension example described in Appendix C of RFC7223.

(2) If you want to define 'must' statements on the model , e.g. to ensure that a particular VLAN Id is only used on a single child sub-interface of a given parent, then having the parent leaf defined in the config namespace makes this easier.  I don't think that a must statement is allowed to check against operational leaves, so it either needs a node in the config namespace, or again would have to extract it from the sub-interface name (if that is even possible).

> [Qin]: How is "parent-interface" define in the interface extensions different from base-interface defined in the example of Appendix C in RFC7223? It looks you both using "interface-ref" types to r…
They are pretty much equivalent.  The main difference is that the Appendix C requires a "vlan-tagging" leaf to be configured on the parent interface, whereas the "parent-interface" leaf that I have defined does not, but has the restriction that it cannot be marked as being mandatory.

[Qin]: I can see this subtle difference between two but can't weigh one is better than the other.

Thanks,
Rob

---

From: Robert Wilton <[email-masked]>
Date: Wed, 15 Jul 2015 15:14:58 +0100

Hi Qin,

Please see inline ...

On 15/07/2015 12:21, Qin Wu wrote:
> <snip>
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

---

From: Qin Wu <[email-masked]>
Date: Thu, 16 Jul 2015 12:29:06 +0000

-----邮件原件-----
发件人: Robert Wilton [mailto:[email-masked]] 
发送时间: 2015年7月15日 22:15
收件人: Qin Wu; wangzitao; [email-masked]
主题: Re: [netmod] Interface Extensions YANG draft

Hi Qin,

Please see inline ...

> [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. B…
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:

[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?

[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