Subject: RE: [mobile-ip] FW: I-D ACTION:draft-malinen-mobileip-regreg6-01. txt

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Sun, 11 Mar 2001 16:17:55 +0100

Hello Glenn, 

You're absolutely right. That's exactly what we have been avoiding 
in the HMIPv6 work. There is no need for a non-robust solution
that intrduces a tree of single points of failures. As you said
network administrators can force routes to introduce this effect
if they want their networks to be less robust for other reasons. 

So far I haven't heard *any* reason for it. 

Cheers,
Hesham

> -----Original Message-----
> From:	Glenn Morrow [SMTP:[email-masked]]
> Sent:	Saturday, 10 March 2001 6:40
> To:	[email-masked]
> Subject:	[mobile-ip] FW: I-D ACTION:draft-malinen-mobileip-regreg6-01.txt
> 
> Hello, 
> 
> I still do not understand why the ability to place something at an arbitrary point justifies destroying the connectionless nature of a IP or even IP mobility.
> 
> If arbitrary point is so important, why don't you just tunnel to the arbitrary point based upon routing policy and leave a natural aggregatable solution connectionless. People can always tinker with their routes to make single points of failure if they wish but why build it in.
> 
> Have people simply given up on keeping things connectionless? Is there some sort of graph theory that somehow proves that this is a connection oriented problem domain?
> 
> Respectfully, I wish to be illuminated on this - one way or the other. 
> 
> Thanks, 
> 
> Glenn 
> 
> -----Original Message----- 
> From: [email-masked] [ <mailto:[email-masked]>] 
> Sent: Friday, March 09, 2001 6:35 AM 
> To: IETF-Announce 
> Subject: I-D ACTION:draft-malinen-mobileip-regreg6-01.txt 
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories. 
> 
> 
>         Title           : Mobile IPv6 Regional Registrations 
>         Author(s)       : J. Malinen, F. Le, C. Perkins 
>         Filename        : draft-malinen-mobileip-regreg6-01.txt 
>         Pages           : 28 
>         Date            : 08-Mar-01 
>         
> This document describes Mobile IPv6 regional registration as an 
> optional extension to Mobile IPv6.  Regional registration introduces 
> visited-domain mobility agent functionality for proxying a public 
> care-of-address which remains the same while the mobile node 
> moves in the visited domain.  This reduces the binding update 
> signaling latency for the mobile node and signaling load outside the 
> visited domain.  The protocol defines regional mobility capability 
> negotiation, regional binding update signaling, and regional-aware 
> data routing through a hierarchy of visited-domain mobility agents. 
> The protocol allows for an arbitrary point in the visited-domain 
> hierarchy to distribute the connection-state maintenance between 
> several mobility agents.  IPSec AH is used for securing the protocol 
> as in basic Mobile IPv6. 
> 
> A URL for this Internet-Draft is: 
> <http://www.ietf.org/internet-drafts/draft-malinen-mobileip-regreg6-01.txt> 
> 
> 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-malinen-mobileip-regreg6-01.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-malinen-mobileip-regreg6-01.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. 
> 
>    << Message: Untitled Attachment >>

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 12 Mar 2001 11:36:05 -0800

Hello Hesham,

> if they want their networks to be less robust for other reasons.

I think that the MAP would qualify as a single point of failure.

I also think that we need to avoid restricting the solution to work only
with a single point of failure.  It would be nice to have a more general
solution that doesn't make the mobile node learn all the relevant
topology.

I think what Glenn was suggesting is basically to rely on some scheme
that moves all the regional knowledge into the realm of host routing
that is controlled by a routing protocol invisible to the mobile node.
This might be possible, but there are a lot of problems with it that
need attention.  In the abstract, I find the idea very appealing.  Some
of the problems have to do with stale routing information.  We'd like
to avoid putting routes where they aren't needed -- this is the "proactive"
vs. "reactive" debate in new clothes.  Our experience with regional
registration has shown some ways to do this.

Regards,
Charlie P.

---

From: Claude Castelluccia <[email-masked]>
Date: Tue, 13 Mar 2001 15:06:46 +0100

> I think that the MAP would qualify as a single point of failure.

Hello Charlie,

a nice property of HMIPv6 (basic mode)  is that the RCoA is NOT the address of
the MAP...
The MAP only proxies the packets (like the HA)....

As a result if the MAP fails, another MAP on the links can easily be used to
backup
the first MAP (of course a protocol is needed here to duplicate the context
but this
is feasable -see section 3.3 of
http://www.inrialpes.fr/planete/people/ccastel/hmip.ps.gz for more infos)
transparently to the CNs (i.e. the RCoA does not change)....

Alternatively, if the MAP fails and the previous solution is not implemented,
the MN will stop receiving the
MAP adverti. message for this MAP and
will switch automatically to another MAP...communication will then be
reestablished....the first solution might
be faster though...

So I am not sure that the MAP would qualify as a single point of failure
because it can easily
be changed dynamically and transparently to the CNs .......

regards,

Claude.

--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/