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

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Mon, 12 Mar 2001 19:50:13 +0100

>  
> Probably the problem is related to the difficulty of mobility management without introducing global per-host routing.
> Of course no one is proposing global per-host routing.
> 
	=> That's not a reason to intrduce a tree-like topology. There are other
	ways of doing it.

> If you are concerned about the single point of failure introduced by Mobile IP Regional Registration, our I-D might be worth reading since we tried to propose a solution to relieve the problem of single point of failure while keeping the advantages of regional registration.
> 
	=> I think you've missed Glenn's point a little. He was referring to single pointS of 
	failure, not a single point (one point) of failure like the MAP, GFA ....etc. 

	there is no need for introducing  a circuit-type approach to replace 
	IP routing.

	Regards,
	Hesham

---

From: "Glenn Morrow" <[email-masked]>
Date: Mon, 12 Mar 2001 14:00:32 -0600

Eunsoo,
 
Thanks for the reply. I am trying to get people to open up their minds with
IPv6. It is still fairly malleable for change and has many tools which can
be used to achieve this functionality. The RR draft seems to be let's
fork-lift the IPv4 solution and slap in some anycast magic. I think a better
solution is out there for this functionality using IPv6's features that
leverages any natural aggregation that may exist in any given IP network. 
 
In my opinion arbitary point is not a requirement and even if it were there
are better solutions  which do not require any changes to the protocols,
especially if you use tunneling.
 
RR is nothing more than an IP proxy using MIP signaling to provision it.

 -----Original Message-----
From: Eunsoo Shim [mailto:[email-masked]]
Sent: Saturday, March 10, 2001 10:11 AM
To: mobile-ip
Cc: Eunsoo Shim
Subject: Re: [mobile-ip] FW: I-D
ACTION:draft-malinen-mobileip-regreg6-01.txt

Hi,
 
Probably the problem is related to the difficulty of mobility management
without introducing global per-host routing.
Of course no one is proposing global per-host routing. 
[Morrow, Glenn ] RR is doing per-host routing at the edge on select routers,
some of which are at possibly remoted arbitrary points. My point was that
you could easily tunnel over stupid legacy routers with simple routing
policies in order to achieve this arbitrary point without having to change
MIP at all.
 
Actually the solutions suggested in Mobile IP and Mobile IP Regional
Registration are based on tunneling.
[Morrow, Glenn ] Yes and that's why I really don't see a need to alter MIP
to handle it as routing policy and tunneling can handle the arbitrary point
issue, already. 
And now one of the issues is how to manage/control the tunnels very well.
[Morrow, Glenn ] I believe routing policy combined with tunnels is an
already existing method to archive the arbitrary point given the scope of
the solution set. We also do not have to change the protocol.
If you are concerned about the single point of failure introduced by Mobile
IP Regional Registration, our I-D might be worth reading since we tried to
propose a solution to relieve the problem of single point of failure while
keeping the advantages of regional registration.
Our I-D is available at the following URL for now:
 
<http://www.comet.columbia.edu/~eunsoo/paper/draft-shim-mobileip-reliable-re
g-00.txt>
http://www.comet.columbia.edu/~eunsoo/paper/draft-shim-mobileip-reliable-reg
-00.txt
 
<http://www.comet.columbia.edu/~eunsoo/paper/draft-shim-mobileip-reliable-re
g-00.pdf>
http://www.comet.columbia.edu/~eunsoo/paper/draft-shim-mobileip-reliable-reg
-00.pdf

[Morrow, Glenn ] 
This is a regurgitation of a router redundancy scheme applied to the RR
functionality - earthshattering, indeed.

Thanks.

Eunsoo

----- Original Message ----- 
From: Glenn Morrow <mailto:[email-masked]>  
To: [email-masked] <mailto:[email-masked]>  
Sent: Friday, March 09, 2001 2:39 PM
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]
<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
<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 <http://www.ietf.org/shadow.html>  
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
<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.

---

From: "Glenn Morrow" <[email-masked]>
Date: Mon, 12 Mar 2001 14:18:22 -0600

I wish to strike this caustic sentence from the last mail. It is not
productive.

"RR is nothing more than an IP proxy using MIP signaling to provision it."

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Mon, 12 Mar 2001 21:36:59 +0100

> > 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.
> 
> I think that the MAP would qualify as a single point of failure.
> 
	=> That's true. Just like a HA does.
	However, forcing a static (hidden) hierarchy between the MAP
	and the MN is much less robust, and introduces more single 
	points of failure for no foreseen gain.

> I also think that we need to avoid restricting the solution to work only
> with a single point of failure.  
> 
	=> I agree that some redundancy work is needed for MAPs
	and HAs. I was intending on starting that after San Diego
	but this meeting just came too quickly :)

> It would be nice to have a more general
> solution that doesn't make the mobile node learn all the relevant
> topology.
> 
	=> Is there a solution today that requires the MN's knowledge
	of the topology ? I think all the current drafts within the group
	avoid that. Unless I missed something ?
	Certainly HMIPv6 and the fast handover work in both design
	teams do avoid such knowledge.

> 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.
> 
	=> I can't speak on behalf of Glenn, but my understanding of his mail
	was that he didn't like the connection (circuit) oriented approach
	in the draft in question (the subject of this mail). To be specific
	there is essentially a circuit between the GMA and the AR that 
	the MN is connected to. The path of traffic is forced and a failure
	of any of these mobility agents along the path would kill the entire
	path. That is what I referred to in my mail.

	Regards,
	Hesham

---

From: "Glenn Morrow" <[email-masked]>
Date: Tue, 13 Mar 2001 09:11:54 -0600

Eunsoo,
 
In regards to your draft, thank you for taking the time to detail this
functionality. Anyone who takes the time to contribute to the IETF should be
commended. I believe your draft actually illustrates many of the problematic
issues that will occur with the RR solution as is. While I believe your work
is sound and well thought out, I am hoping that we can arrive at a solution
that is less complicated and more naturally self repairing at the IP layer.
I do not believe we have the same "already deployed" limitations with IPv6
that we had with IPv4 at this time. I am hoping we can use this to our
advantage.
 
Thanks,
 
Glenn

---

From: "Glenn Morrow" <[email-masked]>
Date: Tue, 13 Mar 2001 09:29:34 -0600

Charlie,

Here are my concerns, founded or not.

It seems to me that we might be able to work out a network layer that can
provide the RR benefits yet deal with multiple paths into and out of any
network without having to pick a single arbitrary point for reverse traffic.
I.e. for one stream the mobile might use one GFA while for another stream
the mobile might use another most optimal GFA.

I know the mechanics of this solution will cause more per-host routes in the
local domain per mobile but I believe it may be more route optimal, more
self-repairing and leverage any existing routing policy the network provider
may have.

I also do not relish the thought of having to send double binding updates -
one for the regional and one for the CN's and Home Subnets. It seems to me
that the mobile shouldn't even need to be aware that this function is
happening.

In regards to these connection oriented methods CoS and bandwidth
management. They are more stateful and we should avoid state when we can;
however, these mechanism have and should continue to be designed to repair
themselves based upon topological changes. As they are designed today, these
healing mechanisms do not interfere with routing policy. 

This leads us to my concern that RR in IPv6, as it is, may greatly
complicate these existing and even newly proposed methods of signaling and
accounting for CoS and bandwidth, not to mention traffic engineering and the
ability of providers to control routing policy. I see RR as it stands now as
a new routing protocol that will likely interfere with any routing policy
controlled with say OSPF.

Do you believe there is a mechanism to have the AR's, crossovers and GFA's
up to an arbitrary tier intercept or be sent the regular binding updates,
yet still have the BU's propogate to the CN's? 

What new problems would these new mechanics create in your opinion? 

Do you believe we should spend some time to explore these methods, even if
it means changing something about MIPv6?

My last comment is that I apologize for any caustic statements I may have
made in my previous mails. I should have been more clear, to the exact
points and constructive.

Thanks,

Glenn

-----Original Message-----
From: Charlie Perkins [mailto:[email-masked]]
Sent: Monday, March 12, 2001 1:28 PM
To: Morrow, Glenn [RICH2:C330:EXCH]
Cc: [email-masked]
Subject: Re: [mobile-ip] FW: I-D

Hello Glenn,

> 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.

I'm not sure what the connection is between these two clauses.
Any sort of localized registration is supposed to hide changes of
the care-of address.  The mobile node can consent to such hiding.
Maybe there is something else about our protocol that looks like
an intent to destroy the connectionless nature of IP.  Could you
please be a little more specific about your concerns here?

If I may guess that the mobile node has to keep track of more
network state (what one might call "connection state") then I guess
you would prefer to minimize that.  On this we can agree.  Then
the discussion should center on ways that state is gratuitously
set up as a protocol requirement, and make the tradeoffs.

> 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.

We basically attempted to do exactly what you suggest, by
allowing an anycast address to be used by the mobile node
for the purposes of making regional registrations.  However,
there may be other solutions that have even less connection
state required.  I agree that getting rid of single points of failure
is a good idea.

> 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?

I have not at all given up on it.  Some things seem to be "connection-
oriented" -- say, for instance, header compression state or QoS.
Connectionless has universal appeal because of its simplicity and
typically good-enough performance.  I think that regionalized
registrations lies more on the connectionless side, and that we
should aim to make it as connectionless as possible, while still
making it possible.

Regards,
Charlie P.

---

From: "Glenn Morrow" <[email-masked]>
Date: Tue, 13 Mar 2001 10:07:24 -0600

Charlie,

Thank You - you have hit it on the head. I am hoping we can use the existing
MIP BU's that eventually end up at the CN's. We need to figure out how to
get the local domain routers in the loop of this signaling. The ideas that
come to mind do require changes to the basic MIPv6, though. I'm not sure if
people are willing to consider changes to it.

Thanks,

Glenn

and I apologize again.

-----Original Message-----
From: Charlie Perkins [mailto:[email-masked]]
Sent: Monday, March 12, 2001 1:36 PM
To: Hesham Soliman (EPA)
Cc: [email-masked]
Subject: Re: [mobile-ip] FW: I-D

Hello Hesham,

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: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 14 Mar 2001 18:46:25 +0100

Glenn,

> I hope my response to Charlie's query clears up what I was trying to say technically.  
> 
	=> Yes it did and it gave me a chance to mention my concerns.

> I am hoping that we can all work together to come up with the best solution possible as a team; however, my stupid euphamisms have probably reduced any chances of that now. 
> 
	=> Not at all.

> There are merits to both RR and HMIP. As we move forward, we should try to get the best of both worlds. 
> 
	=> Absolutely, I think we've put in 99% (leaving 1% just in case) 
	of the comments e received. You can see that we received lots
	of comments by reading the ACK section :)
	So we welcome any suggestions that will improve the draft's
	quality. 

	Cheers,
	Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 15 Mar 2001 20:35:41 +0100

> Or regreg6 configurator can freely decide on the number of hierarchy
> levels according to his needs, including having one only. And, I
> do not believe it impossible to have dynamic configuration option
> for regreg6, it is something extra to natural routing, but doable.
> 
	=> Great, but that makes it like HMIPv6, so where is 
	the advantage ? apart from a different name :)

> In fact, having some redundancy in mobility binding state in the
> hierarchy may help reconstructing the state once a regional router
> goes down. Once a MAP goes down, you'll need some effort to set
> up those forwarding entries to the tunnels for mobile nodes under it.
> 
	=> What happens when a GMA goes down ? A GMA is very similar
	to an Extended mode MAP, so I don't see the redundancy
	argument valid.

	BTW, you claim redundancy in the hierarchy when using 
	Regional, how does that happen ? Anycast (if it works)
	does not give you redundancy since the BU will be received
	by _one_ router. 
	Furthermore, what is the point in providing a redundant hierarchy
	if the GMA is a single point of failure ?

> Simply moving the regional CoAs to anothe box is not enough. 
> 
	=> Why ?

> In a
> scalable solution, I do not believe timeout and full re-registration
> in every case for every mobile node is all that can be done, either.
> 
	=> You don't need re-registration in the basic mode case. The 
	connections will remain unscathed. That is provided we do
	have a redundancy protocol.

> > So far I haven't heard *any* reason for it [multiple levels of hierarchy].
> 
> Consider the following: Some users of a localized mobility scheme
> consider bandwidth of the last mile a very precious resource.
> They may also envision that the number of mobile nodes can be
> very large. In fact, so large that one MAP box is not enough to
> handle the signaling load of a visite domain.
> 
	=> We can support several MAPs in the visited domain. Does 
	the current HMIPv6 draft restrict that ? If so please let us 
	know where, because it shouldn't.

> Suppose the last mile is so precious that we can't use but one
> RCoA/MAP option on the router advertisement. How would the
> load balancing with MAP work? 
> 
	=> I don't see that BW argument as valid at all. You can 
	have more than one option in the RA. RAs are not meant 
	to be sent very frequently in HMIPv6, please refer to the Fast 
	Handoffs draft where RAs are sent when the MN is about to 
	move. 
	Load balancing still works regardless of how many options 
	are advertised. It is done from the same MAP. Or are 
	you referring to load sharing between MAPs ?

> If we can distribute load to more than one box by
> maintaining e.g. one level of lower routers, locality of movement
> naturally brings location update signaling load down to other
> boxes from a GMA. When simultaneously increasing the number of
> mobile nodes, I believe the signaling difference becomes
> significant.
> 
	=> I don't see any difference here. In fact, restricting the solution
	to one GMA in reg registration is very unscalable and requires
	a big expensive router with extra cost for reliability. 

	Regards,
	Hesham