Subject: [ieee-ietf-coord] request for IESG early approval for an EtherType for BIER

From: Alia Atlas <[email-masked]>
Date: Tue, 27 Jun 2017 14:42:39 -0400

In RFC 7241 Section 6.2 (as helpfully pointed out by Pat Thaler), it
specifies:

" The IEEE RAC will not assign a new Ethertype to a new IETF protocol
   specification until the IESG has approved the protocol specification
   for publication as an RFC.  In exceptional cases, the IEEE RA will
   consider "early allocation" of an Ethertype for an IETF protocol that
   is still under development when the request comes from, and has been
   vetted by, the IESG."

The BIER Working Group Chairs have requested that a new EtherType request be
approved by the IESG so that it can be forwarded to the IEEE RAC.
The relevant draft is draft-ietf-bier-mpls-encapsulation-07
<https://datatracker.ietf.org/doc/draft-ietf-bier-mpls-encapsulation/>.
At the last IETF, I discussed
the possibility of using a EtherType with a subtype, but that is not
feasible in this case.

This draft has had a WGLC in BIER but it is also going through a Last Call
in MPLS.  Realistically, it will probably be 2-3 months before it comes to
an IESG telechat. I believe that there is work on hardware implementations
and getting an EtherType allocated soon would be helpful.

Are there any concerns about doing this?  If so, let's discuss.  If not, I
would like it to be formally minuted during the next IESG telechat so that
we can get the request in to the IEEE RAC as soon as possible.

Below is explanation of why using a subtype will not work.

The BIER WG would like to have a distinct IEEE Ethernet Type for the use of
the draft draft-ietf-bier-mpls-encapsulation-07
<https://datatracker.ietf.org/doc/draft-ietf-bier-mpls-encapsulation/>, which
defines an encapsulation for BIER technology that can be either carried
natively as MPLS frames or in Ethernet the same way MPLS is carried over
Ethernet in types 0x8847 and 0x8848. Major reasons why we would like to
avoid using existing types or a subtype field are:

   - The BIER header is carefully aligned  for fast processing being at the
      same point in the networking stack as native MPLS (sometimes colloquially
      called level 2.5). It is a carrier backbone targeted technology where
      forwarding speed requirements are the highest. Fast silicon can easily
      strip today Ethernet II headers to provide an aligned structure
and adding
      subtype field would present unnecessary practical difficulty in
      implementation of the technology.
      - Albeit it would be thinkable for 0x8847 or 0x8848 types to be used
      directly to carry the BIER encapsulation relying on the fact
that BIER also
      presents a “label” equivalent, we do perceive that such a route would be
      very perilous since the label would have to be presented in the
same place
      in the payload (which BIER encapsulation today does not) and even then,
      intermediate hops may not be able to tell whether the label
presents a BIER
      encapsulation or an MPLS label stack.
      - BIER header carries in front today a well defined nibble value that
      allows silicon that “peeks” behind ether frame or MPLS label
stack without
      understanding the payload to avoid interpreting BIER as IPv4 or
IPv6 frame
      and try to build 5-tuple spurious entropy that way. Albeit such
a behavior
      is questionable, it is widely deployed in today’s vendors’
silicon chips to
      distinguish “flows” behind MPLS and unknown frames. Adding subtype field
      will misalign this field and may lead to unforeseen results.
      - No obvious candidate Ethernet Type to “subtype” BIER into is
      discernible

Regards,
Alia