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

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 19 Nov 2009 09:13:24 -0800 (PST)

Hello Folks,
  Stig and I have been debating this issue, maybe it is time to talk about this now: There is an opinion that 

IGMP/MLD Proxy at the MAG is not in the current charter

due to

1. Charter requires remote subscription technique and IGMP/MLD Proxy is not exactly remote subscription,

2. Charter says optimizations to deal with avalanche problem will be dealt with after rechartering (the last clause in the charter).
IGMP/MLD Proxy solves avalanche problem.

Regards,

Behcet

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Thu, 19 Nov 2009 18:24:34 +0100

Hi Behcet,

from my perspective, there are two answers to this:

  1. The sense of the charter is to produce (good) solutions without 
protocol modifications. If the wording of the charter is misleading, we 
have to follow its sense ... as Jari said: there are no holy words in 
the charter, Multimob should attempt to do serious, good work fast!

  2. IMHO, there is no issue with charter words:
     - the term "Remote Subscription" as defined in the literature (-> 
see problem statement)
       was coined as counterpart to "home subscription" (HA-Tunneling). 
All the approaches we
       have been discussing in Hiroshima are of type "remote subscription".
     - IGMP/MLD Proxy at the MAG does not solve avalanche/tunnel 
convergence problems in full.
       But even if it did (without protocol modification), that would be 
fine and in no
       contradiction with the charter - as the charter just singles out 
optimizations that do
       change protocols.

In conclusion: you should not debate this artifact. It is a pure waste 
of time and drives the group away from serious work and momentum to 
solutions.

Cheers

Thomas

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

-- 

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: jouni <[email-masked]>
Date: Fri, 20 Nov 2009 01:31:52 +0200

Hi Behcet,

 From the current charter:

 >  Specific goals for the group are:
 >  - Document how multicast can be supported in a Proxy Mobile IPv6
 >    environment

The above does not prevent us working on a MLD Proxy based solution or  
any other solution. And if the solution, be that MLD Proxy or  
something else, works also in a mode where all data comes through LMA,  
the remote subscription requirement is also met.

>
> 2. Charter says optimizations to deal with avalanche problem will be  
> dealt with after rechartering (the last clause in the charter).

I am confused. What this has to do with optimizations? As far as I  
understand it now, MLD Proxy seems to address the following charter  
requirements: "This work will not require any additions or changes to  
message types and parameters specified in RFC 5213, and must assume an  
unmodified mobile host." This can of course change if we get/find new  
facts that state opposite.

Cheers,
	Jouni

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Fri, 20 Nov 2009 00:55:01 +0100

Agree.

Carlos

-- 
Carlos Jesús Bernardos Cano     http://www.netcoms.net
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67

---

From: "Lu, Guang" <[email-masked]>
Date: Fri, 20 Nov 2009 11:13:42 -0500

We also agree with the reasoning by Thomas and Jouni. 

Best regards,
Guang & Juan Carlos

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Carlos Jesús Bernardos Cano
> Sent: Thursday, November 19, 2009 6:55 PM
> To: Thomas C. Schmidt
> Cc: [email-masked]
> Subject: Re: [multimob] IGMP/MLD Proxy at the MAG
> 
> Agree.
> 
> Carlos
> 
> > protocol modifications. If the wording of the charter is misleading,
> > we have to follow its sense ... as Jari said: there are no holy words
> > in the charter, Multimob should attempt to do serious, good work
> fast!
> >
> >      - the term "Remote Subscription" as defined in the literature (-
> >
> > see problem statement)
> >        But even if it did (without protocol modification), that would
> > be fine and in no
> >        contradiction with the charter - as the charter just singles
> > out optimizations that do
> >        change protocols.
> >
> > >   Stig and I have been debating this issue, maybe it is time to
> talk
> > > about this now: There is an opinion that
> > >
> > > 1. Charter requires remote subscription technique and IGMP/MLD
> Proxy
> > > is not exactly remote subscription,
> > >
> > > 2. Charter says optimizations to deal with avalanche problem will
> be dealt with after rechartering (the last clause in the charter).

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 20 Nov 2009 09:09:12 -0800 (PST)

Hi Thomas,

  Remote subscription together with dealing with avalanche problem after rechartering means remote subscription and bi-directional tunneling as described in draft-irtf-mobopts-mmcastv6-ps-09.txt.

  It is true that the charter did not spell out bi-directional tunneling, but it is implied, I don't think the charter needed to do this, right? It was out for review by public, we received no comments for further clarification.

  Thomas, I think it is clear that IGMP/MLD Proxy or MR at the MAG approaches do solve the avalanche problem.

  Tunnel convergence is not well defined, in our chairs' evaluation we defined it as the problem of multiple LMAs sending duplicate multicast data to IGMP/MLD Proxy. I think it is better to stick to this definition and separate the avalanche from tunnel convergence. MR at the MAG does solve both avalanche and tunnel convergence problems.

Regards,

Behcet

----- Original Message ----
> From: Thomas C. Schmidt <[email-masked]>
> To: Behcet Sarikaya <[email-masked]>
> Cc: [email-masked]
> Sent: Thu, November 19, 2009 11:24:34 AM
> 1. The sense of the charter is to produce (good) solutions without protocol 
> modifications. If the wording of the charter is misleading, we have to follow 
> its sense ... as Jari said: there are no holy words in the charter, Multimob 
> should attempt to do serious, good work fast!
> 
>     - the term "Remote Subscription" as defined in the literature (-> see 
> problem statement)
>       was coined as counterpart to "home subscription" (HA-Tunneling). All the 
> approaches we
>     - IGMP/MLD Proxy at the MAG does not solve avalanche/tunnel convergence 
> problems in full.
>       But even if it did (without protocol modification), that would be fine and 
> in no
> In conclusion: you should not debate this artifact. It is a pure waste of time 
> and drives the group away from serious work and momentum to solutions.
> 
> Cheers
> 
> Thomas
> 
> Behcet Sarikaya wrote:
> > Hello Folks,
> > 2. Charter says optimizations to deal with avalanche problem will be dealt 
> with after rechartering (the last clause in the charter).

---

From: Stig Venaas <[email-masked]>
Date: Fri, 20 Nov 2009 12:58:19 -0800

>   Tunnel convergence is not well defined, in our chairs' evaluation we defined it as the problem of multiple LMAs sending duplicate multicast data to IGMP/MLD Proxy. I think it is better to stick t…

I agree with Jouni, Thomas, Guang and the others here. The subscriptions
are sent through the MAG-LMA tunnel, and the data is delivered through
the MAG-LMA tunnel. Are you saying that is not remote subscription?

Charter says:

   must assume an unmodified mobile host. The work will employ the remote
   subscription model. This is a mechanism by which a mobile node joins a
   multicast group and receives multicast data forwarded via the local
   mobility anchor.

If IGMP/MLD proxy solves additional problems, that is a bonus! The basic
solution should not have additional complexity to solve additional
problems, but the proxy solution is one of the basic solutions people
have found to the problem.

At the wg meeting we had consensus (none against) for choosing the proxy
approach as our basic multicast solution. So please let's proceed with
that. We should verify that we have consensus (or at least rough
consensus) on the mailing list too though.

I can send an email to check list consensus,

Stig

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 20 Nov 2009 13:16:17 -0800 (PST)

----- Original Message ----
> From: Stig Venaas <[email-masked]>
> To: Behcet Sarikaya <[email-masked]>
> Cc: Thomas C. Schmidt <[email-masked]>; [email-masked]
> Sent: Fri, November 20, 2009 2:58:19 PM
> >  Remote subscription together with dealing with avalanche problem after 
> rechartering means remote subscription and bi-directional tunneling as described 
> in draft-irtf-mobopts-mmcastv6-ps-09.txt.
> > 
> >  It is true that the charter did not spell out bi-directional tunneling, but 
> it is implied, I don't think the charter needed to do this, right? It was out 
> for review by public, we received no comments for further clarification.
> > 
> >  Tunnel convergence is not well defined, in our chairs' evaluation we defined 
> it as the problem of multiple LMAs sending duplicate multicast data to IGMP/MLD 
> Proxy. I think it is better to stick to this definition and separate the 
> avalanche from tunnel convergence. MR at the MAG does solve both avalanche and 
> tunnel convergence problems.
> 

Let me reply with a question then: Are you saying that bi-directional tunneling is not remote subscription?

> have found to the problem.

The charter also says that optimizations including avalanche problem will be solved with rechartering. 
Are you saying that IGMP/MLD proxy does not solve avalanche problem?

This is the main point. As I mentioned, the two together clearly points to remote subscription + bi-directional tunneling.

So are you saying that we can take the parts of the charter we like and then ignore the parts we don't like?

Regards,

Behcet

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Fri, 20 Nov 2009 22:36:44 +0100

Hi Stig et al.,

being just busy working on Multimob drafts, I tend to suggest 
terminating the discussion on this "How remote must be something to be 
called remote subscription".

People (operators) in the field might be happy to receive guidelines 
from us on how to deploy multicast easily and in an efficient manner. 
They most certainly will not care about whether our charter intended to 
say "far remote", "somewhat remote" or "a little remote" when mentioning 
"remote subscription".

Similarly, I cannot believe that a good, solid solution worked out by 
the WG will be rejected by the IESG because the "degree of remoteness" 
is not right. However,

@Behcet: if you feel uncertain about the exact interpretation of 
"remoteness" in the charter, I would suggest to consult Jari about it. 
I'm sure he'll provide good arguments why it is helpful to relax this 
sacrosanct exegesis.

 From the perspective of identifying technically feasible solutions, I 
cannot sense any spirit of inspiration from these considerations.

So let's all have a good, relaxing weekend and a fresh start to fruitful 
new work on Monday!

Cheers,

Thomas

Stig Venaas wrote:
> Behcet Sarikaya wrote:
>> Hi Thomas,
>>
>>   Remote subscription together with dealing with avalanche problem 
>> after rechartering means remote subscription and bi-directional 
>> tunneling as described in draft-irtf-mobopts-mmcastv6-ps-09.txt.
>>
>>   It is true that the charter did not spell out bi-directional 
>> tunneling, but it is implied, I don't think the charter needed to do 
>> this, right? It was out for review by public, we received no comments 
>> for further clarification.
>>
>>   Thomas, I think it is clear that IGMP/MLD Proxy or MR at the MAG 
>> approaches do solve the avalanche problem.
>>
>>   Tunnel convergence is not well defined, in our chairs' evaluation we 
>> defined it as the problem of multiple LMAs sending duplicate multicast 
>> data to IGMP/MLD Proxy. I think it is better to stick to this 
>> definition and separate the avalanche from tunnel convergence. MR at 
>> the MAG does solve both avalanche and tunnel convergence problems.
> 
>>> in the charter, Multimob should attempt to do serious, good work fast!
>>>
>>>       was coined as counterpart to "home subscription" 
>>> (HA-Tunneling). All the approaches we
>>> In conclusion: you should not debate this artifact. It is a pure 
>>> waste of time and drives the group away from serious work and 
>>> momentum to solutions.
>>>
>>> Cheers
>>>
>>> Thomas
>>>
>>> Behcet Sarikaya wrote:
>>>> Hello Folks,
>>>>   Stig and I have been debating this issue, maybe it is time to talk 
>>>> about this 
>>>> 1. Charter requires remote subscription technique and IGMP/MLD Proxy 
>>>> is not 
>>>> dealt 

--

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 20 Nov 2009 19:24:55 -0800 (PST)

Hi Jouni,
________________________________
From: jouni <[email-masked]>
To: Behcet Sarikaya <[email-masked]>
Cc: [email-masked]
Sent: Thu, November 19, 2009 5:31:52 PM
Subject: Re: [multimob] IGMP/MLD Proxy at the MAG

Hi Behcet,

>  - Document how multicast can be supported in a Proxy Mobile IPv6

The above does not prevent us working on a MLD Proxy based solution or any other solution. And if the solution, be that MLD Proxy or something else, works also in a mode where all data comes through LMA, the remote subscription requirement is also met.

[behcet] There are two kinds of MLD Proxies: Independent MLD Proxy at the MAG or MLD Proxy  at the MAG integrated with LMA. The former case would work independent of PMIPv6 so it is not our concern. What we are talking about is MLD Proxy integrated with LMA. In this case MLD Proxy at the MAG communicates with LMA over MAG-LMA tunnel as in PMIPv6. MLD Proxy sends aggregated joins as MLD reports to LMA as MR. All LMA as MR cares is which downstream interface is interested in which multicast groups so that LMA can tunnel multicast data into that downstream interface. It does not know anything about individual MNs.

The charter says:

The work will employ the remote
  subscription model. This is a mechanism by which a mobile node joins a
  multicast group and receives multicast data forwarded via the local
  mobility anchor.Can we call this solution remote subscription as defined above? I find it difficult to do so.

> IGMP/MLD Proxy solves avalanche problem.

I am confused. What this has to do with optimizations? As far as I understand it now, MLD Proxy seems to address the following charter requirements: "This work will not require any additions or changes to message types and parameters specified in RFC 5213, and must assume an unmodified mobile host." This can of course change if we get/find new facts that state opposite.

[behcet] Optimization here is compared with bi-directional tunneling and remote subscription. Clearly MLD Proxy  at the MAG integrated with LMA is an optimization because LMA sends one copy for the whole group which may have many members.
And the charter says the optimizations are left to rechartering.

Hope the above clarifies my points.

Regards,

Behcet

---

From: Stig Venaas <[email-masked]>
Date: Mon, 23 Nov 2009 11:39:57 -0800

> Hi Jouni,

I would say here that the only difference is whether the upstream
interface is to a local router or if it is the MAG-LMA tunnel. The
nice thing is that the operation of the proxy is the same, so it
makes it easy to support both models.

>   mobility anchor.Can we call this solution remote subscription as defined above? I find it difficult to do so.

I think so. What you quote here is exactly what happens in the MLD
proxy case (where the proxy uses MAG-LMA tunnel as upstream).

> And the charter says the optimizations are left to rechartering.

IMO this is not optimization, it is simply multicast. We want to do
multicast, and the we only want to do replication where the topology
branches out. Which means replication at the MAG.

I also want to say that I think the intention of the charter, is that we
work on a basic solution that is as simple as possible. Where we don't
add complexity by trying to solve more than just basic multicast. IMO
the MLD proxy solution is the simplest possible remote subscription
solution.

There may be other solutions, e.g. doing replication at the LMA, but
unless they are simpler solutions, why would we do that and lose the
main benefit of multicast? Are there any technical reasons for doing
replication at the LMA instead of the MAG?

Stig

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 23 Nov 2009 12:45:52 -0800 (PST)

Hi Guang,
  We have several PMIPv6 solution drafts. We appreciate the work presented in these drafts. The current discussion is a charter discussion to see which direction is the right one for the charter items. 
  Solution drafts are useful on their own virtue maybe not necessarily at this stage but certainly in some future stages.
  Please don't get a wrong impression from the current discussion.

Keep up the good work.

Behcet

----- Original Message ----
> From: "Lu, Guang" <[email-masked]>
> To: [email-masked]
> Sent: Fri, November 20, 2009 10:13:42 AM
> > waste

---

From: "Seil Jeon" <[email-masked]>
Date: Tue, 24 Nov 2009 16:23:46 +0900

Hi Behcet, 

Please see below [Seil Jeon].

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Behcet Sarikaya
Sent: Saturday, November 21, 2009 12:25 PM
To: jouni
Cc: [email-masked]
Subject: Re: [multimob] IGMP/MLD Proxy at the MAG

Hi Jouni,

Hi Behcet,

>  - Document how multicast can be supported in a Proxy Mobile IPv6

The above does not prevent us working on a MLD Proxy based solution or any
other solution. And if the solution, be that MLD Proxy or something else,
works also in a mode where all data comes through LMA, the remote
subscription requirement is also met.

[behcet] There are two kinds of MLD Proxies: Independent MLD Proxy at the
MAG or MLD Proxy  at the MAG integrated with LMA. The former case would
work independent of PMIPv6 so it is not our concern. What we are talking
about is MLD Proxy integrated with LMA. In this case MLD Proxy at the MAG
communicates with LMA over MAG-LMA tunnel as in PMIPv6. MLD Proxy sends
aggregated joins as MLD reports to LMA as MR. All LMA as MR cares is which
downstream interface is interested in which multicast groups so that LMA
can tunnel multicast data into that downstream interface. It does not know
anything about individual MNs.

=> [Seil Jeon] Why a LMA have to know individual MN's state in multicasting?
      In the perspective of multicasting (LMA is MR), a LMA only needs
information whether there is a listener or not.
     And I want to know your solution exactly.. both MR are located MAG and
LMA?

The charter says:

The work will employ the remote
  subscription model. This is a mechanism by which a mobile node joins a
  multicast group and receives multicast data forwarded via the local
  mobility anchor.Can we call this solution remote subscription as defined
above? I find it difficult to do so.

unmodified mobile host." This can of course change if we get/find new facts
that state opposite.

[behcet] Optimization here is compared with bi-directional tunneling and
remote subscription. Clearly MLD Proxy  at the MAG integrated with LMA is
an optimization because LMA sends one copy for the whole group which may
have many members.
And the charter says the optimizations are left to rechartering.

=> [Seil Jeon] IMHO, I don't think. We need PMIPv6 multicasting solution
not adding PMIPv6 + multicasting.
     When we consider basic solution for multicasting, we have to find
reasonble way as possible, and it is our job.
     As other folks said, I have no doubt that MLD proxy is simplest
possible approach for remote subscription solution.

Regards,

Behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 24 Nov 2009 08:45:49 -0800 (PST)

Hi Seil,

----- Original Message ----
> From: Seil Jeon <[email-masked]>
> Sent: Tue, November 24, 2009 1:23:46 AM
> Subject: RE: [multimob] IGMP/MLD Proxy at the MAG
> 
> 
> Hi Behcet, 
> 
> From: jouni 
> To: Behcet Sarikaya 

The charter is pointing at a base solution as in MIPv6/MIPv4 which is characterized as bi-directional tunneling and remote subscription in draft-irtf-mobopts-mmcastv6-ps-09.txt. This is what I am saying. 

> possible approach for remote subscription solution.

I think we should understand optimizations looking at the base solution, the optimizations are vis-a-vis the base solution, we can say that locally available multicast with all variations is an optimization. 

Another point is: according to RFC 4605, MLD Proxy forwards multicast data downstream or sends aggregate joins upstream. 
If you read draft-schmidt, 
Based on the multicast-transparent operations of
   the MAGs, the LMA experiences its tunnel interfaces as multicast
   enabled downstream links, serving zero to many listening nodes.
   Multicast traffic arriving at the LMA is transparently forwarded
   according to its multicast forwarding information base.
tunneling is implicit or has been carefully hidden. Isn't this protocol extension?
So I am saying that we should look at these extensions in the next stage.

Regards,

Behcet

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Wed, 25 Nov 2009 21:31:44 +0100

Hi Behcet,

just a quick word below:

> So I am saying that we should look at these extensions in the next stage.

Thanks for reading carefully :-)

But I don't get your point: This passage describes how a router (such as 
LMA) forwards multicast data to its downstream interfaces according to 
its MFIB. The tunnel interface is seen as an interface that does 
encapsulation, implicitly or explicitly, but the interface is not hidden 
(it's also used for PMIP unicast). The use of PMIP tunnels is certainly 
not a protocol extension. It is actually the PMIP way to shift traffic 
between LMA & MAG.

So nothing new here - it's just Internet routing.

Cheers,

Thomas
--

---

From: jouni korhonen <[email-masked]>
Date: Wed, 25 Nov 2009 23:55:44 +0200

Hi Behcet,

On Nov 24, 2009, at 6:45 PM, Behcet Sarikaya wrote:

[snip]

> So I am saying that we should look at these extensions in the next stage.

The MLD Proxy proposal is aligned with RFC5213 way of doing MAG-LMA tunneling. For non-multicast (unicast) traffic there is also one tunnel, which aggregates traffic for multiple MNs between the MAG-LMA. The tunnel interfaces are not "carefully" hidden in any way, for unicast or multicast traffic. What is needed in case of multicast, is having proper route entries pointing to tunnel interfaces in both MAG and LMA side, and SPD entries to match proper type of traffic. I fail to see this as an protocol extension. Furthermore, I don't understand why we would need to come up with a clearly inferior solution when there is a better one available, which even seems to fit into the existing protocol solution.

Cheers,
	Jouni

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 25 Nov 2009 14:13:14 -0800 (PST)

Hi Thomas,

----- Original Message ----
> Cc: [email-masked]; [email-masked]
> Sent: Wed, November 25, 2009 2:31:44 PM
> > Another point is: according to RFC 4605, MLD Proxy forwards multicast data 
> downstream or sends aggregate joins upstream. If you read draft-schmidt, Based 
> on the multicast-transparent operations of
> But I don't get your point: This passage describes how a router (such as LMA) 
> forwards multicast data to its downstream interfaces according to its MFIB. The 
> tunnel interface is seen as an interface that does encapsulation, implicitly or 
> explicitly, but the interface is not hidden (it's also used for PMIP unicast). 
> The use of PMIP tunnels is certainly not a protocol extension. It is actually 
> the PMIP way to shift traffic between LMA & MAG.
> 

The extension is if you consider RFC 4605. I was thinking that you have to extend RFC 4605 in order to be able to integrate IGMP/MLD Proxy into PMIPv6. 
As I said before, yes we can :), but let's do at the next stage.

Regards,

Behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 25 Nov 2009 14:21:09 -0800 (PST)

Hi Jouni,

  It seems like I became like man with the target in your slides, everybody is shooting at me :).

  See more below.

----- Original Message ----
> From: jouni korhonen <[email-masked]>
> Sent: Wed, November 25, 2009 3:55:44 PM
> > I think we should understand optimizations looking at the base solution, the 
> optimizations are vis-a-vis the base solution, we can say that locally available 
> multicast with all variations is an optimization. 
> > 
> downstream or sends aggregate joins upstream. 
> The MLD Proxy proposal is aligned with RFC5213 way of doing MAG-LMA tunneling. 
> For non-multicast (unicast) traffic there is also one tunnel, which aggregates 
> traffic for multiple MNs between the MAG-LMA. The tunnel interfaces are not 
> "carefully" hidden in any way, for unicast or multicast traffic. What is needed 
> in case of multicast, is having proper route entries pointing to tunnel 
> interfaces in both MAG and LMA side, and SPD entries to match proper type of 
> traffic. I fail to see this as an protocol extension. Furthermore, I don't 
> understand why we would need to come up with a clearly inferior solution when 
> there is a better one available, which even seems to fit into the existing 
> protocol solution.

"inferior"?

It depends on how you look at it. Even MLD Proxy may be inferior to another better solution yet to be found.

"SPD entries"? We're not doing any security things yet.

That said, let's continue to discuss and explore all facets, it is going to be productive for sure.

Regards,

Behcet

---

From: Matthias Waehlisch <[email-masked]>
Date: Wed, 25 Nov 2009 23:25:07 +0100

Hi Behcet,

  see inline:

On Wed, 25 Nov 2009, Behcet Sarikaya wrote:

> > > Another point is: according to RFC 4605, MLD Proxy forwards 
> > > multicast data downstream or sends aggregate joins upstream. If you 
> > > read draft-schmidt,
> > >
> > >Based on the multicast-transparent operations of the MAGs, the LMA 
> > >experiences its tunnel interfaces as multicast enabled downstream 
> > >links, serving zero to many listening nodes. Multicast traffic 
> > >arriving at the LMA is transparently forwarded according to its 
> > >multicast forwarding information base.
> > But I don't get your point: This passage describes how a router (such 
> > as LMA) forwards multicast data to its downstream interfaces according 
> > to its MFIB. The tunnel interface is seen as an interface that does 
> > encapsulation, implicitly or explicitly, but the interface is not 
> > hidden (it's also used for PMIP unicast). The use of PMIP tunnels is 
> > certainly not a protocol extension. It is actually the PMIP way to 
> > shift traffic between LMA & MAG.
> > 
> The extension is if you consider RFC 4605. I was thinking that you have 
> to extend RFC 4605 in order to be able to integrate IGMP/MLD Proxy into 
> PMIPv6. As I said before, yes we can :), but let's do at the next stage.
> 
  What are you talking about? As Thomas said there is nothing new, 
especially no extension.

  Please, say clearly what is the extension in which draft! If it helps, 
draw a picture.

Thanks
  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: Wed, 25 Nov 2009 14:32:58 -0800

>> PMIPv6. As I said before, yes we can :), but let's do at the next stage.

Not sure if this helps, but RFC 4605 does not care about the interface
types. So whether an interface is a tunnel or not makes no difference
wrt 4605.

---

From: jouni korhonen <[email-masked]>
Date: Thu, 26 Nov 2009 12:47:18 +0200

Hi Behcet,

>   It seems like I became like man with the target in your slides, everybody is shooting at me :).

Heh ;)  Maybe I need to update the ending slides for the next meeting..

[snip]

> It depends on how you look at it. Even MLD Proxy may be inferior to another better solution yet to be found.

This is, of course, true. 

> That said, let's continue to discuss and explore all facets, it is going to be productive for sure.

Sure.

Cheers,
	Jouni

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 30 Nov 2009 10:19:28 -0800 (PST)

Hello Matthias,
  What I'm saying is simple:

RFC 4605 defines upstream to MLD Proxy as a regular IP interface and same as downstream to MR.

It is clearly not a link-local interface.

It is also clearly not a tunneling interface. 

draft-schmidt is introducing tunneling on this and this is an extension.

Does RFC 4605 care about tunneling? I don't know. If they did they would have mentioned it in the RFC.

I hope it is clear now. Sorry for not making it clear before.

Regards,

Behcet

----- Original Message ----
> From: Matthias Waehlisch <[email-masked]>
> Sent: Wed, November 25, 2009 4:25:07 PM

---

From: Matthias Waehlisch <[email-masked]>
Date: Mon, 30 Nov 2009 21:56:05 +0100

Hi Behcet,

  thanks for clarification!

  As Stig said: MLD operates transparently w.r.t. the interface type.

> same as downstream to MR.
  No: according to RFC4605, an upstream interface is defined as follows:

--snip--

2.1.  Upstream Interface

   A proxy device's interface in the direction of the root of the tree.
   Also called the "Host interface".

--snap--

  You make two mistakes:

  1. the direction/perspective of the upstream interface

  2. RFC4605 does not make any assumption according to the type of the 
interface

> It is also clearly not a tunneling interface. 
  In which part of the RFC is this stated?

> draft-schmidt is introducing tunneling on this and this is an extension.
  First is correct, second is incorrect.

> have mentioned it in the RFC.
  That's nonsene: You are right, they they did not mention tunneling. But 
as consequence, they did not care about tunneling. RFC4605 operates 
transparently to the interface type.

> I hope it is clear now. Sorry for not making it clear before.
  Thanks again.

  If I am incorrect, please state appropriate parts of the RFC(s).

Thanks
  matthias

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 30 Nov 2009 13:11:28 -0800 (PST)

Hi Matthias,
  Is host interface a tunnel interface?

My answer is no. Tell me if your answer is yes?

So I think this closes the discussion.

Regards,

Behcet

----- Original Message ----
> Sent: Mon, November 30, 2009 2:56:05 PM