Re: Preparing for DMM future steps and rechartering

Hi, Sri,

Sri Gundavelli (sgundave) 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. 

As I said in jabber during the meeting we need to carefully define these
terms.

Let's try to use the term MAG consistently.  It means the first node that
can see IP packets from the MN.  In my mind this should be co-located with
the L2 termination point.

As for "mobility anchor" I am not sure what is your definition of that term.
If you mean some router in the network that the packets for a given MN's
assigned IP address are delivered, then that entity can change over the 
period of time the address is assigned to a given MN.  IMHO when the address
is assigned, that node should be the MAG to which the MN is attached at the
time of assignment.  You can do this by choosing the pool of addresses that
are normally routed to the MAG.  When the MN moves, the "mobility anchor"
can be changed if the routing tables are updated.

> 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. 

If we can change the "mobility anchor" to always be the current MAG while
the MN is in the same domain (or perhaps the same part of a domain) then
there will not be a need for tunnels during that period of time.  You need
a tunnel when you move outside the domain under which routing protocols are
scalable.  This can be a client-MIP tunnel because there won't be much need
to update it, assuming the new CoA is managed in the same way by whatever
network the MN is on at that time.

> 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.  

MAG authenticates the MN when it attaches/moves in.  Authentication gives
an MN ID.  MN ID is used to lookup IP addresses currently assigned.  UPDATE
is generated for those IPs to attract packets to the current MAG.  Mission
accomplished.

> 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.

I think you mean the discussion will not converge, when Alex interpreted 
this to mean the routing tables won't converge... anyway, I hope we can
consider routing protocols as one way to accomplish localized mobility
management.

-Pete

> 
> 
> 
> 
> 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