I had two almost contradictory views after reviewing the document.
The first view is that it is very well-informed and presents a lot of
complex information well. The second view is that it seems lost -- that
it doesn't know what it is trying to do and where it is going.
So, I'm
comfortable seeing it published -- I think some folks will find
it useful, but have some suggestions for how it could be improved to work
as a roadmap for research/thinking about the problem of multicast
mobility in wireless (which I think is what it aspires to be).
Comments:
* First, the draft should be more explicit that its focus is
on multicast IPv6 mobility in WIRELESS environments. You can read
the early part of the draft and think you might be involved
in worrying about someone unplugging from one wired network and plugging
into wired network. Particular odd is that Figure 1 clearly
envisions wireless edge networks (single and multihop) yet never
says wireless anywhere in the text around it..
(Example -- "wireless" appears in the
abstract but then not
again until page 8...)
* The document appears to be seeking to define a set of constraints
within which a solution must appear. I took the step of capitalizing
every MUST/MUST NOT and SHOULD/SHOULD NOT in the document and when you
do that the document is clearly a half-thought-out requirements
document. I suspect the authors would be surprised at themselves if
they undertook the experiment.
I mention it because I often reacted that the document was setting
requirements in one spot but not another and I wondered why.
* in section 2.1, "jointly support unicast and multicast" -- why
not broadcast and anycast as well? (esp. as broadcast is
near universal in wireless and anycast apparently matters)
* in section 2.2.1, 2nd bullet, why would we enable multicast in
a network but ban a particular multicast group from circulation?
(Needs some more explanation here about why this happens -- it is
a surprising restriction not mentioned earlier).
* 2.2.2 uses the word "n-casting" in a context where it is clear
the draft things n-casting is evil, but n-casting is never defined
anywhere in the document.
* 2.4 "Facing deployment complexity, it is desirable that any solution for
mobile multicast SHOULD leave routing protocosl unchanged". [Note
I capitalized SHOULD to point out the restriction here]. Why is this
desired? If we found a
routing approach that worked better for all
environments and supported multicast, wouldn't we prefer that?
* 4.1 -- never mentions that wireless is inherently a broadcast medium
and that there may be opportunities to exploit this feature.
Especially for receivers, an inherently multicast medium makes it
easier to rejoin groups (if the group is already live, you can
immediately listen in).
Craig
_______________________________________________
IRSG mailing list
IRSG at mailman.isi.eduhttp://mailman.isi.edu/mailman/listinfo/irsg
