Re: [netmod] ACL draft defines ether-type as a string

["Acee Lindem (acee)" <[e-mail]>]

My thoughts exactly… A sparse enum is the rational approach.
Thanks,
Acee

On 7/19/17, 2:37 AM, "netmod on behalf of Robert Wilton -X (rwilton -
ENSOFT LIMITED at Cisco)" <[e-mail] on behalf of
[e-mail]> wrote:

>I like the union approach.
>
>I'm not sure that we really want IEEE to have to define an enum entry
>for every possible Ethertype value.   This just means that
>implementations probably ends up with another large mapping table where
>99% of it is just noise.  So I would suggest that 'named ethertypes' are
>restricted to the set of current ones in standard use that people care
>about, and allow vendors to request that their specific ones be added if
>required.
>
>+1 to the description describing the canonical format.
>
>Thanks,
>Rob
>
>
>On 19/07/2017 07:50, Juergen Schoenwaelder wrote:
>> It may even mean that they plan to change ether-type-0xXXXX to foo
>> once 0xXXXX is allocated to foo, which would be a problem. It seems
>> a union of a uint16 and an enum can be more robust.
>>
>>   type union {
>>     type uint16;
>>     type enumeration {
>>       enum ipv4 {
>>         value 0x0800;
>>         description
>>           "Internet Protocol version 4 (IPv4)";
>>         reference
>>           "RFC 791: Internet Protocol"
>>       }
>>     }
>>   }
>>
>> A caveat is that the canonical representation of a uint16 is decimal
>> (and YANG today has no way to control that), which may be a bit
>> inconvenient here. Perhaps the description clause should overwrite
>> this. There is probably also a need to remember implementors that the
>> canonical representation of the union retains the notation, that is,
>> if I write a numeric value (i.e., if I write '0x800' I get back the
>> numeric value 2048 but if I write the enum value 'ipv4' I get back the
>> enum 'ipv4' and not a numeric value.
>>
>> I have also found a definition in [1] that uses a string with a
>> pattern to match a different notation for ether type numeric values.
>>
>>    typedef ethertype-type {
>>      type string {
>>        pattern '[0-9a-fA-F]{2}-[0-9a-fA-F]{2}';
>>      }
>>      description
>>        "The EtherType value represented in the canonical order defined
>>      	by IEEE 802. The canonical representation uses uppercase
>>      	characters.";
>>      reference
>>        "IEEE 802-2014 Clause 9.2";
>>    }
>>
>> While this may be more compliant to IEEE 802-2014 Clause 9.2, having
>> some type that easily resolves to a number may be more desirable in
>> practice.
>>
>> [1] 
>>https://github.com/YangModels/yang/blob/master/standard/ieee/802.1/draft/
>>ieee802-dot1q-types.yang
>>
>> /js
>>
>> PS: Writing definitions for seemingly simple types can be fun.
>>
>> On Tue, Jul 18, 2017 at 10:29:40PM +0000, Alex Campbell wrote:
>>> Doesn't this mean that if a new protocol is defined, then it won't be
>>>usable in ACLs until the server's data model is upgraded? (And with
>>>many devices, that is quite likely never)
>>>
>>>
>>> ________________________________
>>> From: netmod <[e-mail]> on behalf of Mahesh
>>>Jethanandani <[e-mail]>
>>> Sent: Tuesday, 18 July 2017 6:21 p.m.
>>> To: NetMod WG
>>> Subject: [netmod] ACL draft defines ether-type as a string
>>>
>>> The issue of ether-type defined as a string was discussed with
>>>participants from IEEE in IETF. It was generally agreed that since
>>>ether-types are well known values, and centrally managed, that they be
>>>defined as enumerations. There was some clarification sought by IEEE on
>>>which values need to be published. It was suggested that ether-types
>>>that are either private or do not have a protocol identified would be
>>>named as ether-type-0xXXXX where 0xXXXX represents the value assigned.
>>>All the remaining ether-types will be defined as enums with the well
>>>known names.
>>>
>>> As far as the impact of that on the ACL draft is concerned, it will be
>>>to remove all local definitions for ether-type from the draft, such as
>>>the one below and instead use the definition from IEEE, whenever that
>>>is done. It does however put a dependency on the IEEE model.
>>>
>>>
>>>      leaf ether-type {
>>>        type string {
>>>          pattern '[0-9a-fA-F]{4}';
>>>        }
>>>        description
>>>          "The Ethernet Type (or Length) value represented
>>>           in the canonical order defined by IEEE 802.
>>>           The canonical representation uses lowercase
>>>           characters.
>>>
>>>           Note: This is not the most ideal way to define
>>>           ether-types. Ether-types are well known types
>>>           and are registered with RAC in IEEE. So they
>>>           should well defined types with values. For now
>>>           this model is defining it as a string.
>>>
>>>
>>>           There is a note out to IEEE that needs to be
>>>           turned into a liaison statement asking them to
>>>           define all ether-types for the industry to use.";
>>>        reference
>>>          "IEEE 802-2014 Clause 9.2";
>>>      }
>>>      reference
>>>        "IEEE 802: IEEE Standard for Local and Metropolitan
>>>         Area Networks: Overview and Architecture.";
>>>    }
>>>
>>> Mahesh Jethanandani
>>> [e-mail]<mailto:[e-mail]>
>>>
>>>
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/netmod
>>
>
>_______________________________________________
>netmod mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/netmod