Re: [trill] Thoughts on active-active edge

[Radia Perlman <[e-mail]>]

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.

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.

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.

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