Subject: Re: [multimob] Fwd: New Version Notification for draft-ietf-multimob-pmipv6-source-01.txt

From: "Seil Jeon" <[email-masked]>
Date: Wed, 25 Jul 2012 22:51:43 +0100

Hi Thomas,

I have simple question on this draft.

How do you think solution scope and objective?
 - Listing all possible ways of supporting source mobility including
optimization?
 - If so, which level do you think should be considered for extension?
 - Wouldn't it be focused on base source mobility deployment option without
optimization?

Now, we have been working on multicast listener solutions separately; base
deployment option [RFC6224] without any modification and extension of
existing standard protocols and multicast mobility routing optimization
[ietf-multimob-pmipv6-ropt].

This draft includes several cases of source mobility support including
optimization. I think listener and source solutions need to be compatible
each other. Are you considering that? And routing optimization for listener
is now being progressed but not finished yet.

Regards,

Seil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Thomas C. Schmidt
Sent: Monday, July 16, 2012 9:37 PM
To: [email-masked]
Subject: [multimob] Fwd: New Version Notification for
draft-ietf-multimob-pmipv6-source-01.txt

Hi all,

we've prepared and uploaded a new version of the source mobility draft. 
The document has been largely extended with the following new contributions:

    1.  Direct routing with PIM-SM and PIM-SSM has been added.

    2.  PMIP synchronization with PIM added for improved handover.

    3.  Direct routing with BIDIR-PIM has been added.

    4.  MLD Proxy extensions requirements added.

    5.  Peering of MLD Proxies added.

    6.  First sketch of multiple upstream proxy added.

    7.  Editorial improvements.

    8.  Updated references.

Comments, feedback & reviews welcome!

See you in Vancouver,

Thomas

-------- Original Message --------
Subject: New Version Notification for 
draft-ietf-multimob-pmipv6-source-01.txt
Date: Mon, 16 Jul 2012 13:32:17 -0700
From: [email-masked]
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]

A new version of I-D, draft-ietf-multimob-pmipv6-source-01.txt
has been successfully submitted by Thomas C. Schmidt and posted to the
IETF repository.

Filename:	 draft-ietf-multimob-pmipv6-source
Revision:	 01
Title:		 Mobile Multicast Sender Support in Proxy Mobile IPv6
(PMIPv6) 
Domains
Creation date:	 2012-07-16
WG ID:		 multimob
Number of pages: 24
URL: 
http://www.ietf.org/internet-drafts/draft-ietf-multimob-pmipv6-source-01.txt
Status: 
http://datatracker.ietf.org/doc/draft-ietf-multimob-pmipv6-source
Htmlized: 
http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-source-01
Diff: 
http://tools.ietf.org/rfcdiff?url2=draft-ietf-multimob-pmipv6-source-01

Abstract:
    Multicast communication can be enabled in Proxy Mobile IPv6 domains
    via the Local Mobility Anchors by deploying MLD Proxy functions at
    Mobile Access Gateways, via a direct traffic distribution within an
    ISP's access network, or by selective route optimization schemes.
    This document describes the support of mobile multicast senders in
    Proxy Mobile IPv6 domains for all three scenarios.  Protocol
    optimizations for synchronizing PMIPv6 with PIM, as well as extended
    MLD Proxy functions are presented.  Mobile sources always remain
    agnostic of multicast mobility operations.

The IETF Secretariat

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

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Thu, 26 Jul 2012 02:01:15 +0200

Hi Seil,

draft-ietf-multimob-pmipv6-source addresses (and is intended to address) 
the solution space for multicast source mobility in PMIP. You're right 
in pointing at compatibility to listener solutions.

According to listener mobility, we explicitly included the basic 
scenarios yet, i.e.,

  * Base solution (RFC 6224)
  * Single proxy upstream (as subject of draft-ietf-multimob-pmipv6-ropt)
  * Direct multicast routing (as subject of draft-ietf-multimob-pmipv6-ropt)

We should address additional aspects, if arising.

In the context of draft-ietf-multimob-pmipv6-ropt, there are several issues:

  1. As you mention, draft-ietf-multimob-pmipv6-ropt contains initial 
trials to route optimization, which it shouldn't. This was approved as 
an informational document explaining simply the deployment cases 
mentioned above.

  2. draft-ietf-multimob-pmipv6-ropt is neither complete, nor concise 
... I would like to point at my earlier review of March 6th which are 
still unaddressed.

Cheers,

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 °

---

From: "Shuai Gao" <[email-masked]>
Date: Thu, 26 Jul 2012 18:04:33 +0800

Hi Luis,
	Thanks for your comments. I'd like to make some supplements inline on base of Thomas's answers.	

======= 2012-07-26 07:44:09 您在来信中写道：=======

>Hi Luis,
>
>many thanks for your comments, please see answers inline:
>
>On 24.07.2012 19:52, LUIS MIGUEL CONTRERAS MURILLO wrote:
>
>> 1/ The draft presents two main scenarios of source mobility. ...
>>The question is: Do you not consider the MAG as
>> multicast router for the base solution just because the functionality
>> defined for the MAGs in RFC6224 is MLD proxy, or actually you are not
>> considering the MAG as multicast router as an option to deliver
>> multicast traffic through the home network via the LMA?
>
>SEction 3 only refers to the base solution (aka RFC 6224). Full 
>multicast routing functions at MAGs are the topic of Section 4.
>
>On the contrary, if the MAG is a multicast router (using an unmodified 
>multicast routing protocol like some sort of PIM), then multicast data 
>distribution follows the forwarding states implemented by join and leave 
>operations (the TIB or MFIB).
>
>The solution you envision ("multicast router ... to deliver multicast 
>traffic through the home network via the LMA") would require static, 
>exclusive, source-specific forwarding states for all groups in the MFIB. 
>That's not how (dynamic) multicast routing works.

Actually, as a multicast router (PIM-SM), the MAG delivers the mutlicast traffic through the home network via the LMA only after the RP or the DRs of receivers initiate source-specific Join, which cases are described in section 4.3.3 and 4.3.4. 

>
>>
>> 2/ In figure 2, just after MLD proxy configuration statement, you depict
>> the sequence MLD Query (from MAG2 to MN2), Mcast Data (from MN2 to
>> MAG2). I think it is a bit confusing. As far as I understand, the MN2  ...
>>
>Figure 2 adapts the call-flow of the base solution. The MLD Query is 
>needed to establish appropriate multicast listener states at the MAG 
>after a handover.
>
>You are right that the Query is not needed for the source to send 
>multicast data. It is also unnecessary for forwarding traffic to the 
>LMA. We can remove it.   
The Query is not needed. However, it's difficult to discriminate whether the newly attached MN is a multicast listener or source according to current protocol. To be compatible with RFC 6224, the Query can be kept here, I think. Of course, the Query should not be sent if the MAG definitely knows the newly MN is a multicast source. 

>> 9/ In section 5.1 you introduce the multiple upstream interface proxy
>> idea as a way of eliminating routing loops, needing additional rules and
>> process for it. In my opinion, the MTMA concept is a simpler way of
>> having the same results.
>>
>T
>Gee no! - the multiple upstream proxy is a way to attach to multiple 
>LMAs/PIM Routers from a single proxy instance. This bears the strong 
>risk of routing loops ... so any solution must assure to avoid those.
>
The multiple upstream interface proxy can help address local routing optimization problem by deploying single proxy instance with multiple upstream interfaces. Regarding the routing loops and redundant traffic problem, we are working on this and will add corresponding detail scheme to avoid it in next version.  
Thanks
Shuai

Shuai Gao
National Engineering Lab for Next Generation Internet Interconnection Devices
Beijing Jiaotong University
Beijing, China, 100044
[email-masked]
2012-07-26

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Fri, 27 Jul 2012 10:30:07 +0200

Thanks Shuai for your clarifications.

Just one comment about your answer about the Query message in figure 2. I think we are all on the same page. What I would suggest is to depict in a more clear way that the MLD Query, needed basically to determine the multicast listener nature of the MN, run in parallel with the fact of delivering multicast traffic if the MN acts as a source. As it is depicted now, as a sequential flow, can be a little bit confusing.

Thanks again,

Best regards,

Luis

-----Mensaje original-----
De: Shuai Gao [mailto:[email-masked]]
Enviado el: jueves, 26 de julio de 2012 12:05
Para: Thomas C. Schmidt; LUIS MIGUEL CONTRERAS MURILLO
CC: multimob
Asunto: Re: Re: [multimob] Fwd: New Version Notification fordraft-ietf-multimob-pmipv6-source-01.txt

Hi Luis,

>>The question is: Do you not consider the MAG as  multicast router for
>>the base solution just because the functionality  defined for the MAGs
>>in RFC6224 is MLD proxy, or actually you are not  considering the MAG
>>as multicast router as an option to deliver  multicast traffic through
>>the home network via the LMA?
>
>distribution follows the forwarding states implemented by join and
>leave operations (the TIB or MFIB).
>

>
>>
>> 2/ In figure 2, just after MLD proxy configuration statement, you
>> depict the sequence MLD Query (from MAG2 to MN2), Mcast Data (from
>> MN2 to MAG2). I think it is a bit confusing. As far as I understand, the MN2  ...
>>

Thanks
Shuai

Shuai Gao

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: "Seil Jeon" <[email-masked]>
Date: Fri, 27 Jul 2012 10:58:28 +0100

Hi Thomas,

As you pointed it out, multicast mobility routing optimization needs to be
addressed well. In Vancouver meeting, that would be discussed.

And regarding on your answer to my question,

if you are intending to present all the possible ways including
optimization, don't you think this needs to go along with
draft-ietf-multimob-pmipv6-ropt, even though it is informational?

Seil

-----Original Message-----
From: Thomas C. Schmidt [mailto:[email-masked]] 
Sent: Thursday, July 26, 2012 1:01 AM
To: Seil Jeon
Cc: [email-masked]
Subject: Re: [multimob] Fwd: New Version Notification for

Hi Seil,

draft-ietf-multimob-pmipv6-source addresses (and is intended to address) the
solution space for multicast source mobility in PMIP. You're right in
pointing at compatibility to listener solutions.

According to listener mobility, we explicitly included the basic scenarios
yet, i.e.,

  1. As you mention, draft-ietf-multimob-pmipv6-ropt contains initial trials
to route optimization, which it shouldn't. This was approved as an
informational document explaining simply the deployment cases mentioned
above.

  2. draft-ietf-multimob-pmipv6-ropt is neither complete, nor concise ... I
would like to point at my earlier review of March 6th which are still
unaddressed.

Cheers,

Thomas

On 25.07.2012 23:51, Seil Jeon wrote:
>   - Wouldn't it be focused on base source mobility deployment option 
> without optimization?
>
> Now, we have been working on multicast listener solutions separately; 
> base deployment option [RFC6224] without any modification and 
> extension of existing standard protocols and multicast mobility 
> routing optimization [ietf-multimob-pmipv6-ropt].
>
> optimization. I think listener and source solutions need to be 
> compatible each other. Are you considering that? And routing 
> optimization for listener is now being progressed but not finished yet.
>
>
> Regards,
>
> Seil
>
>
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Thomas C. Schmidt

--

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Fri, 27 Jul 2012 12:29:28 +0200

Hi Seil,

> draft-ietf-multimob-pmipv6-ropt, even though it is informational?

No problem with informational ... and as I wrote previously: it does go 
along with the deployment options of draft-ietf-multimob-pmipv6-ropt (up 
to the point where this is specific) - the corresponding pointers are 
already in the draft.

Cheers,

Thomas

---

From: "Seil Jeon" <[email-masked]>
Date: Mon, 30 Jul 2012 00:49:07 +0100

Hi Thomas,

Then, O.K.

See you soon.

Regards,

Seil

On Fri, 27 Jul 2012 12:29:28 +0200
  "Thomas C. Schmidt" <[email-masked]> wrote:
> No problem with informational ... and as I wrote 
>previously: it does go along with the deployment options 
>of draft-ietf-multimob-pmipv6-ropt (up to the point where 
>this is specific) - the corresponding pointers are 
>already in the draft.
> 
> Cheers,
> 
> Thomas
> 
>> From: Thomas C. Schmidt 
>>[mailto:[email-masked]]
>>> The document has been largely extended with the 
>>>following new
>> contributions:
>>>