Re: [trill] Thoughts on active-active edge

["Tissa Senevirathne (tsenevir)" <[e-mail]>]

Radia

Please see in line

From: Radia Perlman [mailto:[e-mail]]
Sent: Tuesday, December 11, 2012 10:00 PM
To: Tissa Senevirathne (tsenevir)
Cc: [e-mail]
Subject: Re: [trill] Thoughts on active-active edge

Tissa, there are always technical tradeoffs between approaches.

Tissa said:
>>[Answer] This depends on the traffic Radia. You cannot assume all multicast hash to Node R1 and all unicast to >>R2 and R3 and hence multicast unicast address ping pong is rare. In the contrary, you could have heavy >>multicast stream and a unicast stream both hashing in to the same RBridge RB1.

I'm not sure what relevance there is to whether unicast hashes to R1, R2, R3, or alternates between them, since the rule is that they all use the pseudonode nickname when ingressing from E. The only way there will be frequent endnode moves for E is if E frequently alternates sending multicast and unicast.  All unicast from E, whether it is sent to R1, R2, or R3, will be perceived by R8 as coming from pseudonode P.  Multicast, on the other hand, with the proposed rule, could bounce between R1, R2, and R3.  Though as an optimization, if the pseudonode P is attached to R2, then R2 could use P when ingressing either unicast or multicast, so multicast that happens to hash to R2 will not be perceived as an endnode move, whereas multicast hashing to R1 or R3 would.


[Answer-2] Are you saying E will not simultaneously send multicast and unicast ? are you also suggesting there is either a single multicast stream or all multicast streams are hashing to the same RBridge that E is attached to ?

Tissa said about why endnode moves are a problem:

>>[Answer] Yes it is big time.  Unlike ancient devices modern devices to hardware based learning. When address >>association start moving, it will constantly bombard the CPU with new address or address move notifications.

Your description sounds to me like it's only a problem if there are a lot of moves.  Since it seems unlikely that E will keep alternating between sending multicast and unicast, or even if there were one node that was doing that for some reason, that there would be lots of nodes acting this way, it seems like the amount of moves seen, relative to the total amount of traffic received by R8, should be really small.

[Answer-2] It is not lots of switches it is how many ping-pong, with a single address and two stream you can overload learning buffers when traffic is coming at high rates.

So, the disadvantages of this proposal, as Sunny pointed out, are
1) the active-active RBs might need a hardware change in order to selectively use a different ingress nickname depending on whether the packet is multicast or unicast  (which implementations is this true for?)
2) distant RBs (say R8), will perceive E moving when E switches from sending unicast to multicast.

[Answer-2] #2 is exactly what I am saying as a big problem. But if you feel it is not a problem, I am not going to argue any further. You should speak to few more people and get the validation. ***Address move is a major problem**

But as I said, all approaches have pluses and minuses, so the minuses have to be weighed against the pluses.

The advantages of this proposed approach relative to the Affinity TLV are:

a) you only need one tree for the campus, and you can have arbitrarily many active-active nodes.  Or to put it a different way, you can have more active-active RBs than there are trees.

b) furthermore, it allows the active-active RBs to do load splitting of multicast (choosing more than one tree), without requiring n*k trees, where n is the number of active-active RBs, and k is the number of trees each might want to use for load splitting.

c) you don't need all RBs to change at once in the campus (as you would with the Affinity proposal).  If R8 is unmodified, R8 will see E changing when E changes from multicast to unicast, but will not have incorrect behavior.  With affinity, absolutely every RB in the campus must be modified or there will be incorrect (not just suboptimal) behavior.


Radia