Subject: RE: v6 host load balancing

From: Bob Hinden <[email-masked]>
Date: Wed, 03 Mar 2004 17:48:29 -0800

Changming,

>As we talked this moning about this issue, we thought that it might be a
>good idea to discuss this in the mailing list so that others can express
>their opinion too.
>
>As one of the top 3 firewall/NAT/IDP vendors, our experience with load
>sharing is very bad. It's only good for router-switch only environment.
>For security gateways with any one of the functionalities as I mentioned
>above, it will create some poblem here or there. This is because it
>needs to see some consecutive packets, if not all, packets in the same
>flow (some applications need to see it in both directions) in order to
>do the correct ALG for NAT, deep packet inspection for idp, network
>based Anti-Virus, which we also start to do. I completely agree with
>your statement that "packet based randomized LS" is bad. For flow based
>LS, we need to be vey careful about the definition of "the flow". Some
>applications have different channels, such as control/signalling and
>data, like FTP, VOIP (H323 or SIP), packets belong to all these channels
>are better to belong to the same firewall, or some of the above
>functionality may break because it needs to deal with dynamic ports in
>either forward or backward directions.

I would agree with your concern if it worked that way.  The load balancing 
being proposed is not load balancing on a per packet basis.  It is load 
sharing when the host is about to pick a router when sending to a new 
destination.  Please reread this part of the neighbor discovery 
specification where it describes the conceptional algorithm for selecting a 
router.  All of the traffic from a host to the same destination will be 
sent to the same router.  Traffic to a different destination will be sent 
to a different router.  Firewalls and similar devices will not have any 
problem seeing flows.

Regards,
Bob

>The problem we have with the draft is the "MUST NOT" sent to the same
>router statement. At very minimum, it should be "SHOULD" to just leave
>an option for the host to turn it off if it deems necessary.
>
>Thanks for the chat on this topic this morning.
>
>Changming Liu
>Netsceen Technologies Inc.
>
>-----Original Message---
>From: Gregory M Lebovitz
>To: [email-masked]
>Cc: Changming Liu
>Sent: 3/2/2004 9:32 PM
>Subject: v6 host load balancing
>
>Dave,
>Was sitting in the v6 mtg yesterday, and quickly reviewed your doc on
>LB. I
>see some use cases, particularly involving state-keeping gateways, like
>FW
>and IPS devices, for which this is going to cause tremendous havoc.
>Could
>my co-worker, changming and I get together with you for a bit and
>discuss
>to see if we are accurate in our assessment?
>
>perhaps as the pm break today (at ietf reg desk) or for bfast tomorrow?
>
>Pls advise,
>Gregory.
>
>+++++++++++++++++++++++++
>IETF-related email from
>Gregory M. Lebovitz
>Architect - CTO Office
>NetScreen Technologies
>
>--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>[email-masked]
>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Thu, 4 Mar 2004 04:25:33 +0200 (EET)

On Wed, 3 Mar 2004, Bob Hinden wrote:
> destination. [...]

Note that Changming was also raising an issue of "flows" (using 
intentionally vague terminology).  Some classes of packets, which do 
not have the same destination address may belong together.  For 
example SIP data and SIP signalling.  Having them redistributed to 
other routers would be disadvantageous.

The same also apply to (rather small) extent in certain cases where
you check that an ICMP Destination Unreachable response is sent in 
response to a valid packet that the firewall has seen.   This is 
hampered in a few corner cases at least.

So, my point is that host-to-router load sharing works on the link, 
but is causing big problems further down in the network, e.g., in 
failure cases (some connections die and others don't: difficult to 
debug), firewalls, etc. -- without a good cause, if load sharing is 
not needed to well, share the load.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings