Subject: Re: [DMM] 答复: Re: Multicast PS to requirements

From: h chan <[email-masked]>
Date: Tue, 4 Dec 2012 18:45:28 +0000

Any changes/clarifications to PS6?

PS6: Duplicate multicast traffic
IP multicast distribution over architectures using IP mobility solutions may lead to convergence of duplicated multicast subscriptions towards the tunnel’s downstream entity (e.g. MAG in PMIPv6).  Concretely, when multicast subscription for individual mobile nodes is coupled with mobility tunnels, duplicate multicast subscription(s) is prone to be received through different upstream paths. This problem is potentially more severe in a distributed mobility environment [draft-sfigueiredo-multimob-use-case-dmm-03].

H Anthony Chan

From: [email-masked] [mailto:[email-masked]] On Behalf Of Seil Jeon
Sent: Thursday, November 22, 2012 4:27 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [DMM] 答复: Re: Multicast PS to requirements

Hi Luo,

Additionally following the comment by Sergio,

From: [email-masked] [mailto:[email-masked]] On Behalf Of Sergio Figueiredo
Sent: Thursday, November 22, 2012 9:35 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [DMM] 答复: Re: Multicast PS to requirements

Hi Luo,

Thanks for your comment. My answer is placed inline:

On 11/22/2012 08:02 AM, [email-masked]<mailto:[email-masked]> wrote:

Hi Sérgio

> PS6: Duplicate multicast traffic
> IP multicast distribution over architectures using IP mobility solutions  may lead to convergence of duplicated multicast subscriptions towards the tunnel’s downstream entity (e.g. MAG in PMIPv6).  >Concretely, when multicast subscription for individual mobile nodes is coupled with mobility tunnels, duplicate multicast subscription(s) is prone to be received through different upstream paths. This problem is potentially more severe in a distributed mobility environment [draft-sfigueiredo-multimob-use-case-dmm-03].

>[Luis>>] This seems not to be a problem of the IP mobility solutions handling multicast traffic with mobility tunnels in general, but a problem of considering several upstream paths ending on the same mobility access router as a consequence of extending tunnels from previousMAR to newMAR to forward the multicast traffic.

> [SF] Exactly. Which is more than likely to happen in a DMM solution, where all "mobility entities" may act as "mobility access routers", and, after mobility, we want to take advantage of the tunnel for the subscription. In those cases, care must be taken in order to not greatly magnify convergence problem observed e.g. in RFC6224.

[Luowen] According to the above discussion, I believe the PS6  is based on the usage scenarios discussed in draft-sfigueiredo-multimob-use-case-dmm-03. But, it seems to me the usage scenarios in this draft is based on a assumed dmm unicast solution and architecture. IMHO, the PS should be based on current existing protocol (e.g. RFC) or current deployment, not a assumed solution.
SF: PS6 is observable is both existing protocols (e.g. RFC6224) and in the use cases we analyzed - in a PMIPv6-based DMM solution. So I assume the PS fits in the REQs document. As I said before, if ignored, the tunnel convergence problem might be a much serious problem than in RFC6224.

>> In the use case draft, there are any solutions not assumed. We presented use cases, having various deployments of existing multicast standard entities, and corresponding analysis based on distributed deployment specified in DMM REQ1.
No more, no less.

Regards,

Seil

Sérgio Figueiredo <[email-masked]><mailto:[email-masked]>
发件人:  [email-masked]<mailto:[email-masked]>

2012/11/21 07:21

收件人

[email-masked]<mailto:[email-masked]>

抄送

主题

Re: [DMM] Multicast PS to requirements

Hi Luis,

A few more comments on this inline:

Em 20-11-2012 19:46, LUIS MIGUEL CONTRERAS MURILLO escreveu:
Hi Anthony,

some comments in line

Best regards,

Luis

De: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] En nombre de h chan
Enviado el: martes, 20 de noviembre de 2012 18:51
Para: Sérgio Figueiredo; [email-masked]<mailto:[email-masked]>
Asunto: [DMM] Multicast PS to requirements

Let us also use another thread to check for consensus of the PS from multimob.

PS1 (revised): Non-optimal routes
Routing via a centralized anchor often results in a longer route. The problem is especially manifested when accessing a local server or servers of a Content Delivery Network (CDN), or when receiving / sending IP multicast packets.
[Luis>>] This is correct if the multicast content is locally available. However this could not be always the case for multicast listeners, for a number of reasons (for instance, conflict in the multicast address allocation between the Home Network and the DMM domain).

[SF] Sure, and the same applies to "accessing a local server a CDN" - it is implicit that the content is locally available. But it can be improved as "when receiving locally available IP multicast or sending IP multicast".

PS6: Duplicate multicast traffic
IP multicast distribution over architectures using IP mobility solutions  may lead to convergence of duplicated multicast subscriptions towards the tunnel’s downstream entity (e.g. MAG in PMIPv6).  Concretely, when multicast subscription for individual mobile nodes is coupled with mobility tunnels, duplicate multicast subscription(s) is prone to be received through different upstream paths. This problem is potentially more severe in a distributed mobility environment [draft-sfigueiredo-multimob-use-case-dmm-03].

[Luis>>] This seems not to be a problem of the IP mobility solutions handling multicast traffic with mobility tunnels in general, but a problem of considering several upstream paths ending on the same mobility access router as a consequence of extending tunnels from previousMAR to newMAR to forward the multicast traffic.

[SF] Exactly. Which is more than likely to happen in a DMM solution, where all "mobility entities" may act as "mobility access routers", and, after mobility, we want to take advantage of the tunnel for the subscription. In those cases, care must be taken in order to not greatly magnify convergence problem observed e.g. in RFC6224.

Regards,
Sérgio

H Anthony Chan

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Sérgio Figueiredo
Sent: Monday, November 19, 2012 5:24 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [DMM] Multicast requirements

Hi Anthony,

Thank you for trying to progress on this matter. I mostly agree with your analysis.

As for the question you posed, first I would like to exactly understand what you mean with "multicast distribution scenario" in "DMM solutions should enable multicast services which are compatible with multicast distribution scenario, etc.". It seems like there is no major difference between this and the "DMM solutions should enable solutions to support multicast services." requirement? Aren't both expressing the need to enable multicast in a DMM solution?

As you stated, "neglecting" the requirement 7.1 we proposed, leads to the PSs you referred.  So, while 7.2 and 7.3 express the need for DMM solutions to allow deployment of multicast services, 7.1 concerns  "how" IP multicast should be enabled in order to avoid the aforementioned PSs. The usage of the word "flexible"is explained by:

"This flexibility enables different IP multicast flows with respect to a mobile host to be managed (e.g., subscribed, received and/or transmitted) using multiple endpoints".

In other words, compatibility with "multicast distribution scenario" doesn't necessarily avoid PS1 and PS6.

Thank you and best regards,
Sérgio

On 11/19/2012 10:28 PM, h chan wrote:
There are 3 proposals for multicast requirements. Before comparing these proposals, let us understand what are the problems first. Two problem statements have been proposed:

PS1 (revised): Non-optimal routes
Routing via a centralized anchor often results in a longer route. The problem is especially manifested when accessing a local server or servers of a Content Delivery Network (CDN), or when receiving / sending IP multicast packets.
PS6: Duplicate multicast traffic
IP multicast distribution over architectures using IP mobility solutions  may lead to convergence of duplicated multicast subscriptions towards the tunnel’s downstream entity (e.g. MAG in PMIPv6).  Concretely, when multicast subscription for individual mobile nodes is coupled with mobility tunnels, duplicate multicast subscription(s) is prone to be received through different upstream paths. This problem is potentially more severe in a distributed mobility environment [draft-sfigueiredo-multimob-use-case-dmm-03].

Then, let us see whether all the 3 REQ proposals have the same intention. In the following, I rephrase them to highlight their similarities.

REQ7.1: Flexible multicast distribution
DMM solutions should be compatible with flexible multicast distribution scenario. Etc.
The Motivation is to allow flexibility in (enable) multicast solutions to solve the problems PS1 and PS6 as explained in use cases already presented and discussed in multimob wg.

REQ7.2:
DMM solutions should enable solutions to support multicast traffic.

(Original wording was "The DMM (unicast) solution MUST be specified in such a way that it can be extended to also support multicast traffic." I rephrase it to highlight the similarity with the other proposals and also changed the must to should.)

REQ7.3:
DMM solutions should enable solutions to support multicast services.

Original wording was “DMM solutions should support multicast services … etc. Given that it is the scope of multimob and not dmm wg to provide the multicast solution, I think “support” here means “enable” solutions to be developed (by multimob).

Similarity and subtle differences: Both REQ7.2 and REQ7.3 want to enable multicast services. Yet the explanation in REQ7.1 seems to indicate not just to enable any one multicast solution but also needs the flexibility in multicast solution. Not all multicast solutions are the same. Some of them results in PS1 or PS6.

Are there any are essential differences between:
In REQ7.1, DMM solutions should be compatible with flexible multicast distribution scenario, etc.
Versus
DMM solutions should enable multicast services which are compatible with multicast distribution scenario, etc.

H Anthony Chan

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Seil Jeon
Sent: Monday, November 19, 2012 5:15 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [DMM] Multicast requirements

Hi Pierrick,

I’ve many times thought about your question. I would say how effectively should we deploy/support multicast over distributed mobility rather than distributed mobile multicast. As a result, you can find this deployment use case and gap analysis at http://tools.ietf.org/html/draft-sfigueiredo-multimob-use-case-dmm-03 presented in multimob several times.

In unicast DMM, main innovation is to distribute the anchor function at many access routers from single core. Following architectural concept of DMM, flexible multicast distribution is one of multicast requirement resulted from the draft described above.

REQ8: Flexible multicast distribution
"DMM solutions SHOULD be compatible with flexible multicast distribution scenarios. This flexibility enables different IP multicast flows with respect to a mobile host to be managed (e.g., subscribed, received and/or transmitted) using multiple endpoints".

Motivation: The motivation for this requirement is to enable flexibility in multicast distribution. The multicast solution may therefore avoid having multicast-capable access routers being restricted to manage all IP multicast traffic relative to a host via a single endpoint (e.g. regular or tunnel interface), which would lead to the problems described in PS1 and PS6.
PS6: Duplicate multicast traffic
IP multicast distribution over architectures using IP mobility solutions  may lead to convergence of duplicated multicast subscriptions towards the tunnel’s downstream entity (e.g. MAG in PMIPv6).  Concretely, when multicast subscription for individual mobile nodes is coupled with mobility tunnels, duplicate multicast subscription(s) is prone to be received through different upstream paths. This problem is potentially more severe in a distributed mobility environment [draft-sfigueiredo-multimob-use-case-dmm-03].

Regards,

Seil

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Monday, November 19, 2012 8:55 AM
To: [email-masked]<mailto:[email-masked]>'; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [DMM] Multicast requirements

Hi all,

I tend to agree with Georgious, however I still do not figure out what is the use-case for distributed mobile multicast (other than academic considerations)? Can someone give concrete example?

I haven’t real all messages from this thread. So, maybe I missed important points.

BR,
Pierrick

De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] De la part de [email-masked]<mailto:[email-masked]>
Envoyé : samedi 17 novembre 2012 13:01
À : [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc : [email-masked]<mailto:[email-masked]>
Objet : Re: [DMM] Multicast requirements

Hi all,

I also agree that the DMM solution should somehow consider muticast deployment. However, I do not thnk that the DMM WG is the right WG to provide the multicast based DMM solution!

One alternative solution will be to have a multicast requirement that emphasizes the need of having extensibility hooks (possibilities) that can be used later on by the multimob WG to provide a
a multicast enabled DMM solution!

So a requirement that specifies something like the following could be used for this purpose:

"The DMM (unicast) solution MUST be specified in such a way that it can be extended to also support multicast traffic."

Best regards,
Georgios

________________________________

Van: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] namens Seil Jeon [[email-masked]<mailto:[email-masked]>]
Verzonden: vrijdag 16 november 2012 22:25
To: 'Zuniga, Juan Carlos'
Cc: [email-masked]<mailto:[email-masked]>
Onderwerp: Re: [DMM] Multicast requirements
Hi Juan,

I've been looked at changed flow of your proposed text but sorry now that my
comment is posted.
At first time, I couldn't make sure however, on hearing Stig's description,
it seems quite reasonable at the first step, not giving any restrictions but
leaving some-specific for the DMM solution it does not support multicast.

On the other hand, it remains at a basic stage for the DMM solution to
support multicast.
So I think additional requirements need to be made for the DMM solution,
accordingly. But of course, this should not also give any specific
limitation and restriction but should be made towards the direction not
limiting the benefits provided by distributed deployment.

I hope to get more comments on this.

Regards,

Seil

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of
Zuniga, Juan Carlos
Sent: Friday, November 16, 2012 8:14 PM
To: Stig Venaas; [email-masked]<mailto:[email-masked]>
Subject: Re: [DMM] Multicast requirements

> -----Original Message-----
> From: Stig Venaas [mailto:[email-masked]]
> Sent: Friday, November 16, 2012 3:01 PM
> To: jouni korhonen
> Cc: [email-masked]<mailto:[email-masked]>; Zuniga, Juan Carlos; Konstantinos Pentikousis;
> Peter McCann; [email-masked]<mailto:[email-masked]>
> Subject: Re: [DMM] Multicast requirements
>
> On 11/15/2012 3:17 AM, jouni korhonen wrote:
> >
> > On Nov 15, 2012, at 1:03 AM, Behcet Sarikaya wrote:
> >
> >>
> >> I think we are reading too much into multicast and unicast should
be
> >> designed in an integrated manner.
> >>
> >> The fact is that multicast is considered as an area of
> specialization,
> >> it requires knowledge of very different protocols than we are
> >> accustomed to in mobility.
> >
> > "Requirement: DMM solutions SHOULD support multicast services. If a
> specific DMM solution does not support multicast services, an
> explanation MUST be provided."
>
> This sounds good to me.
>
> The main thing I want to achieve is what was describes as motivation
> earlier in this thread. Multicast should at least be considered when
> looking into DMM solutions, and not just an afterthought once the
> solution is decided.
>
> Stig

[JCZ] I fully agree with this. That was the intention of the proposed text.

Regards,

Juan Carlos

>
> > To me that reads basically "do not break foundations for multicast
> unless you have a valid & documented reason for it".  If we look e.g.
> into RFC625 multicast wording that is there very briefly but gives a
> hint to a developer where to head to. That is the level I would expect
> DMM documents should aim to.
> >
> > - Jouni
> >
> >
> >> Let dmm deal with its current charter that does not include a word
> of
> >> multicast and if everything goes well we can come back and discuss
> dmm
> >> multicast.
> >>
> >> Regards,
> >>
> >> Behcet

_______________________________________________
dmm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________
dmm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dmm
_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
dmm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dmm

________________________________

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

_______________________________________________
dmm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________
dmm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dmm

---

From: [email-masked]
Date: Wed, 5 Dec 2012 09:23:12 +0800

Hi

To me, the part of PS6 which are based on the analysis of RFC6224 is fine, 
and my suggestion is to keep the first two sentences and remove the last 
one.

Luowen

h chan <[email-masked]> 
2012/12/05 02:45

收件人
Seil Jeon <[email-masked]>, "[email-masked]" <[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
RE: [DMM]       答复: Re:  Multicast PS to requirements

PS6: Duplicate multicast traffic 
IP multicast distribution over architectures using IP mobility solutions 
may lead to convergence of duplicated multicast subscriptions towards the 
tunnel’s downstream entity (e.g. MAG in PMIPv6).  Concretely, when 
multicast subscription for individual mobile nodes is coupled with 
mobility tunnels, duplicate multicast subscription(s) is prone to be 
received through different upstream paths. This problem is potentially 
more severe in a distributed mobility environment 
[draft-sfigueiredo-multimob-use-case-dmm-03].
 
H Anthony Chan
 
From: [email-masked] [mailto:[email-masked]] On Behalf Of Seil 
Jeon
Sent: Thursday, November 22, 2012 4:27 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [DMM] 答复: Re: Multicast PS to requirements
 
Hi Luo,

From: [email-masked] [mailto:[email-masked]] On Behalf Of 
Sergio Figueiredo
Sent: Thursday, November 22, 2012 9:35 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [DMM] 答复: Re: Multicast PS to requirements
 
Hi Luo,

On 11/22/2012 08:02 AM, [email-masked] wrote:

Hi Sérgio 

> IP multicast distribution over architectures using IP mobility solutions 
 may lead to convergence of duplicated multicast subscriptions towards the 
tunnel’s downstream entity (e.g. MAG in PMIPv6).  >Concretely, when 
multicast subscription for individual mobile nodes is coupled with 
mobility tunnels, duplicate multicast subscription(s) is prone to be 
received through different upstream paths. This problem is potentially 
more severe in a distributed mobility environment 
[draft-sfigueiredo-multimob-use-case-dmm-03]. 
  
>[Luis>>] This seems not to be a problem of the IP mobility solutions 
handling multicast traffic with mobility tunnels in general, but a problem 
of considering several upstream paths ending on the same mobility access 
router as a consequence of extending tunnels from previousMAR to newMAR to 
forward the multicast traffic. 
> [SF] Exactly. Which is more than likely to happen in a DMM solution, 
where all "mobility entities" may act as "mobility access routers", and, 
after mobility, we want to take advantage of the tunnel for the 
subscription. In those cases, care must be taken in order to not greatly 
magnify convergence problem observed e.g. in RFC6224. 
[Luowen] According to the above discussion, I believe the PS6  is based on 
the usage scenarios discussed in 
draft-sfigueiredo-multimob-use-case-dmm-03. But, it seems to me the usage 
scenarios in this draft is based on a assumed dmm unicast solution and 
architecture. IMHO, the PS should be based on current existing protocol 
(e.g. RFC) or current deployment, not a assumed solution.
SF: PS6 is observable is both existing protocols (e.g. RFC6224) and in the 
use cases we analyzed - in a PMIPv6-based DMM solution. So I assume the PS 
fits in the REQs document. As I said before, if ignored, the tunnel 
convergence problem might be a much serious problem than in RFC6224.

>> In the use case draft, there are any solutions not assumed. We 
presented use cases, having various deployments of existing multicast 
standard entities, and corresponding analysis based on distributed 
deployment specified in DMM REQ1.
No more, no less.
 
Regards,
 
Seil

Sérgio Figueiredo <[email-masked]> 
发件人:  [email-masked] 
2012/11/21 07:21 

收件人
[email-masked] 
抄送

主题

Hi Luis,

  
some comments in line 
  
Best regards, 
  
Luis 
  
De: [email-masked] [mailto:[email-masked]] En nombre de h chan
Enviado el: martes, 20 de noviembre de 2012 18:51
Para: Sérgio Figueiredo; [email-masked]
Asunto: [DMM] Multicast PS to requirements 
  
Let us also use another thread to check for consensus of the PS from 
multimob. 
  
PS1 (revised): Non-optimal routes 
Routing via a centralized anchor often results in a longer route. The 
problem is especially manifested when accessing a local server or servers 
of a Content Delivery Network (CDN), or when receiving / sending IP 
multicast packets. 
[Luis>>] This is correct if the multicast content is locally available. 
However this could not be always the case for multicast listeners, for a 
number of reasons (for instance, conflict in the multicast address 
allocation between the Home Network and the DMM domain). 
[SF] Sure, and the same applies to "accessing a local server a CDN" - it 
is implicit that the content is locally available. But it can be improved 
as "when receiving locally available IP multicast or sending IP 
multicast".

PS6: Duplicate multicast traffic 
IP multicast distribution over architectures using IP mobility solutions 
may lead to convergence of duplicated multicast subscriptions towards the 
tunnel’s downstream entity (e.g. MAG in PMIPv6).  Concretely, when 
multicast subscription for individual mobile nodes is coupled with 
mobility tunnels, duplicate multicast subscription(s) is prone to be 
received through different upstream paths. This problem is potentially 
more severe in a distributed mobility environment 
[draft-sfigueiredo-multimob-use-case-dmm-03]. 
  
[Luis>>] This seems not to be a problem of the IP mobility solutions 
handling multicast traffic with mobility tunnels in general, but a problem 
of considering several upstream paths ending on the same mobility access 
router as a consequence of extending tunnels from previousMAR to newMAR to 
forward the multicast traffic. 
[SF] Exactly. Which is more than likely to happen in a DMM solution, where 
all "mobility entities" may act as "mobility access routers", and, after 
mobility, we want to take advantage of the tunnel for the subscription. In 
those cases, care must be taken in order to not greatly magnify 
convergence problem observed e.g. in RFC6224.

Regards,
Sérgio

H Anthony Chan 
  
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sé
rgio Figueiredo
Sent: Monday, November 19, 2012 5:24 PM
To: [email-masked]
Subject: Re: [DMM] Multicast requirements 
 
Hi Anthony,

Thank you for trying to progress on this matter. I mostly agree with your 
analysis.

As for the question you posed, first I would like to exactly understand 
what you mean with "multicast distribution scenario" in "DMM solutions 
should enable multicast services which are compatible with multicast 
distribution scenario, etc.". It seems like there is no major difference 
between this and the "DMM solutions should enable solutions to support 
multicast services." requirement? Aren't both expressing the need to 
enable multicast in a DMM solution?

As you stated, "neglecting" the requirement 7.1 we proposed, leads to the 
PSs you referred.  So, while 7.2 and 7.3 express the need for DMM 
solutions to allow deployment of multicast services, 7.1 concerns  "how" 
IP multicast should be enabled in order to avoid the aforementioned PSs. 
The usage of the word "flexible"is explained by: 

"This flexibility enables different IP multicast flows with respect to a 
mobile host to be managed (e.g., subscribed, received and/or transmitted) 
using multiple endpoints". 

In other words, compatibility with "multicast distribution scenario" 
doesn't necessarily avoid PS1 and PS6.

On 11/19/2012 10:28 PM, h chan wrote: 
There are 3 proposals for multicast requirements. Before comparing these 
proposals, let us understand what are the problems first. Two problem 
statements have been proposed: 
  
PS1 (revised): Non-optimal routes 
Routing via a centralized anchor often results in a longer route. The 
problem is especially manifested when accessing a local server or servers 
of a Content Delivery Network (CDN), or when receiving / sending IP 
multicast packets. 
PS6: Duplicate multicast traffic 
IP multicast distribution over architectures using IP mobility solutions 
may lead to convergence of duplicated multicast subscriptions towards the 
tunnel’s downstream entity (e.g. MAG in PMIPv6).  Concretely, when 
multicast subscription for individual mobile nodes is coupled with 
mobility tunnels, duplicate multicast subscription(s) is prone to be 
received through different upstream paths. This problem is potentially 
more severe in a distributed mobility environment 
[draft-sfigueiredo-multimob-use-case-dmm-03]. 
  
Then, let us see whether all the 3 REQ proposals have the same intention. 
In the following, I rephrase them to highlight their similarities. 
  
REQ7.1: Flexible multicast distribution 
DMM solutions should be compatible with flexible multicast distribution 
scenario. Etc. 
The Motivation is to allow flexibility in (enable) multicast solutions to 
solve the problems PS1 and PS6 as explained in use cases already presented 
and discussed in multimob wg. 
  
REQ7.2: 
  
(Original wording was "The DMM (unicast) solution MUST be specified in 
such a way that it can be extended to also support multicast traffic." I 
rephrase it to highlight the similarity with the other proposals and also 
changed the must to should.) 
  
REQ7.3: 
  
Original wording was “DMM solutions should support multicast services … 
etc. Given that it is the scope of multimob and not dmm wg to provide the 
multicast solution, I think “support” here means “enable” solutions to 
be developed (by multimob). 
  
Similarity and subtle differences: Both REQ7.2 and REQ7.3 want to enable 
multicast services. Yet the explanation in REQ7.1 seems to indicate not 
just to enable any one multicast solution but also needs the flexibility 
in multicast solution. Not all multicast solutions are the same. Some of 
them results in PS1 or PS6. 
  
Are there any are essential differences between: 
In REQ7.1, DMM solutions should be compatible with flexible multicast 
distribution scenario, etc. 
Versus 
DMM solutions should enable multicast services which are compatible with 
multicast distribution scenario, etc. 
  
H Anthony Chan 
  
From: [email-masked] [mailto:[email-masked]] On Behalf Of Seil 
Jeon
Sent: Monday, November 19, 2012 5:15 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [DMM] Multicast requirements 
  
Hi Pierrick, 
  
I’ve many times thought about your question. I would say how effectively 
should we deploy/support multicast over distributed mobility rather than 
distributed mobile multicast. As a result, you can find this deployment 
use case and gap analysis at 
http://tools.ietf.org/html/draft-sfigueiredo-multimob-use-case-dmm-03 
presented in multimob several times. 
  
In unicast DMM, main innovation is to distribute the anchor function at 
many access routers from single core. Following architectural concept of 
DMM, flexible multicast distribution is one of multicast requirement 
resulted from the draft described above. 
  
REQ8: Flexible multicast distribution 
"DMM solutions SHOULD be compatible with flexible multicast distribution 
scenarios. This flexibility enables different IP multicast flows with 
respect to a mobile host to be managed (e.g., subscribed, received and/or 
transmitted) using multiple endpoints". 

Motivation: The motivation for this requirement is to enable flexibility 
in multicast distribution. The multicast solution may therefore avoid 
having multicast-capable access routers being restricted to manage all IP 
multicast traffic relative to a host via a single endpoint (e.g. regular 
or tunnel interface), which would lead to the problems described in PS1 
and PS6. 
PS6: Duplicate multicast traffic 
IP multicast distribution over architectures using IP mobility solutions 
may lead to convergence of duplicated multicast subscriptions towards the 
tunnel’s downstream entity (e.g. MAG in PMIPv6).  Concretely, when 
multicast subscription for individual mobile nodes is coupled with 
mobility tunnels, duplicate multicast subscription(s) is prone to be 
received through different upstream paths. This problem is potentially 
more severe in a distributed mobility environment 
[draft-sfigueiredo-multimob-use-case-dmm-03].

Regards, 
  
Seil 
  
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, November 19, 2012 8:55 AM
To: [email-masked]'; [email-masked]; 
[email-masked]
Cc: [email-masked]
Subject: RE: [DMM] Multicast requirements 
  
Hi all, 
  
I tend to agree with Georgious, however I still do not figure out what is 
the use-case for distributed mobile multicast (other than academic 
considerations)? Can someone give concrete example? 
  
I haven’t real all messages from this thread. So, maybe I missed 
important points. 
  
BR, 
Pierrick 
  
De : [email-masked] [mailto:[email-masked]] De la part de 
[email-masked]
Envoyé : samedi 17 novembre 2012 13:01
À : [email-masked]; [email-masked]
Cc : [email-masked]
Objet : Re: [DMM] Multicast requirements 
  
Hi all, 
  
I also agree that the DMM solution should somehow consider muticast 
deployment. However, I do not thnk that the DMM WG is the right WG to 
provide the multicast based DMM solution! 
  
One alternative solution will be to have a multicast requirement that 
emphasizes the need of having extensibility hooks (possibilities) that can 
be used later on by the multimob WG to provide a 
a multicast enabled DMM solution! 

So a requirement that specifies something like the following could be used 
for this purpose: 
  
"The DMM (unicast) solution MUST be specified in such a way that it can be 
extended to also support multicast traffic." 

Best regards, 
Georgios 

Van: [email-masked] [[email-masked]] namens Seil Jeon [
[email-masked]]
Verzonden: vrijdag 16 november 2012 22:25
To: 'Zuniga, Juan Carlos'
Cc: [email-masked]
Onderwerp: Re: [DMM] Multicast requirements 
Hi Juan,

I've been looked at changed flow of your proposed text but sorry now that 
my
comment is posted.
At first time, I couldn't make sure however, on hearing Stig's 
description,
it seems quite reasonable at the first step, not giving any restrictions 
but
leaving some-specific for the DMM solution it does not support multicast.

Regards,

Seil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Zuniga, Juan Carlos
Sent: Friday, November 16, 2012 8:14 PM
To: Stig Venaas; [email-masked]
Subject: Re: [DMM] Multicast requirements

> Cc: [email-masked]; Zuniga, Juan Carlos; Konstantinos Pentikousis; 
> Peter McCann; [email-masked]
be
> looking into DMM solutions, and not just an afterthought once the 

[JCZ] I fully agree with this. That was the intention of the proposed 
text.

Regards,

Juan Carlos

[email-masked]

[email-masked]

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc 
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez 
recu ce message par erreur, veuillez le signaler 
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration, 
France Telecom - Orange decline toute responsabilite si ce message a ete 
altere, deforme ou falsifie. Merci. 
  
This message and its attachments may contain confidential or privileged 
information that may be protected by law; 
they should not be distributed, used or copied without authorisation. 
If you have received this email in error, please notify the sender and 
delete this message and its attachments. 
As emails may be altered, France Telecom - Orange is not liable for 
messages that have been modified, changed or falsified. 
Thank you. 

[email-masked] 

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

[email-masked]

[email-masked]

---

From: "Seil Jeon" <[email-masked]>
Date: Wed, 5 Dec 2012 09:53:04 -0000

Hi Anthony,

For me, it’s ok and nice.

Thanks to your hard work.

Regards,

Seil

From: h chan [mailto:[email-masked]] 
Sent: Tuesday, December 04, 2012 6:45 PM
To: Seil Jeon; [email-masked]
Cc: [email-masked]
Subject: RE: [DMM] 答复: Re: Multicast PS to requirements

H Anthony Chan

Hi Luo,

 

Hi Luo,

Hi Sérgio 

No more, no less.

Regards,

Seil

Sérgio Figueiredo  <mailto:[email-masked]> <[email-masked]> 
发件人:  [email-masked] 

2012/11/21 07:21 

收件人

[email-masked] 

抄送

主题

		

Hi Luis,

  
some comments in line 
  
Best regards, 
  
Luis 
  
De:  <mailto:[email-masked]> [email-masked] [ <mailto:[email-masked]> mailto:[email-masked]] En nombre de h chan
Enviado el: martes, 20 de noviembre de 2012 18:51
Para: Sérgio Figueiredo;  <mailto:[email-masked]> [email-masked]
Asunto: [DMM] Multicast PS to requirements 

  

Regards,
Sérgio

H Anthony Chan 
  
From:  <mailto:[email-masked]> [email-masked] [ <mailto:[email-masked]> mailto:[email-masked]] On Behalf Of Sérgio Figueiredo
Sent: Monday, November 19, 2012 5:24 PM
To:  <mailto:[email-masked]> [email-masked]
Subject: Re: [DMM] Multicast requirements 
  
Hi Anthony,

  

  
REQ7.2: 

REQ7.3: 

  
  
H Anthony Chan 
  
From:  <mailto:[email-masked]> [email-masked] [ <mailto:[email-masked]> mailto:[email-masked]] On Behalf Of Seil Jeon
Sent: Monday, November 19, 2012 5:15 AM
To:  <mailto:[email-masked]> [email-masked]
Cc:  <mailto:[email-masked]> [email-masked]
Subject: Re: [DMM] Multicast requirements 
  
Hi Pierrick, 
  
I’ve many times thought about your question. I would say how effectively should we deploy/support multicast over distributed mobility rather than distributed mobile multicast. As a result, you can find this deployment use case and gap analysis at  <http://tools.ietf.org/html/draft-sfigueiredo-multimob-use-case-dmm-03> http://tools.ietf.org/html/draft-sfigueiredo-multimob-use-case-dmm-03 presented in multimob several times. 

Regards, 
  
Seil 
  
From:  <mailto:[email-masked]> [email-masked] [ <mailto:[email-masked]> mailto:[email-masked]] 
Sent: Monday, November 19, 2012 8:55 AM
To: ' <mailto:[email-masked]> [email-masked]';  <mailto:[email-masked]> [email-masked];  <mailto:[email-masked]> [email-masked]
Cc:  <mailto:[email-masked]> [email-masked]
Subject: RE: [DMM] Multicast requirements 
  
Hi all, 

  
BR, 
Pierrick 
  
De :  <mailto:[email-masked]> [email-masked] [ <mailto:[email-masked]> mailto:[email-masked]] De la part de  <mailto:[email-masked]> [email-masked]
Envoyé : samedi 17 novembre 2012 13:01
À :  <mailto:[email-masked]> [email-masked];  <mailto:[email-masked]> [email-masked]
Cc :  <mailto:[email-masked]> [email-masked]
Objet : Re: [DMM] Multicast requirements 
  
Hi all, 

  

Best regards, 
Georgios 

  _____  

Van:  <mailto:[email-masked]> [email-masked] [ <mailto:[email-masked]> [email-masked]] namens Seil Jeon [ <mailto:[email-masked]> [email-masked]]
Verzonden: vrijdag 16 november 2012 22:25
To: 'Zuniga, Juan Carlos'
Cc:  <mailto:[email-masked]> [email-masked]
Onderwerp: Re: [DMM] Multicast requirements 
Hi Juan,

Regards,

Seil

-----Original Message-----
From:  <mailto:[email-masked]> [email-masked] [ <mailto:[email-masked]> mailto:[email-masked]] On Behalf Of
Zuniga, Juan Carlos
Sent: Friday, November 16, 2012 8:14 PM
To: Stig Venaas;  <mailto:[email-masked]> [email-masked]
Subject: Re: [DMM] Multicast requirements

> From: Stig Venaas [ <mailto:[email-masked]> mailto:[email-masked]]
> Cc:  <mailto:[email-masked]> [email-masked]; Zuniga, Juan Carlos; Konstantinos Pentikousis; 
> Peter McCann;  <mailto:[email-masked]> [email-masked]
be

Regards,

Juan Carlos

_______________________________________________
dmm mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/dmm> https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________
dmm mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/dmm> https://www.ietf.org/mailman/listinfo/dmm 
_________________________________________________________________________________________________________________________ 

_______________________________________________ 
dmm mailing list 
 <mailto:[email-masked]> [email-masked] 
 <https://www.ietf.org/mailman/listinfo/dmm> https://www.ietf.org/mailman/listinfo/dmm 

  _____  

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> http://www.tid.es/ES/PAGINAS/disclaimer.aspx

_______________________________________________
dmm mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/dmm> https://www.ietf.org/mailman/listinfo/dmm

---

From: "Seil Jeon" <[email-masked]>
Date: Wed, 5 Dec 2012 10:00:19 -0000

Hi Luo,

I’m happy to see we’re coming to agreement gradually. However, unfortunately, the draft is describing two former sentences with available use cases.

As you’re fully aware of this situation caused by duplicate multicast traffic, it’s more severe in DMM environment.

I hope we also get agreement soon.

Regards,

Seil

From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, December 05, 2012 1:23 AM
To: h chan
Cc: [email-masked]; Seil Jeon; Sérgio Figueiredo
Subject: 答复: RE: [DMM] 答复: Re: Multicast PS to requirements

Hi 

To me, the part of PS6 which are based on the analysis of RFC6224 is fine, and my suggestion is to keep the first two sentences and remove the last one. 

Luowen 

2012/12/05 02:45 

收件人

抄送

主题

		

  
H Anthony Chan 

Hi Luo, 

  
Hi Luo,

Hi Sérgio 

No more, no less. 
  
Regards, 
  
Seil 

Sérgio Figueiredo  <mailto:[email-masked]> <[email-masked]> 
发件人:   <mailto:[email-masked]> [email-masked] 

2012/11/21 07:21 

收件人

抄送

主题

  

Hi Luis,

 
some comments in line 
 
Best regards, 
 
Luis 

 

 

Regards,
Sérgio

H Anthony Chan 

Hi Anthony,

 

 
REQ7.2: 

REQ7.3: 

 
 
H Anthony Chan 

Hi Pierrick, 

 

Regards, 
 
Seil 

Hi all, 

 
BR, 
Pierrick 

Hi all, 

 

Best regards, 
Georgios 

  

  _____  

Regards,

Seil

-----Original Message-----

be

Regards,

Juan Carlos

 

  

  _____

---

From: [email-masked]
Date: Thu, 6 Dec 2012 09:11:38 +0800

Hi Seil,

I see the situation caused by duplicate multicast traffic, that is the 
issue brought by RFC 6224, is that true? If it is true, then I think we 
have already got the use case. 
What we should do in my mind is to describe an issue faced by the current 
solution, and to indicate in the PS to remind people to avoid this issue 
when develop dmm unicast solution. 
Anyway, nobody knows whether the dmm unicast solution architecture will 
lead to such issues (e.g. duplicate multicast traffic) when developing 
multicast solution based on it.

How about 
PS6: Duplicate multicast traffic 
IP multicast solution over architectures using IP mobility solutions (e.g. 
RFC6224) may lead to convergence of duplicated multicast subscriptions 
towards the tunnel’s downstream entity (e.g. MAG in PMIPv6).  Concretely, 
when multicast subscription for individual mobile nodes is coupled with 
mobility tunnels (e.g. PMIPv6 tunnel), duplicate multicast subscription(s) 
is prone to be received through different upstream paths. This problem may 
also exist in the distributed mobility management environment.

BR
Luowen

"Seil Jeon" <[email-masked]> 
2012/12/05 18:00

收件人
<[email-masked]>, "'h chan'" <[email-masked]>
抄送
<[email-masked]>, 'Sérgio Figueiredo' <[email-masked]>
主题
RE: RE: [DMM]   答复: Re:  Multicast PS to requirements

Hi Luo,
 
I’m happy to see we’re coming to agreement gradually. However, 
unfortunately, the draft is describing two former sentences with available 
use cases.
As you’re fully aware of this situation caused by duplicate multicast 
traffic, it’s more severe in DMM environment.

Regards,
 
Seil

Hi 

Luowen 

收件人

  
H Anthony Chan 

Hi Luo, 

 
Hi Luo,

Hi Sérgio 

  
Regards, 
  
Seil 

收件人
[email-masked] 
抄送

主题

Hi Luis,

 
some comments in line 
 
Best regards, 
 
Luis 

 

Regards,
Sérgio

H Anthony Chan 

Hi Anthony,

 

 
REQ7.2: 

REQ7.3: 

 
 
H Anthony Chan 

Hi Pierrick, 

 

Regards, 
 
Seil 

Hi all, 

 
BR, 
Pierrick 

Hi all, 

 

Best regards, 
Georgios 

Regards,

Seil

-----Original Message-----

be

Regards,

Juan Carlos

---

From: "Seil Jeon" <[email-masked]>
Date: Thu, 6 Dec 2012 17:45:57 -0000

Hi Luo,

See the inline, please.

Regards,

Seil

From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, December 06, 2012 1:12 AM
To: Seil Jeon
Cc: [email-masked]; 'h chan'; 'Sérgio Figueiredo'
Subject: 答复: RE: RE: [DMM] 答复: Re: Multicast PS to requirements

Hi Seil, 

I see the situation caused by duplicate multicast traffic, that is the issue brought by RFC 6224, is that true? If it is true, then I think we have already got the use case. 
>> Sure. Don’t forget we’re discussing on the DMM. Importantly, this situation may also happen in DMM use cases as long as we use a tunnel scheme as key role of IP mobility.

What we should do in my mind is to describe an issue faced by the current solution, and to indicate in the PS to remind people to avoid this issue when develop dmm unicast solution. 
Anyway, nobody knows whether the dmm unicast solution architecture will lead to such issues (e.g. duplicate multicast traffic) when developing multicast solution based on it. 
>> It’s time to wrap up this argument since I clearly answered in previous mail at 26 November. See them carefully, please. You should distinguish a “solution” and a “status” or “situation” made by a solution.

How about   
PS6: Duplicate multicast traffic 
IP multicast solution over architectures using IP mobility solutions (e.g. RFC6224) may lead to convergence of duplicated multicast subscriptions towards the tunnel’s downstream entity (e.g. MAG in PMIPv6).  Concretely, when multicast subscription for individual mobile nodes is coupled with mobility tunnels (e.g. PMIPv6 tunnel), duplicate multicast subscription(s) is prone to be received through different upstream paths. This problem may also exist in the distributed mobility management environment. 

BR 
Luowen 

2012/12/05 18:00 

收件人

抄送

主题

		

Hi Luo, 

  
Regards, 
  
Seil 

Hi 

Luowen 

h chan < <mailto:[email-masked]> [email-masked]> 

2012/12/05 02:45 

收件人

Seil Jeon < <mailto:[email-masked]> [email-masked]>, " <mailto:[email-masked]> [email-masked]" < <mailto:[email-masked]> [email-masked]> 

抄送

" <mailto:[email-masked]> [email-masked]" < <mailto:[email-masked]> [email-masked]> 

主题

  

 
 
H Anthony Chan 
 
To:  <mailto:[email-masked]> [email-masked]
 
Hi Luo, 

From:  <mailto:[email-masked]> [email-masked] [ <mailto:[email-masked]> mailto:[email-masked]] On Behalf Of Sergio Figueiredo
Sent: Thursday, November 22, 2012 9:35 AM
To:  <mailto:[email-masked]> [email-masked]
Cc:  <mailto:[email-masked]> [email-masked]
Subject: Re: [DMM] 答复: Re: Multicast PS to requirements 
 
Hi Luo,

Hi Sérgio 

No more, no less. 
 
Regards, 
 
Seil 

2012/11/21 07:21 

收件人

抄送

主题

  

Hi Luis,

some comments in line 

Best regards, 

Luis 

Regards,
Sérgio

H Anthony Chan 

Hi Anthony,

REQ7.2: 

REQ7.3: 

H Anthony Chan 

Hi Pierrick, 

Regards, 

Seil 

Hi all, 

BR, 
Pierrick 

Hi all, 

Best regards, 
Georgios 

  

  _____  

Regards,

Seil

-----Original Message-----

be

Regards,

Juan Carlos

  

  _____

---

From: [email-masked]
Date: Mon, 10 Dec 2012 09:25:39 +0800

Hi Seil,

Sorry for the late reply due to the business trip. 

What do you mean by a "solution" and a "status" or "situation" made by a 
solution (as you said in the last email) ?  Both based on a solution, 
right?  That is why I argue with you due to there should be no dmm 
solution in this stage. I truly believe that the PS6 may also exist in the 
distributed mobility management environment. But to me, your draft only 
consider certain possibility in dmm environment, not a compeleted one. 
Then I will not be convinced with the assertion based on such 
in-compeleted scenario analysis. Please read my proposed text below. 
Anyway, I agree with you, it’s time to wrap up this argument, since I 
have already make myself so clear. 

To Anthony: do you have any suggestion since you are in charge.

BR
Luowen

2012/12/07 01:45

收件人
<[email-masked]>
抄送
<[email-masked]>, "'h chan'" <[email-masked]>, 'Sérgio 
Figueiredo' <[email-masked]>
主题
RE: RE: RE: [DMM]       答复: Re:  Multicast PS to requirements

Hi Luo,
 
See the inline, please.
 
Regards,
 
Seil

Hi Seil, 

>> Sure. Don’t forget we’re discussing on the DMM. Importantly, this 
situation may also happen in DMM use cases as long as we use a tunnel 
scheme as key role of IP mobility.
What we should do in my mind is to describe an issue faced by the current 
solution, and to indicate in the PS to remind people to avoid this issue 
when develop dmm unicast solution. 
Anyway, nobody knows whether the dmm unicast solution architecture will 
lead to such issues (e.g. duplicate multicast traffic) when developing 
multicast solution based on it. 
>> It’s time to wrap up this argument since I clearly answered in 
previous mail at 26 November. See them carefully, please. You should 
distinguish a “solution” and a “status” or “situation” made by a 
solution.

How about   

BR 
Luowen 

收件人

Hi Luo, 

  
Regards, 
  
Seil 

Hi 

Luowen 

收件人

 
 
H Anthony Chan 

Hi Luo, 

 
Hi Luo,

Hi Sérgio 

 
Regards, 
 
Seil 

收件人
[email-masked] 
抄送

主题

Hi Luis,

some comments in line 

Best regards, 

Luis 

Regards,
Sérgio

H Anthony Chan 

Hi Anthony,

REQ7.2: 

REQ7.3: 

H Anthony Chan 

Hi Pierrick, 

Regards, 

Seil 

Hi all, 

BR, 
Pierrick 

Hi all, 

Best regards, 
Georgios 

 

Regards,

Seil

-----Original Message-----

be

Regards,

Juan Carlos

---

From: h chan <[email-masked]>
Date: Tue, 11 Dec 2012 01:46:17 +0000

I don’t see big difference in the wording of PS6.
The difference is to remove the reference to the draft-sfigueiredo-multimob-use-case-dmm-03
Then, let me ask the question of whether there is plan to move the draft to a WG draft and eventually become an rfc?
If so, the reference is logically possible.
If not, the individual draft will expire and there will be no assurance that the multimob draft will be permanently available. Then the PS can simply state what can be concluded from the draft if we don’t explicitly reference to the draft.

The rest are minor. The second difference is giving examples. We can add if we don’t see objection.

The third is to add IP multicast solution. Generally, it is better to avoid using the same word “solution” twice in the same sentence. There seems to be no major difference in meaning without adding solution here, is there?

H Anthony Chan

From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, December 09, 2012 7:26 PM
To: Seil Jeon
Cc: [email-masked]; h chan; 'Sérgio Figueiredo'
Subject: 答复: RE: RE: RE: [DMM] 答复: Re: Multicast PS to requirements

Hi Seil,

What do you mean by a "solution" and a "status" or "situation" made by a solution (as you said in the last email) ?  Both based on a solution, right?  That is why I argue with you due to there should be no dmm solution in this stage. I truly believe that the PS6 may also exist in the distributed mobility management environment. But to me, your draft only consider certain possibility in dmm environment, not a compeleted one. Then I will not be convinced with the assertion based on such in-compeleted scenario analysis. Please read my proposed text below.
Anyway, I agree with you, it’s time to wrap up this argument, since I have already make myself so clear.

BR
Luowen

2012/12/07 01:45

收件人

<[email-masked]>

抄送

<[email-masked]>, "'h chan'" <[email-masked]>, 'Sérgio Figueiredo' <[email-masked]>

主题

Hi Luo,

See the inline, please.

Regards,

Seil

Hi Seil,

How about

BR
Luowen
"Seil Jeon" <[email-masked]<mailto:[email-masked]>>

2012/12/05 18:00

收件人

<[email-masked]<mailto:[email-masked]>>, "'h chan'" <[email-masked]<mailto:[email-masked]>>

抄送

<[email-masked]<mailto:[email-masked]>>, 'Sérgio Figueiredo' <[email-masked]<mailto:[email-masked]>>

主题

Hi Luo,

Regards,

Seil

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Wednesday, December 05, 2012 1:23 AM
To: h chan
Cc: [email-masked]<mailto:[email-masked]>; Seil Jeon; Sérgio Figueiredo
Subject: 答复: RE: [DMM] 答复: Re: Multicast PS to requirements

Hi

Luowen
h chan <[email-masked]<mailto:[email-masked]>>

2012/12/05 02:45

收件人

Seil Jeon <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

抄送

"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

主题

H Anthony Chan

To: [email-masked]<mailto:[email-masked]>

Hi Luo,

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Sergio Figueiredo
Sent: Thursday, November 22, 2012 9:35 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [DMM] 答复: Re: Multicast PS to requirements

Hi Luo,

Hi Sérgio

No more, no less.

Regards,

Seil

2012/11/21 07:21

收件人

抄送

主题

Hi Luis,

some comments in line

Best regards,

Luis

Regards,
Sérgio

H Anthony Chan

Hi Anthony,

REQ7.2:

REQ7.3:

H Anthony Chan

Hi Pierrick,

Regards,

Seil

Hi all,

BR,
Pierrick

Hi all,

Best regards,
Georgios

Regards,

Seil

-----Original Message-----

be

Regards,

Juan Carlos

---

From: "Seil Jeon" <[email-masked]>
Date: Tue, 11 Dec 2012 16:12:19 -0000

Hi Anthony,

Some comments are posted on your suggestion. And following is our revised text.

IP multicast distribution over architectures using IP mobility solutions (e.g. RFC6224) may lead to convergence of duplicated multicast subscriptions towards the tunnel’s downstream entity (e.g. MAG in PMIPv6).  Concretely, when multicast subscription for individual mobile nodes is coupled with mobility tunnels (e.g. PMIPv6 tunnel), duplicate multicast subscription(s) is prone to be received through different upstream paths. This problem may also exist or be more severe in a distributed mobility environment.

Regards,

Seil

From: h chan [mailto:[email-masked]] 
Sent: Tuesday, December 11, 2012 1:46 AM
To: [email-masked]; Seil Jeon
Cc: [email-masked]; 'Sérgio Figueiredo'
Subject: RE: RE: RE: RE: [DMM] 答复: Re: Multicast PS to requirements

>> Within that sense, I can also consider to remove the reference. And actually, we don’t know the future of this draft as of now.

>> For me, I don’t see any objection on this.

>> “Distribution” you suggested is much preferred.

H Anthony Chan

Hi Seil, 

BR 
Luowen 

2012/12/07 01:45 

收件人

<[email-masked]> 

抄送

主题

		

Hi Luo, 
  
See the inline, please. 
  
Regards, 
  
Seil 

Hi Seil, 

How about   

BR 
Luowen 

"Seil Jeon" < <mailto:[email-masked]> [email-masked]> 

2012/12/05 18:00 

收件人

< <mailto:[email-masked]> [email-masked]>, "'h chan'" < <mailto:[email-masked]> [email-masked]> 

抄送

< <mailto:[email-masked]> [email-masked]>, 'Sérgio Figueiredo' < <mailto:[email-masked]> [email-masked]> 

主题

  

Hi Luo, 

 
Regards, 
 
Seil 
 
From:  <mailto:[email-masked]> [email-masked] [ <mailto:[email-masked]> mailto:[email-masked]] 
Sent: Wednesday, December 05, 2012 1:23 AM
To: h chan
Cc:  <mailto:[email-masked]> [email-masked]; Seil Jeon; Sérgio Figueiredo
Subject: 答复: RE: [DMM] 答复: Re: Multicast PS to requirements 

Hi 

Luowen 

2012/12/05 02:45 

收件人

抄送

主题

  

H Anthony Chan 

Hi Luo, 

Hi Luo,

Hi Sérgio 

No more, no less. 

Regards, 

Seil 

2012/11/21 07:21 

收件人

抄送

主题

  

		

Hi Luis,

some comments in line 

Best regards, 

Luis 

Regards,
Sérgio

H Anthony Chan 

Hi Anthony,

REQ7.2: 

REQ7.3: 

H Anthony Chan 

Hi Pierrick, 

Regards, 

Seil 

Hi all, 

BR, 
Pierrick 

Hi all, 

Best regards, 
Georgios 

  

  _____  

Regards,

Seil

-----Original Message-----

be

Regards,

Juan Carlos

  

  _____

---

From: [email-masked]
Date: Thu, 13 Dec 2012 08:48:09 +0800

Hi Seil and Anthony

No more comments, thanks.

BR
Luowen

2012/12/12 00:12

收件人
"'h chan'" <[email-masked]>
抄送
<[email-masked]>, 'Sérgio Figueiredo' <[email-masked]>, 
<[email-masked]>
主题
RE: RE: RE: RE: [DMM]   答复: Re:  Multicast PS to requirements

Hi Anthony,
 
Some comments are posted on your suggestion. And following is our revised 
text.
 
IP multicast distribution over architectures using IP mobility solutions 
(e.g. RFC6224) may lead to convergence of duplicated multicast 
subscriptions towards the tunnel’s downstream entity (e.g. MAG in 
PMIPv6).  Concretely, when multicast subscription for individual mobile 
nodes is coupled with mobility tunnels (e.g. PMIPv6 tunnel), duplicate 
multicast subscription(s) is prone to be received through different 
upstream paths. This problem may also exist or be more severe in a 
distributed mobility environment.
 
Regards,
 
Seil

I don’t see big difference in the wording of PS6. 
The difference is to remove the reference to the 
draft-sfigueiredo-multimob-use-case-dmm-03
Then, let me ask the question of whether there is plan to move the draft 
to a WG draft and eventually become an rfc?
If so, the reference is logically possible. 
If not, the individual draft will expire and there will be no assurance 
that the multimob draft will be permanently available. Then the PS can 
simply state what can be concluded from the draft if we don’t explicitly 
reference to the draft. 
 
>> Within that sense, I can also consider to remove the reference. And 
actually, we don’t know the future of this draft as of now.
 
The rest are minor. The second difference is giving examples. We can add 
if we don’t see objection.
 
>> For me, I don’t see any objection on this.
 
The third is to add IP multicast solution. Generally, it is better to 
avoid using the same word “solution” twice in the same sentence. There 
seems to be no major difference in meaning without adding solution here, 
is there?

H Anthony Chan

Hi Seil, 

BR 
Luowen 

收件人
<[email-masked]> 
抄送

Hi Luo, 
  
See the inline, please. 
  
Regards, 
  
Seil 

Hi Seil, 

How about   

BR 
Luowen 

收件人

Hi Luo, 

 
Regards, 
 
Seil 

Hi 

Luowen 

收件人

H Anthony Chan 

Hi Luo, 

Hi Luo,

Hi Sérgio 

Regards, 

Seil 

 

收件人
[email-masked] 
抄送

主题

 

Hi Luis,

some comments in line 

Best regards, 

Luis 

Regards,
Sérgio

H Anthony Chan 

Hi Anthony,

REQ7.2: 

REQ7.3: 

H Anthony Chan 

Hi Pierrick, 

Regards, 

Seil 

Hi all, 

BR, 
Pierrick 

Hi all, 

Best regards, 
Georgios 

 

Regards,

Seil

-----Original Message-----

be

Regards,

Juan Carlos