Subject: Re: [multimob] IGMP/MLD Proxy at the MAG

From: Matthias Waehlisch <[email-masked]>
Date: Tue, 1 Dec 2009 13:49:48 +0100

Hi Behcet,

On Mon, 30 Nov 2009, Behcet Sarikaya wrote:

>  Is host interface a tunnel interface?
>
> My answer is no. Tell me if your answer is yes?
>
  not mandatory, but it may be a tunnel interface. The difference notation 
-- "Host interface" and "Router interfaces" -- results from the different 
roles of the proxy ...

  If you are afflicted by doubts, please ask your question within the 
MAGMA mailing list. They should definitely know the answer.

> So I think this closes the discussion.
>
  Hopefully.

Regards
  matthias

-- 
Matthias Waehlisch
.  FU Berlin, Inst. fuer Informatik, AG CST
.  Takustr. 9, D-14195 Berlin, Germany
.. mailto:[email-masked] .. http://www.inf.fu-berlin.de/~waehl
:. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net

---

From: Stig Venaas <[email-masked]>
Date: Tue, 01 Dec 2009 05:09:49 -0800

> -- "Host interface" and "Router interfaces" -- results from the different 

The thing is that the proxy draft doesn't talk about link types at all.
Why should it care if POS, Ethernet, GRE tunnel or whatever? It doesn't
change how the proxy operates. Just like say PIM or OSPF RFCs doesn't
specify link types. What link or interface types you have do not matter.

> MAGMA mailing list. They should definitely know the answer.

You could certainly ask there if you like. It might actually be a better
place than this list :)

I think we should start focusing on coming up with a best possible MLD
proxy proposal, there was consensus at our meeting for that to be the
direction to go for the basic multicast solution.

Stig

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 1 Dec 2009 07:54:17 -0800 (PST)

----- Original Message ----
> From: Matthias Waehlisch <[email-masked]>
> To: Behcet Sarikaya <[email-masked]>
> Cc: [email-masked]
> Sent: Tue, December 1, 2009 6:49:48 AM
> Subject: Re: [multimob] IGMP/MLD Proxy at the MAG
> 
> Hi Behcet,
> 

So I think we are in agreement :).
Yes it may be but it is not as defined in RFC 4605.

As I said many times, it is a protocol extension to have this interface as tunneling interface.

 I think that we are all agreeing on this, right?

Regards,

Behcet

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Tue, 01 Dec 2009 17:15:26 +0100

Hi,

seems this debate is not coming to an end ... see below.

>  I think that we are all agreeing on this, right?

Definitely *not*.

Behcet: Matthias & Stig are trying to explain to you patiently and in 
many emails what the meaning of an IP interface of a router is. You are 
looking at the link type, which is layer 2 ... virtual or physical.

Putting it more direct: you are in the wrong movie, largely missing the 
context.

I guess: now we can end the discussion finally.

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: Behcet Sarikaya <[email-masked]>
Date: Tue, 1 Dec 2009 08:34:12 -0800 (PST)

Hi Thomas,
  I think you should be patient and agree with the right thing.

I have never said we can not do this extension. In my reply to you I said we can do this extension 

but not at the base protocol design stage.

I suggest we discuss all the issues calmly.

Regards,

Behcet

----- Original Message ----
> From: Thomas C. Schmidt <[email-masked]>
> To: Behcet Sarikaya <[email-masked]>
> Cc: Matthias Waehlisch <[email-masked]>; [email-masked]
> Sent: Tue, December 1, 2009 10:15:26 AM
> >> From: Matthias Waehlisch 
> >> To: Behcet Sarikaya 
> >>  not mandatory, but it may be a tunnel interface. The difference notation -- 
> "Host interface" and "Router interfaces" -- results from the different roles of 
> the proxy ...
> >> 
> >>  If you are afflicted by doubts, please ask your question within the MAGMA 
> mailing list. They should definitely know the answer.
> > 
> Behcet: Matthias & Stig are trying to explain to you patiently and in many 
> emails what the meaning of an IP interface of a router is. You are looking at 
> the link type, which is layer 2 ... virtual or physical.
> 
> Putting it more direct: you are in the wrong movie, largely missing the context.
>

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Tue, 01 Dec 2009 17:48:36 +0100

Hi Behcet,

>   I think you should be patient and agree with the right thing.
Sorry for being impatient. However, just because you keep repeating an 
obvious mistake, this fault does not become a tiny bit more correct.

> I suggest we discuss all the issues calmly.

The issue is: there is nothing to discuss. As I said more than a week 
ago: "Nothing new, just IP routing". This whole debate is just about a 
misunderstanding of IP/interfaces at your side.

If you don't believe Matthias, Stig and me, please go ahead and ask the 
folks at Magma.

But please let us release the list from the discussion on "what changes 
does a tunnel interface impose on MLD signaling".

... this is just about to make any serious work on this list go bust.

Thanks for your understanding,

Thomas

--

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 1 Dec 2009 10:04:50 -0800 (PST)

Hi all,

With my chair hat on.

----- Original Message ----
> direction to go for the basic multicast solution.

Yes it is true that in the meeting MLD Proxy was the direction to go. 

Here are some facts:

- we have four solution drafts that takes this direction. 

- after the meeting a WG member (happens to be myself) presented some new facts on MLD Proxy that were not discussed at the meeting 

such as MLD Proxy solves avalanche problem which is mentioned in the charter to be done at the next stage; 

such as MLD Proxy incorporated inside MAG-LMA tunnel is an extension to RFC 4605;

I am OK if WG says that we should ignore these facts and continue on the next steps with MLD Proxy as the fixed direction for the base solution.

Any thoughts?

Behcet

---

From: Matthias Waehlisch <[email-masked]>
Date: Tue, 1 Dec 2009 23:57:40 +0100

Hi Behcet,

  see comments inline:

On Tue, 1 Dec 2009, Behcet Sarikaya wrote:

> - after the meeting a WG member (happens to be myself) presented some 
> new facts on MLD Proxy that were not discussed at the meeting 
> 
> I am OK if WG says that we should ignore these facts and continue on the 
> next steps with MLD Proxy as the fixed direction for the base solution.
> 
  again, that's not (completely) a fact ... Additionally, you are the only 
person on this list who argue that "MAG-LMA tunnel is an extension to 
RFC4605". From my impression it seems to be an appropriate procedure that 
you, Behcet, ask the right people in this 'controversial' case, i.e., the 
MAGMA people - don't be shy. Everything else is ridiculous.

> Any thoughts?
  Yes, see above. And to be honest, Behcet, if you have your "chair hat 
on", you should act in a more reasonable way.

Thanks
  matthias

PS: It would be a nice Christmas present to finish this discussion in 
2009 - that's semi-fun.

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 1 Dec 2009 15:10:58 -0800 (PST)

Hi Matthias, 

  So you are for ignoring these facts and continuing on the next steps with MLD Proxy as the fixed direction for the base solution?

Thx.

Behcet

---

From: Matthias Waehlisch <[email-masked]>
Date: Wed, 2 Dec 2009 00:18:09 +0100

Hi Behcet,

On Tue, 1 Dec 2009, Behcet Sarikaya wrote:

>  So you are for ignoring these facts and continuing on the next steps 
> with MLD Proxy as the fixed direction for the base solution?
>
  (1) I don't see that your facts are correct. It seems that we have 
different meanings on this. Thus, I proposed a way to find a consensus - 
ask the MAGMA people, Behcet.

  (2) Personally (having my Nick Knatterton hat on), I have no objections 
to go ahead with the proxy solution.

Regards
  matthias

---

From: Stig Venaas <[email-masked]>
Date: Tue, 01 Dec 2009 23:20:03 -0800

> With my chair hat on.

OK, and this is with my chair hat on then.
> such as MLD Proxy solves avalanche problem which is mentioned in the charter to be done at the next stage; 

MLD Proxy does have some benefits, in particular that there is no
replication until the topology branches out. This is the way multicast
generally behaves, and it provides the same behavior. That this may
avoid avalanche problem and that that is listed as a possible thing to
work on later does not mean that it cannot be solved now if we find a
simple solution that takes care of it. It's not that we are forced to
find a poorer solution.

> such as MLD Proxy incorporated inside MAG-LMA tunnel is an extension to RFC 4605;

You are the only person claiming that so far, and from the discussion we
have had on the list, I don't buy your argument for why it is an
extension.

> I am OK if WG says that we should ignore these facts and continue on the next steps with MLD Proxy as the fixed direction for the base solution.

I don't agree with how you put the "facts" above, I would not call them
facts. I would like to hear if people on the list disagree, but it was
consensus (which is pretty much "WG says") at the meeting. I don't see
anyone ignoring your issues, only disagreeing that they are issues.

It would be important if there were technical issues with the MLD Proxy
approach, I've not seen any so far. I would like to hear about any
issues.

You have brought up possible issues with MLD Proxy and the charter. I
don't see that it is against the charter. It would of course be an issue
if it were, but so far I haven't seen any indication.

Although I believe that it is in the charter, I also want to say that
generally speaking, it can be possible to deviate from the charter
slightly too if there is WG Consensus and there are good technical
reasons. As Jari said in the meeting, the charter is not set in stone.
It's mostly there to guide us. (I hope I got that right, that is what
I remember). It is possible for a WG and an AD to decide to deviate to
some degree. So far, I don't see that we are deviating from the charter
though. And we should try not to, unless we have good reasons.

Stig

---

From: Jari Arkko <[email-masked]>
Date: Wed, 02 Dec 2009 14:22:48 +0200

I wanted to reply and explain the rationale behind what the charter says 
(as opposed to the specific words in the current charter that may turn 
out to be misleading). The group was prohibited to work on certain 
topics for a couple of reasons, mainly to prevent you from jumping ahead 
to complex solutions before the simple thing was tried, forcing you to 
use existing tools before designing new ones, and to limit your first 
task to an achievable size.

 From my perspective the key requirements are that you do not design any 
new protocol messaging and that you do not spend any time in the 
optimization aspect. However, I'm more than happy to see the use of an 
existing RFC (such as 4605), explanation of its application for this 
node and link type, and I do not mind if you get other benefits such as 
optimization in the same deal. However, I am going to insist that 
including this optimization really comes for free through the use of the 
existing RFC. If your specification ends up having significant behaviour 
rules about it, you are over the line and should probably leave it for 
later.

By the way, one of the possible outcomes of the first phase of this 
working group's effort is that if the existing protocol & existing RFC 
support is good enough, we might not need any additional optimization 
work. I'm getting the sense that the proxy solution is quite optimal 
already.

I also had a few questions about MLD proxies in the MAG. I do not fully 
understand how you plan to aggregate the state and forwarding across the 
different MLD instances (draft-schmidt says that there's one instance 
per MN). Wouldn't you run one instance, really, subscribe through just 
one tunnel, and forward multicast packets from one MN's tunnel to the 
others?

Jari

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Wed, 02 Dec 2009 13:41:58 +0100

Hi Jari,

> one tunnel, and forward multicast packets from one MN's tunnel to the 

There seems to be a slight misunderstanding here: the draft states
    "It therefore needs to
    implement an instance of the MLD proxy function [RFC4605] for each
    upstream tunnel interface that has been established with an LMA."

that is an instance per LMA-MAG tunnel, not per MN. Thus multicast 
listener states of all MNs at one MAG that share a specific LMA (and 
hence the tunnel) may be aggregated. Aggregation is an inherent feature 
of RFC 4605.

In this sense, there is some traffic aggregation inherited from the MLD 
proxy function, but the proposed solution is not optimal: There may be 
MNs at a MAG that are associated with different LMAs, and thus are 
treated in different MLD proxy instances which prevents an overall state 
aggregation.

So there should be room for future improvements on PMIP multicast ;)

Best regards,

Thomas
--

---

From: Stig Venaas <[email-masked]>
Date: Wed, 02 Dec 2009 05:01:22 -0800

Thomas C. Schmidt wrote:
> Hi Jari,
> 
> Jari Arkko wrote:
>>
>> I also had a few questions about MLD proxies in the MAG. I do not 
>> fully understand how you plan to aggregate the state and forwarding 
>> across the different MLD instances (draft-schmidt says that there's 
>> one instance per MN). Wouldn't you run one instance, really, subscribe 
>> through just one tunnel, and forward multicast packets from one MN's 
>> tunnel to the others?
> 

The reason for having multiple instances, is that RFC 4605 assumes a
single upstream interface. In this way, each instance can operate
according to 4605.

I believe what happens then, is that when a new MN arrives, the MAG
will first determine which LMA the MN belongs to. When that is done,
it can reconfigure the proxy instance which has that LMA-MAG tunnel
as its upstream, adding the interface the MN is on, to the list of
downstream interfaces that proxy instance manages.

Thomas, you said something about supporting multiple MNs on the same
link a while ago, not just the current point-to-point. Wouldn't that be
difficult if different MNs on the link are using different LMAs, and
hence different proxy instances?

Stig

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Wed, 02 Dec 2009 14:35:41 +0100

Hi Stig,

Stig Venaas wrote:
>>> one instance per MN). Wouldn't you run one instance, really, 
>>> subscribe through just one tunnel, and forward multicast packets from 
>>> one MN's tunnel to the others?
>>
>> hence the tunnel) may be aggregated. Aggregation is an inherent 
>> feature of RFC 4605.
> 
Yes, exactly so.

> hence different proxy instances?

Well, I mentioned that we are trying to prepare the details of the 
mechanisms in a way that they should equally work on a shared link model 
in PMIP, which might come out of the mobility work.

But I see two issues here:

  (i)  The reaction of the MAG, sending a general query once the MN 
arrives at the link
  (ii) The problem of multiple MLD proxy instances operating on the same 
shared link (what you mentioned)

Ad (i): Following the discussion in Hiroshima, we have experimentally 
tried out the behavior of a Cisco and a Linux router: Both send a 
general query immediately after a link goes up (and the link-local 
address of the router interface is configured). This will of course not 
happen, if an MN arrives on a shared link. In this case, router behavior 
needed the extension of sending the query in response to a router 
solicitation, which I guess is not standard behavior now.

Ad (ii): There may be several issues resulting from mixing proxy 
instances at a single shared link. The first question, how to provide a 
correct mapping of MN to proxy instance, should be solvable based on the 
(link-local) addresses of the MNs that need to be unique in a shared 
link model, as well. On the downstream, I'm not so sure now. In any case 
it would result in two (or more) proxy instances operating on forwarding 
states at one interface. I guess we have to think & discuss about this 
further - its future stuff anyway, since we have point-to-point links in 
current PMIP and target at this network model.

Thanks for pointing at this!

Thomas
--

---

From: "Luis M. Contreras" <[email-masked]>
Date: Wed, 02 Dec 2009 15:01:02 +0100

"Thomas C. Schmidt" <[email-masked]> dijo:

>
> In this sense, there is some traffic aggregation inherited from the 
> MLD proxy function, but the proposed solution is not optimal: There 
> may be MNs at a MAG that are associated with different LMAs, and thus 
> are treated in different MLD proxy instances which prevents an 
> overall state aggregation.
>

Please, note that today there are other proposals which state a single 
MLD instance per MAG. As far as I know, there is not a closed solution 
yet.

regards,

Luis

---

From: Hitoshi Asaeda <[email-masked]>
Date: Thu, 03 Dec 2009 15:54:31 +0900 (JST)

Jari,

> work. I'm getting the sense that the proxy solution is quite optimal

MLD proxy is NOT the optimal solution.
(Well, the word, "optimization" is vague as I said in the last
meeting, though, anyway...)

MLD proxy is good to use and the possible implementation to
aggregate multicast join/leave requests and data packets. However, the
following points must be addressed with protocol extension.

1. One of the most emergent topics is about handover.
   There is no way to make a seamless handover for MN's multicast join
   state by MLD proxy or other existing protocols.
   The solution may also include the discussion about a context
   transfer mechanism.
2. Basic design of MLD proxy requires configuring a single upstream
   interface, and hence some extension to support that MAG connects
   multiple LMAs would be necessary.
3. No local routing supported only with MLD proxy. If local routing
   should be supported, dual-mode implementation (MLD proxy and PIM on
   MAG or LMA) should be also discussed.
4. How about following netext's discussions (multi-LMA, multi-IF,
   roaming, etc.) for multicast?

Some of the necessary discussions are already described in;
http://tools.ietf.org/html/draft-asaeda-multimob-pmip6-extension-02

Discussing the protocol extension is hence necessary.

Regards,
--
Hitoshi Asaeda

---

From: "Luis M. Contreras" <[email-masked]>
Date: Thu, 03 Dec 2009 19:10:24 +0100

Hi Hitoshi,

some comments below:

>   The solution may also include the discussion about a context

IMO, the concept of seamless handover applies basically to the 
multicast service subscribed by the MN as it moves. If we are able of 
guaranteeing no service disruption we are compliant with the idea of 
seamless handover. I think that some of the current solution proposals 
could satisfy this point at this stage, without protocol modifications.
Other aspect is the multicast subscription status at the MLD proxy 
instance. In that case, for transferring the status between MLD 
instances in different MAGs some extra signalling is needed. This could 
imply some protocol modification.

>   multiple LMAs would be necessary.

I think we can separate here MLD-proxy upstream configuration from 
MAG-LMA binding. The MLD proxy instance ignores any mobility process. 
As far as the MAG has some interface active, the MLD proxy instance 
could configure that interface as upstream interface for the proxy 
function. From the MLD instance point of view it is not relevant if 
there is an LMA function at the other end of the upstream interface. 
The MLD instance needs at the other end a multicast router or another 
MLD proxy device. If the equipment at the other end of the upstream 
interface implements additional functions (such LMA one) is not 
relevant from the MLD proxy function point of view.

>   MAG or LMA) should be also discussed.

It is not clear to me what could be the behaviour of a mixed 
MLD-proxy/PIM-multicast router. For instance, if some multicast group 
is reacheable through the LMA, which is the way of requesting the 
content? An MLD query or a PIM join? Both of them could make use of the 
same tunnel between MAG and LMA ...
I think that considering a pure MLD-proxy or a pure multicast router 
behaviour is more realistic. IMO, both could be considered at this 
stage (in my understanding, since the MN subscribes the content through 
the MAG either acting as MLD proxy or multicast router, both roles are 
compliant with the remote subscription condition)

>   roaming, etc.) for multicast?

I'm afraid that this could drive to protocol extensions not valid at 
this stage

Best regards,

Luis

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 4 Dec 2009 08:50:55 -0800 (PST)

Hitoshi, all,
  As it seems there is common misunderstanding by some members in the working group, I thought I should explain the background.

  There are different multicast architectures that can be used for mobility. The currently accepted architecture is based on providing multicast to MNs from the home network by HA/LMA. This architecture is characterized as remote subscription and bi-directional tunneling (also as in draft-irtf-mobopts-mmcastv6-ps-09).

  Mobile IP also recognized locally available multicast using proxy or MR at the local network. It does allow such use but no session continuity is provided.

  Is the home networking architecture "inferior"? I don't think so. It fixes multicast tree in view of MN mobility which is a big plus. Packet duplication is not a big problem if there are only a few MNs in the multicast group. Also in Mobile IPv6, HA directly tunnels to MN. The current approach still allows the use of locally available multicast, so overall it is not bad.

  Is home networking architecture optimal? Certainly it is not. This issue was covered in the literature and draft-irtf-mobopts-mmcastv6 nicely surveys it.

  When Multimob charter was written, the home networking architecture was taken as the basis. When we mentioned optimizations, we considered optimizations vis-a-vis home networking architecture. Based on this, solving avalanche problem as in locally available multicast solutions, is an optimization.

  I have two observations based on the above: one is maybe we should have arranged a presentation/tutorial on the state-of-the-art in Hiroshima to set the stage correctly (this was needed because we do have many new comers to mobility in the WG).

  The second point is that our BoF charter had both base and optimization solutions. IESG gave us only the base solutions to start with. This seems to have broken the proper link between the two somehow. Am I right?

Regards,

Behcet

----- Original Message ----
> From: Hitoshi Asaeda <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> Sent: Thu, December 3, 2009 12:54:31 AM

---

From: Hitoshi Asaeda <[email-masked]>
Date: Sat, 05 Dec 2009 15:14:20 +0900 (JST)

Luis,

> could satisfy this point at this stage, without protocol

MLD modification on a host-side implementation is not needed.
I've been saying, since a MN does not give its join state to its
upstream router (incl. proxy) unless no query reception, the MN cannot
continue to reveive streams from nMAG until nMAG completes joins
for all the subscribed channels.
We are trying to tune some MLD timer value to *reduce* this join
latency (a few seconds or more?) without protocol modification at this
stage, but it does not *eliminate* or effectively reduce the latency.

> instances in different MAGs some extra signalling is needed. This
> could imply some protocol modification.

Right. It is the approach to address above issue I'm saying.

> MAG-LMA binding. The MLD proxy instance ignores any mobility
> process. As far as the MAG has some interface active, the MLD proxy
> instance could configure that interface as upstream interface for the
> proxy function. From the MLD instance point of view it is not relevant
> if there is an LMA function at the other end of the upstream
> interface. The MLD instance needs at the other end a multicast router
> or another MLD proxy device. If the equipment at the other end of the
> upstream interface implements additional functions (such LMA one) is
> not relevant from the MLD proxy function point of view.

This is the way to escape from protocol modification, by configuring
"multicast enable (MLD proxy enable) MAG" and "unicast only MAG".
However, it does not enable to establish the shortest multicast path
for every channel and will use triangle routes. And also it may
require special operational or resource costs, I guess.
Is it an optimal way this group's charter aims anyway?

> content? An MLD query or a PIM join? Both of them could make use of
> the same tunnel between MAG and LMA ...

Right.
I've not confirmed the requirement from operator side to support
dual-mode implementation, but the point we know is that enabling
routing protocols on MAG does not require configuring its upstream
interface and supports local routing. It also eliminates the
limitation to make a MN become a multicast data source, while it is
not in the current charter but good for the further "optimization".

> stage (in my understanding, since the MN subscribes the content
> through the MAG either acting as MLD proxy or multicast router, both
> roles are compliant with the remote subscription condition)

In fact, there is no big difference for the solution either with MLD
proxy or PIM router on MAG. 
MLD proxy is simpler while PIM is more flexible due to no requirement
of upstream interface configuration and local routing support. If PIM
router model with no protocol modification should be described in a
separate draft at this stage, I'm happy to cooperate for it.

BTW, the complete solution with PMIP protocol modification will be
shared with the scenario for both MLD proxy and PIM-enabled MAG
because it mainly depends on a new join state transition mechanism, I
expect.

> I'm afraid that this could drive to protocol extensions not valid at

At this stage, yes, I agree.

Regards,
--
Hitoshi Asaeda

---

From: Stig Venaas <[email-masked]>
Date: Fri, 04 Dec 2009 23:51:29 -0800

>> not relevant from the MLD proxy function point of view.

Right. With respect to the MLD-proxy at the MAG, it can really be policy
and/or configuration which upstream interface is used for the various
MNs. Which means, which MLD-proxy instance handles the particular MAG-MN
interface. Depending on policy/config it can be the usual LMA for the
MN, but can possibly be any interface, like an interface to a local
router (if you want to subscribe in the local network instead of home
subscription), or it could be through say a tunnel interface to another
remote router handling multicast, this could also maybe be a "multicast
LMA", although I'm not sure yet whether that is a good term.

What I'm trying to say is that having an MLD-proxy at the MAG allows for
other approaches than just using the LMA-MAG, and it can maybe be done
on a per MN basis.

> Is it an optimal way this group's charter aims anyway?

I feel we need a solution that does not require multicast support in
the local network and which does subscription through the MAG-LMA
tunnel. Which also the charter says. But as I wrote above, the proxy
approach could allow local subscription too. Describing that should
maybe be left for later, but I believe it is a simple extension. I think
it's good if we describe a base model, but which is easily extensible.

> separate draft at this stage, I'm happy to cooperate for it.

I'm not so sure about mixing MLD proxy and PIM router either. You
could certainly do PIM instead of MLD proxy, it's almost identical,
but as you say, a bit more flexible. My only worry about doing PIM
on the MAG is that it's more heavy duty. It also requires LMAs to
support PIM I think, at least if you think of doing the equivalent
of base MLD-proxy approach with PIM instead. While with MLD-proxy
you have a choice whether the LMA should be another MLD-proxy or a
PIM router. In a way this can be a deployment choice, but you have
a problem if your MAG only supports PIM and LMA only MLD.

I think this point is certainly worth discussing. Maybe we can keep
discussing it now and see what people think. I'm leaning towards
MLD-proxy as a more simple basic solution (with PIM a possible later
improvement), but depending on the resources available at MAGs, PIM
could certainly be an option. One consideration here is the complexity
of a single PIM instance with multiple upstream interfaces, compared to
multiple MLD-proxy instances serving those same upstream interfaces. PIM
is significantly more complex (and it comes in addition to doing MLD on
the downstream interfaces), but with many upstream interfaces, PIM might
be easier.

I also want to say though that if we later describe new solutions
involving protocol changes, I think one could also imagine a proxy
implementation that handles multiple upstream interfaces. Or it is
in a way an implementation detail how you implement multiple proxy
instances in the most efficient way.

Stig

---

From: "Luis M. Contreras" <[email-masked]>
Date: Sat, 05 Dec 2009 12:45:22 +0100

> stage, but it does not *eliminate* or effectively reduce the latency.

I think the method we propose in draft-contreras-multimob-msd-00 to 
support the MN handover by temporally redirecting the current multicast 
flow (subscribed by the MN) from pMAG to nMAG till (normal or tuned) 
subscription renewal can effectively reduce the latency in the 
reception of the multicast content once the MN is attached to nMAG, at 
the cost of more bandwidth temporally in the core network, as well as 
some other inefficiencies (temporal routing ineficiency, MTU reduction, 
etc). I think it is something we have to trade off.

Regards,

Luis

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Sat, 05 Dec 2009 14:33:35 +0100

Hi Luis,

Luis M. Contreras wrote:
> subscription renewal can effectively reduce the latency in the reception 
> of the multicast content once the MN is attached to nMAG, at the cost of 
> more bandwidth temporally in the core network, as well as some other 
> inefficiencies (temporal routing ineficiency, MTU reduction, etc). I 
> think it is something we have to trade off.
> 

You do point at the proposal redirecting via the LMA?
Mhmm, then are you sure about this? We discussed the temporal handover 
behavior prior to IETF 76 online, and if I remember correctly, timing 
was exactly the same as for the "full" handover ??

Cheers,

Thomas

--

---

From: Hitoshi Asaeda <[email-masked]>
Date: Mon, 07 Dec 2009 16:39:20 +0900 (JST)

Stig,

I agree that discussing many technical issues in this ML is beneficial
to decide the current and future direction of this group.
On the other hand, I thought the primary point raised by Jari was
regarding the necessity of protocol modification for "optimized"
mobile multicast.
Although I don't restart the discussion about the "optimization", what
we should know now is what functions should be taken into account for
mobile multicast and which functions may not properly work without
protocol modification or how such functions can be revived by
effective protocol modification.

I think a seamless handover (bullet 1) requires protocol modification.
It is impossible to provide a seamless handover without protocol
modification. This is the main concern.
I also raised other scenarios (bullet 2 to 4). In the current charter,
although some of them could be implemented by some methods without
protocol modification. However, for them, as well as bullet 1,
protocol performance may be improved or operational cost may be
reduced if protocol modification is allowed. This is still my guess,
though.

Again, I don't deny the current MLD proxy approach.
My point is that it is beneficial for this group to move forward by
rechartering after the current basic proposal (i.e. implementation
with no protocol modification) is clarified and completed.

Ok, then I reply Stig's comments below.

> other approaches than just using the LMA-MAG, and it can maybe be done

How do you do it? By configuration? Per MN? Per channel?
It is called "static route", isn't it? :)

> it's good if we describe a base model, but which is easily extensible.

I cannot imagine such mechanism by a simple extension, but I agree
it'd be good if possible.

> a problem if your MAG only supports PIM and LMA only MLD.

Right. Hence I said the requirement of "dual-mode implementation".

> the downstream interfaces), but with many upstream interfaces, PIM might

Yes, that is the point.

> instances in the most efficient way.

Well, according to its concept, proxy modification is more difficult,
because it behaves as a host (from a view of its upstream router) and
does not select an incoming interface. If it selects an incoming
interface intelligently and dynamically, it's called a router. :)
For PMIP modification, adding the state transition mechanism with
defining new messages and CT mechanism would address most issues and
work with any multicast instance (e.g. proxy or router).

Regards,
--
Hitoshi Asaeda

---

From: Hitoshi Asaeda <[email-masked]>
Date: Mon, 07 Dec 2009 16:50:58 +0900 (JST)

> support the MN handover by temporally redirecting the current
> multicast flow (subscribed by the MN) from pMAG to nMAG till
> (normal or tuned) subscription renewal can effectively reduce the
> latency in the reception of the multicast content once the MN is
> attached to nMAG, at the cost of more bandwidth temporally in the
> core network, as well as some other inefficiencies (temporal
> routing ineficiency, MTU reduction, etc). I think it is something
> we have to trade off.

I took a glance at section 7 in your draft.
I'm sorry, but I cannot imagine that your idea mentioned in this
section does not require any protocol modification. Or it seems to me
that some original implementation is required. No?
Is it obvious that every function you propose is implemented by an
ordinal PMIP implementation (i.e. only with standard spec)?

For instance, regarding pMAG-assisted handover, you say; "the pMAG can
be able to temporally forward via the LMA a copy of the multicast
content within an unicast flow towards the new location of the MN,
brahbrah", but is this a common behavior of rfc5213 compliant MAG?

Regards,
--
Hitoshi Asaeda

---

From: Stig Venaas <[email-masked]>
Date: Mon, 07 Dec 2009 00:13:45 -0800

> modification. This is the main concern.

I agree with you. And we have already seen several drafts that discuss
various optimizations. Although we should not work on optimizations now,
it might be worthwhile documenting the shortcomings of whatever basic
solution we come up with.

> with no protocol modification) is clarified and completed.

We are in agreement then :)
> It is called "static route", isn't it? :)

OK, I didn't want to go into details, but for instance today you may
have that your MNs are using different LMAs. In the same way I can
imagine for instance that an operator could configure that MNs that
use one LMA for unicast should get multicast locally, while MNs that
use another LMA should get multicast from that LMA. There could be
other ways of determining which proxy instance/upstream interface to
use for a given MN. My point is just that I think there is a lot of
flexibility in this approach.

> interface intelligently and dynamically, it's called a router. :)

I see your point, but I had a more static binding in mind. That
according to some policy the upstream interface could be determined in
a more static way. I'm not talking about say RPF here. Anyway, I think
this is something we can discuss later if you like.

> work with any multicast instance (e.g. proxy or router).

I think you're right, but need to think more about it.

Stig

---

From: <[email-masked]>
Date: Mon, 7 Dec 2009 10:35:03 +0100

Dear all,
Thanks to all for this discussion!
Especially concerning the proposed optimizations I would appreciate if we could document such open issues in an I-D like the very draft one I had prepared for Hiroshima (http://tools.ietf.org/id/draft-von-hugo-multimob-future-work-00.txt) - e.g. with your contributions for an updated version - or with a completely new one, if this is more appropriate.
What do you think?

Best regards
Dirk 

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Stig Venaas
Gesendet: Montag, 7. Dezember 2009 09:14
An: Hitoshi Asaeda
Cc: [email-masked]
Betreff: Re: [multimob] IGMP/MLD Proxy at the MAG

Stig

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 7 Dec 2009 07:37:04 -0800 (PST)

----- Original Message ----
> From: "[email-masked]" <[email-masked]>
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Sent: Mon, December 7, 2009 3:35:03 AM
> Subject: AW: [multimob] IGMP/MLD Proxy at the MAG
> 
> Dear all,
> Especially concerning the proposed optimizations I would appreciate if we could 
> document such open issues in an I-D like the very draft one I had prepared for 
> Hiroshima (http://tools.ietf.org/id/draft-von-hugo-multimob-future-work-00.txt) 
> - e.g. with your contributions for an updated version - or with a completely new 
> one, if this is more appropriate.
> What do you think?

This is a good initiative. It would help us at this stage to start working on a problem statement draft on IGMP/MLD Proxy issues which could later on be used in rechartering.

--behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 8 Dec 2009 08:52:49 -0800 (PST)

----- Original Message ----
> From: Luis M. Contreras <[email-masked]>
> To: Hitoshi Asaeda <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Sent: Thu, December 3, 2009 12:10:24 PM
> Hitoshi Asaeda dijo:
snipped

> I think we can separate here MLD-proxy upstream configuration from MAG-LMA 
> binding. The MLD proxy instance ignores any mobility process. As far as the MAG 
> has some interface active, the MLD proxy instance could configure that interface 
> as upstream interface for the proxy function. From the MLD instance point of 
> view it is not relevant if there is an LMA function at the other end of the 
> upstream interface. The MLD instance needs at the other end a multicast router 
> or another MLD proxy device. If the equipment at the other end of the upstream 
> interface implements additional functions (such LMA one) is not relevant from 
> the MLD proxy function point of view.

Aren't we talking about extending RFC 4605 here? These are good ideas that we should probably pursue but for extending what RFC 4605 defined?

> MLD-proxy/PIM-multicast router. For instance, if some multicast group is 
> reacheable through the LMA, which is the way of requesting the content? An MLD 
> query or a PIM join? Both of them could make use of the same tunnel between MAG 
> and LMA ...
> I think that considering a pure MLD-proxy or a pure multicast router behaviour 
> is more realistic. IMO, both could be considered at this stage (in my 
> understanding, since the MN subscribes the content through the MAG either acting 
> as MLD proxy or multicast router, both roles are compliant with the remote 
> subscription condition)
> 

Local routing is not yet defined in Netext. Even if it was defined, I don't see how it would affect our work as we are restricted with receiver mobility in the charter?

--behcet

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 08 Dec 2009 10:06:18 -0800

My thoughts on this.

I'm bit concerned the way this is heading. First, this is a new working
group and folks have joined with lot of interest and willingness to solve
some issues. But, here we are at a deadlock at step-1.  This is not a good
sign. I want to see this work to move forward as its helping solve some of
the Proxy Mobile IPv6 issues and so I've some vested interest in the success
of this group. My suggestions taking a neutral stand.

1.) I see that the WG chairs have some strong opinions on technical
approaches and strong disagreement between the chairs, that's not helping in
the issue resolution. Chairs should be moderators and help in setting the
discussion go in the right direction. Surely, the chairs are entitled for
their opinions, but if they have to remove the Chair hat every other minute,
or passionately argue about technical matters, why not take the chair hat
and let some one else run the business ?

2.) I don't see any consensus calls on this issue. Let the WG decide the
approach and have the consensus validated by the AD.  If the chosen approach
is not inline with the charter, let the AD state that and resend it back the
group. But, deadlock at this stage needs to be resolved.

3.) There is a high risk of this WG getting killed, either lack of progress,
or lack of interest. Either way, mainly due to the way the business is
conducted. I hope we can avoid that.

My humble 2c. No offense to any one person or to the chairs. I hope, we can
go for consensus call to resolve this issue.

Regards
Sri 

On 12/8/09 8:52 AM, "Behcet Sarikaya" <[email-masked]> wrote:

---

From: "Luis M. Contreras" <[email-masked]>
Date: Wed, 09 Dec 2009 23:27:24 +0100

Hi Thomas,

"Thomas C. Schmidt" <[email-masked]> dijo:

> Mhmm, then are you sure about this? We discussed the temporal 
> handover behavior prior to IETF 76 online, and if I remember 
> correctly, timing was exactly the same as for the "full" handover ??
>

Yes, I refer to the redirection of the multicast flow via the LMA 
(called pMAG-assisted HO in our draft).

We discussed in the past about this. Nevertheless I miss some delay 
contributions to be taken into account in the "full" handover or 
subscription re-signalling case. For instance, a complete PBA/PBU 
sequence is needed before the MAG could send any MLD message, because 
the MAG gets the link-local address on the point-to-point link with the 
MN just after the PBU (as per bullet 15, section 6.9.1.3 of RFC 5213). 
Additionally, MAG should wait at least for the complete MLD Query / MLD 
Report sequence before to start the delivery of the content to the MN. 
I think the subscription re-signalling involves more signalling 
messages than the redirection case.

In any case, I know it would be needed a deeper analysis and system 
characterization to confirm if the redirection method is actually 
faster (and to which extend) that the subscription re-signalling under 
all circunstances.

Regards,

Luis

---

From: "Luis M. Contreras" <[email-masked]>
Date: Wed, 09 Dec 2009 23:35:04 +0100

Hi Hitoshi,

> brahbrah", but is this a common behavior of rfc5213 compliant MAG?

I see this as an additional functionality added to MAG elements to 
support multicast service, as could be the case for the proposal of 
using context transfer methods to transfer multicast status to nMAG, or 
the case of implementing more than one MLD instance in a MAG. All of 
them are new functionalities proposed in the framework of multicast 
support in PMIP without extending basic protocol defined in RFC5213.

Regards,

Luis

---

From: "Luis M. Contreras" <[email-masked]>
Date: Wed, 09 Dec 2009 23:46:02 +0100

Hi Behcet,

Behcet Sarikaya <[email-masked]> dijo:

> Aren't we talking about extending RFC 4605 here? These are good ideas 
> that we should probably pursue but for extending what RFC 4605 
> defined?
>

I don't think so. Separating MLD-proxy upstream configuration from 
MAG-LMA binding ensures that RFC 4605 is not altered.

>> behaviour
> Local routing is not yet defined in Netext. Even if it was defined, I 
> don't see how it would affect our work as we are restricted with 
> receiver mobility in the charter?
>
>
The MAG could play the role of multicast router (no proxy function) in 
a receiver mobility scenario also. This is not in the framework of the 
charter nowadays, but it could be possible in the future.

Regards,

Luis

---

From: Hitoshi Asaeda <[email-masked]>
Date: Sat, 12 Dec 2009 15:30:56 +0900 (JST)

Hi Luis,

> support multicast service, as could be the case for the proposal
> of using context transfer methods to transfer multicast status to
> nMAG, or the case of implementing more than one MLD instance in a
> MAG. All of them are new functionalities proposed in the framework
> of multicast support in PMIP without extending basic protocol
> defined in RFC5213.          ^^^^^^^

It seems that we are not in the same assumption regarding "protocol
extension".
IMO, whether a new signal or message type is used or not, if a
proposed function cannot be implemented based on existing RFCs, that
function is categorized "protocol extension".

Folks, what do you think?

Regards,
--
Hitoshi Asaeda

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Sat, 12 Dec 2009 11:44:39 +0100

Hi Hitoshi, hi Luis,

see below:

> Folks, what do you think?

That's IMO exactly so. Using the same messages, but changing the 
protocol semantics or the behavior of the entities is a clear protocol 
extension (example: RTP was updated without changing the bits on the 
wire, but with altered RTCP signaling coordination in multicast scenarios).

Jari in his last mail to the group also stated it very clearly:
"However, I am going to insist that including this optimization really 
comes for free through the use of the existing RFC. If your 
specification ends up having significant behaviour rules about it, you 
are over the line and should probably leave it for later."

So, pMAG forwarding via the LMA is clearly *not* covered by RFC5213 ...

Cheers,

Thomas
--