Re: WGLC on the design draft
Francis Dupont <[email protected]> Thu, 05 Jan 2006 22:47:56 +0100
| Newsgroups | gmane.ietf.mobike |
|---|---|
| Message-ID | <[email protected]> |
In your previous mail you wrote:
> 6.3. Message presentation
>
> ...
> Load balancing is currently outside the scope of MOBIKE, however
>
> => as you shot in your feet with the non standard definition of load
> balancing now you are in trouble because you still don't want the real
> load balancing (multiple addresses in the same SA at the same time)
> but want the thing in the middle (one address per SA but different
> addresses in SAs and/or in time).
i am not sure what exactly you would like to have changed.
could you please elaborate a bit?
=> IMHO the problem is simple: there are 3 definitions of load balancing:
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)
Section 6.3 one which is not really described.
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.
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.
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).
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.
Regards
[email protected]