Thanks for the comments!
I don't know what the appropriate list is for this discussion but
I'll include ietf(_at_)ietf(_dot_)org in this response then I suggest we
move to int-area only to avoid duplicates.
Overall:
The draft starts out drawing a reasonable background for the
IETF mobility work in section 1, and then goes on to discuss
problems with the problem statement in section 2. To me the
representation of the problem statement is biased, and presents
the author's subjective view on the problem statement. This
perception of the problem statement seems to have grown out
of the more explicit concerns raised later in the document.
=> Interesting. I actually used the problem statement draft's
description
of the problems, almost word for word. Maybe the analysis is seen as
biased
but the best way to respond to that is to state where I went wrong,
which
is why I published the draft of course (to get feedback).
The NETLMM approach is described on a high level in the current
charter. Simply put, NETLMM expects to place a mobility
anchor point
in the visited network, which acts like a home agent.
The mobile node
will be configured with an address on the anchor
point's link and
keep it for the time it is located in the NETLMM
domain. The anchor
point binds the mobile node's address to its current
default router
(or Access Router, AR). Hence, whenever the mobile node
moves, the
new AR will bind its address to the one allocated to
the mobile node.
Tunneling is done between the anchor point and the AR.
Therefore,
the AR's address can be seen as a Care-of address for the mobile
node. On a more detailed level, several minor changes
can be made;
however, the overview above gives the general idea.
This description is in part incorrect:
1. The mobility anchor point *does not* act like a home agent.
=> Well in the sense that it binds one relatively stable address to
another.
Of course it's not exactly an HA.
It is important to understand that the basic functionality of a
NetLMM domain is to provide dynamic intra-domain routing, and if
you disregard scaling problems, this functionality could be
provided in part by use of e.g. OSPF. That the
proposed internal
architecture happens to have a local mobility anchor node (or
nodes) does not mean that these are like a home agent. They are
not.
=> Not really an important issue, but ok you don't have to see it like
an HA.
2. The introduction of the term 'Care-of address' is misleading.
A node attaching to a NetLMM domain gets an address by usual
means, just as when attaching to any other internet subnet.
The exact mechanism by which the route updates are done is
immaterial to this, and most importantly, there is no other
address involved which is associated with the node, that
would warrants the term 'Care-of address'. The node's IP
address is simply the node's IP address.
=> Again, it's a simple analogy to the anchoring mechanisms in MIP.
I'd rather not delve into a terminology debate at this point, I think
we both understand the overall picture of the NETLMM approach described
in
the charter.
3.1. Applicability to different link layers
Good discussion, apart from the sligth bias towards NetLMM-
bashing.
=> I'm not bashing anything, I don't think that interpreting criticism
as "bashing"
is helpful. This is an emotional description that has nothing to do with
the
technical points made.
This part is incorrect. There is no inherent reason
why a network-
based mobility management scheme may not handle this in a
deterministic manner, based on policy or heuristics. Examples:
move to the a) link with highest basic bandwith; or b) the
link with highest user policy ranking; or c) link with lowest
cost; or indeed the link determined by any evaluation function
using these and other criteria.
=> I think the important point here is who is evaluating this? I think
both sides (the MN and a networking entity) should evaluate and make
their ultimate decisions based on their preferences. Making this a
network-only
decision is not workable. The network can't assume it knows everything
about the types of connections that the device has or will have in the
near future. It can't even tell if a device's interface is functioning
properly!
As for the reliable manner,
reliability is related to quality and determinism, and if the
link quality is made part in the evaluation, this may also be
covered. WHAT IS NOT given is that the resulting choice is
*optimal* from a user viewpoint. But consider that given the
posited availability of both network-based and
host-based mobility
support, the mobile may very well have the option of
establishing
a different ID for the different access types, and use host
mobility to switch between these...
=> So you're jumping over many assumptions here. You're assuming that
both host and network mobility can coexist. On the surface this sounds
conciliatory and ideal, but I'm afraid
it's not practical. Having NETLMM *excludes* the host's ability to
communicate with a local anchor. Hence, when you say host mobility is
possible you must mean a host-HA relationship. This isn't efficient
enough
for the types of handovers, flow movement or multihoming decisions that
a host might make. This also assumes that the overhead of having the
remote
HA is acceptable. It's not acceptable in many cases.
But we do! There's nothin inherent or planned in NetLMM to
prohibit this! On the contrary, it is quite likely that this
will be the most common way of deploying NetLMM in combination
with host-based mobility.
=> I really think you should reconsider this assumption. You seem
to assume that an inter-access technology handover is host-based
while not limiting the definition of a mobility domain to a single
access technology. You can't have it both ways :)
Section 3.2., para. 5:
(b) Multi-homed end nodes will at some point be able to
use different
links for different applications depending on link
quality/capabilities. It is easy to see that the level
of complexity
increases significantly when taking into account flow
movement. The
proliferation of applications and possibility that the
end node is
enabled with interfaces unknown to any given
network-based mobility
scheme makes this a difficult problem. How would a network based
mobility management system know which flows to move to
which link?
It wouldn't. And, more to the point, nobody has claimed that
it would or should!
=> Same answer. Check the definition of local mobility. Not
my definition!
(c) Since the coverage area of different technologies
is likely to
overlap, the decision to use one technology or the
other becomes a
policy decision. The end nodes will have to deal with
making such
policy decisions between different networks and they
should be able
to make the same decisions between different technologies. The
network operator should define metrics (like cost,
loading etc) but
it should let the end host decide what to do. This is not a
philosophical point; there are concrete reasons why the
host needs to
make this policy decision. For instance, the host is most
knowledgeable about the applications it runs and what radio
technologies are best suited to those applications.
Agreed. And nobody has claimed otherwise!!
=> Same answer ;)
End to end signaling is important and necessary in
order to maintain
the end to end design philosophy of the Internet. When
it comes to
localized mobility management, the end to end concept
remains crucial
to the robustness of the mobility management mechanism.
Handovers are
uncertain by nature and in some cases the new
attachment point may
change during the handover process. This is due to the volatile
nature of the radio link at cell borders, which is
typically the case
in most cellular technologies. It is also known that
mobile nodes can
experience ping-pong movement, or cellular thrashing, during
handovers; i.e. the mobile node may quickly move back and forth
between two different access points for a short period
of time. A
network-based mobility management protocol can cause the mobile
node's traffic to be routed to the wrong AR, i.e. the
AR that the
mobile node was expected to move to, but did not. This
can result in
packet losses. In contrast, if the IP mobility
signaling is initiated
from the mobile node, it would be able to discover that
the next AR
has changed and inform the network of its new choice.
When the action
is taken by the mobile node it can be done in a quicker
manner for
predictive or reactive handovers.
I don't see that this follows. What would make it quicker,
when it has less predictive ability than the network, and
longer signalling paths?
=> It's quicker because of most link layers the mobile knows
first what it's best candidate will be. The mobile
is in the best position to measure signals from other basestations
to itself. So of course it will know first.
One of the unwritten motivations of NETLMM is that some
operators and
vendors "believe" that the network must control the
handover. Lets
explore this belief a bit more. Specifically, what does network
control mean? Why is it needed? And how does a
network-based mobility
management mechanism allow for more control?
Since this is an allegation of unwritten motivation, it is of
course hard to prove otherwise.
=> It was a spoken motivation that I heard for many many people
over the last 5 years. So it's not something I made up.
I believe this is more in the
mind of the author than in the minds of those who work on the
NetLMM design.
=> Not at all. I think you're doing the mind reading now.
But there is a MUCH deeper danger here than mis-representation
of motivations; and that is to perpetuate the either-or
dichotomy
between host-based and network-based mobility support. Looking
closer at the respective advantages of network-based
and host-based
mobility, we find that in their pure state, both have
clear draw-
backs, which best can be complemented by the other. So the
title of the current section paints a picture of strife, where
the optimal solution is cooperation.
=> All I'm asking for is a clear and coherent problem statement that
justifies what you claim above. The claims in the current statement
are frankly well below the average engineering common sense. I really
hope someone can show me how these claims make any sense or are backed
by
any data. Simply saying that "each approach has its problems" is not
good
enough or technical enough for me to agree.
The above situation is more difficult to support when a
network-based
mobility management mechanism is adopted. In particular, the
following problem arises. An anchor point may be
required to setup a
security association with any access router in the
network at any
time. A network administrator is suddenly forced to consider the
impacts on memory capacity and the speed of the
security association
establishment at the critical handover time. This
situation does not
arise when the signaling is done end-to-end because in
this case only
one security association is needed, regardless of the
mobile node's
location. Furthermore, the security association does
not need to be
established during the critical handover time.
And neither does it in a NetLMM case -- the most natural to
me would be to pre-configure these, not to try to do it ad-hoc.
=> I don't think this is feasible in a practical deployment. I've worked
on and seen these networks deployed. Imagine a situation where you have
a 100 - 200 local agents and 10 - 20 K basestations, each containing an
AR. Now
try to manually configure SAs between all ARs and all anchors and
maintain
those SAs, i.e. roll the keys ....etc I don't think you'll find many
people wanting
to manage things this way.
The endorsement of more than one alternative for the
same problem
needs to be strongly justified. Unfortunately this was
not the case
for the NETLMM work in IETF. Both NETLMM BoFs clearly
stated that the
WG will exclude the mobile node from the IP mobility management
signaling, which is not a typical requirement related
to a problem,
but one designed around a solution. This premise was
challenged in
both BoFs. Despite lack of clear consensus, the IESG
decided to form
the WG. The problem here is two-fold: How do we decide
on new WGs?
And what is the impact of solving the same problem in
two different
standards? Both questions are not specific to the
NETLMM WG, however,
this WG illustrates the need for a uniform and
predictable process.
This argument seems to be based on the idea that there exists
an alternative to NetLMM within the IETF. This I don't see,
maybe because I see host-based and network-based mobility
support as complementary technologies, and mutually beneficial.
=> Right, I think we disagree on that. I don't think they're
complementary.
Hesham
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf