Re: WGLC on the design draft

 In your previous mail you wrote:

   >  IMHO the problem is simple: there are 3 definitions of load
   >  balancing:
   
   I do not agree that there is 3 definitions of load balancing. 
   
=> what you support and what I want are two different things and we use
the same name, so I don't understand why you disagree.

   >  Charter's one:
   >     o Load balancing. Multihoming is supported only in the sense of
   >       failing over to another interface; sending traffic over multiple
   >       addresses using the same SA is not supported.
   >  (note this is the commonly accepted one)
   > 
   >  Section 3.2 one:
   >        Note that MOBIKE does not aim to support load balancing between
   >        multiple IP addresses.  That is, each peer uses only one of the
   >        available IP addresses at a given point in time.
   >  (note this is a very limited, and IMHO too limited)
   
   I think those definitions are mostly same,

=> no, there are subtle but important differences (we should disagree
about the meaning of "mostly" too :-).

   the charter version does not say anything what happens with
   multiple SAs, thus it keeps that open.

=> yes, the charter is open, mostly because it has to address more
than the mobility problem...

   The charter definition still says that it is failing over to
   another interface, which means it will not use multiple interfaces at
   all, it uses one and if that fails, it fails over to another
   interface, using only that after that.
   
=> hum: "or to use multiple interfaces simultaenously"...
So I am afraid you assume too much about the charter says.

   > What I'd like is a *place* for the limited load balancing (which is not
   > commonly named load balancing outside the two current documents as it is
   > *not* covered by the charter limitation) where a SA uses one address at
   > one time but not all SAs use the same address.
   
   You can already do that.

=> yes, I can already manage mobility without Mobike too.

   It is in the protocol. Simply create multiple
   IKE SAs and each of them can use separate address. Each IPsec SA
   inside those IKE SA moves along with the IKE SA.
   
   So we already have that feature you are asking for.

=> no, I have no direct support of this feature.

   It is also described in the design document (last sentence of the
   section 5.3).
   
   > Now how to do this? 6.3 doesn't seem to be the right place because the text
   > is clearly about possible address lists when what is needed are SPI lists.
   
   6.3 is definately wrong place. The section 5.3 already talks about
   list of SPIs and also list of ranges of SPI values. 
   
=> but this text is not about proposing a solution but explaining why
the current proposal does nothing.

   > So I suggest to fix the text in 3.2 and does not say that MOBIKE but the
   > current design does not aim to support load balancing (keeping the same
   > definition).
   
   Load balancing in any forms is explicit non-goal for MOBIKE WG. The
   charter says that very clearly.
   
=> not in any form, only "sending traffic over multiple addresses
using the same SA is not supported".

   The charter also lists that multihoming is only supported to support
   failing over, not for other reasons. It also explictly says that
   using traffic over multiple address for same SA is outside the scope, but
   that does not mean it would be the only thing covered by load
   balancing.
   
   Load balancing in general is outside the scope of MOBIKE WG.
   
=> yes, and in fact multihoming too... (:-)

   > Note I am not the only person who can compare the design document and
   > the charter so IMHO this should be really addressed before the IETF last
   > call.
   
   I do not really find anything that would be conflicting between the
   charter and the design document about the load balancing. Both of them
   say load balancing is outside the scope of MOBIKE WG and the current
   protocols. 

=> I'll forward your message to the MONAMI6 people and we'll see if
your vision of multihoming is really compatible with the current work
in other WGs.

Regards

[email protected]