Subject: [mobile-ip] I-D ACTION:draft-ietf-mobileip-hmipv6-05.txt

From: [email-masked]
Date: Thu, 29 Nov 2001 06:05:45 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF.

	Title		: Hierarchical MIPv6 mobility management (HMIPv6)
	Author(s)	: H. Soliman, C. Castelluccia, K. Malki, L. Bellier
	Filename	: draft-ietf-mobileip-hmipv6-05.txt
	Pages		: 34
	Date		: 28-Nov-01
	
This draft introduces some extensions for MIPv6 and neighbour
discovery to allow for the introduction of a hierarchical MIPv6
mobility management model. The proposed hierarchical mobility
management for MIPv6 will reduce the amount of signalling to CNs and
the HA and may also improve the performance of MIPv6 in terms of
handoff speed. Moreover, HMIPv6 is well-suited to implement access
control and handoffs between different access technologies.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-hmipv6-05.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mobileip-hmipv6-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-mobileip-hmipv6-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Alexandru Petrescu <[email-masked]>
Date: 29 Nov 2001 18:19:12 +0100

Hi,

Thank you for the new version of the draft.

I understand that MAP discovery is still used like in -04, namely MAP
options are re-transmitted from one interface to another.  I still
wonder if routers should re-transmit on other links what they receive
via RA's on one link.  I see this as the job of routing protocols and
not of RA's.

Also, I still think HMIPv6 should specify a way to delete MAP-options
from an advertising interface.(RR means to do that is to put 0 in
use-prefix of a CHANGE).

Alex

---

From: Greg Daley <[email-masked]>
Date: Fri, 30 Nov 2001 09:05:25 +1100

Hi Alex,

	Comments below.

> via RA's on one link.  I see this as the job of routing protocols and

	I have spent a little time thinking on this
	issue.

	Certainly, I don't think the intention
	is to allow the map options to be propagated
	the MN in an unfiltered form.

	Therefore the AR is the destination of the 
	dynamic MAP propagations (it can decide
	what the Access Network sees).

	I understand that RA Propagation is a
	repeat of dynamic routing function, and that
	similar measures need to be taken in the
	propagation as that with other distance vector
	routing protocols.

	I'm not sure if this is what we want to do
	(replicate router function), but it is an
	easy thing to do, and the trust relationships
	between adjacent nodes on a link is likely 
	to be easy to manage (since there is a good
	chance that SA exist between Routers on the
	same link).

	Router Renumbering sounds OK, but who do
	you allow to send the MAP propagations?

*	MAPS?
	
	If so, then dependent on the number of MAPs,
	the key distribution mechanisms are more
	complex (since it is unlikely that every AR will
	have an SA for every MAP). 
	
*	an Central NMS?

	If you allow just a small set of trusted servers,
	to send the RR Map options, then you have a
	situation where the NMS will have to collect
	information about the MAPs before distributing it
	on the to AR's.

	Additionally, the usage of RR means that 
	the MAP Option is not modified on each hop.

	If physical network topology is a factor 
	in determining the best MAP (as seems to be 
	possible in the draft), then the  NMS would
	need to know the locations of each AR and 
	unicast to them each set of MAP options, in
	order to present accurate network information
	to each.

	An all site-routers RR advertisement would
	present to all ARs the same picture of the
	MAP hierarchy.

	If you are interested in hybrid approaches,
	certain things can be done to improve this
	(but the reliance on the RA propagation 
	would still remain).

	I'm not sure if this is the type of thing
	which should clutter up the HMIP6 draft though.

	Maybe it is appropriate to develop separate
	guidance for dynamic map option propagation
	and management?

> from an advertising interface.(RR means to do that is to put 0 in

	It is easy to delete map options by setting the
	Preference value to 255 (do not use).

	This will not necessarily make the MAP invisible
	immediately, but if you advertise at 255 for
	the elapsed lifetime of the MAP option, then
	after that stage, no one will be bound to
	the MAP, and it can be removed from all
	advertisements

	This will work for RA and RR.

	Greg 

Please excuse me if I do not respond (quickly)
I am just about to travel to Europe.