Subject: [DMM] Multicast requirements

From: jouni korhonen <[email-masked]>
Date: Mon, 12 Nov 2012 21:59:01 +0200

Folks,

This mail is to kick off the discussion on multicast requirement(s) for the draft-ietf-dmm-requirements-02 document. I hope we can nail down the essential multicast requirement(s) as soon as possible.

- Jouni

---

From: Peter McCann <[email-masked]>
Date: Mon, 12 Nov 2012 20:39:08 +0000

jouni korhonen wrote:
> Folks,
> 
> This mail is to kick off the discussion on multicast requirement(s)
> for the draft-ietf-dmm-requirements-02 document. I hope we can nail
> down the essential multicast requirement(s) as soon as possible.

To me, multicast in a DMM environment means joining multicast
groups directly from access routers.  It means re-joining the
multicast tree from a new access router after handover.  I would
hope that we can use existing MLD protocols between the MN and
its first hop AR to accomplish this.

-Pete

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 12 Nov 2012 15:00:25 -0600

Hi Pete,

For PMIPv6, Multimob has defined a base multicast support protocol
which is documented in RFC 6224. You may wish to take a look at this
RFC.

Currently Multimob is working on several extensions to the base protocol.

Let's stop speculating how the multicast is supported and concentrate
on dmm multicast requirements.

Regards,

Behcet

On Mon, Nov 12, 2012 at 2:39 PM, Peter McCann <[email-masked]> wrote:
> _______________________________________________
> dmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 12 Nov 2012 15:13:52 -0600

Hi Jouni,

This discussion originated by a presentation in Multimob of a draft on
IP Multicast Use Cases and Analysis over Distributed Mobility
Management,
http://tools.ietf.org/html/draft-sfigueiredo-multimob-use-case-dmm-03.

This draft is on use cases not on requirements. The author, Seil
mentioned that maybe he can extract some requirements from his draft.

As a possible way going forward, I suggest that Seil does this and
proposes some requirements maybe as part of this thread and we go from
there.

I can tell you that in Multimob meeting in Atlanta, we have not
discussed any requirements.

Regards,

Behcet

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Mon, 12 Nov 2012 22:32:16 +0100

Dear Pete,

multicast mobility management is a route adaptation problem. As in the 
unicast case, mobility can only be treated by routing dynamics in 
trivial cases (re-connect of a tunnel, re-association with next hop). 
Otherwise it is unwise to delegate mobility adaptation to routing 
protocols (-> OSPF, BGP ...).

Accordingly, if DMM distributes mobility operations, handover management 
should foresee easy interconnects to previous distribution trees - both 
for receivers and for mobile multicast sources.

I guess, if DMM people are careful, this is not a world-class item and 
can be treated along the lines of unicast solutions - an isolated 
multicast protocol treatment (as has been previously proposed from 
MULTIMOB folks) seems inappropriate. In core PMIP, multicast treatment 
has turned out to work out simply (-> RFC6224).

Thus my argument: talk to the multicast guys before adopting a solution 
... and make the rest an easy game.

Cheers,

Thomas

-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet                   Fon: +49-40-42875-8452 °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409 °

---

From: Peter McCann <[email-masked]>
Date: Mon, 12 Nov 2012 21:53:20 +0000

In the DMM case my assumption is that the anchor points are closer
to the access routers and therefore are very likely to be in the same
administrative domain.  In these cases, joining the multicast group
directly from the access router gives you the same access to the same
multicast streams and so tunneling the multicast packets won't be
necessary.

-Pete

Thomas C. Schmidt wrote:
> Accordingly, if DMM distributes mobility operations, handover
> management should foresee easy interconnects to previous distribution
> trees - both for receivers and for mobile multicast sources.
> 
> Thus my argument: talk to the multicast guys before adopting a
> solution ... and make the rest an easy game.
> 
> Cheers,
> 
> Thomas
> 
>> To me, multicast in a DMM environment means joining multicast groups
>> directly from access routers.  It means re-joining the multicast tree
>> from a new access router after handover.  I would hope that we can use
>> existing MLD protocols between the MN and its first hop AR to
>> accomplish this.
>> 
>> -Pete
>>

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Mon, 12 Nov 2012 23:05:32 +0100

Hi Pete,

things would be simple, if topology were as described.

Let's wait what dmm is birthing out ... and continue discussion then. In 
any case, complex and incompatible "grand new schemes" do not appear to 
make much sense.

Cheers,

Thomas

---

From: "Seil Jeon" <[email-masked]>
Date: Mon, 12 Nov 2012 22:49:03 -0000

Hi Pete,

That might be one of them we can take on DMM. Imagine, depending on
deployment of existing IP multicasting standard entities, we can think of
various use cases as presented in
http://tools.ietf.org/html/draft-sfigueiredo-multimob-use-case-dmm-03.
Direct routing cannot be applied in every scenario.

After I came back from the trip, we (me and Sergio) have been working on
this with priority. After carefully reviewing the requirement from the use
cases, we'll announce it soon.

Regards,
Seil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter
McCann
Sent: Monday, November 12, 2012 9:53 PM
To: Thomas C. Schmidt
Cc: Stig Venaas; Behcet Sarikaya; [email-masked]
Subject: Re: [DMM] Multicast requirements

In the DMM case my assumption is that the anchor points are closer to the
access routers and therefore are very likely to be in the same
administrative domain.  In these cases, joining the multicast group directly
from the access router gives you the same access to the same multicast
streams and so tunneling the multicast packets won't be necessary.

-Pete

Thomas C. Schmidt wrote:
>> from a new access router after handover.  I would hope that we can 
>> use existing MLD protocols between the MN and its first hop AR to 
>> accomplish this.
>> 
>> -Pete
>>

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Mon, 12 Nov 2012 17:51:47 -0500

I believe the purpose of the discussion was to propose some requirement
text for draft-ietf-dmm-requirements, rather than getting in the
solution space. I propose the following:

Requirement: DMM solutions SHOULD support multicast services. In case
the solution
          does not address multicast, a justification MUST be provided
for the
          omission of multicast from the solution.

Motivation: The purpose of this requirement is to encourage people to
          consider the impacts of running multicast services in a DMM
environment
          from the beginning of the development, thereby avoiding the
need to
          make protocol extensions in the future to support this kind of
          functionality.

Regards,

Juan Carlos

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Thomas C. Schmidt
> Sent: Monday, November 12, 2012 5:06 PM
> To: Peter McCann
> groups
> use

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Tue, 13 Nov 2012 00:03:14 +0100

Hi Juan Carlos,

this all sounds very abstract and more from an administrative point of view.

Point is (and relevant arguments always have an understanding of the 
solution space) that some routing scenarios are easy to accomodate 
multicast and others aren't.

My major point was: If DMM picks a solution, people should just think 
wider (including multicast) and then there is no need to come up with 
weirdo type of "solutions" in Multimob that are only justified by 
unicast solutions being ignorant of other use cases.

In other words: Rather be clever than smart.

Cheers,

Thomas

---

From: Sérgio Figueiredo <[email-masked]>
Date: Mon, 12 Nov 2012 23:10:28 +0000

Hi Juan Carlos,

On 11/12/2012 10:51 PM, Zuniga, Juan Carlos wrote:
> solution space.
We're inline here.

> I propose the following:
This requirement paves the way for the ones I'm reviewing with Seil, and 
keeps IP multicast position, i.e. as a "module" that may or not be 
included by operators.

Although the motivation is clear, this seems as a light requirement to 
be achieved, in the sense that it can be easily transposed. Do you have 
in mind what is a valid "justification" for not addressing multicast?

BR,
Sérgio

---

From: h chan <[email-masked]>
Date: Mon, 12 Nov 2012 23:19:53 +0000

That is right. I had discussed with Seil, and I understand that he will come up with his proposed text soon. 

H Anthony Chan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Seil Jeon
Sent: Monday, November 12, 2012 4:49 PM
To: Peter McCann
Cc: 'Stig Venaas'; 'Behcet Sarikaya'; [email-masked]
Subject: Re: [DMM] Multicast requirements

Hi Pete,

Regards,
Seil

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

-Pete

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Mon, 12 Nov 2012 18:20:36 -0500

Hi Sergio,

> Sérgio Figueiredo
> Sent: Monday, November 12, 2012 6:10 PM
> To: [email-masked]
[JCZ] Good. We don't have time much time for religious battles, so better to propose text soon and get the requirements finalized.
> keeps IP multicast position, i.e. as a "module" that may or not be
[JCZ] I agree. However, talking about "modules" seems to me getting into the solution space, which should not be done in the requirements.
> in mind what is a valid "justification" for not addressing multicast?
[JCZ] I don't have one and I believe it is up to the solution proponents to write one in case they do not support multicast. If they do, a justification would not be needed. The reason for using SHOULD is to allow for people that believe this is not needed to still bring their proposals forward, but giving the reasoning why they believe this is not needed.

Regards,

Juan Carlos
> >> Let's wait what dmm is birthing out ... and continue discussion
> then.
> >> In

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 12 Nov 2012 17:34:46 -0600

Hi Juan Carlos,

> solution space. I propose the following:

Absolutely, let's not lose time on this.

>           omission of multicast from the solution.

OK.

Justification could be out of scope.

>           make protocol extensions in the future to support this kind of

Agreed.

Regards,

Behcet

---

From: Sérgio Figueiredo <[email-masked]>
Date: Mon, 12 Nov 2012 23:46:03 +0000

Hi Juan Carlos,

Don't get me wrong. Although I use the word "module" I'm not referring 
to solution details. What I was referring to was to the optional 
deployment of (at least) multicast discovery / routing protocols, which 
this requirement keeps as is if I understood it correctly.

Cheers,
Sérgio

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Mon, 12 Nov 2012 19:10:36 -0500

Hi Sergio,

I wasn't implying that you were proposing a solution. I just meant that using the word module was perhaps not appropriate for drafting the requirement. Having said that, if you believe there is some wording to that we can propose to reflect your thinking in a clear requirement, please suggest it.

Regards,

Juan Carlos

> From: Sérgio Figueiredo [mailto:[email-masked]]
> Sent: Monday, November 12, 2012 6:46 PM
> To: Zuniga, Juan Carlos
> Cc: [email-masked]
> > [JCZ] Good. We don't have time much time for religious battles, so
> better to propose text soon and get the requirements finalized.
> >>> I propose the following:
> >>>
> >>>
> > [JCZ] I agree. However, talking about "modules" seems to me getting
> into the solution space, which should not be done in the requirements.
> > [JCZ] I don't have one and I believe it is up to the solution
> proponents to write one in case they do not support multicast. If they
> do, a justification would not be needed. The reason for using SHOULD is
> to allow for people that believe this is not needed to still bring
> their proposals forward, but giving the reasoning why they believe this
> is not needed.
> >
> > Regards,
> >
> > Juan Carlos
> >> BR,
> >> Sérgio
> >>> Regards,
> >>>
> >>> Juan Carlos
> >>>
> >>>> any case, complex and incompatible "grand new schemes" do not
> appear
> >>> to
> >>>> make much sense.
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Thomas
> >>>>
> >>>>>> multicast mobility management is a route adaptation problem. As
> in
> >>>> the
> >>>>>> I guess, if DMM people are careful, this is not a world-class
> item
> >>>> and
> >>>>>>> directly from access routers.  It means re-joining the
> multicast
> >>>> tree

---

From: Konstantinos Pentikousis <[email-masked]>
Date: Tue, 13 Nov 2012 14:49:15 +0000

Hi Juan Carlos, all,

  |Requirement: DMM solutions SHOULD support multicast services. In case
  |the solution does not address multicast, a justification MUST be provided
  |for the omission of multicast from the solution.

I like this proposal. It appears to me to capture the essence of the request to cover multicast in DMM. I would make it even shorter however:

Requirement: DMM solutions SHOULD support multicast services. If a specific DMM solution does not support multicast services, an explanation MUST be provided.

  |Motivation: The purpose of this requirement is to encourage people to
  |consider the impacts of running multicast services in a DMM environment
  |from the beginning of the development, thereby avoiding the need to
  |make protocol extensions in the future to support this kind of functionality.

I second the motivation part, although I would also rephrase it a bit:

Motivation: From an operational perspective, if a network domain provides multicast services already, the deployment of a DMM solution should not impede the delivery of such services. From a protocol perspective, a DMM solution should aim to address unicast as well as multicast in a coherent manner, thus avoiding the recurrence of "multicast add-ons", as is the case with today's mobility management solutions.

Best Regards,

Kostas

---

From: Konstantinos Pentikousis <[email-masked]>
Date: Tue, 13 Nov 2012 15:07:29 +0000

Hi Sergio, all,

  |Although the motivation is clear, this seems as a light requirement to
  |be achieved, in the sense that it can be easily transposed. Do you
  |have in mind what is a valid "justification" for not addressing multicast?

I think we already discussed this in Atlanta. Multicast support should not become yet-another-reason to delay DMM solutions, let alone the requirements document.

And, to be honest, if I just "think wider", REQ3, 4, and 5 (IPv6, existing mobility protocols, and compatibility) should be sufficient to cover "multicast support". I copy-paste from the respective motivation sections: "DMM solutions SHOULD target IPv6 as the primary deployment environment." [..] "A DMM solution SHOULD first consider reusing and extending IETF-standardized protocols before specifying new protocols." I think these two would in general cover also stuff developed in multimob. And, as if this is not sufficient, then REQ5 should close this discussion: "The DMM solution MUST be able to co-exist with existing network deployments and end hosts." Therefore, if you already have multicast services in your domain, the DMM solution should handle them.

Now, we did agree in Atlanta to have a quick resolution wrt to multicast, and perhaps explicitly add "REQ7: Multicast support", if the multimob folks can deal with this in an expedient manner. If not, imo, REQs 3/4/5 should more than suffice to cover "multicast support in DMM".

Best Regards,

Kostas

---

From: Konstantinos Pentikousis <[email-masked]>
Date: Tue, 13 Nov 2012 15:18:44 +0000

Hi,

  |I can tell you that in Multimob meeting in Atlanta, we have not
  |discussed any requirements.

Indeed. I was at the multicast meeting in Atlanta, well, the better part of it, and I do not recall any excitement about working on the requirements for multicast support in DMM. On the contrary, as I'm sure the minutes will reflect, the discussion went on about "current issues" in mulitmob drafts.

Multicast is very important. Moving forward with the work in DMM is also very important. I hope we do not stall the progress on DMM requirements till Orlando...

Best Regards,

Kostas

---

From: Konstantinos Pentikousis <[email-masked]>
Date: Tue, 13 Nov 2012 15:36:10 +0000

Hi Thomas, all,

  |Thus my argument: talk to the multicast guys before adopting a
  |solution... and make the rest an easy game.

Somehow I got the feeling that it was the "multicast guys" who wanted to partake in DMM, not the other way around. Therefore, the challenge is on those guys to come up with a coherent DMM requirement and motivation text, in line with the rest of the draft, proportional to the significance of the matter and with respect to the other 6 REQs.

There is already a proposal by Juan Carlos or, if you will, the one I edited, on the floor. Please feel free to propose specific changes, keeping in mind that the current average number of words for each of the requirements is 48 (min: REQ4 with 15 words; max: REQ5 with 79 words).

Best Regards,

Kostas

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 13 Nov 2012 10:03:32 -0600

> Now, we did agree in Atlanta to have a quick resolution wrt to multicast, and perhaps explicitly add "REQ7: Multicast support", if the multimob folks can deal with this in an expedient manner. If n…

I agree. Existing requirements do cover what we need.

Regards,

Behcet

---

From: jouni korhonen <[email-masked]>
Date: Tue, 13 Nov 2012 23:19:20 +0200

> Requirement: DMM solutions SHOULD support multicast services. If a specific DMM solution does not support multicast services, an explanation MUST be provided.

Sounds ok to me.

> Motivation: From an operational perspective, if a network domain provides multicast services already, the deployment of a DMM solution should not impede the delivery of such services. From a protoc…

Ack.

- Jouni

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 13 Nov 2012 20:35:54 -0600

Hi Jouni,

>> Requirement: DMM solutions SHOULD support multicast services.

So here it is a should.

>> If a specific DMM solution does not support multicast services, an explanation MUST be provided.

Why is it a must here?

My comment on this requirement is in mobility area, we have never had
these types of requirements.

For example PMIPv6 was developed with no multicast support.

MIPv6 and PMIPv6 were developed with no fast handover support. MIPSHOP
WG worked on handover extensions to these protocols.

As you know, Costas has changed his view "thinking wider".

If we look back to the beginning of this discussion, i.e. Multimob
meeting in Atlanta and Seil's presentation, we, at least myself, were
mislead. In that presentation at
http://www.ietf.org/proceedings/85/slides/slides-85-multimob-6.pptx

We thought that he had a multicast requirement and a reasonable
suggestion was to take it to dmm. However, if you look at his slide 6,
he does have a requirement there but it is REQ1 from the DMM
requirements draft :-).

If existing requirements are covering what we want, as it seems with
REQ 3/4/5, why not go with them?

Regards,

Behcet

---

From: jouni korhonen <[email-masked]>
Date: Wed, 14 Nov 2012 09:18:21 +0200

Behcet,

>>> Requirement: DMM solutions SHOULD support multicast services.

It seems so.

>>> If a specific DMM solution does not support multicast services, an explanation MUST be provided.

So that one provides a proper justification why the solution chose to 
leverage the former SHOULD and left multicast support unattended. That
makes sense to me.

> For example PMIPv6 was developed with no multicast support.

I doubt it was intentional. RFC6224 did a good job clarifying the operation of
a MAG as a MLD proxy later on.

> As you know, Costas has changed his view "thinking wider".

I'll let him speak for himself.

> REQ 3/4/5, why not go with them?

Perhaps we should have learned what happened with PMIPv6. The assumption was
that multicast would work over it just fine, which was at the end not quite
true. Thus a specific requirement reminding us about that should be ok. If
that multicast specific note boils down to a clarification to an existing
requirement, it is ok. I just don't think we are there yet to jump into that
conclusion.

So, coming back to the proposal from JC & Kostas. There was a  concrete text
proposal. If someone thinks the multicast requirement can be part of existing
requirements; propose text.

- Jouni

---

From: Konstantinos Pentikousis <[email-masked]>
Date: Wed, 14 Nov 2012 17:21:04 +0000

Hi Behcet

  |As you know, Costas has changed his view "thinking wider".

I didn't change my view :) Maybe it was not so clearly explained, apologies for that. I think that it does not harm to have a separate "REQ no. 7" addressing multicast along the lines previously mentioned in the mailing list. However, if drafting such a REQ delays our progress in the WG wrt the -reqs draft, the best practices/gap analysis work or, even worse, going after concrete DMM solutions in a speedy manner, it makes more sense to tweak some of the existing requirements text so we can accommodate the requirement for multicast support. After all, the current DMM chapter does not explicitly mention "multicast".

  |If existing requirements are covering what we want, as it seems with
  |REQ 3/4/5, why not go with them?

I agree, but it's reasonable, since the point was brought up, to explicitly cover multicast (one way or another, see above) in the -reqs draft.

Best Regards,

Kostas

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Wed, 14 Nov 2012 13:23:31 -0500

Hi,

> Konstantinos Pentikousis
> Sent: Wednesday, November 14, 2012 12:21 PM
> To: [email-masked]; jouni korhonen
> Cc: Stig Venaas; Behcet Sarikaya; Peter McCann; [email-masked]
> I didn't change my view :) Maybe it was not so clearly explained,
> apologies for that. I think that it does not harm to have a separate
> "REQ no. 7" addressing multicast along the lines previously mentioned
> in the mailing list. However, if drafting such a REQ delays our
> progress in the WG wrt the -reqs draft, the best practices/gap
analysis
> work or, even worse, going after concrete DMM solutions in a speedy
> manner, it makes more sense to tweak some of the existing requirements
> text so we can accommodate the requirement for multicast support.
After
> all, the current DMM chapter does not explicitly mention "multicast".
> 
> 
> I agree, but it's reasonable, since the point was brought up, to
> explicitly cover multicast (one way or another, see above) in the
-reqs
> draft.
[JCZ] I also agree with explicitly covering multicast. Implicitly
covering it has not been good enough, as this is what triggered this
whole discussion. Explicitly covering it does not seem to be harmful
either. 
The amended text by Kostas seems good to me and I think that we can move
forward with it. Hence, I support including that text in the WG
requirements draft.
Regards,
JC

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 14 Nov 2012 17:03:00 -0600

> forward with it. Hence, I support including that text in the WG

Disagree.

Such requirements state nothing new, and are useless.

How are we going to judge on somebody's multicast solution by looking
at this requirement?

If we include this requirement then we should also have a requirement
saying that fast handover should supported.

If we have a requirement saying that fast handover should be supported
then we should also have a requirement saying that even faster
handover should be supported.

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.

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

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Mon, 12 Nov 2012 22:29:49 +0100

Dear Pete,

Cheers,

Thomas

--

---

From: jouni korhonen <[email-masked]>
Date: Thu, 15 Nov 2012 13:17:05 +0200

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

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

---

From: Sérgio Figueiredo <[email-masked]>
Date: Fri, 16 Nov 2012 14:59:17 +0000

Dear all,

As requested we have been working on a proposal for updating current DMM 
Requirements draft, reflecting the work developed in 
"draft-sfigueiredo-multimob-use-case-dmm-03.txt". We were careful to 
follow the expressed concerns, mainly by not impacting the current 
(mostly accepted) draft structure and content.
As such, we propose the following 2 changes:

# Proposal 1 - small update to PS1 #

PS1: Non-optimal routesRouting 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 
using IP multicasting*.

# Proposal 2 - Add a new requirement#

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

Best regards,
Sérgio & Seil

---

From: Stig Venaas <[email-masked]>
Date: Fri, 16 Nov 2012 12:01:16 -0800

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

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Fri, 16 Nov 2012 15:14:21 -0500

> From: Stig Venaas [mailto:[email-masked]]
> Sent: Friday, November 16, 2012 3:01 PM
> To: jouni korhonen
> Cc: [email-masked]; Zuniga, Juan Carlos; Konstantinos Pentikousis;
> Peter McCann; [email-masked]
> > "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.
> 

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

---

From: "Seil Jeon" <[email-masked]>
Date: Fri, 16 Nov 2012 21:25:43 -0000

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]] On Behalf Of
Zuniga, Juan Carlos
Sent: Friday, November 16, 2012 8:14 PM
To: Stig Venaas; [email-masked]
Subject: Re: [DMM] Multicast requirements

> 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

---

From: <[email-masked]>
Date: Sat, 17 Nov 2012 12:01:27 +0000

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,

Regards,

Seil

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

Regards,

Juan Carlos

---

From: <[email-masked]>
Date: Mon, 19 Nov 2012 08:55:26 +0000

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,

Best regards,

Georgios

________________________________
Van: [email-masked]<mailto:[email-masked]> [[email-masked]] namens Seil Jeon [[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,

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

Regards,

Juan Carlos

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

---

From: "Seil Jeon" <[email-masked]>
Date: Mon, 19 Nov 2012 11:14:48 -0000

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. 

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

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 haven’t real all messages from this thread. So, maybe I missed important points.

BR,

Pierrick

Hi all,

 

 

Best regards,

Georgios

  _____  

Van:  <mailto:[email-masked]> [email-masked] [[email-masked]] namens Seil Jeon [[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]

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

---

From: h chan <[email-masked]>
Date: Mon, 19 Nov 2012 22:28:10 +0000

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

Regards,

Seil

Hi all,

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,

Best regards,

Georgios

Regards,

Seil

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

Regards,

Juan Carlos

Thank you.

---

From: Sérgio Figueiredo <[email-masked]>
Date: Mon, 19 Nov 2012 23:23:41 +0000

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:
>
> 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*.
>
> 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.
>
> 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.
>
> 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.
>
> "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.
>
> 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?
>
> *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
>
> "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]] namens Seil Jeon 
> [[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,
>
> From: [email-masked] 
> <mailto:[email-masked]>[mailto:[email-masked]] On Behalf Of
> Zuniga, Juan Carlos
> To: Stig Venaas; [email-masked] <mailto:[email-masked]>
> > Cc: [email-masked] <mailto:[email-masked]>; Zuniga, Juan 
> Carlos; Konstantinos Pentikousis;
> > Peter McCann; [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>

---

From: h chan <[email-masked]>
Date: Tue, 20 Nov 2012 17:50:52 +0000

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

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

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.

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

REQ7.2:

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

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.

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,

BR,
Pierrick

Hi all,

Best regards,

Georgios

Van: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] namens Seil Jeon [[email-masked]<mailto:[email-masked]>]

Regards,

Seil

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

Regards,

Juan Carlos

Thank you.

dmm mailing list

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Tue, 20 Nov 2012 19:46:58 +0000

Hi Anthony,

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

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

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,

REQ7.2:

REQ7.3:

H Anthony Chan

Hi Pierrick,

Regards,

Seil

Hi all,

BR,
Pierrick

Hi all,

Best regards,

Georgios

Regards,

Seil

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

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

---

From: "Seil Jeon" <[email-masked]>
Date: Tue, 20 Nov 2012 22:32:27 -0000

Hi Luis,

See inline, please.

Regards,

Seil

From: [email-masked] [mailto:[email-masked]] On Behalf Of LUIS
MIGUEL CONTRERAS MURILLO
Sent: Tuesday, November 20, 2012 7:47 PM
To: h chan
Cc: [email-masked]
Subject: Re: [DMM] Multicast PS to requirements

Hi Anthony, 

some comments in line 

Best regards,

Luis

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

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

>> I think you seem talking the opposite case. When all IP multicast is used
locally regardless of IP mobility tunnel, it might avoid the PS1.

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.

>> Thanks to clarifying the issue correctly. Let me rephrase this again as
following,

“IP multicast distribution over architectures making mobility tunnel
endpoint towards an MN terminated on access router may lead to …”

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.

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. 

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.

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. 

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. 

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

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

To: [email-masked]'; [email-masked];

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,

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:  <mailto:[email-masked]> [email-masked]
[[email-masked]] namens Seil Jeon [[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

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

____________________________________________________________________________
_____________________________________________
 
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.

 

  _____  

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: Sérgio Figueiredo <[email-masked]>
Date: Tue, 20 Nov 2012 23:21:20 +0000

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]] *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
>
> */[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
>
> *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]>
> 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?
>
> 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 
>     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*.
>
>     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).
>
>     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.
>
>     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
>     *To:* [email-masked] <mailto:[email-masked]>
>     mobility rather than distributed mobile multicast. As a result,
>     you can find this deployment use case and gap analysis at
>     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.
>
>     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.
>
>     *From:[email-masked]
>     <mailto:[email-masked]> [mailto:[email-masked]]
>     *To:* [email-masked] <mailto:[email-masked]>';
>     [email-masked] <mailto:[email-masked]>;
>     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?
>
>     [mailto:[email-masked]] *De la part de*
>     [email-masked] <mailto:[email-masked]>
>     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
>
>     "The DMM (unicast) solution MUST be specified in such a way that
>     it can be extended to also support multicast traffic."
>
>     Best regards,
>
>     Georgios
>
>     <mailto:[email-masked]>[[email-masked]
>     <mailto:[email-masked]>] namens Seil Jeon [[email-masked]
>     <mailto:[email-masked]>]
>     From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked]] On Behalf Of
>     Zuniga, Juan Carlos
>     > >> 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
>
> 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:

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Wed, 21 Nov 2012 08:37:36 +0000

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,

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

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

Regards,

Juan Carlos

Thank you.

dmm mailing list

dmm mailing list

---

From: <[email-masked]>
Date: Wed, 21 Nov 2012 09:37:25 +0000

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,

Regards,

Seil

Hi all,

BR,
Pierrick

Hi all,

Best regards,

Georgios

Regards,

Seil

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

Regards,

Juan Carlos

Thank you.

dmm mailing list

dmm mailing list

---

From: [email-masked]
Date: Thu, 22 Nov 2012 11:18:24 +0800

Hi Anthony,

Thanks for the summary. And I think the motivation should be also 
included. To me, the text from JuanCarlos is resaonable

>         consider the impacts of running multicast services in a DMM
＞          from the beginning of the development, thereby avoiding the
＞　need to
＞         make protocol extensions in the future to support this kind of
＞         functionality.

Thanks
Luowen

h chan <[email-masked]> 
发件人:  [email-masked]
2012/11/20 06:28

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

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

H Anthony Chan 

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. 

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

Hi all,

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

Hi all,

 

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

Regards,

Juan Carlos

 
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]
https://www.ietf.org/mailman/listinfo/dmm

---

From: [email-masked]
Date: Thu, 22 Nov 2012 11:43:16 +0800

Hi  Sérgio & Seil

Thanks for the proposed text. 

[Luowen] Not quite understand what is meaning of " flexible multicast 
distribution scenarios"?  And what is "multiple endpoints"？ I have read 
through the draft 
http://tools.ietf.org/html/draft-sfigueiredo-multimob-use-case-dmm-03 
roughly (sorry, not in detailed), it indeed describes some scenarios of 
multicast with dmm concept. But it gives me an impression that the 
scenarios are based on some kind of assumed unicast solution and 
architecture. Also, the text proposed here give me feeling that it falls 
into solution scope.
BR
Luowen

Sérgio Figueiredo <[email-masked]> 
发件人:  [email-masked]
2012/11/16 22:59

收件人
[email-masked]
抄送

主题

Dear all,

As requested we have been working on a proposal for updating current DMM 
Requirements draft, reflecting the work developed in 
"draft-sfigueiredo-multimob-use-case-dmm-03.txt". We were careful to 
follow the expressed concerns, mainly by not impacting the current (mostly 
accepted) draft structure and content.
As such, we propose the following 2 changes:

# Proposal 1 - small update to PS1 #
PS1: 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 using 
IP multicasting.

Best regards,
Sérgio & Seil

Regards,
Seil

-----Original Message-----
Peter

directly

-Pete

Thomas C. Schmidt wrote:

Dear Pete,

Cheers,

Thomas

jouni korhonen wrote:

Folks,

-Pete

---

From: [email-masked]
Date: Thu, 22 Nov 2012 16:02:45 +0800

Hi Sérgio

tunnel’s downstream entity (e.g. MAG in PMIPv6).  >Concretely, when 
 
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.
BR
Luowen

2012/11/21 07:21

收件人
[email-masked]
抄送

主题
Re: [DMM] Multicast PS to requirements

Hi Luis,

 
some comments in line 
 
Best regards,
 
Luis

 
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,

PSs you referred.  So, while 7.2 and 7.3 express the need for DMM 

 

 
REQ7.2: 

REQ7.3:

 
 
H Anthony Chan

Hi Pierrick,

 

Regards,
 
Seil

Hi all,

 
BR,
Pierrick

Hi all,

 

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,

Regards,

Seil

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

Regards,

Juan Carlos

---

From: Sérgio Figueiredo <[email-masked]>
Date: Thu, 22 Nov 2012 09:35:16 +0000

Hi Luo,

Thanks for your comment. My answer is placed inline:

On 11/22/2012 08:02 AM, [email-masked] wrote:
> subscriptions towards the tunnel’s downstream entity (e.g. MAG in 
> PMIPv6).  >Concretely, when multicast subscription for individual 
> */>[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 
> 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-masked]>*
> *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
>
> [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".
>
> subscriptions towards the tunnel’s downstream entity (e.g. MAG in 
> 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,
>
> subscriptions towards the tunnel’s downstream entity (e.g. MAG in 
> 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” 
> *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 
> _http://tools.ietf.org/html/draft-sfigueiredo-multimob-use-case-dmm-03_presented 
> in multimob several times.
>
> subscriptions towards the tunnel’s downstream entity (e.g. MAG in 
> *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,
>
> *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,
>
> *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,
>
> From: [email-masked] 
> <mailto:[email-masked]>[_mailto:[email-masked]] On Behalf Of
> Zuniga, Juan Carlos
> To: Stig Venaas; [email-masked] <mailto:[email-masked]>
> > From: Stig Venaas [_mailto:[email-masked]]
> > Cc: [email-masked] <mailto:[email-masked]>; Zuniga, Juan 
> > Peter McCann; [email-masked] <mailto:[email-masked]>
> 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_
> a l'expediteur et le detruire ainsi que les pieces jointes. Les 
> messages electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law;
> [email-masked] <mailto:[email-masked]>
> _https://www.ietf.org/mailman/listinfo/dmm_
>
>
> and receive email on the basis of the terms set out at:_
> __http://www.tid.es/ES/PAGINAS/disclaimer.aspx_
>
>
> [email-masked] <mailto:[email-masked]>
> _https://www.ietf.org/mailman/listinfo/dmm_
>

---

From: "Seil Jeon" <[email-masked]>
Date: Thu, 22 Nov 2012 22:27:21 -0000

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,

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

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

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

Regards,

Seil

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

Regards,

Juan Carlos

  

 

  _____  

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

---

From: [email-masked]
Date: Mon, 26 Nov 2012 11:02:53 +0800

Hi Seil & Sérgio:

Thank you for your reply, And with all respect, I don't know where are you 
coming from when you say there are any solutions not assumed? 

When I read your draft, you have assumption A3 : 
It is assumed that when the IP mobility happens, at least one
   multicast flow is being received (listener) / sent (sender). and a
   mobility tunnel will be created between the P-MAR and the N-MAR.

and A4: ... But when a user moves to another MAR (N-MAR), under
   assumption A3, the upstream interface of MLD Proxy will be configured
   towards the anchor that enables unicast IP address continuity to be
   kept (P-MAR, analogous to LMA function).

IMHO, if without a assumed solution, why you assume, e.g. a mobility 
tunnel will be creates between the P-MAR and N-MAR?  Also, when I read 
your figure 1,2 and 3, why the traffic must be delivered in this way? And 
the limitations you have discussed are basically based on such scenarios, 
not?

My point is, the multicast requirements in DMM REQ in this stage should be 
some text like "DMM solutions should enable solutions to support multicast 
traffic. ". Scenarios for multicast discussed in this stage is too early 
since there are no dmm solutions and architecture, many people shares this 
opinions I believe.

BR
Luowen 

"Seil Jeon" <[email-masked]> 
2012/11/23 06:27

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

Hi Luo,

Sergio Figueiredo
 
Hi Luo,

Hi Sérgio 

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

收件人
[email-masked] 
抄送

主题

Hi Luis,

  
some comments in line 
  
Best regards, 
  
Luis 

  

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,

  

  
REQ7.2: 

REQ7.3: 

  
  
H Anthony Chan 

Hi Pierrick, 

  

Regards, 
  
Seil 

Hi all, 

  
BR, 
Pierrick 

Hi all, 

  

Best regards, 
Georgios 

Regards,

Seil

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

Regards,

Juan Carlos

  

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

---

From: "Seil Jeon" <[email-masked]>
Date: Mon, 26 Nov 2012 16:03:51 -0000

Hi Luo,

Thanks to your comments based on our draft.

See inline, please.

Regards,

Seil

From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, November 26, 2012 3:03 AM
To: Seil Jeon
Cc: [email-masked]; 'Sérgio Figueiredo'
Subject: 答复: RE: [DMM] 答复: Re: Multicast PS to requirements

Hi Seil & Sérgio: 

Thank you for your reply, And with all respect, I don't know where are you coming from when you say there are any solutions not assumed? 

>> This show a certain “STATUS” that can be made by various DMM solutions not a solution obviously.

>> It is also same, see the next explanation in details.

IMHO, if without a assumed solution, why you assume, e.g. a mobility tunnel will be creates between the P-MAR and N-MAR?  Also, when I read your figure 1,2 and 3, why the traffic must be delivered in this way? And the limitations you have discussed are basically based on such scenarios, not?

>> “Mobility tunnel” itself is not a solution. We’re playing on the “tunneling pipe” when we talk about IP mobility. And you know? There are two ways possible to configure MLD upstream interface on the IP mobility; following the direction of anchor router or always upper multicast router when we use existing IGMP/MLD standard. As I mentioned above, these situations may happen which DMM solutions you propose, if you follow “REQ1: distributed deployment”. And this assumption is quite reasonable without support of any DMM solutions.

Importantly, in here, we didn’t assume nor consider any protocol, behavior, and even signaling.

My point is, the multicast requirements in DMM REQ in this stage should be some text like "DMM solutions should enable solutions to support multicast traffic. ".

>> It’s not bad but not to be only one. As I said maybe 10 days ago, it remains at a basic stage for the DMM solution to support multicast. I don’t know what can we get from that. We need to touch more multicast-characteristic for DMM multicast as specified not giving any specific limitation and restriction but importantly being made towards the direction not limiting the benefits provided by distributed deployment. I think you’re quite aware of this need.

Scenarios for multicast discussed in this stage is too early since there are no dmm solutions and architecture, many people shares this opinions I believe. 

>> As I said, these use cases are not based on any DMM solutions but on existing DMM requirements. The requirement we proposed is resulted from the presented use cases and full analysis. 

And sorry I don’t agree with your opinion. In DMM meeting, it was agreed to worth to look at DMM multicast requirements, many people wanted to see them. But it was urged to be made quickly. So, we’re discussing and making progressing for better text, right? You can check the meeting minutes.

BR 
Luowen 

2012/11/23 06:27 

收件人

<[email-masked]> 

抄送

主题

		

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

Regards,

Juan Carlos

 

  

  _____

---

From: h chan <[email-masked]>
Date: Wed, 28 Nov 2012 00:15:00 +0000

Thanks, and I am trying to converge the different proposals.
I think “To consider the impact of multicast on DMM” has the same intention as “studying the possible performance problems in the problem statement so that the DMM solutions will enable multicast solutions that will avoid those problems.”

H Anthony Chan

From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, November 21, 2012 9:18 PM
To: h chan
Cc: [email-masked]; [email-masked]; [email-masked]; Seil Jeon
Subject: 答复: Re: [DMM] Multicast requirements

Hi Anthony,

Thanks for the summary. And I think the motivation should be also included. To me, the text from JuanCarlos is resaonable

Thanks
Luowen

2012/11/20 06:28

收件人

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

抄送

主题

REQ7.2:

REQ7.3:

H Anthony Chan

Hi Pierrick,

Regards,

Seil

Hi all,

BR,
Pierrick

Hi all,

Best regards,
Georgios

Regards,

Seil

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

Regards,

Juan Carlos

---

From: h chan <[email-masked]>
Date: Wed, 28 Nov 2012 00:44:39 +0000

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.

It will have the same intention as REQ7.2 and REQ7.3.

Is that right?

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

Regards,

Juan Carlos

Thank you.

dmm mailing list

---

From: Sérgio Figueiredo <[email-masked]>
Date: Thu, 29 Nov 2012 11:14:00 +0000

Hi Anthony,

Sorry for the late answer. Please check my comments:

On 11/28/2012 12:44 AM, h chan wrote:
> 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.
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
> Of *Sérgio Figueiredo
> *To:* [email-masked]

---

From: h chan <[email-masked]>
Date: Thu, 29 Nov 2012 15:51:27 +0000

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,

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

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

Regards,

Juan Carlos

Thank you.

dmm mailing list