Subject: RE: [Ipoverib] draft-ietf-ipoib-ip-over-infiniband-00.txt

From: "H.K. Jerry Chu" <[email-masked]>
Date: Tue, 26 Feb 2002 01:37:18 -0800 (PST)

It looks like we have a number of people requesting "EtherType" (as per
RFC1700) to be included in the IPoIB encapsulation as part of the
UD payload. The EtherType will occupy the lower 16 bits of a 4 byte word,
with the upper 16 bits marked as reserved.

Those who are against including "EtherType" should speak up now. This
allows us to make a consensus call sooner.

As for myself, I don't really care one way or the other. But if
including "EtherType" addresses the QP sharing issue that people
are concerned, then why not? There is not much of downside for it
except perhaps a bit of architectural unpleasantness. As for non-IP
protocols following the same rule, technically it's up to IBTA to
designate the inclusion of "EtherType" as the official demux scheme.
The same applies to the part of multicast address space reserved
for IPoIB use. But in reality I doubt this will be an issue, as IPoIB
will become a well-publicized application of IB. Anyone serious about
developing IB applications will most likely know about these
contraints/assumptions imposed by IPoIB.

Jerry

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

---

From: Vivek Kashyap <[email-masked]>
Date: Tue, 26 Feb 2002 11:28:20 -0800 (PST)

Please comment soon so that the encapsulation draft can be
        updated and submitted before the cut off of march 2nd.

        For that matter please send in your comments on the draft(s)
        in general in the next couple of days so that they can be
        included before the cut off.

Vivek

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

---

From: Michael Krause <[email-masked]>
Date: Tue, 26 Feb 2002 12:24:15 -0800

>         included before the cut off.

For a UD-based IP over IB implementation, Ethertype isn't required if the 
rest of the IB infrastructure has its act together to allow non-IP services 
to be properly identified. Hence, I don't have a problem with it not being 
included within the specification.

Mike

---

From: Vivek Kashyap <[email-masked]>
Date: Tue, 26 Feb 2002 13:35:55 -0800 (PST)

> included within the specification.

Yes, you are right. Ethertype is also not required for RC (or other
mode) IP over IB implementations.

Vivek

---

From: [email-masked]
Date: Wed, 27 Feb 2002 19:17:54 +0900

>Date: Tue, 26 Feb 2002 12:24:15 -0800
>From: Michael Krause <[email-masked]>
>Subject: Re: [Ipoverib] draft-ietf-ipoib-ip-over-infiniband-00.txt
>to be properly identified.

I need a mechanism which allows non-IP services to be properly identified
on IBTA 1.0a.
I disagree with depending on "post 1.0a IBTA". (e.g. IBTA 1.1, 2.0,.)
(i.e. Packet Identifier in BTH to ditinguish protocols of received packets.)

And I think IETF/ipoib should not force vendors (incl. me) to
select multi-QPs based implementation(s) per interface
 and IETF/ipoib should allow vendors to implement a single QP (per interface)
based design.
It does not mean prohibitting multi QPs (per interface) based design/implement
-ation (e.g. a QP per protocol).
What I want to say is IETF/ipoib should allow both. should not force one.

And IETF/ipoib should allow vendors to implement non-IP protocols over IPoIB.
 (not "directly over IB" but "over IPoIB".)
Of course, they need to follow IETF/ipoib protocol standard.

Assuming above, I recommend you select Ethertype should be in payload.
 i.e. (iii) (b) (by Vivek's summary mail words).

> Hence, I don't have a problem with it not being 

Thanks,
Akihiko

---

From: Michael Krause <[email-masked]>
Date: Wed, 27 Feb 2002 09:34:56 -0800

At 07:17 PM 2/27/2002 +0900, [email-masked] wrote:
>on IBTA 1.0a.  I disagree with depending on "post 1.0a IBTA". (e.g. IBTA 
>1.1, 2.0,.)

My comment has nothing to do with future version of IB technology.  It has 
to do with getting a set of I/O and service infrastructure in place to 
communicate what resources to target for a given service.  To a large 
extent this is independent of the IB technology specification evolution and 
requires more development of service infrastructure / implementations.

>And I think IETF/ipoib should not force vendors (incl. me) to select 
>multi-QPs based implementation(s) per interface  and IETF/ipoib should 
>allow vendors to implement a single QP (per interface) based design.  It 
>does not mean prohibitting multi QPs (per interface) based 
>design/implement -ation (e.g. a QP per protocol). What I want to say is 
>IETF/ipoib should allow both. should not force one.

IP over IB charter is quite explicit in the target of the technology 
specification focus and there is nothing within it that states a method to 
support alternative protocol suites.  As such, there is no basis for 
forcing the inclusion of Ethertype at this time.  Also there is no one 
forcing anyone to use multi-QP implementations as one could simply 
advertise only one QP for all services - how you parse to de-multiplex the 
various protocols is an implementation detail not an IP over IB 
specification requirement.  The specification enables everyone to the 
extent needed to deliver IP over IB solutions.

>And IETF/ipoib should allow vendors to implement non-IP protocols over 
>IPoIB.  (not "directly over IB" but "over IPoIB".) Of course, they need to 
>follow IETF/ipoib protocol standard.

The IETF specifications are used to create interoperable solutions for the 
IP protocol suite of technology.  If a technology does not fall into this 
suite then there is no requirement to provide any additional capabilities 
to support such technology.  No one restricts what you can implement so you 
can implement anything on top of this technology but it is up to you to 
find an appropriate method to specify which is separate from the charter 
specifications.

>  i.e. (iii) (b) (by Vivek's summary mail words).

Disagree.

Mike

---

From: [email-masked]
Date: Thu, 28 Feb 2002 13:17:44 +0900

>Date: Wed, 27 Feb 2002 09:34:56 -0800

>forcing the inclusion of Ethertype at this time. 

I know IETF/ipoib focuses on IP suite and not focus on non-IP themselves.
But I think IETF/ipoib should provide infrastructure on which vendors can
develop various applications (incl. some IPoIB driver implementations 
and their upper layers) based on IETF/ipoib standard.
One of the ways which enable them is Ethertype in payload.
I believe IETF/ipoib is infrastructure for applications.
So even if IETF/ipoib foceses on IP suite, we should think another applications
(e.g. non-IP protocols over IPoIB) and I think you cannot prohibit inclusion
 of Ethertype.

>find an appropriate method to specify which is separate from the charter 

Yes it it up to developers (incl. me) to implement application over IPoIB.
But IETF/ipoib should provide infrastructure for applications over IPoIB.
One of requirements to IETF/IPoIB is
 , implementations are possible *WITHOUT* multi-QPs and tricky/dirty ways,
Ethertype satisfies it, I think.

Thanks,
Akihiko