Subject: RE: [Ipoverib] IPoIB link address

From: Vivek Kashyap <[email-masked]>
Date: Tue, 23 Sep 2003 09:13:59 -0700

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:

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.

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.

Vivek

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

                      "bill"                                                                                                           
                      <[email-masked]>        To:       "'Vandana Rao'" <[email-masked]>, <[email-masked]>                     
                      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-masked] [mailto:[email-masked]] On Behalf
Of Vandana Rao
Sent: Monday, September 22, 2003 2:31 PM
To: [email-masked]
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-masked] https://www1.ietf.org/mailman/listinfo/ipoverib

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

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

---

From: Kanoj Sarcar <[email-masked]>
Date: Tue, 23 Sep 2003 20:15:16 -0700

Hi,

>    This is closer to the current specification except we are adding some

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

---

From: Vivek Kashyap <[email-masked]>
Date: Wed, 24 Sep 2003 01:25:55 -0700 (Pacific Daylight Time)

> > How we do it has two options:

Hello,

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

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

> a multicast group corresponding to one of the v4/v6 IP multicast addresses

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.

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

> 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

> > Vivek

__

Vivek Kashyap

---

From: Michael Krause <[email-masked]>
Date: Wed, 24 Sep 2003 06:55:42 -0700

>v4 packets but not v6 packets.

Agreed.  Layer 2 should stay as ignorant about Layer 3 and above thus 
applying KISS, a single QP should support both v4 / v6.

>maintained in those implementations that prefer it.

The expectation was that this broadcast GID was primarily "management" 
focused (e.g. ARP / ND) thus the overhead / interrupt rate / etc. is 
expected to be relatively low.  If we all agree that the separation does 
not impact interoperability, then it is a local issue.

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

Don't do this with other layer 2 so why do this now?

>this option is chosen, we drop the protocol signature from the

Mike

---

From: Vandana Rao <[email-masked]>
Date: Wed, 24 Sep 2003 13:31:38 -0700

Hi,
Comments below.

>v4 packets but not v6 packets.

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

>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