Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer

[Geoff Huston <[e-mail]>]

It might be useful to appreciate how load balancers are actually used in the public Internet before quoting RFC and drafts at each other. A good starting point is https://www.cmand.org/workshops/202006-v6/slides/cunha.pdf which describes recent work by UFMG’s Italo Cunha.



> On 27 Jul 2020, at 7:47 pm, Mark Smith <[e-mail]> wrote:
> 
> Hi,
> 
> If load balancers are going to be discussed, it also needs to be pointed out that they don't follow the definition of unicast addresses.
> 
> A unicast address is to uniquely identify a single node.
> 
> Load balancers share a single unicast address between multiple nodes, contradictory to the unique and single node identification purpose of unicast addresses.
> 
> That is why they need to do non-RFC compliant things like digging into transport layer headers to work with unicast protocols like UDP, TCP and ICMP, trying to make them work across a fleet of nodes sharing a single unicast address.
> 
> An anycast address, combined with a multi-path transport layer protocol is the way to do service load balancing in an RFC compliant way.
> 
> See Section 5.7.7 of this draft for how.
> 
> https://tools.ietf.org/html/draft-smith-6man-form-func-anycast-addresses-01#section-5.7.7
> 
> Regards,
> Mark.
> 
> 
> On Mon, 27 Jul 2020, 19:08 Vasilenko Eduard, <[e-mail]> wrote:
> Hi Fernando,
> Hence again, following the logic of this draft (the level of detalization that you have given to 5.1) - may be you need additional section 5.1.x: Load Balancer have to look into TCP/UDP ports. Moreover, it could not trust "Flow label" - it is not reliable practice for LB.
> Or alternatively you could say something about LB in section 5.1.2, but because it is a little special case - may be better to have separate 5.1.x
> 
> Eduard