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

---

From: "H.K. Jerry Chu" <[email-masked]>
Date: Wed, 23 Oct 2002 20:47:40 -0700 (PDT)

Comments are interspersed in the mail text (speaking as a co-author,
not a co-chair).

>talk about possible ways of doing things, rather than saying "do

Do you have any specific example of where the ambiguity lies? The
draft has tried to provide max flexibility by avoiding any details
that belong to implementations, and are therefore not essential for
the interoperability. E.g. on Q_Key, TClass, FlowLabel..., there is no
reason why IPoIB must dictate their values as long as their choices
comply with the IB architecture.

There are also some places (e.g. 9.0) the draft leaves open more
than one possibility. This is because those are implementation
concerns (e.g. caching for better efficiency), and don't affect
interoperability.

>be good interoperability based on the existing text.

I believe the draft has covered all the necessary details for
interoperability. There have been quite some changes in the making in
IBTA in the multicast area. But all the changes are at the IB level.
Therefore none of them should affect interoperability as long as
implementations comply with the amended IB mulitcast design.

Due to the obscure nature of some new IB multicast facilities that
are being added specifically to ease the IPoIB implementations, I do
plan on adding a section explaining their usage in IPoIB once the new
IBA 1.1 spec. is released.

>order to actually implement is very little.

Actually this is not true. The draft is not just about multicast. It
is more about how to draw IP subnet boundaries and defining link
attributes. IB is a fully connected network. There are many possibilities
on how to carve out IP subnets on top of an IB network, using IB subnets
and P_Keys as two knives. AFter some discussions the WG settled on
using IB multicast groups within the same partition to define an IP link
independent of IB link boundary, and using attributes defined by IB
multicast groups to define IP link attributes. This is not some
"background" info that you'll find in any IBA spec. In fact some early
IPoIB proposal didn't rely on multicast as much, and was very different
from what we have today.

Since the draft uses multicast groups to define link boundary, it is
natural to cover both in the same draft. That's why the draft is called
"link and multicast..."

>s/SHALL/should/ (lower case)

Ok.

>be good to spell out the algorithm. The above words are a bit cryptic.

Actually the -00 draft described these steps in a lot of more details.
But then some people felt that it got into too much implementation
details, and preferred the wording to be at a more abstract level. There
was always a practical concern with IBA making a lot of changes in the
multicast area, including too much details will make the draft obsolete
when a new version of IBA comes out.

Personally I feel the paragraph is sufficient by itself. An IPoIB
implementor must understand how to use an IB MC group correctly
according to IBA spec.

>Does this need to be said here? Just say what the  MGID values are

But this is exactly what "Figure 4" says except the "scop" field, and
the latter will come from the all-node MGID.

>problems unless there is agreement?

Yes it could be more specific. But again some difficulty here is caused
by the changing IBA spec that Vivek and I and IBA member companies know
about but can't talk about it in public.

But still I don't think this should cause any interoperability problem
as long as the sender manages to get the packets to the router.

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

Ok this is another example of being vague because of the changing IBA
spec. An older version of the paragraph had a very precise recommendation
based on my knowledge of the upcoming IBA 1.1 spec. But Vivek kindly
reminded me that the information of the new spec. is not to be made
public until IBTA releases it (due in early Nov.) so we removed the
old paragraph.

This will be fixed in a couple of weeks.

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

Actually this is one of the few paragraphs that doesn't really belong
to an IPoIB spec. This should be part of "IB multicast usage guide".
BUt unfortunately the latter doesn't exist.

>to a particular mcast group?

I had a section on it and decided to remove it at Vivek's request.
It will be added back in a few weeks (after IBTA releases the 1.1
spec.)

Jerry

---

From: "H.K. Jerry Chu" <[email-masked]>
Date: Wed, 23 Oct 2002 20:47:40 -0700 (PDT)

Ok.

Jerry