Subject: RE: [mobile-ip] MIP v6 Regional Registration - identifying requir ements

From: "Glenn Morrow" <[email-masked]>
Date: Mon, 9 Apr 2001 09:49:17 -0500

Resending due to Thursday's server issues.

-----Original Message-----
From: Morrow, Glenn [RICH2:C330:EXCH] 
Sent: Thursday, April 05, 2001 2:09 PM
To: [email-masked]'
Subject: RE: [mobile-ip] MIP v6 Regional Registration - identifying
requirements

In regards to (9) below. 

Is the implementation concept of binding cache not simply a new type of
routing table overlay? 

And is not a binding entry a type of per host route?

It seems to me that a duck has been semantically avoided being called a duck
IMHO.

I guess what I'm trying to say is, "Is it O.K. to use per host routes if we
call the routing table a binding cache and the route a binding entry?".

Thanks,

Glenn

----------- previous message ------------

9) Regional registration shall not introduce host routes in routing tables

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Mon, 9 Apr 2001 00:29:17 +0200

(The authors of HMIPv6 prepared some answers and Claude
	was meant to send it but I guess it was lost. Sorry if you 
	get multiple copies).

	Hello Phil, 

	This is a great start. Thanks for taking the time. 
	We're not sure why it is referred to as RR but anyhow 
	that's just a name and we all know what you mean
	(Localised moility management). 

	We will only answer to the validity of the requirements and 
	not to where HMIPv6 stands in terms of supporting a 
	requirement. We think it is better to first agree on a set 
	of requirements and take it from there.

	I think I've finally caught up on all the mail about regional registrations
	for MIP v6 and HMIP.  There seems to be significant concerns about the task
	to be accomplished and the specific approach that is specified in the HMIP
	draft.  A short list of concerns include worries about introducing single
	points of failure, whether or not multiple levels of hierarchy are needed,
	the amount of signaling and tunneling overhead that is implied, the

	=> We believe we got some confirmation for ROHC and CT
	folks that tunnelling will not be an issue. 

	relevance of load balancing and the particular metrics in the HMIP draft,

	=> Based on the comments received in Minneapolis we thought 
	it would be good to have load balancing (for HA/MAP/CN) in a separate draft.
	Unless  there is consensus against this, we will do that.

	Here's a short list of requirements drawn from comments received over the
	last month or so and from the HMIP draft that the working group participants
	can use as a basis for discussion.  Please understand that this is not the
	list of requirements I believe are needed 

	=> Understood.

	=> Here are some comments. Hopefully these comments 
	should cause the people who raised the requirements 
	to provide some reasons for raising them.

	=> BTW, the single point of failure issue is not an HMIP
	specific problem. However HMIPv6 has less single 
	points of failure than other proopsals. 

	We would like to add two more requirements. 

	0) Localised mobility management should provide the same
	level of mobility management support as in the basic 
	MIPv6 specifiation. The mobility management functions 
	supported in MIPv6 must not be reduced in such mechanism.

	0.5) The provided mechanism must interwork with existing 
	MIPv6, IPv6 and the proposed mechanisms for SA establishment
	in MIPv6. 

	1) Regional registration shall be introduced to minimize the signaling
	traffic to the home agent or correspondent nodes for intra-domain mobility

	=> Agreed

	2) Regional registration shall not introduce new overhead on links between
	the mobile and the regional registration agents

	=> We're not sure what this means. However if it means no more
	overhead than a BU then it's seems like a reasonable requirement.

	3) Connectivity to the mobiles shall not be interrupted in the presence of
	the failure of regional registration agents

	=> Agreed. Although this should trigger some redundancy work
	in the MIP WG. But it should be kept as a target.

	4) Regional registration shall scale to support millions of nodes in a
	visited network

	=> Agreed.

	5) Regional registration shall be secure against malicious behavior from
	visiting mobiles

	=> Agreed.

	6) Regional registration shall allow multiple levels of hierarchy

	=> We can't see a reason for this requirement. We think it's 
	 OK if we want to support mobile networks but we don't 
	think this requirement should be placed for all cases. 
	We never got an answer for the technical merits of 
	this requirement. It would be good to know why. Otherwise 
	we'd like to remove this requirement.

	7) Regional registration shall support fast handoffs

	=> If that means coexist with the current FH proposal
	then we agree.

	8) Regional registration shall not require changes to the mobile node, the
	home agent, or correspondent nodes

	=> We can understand the HA and CN, but no changes in the MN
	seems strange. Is this possible ? 

	=> Agreed. As long as a Binding Cache entry is not regarded as 
	a host route ? strictly speaking.

	Hesham, Claude and Karim