Re: A Couple of IPoIB Questions

See below in <VK>

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





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

 
        To:     "IPoverIB" <[email protected]>
        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 protected]
https://www1.ietf.org/mailman/listinfo/ipoverib

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