As said in the previous thread, I'm writing up some of the
comments I
had for the 3 groundwork documents.
substantial
-----------
1) scaling requirements/problem space is not described
you do not define anywhere (here or in the requirements)
what is the
scaling factor or the scenarios you're looking at. Both
documents
mention the WLAN switch markets, but that makes me think of
O(1000) to
up to O(50,000) nodes. However, now I have heard that some
folks are
fantasizing about O(10,000,000) nodes per subnet as well.
These
assumptions are very important and need to be made in the
problem
statement.
My own belief is that we should not stretch a single IP
subnet that
far. If you go down that route, even O(10M) isn't going to
be enough:
a service provider operating globally will want to provide
seamless
mobility even when you move between cities (for example) --
because it
if wouldn't need to do that, it wouldn't need this kind of
scaling as
it could use some other mobility techniques to ensure smooth
transitions between IP subnets. Hence, the whole service
provider
would need to be in the same IP subnet. And the next
logical step
would obviously be extending this to inter-domain, like
LxVPNs have
been extended to inter-domain.
This has to stop somewhere. There's no escaping the fact
that if you
want seamless mobility beyond a somehow defined topological
area, some
other mechanisms than extending the IP subnet will need to
be used,
and that likely requires host modifications.
2) the language is wireless-specific
In this doc, and other docs are even worse, it seems to be
the assumption
that the network is wireless. But that's not necessarily
the case; this
kind of localized IP mobility is applicable to wired
networks as well. I'm
not sure how this should be addressed: generalization
throughout the
document(s), or just stating in Introduction that wireless
terminology is
used but that's not meant to be restrictive.
3) Scenarios doesn't mention the typical large WLAN
environment
I was surprised to see that the most logical reason (in my
mind) wasn't
included in scenarios: even if you'd have Ethernet
connectivity between
WLAN access-points, at a certain point the network just
grows so large that
keeping it as a single broadcast domain is NOT a good idea.
In that
scenario you'll want to chunk it up, but hopefully retain
IP mobility as
well. Section 3.1 is written in such a manner that this
scenario is not
highlighted, but rather the focus is on the question about
whether a single
VLAN can be made to cover the campus due to wired link
restrictions.
4) Solution 3 (IGP host routes) problems are not accurate
As pointed out in the previous thread, in Section 4, the
Solution 3
problems are not real problems. A routing table is required
at AR but
it need to include much more than information about the
current MNs
connected to the AR. IGP flooding is not an issue with
proper area
design.
However, solution 3 still would require additional
components, at least a
function to redistribute "CN joins the link, it has IP
address X"
information to the MAP/LMA using the routing protocol. But
this function
is required in any case.
Similar arguments apply to section 4.0, last point 3) in
advantages to
creating a new solution.
5) The problem statement and IPv4
The charter seems to rule IPv4 out of scope, even though the
requirements
document prefers a solution which would work with v4 as
well. The PS doc
doesn't seem to say anything explicit about v6 or v4
support -- maybe it
should.
semi-editorial
--------------
Problem Statement for IP Local
Mobility
==> this is an interesting scoping issue. Do you want
the document to be a
PS in _general_ about IP local mobility, or PS for
_non-host-based_ IP local
mobility? As it's currently written, I think it's the
latter, so unless you
want to significantly change the tone of the text, I'd
suggest rephrasing
the title.
Access Network (revised)
An Access Network consists of following three
components: wireless or
other access points, access routers, access
network gateways which form
the boundary to other networks and may shield
other networks from the
specialized routing protocols (if any) run in the
Access Network; and
(optionally) other internal access network
routers which may also be
needed in some cases to achieve a specialized
routing protocol.
==> this revised statement seems like a complete rewrite
of RFC 3753, and
mostly to the worse. Why do you need to redefine it? What
does 'shield'
mean?
Mobility routing anchor points within the backbone network
maintain a collection of routes for individual mobile
nodes. The routes
point to the access routers on which mobile nodes
currently are located.
Packets for the mobile node are routed to and from the
mobile node through
the mobility anchor point. When a mobile node moves
from one access router
to another, the access routers send a route update to
the mobility anchor
point.
==> this solution seems to be somewhat assumptive of the
solution. Is it
required?
5.0 Security Considerations
Localized mobility management has certain security
considerations, one of
which - need for access network to mobile node
security - was touched on in
this document. Existing localized mobility management
solutions increase the
need for mobile node to access network signaling and
provisioning of the
mobile node with credentials without increasing the
security beyond what is
available if no localized mobility management solution
is used.
==> I'm not sure that "without
increasing..security" is a good way to phrase
this. IMHO, if sufficient credentials aren't used in the
access network (of
a large size), you just can't deploy NETLMM there as the
threats could get
out of hand. So, I believe NETLMM needs to define the
minimum level of
security where it can be deployed. The text above may be
read to imply that
if the network doesn't provide enough credentials for safe
use... too bad,
NETLMM can't require more of them because then it would be
in conflict with
the problem statement.
editorial
---------
==> the are 6 authors, which is more than the maximum 5.
==> the page width exceeds 72 chars; the are also other
ID-nits such
as missing IANA considerations section (btw, ID-nits tool
doesn't
seem to understand the '1.0 Introduction' etc. notation,
not sure if
it should.)
[5] Kivinen, T., and Tschopfening, H., "Design
of the MOBIKE
Protocol",
Internet Draft, work in progress.
==> maybe refer to the protocol instead, unless there was
a good reason to
refer to the design document?
--
Pekka Savola "You each name yourselves
king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash
of Kings
_______________________________________________
netlmm mailing list
netlmm ngnet.it
https://vesuvio.ipv6.cselt.it/mailman/listinfo/netlmm
|