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

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

> 
> Hesham brings up a key point here. Sure, it would of course be nice if
> backup HAs didn't have to be on the same link as the HA. But I don't
> see right off how you do that without introducing all kinds of
> complexity; you have to have some way of getting packets routed to the
> other HAs, and normal IP routing only knows how to deliver packets to
> the destination link.
> 
> So this is an example of where I think just talking about the
> requirement doesn't make sense. There has to also be a general idea
> (or "architecture" if you may) that explains how we can make this
> work, so that folks can decide whether the benefit justifies the cost.
> 

This is why we published the draft in such early stage... to check for
interest and trigger a discussion. Seems to be working :)

This discussion is actually at the core HAHA. MIPv6 implicitly requires
a Home subnet on a Home link: 
- the Binding Cache operates like an ARP/ND cache at delivery time
- the 'Hello' protocol between HAs is based on a ND extension. 
- so is the Binding uniqueness checking, which uses DAD. 

Since the workings of ND do not necessarily match the needs of MIP, this
lead to a bunch of issues in the past. Obviously, the bright side is a
lot of reuse of existing features, as opposed to developing... a HAHA
protocol. 

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. The point is that IP mobility can operate at
routing (L3) time as opposed to delivery (L2) time. An illustration of
that is the virtual home network in
http://www.ietf.org/internet-drafts/draft-thubert-nemo-basic-usages-00.t
xt 

Note that with Nemo basic support, Home is no more just a subnet, but
that it can be an aggregation. That aggregation can be advertised by
mobile points of presence (clusters of HAs with HAHA support) that are
scattered around the globe. 

An illustration of how this aggregation can be partitioned this is given
in appendix:

    +----------------------------------
    | +-------------+                    ^           ^
    | |  +-----+    |             ^      |           |
    | |  | MNP |    |             |      |           |
    | |  +-----+    |   HA        |      | cluster   |
    | |  +-----+    |   share     |      | share     |
    | |  | MNP |    |             |      |           |
    | |  +-----+    |             v      |           |
    | |  +-----+    |             ^      |           |
    | |  |     |    |             |      |           |
    | |  +-----+    |   HA        |      |           |
    | |  +-----+    |   share     |      |           |
    | |  |     |    |             |      |           |
    | |  +-----+    |             v      |           |
    | |             |                    |           |
    | | Local Home  |                    |           |
    | |   Network   |                    v           |
    | +-------------+                                |
    |                                                |
    | +-------------+                                |
    | |             |                                |
    | |  +-----+    |                                |
    | |  |     |    |                 global         |
    | |  +-----+    |                 Home           |
    | |             |                 Network        |
    | +-------------+                                |
    +---------------------------------               v

             Figure 5: Distributed Hierarchical Home Network  

The goal is that the routing fabric always leads a MN to the closest HA
cluster. A HA in that cluster could take the registration and share it
with the rest of the HAs in all the clusters. The goal here is to
partially optimize the path when the MN and its correspondent are in a
same locality, without bypassing the MRHA tunnel. 

Pascal

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

---

From: Soliman Hesham <[email-masked]>
Date: Thu, 6 Nov 2003 06:00:52 -0500

> 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)
2. How to replicate the HA functions across multiple
devices. 

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. 

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

Hesham

---

From: Soliman Hesham <[email-masked]>
Date: Fri, 7 Nov 2003 05:12:59 -0500

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

   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? 

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

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

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

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

Hesham