Bob, Thanks for pointing that out. Actually Dave already mentioned that to me during discussion. The destination address only based load balance will much better. As I also memtioned to him, that sometimes this approach still has a problem due to server load balances. For example, picture a network below: a FTP server farm protected a firewall, and a FTP client also behind its firewall and there are multiple firewalls in different locations to pretect the corporate of the client is in. If the client is doing destination load balance, it may use different corporate firewall as exit point for FTP data channels. This is because FTP server can tell its client to use different server for data channels. This still poses big challenge today.
As I said, I am not completely oppose to load balance. It cab be very benificial . The problem is the "MUST NOT" keyword. At end of the day, the admin should have control whether or to use load balance to its network's benefit, pretty much like ECMP support on the today's router. ECMP by default is turn on in some vendor's routers. But it offers an option to do it differently (packet based or flow based, or whatever) or compeltely turn it off. Another question I have is why it has to be "MUST NOT". If it is because of security, it may be rational. If for performance, it is a little too much. As Pekka pointed out, who knows better than Admin about the network performance/bottleneck? Definitely, not protocol designers. Thanks of taking this into consideration. We just need to make a more thoughtful decision. Changming -----Original Message----- From: Bob Hinden To: Changming Liu Cc: [EMAIL PROTECTED] Sent: 3/3/2004 5:48 PM Subject: RE: v6 host load balancing 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 PROTECTED] >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 PROTECTED] >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
