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

Craig Partridge <> Fri, 10 April 2009 17:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 556D43A6A25 for <>; Fri, 10 Apr 2009 10:21:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.8
X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TDmxOwrP2KK2 for <>; Fri, 10 Apr 2009 10:21:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2529C28C138 for <>; Fri, 10 Apr 2009 10:20:56 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 4EB2828E155; Fri, 10 Apr 2009 13:22:03 -0400 (EDT)
To: "Thomas C. Schmidt" <>
In-Reply-To: Your message of "Sat, 28 Mar 2009 01:32:17 PDT." <>
Date: Fri, 10 Apr 2009 13:22:03 -0400
From: Craig Partridge <>
Message-Id: <>
X-Mailman-Approved-At: Fri, 10 Apr 2009 11:08:26 -0700
Cc: Rajeev Koodli <>, irsg@ISI.EDU, Craig Partridge <>,
Subject: Re: [Mobopts] [IRSG] review of draft-irtf-mobopts-mmcastv6-ps-06.txt
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobility Optimizations <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 10 Apr 2009 17:21:06 -0000

All sounds right from my perspective (sorry for delay -- I was on

In message <>de>, "Thomas C. Schmidt" wr

>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 /<>/* wrote:
>>     From: Craig Partridge <>
>>     Subject: [IRSG] review of draft-irtf-mobopts-mmcastv6-ps-06.txt
>>     To: irsg@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 
>>         * 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" 
>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,
>Prof. Dr. Thomas C. Schmidt
>° Hamburg University of Applied Sciences                   Berliner Tor 7 °
>° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
>°                   Fon: +49-40-42875-8452 °
>°    Fax: +49-40-42875-8409 °