Subject: RE: [Mip6] HAHA architecture was: Agenda for MIP6 at IETF58

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 6 Nov 2003 17:10:57 -0000

> 
> 
>  > Well, it is untrue that the IP mobility concept requires a 
>  > Home Subnet
>  > on a Home Link. 
>  > 
>  > What it needs is least one router that advertises Home (: 
>  > whatever that
>  > is :), attracting the packets for a group of MNs, and that 
>  > knows how and
>  > where to tunnel to these MN. There can actually be more 
> than one such  > point, as long as each one knows how to 
> tunnel to any given 
>  > MN, directly
>  > or via an other cluster. 
> 
> => Hmm. There are two issues here:
> 1. The location of the HAs wrt each other (i.e. on the 
> same link or not)

We want to allow the 'not' part :) Make it an L3 thing.

> 2. How to replicate the HA functions across multiple
> devices. 
> 

Yes, and we propose 3 approaches with different behaviours:
proactive, reactive and predictive. 
Depending on the approach, the relation between the primary HA and the
other HAs may be more like a proxy type (as HMIP) then a replication
thing. 
It may happen that the mechanism for High Availability (that we can
expect to be 'local', as you point out) is different from the mechanism
for geo distribution of HAs, we'll have to decide that. Maybe we can
leave full High Availability (HA, damn) to optional existing processes
such as HSRP or VRRP, as you mention, but gain some level of it by a
proxying process?

> In (1) above we need to understand the complexities involved
> in having an HA function replicated on a different link.
> I assume that if you use ND then you're assuming they
> exist on the same link. If that's the case, I wonder if we 
> can extend/reuse VRRP (IPR issues aside). 
> If you try to put HAs on multiple links, you're effectively 
> (from what you say above) making the HA's address look and 
> act like an anycast address. This leads us to point (2)
> above. 

You still think "HA on links" as opposed to Home networks. We are not
configuring a same address on several interfaces, making it anycast as
you point out. 
We are making 'Home' an aggregation of Home subnets and Mobile Networks.
And we are advertising that aggregation from several places. 
But the final subnets of that aggregation are still located in a unique
place, be they Mobile Links or Home Links (unless other tricks are being
played as part of an other game such as site replication).

The only time I mentioned anycast is for DHAAD purposes, as in MIP. If
several clusters advertise the same aggregation, a DHAAD request should
get to the closest cluster. 
But this may be stretching anycast a little bit? Since we expect anycast
addresses to be built after subnets, not aggregations, do we? Say we get
passed that issue.

Anyway at the end of DHAAD, we should have made it so that a MN gets a
list with HAs in teh closest cluster. So the MN would register to a
(primary) HA in a relatively close location. 

So in my mind, HAHA can be (among other things as Vijay mentioned)
either about finding who the primary HA is and tunnel (HA to HA) to it
(: which I tend to favor :), OR sharing the BCE info in all geographies,
which links to security issues and impacts on the MN, as you mentioned.
One way of envisionning the first possibility is:

- MN register to closest HA (primary HA)
- primary HA instanciates a MRHA tunnel and creates a route over that
tunnel to the MN (MNP) that is being registered
- primary HA redistributes that route to other HAs using HAHA protocol.
This is a proactive model where HAHA looks like a classical Routing
Protocol after all.

No binding caches, just routes. Now, we may want to distribute these
routes to remote clusters only on demand. Or we may have a predictable
HA that centralizes the registration for a set of MN and have the
primary act as a proxy to it. Very open at this point of time :) 

If there is a real Home Network for that MN, then the primary HA must
proactively either register to one of the Home Network HA in a proxy
fashion (not exactly HMIP, though, since it is transparent to the MN),
or sync the binding with it, in order for that HA to intercept packets
on the Home link. But supporting the Home Link is not necessarily a
priority here (we almost removed coming Home in MIPv6, right?)  

> 
> Anycast may work if you only take the narrow view of "HA 
> forwarding". But if you start to look at all the functions 
> performed by the HA, security becomes your enemy IMO :( 
> Anycast is fine if there is no dialogue going on. But if
> you're going to run a protocol between two points which 
> consists of more than one round trip (e.g. IKE) you're in 
> trouble. 
> 
> That's why VRRP (or something like it where two 
> routers share the link) seems like a good option because
> it allows for the standby to become active when needed
> (i.e. instead of being always active). 

Right. *For the high availability part*, it seems be good that the back
up be on a same link.
No the backing up can be transparent to the MN or not. It could be good
to be able to push a new HA to a MN in some circumstances, as is also
being proposed in MIP4.

Anyway the link between HAs backing up each other does not have to be a
Home link for MIP purposes, right?

Pascal

---

From: Ryuji Wakikawa<[email-masked]>
Date: Sat, 08 Nov 2003 04:03:16 +0900

Hi Alex

At Fri, 07 Nov 2003 19:44:14 +0100,
alex wrote:
> 
> "Pascal Thubert (pthubert)" <[email-masked]> writes:
> Could HAHA not only look but also act as a classical routing protocol?
> Could the HA's just exchange routing information instead of BCE sync
> messages?

Is NEMO basic a routing protocol? We do not mention where mobile
network prefix is recorded (i.e. in binding cache or routing table) in
the nemo basic draft. Prefix binding may be route information. HAHA is
same style as the NEMO basic support.

> If yes, then maybe the AR's to which MN attaches can also participate
> in this routing protocol exchanges and thus no need of Mobile IP at
> all, no?

Then, what's difference between MR and AR. 

ryuji

> Alex
> GBU
> 
> 
> _______________________________________________
> Mip6 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mip6

_______________________________________________
Mip6 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mip6

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 07 Nov 2003 20:53:40 +0100

Hi Ryuji,

Ryuji Wakikawa <[email-masked]> writes:
> network prefix is recorded (i.e. in binding cache or routing table)
> in the nemo basic draft.

Excellent idea to discuss about this ambiguity in the NEMO WG instead
(remark this ambiguity was the depart idea but then we did "forwarding
information" to stand for "routing table" in some places, but "routing
table" and "binding cache" still exist at places).

> HAHA is same style as the NEMO basic support.

Except that HAHA seems to raise other important architectural
questions for which few - if at all - answers seem to have surfaced.
I assume that there may be something else down the pipe coming from
members, and I just sit and watch for it to happen.  Namely, how will
routing get updated towards the new HA (the HAHA BC syncing does not
do it).

Also, would an MN switching a HAHA HA be relieved from doing RO to its
CN?

>> If yes, then maybe the AR's to which MN attaches can also
>> participate in this routing protocol exchanges and thus no need of
>> Mobile IP at all, no?
>

I would say here that MN moves and AR is fixed, no?

Alex
GBU