Subject: RE: [ipoverib] summerising the last week & open issues

From: Yaron Haviv <[email-masked]>
Date: Thu, 31 Jan 2002 20:19:17 +0200

Lets review your arguments:
You want to use Ethertype to do non IPoIB stuff (even without the ethertype
you could support future IP stuff like maybe IP v 8)
This is not the focus of this group, even if you do that than it might not
work with other implementations that work strictly with IP

Regarding the second argument you could use different QP's in order to have
multiple IPoIB networks
And even then having Ethertype field doesn't help you multiplexing things
beyond layer 2

The reason for saying it's a philosophical question is that for the things
defined in the IPoIB charter (IP only)
You don't need the Ethertype

Yaron

 -----Original Message-----
From: 	[email-masked] [mailto:[email-masked]]  On Behalf
Of [email-masked]
Sent:	Thursday, January 31, 2002 3:30 AM
To:	Yaron Haviv
Cc:	'Bill Strahm'; [email-masked]'
Subject:	Re: [ipoverib] summerising the last week & open issues

All,

>Message-ID: <20083A3BAEF9D211BDB600805F8B14F301CBF1F0@NTSERVER>
>From: Yaron Haviv <[email-masked]>
>To: "'Bill Strahm'" <[email-masked]>
>Cc: "[email-masked]'" <[email-masked]>
>Subject: [ipoverib] summerising the last week & open issues
>Date: Wed, 30 Jan 2002 15:13:52 +0200
>
>It looks to me like we had a lot of progress done in the last 2 weeks
>I will try and summaries the issues, and status, to enable people to
respond
>on the last issues

>4. Ethertype field in data (need to close)
>many people has mentioned that this issue is not critical, and doesn't harm
>anyone's ability to implement a solution
>it is more of a philosophical debate around strict layering vs. efficiency
>(and maybe also possibility to enable Ethernet over IB one day)
>since it is not a critical issue I would tend to go with the Author (Vivek)
>and leave it as it is specified already

If "ethertype' arguments was summarized so,
we would have some critical problems.

We don't think these debate/argument as philosophical.
It effects our InfiniBand product development.
Without ethertype in payload, probably other vendors can't implement other
 protcols (than IPv4/v6/ARP) on IPoIB neither.

Of course, as Vivek wrote, this mailing-list focuses ipv4/ipv6/arp.
But I think IPoIB is infrastructure for network applications/protocols
 over InfiniBand environment.
If Ethertype exists in payload, many other developers could also
 use this IPoIB protocol to implement many applications to realize many
market
 requirements. If not, vendors can't do so.

So we absolutely need ethertype field in payload (by using IBTA 1.0a. not
2.0).

For example, we implement some "protocols" over IPoIB framework, such as
 'multiplexing software (between arp/ipv4/ipv6 and ipoib driver) which uses
  multiple IPoIB interfaces',
 'cluster nodes patrol software which uses multiple IPoIB interfaces.'
 'rarp',etc.

They all are implemented by IPoIB driver's using ethertype in payload and
IPoIB driver's dispatching protocols by ethertype value.
If info is only 4bit in arp/ipv4/ipv6 packet itself, we cannot implement
any other protocols/applications over IPoIB at all.

>this one to my understanding is the only real open issue right now
>I hope we finalize it and get a consensus quick
>
>Thanks, Yaron

Thanks,
----------------------------------------------------------------------------
--
Akihiko Imai/Development Dept.5, Infrastructure Systems Division, Fujitsu
Ltd.
  e-mail: [email-masked]  TEL: +81-044-754-3456
(ext)7113-8706
  address: 4-4-1 Kamiodanaka Nakahara-ku, Kawasaki 211-8588, Japan

_______________________________________________
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: "Roger Ronald" <[email-masked]>
Date: Thu, 31 Jan 2002 13:50:53 -0600

I'm convinced that the Ethertype is not required for IP over IB.

But if there are folks who want to take advantage of a traditional
differentiator that's always been available, it seems reasonable
to accomodate them. Making up for the lack of the LLC/SNAP
header field that does this is the only way to retain the same
demuxing paradigm that's been used since the 70s.

Some comments are also embedded below:

RR
----- Original Message ----- 
From: "Yaron Haviv" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Thursday, January 31, 2002 12:19 PM
Subject: RE: [ipoverib] summerising the last week & open issues

> Lets review your arguments:

Their "argument" is that their desire to mux protocols in the fashion
that has been traditionally supported and that they would like this support
to continue in IP over IB. I believe that this is not an argument, but a
statement of fact.

> work with other implementations that work strictly with IP

It's a no-brainer that non-IP protocols won't get handled properly 
where there are not implemented. I doubt that anyone expects or 
wants different. They do want the "option" to support those protocols.

> And even then having Ethertype field doesn't help you multiplexing things
 
I doubt that anyone wants any help in demuxing beyond layer 2. They do
not "want" to uses different QPNs since that is a different demuxing method
than they use today.

> You don't need the Ethertype

They want the Ethertype. It provides a value for them.

---

From: [email-masked]
Date: Fri, 01 Feb 2002 11:58:55 +0900

Yaron,

>you could support future IP stuff like maybe IP v 8)

Yes.
 I want to use Ethertype. Ethertype should be in ipoib payload, I think.
And I implemnt a QP per ipoib-interface, which handles multiple protocols
such as (a)ipv4,arp,ipv6, (b) rarp and other protocol modules multiplexing
 multiple ipoib-interfaces (between ip/arp/ipv6 and ipoib driver).
They all have its protocol identifier, i.e. Ethertype, sap.

>You don't need the Ethertype

If Ethertype does not exist in payload, I cannot implement (b)type software.
(Even standard "rarp". I'd let me say Not "don't want to" but "cannot".)

Even if I use multiple QPs per ipoib-interface,
relation between ipv4 and arp is a exception.
If so, they would need to use the same QP as Paul,Roy,and Koji already wrote.
or we would need to make 'unclean' interfaces between ipv4 and arp.
(IMO, using multiple QPs is very suitable for load-balancing, e.g. for multiple
 IPv4 interfaces, multiple IPv6 interfaces.)
 on the other hand, using multiple QPs only to demultiplex received packet
 is too rich to me, I think. Probably many of you think/have some
 good/different ideas/merits for using different QPs per ipoib-interfaces.
 So I don't deny multiple QPs per ipoib-interface.
 But in my case, Multiple QPs are used for load-balancing by using multiple
 ipoib-interces (defining mutiple ip subnets on the same wire.)

As roy wrote and probably some other people think or said,
datalink driver(=ipoib driver)'s snooping upper layer's packet content is
 not right. I think ipoib sould not specify snooping upper layers packets.
I think Ethertype in payload solves these problem and it's .

>work with other implementations that work strictly with IP

Yes. I know this group focuses on ipv4/arp/ipv6. (How about rarp ?)
Of course, I never say "Let's argue about other protocols itself".
I say IPoIB should specify other protocols CAN be carried on the same ipoib
 packet format(with Ethertype) and leave the other protocols specify their
 own protcols/reliability details,etc themselves over ipoib.

If Snooping upper layer packets and Being without Ethertype, they would limit
 some possibility of ipoib itself and its applied range, I think.

Thanks,
  Akihiko

>>I hope we finalize it and get a consensus quick
------------------------------------------------------------------------------
Akihiko Imai/Development Dept.5, Infrastructure Systems Division, Fujitsu Ltd.
  e-mail: [email-masked]  TEL: +81-044-754-3456 (ext)7113-8706
  address: 4-4-1 Kamiodanaka Nakahara-ku, Kawasaki 211-8588, Japan