Re: Preparing for DMM future steps and rechartering

http://tools.ietf.org/html/draft-mccann-dmm-flatarch-00

-Pete

Behcet Sarikaya wrote:
> I think we need a draft from Pete on this so we can all understand
> what is being proposed.
> 
> 
> Regards,
> 
> 
> Behcet
> 
> 
> 
> On Mon, Nov 11, 2013 at 9:29 AM, Sri Gundavelli (sgundave)
> <[email protected]> wrote:
> 
> 
> 	Hi Pete,
> 
> 	I'm not sure, I agree with this, or understand this to be precise. I do
> 	not know know CP (in the form of PMIP, GTP or some other protocol XYZ)
> can 	be completely eliminated. There needs to be some interface between
> the 	access gateway and the mobility anchor. I assumed your's, Marco's
> and 	Ryuji's goal is for eliminating the tunnel, which I don't believe
> it can 	be achieved, but still thought we can discuss this. IMO, its not
> just 	about inserting a RIB route and redistributing it, but even there
> in DP 	there is a state transfer needed  from the CP and the DP.
> Starting point 	appears like a simple route propagation, very soon it
> will end up with a 	bunch of state that gets moved between the two
> nodes.  But, may be I don't 	understand the ideas clearly on eliminating
> CP and eliminating tunnels. 	I'm not going to oppose this, I don't see
> this converging, IMHO.
> 
> 
> 
> 
> 	Regards
> 	Sri
> 
> 
> 
> 
> 	On 11/10/13 3:13 PM, "Peter McCann" <[email protected]> wrote:
> 
> 	>Hi, Sri,
> 	>
> 
> 	>I think you will agree that PMIP is a control protocol for setting up
> 	>tunnels.  A tunnel implies that we are not using the destination IP
> 	>of the inner packet for routing and by definition will lead to a
> 	>non-optimal 	>route and a bit of state on some box that can fail and
> lose that state. 	> 	>I hope that DMM can consider other approaches such
> as injecting routes 	>from the latest L2-attachment point into the
> access network, which is 	>a truly Distributed Mobility Management
> protocol for getting the packets 	>to the mobile node.  It will lead to
> more optimal routes and more robust 	>fault-tolerant operation of the
> network. 	> 	>I think we can continue to use the term MAG to apply to
> that first-hop 	>router which is hopefully co-located with the L2
> termination point (it 	>may not be so in every technology depending on
> the extent to which that 	>technology has evolved to support truly
> Distributed operation). Anything 	>that happens below the MAG (between
> the MAG and the L2 termination point) 	>should be out of scope and we
> should not define any protocol there and we 	>should discourage any
> separation between the two. 	> 	>However, we should not require the MAG
> to run any form of PMIP because 	>tunnels should not be required in the
> architecture.  We should not require 	>an LMA, because this would imply
> a central point of state maintenance and 	>possibility of failure. 	>
> 	>It is fine to consider a split between CP and DP but I thought we had
> 	>agreed 	>that any discussion of the protocol to use on such an
> interface would be 	>out of scope for this WG.  IMHO we should leave
> that to the Wireless & 	>Mobile 	>Working Group of ONF. 	> 	>Now, the
> proponents of OpenFlow and other CP/DP splits have argued that 	>it is
> 	>better to centralize the algorithms such as routing protocols on a
> 	>logically 	>centralized server or servers with a synchronized global
> view of the 	>network. 	>I have no problem with that, in which case this
> centralized controller 	>just 	>needs to get notified about the MN's
> current attachment point, so it can 	>install 	>the routes (or tunnels,
> if an operator wishes to use them) into the DP. 	>But, 	>the mechanisms
> for doing so are out of scope for the DMM WG because we 	>are not
> 	>working on a CP/DP split.  I think it would be appropriate for the DMM
> WG 	>(which 	>exists in the IETF, a standards body that has a long
> history of 	>developing 	>distributed and fault-tolerant routing
> protocols) to describe a more 	>distributed 	>alternative, building on
> foundational Internet technologies such as 	>I-BGP, in 	>such a way that
> will bring down the costs, reduce the latency, and 	>increase the
> 	>robustness of wireless access networks. 	> 	>I actually don't think we
> need to define any new extensions or IEs for 	>BGP; I 	>would like to
> read more about Ryuji's proposed extensions here. All we 	>need is 	>for
> the MAG to learn what IPs have been assigned to the MN, decide which
> 	>of those 	>IPs are in the scope of the local AS, and inject routes for
> those 	>prefixes to 	>itself.  We could work on alternative mechanisms
> for discovering this 	>list of 	>addresses - the fundamental requirement
> is that we use an authenticated 	>MN ID 	>(probably an NAI) as an index
> to lookup the set of IPs in a distributed 	>database. 	>I've proposed
> using DNS for this but there are other alternatives. We 	>also need 	>a
> way to make sure the latest UPDATE gets used by all the BGP peers.
> 	>I've proposed 	>putting a timestamp in LOCAL_PREF but there are
> probably other 	>alternatives. 	> 	>It would also be nice to have a
> well-defined fall-back mechanism in case 	>the MN 	>moves to a different
> AS or just too far from the original MAG, in which 	>case the 	>I-BGP
> approach wouldn't scale.  For these cases, I think a client MIP 	>tunnel
> to 	>an HA located in the original AS for each assigned IP address would
> be 	>ideal. 	>The HA can behave just like the MAGs in that domain,
> injecting routes 	>when MNs 	>establish tunnels to it so as to attract
> the packets to themselves (this 	>would 	>be the routing equivalent of
> the proxy-ARP or proxy-ND mechanism that 	>works on 	>just a single home
> link in MIPv4 or MIPv6).  We should work on mechanisms 	>to enable
> 	>dynamic assignment of local HAs to MNs and dynamic establishment of
> 	>security associations 	>that don't require AAA and associated
> round-trips to the home network. 	>Because the HA 	>is associated with
> the original MAG that assigned the address, this may 	>involve 	>some
> DHCP extensions.  There is already a way to assign the HA IP address
> 	>but we 	>will need new extensions to carry the HA credentials to the
> MN (maybe 	>just an HA DNS 	>name so the MN can use DANE to retrieve a
> public key). 	> 	>I think something like the path I've outlined above
> would make a good 	>work plan 	>for the future of DMM. 	> 	>-Pete 	>
> 
> 
> 	_______________________________________________
> 	dmm mailing list
> 	[email protected]
> 	https://www.ietf.org/mailman/listinfo/dmm
> 
>