Subject: RE: [mobile-ip] Final(?) Cut on LMM Requirements

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 2 May 2001 17:12:20 +0200

Bill, Raj, Phil, Carl, 

I sent some comments earlier on this list but I don't 
know what happened to them. So I'll send them again 
and in the mean time ad to Bill's comments / questions.

> >Seems like we're converging apart from the multiple levels of
> >hierarchy discussion.  Here's what has emerged:
> >
> >1. LMM shall be introduced to minimize the signalling traffic to the
> >home agent or correspondent nodes for intradomain mobility.
> >(One comment - how constrained is "domain" here?  Certainly
> >administrative domain but can it be more constrained than that?
> >Didn't see any other suggestions.)
> >
> [wg>] I believe it should be an administrative domain. The rationale behind this is so that we can assume some sort of trust relationship between elements of the domain and avoid going down ratholes associated with AAA issues when moving between access points. Issues associated with domains that cover wide geographical areas should be covered by scalability requirements.
> 
	=> Agreed.

> >
> >2. LMM shall be secure from malicious behavior.
> >
> [wg>] I assume you mean malicious behaviour by entities outside the (visited) administrative domain (i.e. MN, CN, HA) on the assumption that entities inside the AD either trust each other or have their own intra-network security mechanisms.
> 
	=> I don't think you can trust other entities inside a visited domain.
	These entities may also include other CNs for example. 
	In addition, you don't normally trust a visited domain that you 
	know nothing about. 
> 
> 
> 
> >
> >4. LMM shall be compatible with fast handoffs.
> >
> >5. LMM shall scale to support millions of nodes.
> >(Comment had been that this was too broad but only other suggestion
> >was:
> >"LMM shall scale so that the number of LMM agents scale linearly or
> >sublinearly with the number of deployed subnets, not the number of
> >mobiles." Unless there is more support for the revision we'll stay
> >with the original)
> >
> [wg>] I prefer the alternate wording -- it avoids arguments like "of course it will support a million nodes ... you just have to add 5 gig of memory to every routing table".
> 
	=> Agreed.

> >9. LMM should provide the same level of mobility management support
> >as in the basic MIPv6 spec.
> >
> [wg>] What does this mean?
> 
	=> It means you don't remove functionality from MIPv6. If function
	X is supported in MIPv6 then it should be supported in LMM.
> 
> >
> >10. LMM should support autoconfig.
> >
> [wg>] Autoconfig of what? Does this include auto reconfiguration of DNS servers, gateway routers, subnet masks, applications servers, etc. etc.
> 
	=> Agreed.

	There was another requirement suggested earlier and that is LMM
	MUST comply with the security requirements of MIPv6 and MUST
	NOT require additional extensions or limitations over what 
	MIPv6 requires. Someone (Carl) can find a better wording perhaps.

	Hesham

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 02 May 2001 08:36:03 -0700

Hello folks,

I'm finding it difficult to keep up with all the discussion,

> mobiles." Unless there is more support for the revision we'll stay

I think the original is better, unless someone can demonstrate that
it is actually possible to achieve the suggested linear or sublinear
growth rate.

> 10. LMM should support autoconfig.

Part of the problem of LMM is to figure out what the mobility
routing agents are doing, and where they are to be located.
If LMM involves host routes, then another part of the problem
will be to manage the distribution of the host routes.  A third
part of the problem will be to find ways for the mobility routing
agents to be able to discover their interrelationships (e.g.,
how they fit in a hierarchy or mesh, perhaps).

These problems do not all have to be solved at the same time,
and therefore not all in the same draft.  So, for instance,
one scheme for the distribution of host routes could be compatible
with multiple schemes for autoconfiguration.  I'd even suggest
that manual configuration is acceptable until we have some
experience with testing and deployment of some scheme.  However,
this is not at all to say that autoconfiguration schemes are
not of interest.  It's just that we can go a long way towards
solving LMM problems without the necessary requirement for
autoconfiguration.

As an example, I think it would be very reasonable to have
a Proposed Standard for LMM possibly months or even a year
before having a Proposed Standard for LMM autoconfiguration.
Look at the example of Router Renumbering for IPv6.  On the
other hand, if we have both ready sooner, so much the better!

Regards,
Charlie P.

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 03 May 2001 14:17:13 -0500

Hi Charlie,
  I found your reference to host routes rather odd.
I think that HMIPv6 does not have host routes
maybe expect at the MAP, however regreg6 seems to
have host routes in routers.
  Can you please shed some light onto this?

Regards,

--behcet