Subject: [Ipoverib] AD comments on draft-ietf-ipoib-ip-over-infiniband-01.txt

From: Thomas Narten <[email-masked]>
Date: Mon, 21 Oct 2002 15:03:47 -0400

Here are my review comments on this document. They all seem pretty
much to be of an the editorial nature.

>         datagram(UD) mode. A separate document will describe the
>         implementation of IP subnets over IB's other transport
>         mechanisms.

Better to just say that IP over other modes is outside the scope of
this document.

>         supported by all IB elements be they IB routers, HCAs or TCAs.

Expand acronyms the first time they are used?

>         CRC [IB_ARCH]. Though multicasting support is optional in IB
>         fabrics, IPoIB architecture requires the participating
>         components to support it [IPoIB_MCAST].

clarify. Is the use of multicast optional? Is the implementation
optional? (I suspect you mean to say the former.)

>         The type field SHALL indicate the encapsulated protocol as per
>         the following table.

The document should clearly specify what bit ordering is used.

For figure 2, is it clear how one fills in the fields for:
LRH, GRH, Base Transport Header? Is it clear to everyone (from IBTA
specs) what to put in these fields?

>         Every IP/ARP datagram includes a 4 byte encapsulation header
>         as defined above. Therefore the IP MTU can be found by
>         subtracting 4 from the IPoIB link MTU.

To be clear then, the link MTU is the maximum IB payload that can be
carried, and excludes any of the (variable-length) IB link-layer
headers (e.g., LRH, GRH, ...?)

Note: the document could be clearer by defining two terms, "IB link
MTU" and "IPoIB link MTU". The document currently is a bit loose about
terminology when talking about MTUs.

>                IPoIB Link MTU          IP MTU

I don't think these two terms are very clear.

>                 IPoIB Link MTU          IP MTU
> 
>                     4096                4092
>                     2048                2044
>                     1504                1500
>                     1284                1280
> 
>         The IPv4 MTU MUST NOT be set below 1500 bytes. The minimum
>         IPv6 MTU is 1280 bytes [RFC2373].
> 
>         IB links, switches and CAs support multiple MTUs (IB_MTU):
>         256, 512, 1024, 2048, 4096 bytes. The above conditions on IP
>         MTU require that IB components used in IPoIB subnets support a
>         minimum of 2048 byte MTUs. The IPoIB link MTU is set to the
>         MTU associated with the IB multicast group defined by the
>         broadcast-GID [IPoIB_MCAST].
> 
>         In IPv6 subnets the MTU may be reduced by a Router
>         Advertisement [RFC2461] containing an MTU option which
>         specifies a smaller MTU, or by manual configuration of each
>         node. If a Router Advertisement received on an IPoIB interface
>         has an MTU option specifying an MTU larger than the link MTU
>         or larger than a manually configured value, that MTU option
>         may be logged to system management but must be otherwise
>         ignored.
> 
>         Similarly, the IPv4 MTU may also be reduced by manual
>         configuration of each node.
> 
>         For purposes of this document, information received from DHCP
>         is considered "manually configured".

This section seems overly long and could be made clearer. I think that
all one needs to say is something like the following:

        IB links, switches and CAs support multiple MTUs (IB_MTU):
        256, 512, 1024, 2048, 4096 bytes. In order to reduce problems
        with fragmenation and PMTU discovery, this document requires
        that all IPoIB implementations support an IPoIB MTU of 2044
        octets (i.e., a 2048 IB MTU minus encapsulation
        overhead). Larger and smaller MTUs MAY also be supported, but
        the default configuration must be to support an IPoIB MTU of
        2044 octets.

Nit: better to use "octets" than "bytes". This occurs throughout.

>        each port. The LID (16 bits) is unique within an IB subnet

s/port/IB port/

LID not defined.

>         The interface identifier may also be chosen as per the
>         guidelines specified in [RFC3041].

Not really true (at least not in the context of this document.) I'd
suggest dropping the line. 3041 is about IIDs for temporary
addresses. This document is concerned with permanent IIDs for
assignment to an interface.

>         The IPv6 link local address for an IPoIB interface is formed
>         in accordance with the guidelines in [RFC2373]. The link local
>         address is of the format:
> 
>      10 bits            54 bits                  64 bits
>    +----------+-----------------------+----------------------------+
>    |1111111010|         (zeros)       |    Interface Identifier    |
>    +----------+-----------------------+----------------------------+

Might be better to drop the picture and just point to the other
spec. I.e., I think it's sufficient to just say:

         The IPv6 link local address for an IPoIB interface are formed
         as described in [RFC2373] using the Interface Identifier as
         described in the previous Section.

>         The format is as described below:
> 
>         +--------+--------+--------+--------+
>         |Reserved|         QPN[23-0]        |

say something about byte ordering.

>        Solicit, Router advertisements, Redirect, Neighbour

nit: s/neighbour/neighbor/ (per the spelling in the RFC). Change
throughout.

>        header) as depicted in Figure 1 and specified in the

Don't you mean figure 2?

>                 packet. It is an absolute necessity when transmitting
>                 across the IB subnet since the IB routers use the GID

better: ...when transmitting across multiple IB subnets .."

>                lane(VL) at every xCA, switch that sends/forwards the

what's "xCA, switch"?

>                 The choice of the QPN for IP/ARP communication is up
>                 to the implementation.

better wording: 

                 The choice of what QPN value to use for IP/ARP
                 communication is up to the receiving implementation.

>         c) Global Identifier (GID)
> 
>                 This is one of the Global Identifiers(GIDs)[IB_ARCH]
>                 of the port associated with the IPoIB interface. IB
>                 associates multiple GIDs with a port. It is
>                 RECOMMENDED that the GID formed by the combination of
>                 the IB subnet prefix and the port's GUID be included
>                 in the link-layer/hardware address.

Is there a better way to write the last sentence? Possible confusion
stems from using such terms as "IB subnet prefix", which I assume is
not supposed to refer to an IP subnet prefix.

>                 routing infrastructure or the SA.

Expand "SA".

> 8.0 Security Considerations
> 
>         This document specifies IP transmission over a multicast
>         network. Any network of this kind is vulnerable to a sender
>         claiming another's identity and forge traffic or eavesdrop. It
>         is the responsibility of the higher layers or applications to
>         implement suitable counter-measures if this is a problem.

could be better. Surely, the security issues in IB are not simply the
same as in other network types?

>         IPv4 defines a limited-broadcast address over the link. All
>         IPv4 hosts that are members of the IPv4 subnet are members of
>         this address. IPv6 defines a multicast address referred to as
>         the all-IP hosts address. IPoIB associates a multicast GID
>         with these addresses [IPoIB_MCAST]. This multicast GID will
>         henceforth be referred to as the broadcast-GID. The
>         broadcast-GID is required to be setup for an IPoIB subnet to
>         be formed.

Rather than point to he other document, it might be better to just
include the relavant text here. 

>         d) Service Level(SL)
> 
>                 The method of determining the SL is not defined in
>                 this document. The SL is determined by any of the IBA
>                 approved methods.

I'd like to better understand this. Is there a default value to use in
the absence of other information? Are there any interoperability
issues constraining what values the sender can put in? Does the sender
need to coordinate with the reciever, for instance?

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