Re: [DMM] Comments on draft-patil-dmm-issues-and-approaches2dmm-00

[jouni korhonen <[e-mail]>]

Pete,

Thanks for the review. Some thoughts inline.

On Mar 6, 2012, at 11:48 PM, Peter McCann wrote:

> Hi, Raj, Carl, and Jouni,
> 
> I have some comments on draft-patil-dmm-issues-and-approaches2dmm-00.
> 
> I agree with most of Section 4, "Issues with current mobility models".  However,
> I'd like to point out that existing networks are not just centralized in the manner
> you point out, they also tend to have a hierarchical structure, e.g., the 
> S-GW/P-GW split in 3GPP EPC.  Therefore, the issue you outline in Section 4.3

It is quite common to run combined nodes. 

> ("Inefficient Routing and signaling overhead") is not quite true of the 3GPP
> EPC, which can handle many mobility events in a localized manner similar to
> HMIP.

Could you clarify which functionality in EPC you refer to from IP point of
view?

> 
> The first paragraph of Section 7 talks about source address selection, and the
> need to modify applications so that they request the kind of address that they
> want.  I tend to think that applications will remain unmodified for some time
> to come; however, most applications fit into the paradigm of opening short-lived
> connections to a server and could be accommodated with some sort of automatic
> handling in the MN's IP stack.

I tend to think that developers who care and see some benefit for their
applications would update. Completely automated solution within the stack
would be nice but that also entails larger MN update and would also need
some additional (out of band) policy information to guide address selection.

> 
> I found the last paragraph of Section 7 quite interesting.  I too think that there
> is an important piece missing that you call "seamless mobility anchor relocation".
> I think that the use of an interior routing protocol is spot on.  In fact, if you
> read draft-mccann-dmm-flatarch-00, I propose just that.  I think we can use such
> an anchor relocation protocol to make each access router in an autonomous system
> (or smaller region of an autonomous system) a temporary anchor for a given prefix.
> In my draft I propose running I-BGP on each AR and sending BGP UPDATES into the
> network upon localized mobility events.  Such a protocol can also be used as a

I yet need to read your draft properly.. but in general trying to solve
mobility issues with routing protocols is just moving the problems out
of your hands to others. You easily end up with uncomfortable amount of
host routes and your network being constantly in a "converging" state..

> substitute for the proxy ND technique that is currently specified to "grab" the
> MN's packets at the HA.  By using a routing protocol, the HA can reach across
> several routing hops so it doesn't necessarily need to be on the home link (which
> can be the first AR to which the MN attached).  I think this would also enable us
> to unify the authentication protocols used at the AR with the authentication protocol
> used at the HA.  The ARs are just like HAs that don't have to tunnel the data anywhere
> because the MN is locally connected.

There are virtues for exploring the routing protocol "enslavement" for 
additional mobility management. Geo-redundancy would, for example, benefit
from it.

- Jouni


> 
> Does it make sense to you?
> 
> --
> Peter J. McCann
> Huawei Technologies (USA)
> [e-mail]
> [phone]
> Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ  08807-2863  USA
> 
>