Hi Satoru, Thank you for your comments on my draft, we will consider them in revising it next time.
Let me say that I lived in Japan more than 7 years and I can probably state that I am a bit familiar with the culture. So my translation of your views is that these things happen in IETF and we should live with them. Yes, I agree that it happens but in IETF there is also freedom of expression. We can and we should point the discrepancies and there is nothing wrong to say that this (whatever it is) is wrong, people will respect you more if you do that. Regards, Behcet On Tue, Oct 7, 2014 at 2:31 AM, Satoru Matsushima <satoru.matsush...@gmail.com> wrote: > Hi Behcet, > > > On Tue, Oct 7, 2014 at 5:33 AM, Behcet Sarikaya <sarikaya2...@gmail.com> > wrote: >> >> >> I agree that BGP part in vEPC needs rethinking. That's why in DMM WiFi >> we proposed new approaches like SDN. >> > > Please don't get me wrong. My position hasn't been changed. BGP is used to > forwarding path management signaling. > > In your draft, XMPP is the protocol that has same role of BGP. Good idea, it > is a pub-sub system as same as BGP. You may need to define data model for > dmm in i2rs, yang? I don't know which protocol will be adopted as i2rs > either xmpp, netconf, or forces. > > I suppose that you might want to adopt end-system VPN > (https://tools.ietf.org/html/draft-ietf-l3vpn-end-system-03) as its xml data > modeling. (actually it is BGP. :-) And, as you may know that there is a > draft which mentions about use case of BGP in i2rs. > (http://tools.ietf.org/html/draft-keyupate-i2rs-bgp-usecases) > >> >> Having said that I don't think that the charter text on forwarding >> path and signaling is talking about the same thing. >> > > Interesting. What do you expect for the charter text? > Why not you ask Marco, Anthony and Alper to explain their thought? > > >> >> >> In DMM fir WiFi we also adopted the anycast discovery, what is wrong with >> that? > > > How do you find the anycast address itself? > > >> >> >> Yes I agree, maybe other techniques like AAA can be worked out. Why >> not do it as extensions? >> > > I suppose that it would be a part of enhanced anchoring work, isn't it? > > >> >> 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? >> > > Quite not. I meant disclosing mobility information to network node that > likes such as BGP speaker. > > >> >> So you are saying that these three items gave you some good ideas to >> think about on how you can improve your solution, vEPC. >> > > In my view, the charter items work well to achieve vEPC architecture model, > yes. > More precisely, as the result of discussions which I had so far with many > dmm people, I have noticed some parts which the draft needs more work to > achieve the architecture model. > >> >> 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. > > > I know. So I am trying to express my thought, and then we can recognize > differences each other, and we can discuss. It's normal process in the ietf > I think. > >> >> >> 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. > > > I guess wg management, who are responsible to establish dmm standard, expect > standardizing dmm solution would be very hard work because they find many > variants for it. In that situation, it would be reasonable that they appoint > some persons to lead the work. I really appreciate those persons who > volunteer to take that role to out consolidated solution. > > Cheers, > --satoru _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
