Re: A Couple of IPoIB Questions

At 02:31 PM 11/16/2004, Vivek Kashyap wrote:

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

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.

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

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

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