Please see inline, Carlos. >-----Original Message----- >From: Carlos Jesús Bernardos Cano [mailto:c...@it.uc3m.es] >Sent: Mittwoch, 13. November 2013 12:48 >To: Marco Liebsch >Cc: Sri Gundavelli (sgundave); Peter McCann; dmm@ietf.org >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:c...@it.uc3m.es] >> >Sent: Mittwoch, 13. November 2013 11:51 >> >To: Marco Liebsch >> >Cc: Sri Gundavelli (sgundave); Peter McCann; dmm@ietf.org >> >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: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf >> >> >Of Sri Gundavelli (sgundave) >> >> >Sent: Montag, 11. November 2013 16:30 >> >> >To: Peter McCann >> >> >Cc: dmm@ietf.org >> >> >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" <peter.mcc...@huawei.com> >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 >> >> >dmm@ietf.org >> >> >https://www.ietf.org/mailman/listinfo/dmm >> >> _______________________________________________ >> >> dmm mailing list >> >> dmm@ietf.org >> >> https://www.ietf.org/mailman/listinfo/dmm >> > >> > _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
