Subject: [Ipoverib] ipoib-cm nits/clarifications

From: Dror Goldenberg <[email-masked]>
Date: Wed, 19 Oct 2005 11:02:06 +0200

Technical comments:
-page 7, "The node receiving the IB connection request, however cannot
determine
   the initiating node IP address". I don't think it needs to know the IP
address. It 
   needs to know the Link Layer Address.
   (The solution you propose solves the problem of knowing the peer link
layer address.)
 
- page 7, section 3.3 - Isn't it worth at least noting that simultaneous
connections are
    handled differently than the IB active-active. This can be helpful to
avoid confusion.
 
- page 7, section 3.3 - need to be explicit about the numerical comparison
of 
   link layer address. It is unclear who forms the MSbits, it is the QPN or
the GID.
 
- page 7, section 3.4, worth noting the following issues:
    * since connection teardown is out of band in IB, some messages in
transit can 
              be dropped as a result of teardown.
    * simultaneous teardown can also happen (and is supported by the IB
architecture)
 
- page 10, section 6.0, I don't think that all CM messages should include
the UD QPN
    and the receive MTU. You need both of them in REQ. You only need receive
MTU
    in REP. And that's all. The rest are supposed to be persistent because
of the 
    Communication ID being used.
    This worth some discussion. I don't think that the current definition is
broken, I just 
    think that it has some redundancy.
 
- page 10, section 6.0 - what is the final MTU of a connection ? is it the
minimum between
   the two "receive MTU" , or is it hybrid - different MTU per half
connection ?

Some nits:
- page 6, 4th paragraph, "the receiver", remove non ASCII char following it.
- page 6, 8th paragraph, "the peer", same comment
- page 6 "RTA" should be "RTU"
- page 6, "The CM messages include...Service ID" - this is not true for 
    *all* the CM messages. So maybe worth rewording.
- page 7, paragraph before 3.3, after "node" you have non ASCII, 2
occurrences.
- page 7, paragraph before 3.3, after "sender" you have non ASCII.
- page 12, 12.0 remove non ASCII after "Author"
 
My apologies if I'm repeating Jerry's comments...
 
-Dror
_______________________________________________
IPoverIB mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipoverib

---

From: Vivek Kashyap <[email-masked]>
Date: Wed, 19 Oct 2005 10:21:17 -0700 (PDT)

>   (The solution you propose solves the problem of knowing the peer link

ok

>   link layer address. It is unclear who forms the MSbits, it is the QPN or

yes, will add that.

>    * simultaneous teardown can also happen (and is supported by the IB

I left the details out since it should be expected..however, we can add this
information.

>    think that it has some redundancy.

It is easier to go with one format so we can leave it as such.

>   the two "receive MTU" , or is it hybrid - different MTU per half

The receive MTU gives you the peer's minimum value. An implementation can
work this way. However, it might be useful to state it as the minimum
of the two in the draft..since an implementation is likely to use the 
the same size buffers when sending or receiving. That is if A advt. recv of 
32K it will very likely send packets which are only 32K even if the peer 
send a receive MTU of 64K.

thoughts?

> - page 6, 8th paragraph, "the peer", same comment
will do

> - page 6 "RTA" should be "RTU"
ok
>    *all* the CM messages. So maybe worth rewording.
ok..
> - page 12, 12.0 remove non ASCII after "Author"
yep..need to figure out why they got in...

> My apologies if I'm repeating Jerry's comments...

np. thanks for the comments.

Vivek