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

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 18 Jul 2017 08:21:29 +0200

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
[email-masked]

---

From: William Lupton <[email-masked]>
Date: Tue, 18 Jul 2017 10:21:33 +0200

Editorial: ethertype (no hyphen) seems to be more common than ether-type (28 versus 11 matches in the YANG catalog, plus IEEE seem to use the no-hyphen version).

Also (even more editorial), I don’t see the need for the rather distracting ‘0x’ in the name, so would suggest ethertype-XXXX (yes, I realise that this decision is in the IEEE bailiwick).

William

> On 18 Jul 2017, at 08:21, Mahesh Jethanandani <[email-masked]> wrote:
>

---

From: Alex Campbell <[email-masked]>
Date: Tue, 18 Jul 2017 22:29:40 +0000

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 <[email-masked]> on behalf of Mahesh Jethanandani <[email-masked]>
Sent: Tuesday, 18 July 2017 6:21 p.m.
To: NetMod WG
Subject: [netmod] ACL draft defines ether-type as a string

    leaf ether-type {
      type string {

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

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 19 Jul 2017 07:03:29 +0200

Alex,

One of the suggestions to deal with that came from Martin in trying to define it as:

    typedef ethertype {
      type union {
        type ieee-ethertype:ethertype-enum;
        type uint16; // or a hex-based number
      }
    }
where ieee-ethertype would be defined by IEEE as suggested below. But Acee felt that would delay the deployment of the ieee-types model.

> On Jul 11, 2017, at 9:28 PM, Acee Lindem (acee) <[email-masked]> wrote:
> This would work but it would delay completion on definition of the ieee-types model.

Is that what folks want?

> On Jul 19, 2017, at 12:29 AM, Alex Campbell <[email-masked]> wrote:
> 
> [email-masked] <mailto:[email-masked]>
> 
> 
> 
> 

Mahesh Jethanandani
[email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 19 Jul 2017 07:50:38 +0200

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.

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

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Robert Wilton <[email-masked]>
Date: Wed, 19 Jul 2017 08:37:06 +0200

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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 19 Jul 2017 07:00:00 +0000

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)" <[email-masked] on behalf of
[email-masked]> wrote:

>> [1] 
>>https://github.com/YangModels/yang/blob/master/standard/ieee/802.1/draft/
>>ieee802-dot1q-types.yang
>>
>> /js
>>
>>> 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)
>>>
>>>
>>> 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 {