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

[Behcet Sarikaya <[e-mail]>]

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

> Hi Behcet,
> 
> >> >  In section 3.3, you say MN sends MLD  Report upon multicast data
> >> >  reception. Why? 
> >>  > I think there is something wrong in that  sentence.
> >> 
> >> I cannot understand what's wrong here?
> > 
> > May be you  meant in order to join a group?
> 
> Ok, then I change it to "when it  subscribes a multicast channel".
> 
> >> > 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?
> > 
> > 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.
> 
> 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
>