Hi Satoru,
On Sun, Oct 5, 2014 at 11:19 PM, Satoru Matsushima <satoru.matsush...@gmail.com> wrote: > Behcet, and all, > > Maybe I can't attend next webex meeting tomorrow. So let me try to make > clear what I am thinking. Please correct me if I'm wrong to understand the > notion of the next DMM charter. > > 1. Forwarding path and signaling > In fact, my proposal, stateless-uplan for vEPC (aka vEPC), to dmm is that > wherever mobility management located, existing user-plane control protocol > works fine for forwarding path management with some already proposed > extensions. The important thing is, BGP itself is not mobility management > protocol in the vEPC. The reason for this is because it enables stable > operation, maintained continuously for many advanced use cases, and most > scalable since it supports global Internet routing. But I think that BGP > does not suitable for mobility management. I understand that other people > may have their own choice, of course. I agree that BGP part in vEPC needs rethinking. That's why in DMM WiFi we proposed new approaches like SDN. Having said that I don't think that the charter text on forwarding path and signaling is talking about the same thing. > > 2. Enhanced mobility anchoring > As you may know the vEPC has anycast discovery for EPC-E. It is not a > discovery mechanism actually. As the anycast address is assumed to be > informed from control-plane, which address should be chosen is a matter of > anchor selection policy or algorithm in the mobility management. So I know > that more intelligent anchor selection in the mobility management should be > considered to optimize the path. Anycast would be an operational choice > whether the informed address is assigned to single or multiple routers. In DMM fir WiFi we also adopted the anycast discovery, what is wrong with that? Yes I agree, maybe other techniques like AAA can be worked out. Why not do it as extensions? > > 3. Mobility state exposure > Some people asked me to what entity discloses mobility info mapped into > routes. Yes, vEPC need that entity to achieve the architecture model. Now > that the draft has stated that it is a further study item. We have to study > common way to disclose mobility information regardless the type of mobility > management, which are MIP/PMIP or GTP-C whatever. It may need mobility state > exposure for not only mobile node, but also network node that the charter > has already mentioned. Really? My thinking was that vEPC does not need any involvement from MN because the prefix assigned to MN does not change. As I mentioned in my more recent mail, I think this item is based on 2102 solution proposals in which MN had to deal with many prefixes. Can you clarify which network nodes need exposure to MN mobility state? The ones on the path already know MN prefix, right? > > I support these work items to moving forward. I've found some solutions in > the forwarding path and signaling. But AFAIK, couldn't see the solutions to > apply other two items, but it might be already there. I would like to see > solutions which are clarified into three work items and fill them. I would > be happy to contribute to make things progress. > So you are saying that these three items gave you some good ideas to think about on how you can improve your solution, vEPC. You are indicating that there is a major solution proposal, i.e. vEPC by you, but that can be improved here and there. You are missing the point that such a view point is not yet agreed by the group. Without such an agreement on the base, isn't it quite concerning what the WT's or DT's will do? My understanding is that the formation of WT's or DT's is another way of saying that we don't like all those solutions out there, we will design our own solutions to the above 3. Regards, Behcet _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
