I think we need a draft from Pete on this so we can all understand what is being proposed.
Regards, Behcet On Mon, Nov 11, 2013 at 9:29 AM, Sri Gundavelli (sgundave) < sgund...@cisco.com> wrote: > 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. 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
