Re: IPoIB link address

Hi,
Comments below.
At 01:25 AM 9/24/2003 -0700, Vivek Kashyap wrote:

> >
> > >
> > > 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.
>
>Agreed that it allows such a function. However, I also believe that such a
>notion must be rare.  When a user sets up an ip interface he/she expects to
>just assign IP addresses and send the data out. It would be odd if the user
>is only able to assign one set of addresses but not the other set or transmit
>v4 packets but not v6 packets.

I agree with Vivek that this kind of function will be unacceptable in most 
deployments.

> >
> > 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.
>
>The v6 qpn need not join the broadcast-GID if option 2) below is chosen. The
>driver can, on startup, join the broadcast-GID on the qpn associated with v4
>broadcasts. The attributes can then be borrowed for the v6 qpn without it
>having to actually join the broadcast-GID. The isolation can still be
>maintained in those implementations that prefer it.

There is nothing requiring the broadcast traffic to be received on the same 
QPN as that defined by the link addr. If an implementation is concerned 
about broadcast traffic isolation, it can allocate a separate QP for 
attaching to the broadcast GID and allocate a separate QPN for receiving 
unicast packets. IB multicast packets do not target a particular QPN on the 
remote, just an MGID and so the actual QPN used for this traffic is 
invisible on the wire.

-Vandana