ipoib-cm nits/clarifications
Dror Goldenberg <[email protected]> Wed, 19 Oct 2005 11:02:06 +0200
| Newsgroups | gmane.ietf.ipoib |
|---|---|
| Message-ID | <[email protected]> |
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
--===============0448433478==
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C5D48C.2BFA9BA2"
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C5D48C.2BFA9BA2
Content-Type: text/plain
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
------_=_NextPart_001_01C5D48C.2BFA9BA2
Content-Type: text/html
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<TITLE>Message</TITLE>
<META content="MSHTML 6.00.2900.2769" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial size=2><SPAN class=430564908-19102005><SPAN
class=466025707-19102005><FONT face=Arial size=2><SPAN
class=466025707-19102005><SPAN class=430564908-19102005><FONT face=Arial
size=2>Technical
comments:</FONT></SPAN></SPAN></FONT></SPAN></SPAN></FONT></DIV>
<DIV><FONT><SPAN class=430564908-19102005><SPAN class=466025707-19102005><FONT>
<DIV><SPAN class=466025707-19102005><SPAN class=466025707-19102005><FONT
face=Arial size=2>-page 7, "The node receiving the IB connection request,
however cannot determine</FONT></SPAN></DIV>
<DIV>
<DIV><SPAN class=466025707-19102005><FONT face=Arial size=2> the
initiating node IP address". I don't think it needs to know the IP address. It
</FONT></SPAN></DIV>
<DIV><SPAN class=466025707-19102005><FONT face=Arial size=2> needs
to know the Link Layer Address.</FONT></SPAN></DIV>
<DIV><SPAN class=466025707-19102005><FONT face=Arial><FONT size=2>
(The solution you propose solves the problem of knowing the peer link layer
address.<SPAN class=430564908-19102005>)</SPAN></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=466025707-19102005><SPAN class=466025707-19102005><FONT
face=Arial size=2></FONT></SPAN></SPAN> </DIV>
<DIV><SPAN class=466025707-19102005><SPAN class=466025707-19102005><FONT
face=Arial size=2>- page 7, section 3.3 - Isn't it worth at least noting that
simultaneous connections are</FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=466025707-19102005><FONT face=Arial size=2><SPAN
class=466025707-19102005> handled differently than the IB
active-active. This can be <SPAN class=430564908-19102005>helpful </SPAN>to
avoid confusion.</SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=466025707-19102005><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=466025707-19102005><FONT face=Arial size=2>- page 7, section
3.3 - need to be explicit about the numerical comparison of </FONT></SPAN></DIV>
<DIV><SPAN class=466025707-19102005><FONT face=Arial size=2> link
layer address. It is unclear who forms the MSbits, it is the QPN or the
GID.</FONT></SPAN></DIV>
<DIV><SPAN class=466025707-19102005><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=466025707-19102005><FONT face=Arial size=2>- page 7, section
3.4, worth noting the following issues:</FONT></SPAN></DIV>
<DIV><SPAN class=466025707-19102005><FONT face=Arial size=2> *
since connection teardown is out of band in IB, some messages in transit can
</FONT></SPAN></DIV>
<DIV><SPAN class=466025707-19102005><FONT face=Arial
size=2>
be dropped as a result of teardown.</FONT></SPAN></DIV>
<DIV><SPAN class=466025707-19102005><FONT face=Arial size=2> *
simultaneous teardown can also happen (and is supported by the IB
architecture)</FONT></SPAN></DIV>
<DIV><SPAN class=466025707-19102005><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=466025707-19102005><SPAN class=430564908-19102005><FONT
face=Arial size=2>- page 10, section 6.0, I don't think that all CM messages
should include the UD QPN</FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=466025707-19102005><SPAN class=430564908-19102005><FONT
face=Arial size=2> and the receive MTU. You need both of them
in REQ. You only need receive MTU</FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=466025707-19102005><SPAN class=430564908-19102005><FONT
face=Arial size=2> in REP. And that's all. The rest are
supposed to be persistent because of the </FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=466025707-19102005><SPAN class=430564908-19102005><FONT
face=Arial size=2> Communication ID being
used.</FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=466025707-19102005><SPAN class=430564908-19102005><FONT
face=Arial size=2> This worth some discussion. I don't think
that the current definition is broken, I just </FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=466025707-19102005><SPAN class=430564908-19102005><FONT
face=Arial size=2> think that it has some
redundancy.</FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=466025707-19102005><SPAN class=430564908-19102005><FONT
face=Arial size=2></FONT></SPAN></SPAN> </DIV>
<DIV><SPAN class=466025707-19102005><SPAN class=430564908-19102005><FONT
face=Arial size=2>- page 10, section 6.0 - what is the final MTU of a connection
? is it the minimum between</FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=466025707-19102005><SPAN class=430564908-19102005><FONT
face=Arial size=2> the two "receive MTU" , or is it hybrid -
different MTU per half connection
?</FONT></SPAN></SPAN></DIV></SPAN></DIV></FONT></SPAN></SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=430564908-19102005><SPAN
class=466025707-19102005></SPAN></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=430564908-19102005><SPAN
class=466025707-19102005></SPAN></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=430564908-19102005><SPAN
class=466025707-19102005><FONT face=Arial size=2>Some
nits:</FONT></SPAN></SPAN></FONT></DIV>
<DIV><SPAN class=430564908-19102005><SPAN class=466025707-19102005><FONT
face=Arial size=2>- page 6, 4th paragraph, "the receiver", remove non ASCII char
following it.</FONT></SPAN></DIV>
<DIV>
<DIV><SPAN class=466025707-19102005><FONT face=Arial size=2>- page 6, 8th
paragraph, "the peer", same comment</FONT></SPAN></DIV>
<DIV><SPAN class=466025707-19102005><FONT face=Arial size=2>- page 6 "RTA"
should be "RTU"</FONT></SPAN></DIV>
<DIV><SPAN class=466025707-19102005><FONT face=Arial size=2>- page 6, "The CM
messages include...Service ID" - this is not true for </FONT></SPAN></DIV>
<DIV><SPAN class=466025707-19102005><FONT face=Arial size=2>
*all* the CM messages. So maybe worth rewording.</FONT></SPAN></DIV>
<DIV><SPAN class=466025707-19102005><FONT face=Arial size=2>- page 7, paragraph
before 3.3, after "node" you have non ASCII, 2 occurrences.</FONT></SPAN></DIV>
<DIV><SPAN class=466025707-19102005>
<DIV><SPAN class=466025707-19102005><FONT face=Arial size=2>- page 7, paragraph
before 3.3, after "sender" you have non ASCII.</FONT></SPAN></DIV>
<DIV><SPAN class=466025707-19102005><FONT face=Arial size=2>- page 12, 12.0
remove non ASCII after "Author"</FONT></SPAN></DIV>
<DIV><SPAN class=466025707-19102005></SPAN><SPAN class=466025707-19102005><SPAN
class=430564908-19102005></SPAN></SPAN><SPAN class=466025707-19102005><FONT
face=Arial size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=466025707-19102005>
<DIV><FONT face=Arial size=2><SPAN class=430564908-19102005>My apologies if I'm
repeating Jerry's comments...</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=430564908-19102005></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN
class=430564908-19102005>-Dror</SPAN></FONT></DIV></SPAN></DIV></SPAN></DIV></SPAN></DIV></BODY></HTML>
------_=_NextPart_001_01C5D48C.2BFA9BA2--
--===============0448433478==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
IPoverIB mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ipoverib
--===============0448433478==--