Re: [trill] Thoughts on active-active edge

[Mingui Zhang <[e-mail]>]

Hi,

I think the MAC move affects the path selection at the remote RBridge 'R8', which may bring frame disorder at the endnode 'E' connected to the active-active edge. 

The new proposal suggests that one group occupies one pseudo-node nickname. If "use up the nickname space" is really a problem, the new proposal suffers from this problem, right? Having said that, I want to argue that we have to identify each active-active edge with a pseudo-node nickname in either proposal AND the consumption of nicknames on active-active edge is not a big problem.

Thanks,
Mingui 

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf Of Tissa
>Senevirathne (tsenevir)
>Sent: Wednesday, December 12, 2012 2:11 PM
>To: Radia Perlman
>Cc: [e-mail]
>Subject: Re: [trill] Thoughts on active-active edge
>
>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