> >> 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.
>
> No. It does *not* bind one address to another. It updates the
> routing rules for an IP address - there's no two addresses here to
> bind together.
=> See my answer below.
>
> > Of course it's not exactly an HA.
>
> Right. Except it seems you're still sticking to the idea that it's
> 'kind of' an HA. But again: it's not.
>
> > 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.
>
> Sorry, Hesham. From the whole content of the draft, the
> basic problem
> I see is that it seems you don't understand the overall picture. So
> please don't try to dodge this as you do above - I think you need to
> take a second look at this, and re-evaluate the 'simple
> analogy to the
> anchoring mechanisms in MIP'.
=> Like I said, I didn't think it's the real issue in the draft but
since you persist, and since I don't like to be a "dodger" I took a
second look at the charter since I'm not aware of any WG doc.
Here's an excerpt:
The network-based localized mobility management protocol will conform
to the following framework. Mobility 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.
So, it's an anchor point that "forwards" the MN's traffic to the AR.
If the MN moves to another AR then a "route update" is sent. Since this
anchor sends the MN's traffic to an AR that I presume is potentially
several
hops away, is there some kind of encapsulation going on here? IP in IP
perhaps?
Is there some binding between the outer address and the inner address?
If there isn't then how does this "forwarding" happen?
> > 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.
>
> Heh! As I've seen it in action, you'll have hard time sweet-talking
> me into closing my eyes to this. I've seen the benefits of running
> both in parallel. If you want to close your eyes to the
> mere possibility,
> go ahead, but don't expect me to agree. It is indeed *very*
> practical.
=> It depends on what you mean by "both in parallel". I'm
comparing a *host-based LMM mechanism* to an exclusively *network-based
LMM mechanism*. Have you run those two in parallel? I don't think it
would make sense to do that.
> > 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.
>
> Oho! Please be very aware that here you're *not* arguing host-based
> mobility versus network-based mobility; you're arguing one particular
> type of local mobility-support versus another type.
=> Of course I am! I'm raising concerns against network-based
LMM and my reference is the existing host-based LMM.
THIS can be a
> very interesting discussion indeed, but it is *not* a host-based
> mobility versus network-based mobility discussion, which is what
> your draft seems to be about.
=> Host-based LMM Vs NETLMM. The entire draft addresses LMM
exclusively.
> > 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 :)
>
> Of course I can. There are more degrees of freedom here than can be
> captured in the simple view that 'since A is able to handle inter-
> access mobility, B has lost the freedom to handle it'. Both the set
> of possible radio technologies, and the set of potential providers
> of such are open-ended, and provide for much richer possibilities
> than that.
=> So let's discuss those possibilities.
> >> 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!
>
> I don't know what you want to say with this.
>
> I'm trying to show that your fears about NetLMM is largely
> unfounded, and
> it seems to me that you're wed to your fears, and won't let
> go of them
> even if they're unfounded.
=> I'm not talking about fears, I'm raising technical concerns.
If they are unfounded then tell me why. Simply saying that they're
wrong or negating them without explanation doesn't help. For example,
my answer above refers you to the definition of "local Mobility", which
says nothing about whether the handover is within the same access tech
or a different one. Your response talks about my unfounded fears. That's
not progressing a discussion.
> >> 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.
>
> What you're describing here is not predictive capability,
> but reactive:
> measuring what is. For the access technologies *known to
> it* a network
> may be predictive, where a mobile node has a harder time of
> it.
=> I don't see how it is possible that the network can predict
better than the mobile since every link I've seen that is capable
of this prediction bases such prediction on the information received
from the mobile. My point in that particular paragraph was about
the uncertainty of movement during handovers and how the mobile
node can react quickly to those changes. The handover itself is
predictive because actions are taken before the mobile moves. However,
I was concerned with reactions to certain changes in signal strength,
availability ...etc that can happen later in the handover process, i.e.
potentially after the network had already decided that the mobile is
moving to a particular link.
Of course,
> for access technologies outside those known to a network, it
> will know
> nothing (unless the mobile tells it about those).
=> Sure, but whether an access network is "known" is itself
another big question. "known" should mean "known and functional".
An AP might be present, responds to pings, but it's radio isn't
functioning. So a server in the core would certainly know less
about the state of the radio than a mobile which can detect whether
an AP is funtional, available, limited ...etc.
>
> So, my question above stands:
> 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?
=> I tried to answer above.
> > 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.
>
> Since the NetLMM work is *much* younger than 5 years, I don't know
> what other efforts you're overloading on the current one here.
=> Ah, the WG is very new of course, the culture of "network control"
is very old and we had these discussions for many years in MIP. Some
of "no mobile involvement" approaches are even reflected in certain
modes of FMIPv4 and v6.
> > 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.
>
> Fine. So comment on the problem statement.
=> There is a whole section on it in the draft.
> > 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.
>
> No. Of course you don't want to manually manage 20 K
> base-stations' SAs.
> But that doesn't mean that you can't pre-configure the relationships
> using other means than manually handling each of them. The point is
> that you wouldn't do it ad-hoc.
=> Not sure what you mean by "ad-hoc". You can certainly pre-config
with Certificates ...etc but the point raised in the draft was two
fold (assuming that you agree manual config is not practical):
A. You don't want SA establishment during handover because it adds
time. Since we don't want permanent NxM SAs (no of ARs times number
of anchors), we have a timing problem. This is specific to NETLMM.
B. It's not easy to deduce how many SAs are needed in the anchor based
on the number of MNs it can support. This is a dimensioning
challenge
which only exists in NETLMM.
Hesham
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
