Hi,
My WGLC comments of the I-D as a chair, not the document co-author. I will
also put them one by one into the issue tracker.
- Jouni
1) Abstract
Management (DMM) in IPv6 deployments. The traditionally hierarchical
structure of cellular networks has led to deployment models which are
in practice centralized. Mobility management with logically
Why are we only concerned about cellular networks? Could this be generalized?
Next sentences then start talking about mobile networks. Use consistent
language.
2) Abstract
when needed, and so on. Distributed mobility management must be
secure and compatible with existing network deployments and end
hosts.
I would argue a DMM mechanisms, unless completely done on the network side,
cannot be compatible with existing end host.. It can be backward
compatible, which means there is a way to allow mixing DMM aware and
legacy hosts in a case the DMM solution would require even a configuration
change in the end host.
3) Warnings from automated IDnits (parsed):
== Unused Reference: 'I-D.ietf-netext-pd-pmip' is defined on line 580, but
no explicit reference was found in the text
== Unused Reference: 'RFC3963' is defined on line 648, but no explicit
reference was found in the text
== Unused Reference: 'RFC6224' is defined on line 663, but no explicit
reference was found in the text
== The document seems to lack the recommended RFC 2119 boilerplate, even if
it appears to use RFC 2119 keywords -- however, there's a paragraph with
a matching beginning. Boilerplate error?
(ED: maybe putting RFC2119 language into 'front' section using
<note title="Requirements"> ... </note>)
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
4) Section 1
a centralized mobility anchor providing global reachability and an
always-on experience to the user;
extensions to the base protocols to optimize handover performance
while users roam across wireless cells; and
extensions to enable the use of heterogeneous wireless interfaces
for multi-mode terminals (e.g. smartphones).
o Make this to a bulleted list.
5) Section 1
The presence of the centralized mobility anchor allows a mobile node
to remain reachable when it is not connected to its home domain. The
o "home domain" strikes out, which might not be obvious unless you are
familiar with mobile (cellular) lingo. Give a reference to a document
that a reader can read & get familiar with "home domains" and such.
6) Section 1
and scalability, which require costly network dimensioning and
o Ins't distribution dimensioning as well?
7) Section 1
Moreover, the availability of multi-mode devices and the possibility
of using several network interfaces simultaneously have motivated the
development of even more protocol extensions to add more capabilities
and to combine IP multicasting to the base protocol. In the end,
deployment is further complicated with the multitude of extensions.
o While "multi-mode" is correct, within IETF I would say "multiple
interface host" is better.
o I do not understand how "to combine IP multicasting to the base protocol"
relates to the paragraph.
o What is the "base protocol" here?
8) Section 1
mobile/fixed Internet Service Providers network requires taking into
o Service Providers network (ISP)
9) Section 1
strategies such as selective traffic offload (e.g. 3GPP work items
LIPA/SIPTO [TS.23829]) through alternative access networks (e.g.
o I would replace [TS.23829] with [TS.23.401] since both LIPA/SIPTO are
part of those document these days and the TR is just a technical
report.
8) Section 1
in a truly flat mobile architecture would anchor the traffic closer
to the point of attachment of the user, overcoming the suboptimal
route stretch of a centralized mobility scheme.
o This statement is more or less from the IP layer point of view. The
actual layer-2 aggregation can make the claim of "overcoming route
stretch" more challenging than it sounds.
9) Section 1
considerable periods of time [Paper-Locating.User] . Therefore it is
o misplaced '.'
10) Section 1
with application intelligence suggest that mobility can be provided
selectively, thus simplifying the context maintained in the different
nodes of the mobile network.
o "..mobility could be provided.."
o I would argue that having "simple IP" and "Mobile IP" selectively does
not simplify the context in the network, it actually makes the network
side more complex to implement. However, I would agree that it would
_reduce_ the amount of context maintained in the network.
11) Section 1
The DMM charter addresses two complementary aspects of mobility
management procedures: the distribution of mobility anchors towards a
more flat network and the dynamic activation/deactivation of mobility
protocol support as an enabler to distributed mobility management.
The former aims at positioning mobility anchors (HA, LMA) closer to
the user; ideally, mobility agents could be collocated with the
management support -- thus reducing the amount of state information
that must be maintained in various mobility agents of the mobile
network. The key idea is that dynamic mobility management relaxes
some of the constraints of previously-standardized mobility
management solutions and, by doing so, it can avoid the establishment
of non-optimal tunnels between two topologically distant anchors.
o expand DMM on the first use (excluding the abstract expansion here).
o "..anchors (HA, LMA).." -> "..anchors (e.g., HA, LMA).."
o The last sentence start discussion about tunnels. They are now mentioned
for the first time. Where the use of tunnels originated at this point?
It should be clarified at least with a reference.
o The last sentence states "non-optimal tunnels between two topologically
distant anchors". Where does that originates? Which protocols we are
implicitly referring to?
12) Section 2.1
(3GPP) UMTS networks, CDMA networks, and 3GPP Evolved Packet System
(EPS) networks employ centralized mobility management too. In
particular, Gateway GPRS Support Node (GGSN) and Serving GPRS Support
Node (SGSN) in the 3GPP UMTS hierarchical network, and the Packet
data network Gateway (P-GW) and Serving Gateway (S-GW) in the 3GPP
EPS network, respectively, act as anchors in a hierarchy.
o It is not really UMTS networks, .. rather say GPRS networks.
o Packet Data Network Gateway (P-GW)
o Since in 3GPP example SGSNs and SGWs are taken into anchoring
discussion, then in GPRS case the text should also discuss RNC, which
like SGW is the L2 anchor point for base stations.
o The text should be more clear when talking about anchoring that it
concerns IP layer and specifically user plane traffic. For example,
3GPP GPRS is rather hierarchical at L2 and mobility is handled at
every level of hierarchy rather independently.
o Figure 1 is incomplete in case of GPRS. RNC should be in the picture
as well.
o Figure 1 should change UMTS -> 3G GPRS if RNC is in picture, otherwise
GPRS is just fine.
13) 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 Data and control plane separation is not really something we have
practiced so far in IETF, at least not with the mobility protocols
developed within IETF. I would give a pointer to further reading to
architectures that have that separation and mention also IETF developed
mobility protocols do not have similar concept so far.
14) Section 4.1
REQ1: Distributed deployment
o This requirement must imho state why route optimization (MIPv6) or
localized routing (PMIPv6) as of today are not adequate/enough. The
requirement text itself is OK but the question above needs an answer.
15) Section 4.2
example, when, upon change of point of attachment to the
Internet, an application flow cannot cope with a change in the
o s/Internet/network
PS5: Wasting resources to provide mobility support to nodes that do
not need such support
o s/Wasting/Unnecessarily reserving
the tunnel, keep alive, etc.) is not turned off for peer-to-
o s/keep alive/keep alive signaling
keep alives, etc.) wastes network resources for no application
o s/keep alives/keep alive signaling
16) Section 4.5
o Earlier lists were indexed using (a), (b) etc.. here different style
(1), (2) is used. Choose one style.
17) Section 4.5
PS7: (Related problem) Complicated deployment with too many MIP
variants and extensions
Deployment is complicated with many variants and extensions of
MIP. When introducing new functions which may add to the
complexity, existing solutions are more vulnerable to break.
o I would argue this "related problem" could be removed. I see REQ5 as
a requirement for backward compatibility, not a MIP flavour complexity
issue.
18) Section 4.6
the mobility support provided by the DMM solution; signaling
message protection in terms of authentication, encryption,
etc.; data integrity and confidentiality; opt-in or opt-out
data confidentiality to signaling messages depending on
network environments or user requirements.
o Get rid of "etc". It does not really fit in a middle of a list.
o Some rewording needed. The use of semicolon is confusing.
19) Section 4.6
o The security discussed in "motivation" part seems to be mostly about
the first hop / on-link security. Why not saying that then instead
of listing a job lot of different threats..
their traffic. As signaling messages may travel over the
Internet, end-to-end security could be required.
o "could" is rather weak.. I would say MUST. Also, e2e security
between what? That needs to be stated as well.
20) Section 4.7
4.7. Flexible multicast distribution
REQ7: DMM should enable multicast solutions in flexible distribution
scenario. This flexibility enables different IP multicast
flows with respect to a mobile host to be managed (e.g.,
subscribed, received and/or transmitted) using multiple
endpoints.
o What is "flexible distribution scenario"? That is not mentioned earlier
or defined.
o I would reword the section title to something else like plain
"Multicast" or "Multicast considerations".
o "..using multiple endpoint." is supposed to mean what? I kind of
understand that as an aggregation or what does it intend to say?
21) Section 4.7
problems described in PS1 and PS6.
o For readability I would add references to relevant Sections as
well e.g. "..describer in Section 4.1 PS1 and in Section .."
22) Section 5
legitimate mobile host/router to access the DMM service; Second, end-
to-end security that protects signaling messages for the DMM service.
o e2e security between what? Between nodes that participate in the DMM
protocol as a whole or bilaterally between the end host and some xyz
functional entity?
23) Section 5
It is necessary to provide sufficient defense against possible
security attacks, or to adopt existing security mechanisms and
protocols to provide sufficient security protections. For instance,
EAP-based authentication can be used for access network security,
while IPsec can be used for end-to-end security.
o EAP-based security does not necessarily address on-link / first
hop threats. You gain access, and then can fool around.. does not
sound too promising, unless the security considerations can scope
the used link type better i.e. in p2p links this might be sufficient
but not in all.
On Apr 10, 2013, at 10:19 AM, Jouni Korhonen <[email protected]> wrote:
> Folks,
>
> This mail starts a two week WGLC #2 for draft-ietf-dmm-requirements-03.
> The issues, even editorials, must be recorded into the Issue Tracker,
> otherwise they are likely to be neglected. We require minimum three
> reviews (that are more than one liners). The more the better, though.
>
> The WGLC ends on Wednesday 24rd April.
>
> - Jouni & Julien
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
