Subject: Re: [Ipoverib] A Couple of IPoIB Questions

From: Vivek Kashyap <[email-masked]>
Date: Tue, 16 Nov 2004 14:31:27 -0800

See below in <VK>

Vivek
--
Vivek Kashyap
Linux Technology Center, IBM
[email-masked] 
[email-masked] 
Ph: 503 578 3422 T/L: 775 3422

"Hal Rosenstock" <[email-masked]>
Sent by: [email-masked]
11/16/2004 01:11 PM
Please respond to Hal Rosenstock

        To:     "IPoverIB" <[email-masked]>
        cc: 
        Subject:        [Ipoverib] A Couple of IPoIB Questions

Hi,
 
I have a couple of questions relative to IPoIB:
 
1. draft-ietf-ipoib-ip-over-infiniband-07.txt states:
"Every IPoIB interface MUST "FullMember" join the IB multicast group 
defined by the broadcast-GID."
 
Isn't the broadcast group for IPv4 ? When the IPoIB interface is IPv6 
only, does this group still need be joined ?
If not, where do the parameters for any IPv6 groups come from ? I am 
presuming that this group needs to be joined in 
the IPv6 only case. I just want to be sure.
 
<VK> Yes, the broadcast-GID is at the InfiniBand layer and MUST be joined 
whether you are running at v4 or v6 layer. <VK>

2. ALso, what is the latest status of the Vivek's connected mode draft ? 
Will it be moving forward ?

<VK> I'll be submitting it as draft-ietf-ipoib-connected-mode-00.txt by 
the end of the month. There were some interesting suggestions that were 
made during the IETF WG meeting. Two of the suggestions of consequence are 
given below. The others we can discuss when the minutes are published 
(they include some additional requests on clarification on the 
transmission draft too).

a. The current draft makes the various modes mutually exclusive i.e. RC, 
UC and UD are not allowed simultaneously in the same IP subnet. The 
thought is that it is a link characteristic and hence different per 
connection mode. It was suggested that one be allowed to mix up RC/UC. 
This goes back to the original suggestion in the first draft which was:

IPoIB-UD must always be supported. Additionally, the interface can also 
support either both of RC and UC, or one of them. Or neither of them. 

b. Another suggestion was to allow multiple connected mode links (i.e. at 
IB UC/RC level) between peers.

One thought can be 'yes, but user beware': The IB connections are made 
using the service ID that is derived from the QPN as described in the 
draft. If a second attempt succeeds then there are two links. It is up to 
the implementation to either allow or disallow multiple links.

Thoughts?

<VK>

Thanks.
 
-- Hal_______________________________________________
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: Michael Krause <[email-masked]>
Date: Tue, 16 Nov 2004 20:08:25 -0800

>Vivek

UD MUST always be supported.  I personally don't care whether one does RC 
or UC but I don't think both are required as a MAY option.  The advantage 
of RC is the send credit algorithm.  The advantage of UC is the lack of ACK 
packets.  ACK is noise in the fabric while send credits provide a simple 
method to maintain bandwidth / injection control on a per flow basis.

I see no problems with supporting both UD and *C on the same subnet; it is 
rather foolish to attempt to mandate these be on separate subnets.

>the implementation to either allow or disallow multiple links.

Again, this has been suggested in the past (though most who were involved 
in the original discussions years gone by are likely gone since much of 
this discussion occurred before the IETF workgroup was established).  There 
is obvious benefit to supporting multiple RC per endnode pair.  I do not 
see any technical reason to oppose nor any issue from an interoperability 
perspective.  There is no reason for a "user beware".  The work is rather 
straight to do and implement and the benefit to customers, is again, rather 
obvious when one considers what the IB fabric offers and how connections 
can be enable flows through multipath as well as transparent fail-over, 
flow scheduling, mapping of DiffServ to different arbitration / paths, etc.

Mike