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

From: Gerardo Giaretta <[email-masked]>
Date: Tue, 25 Oct 2005 15:06:23 +0200

Hi Kilian, 

please see some comments below...

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

A similar approach was discussed in the DT: the MN could get a HA prefix
via DNS and then perform DHAAD. However, we agreed that a pure DNS-based
mechanism is better and does not have security concerns as DHAAD. 

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

I would simplify the procedure a bit: get rid of DHAAD and use HA switch
when a HA re-assignment is needed for any reason (e.g. load balancing).

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

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to
[email-masked]. Thank you
====================================================================

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 25 Oct 2005 15:27:48 +0200

Gerardo Giaretta wrote:

>>> 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
>> 
>> wherever the load is
>>  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.
>> 
>> 
>>> 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.
>> 
> 
> 
> A similar approach was discussed in the DT: the MN could get a HA
> prefix via DNS and then perform DHAAD. However, we agreed that a pure
> DNS-based mechanism is better and does not have security concerns as
> DHAAD.
> 
> 
> 
>> 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).

Sorry Kilian, I forgot to say that when the current HA is overloaded or
crashes it has little chance to send the HA Switch message right?

> I would simplify the procedure a bit: get rid of DHAAD and use HA
> switch when a HA re-assignment is needed for any reason (e.g. load
> balancing).

Gerardo, a non-anycast yet-to-be-specified DHAAD together with MPD is
really simple bootstrapping, and in some cases even implemented.

Real simplification would be for the HA Switch message to be simplified
and just be used as a trigger that would make MN re-start the DHAAD
procedure to acquire the new HA.  For example, the HA Switch message
could be defined as just being extensible, and example of extension
could be list of HA Addresses that MN could use as hints; but still
recommend use DHAAD Req/Rep.  (DHAAD Reply contains a list of HAs.)

The HA Switch message could be used just like the 3775 Binding Refresh
Request message (sent by HA to MN to make it send a new BU).

It could also be used just like DHCPv6 "Reconfigure" message.

Alex

---

From: Francis Dupont <[email-masked]>
Date: Tue, 25 Oct 2005 18:32:04 +0200

In your previous mail you wrote:

   Real simplification would be for the HA Switch message to be simplified
   and just be used as a trigger that would make MN re-start the DHAAD
   procedure to acquire the new HA.

=> it doesn't need to be simplified, I quote here the I-D:

   # of Addresses
 
     A 16-bit unsigned integer indicating the number of IPv6 home agent
     addresses in the message.  If set to zero, the mobile node MUST
     perform home agent discovery.

So it can already do what you want... (another reason to like it? :-)

Regards

[email-masked]

---

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

> So it can already do what you want... (another reason to like it? :-)

That's good, thanks for pointing it.  Is that "home agent discovery" DHAAD?

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 25 Oct 2005 16:12:30 -0700

> That's good, thanks for pointing it.  Is that "home agent discovery" DHAAD?

nope. it is whatever the mobile node is configured to
use for HA discovery. possible options include

1. DHAAD
2. DNS
3. https to some server
4. over the air provisiong
5. other proprietary mechanisms specific to each operator.

notice, I left out DHCPv6 because it is tied to access
authentication and can't be used whenever you want.

in general, there are way too many device management
mechanisms that enterprises and Operators use today.
any of them are candidates for HA assignment.

Vijay