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) <a...@cisco.com> wrote:
>
> 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
> <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 <netmod-boun...@ietf.org <mailto:netmod-boun...@ietf.org>> on
> behalf of Mahesh Jethanandani <mjethanand...@gmail.com
> <mailto:mjethanand...@gmail.com>>
> Date: Tuesday, July 11, 2017 at 11:55 AM
> To: "Benoit Claise (bclaise)" <bcla...@cisco.com <mailto:bcla...@cisco.com>>
> Cc: Marc Holness <mholn...@ciena.com <mailto:mholn...@ciena.com>>, Glenn
> Parsons <glenn.pars...@ericsson.com <mailto:glenn.pars...@ericsson.com>>,
> NetMod WG <netmod@ietf.org <mailto:netmod@ietf.org>>
> 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.
>
> Is there a IETF-IEEE co-ordination meeting planned in Prague?
>
>> On Jul 11, 2017, at 3:25 AM, Benoit Claise <bcla...@cisco.com
>> <mailto:bcla...@cisco.com>> 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.
>> <gidfollnniceccif.png> 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
>>
>> <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.
>>>
>>> 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
>>> mjethanand...@gmail.com <mailto:mjethanand...@gmail.com>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> <mailto:netmod@ietf.org>https://www.ietf.org/mailman/listinfo/netmod
>>> <https://www.ietf.org/mailman/listinfo/netmod>
>
> Mahesh Jethanandani
> mjethanand...@gmail.com <mailto:mjethanand...@gmail.com>
Mahesh Jethanandani
mjethanand...@gmail.com
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
