Subject: RE: [Ipoverib] 4/9 deadline for a consensus call

From: "Aditya Dube" <[email-masked]>
Date: Mon, 8 Apr 2002 13:41:41 -0700

IMHO, Adding the EtherType will not cause the performance to degrade and
there is a strong advantage to having this field present. 

There are many corner cases and scenarios that use the EtherType field.
As market requirements change, the requirements for our products might
change to the point where one of these corner scenarios is needed.

Also, there has been a posting on the reflector where a company said
that the EtherType is a must for their products. I would not like the
Standard to preclude anyone from developing Infiniband products.

Aditya Dube

-----Original Message-----
From: Bill Strahm [mailto:[email-masked]] 
Sent: Monday, April 08, 2002 11:19 AM
To: Pete Zaitcev
Cc: Larsen, Roy K; 'Michael Krause'; [email-masked]; [email-masked]
Subject: Re: [Ipoverib] 4/9 deadline for a consensus call

Just on a note from the WG chair...

By definition you ARE a member of the working group by subscribing
to the mailing list and offering the opinion below...

I am very interested in hearing what implementors have to say, I am
of the opinion that including Ethertype in the payload of the packet
is not the right thing to do, however, based on hearing some 
implementation reports from people who actually ARE doing the work, I
am very close to changing my mind again.  

Can you provide a quick summary on your position (I think I read that
you are against the Ethertype field, but I could be wrong) and
especially
any technical reasons for that opinion, such as I can/can't do this
if the field is/isn't there...

Bill
On Mon, Apr 08, 2002 at 02:00:34PM -0400, Pete Zaitcev wrote:
> I do not know if that would count, but I am against that,
> because to make a lower level driver to poke into something that
> belongs to upper levels seems a little retarded to me. My gut
> feeling (e.g. distilled expirience), suggests that such choice
> may also result in a performance hit down the road. Or may be not,
> we'll see.
> 
> Since I am NOT a member of the working group, but a mere implemntor
> of what was designed by smarter people (like you), I kept quiet.
> I am going to write some code and see if this works well.
> Unfortunately, it may be a little too late to change standards
> by that time...
> 
> -- Pete
> 
> > From: "Larsen, Roy K" <[email-masked]>
> > Date: Mon, 8 Apr 2002 10:23:32 -0700 
> 
> > I recently went through the old mails on the EtherType issue and
found that
> > of those folks expressing an opinion, more wanted or were willing to
accept
> > the encapsulation field than were dead set against it.  There
certainly
> > wasn't a strong consensus against.  
> > 
> > Roy
> > 
> > -----Original Message-----
> > From: Michael Krause [mailto:[email-masked]]
> > Sent: Monday, April 08, 2002 7:22 AM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: Re: [Ipoverib] 4/9 deadline for a consensus call
> > 
> > 
> > At 12:15 PM 4/6/2002 -0800, H.K. Jerry Chu wrote:
> > >At the Minneapolis/IETF meeting we had a "room concensus" on the
> > >following:
> > >
> > >1. Embedding EtherType in the IPoIB UD payload.
> > 
> > I've seen strong consensus on the reflector that indicates it should
not be 
> > used.  I don't want to resurface all of the arguments but there were
more 
> > against this from what I could see.
> > 
> > >2. Requiring IPv4 over IB to have a minimal MTU of 1500.
> > >(This effectively rules out all the IB MTUs less than 2K for
> > >running IPoIB.)
> > 
> > Clarified to be for IB UD transport service.
> > 
> > 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

---

From: [email-masked]
Date: Tue, 09 Apr 2002 10:40:04 +0900

I have the same opinions as Aditya, about performance,etc.
And I also agree with Roy and Yaron, about consensus understanding.

Jerry and Bill wrote questions to Pete.
And I also have the same questions about Pete's comments as Jerry has.

Thanks,
Akihiko

---
>Date: Mon, 8 Apr 2002 13:41:41 -0700
>From: "Aditya Dube" <[email-masked]>
>

---
>I recently went through the old mails on the EtherType issue and found that
>of those folks expressing an opinion, more wanted or were willing to accept
>the encapsulation field than were dead set against it.  There certainly

---
>Date: Mon, 8 Apr 2002 11:29:27 -0700 (PDT)
>From: "H.K. Jerry Chu" <[email-masked]>
>
>It's not clear to me what you are against? (Including EtherType?)
>
>But the above argument seems to favor EtherType.
>
>IETF membership is determined by participation. So you have just
>become a member now :-).
>
>Jerry
>

---

From: Hiro Kishimoto <[email-masked]>
Date: Tue, 09 Apr 2002 09:10:47 +0900

I agree with Aditya,

The EtherType field has many benefits with negligible performance
hit. We have a couple of software products which require the EtherType
for straightforward design and implementation on InfiniBand.
---
Hiro Kishimoto

From: "Aditya Dube" <[email-masked]>
Subject: RE: [Ipoverib] 4/9 deadline for a consensus call
Date: Mon, 8 Apr 2002 13:41:41 -0700
Message-ID: <[email-masked]>

---

From: Michael Krause <[email-masked]>
Date: Tue, 09 Apr 2002 08:10:43 -0700

>for straightforward design and implementation on InfiniBand.

Ethertype is to inform one of the next layer above the layer 2 
protocol.  In IP over IB one knows what this type is via the QP and hence 
the IP over IB specification always knows what the protocol is.  For those 
that want to support other layer 3 and above protocols, they must define an 
appropriate specification which is not the IP over IB specification whose 
charter is well understood.

While I can appreciate the desire of some to co-opt the IP over IB 
specification for other purposes that have nothing to do with IP, it simply 
is out of bounds from a charter perspective to include a requirement that 
does not align with the stated purpose of this workgroup.  There is no way 
to create interoperability if people start to encode Ethertype with 
anything but IPv4 or IPv6 values and I'm fairly certain that quite a few 
implementations will simply ignore this field if it is being used for any 
other purpose than IP - as an implementer I certainly have absolutely no 
intention of using it and any attempt to derive compliance / 
interoperability "branding" from its presence is strongly opposed by my 
company.

Mike

BTW, the whole reason for IB Raw and its use of Ethertype was to provide 
such a capability.  The only reason we are not using IB Raw was the lack of 
a sufficiently strong CRC for this type of traffic - be nice if people 
either stated a preference to have the IBTA fix this problem or get rid of 
the associated wire protocol.