Re: [trill] Thoughts on active-active edge

[Sam Aldrin <[e-mail]>]

I agree with Mingui and Tissa on this.

Intentionally creating architecture change to have MAC move scenario is something not at all a good idea.
Also, reasoning that only edge or participating RBridges requires hardware changes is not a good argument for advantage either, because, that depends on topology and deployment scenario, not architecturally better.
Eventually, that change has to be on all RB's anyway, because of silicon and other changes.
I am more concerned the load balancing of the traffic, which is a potential issue, and cannot be ignored.

One point to consider with any solution is from OAM angle. Operationally, how this (any solution) could impact the behavior and the cost associated with this.

I believe we have discussed these scenarios (different solution types) previously. 
WG should reach consensus and move forward with the agreed solution. 
Atleast from the IETF WG sessions, I presumed there was a consensus on the solution. 
Am I wrong in that assumption?

cheers
-sam
On Dec 11, 2012, at 10:46 PM, Mingui Zhang <[e-mail]> wrote:

> 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
> 
> _______________________________________________
> trill mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/trill