Re: Preparing for DMM future steps and rechartering

Hi Marco,

Thanks for the discussion. Please see inline below.

On Wed, 2013-11-13 at 11:59 +0000, Marco Liebsch wrote:
> 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.

Well, I'm not sure about that. To me, keeping always a single anchor by
effectively moving the it using a routing approach is a different
solution that using multiple distributed anchors, and keeping old ones
while there active communications ongoing (and using more "optimal" ones
for new communications).

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

OK.

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

Agree.


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

Thanks,

Carlos

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