[rbridge] Coordinated Multicast Trees to solve RPF issues on active-active edge and more
zhai.hongjun@zte.com.cn
zhai.hongjun at zte.com.cn
Thu Jan 12 21:05:29 PST 2012
Hi Tissa£¬
In the diagram you given, assume 4 distribution trees are acturally
calculated in TRILL campus, i.e., T1 through T4. T1 and T2 are assigned
to RB1, T3 and T4 are assigned to RB2.
Even if RB1 can not see RB2 by hellos, (I think that) RB1 can generate a
pseudonode LSP, Pseu-LSP-RB1, to announce the virtual RBridge (RBv)
nickname and the trees assigned to it, i.e, T1 and T2. In this pseudonode
LSP, RB1 is the only one neighbor (or RB1 and the virtual RBridge RBv are
the only two neigbors) of this pseudonode. After receiving this
pseudonode LSP, RBx can know the path to pseudonode RBv through RB1 on
T1 or T2, shown in the following diagram.
RBx
|
Trill Campus
| |
+----------+ +------------+
| RB1 | | RB2 |
+----------+ + ------------+
\
/ \
/RBv \
---------
scheme of T1 or T2
RB1 uses Nickname Sub-TLV and Trees Sub-TLV (instead of the Affinity
sub-TLV) in Pseu-LSP-RB1, to contains the RBv's nickname and the assigned
trees T1 and T2.
RB2 also annouce similar informtion in its pseudonode LSP, then RBx can
know the path to RBv through RB2 on T3 and T4.
RBx
|
Trill Campus
| |
+----------+ +------------+
| RB1 | | RB2 |
+----------+ + ------------+
\ /
\ /
\ /
---------- -----------
> | | < Port channel (LAG)
| |
+--------------------+
| CE |
+---------------------+
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: +86-25-52877345
Email: zhai.hongjun at zte.com.cn
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
"Tissa Senevirathne (tsenevir)" <tsenevir at cisco.com>
2012-01-13 12:21
ÊÕ¼þÈË
<zhai.hongjun at zte.com.cn>
³ËÍ
<rbridge at postel.org>, <rbridge-bounces at postel.org>
Ö÷Ìâ
RE: [rbridge] Coordinated Multicast Trees to solve RPF issues on
active-active edge and more
Hi Hongjun
I am not quite clear with the way you are proposing to use assigned
nicknames in the pseudonode LSP.
Can you please us the diagram below and explain how your proposal will be
used.
CE means in the following diagram is an 802.1D device that is attached to
RB1 and RB2 through Pt-Pt links and treated as a port channel from CE
stand point.
RBx
|
Trill Campus
| |
+----------+ +------------+
| RB1 | | RB2 |
+----------+ + ------------+
\ /
\ /
\ /
---------- -----------
> | | < Port channel (LAG)
| |
+--------------------+
| CE |
+---------------------+
From: zhai.hongjun at zte.com.cn [mailto:zhai.hongjun at zte.com.cn]
Sent: Thursday, January 12, 2012 7:59 PM
To: Tissa Senevirathne (tsenevir)
Cc: rbridge at postel.org; rbridge-bounces at postel.org
Subject: RE: [rbridge] Coordinated Multicast Trees to solve RPF issues on
active-active edge and more
Hi Tissa,
I have read your draft-tissa-trill-cmt-00.txt with great interests. In
this draft, a new TLV, Affinity Sub-TLV, is introduced to give a member
RBdige of a virtual RBridge group much flexibity in describing the virtual
RBridge nickname and specifying the path of association to specific
distribution tree(S). However, this new TLV causes some backward
compatibilty problems between pre Affinity sub-TLV RBridges and new
RBridges. Even if there is only one pre Affinity sub-TLV RBridge in TRILL
network,the RPF check for virtual Rbridge will fail on this RBridge.
Is the Affinity Sub-TLV necessary for a member RBridge to announce the
virtual Rbridge nickname and the specific distribution trees? Maybe it is
not.
In a given vritual group, each member Rbridge can advertise a specific
pseudonode-LSP to annouce the virtual RBridge nickname and the trees
assigned to it.The nickname and the assigned trees are contained in the
given Nickname Sub-TLV and Trees Sub-TLV in RFC6326. This pseudonode-LSP
represents a special virtual link, on which there is only one RBridge,
i.e., the RBridge advertising this LSP. Only if different member Rbridge
is assigned different tree(s), RPF check information for the virtual
Rbrigde in different trees can be correctly calculated on all the Rbridges
in TRILL network, then the member RBridge can safely use the virtual
Rbridge nickname to do the necessary TRILL-encapsultion on received
native frames.
Therefore, backward compatibilty problems, caused by Affinity sub-TLV, is
removed, while the similar flexibilty of Affinity sub-TLV remains.
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: +86-25-52877345
Email: zhai.hongjun at zte.com.cn
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
"Tissa Senevirathne (tsenevir)" <tsenevir at cisco.com>
·¢¼þÈË: rbridge-bounces at postel.org
2012-01-06 10:11
ÊÕ¼þÈË
<rbridge at postel.org>
³ËÍ
Ö÷Ìâ
[rbridge] Coordinated Multicast Trees to solve RPF issues on active-active
edge and more
Dear All
We have published draft-tissa-trill-cmt-00.txt, in this document we
present a flexible framework to associate child RBridges to different
parent RBRidges for RPF purpose.
Active-active forwarding at the TRILL edge is a very important feature.
Representation of the active-active sub system with a single virtual
RBRidge is a common practice to achieve load balancing and to avoid MAC
flip flop. However, use of virtual RBridge lead to RPF failures. In this
document we provide a solution to address the RPF failures. Please review
and share comments.
ID can be found in URL:
http://www.ietf.org/id/draft-tissa-trill-cmt-00.txt
Summary:
Filename: draft-tissa-trill-cmt
Revision: 00
Title: Coordinated Multicast Trees (CMT)for TRILL
Creation date: 2012-01-05
WG ID: Individual Submission
Number of pages: 14
Abstract:
TRILL facilitates loop free connectivity to non TRILL legacy
networks via choice of an Appointed Forwarder for set of VLANs.
Appointed Forwarder provides VLAN level load sharing with active-
standby model. Mission critical operations such as High Performance
Data Centers require active-active load sharing model. Active-Active
load sharing model can be accomplished by representing any given non
TRILL legacy network with a single virtual RBridge. Virtual
representation of the non-TRILL legacy network with a single RBridge
poses serious challenges in multi-destination RPF calculations. This
document presents the required enhancements to build Coordinated
Multicast Trees (CMT) within the TRILL campus. CMT provides
flexibility to RBridges to select desired path of association to a
given distribution tree.
Thanks
Tissa_______________________________________________
rbridge mailing list
rbridge at postel.org
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.
--------------------------------------------------------
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20120113/96994e90/attachment-0001.html
More information about the rbridge
mailing list