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

From: "Glenn Morrow" <[email-masked]>
Date: Tue, 1 May 2001 11:26:12 -0500

Phil,
 
I'm sorry I haven't responded to this yet. The traffic has been large on
these mailing lists. Sorry again for not getting back to you on the seamoby
draft yesterday. I tried to give some comments today for what they are
worth. Let me know how things turn out. I would like to participate on the
IRTF work.

-----Original Message-----
From: Phil Roberts [mailto:[email-masked]]
Sent: Friday, April 27, 2001 2:58 PM
To: [email-masked]'
Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised
Localized Mobility Management Requirement s)

Hi Glenn,
 
   I didn't mean to ignore your earlier post.  I responded to something
else, got pulled into a meeting, and forgot.
 
   I want to respond to your question about changing real routing protocols
to meet these requirements.  In seamoby there is a small team putting
together a problem statement to get some work started on the routing issues
in the IRTF.  There is a draft of this that SHOULD appear on the seamoby
mailing list early next week.  Your comments on that are more than welcome.
 
   As far as doing that sort of work here, we've tried to focus our work on
protocols based on MIP.  That doesn't mean there aren't other mobility
alternatives and part of seamoby was to figure out whether a good statement
could be put together for requirements that would point to the need for
alternatives.  The outcome of that work so far has been to get some work
done in the IRTF on the impacts of using a "real routing" protocol to
implement mobility rather than a MIP kind of scheme.  Another work item was
to produce a list of requirements to send to us for feedback on whether the
MIP set of protocols can meet them.
 
Phil

-----Original Message-----
From: Glenn Morrow [mailto:[email-masked]]
Sent: Friday, April 27, 2001 3:51 PM
To: [email-masked]
Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised
Localized Mobility Management Requirement s)

Correction,
 
I believe some vendors have actually tried to make some inroads into these
requirements  and direction for solutions already
 
That's providers  - not vendors.

-----Original Message-----
From: Morrow, Glenn [RICH2:C330:EXCH] 
Sent: Thursday, April 26, 2001 1:56 PM
To: [email-masked]
Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised
Localized Mobility Management Requirement s)

Phil, 

I'm not sure either candidate is exactly what we want in the end. So I am
also not sure we should start calling these proposals protocols that have
been summarily accepted or rejected, yet. 

It seems to me that just because the WG has allowed another candidate to
become a WG document does not mean that the WG rejected another WG document.

I may have missed some hmmm, I admit, though. The way I see it is that two
groups have placed different strawmen on the table without any clear
requirements to begin with. Now we are going through the requirements
discussion.

I honestly think that levels of hierarchy (even only 2) gets into the real
routing domain unless you spin an LMM to be an application running on a
host.  

Why are we not looking at changing real routing protocols to achieve some of
these functions? We haven't even gotten into integrity, race conditions,
security associations, routing policy, levels of route propogation and
confidentiality amoung these entities. It seems these real routing protocols
have already been built with these things in mind and that adding the MM
levels might be fairly straight forward.

We might even find that we can get rid of single point of failure with this
approach. This and the fact that the people were obviating the fact that
they were actually doing single per host routes with a name change are my
big sticklers on this whole subject and the main reason for my earlier
tirade in which I compared RR to other proposed solutions that had the same
single point of failure issue but had not been accepted to the WG for this
reason in the past. This didn't mean HMIP. Please note - I didn't submit
these other solutions. 

I also think that with this approach, tunnel-relaying or source routing, the
scalability concerns in terms of route table size may completely vanish with
respect to supporting multiple levels of hierarchy.

We also might find that we can leverage the existing security associations
of these routers and domains to enhance handoff by adding a new mobile
dimension to the routing distance algorithms from a hierarchical point of
view.

I also seems to me that some other solutions that do not have the SPOF
problem have also not been accepted as candidates. The only reason I can
suspect for this is that people made up some lame excuse for summarily
rejecting the use of existing routing protocols or they wanted to just
re-invent the whole wheel from scratch.

We really need to start thinking like the network infrastructure owners and
their administrative staff instead of new protocol creators. I admit I am
also guilty of not doing this in some respects. I believe some vendors have
actually tried to make some inroads into these requirements  and direction
for solutions already. 

I hate to rehash old decisions but why are we not following this direction? 

Thanks, 

Glenn 

p.s. Sorry about any percieved ranting. 

-----Original Message----- 
From: Phil Roberts [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Wednesday, April 25, 2001 3:29 PM 
To: [email-masked]' 
Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised 
Localized Mobility Management Requirement s) 

I'm hoping we don't restart the protocol selection process.  If there are 
compelling reasons to do so we shall.  The requirements gathering is more of

a way to get some convergence on what is really needed in the protocol. 
There has been a fair amount of reflection that has gone on since the 
working group selected the HMIP approach. 

> -----Original Message----- 
> From: Behcet Sarikaya [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Wednesday, April 25, 2001 3:20 PM 
> To: [email-masked] 
> Cc: [email-masked] 
> Subject: Re: Multiple Levels of LMM agents (was: RE: 
> [mobile-ip] Revised 
> Localized Mobility Management Requirement s) 
> 
> 
> Hi Charlie, 
>   I have a feeling that you are talking about regreg6. Is 
> regreg6 still a 
> candidate protocol, i.e. after the requirements will the 
> protocol selection 
> process for LMM  restart? 
> 
> Charlie Perkins wrote: 
> 
> >  Furthermore, 
> > the upgrade is not a forklift upgrade.  One can put in 
> regional-aware routers 
> > wherever they are needed, and not disturb the other configuration. 
> > 
> > We know that the code to do multiple levels is small, and that the 
> > protocol isn't bad at all. 
> > 
> > Regards, 
> > Charlie P. 
> 
> Regards, 
> 
> -- 
> Behcet 
>

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 10 May 2001 10:55:50 +0200

Hello Charlie, 

> >         => The argument thus far has been whether there is any significant
> >         improvement (in delays) that could outweigh the introduced
> >         complexity within the network. So far I haven't seen an argument
> >         to prove that there is such _significant_benefit.
> 
> There is obviously some benefit.  Any time you can put fewer
> processing nodes in the middle of the signaling path, you will
> get improved performance, surely at least by having less jitter.
> I am worried that mistakes at this basic level will have ramifications
> for future handling of video/multimedia streams, and various other
> QoS (especially delay-oriented) reservations.
> 
	=> There is one benefit (point 1 in Erik's mail) in certain 
	cases and there are some obvious disadvantages. The point is whether
	this one benefit outweighs the disadvantages. 
	Also Gopal sent a nice summary that related to your point 
	above about signalling reduction. Processing a signal in more
	than one level will in fact add more delays. Unless 
	forwarding a packet somehow takes longer than procssing it, 
	but that's clearly not true.

> Plus it seems to stand out as the right thing to do.  
> 
	=> Well .... "stand out" is in the eye of the beholder :)
	It was never a requirement for v4. There is nothing different
	here.

> Whether the
> performance gain is significant probably depends on the particular
> network architecture.  As has been noted, restricting the number
> of levels introduces a new requirement to figure out how high or
> low to place the LMM agents.  
> 
	=> You need to do that anyway. We can't short circuit network
	engineering. If you have multi-level LMMs you need to know where
	to put each level to minimise the amount of times a BU is 
	processed on multiple levels, which would in fact make a multi-level
	LMM scenario slower than a single one.

> > >   ---- Backbone/Core Network/IP RAN at least,
> > >
> >         => I don't know if there are any RAN standards
> >         that require this. However, if in future open RANs
> >         are standardised then the argument is the same
> >         whether a network is a RAN or not.
> 
> It is very likely that we'll eventually have open RAN.
> To me, it's clear that a RAN should be a collection of
> IP routable networks.  Do you say otherwise?
> 
	=> No, but the discussion so far hasn't distinguished
	between open or closed RANs. We're discussing the 
	concept regardless of the architecture of what kind of 
	network it's in. What makes an open RAN so different 
	that it requires this ? 
	In fact for an open RAN the delays over the air are so high that no 
	significant gain is perceived in reducing the forwarding 
	delays over the wire. Have I missed something ?

> If your argument is that we don't have IP RAN, so we
> don't need leveled LMMs, then I believe that is a very
> short-sighted argument.
> 
	=> No that was not my argument. I don't see how
	open RANs are so special. In fact if anything it 
	is a living proof of my argument that delays on 
	the wire are insignificant. 

> > >   But why should we have to botch the
> > > obvious network architecture in order to support something only marginally
> > > easier (if at all!) to implement
> > >
> >         => To avoid multiple single point of failiures and keeping unnecessary
> >         state within the network. The solution is not so trivial IMO.
> >         There are several downfalls to consider. Robustness is only one,
> >         Security is another, network availability is another one. All that
> >         amounts to cost.
> 
> First, we should get the LMM agent architecture right.  Security will
> not add any particular penalty here.  Network availability and robustness
> are the same in this context.  > 
> 
	=> Well it is clear (at least to me) that once we start looking at 
	the solution on a lower level of detail (not even implementation
	but simply protocol design) we will see that it _is_ very complex.
	Robustness will certainly become an issue. 

> That requirement can be met by some
> protocol that resolves node failures (a routing protocol).  Whether
> it's a modification to OSPF, or a manet, or something in-between,
> is a problem we can solve in due time.  
> 
	=> This also implies that just to get LMM right we need 
	a few more protocols to make it work. And I do foresee 
	that also if this requirement is placed. Hence, the need 
	to have some very concrete justifications.

	Regards,
	Hesham