Subject: [Ipoverib] AD review comments on draft-ietf-ipoib-link-multicast-02.txt

From: Thomas Narten <[email-masked]>
Date: Mon, 21 Oct 2002 15:03:44 -0400

Here are my review comments on this document. Most seem pretty much to
be of an the editorial nature. But I do have one substantive comment.

Based on my reading of the words, it is not immediately clear how
multicast is supposed to be implemented. The document seems to still
talk about possible ways of doing things, rather than saying "do
this". Has this text all been updated to be in sync with the more
recent thinking on multicast within IBTA? I'm worried that there won't
be good interoperability based on the existing text.

some of the general background info might be better if moved to
another document. The architecture document? What one needs to know in
order to actually implement is very little.

>   IB network layer uses multicast GIDs (MGIDs), which closely resemble

s/IB/The IB/

>    1280 bytes or greater. To be better compatible with Ethernet, the
>    dominant network media in both the LAN and WAN environment, the IPoIB
>    link MTU SHALL be 1500 bytes or greater. This leaves only 2048 and

s/SHALL/should/ (lower case)

>    When a node is brought up on an IPoIB link identified by a P_Key, it
>    must look for the right broadcast group to join. This is done by
>    constructing the MGID with the link P_Key and the IPoIB signature.
>    The node SHOULD always look for a MGID of a link-local scope first
>    before attempting one with a greater scope.

So, joining the group is non-trivial? this should be spelled out
more. I.e, if the joining of potential groups is interative, it would
be good to spell out the algorithm. The above words are a bit cryptic.

>    Since a MGID allocated for transporting IP multicast datagrams is
>    considered only a transient link-layer multicast address, all IB
>    MGIDs allocated for IPoIB purpose SHOULD have T = 1. The scope bits
>    SHALL be the same as that of the all-node MGID for the same IPoIB
>    link.

Does this need to be said here? Just say what the  MGID values are
that are to be used...

>    networks.  The specific mechanism for a sender to forward packets to
>    routers are left to implementations. One can use, for example, the
>    broadcast group, or the all-router multicast group for this purpose.

seems like this should be specified. Won't there  be interoperability
problems unless there is agreement?

>    The cache may need to be validated periodically. E.g., if SA supports
>    multicast group create/delete traps, the sender should register to
>    monitor the status of the target IB multicast group through event
>    notification. If multicast packets were sent to the all-router
>    multicast group because no local listener existed, the sender must be
>    notified by SA when listeners show up later on the local link. This
>    allows the sender to change the forwarding to the right multicast
>    group.

What is the actual recommendation? Seems like the above is vague...

>    When a node leaves an IP multicast group, it SHOULD notify the SA in
>    order for all the related resources to be freed up. This gives SM an
>    opportunity to delete an IB multicast group that is no longer in use,
>    and free up the MLID allocated for it. The specific algorithm is
>    implementation-dependent, and is out of the scope of this document.

Why not MUST? And is it really OK to leave this as implementation
specific?

how does a router ensure that it gets a copy of all mcast packets sent
to a particular mcast group?

Thomas
_______________________________________________
IPoverIB mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipoverib