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 : 010-58552347
Mobile: 13301168517
-----Original Message-----
From: Qin Wu [mailto:[email protected]]
Sent: Wednesday, July 15, 2015 7:38 PM
To: Aijun Wang; [email protected]
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:[email protected]]
发送时间: 2015年7月15日 15:43
收件人: Qin Wu; [email protected]
主题: 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:[email protected]]
Sent: Wednesday, July 15, 2015 11:27 AM
To: Aijun Wang; [email protected]
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:[email protected]] 代表 Aijun Wang
发送时间: 2015年7月6日 12:07
收件人: [email protected]
主题: [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: [email protected] [mailto:[email protected]]
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
[email protected]
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 <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
Mahesh Jethanandani
[email protected]
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
--- End Message ---
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
