Subject: [multimob] Charter and draft submission deadlines

From: Stig Venaas <[email-masked]>
Date: Thu, 17 Feb 2011 13:17:08 -0800

Hi

As you all hopefully have seen, we got a new charter
with new goals and milestones, see
http://tools.ietf.org/wg/multimob/charters

In particular we have the following new milestones/goals:

Jun 2011 - Initial version of document on PMIPv6 routing optimizations 
to avoid tunnel convergence problem

Nov 2011 - Initial version of document on PMIPv6 multicast source 
mobility solution

Nov 2011 - Initial version of document on PMIPv6 handover optimizations

These new topics, as well as IGMP/MLD tuning, are of particular
interest for our upcoming meeting. If you want to submit a new
document or update an existing one, please keep the following
submission deadlines in mind.

•2011-03-07 (Monday): Internet Draft Cut-off for initial document (-00) 
submission by 17:00 PT (01:00 Tuesday, March 8 UTC), upload using IETF 
ID Submission Tool.
•2011-03-14 (Monday): Internet Draft final submission cut-off by 17:00 
PT (01:00 Tuesday, March 15 UTC), upload using IETF ID Submission Tool.

For other deadlines and links to the submission tool etc., see
http://www.ietf.org/meeting/cutoff-dates-2011.html#IETF80

Stig

---

From: <[email-masked]>
Date: Fri, 18 Feb 2011 15:01:22 +0100

Dear Stig, all
Thanks for the reminder! AFAIAAO for the first new WI on PMIPv6 routing optimizations to avoid tunnel convergence problem we have at least 4 different drafts available tackling a potential solution such as

I-D.asaeda-multimob-pmip6-extension:
   For a PMIPv6 domain the establishment of a dedicated multicast tunnel
   is proposed which may either be dynamically set up and released or be
   pre-configured in a static manner.  Both mobility entities MAG and
   LMA may be operated as MLD proxy or multicast router.
I-D.zuniga-multimob-smspmip:
   By introducing a Dedicated Multicast LMA (DM-LMA) as topological anchor
   point for multicast traffic the protocol complexity is reduced in terms
   of time consumption for tunnel set-up by definition of pre- or post-
   configured tunnels between LMA and MAG.
I-D.ietf-mboned-auto-multicast:
   WG MBONED (Multicast Backbone Deployment) describes an approach which allows
   for automatic multicast communication without explicit tunnels.  This procedure
   may be applied to isolated multicast-enabled sites or hosts which are attached
   to a network without native multicast support and removes the need for manual
   configuration.
I-D.sijeon-multimob-mms-pmip6:
   This is a direct or local routing approach applicable to a network topology where
   multicast content delivery source is located in the same network as the MN such
   that the optimal multicast service delivery path is not via LMA but directly via MAG

Did I describe the approaches correctly - did I miss something?
Do you think we can start evaluating the different drafts versus each other and for potential migration to a WG document? 
Thanks for your comments!

Best regards
Dirk 
-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Stig Venaas
Gesendet: Donnerstag, 17. Februar 2011 22:17
An: multimob mailing list
Betreff: [multimob] Charter and draft submission deadlines

Hi

*2011-03-07 (Monday): Internet Draft Cut-off for initial document (-00) 
submission by 17:00 PT (01:00 Tuesday, March 8 UTC), upload using IETF 
ID Submission Tool.
*2011-03-14 (Monday): Internet Draft final submission cut-off by 17:00 
PT (01:00 Tuesday, March 15 UTC), upload using IETF ID Submission Tool.

Stig
_______________________________________________
multimob mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/multimob

---

From: Stig Venaas <[email-masked]>
Date: Wed, 23 Feb 2011 13:45:05 -0800

Hi Dirk, thanks for a good summary, comments below.

>     LMA may be operated as MLD proxy or multicast router.

It's a bit unclear to me whether the tunnel approach is the same as the
dedicated multicast LMA below. I haven't compared the two drafts
carefully, but at least it seems to be roughly the same idea. It would
be good to have a comparison.

>     configured tunnels between LMA and MAG.

As I wrote above, how is this compared to the above draft?

>     to a network without native multicast support and removes the need for manual

I guess this could be done, I assume the MAGs would be the AMT gateways
then. Not sure where the AMT relay would be located.
I'm not sure if this is better than having a dedicated tunnel though.

>     that the optimal multicast service delivery path is not via LMA but directly via MAG

Right, so what we are saying is that the MAG can receive multicast
directly, without involving the MAG. I'm tempted to say that AMT is
a special case of this. Basically the MAG receives multicast from
some "outside" mechanism...

I think there will be a need for both approaches, both "dedicated LMA",
and the MAG receiving directly.

> Do you think we can start evaluating the different drafts versus each other and for potential migration to a WG document?

Certainly. The above are just some of my thoughts. It would be great
to see what others think. Getting some discussion and evaluation of
drafts before the meeting would be great.

Stig

---

From: Hitoshi Asaeda <[email-masked]>
Date: Thu, 24 Feb 2011 11:15:48 +0800 (HKT)

Hi,

> be good to have a comparison.

Thanks for your summary and review.

We've updated our PMIPv6 extension draft;
http://tools.ietf.org/html/draft-asaeda-multimob-pmip6-extension-05

Please take a look at it, when you review the above topic.
Thank you.

Regards,
--
Hitoshi Asaeda

---

From: <[email-masked]>
Date: Mon, 28 Feb 2011 18:19:08 +0100

Dear Hitoshi, all
Thanks for the hint - I have read the updated draft and to me the main
difference seems to be that the dual mode operation of MAG as both MLD
proxy and Multicast Router is not longer envisioned.
I assume in ch. 5.1 it should read _statically_ instead of
_statistically_ ... :-)

This approach seems to be the most general one whereas the others
propose either a dedicated Multicast-LMA or a LMA-independent MR.
The Mboned approach seems to be the only one which may also work for
client MIP ... Right?

As first attempt I think of comparing the alternatives in terms of
scalability, copmpatibility with basic Multimob solution, amount of
protocol extensions required, amount of entities (MAG or LMA or both or
none) affected by extensions, ... Other suggestions very welcome!

I am not sure whether this can be completed before Prague, but at least
a draft for start-up may be provided ;-)

Thanks and best regards
Dirk 

Von: [email-masked] [mailto:[email-masked]] Im
Auftrag von Hitoshi Asaeda
Gesendet: Donnerstag, 24. Februar 2011 04:16
An: [email-masked]
Cc: [email-masked]; von Hugo, Dirk
Betreff: Re: [multimob] Charter and draft submission deadlines

Hi,

Regards,

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 28 Feb 2011 13:03:45 -0800 (PST)

Hi Dirk,

> 
> Dear Stig, all
> Thanks for the reminder! AFAIAAO for the first new WI on  PMIPv6 routing 
>optimizations to avoid tunnel convergence problem we have at  least 4 different 
>drafts available tackling a potential solution such  as
> 

>    to a network without native multicast support and removes  the need for 

If you think this draft applies to our charter item then maybe we need a short 
draft explaining how.

Regards,

Behcet