Subject: RE: [Mip6] draft-dupont-mip6-dhaadharmful-00.txt

From: "Kilian Weniger" <[email-masked]>
Date: Tue, 25 Oct 2005 10:24:42 +0200

> Would then RFC 3775 DHAAD provide 'load balancing'?
>
> I'm asking because I think it is not at all clear for everyone what
> 'load balancing' is and how MIP6 is concerned by load balancing.
> My own take on this is that even if RFC 3775 worked it wouldn't
provide
> 'load balancing' per se.  But, if the HAs co-ordinated themselves
> somehow with some existing load balancing protocol then load balancing
> would be achieved, because the HA list provided in DHAAD Reply and the
> HA list used by MN would allow MN to switch towards wherever the load
is
> minimal.

Yes, some co-ordination between HAs on the home link is required to
provide dynamic load balancing. I think this can already be achieved
with DHAAD as defined in RFC3775 by including load condition in the Home
Agent Information Option in Ras. 

> As pointed out in draft-ietf-mip6-bootstrapping-split-01, DNS-based HA
> discovery may be used only to achieve coarse-grained load balancing by
> dynamically updating the SRV RR priorities. On the other hand, DHAAD
> cannot be used to load balance using different HAs in 
> different subnet.

I agree, RFC3775 DHAAD cannot provide load balancing between different
HAs on different subnets. Besides the minimal pre-configuration, this is
an advantage of the DNS-based discovery. But I think anycast-based HA
discovery has advantages as well, e.g., it can support fine-grained load
balancing and can decrease delay and signaling overhead during
bootstrapping. Maybe a combination might become a good solution, e.g.,

1. The MN gets an HA prefix with the DNS-based discovery mechanism (as
defined in bootstrapping solution). This minimizes the pre-configuration
of the MN and can achieve (coarse-grained) load balancing between HAs of
different subnets.

2. The MN starts anycast-based HA discovery (not necessarily as defined
in RFC3775) using the discovered HA prefix to get the HA address. This
can support fine-grained load balancing between HAs on the same link and
thus results in fast and efficient HA discovery (since subsequent HA
re-assignment for load balancing is not necessarily required). A
possible secure and efficient method could be the IKE Security Gateway
discovery/assignment mechanism mentioned by Francis.

3. When load conditions change dramatically or the HA crashs, the MN
changes its HA using an HA-switch mechanism (this mechanism could also
provide an optional fine-grained load balancing between HAs of different
subnets).

> > So, why this HA - the one assigning the right HA - needs to 
> > have HA functionality?
> > 
> It doesn't. It would be a light-weight "HA assigning entity" - but it
> may very well be a logical entity collocated with the HA. 

IMHO, a separate assignment entity would be possible, but it would
probably increase signaling overhead and delay, because the MN has to
establish another SA during bootstrapping (one to DNS, one to the
assignment entity and finally one to the assigned HA). 

Regards,

Kilian

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 25 Oct 2005 11:52:43 +0200

Kilian Weniger wrote:

>> somehow with some existing load balancing protocol then load
>> balancing would be achieved, because the HA list provided in DHAAD
>> Reply and the HA list used by MN would allow MN to switch towards
>> wherever the load
> 
> is
> 
>> minimal.
> 
> 
> with DHAAD as defined in RFC3775 by including load condition in the
> Home Agent Information Option in Ras.

I agree, a HA may convert its load condition into a combination of HA
Preference and Lifetime sent in the RAs.  Every other HA receives this
RA, so they could collectively build a common ordered HA list.  One of
the HAs sends it to the MN.

The 'conversion' part the HA that would convert its load condition
into Preference and Lifetime is not specified though.

>> As pointed out in draft-ietf-mip6-bootstrapping-split-01, DNS-based
>> HA discovery may be used only to achieve coarse-grained load
>> balancing by dynamically updating the SRV RR priorities. On the
>> other hand, DHAAD cannot be used to load balance using different
>> HAs in different subnet.
> 
> I agree, RFC3775 DHAAD cannot provide load balancing between
> different HAs on different subnets.

I think it is impossible to provide load balancing between different HAs
on different subnets while maintaining a permanent Home Address for the
Mobile Node.

Initial assignment of a less loaded HA from a different subnet, together
with a different HoA, is possible though.

And this latter thing could be approximately achieved with DHAAD:
pre-configure two different subnet prefixes on the MN, let MN do DHAAD
once for each home subnet, and let MN choose one of the HAs.

> Besides the minimal pre-configuration, this is an advantage of the
> DNS-based discovery. But I think anycast-based HA discovery has
> advantages as well, e.g., it can support fine-grained load balancing
> and can decrease delay and signaling overhead during bootstrapping.
> Maybe a combination might become a good solution, e.g.,
> 
> 1. The MN gets an HA prefix with the DNS-based discovery mechanism
> (as defined in bootstrapping solution). This minimizes the
> pre-configuration of the MN and can achieve (coarse-grained) load
> balancing between HAs of different subnets.
> 
> 2. The MN starts anycast-based HA discovery (not necessarily as
> defined in RFC3775) using the discovered HA prefix to get the HA
> address. This can support fine-grained load balancing between HAs on
> the same link and thus results in fast and efficient HA discovery
> (since subsequent HA re-assignment for load balancing is not
> necessarily required). A possible secure and efficient method could
> be the IKE Security Gateway discovery/assignment mechanism mentioned
> by Francis.
> 
> changes its HA using an HA-switch mechanism (this mechanism could
> also provide an optional fine-grained load balancing between HAs of
> different subnets).

This looks like a good overall picture combining all the stuff together.
 It has some good parts, IMHO.

Alex

---

From: Francis Dupont <[email-masked]>
Date: Tue, 25 Oct 2005 16:19:27 +0200

In your previous mail you wrote:

=> there is no such "load condition" defined in RFC 3775...

=> DNS has caching so is more efficient in term of delays.
For the signaling DNS and ICMP are at the same order.

   

=> if you'd like to provide a two phase mechanism (which should not be
low delay and without signaling overhead :-) you should NOT use anycast
addresses as they have only drawbacks at this stage.

=> you have to prove this 'load balancing' is not an illusion.

=> IMHO assignment is better but it can't be proposed as a general
mechanism today.

=> HA-switch doesn't work when the HA becomes unavailable, it works only
when the HA knows it will become unavailable or when another HA is far
better.

   
=> no, DNSSEC provides its own security and needs no SA, in particular
in this case.

Regards

[email-masked]

PS: I believe that without concrete numbers showing a dynamic load
balancing at the bootstrapping phase is needed with its characterics,
in particular the time scale, we are looping. So again I propose
to close the 'load balancing' question.