Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L ocalized Mobility Management Requirement s)

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 24 Apr 2001 23:34:56 +0200

> Actually, no. I'm saying that we have had at least three people who
> have given good arguments, IMHO, as to why multiple levels of
> hierarchy might be needed. On the other side, those arguments
> are refuted by two people who think that no hierarchy is needed.
> Neither side is going to convince the other, both sides have
> good arguments.
> 
	=> I'm not sure who you mean by the "two" people, there is definitely 
	more (at least the authors of HMIP are) but anyway
	after reading the discussion it really seems to me like the only 
	two (understandable IMHO) reasons are:

	1.  In future there may be a need for multi-level hierarchy. That need 
	is not explained really. To me this is not a good reason for including
	any feature. Ithink it makes a lot of sense of scope the problem to
	what we know without "guessing" what might happen in future
	and how theuse of MIP can be changed dramatically. No one 
	knows that this is true.

	2. Multi-level hierarchy localises the signalling. Let's try to understand 
	what this really means. A MAP domain is as large as the amount 
	of traffic that a MAP can handle, regardless of the number of 
	levels of hierarchy. The signalling will always be local to that
	domain. So I'm not really clear on the significant advantage here. 
	We're certainly not expecting any inter-continental mobility 
	management using HMIPv6. So careful placement of the MAP 
	using network engineering skills and common sense is 
	sufficient. 

> What I'm saying is that we have some arguments the feature is needed,
> so let's put it in. From Karim's last email, it sounds like we can
> probably accommodate his concerns about multiplying failure possibilities.
> 
	=> At a cost. The beneft MUST outweigh the cost. This is not 
	the case here IMO.

> If we don't put it in and deployment proves that we need it, 
> 
	=> This is exactly point one above. 

	Hesham

---

From: Theo Pagtzis <[email-masked]>
Date: Tue, 24 Apr 2001 15:14:30 -0700

Hello Hesham,

Not sure that you have read  either my previous postings and of course underlying
reasoning on this topic.

I will just reiterate what the constituency has spoken here and say that we (and
speaking also for myself, I) have elaborated on the topic as concretely as possible..

You may feel that you do not _understand_ the reasons (once more)...the rest of the
constituency _has_. To that people have either agreed or disagreed or expressed
reservations. You, _simply_ don't understand it... QED..

Design means to me catering for future needs. If you do not know future needs you
have to envisage strong possible (within reason) scenarios. Multi-level hierarchy is
one of them IMHO the arguments have been presented in past postings (please take a
look at the thread).

You insist to make specific LMMs to MAP...i.e. HMIP... we have been trying to talk
about LMM candidate schemes. The earth does not revolve around HMIP but LMMs....

The size of the domain is something that is not cast in stone. It is expressed as the
growth in network infrastructure that maps to an individual ISP. The world expects
that ISPs will grow larger in that sense by populating the routing fabring with more
and more routing elements...

in layman's terms MORE CARS --> MORE ROADS otherwise congestion and collapse is
around the corner...I hope you can see the natural analogy with networks.

I guess the above _signifies_ how the benefit outweighs the cost...what is the
benefit...?????

yes you "guessed" right....SCALABILITY...

I hope the above make things a little clearer now...

Theo

UCL/ Mobile Systems

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 26 Apr 2001 07:28:18 -0700 (PDT)

> Hello Hesham,
> 
> Not sure that you have read  either my previous postings and of course
> underlying reasoning on this topic.
> 
> I will just reiterate what the constituency has spoken here and say that we
> (and speaking also for myself, I) have elaborated on the topic as concretely
> as possible..
> 
> You may feel that you do not _understand_ the reasons (once more)...the rest
> of the constituency _has_. To that people have either agreed or disagreed or
> expressed reservations. You, _simply_ don't understand it... QED..

Count me in for an other person who fails to understand the arguments.

Perhaps my lack of understanding has to do with the following:
With LMM we are fundamentally talking about optimizations - mobile IP
without LMM works in the sense that packets move - we just want to optimize
the amount of signalling traffic as well as the time it takes to
update the mobility agents when the MN moves.

Since this is an ENGINEERING organization I'd expect an argument for
"do it this way because it is more optimal" would actually contain some
engineering: example topologies, numbers showing signalling volume and
signaling latency with and without an hierarchy.
I frankly haven't seen any engineering rigor in any arguments for or against
a hierarchy. (Thesis topic anyone?)

Instead we are operating in a mode where some folks (including me)
arguing that without hierarchy things are simpler and others arguing that
hirarachy is more general and flexible.
Neither argument has anything to do with ENGINEERING.

   Erik

---

From: Theo Pagtzis <[email-masked]>
Date: Thu, 26 Apr 2001 08:35:11 -0700

> Neither argument has anything to do with ENGINEERING.

Hi Erik,

   if you see the thread of my previous postings, you will see that I am indeed
talking about optimizations. in terms of signalling and positioning of the LMM
over an LMM hierarchy if such exists.

In particular from previous posting...

   "What you want is to have the LMM in an optimal position for _both_ :

    1) low signalling
     2) reduction in transiting between LMM agents (that is the core ones like
GMA/MAP/fooGMA/fooMAP/ blah blah..)

otherwise one advantage will just kill the other and at the end you will be
pseudo-LMMing the MN..which is what
else...core MIPv6...  blah blah blah"

If this does not elaborate on optimization then what does it?????

I have also argued about multiple needs for this LMM hierarchy, such as
resiliency to failures. Please tell me how would you expect to recover from a
failure of an LMM if you do not know where it lies with relation to its
neighbours..how are these connected? Does it look like a hierarchy to you? When I
am saying hierarchy I mean would the packet go through one LMM before reaching
the one that just failed...The hierarchy argued here can be used for a
multiplicity of purposes

Both schemes are pushing everything in the autoconfiguration...can you envisage
how you are going to autoconfigure the LMM scheme...with a hierarchy I CAN....and
IMHO I cannot see much else..even if you rename it with a different term...

As for the rigour that you suggested...it is as rigorous as the
counterarguments...but I think I have much more reasons that are compelling such
as resiliency AND autoconfig of the LMM.

What I am saying is that you will use it when it comes to resiliency and
autoconfig, but you want like to admit it..

Populating the admin domain with more LMM-aware routers will also require
repositioning of the LMM...what are you going to do then...move it by hand...and
MOST importantly WHERE???
The WHERE word is all about the optimization implied by an LMM hierarchy...

BTW if we want to take drafts and proposals strictly by  rigour of numbers (soon
to come though..stay tuned..) we would need to scrap quite a few proposals here
in IETF, with all due respect of course...I haven't seen that many figures in
drafts...supporting their engineering benefit..in fact it is  more research that
gives the figures and engineering goes out and implements it...because it
"works"...am I wrong here???

Theo

UCL/ Mobile Systems

---

From: Jim Bound <[email-masked]>
Date: Thu, 26 Apr 2001 11:16:21 -0400 (EDT)

Erik,

I think your point is valid.  But I think its an architecture discussion
and not an engineering discussion and those  are different.  But I do
concede to your point at my end.  But I believe there is an engineering
argument too but first we need to know if LMMs distributed help in the
architecture adn that is a discussion we should have at a minimum.

/jim

---

From: Theo Pagtzis <[email-masked]>
Date: Thu, 26 Apr 2001 14:36:45 -0700

Erik Nordmark wrote:

> Numbers!!!
> As in "I optimized the frob code and it sped up by 10% assuming this following
> traffic pattern" when optimizing a protocol implementation.
>
> > neighbours..how are these connected? Does it look like a hierarchy to you?
> > When I am saying hierarchy I mean would the packet go through one LMM before
> > reaching the one that just failed...The hierarchy argued here can be used
> > for a multiplicity of purposes
>
> I don't see how hierarchy makes recovering from failures any easier.

well if you are an LMM and you fail it would be safe for the LMM above or below
you (ie. upstream or downstream) to take over. This is much better than leaving
the MN hanging out to dry...

>
> And a hierarchy does increase the potential number of single
> points of failure.

I cannot see the "why" here...

>
> Whether there is a single level of multiple LMMs or a hierarchy with
> multiple LMMs at each level for redundancy, you still need the
> equivalent of the OSPF hello protocol to track the liveness of
> the individual LMMs as well as the communication paths between them.
> The more LMMs to observe the more hello traffic will fly around the network.
> I assume, given a maximum failure recovery time of N (seconds), that
> there is a tradeoff between the amount of hello traffic compared to
> the amount of handoff related control traffic between the LMMs and the MN.
> But presumably the "cost" is higher if the MNs need to send lots of
> hello packets compared to most of the hello traffic being in the wired
> part of the network.

I don't want to involve the MN in maintaining resiliency in the hierarchy...if
millions of MN start doing what you say there will be problems...in a shell I am
not refering to any solution yet.. just requirements....

>
> In addition, if there is a hierarchy do you need to worry about the
> probability of more than one LMM node failing at the same
> time in a given branch in the tree?
>

not really...I only mentioned that since you said that a hierarchy increases the
probabilities for single points of failure...If routing elements have the same
probability of failing then it does not matter if it is an LMM or not. You would
have increased probability if two or more LMMs would fail at the same time...hence
my argument that this is rare...so it would look more like individual LMM
failures...and by the time the second LMM failure would come up the repair should
be in effect....

>
> So make some assumptions about a topology of LMM and then calculated the
> signalling and hello traffic and compare a flat and hierarchical scheme.
>
> > counterarguments...[...]
> I was pointing fingers at everybody (including myself) for lack of rigor.
>
> > BTW if we want to take drafts and proposals strictly by  rigour of numbers
> > (soon to come though..stay tuned..) we would need to scrap quite a few
> > proposals here in IETF, with all due respect of course...I haven't seen that
> > many figures in drafts...supporting their engineering benefit..in fact it is
> > more research that gives the figures and engineering goes out and implements
> > it...because it "works"...am I wrong here???
>
> Most IETF protocols aren't there for optimization only - they actually
> solve a new problem. The LMM is just optimization. Thus I think we need
> to actually do engineering here.

In that case I will restrict my wording on LMMs..No LMMs have provided any figures
so I have a difficulty believing one against the other...how about that....?????

Theo

UCL/ Mobile Systems

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 26 Apr 2001 12:11:42 -0700 (PDT)

Numbers!!!

Most IETF protocols aren't there for optimization only - they actually
solve a new problem. The LMM is just optimization. Thus I think we need
to actually do engineering here.
(I think the header compression RFCs like 2507 actually has some numbers
in there. This is an example of something I'd call "just" optimizations.)

   Erik