Subject: [netmod] draft-ietf-netmod-acl-model-11 issue #3

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 7 Jul 2017 13:43:49 -0700

Created issue #3 in github <https://github.com/netmod-wg/acl-model/issues/3> as "The model defines 'ether-type' node as a string.” with the following description.

The model defines 'ether-type' node as a string. Ideally, this should be a well defined list of all Ethernet Types assigned by IEEE. This requires collaborating with IEEE.

One suggestion was to define ether-type as identities. That works for when the identities themselves are distributed and need to be made extensible.

But Ethernet Types are doled out in IEEE by Registration Authority Committee (RAC), so they could choose to centrally define it as an enum and give each hex string a name that could be used by models. If a user wants to configure a particular ether-type, the server must import a version of the IEEE 8021q model that has that enumeration.

Alternatively, as @mbj4668 <https://github.com/mbj4668> has suggested, it could also be a typedef like this:

    typedef ether-type {
      type union {
        type ieee-ether-type:ether-type-enum;
        type uint16; // or a hex-based number
      }
    }
Finally, the suggestion is to have ether-type defined as a number (or hex based). This is flexible, but requires users/operators to read and write numbers which are harder to remember than symbolic names.

My personal preference would be for IEEE to define and publish the YANG model with the definitions.

Mahesh Jethanandani
[email-masked]

---

From: Benoit Claise <[email-masked]>
Date: Tue, 11 Jul 2017 12:25:33 +0200

Hi,

In order to look at what has been done already, the advice is to look at 
YANG search <https://www.yangcatalog.org/yang-search/yang-search.php>.
I searched on "ether.type" with the regex flag.
Don't pay attention to the last entry, this will be fixed.

However, specifically pay attention to the second entry, the IEEE one.
It points to 
https://www.yangcatalog.org/yang-search/show_node.php?module=ieee802-dot1q-types&path=%2Fdot1q-types%3Aether-type&revision=2016-09-22

Regards, Benoit
> Created issue #3 in github 
> <https://github.com/netmod-wg/acl-model/issues/3> as "The model 
> defines 'ether-type' node as a string.” with the following description.
>
> The model defines 'ether-type' node as a string. Ideally, this should 
> be a well defined list of all Ethernet Types assigned by IEEE. This 
> requires collaborating with IEEE.
>
> One suggestion was to define ether-type as identities. That works for 
> when the identities themselves are distributed and need to be made 
> extensible.
>
> But Ethernet Types are doled out in IEEE by Registration Authority 
> Committee (RAC), so they could choose to centrally define it as an 
> enum and give each hex string a name that could be used by models. If 
> a user wants to configure a particular ether-type, the server must 
> import a version of the IEEE 8021q model that has that enumeration.
>
> |typedef ether-type { type union { type 
> ieee-ether-type:ether-type-enum; type uint16; // or a hex-based number 
> } } |
> Finally, the suggestion is to have ether-type defined as a number (or 
> hex based). This is flexible, but requires users/operators to read and 
> write numbers which are harder to remember than symbolic names.
>
> [email-masked] <mailto:[email-masked]>
>
>
>
>
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 11 Jul 2017 08:55:25 -0700

Benoit,

Precisely. I did start in yangcatalog.com with the search for ether-type and found that it was defined as a string. It was helpful to get rid of the duplicate definition we had in the ACL draft. But that raised the question of whether it should be defined as a string, when ether-types are well known types.

Is there a IETF-IEEE co-ordination meeting planned in Prague?

> On Jul 11, 2017, at 3:25 AM, Benoit Claise <[email-masked]> wrote:
> 
> Hi,
> 
> In order to look at what has been done already, the advice is to look at YANG search <https://www.yangcatalog.org/yang-search/yang-search.php>.
> It points to https://www.yangcatalog.org/yang-search/show_node.php?module=ieee802-dot1q-types&path=%2Fdot1q-types%3Aether-type&revision=2016-09-22 <https://www.yangcatalog.org/yang-search/show_node.php?module=ieee802-dot1q-types&path=%2Fdot1q-types%3Aether-type&revision=2016-09-22>
> 
> Regards, Benoit
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
> 

Mahesh Jethanandani
[email-masked]

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 11 Jul 2017 17:32:42 +0000

Hi Mahesh, Benoit, Draft Authors,

In terms of a layer-2 ACL, I’d want to be able to match ether-type against any 2-octet number. Hence, I think a string is a very poor choice here.

In support of the above statement, one only needs to look at the existing IEEE registry for ether type.

https://regauth.standards.ieee.org/standards-ra-web/pub/view.html#registries

There are about 3700+ registered ether-types and most of them are private. This is hardly something that we’d want to represent as a YANG enum or even a set of identities.

However, if we are talking about future YANG enhancements, it would be nice to have an identity that could reference a YANG type as a base rather than another identify. That way the base type could be uint16 or some other 2-octet type and well-known ether-types could be represented by YANG identities referencing the base identity of type unit16.

Thanks,
Acee

From: netmod <[email-masked]<mailto:[email-masked]>> on behalf of Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, July 11, 2017 at 11:55 AM
To: "Benoit Claise (bclaise)" <[email-masked]<mailto:[email-masked]>>
Cc: Marc Holness <[email-masked]<mailto:[email-masked]>>, Glenn Parsons <[email-masked]<mailto:[email-masked]>>, NetMod WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] draft-ietf-netmod-acl-model-11 issue #3

Benoit,

Precisely. I did start in yangcatalog.com<http://yangcatalog.com> with the search for ether-type and found that it was defined as a string. It was helpful to get rid of the duplicate definition we had in the ACL draft. But that raised the question of whether it should be defined as a string, when ether-types are well known types.

On Jul 11, 2017, at 3:25 AM, Benoit Claise <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

In order to look at what has been done already, the advice is to look at YANG search<https://www.yangcatalog.org/yang-search/yang-search.php>.
I searched on "ether.type" with the regex flag.
 Don't pay attention to the last entry, this will be fixed.

However, specifically pay attention to the second entry, the IEEE one.
It points to https://www.yangcatalog.org/yang-search/show_node.php?module=ieee802-dot1q-types&path=%2Fdot1q-types%3Aether-type&revision=2016-09-22

Regards, Benoit
Created issue #3 in github<https://github.com/netmod-wg/acl-model/issues/3> as "The model defines 'ether-type' node as a string.” with the following description.

Alternatively, as @mbj4668<https://github.com/mbj4668> has suggested, it could also be a typedef like this:

    typedef ether-type {
      type union {

Mahesh Jethanandani
[email-masked]<mailto:[email-masked]>

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

Mahesh Jethanandani
[email-masked]<mailto:[email-masked]>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 11 Jul 2017 12:21:27 -0700

Acee,

There are couple of arguments in favor of why ether-type should be an well define enum, even if we choose to document the public ones.

- operators know and associate names better than numbers for different ether-types.
- if ether-type was a distributed registry and had to made extensible, it would make sense to define them as identities. ether-types are centrally defined and maintained by IEEE RAC.

Alternatively, as suggested by Martin, the definition could be thus:

    typedef ether-type {
      type union {
        type ieee-ether-type:ether-type-enum;
        type uint16; // or a hex-based number
      }
    }
where we allow for read/write of the hex-based number while IEEE works up the definition of the enums.

> On Jul 11, 2017, at 10:32 AM, Acee Lindem (acee) <[email-masked]> wrote:
> 
> https://regauth.standards.ieee.org/standards-ra-web/pub/view.html#registries <https://regauth.standards.ieee.org/standards-ra-web/pub/view.html#registries>
> 
> From: netmod <[email-masked] <mailto:[email-masked]>> on behalf of Mahesh Jethanandani <[email-masked] <mailto:[email-masked]>>
> To: "Benoit Claise (bclaise)" <[email-masked] <mailto:[email-masked]>>
> Cc: Marc Holness <[email-masked] <mailto:[email-masked]>>, Glenn Parsons <[email-masked] <mailto:[email-masked]>>, NetMod WG <[email-masked] <mailto:[email-masked]>>
> Precisely. I did start in yangcatalog.com <http://yangcatalog.com/> with the search for ether-type and found that it was defined as a string. It was helpful to get rid of the duplicate definition we had in the ACL draft. But that raised the question of whether it should be defined as a string, when ether-types are well known types.
> 
>> On Jul 11, 2017, at 3:25 AM, Benoit Claise <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi,
>> 
>>> [email-masked] <mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
> 
> Mahesh Jethanandani

Mahesh Jethanandani
[email-masked]

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 11 Jul 2017 19:28:06 +0000

Mahesh,

From: Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, July 11, 2017 at 3:21 PM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>
Cc: "Benoit Claise (bclaise)" <[email-masked]<mailto:[email-masked]>>, Marc Holness <[email-masked]<mailto:[email-masked]>>, Glenn Parsons <[email-masked]<mailto:[email-masked]>>, NetMod WG <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] draft-ietf-netmod-acl-model-11 issue #3

Acee,

The layer-2 ACL function needs to the uint16 mappings to be complete.

    typedef ether-type {
      type union {

This would work but it would delay completion on definition of the ieee-types model.

Thanks,
Acee

On Jul 11, 2017, at 10:32 AM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,
Acee

Benoit,

Precisely. I did start in yangcatalog.com<http://yangcatalog.com/> with the search for ether-type and found that it was defined as a string. It was helpful to get rid of the duplicate definition we had in the ACL draft. But that raised the question of whether it should be defined as a string, when ether-types are well known types.

Hi,

Regards, Benoit

    typedef ether-type {
      type union {

Mahesh Jethanandani

Mahesh Jethanandani

Mahesh Jethanandani

---

From: Benoit Claise <[email-masked]>
Date: Wed, 12 Jul 2017 00:10:19 +0200

On 7/11/2017 5:55 PM, Mahesh Jethanandani wrote:
> Benoit,
>
> Precisely. I did start in yangcatalog.com <http://yangcatalog.com> 
> with the search for ether-type and found that it was defined as a 
> string. It was helpful to get rid of the duplicate definition we had 
> in the ACL draft. But that raised the question of whether it should be 
> defined as a string, when ether-types are well known types.
>
Yes, Saturday afternoon.

regards, B.
>> In order to look at what has been done already, the advice is to look 
>> at YANG search <https://www.yangcatalog.org/yang-search/yang-search.php>.
>>> The model defines 'ether-type' node as a string. Ideally, this 
>>> should be a well defined list of all Ethernet Types assigned by 
>>> IEEE. This requires collaborating with IEEE.
>>>
>>> One suggestion was to define ether-type as identities. That works 
>>> for when the identities themselves are distributed and need to be 
>>> made extensible.
>>>
>>> enum and give each hex string a name that could be used by models. 
>>> If a user wants to configure a particular ether-type, the server 
>>> must import a version of the IEEE 8021q model that has that enumeration.
>>>
>>> Alternatively, as @mbj4668 <https://github.com/mbj4668> has 
>>> suggested, it could also be a typedef like this:
>>>
>>> ieee-ether-type:ether-type-enum; type uint16; // or a hex-based 
>>> number } } |
>>> Finally, the suggestion is to have ether-type defined as a number 
>>> (or hex based). This is flexible, but requires users/operators to 
>>> read and write numbers which are harder to remember than symbolic names.
>>>