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

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

Hi Francis, 

>    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. 
>    
> => there is no such "load condition" defined in RFC 3775...

RFC3775 says:

	"...the sending home agent MAY
      dynamically set the Home Agent Preference value, for example
      basing it on the number of mobile nodes it is currently serving or
      on its remaining resources for serving additional mobile nodes;
	such dynamic settings are beyond the scope of this document."

Since the preference value is needed for ordering HAs on the *same link*
only,
my thinking was that an MSP could configure its HAs to use an arbitrary
function for 
dynamic preference value calculation (e.g., based on load conditions).

> 
>    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
> 
> => DNS has caching so is more efficient in term of delays.
> For the signaling DNS and ICMP are at the same order.

I think this is a misunderstanding. I didn't mean the signaling delay
for DNS/DHAAD request/reply. I agree that they should be in the same
order.
I meant that delay and signaling overhead can be reduced if
the HA discovery/assignment is intergrated in IKE exchange that is
needed for bootstrapping anyway, e.g., the anycast IKE_SA_INIT is
replied by 
the HA with the lowest load (would require co-ordination between HAs)

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

see above

> 
>    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
> 
> => you have to prove this 'load balancing' is not an illusion.

As I said in a previous mail, I agree with you that it depends on 
the "real world" conditions/requirements on load balancing.

> 
>    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.
>    
> => IMHO assignment is better but it can't be proposed as a general
> mechanism today.
> 
>    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).
>    
> => 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.
> 

I think Alex had the same comment. I think we had a different
understanding 
of the term HA-switch. For me, the HA-switch mechanism includes
switching the HAs.
If the HA crashes, the MN has to detect the HA unavalability by itself
and 
trigger the HA-switch mechanism (i.e., bootstrap with new HA).

>    > > 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). 
>    
> => no, DNSSEC provides its own security and needs no SA, in particular
> in this case.

You are right, but you still need an additional SA to the assignment
entity.

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

o.k.

Regards,

Kilian

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

---

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

RFC3775 says:

=> there is a large difference between a parameter which MAY be derived
from load condition and a load condition field in a message.

   
=> so you compare with a potential mechanism about we have no details...
I still believe caching will always give an advantage to DNS, i.e.,
the DNS cache should be closer than the HA in the common case.

   I think Alex had the same comment. I think we had a different
   understanding of the term HA-switch.

=> for me HA-switch is the mechanism described in
draft-haley-mip6-ha-switch-00.txt. Obviously a HA can't crash
and after send HA-switch messages.

=> this is HA reselection.
   
Regards