Re: comments on draft-kashyap-ipoib-connected-mode-02.txt

David,

Addressing your comments here rather than inline since this mailer doesn't
do that well:

1. QPN alingnment:
Yes, there was a suggestion on QPN alignment. I'll address it in the next
draft. Please send in any comments if you have any.

2. "In addition to all the above, there may still be some interest from
folks in having the specification choose one of the *C transport types
and a fixed logical MTU."

Is it not an implementation issue? One can choose to enable only the
desired mode and always use the fixed MTU in all negotiations.

3.  ARP in IPoIB-CM.

It is still part of the definiton of IPoIB-CM.  It is just that it won't be
over the Connected modes.We do ARP/RARP over the UD QP.

Vivek

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



                                                                                                                                       
                      "David M. Brean"                                                                                                 
                      <David.Brean@Sun.        To:       [email protected]                                                             
                      COM>                     cc:                                                                                     
                      Sent by:                 Subject:  Re: [Ipoverib] comments on draft-kashyap-ipoib-connected-mode-02.txt          
                      ipoverib-bounces@                                                                                                
                      ietf.org                                                                                                         
                                                                                                                                       
                                                                                                                                       
                      12/12/2004 12:55                                                                                                 
                      PM                                                                                                               
                                                                                                                                       
                                                                                                                                       




Hello,

Vivek Kashyap wrote:

snip ...

>
>ok..let me posit what seems to be the summary to me (looking for more
comments
>from WG members here). I'm more or less reverting to the earlier version
of
>the draft.
>
>In an IPoIB subnet:
>
>            - Every interface MUST support IPoIB-UD
>
>            - An interface MAY optionally also support IPoIB-CM (one or
both)
>                        i.e. removing the mutually exclusive restriction
on rc/uc
>                        Note: IIRC, the same serviceID can be used for
both RC/UC.
>                        If not then they have to stay mutually exclusive.
>
>            - Interoperability is maintained by all nodes supporting
IPoIB-UD.
>              Any two interfaces that do not have a connection mode in
common will
>              fall back to IPoIB-UD.
>
>            - The support of any particular IB mode is indicated by the
flags
>              in the link layer address. Note: IPoIB-UD is always
supported and
>              hence there are no flags to indicate UD support.
>
>            - An interface completes the IPoIB-UD address resolution and
then
>          optionally MAY set up RC/UC connections based on the local
support
>              and received flags.
>
>            - A pure IPoIB-UD implementation ignores the RC/UC flags in
link layer
>              address in received packets. It zeroes them on transmit.
>
>            - Every implementation MUST accept all unicast transmissions
received
>              over any of the IPoIB modes it supports. Multicast/Broadcast
by
>              their nature will be transmitted and received over the
IPoIB-UD only.
>
>            ***This implies that an interface MAY transmit/receive a
packet
>                        over any of RC or UC or UD depending on the modes
supported
>                    between the peer IP and itself.***
>
>            - It is an implementation's decision to connect or retry a
connect on
>              failure on the CM modes. This decision is independently made
per
>              transmission or reception of a connection request.
>
>            - An implementation MAY make multiple connections to a peer.
This
>          is a local decision. So is the decision of the peer to refuse
>          such a connection.
>
>            The serviceID, link setup, the link address flags, MTU
negotiation etc.
>            are covered in the draft.
>
>
>

Wasn't there a suggested change to the alignment of the QPN in the
service ID?  (See
http://www1.ietf.org/mail-archive/web/ipoverib/current/msg01158.html).

>            - MTU -- we need to discuss more as below.
>
>
>
snip ...

>
>The interface MTUs at the peers need not be the same at IP or IB layers.
>
>I agree with the concept of just exchanging the max receive MTU at the IB
>connection setup.
>
>
>
In addition to all the above, there may still be some interest from
folks in having the specification choose one of the *C transport types
and a fixed logical MTU.

Also, the I-D mentions ARP and RARP as "protocol types" in the frame
format.  Seems like these would not apply to connected modes.

-David





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

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