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

[wangzitao]

Yes, this draft is talking about interface extension with tunnel management.
Tunnel is implemented as a virtual interface which provides a simple interface 
for configuration. And the tunnel interface is independent of underlying 
transport protocols to be used. 
The common properties we proposed is common to all the technology specific 
tunnels model, but we are not saying they are common to all the interface 
specific models.

As described in RFC7223, There is no generic mechanism for how an interface is 
configured to be layered on top of some other interface. That is why we put all 
the common properties under technology independent tunnel model(i.e.,interface 
specific model).

Best Regards!
-Michael

-邮件原件-
发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Qin Wu
发送时间: 2015年7月15日 11:27
收件人: Aijun Wang; netmod@ietf.org
主题: 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:netmod-boun...@ietf.org] 代表 Aijun Wang
发送时间: 2015年7月6日 12:07
收件人: netmod@ietf.org
主题: [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: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Qin Wu]

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:netmod-boun...@ietf.org] 代表 Aijun Wang
发送时间: 2015年7月6日 12:07
收件人: netmod@ietf.org
主题: [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: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Interface Extensions YANG draft

[Qin Wu]

>> More naturally it feels that the interface layering is more useful to 
>> 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


>
> /js
>

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] example in draft-ietf-netmod-syslog-model-04

[Ladislav Lhotka]

> On 14 Jul 2015, at 19:21, Clyde Wildes (cwildes)  wrote:
> 
> Lada,
> 
> I would prefer a specification that declares the "all" intent instead of 
> relying on "debug" meaning all messages. A number syslog implementations 
> specify a severity of "all". Example: rsyslog - 
> http://www.rsyslog.com/doc/v8-stable/configuration/filters.html.
> 
> I used the union approach because, in an earlier review, Jan Lindblad 
> suggested it as a simple method to add all without compromising the RFC 
> definition of Severity. His point was that adding a choice is a complication.

OK, I just expressed my opinion. I also note that RFC 5424 says: "Facility and 
Severity values are not normative but often used.  They are described in the 
following tables for purely informational purposes.” So I wonder whether you 
really compromise anything by adding the “all” option.

Lada

> 
> Thanks,
> 
> Clyde
> 
> 
> 
> 
> On 7/14/15, 9:03 AM, "Ladislav Lhotka"  wrote:
> 
>> 
>>> On 14 Jul 2015, at 17:25, Clyde Wildes (cwildes)  wrote:
>>> 
>>> Lada,
>>> 
>>> Thanks for your review.
>>> 
>>> All was not added to the syslogtypes:severity because that would alter the 
>>> definition of severity as specified by RFC 5424 in Table 2 on page 10. I 
>>> agree that it will simplify the model to do so.
>> 
>> The description of the “severity” leaf says:
>> 
>> When severity is specified the default severity comparison is all messages 
>> of the specified severity and greater are logged unless all is specified 
>> which means all severities are requested.
>> 
>> Isn’t then “debug” equivalent to “all”, i.e. is the “all” option really 
>> needed?
>> 
>>> 
>>> Please advise.
>> 
>> I would do a similar thing that you did for facilities: choice between 
>> “severity” (with the type “syslogtypes:severity”) and an empty leaf 
>> "all-severities”.
>> 
>> Lada
>> 
>>> 
>>> Thanks,
>>> 
>>> Clyde
>>> 
>>> 
>>> 
>>> On 7/14/15, 6:57 AM, "netmod on behalf of Ladislav Lhotka" 
>>>  wrote:
>>> 
 Hi,
 
 the example in sec. 4.3 of draft-ietf-netmod-syslog-model-04 is
 invalid: the value of "severity" should be "critical" rather than
 "syslogtypes:critical". Enums are simple strings, not QNames.
 
 Also, I wonder why the type of "severity" is defined (in multiple
 places) like so:
 
type union {
  type syslogtypes:severity;
  type enumeration {
enum all {
  value -1;
  description
"This enum describes the case where all severities 
 are requested.";
}
  }
 
 I think the "all" enum can be simply added to the "syslogtypes:severity"
 enumeration.
 
 Lada
 
 -- 
 Ladislav Lhotka, CZ.NIC Labs
 PGP Key ID: E74E8C0C
 
 ___
 netmod mailing list
 netmod@ietf.org
 https://www.ietf.org/mailman/listinfo/netmod
>> 
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>> 
>> 
>> 
>> 

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Interface Extensions YANG draft

[Robert Wilton]

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 > 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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


Mahesh Jethanandani
mjethanand...@gmail.com 







___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] example in draft-ietf-netmod-syslog-model-04

[Clyde Wildes (cwildes)]

Lada,

I would prefer a specification that declares the "all" intent instead of 
relying on "debug" meaning all messages. A number syslog implementations 
specify a severity of "all". Example: rsyslog - 
http://www.rsyslog.com/doc/v8-stable/configuration/filters.html.

I used the union approach because, in an earlier review, Jan Lindblad suggested 
it as a simple method to add all without compromising the RFC definition of 
Severity. His point was that adding a choice is a complication.

Thanks,

Clyde




On 7/14/15, 9:03 AM, "Ladislav Lhotka"  wrote:

>
>> On 14 Jul 2015, at 17:25, Clyde Wildes (cwildes)  wrote:
>> 
>> Lada,
>> 
>> Thanks for your review.
>> 
>> All was not added to the syslogtypes:severity because that would alter the 
>> definition of severity as specified by RFC 5424 in Table 2 on page 10. I 
>> agree that it will simplify the model to do so.
>
>The description of the “severity” leaf says:
>
>When severity is specified the default severity comparison is all messages of 
>the specified severity and greater are logged unless all is specified which 
>means all severities are requested.
>
>Isn’t then “debug” equivalent to “all”, i.e. is the “all” option really needed?
>
>> 
>> Please advise.
>
>I would do a similar thing that you did for facilities: choice between 
>“severity” (with the type “syslogtypes:severity”) and an empty leaf 
>"all-severities”.
>
>Lada
>
>> 
>> Thanks,
>> 
>> Clyde
>> 
>> 
>> 
>> On 7/14/15, 6:57 AM, "netmod on behalf of Ladislav Lhotka" 
>>  wrote:
>> 
>>> Hi,
>>> 
>>> the example in sec. 4.3 of draft-ietf-netmod-syslog-model-04 is
>>> invalid: the value of "severity" should be "critical" rather than
>>> "syslogtypes:critical". Enums are simple strings, not QNames.
>>> 
>>> Also, I wonder why the type of "severity" is defined (in multiple
>>> places) like so:
>>> 
>>> type union {
>>>   type syslogtypes:severity;
>>>   type enumeration {
>>> enum all {
>>>   value -1;
>>>   description
>>> "This enum describes the case where all severities 
>>>  are requested.";
>>> }
>>>   }
>>> 
>>> I think the "all" enum can be simply added to the "syslogtypes:severity"
>>> enumeration.
>>> 
>>> Lada
>>> 
>>> -- 
>>> Ladislav Lhotka, CZ.NIC Labs
>>> PGP Key ID: E74E8C0C
>>> 
>>> ___
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>
>--
>Ladislav Lhotka, CZ.NIC Labs
>PGP Key ID: E74E8C0C
>
>
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Interface Extensions YANG draft

[Mahesh Jethanandani]

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  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
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
mjethanand...@gmail.com





___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] example in draft-ietf-netmod-syslog-model-04

[Ladislav Lhotka]

> On 14 Jul 2015, at 17:25, Clyde Wildes (cwildes)  wrote:
> 
> Lada,
> 
> Thanks for your review.
> 
> All was not added to the syslogtypes:severity because that would alter the 
> definition of severity as specified by RFC 5424 in Table 2 on page 10. I 
> agree that it will simplify the model to do so.

The description of the “severity” leaf says:

When severity is specified the default severity comparison is all messages of 
the specified severity and greater are logged unless all is specified which 
means all severities are requested.

Isn’t then “debug” equivalent to “all”, i.e. is the “all” option really needed?

> 
> Please advise.

I would do a similar thing that you did for facilities: choice between 
“severity” (with the type “syslogtypes:severity”) and an empty leaf 
"all-severities”.

Lada

> 
> Thanks,
> 
> Clyde
> 
> 
> 
> On 7/14/15, 6:57 AM, "netmod on behalf of Ladislav Lhotka" 
>  wrote:
> 
>> Hi,
>> 
>> the example in sec. 4.3 of draft-ietf-netmod-syslog-model-04 is
>> invalid: the value of "severity" should be "critical" rather than
>> "syslogtypes:critical". Enums are simple strings, not QNames.
>> 
>> Also, I wonder why the type of "severity" is defined (in multiple
>> places) like so:
>> 
>> type union {
>>   type syslogtypes:severity;
>>   type enumeration {
>> enum all {
>>   value -1;
>>   description
>> "This enum describes the case where all severities 
>>  are requested.";
>> }
>>   }
>> 
>> I think the "all" enum can be simply added to the "syslogtypes:severity"
>> enumeration.
>> 
>> Lada
>> 
>> -- 
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] example in draft-ietf-netmod-syslog-model-04

[Clyde Wildes (cwildes)]

Lada,

Thanks for your review.

All was not added to the syslogtypes:severity because that would alter the 
definition of severity as specified by RFC 5424 in Table 2 on page 10. I agree 
that it will simplify the model to do so.

Please advise.

Thanks,

Clyde



On 7/14/15, 6:57 AM, "netmod on behalf of Ladislav Lhotka" 
 wrote:

>Hi,
>
>the example in sec. 4.3 of draft-ietf-netmod-syslog-model-04 is
>invalid: the value of "severity" should be "critical" rather than
>"syslogtypes:critical". Enums are simple strings, not QNames.
>
>Also, I wonder why the type of "severity" is defined (in multiple
>places) like so:
>
>  type union {
>type syslogtypes:severity;
>type enumeration {
>  enum all {
>value -1;
>description
>  "This enum describes the case where all severities 
>   are requested.";
>  }
>}
>
>I think the "all" enum can be simply added to the "syslogtypes:severity"
>enumeration.
>
>Lada
>
>-- 
>Ladislav Lhotka, CZ.NIC Labs
>PGP Key ID: E74E8C0C
>
>___
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] example in draft-ietf-netmod-syslog-model-04

[Ladislav Lhotka]

Hi,

the example in sec. 4.3 of draft-ietf-netmod-syslog-model-04 is
invalid: the value of "severity" should be "critical" rather than
"syslogtypes:critical". Enums are simple strings, not QNames.

Also, I wonder why the type of "severity" is defined (in multiple
places) like so:

  type union {
type syslogtypes:severity;
type enumeration {
  enum all {
value -1;
description
  "This enum describes the case where all severities 
   are requested.";
  }
}

I think the "all" enum can be simply added to the "syslogtypes:severity"
enumeration.

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] ACL model problem

[Ladislav Lhotka]

Hi,

the module ietf-packet-fields.yang in draft-ietf-netmod-acl-model-03
still has the problem that I discovered in the previous revision:

- Containers "source-port-range" and "destination-port-range" are both
  mandatory because the child leaf "lower-port" in each is mandatory. I
  think this wasn't intended. One solution would be to make both of them
  containers with presence.

(see
https://mailarchive.ietf.org/arch/msg/netmod/ShROtXH7aMNDs5HoIiTUa99X0JY)

Even though the tree in sec. 3.1 displays "lower-port" as optional, in
reality ietf-packet-fields.yang still has this leaf as "mandatory true;"
in both "source-port-range" and "destination-port-range".

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Comments on draft-mansfield-uml-to-yang-00

[Italo Busi]

Ops, you are right

Thanks for catching it

Italo

> -Original Message-
> From: Varma, Eve L (Eve) [mailto:eve.va...@alcatel-lucent.com]
> Sent: lunedì 13 luglio 2015 20:25
> To: Italo Busi; netmod@ietf.org
> Subject: RE: Comments on draft-mansfield-uml-to-yang-00
> 
> Hi Italo,
> 
> Thank you for your very helpful comments!
> 
> Just a quick note - the subsection numbers you commented on seems off by one.
> For example, object class mapping is in Section 5.2, not 5.1; association
> mapping is in section 5.5, not 5.4.
> 
> Best regards,
> Eve
> 
> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Italo Busi
> Sent: Friday, July 10, 2015 10:55 AM
> To: netmod@ietf.org
> Subject: [netmod] Comments on draft-mansfield-uml-to-yang-00
> 
> Dear authors of draft-mansfield-uml-to-yang,
> 
> I think this draft is very useful in assisting translation between UML IMs
> and Yang DMs. Since many UML IMs have been already defined, this I-D would
> help in simplifying development and/or gap analysis of new Yang DMs.
> 
> It also complements the work on the suite of translation drafts developed or
> under development in the NETMOD WG (e.g., RFC 6643 and draft-ietf-netmod-
> yang-json).
> 
> I have started to read the draft and have got an initial set of comments I
> would like to share (further comments may follow while I continue reviewing
> the draft).
> 
> Appendix A is very helpful to see how the different mapping rules work. It
> would be worth enhancing it with some further detailed descriptions also
> referencing the YANG Module and not only the YANG tree of draft-dharini-
> netmod-g-698-2-yang-04.
> 
> It seems that section 5 of this I-D is describing the mapping between the
> UML artifacts defined in section 5 of TR-514. It would be worth adding some
> text to clarify this point.
> 
> It seems that section 5.1 of this I-D is describing how the Object Class UML
> artifact described in section 5.1 of TR-514 is mapped into YANG statements.
> 
> In particular, an Object Class UML artifact can be mapped either to a "list"
> or to a "container" YANG statement. The I-D does not describe when (i.e.,
> under which condition) a "list" or a "container" statement should be used.
> Are both approaches equivalent or is there a criteria for using one or other
> approach depending on some characteristics of the Object Class?
> 
> Looking YANG module in the appendix A example (draft-dharini-netmod-g-698-2-
> yang-04), it seems that the superclass property of an Object Class artifact
> is not explicitly defined but it is inferred from the structure of the
> "augment" and "container" statements:
> 
>  augment "/if:interfaces/if:interface" {
>description "Parameters for an optical interface";
>container optIfOChRsSs {
>   description "RsSs path configuration for an interface";
>  <...>
>  }
> 
> Looking at this example, it is also worth noting that the documentation
> property of the optIfOChRsSs Object Class maps to the "description"
> substatement below the "container optIfOChRsSs" statement (i.e., description
> "RsSs path configuration for an interface";). The other description
> statement (i.e., description "Parameters for an optical interface";) is
> mapping the documentation property of the inheritance relationship.
> 
> It would be worth updating Section 5.4 to describe how the properties of the
> Association UML artifacts maps into substatements of the YANG statements as
> well as updating appendix A to describe the example above.
> 
> Is it possible to map into YANG an UML Object Class that inherits from more
> than one superclass?
> 
> Just a nit: I think that reference [7] is not an OMG document
> 
> Thanks, Italo
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Interface Extensions YANG draft

[Robert Wilton]

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


On 14/07/2015 08:59, wangzitao wrote:

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:rwil...@cisco.com]
发送时间: 2015年7月13日 19:24
收件人: wangzitao; netmod@ietf.org
主题: Re: [netmod] Interface Extensions YANG draft

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


On 13/07/2015 09:42, wangzitao wrote:

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;
 

Re: [netmod] Interface Extensions YANG draft

[wangzitao]

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:rwil...@cisco.com] 
发送时间: 2015年7月13日 19:24
收件人: wangzitao; netmod@ietf.org
主题: Re: [netmod] Interface Extensions YANG draft

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


On 13/07/2015 09:42, wangzitao wrote:
> 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:netmod-boun...@ietf.org] 代表 Robert Wilton
> 发送时间: 2015年7月9日 0:11
> 收件人: netmod@ietf.org
> 主题: [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.
>
> https://datatracker.ietf.org/doc/draft-wilton-netmod-intf-ext-yang/
>
> Any comments or feedback is apprecia