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

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