Re: Preparing for DMM future steps and rechartering

Carlos, 

just to clarify my view here: I do not see them as different approaches,
but in a way that the routing approach can complement mobility anchor-based
approaches (MIP-like protocols). And such routing support is needed only
in certain deployments, i.e. in case of a runtime change of the MN's anchor
while the new anchor imports the MN's IP address (binding) context to enable IP address
continuity. To enable routing the MN's downlink data to its current anchor
in the transport network above anchor level, e.g. host routes can be used.

We end up in a routing-only approach if these anchors will be distributed to an extreme
and placed e.g. on radio access points and the approach uses something else than
MIP protocols to transfer IP address context between these access points. Then we
have Pete's DMM deployment model. 

Do you agree to that view?

I think there is common understanding that DMM is a lot about deployment.
Any of those deployment models are valid. Whereas the DMM WG cannot work on all
extensions needed to enable all models, we should converge on a reasonable
set of first work items to allow operators to enable DMM in their network.

marco


>-----Original Message-----
>From: Carlos Jesús Bernardos Cano [mailto:[email protected]]
>Sent: Mittwoch, 13. November 2013 11:51
>To: Marco Liebsch
>Cc: Sri Gundavelli (sgundave); Peter McCann; [email protected]
>Subject: Re: [DMM] Preparing for DMM future steps and rechartering
>
>Hi,
>
>I'm also jumping into the discussion a bit late.
>
>Without going into all the detailed discussions that have taken place recently, I
>just want to share my view on the MIP-based vs routing-based approach.
>
>IMHO, we probably need to further look at both approaches in this group, but
>with enough energy level (otherwise we risk to end up with nothing after several
>years). I personally have my doubts that a distributed routing-based approach
>scales in a moderately large domain (we also saw many years ago proposals of
>doing mobility with routing that did not take off because of convergence,
>scalability and administrative issues).
>I think a MIP-based approach (network or host based) would work, though it
>would imply keeping multiple anchors active for a given MN.
>
>We believe this routing-based vs MIP-based comparison is quite interesting, and
>we are actually working at UC3M on experimentally evaluating both, so we can
>make a more educated statement on pros and cons of each of them.
>
>My two cents,
>
>Carlos
>
>On Wed, 2013-11-13 at 10:10 +0000, Marco Liebsch wrote:
>> Hi Sri, all,
>> let me step in here (with some delay..) to clarify one point you raised.
>> Please see inline.
>>
>> >-----Original Message-----
>> >From: [email protected] [mailto:[email protected]] On Behalf Of
>> >Sri Gundavelli (sgundave)
>> >Sent: Montag, 11. November 2013 16:30
>> >To: Peter McCann
>> >Cc: [email protected]
>> >Subject: Re: [DMM] Preparing for DMM future steps and rechartering
>> >
>> >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.
>>
>> My intention is not to eliminate a tunnel that exists in any of the
>> tunnel management protocols (aka MIP6, PMIP6, ..). My picture of DMM
>> primarily distributes topological anchor point for the MN's IP address(es).
>Forget about the C-plane for now.
>> Tunnels apply solely below (well, towards access) such anchor.
>> If we distribute them to an extreme, they are placed on radio access
>> points and the tunnel disappears. Then we arrive at Pete's model. If
>> anchor points are somewhere above, say in the backhaul, the tunnel
>> remains at least between the anchor and some node in the access (network
>based mobility mgmnt) or the MN (host based mobility mgmnt).
>>
>> I think none of the proposals wants to discuss away the tunnels as per
>> MIP/PMIP. But above anchor level, regular routing applies to plain data
>packets of the U-Plane.
>> A key component for DMM, IMO, is how to accomplish that routing
>> towards the MN's current anchor point, even if the anchored IP address is
>topologically incorrect.
>> To accomplish this, my intent is to not introduce tunnels above anchor level.
>> So, it's not about eliminating tunnels, but it is about not
>> introducing tunnels where never have been tunnels before :-)
>>
>> marco
>>
>> > 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
>> _______________________________________________
>> dmm mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/dmm
>

_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm