Re: [netmod] New Version Notification for draft-wwz-netmod-yang-tunnel-cfg-00.txt

["Aijun Wang" <[e-mail]>]

Hi, Qin,

I think the answer from Robert to Mahesh on July 14(please see the detail on the attached mail) best describes the key point of " draft-wilton-netmod-intf-ext-yang-00":
".... 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?....".

The above statement show clearly the main concern of " draft-wilton-netmod-intf-ext-yang-00", which is different from the " draft-wwz-netmod-yang-tunnel-cfg-00.txt" . The latter draft concern mainly the "upper-layer-interface-extensions".  Some characteristics may have same name, but different denotation(for example "MTU", it has different value in lower-layer-interface and upper-layer-interface). 

>From the model user viewpoint, it is benefit to separate the lower-layer-interface and upper-layer-interface into two yang models, we should clarify with deep consideration the belonging of the seeming "over-lapping" characteristics, although there is not much of them from these two drafts now.


Aijun Wang

China Telecom Corporation Limited Beijing Research Institute 
Intelligent Network Product Line

Tel : [phone]
Mobile:  [phone]





-----Original Message-----
From: Qin Wu [mailto:[e-mail]] 
Sent: Wednesday, July 15, 2015 7:38 PM
To: Aijun Wang; [e-mail]
Subject: RE: [netmod] New Version Notification for draft-wwz-netmod-yang-tunnel-cfg-00.txt

Aijun:
Please see my reply to Robert, I am afraid draft-wilton-netmod-intf-ext-yang-00 is not limited to describe common l2 characteristic of the interface.
Then tunnel interface in draft-wwz-netmod-yang-tunnel-cfg-00 and interface extension proposed in draft-wilton-netmod-intf-ext-yang-00 share some Common properties, so what is the better model design? Place all the properties in one place under tunnel interface or move these properties in In the same level as other properties defined under if:interface?

-Qin
-----邮件原件-----
发件人: Aijun Wang [mailto:[e-mail]]
发送时间: 2015年7月15日 15:43
收件人: Qin Wu; [e-mail]
主题: RE: [netmod] New Version Notification for draft-wwz-netmod-yang-tunnel-cfg-00.txt

Hi, Qin:

Thanks for your comments first.
Below is my answer to your question:
1. As you pointed out, " draft-wilton-netmod-intf-ext-yang-00" focuses mainly on the common layer 2 characteristic of one interface, it augments the ietf: if-interface yang model and compensates the characteristic of one physical interface.
2. Draft "draft-wwz-netmod-yang-tunnel-cfg-00.txt" designs the general tunnel interface model on top of the physical interface model, It covers and references the characteristics defined both in basic ietf: if-interface and its augment layer2 characteristic model, for example that defined in "draft-wilton-netmod-intf-ext-yang-00". 

Do the above descriptions clarify the relationship between them?

Best Regards.

Aijun Wang

China Telecom Corporation Limited Beijing Research Institute Intelligent Network Product Line

-----Original Message-----
From: Qin Wu [mailto:[e-mail]]
Sent: Wednesday, July 15, 2015 11:27 AM
To: Aijun Wang; [e-mail]
Subject: RE: [netmod] New Version Notification for draft-wwz-netmod-yang-tunnel-cfg-00.txt

Authors:
I think this draft will be useful when we consider to choose and configure large number of different technology specific tunnels that share a lot of common properties.
One question I have here is how this draft is related to draft-wilton-netmod-intf-ext-yang-00?
If my understanding is correct, your draft is about interface extension for tunneling management. draft-wilton-netmod-intf-ext-yang-00 focuses on interface extension for L2 sub-interface.
But two draft follows two different model design, you specify common properties within tunnel container while draft-wilton-netmod-intf-ext-yang-00 specifies common properties directly within if:interface.

-Qin
-----邮件原件-----
发件人: netmod [mailto:[e-mail]] 代表 Aijun Wang
发送时间: 2015年7月6日 12:07
收件人: [e-mail]
主题: [netmod] New Version Notification for draft-wwz-netmod-yang-tunnel-cfg-00.txt

Hi, all:

We submitted one new draft (https://tools.ietf.org/html/draft-wwz-netmod-yang-tunnel-cfg-00) that described one general model for the tunnel services used within service provider network. It summaries the common characteristic of the current various tunnel protocols and can be used as one fundamental model for the specific tunnel technology. 
Any feedback is welcome.

Best Regard.



-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Friday, July 03, 2015 4:21 PM
To: Zitao Wang; Yan Zhuang; Aijun Wang; Zhuangyan; Zitao Wang; Aijun Wang
Subject: New Version Notification for draft-wwz-netmod-yang-tunnel-cfg-00.txt


A new version of I-D, draft-wwz-netmod-yang-tunnel-cfg-00.txt
has been successfully submitted by Zitao Wang and posted to the IETF repository.

Name:		draft-wwz-netmod-yang-tunnel-cfg
Revision:	00
Title:		YANG Data Model for Tunnel Management
Document date:	2015-07-03
Group:		Individual Submission
Pages:		21
URL:            https://www.ietf.org/internet-drafts/draft-wwz-netmod-yang-tunnel-cfg-00.txt
Status:         https://datatracker.ietf.org/doc/draft-wwz-netmod-yang-tunnel-cfg/
Htmlized:       https://tools.ietf.org/html/draft-wwz-netmod-yang-tunnel-cfg-00


Abstract:
   This document defines a YANG data model for the configuration and
   management of generic tunnels.  The data model includes configuration
   data and state data.  And it can serve as a base model which is
   augmented with technology-specific details in other, more specific
   tunnel models.

                                                                                  


Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


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

--- Begin Message ---

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?




More comments on the draft.

3.2.

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


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 <[e-mail]> 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.

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

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



Mahesh Jethanandani
[e-mail]

--- End Message ---