Hi Jouni, On Jul 20, 2014, at 2:12 AM, Jouni Korhonen wrote:
> > Ain't that quite visible from the agenda: > > 1.1) have a look at the re-chartering text that it is roughly > acceptable for everyone in the room. We can even do some > minor online editing if there is something that requires > immediate attention. The text has not been changed since > 14th Jun. > Hopefully, folks who have any comments on the charter text bring that up on the ML in advance of the meeting, so that we can resolve them without using meeting cycles. > 1.2) have the initial discussion how to proceed after IETF90. > I don't see that on the agenda. And, can we have the chairs share their thoughts on the plan over the email, so that we can have rounds of discussion on it before the Thu&Fri meetings. Ideally, those meetings should be where we agree to the plan, not where we hear about them and start thinking&discussing... > 2) lenghty powerpoint marathon.. of many I-Ds that we have > already heard a presentation before, so concentrate on > possible updates and how the I-D fits under the current > re-charter milestones. > > 3) on Friday conclude the next steps and the working procedues > for carrying out the stuff. Decision making point here. (we > probably need to add some minutes for the concluding > discussions, so the longer presentations slots are subject > to some adjustment) > Thanks. Alper > - Jouni > > > > 7/19/2014 11:23 AM, Alper Yegin kirjoitti: >> >> Btw, in addition to nailing down the grand plan, it'd also be good if >> Jouni&Dapeng can share the objective of this week's meeting. >> What exactly we want to achieve, how we want to do it, etc. Let's >> announce the objectives, so that we can all work towards that. >> >> Alper >> >> >> >> On Jul 19, 2014, at 11:17 AM, Alper Yegin wrote: >> >>> >>> 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, <[email protected] >>> <mailto:[email protected]>> <[email protected] >>> <mailto:[email protected]>> 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 [[email protected] <mailto:[email protected]>] namens >>>> Sri Gundavelli (sgundave) [[email protected] >>>> <mailto:[email protected]>] >>>> *Verzonden:*donderdag 17 juli 2014 22:23 >>>> *Aan:*Alper Yegin >>>> *CC:*[email protected] <mailto:[email protected]> >>>> *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 <[email protected] <mailto:[email protected]>> >>>> Date:Thursday, July 17, 2014 1:06 PM >>>> To:Sri Gundavelli <[email protected] <mailto:[email protected]>> >>>> Cc:Marco Liebsch <[email protected] >>>> <mailto:[email protected]>>, "[email protected] >>>> <mailto:[email protected]>" <[email protected] <mailto:[email protected]>> >>>> 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 <[email protected] <mailto:[email protected]>> >>>>> Date:Thursday, July 17, 2014 12:39 PM >>>>> To:Sri Gundavelli <[email protected] <mailto:[email protected]>> >>>>> Cc:Marco Liebsch <[email protected] >>>>> <mailto:[email protected]>>, "[email protected] >>>>> <mailto:[email protected]>" <[email protected] <mailto:[email protected]>> >>>>> 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" <[email protected] >>>>>> <mailto:[email protected]>> 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 >>>> [email protected] <mailto:[email protected]> >>>> https://www.ietf.org/mailman/listinfo/dmm >>> >> >> >> >> _______________________________________________ >> dmm mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dmm >> > > _______________________________________________ > dmm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
