Subject: RE: [Mip6] HAHA architecture

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 10 Nov 2003 20:35:58 -0000

> -----Original Message-----
> From: Soliman Hesham [mailto:[email-masked]]
> Sent: vendredi 7 novembre 2003 11:13
> To: Pascal Thubert (pthubert); Thomas Narten
> Cc: Vijay Devarapalli; [email-masked];
[email-masked]; [email-masked]
> Subject: RE: [Mip6] HAHA architecture was: Agenda for MIP6 at IETF58
> 
> 
>  > > 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.
> 
> => I'm not sure why you call them "High availability" and
> "geo distribution", which seems to imply that you can
> have one and not the other. In any case, see my comments
> below.
> 

Ryuji will discuss some of this this afternoon. Yes, I guess that it
could be a deployment thing to enable one or the other. 

>    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?
> 
> => What's the redundancy requirement for the proxying
> process?
> 
A proxy can serve local requests even if the original data is
temporarily offline. So can a secondary HA. I'm not sure what else we
can require past that (and whether I understood the question :)

>  > 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).
> 
> => So, in this scheme, is the HA's IP address (going back to
> basics ;) ) known to the MN and kept the same independently
> of which HA is serving the MN?
> 
Good point :)

For high availability, if you want to have a hot standby backup and
avoid to have all the MN rebind when a HA fails, you need that the
backup is able to serve the same address, in other words, they are on a
same link.

This is actually one of the good reasons why the handling of the
geographical distribution of HAs has better be a different mechanism.
Other reasons are the load on the WAN, the latency, the model (might be
reactive) etc...

>  >
>  > 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 :),
> 
> => So you're saying that the primary and the secondary
> have different IP addresses, right? And when the primary
> falls over, does the secondary "assume" the primary's IP
> address and state? Otherwise this process would not be seamless
> to the MN.
> 
> 
>    OR sharing the BCE info in all
>  > geographies,
>  > which links to security issues and impacts on the MN, as you
>  > mentioned.
> 
> => The security issues I mentioned are due to the use
> of anycast, not sharing BCEs.

Sure. Like I said, anycast is used for DHAAD only, and it does not have
to be secured.

> 
>  > 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?)
> 
> => Right. But, wow! Why are we doing all this again??
> I mean, do you see major advantages compared to just having
> the good old two routers back to back?
> This seems to be going back to Thomas' first question about
> how much complexity are we introducing and for how
> much gain. So far, I don't see a significant gain apart
> from doing the redundancy on L3.
> 
> But perhaps you're thinking of other scenarios (i.e. not just
> the obvious MN-HA case).
> 

One is virtual Home. Note, the authors do not have all the answers, we
have to design this thing together :) Where're opening a door that could
allow to operate MIP at L3, but all the issues (: and benefits :) are
not figured out yet. I believe that it's promising, though.

I wonder what HA fallback (take-over) becomes when a Home Link is
virtual. HAHA can be used to keep 2 HAs in sync, and then when one dies,
classically, the other takes over its Home address... on the virtual
link. On top of that, though, there needs to be Host routes updated on
the surrounding routers to say which HA owns which Address on the
virtual network so the packets from the MN gets to the right HA.

There's also the question of the granularity of the load balancing. Does
it make sense that the traffic for a given MN be load balanced between
HAs, or is the granularity the MN, or a subset of Home? How does that
impact HAHA, can it be only a deployment choice?

>  > Anyway the link between HAs backing up each other does not
>  > have to be a
>  > Home link for MIP purposes, right?
> 
> => It can be a virtual link, i.e. tunnel, sure. That is,
> if I understood your scheme correctly.
> 
Yes. Yes have in mind that you can have several locations, and in each
location, a pair of HAs for high availability of the location or more
than 2 if the scheme is load balancing. For instance, the 'sync' between
locations could be reactive or predictive, while the local sync could be
proactive. I believe we have to make sure that HAHA will provide all the
modes, up to the deployment.

The local pair of HAs could have a dedicated link for sync that does not
have to be the Home Link, so Home can be virtual.

This discussion requires a white board.

Pascal

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