I agree that the discussions were kept at a high level. But as I noted then and now, I disagree with still keeping the discussions at high level… It's still hovering at 10k feet... If we want to make real progress, we need to start bringing the discussion to low level, closer to solutions.
The requirements and gap analysis documents are not strong enough to steer the discussion in any way. Framework documents and what Sri is showing are still very high level. That's why I approached this from the other angle: Categorization of the solutions. The approach I'm proposing is: 1. Discuss the categorization. Whether we agree to necessity of each category. Each category would produce WG I-D(s). (Here we can use all of our requirements, gap analysis, framework thoughts to make sure nothing is missing). 2. Once we agree on the categories, then we discuss how to handle the candidate I-Ds in each category. In a given category, there are various relationships among I-Ds. Some are complementary, some are competing. Some have different applicability. We need to sort that out. So, this is a divide-and-conquer approach, which also lays out how things would come together. I think this is more progressive than still talking about high-level principles (which normally would have finished with the charter + requirements + gap analysis, but we seem to be stuck in a rip current). Alper On Jul 18, 2014, at 9:07 AM, <karag...@cs.utwente.nl> <karag...@cs.utwente.nl> wrote: > Hi Sri, Hi all, > > Agree with Sri that the discussions were kept on a high level. > Please note that the following draft tried to provide the work items that > were discussed > > http://www.ietf.org/id/draft-liebsch-dmm-framework-analysis-03.txt > > I thought that we had agreed on these work items, but apparently we need to > spend more time on this! > > Best regards, > Georgios > > Van: dmm [dmm-boun...@ietf.org] namens Sri Gundavelli (sgundave) > [sgund...@cisco.com] > Verzonden: donderdag 17 juli 2014 22:23 > Aan: Alper Yegin > CC: dmm@ietf.org > Onderwerp: Re: [DMM] demand for DMM traffic steering > > Alper, > > What we broadly agreed in Nov/Mar IETF's (based on offline discussion) to go > with a design group approach. Approach of Individual I-D's, comparing them, > selecting the best will go no where, IMO. There are like dozen proposal on > the table. > > With that goal in mind we have had several conf calls (with smaller group of > folks) in Jan time frame. What we discussed there and in f2f meetings was > summarized in IETF 89 WG slides. Off course, that does not give it a WG > status, but the goal is to come to some agreement on the approach and then > document the approach. Fair comment on lack of details and that its at a > high-level. The discussion is purposely kept at a high-level and we need to > work out the details. We should have more formal design meetings and if we > converge, we should then write a I-D(s). > > Sri > > > > > > > > From: Alper Yegin <alper.ye...@yegin.org> > Date: Thursday, July 17, 2014 1:06 PM > To: Sri Gundavelli <sgund...@cisco.com> > Cc: Marco Liebsch <marco.lieb...@neclab.eu>, "dmm@ietf.org" <dmm@ietf.org> > Subject: Re: [DMM] demand for DMM traffic steering > > Sri, > > You SDNize a solution, then co-locate two entities, and voila the mobility > protocol vanishes, and all that's left is OpenFlow. > That's why there's no mobility protocol in that picture. > > It'd really be good if we see your solution documented, it's not easy to > fully grasp it in a Q&A style. > > (I'm saying this to save us energy. If we read your I-D, we can all see how > it meets the requirements. Otherwise, we are going to have to ask about them > and have lengthy discussions to understand things). > > Alper > > > > > On Jul 17, 2014, at 10:51 PM, Sri Gundavelli (sgundave) wrote: > >> Alper, >> >> There is no mobility protocol here in this below deployment modek. >> Mobility protocol based on GTP/PMIP comes into the second case when we >> introduce the access and the home network based separation. In a flat model, >> its just a SDN interface between the CP and DP functions. But, the way we >> perform gateway selection, allocate application specific gateways, migrate a >> data plane session, allow UE the gateway indicators ..it meets every single >> DMM requirement that we have discussed in this group and with the >> side-affect of realizing CP/DP separation. >> >> >> >> <CA18E534-121E-4582-90A4-14AA394AEDEE.png> >> >> >> Sri >> >> >> From: Alper Yegin <alper.ye...@yegin.org> >> Date: Thursday, July 17, 2014 12:39 PM >> To: Sri Gundavelli <sgund...@cisco.com> >> Cc: Marco Liebsch <marco.lieb...@neclab.eu>, "dmm@ietf.org" <dmm@ietf.org> >> Subject: Re: [DMM] demand for DMM traffic steering >> >> Sri, >> >> PMIP is a solution. >> You can apply SDN approach to it by splitting CP and DP. >> >> For example, a draft like draft-bernardos-dmm-pmip-03 talks about "access >> network anchoring". >> And you can apply SDN to it (as you already mentioned jun your examples on >> this thread), or not. >> >> >> Alper >> >> >> >> >> >> On Jul 17, 2014, at 9:21 PM, Sri Gundavelli (sgundave) wrote: >> >>> I do not know your definition of approach vs solution, but one can argue >>> DMM itself is about a deployment model and an approach. I always insisted >>> its less of a protocol work and more about a tying many aspects. So, what >>> we have been discussing is a solution approach which has the essential >>> properties of CP/DP separation, aspect of optimized/stateless data plane, >>> application specific gateway allocations .. etc and that at the end is an >>> approach for realizing DMM. >>> >>> >>> Sri >>> >>> >>> >>> >>> >>> >>> On 7/17/14 10:59 AM, "Alper Yegin" <alper.ye...@yegin.org> wrote: >>> >>>> Intense readingŠ :-) Lot of abstractions, which I can only follow by >>>> relating to specific solutions. >>>> >>>> In my understanding, what Sri is describing is about "how to apply UP/CP >>>> separation to various DMM solutions". >>>> In the examples I see a number of DMM solutions defined with UP/CP >>>> separation using Sri's terminology (e.g., per-flow mobility, access >>>> network anchoring, host-specific route based solutions, etc). >>>> >>>> So, it's not a solution by itself, but it's an approach that can be >>>> applied to various solution techniques to SDNize them. >>>> And that indeed has value. >>>> >>>> Alper >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >> > > _______________________________________________ > 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
