Subject: [multimob] draft-asaeda-multimob-pmip6-extension-05

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 21 Mar 2011 14:52:24 -0700 (PDT)

Hi Hitoshi,
  I read your draft and have some comments.
In section 3.3, you say MN sends MLD Report upon multicast data reception. Why? 
I think there is something wrong in that sentence.

Your draft is long and detailed and on top of that it mentions [9] 
draft-asaeda-multimob-igmp-mld-mobility-extensions-03.txt as normative 
reference. 

What I am more curious about is how your draft solves the tunnel convergence 
problem. I don't think it is the M-Tunnel because as you mentioned M-Tunnel is 
MAG-LMA tunnel as in [2], i.e. RFC 5213. 

I don't think it is MAG as PIM-SM router as you mention that operators would not 
like it. Sorry but I could not find a specific solution proposal in your draft. 
Maybe I missed something.

How relevant your Section 7 is to the tunnel convergence solution? I have a 
feeling that  it is more relevant for handover optimizations work item we have.

Regards,

Behcet

---

From: Hitoshi Asaeda <[email-masked]>
Date: Wed, 23 Mar 2011 19:46:07 +0100 (CET)

Hi Behcet,

> I think there is something wrong in that sentence.

I cannot understand what's wrong here?

> draft-asaeda-multimob-igmp-mld-mobility-extensions-03.txt as normative 

Right, that draft should be informative reference. I'll move it in the
next revision.

> problem. I don't think it is the M-Tunnel because as you mentioned
> M-Tunnel is MAG-LMA tunnel as in [2], i.e. RFC 5213. 

Single M-Tunnel is established between LMA-MAG and dedicated to
MLD messages and multicast data transmission. It is shared by all MNs
attached to a MAG. It's not established per MN, unlike rfc5213.

> Maybe I missed something.

It is one of the possible ways for multicast services in PMIPv6
domain. I cannot find the reason to prohibit PIM-SM capable MAG.
In fact, since an incoming interface can be set up by the PIM-SM
capable MAG, it gives the chance of localized routing and source
mobility without any protocol modification.
Giving the possibility of a PIM-SM capable MAG would be rather
positive in my feeling.

> How relevant your Section 7 is to the tunnel convergence solution? I
> have a feeling that it is more relevant for handover optimizations
> work item we have.

I think sharing single M-Tunnel by all MNs address the tunnel
convergence problem. If you don't think so, could you tell me what the
problem is?
Regarding handover, I believe our proposed extension is not only
simple and in line with the standard functions, but effectively 
provides seamless handover.
I don't deny someone will propose other mechanisms or extensions with
a different view for the optimization in the later phase, such as
proactive handover. But their mechanisms might require more extension
or additional functions to give more optimization. Our proposal could
be defined as the base extension for them, I guess.

Regards,
--
Hitoshi Asaeda

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 23 Mar 2011 12:31:12 -0700 (PDT)

Hi Hitoshi,

> I cannot understand what's wrong here?

May be you meant in order to join a group?

> attached to a MAG. It's not established per MN, unlike  rfc5213.

see below.

> Giving the possibility of a PIM-SM capable MAG would  be rather

Yes, if PIM-SM can be deployed at all MAGs, tunnel convergence problem won't 
happen. This is kind of like local routing.

> convergence problem. If  you don't think so, could you tell me what the

No because the tunnel convergence problem happens due to multiple LMAs and MNs 
connected to multiple LMAs joining the same group like G1. Then LMAs deliver 
multicast data from G1 to the MAG and MAG just replicates the data to each 
member MN.
M-Tunnel does not address this problem.

I hope this is clear. 

> be defined as the base extension for them, I  guess.

You need to show how relevant it is to the tunnel convergence problem. Right now 
I cannot see it.

Regards,

Behcet

---

From: Hitoshi Asaeda <[email-masked]>
Date: Thu, 24 Mar 2011 09:44:06 +0100 (CET)

Hi Behcet,

> May be you meant in order to join a group?

Ok, then I change it to "when it subscribes a multicast channel".

> M-Tunnel does not address this problem.

Ok, I understand.
This consideration may be addressed with various approaches.
Our current proposal is in line with the concept of minimum protocol
modification, hence I'd propose the following changes.

There is a statement in section 5.1;

   An MLD proxy requires that the upstream and downstream interfaces
   MUST be statistically configured.  As well, MAG MUST configure an
   upstream interface that is the interface MLD Report messages are sent
   to LMA and downstream interfaces that are the interfaces MLD Report
   messages are received from mobile nodes.  This upstream interface is
   the M-Tunnel end-point at the MAG.

and I'll append the following sentence;

   Whether MAG acting as an MLD proxy connects to a single or multiple
   LMAs, M-Tunnel for the MAG MUST be established with one LMA.

Also, I'll change a paragraph in section 5.2 as follows;

   Because of its implementation or operational costs, operators may not
   want to support PIM-SM on MAG.  However, an MLD proxy requires to
   statically configure its upstream interface, which is an M-Tunnel as
   specified in Section 5.1, to receive all multicast data. It also does
   not allow multiple incoming interfaces. Hence even if MAG acting as
   an MLD proxy connects to multiple LMAs, it cannot establish with
   multiple M-Tunnels for each LMA. Therefore, if operators decide to
   support the case that 1) an upstream interface for the optimized
   multicast path is NOT an M-Tunnel to LMA but other interface, and
   should be dynamically selected by MAG according to the optimized
   routing path, or 2) MAG should establish multiple M-Tunnels for
   different LMAs, and an incoming interface should be decided by the
   RPF check, then MAG MUST act as a PIM-SM router.

There might be some discussions for this, but I think above sentences
would become a reasonable start.
I'd appreciate any input, especially from providers and operators.

Regards,
--
Hitoshi Asaeda

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 24 Mar 2011 09:12:20 -0700 (PDT)

Hi Hitoshi,
  Looking at the draft name, i.e. it is about pmip6 extensions, it seems to have 
much larger scope.
I suggest revising it to address only 
PMIPv6 routing optimizations to avoid tunnel convergence problem

maybe you can have another draft to address 
handover optimizations.

Regards,

Behcet

---

From: Hitoshi Asaeda <[email-masked]>
Date: Thu, 24 Mar 2011 21:23:51 +0100 (CET)

Hi Behcet,

> maybe you can have another draft to address 

Our approach (extension) supports routing optimizations and seamless
handover, but it is pretty simple.

We propose to set up the bi-directional tunnel called M-Tunnel that is
dedicated to multicast transmission.
And the protocol extensions are only new PBU-M message for PMIPv6 and
new M-CTD message for CXTP.
There are no other extensions.

If we have concensus, I would be able to split my current draft to two
drafts. But IMO, it is reasonable to keep it as is.

Regards,
--
Hitoshi Asaeda

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 24 Mar 2011 14:10:44 -0700 (PDT)

> drafts. But IMO, it is reasonable to  keep it as is.

Hitoshi, my comments were individual, all hats off.

Regards,

Behcet