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

From: Yaron Haviv <[email-masked]>
Date: Sun, 14 Apr 2002 10:31:39 +0200

Jerry,

We must stop expending the definition somewhere so we get the spec out 
This is IPoIB we are talking about, there is no need for LLC/SNAP, and we
just need the Ethertype 
This is also the consensus, as I understand

Adding LLC/Snap adds features that are not needed for IPoIB, and just add
redundant complexity 
Lets stick to adding the Ethertype and 16 bits reserved, unless there is
something mandatory which violates the clean operation of IPoIB 

Yaron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
H.K. Jerry Chu
Sent: Saturday, April 13, 2002 2:18 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Ipoverib] consensus call on EtherType, min MTU and DHCPv4

Ajoy,

This sounds reasonable to me. But someone needs to make a concrete
proposal here, e.g., writing a draft. (Mike?)

Jerry

>Jerry,
>
>>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.
>
>Would this by definition allow implementations to use LLC/SNAP headers if
>required?  In the cIPoverATM (see rfc2225) world, the LLC/SNAP
>is the default packet format for IP datagrams.
>
>I dont necessarily have an opinion one way or the other, but having the
>alignment definetly helps.
>
>~Ajoy
>
>
>>Date: Thu, 11 Apr 2002 13:34:54 -0700 (PDT)
>>From: "H.K. Jerry Chu" <[email-masked]>
>>Subject: Re: [Ipoverib] consensus call on EtherType, min MTU and DHCPv4
>>To: [email-masked], [email-masked]
>>MIME-Version: 1.0
>>Content-MD5: GenAJUOSmMHlgivkPxdJZA==
>>X-Mailman-Version: 1.0
>>List-Id: IP over InfiniBand WG Discussion List <ipoverib.ietf.org>
>>X-BeenThere: [email-masked]
>>
>>>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
>

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

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

---

From: Michael Krause <[email-masked]>
Date: Mon, 15 Apr 2002 10:20:49 -0700

>This is IPoIB we are talking about, there is no need for LLC/SNAP, and we

The consensus is that people want to have the full range of Ethertype 
values supported.  As such, this needs to be specified independent of the 
IP over IB specification so that everyone may use these values without 
requiring them to implement IP over IB.

Mike

---

From: "Roger Ronald" <[email-masked]>
Date: Mon, 15 Apr 2002 16:16:14 -0500

Let me be the first to suggest that we call Ethertype, by itself, the
ETOL (Ethertype Only Link) Header.

I never meant to suggest that we add the existing LLC/SNAP or IEEE 802.3 LE
header...just that Ethertype (by itself) in this case serves essentially the same purpose.

RR
----- Original Message -----
From: "Michael Krause" <[email-masked]>
To: "Yaron Haviv" <[email-masked]>; "'H.K. Jerry Chu'" <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Monday, April 15, 2002 12:20 PM
Subject: RE: [Ipoverib] consensus call on EtherType, min MTU and DHCPv4

---

From: Vivek Kashyap <[email-masked]>
Date: Mon, 15 Apr 2002 14:45:54 -0700 (PDT)

I agree. LLC/SNAP doesn't provide any useful information that is not
available by a type field. And that is all we need.

Vivek

-- 
Vivek Kashyap
Linux Technology Center, IBM
[email-masked] 
[email-masked] 
503 578 3422 (o)