Re: 答复: Re: Multicast PS to require ments

Hi Luo,

Thanks for your comment. My answer is placed inline:

On 11/22/2012 08:02 AM, [email protected] 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: PS6is 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.

Best regards,
Sérgio

> BR
>
> Luowen
>
>
>
>
>
> *Sérgio Figueiredo <[email protected]>*
> 发件人:  [email protected]
>
> 2012/11/21 07:21
>
> 	
> 收件人
> 	[email protected]
> 抄送
> 	
> 主题
> 	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 protected]_ 
> <mailto:[email protected]>[_mailto:[email protected]_] *En 
> nombre de *h chan*
> Enviado el:* martes, 20 de noviembre de 2012 18:51*
> Para:* Sérgio Figueiredo; [email protected]_ <mailto:[email protected]>*
> 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 protected]_ 
> <mailto:[email protected]>[_mailto:[email protected]_] *On 
> Behalf Of *Sérgio Figueiredo*
> Sent:* Monday, November 19, 2012 5:24 PM*
> To:* [email protected]_ <mailto:[email protected]>*
> 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 protected]_ 
> <mailto:[email protected]>[_mailto:[email protected]_] *On 
> Behalf Of *Seil Jeon*
> Sent:* Monday, November 19, 2012 5:15 AM*
> To:* [email protected]_ <mailto:[email protected]>*
> Cc:* [email protected]_ <mailto:[email protected]>*
> 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 protected]_ 
> <mailto:[email protected]>[_mailto:[email protected]_] *
> Sent:* Monday, November 19, 2012 8:55 AM*
> To:* '[email protected]_ <mailto:[email protected]>'; 
> [email protected]_ <mailto:[email protected]>; 
> [email protected]_ 
> <mailto:[email protected]>*
> Cc:* [email protected]_ <mailto:[email protected]>*
> 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 protected]_ 
> <mailto:[email protected]>[_mailto:[email protected]_] *De la 
> part de* [email protected]_ <mailto:[email protected]>*
> Envoyé :* samedi 17 novembre 2012 13:01*
> À :* [email protected]_ <mailto:[email protected]>; 
> [email protected]_ 
> <mailto:[email protected]>*
> Cc :* [email protected]_ <mailto:[email protected]>*
> 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 protected]_ 
> <mailto:[email protected]>[[email protected]_ 
> <mailto:[email protected]>] namens Seil Jeon [[email protected]_ 
> <mailto:[email protected]>]*
> Verzonden:* vrijdag 16 november 2012 22:25*
> To:* 'Zuniga, Juan Carlos'*
> Cc:* [email protected]_ <mailto:[email protected]>*
> 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 protected]_ 
> <mailto:[email protected]>[_mailto:[email protected]_] On Behalf Of
> Zuniga, Juan Carlos
> Sent: Friday, November 16, 2012 8:14 PM
> To: Stig Venaas; [email protected]_ <mailto:[email protected]>
> Subject: Re: [DMM] Multicast requirements
>
>
> > -----Original Message-----
> > From: Stig Venaas [_mailto:[email protected]_]
> > Sent: Friday, November 16, 2012 3:01 PM
> > To: jouni korhonen
> > Cc: [email protected]_ <mailto:[email protected]>; Zuniga, Juan 
> Carlos; Konstantinos Pentikousis;
> > Peter McCann; [email protected]_ <mailto:[email protected]>
> > 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 protected]_ <mailto:[email protected]>_
> __https://www.ietf.org/mailman/listinfo/dmm_
>
> _______________________________________________
> dmm mailing list_
> [email protected]_ <mailto:[email protected]>_
> __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 protected]_ <mailto:[email protected]>
> _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 protected]_ <mailto:[email protected]>
> _https://www.ietf.org/mailman/listinfo/dmm_
>
> _______________________________________________
> dmm mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dmm
>

_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm