Re: Preparing for DMM future steps and rechartering

Please see inline, Carlos.

>-----Original Message-----
>From: Carlos Jesús Bernardos Cano [mailto:[email protected]]
>Sent: Mittwoch, 13. November 2013 12:48
>To: Marco Liebsch
>Cc: Sri Gundavelli (sgundave); Peter McCann; [email protected]
>Subject: Re: [DMM] Preparing for DMM future steps and rechartering
>
>Hi Marco,
>
>On Wed, 2013-11-13 at 11:23 +0000, Marco Liebsch wrote:
>> 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.
>
>I'm not sure I agree on this. To me this seem to already assume a certain
>solution. And I'm biased because I also have some solutions in mind :D

Not a solution, but a deployment model. The solution would dig into the
protocol bits of a selected protocol e.g. BGP to solve that. That's not what
I am writing about. I write this only to abstract the available solutions to
deployment models and see where the DMM group can do some work to
enable a variety of them.

>
>For example, I think we should not limit only to downlink, unless the ingress
>filtering is not considered an issue (if it is not, this also kind-of assumes a certain
>type of solution).


For sure not. I refrained from describing the complete sequence, as it's not
relevant for this discussion. Just trying to draw some models and see which
gaps DMM can close.

>
>>
>> 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.
>
>Agree, but a routing approach could also be applied even if the anchors are not
>placed on the radio access points. That's why I see routing as an alternative
>solution to IP mobility protocols.

Sure. But I am not sure that it should be the DMM group that builds a new
alternative to IP mobility. What's the gap analysis then about?
Interesting to research about, though.

>
>>
>> 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.
>
>I agree. It would be helpful to get some feedback from operators on which
>deployments they have more interest on.


Good.

Thanks,
marco

>
>Thanks,
>
>Carlos
>
>>
>> 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