Transmission of IP over InfiniBand (IPoIB)
RFC 4391

Note: This ballot was opened for revision 09 and is now closed.

(Steven Bellovin) Discuss

Discuss (2004-08-30 for -** No value found for 'p.get_dochistory.rev' **)
DISCUSS:
Section 4 says:
    For IPv4, the group ID is only 28-bit long and the rest of the
    bits are filled with 0.


State explicitly where the 0 bits are inserted, i.e., which end of the 
80-bit field.  The exmaple seems to imply that it's 52 bits of 0s 
followed by the group ID, but that isn't clear.


How can a node do an expanding ring search for the scope bits?  What 
results tell you if you've gone too far or not far enough?


5.0:  It is not clear that this:


    The method creation of the broadcast group and the assignment/choice
    of its parameters are upto the implementation and/or the
    administrator of the IPoIB subnet.


will yield interoperable implementations.  What if one implementation 
uses administrative control while another has some 
implementation-specific scheme?  I suggest that administrative control 
be mandatory, while other schemes are optional and 
implementation-dependent.


6.0: It says that "implementation MUST be able to handle packets 
received with or without the use of GRH."  What about sending?  It 
seems that implementations MUST be able to send with GRH.  


7.0 says " Larger and smaller MTUs MAY be supported".  Smaller than 
1280 violates the IPv6 spec, I believe.  This should be clarified here.


10.0: 
    Implementations should cache the information about the existence of
    an IB multicast group, its MLID and other attributes.


What are typical cache lifetimes?  What would suggest longer or shorter 
lifetimes?  What other events should cause cache flushes?

(Margaret Cullen) Yes

(Harald Alvestrand) No Objection

Comment (2004-09-02 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Reviewed by Brian Carpenter, Gen-ART

(Bill Fenner) No Objection

(Ted Hardie) (was Discuss) No Objection

Comment (2004-12-13)
No email
send info
Since my discuss is clearing with no text changes, I'm entering the author's comments to me.
I'm okay with these answers.

>Ted Hardie:
>Discuss:
>[2004-08-30] Section 10 and 11 confused me on a couple of points. 
>First, the emulation of
>promiscuous mode seemed a bit odd; I can understand why you would use it
>if you're medium supports it, but why emulate rather than send the packets
>only to the nodes listening?

The emulation is done on the RECEIVE end since we don't have control on
all the senders. An earlier solution requiring all the senders to also
send a copy of all multicast packets to the routers was rejected in
favor of the emulation.

Also, the emulation is not done for local multicast - the packets are sent 
out to the corresponding IB multicast address. When there are no local 
listeners the packet needs to be received by the router. It was decided by 
the WG to keep the senders simple and let the router do the emulation since 
the triggers are already present.

>
>I was also confused by this:
>
>     Note that for an IPoIB link that spans more than one IB subnet
>     connected by IB routers, an adequate multicast forwarding support at
>     the IB level is required for multicast packets to reach listeners on
>     a remote IB subnet. The specific mechanism for this is beyond the
>     scope of IPoIB.
>
>I realize that the specifics are meant to be elsewhere, but this left me
>unsure about whether it was possible to have IP multicast without using
>the IB multicast at all.  The term "remote IB subnet" also seemed like it
>could be ambiguous if there are multicast nodes on multiple links.

Not sure about the question. IP multicast is building on top of IB
multicast, and hence won't work without IB mulitcast. This paragraph
simply reiterates this fact, especially for those IPoIB links that span
multicast IB links.

>

(Sam Hartman) No Objection

(Scott Hollenbeck) (was Discuss) No Objection

(Russ Housley) (was Discuss) No Objection

Comment (2004-09-01)
No email
send info
  In section 5 and section 7: s/upto/up to/

  In section 12: s/should log error messages/SHOULD log error messages/

(David Kessens) (was Discuss) No Objection

(Allison Mankin) No Objection

Comment (2004-09-02 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
No further objection.

(Thomas Narten) (was Discuss) No Objection

Comment (2004-09-02)
No email
send info
>     attributes, and how to setup basic broadcast and multicast services

s/setup/set up/

>     of its parameters are upto the implementation and/or the

s/upto/up to/

References not split.

(Jon Peterson) No Objection

(Bert Wijnen) No Objection

Comment (2004-09-02 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I have bno futher DISCUSS items (I guess there are enough already)

Comments:
- Refrences must be split in normative/informative

(Alex Zinin) No Objection

Comment (2004-09-02 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
All comments I had seem to be already included in other DISCUSS'es