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

From: Gerardo Giaretta <[email-masked]>
Date: Mon, 24 Oct 2005 18:55:13 +0200

> > => IMHO load balancing should not be provided by a DHAAD mechanism
> > but by HA assignment or HA-switch.
> 
> I agree that HA-switch is needed (not only for load balancing), but if
> an DHAAD mechanism already supports load balancing, signaling overhead
> and delay can be saved by skipping a subsequent HA-switch. If MNs
> frequently bootstrap with new HAs (e.g., when always using local HAs),
> the saved signaling overhead and delay might be significant. 
> 

I agree that HA switch may have large signaling overhead. However, as
said in my previous post I think it is quite difficult to achieve load
balancing in spit scenario during HA discovery if we rule out DHAAD. In
integrated scenario, the issue may be less tricky.

--Gerardo

> >    Wouldn't it be possible to integrate HA discovery and 
> > assignment somehow
> >    in an IKEv2 exchange,
> > 
> > => this is the Security Gateway discovery issue. It is in the scope
> > of the IPsec WG but I am afraid we should not wait for a solution
> > from them, on another hand it has to be secure and IPsec people
> > should be better...
> > 
> >    similar as HoA assignment is integrated in IKE
> >    exchange in the bootstrapping solution? E.g., the first 
> IKE message
> >    (IKE_SA_INIT) sent by MN would have anycast address as 
> destination
> >    address (reply and all other IKE messages use unicast 
> addresses as
> >    source/destination) and the Configuration Payload in the 
> > IKE_AUTH may
> >    contain an HA address for assignment to MN (only used if 
> > the HA that
> >    received the anycast IKE_SA_INIT shall not be used, e.g., 
> > because this
> >    HA is overloaded). 
> >    
> > => note this is in fact Security Gateway assignment.
> 
> o.k., good to know. That sounds like an efficient (low signaling
> overhead+load balancing support) and secure HA discovery/assignment
> mechanism, but unfortunately it is not yet available.
> 
> >    > - AFIK, there is no way currently standardized to 
> securely update
> >    > anycast routing except to manually insert host routes 
> > into the subnet
> >    > router handling the anycast address. So maintaining an 
> > anycast address
> >    > would require extra maintenance effort, manually inserting and
> >    deleting
> >    > the routes when HAs are added or deleted.
> >    
> >    Interesting point, but isn't such a mechnism needed for 
> almost all
> >    anycast-based protocols? I.e., isn't there a need for such a
> >    standardized mechanism anyway?
> >    
> > => no, the anycast-based protocols are request/reply protocols so
> > they don't need responder stability.
> 
> Yes, but I think James point was that the subnet routers have to know
> which hosts have configured which anycast addresses. RFC1546 (page 5)
> discusses some possible solutions and proposes to advertise configured
> anycast addresses to routers by using multicast (possibly with an
> enhanced IGMP):
> 
> "Hosts which wish to receive datagrams for a particular anycast
>    address will have to advertise to routers that they have joined the
>    anycast address.  On shared media networks, the best mechanism is
>    probably for a host to periodically multicast information about the
>    anycast addresses it supports (possibly using an enhanced 
> version of
>    IGMP).  The multicast messages ensure that any routers on 
> the network
>    hear that the anycast address is supported on the local subnet and
>    can advertise that fact (if appropriate) to neighboring routers.
>    Note that if there are no routers on the subnet, the multicast
>    messages would simply simply ignored.  (The multicasting 
> approach is
>    suggested because it seems likely to be simpler and more reliable
>    than developing a registration protocol, in which an anycast server
>    must register itself with each router on its local network)."
> 
> After quickly searching for anycast in RFC3376, I guess IGMP doesn't
> support that.
> 
> 
> Regards,
> 
> Kilian
> 
> 
> _______________________________________________
> Mip6 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mip6
> 

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: Mon, 24 Oct 2005 20:40:22 +0200

> integrated scenario, the issue may be less tricky.

Assume for a moment that RFC 3775 DHAAD had no issue with using IPsec
and that anycast implementation were deployed, dynamic update of routes
such that anycast really works.

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.

Alex

---

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

In your previous mail you wrote:

=> my concern is the last "to switch" is in fact "to select".
Without good ideas of real world conditions we can't decide:
 - whether the 'load balancing' in the bootstrapping phase is enough
 - what is the level of 'reactivity' needed to provide this 'load
   balancing', in particular whether the DNS SRV RR mechanism is
   reactive enough (cf RFC 2782 which warns against dynamic weights
   but explains the difference between priorities+weights and precedences)
The only positive thing is the DNS SRV RR mechanism is already heavily
used so it can be considered as mature (i.e., we know where we are going
if we adopt it).
So I propose to close this thread about 'load balancing'.

Regards

[email-masked]

PS: if someone knows (or has a free student who can write) a
theorical or operational report about DNS SRV RR weights
I am interested.