Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

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

Mingui

 

Assuming everyone who need active-active forwarding will and willing to run multi-topology is like assuming all of us engineers are owning BMWs.

 

Joking aside what we need is a simple solution that works without intricacies of multi-topology. So your argument that we should drop CMT and just use multi-topology is very academic and will have some detrimental effect on adaptation of TRILL.

 

I rest my arguments with this.

 

Thanks

Tissa

 

From: Mingui Zhang [mailto:[e-mail]] 
Sent: Wednesday, March 28, 2012 6:35 AM
To: Rohit Watve (rwatve); Radia Perlman; Tissa Senevirathne (tsenevir)
Cc: [e-mail]
Subject: 答复: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

 

Hi Rohit，

 

Thanks for offering the complementary dimension. Yes, I agree that MT-TRILL requires new TLVs. But in case that MT is already supported by TRILL, this is not a Cons of MTRA any more.

 

For the Fast Converge dimension. CMT does need to "perform distribution tree assignment algorithm specified in section 5.1" to change the assignment of affinities of aggregated members when there is a failure. 

 

Thanks,

Mingui

________________________________

发件人: Rohit Watve (rwatve) [[e-mail]]
发送时间: 2012年3月28日 18:22
到: Mingui Zhang; Radia Perlman; Tissa Senevirathne (tsenevir)
Cc: [e-mail]
主题: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Mingui,

5. Fast convergence on failure recovery. We know that resilience is one of the two main purposes of "aggregation". This dimension discusses whether the solution offers a way to do fast failure recovery when there is a failure of an aggregated RBridge or link. 

PN: NO. The new distribution tree need to be recomputed.

CMT: NO. A overall re-configuration is necessary.

MTRA: YES.

CMT does not need reconfiguration. If one Rbridge advertizing affinity tlv goes down, the tree can be rooted at the other Egress Rbridge ID advertizing affinity tlv.

Also, consider adding following to the comparison table

Number of New TLVs (and resulting complexity)

PN: 3

CMT: 1

MTRA: multiple

Thanks
Rohit

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Mingui Zhang
Sent: Wednesday, March 28, 2012 2:10 AM
To: Radia Perlman; Tissa Senevirathne (tsenevir)
Cc: [e-mail]
Subject: 答复: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Radia,

It is a good idea to list the Pros and Cons of each solution. There are three candidate solutions for the same RPFC problem: PN, CMT and MTRA (Multi-Topology TRILL for RBridge Aggregation). Let me compare them in the following dimensions.

1. Whether the solution is incrementally deploy-able.

PN: YES.

CMT: NO.

MTRA: YES.

2. Use only existing silicons. 

PN: NO. New silicon is necessary to support "tunneling" or else MAC addresses may flip-flop.

CMT: YES.

MTRA: Currently NO. But after multi-topology is supported by TRILL, it is a "YES".

3. Multi-cast traffic up from RBv can be load-balanced.

PN: NO.

CMT: YES.

MTRA: YES.

4. Multi-cast traffic down to RBv can be load-balanced.

PN: NO.

CMT: YES.

MTRA: YES.

5. Fast convergence on failure recovery. We know that resilience is one of the two main purposes of "aggregation". This dimension discusses whether the solution offers a way to do fast failure recovery when there is a failure of an aggregated RBridge or link. 

PN: NO. The new distribution tree need to be recomputed.

CMT: NO. A overall re-configuration is necessary.

MTRA: YES. 

The following table lists all above comparisons (A jpg version is also attached just in case.). MTRA is always YES. I think it deserves our follow-up. 

+--------+------------+-----------+----------+------------+-------------+

|Solution|Incre-Deploy|Old Silicon|LB Upwards|LB Downwards|Fast Converge|

+--------+------------+-----------+----------+------------+-------------|

|PN      |YES         |NO         |NO        |NO          |NO           |

+--------+------------+-----------+----------+------------+-------------|

|CMT     |NO          |YES        |YES       |YES         |NO           |

+--------+------------+-----------+----------+------------+-------------|

|MTRA    |YES         |YES(will)  |YES       |YES         |YES          |

+--------+------------+-----------+----------+------------+-------------+

Thanks,

Mingui





发件人: [e-mail] [[e-mail]] 代表 Radia Perlman [[e-mail]]

发送时间: 2012年3月28日 12:52

到: Tissa Senevirathne (tsenevir)

Cc: [e-mail]

主题: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft










It is my understanding that

a) CMT does require changing all the RBs in the campus

b) CMT requires there be at least as many trees as there are active/active RBs on any link

 

Of course, no solution is ideal.  It might have been nice to write up all the proposed solutions to this and pros/cons. Maybe it's

still worth doing.

 

So from memory...other proposals for allowing R1, R2, and R3 to be active/active/active on a link:

 

First note: regardless of whether their port to the link is in a tree, unicast works, and they can use the pseudonode

nickname when encapsulating unicast.

 

Also, if Ri's port to the link is in at least one tree, Ri can use the pseudonode nickname for that link when encapsulating

multidestination frames for ingress, and the RPF check will work without any problems.

 

However, if Ri's port to the link is not in any of the trees,

here were some of the proposed solutions.  So, let's say that R1 and R2's port to the shared link is in at least one tree, and R3's

port to the link is not in any of the trees, and R3 needs to encapsulate a multidestination frame:

 

1) R3 could tunnel it to one of {R1, R2}, and let them inject the packet (with pseudonode nickname) into the campus.

 

Pro: Doesn't affect any RBs other than the ones on the link; backwards compatible.  Con: more hops, might be difficult

in some implementations for R3 to forward by tunneling, might be difficult for R2 to accept a tunneled packet.

 

2) R3 could use its own nickname instead of the pseudonode nickname in this case

 

Pro: Doesn't affect any RBs other than the ones on the link; backwards compatible.  Con: MAC learning in distant RBs will have

frequent learning changes of the source MAC S between being on the pseudonode nickname (whenever S sends unicast,

or multicast through R1 or R2), or being on R3 (when R3 has to encapsulate a multidestination frame from S).

 

------

There might have been some other proposals, but they wound up not to work.

 

Personally, I don't love the CMT thing because of the two disadvantages I mentioned above, but I can live with it.

 

Radia 

_______________________________________________
rbridge mailing list
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge