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

[[e-mail]]

Hi Jana

In my mind，Mingui Zhang has two drafs about Multi-topology for TRILL. I 
think he can give you a detail explanation about your question.

Thanks,
Zhai Hongjun
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 Protocol Development Dept.VI, Central R&D Institute, ZTE Corporation
 No. 68, Zijinghua Road, Yuhuatai District, Nanjing, P.R.China, 210012
 
 Zhai Hongjun
 
 Tel: [phone]
 Email: [e-mail]
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""





Janardhanan Pathangi Narasimhan <[e-mail]> 
发件人:  [e-mail]
2012-03-28 19:14

收件人
"Rohit Watve (rwatve)" <[e-mail]>, Mingui Zhang 
<[e-mail]>, Radia Perlman <[e-mail]>, "Tissa 
Senevirathne (tsenevir)" <[e-mail]>
抄送
"[e-mail]" <[e-mail]>
主题
Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft






Hi Zhai,
 
In the Multi-topology case I am not sure what is meant by incrementally 
deployable. Assuming that all the RBridges in the campus do not understand 
MT except for the RBridges which participate in the Virtual RBrodge, it 
looks like this will cause MAC flip flop on the other RBridges and other 
issues since all the other RBridges do not understand MT.
 
Could you please explain how MT can work in such scenarios?

Thanks
Jana
 
 
From: [e-mail] [mailto:[e-mail]] On 
Behalf Of Rohit Watve (rwatve)
Sent: Wednesday, March 28, 2012 3:53 PM
To: Mingui Zhang; Radia Perlman; Tissa Senevirathne (tsenevir)
Cc: [e-mail]
Subject: 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




--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

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