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

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

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

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

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