Re: IPoIB link address

On Tue, 23 Sep 2003, Kanoj Sarcar wrote:

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

Hello,

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

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

I'm unclear on  the port supporting only one of the ip protocols and not
the other.

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

Yes that is possible. However, in general I would expect the setup to be such
that the multicast GIDs are created by the nodes based on the broadcast-GID
attributes. Since first full-join is a create this shouldn't be much of a
problem for creating the all-nodes v6 multicast GID.

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

I prefer your alternative suggestion. I am viewing the common broadcast-GID
to be the same as the all-1's link address in Ethernet. The multicast
mapping is only for IP multicast addresses same as the ethernet
model (the mapping itself is different from ethernet of course).
[nit: it is FF12::1 and not FF02::1].

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

Yes, this works well. I'm ok with that though would still prefer that, if
this option is chosen, we drop the protocol signature from the
broadcast GID.

Vivek


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

__

Vivek Kashyap
Linux Technology Center, IBM