Re: [MEXT] the future of the MEXT working group

> -----Message d'origine-----
> De : jouni korhonen [mailto:[email protected]]
> Envoyé : vendredi 4 novembre 2011 13:38
> À : SEITE Pierrick RD-RESA-REN
> Cc : [email protected]; [email protected]
> Objet : Re: [MEXT] the future of the MEXT working group
> 
> Pierrick,
> 
> On Nov 4, 2011, at 11:28 AM, <[email protected]>
> <[email protected]> wrote:
> 
> >> Also, I think we ought not only consider just mobility enhancement.
> More
> >> efficient use of CoA(s) for direct/local/non-tunneled communication
> along
> >> with existing mobility solutions should be in scope as well.
> >>
> >
> > Actually, this is the idea behind dynamic mobility management described
> in the charter: use the CoA for IP flow which does not require mobility
> support. We are inline.
> >
> > Pierrick
> 
> Nit picking and a bit of intentional teasing ;) Above is currently about a
> half.. one clear statement in the charter proposal is "the distribution of
> mobility anchors to achieve a more flat design".  The other clear
> statement is "the dynamic activation/deactivation of mobility protocol
> support as an enabler". However to use CoA(s) or any address you get
> locally falls greatly into the source address selection issues, which is
> not really about mobility per se. You don't necessarily even need
> distributed mobility anchors to facilitate that. 

I agree, and I'm not saying that we need to distribute mobility management to benefit from dynamic MM. But I think that distribution can facilitate dynamic MM, even brings dynamic MM natively. Typically, if HA are co-located on each AR: the MN can initiate a communication with the IP obtained from the current AR, with standard IP routing coming into play. Then, if the MN changes the point of attachment, mobility management come into play: previous AR plays the HA role and the current IP is binded to the Ip obtained on the new AR. But, it's just an example of solution and, as you said, there are many other possible ways. So, I'll not digress more; I just want to stress that dynamic MM should not be ignored in future work.

Pierrick

Of course, there are vast
> amount possible solution approaches in this space.
> 
> - Jouni