答复: 答复: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft
Mingui Zhang <zhangmingui@huawei.com> Sun, 01 April 2012 15:34 UTC
Return-Path: <rbridge-bounces@postel.org>
X-Original-To: ietfarch-trill-archive-Osh9cae4@ietfa.amsl.com
Delivered-To: ietfarch-trill-archive-Osh9cae4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADCD21F8C0A for <ietfarch-trill-archive-Osh9cae4@ietfa.amsl.com>; Sun, 1 Apr 2012 08:34:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.496
X-Spam-Level: ****
X-Spam-Status: No, score=4.496 tagged_above=-999 required=5 tests=[BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_110=0.6, J_CHICKENPOX_72=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFzbx93modb0 for <ietfarch-trill-archive-Osh9cae4@ietfa.amsl.com>; Sun, 1 Apr 2012 08:34:17 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 4786021F8C06 for <trill-archive-Osh9cae4@lists.ietf.org>; Sun, 1 Apr 2012 08:34:12 -0700 (PDT)
Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q31FFqLa007827; Sun, 1 Apr 2012 08:15:53 -0700 (PDT)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [58.251.152.66]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q31FFSGq007800 for <rbridge@postel.org>; Sun, 1 Apr 2012 08:15:37 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M1T007MK3PQ01@szxga03-in.huawei.com> for rbridge@postel.org; Sun, 01 Apr 2012 23:15:26 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M1T00EFY3PQK5@szxga03-in.huawei.com> for rbridge@postel.org; Sun, 01 Apr 2012 23:15:26 +0800 (CST)
Received: from szxeml213-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AIE16846; Sun, 01 Apr 2012 23:15:25 +0800
Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by szxeml213-edg.china.huawei.com (172.24.2.30) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 01 Apr 2012 23:08:58 +0800
Received: from SZXEML507-MBS.china.huawei.com ([169.254.7.100]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.01.0323.003; Sun, 01 Apr 2012 23:09:10 +0800
Date: Sun, 01 Apr 2012 15:09:09 +0000
From: Mingui Zhang <zhangmingui@huawei.com>
Subject: 答复: 答复: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft
In-reply-to: <0AA2AFF7-87AE-4300-9DC2-784A22C628DC@gmail.com>
X-Originating-IP: [172.24.1.69]
To: Jon Hudson <jon.hudson@gmail.com>
Message-id: <4552F0907735844E9204A62BBDD325E728CB1F32@SZXEML507-MBS.china.huawei.com>
MIME-version: 1.0
Content-language: zh-CN
Accept-Language: zh-CN, en-US
Thread-topic: 答复: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft
Thread-index: AQHNC6M4X8TnOZ/31Umc7no1WTsFHJZ9Cj0AgABclICAABKNgIABKjzxgAAYT0D//+PaAIAAy5WsgAAUHfCAABB74IAAKcBDgAASQ3CAAUvIPoAAP81cgAAoPaCAACBD3IAAmr6AgAPeCEA=
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
X-CFilter-Loop: Reflected
References: <344037D7CFEFE84E97E9CC1F56C5F4A5DA0303@xmb-sjc-214.amer.cisco.com> <OFB0DE3615.39F65513-ON482579CE.003C2CB1-482579CE.003E7761@zte.com.cn> <4552F0907735844E9204A62BBDD325E728CAD030@SZXEML507-MBS.china.huawei.com> <344037D7CFEFE84E97E9CC1F56C5F4A5DA05D7@xmb-sjc-214.amer.cisco.com> <CAFOuuo79GLE1QQ3MEn=Wx0z-eY8Vsnscy-bVw_8dmKSw8Efe_Q@mail.gmail.com> <4552F0907735844E9204A62BBDD325E728CAE193@SZXEML507-MBS.china.huawei.com> <CD31C838133B34469D6E01406350E68C0EA39F2F@xmb-sjc-215.amer.cisco.com> <CE35792847FBE84687FF9117132C8EFD4711441353@EXCH-CLUSTER-11.force10networks.com> <4552F0907735844E9204A62BBDD325E728CAE2F1@SZXEML507-MBS.china.huawei.com> <CE35792847FBE84687FF9117132C8EFD4711441389@EXCH-CLUSTER-11.force10networks.com> <4552F0907735844E9204A62BBDD325E728CAE77F@SZXEML507-MBS.china.huawei.com> <4552F0907735844E9204A62BBDD325E728CB086C@SZXEML507-MBS.china.huawei.com> <CE35792847FBE84687FF9117132C8EFD47114414C4@EXCH-CLUSTER-11.force10networks.com> <"4552F0907735844E9 204A62BBDD325E728CB099E"@SZXEML507-MBS.china.huawei.com> <0AA2AFF7-87AE-4300-9DC2-784A22C628DC@gmail.com>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: zhangmingui@huawei.com
X-MIME-Autoconverted: from base64 to 8bit by boreas.isi.edu id q31FFSGq007800
Cc: "rbridge@postel.org" <rbridge@postel.org>, Janardhanan Pathangi Narasimhan <jana@force10networks.com>
X-BeenThere: rbridge@postel.org
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:rbridge@postel.org>
List-Help: <mailto:rbridge-request@postel.org?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1002598186=="
Sender: rbridge-bounces@postel.org
Errors-To: rbridge-bounces@postel.org
Hi Jon, Please see my comments below. If I may make one minor point, the last statement is not correct. ZMG> Yes, I am happy to hear your comment. I know of two solutions (one shipping) where default hash parameters are set and where any two cables plugged into the same two RBridges will auto create a LAG. Not directly pertinent to the conversation at hand, but manual input is not a given. Zero-config is the goal for many of us. ZMG> I agree with you. I retrieve the statement about hashing. LAG can work without *manual* configuration of hashing function. I give three suggestions to solve this issue. 1. In practice, if vendors providing the CE devices along with the RBridges, they can set the hashing function not using mac_destination ip_destination to determine the outgoing port. 2. For those non MT RBridges, they can only recognize the base topology. Aggregated RBridges should resort to tunneling approach in order to send multicast traffic to them. 3. RBv001 and RBv010 are advertised as two nicknames besides RBv000 in the base topology. Then non MT RBridges can deem RBv as one RBridge (one ISIS ID) who has three nicknames (RBv000, RBv001 and RBv010). Then non MT RBridges should learn MACs from RBv using a single nickname with the highest priority. Then the MAC flip-flop problem is conquered. Thanks, Mingui 发件人: Jon Hudson [jon.hudson@gmail.com] 发送时间: 2012年3月30日 19:56 到: Mingui Zhang Cc: Janardhanan Pathangi Narasimhan; rbridge@postel.org 主题: Re: 答复: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft If I may make one minor point, the last statement is not correct. ZMG> Think about it. When an operator have a LAG connected to a group of RBridges, he has to decide which port to plug the cables in. He need enter the console window to input the command line to configure parameters and start the LAG. He also need to configure the tuple used for hashing. I know of two solutions (one shipping) where default hash parameters are set and where any two cables plugged into the same two RBridges will auto create a LAG. Not directly pertinent to the conversation at hand, but manual input is not a given. Zero-config is the goal for many of us. Just a side note. Jon On Mar 29, 2012, at 8:56 PM, Mingui Zhang <zhangmingui@huawei.com> wrote: <!-- @font-face {font-family:SimSun} @font-face {font-family:"MS Gothic"} @font-face {font-family:MingLiU} @font-face {font-family:"Cambria Math"} @font-face {font-family:Calibri} @font-face {font-family:Tahoma} @font-face {font-family:Consolas} @font-face {font-family:"\@SimSun"} @font-face {font-family:"\@MS Gothic"} @font-face {font-family:"\@MingLiU"} p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:SimSun} a:link, span.MsoHyperlink {color:blue; text-decoration:underline} a:visited, span.MsoHyperlinkFollowed {color:purple; text-decoration:underline} p {margin-right:0in; margin-left:0in; font-size:12.0pt; font-family:SimSun} p.MsoAcetate, li.MsoAcetate, div.MsoAcetate {margin:0in; margin-bottom:.0001pt; font-size:8.0pt; font-family:"Tahoma","sans-serif"} span.BalloonTextChar {font-family:"Tahoma","sans-serif"} p.msochpdefault, li.msochpdefault, div.msochpdefault {margin-right:0in; margin-left:0in; font-size:10.0pt; font-family:SimSun} span.balloontextchar0 {font-family:"Tahoma","sans-serif"} span.balloontextchar00 {font-family:"Tahoma","sans-serif"} span.emailstyle20 {font-family:"Calibri","sans-serif"; color:#1F497D} span.emailstyle23 {font-family:"Calibri","sans-serif"; color:#1F497D} span.EmailStyle25 {font-family:"Calibri","sans-serif"; color:#1F497D} .MsoChpDefault {font-size:10.0pt} @page WordSection1 {margin:1.0in 1.0in 1.0in 1.0in} --> Hi Jana, Let us assume that I have 20 RBridges in the campus which have end systems connected to it, and all of them need to be reachable. So if a few of them are converted to MTRA RBridges to support active-active, does it mean that RBridges which are not yet converted will not be able to anymore see the nodes connected to these virtual RBridges? Or am I missing something here? ZMG> Although physical reachability can be all to all, it does not mean than the end systems will really communicate in an all to all manner. It is restricted by the VLAN configuration of the campus. Let me give you an example, RB1, RB2, RB3 and RB4 have an all to all connection. The access ports of RB1 and RB3 are configured as the VLAN for end systems of the Dept of Computer Science while the access ports of RB2 and RB4 are configured as another VLAN for end systems of the Dept of Literature. End systems from the same department can talk with each other. But end systems from two different departments will not talk with each other. I am not sure if that is practical, and always possible may depend on the nodes connected and also what controls are available on them ZMG> Think about it. When an operator have a LAG connected to a group of RBridges, he has to decide which port to plug the cables in. He need enter the console window to input the command line to configure parameters and start the LAG. He also need to configure the tuple used for hashing. Thanks, Mingui 发件人: Janardhanan Pathangi Narasimhan [jana@force10networks.com] 发送时间: 2012年3月30日 0:49 到: Mingui Zhang Cc: rbridge@postel.org 主题: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft Hi Mingui, I am slightly confused. For the intra-topology scenario, MT unaware RBridges will not appear in a specific topology other than the based topology. In other words, MTRA RBridges only talks only with MTRA RBridges. Since they all support MT, MTRA can work very well among them. In this scenario, MTRA RBridges and old RBridges co-exist in the same campus. Therefore, this is a solid example that MTRA can be deployed incrementally. Remember, CMT does not allow such kind of deployment. Let us assume that I have 20 RBridges in the campus which have end systems connected to it, and all of them need to be reachable. So if a few of them are converted to MTRA RBridges to support active-active, does it mean that RBridges which are not yet converted will not be able to anymore see the nodes connected to these virtual RBridges? Or am I missing something here? For the inter-topology scenario, we assume MTRA RBridges have to talk with MT unaware RBridges (This is a rigorous assumption.) If operators do want to realize such kind of connection, it is reasonable to assume they will accept the requirement that they need to configure their hashing function to remove the possible MAC flip-flop. I am not sure if that is practical, and always possible may depend on the nodes connected and also what controls are available on them Thanks Jana Thanks, Mingui 发件人: rbridge-bounces@postel.org [rbridge-bounces@postel.org] 代表 Mingui Zhang [zhangmingui@huawei.com] 发送时间: 2012年3月29日 18:50 到: Janardhanan Pathangi Narasimhan Cc: rbridge@postel.org 主题: 答复: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft Hi Jana, >In section 4.1, could you please explain how the frame that is ingressed by RB1 through RBv001 is received at RBx? Two scenarios are given in Section 4. Section 4.1 talks about the intra-topology scenario. Here, RBx is not in topology 1 so it is unreachable by RB1. It need not set up any forwarding path to RBx. Thanks, Mingui 发件人: Janardhanan Pathangi Narasimhan [jana@force10networks.com] 发送时间: 2012年3月28日 22:52 到: Mingui Zhang Cc: rbridge@postel.org 主题: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft Hi Mingui, Section 4, does not give backward compatibility. For e.g. in section 4.2 multi destination frames will be ingressed with two different bridge ID causing MAC move, and having to impose restrictions on hashing functions at the external node may or may not be acceptable . I am not sure that this can be classified as backward compatible since it is not a full solution and can also cause frequent MAC flip flops etc. In section 4.1, could you please explain how the frame that is ingressed by RB1 through RBv001 is received at RBx? Thanks Jana From: Mingui Zhang [mailto:zhangmingui@huawei.com] Sent: Wednesday, March 28, 2012 7:15 PM To: Janardhanan Pathangi Narasimhan Cc: rbridge@postel.org Subject: 答复: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft Hi Jana, I think I should answer your question. I am Mingui Zhang. Please refer to the draft http://tools.ietf.org/html/draft-zhang-trill-multi-topo-rpfc-00. Section 4 is right for the topic you are interested. As a starter draft on the RPFC using Multi-topology. I will be happy to receive your comments. Thanks, Mingui 发件人: Janardhanan Pathangi Narasimhan [jana@force10networks.com] 发送时间: 2012年3月28日 19:14 到: Rohit Watve (rwatve); Mingui Zhang; Radia Perlman; Tissa Senevirathne (tsenevir) Cc: rbridge@postel.org 主题: 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: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Rohit Watve (rwatve) Sent: Wednesday, March 28, 2012 3:53 PM To: Mingui Zhang; Radia Perlman; Tissa Senevirathne (tsenevir) Cc: rbridge@postel.org 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: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Mingui Zhang Sent: Wednesday, March 28, 2012 2:10 AM To: Radia Perlman; Tissa Senevirathne (tsenevir) Cc: rbridge@postel.org 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 发件人: rbridge-bounces@postel.org [rbridge-bounces@postel.org] 代表 Radia Perlman [radiaperlman@gmail.com] 发送时间: 2012年3月28日 12:52 到: Tissa Senevirathne (tsenevir) Cc: rbridge@postel.org 主题: 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 rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge
_______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge
- [rbridge] Call for draft-tissa-trill-cmt-00 to WG… Donald Eastlake
- Re: [rbridge] Call for draft-tissa-trill-cmt-00 t… hu.fangwei
- Re: [rbridge] Call for draft-tissa-trill-cmt-00 t… Jon Hudson
- Re: [rbridge] Call for draft-tissa-trill-cmt-00 t… Tissa Senevirathne (tsenevir)
- Re: [rbridge] Call for draft-tissa-trill-cmt-00 t… zhai.hongjun
- Re: [rbridge] Call for draft-tissa-trill-cmt-00 t… Janardhanan Pathangi Narasimhan
- 答复: [rbridge] Call for draft-tissa-trill-cmt-00 t… Mingui Zhang
- Re: [rbridge] Call for draft-tissa-trill-cmt-00 t… Tissa Senevirathne (tsenevir)
- Re: [rbridge] Call for draft-tissa-trill-cmt-00 t… Radia Perlman
- Re: [rbridge] Call for draft-tissa-trill-cmt-00 t… zhai.hongjun
- Re: [rbridge] Call for draft-tissa-trill-cmt-00 t… Janardhanan Pathangi Narasimhan
- Re: [rbridge] Call for draft-tissa-trill-cmt-00 t… zhai.hongjun
- Re: [rbridge] Call for draft-tissa-trill-cmt-00 t… Tissa Senevirathne (tsenevir)
- 答复: RE: [rbridge] Call for draft-tissa-trill-cmt-… zhai.hongjun
- Re: [rbridge] Call for draft-tissa-trill-cmt-00 t… Tissa Senevirathne (tsenevir)
- 答复: RE: RE: [rbridge] Call for draft-tissa-trill-… zhai.hongjun
- 答复: [rbridge] Call for draft-tissa-trill-cmt-00 t… Mingui Zhang
- Re: [rbridge] Call for draft-tissa-trill-cmt-00 t… Tissa Senevirathne (tsenevir)
- 答复: RE: RE: RE: [rbridge] Call for draft-tissa-tr… zhai.hongjun
- Re: [rbridge] Call for draft-tissa-trill-cmt-00 t… Rohit Watve (rwatve)
- Re: [rbridge] Call for draft-tissa-trill-cmt-00 t… Janardhanan Pathangi Narasimhan
- Re: [rbridge] Call for draft-tissa-trill-cmt-00 t… Tissa Senevirathne (tsenevir)
- Re: [rbridge] Call for draft-tissa-trill-cmt-00 t… Tissa Senevirathne (tsenevir)
- Re: [rbridge] Call for draft-tissa-trill-cmt-00 t… Tissa Senevirathne (tsenevir)
- Re: [rbridge] Call for draft-tissa-trill-cmt-00 t… Tissa Senevirathne (tsenevir)
- 答复: [rbridge] Call for draft-tissa-trill-cmt-00 t… Mingui Zhang
- 答复: [rbridge] Call for draft-tissa-trill-cmt-00 t… Mingui Zhang
- Re: [rbridge] Call for draft-tissa-trill-cmt-00 t… Janardhanan Pathangi Narasimhan
- Re: [rbridge] Call for draft-tissa-trill-cmt-00 t… Tissa Senevirathne (tsenevir)
- 答复: Re: [rbridge] Call for draft-tissa-trill-cmt-… zhai.hongjun
- 答复: 答复: [rbridge] Call for draft-tissa-trill-cmt-… zhai.hongjun
- 答复: [rbridge] Call for draft-tissa-trill-cmt-00 t… Mingui Zhang
- 答复: [rbridge] Call for draft-tissa-trill-cmt-00 t… Mingui Zhang
- Re: [rbridge] Call for draft-tissa-trill-cmt-00 t… Janardhanan Pathangi Narasimhan
- 答复: [rbridge] Call for draft-tissa-trill-cmt-00 t… Mingui Zhang
- Re: [rbridge] Call for draft-tissa-trill-cmt-00 t… Janardhanan Pathangi Narasimhan
- 答复: [rbridge] Call for draft-tissa-trill-cmt-00 t… Mingui Zhang
- Re: [rbridge] Call for draft-tissa-trill-cmt-00 t… Janardhanan Pathangi Narasimhan
- 答复: [rbridge] Call for draft-tissa-trill-cmt-00 t… Mingui Zhang
- Re: [rbridge] Call for draft-tissa-trill-cmt-00 t… Janardhanan Pathangi Narasimhan
- Re: [rbridge] Call for draft-tissa-trill-cmt-00 t… Janardhanan Pathangi Narasimhan
- 答复: [rbridge] Call for draft-tissa-trill-cmt-00 t… Mingui Zhang
- Re: [rbridge] Call for draft-tissa-trill-cmt-00 t… Tissa Senevirathne (tsenevir)
- Re: [rbridge] Call for draft-tissa-trill-cmt-00 t… Tissa Senevirathne (tsenevir)
- Re: [rbridge] Call for draft-tissa-trill-cmt-00 t… letracy
- 答复: [rbridge] Call for draft-tissa-trill-cmt-00 t… Mingui Zhang
- Re: 答复: [rbridge] Call for draft-tissa-trill-cmt-… Jon Hudson
- 答复: 答复: [rbridge] Call for draft-tissa-trill-cmt-… Mingui Zhang
- Re: [rbridge] Call for draft-tissa-trill-cmt-00 t… Tissa Senevirathne (tsenevir)
- 答复: [rbridge] Call for draft-tissa-trill-cmt-00 t… Mingui Zhang
- Re: [rbridge] Call for draft-tissa-trill-cmt-00 t… Donald Eastlake
- Re: [rbridge] Call for draft-tissa-trill-cmt-00 t… Tissa Senevirathne (tsenevir)
- Re: [rbridge] Call for draft-tissa-trill-cmt-00 t… Janardhanan Pathangi Narasimhan
- Re: [rbridge] Call for draft-tissa-trill-cmt-00 t… ayabaner
- Re: [rbridge] Call for draft-tissa-trill-cmt-00 t… Mingui Zhang
- Re: [rbridge] Call for draft-tissa-trill-cmt-00 t… Tissa Senevirathne (tsenevir)
- Re: [rbridge] Call for draft-tissa-trill-cmt-00 t… Tissa Senevirathne (tsenevir)
- Re: [rbridge] Call for draft-tissa-trill-cmt-00 t… Sam Aldrin
- Re: [rbridge] Call for draft-tissa-trill-cmt-00 t… Anoop Ghanwani
- Re: [rbridge] Call for draft-tissa-trill-cmt-00 t… Ramkumar Parameswaran
- Re: [rbridge] Call for draft-tissa-trill-cmt-00 t… Mingui Zhang
- Re: [rbridge] Call for draft-tissa-trill-cmt-00 t… zhai.hongjun
- Re: [rbridge] Call for draft-tissa-trill-cmt-00 t… Tissa Senevirathne (tsenevir)