Re: draft-ietf-ipoib-link-multicast-03.txt

Kanoj,
...
<snip>

>Of course, if the typical case is that join/attach will not fail
>(ie the number of mcg's are not too great), we can probably punt
>on this, but at least with a note that a limit on the number of
>IP multicast groups exists depending on member hca's and fabric
>(switch/SM) capability.

How about adding the following note to the draft regarding this
vunerability?

11.0 New Vunerability in IB Multicast

   Many IB multicast functions are subject to new types of failure due
   to resource constrains compared to Ethernet multicast. This includes
   the creation of an IB multicast group, the join call, both the
   "SendOnlyNonMember", the "FullMember", and the "NonMember" joins, and
   the attaching of a QP to a multicast group.

   In general, these failure conditions are implementation dependent,
   and are believed to be rare. Usually a failure can be propagated back
   to a foreground operation to cause the operation to fail. But some IB
   multicast functions are not tied to any foreground operation, making
   their failures difficult to notice. E.g., if an IP multicast router
   attempts to "NonMember" join a newly created multicast group in the
   local subnet, but the join call fails, packet forwarding for that
   particular multicast group will likely to fail silently without the
   notice of local multicast senders. This type of problems add more
   vulnerability to the already unreliable IP multicast operations.

   Implementations should log error messages upon any IB multicast
   failure.  Network administrators should be aware of this
   vulnerability, and preserve enough multicast resources if IP
   multicast will be used heavily, or a certain degree of reliability is
   expected.

Thanks,

Jerry

>
>Thanks.
>
>Kanoj