Folks,
Let's change gears.
We'd like to propose draft-yegin-dmm-ondemand-mobility-02 for WG adoption.
This draft falls under the following deliverable:
Exposing mobility state to mobile nodes and network nodes:
define solutions that allow, for example, mobile nodes to select
I am only about functions, not picky about terms. But with certain terms there
is some expectation of
the function behind. We need to be clear about the roles of both, access and
home DPA for
mobility management and assess their role in driving the different DMM
scenarios.
marco
From: Sri
Since you are collecting the list, there is one PMIPv6 extension that
deals with access network short lived addresses (where MAG would be the
access DPA): draft-korhonen-dmm-local-prefix-01
I think it belongs to Anchoring IP address within the access network
using IP-in-IP tunneling in your
Folks,
The agenda has been updated.. no more requests allowed (running out of
time). The allocated times for slots are still subject to change, mainly
to take minutes away from those who have plenty to those who have less..
http://www.ietf.org/proceedings/90/agenda/agenda-90-dmm
The agenda
Hi Jouni,
We cannot have an official approval of the documents,
but what we can do is:
- check the WG to see if they are willing to accept a document, based on the
assumption that the new charter would be approved
- if the WG is OK, then when the charter is approved, we can double check on
the
16:05 - 16:15 New proposal, Alper (10 minutes)
The new proposal here is:
https://datatracker.ietf.org/doc/draft-yegin-ip-mobility-orchestrator/
(Jouni, I'd appreciate if you can fix the online agenda as well).
Alper
On Jul 17, 2014, at 7:36 PM, Jouni Korhonen wrote:
Folks,
The
Lets get the charter approved first.
- jouni
7/17/2014 7:42 PM, Alper Yegin kirjoitti:
Hi Jouni,
We cannot have an official approval of the documents,
but what we can do is:
- check the WG to see if they are willing to accept a document, based on the
assumption that the new charter would be
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
I'm in favor of this approach. This was my suggestion as well in the past
(when we presented prefix coloring spec) to move forward some documents.
But, those should be documents which are considered common across multiple
solution approaches. The issue seems to be charter approval.
Sri
On
Understood. If there is agreement on the functional roles, the terms can be
worked out.
Sri
From: Marco Liebsch marco.lieb...@neclab.eumailto:marco.lieb...@neclab.eu
Date: Thursday, July 17, 2014 8:30 AM
To: Sri Gundavelli sgund...@cisco.commailto:sgund...@cisco.com, Hirschman,
Brent B [CTO]
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
Hi Pierrick,
Using the term Anchor in Access DPA is not a minor issue IMHO, because it
implicitly assimilates anchoring and traffic redirection function.
I'm fine with the removal of the Anchor term from the Access DPA. Access
Gateway, Data Plane Redirection function ..(except Locator or
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
On Jul 17, 2014, at 9:11 PM, Sri Gundavelli (sgundave) wrote:
I'm in favor of this approach. This was my suggestion as well in the past
(when we presented prefix coloring spec) to move forward some documents.
But, those should be documents which are considered common across multiple
solution
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 QA style.
Hi Alper,
draft-sarikaya-dmm-for-wifi-
00.txt does not use anchoring, I don't know how many times I should tell?
It simply extends vEPC, so it should be classified wherever vEPC is
classified, and I don't care where.
Regards,
Behcet
On Thu, Jul 17, 2014 at 2:45 PM, Alper Yegin
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
The list is still missing draft-korhonen-dmm-local-prefix-01.
- Jouni
7/17/2014 10:45 PM, Alper Yegin kirjoitti:
On Jul 17, 2014, at 9:11 PM, Sri Gundavelli (sgundave) wrote:
I'm in favor of this approach. This was my suggestion as well in the past
(when we presented prefix coloring spec)
18 matches
Mail list logo
