Re: [multimob] WG: New Version Notification for draft-von-hugo-multimob-future-work-00

"Thomas C. Schmidt" <schmidt@informatik.haw-hamburg.de> Sat, 24 October 2009 21:41 UTC

Return-Path: <schmidt@informatik.haw-hamburg.de>
X-Original-To: multimob@core3.amsl.com
Delivered-To: multimob@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 028613A6946 for <multimob@core3.amsl.com>; Sat, 24 Oct 2009 14:41:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.682
X-Spam-Level:
X-Spam-Status: No, score=-1.682 tagged_above=-999 required=5 tests=[AWL=0.567, BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7tgkc+nXGfj for <multimob@core3.amsl.com>; Sat, 24 Oct 2009 14:41:02 -0700 (PDT)
Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 2CDEF3A679C for <multimob@ietf.org>; Sat, 24 Oct 2009 14:41:01 -0700 (PDT)
Envelope-to: multimob@ietf.org
Received: from e178175179.adsl.alicedsl.de ([85.178.175.179] helo=[192.168.178.20]) by mail2.rz.htw-berlin.de with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from <schmidt@informatik.haw-hamburg.de>) id 1N1oMJ-000FKy-SE; Sat, 24 Oct 2009 23:41:12 +0200
Message-ID: <4AE37471.4000508@informatik.haw-hamburg.de>
Date: Sat, 24 Oct 2009 23:41:05 +0200
From: "Thomas C. Schmidt" <schmidt@informatik.haw-hamburg.de>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Dirk.von-Hugo@telekom.de
References: <643B0A1D1A13AB498304E0BBC80278480176568D@S4DE8PSAAQC.mitte.t-com.de>
In-Reply-To: <643B0A1D1A13AB498304E0BBC80278480176568D@S4DE8PSAAQC.mitte.t-com.de>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de)
Cc: multimob@ietf.org
Subject: Re: [multimob] WG: New Version Notification for draft-von-hugo-multimob-future-work-00
X-BeenThere: multimob@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multicast Mobility <multimob.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/multimob>, <mailto:multimob-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multimob>
List-Post: <mailto:multimob@ietf.org>
List-Help: <mailto:multimob-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multimob>, <mailto:multimob-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 24 Oct 2009 21:41:04 -0000

Hi Dirk,

sorry for being late with replying to your draft proposal.

 From a general perspective, it might be good to think about future work 
in Multimob, but personally I believe that we should concentrate on 
keeping the tight schedule for solutions in the Hiroshima meeting. Once 
we have delivered (excellently & in time) the required contributions, we 
might take the time for a new charter discussion - it will probably be 
2010 then.

In detail, let me first play back on this "pleothera" (plethora ?) thing 
;) :

If you work your way through the PS down to the end, you'll find a 
pretty clear road map 
(http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps-09#page-25):

--------------------------- snip ---------------------------------------
It is recommended that future steps towards extending mobility
services to multicast proceed to first solve the following problems:

      1. Ensure seamless multicast reception during handovers,
         meeting the requirements of mobile IPv6 nodes and networks.
         Thereby address the problems of home subscription without
         n-tunnels, as well as native multicast reception in those
         visited networks, which offer a group communication service.

      2. Integrate multicast listener support into unicast mobility
         management schemes and architectural entities to define a
         consistent mobility service architecture, providing equal
         supporting for unicast and multicast communication.

      3. Provide basic multicast source mobility by designing
         address duality management at end nodes.

--------------------------- snap ---------------------------------------

Still, I'm fairly convinced of that path to go. In shorthand

   1. Complete the MLD optimization issues

   2. Follow the line of unicast mobility protocols

      a.) Minimal multicast in PMIP (we are doing now)
      b.) Optimize PMIP-Multicast
      c.) Extend FMIP/PFMIP, DSMIP, HMIP, Multihoming ...
      d.) Look at NEMO

   3. Design basic source mobility

So this widely agrees with your thoughts, right?

On the contrary, I would tend to disagree about MANET-type of work in 
Multimob. MANET routing works quite differently and multicast/broadcast 
is a fundamental issue there. Leaving this work to the MANET group 
appears much more appropriate to me.

Thanks for thinking ahead!

Cheers,

Thomas

> -----Ursprüngliche Nachricht-----
> Von: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] 
> Gesendet: Montag, 19. Oktober 2009 13:36
> An: von Hugo, Dirk
> Cc: von Hugo, Dirk
> Betreff: New Version Notification for draft-von-hugo-multimob-future-work-00 
> 
> 
> A new version of I-D, draft-von-hugo-multimob-future-work-00.txt has been successfuly submitted by Dirk von Hugo and posted to the IETF repository.
> 
> Filename:	 draft-von-hugo-multimob-future-work
> Revision:	 00
> Title:		 Evaluation of further issues on Multicast Mobility: Potential future work for WG MultiMob
> Creation_date:	 2009-10-19
> WG ID:		 Independent Submission
> Number_of_pages: 8
> 
> Abstract:
> This document discusses potential future extensions on the current 
> work plan of recently approved WG MultiMob (Multicast Mobility).  
> MultiMob charter explicitly states that scope of work will be limited
> to mobility protocols Proxy Mobile IPv6, and multicast group 
> management in terms of IGMPv3/MLDv2 protocols.  Furthermore only
> listener mobility will be dealt with and any modification to these
> existing protocols and to multicast routing protocols are out of
> scope.
>                                                                                   
> 
> 
> The IETF Secretariat.
> 
> 

-- 

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 °