Subject: RE: [mobile-ip] LMM for IPv6 requirements-Movement detection

From: "Qiang Zhang" <[email-masked]>
Date: Wed, 21 Nov 2001 18:18:05 -0500

Maybe should differentiate 
"physical movement" from "topological movement" ? 

I see AAA possible for the later, but no where for the physical
movement. 

Michael Thomas wrote:

> I'm making no point whatsoever on the whole draft,

Mike,

nor do I say you are making a point on the whole draft.
By mentioning the _whole_ draft, you are making a general
comment out of a particular comment. If you tweak the
premisse of a particular point into a general point, of course
the conclusions won't hold.

>
> nor can I see how my comment would be taken as
> such.

See, how could it be taken as such, as no one said it would?

> Nor have I ascribed blame on you or anybody
> else, as I have no idea who wrote the paragraph
> that was quoted.

Authorship of said paragraph (mine) was in the line _before_ said
paragraph.
Please add a disclaimer in your comments in the future saying that
your comment focuses on what you kept, and what you cut out you
disregarded. People in this list might assume you comment on the whole
email,
and might not understand where you are coming from.

Cedric.

> I'm simply pointing out that AAA
> seems like a very weird example of what
> could/should be used as a movement detection
> mechanism. As for better wording, I'd suggest that
> any mention of AAA in that capacity should just be
> deleted from the text of the requirements.
>
>              Mike
>
> Cedric Westphal writes:
>  > Mike,
>  >
>  > Michael Thomas wrote:
>  >
>  > > Cedric Westphal writes:
>  >
>  > something that conveniently got omitted to make a point. Please do
>  > not use the so-called 'projector' technique, where you point at one
>  > detail to cast doubts on the validity of the whole. The
professional
>  > attitude, as well as the common etiquette on IETF mailing lists, is
to
>  > at least mention (with a *snip* or equivalent) that you cut
something
>  > from the exchange.
>  >
>  > >
>  > >  > 3.5.4 Movement detection
>  > >  >
>  > >  > Any LMM mechanism MUST contain or make use of a mechanism that
provides
>  > >  > movement detection between separate visited domains. Movement
detection
>  > >  > allows a MN to identify that it has moved to a new LM domain,
and to perform
>  > >  > registration in the new LM domain. LMM mechanism SHOULD
interwork with
>  > >  > a default movement detection mechanism, such as AAA.
>  > >
>  > >    AAA?!?
>  > >
>  > >    AAA isn't a movement detection mechanism, nor should it be
>  > >    used as one. That's a *very* bell shaped view of the world.
>  >
>  > You can blame me as much as you care, the mention of AAA comes from
the
>  > original 3.5.4 Movement detection paragraph in the draft. By the
way, Mike,
>  > if you have some better wording to offer, please do so.
>  >
>  > Cedric.
>  >
>  > >
>  >
>  > >
>  > >
>  > >            Mike
>  >

---

From: Theo Pagtzis <[email-masked]>
Date: Wed, 21 Nov 2001 23:46:18 +0000

Guys,

 AAA is the last wheel of the carriage that gets notified about the
movement of the MN to an new domain. This has been already preceded by
network detection (L3). I would be grateful if we do not mix the two
even if we mean site/domain/planet or interstellar movement...

we all understand what was meant by the example that was brought up and
we all appreciate that the network layer prevails over detection in any
case (since we are concerned with IP mobility - yes I know it was L2
that saw it first.. )

let us please move forward on that and remove AAA from the movement
detection map or I think I am going to faint..

Theo
UCL/Mobile Systems

---

From: "Jari T. Malinen" <[email-masked]>
Date: Wed, 21 Nov 2001 16:24:49 -0800

I agree. For the sake of the main list not being flooded with LMM design
team discussion, and to get ahead, let's just drop the example text
"such as AAA". We could also call the movement detection as LMM domain
movement or LMM domain detection.

For Mike: AR domain and LMM domain detection coupling/decoupling is
a design space issue, if the former is always available and can indicate
the presence of support for LMM, ok, it is just worth mentioning LMM domain
detection is an issue whether provided separately or by e.g. AR domain
detection.

BR,

-Jari

---

From: Michael Thomas <[email-masked]>
Date: Wed, 21 Nov 2001 16:37:44 -0800 (PST)

> detection is an issue whether provided separately or by e.g. AR domain

   Hmm. Putting it into design space makes it harder to
   evaluate solutions by comparing them to requirements.
   A somewhat similar argument erupted a while ago about
   the assumption that the AAA and HA were always in the
   same administrative realm. If we were drawing
   up requirements for that, I'd say that that would
   be a pretty important one to settle on. I'm
   somewhat concerned that this could be a similar
   case and that it would be better resolved in the 
   requirements phase rather than 6 months into
   the design phase...

	      Mike

---

From: Theo Pagtzis <[email-masked]>
Date: Thu, 22 Nov 2001 00:55:50 +0000

Hi Mike,

  the issue of LMM detection pertains primarily on the established issue
for (auto)configuration of the LMM..since they have to advertise their
existence (or better LMM capability). Advertisment alone can effect one
level of indirection (let's put it this way) in the 'detection'
abstraction still at L3. How you do that is up to the LMM
autoconfiguration protocol but it has indeed been addressed in the
requirement space IMHO as the requirement for autoconfiguration...

I would suggest we do not scratch this wound on this draft...there is _a
lot of space for another_ a pointer for it already exists though..

So by just a single capability flag I can solve (very crudely) and fuse
the AR/LMM detection...the requirement is how to configure the thing to
do that cooperatively with an AR/LMM population and has been addressed I
am sure... (I wrote it.. :)

Theo
UCL/Mobile Systems

---

From: "Jari T. Malinen" <[email-masked]>
Date: Wed, 21 Nov 2001 17:46:07 -0800

This reminds me that there was a question in the design team
on what the autoconfiguration in the text refers to. In addition
to setting up the capability advertisement in ARs, you say it also
encompasses the MN operation on recognizing the capability.  This
is clearer if there is also the text on LMM domain movement detection
as a separate item.

Settling whether the AR/LMM domains are coupled/decoupled now may
indeed help evaluation but it also may lead to the kind of dispute
Mike was refering to: if we now say AR/LMM domains are the same or not,
we create the kind of assumption that later may get challenged.
To help evaluation when leaving it as a design space issue we may
consider a basic design principle of making protocols independent of
each other when possible.

BR,

-Jari

---

From: Theo Pagtzis <[email-masked]>
Date: Thu, 22 Nov 2001 02:00:40 +0000

hmm....

IMHO we must keep the AR and LMM entities fused as one (tightly
coupled). The reason is that if you don't do that you introduce
immediately a routing overlay...on top of ARs..routing-wise I think this
is going to be non-optimal

> is clearer if there is also the text on LMM domain movement detection

yes perhaps we could accomodate such mention..it is not unreasonable
especially for spare LMM deployment..

> each other when possible.

beware..(see top) because if you do them independent...you effectively
talk about routing overlays..this is against aforementioned requirements
in the LMM req draft.

Theo
UCL/Mobile Systems

---

From: "Jari T. Malinen" <[email-masked]>
Date: Wed, 21 Nov 2001 18:27:12 -0800

Theo,

I think we were here discussing a bit different issue than routing
overlay. Whether LMM domain detection and AR domain detection is
the same or not does not mandate/prevent from placing LMM entities
to ARs only, their transport topology can be a separate issue from
how a LMM domain is detected by MN connecting to an AR.

BR,

-Jari

---

From: Theo Pagtzis <[email-masked]>
Date: Thu, 22 Nov 2001 03:34:35 +0000

Jari,

 I am aware that the issue appears somewhat different than what was
mentioned..however I look on the impact of the seperation you or Mike
may advocate..

I respectfully disagree with your position..by the time you decouple a
single LMM entity away from its AR device for inter-domain LMM
detection..you have done it for all...otherwise how could you
distinguish which is which..unless of course you only have one LMM agent
per domain..which I trust is a no-no (does not scale).

Theo
UCL/Mobile Systems

PS.If you don't hear me back in your next response I've gone to
bed..night to all..

---

From: "James Kempf" <[email-masked]>
Date: Mon, 26 Nov 2001 08:20:23 -0800

I agree with Theo and Mike on this.

There is a danger with LMM that it will become a routing overlay. The
requirements must clearly establish that it isn't, to avoid adverse
interactions with routing. Therefore, I think the requirements need to
explicitly state that movement detection for LMM agents is done via AR
movement detection.

        jak

---

From: Michael Thomas <[email-masked]>
Date: Tue, 27 Nov 2001 13:23:42 -0800 (PST)

> is going to be non-optimal

If you're talking about the FMIP case where you
normally use it as a helper during the handoff,
rather than a semi-permanent pivot point (as with
HMIP), is the sub-optimality really the principle
concern? When I'm handing off from one AR to
another, it only matters that it's "fast enough"
to achieve the desire results. Being colocated
with the AR is probably the most optimal, but it
seems questionable whether we should preclude the
ability to place it elsewhere. For example,
suppose that I roam into an AR that for whatever
reason doesn't/won't support FMIP. Should I not
have the ability to use something else which is
good enough to achieve fast handovers even though
it won't achieve least cost routing? Sounds like a
plausible scenario to me, and keeps with the
general internet philosophy of unbundling
services.

		Mike

---

From: Greg Daley <[email-masked]>
Date: Wed, 28 Nov 2001 11:11:57 +1100

Hi Mike,

	I think that the issue of becoming an overlay network 
	is largely moot. (I.e. it is unlikely that LMM will become
	an overlay, to any greater extent than MIPv6).

	What is possibly useful is to make sure that the AR is
	in charge of LMM discovery mechanisms, to ensure that
	multiple agents aren't contending for the same access medium,
	and so that the routing functions aren't re-implemented.

	With regard to the LMM Mobility (rather than discovery) function,
	I prefer that the LMM schema doesn't tie it into the AR,
	since this breaks a lot of "good enough" solutions (Like HMIPv6)
	as you mention.

		Greg Daley

Michael Thomas wrote:
>\

---

From: "James Kempf" <[email-masked]>
Date: Tue, 27 Nov 2001 16:18:35 -0800

I don't understand what you mean by LMM Mobility. My understanding is
that the only issue involved in movement detection is having the mobile
node determine when it has moved from one LMM agent coverage area to
another. But you seem to have something else in mind.

            jak

---

From: Michael Thomas <[email-masked]>
Date: Tue, 27 Nov 2001 17:28:50 -0800 (PST)

> 	and so that the routing functions aren't re-implemented.

Well, this doesn't really address my concern which
was what happens if the AR doesn't support LMM at
all? It seems to me that the fate sharing is
between the LMM and MN, and if there's isn't
explicit linkage requiring AR/LMM to be colocated,
then an LMM would need to have some means of
advertising itself which is under *its* control.
This is particularly important since we don't want
to give point of attachment a stranglehold on the
mobile node just by virtue of its being the point
of attachment.

		Mike

---

From: Greg Daley <[email-masked]>
Date: Wed, 28 Nov 2001 13:01:28 +1100

> another. But you seem to have something else in mind.

	Hi James,

	It depends on how tight the coupling is.
	I just don't want to get into a situation where the draft
	says something like "The LMM Agent should be co-located with the AR"

	since there are at least two functions:

*	The advertising/dynamic discovery mechanism for the LMM domain
	(which is intrinsically tied to a set of access networks)

*	The mobility management and signalling which may or may not be
insensitive
	to where the Mobile devices connect from.

	Maybe I'm just being reactionary, but since there are two functions,
	I see two agents, apart from the mobile node.

		Greg

---

From: Greg Daley <[email-masked]>
Date: Wed, 28 Nov 2001 13:34:28 +1100

[answers below:]

	Hi Mike,

	I understand what the problem is since we are dealing with 
	it ourselves.

	We have an old router which does IPv6 but doesn't support
	the advertised options which we require for our LMM solution
	(HMIPv6).

	In this case, the issue is specific to the Local Access Network,
	and thus by putting in our own advertising agent on the local
	network, we solve this problem.

	The same mechanism is used, but upgraded to include the advertised
	options, which could be expected from the AR. Since these are 
	link local Router Advertisements, there is no propagation
	for the capability across multiple L3 Access networks.  There is
	also no requirement to process this information from multiple
	remote sources.

	Therefore, the LMM compliant Mobile Node does not have to decide
	between which advertising mechanism to watch for or which received
	advertisement to choose between (in this simplistic situation).

	If the mobile node starts making those decisions based on the 
	externally advertised information (from possibly multiple sources),
	then that is a routing overlay, since it replicates routing function.

	I don't even mind that another entity than the Access Router (on the
	access network) takes these advertising functions on, so long as the
	end nodes aren't required to make choices based on advanced network
	knowledge or additional protocols, and the Advertising Agent can be
	left to tell them what LMM is available.

	Sorry that this was so long winded.
	I think we have two goals which aren't necessarily duelling with each
	other. It's just a matter of trying to find the best balance of words.

		Greg

---

From: Theo Pagtzis <[email-masked]>
Date: Wed, 28 Nov 2001 08:19:28 +0000

I believe that if you place the LMM agent anywhere else than the AR you
will eventually have suboptimal routing since it will need to go to

  that AR ------> LMM -----> that AR ------> MN

whereas you can have it

  to AR/LMM ----> MN

I anticipate that some border ANR would host the LMM within the domain
whereas the FMIP proto would need to be deployed at the last hop
wireless. Otherwise you end up having suboptimal second routing legs
beyond the border router. In that respect I cannot see how FMIP gets
mixed with LMM irrespective where the first is support or not.

Also how can a handoff be fast and also have suboptimal routing in
effect. It looks to me as if you are spinning your wheels to go away
from inertia...ie run fast for a handoff but run so fast to make it up
for the suboptimal route...I am not convinced that it sounds plausible
unless of course you have a commercial scenario in mind that I haven't
heard of yet..

Theo
UCL/Mobile Systems Group

---

From: Theo Pagtzis <[email-masked]>
Date: Wed, 28 Nov 2001 08:31:08 +0000

Just a second...

  the primary function of an LMM agent function is to localise signaling
w.r.t. BUs as well as forward the traffic to the MN.

The advertising and dynamic discovery of one or more LMM is _not_ what
an LMM is characterized as such. That is to say that some agent that
advertises existence of an LMM is not an LMM agent by itself. I am
saying this because you seem to decouple the advertising function from
the core LMM function..while this is fine by me...since you want to
somewhat centralise reporting of LMM agents to the advertiser such that
you have better control of advertising.

However by no means is the advertiser an LMM agent...otherwise you have
elected a single LMM agent as advertiser, which if it goes does down so
goes for the advertising capability. In that light the advertiser is not
an LMM agent.

The fact that some announcer voices that the king is around does not
make the announcer a king.

Theo
UCL/Mobile Systems Group

---

From: Michael Thomas <[email-masked]>
Date: Wed, 28 Nov 2001 08:57:55 -0800 (PST)

>   that AR ------> LMM -----> that AR ------> MN

   Sure, I didn't claim that it would be least cost.
   In fact, I asked whether the tradeoff of least cost
   vs. severability should be toward least cost. At least
   in the case where the "fast" tunnel is temporary.
   Read on...

 > unless of course you have a commercial scenario in mind that I haven't

   Fast, of course, is in the eye of the beholder. The
   transit times through the core of the network these
   days are primarily due to speed of light considerations
   if you don't experience congestion. Thus, it's not 
   inconceivable that you could place your LMM geographically
   and topologically "distant" and still meet the real time
   goals of your handoff. 

   For example, I just ran a traceroute between my home 
   machine in San Francisco, and Cisco's SSH server in 
   San Jose, the first hop cost was about 13ms, but the
   rest of the trip through 9 routers (!) was about 3ms.
   Thus, if my LMM were, say, at the edge of Cisco's
   network rather than at the first hop router, I'd be
   saving 3ms out of 16 total, perhaps less depending
   on the actual source/destination. For voice traffic,
   an additional 3ms of jitter is pretty much noise
   (doubly true for wireless). To my mind, this
   says that actual location of the LMM needs to
   be close to the MN, but not "as close as
   possible". Thus it seems that colocation while
   potentially simplifying the requirements, isn't
   based on any need for "fastness". Given the 
   potential benefit of splitting the
   functionality for AR's which will not/cannot
   do LMM, I think we ought to consider that
   scenario.

		Mike

---

From: Theo Pagtzis <[email-masked]>
Date: Wed, 28 Nov 2001 17:46:23 +0000

Hi Mike,

>    and topologically "distant" and still meet the real time

unless other types of latency hit you that are beyond congestion...yup I
agree with that..
>    do LMM, I think we ought to consider that

I think we agree on that..I don't want to bring an LMM so close to the
MN such that it can touch it by breathing...far from it..I agree with
you..you need to give some slack to the MN to move around..it is exactly
like the leash on a dog...if you have the leash too tight you have
control of the dog but you do strangle him (litteraly :) in terms of
movement..

however..if you give some slack to the leash, the dog can only move
around a certain locality...

but..wait a sec. Perhaps we are arguing about a point we were agreeing
in the first place. What I had in mind is that the LMM needs to be
co-located with a AR, but in fact I meant a border router (perhaps ANR
sounds better). Beyond that if you don't have that many border routers
at the edges of your domain, I would be in favour to co-locate the LMM
agent(s) also on some router(s) within the domain to achieve redundancy
and load balancing. What I felt as not in favour of was to put an LMM as
a stand alone box that is not a router.

The idea in my head is thus to co-locate with ANRs (what hesham
mentioned correctly as route aggregation point) and maybe ARs for
multiplicity.

Theo
UCL/Mobile Systems Group

---

From: Greg Daley <[email-masked]>
Date: Thu, 29 Nov 2001 09:01:54 +1100

Hi Theo, 

	Maybe this part is a confusion of terms.

	Advertising the LMM locations is obviously part of LMM.

	Since the Advertiser has to know the identities of LMM Mobility
	Agents, I named it an LMM Advertising Agent. (including it as part
	of the logical system).

	This is because the Advertising agent may have to know and
	understand the state of LMM Agents (and must be part of the
	framework, even if this function is not used in every LMM solution).

	I personally don't see any major problem in defining two discrete
	entities with discrete functions both as Agents.

	i.e. the Advertising Agent does not have any of the function of 
		the Mobility Agent (--> packet tunnelling/forwarding/etc.).

	it is most likely a software process like radvd...

	If there is consensus that this description is not helpful, I will 
	refrain from using it.  What others have said recently regarding the 
	location of LMM (Mobility) Agents could indicate that this distinction
	is useful.

		Greg Daley

---

From: Theo Pagtzis <[email-masked]>
Date: Wed, 28 Nov 2001 22:36:39 +0000

>         Maybe this part is a confusion of terms.

possible, but not on this end.. :)

>         Advertising the LMM locations is obviously part of LMM.

yes, but carefull.. by LMM I do not imply agent, but the scheme of
localised mobility management.

>         Agents, I named it an LMM Advertising Agent. (including it as part

now we are in sync...proceed..
>         framework, even if this function is not used in every LMM solution).

well we don't want to open that can of worms...yet..but sure..one slight
objection...know...yes..understand..hmmm perhaps not...unless the
advertising agent is going to re-elect a new LMM agent as soon as it
looses the heartbeat from the former master..then yes I can see where
you coming from..

>         entities with discrete functions both as Agents.

if we want to be structured I would opt for these terms....the abstract
functions are quite applicable to any solution..
>         location of LMM (Mobility) Agents could indicate that this distinction

I think it is indeed
>                 Greg Daley

Cheers

Theo
UCL/Mobile Systems Group