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

On Fri, 2 May 2003, Roy Brabson wrote:

> 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?

My delay - I had hoped to publish the -02.txt along with the
encapsulation draft -04.txt but couldn't. Will publish by 8th.

>
> - 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.

Any IPoIB host/router is required to join the Broadcast-GID. That is how
the subnet is setup. This GID is derived from the  all 1's address in
the case of IPv4; and the all-nodes address in the case of IPv6.

The IP layer requires( v6- RFC1884; v4 - IGMPv2 RFC2236) that the multicast
routers always be ready to accept packets received on the all-routers IP
multicast  address.  Therefore the corresponding all-routers IB MGID must
be "FullMember" joined by the router.

The creation of the all-router IB group therefore is implicit in the IP router
listening on the all-router IP multicast address. The administrator
doesn't need to create it explicitly.


>
> - 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.

Yes, if the all-routers MGID doesn't exist and there are no receivers on
the subnet there is no 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?

An IP application may send the multicast packet to any group. One could
request that the interface be notified of every MGID creation/deletion but the
application(s) might never send any data to those groups. Therefore,
the wildcard report request is something that the implementation will
have to weigh against usage. The choice is upto the implementor.


It does seem like a reasonable thing to request creation/deletion
report on the all-router multicast GID.


>
>   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.

It will work but how is this a better thing to do ? I also
do not think that such behaviour can/should be disallowed.

Will go over the rest and answer later.

Vivek


>
> - 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
> _______________________________________________
> IPoverIB mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ipoverib
>
>

__

Vivek Kashyap
Linux Technology Center, IBM