Joel M. Halpern <[email protected]> wrote: > I suspect that for most GRASP purposes, even if there is a layer 2 network > between the parties, we are not much worried about how LAG handles GRASP > packets? If we care about that, then the source port should be randomized > between flows, and stable for sequences of related messages.
The idea being that the different 5-tuples would wind up on different links of the LAG, correct? Brian E Carpenter <[email protected]> wrote: > I think we don't care, because GRASP traffic density should be quite > modest so load balancing isn't really an issue. In response to Michael, > I don't think the source port matters at all for M_FLOOD messages. My > code uses the o/s default, but it has no significance to the > recipient. I agree with Brian: the DULL message is basically just a probe sent every few seconds. The bulk traffic would run over IPsec, so there will be an ESP SPI#. How would a LAG flow balancer deal with that? I don't think it would balance at all unless two SAs were negotiated. I think that the flow header could also be tweaked in some kind of round robin fashion. But, if it's a MC-LAG, then the ACP really wants to see both chassis seperately. So it occurs to me that we could hack LACP rather than LLDP :-) It appears that it uses a specific multicast destination. -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
