Re: IPoIB link address

Vivek Kashyap wrote:
> 
> Bill,
> 
> [Vandana had asked me this question and so I brought it up with you and
> Jerry. I then requested Vandana to send it to the list. So not a
> coincidence :)].
> 
> I discussed it with Jerry and it is clear that the drafts are not explicit
> in making it a requirement that the attributes have to be the same. There
> are implementations that can work with different Q_Keys (since they choose
> to support different QPs), however an implementation that cannot/does not
> choose different QPs for the two protocols will have to 'work harder'
> within the driver to make it work. Therefore I agree that a common set of
> Q_Keys (and other attributes) needs to be an explicit requirement.
> Architecturally too, a link shouldn't depend on the upper layer protocol --
> whether it is v4 or v6 -- it is just a link.
> 
> How we do it has two options:

Hi,

> 
> 1) Two Broadcast-GIDs
> 
>    a) Explicitly require that the two broadcast-GIDs have same attribute
>    values
>    b) Explicitly require that both the broadcast-GIDs are always created
> 
>    This is closer to the current specification except we are adding some
>    requirements.

Note that this scheme allows the fabric administrator (via the creation of
v4 and/or v6 groups) to indicate to the nodes whether v4 and/or v6 operation
is intended on the fabric. Smart nodes can then decide to fail or succeed
setting up IPv4 or IPv6 protocol on the interface (during the DLPI bind
operation or similar). Whether such a way of controlling operation of the 
nodes by the fabric administrator is desirable or not is another issue.

There is also the issue of broadcast traffic isolation that has been
pointed out; any port which has a only a single qpn accepting v6 traffic
currently does not need to receive broadcast traffic, saving both fabric
resources and host interruption.
 
> 
> 2) One common broadcast-GID
> 
>    a) One broadcast-GID that the driver joins. [the protocol signatures can
>    still be included in the multicast mappings].
> 
>    This is architecturally cleaner and may be for implementation too --
>    only one broadcast-GID to be created and joined.

Yes, its does seem cleaner and simpler, and makes fabric configuration
errors less likely (note that the fabric administrator still can create
a multicast group corresponding to one of the v4/v6 IP multicast addresses
with the wrong qkey).

If this common group is adopted, one possibility to think about is making
the link broadcast address the same as the link multicast address for
224.0.0.1 or FF02:0:0:0:0:0:0:1, resulting in a reduction of one
multicast group required for v4 and/or v6 operation on the fabric.

Alternatively, what might work best (ie requires minimal changes
to existing implementations) is naming the current v4 broadcast group as 
the common group, and eliminating any implications that the v6 all-node
group should be created by the fabric administrator.

Thanks.

Kanoj


> 
> Vivek
> 
> --
> Vivek Kashyap
> Linux Technology Center, IBM
> [email protected]
> [email protected]
> Ph: 503 578 3422 T/L: 775 3422
> 
> 
>                       "bill"
>                       <[email protected]>        To:       "'Vandana Rao'" <[email protected]>, <[email protected]>
>                       Sent by:                 cc:
>                       ipoverib-admin@ie        Subject:  RE: [Ipoverib] IPoIB link address
>                       tf.org
> 
> 
>                       09/22/2003 04:04
>                       PM
> 
> 
> 
> Vandana,
> 
> This issue has been discussed in private amongst the authors for a few
> days now.  Any chance I can get an opinion from you on your preferences
> between 1/2 (and why).  I'd like to get this nailed soon so we can
> FINALLY get some forward progress on standards
> 
> Bill
> 
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf
> Of Vandana Rao
> Sent: Monday, September 22, 2003 2:31 PM
> To: [email protected]
> Subject: [Ipoverib] IPoIB link address
> 
> Hi,
> 
> In the IP encapsulation draft , section 6.1.2, it is indicated that the
> Q_Key used should be that of the
> broadcast-GID. Which broadcast GID should be used? Specifically, if the
> IPv4 and IPv6 broadcast GIDs are assigned different Q_keys, which Q_Key
> should be used?
> 
> The issue with potentially allowing different Q_Key values for the 2
> GIDs
> is that 2 separate QPs will have to
> be allocated for IPv4 and IPv6 traffic respectively and will require the
> 
> IPoIB driver to keep track of upper layer protocols.
> If everyone agrees that this is a problem, there are 2 ways to address
> the
> issue:
> 1) Require the 2 broadcast GIDs to have the same attributes such as
> Q_key,
> MTU etc.
> or
> 2) Create a single broadcast GID to define the link.
> 
> -Vandana
> 
> _______________________________________________
> IPoverIB mailing list
> [email protected] https://www1.ietf.org/mailman/listinfo/ipoverib
> 
> _______________________________________________
> IPoverIB mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ipoverib
> 
> _______________________________________________
> IPoverIB mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ipoverib