Thanks for the comments!
I don't know what the appropriate list is for this discussion but
I'll include ietf@xxxxxxxx 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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf