Re: Reacting to previous messages

[Radia Perlman - Boston Center for Networking <radia.perlman@east.sun.com>]

Dave,

I really don't understand the point of your message. I think it is
counterproductive to continue arguing at this point about, essentially,
unidirectional vs bidirectional trees. We should get the working group
off the ground, and then argue the engineering tradeoffs of various things.
Mostly I think bi vs uni is a minor point, and way too much bandwidth
has been spent arguing about it. (Studying it is a different matter, i.e.,
making lists of pros and cons, and I think that would be fine, but
we should not distract the chairs from getting the working group
off the ground by pretending this is a life and death issue that must
be decided now, and if decided the "wrong" way, the entire working
group is worthless.)
Anything can be supported with
either bi or uni trees, though bi will be more efficient for multisender apps.
The interesting question is, how much more expensive, if at all, would it be
to support bi trees? What functionality, if any, is lost or gained?

You asserted that you raised the question of whether there were any
compelling applications for multisender groups and that "none came up".
This isn't true. There were suggested applications.
Maybe none of those were "compelling"
to you, but reasonable people can disagree about how "compelling" they are.
And even if the suggested apps are only slightly useful, if multisender
apps can be supported AS EASILY as single sender apps, then ANY potentially
useful apps, or the desire to be flexible enough for
new types of apps we haven't yet thought of
would be sufficient reason to support them. Note again that customer
demand drove the PIM implementors to support bidirectional trees, not
just researchers thinking it would be a cool thing to do, and that
just doesn't seem to mesh well with the assertion that nobody can
think of any worthwhile multisender apps.

What I think most of the people in this working group agree on is that
groups should be identified in such a way that multicast addresses are
administered locally (by a single node), and be part of the group ID that
endnodes join to eliminate the necessity for routing to figure out how
to route to class D addresses. That's 90% of the
spirit of both Express and SM, and I'd think any supporter of either
approach should be happy with an outcome that preserves those properties.
There's no reason to be divisive about
details, especially at this point in the WG. And I fully support coming
up with a different, neutral name at this point so it isn't an ego fight
of "ours" vs "theirs", but instead is viewed as something we all contribute
to and support.

Radia