Subject: RE: [ipoverib] moving forward with the open Issues - end node configuration

From: "Vivek Kashyap" <[email-masked]>
Date: Fri, 25 Jan 2002 12:04:20 -0800

<VK> I am not sure what you gain by that. The P_Key is programmed into the
port by the SM on startup. You already have it in the P_Key tables.  How
you determine the P_Key to use is upto your administrator.

If there are multiple IPoIB subnets over the fabric - how do you know which
serviceID to choose ? These will have to be specified by the administrator.
So the administrator might as well specify the P_Key per IP interface. You
may automate the process by ensuring that your interface tries all the
P_Keys in the relevant port.

The P_Key then allows you to determine the all-nodes multicast/broadcast
address (as defined in the multicast draft). This address that has to be
setup by the administrator (first node/other method). Every interface is
required to join this address. The MTU returned on the join request is the
MTU of the interface. So the MTU is automatically configured. The join
request is less than 256 bytes and hence will be received by the SM
whatever be the link MTU/path MTU.

Zero-conf can be done in the following way though:

      The P_Keys are in the P_Key tables. Let, by default, there exist an
MGID formed by zeroing out the link-id (P_Key) field in the MGID. So for
IPv4 it will be FF12::255.255.255.255. This group is joined by the
interfaces. If they are in the partition of this MGID they will receive the
right P_Key to use for the subnet. They will also get the subnet MTU. There
can be only one such subnet in the IB subnet. If multiple IPoIB links are
defined then this scheme won't be universal but it allows complete
automation in the default case.

For multiple IPoIB links:

      If the IPoIB ports can support at least two P_Keys (since we are
looking at multiple IPoIB links) we can always define a default subnet (as
above). A DHCP server can be put on this IPoIB link. A node then enquires
this DHCP server for the P_Key. I can suggest the DHCP extensions/process
required if needed.

Comments ?

Vivek
<VK>

The current IPOverIB spec requires that the P_Key and MTU be configured
on each node.

The IPOverIB spec should provide a default method for an end-node to
come online with no IPoIB-specific configuration.

During initialization, a node could query an IPOverIB specific
ServiceRecord (Table 164, pg 685). This query will return a P_Key and
ServiceSpecificFlags. The ServiceSpecificFlags can specify whether 2048
or 4096 is the link MTU.

The ServiceRecord's ServiceID should have a default value specific to
IPOverIB. This number could be 0xFFFF:4000 in accordance with vol3
section on "ServiceID Namespace" (Table 128, pg 215).

The ServiceRecord needs to be created just as the all-node or broadcast
MCGroup is created, i.e. by the first node on the network.

If the Network Admin wishes to put the end-node on a different P_Key,
then the Admin may override the values returned by the ServiceRecord.
That is outside the scope of my proposal.

Aditya Dube

_______________________________________________
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: Michael Krause <[email-masked]>
Date: Sun, 27 Jan 2002 07:38:00 -0800

>you determine the P_Key to use is upto your administrator.

Concur with Vivek that P_Key, etc. management is outside the scope of the 
IP-over-IB spec as there are many policy decisions that need to be taken 
into account that are very IB specific and IP should not care about these 
policies.  There is precedence for such a stance as IP does not care about 
802.1Q (VLAN) and IB for this spec's purpose is a layer 2 which uses 
partitions conceptually similar to VLANs from the IP perspective and thus 
are transparent in terms of the management aspects.  The same can be said 
of service ID management.

Mike