Comments on draft-ietf-ipoib-link-multicast-04.txt

I've just started to look at IPoIB, so please forgive me if some of the 
comments below have been discussed previously.  I did try to read through 
the mailing list archive, but may have missed some of the relevant posts.

- The draft contains a reference to draft-ietf-ipoib-architecture-01.txt. 
  This is an expired draft which hasn't been updated in almost 18 months. 
  Should this reference be deleted, or is referenced draft updated and 
  published as an RFC?

- In Section 9.0, am I correct in assuming that all routers MUST join the 
  all-routers multicast group if it exists?  And, if one does not exist, 
  shouldn't the router create the group when it first connects to the IB 
  subnet as a "FullMember"?  This section also makes it sound as though 
  the IB administrator must create the all-router multicast group, which 
  doesn't seem to be necessary.  And it doesn't describe if/when/how a 
  router is expected to join the all-router multicast group.

- Section 9.0 indicates that "The packet SHOULD be forwarded to locally 
  connected routers.  [snip] The specific mechanism for a sender to 
  forward packets to routers are left to implementations".  At a 
  minimum, I think the exact implementation needs to be specified.  The 
  text suggests using all-router multicast group or the broadcast group. 
  If a router is required to create the all-router multicast group (see 
  the previous comment), then wouldn't it be sufficient to check for the 
  existence of the all-router multicast group and, if it exists, send to 
  that?  If it doesn't exist, then there can't be any multicast routers 
  on the link, and since there aren't any local listeners there are no 
  on-link listeners there isn't any need to send the packet.

  And shouldn't the IPoIB sender subscribe to the IB multicast group 
  creation events using a wildcard MGID so that it can 
  "SendOnlyNonMember" join the group if a listener appears on the local 
  IB subnet, or "SendOnlyNonMember" join the all-routers group if a 
  router appears on-link and creates the all-routers multicast group? 
  And doesn't it need to subscribe to the IB multicast group deletion 
  events so that it knows when to switch back to sending to the 
  all-router multicast group and/or stop sending?

  But I'm wondering why a node needs to do this at all.  Wouldn't it 
  make more sense for the IPoIB node instead create the multicast group 
  and join the group so that IPoIB multicast routers can join the group? 
  Yes, the IPoIB sender will need create the group as a "FullMember", 
  but this seems to provide a simpler mapping of IP multicast to IB 
  multicast.

- Section 9.0 also indicates that "A multicast sender must join the 
  target multicast group as a "SendOnlyNonMember" before outgoing 
  messages from it can be successfully routed." This text should be 
  clarified to indicate this is only true if the node has not already 
  joined the group as either a "FullMember" or "SendOnlyNonMember".  The 
  If-Then-Else logic below correctly shows this behavior, but this 
  paragraph does not reflect that behavior.

- Section 9.0 states that the MGID cache may need to be validated 
  periodically.  I think it would be useful to indicate why this might 
  be necessary, how a node should go about doing so, and what action 
  should be taken if the MGID is found to be invalid.  I'm assuming that 
  this would be done by checking with the SA on the outbound link for a 
  "MCMemberRecord" that matches the MGID and, if not found, creating the 
  multicast group and rejoining.

- Section 9.0 indicates that "For the rest of attributes, it is 
  recommended the same values from the all-node multicast/broadcast 
  group be used." Should this instead say "For the rest of the 
  attributes, the same values from the all-node multicast/broadcast 
  group SHOULD be used." Regardless of the wording, this text seems to 
  contradict the Section 7.0 which states a node must "use the rest of 
  the link attributes associated with the group for all future 
  communication on the link.  If Section 7.0 is correct, should this be 
  a MUST instead of a SHOULD?  And, if not, under what circumstances 
  would a node choose to not use the same values?

Roy