Subject: [Ipoverib] Preferences for the encapsulation issues posted by Joe Pelissier

From: "Deleganes, Ellen M" <[email-masked]>
Date: Mon, 22 Oct 2001 10:10:39 -0700

Greetings,

Attached are the preferences to the issues raised in a previous email from
Joe Pelissier from one group within Intel.

Regards,

Ellen Deleganes
Intel Corporation
[email-masked]

============================

1.            Determination of service level

Preference for option a: use the SL from the all hosts multicast group. The
reason this was preferred over the option to use the SL from the path record
is that getting the SL from the path record requires the implementation to
either cache the SL or go to the SM to get the path record. 

1a.            Determination of service level

Preference for option 1: do not include a flag provided by the subnet
administrator that indicates the SL of the all hosts multicast group may be
used for IP unicast communication. If the flag is there, the implication is
that the SL for the all hosts multicast group might not be the same as the
unicast SL. It was felt that it would be simpler if the SL were the same.

2.      IB Transport Service

Preference for option 1: Title RFC something like "Encapsulation of IP in IB
Unreliable Datagram", require use of unreliable datagram, and within this
RFC remain silent with respect to other transport methods (neither implies
nor prohibits use of other IB transports). The reason for this preference is
that the implication is the issues discussions will be restricted this
topic. If someone else wants to discuss IP encapsulation over some other
transport, it should be treated as a separate RFC.

3a.            Relationship between IP and IB subnets

Preference for option a: An IP subnet is contained within a single IB
subnet. A number of problems still need to be solved for an IP subnet to
span multiple IB subnets and it was felt that to get the spec done in a
reasonable amount of time the first edition should restrict the IP subnet to
be contained within a single IB subnet. The main issues raised with allowing
an IP subnet to span multiple IB subnets is the router definition, multiple
IB subnet issues and Multicast across IB subnets for an all host multicast
group are still being worked or are not defined. By choosing option a, the
number of dependencies on the work of other teams is reduced.

3b.            Mapping IPv4 scope bits to IB GID scope bits

Preference for option a: Use local scope in IB GID for all IP packets. This
is implied by the answer to 3a.

3c.            Mapping IPv6 scope bits to IB GID scope bits

Preference for option a: Use local scope in IB GID for all IP packets. This
is implied by the answer to 3a.

4a.            Mapping of IPv4 multicast address to IB multicast GID

Preference for option a: Define an algorithmic mapping. This allows the
driver to calculate the address without having to ask a Multicast server.
This is simpler and does not require a central authority to assign and keep
track of the address mappings and respond to requests for the mappings. 

4b.            Mapping of IPv6 multicast address to IB multicast GID

Preference for option a: Define an algorithmic mapping. Same reasons as
given for 4a.

5.            Mapping of multicast GID to multicast LID

If an IP subnet does not span multiple IB subnets, this is a non-issue.
Note, this should logically be grouped after Issue 3a.

6a.            Contents of the hardware address for IBARP (in addition to
QPN, GUID and Q_Key)

Preference for option a: Include LID. The IBARP should return enough
information to get to the destination without having to query the SM.

6b.            Contents of the hardware address for IBARP (in addition to
QPN, GUID and Q_Key)

Preference for option a: Include GID. See 6a.

6c.            Contents of the hardware address for IBARP (in addition to
QPN, GUID and Q_Key)

No preference. Insufficient understanding about what the capability flags
are and how they would be used to state a preference 

7.            Inclusion of GRH in IB subnet local unicast IP over IB packets
(GRH required in multicast packets and inter-IB subnet packets in accordance
with the InfiniBand specification)

Preference for option 1: Remain silent (which leaves inclusion of GRH in
unicast packets optional as specified by the InfiniBand specification)

8.            Inclusion of a field to identify the protocol (like an
"Ethertype")

Preference for option 1: Include an identification field.

9.            Determination of multicast parameters for the multicast group
used for IBARP. (Note: there was a proposal to use the InfiniBand SIDR
mechanism; at this point there appears to be no one that believes this is a
workable solution).

Preference for option 1: Use a well-known ServiceName, do a ServiceRecord
lookup to get the MGID, and then to a MCGroup lookup for the rest of the
parameters.

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