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

From: Yaron Haviv <[email-masked]>
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  

1. LID in ARP (Closed)
it was agreed to remove the LID from the ARP body, who ever needs it will
get it from the LRH

2. Capabilities bits (Closed)
no one rejected the idea of postponing the capability discussion to a
separate RFC
where another related issue is the SDP (Socket Direct) capability (also
postponed)

3. end node configuration (almost closed)
for now MS (Dube) has withdrawn from its proposal to do something automatic
with the end node configuration in the context of this RFC
we might target it in the future also with the help of IBTA (ServiceID,
etc’)
it might also solve my concern around the 1500MTU size, so I don’t mind
dropping the 1500MTU issue for now too

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 

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

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

---

From: [email-masked]
Date: Thu, 31 Jan 2002 10:30:18 +0900

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
>

>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.

>I hope we finalize it and get a consensus quick 

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