Hi,
<as an individual contributor and not wearing any hats>
In Introduction it says:
"..
capacity, service providers need to implement new strategies such as
selective traffic offload (e.g. 3GPP work items LIPA/SIPTO [TS.23829])
through alternative access networks (e.g. WLAN) [Paper-
Mobile.Data.Offloading]. Moreover, the presence of content providers
closer to the mobile/fixed Internet Service Providers network
requires taking into account local Content Delivery Networks (CDNs)
while providing mobility services."
o I would also mention here that the gateway selection mechanism can take the
user proximity into account at least within EPC [29.303].. as we are already
referencing to 3GPP as an example.
o One another aspect I would mention here is the commercial deployment reality.
While we have means for selecting and using more optimally located gateways
those are not pursued due charging and billing reasons; here I mean that
while assigning a gateway anchor node from a visited network while the MN is
roaming is not done until recently (and still only limited to voice
services).
That kind of issues are not solved by a mobility protocol but a different
trust
and/or billing models between network operators.
In Section 3.2
"..
former case only the data plane is distributed. Fully distributed
mobility management implies that both the data plane and the control
plane are distributed. These different approaches are described in
.."
o Would it be OK to mention here that even if full distribution could be
achieved
for the mobility part of the system, some parts are still going to be
centralized
or just geographically replicated at best? Here I mean functions like
subscriber management, subscription databases and network access
authentication.
In Section 4.1:
"PS2: Divergence from other evolutionary trends in network
architecture
Centralized mobility management can become non-optimal with a
flat network architecture."
o What are the "other"? I would consider removing PS2 if we cannot name
those.
"PS3: Low scalability of centralized route and mobility context
maintenance"
o Isn't e.g. the SDN evolution just doing to the opposite? Highly
centralized management point for traffic steering? I would reconsider
PS3 unless we have more evidence that this is really an issue. Or
then we need to point out something that makes it more context
specific for DMM or mobility.
In Section 4.2:
"REQ2: Transparency to Upper Layers when needed
DMM solutions MUST provide transparent mobility support above
the IP layer when needed. Such transparency is needed, for.."
o Doesn't the "when needed" make the earlier MUST conditional? At least
I understand it so. If that is the case we probably could just say:
"DMM solutions SHOULD provide transparent mobility support above the
IP layer." ?
In Section 4.4:
o I would just remove the sentence:
"Motivation: Using IETF protocols is easier to deploy and to
update." IMHO it brings no additional clarity what has already been
said.
In Section 4.5:
o I would reword "Compatibility" to "Backwards and forward compatibility".
A general editorial note. I would consider rewording all these "PSx" and
"O-PSx" problem statement and just include them into the generic requirement
text.
- Jouni
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
