Subject: Re: [Ipoverib] consensus call on EtherType, min MTU and DHCPv4

From: "H.K. Jerry Chu" <[email-masked]>
Date: Thu, 11 Apr 2002 13:34:54 -0700 (PDT)

>X-Sender: [email-masked]
>Date: Thu, 11 Apr 2002 06:33:06 -0700

<snip>

>>Last week I asked people to bring "new, convincing evidence" when
>>arguing for or against EtherType. But unfortunately in the past few
>>days all I heard was either old arguments, or people reiterating their
>>positions. Since no one has brought forward any new, convincing
>>evidence against EtherType, and in both the mailing list and the
>>f2f meeting Bill and I feel there have been more people for EtherType
>>than against it, plus a number of people requesting EtherType are
>>actually working on real implementation, I hereby declare EtherType
>>to be the rough consensus of the WG to be included in the UD payload
>>of every IPoIB packet.
>
>What is the specification of Ethertype other than it is 16-bits of space 
>followed by the next set of headers?

To keep 4-byte alignment I suggest to have Ethertype residing in the
lower (network byte-ordering) 2 bytes with the upper 16 bits marked
as reserved. It'd use the values for ARP, IPv4 and IPv6 from the
"EtherType" defined by IANA. Beyond these three protocols I'm not
sure we (IPoIB WG) want or even can say much.

>Is an implementation required to 
>process this field if it does not want to do so?

IMO the sender MUST incorporate EtherType correctly in all the
outgoing ARP/IPv4/IPv6 pkts (including both unicast and multicast).
The receiver SHOULD but is not required to demux based on EtherType.
This is partly implementation detail. If a receiver can correctly
demux without examining EtherType, why do we care?

>Is Ethertype required for 
>all IB transport services that may support IP traffic - it seems that it 
>must be to remain consistent from an implementation point of view.

Agreed. But since the consensus call was made specifically for UD,
for non-UD people can speak up if they have a different opinion.

>
>>Over the past couple of days a couple of senior IBTA members have
>>reiterated their positions against EtherType. But in my opinion the
>>decision of including EtherType in the UD payload is at least partly
>>as the result of the IBTA failing to address people's need to have a
>>field in IB identifying the type of the data being encapsulated in
>>the UD payload.
>
>In essence, the consensus is that the IP over IB workgroup is defining the 
>official Raw protocol on behalf of the IBTA since in many people's opinion 
>the IBTA screwed up.  As such, it would be beneficial to simply write a 
>draft with this as the stated goal so that anyone can use it independent of 
>IP over IB's charter for such purposes and then have the IP over IB 
>specification reference said draft.

Agreed. But since the draft will address a generic IB issue rather than
IPoIB issue, IBTA seems to be the right place for such a document, not
IETF.

>  This will be much cleaner and at least 
>make everyone who may want to implement such a service not have to go 
>searching within an IP over IB specification to find this non-IP focused 
>functionality.

Agreed.

>
>>Some argued that the QP is supposed to serve that
>>purpose, but we are not even doing that for IPv4, ARP/RARP and IPv6.
>>I think the argument is rather weak.
>
>Just as weak as hijacking one spec to include functionality that has 
>nothing to do with the stated charter of this workgroup.  Consensus has 
>been reached so I'll let it die.

Had IBTA fixed raw datagram to be used by IPoIB as the default IB
transport, or had we adopted SIDR to map ARP/IPv4/IPv6 to different
QPs, we wouldn't have gone down this path. Failing both, Ethertype
seemed inevitable.

Jerry

>Mike

_______________________________________________
IPoverIB mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipoverib

---

From: Michael Krause <[email-masked]>
Date: Thu, 11 Apr 2002 15:35:02 -0700

>sure we (IPoIB WG) want or even can say much.

I see no reason to further waste 2 more bytes on this thus increasing small 
packet overheads even further.  The Ethertype is going to be delivered 
along with some portion of the LRH / GRH / DETH / etc. which depending upon 
the local implementation may result in a varying amount of data.  This 
field really has nothing to do with the wire protocol's desire to be 4-byte 
aligned.

>demux without examining EtherType, why do we care?

Just needs to be stated what people must incorporate in terms of the wire 
protocol and what they can ignore if desired.

>for non-UD people can speak up if they have a different opinion.

Make it one way or another for all transport services so at least people 
don't have to do it multiple ways.

>IPoIB issue, IBTA seems to be the right place for such a document, not

This isn't an IBTA issue at all - this is about the IETF defining how a 
payload will be interpreted with some portion being control and some 
portion being data.  There is no effort within the IBTA to codify this 
packet layout as part of the IB specification therefore, it you want to use 
this for non-IP protocols in addition to IP, then you should codify this in 
an IETF standard.

>QPs, we wouldn't have gone down this path. Failing both, Ethertype

There are some who did not want to fix it so it will not be fixed and I'm 
of the opinion it should be removed for the IB specification in its 
entirety.  But I'm just the co-chair and only have 1 vote just like any 
other company within the IBTA in this regard.

Mike