Re: [multimob] PMIPv6 extension for multicast

["Thomas C. Schmidt" <[e-mail]>]

Hi Hitoshi, hi all,

we worked through your revised draft and have the following feedback:

For the general, the draft seems to rephrase operations of GRE 
tunneling, PIM and MLD in your own words which leaves unclear, what 
actually is the standard protocol behavior (defined elsewhere), and what 
is particular for your proposal. Understanding is also hindered by 
observations that are correct, but unrelated to the specific subject, 
and also statements that are incorrect.

In detail, we extracted the following contributions:

   1.) Your proposal only addresses SSM (without ever mentioning this)
   2.) You span a full mesh of M-tunnels between all MAGs and all LMAs 
(in addition to PMIP tunnels)
   3.) You deploy PIM-SSM on all MAGs and all LMAs

Since this scenario experiences the routing convergence problem 
described in http://tools.ietf.org/html/rfc5757#section-2.2.2 (which you 
should reference, btw.), you define

   4.) Some additional smoothing procedures for handover

Did we understand this correctly?


Our comments on this:

Ad 1.): It is legitimate to define solutions solely for SSM, but this 
should be mentioned right away (in title and abstract).

Ad 2.): A mesh of permanent tunnels appears pretty ugly. In a large PMIP 
deployment, you will end up with hundreds to thousands of 
multicast-induced tunnels at a single LMA. This raises severe scaling & 
complexity issues, but most likely will be unfeasible for cross-domain 
PMIP deployments. As these tunnels are static and beyond the control of 
the PMIP prefix management, there may be issues arising for unicast 
routing, as well.

Ad 3.): PIM-SSM should transparently work on such a dense router mesh. 
However, multicast routes (selected from RPF) may not turn out to be as 
described in your draft. After an MN joins (S,G), its MAG selects the 
upstream according to the unicast route to S. What will this be? Most 
likely, S is completely "unrelated" to the MN and to its LMA, so the 
route to S may go wherever the (unicast) routing table of the local MAG 
points to. In many cases this will be default.

In addition, once MN1 has established service of (S,G) at a MAG, a newly 
arriving MN2 will inherit this service (which is efficient). Now, if MN1 
detaches, MN2 will continue to be served on the same route as MN1 did. 
In the (unlikely) case that MN1 had been subscribed to a "home service" 
(via its LMA, as suggested in your draft), MN2 continues to consume the 
"home service" of MN1, even though MN1 is gone.

This leads to a picture which is complicated, disadvantageous in 
policy-based conditions (btw. conflicts with your policy-store solution) 
and contradicts the PMIP service model.


As an intermediate summary: If we understood correctly, up until this 
point you have defined only a deployment scenario, but no new protocol 
operations or semantic. So this could simply be activated based on the 
protocols available today ... but may lead to a quite unexpected outcome ;)


Ad 4.): The scenario so far adapts to mobility via the PIM-SSM routing 
dynamics, which may be too slow for smooth handoffs. That's why you 
define three protocol extensions for smoothing the handover process for 
multicast (isolated from unicast handover management).

Comments on this:

  * Policy Profile: Your policy is acquired from LMA (after a regular 
PMIP handover). This is actually the long path & slow procedure, so I 
don't expect much acceleration here ... in particular, you cannot be 
faster than unicast (slow) handover. Also: this policy management 
conflicts with the routing scenario mentioned above.

  * Extended Proxy Binding Update: This I actually cannot understand. 
You inform the nMAG of multicast subscriptions prior to handover ... so 
you do a predictive handover, but you don't define any prediction 
mechanism. I cannot see how this works ...

  * CXTP: This context transfer is de-synchronized from the unicast 
handover, which does not really help in handover acceleration (cannot be 
faster than unicast, complicates a synchronization later ...).

CXTP handover may be interesting in the cases discussed after Prague (a 
new broadcast access link is selected solely for multicast reception 
...). We believe its not the most suitable approach here.


So far for the feedback - did we miss(s/s/ -understand) something?

Best regards,

Thomas & Matthias


On 15.07.2011 12:32, Hitoshi Asaeda wrote:
> Hello folks,
>
> We revised our PMIPv6 extension draft as follows:
>
> http://tools.ietf.org/html/draft-asaeda-multimob-pmip6-extension-06
>
> This draft specifies the scenario in which both LMA and MAG act as
> PIM-SM routers. This draft addresses the tunnel convergence problem
> and provides seamless handover. It defines Proxy Binding Update and
> Proxy Binding Acknowledgement messages with multicast extension.
>
> Comments welcome.
>
> Regards,
> --
> Hitoshi Asaeda
>
>
> _______________________________________________
> multimob mailing list
> [e-mail]
> 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: [phone] °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: [phone] °