Re: [Mobopts] [IRSG] review of draft-irtf-mobopts-mmcastv6-ps-06.txt

["Thomas C. Schmidt" <schmidt at informatik.haw-hamburg.de>]

Dear Craig,

many thanks again for your review.

We have now discussed and overlooked things, and are ready to answer: 
please see comments inline.


> --- On *Tue, 3/24/09, Craig Partridge /<craig at aland.bbn.com>/* wrote:
>
>
>     From: Craig Partridge <craig at aland.bbn.com>
>     Subject: [IRSG] review of draft-irtf-mobopts-mmcastv6-ps-06.txt
>     To: irsg at ISI.EDU
>     Date: Tuesday, March 24, 2009, 9:22 AM
>
>
>     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.

This is in a sense quite right: We are trying to comprehensively explore 
the problem space and to present all relevant aspects of the somewhat 
intricate issues. The idea was to write a general reference document 
that summarizes 'all there is to think about' in its corresponding contexts.

In this sense, the document is not going into a particular direction, 
that's right.

>     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...)

Yes, you are right: one should not forget about the obvious.

We added explicit statements in the introduction to link to the wireless 
domain.

>         * 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.

We repeated your experiment and questioned all these occurrences. In 
quite a number of cases we reworded, in particular the "must/must not" 
terms.

In general the document does not make use of normative terms in the 
sense of RFC 2119, so there are repeated occurrences where "should" is 
just used as an English word, in particular like "should preferably do ...".

There are a couple of instances, where requirements drop out of other 
sources. Some originate for instance from normative aspects of existing 
standards (e.g., "must respect scoping restrictions"), some are just 
logical consequences of technical arguments given beforehand (e.g., 
"source must provide address transparency"). The latter are not meant as 
requirements for specific protocols, but as conclusions "if we want to 
achieve this, we have to do the other".

>           I mention it because I often reacted that the document was setting
>           requirements in one spot but not another and I wondered why.
Actually, we tried to keep the solution space as open as possible by 
avoiding any evitable constraint in argumentation.

>         * 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)
:-) The issue we discuss is multicast and thereby assume, a unicast 
routing is present. Broadcast, I suspect, is not exactly an issue, as it 
may be viewed as a special case of multicast (can at least be emulated 
by multicast).
Anycast matters, yes, but it is not required to implement multicast. So 
adding anycast mobility aspects to the document would probably just 
confuse the reader, or am I wrong?


>         * 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).
We added a clarifying remark.
A limited group allowance is not rare these days for administrative 
reasons. A typical example are IPTV deployments, where providers offer 
(allow for) a certain collection of groups (TV channels) they 
(contractually) support. Other IPTV multicast groups they do not support 
(allow) in their networks. So by changing a provider on handover, one 
may enter a domain without the group previously under subscription.

>         * 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.
We added an explanation.

By the way: this is not meant to say n-casting is evil - the document 
just recalls known issues.

>         * 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?

From a technical and research perspective we completely agree: We would 
much rather design an elegant routing protocol than fiddle with proxy 
functions. However, this is a pure deployment argument. Given the 
experiences with slow, limited multicast deployment today, it appears 
much more promising to propose solutions that only require adding some 
'boxes' at the wireless edges and leave the routing core untouched. 
Otherwise, we assume, a timely deployment is hardly to expect.

>         * 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).
Yes, again this is one of the obvious to be mentioned in the beginning 
of section 4. We added this.

I hope we got all your comments and hints right.

Best regards,

Thomas

--

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet                   Fon: +49-40-42875-8452 °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409 °