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.
1.2) have the initial discussion how to proceed after IETF90.
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)
- 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
