Subject: RE: [ipoverib] resolving the Ethertype issue

From: "Larsen, Roy K" <[email-masked]>
Date: Fri, 25 Jan 2002 12:36:25 -0800

Although my feelings aren't strong enough to drag the reflector into a never
ending rat hole, I believe the IPoIB draft should specify a
protoco/"Ethertype" as the first field of the payload which is treated as an
IPoIB protocol specific field.  The reasons are as follows:

1.  Interesting OSs require the link driver to identify the destination
protocol of received frames.

2.  QPNs do not provide a clean mechanism to do this because, at a minimum,
both ARP responses and IPv4 frames must share the same QPN.

3.  Requiring the IPoIB driver to peek into an upper-level protocol frame is
architecturally displeasing. (Read that as an euphemism for KLUDGE.)

4.  Arguments that some day the IB header may contain such a field are
irrelevant in defining a protocol today.  (Same reasoning we've seen for IB
subnet routing issues.)

Roy

-----Original Message-----
From: Yaron Haviv [mailto:[email-masked]]
Sent: Friday, January 25, 2002 9:46 AM
To: [email-masked]
Subject: [ipoverib] resolving the Ethertype issue

As Arvind mentioned the Ethertype field issue is one of the last items to
agree up on

Currently there are 2 proposals:
1.	(Vivek) no need for ethertype, we could see its an ARP from the
first
fields in the Packet (IP Ver)
2.	put the Ethertype field in the first few bytes of each message

I personally don't see it as a critical decision choosing 1 or 2, the only
thing that Vivek proposal might not enable is doing Ethernet over IB which
is not in the scope of this RFC anyway
I would tend to agree with Vivek for the simplicity reasons (not the
performance ones)

If any one has a firm reason why to put the Ethertype field in the payload
please make your arguments
And it would help in settling this matter too
Please try to give real reasons in this case too, and not things like “it is
better”, etc'

Yaron

_______________________________________________
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: Yaron Haviv <[email-masked]>
Date: Sat, 26 Jan 2002 00:21:28 +0200

Roy, similar arguments like Paul, see embadded

 -----Original Message-----
From: 	[email-masked] [mailto:[email-masked]]  On Behalf
Of Larsen, Roy K
Sent:	Friday, January 25, 2002 10:36 PM
To:	[email-masked]'; [email-masked]
Subject:	RE: [ipoverib] resolving the Ethertype issue

1.  Interesting OSs require the link driver to identify the destination
protocol of received frames.
<yh> since you know its IP, you could fill it out

2.  QPNs do not provide a clean mechanism to do this because, at a minimum,
both ARP responses and IPv4 frames must share the same QPN.
<yh> the idea Vivek suggested is to put zero in the IP ver field in cases of
an ARP, this resolves the problem

3.  Requiring the IPoIB driver to peek into an upper-level protocol frame is
architecturally displeasing. (Read that as an euphemism for KLUDGE.)
<yh> also Ethernet IP drivers do some of it today, not sure I get what you
mean as upper-level in this case

4.  Arguments that some day the IB header may contain such a field are
irrelevant in defining a protocol today.  (Same reasoning we've seen for IB
subnet routing issues.)
<yh> this was not assumed, just was argued that it might also solve the
problem of limiting it to IP (& not also other Ethernet stuff)

Roy

-----Original Message-----
From: Yaron Haviv [mailto:[email-masked]]
Sent: Friday, January 25, 2002 9:46 AM
To: [email-masked]
Subject: [ipoverib] resolving the Ethertype issue

If any one has a firm reason why to put the Ethertype field in the payload
please make your arguments
And it would help in settling this matter too
Please try to give real reasons in this case too, and not things like "it is
better", etc'

Yaron