Re: [MEXT] IETF-80 meeting minutes posted / clarifications on draft-liu-mext-distributed-mobile-ip

Hi Romain,

Thanks for the feedback. Please see inline.


Regards,
Pierrick

> -----Message d'origine-----
> De : Romain KUNTZ [mailto:[email protected]]
> Envoyé : mercredi 20 avril 2011 22:31
> À : SEITE Pierrick RD-RESA-REN
> Cc : [email protected]
> Objet : Re: [MEXT] IETF-80 meeting minutes posted / clarifications on
> draft-liu-mext-distributed-mobile-ip
> 
> Hello Pierrick,
> 
> Allow to jump into the discussion, I have a couple of questions regarding
> this draft.
> 
> On Apr 20, 2011, at 1:14, <[email protected]>
> <[email protected]> wrote:
> > IMHO, the "multiple home addresses" feature was misunderstood during the
> meeting. It is not require that a MN attached to a HA uses severals HoAs.
> Actually, the MN can use several home addresses only when attached to
> several HAs. Considering the use-case above, it means:
> > - Flow#1 served by HA1/AR1 and uses HoA1
> > - flow#2 served by HA2/AR2 and uses HoA2
> 
> Still, how does a CN that wishes to contact a MN selects the correct Home
> Address? The MN would need to be always anchored to one HA in order to
> keep at least one stable HoA over time.
> 

Right, reachability is an issue. Section 4.2 of http://tools.ietf.org/html/draft-yokota-dmm-scenario gives clues for solution. Relying temporally on a centralized mobility anchor point could be also a solution. Anyway, we have to think more about that.

> Also, how would you prevent a malicious node to register 2 symmetric
> bindings at 2 different home agents (say HoA1<->HoA2 at HA1, and HoA2<-
> >HoA1 at HA2), which could potentially lead to a routing loop between both
> HAs?
> 

Good point. But, IMHO, this issue is not specific to a distributed mobility architecture. For instance, http://tools.ietf.org/id/draft-ng-intarea-tunnel-loop-00.txt discusses the issue and proposes solution.

> Regards,
> Romain