Re: [trill] Thoughts on active-active edge

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

Please see comments in-line

From: [e-mail] [mailto:[e-mail]] On Behalf Of Radia Perlman
Sent: Tuesday, December 11, 2012 12:53 PM
To: [e-mail]
Subject: [trill] Thoughts on active-active edge

I'm not too happy about any of the proposed solutions to the active-active edge issue, and wondering if there might be a simpler approach.

To review the problem:

Suppose R1, R2, and R3 are all attached to a set of endnodes (say, through a hypervisor).  Let's say "E" is one of the endnodes multihomed through R1, R2, R3.  Let's say "R8" is a distant RBridge (one several hops away from R1, R2, and R3).

a) If R1, R2, and R3 use their own nickname when encapsulating a frame from E, then R8 will see frequent changes of E's location (between R1, R2, and R3).  Furthermore, it would be nice if the path from R8 to E could go via the shortest path (if, for instance, R2 is much closer to R8 than R1).

b) If R1, R2, and R3 use a pseudonode nickname (say P) for all the multihomed endnodes, then the RPF check doesn't work when the "wrong" RBridge injects the encapsuated packet into the campus.  (the tree will have only one of R1, R2, or R3 attached to the pseudonode, say R2, so when R2 injects using the pseuodnode as ingress nickname, the RPF check will work, but it will not work if R1 or R3 inject).

--------------

So...this might have been discussed before, but it might not hurt to look at it with fresh eyes again.



*******************
Proposed rule: R1, R2, and R3 should use the pseudonode nickname when encapsulating unicast, but use their own nickname when encapsulating multidestination.
***********************

Result:  R8 will see endnode changes for E, but not very frequent;  R8 will only see changes when traffic from E alternates between multidestination and unicast.

[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.

Question: Are perceived endnode moves a problem?  Why?

[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.

If endnode changes are, for some reason, a problem, we could have R1, R2, and R3 announce in LSPs, that they are attached to pseudonode P as an active/active group, and therefore, endnode moves between P and anything in the set {R1, R2, R3} should not raise alarms.  Better yet, would be to say if endnode E is attached to P, then don't move it to {R1, R2, or R3}.

[Answer] This will complicate hardware learning. Or least need to re-do the hardware implementations different than today.

We discussed this approach many times with you before and the pain points are the same.

Radia