Subject: Re: [DMM] Multicast requirements

From: Sérgio Figueiredo <[email-masked]>
Date: Tue, 04 Dec 2012 14:59:41 +0000

Hi Anthony,

I agree with your reasoning. As such, in my opinion the requirement can 
be added along those lines.

Best regards,
Sérgio

On 11/29/2012 03:51 PM, h chan wrote:
>
> Sergio,
>
> The intentions of both 7.2 and 7.3 are to enable multicast solutions 
> can be developed by the multimob wg after dmm solutions have been 
> developed by dmm wg.
>
> In addition, I think multimob wg is concerned not only to be able to 
> develop "any" multicast solutions, but the multicast solutions that 
> will not have performance problems as investigated in the problem 
> statements.
>
> Therefore, I guess we can converge all three requirements 7.1, 7.2, 
> and 7.3 into one single requirement by taking into consideration all 
> these three requirements.
>
> H Anthony Chan
>
> *From:*Sérgio Figueiredo [mailto:[email-masked]]
> *Sent:* Thursday, November 29, 2012 5:14 AM
> *To:* h chan
> *Cc:* [email-masked]
> *Subject:* Re: [DMM] Multicast requirements
>
> Hi Anthony,
>
> Sorry for the late answer. Please check my comments:
>
> On 11/28/2012 12:44 AM, h chan wrote:
>
>     So, if we rephrase 7.1 as
>
>     REQ7.1: Flexible multicast distribution
>
>     DMM solutions should enable multicast services which are
>     compatible with (flexible?) multicast distribution scenario. Etc.
>
> SF: It is not clear to me why you are introducing the redundancy in 
> the description. Do you mean it as it is?
>
>
> It will have the same intention as REQ7.2 and REQ7.3.
>
> Is that right?
>
> I would say that REQ7.1 has the major intention of avoiding the 
> referred problems, while REQ7.2 and REQ7.3 serve the purpose of 
> stating multicast should "somehow" be supported in DMM solutions.
>
> With REQ7.1, we want to assure the identified problems are avoided in 
> a future DMM solution.
>
> Best 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
>

---

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

Has the following taken 7.1, 7.2, and 7.3 into consideration?

REQ7: Flexible multicast distribution
DMM should enable multicast solutions in flexible distribution scenario. 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 of this requirement is to consider multicast early so that solutions can be developed to overcome performance issues in multicast distribution scenario. 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.

H Anthony Chan

From: [email-masked] [mailto:[email-masked]] On Behalf Of Sérgio Figueiredo
Sent: Tuesday, December 04, 2012 9:00 AM
To: h chan
Cc: [email-masked]
Subject: Re: [DMM] Multicast requirements

Hi Anthony,

I agree with your reasoning. As such, in my opinion the requirement can be added along those lines.

Best regards,
Sérgio

The intentions of both 7.2 and 7.3 are to enable multicast solutions can be developed by the multimob wg after dmm solutions have been developed by dmm wg.
In addition, I think multimob wg is concerned not only to be able to develop "any" multicast solutions, but the multicast solutions that will not have performance problems as investigated in the problem statements.

Therefore, I guess we can converge all three requirements 7.1, 7.2, and 7.3 into one single requirement by taking into consideration all these three requirements.

H Anthony Chan

From: Sérgio Figueiredo [mailto:[email-masked]]
Sent: Thursday, November 29, 2012 5:14 AM
To: h chan
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [DMM] Multicast requirements

Hi Anthony,

On 11/28/2012 12:44 AM, h chan wrote:
So, if we rephrase 7.1 as
REQ7.1: Flexible multicast distribution
DMM solutions should enable multicast services which are compatible with (flexible?) multicast distribution scenario. Etc.
SF: It is not clear to me why you are introducing the redundancy in the description. Do you mean it as it is?

Is that right?

I would say that REQ7.1 has the major intention of avoiding the referred problems, while REQ7.2 and REQ7.3 serve the purpose of stating multicast should "somehow" be supported in DMM solutions.

With REQ7.1, we want to assure the identified problems are avoided in a future DMM solution.

Best 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.

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:

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]> [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

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.

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

> Cc: [email-masked]<mailto:[email-masked]>; Zuniga, Juan Carlos; Konstantinos Pentikousis;
> Peter McCann; [email-masked]<mailto:[email-masked]>
be
> > "Requirement: DMM solutions SHOULD support multicast services. If a
> The main thing I want to achieve is what was describes as motivation
> earlier in this thread. Multicast should at least be considered when

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

Regards,

Juan Carlos

> 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
> >> 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

Thank you.

dmm mailing list

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

---

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

Instead of "especially," we can change to "for example." Non-optimal routes can take place in other cases too.

H Anthony Chan

From: [email-masked] [mailto:[email-masked]] On Behalf Of LUIS MIGUEL CONTRERAS MURILLO
Sent: Wednesday, November 21, 2012 2:38 AM
To: Sérgio Figueiredo; [email-masked]
Subject: Re: [DMM] Multicast PS to requirements

Thanks Sergio, Seil,

Just a final comment. For PS1, not sure if the word "especially" in the sentence "The problem is especially manifested ..." should be removed.

Regards,

Luis

De: [email-masked] [mailto:[email-masked]] En nombre de Sérgio Figueiredo
Enviado el: miércoles, 21 de noviembre de 2012 0:21
Para: [email-masked]
Asunto: 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.

[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".

[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

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

Thank you.

dmm mailing list

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

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: h chan <[email-masked]>
Date: Tue, 4 Dec 2012 18:41:35 +0000

Is there consensus for PS1 now?

Routing via a centralized anchor often results in a longer route. The problem is manifested, for example, when accessing a local server or servers of a Content Delivery Network (CDN), or when receiving locally available IP multicast or sending IP multicast packets.

H Anthony Chan

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, November 21, 2012 3:37 AM
To: 'LUIS MIGUEL CONTRERAS MURILLO'; Sérgio Figueiredo; [email-masked]
Subject: Re: [DMM] Multicast PS to requirements

Hi,

Referring to CDN does not make any assumptions on the delivery mode. So, if you really want to stress multicast, I suggest the following:

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), including both unicast and multicast delivery mode.

BR,
Pierrick

De : [email-masked] [mailto:[email-masked]] De la part de LUIS MIGUEL CONTRERAS MURILLO
Envoyé : mercredi 21 novembre 2012 09:38
À : Sérgio Figueiredo; [email-masked]
Objet : Re: [DMM] Multicast PS to requirements

Thanks Sergio, Seil,

Regards,

Luis

De: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] En nombre de Sérgio Figueiredo
Enviado el: miércoles, 21 de noviembre de 2012 0:21
Para: [email-masked]<mailto:[email-masked]>
Asunto: Re: [DMM] Multicast PS to requirements

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,

Seil

Hi all,

BR,
Pierrick

Hi all,

Best regards,

Georgios

Regards,

Seil

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

be

Regards,

Juan Carlos

Thank you.

dmm mailing list

dmm mailing list

Thank you.

---

From: Sérgio Figueiredo <[email-masked]>
Date: Tue, 04 Dec 2012 22:34:07 +0000

Hi,

Agreed.

Regards,
Sérgio

On 12/04/2012 06:28 PM, h chan wrote:
>
> Instead of "especially," we can change to "for example." Non-optimal 
> routes can take place in other cases too.
>
> H Anthony Chan
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf 
> Of *LUIS MIGUEL CONTRERAS MURILLO
> *Sent:* Wednesday, November 21, 2012 2:38 AM
> *To:* Sérgio Figueiredo; [email-masked]
> *Subject:* Re: [DMM] Multicast PS to requirements
>
> Thanks Sergio, Seil,
>
> Just a final comment. For PS1, not sure if the word "especially" in 
> the sentence "The problem is especially manifested ..." should be removed.
>
> Regards,
>
> Luis
>
> *De:[email-masked] [mailto:[email-masked]] *En nombre de 
> *Sérgio Figueiredo
> *Enviado el:* miércoles, 21 de noviembre de 2012 0:21
> *Para:* [email-masked]
> *Asunto:* Re: [DMM] Multicast PS to requirements
>
> Hi 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
>
>     */[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".
>
> *//*
> */[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
>
>     *Van:[email-masked] <mailto:[email-masked]>
>     [[email-masked] <mailto:[email-masked]>] namens Seil
>     Jeon [[email-masked] <mailto:[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:
> 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: