From rbridge-bounces@postel.org Sun Apr 1 08:34:18 2012 Return-Path: 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 ; 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 ; 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 ; 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 ; 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 Subject: =?gb2312?B?tPC4tDogtPC4tDogW3JicmlkZ2VdIENhbGwgZm9yIGRyYWZ0LXRpc3NhLXRy?= =?gb2312?Q?ill-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 Message-id: <4552F0907735844E9204A62BBDD325E728CB1F32@SZXEML507-MBS.china.huawei.com> MIME-version: 1.0 Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: =?gb2312?B?tPC4tDogW3JicmlkZ2VdIENhbGwgZm9yIGRyYWZ0LXRpc3NhLXRyaWxsLWNt?= =?gb2312?Q?t-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> <4552F0907735844E9204A62BBDD325E728CAD030@SZXEML507-MBS.china.huawei.com> <344037D7CFEFE84E97E9CC1F56C5F4A5DA05D7@xmb-sjc-214.amer.cisco.com> <4552F0907735844E9204A62BBDD325E728CAE193@SZXEML507-MBS.china.huawei.com> <4552F0907735844E9204A62BBDD325E728CAE2F1@SZXEML507-MBS.china.huawei.com> <4552F0907735844E9204A62BBDD325E728CAE77F@SZXEML507-MBS.china.huawei.com> <4552F0907735844E9204A62BBDD325E728CB086C@SZXEML507-MBS.china.huawei.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" , Janardhanan Pathangi Narasimhan X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1002598186==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org --===============1002598186== Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-Transfer-Encoding: 8bit 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 wrote: 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 --===============1002598186== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge --===============1002598186==-- From rbridge-bounces@postel.org Sun Apr 1 09:47:43 2012 Return-Path: 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 72C7F21F8A87 for ; Sun, 1 Apr 2012 09:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.947 X-Spam-Level: X-Spam-Status: No, score=-0.947 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, MIME_CHARSET_FARAWAY=2.45, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_MED=-4] 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 NUUOwPQXgcPB for ; Sun, 1 Apr 2012 09:47:41 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 1BFF621F8A86 for ; Sun, 1 Apr 2012 09:47:41 -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 q31GSTC2016837; Sun, 1 Apr 2012 09:28:31 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q31GRpNN016784 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 1 Apr 2012 09:28:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tsenevir@cisco.com; l=84882; q=dns/txt; s=iport; t=1333297680; x=1334507280; h=mime-version:subject:date:message-id:references:from:to: cc; bh=+uuBoLhEHTrx6qHj0b/lqNds3vcd0AwozWZyM7RZ24U=; b=c+1DstIiWquDHarwVg3m7cWVF8aoX2nuzU1hZ0ms+6xsVSDO2zI0qOa0 gCPZ2OW4DvQiUonETskIymSq89aJRpPNpvJrTI6YfQCLPgsn1QhnYkGD8 MwKvBWlCFWUul/k848Qi4lNvF1QX8lkzeSDdn4BaDjz2T348L1uQLZkxj Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoFAGqBeE+rRDoG/2dsb2JhbABDglODAapAAYh2gQeCCQEBAQQSAQcCARADNQgMDAQCAQYCEQQBAQsGEAEGAQQCASAlCQgCBAESCBMHh2YBC6ABjQIIiRiKFoVqOWMEiFiOGooigxSBaIMH X-IronPort-AV: E=Sophos;i="4.75,353,1330905600"; d="scan'208,217";a="38587097" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 01 Apr 2012 16:27:50 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q31GRovI001061; Sun, 1 Apr 2012 16:27:50 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Apr 2012 09:27:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 1 Apr 2012 09:27:49 -0700 Message-ID: <344037D7CFEFE84E97E9CC1F56C5F4A5DA122A@xmb-sjc-214.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft Thread-Index: AQHNC6M4X8TnOZ/31Umc7no1WTsFHJZ9Cj0AgABclICAABKNgIABKjzxgAAYT0D//+PaAIAAy5WsgAAUHfCAABB74IAAKcBDgAASQ3CAAUvIPoAAP81cgAAoPaCAACBD3IAAtGNggAAT3tCAAA2IQIAADzCAgAAD9ECAA6fZcA== References: <344037D7CFEFE84E97E9CC1F56C5F4A5DA0303@xmb-sjc-214.amer.cisco.com><4552F0907735844E9204A62BBDD325E728CAD030@SZXEML507-MBS.china.huawei.com><344037D7CFEFE84E97E9CC1F56C5F4A5DA05D7@xmb-sjc-214.amer.cisco.com><4552F0907735844E9204A62BBDD325E728CAE193@SZXEML507-MBS.china.huawei.com><4552F0907735844E9204A62BBDD325E728CAE2F1@SZXEML507-MBS.china.huawei.com><4552F0907735844E9204A62BBDD325E728CAE77F@SZXEML507-MBS.china.huawei.com><4552F0907735844E9204A62BBDD325E728CB086C@SZXEML507-MBS.china.huawei.com><4552F0907735844E9204A62BBDD325! E728CB099 E@SZXEML507- MBS.china.huawei.com><4552F0907735844E9204A62BBDD325E728CB0B20@SZXEML507-MBS.china.huawei.com> From: "Tissa Senevirathne (tsenevir)" To: "Janardhanan Pathangi Narasimhan" , "Mingui Zhang" X-OriginalArrivalTime: 01 Apr 2012 16:27:50.0734 (UTC) FILETIME=[61AF06E0:01CD1024] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: tsenevir@cisco.com Cc: rbridge@postel.org Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1555501365==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org This is a multi-part message in MIME format. --===============1555501365== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD1024.617B85AA" This is a multi-part message in MIME format. ------_=_NextPart_001_01CD1024.617B85AA Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi Mingui =20 I have not seen an answer for the questions below could you please = answer simple question: =20 What is your proposal for active-active for people who do not want to = run multi-topology ? =20 From: Tissa Senevirathne (tsenevir)=20 Sent: Friday, March 30, 2012 1:37 AM To: Tissa Senevirathne (tsenevir); 'Janardhanan Pathangi Narasimhan'; = 'Mingui Zhang' Cc: 'rbridge@postel.org' Subject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft =20 Small typo correction=20 =20 From: Tissa Senevirathne (tsenevir)=20 Sent: Friday, March 30, 2012 1:25 AM To: 'Janardhanan Pathangi Narasimhan'; Mingui Zhang Cc: rbridge@postel.org Subject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft =20 Jana is absolutely correct on the observation below. =20 One more point to add, as have indicated earlier =20 1. Not all customer will run multi-topology 2. You cannot force customers to run multi-topology when they need = active-active forwarding 3. What is your solution for customers who *do NOT* want to run = multi-topology ? =20 From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On = Behalf Of Janardhanan Pathangi Narasimhan Sent: Friday, March 30, 2012 12:30 AM To: Mingui Zhang Cc: rbridge@postel.org Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft =20 Hi Mingui =20 When you realize active-active, you are asking for the active-active = to be setup in a new topology and not the base topology. So these nodes = which need to talk to the other nodes which are behind non-MT RBridges = cannot do so any more.=20 =20 Specifically for MT to be backward compatible, you need all nodes = which want to talk to each other part of the base topology. If you do = that you cannot realize active-active. If you put the active-active in a = new topology, than they can no longer talk to nodes on the base topology = of non-MT RBridges. =20 So yes, MT-TRILL is backward compatible for base topology, but the = realization of active-active with MT =A8C TRILL is not backward = compatible. That was the point I was bringing up. =20 Thanks Jana =20 =20 From: Mingui Zhang [mailto:zhangmingui@huawei.com]=20 Sent: Friday, March 30, 2012 12:15 PM To: Janardhanan Pathangi Narasimhan Cc: rbridge@postel.org Subject: =B4=F0=B8=B4: [rbridge] Call for draft-tissa-trill-cmt-00 to WG = draft =20 Hi Jana,=20 =20 All RBridges in the campus are in the base topology. MT RBridges can = well communicate with non-MT RBridges using the base topology.=20 =20 I feel that you are arguing that MT-TRILL is not backward compatible. = That is a incorrect judgement. =20 Thanks, Mingui ________________________________ =B7=A2=BC=FE=C8=CB: Janardhanan Pathangi Narasimhan = [jana@force10networks.com] =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C230=C8=D5 13:29 =B5=BD: Mingui Zhang Cc: rbridge@postel.org =D6=F7=CC=E2: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG = draft Hi Mingui, =20 With MT approach, when two RBridges which had stations talking to each = other and one of them is converted to MT, then the communication is = broken. So it does not have backward computability.=20 =20 Thanks Jana =20 =20 From: Mingui Zhang [mailto:zhangmingui@huawei.com]=20 Sent: Friday, March 30, 2012 12:27 AM To: Janardhanan Pathangi Narasimhan Cc: rbridge@postel.org Subject: =B4=F0=B8=B4: [rbridge] Call for draft-tissa-trill-cmt-00 to WG = draft =20 Hi Jana,=20 =20 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? =20 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. =20 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 =20 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. =20 Thanks, Mingui =20 =20 =20 ________________________________ =B7=A2=BC=FE=C8=CB: Janardhanan Pathangi Narasimhan = [jana@force10networks.com] =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C230=C8=D5 0:49 =B5=BD: Mingui Zhang Cc: rbridge@postel.org =D6=F7=CC=E2: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG = draft Hi Mingui, =20 I am slightly confused.=20 =20 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. =20 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? =20 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.=20 =20 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 =20 Thanks Jana =20 Thanks, Mingui ________________________________ =B7=A2=BC=FE=C8=CB: rbridge-bounces@postel.org = [rbridge-bounces@postel.org] =B4=FA=B1=ED Mingui Zhang = [zhangmingui@huawei.com] =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C229=C8=D5 18:50 =B5=BD: Janardhanan Pathangi Narasimhan Cc: rbridge@postel.org =D6=F7=CC=E2: =B4=F0=B8=B4: [rbridge] Call for draft-tissa-trill-cmt-00 = to WG draft Hi Jana,=20 =20 >In section 4.1, could you please explain how the frame that is = ingressed by RB1 through RBv001 is received at RBx?=20 =20 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. =20 Thanks, Mingui ________________________________ =B7=A2=BC=FE=C8=CB: Janardhanan Pathangi Narasimhan = [jana@force10networks.com] =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C228=C8=D5 22:52 =B5=BD: Mingui Zhang Cc: rbridge@postel.org =D6=F7=CC=E2: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG = draft Hi Mingui, =20 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. =20 In section 4.1, could you please explain how the frame that is ingressed = by RB1 through RBv001 is received at RBx?=20 =20 Thanks Jana =20 =20 From: Mingui Zhang [mailto:zhangmingui@huawei.com]=20 Sent: Wednesday, March 28, 2012 7:15 PM To: Janardhanan Pathangi Narasimhan Cc: rbridge@postel.org Subject: =B4=F0=B8=B4: [rbridge] Call for draft-tissa-trill-cmt-00 to WG = draft =20 Hi Jana,=20 =20 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. =20 Thanks, Mingui ________________________________ =B7=A2=BC=FE=C8=CB: Janardhanan Pathangi Narasimhan = [jana@force10networks.com] =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C228=C8=D5 19:14 =B5=BD: Rohit Watve (rwatve); Mingui Zhang; Radia Perlman; Tissa = Senevirathne (tsenevir) Cc: rbridge@postel.org =D6=F7=CC=E2: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG = draft Hi Zhai, =20 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. =20 Could you please explain how MT can work in such scenarios? Thanks Jana =20 =20 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 =20 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.=20 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: =B4=F0=B8=B4: [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.=20 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.=20 PN: NO. The new distribution tree need to be recomputed. CMT: NO. A overall re-configuration is necessary. MTRA: YES.=20 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.=20 +--------+------------+-----------+----------+------------+-------------+= |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 =20 =B7=A2=BC=FE=C8=CB: rbridge-bounces@postel.org = [rbridge-bounces@postel.org] =B4=FA=B1=ED Radia Perlman = [radiaperlman@gmail.com] =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C228=C8=D5 12:52 =B5=BD: Tissa Senevirathne (tsenevir) Cc: rbridge@postel.org =D6=F7=CC=E2: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG = draft =20 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 =20 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. =20 So from memory...other proposals for allowing R1, R2, and R3 to be = active/active/active on a link: =20 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. =20 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. =20 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: =20 1) R3 could tunnel it to one of {R1, R2}, and let them inject the packet = (with pseudonode nickname) into the campus. =20 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. =20 2) R3 could use its own nickname instead of the pseudonode nickname in = this case =20 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). =20 ------ There might have been some other proposals, but they wound up not to = work. =20 Personally, I don't love the CMT thing because of the two disadvantages = I mentioned above, but I can live with it. =20 Radia=20 =20 ------_=_NextPart_001_01CD1024.617B85AA Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Mingui

 

I have not seen an answer for the questions below could you please = answer simple question:

 

What is your proposal for active-active for people who do not want to = run multi-topology ?

 

From:= = Tissa Senevirathne (tsenevir)
Sent: Friday, March 30, 2012 = 1:37 AM
To: Tissa Senevirathne (tsenevir); 'Janardhanan = Pathangi Narasimhan'; 'Mingui Zhang'
Cc: = 'rbridge@postel.org'
Subject: RE: [rbridge] Call for = draft-tissa-trill-cmt-00 to WG draft

 

Small typo correction

 

From:= = Tissa Senevirathne (tsenevir)
Sent: Friday, March 30, 2012 = 1:25 AM
To: 'Janardhanan Pathangi Narasimhan'; Mingui = Zhang
Cc: rbridge@postel.org
Subject:<= /b> RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG = draft

 

Jana is absolutely correct on the observation = below.

 

One more point to add, as have indicated = earlier

 

1.       = Not all customer will run multi-topology

2.       = You cannot force customers to run multi-topology when they need = active-active forwarding

3.       = What is your solution for customers who *do NOT* want to run = multi-topology ?

 

From:= = rbridge-bounces@postel.org= [mailto:rbridge-bounces@postel.= org] On Behalf Of Janardhanan Pathangi = Narasimhan
Sent: Friday, March 30, 2012 12:30 AM
To: = Mingui Zhang
Cc: rbridge@postel.org
Subject:<= /b> Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG = draft

 

Hi Mingui

 

  When you realize active-active, you are asking for the = active-active to be setup in a new topology and not the base topology. = So these nodes which need to talk to the other nodes which are behind = non-MT RBridges cannot do so any more.

 

  Specifically for MT to be backward compatible, you need all = nodes which want to talk to each other part of the base topology. If you = do that you cannot realize active-active. If you put the active-active = in a new topology, than they can no longer talk to nodes on the base = topology of non-MT RBridges.

 

So yes, MT-TRILL is backward compatible for base topology, but the = realization of active-active with MT =A8C TRILL is not backward = compatible. That was the point I was bringing = up.

 

Thanks

Jana

 

 

From:= = Mingui Zhang [mailto:zhangmingui@huawei.com]=
Sent: Friday, March 30, 2012 12:15 PM
To: = Janardhanan Pathangi Narasimhan
Cc: rbridge@postel.org
Subject:<= /b> =B4=F0=B8=B4: [rbridge] = Call for draft-tissa-trill-cmt-00 to WG = draft

 

= Hi Jana,

=  

= All RBridges in the campus are in the base topology. MT RBridges can = well communicate with non-MT RBridges using the base = topology. 

=  

= I feel that you are arguing that MT-TRILL is not = backward compatible. That is a incorrect = judgement.

=  

= Thanks,

= Mingui

=

=B7=A2=BC=FE=C8=CB= := Janardhanan Pathangi Narasimhan = [jana@force10networks.com]
=B7=A2=CB=CD=CA=B1=BC=E4= := 2012=C4=EA= 3=D4=C2= 30=C8=D5= 13:29
=B5=BD= := Mingui Zhang
Cc: rbridge@postel.org
=D6=F7=CC=E2= := RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG = draft

Hi Mingui,

 

With MT approach, when two RBridges which had stations talking to = each other and one of them is converted to MT, then the communication is = broken. So it does not have backward computability.

 

Thanks

Jana

 

 

= From:= Mingui Zhang [mailto:zhangmingui@huawei.com]=
Sent: Friday, March 30, 2012 12:27 AM
To: = Janardhanan Pathangi Narasimhan
Cc: rbridge@postel.org
Subject:<= /b> =B4=F0=B8=B4= : [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

 

= 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

=  

=  

=  

=B7=A2=BC=FE=C8=CB= := Janardhanan Pathangi Narasimhan = [jana@force10networks.com]
=B7=A2=CB=CD=CA=B1=BC=E4= := 2012=C4=EA= 3=D4=C2= 30=C8=D5= 0:49
=B5=BD= := Mingui Zhang
Cc: rbridge@postel.org
=D6=F7=CC=E2= := 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

=B7=A2=BC=FE=C8=CB= := rbridge-bounces@postel.org = [rbridge-bounces@postel.org] =B4=FA=B1=ED= Mingui Zhang [zhangmingui@huawei.com]
=B7=A2=CB=CD=CA=B1=BC=E4= := 2012=C4=EA= 3=D4=C2= 29=C8=D5= 18:50
=B5=BD= := Janardhanan Pathangi Narasimhan
Cc: rbridge@postel.org
=D6=F7=CC=E2= := =B4=F0=B8=B4= : [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

=B7=A2=BC=FE=C8=CB= := Janardhanan Pathangi Narasimhan = [jana@force10networks.com]
=B7=A2=CB=CD=CA=B1=BC=E4= := 2012=C4=EA= 3=D4=C2= 28=C8=D5= 22:52
=B5=BD= := Mingui Zhang
Cc: rbridge@postel.org
=D6=F7=CC=E2= := 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: =B4=F0=B8=B4= : [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

=B7=A2=BC=FE=C8=CB= := Janardhanan Pathangi Narasimhan = [jana@force10networks.com]
=B7=A2=CB=CD=CA=B1=BC=E4= := 2012=C4=EA= 3=D4=C2= 28=C8=D5= 19:14
=B5=BD= := Rohit Watve (rwatve); Mingui Zhang; Radia Perlman; Tissa Senevirathne = (tsenevir)
Cc: rbridge@postel.org
=D6=F7=CC=E2= := 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: =B4=F0=B8=B4: [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    &nb= sp; |YES         = |NO         = |NO        = |NO          = |NO           = |

+--------+------------+-------= ----+----------+------------+-------------|

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

+--------+------------+-------= ----+----------+------------+-------------|

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

+--------+------------+-------= ----+----------+------------+-------------+

Thanks,

Mingui

 

=B7=A2=BC=FE=C8=CB: rbridge-bounces@postel.org = [rbridge-bounces@postel.org] = =B4=FA=B1=ED Radia Perlman = [radiaperlman@gmail.com]

=B7=A2=CB=CD=CA=B1=BC=E4= : 2012=C4=EA3=D4=C228=C8=D5 12:52

=B5=BD: Tissa Senevirathne = (tsenevir)

Cc: rbridge@postel.org

=D6=F7=CC=E2: 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

 

=
------_=_NextPart_001_01CD1024.617B85AA-- --===============1555501365== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge --===============1555501365==-- From rbridge-bounces@postel.org Mon Apr 2 08:29:40 2012 Return-Path: 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 A271021F8575 for ; Mon, 2 Apr 2012 08:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.062 X-Spam-Level: **** X-Spam-Status: No, score=4.062 tagged_above=-999 required=5 tests=[AWL=1.011, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, MIME_HTML_MOSTLY=0.001, 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 hvWSu1d5HOr4 for ; Mon, 2 Apr 2012 08:29:38 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 44EBE21F857F for ; Mon, 2 Apr 2012 08:29:38 -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 q32EwYJX016297; Mon, 2 Apr 2012 07:58:38 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [58.251.152.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q32Eulwc015944 for ; Mon, 2 Apr 2012 07:56:57 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M1U008JWXDY8F@szxga05-in.huawei.com> for rbridge@postel.org; Mon, 02 Apr 2012 22:53:58 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M1U00792XDYSW@szxga05-in.huawei.com> for rbridge@postel.org; Mon, 02 Apr 2012 22:53:58 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHZ50127; Mon, 02 Apr 2012 22:53:57 +0800 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 02 Apr 2012 22:53:56 +0800 Received: from SZXEML507-MBS.china.huawei.com ([169.254.7.100]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.003; Mon, 02 Apr 2012 22:53:53 +0800 Date: Mon, 02 Apr 2012 14:53:51 +0000 From: Mingui Zhang Subject: =?gb2312?B?tPC4tDogW3JicmlkZ2VdIENhbGwgZm9yIGRyYWZ0LXRpc3NhLXRyaWxsLWNt?= =?gb2312?Q?t-00_to_WG_draft?= In-reply-to: <344037D7CFEFE84E97E9CC1F56C5F4A5DA122A@xmb-sjc-214.amer.cisco.com> X-Originating-IP: [172.24.1.45] To: "Tissa Senevirathne (tsenevir)" , Janardhanan Pathangi Narasimhan Message-id: <4552F0907735844E9204A62BBDD325E728CB1FA4@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//+PaAIAAy5WsgAAUHfCAABB74IAAKcBDgAASQ3CAAUvIPoAAP81cgAAoPaCAACBD3IAAtGNggAAT3tCAAA2IQIAADzCAgAAD9ECAA6fZcIABd2IM X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <344037D7CFEFE84E97E9CC1F56C5F4A5DA0303@xmb-sjc-214.amer.cisco.com> <4552F0907735844E9204A62BBDD325E728CAD030@SZXEML507-MBS.china.huawei.com> <344037D7CFEFE84E97E9CC1F56C5F4A5DA05D7@xmb-sjc-214.amer.cisco.com> <4552F0907735844E9204A62BBDD325E728CAE193@SZXEML507-MBS.china.huawei.com> <4552F0907735844E9204A62BBDD325E728CAE2F1@SZXEML507-MBS.china.huawei.com> <4552F0907735844E9204A62BBDD325E728CAE77F@SZXEML507-MBS.china.huawei.com> <4552F0907735844E9204A62BBDD325E728CB086C@SZXEML507-MBS.china.huawei.com> <4552F0907735844E9204A62BBDD325E728CB0B20@SZXEML507-MBS.china.huawei.com> <344037D7CFEFE84E97E9CC1F56C5F4A5DA122A@xmb-sjc-214.amer.cisco.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: zhangmingui@huawei.com Cc: "rbridge@postel.org" X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1520252617==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org --===============1520252617== Content-type: multipart/alternative; boundary="Boundary_(ID_qB4eKtWtsHghl7d3R0jKSw)" Content-language: zh-CN --Boundary_(ID_qB4eKtWtsHghl7d3R0jKSw) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 SGkgVGlzc2EsDQoNCldlIGtub3cgdGhhdCBSQnJpZGdlIEFnZ3JlZ2F0aW9uIGlzIHVzZWQgdG8g aW5jcmVhc2UgdGhlIGFjY2VzcyBjYXBhY2l0eSB3aXRob3V0IHVwZ3JhZGUgb2YgdGhlIFJCcmlk Z2VzLiBUaGUgbW90aXZhdGlvbiBpcyB0aGUgc2FtZSBhcyB0aGUgdHJhZGl0aW9uYWwgTEFHOiBp dCB3aWxsIGhlbHAgY3VzdG9tZXJzIHRvIHJlZHVjZSB0aGVpciBpbnZlc3RtZW50LiBJZiBhY3Rp dmUtYWN0aXZlIG11bHRpLWhvbWluZyBjYW4gd29yayB3ZWxsLCBjdXN0b21lcnMgd2lsbCBlYWdl ciB0byBwdXJjaGFzZSBNVCBmZWF0dXJlLiBJdCBtYXkgZXZlbiBhY3QgYXMgYSBmYWN0b3IgdGhh dCBwcm9tb3RlcyBNVC1UUklMTCwgd2hvIGtub3dzLg0KDQpPbiB0aGUgb3RoZXIgaGFuZCwgc2lu Y2UgTVRSQSBpcyBiYWNrd2FyZCBjb21wYXRpYmxlLCBpdCBhbGxvd3Mgb3RoZXIgbm9uLU1UUkEg c29sdXRpb25zIGNvLWV4aXN0IGluIHRoZSBjYW1wdXMuIFRoZXNlIHNvbHV0aW9ucyB3b3JrIGlu IHRoZSBiYXNlIHRvcG9sb2d5LiBUaGVzZSBzb2x1dGlvbnMgbWF5IGluY2x1ZGUgdHVubmVsaW5n IGFwcHJvYWNoLiBBcyB3ZSBrbm93LCB0dW5uZWxpbmcgaGFkIGJlZW4gd2lkZWx5IHVzZWQgb24g dHJhZGl0aW9uYWwgc3dpdGNoZXMuIElmIHRoZXJlIGFyZSBjdXN0b21lcnMgd2hvIHJlYWxseSBk byBub3QgbGlrZSBNVCwganVzdCB1c2UgdHVubmVsaW5nIGFwcHJvYWNoIG9yIG90aGVycy4NCg0K SG93ZXZlciwgSSBkb24ndCB0aGluayB0aGF0IG11bHRpLXRvcG9sb2d5IGlzIHRoYXQgZXhwZW5z aXZlLiBJIGJlbGlldmUgeW91IGhhdmUgaGVhcmQgb2Ygc2lsaWNvbnMgb3IgaW1wbGVtZW50YXRp b25zIGFscmVhZHkgc3VwcG9ydCBtdWx0aS10b3BvbG9neSBmZWF0dXJlIGJlZm9yZSAyMDEwIHdo ZW4gUkZDIDYzMjUgd2FzIHB1Ymxpc2hlZC4NCg0KVGhhbmtzLA0KTWluZ3VpDQoNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogVGlzc2EgU2VuZXZpcmF0aG5lICh0 c2VuZXZpcikgW3RzZW5ldmlyQGNpc2NvLmNvbV0NCreiy83KsbzkOiAyMDEyxOo01MIyyNUgMDoy Nw0Ktb06IEphbmFyZGhhbmFuIFBhdGhhbmdpIE5hcmFzaW1oYW47IE1pbmd1aSBaaGFuZw0KQ2M6 IHJicmlkZ2VAcG9zdGVsLm9yZw0K1vfM4jogUkU6IFtyYnJpZGdlXSBDYWxsIGZvciBkcmFmdC10 aXNzYS10cmlsbC1jbXQtMDAgdG8gV0cgZHJhZnQNCg0KSGkgTWluZ3VpDQoNCkkgaGF2ZSBub3Qg c2VlbiBhbiBhbnN3ZXIgZm9yIHRoZSBxdWVzdGlvbnMgYmVsb3cgY291bGQgeW91IHBsZWFzZSBh bnN3ZXIgc2ltcGxlIHF1ZXN0aW9uOg0KDQpXaGF0IGlzIHlvdXIgcHJvcG9zYWwgZm9yIGFjdGl2 ZS1hY3RpdmUgZm9yIHBlb3BsZSB3aG8gZG8gbm90IHdhbnQgdG8gcnVuIG11bHRpLXRvcG9sb2d5 ID8NCg0KRnJvbTogVGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZpcikNClNlbnQ6IEZyaWRheSwg TWFyY2ggMzAsIDIwMTIgMTozNyBBTQ0KVG86IFRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIp OyAnSmFuYXJkaGFuYW4gUGF0aGFuZ2kgTmFyYXNpbWhhbic7ICdNaW5ndWkgWmhhbmcnDQpDYzog J3JicmlkZ2VAcG9zdGVsLm9yZycNClN1YmplY3Q6IFJFOiBbcmJyaWRnZV0gQ2FsbCBmb3IgZHJh ZnQtdGlzc2EtdHJpbGwtY210LTAwIHRvIFdHIGRyYWZ0DQoNClNtYWxsIHR5cG8gY29ycmVjdGlv bg0KDQpGcm9tOiBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKQ0KU2VudDogRnJpZGF5LCBN YXJjaCAzMCwgMjAxMiAxOjI1IEFNDQpUbzogJ0phbmFyZGhhbmFuIFBhdGhhbmdpIE5hcmFzaW1o YW4nOyBNaW5ndWkgWmhhbmcNCkNjOiByYnJpZGdlQHBvc3RlbC5vcmc8bWFpbHRvOnJicmlkZ2VA cG9zdGVsLm9yZz4NClN1YmplY3Q6IFJFOiBbcmJyaWRnZV0gQ2FsbCBmb3IgZHJhZnQtdGlzc2Et dHJpbGwtY210LTAwIHRvIFdHIGRyYWZ0DQoNCkphbmEgaXMgYWJzb2x1dGVseSBjb3JyZWN0IG9u IHRoZSBvYnNlcnZhdGlvbiBiZWxvdy4NCg0KT25lIG1vcmUgcG9pbnQgdG8gYWRkLCBhcyBoYXZl IGluZGljYXRlZCBlYXJsaWVyDQoNCg0KMS4gICAgICAgTm90IGFsbCBjdXN0b21lciB3aWxsIHJ1 biBtdWx0aS10b3BvbG9neQ0KDQoyLiAgICAgICBZb3UgY2Fubm90IGZvcmNlIGN1c3RvbWVycyB0 byBydW4gbXVsdGktdG9wb2xvZ3kgd2hlbiB0aGV5IG5lZWQgYWN0aXZlLWFjdGl2ZSBmb3J3YXJk aW5nDQoNCjMuICAgICAgIFdoYXQgaXMgeW91ciBzb2x1dGlvbiBmb3IgY3VzdG9tZXJzIHdobyAq ZG8gTk9UKiB3YW50IHRvIHJ1biBtdWx0aS10b3BvbG9neSA/DQoNCkZyb206IHJicmlkZ2UtYm91 bmNlc0Bwb3N0ZWwub3JnPG1haWx0bzpyYnJpZGdlLWJvdW5jZXNAcG9zdGVsLm9yZz4gW21haWx0 bzpyYnJpZGdlLWJvdW5jZXNAcG9zdGVsLm9yZ10gT24gQmVoYWxmIE9mIEphbmFyZGhhbmFuIFBh dGhhbmdpIE5hcmFzaW1oYW4NClNlbnQ6IEZyaWRheSwgTWFyY2ggMzAsIDIwMTIgMTI6MzAgQU0N ClRvOiBNaW5ndWkgWmhhbmcNCkNjOiByYnJpZGdlQHBvc3RlbC5vcmc8bWFpbHRvOnJicmlkZ2VA cG9zdGVsLm9yZz4NClN1YmplY3Q6IFJlOiBbcmJyaWRnZV0gQ2FsbCBmb3IgZHJhZnQtdGlzc2Et dHJpbGwtY210LTAwIHRvIFdHIGRyYWZ0DQoNCkhpIE1pbmd1aQ0KDQogIFdoZW4geW91IHJlYWxp emUgYWN0aXZlLWFjdGl2ZSwgeW91IGFyZSBhc2tpbmcgZm9yIHRoZSBhY3RpdmUtYWN0aXZlIHRv IGJlIHNldHVwIGluIGEgbmV3IHRvcG9sb2d5IGFuZCBub3QgdGhlIGJhc2UgdG9wb2xvZ3kuIFNv IHRoZXNlIG5vZGVzIHdoaWNoIG5lZWQgdG8gdGFsayB0byB0aGUgb3RoZXIgbm9kZXMgd2hpY2gg YXJlIGJlaGluZCBub24tTVQgUkJyaWRnZXMgY2Fubm90IGRvIHNvIGFueSBtb3JlLg0KDQogIFNw ZWNpZmljYWxseSBmb3IgTVQgdG8gYmUgYmFja3dhcmQgY29tcGF0aWJsZSwgeW91IG5lZWQgYWxs IG5vZGVzIHdoaWNoIHdhbnQgdG8gdGFsayB0byBlYWNoIG90aGVyIHBhcnQgb2YgdGhlIGJhc2Ug dG9wb2xvZ3kuIElmIHlvdSBkbyB0aGF0IHlvdSBjYW5ub3QgcmVhbGl6ZSBhY3RpdmUtYWN0aXZl LiBJZiB5b3UgcHV0IHRoZSBhY3RpdmUtYWN0aXZlIGluIGEgbmV3IHRvcG9sb2d5LCB0aGFuIHRo ZXkgY2FuIG5vIGxvbmdlciB0YWxrIHRvIG5vZGVzIG9uIHRoZSBiYXNlIHRvcG9sb2d5IG9mIG5v bi1NVCBSQnJpZGdlcy4NCg0KU28geWVzLCBNVC1UUklMTCBpcyBiYWNrd2FyZCBjb21wYXRpYmxl IGZvciBiYXNlIHRvcG9sb2d5LCBidXQgdGhlIHJlYWxpemF0aW9uIG9mIGFjdGl2ZS1hY3RpdmUg d2l0aCBNVCCoQyBUUklMTCBpcyBub3QgYmFja3dhcmQgY29tcGF0aWJsZS4gVGhhdCB3YXMgdGhl IHBvaW50IEkgd2FzIGJyaW5naW5nIHVwLg0KDQpUaGFua3MNCkphbmENCg0KDQpGcm9tOiBNaW5n dWkgWmhhbmcgW21haWx0bzp6aGFuZ21pbmd1aUBodWF3ZWkuY29tXQ0KU2VudDogRnJpZGF5LCBN YXJjaCAzMCwgMjAxMiAxMjoxNSBQTQ0KVG86IEphbmFyZGhhbmFuIFBhdGhhbmdpIE5hcmFzaW1o YW4NCkNjOiByYnJpZGdlQHBvc3RlbC5vcmc8bWFpbHRvOnJicmlkZ2VAcG9zdGVsLm9yZz4NClN1 YmplY3Q6ILTwuLQ6IFtyYnJpZGdlXSBDYWxsIGZvciBkcmFmdC10aXNzYS10cmlsbC1jbXQtMDAg dG8gV0cgZHJhZnQNCg0KSGkgSmFuYSwNCg0KQWxsIFJCcmlkZ2VzIGluIHRoZSBjYW1wdXMgYXJl IGluIHRoZSBiYXNlIHRvcG9sb2d5LiBNVCBSQnJpZGdlcyBjYW4gd2VsbCBjb21tdW5pY2F0ZSB3 aXRoIG5vbi1NVCBSQnJpZGdlcyB1c2luZyB0aGUgYmFzZSB0b3BvbG9neS4NCg0KSSBmZWVsIHRo YXQgeW91IGFyZSBhcmd1aW5nIHRoYXQgTVQtVFJJTEwgaXMgbm90IGJhY2t3YXJkIGNvbXBhdGli bGUuIFRoYXQgaXMgYSBpbmNvcnJlY3QganVkZ2VtZW50Lg0KDQpUaGFua3MsDQpNaW5ndWkNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IEphbmFyZGhhbmFuIFBhdGhh bmdpIE5hcmFzaW1oYW4gW2phbmFAZm9yY2UxMG5ldHdvcmtzLmNvbV0NCreiy83KsbzkOiAyMDEy xOoz1MIzMMjVIDEzOjI5DQq1vTogTWluZ3VpIFpoYW5nDQpDYzogcmJyaWRnZUBwb3N0ZWwub3Jn PG1haWx0bzpyYnJpZGdlQHBvc3RlbC5vcmc+DQrW98ziOiBSRTogW3JicmlkZ2VdIENhbGwgZm9y IGRyYWZ0LXRpc3NhLXRyaWxsLWNtdC0wMCB0byBXRyBkcmFmdA0KSGkgTWluZ3VpLA0KDQpXaXRo IE1UIGFwcHJvYWNoLCB3aGVuIHR3byBSQnJpZGdlcyB3aGljaCBoYWQgc3RhdGlvbnMgdGFsa2lu ZyB0byBlYWNoIG90aGVyIGFuZCBvbmUgb2YgdGhlbSBpcyBjb252ZXJ0ZWQgdG8gTVQsIHRoZW4g dGhlIGNvbW11bmljYXRpb24gaXMgYnJva2VuLiBTbyBpdCBkb2VzIG5vdCBoYXZlIGJhY2t3YXJk IGNvbXB1dGFiaWxpdHkuDQoNClRoYW5rcw0KSmFuYQ0KDQoNCkZyb206IE1pbmd1aSBaaGFuZyBb bWFpbHRvOnpoYW5nbWluZ3VpQGh1YXdlaS5jb21dDQpTZW50OiBGcmlkYXksIE1hcmNoIDMwLCAy MDEyIDEyOjI3IEFNDQpUbzogSmFuYXJkaGFuYW4gUGF0aGFuZ2kgTmFyYXNpbWhhbg0KQ2M6IHJi cmlkZ2VAcG9zdGVsLm9yZzxtYWlsdG86cmJyaWRnZUBwb3N0ZWwub3JnPg0KU3ViamVjdDogtPC4 tDogW3JicmlkZ2VdIENhbGwgZm9yIGRyYWZ0LXRpc3NhLXRyaWxsLWNtdC0wMCB0byBXRyBkcmFm dA0KDQpIaSBKYW5hLA0KDQpMZXQgdXMgYXNzdW1lIHRoYXQgSSBoYXZlIDIwIFJCcmlkZ2VzIGlu IHRoZSBjYW1wdXMgd2hpY2ggaGF2ZSBlbmQgc3lzdGVtcyBjb25uZWN0ZWQgdG8gaXQsIGFuZCBh bGwgb2YgdGhlbSBuZWVkIHRvIGJlIHJlYWNoYWJsZS4gU28gaWYgYSBmZXcgb2YgdGhlbSBhcmUg Y29udmVydGVkIHRvIE1UUkEgUkJyaWRnZXMgdG8gc3VwcG9ydCBhY3RpdmUtYWN0aXZlLCBkb2Vz IGl0IG1lYW4gdGhhdCBSQnJpZGdlcyB3aGljaCBhcmUgbm90IHlldCBjb252ZXJ0ZWQgd2lsbCBu b3QgYmUgYWJsZSB0byBhbnltb3JlIHNlZSB0aGUgbm9kZXMgY29ubmVjdGVkIHRvIHRoZXNlIHZp cnR1YWwgUkJyaWRnZXM/IE9yIGFtIEkgbWlzc2luZyBzb21ldGhpbmcgaGVyZT8NCg0KWk1HPiBB bHRob3VnaCBwaHlzaWNhbCByZWFjaGFiaWxpdHkgY2FuIGJlIGFsbCB0byBhbGwsIGl0IGRvZXMg bm90IG1lYW4gdGhhbiB0aGUgZW5kIHN5c3RlbXMgd2lsbCByZWFsbHkgY29tbXVuaWNhdGUgaW4g YW4gYWxsIHRvIGFsbCBtYW5uZXIuIEl0IGlzIHJlc3RyaWN0ZWQgYnkgdGhlIFZMQU4gY29uZmln dXJhdGlvbiBvZiB0aGUgY2FtcHVzLiBMZXQgbWUgZ2l2ZSB5b3UgYW4gZXhhbXBsZSwgUkIxLCBS QjIsIFJCMyBhbmQgUkI0IGhhdmUgYW4gYWxsIHRvIGFsbCBjb25uZWN0aW9uLiBUaGUgYWNjZXNz IHBvcnRzIG9mIFJCMSBhbmQgUkIzIGFyZSBjb25maWd1cmVkIGFzIHRoZSBWTEFOIGZvciBlbmQg c3lzdGVtcyBvZiB0aGUgRGVwdCBvZiBDb21wdXRlciBTY2llbmNlIHdoaWxlIHRoZSBhY2Nlc3Mg cG9ydHMgb2YgUkIyIGFuZCBSQjQgYXJlIGNvbmZpZ3VyZWQgYXMgYW5vdGhlciBWTEFOIGZvciBl bmQgc3lzdGVtcyBvZiB0aGUgRGVwdCBvZiBMaXRlcmF0dXJlLiBFbmQgc3lzdGVtcyBmcm9tIHRo ZSBzYW1lIGRlcGFydG1lbnQgY2FuIHRhbGsgd2l0aCBlYWNoIG90aGVyLiBCdXQgZW5kIHN5c3Rl bXMgZnJvbSB0d28gZGlmZmVyZW50IGRlcGFydG1lbnRzIHdpbGwgbm90IHRhbGsgd2l0aCBlYWNo IG90aGVyLg0KDQpJIGFtIG5vdCBzdXJlIGlmIHRoYXQgaXMgcHJhY3RpY2FsLCBhbmQgYWx3YXlz IHBvc3NpYmxlIG1heSBkZXBlbmQgb24gdGhlIG5vZGVzIGNvbm5lY3RlZCBhbmQgYWxzbyB3aGF0 IGNvbnRyb2xzIGFyZSBhdmFpbGFibGUgb24gdGhlbQ0KDQpaTUc+IFRoaW5rIGFib3V0IGl0LiBX aGVuIGFuIG9wZXJhdG9yIGhhdmUgYSBMQUcgY29ubmVjdGVkIHRvIGEgZ3JvdXAgb2YgUkJyaWRn ZXMsIGhlIGhhcyB0byBkZWNpZGUgd2hpY2ggcG9ydCB0byBwbHVnIHRoZSBjYWJsZXMgaW4uIEhl IG5lZWQgZW50ZXIgdGhlIGNvbnNvbGUgd2luZG93IHRvIGlucHV0IHRoZSBjb21tYW5kIGxpbmUg dG8gY29uZmlndXJlIHBhcmFtZXRlcnMgYW5kIHN0YXJ0IHRoZSBMQUcuIEhlIGFsc28gbmVlZCB0 byBjb25maWd1cmUgdGhlIHR1cGxlIHVzZWQgZm9yIGhhc2hpbmcuDQoNClRoYW5rcywNCk1pbmd1 aQ0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogSmFuYXJk aGFuYW4gUGF0aGFuZ2kgTmFyYXNpbWhhbiBbamFuYUBmb3JjZTEwbmV0d29ya3MuY29tXQ0Kt6LL zcqxvOQ6IDIwMTLE6jPUwjMwyNUgMDo0OQ0Ktb06IE1pbmd1aSBaaGFuZw0KQ2M6IHJicmlkZ2VA cG9zdGVsLm9yZzxtYWlsdG86cmJyaWRnZUBwb3N0ZWwub3JnPg0K1vfM4jogUkU6IFtyYnJpZGdl XSBDYWxsIGZvciBkcmFmdC10aXNzYS10cmlsbC1jbXQtMDAgdG8gV0cgZHJhZnQNCkhpIE1pbmd1 aSwNCg0KSSBhbSBzbGlnaHRseSBjb25mdXNlZC4NCg0KRm9yIHRoZSBpbnRyYS10b3BvbG9neSBz Y2VuYXJpbywgTVQgdW5hd2FyZSBSQnJpZGdlcyB3aWxsIG5vdCBhcHBlYXIgaW4gYSBzcGVjaWZp YyB0b3BvbG9neSBvdGhlciB0aGFuIHRoZSBiYXNlZCB0b3BvbG9neS4gSW4gb3RoZXIgd29yZHMs IE1UUkEgUkJyaWRnZXMgb25seSB0YWxrcyBvbmx5IHdpdGggTVRSQSBSQnJpZGdlcy4gU2luY2Ug dGhleSBhbGwgc3VwcG9ydCBNVCwgTVRSQSBjYW4gd29yayB2ZXJ5IHdlbGwgYW1vbmcgdGhlbS4g SW4gdGhpcyBzY2VuYXJpbywgTVRSQSBSQnJpZGdlcyBhbmQgb2xkIFJCcmlkZ2VzIGNvLWV4aXN0 IGluIHRoZSBzYW1lIGNhbXB1cy4gVGhlcmVmb3JlLCB0aGlzIGlzIGEgc29saWQgZXhhbXBsZSB0 aGF0IE1UUkEgY2FuIGJlIGRlcGxveWVkIGluY3JlbWVudGFsbHkuIFJlbWVtYmVyLCBDTVQgZG9l cyBub3QgYWxsb3cgc3VjaCBraW5kIG9mIGRlcGxveW1lbnQuDQoNCkxldCB1cyBhc3N1bWUgdGhh dCBJIGhhdmUgMjAgUkJyaWRnZXMgaW4gdGhlIGNhbXB1cyB3aGljaCBoYXZlIGVuZCBzeXN0ZW1z IGNvbm5lY3RlZCB0byBpdCwgYW5kIGFsbCBvZiB0aGVtIG5lZWQgdG8gYmUgcmVhY2hhYmxlLiBT byBpZiBhIGZldyBvZiB0aGVtIGFyZSBjb252ZXJ0ZWQgdG8gTVRSQSBSQnJpZGdlcyB0byBzdXBw b3J0IGFjdGl2ZS1hY3RpdmUsIGRvZXMgaXQgbWVhbiB0aGF0IFJCcmlkZ2VzIHdoaWNoIGFyZSBu b3QgeWV0IGNvbnZlcnRlZCB3aWxsIG5vdCBiZSBhYmxlIHRvIGFueW1vcmUgc2VlIHRoZSBub2Rl cyBjb25uZWN0ZWQgdG8gdGhlc2UgdmlydHVhbCBSQnJpZGdlcz8gT3IgYW0gSSBtaXNzaW5nIHNv bWV0aGluZyBoZXJlPw0KDQpGb3IgdGhlIGludGVyLXRvcG9sb2d5IHNjZW5hcmlvLCB3ZSBhc3N1 bWUgTVRSQSBSQnJpZGdlcyBoYXZlIHRvIHRhbGsgd2l0aCBNVCB1bmF3YXJlIFJCcmlkZ2VzIChU aGlzIGlzIGEgcmlnb3JvdXMgYXNzdW1wdGlvbi4pIElmIG9wZXJhdG9ycyBkbyB3YW50IHRvIHJl YWxpemUgc3VjaCBraW5kIG9mIGNvbm5lY3Rpb24sIGl0IGlzIHJlYXNvbmFibGUgdG8gYXNzdW1l IHRoZXkgd2lsbCBhY2NlcHQgdGhlIHJlcXVpcmVtZW50IHRoYXQgdGhleSBuZWVkIHRvIGNvbmZp Z3VyZSB0aGVpciBoYXNoaW5nIGZ1bmN0aW9uIHRvIHJlbW92ZSB0aGUgcG9zc2libGUgTUFDIGZs aXAtZmxvcC4NCg0KSSBhbSBub3Qgc3VyZSBpZiB0aGF0IGlzIHByYWN0aWNhbCwgYW5kIGFsd2F5 cyBwb3NzaWJsZSBtYXkgZGVwZW5kIG9uIHRoZSBub2RlcyBjb25uZWN0ZWQgYW5kIGFsc28gd2hh dCBjb250cm9scyBhcmUgYXZhaWxhYmxlIG9uIHRoZW0NCg0KVGhhbmtzDQpKYW5hDQoNClRoYW5r cywNCk1pbmd1aQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogcmJy aWRnZS1ib3VuY2VzQHBvc3RlbC5vcmc8bWFpbHRvOnJicmlkZ2UtYm91bmNlc0Bwb3N0ZWwub3Jn PiBbcmJyaWRnZS1ib3VuY2VzQHBvc3RlbC5vcmddILT6se0gTWluZ3VpIFpoYW5nIFt6aGFuZ21p bmd1aUBodWF3ZWkuY29tXQ0Kt6LLzcqxvOQ6IDIwMTLE6jPUwjI5yNUgMTg6NTANCrW9OiBKYW5h cmRoYW5hbiBQYXRoYW5naSBOYXJhc2ltaGFuDQpDYzogcmJyaWRnZUBwb3N0ZWwub3JnPG1haWx0 bzpyYnJpZGdlQHBvc3RlbC5vcmc+DQrW98ziOiC08Li0OiBbcmJyaWRnZV0gQ2FsbCBmb3IgZHJh ZnQtdGlzc2EtdHJpbGwtY210LTAwIHRvIFdHIGRyYWZ0DQpIaSBKYW5hLA0KDQo+SW4gc2VjdGlv biA0LjEsIGNvdWxkIHlvdSBwbGVhc2UgZXhwbGFpbiBob3cgdGhlIGZyYW1lIHRoYXQgaXMgaW5n cmVzc2VkIGJ5IFJCMSB0aHJvdWdoIFJCdjAwMSBpcyByZWNlaXZlZCBhdCBSQng/DQoNClR3byBz Y2VuYXJpb3MgYXJlIGdpdmVuIGluIFNlY3Rpb24gNC4gU2VjdGlvbiA0LjEgdGFsa3MgYWJvdXQg dGhlIGludHJhLXRvcG9sb2d5IHNjZW5hcmlvLiBIZXJlLCBSQnggaXMgbm90IGluIHRvcG9sb2d5 IDEgc28gaXQgaXMgdW5yZWFjaGFibGUgYnkgUkIxLiBJdCBuZWVkIG5vdCBzZXQgdXAgYW55IGZv cndhcmRpbmcgcGF0aCB0byBSQnguDQoNClRoYW5rcywNCk1pbmd1aQ0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCreivP7IyzogSmFuYXJkaGFuYW4gUGF0aGFuZ2kgTmFyYXNpbWhh biBbamFuYUBmb3JjZTEwbmV0d29ya3MuY29tXQ0Kt6LLzcqxvOQ6IDIwMTLE6jPUwjI4yNUgMjI6 NTINCrW9OiBNaW5ndWkgWmhhbmcNCkNjOiByYnJpZGdlQHBvc3RlbC5vcmc8bWFpbHRvOnJicmlk Z2VAcG9zdGVsLm9yZz4NCtb3zOI6IFJFOiBbcmJyaWRnZV0gQ2FsbCBmb3IgZHJhZnQtdGlzc2Et dHJpbGwtY210LTAwIHRvIFdHIGRyYWZ0DQpIaSBNaW5ndWksDQoNClNlY3Rpb24gNCwgZG9lcyBu b3QgZ2l2ZSBiYWNrd2FyZCBjb21wYXRpYmlsaXR5LiBGb3IgZS5nLiBpbiBzZWN0aW9uIDQuMiBt dWx0aSBkZXN0aW5hdGlvbiBmcmFtZXMgd2lsbCBiZSBpbmdyZXNzZWQgd2l0aCB0d28gZGlmZmVy ZW50IGJyaWRnZSBJRCBjYXVzaW5nIE1BQyBtb3ZlLCBhbmQgaGF2aW5nIHRvIGltcG9zZSByZXN0 cmljdGlvbnMgb24gaGFzaGluZyBmdW5jdGlvbnMgYXQgdGhlIGV4dGVybmFsIG5vZGUgbWF5IG9y IG1heSBub3QgYmUgYWNjZXB0YWJsZSAuIEkgYW0gbm90IHN1cmUgdGhhdCB0aGlzIGNhbiBiZSBj bGFzc2lmaWVkIGFzIGJhY2t3YXJkIGNvbXBhdGlibGUgc2luY2UgaXQgaXMgbm90IGEgZnVsbCBz b2x1dGlvbiBhbmQgY2FuIGFsc28gY2F1c2UgZnJlcXVlbnQgTUFDIGZsaXAgZmxvcHMgZXRjLg0K DQpJbiBzZWN0aW9uIDQuMSwgY291bGQgeW91IHBsZWFzZSBleHBsYWluIGhvdyB0aGUgZnJhbWUg dGhhdCBpcyBpbmdyZXNzZWQgYnkgUkIxIHRocm91Z2ggUkJ2MDAxIGlzIHJlY2VpdmVkIGF0IFJC eD8NCg0KVGhhbmtzDQpKYW5hDQoNCg0KRnJvbTogTWluZ3VpIFpoYW5nIFttYWlsdG86emhhbmdt aW5ndWlAaHVhd2VpLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMjgsIDIwMTIgNzoxNSBQ TQ0KVG86IEphbmFyZGhhbmFuIFBhdGhhbmdpIE5hcmFzaW1oYW4NCkNjOiByYnJpZGdlQHBvc3Rl bC5vcmc8bWFpbHRvOnJicmlkZ2VAcG9zdGVsLm9yZz4NClN1YmplY3Q6ILTwuLQ6IFtyYnJpZGdl XSBDYWxsIGZvciBkcmFmdC10aXNzYS10cmlsbC1jbXQtMDAgdG8gV0cgZHJhZnQNCg0KSGkgSmFu YSwNCg0KSSB0aGluayBJIHNob3VsZCBhbnN3ZXIgeW91ciBxdWVzdGlvbi4gSSBhbSBNaW5ndWkg WmhhbmcuDQpQbGVhc2UgcmVmZXIgdG8gdGhlIGRyYWZ0IGh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXpoYW5nLXRyaWxsLW11bHRpLXRvcG8tcnBmYy0wMC4gU2VjdGlvbiA0IGlzIHJp Z2h0IGZvciB0aGUgdG9waWMgeW91IGFyZSBpbnRlcmVzdGVkLiBBcyBhIHN0YXJ0ZXIgZHJhZnQg b24gdGhlIFJQRkMgdXNpbmcgTXVsdGktdG9wb2xvZ3kuIEkgd2lsbCBiZSBoYXBweSB0byByZWNl aXZlIHlvdXIgY29tbWVudHMuDQoNClRoYW5rcywNCk1pbmd1aQ0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCreivP7IyzogSmFuYXJkaGFuYW4gUGF0aGFuZ2kgTmFyYXNpbWhhbiBb amFuYUBmb3JjZTEwbmV0d29ya3MuY29tXQ0Kt6LLzcqxvOQ6IDIwMTLE6jPUwjI4yNUgMTk6MTQN CrW9OiBSb2hpdCBXYXR2ZSAocndhdHZlKTsgTWluZ3VpIFpoYW5nOyBSYWRpYSBQZXJsbWFuOyBU aXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKQ0KQ2M6IHJicmlkZ2VAcG9zdGVsLm9yZzxtYWls dG86cmJyaWRnZUBwb3N0ZWwub3JnPg0K1vfM4jogUkU6IFtyYnJpZGdlXSBDYWxsIGZvciBkcmFm dC10aXNzYS10cmlsbC1jbXQtMDAgdG8gV0cgZHJhZnQNCkhpIFpoYWksDQoNCkluIHRoZSBNdWx0 aS10b3BvbG9neSBjYXNlIEkgYW0gbm90IHN1cmUgd2hhdCBpcyBtZWFudCBieSBpbmNyZW1lbnRh bGx5IGRlcGxveWFibGUuIEFzc3VtaW5nIHRoYXQgYWxsIHRoZSBSQnJpZGdlcyBpbiB0aGUgY2Ft cHVzIGRvIG5vdCB1bmRlcnN0YW5kIE1UIGV4Y2VwdCBmb3IgdGhlIFJCcmlkZ2VzIHdoaWNoIHBh cnRpY2lwYXRlIGluIHRoZSBWaXJ0dWFsIFJCcm9kZ2UsIGl0IGxvb2tzIGxpa2UgdGhpcyB3aWxs IGNhdXNlIE1BQyBmbGlwIGZsb3Agb24gdGhlIG90aGVyIFJCcmlkZ2VzIGFuZCBvdGhlciBpc3N1 ZXMgc2luY2UgYWxsIHRoZSBvdGhlciBSQnJpZGdlcyBkbyBub3QgdW5kZXJzdGFuZCBNVC4NCg0K Q291bGQgeW91IHBsZWFzZSBleHBsYWluIGhvdyBNVCBjYW4gd29yayBpbiBzdWNoIHNjZW5hcmlv cz8NCg0KVGhhbmtzDQpKYW5hDQoNCg0KRnJvbTogcmJyaWRnZS1ib3VuY2VzQHBvc3RlbC5vcmc8 bWFpbHRvOnJicmlkZ2UtYm91bmNlc0Bwb3N0ZWwub3JnPiBbbWFpbHRvOnJicmlkZ2UtYm91bmNl c0Bwb3N0ZWwub3JnXSBPbiBCZWhhbGYgT2YgUm9oaXQgV2F0dmUgKHJ3YXR2ZSkNClNlbnQ6IFdl ZG5lc2RheSwgTWFyY2ggMjgsIDIwMTIgMzo1MyBQTQ0KVG86IE1pbmd1aSBaaGFuZzsgUmFkaWEg UGVybG1hbjsgVGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZpcikNCkNjOiByYnJpZGdlQHBvc3Rl bC5vcmc8bWFpbHRvOnJicmlkZ2VAcG9zdGVsLm9yZz4NClN1YmplY3Q6IFJlOiBbcmJyaWRnZV0g Q2FsbCBmb3IgZHJhZnQtdGlzc2EtdHJpbGwtY210LTAwIHRvIFdHIGRyYWZ0DQoNCg0KSGkgTWlu Z3VpLA0KDQo1LiBGYXN0IGNvbnZlcmdlbmNlIG9uIGZhaWx1cmUgcmVjb3ZlcnkuIFdlIGtub3cg dGhhdCByZXNpbGllbmNlIGlzIG9uZSBvZiB0aGUgdHdvIG1haW4gcHVycG9zZXMgb2YgImFnZ3Jl Z2F0aW9uIi4gVGhpcyBkaW1lbnNpb24gZGlzY3Vzc2VzIHdoZXRoZXIgdGhlIHNvbHV0aW9uIG9m ZmVycyBhIHdheSB0byBkbyBmYXN0IGZhaWx1cmUgcmVjb3Zlcnkgd2hlbiB0aGVyZSBpcyBhIGZh aWx1cmUgb2YgYW4gYWdncmVnYXRlZCBSQnJpZGdlIG9yIGxpbmsuDQoNClBOOiBOTy4gVGhlIG5l dyBkaXN0cmlidXRpb24gdHJlZSBuZWVkIHRvIGJlIHJlY29tcHV0ZWQuDQoNCkNNVDogTk8uIEEg b3ZlcmFsbCByZS1jb25maWd1cmF0aW9uIGlzIG5lY2Vzc2FyeS4NCg0KTVRSQTogWUVTLg0KDQpD TVQgZG9lcyBub3QgbmVlZCByZWNvbmZpZ3VyYXRpb24uIElmIG9uZSBSYnJpZGdlIGFkdmVydGl6 aW5nIGFmZmluaXR5IHRsdiBnb2VzIGRvd24sIHRoZSB0cmVlIGNhbiBiZSByb290ZWQgYXQgdGhl IG90aGVyIEVncmVzcyBSYnJpZGdlIElEIGFkdmVydGl6aW5nIGFmZmluaXR5IHRsdi4NCg0KQWxz bywgY29uc2lkZXIgYWRkaW5nIGZvbGxvd2luZyB0byB0aGUgY29tcGFyaXNvbiB0YWJsZQ0KDQpO dW1iZXIgb2YgTmV3IFRMVnMgKGFuZCByZXN1bHRpbmcgY29tcGxleGl0eSkNCg0KUE46IDMNCg0K Q01UOiAxDQoNCk1UUkE6IG11bHRpcGxlDQoNClRoYW5rcw0KUm9oaXQNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IHJicmlkZ2UtYm91bmNlc0Bwb3N0ZWwub3JnPG1haWx0bzpy YnJpZGdlLWJvdW5jZXNAcG9zdGVsLm9yZz4gW21haWx0bzpyYnJpZGdlLWJvdW5jZXNAcG9zdGVs Lm9yZ10gT24gQmVoYWxmIE9mIE1pbmd1aSBaaGFuZw0KU2VudDogV2VkbmVzZGF5LCBNYXJjaCAy OCwgMjAxMiAyOjEwIEFNDQpUbzogUmFkaWEgUGVybG1hbjsgVGlzc2EgU2VuZXZpcmF0aG5lICh0 c2VuZXZpcikNCkNjOiByYnJpZGdlQHBvc3RlbC5vcmc8bWFpbHRvOnJicmlkZ2VAcG9zdGVsLm9y Zz4NClN1YmplY3Q6ILTwuLQ6IFtyYnJpZGdlXSBDYWxsIGZvciBkcmFmdC10aXNzYS10cmlsbC1j bXQtMDAgdG8gV0cgZHJhZnQNCg0KSGkgUmFkaWEsDQoNCkl0IGlzIGEgZ29vZCBpZGVhIHRvIGxp c3QgdGhlIFByb3MgYW5kIENvbnMgb2YgZWFjaCBzb2x1dGlvbi4gVGhlcmUgYXJlIHRocmVlIGNh bmRpZGF0ZSBzb2x1dGlvbnMgZm9yIHRoZSBzYW1lIFJQRkMgcHJvYmxlbTogUE4sIENNVCBhbmQg TVRSQSAoTXVsdGktVG9wb2xvZ3kgVFJJTEwgZm9yIFJCcmlkZ2UgQWdncmVnYXRpb24pLiBMZXQg bWUgY29tcGFyZSB0aGVtIGluIHRoZSBmb2xsb3dpbmcgZGltZW5zaW9ucy4NCg0KMS4gV2hldGhl ciB0aGUgc29sdXRpb24gaXMgaW5jcmVtZW50YWxseSBkZXBsb3ktYWJsZS4NCg0KUE46IFlFUy4N Cg0KQ01UOiBOTy4NCg0KTVRSQTogWUVTLg0KDQoyLiBVc2Ugb25seSBleGlzdGluZyBzaWxpY29u cy4NCg0KUE46IE5PLiBOZXcgc2lsaWNvbiBpcyBuZWNlc3NhcnkgdG8gc3VwcG9ydCAidHVubmVs aW5nIiBvciBlbHNlIE1BQyBhZGRyZXNzZXMgbWF5IGZsaXAtZmxvcC4NCg0KQ01UOiBZRVMuDQoN Ck1UUkE6IEN1cnJlbnRseSBOTy4gQnV0IGFmdGVyIG11bHRpLXRvcG9sb2d5IGlzIHN1cHBvcnRl ZCBieSBUUklMTCwgaXQgaXMgYSAiWUVTIi4NCg0KMy4gTXVsdGktY2FzdCB0cmFmZmljIHVwIGZy b20gUkJ2IGNhbiBiZSBsb2FkLWJhbGFuY2VkLg0KDQpQTjogTk8uDQoNCkNNVDogWUVTLg0KDQpN VFJBOiBZRVMuDQoNCjQuIE11bHRpLWNhc3QgdHJhZmZpYyBkb3duIHRvIFJCdiBjYW4gYmUgbG9h ZC1iYWxhbmNlZC4NCg0KUE46IE5PLg0KDQpDTVQ6IFlFUy4NCg0KTVRSQTogWUVTLg0KDQo1LiBG YXN0IGNvbnZlcmdlbmNlIG9uIGZhaWx1cmUgcmVjb3ZlcnkuIFdlIGtub3cgdGhhdCByZXNpbGll bmNlIGlzIG9uZSBvZiB0aGUgdHdvIG1haW4gcHVycG9zZXMgb2YgImFnZ3JlZ2F0aW9uIi4gVGhp cyBkaW1lbnNpb24gZGlzY3Vzc2VzIHdoZXRoZXIgdGhlIHNvbHV0aW9uIG9mZmVycyBhIHdheSB0 byBkbyBmYXN0IGZhaWx1cmUgcmVjb3Zlcnkgd2hlbiB0aGVyZSBpcyBhIGZhaWx1cmUgb2YgYW4g YWdncmVnYXRlZCBSQnJpZGdlIG9yIGxpbmsuDQoNClBOOiBOTy4gVGhlIG5ldyBkaXN0cmlidXRp b24gdHJlZSBuZWVkIHRvIGJlIHJlY29tcHV0ZWQuDQoNCkNNVDogTk8uIEEgb3ZlcmFsbCByZS1j b25maWd1cmF0aW9uIGlzIG5lY2Vzc2FyeS4NCg0KTVRSQTogWUVTLg0KDQpUaGUgZm9sbG93aW5n IHRhYmxlIGxpc3RzIGFsbCBhYm92ZSBjb21wYXJpc29ucyAoQSBqcGcgdmVyc2lvbiBpcyBhbHNv IGF0dGFjaGVkIGp1c3QgaW4gY2FzZS4pLiBNVFJBIGlzIGFsd2F5cyBZRVMuIEkgdGhpbmsgaXQg ZGVzZXJ2ZXMgb3VyIGZvbGxvdy11cC4NCg0KKy0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLSstLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKw0KDQp8U29sdXRpb258 SW5jcmUtRGVwbG95fE9sZCBTaWxpY29ufExCIFVwd2FyZHN8TEIgRG93bndhcmRzfEZhc3QgQ29u dmVyZ2V8DQoNCistLS0tLS0tLSstLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tLSst LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLXwNCg0KfFBOICAgICAgfFlFUyAgICAgICAgIHxOTyAg ICAgICAgIHxOTyAgICAgICAgfE5PICAgICAgICAgIHxOTyAgICAgICAgICAgfA0KDQorLS0tLS0t LS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKy0tLS0t LS0tLS0tLS18DQoNCnxDTVQgICAgIHxOTyAgICAgICAgICB8WUVTICAgICAgICB8WUVTICAgICAg IHxZRVMgICAgICAgICB8Tk8gICAgICAgICAgIHwNCg0KKy0tLS0tLS0tKy0tLS0tLS0tLS0tLSst LS0tLS0tLS0tLSstLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tfA0KDQp8TVRS QSAgICB8WUVTICAgICAgICAgfFlFUyh3aWxsKSAgfFlFUyAgICAgICB8WUVTICAgICAgICAgfFlF UyAgICAgICAgICB8DQoNCistLS0tLS0tLSstLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0t LS0tLSstLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLSsNCg0KVGhhbmtzLA0KDQpNaW5ndWkNCg0K DQq3orz+yMs6IHJicmlkZ2UtYm91bmNlc0Bwb3N0ZWwub3JnPG1haWx0bzpyYnJpZGdlLWJvdW5j ZXNAcG9zdGVsLm9yZz4gW3JicmlkZ2UtYm91bmNlc0Bwb3N0ZWwub3JnXSC0+rHtIFJhZGlhIFBl cmxtYW4gW3JhZGlhcGVybG1hbkBnbWFpbC5jb21dDQoNCreiy83KsbzkOiAyMDEyxOoz1MIyOMjV IDEyOjUyDQoNCrW9OiBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKQ0KDQpDYzogcmJyaWRn ZUBwb3N0ZWwub3JnPG1haWx0bzpyYnJpZGdlQHBvc3RlbC5vcmc+DQoNCtb3zOI6IFJlOiBbcmJy aWRnZV0gQ2FsbCBmb3IgZHJhZnQtdGlzc2EtdHJpbGwtY210LTAwIHRvIFdHIGRyYWZ0DQoNCg0K SXQgaXMgbXkgdW5kZXJzdGFuZGluZyB0aGF0DQoNCmEpIENNVCBkb2VzIHJlcXVpcmUgY2hhbmdp bmcgYWxsIHRoZSBSQnMgaW4gdGhlIGNhbXB1cw0KDQpiKSBDTVQgcmVxdWlyZXMgdGhlcmUgYmUg YXQgbGVhc3QgYXMgbWFueSB0cmVlcyBhcyB0aGVyZSBhcmUgYWN0aXZlL2FjdGl2ZSBSQnMgb24g YW55IGxpbmsNCg0KDQoNCk9mIGNvdXJzZSwgbm8gc29sdXRpb24gaXMgaWRlYWwuICBJdCBtaWdo dCBoYXZlIGJlZW4gbmljZSB0byB3cml0ZSB1cCBhbGwgdGhlIHByb3Bvc2VkIHNvbHV0aW9ucyB0 byB0aGlzIGFuZCBwcm9zL2NvbnMuIE1heWJlIGl0J3MNCg0Kc3RpbGwgd29ydGggZG9pbmcuDQoN Cg0KDQpTbyBmcm9tIG1lbW9yeS4uLm90aGVyIHByb3Bvc2FscyBmb3IgYWxsb3dpbmcgUjEsIFIy LCBhbmQgUjMgdG8gYmUgYWN0aXZlL2FjdGl2ZS9hY3RpdmUgb24gYSBsaW5rOg0KDQoNCg0KRmly c3Qgbm90ZTogcmVnYXJkbGVzcyBvZiB3aGV0aGVyIHRoZWlyIHBvcnQgdG8gdGhlIGxpbmsgaXMg aW4gYSB0cmVlLCB1bmljYXN0IHdvcmtzLCBhbmQgdGhleSBjYW4gdXNlIHRoZSBwc2V1ZG9ub2Rl DQoNCm5pY2tuYW1lIHdoZW4gZW5jYXBzdWxhdGluZyB1bmljYXN0Lg0KDQoNCg0KQWxzbywgaWYg UmkncyBwb3J0IHRvIHRoZSBsaW5rIGlzIGluIGF0IGxlYXN0IG9uZSB0cmVlLCBSaSBjYW4gdXNl IHRoZSBwc2V1ZG9ub2RlIG5pY2tuYW1lIGZvciB0aGF0IGxpbmsgd2hlbiBlbmNhcHN1bGF0aW5n DQoNCm11bHRpZGVzdGluYXRpb24gZnJhbWVzIGZvciBpbmdyZXNzLCBhbmQgdGhlIFJQRiBjaGVj ayB3aWxsIHdvcmsgd2l0aG91dCBhbnkgcHJvYmxlbXMuDQoNCg0KDQpIb3dldmVyLCBpZiBSaSdz IHBvcnQgdG8gdGhlIGxpbmsgaXMgbm90IGluIGFueSBvZiB0aGUgdHJlZXMsDQoNCmhlcmUgd2Vy ZSBzb21lIG9mIHRoZSBwcm9wb3NlZCBzb2x1dGlvbnMuICBTbywgbGV0J3Mgc2F5IHRoYXQgUjEg YW5kIFIyJ3MgcG9ydCB0byB0aGUgc2hhcmVkIGxpbmsgaXMgaW4gYXQgbGVhc3Qgb25lIHRyZWUs IGFuZCBSMydzDQoNCnBvcnQgdG8gdGhlIGxpbmsgaXMgbm90IGluIGFueSBvZiB0aGUgdHJlZXMs IGFuZCBSMyBuZWVkcyB0byBlbmNhcHN1bGF0ZSBhIG11bHRpZGVzdGluYXRpb24gZnJhbWU6DQoN Cg0KDQoxKSBSMyBjb3VsZCB0dW5uZWwgaXQgdG8gb25lIG9mIHtSMSwgUjJ9LCBhbmQgbGV0IHRo ZW0gaW5qZWN0IHRoZSBwYWNrZXQgKHdpdGggcHNldWRvbm9kZSBuaWNrbmFtZSkgaW50byB0aGUg Y2FtcHVzLg0KDQoNCg0KUHJvOiBEb2Vzbid0IGFmZmVjdCBhbnkgUkJzIG90aGVyIHRoYW4gdGhl IG9uZXMgb24gdGhlIGxpbms7IGJhY2t3YXJkcyBjb21wYXRpYmxlLiAgQ29uOiBtb3JlIGhvcHMs IG1pZ2h0IGJlIGRpZmZpY3VsdA0KDQppbiBzb21lIGltcGxlbWVudGF0aW9ucyBmb3IgUjMgdG8g Zm9yd2FyZCBieSB0dW5uZWxpbmcsIG1pZ2h0IGJlIGRpZmZpY3VsdCBmb3IgUjIgdG8gYWNjZXB0 IGEgdHVubmVsZWQgcGFja2V0Lg0KDQoNCg0KMikgUjMgY291bGQgdXNlIGl0cyBvd24gbmlja25h bWUgaW5zdGVhZCBvZiB0aGUgcHNldWRvbm9kZSBuaWNrbmFtZSBpbiB0aGlzIGNhc2UNCg0KDQoN ClBybzogRG9lc24ndCBhZmZlY3QgYW55IFJCcyBvdGhlciB0aGFuIHRoZSBvbmVzIG9uIHRoZSBs aW5rOyBiYWNrd2FyZHMgY29tcGF0aWJsZS4gIENvbjogTUFDIGxlYXJuaW5nIGluIGRpc3RhbnQg UkJzIHdpbGwgaGF2ZQ0KDQpmcmVxdWVudCBsZWFybmluZyBjaGFuZ2VzIG9mIHRoZSBzb3VyY2Ug TUFDIFMgYmV0d2VlbiBiZWluZyBvbiB0aGUgcHNldWRvbm9kZSBuaWNrbmFtZSAod2hlbmV2ZXIg UyBzZW5kcyB1bmljYXN0LA0KDQpvciBtdWx0aWNhc3QgdGhyb3VnaCBSMSBvciBSMiksIG9yIGJl aW5nIG9uIFIzICh3aGVuIFIzIGhhcyB0byBlbmNhcHN1bGF0ZSBhIG11bHRpZGVzdGluYXRpb24g ZnJhbWUgZnJvbSBTKS4NCg0KDQoNCi0tLS0tLQ0KDQpUaGVyZSBtaWdodCBoYXZlIGJlZW4gc29t ZSBvdGhlciBwcm9wb3NhbHMsIGJ1dCB0aGV5IHdvdW5kIHVwIG5vdCB0byB3b3JrLg0KDQoNCg0K UGVyc29uYWxseSwgSSBkb24ndCBsb3ZlIHRoZSBDTVQgdGhpbmcgYmVjYXVzZSBvZiB0aGUgdHdv IGRpc2FkdmFudGFnZXMgSSBtZW50aW9uZWQgYWJvdmUsIGJ1dCBJIGNhbiBsaXZlIHdpdGggaXQu DQoNCg0KDQpSYWRpYQ0KDQo= --Boundary_(ID_qB4eKtWtsHghl7d3R0jKSw) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable
Hi Tissa,

We know that RBridge Aggregation is used to increase the access capaci= ty without upgrade of the RBridges. The motivation is the same as the = traditional LAG: it will help customers to reduce their investment. If= active-active multi-homing can work well, customers will eager to purchase MT feature. It may even act as a factor t= hat promotes MT-TRILL, who knows.

On the other hand, since MTRA is backward compatible, it allows other = non-MTRA solutions co-exist in the campus. These solutions work in the base= topology. These solutions may include tunneling approach. As we know, tunn= eling had been widely used on traditional switches. If there are customers who really do not like MT, just use tunne= ling approach or others. 

However, I don't think that multi-topology is that expensive. I believ= e you have heard of silicons or implementations already support multi-topol= ogy feature before 2010 when RFC 6325 was published. 

Thanks,
Mingui


=B7=A2=BC=FE=C8=CB: Tissa Senevirathne (= tsenevir) [tsenevir@cisco.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA4=D4=C22=C8=D5 0:27
=B5=BD: Janardhanan Pathangi Narasimhan; Mingui Zhang
Cc: rbridge@postel.org
=D6=F7=CC=E2: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG = draft

Hi Mingui

 

I have not seen an answ= er for the questions below could you please answer simple question:<= /p>

 

What is your proposal f= or active-active for people who do not want to run multi-topology ?<= /p>

 

From: Tissa = Senevirathne (tsenevir)
Sent: Friday, March 30, 2012 1:37 AM
To: Tissa Senevirathne (tsenevir); 'Janardhanan Pathangi Narasimhan'= ; 'Mingui Zhang'
Cc: 'rbridge@postel.org'
Subject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft=

 

Small typo correction

 

From: Tissa = Senevirathne (tsenevir)
Sent: Friday, March 30, 2012 1:25 AM
To: 'Janardhanan Pathangi Narasimhan'; Mingui Zhang
Cc: rbridge@= postel.org
Subject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft=

 

Jana is absolutely corr= ect on the observation below.

 

One more point to add, = as have indicated earlier

 

1.       Not all customer will run= multi-topology

2.       You cannot force customer= s to run multi-topology when they need active-active forwarding

3.       What is your solution for= customers who *do NOT* want to run multi-topology ?

 

From: rbridge-bou= nces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Janardhanan Pathangi Narasimhan
Sent: Friday, March 30, 2012 12:30 AM
To: Mingui Zhang
Cc: rbridge@= postel.org
Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft=

 

Hi Mingui

 

  When you realize= active-active, you are asking for the active-active to be setup in a new t= opology and not the base topology. So these nodes which need to talk to the other nodes which are behind non-MT RBridges cannot do so a= ny more.

 

  Specifically for= MT to be backward compatible, you need all nodes which want to talk to eac= h other part of the base topology. If you do that you cannot realize active-active. If you put the active-active in a new topology, tha= n they can no longer talk to nodes on the base topology of non-MT RBridges.=

 

So yes, MT-TRILL is bac= kward compatible for base topology, but the realization of active-active wi= th MT =A8C TRILL is not backward compatible. That was the point I was bringing up.

 

Thanks

Jana

 

 

From: Mingui= Zhang [mailto:= zhangmingui@huawei.com]
Sent: Friday, March 30, 2012 12:15 PM
To: Janardhanan Pathangi Narasimhan
Cc: rbridge@= postel.org
Subject: =B4= =F0=B8=B4: [rbridge] Call for draft-tissa-trill-cmt-00 = to WG draft

 

Hi Jana,

 

All RBridges in the campus= are in the base topology. MT RBridges can well communicate with non-MT RBr= idges using the base topology. 

 

I feel that you are arguin= g that MT-TRILL is not backward compatible. That is a incorrect judgem= ent.

 

Thanks,

Mingui

=B7=A2=BC=FE=C8=CB= : Janardhanan Pathangi Narasimhan [jana@force10networks.com]
=B7= =A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C230=C8=D5 13:29
=B5= =BD: Mingui Zhang
Cc: rbridge@= postel.org
=D6= =F7=CC=E2: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Mingui,

 

With MT approach, when = two RBridges which had stations talking to each other and one of them is co= nverted to MT, then the communication is broken. So it does not have backward computability.

 

Thanks

Jana

 

 

From: Mingui Zhang [mailto:zhangmingui@huawei.com]
Sent: Friday, March 30, 2012 12:27 AM
To: Janardhanan Pathangi Narasimhan
Cc: rbridge@= postel.org
Subject: =B4=F0=B8=B4: [rbridge] Call for = draft-tissa-trill-cmt-00 to WG draft

 

Hi Jana,

 

Let us assume that I have = 20 RBridges in the campus which have end systems connected to it, and all o= f 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 whic= h 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 Sci= ence while the access ports of RB2 and RB4 are configured as another VLAN for end systems of the Dept of Lite= rature. 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 p= ractical, and always possible may depend on the nodes connected and also wh= at controls are available on them=

 

ZMG> Think about it. Wh= en an operator have a LAG connected to a group of RBridges, he has to decid= e 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

 

 

 

=B7=A2=BC=FE=C8=CB= : Janardhanan Pathangi Narasimhan [jana@force10networks.com]
=B7= =A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C230=C8=D5 0:49
=B5= =BD: Mingui Zhang
Cc: rbridge@= postel.org
=D6= =F7=CC=E2: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Mingui,

 

I am slightly confused.

 

For the intra-topology sce= nario, MT unaware RBridges will not appear in a specific topology other tha= n the based topology. In other words, MTRA RBridges only talks only with MTRA RBridges. Since they all support MT, MTRA can work ve= ry well among them. In this scenario, MTRA RBridges and old RBridges co-exi= st 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 ha= ve 20 RBridges in the campus which have end systems connected to it, and al= l 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 RBr= idges 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 sce= nario, 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 r= equirement that they need to configure their hashing function to remove the= possible MAC flip-flop. 

 

I am not sure if that i= s practical, and always possible may depend on the nodes connected and also= what controls are available on them

 

Thanks

Jana

 

Thanks,

Mingui

=B7=A2=BC=FE=C8=CB= : rbridge-bou= nces@postel.org [rbridge-bounces@postel.org] =B4=FA= =B1=ED Mingui Zhang [zhangmingui@huawei.co= m]
=B7= =A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C229=C8=D5 18:50
=B5= =BD: Janardhanan Pathangi Narasimhan
Cc: rbridge@= postel.org
=D6= =F7=CC=E2: =B4=F0= =B8=B4: [rbridge] Call for draft-tissa-tri= ll-cmt-00 to WG draft

Hi Jana, 

 

>In section 4.1, cou= ld 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.<= /span>

 

Thanks,

Mingui

=B7=A2=BC=FE=C8=CB= : Janardhanan Pathangi Narasimhan [jana@force10networks.com]
=B7= =A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C228=C8=D5 22:52
=B5= =BD: Mingui Zhang
Cc: rbridge@= postel.org
=D6= =F7=CC=E2: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Mingui,

 

Section 4, does not giv= e 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 extern= al node may or may not be acceptable . I am not sure that this can be class= ified as backward compatible since it is not a full solution and can also c= ause frequent MAC flip flops etc.=

 

In section 4.1, could y= ou 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: =B4=F0=B8=B4: [rbridge] Call for = draft-tissa-trill-cmt-00 to WG draft

 

Hi Jana,

 

I think I should answer yo= ur question. I am Mingui Zhang.

Please refer to the draft&= nbsp;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

=B7=A2=BC=FE=C8=CB= : Janardhanan Pathangi Narasimhan [jana@force10networks.com]
=B7= =A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C228=C8=D5 19:14
=B5= =BD: Rohit Watve (rwatve); Mingui Zhang; Radia Perlman; Tissa Senevirathne (tsenevir)=
Cc: rbridge@= postel.org
=D6= =F7=CC=E2: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Zhai,

 

In the Multi-topology c= ase 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 t= his will cause MAC flip flop on the other RBridges and other issues since a= ll the other RBridges do not understand MT.

 

Could you please explai= n how MT can work in such scenarios?


Thanks

Jana

 

 

From: rbridge-bou= nces@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 o= ffers a way to do fast failure recovery when there is a failure of an aggregated RBridge or link.

PN: NO. The new distri= bution tree need to be recomputed.

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

MTRA: YES.

CMT does not need re= configuration. If one Rbridge advertiz= ing affinity tlv goes down, the tree can be root= ed at the other Egress Rbr= idge ID advertizing affinity tlv.=

Also, consider addin= g following to the comparison table

Number of New TLVs (= and resulting complexity)

PN: 3

CMT: 1

MTRA: multiple

Thanks
Rohit

-----Original Message-= ----
From: rbrid= ge-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: =B4=F0=B8=B4: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Radia,

It is a good idea to l= ist 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 RBri= dge Aggregation). Let me compare them in the following dimensions.

1. Whether the solutio= n is incrementally deploy-able.

PN: YES.

CMT: NO.

MTRA: YES.

2. Use only existing s= ilicons.

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

CMT: YES.

MTRA: Currently NO. Bu= t 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 o= ffers a way to do fast failure recovery when there is a failure of an aggregated RBridge or link.

PN: NO. The new distri= bution tree need to be recomputed.

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

MTRA: YES.

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

+--------+----= --------+-----------+----------+------------+-------------&= #43;

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

+--------+----= --------+-----------+----------+------------+-------------|=

|PN   &= nbsp;  |YES         |NO &= nbsp;       |NO     =    |NO          |NO&= nbsp;          |

+--------+----= --------+-----------+----------+------------+-------------|=

|CMT   =   |NO          |YES =        |YES     &nbs= p; |YES         |NO  &nbs= p;        |

+--------+----= --------+-----------+----------+------------+-------------|=

|MTRA   = ; |YES         |YES(will)  |YE= S       |YES     &nb= sp;   |YES          = |

+--------+----= --------+-----------+----------+------------+-------------&= #43;

Thanks,

Mingui

 

=B7=A2= =BC=FE=C8=CB: rbridge-bou= nces@postel.org [rbridge-bounces@postel.org] =B4=FA=B1=ED Radia Perlman [radiaperlman@gmail.com]

=B7=A2= =CB=CD=CA=B1=BC=E4= : 2012=C4=EA3=D4=C228=C8=D5 12:52

=B5=BD: Tiss= a Senevirathne (tsenevir)

Cc: rbridge@postel.org

=D6=F7=CC=E2: Re= : [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

 

It is my understanding= that

a) CMT does require ch= anging all the RBs in the campus<= /p>

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 solut= ions 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 ca= n use the pseudonode

nickname when encapsul= ating unicast.

 

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

multidestination frame= s 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,<= /span>

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<= /span>

port to the link is no= t 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 nicknam= e) into the campus.

 

Pro: Doesn't affect an= y RBs other than the ones on the link; backwards compatible.  Con: mor= e hops, might be difficult

in some implementation= s for R3 to forward by tunneling, might be difficult for R2 to accept a tun= neled packet.

 

2) R3 could use its ow= n nickname instead of the pseudonode nickname in this case

 

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

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

or multicast through R= 1 or R2), or being on R3 (when R3 has to encapsulate a multidestination fra= me from S).

 

------

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

 

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

 

Radia

 

--Boundary_(ID_qB4eKtWtsHghl7d3R0jKSw)-- --===============1520252617== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge --===============1520252617==-- From rbridge-bounces@postel.org Mon Apr 2 08:52:35 2012 Return-Path: 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 D22FF21F863F for ; Mon, 2 Apr 2012 08:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, MIME_CHARSET_FARAWAY=2.45, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_MED=-4] 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 O6XvvrYbgEJU for ; Mon, 2 Apr 2012 08:52:33 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 175B721F85E7 for ; Mon, 2 Apr 2012 08:52:32 -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 q32FEvmS019704; Mon, 2 Apr 2012 08:15:01 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q32FEUPF019673 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 2 Apr 2012 08:14:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tsenevir@cisco.com; l=98619; q=dns/txt; s=iport; t=1333379679; x=1334589279; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=smNUvt5dpQ0Nd/N/rHRPC3kkjRtDoU+FQZRvgRWXpAM=; b=WGKIOQRXeAJlU5sm3zN9I87hBZ69D2tJ+msFsL0ORdbuYwXb21l/QT94 U1LP1zYpZYsOwWFhJ8aelhnjgcPCcQg/wJsIVzgDsbI5mkfEZYvN3NZIs QSOJp+dlyl7xZ9IEDstKcGzaQf72ej/eA3uJtt7iZzGxrdJ/nnvCb/O8Z Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAHHBeU+rRDoI/2dsb2JhbABFgkaDAapKAYh+gQeCCQEBAQQSAQcBAQEQAzUIDAwEAgEGAhEEAQELBhABBgEEAgEgJQkIAgQBEggTB4dmDJs0jQIIkWKKFoVqOWMEiFiOGooigxSBaIMH X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208,217";a="36113503" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 02 Apr 2012 15:14:29 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q32FESbj002452; Mon, 2 Apr 2012 15:14:29 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Apr 2012 08:14:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 2 Apr 2012 08:14:27 -0700 Message-ID: <344037D7CFEFE84E97E9CC1F56C5F4A5E3ACD9@xmb-sjc-214.amer.cisco.com> In-Reply-To: <4552F0907735844E9204A62BBDD325E728CB1FA4@SZXEML507-MBS.china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft Thread-Index: AQHNC6M4X8TnOZ/31Umc7no1WTsFHJZ9Cj0AgABclICAABKNgIABKjzxgAAYT0D//+PaAIAAy5WsgAAUHfCAABB74IAAKcBDgAASQ3CAAUvIPoAAP81cgAAoPaCAACBD3IAAtGNggAAT3tCAAA2IQIAADzCAgAAD9ECAA6fZcIABd2IMgAACI9A= References: <344037D7CFEFE84E97E9CC1F56C5F4A5DA0303@xmb-sjc-214.amer.cisco.com> <4552F0907735844E9204A62BBDD325E728CAD030@SZXEML507-MBS.china.huawei.com> <344037D7CFEFE84E97E9CC1F56C5F4A5DA05D7@xmb-sjc-214.amer.cisco.com> <4552F0907735844E9204A62BBDD325E728CAE193@SZXEML507-MBS.china.huawei.com> <4552F0907735844E9204A62BBDD325E728CAE2F1@SZXEML507-MBS.china.huawei.com> <4552F0907735844E9204A62BBDD325E728CAE77F@SZXEML507-MBS.china.huawei.com> <4552F0907735844E9204A62BBDD325E728CB086C@SZXEML507-MBS.china.huawei.com> <4552F0907735844E9204A62BBDD325E728CB0B20@SZXEML507-MBS.china.huawei.com> <344037D7CFEFE84E97E9CC1F56C5F4A5DA122A@xmb-sjc-214.amer.cisco.com> <4552F0907735844E9204A62BBDD325E728CB1FA4@SZXEML507-MBS.china.huawei.com> From: "Tissa Senevirathne (tsenevir)" To: "Mingui Zhang" , "Janardhanan Pathangi Narasimhan" X-OriginalArrivalTime: 02 Apr 2012 15:14:28.0754 (UTC) FILETIME=[4C4FEF20:01CD10E3] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: tsenevir@cisco.com Cc: rbridge@postel.org Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0327941758==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org This is a multi-part message in MIME format. --===============0327941758== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD10E3.4C2F8842" This is a multi-part message in MIME format. ------_=_NextPart_001_01CD10E3.4C2F8842 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi Mingui =20 You are assuming a lot.=20 That is:=20 1. People will deploy Multi-topology when they need active-active = forwarding.=20 2. It is easy to deploy and people will like it 3. It is already out there =20 #2 you can check % vise how many MT installations there in L3 world. =20 Again I would summarize CMT need only one TLV, MT require lot more TLV = and require major changes to RFC6326 control plane. =20 Backward compatibility of control plane in my world is not an issue as = we are exchanging more emails than really trying to deploy RBridges and = there are no RBridges there forwarding packets in real networks. =20 However, your claim that MT is backward compatible without any tweaks is = false (Jana has pointed out several times). =20 Like I have said, many times before, MT approach you have may be = utilized for active-active forwarding in MT installations. I will = support that solution as an optimization for MT, certainly I **do not** = support it as the only solution for all active-active deployments. If = we agree on that then we have consensus and both work can move forward = (we need to make progress). If not then we can continue to disagree and = I request WG chairs to decide via a vote on making CMT a WG document. =20 =20 Thanks Tissa From: Mingui Zhang [mailto:zhangmingui@huawei.com]=20 Sent: Monday, April 02, 2012 7:54 AM To: Tissa Senevirathne (tsenevir); Janardhanan Pathangi Narasimhan Cc: rbridge@postel.org Subject: =B4=F0=B8=B4: [rbridge] Call for draft-tissa-trill-cmt-00 to WG = draft =20 Hi Tissa, =20 We know that RBridge Aggregation is used to increase the access capacity = without upgrade of the RBridges. The motivation is the same as the = traditional LAG: it will help customers to reduce their investment. If = active-active multi-homing can work well, customers will eager to = purchase MT feature. It may even act as a factor that promotes MT-TRILL, = who knows. =20 On the other hand, since MTRA is backward compatible, it allows other = non-MTRA solutions co-exist in the campus. These solutions work in the = base topology. These solutions may include tunneling approach. As we = know, tunneling had been widely used on traditional switches. If there = are customers who really do not like MT, just use tunneling approach or = others.=20 =20 However, I don't think that multi-topology is that expensive. I believe = you have heard of silicons or implementations already support = multi-topology feature before 2010 when RFC 6325 was published.=20 =20 Thanks, Mingui =20 ________________________________ =B7=A2=BC=FE=C8=CB: Tissa Senevirathne (tsenevir) [tsenevir@cisco.com] =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA4=D4=C22=C8=D5 0:27 =B5=BD: Janardhanan Pathangi Narasimhan; Mingui Zhang Cc: rbridge@postel.org =D6=F7=CC=E2: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG = draft Hi Mingui =20 I have not seen an answer for the questions below could you please = answer simple question: =20 What is your proposal for active-active for people who do not want to = run multi-topology ? =20 From: Tissa Senevirathne (tsenevir)=20 Sent: Friday, March 30, 2012 1:37 AM To: Tissa Senevirathne (tsenevir); 'Janardhanan Pathangi Narasimhan'; = 'Mingui Zhang' Cc: 'rbridge@postel.org' Subject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft =20 Small typo correction=20 =20 From: Tissa Senevirathne (tsenevir)=20 Sent: Friday, March 30, 2012 1:25 AM To: 'Janardhanan Pathangi Narasimhan'; Mingui Zhang Cc: rbridge@postel.org Subject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft =20 Jana is absolutely correct on the observation below. =20 One more point to add, as have indicated earlier =20 1. Not all customer will run multi-topology 2. You cannot force customers to run multi-topology when they need = active-active forwarding 3. What is your solution for customers who *do NOT* want to run = multi-topology ? =20 From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On = Behalf Of Janardhanan Pathangi Narasimhan Sent: Friday, March 30, 2012 12:30 AM To: Mingui Zhang Cc: rbridge@postel.org Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft =20 Hi Mingui =20 When you realize active-active, you are asking for the active-active = to be setup in a new topology and not the base topology. So these nodes = which need to talk to the other nodes which are behind non-MT RBridges = cannot do so any more.=20 =20 Specifically for MT to be backward compatible, you need all nodes = which want to talk to each other part of the base topology. If you do = that you cannot realize active-active. If you put the active-active in a = new topology, than they can no longer talk to nodes on the base topology = of non-MT RBridges. =20 So yes, MT-TRILL is backward compatible for base topology, but the = realization of active-active with MT =A8C TRILL is not backward = compatible. That was the point I was bringing up. =20 Thanks Jana =20 =20 From: Mingui Zhang [mailto:zhangmingui@huawei.com]=20 Sent: Friday, March 30, 2012 12:15 PM To: Janardhanan Pathangi Narasimhan Cc: rbridge@postel.org Subject: =B4=F0=B8=B4: [rbridge] Call for draft-tissa-trill-cmt-00 to WG = draft =20 Hi Jana,=20 =20 All RBridges in the campus are in the base topology. MT RBridges can = well communicate with non-MT RBridges using the base topology.=20 =20 I feel that you are arguing that MT-TRILL is not backward compatible. = That is a incorrect judgement. =20 Thanks, Mingui ________________________________ =B7=A2=BC=FE=C8=CB: Janardhanan Pathangi Narasimhan = [jana@force10networks.com] =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C230=C8=D5 13:29 =B5=BD: Mingui Zhang Cc: rbridge@postel.org =D6=F7=CC=E2: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG = draft Hi Mingui, =20 With MT approach, when two RBridges which had stations talking to each = other and one of them is converted to MT, then the communication is = broken. So it does not have backward computability.=20 =20 Thanks Jana =20 =20 From: Mingui Zhang [mailto:zhangmingui@huawei.com]=20 Sent: Friday, March 30, 2012 12:27 AM To: Janardhanan Pathangi Narasimhan Cc: rbridge@postel.org Subject: =B4=F0=B8=B4: [rbridge] Call for draft-tissa-trill-cmt-00 to WG = draft =20 Hi Jana,=20 =20 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? =20 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. =20 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 =20 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. =20 Thanks, Mingui =20 =20 =20 ________________________________ =B7=A2=BC=FE=C8=CB: Janardhanan Pathangi Narasimhan = [jana@force10networks.com] =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C230=C8=D5 0:49 =B5=BD: Mingui Zhang Cc: rbridge@postel.org =D6=F7=CC=E2: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG = draft Hi Mingui, =20 I am slightly confused.=20 =20 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. =20 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? =20 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.=20 =20 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 =20 Thanks Jana =20 Thanks, Mingui ________________________________ =B7=A2=BC=FE=C8=CB: rbridge-bounces@postel.org = [rbridge-bounces@postel.org] =B4=FA=B1=ED Mingui Zhang = [zhangmingui@huawei.com] =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C229=C8=D5 18:50 =B5=BD: Janardhanan Pathangi Narasimhan Cc: rbridge@postel.org =D6=F7=CC=E2: =B4=F0=B8=B4: [rbridge] Call for draft-tissa-trill-cmt-00 = to WG draft Hi Jana,=20 =20 >In section 4.1, could you please explain how the frame that is = ingressed by RB1 through RBv001 is received at RBx?=20 =20 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. =20 Thanks, Mingui ________________________________ =B7=A2=BC=FE=C8=CB: Janardhanan Pathangi Narasimhan = [jana@force10networks.com] =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C228=C8=D5 22:52 =B5=BD: Mingui Zhang Cc: rbridge@postel.org =D6=F7=CC=E2: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG = draft Hi Mingui, =20 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. =20 In section 4.1, could you please explain how the frame that is ingressed = by RB1 through RBv001 is received at RBx?=20 =20 Thanks Jana =20 =20 From: Mingui Zhang [mailto:zhangmingui@huawei.com]=20 Sent: Wednesday, March 28, 2012 7:15 PM To: Janardhanan Pathangi Narasimhan Cc: rbridge@postel.org Subject: =B4=F0=B8=B4: [rbridge] Call for draft-tissa-trill-cmt-00 to WG = draft =20 Hi Jana,=20 =20 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. =20 Thanks, Mingui ________________________________ =B7=A2=BC=FE=C8=CB: Janardhanan Pathangi Narasimhan = [jana@force10networks.com] =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C228=C8=D5 19:14 =B5=BD: Rohit Watve (rwatve); Mingui Zhang; Radia Perlman; Tissa = Senevirathne (tsenevir) Cc: rbridge@postel.org =D6=F7=CC=E2: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG = draft Hi Zhai, =20 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. =20 Could you please explain how MT can work in such scenarios? Thanks Jana =20 =20 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 =20 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.=20 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: =B4=F0=B8=B4: [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.=20 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.=20 PN: NO. The new distribution tree need to be recomputed. CMT: NO. A overall re-configuration is necessary. MTRA: YES.=20 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.=20 +--------+------------+-----------+----------+------------+-------------+= |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 =20 =B7=A2=BC=FE=C8=CB: rbridge-bounces@postel.org = [rbridge-bounces@postel.org] =B4=FA=B1=ED Radia Perlman = [radiaperlman@gmail.com] =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C228=C8=D5 12:52 =B5=BD: Tissa Senevirathne (tsenevir) Cc: rbridge@postel.org =D6=F7=CC=E2: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG = draft =20 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 =20 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. =20 So from memory...other proposals for allowing R1, R2, and R3 to be = active/active/active on a link: =20 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. =20 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. =20 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: =20 1) R3 could tunnel it to one of {R1, R2}, and let them inject the packet = (with pseudonode nickname) into the campus. =20 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. =20 2) R3 could use its own nickname instead of the pseudonode nickname in = this case =20 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). =20 ------ There might have been some other proposals, but they wound up not to = work. =20 Personally, I don't love the CMT thing because of the two disadvantages = I mentioned above, but I can live with it. =20 Radia=20 =20 ------_=_NextPart_001_01CD10E3.4C2F8842 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Mingui

 

You are assuming a lot.

That is:

1. People will deploy Multi-topology when they need active-active = forwarding.

2. It is easy to deploy and people will like = it

3. It is already out there

 

#2 you can check % vise how many MT installations there in L3 = world.

 

Again I would summarize CMT need only one TLV, MT require lot more = TLV and require major changes to RFC6326 control = plane.

 

Backward compatibility of control plane in my world is not an issue = as we are exchanging more emails than really trying to deploy RBridges = and there are no RBridges there forwarding packets in real = networks.

 

However, your claim that MT is backward compatible without any tweaks = is false (Jana has pointed out several times).

 

Like I have said, many times before, MT approach you have may be = utilized for active-active forwarding in MT installations. I will = support that solution as an optimization for MT, certainly I **do not** = support it  as the only solution for all active-active deployments. = If we agree on that then we have consensus and both work can move = forward (we need to make progress). If not then we can continue to = disagree and I request WG chairs to decide via a vote on making CMT a WG = document.

 

 

Thanks

Tissa

From:= = Mingui Zhang [mailto:zhangmingui@huawei.com]
Sent: Monday, = April 02, 2012 7:54 AM
To: Tissa Senevirathne (tsenevir); = Janardhanan Pathangi Narasimhan
Cc: = rbridge@postel.org
Subject: =B4=F0=B8=B4: [rbridge] = Call for draft-tissa-trill-cmt-00 to WG = draft

 

= Hi Tissa,

=  

= We know that RBridge Aggregation is used to increase the access capacity = without upgrade of the RBridges. The motivation is the same as = the traditional LAG: it will help customers to reduce their = investment. If active-active multi-homing can work well, customers will = eager to purchase MT feature. It may even act as a factor that promotes = MT-TRILL, who knows.

=  

= On the other hand, since MTRA is backward compatible, it allows other = non-MTRA solutions co-exist in the campus. These solutions work in the = base topology. These solutions may include tunneling approach. As we = know, tunneling had been widely used on traditional switches. If there = are customers who really do not like MT, just use tunneling approach or = others. 

=  

= However, I don't think that multi-topology is that expensive. I believe = you have heard of silicons or implementations already support = multi-topology feature before 2010 when RFC 6325 was = published. 

=  

= Thanks,

= Mingui

=  

=B7=A2=BC=FE=C8=CB= := Tissa Senevirathne (tsenevir) [tsenevir@cisco.com]
=B7=A2=CB=CD=CA=B1=BC=E4= := 2012=C4=EA= 4=D4=C2= 2=C8=D5= 0:27
=B5=BD= := Janardhanan Pathangi Narasimhan; Mingui Zhang
Cc: rbridge@postel.org
=D6=F7=CC=E2= := RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Mingui

 

I have not seen an answer for the questions below could you please = answer simple question:

 

What is your proposal for active-active for people who do not want to = run multi-topology ?

 

= From:= Tissa Senevirathne (tsenevir)
Sent: Friday, March 30, 2012 = 1:37 AM
To: Tissa Senevirathne (tsenevir); 'Janardhanan = Pathangi Narasimhan'; 'Mingui Zhang'
Cc: = 'rbridge@postel.org'
Subject: RE: [rbridge] Call for = draft-tissa-trill-cmt-00 to WG draft

 

Small typo correction

 

= From:= Tissa Senevirathne (tsenevir)
Sent: Friday, March 30, 2012 = 1:25 AM
To: 'Janardhanan Pathangi Narasimhan'; Mingui = Zhang
Cc: rbridge@postel.org
Subject: RE: = [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

 

Jana is absolutely correct on the observation below.

 

One more point to add, as have indicated earlier

 

1.       = Not all customer will run multi-topology

2.       = You cannot force customers to run multi-topology when they need = active-active forwarding

3.       = What is your solution for customers who *do NOT* want to run = multi-topology ?

 

= From:= rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of = Janardhanan Pathangi Narasimhan
Sent: Friday, March 30, = 2012 12:30 AM
To: Mingui Zhang
Cc: rbridge@postel.org
Subject: Re: = [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

 

Hi Mingui

 

  When you realize active-active, you are asking for the = active-active to be setup in a new topology and not the base topology. = So these nodes which need to talk to the other nodes which are behind = non-MT RBridges cannot do so any more.

 

  Specifically for MT to be backward compatible, you need all = nodes which want to talk to each other part of the base topology. If you = do that you cannot realize active-active. If you put the active-active = in a new topology, than they can no longer talk to nodes on the base = topology of non-MT RBridges.

 

So yes, MT-TRILL is backward compatible for base topology, but the = realization of active-active with MT =A8C TRILL is not backward = compatible. That was the point I was bringing up.

 

Thanks

Jana

 

 

= From:= Mingui Zhang [mailto:zhangmingui@huawei.com]
Sent: = Friday, March 30, 2012 12:15 PM
To: Janardhanan Pathangi = Narasimhan
Cc: rbridge@postel.org
Subject: =B4=F0=B8=B4= : [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

 

= Hi Jana,

=  

= All RBridges in the campus are in the base topology. MT RBridges can = well communicate with non-MT RBridges using the base = topology. 

=  

= I feel that you are arguing that MT-TRILL is not = backward compatible. That is a incorrect judgement.

=  

= Thanks,

= Mingui

=

=B7=A2=BC=FE=C8=CB= := Janardhanan Pathangi Narasimhan = [jana@force10networks.com]
=B7=A2=CB=CD=CA=B1=BC=E4= := 2012=C4=EA= 3=D4=C2= 30=C8=D5= 13:29
=B5=BD= := Mingui Zhang
Cc: rbridge@postel.org
=D6=F7=CC=E2= := RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Mingui,

 

With MT approach, when two RBridges which had stations talking to = each other and one of them is converted to MT, then the communication is = broken. So it does not have backward computability.

 

Thanks

Jana

 

 

= From:= Mingui Zhang [mailto:zhangmingui@huawei.com]
Sent: = Friday, March 30, 2012 12:27 AM
To: Janardhanan Pathangi = Narasimhan
Cc: rbridge@postel.org
Subject: =B4=F0=B8=B4= : [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

 

= 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

=  

=  

=  

=B7=A2=BC=FE=C8=CB= := Janardhanan Pathangi Narasimhan = [jana@force10networks.com]
=B7=A2=CB=CD=CA=B1=BC=E4= := 2012=C4=EA= 3=D4=C2= 30=C8=D5= 0:49
=B5=BD= := Mingui Zhang
Cc: rbridge@postel.org
=D6=F7=CC=E2= := 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

=B7=A2=BC=FE=C8=CB= := rbridge-bounces@postel.org = [rbridge-bounces@postel.org] =B4=FA=B1=ED= Mingui Zhang [zhangmingui@huawei.com]
=B7=A2=CB=CD=CA=B1=BC=E4= := 2012=C4=EA= 3=D4=C2= 29=C8=D5= 18:50
=B5=BD= := Janardhanan Pathangi Narasimhan
Cc: rbridge@postel.org
=D6=F7=CC=E2= := =B4=F0=B8=B4= : [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

=B7=A2=BC=FE=C8=CB= := Janardhanan Pathangi Narasimhan = [jana@force10networks.com]
=B7=A2=CB=CD=CA=B1=BC=E4= := 2012=C4=EA= 3=D4=C2= 28=C8=D5= 22:52
=B5=BD= := Mingui Zhang
Cc: rbridge@postel.org
=D6=F7=CC=E2= := 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: =B4=F0=B8=B4= : [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

=B7=A2=BC=FE=C8=CB= := Janardhanan Pathangi Narasimhan = [jana@force10networks.com]
=B7=A2=CB=CD=CA=B1=BC=E4= := 2012=C4=EA= 3=D4=C2= 28=C8=D5= 19:14
=B5=BD= := Rohit Watve (rwatve); Mingui Zhang; Radia Perlman; Tissa Senevirathne = (tsenevir)
Cc: rbridge@postel.org
=D6=F7=CC=E2= := 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: =B4=F0=B8=B4: [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    &nb= sp; |YES         = |NO         = |NO        = |NO          = |NO           = |

+--------+------------+-------= ----+----------+------------+-------------|

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

+--------+------------+-------= ----+----------+------------+-------------|

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

+--------+------------+-------= ----+----------+------------+-------------+

Thanks,

Mingui

 

=B7=A2=BC=FE=C8=CB: rbridge-bounces@postel.org = [rbridge-bounces@postel.org] = =B4=FA=B1=ED Radia Perlman = [radiaperlman@gmail.com]

=B7=A2=CB=CD=CA=B1=BC=E4= : 2012=C4=EA3=D4=C228=C8=D5 12:52

=B5=BD: Tissa Senevirathne = (tsenevir)

Cc: rbridge@postel.org

=D6=F7=CC=E2: 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

 

=
<= /div>
------_=_NextPart_001_01CD10E3.4C2F8842-- --===============0327941758== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge --===============0327941758==-- From rbridge-bounces@postel.org Mon Apr 2 09:16:13 2012 Return-Path: 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 93C9B21F86F0 for ; Mon, 2 Apr 2012 09:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.929 X-Spam-Level: * X-Spam-Status: No, score=1.929 tagged_above=-999 required=5 tests=[AWL=3.723, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_MED=-4] 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 dEixotnc7mYG for ; Mon, 2 Apr 2012 09:16:10 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id B785B21F86EF for ; Mon, 2 Apr 2012 09:16:10 -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 q32FfvX2024324; Mon, 2 Apr 2012 08:42:01 -0700 (PDT) Received: from mx.force10networks.com (maa.force10networks.com [59.163.202.254]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q32FfCdL024288 for ; Mon, 2 Apr 2012 08:41:22 -0700 (PDT) Received: from EXCH-CLUSTER-11.force10networks.com ([10.16.127.21]) by exch7-maa-fe.force10networks.com ([10.16.126.10]) with mapi; Mon, 2 Apr 2012 21:11:11 +0530 From: Janardhanan Pathangi Narasimhan To: "Tissa Senevirathne (tsenevir)" , Mingui Zhang Date: Mon, 2 Apr 2012 21:15:05 +0530 Thread-Topic: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft Thread-Index: AQHNC6M4X8TnOZ/31Umc7no1WTsFHJZ9Cj0AgABclICAABKNgIABKjzxgAAYT0D//+PaAIAAy5WsgAAUHfCAABB74IAAKcBDgAASQ3CAAUvIPoAAP81cgAAoPaCAACBD3IAAtGNggAAT3tCAAA2IQIAADzCAgAAD9ECAA6fZcIABd2IMgAACI9CAAAwGgA== Message-ID: References: <344037D7CFEFE84E97E9CC1F56C5F4A5DA0303@xmb-sjc-214.amer.cisco.com> <4552F0907735844E9204A62BBDD325E728CAD030@SZXEML507-MBS.china.huawei.com> <344037D7CFEFE84E97E9CC1F56C5F4A5DA05D7@xmb-sjc-214.amer.cisco.com> <4552F0907735844E9204A62BBDD325E728CAE193@SZXEML507-MBS.china.huawei.com> <4552F0907735844E9204A62BBDD325E728CAE2F1@SZXEML507-MBS.china.huawei.com> <4552F0907735844E9204A62BBDD325E728CAE77F@SZXEML507-MBS.china.huawei.com> <4552F0907735844E9204A62BBDD325E728CB086C@SZXEML507-MBS.china.huawei.com> <4552F0907735844E9204A62BBDD325E728CB0B20@SZXEML507-MBS.china.huawei.com> <344037D7CFEFE84E97E9CC1F56C5F4A5DA122A@xmb-sjc-214.amer.cisco.com> <4552F0907735844E9204A62BBDD325E728CB1FA4@SZXEML507-MBS.china.huawei.com> <344037D7CFEFE84E97E9CC1F56C5F4A5E3ACD9@xmb-sjc-214.amer.cisco.com> In-Reply-To: <344037D7CFEFE84E97E9CC1F56C5F4A5E3ACD9@xmb-sjc-214.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: jana@force10networks.com Cc: "rbridge@postel.org" Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0887068609==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org --===============0887068609== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_CE35792847FBE84687FF9117132C8EFD471144176BEXCHCLUSTER11_" --_000_CE35792847FBE84687FF9117132C8EFD471144176BEXCHCLUSTER11_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgVGlzc2EsDQoNCg0KYSkgSW4gdGVybXMgb2YgY29udHJvbCBwbGFuZSBzdGF0ZXMgYW5kIHdv cmssIEkgdGhpbmsgTVQgaXMgbXVjaCBtb3JlIGhlYXZ5IGFuZCBhbHNvIGlmIGFsbCBlbGVtZW50 cyBoYXZlIHRvIGJlIGluIGFsbCB0b3BvbG9naWVzIChmb3IgdGhlIHNha2Ugb2YgYWN0aXZlLWFj dGl2ZSksIHRoYXQgd291bGQgaW5jcmVhc2UgdGhlIHN0YXRlcyBvbiBhbGwgbm9kZXMNCg0KU28g SSBhZ3JlZSB3aXRoIHlvdSB0aGF0IHllcyBNVCBtYXkgYmUgdXNhYmxlIGFzIGFjdGl2ZS1hY3Rp dmUgc29sdXRpb24sIGJ1dCBpdCB3b3VsZCBiZSB3cm9uZyB0byBzYXkgdGhhdCBNVCBpcyBhIGJl dHRlciBhY3RpdmUtYWN0aXZlIG9yIHNob3VsZCBiZSBtYWlubHkgdXNlZCBmb3IgYWN0aXZlLWFj dGl2ZSBtb2RlLg0KDQpUaGFua3MNCkphbmENCg0KDQpGcm9tOiBUaXNzYSBTZW5ldmlyYXRobmUg KHRzZW5ldmlyKSBbbWFpbHRvOnRzZW5ldmlyQGNpc2NvLmNvbV0NClNlbnQ6IE1vbmRheSwgQXBy aWwgMDIsIDIwMTIgODo0NCBQTQ0KVG86IE1pbmd1aSBaaGFuZzsgSmFuYXJkaGFuYW4gUGF0aGFu Z2kgTmFyYXNpbWhhbg0KQ2M6IHJicmlkZ2VAcG9zdGVsLm9yZw0KU3ViamVjdDogUkU6IFtyYnJp ZGdlXSBDYWxsIGZvciBkcmFmdC10aXNzYS10cmlsbC1jbXQtMDAgdG8gV0cgZHJhZnQNCg0KSGkg TWluZ3VpDQoNCllvdSBhcmUgYXNzdW1pbmcgYSBsb3QuDQpUaGF0IGlzOg0KMS4gUGVvcGxlIHdp bGwgZGVwbG95IE11bHRpLXRvcG9sb2d5IHdoZW4gdGhleSBuZWVkIGFjdGl2ZS1hY3RpdmUgZm9y d2FyZGluZy4NCjIuIEl0IGlzIGVhc3kgdG8gZGVwbG95IGFuZCBwZW9wbGUgd2lsbCBsaWtlIGl0 DQozLiBJdCBpcyBhbHJlYWR5IG91dCB0aGVyZQ0KDQojMiB5b3UgY2FuIGNoZWNrICUgdmlzZSBo b3cgbWFueSBNVCBpbnN0YWxsYXRpb25zIHRoZXJlIGluIEwzIHdvcmxkLg0KDQpBZ2FpbiBJIHdv dWxkIHN1bW1hcml6ZSBDTVQgbmVlZCBvbmx5IG9uZSBUTFYsIE1UIHJlcXVpcmUgbG90IG1vcmUg VExWIGFuZCByZXF1aXJlIG1ham9yIGNoYW5nZXMgdG8gUkZDNjMyNiBjb250cm9sIHBsYW5lLg0K DQpCYWNrd2FyZCBjb21wYXRpYmlsaXR5IG9mIGNvbnRyb2wgcGxhbmUgaW4gbXkgd29ybGQgaXMg bm90IGFuIGlzc3VlIGFzIHdlIGFyZSBleGNoYW5naW5nIG1vcmUgZW1haWxzIHRoYW4gcmVhbGx5 IHRyeWluZyB0byBkZXBsb3kgUkJyaWRnZXMgYW5kIHRoZXJlIGFyZSBubyBSQnJpZGdlcyB0aGVy ZSBmb3J3YXJkaW5nIHBhY2tldHMgaW4gcmVhbCBuZXR3b3Jrcy4NCg0KSG93ZXZlciwgeW91ciBj bGFpbSB0aGF0IE1UIGlzIGJhY2t3YXJkIGNvbXBhdGlibGUgd2l0aG91dCBhbnkgdHdlYWtzIGlz IGZhbHNlIChKYW5hIGhhcyBwb2ludGVkIG91dCBzZXZlcmFsIHRpbWVzKS4NCg0KTGlrZSBJIGhh dmUgc2FpZCwgbWFueSB0aW1lcyBiZWZvcmUsIE1UIGFwcHJvYWNoIHlvdSBoYXZlIG1heSBiZSB1 dGlsaXplZCBmb3IgYWN0aXZlLWFjdGl2ZSBmb3J3YXJkaW5nIGluIE1UIGluc3RhbGxhdGlvbnMu IEkgd2lsbCBzdXBwb3J0IHRoYXQgc29sdXRpb24gYXMgYW4gb3B0aW1pemF0aW9uIGZvciBNVCwg Y2VydGFpbmx5IEkgKipkbyBub3QqKiBzdXBwb3J0IGl0ICBhcyB0aGUgb25seSBzb2x1dGlvbiBm b3IgYWxsIGFjdGl2ZS1hY3RpdmUgZGVwbG95bWVudHMuIElmIHdlIGFncmVlIG9uIHRoYXQgdGhl biB3ZSBoYXZlIGNvbnNlbnN1cyBhbmQgYm90aCB3b3JrIGNhbiBtb3ZlIGZvcndhcmQgKHdlIG5l ZWQgdG8gbWFrZSBwcm9ncmVzcykuIElmIG5vdCB0aGVuIHdlIGNhbiBjb250aW51ZSB0byBkaXNh Z3JlZSBhbmQgSSByZXF1ZXN0IFdHIGNoYWlycyB0byBkZWNpZGUgdmlhIGEgdm90ZSBvbiBtYWtp bmcgQ01UIGEgV0cgZG9jdW1lbnQuDQoNCg0KVGhhbmtzDQpUaXNzYQ0KDQpGcm9tOiBNaW5ndWkg WmhhbmcgW21haWx0bzp6aGFuZ21pbmd1aUBodWF3ZWkuY29tXQ0KU2VudDogTW9uZGF5LCBBcHJp bCAwMiwgMjAxMiA3OjU0IEFNDQpUbzogVGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZpcik7IEph bmFyZGhhbmFuIFBhdGhhbmdpIE5hcmFzaW1oYW4NCkNjOiByYnJpZGdlQHBvc3RlbC5vcmc8bWFp bHRvOnJicmlkZ2VAcG9zdGVsLm9yZz4NClN1YmplY3Q6ILTwuLQ6IFtyYnJpZGdlXSBDYWxsIGZv ciBkcmFmdC10aXNzYS10cmlsbC1jbXQtMDAgdG8gV0cgZHJhZnQNCg0KSGkgVGlzc2EsDQoNCldl IGtub3cgdGhhdCBSQnJpZGdlIEFnZ3JlZ2F0aW9uIGlzIHVzZWQgdG8gaW5jcmVhc2UgdGhlIGFj Y2VzcyBjYXBhY2l0eSB3aXRob3V0IHVwZ3JhZGUgb2YgdGhlIFJCcmlkZ2VzLiBUaGUgbW90aXZh dGlvbiBpcyB0aGUgc2FtZSBhcyB0aGUgdHJhZGl0aW9uYWwgTEFHOiBpdCB3aWxsIGhlbHAgY3Vz dG9tZXJzIHRvIHJlZHVjZSB0aGVpciBpbnZlc3RtZW50LiBJZiBhY3RpdmUtYWN0aXZlIG11bHRp LWhvbWluZyBjYW4gd29yayB3ZWxsLCBjdXN0b21lcnMgd2lsbCBlYWdlciB0byBwdXJjaGFzZSBN VCBmZWF0dXJlLiBJdCBtYXkgZXZlbiBhY3QgYXMgYSBmYWN0b3IgdGhhdCBwcm9tb3RlcyBNVC1U UklMTCwgd2hvIGtub3dzLg0KDQpPbiB0aGUgb3RoZXIgaGFuZCwgc2luY2UgTVRSQSBpcyBiYWNr d2FyZCBjb21wYXRpYmxlLCBpdCBhbGxvd3Mgb3RoZXIgbm9uLU1UUkEgc29sdXRpb25zIGNvLWV4 aXN0IGluIHRoZSBjYW1wdXMuIFRoZXNlIHNvbHV0aW9ucyB3b3JrIGluIHRoZSBiYXNlIHRvcG9s b2d5LiBUaGVzZSBzb2x1dGlvbnMgbWF5IGluY2x1ZGUgdHVubmVsaW5nIGFwcHJvYWNoLiBBcyB3 ZSBrbm93LCB0dW5uZWxpbmcgaGFkIGJlZW4gd2lkZWx5IHVzZWQgb24gdHJhZGl0aW9uYWwgc3dp dGNoZXMuIElmIHRoZXJlIGFyZSBjdXN0b21lcnMgd2hvIHJlYWxseSBkbyBub3QgbGlrZSBNVCwg anVzdCB1c2UgdHVubmVsaW5nIGFwcHJvYWNoIG9yIG90aGVycy4NCg0KSG93ZXZlciwgSSBkb24n dCB0aGluayB0aGF0IG11bHRpLXRvcG9sb2d5IGlzIHRoYXQgZXhwZW5zaXZlLiBJIGJlbGlldmUg eW91IGhhdmUgaGVhcmQgb2Ygc2lsaWNvbnMgb3IgaW1wbGVtZW50YXRpb25zIGFscmVhZHkgc3Vw cG9ydCBtdWx0aS10b3BvbG9neSBmZWF0dXJlIGJlZm9yZSAyMDEwIHdoZW4gUkZDIDYzMjUgd2Fz IHB1Ymxpc2hlZC4NCg0KVGhhbmtzLA0KTWluZ3VpDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQq3orz+yMs6IFRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpIFt0c2VuZXZp ckBjaXNjby5jb21dDQq3osvNyrG85DogMjAxMsTqNNTCMsjVIDA6MjcNCrW9OiBKYW5hcmRoYW5h biBQYXRoYW5naSBOYXJhc2ltaGFuOyBNaW5ndWkgWmhhbmcNCkNjOiByYnJpZGdlQHBvc3RlbC5v cmc8bWFpbHRvOnJicmlkZ2VAcG9zdGVsLm9yZz4NCtb3zOI6IFJFOiBbcmJyaWRnZV0gQ2FsbCBm b3IgZHJhZnQtdGlzc2EtdHJpbGwtY210LTAwIHRvIFdHIGRyYWZ0DQpIaSBNaW5ndWkNCg0KSSBo YXZlIG5vdCBzZWVuIGFuIGFuc3dlciBmb3IgdGhlIHF1ZXN0aW9ucyBiZWxvdyBjb3VsZCB5b3Ug cGxlYXNlIGFuc3dlciBzaW1wbGUgcXVlc3Rpb246DQoNCldoYXQgaXMgeW91ciBwcm9wb3NhbCBm b3IgYWN0aXZlLWFjdGl2ZSBmb3IgcGVvcGxlIHdobyBkbyBub3Qgd2FudCB0byBydW4gbXVsdGkt dG9wb2xvZ3kgPw0KDQpGcm9tOiBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKQ0KU2VudDog RnJpZGF5LCBNYXJjaCAzMCwgMjAxMiAxOjM3IEFNDQpUbzogVGlzc2EgU2VuZXZpcmF0aG5lICh0 c2VuZXZpcik7ICdKYW5hcmRoYW5hbiBQYXRoYW5naSBOYXJhc2ltaGFuJzsgJ01pbmd1aSBaaGFu ZycNCkNjOiAncmJyaWRnZUBwb3N0ZWwub3JnJw0KU3ViamVjdDogUkU6IFtyYnJpZGdlXSBDYWxs IGZvciBkcmFmdC10aXNzYS10cmlsbC1jbXQtMDAgdG8gV0cgZHJhZnQNCg0KU21hbGwgdHlwbyBj b3JyZWN0aW9uDQoNCkZyb206IFRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpDQpTZW50OiBG cmlkYXksIE1hcmNoIDMwLCAyMDEyIDE6MjUgQU0NClRvOiAnSmFuYXJkaGFuYW4gUGF0aGFuZ2kg TmFyYXNpbWhhbic7IE1pbmd1aSBaaGFuZw0KQ2M6IHJicmlkZ2VAcG9zdGVsLm9yZzxtYWlsdG86 cmJyaWRnZUBwb3N0ZWwub3JnPg0KU3ViamVjdDogUkU6IFtyYnJpZGdlXSBDYWxsIGZvciBkcmFm dC10aXNzYS10cmlsbC1jbXQtMDAgdG8gV0cgZHJhZnQNCg0KSmFuYSBpcyBhYnNvbHV0ZWx5IGNv cnJlY3Qgb24gdGhlIG9ic2VydmF0aW9uIGJlbG93Lg0KDQpPbmUgbW9yZSBwb2ludCB0byBhZGQs IGFzIGhhdmUgaW5kaWNhdGVkIGVhcmxpZXINCg0KDQoxLiAgICAgICBOb3QgYWxsIGN1c3RvbWVy IHdpbGwgcnVuIG11bHRpLXRvcG9sb2d5DQoNCjIuICAgICAgIFlvdSBjYW5ub3QgZm9yY2UgY3Vz dG9tZXJzIHRvIHJ1biBtdWx0aS10b3BvbG9neSB3aGVuIHRoZXkgbmVlZCBhY3RpdmUtYWN0aXZl IGZvcndhcmRpbmcNCg0KMy4gICAgICAgV2hhdCBpcyB5b3VyIHNvbHV0aW9uIGZvciBjdXN0b21l cnMgd2hvICpkbyBOT1QqIHdhbnQgdG8gcnVuIG11bHRpLXRvcG9sb2d5ID8NCg0KRnJvbTogcmJy aWRnZS1ib3VuY2VzQHBvc3RlbC5vcmc8bWFpbHRvOnJicmlkZ2UtYm91bmNlc0Bwb3N0ZWwub3Jn PiBbbWFpbHRvOnJicmlkZ2UtYm91bmNlc0Bwb3N0ZWwub3JnXSBPbiBCZWhhbGYgT2YgSmFuYXJk aGFuYW4gUGF0aGFuZ2kgTmFyYXNpbWhhbg0KU2VudDogRnJpZGF5LCBNYXJjaCAzMCwgMjAxMiAx MjozMCBBTQ0KVG86IE1pbmd1aSBaaGFuZw0KQ2M6IHJicmlkZ2VAcG9zdGVsLm9yZzxtYWlsdG86 cmJyaWRnZUBwb3N0ZWwub3JnPg0KU3ViamVjdDogUmU6IFtyYnJpZGdlXSBDYWxsIGZvciBkcmFm dC10aXNzYS10cmlsbC1jbXQtMDAgdG8gV0cgZHJhZnQNCg0KSGkgTWluZ3VpDQoNCiAgV2hlbiB5 b3UgcmVhbGl6ZSBhY3RpdmUtYWN0aXZlLCB5b3UgYXJlIGFza2luZyBmb3IgdGhlIGFjdGl2ZS1h Y3RpdmUgdG8gYmUgc2V0dXAgaW4gYSBuZXcgdG9wb2xvZ3kgYW5kIG5vdCB0aGUgYmFzZSB0b3Bv bG9neS4gU28gdGhlc2Ugbm9kZXMgd2hpY2ggbmVlZCB0byB0YWxrIHRvIHRoZSBvdGhlciBub2Rl cyB3aGljaCBhcmUgYmVoaW5kIG5vbi1NVCBSQnJpZGdlcyBjYW5ub3QgZG8gc28gYW55IG1vcmUu DQoNCiAgU3BlY2lmaWNhbGx5IGZvciBNVCB0byBiZSBiYWNrd2FyZCBjb21wYXRpYmxlLCB5b3Ug bmVlZCBhbGwgbm9kZXMgd2hpY2ggd2FudCB0byB0YWxrIHRvIGVhY2ggb3RoZXIgcGFydCBvZiB0 aGUgYmFzZSB0b3BvbG9neS4gSWYgeW91IGRvIHRoYXQgeW91IGNhbm5vdCByZWFsaXplIGFjdGl2 ZS1hY3RpdmUuIElmIHlvdSBwdXQgdGhlIGFjdGl2ZS1hY3RpdmUgaW4gYSBuZXcgdG9wb2xvZ3ks IHRoYW4gdGhleSBjYW4gbm8gbG9uZ2VyIHRhbGsgdG8gbm9kZXMgb24gdGhlIGJhc2UgdG9wb2xv Z3kgb2Ygbm9uLU1UIFJCcmlkZ2VzLg0KDQpTbyB5ZXMsIE1ULVRSSUxMIGlzIGJhY2t3YXJkIGNv bXBhdGlibGUgZm9yIGJhc2UgdG9wb2xvZ3ksIGJ1dCB0aGUgcmVhbGl6YXRpb24gb2YgYWN0aXZl LWFjdGl2ZSB3aXRoIE1UIKhDIFRSSUxMIGlzIG5vdCBiYWNrd2FyZCBjb21wYXRpYmxlLiBUaGF0 IHdhcyB0aGUgcG9pbnQgSSB3YXMgYnJpbmdpbmcgdXAuDQoNClRoYW5rcw0KSmFuYQ0KDQoNCkZy b206IE1pbmd1aSBaaGFuZyBbbWFpbHRvOnpoYW5nbWluZ3VpQGh1YXdlaS5jb21dDQpTZW50OiBG cmlkYXksIE1hcmNoIDMwLCAyMDEyIDEyOjE1IFBNDQpUbzogSmFuYXJkaGFuYW4gUGF0aGFuZ2kg TmFyYXNpbWhhbg0KQ2M6IHJicmlkZ2VAcG9zdGVsLm9yZzxtYWlsdG86cmJyaWRnZUBwb3N0ZWwu b3JnPg0KU3ViamVjdDogtPC4tDogW3JicmlkZ2VdIENhbGwgZm9yIGRyYWZ0LXRpc3NhLXRyaWxs LWNtdC0wMCB0byBXRyBkcmFmdA0KDQpIaSBKYW5hLA0KDQpBbGwgUkJyaWRnZXMgaW4gdGhlIGNh bXB1cyBhcmUgaW4gdGhlIGJhc2UgdG9wb2xvZ3kuIE1UIFJCcmlkZ2VzIGNhbiB3ZWxsIGNvbW11 bmljYXRlIHdpdGggbm9uLU1UIFJCcmlkZ2VzIHVzaW5nIHRoZSBiYXNlIHRvcG9sb2d5Lg0KDQpJ IGZlZWwgdGhhdCB5b3UgYXJlIGFyZ3VpbmcgdGhhdCBNVC1UUklMTCBpcyBub3QgYmFja3dhcmQg Y29tcGF0aWJsZS4gVGhhdCBpcyBhIGluY29ycmVjdCBqdWRnZW1lbnQuDQoNClRoYW5rcywNCk1p bmd1aQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogSmFuYXJkaGFu YW4gUGF0aGFuZ2kgTmFyYXNpbWhhbiBbamFuYUBmb3JjZTEwbmV0d29ya3MuY29tXQ0Kt6LLzcqx vOQ6IDIwMTLE6jPUwjMwyNUgMTM6MjkNCrW9OiBNaW5ndWkgWmhhbmcNCkNjOiByYnJpZGdlQHBv c3RlbC5vcmc8bWFpbHRvOnJicmlkZ2VAcG9zdGVsLm9yZz4NCtb3zOI6IFJFOiBbcmJyaWRnZV0g Q2FsbCBmb3IgZHJhZnQtdGlzc2EtdHJpbGwtY210LTAwIHRvIFdHIGRyYWZ0DQpIaSBNaW5ndWks DQoNCldpdGggTVQgYXBwcm9hY2gsIHdoZW4gdHdvIFJCcmlkZ2VzIHdoaWNoIGhhZCBzdGF0aW9u cyB0YWxraW5nIHRvIGVhY2ggb3RoZXIgYW5kIG9uZSBvZiB0aGVtIGlzIGNvbnZlcnRlZCB0byBN VCwgdGhlbiB0aGUgY29tbXVuaWNhdGlvbiBpcyBicm9rZW4uIFNvIGl0IGRvZXMgbm90IGhhdmUg YmFja3dhcmQgY29tcHV0YWJpbGl0eS4NCg0KVGhhbmtzDQpKYW5hDQoNCg0KRnJvbTogTWluZ3Vp IFpoYW5nIFttYWlsdG86emhhbmdtaW5ndWlAaHVhd2VpLmNvbV0NClNlbnQ6IEZyaWRheSwgTWFy Y2ggMzAsIDIwMTIgMTI6MjcgQU0NClRvOiBKYW5hcmRoYW5hbiBQYXRoYW5naSBOYXJhc2ltaGFu DQpDYzogcmJyaWRnZUBwb3N0ZWwub3JnPG1haWx0bzpyYnJpZGdlQHBvc3RlbC5vcmc+DQpTdWJq ZWN0OiC08Li0OiBbcmJyaWRnZV0gQ2FsbCBmb3IgZHJhZnQtdGlzc2EtdHJpbGwtY210LTAwIHRv IFdHIGRyYWZ0DQoNCkhpIEphbmEsDQoNCkxldCB1cyBhc3N1bWUgdGhhdCBJIGhhdmUgMjAgUkJy aWRnZXMgaW4gdGhlIGNhbXB1cyB3aGljaCBoYXZlIGVuZCBzeXN0ZW1zIGNvbm5lY3RlZCB0byBp dCwgYW5kIGFsbCBvZiB0aGVtIG5lZWQgdG8gYmUgcmVhY2hhYmxlLiBTbyBpZiBhIGZldyBvZiB0 aGVtIGFyZSBjb252ZXJ0ZWQgdG8gTVRSQSBSQnJpZGdlcyB0byBzdXBwb3J0IGFjdGl2ZS1hY3Rp dmUsIGRvZXMgaXQgbWVhbiB0aGF0IFJCcmlkZ2VzIHdoaWNoIGFyZSBub3QgeWV0IGNvbnZlcnRl ZCB3aWxsIG5vdCBiZSBhYmxlIHRvIGFueW1vcmUgc2VlIHRoZSBub2RlcyBjb25uZWN0ZWQgdG8g dGhlc2UgdmlydHVhbCBSQnJpZGdlcz8gT3IgYW0gSSBtaXNzaW5nIHNvbWV0aGluZyBoZXJlPw0K DQpaTUc+IEFsdGhvdWdoIHBoeXNpY2FsIHJlYWNoYWJpbGl0eSBjYW4gYmUgYWxsIHRvIGFsbCwg aXQgZG9lcyBub3QgbWVhbiB0aGFuIHRoZSBlbmQgc3lzdGVtcyB3aWxsIHJlYWxseSBjb21tdW5p Y2F0ZSBpbiBhbiBhbGwgdG8gYWxsIG1hbm5lci4gSXQgaXMgcmVzdHJpY3RlZCBieSB0aGUgVkxB TiBjb25maWd1cmF0aW9uIG9mIHRoZSBjYW1wdXMuIExldCBtZSBnaXZlIHlvdSBhbiBleGFtcGxl LCBSQjEsIFJCMiwgUkIzIGFuZCBSQjQgaGF2ZSBhbiBhbGwgdG8gYWxsIGNvbm5lY3Rpb24uIFRo ZSBhY2Nlc3MgcG9ydHMgb2YgUkIxIGFuZCBSQjMgYXJlIGNvbmZpZ3VyZWQgYXMgdGhlIFZMQU4g Zm9yIGVuZCBzeXN0ZW1zIG9mIHRoZSBEZXB0IG9mIENvbXB1dGVyIFNjaWVuY2Ugd2hpbGUgdGhl IGFjY2VzcyBwb3J0cyBvZiBSQjIgYW5kIFJCNCBhcmUgY29uZmlndXJlZCBhcyBhbm90aGVyIFZM QU4gZm9yIGVuZCBzeXN0ZW1zIG9mIHRoZSBEZXB0IG9mIExpdGVyYXR1cmUuIEVuZCBzeXN0ZW1z IGZyb20gdGhlIHNhbWUgZGVwYXJ0bWVudCBjYW4gdGFsayB3aXRoIGVhY2ggb3RoZXIuIEJ1dCBl bmQgc3lzdGVtcyBmcm9tIHR3byBkaWZmZXJlbnQgZGVwYXJ0bWVudHMgd2lsbCBub3QgdGFsayB3 aXRoIGVhY2ggb3RoZXIuDQoNCkkgYW0gbm90IHN1cmUgaWYgdGhhdCBpcyBwcmFjdGljYWwsIGFu ZCBhbHdheXMgcG9zc2libGUgbWF5IGRlcGVuZCBvbiB0aGUgbm9kZXMgY29ubmVjdGVkIGFuZCBh bHNvIHdoYXQgY29udHJvbHMgYXJlIGF2YWlsYWJsZSBvbiB0aGVtDQoNClpNRz4gVGhpbmsgYWJv dXQgaXQuIFdoZW4gYW4gb3BlcmF0b3IgaGF2ZSBhIExBRyBjb25uZWN0ZWQgdG8gYSBncm91cCBv ZiBSQnJpZGdlcywgaGUgaGFzIHRvIGRlY2lkZSB3aGljaCBwb3J0IHRvIHBsdWcgdGhlIGNhYmxl cyBpbi4gSGUgbmVlZCBlbnRlciB0aGUgY29uc29sZSB3aW5kb3cgdG8gaW5wdXQgdGhlIGNvbW1h bmQgbGluZSB0byBjb25maWd1cmUgcGFyYW1ldGVycyBhbmQgc3RhcnQgdGhlIExBRy4gSGUgYWxz byBuZWVkIHRvIGNvbmZpZ3VyZSB0aGUgdHVwbGUgdXNlZCBmb3IgaGFzaGluZy4NCg0KVGhhbmtz LA0KTWluZ3VpDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8/sjL OiBKYW5hcmRoYW5hbiBQYXRoYW5naSBOYXJhc2ltaGFuIFtqYW5hQGZvcmNlMTBuZXR3b3Jrcy5j b21dDQq3osvNyrG85DogMjAxMsTqM9TCMzDI1SAwOjQ5DQq1vTogTWluZ3VpIFpoYW5nDQpDYzog cmJyaWRnZUBwb3N0ZWwub3JnPG1haWx0bzpyYnJpZGdlQHBvc3RlbC5vcmc+DQrW98ziOiBSRTog W3JicmlkZ2VdIENhbGwgZm9yIGRyYWZ0LXRpc3NhLXRyaWxsLWNtdC0wMCB0byBXRyBkcmFmdA0K SGkgTWluZ3VpLA0KDQpJIGFtIHNsaWdodGx5IGNvbmZ1c2VkLg0KDQpGb3IgdGhlIGludHJhLXRv cG9sb2d5IHNjZW5hcmlvLCBNVCB1bmF3YXJlIFJCcmlkZ2VzIHdpbGwgbm90IGFwcGVhciBpbiBh IHNwZWNpZmljIHRvcG9sb2d5IG90aGVyIHRoYW4gdGhlIGJhc2VkIHRvcG9sb2d5LiBJbiBvdGhl ciB3b3JkcywgTVRSQSBSQnJpZGdlcyBvbmx5IHRhbGtzIG9ubHkgd2l0aCBNVFJBIFJCcmlkZ2Vz LiBTaW5jZSB0aGV5IGFsbCBzdXBwb3J0IE1ULCBNVFJBIGNhbiB3b3JrIHZlcnkgd2VsbCBhbW9u ZyB0aGVtLiBJbiB0aGlzIHNjZW5hcmlvLCBNVFJBIFJCcmlkZ2VzIGFuZCBvbGQgUkJyaWRnZXMg Y28tZXhpc3QgaW4gdGhlIHNhbWUgY2FtcHVzLiBUaGVyZWZvcmUsIHRoaXMgaXMgYSBzb2xpZCBl eGFtcGxlIHRoYXQgTVRSQSBjYW4gYmUgZGVwbG95ZWQgaW5jcmVtZW50YWxseS4gUmVtZW1iZXIs IENNVCBkb2VzIG5vdCBhbGxvdyBzdWNoIGtpbmQgb2YgZGVwbG95bWVudC4NCg0KTGV0IHVzIGFz c3VtZSB0aGF0IEkgaGF2ZSAyMCBSQnJpZGdlcyBpbiB0aGUgY2FtcHVzIHdoaWNoIGhhdmUgZW5k IHN5c3RlbXMgY29ubmVjdGVkIHRvIGl0LCBhbmQgYWxsIG9mIHRoZW0gbmVlZCB0byBiZSByZWFj aGFibGUuIFNvIGlmIGEgZmV3IG9mIHRoZW0gYXJlIGNvbnZlcnRlZCB0byBNVFJBIFJCcmlkZ2Vz IHRvIHN1cHBvcnQgYWN0aXZlLWFjdGl2ZSwgZG9lcyBpdCBtZWFuIHRoYXQgUkJyaWRnZXMgd2hp Y2ggYXJlIG5vdCB5ZXQgY29udmVydGVkIHdpbGwgbm90IGJlIGFibGUgdG8gYW55bW9yZSBzZWUg dGhlIG5vZGVzIGNvbm5lY3RlZCB0byB0aGVzZSB2aXJ0dWFsIFJCcmlkZ2VzPyBPciBhbSBJIG1p c3Npbmcgc29tZXRoaW5nIGhlcmU/DQoNCkZvciB0aGUgaW50ZXItdG9wb2xvZ3kgc2NlbmFyaW8s IHdlIGFzc3VtZSBNVFJBIFJCcmlkZ2VzIGhhdmUgdG8gdGFsayB3aXRoIE1UIHVuYXdhcmUgUkJy aWRnZXMgKFRoaXMgaXMgYSByaWdvcm91cyBhc3N1bXB0aW9uLikgSWYgb3BlcmF0b3JzIGRvIHdh bnQgdG8gcmVhbGl6ZSBzdWNoIGtpbmQgb2YgY29ubmVjdGlvbiwgaXQgaXMgcmVhc29uYWJsZSB0 byBhc3N1bWUgdGhleSB3aWxsIGFjY2VwdCB0aGUgcmVxdWlyZW1lbnQgdGhhdCB0aGV5IG5lZWQg dG8gY29uZmlndXJlIHRoZWlyIGhhc2hpbmcgZnVuY3Rpb24gdG8gcmVtb3ZlIHRoZSBwb3NzaWJs ZSBNQUMgZmxpcC1mbG9wLg0KDQpJIGFtIG5vdCBzdXJlIGlmIHRoYXQgaXMgcHJhY3RpY2FsLCBh bmQgYWx3YXlzIHBvc3NpYmxlIG1heSBkZXBlbmQgb24gdGhlIG5vZGVzIGNvbm5lY3RlZCBhbmQg YWxzbyB3aGF0IGNvbnRyb2xzIGFyZSBhdmFpbGFibGUgb24gdGhlbQ0KDQpUaGFua3MNCkphbmEN Cg0KVGhhbmtzLA0KTWluZ3VpDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8 /sjLOiByYnJpZGdlLWJvdW5jZXNAcG9zdGVsLm9yZzxtYWlsdG86cmJyaWRnZS1ib3VuY2VzQHBv c3RlbC5vcmc+IFtyYnJpZGdlLWJvdW5jZXNAcG9zdGVsLm9yZ10gtPqx7SBNaW5ndWkgWmhhbmcg W3poYW5nbWluZ3VpQGh1YXdlaS5jb21dDQq3osvNyrG85DogMjAxMsTqM9TCMjnI1SAxODo1MA0K tb06IEphbmFyZGhhbmFuIFBhdGhhbmdpIE5hcmFzaW1oYW4NCkNjOiByYnJpZGdlQHBvc3RlbC5v cmc8bWFpbHRvOnJicmlkZ2VAcG9zdGVsLm9yZz4NCtb3zOI6ILTwuLQ6IFtyYnJpZGdlXSBDYWxs IGZvciBkcmFmdC10aXNzYS10cmlsbC1jbXQtMDAgdG8gV0cgZHJhZnQNCkhpIEphbmEsDQoNCj5J biBzZWN0aW9uIDQuMSwgY291bGQgeW91IHBsZWFzZSBleHBsYWluIGhvdyB0aGUgZnJhbWUgdGhh dCBpcyBpbmdyZXNzZWQgYnkgUkIxIHRocm91Z2ggUkJ2MDAxIGlzIHJlY2VpdmVkIGF0IFJCeD8N Cg0KVHdvIHNjZW5hcmlvcyBhcmUgZ2l2ZW4gaW4gU2VjdGlvbiA0LiBTZWN0aW9uIDQuMSB0YWxr cyBhYm91dCB0aGUgaW50cmEtdG9wb2xvZ3kgc2NlbmFyaW8uIEhlcmUsIFJCeCBpcyBub3QgaW4g dG9wb2xvZ3kgMSBzbyBpdCBpcyB1bnJlYWNoYWJsZSBieSBSQjEuIEl0IG5lZWQgbm90IHNldCB1 cCBhbnkgZm9yd2FyZGluZyBwYXRoIHRvIFJCeC4NCg0KVGhhbmtzLA0KTWluZ3VpDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8/sjLOiBKYW5hcmRoYW5hbiBQYXRoYW5naSBO YXJhc2ltaGFuIFtqYW5hQGZvcmNlMTBuZXR3b3Jrcy5jb21dDQq3osvNyrG85DogMjAxMsTqM9TC MjjI1SAyMjo1Mg0Ktb06IE1pbmd1aSBaaGFuZw0KQ2M6IHJicmlkZ2VAcG9zdGVsLm9yZzxtYWls dG86cmJyaWRnZUBwb3N0ZWwub3JnPg0K1vfM4jogUkU6IFtyYnJpZGdlXSBDYWxsIGZvciBkcmFm dC10aXNzYS10cmlsbC1jbXQtMDAgdG8gV0cgZHJhZnQNCkhpIE1pbmd1aSwNCg0KU2VjdGlvbiA0 LCBkb2VzIG5vdCBnaXZlIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkuIEZvciBlLmcuIGluIHNlY3Rp b24gNC4yIG11bHRpIGRlc3RpbmF0aW9uIGZyYW1lcyB3aWxsIGJlIGluZ3Jlc3NlZCB3aXRoIHR3 byBkaWZmZXJlbnQgYnJpZGdlIElEIGNhdXNpbmcgTUFDIG1vdmUsIGFuZCBoYXZpbmcgdG8gaW1w b3NlIHJlc3RyaWN0aW9ucyBvbiBoYXNoaW5nIGZ1bmN0aW9ucyBhdCB0aGUgZXh0ZXJuYWwgbm9k ZSBtYXkgb3IgbWF5IG5vdCBiZSBhY2NlcHRhYmxlIC4gSSBhbSBub3Qgc3VyZSB0aGF0IHRoaXMg Y2FuIGJlIGNsYXNzaWZpZWQgYXMgYmFja3dhcmQgY29tcGF0aWJsZSBzaW5jZSBpdCBpcyBub3Qg YSBmdWxsIHNvbHV0aW9uIGFuZCBjYW4gYWxzbyBjYXVzZSBmcmVxdWVudCBNQUMgZmxpcCBmbG9w cyBldGMuDQoNCkluIHNlY3Rpb24gNC4xLCBjb3VsZCB5b3UgcGxlYXNlIGV4cGxhaW4gaG93IHRo ZSBmcmFtZSB0aGF0IGlzIGluZ3Jlc3NlZCBieSBSQjEgdGhyb3VnaCBSQnYwMDEgaXMgcmVjZWl2 ZWQgYXQgUkJ4Pw0KDQpUaGFua3MNCkphbmENCg0KDQpGcm9tOiBNaW5ndWkgWmhhbmcgW21haWx0 bzp6aGFuZ21pbmd1aUBodWF3ZWkuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBNYXJjaCAyOCwgMjAx MiA3OjE1IFBNDQpUbzogSmFuYXJkaGFuYW4gUGF0aGFuZ2kgTmFyYXNpbWhhbg0KQ2M6IHJicmlk Z2VAcG9zdGVsLm9yZzxtYWlsdG86cmJyaWRnZUBwb3N0ZWwub3JnPg0KU3ViamVjdDogtPC4tDog W3JicmlkZ2VdIENhbGwgZm9yIGRyYWZ0LXRpc3NhLXRyaWxsLWNtdC0wMCB0byBXRyBkcmFmdA0K DQpIaSBKYW5hLA0KDQpJIHRoaW5rIEkgc2hvdWxkIGFuc3dlciB5b3VyIHF1ZXN0aW9uLiBJIGFt IE1pbmd1aSBaaGFuZy4NClBsZWFzZSByZWZlciB0byB0aGUgZHJhZnQgaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtemhhbmctdHJpbGwtbXVsdGktdG9wby1ycGZjLTAwLiBTZWN0aW9u IDQgaXMgcmlnaHQgZm9yIHRoZSB0b3BpYyB5b3UgYXJlIGludGVyZXN0ZWQuIEFzIGEgc3RhcnRl ciBkcmFmdCBvbiB0aGUgUlBGQyB1c2luZyBNdWx0aS10b3BvbG9neS4gSSB3aWxsIGJlIGhhcHB5 IHRvIHJlY2VpdmUgeW91ciBjb21tZW50cy4NCg0KVGhhbmtzLA0KTWluZ3VpDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0Kt6K8/sjLOiBKYW5hcmRoYW5hbiBQYXRoYW5naSBOYXJh c2ltaGFuIFtqYW5hQGZvcmNlMTBuZXR3b3Jrcy5jb21dDQq3osvNyrG85DogMjAxMsTqM9TCMjjI 1SAxOToxNA0Ktb06IFJvaGl0IFdhdHZlIChyd2F0dmUpOyBNaW5ndWkgWmhhbmc7IFJhZGlhIFBl cmxtYW47IFRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpDQpDYzogcmJyaWRnZUBwb3N0ZWwu b3JnPG1haWx0bzpyYnJpZGdlQHBvc3RlbC5vcmc+DQrW98ziOiBSRTogW3JicmlkZ2VdIENhbGwg Zm9yIGRyYWZ0LXRpc3NhLXRyaWxsLWNtdC0wMCB0byBXRyBkcmFmdA0KSGkgWmhhaSwNCg0KSW4g dGhlIE11bHRpLXRvcG9sb2d5IGNhc2UgSSBhbSBub3Qgc3VyZSB3aGF0IGlzIG1lYW50IGJ5IGlu Y3JlbWVudGFsbHkgZGVwbG95YWJsZS4gQXNzdW1pbmcgdGhhdCBhbGwgdGhlIFJCcmlkZ2VzIGlu IHRoZSBjYW1wdXMgZG8gbm90IHVuZGVyc3RhbmQgTVQgZXhjZXB0IGZvciB0aGUgUkJyaWRnZXMg d2hpY2ggcGFydGljaXBhdGUgaW4gdGhlIFZpcnR1YWwgUkJyb2RnZSwgaXQgbG9va3MgbGlrZSB0 aGlzIHdpbGwgY2F1c2UgTUFDIGZsaXAgZmxvcCBvbiB0aGUgb3RoZXIgUkJyaWRnZXMgYW5kIG90 aGVyIGlzc3VlcyBzaW5jZSBhbGwgdGhlIG90aGVyIFJCcmlkZ2VzIGRvIG5vdCB1bmRlcnN0YW5k IE1ULg0KDQpDb3VsZCB5b3UgcGxlYXNlIGV4cGxhaW4gaG93IE1UIGNhbiB3b3JrIGluIHN1Y2gg c2NlbmFyaW9zPw0KDQpUaGFua3MNCkphbmENCg0KDQpGcm9tOiByYnJpZGdlLWJvdW5jZXNAcG9z dGVsLm9yZzxtYWlsdG86cmJyaWRnZS1ib3VuY2VzQHBvc3RlbC5vcmc+IFttYWlsdG86cmJyaWRn ZS1ib3VuY2VzQHBvc3RlbC5vcmddIE9uIEJlaGFsZiBPZiBSb2hpdCBXYXR2ZSAocndhdHZlKQ0K U2VudDogV2VkbmVzZGF5LCBNYXJjaCAyOCwgMjAxMiAzOjUzIFBNDQpUbzogTWluZ3VpIFpoYW5n OyBSYWRpYSBQZXJsbWFuOyBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKQ0KQ2M6IHJicmlk Z2VAcG9zdGVsLm9yZzxtYWlsdG86cmJyaWRnZUBwb3N0ZWwub3JnPg0KU3ViamVjdDogUmU6IFty YnJpZGdlXSBDYWxsIGZvciBkcmFmdC10aXNzYS10cmlsbC1jbXQtMDAgdG8gV0cgZHJhZnQNCg0K DQpIaSBNaW5ndWksDQoNCjUuIEZhc3QgY29udmVyZ2VuY2Ugb24gZmFpbHVyZSByZWNvdmVyeS4g V2Uga25vdyB0aGF0IHJlc2lsaWVuY2UgaXMgb25lIG9mIHRoZSB0d28gbWFpbiBwdXJwb3NlcyBv ZiAiYWdncmVnYXRpb24iLiBUaGlzIGRpbWVuc2lvbiBkaXNjdXNzZXMgd2hldGhlciB0aGUgc29s dXRpb24gb2ZmZXJzIGEgd2F5IHRvIGRvIGZhc3QgZmFpbHVyZSByZWNvdmVyeSB3aGVuIHRoZXJl IGlzIGEgZmFpbHVyZSBvZiBhbiBhZ2dyZWdhdGVkIFJCcmlkZ2Ugb3IgbGluay4NCg0KUE46IE5P LiBUaGUgbmV3IGRpc3RyaWJ1dGlvbiB0cmVlIG5lZWQgdG8gYmUgcmVjb21wdXRlZC4NCg0KQ01U OiBOTy4gQSBvdmVyYWxsIHJlLWNvbmZpZ3VyYXRpb24gaXMgbmVjZXNzYXJ5Lg0KDQpNVFJBOiBZ RVMuDQoNCkNNVCBkb2VzIG5vdCBuZWVkIHJlY29uZmlndXJhdGlvbi4gSWYgb25lIFJicmlkZ2Ug YWR2ZXJ0aXppbmcgYWZmaW5pdHkgdGx2IGdvZXMgZG93biwgdGhlIHRyZWUgY2FuIGJlIHJvb3Rl ZCBhdCB0aGUgb3RoZXIgRWdyZXNzIFJicmlkZ2UgSUQgYWR2ZXJ0aXppbmcgYWZmaW5pdHkgdGx2 Lg0KDQpBbHNvLCBjb25zaWRlciBhZGRpbmcgZm9sbG93aW5nIHRvIHRoZSBjb21wYXJpc29uIHRh YmxlDQoNCk51bWJlciBvZiBOZXcgVExWcyAoYW5kIHJlc3VsdGluZyBjb21wbGV4aXR5KQ0KDQpQ TjogMw0KDQpDTVQ6IDENCg0KTVRSQTogbXVsdGlwbGUNCg0KVGhhbmtzDQpSb2hpdA0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogcmJyaWRnZS1ib3VuY2VzQHBvc3RlbC5vcmc8 bWFpbHRvOnJicmlkZ2UtYm91bmNlc0Bwb3N0ZWwub3JnPiBbbWFpbHRvOnJicmlkZ2UtYm91bmNl c0Bwb3N0ZWwub3JnXSBPbiBCZWhhbGYgT2YgTWluZ3VpIFpoYW5nDQpTZW50OiBXZWRuZXNkYXks IE1hcmNoIDI4LCAyMDEyIDI6MTAgQU0NClRvOiBSYWRpYSBQZXJsbWFuOyBUaXNzYSBTZW5ldmly YXRobmUgKHRzZW5ldmlyKQ0KQ2M6IHJicmlkZ2VAcG9zdGVsLm9yZzxtYWlsdG86cmJyaWRnZUBw b3N0ZWwub3JnPg0KU3ViamVjdDogtPC4tDogW3JicmlkZ2VdIENhbGwgZm9yIGRyYWZ0LXRpc3Nh LXRyaWxsLWNtdC0wMCB0byBXRyBkcmFmdA0KDQpIaSBSYWRpYSwNCg0KSXQgaXMgYSBnb29kIGlk ZWEgdG8gbGlzdCB0aGUgUHJvcyBhbmQgQ29ucyBvZiBlYWNoIHNvbHV0aW9uLiBUaGVyZSBhcmUg dGhyZWUgY2FuZGlkYXRlIHNvbHV0aW9ucyBmb3IgdGhlIHNhbWUgUlBGQyBwcm9ibGVtOiBQTiwg Q01UIGFuZCBNVFJBIChNdWx0aS1Ub3BvbG9neSBUUklMTCBmb3IgUkJyaWRnZSBBZ2dyZWdhdGlv bikuIExldCBtZSBjb21wYXJlIHRoZW0gaW4gdGhlIGZvbGxvd2luZyBkaW1lbnNpb25zLg0KDQox LiBXaGV0aGVyIHRoZSBzb2x1dGlvbiBpcyBpbmNyZW1lbnRhbGx5IGRlcGxveS1hYmxlLg0KDQpQ TjogWUVTLg0KDQpDTVQ6IE5PLg0KDQpNVFJBOiBZRVMuDQoNCjIuIFVzZSBvbmx5IGV4aXN0aW5n IHNpbGljb25zLg0KDQpQTjogTk8uIE5ldyBzaWxpY29uIGlzIG5lY2Vzc2FyeSB0byBzdXBwb3J0 ICJ0dW5uZWxpbmciIG9yIGVsc2UgTUFDIGFkZHJlc3NlcyBtYXkgZmxpcC1mbG9wLg0KDQpDTVQ6 IFlFUy4NCg0KTVRSQTogQ3VycmVudGx5IE5PLiBCdXQgYWZ0ZXIgbXVsdGktdG9wb2xvZ3kgaXMg c3VwcG9ydGVkIGJ5IFRSSUxMLCBpdCBpcyBhICJZRVMiLg0KDQozLiBNdWx0aS1jYXN0IHRyYWZm aWMgdXAgZnJvbSBSQnYgY2FuIGJlIGxvYWQtYmFsYW5jZWQuDQoNClBOOiBOTy4NCg0KQ01UOiBZ RVMuDQoNCk1UUkE6IFlFUy4NCg0KNC4gTXVsdGktY2FzdCB0cmFmZmljIGRvd24gdG8gUkJ2IGNh biBiZSBsb2FkLWJhbGFuY2VkLg0KDQpQTjogTk8uDQoNCkNNVDogWUVTLg0KDQpNVFJBOiBZRVMu DQoNCjUuIEZhc3QgY29udmVyZ2VuY2Ugb24gZmFpbHVyZSByZWNvdmVyeS4gV2Uga25vdyB0aGF0 IHJlc2lsaWVuY2UgaXMgb25lIG9mIHRoZSB0d28gbWFpbiBwdXJwb3NlcyBvZiAiYWdncmVnYXRp b24iLiBUaGlzIGRpbWVuc2lvbiBkaXNjdXNzZXMgd2hldGhlciB0aGUgc29sdXRpb24gb2ZmZXJz IGEgd2F5IHRvIGRvIGZhc3QgZmFpbHVyZSByZWNvdmVyeSB3aGVuIHRoZXJlIGlzIGEgZmFpbHVy ZSBvZiBhbiBhZ2dyZWdhdGVkIFJCcmlkZ2Ugb3IgbGluay4NCg0KUE46IE5PLiBUaGUgbmV3IGRp c3RyaWJ1dGlvbiB0cmVlIG5lZWQgdG8gYmUgcmVjb21wdXRlZC4NCg0KQ01UOiBOTy4gQSBvdmVy YWxsIHJlLWNvbmZpZ3VyYXRpb24gaXMgbmVjZXNzYXJ5Lg0KDQpNVFJBOiBZRVMuDQoNClRoZSBm b2xsb3dpbmcgdGFibGUgbGlzdHMgYWxsIGFib3ZlIGNvbXBhcmlzb25zIChBIGpwZyB2ZXJzaW9u IGlzIGFsc28gYXR0YWNoZWQganVzdCBpbiBjYXNlLikuIE1UUkEgaXMgYWx3YXlzIFlFUy4gSSB0 aGluayBpdCBkZXNlcnZlcyBvdXIgZm9sbG93LXVwLg0KDQorLS0tLS0tLS0rLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rDQoNCnxT b2x1dGlvbnxJbmNyZS1EZXBsb3l8T2xkIFNpbGljb258TEIgVXB3YXJkc3xMQiBEb3dud2FyZHN8 RmFzdCBDb252ZXJnZXwNCg0KKy0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0t LS0tLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tfA0KDQp8UE4gICAgICB8WUVTICAgICAg ICAgfE5PICAgICAgICAgfE5PICAgICAgICB8Tk8gICAgICAgICAgfE5PICAgICAgICAgICB8DQoN CistLS0tLS0tLSstLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tLSstLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tLXwNCg0KfENNVCAgICAgfE5PICAgICAgICAgIHxZRVMgICAgICAgIHxZ RVMgICAgICAgfFlFUyAgICAgICAgIHxOTyAgICAgICAgICAgfA0KDQorLS0tLS0tLS0rLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS18 DQoNCnxNVFJBICAgIHxZRVMgICAgICAgICB8WUVTKHdpbGwpICB8WUVTICAgICAgIHxZRVMgICAg ICAgICB8WUVTICAgICAgICAgIHwNCg0KKy0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0t LSstLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKw0KDQpUaGFua3MsDQoNCk1p bmd1aQ0KDQoNCreivP7IyzogcmJyaWRnZS1ib3VuY2VzQHBvc3RlbC5vcmc8bWFpbHRvOnJicmlk Z2UtYm91bmNlc0Bwb3N0ZWwub3JnPiBbcmJyaWRnZS1ib3VuY2VzQHBvc3RlbC5vcmddILT6se0g UmFkaWEgUGVybG1hbiBbcmFkaWFwZXJsbWFuQGdtYWlsLmNvbV0NCg0Kt6LLzcqxvOQ6IDIwMTLE 6jPUwjI4yNUgMTI6NTINCg0Ktb06IFRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpDQoNCkNj OiByYnJpZGdlQHBvc3RlbC5vcmc8bWFpbHRvOnJicmlkZ2VAcG9zdGVsLm9yZz4NCg0K1vfM4jog UmU6IFtyYnJpZGdlXSBDYWxsIGZvciBkcmFmdC10aXNzYS10cmlsbC1jbXQtMDAgdG8gV0cgZHJh ZnQNCg0KDQpJdCBpcyBteSB1bmRlcnN0YW5kaW5nIHRoYXQNCg0KYSkgQ01UIGRvZXMgcmVxdWly ZSBjaGFuZ2luZyBhbGwgdGhlIFJCcyBpbiB0aGUgY2FtcHVzDQoNCmIpIENNVCByZXF1aXJlcyB0 aGVyZSBiZSBhdCBsZWFzdCBhcyBtYW55IHRyZWVzIGFzIHRoZXJlIGFyZSBhY3RpdmUvYWN0aXZl IFJCcyBvbiBhbnkgbGluaw0KDQoNCg0KT2YgY291cnNlLCBubyBzb2x1dGlvbiBpcyBpZGVhbC4g IEl0IG1pZ2h0IGhhdmUgYmVlbiBuaWNlIHRvIHdyaXRlIHVwIGFsbCB0aGUgcHJvcG9zZWQgc29s dXRpb25zIHRvIHRoaXMgYW5kIHByb3MvY29ucy4gTWF5YmUgaXQncw0KDQpzdGlsbCB3b3J0aCBk b2luZy4NCg0KDQoNClNvIGZyb20gbWVtb3J5Li4ub3RoZXIgcHJvcG9zYWxzIGZvciBhbGxvd2lu ZyBSMSwgUjIsIGFuZCBSMyB0byBiZSBhY3RpdmUvYWN0aXZlL2FjdGl2ZSBvbiBhIGxpbms6DQoN Cg0KDQpGaXJzdCBub3RlOiByZWdhcmRsZXNzIG9mIHdoZXRoZXIgdGhlaXIgcG9ydCB0byB0aGUg bGluayBpcyBpbiBhIHRyZWUsIHVuaWNhc3Qgd29ya3MsIGFuZCB0aGV5IGNhbiB1c2UgdGhlIHBz ZXVkb25vZGUNCg0Kbmlja25hbWUgd2hlbiBlbmNhcHN1bGF0aW5nIHVuaWNhc3QuDQoNCg0KDQpB bHNvLCBpZiBSaSdzIHBvcnQgdG8gdGhlIGxpbmsgaXMgaW4gYXQgbGVhc3Qgb25lIHRyZWUsIFJp IGNhbiB1c2UgdGhlIHBzZXVkb25vZGUgbmlja25hbWUgZm9yIHRoYXQgbGluayB3aGVuIGVuY2Fw c3VsYXRpbmcNCg0KbXVsdGlkZXN0aW5hdGlvbiBmcmFtZXMgZm9yIGluZ3Jlc3MsIGFuZCB0aGUg UlBGIGNoZWNrIHdpbGwgd29yayB3aXRob3V0IGFueSBwcm9ibGVtcy4NCg0KDQoNCkhvd2V2ZXIs IGlmIFJpJ3MgcG9ydCB0byB0aGUgbGluayBpcyBub3QgaW4gYW55IG9mIHRoZSB0cmVlcywNCg0K aGVyZSB3ZXJlIHNvbWUgb2YgdGhlIHByb3Bvc2VkIHNvbHV0aW9ucy4gIFNvLCBsZXQncyBzYXkg dGhhdCBSMSBhbmQgUjIncyBwb3J0IHRvIHRoZSBzaGFyZWQgbGluayBpcyBpbiBhdCBsZWFzdCBv bmUgdHJlZSwgYW5kIFIzJ3MNCg0KcG9ydCB0byB0aGUgbGluayBpcyBub3QgaW4gYW55IG9mIHRo ZSB0cmVlcywgYW5kIFIzIG5lZWRzIHRvIGVuY2Fwc3VsYXRlIGEgbXVsdGlkZXN0aW5hdGlvbiBm cmFtZToNCg0KDQoNCjEpIFIzIGNvdWxkIHR1bm5lbCBpdCB0byBvbmUgb2Yge1IxLCBSMn0sIGFu ZCBsZXQgdGhlbSBpbmplY3QgdGhlIHBhY2tldCAod2l0aCBwc2V1ZG9ub2RlIG5pY2tuYW1lKSBp bnRvIHRoZSBjYW1wdXMuDQoNCg0KDQpQcm86IERvZXNuJ3QgYWZmZWN0IGFueSBSQnMgb3RoZXIg dGhhbiB0aGUgb25lcyBvbiB0aGUgbGluazsgYmFja3dhcmRzIGNvbXBhdGlibGUuICBDb246IG1v cmUgaG9wcywgbWlnaHQgYmUgZGlmZmljdWx0DQoNCmluIHNvbWUgaW1wbGVtZW50YXRpb25zIGZv ciBSMyB0byBmb3J3YXJkIGJ5IHR1bm5lbGluZywgbWlnaHQgYmUgZGlmZmljdWx0IGZvciBSMiB0 byBhY2NlcHQgYSB0dW5uZWxlZCBwYWNrZXQuDQoNCg0KDQoyKSBSMyBjb3VsZCB1c2UgaXRzIG93 biBuaWNrbmFtZSBpbnN0ZWFkIG9mIHRoZSBwc2V1ZG9ub2RlIG5pY2tuYW1lIGluIHRoaXMgY2Fz ZQ0KDQoNCg0KUHJvOiBEb2Vzbid0IGFmZmVjdCBhbnkgUkJzIG90aGVyIHRoYW4gdGhlIG9uZXMg b24gdGhlIGxpbms7IGJhY2t3YXJkcyBjb21wYXRpYmxlLiAgQ29uOiBNQUMgbGVhcm5pbmcgaW4g ZGlzdGFudCBSQnMgd2lsbCBoYXZlDQoNCmZyZXF1ZW50IGxlYXJuaW5nIGNoYW5nZXMgb2YgdGhl IHNvdXJjZSBNQUMgUyBiZXR3ZWVuIGJlaW5nIG9uIHRoZSBwc2V1ZG9ub2RlIG5pY2tuYW1lICh3 aGVuZXZlciBTIHNlbmRzIHVuaWNhc3QsDQoNCm9yIG11bHRpY2FzdCB0aHJvdWdoIFIxIG9yIFIy KSwgb3IgYmVpbmcgb24gUjMgKHdoZW4gUjMgaGFzIHRvIGVuY2Fwc3VsYXRlIGEgbXVsdGlkZXN0 aW5hdGlvbiBmcmFtZSBmcm9tIFMpLg0KDQoNCg0KLS0tLS0tDQoNClRoZXJlIG1pZ2h0IGhhdmUg YmVlbiBzb21lIG90aGVyIHByb3Bvc2FscywgYnV0IHRoZXkgd291bmQgdXAgbm90IHRvIHdvcmsu DQoNCg0KDQpQZXJzb25hbGx5LCBJIGRvbid0IGxvdmUgdGhlIENNVCB0aGluZyBiZWNhdXNlIG9m IHRoZSB0d28gZGlzYWR2YW50YWdlcyBJIG1lbnRpb25lZCBhYm92ZSwgYnV0IEkgY2FuIGxpdmUg d2l0aCBpdC4NCg0KDQoNClJhZGlhDQoNCg== --_000_CE35792847FBE84687FF9117132C8EFD471144176BEXCHCLUSTER11_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Tissa,=

 <= /p>

 

a) In terms of control plane states and work, I think MT is muc= h more heavy and also if all elements have to be in all topologies (for the= sake of active-active), that would increase the states on all nodes

 

So I agree with you that yes MT may be usable as a= ctive-active solution, but it would be wrong to say that MT is a better act= ive-active or should be mainly used for active-active mode.

 

Thanks

Jana=

 <= /p>

 

<= p class=3DMsoNormal>From: Tissa Senevirathne (tsenevir) [mailto:tsenevir@cisc= o.com]
Sent: Monday, April 02, 2012 8:44 PM
To: Mingui= Zhang; Janardhanan Pathangi Narasimhan
Cc: rbridge@postel.orgSubject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draf= t

 

Hi Mingui

 

You = are assuming a lot.

That= is:

1. People will deplo= y Multi-topology when they need active-active forwarding.

2. It is easy to deploy and people will li= ke it

3. It is already out= there

 

#2 you can check % vise how many MT in= stallations there in L3 world.

 

Again I would = summarize CMT need only one TLV, MT require lot more TLV and require major = changes to RFC6326 control plane.

 

Backward co= mpatibility of control plane in my world is not an issue as we are exchangi= ng more emails than really trying to deploy RBridges and there are no RBrid= ges there forwarding packets in real networks.

 

However, your claim that MT is backward compatible without any tweaks is = false (Jana has pointed out several times).

 

Like I have said, many times before, MT approach you have may be utilized = for active-active forwarding in MT installations. I will support that solut= ion as an optimization for MT, certainly I **do not** support it  as t= he only solution for all active-active deployments. If we agree on that the= n we have consensus and both work can move forward (we need to make progres= s). If not then we can continue to disagree and I request WG chairs to deci= de via a vote on making CMT a WG document.

 

 

Thanks

Tissa

 

Fr= om: Mingui Zhang [mailto:zhang= mingui@huawei.com]
Sent: Monday, April 02, 2012 7:54 AM
<= b>To: Tissa Senevirathne (tsenevir); Janardhanan Pathangi NarasimhanCc: rbridge@postel.orgSubject: =B4= =F0=B8=B4: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

 

Hi Tissa,

 

We know that RBridge Aggregation is used to increase the access capa= city without upgrade of the RBridges. The motivation is the same as the&nbs= p;traditional LAG: it will help customers to reduce their investment. = If active-active multi-homing can work well, customers will eager to purcha= se MT feature. It may even act as a factor that promotes MT-TRILL, who know= s.

 

On the other hand, since M= TRA is backward compatible, it allows other non-MTRA solutions co-exist in = the campus. These solutions work in the base topology. These solutions may = include tunneling approach. As we know, tunneling had been widely used on t= raditional switches. If there are customers who really do not like MT, just= use tunneling approach or others. 

 

However, I don't think that multi-topology is that expensive. I= believe you have heard of silicons or implementations already support mult= i-topology feature before 2010 when RFC 6325 was published. 

 

Thanks,

Mingui=

 

=

=B7=A2=BC=FE=C8=CB: Tissa Senevirathne (tsenevir) [tsenevir@cisco.com]
<= b>=B7=A2=CB=CD=CA= =B1=BC=E4: 2012=C4=EA4=D4=C22=C8=D5 0= :27
= =B5=BD: Janardhanan Pathangi Narasimhan; M= ingui Zhang
Cc: rbridge@pos= tel.org
=D6=F7=CC=E2: RE: [rbridge] Call f= or draft-tissa-trill-cmt-00 to WG draft

=

Hi Mingui

 

I have not s= een an answer for the questions below could you please answer simple questi= on:

 

What is your proposal for active-active for pe= ople who do not want to run multi-topology ?

 

From: Tissa Senevirathne (tsenevir)
Sent: Friday, March 30, 2012 1:37 AM
To: Tissa Senevirathne (tsenevir= ); 'Janardhanan Pathangi Narasimhan'; 'Mingui Zhang'
Cc: 'rbridge= @postel.org'
Subject: RE: [rbridge] Call for draft-tissa-trill-cm= t-00 to WG draft

 

Small typo correction

&nb= sp;

<= p class=3DMsoNormal>From: Tissa Senevirathne (tsenevi= r)
Sent: Friday, March 30, 2012 1:25 AM
To: 'Janardhan= an Pathangi Narasimhan'; Mingui Zhang
Cc: rbridge@postel.org
Subject: = RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

<= span style=3D'color:black'> 

Jana is absolutely correct on the observation below.

&nbs= p;

One more point to add, as have indicated earlier

&nbs= p;

1. &nb= sp;     Not all customer will run multi-t= opology

2.&n= bsp;      You cannot force customers= to run multi-topology when they need active-active forwarding

3.    =    What is your solution for customers who *do N= OT* want to run multi-topology ?

 

From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] = On Behalf Of Janardhanan Pathangi Narasimhan
Sent: Friday, Ma= rch 30, 2012 12:30 AM
To: Mingui Zhang
Cc: rbridge@postel.org
Su= bject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

 

Hi Mingui=

 

  When you real= ize active-active, you are asking for the active-active to be setup in a ne= w topology and not the base topology. So these nodes which need to talk to = the other nodes which are behind non-MT RBridges cannot do so any more.

=  

  Specifically for MT to be backward compatible= , you need all nodes which want to talk to each other part of the base topo= logy. If you do that you cannot realize active-active. If you put the activ= e-active in a new topology, than they can no longer talk to nodes on the ba= se topology of non-MT RBridges.

 

So yes, MT-TRILL i= s backward compatible for base topology, but the realization of active-acti= ve with MT =A8C TRILL is not backward compatible. That was the point I was = bringing up.

 <= /span>

Thanks

Jana

 <= /span>

 

From: Mingui Zhang [<= a href=3D"mailto:zhangmingui@huawei.com" target=3D"_blank">mailto:zhangming= ui@huawei.com]
Sent: Friday, March 30, 2012 12:15 PM
T= o: Janardhanan Pathangi Narasimhan
Cc: rbridge@postel.org
Subject:= =B4=F0=B8= =B4: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

 

<= p class=3DMsoNormal>Hi Jana,

 

All RB= ridges in the campus are in the base topology. MT RBridges can well communi= cate with non-MT RBridges using the base topology. 

=  

<= p class=3DMsoNormal>I feel that you are arguing that MT-TRILL is not ba= ckward compatible. That is a incorrect judgement.

 <= /span>

Thanks,

Mingui

=B7= =A2=BC=FE=C8=CB: Janardhanan Pathangi Nara= simhan [jana@force10networks.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C230=C8=D5 13:29
=B5=BD: Mingui Zhang
Cc: rbridge@postel.org
=D6=F7=CC=E2: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Mingui,

 

With MT approach, w= hen two RBridges which had stations talking to each other and one of them i= s converted to MT, then the communication is broken. So it does not have ba= ckward computability. =

 

Thanks

Jana=

 

 

From: Ming= ui Zhang [mailt= o:zhangmingui@huawei.com]
Sent: Friday, March 30, 2012 12:27= AM
To: Janardhanan Pathangi Narasimhan
Cc: rbridge@postel.org
S= ubject: =B4=F0=B8=B4: [rbridge] Call for draft-tissa-trill-cmt-00 to W= G draft

 <= /p>

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 me= an that RBridges which are not yet converted will not be able to anymore se= e the nodes connected to these virtual RBridges? Or am I missing something = here?

 =

ZMG> Although physical re= achability can be all to all, it does not mean than the end systems will re= ally communicate in an all to all manner. It is restricted by the VLAN conf= iguration 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 configur= ed as the VLAN for end systems of the Dept of Computer Science while the ac= cess 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 w= ith each other.

 

I am no= t sure if that is practical, and always possible may depend on the nodes co= nnected and also what controls are available on them

 = ;

ZMG> Think about it. When an operator have a LAG conn= ected to a group of RBridges, he has to decide which port to plug the cable= s in. He need enter the console window to input the command line to configu= re parameters and start the LAG. He also need to configure the tuple used f= or hashing.

<= div>

 =

Thanks,

<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:blac= k'>Mingui

 

 

=  

<= div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'>

=B7=A2=BC=FE=C8=CB: Janardhanan Pathangi Narasimhan [jana@force10networks.com]
<= span lang=3DZH-CN style=3D'font-size:10.0pt;color:black'>=B7=A2=CB=CD=CA=B1= =BC=E4: 2012=C4=EA3=D4=C230=C8=D5 0:49<= br>=B5= =BD: Mingui Zhang
Cc: rbridge@postel.org
=D6=F7=CC= =E2: RE: [rbridge] Call for draft-tissa-tr= ill-cmt-00 to WG draft=

Hi Mingui,

 <= /span>

I am slightly confused.

 

= For the intra-topology scenario, MT unaware RBridges will not appear in a s= pecific topology other than the based topology. In other words, MTRA RBridg= es 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 de= ployment.

 

Let us assume that I have 20 RBridges i= n the campus which have end systems connected to it, and all of them need t= o be reachable. So if a few of them are converted to MTRA RBridges to suppo= rt active-active, does it mean that RBridges which are not yet converted wi= ll 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 t= o realize such kind of connection, it is reasonable to assume they will acc= ept the requirement that they need to configure their hashing function to r= emove the possible MAC flip-flop. <= o:p>

 

= I am not sure if that is practical, and always possible may depend on the n= odes connected and also what controls are available on them

&nbs= p;

Thanks

=

Jana

 

Thanks,=

Mingui

=B7=A2=BC=FE=C8=CB: rbridge-bounces@postel.org [rbridge-bounces@postel.org] =B4=FA=B1=ED= Mingui Zhang [zhangmingui@huawei.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C229=C8=D5 18:50
=B5=BD:= Janardhanan Pathangi Narasimhan
Cc: rbridge@postel.org
=D6=F7=CC=E2<= /span>: =B4=F0=B8=B4: [rbridge] Call for draft-t= issa-trill-cmt-00 to WG draft=

Hi Jana, 

<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:blac= k'> 

>In section 4.1, could you please explain = how the frame that is ingressed by RB1 through RBv001 is received at RBx? 

 <= o:p>

Two scenarios are = given in Section 4. Section 4.1 talks about the intra-topology scenario. He= re, RBx is not in topology 1 so it is unreachable by RB1. It need not set u= p any forwarding path to RBx.=

 

Than= ks,

Mingui

=

=B7=A2=BC=FE=C8=CB:= Janardhanan Pathangi Narasimhan [jana@force10networks.com]<= br>=B7= =A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C228=C8=D5<= /span> 22:52
=B5=BD: Mingui Zhang
Cc= : rbridge@poste= l.org
=D6=F7=CC=E2: RE: [rbridge] Call for= draft-tissa-trill-cmt-00 to WG draft

Hi Mingui,

 

Section 4, does not give backward compatibility. Fo= r e.g. in section 4.2 multi destination frames will be ingressed with two d= ifferent bridge ID causing MAC move, and having to impose restrictions on h= ashing functions at the external node may or may not be acceptable . I am n= ot 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.

&n= bsp;

In section 4.1, could you please explain how the frame that i= s ingressed by RB1 through RBv001 is received at RBx?

 

Thanks

Jana

 

 

<= b>From: Mingui Zhang [mailto:zhangmingui@huawei.com]
Sent: Wednesday, March 28, 2012 7:15 PM
To: Janardhanan Pathangi Nar= asimhan
Cc: rbridge@postel.org
Subject: =B4=F0=B8=B4: [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-0= 0. Section 4 is right for the topic you are interested. As a starter dr= aft on the RPFC using Multi-topology. I will be happy to receive your comme= nts.

 

Thanks,

Mingui

=

=B7=A2=BC=FE=C8=CB: Janardhanan Pathangi Narasimhan [jana@force10networks.com]
=B7=A2=CB= =CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C228=C8=D5<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:blac= k'> 19:14
=B5=BD: Rohit Watve (rwatve); Mingui= Zhang; Radia Perlman; Tissa Senevirathne (tsenevir)
Cc: rbridge@postel.org
= =D6=F7= =CC=E2: RE: [rbridge] Call for draft-tissa= -trill-cmt-00 to WG draft

Hi Zhai,

&nbs= p;

In the Multi-topology case I am not sure what is meant by incre= mentally deployable. Assuming that all the RBridges in the campus do not un= derstand MT except for the RBridges which participate in the Virtual RBrodg= e, it looks like this will cause MAC flip flop on the other RBridges and ot= her issues since all the other RBridges do not understand MT.

&nbs= p;

Could you please explain how MT can work in such scenarios?

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>
Thanks

Jana

 

 

From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org= ] On Behalf Of Rohit Watve (rwatve)
Sent: Wednesday, M= arch 28, 2012 3:53 PM
To: Mingui Zhang; Radia Perlman; Tissa Sene= virathne (tsenevir)
Cc: rbridge@postel.org
Subject: Re: [rbridge] Call= for draft-tissa-trill-cmt-00 to WG draft

 

Hi Mingui,

5. Fast convergen= ce on failure recovery. We know that resilience is one of the two main purp= oses of "aggregation". This dimension discusses whether the solut= ion offers a way to do fast failure recovery when there is a failure of an = aggregated RBridge or link. <= /span>

PN: NO. The n= ew distribution tree need to be recomputed.

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

MTRA: YES.

CMT does not need r= econfiguration. If one Rbridge advertizing affinity tlv goes down, the<= span style=3D'color:black'> tree can be rooted at the other Egress Rbridge= ID advertizing affinity tlv.=

Also, cons= ider adding following to the comparison table

Number of New TLVs (and resulting complexity)

PN: 3=

CMT:= 1

MTRA: multiple

Thanks
Rohit<= /span>

-----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: Ra= dia Perlman; Tissa Senevirathne (tsenevir)
Cc: rbridge@postel.org
Subject: =B4=F0=B8=B4: [rbridge]= Call for draft-tissa-trill-cmt-00 to WG draft

Hi Radia,

<= span style=3D'font-family:Consolas;color:black'>It is a good idea to list t= he 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 A= ggregation). Let me compare them in the following dimensions.

1. Whether the solution is incrementally deploy-able.

PN: YES.=

C= MT: NO.

MTRA: YES.

2. Use only existing silicons.

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

CMT: YES.

MTRA: Currently NO. But after multi-topology i= s 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 con= vergence on failure recovery. We know that resilience is one of the two mai= n 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. <= /o:p>

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 c= ase.). 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&n= bsp;         |YES   =      |YES       |YES = ;        |NO    &nbs= p;      |<= /o:p>

+------= --+------------+-----------+----------+------------+-------------|

|MTRA    |YES   &nbs= p;     |YES(will)  |YES    &nb= sp;  |YES         |YES &n= bsp;        |

+--------+------------+-----------+----------+------------+---------= ----+

Thanks,

Mingui

&n= bsp;

=B7=A2=BC=FE=C8=CB: rbridge-bounces@postel.org [rbridge-bounces@postel.org] =B4=FA=B1=ED Radia Perlman [radiaperlman@gmail.com]

=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C228=C8=D5 12:52

=B5=BD: Tissa Senevirathne (tsenevir)

Cc: rbridge@postel.org

=D6=F7=CC=E2: Re: [r= bridge] 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 lea= st as many trees as there are active/active RBs on any link

 

Of course, no sol= ution 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, an= d 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 ps= eudonode

nickname when encapsulating unica= st.

 

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

multidestination frames for ingress, and the RPF check will work = without any problems.<= /p>

 

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

here were some of the proposed solu= tions.  So, let's say that R1 and R2's port to the shared link is in a= t least one tree, and R3's

port to the lin= k is not in any of the trees, and R3 needs to encapsulate a multidestinatio= n frame:

 

1) R3 could tunnel it to one of {R1, R2}, and let them inject the pa= cket (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 implementatio= ns for R3 to forward by tunneling, might be difficult for R2 to accept a tu= nneled packet.

<= span style=3D'font-family:Consolas;color:black'> 

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

=

 

Pro: Doesn't affect any RBs other than the ones on the lin= k; 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).

 

------<= span style=3D'color:black'>

There might have been some other proposals, but t= hey wound up not to work.

 

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

 <= /span>

Radia =

 

<= /div>
= --_000_CE35792847FBE84687FF9117132C8EFD471144176BEXCHCLUSTER11_-- --===============0887068609== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge --===============0887068609==-- From rbridge-bounces@postel.org Mon Apr 2 09:20:08 2012 Return-Path: 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 0BB3021F86EC for ; Mon, 2 Apr 2012 09:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.725 X-Spam-Level: *** X-Spam-Status: No, score=3.725 tagged_above=-999 required=5 tests=[AWL=0.674, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, MIME_HTML_MOSTLY=0.001, 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 UsX2fbRaoQy4 for ; Mon, 2 Apr 2012 09:20:04 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 5D21F21F865B for ; Mon, 2 Apr 2012 09:20:04 -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 q32FDR1K019226; Mon, 2 Apr 2012 08:13:30 -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 q32FD7H9019184 for ; Mon, 2 Apr 2012 08:13:16 -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 <0M1U00IDCY9UN9@szxga03-in.huawei.com> for rbridge@postel.org; Mon, 02 Apr 2012 23:13:06 +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 <0M1U0058OY9U8X@szxga03-in.huawei.com> for rbridge@postel.org; Mon, 02 Apr 2012 23:13:06 +0800 (CST) Received: from szxeml210-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AIE41505; Mon, 02 Apr 2012 23:13:05 +0800 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by szxeml210-edg.china.huawei.com (172.24.2.183) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 02 Apr 2012 23:12:53 +0800 Received: from SZXEML507-MBS.china.huawei.com ([169.254.7.100]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0323.003; Mon, 02 Apr 2012 23:13:04 +0800 Date: Mon, 02 Apr 2012 15:13:03 +0000 From: Mingui Zhang Subject: =?gb2312?B?tPC4tDogtPC4tDogW3JicmlkZ2VdIENhbGwgZm9yIGRyYWZ0LXRpc3NhLXRy?= =?gb2312?Q?ill-cmt-00_to_WG_draft?= In-reply-to: X-Originating-IP: [172.24.1.45] To: Janardhanan Pathangi Narasimhan Message-id: <4552F0907735844E9204A62BBDD325E728CB1FB1@SZXEML507-MBS.china.huawei.com> MIME-version: 1.0 Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: =?gb2312?B?tPC4tDogW3JicmlkZ2VdIENhbGwgZm9yIGRyYWZ0LXRpc3NhLXRyaWxsLWNt?= =?gb2312?Q?t-00_to_WG_draft?= Thread-index: AQHNC6M4X8TnOZ/31Umc7no1WTsFHJZ9Cj0AgABclICAABKNgIABKjzxgAAYT0D//+PaAIAAy5WsgAAUHfCAABB74IAAKcBDgAASQ3CAAUvIPoAAP81cgAAoPaCAACBD3IAAtGNggAAT3tCAAA2IQIAAAkK2gAADovD///9TQYAAHoYggAAAUQSAAAYzhYADegIOgAAJaYCAAYsMQA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4552F0907735844E9204A62BBDD325E728CB1F36@SZXEML507-MBS.china.huawei.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: zhangmingui@huawei.com Cc: "'rbridge@postel.org'" X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0930759284==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org --===============0930759284== Content-type: multipart/alternative; boundary="Boundary_(ID_rCIsuDB2dDon3hjJlff68A)" Content-language: zh-CN --Boundary_(ID_rCIsuDB2dDon3hjJlff68A) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 SGkgSmFuYSwNCg0KWW91IG9mZmVyIGEgZGV0YWlsIGV4cGxhbmF0aW9uIG9uIGhvdyB0dW5uZWxp bmcgYXBwcm9hY2ggd29ya3MuIEkgYmVsaWV2ZSB0aGUgbGF0dGVyIGNhc2UgYmVsb3cgaXMgbm90 IENNVCBhbnltb3JlLiBJdCdzIG5vcm1hbCBUUklMTCBwbHVzIHR1bm5lbGluZy4NCg0KIkhlbmNl IGVpdGhlciB0aGUgZW50aXJlIGNhbXB1cyBidWlsZHMgdHJlZXMgYmFzZWQgb24gQWZmaW5pdHkg VExWIG9yIHRoZSBlbnRpcmUgY2FtcHVzIGJ1aWxkcyB0cmVlcyBiYXNlZCBvbiBub3JtYWwgbWVj aGFuaXNtIGFuZCBpZ25vcmUgQWZmaW5pdHkgVExWLiINCg0KVGhpcyBpcyBhY3R1YWxseSBub3Qg YmFja3dhcmQgY29tcGF0YWJpbGl0eS4gSWYgeW91IHJlYWQgdGhlIEZHTCBkcmFmdCwgeW91IHdp bGwga25vdyB3aGF0IGlzIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkuDQoNClRoYW5rcywNCk1pbmd1 aQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8/sjLOiBKYW5hcmRoYW5h biBQYXRoYW5naSBOYXJhc2ltaGFuIFtqYW5hQGZvcmNlMTBuZXR3b3Jrcy5jb21dDQq3osvNyrG8 5DogMjAxMsTqNNTCMcjVIDIzOjUwDQq1vTogTWluZ3VpIFpoYW5nDQpDYzogJ3JicmlkZ2VAcG9z dGVsLm9yZycNCtb3zOI6IFJFOiC08Li0OiBbcmJyaWRnZV0gQ2FsbCBmb3IgZHJhZnQtdGlzc2Et dHJpbGwtY210LTAwIHRvIFdHIGRyYWZ0DQoNCkhpIE1pbmd1aSwNCg0KUGxlYXNlIGxvb2sgYXQg c2VjdGlvbiA0LjMuIKGwQWZmaW5pdHkgU3ViLVRMViBDYXBhYmlsaXR5obEgqEMgVGhpcyBpcyB0 byBpbmRpY2F0ZSBpZiBhbiBSQnJpZGdlIGNhbiBvciBjYW5ub3Qgc3VwcG9ydCBBZmZpbml0eSBU TFYuIFRoaXMgY2FwYWJpbGl0eSBpbmNsdWRlcyBib3RoIHRoZSBhYmlsaXR5IHRvIHNldCB0aGUg QWZmaW5pdHkgVExWIGFuZCBhbHNvIHRoZSBjYXBhYmlsaXR5IHRvIGFjdCBvbiBpdCwgaS5lLiBj YWxjdWxhdGUgdHJlZXMgYmFzZWQgb24gQWZmaW5pdHkgVExWDQoNClRoZSBiYWNrd2FyZCBjb21w YXRpYmlsaXR5IG9wZXJhdGVzIGFzIGZvbGxvd3MNCg0KDQotICAgICAgICAgIE9uY2UgdGhlIExT UCBkYXRhIGJhc2UgaXMgZm9ybWVkLCBpZiBhbGwgUkJyaWRnZXMgaW4gdGhlIGNhbXB1cyBzdXBw b3J0IEFmZmluaXR5IFRMViwgdGhhbiBhbGwgdGhlIFJCcmlkZ2VzIGluIHRoZSBjYW1wdXMgd2ls bCBidWlsZCB0aGUgdHJlZSBiYXNlZCBvbiB0aGUgQWZmaW5pdHkgVExWDQoNCi0gICAgICAgICAg SWYgdGhlcmUgaXMgb25lIG9yIG1vcmUgUkJyaWRnZXMgd2hpY2ggZG8gbm90IGFkdmVydGlzZSCh sEFmZmluaXR5IENhcGFiaWxpdHmhsSwgdGhhbiBhbGwgdGhlIFJCcmlkZ2VzIGluIHRoZSBjYW1w dXMgd2lsbCBidWlsZCB0aGUgdHJlZSBiYXNlZCBvbiBub3JtYWwgbWVjaGFuaXNtIGFuZCB3aWxs IGlnbm9yZSB0aGUgYWZmaW5pdHkgVExWIChpbmNsdWRpbmcgdGhvc2Ugcm91dGVycyB3aGljaCBh cmUgY2FwYWJsZSBvZiB1bmRlcnN0YW5kaW5nIHRoaXMpDQoNCkhlbmNlIGVpdGhlciB0aGUgZW50 aXJlIGNhbXB1cyBidWlsZHMgdHJlZXMgYmFzZWQgb24gQWZmaW5pdHkgVExWIG9yIHRoZSBlbnRp cmUgY2FtcHVzIGJ1aWxkcyB0cmVlcyBiYXNlZCBvbiBub3JtYWwgbWVjaGFuaXNtIGFuZCBpZ25v cmUgQWZmaW5pdHkgVExWLiBUaGVyZSBpcyBubyBzaXR1YXRpb24gd2hlcmUgdGhlIFRSRUVTIGFy ZSBvdXQgb2Ygc3luYyBiZXR3ZWVuIGRpZmZlcmVudCBub2Rlcw0KDQpJbiB0ZXJtcyBvZiB0dW5u ZWxpbmcsIHRoZSBhcHByb2FjaCBpcyBhcyBmb2xsb3dzDQoNCg0KLSAgICAgICAgICBXaGVuIHRo ZXJlIGFyZSBzb21lIG5vbiBDTVQgbm9kZXMsIGFsbCBSQnJpZGdlcyBidWlsZCB0aGUgdHJlZXMg YmFzZWQgb24gdGhlIHJlZ3VsYXIgbWVjaGFuaXNtLiBJbiB0aGlzIHNpdHVhdGlvbiwgbGV0IHVz IGFzc3VtZSB0aGF0IHRoZXJlIGFyZSB0aHJlZSBSQnJpZGdlcyBSMSwgUjIgYW5kIFIzIGpvaW5p bmcgdG8gZW11bGF0ZSBhIHZpcnR1YWwgUkJyaWRnZSBSQlYuIE5vdyBzaW5jZSB0aGUgdHJlZXMg Zm9ybWVkIGFyZSBiYXNlZCBvbiBub3JtYWwgbWVjaGFuaXNtIGFuZCBub3QgYmFzZWQgb24gQWZm aW5pdHkgVExWLCBpdCBpcyBub3QgZ3VhcmFudGVlZCB0aGF0IGFsbCBSMSwgUjIgYW5kIFIzIHdp bGwgaGF2ZSBhIGNvbm5lY3Rpdml0eSB0byBSQlYgb24gYXQgbGVhc3Qgb25lIHRyZWUuDQoNCi0g ICAgICAgICAgQnV0IGl0IGlzIGFsd2F5cyBHdWFyZW50ZWVkIHRoYXQgYXQgbGVhc3Qgb25lIG9m IFIxLCBSMiBhbmQgUjMgd2lsbCBoYXZlIHRoaXMgY29ubmVjdGl2aXR5DQoNCi0gICAgICAgICAg U28gaWYgZm9yIGFyZ3VtZW50IHNha2UgUjEgaGFzIHRoaXMgY29ubmVjdGl2aXR5IHRvIFJCdiwg dGhlbiB3aGVuIFIyIGFuZCBSMyBnZXQgYSBtdWx0aS1kZXN0aW5hdGlvbiBmcmFtZSwgdGhleSBj YW5ub3QgaW5ncmVzcyB0aGF0IHNpbmNlIHRoZXkgY2Fubm90IHNldCB0aGUgaW5ncmVzcyBOaWNr bmFtZSBhcyBSQnYuIFNvIHRoZXkgd2lsbCB0dW5uZWwgaXQgdG8gUjEsIHdoaWNoIHdpbGwgdGhl biBpbmdyZXNzIGl0IG9uIHRoZWlyIGJlaGFsZiBpbnRvIHRoZSBUUklMTCBjYW1wdXMgbmV0d29y aywgYXMgaXQgaGFzIHRoZSBjb25uZWN0aXZpdHkgdG8gUkJ2LCBhbmQgY2FuIHVzZSB0aGUgaW5n cmVzcyBuaWNrbmFtZSBvZiBSQlYgaW4gbXVsdGktZGVzdGluYXRpb24gZnJhbWVzIHdpdGhvdXQg YW55IHByb2JsZW1zIG9mIFJQRiBjaGVjayBmYWlsdXJlcy4NCg0KTGV0IHVzIGtub3cgaWYgdGhp cyBpcyBub3QgY2xlYXIgaW4gdGhlIGRyYWZ0LCBtYXliZSB3ZSBjYW4gYWRkIG1vcmUgdGV4dCB0 byBjbGFyaWZ5IHRoaXMgb3BlcmF0aW9uIGluIHRoZSBuZXh0IHZlcnNpb24gb2YgdGhlIGRyYWZ0 IGlmIHRoYXQgaXMgdGhlIGNhc2UuDQoNCkFuZCBub3RlIHRoaXMgdHVubmVsaW5nIGlzIG9ubHkg Zm9yIG11bHRpLWRlc3RpbmF0aW9uIGZyYW1lcyBhbmQgbm90IGZvciB1bmljYXN0IGZyYW1lcyBi ZWluZyBpbmdyZXNzZWQgYnkgUjIgYW5kIFIzLg0KDQpUaGFua3MNCkphbmENCg0KDQpGcm9tOiBN aW5ndWkgWmhhbmcgW21haWx0bzp6aGFuZ21pbmd1aUBodWF3ZWkuY29tXQ0KU2VudDogU3VuZGF5 LCBBcHJpbCAwMSwgMjAxMiA4OjM3IFBNDQpUbzogSmFuYXJkaGFuYW4gUGF0aGFuZ2kgTmFyYXNp bWhhbg0KQ2M6ICdyYnJpZGdlQHBvc3RlbC5vcmcnDQpTdWJqZWN0OiC08Li0OiC08Li0OiBbcmJy aWRnZV0gQ2FsbCBmb3IgZHJhZnQtdGlzc2EtdHJpbGwtY210LTAwIHRvIFdHIGRyYWZ0DQoNCkhp IEphbmEsDQoNCkxldCBtZSB1c2UgYW4gZXhhbXBsZSB0byBleHBsYWluLiBTdXBwb3NlIFJCMSwg UkIyIGFyZSBtZW1iZXJzIG9mIHRoZSBhZ2dyZWdhdGlvbi4gUkJyIGlzIGEgcmVtb3RlIFJCcmlk Z2Ugd2hvIHN1cHBvcnQgQ01ULiBJdCBtYXkgY29tbXVuaWNhdGUgd2l0aCB0aGUgYWdncmVnYXRp b24uIFdlIGFzc3VtZSB0aGF0IHRoZSB0cmFuc2l0IFJCcmlkZ2UgUkJ0IGlzIG5vbiBDTVQuIEl0 IGNhbm5vdCBjYWxjdWxhdGUgdGhlIHRyZWVzIGFzIFJCciB3aGljaCBjYWxjdWxhdGVzIHR3byB0 cmVlcyBhY2NvcmRpbmcgdG8gdGhlIEFmZmluaXR5IFRMVnMgZnJvbSBSQjEgYW5kIFJCMi4gVGhl biB0aGUgdHdvIHRyZWVzIGNhbGN1bGF0ZWQgYnkgUkJyIGFyZSBpbmNvbnNpc3RlbnQgd2l0aCB0 aG9zZSBjYWxjdWxhdGVkIGJ5IFJCdC4gTXVsdGljYXN0IHRyYWZmaWMgd2lsbCBub3QgYmUgZm9y d2FyZGVkIGNvcnJlY3RseSB0aHJvdWdoIFJCdC4NCg0KRnJvbSB0aGUgYWJvdmUgZXhhbXBsZSwg eW91IGNhbiBzZWUgdGhhdCBDTVQgZG9lcyBub3QgYWxsb3cgbm9uIENNVCBSQnJpZGdlIGV4aXN0 IGluIHRoZSBzYW1lIGNhbXB1cyBiZWNhdXNlIG9mIHRoZSBpbmNvbnNpc3RlbmNlIG9mIGRpc3Ry aWJ1dGlvbiB0cmVlIGNhbGN1bGF0aW9uLiBXaGVuIHlvdSBzYWlkIHRoYXQgQ01UIGNhbiByZXNv cnQgdG8gdHVubmVsaW5nLiBUaGF0IGlzIHRvIHNheSB0aGVyZSBpcyBub24gQ01UIFJCcmlkZ2Vz IGluIHRoZSBjYW1wdXMuIFRoZW4gd2UgYWx3YXlzIGhhdmUgdG8gcmVzb3J0IHRvIHR1bm5lbGlu ZyBhbmQgdHJhZGl0aW9uYWwgZGlzdHJpYnV0aW9uIHRyZWUgY2FsY3VsYXRpb24gZHVlIHRvIHRo ZSBpbmNvbnNpc3RlbmNlIG9mIGFmZmluaXR5IGRpc3RyaWJ1dGlvbiB0cmVlIGNhbGN1bGF0aW9u LiBUaGF0IGlzIG5vdCBDTVQgYW55bW9yZS4NCg0KQmFzZWQgb24gYWJvdmUgYW5hbHlzaXMsIHdl IGNhbiBjb25jbHVkZSB0aGF0IHR1bm5lbGluZyBhcHByb2FjaCBhbmQgQ01UIGFyZSBtdXR1YWxs eSAgZXhjbHVzaXZlLg0KDQpUaGFua3MsDQpNaW5ndWkNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCreivP7IyzogSmFuYXJkaGFuYW4gUGF0aGFuZ2kgTmFyYXNpbWhhbiBbamFu YUBmb3JjZTEwbmV0d29ya3MuY29tXQ0Kt6LLzcqxvOQ6IDIwMTLE6jPUwjMwyNUgMTc6NTgNCrW9 OiBNaW5ndWkgWmhhbmcNCkNjOiAncmJyaWRnZUBwb3N0ZWwub3JnJw0K1vfM4jogUmU6ILTwuLQ6 IFtyYnJpZGdlXSBDYWxsIGZvciBkcmFmdC10aXNzYS10cmlsbC1jbXQtMDAgdG8gV0cgZHJhZnQN Cg0KSGkgTWluZ3VpDQoNCkkgZGlkIG5vdCB1bmRlcnN0YW5kIHlvciBzdGF0ZW1lbnQuIFdoZW4g bm9uIENNVCBub2RlcyBhcmUgcHJlc2VudCBhbGwgbm9kZXMgKGluY2x1ZGluZyBDTVQgbm9kZXMp IGNhbGN1bGF0ZSB0cmVlcyBhcyBwZXIgdGhlIGJhc2Ugc3RhbmRhcmQuIFNvIGV2ZXJ5IG5vZGUg aXMgcHJldHR5IG11Y2ggcHJlc2VudC4NCg0KSW4gdGhpcyBzaXR1YXRpb24gYW5kIHdpdGggYWN0 aXZlLWFjdGl2ZSB3aGVuIGEgUkJyaWRnZSBnZXRzIG11bHRpIGRlc3RpbmF0aW9uIGZyYW1lIGZy b20gQ0UgZGV2aWNlcyBhbmQgaXQgZG9lcyBub3QgaGF2ZSB0aGUgdmlydHVhbCBSQnJpZGdlIGNv bm5lY3RlZCBpbiBhbnkgdHJlZSwgaXQgdHVubmVscyB0aGUgZnJhbWUgdG8gb25lIG9mIHRoZSBS QnJpZGdlcyB0aGF0IGhhcyB0aGUgVlJCIGNvbm5lY3Rpdml0eSwgd2hpY2ggdGhlbiBpbmdyZXNz ZXMgdGhpcyBmcmFtZS4NCg0KTGV0IG1lIGtub3cgaWYgdGhlcmUgaXMgYW55IGlzc3VlIHdpdGgg dGhpcw0KDQpUaGFua3MNCkphbmENCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CkZyb206IE1pbmd1aSBaaGFuZw0KVG86IEphbmFyZGhhbmFuIFBhdGhhbmdpIE5hcmFzaW1oYW4N CkNjOiByYnJpZGdlQHBvc3RlbC5vcmc8bWFpbHRvOnJicmlkZ2VAcG9zdGVsLm9yZz4NClNlbnQ6 IEZyaSBNYXIgMzAgMTU6MTI6NTkgMjAxMg0KU3ViamVjdDogtPC4tDogW3JicmlkZ2VdIENhbGwg Zm9yIGRyYWZ0LXRpc3NhLXRyaWxsLWNtdC0wMCB0byBXRyBkcmFmdA0KSGkgSmFuYSwNCg0KV2hl biB5b3Ugc2F5IENNVCBkaXNhcHBlYXJzLCBJIGFtIGFzc3VtaW5nIHlvdSBtZWFuIHRoYXQgd2Ug d2lsbCBoYXZlIHRvIGRvIHR1bm5lbGluZyBmb3IgYWxsIG11bHRpLWRlc3RpbmF0aW9uIGZyYW1l cy4gTXVjaCB0aGUgc2FtZSBhcyB3aGF0IHdlIHdvdWxkIGhhdmUgdG8gZG8gd2l0aCBNVCB3aGVu IG9uZSBub24tTVQgUkJyaWRnZSBleGlzdHMuDQoNClpNRz4gTm90IGV4YWN0bHkuIEluIENNVCwg ZXZlbiB5b3UgZG8gbm90IG5lZWQgdG8gY29tbXVuaWNhdGUgd2l0aCBub24tQ01UIFJCcmlkZ2Vz LCB0aGUgQ01UIGNhbm5vdCBiZSB1c2VkIGlmIG5vbi1DTVQgUkJyaWRnZXMgZXhpc3QgaW4gdGhl IGNhbXB1cy4gTm9uLUNNVCBSQnJpZGdlcyBldmVuIGNhbm5vdCBhcHBlYXIgYXMgdHJhbnNpdCBS QnJpZGdlcy4gQXMgeW91IGtub3csIHRoZSB0cmVlcyB3aWxsIG5vdCBiZSBjYWxjdWxhdGVkIGFj Y29yZGluZyB0byB0aGUgYWZmaW5pdHkgVExWIGJ5IHRoZXNlIFJCcmlkZ2VzLg0KDQpUaGFua3Ms DQpNaW5ndWkNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogSmFu YXJkaGFuYW4gUGF0aGFuZ2kgTmFyYXNpbWhhbiBbamFuYUBmb3JjZTEwbmV0d29ya3MuY29tXQ0K t6LLzcqxvOQ6IDIwMTLE6jPUwjMwyNUgMTc6MzYNCrW9OiBNaW5ndWkgWmhhbmcNCkNjOiByYnJp ZGdlQHBvc3RlbC5vcmc8bWFpbHRvOnJicmlkZ2VAcG9zdGVsLm9yZz4NCtb3zOI6IFJFOiBbcmJy aWRnZV0gQ2FsbCBmb3IgZHJhZnQtdGlzc2EtdHJpbGwtY210LTAwIHRvIFdHIGRyYWZ0DQpIaSBN aW5ndWksDQoNClRoZSB0dW5uZWxpbmcgaXMgb25seSBmb3IgbXVsdGktZGVzdGluYXRpb24gZnJh bWVzIGFuZCBub3QgZm9yIHVuaWNhc3QgZnJhbWVzLiBIZW5jZSBub3Qgc3VyZSB3aGF0IHlvdSBh cmUgcmVmZXJyaW5nIHRvIGhlcmUgYXMgdHVubmVsaW5nIGJhc2VkIG9uIGVncmVzcyBSQnJpZGdl Lg0KDQpXaGVuIHlvdSBzYXkgQ01UIGRpc2FwcGVhcnMsIEkgYW0gYXNzdW1pbmcgeW91IG1lYW4g dGhhdCB3ZSB3aWxsIGhhdmUgdG8gZG8gdHVubmVsaW5nIGZvciBhbGwgbXVsdGktZGVzdGluYXRp b24gZnJhbWVzLiBNdWNoIHRoZSBzYW1lIGFzIHdoYXQgd2Ugd291bGQgaGF2ZSB0byBkbyB3aXRo IE1UIHdoZW4gb25lIG5vbi1NVCBSQnJpZGdlIGV4aXN0cy4NCg0KVGhhbmtzDQpKYW5hDQoNCg0K RnJvbTogTWluZ3VpIFpoYW5nIFttYWlsdG86emhhbmdtaW5ndWlAaHVhd2VpLmNvbV0NClNlbnQ6 IEZyaWRheSwgTWFyY2ggMzAsIDIwMTIgMToyNiBQTQ0KVG86IEphbmFyZGhhbmFuIFBhdGhhbmdp IE5hcmFzaW1oYW4NCkNjOiByYnJpZGdlQHBvc3RlbC5vcmc8bWFpbHRvOnJicmlkZ2VAcG9zdGVs Lm9yZz4NClN1YmplY3Q6ILTwuLQ6IFtyYnJpZGdlXSBDYWxsIGZvciBkcmFmdC10aXNzYS10cmls bC1jbXQtMDAgdG8gV0cgZHJhZnQNCg0KSGkgSmFuYSwNCg0KVGhlIGJlYXV0eSBvZiBNVFJBIGlz IHRoYXQgYWdncmVnYXRlZCBtZW1iZXJzIGNhbiBkZXRlcm1pbmUgdGhlbXNlbHZlcyB3aGV0aGVy IHRvIHVzZSB0dW5uZWxpbmcgb3Igbm90IGFjY29yZGluZyB0byB0aGUgZWdyZXNzIFJCcmlkZ2Vz LiBGb3IgTVQgZWdyZXNzIFJCcmlkZ2VzLCB0aGV5IG5lZWQgbm90IGRvIHR1bm5lbGluZy4NCg0K QXMgbG9uZyBhcyB0aGVyZSBpcyBvbmx5IG9uZSBvbGQgUkJyaWRnZSBpbiB0aGUgY2FtcHVzLCBD TVQgZG9lcyBub3Qgd29yay4gSW4gb3JkZXIgdG8gYmUgYmFja3dhcmQgY29tcGF0aWJsZSB1c2lu ZyB0dW5uZWxpbmcsIENNVCBqdXN0IHNpbXBseSBkaXNhcHBlYXJzIHRvdGFsbHkuIFRoZXJlIGlz IG5vIENNVCBhbnltb3JlLg0KDQpUaGFua3MsDQpNaW5ndWkNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQq3orz+yMs6IEphbmFyZGhhbmFuIFBhdGhhbmdpIE5hcmFzaW1oYW4gW2ph bmFAZm9yY2UxMG5ldHdvcmtzLmNvbV0NCreiy83KsbzkOiAyMDEyxOoz1MIzMMjVIDE1OjQ4DQq1 vTogTWluZ3VpIFpoYW5nDQpDYzogcmJyaWRnZUBwb3N0ZWwub3JnPG1haWx0bzpyYnJpZGdlQHBv c3RlbC5vcmc+DQrW98ziOiBSRTogW3JicmlkZ2VdIENhbGwgZm9yIGRyYWZ0LXRpc3NhLXRyaWxs LWNtdC0wMCB0byBXRyBkcmFmdA0KSGkgTWluZ2hpLA0KDQpXaXRoIHR1bm5lbGluZyBhbGwgYXBw cm9hY2hlcyBhcmUgYmFja3dhcmQgY29tcGF0aWJsZSwgaW5jbHVkaW5nIENNVC4NCg0KVGhhbmtz DQpKYW5hDQoNCg0KRnJvbTogTWluZ3VpIFpoYW5nIFttYWlsdG86emhhbmdtaW5ndWlAaHVhd2Vp LmNvbV0NClNlbnQ6IEZyaWRheSwgTWFyY2ggMzAsIDIwMTIgMToxNCBQTQ0KVG86IEphbmFyZGhh bmFuIFBhdGhhbmdpIE5hcmFzaW1oYW4NCkNjOiByYnJpZGdlQHBvc3RlbC5vcmc8bWFpbHRvOnJi cmlkZ2VAcG9zdGVsLm9yZz4NClN1YmplY3Q6ILTwuLQ6IFtyYnJpZGdlXSBDYWxsIGZvciBkcmFm dC10aXNzYS10cmlsbC1jbXQtMDAgdG8gV0cgZHJhZnQNCg0KSGkgSmFuYSwNCg0KSGF2ZSB5b3Ug Zm9yZ290dGVuIHRoZSB0dW5uZWxpbmcgYXBwcm9hY2g/IEluIG9yZGVyIHRvIGVuYWJsZSB0aGUg Y29tbXVuaWNhdGlvbiBiZXR3ZWVuIE1UUkEgUkJyaWRnZXMgYW5kIG5vbi1NVCBSQnJpZGdlcywg d2UgY2FuIGFsd2F5cyByZXNvcnQgdG8gdGhlIHR1bm5lbGluZyBhcHByb2FjaCB0byByZWRpcmVj dCB0aGUgYWdncmVnYXRlZCB0cmFmZmljIHRvIHRoZSBvbmx5IHBhcmVudCBvZiBSQnYgb24gdGhl IGRpc3RyaWJ1dGlvbiB0cmVlIG9mIHRoZSBiYXNlIHRvcG9sb2d5IGZvciBkZWxpdmVyeS4NCg0K SSBkaWQgbm90IG1lbnRpb24gdHVubmVsaW5nIHNpbmNlIEkgbGlrZSBzaW1wbGUgc29sdXRpb25z LiBJIHRoaW5rIFNlY3Rpb24gNC4yIG9mIG15IGRyYWZ0IGRpZCBvZmZlciBhbm90aGVyIHNpbXBs ZXIgc29sdXRpb24gdG8gYWxsb3cgdXMgdG8gZW5hYmxlIHRoZSBjb21tdW5pY2F0aW9uIGJldHdl ZW4gTVJUQSBSQnJpZGdlcyBhbmQgbm9uLU1UIFJCcmlkZ2VzLiBJIGluc2lzdCBvbiB0aGlzIHNv bHV0aW9uIHVudGlsIG9wZXJhdG9ycyB0ZWxsIG1lIGl0IGlzIG5vdCB3b3JrYWJsZS4NCg0KU28s IG9mIGNvdXJzZSBNUlRBIGlzIGJhY2t3YXJkIGNvbXBhdGlibGUuDQoNClRoYW5rcywNCk1pbmd1 aQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogSmFuYXJkaGFuYW4g UGF0aGFuZ2kgTmFyYXNpbWhhbiBbamFuYUBmb3JjZTEwbmV0d29ya3MuY29tXQ0Kt6LLzcqxvOQ6 IDIwMTLE6jPUwjMwyNUgMTU6MzANCrW9OiBNaW5ndWkgWmhhbmcNCkNjOiByYnJpZGdlQHBvc3Rl bC5vcmc8bWFpbHRvOnJicmlkZ2VAcG9zdGVsLm9yZz4NCtb3zOI6IFJFOiBbcmJyaWRnZV0gQ2Fs bCBmb3IgZHJhZnQtdGlzc2EtdHJpbGwtY210LTAwIHRvIFdHIGRyYWZ0DQpIaSBNaW5ndWkNCg0K ICBXaGVuIHlvdSByZWFsaXplIGFjdGl2ZS1hY3RpdmUsIHlvdSBhcmUgYXNraW5nIGZvciB0aGUg YWN0aXZlLWFjdGl2ZSB0byBiZSBzZXR1cCBpbiBhIG5ldyB0b3BvbG9neSBhbmQgbm90IHRoZSBi YXNlIHRvcG9sb2d5LiBTbyB0aGVzZSBub2RlcyB3aGljaCBuZWVkIHRvIHRhbGsgdG8gdGhlIG90 aGVyIG5vZGVzIHdoaWNoIGFyZSBiZWhpbmQgbm9uLU1UIFJCcmlkZ2VzIGNhbm5vdCBkbyBzbyBh bnkgbW9yZS4NCg0KICBTcGVjaWZpY2FsbHkgZm9yIE1UIHRvIGJlIGJhY2t3YXJkIGNvbXBhdGli bGUsIHlvdSBuZWVkIGFsbCBub2RlcyB3aGljaCB3YW50IHRvIHRhbGsgdG8gZWFjaCBvdGhlciBw YXJ0IG9mIHRoZSBiYXNlIHRvcG9sb2d5LiBJZiB5b3UgZG8gdGhhdCB5b3UgY2Fubm90IHJlYWxp emUgYWN0aXZlLWFjdGl2ZS4gSWYgeW91IHB1dCB0aGUgYWN0aXZlLWFjdGl2ZSBpbiBhIG5ldyB0 b3BvbG9neSwgdGhhbiB0aGV5IGNhbiBubyBsb25nZXIgdGFsayB0byBub2RlcyBvbiB0aGUgYmFz ZSB0b3BvbG9neSBvZiBub24tTVQgUkJyaWRnZXMuDQoNClNvIHllcywgTVQtVFJJTEwgaXMgYmFj a3dhcmQgY29tcGF0aWJsZSBmb3IgYmFzZSB0b3BvbG9neSwgYnV0IHRoZSByZWFsaXphdGlvbiBv ZiBhY3RpdmUtYWN0aXZlIHdpdGggTVQgqEMgVFJJTEwgaXMgbm90IGJhY2t3YXJkIGNvbXBhdGli bGUuIFRoYXQgd2FzIHRoZSBwb2ludCBJIHdhcyBicmluZ2luZyB1cC4NCg0KVGhhbmtzDQpKYW5h DQoNCg0KRnJvbTogTWluZ3VpIFpoYW5nIFttYWlsdG86emhhbmdtaW5ndWlAaHVhd2VpLmNvbV0N ClNlbnQ6IEZyaWRheSwgTWFyY2ggMzAsIDIwMTIgMTI6MTUgUE0NClRvOiBKYW5hcmRoYW5hbiBQ YXRoYW5naSBOYXJhc2ltaGFuDQpDYzogcmJyaWRnZUBwb3N0ZWwub3JnPG1haWx0bzpyYnJpZGdl QHBvc3RlbC5vcmc+DQpTdWJqZWN0OiC08Li0OiBbcmJyaWRnZV0gQ2FsbCBmb3IgZHJhZnQtdGlz c2EtdHJpbGwtY210LTAwIHRvIFdHIGRyYWZ0DQoNCkhpIEphbmEsDQoNCkFsbCBSQnJpZGdlcyBp biB0aGUgY2FtcHVzIGFyZSBpbiB0aGUgYmFzZSB0b3BvbG9neS4gTVQgUkJyaWRnZXMgY2FuIHdl bGwgY29tbXVuaWNhdGUgd2l0aCBub24tTVQgUkJyaWRnZXMgdXNpbmcgdGhlIGJhc2UgdG9wb2xv Z3kuDQoNCkkgZmVlbCB0aGF0IHlvdSBhcmUgYXJndWluZyB0aGF0IE1ULVRSSUxMIGlzIG5vdCBi YWNrd2FyZCBjb21wYXRpYmxlLiBUaGF0IGlzIGEgaW5jb3JyZWN0IGp1ZGdlbWVudC4NCg0KVGhh bmtzLA0KTWluZ3VpDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8/sjLOiBK YW5hcmRoYW5hbiBQYXRoYW5naSBOYXJhc2ltaGFuIFtqYW5hQGZvcmNlMTBuZXR3b3Jrcy5jb21d DQq3osvNyrG85DogMjAxMsTqM9TCMzDI1SAxMzoyOQ0Ktb06IE1pbmd1aSBaaGFuZw0KQ2M6IHJi cmlkZ2VAcG9zdGVsLm9yZzxtYWlsdG86cmJyaWRnZUBwb3N0ZWwub3JnPg0K1vfM4jogUkU6IFty YnJpZGdlXSBDYWxsIGZvciBkcmFmdC10aXNzYS10cmlsbC1jbXQtMDAgdG8gV0cgZHJhZnQNCkhp IE1pbmd1aSwNCg0KV2l0aCBNVCBhcHByb2FjaCwgd2hlbiB0d28gUkJyaWRnZXMgd2hpY2ggaGFk IHN0YXRpb25zIHRhbGtpbmcgdG8gZWFjaCBvdGhlciBhbmQgb25lIG9mIHRoZW0gaXMgY29udmVy dGVkIHRvIE1ULCB0aGVuIHRoZSBjb21tdW5pY2F0aW9uIGlzIGJyb2tlbi4gU28gaXQgZG9lcyBu b3QgaGF2ZSBiYWNrd2FyZCBjb21wdXRhYmlsaXR5Lg0KDQpUaGFua3MNCkphbmENCg0KDQpGcm9t OiBNaW5ndWkgWmhhbmcgW21haWx0bzp6aGFuZ21pbmd1aUBodWF3ZWkuY29tXQ0KU2VudDogRnJp ZGF5LCBNYXJjaCAzMCwgMjAxMiAxMjoyNyBBTQ0KVG86IEphbmFyZGhhbmFuIFBhdGhhbmdpIE5h cmFzaW1oYW4NCkNjOiByYnJpZGdlQHBvc3RlbC5vcmc8bWFpbHRvOnJicmlkZ2VAcG9zdGVsLm9y Zz4NClN1YmplY3Q6ILTwuLQ6IFtyYnJpZGdlXSBDYWxsIGZvciBkcmFmdC10aXNzYS10cmlsbC1j bXQtMDAgdG8gV0cgZHJhZnQNCg0KSGkgSmFuYSwNCg0KTGV0IHVzIGFzc3VtZSB0aGF0IEkgaGF2 ZSAyMCBSQnJpZGdlcyBpbiB0aGUgY2FtcHVzIHdoaWNoIGhhdmUgZW5kIHN5c3RlbXMgY29ubmVj dGVkIHRvIGl0LCBhbmQgYWxsIG9mIHRoZW0gbmVlZCB0byBiZSByZWFjaGFibGUuIFNvIGlmIGEg ZmV3IG9mIHRoZW0gYXJlIGNvbnZlcnRlZCB0byBNVFJBIFJCcmlkZ2VzIHRvIHN1cHBvcnQgYWN0 aXZlLWFjdGl2ZSwgZG9lcyBpdCBtZWFuIHRoYXQgUkJyaWRnZXMgd2hpY2ggYXJlIG5vdCB5ZXQg Y29udmVydGVkIHdpbGwgbm90IGJlIGFibGUgdG8gYW55bW9yZSBzZWUgdGhlIG5vZGVzIGNvbm5l Y3RlZCB0byB0aGVzZSB2aXJ0dWFsIFJCcmlkZ2VzPyBPciBhbSBJIG1pc3Npbmcgc29tZXRoaW5n IGhlcmU/DQoNClpNRz4gQWx0aG91Z2ggcGh5c2ljYWwgcmVhY2hhYmlsaXR5IGNhbiBiZSBhbGwg dG8gYWxsLCBpdCBkb2VzIG5vdCBtZWFuIHRoYW4gdGhlIGVuZCBzeXN0ZW1zIHdpbGwgcmVhbGx5 IGNvbW11bmljYXRlIGluIGFuIGFsbCB0byBhbGwgbWFubmVyLiBJdCBpcyByZXN0cmljdGVkIGJ5 IHRoZSBWTEFOIGNvbmZpZ3VyYXRpb24gb2YgdGhlIGNhbXB1cy4gTGV0IG1lIGdpdmUgeW91IGFu IGV4YW1wbGUsIFJCMSwgUkIyLCBSQjMgYW5kIFJCNCBoYXZlIGFuIGFsbCB0byBhbGwgY29ubmVj dGlvbi4gVGhlIGFjY2VzcyBwb3J0cyBvZiBSQjEgYW5kIFJCMyBhcmUgY29uZmlndXJlZCBhcyB0 aGUgVkxBTiBmb3IgZW5kIHN5c3RlbXMgb2YgdGhlIERlcHQgb2YgQ29tcHV0ZXIgU2NpZW5jZSB3 aGlsZSB0aGUgYWNjZXNzIHBvcnRzIG9mIFJCMiBhbmQgUkI0IGFyZSBjb25maWd1cmVkIGFzIGFu b3RoZXIgVkxBTiBmb3IgZW5kIHN5c3RlbXMgb2YgdGhlIERlcHQgb2YgTGl0ZXJhdHVyZS4gRW5k IHN5c3RlbXMgZnJvbSB0aGUgc2FtZSBkZXBhcnRtZW50IGNhbiB0YWxrIHdpdGggZWFjaCBvdGhl ci4gQnV0IGVuZCBzeXN0ZW1zIGZyb20gdHdvIGRpZmZlcmVudCBkZXBhcnRtZW50cyB3aWxsIG5v dCB0YWxrIHdpdGggZWFjaCBvdGhlci4NCg0KSSBhbSBub3Qgc3VyZSBpZiB0aGF0IGlzIHByYWN0 aWNhbCwgYW5kIGFsd2F5cyBwb3NzaWJsZSBtYXkgZGVwZW5kIG9uIHRoZSBub2RlcyBjb25uZWN0 ZWQgYW5kIGFsc28gd2hhdCBjb250cm9scyBhcmUgYXZhaWxhYmxlIG9uIHRoZW0NCg0KWk1HPiBU aGluayBhYm91dCBpdC4gV2hlbiBhbiBvcGVyYXRvciBoYXZlIGEgTEFHIGNvbm5lY3RlZCB0byBh IGdyb3VwIG9mIFJCcmlkZ2VzLCBoZSBoYXMgdG8gZGVjaWRlIHdoaWNoIHBvcnQgdG8gcGx1ZyB0 aGUgY2FibGVzIGluLiBIZSBuZWVkIGVudGVyIHRoZSBjb25zb2xlIHdpbmRvdyB0byBpbnB1dCB0 aGUgY29tbWFuZCBsaW5lIHRvIGNvbmZpZ3VyZSBwYXJhbWV0ZXJzIGFuZCBzdGFydCB0aGUgTEFH LiBIZSBhbHNvIG5lZWQgdG8gY29uZmlndXJlIHRoZSB0dXBsZSB1c2VkIGZvciBoYXNoaW5nLg0K DQpUaGFua3MsDQpNaW5ndWkNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQq3orz+yMs6IEphbmFyZGhhbmFuIFBhdGhhbmdpIE5hcmFzaW1oYW4gW2phbmFAZm9yY2UxMG5l dHdvcmtzLmNvbV0NCreiy83KsbzkOiAyMDEyxOoz1MIzMMjVIDA6NDkNCrW9OiBNaW5ndWkgWmhh bmcNCkNjOiByYnJpZGdlQHBvc3RlbC5vcmc8bWFpbHRvOnJicmlkZ2VAcG9zdGVsLm9yZz4NCtb3 zOI6IFJFOiBbcmJyaWRnZV0gQ2FsbCBmb3IgZHJhZnQtdGlzc2EtdHJpbGwtY210LTAwIHRvIFdH IGRyYWZ0DQpIaSBNaW5ndWksDQoNCkkgYW0gc2xpZ2h0bHkgY29uZnVzZWQuDQoNCkZvciB0aGUg aW50cmEtdG9wb2xvZ3kgc2NlbmFyaW8sIE1UIHVuYXdhcmUgUkJyaWRnZXMgd2lsbCBub3QgYXBw ZWFyIGluIGEgc3BlY2lmaWMgdG9wb2xvZ3kgb3RoZXIgdGhhbiB0aGUgYmFzZWQgdG9wb2xvZ3ku IEluIG90aGVyIHdvcmRzLCBNVFJBIFJCcmlkZ2VzIG9ubHkgdGFsa3Mgb25seSB3aXRoIE1UUkEg UkJyaWRnZXMuIFNpbmNlIHRoZXkgYWxsIHN1cHBvcnQgTVQsIE1UUkEgY2FuIHdvcmsgdmVyeSB3 ZWxsIGFtb25nIHRoZW0uIEluIHRoaXMgc2NlbmFyaW8sIE1UUkEgUkJyaWRnZXMgYW5kIG9sZCBS QnJpZGdlcyBjby1leGlzdCBpbiB0aGUgc2FtZSBjYW1wdXMuIFRoZXJlZm9yZSwgdGhpcyBpcyBh IHNvbGlkIGV4YW1wbGUgdGhhdCBNVFJBIGNhbiBiZSBkZXBsb3llZCBpbmNyZW1lbnRhbGx5LiBS ZW1lbWJlciwgQ01UIGRvZXMgbm90IGFsbG93IHN1Y2gga2luZCBvZiBkZXBsb3ltZW50Lg0KDQpM ZXQgdXMgYXNzdW1lIHRoYXQgSSBoYXZlIDIwIFJCcmlkZ2VzIGluIHRoZSBjYW1wdXMgd2hpY2gg aGF2ZSBlbmQgc3lzdGVtcyBjb25uZWN0ZWQgdG8gaXQsIGFuZCBhbGwgb2YgdGhlbSBuZWVkIHRv IGJlIHJlYWNoYWJsZS4gU28gaWYgYSBmZXcgb2YgdGhlbSBhcmUgY29udmVydGVkIHRvIE1UUkEg UkJyaWRnZXMgdG8gc3VwcG9ydCBhY3RpdmUtYWN0aXZlLCBkb2VzIGl0IG1lYW4gdGhhdCBSQnJp ZGdlcyB3aGljaCBhcmUgbm90IHlldCBjb252ZXJ0ZWQgd2lsbCBub3QgYmUgYWJsZSB0byBhbnlt b3JlIHNlZSB0aGUgbm9kZXMgY29ubmVjdGVkIHRvIHRoZXNlIHZpcnR1YWwgUkJyaWRnZXM/IE9y IGFtIEkgbWlzc2luZyBzb21ldGhpbmcgaGVyZT8NCg0KRm9yIHRoZSBpbnRlci10b3BvbG9neSBz Y2VuYXJpbywgd2UgYXNzdW1lIE1UUkEgUkJyaWRnZXMgaGF2ZSB0byB0YWxrIHdpdGggTVQgdW5h d2FyZSBSQnJpZGdlcyAoVGhpcyBpcyBhIHJpZ29yb3VzIGFzc3VtcHRpb24uKSBJZiBvcGVyYXRv cnMgZG8gd2FudCB0byByZWFsaXplIHN1Y2gga2luZCBvZiBjb25uZWN0aW9uLCBpdCBpcyByZWFz b25hYmxlIHRvIGFzc3VtZSB0aGV5IHdpbGwgYWNjZXB0IHRoZSByZXF1aXJlbWVudCB0aGF0IHRo ZXkgbmVlZCB0byBjb25maWd1cmUgdGhlaXIgaGFzaGluZyBmdW5jdGlvbiB0byByZW1vdmUgdGhl IHBvc3NpYmxlIE1BQyBmbGlwLWZsb3AuDQoNCkkgYW0gbm90IHN1cmUgaWYgdGhhdCBpcyBwcmFj dGljYWwsIGFuZCBhbHdheXMgcG9zc2libGUgbWF5IGRlcGVuZCBvbiB0aGUgbm9kZXMgY29ubmVj dGVkIGFuZCBhbHNvIHdoYXQgY29udHJvbHMgYXJlIGF2YWlsYWJsZSBvbiB0aGVtDQoNClRoYW5r cw0KSmFuYQ0KDQpUaGFua3MsDQpNaW5ndWkNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQq3orz+yMs6IHJicmlkZ2UtYm91bmNlc0Bwb3N0ZWwub3JnPG1haWx0bzpyYnJpZGdlLWJv dW5jZXNAcG9zdGVsLm9yZz4gW3JicmlkZ2UtYm91bmNlc0Bwb3N0ZWwub3JnXSC0+rHtIE1pbmd1 aSBaaGFuZyBbemhhbmdtaW5ndWlAaHVhd2VpLmNvbV0NCreiy83KsbzkOiAyMDEyxOoz1MIyOcjV IDE4OjUwDQq1vTogSmFuYXJkaGFuYW4gUGF0aGFuZ2kgTmFyYXNpbWhhbg0KQ2M6IHJicmlkZ2VA cG9zdGVsLm9yZzxtYWlsdG86cmJyaWRnZUBwb3N0ZWwub3JnPg0K1vfM4jogtPC4tDogW3Jicmlk Z2VdIENhbGwgZm9yIGRyYWZ0LXRpc3NhLXRyaWxsLWNtdC0wMCB0byBXRyBkcmFmdA0KSGkgSmFu YSwNCg0KPkluIHNlY3Rpb24gNC4xLCBjb3VsZCB5b3UgcGxlYXNlIGV4cGxhaW4gaG93IHRoZSBm cmFtZSB0aGF0IGlzIGluZ3Jlc3NlZCBieSBSQjEgdGhyb3VnaCBSQnYwMDEgaXMgcmVjZWl2ZWQg YXQgUkJ4Pw0KDQpUd28gc2NlbmFyaW9zIGFyZSBnaXZlbiBpbiBTZWN0aW9uIDQuIFNlY3Rpb24g NC4xIHRhbGtzIGFib3V0IHRoZSBpbnRyYS10b3BvbG9neSBzY2VuYXJpby4gSGVyZSwgUkJ4IGlz IG5vdCBpbiB0b3BvbG9neSAxIHNvIGl0IGlzIHVucmVhY2hhYmxlIGJ5IFJCMS4gSXQgbmVlZCBu b3Qgc2V0IHVwIGFueSBmb3J3YXJkaW5nIHBhdGggdG8gUkJ4Lg0KDQpUaGFua3MsDQpNaW5ndWkN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IEphbmFyZGhhbmFuIFBh dGhhbmdpIE5hcmFzaW1oYW4gW2phbmFAZm9yY2UxMG5ldHdvcmtzLmNvbV0NCreiy83KsbzkOiAy MDEyxOoz1MIyOMjVIDIyOjUyDQq1vTogTWluZ3VpIFpoYW5nDQpDYzogcmJyaWRnZUBwb3N0ZWwu b3JnPG1haWx0bzpyYnJpZGdlQHBvc3RlbC5vcmc+DQrW98ziOiBSRTogW3JicmlkZ2VdIENhbGwg Zm9yIGRyYWZ0LXRpc3NhLXRyaWxsLWNtdC0wMCB0byBXRyBkcmFmdA0KSGkgTWluZ3VpLA0KDQpT ZWN0aW9uIDQsIGRvZXMgbm90IGdpdmUgYmFja3dhcmQgY29tcGF0aWJpbGl0eS4gRm9yIGUuZy4g aW4gc2VjdGlvbiA0LjIgbXVsdGkgZGVzdGluYXRpb24gZnJhbWVzIHdpbGwgYmUgaW5ncmVzc2Vk IHdpdGggdHdvIGRpZmZlcmVudCBicmlkZ2UgSUQgY2F1c2luZyBNQUMgbW92ZSwgYW5kIGhhdmlu ZyB0byBpbXBvc2UgcmVzdHJpY3Rpb25zIG9uIGhhc2hpbmcgZnVuY3Rpb25zIGF0IHRoZSBleHRl cm5hbCBub2RlIG1heSBvciBtYXkgbm90IGJlIGFjY2VwdGFibGUgLiBJIGFtIG5vdCBzdXJlIHRo YXQgdGhpcyBjYW4gYmUgY2xhc3NpZmllZCBhcyBiYWNrd2FyZCBjb21wYXRpYmxlIHNpbmNlIGl0 IGlzIG5vdCBhIGZ1bGwgc29sdXRpb24gYW5kIGNhbiBhbHNvIGNhdXNlIGZyZXF1ZW50IE1BQyBm bGlwIGZsb3BzIGV0Yy4NCg0KSW4gc2VjdGlvbiA0LjEsIGNvdWxkIHlvdSBwbGVhc2UgZXhwbGFp biBob3cgdGhlIGZyYW1lIHRoYXQgaXMgaW5ncmVzc2VkIGJ5IFJCMSB0aHJvdWdoIFJCdjAwMSBp cyByZWNlaXZlZCBhdCBSQng/DQoNClRoYW5rcw0KSmFuYQ0KDQoNCkZyb206IE1pbmd1aSBaaGFu ZyBbbWFpbHRvOnpoYW5nbWluZ3VpQGh1YXdlaS5jb21dDQpTZW50OiBXZWRuZXNkYXksIE1hcmNo IDI4LCAyMDEyIDc6MTUgUE0NClRvOiBKYW5hcmRoYW5hbiBQYXRoYW5naSBOYXJhc2ltaGFuDQpD YzogcmJyaWRnZUBwb3N0ZWwub3JnPG1haWx0bzpyYnJpZGdlQHBvc3RlbC5vcmc+DQpTdWJqZWN0 OiC08Li0OiBbcmJyaWRnZV0gQ2FsbCBmb3IgZHJhZnQtdGlzc2EtdHJpbGwtY210LTAwIHRvIFdH IGRyYWZ0DQoNCkhpIEphbmEsDQoNCkkgdGhpbmsgSSBzaG91bGQgYW5zd2VyIHlvdXIgcXVlc3Rp b24uIEkgYW0gTWluZ3VpIFpoYW5nLg0KUGxlYXNlIHJlZmVyIHRvIHRoZSBkcmFmdCBodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy10cmlsbC1tdWx0aS10b3BvLXJwZmMtMDAu IFNlY3Rpb24gNCBpcyByaWdodCBmb3IgdGhlIHRvcGljIHlvdSBhcmUgaW50ZXJlc3RlZC4gQXMg YSBzdGFydGVyIGRyYWZ0IG9uIHRoZSBSUEZDIHVzaW5nIE11bHRpLXRvcG9sb2d5LiBJIHdpbGwg YmUgaGFwcHkgdG8gcmVjZWl2ZSB5b3VyIGNvbW1lbnRzLg0KDQpUaGFua3MsDQpNaW5ndWkNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IEphbmFyZGhhbmFuIFBhdGhh bmdpIE5hcmFzaW1oYW4gW2phbmFAZm9yY2UxMG5ldHdvcmtzLmNvbV0NCreiy83KsbzkOiAyMDEy xOoz1MIyOMjVIDE5OjE0DQq1vTogUm9oaXQgV2F0dmUgKHJ3YXR2ZSk7IE1pbmd1aSBaaGFuZzsg UmFkaWEgUGVybG1hbjsgVGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZpcikNCkNjOiByYnJpZGdl QHBvc3RlbC5vcmc8bWFpbHRvOnJicmlkZ2VAcG9zdGVsLm9yZz4NCtb3zOI6IFJFOiBbcmJyaWRn ZV0gQ2FsbCBmb3IgZHJhZnQtdGlzc2EtdHJpbGwtY210LTAwIHRvIFdHIGRyYWZ0DQpIaSBaaGFp LA0KDQpJbiB0aGUgTXVsdGktdG9wb2xvZ3kgY2FzZSBJIGFtIG5vdCBzdXJlIHdoYXQgaXMgbWVh bnQgYnkgaW5jcmVtZW50YWxseSBkZXBsb3lhYmxlLiBBc3N1bWluZyB0aGF0IGFsbCB0aGUgUkJy aWRnZXMgaW4gdGhlIGNhbXB1cyBkbyBub3QgdW5kZXJzdGFuZCBNVCBleGNlcHQgZm9yIHRoZSBS QnJpZGdlcyB3aGljaCBwYXJ0aWNpcGF0ZSBpbiB0aGUgVmlydHVhbCBSQnJvZGdlLCBpdCBsb29r cyBsaWtlIHRoaXMgd2lsbCBjYXVzZSBNQUMgZmxpcCBmbG9wIG9uIHRoZSBvdGhlciBSQnJpZGdl cyBhbmQgb3RoZXIgaXNzdWVzIHNpbmNlIGFsbCB0aGUgb3RoZXIgUkJyaWRnZXMgZG8gbm90IHVu ZGVyc3RhbmQgTVQuDQoNCkNvdWxkIHlvdSBwbGVhc2UgZXhwbGFpbiBob3cgTVQgY2FuIHdvcmsg aW4gc3VjaCBzY2VuYXJpb3M/DQoNClRoYW5rcw0KSmFuYQ0KDQoNCkZyb206IHJicmlkZ2UtYm91 bmNlc0Bwb3N0ZWwub3JnPG1haWx0bzpyYnJpZGdlLWJvdW5jZXNAcG9zdGVsLm9yZz4gW21haWx0 bzpyYnJpZGdlLWJvdW5jZXNAcG9zdGVsLm9yZ10gT24gQmVoYWxmIE9mIFJvaGl0IFdhdHZlIChy d2F0dmUpDQpTZW50OiBXZWRuZXNkYXksIE1hcmNoIDI4LCAyMDEyIDM6NTMgUE0NClRvOiBNaW5n dWkgWmhhbmc7IFJhZGlhIFBlcmxtYW47IFRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpDQpD YzogcmJyaWRnZUBwb3N0ZWwub3JnPG1haWx0bzpyYnJpZGdlQHBvc3RlbC5vcmc+DQpTdWJqZWN0 OiBSZTogW3JicmlkZ2VdIENhbGwgZm9yIGRyYWZ0LXRpc3NhLXRyaWxsLWNtdC0wMCB0byBXRyBk cmFmdA0KDQoNCkhpIE1pbmd1aSwNCg0KNS4gRmFzdCBjb252ZXJnZW5jZSBvbiBmYWlsdXJlIHJl Y292ZXJ5LiBXZSBrbm93IHRoYXQgcmVzaWxpZW5jZSBpcyBvbmUgb2YgdGhlIHR3byBtYWluIHB1 cnBvc2VzIG9mICJhZ2dyZWdhdGlvbiIuIFRoaXMgZGltZW5zaW9uIGRpc2N1c3NlcyB3aGV0aGVy IHRoZSBzb2x1dGlvbiBvZmZlcnMgYSB3YXkgdG8gZG8gZmFzdCBmYWlsdXJlIHJlY292ZXJ5IHdo ZW4gdGhlcmUgaXMgYSBmYWlsdXJlIG9mIGFuIGFnZ3JlZ2F0ZWQgUkJyaWRnZSBvciBsaW5rLg0K DQpQTjogTk8uIFRoZSBuZXcgZGlzdHJpYnV0aW9uIHRyZWUgbmVlZCB0byBiZSByZWNvbXB1dGVk Lg0KDQpDTVQ6IE5PLiBBIG92ZXJhbGwgcmUtY29uZmlndXJhdGlvbiBpcyBuZWNlc3NhcnkuDQoN Ck1UUkE6IFlFUy4NCg0KQ01UIGRvZXMgbm90IG5lZWQgcmVjb25maWd1cmF0aW9uLiBJZiBvbmUg UmJyaWRnZSBhZHZlcnRpemluZyBhZmZpbml0eSB0bHYgZ29lcyBkb3duLCB0aGUgdHJlZSBjYW4g YmUgcm9vdGVkIGF0IHRoZSBvdGhlciBFZ3Jlc3MgUmJyaWRnZSBJRCBhZHZlcnRpemluZyBhZmZp bml0eSB0bHYuDQoNCkFsc28sIGNvbnNpZGVyIGFkZGluZyBmb2xsb3dpbmcgdG8gdGhlIGNvbXBh cmlzb24gdGFibGUNCg0KTnVtYmVyIG9mIE5ldyBUTFZzIChhbmQgcmVzdWx0aW5nIGNvbXBsZXhp dHkpDQoNClBOOiAzDQoNCkNNVDogMQ0KDQpNVFJBOiBtdWx0aXBsZQ0KDQpUaGFua3MNClJvaGl0 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiByYnJpZGdlLWJvdW5jZXNAcG9z dGVsLm9yZzxtYWlsdG86cmJyaWRnZS1ib3VuY2VzQHBvc3RlbC5vcmc+IFttYWlsdG86cmJyaWRn ZS1ib3VuY2VzQHBvc3RlbC5vcmddIE9uIEJlaGFsZiBPZiBNaW5ndWkgWmhhbmcNClNlbnQ6IFdl ZG5lc2RheSwgTWFyY2ggMjgsIDIwMTIgMjoxMCBBTQ0KVG86IFJhZGlhIFBlcmxtYW47IFRpc3Nh IFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpDQpDYzogcmJyaWRnZUBwb3N0ZWwub3JnPG1haWx0bzpy YnJpZGdlQHBvc3RlbC5vcmc+DQpTdWJqZWN0OiC08Li0OiBbcmJyaWRnZV0gQ2FsbCBmb3IgZHJh ZnQtdGlzc2EtdHJpbGwtY210LTAwIHRvIFdHIGRyYWZ0DQoNCkhpIFJhZGlhLA0KDQpJdCBpcyBh IGdvb2QgaWRlYSB0byBsaXN0IHRoZSBQcm9zIGFuZCBDb25zIG9mIGVhY2ggc29sdXRpb24uIFRo ZXJlIGFyZSB0aHJlZSBjYW5kaWRhdGUgc29sdXRpb25zIGZvciB0aGUgc2FtZSBSUEZDIHByb2Js ZW06IFBOLCBDTVQgYW5kIE1UUkEgKE11bHRpLVRvcG9sb2d5IFRSSUxMIGZvciBSQnJpZGdlIEFn Z3JlZ2F0aW9uKS4gTGV0IG1lIGNvbXBhcmUgdGhlbSBpbiB0aGUgZm9sbG93aW5nIGRpbWVuc2lv bnMuDQoNCjEuIFdoZXRoZXIgdGhlIHNvbHV0aW9uIGlzIGluY3JlbWVudGFsbHkgZGVwbG95LWFi bGUuDQoNClBOOiBZRVMuDQoNCkNNVDogTk8uDQoNCk1UUkE6IFlFUy4NCg0KMi4gVXNlIG9ubHkg ZXhpc3Rpbmcgc2lsaWNvbnMuDQoNClBOOiBOTy4gTmV3IHNpbGljb24gaXMgbmVjZXNzYXJ5IHRv IHN1cHBvcnQgInR1bm5lbGluZyIgb3IgZWxzZSBNQUMgYWRkcmVzc2VzIG1heSBmbGlwLWZsb3Au DQoNCkNNVDogWUVTLg0KDQpNVFJBOiBDdXJyZW50bHkgTk8uIEJ1dCBhZnRlciBtdWx0aS10b3Bv bG9neSBpcyBzdXBwb3J0ZWQgYnkgVFJJTEwsIGl0IGlzIGEgIllFUyIuDQoNCjMuIE11bHRpLWNh c3QgdHJhZmZpYyB1cCBmcm9tIFJCdiBjYW4gYmUgbG9hZC1iYWxhbmNlZC4NCg0KUE46IE5PLg0K DQpDTVQ6IFlFUy4NCg0KTVRSQTogWUVTLg0KDQo0LiBNdWx0aS1jYXN0IHRyYWZmaWMgZG93biB0 byBSQnYgY2FuIGJlIGxvYWQtYmFsYW5jZWQuDQoNClBOOiBOTy4NCg0KQ01UOiBZRVMuDQoNCk1U UkE6IFlFUy4NCg0KNS4gRmFzdCBjb252ZXJnZW5jZSBvbiBmYWlsdXJlIHJlY292ZXJ5LiBXZSBr bm93IHRoYXQgcmVzaWxpZW5jZSBpcyBvbmUgb2YgdGhlIHR3byBtYWluIHB1cnBvc2VzIG9mICJh Z2dyZWdhdGlvbiIuIFRoaXMgZGltZW5zaW9uIGRpc2N1c3NlcyB3aGV0aGVyIHRoZSBzb2x1dGlv biBvZmZlcnMgYSB3YXkgdG8gZG8gZmFzdCBmYWlsdXJlIHJlY292ZXJ5IHdoZW4gdGhlcmUgaXMg YSBmYWlsdXJlIG9mIGFuIGFnZ3JlZ2F0ZWQgUkJyaWRnZSBvciBsaW5rLg0KDQpQTjogTk8uIFRo ZSBuZXcgZGlzdHJpYnV0aW9uIHRyZWUgbmVlZCB0byBiZSByZWNvbXB1dGVkLg0KDQpDTVQ6IE5P LiBBIG92ZXJhbGwgcmUtY29uZmlndXJhdGlvbiBpcyBuZWNlc3NhcnkuDQoNCk1UUkE6IFlFUy4N Cg0KVGhlIGZvbGxvd2luZyB0YWJsZSBsaXN0cyBhbGwgYWJvdmUgY29tcGFyaXNvbnMgKEEganBn IHZlcnNpb24gaXMgYWxzbyBhdHRhY2hlZCBqdXN0IGluIGNhc2UuKS4gTVRSQSBpcyBhbHdheXMg WUVTLiBJIHRoaW5rIGl0IGRlc2VydmVzIG91ciBmb2xsb3ctdXAuDQoNCistLS0tLS0tLSstLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t LSsNCg0KfFNvbHV0aW9ufEluY3JlLURlcGxveXxPbGQgU2lsaWNvbnxMQiBVcHdhcmRzfExCIERv d253YXJkc3xGYXN0IENvbnZlcmdlfA0KDQorLS0tLS0tLS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0t LS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS18DQoNCnxQTiAgICAgIHxZ RVMgICAgICAgICB8Tk8gICAgICAgICB8Tk8gICAgICAgIHxOTyAgICAgICAgICB8Tk8gICAgICAg ICAgIHwNCg0KKy0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tLS0tKy0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tfA0KDQp8Q01UICAgICB8Tk8gICAgICAgICAgfFlFUyAg ICAgICAgfFlFUyAgICAgICB8WUVTICAgICAgICAgfE5PICAgICAgICAgICB8DQoNCistLS0tLS0t LSstLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rLS0tLS0t LS0tLS0tLXwNCg0KfE1UUkEgICAgfFlFUyAgICAgICAgIHxZRVMod2lsbCkgIHxZRVMgICAgICAg fFlFUyAgICAgICAgIHxZRVMgICAgICAgICAgfA0KDQorLS0tLS0tLS0rLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rDQoNClRoYW5r cywNCg0KTWluZ3VpDQoNCg0Kt6K8/sjLOiByYnJpZGdlLWJvdW5jZXNAcG9zdGVsLm9yZzxtYWls dG86cmJyaWRnZS1ib3VuY2VzQHBvc3RlbC5vcmc+IFtyYnJpZGdlLWJvdW5jZXNAcG9zdGVsLm9y Z10gtPqx7SBSYWRpYSBQZXJsbWFuIFtyYWRpYXBlcmxtYW5AZ21haWwuY29tXQ0KDQq3osvNyrG8 5DogMjAxMsTqM9TCMjjI1SAxMjo1Mg0KDQq1vTogVGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZp cikNCg0KQ2M6IHJicmlkZ2VAcG9zdGVsLm9yZzxtYWlsdG86cmJyaWRnZUBwb3N0ZWwub3JnPg0K DQrW98ziOiBSZTogW3JicmlkZ2VdIENhbGwgZm9yIGRyYWZ0LXRpc3NhLXRyaWxsLWNtdC0wMCB0 byBXRyBkcmFmdA0KDQoNCkl0IGlzIG15IHVuZGVyc3RhbmRpbmcgdGhhdA0KDQphKSBDTVQgZG9l cyByZXF1aXJlIGNoYW5naW5nIGFsbCB0aGUgUkJzIGluIHRoZSBjYW1wdXMNCg0KYikgQ01UIHJl cXVpcmVzIHRoZXJlIGJlIGF0IGxlYXN0IGFzIG1hbnkgdHJlZXMgYXMgdGhlcmUgYXJlIGFjdGl2 ZS9hY3RpdmUgUkJzIG9uIGFueSBsaW5rDQoNCg0KDQpPZiBjb3Vyc2UsIG5vIHNvbHV0aW9uIGlz IGlkZWFsLiAgSXQgbWlnaHQgaGF2ZSBiZWVuIG5pY2UgdG8gd3JpdGUgdXAgYWxsIHRoZSBwcm9w b3NlZCBzb2x1dGlvbnMgdG8gdGhpcyBhbmQgcHJvcy9jb25zLiBNYXliZSBpdCdzDQoNCnN0aWxs IHdvcnRoIGRvaW5nLg0KDQoNCg0KU28gZnJvbSBtZW1vcnkuLi5vdGhlciBwcm9wb3NhbHMgZm9y IGFsbG93aW5nIFIxLCBSMiwgYW5kIFIzIHRvIGJlIGFjdGl2ZS9hY3RpdmUvYWN0aXZlIG9uIGEg bGluazoNCg0KDQoNCkZpcnN0IG5vdGU6IHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciB0aGVpciBwb3J0 IHRvIHRoZSBsaW5rIGlzIGluIGEgdHJlZSwgdW5pY2FzdCB3b3JrcywgYW5kIHRoZXkgY2FuIHVz ZSB0aGUgcHNldWRvbm9kZQ0KDQpuaWNrbmFtZSB3aGVuIGVuY2Fwc3VsYXRpbmcgdW5pY2FzdC4N Cg0KDQoNCkFsc28sIGlmIFJpJ3MgcG9ydCB0byB0aGUgbGluayBpcyBpbiBhdCBsZWFzdCBvbmUg dHJlZSwgUmkgY2FuIHVzZSB0aGUgcHNldWRvbm9kZSBuaWNrbmFtZSBmb3IgdGhhdCBsaW5rIHdo ZW4gZW5jYXBzdWxhdGluZw0KDQptdWx0aWRlc3RpbmF0aW9uIGZyYW1lcyBmb3IgaW5ncmVzcywg YW5kIHRoZSBSUEYgY2hlY2sgd2lsbCB3b3JrIHdpdGhvdXQgYW55IHByb2JsZW1zLg0KDQoNCg0K SG93ZXZlciwgaWYgUmkncyBwb3J0IHRvIHRoZSBsaW5rIGlzIG5vdCBpbiBhbnkgb2YgdGhlIHRy ZWVzLA0KDQpoZXJlIHdlcmUgc29tZSBvZiB0aGUgcHJvcG9zZWQgc29sdXRpb25zLiAgU28sIGxl dCdzIHNheSB0aGF0IFIxIGFuZCBSMidzIHBvcnQgdG8gdGhlIHNoYXJlZCBsaW5rIGlzIGluIGF0 IGxlYXN0IG9uZSB0cmVlLCBhbmQgUjMncw0KDQpwb3J0IHRvIHRoZSBsaW5rIGlzIG5vdCBpbiBh bnkgb2YgdGhlIHRyZWVzLCBhbmQgUjMgbmVlZHMgdG8gZW5jYXBzdWxhdGUgYSBtdWx0aWRlc3Rp bmF0aW9uIGZyYW1lOg0KDQoNCg0KMSkgUjMgY291bGQgdHVubmVsIGl0IHRvIG9uZSBvZiB7UjEs IFIyfSwgYW5kIGxldCB0aGVtIGluamVjdCB0aGUgcGFja2V0ICh3aXRoIHBzZXVkb25vZGUgbmlj a25hbWUpIGludG8gdGhlIGNhbXB1cy4NCg0KDQoNClBybzogRG9lc24ndCBhZmZlY3QgYW55IFJC cyBvdGhlciB0aGFuIHRoZSBvbmVzIG9uIHRoZSBsaW5rOyBiYWNrd2FyZHMgY29tcGF0aWJsZS4g IENvbjogbW9yZSBob3BzLCBtaWdodCBiZSBkaWZmaWN1bHQNCg0KaW4gc29tZSBpbXBsZW1lbnRh dGlvbnMgZm9yIFIzIHRvIGZvcndhcmQgYnkgdHVubmVsaW5nLCBtaWdodCBiZSBkaWZmaWN1bHQg Zm9yIFIyIHRvIGFjY2VwdCBhIHR1bm5lbGVkIHBhY2tldC4NCg0KDQoNCjIpIFIzIGNvdWxkIHVz ZSBpdHMgb3duIG5pY2tuYW1lIGluc3RlYWQgb2YgdGhlIHBzZXVkb25vZGUgbmlja25hbWUgaW4g dGhpcyBjYXNlDQoNCg0KDQpQcm86IERvZXNuJ3QgYWZmZWN0IGFueSBSQnMgb3RoZXIgdGhhbiB0 aGUgb25lcyBvbiB0aGUgbGluazsgYmFja3dhcmRzIGNvbXBhdGlibGUuICBDb246IE1BQyBsZWFy bmluZyBpbiBkaXN0YW50IFJCcyB3aWxsIGhhdmUNCg0KZnJlcXVlbnQgbGVhcm5pbmcgY2hhbmdl cyBvZiB0aGUgc291cmNlIE1BQyBTIGJldHdlZW4gYmVpbmcgb24gdGhlIHBzZXVkb25vZGUgbmlj a25hbWUgKHdoZW5ldmVyIFMgc2VuZHMgdW5pY2FzdCwNCg0Kb3IgbXVsdGljYXN0IHRocm91Z2gg UjEgb3IgUjIpLCBvciBiZWluZyBvbiBSMyAod2hlbiBSMyBoYXMgdG8gZW5jYXBzdWxhdGUgYSBt dWx0aWRlc3RpbmF0aW9uIGZyYW1lIGZyb20gUykuDQoNCg0KDQotLS0tLS0NCg0KVGhlcmUgbWln aHQgaGF2ZSBiZWVuIHNvbWUgb3RoZXIgcHJvcG9zYWxzLCBidXQgdGhleSB3b3VuZCB1cCBub3Qg dG8gd29yay4NCg0KDQoNClBlcnNvbmFsbHksIEkgZG9uJ3QgbG92ZSB0aGUgQ01UIHRoaW5nIGJl Y2F1c2Ugb2YgdGhlIHR3byBkaXNhZHZhbnRhZ2VzIEkgbWVudGlvbmVkIGFib3ZlLCBidXQgSSBj YW4gbGl2ZSB3aXRoIGl0Lg0KDQoNCg0KUmFkaWENCg0K --Boundary_(ID_rCIsuDB2dDon3hjJlff68A) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable
Hi Jana,

You offer a detail explanation on how tunneling approach works. I beli= eve the latter case below is not CMT anymore. It's normal TRILL plus tunnel= ing.

"Hence either the entire campus builds trees based on Affinity TL= V or the entire campus builds trees based on normal mechanism and ignore Af= finity TLV."  

This is actually not backward compatability. If you read the FGL draft= , you will know what is backward compatibility. 

Thanks,
Mingui

=B7=A2=BC=FE=C8=CB: Janardhanan Pathangi= Narasimhan [jana@force10networks.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA4=D4=C21=C8=D5 23:50
=B5=BD: Mingui Zhang
Cc: 'rbridge@postel.org'
=D6=F7=CC=E2: RE: =B4=F0=B8=B4: [rbridge] Call for draft-tissa-trill= -cmt-00 to WG draft

Hi Mingui,

 

Please look at section = 4.3. =A1=B0Affinity Sub-TLV Capability=A1=B1 =A8C This is to indicate if an= RBridge can or cannot support Affinity TLV. This capability includes both the ability to set the Affinity TLV and also the capability to act on= it, i.e. calculate trees based on Affinity TLV

 

The backward compatibil= ity operates as follows

 

-          Once the LSP data base is= formed, if all RBridges in the campus support Affinity TLV, than all the R= Bridges in the campus will build the tree based on the Affinity TLV

-          If there is one or more R= Bridges which do not advertise =A1=B0Affinity Capability=A1=B1, than all th= e RBridges in the campus will build the tree based on normal mechanism and will ignore the affinity TLV (including those routers which are capabl= e of understanding this)

 

Hence either the entire= campus builds trees based on Affinity TLV or the entire campus builds tree= s based on normal mechanism and ignore Affinity TLV. There is no situation where the TREES are out of sync between different nodes

 

In terms of tunneling, = the approach is as follows

 

-          When there are some non C= MT nodes, all RBridges build the trees based on the regular mechanism. In t= his situation, let us assume that there are three RBridges R1, R2 and R3 joining to emulate a virtual RBridge RBV. Now since the tree= s formed are based on normal mechanism and not based on Affinity TLV, it is= not guaranteed that all R1, R2 and R3 will have a connectivity to RBV on a= t least one tree.

-          But it is always Guarente= ed that at least one of R1, R2 and R3 will have this connectivity

-          So if for argument sake R= 1 has this connectivity to RBv, then when R2 and R3 get a multi-destination= frame, they cannot ingress that since they cannot set the ingress Nickname as RBv. So they will tunnel it to R1, which will then= ingress it on their behalf into the TRILL campus network, as it has the co= nnectivity to RBv, and can use the ingress nickname of RBV in multi-destina= tion frames without any problems of RPF check failures.

 

Let us know if this is = not clear in the draft, maybe we can add more text to clarify this operatio= n in the next version of the draft if that is the case.

 

And note this tunneling= is only for multi-destination frames and not for unicast frames being ingr= essed by R2 and R3.

 

Thanks

Jana

 

 

From: Mingui= Zhang [mailto:zhangmingui@huawei.com]
Sent: Sunday, April 01, 2012 8:37 PM
To: Janardhanan Pathangi Narasimhan
Cc: 'rbridge@postel.org'
Subject: =B4= =F0=B8=B4: =B4=F0=B8=B4<= span style=3D"font-size:10.0pt; font-family:"Tahoma","sans-s= erif"">: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

 

Hi Jana,

 

Let me use an example to e= xplain. Suppose RB1, RB2 are members of the aggregation. RBr is a remote RB= ridge who support CMT. It may communicate with the aggregation. We assume that the transit RBridge RBt is non CMT. It cannot calculate the= trees as RBr which calculates two trees according to the Affinity TLVs fro= m RB1 and RB2. Then the two trees calculated by RBr are inconsist= ent with those calculated by RBt. Multicast traffic will not be forwarded correctly through RBt.

 

From the above example, yo= u can see that CMT does not allow non CMT RBridge exist in the same campus = because of the inconsistence of distribution tree calculation. When you said that CMT can resort to tunneling. That is to say there is no= n CMT RBridges in the campus. Then we always have to resort to tunneling an= d traditional distribution tree calculation due to the incon= sistence of affinity distribution tree calculation. That is not CMT anymore.

 

Based on above analysis, w= e can conclude that tunneling approach and CMT are mutually  exclusive= .

 

Thanks,

Mingui

 

=B7=A2=BC=FE=C8=CB= : Janardhanan Pathangi Narasimhan [jana@force10networks.com]
=B7= =A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C230=C8=D5 17:58
=B5= =BD: Mingui Zhang
Cc: 'rbridge@postel.org'
=D6= =F7=CC=E2: Re: =B4=F0= =B8=B4: [rbridge] Call for draft-tissa-tri= ll-cmt-00 to WG draft

Hi Mingui

I did not understand yor statement. When non CMT nodes are present all node= s (including CMT nodes) calculate trees as per the base standard. So every = node is pretty much present.

In this situation and with active-active when a RBridge gets multi destinat= ion frame from CE devices and it does not have the virtual RBridge connecte= d in any tree, it tunnels the frame to one of the RBridges that has the VRB= connectivity, which then ingresses this frame.

Let me know if there is any issue with this

Thanks
Jana

From: Mingui Zhang
To: Janardhanan Pathangi Narasimhan
Cc: rbridge@= postel.org
Sent: Fri Mar 30 15:12:59 2012
Subject: =B4=F0=B8=B4: [rbridge] Call for = draft-tissa-trill-cmt-00 to WG draft

Hi Jana,

 

When you say CMT disapp= ears, I am assuming you mean that we will have to do tunneling for all mult= i-destination frames. Much the same as what we would have to do with MT when one non-MT RBridge exists. 

 

ZMG> Not exactly. In CM= T, even you do not need to communicate with non-CMT RBridges, the CMT canno= t be used if non-CMT RBridges exist in the campus. Non-CMT RBridges even cannot appear as transit RBridges. As you know, the trees wi= ll not be calculated according to the affinity TLV by these RBridges. =

 

Thanks,

Mingui

 

=B7=A2=BC=FE=C8=CB= : Janardhanan Pathangi Narasimhan [jana@force10networks.com]
=B7= =A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C230=C8=D5 17:36
=B5= =BD: Mingui Zhang
Cc: rbridge@= postel.org
=D6= =F7=CC=E2: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Mingui,

 

The tunneling is only f= or multi-destination frames and not for unicast frames. Hence not sure what= you are referring to here as tunneling based on egress RBridge.

 

When you say CMT disapp= ears, I am assuming you mean that we will have to do tunneling for all mult= i-destination frames. Much the same as what we would have to do with MT when one non-MT RBridge exists.

 

Thanks

Jana

 

 

From: Mingui Zhang [mailto:zhangmingui@huawei.com]
Sent: Friday, March 30, 2012 1:26 PM
To: Janardhanan Pathangi Narasimhan
Cc: rbridge@= postel.org
Subject: =B4=F0=B8=B4: [rbridge] Call for = draft-tissa-trill-cmt-00 to WG draft

 

Hi Jana,

 

The beauty of MTRA is that= aggregated members can determine themselves whether to use tunneling or no= t according to the egress RBridges. For MT egress RBridges, they need not do tunneling.

 

As long as there is only o= ne old RBridge in the campus, CMT does not work. In order to be backward co= mpatible using tunneling, CMT just simply disappears totally. There is no CMT anymore. 

 

Thanks,

Mingui

=B7=A2=BC=FE=C8=CB= : Janardhanan Pathangi Narasimhan [jana@force10networks.com]
=B7= =A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C230=C8=D5 15:48
=B5= =BD: Mingui Zhang
Cc: rbridge@= postel.org
=D6= =F7=CC=E2: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Minghi,

 

With tunneling all appr= oaches are backward compatible, including CMT.

 

Thanks

Jana

 

 

From: Mingui Zhang [mailto:zhangmingui@huawei.com]
Sent: Friday, March 30, 2012 1:14 PM
To: Janardhanan Pathangi Narasimhan
Cc: rbridge@= postel.org
Subject: =B4=F0=B8=B4: [rbridge] Call for = draft-tissa-trill-cmt-00 to WG draft

 

Hi Jana,

 

Have you forgotten the tun= neling approach? In order to enable the communication between MTRA RBridges= and non-MT RBridges, we can always resort to the tunneling approach to redirect the aggregated traffic to the only parent of RBv on t= he distribution tree of the base topology for delivery. 

 

I did not mention tunnelin= g since I like simple solutions. I think Section 4.2 of my draft did offer = another simpler solution to allow us to enable the communication between MRTA RBridges and non-MT RBridges. I insist on this solution until= operators tell me it is not workable.

 

So, of course MRTA is back= ward compatible. 

 

Thanks,

Mingui

=B7=A2=BC=FE=C8=CB= : Janardhanan Pathangi Narasimhan [jana@force10networks.com]
=B7= =A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C230=C8=D5 15:30
=B5= =BD: Mingui Zhang
Cc: rbridge@= postel.org
=D6= =F7=CC=E2: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Mingui

 

  When you realize= active-active, you are asking for the active-active to be setup in a new t= opology and not the base topology. So these nodes which need to talk to the other nodes which are behind non-MT RBridges cannot do so a= ny more.

 

  Specifically for= MT to be backward compatible, you need all nodes which want to talk to eac= h other part of the base topology. If you do that you cannot realize active-active. If you put the active-active in a new topology, tha= n they can no longer talk to nodes on the base topology of non-MT RBridges.=

 

So yes, MT-TRILL is bac= kward compatible for base topology, but the realization of active-active wi= th MT =A8C TRILL is not backward compatible. That was the point I was bringing up.

 

Thanks

Jana

 

 

From: Mingui Zhang [mailto:zhangmingui@huawei.com]
Sent: Friday, March 30, 2012 12:15 PM
To: Janardhanan Pathangi Narasimhan
Cc: rbridge@= postel.org
Subject: =B4=F0=B8=B4: [rbridge] Call for = draft-tissa-trill-cmt-00 to WG draft

 

Hi Jana,

 

All RBridges in the campus= are in the base topology. MT RBridges can well communicate with non-MT RBr= idges using the base topology. 

 

I feel that you are arguin= g that MT-TRILL is not backward compatible. That is a incorrect judgem= ent.

 

Thanks,

Mingui

=B7=A2=BC=FE=C8=CB= : Janardhanan Pathangi Narasimhan [jana@force10networks.com]
=B7= =A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C230=C8=D5 13:29
=B5= =BD: Mingui Zhang
Cc: rbridge@= postel.org
=D6= =F7=CC=E2: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Mingui,

 

With MT approach, when = two RBridges which had stations talking to each other and one of them is co= nverted to MT, then the communication is broken. So it does not have backward computability.

 

Thanks

Jana

 

 

From: Mingui Zhang [mailto:zhangmingui@huawei.com]
Sent: Friday, March 30, 2012 12:27 AM
To: Janardhanan Pathangi Narasimhan
Cc: rbridge@= postel.org
Subject: =B4=F0=B8=B4: [rbridge] Call for = draft-tissa-trill-cmt-00 to WG draft

 

Hi Jana,

 

Let us assume that I have = 20 RBridges in the campus which have end systems connected to it, and all o= f 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 whic= h 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 Sci= ence while the access ports of RB2 and RB4 are configured as another VLAN for end systems of the Dept of Lite= rature. 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 p= ractical, and always possible may depend on the nodes connected and also wh= at controls are available on them=

 

ZMG> Think about it. Wh= en an operator have a LAG connected to a group of RBridges, he has to decid= e 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

 

 

 

=B7=A2=BC=FE=C8=CB= : Janardhanan Pathangi Narasimhan [jana@force10networks.com]
=B7= =A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C230=C8=D5 0:49
=B5= =BD: Mingui Zhang
Cc: rbridge@= postel.org
=D6= =F7=CC=E2: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Mingui,

 

I am slightly confused.

 

For the intra-topology sce= nario, MT unaware RBridges will not appear in a specific topology other tha= n the based topology. In other words, MTRA RBridges only talks only with MTRA RBridges. Since they all support MT, MTRA can work ve= ry well among them. In this scenario, MTRA RBridges and old RBridges co-exi= st 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 ha= ve 20 RBridges in the campus which have end systems connected to it, and al= l 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 RBr= idges 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 sce= nario, 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 r= equirement that they need to configure their hashing function to remove the= possible MAC flip-flop. 

 

I am not sure if that i= s practical, and always possible may depend on the nodes connected and also= what controls are available on them

 

Thanks

Jana

 

Thanks,

Mingui

=B7=A2=BC=FE=C8=CB= : rbridge-bou= nces@postel.org [rbridge-bounces@postel.org] =B4=FA= =B1=ED Mingui Zhang [zhangmingui@huawei.co= m]
=B7= =A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C229=C8=D5 18:50
=B5= =BD: Janardhanan Pathangi Narasimhan
Cc: rbridge@= postel.org
=D6= =F7=CC=E2: =B4=F0= =B8=B4: [rbridge] Call for draft-tissa-tri= ll-cmt-00 to WG draft

Hi Jana, 

 

>In section 4.1, cou= ld 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.<= /span>

 

Thanks,

Mingui

=B7=A2=BC=FE=C8=CB= : Janardhanan Pathangi Narasimhan [jana@force10networks.com]
=B7= =A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C228=C8=D5 22:52
=B5= =BD: Mingui Zhang
Cc: rbridge@= postel.org
=D6= =F7=CC=E2: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Mingui,

 

Section 4, does not giv= e 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 extern= al node may or may not be acceptable . I am not sure that this can be class= ified as backward compatible since it is not a full solution and can also c= ause frequent MAC flip flops etc.=

 

In section 4.1, could y= ou 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: =B4=F0=B8=B4: [rbridge] Call for = draft-tissa-trill-cmt-00 to WG draft

 

Hi Jana,

 

I think I should answer yo= ur question. I am Mingui Zhang.

Please refer to the draft&= nbsp;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

=B7=A2=BC=FE=C8=CB= : Janardhanan Pathangi Narasimhan [jana@force10networks.com]
=B7= =A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C228=C8=D5 19:14
=B5= =BD: Rohit Watve (rwatve); Mingui Zhang; Radia Perlman; Tissa Senevirathne (tsenevir)=
Cc: rbridge@= postel.org
=D6= =F7=CC=E2: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Zhai,

 

In the Multi-topology c= ase 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 t= his will cause MAC flip flop on the other RBridges and other issues since a= ll the other RBridges do not understand MT.

 

Could you please explai= n how MT can work in such scenarios?


Thanks

Jana

 

 

From: rbridge-bou= nces@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 o= ffers a way to do fast failure recovery when there is a failure of an aggregated RBridge or link.

PN: NO. The new distri= bution tree need to be recomputed.

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

MTRA: YES.

CMT does not need re= configuration. If one Rbridge advertiz= ing affinity tlv goes down, the tree can be root= ed at the other Egress Rbr= idge ID advertizing affinity tlv.=

Also, consider addin= g following to the comparison table

Number of New TLVs (= and resulting complexity)

PN: 3

CMT: 1

MTRA: multiple

Thanks
Rohit

-----Original Message-= ----
From: rbrid= ge-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: =B4=F0=B8=B4: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Radia,

It is a good idea to l= ist 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 RBri= dge Aggregation). Let me compare them in the following dimensions.

1. Whether the solutio= n is incrementally deploy-able.

PN: YES.

CMT: NO.

MTRA: YES.

2. Use only existing s= ilicons.

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

CMT: YES.

MTRA: Currently NO. Bu= t 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 o= ffers a way to do fast failure recovery when there is a failure of an aggregated RBridge or link.

PN: NO. The new distri= bution tree need to be recomputed.

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

MTRA: YES.

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

+--------+----= --------+-----------+----------+------------+-------------&= #43;

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

+--------+----= --------+-----------+----------+------------+-------------|=

|PN   &= nbsp;  |YES         |NO &= nbsp;       |NO     =    |NO          |NO&= nbsp;          |

+--------+----= --------+-----------+----------+------------+-------------|=

|CMT   =   |NO          |YES =        |YES     &nbs= p; |YES         |NO  &nbs= p;        |

+--------+----= --------+-----------+----------+------------+-------------|=

|MTRA   = ; |YES         |YES(will)  |YE= S       |YES     &nb= sp;   |YES          = |

+--------+----= --------+-----------+----------+------------+-------------&= #43;

Thanks,

Mingui

 

=B7=A2= =BC=FE=C8=CB: rbridge-bou= nces@postel.org [rbridge-bounces@postel.org] =B4=FA=B1=ED Radia Perlman [radiaperlman@gmail.com]

=B7=A2= =CB=CD=CA=B1=BC=E4= : 2012=C4=EA3=D4=C228=C8=D5 12:52

=B5=BD: Tiss= a Senevirathne (tsenevir)

Cc: rbridge@postel.org

=D6=F7=CC=E2: Re= : [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

 

It is my understanding= that

a) CMT does require ch= anging all the RBs in the campus<= /p>

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 solut= ions 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 ca= n use the pseudonode

nickname when encapsul= ating unicast.

 

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

multidestination frame= s 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,<= /span>

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<= /span>

port to the link is no= t 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 nicknam= e) into the campus.

 

Pro: Doesn't affect an= y RBs other than the ones on the link; backwards compatible.  Con: mor= e hops, might be difficult

in some implementation= s for R3 to forward by tunneling, might be difficult for R2 to accept a tun= neled packet.

 

2) R3 could use its ow= n nickname instead of the pseudonode nickname in this case

 

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

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

or multicast through R= 1 or R2), or being on R3 (when R3 has to encapsulate a multidestination fra= me from S).

 

------

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

 

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

 

Radia

 

--Boundary_(ID_rCIsuDB2dDon3hjJlff68A)-- --===============0930759284== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge --===============0930759284==-- From rbridge-bounces@postel.org Mon Apr 2 09:25:37 2012 Return-Path: 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 6B80521F86B4 for ; Mon, 2 Apr 2012 09:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.49 X-Spam-Level: ** X-Spam-Status: No, score=2.49 tagged_above=-999 required=5 tests=[AWL=-0.561, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, MIME_HTML_MOSTLY=0.001, 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 KrnsCAUpX1fe for ; Mon, 2 Apr 2012 09:25:34 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2278D21F8680 for ; Mon, 2 Apr 2012 09:25:22 -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 q32FapDa023538; Mon, 2 Apr 2012 08:36:54 -0700 (PDT) Received: from mx.force10networks.com (maa.force10networks.com [59.163.202.254]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q32FZl55023387 for ; Mon, 2 Apr 2012 08:35:57 -0700 (PDT) Received: from EXCH-CLUSTER-11.force10networks.com ([10.16.127.21]) by exch7-maa-fe.force10networks.com ([10.16.126.10]) with mapi; Mon, 2 Apr 2012 21:05:36 +0530 From: Janardhanan Pathangi Narasimhan To: Mingui Zhang Date: Mon, 2 Apr 2012 21:09:30 +0530 Subject: =?gb2312?B?UkU6ILTwuLQ6IFtyYnJpZGdlXSBDYWxsIGZvciBkcmFmdC10aXNzYS10cmls?= =?gb2312?B?bC1jbXQtMDAgdG8gV0cgZHJhZnQ=?= Thread-Topic: =?gb2312?B?tPC4tDogW3JicmlkZ2VdIENhbGwgZm9yIGRyYWZ0LXRpc3NhLXRyaWxsLWM=?= =?gb2312?B?bXQtMDAgdG8gV0cgZHJhZnQ=?= Thread-Index: AQHNC6M4X8TnOZ/31Umc7no1WTsFHJZ9Cj0AgABclICAABKNgIABKjzxgAAYT0D//+PaAIAAy5WsgAAUHfCAABB74IAAKcBDgAASQ3CAAUvIPoAAP81cgAAoPaCAACBD3IAAtGNggAAT3tCAAA2IQIAAAkK2gAADovD///9TQYAAHoYggAAAUQSAAAYzhYADegIOgAAJaYCAAYsMQIAABzHg Message-ID: References: <4552F0907735844E9204A62BBDD325E728CB1F36@SZXEML507-MBS.china.huawei.com> <4552F0907735844E9204A62BBDD325E728CB1FB1@SZXEML507-MBS.china.huawei.com> In-Reply-To: <4552F0907735844E9204A62BBDD325E728CB1FB1@SZXEML507-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: jana@force10networks.com Cc: "'rbridge@postel.org'" X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2069346443==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org --===============2069346443== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_CE35792847FBE84687FF9117132C8EFD471144176AEXCHCLUSTER11_" --_000_CE35792847FBE84687FF9117132C8EFD471144176AEXCHCLUSTER11_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgTWluZ3VpLA0KDQpUaGFua3MgSSB0aGluayB3ZSBhcmUgaW4gYWdyZWVtZW50IHRoYXQgQ01U IHdpbGwgd29yayB3aXRoIGV4aXN0aW5nIFJCcmlkZ2VzIGluIGNvbXBhdGlibGUgbW9kZSwgd2hl dGhlciB3ZSBjYWxsIGl0IKGwQmFja3dhcmQgQ29tcGF0aWJsZaGxIG9yIHNvbWV0aGluZyBlbHNl LCBpcyBmaW5lLg0KDQpUaGFua3MNCkphbmENCg0KDQpGcm9tOiBNaW5ndWkgWmhhbmcgW21haWx0 bzp6aGFuZ21pbmd1aUBodWF3ZWkuY29tXQ0KU2VudDogTW9uZGF5LCBBcHJpbCAwMiwgMjAxMiA4 OjQzIFBNDQpUbzogSmFuYXJkaGFuYW4gUGF0aGFuZ2kgTmFyYXNpbWhhbg0KQ2M6ICdyYnJpZGdl QHBvc3RlbC5vcmcnDQpTdWJqZWN0OiC08Li0OiC08Li0OiBbcmJyaWRnZV0gQ2FsbCBmb3IgZHJh ZnQtdGlzc2EtdHJpbGwtY210LTAwIHRvIFdHIGRyYWZ0DQoNCkhpIEphbmEsDQoNCllvdSBvZmZl ciBhIGRldGFpbCBleHBsYW5hdGlvbiBvbiBob3cgdHVubmVsaW5nIGFwcHJvYWNoIHdvcmtzLiBJ IGJlbGlldmUgdGhlIGxhdHRlciBjYXNlIGJlbG93IGlzIG5vdCBDTVQgYW55bW9yZS4gSXQncyBu b3JtYWwgVFJJTEwgcGx1cyB0dW5uZWxpbmcuDQoNCiJIZW5jZSBlaXRoZXIgdGhlIGVudGlyZSBj YW1wdXMgYnVpbGRzIHRyZWVzIGJhc2VkIG9uIEFmZmluaXR5IFRMViBvciB0aGUgZW50aXJlIGNh bXB1cyBidWlsZHMgdHJlZXMgYmFzZWQgb24gbm9ybWFsIG1lY2hhbmlzbSBhbmQgaWdub3JlIEFm ZmluaXR5IFRMVi4iDQoNClRoaXMgaXMgYWN0dWFsbHkgbm90IGJhY2t3YXJkIGNvbXBhdGFiaWxp dHkuIElmIHlvdSByZWFkIHRoZSBGR0wgZHJhZnQsIHlvdSB3aWxsIGtub3cgd2hhdCBpcyBiYWNr d2FyZCBjb21wYXRpYmlsaXR5Lg0KDQpUaGFua3MsDQpNaW5ndWkNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCreivP7IyzogSmFuYXJkaGFuYW4gUGF0aGFuZ2kgTmFyYXNpbWhh biBbamFuYUBmb3JjZTEwbmV0d29ya3MuY29tXQ0Kt6LLzcqxvOQ6IDIwMTLE6jTUwjHI1SAyMzo1 MA0Ktb06IE1pbmd1aSBaaGFuZw0KQ2M6ICdyYnJpZGdlQHBvc3RlbC5vcmcnDQrW98ziOiBSRTog tPC4tDogW3JicmlkZ2VdIENhbGwgZm9yIGRyYWZ0LXRpc3NhLXRyaWxsLWNtdC0wMCB0byBXRyBk cmFmdA0KSGkgTWluZ3VpLA0KDQpQbGVhc2UgbG9vayBhdCBzZWN0aW9uIDQuMy4gobBBZmZpbml0 eSBTdWItVExWIENhcGFiaWxpdHmhsSCoQyBUaGlzIGlzIHRvIGluZGljYXRlIGlmIGFuIFJCcmlk Z2UgY2FuIG9yIGNhbm5vdCBzdXBwb3J0IEFmZmluaXR5IFRMVi4gVGhpcyBjYXBhYmlsaXR5IGlu Y2x1ZGVzIGJvdGggdGhlIGFiaWxpdHkgdG8gc2V0IHRoZSBBZmZpbml0eSBUTFYgYW5kIGFsc28g dGhlIGNhcGFiaWxpdHkgdG8gYWN0IG9uIGl0LCBpLmUuIGNhbGN1bGF0ZSB0cmVlcyBiYXNlZCBv biBBZmZpbml0eSBUTFYNCg0KVGhlIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgb3BlcmF0ZXMgYXMg Zm9sbG93cw0KDQoNCi0gICAgICAgICAgT25jZSB0aGUgTFNQIGRhdGEgYmFzZSBpcyBmb3JtZWQs IGlmIGFsbCBSQnJpZGdlcyBpbiB0aGUgY2FtcHVzIHN1cHBvcnQgQWZmaW5pdHkgVExWLCB0aGFu IGFsbCB0aGUgUkJyaWRnZXMgaW4gdGhlIGNhbXB1cyB3aWxsIGJ1aWxkIHRoZSB0cmVlIGJhc2Vk IG9uIHRoZSBBZmZpbml0eSBUTFYNCg0KLSAgICAgICAgICBJZiB0aGVyZSBpcyBvbmUgb3IgbW9y ZSBSQnJpZGdlcyB3aGljaCBkbyBub3QgYWR2ZXJ0aXNlIKGwQWZmaW5pdHkgQ2FwYWJpbGl0eaGx LCB0aGFuIGFsbCB0aGUgUkJyaWRnZXMgaW4gdGhlIGNhbXB1cyB3aWxsIGJ1aWxkIHRoZSB0cmVl IGJhc2VkIG9uIG5vcm1hbCBtZWNoYW5pc20gYW5kIHdpbGwgaWdub3JlIHRoZSBhZmZpbml0eSBU TFYgKGluY2x1ZGluZyB0aG9zZSByb3V0ZXJzIHdoaWNoIGFyZSBjYXBhYmxlIG9mIHVuZGVyc3Rh bmRpbmcgdGhpcykNCg0KSGVuY2UgZWl0aGVyIHRoZSBlbnRpcmUgY2FtcHVzIGJ1aWxkcyB0cmVl cyBiYXNlZCBvbiBBZmZpbml0eSBUTFYgb3IgdGhlIGVudGlyZSBjYW1wdXMgYnVpbGRzIHRyZWVz IGJhc2VkIG9uIG5vcm1hbCBtZWNoYW5pc20gYW5kIGlnbm9yZSBBZmZpbml0eSBUTFYuIFRoZXJl IGlzIG5vIHNpdHVhdGlvbiB3aGVyZSB0aGUgVFJFRVMgYXJlIG91dCBvZiBzeW5jIGJldHdlZW4g ZGlmZmVyZW50IG5vZGVzDQoNCkluIHRlcm1zIG9mIHR1bm5lbGluZywgdGhlIGFwcHJvYWNoIGlz IGFzIGZvbGxvd3MNCg0KDQotICAgICAgICAgIFdoZW4gdGhlcmUgYXJlIHNvbWUgbm9uIENNVCBu b2RlcywgYWxsIFJCcmlkZ2VzIGJ1aWxkIHRoZSB0cmVlcyBiYXNlZCBvbiB0aGUgcmVndWxhciBt ZWNoYW5pc20uIEluIHRoaXMgc2l0dWF0aW9uLCBsZXQgdXMgYXNzdW1lIHRoYXQgdGhlcmUgYXJl IHRocmVlIFJCcmlkZ2VzIFIxLCBSMiBhbmQgUjMgam9pbmluZyB0byBlbXVsYXRlIGEgdmlydHVh bCBSQnJpZGdlIFJCVi4gTm93IHNpbmNlIHRoZSB0cmVlcyBmb3JtZWQgYXJlIGJhc2VkIG9uIG5v cm1hbCBtZWNoYW5pc20gYW5kIG5vdCBiYXNlZCBvbiBBZmZpbml0eSBUTFYsIGl0IGlzIG5vdCBn dWFyYW50ZWVkIHRoYXQgYWxsIFIxLCBSMiBhbmQgUjMgd2lsbCBoYXZlIGEgY29ubmVjdGl2aXR5 IHRvIFJCViBvbiBhdCBsZWFzdCBvbmUgdHJlZS4NCg0KLSAgICAgICAgICBCdXQgaXQgaXMgYWx3 YXlzIEd1YXJlbnRlZWQgdGhhdCBhdCBsZWFzdCBvbmUgb2YgUjEsIFIyIGFuZCBSMyB3aWxsIGhh dmUgdGhpcyBjb25uZWN0aXZpdHkNCg0KLSAgICAgICAgICBTbyBpZiBmb3IgYXJndW1lbnQgc2Fr ZSBSMSBoYXMgdGhpcyBjb25uZWN0aXZpdHkgdG8gUkJ2LCB0aGVuIHdoZW4gUjIgYW5kIFIzIGdl dCBhIG11bHRpLWRlc3RpbmF0aW9uIGZyYW1lLCB0aGV5IGNhbm5vdCBpbmdyZXNzIHRoYXQgc2lu Y2UgdGhleSBjYW5ub3Qgc2V0IHRoZSBpbmdyZXNzIE5pY2tuYW1lIGFzIFJCdi4gU28gdGhleSB3 aWxsIHR1bm5lbCBpdCB0byBSMSwgd2hpY2ggd2lsbCB0aGVuIGluZ3Jlc3MgaXQgb24gdGhlaXIg YmVoYWxmIGludG8gdGhlIFRSSUxMIGNhbXB1cyBuZXR3b3JrLCBhcyBpdCBoYXMgdGhlIGNvbm5l Y3Rpdml0eSB0byBSQnYsIGFuZCBjYW4gdXNlIHRoZSBpbmdyZXNzIG5pY2tuYW1lIG9mIFJCViBp biBtdWx0aS1kZXN0aW5hdGlvbiBmcmFtZXMgd2l0aG91dCBhbnkgcHJvYmxlbXMgb2YgUlBGIGNo ZWNrIGZhaWx1cmVzLg0KDQpMZXQgdXMga25vdyBpZiB0aGlzIGlzIG5vdCBjbGVhciBpbiB0aGUg ZHJhZnQsIG1heWJlIHdlIGNhbiBhZGQgbW9yZSB0ZXh0IHRvIGNsYXJpZnkgdGhpcyBvcGVyYXRp b24gaW4gdGhlIG5leHQgdmVyc2lvbiBvZiB0aGUgZHJhZnQgaWYgdGhhdCBpcyB0aGUgY2FzZS4N Cg0KQW5kIG5vdGUgdGhpcyB0dW5uZWxpbmcgaXMgb25seSBmb3IgbXVsdGktZGVzdGluYXRpb24g ZnJhbWVzIGFuZCBub3QgZm9yIHVuaWNhc3QgZnJhbWVzIGJlaW5nIGluZ3Jlc3NlZCBieSBSMiBh bmQgUjMuDQoNClRoYW5rcw0KSmFuYQ0KDQoNCkZyb206IE1pbmd1aSBaaGFuZyBbbWFpbHRvOnpo YW5nbWluZ3VpQGh1YXdlaS5jb21dDQpTZW50OiBTdW5kYXksIEFwcmlsIDAxLCAyMDEyIDg6Mzcg UE0NClRvOiBKYW5hcmRoYW5hbiBQYXRoYW5naSBOYXJhc2ltaGFuDQpDYzogJ3JicmlkZ2VAcG9z dGVsLm9yZycNClN1YmplY3Q6ILTwuLQ6ILTwuLQ6IFtyYnJpZGdlXSBDYWxsIGZvciBkcmFmdC10 aXNzYS10cmlsbC1jbXQtMDAgdG8gV0cgZHJhZnQNCg0KSGkgSmFuYSwNCg0KTGV0IG1lIHVzZSBh biBleGFtcGxlIHRvIGV4cGxhaW4uIFN1cHBvc2UgUkIxLCBSQjIgYXJlIG1lbWJlcnMgb2YgdGhl IGFnZ3JlZ2F0aW9uLiBSQnIgaXMgYSByZW1vdGUgUkJyaWRnZSB3aG8gc3VwcG9ydCBDTVQuIEl0 IG1heSBjb21tdW5pY2F0ZSB3aXRoIHRoZSBhZ2dyZWdhdGlvbi4gV2UgYXNzdW1lIHRoYXQgdGhl IHRyYW5zaXQgUkJyaWRnZSBSQnQgaXMgbm9uIENNVC4gSXQgY2Fubm90IGNhbGN1bGF0ZSB0aGUg dHJlZXMgYXMgUkJyIHdoaWNoIGNhbGN1bGF0ZXMgdHdvIHRyZWVzIGFjY29yZGluZyB0byB0aGUg QWZmaW5pdHkgVExWcyBmcm9tIFJCMSBhbmQgUkIyLiBUaGVuIHRoZSB0d28gdHJlZXMgY2FsY3Vs YXRlZCBieSBSQnIgYXJlIGluY29uc2lzdGVudCB3aXRoIHRob3NlIGNhbGN1bGF0ZWQgYnkgUkJ0 LiBNdWx0aWNhc3QgdHJhZmZpYyB3aWxsIG5vdCBiZSBmb3J3YXJkZWQgY29ycmVjdGx5IHRocm91 Z2ggUkJ0Lg0KDQpGcm9tIHRoZSBhYm92ZSBleGFtcGxlLCB5b3UgY2FuIHNlZSB0aGF0IENNVCBk b2VzIG5vdCBhbGxvdyBub24gQ01UIFJCcmlkZ2UgZXhpc3QgaW4gdGhlIHNhbWUgY2FtcHVzIGJl Y2F1c2Ugb2YgdGhlIGluY29uc2lzdGVuY2Ugb2YgZGlzdHJpYnV0aW9uIHRyZWUgY2FsY3VsYXRp b24uIFdoZW4geW91IHNhaWQgdGhhdCBDTVQgY2FuIHJlc29ydCB0byB0dW5uZWxpbmcuIFRoYXQg aXMgdG8gc2F5IHRoZXJlIGlzIG5vbiBDTVQgUkJyaWRnZXMgaW4gdGhlIGNhbXB1cy4gVGhlbiB3 ZSBhbHdheXMgaGF2ZSB0byByZXNvcnQgdG8gdHVubmVsaW5nIGFuZCB0cmFkaXRpb25hbCBkaXN0 cmlidXRpb24gdHJlZSBjYWxjdWxhdGlvbiBkdWUgdG8gdGhlIGluY29uc2lzdGVuY2Ugb2YgYWZm aW5pdHkgZGlzdHJpYnV0aW9uIHRyZWUgY2FsY3VsYXRpb24uIFRoYXQgaXMgbm90IENNVCBhbnlt b3JlLg0KDQpCYXNlZCBvbiBhYm92ZSBhbmFseXNpcywgd2UgY2FuIGNvbmNsdWRlIHRoYXQgdHVu bmVsaW5nIGFwcHJvYWNoIGFuZCBDTVQgYXJlIG11dHVhbGx5ICBleGNsdXNpdmUuDQoNClRoYW5r cywNCk1pbmd1aQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8/sjLOiBK YW5hcmRoYW5hbiBQYXRoYW5naSBOYXJhc2ltaGFuIFtqYW5hQGZvcmNlMTBuZXR3b3Jrcy5jb21d DQq3osvNyrG85DogMjAxMsTqM9TCMzDI1SAxNzo1OA0Ktb06IE1pbmd1aSBaaGFuZw0KQ2M6ICdy YnJpZGdlQHBvc3RlbC5vcmcnDQrW98ziOiBSZTogtPC4tDogW3JicmlkZ2VdIENhbGwgZm9yIGRy YWZ0LXRpc3NhLXRyaWxsLWNtdC0wMCB0byBXRyBkcmFmdA0KDQpIaSBNaW5ndWkNCg0KSSBkaWQg bm90IHVuZGVyc3RhbmQgeW9yIHN0YXRlbWVudC4gV2hlbiBub24gQ01UIG5vZGVzIGFyZSBwcmVz ZW50IGFsbCBub2RlcyAoaW5jbHVkaW5nIENNVCBub2RlcykgY2FsY3VsYXRlIHRyZWVzIGFzIHBl ciB0aGUgYmFzZSBzdGFuZGFyZC4gU28gZXZlcnkgbm9kZSBpcyBwcmV0dHkgbXVjaCBwcmVzZW50 Lg0KDQpJbiB0aGlzIHNpdHVhdGlvbiBhbmQgd2l0aCBhY3RpdmUtYWN0aXZlIHdoZW4gYSBSQnJp ZGdlIGdldHMgbXVsdGkgZGVzdGluYXRpb24gZnJhbWUgZnJvbSBDRSBkZXZpY2VzIGFuZCBpdCBk b2VzIG5vdCBoYXZlIHRoZSB2aXJ0dWFsIFJCcmlkZ2UgY29ubmVjdGVkIGluIGFueSB0cmVlLCBp dCB0dW5uZWxzIHRoZSBmcmFtZSB0byBvbmUgb2YgdGhlIFJCcmlkZ2VzIHRoYXQgaGFzIHRoZSBW UkIgY29ubmVjdGl2aXR5LCB3aGljaCB0aGVuIGluZ3Jlc3NlcyB0aGlzIGZyYW1lLg0KDQpMZXQg bWUga25vdyBpZiB0aGVyZSBpcyBhbnkgaXNzdWUgd2l0aCB0aGlzDQoNClRoYW5rcw0KSmFuYQ0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogTWluZ3VpIFpoYW5nDQpU bzogSmFuYXJkaGFuYW4gUGF0aGFuZ2kgTmFyYXNpbWhhbg0KQ2M6IHJicmlkZ2VAcG9zdGVsLm9y ZzxtYWlsdG86cmJyaWRnZUBwb3N0ZWwub3JnPg0KU2VudDogRnJpIE1hciAzMCAxNToxMjo1OSAy MDEyDQpTdWJqZWN0OiC08Li0OiBbcmJyaWRnZV0gQ2FsbCBmb3IgZHJhZnQtdGlzc2EtdHJpbGwt Y210LTAwIHRvIFdHIGRyYWZ0DQpIaSBKYW5hLA0KDQpXaGVuIHlvdSBzYXkgQ01UIGRpc2FwcGVh cnMsIEkgYW0gYXNzdW1pbmcgeW91IG1lYW4gdGhhdCB3ZSB3aWxsIGhhdmUgdG8gZG8gdHVubmVs aW5nIGZvciBhbGwgbXVsdGktZGVzdGluYXRpb24gZnJhbWVzLiBNdWNoIHRoZSBzYW1lIGFzIHdo YXQgd2Ugd291bGQgaGF2ZSB0byBkbyB3aXRoIE1UIHdoZW4gb25lIG5vbi1NVCBSQnJpZGdlIGV4 aXN0cy4NCg0KWk1HPiBOb3QgZXhhY3RseS4gSW4gQ01ULCBldmVuIHlvdSBkbyBub3QgbmVlZCB0 byBjb21tdW5pY2F0ZSB3aXRoIG5vbi1DTVQgUkJyaWRnZXMsIHRoZSBDTVQgY2Fubm90IGJlIHVz ZWQgaWYgbm9uLUNNVCBSQnJpZGdlcyBleGlzdCBpbiB0aGUgY2FtcHVzLiBOb24tQ01UIFJCcmlk Z2VzIGV2ZW4gY2Fubm90IGFwcGVhciBhcyB0cmFuc2l0IFJCcmlkZ2VzLiBBcyB5b3Uga25vdywg dGhlIHRyZWVzIHdpbGwgbm90IGJlIGNhbGN1bGF0ZWQgYWNjb3JkaW5nIHRvIHRoZSBhZmZpbml0 eSBUTFYgYnkgdGhlc2UgUkJyaWRnZXMuDQoNClRoYW5rcywNCk1pbmd1aQ0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0Kt6K8/sjLOiBKYW5hcmRoYW5hbiBQYXRoYW5naSBOYXJh c2ltaGFuIFtqYW5hQGZvcmNlMTBuZXR3b3Jrcy5jb21dDQq3osvNyrG85DogMjAxMsTqM9TCMzDI 1SAxNzozNg0Ktb06IE1pbmd1aSBaaGFuZw0KQ2M6IHJicmlkZ2VAcG9zdGVsLm9yZzxtYWlsdG86 cmJyaWRnZUBwb3N0ZWwub3JnPg0K1vfM4jogUkU6IFtyYnJpZGdlXSBDYWxsIGZvciBkcmFmdC10 aXNzYS10cmlsbC1jbXQtMDAgdG8gV0cgZHJhZnQNCkhpIE1pbmd1aSwNCg0KVGhlIHR1bm5lbGlu ZyBpcyBvbmx5IGZvciBtdWx0aS1kZXN0aW5hdGlvbiBmcmFtZXMgYW5kIG5vdCBmb3IgdW5pY2Fz dCBmcmFtZXMuIEhlbmNlIG5vdCBzdXJlIHdoYXQgeW91IGFyZSByZWZlcnJpbmcgdG8gaGVyZSBh cyB0dW5uZWxpbmcgYmFzZWQgb24gZWdyZXNzIFJCcmlkZ2UuDQoNCldoZW4geW91IHNheSBDTVQg ZGlzYXBwZWFycywgSSBhbSBhc3N1bWluZyB5b3UgbWVhbiB0aGF0IHdlIHdpbGwgaGF2ZSB0byBk byB0dW5uZWxpbmcgZm9yIGFsbCBtdWx0aS1kZXN0aW5hdGlvbiBmcmFtZXMuIE11Y2ggdGhlIHNh bWUgYXMgd2hhdCB3ZSB3b3VsZCBoYXZlIHRvIGRvIHdpdGggTVQgd2hlbiBvbmUgbm9uLU1UIFJC cmlkZ2UgZXhpc3RzLg0KDQpUaGFua3MNCkphbmENCg0KDQpGcm9tOiBNaW5ndWkgWmhhbmcgW21h aWx0bzp6aGFuZ21pbmd1aUBodWF3ZWkuY29tXQ0KU2VudDogRnJpZGF5LCBNYXJjaCAzMCwgMjAx MiAxOjI2IFBNDQpUbzogSmFuYXJkaGFuYW4gUGF0aGFuZ2kgTmFyYXNpbWhhbg0KQ2M6IHJicmlk Z2VAcG9zdGVsLm9yZzxtYWlsdG86cmJyaWRnZUBwb3N0ZWwub3JnPg0KU3ViamVjdDogtPC4tDog W3JicmlkZ2VdIENhbGwgZm9yIGRyYWZ0LXRpc3NhLXRyaWxsLWNtdC0wMCB0byBXRyBkcmFmdA0K DQpIaSBKYW5hLA0KDQpUaGUgYmVhdXR5IG9mIE1UUkEgaXMgdGhhdCBhZ2dyZWdhdGVkIG1lbWJl cnMgY2FuIGRldGVybWluZSB0aGVtc2VsdmVzIHdoZXRoZXIgdG8gdXNlIHR1bm5lbGluZyBvciBu b3QgYWNjb3JkaW5nIHRvIHRoZSBlZ3Jlc3MgUkJyaWRnZXMuIEZvciBNVCBlZ3Jlc3MgUkJyaWRn ZXMsIHRoZXkgbmVlZCBub3QgZG8gdHVubmVsaW5nLg0KDQpBcyBsb25nIGFzIHRoZXJlIGlzIG9u bHkgb25lIG9sZCBSQnJpZGdlIGluIHRoZSBjYW1wdXMsIENNVCBkb2VzIG5vdCB3b3JrLiBJbiBv cmRlciB0byBiZSBiYWNrd2FyZCBjb21wYXRpYmxlIHVzaW5nIHR1bm5lbGluZywgQ01UIGp1c3Qg c2ltcGx5IGRpc2FwcGVhcnMgdG90YWxseS4gVGhlcmUgaXMgbm8gQ01UIGFueW1vcmUuDQoNClRo YW5rcywNCk1pbmd1aQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7Iyzog SmFuYXJkaGFuYW4gUGF0aGFuZ2kgTmFyYXNpbWhhbiBbamFuYUBmb3JjZTEwbmV0d29ya3MuY29t XQ0Kt6LLzcqxvOQ6IDIwMTLE6jPUwjMwyNUgMTU6NDgNCrW9OiBNaW5ndWkgWmhhbmcNCkNjOiBy YnJpZGdlQHBvc3RlbC5vcmc8bWFpbHRvOnJicmlkZ2VAcG9zdGVsLm9yZz4NCtb3zOI6IFJFOiBb cmJyaWRnZV0gQ2FsbCBmb3IgZHJhZnQtdGlzc2EtdHJpbGwtY210LTAwIHRvIFdHIGRyYWZ0DQpI aSBNaW5naGksDQoNCldpdGggdHVubmVsaW5nIGFsbCBhcHByb2FjaGVzIGFyZSBiYWNrd2FyZCBj b21wYXRpYmxlLCBpbmNsdWRpbmcgQ01ULg0KDQpUaGFua3MNCkphbmENCg0KDQpGcm9tOiBNaW5n dWkgWmhhbmcgW21haWx0bzp6aGFuZ21pbmd1aUBodWF3ZWkuY29tXQ0KU2VudDogRnJpZGF5LCBN YXJjaCAzMCwgMjAxMiAxOjE0IFBNDQpUbzogSmFuYXJkaGFuYW4gUGF0aGFuZ2kgTmFyYXNpbWhh bg0KQ2M6IHJicmlkZ2VAcG9zdGVsLm9yZzxtYWlsdG86cmJyaWRnZUBwb3N0ZWwub3JnPg0KU3Vi amVjdDogtPC4tDogW3JicmlkZ2VdIENhbGwgZm9yIGRyYWZ0LXRpc3NhLXRyaWxsLWNtdC0wMCB0 byBXRyBkcmFmdA0KDQpIaSBKYW5hLA0KDQpIYXZlIHlvdSBmb3Jnb3R0ZW4gdGhlIHR1bm5lbGlu ZyBhcHByb2FjaD8gSW4gb3JkZXIgdG8gZW5hYmxlIHRoZSBjb21tdW5pY2F0aW9uIGJldHdlZW4g TVRSQSBSQnJpZGdlcyBhbmQgbm9uLU1UIFJCcmlkZ2VzLCB3ZSBjYW4gYWx3YXlzIHJlc29ydCB0 byB0aGUgdHVubmVsaW5nIGFwcHJvYWNoIHRvIHJlZGlyZWN0IHRoZSBhZ2dyZWdhdGVkIHRyYWZm aWMgdG8gdGhlIG9ubHkgcGFyZW50IG9mIFJCdiBvbiB0aGUgZGlzdHJpYnV0aW9uIHRyZWUgb2Yg dGhlIGJhc2UgdG9wb2xvZ3kgZm9yIGRlbGl2ZXJ5Lg0KDQpJIGRpZCBub3QgbWVudGlvbiB0dW5u ZWxpbmcgc2luY2UgSSBsaWtlIHNpbXBsZSBzb2x1dGlvbnMuIEkgdGhpbmsgU2VjdGlvbiA0LjIg b2YgbXkgZHJhZnQgZGlkIG9mZmVyIGFub3RoZXIgc2ltcGxlciBzb2x1dGlvbiB0byBhbGxvdyB1 cyB0byBlbmFibGUgdGhlIGNvbW11bmljYXRpb24gYmV0d2VlbiBNUlRBIFJCcmlkZ2VzIGFuZCBu b24tTVQgUkJyaWRnZXMuIEkgaW5zaXN0IG9uIHRoaXMgc29sdXRpb24gdW50aWwgb3BlcmF0b3Jz IHRlbGwgbWUgaXQgaXMgbm90IHdvcmthYmxlLg0KDQpTbywgb2YgY291cnNlIE1SVEEgaXMgYmFj a3dhcmQgY29tcGF0aWJsZS4NCg0KVGhhbmtzLA0KTWluZ3VpDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0Kt6K8/sjLOiBKYW5hcmRoYW5hbiBQYXRoYW5naSBOYXJhc2ltaGFuIFtq YW5hQGZvcmNlMTBuZXR3b3Jrcy5jb21dDQq3osvNyrG85DogMjAxMsTqM9TCMzDI1SAxNTozMA0K tb06IE1pbmd1aSBaaGFuZw0KQ2M6IHJicmlkZ2VAcG9zdGVsLm9yZzxtYWlsdG86cmJyaWRnZUBw b3N0ZWwub3JnPg0K1vfM4jogUkU6IFtyYnJpZGdlXSBDYWxsIGZvciBkcmFmdC10aXNzYS10cmls bC1jbXQtMDAgdG8gV0cgZHJhZnQNCkhpIE1pbmd1aQ0KDQogIFdoZW4geW91IHJlYWxpemUgYWN0 aXZlLWFjdGl2ZSwgeW91IGFyZSBhc2tpbmcgZm9yIHRoZSBhY3RpdmUtYWN0aXZlIHRvIGJlIHNl dHVwIGluIGEgbmV3IHRvcG9sb2d5IGFuZCBub3QgdGhlIGJhc2UgdG9wb2xvZ3kuIFNvIHRoZXNl IG5vZGVzIHdoaWNoIG5lZWQgdG8gdGFsayB0byB0aGUgb3RoZXIgbm9kZXMgd2hpY2ggYXJlIGJl aGluZCBub24tTVQgUkJyaWRnZXMgY2Fubm90IGRvIHNvIGFueSBtb3JlLg0KDQogIFNwZWNpZmlj YWxseSBmb3IgTVQgdG8gYmUgYmFja3dhcmQgY29tcGF0aWJsZSwgeW91IG5lZWQgYWxsIG5vZGVz IHdoaWNoIHdhbnQgdG8gdGFsayB0byBlYWNoIG90aGVyIHBhcnQgb2YgdGhlIGJhc2UgdG9wb2xv Z3kuIElmIHlvdSBkbyB0aGF0IHlvdSBjYW5ub3QgcmVhbGl6ZSBhY3RpdmUtYWN0aXZlLiBJZiB5 b3UgcHV0IHRoZSBhY3RpdmUtYWN0aXZlIGluIGEgbmV3IHRvcG9sb2d5LCB0aGFuIHRoZXkgY2Fu IG5vIGxvbmdlciB0YWxrIHRvIG5vZGVzIG9uIHRoZSBiYXNlIHRvcG9sb2d5IG9mIG5vbi1NVCBS QnJpZGdlcy4NCg0KU28geWVzLCBNVC1UUklMTCBpcyBiYWNrd2FyZCBjb21wYXRpYmxlIGZvciBi YXNlIHRvcG9sb2d5LCBidXQgdGhlIHJlYWxpemF0aW9uIG9mIGFjdGl2ZS1hY3RpdmUgd2l0aCBN VCCoQyBUUklMTCBpcyBub3QgYmFja3dhcmQgY29tcGF0aWJsZS4gVGhhdCB3YXMgdGhlIHBvaW50 IEkgd2FzIGJyaW5naW5nIHVwLg0KDQpUaGFua3MNCkphbmENCg0KDQpGcm9tOiBNaW5ndWkgWmhh bmcgW21haWx0bzp6aGFuZ21pbmd1aUBodWF3ZWkuY29tXQ0KU2VudDogRnJpZGF5LCBNYXJjaCAz MCwgMjAxMiAxMjoxNSBQTQ0KVG86IEphbmFyZGhhbmFuIFBhdGhhbmdpIE5hcmFzaW1oYW4NCkNj OiByYnJpZGdlQHBvc3RlbC5vcmc8bWFpbHRvOnJicmlkZ2VAcG9zdGVsLm9yZz4NClN1YmplY3Q6 ILTwuLQ6IFtyYnJpZGdlXSBDYWxsIGZvciBkcmFmdC10aXNzYS10cmlsbC1jbXQtMDAgdG8gV0cg ZHJhZnQNCg0KSGkgSmFuYSwNCg0KQWxsIFJCcmlkZ2VzIGluIHRoZSBjYW1wdXMgYXJlIGluIHRo ZSBiYXNlIHRvcG9sb2d5LiBNVCBSQnJpZGdlcyBjYW4gd2VsbCBjb21tdW5pY2F0ZSB3aXRoIG5v bi1NVCBSQnJpZGdlcyB1c2luZyB0aGUgYmFzZSB0b3BvbG9neS4NCg0KSSBmZWVsIHRoYXQgeW91 IGFyZSBhcmd1aW5nIHRoYXQgTVQtVFJJTEwgaXMgbm90IGJhY2t3YXJkIGNvbXBhdGlibGUuIFRo YXQgaXMgYSBpbmNvcnJlY3QganVkZ2VtZW50Lg0KDQpUaGFua3MsDQpNaW5ndWkNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IEphbmFyZGhhbmFuIFBhdGhhbmdpIE5h cmFzaW1oYW4gW2phbmFAZm9yY2UxMG5ldHdvcmtzLmNvbV0NCreiy83KsbzkOiAyMDEyxOoz1MIz MMjVIDEzOjI5DQq1vTogTWluZ3VpIFpoYW5nDQpDYzogcmJyaWRnZUBwb3N0ZWwub3JnPG1haWx0 bzpyYnJpZGdlQHBvc3RlbC5vcmc+DQrW98ziOiBSRTogW3JicmlkZ2VdIENhbGwgZm9yIGRyYWZ0 LXRpc3NhLXRyaWxsLWNtdC0wMCB0byBXRyBkcmFmdA0KSGkgTWluZ3VpLA0KDQpXaXRoIE1UIGFw cHJvYWNoLCB3aGVuIHR3byBSQnJpZGdlcyB3aGljaCBoYWQgc3RhdGlvbnMgdGFsa2luZyB0byBl YWNoIG90aGVyIGFuZCBvbmUgb2YgdGhlbSBpcyBjb252ZXJ0ZWQgdG8gTVQsIHRoZW4gdGhlIGNv bW11bmljYXRpb24gaXMgYnJva2VuLiBTbyBpdCBkb2VzIG5vdCBoYXZlIGJhY2t3YXJkIGNvbXB1 dGFiaWxpdHkuDQoNClRoYW5rcw0KSmFuYQ0KDQoNCkZyb206IE1pbmd1aSBaaGFuZyBbbWFpbHRv OnpoYW5nbWluZ3VpQGh1YXdlaS5jb21dDQpTZW50OiBGcmlkYXksIE1hcmNoIDMwLCAyMDEyIDEy OjI3IEFNDQpUbzogSmFuYXJkaGFuYW4gUGF0aGFuZ2kgTmFyYXNpbWhhbg0KQ2M6IHJicmlkZ2VA cG9zdGVsLm9yZzxtYWlsdG86cmJyaWRnZUBwb3N0ZWwub3JnPg0KU3ViamVjdDogtPC4tDogW3Ji cmlkZ2VdIENhbGwgZm9yIGRyYWZ0LXRpc3NhLXRyaWxsLWNtdC0wMCB0byBXRyBkcmFmdA0KDQpI aSBKYW5hLA0KDQpMZXQgdXMgYXNzdW1lIHRoYXQgSSBoYXZlIDIwIFJCcmlkZ2VzIGluIHRoZSBj YW1wdXMgd2hpY2ggaGF2ZSBlbmQgc3lzdGVtcyBjb25uZWN0ZWQgdG8gaXQsIGFuZCBhbGwgb2Yg dGhlbSBuZWVkIHRvIGJlIHJlYWNoYWJsZS4gU28gaWYgYSBmZXcgb2YgdGhlbSBhcmUgY29udmVy dGVkIHRvIE1UUkEgUkJyaWRnZXMgdG8gc3VwcG9ydCBhY3RpdmUtYWN0aXZlLCBkb2VzIGl0IG1l YW4gdGhhdCBSQnJpZGdlcyB3aGljaCBhcmUgbm90IHlldCBjb252ZXJ0ZWQgd2lsbCBub3QgYmUg YWJsZSB0byBhbnltb3JlIHNlZSB0aGUgbm9kZXMgY29ubmVjdGVkIHRvIHRoZXNlIHZpcnR1YWwg UkJyaWRnZXM/IE9yIGFtIEkgbWlzc2luZyBzb21ldGhpbmcgaGVyZT8NCg0KWk1HPiBBbHRob3Vn aCBwaHlzaWNhbCByZWFjaGFiaWxpdHkgY2FuIGJlIGFsbCB0byBhbGwsIGl0IGRvZXMgbm90IG1l YW4gdGhhbiB0aGUgZW5kIHN5c3RlbXMgd2lsbCByZWFsbHkgY29tbXVuaWNhdGUgaW4gYW4gYWxs IHRvIGFsbCBtYW5uZXIuIEl0IGlzIHJlc3RyaWN0ZWQgYnkgdGhlIFZMQU4gY29uZmlndXJhdGlv biBvZiB0aGUgY2FtcHVzLiBMZXQgbWUgZ2l2ZSB5b3UgYW4gZXhhbXBsZSwgUkIxLCBSQjIsIFJC MyBhbmQgUkI0IGhhdmUgYW4gYWxsIHRvIGFsbCBjb25uZWN0aW9uLiBUaGUgYWNjZXNzIHBvcnRz IG9mIFJCMSBhbmQgUkIzIGFyZSBjb25maWd1cmVkIGFzIHRoZSBWTEFOIGZvciBlbmQgc3lzdGVt cyBvZiB0aGUgRGVwdCBvZiBDb21wdXRlciBTY2llbmNlIHdoaWxlIHRoZSBhY2Nlc3MgcG9ydHMg b2YgUkIyIGFuZCBSQjQgYXJlIGNvbmZpZ3VyZWQgYXMgYW5vdGhlciBWTEFOIGZvciBlbmQgc3lz dGVtcyBvZiB0aGUgRGVwdCBvZiBMaXRlcmF0dXJlLiBFbmQgc3lzdGVtcyBmcm9tIHRoZSBzYW1l IGRlcGFydG1lbnQgY2FuIHRhbGsgd2l0aCBlYWNoIG90aGVyLiBCdXQgZW5kIHN5c3RlbXMgZnJv bSB0d28gZGlmZmVyZW50IGRlcGFydG1lbnRzIHdpbGwgbm90IHRhbGsgd2l0aCBlYWNoIG90aGVy Lg0KDQpJIGFtIG5vdCBzdXJlIGlmIHRoYXQgaXMgcHJhY3RpY2FsLCBhbmQgYWx3YXlzIHBvc3Np YmxlIG1heSBkZXBlbmQgb24gdGhlIG5vZGVzIGNvbm5lY3RlZCBhbmQgYWxzbyB3aGF0IGNvbnRy b2xzIGFyZSBhdmFpbGFibGUgb24gdGhlbQ0KDQpaTUc+IFRoaW5rIGFib3V0IGl0LiBXaGVuIGFu IG9wZXJhdG9yIGhhdmUgYSBMQUcgY29ubmVjdGVkIHRvIGEgZ3JvdXAgb2YgUkJyaWRnZXMsIGhl IGhhcyB0byBkZWNpZGUgd2hpY2ggcG9ydCB0byBwbHVnIHRoZSBjYWJsZXMgaW4uIEhlIG5lZWQg ZW50ZXIgdGhlIGNvbnNvbGUgd2luZG93IHRvIGlucHV0IHRoZSBjb21tYW5kIGxpbmUgdG8gY29u ZmlndXJlIHBhcmFtZXRlcnMgYW5kIHN0YXJ0IHRoZSBMQUcuIEhlIGFsc28gbmVlZCB0byBjb25m aWd1cmUgdGhlIHR1cGxlIHVzZWQgZm9yIGhhc2hpbmcuDQoNClRoYW5rcywNCk1pbmd1aQ0KDQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogSmFuYXJkaGFuYW4g UGF0aGFuZ2kgTmFyYXNpbWhhbiBbamFuYUBmb3JjZTEwbmV0d29ya3MuY29tXQ0Kt6LLzcqxvOQ6 IDIwMTLE6jPUwjMwyNUgMDo0OQ0Ktb06IE1pbmd1aSBaaGFuZw0KQ2M6IHJicmlkZ2VAcG9zdGVs Lm9yZzxtYWlsdG86cmJyaWRnZUBwb3N0ZWwub3JnPg0K1vfM4jogUkU6IFtyYnJpZGdlXSBDYWxs IGZvciBkcmFmdC10aXNzYS10cmlsbC1jbXQtMDAgdG8gV0cgZHJhZnQNCkhpIE1pbmd1aSwNCg0K SSBhbSBzbGlnaHRseSBjb25mdXNlZC4NCg0KRm9yIHRoZSBpbnRyYS10b3BvbG9neSBzY2VuYXJp bywgTVQgdW5hd2FyZSBSQnJpZGdlcyB3aWxsIG5vdCBhcHBlYXIgaW4gYSBzcGVjaWZpYyB0b3Bv bG9neSBvdGhlciB0aGFuIHRoZSBiYXNlZCB0b3BvbG9neS4gSW4gb3RoZXIgd29yZHMsIE1UUkEg UkJyaWRnZXMgb25seSB0YWxrcyBvbmx5IHdpdGggTVRSQSBSQnJpZGdlcy4gU2luY2UgdGhleSBh bGwgc3VwcG9ydCBNVCwgTVRSQSBjYW4gd29yayB2ZXJ5IHdlbGwgYW1vbmcgdGhlbS4gSW4gdGhp cyBzY2VuYXJpbywgTVRSQSBSQnJpZGdlcyBhbmQgb2xkIFJCcmlkZ2VzIGNvLWV4aXN0IGluIHRo ZSBzYW1lIGNhbXB1cy4gVGhlcmVmb3JlLCB0aGlzIGlzIGEgc29saWQgZXhhbXBsZSB0aGF0IE1U UkEgY2FuIGJlIGRlcGxveWVkIGluY3JlbWVudGFsbHkuIFJlbWVtYmVyLCBDTVQgZG9lcyBub3Qg YWxsb3cgc3VjaCBraW5kIG9mIGRlcGxveW1lbnQuDQoNCkxldCB1cyBhc3N1bWUgdGhhdCBJIGhh dmUgMjAgUkJyaWRnZXMgaW4gdGhlIGNhbXB1cyB3aGljaCBoYXZlIGVuZCBzeXN0ZW1zIGNvbm5l Y3RlZCB0byBpdCwgYW5kIGFsbCBvZiB0aGVtIG5lZWQgdG8gYmUgcmVhY2hhYmxlLiBTbyBpZiBh IGZldyBvZiB0aGVtIGFyZSBjb252ZXJ0ZWQgdG8gTVRSQSBSQnJpZGdlcyB0byBzdXBwb3J0IGFj dGl2ZS1hY3RpdmUsIGRvZXMgaXQgbWVhbiB0aGF0IFJCcmlkZ2VzIHdoaWNoIGFyZSBub3QgeWV0 IGNvbnZlcnRlZCB3aWxsIG5vdCBiZSBhYmxlIHRvIGFueW1vcmUgc2VlIHRoZSBub2RlcyBjb25u ZWN0ZWQgdG8gdGhlc2UgdmlydHVhbCBSQnJpZGdlcz8gT3IgYW0gSSBtaXNzaW5nIHNvbWV0aGlu ZyBoZXJlPw0KDQpGb3IgdGhlIGludGVyLXRvcG9sb2d5IHNjZW5hcmlvLCB3ZSBhc3N1bWUgTVRS QSBSQnJpZGdlcyBoYXZlIHRvIHRhbGsgd2l0aCBNVCB1bmF3YXJlIFJCcmlkZ2VzIChUaGlzIGlz IGEgcmlnb3JvdXMgYXNzdW1wdGlvbi4pIElmIG9wZXJhdG9ycyBkbyB3YW50IHRvIHJlYWxpemUg c3VjaCBraW5kIG9mIGNvbm5lY3Rpb24sIGl0IGlzIHJlYXNvbmFibGUgdG8gYXNzdW1lIHRoZXkg d2lsbCBhY2NlcHQgdGhlIHJlcXVpcmVtZW50IHRoYXQgdGhleSBuZWVkIHRvIGNvbmZpZ3VyZSB0 aGVpciBoYXNoaW5nIGZ1bmN0aW9uIHRvIHJlbW92ZSB0aGUgcG9zc2libGUgTUFDIGZsaXAtZmxv cC4NCg0KSSBhbSBub3Qgc3VyZSBpZiB0aGF0IGlzIHByYWN0aWNhbCwgYW5kIGFsd2F5cyBwb3Nz aWJsZSBtYXkgZGVwZW5kIG9uIHRoZSBub2RlcyBjb25uZWN0ZWQgYW5kIGFsc28gd2hhdCBjb250 cm9scyBhcmUgYXZhaWxhYmxlIG9uIHRoZW0NCg0KVGhhbmtzDQpKYW5hDQoNClRoYW5rcywNCk1p bmd1aQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogcmJyaWRnZS1i b3VuY2VzQHBvc3RlbC5vcmc8bWFpbHRvOnJicmlkZ2UtYm91bmNlc0Bwb3N0ZWwub3JnPiBbcmJy aWRnZS1ib3VuY2VzQHBvc3RlbC5vcmddILT6se0gTWluZ3VpIFpoYW5nIFt6aGFuZ21pbmd1aUBo dWF3ZWkuY29tXQ0Kt6LLzcqxvOQ6IDIwMTLE6jPUwjI5yNUgMTg6NTANCrW9OiBKYW5hcmRoYW5h biBQYXRoYW5naSBOYXJhc2ltaGFuDQpDYzogcmJyaWRnZUBwb3N0ZWwub3JnPG1haWx0bzpyYnJp ZGdlQHBvc3RlbC5vcmc+DQrW98ziOiC08Li0OiBbcmJyaWRnZV0gQ2FsbCBmb3IgZHJhZnQtdGlz c2EtdHJpbGwtY210LTAwIHRvIFdHIGRyYWZ0DQpIaSBKYW5hLA0KDQo+SW4gc2VjdGlvbiA0LjEs IGNvdWxkIHlvdSBwbGVhc2UgZXhwbGFpbiBob3cgdGhlIGZyYW1lIHRoYXQgaXMgaW5ncmVzc2Vk IGJ5IFJCMSB0aHJvdWdoIFJCdjAwMSBpcyByZWNlaXZlZCBhdCBSQng/DQoNClR3byBzY2VuYXJp b3MgYXJlIGdpdmVuIGluIFNlY3Rpb24gNC4gU2VjdGlvbiA0LjEgdGFsa3MgYWJvdXQgdGhlIGlu dHJhLXRvcG9sb2d5IHNjZW5hcmlvLiBIZXJlLCBSQnggaXMgbm90IGluIHRvcG9sb2d5IDEgc28g aXQgaXMgdW5yZWFjaGFibGUgYnkgUkIxLiBJdCBuZWVkIG5vdCBzZXQgdXAgYW55IGZvcndhcmRp bmcgcGF0aCB0byBSQnguDQoNClRoYW5rcywNCk1pbmd1aQ0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCreivP7IyzogSmFuYXJkaGFuYW4gUGF0aGFuZ2kgTmFyYXNpbWhhbiBbamFu YUBmb3JjZTEwbmV0d29ya3MuY29tXQ0Kt6LLzcqxvOQ6IDIwMTLE6jPUwjI4yNUgMjI6NTINCrW9 OiBNaW5ndWkgWmhhbmcNCkNjOiByYnJpZGdlQHBvc3RlbC5vcmc8bWFpbHRvOnJicmlkZ2VAcG9z dGVsLm9yZz4NCtb3zOI6IFJFOiBbcmJyaWRnZV0gQ2FsbCBmb3IgZHJhZnQtdGlzc2EtdHJpbGwt Y210LTAwIHRvIFdHIGRyYWZ0DQpIaSBNaW5ndWksDQoNClNlY3Rpb24gNCwgZG9lcyBub3QgZ2l2 ZSBiYWNrd2FyZCBjb21wYXRpYmlsaXR5LiBGb3IgZS5nLiBpbiBzZWN0aW9uIDQuMiBtdWx0aSBk ZXN0aW5hdGlvbiBmcmFtZXMgd2lsbCBiZSBpbmdyZXNzZWQgd2l0aCB0d28gZGlmZmVyZW50IGJy aWRnZSBJRCBjYXVzaW5nIE1BQyBtb3ZlLCBhbmQgaGF2aW5nIHRvIGltcG9zZSByZXN0cmljdGlv bnMgb24gaGFzaGluZyBmdW5jdGlvbnMgYXQgdGhlIGV4dGVybmFsIG5vZGUgbWF5IG9yIG1heSBu b3QgYmUgYWNjZXB0YWJsZSAuIEkgYW0gbm90IHN1cmUgdGhhdCB0aGlzIGNhbiBiZSBjbGFzc2lm aWVkIGFzIGJhY2t3YXJkIGNvbXBhdGlibGUgc2luY2UgaXQgaXMgbm90IGEgZnVsbCBzb2x1dGlv biBhbmQgY2FuIGFsc28gY2F1c2UgZnJlcXVlbnQgTUFDIGZsaXAgZmxvcHMgZXRjLg0KDQpJbiBz ZWN0aW9uIDQuMSwgY291bGQgeW91IHBsZWFzZSBleHBsYWluIGhvdyB0aGUgZnJhbWUgdGhhdCBp cyBpbmdyZXNzZWQgYnkgUkIxIHRocm91Z2ggUkJ2MDAxIGlzIHJlY2VpdmVkIGF0IFJCeD8NCg0K VGhhbmtzDQpKYW5hDQoNCg0KRnJvbTogTWluZ3VpIFpoYW5nIFttYWlsdG86emhhbmdtaW5ndWlA aHVhd2VpLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMjgsIDIwMTIgNzoxNSBQTQ0KVG86 IEphbmFyZGhhbmFuIFBhdGhhbmdpIE5hcmFzaW1oYW4NCkNjOiByYnJpZGdlQHBvc3RlbC5vcmc8 bWFpbHRvOnJicmlkZ2VAcG9zdGVsLm9yZz4NClN1YmplY3Q6ILTwuLQ6IFtyYnJpZGdlXSBDYWxs IGZvciBkcmFmdC10aXNzYS10cmlsbC1jbXQtMDAgdG8gV0cgZHJhZnQNCg0KSGkgSmFuYSwNCg0K SSB0aGluayBJIHNob3VsZCBhbnN3ZXIgeW91ciBxdWVzdGlvbi4gSSBhbSBNaW5ndWkgWmhhbmcu DQpQbGVhc2UgcmVmZXIgdG8gdGhlIGRyYWZ0IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LXpoYW5nLXRyaWxsLW11bHRpLXRvcG8tcnBmYy0wMC4gU2VjdGlvbiA0IGlzIHJpZ2h0IGZv ciB0aGUgdG9waWMgeW91IGFyZSBpbnRlcmVzdGVkLiBBcyBhIHN0YXJ0ZXIgZHJhZnQgb24gdGhl IFJQRkMgdXNpbmcgTXVsdGktdG9wb2xvZ3kuIEkgd2lsbCBiZSBoYXBweSB0byByZWNlaXZlIHlv dXIgY29tbWVudHMuDQoNClRoYW5rcywNCk1pbmd1aQ0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCreivP7IyzogSmFuYXJkaGFuYW4gUGF0aGFuZ2kgTmFyYXNpbWhhbiBbamFuYUBm b3JjZTEwbmV0d29ya3MuY29tXQ0Kt6LLzcqxvOQ6IDIwMTLE6jPUwjI4yNUgMTk6MTQNCrW9OiBS b2hpdCBXYXR2ZSAocndhdHZlKTsgTWluZ3VpIFpoYW5nOyBSYWRpYSBQZXJsbWFuOyBUaXNzYSBT ZW5ldmlyYXRobmUgKHRzZW5ldmlyKQ0KQ2M6IHJicmlkZ2VAcG9zdGVsLm9yZzxtYWlsdG86cmJy aWRnZUBwb3N0ZWwub3JnPg0K1vfM4jogUkU6IFtyYnJpZGdlXSBDYWxsIGZvciBkcmFmdC10aXNz YS10cmlsbC1jbXQtMDAgdG8gV0cgZHJhZnQNCkhpIFpoYWksDQoNCkluIHRoZSBNdWx0aS10b3Bv bG9neSBjYXNlIEkgYW0gbm90IHN1cmUgd2hhdCBpcyBtZWFudCBieSBpbmNyZW1lbnRhbGx5IGRl cGxveWFibGUuIEFzc3VtaW5nIHRoYXQgYWxsIHRoZSBSQnJpZGdlcyBpbiB0aGUgY2FtcHVzIGRv IG5vdCB1bmRlcnN0YW5kIE1UIGV4Y2VwdCBmb3IgdGhlIFJCcmlkZ2VzIHdoaWNoIHBhcnRpY2lw YXRlIGluIHRoZSBWaXJ0dWFsIFJCcm9kZ2UsIGl0IGxvb2tzIGxpa2UgdGhpcyB3aWxsIGNhdXNl IE1BQyBmbGlwIGZsb3Agb24gdGhlIG90aGVyIFJCcmlkZ2VzIGFuZCBvdGhlciBpc3N1ZXMgc2lu Y2UgYWxsIHRoZSBvdGhlciBSQnJpZGdlcyBkbyBub3QgdW5kZXJzdGFuZCBNVC4NCg0KQ291bGQg eW91IHBsZWFzZSBleHBsYWluIGhvdyBNVCBjYW4gd29yayBpbiBzdWNoIHNjZW5hcmlvcz8NCg0K VGhhbmtzDQpKYW5hDQoNCg0KRnJvbTogcmJyaWRnZS1ib3VuY2VzQHBvc3RlbC5vcmc8bWFpbHRv OnJicmlkZ2UtYm91bmNlc0Bwb3N0ZWwub3JnPiBbbWFpbHRvOnJicmlkZ2UtYm91bmNlc0Bwb3N0 ZWwub3JnXSBPbiBCZWhhbGYgT2YgUm9oaXQgV2F0dmUgKHJ3YXR2ZSkNClNlbnQ6IFdlZG5lc2Rh eSwgTWFyY2ggMjgsIDIwMTIgMzo1MyBQTQ0KVG86IE1pbmd1aSBaaGFuZzsgUmFkaWEgUGVybG1h bjsgVGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZpcikNCkNjOiByYnJpZGdlQHBvc3RlbC5vcmc8 bWFpbHRvOnJicmlkZ2VAcG9zdGVsLm9yZz4NClN1YmplY3Q6IFJlOiBbcmJyaWRnZV0gQ2FsbCBm b3IgZHJhZnQtdGlzc2EtdHJpbGwtY210LTAwIHRvIFdHIGRyYWZ0DQoNCg0KSGkgTWluZ3VpLA0K DQo1LiBGYXN0IGNvbnZlcmdlbmNlIG9uIGZhaWx1cmUgcmVjb3ZlcnkuIFdlIGtub3cgdGhhdCBy ZXNpbGllbmNlIGlzIG9uZSBvZiB0aGUgdHdvIG1haW4gcHVycG9zZXMgb2YgImFnZ3JlZ2F0aW9u Ii4gVGhpcyBkaW1lbnNpb24gZGlzY3Vzc2VzIHdoZXRoZXIgdGhlIHNvbHV0aW9uIG9mZmVycyBh IHdheSB0byBkbyBmYXN0IGZhaWx1cmUgcmVjb3Zlcnkgd2hlbiB0aGVyZSBpcyBhIGZhaWx1cmUg b2YgYW4gYWdncmVnYXRlZCBSQnJpZGdlIG9yIGxpbmsuDQoNClBOOiBOTy4gVGhlIG5ldyBkaXN0 cmlidXRpb24gdHJlZSBuZWVkIHRvIGJlIHJlY29tcHV0ZWQuDQoNCkNNVDogTk8uIEEgb3ZlcmFs bCByZS1jb25maWd1cmF0aW9uIGlzIG5lY2Vzc2FyeS4NCg0KTVRSQTogWUVTLg0KDQpDTVQgZG9l cyBub3QgbmVlZCByZWNvbmZpZ3VyYXRpb24uIElmIG9uZSBSYnJpZGdlIGFkdmVydGl6aW5nIGFm ZmluaXR5IHRsdiBnb2VzIGRvd24sIHRoZSB0cmVlIGNhbiBiZSByb290ZWQgYXQgdGhlIG90aGVy IEVncmVzcyBSYnJpZGdlIElEIGFkdmVydGl6aW5nIGFmZmluaXR5IHRsdi4NCg0KQWxzbywgY29u c2lkZXIgYWRkaW5nIGZvbGxvd2luZyB0byB0aGUgY29tcGFyaXNvbiB0YWJsZQ0KDQpOdW1iZXIg b2YgTmV3IFRMVnMgKGFuZCByZXN1bHRpbmcgY29tcGxleGl0eSkNCg0KUE46IDMNCg0KQ01UOiAx DQoNCk1UUkE6IG11bHRpcGxlDQoNClRoYW5rcw0KUm9oaXQNCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IHJicmlkZ2UtYm91bmNlc0Bwb3N0ZWwub3JnPG1haWx0bzpyYnJpZGdl LWJvdW5jZXNAcG9zdGVsLm9yZz4gW21haWx0bzpyYnJpZGdlLWJvdW5jZXNAcG9zdGVsLm9yZ10g T24gQmVoYWxmIE9mIE1pbmd1aSBaaGFuZw0KU2VudDogV2VkbmVzZGF5LCBNYXJjaCAyOCwgMjAx MiAyOjEwIEFNDQpUbzogUmFkaWEgUGVybG1hbjsgVGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZp cikNCkNjOiByYnJpZGdlQHBvc3RlbC5vcmc8bWFpbHRvOnJicmlkZ2VAcG9zdGVsLm9yZz4NClN1 YmplY3Q6ILTwuLQ6IFtyYnJpZGdlXSBDYWxsIGZvciBkcmFmdC10aXNzYS10cmlsbC1jbXQtMDAg dG8gV0cgZHJhZnQNCg0KSGkgUmFkaWEsDQoNCkl0IGlzIGEgZ29vZCBpZGVhIHRvIGxpc3QgdGhl IFByb3MgYW5kIENvbnMgb2YgZWFjaCBzb2x1dGlvbi4gVGhlcmUgYXJlIHRocmVlIGNhbmRpZGF0 ZSBzb2x1dGlvbnMgZm9yIHRoZSBzYW1lIFJQRkMgcHJvYmxlbTogUE4sIENNVCBhbmQgTVRSQSAo TXVsdGktVG9wb2xvZ3kgVFJJTEwgZm9yIFJCcmlkZ2UgQWdncmVnYXRpb24pLiBMZXQgbWUgY29t cGFyZSB0aGVtIGluIHRoZSBmb2xsb3dpbmcgZGltZW5zaW9ucy4NCg0KMS4gV2hldGhlciB0aGUg c29sdXRpb24gaXMgaW5jcmVtZW50YWxseSBkZXBsb3ktYWJsZS4NCg0KUE46IFlFUy4NCg0KQ01U OiBOTy4NCg0KTVRSQTogWUVTLg0KDQoyLiBVc2Ugb25seSBleGlzdGluZyBzaWxpY29ucy4NCg0K UE46IE5PLiBOZXcgc2lsaWNvbiBpcyBuZWNlc3NhcnkgdG8gc3VwcG9ydCAidHVubmVsaW5nIiBv ciBlbHNlIE1BQyBhZGRyZXNzZXMgbWF5IGZsaXAtZmxvcC4NCg0KQ01UOiBZRVMuDQoNCk1UUkE6 IEN1cnJlbnRseSBOTy4gQnV0IGFmdGVyIG11bHRpLXRvcG9sb2d5IGlzIHN1cHBvcnRlZCBieSBU UklMTCwgaXQgaXMgYSAiWUVTIi4NCg0KMy4gTXVsdGktY2FzdCB0cmFmZmljIHVwIGZyb20gUkJ2 IGNhbiBiZSBsb2FkLWJhbGFuY2VkLg0KDQpQTjogTk8uDQoNCkNNVDogWUVTLg0KDQpNVFJBOiBZ RVMuDQoNCjQuIE11bHRpLWNhc3QgdHJhZmZpYyBkb3duIHRvIFJCdiBjYW4gYmUgbG9hZC1iYWxh bmNlZC4NCg0KUE46IE5PLg0KDQpDTVQ6IFlFUy4NCg0KTVRSQTogWUVTLg0KDQo1LiBGYXN0IGNv bnZlcmdlbmNlIG9uIGZhaWx1cmUgcmVjb3ZlcnkuIFdlIGtub3cgdGhhdCByZXNpbGllbmNlIGlz IG9uZSBvZiB0aGUgdHdvIG1haW4gcHVycG9zZXMgb2YgImFnZ3JlZ2F0aW9uIi4gVGhpcyBkaW1l bnNpb24gZGlzY3Vzc2VzIHdoZXRoZXIgdGhlIHNvbHV0aW9uIG9mZmVycyBhIHdheSB0byBkbyBm YXN0IGZhaWx1cmUgcmVjb3Zlcnkgd2hlbiB0aGVyZSBpcyBhIGZhaWx1cmUgb2YgYW4gYWdncmVn YXRlZCBSQnJpZGdlIG9yIGxpbmsuDQoNClBOOiBOTy4gVGhlIG5ldyBkaXN0cmlidXRpb24gdHJl ZSBuZWVkIHRvIGJlIHJlY29tcHV0ZWQuDQoNCkNNVDogTk8uIEEgb3ZlcmFsbCByZS1jb25maWd1 cmF0aW9uIGlzIG5lY2Vzc2FyeS4NCg0KTVRSQTogWUVTLg0KDQpUaGUgZm9sbG93aW5nIHRhYmxl IGxpc3RzIGFsbCBhYm92ZSBjb21wYXJpc29ucyAoQSBqcGcgdmVyc2lvbiBpcyBhbHNvIGF0dGFj aGVkIGp1c3QgaW4gY2FzZS4pLiBNVFJBIGlzIGFsd2F5cyBZRVMuIEkgdGhpbmsgaXQgZGVzZXJ2 ZXMgb3VyIGZvbGxvdy11cC4NCg0KKy0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLSst LS0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKw0KDQp8U29sdXRpb258SW5jcmUt RGVwbG95fE9sZCBTaWxpY29ufExCIFVwd2FyZHN8TEIgRG93bndhcmRzfEZhc3QgQ29udmVyZ2V8 DQoNCistLS0tLS0tLSstLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0rLS0tLS0tLS0tLS0tLXwNCg0KfFBOICAgICAgfFlFUyAgICAgICAgIHxOTyAgICAgICAg IHxOTyAgICAgICAgfE5PICAgICAgICAgIHxOTyAgICAgICAgICAgfA0KDQorLS0tLS0tLS0rLS0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t LS18DQoNCnxDTVQgICAgIHxOTyAgICAgICAgICB8WUVTICAgICAgICB8WUVTICAgICAgIHxZRVMg ICAgICAgICB8Tk8gICAgICAgICAgIHwNCg0KKy0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLSstLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tfA0KDQp8TVRSQSAgICB8 WUVTICAgICAgICAgfFlFUyh3aWxsKSAgfFlFUyAgICAgICB8WUVTICAgICAgICAgfFlFUyAgICAg ICAgICB8DQoNCistLS0tLS0tLSstLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tLSst LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLSsNCg0KVGhhbmtzLA0KDQpNaW5ndWkNCg0KDQq3orz+ yMs6IHJicmlkZ2UtYm91bmNlc0Bwb3N0ZWwub3JnPG1haWx0bzpyYnJpZGdlLWJvdW5jZXNAcG9z dGVsLm9yZz4gW3JicmlkZ2UtYm91bmNlc0Bwb3N0ZWwub3JnXSC0+rHtIFJhZGlhIFBlcmxtYW4g W3JhZGlhcGVybG1hbkBnbWFpbC5jb21dDQoNCreiy83KsbzkOiAyMDEyxOoz1MIyOMjVIDEyOjUy DQoNCrW9OiBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKQ0KDQpDYzogcmJyaWRnZUBwb3N0 ZWwub3JnPG1haWx0bzpyYnJpZGdlQHBvc3RlbC5vcmc+DQoNCtb3zOI6IFJlOiBbcmJyaWRnZV0g Q2FsbCBmb3IgZHJhZnQtdGlzc2EtdHJpbGwtY210LTAwIHRvIFdHIGRyYWZ0DQoNCg0KSXQgaXMg bXkgdW5kZXJzdGFuZGluZyB0aGF0DQoNCmEpIENNVCBkb2VzIHJlcXVpcmUgY2hhbmdpbmcgYWxs IHRoZSBSQnMgaW4gdGhlIGNhbXB1cw0KDQpiKSBDTVQgcmVxdWlyZXMgdGhlcmUgYmUgYXQgbGVh c3QgYXMgbWFueSB0cmVlcyBhcyB0aGVyZSBhcmUgYWN0aXZlL2FjdGl2ZSBSQnMgb24gYW55IGxp bmsNCg0KDQoNCk9mIGNvdXJzZSwgbm8gc29sdXRpb24gaXMgaWRlYWwuICBJdCBtaWdodCBoYXZl IGJlZW4gbmljZSB0byB3cml0ZSB1cCBhbGwgdGhlIHByb3Bvc2VkIHNvbHV0aW9ucyB0byB0aGlz IGFuZCBwcm9zL2NvbnMuIE1heWJlIGl0J3MNCg0Kc3RpbGwgd29ydGggZG9pbmcuDQoNCg0KDQpT byBmcm9tIG1lbW9yeS4uLm90aGVyIHByb3Bvc2FscyBmb3IgYWxsb3dpbmcgUjEsIFIyLCBhbmQg UjMgdG8gYmUgYWN0aXZlL2FjdGl2ZS9hY3RpdmUgb24gYSBsaW5rOg0KDQoNCg0KRmlyc3Qgbm90 ZTogcmVnYXJkbGVzcyBvZiB3aGV0aGVyIHRoZWlyIHBvcnQgdG8gdGhlIGxpbmsgaXMgaW4gYSB0 cmVlLCB1bmljYXN0IHdvcmtzLCBhbmQgdGhleSBjYW4gdXNlIHRoZSBwc2V1ZG9ub2RlDQoNCm5p Y2tuYW1lIHdoZW4gZW5jYXBzdWxhdGluZyB1bmljYXN0Lg0KDQoNCg0KQWxzbywgaWYgUmkncyBw b3J0IHRvIHRoZSBsaW5rIGlzIGluIGF0IGxlYXN0IG9uZSB0cmVlLCBSaSBjYW4gdXNlIHRoZSBw c2V1ZG9ub2RlIG5pY2tuYW1lIGZvciB0aGF0IGxpbmsgd2hlbiBlbmNhcHN1bGF0aW5nDQoNCm11 bHRpZGVzdGluYXRpb24gZnJhbWVzIGZvciBpbmdyZXNzLCBhbmQgdGhlIFJQRiBjaGVjayB3aWxs IHdvcmsgd2l0aG91dCBhbnkgcHJvYmxlbXMuDQoNCg0KDQpIb3dldmVyLCBpZiBSaSdzIHBvcnQg dG8gdGhlIGxpbmsgaXMgbm90IGluIGFueSBvZiB0aGUgdHJlZXMsDQoNCmhlcmUgd2VyZSBzb21l IG9mIHRoZSBwcm9wb3NlZCBzb2x1dGlvbnMuICBTbywgbGV0J3Mgc2F5IHRoYXQgUjEgYW5kIFIy J3MgcG9ydCB0byB0aGUgc2hhcmVkIGxpbmsgaXMgaW4gYXQgbGVhc3Qgb25lIHRyZWUsIGFuZCBS MydzDQoNCnBvcnQgdG8gdGhlIGxpbmsgaXMgbm90IGluIGFueSBvZiB0aGUgdHJlZXMsIGFuZCBS MyBuZWVkcyB0byBlbmNhcHN1bGF0ZSBhIG11bHRpZGVzdGluYXRpb24gZnJhbWU6DQoNCg0KDQox KSBSMyBjb3VsZCB0dW5uZWwgaXQgdG8gb25lIG9mIHtSMSwgUjJ9LCBhbmQgbGV0IHRoZW0gaW5q ZWN0IHRoZSBwYWNrZXQgKHdpdGggcHNldWRvbm9kZSBuaWNrbmFtZSkgaW50byB0aGUgY2FtcHVz Lg0KDQoNCg0KUHJvOiBEb2Vzbid0IGFmZmVjdCBhbnkgUkJzIG90aGVyIHRoYW4gdGhlIG9uZXMg b24gdGhlIGxpbms7IGJhY2t3YXJkcyBjb21wYXRpYmxlLiAgQ29uOiBtb3JlIGhvcHMsIG1pZ2h0 IGJlIGRpZmZpY3VsdA0KDQppbiBzb21lIGltcGxlbWVudGF0aW9ucyBmb3IgUjMgdG8gZm9yd2Fy ZCBieSB0dW5uZWxpbmcsIG1pZ2h0IGJlIGRpZmZpY3VsdCBmb3IgUjIgdG8gYWNjZXB0IGEgdHVu bmVsZWQgcGFja2V0Lg0KDQoNCg0KMikgUjMgY291bGQgdXNlIGl0cyBvd24gbmlja25hbWUgaW5z dGVhZCBvZiB0aGUgcHNldWRvbm9kZSBuaWNrbmFtZSBpbiB0aGlzIGNhc2UNCg0KDQoNClBybzog RG9lc24ndCBhZmZlY3QgYW55IFJCcyBvdGhlciB0aGFuIHRoZSBvbmVzIG9uIHRoZSBsaW5rOyBi YWNrd2FyZHMgY29tcGF0aWJsZS4gIENvbjogTUFDIGxlYXJuaW5nIGluIGRpc3RhbnQgUkJzIHdp bGwgaGF2ZQ0KDQpmcmVxdWVudCBsZWFybmluZyBjaGFuZ2VzIG9mIHRoZSBzb3VyY2UgTUFDIFMg YmV0d2VlbiBiZWluZyBvbiB0aGUgcHNldWRvbm9kZSBuaWNrbmFtZSAod2hlbmV2ZXIgUyBzZW5k cyB1bmljYXN0LA0KDQpvciBtdWx0aWNhc3QgdGhyb3VnaCBSMSBvciBSMiksIG9yIGJlaW5nIG9u IFIzICh3aGVuIFIzIGhhcyB0byBlbmNhcHN1bGF0ZSBhIG11bHRpZGVzdGluYXRpb24gZnJhbWUg ZnJvbSBTKS4NCg0KDQoNCi0tLS0tLQ0KDQpUaGVyZSBtaWdodCBoYXZlIGJlZW4gc29tZSBvdGhl ciBwcm9wb3NhbHMsIGJ1dCB0aGV5IHdvdW5kIHVwIG5vdCB0byB3b3JrLg0KDQoNCg0KUGVyc29u YWxseSwgSSBkb24ndCBsb3ZlIHRoZSBDTVQgdGhpbmcgYmVjYXVzZSBvZiB0aGUgdHdvIGRpc2Fk dmFudGFnZXMgSSBtZW50aW9uZWQgYWJvdmUsIGJ1dCBJIGNhbiBsaXZlIHdpdGggaXQuDQoNCg0K DQpSYWRpYQ0KDQo= --_000_CE35792847FBE84687FF9117132C8EFD471144176AEXCHCLUSTER11_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Mingui= ,

 =

Thanks I think we are in agreement that CM= T will work with existing RBridges in compatible mode, whether we call it = =A1=B0Backward Compatible=A1=B1 or something else, is fine.

 

Thanks

Jana=

 <= /p>

 

<= p class=3DMsoNormal>From: Mingui Zhang [mailto:zhangmingui@huawei.com]
Sent: Monday, April 02, 2012 8:43 PM
To: Janardhanan Pathang= i Narasimhan
Cc: 'rbridge@postel.org'
Subject: <= span lang=3DZH-CN style=3D'font-size:10.0pt'>=B4=F0=B8=B4: =B4=F0=B8=B4: [rbridge] Call for draft-t= issa-trill-cmt-00 to WG draft

 

Hi Jana,

 

You offer a detail explanation= on how tunneling approach works. I believe the latter case below is not CM= T anymore. It's normal TRILL plus tunneling.

 

"Hence either the entire campus builds trees based on= Affinity TLV or the entire campus builds trees based on normal mechanism a= nd ignore Affinity TLV."  

 

This is actually not backward compatability. If you read the FGL dr= aft, you will know what is backward compatibility. <= /p>

 

Thanks,

Mingui

 

=B7= =A2=BC=FE=C8=CB: Janardhanan Pathangi Nara= simhan [jana@force10networks.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA4=D4=C21=C8=D5 23:50
=B5=BD: Mingui Zhang
Cc: 'rbridge@postel.org'
=D6=F7=CC=E2: RE: =B4=F0=B8=B4: [rbridge] Call for draft-tissa= -trill-cmt-00 to WG draft

Hi Mingui,

 =

Please look at section 4.= 3. =A1=B0Affinity Sub-TLV Capability=A1=B1 =A8C This is to indicate if an R= Bridge can or cannot support Affinity TLV. This capability includes both th= e ability to set the Affinity TLV and also the capability to act on it, i.e= . calculate trees based on Affinity TLV<= o:p>

 

The back= ward compatibility operates as follows

 

-     &nb= sp;    Once the LSP data base is formed, if al= l RBridges in the campus support Affinity TLV, than all the RBridges in the= campus will build the tree based on the Affinity TLV

-     &nbs= p;    If there is one or more RBridges which d= o not advertise =A1=B0Affinity Capability=A1=B1, than all the RBridges in t= he campus will build the tree based on normal mechanism and will ignore the= affinity TLV (including those routers which are capable of understanding t= his)

 

Hence either the entire campus builds trees b= ased on Affinity TLV or the entire campus builds trees based on normal mech= anism and ignore Affinity TLV. There is no situation where the TREES are ou= t of sync between different nodes

 

In terms of tunn= eling, the approach is as follows

 

-      &n= bsp;   When there are some non CMT nodes, all RBrid= ges build the trees based on the regular mechanism. In this situation, let = us assume that there are three RBridges R1, R2 and R3 joining to emulate a = virtual RBridge RBV. Now since the trees formed are based on normal mechani= sm and not based on Affinity TLV, it is not guaranteed that all R1, R2 and = R3 will have a connectivity to RBV on at least one tree.

-     =      But it is always Guarenteed that at = least one of R1, R2 and R3 will have this connectivity

-     =      So if for argument sake R1 has this = connectivity to RBv, then when R2 and R3 get a multi-destination frame, the= y cannot ingress that since they cannot set the ingress Nickname as RBv. So= they will tunnel it to R1, which will then ingress it on their behalf into= the TRILL campus network, as it has the connectivity to RBv, and can use t= he ingress nickname of RBV in multi-destination frames without any problems= of RPF check failures.

 <= o:p>

Let us know if this is not= clear in the draft, maybe we can add more text to clarify this operation i= n the next version of the draft if that is the case.

 =

And note this tunneling is only for multi-destination frames and not for= unicast frames being ingressed by R2 and R3.

 

Than= ks

Jana

 

 

Fro= m: Mingui Zhang [m= ailto:zhangmingui@huawei.com]
Sent: Sunday, April 01, 2012 8= :37 PM
To: Janardhanan Pathangi Narasimhan
Cc: 'rbridge= @postel.org'
Subject: =B4=F0=B8=B4: =B4=F0=B8=B4: [rbridge] Cal= l for draft-tissa-trill-cmt-00 to WG draft

 

Hi= Jana,

<= p class=3DMsoNormal> 

Let me use an example to ex= plain. Suppose RB1, RB2 are members of the aggregation. RBr is a remote RBr= idge who support CMT. It may communicate with the aggregation. We assume th= at the transit RBridge RBt is non CMT. It cannot calculate the trees as RBr= which calculates two trees according to the Affinity TLVs from RB1 and RB2= . Then the two trees calculated by RBr are inconsistent with thos= e calculated by RBt. Multicast traffic will not be forwarded correctly thro= ugh RBt.

 

From the above example, y= ou can see that CMT does not allow non CMT RBridge exist in the same campus= because of the inconsistence of distribution tree calculation. W= hen you said that CMT can resort to tunneling. That is to say there is non = CMT RBridges in the campus. Then we always have to resort to tunneling and = traditional distribution tree calculation due to the inconsi= stence of affinity distribution tree calculation. That is not CMT anym= ore.

 <= /span>

Based on above analysis, we c= an conclude that tunneling approach and CMT are mutually  exclusive.

 

Thanks,

Mingui<= /span>

 

=B7=A2=BC=FE=C8=CB: Janardhanan Pathangi Narasimhan [jana@force10networks.com= ]
= =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C2<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:blac= k'>30=C8= =D5 17:58
=B5=BD: Mingui Zhang
<= b>Cc: 'rbridge@postel.org'
=D6=F7=CC=E2: R= e: =B4=F0= =B8=B4: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft<= /span>

Hi = Mingui

I did not understand yor statement. When non CMT nodes are pr= esent all nodes (including CMT nodes) calculate trees as per the base stand= ard. So every node is pretty much present.

In this situation and wit= h active-active when a RBridge gets multi destination frame from CE devices= and it does not have the virtual RBridge connected in any tree, it tunnels= the frame to one of the RBridges that has the VRB connectivity, which then= ingresses this frame.

Let me know if there is any issue with this
Thanks
Jana

From: Mingui Zhang
To: Janardhanan Pathangi Narasimhan <= br>Cc: rbrid= ge@postel.org
Sent: Fri Mar 30 15:12:59 2012
Subject: =B4=F0= =B8=B4: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft =

Hi Jana, <= /p>

 <= o:p>

When you say CM= T disappears, I am assuming you mean that we will have to do tunneling for = all multi-destination frames. Much the same as what we would have to do wit= h MT when one non-MT RBridge exists. 

&nbs= p;

ZMG> Not exactly. In CMT, even you do not need to co= mmunicate with non-CMT RBridges, the CMT cannot be used if non-CMT RBridges= exist in the campus. Non-CMT RBridges even cannot appear as transit RBridg= es. As you know, the trees will not be calculated according to the affinity= TLV by these RBridges. =

 

Than= ks,

Mingui <= /span>

 

<= span lang=3DZH-CN style=3D'font-size:10.0pt;color:black'>=B7=A2=BC=FE=C8=CB= : Janardhanan Pathangi Narasimhan [jana@fo= rce10networks.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2= 012=C4=EA<= /span>3=D4=C230=C8=D5 17:36
=B5=BD: Ming= ui Zhang
Cc: rbridge@postel.org
=D6=F7=CC=E2: RE: [= rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Mingui,

 

The tunneling is only for multi-de= stination frames and not for unicast frames. Hence not sure what you are re= ferring to here as tunneling based on egress RBridge.

 

When you say CMT disappears, I am assuming you mean that we will have t= o do tunneling for all multi-destination frames. Much the same as what we w= ould have to do with MT when one non-MT RBridge exists.

 

Thanks

Jana<= /span>

 

 

From: Mingui Zhang [mailto:zhangmingui@huawei.com]
Sent= : Friday, March 30, 2012 1:26 PM
To: Janardhanan Pathangi Nar= asimhan
Cc: rbridge@postel.org
Subject: =B4=F0=B8=B4: [rbridge] Call = for draft-tissa-trill-cmt-00 to WG draft=

 

Hi J= ana,

 <= /span>

The beauty of MTRA is that ag= gregated members can determine themselves whether to use tunneling or not a= ccording to the egress RBridges. For MT egress RBridges, they need not do t= unneling.

 

As long as there is only= one old RBridge in the campus, CMT does not work. In order to be backward = compatible using tunneling, CMT just simply disappears totally. There is no= CMT anymore. 

 

Thanks,=

Mingui

<= div>

=B7=A2=BC=FE=C8=CB: Janardhanan Pathangi Narasimhan [jana@force10networks.com]
=B7=A2=CB= =CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C230=C8=D5<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:blac= k'> 15:48
=B5=BD: Mingui Zhang
Cc: <= a href=3D"mailto:rbridge@postel.org" target=3D"_blank">rbridge@postel.org
= =D6=F7=CC=E2: RE: [rbridge] Call for draft= -tissa-trill-cmt-00 to WG draft

Hi Minghi,<= span style=3D'color:black'>

 

With tunneling all approaches are backward compatible, = including CMT.

 

Thanks

Jana

&nbs= p;

 

=

From: Mingui Zhang= [mailto:zhangm= ingui@huawei.com]
Sent: Friday, March 30, 2012 1:14 PM
To: Janardhanan Pathangi Narasimhan
Cc: rbridge@postel.org
Subject: =B4=F0= =B8=B4: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft<= /span>

 

=

Hi Jana, <= /o:p>

 

Have = you forgotten the tunneling approach? In order to enable the communication = between MTRA RBridges and non-MT RBridges, we can always resort to the tunn= eling approach to redirect the aggregated traffic to the only parent of RBv= on the distribution tree of the base topology for delivery. 

 

I did not mention tunneling since I like s= imple solutions. I think Section 4.2 of my draft did offer another simpler = solution to allow us to enable the communication between MRTA RBridges and = non-MT RBridges. I insist on this solution until operators tell me it is no= t workable.

<= div>

 =

So, of course MRTA is = backward compatible. 

 

Thanks,=

Mingui

=B7=A2=BC=FE=C8=CB: Janardhanan Pathangi Narasimhan [jana@force10networks.com]
= =B7=A2= =CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C230= =C8=D5 15:30
=B5=BD: Mingui Zhang
Cc: rbridge@postel.o= rg
=D6=F7=CC=E2: RE: [rbridge] Call for dr= aft-tissa-trill-cmt-00 to WG draft<= /o:p>

Hi Mingui

 

  When you realize active-active, you are asking f= or the active-active to be setup in a new topology and not the base topolog= y. So these nodes which need to talk to the other nodes which are behind no= n-MT RBridges cannot do so any more.

 

  Speci= fically for MT to be backward compatible, you need all nodes which want to = talk to each other part of the base topology. If you do that you cannot rea= lize active-active. If you put the active-active in a new topology, than th= ey can no longer talk to nodes on the base topology of non-MT RBridges.

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 

So yes, MT-TRILL is backward compatible for base topo= logy, but the realization of active-active with MT =A8C TRILL is not backwa= rd compatible. That was the point I was bringing up.

 =

Thanks

Jana

 =

 

<= b>From: Mingui Zhang [mailto:zhangmingui@huawei.com]
Sent: Friday, March 30, 2012 12:15 PM
To: Janardhanan Pathangi Naras= imhan
Cc: rbridge@postel.org
Subject: =B4=F0=B8=B4: [rbridge] Call f= or draft-tissa-trill-cmt-00 to WG draft<= o:p>

 

Hi Jana, <= /span>

 

<= /div>

All RBridges in the campus are in the ba= se topology. MT RBridges can well communicate with non-MT RBridges using th= e base topology. =

 

I feel that= you are arguing that MT-TRILL is not backward compatible. That is a i= ncorrect judgement.

 

Thanks,

Mingui

=B7=A2=BC=FE=C8=CB: Janardhanan Pathangi Narasimhan [jana@force10networks.com]
=B7=A2=CB= =CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C230=C8=D5<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:blac= k'> 13:29
=B5=BD: Mingui Zhang
Cc: <= a href=3D"mailto:rbridge@postel.org" target=3D"_blank">rbridge@postel.org
= =D6=F7=CC=E2: RE: [rbridge] Call for draft= -tissa-trill-cmt-00 to WG draft

Hi Mingui,<= span style=3D'color:black'>

 

With MT approach, when two RBridges which had stations = talking to each other and one of them is converted to MT, then the communic= ation is broken. So it does not have backward computability.

&nbs= p;

Thanks

=

Jana

 

 

From: Mingui Zhang [mailto:zhangmingui@huawei.com]
= Sent: Friday, March 30, 2012 12:27 AM
To: Janardhanan Pathang= i Narasimhan
Cc: rbridge@postel.org
Subject: =B4=F0=B8=B4: [rbridge] = Call for draft-tissa-trill-cmt-00 to WG draft

 

Hi J= ana,

 

Let us assume that I have 20 = RBridges in the campus which have end systems connected to it, and all of t= hem need to be reachable. So if a few of them are converted to MTRA RBridge= s to support active-active, does it mean that RBridges which are not yet co= nverted will not be able to anymore see the nodes connected to these virtua= l RBridges? Or am I missing something here?

 <= span style=3D'color:black'>

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 man= ner. 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 ac= cess 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 configu= red 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 alwa= ys possible may depend on the nodes connected and also what controls are av= ailable on them

 <= o:p>

ZMG> Think abou= t 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 windo= w to input the command line to configure parameters and start the LAG. He a= lso need to configure the tuple used for hashing.

 <= /span>

Thanks,

Mingui

 <= /span>

 

 

=B7=A2=BC= =FE=C8=CB: Janardhanan Pathangi Narasimhan= [jana@force10networks.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C230=C8=D5 0:49
=B5=BD: Mingui Zhang
Cc: rbridge@postel.org
=D6=F7=CC=E2: 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 b= ased topology. In other words, MTRA RBridges only talks only with MTRA RBri= dges. Since they all support MT, MTRA can work very well among them. In thi= s scenario, MTRA RBridges and old RBridges co-exist in the same campus. The= refore, this is a solid example that MTRA can be deployed incrementally. Re= member, CMT does not allow such kind of deployment.

 <= span style=3D'color:black'>

Let us assume that I have 20 RBridges in the campus which have end system= s connected to it, and all of them need to be reachable. So if a few of the= m are converted to MTRA RBridges to support active-active, does it mean tha= t 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?<= /span>

 

For the inter-topology scenario, w= e assume MTRA RBridges have to talk with MT unaware RBridges (This is a rig= orous 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.&= nbsp;

 

I am not sure if that is practical= , and always possible may depend on the nodes connected and also what contr= ols are available on them

 

Thanks

Jana

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 

=

Thanks,

Mingui

=B7= =A2=BC=FE=C8=CB: rbridge-bounces@postel.org [rbri= dge-bounces@postel.org] =B4=FA=B1=ED Mingui Zhang [zhangmingui@huawei.com]=
=B7= =A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C229=C8=D5<= /span> 18:50
=B5=BD: Janardhanan Pathangi = Narasimhan
Cc: rbridge@postel.org
=D6=F7=CC=E2: =B4=F0=B8=B4<= /span>: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft<= span style=3D'color:black'>

Hi Jana, 

 

>= In section 4.1, could you please explain how the frame that is ingressed by= RB1 through RBv001 is received at RBx? 

=  

<= p class=3DMsoNormal>Two scenarios are given in Section 4. Section 4.1 t= alks about the intra-topology scenario. Here, RBx is not in topology 1 so i= t is unreachable by RB1. It need not set up any forwarding path to RBx.

 

Thanks,

Mingui

=B7=A2=BC=FE=C8=CB: Janardhanan Patha= ngi Narasimhan [jana@force10networks.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C228=C8=D5 22:52
=B5=BD<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:blac= k'>: Mingui Zhang
Cc: rbridge@postel.org
=D6=F7=CC=E2<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:blac= k'>: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG d= raft

Hi Mingui,=

 

Section = 4, does not give backward compatibility. For e.g. in section 4.2 multi dest= ination frames will be ingressed with two different bridge ID causing MAC m= ove, 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 classif= ied as backward compatible since it is not a full solution and can also cau= se frequent MAC flip flops etc.

 

In section 4.1, co= uld you please explain how the frame that is ingressed by RB1 through RBv00= 1 is received at RBx? =

 

Thanks

Jana=

 

 

From: Ming= ui Zhang [mailt= o:zhangmingui@huawei.com]
Sent: Wednesday, March 28, 2012 7:= 15 PM
To: Janardhanan Pathangi Narasimhan
Cc: rbridge@postel.org
= Subject: =B4=F0=B8=B4: [rbridge] Call for draft-tissa-trill-cmt-00 = to WG draft

<= /div>

 

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 t= he topic you are interested. As a starter draft on the RPFC using Multi-top= ology. I will be happy to receive your comments.

&nbs= p;

Thanks,

Mingui

<= /span>

= =B7=A2=BC=FE=C8=CB: Janardhanan Pathangi N= arasimhan [jana@force10networks.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C228=C8=D5 19:14
=B5=BD:<= /span> Rohit Watve (rwatve); Mingui Zhang; Radia Perlman; Tissa Sen= evirathne (tsenevir)
Cc: rbridge@postel.org
=D6=F7=CC=E2: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Zhai,

 

In the Multi-topology ca= se I am not sure what is meant by incrementally deployable. Assuming that a= ll 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 RBrid= ges do not understand MT.

 

Could you please explain= how MT can work in such scenarios?=


Thanks

Jana

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 

 <= /span>

From: rbridge-bounc= es@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Rohit Wa= tve (rwatve)
Sent: Wednesday, March 28, 2012 3:53 PM
To: Mingui Zhang; Radia Perlman; Tissa Senevirathne (tsenevir)
Cc: = rbridge@postel.org<= /a>
Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to W= G draft

 <= /p>

Hi Mingui,

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

PN: NO. The new distribution tree need to be re= computed.

CMT: NO. A overall re-configurat= ion is necessary.

<= p>MTRA: YES.

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

Also, consider adding following to the comp= arison table

Number of New TLVs (and res= ulting complexity)

=

PN: 3

CMT: 1

MTRA: multiple<= /p>

Thanks
Rohit

-----Original Message-----
From: rbridge-bounces@poste= l.org [= mailto:rbridge-bounces@postel.org] On Behalf Of Mingui Zhang
Sent: W= ednesday, March 28, 2012 2:10 AM
To: Radia Perlman; Tissa Senevirathne (= tsenevir)
Cc: rb= ridge@postel.org
Subject: = =B4=F0=B8=B4: [rbridge] Call for draft-tissa-trill-cmt-0= 0 to WG draft

Hi Radia,

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

1. Whether t= he solution is incrementally deploy-able.

= PN: YES.

CMT: NO.

MTRA: YES.

2. Use only existing s= ilicons.

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

CMT: YES.

MTR= A: Currently NO. But after multi-topology is supported by TRILL, it is a &q= uot;YES".

<= span style=3D'font-family:Consolas;color:black'>3. Multi-cast traffic up fr= om RBv can be load-balanced.<= /span>

PN: NO.

CMT: YES.

MTRA= : YES.

4. Multi-cast traffic down to RBv c= an 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&= quot;. This dimension discusses whether the solution offers a way to do fas= t failure recovery when there is a failure of an aggregated RBridge or link= .

PN: NO. The new distribution tree nee= d to be recomputed.

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

MTRA: YES.

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

+--------= +------------+-----------+----------+------------+-------------+

|Solution|Incre-Deploy|Old Silicon|LB Upwards|LB Dow= nwards|Fast Converge|<= /p>

+--------+----------= --+-----------+----------+------------+-------------|

|PN      |YES    &= nbsp;    |NO        = |NO        |NO    &= nbsp;     |NO       =     |

+--------+-----------= -+-----------+----------+------------+-------------|

|CMT     |NO     &n= bsp;    |YES        |YES&= nbsp;      |YES      = ;   |NO         &nbs= p; |

+--------+------------+-----------+--= --------+------------+-------------|

|MTRA=     |YES         |YE= S(will)  |YES       |YES  &nbs= p;      |YES      &n= bsp;   |

=

+--------+------------+= -----------+----------+------------+-------------+

Thanks,

Mingui

 

= =B7=A2=BC=FE= =C8=CB: rbridge-bounces@postel= .org [rbridge-bounces@postel.org] =B4= =FA=B1=ED Radia Per= lman [radiaperlman@gmail.com]=

= =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C2<= /span>28=C8=D5 12:52

=B5=BD: Tissa Senevirathne (tsenevir)

= Cc: rbridge@postel.= org

=D6=F7=CC=E2: Re: [rbridge] Call for draft-t= issa-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 the= re are active/active RBs on any link

 = ;

Of course, no solution is ideal.  I= t might have been nice to write up all the proposed solutions to this and p= ros/cons. Maybe it's

still worth doing.

 

So f= rom memory...other proposals for allowing R1, R2, and R3 to be active/activ= e/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=

multidestina= tion frames for ingress, and the RPF check will work without any problems.<= /span>

 <= o:p>

Ho= wever, 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 tun= nel 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 b= y tunneling, might be difficult for R2 to accept a tunneled packet.<= span style=3D'color:black'>

 

2) R3 cou= ld 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 compatibl= e.  Con: MAC learning in distant RBs will have

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

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

&= nbsp;

------

There might have been some other proposals, but they wound up not to wo= rk.

 

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

 

Radia

 

<= /div>
<= /div>
= --_000_CE35792847FBE84687FF9117132C8EFD471144176AEXCHCLUSTER11_-- --===============2069346443== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge --===============2069346443==-- From rbridge-bounces@postel.org Mon Apr 2 11:24:47 2012 Return-Path: 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 82D9021F862B for ; Mon, 2 Apr 2012 11:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.475 X-Spam-Level: X-Spam-Status: No, score=-0.475 tagged_above=-999 required=5 tests=[AWL=-1.772, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, MIME_HTML_MOSTLY=0.001, 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 r5+SWipJK8Iu for ; Mon, 2 Apr 2012 11:24:43 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8C521F8599 for ; Mon, 2 Apr 2012 11:24:43 -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 q32I9AO9018778; Mon, 2 Apr 2012 11:09:13 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q32I8Okf018398 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 2 Apr 2012 11:08:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tsenevir@cisco.com; l=130127; q=dns/txt; s=iport; t=1333390112; x=1334599712; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=mWXKOZqnr4N7icLXzBQCJGSl1/RPaw6l1Mh5e/wREbk=; b=nHKSbw+KoIYMyHKoQN904hhPQ0BG+JVR20QlLbzLTWNTg/yduAjj9/Ac WPKSGgGGdVBGDjPjWrH+PLk0UPrftbyllDW4r1WsfdC0FyT4Z9TD6dRNB hohi0sBN3Cq03DcmdM6/1IK1bQwz/AKc8FEwqinK6Xnx62nDAjAXkFz1P A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIFAHfqeU+rRDoI/2dsb2JhbABFgkaDAak1AYh+gQeCCQEBAQQSAQcBAQEQAzUIDAwEAgEGAhEEAQELBhABBgEEAgEgJQYDCAIEARIIEweHZgELm1GNAgiSBIoWhTw5YwSIWI4aiiKDFIFogwc X-IronPort-AV: E=Sophos;i="4.75,358,1330905600"; d="scan'208,217";a="36140339" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 02 Apr 2012 18:08:23 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q32I8Nug018160; Mon, 2 Apr 2012 18:08:23 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Apr 2012 11:08:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: =?gb2312?B?UkU6ILTwuLQ6IFtyYnJpZGdlXSBDYWxsIGZvciBkcmFmdC10aXNzYQ==?= =?gb2312?B?LXRyaWxsLWNtdC0wMCB0byBXRyBkcmFmdA==?= Date: Mon, 2 Apr 2012 11:08:21 -0700 Message-ID: <344037D7CFEFE84E97E9CC1F56C5F4A5E3AD99@xmb-sjc-214.amer.cisco.com> In-Reply-To: <4552F0907735844E9204A62BBDD325E728CB1FB1@SZXEML507-MBS.china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: =?gb2312?B?tPC4tDogW3JicmlkZ2VdIENhbGwgZm9yIGRyYWZ0LXRpc3NhLXRyaWxsLWM=?= =?gb2312?B?bXQtMDAgdG8gV0cgZHJhZnQ=?= Thread-Index: AQHNC6M4X8TnOZ/31Umc7no1WTsFHJZ9Cj0AgABclICAABKNgIABKjzxgAAYT0D//+PaAIAAy5WsgAAUHfCAABB74IAAKcBDgAASQ3CAAUvIPoAAP81cgAAoPaCAACBD3IAAtGNggAAT3tCAAA2IQIAAAkK2gAADovD///9TQYAAHoYggAAAUQSAAAYzhYADegIOgAAJaYCAAYsMQIAAMMEQ References: <4552F0907735844E9204A62BBDD325E728CB1F36@SZXEML507-MBS.china.huawei.com> <4552F0907735844E9204A62BBDD325E728CB1FB1@SZXEML507-MBS.china.huawei.com> From: "Tissa Senevirathne (tsenevir)" To: "Mingui Zhang" , "Janardhanan Pathangi Narasimhan" X-OriginalArrivalTime: 02 Apr 2012 18:08:22.0969 (UTC) FILETIME=[9796CA90:01CD10FB] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: tsenevir@cisco.com Cc: rbridge@postel.org X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1080870884==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org This is a multi-part message in MIME format. --===============1080870884== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD10FB.97590BB2" This is a multi-part message in MIME format. ------_=_NextPart_001_01CD10FB.97590BB2 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Mingui =20 Since you are so empathetic about backward compatibility of control = plane, could you please let me know based on your estimates how many = RBridges out there in production networks ? So we can attach a priority = to the backward compatibility. =20 =20 From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On = Behalf Of Mingui Zhang Sent: Monday, April 02, 2012 8:13 AM To: Janardhanan Pathangi Narasimhan Cc: 'rbridge@postel.org' Subject: =B4=F0=B8=B4: =B4=F0=B8=B4: [rbridge] Call for = draft-tissa-trill-cmt-00 to WG draft =20 Hi Jana, =20 You offer a detail explanation on how tunneling approach works. I = believe the latter case below is not CMT anymore. It's normal TRILL plus = tunneling. =20 "Hence either the entire campus builds trees based on Affinity TLV or = the entire campus builds trees based on normal mechanism and ignore = Affinity TLV." =20 =20 This is actually not backward compatability. If you read the FGL draft, = you will know what is backward compatibility.=20 =20 Thanks, Mingui =20 ________________________________ =B7=A2=BC=FE=C8=CB: Janardhanan Pathangi Narasimhan = [jana@force10networks.com] =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA4=D4=C21=C8=D5 23:50 =B5=BD: Mingui Zhang Cc: 'rbridge@postel.org' =D6=F7=CC=E2: RE: =B4=F0=B8=B4: [rbridge] Call for = draft-tissa-trill-cmt-00 to WG draft Hi Mingui, =20 Please look at section 4.3. =A1=B0Affinity Sub-TLV Capability=A1=B1 =A8C = This is to indicate if an RBridge can or cannot support Affinity TLV. = This capability includes both the ability to set the Affinity TLV and = also the capability to act on it, i.e. calculate trees based on Affinity = TLV =20 The backward compatibility operates as follows =20 - Once the LSP data base is formed, if all RBridges in the = campus support Affinity TLV, than all the RBridges in the campus will = build the tree based on the Affinity TLV - If there is one or more RBridges which do not advertise = =A1=B0Affinity Capability=A1=B1, than all the RBridges in the campus = will build the tree based on normal mechanism and will ignore the = affinity TLV (including those routers which are capable of understanding = this) =20 Hence either the entire campus builds trees based on Affinity TLV or the = entire campus builds trees based on normal mechanism and ignore Affinity = TLV. There is no situation where the TREES are out of sync between = different nodes =20 In terms of tunneling, the approach is as follows =20 - When there are some non CMT nodes, all RBridges build the = trees based on the regular mechanism. In this situation, let us assume = that there are three RBridges R1, R2 and R3 joining to emulate a virtual = RBridge RBV. Now since the trees formed are based on normal mechanism = and not based on Affinity TLV, it is not guaranteed that all R1, R2 and = R3 will have a connectivity to RBV on at least one tree. - But it is always Guarenteed that at least one of R1, R2 and = R3 will have this connectivity=20 - So if for argument sake R1 has this connectivity to RBv, then = when R2 and R3 get a multi-destination frame, they cannot ingress that = since they cannot set the ingress Nickname as RBv. So they will tunnel = it to R1, which will then ingress it on their behalf into the TRILL = campus network, as it has the connectivity to RBv, and can use the = ingress nickname of RBV in multi-destination frames without any problems = of RPF check failures. =20 Let us know if this is not clear in the draft, maybe we can add more = text to clarify this operation in the next version of the draft if that = is the case. =20 And note this tunneling is only for multi-destination frames and not for = unicast frames being ingressed by R2 and R3. =20 Thanks Jana =20 =20 From: Mingui Zhang [mailto:zhangmingui@huawei.com]=20 Sent: Sunday, April 01, 2012 8:37 PM To: Janardhanan Pathangi Narasimhan Cc: 'rbridge@postel.org' Subject: =B4=F0=B8=B4: =B4=F0=B8=B4: [rbridge] Call for = draft-tissa-trill-cmt-00 to WG draft =20 Hi Jana, =20 Let me use an example to explain. Suppose RB1, RB2 are members of the = aggregation. RBr is a remote RBridge who support CMT. It may communicate = with the aggregation. We assume that the transit RBridge RBt is non CMT. = It cannot calculate the trees as RBr which calculates two trees = according to the Affinity TLVs from RB1 and RB2. Then the two trees = calculated by RBr are inconsistent with those calculated by RBt. = Multicast traffic will not be forwarded correctly through RBt. =20 >From the above example, you can see that CMT does not allow non CMT = RBridge exist in the same campus because of the inconsistence of = distribution tree calculation. When you said that CMT can resort to = tunneling. That is to say there is non CMT RBridges in the campus. Then = we always have to resort to tunneling and traditional distribution tree = calculation due to the inconsistence of affinity distribution tree = calculation. That is not CMT anymore. =20 Based on above analysis, we can conclude that tunneling approach and CMT = are mutually exclusive. =20 Thanks, Mingui =20 ________________________________ =B7=A2=BC=FE=C8=CB: Janardhanan Pathangi Narasimhan = [jana@force10networks.com] =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C230=C8=D5 17:58 =B5=BD: Mingui Zhang Cc: 'rbridge@postel.org' =D6=F7=CC=E2: Re: =B4=F0=B8=B4: [rbridge] Call for = draft-tissa-trill-cmt-00 to WG draft Hi Mingui I did not understand yor statement. When non CMT nodes are present all = nodes (including CMT nodes) calculate trees as per the base standard. So = every node is pretty much present. In this situation and with active-active when a RBridge gets multi = destination frame from CE devices and it does not have the virtual = RBridge connected in any tree, it tunnels the frame to one of the = RBridges that has the VRB connectivity, which then ingresses this frame. Let me know if there is any issue with this Thanks Jana ________________________________ From: Mingui Zhang=20 To: Janardhanan Pathangi Narasimhan=20 Cc: rbridge@postel.org=20 Sent: Fri Mar 30 15:12:59 2012 Subject: =B4=F0=B8=B4: [rbridge] Call for draft-tissa-trill-cmt-00 to WG = draft=20 Hi Jana,=20 =20 When you say CMT disappears, I am assuming you mean that we will have to = do tunneling for all multi-destination frames. Much the same as what we = would have to do with MT when one non-MT RBridge exists.=20 =20 ZMG> Not exactly. In CMT, even you do not need to communicate with = non-CMT RBridges, the CMT cannot be used if non-CMT RBridges exist in = the campus. Non-CMT RBridges even cannot appear as transit RBridges. As = you know, the trees will not be calculated according to the affinity TLV = by these RBridges.=20 =20 Thanks, Mingui=20 =20 ________________________________ =B7=A2=BC=FE=C8=CB: Janardhanan Pathangi Narasimhan = [jana@force10networks.com] =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C230=C8=D5 17:36 =B5=BD: Mingui Zhang Cc: rbridge@postel.org =D6=F7=CC=E2: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG = draft Hi Mingui, =20 The tunneling is only for multi-destination frames and not for unicast = frames. Hence not sure what you are referring to here as tunneling based = on egress RBridge. =20 When you say CMT disappears, I am assuming you mean that we will have to = do tunneling for all multi-destination frames. Much the same as what we = would have to do with MT when one non-MT RBridge exists. =20 Thanks Jana =20 =20 From: Mingui Zhang [mailto:zhangmingui@huawei.com]=20 Sent: Friday, March 30, 2012 1:26 PM To: Janardhanan Pathangi Narasimhan Cc: rbridge@postel.org Subject: =B4=F0=B8=B4: [rbridge] Call for draft-tissa-trill-cmt-00 to WG = draft =20 Hi Jana, =20 The beauty of MTRA is that aggregated members can determine themselves = whether to use tunneling or not according to the egress RBridges. For MT = egress RBridges, they need not do tunneling. =20 As long as there is only one old RBridge in the campus, CMT does not = work. In order to be backward compatible using tunneling, CMT just = simply disappears totally. There is no CMT anymore.=20 =20 Thanks, Mingui ________________________________ =B7=A2=BC=FE=C8=CB: Janardhanan Pathangi Narasimhan = [jana@force10networks.com] =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C230=C8=D5 15:48 =B5=BD: Mingui Zhang Cc: rbridge@postel.org =D6=F7=CC=E2: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG = draft Hi Minghi, =20 With tunneling all approaches are backward compatible, including CMT.=20 =20 Thanks Jana =20 =20 From: Mingui Zhang [mailto:zhangmingui@huawei.com]=20 Sent: Friday, March 30, 2012 1:14 PM To: Janardhanan Pathangi Narasimhan Cc: rbridge@postel.org Subject: =B4=F0=B8=B4: [rbridge] Call for draft-tissa-trill-cmt-00 to WG = draft =20 Hi Jana,=20 =20 Have you forgotten the tunneling approach? In order to enable the = communication between MTRA RBridges and non-MT RBridges, we can always = resort to the tunneling approach to redirect the aggregated traffic to = the only parent of RBv on the distribution tree of the base topology for = delivery.=20 =20 I did not mention tunneling since I like simple solutions. I think = Section 4.2 of my draft did offer another simpler solution to allow us = to enable the communication between MRTA RBridges and non-MT RBridges. I = insist on this solution until operators tell me it is not workable. =20 So, of course MRTA is backward compatible.=20 =20 Thanks, Mingui ________________________________ =B7=A2=BC=FE=C8=CB: Janardhanan Pathangi Narasimhan = [jana@force10networks.com] =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C230=C8=D5 15:30 =B5=BD: Mingui Zhang Cc: rbridge@postel.org =D6=F7=CC=E2: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG = draft Hi Mingui =20 When you realize active-active, you are asking for the active-active = to be setup in a new topology and not the base topology. So these nodes = which need to talk to the other nodes which are behind non-MT RBridges = cannot do so any more.=20 =20 Specifically for MT to be backward compatible, you need all nodes = which want to talk to each other part of the base topology. If you do = that you cannot realize active-active. If you put the active-active in a = new topology, than they can no longer talk to nodes on the base topology = of non-MT RBridges. =20 So yes, MT-TRILL is backward compatible for base topology, but the = realization of active-active with MT =A8C TRILL is not backward = compatible. That was the point I was bringing up. =20 Thanks Jana =20 =20 From: Mingui Zhang [mailto:zhangmingui@huawei.com]=20 Sent: Friday, March 30, 2012 12:15 PM To: Janardhanan Pathangi Narasimhan Cc: rbridge@postel.org Subject: =B4=F0=B8=B4: [rbridge] Call for draft-tissa-trill-cmt-00 to WG = draft =20 Hi Jana,=20 =20 All RBridges in the campus are in the base topology. MT RBridges can = well communicate with non-MT RBridges using the base topology.=20 =20 I feel that you are arguing that MT-TRILL is not backward compatible. = That is a incorrect judgement. =20 Thanks, Mingui ________________________________ =B7=A2=BC=FE=C8=CB: Janardhanan Pathangi Narasimhan = [jana@force10networks.com] =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C230=C8=D5 13:29 =B5=BD: Mingui Zhang Cc: rbridge@postel.org =D6=F7=CC=E2: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG = draft Hi Mingui, =20 With MT approach, when two RBridges which had stations talking to each = other and one of them is converted to MT, then the communication is = broken. So it does not have backward computability.=20 =20 Thanks Jana =20 =20 From: Mingui Zhang [mailto:zhangmingui@huawei.com]=20 Sent: Friday, March 30, 2012 12:27 AM To: Janardhanan Pathangi Narasimhan Cc: rbridge@postel.org Subject: =B4=F0=B8=B4: [rbridge] Call for draft-tissa-trill-cmt-00 to WG = draft =20 Hi Jana,=20 =20 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? =20 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. =20 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 =20 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. =20 Thanks, Mingui =20 =20 =20 ________________________________ =B7=A2=BC=FE=C8=CB: Janardhanan Pathangi Narasimhan = [jana@force10networks.com] =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C230=C8=D5 0:49 =B5=BD: Mingui Zhang Cc: rbridge@postel.org =D6=F7=CC=E2: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG = draft Hi Mingui, =20 I am slightly confused.=20 =20 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. =20 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? =20 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.=20 =20 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 =20 Thanks Jana =20 Thanks, Mingui ________________________________ =B7=A2=BC=FE=C8=CB: rbridge-bounces@postel.org = [rbridge-bounces@postel.org] =B4=FA=B1=ED Mingui Zhang = [zhangmingui@huawei.com] =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C229=C8=D5 18:50 =B5=BD: Janardhanan Pathangi Narasimhan Cc: rbridge@postel.org =D6=F7=CC=E2: =B4=F0=B8=B4: [rbridge] Call for draft-tissa-trill-cmt-00 = to WG draft Hi Jana,=20 =20 >In section 4.1, could you please explain how the frame that is = ingressed by RB1 through RBv001 is received at RBx?=20 =20 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. =20 Thanks, Mingui ________________________________ =B7=A2=BC=FE=C8=CB: Janardhanan Pathangi Narasimhan = [jana@force10networks.com] =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C228=C8=D5 22:52 =B5=BD: Mingui Zhang Cc: rbridge@postel.org =D6=F7=CC=E2: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG = draft Hi Mingui, =20 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. =20 In section 4.1, could you please explain how the frame that is ingressed = by RB1 through RBv001 is received at RBx?=20 =20 Thanks Jana =20 =20 From: Mingui Zhang [mailto:zhangmingui@huawei.com]=20 Sent: Wednesday, March 28, 2012 7:15 PM To: Janardhanan Pathangi Narasimhan Cc: rbridge@postel.org Subject: =B4=F0=B8=B4: [rbridge] Call for draft-tissa-trill-cmt-00 to WG = draft =20 Hi Jana,=20 =20 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. =20 Thanks, Mingui ________________________________ =B7=A2=BC=FE=C8=CB: Janardhanan Pathangi Narasimhan = [jana@force10networks.com] =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C228=C8=D5 19:14 =B5=BD: Rohit Watve (rwatve); Mingui Zhang; Radia Perlman; Tissa = Senevirathne (tsenevir) Cc: rbridge@postel.org =D6=F7=CC=E2: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG = draft Hi Zhai, =20 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. =20 Could you please explain how MT can work in such scenarios? Thanks Jana =20 =20 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 =20 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.=20 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: =B4=F0=B8=B4: [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.=20 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.=20 PN: NO. The new distribution tree need to be recomputed. CMT: NO. A overall re-configuration is necessary. MTRA: YES.=20 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.=20 +--------+------------+-----------+----------+------------+-------------+= |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 =20 =B7=A2=BC=FE=C8=CB: rbridge-bounces@postel.org = [rbridge-bounces@postel.org] =B4=FA=B1=ED Radia Perlman = [radiaperlman@gmail.com] =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C228=C8=D5 12:52 =B5=BD: Tissa Senevirathne (tsenevir) Cc: rbridge@postel.org =D6=F7=CC=E2: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG = draft =20 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 =20 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. =20 So from memory...other proposals for allowing R1, R2, and R3 to be = active/active/active on a link: =20 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. =20 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. =20 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: =20 1) R3 could tunnel it to one of {R1, R2}, and let them inject the packet = (with pseudonode nickname) into the campus. =20 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. =20 2) R3 could use its own nickname instead of the pseudonode nickname in = this case =20 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). =20 ------ There might have been some other proposals, but they wound up not to = work. =20 Personally, I don't love the CMT thing because of the two disadvantages = I mentioned above, but I can live with it. =20 Radia=20 =20 ------_=_NextPart_001_01CD10FB.97590BB2 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Mingui

 

Since you are so empathetic about backward compatibility of control = plane, could you please let me know based on your estimates how many = RBridges out there in production networks ? So we can attach a priority = to the backward compatibility.

 

 

From:= = rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On = Behalf Of Mingui Zhang
Sent: Monday, April 02, 2012 8:13 = AM
To: Janardhanan Pathangi Narasimhan
Cc: = 'rbridge@postel.org'
Subject: =B4=F0=B8=B4: = =B4=F0=B8=B4: [rbridge] = Call for draft-tissa-trill-cmt-00 to WG = draft

 

= Hi Jana,

=  

= You offer a detail explanation on how tunneling approach works. I = believe the latter case below is not CMT anymore. It's normal TRILL plus = tunneling.

=  

= "Hence either the entire campus builds trees based on Affinity TLV = or the entire campus builds trees based on normal mechanism and ignore = Affinity TLV."  

=  

= This is actually not backward compatability. If you read the FGL draft, = you will know what is backward = compatibility. 

=  

= Thanks,

= Mingui

=  

=B7=A2=BC=FE=C8=CB= := Janardhanan Pathangi Narasimhan = [jana@force10networks.com]
=B7=A2=CB=CD=CA=B1=BC=E4= := 2012=C4=EA= 4=D4=C2= 1=C8=D5= 23:50
=B5=BD= := Mingui Zhang
Cc: 'rbridge@postel.org'
=D6=F7=CC=E2= := RE: =B4=F0=B8=B4= : [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Mingui,

 

Please look at section 4.3. =A1=B0Affinity Sub-TLV Capability=A1=B1 = =A8C This is to indicate if an RBridge can or cannot support Affinity = TLV. This capability includes both the ability to set the Affinity TLV = and also the capability to act on it, i.e. calculate trees based on = Affinity TLV

 

The backward compatibility operates as follows

 

-       &= nbsp;  Once the LSP data base is formed, if all RBridges in the campus = support Affinity TLV, than all the RBridges in the campus will build the = tree based on the Affinity TLV

-       &= nbsp;  If there is one or more RBridges which do not advertise = =A1=B0Affinity Capability=A1=B1, than all the RBridges in the campus = will build the tree based on normal mechanism and will ignore the = affinity TLV (including those routers which are capable of understanding = this)

 

Hence either the entire campus builds trees based on Affinity TLV or = the entire campus builds trees based on normal mechanism and ignore = Affinity TLV. There is no situation where the TREES are out of sync = between different nodes

 

In terms of tunneling, the approach is as follows

 

-       &= nbsp;  When there are some non CMT nodes, all RBridges build the trees based = on the regular mechanism. In this situation, let us assume that there = are three RBridges R1, R2 and R3 joining to emulate a virtual RBridge = RBV. Now since the trees formed are based on normal mechanism and not = based on Affinity TLV, it is not guaranteed that all R1, R2 and R3 will = have a connectivity to RBV on at least one tree.

-       &= nbsp;  But it is always Guarenteed that at least one of R1, R2 and R3 will = have this connectivity

-       &= nbsp;  So if for argument sake R1 has this connectivity to RBv, then when R2 = and R3 get a multi-destination frame, they cannot ingress that since = they cannot set the ingress Nickname as RBv. So they will tunnel it to = R1, which will then ingress it on their behalf into the TRILL campus = network, as it has the connectivity to RBv, and can use the ingress = nickname of RBV in multi-destination frames without any problems of RPF = check failures.

 

Let us know if this is not clear in the draft, maybe we can add more = text to clarify this operation in the next version of the draft if that = is the case.

 

And note this tunneling is only for multi-destination frames and not = for unicast frames being ingressed by R2 and R3.

 

Thanks

Jana

 

 

= From:= Mingui Zhang [mailto:zhangmingui@huawei.com]=
Sent: Sunday, April 01, 2012 8:37 PM
To: = Janardhanan Pathangi Narasimhan
Cc: = 'rbridge@postel.org'
Subject: =B4=F0=B8=B4= : =B4=F0=B8=B4= : [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

 

= Hi Jana,

=  

= Let me use an example to explain. Suppose RB1, RB2 are members of the = aggregation. RBr is a remote RBridge who support CMT. It may communicate = with the aggregation. We assume that the transit RBridge RBt is non CMT. = It cannot calculate the trees as RBr which calculates two trees = according to the Affinity TLVs from RB1 and RB2. Then the two = trees calculated by RBr are inconsistent with those calculated = by RBt. Multicast traffic will not be forwarded correctly through = RBt.

=  

= >From the above example, you can see that CMT does not allow non CMT = RBridge exist in the same campus because of = the inconsistence of distribution tree calculation. When you = said that CMT can resort to tunneling. That is to say there is non CMT = RBridges in the campus. Then we always have to resort to tunneling and = traditional distribution tree calculation due to = the inconsistence of affinity distribution tree calculation. = That is not CMT anymore.

=  

= Based on above analysis, we can conclude that tunneling approach and CMT = are mutually  exclusive.

=  

= Thanks,

= Mingui

=  

=B7=A2=BC=FE=C8=CB= := Janardhanan Pathangi Narasimhan = [jana@force10networks.com]
=B7=A2=CB=CD=CA=B1=BC=E4= := 2012=C4=EA= 3=D4=C2= 30=C8=D5= 17:58
=B5=BD= := Mingui Zhang
Cc: 'rbridge@postel.org'
=D6=F7=CC=E2= := Re: =B4=F0=B8=B4= : [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi= Mingui

I did not understand yor statement. When non CMT nodes = are present all nodes (including CMT nodes) calculate trees as per the = base standard. So every node is pretty much present.

In this = situation and with active-active when a RBridge gets multi destination = frame from CE devices and it does not have the virtual RBridge connected = in any tree, it tunnels the frame to one of the RBridges that has the = VRB connectivity, which then ingresses this frame.

Let me know if = there is any issue with this

Thanks
Jana

= From= : Mingui Zhang
To: Janardhanan Pathangi Narasimhan =
Cc: rbridge@postel.org
Sent: Fri Mar 30 = 15:12:59 2012
Subject: =B4=F0=B8=B4= : [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

= Hi Jana,

=  

When you say CMT disappears, I am assuming you mean that we will have = to do tunneling for all multi-destination frames. Much the same as what = we would have to do with MT when one non-MT RBridge exists.=  

=  

= ZMG> Not exactly. In CMT, even you do not need to communicate with = non-CMT RBridges, the CMT cannot be used if non-CMT RBridges exist in = the campus. Non-CMT RBridges even cannot appear as transit RBridges. As = you know, the trees will not be calculated according to the affinity TLV = by these RBridges. 

=  

= Thanks,

= Mingui

=  

=B7=A2=BC=FE=C8=CB= := Janardhanan Pathangi Narasimhan = [jana@force10networks.com]
=B7=A2=CB=CD=CA=B1=BC=E4= := 2012=C4=EA= 3=D4=C2= 30=C8=D5= 17:36
=B5=BD= := Mingui Zhang
Cc: rbridge@postel.org
=D6=F7=CC=E2= := RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Mingui,

 

The tunneling is only for multi-destination frames and not for = unicast frames. Hence not sure what you are referring to here as = tunneling based on egress RBridge.

 

When you say CMT disappears, I am assuming you mean that we will have = to do tunneling for all multi-destination frames. Much the same as what = we would have to do with MT when one non-MT RBridge exists.

 

Thanks

Jana

 

 

= From:= Mingui Zhang [mailto:zhangmingui@huawei.com]
Sent: = Friday, March 30, 2012 1:26 PM
To: Janardhanan Pathangi = Narasimhan
Cc: rbridge@postel.org
Subject: =B4=F0=B8=B4= : [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

 

= Hi Jana,

=  

= The beauty of MTRA is that aggregated members can determine themselves = whether to use tunneling or not according to the egress RBridges. For MT = egress RBridges, they need not do tunneling.

=  

= As long as there is only one old RBridge in the campus, CMT does not = work. In order to be backward compatible using tunneling, CMT just = simply disappears totally. There is no CMT anymore. 

=  

= Thanks,

= Mingui

=B7=A2=BC=FE=C8=CB= := Janardhanan Pathangi Narasimhan = [jana@force10networks.com]
=B7=A2=CB=CD=CA=B1=BC=E4= := 2012=C4=EA= 3=D4=C2= 30=C8=D5= 15:48
=B5=BD= := Mingui Zhang
Cc: rbridge@postel.org
=D6=F7=CC=E2= := RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Minghi,

 

With tunneling all approaches are backward compatible, including CMT. =

 

Thanks

Jana

 

 

= From:= Mingui Zhang [mailto:zhangmingui@huawei.com]
Sent: = Friday, March 30, 2012 1:14 PM
To: Janardhanan Pathangi = Narasimhan
Cc: rbridge@postel.org
Subject: =B4=F0=B8=B4= : [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

 

= Hi Jana,

=  

= Have you forgotten the tunneling approach? In order to enable the = communication between MTRA RBridges and non-MT RBridges, we can always = resort to the tunneling approach to redirect the aggregated traffic to = the only parent of RBv on the distribution tree of the base topology for = delivery. 

=  

= I did not mention tunneling since I like simple solutions. I think = Section 4.2 of my draft did offer another simpler solution to allow us = to enable the communication between MRTA RBridges and non-MT RBridges. I = insist on this solution until operators tell me it is not = workable.

=  

= So, of course MRTA is backward compatible. 

=  

= Thanks,

= Mingui

=B7=A2=BC=FE=C8=CB= := Janardhanan Pathangi Narasimhan = [jana@force10networks.com]
=B7=A2=CB=CD=CA=B1=BC=E4= := 2012=C4=EA= 3=D4=C2= 30=C8=D5= 15:30
=B5=BD= := Mingui Zhang
Cc: rbridge@postel.org
=D6=F7=CC=E2= := RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Mingui

 

  When you realize active-active, you are asking for the = active-active to be setup in a new topology and not the base topology. = So these nodes which need to talk to the other nodes which are behind = non-MT RBridges cannot do so any more.

 

  Specifically for MT to be backward compatible, you need all = nodes which want to talk to each other part of the base topology. If you = do that you cannot realize active-active. If you put the active-active = in a new topology, than they can no longer talk to nodes on the base = topology of non-MT RBridges.

 

So yes, MT-TRILL is backward compatible for base topology, but the = realization of active-active with MT =A8C TRILL is not backward = compatible. That was the point I was bringing up.

 

Thanks

Jana

 

 

= From:= Mingui Zhang [mailto:zhangmingui@huawei.com]
Sent: = Friday, March 30, 2012 12:15 PM
To: Janardhanan Pathangi = Narasimhan
Cc: rbridge@postel.org
Subject: =B4=F0=B8=B4= : [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

 

= Hi Jana,

=  

= All RBridges in the campus are in the base topology. MT RBridges can = well communicate with non-MT RBridges using the base = topology. 

=  

= I feel that you are arguing that MT-TRILL is not = backward compatible. That is a incorrect judgement.

=  

= Thanks,

= Mingui

=

=B7=A2=BC=FE=C8=CB= := Janardhanan Pathangi Narasimhan = [jana@force10networks.com]
=B7=A2=CB=CD=CA=B1=BC=E4= := 2012=C4=EA= 3=D4=C2= 30=C8=D5= 13:29
=B5=BD= := Mingui Zhang
Cc: rbridge@postel.org
=D6=F7=CC=E2= := RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

Hi Mingui,

 

With MT approach, when two RBridges which had stations talking to = each other and one of them is converted to MT, then the communication is = broken. So it does not have backward computability.

 

Thanks

Jana

 

 

= From:= Mingui Zhang [mailto:zhangmingui@huawei.com]
Sent: = Friday, March 30, 2012 12:27 AM
To: Janardhanan Pathangi = Narasimhan
Cc: rbridge@postel.org
Subject: =B4=F0=B8=B4= : [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft

 

= 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

=  

=  

=  

=B7=A2=BC=FE=C8=CB= := Janardhanan Pathangi Narasimhan = [jana@force10networks.com]
=B7=A2=CB=CD=CA=B1=BC=E4= := 2012=C4=EA= 3=D4=C2= 30=C8=D5= 0:49
=B5=BD= := Mingui Zhang
Cc: rbridge@postel.org
=D6=F7=CC=E2= := 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

=B7=A2=BC=FE=C8=CB= := rbridge-bounces@postel.org = [rbridge-bounces@postel.org] =B4=FA=B1=ED= Mingui Zhang [zhangmingui@huawei.com]
=B7=A2=CB=CD=CA=B1=BC=E4= := 2012=C4=EA= 3=D4=C2= 29=C8=D5= 18:50
=B5=BD= := Janardhanan Pathangi Narasimhan
Cc: rbridge@postel.org
=D6=F7=CC=E2= := =B4=F0=B8=B4= : [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

=B7=A2=BC=FE=C8=CB= := Janardhanan Pathangi Narasimhan = [jana@force10networks.com]
=B7=A2=CB=CD=CA=B1=BC=E4= := 2012=C4=EA= 3=D4=C2= 28=C8=D5= 22:52
=B5=BD= := Mingui Zhang
Cc: rbridge@postel.org
=D6=F7=CC=E2= := 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: =B4=F0=B8=B4= : [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

=B7=A2=BC=FE=C8=CB= := Janardhanan Pathangi Narasimhan = [jana@force10networks.com]
=B7=A2=CB=CD=CA=B1=BC=E4= := 2012=C4=EA= 3=D4=C2= 28=C8=D5= 19:14
=B5=BD= := Rohit Watve (rwatve); Mingui Zhang; Radia Perlman; Tissa Senevirathne = (tsenevir)
Cc: rbridge@postel.org
=D6=F7=CC=E2= := 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: =B4=F0=B8=B4: [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    &nb= sp; |YES         = |NO         = |NO        = |NO          = |NO           = |

+--------+------------+-------= ----+----------+------------+-------------|

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

+--------+------------+-------= ----+----------+------------+-------------|

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

+--------+------------+-------= ----+----------+------------+-------------+

Thanks,

Mingui

 

=B7=A2=BC=FE=C8=CB: rbridge-bounces@postel.org = [rbridge-bounces@postel.org] = =B4=FA=B1=ED Radia Perlman = [radiaperlman@gmail.com]

=B7=A2=CB=CD=CA=B1=BC=E4= : 2012=C4=EA3=D4=C228=C8=D5 12:52

=B5=BD: Tissa Senevirathne = (tsenevir)

Cc: rbridge@postel.org

=D6=F7=CC=E2: 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

 

=
<= /div>
------_=_NextPart_001_01CD10FB.97590BB2-- --===============1080870884== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge --===============1080870884==-- From rbridge-bounces@postel.org Wed Apr 4 21:20:22 2012 Return-Path: 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 62AAD21F8692 for ; Wed, 4 Apr 2012 21:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.832 X-Spam-Level: X-Spam-Status: No, score=-3.832 tagged_above=-999 required=5 tests=[AWL=2.767, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 AXVjfmCWw16K for ; Wed, 4 Apr 2012 21:20:21 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4DA21F8691 for ; Wed, 4 Apr 2012 21:20:21 -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 q3541xsk018412; Wed, 4 Apr 2012 21:02:00 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q3541iKe018387 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 4 Apr 2012 21:01:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tsenevir@cisco.com; l=3505; q=dns/txt; s=iport; t=1333598513; x=1334808113; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=46UMc6bKD3via2lcx9uLcKNGJeevZbpAvfW5fPoGljU=; b=BuvvOJ5c8qozbcUdGPF4gDxZyxxAEY3/FolwSvt9mDHVesK8FRy42ANX /c4wX1lSghXJJmqRim98M6AHjglsCGT4yTirQ4NZZo9Elz2XzR8oA3U11 clNdutd/7TprhP5UprvY+1oSbUBDe5dG7VYShCU8C/9axrI8ChkeoF0ED Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFALcYfU+rRDoG/2dsb2JhbABCA7hbgQeCCQEBAQQBAQEPARQJPgsMBAIBCA4DBAEBAQoGFwEGASAGHwkIAQEEARIIGodeAwoMm0CVdA2JU4oYgw6CRmMEiCYzjiCKJYMUgWmDBw X-IronPort-AV: E=Sophos;i="4.75,374,1330905600"; d="scan'208";a="36562699" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 05 Apr 2012 04:01:44 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3541ihn000983; Thu, 5 Apr 2012 04:01:44 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Apr 2012 21:01:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 4 Apr 2012 21:01:43 -0700 Message-ID: <344037D7CFEFE84E97E9CC1F56C5F4A5E3B715@xmb-sjc-214.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Parent node ID selection for multi destination trees Thread-Index: Ac0MBt4OihpRYOCPSSi5AeZBS70T4gG2brnA References: From: "Tissa Senevirathne (tsenevir)" To: "Donald Eastlake" , "Ayan Banerjee (ayabaner)" X-OriginalArrivalTime: 05 Apr 2012 04:01:44.0056 (UTC) FILETIME=[D0510F80:01CD12E0] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: tsenevir@cisco.com X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id q3541iKe018387 Cc: rbridge@postel.org, "Varun Shah \(varshah\)" Subject: Re: [rbridge] Parent node ID selection for multi destination trees X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org Hi Donald Since we are still in very early days of TRILL, I think it is alright to in= clude the proposed change in the clear correct draft. I also support making Clear correct draft. Thanks Tissa -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Beh= alf Of Donald Eastlake Sent: Tuesday, March 27, 2012 3:28 AM To: Ayan Banerjee (ayabaner) Cc: rbridge@postel.org; Varun Shah (varshah) Subject: Re: [rbridge] Parent node ID selection for multi destination trees The only problem with making the change below is that it is very important = that all RBridges calculate exactly the same distribution trees. Otherwise = multi-destinationn traffic get dropped due to the Reverse Path Forwarding C= heck. The existing specification, while a bit odd, works; but an implementa= tion of the existing specification and the proposed changed specification w= ould have interoperability problems for multi-destination TRILL Data frame. I'd really like to hear from other implementors as to whether they have imp= lemented it as specified in RFC 6325 and what their feelings are about the = proposed change. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com On Sat, Mar 17, 2012 at 2:24 PM, ayabaner wrote: > Varun, > > Agree, that was the original intention. I believe that if kept as-is = > we will have more unnecessary changes in the SPF outputs when topology ch= anges. > > I believe that we should just add this into the = > "draft-ietf-trill-clear-correct-01". > > Thanks, > Ayan > > > > > On 3/16/12 5:30 PM, "varshah" wrote: > > Hi, > > Reading section 4.5 of RFC 6325 > (http://tools.ietf.org/html/rfc6325#section-4.5) it seems that the = > selection of a parent node =A0(7 byte- node ID) for a node N on a multi = > destination tree j; should be based on j % p, where p is the number of = > equal cost parent nodes to reach node N from root node R. > > The intent seems to use lowest parent node ID for tree 1, next for = > tree 2 and so on.... And circle through if we have more possible trees = > than parent nodes. > > However, the trees are numbered starting 1, and the parent node IDs = > are indexed starting 0 to (p - 1). =A0So, for a node N, when the network = > supports > 2 trees and with two possible parent nodes, =A0we would use > > parent node indexed at 1 for tree 1, j % p --> 1 % 2 =3D 1 and Parent = > node indexed at 0 for tree 2, j % p --> 2 % 2 =3D 0. > > To stay with the real intention, it would help if we had (j - 1) %p. > > In that case, > parent node indexed at 0 for tree 1, (j =A0- 1)% p --> 0 % 2 =3D 0 and = > Parent node indexed at 1 for tree 2,( j - 1) % p --> 1 % 2 =3D 1. > > Thanks, > -Varun > ________________________________ > _______________________________________________ > 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 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 From rbridge-bounces@postel.org Wed Apr 4 23:27:03 2012 Return-Path: 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 6D15221F86E3 for ; Wed, 4 Apr 2012 23:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] 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 2gXPSiTnhdDi for ; Wed, 4 Apr 2012 23:27:02 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 93B7D21F86C7 for ; Wed, 4 Apr 2012 23:27:02 -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 q3564MR8006377; Wed, 4 Apr 2012 23:04:24 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q3563JGA006004 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 4 Apr 2012 23:03:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ayabaner@cisco.com; l=1493; q=dns/txt; s=iport; t=1333605808; x=1334815408; h=date:subject:from:to:message-id:mime-version; bh=nzm6u+scwr4zyAXpR8ybdpAjwiAqod1r6aBVc1S/oMQ=; b=GRsbKkL0ecj0/ggdII+D8HQA4D5kZSt90Q3oZyGasX8cfrkEFUrYF2UB ohU8MqYUl8Dm8kiuCEIYbn6W8fTHSfeI4d70JesL59VCuAz/0BZDzUJyu 33o8yWD28VVlAtiEuRhLZzXR1DGicZhOAnH6nQ17Un+SUk2yQ6s6/5YUS Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANk0fU+rRDoG/2dsb2JhbABFgka1HHeBB4IACwEEEgEKIDEdAQgDAQWBFQEENYdrAZoegSefW40rgyQEiFmFLIdjjkqBaYMH X-IronPort-AV: E=Sophos;i="4.75,374,1330905600"; d="scan'208,217";a="36572938" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 05 Apr 2012 06:03:19 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3563Jii030712 for ; Thu, 5 Apr 2012 06:03:19 GMT Received: from xmb-sjc-22b.amer.cisco.com ([128.107.191.112]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Apr 2012 23:03:18 -0700 Received: from 10.21.67.31 ([10.21.67.31]) by xmb-sjc-22b.amer.cisco.com ([128.107.191.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 5 Apr 2012 06:03:17 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 04 Apr 2012 23:03:27 -0700 From: ayabaner To: Message-ID: Thread-Topic: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft Thread-Index: Ac0S8dE1/IO9r1jUIEGq/0uJDAjJ5Q== Mime-version: 1.0 X-OriginalArrivalTime: 05 Apr 2012 06:03:18.0869 (UTC) FILETIME=[CC5D3050:01CD12F1] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: ayabaner@cisco.com Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0527469191==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0527469191== Content-type: multipart/alternative; boundary="B_3416425408_8895766" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3416425408_8895766 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Yes, I believe that this is an important piece of the puzzle and should be made a WG document. Thanks, Ayan ==== During the TRILL session today, there was a consensus of those in the room to make draft-tissa-trill-cmt-00.txt a TRILL WG draft. This is a call on the WG mailing list to confirm that consensus. If you wish to respond, please do so by April 10th. Thanks, Donald --B_3416425408_8895766 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft Yes, I believe that this is an important piece of the puzzle and should b= e made a WG document.

Thanks,
Ayan
=3D=3D=3D=3D



During the TRILL session today, there was a consensus of those in the
room to make draft-tissa-trill-cmt-00.txt a TRILL WG draft. This is a
call on the WG mailing list to confirm that consensus. If you wish to
respond, please do so by April 10th.

Thanks,
Donald --B_3416425408_8895766-- --===============0527469191== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge --===============0527469191==-- From rbridge-bounces@postel.org Wed Apr 4 23:29:22 2012 Return-Path: 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 C333E21F86E3 for ; Wed, 4 Apr 2012 23:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.376 X-Spam-Level: X-Spam-Status: No, score=-5.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4] 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 T08o3GMqDCHm for ; Wed, 4 Apr 2012 23:29:21 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id DFB5C21F86C7 for ; Wed, 4 Apr 2012 23:29:21 -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 q355uZUE005262; Wed, 4 Apr 2012 22:56:36 -0700 (PDT) Received: from mail-iy0-f180.google.com (mail-iy0-f180.google.com [209.85.210.180]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q355tsRp005215 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 4 Apr 2012 22:56:03 -0700 (PDT) Received: by iage36 with SMTP id e36so2180902iag.39 for ; Wed, 04 Apr 2012 22:55:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-gm-message-state; bh=tgfCCXuYiTHVNdV8tOGvZ7GyPcsyeb10cKlDbFcef0s=; b=BzY11ft4fJ/gARuNpKiKMuyOtKANQgkNXyyA4thutlmOFf3iAKdGp/Q8ZvwKe0ev6Q jJdcALAOb08KolqkC7gqlYn36CuUiHvlbq4a8lyc3ZI8W/yi8Go2odvr52BGY3oFOyxQ m8Jv+HEvIF1AAXfaYByyAa//zuGaNggd0zQEJksGd9F92W+8Gu0q7vKHPw5p8wu5XxYp h4J9a2WtseSe2QERCFPwOoTLnSddSrqquwdw3TXJzwWJY7VNPFT52xY7ZUOOgZbWS1ca N93XfBj6S79ZosJlZaE/18fA6QY5eoaDvwlg3o5kMALlNFuHZmbmAC+TqVBgUWQx5yh4 dbzQ== Received: by 10.42.144.201 with SMTP id c9mr736179icv.29.1333605353820; Wed, 04 Apr 2012 22:55:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.30.195 with HTTP; Wed, 4 Apr 2012 22:55:33 -0700 (PDT) From: Muhammad Mohsin Sardar Date: Thu, 5 Apr 2012 10:55:33 +0500 Message-ID: To: rbridge@postel.org Content-Type: multipart/mixed; boundary=90e6ba6e8a1862913f04bce831c0 X-Gm-Message-State: ALoCoQkkHdFLNcuBZTfDW0fofqRA4knsEQI/re7fNkIT2wxGk8fPBCGbF1wjzWDGnenYj4/bV3pO X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: mohsin.sardar@seecs.edu.pk Subject: [rbridge] TRILL control frames communication X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org --90e6ba6e8a1862913f04bce831c0 Content-Type: multipart/alternative; boundary=90e6ba6e8a1862913a04bce831be --90e6ba6e8a1862913a04bce831be Content-Type: text/plain; charset=ISO-8859-1 Hi! Given in RFC6325 section 4.2.3 TRILL IS-IS frames are never forwarded by an RBridge but are locally processed on receipt. (Such processing may cause the RBridge to send additional TRILL IS-IS frames.) Given in RFC6325 section 4.6.2 1. If the Outer.MacDA is All-IS-IS-RBridges and the Ethertype is L2-IS-IS, the frame is handled as described in Section 4.6.2.1. 4.6.2.1. TRILL Control Frames: The frame is processed by the TRILL IS-IS instance on RBn and is not forwarded. As IS-IS frames are never forwarded by an RBridge, why All-IS-IS-RBridges multicast address is used? Please clarify. As per my understanding TRILL IIH frames are sent to the neighbors, bounded by RBridges ( Broadcast domain is link) Am I right? +-------+ +---------+ +---------+ +---------+ +----------+ +-------+ | ESa +----+ RB1 +----+ RB3 +--------+ RB4 +-------+ RB2 +---+ESb | +-------+ |ingress| | transit| | transit| | egress | +-------+ +---------+ +---------+ +---------+ +----------+ If all RBridges are just up, following pattern will be followed: RB1 send TRILL IIH to RB3 RB2 send TRILL IIH to RB4 RB3 send TRILL IIH to RB1 and RB4 RB4 send TRILL IIH to RB2 and RB3 Please correct me, if I am misinterpreting it. TRILL IS-IS LSP's are used to communicate the link information to the campus. That's how, RBridges know each other. As RBridges do not forward TRILL IS-IS frames, how information (TRILL IS-IS LSP) of RB1 is communicated to RB2? Thank you! -- Best Regards, Muhammad Mohsin Sardar --90e6ba6e8a1862913a04bce831be Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi!

Given in RFC6325 section 4.2.3
TRILL IS-IS frames are never f= orwarded by an RBridge but are locally processed on receipt.=A0 (Such proce= ssing may cause the RBridge to send additional TRILL IS-IS frames.)
Give= n in RFC6325 section 4.6.2
1. If the Outer.MacDA is All-IS-IS-RBridges and the Ethertype is L2-IS-IS, = the frame is handled as described in Section 4.6.2.1.
4.6.2.1. TRILL Con= trol Frames: The frame is processed by the TRILL IS-IS instance on RBn and = is not forwarded.
As IS-IS frames are never forwarded b= y an RBridge, why All-IS-IS-RBridges multicast address is used? Please clar= ify.

As per my understanding TRILL IIH frames are sent to the= neighbors, bounded by RBridges ( Broadcast domain is link)
Am I right?


=A0=A0= =A0=A0 +-------+=A0=A0=A0 +---------+=A0=A0=A0 +---------+=A0=A0=A0=A0=A0= =A0=A0=A0 +---------+=A0=A0=A0=A0=A0=A0 +----------+=A0=A0 +-------+
=A0= =A0=A0=A0 | ESa +----+ RB1=A0 +----+ RB3=A0 +--------+ RB4=A0 +-------+=A0 = RB2=A0 +---+ESb |
=A0=A0=A0=A0 +-------+ =A0 =A0 |ingress|=A0 =A0=A0 | transit|=A0=A0=A0=A0= =A0 =A0 =A0 | transit|=A0 =A0 =A0 =A0 | egress | =A0=A0 +-------+
=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +---------+=A0=A0=A0 +-= --------+=A0=A0=A0=A0=A0=A0=A0=A0 +---------+=A0 =A0 =A0=A0 +----------+
If all RBridges are just up, following pattern will be followed:
RB1 send TRILL IIH to RB3
RB2 send TRILL IIH to RB4
RB3 send TRILL II= H to RB1 and RB4
RB4 send TRILL IIH to RB2 and RB3
Please correct me, if I am misinterpreting it.
TRILL IS-IS LSP's are used to communicate the link information to t= he campus. That's how, RBridges know each other.
As RBridges do not forward TRILL IS-IS frames, how infor= mation (TRILL IS-IS LSP) of RB1 is communicated to RB2?

Thank you!

--
Best Regards,
Muhammad Mohsin Sardar
--90e6ba6e8a1862913a04bce831be-- --90e6ba6e8a1862913f04bce831c0 Content-Type: text/plain; charset=US-ASCII; name="TRILL.txt" Content-Disposition: attachment; filename="TRILL.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h0ne01gw1 R2l2ZW4gaW4gUkZDNjMyNSBzZWN0aW9uIDQuMi4zClRSSUxMIElTLUlTIGZyYW1lcyBhcmUgbmV2 ZXIgZm9yd2FyZGVkIGJ5IGFuIFJCcmlkZ2UgYnV0IGFyZSBsb2NhbGx5IHByb2Nlc3NlZCBvbiBy ZWNlaXB0LiAgKFN1Y2ggcHJvY2Vzc2luZyBtYXkgY2F1c2UgdGhlIFJCcmlkZ2UgdG8gc2VuZCBh ZGRpdGlvbmFsIFRSSUxMIElTLUlTIGZyYW1lcy4pCkdpdmVuIGluIFJGQzYzMjUgc2VjdGlvbiA0 LjYuMgoxLiBJZiB0aGUgT3V0ZXIuTWFjREEgaXMgQWxsLUlTLUlTLVJCcmlkZ2VzIGFuZCB0aGUg RXRoZXJ0eXBlIGlzIEwyLUlTLUlTLCB0aGUgZnJhbWUgaXMgaGFuZGxlZCBhcyBkZXNjcmliZWQg aW4gU2VjdGlvbiA0LjYuMi4xLgo0LjYuMi4xLiBUUklMTCBDb250cm9sIEZyYW1lczogVGhlIGZy YW1lIGlzIHByb2Nlc3NlZCBieSB0aGUgVFJJTEwgSVMtSVMgaW5zdGFuY2Ugb24gUkJuIGFuZCBp cyBub3QgZm9yd2FyZGVkLgoKQXMgSVMtSVMgZnJhbWVzIGFyZSBuZXZlciBmb3J3YXJkZWQgYnkg YW4gUkJyaWRnZSwgd2h5IEFsbC1JUy1JUy1SQnJpZGdlcyBtdWx0aWNhc3QgYWRkcmVzcyBpcyB1 c2VkPyBQbGVhc2UgY2xhcmlmeS4KCkFzIHBlciBteSB1bmRlcnN0YW5kaW5nIFRSSUxMIElJSCBm cmFtZXMgYXJlIHNlbnQgdG8gdGhlIG5laWdoYm9ycywgYm91bmRlZCBieSBSQnJpZGdlcyAoIEJy b2FkY2FzdCBkb21haW4gaXMgbGluaykKCkFtIEkgcmlnaHQ/CgoKICAgICArLS0tLS0rICArLS0t LS0tLSsgICArLS0tLS0tLSsgICAgICAgKy0tLS0tLS0rICAgKy0tLS0tLS0rICArLS0tLSsKICAg ICB8IEVTYSArLS0rICBSQjEgICstLS0rICBSQjMgICstLS0tLS0tKyAgUkI0ICArLS0tKyAgUkIy ICArLS0rRVNiIHwKICAgICArLS0tLS0rICB8aW5ncmVzc3wgICB8dHJhbnNpdHwgICAgICAgfHRy YW5zaXR8ICAgfGVncmVzcyB8ICArLS0tLSsKICAgICAgICAgICAgICArLS0tLS0tLSsgICArLS0t LS0tLSsgICAgICAgKy0tLS0tLS0rICAgKy0tLS0tLS0rCgpJZiBhbGwgUkJyaWRnZXMgYXJlIGp1 c3QgdXAsIGZvbGxvd2luZyBwYXR0ZXJuIHdpbGwgYmUgZm9sbG93ZWQ6ClJCMSBzZW5kIFRSSUxM IElJSCB0byBSQjMKUkIyIHNlbmQgVFJJTEwgSUlIIHRvIFJCNApSQjMgc2VuZCBUUklMTCBJSUgg dG8gUkIxIGFuZCBSQjQKUkI0IHNlbmQgVFJJTEwgSUlIIHRvIFJCMiBhbmQgUkIzCgpQbGVhc2Ug Y29ycmVjdCBtZSwgaWYgSSBhbSBtaXNpbnRlcnByZXRpbmcgaXQuCgpUUklMTCBJUy1JUyBMU1An cyBhcmUgdXNlZCB0byBjb21tdW5pY2F0ZSB0aGUgbGluayBpbmZvcm1hdGlvbiB0byB0aGUgY2Ft cHVzLiBUaGF0cyBob3csIFJCcmlkZ2VzIGtub3cgZWFjaCBvdGhlci4KQXMgUkJyaWRnZXMgZG8g bm90IGZvcndhcmQgVFJJTEwgSVMtSVMgZnJhbWVzLCBob3cgaW5mb3JtYXRpb24gKFRSSUxMIElT LUlTIExTUCkgb2YgUkIxIGlzIGNvbW11bmljYXRlZCB0byBSQjI/CgoK --90e6ba6e8a1862913f04bce831c0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge --90e6ba6e8a1862913f04bce831c0-- From rbridge-bounces@postel.org Thu Apr 5 02:16:07 2012 Return-Path: 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 0C70F21F86F0 for ; Thu, 5 Apr 2012 02:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.257 X-Spam-Level: X-Spam-Status: No, score=0.257 tagged_above=-999 required=5 tests=[AWL=3.806, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] 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 6xCwMtQouXhM for ; Thu, 5 Apr 2012 02:16:05 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0CC21F86D3 for ; Thu, 5 Apr 2012 02:15:58 -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 q358uMfc002030; Thu, 5 Apr 2012 01:56:23 -0700 (PDT) Received: from szxga04-in.huawei.com ([58.251.152.67]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q358td6D001917 for ; Thu, 5 Apr 2012 01:55:48 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M20006BA0PSEG@szxga04-in.huawei.com> for rbridge@postel.org; Thu, 05 Apr 2012 16:53:52 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M2000KHZ0PR8J@szxga04-in.huawei.com> for rbridge@postel.org; Thu, 05 Apr 2012 16:53:52 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AIC64110; Thu, 05 Apr 2012 16:53:06 +0800 Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 05 Apr 2012 16:53:00 +0800 Received: from SZXEML507-MBS.china.huawei.com ([169.254.7.100]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.01.0323.003; Thu, 05 Apr 2012 16:53:01 +0800 Date: Thu, 05 Apr 2012 08:53:00 +0000 From: Mingui Zhang In-reply-to: <344037D7CFEFE84E97E9CC1F56C5F4A5E3ACD9@xmb-sjc-214.amer.cisco.com> X-Originating-IP: [10.108.4.73] To: "Tissa Senevirathne (tsenevir)" , Janardhanan Pathangi Narasimhan Message-id: <4552F0907735844E9204A62BBDD325E728CB35A1@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//+PaAIAAy5WsgAAUHfCAABB74IAAKcBDgAASQ3CAAUvIPoAAP81cgAAoPaCAACBD3IAAtGNggAAT3tCAAA2IQIAADzCAgAAD9ECAA6fZcIABd2IMgAACI9CABDHOkA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <344037D7CFEFE84E97E9CC1F56C5F4A5DA0303@xmb-sjc-214.amer.cisco.com> <4552F0907735844E9204A62BBDD325E728CAD030@SZXEML507-MBS.china.huawei.com> <344037D7CFEFE84E97E9CC1F56C5F4A5DA05D7@xmb-sjc-214.amer.cisco.com> <4552F0907735844E9204A62BBDD325E728CAE193@SZXEML507-MBS.china.huawei.com> <4552F0907735844E9204A62BBDD325E728CAE2F1@SZXEML507-MBS.china.huawei.com> <4552F0907735844E9204A62BBDD325E728CAE77F@SZXEML507-MBS.china.huawei.com> <4552F0907735844E9204A62BBDD325E728CB086C@SZXEML507-MBS.china.huawei.com> <"CE35792847FBE8468 7FF911713 2C8EFD471144 1520"@EXCH-CLUSTER-11.force10networks.com> <4552F0907735844E9204A62BBDD325E728CB0B20@SZXEML507-MBS.china.huawei.com> <344037D7CFEFE84E97E9CC1F56C5F4A5DA122A@xmb-sjc-214.amer.cisco.com> <4552F0907735844E9204A62BBDD325E728CB1FA4@SZXEML507-MBS.china.huawei.com> <344037D7CFEFE84E97E9CC1F56C5F4A5E3ACD9@xmb-sjc-214.amer.cisco.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 q358td6D001917 Cc: "rbridge@postel.org" Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1056919855==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org --===============1056919855== Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-Transfer-Encoding: 8bit Hi Tissa, If one tries hard to search, then he will find each solution has its drawbacks. The reluctance to deploy MT maybe a problem to MTRA, I agree with you. But, as I had pointed out in my draft, MTRA is capable to be run in the same campus and uses other solutions in the base topology. However, I need to pointed out that the reason why there are not many L3 MT is a historical one. For switches/bridges, especially when they are used in data center networks, ECMP and multi-path features are highly desired. For the benefit of the WG, I don't want to mention the names of TRILL pre-standard implementations and devices that work like TRILL from other SDOs. I think you can find examples that support MT. We can talk about this problem offline. Personally, the WG voting should not be used as a tool to endorse a solution before WG members are clear that it is workable and there are other competing solutions working for an overlapping problem space. IMHO, competing solutions should be merged or adopted as alternatives. Just as that we allow cheap local-brand cars to run on same roads along with BMWs. Let customers make choices themselves. Before the final WG decision is made, let me outline the winning advantages of MTRA for the WG members to consider. 1. MTRA is incremental deploy-able. It allows other non-MTRA RBridges exist in the same campus as transit or edge nodes. The solutions to communicate with non-MTRA are depicted in the email to Jon, you can find it. 2. MTRA realizes traffic segregation which guarantees that a LAG link failure is isolated in a specific topology. 3. MTRA is able to converge fast when there is a node/link failure of the aggregation. 4. If MT is already supported by TRILL, no extra TLVs are needed. Thanks, Mingui > -----Original Message----- > From: Tissa Senevirathne (tsenevir) [mailto:tsenevir@cisco.com] > Sent: Monday, April 02, 2012 11:14 PM > To: Mingui Zhang; Janardhanan Pathangi Narasimhan > Cc: rbridge@postel.org > Subject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > Hi Mingui > > > > You are assuming a lot. > > That is: > > 1. People will deploy Multi-topology when they need active-active > forwarding. > > 2. It is easy to deploy and people will like it > > 3. It is already out there > > > > #2 you can check % vise how many MT installations there in L3 world. > > > > Again I would summarize CMT need only one TLV, MT require lot more TLV > and require major changes to RFC6326 control plane. > > > > Backward compatibility of control plane in my world is not an issue as we are > exchanging more emails than really trying to deploy RBridges and there are no > RBridges there forwarding packets in real networks. > > > > However, your claim that MT is backward compatible without any tweaks is > false (Jana has pointed out several times). > > > > Like I have said, many times before, MT approach you have may be utilized > for active-active forwarding in MT installations. I will support that solution as > an optimization for MT, certainly I **do not** support it as the only solution > for all active-active deployments. If we agree on that then we have consensus > and both work can move forward (we need to make progress). If not then we > can continue to disagree and I request WG chairs to decide via a vote on > making CMT a WG document. > > > > > > Thanks > > Tissa > > From: Mingui Zhang [mailto:zhangmingui@huawei.com] > Sent: Monday, April 02, 2012 7:54 AM > To: Tissa Senevirathne (tsenevir); Janardhanan Pathangi Narasimhan > Cc: rbridge@postel.org > Subject: 答复: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > > > Hi Tissa, > > > > We know that RBridge Aggregation is used to increase the access capacity > without upgrade of the RBridges. The motivation is the same as the traditional > LAG: it will help customers to reduce their investment. If active-active > multi-homing can work well, customers will eager to purchase MT feature. It > may even act as a factor that promotes MT-TRILL, who knows. > > > > On the other hand, since MTRA is backward compatible, it allows other > non-MTRA solutions co-exist in the campus. These solutions work in the base > topology. These solutions may include tunneling approach. As we know, > tunneling had been widely used on traditional switches. If there are > customers who really do not like MT, just use tunneling approach or others. > > > > However, I don't think that multi-topology is that expensive. I believe you > have heard of silicons or implementations already support multi-topology > feature before 2010 when RFC 6325 was published. > > > > Thanks, > > Mingui > > > > ________________________________ > > 发件人: Tissa Senevirathne (tsenevir) [tsenevir@cisco.com] > 发送时间: 2012年4月2日 0:27 > 到: Janardhanan Pathangi Narasimhan; Mingui Zhang > Cc: rbridge@postel.org > 主题: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > Hi Mingui > > > > I have not seen an answer for the questions below could you please answer > simple question: > > > > What is your proposal for active-active for people who do not want to run > multi-topology ? > > > > From: Tissa Senevirathne (tsenevir) > Sent: Friday, March 30, 2012 1:37 AM > To: Tissa Senevirathne (tsenevir); 'Janardhanan Pathangi Narasimhan'; 'Mingui > Zhang' > Cc: 'rbridge@postel.org' > Subject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > > > Small typo correction > > > > From: Tissa Senevirathne (tsenevir) > Sent: Friday, March 30, 2012 1:25 AM > To: 'Janardhanan Pathangi Narasimhan'; Mingui Zhang > Cc: rbridge@postel.org > Subject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > > > Jana is absolutely correct on the observation below. > > > > One more point to add, as have indicated earlier > > > > 1. Not all customer will run multi-topology > > 2. You cannot force customers to run multi-topology when they need > active-active forwarding > > 3. What is your solution for customers who *do NOT* want to run > multi-topology ? > > > > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Janardhanan Pathangi Narasimhan > Sent: Friday, March 30, 2012 12:30 AM > To: Mingui Zhang > Cc: rbridge@postel.org > Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > > > Hi Mingui > > > > When you realize active-active, you are asking for the active-active to be > setup in a new topology and not the base topology. So these nodes which > need to talk to the other nodes which are behind non-MT RBridges cannot do > so any more. > > > > Specifically for MT to be backward compatible, you need all nodes which > want to talk to each other part of the base topology. If you do that you cannot > realize active-active. If you put the active-active in a new topology, than they > can no longer talk to nodes on the base topology of non-MT RBridges. > > > > So yes, MT-TRILL is backward compatible for base topology, but the realization > of active-active with MT – TRILL is not backward compatible. That was the > point I was bringing up. > > > > Thanks > > Jana > > > > > > From: Mingui Zhang [mailto:zhangmingui@huawei.com] > Sent: Friday, March 30, 2012 12:15 PM > To: Janardhanan Pathangi Narasimhan > Cc: rbridge@postel.org > Subject: 答复: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > > > Hi Jana, > > > > All RBridges in the campus are in the base topology. MT RBridges can well > communicate with non-MT RBridges using the base topology. > > > > I feel that you are arguing that MT-TRILL is not backward compatible. That is a > incorrect judgement. > > > > Thanks, > > Mingui > > ________________________________ > > 发件人: Janardhanan Pathangi Narasimhan [jana@force10networks.com] > 发送时间: 2012年3月30日 13:29 > 到: Mingui Zhang > Cc: rbridge@postel.org > 主题: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > Hi Mingui, > > > > With MT approach, when two RBridges which had stations talking to each > other and one of them is converted to MT, then the communication is broken. > So it does not have backward computability. > > > > Thanks > > Jana > > > > > > From: Mingui Zhang [mailto:zhangmingui@huawei.com] > Sent: Friday, March 30, 2012 12:27 AM > To: Janardhanan Pathangi Narasimhan > Cc: rbridge@postel.org > Subject: 答复: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > > > 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 > > --===============1056919855== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge --===============1056919855==-- From rbridge-bounces@postel.org Thu Apr 5 07:46:57 2012 Return-Path: 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 74BE521F86BE for ; Thu, 5 Apr 2012 07:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.523 X-Spam-Level: X-Spam-Status: No, score=-4.523 tagged_above=-999 required=5 tests=[AWL=2.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 INfsq7N6xtZk for ; Thu, 5 Apr 2012 07:46:56 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id A557E21F86BD for ; Thu, 5 Apr 2012 07:46:56 -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 q35ETQDY023732; Thu, 5 Apr 2012 07:29:28 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q35ESmJ7023642 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 5 Apr 2012 07:28:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tsenevir@cisco.com; l=4375; q=dns/txt; s=iport; t=1333636137; x=1334845737; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=dJhUeOJtBEziL8zz0MvJsdmxSfDuS2mXF7Ym6+5gpGI=; b=NNnhR0qFnjbmnT+RHPFSrYoE9bnDBCB7LXhFI9MvKHqItXch1ovlf7LZ 13uS48V7DYRQ87QwSroirERP4IJyW+C9td/YC72cyUBjb54Bx3vM1ieMJ qXCChgYQOCtDNnvh6Ch4r1TbExshCWkDVEfM3NlfMEoGRnP/bnxRMHee/ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAFqrfU+rRDoI/2dsb2JhbABFgka2JoEHggkBAQEEEgEJARADPhsCAQgRBAEBCwYXAQYBRQkIAQEEARIIGodrmyafeI93YwSIWZtdgWmDBw X-IronPort-AV: E=Sophos;i="4.75,375,1330905600"; d="scan'208,217";a="39206540" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 05 Apr 2012 14:28:47 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q35ESlvh009150 for ; Thu, 5 Apr 2012 14:28:47 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Apr 2012 07:28:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 5 Apr 2012 07:28:38 -0700 Message-ID: <344037D7CFEFE84E97E9CC1F56C5F4A5E3B778@xmb-sjc-214.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft Thread-Index: Ac0S8dE1/IO9r1jUIEGq/0uJDAjJ5QARooIw References: From: "Tissa Senevirathne (tsenevir)" To: "Ayan Banerjee (ayabaner)" , X-OriginalArrivalTime: 05 Apr 2012 14:28:40.0156 (UTC) FILETIME=[654269C0:01CD1338] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: tsenevir@cisco.com Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1108398677==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org This is a multi-part message in MIME format. --===============1108398677== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD1338.6526E158" This is a multi-part message in MIME format. ------_=_NextPart_001_01CD1338.6526E158 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable +1 vote in support. =20 From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Ayan Banerjee (ayabaner) Sent: Wednesday, April 04, 2012 11:03 PM To: rbridge@postel.org Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft =20 Yes, I believe that this is an important piece of the puzzle and should be made a WG document.=20 Thanks, Ayan =3D=3D=3D=3D During the TRILL session today, there was a consensus of those in the room to make draft-tissa-trill-cmt-00.txt a TRILL WG draft. This is a call on the WG mailing list to confirm that consensus. If you wish to respond, please do so by April 10th. Thanks, Donald=20 ------_=_NextPart_001_01CD1338.6526E158 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Re: [rbridge] Call for = draft-tissa-trill-cmt-00 to WG draft

+1 vote in support.

 

From:= = rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On = Behalf Of Ayan Banerjee (ayabaner)
Sent: Wednesday, April = 04, 2012 11:03 PM
To: rbridge@postel.org
Subject: = Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG = draft

 

Yes, I believe that this = is an important piece of the puzzle and should be made a WG document. =

Thanks,
Ayan
=3D=3D=3D=3D



During the TRILL = session today, there was a consensus of those in the
room to make = draft-tissa-trill-cmt-00.txt a TRILL WG draft. This is a
call on the = WG mailing list to confirm that consensus. If you wish to
respond, = please do so by April 10th.

Thanks,
Donald =

------_=_NextPart_001_01CD1338.6526E158-- --===============1108398677== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge --===============1108398677==-- From rbridge-bounces@postel.org Thu Apr 5 08:05:09 2012 Return-Path: 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 798CD21F8716 for ; Thu, 5 Apr 2012 08:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.414 X-Spam-Level: X-Spam-Status: No, score=-3.414 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] 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 33uXu1GSeAfu for ; Thu, 5 Apr 2012 08:05:07 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 7157321F8572 for ; Thu, 5 Apr 2012 08:05:07 -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 q35EbqnI024654; Thu, 5 Apr 2012 07:37:54 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q35EbAUF024599 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 5 Apr 2012 07:37:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tsenevir@cisco.com; l=25938; q=dns/txt; s=iport; t=1333636639; x=1334846239; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=3L3kMr7Yy1o+ju3RptODUTA71gMNBVje02dTYL6JaZY=; b=cXa+001BkuS4A2h8h0nU/I+mE/trt2zv4IgUcKfeIUnWewqBLrfdzHQj 81PPce815hqfl8NBueWN/geY29SHfr54TauBlwV3ShADi0Kk8EVmDIKar HfAXCZ3U40NaxKB2UAzu+BHqrjggQjsCkiQVkske5otqReOcQi3ZKPgBF k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAL6tfU+rRDoJ/2dsb2JhbABFhW+yfYEHggkBAQEEEgEHAxM1CAwMBAIBBgIRBAEBBQYGFwEEAgEgJQkIAgQBEggTB4deAwoBC5sTjQIIiQ8NiVOBK4h2hR05YwSIWY4jiiaDFIFpgweBPA X-IronPort-AV: E=Sophos;i="4.75,375,1330905600"; d="scan'208";a="39117068" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 05 Apr 2012 14:36:49 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q35EanSR010577; Thu, 5 Apr 2012 14:36:49 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Apr 2012 07:36:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 5 Apr 2012 07:36:47 -0700 Message-ID: <344037D7CFEFE84E97E9CC1F56C5F4A5E3B780@xmb-sjc-214.amer.cisco.com> In-Reply-To: <4552F0907735844E9204A62BBDD325E728CB35A1@SZXEML507-MBS.china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft Thread-Index: AQHNC6M4X8TnOZ/31Umc7no1WTsFHJZ9Cj0AgABclICAABKNgIABKjzxgAAYT0D//+PaAIAAy5WsgAAUHfCAABB74IAAKcBDgAASQ3CAAUvIPoAAP81cgAAoPaCAACBD3IAAtGNggAAT3tCAAA2IQIAADzCAgAAD9ECAA6fZcIABd2IMgAACI9CABDHOkIAAfh4Q References: <344037D7CFEFE84E97E9CC1F56C5F4A5DA0303@xmb-sjc-214.amer.cisco.com> <4552F0907735844E9204A62BBDD325E728CAD030@SZXEML507-MBS.china.huawei.com> <344037D7CFEFE84E97E9CC1F56C5F4A5DA05D7@xmb-sjc-214.amer.cisco.com> <4552F0907735844E9204A62BBDD325E728CAE193@SZXEML507-MBS.china.huawei.com> <4552F0907735844E9204A62BBDD325E728CAE2F1@SZXEML507-MBS.china.huawei.com> <4552F0907735844E9204A62BBDD325E728CAE77F@SZXEML507-MBS.china.huawei.com> <4552F0907735844E9204A62BBDD325E728CB086C@SZXEML507-MBS.china.huawei.com> <"CE35792847FBE8468 7FF9117 13 2C8EFD471 144 1520"@EXCH-CLUSTER-11.force10networks.com> <4552F0907735844E9204A62BBDD325E728CB0B20@SZXEML507-MBS.china.huawei.com> <344037D7CFEFE84E97E9CC1F56C5F4A5DA122A@xmb-sjc-214.amer.cisco.com> <4552F0907735844E9204A62BBDD325E728CB1FA4@SZXEML507-MBS.china.huawei.com> <344037D7CFEFE84E97E9CC1F56C5F4A5E3ACD9@xmb-sjc-214.amer.cisco.com> <4552F0907735844E9204A62BBDD325E728CB35A1@SZXEML507-MBS.china.huawei.com> From: "Tissa Senevirathne (tsenevir)" To: "Mingui Zhang" , "Janardhanan Pathangi Narasimhan" X-OriginalArrivalTime: 05 Apr 2012 14:36:49.0832 (UTC) FILETIME=[89210A80:01CD1339] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: tsenevir@cisco.com X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id q35EbAUF024599 Cc: rbridge@postel.org Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1869803668==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org --===============1869803668== Content-class: urn:content-classes:message Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Mingui I choose only to answer your last question on "MT is already supported in TRILL". Why are you saying that ? I do not see any RFC or WG document ? -----Original Message----- From: Mingui Zhang [mailto:zhangmingui@huawei.com] Sent: Thursday, April 05, 2012 1:53 AM To: Tissa Senevirathne (tsenevir); Janardhanan Pathangi Narasimhan Cc: rbridge@postel.org Subject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft Hi Tissa, If one tries hard to search, then he will find each solution has its drawbacks. The reluctance to deploy MT maybe a problem to MTRA, I agree with you. But, as I had pointed out in my draft, MTRA is capable to be run in the same campus and uses other solutions in the base topology. However, I need to pointed out that the reason why there are not many L3 MT is a historical one. For switches/bridges, especially when they are used in data center networks, ECMP and multi-path features are highly desired. For the benefit of the WG, I don't want to mention the names of TRILL pre-standard implementations and devices that work like TRILL from other SDOs. I think you can find examples that support MT. We can talk about this problem offline. Personally, the WG voting should not be used as a tool to endorse a solution before WG members are clear that it is workable and there are other competing solutions working for an overlapping problem space. IMHO, competing solutions should be merged or adopted as alternatives. Just as that we allow cheap local-brand cars to run on same roads along with BMWs. Let customers make choices themselves. Before the final WG decision is made, let me outline the winning advantages of MTRA for the WG members to consider. 1. MTRA is incremental deploy-able. It allows other non-MTRA RBridges exist in the same campus as transit or edge nodes. The solutions to communicate with non-MTRA are depicted in the email to Jon, you can find it. 2. MTRA realizes traffic segregation which guarantees that a LAG link failure is isolated in a specific topology. 3. MTRA is able to converge fast when there is a node/link failure of the aggregation. 4. If MT is already supported by TRILL, no extra TLVs are needed. Thanks, Mingui > -----Original Message----- > From: Tissa Senevirathne (tsenevir) [mailto:tsenevir@cisco.com] > Sent: Monday, April 02, 2012 11:14 PM > To: Mingui Zhang; Janardhanan Pathangi Narasimhan > Cc: rbridge@postel.org > Subject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > Hi Mingui > > > > You are assuming a lot. > > That is: > > 1. People will deploy Multi-topology when they need active-active > forwarding. > > 2. It is easy to deploy and people will like it > > 3. It is already out there > > > > #2 you can check % vise how many MT installations there in L3 world. > > > > Again I would summarize CMT need only one TLV, MT require lot more TLV > and require major changes to RFC6326 control plane. > > > > Backward compatibility of control plane in my world is not an issue as we are > exchanging more emails than really trying to deploy RBridges and there are no > RBridges there forwarding packets in real networks. > > > > However, your claim that MT is backward compatible without any tweaks is > false (Jana has pointed out several times). > > > > Like I have said, many times before, MT approach you have may be utilized > for active-active forwarding in MT installations. I will support that solution as > an optimization for MT, certainly I **do not** support it as the only solution > for all active-active deployments. If we agree on that then we have consensus > and both work can move forward (we need to make progress). If not then we > can continue to disagree and I request WG chairs to decide via a vote on > making CMT a WG document. > > > > > > Thanks > > Tissa > > From: Mingui Zhang [mailto:zhangmingui@huawei.com] > Sent: Monday, April 02, 2012 7:54 AM > To: Tissa Senevirathne (tsenevir); Janardhanan Pathangi Narasimhan > Cc: rbridge@postel.org > Subject: 答复: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > > > Hi Tissa, > > > > We know that RBridge Aggregation is used to increase the access capacity > without upgrade of the RBridges. The motivation is the same as the traditional > LAG: it will help customers to reduce their investment. If active-active > multi-homing can work well, customers will eager to purchase MT feature. It > may even act as a factor that promotes MT-TRILL, who knows. > > > > On the other hand, since MTRA is backward compatible, it allows other > non-MTRA solutions co-exist in the campus. These solutions work in the base > topology. These solutions may include tunneling approach. As we know, > tunneling had been widely used on traditional switches. If there are > customers who really do not like MT, just use tunneling approach or others. > > > > However, I don't think that multi-topology is that expensive. I believe you > have heard of silicons or implementations already support multi-topology > feature before 2010 when RFC 6325 was published. > > > > Thanks, > > Mingui > > > > ________________________________ > > 发件人: Tissa Senevirathne (tsenevir) [tsenevir@cisco.com] > 发送时间: 2012年4月2日 0:27 > 到: Janardhanan Pathangi Narasimhan; Mingui Zhang > Cc: rbridge@postel.org > 主题: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > Hi Mingui > > > > I have not seen an answer for the questions below could you please answer > simple question: > > > > What is your proposal for active-active for people who do not want to run > multi-topology ? > > > > From: Tissa Senevirathne (tsenevir) > Sent: Friday, March 30, 2012 1:37 AM > To: Tissa Senevirathne (tsenevir); 'Janardhanan Pathangi Narasimhan'; 'Mingui > Zhang' > Cc: 'rbridge@postel.org' > Subject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > > > Small typo correction > > > > From: Tissa Senevirathne (tsenevir) > Sent: Friday, March 30, 2012 1:25 AM > To: 'Janardhanan Pathangi Narasimhan'; Mingui Zhang > Cc: rbridge@postel.org > Subject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > > > Jana is absolutely correct on the observation below. > > > > One more point to add, as have indicated earlier > > > > 1. Not all customer will run multi-topology > > 2. You cannot force customers to run multi-topology when they need > active-active forwarding > > 3. What is your solution for customers who *do NOT* want to run > multi-topology ? > > > > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Janardhanan Pathangi Narasimhan > Sent: Friday, March 30, 2012 12:30 AM > To: Mingui Zhang > Cc: rbridge@postel.org > Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > > > Hi Mingui > > > > When you realize active-active, you are asking for the active-active to be > setup in a new topology and not the base topology. So these nodes which > need to talk to the other nodes which are behind non-MT RBridges cannot do > so any more. > > > > Specifically for MT to be backward compatible, you need all nodes which > want to talk to each other part of the base topology. If you do that you cannot > realize active-active. If you put the active-active in a new topology, than they > can no longer talk to nodes on the base topology of non-MT RBridges. > > > > So yes, MT-TRILL is backward compatible for base topology, but the realization > of active-active with MT – TRILL is not backward compatible. That was the > point I was bringing up. > > > > Thanks > > Jana > > > > > > From: Mingui Zhang [mailto:zhangmingui@huawei.com] > Sent: Friday, March 30, 2012 12:15 PM > To: Janardhanan Pathangi Narasimhan > Cc: rbridge@postel.org > Subject: 答复: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > > > Hi Jana, > > > > All RBridges in the campus are in the base topology. MT RBridges can well > communicate with non-MT RBridges using the base topology. > > > > I feel that you are arguing that MT-TRILL is not backward compatible. That is a > incorrect judgement. > > > > Thanks, > > Mingui > > ________________________________ > > 发件人: Janardhanan Pathangi Narasimhan [jana@force10networks.com] > 发送时间: 2012年3月30日 13:29 > 到: Mingui Zhang > Cc: rbridge@postel.org > 主题: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > Hi Mingui, > > > > With MT approach, when two RBridges which had stations talking to each > other and one of them is converted to MT, then the communication is broken. > So it does not have backward computability. > > > > Thanks > > Jana > > > > > > From: Mingui Zhang [mailto:zhangmingui@huawei.com] > Sent: Friday, March 30, 2012 12:27 AM > To: Janardhanan Pathangi Narasimhan > Cc: rbridge@postel.org > Subject: 答复: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > > > 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 > > --===============1869803668== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge --===============1869803668==-- From rbridge-bounces@postel.org Thu Apr 5 08:34:04 2012 Return-Path: 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 EB4AF21F870E for ; Thu, 5 Apr 2012 08:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] 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 RnOcSl5RoHgG for ; Thu, 5 Apr 2012 08:34:03 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE3621F870B for ; Thu, 5 Apr 2012 08:34:03 -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 q35FFLkP000615; Thu, 5 Apr 2012 08:15:22 -0700 (PDT) Received: from mail-pz0-f41.google.com (mail-pz0-f41.google.com [209.85.210.41]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q35FEpfR000543 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 5 Apr 2012 08:15:00 -0700 (PDT) Received: by dajx4 with SMTP id x4so1996967daj.0 for ; Thu, 05 Apr 2012 08:14:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=svjrsn+zm8amKyPWNux2CUBgy8SYuANTdh4CcovgcvI=; b=cR3FUGtY/1DiXzonzvtDgzn91c6jZCmTwR2W5EGWchT7y9znX+bsAvA0dgKM7HM8j1 EkP9RjPRR3miQz8ncBhTozTAdxnOcRKDI83AvfzSKPn//WtPK1vz1IZdqNyGaqzYX83X 045Sq7GvRZvkvjNvGqt8cs5QJgZcEW4xwiNUC5LRMCxIL2KL7T1EGH2HT53pFwBWYbz7 8fRIPYRRYhbrBTP3JKv50xixvwd8V+FjWrh3LfJtudsUWxC+ojyRDZP5WtJ8tsQulzGt S4S5fyUD3HDSJogbpTSsSDaiKAXlMWmM2N6mIrdhjznotCeWAsgwrISm7VTY5jTxuRMp tPqQ== Received: by 10.68.197.39 with SMTP id ir7mr8166309pbc.17.1333638890888; Thu, 05 Apr 2012 08:14:50 -0700 (PDT) Received: from [192.168.1.5] (c-107-3-156-34.hsd1.ca.comcast.net. [107.3.156.34]) by mx.google.com with ESMTPS id b10sm3498807pbr.46.2012.04.05.08.14.44 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Apr 2012 08:14:44 -0700 (PDT) References: <344037D7CFEFE84E97E9CC1F56C5F4A5E3B778@xmb-sjc-214.amer.cisco.com> In-Reply-To: <344037D7CFEFE84E97E9CC1F56C5F4A5E3B778@xmb-sjc-214.amer.cisco.com> Mime-Version: 1.0 (1.0) Message-Id: X-Mailer: iPad Mail (9B176) From: Sam Aldrin Date: Thu, 5 Apr 2012 08:14:43 -0700 To: "Tissa Senevirathne (tsenevir)" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: aldrin.ietf@gmail.com Cc: "" Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0456448998==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org --===============0456448998== Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-A64009DF-5F55-4FFC-B07F-214B60D5A65B --Apple-Mail-A64009DF-5F55-4FFC-B07F-214B60D5A65B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I support this draft to be adopted as WG document. The solution proposed is least overhead and doesn't require unnecessary over= head of deploying certain topology. The arguments raised against thus far do= not provide much simpler solution by any means.=20 Cheers Sam Sent from my iPad On Apr 5, 2012, at 7:28 AM, "Tissa Senevirathne (tsenevir)" wrote: > +1 vote in support. > =20 > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Be= half Of Ayan Banerjee (ayabaner) > Sent: Wednesday, April 04, 2012 11:03 PM > To: rbridge@postel.org > Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > =20 > Yes, I believe that this is an important piece of the puzzle and should be= made a WG document.=20 >=20 > Thanks, > Ayan > =3D=3D=3D=3D >=20 >=20 >=20 > During the TRILL session today, there was a consensus of those in the > room to make draft-tissa-trill-cmt-00.txt a TRILL WG draft. This is a > call on the WG mailing list to confirm that consensus. If you wish to > respond, please do so by April 10th. >=20 > Thanks, > Donald > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge --Apple-Mail-A64009DF-5F55-4FFC-B07F-214B60D5A65B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I support this draft to be= adopted as WG document.
The solution proposed is least overhead a= nd doesn't require unnecessary overhead of deploying certain topology. The a= rguments raised against thus far do not provide much simpler solution by any= means. 

Cheers
Sam
Sent from my iPad
On Apr 5, 2012, at 7:28 AM, "Tissa Senevirathne (tsenevir)" <tsenevir@cisco.com> wrote:

Re: [rbridge] Call for draft-tis= sa-trill-cmt-00 to WG draft

+1 vote in support.

=

 

 

Yes, I believ= e that this is an important piece of the puzzle and should be made a WG docu= ment.

Thanks,
Ayan
=3D=3D=3D=3D



During the TRIL= L session today, there was a consensus of those in the
room to make draft= -tissa-trill-cmt-00.txt a TRILL WG draft. This is a
call on the WG mailin= g list to confirm that consensus. If you wish to
respond, please do so by= April 10th.

Thanks,
Donald

______________________________= _________________
rbridge mailing list
rbridge@postel.org
http://mailman.po= stel.org/mailman/listinfo/rbridge
= --Apple-Mail-A64009DF-5F55-4FFC-B07F-214B60D5A65B-- --===============0456448998== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge --===============0456448998==-- From rbridge-bounces@postel.org Thu Apr 5 08:42:21 2012 Return-Path: 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 E8CC421F8698 for ; Thu, 5 Apr 2012 08:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.799 X-Spam-Level: X-Spam-Status: No, score=-104.799 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 1DC3eYHOU0AD for ; Thu, 5 Apr 2012 08:42:21 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id F19D521F8598 for ; Thu, 5 Apr 2012 08:42:20 -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 q35FRFsf002414; Thu, 5 Apr 2012 08:27:17 -0700 (PDT) Received: from mail-lpp01m010-f52.google.com (mail-lpp01m010-f52.google.com [209.85.215.52]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q35FQvO0002351 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 5 Apr 2012 08:27:07 -0700 (PDT) Received: by lahi5 with SMTP id i5so3012938lah.39 for ; Thu, 05 Apr 2012 08:26:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=8XG38rXJ9vMLGLPHafNwVlQW6VCuJRchxipvRjtnH80=; b=mkYsEaj6p6U++3g1EDEIt7Xsxhvtr+rbSCn4nsnVUTY3jxylbZBZaZEbxUzK/+a+5x zDsXx4nVG2BEGN1cdY3skQ3oXZHus9tjvuCRGep4/t4b1GAq2yThQDnKGbwVxpgqfMo8 i9gfmpZFbZy7EMPhzT0w99bz1PEtzptiNFwn2PDKFNZgm8gtGMMrTIjduu+ihJfgWEcy jD9nNGvq96BqHO4HM/R4cAeKSsv4m/0hRDRSsAq7wAy1di1nLh0HjxKLzyvmgtWpaH7H fc8LsBgDm9SQ/hfqpsvft1zcRs7F5z8DHftrcRKjujsrK2qXdzpomSgcR/3jGR0CugUj pAeg== Received: by 10.152.131.74 with SMTP id ok10mr3654639lab.17.1333639616318; Thu, 05 Apr 2012 08:26:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.162 with HTTP; Thu, 5 Apr 2012 08:26:35 -0700 (PDT) In-Reply-To: References: From: Donald Eastlake Date: Thu, 5 Apr 2012 11:26:35 -0400 Message-ID: To: Muhammad Mohsin Sardar X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: d3e3e3@gmail.com X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id q35FQvO0002351 Cc: rbridge@postel.org Subject: Re: [rbridge] TRILL control frames communication X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org Hi Muhammad, On Thu, Apr 5, 2012 at 1:55 AM, Muhammad Mohsin Sardar wrote: > Hi! > > Given in RFC6325 section 4.2.3 > TRILL IS-IS frames are never forwarded by an RBridge but are locally > processed on receipt.=A0 (Such processing may cause the RBridge to send > additional TRILL IS-IS frames.) > Given in RFC6325 section 4.6.2 > 1. If the Outer.MacDA is All-IS-IS-RBridges and the Ethertype is L2-IS-IS, > the frame is handled as described in Section 4.6.2.1. > 4.6.2.1. TRILL Control Frames: The frame is processed by the TRILL IS-IS > instance on RBn and is not forwarded. > > As IS-IS frames are never forwarded by an RBridge, why All-IS-IS-RBridges > multicast address is used? Please clarify. The All-IS-IS-RBridges multicast Ethernet address is used on Ethernet links to be sure that the frame reaches all the interfaces on the link. Keep in mind that in TRILL terms a "link" can be a bridged LAN. TRILL has always supported multi-access links. > As per my understanding TRILL IIH frames are sent to the neighbors, > bounded by RBridges ( Broadcast domain is link) Am I right? Bounded by RBridges, Layer 3 routers, and end stations. Your figure below was garbled in transmission. Trying to send wide ASCII art through email is not such a good idea... I've attempted to reconstruct it narrower below and have also added RB5. +-----+ +-------+ +-------+ +-------+ +------+ +-----+ | ESa +--+ RB1 +--+ RB3 +--+--+ RB4 +--+ RB2 +--+ ESb | | | |ingress| |transit| | |transit| |egress| | | +-----+ +-------+ +-------+ | +-------+ +------+ +-----+ | +-+-+ |RB5| +---+ > If all RBridges are just up, following pattern will be followed: > RB1 send TRILL IIH to RB3 > RB2 send TRILL IIH to RB4 > RB3 send TRILL IIH to RB1 and RB4 > RB4 send TRILL IIH to RB2 and RB3 > Please correct me, if I am misinterpreting it. RB1 also sends Hellos to ESa and RB2 also sends Hellos to ESb. Beause Ethernet supports multi-access links and the Hellos are sent to a multicast address, in my expanded version of your diagram, Hellos sent by RB3 on the link it shares with RB4 are also delivered to RB5, Hellos sent by RB4 on that link are also delivered to RB5, and Hellos send by RB5 are delivered to both RB3 and RB4. It does not matter particulrly if the link connecting RB3, RB4, and RB5 is some inherently multi-access technology or perhaps consists of three point-to-point physical Ethernet links connected by a bridge or whatever. > TRILL IS-IS LSP's are used to communicate the link information to > the campus. That's how, RBridges know each other. > As RBridges do not forward TRILL IS-IS frames, how information > (TRILL IS-IS LSP) of RB1 is communicated to RB2? "not forward" just means that the frames are not automatically forwarded at a low level. If every RBridge that received an LSP immediately forwarded it out all of its ports, other than the one it received it on, for any non-tree topology you would quickly find your network saturated with loooping LSPs. The ISO standard update process for the link state database is described in Section 7.3 of ISO/IEC 10589-2002. The techniques used in Layer 3 IS-IS are generally applicable to TRILL. Commonly, if an LSP is received that is not a duplicate of one alrady held by the RBridge it will be stored in the link state database and flags are set so it will be promptly forwarded. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com > Thank you! > > -- > Best Regards, > Muhammad Mohsin Sardar _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge From rbridge-bounces@postel.org Thu Apr 5 09:54:29 2012 Return-Path: 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 DB5A521F86F5 for ; Thu, 5 Apr 2012 09:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.376 X-Spam-Level: X-Spam-Status: No, score=-5.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4] 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 IuJIQVFlGJGu for ; Thu, 5 Apr 2012 09:54:28 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id D73FB21F86E1 for ; Thu, 5 Apr 2012 09:54:28 -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 q35Gqqg2017804; Thu, 5 Apr 2012 09:52:53 -0700 (PDT) Received: from mail-iy0-f180.google.com (mail-iy0-f180.google.com [209.85.210.180]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q35GqJ1o017751 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 5 Apr 2012 09:52:28 -0700 (PDT) Received: by iage36 with SMTP id e36so3369786iag.39 for ; Thu, 05 Apr 2012 09:52:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=za9sC7CgPZpXJameMdhUPi/thWZ2m+IC5DQkrI5LT8k=; b=jFMn88OX4bOcMgf5119OEAKlLJhjAVuKaVZZfXiKGkn62Gmt18syLD6aL517+VL8WS 7xX7HRf4rfBfOctKoCkfU90cKBzq3b8JgdpnRB5XjwuiM5sIElSlkhRhNQwalJ5VO/bx FPHcI5k7wvQ1elqRaxqxqsrUPGpMxEqfNpqFNft3XHBjx1Mrvssivv5gXXt/raKIU0Hx PmNAyp1tw/p7r4XwiLn7MnlzaDeGdoVglumiPs1dSxzdiN0mq+t5+3QZpNw1izXtknv9 ULK9MYmhgFG5WPbwp2r1rRXDboQt6QQCJxacjfFXbEXA2vaEEYdJVgt+ybKu42+BxGa6 n2ag== Received: by 10.42.144.201 with SMTP id c9mr2495901icv.29.1333644739130; Thu, 05 Apr 2012 09:52:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.30.195 with HTTP; Thu, 5 Apr 2012 09:51:58 -0700 (PDT) In-Reply-To: References: From: Muhammad Mohsin Sardar Date: Thu, 5 Apr 2012 21:51:58 +0500 Message-ID: To: Donald Eastlake X-Gm-Message-State: ALoCoQnV1CrixtH5ElqQytwmQm/Cbrf9fq4IipEXFpkJ9hzdYQ6RxmVMRNWsRL6AnnIpM/gXUvd2 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: mohsin.sardar@seecs.edu.pk Cc: rbridge@postel.org Subject: Re: [rbridge] TRILL control frames communication X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0308308949==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org --===============0308308949== Content-Type: multipart/alternative; boundary=90e6ba6e8a18eeb50104bcf15cd4 --90e6ba6e8a18eeb50104bcf15cd4 Content-Type: text/plain; charset=ISO-8859-1 Thanks Donald! On Thu, Apr 5, 2012 at 8:26 PM, Donald Eastlake wrote: > Hi Muhammad, > > On Thu, Apr 5, 2012 at 1:55 AM, Muhammad Mohsin Sardar > wrote: > > > Hi! > > > > Given in RFC6325 section 4.2.3 > > TRILL IS-IS frames are never forwarded by an RBridge but are locally > > processed on receipt. (Such processing may cause the RBridge to send > > additional TRILL IS-IS frames.) > > Given in RFC6325 section 4.6.2 > > 1. If the Outer.MacDA is All-IS-IS-RBridges and the Ethertype is > L2-IS-IS, > > the frame is handled as described in Section 4.6.2.1. > > 4.6.2.1. TRILL Control Frames: The frame is processed by the TRILL IS-IS > > instance on RBn and is not forwarded. > > > > As IS-IS frames are never forwarded by an RBridge, why All-IS-IS-RBridges > > multicast address is used? Please clarify. > > The All-IS-IS-RBridges multicast Ethernet address is used on Ethernet > links to be sure that the frame reaches all the interfaces on the > link. Keep in mind that in TRILL terms a "link" can be a bridged LAN. > TRILL has always supported multi-access links. > > > As per my understanding TRILL IIH frames are sent to the neighbors, > > bounded by RBridges ( Broadcast domain is link) Am I right? > > Bounded by RBridges, Layer 3 routers, and end stations. > > Your figure below was garbled in transmission. Trying to send wide > ASCII art through email is not such a good idea... I've attempted to > reconstruct it narrower below and have also added RB5. > > +-----+ +-------+ +-------+ +-------+ +------+ +-----+ > | ESa +--+ RB1 +--+ RB3 +--+--+ RB4 +--+ RB2 +--+ ESb | > | | |ingress| |transit| | |transit| |egress| | | > +-----+ +-------+ +-------+ | +-------+ +------+ +-----+ > | > +-+-+ > |RB5| > +---+ > > > If all RBridges are just up, following pattern will be followed: > > RB1 send TRILL IIH to RB3 > > RB2 send TRILL IIH to RB4 > > RB3 send TRILL IIH to RB1 and RB4 > > RB4 send TRILL IIH to RB2 and RB3 > > Please correct me, if I am misinterpreting it. > > RB1 also sends Hellos to ESa and RB2 also sends Hellos to ESb. Beause > Ethernet supports multi-access links and the Hellos are sent to a > multicast address, in my expanded version of your diagram, Hellos sent > by RB3 on the link it shares with RB4 are also delivered to RB5, > Hellos sent by RB4 on that link are also delivered to RB5, and Hellos > send by RB5 are delivered to both RB3 and RB4. It does not matter > particulrly if the link connecting RB3, RB4, and RB5 is some > inherently multi-access technology or perhaps consists of three > point-to-point physical Ethernet links connected by a bridge or > whatever. > > > TRILL IS-IS LSP's are used to communicate the link information to > > the campus. That's how, RBridges know each other. > > As RBridges do not forward TRILL IS-IS frames, how information > > (TRILL IS-IS LSP) of RB1 is communicated to RB2? > > "not forward" just means that the frames are not automatically > forwarded at a low level. If every RBridge that received an LSP > immediately forwarded it out all of its ports, other than the one it > received it on, for any non-tree topology you would quickly find your > network saturated with loooping LSPs. The ISO standard update process > for the link state database is described in Section 7.3 of ISO/IEC > 10589-2002. The techniques used in Layer 3 IS-IS are generally > applicable to TRILL. Commonly, if an LSP is received that is not a > duplicate of one alrady held by the RBridge it will be stored in the > link state database and flags are set so it will be promptly > forwarded. > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > > > Thank you! > > > > -- > > Best Regards, > > Muhammad Mohsin Sardar > -- Best Regards, Muhammad Mohsin Sardar --90e6ba6e8a18eeb50104bcf15cd4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Donald!

On Thu, Apr 5, 2012 at 8:2= 6 PM, Donald Eastlake <d3e3e3@gmail.com> wrote:
Hi Muhammad,

On Thu, Apr 5, 2012 at 1:55 AM, Muhammad Mohsin Sardar
<mohsin.sardar@seecs.edu.p= k> wrote:

> Hi!
>
> Given in RFC6325 section 4.2.3
> TRILL IS-IS frames are never forwarded by an RBridge but are locally > processed on receipt.=A0 (Such processing may cause the RBridge to sen= d
> additional TRILL IS-IS frames.)
> Given in RFC6325 section 4.6.2
> 1. If the Outer.MacDA is All-IS-IS-RBridges and the Ethertype is L2-IS= -IS,
> the frame is handled as described in Section 4.6.2.1.
> 4.6.2.1. TRILL Control Frames: The frame is processed by the TRILL IS-= IS
> instance on RBn and is not forwarded.
>
> As IS-IS frames are never forwarded by an RBridge, why All-IS-IS-RBrid= ges
> multicast address is used? Please clarify.

The All-IS-IS-RBridges multicast Ethernet address is used on Ethernet=
links to be sure that the frame reaches all the interfaces on the
link. Keep in mind that in TRILL terms a "link" can be a bridged = LAN.
TRILL has always supported multi-access links.

> As per my understanding TRILL IIH frames are sent to the neighbors, > bounded by RBridges ( Broadcast domain is link) Am I right?

Bounded by RBridges, Layer 3 routers, and end stations.

Your figure below was garbled in transmission. Trying to send wide
ASCII art through email is not such a good idea... I've attempted to reconstruct it narrower below and have also added RB5.

+-----+ =A0+-------+ =A0+-------+ =A0 =A0 +-------+ =A0+------+ =A0+-----+<= br> | ESa +--+ RB1 =A0 +--+ RB3 =A0 +--+--+ RB4 =A0 +--+ RB2 =A0+--+ ESb |
| =A0 =A0 | =A0|ingress| =A0|transit| =A0| =A0|transit| =A0|egress| =A0| = =A0 =A0 |
+-----+ =A0+-------+ =A0+-------+ =A0| =A0+-------+ =A0+------+ =A0+-----+<= br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +-+-+
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |RB5|
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = +---+

> If all RBridges are just up, following pattern will be followed:
> RB1 send TRILL IIH to RB3
> RB2 send TRILL IIH to RB4
> RB3 send TRILL IIH to RB1 and RB4
> RB4 send TRILL IIH to RB2 and RB3
> Please correct me, if I am misinterpreting it.

RB1 also sends Hellos to ESa and RB2 also sends Hellos to ESb. Beause=
Ethernet supports multi-access links and the Hellos are sent to a
multicast address, in my expanded version of your diagram, Hellos sent
by RB3 on the link it shares with RB4 are also delivered to RB5,
Hellos sent by RB4 on that link are also delivered to RB5, and Hellos
send by RB5 are delivered to both RB3 and RB4. It does not matter
particulrly if the link connecting RB3, RB4, and RB5 is some
inherently multi-access technology or perhaps consists of three
point-to-point physical Ethernet links connected by a bridge or
whatever.

> TRILL IS-IS LSP's are used to communicate the link information to<= br> > the campus. That's how, RBridges know each other.
> As RBridges do not forward TRILL IS-IS frames, how information
> (TRILL IS-IS LSP) of RB1 is communicated to RB2?

"not forward" just means that the frames are not automatica= lly
forwarded at a low level. If every RBridge that received an LSP
immediately forwarded it out all of its ports, other than the one it
received it on, for any non-tree topology you would quickly find your
network saturated with loooping LSPs. The ISO standard update process
for the link state database is described in Section 7.3 of ISO/IEC
10589-2002. The techniques used in Layer 3 IS-IS are generally
applicable to TRILL. Commonly, if an LSP is received that is not a
duplicate of one alrady held by the RBridge it will be stored in the
link state database and flags are set so it will be promptly
forwarded.

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
=A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell)
=A0155 Beaver Street,=A0Milford, MA 01757 USA
=A0d3e3e3@gmail.com

> Thank you!
>
> --
> Best Regards,
> Muhammad Mohsin Sardar



--
Best Regard= s,
Muhammad Mohsin Sardar
--90e6ba6e8a18eeb50104bcf15cd4-- --===============0308308949== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge --===============0308308949==-- From rbridge-bounces@postel.org Thu Apr 5 10:32:50 2012 Return-Path: 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 F17CF21F876C for ; Thu, 5 Apr 2012 10:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4] 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 C1dveULu8CRL for ; Thu, 5 Apr 2012 10:32:48 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 1B07F21F8766 for ; Thu, 5 Apr 2012 10:32:48 -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 q35HBUoN021410; Thu, 5 Apr 2012 10:11:31 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q35HAcjU021327 for ; Thu, 5 Apr 2012 10:10:47 -0700 (PDT) Received: from [10.16.192.232] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Thu, 05 Apr 2012 10:20:38 -0700 X-Server-Uuid: 72204117-5C29-4314-8910-60DB108979CB Received: from SJEXCHCAS01.corp.ad.broadcom.com (10.16.192.31) by SJEXCHHUB02.corp.ad.broadcom.com (10.16.192.232) with Microsoft SMTP Server (TLS) id 8.2.247.2; Thu, 5 Apr 2012 10:10:23 -0700 Received: from SJEXCHMB05.corp.ad.broadcom.com ( [fe80::4ccf:d24d:fe6c:9594]) by sjexchcas01.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Thu, 5 Apr 2012 10:10:22 -0700 From: "Naveen Nimmu" To: "rbridge@postel.org" Thread-Topic: rbridge Digest, Vol 95, Issue 11 Thread-Index: AQHNEzv6VPXGiiImbEuMgGVb3iRs0ZaMdy9S Date: Thu, 5 Apr 2012 17:10:21 +0000 Message-ID: <8FCD488658FD4040A3A2279ABA0AD48305611A@SJEXCHMB05.corp.ad.broadcom.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.9.208.53] MIME-Version: 1.0 X-WSS-ID: 63630BEC3IO1251926-03-01 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: naveen@broadcom.com X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id q35HAcjU021327 Subject: Re: [rbridge] rbridge Digest, Vol 95, Issue 11 X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org +1 vote to make it WG document. Thanks naveen ________________________________________ From: rbridge-bounces@postel.org [rbridge-bounces@postel.org] on behalf of rbridge-request@postel.org [rbridge-request@postel.org] Sent: Thursday, April 05, 2012 8:07 PM To: rbridge@postel.org Subject: rbridge Digest, Vol 95, Issue 11 Send rbridge mailing list submissions to rbridge@postel.org To subscribe or unsubscribe via the World Wide Web, visit http://mailman.postel.org/mailman/listinfo/rbridge or, via email, send a message with subject or body 'help' to rbridge-request@postel.org You can reach the person managing the list at rbridge-owner@postel.org When replying, please edit your Subject line so it is more specific than "Re: Contents of rbridge digest..." Today's Topics: 1. Re: Call for draft-tissa-trill-cmt-00 to WG draft (Tissa Senevirathne (tsenevir)) 2. Re: Call for draft-tissa-trill-cmt-00 to WG draft (Tissa Senevirathne (tsenevir)) ---------------------------------------------------------------------- Message: 1 Date: Thu, 5 Apr 2012 07:28:38 -0700 From: "Tissa Senevirathne (tsenevir)" Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft To: "Ayan Banerjee (ayabaner)" , Message-ID: <344037D7CFEFE84E97E9CC1F56C5F4A5E3B778@xmb-sjc-214.amer.cisco.com> Content-Type: text/plain; charset="us-ascii" +1 vote in support. From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Ayan Banerjee (ayabaner) Sent: Wednesday, April 04, 2012 11:03 PM To: rbridge@postel.org Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft Yes, I believe that this is an important piece of the puzzle and should be made a WG document. Thanks, Ayan ==== During the TRILL session today, there was a consensus of those in the room to make draft-tissa-trill-cmt-00.txt a TRILL WG draft. This is a call on the WG mailing list to confirm that consensus. If you wish to respond, please do so by April 10th. Thanks, Donald -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20120405/f43f46e0/attachment-0001.html ------------------------------ Message: 2 Date: Thu, 5 Apr 2012 07:36:47 -0700 From: "Tissa Senevirathne (tsenevir)" Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft To: "Mingui Zhang" , "Janardhanan Pathangi Narasimhan" Cc: rbridge@postel.org Message-ID: <344037D7CFEFE84E97E9CC1F56C5F4A5E3B780@xmb-sjc-214.amer.cisco.com> Content-Type: text/plain; charset="gb2312" Mingui I choose only to answer your last question on "MT is already supported in TRILL". Why are you saying that ? I do not see any RFC or WG document ? -----Original Message----- From: Mingui Zhang [mailto:zhangmingui@huawei.com] Sent: Thursday, April 05, 2012 1:53 AM To: Tissa Senevirathne (tsenevir); Janardhanan Pathangi Narasimhan Cc: rbridge@postel.org Subject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft Hi Tissa, If one tries hard to search, then he will find each solution has its drawbacks. The reluctance to deploy MT maybe a problem to MTRA, I agree with you. But, as I had pointed out in my draft, MTRA is capable to be run in the same campus and uses other solutions in the base topology. However, I need to pointed out that the reason why there are not many L3 MT is a historical one. For switches/bridges, especially when they are used in data center networks, ECMP and multi-path features are highly desired. For the benefit of the WG, I don't want to mention the names of TRILL pre-standard implementations and devices that work like TRILL from other SDOs. I think you can find examples that support MT. We can talk about this problem offline. Personally, the WG voting should not be used as a tool to endorse a solution before WG members are clear that it is workable and there are other competing solutions working for an overlapping problem space. IMHO, competing solutions should be merged or adopted as alternatives. Just as that we allow cheap local-brand cars to run on same roads along with BMWs. Let customers make choices themselves. Before the final WG decision is made, let me outline the winning advantages of MTRA for the WG members to consider. 1. MTRA is incremental deploy-able. It allows other non-MTRA RBridges exist in the same campus as transit or edge nodes. The solutions to communicate with non-MTRA are depicted in the email to Jon, you can find it. 2. MTRA realizes traffic segregation which guarantees that a LAG link failure is isolated in a specific topology. 3. MTRA is able to converge fast when there is a node/link failure of the aggregation. 4. If MT is already supported by TRILL, no extra TLVs are needed. Thanks, Mingui > -----Original Message----- > From: Tissa Senevirathne (tsenevir) [mailto:tsenevir@cisco.com] > Sent: Monday, April 02, 2012 11:14 PM > To: Mingui Zhang; Janardhanan Pathangi Narasimhan > Cc: rbridge@postel.org > Subject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > Hi Mingui > > > > You are assuming a lot. > > That is: > > 1. People will deploy Multi-topology when they need active-active > forwarding. > > 2. It is easy to deploy and people will like it > > 3. It is already out there > > > > #2 you can check % vise how many MT installations there in L3 world. > > > > Again I would summarize CMT need only one TLV, MT require lot more TLV > and require major changes to RFC6326 control plane. > > > > Backward compatibility of control plane in my world is not an issue as we are > exchanging more emails than really trying to deploy RBridges and there are no > RBridges there forwarding packets in real networks. > > > > However, your claim that MT is backward compatible without any tweaks is > false (Jana has pointed out several times). > > > > Like I have said, many times before, MT approach you have may be utilized > for active-active forwarding in MT installations. I will support that solution as > an optimization for MT, certainly I **do not** support it as the only solution > for all active-active deployments. If we agree on that then we have consensus > and both work can move forward (we need to make progress). If not then we > can continue to disagree and I request WG chairs to decide via a vote on > making CMT a WG document. > > > > > > Thanks > > Tissa > > From: Mingui Zhang [mailto:zhangmingui@huawei.com] > Sent: Monday, April 02, 2012 7:54 AM > To: Tissa Senevirathne (tsenevir); Janardhanan Pathangi Narasimhan > Cc: rbridge@postel.org > Subject: ????: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > > > Hi Tissa, > > > > We know that RBridge Aggregation is used to increase the access capacity > without upgrade of the RBridges. The motivation is the same as the traditional > LAG: it will help customers to reduce their investment. If active-active > multi-homing can work well, customers will eager to purchase MT feature. It > may even act as a factor that promotes MT-TRILL, who knows. > > > > On the other hand, since MTRA is backward compatible, it allows other > non-MTRA solutions co-exist in the campus. These solutions work in the base > topology. These solutions may include tunneling approach. As we know, > tunneling had been widely used on traditional switches. If there are > customers who really do not like MT, just use tunneling approach or others. > > > > However, I don't think that multi-topology is that expensive. I believe you > have heard of silicons or implementations already support multi-topology > feature before 2010 when RFC 6325 was published. > > > > Thanks, > > Mingui > > > > ________________________________ > > ??????: Tissa Senevirathne (tsenevir) [tsenevir@cisco.com] > ????????: 2012??4??2?? 0:27 > ??: Janardhanan Pathangi Narasimhan; Mingui Zhang > Cc: rbridge@postel.org > ????: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > Hi Mingui > > > > I have not seen an answer for the questions below could you please answer > simple question: > > > > What is your proposal for active-active for people who do not want to run > multi-topology ? > > > > From: Tissa Senevirathne (tsenevir) > Sent: Friday, March 30, 2012 1:37 AM > To: Tissa Senevirathne (tsenevir); 'Janardhanan Pathangi Narasimhan'; 'Mingui > Zhang' > Cc: 'rbridge@postel.org' > Subject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > > > Small typo correction > > > > From: Tissa Senevirathne (tsenevir) > Sent: Friday, March 30, 2012 1:25 AM > To: 'Janardhanan Pathangi Narasimhan'; Mingui Zhang > Cc: rbridge@postel.org > Subject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > > > Jana is absolutely correct on the observation below. > > > > One more point to add, as have indicated earlier > > > > 1. Not all customer will run multi-topology > > 2. You cannot force customers to run multi-topology when they need > active-active forwarding > > 3. What is your solution for customers who *do NOT* want to run > multi-topology ? > > > > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Janardhanan Pathangi Narasimhan > Sent: Friday, March 30, 2012 12:30 AM > To: Mingui Zhang > Cc: rbridge@postel.org > Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > > > Hi Mingui > > > > When you realize active-active, you are asking for the active-active to be > setup in a new topology and not the base topology. So these nodes which > need to talk to the other nodes which are behind non-MT RBridges cannot do > so any more. > > > > Specifically for MT to be backward compatible, you need all nodes which > want to talk to each other part of the base topology. If you do that you cannot > realize active-active. If you put the active-active in a new topology, than they > can no longer talk to nodes on the base topology of non-MT RBridges. > > > > So yes, MT-TRILL is backward compatible for base topology, but the realization > of active-active with MT ?C TRILL is not backward compatible. That was the > point I was bringing up. > > > > Thanks > > Jana > > > > > > From: Mingui Zhang [mailto:zhangmingui@huawei.com] > Sent: Friday, March 30, 2012 12:15 PM > To: Janardhanan Pathangi Narasimhan > Cc: rbridge@postel.org > Subject: ????: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > > > Hi Jana, > > > > All RBridges in the campus are in the base topology. MT RBridges can well > communicate with non-MT RBridges using the base topology. > > > > I feel that you are arguing that MT-TRILL is not backward compatible. That is a > incorrect judgement. > > > > Thanks, > > Mingui > > ________________________________ > > ??????: Janardhanan Pathangi Narasimhan [jana@force10networks.com] > ????????: 2012??3??30?? 13:29 > ??: Mingui Zhang > Cc: rbridge@postel.org > ????: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > Hi Mingui, > > > > With MT approach, when two RBridges which had stations talking to each > other and one of them is converted to MT, then the communication is broken. > So it does not have backward computability. > > > > Thanks > > Jana > > > > > > From: Mingui Zhang [mailto:zhangmingui@huawei.com] > Sent: Friday, March 30, 2012 12:27 AM > To: Janardhanan Pathangi Narasimhan > Cc: rbridge@postel.org > Subject: ????: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > > > 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 End of rbridge Digest, Vol 95, Issue 11 *************************************** _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge From rbridge-bounces@postel.org Thu Apr 5 10:53:51 2012 Return-Path: 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 D928621F875D for ; Thu, 5 Apr 2012 10:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.476 X-Spam-Level: X-Spam-Status: No, score=-4.476 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 0PUDStjYplpk for ; Thu, 5 Apr 2012 10:53:51 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 3302221F874F for ; Thu, 5 Apr 2012 10:53:51 -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 q35HpWrT028980; Thu, 5 Apr 2012 10:51:33 -0700 (PDT) Received: from mail-pb0-f52.google.com (mail-pb0-f52.google.com [209.85.160.52]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q35HowgY028920 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 5 Apr 2012 10:51:07 -0700 (PDT) Received: by pbcuo15 with SMTP id uo15so2302747pbc.39 for ; Thu, 05 Apr 2012 10:50:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=baP9IzATz8ZJy9165DXUllPwWN/SRvff1Tb1VZxXaj8=; b=umezR6XNLOwEFeEaXCpAsUsIAbKiuF6OpkMCDUC82rXKYG8OjTRClpiVHECia1MPwG DaE8mOh5X1jDMff0pXZjVK6EwgbZlu8LstQkxdhnD/xeTkvfTtLVzjCEZfReDnQAiazR Hcdju5x07dbOEYSvUhY2BcoUIjp1n26fixgIXth9ivAWm1Xs3WfdC1WYcJtw24yxAUrL kwCHFlHzh2xwEadp4y0tA5hcqG7VEEZejYlQ1g8/YE4hsek79C0T5mtKGwKEa/YtCpBS 8hH1qit3GvNmDPMb+rFrrzhT6DheWicsxeiRvzerk1lFbxs7RRm23wdudErVR82Z0S7U ceDg== MIME-Version: 1.0 Received: by 10.68.74.197 with SMTP id w5mr8561545pbv.129.1333648258218; Thu, 05 Apr 2012 10:50:58 -0700 (PDT) Received: by 10.143.5.20 with HTTP; Thu, 5 Apr 2012 10:50:57 -0700 (PDT) In-Reply-To: References: Date: Thu, 5 Apr 2012 10:50:57 -0700 X-Google-Sender-Auth: wg-zbsfRNGtP2W-kelt_NGnqMk8 Message-ID: From: Anoop Ghanwani To: Donald Eastlake X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: ghanwani@gmail.com Cc: rbridge@postel.org Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1443162309==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org --===============1443162309== Content-Type: multipart/alternative; boundary=f46d040fa1e8afb95204bcf22ed7 --f46d040fa1e8afb95204bcf22ed7 Content-Type: text/plain; charset=ISO-8859-1 I support making this document a WG draft. Anoop On Mon, Mar 26, 2012 at 3:38 PM, Donald Eastlake wrote: > During the TRILL session today, there was a consensus of those in the > room to make draft-tissa-trill-cmt-00.txt a TRILL WG draft. This is a > call on the WG mailing list to confirm that consensus. If you wish to > respond, please do so by April 10th. > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > --f46d040fa1e8afb95204bcf22ed7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I support making this document a WG draft.

Anoop

On Mon, Mar 26, 2012 at 3:38 PM, Donald Eastlake <d3e3e3@gmail.com> wrote:
During the TRILL session today, there was a = consensus of those in the
room to make draft-tissa-trill-cmt-00.txt a TRILL WG draft. This is a
call on the WG mailing list to confirm that consensus. If you wish to
respond, please do so by April 10th.

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
=A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell)
=A0155 Beaver Street,=A0Milford, MA 01757 USA
=A0d3e3e3@gmail.com

_______________________________________________
rbridge mailing list
rbridge@postel.org
http://mailman.postel.org/mailman/listinfo/rbridge

--f46d040fa1e8afb95204bcf22ed7-- --===============1443162309== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge --===============1443162309==-- From rbridge-bounces@postel.org Thu Apr 5 11:18:13 2012 Return-Path: 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 C96A221F8692 for ; Thu, 5 Apr 2012 11:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.499 X-Spam-Level: X-Spam-Status: No, score=-105.499 tagged_above=-999 required=5 tests=[AWL=1.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 Sg08MJKL2u-g for ; Thu, 5 Apr 2012 11:18:13 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id CE17821F86A4 for ; Thu, 5 Apr 2012 11:17:57 -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 q35I1rno000775; Thu, 5 Apr 2012 11:01:54 -0700 (PDT) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q35I1Yug000730 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 5 Apr 2012 11:01:45 -0700 (PDT) Received: by lbom4 with SMTP id m4so365383lbo.39 for ; Thu, 05 Apr 2012 11:01:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=UXivxTmi6Fx0Nrp5XoqYaQudSSRI7maX0rNmfYm68iU=; b=N4hZCn8gJHTKyfLPBjGTLPdZqELvTohbGUOnA3dy4bpphdUnttJJrKiPiZzGIgVjWZ mcDSrk9nnzmNvQlbkykjaQcJY0mVvsXjuaJ1BPHB5p1vFnjrn2skArUV1lpAIHpOFH9/ 74laQLBvm73O6ioSUqEkBLyDdlheWqsg2DgAFj6S4ePEWfqwFpI+mMvna5AZ8H2IfcAS QVFHzFSIGVGhshU0M2ig5mRdLSKyX8Twu2QMdMkMU7dEKqB9j9PxKIwYPRQmvhHaZm8M XG73WmtGQdYxh9lRdbdM6f+mi23cr6m3sBOMMoIcUuxChPAdfEVc9aubftJ2Il9v1kH2 1ooQ== Received: by 10.152.133.144 with SMTP id pc16mr4545490lab.0.1333648893805; Thu, 05 Apr 2012 11:01:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.162 with HTTP; Thu, 5 Apr 2012 11:01:12 -0700 (PDT) From: Donald Eastlake Date: Thu, 5 Apr 2012 14:01:12 -0400 Message-ID: To: rbridge@postel.org X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: d3e3e3@gmail.com X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id q35I1Yug000730 Subject: [rbridge] draft-tissa-trill-cmt-00 to WG draft X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org This is a WG consensus determination that draft-tissa-trill-cmt-00.txt should be a working group draft. There was a strong consensus for this at the Paris meeting. Although the consensus on the mailing list is a bit rougher, overall I do not think there is any real question that the consensus of the WG is to make this a working draft. Thanks, Donald [Co-Chair] PS: I will be posting a separate message with some personal thoughts. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge From rbridge-bounces@postel.org Thu Apr 5 11:38:56 2012 Return-Path: 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 6090221F8642 for ; Thu, 5 Apr 2012 11:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 fzqxY3LhiHIh for ; Thu, 5 Apr 2012 11:38:55 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id A104E21F85E5 for ; Thu, 5 Apr 2012 11:38:55 -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 q35IJTAE003999; Thu, 5 Apr 2012 11:19:31 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q35IIlXg003917 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 5 Apr 2012 11:18:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ramkumar@cisco.com; l=1845; q=dns/txt; s=iport; t=1333649936; x=1334859536; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=aEp+DuQdpwC35CODTGVHfyY14kc0dbeNCO4GTKJI6aE=; b=RLn/mFmft8MWsRvRdb0yYkb0NYiUfTXSylXTZYfiqkDeZNKsDJjp8b9p 3RSbtt9dOmkAWmzaOhXYYh8dfBv96+LMtBR0a0f8pw074oNtFOjGQZPII SOzGaod5Qm+4tttisdykZo29xIGGm/7pvmPwkSiABLmvH4E9wfcctxtIN c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAF3hfU+rRDoJ/2dsb2JhbABFhW+zBIEHggkBAQEDAQEBAQ8BCgZLCwULCxEEAQEBJwMCAicfCQgGExsHh2cEAQuad40IkmKPQoEYBIhZjiONOoFpgwc X-IronPort-AV: E=Sophos;i="4.75,377,1330905600"; d="scan'208";a="36662156" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 05 Apr 2012 18:18:47 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q35IIkTD025266; Thu, 5 Apr 2012 18:18:46 GMT Received: from xfe-sjc-232.amer.cisco.com ([128.107.191.79]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Apr 2012 11:18:47 -0700 Received: from sjc-xdm-134.cisco.com ([10.28.29.230]) by xfe-sjc-232.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2012 11:18:45 -0700 Date: Thu, 5 Apr 2012 11:18:45 -0700 (PDT) From: Ramkumar Parameswaran To: Sam Aldrin In-Reply-To: Message-ID: References: <344037D7CFEFE84E97E9CC1F56C5F4A5E3B778@xmb-sjc-214.amer.cisco.com> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-572771826-1333649926=:18384" X-OriginalArrivalTime: 05 Apr 2012 18:18:45.0978 (UTC) FILETIME=[8A2BABA0:01CD1358] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: ramkumar@cisco.com Cc: "Tissa Senevirathne \(tsenevir\)" , rbridge@postel.org Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-572771826-1333649926=:18384 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT +1, I think affinity TLV and virtual edge rbridge are very pragmatic concepts. On Thu, 5 Apr 2012, Sam Aldrin wrote: > I support this draft to be adopted as WG document. > The solution proposed is least overhead and doesn't require unnecessary > overhead of deploying certain topology. The arguments raised against thus > far do not provide much simpler solution by any means.聽 > > Cheers > Sam > Sent from my iPad > > On Apr 5, 2012, at 7:28 AM, "Tissa Senevirathne (tsenevir)" > wrote: > > +1 vote in support. > > 聽 > > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Ayan Banerjee > (ayabaner) > Sent: Wednesday, April 04, 2012 11:03 PM > To: rbridge@postel.org > Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG > draft > > 聽 > > Yes, I believe that this is an important piece of the puzzle and > should be made a WG document. > > Thanks, > Ayan > ==== > > > > During the TRILL session today, there was a consensus of those in the > room to make draft-tissa-trill-cmt-00.txt a TRILL WG draft. This is a > call on the WG mailing list to confirm that consensus. If you wish to > respond, please do so by April 10th. > > Thanks, > Donald > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > > > --8323328-572771826-1333649926=:18384 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge --8323328-572771826-1333649926=:18384-- From rbridge-bounces@postel.org Thu Apr 5 12:05:46 2012 Return-Path: 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 A4C0921F86B6 for ; Thu, 5 Apr 2012 12:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] 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 Xo+aNzaMFODw for ; Thu, 5 Apr 2012 12:05:45 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id CFA9521F86B5 for ; Thu, 5 Apr 2012 12:05:45 -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 q35ImuCO009707; Thu, 5 Apr 2012 11:48:58 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q35ImANr009307 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 5 Apr 2012 11:48:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=letracy@cisco.com; l=5516; q=dns/txt; s=iport; t=1333651699; x=1334861299; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=b7RNIjOfq2ZVeXDJyIDvZ0DLeLT5sVd0M52KyQ7xWCA=; b=A9nz/GYmpvRNAogPBAJM+2JVXHZheVCDtQ3Em+5x/QCRyPnaelfUz/bm 0YasmzoWClcuKMAeJr8eockg2HgL0RsvfrOV/D1vBwVVCeJc8lqp3SdhK iXjUtFjTKox8iBYe7B4AR4uaiiSoTb6P7NMtVKyjT4PVnHf2+Gwdpjgcn Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoUHAEjofU+rRDoJ/2dsb2JhbABFgkaGEKcbAYgLdoEHggkBAQEDAQEBAQ8BCiAxCwUNAQgJCAQBAQEnKAYfCQgBAQQBDQUbB4deAwYEAQuacpYGDYlTiiGGOQSIWYUsh2aBEYomgxSBaYE3gVA X-IronPort-AV: E=Sophos;i="4.75,377,1330905600"; d="scan'208,217";a="36667297" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 05 Apr 2012 18:48:10 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q35ImAMq013387; Thu, 5 Apr 2012 18:48:10 GMT Received: from xmb-sjc-238.amer.cisco.com ([128.107.191.16]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Apr 2012 11:48:10 -0700 Received: from 10.21.74.121 ([10.21.74.121]) by xmb-sjc-238.amer.cisco.com ([128.107.191.16]) with Microsoft Exchange Server HTTP-DAV ; Thu, 5 Apr 2012 18:48:09 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Thu, 05 Apr 2012 11:48:08 -0700 From: letracy To: Sam Aldrin , "Tissa Senevirathne (tsenevir)" Message-ID: Thread-Topic: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft Thread-Index: Ac0TXKRqxseZBnsZV0KArfN8xt4CAw== In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 05 Apr 2012 18:48:10.0368 (UTC) FILETIME=[A5D43800:01CD135C] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: letracy@cisco.com Cc: "" Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1289939088==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1289939088== Content-type: multipart/alternative; boundary="B_3416471288_40121877" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3416471288_40121877 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit +1 also. I believe this is a valuable addition. Thanks, Leonard On 4/5/12 8:14 AM, "Sam Aldrin" wrote: > I support this draft to be adopted as WG document. > The solution proposed is least overhead and doesn't require unnecessary > overhead of deploying certain topology. The arguments raised against thus far > do not provide much simpler solution by any means. > > Cheers > Sam > Sent from my iPad > > On Apr 5, 2012, at 7:28 AM, "Tissa Senevirathne (tsenevir)" > wrote: > >> Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft >> +1 vote in support. >> >> >> From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On >> Behalf Of Ayan Banerjee (ayabaner) >> Sent: Wednesday, April 04, 2012 11:03 PM >> To: rbridge@postel.org >> Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft >> >> Yes, I believe that this is an important piece of the puzzle and should be >> made a WG document. >> >> Thanks, >> Ayan >> ==== >> >> >> >> During the TRILL session today, there was a consensus of those in the >> room to make draft-tissa-trill-cmt-00.txt a TRILL WG draft. This is a >> call on the WG mailing list to confirm that consensus. If you wish to >> respond, please do so by April 10th. >> >> Thanks, >> Donald >> _______________________________________________ >> 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 --B_3416471288_40121877 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft +1 also.  I believe this is a valuable addition.

Thanks,
Leonard



On 4/5/12 8:14 AM, "Sam Aldrin" <aldrin.ietf@gmail.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>I support this draft to be adopted as WG documen= t.
The solution proposed is least overhead and doesn't require unnecessary ove= rhead of deploying certain topology. The arguments raised against thus far d= o not provide much simpler solution by any means.

Cheers
Sam
Sent from my iPad

On Apr 5, 2012, at 7:28 AM, "Tissa Senevirathne (tsenevir)" <<= a href=3D"tsenevir@cisco.com">tsenevir@cisco.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Re: [rbridge] Call for draft-tissa-trill-cmt-00 = to WG draft
+1 vote in support.
 

From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behal= f Of Ayan Banerjee (ayabaner)
Sent: Wednesday, April 04, 2012 11:03 PM
To: rbridge@postel.org
Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft=

Yes, I believe that this is an important piece of the puzzl= e and should be made a WG document.

Thanks,
Ayan
=3D=3D=3D=3D



During the TRILL session today, there was a consensus of those in the
room to make draft-tissa-trill-cmt-00.txt a TRILL WG draft. This is a
call on the WG mailing list to confirm that consensus. If you wish to
respond, please do so by April 10th.

Thanks,
Donald
_______________________________________________
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
--B_3416471288_40121877-- --===============1289939088== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge --===============1289939088==-- From rbridge-bounces@postel.org Thu Apr 5 12:55:35 2012 Return-Path: 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 B4F2021F86B6 for ; Thu, 5 Apr 2012 12:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.639 X-Spam-Level: X-Spam-Status: No, score=-105.639 tagged_above=-999 required=5 tests=[AWL=0.960, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 ULW-A9qR91eY for ; Thu, 5 Apr 2012 12:55:35 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 16BBA21F86A4 for ; Thu, 5 Apr 2012 12:55:35 -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 q35Jn0OC018814; Thu, 5 Apr 2012 12:49:00 -0700 (PDT) Received: from mail-lpp01m010-f52.google.com (mail-lpp01m010-f52.google.com [209.85.215.52]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q35JmKvX018461 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 5 Apr 2012 12:48:30 -0700 (PDT) Received: by lahi5 with SMTP id i5so3277544lah.39 for ; Thu, 05 Apr 2012 12:48:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=AuMYUS03KUYa9orgmQX1T6JU4hI5E7khm77lSrimXY0=; b=Dm+8CmL9NJRLESKdmfU6EJ8b7Rk9TGSyK+VxrpG9SKGHsQTh4YICN5CuYr6yT6IVme NvztHJF4+5fiq87FsQJ9slhyuzaVLDbGw8t104J9SgNeOzPQFbTfVpRXU/lkQ+mwr69L ziqVYrDcjiOy0JksnRFw1cONyL5AIGjHuKbkVLxOICrZzu7bFXnnr5MiGy4BhInk5yKF VVfUSbH/AjPoUngG3zaUGyZoaWBceiZXU7ND3Dn8pwrrmEA17p0bNMY8oljoYToqlsr4 KUxI84lm2qsrF3ntcwCVMo1sTYzv4g3XlTztcr24BwIaQVYpTkg3+gYwMCR8k7onxpAe 3T7Q== Received: by 10.152.115.38 with SMTP id jl6mr4891757lab.24.1333655299548; Thu, 05 Apr 2012 12:48:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.162 with HTTP; Thu, 5 Apr 2012 12:47:59 -0700 (PDT) In-Reply-To: References: From: Donald Eastlake Date: Thu, 5 Apr 2012 15:47:59 -0400 Message-ID: To: rbridge@postel.org X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: d3e3e3@gmail.com X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id q35JmKvX018461 Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org All of the proposals have some good and bad features. The approval of the CMT draft as a working group draft is not final approval to request RFC publication. I think the CMT draft needs some more work particularly to cover failure cases. I don't think the WG has decided the details of multi-topology yet. If, when it does so, MT provides a simpler way to do what the CMT draft does, then I think those using multi-topology should be able to use that technique to solve this problem. I believe the CMT draft only covers cases where the RBridges are not adjacent in that they can't see each other's Hellos. (You might refer to this case by the oxymoronic term "opaque link".) For the case where the RBridges are adjacent and you could easily have a pseudo node, I believe a separate draft is needed. I tend to think that such a draft would probably end up using the CMT sub-TLV but it might not. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com On Mon, Mar 26, 2012 at 6:38 PM, Donald Eastlake wrote: > During the TRILL session today, there was a consensus of those in the > room to make draft-tissa-trill-cmt-00.txt a TRILL WG draft. This is a > call on the WG mailing list to confirm that consensus. If you wish to > respond, please do so by April 10th. > > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) > =A0155 Beaver Street,=A0Milford, MA 01757 USA > =A0d3e3e3@gmail.com _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge From rbridge-bounces@postel.org Thu Apr 5 13:14:57 2012 Return-Path: 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 59E4121F8613 for ; Thu, 5 Apr 2012 13:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.799 X-Spam-Level: X-Spam-Status: No, score=-105.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 FZeQplTG8vgC for ; Thu, 5 Apr 2012 13:14:56 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6515421F8611 for ; Thu, 5 Apr 2012 13:14:56 -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 q35JjvFU018321; Thu, 5 Apr 2012 12:45:58 -0700 (PDT) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q35JjWcu018286 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 5 Apr 2012 12:45:42 -0700 (PDT) Received: by lbom4 with SMTP id m4so466617lbo.39 for ; Thu, 05 Apr 2012 12:45:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=EGI5hoHKhZQ+SvD8GoO00Cy9K6pyPMvYJdvXqlsNpdg=; b=KHGrgSKTisF09YAarAv1PsHMLw6IG5BygW1FdICd3tjUN7f8sjGn4CbepHq7iWPJpW Q7/Nvzhdn9ZwV+D9DpCypQQF7ghG561A4nMq3iP5wW7C3o4Wp3TQDrj9UHIZyuBd/jsf bMboRZpuH5Rv5gH0NN3SHSIGPW0HSiEm/ZBXEk/pYiuPnZpWO6wb5RuYvfYLU6Mq5VB1 1+MD11UFqU0OGWWG+sq0+xxtu91DZlUofc5+LtNwoVWaX1py0Nm2FI7Ms7TFB4TNWsiB Hf7FTWPUgcG1U6ibV0BodIokaxv/cMcIeQT4yfyZQ5Udrl9llCyfaW+XbiakpJL23D9b ++9g== Received: by 10.152.146.39 with SMTP id sz7mr4959522lab.3.1333655131417; Thu, 05 Apr 2012 12:45:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.162 with HTTP; Thu, 5 Apr 2012 12:45:10 -0700 (PDT) In-Reply-To: References: From: Donald Eastlake Date: Thu, 5 Apr 2012 15:45:10 -0400 Message-ID: To: Santosh Rajagopalan X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: d3e3e3@gmail.com X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id q35JjWcu018286 Cc: rbridge@postel.org Subject: Re: [rbridge] network topology constraints in draft-tissa-trill-cmt-00 X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org Hi Sunny, On Wed, Mar 28, 2012 at 6:00 PM, Santosh Rajagopalan wrote: > This is a clever draft, but I wanted to point out some network topology > constraints in the proposal: > > 1) It looks like you can only use this proposal if the CE switches are *n= ot* > interconnected in any fashion outside of the trill network. This is becau= se > sending packets into the CE network strips off information needed to prev= ent > loops. Let me illustrate using the example from the draft: RB1 receives a > multidestination packet from the trill campus on tree 1, and it also has = an > "affinity" for that tree. So it decaps it and send the packet into the CE > network (basically, a copy gets sent to each of CE1..CEn). > > Let's assume that the CE network is composed of interconnected switches, > instead of the isolated switches shown in the picture. This is reasonable, > because it avoids needing to take the extra hop to the aggregation layer = for > end-systems on the same chassis or rack. This means that a broadcast pack= et > would be replicated by the CE network to each of its switches, including > CE1...CEn. So CE1..CEn just got their first duplicate. Each of these > switches looks at the attached rbridges as edge ports, so it sends them a > copy. Now, rbridges RB1..RBk each label the ingressing packet with their > respective "affinity" tree labels and sends them into the TRILL network, > where it gets to the edge of the trill network, and the cycle repeats. You > now have a loop. > > In addition, if you had interconnectivity between the CE switches, then t= he > edge rbridges would be able to exchange LSPs with each other, which will (I think you mean Hellos.) > result in one of them being elected the AF. The others will then not encap > or decap CE packets. So the affinity based approach would conflict with = =A0RFC > 6325. All in all, we need the CE switches to be isolated here. OK. The technique in this draft is an optimization to spread load more evenly and improve fail over. If there are cases where you can't use this technique, then, in those cases, you can look for other ways to accomplish either or both such improvements. > 2) Applying an STP-based solution like the one described in RFC 6325 ("The > Spanning Tree Solution") to =A0break the connectivity between the CE swit= ches > won't work here, because this will render certain switches unreachable on > some trees. In figure 13 ("wiring closet topology") in rfc 6325, if RB1 h= as > an affinity for tree k, then packets coming in from the trill cloud on th= at > tree will need to get to B2 through RB1, but since STP has blocked B1-B2 > this won't happen. This just reiterates that no form of interconnect > whatsoever between the CE switches is permissible, and "The Spanning Tree > Solution" will not work here. I don't understand your comment #2 above. Assuming use of the technique in RFC 6325 A.3.3 so the link between B1 and B2 is blocked, you imply that multi-destination frames for B2 must somehow be delivered via RB1->B1->B2, which will not work. But why can't they be directly delivered via RB1->B2, since I believe we are assuming that both B1 and B2 are each directly connected to both RB1 and RB2? After all, with the B1-B2 link blocked, there isn't any way that RB1 and RB2 can tell if that link is still up. If someone just snipped the cable between B1 and B2, what would change at RB1 or RB2? Yet you agree, I believe, that if B1 and B2 had never been connected, it would work... > 3) In addition to the above constraint, each CE switch needs to be connec= ted > to every rbridge, and the consequence of any of the LAG links going down = are > catastrophic. Also, each rbridge needs to have a vLAG each to each CE swi= tch > in the LAN. This is necessary because the entire CE network has been > "emulated" by the pseudo-rbridge (RBv) in the draft. This depends on whether one RBv is for all the CEs or you have multiple RBv nicknames. It seems to me you at least need a different RBv for each different set of RBridges whose links are aggregated. (Except. of course, if you get down to one rbridge, you can just use that rbridge's nickname for the ingress...) > Let's say a packet arrives from the trill core at a certain rbridge on a > tree that it has an affinity for. The assumption is that by decapsulating > the packet and sending it to each of the attached CE links, all the stati= ons > in the CE network will get the packet. So if there's a certain CE switch > which isn't connected to this rbridge, it will not get the packet (the > packet can't get to the CE switch through another CE switch, because of t= he > constraint in 1) above). > > This means that a) each rbridge needs to have n vLAGs, one for each CE > switch, and b) each CE switch needs to have k ports in its LAG, one for e= ach > rbridge. Note that most switches have scalability constraints on the numb= er > of LAG members and on the number of VLAGs. For small networks this may not > be a problem, however, this may still be a problem if one of your links on > the LAG goes down. In that case, that CE switch will get permanently > blackholed for some trees. (Essentially, the upstream rbridge on the other > end of the down link no longer has any way of reaching the CE switch on t= he > x trees it has an affinity for) > > At the very least, this proposal needs a way for an rbridge to "relinquis= h" > its affinity trees when any VLAG link goes down, and a way those trees to > either be retired or be picked up by other rbridges. In addition, the > rbridge will need to bring all of its CE-facing links down, so that the CE > bridges don't try to use that rbridge to inject packets into the TRILL > network. Lots of things can happen. Links can fail or come up. RBridges can fail or come up. The campus can be re-configured to increase or decrease the number of trees. I don't think any of the proposals specifies how to handle all these events. > 4) Because of the constraint imposed by 1), you cannot interconnect two > trill clouds using an intermediate CE cloud - the trill clouds will need = to > be merged using p2p trill links. This could be a problem if you plan to > incrementally upgrade your switches to trill, as opposed to a fork-lift > upgrade of your whole data center. As far as I can tell, you mean "bridged LAN" when you say "CE cloud". Of course you can connect trill clouds with a bridged LAN to form a single campus, you just can't use this particular technique at the same time. Considering the bridged LAN as a multi-access transit link, if you follow typically recommended network design and do not put end stations on that link, it doesn't make much difference that you can't use this technique. I don't think it has anything to do with "p2p trill links". TRILL has always fully supported multi-access links. There is no problem using one or more multi-access and/or p2p physical links to connect RBridges to a bridged LAN as part of a TRILL campus whether or not the topology is such that that bridged LAN is the only connection between two parts of the campus. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com > Note that the existing version of RFC 6325 does not have constraints on > interconnectivity of CE switches or rbridges as described above. > > Thoughts? > > -- > Sunny Rajagopalan _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge From rbridge-bounces@postel.org Thu Apr 5 15:48:52 2012 Return-Path: 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 A358321F86F1 for ; Thu, 5 Apr 2012 15:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 YNH8W7zAlYyo for ; Thu, 5 Apr 2012 15:48:51 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 83D7B21F868A for ; Thu, 5 Apr 2012 15:48:46 -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 q35MTaYf014294; Thu, 5 Apr 2012 15:29:38 -0700 (PDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q35MSlIb014242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 5 Apr 2012 15:28:56 -0700 (PDT) Received: from /spool/local by e5.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 5 Apr 2012 18:28:46 -0400 Received: from d01dlp02.pok.ibm.com (9.56.224.85) by e5.ny.us.ibm.com (192.168.1.105) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 5 Apr 2012 18:28:43 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 9570B6E804C; Thu, 5 Apr 2012 18:28:42 -0400 (EDT) Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q35MSfo4289186; Thu, 5 Apr 2012 18:28:42 -0400 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q35MSMT4017572; Thu, 5 Apr 2012 16:28:23 -0600 Received: from d03nm127.boulder.ibm.com (d03nm127.boulder.ibm.com [9.17.195.18]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q35MSMnR017569; Thu, 5 Apr 2012 16:28:22 -0600 In-Reply-To: References: To: Donald Eastlake MIME-Version: 1.0 X-KeepSent: 5C9DC8DA:85823406-872579D7:0078EB2A; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: Santosh Rajagopalan Date: Thu, 5 Apr 2012 15:27:53 -0700 X-MIMETrack: Serialize by Router on D03NM127/03/M/IBM(Release 8.5.1FP2|March 17, 2010) at 04/05/2012 16:27:55, Serialize complete at 04/05/2012 16:27:55 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12040522-5930-0000-0000-000006C309FC X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sunny.rajagopalan@us.ibm.com Cc: rbridge@postel.org, rbridge-bounces@postel.org Subject: Re: [rbridge] network topology constraints in draft-tissa-trill-cmt-00 X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0222824213==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org This is a multipart message in MIME format. --===============0222824213== Content-Type: multipart/alternative; boundary="=_alternative 007B69B2882579D7_=" This is a multipart message in MIME format. --=_alternative 007B69B2882579D7_= Content-Type: text/plain; charset="US-ASCII" Hi, Donald 1) The most significant topology concern I have is that with CMT, the CE switches that are connected into the rbridges cannot be interconnected - this forces all east-west traffic to take an extra hop north. This needs to be well-documented. 2) You're right that STP isn't precluded, but with no interconnects possible between the CE bridges, its not needed either. 3) The solution for the CE-rbridge link failure isn't presented in the draft. My bigger problem is that all the solutions I can think of in the framework of this draft are expensive to the point of being deal-breakers. Shutting down *all* the south-facing links on an rbridge when *one* link goes down isn't workable. Can you explain how having multiple RBv nicknames solves this problem? There is one (expensive) solution I can think of, if you have an RBv per CE switch. In this case the rbridge will only advertise a virtual nickname if the link which has been "assigned" to that RBv is still up. This solution, unfortunately, expands the databases and state everywhere, in addition to making our 16-bit space run through faster. Is this the solution the draft authors will be going towards? -- Sunny From: Donald Eastlake To: Santosh Rajagopalan/Santa Clara/IBM@IBMUS Cc: rbridge@postel.org Date: 04/05/2012 01:15 PM Subject: Re: [rbridge] network topology constraints in draft-tissa-trill-cmt-00 Sent by: rbridge-bounces@postel.org Hi Sunny, On Wed, Mar 28, 2012 at 6:00 PM, Santosh Rajagopalan wrote: > This is a clever draft, but I wanted to point out some network topology > constraints in the proposal: > > 1) It looks like you can only use this proposal if the CE switches are *not* > interconnected in any fashion outside of the trill network. This is because > sending packets into the CE network strips off information needed to prevent > loops. Let me illustrate using the example from the draft: RB1 receives a > multidestination packet from the trill campus on tree 1, and it also has an > "affinity" for that tree. So it decaps it and send the packet into the CE > network (basically, a copy gets sent to each of CE1..CEn). > > Let's assume that the CE network is composed of interconnected switches, > instead of the isolated switches shown in the picture. This is reasonable, > because it avoids needing to take the extra hop to the aggregation layer for > end-systems on the same chassis or rack. This means that a broadcast packet > would be replicated by the CE network to each of its switches, including > CE1...CEn. So CE1..CEn just got their first duplicate. Each of these > switches looks at the attached rbridges as edge ports, so it sends them a > copy. Now, rbridges RB1..RBk each label the ingressing packet with their > respective "affinity" tree labels and sends them into the TRILL network, > where it gets to the edge of the trill network, and the cycle repeats. You > now have a loop. > > In addition, if you had interconnectivity between the CE switches, then the > edge rbridges would be able to exchange LSPs with each other, which will (I think you mean Hellos.) > result in one of them being elected the AF. The others will then not encap > or decap CE packets. So the affinity based approach would conflict with RFC > 6325. All in all, we need the CE switches to be isolated here. OK. The technique in this draft is an optimization to spread load more evenly and improve fail over. If there are cases where you can't use this technique, then, in those cases, you can look for other ways to accomplish either or both such improvements. > 2) Applying an STP-based solution like the one described in RFC 6325 ("The > Spanning Tree Solution") to break the connectivity between the CE switches > won't work here, because this will render certain switches unreachable on > some trees. In figure 13 ("wiring closet topology") in rfc 6325, if RB1 has > an affinity for tree k, then packets coming in from the trill cloud on that > tree will need to get to B2 through RB1, but since STP has blocked B1-B2 > this won't happen. This just reiterates that no form of interconnect > whatsoever between the CE switches is permissible, and "The Spanning Tree > Solution" will not work here. I don't understand your comment #2 above. Assuming use of the technique in RFC 6325 A.3.3 so the link between B1 and B2 is blocked, you imply that multi-destination frames for B2 must somehow be delivered via RB1->B1->B2, which will not work. But why can't they be directly delivered via RB1->B2, since I believe we are assuming that both B1 and B2 are each directly connected to both RB1 and RB2? After all, with the B1-B2 link blocked, there isn't any way that RB1 and RB2 can tell if that link is still up. If someone just snipped the cable between B1 and B2, what would change at RB1 or RB2? Yet you agree, I believe, that if B1 and B2 had never been connected, it would work... > 3) In addition to the above constraint, each CE switch needs to be connected > to every rbridge, and the consequence of any of the LAG links going down are > catastrophic. Also, each rbridge needs to have a vLAG each to each CE switch > in the LAN. This is necessary because the entire CE network has been > "emulated" by the pseudo-rbridge (RBv) in the draft. This depends on whether one RBv is for all the CEs or you have multiple RBv nicknames. It seems to me you at least need a different RBv for each different set of RBridges whose links are aggregated. (Except. of course, if you get down to one rbridge, you can just use that rbridge's nickname for the ingress...) > Let's say a packet arrives from the trill core at a certain rbridge on a > tree that it has an affinity for. The assumption is that by decapsulating > the packet and sending it to each of the attached CE links, all the stations > in the CE network will get the packet. So if there's a certain CE switch > which isn't connected to this rbridge, it will not get the packet (the > packet can't get to the CE switch through another CE switch, because of the > constraint in 1) above). > > This means that a) each rbridge needs to have n vLAGs, one for each CE > switch, and b) each CE switch needs to have k ports in its LAG, one for each > rbridge. Note that most switches have scalability constraints on the number > of LAG members and on the number of VLAGs. For small networks this may not > be a problem, however, this may still be a problem if one of your links on > the LAG goes down. In that case, that CE switch will get permanently > blackholed for some trees. (Essentially, the upstream rbridge on the other > end of the down link no longer has any way of reaching the CE switch on the > x trees it has an affinity for) > > At the very least, this proposal needs a way for an rbridge to "relinquish" > its affinity trees when any VLAG link goes down, and a way those trees to > either be retired or be picked up by other rbridges. In addition, the > rbridge will need to bring all of its CE-facing links down, so that the CE > bridges don't try to use that rbridge to inject packets into the TRILL > network. Lots of things can happen. Links can fail or come up. RBridges can fail or come up. The campus can be re-configured to increase or decrease the number of trees. I don't think any of the proposals specifies how to handle all these events. > 4) Because of the constraint imposed by 1), you cannot interconnect two > trill clouds using an intermediate CE cloud - the trill clouds will need to > be merged using p2p trill links. This could be a problem if you plan to > incrementally upgrade your switches to trill, as opposed to a fork-lift > upgrade of your whole data center. As far as I can tell, you mean "bridged LAN" when you say "CE cloud". Of course you can connect trill clouds with a bridged LAN to form a single campus, you just can't use this particular technique at the same time. Considering the bridged LAN as a multi-access transit link, if you follow typically recommended network design and do not put end stations on that link, it doesn't make much difference that you can't use this technique. I don't think it has anything to do with "p2p trill links". TRILL has always fully supported multi-access links. There is no problem using one or more multi-access and/or p2p physical links to connect RBridges to a bridged LAN as part of a TRILL campus whether or not the topology is such that that bridged LAN is the only connection between two parts of the campus. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > Note that the existing version of RFC 6325 does not have constraints on > interconnectivity of CE switches or rbridges as described above. > > Thoughts? > > -- > Sunny Rajagopalan _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge --=_alternative 007B69B2882579D7_= Content-Type: text/html; charset="US-ASCII" Hi, Donald
1) The most significant topology concern I have is that with CMT, the CE switches that are connected into the rbridges cannot be interconnected - this forces all east-west traffic to take an extra hop north. This needs to be well-documented.

2) You're right that STP isn't precluded, but with no interconnects possible between the CE bridges, its not needed either.

3) The solution for the CE-rbridge link failure isn't presented in the draft. My bigger problem is that all the solutions I can think of in the framework of this draft are expensive to the point of being deal-breakers. Shutting down *all* the south-facing links on an rbridge when *one* link goes down isn't workable. Can you explain how having multiple RBv nicknames solves this problem?
There is one (expensive) solution I can think of, if you have an RBv per CE switch. In this case the rbridge will only advertise a virtual nickname if the link which has been "assigned" to that RBv is still up. This solution, unfortunately, expands the databases and state everywhere, in addition to making our 16-bit space run through faster. Is this the solution the draft authors will be going towards?

--
Sunny



From:        Donald Eastlake <d3e3e3@gmail.com>
To:        Santosh Rajagopalan/Santa Clara/IBM@IBMUS
Cc:        rbridge@postel.org
Date:        04/05/2012 01:15 PM
Subject:        Re: [rbridge] network topology constraints in        draft-tissa-trill-cmt-00
Sent by:        rbridge-bounces@postel.org



Hi Sunny,

On Wed, Mar 28, 2012 at 6:00 PM, Santosh Rajagopalan
<sunny.rajagopalan@us.ibm.com> wrote:
> This is a clever draft, but I wanted to point out some network topology
> constraints in the proposal:
>
> 1) It looks like you can only use this proposal if the CE switches are *not*
> interconnected in any fashion outside of the trill network. This is because
> sending packets into the CE network strips off information needed to prevent
> loops. Let me illustrate using the example from the draft: RB1 receives a
> multidestination packet from the trill campus on tree 1, and it also has an
> "affinity" for that tree. So it decaps it and send the packet into the CE
> network (basically, a copy gets sent to each of CE1..CEn).
>
> Let's assume that the CE network is composed of interconnected switches,
> instead of the isolated switches shown in the picture. This is reasonable,
> because it avoids needing to take the extra hop to the aggregation layer for
> end-systems on the same chassis or rack. This means that a broadcast packet
> would be replicated by the CE network to each of its switches, including
> CE1...CEn. So CE1..CEn just got their first duplicate. Each of these
> switches looks at the attached rbridges as edge ports, so it sends them a
> copy. Now, rbridges RB1..RBk each label the ingressing packet with their
> respective "affinity" tree labels and sends them into the TRILL network,
> where it gets to the edge of the trill network, and the cycle repeats. You
> now have a loop.
>
> In addition, if you had interconnectivity between the CE switches, then the
> edge rbridges would be able to exchange LSPs with each other, which will

(I think you mean Hellos.)

> result in one of them being elected the AF. The others will then not encap
> or decap CE packets. So the affinity based approach would conflict with  RFC
> 6325. All in all, we need the CE switches to be isolated here.

OK. The technique in this draft is an optimization to spread load more
evenly and improve fail over. If there are cases where you can't use
this technique, then, in those cases, you can look for other ways to
accomplish either or both such improvements.

> 2) Applying an STP-based solution like the one described in RFC 6325 ("The
> Spanning Tree Solution") to  break the connectivity between the CE switches
> won't work here, because this will render certain switches unreachable on
> some trees. In figure 13 ("wiring closet topology") in rfc 6325, if RB1 has
> an affinity for tree k, then packets coming in from the trill cloud on that
> tree will need to get to B2 through RB1, but since STP has blocked B1-B2
> this won't happen. This just reiterates that no form of interconnect
> whatsoever between the CE switches is permissible, and "The Spanning Tree
> Solution" will not work here.

I don't understand your comment #2 above. Assuming use of the
technique in RFC 6325 A.3.3 so the link between B1 and B2 is blocked,
you imply that multi-destination frames for B2 must somehow be
delivered via RB1->B1->B2, which will not work. But why can't they be
directly delivered via RB1->B2, since I believe we are assuming that
both B1 and B2 are each directly connected to both RB1 and RB2? After
all, with the B1-B2 link blocked, there isn't any way that RB1 and RB2
can tell if that link is still up. If someone just snipped the cable
between B1 and B2, what would change at RB1 or RB2? Yet you agree, I
believe, that if B1 and B2 had never been connected, it would work...

> 3) In addition to the above constraint, each CE switch needs to be connected
> to every rbridge, and the consequence of any of the LAG links going down are
> catastrophic. Also, each rbridge needs to have a vLAG each to each CE switch
> in the LAN. This is necessary because the entire CE network has been
> "emulated" by the pseudo-rbridge (RBv) in the draft.

This depends on whether one RBv is for all the CEs or you have
multiple RBv nicknames. It seems to me you at least need a different
RBv for each different set of RBridges whose links are aggregated.
(Except. of course, if you get down to one rbridge, you can just use
that rbridge's nickname for the ingress...)

> Let's say a packet arrives from the trill core at a certain rbridge on a
> tree that it has an affinity for. The assumption is that by decapsulating
> the packet and sending it to each of the attached CE links, all the stations
> in the CE network will get the packet. So if there's a certain CE switch
> which isn't connected to this rbridge, it will not get the packet (the
> packet can't get to the CE switch through another CE switch, because of the
> constraint in 1) above).
>
> This means that a) each rbridge needs to have n vLAGs, one for each CE
> switch, and b) each CE switch needs to have k ports in its LAG, one for each
> rbridge. Note that most switches have scalability constraints on the number
> of LAG members and on the number of VLAGs. For small networks this may not
> be a problem, however, this may still be a problem if one of your links on
> the LAG goes down. In that case, that CE switch will get permanently
> blackholed for some trees. (Essentially, the upstream rbridge on the other
> end of the down link no longer has any way of reaching the CE switch on the
> x trees it has an affinity for)
>
> At the very least, this proposal needs a way for an rbridge to "relinquish"
> its affinity trees when any VLAG link goes down, and a way those trees to
> either be retired or be picked up by other rbridges. In addition, the
> rbridge will need to bring all of its CE-facing links down, so that the CE
> bridges don't try to use that rbridge to inject packets into the TRILL
> network.

Lots of things can happen. Links can fail or come up. RBridges can
fail or come up. The campus can be re-configured to increase or
decrease the number of trees. I don't think any of the proposals
specifies how to handle all these events.

> 4) Because of the constraint imposed by 1), you cannot interconnect two
> trill clouds using an intermediate CE cloud - the trill clouds will need to
> be merged using p2p trill links. This could be a problem if you plan to
> incrementally upgrade your switches to trill, as opposed to a fork-lift
> upgrade of your whole data center.

As far as I can tell, you mean "bridged LAN" when you say "CE cloud".
Of course you can connect trill clouds with a bridged LAN to form a
single campus, you just can't use this particular technique at the
same time. Considering the bridged LAN as a multi-access transit link,
if you follow typically recommended network design and do not put end
stations on that link, it doesn't make much difference that you can't
use this technique.

I don't think it has anything to do with "p2p trill links". TRILL has
always fully supported multi-access links. There is no problem using
one or more multi-access and/or p2p physical links to connect RBridges
to a bridged LAN as part of a TRILL campus whether or not the topology
is such that that bridged LAN is the only connection between two parts
of the campus.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com

> Note that the existing version of RFC 6325 does not have constraints on
> interconnectivity of CE switches or rbridges as described above.
>
> Thoughts?
>
> --
> Sunny Rajagopalan

_______________________________________________
rbridge mailing list
rbridge@postel.org
http://mailman.postel.org/mailman/listinfo/rbridge
--=_alternative 007B69B2882579D7_=-- --===============0222824213== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge --===============0222824213==-- From rbridge-bounces@postel.org Thu Apr 5 17:38:43 2012 Return-Path: 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 46F2311E8074 for ; Thu, 5 Apr 2012 17:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.229 X-Spam-Level: X-Spam-Status: No, score=-104.229 tagged_above=-999 required=5 tests=[AWL=2.370, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 GElJw6gdbx2h for ; Thu, 5 Apr 2012 17:38:42 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 05E6011E8072 for ; Thu, 5 Apr 2012 17:38:41 -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 q360H3GN029345; Thu, 5 Apr 2012 17:17:04 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [12.22.58.30]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q360GUm8029290 for ; Thu, 5 Apr 2012 17:16:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5076E21F8636 for ; Thu, 5 Apr 2012 17:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 Nf5BTLMHuyYX; Thu, 5 Apr 2012 17:16:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6C9621F8522; Thu, 5 Apr 2012 17:16:29 -0700 (PDT) MIME-Version: 1.0 From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120406001629.4481.84102.idtracker@ietfa.amsl.com> Date: Thu, 05 Apr 2012 17:16:29 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: internet-drafts@ietf.org X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id q360GUm8029290 Cc: rbridge@postel.org Subject: [rbridge] I-D Action: draft-ietf-trill-rbridge-mib-07.txt X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transparent Interconnection of Lots of Links Working Group of the IETF. Title : Definitions of Managed Objects for RBridges (Routing Bridges) Author(s) : Anil Rijhsinghani Kate Zebrose Filename : draft-ietf-trill-rbridge-mib-07.txt Pages : 56 Date : 2012-04-05 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing an RBridge (Routing Bridge), also known as a TRILL Switch, based on the IETF TRILL (Transparent Interconnection of Lots of Links) protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-mib-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-trill-rbridge-mib-07.txt _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge From rbridge-bounces@postel.org Thu Apr 5 18:38:04 2012 Return-Path: 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 0E7DA11E808F for ; Thu, 5 Apr 2012 18:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 LzrNoW8Sfo2X for ; Thu, 5 Apr 2012 18:38:03 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 51D3C11E8088 for ; Thu, 5 Apr 2012 18:38:03 -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 q361HYJx007602; Thu, 5 Apr 2012 18:17:35 -0700 (PDT) Received: from mail-ob0-f180.google.com (mail-ob0-f180.google.com [209.85.214.180]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q361H0o6007560 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 5 Apr 2012 18:17:09 -0700 (PDT) Received: by obbun3 with SMTP id un3so3971325obb.39 for ; Thu, 05 Apr 2012 18:16:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=PMYpnSvFQ95TV4oWN4IDYhNE6GYmHmVBHFFu36UBfoY=; b=vdFVa4KwzVg3JLOguEKM2DJpY7koPwBkjldAU++M8beSr/Hc1GTtFOGf6pmA5r9I4o Vx10MEbpWPqehJVLvwITg1It2xcAvvsH7VBQv/r9+ggHAUsXDegwIpAmumFHIJmCzk9h OomWET0nXNyYbpJdS8G4ezKFOExku5XhIVajg2g/eW4bq1CknaAZ66PDR+90wuWf3+uF jhJEwzPeXBqhtH7oqymJl+KjD7llTEgBHZVI51TvBEBfhIhULb65ifx+0OrZFzzIzeVd QmZAG4dsgQRRPG98lhCpH6lhnjt+V3iK7kwXGgbaGUY47gwrMu6dYlfC5qIiiu/YeNew lvSQ== MIME-Version: 1.0 Received: by 10.60.8.103 with SMTP id q7mr6642436oea.61.1333675019535; Thu, 05 Apr 2012 18:16:59 -0700 (PDT) Received: by 10.182.14.71 with HTTP; Thu, 5 Apr 2012 18:16:59 -0700 (PDT) Date: Thu, 5 Apr 2012 18:16:59 -0700 Message-ID: From: Mahesh Akula To: Anil Rijhsinghani X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: mahesh.akula36@gmail.com Cc: rbridge@postel.org Subject: [rbridge] Question on draft-ietf-trill-rbridge-mib-07 X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0481583835==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org --===============0481583835== Content-Type: multipart/alternative; boundary=e89a8ff1c7dec905ab04bcf8693b --e89a8ff1c7dec905ab04bcf8693b Content-Type: text/plain; charset=ISO-8859-1 Hi Anil, I have one question on draft-ietf-trill-rbridge-mib-07. In rbridgeSnoopingPortTable, I see that we are maintaining for each Rbridge port, list of IP Multicast Router addresses connected to that port. >From what I understand from RFC 6325 section 4.7 , all we care is for each port, are there IP multicast routers connected and their types( ipv4/ipv6/both), so that we can pass along reports accordingly. It looks to me all we need is to maintain just one enum per port with values (ipv4/ipv6/both). Why do we need to maintain all IP Multicast router addresses in TRILL MIB? Any other reasons? Regards, Mahesh --e89a8ff1c7dec905ab04bcf8693b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Anil,
=A0
I have one question on draft-ietf-trill-rbridge-mib-07.
=A0
In rbridgeSnoopingPortTable, I see that we are maintaining for each Rb= ridge port, list of IP Multicast Router addresses connected to that port. <= /div>
=A0
From what I understand from RFC 6325 section=A04.7=A0, all we care is for each por= t, are there IP multicast routers connected and their types( ipv4/ipv6/both= ), so that we can pass along reports accordingly.=A0 It=A0looks to me all w= e need=A0is to maintain=A0just one enum per port with values (ipv4/ipv6/bot= h).
=A0
Why do we need to maintain all IP Multicast router addresses in TRILL = MIB? Any other reasons?
=A0
Regards,
Mahesh
=A0
=A0
--e89a8ff1c7dec905ab04bcf8693b-- --===============0481583835== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge --===============0481583835==-- From rbridge-bounces@postel.org Thu Apr 5 19:17:05 2012 Return-Path: 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 3C0FC11E808E for ; Thu, 5 Apr 2012 19:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=1.999, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 CqLkMJXq5dgG for ; Thu, 5 Apr 2012 19:17:04 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 83FB811E8086 for ; Thu, 5 Apr 2012 19:17:04 -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 q361i5DS011066; Thu, 5 Apr 2012 18:44:06 -0700 (PDT) Received: from mta21.charter.net (mta21.charter.net [216.33.127.81]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q361hoxV011048 for ; Thu, 5 Apr 2012 18:43:59 -0700 (PDT) Received: from imp11 ([10.20.200.11]) by mta21.charter.net (InterMail vM.8.01.05.02 201-2260-151-103-20110920) with ESMTP id <20120406014349.YULY12025.mta21.charter.net@imp11>; Thu, 5 Apr 2012 21:43:49 -0400 Received: from [192.168.1.106] ([71.10.228.40]) by imp11 with smtp.charter.net id uRjp1i00B0sw4rK05Rjpym; Thu, 05 Apr 2012 21:43:49 -0400 X-Authority-Analysis: v=1.1 cv=rvNqJbVGdbt4egs52VbhtoJZG7AoPDG9H2iogr/sNfs= c=1 sm=1 a=OGc901ZSejkA:10 a=yUnIBFQkZM0A:10 a=uxqmlfvtJbLpRWMvzcSYSQ==:17 a=kFHd0a58cXemONYJzxgA:9 a=ViuaVcDrHx0l3I8QnF4A:7 a=wPNLvfGTeEIA:10 a=m6KmGIAEsTSBDPh3:21 a=C83rXpQRLMLEKPoW:21 a=48vgC7mUAAAA:8 a=vZkqy9VHanpOht2oplUA:9 a=juAfHFTn6OzS9vxl000A:7 a=_W_S_7VecoQA:10 a=uxqmlfvtJbLpRWMvzcSYSQ==:117 Mime-Version: 1.0 (Apple Message framework v1257) From: Anil Rijhsinghani In-Reply-To: Date: Thu, 5 Apr 2012 21:43:53 -0400 Message-Id: References: To: Mahesh Akula X-Mailer: Apple Mail (2.1257) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: anil@charter.net Cc: rbridge@postel.org Subject: Re: [rbridge] Question on draft-ietf-trill-rbridge-mib-07 X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1725799492==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org --===============1725799492== Content-Type: multipart/alternative; boundary="Apple-Mail=_82FF711C-8E1D-4B21-9E2C-D8AEE7B0AF07" --Apple-Mail=_82FF711C-8E1D-4B21-9E2C-D8AEE7B0AF07 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Mahesh, As the INDEX is rbridgeBasePort, there is a unique entry per port and we = are only maintaining per port the knowledge that there is at least one = multicast router, either v4 or v6, and which one it is (useful from a = management perspective). So it should not return a list of all IP = multicast router addresses connected per port. The total number of = entries in the table would be the number of Rbridge ports on which = snooping has detected an IP multicast router. Regards, Anil On Apr 5, 2012, at 9:16 PM, Mahesh Akula wrote: > Hi Anil, > =20 > I have one question on draft-ietf-trill-rbridge-mib-07. > =20 > In rbridgeSnoopingPortTable, I see that we are maintaining for each = Rbridge port, list of IP Multicast Router addresses connected to that = port. > =20 > =46rom what I understand from RFC 6325 section 4.7 , all we care is = for each port, are there IP multicast routers connected and their types( = ipv4/ipv6/both), so that we can pass along reports accordingly. It = looks to me all we need is to maintain just one enum per port with = values (ipv4/ipv6/both). > =20 > Why do we need to maintain all IP Multicast router addresses in TRILL = MIB? Any other reasons? > =20 > Regards, > Mahesh > =20 > =20 --Apple-Mail=_82FF711C-8E1D-4B21-9E2C-D8AEE7B0AF07 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 Mahesh,

As the INDEX is rbridgeBasePort, there is a unique entry per port and we are only maintaining per port the knowledge that there is at least one multicast router, either v4 or v6, and which one it is (useful from a management perspective). So it should not return a list of all IP multicast router addresses connected per port. The total number of entries in the table would be the number of Rbridge ports on which snooping has detected an IP multicast router.

Regards,
Anil

On Apr 5, 2012, at 9:16 PM, Mahesh Akula wrote:

Hi Anil,
 
I have one question on draft-ietf-trill-rbridge-mib-07.
 
In rbridgeSnoopingPortTable, I see that we are maintaining for each Rbridge port, list of IP Multicast Router addresses connected to that port.
 
From what I understand from RFC 6325 section 4.7 , all we care is for each port, are there IP multicast routers connected and their types( ipv4/ipv6/both), so that we can pass along reports accordingly.  It looks to me all we need is to maintain just one enum per port with values (ipv4/ipv6/both).
 
Why do we need to maintain all IP Multicast router addresses in TRILL MIB? Any other reasons?
 
Regards,
Mahesh
 
 

--Apple-Mail=_82FF711C-8E1D-4B21-9E2C-D8AEE7B0AF07-- --===============1725799492== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge --===============1725799492==-- From rbridge-bounces@postel.org Thu Apr 5 19:23:20 2012 Return-Path: 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 9213811E808E for ; Thu, 5 Apr 2012 19:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 1-Nrqy144lwO for ; Thu, 5 Apr 2012 19:23:19 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id C573411E8086 for ; Thu, 5 Apr 2012 19:23:19 -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 q3629DQi014917; Thu, 5 Apr 2012 19:09:13 -0700 (PDT) Received: from mail-ob0-f180.google.com (mail-ob0-f180.google.com [209.85.214.180]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q3628nAn014873 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 5 Apr 2012 19:08:58 -0700 (PDT) Received: by obbun3 with SMTP id un3so4036637obb.39 for ; Thu, 05 Apr 2012 19:08:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=49TVtYNVepEnBGADFpwrlvLAGMDw0l9M5/9UDgdlgGU=; b=HekvKRegsOvvIu6WOwQhEWyCCSlMHh3IqwQKv+8tABU1xQGMIlTHq8D9sWJURzCTFy aaP3jQUbu5kQ73FW+nJPl96Nrz5OBX/0jqm9E/SC/nDpF88gADq32HcVtVB36bZZtOYg NlDwherElVDgOZWjlXEYmS3W0zdrTYk85YrSbzoyUTei8EiFQQuMX0fndOL6DLqdXmdp /2scsfCwb+rf8XxrVbGc90s56E6itmYWCb6H8fHC4/6zpC2G0D3oUYNrtBIsjuEubiJQ exwxTVvw8oiT1t42M42nw+t9QoDIW50mAvPGoIo+zwNqRBAl81BULJAaz/1t7uNmxP3E VJ3Q== MIME-Version: 1.0 Received: by 10.182.139.42 with SMTP id qv10mr6974755obb.71.1333678129273; Thu, 05 Apr 2012 19:08:49 -0700 (PDT) Received: by 10.182.14.71 with HTTP; Thu, 5 Apr 2012 19:08:49 -0700 (PDT) In-Reply-To: References: Date: Thu, 5 Apr 2012 19:08:49 -0700 Message-ID: From: Mahesh Akula To: Anil Rijhsinghani X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: mahesh.akula36@gmail.com Cc: rbridge@postel.org Subject: Re: [rbridge] Question on draft-ietf-trill-rbridge-mib-07 X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0188455988==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org --===============0188455988== Content-Type: multipart/alternative; boundary=e89a8f839ee323dbd004bcf9231f --e89a8f839ee323dbd004bcf9231f Content-Type: text/plain; charset=ISO-8859-1 Hi Anil, But there can be both ipv4/ipv6 multicast routers attached to that link right? >> IP multicast data SHOULD only be sent on links where there is either an IP multicast router for that IP type (IPv4 or IPv6) or .. As the idea is to forward the data (and reports) only if there is a router for that specific IP type, it looks to me it is more important to capture whether only one IP type of multicast router is attached or both. Also, as there can be more than one multicast router of each IP type attached, capturing only one of them may not serve any purpose IMO. Regards, Mahesh On Thu, Apr 5, 2012 at 6:43 PM, Anil Rijhsinghani wrote: > Mahesh, > > As the INDEX is rbridgeBasePort, there is a unique entry per port and we > are only maintaining per port the knowledge that there is at least one > multicast router, either v4 or v6, and which one it is (useful from a > management perspective). So it should not return a list of all IP multicast > router addresses connected per port. The total number of entries in the > table would be the number of Rbridge ports on which snooping has detected > an IP multicast router. > > Regards, > Anil > > On Apr 5, 2012, at 9:16 PM, Mahesh Akula wrote: > > Hi Anil, > > I have one question on draft-ietf-trill-rbridge-mib-07. > > In rbridgeSnoopingPortTable, I see that we are maintaining for each > Rbridge port, list of IP Multicast Router addresses connected to that port. > > From what I understand from RFC 6325 section 4.7 , > all we care is for each port, are there IP multicast routers connected and > their types( ipv4/ipv6/both), so that we can pass along reports > accordingly. It looks to me all we need is to maintain just one enum per > port with values (ipv4/ipv6/both). > > Why do we need to maintain all IP Multicast router addresses in TRILL MIB? > Any other reasons? > > Regards, > Mahesh > > > > > --e89a8f839ee323dbd004bcf9231f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Anil,
=A0
But there can be both ipv4/ipv6 multi= cast routers attached to that link right?=A0
=A0
>&= gt;=A0=A0 IP multicast data SHOULD only be sent on links where there is eit= her
=A0=A0 an IP multicast router for that IP type (IPv4 or IPv6) or ..
=A0
As the idea is=A0to forward the data (and reports)=A0only = if there is a router for that specific=A0IP type, it looks to me it is more= important to capture whether only one IP type of multicast router=A0is att= ached or both.
=A0
Also, as there can be more than one multicast router of = each IP type attached, capturing only one of them may not serve any purpose= IMO.
=A0
Regards,
Mahesh


= =A0
On Thu, Apr 5, 2012 at 6:43 PM, Anil Rijhsinghan= i <anil@charter.ne= t> wrote:
Mahesh,

As the INDEX= is rbridgeBasePort, there is a unique entry per port and we are only maint= aining per port the knowledge that there is at least one multicast router, = either v4 or v6, and which one it is (useful from a management perspective)= .=A0So it should not return a list of all IP multicast router addresses con= nected per port. The total number of entries in the table would be the numb= er of Rbridge ports on which snooping has detected an IP multicast router.<= /div>

Regards,
Anil

On Apr 5, 2012, at 9:16 PM, Mahesh Akula wrote:

Hi Anil,
=A0
I have one question on draft-ietf-trill-rbridge-mib-07.
=A0
In rbridgeSnoopingPortTable, I see that we are maintaining for each Rb= ridge port, list of IP Multicast Router addresses connected to that port. <= /div>
=A0
From what I understand from RFC 6325 section=A04.7=A0, all we ca= re is for each port, are there IP multicast routers connected and their typ= es( ipv4/ipv6/both), so that we can pass along reports accordingly.=A0 It= =A0looks to me all we need=A0is to maintain=A0just one enum per port with v= alues (ipv4/ipv6/both).
=A0
Why do we need to maintain all IP Multicast router addresses in TRILL = MIB? Any other reasons?
=A0
Regards,
Mahesh
=A0
=A0


--e89a8f839ee323dbd004bcf9231f-- --===============0188455988== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge --===============0188455988==-- From rbridge-bounces@postel.org Thu Apr 5 20:39:34 2012 Return-Path: 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 2C94511E8081 for ; Thu, 5 Apr 2012 20:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.505 X-Spam-Level: X-Spam-Status: No, score=-0.505 tagged_above=-999 required=5 tests=[AWL=3.045, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] 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 2rdamwfWUXoL for ; Thu, 5 Apr 2012 20:39:32 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4B621F8525 for ; Thu, 5 Apr 2012 20:39:32 -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 q363J1fb025343; Thu, 5 Apr 2012 20:19:03 -0700 (PDT) Received: from szxga04-in.huawei.com ([58.251.152.67]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q363IFo1024884 for ; Thu, 5 Apr 2012 20:18:24 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M2100LMUFUD4H@szxga04-in.huawei.com> for rbridge@postel.org; Fri, 06 Apr 2012 11:18:14 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M2100B2MFUD9G@szxga04-in.huawei.com> for rbridge@postel.org; Fri, 06 Apr 2012 11:18:13 +0800 (CST) Received: from szxeml212-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AID23334; Fri, 06 Apr 2012 11:18:12 +0800 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml212-edg.china.huawei.com (172.24.2.181) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 06 Apr 2012 11:17:54 +0800 Received: from SZXEML507-MBS.china.huawei.com ([169.254.7.100]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.003; Fri, 06 Apr 2012 11:18:08 +0800 Date: Fri, 06 Apr 2012 03:18:07 +0000 From: Mingui Zhang In-reply-to: <344037D7CFEFE84E97E9CC1F56C5F4A5E3B780@xmb-sjc-214.amer.cisco.com> X-Originating-IP: [10.108.4.73] To: "Tissa Senevirathne (tsenevir)" , Janardhanan Pathangi Narasimhan Message-id: <4552F0907735844E9204A62BBDD325E728CB37BE@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//+PaAIAAy5WsgAAUHfCAABB74IAAKcBDgAASQ3CAAUvIPoAAP81cgAAoPaCAACBD3IAAtGNggAAT3tCAAA2IQIAADzCAgAAD9ECAA6fZcIABd2IMgAACI9CABDHOkIAAfh4QgADH9oA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <344037D7CFEFE84E97E9CC1F56C5F4A5DA0303@xmb-sjc-214.amer.cisco.com> <4552F0907735844E9204A62BBDD325E728CAD030@SZXEML507-MBS.china.huawei.com> <344037D7CFEFE84E97E9CC1F56C5F4A5DA05D7@xmb-sjc-214.amer.cisco.com> <4552F0907735844E9204A62BBDD325E728CAE193@SZXEML507-MBS.china.huawei.com> <4552F0907735844E9204A62BBDD325E728CAE2F1@SZXEML507-MBS.china.huawei.com> <4552F0907735844E9204A62BBDD325E728CAE77F@SZXEML507-MBS.china.huawei.com> <4552F0907735844E9204A62BBDD325E728CB086C@SZXEML507-MBS.china.huawei.com> <"CE35792847FBE846 8 7FF9117 13 2C8EFD471 144 1520"@EXCH-CLUSTER-11.force10networks.com> <4552F0907735844E9204A62BBDD325E728CB0B20@SZXEML507-MBS.china.huawei.com> <344037D7CFEFE84E97E9CC1F56C5F4A5DA122A@xmb-sjc-214.amer.cisco.com> <4552F0907735844E9204A62BBDD325E728CB1FA4@SZXEML507-MBS.china.huawei.com> <344037D7CFEFE84E97E9CC1F56C5F4A5E3ACD9@xmb-sjc-214.amer.cisco.com> <4552F0907735844E9204A62BBDD325E728CB35A1@SZXEML507-MBS.china.huawei.com> <344037D7CFEFE84E97E9CC1F56C5F4A5E3B780@xmb-sjc-214.amer.cisco.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 q363IFo1024884 Cc: "rbridge@postel.org" Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1741134455==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org --===============1741134455== Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-Transfer-Encoding: 8bit Tissa, That is why I use an "If" to start that sentence. When you referred to it, you omitted that word. I believe multi-topology is very important to TRILL and customers. We are going to work on it in the near future. If you ever looked at the individual drafts submitted for this WG, you would find there was a draft http://tools.ietf.org/html/draft-eastlake-trill-rbridge-multi-topo-02. I believe it was written up for making multi-topology TRILL a reality. Thanks, Mingui > -----Original Message----- > From: Tissa Senevirathne (tsenevir) [mailto:tsenevir@cisco.com] > Sent: Thursday, April 05, 2012 10:37 PM > To: Mingui Zhang; Janardhanan Pathangi Narasimhan > Cc: rbridge@postel.org > Subject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > Mingui > > I choose only to answer your last question on "MT is already supported in > TRILL". Why are you saying that ? I do not see any RFC or WG document ? > > -----Original Message----- > From: Mingui Zhang [mailto:zhangmingui@huawei.com] > Sent: Thursday, April 05, 2012 1:53 AM > To: Tissa Senevirathne (tsenevir); Janardhanan Pathangi Narasimhan > Cc: rbridge@postel.org > Subject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > Hi Tissa, > > If one tries hard to search, then he will find each solution has its drawbacks. > The reluctance to deploy MT maybe a problem to MTRA, I agree with you. But, > as I had pointed out in my draft, MTRA is capable to be run in the same > campus and uses other solutions in the base topology. However, I need to > pointed out that the reason why there are not many L3 MT is a historical one. > For switches/bridges, especially when they are used in data center networks, > ECMP and multi-path features are highly desired. For the benefit of the WG, I > don't want to mention the names of TRILL pre-standard implementations and > devices that work like TRILL from other SDOs. I think you can find examples > that support MT. We can talk about this problem offline. > > Personally, the WG voting should not be used as a tool to endorse a solution > before WG members are clear that it is workable and there are other > competing solutions working for an overlapping problem space. IMHO, > competing solutions should be merged or adopted as alternatives. Just as that > we allow cheap local-brand cars to run on same roads along with BMWs. Let > customers make choices themselves. > > Before the final WG decision is made, let me outline the winning advantages > of MTRA for the WG members to consider. > 1. MTRA is incremental deploy-able. It allows other non-MTRA RBridges exist > in the same campus as transit or edge nodes. The solutions to communicate > with non-MTRA are depicted in the email to Jon, you can find it. > 2. MTRA realizes traffic segregation which guarantees that a LAG link failure is > isolated in a specific topology. > 3. MTRA is able to converge fast when there is a node/link failure of the > aggregation. > 4. If MT is already supported by TRILL, no extra TLVs are needed. > > Thanks, > Mingui > > > > -----Original Message----- > > From: Tissa Senevirathne (tsenevir) [mailto:tsenevir@cisco.com] > > Sent: Monday, April 02, 2012 11:14 PM > > To: Mingui Zhang; Janardhanan Pathangi Narasimhan > > Cc: rbridge@postel.org > > Subject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > > > Hi Mingui > > > > > > > > You are assuming a lot. > > > > That is: > > > > 1. People will deploy Multi-topology when they need active-active > > forwarding. > > > > 2. It is easy to deploy and people will like it > > > > 3. It is already out there > > > > > > > > #2 you can check % vise how many MT installations there in L3 world. > > > > > > > > Again I would summarize CMT need only one TLV, MT require lot more > TLV > > and require major changes to RFC6326 control plane. > > > > > > > > Backward compatibility of control plane in my world is not an issue as we > are > > exchanging more emails than really trying to deploy RBridges and there > are no > > RBridges there forwarding packets in real networks. > > > > > > > > However, your claim that MT is backward compatible without any tweaks > is > > false (Jana has pointed out several times). > > > > > > > > Like I have said, many times before, MT approach you have may be > utilized > > for active-active forwarding in MT installations. I will support that > solution as > > an optimization for MT, certainly I **do not** support it as the only > solution > > for all active-active deployments. If we agree on that then we have > consensus > > and both work can move forward (we need to make progress). If not > then we > > can continue to disagree and I request WG chairs to decide via a vote on > > making CMT a WG document. > > > > > > > > > > > > Thanks > > > > Tissa > > > > From: Mingui Zhang [mailto:zhangmingui@huawei.com] > > Sent: Monday, April 02, 2012 7:54 AM > > To: Tissa Senevirathne (tsenevir); Janardhanan Pathangi Narasimhan > > Cc: rbridge@postel.org > > Subject: 答复: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > > > > > > > Hi Tissa, > > > > > > > > We know that RBridge Aggregation is used to increase the access > capacity > > without upgrade of the RBridges. The motivation is the same as the > traditional > > LAG: it will help customers to reduce their investment. If active-active > > multi-homing can work well, customers will eager to purchase MT > feature. It > > may even act as a factor that promotes MT-TRILL, who knows. > > > > > > > > On the other hand, since MTRA is backward compatible, it allows other > > non-MTRA solutions co-exist in the campus. These solutions work in the > base > > topology. These solutions may include tunneling approach. As we know, > > tunneling had been widely used on traditional switches. If there are > > customers who really do not like MT, just use tunneling approach or > others. > > > > > > > > However, I don't think that multi-topology is that expensive. I believe > you > > have heard of silicons or implementations already support > multi-topology > > feature before 2010 when RFC 6325 was published. > > > > > > > > Thanks, > > > > Mingui > > > > > > > > ________________________________ > > > > 发件人: Tissa Senevirathne (tsenevir) [tsenevir@cisco.com] > > 发送时间: 2012年4月2日 0:27 > > 到: Janardhanan Pathangi Narasimhan; Mingui Zhang > > Cc: rbridge@postel.org > > 主题: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > > > Hi Mingui > > > > > > > > I have not seen an answer for the questions below could you please > answer > > simple question: > > > > > > > > What is your proposal for active-active for people who do not want to > run > > multi-topology ? > > > > > > > > From: Tissa Senevirathne (tsenevir) > > Sent: Friday, March 30, 2012 1:37 AM > > To: Tissa Senevirathne (tsenevir); 'Janardhanan Pathangi Narasimhan'; > 'Mingui > > Zhang' > > Cc: 'rbridge@postel.org' > > Subject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > > > > > > > Small typo correction > > > > > > > > From: Tissa Senevirathne (tsenevir) > > Sent: Friday, March 30, 2012 1:25 AM > > To: 'Janardhanan Pathangi Narasimhan'; Mingui Zhang > > Cc: rbridge@postel.org > > Subject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > > > > > > > Jana is absolutely correct on the observation below. > > > > > > > > One more point to add, as have indicated earlier > > > > > > > > 1. Not all customer will run multi-topology > > > > 2. You cannot force customers to run multi-topology when they > need > > active-active forwarding > > > > 3. What is your solution for customers who *do NOT* want to > run > > multi-topology ? > > > > > > > > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] > On > > Behalf Of Janardhanan Pathangi Narasimhan > > Sent: Friday, March 30, 2012 12:30 AM > > To: Mingui Zhang > > Cc: rbridge@postel.org > > Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > > > > > > > Hi Mingui > > > > > > > > When you realize active-active, you are asking for the active-active to > be > > setup in a new topology and not the base topology. So these nodes > which > > need to talk to the other nodes which are behind non-MT RBridges > cannot do > > so any more. > > > > > > > > Specifically for MT to be backward compatible, you need all nodes > which > > want to talk to each other part of the base topology. If you do that you > cannot > > realize active-active. If you put the active-active in a new topology, than > they > > can no longer talk to nodes on the base topology of non-MT RBridges. > > > > > > > > So yes, MT-TRILL is backward compatible for base topology, but the > realization > > of active-active with MT – TRILL is not backward compatible. That was > the > > point I was bringing up. > > > > > > > > Thanks > > > > Jana > > > > > > > > > > > > From: Mingui Zhang [mailto:zhangmingui@huawei.com] > > Sent: Friday, March 30, 2012 12:15 PM > > To: Janardhanan Pathangi Narasimhan > > Cc: rbridge@postel.org > > Subject: 答复: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > > > > > > > Hi Jana, > > > > > > > > All RBridges in the campus are in the base topology. MT RBridges can well > > communicate with non-MT RBridges using the base topology. > > > > > > > > I feel that you are arguing that MT-TRILL is not backward compatible. > That is a > > incorrect judgement. > > > > > > > > Thanks, > > > > Mingui > > > > ________________________________ > > > > 发件人: Janardhanan Pathangi Narasimhan > [jana@force10networks.com] > > 发送时间: 2012年3月30日 13:29 > > 到: Mingui Zhang > > Cc: rbridge@postel.org > > 主题: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > > > Hi Mingui, > > > > > > > > With MT approach, when two RBridges which had stations talking to > each > > other and one of them is converted to MT, then the communication is > broken. > > So it does not have backward computability. > > > > > > > > Thanks > > > > Jana > > > > > > > > > > > > From: Mingui Zhang [mailto:zhangmingui@huawei.com] > > Sent: Friday, March 30, 2012 12:27 AM > > To: Janardhanan Pathangi Narasimhan > > Cc: rbridge@postel.org > > Subject: 答复: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > > > > > > > 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 > > > > --===============1741134455== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge --===============1741134455==-- From rbridge-bounces@postel.org Fri Apr 6 02:39:35 2012 Return-Path: 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 507D621F8643 for ; Fri, 6 Apr 2012 02:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.239 X-Spam-Level: X-Spam-Status: No, score=-100.239 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100, WEIRD_QUOTING=1.396] 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 fEKCnXBpYMsF for ; Fri, 6 Apr 2012 02:39:34 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 63B1021F863E for ; Fri, 6 Apr 2012 02:39:34 -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 q369F2uK017607; Fri, 6 Apr 2012 02:15:04 -0700 (PDT) Received: from mx8.zte.com.cn (mx9.zte.com.cn [58.60.230.102]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q369ETMG017517; Fri, 6 Apr 2012 02:14:39 -0700 (PDT) Received: from [10.30.3.21] by [192.168.164.15] with StormMail ESMTP id 14085.2642532086; Fri, 6 Apr 2012 16:59:07 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q369E75X052148; Fri, 6 Apr 2012 17:14:07 +0800 (GMT-8) (envelope-from zhai.hongjun@zte.com.cn) In-Reply-To: To: Donald Eastlake MIME-Version: 1.0 X-KeepSent: 44A8F542:9B263920-482579D8:00329F97; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhai.hongjun@zte.com.cn Date: Fri, 6 Apr 2012 17:14:02 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-06 17:14:09, Serialize complete at 2012-04-06 17:14:09 X-MAIL: mse02.zte.com.cn q369E75X052148 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: zhai.hongjun@zte.com.cn Cc: rbridge@postel.org, rbridge-bounces@postel.org Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0830381824==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org This is a multipart message in MIME format. --===============0830381824== Content-Type: multipart/alternative; boundary="=_alternative 003311AB482579D8_=" This is a multipart message in MIME format. --=_alternative 003311AB482579D8_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 PiBGb3IgdGhlIGNhc2Ugd2hlcmUgdGhlIFJCcmlkZ2VzIGFyZSBhZGphY2VudCBhbmQgeW91IGNv dWxkIGVhc2lseSBoYXZlIGEgDQpwc2V1ZG8gbm9kZSwgSQ0KPiBiZWxpZXZlIGEgc2VwYXJhdGUg ZHJhZnQgaXMgbmVlZGVkLiBJIHRlbmQgdG8gdGhpbmsgdGhhdCBzdWNoIGEgZHJhZnQNCj4gd291 bGQgcHJvYmFibHkgZW5kIHVwIHVzaW5nIHRoZSBDTVQgc3ViLVRMViBidXQgaXQgbWlnaHQgbm90 Lg0KDQpUaGUgdXNpbmcgb2YgQ01UIHN1Yi1UTFYgaW4gUE4gZHJhZnQgaGFzIGJlZW4gZGljdXNz ZWQgYW1vbmcgdGhlIGF1dGhvcnMgDQpvZiBDTVQgYW5kIFBOIGRyYWZ0cy4gSW4gdGhlIG5leHQg dmVyc2lvbiBvZiBQTiBkcmFmdCwgd2Ugd2lsbCB1c2UgQ01UIA0Kc3ViLVRMViB0byBzbG92ZSB0 aGUgUlBGIGFuZCBtYWtlIFBOIGEgbW9yZSBjb21tb24gZnJhbWV3b3JrIGZvciBib3RoIA0KcHQt cHQgYW5kIG11bHRpLWFjY2VzcyBMQU4uDQoNCg0KDQpUaGFua3MsDQpaaGFpIEhvbmdqdW4NCiIi IiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIi IiIiIiIiIiIiIiINCiBQcm90b2NvbCBEZXZlbG9wbWVudCBEZXB0LlZJLCBDZW50cmFsIFImRCBJ bnN0aXR1dGUsIFpURSBDb3Jwb3JhdGlvbg0KIE5vLiA2OCwgWmlqaW5naHVhIFJvYWQsIFl1aHVh dGFpIERpc3RyaWN0LCBOYW5qaW5nLCBQLlIuQ2hpbmEsIDIxMDAxMg0KIA0KIFpoYWkgSG9uZ2p1 bg0KIA0KIFRlbDogKzg2LTI1LTUyODc3MzQ1DQogRW1haWw6IHpoYWkuaG9uZ2p1bkB6dGUuY29t LmNuDQoiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIi IiIiIiIiIiIiIiIiIiIiIiIiIg0KDQoNCg0KDQoNCkRvbmFsZCBFYXN0bGFrZSA8ZDNlM2UzQGdt YWlsLmNvbT4gDQq3orz+yMs6ICByYnJpZGdlLWJvdW5jZXNAcG9zdGVsLm9yZw0KMjAxMi0wNC0w NiAwMzo0Nw0KDQrK1bz+yMsNCnJicmlkZ2VAcG9zdGVsLm9yZw0Ks63LzQ0KDQrW98ziDQpSZTog W3JicmlkZ2VdIENhbGwgZm9yIGRyYWZ0LXRpc3NhLXRyaWxsLWNtdC0wMCB0byBXRyBkcmFmdA0K DQoNCg0KDQoNCg0KQWxsIG9mIHRoZSBwcm9wb3NhbHMgaGF2ZSBzb21lIGdvb2QgYW5kIGJhZCBm ZWF0dXJlcy4NCg0KVGhlIGFwcHJvdmFsIG9mIHRoZSBDTVQgZHJhZnQgYXMgYSB3b3JraW5nIGdy b3VwIGRyYWZ0IGlzIG5vdCBmaW5hbA0KYXBwcm92YWwgdG8gcmVxdWVzdCBSRkMgcHVibGljYXRp b24uIEkgdGhpbmsgdGhlIENNVCBkcmFmdCBuZWVkcyBzb21lDQptb3JlIHdvcmsgcGFydGljdWxh cmx5IHRvIGNvdmVyIGZhaWx1cmUgY2FzZXMuDQoNCkkgZG9uJ3QgdGhpbmsgdGhlIFdHIGhhcyBk ZWNpZGVkIHRoZSBkZXRhaWxzIG9mIG11bHRpLXRvcG9sb2d5IHlldC4NCklmLCB3aGVuIGl0IGRv ZXMgc28sIE1UIHByb3ZpZGVzIGEgc2ltcGxlciB3YXkgdG8gZG8gd2hhdCB0aGUgQ01UDQpkcmFm dCBkb2VzLCB0aGVuIEkgdGhpbmsgdGhvc2UgdXNpbmcgbXVsdGktdG9wb2xvZ3kgc2hvdWxkIGJl IGFibGUgdG8NCnVzZSB0aGF0IHRlY2huaXF1ZSB0byBzb2x2ZSB0aGlzIHByb2JsZW0uDQoNCkkg YmVsaWV2ZSB0aGUgQ01UIGRyYWZ0IG9ubHkgY292ZXJzIGNhc2VzIHdoZXJlIHRoZSBSQnJpZGdl cyBhcmUgbm90DQphZGphY2VudCBpbiB0aGF0IHRoZXkgY2FuJ3Qgc2VlIGVhY2ggb3RoZXIncyBI ZWxsb3MuIChZb3UgbWlnaHQgcmVmZXINCnRvIHRoaXMgY2FzZSBieSB0aGUgb3h5bW9yb25pYyB0 ZXJtICJvcGFxdWUgbGluayIuKSBGb3IgdGhlIGNhc2Ugd2hlcmUNCnRoZSBSQnJpZGdlcyBhcmUg YWRqYWNlbnQgYW5kIHlvdSBjb3VsZCBlYXNpbHkgaGF2ZSBhIHBzZXVkbyBub2RlLCBJDQpiZWxp ZXZlIGEgc2VwYXJhdGUgZHJhZnQgaXMgbmVlZGVkLiBJIHRlbmQgdG8gdGhpbmsgdGhhdCBzdWNo IGEgZHJhZnQNCndvdWxkIHByb2JhYmx5IGVuZCB1cCB1c2luZyB0aGUgQ01UIHN1Yi1UTFYgYnV0 IGl0IG1pZ2h0IG5vdC4NCg0KVGhhbmtzLA0KRG9uYWxkDQo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0KIERvbmFsZCBFLiBFYXN0bGFrZSAzcmQgICArMS01MDgtMzMzLTIyNzAgKGNlbGwp DQogMTU1IEJlYXZlciBTdHJlZXQsIE1pbGZvcmQsIE1BIDAxNzU3IFVTQQ0KIGQzZTNlM0BnbWFp bC5jb20NCg0KT24gTW9uLCBNYXIgMjYsIDIwMTIgYXQgNjozOCBQTSwgRG9uYWxkIEVhc3RsYWtl IDxkM2UzZTNAZ21haWwuY29tPiB3cm90ZToNCj4gRHVyaW5nIHRoZSBUUklMTCBzZXNzaW9uIHRv ZGF5LCB0aGVyZSB3YXMgYSBjb25zZW5zdXMgb2YgdGhvc2UgaW4gdGhlDQo+IHJvb20gdG8gbWFr ZSBkcmFmdC10aXNzYS10cmlsbC1jbXQtMDAudHh0IGEgVFJJTEwgV0cgZHJhZnQuIFRoaXMgaXMg YQ0KPiBjYWxsIG9uIHRoZSBXRyBtYWlsaW5nIGxpc3QgdG8gY29uZmlybSB0aGF0IGNvbnNlbnN1 cy4gSWYgeW91IHdpc2ggdG8NCj4gcmVzcG9uZCwgcGxlYXNlIGRvIHNvIGJ5IEFwcmlsIDEwdGgu DQo+DQo+IFRoYW5rcywNCj4gRG9uYWxkDQo+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09 DQo+ICBEb25hbGQgRS4gRWFzdGxha2UgM3JkICAgKzEtNTA4LTMzMy0yMjcwIChjZWxsKQ0KPiAg MTU1IEJlYXZlciBTdHJlZXQsIE1pbGZvcmQsIE1BIDAxNzU3IFVTQQ0KPiAgZDNlM2UzQGdtYWls LmNvbQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K cmJyaWRnZSBtYWlsaW5nIGxpc3QNCnJicmlkZ2VAcG9zdGVsLm9yZw0KaHR0cDovL21haWxtYW4u cG9zdGVsLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JicmlkZ2UNCg0KDQoNCg0KDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9y bWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlz IG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRo aXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBh Ym92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0 dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3Ro ZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNv bmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlk dWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9m IHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhv c2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5u ZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 003311AB482579D8_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEZvciB0aGUgY2FzZSB3aGVyZSB0aGUgUkJyaWRn ZXMgYXJlIGFkamFjZW50DQphbmQgeW91IGNvdWxkIGVhc2lseSBoYXZlIGEgcHNldWRvIG5vZGUs IEk8YnI+DQomZ3Q7IGJlbGlldmUgYSBzZXBhcmF0ZSBkcmFmdCBpcyBuZWVkZWQuIEkgdGVuZCB0 byB0aGluayB0aGF0IHN1Y2ggYSBkcmFmdDxicj4NCiZndDsgd291bGQgcHJvYmFibHkgZW5kIHVw IHVzaW5nIHRoZSBDTVQgc3ViLVRMViBidXQgaXQgbWlnaHQgbm90LjwvZm9udD48L3R0Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGUgdXNpbmcgb2YgQ01UIHN1 Yi1UTFYgaW4gUE4gZHJhZnQNCmhhcyBiZWVuIGRpY3Vzc2VkIGFtb25nIHRoZSBhdXRob3JzIG9m IENNVCBhbmQgUE4gZHJhZnRzLiBJbiB0aGUgbmV4dCB2ZXJzaW9uDQpvZiBQTiBkcmFmdCwgd2Ug d2lsbCB1c2UgQ01UIHN1Yi1UTFYgdG8gc2xvdmUgdGhlIFJQRiBhbmQgbWFrZSBQTiBhIG1vcmUN CmNvbW1vbiBmcmFtZXdvcmsgZm9yIGJvdGggcHQtcHQgYW5kIG11bHRpLWFjY2VzcyBMQU4uPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8YnI+DQo8YnI+ DQpUaGFua3MsPGJyPg0KWmhhaSBIb25nanVuPGJyPg0KJnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7 JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1 b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7 JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1 b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7 JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1 b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7 JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7PGJy Pg0KIFByb3RvY29sIERldmVsb3BtZW50IERlcHQuVkksIENlbnRyYWwgUiZhbXA7RCBJbnN0aXR1 dGUsIFpURSBDb3Jwb3JhdGlvbjxicj4NCiBOby4gNjgsIFppamluZ2h1YSBSb2FkLCBZdWh1YXRh aSBEaXN0cmljdCwgTmFuamluZywgUC5SLkNoaW5hLCAyMTAwMTI8YnI+DQogPGJyPg0KIFpoYWkg SG9uZ2p1bjxicj4NCiA8YnI+DQogVGVsOiArODYtMjUtNTI4NzczNDU8YnI+DQogRW1haWw6IHpo YWkuaG9uZ2p1bkB6dGUuY29tLmNuPGJyPg0KJnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7 JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1 b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7 JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1 b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7 JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1 b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7 JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7PGJy Pg0KPGJyPg0KPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0zNiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPjxiPkRvbmFsZCBFYXN0bGFrZSAmbHQ7ZDNlM2UzQGdtYWlsLmNvbSZndDs8L2I+DQo8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7cmJy aWRnZS1ib3VuY2VzQHBvc3RlbC5vcmc8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+MjAxMi0wNC0wNiAwMzo0NzwvZm9udD4NCjx0ZCB3aWR0aD02MyU+DQo8dGFibGUg d2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5yYnJpZGdlQHBvc3RlbC5vcmc8L2ZvbnQ+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4N CjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2Zv bnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBbcmJyaWRn ZV0gQ2FsbCBmb3IgZHJhZnQtdGlzc2EtdHJpbGwtY210LTAwDQp0byBXRyBkcmFmdDwvZm9udD48 L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJs ZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+QWxsIG9m IHRoZSBwcm9wb3NhbHMgaGF2ZSBzb21lIGdvb2QgYW5kIGJhZCBmZWF0dXJlcy48YnI+DQo8YnI+ DQpUaGUgYXBwcm92YWwgb2YgdGhlIENNVCBkcmFmdCBhcyBhIHdvcmtpbmcgZ3JvdXAgZHJhZnQg aXMgbm90IGZpbmFsPGJyPg0KYXBwcm92YWwgdG8gcmVxdWVzdCBSRkMgcHVibGljYXRpb24uIEkg dGhpbmsgdGhlIENNVCBkcmFmdCBuZWVkcyBzb21lPGJyPg0KbW9yZSB3b3JrIHBhcnRpY3VsYXJs eSB0byBjb3ZlciBmYWlsdXJlIGNhc2VzLjxicj4NCjxicj4NCkkgZG9uJ3QgdGhpbmsgdGhlIFdH IGhhcyBkZWNpZGVkIHRoZSBkZXRhaWxzIG9mIG11bHRpLXRvcG9sb2d5IHlldC48YnI+DQpJZiwg d2hlbiBpdCBkb2VzIHNvLCBNVCBwcm92aWRlcyBhIHNpbXBsZXIgd2F5IHRvIGRvIHdoYXQgdGhl IENNVDxicj4NCmRyYWZ0IGRvZXMsIHRoZW4gSSB0aGluayB0aG9zZSB1c2luZyBtdWx0aS10b3Bv bG9neSBzaG91bGQgYmUgYWJsZSB0bzxicj4NCnVzZSB0aGF0IHRlY2huaXF1ZSB0byBzb2x2ZSB0 aGlzIHByb2JsZW0uPGJyPg0KPGJyPg0KSSBiZWxpZXZlIHRoZSBDTVQgZHJhZnQgb25seSBjb3Zl cnMgY2FzZXMgd2hlcmUgdGhlIFJCcmlkZ2VzIGFyZSBub3Q8YnI+DQphZGphY2VudCBpbiB0aGF0 IHRoZXkgY2FuJ3Qgc2VlIGVhY2ggb3RoZXIncyBIZWxsb3MuIChZb3UgbWlnaHQgcmVmZXI8YnI+ DQp0byB0aGlzIGNhc2UgYnkgdGhlIG94eW1vcm9uaWMgdGVybSAmcXVvdDtvcGFxdWUgbGluayZx dW90Oy4pIEZvciB0aGUgY2FzZQ0Kd2hlcmU8YnI+DQp0aGUgUkJyaWRnZXMgYXJlIGFkamFjZW50 IGFuZCB5b3UgY291bGQgZWFzaWx5IGhhdmUgYSBwc2V1ZG8gbm9kZSwgSTxicj4NCmJlbGlldmUg YSBzZXBhcmF0ZSBkcmFmdCBpcyBuZWVkZWQuIEkgdGVuZCB0byB0aGluayB0aGF0IHN1Y2ggYSBk cmFmdDxicj4NCndvdWxkIHByb2JhYmx5IGVuZCB1cCB1c2luZyB0aGUgQ01UIHN1Yi1UTFYgYnV0 IGl0IG1pZ2h0IG5vdC48YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KRG9uYWxkPGJyPg0KPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQombmJzcDtEb25hbGQgRS4gRWFzdGxha2UgM3Jk Jm5ic3A7Jm5ic3A7ICsxLTUwOC0zMzMtMjI3MCAoY2VsbCk8YnI+DQombmJzcDsxNTUgQmVhdmVy IFN0cmVldCwmbmJzcDtNaWxmb3JkLCBNQSAwMTc1NyBVU0E8YnI+DQombmJzcDtkM2UzZTNAZ21h aWwuY29tPGJyPg0KPGJyPg0KT24gTW9uLCBNYXIgMjYsIDIwMTIgYXQgNjozOCBQTSwgRG9uYWxk IEVhc3RsYWtlICZsdDtkM2UzZTNAZ21haWwuY29tJmd0Ow0Kd3JvdGU6PGJyPg0KJmd0OyBEdXJp bmcgdGhlIFRSSUxMIHNlc3Npb24gdG9kYXksIHRoZXJlIHdhcyBhIGNvbnNlbnN1cyBvZiB0aG9z ZSBpbg0KdGhlPGJyPg0KJmd0OyByb29tIHRvIG1ha2UgZHJhZnQtdGlzc2EtdHJpbGwtY210LTAw LnR4dCBhIFRSSUxMIFdHIGRyYWZ0LiBUaGlzIGlzDQphPGJyPg0KJmd0OyBjYWxsIG9uIHRoZSBX RyBtYWlsaW5nIGxpc3QgdG8gY29uZmlybSB0aGF0IGNvbnNlbnN1cy4gSWYgeW91IHdpc2gNCnRv PGJyPg0KJmd0OyByZXNwb25kLCBwbGVhc2UgZG8gc28gYnkgQXByaWwgMTB0aC48YnI+DQomZ3Q7 PGJyPg0KJmd0OyBUaGFua3MsPGJyPg0KJmd0OyBEb25hbGQ8YnI+DQomZ3Q7ID09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PGJyPg0KJmd0OyAmbmJzcDtEb25hbGQgRS4gRWFzdGxha2UgM3Jk Jm5ic3A7Jm5ic3A7ICsxLTUwOC0zMzMtMjI3MCAoY2VsbCk8YnI+DQomZ3Q7ICZuYnNwOzE1NSBC ZWF2ZXIgU3RyZWV0LCZuYnNwO01pbGZvcmQsIE1BIDAxNzU3IFVTQTxicj4NCiZndDsgJm5ic3A7 ZDNlM2UzQGdtYWlsLmNvbTxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KcmJyaWRnZSBtYWlsaW5nIGxpc3Q8YnI+DQpyYnJpZGdl QHBvc3RlbC5vcmc8YnI+DQpodHRwOi8vbWFpbG1hbi5wb3N0ZWwub3JnL21haWxtYW4vbGlzdGlu Zm8vcmJyaWRnZTxicj4NCjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjxwcmU+DQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRF Jm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJz cDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwm bmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtz ZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11 bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7 bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFp bnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0 dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2Ym bmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZu YnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZu YnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNw O2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2Ym bmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNw O3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91 Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJz cDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3Im bmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtl eHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhv c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5i c3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7 dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3Bh bSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 003311AB482579D8_=-- --===============0830381824== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge --===============0830381824==-- From rbridge-bounces@postel.org Fri Apr 6 05:05:09 2012 Return-Path: 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 CE89B21F85A1 for ; Fri, 6 Apr 2012 05:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4] 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 7rWJTur0jp9y for ; Fri, 6 Apr 2012 05:05:07 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id D35B621F859F for ; Fri, 6 Apr 2012 05:05:07 -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 q36BoSZw009516; Fri, 6 Apr 2012 04:50:29 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q36Bo1GV009439 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 6 Apr 2012 04:50:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=varshah@cisco.com; l=26160; q=dns/txt; s=iport; t=1333713010; x=1334922610; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=4VBcnNxPPG3/HFfJfSBVGr6aWMZbzQMuZF1jILciE38=; b=Trx8o8Trhlyn9182sbT8q6bNEHrkrA8WdU+TaSXKhIaYLtomCBJ494gy 5N7a6PxT7QQL8lW7jTMgWaan1sjOLKuvh6aU7KzpIxEnibL+UM9G/7Shv kvA20XmiZnLEfdRkeEmtTGnuyGipUv4V4/9Ou1HLHIDRbhjqb4ihw5yaL s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At8KAG/Xfk+tJXG//2dsb2JhbABFuAgBA4EMgQeCCQEBAQMBAQEBDwEHAx0CAREXCAEQBwYBCAkIAwEBAQ0bKAYKFQkIAQEEExsCBAGHXgMGBQuYfoEnlhYNiVOKJIEhFgOEcgSIWoUsh2aBEYoogxSBaYMHgTw X-IronPort-AV: E=Sophos;i="4.75,381,1330905600"; d="scan'208";a="72609448" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 06 Apr 2012 11:50:00 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id q36Bo0XX031642 for ; Fri, 6 Apr 2012 11:50:00 GMT Received: from xmb-rcd-209.cisco.com ([72.163.62.216]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Apr 2012 06:50:00 -0500 Received: from 10.21.88.155 ([10.21.88.155]) by XMB-RCD-209.cisco.com ([72.163.62.216]) with Microsoft Exchange Server HTTP-DAV ; Fri, 6 Apr 2012 11:49:59 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Fri, 06 Apr 2012 04:49:21 -0700 From: varshah To: Message-ID: Thread-Topic: rbridge Digest, Vol 95, Issue 11 Thread-Index: Ac0T6034SFljDH1qDkeyJEPPTEibdw== In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 06 Apr 2012 11:50:00.0152 (UTC) FILETIME=[654ED580:01CD13EB] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: varshah@cisco.com Subject: Re: [rbridge] rbridge Digest, Vol 95, Issue 11 X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org +1 for making draft-tissa-trill-cmt-00 a WG draft. Thanks, -Varun On 4/5/12 7:37 AM, "rbridge-request@postel.org" wrote: > Send rbridge mailing list submissions to > rbridge@postel.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mailman.postel.org/mailman/listinfo/rbridge > or, via email, send a message with subject or body 'help' to > rbridge-request@postel.org > > You can reach the person managing the list at > rbridge-owner@postel.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of rbridge digest..." > > > Today's Topics: > > 1. Re: Call for draft-tissa-trill-cmt-00 to WG draft > (Tissa Senevirathne (tsenevir)) > 2. Re: Call for draft-tissa-trill-cmt-00 to WG draft > (Tissa Senevirathne (tsenevir)) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 5 Apr 2012 07:28:38 -0700 > From: "Tissa Senevirathne (tsenevir)" > Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > To: "Ayan Banerjee (ayabaner)" , > > Message-ID: > <344037D7CFEFE84E97E9CC1F56C5F4A5E3B778@xmb-sjc-214.amer.cisco.com> > Content-Type: text/plain; charset="us-ascii" > > +1 vote in support. > > > > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Ayan Banerjee (ayabaner) > Sent: Wednesday, April 04, 2012 11:03 PM > To: rbridge@postel.org > Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > > > Yes, I believe that this is an important piece of the puzzle and should > be made a WG document. > > Thanks, > Ayan > ==== > > > > During the TRILL session today, there was a consensus of those in the > room to make draft-tissa-trill-cmt-00.txt a TRILL WG draft. This is a > call on the WG mailing list to confirm that consensus. If you wish to > respond, please do so by April 10th. > > Thanks, > Donald > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://mailman.postel.org/pipermail/rbridge/attachments/20120405/f43f46e0/atta > chment-0001.html > > ------------------------------ > > Message: 2 > Date: Thu, 5 Apr 2012 07:36:47 -0700 > From: "Tissa Senevirathne (tsenevir)" > Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > To: "Mingui Zhang" , "Janardhanan Pathangi > Narasimhan" > Cc: rbridge@postel.org > Message-ID: > <344037D7CFEFE84E97E9CC1F56C5F4A5E3B780@xmb-sjc-214.amer.cisco.com> > Content-Type: text/plain; charset="gb2312" > > Mingui > > I choose only to answer your last question on "MT is already supported in > TRILL". Why are you saying that ? I do not see any RFC or WG document ? > > -----Original Message----- > From: Mingui Zhang [mailto:zhangmingui@huawei.com] > Sent: Thursday, April 05, 2012 1:53 AM > To: Tissa Senevirathne (tsenevir); Janardhanan Pathangi Narasimhan > Cc: rbridge@postel.org > Subject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > Hi Tissa, > > If one tries hard to search, then he will find each solution has its > drawbacks. The reluctance to deploy MT maybe a problem to MTRA, I agree with > you. But, as I had pointed out in my draft, MTRA is capable to be run in the > same campus and uses other solutions in the base topology. However, I need to > pointed out that the reason why there are not many L3 MT is a historical one. > For switches/bridges, especially when they are used in data center networks, > ECMP and multi-path features are highly desired. For the benefit of the WG, I > don't want to mention the names of TRILL pre-standard implementations and > devices that work like TRILL from other SDOs. I think you can find examples > that support MT. We can talk about this problem offline. > > Personally, the WG voting should not be used as a tool to endorse a solution > before WG members are clear that it is workable and there are other competing > solutions working for an overlapping problem space. IMHO, competing solutions > should be merged or adopted as alternatives. Just as that we allow cheap > local-brand cars to run on same roads along with BMWs. Let customers make > choices themselves. > > Before the final WG decision is made, let me outline the winning advantages of > MTRA for the WG members to consider. > 1. MTRA is incremental deploy-able. It allows other non-MTRA RBridges exist in > the same campus as transit or edge nodes. The solutions to communicate with > non-MTRA are depicted in the email to Jon, you can find it. > 2. MTRA realizes traffic segregation which guarantees that a LAG link failure > is isolated in a specific topology. > 3. MTRA is able to converge fast when there is a node/link failure of the > aggregation. > 4. If MT is already supported by TRILL, no extra TLVs are needed. > > Thanks, > Mingui > > >> -----Original Message----- >> From: Tissa Senevirathne (tsenevir) [mailto:tsenevir@cisco.com] >> Sent: Monday, April 02, 2012 11:14 PM >> To: Mingui Zhang; Janardhanan Pathangi Narasimhan >> Cc: rbridge@postel.org >> Subject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft >> >> Hi Mingui >> >> >> >> You are assuming a lot. >> >> That is: >> >> 1. People will deploy Multi-topology when they need active-active >> forwarding. >> >> 2. It is easy to deploy and people will like it >> >> 3. It is already out there >> >> >> >> #2 you can check % vise how many MT installations there in L3 world. >> >> >> >> Again I would summarize CMT need only one TLV, MT require lot more TLV >> and require major changes to RFC6326 control plane. >> >> >> >> Backward compatibility of control plane in my world is not an issue as we are >> exchanging more emails than really trying to deploy RBridges and there are no >> RBridges there forwarding packets in real networks. >> >> >> >> However, your claim that MT is backward compatible without any tweaks is >> false (Jana has pointed out several times). >> >> >> >> Like I have said, many times before, MT approach you have may be utilized >> for active-active forwarding in MT installations. I will support that >> solution as >> an optimization for MT, certainly I **do not** support it as the only >> solution >> for all active-active deployments. If we agree on that then we have consensus >> and both work can move forward (we need to make progress). If not then we >> can continue to disagree and I request WG chairs to decide via a vote on >> making CMT a WG document. >> >> >> >> >> >> Thanks >> >> Tissa >> >> From: Mingui Zhang [mailto:zhangmingui@huawei.com] >> Sent: Monday, April 02, 2012 7:54 AM >> To: Tissa Senevirathne (tsenevir); Janardhanan Pathangi Narasimhan >> Cc: rbridge@postel.org >> Subject: ????: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft >> >> >> >> Hi Tissa, >> >> >> >> We know that RBridge Aggregation is used to increase the access capacity >> without upgrade of the RBridges. The motivation is the same as the >> traditional >> LAG: it will help customers to reduce their investment. If active-active >> multi-homing can work well, customers will eager to purchase MT feature. It >> may even act as a factor that promotes MT-TRILL, who knows. >> >> >> >> On the other hand, since MTRA is backward compatible, it allows other >> non-MTRA solutions co-exist in the campus. These solutions work in the base >> topology. These solutions may include tunneling approach. As we know, >> tunneling had been widely used on traditional switches. If there are >> customers who really do not like MT, just use tunneling approach or others. >> >> >> >> However, I don't think that multi-topology is that expensive. I believe you >> have heard of silicons or implementations already support multi-topology >> feature before 2010 when RFC 6325 was published. >> >> >> >> Thanks, >> >> Mingui >> >> >> >> ________________________________ >> >> ??????: Tissa Senevirathne (tsenevir) [tsenevir@cisco.com] >> ????????: 2012??4??2?? 0:27 >> ??: Janardhanan Pathangi Narasimhan; Mingui Zhang >> Cc: rbridge@postel.org >> ????: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft >> >> Hi Mingui >> >> >> >> I have not seen an answer for the questions below could you please answer >> simple question: >> >> >> >> What is your proposal for active-active for people who do not want to run >> multi-topology ? >> >> >> >> From: Tissa Senevirathne (tsenevir) >> Sent: Friday, March 30, 2012 1:37 AM >> To: Tissa Senevirathne (tsenevir); 'Janardhanan Pathangi Narasimhan'; 'Mingui >> Zhang' >> Cc: 'rbridge@postel.org' >> Subject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft >> >> >> >> Small typo correction >> >> >> >> From: Tissa Senevirathne (tsenevir) >> Sent: Friday, March 30, 2012 1:25 AM >> To: 'Janardhanan Pathangi Narasimhan'; Mingui Zhang >> Cc: rbridge@postel.org >> Subject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft >> >> >> >> Jana is absolutely correct on the observation below. >> >> >> >> One more point to add, as have indicated earlier >> >> >> >> 1. Not all customer will run multi-topology >> >> 2. You cannot force customers to run multi-topology when they need >> active-active forwarding >> >> 3. What is your solution for customers who *do NOT* want to run >> multi-topology ? >> >> >> >> From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On >> Behalf Of Janardhanan Pathangi Narasimhan >> Sent: Friday, March 30, 2012 12:30 AM >> To: Mingui Zhang >> Cc: rbridge@postel.org >> Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft >> >> >> >> Hi Mingui >> >> >> >> When you realize active-active, you are asking for the active-active to be >> setup in a new topology and not the base topology. So these nodes which >> need to talk to the other nodes which are behind non-MT RBridges cannot do >> so any more. >> >> >> >> Specifically for MT to be backward compatible, you need all nodes which >> want to talk to each other part of the base topology. If you do that you >> cannot >> realize active-active. If you put the active-active in a new topology, than >> they >> can no longer talk to nodes on the base topology of non-MT RBridges. >> >> >> >> So yes, MT-TRILL is backward compatible for base topology, but the >> realization >> of active-active with MT ?C TRILL is not backward compatible. That was the >> point I was bringing up. >> >> >> >> Thanks >> >> Jana >> >> >> >> >> >> From: Mingui Zhang [mailto:zhangmingui@huawei.com] >> Sent: Friday, March 30, 2012 12:15 PM >> To: Janardhanan Pathangi Narasimhan >> Cc: rbridge@postel.org >> Subject: ????: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft >> >> >> >> Hi Jana, >> >> >> >> All RBridges in the campus are in the base topology. MT RBridges can well >> communicate with non-MT RBridges using the base topology. >> >> >> >> I feel that you are arguing that MT-TRILL is not backward compatible. That is >> a >> incorrect judgement. >> >> >> >> Thanks, >> >> Mingui >> >> ________________________________ >> >> ??????: Janardhanan Pathangi Narasimhan [jana@force10networks.com] >> ????????: 2012??3??30?? 13:29 >> ??: Mingui Zhang >> Cc: rbridge@postel.org >> ????: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft >> >> Hi Mingui, >> >> >> >> With MT approach, when two RBridges which had stations talking to each >> other and one of them is converted to MT, then the communication is broken. >> So it does not have backward computability. >> >> >> >> Thanks >> >> Jana >> >> >> >> >> >> From: Mingui Zhang [mailto:zhangmingui@huawei.com] >> Sent: Friday, March 30, 2012 12:27 AM >> To: Janardhanan Pathangi Narasimhan >> Cc: rbridge@postel.org >> Subject: ????: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft >> >> >> >> 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 > > > End of rbridge Digest, Vol 95, Issue 11 > *************************************** _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge From rbridge-bounces@postel.org Fri Apr 6 05:33:30 2012 Return-Path: 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 60E0C21F8546 for ; Fri, 6 Apr 2012 05:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.266 X-Spam-Level: X-Spam-Status: No, score=-5.266 tagged_above=-999 required=5 tests=[AWL=1.334, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 9KW8JW+Brepr for ; Fri, 6 Apr 2012 05:33:29 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id AFD2421F8542 for ; Fri, 6 Apr 2012 05:33:29 -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 q36CNp9M014764; Fri, 6 Apr 2012 05:23:52 -0700 (PDT) Received: from mta31.charter.net (mta31.charter.net [216.33.127.82]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q36CNVTO014445 for ; Fri, 6 Apr 2012 05:23:40 -0700 (PDT) Received: from imp10 ([10.20.200.15]) by mta31.charter.net (InterMail vM.8.01.05.02 201-2260-151-103-20110920) with ESMTP id <20120406122329.EGRJ24708.mta31.charter.net@imp10>; Fri, 6 Apr 2012 08:23:29 -0400 Received: from [192.168.1.106] ([71.10.228.40]) by imp10 with smtp.charter.net id ucPV1i0070sw4rK05cPVEF; Fri, 06 Apr 2012 08:23:29 -0400 X-Authority-Analysis: v=1.1 cv=JYQIUidRAECiNa+jsiaNMIhYElg3H2WoMKCJIGO75f4= c=1 sm=1 a=HXW8s7Hvfe4A:10 a=yUnIBFQkZM0A:10 a=8nJEP1OIZ-IA:10 a=uxqmlfvtJbLpRWMvzcSYSQ==:17 a=oEQ2TvfSHUdwZXvcvIEA:9 a=wPNLvfGTeEIA:10 a=uxqmlfvtJbLpRWMvzcSYSQ==:117 Mime-Version: 1.0 (Apple Message framework v1257) From: Anil Rijhsinghani In-Reply-To: Date: Fri, 6 Apr 2012 08:23:28 -0400 Message-Id: <1692AF62-B4E9-4148-8A70-9E4A9A7C15D5@charter.net> References: To: Mahesh Akula X-Mailer: Apple Mail (2.1257) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: anil@charter.net X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id q36CNVTO014445 Cc: rbridge@postel.org Subject: Re: [rbridge] Question on draft-ietf-trill-rbridge-mib-07 X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org On Apr 5, 2012, at 10:08 PM, Mahesh Akula wrote: > >> IP multicast data SHOULD only be sent on links where there is either > an IP multicast router for that IP type (IPv4 or IPv6) or .. > > As the idea is to forward the data (and reports) only if there is a router for that specific IP type, it looks to me it is more important to capture whether only one IP type of multicast router is attached or both. After reading the protocol section again, I think I agree with you here and will accommodate the above in yet another revision. > Also, as there can be more than one multicast router of each IP type attached, capturing only one of them may not serve any purpose IMO. Capturing one is better than all of them, which I think was one of your original issues in this thread. The thought here was to record at least one so that a manager can do some correlation when there's multicasting going on. If a multicast is being forwarded, some additional data on why it's being forwarded would be useful. A switch need only know of one alive on a port, in order to continue multicasting on that port. You're not normally going to have lots of multicast routers on every link in any case. Given your first suggestion, we could add rbridgeSnoopingPortAddrType to the INDEX, thus allowing a single object to be returned per instance: the address of the router. What do you think? Regards, Anil _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge From rbridge-bounces@postel.org Fri Apr 6 15:08:37 2012 Return-Path: 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 DB14011E8099 for ; Fri, 6 Apr 2012 15:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 ea4MKyMzS1lx for ; Fri, 6 Apr 2012 15:08:37 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 1C40D11E8098 for ; Fri, 6 Apr 2012 15:08:37 -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 q36LkaQX004058; Fri, 6 Apr 2012 14:46:37 -0700 (PDT) Received: from mail-lpp01m010-f52.google.com (mail-lpp01m010-f52.google.com [209.85.215.52]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q36Ljxil004023 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 6 Apr 2012 14:46:09 -0700 (PDT) Received: by lahi5 with SMTP id i5so4222932lah.39 for ; Fri, 06 Apr 2012 14:45:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1Tzr2nx4ssjBFW6b7S1b6aKJwDzbaTfogU41pjIqIT0=; b=MojYKylrhxsybQJvijsApAxLN/afoVe+FyeNWxCTyDu9usP+VznwQ2k3mCQw/rDZrQ BqYaYvZNvh67cgG/ivG2GPBKvIhP5XrX8a6CrrylGD43rsPmXBNrU8ZGlD5xgsXNa1QR 0UtQ6mQ3ZdkNbavog49M/nkjmLxo8WBjEZ7QfAqvCR3N5LA/Qqq2dI1m2UpRrBN9c0Kg mQQUiTBYXzZmL/uHSfKrvP4Mi6CDl+5Uvc5N1FqbQu8vy6A2u8qvrI18jFdfKakZEmIL yr61RC0a0DtpkmtzhR7WKaLTDtU9k0Tfmu+3ghYO214r2g0imIa3zNRDde6VV7U30O16 3aRg== MIME-Version: 1.0 Received: by 10.152.125.41 with SMTP id mn9mr10660341lab.30.1333748758993; Fri, 06 Apr 2012 14:45:58 -0700 (PDT) Received: by 10.152.4.70 with HTTP; Fri, 6 Apr 2012 14:45:58 -0700 (PDT) In-Reply-To: <1692AF62-B4E9-4148-8A70-9E4A9A7C15D5@charter.net> References: <1692AF62-B4E9-4148-8A70-9E4A9A7C15D5@charter.net> Date: Fri, 6 Apr 2012 14:45:58 -0700 Message-ID: From: Mahesh Akula To: Anil Rijhsinghani X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: mahesh.akula36@gmail.com Cc: rbridge@postel.org Subject: Re: [rbridge] Question on draft-ietf-trill-rbridge-mib-07 X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0443828424==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org --===============0443828424== Content-Type: multipart/alternative; boundary=f46d042f9288ffdca104bd099425 --f46d042f9288ffdca104bd099425 Content-Type: text/plain; charset=ISO-8859-1 Hi Anil, On Fri, Apr 6, 2012 at 5:23 AM, Anil Rijhsinghani wrote: > On Apr 5, 2012, at 10:08 PM, Mahesh Akula wrote: > > > >> IP multicast data SHOULD only be sent on links where there is either > > an IP multicast router for that IP type (IPv4 or IPv6) or .. > > > > As the idea is to forward the data (and reports) only if there is a > router for that specific IP type, it looks to me it is more important to > capture whether only one IP type of multicast router is attached or both. > > After reading the protocol section again, I think I agree with you here > and will accommodate the above in yet another revision. > > > Also, as there can be more than one multicast router of each IP type > attached, capturing only one of them may not serve any purpose IMO. > > Capturing one is better than all of them, which I think was one of your > original issues in this thread. The thought here was to record at least one > so that a manager can do some correlation when there's multicasting going > on. If a multicast is being forwarded, some additional data on why it's > being forwarded would be useful. A switch need only know of one alive on a > port, in order to continue multicasting on that port. You're not normally > going to have lots of multicast routers on every link in any case. Given > your first suggestion, we could add rbridgeSnoopingPortAddrType to the > INDEX, thus allowing a single object to be returned per instance: the > address of the router. What do you think? > [MA]: I personally still feel that we should just maintain only enum per port (ipv4/ipv6/both). Because If there are multiple routers attached, the value of the address will be non deterministic IMO. But I dont see any harm in having it otherwise. Thank you, Regards, Mahesh > > Regards, > Anil > > --f46d042f9288ffdca104bd099425 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Anil,

On Fri, Apr 6, 2012 at 5:23 AM, Anil Rijhsinghan= i <anil@charter.ne= t> wrote:
On Apr 5, 2012, at 10:08 PM, Mahesh Akula wrote:

&= gt; >> =A0 IP multicast data SHOULD only be sent on links where there= is either
> =A0 =A0an IP multicast router for that IP type (IPv4 or = IPv6) or ..
>
> As the idea is to forward the data (and reports) only if there= is a router for that specific IP type, it looks to me it is more important= to capture whether only one IP type of multicast router is attached or bot= h.

After reading the protocol section again, I think I agree with yo= u here and will accommodate the above in yet another revision.

> Also, as there can be more than one multicast ro= uter of each IP type attached, capturing only one of them may not serve any= purpose IMO.

Capturing one is better than all of them, which = I think was one of your original issues in this thread. The thought here wa= s to record at least one so that a manager can do some correlation when the= re's multicasting going on. If a multicast is being forwarded, some add= itional data on why it's being forwarded would be useful. A switch need= only know of one alive on a port, in order to continue multicasting on tha= t port. You're not normally going to have lots of multicast routers on = every link in any case. Given your first suggestion, we could add rbridgeSn= oopingPortAddrType to the INDEX, thus allowing a single object to be return= ed per instance: the address of the router. What do you think?
=A0
[MA]: =A0I personally still feel that we should just maintain only enu= m per port (ipv4/ipv6/both). Because=A0If there are multiple routers attach= ed, the value of the address will be non deterministic IMO.=A0=A0But I dont= see any harm in having it otherwise.
=A0
Thank you,
=A0
Regards,
Mahesh

Regards,
Anil


--f46d042f9288ffdca104bd099425-- --===============0443828424== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge --===============0443828424==-- From rbridge-bounces@postel.org Fri Apr 6 20:16:38 2012 Return-Path: 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 9110921F846A for ; Fri, 6 Apr 2012 20:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.436 X-Spam-Level: X-Spam-Status: No, score=-3.436 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] 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 QSjD7KfTWR92 for ; Fri, 6 Apr 2012 20:16:36 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id B366621F8469 for ; Fri, 6 Apr 2012 20:16:36 -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 q3730DLS015008; Fri, 6 Apr 2012 20:00:15 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q372xfUk014962 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 6 Apr 2012 19:59:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tsenevir@cisco.com; l=30884; q=dns/txt; s=iport; t=1333767589; x=1334977189; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=mxA66xuTTvU1XbR5bmB082V3iZOq0hmZmKGSgrZ4Juw=; b=D7Uow9qYDhSgJmozGn1i076zcyNnLP9pJe4d7pkEXs/t04hJ2sLZo2Jc k5CR9xkDuwon5Cc6hpF6jO4/nQiT6XjhThDwWp5HQ1KNvF92+EoG/e4sP l3xr2W/ABREDzLd8G/GNOovaOcRCLxJpNM2c2njDDXv8h4ap7rxyEtZzi E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAEutf0+rRDoG/2dsb2JhbABDhXyzNoEHggkBAQEEEgEHAxM1CAwMBAIBBgIRBAEBBQYGFwEEAgEgJQkIAgQBEggTB4deAwoBC55ajQQIiG8NgWuBK4h5hRA5YwSIWo4jiiiDFIFpgweBPA X-IronPort-AV: E=Sophos;i="4.75,384,1330905600"; d="scan'208";a="39370558" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 07 Apr 2012 02:59:40 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q372xeLT025632; Sat, 7 Apr 2012 02:59:40 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Apr 2012 19:59:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 6 Apr 2012 19:59:38 -0700 Message-ID: <344037D7CFEFE84E97E9CC1F56C5F4A5EC1FFB@xmb-sjc-214.amer.cisco.com> In-Reply-To: <4552F0907735844E9204A62BBDD325E728CB37BE@SZXEML507-MBS.china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft Thread-Index: AQHNC6M4X8TnOZ/31Umc7no1WTsFHJZ9Cj0AgABclICAABKNgIABKjzxgAAYT0D//+PaAIAAy5WsgAAUHfCAABB74IAAKcBDgAASQ3CAAUvIPoAAP81cgAAoPaCAACBD3IAAtGNggAAT3tCAAA2IQIAADzCAgAAD9ECAA6fZcIABd2IMgAACI9CABDHOkIAAfh4QgADH9oCAAZqw4A== References: <344037D7CFEFE84E97E9CC1F56C5F4A5DA0303@xmb-sjc-214.amer.cisco.com> <4552F0907735844E9204A62BBDD325E728CAD030@SZXEML507-MBS.china.huawei.com> <344037D7CFEFE84E97E9CC1F56C5F4A5DA05D7@xmb-sjc-214.amer.cisco.com> <4552F0907735844E9204A62BBDD325E728CAE193@SZXEML507-MBS.china.huawei.com> <4552F0907735844E9204A62BBDD325E728CAE2F1@SZXEML507-MBS.china.huawei.com> <4552F0907735844E9204A62BBDD325E728CAE77F@SZXEML507-MBS.china.huawei.com> <4552F0907735844E9204A62BBDD325E728CB086C@SZXEML507-MBS.china.huawei.com> <"CE35792847FBE846 8 7FF911 7 13 2C8EFD4 71 144 1520"@EXCH-CLUSTER-11.force10networks.com> <4552F0907735844E9204A62BBDD325E728CB0B20@SZXEML507-MBS.china.huawei.com> <344037D7CFEFE84E97E9CC1F56C5F4A5DA122A@xmb-sjc-214.amer.cisco.com> <4552F0907735844E9204A62BBDD325E728CB1FA4@SZXEML507-MBS.china.huawei.com> <344037D7CFEFE84E97E9CC1F56C5F4A5E3ACD9@xmb-sjc-214.amer.cisco.com> <4552F0907735844E9204A62BBDD325E728CB35A1@SZXEML507-MBS.china.huawei.com> <344037D7CFEFE84E97E9CC1F56C5F4A5E3B780@xmb-sjc-214.amer.cisco.com> <4552F0907735844E9204A62BBDD325E728CB37BE@SZXEML507-MBS.china.huawei.com> From: "Tissa Senevirathne (tsenevir)" To: "Mingui Zhang" , "Janardhanan Pathangi Narasimhan" X-OriginalArrivalTime: 07 Apr 2012 02:59:39.0972 (UTC) FILETIME=[796A7040:01CD146A] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: tsenevir@cisco.com X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id q372xfUk014962 Cc: rbridge@postel.org Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1648739160==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org --===============1648739160== Content-class: urn:content-classes:message Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Mingui My last response on this subject: Basic point being: Not all customers going to run multi-topology. We need a solution for people who do not use multi-topology. Your solution does not work for the people who do not want to run MT. Having few drafts does not indicate any readiness of a solution nor acceptance of it nor deployment by all customers. I rest my case!. Thanks Tissa -----Original Message----- From: Mingui Zhang [mailto:zhangmingui@huawei.com] Sent: Thursday, April 05, 2012 8:18 PM To: Tissa Senevirathne (tsenevir); Janardhanan Pathangi Narasimhan Cc: rbridge@postel.org Subject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft Tissa, That is why I use an "If" to start that sentence. When you referred to it, you omitted that word. I believe multi-topology is very important to TRILL and customers. We are going to work on it in the near future. If you ever looked at the individual drafts submitted for this WG, you would find there was a draft http://tools.ietf.org/html/draft-eastlake-trill-rbridge-multi-topo-02. I believe it was written up for making multi-topology TRILL a reality. Thanks, Mingui > -----Original Message----- > From: Tissa Senevirathne (tsenevir) [mailto:tsenevir@cisco.com] > Sent: Thursday, April 05, 2012 10:37 PM > To: Mingui Zhang; Janardhanan Pathangi Narasimhan > Cc: rbridge@postel.org > Subject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > Mingui > > I choose only to answer your last question on "MT is already supported in > TRILL". Why are you saying that ? I do not see any RFC or WG document ? > > -----Original Message----- > From: Mingui Zhang [mailto:zhangmingui@huawei.com] > Sent: Thursday, April 05, 2012 1:53 AM > To: Tissa Senevirathne (tsenevir); Janardhanan Pathangi Narasimhan > Cc: rbridge@postel.org > Subject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > Hi Tissa, > > If one tries hard to search, then he will find each solution has its drawbacks. > The reluctance to deploy MT maybe a problem to MTRA, I agree with you. But, > as I had pointed out in my draft, MTRA is capable to be run in the same > campus and uses other solutions in the base topology. However, I need to > pointed out that the reason why there are not many L3 MT is a historical one. > For switches/bridges, especially when they are used in data center networks, > ECMP and multi-path features are highly desired. For the benefit of the WG, I > don't want to mention the names of TRILL pre-standard implementations and > devices that work like TRILL from other SDOs. I think you can find examples > that support MT. We can talk about this problem offline. > > Personally, the WG voting should not be used as a tool to endorse a solution > before WG members are clear that it is workable and there are other > competing solutions working for an overlapping problem space. IMHO, > competing solutions should be merged or adopted as alternatives. Just as that > we allow cheap local-brand cars to run on same roads along with BMWs. Let > customers make choices themselves. > > Before the final WG decision is made, let me outline the winning advantages > of MTRA for the WG members to consider. > 1. MTRA is incremental deploy-able. It allows other non-MTRA RBridges exist > in the same campus as transit or edge nodes. The solutions to communicate > with non-MTRA are depicted in the email to Jon, you can find it. > 2. MTRA realizes traffic segregation which guarantees that a LAG link failure is > isolated in a specific topology. > 3. MTRA is able to converge fast when there is a node/link failure of the > aggregation. > 4. If MT is already supported by TRILL, no extra TLVs are needed. > > Thanks, > Mingui > > > > -----Original Message----- > > From: Tissa Senevirathne (tsenevir) [mailto:tsenevir@cisco.com] > > Sent: Monday, April 02, 2012 11:14 PM > > To: Mingui Zhang; Janardhanan Pathangi Narasimhan > > Cc: rbridge@postel.org > > Subject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > > > Hi Mingui > > > > > > > > You are assuming a lot. > > > > That is: > > > > 1. People will deploy Multi-topology when they need active-active > > forwarding. > > > > 2. It is easy to deploy and people will like it > > > > 3. It is already out there > > > > > > > > #2 you can check % vise how many MT installations there in L3 world. > > > > > > > > Again I would summarize CMT need only one TLV, MT require lot more > TLV > > and require major changes to RFC6326 control plane. > > > > > > > > Backward compatibility of control plane in my world is not an issue as we > are > > exchanging more emails than really trying to deploy RBridges and there > are no > > RBridges there forwarding packets in real networks. > > > > > > > > However, your claim that MT is backward compatible without any tweaks > is > > false (Jana has pointed out several times). > > > > > > > > Like I have said, many times before, MT approach you have may be > utilized > > for active-active forwarding in MT installations. I will support that > solution as > > an optimization for MT, certainly I **do not** support it as the only > solution > > for all active-active deployments. If we agree on that then we have > consensus > > and both work can move forward (we need to make progress). If not > then we > > can continue to disagree and I request WG chairs to decide via a vote on > > making CMT a WG document. > > > > > > > > > > > > Thanks > > > > Tissa > > > > From: Mingui Zhang [mailto:zhangmingui@huawei.com] > > Sent: Monday, April 02, 2012 7:54 AM > > To: Tissa Senevirathne (tsenevir); Janardhanan Pathangi Narasimhan > > Cc: rbridge@postel.org > > Subject: 答复: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > > > > > > > Hi Tissa, > > > > > > > > We know that RBridge Aggregation is used to increase the access > capacity > > without upgrade of the RBridges. The motivation is the same as the > traditional > > LAG: it will help customers to reduce their investment. If active-active > > multi-homing can work well, customers will eager to purchase MT > feature. It > > may even act as a factor that promotes MT-TRILL, who knows. > > > > > > > > On the other hand, since MTRA is backward compatible, it allows other > > non-MTRA solutions co-exist in the campus. These solutions work in the > base > > topology. These solutions may include tunneling approach. As we know, > > tunneling had been widely used on traditional switches. If there are > > customers who really do not like MT, just use tunneling approach or > others. > > > > > > > > However, I don't think that multi-topology is that expensive. I believe > you > > have heard of silicons or implementations already support > multi-topology > > feature before 2010 when RFC 6325 was published. > > > > > > > > Thanks, > > > > Mingui > > > > > > > > ________________________________ > > > > 发件人: Tissa Senevirathne (tsenevir) [tsenevir@cisco.com] > > 发送时间: 2012年4月2日 0:27 > > 到: Janardhanan Pathangi Narasimhan; Mingui Zhang > > Cc: rbridge@postel.org > > 主题: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > > > Hi Mingui > > > > > > > > I have not seen an answer for the questions below could you please > answer > > simple question: > > > > > > > > What is your proposal for active-active for people who do not want to > run > > multi-topology ? > > > > > > > > From: Tissa Senevirathne (tsenevir) > > Sent: Friday, March 30, 2012 1:37 AM > > To: Tissa Senevirathne (tsenevir); 'Janardhanan Pathangi Narasimhan'; > 'Mingui > > Zhang' > > Cc: 'rbridge@postel.org' > > Subject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > > > > > > > Small typo correction > > > > > > > > From: Tissa Senevirathne (tsenevir) > > Sent: Friday, March 30, 2012 1:25 AM > > To: 'Janardhanan Pathangi Narasimhan'; Mingui Zhang > > Cc: rbridge@postel.org > > Subject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > > > > > > > Jana is absolutely correct on the observation below. > > > > > > > > One more point to add, as have indicated earlier > > > > > > > > 1. Not all customer will run multi-topology > > > > 2. You cannot force customers to run multi-topology when they > need > > active-active forwarding > > > > 3. What is your solution for customers who *do NOT* want to > run > > multi-topology ? > > > > > > > > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] > On > > Behalf Of Janardhanan Pathangi Narasimhan > > Sent: Friday, March 30, 2012 12:30 AM > > To: Mingui Zhang > > Cc: rbridge@postel.org > > Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > > > > > > > Hi Mingui > > > > > > > > When you realize active-active, you are asking for the active-active to > be > > setup in a new topology and not the base topology. So these nodes > which > > need to talk to the other nodes which are behind non-MT RBridges > cannot do > > so any more. > > > > > > > > Specifically for MT to be backward compatible, you need all nodes > which > > want to talk to each other part of the base topology. If you do that you > cannot > > realize active-active. If you put the active-active in a new topology, than > they > > can no longer talk to nodes on the base topology of non-MT RBridges. > > > > > > > > So yes, MT-TRILL is backward compatible for base topology, but the > realization > > of active-active with MT – TRILL is not backward compatible. That was > the > > point I was bringing up. > > > > > > > > Thanks > > > > Jana > > > > > > > > > > > > From: Mingui Zhang [mailto:zhangmingui@huawei.com] > > Sent: Friday, March 30, 2012 12:15 PM > > To: Janardhanan Pathangi Narasimhan > > Cc: rbridge@postel.org > > Subject: 答复: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > > > > > > > Hi Jana, > > > > > > > > All RBridges in the campus are in the base topology. MT RBridges can well > > communicate with non-MT RBridges using the base topology. > > > > > > > > I feel that you are arguing that MT-TRILL is not backward compatible. > That is a > > incorrect judgement. > > > > > > > > Thanks, > > > > Mingui > > > > ________________________________ > > > > 发件人: Janardhanan Pathangi Narasimhan > [jana@force10networks.com] > > 发送时间: 2012年3月30日 13:29 > > 到: Mingui Zhang > > Cc: rbridge@postel.org > > 主题: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > > > Hi Mingui, > > > > > > > > With MT approach, when two RBridges which had stations talking to > each > > other and one of them is converted to MT, then the communication is > broken. > > So it does not have backward computability. > > > > > > > > Thanks > > > > Jana > > > > > > > > > > > > From: Mingui Zhang [mailto:zhangmingui@huawei.com] > > Sent: Friday, March 30, 2012 12:27 AM > > To: Janardhanan Pathangi Narasimhan > > Cc: rbridge@postel.org > > Subject: 答复: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > > > > > > > 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 > > > > --===============1648739160== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge --===============1648739160==-- From rbridge-bounces@postel.org Sun Apr 8 21:05:31 2012 Return-Path: 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 96EFD21F8622 for ; Sun, 8 Apr 2012 21:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 IeEqha8c+OoD for ; Sun, 8 Apr 2012 21:05:30 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id DE3C421F8620 for ; Sun, 8 Apr 2012 21:05:30 -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 q39437vg022328; Sun, 8 Apr 2012 21:03:08 -0700 (PDT) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q3942jMG022239 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 8 Apr 2012 21:02:55 -0700 (PDT) Received: by lbom4 with SMTP id m4so2526947lbo.39 for ; Sun, 08 Apr 2012 21:02:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BoW6GZU4bYYUlEf/EqclpXc89tX8hnDOh2pmyxb2RtM=; b=BxvLgPaJZ+Ha/ETiVp7dTykXhGtCTrSi+YxiK1oCKK+0q6qJgkwmOve58Pg6ZUglfX /mo3IO6wJQ1Dr8ABYEbS+CPx+Nxdxi5lm+Pu7chqX89PlY47Nv8HJwgGUQCSbwgFWNWD +umYCZGKV06W6zezXK9/Bj5nH7fLQtejygcqSSN7k16fq7ehCSMujhFxKPI/WTha3euL bfRK/V3IPvc9UzjrVN+tOmWs5/IH5SBPvZd/LGZKjhu4tvCQ8mfyKpiSexs5ltuG1eG1 DZY9xwslqzBMsRkvRCBv95rYRbbUgBgigBsg4yvmOW2NTggmqz9HSytGXUDvqIe0y1Uw AYxw== MIME-Version: 1.0 Received: by 10.152.133.144 with SMTP id pc16mr9461322lab.0.1333944164787; Sun, 08 Apr 2012 21:02:44 -0700 (PDT) Received: by 10.112.2.10 with HTTP; Sun, 8 Apr 2012 21:02:44 -0700 (PDT) In-Reply-To: <4F481869.1030301@acm.org> References: <4F481869.1030301@acm.org> Date: Sun, 8 Apr 2012 21:02:44 -0700 Message-ID: From: Jon Hudson To: Erik Nordmark X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: jon.hudson@gmail.com Cc: "rbridge@postel.org" Subject: Re: [rbridge] WG last call on TRILL: Clarifications, Corrections, and Updates X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0648849007==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org --===============0648849007== Content-Type: multipart/alternative; boundary=f46d042dfea917a45c04bd3714d8 --f46d042dfea917a45c04bd3714d8 Content-Type: text/plain; charset=ISO-8859-1 While very late in responding. I have read and support this draft. Jon On Fri, Feb 24, 2012 at 3:08 PM, Erik Nordmark wrote: > > This starts a working group last call on > draft-ietf-trill-clear-correct-00.txt. > > Please send any comments to the rbridge mailing list, including comments > that you read it and think it is fine. > > The WG last call will end on Monday March 12th. > > The document contains rather independent clarifications, corrections, > and updates, thus if you have comments it would be good to try to > clearly identify the sections in the document. > > Erik > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > -- "Do not lie. And do not do what you hate." --f46d042dfea917a45c04bd3714d8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

While very late in responding. I have read and support = this draft.=A0

Jon


On Fri, Feb 24, 2012 at 3:08 PM, Erik Nordmark &= lt;nordmark@acm.org> wrot= e:

This starts a working group last call on
draft-ietf-trill-clear-correct-00.txt.

Please send any comments to the rbridge mailing list, including comments that you read it and think it is fine.

The WG last call will end on Monday March 12th.

The document contains rather independent clarifications, corrections,
and updates, thus if you have comments it would be good to try to
clearly identify the sections in the document.

=A0 =A0Erik
_______________________________________________
rbridge mailing list
rbridge@postel.org
http://mailman.postel.org/mailman/listinfo/rbridge



--
"Do not= lie. And do not do what you hate."

--f46d042dfea917a45c04bd3714d8-- --===============0648849007== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge --===============0648849007==-- From rbridge-bounces@postel.org Mon Apr 9 16:31:04 2012 Return-Path: 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 D261821F879B for ; Mon, 9 Apr 2012 16:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.581 X-Spam-Level: X-Spam-Status: No, score=-104.581 tagged_above=-999 required=5 tests=[AWL=2.018, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 OQJqPfChdGhI for ; Mon, 9 Apr 2012 16:31:03 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 0499721F8782 for ; Mon, 9 Apr 2012 16:31:02 -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 q39NHJbB023586; Mon, 9 Apr 2012 16:17:20 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [12.22.58.30]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q39NGYAK023511 for ; Mon, 9 Apr 2012 16:16:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FDCE21F84C2 for ; Mon, 9 Apr 2012 16:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 F0Aq3rTo9Qnk; Mon, 9 Apr 2012 16:16:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 095D621F848B; Mon, 9 Apr 2012 16:16:34 -0700 (PDT) MIME-Version: 1.0 From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120409231634.15406.20236.idtracker@ietfa.amsl.com> Date: Mon, 09 Apr 2012 16:16:34 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: internet-drafts@ietf.org X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id q39NGYAK023511 Cc: rbridge@postel.org Subject: [rbridge] I-D Action: draft-ietf-trill-rbridge-bfd-04.txt X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transparent Interconnection of Lots of Links Working Group of the IETF. Title : TRILL: Bidirectional Forwarding Detection (BFD) Support Author(s) : Vishwas Manral Donald Eastlake Dave Ward Ayan Banerjee Filename : draft-ietf-trill-rbridge-bfd-04.txt Pages : 11 Date : 2012-04-09 This document specifies use of the BFD (Bidirectional Forwarding Detection) protocol in RBridge campuses based on the Rbridge Channel extension to the the TRILL (TRansparent Interconnection of Lots of Links) protocol. BFD is a widely deployed OAM (Operations, Administration, and Maintenance) mechanism in IP and MPLS networks, using UDP and ACH encapsulation respectively. This document specifies the BFD encapsulation over TRILL. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-bfd-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-trill-rbridge-bfd-04.txt _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge From rbridge-bounces@postel.org Tue Apr 10 08:35:16 2012 Return-Path: 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 20E8A11E80FF for ; Tue, 10 Apr 2012 08:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.676 X-Spam-Level: X-Spam-Status: No, score=-5.676 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 vyWhi7TfI0Gv for ; Tue, 10 Apr 2012 08:35:13 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id A443B11E80F6 for ; Tue, 10 Apr 2012 08:35:13 -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 q3AFBL8a013892; Tue, 10 Apr 2012 08:11:22 -0700 (PDT) Received: from mail-iy0-f180.google.com (mail-iy0-f180.google.com [209.85.210.180]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q3AFAhKQ013753 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 10 Apr 2012 08:10:52 -0700 (PDT) Received: by iage36 with SMTP id e36so12088317iag.39 for ; Tue, 10 Apr 2012 08:10:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-gm-message-state; bh=DD90n+Zp4dJigE7O1N8ad2U+9KXvrMwD6G4GNRHmkHg=; b=boXrY++9DrW2IqwomUP9FUktwmkwZM/cM3o8TLaWDda4Q4TPw/w9ZCtIpLbkT7gxst 7vBEWBgF1u3tXtymkh4xOOB1rbfGKTcTuwNpW1aAI0pkHaP+nQImTTYc+mrDd1dQ/oAj HlCoNRvbxJaQff5o4CBIFXRbQx156aSoI1BYtGCNlYIvNOFN0LE/IG8Cppaxfqvv4RQJ hKDiRxwKQP2dFzUz4Wd2/vElwsdgJX/UzvyR8JAQGu3ft8eUEERNGblMTGmfkMYxx9Nb UBqyY0sOxSx2IgBr630PHw3LXwlF76HjmDbQcMKqNChwyniRxcHYNAdbwiIb9jWf83qT ieHg== Received: by 10.42.144.201 with SMTP id c9mr8089013icv.29.1334070642933; Tue, 10 Apr 2012 08:10:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.30.195 with HTTP; Tue, 10 Apr 2012 08:10:22 -0700 (PDT) From: Muhammad Mohsin Sardar Date: Tue, 10 Apr 2012 20:10:22 +0500 Message-ID: To: rbridge@postel.org X-Gm-Message-State: ALoCoQk0rFOwkCyqJa9t+BC2ImfpAGSzfoSOUd4ZsKgQCx7/S5ie1AtVfJC/NGP4IC4ZSxmNjM13 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: mohsin.sardar@seecs.edu.pk Subject: [rbridge] Clarification regarding TRILL LSP and Hello X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2060320263==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org --===============2060320263== Content-Type: multipart/alternative; boundary=90e6ba6e8a18c6ff1404bd5486d5 --90e6ba6e8a18c6ff1404bd5486d5 Content-Type: text/plain; charset=ISO-8859-1 Hi, Is Level 1 link state PDU described in section 9.8 of ISO/IEC 10598-2002 and Level 1 LAN IS to IS hello PDU in section 9.5 applicable for TRILL? Or information given in section 4.2.4.4 (TRILL LSP) and section 4.4.2 (TRILL Hello contents) of RFC6325 is sufficient? (I know the TLVs mentioned in RFC 6326 regarding these sections) If description of Level 1 link state PDU and Level 1 LAN IS to IS hello of ISO/IEC 10598-2002 is partially applicable, please clarify? Thank you! -- Best Regards, Muhammad Mohsin Sardar --90e6ba6e8a18c6ff1404bd5486d5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,
Is Level 1 link state PDU described in section 9.8 of ISO/IEC 10598= -2002 and Level 1 LAN IS to IS hello PDU in section 9.5 applicable for TRIL= L?
Or information given in section 4.2.4.4 (TRILL LSP) and section 4.4.2= (TRILL Hello contents) of RFC6325=A0 is sufficient? (I know the TLVs menti= oned in RFC 6326 regarding these sections)

If description of Level 1 link state PDU and Level 1 LAN IS to IS hello= of ISO/IEC 10598-2002 is partially applicable, please clarify?

Than= k you!

--
Best Regards,
Muhammad Mohsin Sardar<= br> --90e6ba6e8a18c6ff1404bd5486d5-- --===============2060320263== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge --===============2060320263==-- From rbridge-bounces@postel.org Tue Apr 10 09:13:23 2012 Return-Path: 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 3C17711E80CB for ; Tue, 10 Apr 2012 09:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.669 X-Spam-Level: X-Spam-Status: No, score=-105.669 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 cJuUQxxoFqED for ; Tue, 10 Apr 2012 09:13:22 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 80A4F11E80BE for ; Tue, 10 Apr 2012 09:13:22 -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 q3AFluwf020059; Tue, 10 Apr 2012 08:47:57 -0700 (PDT) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q3AFlY3j019993 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 10 Apr 2012 08:47:44 -0700 (PDT) Received: by lbom4 with SMTP id m4so4328770lbo.39 for ; Tue, 10 Apr 2012 08:47:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=o79jv74qilSVxmT0D8xgRwti6GUzA1JRrkZDC5F6KGg=; b=p3rTukxvcGnPYPDCXu+OamsOSWDE3j+d5jGle/v8Ngz0SXX6JbkK7fIsm4LTn5zBxz PyjJzPQO3pQRGR7ivGfqoed+bXl0TZjT+DaSAPgfSz/zpT4OVuSQPNYPj2TuEyLWsxMT Javuw/F2M3VFsU5Mc1ZbxZCWsr8/aCPG/uHcDEoH8P2gnuhgpWKLum2grGtbqNcjWkjk ROjMsunpZQH7PYiOJlDh+Ya6syceuWsLQcrj6FlWXGQnRsULImXTNGlKig5Pop8hJJ/n /8gdEPlYhLrHkHfdcDRDQWt8NTltWnTxH7FCGe2KLmI6uQkwz1OQXYbTskgJZDsUdZ94 SEgg== Received: by 10.112.10.41 with SMTP id f9mr1462755lbb.46.1334072853038; Tue, 10 Apr 2012 08:47:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.162 with HTTP; Tue, 10 Apr 2012 08:47:12 -0700 (PDT) In-Reply-To: References: From: Donald Eastlake Date: Tue, 10 Apr 2012 11:47:12 -0400 Message-ID: To: Muhammad Mohsin Sardar X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: d3e3e3@gmail.com X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id q3AFlY3j019993 Cc: rbridge@postel.org Subject: Re: [rbridge] Clarification regarding TRILL LSP and Hello X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org Hi, On Tue, Apr 10, 2012 at 11:10 AM, Muhammad Mohsin Sardar wrote: > Hi, > Is Level 1 link state PDU described in section 9.8 of ISO/IEC 10598-2002 = and > Level 1 LAN IS to IS hello PDU in section 9.5 applicable for TRILL? TRILL is based on IS-IS so, unless the TRILL documents say that something should be different, the TRILL IS-IS PDUs follow the ISO standard. > Or information given in section 4.2.4.4 (TRILL LSP) and section 4.4.2 (TR= ILL > Hello contents) of RFC6325=A0 is sufficient? (I know the TLVs mentioned i= n RFC > 6326 regarding these sections) I doubt that the information in those sections of RFC 6325 are sufficient. Note that RFC 6325 is updated by RFC 6327 and 6439. Note particularly Section 7 of RFC 6327. > If description of Level 1 link state PDU and Level 1 LAN IS to IS hello of > ISO/IEC 10598-2002 is partially applicable, please clarify? The TRILL documents specify how the TRILL LSPs and Hellos differ from the ISO standard (and from RFC 1195). Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com > Thank you! > > -- > Best Regards, > Muhammad Mohsin Sardar _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge From rbridge-bounces@postel.org Tue Apr 10 15:30:08 2012 Return-Path: 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 C702911E8148 for ; Tue, 10 Apr 2012 15:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.626 X-Spam-Level: X-Spam-Status: No, score=-104.626 tagged_above=-999 required=5 tests=[AWL=1.973, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 2uwtolR70mbd for ; Tue, 10 Apr 2012 15:30:07 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id DD8B611E812C for ; Tue, 10 Apr 2012 15:30:07 -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 q3AMD0uW020047; Tue, 10 Apr 2012 15:13:02 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [12.22.58.30]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q3AMCbHP020018 for ; Tue, 10 Apr 2012 15:12:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A445A11E8119 for ; Tue, 10 Apr 2012 15:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 M1krsW9Dzzgr; Tue, 10 Apr 2012 15:12:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB4F11E80D2; Tue, 10 Apr 2012 15:12:35 -0700 (PDT) MIME-Version: 1.0 From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120410221235.18766.8366.idtracker@ietfa.amsl.com> Date: Tue, 10 Apr 2012 15:12:35 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: internet-drafts@ietf.org X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id q3AMCbHP020018 Cc: rbridge@postel.org Subject: [rbridge] I-D Action: draft-ietf-trill-rbridge-bfd-05.txt X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transparent Interconnection of Lots of Links Working Group of the IETF. Title : TRILL: Bidirectional Forwarding Detection (BFD) Support Author(s) : Vishwas Manral Donald Eastlake Dave Ward Ayan Banerjee Filename : draft-ietf-trill-rbridge-bfd-05.txt Pages : 16 Date : 2012-04-10 This document specifies use of the BFD (Bidirectional Forwarding Detection) protocol in RBridge campuses based on the Rbridge Channel extension to the the TRILL (TRansparent Interconnection of Lots of Links) protocol. BFD is a widely deployed OAM (Operations, Administration, and Maintenance) mechanism in IP and MPLS networks, using UDP and ACH encapsulation respectively. This document specifies the BFD encapsulation over TRILL. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-bfd-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-trill-rbridge-bfd-05.txt _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge From rbridge-bounces@postel.org Tue Apr 10 18:42:03 2012 Return-Path: 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 6F31321F8504 for ; Tue, 10 Apr 2012 18:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4] 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 ZsidU9w5cJJQ for ; Tue, 10 Apr 2012 18:42:01 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 84E4421F8503 for ; Tue, 10 Apr 2012 18:42:01 -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 q3B1W7kv021480; Tue, 10 Apr 2012 18:32:09 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q3B1VhY1021444 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 10 Apr 2012 18:31:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rwatve@cisco.com; l=27574; q=dns/txt; s=iport; t=1334107912; x=1335317512; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=5joaKoS3Mo8kb+WlX6PY2qmbCMPcqs+q+7Z7L22GU8A=; b=mIs2UHGfm6ouj3V1fO30ZNlnRnzM5lkEXMA5mkoJRWgtqUcwuZpaYJwp nO8Ba/GKZ8razcQlo5IsD4xMas00FHmwaEQH6nJ4wd2i2f1oJD4AbUkGY QfeEC1gyl3+/g/ofAa9yBNUOHDm0G96ExZDwU131bVr8eqfB07iBre0ZU s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAJHehE+rRDoJ/2dsb2JhbABEuT2BB4IJAQEBAwEBAQEPAQcDEwoUFwgBEAcEAgEIEQMBAQELAgQXAQYBIAYKFQkIAQEEARIIEwIEAYdeAwYEAQuaMpZCDYlTiiSGN2MEiFqOI4oogxSBaYMHgTw X-IronPort-AV: E=Sophos;i="4.75,402,1330905600"; d="scan'208";a="39953972" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 11 Apr 2012 01:31:42 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3B1VfZS002880 for ; Wed, 11 Apr 2012 01:31:42 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Apr 2012 18:31:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 10 Apr 2012 18:31:39 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] rbridge Digest, Vol 95, Issue 11 Thread-Index: Ac0T6034SFljDH1qDkeyJEPPTEibdwDl34CQ References: From: "Rohit Watve (rwatve)" To: "Varun Shah (varshah)" , X-OriginalArrivalTime: 11 Apr 2012 01:31:41.0853 (UTC) FILETIME=[D91064D0:01CD1782] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rwatve@cisco.com X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id q3B1VhY1021444 Subject: Re: [rbridge] rbridge Digest, Vol 95, Issue 11 X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org +1 for making draft-tissa-trill-cmt-00 a WG draft. Thanks Rohit -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Varun Shah (varshah) Sent: Friday, April 06, 2012 4:49 AM To: rbridge@postel.org Subject: Re: [rbridge] rbridge Digest, Vol 95, Issue 11 +1 for making draft-tissa-trill-cmt-00 a WG draft. Thanks, -Varun On 4/5/12 7:37 AM, "rbridge-request@postel.org" wrote: > Send rbridge mailing list submissions to > rbridge@postel.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mailman.postel.org/mailman/listinfo/rbridge > or, via email, send a message with subject or body 'help' to > rbridge-request@postel.org > > You can reach the person managing the list at > rbridge-owner@postel.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of rbridge digest..." > > > Today's Topics: > > 1. Re: Call for draft-tissa-trill-cmt-00 to WG draft > (Tissa Senevirathne (tsenevir)) > 2. Re: Call for draft-tissa-trill-cmt-00 to WG draft > (Tissa Senevirathne (tsenevir)) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 5 Apr 2012 07:28:38 -0700 > From: "Tissa Senevirathne (tsenevir)" > Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > To: "Ayan Banerjee (ayabaner)" , > > Message-ID: > <344037D7CFEFE84E97E9CC1F56C5F4A5E3B778@xmb-sjc-214.amer.cisco.com> > Content-Type: text/plain; charset="us-ascii" > > +1 vote in support. > > > > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Ayan Banerjee (ayabaner) > Sent: Wednesday, April 04, 2012 11:03 PM > To: rbridge@postel.org > Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > > > Yes, I believe that this is an important piece of the puzzle and should > be made a WG document. > > Thanks, > Ayan > ==== > > > > During the TRILL session today, there was a consensus of those in the > room to make draft-tissa-trill-cmt-00.txt a TRILL WG draft. This is a > call on the WG mailing list to confirm that consensus. If you wish to > respond, please do so by April 10th. > > Thanks, > Donald > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://mailman.postel.org/pipermail/rbridge/attachments/20120405/f43f46e 0/atta > chment-0001.html > > ------------------------------ > > Message: 2 > Date: Thu, 5 Apr 2012 07:36:47 -0700 > From: "Tissa Senevirathne (tsenevir)" > Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > To: "Mingui Zhang" , "Janardhanan Pathangi > Narasimhan" > Cc: rbridge@postel.org > Message-ID: > <344037D7CFEFE84E97E9CC1F56C5F4A5E3B780@xmb-sjc-214.amer.cisco.com> > Content-Type: text/plain; charset="gb2312" > > Mingui > > I choose only to answer your last question on "MT is already supported in > TRILL". Why are you saying that ? I do not see any RFC or WG document ? > > -----Original Message----- > From: Mingui Zhang [mailto:zhangmingui@huawei.com] > Sent: Thursday, April 05, 2012 1:53 AM > To: Tissa Senevirathne (tsenevir); Janardhanan Pathangi Narasimhan > Cc: rbridge@postel.org > Subject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft > > Hi Tissa, > > If one tries hard to search, then he will find each solution has its > drawbacks. The reluctance to deploy MT maybe a problem to MTRA, I agree with > you. But, as I had pointed out in my draft, MTRA is capable to be run in the > same campus and uses other solutions in the base topology. However, I need to > pointed out that the reason why there are not many L3 MT is a historical one. > For switches/bridges, especially when they are used in data center networks, > ECMP and multi-path features are highly desired. For the benefit of the WG, I > don't want to mention the names of TRILL pre-standard implementations and > devices that work like TRILL from other SDOs. I think you can find examples > that support MT. We can talk about this problem offline. > > Personally, the WG voting should not be used as a tool to endorse a solution > before WG members are clear that it is workable and there are other competing > solutions working for an overlapping problem space. IMHO, competing solutions > should be merged or adopted as alternatives. Just as that we allow cheap > local-brand cars to run on same roads along with BMWs. Let customers make > choices themselves. > > Before the final WG decision is made, let me outline the winning advantages of > MTRA for the WG members to consider. > 1. MTRA is incremental deploy-able. It allows other non-MTRA RBridges exist in > the same campus as transit or edge nodes. The solutions to communicate with > non-MTRA are depicted in the email to Jon, you can find it. > 2. MTRA realizes traffic segregation which guarantees that a LAG link failure > is isolated in a specific topology. > 3. MTRA is able to converge fast when there is a node/link failure of the > aggregation. > 4. If MT is already supported by TRILL, no extra TLVs are needed. > > Thanks, > Mingui > > >> -----Original Message----- >> From: Tissa Senevirathne (tsenevir) [mailto:tsenevir@cisco.com] >> Sent: Monday, April 02, 2012 11:14 PM >> To: Mingui Zhang; Janardhanan Pathangi Narasimhan >> Cc: rbridge@postel.org >> Subject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft >> >> Hi Mingui >> >> >> >> You are assuming a lot. >> >> That is: >> >> 1. People will deploy Multi-topology when they need active-active >> forwarding. >> >> 2. It is easy to deploy and people will like it >> >> 3. It is already out there >> >> >> >> #2 you can check % vise how many MT installations there in L3 world. >> >> >> >> Again I would summarize CMT need only one TLV, MT require lot more TLV >> and require major changes to RFC6326 control plane. >> >> >> >> Backward compatibility of control plane in my world is not an issue as we are >> exchanging more emails than really trying to deploy RBridges and there are no >> RBridges there forwarding packets in real networks. >> >> >> >> However, your claim that MT is backward compatible without any tweaks is >> false (Jana has pointed out several times). >> >> >> >> Like I have said, many times before, MT approach you have may be utilized >> for active-active forwarding in MT installations. I will support that >> solution as >> an optimization for MT, certainly I **do not** support it as the only >> solution >> for all active-active deployments. If we agree on that then we have consensus >> and both work can move forward (we need to make progress). If not then we >> can continue to disagree and I request WG chairs to decide via a vote on >> making CMT a WG document. >> >> >> >> >> >> Thanks >> >> Tissa >> >> From: Mingui Zhang [mailto:zhangmingui@huawei.com] >> Sent: Monday, April 02, 2012 7:54 AM >> To: Tissa Senevirathne (tsenevir); Janardhanan Pathangi Narasimhan >> Cc: rbridge@postel.org >> Subject: ????: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft >> >> >> >> Hi Tissa, >> >> >> >> We know that RBridge Aggregation is used to increase the access capacity >> without upgrade of the RBridges. The motivation is the same as the >> traditional >> LAG: it will help customers to reduce their investment. If active-active >> multi-homing can work well, customers will eager to purchase MT feature. It >> may even act as a factor that promotes MT-TRILL, who knows. >> >> >> >> On the other hand, since MTRA is backward compatible, it allows other >> non-MTRA solutions co-exist in the campus. These solutions work in the base >> topology. These solutions may include tunneling approach. As we know, >> tunneling had been widely used on traditional switches. If there are >> customers who really do not like MT, just use tunneling approach or others. >> >> >> >> However, I don't think that multi-topology is that expensive. I believe you >> have heard of silicons or implementations already support multi-topology >> feature before 2010 when RFC 6325 was published. >> >> >> >> Thanks, >> >> Mingui >> >> >> >> ________________________________ >> >> ??????: Tissa Senevirathne (tsenevir) [tsenevir@cisco.com] >> ????????: 2012??4??2?? 0:27 >> ??: Janardhanan Pathangi Narasimhan; Mingui Zhang >> Cc: rbridge@postel.org >> ????: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft >> >> Hi Mingui >> >> >> >> I have not seen an answer for the questions below could you please answer >> simple question: >> >> >> >> What is your proposal for active-active for people who do not want to run >> multi-topology ? >> >> >> >> From: Tissa Senevirathne (tsenevir) >> Sent: Friday, March 30, 2012 1:37 AM >> To: Tissa Senevirathne (tsenevir); 'Janardhanan Pathangi Narasimhan'; 'Mingui >> Zhang' >> Cc: 'rbridge@postel.org' >> Subject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft >> >> >> >> Small typo correction >> >> >> >> From: Tissa Senevirathne (tsenevir) >> Sent: Friday, March 30, 2012 1:25 AM >> To: 'Janardhanan Pathangi Narasimhan'; Mingui Zhang >> Cc: rbridge@postel.org >> Subject: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft >> >> >> >> Jana is absolutely correct on the observation below. >> >> >> >> One more point to add, as have indicated earlier >> >> >> >> 1. Not all customer will run multi-topology >> >> 2. You cannot force customers to run multi-topology when they need >> active-active forwarding >> >> 3. What is your solution for customers who *do NOT* want to run >> multi-topology ? >> >> >> >> From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On >> Behalf Of Janardhanan Pathangi Narasimhan >> Sent: Friday, March 30, 2012 12:30 AM >> To: Mingui Zhang >> Cc: rbridge@postel.org >> Subject: Re: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft >> >> >> >> Hi Mingui >> >> >> >> When you realize active-active, you are asking for the active-active to be >> setup in a new topology and not the base topology. So these nodes which >> need to talk to the other nodes which are behind non-MT RBridges cannot do >> so any more. >> >> >> >> Specifically for MT to be backward compatible, you need all nodes which >> want to talk to each other part of the base topology. If you do that you >> cannot >> realize active-active. If you put the active-active in a new topology, than >> they >> can no longer talk to nodes on the base topology of non-MT RBridges. >> >> >> >> So yes, MT-TRILL is backward compatible for base topology, but the >> realization >> of active-active with MT ?C TRILL is not backward compatible. That was the >> point I was bringing up. >> >> >> >> Thanks >> >> Jana >> >> >> >> >> >> From: Mingui Zhang [mailto:zhangmingui@huawei.com] >> Sent: Friday, March 30, 2012 12:15 PM >> To: Janardhanan Pathangi Narasimhan >> Cc: rbridge@postel.org >> Subject: ????: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft >> >> >> >> Hi Jana, >> >> >> >> All RBridges in the campus are in the base topology. MT RBridges can well >> communicate with non-MT RBridges using the base topology. >> >> >> >> I feel that you are arguing that MT-TRILL is not backward compatible. That is >> a >> incorrect judgement. >> >> >> >> Thanks, >> >> Mingui >> >> ________________________________ >> >> ??????: Janardhanan Pathangi Narasimhan [jana@force10networks.com] >> ????????: 2012??3??30?? 13:29 >> ??: Mingui Zhang >> Cc: rbridge@postel.org >> ????: RE: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft >> >> Hi Mingui, >> >> >> >> With MT approach, when two RBridges which had stations talking to each >> other and one of them is converted to MT, then the communication is broken. >> So it does not have backward computability. >> >> >> >> Thanks >> >> Jana >> >> >> >> >> >> From: Mingui Zhang [mailto:zhangmingui@huawei.com] >> Sent: Friday, March 30, 2012 12:27 AM >> To: Janardhanan Pathangi Narasimhan >> Cc: rbridge@postel.org >> Subject: ????: [rbridge] Call for draft-tissa-trill-cmt-00 to WG draft >> >> >> >> 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 > > > End of rbridge Digest, Vol 95, Issue 11 > *************************************** _______________________________________________ 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 From rbridge-bounces@postel.org Wed Apr 11 08:10:23 2012 Return-Path: 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 615C911E816F for ; Wed, 11 Apr 2012 08:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.653 X-Spam-Level: X-Spam-Status: No, score=-105.653 tagged_above=-999 required=5 tests=[AWL=0.946, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 zhPl3ztgxaPy for ; Wed, 11 Apr 2012 08:10:22 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id BABD211E815C for ; Wed, 11 Apr 2012 08:10:22 -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 q3BElFpE013133; Wed, 11 Apr 2012 07:47:17 -0700 (PDT) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q3BEkZfw013056 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 11 Apr 2012 07:46:45 -0700 (PDT) Received: by lbom4 with SMTP id m4so1190862lbo.39 for ; Wed, 11 Apr 2012 07:46:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=2YuoAdSje7eTTA9CdvVfr+IgpjgfcemW3mSkS7p7o1I=; b=lXQ8yFn1O6akIwdX1eOXYmHT9wEIyegW6egU4/jDB5audarEcaQcrICXKM1OWj9Gso xsBeKV6tVLCuzRpN0PHE4hqTMsnXpav2GDa3IBbZotUyPDWydQWJSiHwEQr7Vt0yFklc mfjsdpwC0sWQ49GHfjExA5BLPrcY/klldGbA6VeyHmqArih2xNDDFnga0ih1OXG7JqlD B4XnWtgkrDJfRfcNf86ey4Lz+fL26xq6dQ3MOGsAbJQMh8eoqL76vm0MgHlOxTrhcfoX cXBXJMYjve6qG+i7MVtExT3eTMs2TkNggrcMHlDBnRkcsYGp4tE2aXPRSyPl6rM7Z9ok sUNg== Received: by 10.152.113.229 with SMTP id jb5mr18318084lab.45.1334155594487; Wed, 11 Apr 2012 07:46:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.162 with HTTP; Wed, 11 Apr 2012 07:46:14 -0700 (PDT) In-Reply-To: <20120410221235.18766.8366.idtracker@ietfa.amsl.com> References: <20120410221235.18766.8366.idtracker@ietfa.amsl.com> From: Donald Eastlake Date: Wed, 11 Apr 2012 10:46:14 -0400 Message-ID: To: rbridge@postel.org X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: d3e3e3@gmail.com X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id q3BEkZfw013056 Subject: Re: [rbridge] I-D Action: draft-ietf-trill-rbridge-bfd-05.txt X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org Hi, draft-ietf-trill-rbridge-bfd-05.txt and draft-ietf-trill-rbridge-bfd-04.txt have only editorial changes and fixes to nits. There are no technical changes from draft-ietf-trill-rbridge-bfd-03.txt for which it was determined that there was WG consensus to request RFC publication. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com On Tue, Apr 10, 2012 at 6:12 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. This draft is a work item of the Transparent Interconnection of Lots= of Links Working Group of the IETF. > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : TRILL: Bidirectional Forwardin= g Detection (BFD) Support > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Vishwas Manral > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Donald Eastlake > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Dave Ward > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Ayan Banerjee > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-trill-rbridge-bfd-05.= txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 16 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-04-10 > > =A0 This document specifies use of the BFD (Bidirectional Forwarding > =A0 Detection) protocol in RBridge campuses based on the Rbridge Channel > =A0 extension to the the TRILL (TRansparent Interconnection of Lots of > =A0 Links) protocol. > > =A0 BFD is a widely deployed OAM (Operations, Administration, and > =A0 Maintenance) mechanism in IP and MPLS networks, using UDP and ACH > =A0 encapsulation respectively. =A0This document specifies the BFD > =A0 encapsulation over TRILL. > > > > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-bfd-05.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-trill-rbridge-bfd-05.txt > > > _______________________________________________ > 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 From rbridge-bounces@postel.org Wed Apr 11 09:44:09 2012 Return-Path: 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 473D011E80A3 for ; Wed, 11 Apr 2012 09:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.72 X-Spam-Level: X-Spam-Status: No, score=-105.72 tagged_above=-999 required=5 tests=[AWL=0.879, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 nTkXrwG6KNrT for ; Wed, 11 Apr 2012 09:44:07 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id B6F4211E8089 for ; Wed, 11 Apr 2012 09:44:06 -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 q3BGa9AC000816; Wed, 11 Apr 2012 09:36:10 -0700 (PDT) Received: from mail-lpp01m010-f52.google.com (mail-lpp01m010-f52.google.com [209.85.215.52]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q3BGZe1X000748 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 11 Apr 2012 09:35:50 -0700 (PDT) Received: by lahi5 with SMTP id i5so1359688lah.39 for ; Wed, 11 Apr 2012 09:35:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=EC9WqkrdbaHWUPCYbtmCPJBKSQwp6hXIX5ftpcPqLvk=; b=cd+lisV4v4NhXmis0o0aJlsUGThcefmcXHRzyAmUhBunML1HunlVr2Cd11EVMb78Iw LJ2dE3IRlNHGkDtDY3/BpPh0rqnRlKO/WQZbDKVy1WJ5e9g5dDnVdRfgsm6D3JhjQTRc 6Fh0idER+DpEAvWlWUnqd9l4va9cj90Mi/BETRc7fe2sPyFqwczaxc+UdfytTlHtplJG 9u4zj6V0h7SZogfVQAT6k1DzXuvLx9Idt9nnql32QcqnhHJeYc1z3sPSGDy2vRBrRwkx qU8Cgbjz5/hGFlxf+UMPc4lM+NmZ88/YHFuVw9GtnnzaAqmlbAtaIisC0L09NMNSmlho oOvg== Received: by 10.112.10.41 with SMTP id f9mr3236198lbb.46.1334162139125; Wed, 11 Apr 2012 09:35:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.162 with HTTP; Wed, 11 Apr 2012 09:35:18 -0700 (PDT) In-Reply-To: References: <20120410221235.18766.8366.idtracker@ietfa.amsl.com> From: Donald Eastlake Date: Wed, 11 Apr 2012 12:35:18 -0400 Message-ID: To: rbridge@postel.org X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: d3e3e3@gmail.com X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id q3BGZe1X000748 Subject: Re: [rbridge] I-D Action: draft-ietf-trill-rbridge-bfd-05.txt X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org Correction: All of the -03, -04, and -05 drafts were to fix editorial problems and nits. There have been no technical changes since -02 for which consensus was determined here: http://www.postel.org/pipermail/rbridge/2012-February/004804.html Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com On Wed, Apr 11, 2012 at 10:46 AM, Donald Eastlake wrote: > Hi, > > draft-ietf-trill-rbridge-bfd-05.txt and > draft-ietf-trill-rbridge-bfd-04.txt have only editorial changes and > fixes to nits. There are no technical changes from > draft-ietf-trill-rbridge-bfd-03.txt for which it was determined that > there was WG consensus to request RFC publication. > > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) > =A0155 Beaver Street,=A0Milford, MA 01757 USA > =A0d3e3e3@gmail.com > > > On Tue, Apr 10, 2012 at 6:12 PM, =A0 wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. This draft is a work item of the Transparent Interconnection of Lot= s of Links Working Group of the IETF. >> >> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : TRILL: Bidirectional Forwardi= ng Detection (BFD) Support >> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Vishwas Manral >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Donald Eastlake >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Dave Ward >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Ayan Banerjee >> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-trill-rbridge-bfd-05= .txt >> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 16 >> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-04-10 >> >> =A0 This document specifies use of the BFD (Bidirectional Forwarding >> =A0 Detection) protocol in RBridge campuses based on the Rbridge Channel >> =A0 extension to the the TRILL (TRansparent Interconnection of Lots of >> =A0 Links) protocol. >> >> =A0 BFD is a widely deployed OAM (Operations, Administration, and >> =A0 Maintenance) mechanism in IP and MPLS networks, using UDP and ACH >> =A0 encapsulation respectively. =A0This document specifies the BFD >> =A0 encapsulation over TRILL. >> >> >> >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-bfd-05.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-trill-rbridge-bfd-05.txt >> >> >> _______________________________________________ >> 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 From touch@isi.edu Wed Apr 11 11:20:57 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAE6A11E80C6 for ; Wed, 11 Apr 2012 11:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.53 X-Spam-Level: X-Spam-Status: No, score=-103.53 tagged_above=-999 required=5 tests=[AWL=-0.931, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 OBhf+rthLU6N for ; Wed, 11 Apr 2012 11:20:55 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE0311E80BB for ; Wed, 11 Apr 2012 11:20:53 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q3BIKQti011512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Apr 2012 11:20:27 -0700 (PDT) Message-ID: <4F85CB6A.7010606@isi.edu> Date: Wed, 11 Apr 2012 11:20:26 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: trill@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: [trill] Welcome to the new rbridge/trill email list X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 18:20:57 -0000 Hi, all, If you receive this message, you have been successfully subscribed to the new trill@ietf.org mailing list based on your previous subscription to rbridge@postel.org. You can verify your settings here: https://www.ietf.org/mailman/listinfo/trill Welcome to the new list, and please let me know if you have any concerns or problems. Joe (list admin) From rbridge-bounces@postel.org Wed Apr 11 11:26:33 2012 Return-Path: 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 3A31111E80D0 for ; Wed, 11 Apr 2012 11:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.449 X-Spam-Level: X-Spam-Status: No, score=-105.449 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 0ren6tqwk60j for ; Wed, 11 Apr 2012 11:26:32 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6EAFA11E80CE for ; Wed, 11 Apr 2012 11:26:32 -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 q3BIMWbb019164; Wed, 11 Apr 2012 11:22:33 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q3BIMJ4X019138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 11 Apr 2012 11:22:19 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q3BIL7h3011591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Apr 2012 11:21:07 -0700 (PDT) Message-ID: <4F85CB93.2000102@isi.edu> Date: Wed, 11 Apr 2012 11:21:07 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Developing a hybrid router/bridge." X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Subject: [rbridge] URGENT INFO - rbridge list moving to trill@ietf.org X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org Hi, all, This should be the last post to this list. You should be receiving a welcome message on the trill@ietf.org mailing list now. >>IF YOU RECEIVE THIS MESSAGE AND NOT ONE ADDRESSED TO trill@ietf.org<<< In this case, you need to subscribe to trill@ietf.org to continue to participate in this list. Information on subscribing is here: https://www.ietf.org/mailman/listinfo/trill Joe (rbridge/trill mailing list admin) _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge From rbridge-bounces@postel.org Wed Apr 11 11:47:42 2012 Return-Path: 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 9C57321F84AA for ; Wed, 11 Apr 2012 11:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.461 X-Spam-Level: X-Spam-Status: No, score=-105.461 tagged_above=-999 required=5 tests=[AWL=1.138, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 DOFGehRbeSAp for ; Wed, 11 Apr 2012 11:47:41 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id D610921F84A7 for ; Wed, 11 Apr 2012 11:47:41 -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 q3BIHV6Z018348; Wed, 11 Apr 2012 11:17:32 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q3BIHEVE018322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 11 Apr 2012 11:17:14 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q3BIH0Vu010764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Apr 2012 11:17:00 -0700 (PDT) Message-ID: <4F85CA9C.7090708@isi.edu> Date: Wed, 11 Apr 2012 11:17:00 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Developing a hybrid router/bridge." X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Subject: [rbridge] RBRIDGE LIST HAS MOVED TO TRILL@IETF.ORG X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org Hi, all, The rbridge mailing list HAS NOW MOVED to trill@ietf.org, to be more consistent with other IETF WG mailing lists. This move was done in coordination with the WG chairs. The archives have been moved as well. Info on the new list is here: https://www.ietf.org/mailman/listinfo/trill I have tried to copy user list settings (including "nomail" settings) between these two systems, FWIW. I will continue to administer the new list. This should be one of the last messages you receive on rbridge@postel.org. Joe (rbridge/trill mailing list admin) _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge From touch@isi.edu Wed Apr 11 15:05:40 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C259F21F8478 for ; Wed, 11 Apr 2012 15:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.545 X-Spam-Level: X-Spam-Status: No, score=-105.545 tagged_above=-999 required=5 tests=[AWL=1.054, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 tIm3wls66b9n for ; Wed, 11 Apr 2012 15:05:40 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 4A25A21F8475 for ; Wed, 11 Apr 2012 15:05:40 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q3BM5LgJ023842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 11 Apr 2012 15:05:21 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q3BM55pw019662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Apr 2012 15:05:05 -0700 (PDT) Message-ID: <4F860011.7000007@isi.edu> Date: Wed, 11 Apr 2012 15:05:05 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Developing a hybrid router/bridge." Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Subject: [trill] test - please ignore X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 22:05:40 -0000 Hi, all, This is a test message sent to "rbridge@postel.org". Please ignore. Joe (list admin) From touch@isi.edu Wed Apr 11 15:26:21 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5779311E80D9 for ; Wed, 11 Apr 2012 15:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.583 X-Spam-Level: X-Spam-Status: No, score=-103.583 tagged_above=-999 required=5 tests=[AWL=-0.984, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 HJeqHWmRT47F for ; Wed, 11 Apr 2012 15:26:20 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id DF22E11E8073 for ; Wed, 11 Apr 2012 15:26:20 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q3BMQD4M023422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Apr 2012 15:26:13 -0700 (PDT) Message-ID: <4F860505.6020802@isi.edu> Date: Wed, 11 Apr 2012 15:26:13 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: trill@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: [trill] TRILL/rbridge list changover now complete X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 22:26:21 -0000 Hi, all, As I noted previously, this is the new home of the rbridge mailing list. All posts to "rbridge@postel.org" will be redirected here (as just happened with a test message I sent). However it would be preferable for everyone to start using the new "trill@ietf.org" address as soon as possible. This concludes my posts about the changeover. Joe (list admin) From d3e3e3@gmail.com Thu Apr 12 20:13:58 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3B3321F86C8 for ; Thu, 12 Apr 2012 20:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.218 X-Spam-Level: X-Spam-Status: No, score=-104.218 tagged_above=-999 required=5 tests=[AWL=-0.619, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 Fj7EplUmqeZA for ; Thu, 12 Apr 2012 20:13:58 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id E09D821F86B5 for ; Thu, 12 Apr 2012 20:13:57 -0700 (PDT) Received: by lagj5 with SMTP id j5so2241834lag.31 for ; Thu, 12 Apr 2012 20:13:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=tybgpl2yh1iY39r+GwGAYv6OlMs7oGiN8kaQOYYWGxk=; b=eGsVTH4ZDvS8GilypdQiaX+ZeRS9PDFmqXzqoSvF/A52Pw7/RBaae1pYfDJxeykC2X 4t4JJp9urtjYPEM4tAXGlxDMx1/8XYcD4epkIJaUXce1H2xVNa8MhamEFuu4y3Ud6dEa UWjG5G5QINQ/yMwCDf6jQUomJyQzlr3XJm+MMTv5VEKQip5G8Nd38t10f1em6RDuCAAj d9qmYikXMdYSsmHs0uF4efMXCpXCXXcjB/nBdQh5YrSkPJSwhS3+qHMae7qZ0Qz13bLZ ZK00tngFHMPhHQu3IRFwLmPKpl7fSYy8Iv7A4MwfFi9s1RMv9h/K7+mxpHL/nqNH7oEi b6CQ== Received: by 10.152.133.144 with SMTP id pc16mr83155lab.0.1334286836811; Thu, 12 Apr 2012 20:13:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.162 with HTTP; Thu, 12 Apr 2012 20:13:36 -0700 (PDT) From: Donald Eastlake Date: Thu, 12 Apr 2012 23:13:36 -0400 Message-ID: To: trill@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [trill] draft-hu-trill-rbridge-esadi to TRILL WG draft X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 03:13:58 -0000 This message begins a two week comment period for TRILL WG assent to make draft-hu-trill-rbridge-esadi-04.txt a TRILL WG draft. Thanks, Donald [Co-Chair) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com From dai.xuehui@zte.com.cn Mon Apr 16 19:52:21 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D95521F848A; Mon, 16 Apr 2012 19:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.035 X-Spam-Level: X-Spam-Status: No, score=-95.035 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] 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 q6OfMp177wlS; Mon, 16 Apr 2012 19:52:17 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id C10C911E8072; Mon, 16 Apr 2012 19:52:16 -0700 (PDT) Received: from [192.168.164.15] by mx5.zte.com.cn with surfront esmtp id 286201455586978; Tue, 17 Apr 2012 10:13:28 +0800 (CST) Received: from [10.30.3.21] by [192.168.164.15] with StormMail ESMTP id 16716.1726657790; Tue, 17 Apr 2012 10:36:25 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q3H2q7OA079309; Tue, 17 Apr 2012 10:52:07 +0800 (GMT-8) (envelope-from dai.xuehui@zte.com.cn) In-Reply-To: To: Donald Eastlake MIME-Version: 1.0 X-KeepSent: D30CA38E:2C79C7A8-482579E3:000FB18F; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: dai.xuehui@zte.com.cn Date: Tue, 17 Apr 2012 10:52:04 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-17 10:52:08, Serialize complete at 2012-04-17 10:52:08 Content-Type: multipart/alternative; boundary="=_alternative 000FC270482579E3_=" X-MAIL: mse02.zte.com.cn q3H2q7OA079309 Cc: trill-bounces@ietf.org, trill@ietf.org Subject: Re: [trill] draft-hu-trill-rbridge-esadi to TRILL WG draft X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 02:52:21 -0000 This is a multipart message in MIME format. --=_alternative 000FC270482579E3_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 KzGjrCBzdXBwb3J0DQoNCg0KDQoNCg0KRG9uYWxkIEVhc3RsYWtlIDxkM2UzZTNAZ21haWwuY29t PiANCreivP7IyzogIHRyaWxsLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMTItMDQtMTMgMTE6MTMNCg0K ytW8/sjLDQp0cmlsbEBpZXRmLm9yZw0Ks63LzQ0KDQrW98ziDQpbdHJpbGxdIGRyYWZ0LWh1LXRy aWxsLXJicmlkZ2UtZXNhZGkgdG8gVFJJTEwgV0cgZHJhZnQNCg0KDQoNCg0KDQoNClRoaXMgbWVz c2FnZSBiZWdpbnMgYSB0d28gd2VlayBjb21tZW50IHBlcmlvZCBmb3IgVFJJTEwgV0cgYXNzZW50 IHRvDQptYWtlIGRyYWZ0LWh1LXRyaWxsLXJicmlkZ2UtZXNhZGktMDQudHh0IGEgVFJJTEwgV0cg ZHJhZnQuDQoNClRoYW5rcywNCkRvbmFsZCBbQ28tQ2hhaXIpDQo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQ0KIERvbmFsZCBFLiBFYXN0bGFrZSAzcmQgICArMS01MDgtMzMzLTIyNzAgKGNl bGwpDQogMTU1IEJlYXZlciBTdHJlZXQsIE1pbGZvcmQsIE1BIDAxNzU3IFVTQQ0KIGQzZTNlM0Bn bWFpbC5jb20NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQp0cmlsbCBtYWlsaW5nIGxpc3QNCnRyaWxsQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsDQoNCg0KDQo= --=_alternative 000FC270482579E3_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPisxo6wgc3VwcG9ydDwvZm9udD4N Cjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZh bGlnbj10b3A+DQo8dGQgd2lkdGg9MzUlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48 Yj5Eb25hbGQgRWFzdGxha2UgJmx0O2QzZTNlM0BnbWFpbC5jb20mZ3Q7PC9iPg0KPC9mb250Pg0K PGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj63orz+yMs6ICZuYnNwO3RyaWxsLWJv dW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ MjAxMi0wNC0xMyAxMToxMzwvZm9udD4NCjx0ZCB3aWR0aD02NCU+DQo8dGFibGUgd2lkdGg9MTAw JT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj50cmlsbEBpZXRmLm9yZzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0K PHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63L zTwvZm9udD48L2Rpdj4NCjx0ZD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1y aWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0 ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+W3RyaWxsXSBkcmFmdC1odS10cmlsbC1y YnJpZGdlLWVzYWRpDQp0byBUUklMTCBXRyBkcmFmdDwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRh YmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0K PGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+VGhpcyBtZXNzYWdlIGJlZ2lucyBhIHR3 byB3ZWVrIGNvbW1lbnQgcGVyaW9kIGZvcg0KVFJJTEwgV0cgYXNzZW50IHRvPGJyPg0KbWFrZSBk cmFmdC1odS10cmlsbC1yYnJpZGdlLWVzYWRpLTA0LnR4dCBhIFRSSUxMIFdHIGRyYWZ0Ljxicj4N Cjxicj4NClRoYW5rcyw8YnI+DQpEb25hbGQgW0NvLUNoYWlyKTxicj4NCj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PGJyPg0KJm5ic3A7RG9uYWxkIEUuIEVhc3RsYWtlIDNyZCZuYnNwOyZu YnNwOyArMS01MDgtMzMzLTIyNzAgKGNlbGwpPGJyPg0KJm5ic3A7MTU1IEJlYXZlciBTdHJlZXQs Jm5ic3A7TWlsZm9yZCwgTUEgMDE3NTcgVVNBPGJyPg0KJm5ic3A7ZDNlM2UzQGdtYWlsLmNvbTxi cj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K dHJpbGwgbWFpbGluZyBsaXN0PGJyPg0KdHJpbGxAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsPGJyPg0KPGJyPg0KPC9mb250PjwvdHQ+DQo8 YnI+DQo= --=_alternative 000FC270482579E3_=-- From zhangmingui@huawei.com Tue Apr 17 01:32:03 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13D6D21F8468 for ; Tue, 17 Apr 2012 01:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 EuMw5Dty7FvO for ; Tue, 17 Apr 2012 01:31:59 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id D134121F8596 for ; Tue, 17 Apr 2012 01:31:58 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEZ12419; Tue, 17 Apr 2012 04:31:58 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 17 Apr 2012 01:29:33 -0700 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 17 Apr 2012 01:29:31 -0700 Received: from SZXEML507-MBS.china.huawei.com ([169.254.7.100]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0323.003; Tue, 17 Apr 2012 16:29:26 +0800 From: Mingui Zhang To: Donald Eastlake , "trill@ietf.org" Thread-Topic: [trill] draft-hu-trill-rbridge-esadi to TRILL WG draft Thread-Index: AQHNGSO/+iT9mAvDaEiVo6fiICef3Jaeq+XQ Date: Tue, 17 Apr 2012 08:29:26 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E728CB5D45@SZXEML507-MBS.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.73] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [trill] draft-hu-trill-rbridge-esadi to TRILL WG draft X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 08:32:03 -0000 I have read through the newest version of this document and support it. Thanks, Mingui s/A Link State PDU with fragment number equal to zero/A Link State PDU with= fragment number equals to zero/ s/end nodes/end stations/ "TRILL ESADI Frame Structure" should be put together with "Figure 1 " as th= e caption of the figure.=09 s/EASDAI/ESADI/ > -----Original Message----- > From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf= Of > Donald Eastlake > Sent: Friday, April 13, 2012 11:14 AM > To: trill@ietf.org > Subject: [trill] draft-hu-trill-rbridge-esadi to TRILL WG draft >=20 > This message begins a two week comment period for TRILL WG assent to > make draft-hu-trill-rbridge-esadi-04.txt a TRILL WG draft. >=20 > Thanks, > Donald [Co-Chair) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) > =A0155 Beaver Street,=A0Milford, MA 01757 USA > =A0d3e3e3@gmail.com > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill From internet-drafts@ietf.org Tue Apr 17 14:59:41 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFA7511E80CC for ; Tue, 17 Apr 2012 14:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.459 X-Spam-Level: X-Spam-Status: No, score=-102.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 zjV6-8+XxNK1 for ; Tue, 17 Apr 2012 14:59:41 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 8E06711E80B1 for ; Tue, 17 Apr 2012 14:59:41 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [12.22.58.30]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q3HLxC29017450 for ; Tue, 17 Apr 2012 14:59:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B49B11E80B1 for ; Tue, 17 Apr 2012 14:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 5QfVqT1CQ98I; Tue, 17 Apr 2012 14:59:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE58E11E8086; Tue, 17 Apr 2012 14:59:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120417215907.29707.76095.idtracker@ietfa.amsl.com> Date: Tue, 17 Apr 2012 14:59:07 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: internet-drafts@ietf.org Cc: rbridge@postel.org Subject: [trill] I-D Action: draft-ietf-trill-cmt-00.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 21:59:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transparent Interconnection of Lots o= f Links Working Group of the IETF. Title : Coordinated Multicast Trees (CMT)for TRILL Author(s) : Tissa Senevirathne Janardhanan Pathangi Jon Hudson Filename : draft-ietf-trill-cmt-00.txt Pages : 14 Date : 2012-04-17 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 to solve related RPF issues. CMT provides flexibility to RBridges to select desired path of association to a given distribution tree. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-trill-cmt-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-trill-cmt-00.txt From d3e3e3@gmail.com Wed Apr 18 21:11:51 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7F511E807F for ; Wed, 18 Apr 2012 21:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.049 X-Spam-Level: X-Spam-Status: No, score=-104.049 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 mbeBx+KHIcQG for ; Wed, 18 Apr 2012 21:11:46 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 30D6411E8075 for ; Wed, 18 Apr 2012 21:11:46 -0700 (PDT) Received: by lagj5 with SMTP id j5so6750454lag.31 for ; Wed, 18 Apr 2012 21:11:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=INDy9k8RSiFjjGgDwqBtL/Xpvs0MPBOYrTrGtQyB4mg=; b=0CC2pckIm3lDCfGffQMzie05zstcRPnQRESZVw4zt3W9SHRfBwnjquRnfFkeigJJx5 /pExx2YoRm7E9qScvOnOrEwkiOFibPhg/2/E7wnzH5dU36TAwgFkbowVUmy1cqyBeab1 ZqHhnm3VVJbHONOLloMNTiPL1Su9xhIo4bs+EwAgFZtOTBuiXNOh65gYUo8qKISO5eHr l4NWPWSQqOyDa62TqiKvN3FHrHeoUCcWDCpNx9edQRSe02DkEHLbPa9IcAcNqPxpWUWY bbTCQ7mYX7GOAf31PXn6I00dymbERwEUEuuLsZycxommuySmq++7M+fhrcahr23s8zVh 0z3Q== Received: by 10.152.111.198 with SMTP id ik6mr447435lab.38.1334808705141; Wed, 18 Apr 2012 21:11:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.162 with HTTP; Wed, 18 Apr 2012 21:11:24 -0700 (PDT) From: Donald Eastlake Date: Thu, 19 Apr 2012 00:11:24 -0400 Message-ID: To: trill@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [trill] Consensus for draft-ietf-trill-clear-correct X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 04:11:51 -0000 This draft has passed WGLC and there was sufficient support to incorporate the change posted here: http://www.ietf.org/mail-archive/web/trill/current/msg04869.html That change will be incorporated and we will request RFC publication. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com From tsenevir@cisco.com Thu Apr 19 14:03:02 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEAAD11E8093 for ; Thu, 19 Apr 2012 14:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.977 X-Spam-Level: X-Spam-Status: No, score=-6.977 tagged_above=-999 required=5 tests=[AWL=3.621, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 7zaD8Mua8749 for ; Thu, 19 Apr 2012 14:03:01 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC1F11E8089 for ; Thu, 19 Apr 2012 14:03:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tsenevir@cisco.com; l=2831; q=dns/txt; s=iport; t=1334869381; x=1336078981; h=mime-version:subject:date:message-id:from:to; bh=pXdvqhqfWyVeq5FO/W9JKR2jtGzVujAJPUG866gxPA8=; b=DU+vRq4++WrKkTlSDZXKtRRjAwLHhYzGiRnp3jGHoI/7bFHZlQCJXrU0 zPMIQIfeAK8ygHjSZA55sWZEB82xzD3YHXJ/WtFet68d/QREuXbYqBnuO etShFOHtJXVQSBcLS3gbNb7vna9YvGlgVye4Fi6IFPRpeGVsJPg2BGrRb 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAPF8kE+Q/khR/2dsb2JhbABDgkamD4hygQeCCwEEEgEJEQNbAQweBhgHVwEEGwEZh2wBC5lOgSigFI1CgkJjBIhcm2WBaYMH X-IronPort-AV: E=Sophos;i="4.75,447,1330905600"; d="scan'208,217";a="71316802" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 19 Apr 2012 21:02:53 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3JL2mCF002867 for ; Thu, 19 Apr 2012 21:02:50 GMT Received: from xbh-sjc-211.amer.cisco.com ([171.70.151.144]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 20 Apr 2012 02:32:45 +0530 Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Apr 2012 14:02:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD1E6F.B80D114E" Date: Thu, 19 Apr 2012 14:02:23 -0700 Message-ID: <344037D7CFEFE84E97E9CC1F56C5F4A50100E64C@xmb-sjc-214.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TRILL OAM Requriements - Thread-Index: Ac0eb7eEn/0rgR5FSVyjmY8KifcbtA== From: "Tissa Senevirathne (tsenevir)" To: X-OriginalArrivalTime: 19 Apr 2012 21:02:24.0080 (UTC) FILETIME=[B7FFA500:01CD1E6F] Subject: [trill] TRILL OAM Requriements - X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 21:03:02 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD1E6F.B80D114E Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Dear All As agreed during the 83rd IETF meeting we have published TRILL OAM Requirements. Below is the link to the ID. Please review and share your thoughts. =20 http://www.ietf.org/id/draft-tissa-trill-oam-req-00.txt =20 Thanks Tissa ------_=_NextPart_001_01CD1E6F.B80D114E Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Dear = All


As agreed during the = 83rd IETF meeting we have published TRILL OAM Requirements. = Below is the link to the ID. Please review and share your = thoughts.

 

http://w= ww.ietf.org/id/draft-tissa-trill-oam-req-00.txt

 

Thanks

Tissa

------_=_NextPart_001_01CD1E6F.B80D114E-- From xiao.min2@zte.com.cn Thu Apr 19 23:48:37 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4829F21F8742; Thu, 19 Apr 2012 23:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.776 X-Spam-Level: X-Spam-Status: No, score=-95.776 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] 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 7gSCIKDkRcTu; Thu, 19 Apr 2012 23:48:36 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 9E46E21F873D; Thu, 19 Apr 2012 23:48:35 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 286201455586978; Fri, 20 Apr 2012 14:09:14 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 23185.1726657790; Fri, 20 Apr 2012 14:48:15 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q3K6mJGM018024; Fri, 20 Apr 2012 14:48:19 +0800 (GMT-8) (envelope-from xiao.min2@zte.com.cn) In-Reply-To: To: Donald Eastlake MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: xiao.min2@zte.com.cn Date: Fri, 20 Apr 2012 14:48:13 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-20 14:48:21, Serialize complete at 2012-04-20 14:48:21 Content-Type: multipart/alternative; boundary="=_alternative 0025594A482579E6_=" X-MAIL: mse01.zte.com.cn q3K6mJGM018024 Cc: trill-bounces@ietf.org, trill@ietf.org Subject: Re: [trill] draft-hu-trill-rbridge-esadi to TRILL WG draft X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 06:48:37 -0000 This is a multipart message in MIME format. --=_alternative 0025594A482579E6_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 U3VwcG9ydC4NCg0KQlJzLA0KWGlhbyBNaW4NCg0KDQoNCg0KRG9uYWxkIEVhc3RsYWtlIDxkM2Uz ZTNAZ21haWwuY29tPiANCreivP7IyzogIHRyaWxsLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMTIvMDQv MTMgMTE6MTMNCg0KytW8/sjLDQp0cmlsbEBpZXRmLm9yZw0Ks63LzQ0KDQrW98ziDQpbdHJpbGxd IGRyYWZ0LWh1LXRyaWxsLXJicmlkZ2UtZXNhZGkgdG8gVFJJTEwgV0cgZHJhZnQNCg0KDQoNCg0K DQoNClRoaXMgbWVzc2FnZSBiZWdpbnMgYSB0d28gd2VlayBjb21tZW50IHBlcmlvZCBmb3IgVFJJ TEwgV0cgYXNzZW50IHRvDQptYWtlIGRyYWZ0LWh1LXRyaWxsLXJicmlkZ2UtZXNhZGktMDQudHh0 IGEgVFJJTEwgV0cgZHJhZnQuDQoNClRoYW5rcywNCkRvbmFsZCBbQ28tQ2hhaXIpDQo9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PQ0KIERvbmFsZCBFLiBFYXN0bGFrZSAzcmQgICArMS01MDgt MzMzLTIyNzAgKGNlbGwpDQogMTU1IEJlYXZlciBTdHJlZXQsIE1pbGZvcmQsIE1BIDAxNzU3IFVT QQ0KIGQzZTNlM0BnbWFpbC5jb20NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQp0cmlsbCBtYWlsaW5nIGxpc3QNCnRyaWxsQGlldGYub3JnDQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsDQoNCg0KDQo= --=_alternative 0025594A482579E6_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlN1cHBvcnQuPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5CUnMsPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5YaWFvIE1pbjwvZm9udD4NCjxicj4NCjxicj4N Cjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lk dGg9MzYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5Eb25hbGQgRWFzdGxha2Ug Jmx0O2QzZTNlM0BnbWFpbC5jb20mZ3Q7PC9iPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj63orz+yMs6ICZuYnNwO3RyaWxsLWJvdW5jZXNAaWV0Zi5vcmc8L2Zv bnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMi8wNC8xMyAxMToxMzwv Zm9udD4NCjx0ZCB3aWR0aD02MyU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9w Pg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj50 cmlsbEBpZXRmLm9yZzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1y aWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0 ZD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+W3RyaWxsXSBkcmFmdC1odS10cmlsbC1yYnJpZGdlLWVzYWRpDQp0byBU UklMTCBXRyBkcmFmdDwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxm b250IHNpemU9Mj48dHQ+VGhpcyBtZXNzYWdlIGJlZ2lucyBhIHR3byB3ZWVrIGNvbW1lbnQgcGVy aW9kIGZvcg0KVFJJTEwgV0cgYXNzZW50IHRvPGJyPg0KbWFrZSBkcmFmdC1odS10cmlsbC1yYnJp ZGdlLWVzYWRpLTA0LnR4dCBhIFRSSUxMIFdHIGRyYWZ0Ljxicj4NCjxicj4NClRoYW5rcyw8YnI+ DQpEb25hbGQgW0NvLUNoYWlyKTxicj4NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJy Pg0KJm5ic3A7RG9uYWxkIEUuIEVhc3RsYWtlIDNyZCZuYnNwOyZuYnNwOyArMS01MDgtMzMzLTIy NzAgKGNlbGwpPGJyPg0KJm5ic3A7MTU1IEJlYXZlciBTdHJlZXQsJm5ic3A7TWlsZm9yZCwgTUEg MDE3NTcgVVNBPGJyPg0KJm5ic3A7ZDNlM2UzQGdtYWlsLmNvbTxicj4NCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KdHJpbGwgbWFpbGluZyBsaXN0 PGJyPg0KdHJpbGxAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3RyaWxsPGJyPg0KPGJyPg0KPC90dD48L2ZvbnQ+DQo8YnI+DQo= --=_alternative 0025594A482579E6_=-- From somnath.chatterjee01@gmail.com Fri Apr 20 10:17:28 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9C4F21F8681 for ; Fri, 20 Apr 2012 10:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_53=0.6, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_LOW=-1] 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 kwW82m6MpdUF for ; Fri, 20 Apr 2012 10:17:28 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 35E7B21F867F for ; Fri, 20 Apr 2012 10:17:27 -0700 (PDT) Received: by yhkk25 with SMTP id k25so6104601yhk.31 for ; Fri, 20 Apr 2012 10:17:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=oTkoQqF49APwKrBBdqn+5RS5q+r4b+G2XP7uDLzk234=; b=xu1btnUS8bWYISxUj1zgBuJ1rURQNTrtj9L80grrYdH8U0YLUQRif34PAM5lMuRyl7 pSOwsjOCR4iVmBs/pEH39gBfUP1gcPz604iJpz7Jdv85ocaVWUX84cd1TRvECz5hH7fQ wVFpFqimcBwBt9knQ1k2oHV0eKDkSbQger7FyNOOA/6k5euTuEC6PFFdgEJWBFo44QTk 4YilbGPszeHV9fks4wp4g0G4XGn1PACxaWx163qhUij7NGuIKispyd89TIMFWvd/U+0C 6wA5dbuoLrUBc1DKcy0ged5MX2nvwy2wDF6/lr5yeCxwGYQX011JJKOZbqQrbTPgVCV4 0/0g== MIME-Version: 1.0 Received: by 10.236.175.164 with SMTP id z24mr6733657yhl.101.1334942247667; Fri, 20 Apr 2012 10:17:27 -0700 (PDT) Received: by 10.146.103.2 with HTTP; Fri, 20 Apr 2012 10:17:27 -0700 (PDT) Date: Fri, 20 Apr 2012 22:47:27 +0530 Message-ID: From: somnath chatterjee To: trill@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [trill] [rbridge] draft-hu-trill-rbridge-esadi-04 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 17:17:28 -0000 Hi Authors, I have read the draft-hu-trill-rbridge-esadi-04 and support it. I have one question regarding the problem stated in the draft " 2. Fast update advantages: ESADI protocol provides a fast update of end nodes MAC (Media Access Control) addresses. If an end station is unplugged from one RBridge and plugged into another, frames addressed to that older RBridge can be black holed. They can be sent just to the older RBridge that the end station was connected to until cached address information at some remote RBridge times out, possibly for tens of seconds [RFC6325]." In this scenario when an end-station moves TO a link where an RBridge(RBx) with ESADI support is serving as AF for the vlan on which the end-station is connected, this RBridge sends the end-station MACs through ESADI pdu to other ESADI RBridges with a higher confidence and the old routes in other ESADI RBridges are over-written.New routes(MAC "A" is reachable via egress RBridge RBx) exist and frames destined to MAC "A" are not black holed. But what if this end-station moves FROM a link which has RBridge(RB1) with ESADI support TO a link where RBridge(RB2) donot have ESADI support. Is there any way RB1 can notify other ESADI implemented RBridges in the campus to flush the old route(MAC "A" is reachable via egress RB1) so that frames for MAC "A" are not send directly to RB1 and are rather treated as unknown unicast frame and send on a DTree? Could RB1 send to ESADI Implemented RBridges that MAC "A" is no longer reachable via itself by sending confidence as 0 for that MAC in its ESADI pdus? Please correct me if my understanding is wrong. Also could we recommend ESADI implemented RBridges to become DRB and serve more AF for vlans. Editorial comments and typos: In Abstract ESADI (End System Address Distribution Information) should be replaced by ESADI (End Station Address Distribution Information) as per RFC6325 In section 3. ESADI DRB State 8th line: "for which RB1 is holding an ESADI-LSP zero with an ESADI Pararmeters" , typo for "Parameters" In section 4. ESADI PDU processing 4th line: "are only EASDI-LSP, EASDI-CSNP and EASDI-PSNP PDUs used in ESADI."should be changed to "are only ESADI-LSP, ESADI-CSNP and ESADI-PSNP PDUs used in ESADI." In section 4.1 Sending of ESASI PDUs Change the typo in the header itself. 4th line: "6(Innter.MacSA)" to '6(Inner.MacSA)" 5th line: "starting with the Intradomain Routeing Protocol Discriminator," Typo "Routeing" to "Routing" 2nd Para, 1st line: "Once an ESADI instance is operationally up, it multicasts it self- originated LSP number zero on the virtual link to announce its ESADI parameters." may be changed to "Once an ESADI instance is operationally up, it multicasts/sends its self- originated LSP number zero on the virtual link to announce its ESADI parameters." 5th Para, 2nd line: Typo "EASDI" In section 5. ESADI-LSP Contents 7th line typo "EASDAI-LSPs In section 5.1 ESADI Parameter Data 4th line typo "occurrnce" Thank you, Regards, Somnath From hu.fangwei@zte.com.cn Sat Apr 21 20:27:54 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF8E21F8466; Sat, 21 Apr 2012 20:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.435 X-Spam-Level: X-Spam-Status: No, score=-96.435 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, J_CHICKENPOX_63=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] 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 eWzI-Vw6EnxN; Sat, 21 Apr 2012 20:27:53 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 709D321F8452; Sat, 21 Apr 2012 20:27:52 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 286201455586978; Sun, 22 Apr 2012 10:48:09 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 96035.2371961387; Sun, 22 Apr 2012 11:27:45 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q3M3ReoK046561; Sun, 22 Apr 2012 11:27:40 +0800 (GMT-8) (envelope-from hu.fangwei@zte.com.cn) In-Reply-To: To: somnath chatterjee MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.4 June 01, 2004 Message-ID: From: hu.fangwei@zte.com.cn Date: Sun, 22 Apr 2012 11:27:31 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-22 11:27:42, Serialize complete at 2012-04-22 11:27:42 Content-Type: multipart/alternative; boundary="=_alternative 001303A0482579E8_=" X-MAIL: mse02.zte.com.cn q3M3ReoK046561 Cc: trill-bounces@ietf.org, trill@ietf.org Subject: Re: [trill] [rbridge] draft-hu-trill-rbridge-esadi-04 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2012 03:27:54 -0000 This is a multipart message in MIME format. --=_alternative 001303A0482579E8_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgcmV2aWV3aW5nIGFuZCBjb21tZW50cy4NCg0KUGxzIHNlZSB0aGUgZm9s bG93aW5nIGluIGxpbmUuDQoNCj5IaSBBdXRob3JzLA0KDQo+SSBoYXZlIHJlYWQgdGhlIGRyYWZ0 LWh1LXRyaWxsLXJicmlkZ2UtZXNhZGktMDQgYW5kIHN1cHBvcnQgaXQuDQoNCj5JIGhhdmUgb25l IHF1ZXN0aW9uIHJlZ2FyZGluZyB0aGUgcHJvYmxlbSBzdGF0ZWQgaW4gdGhlIGRyYWZ0DQoNCj4g IiAyLiBGYXN0IHVwZGF0ZSBhZHZhbnRhZ2VzOiBFU0FESSBwcm90b2NvbCBwcm92aWRlcyBhIGZh c3QgdXBkYXRlIG9mDQogICAgICBlbmQgbm9kZXMgTUFDIChNZWRpYSBBY2Nlc3MgQ29udHJvbCkg YWRkcmVzc2VzLiAgSWYgYW4gZW5kIHN0YXRpb24NCiAgICAgIGlzIHVucGx1Z2dlZCBmcm9tIG9u ZSBSQnJpZGdlIGFuZCBwbHVnZ2VkIGludG8gYW5vdGhlciwgZnJhbWVzDQogICAgICBhZGRyZXNz ZWQgdG8gdGhhdCBvbGRlciBSQnJpZGdlIGNhbiBiZSBibGFjayBob2xlZC4gIFRoZXkgY2FuIGJl DQogICAgICBzZW50IGp1c3QgdG8gdGhlIG9sZGVyIFJCcmlkZ2UgdGhhdCB0aGUgZW5kIHN0YXRp b24gd2FzIGNvbm5lY3RlZA0KICAgICAgdG8gdW50aWwgY2FjaGVkIGFkZHJlc3MgaW5mb3JtYXRp b24gYXQgc29tZSByZW1vdGUgUkJyaWRnZSB0aW1lcw0KICAgICAgb3V0LCBwb3NzaWJseSBmb3Ig dGVucyBvZiBzZWNvbmRzIFtSRkM2MzI1XS4iDQoNCj5JbiB0aGlzIHNjZW5hcmlvIHdoZW4gYW4g ZW5kLXN0YXRpb24gbW92ZXMgVE8gYSBsaW5rIHdoZXJlIGFuDQo+UkJyaWRnZShSQngpIHdpdGgg RVNBREkgc3VwcG9ydCBpcyBzZXJ2aW5nIGFzIEFGIGZvciB0aGUgdmxhbiBvbiB3aGljaA0KPnRo ZSBlbmQtc3RhdGlvbiBpcyBjb25uZWN0ZWQsIHRoaXMgUkJyaWRnZSBzZW5kcyB0aGUgZW5kLXN0 YXRpb24gTUFDcw0KPnRocm91Z2ggRVNBREkgcGR1IHRvIG90aGVyIEVTQURJIFJCcmlkZ2VzIHdp dGggYSBoaWdoZXIgY29uZmlkZW5jZSBhbmQNCj50aGUgb2xkIHJvdXRlcyBpbiBvdGhlciBFU0FE SSBSQnJpZGdlcyBhcmUgb3Zlci13cml0dGVuLk5ldyByb3V0ZXMoTUFDDQo+IkEiIGlzIHJlYWNo YWJsZSB2aWEgZWdyZXNzIFJCcmlkZ2UgUkJ4KSBleGlzdCBhbmQgZnJhbWVzIGRlc3RpbmVkIHRv DQo+TUFDICJBIiBhcmUgbm90IGJsYWNrIGhvbGVkLg0KDQo+QnV0IHdoYXQgaWYgdGhpcyBlbmQt c3RhdGlvbiBtb3ZlcyBGUk9NIGEgbGluayB3aGljaCBoYXMgUkJyaWRnZShSQjEpDQo+d2l0aCBF U0FESSBzdXBwb3J0IFRPIGEgbGluayB3aGVyZSBSQnJpZGdlKFJCMikgZG9ub3QgaGF2ZSBFU0FE SQ0KPnN1cHBvcnQuIElzIHRoZXJlIGFueSB3YXkgUkIxIGNhbiBub3RpZnkgb3RoZXIgRVNBREkg aW1wbGVtZW50ZWQNCj5SQnJpZGdlcyBpbiB0aGUgY2FtcHVzIHRvIGZsdXNoIHRoZSBvbGQgcm91 dGUoTUFDICJBIiBpcyByZWFjaGFibGUgdmlhDQo+ZWdyZXNzIFJCMSkgc28gdGhhdCBmcmFtZXMg Zm9yIE1BQyAiQSIgYXJlIG5vdCBzZW5kIGRpcmVjdGx5IHRvIFJCMQ0KPmFuZCBhcmUgcmF0aGVy IHRyZWF0ZWQgYXMgdW5rbm93biB1bmljYXN0IGZyYW1lIGFuZCBzZW5kIG9uIGEgRFRyZWU/DQo+ Q291bGQgUkIxIHNlbmQgdG8gRVNBREkgSW1wbGVtZW50ZWQgUkJyaWRnZXMgdGhhdCBNQUMgIkEi IGlzIG5vIGxvbmdlcg0KPnJlYWNoYWJsZSB2aWEgaXRzZWxmIGJ5IHNlbmRpbmcgY29uZmlkZW5j ZSBhcyAwIGZvciB0aGF0IE1BQyBpbiBpdHMNCj5FU0FESSBwZHVzPw0KDQpbaGZ3XSBJZiBSQjEg bm90aWZ5IHRoYXQgdGhlIGVuZC1zdGF0aW9uIG1vdmVzIGZyb20gdGhlIGxpbmssIFJCMSB3aWxs IA0KdXBkYXRlDQoNCiBhbmQgZmxvb2QgdGhlIExTUCBvcmlnaW5hdGVkIHdpdGggbnVsbGluZyBv dXQgdGhlIGVuZC1zdGF0aW9uIGFkZHJlc3MuIA0KV2hlbiBvdGhlciBFU0FESSANCg0KIFJCcmlk Z2UgcmVjZWl2ZXMgdGhlIHVwZGF0ZWQgTFNQLCB0aGV5IHdpbGwgZm9yZ2V0IHRoZSBNQUMgIkEi IGZyb20gaXRzIA0KTUFDIHRhYmxlLg0KDQogSW4gdGhpcyB3YXksIEVTQURJIHByb3RvY29sIGNh biBmYXN0IHVwZGF0ZSB0aGUgTUFDIHRhYmxlIG9mIHJlbW90ZSANClJCcmlkZ2VzIHdoZW4gdGhl IGVuZCBzdGF0aW9uIGF0dGFjaGVkDQoNCiBpcyB1bnBsdWdlZCBvciBhIG5ldyBlbmQgc3RhdGlv biBpcyBwbHVnZWQuDQoNCg0KPlBsZWFzZSBjb3JyZWN0IG1lIGlmIG15IHVuZGVyc3RhbmRpbmcg aXMgd3JvbmcuDQoNCj5BbHNvIGNvdWxkIHdlIHJlY29tbWVuZCBFU0FESSBpbXBsZW1lbnRlZCBS QnJpZGdlcyB0byBiZWNvbWUgRFJCIGFuZA0KPnNlcnZlIG1vcmUgQUYgZm9yIHZsYW5zLg0KDQo+ RWRpdG9yaWFsIGNvbW1lbnRzIGFuZCB0eXBvczoNCg0KPkluIEFic3RyYWN0DQo+RVNBREkgKEVu ZCBTeXN0ZW0gQWRkcmVzcyBEaXN0cmlidXRpb24gSW5mb3JtYXRpb24pIHNob3VsZCBiZSByZXBs YWNlZCBieQ0KPkVTQURJIChFbmQgU3RhdGlvbiBBZGRyZXNzIERpc3RyaWJ1dGlvbiBJbmZvcm1h dGlvbikgYXMgcGVyIFJGQzYzMjUNCg0KPkluIHNlY3Rpb24gMy4gRVNBREkgRFJCIFN0YXRlDQo+ OHRoIGxpbmU6ICJmb3Igd2hpY2ggUkIxIGlzIGhvbGRpbmcgYW4gRVNBREktTFNQIHplcm8gd2l0 aCBhbiBFU0FESQ0KPlBhcmFybWV0ZXJzIiAsIHR5cG8gZm9yICJQYXJhbWV0ZXJzIg0KDQoNCj5J biBzZWN0aW9uIDQuIEVTQURJIFBEVSBwcm9jZXNzaW5nDQo+NHRoIGxpbmU6ICAgICAiYXJlIG9u bHkgRUFTREktTFNQLCBFQVNESS1DU05QIGFuZCBFQVNESS1QU05QIFBEVXMgdXNlZA0KPmluIEVT QURJLiJzaG91bGQgYmUgY2hhbmdlZCB0bw0KPiAgICJhcmUgb25seSBFU0FESS1MU1AsIEVTQURJ LUNTTlAgYW5kIEVTQURJLVBTTlAgUERVcyB1c2VkIGluIEVTQURJLiINCg0KPkluIHNlY3Rpb24g NC4xIFNlbmRpbmcgb2YgRVNBU0kgUERVcw0KDQo+Q2hhbmdlIHRoZSB0eXBvIGluIHRoZSBoZWFk ZXIgaXRzZWxmLg0KDQo+NHRoIGxpbmU6ICAgICI2KElubnRlci5NYWNTQSkiIHRvICc2KElubmVy Lk1hY1NBKSINCg0KPjV0aCBsaW5lOiAgICAgInN0YXJ0aW5nIHdpdGggdGhlIEludHJhZG9tYWlu IFJvdXRlaW5nIFByb3RvY29sDQo+RGlzY3JpbWluYXRvciwiIFR5cG8gIlJvdXRlaW5nIiB0byAi Um91dGluZyINCg0KPjJuZCBQYXJhLCAxc3QgbGluZTogIk9uY2UgYW4gRVNBREkgaW5zdGFuY2Ug aXMgb3BlcmF0aW9uYWxseSB1cCwgaXQNCj5tdWx0aWNhc3RzIGl0IHNlbGYtDQogPiAgb3JpZ2lu YXRlZCBMU1AgbnVtYmVyIHplcm8gb24gdGhlIHZpcnR1YWwgbGluayB0byBhbm5vdW5jZSBpdHMg RVNBREkNCiA+ICBwYXJhbWV0ZXJzLiIgICBtYXkgYmUgY2hhbmdlZCB0bw0KPiJPbmNlIGFuIEVT QURJIGluc3RhbmNlIGlzIG9wZXJhdGlvbmFsbHkgdXAsIGl0IG11bHRpY2FzdHMvc2VuZHMgaXRz IA0Kc2VsZi0NCj4gICBvcmlnaW5hdGVkIExTUCBudW1iZXIgemVybyBvbiB0aGUgdmlydHVhbCBs aW5rIHRvIGFubm91bmNlIGl0cyBFU0FESQ0KPiAgIHBhcmFtZXRlcnMuIg0KDQo+NXRoIFBhcmEs IDJuZCBsaW5lOiBUeXBvICJFQVNESSINCg0KPkluIHNlY3Rpb24gNS4gRVNBREktTFNQIENvbnRl bnRzDQo+N3RoIGxpbmUgdHlwbyAiRUFTREFJLUxTUHMNCg0KPkluIHNlY3Rpb24gNS4xIEVTQURJ IFBhcmFtZXRlciBEYXRhDQo+NHRoIGxpbmUgdHlwbyAib2NjdXJybmNlIg0KDQpbaGZ3XSBUaGFu a3MgZm9yIHRoZSBjb3JyZWN0aW5nLCB3ZSB3aWxsIGNvcnJlY3QgaXQgaW4gdGhlIG5leHQgdmVy c2lvbi4NCg0KDQoNCg0Kc29tbmF0aCBjaGF0dGVyamVlIDxzb21uYXRoLmNoYXR0ZXJqZWUwMUBn bWFpbC5jb20+IA0Kt6K8/sjLOiAgdHJpbGwtYm91bmNlc0BpZXRmLm9yZw0KMjAxMi0wNC0yMSAw MToxNw0KDQrK1bz+yMsNCnRyaWxsQGlldGYub3JnDQqzrcvNDQoNCtb3zOINClt0cmlsbF0gW3Ji cmlkZ2VdIGRyYWZ0LWh1LXRyaWxsLXJicmlkZ2UtZXNhZGktMDQNCg0KDQoNCg0KDQoNCkhpIEF1 dGhvcnMsDQoNCkkgaGF2ZSByZWFkIHRoZSBkcmFmdC1odS10cmlsbC1yYnJpZGdlLWVzYWRpLTA0 IGFuZCBzdXBwb3J0IGl0Lg0KDQpJIGhhdmUgb25lIHF1ZXN0aW9uIHJlZ2FyZGluZyB0aGUgcHJv YmxlbSBzdGF0ZWQgaW4gdGhlIGRyYWZ0DQoNCiAiIDIuIEZhc3QgdXBkYXRlIGFkdmFudGFnZXM6 IEVTQURJIHByb3RvY29sIHByb3ZpZGVzIGEgZmFzdCB1cGRhdGUgb2YNCiAgICAgIGVuZCBub2Rl cyBNQUMgKE1lZGlhIEFjY2VzcyBDb250cm9sKSBhZGRyZXNzZXMuICBJZiBhbiBlbmQgc3RhdGlv bg0KICAgICAgaXMgdW5wbHVnZ2VkIGZyb20gb25lIFJCcmlkZ2UgYW5kIHBsdWdnZWQgaW50byBh bm90aGVyLCBmcmFtZXMNCiAgICAgIGFkZHJlc3NlZCB0byB0aGF0IG9sZGVyIFJCcmlkZ2UgY2Fu IGJlIGJsYWNrIGhvbGVkLiAgVGhleSBjYW4gYmUNCiAgICAgIHNlbnQganVzdCB0byB0aGUgb2xk ZXIgUkJyaWRnZSB0aGF0IHRoZSBlbmQgc3RhdGlvbiB3YXMgY29ubmVjdGVkDQogICAgICB0byB1 bnRpbCBjYWNoZWQgYWRkcmVzcyBpbmZvcm1hdGlvbiBhdCBzb21lIHJlbW90ZSBSQnJpZGdlIHRp bWVzDQogICAgICBvdXQsIHBvc3NpYmx5IGZvciB0ZW5zIG9mIHNlY29uZHMgW1JGQzYzMjVdLiIN Cg0KSW4gdGhpcyBzY2VuYXJpbyB3aGVuIGFuIGVuZC1zdGF0aW9uIG1vdmVzIFRPIGEgbGluayB3 aGVyZSBhbg0KUkJyaWRnZShSQngpIHdpdGggRVNBREkgc3VwcG9ydCBpcyBzZXJ2aW5nIGFzIEFG IGZvciB0aGUgdmxhbiBvbiB3aGljaA0KdGhlIGVuZC1zdGF0aW9uIGlzIGNvbm5lY3RlZCwgdGhp cyBSQnJpZGdlIHNlbmRzIHRoZSBlbmQtc3RhdGlvbiBNQUNzDQp0aHJvdWdoIEVTQURJIHBkdSB0 byBvdGhlciBFU0FESSBSQnJpZGdlcyB3aXRoIGEgaGlnaGVyIGNvbmZpZGVuY2UgYW5kDQp0aGUg b2xkIHJvdXRlcyBpbiBvdGhlciBFU0FESSBSQnJpZGdlcyBhcmUgb3Zlci13cml0dGVuLk5ldyBy b3V0ZXMoTUFDDQoiQSIgaXMgcmVhY2hhYmxlIHZpYSBlZ3Jlc3MgUkJyaWRnZSBSQngpIGV4aXN0 IGFuZCBmcmFtZXMgZGVzdGluZWQgdG8NCk1BQyAiQSIgYXJlIG5vdCBibGFjayBob2xlZC4NCg0K QnV0IHdoYXQgaWYgdGhpcyBlbmQtc3RhdGlvbiBtb3ZlcyBGUk9NIGEgbGluayB3aGljaCBoYXMg UkJyaWRnZShSQjEpDQp3aXRoIEVTQURJIHN1cHBvcnQgVE8gYSBsaW5rIHdoZXJlIFJCcmlkZ2Uo UkIyKSBkb25vdCBoYXZlIEVTQURJDQpzdXBwb3J0LiBJcyB0aGVyZSBhbnkgd2F5IFJCMSBjYW4g bm90aWZ5IG90aGVyIEVTQURJIGltcGxlbWVudGVkDQpSQnJpZGdlcyBpbiB0aGUgY2FtcHVzIHRv IGZsdXNoIHRoZSBvbGQgcm91dGUoTUFDICJBIiBpcyByZWFjaGFibGUgdmlhDQplZ3Jlc3MgUkIx KSBzbyB0aGF0IGZyYW1lcyBmb3IgTUFDICJBIiBhcmUgbm90IHNlbmQgZGlyZWN0bHkgdG8gUkIx DQphbmQgYXJlIHJhdGhlciB0cmVhdGVkIGFzIHVua25vd24gdW5pY2FzdCBmcmFtZSBhbmQgc2Vu ZCBvbiBhIERUcmVlPw0KQ291bGQgUkIxIHNlbmQgdG8gRVNBREkgSW1wbGVtZW50ZWQgUkJyaWRn ZXMgdGhhdCBNQUMgIkEiIGlzIG5vIGxvbmdlcg0KcmVhY2hhYmxlIHZpYSBpdHNlbGYgYnkgc2Vu ZGluZyBjb25maWRlbmNlIGFzIDAgZm9yIHRoYXQgTUFDIGluIGl0cw0KRVNBREkgcGR1cz8NCg0K UGxlYXNlIGNvcnJlY3QgbWUgaWYgbXkgdW5kZXJzdGFuZGluZyBpcyB3cm9uZy4NCg0KQWxzbyBj b3VsZCB3ZSByZWNvbW1lbmQgRVNBREkgaW1wbGVtZW50ZWQgUkJyaWRnZXMgdG8gYmVjb21lIERS QiBhbmQNCnNlcnZlIG1vcmUgQUYgZm9yIHZsYW5zLg0KDQpFZGl0b3JpYWwgY29tbWVudHMgYW5k IHR5cG9zOg0KDQpJbiBBYnN0cmFjdA0KRVNBREkgKEVuZCBTeXN0ZW0gQWRkcmVzcyBEaXN0cmli dXRpb24gSW5mb3JtYXRpb24pIHNob3VsZCBiZSByZXBsYWNlZCBieQ0KRVNBREkgKEVuZCBTdGF0 aW9uIEFkZHJlc3MgRGlzdHJpYnV0aW9uIEluZm9ybWF0aW9uKSBhcyBwZXIgUkZDNjMyNQ0KDQpJ biBzZWN0aW9uIDMuIEVTQURJIERSQiBTdGF0ZQ0KOHRoIGxpbmU6ICJmb3Igd2hpY2ggUkIxIGlz IGhvbGRpbmcgYW4gRVNBREktTFNQIHplcm8gd2l0aCBhbiBFU0FESQ0KUGFyYXJtZXRlcnMiICwg dHlwbyBmb3IgIlBhcmFtZXRlcnMiDQoNCg0KSW4gc2VjdGlvbiA0LiBFU0FESSBQRFUgcHJvY2Vz c2luZw0KNHRoIGxpbmU6ICAgICAiYXJlIG9ubHkgRUFTREktTFNQLCBFQVNESS1DU05QIGFuZCBF QVNESS1QU05QIFBEVXMgdXNlZA0KaW4gRVNBREkuInNob3VsZCBiZSBjaGFuZ2VkIHRvDQogICAi YXJlIG9ubHkgRVNBREktTFNQLCBFU0FESS1DU05QIGFuZCBFU0FESS1QU05QIFBEVXMgdXNlZCBp biBFU0FESS4iDQoNCkluIHNlY3Rpb24gNC4xIFNlbmRpbmcgb2YgRVNBU0kgUERVcw0KDQpDaGFu Z2UgdGhlIHR5cG8gaW4gdGhlIGhlYWRlciBpdHNlbGYuDQoNCjR0aCBsaW5lOiAgICAiNihJbm50 ZXIuTWFjU0EpIiB0byAnNihJbm5lci5NYWNTQSkiDQoNCjV0aCBsaW5lOiAgICAgInN0YXJ0aW5n IHdpdGggdGhlIEludHJhZG9tYWluIFJvdXRlaW5nIFByb3RvY29sDQpEaXNjcmltaW5hdG9yLCIg VHlwbyAiUm91dGVpbmciIHRvICJSb3V0aW5nIg0KDQoybmQgUGFyYSwgMXN0IGxpbmU6ICJPbmNl IGFuIEVTQURJIGluc3RhbmNlIGlzIG9wZXJhdGlvbmFsbHkgdXAsIGl0DQptdWx0aWNhc3RzIGl0 IHNlbGYtDQogICBvcmlnaW5hdGVkIExTUCBudW1iZXIgemVybyBvbiB0aGUgdmlydHVhbCBsaW5r IHRvIGFubm91bmNlIGl0cyBFU0FESQ0KICAgcGFyYW1ldGVycy4iICAgbWF5IGJlIGNoYW5nZWQg dG8NCiJPbmNlIGFuIEVTQURJIGluc3RhbmNlIGlzIG9wZXJhdGlvbmFsbHkgdXAsIGl0IG11bHRp Y2FzdHMvc2VuZHMgaXRzIHNlbGYtDQogICBvcmlnaW5hdGVkIExTUCBudW1iZXIgemVybyBvbiB0 aGUgdmlydHVhbCBsaW5rIHRvIGFubm91bmNlIGl0cyBFU0FESQ0KICAgcGFyYW1ldGVycy4iDQoN CjV0aCBQYXJhLCAybmQgbGluZTogVHlwbyAiRUFTREkiDQoNCkluIHNlY3Rpb24gNS4gRVNBREkt TFNQIENvbnRlbnRzDQo3dGggbGluZSB0eXBvICJFQVNEQUktTFNQcw0KDQpJbiBzZWN0aW9uIDUu MSBFU0FESSBQYXJhbWV0ZXIgRGF0YQ0KNHRoIGxpbmUgdHlwbyAib2NjdXJybmNlIg0KDQpUaGFu ayB5b3UsDQpSZWdhcmRzLA0KU29tbmF0aA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCnRyaWxsIG1haWxpbmcgbGlzdA0KdHJpbGxAaWV0Zi5vcmcNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJpbGwNCg0KDQoNCg== --=_alternative 001303A0482579E8_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcyBmb3IgdGhlIHJldmll d2luZyBhbmQgY29tbWVudHMuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj5QbHMgc2VlIHRoZSBmb2xsb3dpbmcgaW4gbGluZS48L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7SGkgQXV0aG9ycyw8YnI+DQo8YnI+DQomZ3Q7SSBoYXZl IHJlYWQgdGhlIGRyYWZ0LWh1LXRyaWxsLXJicmlkZ2UtZXNhZGktMDQgYW5kIHN1cHBvcnQgaXQu PGJyPg0KPGJyPg0KJmd0O0kgaGF2ZSBvbmUgcXVlc3Rpb24gcmVnYXJkaW5nIHRoZSBwcm9ibGVt IHN0YXRlZCBpbiB0aGUgZHJhZnQ8YnI+DQo8YnI+DQomZ3Q7ICZxdW90OyAyLiBGYXN0IHVwZGF0 ZSBhZHZhbnRhZ2VzOiBFU0FESSBwcm90b2NvbCBwcm92aWRlcyBhIGZhc3QgdXBkYXRlDQpvZjxi cj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwO2VuZCBub2RlcyBNQUMgKE1lZGlhIEFjY2VzcyBDb250 cm9sKSBhZGRyZXNzZXMuICZuYnNwO0lmDQphbiBlbmQgc3RhdGlvbjxicj4NCiAmbmJzcDsgJm5i c3A7ICZuYnNwO2lzIHVucGx1Z2dlZCBmcm9tIG9uZSBSQnJpZGdlIGFuZCBwbHVnZ2VkIGludG8g YW5vdGhlciwNCmZyYW1lczxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwO2FkZHJlc3NlZCB0byB0 aGF0IG9sZGVyIFJCcmlkZ2UgY2FuIGJlIGJsYWNrIGhvbGVkLg0KJm5ic3A7VGhleSBjYW4gYmU8 YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDtzZW50IGp1c3QgdG8gdGhlIG9sZGVyIFJCcmlkZ2Ug dGhhdCB0aGUgZW5kIHN0YXRpb24NCndhcyBjb25uZWN0ZWQ8YnI+DQogJm5ic3A7ICZuYnNwOyAm bmJzcDt0byB1bnRpbCBjYWNoZWQgYWRkcmVzcyBpbmZvcm1hdGlvbiBhdCBzb21lIHJlbW90ZQ0K UkJyaWRnZSB0aW1lczxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwO291dCwgcG9zc2libHkgZm9y IHRlbnMgb2Ygc2Vjb25kcyBbUkZDNjMyNV0uJnF1b3Q7PGJyPg0KPGJyPg0KJmd0O0luIHRoaXMg c2NlbmFyaW8gd2hlbiBhbiBlbmQtc3RhdGlvbiBtb3ZlcyBUTyBhIGxpbmsgd2hlcmUgYW48YnI+ DQomZ3Q7UkJyaWRnZShSQngpIHdpdGggRVNBREkgc3VwcG9ydCBpcyBzZXJ2aW5nIGFzIEFGIGZv ciB0aGUgdmxhbiBvbiB3aGljaDxicj4NCiZndDt0aGUgZW5kLXN0YXRpb24gaXMgY29ubmVjdGVk LCB0aGlzIFJCcmlkZ2Ugc2VuZHMgdGhlIGVuZC1zdGF0aW9uIE1BQ3M8YnI+DQomZ3Q7dGhyb3Vn aCBFU0FESSBwZHUgdG8gb3RoZXIgRVNBREkgUkJyaWRnZXMgd2l0aCBhIGhpZ2hlciBjb25maWRl bmNlDQphbmQ8YnI+DQomZ3Q7dGhlIG9sZCByb3V0ZXMgaW4gb3RoZXIgRVNBREkgUkJyaWRnZXMg YXJlIG92ZXItd3JpdHRlbi5OZXcgcm91dGVzKE1BQzxicj4NCiZndDsmcXVvdDtBJnF1b3Q7IGlz IHJlYWNoYWJsZSB2aWEgZWdyZXNzIFJCcmlkZ2UgUkJ4KSBleGlzdCBhbmQgZnJhbWVzDQpkZXN0 aW5lZCB0bzxicj4NCiZndDtNQUMgJnF1b3Q7QSZxdW90OyBhcmUgbm90IGJsYWNrIGhvbGVkLjxi cj4NCjxicj4NCiZndDtCdXQgd2hhdCBpZiB0aGlzIGVuZC1zdGF0aW9uIG1vdmVzIEZST00gYSBs aW5rIHdoaWNoIGhhcyBSQnJpZGdlKFJCMSk8YnI+DQomZ3Q7d2l0aCBFU0FESSBzdXBwb3J0IFRP IGEgbGluayB3aGVyZSBSQnJpZGdlKFJCMikgZG9ub3QgaGF2ZSBFU0FESTxicj4NCiZndDtzdXBw b3J0LiBJcyB0aGVyZSBhbnkgd2F5IFJCMSBjYW4gbm90aWZ5IG90aGVyIEVTQURJIGltcGxlbWVu dGVkPGJyPg0KJmd0O1JCcmlkZ2VzIGluIHRoZSBjYW1wdXMgdG8gZmx1c2ggdGhlIG9sZCByb3V0 ZShNQUMgJnF1b3Q7QSZxdW90OyBpcw0KcmVhY2hhYmxlIHZpYTxicj4NCiZndDtlZ3Jlc3MgUkIx KSBzbyB0aGF0IGZyYW1lcyBmb3IgTUFDICZxdW90O0EmcXVvdDsgYXJlIG5vdCBzZW5kIGRpcmVj dGx5DQp0byBSQjE8YnI+DQomZ3Q7YW5kIGFyZSByYXRoZXIgdHJlYXRlZCBhcyB1bmtub3duIHVu aWNhc3QgZnJhbWUgYW5kIHNlbmQgb24gYSBEVHJlZT88YnI+DQomZ3Q7Q291bGQgUkIxIHNlbmQg dG8gRVNBREkgSW1wbGVtZW50ZWQgUkJyaWRnZXMgdGhhdCBNQUMgJnF1b3Q7QSZxdW90Ow0KaXMg bm8gbG9uZ2VyPGJyPg0KJmd0O3JlYWNoYWJsZSB2aWEgaXRzZWxmIGJ5IHNlbmRpbmcgY29uZmlk ZW5jZSBhcyAwIGZvciB0aGF0IE1BQyBpbiBpdHM8YnI+DQomZ3Q7RVNBREkgcGR1cz88L3R0Pjwv Zm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0Pjxicj4NCltoZnddIElmIFJCMSBub3RpZnkgdGhh dCB0aGUgZW5kLXN0YXRpb24gbW92ZXMgZnJvbSB0aGUgbGluaywgUkIxIHdpbGwNCnVwZGF0ZTwv dHQ+PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jm5ic3A7YW5kIGZsb29kIHRo ZSBMU1Agb3JpZ2luYXRlZCB3aXRoIG51bGxpbmcgb3V0DQp0aGUgZW5kLXN0YXRpb24gYWRkcmVz cy4gV2hlbiBvdGhlciBFU0FESSA8L3R0PjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTI+ PHR0PiZuYnNwO1JCcmlkZ2UgcmVjZWl2ZXMgdGhlIHVwZGF0ZWQgTFNQLCB0aGV5IHdpbGwNCmZv cmdldCB0aGUgTUFDICZxdW90O0EmcXVvdDsgZnJvbSBpdHMgTUFDIHRhYmxlLjwvdHQ+PC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jm5ic3A7SW4gdGhpcyB3YXksIEVTQURJIHBy b3RvY29sIGNhbiBmYXN0IHVwZGF0ZQ0KdGhlIE1BQyB0YWJsZSBvZiByZW1vdGUgUkJyaWRnZXMg d2hlbiB0aGUgZW5kIHN0YXRpb24gYXR0YWNoZWQ8L3R0PjwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTI+PHR0PiZuYnNwO2lzIHVucGx1Z2VkIG9yIGEgbmV3IGVuZCBzdGF0aW9uIGlzIHBs dWdlZC48L3R0PjwvZm9udD4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8 dGQgd2lkdGg9MTAwJT48L3RhYmxlPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+PGJyPg0KJmd0O1Bs ZWFzZSBjb3JyZWN0IG1lIGlmIG15IHVuZGVyc3RhbmRpbmcgaXMgd3JvbmcuPGJyPg0KPGJyPg0K Jmd0O0Fsc28gY291bGQgd2UgcmVjb21tZW5kIEVTQURJIGltcGxlbWVudGVkIFJCcmlkZ2VzIHRv IGJlY29tZSBEUkIgYW5kPGJyPg0KJmd0O3NlcnZlIG1vcmUgQUYgZm9yIHZsYW5zLjxicj4NCjxi cj4NCiZndDtFZGl0b3JpYWwgY29tbWVudHMgYW5kIHR5cG9zOjxicj4NCjxicj4NCiZndDtJbiBB YnN0cmFjdDxicj4NCiZndDtFU0FESSAoRW5kIFN5c3RlbSBBZGRyZXNzIERpc3RyaWJ1dGlvbiBJ bmZvcm1hdGlvbikgc2hvdWxkIGJlIHJlcGxhY2VkDQpieTxicj4NCiZndDtFU0FESSAoRW5kIFN0 YXRpb24gQWRkcmVzcyBEaXN0cmlidXRpb24gSW5mb3JtYXRpb24pIGFzIHBlciBSRkM2MzI1PGJy Pg0KPGJyPg0KJmd0O0luIHNlY3Rpb24gMy4gRVNBREkgRFJCIFN0YXRlPGJyPg0KJmd0Ozh0aCBs aW5lOiAmcXVvdDtmb3Igd2hpY2ggUkIxIGlzIGhvbGRpbmcgYW4gRVNBREktTFNQIHplcm8gd2l0 aCBhbg0KRVNBREk8YnI+DQomZ3Q7UGFyYXJtZXRlcnMmcXVvdDsgLCB0eXBvIGZvciAmcXVvdDtQ YXJhbWV0ZXJzJnF1b3Q7PGJyPg0KPGJyPg0KPGJyPg0KJmd0O0luIHNlY3Rpb24gNC4gRVNBREkg UERVIHByb2Nlc3Npbmc8YnI+DQomZ3Q7NHRoIGxpbmU6ICZuYnNwOyAmbmJzcDsgJnF1b3Q7YXJl IG9ubHkgRUFTREktTFNQLCBFQVNESS1DU05QIGFuZCBFQVNESS1QU05QDQpQRFVzIHVzZWQ8YnI+ DQomZ3Q7aW4gRVNBREkuJnF1b3Q7c2hvdWxkIGJlIGNoYW5nZWQgdG88YnI+DQomZ3Q7ICZuYnNw OyAmcXVvdDthcmUgb25seSBFU0FESS1MU1AsIEVTQURJLUNTTlAgYW5kIEVTQURJLVBTTlAgUERV cyB1c2VkDQppbiBFU0FESS4mcXVvdDs8YnI+DQo8YnI+DQomZ3Q7SW4gc2VjdGlvbiA0LjEgU2Vu ZGluZyBvZiBFU0FTSSBQRFVzPGJyPg0KPGJyPg0KJmd0O0NoYW5nZSB0aGUgdHlwbyBpbiB0aGUg aGVhZGVyIGl0c2VsZi48YnI+DQo8YnI+DQomZ3Q7NHRoIGxpbmU6ICZuYnNwOyAmbmJzcDsmcXVv dDs2KElubnRlci5NYWNTQSkmcXVvdDsgdG8gJzYoSW5uZXIuTWFjU0EpJnF1b3Q7PGJyPg0KPGJy Pg0KJmd0OzV0aCBsaW5lOiAmbmJzcDsgJm5ic3A7ICZxdW90O3N0YXJ0aW5nIHdpdGggdGhlIElu dHJhZG9tYWluIFJvdXRlaW5nDQpQcm90b2NvbDxicj4NCiZndDtEaXNjcmltaW5hdG9yLCZxdW90 OyBUeXBvICZxdW90O1JvdXRlaW5nJnF1b3Q7IHRvICZxdW90O1JvdXRpbmcmcXVvdDs8YnI+DQo8 YnI+DQomZ3Q7Mm5kIFBhcmEsIDFzdCBsaW5lOiAmcXVvdDtPbmNlIGFuIEVTQURJIGluc3RhbmNl IGlzIG9wZXJhdGlvbmFsbHkgdXAsDQppdDxicj4NCiZndDttdWx0aWNhc3RzIGl0IHNlbGYtPGJy Pg0KICZndDsgJm5ic3A7b3JpZ2luYXRlZCBMU1AgbnVtYmVyIHplcm8gb24gdGhlIHZpcnR1YWwg bGluayB0byBhbm5vdW5jZQ0KaXRzIEVTQURJPGJyPg0KICZndDsgJm5ic3A7cGFyYW1ldGVycy4m cXVvdDsgJm5ic3A7IG1heSBiZSBjaGFuZ2VkIHRvPGJyPg0KJmd0OyZxdW90O09uY2UgYW4gRVNB REkgaW5zdGFuY2UgaXMgb3BlcmF0aW9uYWxseSB1cCwgaXQgbXVsdGljYXN0cy9zZW5kcw0KaXRz IHNlbGYtPGJyPg0KJmd0OyAmbmJzcDsgb3JpZ2luYXRlZCBMU1AgbnVtYmVyIHplcm8gb24gdGhl IHZpcnR1YWwgbGluayB0byBhbm5vdW5jZQ0KaXRzIEVTQURJPGJyPg0KJmd0OyAmbmJzcDsgcGFy YW1ldGVycy4mcXVvdDs8YnI+DQo8YnI+DQomZ3Q7NXRoIFBhcmEsIDJuZCBsaW5lOiBUeXBvICZx dW90O0VBU0RJJnF1b3Q7PGJyPg0KPGJyPg0KJmd0O0luIHNlY3Rpb24gNS4gRVNBREktTFNQIENv bnRlbnRzPGJyPg0KJmd0Ozd0aCBsaW5lIHR5cG8gJnF1b3Q7RUFTREFJLUxTUHM8YnI+DQo8YnI+ DQomZ3Q7SW4gc2VjdGlvbiA1LjEgRVNBREkgUGFyYW1ldGVyIERhdGE8YnI+DQomZ3Q7NHRoIGxp bmUgdHlwbyAmcXVvdDtvY2N1cnJuY2UmcXVvdDs8L3R0PjwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+W2hmd10gVGhhbmtzIGZvciB0aGUgY29ycmVjdGlu Zywgd2UNCndpbGwgY29ycmVjdCBpdCBpbiB0aGUgbmV4dCB2ZXJzaW9uLjxicj4NCjwvZm9udD4N Cjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8 dGQgd2lkdGg9MzUlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5zb21uYXRoIGNo YXR0ZXJqZWUgJmx0O3NvbW5hdGguY2hhdHRlcmplZTAxQGdtYWlsLmNvbSZndDs8L2I+DQo8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7dHJp bGwtYm91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj4yMDEyLTA0LTIxIDAxOjE3PC9mb250Pg0KPHRkIHdpZHRoPTY0JT4NCjx0YWJsZSB3aWR0 aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPnRyaWxsQGlldGYub3JnPC9mb250Pg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFs aWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2 Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5bdHJpbGxdIFtyYnJpZGdlXSBk cmFmdC1odS10cmlsbC1yYnJpZGdlLWVzYWRpLTA0PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFi bGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8 YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5IaSBBdXRob3JzLDxicj4NCjxicj4NCkkg aGF2ZSByZWFkIHRoZSBkcmFmdC1odS10cmlsbC1yYnJpZGdlLWVzYWRpLTA0IGFuZCBzdXBwb3J0 IGl0Ljxicj4NCjxicj4NCkkgaGF2ZSBvbmUgcXVlc3Rpb24gcmVnYXJkaW5nIHRoZSBwcm9ibGVt IHN0YXRlZCBpbiB0aGUgZHJhZnQ8YnI+DQo8YnI+DQogJnF1b3Q7IDIuIEZhc3QgdXBkYXRlIGFk dmFudGFnZXM6IEVTQURJIHByb3RvY29sIHByb3ZpZGVzIGEgZmFzdCB1cGRhdGUNCm9mPGJyPg0K ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZW5kIG5vZGVzIE1BQyAoTWVkaWEgQWNjZXNzIENvbnRyb2wp IGFkZHJlc3Nlcy4gJm5ic3A7SWYNCmFuIGVuZCBzdGF0aW9uPGJyPg0KICZuYnNwOyAmbmJzcDsg Jm5ic3A7aXMgdW5wbHVnZ2VkIGZyb20gb25lIFJCcmlkZ2UgYW5kIHBsdWdnZWQgaW50byBhbm90 aGVyLA0KZnJhbWVzPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7YWRkcmVzc2VkIHRvIHRoYXQg b2xkZXIgUkJyaWRnZSBjYW4gYmUgYmxhY2sgaG9sZWQuDQombmJzcDtUaGV5IGNhbiBiZTxicj4N CiAmbmJzcDsgJm5ic3A7ICZuYnNwO3NlbnQganVzdCB0byB0aGUgb2xkZXIgUkJyaWRnZSB0aGF0 IHRoZSBlbmQgc3RhdGlvbg0Kd2FzIGNvbm5lY3RlZDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNw O3RvIHVudGlsIGNhY2hlZCBhZGRyZXNzIGluZm9ybWF0aW9uIGF0IHNvbWUgcmVtb3RlDQpSQnJp ZGdlIHRpbWVzPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7b3V0LCBwb3NzaWJseSBmb3IgdGVu cyBvZiBzZWNvbmRzIFtSRkM2MzI1XS4mcXVvdDs8YnI+DQo8YnI+DQpJbiB0aGlzIHNjZW5hcmlv IHdoZW4gYW4gZW5kLXN0YXRpb24gbW92ZXMgVE8gYSBsaW5rIHdoZXJlIGFuPGJyPg0KUkJyaWRn ZShSQngpIHdpdGggRVNBREkgc3VwcG9ydCBpcyBzZXJ2aW5nIGFzIEFGIGZvciB0aGUgdmxhbiBv biB3aGljaDxicj4NCnRoZSBlbmQtc3RhdGlvbiBpcyBjb25uZWN0ZWQsIHRoaXMgUkJyaWRnZSBz ZW5kcyB0aGUgZW5kLXN0YXRpb24gTUFDczxicj4NCnRocm91Z2ggRVNBREkgcGR1IHRvIG90aGVy IEVTQURJIFJCcmlkZ2VzIHdpdGggYSBoaWdoZXIgY29uZmlkZW5jZSBhbmQ8YnI+DQp0aGUgb2xk IHJvdXRlcyBpbiBvdGhlciBFU0FESSBSQnJpZGdlcyBhcmUgb3Zlci13cml0dGVuLk5ldyByb3V0 ZXMoTUFDPGJyPg0KJnF1b3Q7QSZxdW90OyBpcyByZWFjaGFibGUgdmlhIGVncmVzcyBSQnJpZGdl IFJCeCkgZXhpc3QgYW5kIGZyYW1lcyBkZXN0aW5lZA0KdG88YnI+DQpNQUMgJnF1b3Q7QSZxdW90 OyBhcmUgbm90IGJsYWNrIGhvbGVkLjxicj4NCjxicj4NCkJ1dCB3aGF0IGlmIHRoaXMgZW5kLXN0 YXRpb24gbW92ZXMgRlJPTSBhIGxpbmsgd2hpY2ggaGFzIFJCcmlkZ2UoUkIxKTxicj4NCndpdGgg RVNBREkgc3VwcG9ydCBUTyBhIGxpbmsgd2hlcmUgUkJyaWRnZShSQjIpIGRvbm90IGhhdmUgRVNB REk8YnI+DQpzdXBwb3J0LiBJcyB0aGVyZSBhbnkgd2F5IFJCMSBjYW4gbm90aWZ5IG90aGVyIEVT QURJIGltcGxlbWVudGVkPGJyPg0KUkJyaWRnZXMgaW4gdGhlIGNhbXB1cyB0byBmbHVzaCB0aGUg b2xkIHJvdXRlKE1BQyAmcXVvdDtBJnF1b3Q7IGlzIHJlYWNoYWJsZQ0KdmlhPGJyPg0KZWdyZXNz IFJCMSkgc28gdGhhdCBmcmFtZXMgZm9yIE1BQyAmcXVvdDtBJnF1b3Q7IGFyZSBub3Qgc2VuZCBk aXJlY3RseQ0KdG8gUkIxPGJyPg0KYW5kIGFyZSByYXRoZXIgdHJlYXRlZCBhcyB1bmtub3duIHVu aWNhc3QgZnJhbWUgYW5kIHNlbmQgb24gYSBEVHJlZT88YnI+DQpDb3VsZCBSQjEgc2VuZCB0byBF U0FESSBJbXBsZW1lbnRlZCBSQnJpZGdlcyB0aGF0IE1BQyAmcXVvdDtBJnF1b3Q7IGlzDQpubyBs b25nZXI8YnI+DQpyZWFjaGFibGUgdmlhIGl0c2VsZiBieSBzZW5kaW5nIGNvbmZpZGVuY2UgYXMg MCBmb3IgdGhhdCBNQUMgaW4gaXRzPGJyPg0KRVNBREkgcGR1cz88YnI+DQo8YnI+DQpQbGVhc2Ug Y29ycmVjdCBtZSBpZiBteSB1bmRlcnN0YW5kaW5nIGlzIHdyb25nLjxicj4NCjxicj4NCkFsc28g Y291bGQgd2UgcmVjb21tZW5kIEVTQURJIGltcGxlbWVudGVkIFJCcmlkZ2VzIHRvIGJlY29tZSBE UkIgYW5kPGJyPg0Kc2VydmUgbW9yZSBBRiBmb3IgdmxhbnMuPGJyPg0KPGJyPg0KRWRpdG9yaWFs IGNvbW1lbnRzIGFuZCB0eXBvczo8YnI+DQo8YnI+DQpJbiBBYnN0cmFjdDxicj4NCkVTQURJIChF bmQgU3lzdGVtIEFkZHJlc3MgRGlzdHJpYnV0aW9uIEluZm9ybWF0aW9uKSBzaG91bGQgYmUgcmVw bGFjZWQNCmJ5PGJyPg0KRVNBREkgKEVuZCBTdGF0aW9uIEFkZHJlc3MgRGlzdHJpYnV0aW9uIElu Zm9ybWF0aW9uKSBhcyBwZXIgUkZDNjMyNTxicj4NCjxicj4NCkluIHNlY3Rpb24gMy4gRVNBREkg RFJCIFN0YXRlPGJyPg0KOHRoIGxpbmU6ICZxdW90O2ZvciB3aGljaCBSQjEgaXMgaG9sZGluZyBh biBFU0FESS1MU1AgemVybyB3aXRoIGFuIEVTQURJPGJyPg0KUGFyYXJtZXRlcnMmcXVvdDsgLCB0 eXBvIGZvciAmcXVvdDtQYXJhbWV0ZXJzJnF1b3Q7PGJyPg0KPGJyPg0KPGJyPg0KSW4gc2VjdGlv biA0LiBFU0FESSBQRFUgcHJvY2Vzc2luZzxicj4NCjR0aCBsaW5lOiAmbmJzcDsgJm5ic3A7ICZx dW90O2FyZSBvbmx5IEVBU0RJLUxTUCwgRUFTREktQ1NOUCBhbmQgRUFTREktUFNOUA0KUERVcyB1 c2VkPGJyPg0KaW4gRVNBREkuJnF1b3Q7c2hvdWxkIGJlIGNoYW5nZWQgdG88YnI+DQogJm5ic3A7 ICZxdW90O2FyZSBvbmx5IEVTQURJLUxTUCwgRVNBREktQ1NOUCBhbmQgRVNBREktUFNOUCBQRFVz IHVzZWQgaW4NCkVTQURJLiZxdW90Ozxicj4NCjxicj4NCkluIHNlY3Rpb24gNC4xIFNlbmRpbmcg b2YgRVNBU0kgUERVczxicj4NCjxicj4NCkNoYW5nZSB0aGUgdHlwbyBpbiB0aGUgaGVhZGVyIGl0 c2VsZi48YnI+DQo8YnI+DQo0dGggbGluZTogJm5ic3A7ICZuYnNwOyZxdW90OzYoSW5udGVyLk1h Y1NBKSZxdW90OyB0byAnNihJbm5lci5NYWNTQSkmcXVvdDs8YnI+DQo8YnI+DQo1dGggbGluZTog Jm5ic3A7ICZuYnNwOyAmcXVvdDtzdGFydGluZyB3aXRoIHRoZSBJbnRyYWRvbWFpbiBSb3V0ZWlu ZyBQcm90b2NvbDxicj4NCkRpc2NyaW1pbmF0b3IsJnF1b3Q7IFR5cG8gJnF1b3Q7Um91dGVpbmcm cXVvdDsgdG8gJnF1b3Q7Um91dGluZyZxdW90Ozxicj4NCjxicj4NCjJuZCBQYXJhLCAxc3QgbGlu ZTogJnF1b3Q7T25jZSBhbiBFU0FESSBpbnN0YW5jZSBpcyBvcGVyYXRpb25hbGx5IHVwLCBpdDxi cj4NCm11bHRpY2FzdHMgaXQgc2VsZi08YnI+DQogJm5ic3A7IG9yaWdpbmF0ZWQgTFNQIG51bWJl ciB6ZXJvIG9uIHRoZSB2aXJ0dWFsIGxpbmsgdG8gYW5ub3VuY2UgaXRzDQpFU0FESTxicj4NCiAm bmJzcDsgcGFyYW1ldGVycy4mcXVvdDsgJm5ic3A7IG1heSBiZSBjaGFuZ2VkIHRvPGJyPg0KJnF1 b3Q7T25jZSBhbiBFU0FESSBpbnN0YW5jZSBpcyBvcGVyYXRpb25hbGx5IHVwLCBpdCBtdWx0aWNh c3RzL3NlbmRzIGl0cw0Kc2VsZi08YnI+DQogJm5ic3A7IG9yaWdpbmF0ZWQgTFNQIG51bWJlciB6 ZXJvIG9uIHRoZSB2aXJ0dWFsIGxpbmsgdG8gYW5ub3VuY2UgaXRzDQpFU0FESTxicj4NCiAmbmJz cDsgcGFyYW1ldGVycy4mcXVvdDs8YnI+DQo8YnI+DQo1dGggUGFyYSwgMm5kIGxpbmU6IFR5cG8g JnF1b3Q7RUFTREkmcXVvdDs8YnI+DQo8YnI+DQpJbiBzZWN0aW9uIDUuIEVTQURJLUxTUCBDb250 ZW50czxicj4NCjd0aCBsaW5lIHR5cG8gJnF1b3Q7RUFTREFJLUxTUHM8YnI+DQo8YnI+DQpJbiBz ZWN0aW9uIDUuMSBFU0FESSBQYXJhbWV0ZXIgRGF0YTxicj4NCjR0aCBsaW5lIHR5cG8gJnF1b3Q7 b2NjdXJybmNlJnF1b3Q7PGJyPg0KPGJyPg0KVGhhbmsgeW91LDxicj4NClJlZ2FyZHMsPGJyPg0K U29tbmF0aDxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KdHJpbGwgbWFpbGluZyBsaXN0PGJyPg0KdHJpbGxAaWV0Zi5vcmc8YnI+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsPGJyPg0KPGJyPg0KPC90dD48 L2ZvbnQ+DQo8YnI+DQo= --=_alternative 001303A0482579E8_=-- From mohsin.sardar@seecs.edu.pk Sun Apr 22 11:49:39 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0457321F8648 for ; Sun, 22 Apr 2012 11:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.532 X-Spam-Level: X-Spam-Status: No, score=-3.532 tagged_above=-999 required=5 tests=[AWL=-2.045, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 zZBNVtVTYiQ5 for ; Sun, 22 Apr 2012 11:49:38 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5830021F8642 for ; Sun, 22 Apr 2012 11:49:38 -0700 (PDT) Received: by iazz13 with SMTP id z13so19099179iaz.31 for ; Sun, 22 Apr 2012 11:49:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-gm-message-state; bh=+/Rz0d3HGWxi49/EjQlBLMbWxViTYH9NzK4ZDWZuuCY=; b=jxO9BOAadPE/AcvpceAvLYwqD+csAP8Xz70Gs6KKtF3ouR7W8CdhT3HTUL6h791pK3 LEP5ROTeU2HgbIEABuj0TWcwagUrH3S9XaYdHow4W4Iva34VLZEypvhicJUiXMxzt2hu K1fPo80/KCtJWe3uhUkmQwpj7ReLkQmb7kDf6SgSvsxFcLaziDaiWRwRpJtWBqiLCorD 8jbVOIsyzegI7U9t4I9eOnHxc7jpQmMSW6Cc0N4VuFm71KYZZLVWVnP5QG5YJ8Z+Q1JC u4e2W2h/7iuDtvm4fk/r5BPTgXQJR7F+D0Y9+ic+NTn7fpNVVI3XdR0J9oH/iQhuAMcO wLKA== Received: by 10.42.157.65 with SMTP id c1mr9817255icx.6.1335120577831; Sun, 22 Apr 2012 11:49:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.102.195 with HTTP; Sun, 22 Apr 2012 11:49:17 -0700 (PDT) From: Muhammad Mohsin Sardar Date: Sun, 22 Apr 2012 23:49:17 +0500 Message-ID: To: rbridge@postel.org, trill@ietf.org Content-Type: multipart/alternative; boundary=90e6ba6e8d3ac621f904be48fbb6 X-Gm-Message-State: ALoCoQk2Dixge0aINRhjfZneXR3BJGx9c/b2WU0mT5tYObr73nsEQ8CpeHylvRLVge2D11J10+9i Subject: [trill] Tree calculation X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2012 18:49:39 -0000 --90e6ba6e8d3ac621f904be48fbb6 Content-Type: text/plain; charset=ISO-8859-1 Hi, It is given in section 4.5 of RFC 6325: "it is important for all RBridges to know: o how many trees to compute o which trees to compute o what the tree number for each tree is o which trees each ingress RBridge might choose (for building Reverse Path Forwarding Check filters)" Can anyone explain, how an RBridge calculate this information? Thank you! -- Best Regards, Muhammad Mohsin Sardar --90e6ba6e8d3ac621f904be48fbb6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

It is given in section 4.5 of RFC 6325:

"it is important for = all RBridges to know:
   o  how many trees to compute



   o  which trees to compute
   o  what the tree number for each tree is=

   o  which trees each ingress RBridge might choose (for building
  =
    Reverse Path Forwarding Check filters)"




Can anyone explain, how an RBridge calculate this infor=
mation?
Thank you!

--
Best Regards,
Muhammad Mohsin Sardar
--90e6ba6e8d3ac621f904be48fbb6-- From mohsin.sardar@seecs.edu.pk Sun Apr 22 11:49:56 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9E921F8648 for ; Sun, 22 Apr 2012 11:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.532 X-Spam-Level: X-Spam-Status: No, score=-3.532 tagged_above=-999 required=5 tests=[AWL=-2.045, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 G9OItDILyeOO for ; Sun, 22 Apr 2012 11:49:56 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3B521F8642 for ; Sun, 22 Apr 2012 11:49:56 -0700 (PDT) Received: from mail-iy0-f180.google.com (mail-iy0-f180.google.com [209.85.210.180]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q3MIncgS002637 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 22 Apr 2012 11:49:48 -0700 (PDT) Received: by iage36 with SMTP id e36so25547893iag.39 for ; Sun, 22 Apr 2012 11:49:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-gm-message-state; bh=+/Rz0d3HGWxi49/EjQlBLMbWxViTYH9NzK4ZDWZuuCY=; b=Mx3WCRSRJ2YavaJSkv3tpdLyTST//dtJNnoClm+nFUbWGtHcUPtM0YajBkM7GpCmku pz8vmxYknXyfyHp+EPBJzQKvewpK7ZFKF4Dy4U24ThFNUavDYsVMgOfw8gOGziP0x1e1 v9mn1ZgGjcbpBW9kcAlSRiVKGjfr2amhH26CeGzYXYWpfT/yOnw0BCTggWxyExqlvL6p LhHTcGyerb/xUgHwE4tv+uEexnF8RKrf5AD8SmKEcxbGCkiNe7XnJcIoejj+ZkOnW2jI S/Ii3llTfx36Xo/yzzOpAx28xTLJiXMqBsvhdnWRSO1JllZSiQFSCH47HKGwkUbWjXuQ LnVw== Received: by 10.42.157.65 with SMTP id c1mr9817255icx.6.1335120577831; Sun, 22 Apr 2012 11:49:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.102.195 with HTTP; Sun, 22 Apr 2012 11:49:17 -0700 (PDT) From: Muhammad Mohsin Sardar Date: Sun, 22 Apr 2012 23:49:17 +0500 Message-ID: To: rbridge@postel.org, trill@ietf.org Content-Type: multipart/alternative; boundary=90e6ba6e8d3ac621f904be48fbb6 X-Gm-Message-State: ALoCoQneFFVm+i4qCw8sDML8I3Mspyy6NKDMZ7PDjIjzhlocxRjy2SxaxjCGci70N2hTFVkBHasP X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: mohsin.sardar@seecs.edu.pk Subject: [trill] Tree calculation X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2012 18:49:56 -0000 --90e6ba6e8d3ac621f904be48fbb6 Content-Type: text/plain; charset=ISO-8859-1 Hi, It is given in section 4.5 of RFC 6325: "it is important for all RBridges to know: o how many trees to compute o which trees to compute o what the tree number for each tree is o which trees each ingress RBridge might choose (for building Reverse Path Forwarding Check filters)" Can anyone explain, how an RBridge calculate this information? Thank you! -- Best Regards, Muhammad Mohsin Sardar --90e6ba6e8d3ac621f904be48fbb6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

It is given in section 4.5 of RFC 6325:

"it is important for = all RBridges to know:
   o  how many trees to compute



   o  which trees to compute
   o  what the tree number for each tree is=

   o  which trees each ingress RBridge might choose (for building
  =
    Reverse Path Forwarding Check filters)"




Can anyone explain, how an RBridge calculate this infor=
mation?
Thank you!

--
Best Regards,
Muhammad Mohsin Sardar
--90e6ba6e8d3ac621f904be48fbb6-- From huutho411@gmail.com Sun Apr 22 21:44:08 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A71A21E801F for ; Sun, 22 Apr 2012 21:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 PGg8S3IOeka6 for ; Sun, 22 Apr 2012 21:44:06 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 22BDF21E8013 for ; Sun, 22 Apr 2012 21:43:57 -0700 (PDT) Received: by qaea16 with SMTP id a16so1277614qae.10 for ; Sun, 22 Apr 2012 21:43:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=2JYmt7RYJYFT5sf9I2CuA3NneY9jvoDEmamj3NwjmSs=; b=hLdy1gHagwcH4m2FZ+Qm8Q4ZAjH9bbLzfauAmpayAEr5Cm+wo6795VwFzBnyZ1wY1b sdd04dkKW4JZXoqPbS1CF4dwMHGAOKnaIvrZYBhmWsxH6WDADOoqnKyt+Fb+Tt5KOEqu ST71PwHtoAyrXNsvAOjRxEuGCckWB4BGPath8D5pDLll4FGtsLnaGPwFB/p6rRlYvaW4 0r3FT/11dzOnyPSiXVjv4Vjszdca47gfqdjx4h39mGg6BFzqBYpyN+TtZdYUKSKnG0rz f1aXUafWsGTFHC9WyMWl5vNEIeY/qIlKl0Ds6UledYN6MYfHbw34JAH8ZpPqUVQ8W1NU /ZVg== MIME-Version: 1.0 Received: by 10.229.201.105 with SMTP id ez41mr3894362qcb.39.1335156226796; Sun, 22 Apr 2012 21:43:46 -0700 (PDT) Received: by 10.229.99.200 with HTTP; Sun, 22 Apr 2012 21:43:46 -0700 (PDT) Date: Mon, 23 Apr 2012 11:43:46 +0700 Message-ID: From: Nguyen Huu Tho To: trill@ietf.org Content-Type: multipart/alternative; boundary=00504502961e9e2ef304be5148e5 Subject: [trill] Some questions about ESADI X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 04:44:09 -0000 --00504502961e9e2ef304be5148e5 Content-Type: text/plain; charset=UTF-8 Dear all, I have 2 questions relating to ESADI - Question 1: Influence of ESADI to bandwidth in a TRILL campus. If a TRILL campus does not use ESADI to advertise their end stations, how much percent of bandwidth will br decreased because of flooding packets. I know that it is depend on the topology but i just want to know an average result. - Question 2: All TRILL vendors can support ESADI or not Have any special requirement of TRILL to RB can run ESADI protocol ? If you have any information about this subject, please help me! Thank for your reading! Best Regard, -- +-- | Nguyen Huu Tho. Mail: huutho411@gmail.com | --+ --00504502961e9e2ef304be5148e5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear all,
I have 2 questions relating to ESADI=
  • Question 1: Influence o= f ESADI =C2=A0to bandwidth=C2=A0in a TRILL campus.
If a TRILL campus does not use ESADI to advertise their end stations,
=C2=A0 =C2=A0=C2=A0how much percent of bandwidth will br decreased because = of flooding packets.
I know that it is depend on the topology but i just want to know an average= result.
  • Question 2: All TRILL vendors can support ESADI or not
=
Have any special requirement of TRILL to RB can run ESADI protocol ?

If= you have any information about this subject, please help me!

Thank for your reading!
Bes= t Regard,

--
+--
| Nguyen Huu Tho.
=C2=A0=C2= =A0 Mail: huutho411@gmail.com=C2= =A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 --+

--00504502961e9e2ef304be5148e5-- From hu.fangwei@zte.com.cn Sun Apr 22 23:23:18 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D215721F854C; Sun, 22 Apr 2012 23:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.29 X-Spam-Level: X-Spam-Status: No, score=-96.29 tagged_above=-999 required=5 tests=[AWL=-0.145, BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] 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 N6sQ7d7dQGX1; Sun, 22 Apr 2012 23:23:17 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8AA21F8495; Sun, 22 Apr 2012 23:23:16 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 286201455586978; Mon, 23 Apr 2012 13:42:52 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 31179.1665794388; Mon, 23 Apr 2012 14:23:08 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q3N6N5n4011660; Mon, 23 Apr 2012 14:23:05 +0800 (GMT-8) (envelope-from hu.fangwei@zte.com.cn) In-Reply-To: To: Nguyen Huu Tho MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.4 June 01, 2004 Message-ID: From: hu.fangwei@zte.com.cn Date: Mon, 23 Apr 2012 14:23:06 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-23 14:23:06, Serialize complete at 2012-04-23 14:23:06 Content-Type: multipart/alternative; boundary="=_alternative 00231262482579E9_=" X-MAIL: mse01.zte.com.cn q3N6N5n4011660 Cc: trill-bounces@ietf.org, trill@ietf.org Subject: Re: [trill] Some questions about ESADI X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 06:23:19 -0000 This is a multipart message in MIME format. --=_alternative 00231262482579E9_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksTmd1eWVuIEh1dSBUaG8NCg0KPkRlYXIgYWxsLA0KPkkgaGF2ZSAyIHF1ZXN0aW9ucyByZWxh dGluZyB0byBFU0FESSANCiAgICAgPlF1ZXN0aW9uIDE6IEluZmx1ZW5jZSBvZiBFU0FESSAgdG8g YmFuZHdpZHRoIGluIGEgVFJJTEwgY2FtcHVzLg0KICAgICA+IElmIGEgVFJJTEwgY2FtcHVzIGRv ZXMgbm90IHVzZSBFU0FESSB0byBhZHZlcnRpc2UgdGhlaXIgZW5kIA0Kc3RhdGlvbnMsDQogICAg ID4gICAgIGhvdyBtdWNoIHBlcmNlbnQgb2YgYmFuZHdpZHRoIHdpbGwgYnIgZGVjcmVhc2VkIGJl Y2F1c2Ugb2YgDQpmbG9vZGluZyBwYWNrZXRzLg0KICAgICA+IEkga25vdyB0aGF0IGl0IGlzIGRl cGVuZCBvbiB0aGUgdG9wb2xvZ3kgYnV0IGkganVzdCB3YW50IHRvIGtub3cgYW4gDQphdmVyYWdl IHJlc3VsdC4NCg0KW2hmd10gRVNBREkgaXMgYW4gb3B0aW9uYWwgZW5kIHN0YXRpb24gYWRkcmVz cyBsZWFybmluZyBtZXRob2QuIEJlc2lkZXMgDQpFU0FESSwgdGhlcmUgYXJlIGZpdmUgaW5kZXBl bmRlbnQgd2F5cyBmb3IgYW4gUkJyaWRnZSB0byBsZWFybiB0aGUgZW5kIA0Kc3RhdGlvbiBhZGRy ZXNzKHNlY3Rpb24gNC44LjEgb2YgUkZDIDYzMjUpLiBJZiBhIFRSSUxMIGNhbXB1cyBkb2VzIG5v dCB1c2UgDQpFU0FESSwgdGhlIFJCcmlkZ2VzIGNhbiBsZWFybiB0aGUgZW5kIHN0YXRpb24gYWRk cmVzcyBieSBvdGhlciB3YXlzLCBzdWNoIA0KYXMgZGF0YSBwbGFuZSBsZWFyaW5nLiBUaGUgRVNB REkgcHJvdG9jb2wncyBwb3RlbnRpYWwgYWR2YW50YWdlIG92ZXIgZGF0YSANCnBsYW5lIGxlYXJu aW5nIGlzIGluIHNlY3VyaXR5IGFuZCBmYXN0IHVwZGF0ZSwgbm90IGluIHJlZHVjaW5nIHRoZSAN CmJhbmR3aWR0aC4gRVNBREkgY2FuIHVuaWNhc3QgdGhlIEVTQURJIFBEVSBpbiBzdGVhZCBvZiBt dWx0aWNhc3RpbmcgaW4gDQpzb21lIHNpdHVhdGlvbiwgd2hpY2ggY2FuIG9wdGltaXplIHRoZSBF U0FESSBQRFUgc2VuZGluZyBhbmQgYXZvaWRpbmcgDQptdWx0aWNhc3Qgc3Rvcm0uIEkgYW0gc29y cnkgZm9yIHRoYXQgSSBjYW4gbm90IGdpdmUgdGhlIGFjY3VyYXRlIHJlc3VsdCBvZiANCmJhbmR3 aWR0aCBkZWNyZWFzZWQsIGJlY2FzdWUgdGhhdCBpcyBub3QgdGhlIG1ham9yIGdvYWwgZm9yIEVT QURJIA0KcHJvdG9jb2wuDQoNCiAgICA+IFF1ZXN0aW9uIDI6IEFsbCBUUklMTCB2ZW5kb3JzIGNh biBzdXBwb3J0IEVTQURJIG9yIG5vdA0KICAgICAgID4gIEhhdmUgYW55IHNwZWNpYWwgcmVxdWly ZW1lbnQgb2YgVFJJTEwgdG8gUkIgY2FuIHJ1biBFU0FESSANCnByb3RvY29sID8NCltoZnddICBF U0FESSBpcyBhIG9wdGlvbmFsIHdheSBmb3IgUkJyaWRnZXMgdG8gbGVhcm5pbmcgZW5kIHN0YXRp b24gDQphZGRyZXNzLiAgVGhlIFJCcmlkZ2UgaW1wbGVtZW50IEVTQURJIGNhbiBhY2hpdmUgdGhl IHBvdGVudGlhbCBhZHZhbnRhZ2UgDQppbiBzZWN1cml0eSBhbmQgZmFzdCB1cGRhdGUuIA0KSSB0 aGluayBpdCBpcyBubyBzcGVjaWFsIHJlcXVpcmVtZW50IGZvciBSQiB0byBydW4gRVNBREkgcHJv dG9jb2wuICBFU0FESSANCmlzIGEgZmVhdHVyZSBvZiBUUklMTC4NCg0KPklmIHlvdSBoYXZlIGFu eSBpbmZvcm1hdGlvbiBhYm91dCB0aGlzIHN1YmplY3QsIHBsZWFzZSBoZWxwIG1lIQ0KDQpSZWdh cmRzDQoNCg0KDQoNCk5ndXllbiBIdXUgVGhvIDxodXV0aG80MTFAZ21haWwuY29tPiANCreivP7I yzogIHRyaWxsLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMTItMDQtMjMgMTI6NDMNCg0KytW8/sjLDQp0 cmlsbEBpZXRmLm9yZw0Ks63LzQ0KDQrW98ziDQpbdHJpbGxdIFNvbWUgcXVlc3Rpb25zIGFib3V0 IEVTQURJDQoNCg0KDQoNCg0KDQpEZWFyIGFsbCwNCkkgaGF2ZSAyIHF1ZXN0aW9ucyByZWxhdGlu ZyB0byBFU0FESQ0KUXVlc3Rpb24gMTogSW5mbHVlbmNlIG9mIEVTQURJICB0byBiYW5kd2lkdGgg aW4gYSBUUklMTCBjYW1wdXMuDQpJZiBhIFRSSUxMIGNhbXB1cyBkb2VzIG5vdCB1c2UgRVNBREkg dG8gYWR2ZXJ0aXNlIHRoZWlyIGVuZCBzdGF0aW9ucywNCiAgICBob3cgbXVjaCBwZXJjZW50IG9m IGJhbmR3aWR0aCB3aWxsIGJyIGRlY3JlYXNlZCBiZWNhdXNlIG9mIGZsb29kaW5nIA0KcGFja2V0 cy4NCkkga25vdyB0aGF0IGl0IGlzIGRlcGVuZCBvbiB0aGUgdG9wb2xvZ3kgYnV0IGkganVzdCB3 YW50IHRvIGtub3cgYW4gDQphdmVyYWdlIHJlc3VsdC4NClF1ZXN0aW9uIDI6IEFsbCBUUklMTCB2 ZW5kb3JzIGNhbiBzdXBwb3J0IEVTQURJIG9yIG5vdA0KSGF2ZSBhbnkgc3BlY2lhbCByZXF1aXJl bWVudCBvZiBUUklMTCB0byBSQiBjYW4gcnVuIEVTQURJIHByb3RvY29sID8NCg0KSWYgeW91IGhh dmUgYW55IGluZm9ybWF0aW9uIGFib3V0IHRoaXMgc3ViamVjdCwgcGxlYXNlIGhlbHAgbWUhDQoN ClRoYW5rIGZvciB5b3VyIHJlYWRpbmchDQpCZXN0IFJlZ2FyZCwNCg0KLS0gDQorLS0NCnwgTmd1 eWVuIEh1dSBUaG8uDQogICBNYWlsOiBodXV0aG80MTFAZ21haWwuY29tICB8DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tKw0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnRyaWxsIG1haWxpbmcgbGlzdA0KdHJpbGxA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJpbGwNCg0K DQo= --=_alternative 00231262482579E9_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD48Zm9udCBzaXpl PTM+Tmd1eWVuIEh1dSBUaG88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPiZndDtEZWFy IGFsbCw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZndDtJIGhhdmUgMiBxdWVzdGlvbnMgcmVs YXRpbmcgdG8gRVNBREkgPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4mbmJzcDsgJm5ic3A7ICZu YnNwOyZndDtRdWVzdGlvbiAxOiBJbmZsdWVuY2Ugb2YgRVNBREkNCiZuYnNwO3RvIGJhbmR3aWR0 aCZuYnNwO2luIGEgVFJJTEwgY2FtcHVzLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsmZ3Q7IElmIGEgVFJJTEwgY2FtcHVzIGRvZXMgbm90IHVzZQ0KRVNBREkg dG8gYWR2ZXJ0aXNlIHRoZWlyIGVuZCBzdGF0aW9ucyw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0z PiZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyAmbmJzcDsgJm5ic3A7Jm5ic3A7aG93IG11Y2ggcGVy Y2VudA0Kb2YgYmFuZHdpZHRoIHdpbGwgYnIgZGVjcmVhc2VkIGJlY2F1c2Ugb2YgZmxvb2Rpbmcg cGFja2V0cy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0 OyBJIGtub3cgdGhhdCBpdCBpcyBkZXBlbmQgb24gdGhlDQp0b3BvbG9neSBidXQgaSBqdXN0IHdh bnQgdG8ga25vdyBhbiBhdmVyYWdlIHJlc3VsdC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0zPltoZnddIEVTQURJIGlzIGFuIG9wdGlvbmFsIGVuZCBzdGF0aW9uIGFkZHJlc3MgbGVhcm5p bmcNCm1ldGhvZC4gQmVzaWRlcyBFU0FESSwgdGhlcmUgYXJlIGZpdmUgaW5kZXBlbmRlbnQgd2F5 cyBmb3IgYW4gUkJyaWRnZSB0bw0KbGVhcm4gdGhlIGVuZCBzdGF0aW9uIGFkZHJlc3Moc2VjdGlv biA0LjguMSBvZiBSRkMgNjMyNSkuIElmIGEgVFJJTEwgY2FtcHVzDQpkb2VzIG5vdCB1c2UgRVNB REksIHRoZSBSQnJpZGdlcyBjYW4gbGVhcm4gdGhlIGVuZCBzdGF0aW9uIGFkZHJlc3MgYnkgb3Ro ZXINCndheXMsIHN1Y2ggYXMgZGF0YSBwbGFuZSBsZWFyaW5nLiBUaGUgRVNBREkgcHJvdG9jb2wn cyBwb3RlbnRpYWwgYWR2YW50YWdlDQpvdmVyIGRhdGEgcGxhbmUgbGVhcm5pbmcgaXMgaW4gc2Vj dXJpdHkgYW5kIGZhc3QgdXBkYXRlLCBub3QgaW4gcmVkdWNpbmcNCnRoZSBiYW5kd2lkdGguIEVT QURJIGNhbiB1bmljYXN0IHRoZSBFU0FESSBQRFUgaW4gc3RlYWQgb2YgbXVsdGljYXN0aW5nDQpp biBzb21lIHNpdHVhdGlvbiwgd2hpY2ggY2FuIG9wdGltaXplIHRoZSBFU0FESSBQRFUgc2VuZGlu ZyBhbmQgYXZvaWRpbmcNCm11bHRpY2FzdCBzdG9ybS4gSSBhbSBzb3JyeSBmb3IgdGhhdCBJIGNh biBub3QgZ2l2ZSB0aGUgYWNjdXJhdGUgcmVzdWx0DQpvZiBiYW5kd2lkdGggZGVjcmVhc2VkLCBi ZWNhc3VlIHRoYXQgaXMgbm90IHRoZSBtYWpvciBnb2FsIGZvciBFU0FESSBwcm90b2NvbC48L2Zv bnQ+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTEwMCU+ PC90YWJsZT4NCjxicj48Zm9udCBzaXplPTM+Jm5ic3A7ICZuYnNwOyAmZ3Q7IFF1ZXN0aW9uIDI6 IEFsbCBUUklMTCB2ZW5kb3JzIGNhbiBzdXBwb3J0DQpFU0FESSBvciBub3Q8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0zIGNvbG9yPSMyMjIyMjIgZmFjZT0iQXJpYWwiPiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyZndDsNCiZuYnNwO0hhdmUgYW55IHNwZWNpYWwgcmVxdWlyZW1lbnQgb2YgVFJJ TEwgdG8gUkIgY2FuIHJ1biBFU0FESSBwcm90b2NvbA0KPzwvZm9udD4NCjxicj48Zm9udCBzaXpl PTMgY29sb3I9IzIyMjIyMiBmYWNlPSJBcmlhbCI+W2hmd10gJm5ic3A7RVNBREkgaXMgYSBvcHRp b25hbA0Kd2F5IGZvciBSQnJpZGdlcyB0byBsZWFybmluZyBlbmQgc3RhdGlvbiBhZGRyZXNzLiAm bmJzcDtUaGUgUkJyaWRnZSBpbXBsZW1lbnQNCkVTQURJIGNhbiBhY2hpdmUgdGhlIHBvdGVudGlh bCBhZHZhbnRhZ2UgaW4gc2VjdXJpdHkgYW5kIGZhc3QgdXBkYXRlLiA8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0zIGNvbG9yPSMyMjIyMjIgZmFjZT0iQXJpYWwiPkkgdGhpbmsgaXQgaXMgbm8gc3Bl Y2lhbCByZXF1aXJlbWVudA0KZm9yIFJCIHRvIHJ1biBFU0FESSBwcm90b2NvbC4gJm5ic3A7RVNB REkgaXMgYSBmZWF0dXJlIG9mIFRSSUxMLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+ Jmd0O0lmIHlvdSBoYXZlIGFueSBpbmZvcm1hdGlvbiBhYm91dCB0aGlzIHN1YmplY3QsIHBsZWFz ZQ0KaGVscCBtZSE8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPlJlZ2FyZHM8L2ZvbnQ+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjwvZm9udD4NCjxicj4NCjxicj4N Cjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzUl Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5OZ3V5ZW4gSHV1IFRobyAmbHQ7aHV1 dGhvNDExQGdtYWlsLmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7dHJpbGwtYm91bmNlc0BpZXRmLm9yZzwvZm9udD4N CjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEyLTA0LTIzIDEyOjQzPC9mb250 Pg0KPHRkIHdpZHRoPTY0JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8 dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+ yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPnRyaWxs QGlldGYub3JnPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0 Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPg0K PHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj5bdHJpbGxdIFNvbWUgcXVlc3Rpb25zIGFib3V0IEVTQURJPC9mb250PjwvdGFi bGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0K PGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPkRlYXIgYWxsLDwvZm9u dD4NCjxicj48Zm9udCBzaXplPTM+SSBoYXZlIDIgcXVlc3Rpb25zIHJlbGF0aW5nIHRvIEVTQURJ PC9mb250Pg0KPHVsPg0KPGxpPjxmb250IHNpemU9Mz5RdWVzdGlvbiAxOiBJbmZsdWVuY2Ugb2Yg RVNBREkgJm5ic3A7dG8gYmFuZHdpZHRoJm5ic3A7aW4NCmEgVFJJTEwgY2FtcHVzLjwvZm9udD48 L3VsPjxmb250IHNpemU9Mz5JZiBhIFRSSUxMIGNhbXB1cyBkb2VzIG5vdCB1c2UgRVNBREkNCnRv IGFkdmVydGlzZSB0aGVpciBlbmQgc3RhdGlvbnMsPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4m bmJzcDsgJm5ic3A7Jm5ic3A7aG93IG11Y2ggcGVyY2VudCBvZiBiYW5kd2lkdGggd2lsbA0KYnIg ZGVjcmVhc2VkIGJlY2F1c2Ugb2YgZmxvb2RpbmcgcGFja2V0cy48L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0zPkkga25vdyB0aGF0IGl0IGlzIGRlcGVuZCBvbiB0aGUgdG9wb2xvZ3kgYnV0IGkganVz dCB3YW50DQp0byBrbm93IGFuIGF2ZXJhZ2UgcmVzdWx0LjwvZm9udD4NCjx1bD4NCjxsaT48Zm9u dCBzaXplPTM+UXVlc3Rpb24gMjogQWxsIFRSSUxMIHZlbmRvcnMgY2FuIHN1cHBvcnQgRVNBREkg b3Igbm90PC9mb250PjwvdWw+PGZvbnQgc2l6ZT0zIGNvbG9yPSMyMjIyMjIgZmFjZT0iQXJpYWwi PkhhdmUNCmFueSBzcGVjaWFsIHJlcXVpcmVtZW50IG9mIFRSSUxMIHRvIFJCIGNhbiBydW4gRVNB REkgcHJvdG9jb2wgPzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+SWYgeW91IGhhdmUg YW55IGluZm9ybWF0aW9uIGFib3V0IHRoaXMgc3ViamVjdCwgcGxlYXNlDQpoZWxwIG1lITwvZm9u dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+VGhhbmsgZm9yIHlvdXIgcmVhZGluZyE8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0zPkJlc3QgUmVnYXJkLDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTM+LS0gPGJyPg0KKy0tPGJyPg0KfCBOZ3V5ZW4gSHV1IFRoby48YnI+DQombmJzcDsmbmJz cDsgTWFpbDogPC9mb250PjxhIGhyZWY9bWFpbHRvOmh1dXRobzQxMUBnbWFpbC5jb20+PGZvbnQg c2l6ZT0zIGNvbG9yPWJsdWU+PHU+aHV1dGhvNDExQGdtYWlsLmNvbTwvdT48L2ZvbnQ+PC9hPjxm b250IHNpemU9Mz4mbmJzcDsNCnw8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7DQotLSs8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yPjx0dD5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnRyaWxsIG1haWxpbmcgbGlz dDxicj4NCnRyaWxsQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby90cmlsbDxicj4NCjwvdHQ+PC9mb250Pg0KPGJyPg0K --=_alternative 00231262482579E9_=-- From somnath.chatterjee01@gmail.com Sun Apr 22 23:57:08 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5336821F85D0; Sun, 22 Apr 2012 23:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.874 X-Spam-Level: X-Spam-Status: No, score=-0.874 tagged_above=-999 required=5 tests=[AWL=-1.526, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_75=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] 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 1rXciMSqseKy; Sun, 22 Apr 2012 23:57:04 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4A73A21F8495; Sun, 22 Apr 2012 23:57:04 -0700 (PDT) Received: by yenm5 with SMTP id m5so6848210yen.31 for ; Sun, 22 Apr 2012 23:57:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=g16NnURELwYMZ77pDw1YghOP/COFJ8kNXgkdYjpjEpM=; b=MJy0kuJffTi5Ovp0SjYjVXRXiDcRLvE/uyPlGnn+6flilTcpxzmZytps8fx2wGeA40 oxhx0dbjfntkr6x5/jZ6Utox9uoD9DlmayBxmj/WDfxRP3tyDsjXV1GOiBt4eecSclhl 13KiDJUW34tnjHaYth/MSine+9zpALcIF7JAzryq/rm7WC36Yok7sAiAySUlBbOrbBFE AkBFCbPRL6GZbRfoXxisInmv4cTHsfBI+VGs2AwnliialY1Jjd3XRoQ0gsUuOEuCBfkr hlXCipVICdmVCJ6LnYIUQP05Tz7Q6MrBbFTmCpjBF9BTtWCcm4ms52f7OTORofWTiIkB THHw== MIME-Version: 1.0 Received: by 10.236.79.40 with SMTP id h28mr13743593yhe.50.1335164223819; Sun, 22 Apr 2012 23:57:03 -0700 (PDT) Received: by 10.146.255.30 with HTTP; Sun, 22 Apr 2012 23:57:03 -0700 (PDT) In-Reply-To: References: Date: Mon, 23 Apr 2012 12:27:03 +0530 Message-ID: From: somnath chatterjee To: hu.fangwei@zte.com.cn Content-Type: multipart/alternative; boundary=20cf300fab4b47104b04be532564 Cc: trill-bounces@ietf.org, trill@ietf.org Subject: Re: [trill] [rbridge] draft-hu-trill-rbridge-esadi-04 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 06:57:08 -0000 --20cf300fab4b47104b04be532564 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi Fangwei, Thank you for the explanation. So, RB1 doesnot include the end-stations MAC in its LSP. What if RB1 has opted not to send this end-station MAC in its ESADI-LSP earlier? The other ESADI RBridges has no way to learn that this MAC has to be flushed(which may be learned through other procedures except ESADI). It would be good if ESADI RBridges could explicitly tell other RBridges to forget a MAC. Regards, Somnath 2012/4/22 > > Thanks for the reviewing and comments. > > Pls see the following in line. > > >Hi Authors, > > >I have read the draft-hu-trill-rbridge-esadi-04 and support it. > > >I have one question regarding the problem stated in the draft > > > " 2. Fast update advantages: ESADI protocol provides a fast update of > end nodes MAC (Media Access Control) addresses. If an end station > is unplugged from one RBridge and plugged into another, frames > addressed to that older RBridge can be black holed. They can be > sent just to the older RBridge that the end station was connected > to until cached address information at some remote RBridge times > out, possibly for tens of seconds [RFC6325]." > > >In this scenario when an end-station moves TO a link where an > >RBridge(RBx) with ESADI support is serving as AF for the vlan on which > >the end-station is connected, this RBridge sends the end-station MACs > >through ESADI pdu to other ESADI RBridges with a higher confidence and > >the old routes in other ESADI RBridges are over-written.New routes(MAC > >"A" is reachable via egress RBridge RBx) exist and frames destined to > >MAC "A" are not black holed. > > >But what if this end-station moves FROM a link which has RBridge(RB1) > >with ESADI support TO a link where RBridge(RB2) donot have ESADI > >support. Is there any way RB1 can notify other ESADI implemented > >RBridges in the campus to flush the old route(MAC "A" is reachable via > >egress RB1) so that frames for MAC "A" are not send directly to RB1 > >and are rather treated as unknown unicast frame and send on a DTree? > >Could RB1 send to ESADI Implemented RBridges that MAC "A" is no longer > >reachable via itself by sending confidence as 0 for that MAC in its > >ESADI pdus? > > [hfw] If RB1 notify that the end-station moves from the link, RB1 will > update > > and flood the LSP originated with nulling out the end-station address. > When other ESADI > > RBridge receives the updated LSP, they will forget the MAC "A" from its > MAC table. > > In this way, ESADI protocol can fast update the MAC table of remote > RBridges when the end station attached > > is unpluged or a new end station is pluged. > > > >Please correct me if my understanding is wrong. > > >Also could we recommend ESADI implemented RBridges to become DRB and > >serve more AF for vlans. > > >Editorial comments and typos: > > >In Abstract > >ESADI (End System Address Distribution Information) should be replaced b= y > >ESADI (End Station Address Distribution Information) as per RFC6325 > > >In section 3. ESADI DRB State > >8th line: "for which RB1 is holding an ESADI-LSP zero with an ESADI > >Pararmeters" , typo for "Parameters" > > > >In section 4. ESADI PDU processing > >4th line: "are only EASDI-LSP, EASDI-CSNP and EASDI-PSNP PDUs used > >in ESADI."should be changed to > > "are only ESADI-LSP, ESADI-CSNP and ESADI-PSNP PDUs used in ESADI." > > >In section 4.1 Sending of ESASI PDUs > > >Change the typo in the header itself. > > >4th line: "6(Innter.MacSA)" to '6(Inner.MacSA)" > > >5th line: "starting with the Intradomain Routeing Protocol > >Discriminator," Typo "Routeing" to "Routing" > > >2nd Para, 1st line: "Once an ESADI instance is operationally up, it > >multicasts it self- > > originated LSP number zero on the virtual link to announce its ESADI > > parameters." may be changed to > >"Once an ESADI instance is operationally up, it multicasts/sends its sel= f- > > originated LSP number zero on the virtual link to announce its ESADI > > parameters." > > >5th Para, 2nd line: Typo "EASDI" > > >In section 5. ESADI-LSP Contents > >7th line typo "EASDAI-LSPs > > >In section 5.1 ESADI Parameter Data > >4th line typo "occurrnce" > > [hfw] Thanks for the correcting, we will correct it in the next version. > > > > *somnath chatterjee * > =B7=A2=BC=FE=C8=CB: trill-bounces@ietf.org > > 2012-04-21 01:17 > =CA=D5=BC=FE=C8=CB > trill@ietf.org > =B3=AD=CB=CD > =D6=F7=CC=E2 > [trill] [rbridge] draft-hu-trill-rbridge-esadi-04 > > > > > Hi Authors, > > I have read the draft-hu-trill-rbridge-esadi-04 and support it. > > I have one question regarding the problem stated in the draft > > " 2. Fast update advantages: ESADI protocol provides a fast update of > end nodes MAC (Media Access Control) addresses. If an end station > is unplugged from one RBridge and plugged into another, frames > addressed to that older RBridge can be black holed. They can be > sent just to the older RBridge that the end station was connected > to until cached address information at some remote RBridge times > out, possibly for tens of seconds [RFC6325]." > > In this scenario when an end-station moves TO a link where an > RBridge(RBx) with ESADI support is serving as AF for the vlan on which > the end-station is connected, this RBridge sends the end-station MACs > through ESADI pdu to other ESADI RBridges with a higher confidence and > the old routes in other ESADI RBridges are over-written.New routes(MAC > "A" is reachable via egress RBridge RBx) exist and frames destined to > MAC "A" are not black holed. > > But what if this end-station moves FROM a link which has RBridge(RB1) > with ESADI support TO a link where RBridge(RB2) donot have ESADI > support. Is there any way RB1 can notify other ESADI implemented > RBridges in the campus to flush the old route(MAC "A" is reachable via > egress RB1) so that frames for MAC "A" are not send directly to RB1 > and are rather treated as unknown unicast frame and send on a DTree? > Could RB1 send to ESADI Implemented RBridges that MAC "A" is no longer > reachable via itself by sending confidence as 0 for that MAC in its > ESADI pdus? > > Please correct me if my understanding is wrong. > > Also could we recommend ESADI implemented RBridges to become DRB and > serve more AF for vlans. > > Editorial comments and typos: > > In Abstract > ESADI (End System Address Distribution Information) should be replaced by > ESADI (End Station Address Distribution Information) as per RFC6325 > > In section 3. ESADI DRB State > 8th line: "for which RB1 is holding an ESADI-LSP zero with an ESADI > Pararmeters" , typo for "Parameters" > > > In section 4. ESADI PDU processing > 4th line: "are only EASDI-LSP, EASDI-CSNP and EASDI-PSNP PDUs used > in ESADI."should be changed to > "are only ESADI-LSP, ESADI-CSNP and ESADI-PSNP PDUs used in ESADI." > > In section 4.1 Sending of ESASI PDUs > > Change the typo in the header itself. > > 4th line: "6(Innter.MacSA)" to '6(Inner.MacSA)" > > 5th line: "starting with the Intradomain Routeing Protocol > Discriminator," Typo "Routeing" to "Routing" > > 2nd Para, 1st line: "Once an ESADI instance is operationally up, it > multicasts it self- > originated LSP number zero on the virtual link to announce its ESADI > parameters." may be changed to > "Once an ESADI instance is operationally up, it multicasts/sends its self= - > originated LSP number zero on the virtual link to announce its ESADI > parameters." > > 5th Para, 2nd line: Typo "EASDI" > > In section 5. ESADI-LSP Contents > 7th line typo "EASDAI-LSPs > > In section 5.1 ESADI Parameter Data > 4th line typo "occurrnce" > > Thank you, > Regards, > Somnath > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill > > > --20cf300fab4b47104b04be532564 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Hi Fangwei,

= Thank you for the explanation.

So, RB1 doesnot include the end-stations MAC in its LSP. What if RB1 has op= ted not to send this end-station MAC in its ESADI-LSP earlier? The other ES= ADI RBridges has no way to learn that this MAC has to be flushed(which may = be learned through other procedures except ESADI). It would be good if ESAD= I RBridges could explicitly tell other RBridges to forget a MAC.

Regards,
Somnath

2012/4/22 <hu.fangwei@zte.com.cn&g= t;

Thanks for the reviewing and comments.

Pls see the following in line.

>Hi Authors,

>I have read the draft-hu-trill-rbridge-esadi-04 and support it.

>I have one question regarding the problem stated in the draft

> " 2. Fast update advantages: ESADI protocol provides a fast updat= e of
     end nodes MAC (Media Access Control) addresses.  = If an end station
     is unplugged from one RBridge and plugged into another= , frames
     addressed to that older RBridge can be black holed.  They can be
     sent just to the older RBridge that the end station was connected
     to until cached address information at some remote RBridge times
     out, possibly for tens of seconds [RFC6325]."

>In this scenario when an end-station moves TO a link where an
>RBridge(RBx) with ESADI support is serving as AF for the vlan on which<= br> >the end-station is connected, this RBridge sends the end-station MACs >through ESADI pdu to other ESADI RBridges with a higher confidence and
>the old routes in other ESADI RBridges are over-written.New routes(MAC<= br> >"A" is reachable via egress RBridge RBx) exist and frames destined to
>MAC "A" are not black holed.

>But what if this end-station moves FROM a link which has RBridge(RB1) >with ESADI support TO a link where RBridge(RB2) donot have ESADI
>support. Is there any way RB1 can notify other ESADI implemented
>RBridges in the campus to flush the old route(MAC "A" is reachable via
>egress RB1) so that frames for MAC "A" are not send directly to RB1
>and are rather treated as unknown unicast frame and send on a DTree? >Could RB1 send to ESADI Implemented RBridges that MAC "A" is no longer
>reachable via itself by sending confidence as 0 for that MAC in its
>ESADI pdus?

[hfw] If RB1 notify that the end-station moves from the link, RB1 will update

 and flood the LSP originated with nulling out the end-station address. When other ESADI

 RBridge receives the updated LSP, they will forget the MAC "A" from its MAC table.

 In this way, ESADI protocol can fast update the MAC table of remote RBridges when the end station attached

 is unpluged or a new end station is pluged.=


>Please correct me if my understanding is wrong.

>Also could we recommend ESADI implemented RBridges to become DRB and >serve more AF for vlans.

>Editorial comments and typos:

>In Abstract
>ESADI (End System Address Distribution Information) should be replaced by
>ESADI (End Station Address Distribution Information) as per RFC6325

>In section 3. ESADI DRB State
>8th line: "for which RB1 is holding an ESADI-LSP zero with an ESADI
>Pararmeters" , typo for "Parameters"


>In section 4. ESADI PDU processing
>4th line:     "are only EASDI-LSP, EASDI-CSNP and EASDI-= PSNP PDUs used
>in ESADI."should be changed to
>   "are only ESADI-LSP, ESADI-CSNP and ESADI-PSNP PDUs used in ESADI."

>In section 4.1 Sending of ESASI PDUs

>Change the typo in the header itself.

>4th line:    "6(Innter.MacSA)" to '6(Inner.MacS= A)"

>5th line:     "starting with the Intradomain Routeing Protocol
>Discriminator," Typo "Routeing" to "Routing"
>2nd Para, 1st line: "Once an ESADI instance is operationally up, it
>multicasts it self-
>  originated LSP number zero on the virtual link to announce its ESADI
>  parameters."   may be changed to
>"Once an ESADI instance is operationally up, it multicasts/sends its self-
>   originated LSP number zero on the virtual link to announce its ESADI
>   parameters."

>5th Para, 2nd line: Typo "EASDI"

>In section 5. ESADI-LSP Contents
>7th line typo "EASDAI-LSPs

>In section 5.1 ESADI Parameter Data
>4th line typo "occurrnce"

[hfw] Thanks for the correcting, = we will correct it in the next version.


somnath chatterje= e <s= omnath.chatterjee01@gmail.com>
=B7=A2=BC=FE=C8=CB:  trill-bounces@ietf.org=

2012-04-21 01:17

=CA=D5=BC=FE=C8= =CB
trill@ietf.org
=B3=AD=CB=CD
=D6=F7=CC=E2
[trill] [rbridge] draft-hu-tr= ill-rbridge-esadi-04





Hi Authors,

I have read the draft-hu-trill-rbridge-esadi-04 and support it.

I have one question regarding the problem stated in the draft

" 2. Fast update advantages: ESADI protocol provides a fast update of
     end nodes MAC (Media Access Control) addresses.  = If an end station
     is unplugged from one RBridge and plugged into another= , frames
     addressed to that older RBridge can be black holed.  They can be
     sent just to the older RBridge that the end station was connected
     to until cached address information at some remote RBridge times
     out, possibly for tens of seconds [RFC6325]."

In this scenario when an end-station moves TO a link where an
RBridge(RBx) with ESADI support is serving as AF for the vlan on which
the end-station is connected, this RBridge sends the end-station MACs
through ESADI pdu to other ESADI RBridges with a higher confidence and
the old routes in other ESADI RBridges are over-written.New routes(MAC
"A" is reachable via egress RBridge RBx) exist and frames destine= d to
MAC "A" are not black holed.

But what if this end-station moves FROM a link which has RBridge(RB1)
with ESADI support TO a link where RBridge(RB2) donot have ESADI
support. Is there any way RB1 can notify other ESADI implemented
RBridges in the campus to flush the old route(MAC "A" is reachabl= e via
egress RB1) so that frames for MAC "A" are not send directly to RB1
and are rather treated as unknown unicast frame and send on a DTree?
Could RB1 send to ESADI Implemented RBridges that MAC "A" is no longer
reachable via itself by sending confidence as 0 for that MAC in its
ESADI pdus?

Please correct me if my understanding is wrong.

Also could we recommend ESADI implemented RBridges to become DRB and
serve more AF for vlans.

Editorial comments and typos:

In Abstract
ESADI (End System Address Distribution Information) should be replaced by
ESADI (End Station Address Distribution Information) as per RFC6325

In section 3. ESADI DRB State
8th line: "for which RB1 is holding an ESADI-LSP zero with an ESADI Pararmeters" , typo for "Parameters"


In section 4. ESADI PDU processing
4th line:     "are only EASDI-LSP, EASDI-CSNP and EASDI-PSNP PDUs used
in ESADI."should be changed to
  "are only ESADI-LSP, ESADI-CSNP and ESADI-PSNP PDUs used in ESADI."

In section 4.1 Sending of ESASI PDUs

Change the typo in the header itself.

4th line:    "6(Innter.MacSA)" to '6(Inner.MacSA)&q= uot;

5th line:     "starting with the Intradomain Routeing Protoc= ol
Discriminator," Typo "Routeing" to "Routing"

2nd Para, 1st line: "Once an ESADI instance is operationally up, it multicasts it self-
  originated LSP number zero on the virtual link to announce its ESADI
  parameters."   may be changed to
"Once an ESADI instance is operationally up, it multicasts/sends its self-
  originated LSP number zero on the virtual link to announce its ESADI
  parameters."

5th Para, 2nd line: Typo "EASDI"

In section 5. ESADI-LSP Contents
7th line typo "EASDAI-LSPs

In section 5.1 ESADI Parameter Data
4th line typo "occurrnce"

Thank you,
Regards,
Somnath
_______________________________________________
trill mailing list
trill@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/trill

--20cf300fab4b47104b04be532564-- From hu.fangwei@zte.com.cn Mon Apr 23 01:14:26 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D10C121F8613; Mon, 23 Apr 2012 01:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.063 X-Spam-Level: X-Spam-Status: No, score=-96.063 tagged_above=-999 required=5 tests=[AWL=-0.228, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_75=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] 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 tN40rWJ6rlXj; Mon, 23 Apr 2012 01:14:22 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 4061921F85DF; Mon, 23 Apr 2012 01:14:21 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 286201455586978; Mon, 23 Apr 2012 15:33:28 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 66762.2371961387; Mon, 23 Apr 2012 16:14:13 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q3N8EBON043908; Mon, 23 Apr 2012 16:14:11 +0800 (GMT-8) (envelope-from hu.fangwei@zte.com.cn) In-Reply-To: To: somnath chatterjee MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.4 June 01, 2004 Message-ID: From: hu.fangwei@zte.com.cn Date: Mon, 23 Apr 2012 16:14:12 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-23 16:14:12, Serialize complete at 2012-04-23 16:14:12 Content-Type: multipart/alternative; boundary="=_alternative 002D3E9B482579E9_=" X-MAIL: mse01.zte.com.cn q3N8EBON043908 Cc: trill-bounces@ietf.org, trill@ietf.org Subject: Re: [trill] [rbridge] draft-hu-trill-rbridge-esadi-04 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 08:14:27 -0000 This is a multipart message in MIME format. --=_alternative 002D3E9B482579E9_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksIGNoYXR0ZXJqZWUNCg0KQnkgbXkgdW5kZXJzdGFuZGluZywgSWYgUkIxIHN1cHBvcnRzIEVT QURJLCBpdCBhZHZlcnRpc2VzIGFsbCB0aGUgDQplbmQtc3RhdGlvbiBNQUMgYXR0YWNoZWQgdG8g dGhlIHJlbW90ZSBSQnJpZGdlcy4NCg0KVGhlIHJlbW90ZSBSQnJpZGdlIGNhbiBkbyBzb21lIHBv bGljeSBmb3J3YXJkaW5nIGJhc2VkIG9uIHRoZSBNQUMgYWRkcmVzcywgDQpidXQgSSB0aGluayBp dCBpcyBubyBuZWVkIHRvIG9wdCB0byBzZW5kIHRoZSBlbmQtc3RhdGlvbiBNQUMgYnkgdGhlIGxv Y2FsIA0KUkJyaWRnZS4NCg0KUmVnYXJkcw0KDQoNCg0Kc29tbmF0aCBjaGF0dGVyamVlIDxzb21u YXRoLmNoYXR0ZXJqZWUwMUBnbWFpbC5jb20+IA0KMjAxMi0wNC0yMyAxNDo1Nw0KDQrK1bz+yMsN Cmh1LmZhbmd3ZWlAenRlLmNvbS5jbg0Ks63LzQ0KdHJpbGxAaWV0Zi5vcmcsIHRyaWxsLWJvdW5j ZXNAaWV0Zi5vcmcNCtb3zOINClJlOiBbdHJpbGxdIFtyYnJpZGdlXSBkcmFmdC1odS10cmlsbC1y YnJpZGdlLWVzYWRpLTA0DQoNCg0KDQoNCg0KDQpIaSBGYW5nd2VpLA0KDQpUaGFuayB5b3UgZm9y IHRoZSBleHBsYW5hdGlvbi4NCg0KU28sIFJCMSBkb2Vzbm90IGluY2x1ZGUgdGhlIGVuZC1zdGF0 aW9ucyBNQUMgaW4gaXRzIExTUC4gV2hhdCBpZiBSQjEgaGFzIA0Kb3B0ZWQgbm90IHRvIHNlbmQg dGhpcyBlbmQtc3RhdGlvbiBNQUMgaW4gaXRzIEVTQURJLUxTUCBlYXJsaWVyPyBUaGUgb3RoZXIg DQpFU0FESSBSQnJpZGdlcyBoYXMgbm8gd2F5IHRvIGxlYXJuIHRoYXQgdGhpcyBNQUMgaGFzIHRv IGJlIGZsdXNoZWQod2hpY2ggDQptYXkgYmUgbGVhcm5lZCB0aHJvdWdoIG90aGVyIHByb2NlZHVy ZXMgZXhjZXB0IEVTQURJKS4gSXQgd291bGQgYmUgZ29vZCBpZiANCkVTQURJIFJCcmlkZ2VzIGNv dWxkIGV4cGxpY2l0bHkgdGVsbCBvdGhlciBSQnJpZGdlcyB0byBmb3JnZXQgYSBNQUMuDQoNClJl Z2FyZHMsDQpTb21uYXRoDQoNCjIwMTIvNC8yMiA8aHUuZmFuZ3dlaUB6dGUuY29tLmNuPg0KDQpU aGFua3MgZm9yIHRoZSByZXZpZXdpbmcgYW5kIGNvbW1lbnRzLiANCg0KUGxzIHNlZSB0aGUgZm9s bG93aW5nIGluIGxpbmUuIA0KDQo+SGkgQXV0aG9ycywNCg0KPkkgaGF2ZSByZWFkIHRoZSBkcmFm dC1odS10cmlsbC1yYnJpZGdlLWVzYWRpLTA0IGFuZCBzdXBwb3J0IGl0Lg0KDQo+SSBoYXZlIG9u ZSBxdWVzdGlvbiByZWdhcmRpbmcgdGhlIHByb2JsZW0gc3RhdGVkIGluIHRoZSBkcmFmdA0KDQo+ ICIgMi4gRmFzdCB1cGRhdGUgYWR2YW50YWdlczogRVNBREkgcHJvdG9jb2wgcHJvdmlkZXMgYSBm YXN0IHVwZGF0ZSBvZg0KICAgICBlbmQgbm9kZXMgTUFDIChNZWRpYSBBY2Nlc3MgQ29udHJvbCkg YWRkcmVzc2VzLiAgSWYgYW4gZW5kIHN0YXRpb24NCiAgICAgaXMgdW5wbHVnZ2VkIGZyb20gb25l IFJCcmlkZ2UgYW5kIHBsdWdnZWQgaW50byBhbm90aGVyLCBmcmFtZXMNCiAgICAgYWRkcmVzc2Vk IHRvIHRoYXQgb2xkZXIgUkJyaWRnZSBjYW4gYmUgYmxhY2sgaG9sZWQuICBUaGV5IGNhbiBiZQ0K ICAgICBzZW50IGp1c3QgdG8gdGhlIG9sZGVyIFJCcmlkZ2UgdGhhdCB0aGUgZW5kIHN0YXRpb24g d2FzIGNvbm5lY3RlZA0KICAgICB0byB1bnRpbCBjYWNoZWQgYWRkcmVzcyBpbmZvcm1hdGlvbiBh dCBzb21lIHJlbW90ZSBSQnJpZGdlIHRpbWVzDQogICAgIG91dCwgcG9zc2libHkgZm9yIHRlbnMg b2Ygc2Vjb25kcyBbUkZDNjMyNV0uIg0KDQo+SW4gdGhpcyBzY2VuYXJpbyB3aGVuIGFuIGVuZC1z dGF0aW9uIG1vdmVzIFRPIGEgbGluayB3aGVyZSBhbg0KPlJCcmlkZ2UoUkJ4KSB3aXRoIEVTQURJ IHN1cHBvcnQgaXMgc2VydmluZyBhcyBBRiBmb3IgdGhlIHZsYW4gb24gd2hpY2gNCj50aGUgZW5k LXN0YXRpb24gaXMgY29ubmVjdGVkLCB0aGlzIFJCcmlkZ2Ugc2VuZHMgdGhlIGVuZC1zdGF0aW9u IE1BQ3MNCj50aHJvdWdoIEVTQURJIHBkdSB0byBvdGhlciBFU0FESSBSQnJpZGdlcyB3aXRoIGEg aGlnaGVyIGNvbmZpZGVuY2UgYW5kDQo+dGhlIG9sZCByb3V0ZXMgaW4gb3RoZXIgRVNBREkgUkJy aWRnZXMgYXJlIG92ZXItd3JpdHRlbi5OZXcgcm91dGVzKE1BQw0KPiJBIiBpcyByZWFjaGFibGUg dmlhIGVncmVzcyBSQnJpZGdlIFJCeCkgZXhpc3QgYW5kIGZyYW1lcyBkZXN0aW5lZCB0bw0KPk1B QyAiQSIgYXJlIG5vdCBibGFjayBob2xlZC4NCg0KPkJ1dCB3aGF0IGlmIHRoaXMgZW5kLXN0YXRp b24gbW92ZXMgRlJPTSBhIGxpbmsgd2hpY2ggaGFzIFJCcmlkZ2UoUkIxKQ0KPndpdGggRVNBREkg c3VwcG9ydCBUTyBhIGxpbmsgd2hlcmUgUkJyaWRnZShSQjIpIGRvbm90IGhhdmUgRVNBREkNCj5z dXBwb3J0LiBJcyB0aGVyZSBhbnkgd2F5IFJCMSBjYW4gbm90aWZ5IG90aGVyIEVTQURJIGltcGxl bWVudGVkDQo+UkJyaWRnZXMgaW4gdGhlIGNhbXB1cyB0byBmbHVzaCB0aGUgb2xkIHJvdXRlKE1B QyAiQSIgaXMgcmVhY2hhYmxlIHZpYQ0KPmVncmVzcyBSQjEpIHNvIHRoYXQgZnJhbWVzIGZvciBN QUMgIkEiIGFyZSBub3Qgc2VuZCBkaXJlY3RseSB0byBSQjENCj5hbmQgYXJlIHJhdGhlciB0cmVh dGVkIGFzIHVua25vd24gdW5pY2FzdCBmcmFtZSBhbmQgc2VuZCBvbiBhIERUcmVlPw0KPkNvdWxk IFJCMSBzZW5kIHRvIEVTQURJIEltcGxlbWVudGVkIFJCcmlkZ2VzIHRoYXQgTUFDICJBIiBpcyBu byBsb25nZXINCj5yZWFjaGFibGUgdmlhIGl0c2VsZiBieSBzZW5kaW5nIGNvbmZpZGVuY2UgYXMg MCBmb3IgdGhhdCBNQUMgaW4gaXRzDQo+RVNBREkgcGR1cz8gDQoNCltoZnddIElmIFJCMSBub3Rp ZnkgdGhhdCB0aGUgZW5kLXN0YXRpb24gbW92ZXMgZnJvbSB0aGUgbGluaywgUkIxIHdpbGwgDQp1 cGRhdGUgDQoNCiBhbmQgZmxvb2QgdGhlIExTUCBvcmlnaW5hdGVkIHdpdGggbnVsbGluZyBvdXQg dGhlIGVuZC1zdGF0aW9uIGFkZHJlc3MuIA0KV2hlbiBvdGhlciBFU0FESSANCg0KIFJCcmlkZ2Ug cmVjZWl2ZXMgdGhlIHVwZGF0ZWQgTFNQLCB0aGV5IHdpbGwgZm9yZ2V0IHRoZSBNQUMgIkEiIGZy b20gaXRzIA0KTUFDIHRhYmxlLiANCg0KIEluIHRoaXMgd2F5LCBFU0FESSBwcm90b2NvbCBjYW4g ZmFzdCB1cGRhdGUgdGhlIE1BQyB0YWJsZSBvZiByZW1vdGUgDQpSQnJpZGdlcyB3aGVuIHRoZSBl bmQgc3RhdGlvbiBhdHRhY2hlZCANCg0KIGlzIHVucGx1Z2VkIG9yIGEgbmV3IGVuZCBzdGF0aW9u IGlzIHBsdWdlZC4NCg0KDQoNCj5QbGVhc2UgY29ycmVjdCBtZSBpZiBteSB1bmRlcnN0YW5kaW5n IGlzIHdyb25nLg0KDQo+QWxzbyBjb3VsZCB3ZSByZWNvbW1lbmQgRVNBREkgaW1wbGVtZW50ZWQg UkJyaWRnZXMgdG8gYmVjb21lIERSQiBhbmQNCj5zZXJ2ZSBtb3JlIEFGIGZvciB2bGFucy4NCg0K PkVkaXRvcmlhbCBjb21tZW50cyBhbmQgdHlwb3M6DQoNCj5JbiBBYnN0cmFjdA0KPkVTQURJIChF bmQgU3lzdGVtIEFkZHJlc3MgRGlzdHJpYnV0aW9uIEluZm9ybWF0aW9uKSBzaG91bGQgYmUgcmVw bGFjZWQgYnkNCj5FU0FESSAoRW5kIFN0YXRpb24gQWRkcmVzcyBEaXN0cmlidXRpb24gSW5mb3Jt YXRpb24pIGFzIHBlciBSRkM2MzI1DQoNCj5JbiBzZWN0aW9uIDMuIEVTQURJIERSQiBTdGF0ZQ0K Pjh0aCBsaW5lOiAiZm9yIHdoaWNoIFJCMSBpcyBob2xkaW5nIGFuIEVTQURJLUxTUCB6ZXJvIHdp dGggYW4gRVNBREkNCj5QYXJhcm1ldGVycyIgLCB0eXBvIGZvciAiUGFyYW1ldGVycyINCg0KDQo+ SW4gc2VjdGlvbiA0LiBFU0FESSBQRFUgcHJvY2Vzc2luZw0KPjR0aCBsaW5lOiAgICAgImFyZSBv bmx5IEVBU0RJLUxTUCwgRUFTREktQ1NOUCBhbmQgRUFTREktUFNOUCBQRFVzIHVzZWQNCj5pbiBF U0FESS4ic2hvdWxkIGJlIGNoYW5nZWQgdG8NCj4gICAiYXJlIG9ubHkgRVNBREktTFNQLCBFU0FE SS1DU05QIGFuZCBFU0FESS1QU05QIFBEVXMgdXNlZCBpbiBFU0FESS4iDQoNCj5JbiBzZWN0aW9u IDQuMSBTZW5kaW5nIG9mIEVTQVNJIFBEVXMNCg0KPkNoYW5nZSB0aGUgdHlwbyBpbiB0aGUgaGVh ZGVyIGl0c2VsZi4NCg0KPjR0aCBsaW5lOiAgICAiNihJbm50ZXIuTWFjU0EpIiB0byAnNihJbm5l ci5NYWNTQSkiDQoNCj41dGggbGluZTogICAgICJzdGFydGluZyB3aXRoIHRoZSBJbnRyYWRvbWFp biBSb3V0ZWluZyBQcm90b2NvbA0KPkRpc2NyaW1pbmF0b3IsIiBUeXBvICJSb3V0ZWluZyIgdG8g IlJvdXRpbmciDQoNCj4ybmQgUGFyYSwgMXN0IGxpbmU6ICJPbmNlIGFuIEVTQURJIGluc3RhbmNl IGlzIG9wZXJhdGlvbmFsbHkgdXAsIGl0DQo+bXVsdGljYXN0cyBpdCBzZWxmLQ0KPiAgb3JpZ2lu YXRlZCBMU1AgbnVtYmVyIHplcm8gb24gdGhlIHZpcnR1YWwgbGluayB0byBhbm5vdW5jZSBpdHMg RVNBREkNCj4gIHBhcmFtZXRlcnMuIiAgIG1heSBiZSBjaGFuZ2VkIHRvDQo+Ik9uY2UgYW4gRVNB REkgaW5zdGFuY2UgaXMgb3BlcmF0aW9uYWxseSB1cCwgaXQgbXVsdGljYXN0cy9zZW5kcyBpdHMg DQpzZWxmLQ0KPiAgIG9yaWdpbmF0ZWQgTFNQIG51bWJlciB6ZXJvIG9uIHRoZSB2aXJ0dWFsIGxp bmsgdG8gYW5ub3VuY2UgaXRzIEVTQURJDQo+ICAgcGFyYW1ldGVycy4iDQoNCj41dGggUGFyYSwg Mm5kIGxpbmU6IFR5cG8gIkVBU0RJIg0KDQo+SW4gc2VjdGlvbiA1LiBFU0FESS1MU1AgQ29udGVu dHMNCj43dGggbGluZSB0eXBvICJFQVNEQUktTFNQcw0KDQo+SW4gc2VjdGlvbiA1LjEgRVNBREkg UGFyYW1ldGVyIERhdGENCj40dGggbGluZSB0eXBvICJvY2N1cnJuY2UiIA0KDQpbaGZ3XSBUaGFu a3MgZm9yIHRoZSBjb3JyZWN0aW5nLCB3ZSB3aWxsIGNvcnJlY3QgaXQgaW4gdGhlIG5leHQgdmVy c2lvbi4NCg0KDQoNCg0Kc29tbmF0aCBjaGF0dGVyamVlIDxzb21uYXRoLmNoYXR0ZXJqZWUwMUBn bWFpbC5jb20+IA0Kt6K8/sjLOiAgdHJpbGwtYm91bmNlc0BpZXRmLm9yZyANCjIwMTItMDQtMjEg MDE6MTcgDQoNCg0KytW8/sjLDQp0cmlsbEBpZXRmLm9yZyANCrOty80NCg0K1vfM4g0KW3RyaWxs XSBbcmJyaWRnZV0gZHJhZnQtaHUtdHJpbGwtcmJyaWRnZS1lc2FkaS0wNA0KDQoNCg0KDQoNCg0K DQoNCkhpIEF1dGhvcnMsDQoNCkkgaGF2ZSByZWFkIHRoZSBkcmFmdC1odS10cmlsbC1yYnJpZGdl LWVzYWRpLTA0IGFuZCBzdXBwb3J0IGl0Lg0KDQpJIGhhdmUgb25lIHF1ZXN0aW9uIHJlZ2FyZGlu ZyB0aGUgcHJvYmxlbSBzdGF0ZWQgaW4gdGhlIGRyYWZ0DQoNCiIgMi4gRmFzdCB1cGRhdGUgYWR2 YW50YWdlczogRVNBREkgcHJvdG9jb2wgcHJvdmlkZXMgYSBmYXN0IHVwZGF0ZSBvZg0KICAgICBl bmQgbm9kZXMgTUFDIChNZWRpYSBBY2Nlc3MgQ29udHJvbCkgYWRkcmVzc2VzLiAgSWYgYW4gZW5k IHN0YXRpb24NCiAgICAgaXMgdW5wbHVnZ2VkIGZyb20gb25lIFJCcmlkZ2UgYW5kIHBsdWdnZWQg aW50byBhbm90aGVyLCBmcmFtZXMNCiAgICAgYWRkcmVzc2VkIHRvIHRoYXQgb2xkZXIgUkJyaWRn ZSBjYW4gYmUgYmxhY2sgaG9sZWQuICBUaGV5IGNhbiBiZQ0KICAgICBzZW50IGp1c3QgdG8gdGhl IG9sZGVyIFJCcmlkZ2UgdGhhdCB0aGUgZW5kIHN0YXRpb24gd2FzIGNvbm5lY3RlZA0KICAgICB0 byB1bnRpbCBjYWNoZWQgYWRkcmVzcyBpbmZvcm1hdGlvbiBhdCBzb21lIHJlbW90ZSBSQnJpZGdl IHRpbWVzDQogICAgIG91dCwgcG9zc2libHkgZm9yIHRlbnMgb2Ygc2Vjb25kcyBbUkZDNjMyNV0u Ig0KDQpJbiB0aGlzIHNjZW5hcmlvIHdoZW4gYW4gZW5kLXN0YXRpb24gbW92ZXMgVE8gYSBsaW5r IHdoZXJlIGFuDQpSQnJpZGdlKFJCeCkgd2l0aCBFU0FESSBzdXBwb3J0IGlzIHNlcnZpbmcgYXMg QUYgZm9yIHRoZSB2bGFuIG9uIHdoaWNoDQp0aGUgZW5kLXN0YXRpb24gaXMgY29ubmVjdGVkLCB0 aGlzIFJCcmlkZ2Ugc2VuZHMgdGhlIGVuZC1zdGF0aW9uIE1BQ3MNCnRocm91Z2ggRVNBREkgcGR1 IHRvIG90aGVyIEVTQURJIFJCcmlkZ2VzIHdpdGggYSBoaWdoZXIgY29uZmlkZW5jZSBhbmQNCnRo ZSBvbGQgcm91dGVzIGluIG90aGVyIEVTQURJIFJCcmlkZ2VzIGFyZSBvdmVyLXdyaXR0ZW4uTmV3 IHJvdXRlcyhNQUMNCiJBIiBpcyByZWFjaGFibGUgdmlhIGVncmVzcyBSQnJpZGdlIFJCeCkgZXhp c3QgYW5kIGZyYW1lcyBkZXN0aW5lZCB0bw0KTUFDICJBIiBhcmUgbm90IGJsYWNrIGhvbGVkLg0K DQpCdXQgd2hhdCBpZiB0aGlzIGVuZC1zdGF0aW9uIG1vdmVzIEZST00gYSBsaW5rIHdoaWNoIGhh cyBSQnJpZGdlKFJCMSkNCndpdGggRVNBREkgc3VwcG9ydCBUTyBhIGxpbmsgd2hlcmUgUkJyaWRn ZShSQjIpIGRvbm90IGhhdmUgRVNBREkNCnN1cHBvcnQuIElzIHRoZXJlIGFueSB3YXkgUkIxIGNh biBub3RpZnkgb3RoZXIgRVNBREkgaW1wbGVtZW50ZWQNClJCcmlkZ2VzIGluIHRoZSBjYW1wdXMg dG8gZmx1c2ggdGhlIG9sZCByb3V0ZShNQUMgIkEiIGlzIHJlYWNoYWJsZSB2aWENCmVncmVzcyBS QjEpIHNvIHRoYXQgZnJhbWVzIGZvciBNQUMgIkEiIGFyZSBub3Qgc2VuZCBkaXJlY3RseSB0byBS QjENCmFuZCBhcmUgcmF0aGVyIHRyZWF0ZWQgYXMgdW5rbm93biB1bmljYXN0IGZyYW1lIGFuZCBz ZW5kIG9uIGEgRFRyZWU/DQpDb3VsZCBSQjEgc2VuZCB0byBFU0FESSBJbXBsZW1lbnRlZCBSQnJp ZGdlcyB0aGF0IE1BQyAiQSIgaXMgbm8gbG9uZ2VyDQpyZWFjaGFibGUgdmlhIGl0c2VsZiBieSBz ZW5kaW5nIGNvbmZpZGVuY2UgYXMgMCBmb3IgdGhhdCBNQUMgaW4gaXRzDQpFU0FESSBwZHVzPw0K DQpQbGVhc2UgY29ycmVjdCBtZSBpZiBteSB1bmRlcnN0YW5kaW5nIGlzIHdyb25nLg0KDQpBbHNv IGNvdWxkIHdlIHJlY29tbWVuZCBFU0FESSBpbXBsZW1lbnRlZCBSQnJpZGdlcyB0byBiZWNvbWUg RFJCIGFuZA0Kc2VydmUgbW9yZSBBRiBmb3IgdmxhbnMuDQoNCkVkaXRvcmlhbCBjb21tZW50cyBh bmQgdHlwb3M6DQoNCkluIEFic3RyYWN0DQpFU0FESSAoRW5kIFN5c3RlbSBBZGRyZXNzIERpc3Ry aWJ1dGlvbiBJbmZvcm1hdGlvbikgc2hvdWxkIGJlIHJlcGxhY2VkIGJ5DQpFU0FESSAoRW5kIFN0 YXRpb24gQWRkcmVzcyBEaXN0cmlidXRpb24gSW5mb3JtYXRpb24pIGFzIHBlciBSRkM2MzI1DQoN CkluIHNlY3Rpb24gMy4gRVNBREkgRFJCIFN0YXRlDQo4dGggbGluZTogImZvciB3aGljaCBSQjEg aXMgaG9sZGluZyBhbiBFU0FESS1MU1AgemVybyB3aXRoIGFuIEVTQURJDQpQYXJhcm1ldGVycyIg LCB0eXBvIGZvciAiUGFyYW1ldGVycyINCg0KDQpJbiBzZWN0aW9uIDQuIEVTQURJIFBEVSBwcm9j ZXNzaW5nDQo0dGggbGluZTogICAgICJhcmUgb25seSBFQVNESS1MU1AsIEVBU0RJLUNTTlAgYW5k IEVBU0RJLVBTTlAgUERVcyB1c2VkDQppbiBFU0FESS4ic2hvdWxkIGJlIGNoYW5nZWQgdG8NCiAg ImFyZSBvbmx5IEVTQURJLUxTUCwgRVNBREktQ1NOUCBhbmQgRVNBREktUFNOUCBQRFVzIHVzZWQg aW4gRVNBREkuIg0KDQpJbiBzZWN0aW9uIDQuMSBTZW5kaW5nIG9mIEVTQVNJIFBEVXMNCg0KQ2hh bmdlIHRoZSB0eXBvIGluIHRoZSBoZWFkZXIgaXRzZWxmLg0KDQo0dGggbGluZTogICAgIjYoSW5u dGVyLk1hY1NBKSIgdG8gJzYoSW5uZXIuTWFjU0EpIg0KDQo1dGggbGluZTogICAgICJzdGFydGlu ZyB3aXRoIHRoZSBJbnRyYWRvbWFpbiBSb3V0ZWluZyBQcm90b2NvbA0KRGlzY3JpbWluYXRvciwi IFR5cG8gIlJvdXRlaW5nIiB0byAiUm91dGluZyINCg0KMm5kIFBhcmEsIDFzdCBsaW5lOiAiT25j ZSBhbiBFU0FESSBpbnN0YW5jZSBpcyBvcGVyYXRpb25hbGx5IHVwLCBpdA0KbXVsdGljYXN0cyBp dCBzZWxmLQ0KICBvcmlnaW5hdGVkIExTUCBudW1iZXIgemVybyBvbiB0aGUgdmlydHVhbCBsaW5r IHRvIGFubm91bmNlIGl0cyBFU0FESQ0KICBwYXJhbWV0ZXJzLiIgICBtYXkgYmUgY2hhbmdlZCB0 bw0KIk9uY2UgYW4gRVNBREkgaW5zdGFuY2UgaXMgb3BlcmF0aW9uYWxseSB1cCwgaXQgbXVsdGlj YXN0cy9zZW5kcyBpdHMgc2VsZi0NCiAgb3JpZ2luYXRlZCBMU1AgbnVtYmVyIHplcm8gb24gdGhl IHZpcnR1YWwgbGluayB0byBhbm5vdW5jZSBpdHMgRVNBREkNCiAgcGFyYW1ldGVycy4iDQoNCjV0 aCBQYXJhLCAybmQgbGluZTogVHlwbyAiRUFTREkiDQoNCkluIHNlY3Rpb24gNS4gRVNBREktTFNQ IENvbnRlbnRzDQo3dGggbGluZSB0eXBvICJFQVNEQUktTFNQcw0KDQpJbiBzZWN0aW9uIDUuMSBF U0FESSBQYXJhbWV0ZXIgRGF0YQ0KNHRoIGxpbmUgdHlwbyAib2NjdXJybmNlIg0KDQpUaGFuayB5 b3UsDQpSZWdhcmRzLA0KU29tbmF0aA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCnRyaWxsIG1haWxpbmcgbGlzdA0KdHJpbGxAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJpbGwNCg0KDQoNCg0K --=_alternative 002D3E9B482579E9_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLCBjaGF0dGVyamVlPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5CeSBteSB1bmRlcnN0 YW5kaW5nLCBJZiBSQjEgc3VwcG9ydHMNCkVTQURJLCBpdCBhZHZlcnRpc2VzIGFsbCB0aGUgZW5k LXN0YXRpb24gTUFDIGF0dGFjaGVkIHRvIHRoZSByZW1vdGUgUkJyaWRnZXMuPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGUgcmVtb3RlIFJCcmlkZ2Ug Y2FuIGRvIHNvbWUgcG9saWN5DQpmb3J3YXJkaW5nIGJhc2VkIG9uIHRoZSBNQUMgYWRkcmVzcywg YnV0IEkgdGhpbmsgaXQgaXMgbm8gbmVlZCB0byBvcHQgdG8NCnNlbmQgdGhlIGVuZC1zdGF0aW9u IE1BQyBieSB0aGUgbG9jYWwgUkJyaWRnZS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPlJlZ2FyZHM8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFi bGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM1JT48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+c29tbmF0aCBjaGF0dGVyamVlICZsdDtzb21uYXRoLmNo YXR0ZXJqZWUwMUBnbWFpbC5jb20mZ3Q7PC9iPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPjIwMTItMDQtMjMgMTQ6NTc8L2ZvbnQ+DQo8dGQgd2lkdGg9NjQlPg0K PHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmln aHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0 ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+aHUuZmFuZ3dlaUB6dGUuY29tLmNuPC9m b250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj50cmlsbEBpZXRmLm9yZywgdHJpbGwtYm91bmNlc0BpZXRmLm9yZzwv Zm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFt0cmlsbF0gW3JicmlkZ2VdIGRyYWZ0LWh1LXRyaWxsLXJi cmlkZ2UtZXNhZGktMDQ8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249 dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48 Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+SGkgRmFuZ3dlaSw8L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rIHlvdSBmb3IgdGhlIGV4cGxh bmF0aW9uLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ U28sIFJCMSBkb2Vzbm90IGluY2x1ZGUgdGhlIGVuZC1zdGF0aW9ucw0KTUFDIGluIGl0cyBMU1Au IFdoYXQgaWYgUkIxIGhhcyBvcHRlZCBub3QgdG8gc2VuZCB0aGlzIGVuZC1zdGF0aW9uIE1BQw0K aW4gaXRzIEVTQURJLUxTUCBlYXJsaWVyPyBUaGUgb3RoZXIgRVNBREkgUkJyaWRnZXMgaGFzIG5v IHdheSB0byBsZWFybg0KdGhhdCB0aGlzIE1BQyBoYXMgdG8gYmUgZmx1c2hlZCh3aGljaCBtYXkg YmUgbGVhcm5lZCB0aHJvdWdoIG90aGVyIHByb2NlZHVyZXMNCmV4Y2VwdCBFU0FESSkuIEl0IHdv dWxkIGJlIGdvb2QgaWYgRVNBREkgUkJyaWRnZXMgY291bGQgZXhwbGljaXRseSB0ZWxsDQpvdGhl ciBSQnJpZGdlcyB0byBmb3JnZXQgYSBNQUMuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MyBmYWNlPSJzYW5zLXNlcmlmIj5SZWdhcmRzLDwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+U29tbmF0aDxicj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+MjAxMi80LzIyICZsdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86aHUuZmFu Z3dlaUB6dGUuY29tLmNuIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFj ZT0ic2Fucy1zZXJpZiI+PHU+aHUuZmFuZ3dlaUB6dGUuY29tLmNuPC91PjwvZm9udD48L2E+PGZv bnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZndDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0z IGZhY2U9InNhbnMtc2VyaWYiPjxicj4NClRoYW5rcyBmb3IgdGhlIHJldmlld2luZyBhbmQgY29t bWVudHMuIDxicj4NCjxicj4NClBscyBzZWUgdGhlIGZvbGxvd2luZyBpbiBsaW5lLiA8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0zPjx0dD48YnI+DQomZ3Q7SGkgQXV0aG9ycyw8YnI+DQo8YnI+DQom Z3Q7SSBoYXZlIHJlYWQgdGhlIGRyYWZ0LWh1LXRyaWxsLXJicmlkZ2UtZXNhZGktMDQgYW5kIHN1 cHBvcnQgaXQuPGJyPg0KPGJyPg0KJmd0O0kgaGF2ZSBvbmUgcXVlc3Rpb24gcmVnYXJkaW5nIHRo ZSBwcm9ibGVtIHN0YXRlZCBpbiB0aGUgZHJhZnQ8YnI+DQo8YnI+DQomZ3Q7ICZxdW90OyAyLiBG YXN0IHVwZGF0ZSBhZHZhbnRhZ2VzOiBFU0FESSBwcm90b2NvbCBwcm92aWRlcyBhIGZhc3QgdXBk YXRlDQpvZjxicj4NCiAmbmJzcDsgJm5ic3A7IGVuZCBub2RlcyBNQUMgKE1lZGlhIEFjY2VzcyBD b250cm9sKSBhZGRyZXNzZXMuICZuYnNwO0lmDQphbiBlbmQgc3RhdGlvbjxicj4NCiAmbmJzcDsg Jm5ic3A7IGlzIHVucGx1Z2dlZCBmcm9tIG9uZSBSQnJpZGdlIGFuZCBwbHVnZ2VkIGludG8gYW5v dGhlciwNCmZyYW1lczxicj4NCiAmbmJzcDsgJm5ic3A7IGFkZHJlc3NlZCB0byB0aGF0IG9sZGVy IFJCcmlkZ2UgY2FuIGJlIGJsYWNrIGhvbGVkLiAmbmJzcDtUaGV5DQpjYW4gYmU8YnI+DQogJm5i c3A7ICZuYnNwOyBzZW50IGp1c3QgdG8gdGhlIG9sZGVyIFJCcmlkZ2UgdGhhdCB0aGUgZW5kIHN0 YXRpb24gd2FzDQpjb25uZWN0ZWQ8YnI+DQogJm5ic3A7ICZuYnNwOyB0byB1bnRpbCBjYWNoZWQg YWRkcmVzcyBpbmZvcm1hdGlvbiBhdCBzb21lIHJlbW90ZSBSQnJpZGdlDQp0aW1lczxicj4NCiAm bmJzcDsgJm5ic3A7IG91dCwgcG9zc2libHkgZm9yIHRlbnMgb2Ygc2Vjb25kcyBbUkZDNjMyNV0u JnF1b3Q7PGJyPg0KPGJyPg0KJmd0O0luIHRoaXMgc2NlbmFyaW8gd2hlbiBhbiBlbmQtc3RhdGlv biBtb3ZlcyBUTyBhIGxpbmsgd2hlcmUgYW48YnI+DQomZ3Q7UkJyaWRnZShSQngpIHdpdGggRVNB REkgc3VwcG9ydCBpcyBzZXJ2aW5nIGFzIEFGIGZvciB0aGUgdmxhbiBvbiB3aGljaDxicj4NCiZn dDt0aGUgZW5kLXN0YXRpb24gaXMgY29ubmVjdGVkLCB0aGlzIFJCcmlkZ2Ugc2VuZHMgdGhlIGVu ZC1zdGF0aW9uIE1BQ3M8YnI+DQomZ3Q7dGhyb3VnaCBFU0FESSBwZHUgdG8gb3RoZXIgRVNBREkg UkJyaWRnZXMgd2l0aCBhIGhpZ2hlciBjb25maWRlbmNlDQphbmQ8YnI+DQomZ3Q7dGhlIG9sZCBy b3V0ZXMgaW4gb3RoZXIgRVNBREkgUkJyaWRnZXMgYXJlIG92ZXItd3JpdHRlbi5OZXcgcm91dGVz KE1BQzxicj4NCiZndDsmcXVvdDtBJnF1b3Q7IGlzIHJlYWNoYWJsZSB2aWEgZWdyZXNzIFJCcmlk Z2UgUkJ4KSBleGlzdCBhbmQgZnJhbWVzDQpkZXN0aW5lZCB0bzxicj4NCiZndDtNQUMgJnF1b3Q7 QSZxdW90OyBhcmUgbm90IGJsYWNrIGhvbGVkLjxicj4NCjxicj4NCiZndDtCdXQgd2hhdCBpZiB0 aGlzIGVuZC1zdGF0aW9uIG1vdmVzIEZST00gYSBsaW5rIHdoaWNoIGhhcyBSQnJpZGdlKFJCMSk8 YnI+DQomZ3Q7d2l0aCBFU0FESSBzdXBwb3J0IFRPIGEgbGluayB3aGVyZSBSQnJpZGdlKFJCMikg ZG9ub3QgaGF2ZSBFU0FESTxicj4NCiZndDtzdXBwb3J0LiBJcyB0aGVyZSBhbnkgd2F5IFJCMSBj YW4gbm90aWZ5IG90aGVyIEVTQURJIGltcGxlbWVudGVkPGJyPg0KJmd0O1JCcmlkZ2VzIGluIHRo ZSBjYW1wdXMgdG8gZmx1c2ggdGhlIG9sZCByb3V0ZShNQUMgJnF1b3Q7QSZxdW90OyBpcw0KcmVh Y2hhYmxlIHZpYTxicj4NCiZndDtlZ3Jlc3MgUkIxKSBzbyB0aGF0IGZyYW1lcyBmb3IgTUFDICZx dW90O0EmcXVvdDsgYXJlIG5vdCBzZW5kIGRpcmVjdGx5DQp0byBSQjE8YnI+DQomZ3Q7YW5kIGFy ZSByYXRoZXIgdHJlYXRlZCBhcyB1bmtub3duIHVuaWNhc3QgZnJhbWUgYW5kIHNlbmQgb24gYSBE VHJlZT88YnI+DQomZ3Q7Q291bGQgUkIxIHNlbmQgdG8gRVNBREkgSW1wbGVtZW50ZWQgUkJyaWRn ZXMgdGhhdCBNQUMgJnF1b3Q7QSZxdW90Ow0KaXMgbm8gbG9uZ2VyPGJyPg0KJmd0O3JlYWNoYWJs ZSB2aWEgaXRzZWxmIGJ5IHNlbmRpbmcgY29uZmlkZW5jZSBhcyAwIGZvciB0aGF0IE1BQyBpbiBp dHM8YnI+DQomZ3Q7RVNBREkgcGR1cz88L3R0PjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fu cy1zZXJpZiI+IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+PHR0Pjxicj4NCltoZnddIElmIFJC MSBub3RpZnkgdGhhdCB0aGUgZW5kLXN0YXRpb24gbW92ZXMgZnJvbSB0aGUgbGluaywgUkIxIHdp bGwNCnVwZGF0ZTwvdHQ+PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPGJy Pg0KPC9mb250Pjxmb250IHNpemU9Mz48dHQ+PGJyPg0KIGFuZCBmbG9vZCB0aGUgTFNQIG9yaWdp bmF0ZWQgd2l0aCBudWxsaW5nIG91dCB0aGUgZW5kLXN0YXRpb24gYWRkcmVzcy4NCldoZW4gb3Ro ZXIgRVNBREkgPC90dD48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4N CjwvZm9udD48Zm9udCBzaXplPTM+PHR0Pjxicj4NCiBSQnJpZGdlIHJlY2VpdmVzIHRoZSB1cGRh dGVkIExTUCwgdGhleSB3aWxsIGZvcmdldCB0aGUgTUFDICZxdW90O0EmcXVvdDsNCmZyb20gaXRz IE1BQyB0YWJsZS48L3R0PjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxi cj4NCjwvZm9udD48Zm9udCBzaXplPTM+PHR0Pjxicj4NCiBJbiB0aGlzIHdheSwgRVNBREkgcHJv dG9jb2wgY2FuIGZhc3QgdXBkYXRlIHRoZSBNQUMgdGFibGUgb2YgcmVtb3RlIFJCcmlkZ2VzDQp3 aGVuIHRoZSBlbmQgc3RhdGlvbiBhdHRhY2hlZDwvdHQ+PC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJzYW5zLXNlcmlmIj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTM+PHR0Pjxicj4NCiBpcyB1 bnBsdWdlZCBvciBhIG5ldyBlbmQgc3RhdGlvbiBpcyBwbHVnZWQuPC90dD48L2ZvbnQ+DQo8dGFi bGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTEwMCU+PC90YWJsZT4N Cjxicj48Zm9udCBzaXplPTM+PHR0Pjxicj4NCjxicj4NCiZndDtQbGVhc2UgY29ycmVjdCBtZSBp ZiBteSB1bmRlcnN0YW5kaW5nIGlzIHdyb25nLjxicj4NCjxicj4NCiZndDtBbHNvIGNvdWxkIHdl IHJlY29tbWVuZCBFU0FESSBpbXBsZW1lbnRlZCBSQnJpZGdlcyB0byBiZWNvbWUgRFJCIGFuZDxi cj4NCiZndDtzZXJ2ZSBtb3JlIEFGIGZvciB2bGFucy48YnI+DQo8YnI+DQomZ3Q7RWRpdG9yaWFs IGNvbW1lbnRzIGFuZCB0eXBvczo8YnI+DQo8YnI+DQomZ3Q7SW4gQWJzdHJhY3Q8YnI+DQomZ3Q7 RVNBREkgKEVuZCBTeXN0ZW0gQWRkcmVzcyBEaXN0cmlidXRpb24gSW5mb3JtYXRpb24pIHNob3Vs ZCBiZSByZXBsYWNlZA0KYnk8YnI+DQomZ3Q7RVNBREkgKEVuZCBTdGF0aW9uIEFkZHJlc3MgRGlz dHJpYnV0aW9uIEluZm9ybWF0aW9uKSBhcyBwZXIgUkZDNjMyNTxicj4NCjxicj4NCiZndDtJbiBz ZWN0aW9uIDMuIEVTQURJIERSQiBTdGF0ZTxicj4NCiZndDs4dGggbGluZTogJnF1b3Q7Zm9yIHdo aWNoIFJCMSBpcyBob2xkaW5nIGFuIEVTQURJLUxTUCB6ZXJvIHdpdGggYW4NCkVTQURJPGJyPg0K Jmd0O1BhcmFybWV0ZXJzJnF1b3Q7ICwgdHlwbyBmb3IgJnF1b3Q7UGFyYW1ldGVycyZxdW90Ozxi cj4NCjxicj4NCjxicj4NCiZndDtJbiBzZWN0aW9uIDQuIEVTQURJIFBEVSBwcm9jZXNzaW5nPGJy Pg0KJmd0OzR0aCBsaW5lOiAmbmJzcDsgJm5ic3A7ICZxdW90O2FyZSBvbmx5IEVBU0RJLUxTUCwg RUFTREktQ1NOUCBhbmQgRUFTREktUFNOUA0KUERVcyB1c2VkPGJyPg0KJmd0O2luIEVTQURJLiZx dW90O3Nob3VsZCBiZSBjaGFuZ2VkIHRvPGJyPg0KJmd0OyAmbmJzcDsgJnF1b3Q7YXJlIG9ubHkg RVNBREktTFNQLCBFU0FESS1DU05QIGFuZCBFU0FESS1QU05QIFBEVXMgdXNlZA0KaW4gRVNBREku JnF1b3Q7PGJyPg0KPGJyPg0KJmd0O0luIHNlY3Rpb24gNC4xIFNlbmRpbmcgb2YgRVNBU0kgUERV czxicj4NCjxicj4NCiZndDtDaGFuZ2UgdGhlIHR5cG8gaW4gdGhlIGhlYWRlciBpdHNlbGYuPGJy Pg0KPGJyPg0KJmd0OzR0aCBsaW5lOiAmbmJzcDsgJm5ic3A7JnF1b3Q7NihJbm50ZXIuTWFjU0Ep JnF1b3Q7IHRvICc2KElubmVyLk1hY1NBKSZxdW90Ozxicj4NCjxicj4NCiZndDs1dGggbGluZTog Jm5ic3A7ICZuYnNwOyAmcXVvdDtzdGFydGluZyB3aXRoIHRoZSBJbnRyYWRvbWFpbiBSb3V0ZWlu Zw0KUHJvdG9jb2w8YnI+DQomZ3Q7RGlzY3JpbWluYXRvciwmcXVvdDsgVHlwbyAmcXVvdDtSb3V0 ZWluZyZxdW90OyB0byAmcXVvdDtSb3V0aW5nJnF1b3Q7PGJyPg0KPGJyPg0KJmd0OzJuZCBQYXJh LCAxc3QgbGluZTogJnF1b3Q7T25jZSBhbiBFU0FESSBpbnN0YW5jZSBpcyBvcGVyYXRpb25hbGx5 IHVwLA0KaXQ8YnI+DQomZ3Q7bXVsdGljYXN0cyBpdCBzZWxmLTxicj4NCiZndDsgJm5ic3A7b3Jp Z2luYXRlZCBMU1AgbnVtYmVyIHplcm8gb24gdGhlIHZpcnR1YWwgbGluayB0byBhbm5vdW5jZSBp dHMNCkVTQURJPGJyPg0KJmd0OyAmbmJzcDtwYXJhbWV0ZXJzLiZxdW90OyAmbmJzcDsgbWF5IGJl IGNoYW5nZWQgdG88YnI+DQomZ3Q7JnF1b3Q7T25jZSBhbiBFU0FESSBpbnN0YW5jZSBpcyBvcGVy YXRpb25hbGx5IHVwLCBpdCBtdWx0aWNhc3RzL3NlbmRzDQppdHMgc2VsZi08YnI+DQomZ3Q7ICZu YnNwOyBvcmlnaW5hdGVkIExTUCBudW1iZXIgemVybyBvbiB0aGUgdmlydHVhbCBsaW5rIHRvIGFu bm91bmNlDQppdHMgRVNBREk8YnI+DQomZ3Q7ICZuYnNwOyBwYXJhbWV0ZXJzLiZxdW90Ozxicj4N Cjxicj4NCiZndDs1dGggUGFyYSwgMm5kIGxpbmU6IFR5cG8gJnF1b3Q7RUFTREkmcXVvdDs8YnI+ DQo8YnI+DQomZ3Q7SW4gc2VjdGlvbiA1LiBFU0FESS1MU1AgQ29udGVudHM8YnI+DQomZ3Q7N3Ro IGxpbmUgdHlwbyAmcXVvdDtFQVNEQUktTFNQczxicj4NCjxicj4NCiZndDtJbiBzZWN0aW9uIDUu MSBFU0FESSBQYXJhbWV0ZXIgRGF0YTxicj4NCiZndDs0dGggbGluZSB0eXBvICZxdW90O29jY3Vy cm5jZSZxdW90OzwvdHQ+PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjxi cj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+W2hmd10gVGhh bmtzIGZvciB0aGUgY29ycmVjdGluZywgd2UNCndpbGwgY29ycmVjdCBpdCBpbiB0aGUgbmV4dCB2 ZXJzaW9uLjxicj4NCjxicj4NCjxicj4NCjwvZm9udD4NCjxwPg0KPHRhYmxlIHdpZHRoPTEwMCU+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD01MiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPjxiPnNvbW5hdGggY2hhdHRlcmplZSAmbHQ7PC9iPjwvZm9udD48YSBocmVmPW1haWx0 bzpzb21uYXRoLmNoYXR0ZXJqZWUwMUBnbWFpbC5jb20gdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXpl PTEgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48Yj48dT5zb21uYXRoLmNoYXR0ZXJqZWUw MUBnbWFpbC5jb208L3U+PC9iPjwvZm9udD48L2E+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPjxiPiZndDs8L2I+DQo8YnI+DQq3orz+yMs6ICZuYnNwOzwvZm9udD48YSBocmVmPSJtYWls dG86dHJpbGwtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTEgY29s b3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT50cmlsbC1ib3VuY2VzQGlldGYub3JnPC91Pjwv Zm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPHA+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTItMDQtMjEgMDE6MTc8L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPHRkIHdpZHRoPTQ3JT4NCjxicj4N Cjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MTIlPg0KPGRp diBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250 PjwvZGl2Pg0KPHRkIHdpZHRoPTg3JT48YSBocmVmPW1haWx0bzp0cmlsbEBpZXRmLm9yZyB0YXJn ZXQ9X2JsYW5rPjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1PnRy aWxsQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYi Pg0KPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPg0KPHRyIHZh bGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj5bdHJpbGxdIFtyYnJpZGdlXSBkcmFmdC1odS10cmlsbC1yYnJpZGdlLWVzYWRpLTA0PC9m b250PjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249 dG9wPg0KPHRkIHdpZHRoPTQ5JT4NCjx0ZCB3aWR0aD01MCU+PC90YWJsZT4NCjxicj48L3RhYmxl Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8YnI+DQo8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0zPjx0dD5IaSBBdXRob3JzLDxicj4NCjxicj4NCkkgaGF2ZSByZWFk IHRoZSBkcmFmdC1odS10cmlsbC1yYnJpZGdlLWVzYWRpLTA0IGFuZCBzdXBwb3J0IGl0Ljxicj4N Cjxicj4NCkkgaGF2ZSBvbmUgcXVlc3Rpb24gcmVnYXJkaW5nIHRoZSBwcm9ibGVtIHN0YXRlZCBp biB0aGUgZHJhZnQ8YnI+DQo8YnI+DQomcXVvdDsgMi4gRmFzdCB1cGRhdGUgYWR2YW50YWdlczog RVNBREkgcHJvdG9jb2wgcHJvdmlkZXMgYSBmYXN0IHVwZGF0ZQ0Kb2Y8YnI+DQogJm5ic3A7ICZu YnNwOyBlbmQgbm9kZXMgTUFDIChNZWRpYSBBY2Nlc3MgQ29udHJvbCkgYWRkcmVzc2VzLiAmbmJz cDtJZg0KYW4gZW5kIHN0YXRpb248YnI+DQogJm5ic3A7ICZuYnNwOyBpcyB1bnBsdWdnZWQgZnJv bSBvbmUgUkJyaWRnZSBhbmQgcGx1Z2dlZCBpbnRvIGFub3RoZXIsDQpmcmFtZXM8YnI+DQogJm5i c3A7ICZuYnNwOyBhZGRyZXNzZWQgdG8gdGhhdCBvbGRlciBSQnJpZGdlIGNhbiBiZSBibGFjayBo b2xlZC4gJm5ic3A7VGhleQ0KY2FuIGJlPGJyPg0KICZuYnNwOyAmbmJzcDsgc2VudCBqdXN0IHRv IHRoZSBvbGRlciBSQnJpZGdlIHRoYXQgdGhlIGVuZCBzdGF0aW9uIHdhcw0KY29ubmVjdGVkPGJy Pg0KICZuYnNwOyAmbmJzcDsgdG8gdW50aWwgY2FjaGVkIGFkZHJlc3MgaW5mb3JtYXRpb24gYXQg c29tZSByZW1vdGUgUkJyaWRnZQ0KdGltZXM8YnI+DQogJm5ic3A7ICZuYnNwOyBvdXQsIHBvc3Np Ymx5IGZvciB0ZW5zIG9mIHNlY29uZHMgW1JGQzYzMjVdLiZxdW90Ozxicj4NCjxicj4NCkluIHRo aXMgc2NlbmFyaW8gd2hlbiBhbiBlbmQtc3RhdGlvbiBtb3ZlcyBUTyBhIGxpbmsgd2hlcmUgYW48 YnI+DQpSQnJpZGdlKFJCeCkgd2l0aCBFU0FESSBzdXBwb3J0IGlzIHNlcnZpbmcgYXMgQUYgZm9y IHRoZSB2bGFuIG9uIHdoaWNoPGJyPg0KdGhlIGVuZC1zdGF0aW9uIGlzIGNvbm5lY3RlZCwgdGhp cyBSQnJpZGdlIHNlbmRzIHRoZSBlbmQtc3RhdGlvbiBNQUNzPGJyPg0KdGhyb3VnaCBFU0FESSBw ZHUgdG8gb3RoZXIgRVNBREkgUkJyaWRnZXMgd2l0aCBhIGhpZ2hlciBjb25maWRlbmNlIGFuZDxi cj4NCnRoZSBvbGQgcm91dGVzIGluIG90aGVyIEVTQURJIFJCcmlkZ2VzIGFyZSBvdmVyLXdyaXR0 ZW4uTmV3IHJvdXRlcyhNQUM8YnI+DQomcXVvdDtBJnF1b3Q7IGlzIHJlYWNoYWJsZSB2aWEgZWdy ZXNzIFJCcmlkZ2UgUkJ4KSBleGlzdCBhbmQgZnJhbWVzIGRlc3RpbmVkDQp0bzxicj4NCk1BQyAm cXVvdDtBJnF1b3Q7IGFyZSBub3QgYmxhY2sgaG9sZWQuPGJyPg0KPGJyPg0KQnV0IHdoYXQgaWYg dGhpcyBlbmQtc3RhdGlvbiBtb3ZlcyBGUk9NIGEgbGluayB3aGljaCBoYXMgUkJyaWRnZShSQjEp PGJyPg0Kd2l0aCBFU0FESSBzdXBwb3J0IFRPIGEgbGluayB3aGVyZSBSQnJpZGdlKFJCMikgZG9u b3QgaGF2ZSBFU0FESTxicj4NCnN1cHBvcnQuIElzIHRoZXJlIGFueSB3YXkgUkIxIGNhbiBub3Rp Znkgb3RoZXIgRVNBREkgaW1wbGVtZW50ZWQ8YnI+DQpSQnJpZGdlcyBpbiB0aGUgY2FtcHVzIHRv IGZsdXNoIHRoZSBvbGQgcm91dGUoTUFDICZxdW90O0EmcXVvdDsgaXMgcmVhY2hhYmxlDQp2aWE8 YnI+DQplZ3Jlc3MgUkIxKSBzbyB0aGF0IGZyYW1lcyBmb3IgTUFDICZxdW90O0EmcXVvdDsgYXJl IG5vdCBzZW5kIGRpcmVjdGx5DQp0byBSQjE8YnI+DQphbmQgYXJlIHJhdGhlciB0cmVhdGVkIGFz IHVua25vd24gdW5pY2FzdCBmcmFtZSBhbmQgc2VuZCBvbiBhIERUcmVlPzxicj4NCkNvdWxkIFJC MSBzZW5kIHRvIEVTQURJIEltcGxlbWVudGVkIFJCcmlkZ2VzIHRoYXQgTUFDICZxdW90O0EmcXVv dDsgaXMNCm5vIGxvbmdlcjxicj4NCnJlYWNoYWJsZSB2aWEgaXRzZWxmIGJ5IHNlbmRpbmcgY29u ZmlkZW5jZSBhcyAwIGZvciB0aGF0IE1BQyBpbiBpdHM8YnI+DQpFU0FESSBwZHVzPzxicj4NCjxi cj4NClBsZWFzZSBjb3JyZWN0IG1lIGlmIG15IHVuZGVyc3RhbmRpbmcgaXMgd3JvbmcuPGJyPg0K PGJyPg0KQWxzbyBjb3VsZCB3ZSByZWNvbW1lbmQgRVNBREkgaW1wbGVtZW50ZWQgUkJyaWRnZXMg dG8gYmVjb21lIERSQiBhbmQ8YnI+DQpzZXJ2ZSBtb3JlIEFGIGZvciB2bGFucy48YnI+DQo8YnI+ DQpFZGl0b3JpYWwgY29tbWVudHMgYW5kIHR5cG9zOjxicj4NCjxicj4NCkluIEFic3RyYWN0PGJy Pg0KRVNBREkgKEVuZCBTeXN0ZW0gQWRkcmVzcyBEaXN0cmlidXRpb24gSW5mb3JtYXRpb24pIHNo b3VsZCBiZSByZXBsYWNlZA0KYnk8YnI+DQpFU0FESSAoRW5kIFN0YXRpb24gQWRkcmVzcyBEaXN0 cmlidXRpb24gSW5mb3JtYXRpb24pIGFzIHBlciBSRkM2MzI1PGJyPg0KPGJyPg0KSW4gc2VjdGlv biAzLiBFU0FESSBEUkIgU3RhdGU8YnI+DQo4dGggbGluZTogJnF1b3Q7Zm9yIHdoaWNoIFJCMSBp cyBob2xkaW5nIGFuIEVTQURJLUxTUCB6ZXJvIHdpdGggYW4gRVNBREk8YnI+DQpQYXJhcm1ldGVy cyZxdW90OyAsIHR5cG8gZm9yICZxdW90O1BhcmFtZXRlcnMmcXVvdDs8YnI+DQo8YnI+DQo8YnI+ DQpJbiBzZWN0aW9uIDQuIEVTQURJIFBEVSBwcm9jZXNzaW5nPGJyPg0KNHRoIGxpbmU6ICZuYnNw OyAmbmJzcDsgJnF1b3Q7YXJlIG9ubHkgRUFTREktTFNQLCBFQVNESS1DU05QIGFuZCBFQVNESS1Q U05QDQpQRFVzIHVzZWQ8YnI+DQppbiBFU0FESS4mcXVvdDtzaG91bGQgYmUgY2hhbmdlZCB0bzxi cj4NCiAmbmJzcDsmcXVvdDthcmUgb25seSBFU0FESS1MU1AsIEVTQURJLUNTTlAgYW5kIEVTQURJ LVBTTlAgUERVcyB1c2VkIGluDQpFU0FESS4mcXVvdDs8YnI+DQo8YnI+DQpJbiBzZWN0aW9uIDQu MSBTZW5kaW5nIG9mIEVTQVNJIFBEVXM8YnI+DQo8YnI+DQpDaGFuZ2UgdGhlIHR5cG8gaW4gdGhl IGhlYWRlciBpdHNlbGYuPGJyPg0KPGJyPg0KNHRoIGxpbmU6ICZuYnNwOyAmbmJzcDsmcXVvdDs2 KElubnRlci5NYWNTQSkmcXVvdDsgdG8gJzYoSW5uZXIuTWFjU0EpJnF1b3Q7PGJyPg0KPGJyPg0K NXRoIGxpbmU6ICZuYnNwOyAmbmJzcDsgJnF1b3Q7c3RhcnRpbmcgd2l0aCB0aGUgSW50cmFkb21h aW4gUm91dGVpbmcgUHJvdG9jb2w8YnI+DQpEaXNjcmltaW5hdG9yLCZxdW90OyBUeXBvICZxdW90 O1JvdXRlaW5nJnF1b3Q7IHRvICZxdW90O1JvdXRpbmcmcXVvdDs8YnI+DQo8YnI+DQoybmQgUGFy YSwgMXN0IGxpbmU6ICZxdW90O09uY2UgYW4gRVNBREkgaW5zdGFuY2UgaXMgb3BlcmF0aW9uYWxs eSB1cCwgaXQ8YnI+DQptdWx0aWNhc3RzIGl0IHNlbGYtPGJyPg0KICZuYnNwO29yaWdpbmF0ZWQg TFNQIG51bWJlciB6ZXJvIG9uIHRoZSB2aXJ0dWFsIGxpbmsgdG8gYW5ub3VuY2UgaXRzIEVTQURJ PGJyPg0KICZuYnNwO3BhcmFtZXRlcnMuJnF1b3Q7ICZuYnNwOyBtYXkgYmUgY2hhbmdlZCB0bzxi cj4NCiZxdW90O09uY2UgYW4gRVNBREkgaW5zdGFuY2UgaXMgb3BlcmF0aW9uYWxseSB1cCwgaXQg bXVsdGljYXN0cy9zZW5kcyBpdHMNCnNlbGYtPGJyPg0KICZuYnNwO29yaWdpbmF0ZWQgTFNQIG51 bWJlciB6ZXJvIG9uIHRoZSB2aXJ0dWFsIGxpbmsgdG8gYW5ub3VuY2UgaXRzIEVTQURJPGJyPg0K ICZuYnNwO3BhcmFtZXRlcnMuJnF1b3Q7PGJyPg0KPGJyPg0KNXRoIFBhcmEsIDJuZCBsaW5lOiBU eXBvICZxdW90O0VBU0RJJnF1b3Q7PGJyPg0KPGJyPg0KSW4gc2VjdGlvbiA1LiBFU0FESS1MU1Ag Q29udGVudHM8YnI+DQo3dGggbGluZSB0eXBvICZxdW90O0VBU0RBSS1MU1BzPGJyPg0KPGJyPg0K SW4gc2VjdGlvbiA1LjEgRVNBREkgUGFyYW1ldGVyIERhdGE8YnI+DQo0dGggbGluZSB0eXBvICZx dW90O29jY3Vycm5jZSZxdW90Ozxicj4NCjxicj4NClRoYW5rIHlvdSw8YnI+DQpSZWdhcmRzLDxi cj4NClNvbW5hdGg8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+PHR0Pl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KdHJpbGwgbWFpbGluZyBs aXN0PC90dD48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHR0Pjx1Pjxicj4NCjwvdT48 L3R0PjwvZm9udD48YSBocmVmPW1haWx0bzp0cmlsbEBpZXRmLm9yZyB0YXJnZXQ9X2JsYW5rPjxm b250IHNpemU9MyBjb2xvcj1ibHVlPjx0dD48dT50cmlsbEBpZXRmLm9yZzwvdT48L3R0PjwvZm9u dD48L2E+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHR0Pjx1Pjxicj4NCjwvdT48L3R0PjwvZm9u dD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJpbGwgdGFy Z2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dHQ+PHU+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmlsbDwvdT48L3R0PjwvZm9udD48L2E+PGZvbnQgc2l6 ZT0zPjx0dD48YnI+DQo8L3R0PjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ PGJyPg0KPC9mb250Pg0KPGJyPg0KPGJyPg0K --=_alternative 002D3E9B482579E9_=-- From somnath.chatterjee01@gmail.com Mon Apr 23 01:40:03 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7BEA21F8642; Mon, 23 Apr 2012 01:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.189 X-Spam-Level: X-Spam-Status: No, score=0.189 tagged_above=-999 required=5 tests=[AWL=-1.062, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_75=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] 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 e9AOGlVhlWYp; Mon, 23 Apr 2012 01:40:02 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id CD39C21F863D; Mon, 23 Apr 2012 01:40:01 -0700 (PDT) Received: by yenm5 with SMTP id m5so6874323yen.31 for ; Mon, 23 Apr 2012 01:40:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ixTpmB1+qjksZRShe95lmDOjcG/FHEMSPlZKTTaKBdQ=; b=gQbBIfvCSBvK7wTZkgccKYlwfEfi3rkLxYy03p+DgU3AyVeZnK/p0GI9PNxeDRIogD Qw+VEqc6AdtP1+sw3BOtb0+GGzPzLnXLp9CZT/YUez1UUqgbM5LbOxM75U7nuez75Z76 h87rJTAartvKAi3lNukePZsO/Fq/9Krfr2EfY0Q2bmNrfs7hyLnC/Fr4jTkUrMXhoYoe h5HgfKTguKN/ShXUc2JdbPTAHeQqF7fLzdGMPsHOGeGV2VEigXe+DpApUGiWcR/5rC2j 3wljHc8+LIT9ZddvbC6HlMIMm4SB08iugJgQ7Emz1jrLQeBGyqByaCTyEcqEUozgTYSo Gr7w== MIME-Version: 1.0 Received: by 10.236.37.168 with SMTP id y28mr7567673yha.111.1335170401362; Mon, 23 Apr 2012 01:40:01 -0700 (PDT) Received: by 10.146.255.30 with HTTP; Mon, 23 Apr 2012 01:40:01 -0700 (PDT) In-Reply-To: References: Date: Mon, 23 Apr 2012 14:10:01 +0530 Message-ID: From: somnath chatterjee To: hu.fangwei@zte.com.cn Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: trill-bounces@ietf.org, trill@ietf.org Subject: Re: [trill] [rbridge] draft-hu-trill-rbridge-esadi-04 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 08:40:04 -0000 Hi , In introduction of draft-hu-trill-rbridge-esadi-04 " An RBridge that is announcing connectivity to VLAN-x (normally a VLAN-x appointed forwarder) MAY use the (ESADI) protocol to announce the end station address of some or all of its attached VLAN-x end nodes to other RBridges that are running ESADI for VLAN-x." An ESADI supported RBridge MAY selectively send about end-station MACs and MAY opt to not send all the end-station MACs. I am only suggesting to send MAC in updated ESADI-LSP with confidence zero(for every lost MAC), so that other ESADI RBridges could easily recognize that this MAC needs to be deleted, rather than compare it with previously stored information and then delete. Thank you, Regards, Somnath 2012/4/23 > > > Hi, chatterjee > > By my understanding, If RB1 supports ESADI, it advertises all the end-sta= tion MAC attached to the remote RBridges. > > The remote RBridge can do some policy forwarding based on the MAC address= , but I think it is no need to opt to send the end-station MAC by the local= RBridge. > > Regards > > > somnath chatterjee > > 2012-04-23 14:57 > > =CA=D5=BC=FE=C8=CB > hu.fangwei@zte.com.cn > =B3=AD=CB=CD > trill@ietf.org, trill-bounces@ietf.org > =D6=F7=CC=E2 > Re: [trill] [rbridge] draft-hu-trill-rbridge-esadi-04 > > > > > > Hi Fangwei, > > Thank you for the explanation. > > So, RB1 doesnot include the end-stations MAC in its LSP. What if RB1 has = opted not to send this end-station MAC in its ESADI-LSP earlier? The other = ESADI RBridges has no way to learn that this MAC has to be flushed(which ma= y be learned through other procedures except ESADI). It would be good if ES= ADI RBridges could explicitly tell other RBridges to forget a MAC. > > Regards, > Somnath > > 2012/4/22 > > Thanks for the reviewing and comments. > > Pls see the following in line. > > >Hi Authors, > > >I have read the draft-hu-trill-rbridge-esadi-04 and support it. > > >I have one question regarding the problem stated in the draft > > > " 2. Fast update advantages: ESADI protocol provides a fast update of > end nodes MAC (Media Access Control) addresses. If an end station > is unplugged from one RBridge and plugged into another, frames > addressed to that older RBridge can be black holed. They can be > sent just to the older RBridge that the end station was connected > to until cached address information at some remote RBridge times > out, possibly for tens of seconds [RFC6325]." > > >In this scenario when an end-station moves TO a link where an > >RBridge(RBx) with ESADI support is serving as AF for the vlan on which > >the end-station is connected, this RBridge sends the end-station MACs > >through ESADI pdu to other ESADI RBridges with a higher confidence and > >the old routes in other ESADI RBridges are over-written.New routes(MAC > >"A" is reachable via egress RBridge RBx) exist and frames destined to > >MAC "A" are not black holed. > > >But what if this end-station moves FROM a link which has RBridge(RB1) > >with ESADI support TO a link where RBridge(RB2) donot have ESADI > >support. Is there any way RB1 can notify other ESADI implemented > >RBridges in the campus to flush the old route(MAC "A" is reachable via > >egress RB1) so that frames for MAC "A" are not send directly to RB1 > >and are rather treated as unknown unicast frame and send on a DTree? > >Could RB1 send to ESADI Implemented RBridges that MAC "A" is no longer > >reachable via itself by sending confidence as 0 for that MAC in its > >ESADI pdus? > > [hfw] If RB1 notify that the end-station moves from the link, RB1 will up= date > > and flood the LSP originated with nulling out the end-station address. Wh= en other ESADI > > RBridge receives the updated LSP, they will forget the MAC "A" from its M= AC table. > > In this way, ESADI protocol can fast update the MAC table of remote RBrid= ges when the end station attached > > is unpluged or a new end station is pluged. > > > > >Please correct me if my understanding is wrong. > > >Also could we recommend ESADI implemented RBridges to become DRB and > >serve more AF for vlans. > > >Editorial comments and typos: > > >In Abstract > >ESADI (End System Address Distribution Information) should be replaced b= y > >ESADI (End Station Address Distribution Information) as per RFC6325 > > >In section 3. ESADI DRB State > >8th line: "for which RB1 is holding an ESADI-LSP zero with an ESADI > >Pararmeters" , typo for "Parameters" > > > >In section 4. ESADI PDU processing > >4th line: "are only EASDI-LSP, EASDI-CSNP and EASDI-PSNP PDUs used > >in ESADI."should be changed to > > "are only ESADI-LSP, ESADI-CSNP and ESADI-PSNP PDUs used in ESADI." > > >In section 4.1 Sending of ESASI PDUs > > >Change the typo in the header itself. > > >4th line: "6(Innter.MacSA)" to '6(Inner.MacSA)" > > >5th line: "starting with the Intradomain Routeing Protocol > >Discriminator," Typo "Routeing" to "Routing" > > >2nd Para, 1st line: "Once an ESADI instance is operationally up, it > >multicasts it self- > > originated LSP number zero on the virtual link to announce its ESADI > > parameters." may be changed to > >"Once an ESADI instance is operationally up, it multicasts/sends its sel= f- > > originated LSP number zero on the virtual link to announce its ESADI > > parameters." > > >5th Para, 2nd line: Typo "EASDI" > > >In section 5. ESADI-LSP Contents > >7th line typo "EASDAI-LSPs > > >In section 5.1 ESADI Parameter Data > >4th line typo "occurrnce" > > [hfw] Thanks for the correcting, we will correct it in the next version. > > > somnath chatterjee > =B7=A2=BC=FE=C8=CB: trill-bounces@ietf.org > > 2012-04-21 01:17 > > > =CA=D5=BC=FE=C8=CB > trill@ietf.org > =B3=AD=CB=CD > =D6=F7=CC=E2 > [trill] [rbridge] draft-hu-trill-rbridge-esadi-04 > > > > > > > > Hi Authors, > > I have read the draft-hu-trill-rbridge-esadi-04 and support it. > > I have one question regarding the problem stated in the draft > > " 2. Fast update advantages: ESADI protocol provides a fast update of > end nodes MAC (Media Access Control) addresses. If an end station > is unplugged from one RBridge and plugged into another, frames > addressed to that older RBridge can be black holed. They can be > sent just to the older RBridge that the end station was connected > to until cached address information at some remote RBridge times > out, possibly for tens of seconds [RFC6325]." > > In this scenario when an end-station moves TO a link where an > RBridge(RBx) with ESADI support is serving as AF for the vlan on which > the end-station is connected, this RBridge sends the end-station MACs > through ESADI pdu to other ESADI RBridges with a higher confidence and > the old routes in other ESADI RBridges are over-written.New routes(MAC > "A" is reachable via egress RBridge RBx) exist and frames destined to > MAC "A" are not black holed. > > But what if this end-station moves FROM a link which has RBridge(RB1) > with ESADI support TO a link where RBridge(RB2) donot have ESADI > support. Is there any way RB1 can notify other ESADI implemented > RBridges in the campus to flush the old route(MAC "A" is reachable via > egress RB1) so that frames for MAC "A" are not send directly to RB1 > and are rather treated as unknown unicast frame and send on a DTree? > Could RB1 send to ESADI Implemented RBridges that MAC "A" is no longer > reachable via itself by sending confidence as 0 for that MAC in its > ESADI pdus? > > Please correct me if my understanding is wrong. > > Also could we recommend ESADI implemented RBridges to become DRB and > serve more AF for vlans. > > Editorial comments and typos: > > In Abstract > ESADI (End System Address Distribution Information) should be replaced by > ESADI (End Station Address Distribution Information) as per RFC6325 > > In section 3. ESADI DRB State > 8th line: "for which RB1 is holding an ESADI-LSP zero with an ESADI > Pararmeters" , typo for "Parameters" > > > In section 4. ESADI PDU processing > 4th line: "are only EASDI-LSP, EASDI-CSNP and EASDI-PSNP PDUs used > in ESADI."should be changed to > "are only ESADI-LSP, ESADI-CSNP and ESADI-PSNP PDUs used in ESADI." > > In section 4.1 Sending of ESASI PDUs > > Change the typo in the header itself. > > 4th line: "6(Innter.MacSA)" to '6(Inner.MacSA)" > > 5th line: "starting with the Intradomain Routeing Protocol > Discriminator," Typo "Routeing" to "Routing" > > 2nd Para, 1st line: "Once an ESADI instance is operationally up, it > multicasts it self- > originated LSP number zero on the virtual link to announce its ESADI > parameters." may be changed to > "Once an ESADI instance is operationally up, it multicasts/sends its self= - > originated LSP number zero on the virtual link to announce its ESADI > parameters." > > 5th Para, 2nd line: Typo "EASDI" > > In section 5. ESADI-LSP Contents > 7th line typo "EASDAI-LSPs > > In section 5.1 ESADI Parameter Data > 4th line typo "occurrnce" > > Thank you, > Regards, > Somnath > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill > > > From zhai.hongjun@zte.com.cn Mon Apr 23 01:56:01 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 189F721F84B3; Mon, 23 Apr 2012 01:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.839 X-Spam-Level: X-Spam-Status: No, score=-93.839 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_75=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100, WEIRD_QUOTING=1.396] 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 WRfDGLF-kveE; Mon, 23 Apr 2012 01:55:58 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD5921F84B2; Mon, 23 Apr 2012 01:55:57 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 286201455586978; Mon, 23 Apr 2012 16:16:01 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 66762.2371961387; Mon, 23 Apr 2012 16:55:46 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q3N8teso026222; Mon, 23 Apr 2012 16:55:40 +0800 (GMT-8) (envelope-from zhai.hongjun@zte.com.cn) In-Reply-To: To: somnath chatterjee MIME-Version: 1.0 X-KeepSent: B526CAA7:09101149-482579E9:0030A556; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhai.hongjun@zte.com.cn Date: Mon, 23 Apr 2012 16:55:39 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-23 16:55:41, Serialize complete at 2012-04-23 16:55:41 Content-Type: multipart/alternative; boundary="=_alternative 003169C8482579E9_=" X-MAIL: mse01.zte.com.cn q3N8teso026222 Cc: trill-bounces@ietf.org, hu.fangwei@zte.com.cn, trill@ietf.org Subject: Re: [trill] [rbridge] draft-hu-trill-rbridge-esadi-04 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 08:56:01 -0000 This is a multipart message in MIME format. --=_alternative 003169C8482579E9_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 U2VlIGluLWxpbmUsIHBscy4NCg0KDQoNClRoYW5rcywNClpoYWkgSG9uZ2p1bg0KIiIiIiIiIiIi IiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIi IiIiIg0KIFByb3RvY29sIERldmVsb3BtZW50IERlcHQuVkksIENlbnRyYWwgUiZEIEluc3RpdHV0 ZSwgWlRFIENvcnBvcmF0aW9uDQogTm8uIDY4LCBaaWppbmdodWEgUm9hZCwgWXVodWF0YWkgRGlz dHJpY3QsIE5hbmppbmcsIFAuUi5DaGluYSwgMjEwMDEyDQogDQogWmhhaSBIb25nanVuDQogDQog VGVsOiArODYtMjUtNTI4NzczNDUNCiBFbWFpbDogemhhaS5ob25nanVuQHp0ZS5jb20uY24NCiIi IiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIi IiIiIiIiIiIiIiIiDQoNCg0KDQoNCg0Kc29tbmF0aCBjaGF0dGVyamVlIDxzb21uYXRoLmNoYXR0 ZXJqZWUwMUBnbWFpbC5jb20+IA0Kt6K8/sjLOiAgdHJpbGwtYm91bmNlc0BpZXRmLm9yZw0KMjAx Mi0wNC0yMyAxNjo0MA0KDQrK1bz+yMsNCmh1LmZhbmd3ZWlAenRlLmNvbS5jbg0Ks63LzQ0KdHJp bGwtYm91bmNlc0BpZXRmLm9yZywgdHJpbGxAaWV0Zi5vcmcNCtb3zOINClJlOiBbdHJpbGxdIFty YnJpZGdlXSBkcmFmdC1odS10cmlsbC1yYnJpZGdlLWVzYWRpLTA0DQoNCg0KDQoNCg0KDQogPiBI aSAsDQoNCj4gSW4gaW50cm9kdWN0aW9uIG9mIGRyYWZ0LWh1LXRyaWxsLXJicmlkZ2UtZXNhZGkt MDQNCj4gIiAgQW4gUkJyaWRnZSB0aGF0IGlzIGFubm91bmNpbmcgY29ubmVjdGl2aXR5IHRvIFZM QU4teCAobm9ybWFsbHkgYQ0KPiAgICBWTEFOLXggYXBwb2ludGVkIGZvcndhcmRlcikgTUFZIHVz ZSB0aGUgKEVTQURJKSBwcm90b2NvbCB0byBhbm5vdW5jZQ0KPiAgICB0aGUgZW5kIHN0YXRpb24g YWRkcmVzcyBvZiBzb21lIG9yIGFsbCBvZiBpdHMgYXR0YWNoZWQgVkxBTi14IGVuZA0KPiAgIG5v ZGVzIHRvIG90aGVyIFJCcmlkZ2VzIHRoYXQgYXJlIHJ1bm5pbmcgRVNBREkgZm9yIFZMQU4teC4i DQoNCj4gQW4gRVNBREkgc3VwcG9ydGVkIFJCcmlkZ2UgTUFZIHNlbGVjdGl2ZWx5IHNlbmQgYWJv dXQgZW5kLXN0YXRpb24gTUFDcw0KPiBhbmQgTUFZIG9wdCB0byBub3Qgc2VuZCBhbGwgdGhlIGVu ZC1zdGF0aW9uIE1BQ3MuDQoNCj4gSSBhbSBvbmx5IHN1Z2dlc3RpbmcgdG8gc2VuZCBNQUMgaW4g dXBkYXRlZCBFU0FESS1MU1Agd2l0aCBjb25maWRlbmNlDQo+IHplcm8oZm9yIGV2ZXJ5IGxvc3Qg TUFDKSwgc28gdGhhdCBvdGhlciBFU0FESSBSQnJpZGdlcyBjb3VsZCBlYXNpbHkNCj4gcmVjb2du aXplIHRoYXQgdGhpcyBNQUMgbmVlZHMgdG8gYmUgZGVsZXRlZCwgcmF0aGVyIHRoYW4gY29tcGFy ZSBpdA0KPiB3aXRoIHByZXZpb3VzbHkgc3RvcmVkIGluZm9ybWF0aW9uIGFuZCB0aGVuIGRlbGV0 ZS4NCg0KVGhhbmtzIGZvciB5b3VyIGdvb2Qgc3VnZ2VzdGlvbi4gSSB0aGluayBpdCBpcyBmZWFz aWJsZS4NCg0KDQpUaGFuayB5b3UsDQpSZWdhcmRzLA0KU29tbmF0aA0KDQoyMDEyLzQvMjMgPGh1 LmZhbmd3ZWlAenRlLmNvbS5jbj4NCj4NCj4NCj4gSGksIGNoYXR0ZXJqZWUNCj4NCj4gQnkgbXkg dW5kZXJzdGFuZGluZywgSWYgUkIxIHN1cHBvcnRzIEVTQURJLCBpdCBhZHZlcnRpc2VzIGFsbCB0 aGUgDQplbmQtc3RhdGlvbiBNQUMgYXR0YWNoZWQgdG8gdGhlIHJlbW90ZSBSQnJpZGdlcy4NCj4N Cj4gVGhlIHJlbW90ZSBSQnJpZGdlIGNhbiBkbyBzb21lIHBvbGljeSBmb3J3YXJkaW5nIGJhc2Vk IG9uIHRoZSBNQUMgDQphZGRyZXNzLCBidXQgSSB0aGluayBpdCBpcyBubyBuZWVkIHRvIG9wdCB0 byBzZW5kIHRoZSBlbmQtc3RhdGlvbiBNQUMgYnkgDQp0aGUgbG9jYWwgUkJyaWRnZS4NCj4NCj4g UmVnYXJkcw0KPg0KPg0KPiBzb21uYXRoIGNoYXR0ZXJqZWUgPHNvbW5hdGguY2hhdHRlcmplZTAx QGdtYWlsLmNvbT4NCj4NCj4gMjAxMi0wNC0yMyAxNDo1Nw0KPg0KPiDK1bz+yMsNCj4gaHUuZmFu Z3dlaUB6dGUuY29tLmNuDQo+ILOty80NCj4gdHJpbGxAaWV0Zi5vcmcsIHRyaWxsLWJvdW5jZXNA aWV0Zi5vcmcNCj4g1vfM4g0KPiBSZTogW3RyaWxsXSBbcmJyaWRnZV0gZHJhZnQtaHUtdHJpbGwt cmJyaWRnZS1lc2FkaS0wNA0KPg0KPg0KPg0KPg0KPg0KPiBIaSBGYW5nd2VpLA0KPg0KPiBUaGFu ayB5b3UgZm9yIHRoZSBleHBsYW5hdGlvbi4NCj4NCj4gU28sIFJCMSBkb2Vzbm90IGluY2x1ZGUg dGhlIGVuZC1zdGF0aW9ucyBNQUMgaW4gaXRzIExTUC4gV2hhdCBpZiBSQjEgaGFzIA0Kb3B0ZWQg bm90IHRvIHNlbmQgdGhpcyBlbmQtc3RhdGlvbiBNQUMgaW4gaXRzIEVTQURJLUxTUCBlYXJsaWVy PyBUaGUgb3RoZXIgDQpFU0FESSBSQnJpZGdlcyBoYXMgbm8gd2F5IHRvIGxlYXJuIHRoYXQgdGhp cyBNQUMgaGFzIHRvIGJlIGZsdXNoZWQod2hpY2ggDQptYXkgYmUgbGVhcm5lZCB0aHJvdWdoIG90 aGVyIHByb2NlZHVyZXMgZXhjZXB0IEVTQURJKS4gSXQgd291bGQgYmUgZ29vZCBpZiANCkVTQURJ IFJCcmlkZ2VzIGNvdWxkIGV4cGxpY2l0bHkgdGVsbCBvdGhlciBSQnJpZGdlcyB0byBmb3JnZXQg YSBNQUMuDQo+DQo+IFJlZ2FyZHMsDQo+IFNvbW5hdGgNCj4NCj4gMjAxMi80LzIyIDxodS5mYW5n d2VpQHp0ZS5jb20uY24+DQo+DQo+IFRoYW5rcyBmb3IgdGhlIHJldmlld2luZyBhbmQgY29tbWVu dHMuDQo+DQo+IFBscyBzZWUgdGhlIGZvbGxvd2luZyBpbiBsaW5lLg0KPg0KPiA+SGkgQXV0aG9y cywNCj4NCj4gPkkgaGF2ZSByZWFkIHRoZSBkcmFmdC1odS10cmlsbC1yYnJpZGdlLWVzYWRpLTA0 IGFuZCBzdXBwb3J0IGl0Lg0KPg0KPiA+SSBoYXZlIG9uZSBxdWVzdGlvbiByZWdhcmRpbmcgdGhl IHByb2JsZW0gc3RhdGVkIGluIHRoZSBkcmFmdA0KPg0KPiA+ICIgMi4gRmFzdCB1cGRhdGUgYWR2 YW50YWdlczogRVNBREkgcHJvdG9jb2wgcHJvdmlkZXMgYSBmYXN0IHVwZGF0ZSBvZg0KPiAgICAg ZW5kIG5vZGVzIE1BQyAoTWVkaWEgQWNjZXNzIENvbnRyb2wpIGFkZHJlc3Nlcy4gIElmIGFuIGVu ZCBzdGF0aW9uDQo+ICAgICBpcyB1bnBsdWdnZWQgZnJvbSBvbmUgUkJyaWRnZSBhbmQgcGx1Z2dl ZCBpbnRvIGFub3RoZXIsIGZyYW1lcw0KPiAgICAgYWRkcmVzc2VkIHRvIHRoYXQgb2xkZXIgUkJy aWRnZSBjYW4gYmUgYmxhY2sgaG9sZWQuICBUaGV5IGNhbiBiZQ0KPiAgICAgc2VudCBqdXN0IHRv IHRoZSBvbGRlciBSQnJpZGdlIHRoYXQgdGhlIGVuZCBzdGF0aW9uIHdhcyBjb25uZWN0ZWQNCj4g ICAgIHRvIHVudGlsIGNhY2hlZCBhZGRyZXNzIGluZm9ybWF0aW9uIGF0IHNvbWUgcmVtb3RlIFJC cmlkZ2UgdGltZXMNCj4gICAgIG91dCwgcG9zc2libHkgZm9yIHRlbnMgb2Ygc2Vjb25kcyBbUkZD NjMyNV0uIg0KPg0KPiA+SW4gdGhpcyBzY2VuYXJpbyB3aGVuIGFuIGVuZC1zdGF0aW9uIG1vdmVz IFRPIGEgbGluayB3aGVyZSBhbg0KPiA+UkJyaWRnZShSQngpIHdpdGggRVNBREkgc3VwcG9ydCBp cyBzZXJ2aW5nIGFzIEFGIGZvciB0aGUgdmxhbiBvbiB3aGljaA0KPiA+dGhlIGVuZC1zdGF0aW9u IGlzIGNvbm5lY3RlZCwgdGhpcyBSQnJpZGdlIHNlbmRzIHRoZSBlbmQtc3RhdGlvbiBNQUNzDQo+ ID50aHJvdWdoIEVTQURJIHBkdSB0byBvdGhlciBFU0FESSBSQnJpZGdlcyB3aXRoIGEgaGlnaGVy IGNvbmZpZGVuY2UgYW5kDQo+ID50aGUgb2xkIHJvdXRlcyBpbiBvdGhlciBFU0FESSBSQnJpZGdl cyBhcmUgb3Zlci13cml0dGVuLk5ldyByb3V0ZXMoTUFDDQo+ID4iQSIgaXMgcmVhY2hhYmxlIHZp YSBlZ3Jlc3MgUkJyaWRnZSBSQngpIGV4aXN0IGFuZCBmcmFtZXMgZGVzdGluZWQgdG8NCj4gPk1B QyAiQSIgYXJlIG5vdCBibGFjayBob2xlZC4NCj4NCj4gPkJ1dCB3aGF0IGlmIHRoaXMgZW5kLXN0 YXRpb24gbW92ZXMgRlJPTSBhIGxpbmsgd2hpY2ggaGFzIFJCcmlkZ2UoUkIxKQ0KPiA+d2l0aCBF U0FESSBzdXBwb3J0IFRPIGEgbGluayB3aGVyZSBSQnJpZGdlKFJCMikgZG9ub3QgaGF2ZSBFU0FE SQ0KPiA+c3VwcG9ydC4gSXMgdGhlcmUgYW55IHdheSBSQjEgY2FuIG5vdGlmeSBvdGhlciBFU0FE SSBpbXBsZW1lbnRlZA0KPiA+UkJyaWRnZXMgaW4gdGhlIGNhbXB1cyB0byBmbHVzaCB0aGUgb2xk IHJvdXRlKE1BQyAiQSIgaXMgcmVhY2hhYmxlIHZpYQ0KPiA+ZWdyZXNzIFJCMSkgc28gdGhhdCBm cmFtZXMgZm9yIE1BQyAiQSIgYXJlIG5vdCBzZW5kIGRpcmVjdGx5IHRvIFJCMQ0KPiA+YW5kIGFy ZSByYXRoZXIgdHJlYXRlZCBhcyB1bmtub3duIHVuaWNhc3QgZnJhbWUgYW5kIHNlbmQgb24gYSBE VHJlZT8NCj4gPkNvdWxkIFJCMSBzZW5kIHRvIEVTQURJIEltcGxlbWVudGVkIFJCcmlkZ2VzIHRo YXQgTUFDICJBIiBpcyBubyBsb25nZXINCj4gPnJlYWNoYWJsZSB2aWEgaXRzZWxmIGJ5IHNlbmRp bmcgY29uZmlkZW5jZSBhcyAwIGZvciB0aGF0IE1BQyBpbiBpdHMNCj4gPkVTQURJIHBkdXM/DQo+ DQo+IFtoZnddIElmIFJCMSBub3RpZnkgdGhhdCB0aGUgZW5kLXN0YXRpb24gbW92ZXMgZnJvbSB0 aGUgbGluaywgUkIxIHdpbGwgDQp1cGRhdGUNCj4NCj4gYW5kIGZsb29kIHRoZSBMU1Agb3JpZ2lu YXRlZCB3aXRoIG51bGxpbmcgb3V0IHRoZSBlbmQtc3RhdGlvbiBhZGRyZXNzLiANCldoZW4gb3Ro ZXIgRVNBREkNCj4NCj4gUkJyaWRnZSByZWNlaXZlcyB0aGUgdXBkYXRlZCBMU1AsIHRoZXkgd2ls bCBmb3JnZXQgdGhlIE1BQyAiQSIgZnJvbSBpdHMgDQpNQUMgdGFibGUuDQo+DQo+IEluIHRoaXMg d2F5LCBFU0FESSBwcm90b2NvbCBjYW4gZmFzdCB1cGRhdGUgdGhlIE1BQyB0YWJsZSBvZiByZW1v dGUgDQpSQnJpZGdlcyB3aGVuIHRoZSBlbmQgc3RhdGlvbiBhdHRhY2hlZA0KPg0KPiBpcyB1bnBs dWdlZCBvciBhIG5ldyBlbmQgc3RhdGlvbiBpcyBwbHVnZWQuDQo+DQo+DQo+DQo+ID5QbGVhc2Ug Y29ycmVjdCBtZSBpZiBteSB1bmRlcnN0YW5kaW5nIGlzIHdyb25nLg0KPg0KPiA+QWxzbyBjb3Vs ZCB3ZSByZWNvbW1lbmQgRVNBREkgaW1wbGVtZW50ZWQgUkJyaWRnZXMgdG8gYmVjb21lIERSQiBh bmQNCj4gPnNlcnZlIG1vcmUgQUYgZm9yIHZsYW5zLg0KPg0KPiA+RWRpdG9yaWFsIGNvbW1lbnRz IGFuZCB0eXBvczoNCj4NCj4gPkluIEFic3RyYWN0DQo+ID5FU0FESSAoRW5kIFN5c3RlbSBBZGRy ZXNzIERpc3RyaWJ1dGlvbiBJbmZvcm1hdGlvbikgc2hvdWxkIGJlIHJlcGxhY2VkIA0KYnkNCj4g PkVTQURJIChFbmQgU3RhdGlvbiBBZGRyZXNzIERpc3RyaWJ1dGlvbiBJbmZvcm1hdGlvbikgYXMg cGVyIFJGQzYzMjUNCj4NCj4gPkluIHNlY3Rpb24gMy4gRVNBREkgRFJCIFN0YXRlDQo+ID44dGgg bGluZTogImZvciB3aGljaCBSQjEgaXMgaG9sZGluZyBhbiBFU0FESS1MU1AgemVybyB3aXRoIGFu IEVTQURJDQo+ID5QYXJhcm1ldGVycyIgLCB0eXBvIGZvciAiUGFyYW1ldGVycyINCj4NCj4NCj4g PkluIHNlY3Rpb24gNC4gRVNBREkgUERVIHByb2Nlc3NpbmcNCj4gPjR0aCBsaW5lOiAgICAgImFy ZSBvbmx5IEVBU0RJLUxTUCwgRUFTREktQ1NOUCBhbmQgRUFTREktUFNOUCBQRFVzIHVzZWQNCj4g PmluIEVTQURJLiJzaG91bGQgYmUgY2hhbmdlZCB0bw0KPiA+ICAgImFyZSBvbmx5IEVTQURJLUxT UCwgRVNBREktQ1NOUCBhbmQgRVNBREktUFNOUCBQRFVzIHVzZWQgaW4gRVNBREkuIg0KPg0KPiA+ SW4gc2VjdGlvbiA0LjEgU2VuZGluZyBvZiBFU0FTSSBQRFVzDQo+DQo+ID5DaGFuZ2UgdGhlIHR5 cG8gaW4gdGhlIGhlYWRlciBpdHNlbGYuDQo+DQo+ID40dGggbGluZTogICAgIjYoSW5udGVyLk1h Y1NBKSIgdG8gJzYoSW5uZXIuTWFjU0EpIg0KPg0KPiA+NXRoIGxpbmU6ICAgICAic3RhcnRpbmcg d2l0aCB0aGUgSW50cmFkb21haW4gUm91dGVpbmcgUHJvdG9jb2wNCj4gPkRpc2NyaW1pbmF0b3Is IiBUeXBvICJSb3V0ZWluZyIgdG8gIlJvdXRpbmciDQo+DQo+ID4ybmQgUGFyYSwgMXN0IGxpbmU6 ICJPbmNlIGFuIEVTQURJIGluc3RhbmNlIGlzIG9wZXJhdGlvbmFsbHkgdXAsIGl0DQo+ID5tdWx0 aWNhc3RzIGl0IHNlbGYtDQo+ID4gIG9yaWdpbmF0ZWQgTFNQIG51bWJlciB6ZXJvIG9uIHRoZSB2 aXJ0dWFsIGxpbmsgdG8gYW5ub3VuY2UgaXRzIEVTQURJDQo+ID4gIHBhcmFtZXRlcnMuIiAgIG1h eSBiZSBjaGFuZ2VkIHRvDQo+ID4iT25jZSBhbiBFU0FESSBpbnN0YW5jZSBpcyBvcGVyYXRpb25h bGx5IHVwLCBpdCBtdWx0aWNhc3RzL3NlbmRzIGl0cyANCnNlbGYtDQo+ID4gICBvcmlnaW5hdGVk IExTUCBudW1iZXIgemVybyBvbiB0aGUgdmlydHVhbCBsaW5rIHRvIGFubm91bmNlIGl0cyBFU0FE SQ0KPiA+ICAgcGFyYW1ldGVycy4iDQo+DQo+ID41dGggUGFyYSwgMm5kIGxpbmU6IFR5cG8gIkVB U0RJIg0KPg0KPiA+SW4gc2VjdGlvbiA1LiBFU0FESS1MU1AgQ29udGVudHMNCj4gPjd0aCBsaW5l IHR5cG8gIkVBU0RBSS1MU1BzDQo+DQo+ID5JbiBzZWN0aW9uIDUuMSBFU0FESSBQYXJhbWV0ZXIg RGF0YQ0KPiA+NHRoIGxpbmUgdHlwbyAib2NjdXJybmNlIg0KPg0KPiBbaGZ3XSBUaGFua3MgZm9y IHRoZSBjb3JyZWN0aW5nLCB3ZSB3aWxsIGNvcnJlY3QgaXQgaW4gdGhlIG5leHQgdmVyc2lvbi4N Cj4NCj4NCj4gc29tbmF0aCBjaGF0dGVyamVlIDxzb21uYXRoLmNoYXR0ZXJqZWUwMUBnbWFpbC5j b20+DQo+ILeivP7IyzogIHRyaWxsLWJvdW5jZXNAaWV0Zi5vcmcNCj4NCj4gMjAxMi0wNC0yMSAw MToxNw0KPg0KPg0KPiDK1bz+yMsNCj4gdHJpbGxAaWV0Zi5vcmcNCj4gs63LzQ0KPiDW98ziDQo+ IFt0cmlsbF0gW3JicmlkZ2VdIGRyYWZ0LWh1LXRyaWxsLXJicmlkZ2UtZXNhZGktMDQNCj4NCj4N Cj4NCj4NCj4NCj4NCj4NCj4gSGkgQXV0aG9ycywNCj4NCj4gSSBoYXZlIHJlYWQgdGhlIGRyYWZ0 LWh1LXRyaWxsLXJicmlkZ2UtZXNhZGktMDQgYW5kIHN1cHBvcnQgaXQuDQo+DQo+IEkgaGF2ZSBv bmUgcXVlc3Rpb24gcmVnYXJkaW5nIHRoZSBwcm9ibGVtIHN0YXRlZCBpbiB0aGUgZHJhZnQNCj4N Cj4gIiAyLiBGYXN0IHVwZGF0ZSBhZHZhbnRhZ2VzOiBFU0FESSBwcm90b2NvbCBwcm92aWRlcyBh IGZhc3QgdXBkYXRlIG9mDQo+ICAgICBlbmQgbm9kZXMgTUFDIChNZWRpYSBBY2Nlc3MgQ29udHJv bCkgYWRkcmVzc2VzLiAgSWYgYW4gZW5kIHN0YXRpb24NCj4gICAgIGlzIHVucGx1Z2dlZCBmcm9t IG9uZSBSQnJpZGdlIGFuZCBwbHVnZ2VkIGludG8gYW5vdGhlciwgZnJhbWVzDQo+ICAgICBhZGRy ZXNzZWQgdG8gdGhhdCBvbGRlciBSQnJpZGdlIGNhbiBiZSBibGFjayBob2xlZC4gIFRoZXkgY2Fu IGJlDQo+ICAgICBzZW50IGp1c3QgdG8gdGhlIG9sZGVyIFJCcmlkZ2UgdGhhdCB0aGUgZW5kIHN0 YXRpb24gd2FzIGNvbm5lY3RlZA0KPiAgICAgdG8gdW50aWwgY2FjaGVkIGFkZHJlc3MgaW5mb3Jt YXRpb24gYXQgc29tZSByZW1vdGUgUkJyaWRnZSB0aW1lcw0KPiAgICAgb3V0LCBwb3NzaWJseSBm b3IgdGVucyBvZiBzZWNvbmRzIFtSRkM2MzI1XS4iDQo+DQo+IEluIHRoaXMgc2NlbmFyaW8gd2hl biBhbiBlbmQtc3RhdGlvbiBtb3ZlcyBUTyBhIGxpbmsgd2hlcmUgYW4NCj4gUkJyaWRnZShSQngp IHdpdGggRVNBREkgc3VwcG9ydCBpcyBzZXJ2aW5nIGFzIEFGIGZvciB0aGUgdmxhbiBvbiB3aGlj aA0KPiB0aGUgZW5kLXN0YXRpb24gaXMgY29ubmVjdGVkLCB0aGlzIFJCcmlkZ2Ugc2VuZHMgdGhl IGVuZC1zdGF0aW9uIE1BQ3MNCj4gdGhyb3VnaCBFU0FESSBwZHUgdG8gb3RoZXIgRVNBREkgUkJy aWRnZXMgd2l0aCBhIGhpZ2hlciBjb25maWRlbmNlIGFuZA0KPiB0aGUgb2xkIHJvdXRlcyBpbiBv dGhlciBFU0FESSBSQnJpZGdlcyBhcmUgb3Zlci13cml0dGVuLk5ldyByb3V0ZXMoTUFDDQo+ICJB IiBpcyByZWFjaGFibGUgdmlhIGVncmVzcyBSQnJpZGdlIFJCeCkgZXhpc3QgYW5kIGZyYW1lcyBk ZXN0aW5lZCB0bw0KPiBNQUMgIkEiIGFyZSBub3QgYmxhY2sgaG9sZWQuDQo+DQo+IEJ1dCB3aGF0 IGlmIHRoaXMgZW5kLXN0YXRpb24gbW92ZXMgRlJPTSBhIGxpbmsgd2hpY2ggaGFzIFJCcmlkZ2Uo UkIxKQ0KPiB3aXRoIEVTQURJIHN1cHBvcnQgVE8gYSBsaW5rIHdoZXJlIFJCcmlkZ2UoUkIyKSBk b25vdCBoYXZlIEVTQURJDQo+IHN1cHBvcnQuIElzIHRoZXJlIGFueSB3YXkgUkIxIGNhbiBub3Rp Znkgb3RoZXIgRVNBREkgaW1wbGVtZW50ZWQNCj4gUkJyaWRnZXMgaW4gdGhlIGNhbXB1cyB0byBm bHVzaCB0aGUgb2xkIHJvdXRlKE1BQyAiQSIgaXMgcmVhY2hhYmxlIHZpYQ0KPiBlZ3Jlc3MgUkIx KSBzbyB0aGF0IGZyYW1lcyBmb3IgTUFDICJBIiBhcmUgbm90IHNlbmQgZGlyZWN0bHkgdG8gUkIx DQo+IGFuZCBhcmUgcmF0aGVyIHRyZWF0ZWQgYXMgdW5rbm93biB1bmljYXN0IGZyYW1lIGFuZCBz ZW5kIG9uIGEgRFRyZWU/DQo+IENvdWxkIFJCMSBzZW5kIHRvIEVTQURJIEltcGxlbWVudGVkIFJC cmlkZ2VzIHRoYXQgTUFDICJBIiBpcyBubyBsb25nZXINCj4gcmVhY2hhYmxlIHZpYSBpdHNlbGYg Ynkgc2VuZGluZyBjb25maWRlbmNlIGFzIDAgZm9yIHRoYXQgTUFDIGluIGl0cw0KPiBFU0FESSBw ZHVzPw0KPg0KPiBQbGVhc2UgY29ycmVjdCBtZSBpZiBteSB1bmRlcnN0YW5kaW5nIGlzIHdyb25n Lg0KPg0KPiBBbHNvIGNvdWxkIHdlIHJlY29tbWVuZCBFU0FESSBpbXBsZW1lbnRlZCBSQnJpZGdl cyB0byBiZWNvbWUgRFJCIGFuZA0KPiBzZXJ2ZSBtb3JlIEFGIGZvciB2bGFucy4NCj4NCj4gRWRp dG9yaWFsIGNvbW1lbnRzIGFuZCB0eXBvczoNCj4NCj4gSW4gQWJzdHJhY3QNCj4gRVNBREkgKEVu ZCBTeXN0ZW0gQWRkcmVzcyBEaXN0cmlidXRpb24gSW5mb3JtYXRpb24pIHNob3VsZCBiZSByZXBs YWNlZCANCmJ5DQo+IEVTQURJIChFbmQgU3RhdGlvbiBBZGRyZXNzIERpc3RyaWJ1dGlvbiBJbmZv cm1hdGlvbikgYXMgcGVyIFJGQzYzMjUNCj4NCj4gSW4gc2VjdGlvbiAzLiBFU0FESSBEUkIgU3Rh dGUNCj4gOHRoIGxpbmU6ICJmb3Igd2hpY2ggUkIxIGlzIGhvbGRpbmcgYW4gRVNBREktTFNQIHpl cm8gd2l0aCBhbiBFU0FESQ0KPiBQYXJhcm1ldGVycyIgLCB0eXBvIGZvciAiUGFyYW1ldGVycyIN Cj4NCj4NCj4gSW4gc2VjdGlvbiA0LiBFU0FESSBQRFUgcHJvY2Vzc2luZw0KPiA0dGggbGluZTog ICAgICJhcmUgb25seSBFQVNESS1MU1AsIEVBU0RJLUNTTlAgYW5kIEVBU0RJLVBTTlAgUERVcyB1 c2VkDQo+IGluIEVTQURJLiJzaG91bGQgYmUgY2hhbmdlZCB0bw0KPiAgImFyZSBvbmx5IEVTQURJ LUxTUCwgRVNBREktQ1NOUCBhbmQgRVNBREktUFNOUCBQRFVzIHVzZWQgaW4gRVNBREkuIg0KPg0K PiBJbiBzZWN0aW9uIDQuMSBTZW5kaW5nIG9mIEVTQVNJIFBEVXMNCj4NCj4gQ2hhbmdlIHRoZSB0 eXBvIGluIHRoZSBoZWFkZXIgaXRzZWxmLg0KPg0KPiA0dGggbGluZTogICAgIjYoSW5udGVyLk1h Y1NBKSIgdG8gJzYoSW5uZXIuTWFjU0EpIg0KPg0KPiA1dGggbGluZTogICAgICJzdGFydGluZyB3 aXRoIHRoZSBJbnRyYWRvbWFpbiBSb3V0ZWluZyBQcm90b2NvbA0KPiBEaXNjcmltaW5hdG9yLCIg VHlwbyAiUm91dGVpbmciIHRvICJSb3V0aW5nIg0KPg0KPiAybmQgUGFyYSwgMXN0IGxpbmU6ICJP bmNlIGFuIEVTQURJIGluc3RhbmNlIGlzIG9wZXJhdGlvbmFsbHkgdXAsIGl0DQo+IG11bHRpY2Fz dHMgaXQgc2VsZi0NCj4gIG9yaWdpbmF0ZWQgTFNQIG51bWJlciB6ZXJvIG9uIHRoZSB2aXJ0dWFs IGxpbmsgdG8gYW5ub3VuY2UgaXRzIEVTQURJDQo+ICBwYXJhbWV0ZXJzLiIgICBtYXkgYmUgY2hh bmdlZCB0bw0KPiAiT25jZSBhbiBFU0FESSBpbnN0YW5jZSBpcyBvcGVyYXRpb25hbGx5IHVwLCBp dCBtdWx0aWNhc3RzL3NlbmRzIGl0cyANCnNlbGYtDQo+ICBvcmlnaW5hdGVkIExTUCBudW1iZXIg emVybyBvbiB0aGUgdmlydHVhbCBsaW5rIHRvIGFubm91bmNlIGl0cyBFU0FESQ0KPiAgcGFyYW1l dGVycy4iDQo+DQo+IDV0aCBQYXJhLCAybmQgbGluZTogVHlwbyAiRUFTREkiDQo+DQo+IEluIHNl Y3Rpb24gNS4gRVNBREktTFNQIENvbnRlbnRzDQo+IDd0aCBsaW5lIHR5cG8gIkVBU0RBSS1MU1Bz DQo+DQo+IEluIHNlY3Rpb24gNS4xIEVTQURJIFBhcmFtZXRlciBEYXRhDQo+IDR0aCBsaW5lIHR5 cG8gIm9jY3Vycm5jZSINCj4NCj4gVGhhbmsgeW91LA0KPiBSZWdhcmRzLA0KPiBTb21uYXRoDQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHRyaWxs IG1haWxpbmcgbGlzdA0KPiB0cmlsbEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3RyaWxsDQo+DQo+DQo+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KdHJpbGwgbWFpbGluZyBsaXN0DQp0cmlsbEBpZXRmLm9y Zw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmlsbA0KDQoNCg== --=_alternative 003169C8482579E9_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlNlZSBpbi1saW5lLCBwbHMuPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8YnI+DQo8YnI+ DQpUaGFua3MsPGJyPg0KWmhhaSBIb25nanVuPGJyPg0KJnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7 JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1 b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7 JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1 b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7 JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1 b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7 JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7PGJy Pg0KIFByb3RvY29sIERldmVsb3BtZW50IERlcHQuVkksIENlbnRyYWwgUiZhbXA7RCBJbnN0aXR1 dGUsIFpURSBDb3Jwb3JhdGlvbjxicj4NCiBOby4gNjgsIFppamluZ2h1YSBSb2FkLCBZdWh1YXRh aSBEaXN0cmljdCwgTmFuamluZywgUC5SLkNoaW5hLCAyMTAwMTI8YnI+DQogPGJyPg0KIFpoYWkg SG9uZ2p1bjxicj4NCiA8YnI+DQogVGVsOiArODYtMjUtNTI4NzczNDU8YnI+DQogRW1haWw6IHpo YWkuaG9uZ2p1bkB6dGUuY29tLmNuPGJyPg0KJnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7 JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1 b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7 JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1 b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7 JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1 b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7 JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7PGJy Pg0KPGJyPg0KPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0zNiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPjxiPnNvbW5hdGggY2hhdHRlcmplZSAmbHQ7c29tbmF0aC5jaGF0dGVyamVlMDFAZ21haWwu Y29tJmd0OzwvYj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ t6K8/sjLOiAmbmJzcDt0cmlsbC1ib3VuY2VzQGlldGYub3JnPC9mb250Pg0KPHA+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTItMDQtMjMgMTY6NDA8L2ZvbnQ+DQo8dGQgd2lkdGg9 NjMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxp Z249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rp dj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+aHUuZmFuZ3dlaUB6dGUuY29t LmNuPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj50cmlsbC1ib3VuY2VzQGlldGYub3JnLCB0cmlsbEBpZXRm Lm9yZzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFt0cmlsbF0gW3JicmlkZ2VdIGRyYWZ0LWh1LXRy aWxsLXJicmlkZ2UtZXNhZGktMDQ8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2 YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZuYnNwOyZndDsgSGkgLDxicj4NCjxicj4NCiZndDsgSW4g aW50cm9kdWN0aW9uIG9mIGRyYWZ0LWh1LXRyaWxsLXJicmlkZ2UtZXNhZGktMDQ8YnI+DQomZ3Q7 ICZxdW90OyAmbmJzcDtBbiBSQnJpZGdlIHRoYXQgaXMgYW5ub3VuY2luZyBjb25uZWN0aXZpdHkg dG8gVkxBTi14DQoobm9ybWFsbHkgYTxicj4NCiZndDsgJm5ic3A7ICZuYnNwO1ZMQU4teCBhcHBv aW50ZWQgZm9yd2FyZGVyKSBNQVkgdXNlIHRoZSAoRVNBREkpIHByb3RvY29sDQp0byBhbm5vdW5j ZTxicj4NCiZndDsgJm5ic3A7ICZuYnNwO3RoZSBlbmQgc3RhdGlvbiBhZGRyZXNzIG9mIHNvbWUg b3IgYWxsIG9mIGl0cyBhdHRhY2hlZA0KVkxBTi14IGVuZDxicj4NCiZndDsgJm5ic3A7IG5vZGVz IHRvIG90aGVyIFJCcmlkZ2VzIHRoYXQgYXJlIHJ1bm5pbmcgRVNBREkgZm9yIFZMQU4teC4mcXVv dDs8YnI+DQo8YnI+DQomZ3Q7IEFuIEVTQURJIHN1cHBvcnRlZCBSQnJpZGdlIE1BWSBzZWxlY3Rp dmVseSBzZW5kIGFib3V0IGVuZC1zdGF0aW9uDQpNQUNzPGJyPg0KJmd0OyBhbmQgTUFZIG9wdCB0 byBub3Qgc2VuZCBhbGwgdGhlIGVuZC1zdGF0aW9uIE1BQ3MuPGJyPg0KPGJyPg0KJmd0OyBJIGFt IG9ubHkgc3VnZ2VzdGluZyB0byBzZW5kIE1BQyBpbiB1cGRhdGVkIEVTQURJLUxTUCB3aXRoIGNv bmZpZGVuY2U8YnI+DQomZ3Q7IHplcm8oZm9yIGV2ZXJ5IGxvc3QgTUFDKSwgc28gdGhhdCBvdGhl ciBFU0FESSBSQnJpZGdlcyBjb3VsZCBlYXNpbHk8YnI+DQomZ3Q7IHJlY29nbml6ZSB0aGF0IHRo aXMgTUFDIG5lZWRzIHRvIGJlIGRlbGV0ZWQsIHJhdGhlciB0aGFuIGNvbXBhcmUgaXQ8YnI+DQom Z3Q7IHdpdGggcHJldmlvdXNseSBzdG9yZWQgaW5mb3JtYXRpb24gYW5kIHRoZW4gZGVsZXRlLjwv Zm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+VGhhbmtzIGZvciB5b3VyIGdv b2Qgc3VnZ2VzdGlvbi4gSSB0aGluayBpdCBpcyBmZWFzaWJsZS48L2ZvbnQ+PC90dD4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCjxicj4NClRoYW5rIHlvdSw8YnI+DQpSZWdhcmRzLDxicj4N ClNvbW5hdGg8YnI+DQo8YnI+DQoyMDEyLzQvMjMgJmx0O2h1LmZhbmd3ZWlAenRlLmNvbS5jbiZn dDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgSGksIGNoYXR0ZXJqZWU8YnI+DQomZ3Q7 PGJyPg0KJmd0OyBCeSBteSB1bmRlcnN0YW5kaW5nLCBJZiBSQjEgc3VwcG9ydHMgRVNBREksIGl0 IGFkdmVydGlzZXMgYWxsIHRoZQ0KZW5kLXN0YXRpb24gTUFDIGF0dGFjaGVkIHRvIHRoZSByZW1v dGUgUkJyaWRnZXMuPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlIHJlbW90ZSBSQnJpZGdlIGNhbiBk byBzb21lIHBvbGljeSBmb3J3YXJkaW5nIGJhc2VkIG9uIHRoZSBNQUMNCmFkZHJlc3MsIGJ1dCBJ IHRoaW5rIGl0IGlzIG5vIG5lZWQgdG8gb3B0IHRvIHNlbmQgdGhlIGVuZC1zdGF0aW9uIE1BQyBi eQ0KdGhlIGxvY2FsIFJCcmlkZ2UuPGJyPg0KJmd0Ozxicj4NCiZndDsgUmVnYXJkczxicj4NCiZn dDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBzb21uYXRoIGNoYXR0ZXJqZWUgJmx0O3NvbW5hdGguY2hh dHRlcmplZTAxQGdtYWlsLmNvbSZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAyMDEyLTA0LTIzIDE0 OjU3PGJyPg0KJmd0Ozxicj4NCiZndDsgytW8/sjLPGJyPg0KJmd0OyBodS5mYW5nd2VpQHp0ZS5j b20uY248YnI+DQomZ3Q7ILOty808YnI+DQomZ3Q7IHRyaWxsQGlldGYub3JnLCB0cmlsbC1ib3Vu Y2VzQGlldGYub3JnPGJyPg0KJmd0OyDW98ziPGJyPg0KJmd0OyBSZTogW3RyaWxsXSBbcmJyaWRn ZV0gZHJhZnQtaHUtdHJpbGwtcmJyaWRnZS1lc2FkaS0wNDxicj4NCiZndDs8YnI+DQomZ3Q7PGJy Pg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBIaSBGYW5nd2VpLDxicj4NCiZn dDs8YnI+DQomZ3Q7IFRoYW5rIHlvdSBmb3IgdGhlIGV4cGxhbmF0aW9uLjxicj4NCiZndDs8YnI+ DQomZ3Q7IFNvLCBSQjEgZG9lc25vdCBpbmNsdWRlIHRoZSBlbmQtc3RhdGlvbnMgTUFDIGluIGl0 cyBMU1AuIFdoYXQgaWYgUkIxDQpoYXMgb3B0ZWQgbm90IHRvIHNlbmQgdGhpcyBlbmQtc3RhdGlv biBNQUMgaW4gaXRzIEVTQURJLUxTUCBlYXJsaWVyPyBUaGUNCm90aGVyIEVTQURJIFJCcmlkZ2Vz IGhhcyBubyB3YXkgdG8gbGVhcm4gdGhhdCB0aGlzIE1BQyBoYXMgdG8gYmUgZmx1c2hlZCh3aGlj aA0KbWF5IGJlIGxlYXJuZWQgdGhyb3VnaCBvdGhlciBwcm9jZWR1cmVzIGV4Y2VwdCBFU0FESSku IEl0IHdvdWxkIGJlIGdvb2QNCmlmIEVTQURJIFJCcmlkZ2VzIGNvdWxkIGV4cGxpY2l0bHkgdGVs bCBvdGhlciBSQnJpZGdlcyB0byBmb3JnZXQgYSBNQUMuPGJyPg0KJmd0Ozxicj4NCiZndDsgUmVn YXJkcyw8YnI+DQomZ3Q7IFNvbW5hdGg8YnI+DQomZ3Q7PGJyPg0KJmd0OyAyMDEyLzQvMjIgJmx0 O2h1LmZhbmd3ZWlAenRlLmNvbS5jbiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGFua3MgZm9y IHRoZSByZXZpZXdpbmcgYW5kIGNvbW1lbnRzLjxicj4NCiZndDs8YnI+DQomZ3Q7IFBscyBzZWUg dGhlIGZvbGxvd2luZyBpbiBsaW5lLjxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDtIaSBBdXRob3Jz LDxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDtJIGhhdmUgcmVhZCB0aGUgZHJhZnQtaHUtdHJpbGwt cmJyaWRnZS1lc2FkaS0wNCBhbmQgc3VwcG9ydCBpdC48YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7 SSBoYXZlIG9uZSBxdWVzdGlvbiByZWdhcmRpbmcgdGhlIHByb2JsZW0gc3RhdGVkIGluIHRoZSBk cmFmdDxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsgJnF1b3Q7IDIuIEZhc3QgdXBkYXRlIGFkdmFu dGFnZXM6IEVTQURJIHByb3RvY29sIHByb3ZpZGVzIGEgZmFzdA0KdXBkYXRlIG9mPGJyPg0KJmd0 OyAmbmJzcDsgJm5ic3A7IGVuZCBub2RlcyBNQUMgKE1lZGlhIEFjY2VzcyBDb250cm9sKSBhZGRy ZXNzZXMuICZuYnNwO0lmDQphbiBlbmQgc3RhdGlvbjxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBp cyB1bnBsdWdnZWQgZnJvbSBvbmUgUkJyaWRnZSBhbmQgcGx1Z2dlZCBpbnRvIGFub3RoZXIsDQpm cmFtZXM8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgYWRkcmVzc2VkIHRvIHRoYXQgb2xkZXIgUkJy aWRnZSBjYW4gYmUgYmxhY2sgaG9sZWQuDQombmJzcDtUaGV5IGNhbiBiZTxicj4NCiZndDsgJm5i c3A7ICZuYnNwOyBzZW50IGp1c3QgdG8gdGhlIG9sZGVyIFJCcmlkZ2UgdGhhdCB0aGUgZW5kIHN0 YXRpb24NCndhcyBjb25uZWN0ZWQ8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgdG8gdW50aWwgY2Fj aGVkIGFkZHJlc3MgaW5mb3JtYXRpb24gYXQgc29tZSByZW1vdGUgUkJyaWRnZQ0KdGltZXM8YnI+ DQomZ3Q7ICZuYnNwOyAmbmJzcDsgb3V0LCBwb3NzaWJseSBmb3IgdGVucyBvZiBzZWNvbmRzIFtS RkM2MzI1XS4mcXVvdDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7SW4gdGhpcyBzY2VuYXJpbyB3 aGVuIGFuIGVuZC1zdGF0aW9uIG1vdmVzIFRPIGEgbGluayB3aGVyZSBhbjxicj4NCiZndDsgJmd0 O1JCcmlkZ2UoUkJ4KSB3aXRoIEVTQURJIHN1cHBvcnQgaXMgc2VydmluZyBhcyBBRiBmb3IgdGhl IHZsYW4NCm9uIHdoaWNoPGJyPg0KJmd0OyAmZ3Q7dGhlIGVuZC1zdGF0aW9uIGlzIGNvbm5lY3Rl ZCwgdGhpcyBSQnJpZGdlIHNlbmRzIHRoZSBlbmQtc3RhdGlvbg0KTUFDczxicj4NCiZndDsgJmd0 O3Rocm91Z2ggRVNBREkgcGR1IHRvIG90aGVyIEVTQURJIFJCcmlkZ2VzIHdpdGggYSBoaWdoZXIg Y29uZmlkZW5jZQ0KYW5kPGJyPg0KJmd0OyAmZ3Q7dGhlIG9sZCByb3V0ZXMgaW4gb3RoZXIgRVNB REkgUkJyaWRnZXMgYXJlIG92ZXItd3JpdHRlbi5OZXcgcm91dGVzKE1BQzxicj4NCiZndDsgJmd0 OyZxdW90O0EmcXVvdDsgaXMgcmVhY2hhYmxlIHZpYSBlZ3Jlc3MgUkJyaWRnZSBSQngpIGV4aXN0 IGFuZCBmcmFtZXMNCmRlc3RpbmVkIHRvPGJyPg0KJmd0OyAmZ3Q7TUFDICZxdW90O0EmcXVvdDsg YXJlIG5vdCBibGFjayBob2xlZC48YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7QnV0IHdoYXQgaWYg dGhpcyBlbmQtc3RhdGlvbiBtb3ZlcyBGUk9NIGEgbGluayB3aGljaCBoYXMgUkJyaWRnZShSQjEp PGJyPg0KJmd0OyAmZ3Q7d2l0aCBFU0FESSBzdXBwb3J0IFRPIGEgbGluayB3aGVyZSBSQnJpZGdl KFJCMikgZG9ub3QgaGF2ZSBFU0FESTxicj4NCiZndDsgJmd0O3N1cHBvcnQuIElzIHRoZXJlIGFu eSB3YXkgUkIxIGNhbiBub3RpZnkgb3RoZXIgRVNBREkgaW1wbGVtZW50ZWQ8YnI+DQomZ3Q7ICZn dDtSQnJpZGdlcyBpbiB0aGUgY2FtcHVzIHRvIGZsdXNoIHRoZSBvbGQgcm91dGUoTUFDICZxdW90 O0EmcXVvdDsNCmlzIHJlYWNoYWJsZSB2aWE8YnI+DQomZ3Q7ICZndDtlZ3Jlc3MgUkIxKSBzbyB0 aGF0IGZyYW1lcyBmb3IgTUFDICZxdW90O0EmcXVvdDsgYXJlIG5vdCBzZW5kDQpkaXJlY3RseSB0 byBSQjE8YnI+DQomZ3Q7ICZndDthbmQgYXJlIHJhdGhlciB0cmVhdGVkIGFzIHVua25vd24gdW5p Y2FzdCBmcmFtZSBhbmQgc2VuZCBvbiBhDQpEVHJlZT88YnI+DQomZ3Q7ICZndDtDb3VsZCBSQjEg c2VuZCB0byBFU0FESSBJbXBsZW1lbnRlZCBSQnJpZGdlcyB0aGF0IE1BQyAmcXVvdDtBJnF1b3Q7 DQppcyBubyBsb25nZXI8YnI+DQomZ3Q7ICZndDtyZWFjaGFibGUgdmlhIGl0c2VsZiBieSBzZW5k aW5nIGNvbmZpZGVuY2UgYXMgMCBmb3IgdGhhdCBNQUMgaW4NCml0czxicj4NCiZndDsgJmd0O0VT QURJIHBkdXM/PGJyPg0KJmd0Ozxicj4NCiZndDsgW2hmd10gSWYgUkIxIG5vdGlmeSB0aGF0IHRo ZSBlbmQtc3RhdGlvbiBtb3ZlcyBmcm9tIHRoZSBsaW5rLCBSQjENCndpbGwgdXBkYXRlPGJyPg0K Jmd0Ozxicj4NCiZndDsgYW5kIGZsb29kIHRoZSBMU1Agb3JpZ2luYXRlZCB3aXRoIG51bGxpbmcg b3V0IHRoZSBlbmQtc3RhdGlvbiBhZGRyZXNzLg0KV2hlbiBvdGhlciBFU0FESTxicj4NCiZndDs8 YnI+DQomZ3Q7IFJCcmlkZ2UgcmVjZWl2ZXMgdGhlIHVwZGF0ZWQgTFNQLCB0aGV5IHdpbGwgZm9y Z2V0IHRoZSBNQUMgJnF1b3Q7QSZxdW90Ow0KZnJvbSBpdHMgTUFDIHRhYmxlLjxicj4NCiZndDs8 YnI+DQomZ3Q7IEluIHRoaXMgd2F5LCBFU0FESSBwcm90b2NvbCBjYW4gZmFzdCB1cGRhdGUgdGhl IE1BQyB0YWJsZSBvZiByZW1vdGUNClJCcmlkZ2VzIHdoZW4gdGhlIGVuZCBzdGF0aW9uIGF0dGFj aGVkPGJyPg0KJmd0Ozxicj4NCiZndDsgaXMgdW5wbHVnZWQgb3IgYSBuZXcgZW5kIHN0YXRpb24g aXMgcGx1Z2VkLjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0O1Bs ZWFzZSBjb3JyZWN0IG1lIGlmIG15IHVuZGVyc3RhbmRpbmcgaXMgd3JvbmcuPGJyPg0KJmd0Ozxi cj4NCiZndDsgJmd0O0Fsc28gY291bGQgd2UgcmVjb21tZW5kIEVTQURJIGltcGxlbWVudGVkIFJC cmlkZ2VzIHRvIGJlY29tZSBEUkINCmFuZDxicj4NCiZndDsgJmd0O3NlcnZlIG1vcmUgQUYgZm9y IHZsYW5zLjxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDtFZGl0b3JpYWwgY29tbWVudHMgYW5kIHR5 cG9zOjxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDtJbiBBYnN0cmFjdDxicj4NCiZndDsgJmd0O0VT QURJIChFbmQgU3lzdGVtIEFkZHJlc3MgRGlzdHJpYnV0aW9uIEluZm9ybWF0aW9uKSBzaG91bGQg YmUNCnJlcGxhY2VkIGJ5PGJyPg0KJmd0OyAmZ3Q7RVNBREkgKEVuZCBTdGF0aW9uIEFkZHJlc3Mg RGlzdHJpYnV0aW9uIEluZm9ybWF0aW9uKSBhcyBwZXIgUkZDNjMyNTxicj4NCiZndDs8YnI+DQom Z3Q7ICZndDtJbiBzZWN0aW9uIDMuIEVTQURJIERSQiBTdGF0ZTxicj4NCiZndDsgJmd0Ozh0aCBs aW5lOiAmcXVvdDtmb3Igd2hpY2ggUkIxIGlzIGhvbGRpbmcgYW4gRVNBREktTFNQIHplcm8gd2l0 aA0KYW4gRVNBREk8YnI+DQomZ3Q7ICZndDtQYXJhcm1ldGVycyZxdW90OyAsIHR5cG8gZm9yICZx dW90O1BhcmFtZXRlcnMmcXVvdDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0O0lu IHNlY3Rpb24gNC4gRVNBREkgUERVIHByb2Nlc3Npbmc8YnI+DQomZ3Q7ICZndDs0dGggbGluZTog Jm5ic3A7ICZuYnNwOyAmcXVvdDthcmUgb25seSBFQVNESS1MU1AsIEVBU0RJLUNTTlAgYW5kDQpF QVNESS1QU05QIFBEVXMgdXNlZDxicj4NCiZndDsgJmd0O2luIEVTQURJLiZxdW90O3Nob3VsZCBi ZSBjaGFuZ2VkIHRvPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmcXVvdDthcmUgb25seSBFU0FESS1M U1AsIEVTQURJLUNTTlAgYW5kIEVTQURJLVBTTlAgUERVcw0KdXNlZCBpbiBFU0FESS4mcXVvdDs8 YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7SW4gc2VjdGlvbiA0LjEgU2VuZGluZyBvZiBFU0FTSSBQ RFVzPGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0O0NoYW5nZSB0aGUgdHlwbyBpbiB0aGUgaGVhZGVy IGl0c2VsZi48YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7NHRoIGxpbmU6ICZuYnNwOyAmbmJzcDsm cXVvdDs2KElubnRlci5NYWNTQSkmcXVvdDsgdG8gJzYoSW5uZXIuTWFjU0EpJnF1b3Q7PGJyPg0K Jmd0Ozxicj4NCiZndDsgJmd0OzV0aCBsaW5lOiAmbmJzcDsgJm5ic3A7ICZxdW90O3N0YXJ0aW5n IHdpdGggdGhlIEludHJhZG9tYWluIFJvdXRlaW5nDQpQcm90b2NvbDxicj4NCiZndDsgJmd0O0Rp c2NyaW1pbmF0b3IsJnF1b3Q7IFR5cG8gJnF1b3Q7Um91dGVpbmcmcXVvdDsgdG8gJnF1b3Q7Um91 dGluZyZxdW90Ozxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsybmQgUGFyYSwgMXN0IGxpbmU6ICZx dW90O09uY2UgYW4gRVNBREkgaW5zdGFuY2UgaXMgb3BlcmF0aW9uYWxseQ0KdXAsIGl0PGJyPg0K Jmd0OyAmZ3Q7bXVsdGljYXN0cyBpdCBzZWxmLTxicj4NCiZndDsgJmd0OyAmbmJzcDtvcmlnaW5h dGVkIExTUCBudW1iZXIgemVybyBvbiB0aGUgdmlydHVhbCBsaW5rIHRvIGFubm91bmNlDQppdHMg RVNBREk8YnI+DQomZ3Q7ICZndDsgJm5ic3A7cGFyYW1ldGVycy4mcXVvdDsgJm5ic3A7IG1heSBi ZSBjaGFuZ2VkIHRvPGJyPg0KJmd0OyAmZ3Q7JnF1b3Q7T25jZSBhbiBFU0FESSBpbnN0YW5jZSBp cyBvcGVyYXRpb25hbGx5IHVwLCBpdCBtdWx0aWNhc3RzL3NlbmRzDQppdHMgc2VsZi08YnI+DQom Z3Q7ICZndDsgJm5ic3A7IG9yaWdpbmF0ZWQgTFNQIG51bWJlciB6ZXJvIG9uIHRoZSB2aXJ0dWFs IGxpbmsgdG8gYW5ub3VuY2UNCml0cyBFU0FESTxicj4NCiZndDsgJmd0OyAmbmJzcDsgcGFyYW1l dGVycy4mcXVvdDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7NXRoIFBhcmEsIDJuZCBsaW5lOiBU eXBvICZxdW90O0VBU0RJJnF1b3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0O0luIHNlY3Rpb24g NS4gRVNBREktTFNQIENvbnRlbnRzPGJyPg0KJmd0OyAmZ3Q7N3RoIGxpbmUgdHlwbyAmcXVvdDtF QVNEQUktTFNQczxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDtJbiBzZWN0aW9uIDUuMSBFU0FESSBQ YXJhbWV0ZXIgRGF0YTxicj4NCiZndDsgJmd0OzR0aCBsaW5lIHR5cG8gJnF1b3Q7b2NjdXJybmNl JnF1b3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgW2hmd10gVGhhbmtzIGZvciB0aGUgY29ycmVjdGlu Zywgd2Ugd2lsbCBjb3JyZWN0IGl0IGluIHRoZSBuZXh0IHZlcnNpb24uPGJyPg0KJmd0Ozxicj4N CiZndDs8YnI+DQomZ3Q7IHNvbW5hdGggY2hhdHRlcmplZSAmbHQ7c29tbmF0aC5jaGF0dGVyamVl MDFAZ21haWwuY29tJmd0Ozxicj4NCiZndDsgt6K8/sjLOiAmbmJzcDt0cmlsbC1ib3VuY2VzQGll dGYub3JnPGJyPg0KJmd0Ozxicj4NCiZndDsgMjAxMi0wNC0yMSAwMToxNzxicj4NCiZndDs8YnI+ DQomZ3Q7PGJyPg0KJmd0OyDK1bz+yMs8YnI+DQomZ3Q7IHRyaWxsQGlldGYub3JnPGJyPg0KJmd0 OyCzrcvNPGJyPg0KJmd0OyDW98ziPGJyPg0KJmd0OyBbdHJpbGxdIFtyYnJpZGdlXSBkcmFmdC1o dS10cmlsbC1yYnJpZGdlLWVzYWRpLTA0PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJy Pg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgSGkgQXV0aG9y cyw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIGhhdmUgcmVhZCB0aGUgZHJhZnQtaHUtdHJpbGwtcmJy aWRnZS1lc2FkaS0wNCBhbmQgc3VwcG9ydCBpdC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIGhhdmUg b25lIHF1ZXN0aW9uIHJlZ2FyZGluZyB0aGUgcHJvYmxlbSBzdGF0ZWQgaW4gdGhlIGRyYWZ0PGJy Pg0KJmd0Ozxicj4NCiZndDsgJnF1b3Q7IDIuIEZhc3QgdXBkYXRlIGFkdmFudGFnZXM6IEVTQURJ IHByb3RvY29sIHByb3ZpZGVzIGEgZmFzdCB1cGRhdGUNCm9mPGJyPg0KJmd0OyAmbmJzcDsgJm5i c3A7IGVuZCBub2RlcyBNQUMgKE1lZGlhIEFjY2VzcyBDb250cm9sKSBhZGRyZXNzZXMuICZuYnNw O0lmDQphbiBlbmQgc3RhdGlvbjxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBpcyB1bnBsdWdnZWQg ZnJvbSBvbmUgUkJyaWRnZSBhbmQgcGx1Z2dlZCBpbnRvIGFub3RoZXIsDQpmcmFtZXM8YnI+DQom Z3Q7ICZuYnNwOyAmbmJzcDsgYWRkcmVzc2VkIHRvIHRoYXQgb2xkZXIgUkJyaWRnZSBjYW4gYmUg YmxhY2sgaG9sZWQuDQombmJzcDtUaGV5IGNhbiBiZTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBz ZW50IGp1c3QgdG8gdGhlIG9sZGVyIFJCcmlkZ2UgdGhhdCB0aGUgZW5kIHN0YXRpb24NCndhcyBj b25uZWN0ZWQ8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgdG8gdW50aWwgY2FjaGVkIGFkZHJlc3Mg aW5mb3JtYXRpb24gYXQgc29tZSByZW1vdGUgUkJyaWRnZQ0KdGltZXM8YnI+DQomZ3Q7ICZuYnNw OyAmbmJzcDsgb3V0LCBwb3NzaWJseSBmb3IgdGVucyBvZiBzZWNvbmRzIFtSRkM2MzI1XS4mcXVv dDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJbiB0aGlzIHNjZW5hcmlvIHdoZW4gYW4gZW5kLXN0YXRp b24gbW92ZXMgVE8gYSBsaW5rIHdoZXJlIGFuPGJyPg0KJmd0OyBSQnJpZGdlKFJCeCkgd2l0aCBF U0FESSBzdXBwb3J0IGlzIHNlcnZpbmcgYXMgQUYgZm9yIHRoZSB2bGFuIG9uIHdoaWNoPGJyPg0K Jmd0OyB0aGUgZW5kLXN0YXRpb24gaXMgY29ubmVjdGVkLCB0aGlzIFJCcmlkZ2Ugc2VuZHMgdGhl IGVuZC1zdGF0aW9uIE1BQ3M8YnI+DQomZ3Q7IHRocm91Z2ggRVNBREkgcGR1IHRvIG90aGVyIEVT QURJIFJCcmlkZ2VzIHdpdGggYSBoaWdoZXIgY29uZmlkZW5jZQ0KYW5kPGJyPg0KJmd0OyB0aGUg b2xkIHJvdXRlcyBpbiBvdGhlciBFU0FESSBSQnJpZGdlcyBhcmUgb3Zlci13cml0dGVuLk5ldyBy b3V0ZXMoTUFDPGJyPg0KJmd0OyAmcXVvdDtBJnF1b3Q7IGlzIHJlYWNoYWJsZSB2aWEgZWdyZXNz IFJCcmlkZ2UgUkJ4KSBleGlzdCBhbmQgZnJhbWVzDQpkZXN0aW5lZCB0bzxicj4NCiZndDsgTUFD ICZxdW90O0EmcXVvdDsgYXJlIG5vdCBibGFjayBob2xlZC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBC dXQgd2hhdCBpZiB0aGlzIGVuZC1zdGF0aW9uIG1vdmVzIEZST00gYSBsaW5rIHdoaWNoIGhhcyBS QnJpZGdlKFJCMSk8YnI+DQomZ3Q7IHdpdGggRVNBREkgc3VwcG9ydCBUTyBhIGxpbmsgd2hlcmUg UkJyaWRnZShSQjIpIGRvbm90IGhhdmUgRVNBREk8YnI+DQomZ3Q7IHN1cHBvcnQuIElzIHRoZXJl IGFueSB3YXkgUkIxIGNhbiBub3RpZnkgb3RoZXIgRVNBREkgaW1wbGVtZW50ZWQ8YnI+DQomZ3Q7 IFJCcmlkZ2VzIGluIHRoZSBjYW1wdXMgdG8gZmx1c2ggdGhlIG9sZCByb3V0ZShNQUMgJnF1b3Q7 QSZxdW90OyBpcw0KcmVhY2hhYmxlIHZpYTxicj4NCiZndDsgZWdyZXNzIFJCMSkgc28gdGhhdCBm cmFtZXMgZm9yIE1BQyAmcXVvdDtBJnF1b3Q7IGFyZSBub3Qgc2VuZCBkaXJlY3RseQ0KdG8gUkIx PGJyPg0KJmd0OyBhbmQgYXJlIHJhdGhlciB0cmVhdGVkIGFzIHVua25vd24gdW5pY2FzdCBmcmFt ZSBhbmQgc2VuZCBvbiBhIERUcmVlPzxicj4NCiZndDsgQ291bGQgUkIxIHNlbmQgdG8gRVNBREkg SW1wbGVtZW50ZWQgUkJyaWRnZXMgdGhhdCBNQUMgJnF1b3Q7QSZxdW90Ow0KaXMgbm8gbG9uZ2Vy PGJyPg0KJmd0OyByZWFjaGFibGUgdmlhIGl0c2VsZiBieSBzZW5kaW5nIGNvbmZpZGVuY2UgYXMg MCBmb3IgdGhhdCBNQUMgaW4gaXRzPGJyPg0KJmd0OyBFU0FESSBwZHVzPzxicj4NCiZndDs8YnI+ DQomZ3Q7IFBsZWFzZSBjb3JyZWN0IG1lIGlmIG15IHVuZGVyc3RhbmRpbmcgaXMgd3JvbmcuPGJy Pg0KJmd0Ozxicj4NCiZndDsgQWxzbyBjb3VsZCB3ZSByZWNvbW1lbmQgRVNBREkgaW1wbGVtZW50 ZWQgUkJyaWRnZXMgdG8gYmVjb21lIERSQiBhbmQ8YnI+DQomZ3Q7IHNlcnZlIG1vcmUgQUYgZm9y IHZsYW5zLjxicj4NCiZndDs8YnI+DQomZ3Q7IEVkaXRvcmlhbCBjb21tZW50cyBhbmQgdHlwb3M6 PGJyPg0KJmd0Ozxicj4NCiZndDsgSW4gQWJzdHJhY3Q8YnI+DQomZ3Q7IEVTQURJIChFbmQgU3lz dGVtIEFkZHJlc3MgRGlzdHJpYnV0aW9uIEluZm9ybWF0aW9uKSBzaG91bGQgYmUgcmVwbGFjZWQN CmJ5PGJyPg0KJmd0OyBFU0FESSAoRW5kIFN0YXRpb24gQWRkcmVzcyBEaXN0cmlidXRpb24gSW5m b3JtYXRpb24pIGFzIHBlciBSRkM2MzI1PGJyPg0KJmd0Ozxicj4NCiZndDsgSW4gc2VjdGlvbiAz LiBFU0FESSBEUkIgU3RhdGU8YnI+DQomZ3Q7IDh0aCBsaW5lOiAmcXVvdDtmb3Igd2hpY2ggUkIx IGlzIGhvbGRpbmcgYW4gRVNBREktTFNQIHplcm8gd2l0aCBhbg0KRVNBREk8YnI+DQomZ3Q7IFBh cmFybWV0ZXJzJnF1b3Q7ICwgdHlwbyBmb3IgJnF1b3Q7UGFyYW1ldGVycyZxdW90Ozxicj4NCiZn dDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJbiBzZWN0aW9uIDQuIEVTQURJIFBEVSBwcm9jZXNzaW5n PGJyPg0KJmd0OyA0dGggbGluZTogJm5ic3A7ICZuYnNwOyAmcXVvdDthcmUgb25seSBFQVNESS1M U1AsIEVBU0RJLUNTTlAgYW5kIEVBU0RJLVBTTlANClBEVXMgdXNlZDxicj4NCiZndDsgaW4gRVNB REkuJnF1b3Q7c2hvdWxkIGJlIGNoYW5nZWQgdG88YnI+DQomZ3Q7ICZuYnNwOyZxdW90O2FyZSBv bmx5IEVTQURJLUxTUCwgRVNBREktQ1NOUCBhbmQgRVNBREktUFNOUCBQRFVzIHVzZWQNCmluIEVT QURJLiZxdW90Ozxicj4NCiZndDs8YnI+DQomZ3Q7IEluIHNlY3Rpb24gNC4xIFNlbmRpbmcgb2Yg RVNBU0kgUERVczxicj4NCiZndDs8YnI+DQomZ3Q7IENoYW5nZSB0aGUgdHlwbyBpbiB0aGUgaGVh ZGVyIGl0c2VsZi48YnI+DQomZ3Q7PGJyPg0KJmd0OyA0dGggbGluZTogJm5ic3A7ICZuYnNwOyZx dW90OzYoSW5udGVyLk1hY1NBKSZxdW90OyB0byAnNihJbm5lci5NYWNTQSkmcXVvdDs8YnI+DQom Z3Q7PGJyPg0KJmd0OyA1dGggbGluZTogJm5ic3A7ICZuYnNwOyAmcXVvdDtzdGFydGluZyB3aXRo IHRoZSBJbnRyYWRvbWFpbiBSb3V0ZWluZw0KUHJvdG9jb2w8YnI+DQomZ3Q7IERpc2NyaW1pbmF0 b3IsJnF1b3Q7IFR5cG8gJnF1b3Q7Um91dGVpbmcmcXVvdDsgdG8gJnF1b3Q7Um91dGluZyZxdW90 Ozxicj4NCiZndDs8YnI+DQomZ3Q7IDJuZCBQYXJhLCAxc3QgbGluZTogJnF1b3Q7T25jZSBhbiBF U0FESSBpbnN0YW5jZSBpcyBvcGVyYXRpb25hbGx5DQp1cCwgaXQ8YnI+DQomZ3Q7IG11bHRpY2Fz dHMgaXQgc2VsZi08YnI+DQomZ3Q7ICZuYnNwO29yaWdpbmF0ZWQgTFNQIG51bWJlciB6ZXJvIG9u IHRoZSB2aXJ0dWFsIGxpbmsgdG8gYW5ub3VuY2UgaXRzDQpFU0FESTxicj4NCiZndDsgJm5ic3A7 cGFyYW1ldGVycy4mcXVvdDsgJm5ic3A7IG1heSBiZSBjaGFuZ2VkIHRvPGJyPg0KJmd0OyAmcXVv dDtPbmNlIGFuIEVTQURJIGluc3RhbmNlIGlzIG9wZXJhdGlvbmFsbHkgdXAsIGl0IG11bHRpY2Fz dHMvc2VuZHMNCml0cyBzZWxmLTxicj4NCiZndDsgJm5ic3A7b3JpZ2luYXRlZCBMU1AgbnVtYmVy IHplcm8gb24gdGhlIHZpcnR1YWwgbGluayB0byBhbm5vdW5jZSBpdHMNCkVTQURJPGJyPg0KJmd0 OyAmbmJzcDtwYXJhbWV0ZXJzLiZxdW90Ozxicj4NCiZndDs8YnI+DQomZ3Q7IDV0aCBQYXJhLCAy bmQgbGluZTogVHlwbyAmcXVvdDtFQVNESSZxdW90Ozxicj4NCiZndDs8YnI+DQomZ3Q7IEluIHNl Y3Rpb24gNS4gRVNBREktTFNQIENvbnRlbnRzPGJyPg0KJmd0OyA3dGggbGluZSB0eXBvICZxdW90 O0VBU0RBSS1MU1BzPGJyPg0KJmd0Ozxicj4NCiZndDsgSW4gc2VjdGlvbiA1LjEgRVNBREkgUGFy YW1ldGVyIERhdGE8YnI+DQomZ3Q7IDR0aCBsaW5lIHR5cG8gJnF1b3Q7b2NjdXJybmNlJnF1b3Q7 PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhhbmsgeW91LDxicj4NCiZndDsgUmVnYXJkcyw8YnI+DQom Z3Q7IFNvbW5hdGg8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KJmd0OyB0cmlsbCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IHRyaWxs QGlldGYub3JnPGJyPg0KJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3RyaWxsPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQp0cmlsbCBtYWlsaW5nIGxpc3Q8 YnI+DQp0cmlsbEBpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdHJpbGw8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCg== --=_alternative 003169C8482579E9_=-- From narten@us.ibm.com Mon Apr 23 05:46:12 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB64121F85F2 for ; Mon, 23 Apr 2012 05:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.229 X-Spam-Level: X-Spam-Status: No, score=-110.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 EJh1JmpCtnQm for ; Mon, 23 Apr 2012 05:46:12 -0700 (PDT) Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) by ietfa.amsl.com (Postfix) with ESMTP id 3D46221F85E3 for ; Mon, 23 Apr 2012 05:46:12 -0700 (PDT) Received: from /spool/local by e37.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 23 Apr 2012 06:46:11 -0600 Received: from d03dlp01.boulder.ibm.com (9.17.202.177) by e37.co.us.ibm.com (192.168.1.137) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 23 Apr 2012 06:45:28 -0600 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id 46FEFC4000B for ; Mon, 23 Apr 2012 06:45:26 -0600 (MDT) Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q3NCif81264826 for ; Mon, 23 Apr 2012 06:44:51 -0600 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q3NCiejo019007 for ; Mon, 23 Apr 2012 06:44:40 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-216-82.mts.ibm.com [9.65.216.82]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q3NCidVj018989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2012 06:44:40 -0600 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.5/8.12.5) with ESMTP id q3NCicwq006370; Mon, 23 Apr 2012 08:44:38 -0400 Message-Id: <201204231244.q3NCicwq006370@cichlid.raleigh.ibm.com> To: Donald Eastlake In-reply-to: References: Comments: In-reply-to Donald Eastlake message dated "Thu, 12 Apr 2012 23:13:36 -0400." Date: Mon, 23 Apr 2012 08:44:38 -0400 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12042312-7408-0000-0000-0000046CA8EF Cc: trill@ietf.org Subject: Re: [trill] draft-hu-trill-rbridge-esadi to TRILL WG draft X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 12:46:13 -0000 > This message begins a two week comment period for TRILL WG assent to > make draft-hu-trill-rbridge-esadi-04.txt a TRILL WG draft. Question about the scope of this document. It says: This document updates [RFC6325], the TRILL basic specification, particularly the description of the ESADI protocol, and prevails over [RFC6325] in the case of conflicts. To be clear, is the intention of this document to become the single, normative description of ESADI? FWIW, I hope so. IMO, it would be best to put all of the ESADI protocol specification into a single, definitive document. And have that document obsolete/supersede all previous specifications on the topic of ESADI. Thomas From d3e3e3@gmail.com Mon Apr 23 08:18:08 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A79C21F86F7 for ; Mon, 23 Apr 2012 08:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.98 X-Spam-Level: X-Spam-Status: No, score=-103.98 tagged_above=-999 required=5 tests=[AWL=-0.381, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 gopFU55PDwh1 for ; Mon, 23 Apr 2012 08:18:08 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9A53A21F86F0 for ; Mon, 23 Apr 2012 08:18:07 -0700 (PDT) Received: by lagj5 with SMTP id j5so9779837lag.31 for ; Mon, 23 Apr 2012 08:18:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=MRWdIdMtCs8GkzQMIUMNdz/vO+x61AZIsUU5elStWko=; b=S3p5iio/rsIxms0aVmEXchIElHJUlK5OhzWbv2xw6PSVF47PF/w6cKilY078k/kFdu UimI3rrosal5ZDMKu8gRzu3idbGdWJaZECZ+fVwBq1U0Ezc5CADXsZ1OKwE6GIvsKZLh uNX1svariIiUbsmV/mAlwUCPZPo1shKXikuKaJbDNrrZ0BahO66QTy/TxNecIfCepcz5 C4d+1BMWBRW/2XdhOGJqe4V8XkSpqd9d9YJk/dl/GEACPXAntXKaxaBuUu8oFQY7Fm2C peP0tSrvuxKwfFp99QhmiW1PnPqUQoMsJFQBgFeDaEeh6jrx+XsIOJZADTiXynQ/VJ6B d/lw== Received: by 10.112.100.134 with SMTP id ey6mr8150384lbb.18.1335194286552; Mon, 23 Apr 2012 08:18:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.144.8 with HTTP; Mon, 23 Apr 2012 08:17:46 -0700 (PDT) In-Reply-To: <201204231244.q3NCicwq006370@cichlid.raleigh.ibm.com> References: <201204231244.q3NCicwq006370@cichlid.raleigh.ibm.com> From: Donald Eastlake Date: Mon, 23 Apr 2012 11:17:46 -0400 Message-ID: To: Thomas Narten Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: trill@ietf.org Subject: Re: [trill] draft-hu-trill-rbridge-esadi to TRILL WG draft X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 15:18:08 -0000 Well, ESADI is built on TRILL but it is the intent to put all the ESADI specific stuff in this draft. By the way, I'm pretty busy in China with meetings this week so I may not be as responsive on the list. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com On Mon, Apr 23, 2012 at 8:44 AM, Thomas Narten wrote: >> This message begins a two week comment period for TRILL WG assent to >> make draft-hu-trill-rbridge-esadi-04.txt a TRILL WG draft. > > Question about the scope of this document. It says: > > =A0 This document updates [RFC6325], the TRILL basic specification, > =A0 particularly the description of the ESADI protocol, and prevails over > =A0 [RFC6325] in the case of conflicts. > > To be clear, is the intention of this document to become the single, > normative description of ESADI? > > FWIW, I hope so. IMO, it would be best to put all of the ESADI > protocol specification into a single, definitive document. And have > that document obsolete/supersede all previous specifications on the > topic of ESADI. > > Thomas > From narten@us.ibm.com Mon Apr 23 08:22:35 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3B7721F873B for ; Mon, 23 Apr 2012 08:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.282 X-Spam-Level: X-Spam-Status: No, score=-110.282 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 VZG27QMBIW6r for ; Mon, 23 Apr 2012 08:22:34 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by ietfa.amsl.com (Postfix) with ESMTP id 1C32C21F8735 for ; Mon, 23 Apr 2012 08:22:34 -0700 (PDT) Received: from /spool/local by e34.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 23 Apr 2012 09:22:29 -0600 Received: from d01dlp03.pok.ibm.com (9.56.224.17) by e34.co.us.ibm.com (192.168.1.134) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 23 Apr 2012 09:21:40 -0600 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id D9857C9006C for ; Mon, 23 Apr 2012 11:21:37 -0400 (EDT) Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q3NFLVSk070688 for ; Mon, 23 Apr 2012 11:21:31 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q3NFLRv2014032 for ; Mon, 23 Apr 2012 12:21:27 -0300 Received: from cichlid.raleigh.ibm.com (sig-9-65-240-231.mts.ibm.com [9.65.240.231]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q3NFLPoM013430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2012 12:21:25 -0300 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.5/8.12.5) with ESMTP id q3NFLKuG006555; Mon, 23 Apr 2012 11:21:20 -0400 Message-Id: <201204231521.q3NFLKuG006555@cichlid.raleigh.ibm.com> To: Donald Eastlake In-reply-to: References: <201204231244.q3NCicwq006370@cichlid.raleigh.ibm.com> Comments: In-reply-to Donald Eastlake message dated "Mon, 23 Apr 2012 11:17:46 -0400." Date: Mon, 23 Apr 2012 11:21:19 -0400 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12042315-1780-0000-0000-000004FA73A9 X-IBM-ISS-SpamDetectors: X-IBM-ISS-DetailInfo: BY=3.00000271; HX=3.00000187; KW=3.00000007; PH=3.00000001; SC=3.00000001; SDB=6.00133411; UDB=6.00031283; UTC=2012-04-23 15:22:28 Cc: trill@ietf.org Subject: Re: [trill] draft-hu-trill-rbridge-esadi to TRILL WG draft X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 15:22:35 -0000 > Well, ESADI is built on TRILL but it is the intent to put all the > ESADI specific stuff in this draft. Sounds good. I think it would be good to have all the ESADI stuff (to the degree possible) be in a single RFC, rather than scattered in multiple documents. That way, if folk implement ESADI, it's easy to say that means RFC XXX. Thomas From jon.hudson@gmail.com Mon Apr 23 08:37:55 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FAA221F8702 for ; Mon, 23 Apr 2012 08:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] 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 WxyUCEsy1wUm for ; Mon, 23 Apr 2012 08:37:54 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id AA00921F8664 for ; Mon, 23 Apr 2012 08:37:54 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so4034542pbb.31 for ; Mon, 23 Apr 2012 08:37:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=47ba3OTeSXdgX1mkFlu1NXNUHDa/9tdHa9ZPKqwi1n0=; b=MkFY/FP2uW5+bJPuB1Jm61i8OyWbMn7yfP2SSnI/rTMQONtcpIx5QA9hH42IpmdjnA 9HuC2iC37bhN65+Ft0iV9aZAXd75mSKC8oy6mHuVBBDoZd3/acg2KuaH1mKLNxHxugCk qdESlYBI6jj7RU1KjaoxmRAZOsj0XOhqjEfIG+6IndmvntmCSa4xpnP6pmwewpfe8NqR DHV2sfBbh/RSbI1Up1sVAAf9wf2BDhAn/Y/vmEKu4TTfi9DI6nbycV3O7txzRSGytHPR 8sukaMtP8em/s9Ct+hCPx1TAGs7D5C3HoYIR0oyLS6MS5GZWseV/wINz0vwWCmqzEuX/ UVgA== Received: by 10.68.75.45 with SMTP id z13mr779512pbv.100.1335195474540; Mon, 23 Apr 2012 08:37:54 -0700 (PDT) Received: from [10.0.1.6] (c-98-234-218-27.hsd1.ca.comcast.net. [98.234.218.27]) by mx.google.com with ESMTPS id tk8sm612175pbc.33.2012.04.23.08.37.52 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Apr 2012 08:37:53 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9B176) From: Jon Hudson Date: Mon, 23 Apr 2012 08:37:49 -0700 To: Donald Eastlake Cc: "trill@ietf.org" Subject: Re: [trill] draft-hu-trill-rbridge-esadi to TRILL WG draft X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 15:37:55 -0000 I have read and support this document. But I echo Thomas's comment that it would be desirable for ESADI to be in so= me standalone form for easy use by other groups.=20 On Apr 12, 2012, at 8:13 PM, Donald Eastlake wrote: > This message begins a two week comment period for TRILL WG assent to > make draft-hu-trill-rbridge-esadi-04.txt a TRILL WG draft. >=20 > Thanks, > Donald [Co-Chair) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill From aldrin.ietf@gmail.com Mon Apr 23 09:12:34 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FFB221F8720 for ; Mon, 23 Apr 2012 09:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] 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 L+pXVQM6GTFO for ; Mon, 23 Apr 2012 09:12:33 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id E544721F8754 for ; Mon, 23 Apr 2012 09:12:30 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so4074130pbb.31 for ; Mon, 23 Apr 2012 09:12:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=fw2eUjwjtBcNGne5zahQpUeszCKW4Yp8nLdDztNAjPQ=; b=QyiSK1hWKmG50dPWc9GmLdwBfeIzlWhkTUSYZph7pAENbFsr1ND0Zzxm6icPQxZqLH QWfmQROQ5b0ia6Dyiulj/K9iUTiCWvzV0CQFNZRMMQ8GHfdcesfGXjtYJMinUQonGH4V Gekw+fY/phTNENKDPUSiIsbt7smYJGV39YOkHqvUsXzqBpRRoxR/5X0cZtg077bS60X5 CEk8kqNPyWtLO6AIyAoZUAotmDdX81zLEZnB9nQNeSGl8A6AfKdr/VipzHZ7YWzgyii5 Tr6GF1QV9ddj0eqcSWGVVXyraRpTK0qsPIKqCVLzDqo+qeq+XW9QIBTW/sPdlkKPpOwX z7Mw== Received: by 10.68.195.38 with SMTP id ib6mr21399972pbc.28.1335197550786; Mon, 23 Apr 2012 09:12:30 -0700 (PDT) Received: from [192.168.255.176] ([12.207.18.42]) by mx.google.com with ESMTPS id ih3sm480871pbc.10.2012.04.23.09.12.28 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Apr 2012 09:12:29 -0700 (PDT) References: <201204231244.q3NCicwq006370@cichlid.raleigh.ibm.com> <201204231521.q3NFLKuG006555@cichlid.raleigh.ibm.com> In-Reply-To: <201204231521.q3NFLKuG006555@cichlid.raleigh.ibm.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (9B176) From: Sam Aldrin Date: Mon, 23 Apr 2012 09:12:27 -0700 To: Thomas Narten Cc: Donald Eastlake , "trill@ietf.org" Subject: Re: [trill] draft-hu-trill-rbridge-esadi to TRILL WG draft X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 16:12:34 -0000 Support this draft, at the same time, agree with Thomas to have a single rfc= for all ESADI stuff. Cheers Sam Sent from my iPad On Apr 23, 2012, at 8:21 AM, Thomas Narten wrote: >> Well, ESADI is built on TRILL but it is the intent to put all the >> ESADI specific stuff in this draft. >=20 > Sounds good. I think it would be good to have all the ESADI stuff (to > the degree possible) be in a single RFC, rather than scattered in > multiple documents. That way, if folk implement ESADI, it's easy to > say that means RFC XXX. >=20 > Thomas >=20 > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill From linda.dunbar@huawei.com Mon Apr 23 14:41:26 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD65021E802D; Mon, 23 Apr 2012 14:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 25o9Ryls3L05; Mon, 23 Apr 2012 14:41:26 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4076921E8028; Mon, 23 Apr 2012 14:41:26 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFD79643; Mon, 23 Apr 2012 17:41:25 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 23 Apr 2012 14:39:41 -0700 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.003; Mon, 23 Apr 2012 14:39:31 -0700 From: Linda Dunbar To: Donald Eastlake , "zhai.hongjun@zte.com.cn" , "hu.fangwei@zte.com.cn" , "Radia@alum.mit.edu" Thread-Topic: [trill] [rbridge] draft-hu-trill-rbridge-esadi-04 Thread-Index: AQHNHxmqWppp9pC8NUq/bk1heRbK7pamptiAgAJNVVA= Date: Mon, 23 Apr 2012 21:39:31 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F632E63C3B@dfweml505-mbx> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.156] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F632E63C3Bdfweml505mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "trill-bounces@ietf.org" , "trill@ietf.org" Subject: Re: [trill] [rbridge] draft-hu-trill-rbridge-esadi-04 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 21:41:27 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F632E63C3Bdfweml505mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have read through the draft-hu-trill-rbridge-esadi-04 and support it. Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F632E63C3Bdfweml505mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have read through the d= raft-hu-trill-rbridge-esadi-04 and support it.

 <= /p>

Linda Dunbar

--_000_4A95BA014132FF49AE685FAB4B9F17F632E63C3Bdfweml505mbx_-- From d3e3e3@gmail.com Mon Apr 23 16:33:14 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DAC821F8601; Mon, 23 Apr 2012 16:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.528 X-Spam-Level: X-Spam-Status: No, score=-101.528 tagged_above=-999 required=5 tests=[AWL=-2.779, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_75=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 q-QmVFPoCsNY; Mon, 23 Apr 2012 16:33:13 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id BAEB821F8606; Mon, 23 Apr 2012 16:33:12 -0700 (PDT) Received: by lbgc1 with SMTP id c1so60001lbg.31 for ; Mon, 23 Apr 2012 16:33:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=Cs75I5PR2g0oY7O3/JX6nCgwTQaQWMevIoD7ZbUcN3I=; b=cqeleYFDb8g0eZByEcexWIDPv/FkN/FdSZtqrnQYNRhNuaVqThGjYvSjJ9YjuOW8fu fNNdvo7gd/SiBgO1K3fIVFuPRLLTRgwWStmSxGZ/qPO+qSceTI/EoEPvjNTuAoWgxCqg q1OEQ7roKD2tBYXlqjl9+Yli/xK1bRha+sw2v4ncO1vjDplRZk4m7LgLwd0+cMyI8bzm I6qlziiAdKbAAbMj3XUHlOOkckhELJIk0hCFlvb3fjp/j/m7fOuSTv6OsMG6dQKVpkxq tOCSN8nwUCWOWoBujO6TkRgIHHQ4y7k7izngf06Mmsh7NqS6qmNNLy94DrvPcFdMuhwi mcwA== Received: by 10.152.112.97 with SMTP id ip1mr3704591lab.31.1335223991603; Mon, 23 Apr 2012 16:33:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.144.8 with HTTP; Mon, 23 Apr 2012 16:32:51 -0700 (PDT) In-Reply-To: References: From: Donald Eastlake Date: Mon, 23 Apr 2012 19:32:51 -0400 Message-ID: To: somnath chatterjee Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: trill-bounces@ietf.org, hu.fangwei@zte.com.cn, trill@ietf.org Subject: Re: [trill] [rbridge] draft-hu-trill-rbridge-esadi-04 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 23:33:14 -0000 Hi Somnath, Generally speaking, on your questions about what happens if a end station moves from being connected to an ESADI RBridge that is advertising the end stations MAC address to a non-ESADI RBridge, where both are Appointed Forwarders for the stations VLAN, what happens. If the "from" RBridge notices, it removed that MAC address from its ESADI-LSP. By the ESADI flooding, that updated LSP without the MAC address will get to all other participating ESADI RBridges for that VLAN. If the "to" RBridge is not an ESADI RBridge, then, of course, you do not get any benefit from ESADI for the connection to it. There is little, if any benefit, from trying to play around with dymanically set confidences in this case. If both the "from" and "to" RBridges are ESADI RBridges and they both think MAC address M is connected in VLAN V for which they are participating in ESADI, then both with advertise this in their ESADI-LSP. An implementation could keep track of when if gets LSP updates and try to figure out which was more recent. See below. 2012/4/23 somnath chatterjee : > Hi , > > In introduction of draft-hu-trill-rbridge-esadi-04 > " An RBridge that is announcing connectivity to VLAN-x (normally a > VLAN-x appointed forwarder) MAY use the (ESADI) protocol to announce > the end station address of some or all of its attached VLAN-x end > nodes to other RBridges that are running ESADI for VLAN-x." > > An ESADI supported RBridge MAY selectively send about end-station MACs > and MAY opt to not send all the end-station MACs. > > I am only suggesting to send MAC in updated ESADI-LSP with confidence > zero(for every lost MAC), so that other ESADI RBridges could easily > recognize that this MAC needs to be deleted, rather than compare it > with previously stored information and then delete. It is stronger to just drop the MAC for your ESADI-LSP. Other EASDI RBridges need to look at your update to figure out if/how to update their FIB in any case. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > Thank you, > Regards, > Somnath > > 2012/4/23 >> >> >> Hi, chatterjee >> >> By my understanding, If RB1 supports ESADI, it advertises all the end-st= ation MAC attached to the remote RBridges. >> >> The remote RBridge can do some policy forwarding based on the MAC addres= s, but I think it is no need to opt to send the end-station MAC by the loca= l RBridge. >> >> Regards >> >> >> somnath chatterjee >> >> 2012-04-23 14:57 >> >> =CA=D5=BC=FE=C8=CB >> hu.fangwei@zte.com.cn >> =B3=AD=CB=CD >> trill@ietf.org, trill-bounces@ietf.org >> =D6=F7=CC=E2 >> Re: [trill] [rbridge] draft-hu-trill-rbridge-esadi-04 >> >> >> >> >> >> Hi Fangwei, >> >> Thank you for the explanation. >> >> So, RB1 doesnot include the end-stations MAC in its LSP. What if RB1 has= opted not to send this end-station MAC in its ESADI-LSP earlier? The other= ESADI RBridges has no way to learn that this MAC has to be flushed(which m= ay be learned through other procedures except ESADI). It would be good if E= SADI RBridges could explicitly tell other RBridges to forget a MAC. >> >> Regards, >> Somnath >> >> 2012/4/22 >> >> Thanks for the reviewing and comments. >> >> Pls see the following in line. >> >> >Hi Authors, >> >> >I have read the draft-hu-trill-rbridge-esadi-04 and support it. >> >> >I have one question regarding the problem stated in the draft >> >> > " 2. Fast update advantages: ESADI protocol provides a fast update of >> end nodes MAC (Media Access Control) addresses. If an end station >> is unplugged from one RBridge and plugged into another, frames >> addressed to that older RBridge can be black holed. They can be >> sent just to the older RBridge that the end station was connected >> to until cached address information at some remote RBridge times >> out, possibly for tens of seconds [RFC6325]." >> >> >In this scenario when an end-station moves TO a link where an >> >RBridge(RBx) with ESADI support is serving as AF for the vlan on which >> >the end-station is connected, this RBridge sends the end-station MACs >> >through ESADI pdu to other ESADI RBridges with a higher confidence and >> >the old routes in other ESADI RBridges are over-written.New routes(MAC >> >"A" is reachable via egress RBridge RBx) exist and frames destined to >> >MAC "A" are not black holed. >> >> >But what if this end-station moves FROM a link which has RBridge(RB1) >> >with ESADI support TO a link where RBridge(RB2) donot have ESADI >> >support. Is there any way RB1 can notify other ESADI implemented >> >RBridges in the campus to flush the old route(MAC "A" is reachable via >> >egress RB1) so that frames for MAC "A" are not send directly to RB1 >> >and are rather treated as unknown unicast frame and send on a DTree? >> >Could RB1 send to ESADI Implemented RBridges that MAC "A" is no longer >> >reachable via itself by sending confidence as 0 for that MAC in its >> >ESADI pdus? >> >> [hfw] If RB1 notify that the end-station moves from the link, RB1 will u= pdate >> >> and flood the LSP originated with nulling out the end-station address. W= hen other ESADI >> >> RBridge receives the updated LSP, they will forget the MAC "A" from its = MAC table. >> >> In this way, ESADI protocol can fast update the MAC table of remote RBri= dges when the end station attached >> >> is unpluged or a new end station is pluged. >> >> >> >> >Please correct me if my understanding is wrong. >> >> >Also could we recommend ESADI implemented RBridges to become DRB and >> >serve more AF for vlans. >> >> >Editorial comments and typos: >> >> >In Abstract >> >ESADI (End System Address Distribution Information) should be replaced = by >> >ESADI (End Station Address Distribution Information) as per RFC6325 >> >> >In section 3. ESADI DRB State >> >8th line: "for which RB1 is holding an ESADI-LSP zero with an ESADI >> >Pararmeters" , typo for "Parameters" >> >> >> >In section 4. ESADI PDU processing >> >4th line: "are only EASDI-LSP, EASDI-CSNP and EASDI-PSNP PDUs used >> >in ESADI."should be changed to >> > "are only ESADI-LSP, ESADI-CSNP and ESADI-PSNP PDUs used in ESADI." >> >> >In section 4.1 Sending of ESASI PDUs >> >> >Change the typo in the header itself. >> >> >4th line: "6(Innter.MacSA)" to '6(Inner.MacSA)" >> >> >5th line: "starting with the Intradomain Routeing Protocol >> >Discriminator," Typo "Routeing" to "Routing" >> >> >2nd Para, 1st line: "Once an ESADI instance is operationally up, it >> >multicasts it self- >> > originated LSP number zero on the virtual link to announce its ESADI >> > parameters." may be changed to >> >"Once an ESADI instance is operationally up, it multicasts/sends its se= lf- >> > originated LSP number zero on the virtual link to announce its ESADI >> > parameters." >> >> >5th Para, 2nd line: Typo "EASDI" >> >> >In section 5. ESADI-LSP Contents >> >7th line typo "EASDAI-LSPs >> >> >In section 5.1 ESADI Parameter Data >> >4th line typo "occurrnce" >> >> [hfw] Thanks for the correcting, we will correct it in the next version. >> >> >> somnath chatterjee >> =B7=A2=BC=FE=C8=CB: trill-bounces@ietf.org >> >> 2012-04-21 01:17 >> >> >> =CA=D5=BC=FE=C8=CB >> trill@ietf.org >> =B3=AD=CB=CD >> =D6=F7=CC=E2 >> [trill] [rbridge] draft-hu-trill-rbridge-esadi-04 >> >> >> >> >> >> >> >> Hi Authors, >> >> I have read the draft-hu-trill-rbridge-esadi-04 and support it. >> >> I have one question regarding the problem stated in the draft >> >> " 2. Fast update advantages: ESADI protocol provides a fast update of >> end nodes MAC (Media Access Control) addresses. If an end station >> is unplugged from one RBridge and plugged into another, frames >> addressed to that older RBridge can be black holed. They can be >> sent just to the older RBridge that the end station was connected >> to until cached address information at some remote RBridge times >> out, possibly for tens of seconds [RFC6325]." >> >> In this scenario when an end-station moves TO a link where an >> RBridge(RBx) with ESADI support is serving as AF for the vlan on which >> the end-station is connected, this RBridge sends the end-station MACs >> through ESADI pdu to other ESADI RBridges with a higher confidence and >> the old routes in other ESADI RBridges are over-written.New routes(MAC >> "A" is reachable via egress RBridge RBx) exist and frames destined to >> MAC "A" are not black holed. >> >> But what if this end-station moves FROM a link which has RBridge(RB1) >> with ESADI support TO a link where RBridge(RB2) donot have ESADI >> support. Is there any way RB1 can notify other ESADI implemented >> RBridges in the campus to flush the old route(MAC "A" is reachable via >> egress RB1) so that frames for MAC "A" are not send directly to RB1 >> and are rather treated as unknown unicast frame and send on a DTree? >> Could RB1 send to ESADI Implemented RBridges that MAC "A" is no longer >> reachable via itself by sending confidence as 0 for that MAC in its >> ESADI pdus? >> >> Please correct me if my understanding is wrong. >> >> Also could we recommend ESADI implemented RBridges to become DRB and >> serve more AF for vlans. >> >> Editorial comments and typos: >> >> In Abstract >> ESADI (End System Address Distribution Information) should be replaced b= y >> ESADI (End Station Address Distribution Information) as per RFC6325 >> >> In section 3. ESADI DRB State >> 8th line: "for which RB1 is holding an ESADI-LSP zero with an ESADI >> Pararmeters" , typo for "Parameters" >> >> >> In section 4. ESADI PDU processing >> 4th line: "are only EASDI-LSP, EASDI-CSNP and EASDI-PSNP PDUs used >> in ESADI."should be changed to >> "are only ESADI-LSP, ESADI-CSNP and ESADI-PSNP PDUs used in ESADI." >> >> In section 4.1 Sending of ESASI PDUs >> >> Change the typo in the header itself. >> >> 4th line: "6(Innter.MacSA)" to '6(Inner.MacSA)" >> >> 5th line: "starting with the Intradomain Routeing Protocol >> Discriminator," Typo "Routeing" to "Routing" >> >> 2nd Para, 1st line: "Once an ESADI instance is operationally up, it >> multicasts it self- >> originated LSP number zero on the virtual link to announce its ESADI >> parameters." may be changed to >> "Once an ESADI instance is operationally up, it multicasts/sends its sel= f- >> originated LSP number zero on the virtual link to announce its ESADI >> parameters." >> >> 5th Para, 2nd line: Typo "EASDI" >> >> In section 5. ESADI-LSP Contents >> 7th line typo "EASDAI-LSPs >> >> In section 5.1 ESADI Parameter Data >> 4th line typo "occurrnce" >> >> Thank you, >> Regards, >> Somnath >> _______________________________________________ >> trill mailing list >> trill@ietf.org >> https://www.ietf.org/mailman/listinfo/trill >> >> >> > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill From somnath.chatterjee01@gmail.com Tue Apr 24 01:58:13 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B6421F86EE; Tue, 24 Apr 2012 01:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.543 X-Spam-Level: X-Spam-Status: No, score=0.543 tagged_above=-999 required=5 tests=[AWL=-0.708, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_75=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] 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 XPNKbhbsyeO3; Tue, 24 Apr 2012 01:58:12 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id C69BD21F86D3; Tue, 24 Apr 2012 01:58:11 -0700 (PDT) Received: by ghbg16 with SMTP id g16so200306ghb.31 for ; Tue, 24 Apr 2012 01:58:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ZL+8tCX2FI23v+I+I3q3ymomdzXQwbbsIt/ES5uFyYk=; b=o6Qhgxe0qjkBr+3UEKlF0kzQmIBJcpIS1goZsEO8UNl32vKNTlWfNNzPbQc1bDYnk1 HfVc2taRy5oQYmo3sfxkc7Nef81BCt4Qt5CZpR0UsHZ5M2GjDJ5eoTa+44YrCafXXsAn dFtx941ey6G2lew3+gF+jH8FAniPuhrZL2Qo7ITrJkJB9Ctzqm8dktcM3JjFtVpZcn6g QHLta8/emYz1TBCIqPTR06A53Udj6++uITX0g1GoUvFrto4Z2aC+O//gbipK+boSsNdp UmWMapABAeaHB4xOjxMYwMSVpfxFojL9r/ZqCs5mmArp0BP0CPJc56zUSH2z3EUpXwko ykSA== MIME-Version: 1.0 Received: by 10.101.20.1 with SMTP id x1mr2988899ani.36.1335257891291; Tue, 24 Apr 2012 01:58:11 -0700 (PDT) Received: by 10.146.255.30 with HTTP; Tue, 24 Apr 2012 01:58:11 -0700 (PDT) In-Reply-To: References: Date: Tue, 24 Apr 2012 14:28:11 +0530 Message-ID: From: somnath chatterjee To: Donald Eastlake Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: trill-bounces@ietf.org, hu.fangwei@zte.com.cn, trill@ietf.org Subject: Re: [trill] [rbridge] draft-hu-trill-rbridge-esadi-04 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 08:58:13 -0000 Hi Donald, Please consider a scenario where the "from" RBridge has ESADI(RB1), the "to" RBridge is non-ESADI(RB2) and there is another ESADI RBridge(RB3) which is neither "to" or "from" but in the campus. I was concerned about the this RB3 which will receive ESADI LSP from RB1. If the RB1 had previously chosen not to include the End-Station MAC in its earlier ESADI-LSP, the RB3 has no way to know that the this MAC is to be flushed when it receives the updated ESADI-LSP from RB1. I assume that ESADI RBridges will compare previous ESADI-LSP and latest ESADI-LSP to find the lost MACs. As ESADI RBridges MAY send partial information about End-Stations connected to it, comparing previous and latest ESADI-LSPs may not always give complete information about lost MACs. So if there was a way to notify explicitly about the lost MACs it would be easy for an ESADI RBridge to conclude about the lost MACs, also comparing previous and current ESADI-LSPs overhead will not exist. Please correct me if my understanding is wrong. Thank you, Regards, Somnath 2012/4/24 Donald Eastlake : > Hi Somnath, > > Generally speaking, on your questions about what happens if a end > station moves from being connected to an ESADI RBridge that is > advertising the end stations MAC address to a non-ESADI RBridge, where > both are Appointed Forwarders for the stations VLAN, what happens. If > the "from" RBridge notices, it removed that MAC address from its > ESADI-LSP. By the ESADI flooding, that updated LSP without the MAC > address will get to all other participating ESADI RBridges for that > VLAN. > > If the "to" RBridge is not an ESADI RBridge, then, of course, you do > not get any benefit from ESADI for the connection to it. > > There is little, if any benefit, from trying to play around with > dymanically set confidences in this case. If both the "from" and "to" > RBridges are ESADI RBridges and they both think MAC address M is > connected in VLAN V for which they are participating in ESADI, then > both with advertise this in their ESADI-LSP. An implementation could > keep track of when if gets LSP updates and try to figure out which was > more recent. > > See below. > > 2012/4/23 somnath chatterjee : >> Hi , >> >> In introduction of draft-hu-trill-rbridge-esadi-04 >> " An RBridge that is announcing connectivity to VLAN-x (normally a >> VLAN-x appointed forwarder) MAY use the (ESADI) protocol to announce >> the end station address of some or all of its attached VLAN-x end >> nodes to other RBridges that are running ESADI for VLAN-x." >> >> An ESADI supported RBridge MAY selectively send about end-station MACs >> and MAY opt to not send all the end-station MACs. >> >> I am only suggesting to send MAC in updated ESADI-LSP with confidence >> zero(for every lost MAC), so that other ESADI RBridges could easily >> recognize that this MAC needs to be deleted, rather than compare it >> with previously stored information and then delete. > > It is stronger to just drop the MAC for your ESADI-LSP. Other EASDI > RBridges need to look at your update to figure out if/how to update > their FIB in any case. > > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > >> Thank you, >> Regards, >> Somnath >> >> 2012/4/23 >>> >>> >>> Hi, chatterjee >>> >>> By my understanding, If RB1 supports ESADI, it advertises all the end-s= tation MAC attached to the remote RBridges. >>> >>> The remote RBridge can do some policy forwarding based on the MAC addre= ss, but I think it is no need to opt to send the end-station MAC by the loc= al RBridge. >>> >>> Regards >>> >>> >>> somnath chatterjee >>> >>> 2012-04-23 14:57 >>> >>> =CA=D5=BC=FE=C8=CB >>> hu.fangwei@zte.com.cn >>> =B3=AD=CB=CD >>> trill@ietf.org, trill-bounces@ietf.org >>> =D6=F7=CC=E2 >>> Re: [trill] [rbridge] draft-hu-trill-rbridge-esadi-04 >>> >>> >>> >>> >>> >>> Hi Fangwei, >>> >>> Thank you for the explanation. >>> >>> So, RB1 doesnot include the end-stations MAC in its LSP. What if RB1 ha= s opted not to send this end-station MAC in its ESADI-LSP earlier? The othe= r ESADI RBridges has no way to learn that this MAC has to be flushed(which = may be learned through other procedures except ESADI). It would be good if = ESADI RBridges could explicitly tell other RBridges to forget a MAC. >>> >>> Regards, >>> Somnath >>> >>> 2012/4/22 >>> >>> Thanks for the reviewing and comments. >>> >>> Pls see the following in line. >>> >>> >Hi Authors, >>> >>> >I have read the draft-hu-trill-rbridge-esadi-04 and support it. >>> >>> >I have one question regarding the problem stated in the draft >>> >>> > " 2. Fast update advantages: ESADI protocol provides a fast update of >>> end nodes MAC (Media Access Control) addresses. If an end station >>> is unplugged from one RBridge and plugged into another, frames >>> addressed to that older RBridge can be black holed. They can be >>> sent just to the older RBridge that the end station was connected >>> to until cached address information at some remote RBridge times >>> out, possibly for tens of seconds [RFC6325]." >>> >>> >In this scenario when an end-station moves TO a link where an >>> >RBridge(RBx) with ESADI support is serving as AF for the vlan on which >>> >the end-station is connected, this RBridge sends the end-station MACs >>> >through ESADI pdu to other ESADI RBridges with a higher confidence and >>> >the old routes in other ESADI RBridges are over-written.New routes(MAC >>> >"A" is reachable via egress RBridge RBx) exist and frames destined to >>> >MAC "A" are not black holed. >>> >>> >But what if this end-station moves FROM a link which has RBridge(RB1) >>> >with ESADI support TO a link where RBridge(RB2) donot have ESADI >>> >support. Is there any way RB1 can notify other ESADI implemented >>> >RBridges in the campus to flush the old route(MAC "A" is reachable via >>> >egress RB1) so that frames for MAC "A" are not send directly to RB1 >>> >and are rather treated as unknown unicast frame and send on a DTree? >>> >Could RB1 send to ESADI Implemented RBridges that MAC "A" is no longer >>> >reachable via itself by sending confidence as 0 for that MAC in its >>> >ESADI pdus? >>> >>> [hfw] If RB1 notify that the end-station moves from the link, RB1 will = update >>> >>> and flood the LSP originated with nulling out the end-station address. = When other ESADI >>> >>> RBridge receives the updated LSP, they will forget the MAC "A" from its= MAC table. >>> >>> In this way, ESADI protocol can fast update the MAC table of remote RBr= idges when the end station attached >>> >>> is unpluged or a new end station is pluged. >>> >>> >>> >>> >Please correct me if my understanding is wrong. >>> >>> >Also could we recommend ESADI implemented RBridges to become DRB and >>> >serve more AF for vlans. >>> >>> >Editorial comments and typos: >>> >>> >In Abstract >>> >ESADI (End System Address Distribution Information) should be replaced= by >>> >ESADI (End Station Address Distribution Information) as per RFC6325 >>> >>> >In section 3. ESADI DRB State >>> >8th line: "for which RB1 is holding an ESADI-LSP zero with an ESADI >>> >Pararmeters" , typo for "Parameters" >>> >>> >>> >In section 4. ESADI PDU processing >>> >4th line: "are only EASDI-LSP, EASDI-CSNP and EASDI-PSNP PDUs used >>> >in ESADI."should be changed to >>> > "are only ESADI-LSP, ESADI-CSNP and ESADI-PSNP PDUs used in ESADI." >>> >>> >In section 4.1 Sending of ESASI PDUs >>> >>> >Change the typo in the header itself. >>> >>> >4th line: "6(Innter.MacSA)" to '6(Inner.MacSA)" >>> >>> >5th line: "starting with the Intradomain Routeing Protocol >>> >Discriminator," Typo "Routeing" to "Routing" >>> >>> >2nd Para, 1st line: "Once an ESADI instance is operationally up, it >>> >multicasts it self- >>> > originated LSP number zero on the virtual link to announce its ESADI >>> > parameters." may be changed to >>> >"Once an ESADI instance is operationally up, it multicasts/sends its s= elf- >>> > originated LSP number zero on the virtual link to announce its ESAD= I >>> > parameters." >>> >>> >5th Para, 2nd line: Typo "EASDI" >>> >>> >In section 5. ESADI-LSP Contents >>> >7th line typo "EASDAI-LSPs >>> >>> >In section 5.1 ESADI Parameter Data >>> >4th line typo "occurrnce" >>> >>> [hfw] Thanks for the correcting, we will correct it in the next version= . >>> >>> >>> somnath chatterjee >>> =B7=A2=BC=FE=C8=CB: trill-bounces@ietf.org >>> >>> 2012-04-21 01:17 >>> >>> >>> =CA=D5=BC=FE=C8=CB >>> trill@ietf.org >>> =B3=AD=CB=CD >>> =D6=F7=CC=E2 >>> [trill] [rbridge] draft-hu-trill-rbridge-esadi-04 >>> >>> >>> >>> >>> >>> >>> >>> Hi Authors, >>> >>> I have read the draft-hu-trill-rbridge-esadi-04 and support it. >>> >>> I have one question regarding the problem stated in the draft >>> >>> " 2. Fast update advantages: ESADI protocol provides a fast update of >>> end nodes MAC (Media Access Control) addresses. If an end station >>> is unplugged from one RBridge and plugged into another, frames >>> addressed to that older RBridge can be black holed. They can be >>> sent just to the older RBridge that the end station was connected >>> to until cached address information at some remote RBridge times >>> out, possibly for tens of seconds [RFC6325]." >>> >>> In this scenario when an end-station moves TO a link where an >>> RBridge(RBx) with ESADI support is serving as AF for the vlan on which >>> the end-station is connected, this RBridge sends the end-station MACs >>> through ESADI pdu to other ESADI RBridges with a higher confidence and >>> the old routes in other ESADI RBridges are over-written.New routes(MAC >>> "A" is reachable via egress RBridge RBx) exist and frames destined to >>> MAC "A" are not black holed. >>> >>> But what if this end-station moves FROM a link which has RBridge(RB1) >>> with ESADI support TO a link where RBridge(RB2) donot have ESADI >>> support. Is there any way RB1 can notify other ESADI implemented >>> RBridges in the campus to flush the old route(MAC "A" is reachable via >>> egress RB1) so that frames for MAC "A" are not send directly to RB1 >>> and are rather treated as unknown unicast frame and send on a DTree? >>> Could RB1 send to ESADI Implemented RBridges that MAC "A" is no longer >>> reachable via itself by sending confidence as 0 for that MAC in its >>> ESADI pdus? >>> >>> Please correct me if my understanding is wrong. >>> >>> Also could we recommend ESADI implemented RBridges to become DRB and >>> serve more AF for vlans. >>> >>> Editorial comments and typos: >>> >>> In Abstract >>> ESADI (End System Address Distribution Information) should be replaced = by >>> ESADI (End Station Address Distribution Information) as per RFC6325 >>> >>> In section 3. ESADI DRB State >>> 8th line: "for which RB1 is holding an ESADI-LSP zero with an ESADI >>> Pararmeters" , typo for "Parameters" >>> >>> >>> In section 4. ESADI PDU processing >>> 4th line: "are only EASDI-LSP, EASDI-CSNP and EASDI-PSNP PDUs used >>> in ESADI."should be changed to >>> "are only ESADI-LSP, ESADI-CSNP and ESADI-PSNP PDUs used in ESADI." >>> >>> In section 4.1 Sending of ESASI PDUs >>> >>> Change the typo in the header itself. >>> >>> 4th line: "6(Innter.MacSA)" to '6(Inner.MacSA)" >>> >>> 5th line: "starting with the Intradomain Routeing Protocol >>> Discriminator," Typo "Routeing" to "Routing" >>> >>> 2nd Para, 1st line: "Once an ESADI instance is operationally up, it >>> multicasts it self- >>> originated LSP number zero on the virtual link to announce its ESADI >>> parameters." may be changed to >>> "Once an ESADI instance is operationally up, it multicasts/sends its se= lf- >>> originated LSP number zero on the virtual link to announce its ESADI >>> parameters." >>> >>> 5th Para, 2nd line: Typo "EASDI" >>> >>> In section 5. ESADI-LSP Contents >>> 7th line typo "EASDAI-LSPs >>> >>> In section 5.1 ESADI Parameter Data >>> 4th line typo "occurrnce" >>> >>> Thank you, >>> Regards, >>> Somnath >>> _______________________________________________ >>> trill mailing list >>> trill@ietf.org >>> https://www.ietf.org/mailman/listinfo/trill >>> >>> >>> >> _______________________________________________ >> trill mailing list >> trill@ietf.org >> https://www.ietf.org/mailman/listinfo/trill From d3e3e3@gmail.com Tue Apr 24 17:10:42 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4E411E8074 for ; Tue, 24 Apr 2012 17:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.423 X-Spam-Level: X-Spam-Status: No, score=-101.423 tagged_above=-999 required=5 tests=[AWL=-2.674, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_75=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 AEe3zfunkSzg for ; Tue, 24 Apr 2012 17:10:40 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 541B411E80B7 for ; Tue, 24 Apr 2012 17:10:40 -0700 (PDT) Received: by lagj5 with SMTP id j5so1044423lag.31 for ; Tue, 24 Apr 2012 17:10:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=3bbpHsAzcTTXEBkluynfMUEQXC2Slda3F17Jg9NWZHU=; b=Y+1k2auUebBag2oDRENPgzy17hz+e1Qbub3uOP02yVp/psPujmPKdtZS7LuDMHqwlM BfX8mOhzVNGeJpVhfzhs5iABonu1v6574xLiWjcjDr8J3LaGAwHR27DUsBMfS243oIRI ZJMr6NJ6zYIWrzNrKlHYjR3fybWZmhCGAwQsNJ+w8kClLrqYxNRSxAbgLrS4Nd4sqgNp 9OUx14Ew/vfLkHMADpnjNoKQHWhmFoMsAdXJMS1L0IJaqTgpr9gRCdQ3T46RFGg8ayb7 ujFoeUEybvF0H1zWoUfAmMRNfED53BmT4mK7AYN0dKTGRNEFTUI1BrJEl5gTefSsPwv6 y8yQ== Received: by 10.112.8.197 with SMTP id t5mr240573lba.46.1335312639003; Tue, 24 Apr 2012 17:10:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.144.8 with HTTP; Tue, 24 Apr 2012 17:10:18 -0700 (PDT) In-Reply-To: References: From: Donald Eastlake Date: Tue, 24 Apr 2012 20:10:18 -0400 Message-ID: To: somnath chatterjee Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: Hu Fangwei , trill@ietf.org Subject: [trill] Fwd: [rbridge] draft-hu-trill-rbridge-esadi-04 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 00:10:42 -0000 Hi Somnath, 2012/4/24 somnath chatterjee : > Hi Donald, > > Please consider a scenario where the "from" RBridge has ESADI(RB1), > the "to" RBridge is non-ESADI(RB2) and there is another ESADI > RBridge(RB3) which is neither "to" or "from" but in the campus. I was > concerned about the this RB3 which will receive ESADI LSP from RB1. If > the RB1 had previously chosen not to include the End-Station MAC in > its earlier ESADI-LSP, the RB3 has no way to know that the this MAC is > to be flushed when it receives the updated ESADI-LSP from RB1. As a very general comment, TRILL provides many tools and does not generally demand that they be used in some specify way. It was important in designing TRILL that default operations, without various options, be something reasonable. But if someone starts to implement various optional feature or to configure priorities or whatever, it is general up to them to figure out how to do this to get a good result. Some things, like how the DRB should determine what, if any, other RBridges on a multi-RBridge link should be appointed forwarders for what VLANs were deliberately left out of scope because it seems complicated, with lots of factors that could be taken into account, and an area where different implementors could compete. Your statement above about what might happen seem right, but so what? Why did the network manager choose not to use ESADI to advertise the MAC address involved? Is data plane address learning also enabled at these RBridges? Shouldn't it be obvious that if you have data plane learning enabled (which is the default) and you don't use ESADI for MAC address M1, then you get data plane / time-out driven behavior for M1? What else would you expect? > I assume that ESADI RBridges will compare previous ESADI-LSP and > latest ESADI-LSP to find the lost MACs. Well, at least logically, that's not the way I look at it. An RBridge can have various MAC address learning information including manually configured addresses, data plane learned addresses, and addresses in its ESADI link state database. So, if any of this information changes, then potentially it needs to update its MAC forwarding tables, using the rules in RFC 6325 to reconcile conflicts between these different types of information. There are various ways it can optimize this update process including comparing old versus new information. > As ESADI RBridges MAY send > partial information about End-Stations connected to it, comparing > previous and latest ESADI-LSPs may not always give complete > information about lost MACs. I would guess that there would normally be some specific reason for leaving some MAC address out. For example, there are a few MAC attachments that are more important to transmit securely or that are more dynamic and it is important to update quickly, and for which the data being sent/received is usually to other RBridges that implement ESADI. So it makes sense to include those MACs. While there is another set of MAC attachments for which security / rapid update is less important and/or it is known that most of the other RBridges for which data from/to such MACs is communicated don't implement ESADI so it is pointless to communicate them in ESADI. > So if there was a way to notify > explicitly about the lost MACs it would be easy for an ESADI RBridge > to conclude about the lost MACs, also comparing previous and current > ESADI-LSPs overhead will not exist. But you would have the overhead of processing the new MAC unlearn message, which might have to be sent to all RBridges attached to a VLAN unless you carefully tracked every RBridge that might have learned the MAC... Adding some optional way to remotely delete one or more MAC addresses is a reasonable idea but I don't think you would necessarily always want to use it even if it was available. Sometimes the existing data plane learning is fine... Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > Please correct me if my understanding is wrong. > > Thank you, > Regards, > Somnath > > > 2012/4/24 Donald Eastlake : >> Hi Somnath, >> >> Generally speaking, on your questions about what happens if a end >> station moves from being connected to an ESADI RBridge that is >> advertising the end stations MAC address to a non-ESADI RBridge, where >> both are Appointed Forwarders for the stations VLAN, what happens. If >> the "from" RBridge notices, it removed that MAC address from its >> ESADI-LSP. By the ESADI flooding, that updated LSP without the MAC >> address will get to all other participating ESADI RBridges for that >> VLAN. >> >> If the "to" RBridge is not an ESADI RBridge, then, of course, you do >> not get any benefit from ESADI for the connection to it. >> >> There is little, if any benefit, from trying to play around with >> dymanically set confidences in this case. If both the "from" and "to" >> RBridges are ESADI RBridges and they both think MAC address M is >> connected in VLAN V for which they are participating in ESADI, then >> both with advertise this in their ESADI-LSP. An implementation could >> keep track of when if gets LSP updates and try to figure out which was >> more recent. >> >> See below. >> >> 2012/4/23 somnath chatterjee : >>> Hi , >>> >>> In introduction of draft-hu-trill-rbridge-esadi-04 >>> " An RBridge that is announcing connectivity to VLAN-x (normally a >>> VLAN-x appointed forwarder) MAY use the (ESADI) protocol to announce >>> the end station address of some or all of its attached VLAN-x end >>> nodes to other RBridges that are running ESADI for VLAN-x." >>> >>> An ESADI supported RBridge MAY selectively send about end-station MACs >>> and MAY opt to not send all the end-station MACs. >>> >>> I am only suggesting to send MAC in updated ESADI-LSP with confidence >>> zero(for every lost MAC), so that other ESADI RBridges could easily >>> recognize that this MAC needs to be deleted, rather than compare it >>> with previously stored information and then delete. >> >> It is stronger to just drop the MAC for your ESADI-LSP. Other EASDI >> RBridges need to look at your update to figure out if/how to update >> their FIB in any case. >> >> Thanks, >> Donald >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> 155 Beaver Street, Milford, MA 01757 USA >> d3e3e3@gmail.com >> >>> Thank you, >>> Regards, >>> Somnath >>> >>> 2012/4/23 >>>> >>>> >>>> Hi, chatterjee >>>> >>>> By my understanding, If RB1 supports ESADI, it advertises all the end-= station MAC attached to the remote RBridges. >>>> >>>> The remote RBridge can do some policy forwarding based on the MAC addr= ess, but I think it is no need to opt to send the end-station MAC by the lo= cal RBridge. >>>> >>>> Regards >>>> >>>> >>>> somnath chatterjee >>>> >>>> 2012-04-23 14:57 >>>> >>>> =CA=D5=BC=FE=C8=CB >>>> hu.fangwei@zte.com.cn >>>> =B3=AD=CB=CD >>>> trill@ietf.org, trill-bounces@ietf.org >>>> =D6=F7=CC=E2 >>>> Re: [trill] [rbridge] draft-hu-trill-rbridge-esadi-04 >>>> >>>> >>>> >>>> >>>> >>>> Hi Fangwei, >>>> >>>> Thank you for the explanation. >>>> >>>> So, RB1 doesnot include the end-stations MAC in its LSP. What if RB1 h= as opted not to send this end-station MAC in its ESADI-LSP earlier? The oth= er ESADI RBridges has no way to learn that this MAC has to be flushed(which= may be learned through other procedures except ESADI). It would be good if= ESADI RBridges could explicitly tell other RBridges to forget a MAC. >>>> >>>> Regards, >>>> Somnath >>>> >>>> 2012/4/22 >>>> >>>> Thanks for the reviewing and comments. >>>> >>>> Pls see the following in line. >>>> >>>> >Hi Authors, >>>> >>>> >I have read the draft-hu-trill-rbridge-esadi-04 and support it. >>>> >>>> >I have one question regarding the problem stated in the draft >>>> >>>> > " 2. Fast update advantages: ESADI protocol provides a fast update o= f >>>> end nodes MAC (Media Access Control) addresses. If an end station >>>> is unplugged from one RBridge and plugged into another, frames >>>> addressed to that older RBridge can be black holed. They can be >>>> sent just to the older RBridge that the end station was connected >>>> to until cached address information at some remote RBridge times >>>> out, possibly for tens of seconds [RFC6325]." >>>> >>>> >In this scenario when an end-station moves TO a link where an >>>> >RBridge(RBx) with ESADI support is serving as AF for the vlan on whic= h >>>> >the end-station is connected, this RBridge sends the end-station MACs >>>> >through ESADI pdu to other ESADI RBridges with a higher confidence an= d >>>> >the old routes in other ESADI RBridges are over-written.New routes(MA= C >>>> >"A" is reachable via egress RBridge RBx) exist and frames destined to >>>> >MAC "A" are not black holed. >>>> >>>> >But what if this end-station moves FROM a link which has RBridge(RB1) >>>> >with ESADI support TO a link where RBridge(RB2) donot have ESADI >>>> >support. Is there any way RB1 can notify other ESADI implemented >>>> >RBridges in the campus to flush the old route(MAC "A" is reachable vi= a >>>> >egress RB1) so that frames for MAC "A" are not send directly to RB1 >>>> >and are rather treated as unknown unicast frame and send on a DTree? >>>> >Could RB1 send to ESADI Implemented RBridges that MAC "A" is no longe= r >>>> >reachable via itself by sending confidence as 0 for that MAC in its >>>> >ESADI pdus? >>>> >>>> [hfw] If RB1 notify that the end-station moves from the link, RB1 will= update >>>> >>>> and flood the LSP originated with nulling out the end-station address.= When other ESADI >>>> >>>> RBridge receives the updated LSP, they will forget the MAC "A" from it= s MAC table. >>>> >>>> In this way, ESADI protocol can fast update the MAC table of remote RB= ridges when the end station attached >>>> >>>> is unpluged or a new end station is pluged. >>>> >>>> >>>> >>>> >Please correct me if my understanding is wrong. >>>> >>>> >Also could we recommend ESADI implemented RBridges to become DRB and >>>> >serve more AF for vlans. >>>> >>>> >Editorial comments and typos: >>>> >>>> >In Abstract >>>> >ESADI (End System Address Distribution Information) should be replace= d by >>>> >ESADI (End Station Address Distribution Information) as per RFC6325 >>>> >>>> >In section 3. ESADI DRB State >>>> >8th line: "for which RB1 is holding an ESADI-LSP zero with an ESADI >>>> >Pararmeters" , typo for "Parameters" >>>> >>>> >>>> >In section 4. ESADI PDU processing >>>> >4th line: "are only EASDI-LSP, EASDI-CSNP and EASDI-PSNP PDUs use= d >>>> >in ESADI."should be changed to >>>> > "are only ESADI-LSP, ESADI-CSNP and ESADI-PSNP PDUs used in ESADI.= " >>>> >>>> >In section 4.1 Sending of ESASI PDUs >>>> >>>> >Change the typo in the header itself. >>>> >>>> >4th line: "6(Innter.MacSA)" to '6(Inner.MacSA)" >>>> >>>> >5th line: "starting with the Intradomain Routeing Protocol >>>> >Discriminator," Typo "Routeing" to "Routing" >>>> >>>> >2nd Para, 1st line: "Once an ESADI instance is operationally up, it >>>> >multicasts it self- >>>> > originated LSP number zero on the virtual link to announce its ESAD= I >>>> > parameters." may be changed to >>>> >"Once an ESADI instance is operationally up, it multicasts/sends its = self- >>>> > originated LSP number zero on the virtual link to announce its ESA= DI >>>> > parameters." >>>> >>>> >5th Para, 2nd line: Typo "EASDI" >>>> >>>> >In section 5. ESADI-LSP Contents >>>> >7th line typo "EASDAI-LSPs >>>> >>>> >In section 5.1 ESADI Parameter Data >>>> >4th line typo "occurrnce" >>>> >>>> [hfw] Thanks for the correcting, we will correct it in the next versio= n. >>>> >>>> >>>> somnath chatterjee >>>> =B7=A2=BC=FE=C8=CB: trill-bounces@ietf.org >>>> >>>> 2012-04-21 01:17 >>>> >>>> >>>> =CA=D5=BC=FE=C8=CB >>>> trill@ietf.org >>>> =B3=AD=CB=CD >>>> =D6=F7=CC=E2 >>>> [trill] [rbridge] draft-hu-trill-rbridge-esadi-04 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Hi Authors, >>>> >>>> I have read the draft-hu-trill-rbridge-esadi-04 and support it. >>>> >>>> I have one question regarding the problem stated in the draft >>>> >>>> " 2. Fast update advantages: ESADI protocol provides a fast update of >>>> end nodes MAC (Media Access Control) addresses. If an end station >>>> is unplugged from one RBridge and plugged into another, frames >>>> addressed to that older RBridge can be black holed. They can be >>>> sent just to the older RBridge that the end station was connected >>>> to until cached address information at some remote RBridge times >>>> out, possibly for tens of seconds [RFC6325]." >>>> >>>> In this scenario when an end-station moves TO a link where an >>>> RBridge(RBx) with ESADI support is serving as AF for the vlan on which >>>> the end-station is connected, this RBridge sends the end-station MACs >>>> through ESADI pdu to other ESADI RBridges with a higher confidence and >>>> the old routes in other ESADI RBridges are over-written.New routes(MAC >>>> "A" is reachable via egress RBridge RBx) exist and frames destined to >>>> MAC "A" are not black holed. >>>> >>>> But what if this end-station moves FROM a link which has RBridge(RB1) >>>> with ESADI support TO a link where RBridge(RB2) donot have ESADI >>>> support. Is there any way RB1 can notify other ESADI implemented >>>> RBridges in the campus to flush the old route(MAC "A" is reachable via >>>> egress RB1) so that frames for MAC "A" are not send directly to RB1 >>>> and are rather treated as unknown unicast frame and send on a DTree? >>>> Could RB1 send to ESADI Implemented RBridges that MAC "A" is no longer >>>> reachable via itself by sending confidence as 0 for that MAC in its >>>> ESADI pdus? >>>> >>>> Please correct me if my understanding is wrong. >>>> >>>> Also could we recommend ESADI implemented RBridges to become DRB and >>>> serve more AF for vlans. >>>> >>>> Editorial comments and typos: >>>> >>>> In Abstract >>>> ESADI (End System Address Distribution Information) should be replaced= by >>>> ESADI (End Station Address Distribution Information) as per RFC6325 >>>> >>>> In section 3. ESADI DRB State >>>> 8th line: "for which RB1 is holding an ESADI-LSP zero with an ESADI >>>> Pararmeters" , typo for "Parameters" >>>> >>>> >>>> In section 4. ESADI PDU processing >>>> 4th line: "are only EASDI-LSP, EASDI-CSNP and EASDI-PSNP PDUs used >>>> in ESADI."should be changed to >>>> "are only ESADI-LSP, ESADI-CSNP and ESADI-PSNP PDUs used in ESADI." >>>> >>>> In section 4.1 Sending of ESASI PDUs >>>> >>>> Change the typo in the header itself. >>>> >>>> 4th line: "6(Innter.MacSA)" to '6(Inner.MacSA)" >>>> >>>> 5th line: "starting with the Intradomain Routeing Protocol >>>> Discriminator," Typo "Routeing" to "Routing" >>>> >>>> 2nd Para, 1st line: "Once an ESADI instance is operationally up, it >>>> multicasts it self- >>>> originated LSP number zero on the virtual link to announce its ESADI >>>> parameters." may be changed to >>>> "Once an ESADI instance is operationally up, it multicasts/sends its s= elf- >>>> originated LSP number zero on the virtual link to announce its ESADI >>>> parameters." >>>> >>>> 5th Para, 2nd line: Typo "EASDI" >>>> >>>> In section 5. ESADI-LSP Contents >>>> 7th line typo "EASDAI-LSPs >>>> >>>> In section 5.1 ESADI Parameter Data >>>> 4th line typo "occurrnce" >>>> >>>> Thank you, >>>> Regards, >>>> Somnath >>>> _______________________________________________ >>>> trill mailing list >>>> trill@ietf.org >>>> https://www.ietf.org/mailman/listinfo/trill >>>> >>>> >>>> >>> _______________________________________________ >>> trill mailing list >>> trill@ietf.org >>> https://www.ietf.org/mailman/listinfo/trill From huutho411@gmail.com Wed Apr 25 04:01:46 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D47F21F86DC for ; Wed, 25 Apr 2012 04:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_LOW=-1] 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 493rjeBWvdj0 for ; Wed, 25 Apr 2012 04:01:45 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE4E21F86D9 for ; Wed, 25 Apr 2012 04:01:45 -0700 (PDT) Received: by qcsq13 with SMTP id q13so1071827qcs.31 for ; Wed, 25 Apr 2012 04:01:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=dsk3HjdTi+bkEsP0N74iBn+fWasQzkYJgHnPNCEf5/8=; b=hxSt/8+r95boHhuqDYPEBqr3kdUOty9Hz0u3Eez1Y7avNkq2UQ3b0vaEFtuUe+C3B8 +wXX4DblUsRYeLVjPKJEqEsQuJoeYE4gWuPQNryDu/PP6dnCFjF3W8avUdgo/IfWaWZg vOeU40mvoU103GEoGE9fqROu/xCShKZCH5BoSaMMaQQUWFvTvl+TlmQ22pLs6R5rRNSd 5vpKlhJcL2Xw7m92tZZcmSfaQFQnW+Wo1V8m8S5ZxO5tI2AiylFsjSkDxcP9wxnuUiQ0 Fx8zbT2LHmQUgpSbvek9y86PYmiXhw3O13KMsKg8OXcH8SHL6w1ZMKF3D6cAf/SOrypl xiYA== MIME-Version: 1.0 Received: by 10.224.220.145 with SMTP id hy17mr1658133qab.2.1335351705126; Wed, 25 Apr 2012 04:01:45 -0700 (PDT) Received: by 10.229.99.200 with HTTP; Wed, 25 Apr 2012 04:01:45 -0700 (PDT) Date: Wed, 25 Apr 2012 18:01:45 +0700 Message-ID: From: Nguyen Huu Tho To: trill@ietf.org Content-Type: multipart/alternative; boundary=20cf3074d75808c79204be7ecc12 Subject: [trill] Some question about TRILL IS-IS and Distribution Tree X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 11:01:46 -0000 --20cf3074d75808c79204be7ecc12 Content-Type: text/plain; charset=UTF-8 Dear all, I have some questions about trill IS-IS and Distribution Tree. Anybody can help me ? 1. When TRILL use IS-IS, TRILL has a new type of hello message which is called TRILL HELLO. So, IS-IS HELLO of original IS-IS still have used or TRILL hello message includes all function of original IS-IS hello and original IS-IS HELLO isn't exist. 2. Is there any mechanism for each RBridge to choose the used distribution tree and advertise them to other RBridges 3. In RFC 6325, In distribution tree part, When the RB having the highest tree root priority send a list of s tree roots nickname. Why we have the case s < k trees which all RBs in the campus must calculate ? 4. When Ingress RB have multi nicknames, there is any mechanism to choose which nicknames the RB will put in the Ingress nickname of TRILL header of this frame 5. When a Ingress RB1 receive a multi-destination frames, when the Ingress RB1 choose the distribution tree (have tree root is RB4). When the frame reaches to the RB4, whether the tree root send the frame to RB2 with outer.MacDA is All-RBridges or unicast Outer.MacDA ? And when the frame reaches to RB4, whether RB send to all nodes in this distribution tree with the outer.MacDA is All-RBridges or not? (RB2) === (RB4) (tree root) // \\ (Ingress) (RB1) (RB3) Thanks , -- +-- | Nguyen Huu Tho. Mail: huutho411@gmail.com | --+ --20cf3074d75808c79204be7ecc12 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear all,=C2=A0

I have some questions about trill IS-IS = and Distribution Tree. Anybody can help me ?

1. When TRILL use IS-IS, TRILL has a new type of hello messag= e which is called TRILL HELLO.=C2=A0
So, IS-IS HELLO of original IS-IS still have used or TRILL = hello message includes all function of original IS-IS hello and original IS= -IS HELLO isn't exist.

2.=C2=A0Is there any me= chanism for each RBridge to choose the used distribution tree and advertise= them to other RBridges

3. In RFC 6325, In distribution tree part, When the RB = having the highest tree root priority send a list of s tree roots nickname.= Why we have the case s < k trees which all RBs in the campus must calcu= late ?

4. When Ingress RB have multi nicknames, there is any m= echanism to choose which nicknames the RB will put in the Ingress nickname = of TRILL header of this frame

5. When a Ingress RB= 1 receive a multi-destination frames, when the Ingress RB1 choose the distr= ibution tree (have tree root is RB4). When the frame reaches to the RB4, wh= ether the tree root send the frame to RB2 with outer.MacDA is All-RBridges = or unicast Outer.MacDA ?=C2=A0
And when the frame reaches to RB4, whether RB send to all nodes in thi= s distribution tree with the outer.MacDA is All-RBridges or not?
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 (RB2) =C2=A0 =C2=A0 =3D=3D=3D (RB4) (tree root)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 \\ =C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (Ingress) = (RB1) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (RB3) =C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0=


Thanks ,
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0
--=
+--
| Nguyen Huu Tho.
=C2=A0=C2=A0 Mail: huutho411@gmail.com=C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --+

--20cf3074d75808c79204be7ecc12-- From somnath.chatterjee01@gmail.com Wed Apr 25 04:10:03 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 013B721F872E for ; Wed, 25 Apr 2012 04:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.72 X-Spam-Level: X-Spam-Status: No, score=0.72 tagged_above=-999 required=5 tests=[AWL=-0.531, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_75=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] 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 b8v2OMeHUCoT for ; Wed, 25 Apr 2012 04:10:00 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id F29EC21F86FA for ; Wed, 25 Apr 2012 04:09:59 -0700 (PDT) Received: by yenm5 with SMTP id m5so1186791yen.31 for ; Wed, 25 Apr 2012 04:09:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=kF8fwI2zXmanxSCYzT2yXyQftuK+O5ieTeHtargyMRY=; b=TQhAzDGYAshsYVFXMHqilKOgKvc+wzHPkizgdkL2f69j4wWXrcP4GBIHIGgTuU0qMr uHe+znt+JTU1MLjm97hLv5KpAeIIV+TPPn1EB00pBlBDR/gZ+E1QfPu7ZMU7uFTRL4C3 c7+GjK9kPbIualk4c7fQmbEZz/kMgcTOWzRI9at6igpzQjbTakVKvbyqmdVvbj+557x+ IUXZlGTwk3n/Y7j4i2L8wW/07gNR5Y5nsSFQQmeM2RXVRqI4IApKn5Hux9f65HA9+Fq3 D+RpqL614xxWdupQuJTnghPbrPqZyzD0S2XTudJC4OYzRtR6tCeyX/qg1TfFR+Q+rduL K5zA== MIME-Version: 1.0 Received: by 10.236.79.8 with SMTP id h8mr2036996yhe.79.1335352199562; Wed, 25 Apr 2012 04:09:59 -0700 (PDT) Received: by 10.146.255.30 with HTTP; Wed, 25 Apr 2012 04:09:59 -0700 (PDT) In-Reply-To: References: Date: Wed, 25 Apr 2012 16:39:59 +0530 Message-ID: From: somnath chatterjee To: Donald Eastlake Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: Hu Fangwei , trill@ietf.org Subject: Re: [trill] [rbridge] draft-hu-trill-rbridge-esadi-04 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 11:10:03 -0000 Hi Donald, Thank you for the explanation. I agree with you that it is a corner case and might be a type of misconfiguration. In such case it would be good to fall back to aging out routes/fdbs normally. Regards, Somnath 2012/4/25 Donald Eastlake : > Hi Somnath, > > 2012/4/24 somnath chatterjee : >> Hi Donald, >> >> Please consider a scenario where the "from" RBridge has ESADI(RB1), >> the "to" RBridge is non-ESADI(RB2) and there is another ESADI >> RBridge(RB3) which is neither "to" or "from" but in the campus. I was >> concerned about the this RB3 which will receive ESADI LSP from RB1. If >> the RB1 had previously chosen not to include the End-Station MAC in >> its earlier ESADI-LSP, the RB3 has no way to know that the this MAC is >> to be flushed when it receives the updated ESADI-LSP from RB1. > > As a very general comment, TRILL provides many tools and does not > generally demand that they be used in some specify way. It was > important in designing TRILL that default operations, without various > options, be something reasonable. But if someone starts to implement > various optional feature or to configure priorities or whatever, it is > general up to them to figure out how to do this to get a good result. > Some things, like how the DRB should determine what, if any, other > RBridges on a multi-RBridge link should be appointed forwarders for > what VLANs were deliberately left out of scope because it seems > complicated, with lots of factors that could be taken into account, > and an area where different implementors could compete. > > Your statement above about what might happen seem right, but so what? > Why did the network manager choose not to use ESADI to advertise the > MAC address involved? Is data plane address learning also enabled at > these RBridges? > > Shouldn't it be obvious that if you have data plane learning enabled > (which is the default) and you don't use ESADI for MAC address M1, > then you get data plane / time-out driven behavior for M1? What else > would you expect? > >> I assume that ESADI RBridges will compare previous ESADI-LSP and >> latest ESADI-LSP to find the lost MACs. > > Well, at least logically, that's not the way I look at it. An RBridge > can have various MAC address learning information including manually > configured addresses, data plane learned addresses, and addresses in > its ESADI link state database. So, if any of this information changes, > then potentially it needs to update its MAC forwarding tables, using > the rules in RFC 6325 to reconcile conflicts between these different > types of information. There are various ways it can optimize this > update process including comparing old versus new information. > >> As ESADI RBridges MAY send >> partial information about End-Stations connected to it, comparing >> previous and latest ESADI-LSPs may not always give complete >> information about lost MACs. > > I would guess that there would normally be some specific reason for > leaving some MAC address out. For example, there are a few MAC > attachments that are more important to transmit securely or that are > more dynamic and it is important to update quickly, and for which the > data being sent/received is usually to other RBridges that implement > ESADI. So it makes sense to include those MACs. While there is another > set of MAC attachments for which security / rapid update is less > important and/or it is known that most of the other RBridges for which > data from/to such MACs is communicated don't implement ESADI so it is > pointless to communicate them in ESADI. > >> So if there was a way to notify >> explicitly about the lost MACs it would be easy for an ESADI RBridge >> to conclude about the lost MACs, also comparing previous and current >> ESADI-LSPs overhead will not exist. > > But you would have the overhead of processing the new MAC unlearn > message, which might have to be sent to all RBridges attached to a > VLAN unless you carefully tracked every RBridge that might have > learned the MAC... > > Adding some optional way to remotely delete one or more MAC addresses > is a reasonable idea but I don't think you would necessarily always > want to use it even if it was available. Sometimes the existing data > plane learning is fine... > > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > >> Please correct me if my understanding is wrong. >> >> Thank you, >> Regards, >> Somnath >> >> >> 2012/4/24 Donald Eastlake : >>> Hi Somnath, >>> >>> Generally speaking, on your questions about what happens if a end >>> station moves from being connected to an ESADI RBridge that is >>> advertising the end stations MAC address to a non-ESADI RBridge, where >>> both are Appointed Forwarders for the stations VLAN, what happens. If >>> the "from" RBridge notices, it removed that MAC address from its >>> ESADI-LSP. By the ESADI flooding, that updated LSP without the MAC >>> address will get to all other participating ESADI RBridges for that >>> VLAN. >>> >>> If the "to" RBridge is not an ESADI RBridge, then, of course, you do >>> not get any benefit from ESADI for the connection to it. >>> >>> There is little, if any benefit, from trying to play around with >>> dymanically set confidences in this case. If both the "from" and "to" >>> RBridges are ESADI RBridges and they both think MAC address M is >>> connected in VLAN V for which they are participating in ESADI, then >>> both with advertise this in their ESADI-LSP. An implementation could >>> keep track of when if gets LSP updates and try to figure out which was >>> more recent. >>> >>> See below. >>> >>> 2012/4/23 somnath chatterjee : >>>> Hi , >>>> >>>> In introduction of draft-hu-trill-rbridge-esadi-04 >>>> " An RBridge that is announcing connectivity to VLAN-x (normally a >>>> VLAN-x appointed forwarder) MAY use the (ESADI) protocol to announce >>>> the end station address of some or all of its attached VLAN-x end >>>> nodes to other RBridges that are running ESADI for VLAN-x." >>>> >>>> An ESADI supported RBridge MAY selectively send about end-station MACs >>>> and MAY opt to not send all the end-station MACs. >>>> >>>> I am only suggesting to send MAC in updated ESADI-LSP with confidence >>>> zero(for every lost MAC), so that other ESADI RBridges could easily >>>> recognize that this MAC needs to be deleted, rather than compare it >>>> with previously stored information and then delete. >>> >>> It is stronger to just drop the MAC for your ESADI-LSP. Other EASDI >>> RBridges need to look at your update to figure out if/how to update >>> their FIB in any case. >>> >>> Thanks, >>> Donald >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >>> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >>> 155 Beaver Street, Milford, MA 01757 USA >>> d3e3e3@gmail.com >>> >>>> Thank you, >>>> Regards, >>>> Somnath >>>> >>>> 2012/4/23 >>>>> >>>>> >>>>> Hi, chatterjee >>>>> >>>>> By my understanding, If RB1 supports ESADI, it advertises all the end= -station MAC attached to the remote RBridges. >>>>> >>>>> The remote RBridge can do some policy forwarding based on the MAC add= ress, but I think it is no need to opt to send the end-station MAC by the l= ocal RBridge. >>>>> >>>>> Regards >>>>> >>>>> >>>>> somnath chatterjee >>>>> >>>>> 2012-04-23 14:57 >>>>> >>>>> =CA=D5=BC=FE=C8=CB >>>>> hu.fangwei@zte.com.cn >>>>> =B3=AD=CB=CD >>>>> trill@ietf.org, trill-bounces@ietf.org >>>>> =D6=F7=CC=E2 >>>>> Re: [trill] [rbridge] draft-hu-trill-rbridge-esadi-04 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Hi Fangwei, >>>>> >>>>> Thank you for the explanation. >>>>> >>>>> So, RB1 doesnot include the end-stations MAC in its LSP. What if RB1 = has opted not to send this end-station MAC in its ESADI-LSP earlier? The ot= her ESADI RBridges has no way to learn that this MAC has to be flushed(whic= h may be learned through other procedures except ESADI). It would be good i= f ESADI RBridges could explicitly tell other RBridges to forget a MAC. >>>>> >>>>> Regards, >>>>> Somnath >>>>> >>>>> 2012/4/22 >>>>> >>>>> Thanks for the reviewing and comments. >>>>> >>>>> Pls see the following in line. >>>>> >>>>> >Hi Authors, >>>>> >>>>> >I have read the draft-hu-trill-rbridge-esadi-04 and support it. >>>>> >>>>> >I have one question regarding the problem stated in the draft >>>>> >>>>> > " 2. Fast update advantages: ESADI protocol provides a fast update = of >>>>> end nodes MAC (Media Access Control) addresses. If an end statio= n >>>>> is unplugged from one RBridge and plugged into another, frames >>>>> addressed to that older RBridge can be black holed. They can be >>>>> sent just to the older RBridge that the end station was connected >>>>> to until cached address information at some remote RBridge times >>>>> out, possibly for tens of seconds [RFC6325]." >>>>> >>>>> >In this scenario when an end-station moves TO a link where an >>>>> >RBridge(RBx) with ESADI support is serving as AF for the vlan on whi= ch >>>>> >the end-station is connected, this RBridge sends the end-station MAC= s >>>>> >through ESADI pdu to other ESADI RBridges with a higher confidence a= nd >>>>> >the old routes in other ESADI RBridges are over-written.New routes(M= AC >>>>> >"A" is reachable via egress RBridge RBx) exist and frames destined t= o >>>>> >MAC "A" are not black holed. >>>>> >>>>> >But what if this end-station moves FROM a link which has RBridge(RB1= ) >>>>> >with ESADI support TO a link where RBridge(RB2) donot have ESADI >>>>> >support. Is there any way RB1 can notify other ESADI implemented >>>>> >RBridges in the campus to flush the old route(MAC "A" is reachable v= ia >>>>> >egress RB1) so that frames for MAC "A" are not send directly to RB1 >>>>> >and are rather treated as unknown unicast frame and send on a DTree? >>>>> >Could RB1 send to ESADI Implemented RBridges that MAC "A" is no long= er >>>>> >reachable via itself by sending confidence as 0 for that MAC in its >>>>> >ESADI pdus? >>>>> >>>>> [hfw] If RB1 notify that the end-station moves from the link, RB1 wil= l update >>>>> >>>>> and flood the LSP originated with nulling out the end-station address= . When other ESADI >>>>> >>>>> RBridge receives the updated LSP, they will forget the MAC "A" from i= ts MAC table. >>>>> >>>>> In this way, ESADI protocol can fast update the MAC table of remote R= Bridges when the end station attached >>>>> >>>>> is unpluged or a new end station is pluged. >>>>> >>>>> >>>>> >>>>> >Please correct me if my understanding is wrong. >>>>> >>>>> >Also could we recommend ESADI implemented RBridges to become DRB and >>>>> >serve more AF for vlans. >>>>> >>>>> >Editorial comments and typos: >>>>> >>>>> >In Abstract >>>>> >ESADI (End System Address Distribution Information) should be replac= ed by >>>>> >ESADI (End Station Address Distribution Information) as per RFC6325 >>>>> >>>>> >In section 3. ESADI DRB State >>>>> >8th line: "for which RB1 is holding an ESADI-LSP zero with an ESADI >>>>> >Pararmeters" , typo for "Parameters" >>>>> >>>>> >>>>> >In section 4. ESADI PDU processing >>>>> >4th line: "are only EASDI-LSP, EASDI-CSNP and EASDI-PSNP PDUs us= ed >>>>> >in ESADI."should be changed to >>>>> > "are only ESADI-LSP, ESADI-CSNP and ESADI-PSNP PDUs used in ESADI= ." >>>>> >>>>> >In section 4.1 Sending of ESASI PDUs >>>>> >>>>> >Change the typo in the header itself. >>>>> >>>>> >4th line: "6(Innter.MacSA)" to '6(Inner.MacSA)" >>>>> >>>>> >5th line: "starting with the Intradomain Routeing Protocol >>>>> >Discriminator," Typo "Routeing" to "Routing" >>>>> >>>>> >2nd Para, 1st line: "Once an ESADI instance is operationally up, it >>>>> >multicasts it self- >>>>> > originated LSP number zero on the virtual link to announce its ESA= DI >>>>> > parameters." may be changed to >>>>> >"Once an ESADI instance is operationally up, it multicasts/sends its= self- >>>>> > originated LSP number zero on the virtual link to announce its ES= ADI >>>>> > parameters." >>>>> >>>>> >5th Para, 2nd line: Typo "EASDI" >>>>> >>>>> >In section 5. ESADI-LSP Contents >>>>> >7th line typo "EASDAI-LSPs >>>>> >>>>> >In section 5.1 ESADI Parameter Data >>>>> >4th line typo "occurrnce" >>>>> >>>>> [hfw] Thanks for the correcting, we will correct it in the next versi= on. >>>>> >>>>> >>>>> somnath chatterjee >>>>> =B7=A2=BC=FE=C8=CB: trill-bounces@ietf.org >>>>> >>>>> 2012-04-21 01:17 >>>>> >>>>> >>>>> =CA=D5=BC=FE=C8=CB >>>>> trill@ietf.org >>>>> =B3=AD=CB=CD >>>>> =D6=F7=CC=E2 >>>>> [trill] [rbridge] draft-hu-trill-rbridge-esadi-04 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Hi Authors, >>>>> >>>>> I have read the draft-hu-trill-rbridge-esadi-04 and support it. >>>>> >>>>> I have one question regarding the problem stated in the draft >>>>> >>>>> " 2. Fast update advantages: ESADI protocol provides a fast update of >>>>> end nodes MAC (Media Access Control) addresses. If an end statio= n >>>>> is unplugged from one RBridge and plugged into another, frames >>>>> addressed to that older RBridge can be black holed. They can be >>>>> sent just to the older RBridge that the end station was connected >>>>> to until cached address information at some remote RBridge times >>>>> out, possibly for tens of seconds [RFC6325]." >>>>> >>>>> In this scenario when an end-station moves TO a link where an >>>>> RBridge(RBx) with ESADI support is serving as AF for the vlan on whic= h >>>>> the end-station is connected, this RBridge sends the end-station MACs >>>>> through ESADI pdu to other ESADI RBridges with a higher confidence an= d >>>>> the old routes in other ESADI RBridges are over-written.New routes(MA= C >>>>> "A" is reachable via egress RBridge RBx) exist and frames destined to >>>>> MAC "A" are not black holed. >>>>> >>>>> But what if this end-station moves FROM a link which has RBridge(RB1) >>>>> with ESADI support TO a link where RBridge(RB2) donot have ESADI >>>>> support. Is there any way RB1 can notify other ESADI implemented >>>>> RBridges in the campus to flush the old route(MAC "A" is reachable vi= a >>>>> egress RB1) so that frames for MAC "A" are not send directly to RB1 >>>>> and are rather treated as unknown unicast frame and send on a DTree? >>>>> Could RB1 send to ESADI Implemented RBridges that MAC "A" is no longe= r >>>>> reachable via itself by sending confidence as 0 for that MAC in its >>>>> ESADI pdus? >>>>> >>>>> Please correct me if my understanding is wrong. >>>>> >>>>> Also could we recommend ESADI implemented RBridges to become DRB and >>>>> serve more AF for vlans. >>>>> >>>>> Editorial comments and typos: >>>>> >>>>> In Abstract >>>>> ESADI (End System Address Distribution Information) should be replace= d by >>>>> ESADI (End Station Address Distribution Information) as per RFC6325 >>>>> >>>>> In section 3. ESADI DRB State >>>>> 8th line: "for which RB1 is holding an ESADI-LSP zero with an ESADI >>>>> Pararmeters" , typo for "Parameters" >>>>> >>>>> >>>>> In section 4. ESADI PDU processing >>>>> 4th line: "are only EASDI-LSP, EASDI-CSNP and EASDI-PSNP PDUs use= d >>>>> in ESADI."should be changed to >>>>> "are only ESADI-LSP, ESADI-CSNP and ESADI-PSNP PDUs used in ESADI." >>>>> >>>>> In section 4.1 Sending of ESASI PDUs >>>>> >>>>> Change the typo in the header itself. >>>>> >>>>> 4th line: "6(Innter.MacSA)" to '6(Inner.MacSA)" >>>>> >>>>> 5th line: "starting with the Intradomain Routeing Protocol >>>>> Discriminator," Typo "Routeing" to "Routing" >>>>> >>>>> 2nd Para, 1st line: "Once an ESADI instance is operationally up, it >>>>> multicasts it self- >>>>> originated LSP number zero on the virtual link to announce its ESADI >>>>> parameters." may be changed to >>>>> "Once an ESADI instance is operationally up, it multicasts/sends its = self- >>>>> originated LSP number zero on the virtual link to announce its ESADI >>>>> parameters." >>>>> >>>>> 5th Para, 2nd line: Typo "EASDI" >>>>> >>>>> In section 5. ESADI-LSP Contents >>>>> 7th line typo "EASDAI-LSPs >>>>> >>>>> In section 5.1 ESADI Parameter Data >>>>> 4th line typo "occurrnce" >>>>> >>>>> Thank you, >>>>> Regards, >>>>> Somnath >>>>> _______________________________________________ >>>>> trill mailing list >>>>> trill@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/trill >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> trill mailing list >>>> trill@ietf.org >>>> https://www.ietf.org/mailman/listinfo/trill From d3e3e3@gmail.com Wed Apr 25 06:27:46 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CBD621F866C for ; Wed, 25 Apr 2012 06:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.462 X-Spam-Level: X-Spam-Status: No, score=-103.462 tagged_above=-999 required=5 tests=[AWL=-0.463, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 oslHrouaQqaP for ; Wed, 25 Apr 2012 06:27:45 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 29D4621F85BD for ; Wed, 25 Apr 2012 06:27:44 -0700 (PDT) Received: by lagj5 with SMTP id j5so75134lag.31 for ; Wed, 25 Apr 2012 06:27:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=P8aXNpSW8w3QNIvztn+8Q0kHZvZRDyU47+mn6GHBKs8=; b=KLTIdZNHPSZEAbrxdPgsQ4kw/D4EoKxoKVUEAjuiol06MIOf5uQmW8+/QwqiZJkU7I hMxPCH86MzbylyEBpVgTo4v7x4QMTpF3fVE6Hx+qFq0fdoa+103opzPILOA2U4nlv3NM qpAGUuewuxhFrWgKNBI4p+qP4Uc/6m9mouXmKzHMrve2uR3OniZVvsseybAJ/kj/3VWY OyBhjAl1s7qtM+x7OVuAz38MP2MpFCSLVEtZm9YyJlnYeGCw1LdtEVUhvjscSHedQub5 x/+yh76bfJ/hHhhipZGIhCfmtg4psuCQtfkBkXkAiLzQDDWN1tXr1M1lhUk9ZHh3DwwQ tq9w== Received: by 10.152.111.198 with SMTP id ik6mr2577171lab.38.1335360463971; Wed, 25 Apr 2012 06:27:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.144.8 with HTTP; Wed, 25 Apr 2012 06:27:23 -0700 (PDT) In-Reply-To: References: From: Donald Eastlake Date: Wed, 25 Apr 2012 09:27:23 -0400 Message-ID: To: Nguyen Huu Tho Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: trill@ietf.org Subject: Re: [trill] Some question about TRILL IS-IS and Distribution Tree X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 13:27:46 -0000 See below: On Wed, Apr 25, 2012 at 7:01 AM, Nguyen Huu Tho wrote= : > Dear all, > > I have some questions about trill IS-IS and Distribution Tree. Anybody ca= n > help me ? > > 1. When TRILL use IS-IS, TRILL has a new type of hello message which is > called TRILL HELLO. > So, IS-IS HELLO of original IS-IS still have used or TRILL hello message > includes all function of original IS-IS hello and original IS-IS HELLO is= n't > exist. The TRILL Hello replaces the original IS-IS Hello on LAN links. It's really just a variation and uses the same PDU type number and same fixed PDU header. There is just some variation in its contents. RFC 6327 might be the best place to start concerning the TRILL Hello. > 2.=A0Is there any mechanism for each RBridge to choose the used distribut= ion > tree and advertise them to other RBridges If there is only one distribution tree, obviously every RBridge has to use it. If there is more than one distribution tree, how each RBridge decides which trees it is going to use in general and which tree it is going to use for any particular flow are out of scope of all current TRILL documents. RBridges can announce the distribution trees they might use with the Trees Used Identifiers Sub-TLV. See RFC 6326. > 3. In RFC 6325, In distribution tree part, When the RB having the highest > tree root priority send a list of s tree roots nickname. Why we have the > case s < k trees which all RBs in the campus must calculate ? I don't quite understand your question. I assume you are talking about Section 4.5 of RFC 6325. Not there are some change to this section in draft-ietf-trill-clear-correct which has been judged to have WG consensus. The distribution tree determination logic is a bit complex because different people wanted different things. Some thought that priority should be adequate, with the k highest priority being computed. Others wanted to always give an explicit list of the roots. The result is somewhat of a hybrid which can express a variety of policies for distribution tree determination. The RBridge holding the highest priority nickname to be a tree root can specify k, the number of trees they want computed, and can separately specify a list of desired tree root nicknames of length s. So, obviously, it can specify s < k. For example, k could be 3 and the explicit list of root nicknames could be null in order to use the three highest priority roots... > 4. When Ingress RB have multi nicknames, there is any mechanism to choose > which nicknames the RB will put in the Ingress nickname of TRILL header o= f > this frame Not currently. It is up to the RBridge. > 5. When a Ingress RB1 receive a multi-destination frames, when the Ingres= s > RB1 choose the distribution tree (have tree root is RB4). When the frame > reaches to the RB4, whether the tree root send the frame to RB2 with > outer.MacDA is All-RBridges or unicast Outer.MacDA ? With the TRILL base protocol standard RFC 6325 any multi-destination TRILL data frame being send on an Ethernet link is always sent with the outer.MacDA All-RBridges. It does not matter where in the distribution tree the Ethernet link is. It does not matter if the Ethernet link is point-to-point or multi-access. (Of course, if the link is not Ethernet, for example a PPP link (RFC 6361), then there might not be any outer.MacDA.) > And when the frame reaches to RB4, whether RB send to all nodes in this > distribution tree with the outer.MacDA is All-RBridges or not? > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 (RB2) =A0 =A0 =3D=3D=3D (RB4) (tree root) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0// =A0 =A0 =A0 =A0 =A0 =A0 \\ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (Ingress) (RB1) =A0 =A0 =A0 =A0 =A0 (= RB3) The TRILL distribution trees are bi-directional trees that reach all RBridges in the campus. Which RBridge is the "tree root" matters only when the tree is being calculated. After an RBridge has calculated the forwarding entries for the tree, it no longer matters what the root was and the type of forwarding is the same for any forwarded multi-detination frame. If the frame is output through an Ethernet port, its outer.MacDA is set to All-RBridges. Frames do not just go to the root and then get distributed by the root. In your diagram above, any multi-destination frame ingressed by RB1 will be sent to RB2. RB2 will send it to both RB3 and RB4. And RB3 and RB4 will not forward the frame as a TRILL data frame. (Any or all of the RBs may decapsulate the frame and send it locally as native frame where appropriate.) It make no difference to the actual distribution that RB4 was the root used by all the RBridges to calculate the tree. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com > Thanks , > > -- > +-- > | Nguyen Huu Tho. > =A0=A0 Mail: huutho411@gmail.com=A0 | From sunny.rajagopalan@us.ibm.com Wed Apr 25 15:37:08 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F09B21F8811 for ; Wed, 25 Apr 2012 15:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.312 X-Spam-Level: X-Spam-Status: No, score=-10.312 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 6qcRYL3GYpgo for ; Wed, 25 Apr 2012 15:37:07 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by ietfa.amsl.com (Postfix) with ESMTP id E3B8521F8534 for ; Wed, 25 Apr 2012 15:37:04 -0700 (PDT) Received: from /spool/local by e35.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 25 Apr 2012 16:37:04 -0600 Received: from d03dlp03.boulder.ibm.com (9.17.202.179) by e35.co.us.ibm.com (192.168.1.135) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 25 Apr 2012 16:37:01 -0600 Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id 1B12819D8048 for ; Wed, 25 Apr 2012 16:36:51 -0600 (MDT) Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q3PMaxAW236706 for ; Wed, 25 Apr 2012 16:37:00 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q3PMawZe030700 for ; Wed, 25 Apr 2012 16:36:58 -0600 Received: from d03nm127.boulder.ibm.com (d03nm127.boulder.ibm.com [9.17.195.18]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q3PMatFk030670 for ; Wed, 25 Apr 2012 16:36:55 -0600 In-Reply-To: <344037D7CFEFE84E97E9CC1F56C5F4A50100E64C@xmb-sjc-214.amer.cisco.com> References: <344037D7CFEFE84E97E9CC1F56C5F4A50100E64C@xmb-sjc-214.amer.cisco.com> To: trill@ietf.org MIME-Version: 1.0 X-KeepSent: DB5D95ED:C6594B78-872579EB:00764D44; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: Santosh Rajagopalan Date: Wed, 25 Apr 2012 15:36:53 -0700 X-MIMETrack: Serialize by Router on D03NM127/03/M/IBM(Release 8.5.1FP2|March 17, 2010) at 04/25/2012 16:36:54, Serialize complete at 04/25/2012 16:36:54 Content-Type: multipart/alternative; boundary="=_alternative 007C3F29882579EB_=" X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12042522-6148-0000-0000-00000552B106 Subject: Re: [trill] TRILL OAM Requirements - X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 22:37:08 -0000 This is a multipart message in MIME format. --=_alternative 007C3F29882579EB_= Content-Type: text/plain; charset="US-ASCII" Comments on this doc: 4.3 Continuity check: This seems to be defined too broadly in the doc. I look at this as a keepalive mechanism which gets set by configuration, and stays on for a longer period of time (as opposed to connectivity verification, which is user-initiated and short-lived). In Ethernet OAM, this is used to keep track of connectivity between adjacent switches and between switches that lie at the edges of a "level". The value of continuity check as defined in this doc seems less certain to me. What does it mean to have continuity checks for each flow? Each time a flow gets initiated, is an operator expected to setup keepalives for that flow? Or is this expected to get started automatically every time a new flow is detected? Either way, this doesn't scale for effort or state. The same goes for continuity checks which check if each link of a multipath is alive. I would recommend that the scope of the continuity check messages get narrowed to measure the connectivity liveliness for rbridges either on a per-hop basis or an end-to-end basis. 4.5. General Requirements "OAM MUST NOT require extensions to or modifications of the TRILL header." Is the rbridge channel as defined in http://tools.ietf.org/html/draft-eastlake-trill-rbridge-channel-00 considered an extension or modification of the TRILL header? "OAM, as practical as possible, SHOULD provide a single framework between TRILL and other similar standards." I'm not sure what this means. Can someone clarify? "OAM MUST maintain related error and operational counters." Again, what does this mean? Is the requirement that the OAM framework defined for trill must be able to query all counters? "OAM MUST provide a single OAM framework for all TRILL OAM functions" Can you provide an example of what would be a violation of this? 4.7. Packet Loss This is another section which is very broadly defined. Most switches I know of don't have the ability to maintain packet loss counters per flow, or even per source rbridge (leave aside packet loss for one link of an ecmp between rbridges). The best you can get here is packet losses for a given link, and this is already part of the TRILL MIB and can be queried by SNMP. 4.8. Packet Delay As defined here, measurement of packet delay seems to require hardware support. Is that the intent? Or is this supposed to measure delay between OAM software processes on the relevant switches? 5. General Format of TRILL OAM Messages The inner ethernet header should be called out explicitly, instead of being subsumed in the "Flow entropy" section, since using anything other than ethernet after the trill header would break every single trill compliant piece of silicon I know of. -- Sunny Rajagopalan From: "Tissa Senevirathne (tsenevir)" To: Date: 04/19/2012 02:04 PM Subject: [trill] TRILL OAM Requriements - Sent by: trill-bounces@ietf.org Dear All As agreed during the 83rd IETF meeting we have published TRILL OAM Requirements. Below is the link to the ID. Please review and share your thoughts. http://www.ietf.org/id/draft-tissa-trill-oam-req-00.txt Thanks Tissa_______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill --=_alternative 007C3F29882579EB_= Content-Type: text/html; charset="US-ASCII" Comments on this doc:
4.3 Continuity check:
This seems to be defined too broadly in the doc. I look at this as a keepalive mechanism which gets set  by configuration, and stays on for a longer period of time (as opposed to connectivity verification, which is user-initiated and short-lived). In Ethernet OAM, this is used to keep track of connectivity between adjacent switches and between switches that lie at the edges of a "level".
The value of continuity check as defined in this doc seems less certain to me. What does it mean to have continuity checks for each flow? Each time a flow gets initiated, is an operator expected to setup keepalives for that flow? Or is this expected to get started automatically every time a new flow is detected? Either way, this doesn't scale for effort or state. The same goes for continuity checks which check if each link of a multipath is alive. I would recommend that the scope of the continuity check messages get narrowed to measure the connectivity liveliness for rbridges either on a per-hop basis or an end-to-end basis.

4.5. General Requirements

"OAM MUST NOT require extensions to or modifications of the TRILL
  header."
Is the rbridge channel as defined in  http://tools.ietf.org/html/draft-eastlake-trill-rbridge-channel-00 considered an extension or modification of the TRILL header?

"OAM, as practical as possible, SHOULD provide a single framework
  between TRILL and other similar standards."
I'm not sure what this means. Can someone clarify?

"OAM MUST maintain related error and operational counters."
Again, what does this mean? Is the requirement that the OAM framework defined for trill must be able to query all counters?

"OAM MUST provide a single OAM framework for all TRILL OAM functions"
Can you provide an example of what would be a violation of this?

4.7. Packet Loss
This is another section which is very broadly defined. Most switches I know of don't have the ability to maintain packet loss counters per flow, or even per source rbridge (leave aside packet loss for one link of an ecmp between rbridges). The best you can get here is packet losses for a given link, and this is already part of the TRILL MIB and can be queried by SNMP.

4.8. Packet Delay
As defined here, measurement of packet delay seems to require hardware support. Is that the intent? Or is this supposed to measure delay between OAM software processes on the relevant switches?

5. General Format of TRILL OAM Messages
The inner ethernet header should be called out explicitly, instead of being subsumed in the "Flow entropy" section, since using anything other than ethernet after the trill header would break every single trill compliant piece of silicon I know of.

--
Sunny Rajagopalan






From:        "Tissa Senevirathne (tsenevir)" <tsenevir@cisco.com>
To:        <trill@ietf.org>
Date:        04/19/2012 02:04 PM
Subject:        [trill] TRILL OAM Requriements -
Sent by:        trill-bounces@ietf.org



Dear All

As agreed during the 83rd IETF meeting we have published TRILL OAM Requirements. Below is the link to the ID. Please review and share your thoughts.
 
http://www.ietf.org/id/draft-tissa-trill-oam-req-00.txt
 
Thanks
Tissa_______________________________________________
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill
--=_alternative 007C3F29882579EB_=-- From aldrin.ietf@gmail.com Wed Apr 25 21:52:50 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4366221F88C6 for ; Wed, 25 Apr 2012 21:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.4 X-Spam-Level: X-Spam-Status: No, score=-4.4 tagged_above=-999 required=5 tests=[AWL=-0.802, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 Uh6UslKvwH4j for ; Wed, 25 Apr 2012 21:52:48 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id A85C821F88C4 for ; Wed, 25 Apr 2012 21:52:47 -0700 (PDT) Received: by dady13 with SMTP id y13so1545276dad.27 for ; Wed, 25 Apr 2012 21:52:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=j1B2OjawiVwSmZJCITkRLsMmv9rU0CN4zYsFaFsx4wY=; b=af61E5TLdEW+pJ1zHHoWH3oqgcgx/NRqRvG1/skfTLbc5XePXL2X0ujOU4QPxy/S8g MSXzFpCBTUlsBAv/cJZOjTNyWfGce36eHFy6GOWA2udD/BaWzsQ9HJ010lU/AwJwm1f6 Gsk+zQAZOweQ8EfCZBX0Pbtzh8DWrfj8lDygyff3xoo8Cw8Bw8LPSQwruV0ExFss0/RX zajIIXJ0RJ1cWzKAfDdVHNltkcjpC+M5FdFHqNhmYHWJvGLvyTHFicrDE2ilnR8S2eqR 2VGpasfIHIDZBcJ+3ycoRZnz1/8vlmATQhWhKkQ8msJISwNazOr7ht5SIqvZKrz/AqcL 1IcQ== Received: by 10.68.190.69 with SMTP id go5mr13057167pbc.98.1335415967383; Wed, 25 Apr 2012 21:52:47 -0700 (PDT) Received: from [192.168.1.2] (c-107-3-156-34.hsd1.ca.comcast.net. [107.3.156.34]) by mx.google.com with ESMTPS id x1sm2145533pbp.50.2012.04.25.21.52.43 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Apr 2012 21:52:44 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_12F8B2C2-392A-4774-A7CC-F188011EECB6" From: Sam Aldrin In-Reply-To: Date: Wed, 25 Apr 2012 21:52:42 -0700 Message-Id: <4ECDDE13-BA0F-41E6-BE64-C00CE24D4FBC@gmail.com> References: <344037D7CFEFE84E97E9CC1F56C5F4A50100E64C@xmb-sjc-214.amer.cisco.com> To: Santosh Rajagopalan X-Mailer: Apple Mail (2.1257) Cc: trill@ietf.org Subject: Re: [trill] TRILL OAM Requirements - X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 04:52:50 -0000 --Apple-Mail=_12F8B2C2-392A-4774-A7CC-F188011EECB6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Santosh, Please find my comments inline with %SAM. On Apr 25, 2012, at 3:36 PM, Santosh Rajagopalan wrote: > Comments on this doc:=20 > 4.3 Continuity check:=20 > This seems to be defined too broadly in the doc. I look at this as a = keepalive mechanism which gets set by configuration, and stays on for a = longer period of time (as opposed to connectivity verification, which is = user-initiated and short-lived). In Ethernet OAM, this is used to keep = track of connectivity between adjacent switches and between switches = that lie at the edges of a "level".=20 > The value of continuity check as defined in this doc seems less = certain to me. %SAM - What would make is certain in a requirements document in your = opinion? > What does it mean to have continuity checks for each flow? Each time a = flow gets initiated, is an operator expected to setup keepalives for = that flow? Or is this expected to get started automatically every time a = new flow is detected? %SAM - This is requirements document. There should be ability to verify = any given individual path/flow. > Either way, this doesn't scale for effort or state. %SAM - Just because a vendor device cannot scale, it doesn't mean cannot = be done. May be if you can justify with a quantification what scale = metrics you are talking, would help to discuss further. > The same goes for continuity checks which check if each link of a = multipath is alive. I would recommend that the scope of the continuity = check messages get narrowed to measure the connectivity liveliness for = rbridges either on a per-hop basis or an end-to-end basis.=20 %SAM - Again, I am not sure, based on what quantification you are = arriving at the conclusion. This is fundamental requirement in other = network types as well. So, would like you to provide more data points = to your argument on why it cannot be done in TRILL, whilst the same is = done in other networks. >=20 > 4.5. General Requirements=20 >=20 > "OAM MUST NOT require extensions to or modifications of the TRILL > header."=20 > Is the rbridge channel as defined in = http://tools.ietf.org/html/draft-eastlake-trill-rbridge-channel-00 = considered an extension or modification of the TRILL header?=20 %SAM - Please ask the author for clarification. >=20 > "OAM, as practical as possible, SHOULD provide a single framework > between TRILL and other similar standards."=20 > I'm not sure what this means. Can someone clarify?=20 %SAM - We could add more clarifying text here. My take on this is, we = should not define individual framework for different OAM components. For = example, to quickly achieve ping and trace, we define a packet format. = Later, when we want to test multipath/ECMP, oops..cannot be done, so let = us define a new format. So, the requirement emphasize on avoiding that. = Can it be 100% achievable, simple answer is NO. But we need to try our = best. Others could chime in, if they want to add. >=20 > "OAM MUST maintain related error and operational counters."=20 > Again, what does this mean? Is the requirement that the OAM framework = defined for trill must be able to query all counters? %SAM - What part is not clear? Requirement is specifying the error = counters should be maintained on an RBridge. Whether you provide access = to query or only display via CLI is implementation specific. >=20 >=20 > "OAM MUST provide a single OAM framework for all TRILL OAM functions"=20= > Can you provide an example of what would be a violation of this?=20 %SAM - see earlier reasoning. >=20 > 4.7. Packet Loss=20 > This is another section which is very broadly defined. Most switches I = know of don't have the ability to maintain packet loss counters per = flow, or even per source rbridge (leave aside packet loss for one link = of an ecmp between rbridges). The best you can get here is packet losses = for a given link, and this is already part of the TRILL MIB and can be = queried by SNMP.=20 %SAM - When you say 'most', does that mean there are switches which = could do that, correct? That is why the word 'SHOULD' is used. If any = vendor cannot support, that is their choice. In regds to MIB or SNMP, = they are part of OAM umbrella. Not sure why this OAM requirement = implemented via SNMP is an issue to you? >=20 > 4.8. Packet Delay >=20 > As defined here, measurement of packet delay seems to require hardware = support. Is that the intent? Or is this supposed to measure delay = between OAM software processes on the relevant switches?=20 %SAM - I think it is both. If you can timestamp at each level, one could = provide more granular levels. How you do it? could be proprietary or = part of solution documents. >=20 > 5. General Format of TRILL OAM Messages=20 > The inner ethernet header should be called out explicitly, instead of = being subsumed in the "Flow entropy" section, since using anything other = than ethernet after the trill header would break every single trill = compliant piece of silicon I know of.=20 %SAM - We have merchant silicon vendors on the author list. I have my = opinion but will leave it for them to comment. :D HTH, -sam >=20 > --=20 > Sunny Rajagopalan=20 >=20 >=20 >=20 >=20 >=20 >=20 > From: "Tissa Senevirathne (tsenevir)" =20 > To: =20 > Date: 04/19/2012 02:04 PM=20 > Subject: [trill] TRILL OAM Requriements -=20 > Sent by: trill-bounces@ietf.org=20 >=20 >=20 >=20 > Dear All=20 >=20 > As agreed during the 83rd IETF meeting we have published TRILL OAM = Requirements. Below is the link to the ID. Please review and share your = thoughts.=20 > =20 > http://www.ietf.org/id/draft-tissa-trill-oam-req-00.txt=20 > =20 > Thanks=20 > Tissa_______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill >=20 > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill --Apple-Mail=_12F8B2C2-392A-4774-A7CC-F188011EECB6 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Santosh,

Please find my comments inline with %SAM.

On Apr 25, 2012, at 3:36 PM, Santosh Rajagopalan wrote:

Comments on this doc:
4.3 Continuity check:
This seems to be defined too broadly in the doc. I look at this as a keepalive mechanism which gets set  by configuration, and stays on for a longer period of time (as opposed to connectivity verification, which is user-initiated and short-lived). In Ethernet OAM, this is used to keep track of connectivity between adjacent switches and between switches that lie at the edges of a "level".
The value of continuity check as defined in this doc seems less certain to me.
%SAM - What would make is certain in a requirements document in your opinion?
What does it mean to have continuity checks for each flow? Each time a flow gets initiated, is an operator expected to setup keepalives for that flow? Or is this expected to get started automatically every time a new flow is detected?
%SAM - This is requirements document. There should be ability to verify any given individual path/flow.
Either way, this doesn't scale for effort or state.
%SAM - Just because a vendor device cannot scale, it doesn't mean cannot be done. May be if you can justify with a quantification what scale metrics you are talking, would help to discuss further.
The same goes for continuity checks which check if each link of a multipath is alive. I would recommend that the scope of the continuity check messages get narrowed to measure the connectivity liveliness for rbridges either on a per-hop basis or an end-to-end basis.
%SAM - Again, I am not sure, based on what quantification you are arriving at the conclusion. This is fundamental requirement in other network types as well. So,  would like you to provide more data points to your argument on why it cannot be done in TRILL, whilst the same is done in other networks.

4.5. General Requirements

"OAM MUST NOT require extensions to or modifications of the TRILL
  header."
Is the rbridge channel as defined in  http://tools.ietf.org/html/draft-eastlake-trill-rbridge-channel-00 considered an extension or modification of the TRILL header?
%SAM - Please ask the author for clarification.

"OAM, as practical as possible, SHOULD provide a single framework
  between TRILL and other similar standards."
I'm not sure what this means. Can someone clarify?
%SAM - We could add more clarifying text here. My take on this is, we should not define individual framework for different OAM components. For example, to quickly achieve ping and trace, we define a packet format. Later, when we want to test multipath/ECMP, oops..cannot be done, so let us define a new format. So, the requirement emphasize on avoiding that. Can it be 100% achievable, simple answer is NO. But we need to try our best. Others could chime in, if they want to add.

"OAM MUST maintain related error and operational counters."
Again, what does this mean? Is the requirement that the OAM framework defined for trill must be able to query all counters?
%SAM - What part is not clear? Requirement is specifying the error counters should be maintained on an RBridge. Whether you provide access to query or only display via CLI is implementation specific.


"OAM MUST provide a single OAM framework for all TRILL OAM functions"
Can you provide an example of what would be a violation of this?
%SAM - see earlier reasoning.

4.7. Packet Loss
This is another section which is very broadly defined. Most switches I know of don't have the ability to maintain packet loss counters per flow, or even per source rbridge (leave aside packet loss for one link of an ecmp between rbridges). The best you can get here is packet losses for a given link, and this is already part of the TRILL MIB and can be queried by SNMP.
%SAM - When you say 'most', does that mean there are switches which could do that, correct? That is why the word 'SHOULD' is used. If any vendor cannot support, that is their choice. In regds to MIB or SNMP, they are part of OAM umbrella. Not sure why this OAM requirement implemented via SNMP is an issue to you?

4.8. Packet Delay
As defined here, measurement of packet delay seems to require hardware support. Is that the intent? Or is this supposed to measure delay between OAM software processes on the relevant switches?
%SAM - I think it is both. If you can timestamp at each level, one could provide more granular levels. How you do it? could be proprietary or part of solution documents.

5. General Format of TRILL OAM Messages
The inner ethernet header should be called out explicitly, instead of being subsumed in the "Flow entropy" section, since using anything other than ethernet after the trill header would break every single trill compliant piece of silicon I know of.
%SAM - We have merchant silicon vendors on the author list. I have my opinion but will leave it for them to comment. :D

HTH,
-sam

--
Sunny Rajagopalan






From:        "Tissa Senevirathne (tsenevir)" <tsenevir@cisco.com>
To:        <trill@ietf.org>
Date:        04/19/2012 02:04 PM
Subject:        [trill] TRILL OAM Requriements -
Sent by:        trill-bounces@ietf.org



Dear All

As agreed during the 83rd IETF meeting we have published TRILL OAM Requirements. Below is the link to the ID. Please review and share your thoughts.
 
http://www.ietf.org/id/draft-tissa-trill-oam-req-00.txt
 
Thanks
Tissa_______________________________________________
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill
_______________________________________________
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

--Apple-Mail=_12F8B2C2-392A-4774-A7CC-F188011EECB6-- From internet-drafts@ietf.org Thu Apr 26 10:56:48 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A688E21E8098; Thu, 26 Apr 2012 10:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 40se8GUEDuRm; Thu, 26 Apr 2012 10:56:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08DF421F865A; Thu, 26 Apr 2012 10:56:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.01p1 Message-ID: <20120426175648.9178.36410.idtracker@ietfa.amsl.com> Date: Thu, 26 Apr 2012 10:56:48 -0700 Cc: trill@ietf.org Subject: [trill] I-D Action: draft-ietf-trill-clear-correct-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 17:56:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transparent Interconnection of Lots o= f Links Working Group of the IETF. Title : TRILL: Clarifications, Corrections, and Updates Author(s) : Donald Eastlake Mingui Zhang Anoop Ghanwani Ayan Banerjee Vishwas Manral Filename : draft-ietf-trill-clear-correct-02.txt Pages : 29 Date : 2012-04-26 The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol provides least cost pair-wise data forwarding without configuration in multi-hop networks with arbitrary topology, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using IS-IS (Intermediate System to Intermediate System) link state routing and by encapsulating traffic using a header that includes a hop count. Since the TRILL base protocol was approved in March 2010, active development of TRILL has revealed a few errata in the original RFC 6325 and some cases that could use clarifications or updates. RFC 6327 and RFC 6439 provide clarifications and updates with respect to Adjacency and Appointed Forwarders. This document provide other known clarifications, corrections, and updates to RFC 6325, RFC 6327, and RFC 6439. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-trill-clear-correct-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-trill-clear-correct-02.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-trill-clear-correct/ From narten@us.ibm.com Thu Apr 26 11:13:38 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8706F21F8678 for ; Thu, 26 Apr 2012 11:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 ZT7x7ZhdP8hR for ; Thu, 26 Apr 2012 11:13:38 -0700 (PDT) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by ietfa.amsl.com (Postfix) with ESMTP id C624B21F866B for ; Thu, 26 Apr 2012 11:13:37 -0700 (PDT) Received: from /spool/local by e4.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 26 Apr 2012 14:13:35 -0400 Received: from d01dlp02.pok.ibm.com (9.56.224.85) by e4.ny.us.ibm.com (192.168.1.104) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 26 Apr 2012 14:13:12 -0400 Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 79C446E8049 for ; Thu, 26 Apr 2012 14:13:10 -0400 (EDT) Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q3QID9H7101410 for ; Thu, 26 Apr 2012 14:13:09 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q3QNi2Do003582 for ; Thu, 26 Apr 2012 19:44:02 -0400 Received: from cichlid.raleigh.ibm.com ([9.80.5.204]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q3QNi1bv003438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 26 Apr 2012 19:44:01 -0400 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.5/8.12.5) with ESMTP id q3QID7ZP018730 for ; Thu, 26 Apr 2012 14:13:07 -0400 Message-Id: <201204261813.q3QID7ZP018730@cichlid.raleigh.ibm.com> To: trill@ietf.org Date: Thu, 26 Apr 2012 14:13:06 -0400 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12042618-3534-0000-0000-000007D60868 Subject: [trill] TRILL OAM Requirements: Sections X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 18:13:38 -0000 draft-tissa-trill-oam-req-00.txt says; > Section: A section is a partial segment of a path between any two > given RBridges. As an example, consider the case where RB1 is > connected to RBx via RB2 and RB3. The segment between RB3 to RBx is > referred to as a Section of the path RB1 to RBx. Where does this notion of a section come from and why do we need it in TRILL? AFAIK, TRILL doesn't have this notion, so this is something that OAM is creating on its own. Then later: > An RBridge SHOULD have the ability to verify the above connectivity > tests on sections. As an example, assume RB1 is connected to RB5 via > RB2, RB3 and RB4. An operator SHOULD be able to verify the RB1 to > RB5 connectivity on the section from RB3 to RB5. The difference is > that the ingress and egress TRILL nicknames in this case are RB1 and > RB5 as opposed to RB3 and RB5, even though the message itself may > originate at RB3. I am not comfortable with this requirement. This would seem to complicate the requirements and I'm not sure why it is needed. I'm also a bit wary about what the implication is in terms of what sort of functionality or mechanism would be required to be able to achieve this requirement. (The notion of "sections" comes up in several places in the document, and the above applies to all of them.) Do we really want or need sections? Thomas From narten@us.ibm.com Thu Apr 26 11:55:16 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6907E21E816D for ; Thu, 26 Apr 2012 11:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 6-8oAfrdpJyt for ; Thu, 26 Apr 2012 11:55:15 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by ietfa.amsl.com (Postfix) with ESMTP id B1DAB21E8160 for ; Thu, 26 Apr 2012 11:55:15 -0700 (PDT) Received: from /spool/local by e35.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 26 Apr 2012 12:55:15 -0600 Received: from d03dlp02.boulder.ibm.com (9.17.202.178) by e35.co.us.ibm.com (192.168.1.135) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 26 Apr 2012 12:55:13 -0600 Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id C1D5D3E4004E for ; Thu, 26 Apr 2012 12:55:11 -0600 (MDT) Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q3QIt5NG151450 for ; Thu, 26 Apr 2012 12:55:06 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q3QIt1Po015442 for ; Thu, 26 Apr 2012 12:55:01 -0600 Received: from cichlid.raleigh.ibm.com ([9.80.5.204]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q3QIt0Z3015124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 26 Apr 2012 12:55:01 -0600 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.5/8.12.5) with ESMTP id q3QIsxDS019263 for ; Thu, 26 Apr 2012 14:54:59 -0400 Message-Id: <201204261854.q3QIsxDS019263@cichlid.raleigh.ibm.com> To: trill@ietf.org Date: Thu, 26 Apr 2012 14:54:58 -0400 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12042618-6148-0000-0000-00000559775E Subject: [trill] TRILL OAM Requirements: Third party debugging X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 18:55:16 -0000 I may just be misreading intent, but to be sure, I'd like to clarify the following point. I had assumed that things like connectivity testing, tracing, etc. would need to be supported from one RB to another. That is, if I was on RB1, I could do a connectivity check to any other RB. Or trace a path. However, any sort of test involving connectivity from RB1 would need to be *initiated* from RB1. There is some wording in draft-tissa-trill-oam-req-00.txt that could be interpreted as it being a requirement that one should be able to initiate an operation between RB1 and RB2 from some arbitrary third RB. Is that the case? E.g.,: > OAM MUST have the ability to verify an RBridge RB1 is connected to a > specific RBridge RB2. I would assume that the verifying that RB1 can reach RB2 is a requirement "for RB1". that is, if I am logged into RB1, I can initiate such a check to any destination I want. But the above definition would also include being able to ask that question from *any* RB. Is that the intention? > An RBridge SHOULD have the ability to verify the above connectivity > tests on sections. As an example, assume RB1 is connected to RB5 via > RB2, RB3 and RB4. An operator SHOULD be able to verify the RB1 to > RB5 connectivity on the section from RB3 to RB5. The difference is > that the ingress and egress TRILL nicknames in this case are RB1 and > RB5 as opposed to RB3 and RB5, even though the message itself may > originate at RB3. Is the operator above "sitting at" RB3? I.e., is the test initiated from RB3 and does it inject packet that have a source RB of RB1? (That seems fine at one level because no special mechanisms are needed to achieve this.) But beyond that, I'm not sure what is envisioned, because if you did (say) traceroute, TTL exceeded errors would go back to RB1, not RB3. Same for any OAM response messages. What is the thinking here? Thomas From narten@us.ibm.com Thu Apr 26 12:39:57 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEAB821E8186 for ; Thu, 26 Apr 2012 12:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 tl4UzwOqKcsB for ; Thu, 26 Apr 2012 12:39:52 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by ietfa.amsl.com (Postfix) with ESMTP id A95EE21E8185 for ; Thu, 26 Apr 2012 12:39:52 -0700 (PDT) Received: from /spool/local by e31.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 26 Apr 2012 13:39:52 -0600 Received: from d03dlp03.boulder.ibm.com (9.17.202.179) by e31.co.us.ibm.com (192.168.1.131) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 26 Apr 2012 13:39:31 -0600 Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id 3D74419D8053 for ; Thu, 26 Apr 2012 13:39:20 -0600 (MDT) Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q3QJdIT0156782 for ; Thu, 26 Apr 2012 13:39:18 -0600 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q3QJdGPX004457 for ; Thu, 26 Apr 2012 13:39:16 -0600 Received: from cichlid.raleigh.ibm.com ([9.80.5.204]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q3QJdFCY004350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 26 Apr 2012 13:39:16 -0600 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.5/8.12.5) with ESMTP id q3QJdCfJ019770 for ; Thu, 26 Apr 2012 15:39:12 -0400 Message-Id: <201204261939.q3QJdCfJ019770@cichlid.raleigh.ibm.com> To: trill@ietf.org Date: Thu, 26 Apr 2012 15:39:12 -0400 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12042619-7282-0000-0000-00000884AD40 Subject: [trill] TRILL OAM Requirements: Connectivity X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 19:39:58 -0000 draft-tissa-trill-oam-req-00.txt has the following definition: > Connected: The term connected is used to indicate reachability; RB2 > is connected to RB1 implies that RB2 is reachable from RB1. This is an unituitive definition to me. In my mind, "connected" means two device are (essentially) separated by a wire. Or, a node is "connected" to a network. I.e,. the two nodes are neighbors. Where does this definition of "connected" come from? Is this taken from somewhere else? Or is this a new definition for TRILL OAM? Why not use a term like "reachable"? Later, one of the requirements is: > OAM MUST have the ability to verify an RBridge RB1 is connected to a > specific RBridge RB2. Given the above defintion, the usage of the term "connected" above is murky to me. The definitions section uses "connected" in a much broader sense than two neighbors being directly attached. Is the above requirement that RB1 be able to verify it is a neighbor of RB2 (and has connectivity?)? Or, if the requirement is testing connectivity between arbitrary RBs, how is that different from other requirements that relate to path verification? > OAM MUST provide functions that enable an RBridge to perform a > Continuity Check to any other RBridge over a specified path or a set > of paths. This section uses "continuity check", which seems like a more precise term than "connected". Thomas From narten@us.ibm.com Thu Apr 26 13:36:52 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F0721F8795 for ; Thu, 26 Apr 2012 13:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 N68SJ9YY9v1O for ; Thu, 26 Apr 2012 13:36:51 -0700 (PDT) Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) by ietfa.amsl.com (Postfix) with ESMTP id 2606A21F8793 for ; Thu, 26 Apr 2012 13:36:51 -0700 (PDT) Received: from /spool/local by e7.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 26 Apr 2012 16:36:45 -0400 Received: from d01dlp02.pok.ibm.com (9.56.224.85) by e7.ny.us.ibm.com (192.168.1.107) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 26 Apr 2012 16:36:42 -0400 Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 2674E6E804B for ; Thu, 26 Apr 2012 16:36:41 -0400 (EDT) Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q3QKacwv109322 for ; Thu, 26 Apr 2012 16:36:39 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q3QKaXJH011183 for ; Thu, 26 Apr 2012 17:36:34 -0300 Received: from cichlid.raleigh.ibm.com ([9.80.5.204]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q3QKaTtu010679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Apr 2012 17:36:32 -0300 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.5/8.12.5) with ESMTP id q3QKaRIm020300; Thu, 26 Apr 2012 16:36:27 -0400 Message-Id: <201204262036.q3QKaRIm020300@cichlid.raleigh.ibm.com> To: Sam Aldrin In-reply-to: <4ECDDE13-BA0F-41E6-BE64-C00CE24D4FBC@gmail.com> References: <344037D7CFEFE84E97E9CC1F56C5F4A50100E64C@xmb-sjc-214.amer.cisco.com> <4ECDDE13-BA0F-41E6-BE64-C00CE24D4FBC@gmail.com> Comments: In-reply-to Sam Aldrin message dated "Wed, 25 Apr 2012 21:52:42 -0700." Date: Thu, 26 Apr 2012 16:36:26 -0400 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12042620-5806-0000-0000-000014A71043 Cc: trill@ietf.org Subject: Re: [trill] TRILL OAM Requirements - X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 20:36:52 -0000 Let me see if I can help tease this apart a bit more. One comment I have (broadly speaking) about the requirements document is that it could be more clear that it is about providing TRILL mechanisms that would allow certain functionality to be provided. Whether an implementation provides all those tools (or facilities) is a separate matter. And may even be out-of-scope for TRILL to *require*. So, if someone is worried that doing something for lots of flows does not scale, there is nothing that says an implemenation is required to *implement* such functionality. In addition, let's assume operators will be smart enough to use facilities that make sense, and that they won't turn on things that cause their networks to keel over. :-) Another way to look at it, ICMP defines echo request/TTL exceeded/etc. Tools like ping/traceroute make use of those facilities. But no where (I think) does the IETF require that an IP stack provide Ping or traceroute. So, TRILL OAM needs to provide mechanisms that can be used to implement OAM. That is what we need to focus on. Sam Aldrin writes: > Santosh, > > Please find my comments inline with %SAM. > > > On Apr 25, 2012, at 3:36 PM, Santosh Rajagopalan wrote: > > > Comments on this doc: > > 4.3 Continuity check: > > This seems to be defined too broadly in the doc. I look at this as a > > keepalive mechanism which gets set by configuration, and stays on > > for a longer period of time (as opposed to connectivity > > verification, which is user-initiated and short-lived). In Ethernet > > OAM, this is used to keep track of connectivity between adjacent > > switches and between switches that lie at the edges of a "level". > > The value of continuity check as defined in this doc seems less > > certain to me. > > %SAM - What would make is certain in a requirements document in your > opinion? MPLS is circuit oriented. I.e., a path is an end to end path. One identifies a path at the head end. Anything that enters an MPLS tunnel pops out at the other end. Trill just doesn't have that notion. So reusing the definitions from RFC5860 doesn't immediately make sense to me. The notion of a path in TRILL is very different than MPLS. The document says: > OAM MUST provide functions that enable an RBridge to perform a > Continuity Check to any other RBridge over a specified path or a set > of paths. How do you indicate what "a specified path" is in TRILL? What is the mechanism for doing so? Is this the same thing as using a flow or is it something different? But the flow-related requirements are mentioned elsewhere, so I'm not sure what the above means/implies. > > What does it mean to have continuity checks for each flow? Each time > > a flow gets initiated, is an operator expected to setup keepalives > > for that flow? Or is this expected to get started automatically > > every time a new flow is detected? > > %SAM - This is requirements document. There should be ability to > verify any given individual path/flow. I think what the requirements document should say is that TRILL OAM must provide mechanisms that allow one to provide continuity checks for particular flows. How and when those are used, and what kind of tools actually make use of these mechanisms is a separate matter (and may even be out-of-scope for TRILL to define in terms of requirements). But TRILL OAM does need to provide the mechanisms to allows such connectivity checks to be done. > > Either way, this doesn't scale for effort or state. > > %SAM - Just because a vendor device cannot scale, it doesn't mean > cannot be done. May be if you can justify with a quantification what > scale metrics you are talking, would help to discuss further. TRILL provides mechanisms, it's a product decision what to implement? :-) > > The same goes for continuity checks which check if each link of a > > multipath is alive. I would recommend that the scope of the > > continuity check messages get narrowed to measure the connectivity > > liveliness for rbridges either on a per-hop basis or an end-to-end > > basis. > > %SAM - Again, I am not sure, based on what quantification you are > arriving at the conclusion. This is fundamental requirement in > other network types as well. So, would like you to provide more > data points to your argument on why it cannot be done in TRILL, > whilst the same is done in other networks. If TRILL just provides mechanisms for such checks, and it is an operator choice where they are enabled, that would seem a reasonable way to have it both ways. > > 4.5. General Requirements > > > "OAM MUST NOT require extensions to or modifications of the TRILL > > header." > > Is the rbridge channel as defined in > http://tools.ietf.org/html/draft-eastlake-trill-rbridge-channel-00 > considered an extension or modification of the TRILL header? > > %SAM - Please ask the author for clarification. I would say "TRILL header" is defined narrowly by the base spec and maybe draft-ietf-trill-rbridge-extension-03.txt And IMO, the channel header is a payload and is not considered part of the TRILL header. The document should say this. > > "OAM, as practical as possible, SHOULD provide a single framework > > between TRILL and other similar standards." > > I'm not sure what this means. Can someone clarify? > > %SAM - We could add more clarifying text here. My take on this is, we > should not define individual framework for different OAM > components. For example, to quickly achieve ping and trace, we define > a packet format. Later, when we want to test multipath/ECMP, > oops..cannot be done, so let us define a new format. So, the > requirement emphasize on avoiding that. Can it be 100% achievable, > simple answer is NO. But we need to try our best. Others could chime > in, if they want to add. My take is that the requirement is somewhat vague, so arguing about what it means is probably not all that useful. And given that it is a SHOULD, rather than MUST, also not critical to define. But at the same time, it makes the requirement not all that meaningful. :-) > > "OAM MUST maintain related error and operational counters." I interpreted this to mean that an implementation must maintain error counters (ok, that isn't rocket science). But it says nothing about how OAM gains access to those counters, or indeed, which counters are appropriate to record. > > Again, what does this mean? Is the requirement that the OAM > > framework defined for trill must be able to query all counters? I do not believe that this is implied. > %SAM - What part is not clear? Requirement is specifying the error > counters should be maintained on an RBridge. Whether you provide > access to query or only display via CLI is implementation specific. I would like to see the document add the following requirement: Error and operational counters SHOULD BE accessed via SNMP. And I would go further and say (though this doesn't need to be said, as long as its understood) that there is no need for OAM to define an alternate mechanism (besides SNMP) for getting access to such counters. Implementations are free of course to do their own thing as well (e.g., CLI). > > "OAM MUST provide a single OAM framework for all TRILL OAM functions" > > Can you provide an example of what would be a violation of this? > > %SAM - see earlier reasoning. IMO, the above should be a SHOULD. Since "single OAM framework" is a nebulous term, I would not be comfortable agreeing it is a MUST. Devil is in the details... But I agree that it's an appropriate goal. > > 4.7. Packet Loss > > > This is another section which is very broadly defined. Most switches > > I know of don't have the ability to maintain packet loss counters > > per flow, or even per source rbridge (leave aside packet loss for > > one link of an ecmp between rbridges). The best you can get here is > > packet losses for a given link, and this is already part of the > > TRILL MIB and can be queried by SNMP. > > %SAM - When you say 'most', does that mean there are switches which > could do that, correct? That is why the word 'SHOULD' is used. If any > vendor cannot support, that is their choice. In regds to MIB or SNMP, > they are part of OAM umbrella. Not sure why this OAM requirement > implemented via SNMP is an issue to you? I think the better thing to do is look at specific requirements: > OAM SHOULD provide the ability to measure packet loss for a > specified flow between any two RBridges. Does this imply a specific requirement on an implementation? Does this require some new OAM mechanism to be defined (beyond what is needed for the other requirements)? I'm not sure... And without being sure, I'm not sure if this should be a SHOULD requirement or not. E.g., is the above saying that one should be able to run a test using a specific flow that measures packet loss? I would say yes. And I think I know how to implement this. Or is this a requirement that says for a given flow X (whatever that means) of *actual* *data* *packets*, does OAM need to be able to track the packet loss *for* *that* *actual* *flow*? If so, I don't know right off how you could do that and it sounds expensive/complex to implement. I wouldn't want this to be a requirement. :-) Thus, further clarification would seem in order. > > 4.8. Packet Delay > > > As defined here, measurement of packet delay seems to require > > hardware support. Is that the intent? Or is this supposed to measure > > delay between OAM software processes on the relevant switches? > > %SAM - I think it is both. If you can timestamp at each level, one > could provide more granular levels. How you do it? could be > proprietary or part of solution documents. We are not intereseted in proprietary solutions. :-) What is the actual TRILL OAM *mechanism* that would be needed to support such a requirement? That is what we should focus on. > > > > > 5. General Format of TRILL OAM Messages > > > The inner ethernet header should be called out explicitly, instead > > of being subsumed in the "Flow entropy" section, since using > > anything other than ethernet after the trill header would break > > every single trill compliant piece of silicon I know of. > > %SAM - We have merchant silicon vendors on the author list. I have my > opinion but will leave it for them to comment. :D To be clear, it would be helpful to me if Figure 1 showed what the TRILL header part contained. Does it contain the inner src/dst MAC and VLAN, for instance? Actually, it clearly does not. RFC6325 does not consider the inner header to be part of the TRILL header. It would probably help to give an example as to what the Flow Entropy field contained. Also, the inner header fields (like reserved DA multicast addresses) have special meaning in TRILL. Are there any special rules wrt the Flow Entropy field wrt reserved or otherwise specially defifined values? Thomas From aldrin.ietf@gmail.com Thu Apr 26 15:13:42 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 466A821F86A4 for ; Thu, 26 Apr 2012 15:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] 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 07kRRCu-tV70 for ; Thu, 26 Apr 2012 15:13:40 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA1D21F8646 for ; Thu, 26 Apr 2012 15:13:40 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so217231pbb.31 for ; Thu, 26 Apr 2012 15:13:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=RN2tpv8SkPXKdqNqNrog4ghZqiic7+0qy2L2NZ/YXJ8=; b=LD+EMSLFmao94fJ3bGdTFR3B+WC2NyYNs0mUa6vlp13l/BAhDS9b053nhGLuuGzWvr 4Jv+ZwSjkU/muZT8jzhR0DVxWJtemYJGdyawBJ71rd+x+fEgE+wAEyL8JC2XBZa7iECM 9RMB+CfvJRgUn74s+KJRPUaf1m6iq4JZdkmdMY8evxw+IeiPGJETM+6bBUg2h/KYsX5m fq2CJ5R/BlRgT+FLfsVeoxGVTQgMdIESnwvddHNMQEbiz4aRRu1W3lY3ScRIGeRUABWS uldYWRbPYE02IUDUTQhkGZkxhI1Xbl6LzUBG7nJHQa/5MK+lIwmcW/3+zntXxRZXVTMf 5HCQ== Received: by 10.68.132.232 with SMTP id ox8mr18467458pbb.145.1335478420269; Thu, 26 Apr 2012 15:13:40 -0700 (PDT) Received: from [192.168.255.176] ([12.207.18.42]) by mx.google.com with ESMTPS id la9sm4457616pbc.1.2012.04.26.15.13.38 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 Apr 2012 15:13:38 -0700 (PDT) References: <344037D7CFEFE84E97E9CC1F56C5F4A50100E64C@xmb-sjc-214.amer.cisco.com> <4ECDDE13-BA0F-41E6-BE64-C00CE24D4FBC@gmail.com> <201204262036.q3QKaRIm020300@cichlid.raleigh.ibm.com> In-Reply-To: <201204262036.q3QKaRIm020300@cichlid.raleigh.ibm.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <6157EE78-9F6D-4D87-92CA-78F616E7707B@gmail.com> X-Mailer: iPad Mail (9B176) From: Sam Aldrin Date: Thu, 26 Apr 2012 15:13:37 -0700 To: Thomas Narten Cc: "trill@ietf.org" Subject: Re: [trill] TRILL OAM Requirements - X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 22:13:42 -0000 See my comments inline. Sent from my iPad On Apr 26, 2012, at 1:36 PM, Thomas Narten wrote: > Let me see if I can help tease this apart a bit more. >=20 > One comment I have (broadly speaking) about the requirements document > is that it could be more clear that it is about providing TRILL > mechanisms that would allow certain functionality to be > provided. Whether an implementation provides all those tools (or > facilities) is a separate matter. And may even be out-of-scope for > TRILL to *require*. >=20 > So, if someone is worried that doing something for lots of flows does > not scale, there is nothing that says an implemenation is required to > *implement* such functionality. In addition, let's assume operators > will be smart enough to use facilities that make sense, and that they > won't turn on things that cause their networks to keel over. :-) Thanks for asserting what I was saying. :D >=20 > Another way to look at it, ICMP defines echo request/TTL > exceeded/etc. Tools like ping/traceroute make use of those > facilities. But no where (I think) does the IETF require that an IP > stack provide Ping or traceroute. That's exactly should be with OAM for TRILL as well. Whether one implements v= ia ping or trace is beyond the scope of this doc. >=20 > So, TRILL OAM needs to provide mechanisms that can be used to > implement OAM. That is what we need to focus on. >=20 > Sam Aldrin writes: >=20 >> Santosh, >>=20 >> Please find my comments inline with %SAM. >>=20 >>> On Apr 25, 2012, at 3:36 PM, Santosh Rajagopalan wrote: >>=20 >>> Comments on this doc: >>> 4.3 Continuity check: >>> This seems to be defined too broadly in the doc. I look at this as a >>> keepalive mechanism which gets set by configuration, and stays on >>> for a longer period of time (as opposed to connectivity >>> verification, which is user-initiated and short-lived). In Ethernet >>> OAM, this is used to keep track of connectivity between adjacent >>> switches and between switches that lie at the edges of a "level". >>> The value of continuity check as defined in this doc seems less >>> certain to me. >>=20 >> %SAM - What would make is certain in a requirements document in your >> opinion? >=20 > MPLS is circuit oriented. I.e., a path is an end to end path. One > identifies a path at the head end. Anything that enters an MPLS tunnel > pops out at the other end. Trill just doesn't have that notion. So > reusing the definitions from RFC5860 doesn't immediately make sense to > me. >=20 > The notion of a path in TRILL is very different than MPLS. If it same as MPLS, there wouldn't be TRILL, instead it is all mpls. Having s= aid that, whether it is mpls packet or trill frame, both traverse the device= s and the path could be traced and verified. Tis includes load balancing etc= . there exists unicast and multicast in both the places. We should be reusin= g whatever was laid out for mpls as much as possible. If something is not re= ally applicable, we can always address that, which I haven't seen in the abo= ve case or question. >=20 > The document says: >=20 >> OAM MUST provide functions that enable an RBridge to perform a >> Continuity Check to any other RBridge over a specified path or a set >> of paths. >=20 > How do you indicate what "a specified path" is in TRILL? What is the > mechanism for doing so? Is this the same thing as using a flow or is > it something different? But the flow-related requirements are > mentioned elsewhere, so I'm not sure what the above means/implies. Imo they represent the same. May be we should clarify what path and flow mea= n. Whether they are same or different. >=20 >>> What does it mean to have continuity checks for each flow? Each time >>> a flow gets initiated, is an operator expected to setup keepalives >>> for that flow? Or is this expected to get started automatically >>> every time a new flow is detected? >>=20 >> %SAM - This is requirements document. There should be ability to >> verify any given individual path/flow. >=20 > I think what the requirements document should say is that TRILL OAM > must provide mechanisms that allow one to provide continuity checks > for particular flows. How and when those are used, and what kind of > tools actually make use of these mechanisms is a separate matter (and > may even be out-of-scope for TRILL to define in terms of > requirements). But TRILL OAM does need to provide the mechanisms to > allows such connectivity checks to be done. Yes. Solution document covers how to achieve that. One step at a time. >=20 >>> Either way, this doesn't scale for effort or state. >>=20 >> %SAM - Just because a vendor device cannot scale, it doesn't mean >> cannot be done. May be if you can justify with a quantification what >> scale metrics you are talking, would help to discuss further. >=20 > TRILL provides mechanisms, it's a product decision what to implement? > :-) >=20 >>> The same goes for continuity checks which check if each link of a >>> multipath is alive. I would recommend that the scope of the >>> continuity check messages get narrowed to measure the connectivity >>> liveliness for rbridges either on a per-hop basis or an end-to-end >>> basis. >>=20 >> %SAM - Again, I am not sure, based on what quantification you are >> arriving at the conclusion. This is fundamental requirement in >> other network types as well. So, would like you to provide more >> data points to your argument on why it cannot be done in TRILL, >> whilst the same is done in other networks. >=20 > If TRILL just provides mechanisms for such checks, and it is an > operator choice where they are enabled, that would seem a reasonable > way to have it both ways. Ack. >=20 >>> 4.5. General Requirements >>=20 >>> "OAM MUST NOT require extensions to or modifications of the TRILL >>> header." >>> Is the rbridge channel as defined in >> http://tools.ietf.org/html/draft-eastlake-trill-rbridge-channel-00 >> considered an extension or modification of the TRILL header? >>=20 >> %SAM - Please ask the author for clarification. >=20 > I would say "TRILL header" is defined narrowly by the base spec and > maybe draft-ietf-trill-rbridge-extension-03.txt >=20 > And IMO, the channel header is a payload and is not considered part of > the TRILL header. The document should say this. >=20 >>> "OAM, as practical as possible, SHOULD provide a single framework >>> between TRILL and other similar standards." >>> I'm not sure what this means. Can someone clarify? >>=20 >> %SAM - We could add more clarifying text here. My take on this is, we >> should not define individual framework for different OAM >> components. For example, to quickly achieve ping and trace, we define >> a packet format. Later, when we want to test multipath/ECMP, >> oops..cannot be done, so let us define a new format. So, the >> requirement emphasize on avoiding that. Can it be 100% achievable, >> simple answer is NO. But we need to try our best. Others could chime >> in, if they want to add. >=20 > My take is that the requirement is somewhat vague, so arguing about > what it means is probably not all that useful. And given that it is a > SHOULD, rather than MUST, also not critical to define. But at the > same time, it makes the requirement not all that meaningful. :-) Do you want it to be moved to MUST to make it meaningful :D >=20 >>> "OAM MUST maintain related error and operational counters." >=20 > I interpreted this to mean that an implementation must maintain error > counters (ok, that isn't rocket science). But it says nothing about > how OAM gains access to those counters, or indeed, which counters are > appropriate to record. We could further classify the error counters. But do to agree that mentionin= g access method is part of the scope. If I say, XML must, not many folks may= like it. >=20 >>> Again, what does this mean? Is the requirement that the OAM >>> framework defined for trill must be able to query all counters? >=20 > I do not believe that this is implied. >=20 >> %SAM - What part is not clear? Requirement is specifying the error >> counters should be maintained on an RBridge. Whether you provide >> access to query or only display via CLI is implementation specific. >=20 > I would like to see the document add the following requirement: >=20 > Error and operational counters SHOULD BE accessed via SNMP. If Snmp, why not cli, XML etc? >=20 > And I would go further and say (though this doesn't need to be said, > as long as its understood) that there is no need for OAM to define an > alternate mechanism (besides SNMP) for getting access to such > counters. Implementations are free of course to do their own thing as > well (e.g., CLI). I still say, we should not define any here. If folks think Snmp is great, so= be it. But not everyone is employing Snmp as 'the' baseline mechanism. >=20 >>> "OAM MUST provide a single OAM framework for all TRILL OAM functions" >>> Can you provide an example of what would be a violation of this? >>=20 >> %SAM - see earlier reasoning. >=20 > IMO, the above should be a SHOULD. Since "single OAM framework" is a > nebulous term, I would not be comfortable agreeing it is a MUST. Devil > is in the details... >=20 > But I agree that it's an appropriate goal. Yes it is a noble goal, to ensure future changes adhere to it. As we all sha= re the same goal, do not think we should deliberate too much, unless one is p= lanning alternate mechanism. >=20 >>> 4.7. Packet Loss >>=20 >>> This is another section which is very broadly defined. Most switches >>> I know of don't have the ability to maintain packet loss counters >>> per flow, or even per source rbridge (leave aside packet loss for >>> one link of an ecmp between rbridges). The best you can get here is >>> packet losses for a given link, and this is already part of the >>> TRILL MIB and can be queried by SNMP. >>=20 >> %SAM - When you say 'most', does that mean there are switches which >> could do that, correct? That is why the word 'SHOULD' is used. If any >> vendor cannot support, that is their choice. In regds to MIB or SNMP, >> they are part of OAM umbrella. Not sure why this OAM requirement >> implemented via SNMP is an issue to you? >=20 > I think the better thing to do is look at specific requirements: >=20 >> OAM SHOULD provide the ability to measure packet loss for a >> specified flow between any two RBridges. >=20 > Does this imply a specific requirement on an implementation? Does this > require some new OAM mechanism to be defined (beyond what is needed > for the other requirements)? I'm not sure... And without being sure, > I'm not sure if this should be a SHOULD requirement or not. As this is requirement/framework document, do you agree that one should be a= ble to measure packet loss for a given path? There are many ways one could i= mplement this. Mpls has its own, 1731 specifies its own way. We could come u= p with one, later, as well. But frame work should be able to support it. >=20 > E.g., is the above saying that one should be able to run a test using > a specific flow that measures packet loss? I would say yes. And I > think I know how to implement this. >=20 > Or is this a requirement that says for a given flow X (whatever that > means) of *actual* *data* *packets*, does OAM need to be able to track > the packet loss *for* *that* *actual* *flow*? If so, I don't know > right off how you could do that and it sounds expensive/complex to > implement. I wouldn't want this to be a requirement. :-) Agree. If you specify, I would not implement :D >=20 > Thus, further clarification would seem in order. >=20 >>> 4.8. Packet Delay >>=20 >>> As defined here, measurement of packet delay seems to require >>> hardware support. Is that the intent? Or is this supposed to measure >>> delay between OAM software processes on the relevant switches? >>=20 >> %SAM - I think it is both. If you can timestamp at each level, one >> could provide more granular levels. How you do it? could be >> proprietary or part of solution documents. >=20 > We are not intereseted in proprietary solutions. :-) What is the > actual TRILL OAM *mechanism* that would be needed to support such a > requirement? That is what we should focus on. Measuring rtt, one way delay etc are in the scope here. When we consider pay= load, we should consider time stamp fields option. Sam >=20 >>=20 >>>=20 >>> 5. General Format of TRILL OAM Messages >>=20 >>> The inner ethernet header should be called out explicitly, instead >>> of being subsumed in the "Flow entropy" section, since using >>> anything other than ethernet after the trill header would break >>> every single trill compliant piece of silicon I know of. >>=20 >> %SAM - We have merchant silicon vendors on the author list. I have my >> opinion but will leave it for them to comment. :D >=20 > To be clear, it would be helpful to me if Figure 1 showed what the > TRILL header part contained. Does it contain the inner src/dst MAC and > VLAN, for instance? Actually, it clearly does not. RFC6325 does not > consider the inner header to be part of the TRILL header. >=20 > It would probably help to give an example as to what the Flow Entropy > field contained. Also, the inner header fields (like reserved DA > multicast addresses) have special meaning in TRILL. Are there any > special rules wrt the Flow Entropy field wrt reserved or otherwise > specially defifined values? >=20 > Thomas >=20 >=20 From tsenevir@cisco.com Thu Apr 26 15:33:54 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3F6521F87AA for ; Thu, 26 Apr 2012 15:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.782 X-Spam-Level: X-Spam-Status: No, score=-7.782 tagged_above=-999 required=5 tests=[AWL=2.817, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 YOeJkbZUx2oI for ; Thu, 26 Apr 2012 15:33:53 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 0BDEF21F87A7 for ; Thu, 26 Apr 2012 15:33:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tsenevir@cisco.com; l=2224; q=dns/txt; s=iport; t=1335479633; x=1336689233; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=ybZ6VlXfdPuAYnNiiKgGVUubVtplvse+GAM7pc/R61s=; b=juEqkBQ29jq/b63GS10RjH4DgA61Vl3jWv7yknT2qlsI5fz1iB0tVago nggdY8mUA4q0FtcisAhCueNFhtyw/uDMS1yw0L1UdrB+lkxL8FtrNFTMK QZNM5utxqZi1Pbu4KdC0hgv1himhd+0Q+BC2A4kGFUODmgS9gVh+xw0k4 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAJPMmU+rRDoI/2dsb2JhbAA7CrFygQeCCQEBAQMBAQEBDwEdCjQQBwQCAQgRBAEBCwYXAQYBJh8JCAEBBAESCBqHZgQBC5sroBoEinmFYmMEiGObcYFpgwg X-IronPort-AV: E=Sophos;i="4.75,487,1330905600"; d="scan'208";a="39771641" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 26 Apr 2012 22:33:48 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3QMXk14007503; Thu, 26 Apr 2012 22:33:46 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 15:33:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Apr 2012 15:33:44 -0700 Message-ID: <344037D7CFEFE84E97E9CC1F56C5F4A5010A2C32@xmb-sjc-214.amer.cisco.com> In-Reply-To: <201204261813.q3QID7ZP018730@cichlid.raleigh.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [trill] TRILL OAM Requirements: Sections Thread-Index: Ac0j2FFdYpSNWiH6QBq206hyaT+tKQAI24TA References: <201204261813.q3QID7ZP018730@cichlid.raleigh.ibm.com> From: "Tissa Senevirathne (tsenevir)" To: "Thomas Narten" , X-OriginalArrivalTime: 26 Apr 2012 22:33:46.0278 (UTC) FILETIME=[A488EC60:01CD23FC] Subject: Re: [trill] TRILL OAM Requirements: Sections X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 22:33:54 -0000 "Section" is a general terminology used to identify a partial segment of the path between two end points. Please refer to RFC 5860 "Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks". 5860 is listed as a reference in the document. draft-tissa-trill-oam-req assumes readers are familiar with various OAM concept in the industry. Relevant documents are also listed as references. -----Original Message----- From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of Thomas Narten Sent: Thursday, April 26, 2012 11:13 AM To: trill@ietf.org Subject: [trill] TRILL OAM Requirements: Sections draft-tissa-trill-oam-req-00.txt says; > Section: A section is a partial segment of a path between any two > given RBridges. As an example, consider the case where RB1 is > connected to RBx via RB2 and RB3. The segment between RB3 to RBx is > referred to as a Section of the path RB1 to RBx. Where does this notion of a section come from and why do we need it in TRILL? AFAIK, TRILL doesn't have this notion, so this is something that OAM is creating on its own. Then later: > An RBridge SHOULD have the ability to verify the above connectivity > tests on sections. As an example, assume RB1 is connected to RB5 via > RB2, RB3 and RB4. An operator SHOULD be able to verify the RB1 to > RB5 connectivity on the section from RB3 to RB5. The difference is > that the ingress and egress TRILL nicknames in this case are RB1 and > RB5 as opposed to RB3 and RB5, even though the message itself may > originate at RB3. I am not comfortable with this requirement. This would seem to complicate the requirements and I'm not sure why it is needed. I'm also a bit wary about what the implication is in terms of what sort of functionality or mechanism would be required to be able to achieve this requirement. (The notion of "sections" comes up in several places in the document, and the above applies to all of them.) Do we really want or need sections? Thomas _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill From narten@us.ibm.com Thu Apr 26 17:08:13 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7160B21E80B8 for ; Thu, 26 Apr 2012 17:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 Z6WAaDvhl1hK for ; Thu, 26 Apr 2012 17:08:12 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by ietfa.amsl.com (Postfix) with ESMTP id 759E521E805F for ; Thu, 26 Apr 2012 17:08:12 -0700 (PDT) Received: from /spool/local by e3.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 26 Apr 2012 20:08:10 -0400 Received: from d01dlp02.pok.ibm.com (9.56.224.85) by e3.ny.us.ibm.com (192.168.1.103) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 26 Apr 2012 20:07:41 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 7839F6E8049 for ; Thu, 26 Apr 2012 20:07:40 -0400 (EDT) Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q3R07dWQ114736 for ; Thu, 26 Apr 2012 20:07:40 -0400 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q3R08EAJ031150 for ; Thu, 26 Apr 2012 18:08:14 -0600 Received: from cichlid.raleigh.ibm.com ([9.80.5.204]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q3R08Dwh031110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Apr 2012 18:08:14 -0600 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.5/8.12.5) with ESMTP id q3R07bT0026940; Thu, 26 Apr 2012 20:07:37 -0400 Message-Id: <201204270007.q3R07bT0026940@cichlid.raleigh.ibm.com> To: "Tissa Senevirathne (tsenevir)" In-reply-to: <344037D7CFEFE84E97E9CC1F56C5F4A5010A2C32@xmb-sjc-214.amer.cisco.com> References: <201204261813.q3QID7ZP018730@cichlid.raleigh.ibm.com> <344037D7CFEFE84E97E9CC1F56C5F4A5010A2C32@xmb-sjc-214.amer.cisco.com> Comments: In-reply-to "Tissa Senevirathne (tsenevir)" message dated "Thu, 26 Apr 2012 15:33:44 -0700." Date: Thu, 26 Apr 2012 20:07:36 -0400 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12042700-8974-0000-0000-000008850CE9 Cc: trill@ietf.org Subject: Re: [trill] TRILL OAM Requirements: Sections X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 00:08:13 -0000 Hi Tissa. "Tissa Senevirathne (tsenevir)" writes: > "Section" is a general terminology used to identify a partial segment of > the path between two end points. Please refer to RFC 5860 "Requirements > for Operations, Administration, and Maintenance (OAM) in MPLS Transport > Networks". 5860 is listed as a reference in the document. > draft-tissa-trill-oam-req assumes readers are familiar with various OAM > concept in the industry. Relevant documents are also listed as > references. You didn't really respond to my core point though. Why should TRILL OAM support this notion? What value does it have in a TRILL network? I cannot agree to say TRILL OAM needs to support this notion because I don't understand the implications in terms of how it will impact the OAM mechanisms and protocols that need to be defined. Without understanding that (in a rough, architectural sense), I cannot support it. I also just don't see the value. Do operators define sections? How is that useful in a TRILL network? Thomas > -----Original Message----- > From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf > Of Thomas Narten > Sent: Thursday, April 26, 2012 11:13 AM > To: trill@ietf.org > Subject: [trill] TRILL OAM Requirements: Sections > draft-tissa-trill-oam-req-00.txt says; > > Section: A section is a partial segment of a path between any two > > given RBridges. As an example, consider the case where RB1 is > > connected to RBx via RB2 and RB3. The segment between RB3 to RBx is > > referred to as a Section of the path RB1 to RBx. > Where does this notion of a section come from and why do we need it in > TRILL? AFAIK, TRILL doesn't have this notion, so this is something that > OAM is creating on its own. > Then later: > > An RBridge SHOULD have the ability to verify the above connectivity > > tests on sections. As an example, assume RB1 is connected to RB5 > via > > RB2, RB3 and RB4. An operator SHOULD be able to verify the RB1 to > > RB5 connectivity on the section from RB3 to RB5. The difference is > > that the ingress and egress TRILL nicknames in this case are RB1 > and > > RB5 as opposed to RB3 and RB5, even though the message itself may > > originate at RB3. > I am not comfortable with this requirement. This would seem to > complicate the requirements and I'm not sure why it is needed. I'm also > a bit wary about what the implication is in terms of what sort of > functionality or mechanism would be required to be able to achieve this > requirement. > (The notion of "sections" comes up in several places in the document, > and the above applies to all of them.) > Do we really want or need sections? > Thomas > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill From liao.ting@zte.com.cn Thu Apr 26 18:47:19 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 612AA11E8097; Thu, 26 Apr 2012 18:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.134 X-Spam-Level: X-Spam-Status: No, score=-95.134 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] 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 GUZooMDiSK9V; Thu, 26 Apr 2012 18:47:19 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 5639F11E8096; Thu, 26 Apr 2012 18:47:16 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 286201455586978; Fri, 27 Apr 2012 09:06:10 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 59876.1726657790; Fri, 27 Apr 2012 09:46:57 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q3R1l6wd011733; Fri, 27 Apr 2012 09:47:06 +0800 (GMT-8) (envelope-from liao.ting@zte.com.cn) In-Reply-To: To: Donald Eastlake MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: liao.ting@zte.com.cn Date: Fri, 27 Apr 2012 09:46:56 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-27 09:47:07, Serialize complete at 2012-04-27 09:47:07 Content-Type: multipart/alternative; boundary="=_alternative 0009CEB7482579ED_=" X-MAIL: mse02.zte.com.cn q3R1l6wd011733 Cc: trill-bounces@ietf.org, trill@ietf.org Subject: [trill] =?gb2312?b?tPC4tDogIGRyYWZ0LWh1LXRyaWxsLXJicmlkZ2UtZXNh?= =?gb2312?b?ZGkgdG8gVFJJTEwgV0cgZHJhZnQ=?= X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 01:47:19 -0000 This is a multipart message in MIME format. --=_alternative 0009CEB7482579ED_= Content-Type: text/plain; charset="US-ASCII" I have read this document and support it. BRs, Liao Ting --=_alternative 0009CEB7482579ED_= Content-Type: text/html; charset="US-ASCII"
I have read this document and support it.

BRs,
Liao Ting --=_alternative 0009CEB7482579ED_=-- From nordmark@acm.org Fri Apr 27 09:29:34 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5047F21F86A5 for ; Fri, 27 Apr 2012 09:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 LgkVHwrTNn98 for ; Fri, 27 Apr 2012 09:29:33 -0700 (PDT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by ietfa.amsl.com (Postfix) with ESMTP id CD19821F868A for ; Fri, 27 Apr 2012 09:29:33 -0700 (PDT) Received: from [10.33.22.115] (128-107-239-233.cisco.com [128.107.239.233]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id q3RGTVBT019361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2012 09:29:31 -0700 Message-ID: <4F9AC96C.8010606@acm.org> Date: Fri, 27 Apr 2012 09:29:32 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: Thomas Narten References: <201204261939.q3QJdCfJ019770@cichlid.raleigh.ibm.com> In-Reply-To: <201204261939.q3QJdCfJ019770@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: trill@ietf.org Subject: Re: [trill] TRILL OAM Requirements: Connectivity X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 16:29:34 -0000 On 4/26/12 12:39 PM, Thomas Narten wrote: > draft-tissa-trill-oam-req-00.txt has the following definition: > >> Connected: The term connected is used to indicate reachability; RB2 >> is connected to RB1 implies that RB2 is reachable from RB1. > > This is an unituitive definition to me. In my mind, "connected" means > two device are (essentially) separated by a wire. Or, a node is > "connected" to a network. I.e,. the two nodes are neighbors. > > Where does this definition of "connected" come from? Is this taken > from somewhere else? Or is this a new definition for TRILL OAM? When I read the document yesterday the "connected" term made me stumble as well. If this is a well-defined term in other OAM standards, then we should include that definition in the terminology section so that it can be clear. If it is not, then lets use a term that is more clear. Erik From internet-drafts@ietf.org Fri Apr 27 09:48:53 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0994921F873E; Fri, 27 Apr 2012 09:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.503 X-Spam-Level: X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 1q58H-C+AHRy; Fri, 27 Apr 2012 09:48:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5629221F86B1; Fri, 27 Apr 2012 09:48:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120427164852.18814.93540.idtracker@ietfa.amsl.com> Date: Fri, 27 Apr 2012 09:48:52 -0700 Cc: trill@ietf.org Subject: [trill] I-D Action: draft-ietf-trill-rbridge-vlan-mapping-07.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 16:48:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transparent Interconnection of Lots o= f Links Working Group of the IETF. Title : RBridges: Campus VLAN and Priority Regions Author(s) : Radia Perlman Ayan Banerjee Anil Rijhsinghani Donald Eastlake Dinesh G. Dutt Filename : draft-ietf-trill-rbridge-vlan-mapping-07.txt Pages : 19 Date : 2012-04-27 Within an RBridge campus, the VLAN and priority of TRILL encapsulated frames is preserved. However, in some cases it may be desired that data VLAN and/or priority be mapped at the boundary between regions of such a campus. This document describes an optional RBridge feature to provide this function. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-vlan-mapping-0= 7.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-trill-rbridge-vlan-mapping-07= .txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-vlan-mapping/ From nordmark@acm.org Fri Apr 27 09:53:27 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD00421F8633 for ; Fri, 27 Apr 2012 09:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 edep7-3nM0jW for ; Fri, 27 Apr 2012 09:53:27 -0700 (PDT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by ietfa.amsl.com (Postfix) with ESMTP id 2640B21F85FB for ; Fri, 27 Apr 2012 09:53:27 -0700 (PDT) Received: from [10.33.22.115] (128-107-239-233.cisco.com [128.107.239.233]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id q3RGrOpQ031742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2012 09:53:25 -0700 Message-ID: <4F9ACF05.9070302@acm.org> Date: Fri, 27 Apr 2012 09:53:25 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: trill@ietf.org References: <4F9ACE0E.7030408@sonic.net> In-Reply-To: <4F9ACE0E.7030408@sonic.net> X-Forwarded-Message-Id: <4F9ACE0E.7030408@sonic.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [trill] TRILL OAM Requirements: available paths X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 16:53:27 -0000 Two requirements use the wording "all available paths." and "all available ECMP paths.", respectively and I'm not sure I know what that means. Take the following example picture: R1 / \ / \ / \ / \ / \ RB11 RB12 / \ / \ / \ / \ RB111 RB112 RB121 RB122 \ \ / / \ \ / / \ \/ / ------R2------ We can see that there are 4 paths with 3 hops to get from R1 to R2, with two layers of ECMP decisions. But how many available paths are there? Given that the RBridges make independent ECMP decisions, and how they do that is a local matter, it could be the case that for any packet, if R1 picks the left link, then R11 would also pick the left link; if R1 picks the right link, then R12 also picks the right link. Thus there would be no packet (data or OAM) that would cause packets between R1 and R2 to pass via RB112 or RB121. Even if we ignore that as unlikely, there is still the fact that R1 can't easily tell how many (shortest) paths there might be between it and R2. With single-level TRILL the LSDB could be used to tell, but if we ever go to multi-level that wouldn't be the case any more. And even if R1 knows that there are 4 potential paths, it can't format a data packet (or format the flow entropy in an OAM packet) in such a way that particular paths get chosen by downstream ECMP decisions. Thus for any notion of "all available paths" that make sense to me, we'd need an OAM approach that can explore the topology one hop at a time and at each hop explore all the possible ECMP choices. Using the entropy doesn't help with this (but the entropy is critical for following the path taken by a particular flow of data packets). Hence it would be good to clarify what the assumptions are behind this notion of all available paths. Thanks, Erik From tsenevir@cisco.com Fri Apr 27 14:13:33 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5412711E8087 for ; Fri, 27 Apr 2012 14:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.064 X-Spam-Level: X-Spam-Status: No, score=-8.064 tagged_above=-999 required=5 tests=[AWL=2.535, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 DGBCQ5KFqs0C for ; Fri, 27 Apr 2012 14:13:32 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id C65AC11E8085 for ; Fri, 27 Apr 2012 14:13:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tsenevir@cisco.com; l=2804; q=dns/txt; s=iport; t=1335561212; x=1336770812; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=EEo+buZpOcmSP6tCLuwHDc5HeO2eCoPJngJ5yupkeKI=; b=mdXT9bTAnSYPLxN3scUCPYSuspJRHtgD1gSGJgynEJOXbO7DkrAZdsU6 /7TOIzjHbwQyDCT6RgDVu4uHL2W3j8Ago3ZuF73gU4OJfMWankFlkLxTv Ho8j4NiLq8zdaUn5HWs0EmLVW4pbBnvNhZg8+pa7JQULuC/Qezo4mWcmu k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJkKm0+rRDoH/2dsb2JhbABEsgSBB4IJAQEBBAEBAQ8BHQo0FwQCAQgRBAEBCwYXAQYBJh8JCAEBBAESCBMHh2oBC5ssoAgEkDpjBIhjm3GBaYMI X-IronPort-AV: E=Sophos;i="4.75,492,1330905600"; d="scan'208";a="39978628" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 27 Apr 2012 21:13:32 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q3RLDWE8027269; Fri, 27 Apr 2012 21:13:32 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Apr 2012 14:13:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Apr 2012 14:13:31 -0700 Message-ID: <344037D7CFEFE84E97E9CC1F56C5F4A5010A2F53@xmb-sjc-214.amer.cisco.com> In-Reply-To: <4F9ACF05.9070302@acm.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [trill] TRILL OAM Requirements: available paths Thread-Index: Ac0klkgYZRoDDAszRZ+jlME9RN9NSAAI6mGA References: <4F9ACE0E.7030408@sonic.net> <4F9ACF05.9070302@acm.org> From: "Tissa Senevirathne (tsenevir)" To: "Erik Nordmark" , X-OriginalArrivalTime: 27 Apr 2012 21:13:32.0320 (UTC) FILETIME=[999AFA00:01CD24BA] Subject: Re: [trill] TRILL OAM Requirements: available paths X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 21:13:33 -0000 We can make the wording uniform. It was intended to be all available ECMP paths. Because with IS-IS in place you have only visibility to the Equal cost paths. When using multi-level TRILL, still the packets get forwarded along the Equal Cost Multipaths when it is available. How the entropy is derived to cover different equal cost paths is in the scope of a framework/solution. -----Original Message----- From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of Erik Nordmark Sent: Friday, April 27, 2012 9:53 AM To: trill@ietf.org Subject: [trill] TRILL OAM Requirements: available paths Two requirements use the wording "all available paths." and "all available ECMP paths.", respectively and I'm not sure I know what that means. Take the following example picture: R1 / \ / \ / \ / \ / \ RB11 RB12 / \ / \ / \ / \ RB111 RB112 RB121 RB122 \ \ / / \ \ / / \ \/ / ------R2------ We can see that there are 4 paths with 3 hops to get from R1 to R2, with two layers of ECMP decisions. But how many available paths are there? Given that the RBridges make independent ECMP decisions, and how they do that is a local matter, it could be the case that for any packet, if R1 picks the left link, then R11 would also pick the left link; if R1 picks the right link, then R12 also picks the right link. Thus there would be no packet (data or OAM) that would cause packets between R1 and R2 to pass via RB112 or RB121. Even if we ignore that as unlikely, there is still the fact that R1 can't easily tell how many (shortest) paths there might be between it and R2. With single-level TRILL the LSDB could be used to tell, but if we ever go to multi-level that wouldn't be the case any more. And even if R1 knows that there are 4 potential paths, it can't format a data packet (or format the flow entropy in an OAM packet) in such a way that particular paths get chosen by downstream ECMP decisions. Thus for any notion of "all available paths" that make sense to me, we'd need an OAM approach that can explore the topology one hop at a time and at each hop explore all the possible ECMP choices. Using the entropy doesn't help with this (but the entropy is critical for following the path taken by a particular flow of data packets). Hence it would be good to clarify what the assumptions are behind this notion of all available paths. Thanks, Erik _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill From sunny.rajagopalan@us.ibm.com Fri Apr 27 14:16:05 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6F121F8582 for ; Fri, 27 Apr 2012 14:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.348 X-Spam-Level: X-Spam-Status: No, score=-10.348 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 JHke69W2tDYq for ; Fri, 27 Apr 2012 14:16:05 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5ED21F8575 for ; Fri, 27 Apr 2012 14:16:00 -0700 (PDT) Received: from /spool/local by e35.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 27 Apr 2012 15:16:00 -0600 Received: from d03dlp02.boulder.ibm.com (9.17.202.178) by e35.co.us.ibm.com (192.168.1.135) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 27 Apr 2012 15:15:58 -0600 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id CB0D63E40036; Fri, 27 Apr 2012 15:15:57 -0600 (MDT) Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q3RLFavJ160436; Fri, 27 Apr 2012 15:15:39 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q3RLFX4l028309; Fri, 27 Apr 2012 15:15:34 -0600 Received: from d03nm127.boulder.ibm.com (d03nm127.boulder.ibm.com [9.17.195.18]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q3RLFWQj028268; Fri, 27 Apr 2012 15:15:32 -0600 In-Reply-To: <4F9ACF05.9070302@acm.org> References: <4F9ACE0E.7030408@sonic.net> <4F9ACF05.9070302@acm.org> To: Erik Nordmark MIME-Version: 1.0 X-KeepSent: 909960BD:8F0E0541-872579ED:007407A1; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: Santosh Rajagopalan Date: Fri, 27 Apr 2012 14:15:25 -0700 X-MIMETrack: Serialize by Router on D03NM127/03/M/IBM(Release 8.5.1FP2|March 17, 2010) at 04/27/2012 15:15:32, Serialize complete at 04/27/2012 15:15:32 Content-Type: multipart/alternative; boundary="=_alternative 0074C89F882579ED_=" X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12042721-6148-0000-0000-0000056257F0 Cc: trill-bounces@ietf.org, trill@ietf.org Subject: Re: [trill] TRILL OAM Requirements: available paths X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 21:16:05 -0000 This is a multipart message in MIME format. --=_alternative 0074C89F882579ED_= Content-Type: text/plain; charset="US-ASCII" I agree, the wording needs to be tightened to say "all possible ecmp paths" rather than "all available paths". An operator working out R1-R2 communication is interested in all possible paths data traffic could take rather than all theoretically available paths. From: Erik Nordmark To: trill@ietf.org Date: 04/27/2012 09:53 AM Subject: [trill] TRILL OAM Requirements: available paths Sent by: trill-bounces@ietf.org Two requirements use the wording "all available paths." and "all available ECMP paths.", respectively and I'm not sure I know what that means. Take the following example picture: R1 / \ / \ / \ / \ / \ RB11 RB12 / \ / \ / \ / \ RB111 RB112 RB121 RB122 \ \ / / \ \ / / \ \/ / ------R2------ We can see that there are 4 paths with 3 hops to get from R1 to R2, with two layers of ECMP decisions. But how many available paths are there? Given that the RBridges make independent ECMP decisions, and how they do that is a local matter, it could be the case that for any packet, if R1 picks the left link, then R11 would also pick the left link; if R1 picks the right link, then R12 also picks the right link. Thus there would be no packet (data or OAM) that would cause packets between R1 and R2 to pass via RB112 or RB121. Even if we ignore that as unlikely, there is still the fact that R1 can't easily tell how many (shortest) paths there might be between it and R2. With single-level TRILL the LSDB could be used to tell, but if we ever go to multi-level that wouldn't be the case any more. And even if R1 knows that there are 4 potential paths, it can't format a data packet (or format the flow entropy in an OAM packet) in such a way that particular paths get chosen by downstream ECMP decisions. Thus for any notion of "all available paths" that make sense to me, we'd need an OAM approach that can explore the topology one hop at a time and at each hop explore all the possible ECMP choices. Using the entropy doesn't help with this (but the entropy is critical for following the path taken by a particular flow of data packets). Hence it would be good to clarify what the assumptions are behind this notion of all available paths. Thanks, Erik _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill --=_alternative 0074C89F882579ED_= Content-Type: text/html; charset="US-ASCII" I agree, the wording needs to be tightened to say "all possible ecmp paths" rather than "all available paths". An operator working out R1-R2 communication is interested in all possible paths data traffic could take rather than all theoretically available paths.



From:        Erik Nordmark <nordmark@acm.org>
To:        trill@ietf.org
Date:        04/27/2012 09:53 AM
Subject:        [trill] TRILL OAM Requirements: available paths
Sent by:        trill-bounces@ietf.org




Two requirements use the wording "all available paths." and "all
available ECMP paths.", respectively and I'm not sure I know what that
means.

Take the following example picture:

               R1
              /  \
             /    \
            /      \
           /        \
          /          \
       RB11          RB12
       /  \          /  \
      /    \        /    \
   RB111  RB112  RB121  RB122
      \      \    /      /
       \      \  /      /
        \      \/      /
         ------R2------

We can see that there are 4 paths with 3 hops to get from R1 to R2, with
two layers of ECMP decisions. But how many available paths are there?

Given that the RBridges make independent ECMP decisions, and how they do
that is a local matter, it could be the case that for any packet, if R1
picks the left link, then R11 would also pick the left link; if R1 picks
the right link, then R12 also picks the right link.
Thus there would be no packet (data or OAM) that would cause packets
between R1 and R2 to pass via RB112 or RB121.

Even if we ignore that as unlikely, there is still the fact that R1
can't easily tell how many (shortest) paths there might be between it
and R2. With single-level TRILL the LSDB could be used to tell, but if
we ever go to multi-level that wouldn't be the case any more.
And even if R1 knows that there are 4 potential paths, it can't format a
data packet (or format the flow entropy in an OAM packet) in such a way
that particular paths get chosen by downstream ECMP decisions.

Thus for any notion of "all available paths" that make sense to me, we'd
need an OAM approach that can explore the topology one hop at a time and
at each hop explore all the possible ECMP choices. Using the entropy
doesn't help with this (but the entropy is critical for following the
path taken by a particular flow of data packets).

Hence it would be good to clarify what the assumptions are behind this
notion of all available paths.

Thanks,
    Erik

_______________________________________________
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill
--=_alternative 0074C89F882579ED_=-- From nordmark@acm.org Fri Apr 27 16:07:10 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A0921F85C3 for ; Fri, 27 Apr 2012 16:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 7AYuZ-zMjB6J for ; Fri, 27 Apr 2012 16:07:10 -0700 (PDT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3D621F85B9 for ; Fri, 27 Apr 2012 16:07:10 -0700 (PDT) Received: from [10.33.22.115] (128-107-239-233.cisco.com [128.107.239.233]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id q3RN73MK031543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2012 16:07:03 -0700 Message-ID: <4F9B2697.8080401@acm.org> Date: Fri, 27 Apr 2012 16:07:03 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: Santosh Rajagopalan References: <4F9ACE0E.7030408@sonic.net> <4F9ACF05.9070302@acm.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: trill@ietf.org Subject: Re: [trill] TRILL OAM Requirements: available paths X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 23:07:10 -0000 On 4/27/12 2:15 PM, Santosh Rajagopalan wrote: > I agree, the wording needs to be tightened to say "all possible ecmp > paths" rather than "all available paths". An operator working out R1-R2 > communication is interested in all possible paths data traffic could > take rather than all theoretically available paths. The issue is that there is nothing in the TRILL dataplane nor IS-IS control plane which helps the operator determine that some paths (through RB121 and RB112 in the example) are not possible; the ECMP input and hashing is a completely local matter on each RBridge. It isn't useful to state a requirement around something that can't be determined. Erik > > > From: Erik Nordmark > To: trill@ietf.org > Date: 04/27/2012 09:53 AM > Subject: [trill] TRILL OAM Requirements: available paths > Sent by: trill-bounces@ietf.org > ------------------------------------------------------------------------ > > > > > Two requirements use the wording "all available paths." and "all > available ECMP paths.", respectively and I'm not sure I know what that > means. > > Take the following example picture: > > R1 > / \ > / \ > / \ > / \ > / \ > RB11 RB12 > / \ / \ > / \ / \ > RB111 RB112 RB121 RB122 > \ \ / / > \ \ / / > \ \/ / > ------R2------ > > We can see that there are 4 paths with 3 hops to get from R1 to R2, with > two layers of ECMP decisions. But how many available paths are there? > > Given that the RBridges make independent ECMP decisions, and how they do > that is a local matter, it could be the case that for any packet, if R1 > picks the left link, then R11 would also pick the left link; if R1 picks > the right link, then R12 also picks the right link. > Thus there would be no packet (data or OAM) that would cause packets > between R1 and R2 to pass via RB112 or RB121. > > Even if we ignore that as unlikely, there is still the fact that R1 > can't easily tell how many (shortest) paths there might be between it > and R2. With single-level TRILL the LSDB could be used to tell, but if > we ever go to multi-level that wouldn't be the case any more. > And even if R1 knows that there are 4 potential paths, it can't format a > data packet (or format the flow entropy in an OAM packet) in such a way > that particular paths get chosen by downstream ECMP decisions. > > Thus for any notion of "all available paths" that make sense to me, we'd > need an OAM approach that can explore the topology one hop at a time and > at each hop explore all the possible ECMP choices. Using the entropy > doesn't help with this (but the entropy is critical for following the > path taken by a particular flow of data packets). > > Hence it would be good to clarify what the assumptions are behind this > notion of all available paths. > > Thanks, > Erik > > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill > > From tsenevir@cisco.com Fri Apr 27 17:12:59 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B063E21E802B for ; Fri, 27 Apr 2012 17:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.294 X-Spam-Level: X-Spam-Status: No, score=-8.294 tagged_above=-999 required=5 tests=[AWL=2.305, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 ThTX10pQugng for ; Fri, 27 Apr 2012 17:12:59 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9EF21E8027 for ; Fri, 27 Apr 2012 17:12:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tsenevir@cisco.com; l=4089; q=dns/txt; s=iport; t=1335571978; x=1336781578; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=iv5rrFaIus1Kp2lrSn2qrqKADDXLv52gOTIm2QMYIXg=; b=hOPu+9goazsxowBg+cGzDrqv1TBKDJPW5zYjr52cWQ2R9l8JqXLQgYbS q3eKPT8LSGiqguO8NvtKwEFZzxpdyD+gYyskHFtflnbJ+DetnBIh3bLIb evGdUxL/zePvwypCJIzqRaRSnQf/mjgXnouYG7/bnG4yYVOTKOVZw9ayj Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFADk1m0+rRDoH/2dsb2JhbABEsguBB4IJAQEBAwEBAQEPAR0KNAsFBwQCAQgRAwEBAQEKBhcBBgEmHwkIAQEEARIIEweHZgQBC5p0n3MEkDpjBIhjm3GBaYMI X-IronPort-AV: E=Sophos;i="4.75,493,1330905600"; d="scan'208";a="39463525" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 28 Apr 2012 00:12:58 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q3S0CwEq012778; Sat, 28 Apr 2012 00:12:58 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Apr 2012 17:12:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Apr 2012 17:12:57 -0700 Message-ID: <344037D7CFEFE84E97E9CC1F56C5F4A5010A2FFF@xmb-sjc-214.amer.cisco.com> In-Reply-To: <4F9B2697.8080401@acm.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [trill] TRILL OAM Requirements: available paths Thread-Index: Ac0kyn36cPlfGBjPQMiCSwyXXKwEEwACBxwQ References: <4F9ACE0E.7030408@sonic.net> <4F9ACF05.9070302@acm.org> <4F9B2697.8080401@acm.org> From: "Tissa Senevirathne (tsenevir)" To: "Erik Nordmark" , "Santosh Rajagopalan" X-OriginalArrivalTime: 28 Apr 2012 00:12:58.0639 (UTC) FILETIME=[AAD4E1F0:01CD24D3] Cc: trill@ietf.org Subject: Re: [trill] TRILL OAM Requirements: available paths X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2012 00:12:59 -0000 Of course it is possible. The IS-IS topology table provide the information on all available ECMP paths to a specific destination when the egress RBRidge nickname is known. That is what TRILL unicast forwarding table all about. Not sure why you are saying it is not possible to know all ECMP paths. What path among available paths to be selected for a specified is a local matter. That is what all about flow entropy discovery. Like I stated earlier how it is discovered is a framework and solution issue. If you need some reference how it is done in the MPLS world RFC 4379 is a good reference. -----Original Message----- From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of Erik Nordmark Sent: Friday, April 27, 2012 4:07 PM To: Santosh Rajagopalan Cc: trill@ietf.org Subject: Re: [trill] TRILL OAM Requirements: available paths On 4/27/12 2:15 PM, Santosh Rajagopalan wrote: > I agree, the wording needs to be tightened to say "all possible ecmp=20 > paths" rather than "all available paths". An operator working out=20 > R1-R2 communication is interested in all possible paths data traffic=20 > could take rather than all theoretically available paths. The issue is that there is nothing in the TRILL dataplane nor IS-IS control plane which helps the operator determine that some paths (through RB121 and RB112 in the example) are not possible; the ECMP input and hashing is a completely local matter on each RBridge. It isn't useful to state a requirement around something that can't be determined. Erik > > > From: Erik Nordmark > To: trill@ietf.org > Date: 04/27/2012 09:53 AM > Subject: [trill] TRILL OAM Requirements: available paths Sent by:=20 > trill-bounces@ietf.org > ---------------------------------------------------------------------- > -- > > > > > Two requirements use the wording "all available paths." and "all=20 > available ECMP paths.", respectively and I'm not sure I know what that > means. > > Take the following example picture: > > R1 > / \ > / \ > / \ > / \ > / \ > RB11 RB12 > / \ / \ > / \ / \ > RB111 RB112 RB121 RB122 > \ \ / / > \ \ / / > \ \/ / > ------R2------ > > We can see that there are 4 paths with 3 hops to get from R1 to R2,=20 > with two layers of ECMP decisions. But how many available paths are there? > > Given that the RBridges make independent ECMP decisions, and how they=20 > do that is a local matter, it could be the case that for any packet,=20 > if R1 picks the left link, then R11 would also pick the left link; if=20 > R1 picks the right link, then R12 also picks the right link. > Thus there would be no packet (data or OAM) that would cause packets=20 > between R1 and R2 to pass via RB112 or RB121. > > Even if we ignore that as unlikely, there is still the fact that R1=20 > can't easily tell how many (shortest) paths there might be between it=20 > and R2. With single-level TRILL the LSDB could be used to tell, but if > we ever go to multi-level that wouldn't be the case any more. > And even if R1 knows that there are 4 potential paths, it can't format > a data packet (or format the flow entropy in an OAM packet) in such a=20 > way that particular paths get chosen by downstream ECMP decisions. > > Thus for any notion of "all available paths" that make sense to me,=20 > we'd need an OAM approach that can explore the topology one hop at a=20 > time and at each hop explore all the possible ECMP choices. Using the=20 > entropy doesn't help with this (but the entropy is critical for=20 > following the path taken by a particular flow of data packets). > > Hence it would be good to clarify what the assumptions are behind this > notion of all available paths. > > Thanks, > Erik > > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill > > _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill From aldrin.ietf@gmail.com Fri Apr 27 20:01:42 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B624121E8019 for ; Fri, 27 Apr 2012 20:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] 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 srFir3169Q4V for ; Fri, 27 Apr 2012 20:01:42 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id E792E11E808E for ; Fri, 27 Apr 2012 20:01:41 -0700 (PDT) Received: by dady13 with SMTP id y13so2284198dad.27 for ; Fri, 27 Apr 2012 20:01:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=zw1wOnqFYaap82iQufgwFT6GjRBPOtcquANTDgYhr3g=; b=gDI5Osla/wV6eqpaw46u+m5bYGepp3WQHdJrrMAWUUxjbE4co9fkaUQE8R2/BOKk23 PwByzwUqZb0P+GZaZmzFZrPxGxz9/F9gHhLiidE9MLexCtnOhcOq8M6MJRPLUAl07CTq k0dMQ4fTqYun6VamY9nqPfaZlqnbjfmmK245tvhs69xFXJZZyB4JG5rbThIqMoLOVwKj bnKExOjo0Le9E3mT9vxv/Rgb2OqMVW7c/nEt60h39oOylSklci9l7kSkBHCsIsSn6NJl Uq/ia5dOiKYByyPdJ1UJLYqe8VJQ0SUQLI8oWtBAmLqCYt3Okr+JXz7UL8VXgrs4W7Gu 46fQ== Received: by 10.68.235.106 with SMTP id ul10mr28078905pbc.144.1335582101708; Fri, 27 Apr 2012 20:01:41 -0700 (PDT) Received: from [10.33.239.44] (mobile-166-205-138-122.mycingular.net. [166.205.138.122]) by mx.google.com with ESMTPS id nm5sm8294508pbc.6.2012.04.27.20.01.40 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 Apr 2012 20:01:40 -0700 (PDT) References: <4F9ACE0E.7030408@sonic.net> <4F9ACF05.9070302@acm.org> <4F9B2697.8080401@acm.org> In-Reply-To: <4F9B2697.8080401@acm.org> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <6841BE58-6C30-482F-ACCC-9C527E47E4E6@gmail.com> X-Mailer: iPhone Mail (9B176) From: Sam Aldrin Date: Fri, 27 Apr 2012 20:01:35 -0700 To: Erik Nordmark Cc: Santosh Rajagopalan , "trill@ietf.org" Subject: Re: [trill] TRILL OAM Requirements: available paths X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2012 03:01:42 -0000 Erik, The forwarding table is setup based on the control plane information, is-is,= for all the ecmp paths. I am not clear when you say that requirement is not= relevant for this. Even if the forwarding is local matter, one should be ab= le test each of those ecmp paths using entropy field for crafting oam packet= s. This is how ecmp in other network types work as well, including trill. If your understanding of the ecmp in trill is different to what I eluded to,= I would like to hear it.=20 Cheers Sam Sent from my iPhone On Apr 27, 2012, at 4:07 PM, Erik Nordmark wrote: > On 4/27/12 2:15 PM, Santosh Rajagopalan wrote: >> I agree, the wording needs to be tightened to say "all possible ecmp >> paths" rather than "all available paths". An operator working out R1-R2 >> communication is interested in all possible paths data traffic could >> take rather than all theoretically available paths. >=20 > The issue is that there is nothing in the TRILL dataplane nor IS-IS contro= l plane which helps the operator determine that some paths (through RB121 an= d RB112 in the example) are not possible; the ECMP input and hashing is a co= mpletely local matter on each RBridge. >=20 > It isn't useful to state a requirement around something that can't be dete= rmined. >=20 > Erik >=20 >>=20 >>=20 >> From: Erik Nordmark >> To: trill@ietf.org >> Date: 04/27/2012 09:53 AM >> Subject: [trill] TRILL OAM Requirements: available paths >> Sent by: trill-bounces@ietf.org >> ------------------------------------------------------------------------ >>=20 >>=20 >>=20 >>=20 >> Two requirements use the wording "all available paths." and "all >> available ECMP paths.", respectively and I'm not sure I know what that >> means. >>=20 >> Take the following example picture: >>=20 >> R1 >> / \ >> / \ >> / \ >> / \ >> / \ >> RB11 RB12 >> / \ / \ >> / \ / \ >> RB111 RB112 RB121 RB122 >> \ \ / / >> \ \ / / >> \ \/ / >> ------R2------ >>=20 >> We can see that there are 4 paths with 3 hops to get from R1 to R2, with >> two layers of ECMP decisions. But how many available paths are there? >>=20 >> Given that the RBridges make independent ECMP decisions, and how they do >> that is a local matter, it could be the case that for any packet, if R1 >> picks the left link, then R11 would also pick the left link; if R1 picks >> the right link, then R12 also picks the right link. >> Thus there would be no packet (data or OAM) that would cause packets >> between R1 and R2 to pass via RB112 or RB121. >>=20 >> Even if we ignore that as unlikely, there is still the fact that R1 >> can't easily tell how many (shortest) paths there might be between it >> and R2. With single-level TRILL the LSDB could be used to tell, but if >> we ever go to multi-level that wouldn't be the case any more. >> And even if R1 knows that there are 4 potential paths, it can't format a >> data packet (or format the flow entropy in an OAM packet) in such a way >> that particular paths get chosen by downstream ECMP decisions. >>=20 >> Thus for any notion of "all available paths" that make sense to me, we'd >> need an OAM approach that can explore the topology one hop at a time and >> at each hop explore all the possible ECMP choices. Using the entropy >> doesn't help with this (but the entropy is critical for following the >> path taken by a particular flow of data packets). >>=20 >> Hence it would be good to clarify what the assumptions are behind this >> notion of all available paths. >>=20 >> Thanks, >> Erik >>=20 >> _______________________________________________ >> trill mailing list >> trill@ietf.org >> https://www.ietf.org/mailman/listinfo/trill >>=20 >>=20 >=20 > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill From nordmark@acm.org Sat Apr 28 20:37:46 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E202921F855F for ; Sat, 28 Apr 2012 20:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 sIvi8TDGa4Te for ; Sat, 28 Apr 2012 20:37:46 -0700 (PDT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfa.amsl.com (Postfix) with ESMTP id 65F2321F8555 for ; Sat, 28 Apr 2012 20:37:46 -0700 (PDT) Received: from [10.21.77.4] (128-107-239-233.cisco.com [128.107.239.233]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id q3T3bhBt008772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Apr 2012 20:37:44 -0700 Message-ID: <4F9CB786.4090603@acm.org> Date: Sat, 28 Apr 2012 20:37:42 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: trill@ietf.org References: <4F9A342F.8050608@acm.org> In-Reply-To: <4F9A342F.8050608@acm.org> X-Forwarded-Message-Id: <4F9A342F.8050608@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [trill] Nits on draft-ietf-trill-rbridge-extension X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 03:37:47 -0000 I have a few nits from reading the document as part of preparing to send it to the IESG. Would it make sense to fix these before we send it in? Section 2 says: If Op-Length is zero there is no header extension present; else, this area follows immediately after the Ingress Rbridge Nickname field of the TRILL Header. That is a bit confusing, since "area" isn't used earlier in the text. Either the prior sentence should say "extensions area", or the above should say "the extensions follows". I think it would be useful to mention that these two are specified in 6325 (but without the 'S' being part of their names): 0-3 Crit.: Critical summary bits. 0 CHbHS: Critical Hop-by-Hop extension(s) are present. 1 CItES: Critical Ingress-to-Egress extension(s) are present. Typo in section 2.3.1: Should be "CHbHS" critical hop-by-hop extensions, MUST drop the frame. If the CHbH And many more lines have missing 'S': CItES: If the CItE (Critical Ingress to Egress Summary) bit is a one, extensions area. If the CItE bit is zero, no such extensions are present. If either CHbH or CItE is non-zero, egress RBridges that If both CHbH and CItE are zero, the frame is safe, from the point Section 2.3.2 seems to just repeat what is in section 2.3. The document seems to use two different names for the 32 bits: "Extension Header Flags" and "Extended Header Flags". I don't know by what name other draft refer to this field. Thanks, Erik From nordmark@acm.org Sat Apr 28 20:45:38 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3859521F855F for ; Sat, 28 Apr 2012 20:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 xoOFBNDCC9X3 for ; Sat, 28 Apr 2012 20:45:37 -0700 (PDT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfa.amsl.com (Postfix) with ESMTP id 53F1C21F84B9 for ; Sat, 28 Apr 2012 20:45:37 -0700 (PDT) Received: from [10.21.77.4] (128-107-239-233.cisco.com [128.107.239.233]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id q3T3jYTb021944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Apr 2012 20:45:34 -0700 Message-ID: <4F9CB95E.4030902@acm.org> Date: Sat, 28 Apr 2012 20:45:34 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: "Tissa Senevirathne (tsenevir)" References: <4F9ACE0E.7030408@sonic.net> <4F9ACF05.9070302@acm.org> <4F9B2697.8080401@acm.org> <344037D7CFEFE84E97E9CC1F56C5F4A5010A2FFF@xmb-sjc-214.amer.cisco.com> In-Reply-To: <344037D7CFEFE84E97E9CC1F56C5F4A5010A2FFF@xmb-sjc-214.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Santosh Rajagopalan , trill@ietf.org Subject: Re: [trill] TRILL OAM Requirements: available paths X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 03:45:38 -0000 On 4/27/12 5:12 PM, Tissa Senevirathne (tsenevir) wrote: > Of course it is possible. The IS-IS topology table provide the > information on all available ECMP paths to a specific destination when > the egress RBRidge nickname is known. That is what TRILL unicast > forwarding table all about. Not sure why you are saying it is not > possible to know all ECMP paths. You are talking about what Santosh called "all theoretically available paths". Those can be determined from IS-IS. But the document talks about "all available paths" and I don't know what that is supposed to mean. Do you have a succinct definition? What is clear to me is that there can be a subset of the paths that are determined from IS-IS that would never be used, because no entropy in a packet would every pick that path. Is the requirement in the document that the OAM solution should be able to test those paths? > What path among available paths to be selected for a specified is a > local matter. That is what all about flow entropy discovery. Like I > stated earlier how it is discovered is a framework and solution issue. Agreed. > If you need some reference how it is done in the MPLS world RFC 4379 is > a good reference. AFAIK MPLS doesn't have a locally defined ECMP hash function in every hop. TRILL does, which makes these aspects different. Regards, Erik > -----Original Message----- > From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf > Of Erik Nordmark > Sent: Friday, April 27, 2012 4:07 PM > To: Santosh Rajagopalan > Cc: trill@ietf.org > Subject: Re: [trill] TRILL OAM Requirements: available paths > > On 4/27/12 2:15 PM, Santosh Rajagopalan wrote: >> I agree, the wording needs to be tightened to say "all possible ecmp >> paths" rather than "all available paths". An operator working out >> R1-R2 communication is interested in all possible paths data traffic >> could take rather than all theoretically available paths. > > The issue is that there is nothing in the TRILL dataplane nor IS-IS > control plane which helps the operator determine that some paths > (through RB121 and RB112 in the example) are not possible; the ECMP > input and hashing is a completely local matter on each RBridge. > > It isn't useful to state a requirement around something that can't be > determined. > > Erik > >> >> >> From: Erik Nordmark >> To: trill@ietf.org >> Date: 04/27/2012 09:53 AM >> Subject: [trill] TRILL OAM Requirements: available paths Sent by: >> trill-bounces@ietf.org >> ---------------------------------------------------------------------- >> -- >> >> >> >> >> Two requirements use the wording "all available paths." and "all >> available ECMP paths.", respectively and I'm not sure I know what that > >> means. >> >> Take the following example picture: >> >> R1 >> / \ >> / \ >> / \ >> / \ >> / \ >> RB11 RB12 >> / \ / \ >> / \ / \ >> RB111 RB112 RB121 RB122 >> \ \ / / >> \ \ / / >> \ \/ / >> ------R2------ >> >> We can see that there are 4 paths with 3 hops to get from R1 to R2, >> with two layers of ECMP decisions. But how many available paths are > there? >> >> Given that the RBridges make independent ECMP decisions, and how they >> do that is a local matter, it could be the case that for any packet, >> if R1 picks the left link, then R11 would also pick the left link; if >> R1 picks the right link, then R12 also picks the right link. >> Thus there would be no packet (data or OAM) that would cause packets >> between R1 and R2 to pass via RB112 or RB121. >> >> Even if we ignore that as unlikely, there is still the fact that R1 >> can't easily tell how many (shortest) paths there might be between it >> and R2. With single-level TRILL the LSDB could be used to tell, but if > >> we ever go to multi-level that wouldn't be the case any more. >> And even if R1 knows that there are 4 potential paths, it can't format > >> a data packet (or format the flow entropy in an OAM packet) in such a >> way that particular paths get chosen by downstream ECMP decisions. >> >> Thus for any notion of "all available paths" that make sense to me, >> we'd need an OAM approach that can explore the topology one hop at a >> time and at each hop explore all the possible ECMP choices. Using the >> entropy doesn't help with this (but the entropy is critical for >> following the path taken by a particular flow of data packets). >> >> Hence it would be good to clarify what the assumptions are behind this > >> notion of all available paths. >> >> Thanks, >> Erik >> >> _______________________________________________ >> trill mailing list >> trill@ietf.org >> https://www.ietf.org/mailman/listinfo/trill >> >> > > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill > From nordmark@acm.org Sat Apr 28 20:48:37 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54E1821F859A for ; Sat, 28 Apr 2012 20:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 9a2hd4hJZ-tP for ; Sat, 28 Apr 2012 20:48:36 -0700 (PDT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFC121F856F for ; Sat, 28 Apr 2012 20:48:36 -0700 (PDT) Received: from [10.21.77.4] (128-107-239-233.cisco.com [128.107.239.233]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id q3T3mXeB019351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Apr 2012 20:48:34 -0700 Message-ID: <4F9CBA11.2080002@acm.org> Date: Sat, 28 Apr 2012 20:48:33 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: trill@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [trill] draft-hu-trill-rbridge-esadi accepted as TRILL WG draft X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 03:48:37 -0000 Based on the comments on the mailing list this document is accepted as a WG draft. There has been several suggestions that the ESADI draft should include the complete specification of ESADI, thus I suggest the authors do that for the next version. Regards, Erik On 4/12/12 8:13 PM, Donald Eastlake wrote: > This message begins a two week comment period for TRILL WG assent to > make draft-hu-trill-rbridge-esadi-04.txt a TRILL WG draft. > > Thanks, > Donald [Co-Chair) > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill > From tsenevir@cisco.com Sat Apr 28 21:43:06 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BECD21F8575 for ; Sat, 28 Apr 2012 21:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.486 X-Spam-Level: X-Spam-Status: No, score=-8.486 tagged_above=-999 required=5 tests=[AWL=2.113, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 skMtXNlEomNj for ; Sat, 28 Apr 2012 21:43:02 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 228D521F8573 for ; Sat, 28 Apr 2012 21:43:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tsenevir@cisco.com; l=5805; q=dns/txt; s=iport; t=1335674582; x=1336884182; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=61IbDGm6OJHjiobiJ284g5IwJaPLhHlVSYcMhovYWxA=; b=aPO6htOeB9S56uePBmd6ufv9ZJpIsEmJWBBrRMBs9NdkUTBiDuzejE5C JNYRhjuM/GKjUbjxJClCBlVaWb1zZQnf4yhybZPiMf0rx3QZvW/kUV1Nk iXY4mdwYzmJx6I1YkjBbrPhdtFCbgcy5RUfPdu5fY46IxwiMg+UhXr4LT E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAIvFnE+rRDoJ/2dsb2JhbABEshaBB4IJAQEBAwEBAQEPAR0KNAsFBwQCAQgRAwEBAQEKBhcBBgEmHwkIAQEEEwgTB4dmBAELmSqfJwSQP2MEiGSbc4Fpgwg X-IronPort-AV: E=Sophos;i="4.75,498,1330905600"; d="scan'208";a="42581299" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 29 Apr 2012 04:43:01 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3T4h1RX003520; Sun, 29 Apr 2012 04:43:01 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 28 Apr 2012 21:43:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 28 Apr 2012 21:43:00 -0700 Message-ID: <344037D7CFEFE84E97E9CC1F56C5F4A5010A3071@xmb-sjc-214.amer.cisco.com> In-Reply-To: <4F9CB95E.4030902@acm.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [trill] TRILL OAM Requirements: available paths Thread-Index: Ac0luop+nnwlp6llSiaL98MMp8ycRwABz/mw References: <4F9ACE0E.7030408@sonic.net> <4F9ACF05.9070302@acm.org> <4F9B2697.8080401@acm.org> <344037D7CFEFE84E97E9CC1F56C5F4A5010A2FFF@xmb-sjc-214.amer.cisco.com> <4F9CB95E.4030902@acm.org> From: "Tissa Senevirathne (tsenevir)" To: "Erik Nordmark" X-OriginalArrivalTime: 29 Apr 2012 04:43:01.0575 (UTC) FILETIME=[8EF27570:01CD25C2] Cc: trill@ietf.org Subject: Re: [trill] TRILL OAM Requirements: available paths X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 04:43:06 -0000 No, I am talking about all equal cost paths. As IS-IS run through path calculations it only maintain best cost paths. You cannot by default obtain all theoretical paths. Whether entrophy covers a subset or all equal cost paths is a implementation/solution issue. That is the reason requirements are in place to include real payloads. I am not sure whether I am getting the explanation correctly. May be I should call you or you can dial in to the design team meeting and I can explain. -----Original Message----- From: Erik Nordmark [mailto:nordmark@acm.org]=20 Sent: Saturday, April 28, 2012 8:46 PM To: Tissa Senevirathne (tsenevir) Cc: Santosh Rajagopalan; trill@ietf.org Subject: Re: [trill] TRILL OAM Requirements: available paths On 4/27/12 5:12 PM, Tissa Senevirathne (tsenevir) wrote: > Of course it is possible. The IS-IS topology table provide the=20 > information on all available ECMP paths to a specific destination when > the egress RBRidge nickname is known. That is what TRILL unicast=20 > forwarding table all about. Not sure why you are saying it is not=20 > possible to know all ECMP paths. You are talking about what Santosh called "all theoretically available paths". Those can be determined from IS-IS. But the document talks about "all available paths" and I don't know what that is supposed to mean. Do you have a succinct definition? What is clear to me is that there can be a subset of the paths that are determined from IS-IS that would never be used, because no entropy in a packet would every pick that path. Is the requirement in the document that the OAM solution should be able to test those paths? > What path among available paths to be selected for a specified is a=20 > local matter. That is what all about flow entropy discovery. Like I=20 > stated earlier how it is discovered is a framework and solution issue. Agreed. > If you need some reference how it is done in the MPLS world RFC 4379=20 > is a good reference. AFAIK MPLS doesn't have a locally defined ECMP hash function in every hop. TRILL does, which makes these aspects different. Regards, Erik > -----Original Message----- > From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf > Of Erik Nordmark > Sent: Friday, April 27, 2012 4:07 PM > To: Santosh Rajagopalan > Cc: trill@ietf.org > Subject: Re: [trill] TRILL OAM Requirements: available paths > > On 4/27/12 2:15 PM, Santosh Rajagopalan wrote: >> I agree, the wording needs to be tightened to say "all possible ecmp=20 >> paths" rather than "all available paths". An operator working out >> R1-R2 communication is interested in all possible paths data traffic=20 >> could take rather than all theoretically available paths. > > The issue is that there is nothing in the TRILL dataplane nor IS-IS=20 > control plane which helps the operator determine that some paths=20 > (through RB121 and RB112 in the example) are not possible; the ECMP=20 > input and hashing is a completely local matter on each RBridge. > > It isn't useful to state a requirement around something that can't be=20 > determined. > > Erik > >> >> >> From: Erik Nordmark >> To: trill@ietf.org >> Date: 04/27/2012 09:53 AM >> Subject: [trill] TRILL OAM Requirements: available paths Sent by: >> trill-bounces@ietf.org >> --------------------------------------------------------------------- >> - >> -- >> >> >> >> >> Two requirements use the wording "all available paths." and "all=20 >> available ECMP paths.", respectively and I'm not sure I know what=20 >> that > >> means. >> >> Take the following example picture: >> >> R1 >> / \ >> / \ >> / \ >> / \ >> / \ >> RB11 RB12 >> / \ / \ >> / \ / \ >> RB111 RB112 RB121 RB122 >> \ \ / / >> \ \ / / >> \ \/ / >> ------R2------ >> >> We can see that there are 4 paths with 3 hops to get from R1 to R2,=20 >> with two layers of ECMP decisions. But how many available paths are > there? >> >> Given that the RBridges make independent ECMP decisions, and how they >> do that is a local matter, it could be the case that for any packet,=20 >> if R1 picks the left link, then R11 would also pick the left link; if >> R1 picks the right link, then R12 also picks the right link. >> Thus there would be no packet (data or OAM) that would cause packets=20 >> between R1 and R2 to pass via RB112 or RB121. >> >> Even if we ignore that as unlikely, there is still the fact that R1=20 >> can't easily tell how many (shortest) paths there might be between it >> and R2. With single-level TRILL the LSDB could be used to tell, but=20 >> if > >> we ever go to multi-level that wouldn't be the case any more. >> And even if R1 knows that there are 4 potential paths, it can't=20 >> format > >> a data packet (or format the flow entropy in an OAM packet) in such a >> way that particular paths get chosen by downstream ECMP decisions. >> >> Thus for any notion of "all available paths" that make sense to me,=20 >> we'd need an OAM approach that can explore the topology one hop at a=20 >> time and at each hop explore all the possible ECMP choices. Using the >> entropy doesn't help with this (but the entropy is critical for=20 >> following the path taken by a particular flow of data packets). >> >> Hence it would be good to clarify what the assumptions are behind=20 >> this > >> notion of all available paths. >> >> Thanks, >> Erik >> >> _______________________________________________ >> trill mailing list >> trill@ietf.org >> https://www.ietf.org/mailman/listinfo/trill >> >> > > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill > From aldrin.ietf@gmail.com Sat Apr 28 21:54:22 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAC221F8548 for ; Sat, 28 Apr 2012 21:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.302 X-Spam-Level: X-Spam-Status: No, score=-3.302 tagged_above=-999 required=5 tests=[AWL=-1.099, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] 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 ltN7peZhES7t for ; Sat, 28 Apr 2012 21:54:21 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 6957621F848A for ; Sat, 28 Apr 2012 21:54:21 -0700 (PDT) Received: by dady13 with SMTP id y13so3582671dad.27 for ; Sat, 28 Apr 2012 21:54:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=6/boxZAvw9ykkSvgaPSHzRSVh4aHTV/26NKU2BLNIV0=; b=yiUk6PCeMszFjpdfOr6PY7KQboQz0CZ3pKs6W9KAYNQlsHpTykeKPSHWAbcVnKDG5Q y/WDUbDRk2pwrOlrSH+qbRAGu9PyPBQrPE2VpYKvCD0oGsfk3PXGRT/DXLdh9JHvwnMP sgIMKjxDhiBsQCxlehtOA5AwYyHaLnXLwwI/uwvQFybl3+onjAp74hU2xesXYsSp2FrR YAuPrP+3jc+AM7vv/V4r2lnudntjWx6QIr4eF/8V4oIrETdoXXfMU3/VxZp4VjdJX0+7 fLkxd31PiS/cHaF2Jgz349N92hKLrtrR7SctOmlT6hDKMnGUCjCYfTbYcw1pqnapHzkD mf9w== Received: by 10.68.194.40 with SMTP id ht8mr2930007pbc.69.1335675261143; Sat, 28 Apr 2012 21:54:21 -0700 (PDT) Received: from [192.168.1.5] (c-107-3-156-34.hsd1.ca.comcast.net. [107.3.156.34]) by mx.google.com with ESMTPS id wo8sm11731011pbc.0.2012.04.28.21.54.19 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 28 Apr 2012 21:54:20 -0700 (PDT) References: <4F9ACE0E.7030408@sonic.net> <4F9ACF05.9070302@acm.org> <4F9B2697.8080401@acm.org> <344037D7CFEFE84E97E9CC1F56C5F4A5010A2FFF@xmb-sjc-214.amer.cisco.com> <4F9CB95E.4030902@acm.org> In-Reply-To: <4F9CB95E.4030902@acm.org> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <20718496-0FAA-4683-A83E-B97563E01BB6@gmail.com> X-Mailer: iPad Mail (9B176) From: Sam Aldrin Date: Sat, 28 Apr 2012 21:54:18 -0700 To: Erik Nordmark Cc: "Tissa Senevirathne \(tsenevir\)" , Santosh Rajagopalan , "trill@ietf.org" Subject: Re: [trill] TRILL OAM Requirements: available paths X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 04:54:22 -0000 Erik, Every hop in mpls does hashing based on label stack and other header details= . I do not see any difference between TRILL and mpls in this case.=20 The requirement is to specify the ability to test each of those ecmp paths a= vailable. Doesn't matter if the active traffic is taking that path or not. T= his is part of pro-active monitoring. Cheers Sam Sent from my iPad On Apr 28, 2012, at 8:45 PM, Erik Nordmark wrote: > On 4/27/12 5:12 PM, Tissa Senevirathne (tsenevir) wrote: >> Of course it is possible. The IS-IS topology table provide the >> information on all available ECMP paths to a specific destination when >> the egress RBRidge nickname is known. That is what TRILL unicast >> forwarding table all about. Not sure why you are saying it is not >> possible to know all ECMP paths. >=20 > You are talking about what Santosh called "all theoretically available pat= hs". Those can be determined from IS-IS. >=20 > But the document talks about "all available paths" and I don't know what t= hat is supposed to mean. Do you have a succinct definition? >=20 > What is clear to me is that there can be a subset of the paths that are de= termined from IS-IS that would never be used, because no entropy in a packet= would every pick that path. >=20 > Is the requirement in the document that the OAM solution should be able to= test those paths? >=20 >> What path among available paths to be selected for a specified is a >> local matter. That is what all about flow entropy discovery. Like I >> stated earlier how it is discovered is a framework and solution issue. >=20 > Agreed. >=20 >> If you need some reference how it is done in the MPLS world RFC 4379 is >> a good reference. >=20 > AFAIK MPLS doesn't have a locally defined ECMP hash function in every hop.= TRILL does, which makes these aspects different. >=20 > Regards, > Erik >=20 >> -----Original Message----- >> From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf >> Of Erik Nordmark >> Sent: Friday, April 27, 2012 4:07 PM >> To: Santosh Rajagopalan >> Cc: trill@ietf.org >> Subject: Re: [trill] TRILL OAM Requirements: available paths >>=20 >> On 4/27/12 2:15 PM, Santosh Rajagopalan wrote: >>> I agree, the wording needs to be tightened to say "all possible ecmp >>> paths" rather than "all available paths". An operator working out >>> R1-R2 communication is interested in all possible paths data traffic >>> could take rather than all theoretically available paths. >>=20 >> The issue is that there is nothing in the TRILL dataplane nor IS-IS >> control plane which helps the operator determine that some paths >> (through RB121 and RB112 in the example) are not possible; the ECMP >> input and hashing is a completely local matter on each RBridge. >>=20 >> It isn't useful to state a requirement around something that can't be >> determined. >>=20 >> Erik >>=20 >>>=20 >>>=20 >>> From: Erik Nordmark >>> To: trill@ietf.org >>> Date: 04/27/2012 09:53 AM >>> Subject: [trill] TRILL OAM Requirements: available paths Sent by: >>> trill-bounces@ietf.org >>> ---------------------------------------------------------------------- >>> -- >>>=20 >>>=20 >>>=20 >>>=20 >>> Two requirements use the wording "all available paths." and "all >>> available ECMP paths.", respectively and I'm not sure I know what that >>=20 >>> means. >>>=20 >>> Take the following example picture: >>>=20 >>> R1 >>> / \ >>> / \ >>> / \ >>> / \ >>> / \ >>> RB11 RB12 >>> / \ / \ >>> / \ / \ >>> RB111 RB112 RB121 RB122 >>> \ \ / / >>> \ \ / / >>> \ \/ / >>> ------R2------ >>>=20 >>> We can see that there are 4 paths with 3 hops to get from R1 to R2, >>> with two layers of ECMP decisions. But how many available paths are >> there? >>>=20 >>> Given that the RBridges make independent ECMP decisions, and how they >>> do that is a local matter, it could be the case that for any packet, >>> if R1 picks the left link, then R11 would also pick the left link; if >>> R1 picks the right link, then R12 also picks the right link. >>> Thus there would be no packet (data or OAM) that would cause packets >>> between R1 and R2 to pass via RB112 or RB121. >>>=20 >>> Even if we ignore that as unlikely, there is still the fact that R1 >>> can't easily tell how many (shortest) paths there might be between it >>> and R2. With single-level TRILL the LSDB could be used to tell, but if >>=20 >>> we ever go to multi-level that wouldn't be the case any more. >>> And even if R1 knows that there are 4 potential paths, it can't format >>=20 >>> a data packet (or format the flow entropy in an OAM packet) in such a >>> way that particular paths get chosen by downstream ECMP decisions. >>>=20 >>> Thus for any notion of "all available paths" that make sense to me, >>> we'd need an OAM approach that can explore the topology one hop at a >>> time and at each hop explore all the possible ECMP choices. Using the >>> entropy doesn't help with this (but the entropy is critical for >>> following the path taken by a particular flow of data packets). >>>=20 >>> Hence it would be good to clarify what the assumptions are behind this >>=20 >>> notion of all available paths. >>>=20 >>> Thanks, >>> Erik >>>=20 >>> _______________________________________________ >>> trill mailing list >>> trill@ietf.org >>> https://www.ietf.org/mailman/listinfo/trill >>>=20 >>>=20 >>=20 >> _______________________________________________ >> trill mailing list >> trill@ietf.org >> https://www.ietf.org/mailman/listinfo/trill >>=20 >=20 > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill From d3e3e3@gmail.com Sun Apr 29 03:22:45 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8F521F854E for ; Sun, 29 Apr 2012 03:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.747 X-Spam-Level: X-Spam-Status: No, score=-103.747 tagged_above=-999 required=5 tests=[AWL=-0.148, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 go0LcSWxYu6x for ; Sun, 29 Apr 2012 03:22:45 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id EB3E121F8528 for ; Sun, 29 Apr 2012 03:22:44 -0700 (PDT) Received: by iazz13 with SMTP id z13so3627673iaz.31 for ; Sun, 29 Apr 2012 03:22:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=3lHJUM2XEPeQXQi2syW3GzVphIpY2trpfXho4wG57+0=; b=RwCPBrvT2egsvZc4x2I12fR2Dsi3Jyb3UHM8SzVRkYu7qvUEPq0ZsAIGKdUPxGVKQ0 qenMyQLS9yIbB9Ggl3kwMuBfbGkzg71kwMoUrSidgfl9kTUPmNt5XwWa9jK0KHo4i494 tyitlbCQA+v54dgq3ICs0Ri9t6+Svtku76ehu8tftEJzLIcISyRGVxZdOQ6Wdd/tzdjX 9xx8ESUTi4wkFonDvBDz5zCmGNTBLq8jxCbudZZQ5p0nP0pI3WUiHcmJzfr+tsnW37Rs jv6ccjE+K6zT0CtM22bakrSPOqWKU6k9+vyQs3Zd25g92t0YJ+ZQ7YcWj7yCcJJgKt7O iRLw== Received: by 10.50.89.168 with SMTP id bp8mr7571600igb.3.1335694964402; Sun, 29 Apr 2012 03:22:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.59.201 with HTTP; Sun, 29 Apr 2012 03:22:24 -0700 (PDT) In-Reply-To: <4F9CB786.4090603@acm.org> References: <4F9A342F.8050608@acm.org> <4F9CB786.4090603@acm.org> From: Donald Eastlake Date: Sun, 29 Apr 2012 06:22:24 -0400 Message-ID: To: Erik Nordmark Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: trill@ietf.org Subject: Re: [trill] Nits on draft-ietf-trill-rbridge-extension X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 10:22:45 -0000 Hi, I think these are all editorial changes so I'll just make then and post a new version. See below On Sat, Apr 28, 2012 at 11:37 PM, Erik Nordmark wrote: > I have a few nits from reading the document as part of preparing to send = it > to the IESG. > Would it make sense to fix these before we send it in? > > > Section 2 says: > =A0 If Op-Length is zero there is no header extension present; > =A0 else, this area follows immediately after the Ingress Rbridge > =A0 Nickname field of the TRILL Header. > > That is a bit confusing, since "area" isn't used earlier in the text. > Either the prior sentence should say "extensions area", or the above > should say "the extensions follows". OK. > I think it would be useful to mention that these two are specified in > 6325 (but without the 'S' being part of their names): > =A0 =A00-3 =A0Crit.: Critical summary bits. > =A0 =A0 =A0 =A0 0 CHbHS: Critical Hop-by-Hop extension(s) are present. > =A0 =A0 =A0 =A0 1 CItES: Critical Ingress-to-Egress extension(s) are pres= ent. OK. > Typo in section 2.3.1: Should be "CHbHS" > =A0 =A0 =A0critical hop-by-hop extensions, MUST drop the frame. If the CH= bH OK. > And many more lines have missing 'S': > =A0 CItES: If the CItE (Critical Ingress to Egress Summary) bit is a one, > =A0 =A0 =A0extensions area. =A0If the CItE bit is zero, no such extension= s are > =A0 =A0 =A0present. =A0If either CHbH or CItE is non-zero, egress RBridge= s that > =A0 =A0 =A0If both CHbH and CItE are zero, the frame is safe, from the po= int OK. > Section 2.3.2 seems to just repeat what is in section 2.3. I agree. 2.3.2 is completely redundant and should be deleted. > The document seems to use two different names for the 32 bits: > "Extension Header Flags" and "Extended Header Flags". I don't know by > what name other draft refer to this field. I believe that "Extended Header Flags" is best and "Extended" should be preferred. But when referring to the 32-bit word of flags, it is reasonable to call it an "extension", so not all occurrences of "extension" are necssarily an error. Most references to this draft are from the Channel draft which uses "extended". Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com > Thanks, > =A0 Erik From nordmark@acm.org Sun Apr 29 17:36:38 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCF621F85E7 for ; Sun, 29 Apr 2012 17:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 cfnFVAC+k6cY for ; Sun, 29 Apr 2012 17:36:37 -0700 (PDT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE7D21F85AC for ; Sun, 29 Apr 2012 17:36:37 -0700 (PDT) Received: from [10.21.72.123] (128-107-239-233.cisco.com [128.107.239.233]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id q3U0aWUu021187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Apr 2012 17:36:32 -0700 Message-ID: <4F9DDE90.5080604@acm.org> Date: Sun, 29 Apr 2012 17:36:32 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: Sam Aldrin References: <4F9ACE0E.7030408@sonic.net> <4F9ACF05.9070302@acm.org> <4F9B2697.8080401@acm.org> <344037D7CFEFE84E97E9CC1F56C5F4A5010A2FFF@xmb-sjc-214.amer.cisco.com> <4F9CB95E.4030902@acm.org> <20718496-0FAA-4683-A83E-B97563E01BB6@gmail.com> In-Reply-To: <20718496-0FAA-4683-A83E-B97563E01BB6@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Tissa Senevirathne \(tsenevir\)" , Santosh Rajagopalan , "trill@ietf.org" Subject: Re: [trill] TRILL OAM Requirements: available paths X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 00:36:38 -0000 On 4/28/12 9:54 PM, Sam Aldrin wrote: > Erik, > > Every hop in mpls does hashing based on label stack and other header details. I do not see any difference between TRILL and mpls in this case. That's not consistent with what I heard from others when I discussed MPLS OAM. But that isn't the main point. > The requirement is to specify the ability to test each of those ecmp paths available. Doesn't matter if the active traffic is taking that path or not. This is part of pro-active monitoring. OK. Then please make that clear in the requirements document. For instance, that can be done by including a careful definition of "available ecmp paths" in the document. FWIW I don't think any of the solutions that have been discussed so far are capable of testing all the available paths; that just means there is some more work needed on solutions. Erik > Cheers > Sam > > > Sent from my iPad > > On Apr 28, 2012, at 8:45 PM, Erik Nordmark wrote: > >> On 4/27/12 5:12 PM, Tissa Senevirathne (tsenevir) wrote: >>> Of course it is possible. The IS-IS topology table provide the >>> information on all available ECMP paths to a specific destination when >>> the egress RBRidge nickname is known. That is what TRILL unicast >>> forwarding table all about. Not sure why you are saying it is not >>> possible to know all ECMP paths. >> >> You are talking about what Santosh called "all theoretically available paths". Those can be determined from IS-IS. >> >> But the document talks about "all available paths" and I don't know what that is supposed to mean. Do you have a succinct definition? >> >> What is clear to me is that there can be a subset of the paths that are determined from IS-IS that would never be used, because no entropy in a packet would every pick that path. >> >> Is the requirement in the document that the OAM solution should be able to test those paths? >> >>> What path among available paths to be selected for a specified is a >>> local matter. That is what all about flow entropy discovery. Like I >>> stated earlier how it is discovered is a framework and solution issue. >> >> Agreed. >> >>> If you need some reference how it is done in the MPLS world RFC 4379 is >>> a good reference. >> >> AFAIK MPLS doesn't have a locally defined ECMP hash function in every hop. TRILL does, which makes these aspects different. >> >> Regards, >> Erik >> >>> -----Original Message----- >>> From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf >>> Of Erik Nordmark >>> Sent: Friday, April 27, 2012 4:07 PM >>> To: Santosh Rajagopalan >>> Cc: trill@ietf.org >>> Subject: Re: [trill] TRILL OAM Requirements: available paths >>> >>> On 4/27/12 2:15 PM, Santosh Rajagopalan wrote: >>>> I agree, the wording needs to be tightened to say "all possible ecmp >>>> paths" rather than "all available paths". An operator working out >>>> R1-R2 communication is interested in all possible paths data traffic >>>> could take rather than all theoretically available paths. >>> >>> The issue is that there is nothing in the TRILL dataplane nor IS-IS >>> control plane which helps the operator determine that some paths >>> (through RB121 and RB112 in the example) are not possible; the ECMP >>> input and hashing is a completely local matter on each RBridge. >>> >>> It isn't useful to state a requirement around something that can't be >>> determined. >>> >>> Erik >>> >>>> >>>> >>>> From: Erik Nordmark >>>> To: trill@ietf.org >>>> Date: 04/27/2012 09:53 AM >>>> Subject: [trill] TRILL OAM Requirements: available paths Sent by: >>>> trill-bounces@ietf.org >>>> ---------------------------------------------------------------------- >>>> -- >>>> >>>> >>>> >>>> >>>> Two requirements use the wording "all available paths." and "all >>>> available ECMP paths.", respectively and I'm not sure I know what that >>> >>>> means. >>>> >>>> Take the following example picture: >>>> >>>> R1 >>>> / \ >>>> / \ >>>> / \ >>>> / \ >>>> / \ >>>> RB11 RB12 >>>> / \ / \ >>>> / \ / \ >>>> RB111 RB112 RB121 RB122 >>>> \ \ / / >>>> \ \ / / >>>> \ \/ / >>>> ------R2------ >>>> >>>> We can see that there are 4 paths with 3 hops to get from R1 to R2, >>>> with two layers of ECMP decisions. But how many available paths are >>> there? >>>> >>>> Given that the RBridges make independent ECMP decisions, and how they >>>> do that is a local matter, it could be the case that for any packet, >>>> if R1 picks the left link, then R11 would also pick the left link; if >>>> R1 picks the right link, then R12 also picks the right link. >>>> Thus there would be no packet (data or OAM) that would cause packets >>>> between R1 and R2 to pass via RB112 or RB121. >>>> >>>> Even if we ignore that as unlikely, there is still the fact that R1 >>>> can't easily tell how many (shortest) paths there might be between it >>>> and R2. With single-level TRILL the LSDB could be used to tell, but if >>> >>>> we ever go to multi-level that wouldn't be the case any more. >>>> And even if R1 knows that there are 4 potential paths, it can't format >>> >>>> a data packet (or format the flow entropy in an OAM packet) in such a >>>> way that particular paths get chosen by downstream ECMP decisions. >>>> >>>> Thus for any notion of "all available paths" that make sense to me, >>>> we'd need an OAM approach that can explore the topology one hop at a >>>> time and at each hop explore all the possible ECMP choices. Using the >>>> entropy doesn't help with this (but the entropy is critical for >>>> following the path taken by a particular flow of data packets). >>>> >>>> Hence it would be good to clarify what the assumptions are behind this >>> >>>> notion of all available paths. >>>> >>>> Thanks, >>>> Erik >>>> >>>> _______________________________________________ >>>> trill mailing list >>>> trill@ietf.org >>>> https://www.ietf.org/mailman/listinfo/trill >>>> >>>> >>> >>> _______________________________________________ >>> trill mailing list >>> trill@ietf.org >>> https://www.ietf.org/mailman/listinfo/trill >>> >> >> _______________________________________________ >> trill mailing list >> trill@ietf.org >> https://www.ietf.org/mailman/listinfo/trill > From aldrin.ietf@gmail.com Sun Apr 29 17:44:10 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE73E21F85D5 for ; Sun, 29 Apr 2012 17:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] 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 gd9hovzzdE4j for ; Sun, 29 Apr 2012 17:44:09 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC7B21F85AC for ; Sun, 29 Apr 2012 17:44:09 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so3045356pbb.31 for ; Sun, 29 Apr 2012 17:44:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=7eJoqYQa/QvqRDs0/G8zhRSzlRaF2YNbb/rNaXYfbvM=; b=BhQfavWFpme94PW046QadOFdI/vDHT57LI2tnASssAZxkFTuGsyZx3OIO8GM+RT00H g+HNNEJMjJMkoqBO3E0R5KgdKwMRgkh8ru/A1d5R9SGxScc/vklwrebQUdNiCzOpC3ub o1bUt1ZC15MGD1VHR+04Fq7KunnPWi1SEGAaW/Pio1yj8d3MWIGWl9slEiCjBQU7Wyht RKeuBuGV7/lYIDqLc2K91pyJZoQzy3F4hq8ynATHqC2d4/GbM/Ju0/o6x0ZT0CHoDnKy aM8kZkKO4TJFnfPEzK0OKr5nJNYsm42Rq3LwLyU4WPjnaCHZ4pHYd3QY3qG5hiGtLI87 Yc2w== Received: by 10.68.218.72 with SMTP id pe8mr43808157pbc.45.1335746649051; Sun, 29 Apr 2012 17:44:09 -0700 (PDT) Received: from [10.33.239.44] (mobile-166-205-138-122.mycingular.net. [166.205.138.122]) by mx.google.com with ESMTPS id qo5sm4771051pbc.2.2012.04.29.17.44.06 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 29 Apr 2012 17:44:07 -0700 (PDT) References: <4F9ACE0E.7030408@sonic.net> <4F9ACF05.9070302@acm.org> <4F9B2697.8080401@acm.org> <344037D7CFEFE84E97E9CC1F56C5F4A5010A2FFF@xmb-sjc-214.amer.cisco.com> <4F9CB95E.4030902@acm.org> <20718496-0FAA-4683-A83E-B97563E01BB6@gmail.com> <4F9DDE90.5080604@acm.org> In-Reply-To: <4F9DDE90.5080604@acm.org> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9B176) From: Sam Aldrin Date: Sun, 29 Apr 2012 17:44:01 -0700 To: Erik Nordmark Cc: "Tissa Senevirathne \(tsenevir\)" , Santosh Rajagopalan , "trill@ietf.org" Subject: Re: [trill] TRILL OAM Requirements: available paths X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 00:44:10 -0000 Sent from my iPhone On Apr 29, 2012, at 5:36 PM, Erik Nordmark wrote: > On 4/28/12 9:54 PM, Sam Aldrin wrote: >> Erik, >>=20 >> Every hop in mpls does hashing based on label stack and other header deta= ils. I do not see any difference between TRILL and mpls in this case. >=20 > That's not consistent with what I heard from others when I discussed MPLS O= AM. But that isn't the main point. >=20 >> The requirement is to specify the ability to test each of those ecmp pat= hs available. Doesn't matter if the active traffic is taking that path or no= t. This is part of pro-active monitoring. >=20 > OK. Then please make that clear in the requirements document. For instance= , that can be done by including a careful definition of "available ecmp path= s" in the document. >=20 > FWIW I don't think any of the solutions that have been discussed so far ar= e capable of testing all the available paths; that just means there is some m= ore work needed on solutions. >=20 > Erik >=20 >> Cheers >> Sam >>=20 >>=20 >> Sent from my iPad >>=20 >> On Apr 28, 2012, at 8:45 PM, Erik Nordmark wrote: >>=20 >>> On 4/27/12 5:12 PM, Tissa Senevirathne (tsenevir) wrote: >>>> Of course it is possible. The IS-IS topology table provide the >>>> information on all available ECMP paths to a specific destination when >>>> the egress RBRidge nickname is known. That is what TRILL unicast >>>> forwarding table all about. Not sure why you are saying it is not >>>> possible to know all ECMP paths. >>>=20 >>> You are talking about what Santosh called "all theoretically available p= aths". Those can be determined from IS-IS. >>>=20 >>> But the document talks about "all available paths" and I don't know what= that is supposed to mean. Do you have a succinct definition? >>>=20 >>> What is clear to me is that there can be a subset of the paths that are d= etermined from IS-IS that would never be used, because no entropy in a packe= t would every pick that path. >>>=20 >>> Is the requirement in the document that the OAM solution should be able t= o test those paths? >>>=20 >>>> What path among available paths to be selected for a specified is a >>>> local matter. That is what all about flow entropy discovery. Like I >>>> stated earlier how it is discovered is a framework and solution issue. >>>=20 >>> Agreed. >>>=20 >>>> If you need some reference how it is done in the MPLS world RFC 4379 is= >>>> a good reference. >>>=20 >>> AFAIK MPLS doesn't have a locally defined ECMP hash function in every ho= p. TRILL does, which makes these aspects different. >>>=20 >>> Regards, >>> Erik >>>=20 >>>> -----Original Message----- >>>> From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf >>>> Of Erik Nordmark >>>> Sent: Friday, April 27, 2012 4:07 PM >>>> To: Santosh Rajagopalan >>>> Cc: trill@ietf.org >>>> Subject: Re: [trill] TRILL OAM Requirements: available paths >>>>=20 >>>> On 4/27/12 2:15 PM, Santosh Rajagopalan wrote: >>>>> I agree, the wording needs to be tightened to say "all possible ecmp >>>>> paths" rather than "all available paths". An operator working out >>>>> R1-R2 communication is interested in all possible paths data traffic >>>>> could take rather than all theoretically available paths. >>>>=20 >>>> The issue is that there is nothing in the TRILL dataplane nor IS-IS >>>> control plane which helps the operator determine that some paths >>>> (through RB121 and RB112 in the example) are not possible; the ECMP >>>> input and hashing is a completely local matter on each RBridge. >>>>=20 >>>> It isn't useful to state a requirement around something that can't be >>>> determined. >>>>=20 >>>> Erik >>>>=20 >>>>>=20 >>>>>=20 >>>>> From: Erik Nordmark >>>>> To: trill@ietf.org >>>>> Date: 04/27/2012 09:53 AM >>>>> Subject: [trill] TRILL OAM Requirements: available paths Sent by: >>>>> trill-bounces@ietf.org >>>>> ----------------------------------------------------------------------= >>>>> -- >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Two requirements use the wording "all available paths." and "all >>>>> available ECMP paths.", respectively and I'm not sure I know what that= >>>>=20 >>>>> means. >>>>>=20 >>>>> Take the following example picture: >>>>>=20 >>>>> R1 >>>>> / \ >>>>> / \ >>>>> / \ >>>>> / \ >>>>> / \ >>>>> RB11 RB12 >>>>> / \ / \ >>>>> / \ / \ >>>>> RB111 RB112 RB121 RB122 >>>>> \ \ / / >>>>> \ \ / / >>>>> \ \/ / >>>>> ------R2------ >>>>>=20 >>>>> We can see that there are 4 paths with 3 hops to get from R1 to R2, >>>>> with two layers of ECMP decisions. But how many available paths are >>>> there? >>>>>=20 >>>>> Given that the RBridges make independent ECMP decisions, and how they >>>>> do that is a local matter, it could be the case that for any packet, >>>>> if R1 picks the left link, then R11 would also pick the left link; if >>>>> R1 picks the right link, then R12 also picks the right link. >>>>> Thus there would be no packet (data or OAM) that would cause packets >>>>> between R1 and R2 to pass via RB112 or RB121. >>>>>=20 >>>>> Even if we ignore that as unlikely, there is still the fact that R1 >>>>> can't easily tell how many (shortest) paths there might be between it >>>>> and R2. With single-level TRILL the LSDB could be used to tell, but if= >>>>=20 >>>>> we ever go to multi-level that wouldn't be the case any more. >>>>> And even if R1 knows that there are 4 potential paths, it can't format= >>>>=20 >>>>> a data packet (or format the flow entropy in an OAM packet) in such a >>>>> way that particular paths get chosen by downstream ECMP decisions. >>>>>=20 >>>>> Thus for any notion of "all available paths" that make sense to me, >>>>> we'd need an OAM approach that can explore the topology one hop at a >>>>> time and at each hop explore all the possible ECMP choices. Using the >>>>> entropy doesn't help with this (but the entropy is critical for >>>>> following the path taken by a particular flow of data packets). >>>>>=20 >>>>> Hence it would be good to clarify what the assumptions are behind this= >>>>=20 >>>>> notion of all available paths. >>>>>=20 >>>>> Thanks, >>>>> Erik >>>>>=20 >>>>> _______________________________________________ >>>>> trill mailing list >>>>> trill@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/trill >>>>>=20 >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> trill mailing list >>>> trill@ietf.org >>>> https://www.ietf.org/mailman/listinfo/trill >>>>=20 >>>=20 >>> _______________________________________________ >>> trill mailing list >>> trill@ietf.org >>> https://www.ietf.org/mailman/listinfo/trill >>=20 >=20 From aldrin.ietf@gmail.com Sun Apr 29 17:48:18 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5E4021F85E7 for ; Sun, 29 Apr 2012 17:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] 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 y3s5KE9iBmW6 for ; Sun, 29 Apr 2012 17:48:18 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC2D21F85E1 for ; Sun, 29 Apr 2012 17:48:18 -0700 (PDT) Received: by dady13 with SMTP id y13so4499928dad.27 for ; Sun, 29 Apr 2012 17:48:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=nJNMb8fKQkHBX9arz5e4bQVqP5AvvO8epTZW9bdKGe8=; b=Tb3glU9pJ6V0W+aLsaE2JtqG13bHEf9MpLraVJ7uZ/mzlhge3shACIsT7Rv07VUQnZ PWa4F1O6GA1MfURpBinCqE+v9kxyYEG+/7l34J5yiYYYYo8UulTEjpQ2yQaicqEXQuwM UCqpLbGnZvh+A+YXAyjRh85q0vUJhnAsE9/c3gRRVh3Upxt3gTYNjVszpS0t4AetSU8O 65XWLfNHvtEcdvNWvbkONplzvlRqavmTQ7lRnMjftRbr/+Y+xArw05/1XpQRZrS2hwDl OShGQAf7x0E20zzM/K28SVCCkmQn87+F5UQwpljBkDc+kVgfaE9O2ah/gNWxIQpxV9wL 7zqg== Received: by 10.68.230.40 with SMTP id sv8mr37777390pbc.124.1335746898045; Sun, 29 Apr 2012 17:48:18 -0700 (PDT) Received: from [10.33.239.44] (mobile-166-205-138-122.mycingular.net. [166.205.138.122]) by mx.google.com with ESMTPS id hp1sm14295570pbc.67.2012.04.29.17.48.16 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 29 Apr 2012 17:48:17 -0700 (PDT) References: <4F9ACE0E.7030408@sonic.net> <4F9ACF05.9070302@acm.org> <4F9B2697.8080401@acm.org> <344037D7CFEFE84E97E9CC1F56C5F4A5010A2FFF@xmb-sjc-214.amer.cisco.com> <4F9CB95E.4030902@acm.org> <20718496-0FAA-4683-A83E-B97563E01BB6@gmail.com> <4F9DDE90.5080604@acm.org> In-Reply-To: <4F9DDE90.5080604@acm.org> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <7266367D-294A-4882-9C6F-D38DFD96B0E1@gmail.com> X-Mailer: iPhone Mail (9B176) From: Sam Aldrin Date: Sun, 29 Apr 2012 17:48:11 -0700 To: Erik Nordmark Cc: "Tissa Senevirathne \(tsenevir\)" , Santosh Rajagopalan , "trill@ietf.org" Subject: Re: [trill] TRILL OAM Requirements: available paths X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 00:48:19 -0000 Sent from my iPhone On Apr 29, 2012, at 5:36 PM, Erik Nordmark wrote: > On 4/28/12 9:54 PM, Sam Aldrin wrote: >> Erik, >>=20 >> Every hop in mpls does hashing based on label stack and other header deta= ils. I do not see any difference between TRILL and mpls in this case. >=20 > That's not consistent with what I heard from others when I discussed MPLS O= AM. But that isn't the main point. All the implementations I have implemented and came across does hashing at e= very hop. >=20 >> The requirement is to specify the ability to test each of those ecmp pat= hs available. Doesn't matter if the active traffic is taking that path or no= t. This is part of pro-active monitoring. >=20 > OK. Then please make that clear in the requirements document. For instance= , that can be done by including a careful definition of "available ecmp path= s" in the document. Definitely. This review effort is to remove any ambiguity. Sam >=20 > FWIW I don't think any of the solutions that have been discussed so far ar= e capable of testing all the available paths; that just means there is some m= ore work needed on solutions. >=20 > Erik >=20 >> Cheers >> Sam >>=20 >>=20 >> Sent from my iPad >>=20 >> On Apr 28, 2012, at 8:45 PM, Erik Nordmark wrote: >>=20 >>> On 4/27/12 5:12 PM, Tissa Senevirathne (tsenevir) wrote: >>>> Of course it is possible. The IS-IS topology table provide the >>>> information on all available ECMP paths to a specific destination when >>>> the egress RBRidge nickname is known. That is what TRILL unicast >>>> forwarding table all about. Not sure why you are saying it is not >>>> possible to know all ECMP paths. >>>=20 >>> You are talking about what Santosh called "all theoretically available p= aths". Those can be determined from IS-IS. >>>=20 >>> But the document talks about "all available paths" and I don't know what= that is supposed to mean. Do you have a succinct definition? >>>=20 >>> What is clear to me is that there can be a subset of the paths that are d= etermined from IS-IS that would never be used, because no entropy in a packe= t would every pick that path. >>>=20 >>> Is the requirement in the document that the OAM solution should be able t= o test those paths? >>>=20 >>>> What path among available paths to be selected for a specified is a >>>> local matter. That is what all about flow entropy discovery. Like I >>>> stated earlier how it is discovered is a framework and solution issue. >>>=20 >>> Agreed. >>>=20 >>>> If you need some reference how it is done in the MPLS world RFC 4379 is= >>>> a good reference. >>>=20 >>> AFAIK MPLS doesn't have a locally defined ECMP hash function in every ho= p. TRILL does, which makes these aspects different. >>>=20 >>> Regards, >>> Erik >>>=20 >>>> -----Original Message----- >>>> From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf >>>> Of Erik Nordmark >>>> Sent: Friday, April 27, 2012 4:07 PM >>>> To: Santosh Rajagopalan >>>> Cc: trill@ietf.org >>>> Subject: Re: [trill] TRILL OAM Requirements: available paths >>>>=20 >>>> On 4/27/12 2:15 PM, Santosh Rajagopalan wrote: >>>>> I agree, the wording needs to be tightened to say "all possible ecmp >>>>> paths" rather than "all available paths". An operator working out >>>>> R1-R2 communication is interested in all possible paths data traffic >>>>> could take rather than all theoretically available paths. >>>>=20 >>>> The issue is that there is nothing in the TRILL dataplane nor IS-IS >>>> control plane which helps the operator determine that some paths >>>> (through RB121 and RB112 in the example) are not possible; the ECMP >>>> input and hashing is a completely local matter on each RBridge. >>>>=20 >>>> It isn't useful to state a requirement around something that can't be >>>> determined. >>>>=20 >>>> Erik >>>>=20 >>>>>=20 >>>>>=20 >>>>> From: Erik Nordmark >>>>> To: trill@ietf.org >>>>> Date: 04/27/2012 09:53 AM >>>>> Subject: [trill] TRILL OAM Requirements: available paths Sent by: >>>>> trill-bounces@ietf.org >>>>> ----------------------------------------------------------------------= >>>>> -- >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Two requirements use the wording "all available paths." and "all >>>>> available ECMP paths.", respectively and I'm not sure I know what that= >>>>=20 >>>>> means. >>>>>=20 >>>>> Take the following example picture: >>>>>=20 >>>>> R1 >>>>> / \ >>>>> / \ >>>>> / \ >>>>> / \ >>>>> / \ >>>>> RB11 RB12 >>>>> / \ / \ >>>>> / \ / \ >>>>> RB111 RB112 RB121 RB122 >>>>> \ \ / / >>>>> \ \ / / >>>>> \ \/ / >>>>> ------R2------ >>>>>=20 >>>>> We can see that there are 4 paths with 3 hops to get from R1 to R2, >>>>> with two layers of ECMP decisions. But how many available paths are >>>> there? >>>>>=20 >>>>> Given that the RBridges make independent ECMP decisions, and how they >>>>> do that is a local matter, it could be the case that for any packet, >>>>> if R1 picks the left link, then R11 would also pick the left link; if >>>>> R1 picks the right link, then R12 also picks the right link. >>>>> Thus there would be no packet (data or OAM) that would cause packets >>>>> between R1 and R2 to pass via RB112 or RB121. >>>>>=20 >>>>> Even if we ignore that as unlikely, there is still the fact that R1 >>>>> can't easily tell how many (shortest) paths there might be between it >>>>> and R2. With single-level TRILL the LSDB could be used to tell, but if= >>>>=20 >>>>> we ever go to multi-level that wouldn't be the case any more. >>>>> And even if R1 knows that there are 4 potential paths, it can't format= >>>>=20 >>>>> a data packet (or format the flow entropy in an OAM packet) in such a >>>>> way that particular paths get chosen by downstream ECMP decisions. >>>>>=20 >>>>> Thus for any notion of "all available paths" that make sense to me, >>>>> we'd need an OAM approach that can explore the topology one hop at a >>>>> time and at each hop explore all the possible ECMP choices. Using the >>>>> entropy doesn't help with this (but the entropy is critical for >>>>> following the path taken by a particular flow of data packets). >>>>>=20 >>>>> Hence it would be good to clarify what the assumptions are behind this= >>>>=20 >>>>> notion of all available paths. >>>>>=20 >>>>> Thanks, >>>>> Erik >>>>>=20 >>>>> _______________________________________________ >>>>> trill mailing list >>>>> trill@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/trill >>>>>=20 >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> trill mailing list >>>> trill@ietf.org >>>> https://www.ietf.org/mailman/listinfo/trill >>>>=20 >>>=20 >>> _______________________________________________ >>> trill mailing list >>> trill@ietf.org >>> https://www.ietf.org/mailman/listinfo/trill >>=20 >=20 From d3e3e3@gmail.com Sun Apr 29 18:27:11 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 673E321F85A3 for ; Sun, 29 Apr 2012 18:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.743 X-Spam-Level: X-Spam-Status: No, score=-103.743 tagged_above=-999 required=5 tests=[AWL=-0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 ziEfHYq8r2dd for ; Sun, 29 Apr 2012 18:27:10 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB1621F8534 for ; Sun, 29 Apr 2012 18:27:10 -0700 (PDT) Received: by iazz13 with SMTP id z13so4355237iaz.31 for ; Sun, 29 Apr 2012 18:27:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=UL1f3gNHdVqFPmPuSlCa4RcaLiZgfhAiu/+DlGYVLnI=; b=tpowRS8P4j0BJFGm4dfmUq0J+UaE9DIe+FUwVRl8k7+a5d5DSzMEHa2bUKKNCNVsGp j2CDgQo4RaVP0hJR2ZV+8kTzFH3wqKFezs1FrWQow2/sylF8rmf/ypv8L+YUD53vgcub Ay2MZYJLdTlimzHonHZvt9z6cZDfGgkx3UynQxzKK07Z3l9iW6uGZJPqPx9+J+9ITzJ4 7UMfq2C9uxLhVCfqjcjHEzoTlme5a+b05vCROOosJl5aMyiQMDyZD2Zx+pkbriE8ruzE uX/GM7W1u9VX9xHg/1iUm7sd4pox8Qpv98X1sLMbcD8e8b/QNp5IJJpiYgrSZvEHSvkT QZKQ== Received: by 10.50.184.133 with SMTP id eu5mr8966986igc.13.1335749230172; Sun, 29 Apr 2012 18:27:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.59.201 with HTTP; Sun, 29 Apr 2012 18:26:50 -0700 (PDT) In-Reply-To: <4F9CB95E.4030902@acm.org> References: <4F9ACE0E.7030408@sonic.net> <4F9ACF05.9070302@acm.org> <4F9B2697.8080401@acm.org> <344037D7CFEFE84E97E9CC1F56C5F4A5010A2FFF@xmb-sjc-214.amer.cisco.com> <4F9CB95E.4030902@acm.org> From: Donald Eastlake Date: Sun, 29 Apr 2012 21:26:50 -0400 Message-ID: To: trill@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [trill] TRILL OAM Requirements: available paths X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 01:27:11 -0000 I don't think the wording "all paths" should ever be used. If you the it literally, it would even include paths that go through some RBridges more than once. I don't particularly like "all ECMP paths" either. I think the clearest wording is "all least cost paths" if you are talking about known unicast. (And "all distribution tree paths" if you were talking about multi-destination frames.) Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com On Sat, Apr 28, 2012 at 11:45 PM, Erik Nordmark wrote: > On 4/27/12 5:12 PM, Tissa Senevirathne (tsenevir) wrote: >> >> Of course it is possible. The IS-IS topology table provide the >> information on all available ECMP paths to a specific destination when >> the egress RBRidge nickname is known. That is what TRILL unicast >> forwarding table all about. Not sure why you are saying it is not >> possible to know all ECMP paths. > > > You are talking about what Santosh called "all theoretically available > paths". Those can be determined from IS-IS. > > But the document talks about "all available paths" and I don't know what > that is supposed to mean. Do you have a succinct definition? > > What is clear to me is that there can be a subset of the paths that are > determined from IS-IS that would never be used, because no entropy in a > packet would every pick that path. > > Is the requirement in the document that the OAM solution should be able t= o > test those paths? > > >> What path among available paths to be selected for a specified is a >> local matter. That is what all about flow entropy discovery. Like I >> stated earlier how it is discovered is a framework and solution issue. > > > Agreed. > > >> If you need some reference how it is done in the MPLS world RFC 4379 is >> a good reference. > > > AFAIK MPLS doesn't have a locally defined ECMP hash function in every hop= . > TRILL does, which makes these aspects different. > > Regards, > =A0 Erik > > >> -----Original Message----- >> From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf >> Of Erik Nordmark >> Sent: Friday, April 27, 2012 4:07 PM >> To: Santosh Rajagopalan >> Cc: trill@ietf.org >> Subject: Re: [trill] TRILL OAM Requirements: available paths >> >> On 4/27/12 2:15 PM, Santosh Rajagopalan wrote: >>> >>> I agree, the wording needs to be tightened to say "all possible ecmp >>> paths" rather than "all available paths". An operator working out >>> R1-R2 communication is interested in all possible paths data traffic >>> could take rather than all theoretically available paths. >> >> >> The issue is that there is nothing in the TRILL dataplane nor IS-IS >> control plane which helps the operator determine that some paths >> (through RB121 and RB112 in the example) are not possible; the ECMP >> input and hashing is a completely local matter on each RBridge. >> >> It isn't useful to state a requirement around something that can't be >> determined. >> >> =A0 =A0 Erik >> >>> >>> >>> From: Erik Nordmark >>> To: trill@ietf.org >>> Date: 04/27/2012 09:53 AM >>> Subject: [trill] TRILL OAM Requirements: available paths Sent by: >>> trill-bounces@ietf.org >>> ---------------------------------------------------------------------- >>> -- >>> >>> >>> >>> >>> Two requirements use the wording "all available paths." and "all >>> available ECMP paths.", respectively and I'm not sure I know what that >> >> >>> means. >>> >>> Take the following example picture: >>> >>> R1 >>> / \ >>> / \ >>> / \ >>> / \ >>> / \ >>> RB11 RB12 >>> / \ / \ >>> / \ / \ >>> RB111 RB112 RB121 RB122 >>> \ \ / / >>> \ \ / / >>> \ \/ / >>> ------R2------ >>> >>> We can see that there are 4 paths with 3 hops to get from R1 to R2, >>> with two layers of ECMP decisions. But how many available paths are >> >> there? >>> >>> >>> Given that the RBridges make independent ECMP decisions, and how they >>> do that is a local matter, it could be the case that for any packet, >>> if R1 picks the left link, then R11 would also pick the left link; if >>> R1 picks the right link, then R12 also picks the right link. >>> Thus there would be no packet (data or OAM) that would cause packets >>> between R1 and R2 to pass via RB112 or RB121. >>> >>> Even if we ignore that as unlikely, there is still the fact that R1 >>> can't easily tell how many (shortest) paths there might be between it >>> and R2. With single-level TRILL the LSDB could be used to tell, but if >> >> >>> we ever go to multi-level that wouldn't be the case any more. >>> And even if R1 knows that there are 4 potential paths, it can't format >> >> >>> a data packet (or format the flow entropy in an OAM packet) in such a >>> way that particular paths get chosen by downstream ECMP decisions. >>> >>> Thus for any notion of "all available paths" that make sense to me, >>> we'd need an OAM approach that can explore the topology one hop at a >>> time and at each hop explore all the possible ECMP choices. Using the >>> entropy doesn't help with this (but the entropy is critical for >>> following the path taken by a particular flow of data packets). >>> >>> Hence it would be good to clarify what the assumptions are behind this >> >> >>> notion of all available paths. >>> >>> Thanks, >>> Erik >>> >>> _______________________________________________ >>> trill mailing list >>> trill@ietf.org >>> https://www.ietf.org/mailman/listinfo/trill >>> >>> >> >> _______________________________________________ >> trill mailing list >> trill@ietf.org >> https://www.ietf.org/mailman/listinfo/trill >> > > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill From tsenevir@cisco.com Sun Apr 29 20:42:36 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF6821F8617 for ; Sun, 29 Apr 2012 20:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.649 X-Spam-Level: X-Spam-Status: No, score=-8.649 tagged_above=-999 required=5 tests=[AWL=1.950, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 sQXMlOjozO69 for ; Sun, 29 Apr 2012 20:42:35 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id D4A5F21F8616 for ; Sun, 29 Apr 2012 20:42:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tsenevir@cisco.com; l=6706; q=dns/txt; s=iport; t=1335757354; x=1336966954; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=UVBKZG4H7u/FsdGeIauHdy352+bMsjJCxq3wRE1qh4g=; b=QYn5hUwi8hED5R7MsiZTq4mG3mc3RUNQ7SEMdRxEVD8b92pFNGLO+FCm /Xq/rJ3JhzUDIrZt/i0TwhX++5NLZH6uXocHN7szBbt/jdfC8j4b6t4J3 nCe3+pSD2XTEsZVdYMatX0wo1L6LF5XHmpMilmVBTdlenTgJm1MFOGtm5 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFADIJnk+rRDoI/2dsb2JhbABBA7IggQeCCQEBAQQBAQEPAR0+FwQCAQgOAwMBAQEBCgYXAQYBIAYfCQgBAQQBEggTB4ddAwoBC5lalTYNiU8EigyDbIJHYwSIMDSYWYMagWmDCA X-IronPort-AV: E=Sophos;i="4.75,502,1330905600"; d="scan'208";a="42743958" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 30 Apr 2012 03:42:34 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3U3gYCc018822; Mon, 30 Apr 2012 03:42:34 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 29 Apr 2012 20:42:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 29 Apr 2012 20:42:33 -0700 Message-ID: <344037D7CFEFE84E97E9CC1F56C5F4A5010A30CC@xmb-sjc-214.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [trill] TRILL OAM Requirements: available paths Thread-Index: Ac0mcGDwgue3+JraRFqJiNKsvguVSAAErbbg References: <4F9ACE0E.7030408@sonic.net> <4F9ACF05.9070302@acm.org><4F9B2697.8080401@acm.org><344037D7CFEFE84E97E9CC1F56C5F4A5010A2FFF@xmb-sjc-214.amer.cisco.com><4F9CB95E.4030902@acm.org> From: "Tissa Senevirathne (tsenevir)" To: "Donald Eastlake" , X-OriginalArrivalTime: 30 Apr 2012 03:42:34.0351 (UTC) FILETIME=[475DBFF0:01CD2683] Subject: Re: [trill] TRILL OAM Requirements: available paths X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 03:42:36 -0000 I like that Donald.. We can use "all least cost paths", that is = technically more precise and represent exactly what IS-IS does. Thanks Tissa -----Original Message----- From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf = Of Donald Eastlake Sent: Sunday, April 29, 2012 6:27 PM To: trill@ietf.org Subject: Re: [trill] TRILL OAM Requirements: available paths I don't think the wording "all paths" should ever be used. If you the it = literally, it would even include paths that go through some RBridges = more than once. I don't particularly like "all ECMP paths" either. I think the clearest = wording is "all least cost paths" if you are talking about known = unicast. (And "all distribution tree paths" if you were talking about = multi-destination frames.) Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com On Sat, Apr 28, 2012 at 11:45 PM, Erik Nordmark = wrote: > On 4/27/12 5:12 PM, Tissa Senevirathne (tsenevir) wrote: >> >> Of course it is possible. The IS-IS topology table provide the=20 >> information on all available ECMP paths to a specific destination=20 >> when the egress RBRidge nickname is known. That is what TRILL unicast = >> forwarding table all about. Not sure why you are saying it is not=20 >> possible to know all ECMP paths. > > > You are talking about what Santosh called "all theoretically available = > paths". Those can be determined from IS-IS. > > But the document talks about "all available paths" and I don't know=20 > what that is supposed to mean. Do you have a succinct definition? > > What is clear to me is that there can be a subset of the paths that=20 > are determined from IS-IS that would never be used, because no entropy = > in a packet would every pick that path. > > Is the requirement in the document that the OAM solution should be=20 > able to test those paths? > > >> What path among available paths to be selected for a specified is a=20 >> local matter. That is what all about flow entropy discovery. Like I=20 >> stated earlier how it is discovered is a framework and solution = issue. > > > Agreed. > > >> If you need some reference how it is done in the MPLS world RFC 4379=20 >> is a good reference. > > > AFAIK MPLS doesn't have a locally defined ECMP hash function in every = hop. > TRILL does, which makes these aspects different. > > Regards, > =A0 Erik > > >> -----Original Message----- >> From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On=20 >> Behalf Of Erik Nordmark >> Sent: Friday, April 27, 2012 4:07 PM >> To: Santosh Rajagopalan >> Cc: trill@ietf.org >> Subject: Re: [trill] TRILL OAM Requirements: available paths >> >> On 4/27/12 2:15 PM, Santosh Rajagopalan wrote: >>> >>> I agree, the wording needs to be tightened to say "all possible ecmp = >>> paths" rather than "all available paths". An operator working out >>> R1-R2 communication is interested in all possible paths data traffic = >>> could take rather than all theoretically available paths. >> >> >> The issue is that there is nothing in the TRILL dataplane nor IS-IS=20 >> control plane which helps the operator determine that some paths=20 >> (through RB121 and RB112 in the example) are not possible; the ECMP=20 >> input and hashing is a completely local matter on each RBridge. >> >> It isn't useful to state a requirement around something that can't be = >> determined. >> >> =A0 =A0 Erik >> >>> >>> >>> From: Erik Nordmark >>> To: trill@ietf.org >>> Date: 04/27/2012 09:53 AM >>> Subject: [trill] TRILL OAM Requirements: available paths Sent by: >>> trill-bounces@ietf.org >>> -------------------------------------------------------------------- >>> -- >>> -- >>> >>> >>> >>> >>> Two requirements use the wording "all available paths." and "all=20 >>> available ECMP paths.", respectively and I'm not sure I know what=20 >>> that >> >> >>> means. >>> >>> Take the following example picture: >>> >>> R1 >>> / \ >>> / \ >>> / \ >>> / \ >>> / \ >>> RB11 RB12 >>> / \ / \ >>> / \ / \ >>> RB111 RB112 RB121 RB122 >>> \ \ / / >>> \ \ / / >>> \ \/ / >>> ------R2------ >>> >>> We can see that there are 4 paths with 3 hops to get from R1 to R2,=20 >>> with two layers of ECMP decisions. But how many available paths are >> >> there? >>> >>> >>> Given that the RBridges make independent ECMP decisions, and how=20 >>> they do that is a local matter, it could be the case that for any=20 >>> packet, if R1 picks the left link, then R11 would also pick the left = >>> link; if >>> R1 picks the right link, then R12 also picks the right link. >>> Thus there would be no packet (data or OAM) that would cause packets = >>> between R1 and R2 to pass via RB112 or RB121. >>> >>> Even if we ignore that as unlikely, there is still the fact that R1=20 >>> can't easily tell how many (shortest) paths there might be between=20 >>> it and R2. With single-level TRILL the LSDB could be used to tell,=20 >>> but if >> >> >>> we ever go to multi-level that wouldn't be the case any more. >>> And even if R1 knows that there are 4 potential paths, it can't=20 >>> format >> >> >>> a data packet (or format the flow entropy in an OAM packet) in such=20 >>> a way that particular paths get chosen by downstream ECMP decisions. >>> >>> Thus for any notion of "all available paths" that make sense to me,=20 >>> we'd need an OAM approach that can explore the topology one hop at a = >>> time and at each hop explore all the possible ECMP choices. Using=20 >>> the entropy doesn't help with this (but the entropy is critical for=20 >>> following the path taken by a particular flow of data packets). >>> >>> Hence it would be good to clarify what the assumptions are behind=20 >>> this >> >> >>> notion of all available paths. >>> >>> Thanks, >>> Erik >>> >>> _______________________________________________ >>> trill mailing list >>> trill@ietf.org >>> https://www.ietf.org/mailman/listinfo/trill >>> >>> >> >> _______________________________________________ >> trill mailing list >> trill@ietf.org >> https://www.ietf.org/mailman/listinfo/trill >> > > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill From dmbond@us.ibm.com Mon Apr 30 08:43:35 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B870621F870E for ; Mon, 30 Apr 2012 08:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.635 X-Spam-Level: X-Spam-Status: No, score=-8.635 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] 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 DYk6jlDKtvnu for ; Mon, 30 Apr 2012 08:43:34 -0700 (PDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by ietfa.amsl.com (Postfix) with ESMTP id DD1E121F870B for ; Mon, 30 Apr 2012 08:43:33 -0700 (PDT) Received: from /spool/local by e6.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 30 Apr 2012 11:43:32 -0400 Received: from d01dlp01.pok.ibm.com (9.56.224.56) by e6.ny.us.ibm.com (192.168.1.106) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 30 Apr 2012 11:39:24 -0400 Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 7917C38C805A; Mon, 30 Apr 2012 11:39:10 -0400 (EDT) Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q3UFd8L325100426; Mon, 30 Apr 2012 11:39:08 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q3UFd7pj000835; Mon, 30 Apr 2012 12:39:08 -0300 Received: from d01ml076.pok.ibm.com (d01ml076.pok.ibm.com [9.63.8.33]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q3UFd4OP000592; Mon, 30 Apr 2012 12:39:05 -0300 In-Reply-To: <344037D7CFEFE84E97E9CC1F56C5F4A5010A30CC@xmb-sjc-214.amer.cisco.com> References: <4F9ACE0E.7030408@sonic.net> <4F9ACF05.9070302@acm.org><4F9B2697.8080401@acm.org><344037D7CFEFE84E97E9CC1F56C5F4A5010A2FFF@xmb-sjc-214.amer.cisco.com><4F9CB95E.4030902@acm.org> <344037D7CFEFE84E97E9CC1F56C5F4A5010A30CC@xmb-sjc-214.amer.cisco.com> X-KeepSent: DC088BDF:7A5287CE-852579F0:0054CC14; type=4; name=$KeepSent To: "Tissa Senevirathne (tsenevir)" X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: David M Bond Date: Mon, 30 Apr 2012 11:39:04 -0400 X-MIMETrack: Serialize by Router on D01ML076/01/M/IBM(Release 8.5.3 ZX853HP5|January 12, 2012) at 04/30/2012 11:39:04 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=0ABBF363DFC74A848f9e8a93df938690918c0ABBF363DFC74A84" X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12043015-1976-0000-0000-00000CC66D2D Cc: Donald Eastlake , trill-bounces@ietf.org, trill@ietf.org Subject: Re: [trill] TRILL OAM Requirements: available paths X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 15:43:35 -0000 --0__=0ABBF363DFC74A848f9e8a93df938690918c0ABBF363DFC74A84 Content-type: multipart/alternative; Boundary="1__=0ABBF363DFC74A848f9e8a93df938690918c0ABBF363DFC74A84" --1__=0ABBF363DFC74A848f9e8a93df938690918c0ABBF363DFC74A84 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Just a question coming from this conversation that I want to clarify: So we have 'all possible paths' (1) which could include non-least cost paths and so of course we don't want to use this definition. Then we have 'all ecmp paths' or 'all least cost paths' (2) which MAY include paths never chosen by a transit Rbridge because of the local hashing choices. Then we have 'all the least cost paths which may be chosen given the hashing implementation on the local Rbridges' (3). I wonder if choice (2) is useful or do we only really care about choice= (3). For instance, if you have 16 equal cost paths from A to B and your= hashing only will ever use 2 of those paths do we care about reporting = back ecmp paths that will never in practice be used? Perhaps the definition should be tightened to only require determination of all least cost pat= hs that could be used given the local hashing implementation. Or am I misunderstanding the conversation and is this already the point being m= ade between theoretical paths and least cost paths. Thanks, David From: "Tissa Senevirathne (tsenevir)" To: "Donald Eastlake" , Date: 04/29/2012 11:43 PM Subject: Re: [trill] TRILL OAM Requirements: available paths Sent by: trill-bounces@ietf.org I like that Donald.. We can use "all least cost paths", that is technic= ally more precise and represent exactly what IS-IS does. Thanks Tissa -----Original Message----- From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf = Of Donald Eastlake Sent: Sunday, April 29, 2012 6:27 PM To: trill@ietf.org Subject: Re: [trill] TRILL OAM Requirements: available paths I don't think the wording "all paths" should ever be used. If you the i= t literally, it would even include paths that go through some RBridges mo= re than once. I don't particularly like "all ECMP paths" either. I think the clearest= wording is "all least cost paths" if you are talking about known unicas= t. (And "all distribution tree paths" if you were talking about multi-destination frames.) Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com On Sat, Apr 28, 2012 at 11:45 PM, Erik Nordmark wrot= e: > On 4/27/12 5:12 PM, Tissa Senevirathne (tsenevir) wrote: >> >> Of course it is possible. The IS-IS topology table provide the >> information on all available ECMP paths to a specific destination >> when the egress RBRidge nickname is known. That is what TRILL unicas= t >> forwarding table all about. Not sure why you are saying it is not >> possible to know all ECMP paths. > > > You are talking about what Santosh called "all theoretically availabl= e > paths". Those can be determined from IS-IS. > > But the document talks about "all available paths" and I don't know > what that is supposed to mean. Do you have a succinct definition? > > What is clear to me is that there can be a subset of the paths that > are determined from IS-IS that would never be used, because no entrop= y > in a packet would every pick that path. > > Is the requirement in the document that the OAM solution should be > able to test those paths? > > >> What path among available paths to be selected for a specified is a >> local matter. That is what all about flow entropy discovery. Like I >> stated earlier how it is discovered is a framework and solution issu= e. > > > Agreed. > > >> If you need some reference how it is done in the MPLS world RFC 4379= >> is a good reference. > > > AFAIK MPLS doesn't have a locally defined ECMP hash function in every= hop. > TRILL does, which makes these aspects different. > > Regards, > =A0 Erik > > >> -----Original Message----- >> From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On >> Behalf Of Erik Nordmark >> Sent: Friday, April 27, 2012 4:07 PM >> To: Santosh Rajagopalan >> Cc: trill@ietf.org >> Subject: Re: [trill] TRILL OAM Requirements: available paths >> >> On 4/27/12 2:15 PM, Santosh Rajagopalan wrote: >>> >>> I agree, the wording needs to be tightened to say "all possible ecm= p >>> paths" rather than "all available paths". An operator working out >>> R1-R2 communication is interested in all possible paths data traffi= c >>> could take rather than all theoretically available paths. >> >> >> The issue is that there is nothing in the TRILL dataplane nor IS-IS >> control plane which helps the operator determine that some paths >> (through RB121 and RB112 in the example) are not possible; the ECMP >> input and hashing is a completely local matter on each RBridge. >> >> It isn't useful to state a requirement around something that can't b= e >> determined. >> >> =A0 =A0 Erik >> >>> >>> >>> From: Erik Nordmark >>> To: trill@ietf.org >>> Date: 04/27/2012 09:53 AM >>> Subject: [trill] TRILL OAM Requirements: available paths Sent by: >>> trill-bounces@ietf.org >>> -------------------------------------------------------------------= - >>> -- >>> -- >>> >>> >>> >>> >>> Two requirements use the wording "all available paths." and "all >>> available ECMP paths.", respectively and I'm not sure I know what >>> that >> >> >>> means. >>> >>> Take the following example picture: >>> >>> R1 >>> / \ >>> / \ >>> / \ >>> / \ >>> / \ >>> RB11 RB12 >>> / \ / \ >>> / \ / \ >>> RB111 RB112 RB121 RB122 >>> \ \ / / >>> \ \ / / >>> \ \/ / >>> ------R2------ >>> >>> We can see that there are 4 paths with 3 hops to get from R1 to R2,= >>> with two layers of ECMP decisions. But how many available paths are= >> >> there? >>> >>> >>> Given that the RBridges make independent ECMP decisions, and how >>> they do that is a local matter, it could be the case that for any >>> packet, if R1 picks the left link, then R11 would also pick the lef= t >>> link; if >>> R1 picks the right link, then R12 also picks the right link. >>> Thus there would be no packet (data or OAM) that would cause packet= s >>> between R1 and R2 to pass via RB112 or RB121. >>> >>> Even if we ignore that as unlikely, there is still the fact that R1= >>> can't easily tell how many (shortest) paths there might be between >>> it and R2. With single-level TRILL the LSDB could be used to tell, >>> but if >> >> >>> we ever go to multi-level that wouldn't be the case any more. >>> And even if R1 knows that there are 4 potential paths, it can't >>> format >> >> >>> a data packet (or format the flow entropy in an OAM packet) in such= >>> a way that particular paths get chosen by downstream ECMP decisions= . >>> >>> Thus for any notion of "all available paths" that make sense to me,= >>> we'd need an OAM approach that can explore the topology one hop at = a >>> time and at each hop explore all the possible ECMP choices. Using >>> the entropy doesn't help with this (but the entropy is critical for= >>> following the path taken by a particular flow of data packets). >>> >>> Hence it would be good to clarify what the assumptions are behind >>> this >> >> >>> notion of all available paths. >>> >>> Thanks, >>> Erik >>> >>> _______________________________________________ >>> trill mailing list >>> trill@ietf.org >>> https://www.ietf.org/mailman/listinfo/trill >>> >>> >> >> _______________________________________________ >> trill mailing list >> trill@ietf.org >> https://www.ietf.org/mailman/listinfo/trill >> > > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill = --1__=0ABBF363DFC74A848f9e8a93df938690918c0ABBF363DFC74A84 Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-transfer-encoding: quoted-printable

Just a question coming from thi= s conversation that I want to clarify:

So we have 'all possible paths' (1= ) which could include non-least cost paths and so of course we don't wa= nt to use this definition.

Then we have 'all ecmp paths' or '= all least cost paths' (2) which MAY include paths never chosen by a tra= nsit Rbridge because of the local hashing choices.

Then we have 'all the least cost p= aths which may be chosen given the hashing implementation on the local = Rbridges' (3).

I wonder if choice (2) is useful o= r do we only really care about choice (3). For instance, if you have 16= equal cost paths from A to B and your hashing only will ever use 2 of = those paths do we care about reporting back ecmp paths that will never = in practice be used? Perhaps the definition should be tightened to only= require determination of all least cost paths that could be used given= the local hashing implementation. Or am I misunderstanding the convers= ation and is this already the point being made between theoretical path= s and least cost paths.

Thanks,
David

3D"Inactive"Tissa Senevirathne (tsenevir)" ---= 04/29/2012 11:43:07 PM---I like that Donald.. We can use "all leas= t cost paths", that is technically more precise and represe=

From: "Tissa Senevirathne (tsenevir)&q= uot; <tsenevir@cisco.com>
To: "Donald Eastlake" <d3e3e3@= gmail.com>, <trill@ietf.org>
Date: 04/29/2012 11:43 PM
Subject: = Re: [trill] TRILL OAM Requirements= : available paths
Sent by: = trill-bounces@ietf.org




I like that Donald.. We can use "all least co= st paths", that is technically more precise and represent exactly = what IS-IS does.

Thanks
Tissa

-----Original Message-----
From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of Donald Eastlake
Sent: Sunday, April 29, 2012 6:27 PM
To: trill@ietf.org
Subject: Re: [trill] TRILL OAM Requirements: available paths

I don't think the wording "all paths" should ever be used. If= you the it literally, it would even include paths that go through some= RBridges more than once.

I don't particularly like "all ECMP paths" either. I think th= e clearest wording is "all least cost paths" if you are talki= ng about known unicast. (And "all distribution tree paths" if= you were talking about multi-destination frames.)

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
=A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell)
=A0155 Beaver Street,=A0Milford, MA 01757 USA
=A0d3e3e3@gmail.com


On Sat, Apr 28, 2012 at 11:45 PM, Erik Nordmark <nordmark@acm.org>= ; wrote:
> On 4/27/12 5:12 PM, Tissa Senevirathne (tsenevir) wrote:
>>
>> Of course it is possible. The IS-IS topology table provide the=
>> information on all available ECMP paths to a specific destinat= ion
>> when the egress RBRidge nickname is known. That is what TRILL = unicast
>> forwarding table all about. Not sure why you are saying it is = not
>> possible to know all ECMP paths.
>
>
> You are talking about what Santosh called "all theoretically = available
> paths". Those can be determined from IS-IS.
>
> But the document talks about "all available paths" and I= don't know
> what that is supposed to mean. Do you have a succinct definition?<= br> >
> What is clear to me is that there can be a subset of the paths tha= t
> are determined from IS-IS that would never be used, because no ent= ropy
> in a packet would every pick that path.
>
> Is the requirement in the document that the OAM solution should be=
> able to test those paths?
>
>
>> What path among available paths to be selected for a specified= is a
>> local matter. That is what all about flow entropy discovery. L= ike I
>> stated earlier how it is discovered is a framework and solutio= n issue.
>
>
> Agreed.
>
>
>> If you need some reference how it is done in the MPLS world RF= C 4379
>> is a good reference.
>
>
> AFAIK MPLS doesn't have a locally defined ECMP hash function in ev= ery hop.
> TRILL does, which makes these aspects different.
>
> Regards,
> =A0 Erik
>
>
>> -----Original Message-----
>> From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.or= g] On
>> Behalf Of Erik Nordmark
>> Sent: Friday, April 27, 2012 4:07 PM
>> To: Santosh Rajagopalan
>> Cc: trill@ietf.org
>> Subject: Re: [trill] TRILL OAM Requirements: available paths >>
>> On 4/27/12 2:15 PM, Santosh Rajagopalan wrote:
>>>
>>> I agree, the wording needs to be tightened to say "al= l possible ecmp
>>> paths" rather than "all available paths". A= n operator working out
>>> R1-R2 communication is interested in all possible paths da= ta traffic
>>> could take rather than all theoretically available paths.<= br> >>
>>
>> The issue is that there is nothing in the TRILL dataplane nor = IS-IS
>> control plane which helps the operator determine that some pat= hs
>> (through RB121 and RB112 in the example) are not possible; the= ECMP
>> input and hashing is a completely local matter on each RBridge= .
>>
>> It isn't useful to state a requirement around something that c= an't be
>> determined.
>>
>> =A0 =A0 Erik
>>
>>>
>>>
>>> From: Erik Nordmark<nordmark@acm.org>
>>> To: trill@ietf.org
>>> Date: 04/27/2012 09:53 AM
>>> Subject: [trill] TRILL OAM Requirements: available paths S= ent by:
>>> trill-bounces@ietf.org
>>> ----------------------------------------------------------= ----------
>>> --
>>> --
>>>
>>>
>>>
>>>
>>> Two requirements use the wording "all available paths= ." and "all
>>> available ECMP paths.", respectively and I'm not sure= I know what
>>> that
>>
>>
>>> means.
>>>
>>> Take the following example picture:
>>>
>>> R1
>>> / \
>>> / \
>>> / \
>>> / \
>>> / \
>>> RB11 RB12
>>> / \ / \
>>> / \ / \
>>> RB111 RB112 RB121 RB122
>>> \ \ / /
>>> \ \ / /
>>> \ \/ /
>>> ------R2------
>>>
>>> We can see that there are 4 paths with 3 hops to get from = R1 to R2,
>>> with two layers of ECMP decisions. But how many available = paths are
>>
>> there?
>>>
>>>
>>> Given that the RBridges make independent ECMP decisions, a= nd how
>>> they do that is a local matter, it could be the case that = for any
>>> packet, if R1 picks the left link, then R11 would also pic= k the left
>>> link; if
>>> R1 picks the right link, then R12 also picks the right lin= k.
>>> Thus there would be no packet (data or OAM) that would cau= se packets
>>> between R1 and R2 to pass via RB112 or RB121.
>>>
>>> Even if we ignore that as unlikely, there is still the fac= t that R1
>>> can't easily tell how many (shortest) paths there might be= between
>>> it and R2. With single-level TRILL the LSDB could be used = to tell,
>>> but if
>>
>>
>>> we ever go to multi-level that wouldn't be the case any mo= re.
>>> And even if R1 knows that there are 4 potential paths, it = can't
>>> format
>>
>>
>>> a data packet (or format the flow entropy in an OAM packet= ) in such
>>> a way that particular paths get chosen by downstream ECMP = decisions.
>>>
>>> Thus for any notion of "all available paths" tha= t make sense to me,
>>> we'd need an OAM approach that can explore the topology on= e hop at a
>>> time and at each hop explore all the possible ECMP choices= . Using
>>> the entropy doesn't help with this (but the entropy is cri= tical for
>>> following the path taken by a particular flow of data pack= ets).
>>>
>>> Hence it would be good to clarify what the assumptions are= behind
>>> this
>>
>>
>>> notion of all available paths.
>>>
>>> Thanks,
>>> Erik
>>>
>>> _______________________________________________
>>> trill mailing list
>>> trill@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tr= ill
>>>
>>>
>>
>> _______________________________________________
>> trill mailing list
>> trill@ietf.org
>> https://www.ietf.org/mailman/listinfo/trill<= /a>
>>
>
> _______________________________________________
> trill mailing list
> trill@ietf.org
> https://www.ietf.org/mailman/listinfo/trill<= /font>
_______________________________________________
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill
_______________________________________________
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill


= --1__=0ABBF363DFC74A848f9e8a93df938690918c0ABBF363DFC74A84-- --0__=0ABBF363DFC74A848f9e8a93df938690918c0ABBF363DFC74A84 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=0ABBF363DFC74A848f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBF363DFC74A848f9e8a93df938690918c0ABBF363DFC74A84-- From carlsonj@workingcode.com Mon Apr 30 08:59:24 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 216CF21F86A3 for ; Mon, 30 Apr 2012 08:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 VISX5B788lY8 for ; Mon, 30 Apr 2012 08:59:23 -0700 (PDT) Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7223721F8698 for ; Mon, 30 Apr 2012 08:59:23 -0700 (PDT) Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id q3UFxFms026193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Apr 2012 11:59:15 -0400 (EDT) Message-ID: <4F9EB6D2.1050605@workingcode.com> Date: Mon, 30 Apr 2012 11:59:14 -0400 From: James Carlson User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: David M Bond References: <4F9ACE0E.7030408@sonic.net> <4F9ACF05.9070302@acm.org><4F9B2697.8080401@acm.org><344037D7CFEFE84E97E9CC1F56C5F4A5010A2FFF@xmb-sjc-214.amer.cisco.com><4F9CB95E.4030902@acm.org> <344037D7CFEFE84E97E9CC1F56C5F4A5010A30CC@xmb-sjc-214.amer.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC--Metrics: carlson; whitelist Cc: "Tissa Senevirathne \(tsenevir\)" , Donald Eastlake , trill@ietf.org Subject: Re: [trill] TRILL OAM Requirements: available paths X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 15:59:24 -0000 David M Bond wrote: > Just a question coming from this conversation that I want to clarify: > > So we have 'all possible paths' (1) which could include non-least cost > paths and so of course we don't want to use this definition. Indeed. There are (at least) an infinite number of those if you include loops. :-/ > Then we have 'all ecmp paths' or 'all least cost paths' (2) which MAY > include paths never chosen by a transit Rbridge because of the local > hashing choices. > > Then we have 'all the least cost paths which may be chosen given the > hashing implementation on the local Rbridges' (3). I don't think (3) can actually be computed in any meaningful way. You'd have to know the exact hashing algorithm at each node and then perform some sort of analysis to figure out which input values cause which forwarding choices to be made. But the algorithms aren't known (outside of the source code for each node) and the analysis itself (in the general case) requires running trials on each possible input value. Unfortunately, the Universe will eventually hit the big crunch or heat death, and poor TRILL management software will still be trying to figure out whether some ECMP choices in Podunk can or can't be made. I think only (2) is really meaningful. Besides, if the problems that are described for (3) occur, that's an implementation bug, not a feature. The problem of cascading ECMP nodes leading to holes in the hash values is a well-known and well-understood problem, and can be mitigated by having each node mix in locally-chosen stable data into a decent hash computation. -- James Carlson 42.703N 71.076W From pagarwal@broadcom.com Mon Apr 30 10:41:06 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 096CE21F87BD; Mon, 30 Apr 2012 10:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.389 X-Spam-Level: X-Spam-Status: No, score=-5.389 tagged_above=-999 required=5 tests=[AWL=-1.211, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] 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 b2uQCp97mPvS; Mon, 30 Apr 2012 10:41:04 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFF521F87A8; Mon, 30 Apr 2012 10:41:04 -0700 (PDT) Received: from [10.16.192.224] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Mon, 30 Apr 2012 10:41:04 -0700 X-Server-Uuid: B730DE51-FC43-4C83-941F-F1F78A914BDD Received: from SJEXCHCAS07.corp.ad.broadcom.com (10.16.203.17) by SJEXCHHUB01.corp.ad.broadcom.com (10.16.192.224) with Microsoft SMTP Server (TLS) id 8.2.247.2; Mon, 30 Apr 2012 10:40:56 -0700 Received: from SJEXCHMB06.corp.ad.broadcom.com ( [fe80::65ea:1de7:41c4:e948]) by SJEXCHCAS07.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Mon, 30 Apr 2012 10:40:56 -0700 From: "Puneet Agarwal" To: "David M Bond" , "Tissa Senevirathne (tsenevir)" Thread-Topic: [trill] TRILL OAM Requirements: available paths Thread-Index: AQHNJJZVTMVMGcOEcEymoN/hDD8AvJavoeWAgAAfMYCAABJpgIABzb0AgAFrkQCAACXsgIAAyDEA//+sNYA= Date: Mon, 30 Apr 2012 17:40:55 +0000 Message-ID: References: <4F9ACE0E.7030408@sonic.net> <4F9ACF05.9070302@acm.org><4F9B2697.8080401@acm.org><344037D7CFEFE84E97E9CC1F56C5F4A5010A2FFF@xmb-sjc-214.amer.cisco.com><4F9CB95E.4030902@acm.org> <344037D7CFEFE84E97E9CC1F56C5F4A5010A30CC@xmb-sjc-214.amer.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.16.124.58] MIME-Version: 1.0 X-TMWD-Spam-Summary: TS=20120430174105; ID=1; SEV=2.3.1; DFV=B2012043018; IFV=NA; AIF=B2012043018; RPD=5.03.0010; ENG=NA; RPDID=7374723D303030312E30413039303230332E34463945434541392E303041362C73733D312C6667733D30; CAT=NONE; CON=NONE; SIG=AAABAJsKIgAAAAAAAAAAAAAAAAAAAH0= X-MMS-Spam-Filter-ID: B2012043018_5.03.0010 X-WSS-ID: 6380113A3E025444669-01-01 Content-Type: multipart/related; boundary=_004_BA343C7BA78ED743B8A5E83749F7B1C20E7E1CSJEXCHMB06corpadb_; type="multipart/alternative" Cc: Donald Eastlake , "trill-bounces@ietf.org" , "trill@ietf.org" Subject: Re: [trill] TRILL OAM Requirements: available paths X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 17:41:06 -0000 --_004_BA343C7BA78ED743B8A5E83749F7B1C20E7E1CSJEXCHMB06corpadb_ Content-Type: multipart/alternative; boundary=_000_BA343C7BA78ED743B8A5E83749F7B1C20E7E1CSJEXCHMB06corpadb_ Content-Transfer-Encoding: 7bit --_000_BA343C7BA78ED743B8A5E83749F7B1C20E7E1CSJEXCHMB06corpadb_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Protocol should be based on option 2 ie all ECMP paths. Thanks. -Puneet From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of D= avid M Bond Sent: Monday, April 30, 2012 8:39 AM To: Tissa Senevirathne (tsenevir) Cc: Donald Eastlake; trill-bounces@ietf.org; trill@ietf.org Subject: Re: [trill] TRILL OAM Requirements: available paths Just a question coming from this conversation that I want to clarify: So we have 'all possible paths' (1) which could include non-least cost path= s and so of course we don't want to use this definition. Then we have 'all ecmp paths' or 'all least cost paths' (2) which MAY inclu= de paths never chosen by a transit Rbridge because of the local hashing cho= ices. Then we have 'all the least cost paths which may be chosen given the hashin= g implementation on the local Rbridges' (3). I wonder if choice (2) is useful or do we only really care about choice (3)= . For instance, if you have 16 equal cost paths from A to B and your hashin= g only will ever use 2 of those paths do we care about reporting back ecmp = paths that will never in practice be used? Perhaps the definition should be= tightened to only require determination of all least cost paths that could= be used given the local hashing implementation. Or am I misunderstanding t= he conversation and is this already the point being made between theoretica= l paths and least cost paths. Thanks, David [Inactive hide details for "Tissa Senevirathne (tsenevir)" ---04/29/2012 11= :43:07 PM---I like that Donald.. We can use "all leas]"Tissa Senevirathne (= tsenevir)" ---04/29/2012 11:43:07 PM---I like that Donald.. We can use "all= least cost paths", that is technically more precise and represe From: "Tissa Senevirathne (tsenevir)" > To: "Donald Eastlake" >, > Date: 04/29/2012 11:43 PM Subject: Re: [trill] TRILL OAM Requirements: available paths Sent by: trill-bounces@ietf.org ________________________________ I like that Donald.. We can use "all least cost paths", that is technically= more precise and represent exactly what IS-IS does. Thanks Tissa -----Original Message----- From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of D= onald Eastlake Sent: Sunday, April 29, 2012 6:27 PM To: trill@ietf.org Subject: Re: [trill] TRILL OAM Requirements: available paths I don't think the wording "all paths" should ever be used. If you the it li= terally, it would even include paths that go through some RBridges more tha= n once. I don't particularly like "all ECMP paths" either. I think the clearest wor= ding is "all least cost paths" if you are talking about known unicast. (And= "all distribution tree paths" if you were talking about multi-destination = frames.) Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Sat, Apr 28, 2012 at 11:45 PM, Erik Nordmark > wrote: > On 4/27/12 5:12 PM, Tissa Senevirathne (tsenevir) wrote: >> >> Of course it is possible. The IS-IS topology table provide the >> information on all available ECMP paths to a specific destination >> when the egress RBRidge nickname is known. That is what TRILL unicast >> forwarding table all about. Not sure why you are saying it is not >> possible to know all ECMP paths. > > > You are talking about what Santosh called "all theoretically available > paths". Those can be determined from IS-IS. > > But the document talks about "all available paths" and I don't know > what that is supposed to mean. Do you have a succinct definition? > > What is clear to me is that there can be a subset of the paths that > are determined from IS-IS that would never be used, because no entropy > in a packet would every pick that path. > > Is the requirement in the document that the OAM solution should be > able to test those paths? > > >> What path among available paths to be selected for a specified is a >> local matter. That is what all about flow entropy discovery. Like I >> stated earlier how it is discovered is a framework and solution issue. > > > Agreed. > > >> If you need some reference how it is done in the MPLS world RFC 4379 >> is a good reference. > > > AFAIK MPLS doesn't have a locally defined ECMP hash function in every hop= . > TRILL does, which makes these aspects different. > > Regards, > Erik > > >> -----Original Message----- >> From: trill-bounces@ietf.org [mailto:tril= l-bounces@ietf.org] On >> Behalf Of Erik Nordmark >> Sent: Friday, April 27, 2012 4:07 PM >> To: Santosh Rajagopalan >> Cc: trill@ietf.org >> Subject: Re: [trill] TRILL OAM Requirements: available paths >> >> On 4/27/12 2:15 PM, Santosh Rajagopalan wrote: >>> >>> I agree, the wording needs to be tightened to say "all possible ecmp >>> paths" rather than "all available paths". An operator working out >>> R1-R2 communication is interested in all possible paths data traffic >>> could take rather than all theoretically available paths. >> >> >> The issue is that there is nothing in the TRILL dataplane nor IS-IS >> control plane which helps the operator determine that some paths >> (through RB121 and RB112 in the example) are not possible; the ECMP >> input and hashing is a completely local matter on each RBridge. >> >> It isn't useful to state a requirement around something that can't be >> determined. >> >> Erik >> >>> >>> >>> From: Erik Nordmark> >>> To: trill@ietf.org >>> Date: 04/27/2012 09:53 AM >>> Subject: [trill] TRILL OAM Requirements: available paths Sent by: >>> trill-bounces@ietf.org >>> -------------------------------------------------------------------- >>> -- >>> -- >>> >>> >>> >>> >>> Two requirements use the wording "all available paths." and "all >>> available ECMP paths.", respectively and I'm not sure I know what >>> that >> >> >>> means. >>> >>> Take the following example picture: >>> >>> R1 >>> / \ >>> / \ >>> / \ >>> / \ >>> / \ >>> RB11 RB12 >>> / \ / \ >>> / \ / \ >>> RB111 RB112 RB121 RB122 >>> \ \ / / >>> \ \ / / >>> \ \/ / >>> ------R2------ >>> >>> We can see that there are 4 paths with 3 hops to get from R1 to R2, >>> with two layers of ECMP decisions. But how many available paths are >> >> there? >>> >>> >>> Given that the RBridges make independent ECMP decisions, and how >>> they do that is a local matter, it could be the case that for any >>> packet, if R1 picks the left link, then R11 would also pick the left >>> link; if >>> R1 picks the right link, then R12 also picks the right link. >>> Thus there would be no packet (data or OAM) that would cause packets >>> between R1 and R2 to pass via RB112 or RB121. >>> >>> Even if we ignore that as unlikely, there is still the fact that R1 >>> can't easily tell how many (shortest) paths there might be between >>> it and R2. With single-level TRILL the LSDB could be used to tell, >>> but if >> >> >>> we ever go to multi-level that wouldn't be the case any more. >>> And even if R1 knows that there are 4 potential paths, it can't >>> format >> >> >>> a data packet (or format the flow entropy in an OAM packet) in such >>> a way that particular paths get chosen by downstream ECMP decisions. >>> >>> Thus for any notion of "all available paths" that make sense to me, >>> we'd need an OAM approach that can explore the topology one hop at a >>> time and at each hop explore all the possible ECMP choices. Using >>> the entropy doesn't help with this (but the entropy is critical for >>> following the path taken by a particular flow of data packets). >>> >>> Hence it would be good to clarify what the assumptions are behind >>> this >> >> >>> notion of all available paths. >>> >>> Thanks, >>> Erik >>> >>> _______________________________________________ >>> trill mailing list >>> trill@ietf.org >>> https://www.ietf.org/mailman/listinfo/trill >>> >>> >> >> _______________________________________________ >> trill mailing list >> trill@ietf.org >> https://www.ietf.org/mailman/listinfo/trill >> > > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill --_000_BA343C7BA78ED743B8A5E83749F7B1C20E7E1CSJEXCHMB06corpadb_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

Protocol should be based = on option 2 ie all ECMP paths.

 <= /p>

Thanks.

 

-Puneet

From: trill-bo= unces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of David M Bond
Sent: Monday, April 30, 2012 8:39 AM
To: Tissa Senevirathne (tsenevir)
Cc: Donald Eastlake; trill-bounces@ietf.org; trill@ietf.org
Subject: Re: [trill] TRILL OAM Requirements: available paths

 

Just a question coming from this conversation that I want to = clarify:

So we have 'all possible paths' (1) which could include non-leas= t cost paths and so of course we don't want to use this definition.<= br>
Then we have 'all ecmp paths' or 'all least cost paths' (2) whic= h MAY include paths never chosen by a transit Rbridge because of the local = hashing choices.

Then we have 'all the least cost paths which may be chosen given= the hashing implementation on the local Rbridges' (3).

I wonder if choice (2) is useful or do we only really care about= choice (3). For instance, if you have 16 equal cost paths from A to B and = your hashing only will ever use 2 of those paths do we care about reporting back ecmp paths that will never in practice be used? = Perhaps the definition should be tightened to only require determination of= all least cost paths that could be used given the local hashing implementa= tion. Or am I misunderstanding the conversation and is this already the point being made between theoretical = paths and least cost paths.

Thanks,
David

3D"Inactive"Tissa Senevirathne (tsenevir)" ---04/29/2012 11:43:07 PM---I like that Dona= ld.. We can use "all least cost paths", that is technically more = precise and represe

From: "Tissa Senevirathne (tsenevir)" <tsenevir@cisco.com>
To: "Donald Eastlake" <d3e3e3@gmail.com>, <trill@ie= tf.org>
Date: 04/29/2012 11:43 PM
Subject: Re: [trill] TRILL OAM Requirements: available paths=
Sent by: trill-bounces@ie= tf.org




I like that Donald.. We can use "= all least cost paths", that is technically more precise and represent = exactly what IS-IS does.

Thanks
Tissa

-----Original Message-----
From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of Donald Eastlake
Sent: Sunday, April 29, 2012 6:27 PM
To: trill@ietf.org
Subject: Re: [trill] TRILL OAM Requirements: available paths

I don't think the wording "all paths" should ever be used. If= you the it literally, it would even include paths that go through some RBr= idges more than once.

I don't particularly like "all ECMP paths" either. I think th= e clearest wording is "all least cost paths" if you are talking a= bout known unicast. (And "all distribution tree paths" if you wer= e talking about multi-destination frames.)

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com


On Sat, Apr 28, 2012 at 11:45 PM, Erik Nordmark <nordmark@acm.org> wrote:
> On 4/27/12 5:12 PM, Tissa Senevirathne (tsenevir) wrote:
>>
>> Of course it is possible. The IS-IS topology table provide the=
>> information on all available ECMP paths to a specific destinat= ion
>> when the egress RBRidge nickname is known. That is what TRILL = unicast
>> forwarding table all about. Not sure why you are saying it is = not
>> possible to know all ECMP paths.
>
>
> You are talking about what Santosh called "all theoretically = available
> paths". Those can be determined from IS-IS.
>
> But the document talks about "all available paths" and I= don't know
> what that is supposed to mean. Do you have a succinct definition?<= /tt>
>
> What is clear to me is that there can be a subset of the paths tha= t
> are determined from IS-IS that would never be used, because no ent= ropy
> in a packet would every pick that path.
>
> Is the requirement in the document that the OAM solution should be=
> able to test those paths?
>
>
>> What path among available paths to be selected for a specified= is a
>> local matter. That is what all about flow entropy discovery. L= ike I
>> stated earlier how it is discovered is a framework and solutio= n issue.
>
>
> Agreed.
>
>
>> If you need some reference how it is done in the MPLS world RF= C 4379
>> is a good reference.
>
>
> AFAIK MPLS doesn't have a locally defined ECMP hash function in ev= ery hop.
> TRILL does, which makes these aspects different.
>
> Regards,
>   Erik
>
>
>> -----Original Message-----
>> From: trill-bounces@= ietf.org [mailto:trill-bounce= s@ietf.org] On
>> Behalf Of Erik Nordmark
>> Sent: Friday, April 27, 2012 4:07 PM
>> To: Santosh Rajagopalan
>> Cc: trill@ietf.org<= br> >> Subject: Re: [trill] TRILL OAM Requirements: available paths
>>
>> On 4/27/12 2:15 PM, Santosh Rajagopalan wrote:
>>>
>>> I agree, the wording needs to be tightened to say "al= l possible ecmp
>>> paths" rather than "all available paths". A= n operator working out
>>> R1-R2 communication is interested in all possible paths da= ta traffic
>>> could take rather than all theoretically available paths.<= /tt>
>>
>>
>> The issue is that there is nothing in the TRILL dataplane nor = IS-IS
>> control plane which helps the operator determine that some pat= hs
>> (through RB121 and RB112 in the example) are not possible; the= ECMP
>> input and hashing is a completely local matter on each RBridge= .
>>
>> It isn't useful to state a requirement around something that c= an't be
>> determined.
>>
>>     Erik
>>
>>>
>>>
>>> From: Erik Nordmark<nordmark@acm.org>
>>> To: trill@ietf.org
>>> Date: 04/27/2012 09:53 AM
>>> Subject: [trill] TRILL OAM Requirements: available paths S= ent by:
>>> trill-bounces@ie= tf.org
>>> ----------------------------------------------------------= ----------
>>> --
>>> --
>>>
>>>
>>>
>>>
>>> Two requirements use the wording "all available paths= ." and "all
>>> available ECMP paths.", respectively and I'm not sure= I know what
>>> that
>>
>>
>>> means.
>>>
>>> Take the following example picture:
>>>
>>> R1
>>> / \
>>> / \
>>> / \
>>> / \
>>> / \
>>> RB11 RB12
>>> / \ / \
>>> / \ / \
>>> RB111 RB112 RB121 RB122
>>> \ \ / /
>>> \ \ / /
>>> \ \/ /
>>> ------R2------
>>>
>>> We can see that there are 4 paths with 3 hops to get from = R1 to R2,
>>> with two layers of ECMP decisions. But how many available = paths are
>>
>> there?
>>>
>>>
>>> Given that the RBridges make independent ECMP decisions, a= nd how
>>> they do that is a local matter, it could be the case that = for any
>>> packet, if R1 picks the left link, then R11 would also pic= k the left
>>> link; if
>>> R1 picks the right link, then R12 also picks the right lin= k.
>>> Thus there would be no packet (data or OAM) that would cau= se packets
>>> between R1 and R2 to pass via RB112 or RB121.
>>>
>>> Even if we ignore that as unlikely, there is still the fac= t that R1
>>> can't easily tell how many (shortest) paths there might be= between
>>> it and R2. With single-level TRILL the LSDB could be used = to tell,
>>> but if
>>
>>
>>> we ever go to multi-level that wouldn't be the case any mo= re.
>>> And even if R1 knows that there are 4 potential paths, it = can't
>>> format
>>
>>
>>> a data packet (or format the flow entropy in an OAM packet= ) in such
>>> a way that particular paths get chosen by downstream ECMP = decisions.
>>>
>>> Thus for any notion of "all available paths" tha= t make sense to me,
>>> we'd need an OAM approach that can explore the topology on= e hop at a
>>> time and at each hop explore all the possible ECMP choices= . Using
>>> the entropy doesn't help with this (but the entropy is cri= tical for
>>> following the path taken by a particular flow of data pack= ets).
>>>
>>> Hence it would be good to clarify what the assumptions are= behind
>>> this
>>
>>
>>> notion of all available paths.
>>>
>>> Thanks,
>>> Erik
>>>
>>> _______________________________________________
>>> trill mailing list
>>> trill@ietf.org<= br> >>> ht= tps://www.ietf.org/mailman/listinfo/trill
>>>
>>>
>>
>> _______________________________________________
>> trill mailing list
>> trill@ietf.org
>> https:= //www.ietf.org/mailman/listinfo/trill
>>
>
> _______________________________________________
> trill mailing list
> trill@ietf.org
> https://ww= w.ietf.org/mailman/listinfo/trill
_______________________________________________
trill mailing list
trill@ietf.org
https://www.iet= f.org/mailman/listinfo/trill
_______________________________________________
trill mailing list
trill@ietf.org
https://www.iet= f.org/mailman/listinfo/trill

--_000_BA343C7BA78ED743B8A5E83749F7B1C20E7E1CSJEXCHMB06corpadb_-- --_004_BA343C7BA78ED743B8A5E83749F7B1C20E7E1CSJEXCHMB06corpadb_ Content-Type: image/gif; name=image001.gif Content-Description: image001.gif Content-Disposition: inline; filename=image001.gif; size=105; creation-date="Mon, 30 Apr 2012 17:40:55 GMT"; modification-date="Mon, 30 Apr 2012 17:40:55 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --_004_BA343C7BA78ED743B8A5E83749F7B1C20E7E1CSJEXCHMB06corpadb_-- From sunny.rajagopalan@us.ibm.com Mon Apr 30 10:51:25 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54FED21F888F for ; Mon, 30 Apr 2012 10:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.398 X-Spam-Level: X-Spam-Status: No, score=-10.398 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 vIijnVg7qmI5 for ; Mon, 30 Apr 2012 10:51:23 -0700 (PDT) Received: from e39.co.us.ibm.com (e39.co.us.ibm.com [32.97.110.160]) by ietfa.amsl.com (Postfix) with ESMTP id 5730C21F888D for ; Mon, 30 Apr 2012 10:51:23 -0700 (PDT) Received: from /spool/local by e39.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 30 Apr 2012 11:51:22 -0600 Received: from d01dlp03.pok.ibm.com (9.56.224.17) by e39.co.us.ibm.com (192.168.1.139) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 30 Apr 2012 11:51:20 -0600 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id 917BFC9005E; Mon, 30 Apr 2012 13:51:17 -0400 (EDT) Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q3UHpI1B102026; Mon, 30 Apr 2012 13:51:18 -0400 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q3UHpHZQ015925; Mon, 30 Apr 2012 11:51:18 -0600 Received: from d03nm127.boulder.ibm.com (d03nm127.boulder.ibm.com [9.17.195.18]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q3UHpEXB015174; Mon, 30 Apr 2012 11:51:14 -0600 In-Reply-To: References: <4F9ACE0E.7030408@sonic.net> <4F9ACF05.9070302@acm.org><4F9B2697.8080401@acm.org><344037D7CFEFE84E97E9CC1F56C5F4A5010A2FFF@xmb-sjc-214.amer.cisco.com><4F9CB95E.4030902@acm.org> <344037D7CFEFE84E97E9CC1F56C5F4A5010A30CC@xmb-sjc-214.amer.cisco.com> To: "Puneet Agarwal" MIME-Version: 1.0 X-KeepSent: B7B6B9F4:9FA6024F-872579F0:0061DC7F; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: Santosh Rajagopalan Date: Mon, 30 Apr 2012 10:51:20 -0700 X-MIMETrack: Serialize by Router on D03NM127/03/M/IBM(Release 8.5.1FP2|March 17, 2010) at 04/30/2012 11:51:14, Serialize complete at 04/30/2012 11:51:14 Content-Type: multipart/related; boundary="=_related 00621AE0882579F0_=" X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12043017-4242-0000-0000-0000017FD7AA Cc: Donald Eastlake , "Tissa Senevirathne \(tsenevir\)" , "trill-bounces@ietf.org" , David M Bond , "trill@ietf.org" Subject: Re: [trill] TRILL OAM Requirements: available paths X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 17:51:25 -0000 This is a multipart message in MIME format. --=_related 00621AE0882579F0_= Content-Type: multipart/alternative; boundary="=_alternative 00621AE0882579F0_=" --=_alternative 00621AE0882579F0_= Content-Type: text/plain; charset="US-ASCII" I think OAM should only be concerned about option 3. Option 2 can easily be discovered by doing a route query using the cli or snmp etc. Given that the operator already knows that "route to RB X has 4 ecmps", she's probably interested in finding out how many of those will actually ever be used, which is (3). -- Sunny Rajagopalan From: "Puneet Agarwal" To: David M Bond/Bedford/IBM@IBMUS, "Tissa Senevirathne (tsenevir)" Cc: Donald Eastlake , "trill-bounces@ietf.org" , "trill@ietf.org" Date: 04/30/2012 10:45 AM Subject: Re: [trill] TRILL OAM Requirements: available paths Sent by: trill-bounces@ietf.org Protocol should be based on option 2 ie all ECMP paths. Thanks. -Puneet From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of David M Bond Sent: Monday, April 30, 2012 8:39 AM To: Tissa Senevirathne (tsenevir) Cc: Donald Eastlake; trill-bounces@ietf.org; trill@ietf.org Subject: Re: [trill] TRILL OAM Requirements: available paths Just a question coming from this conversation that I want to clarify: So we have 'all possible paths' (1) which could include non-least cost paths and so of course we don't want to use this definition. Then we have 'all ecmp paths' or 'all least cost paths' (2) which MAY include paths never chosen by a transit Rbridge because of the local hashing choices. Then we have 'all the least cost paths which may be chosen given the hashing implementation on the local Rbridges' (3). I wonder if choice (2) is useful or do we only really care about choice (3). For instance, if you have 16 equal cost paths from A to B and your hashing only will ever use 2 of those paths do we care about reporting back ecmp paths that will never in practice be used? Perhaps the definition should be tightened to only require determination of all least cost paths that could be used given the local hashing implementation. Or am I misunderstanding the conversation and is this already the point being made between theoretical paths and least cost paths. Thanks, David "Tissa Senevirathne (tsenevir)" ---04/29/2012 11:43:07 PM---I like that Donald.. We can use "all least cost paths", that is technically more precise and represe From: "Tissa Senevirathne (tsenevir)" To: "Donald Eastlake" , Date: 04/29/2012 11:43 PM Subject: Re: [trill] TRILL OAM Requirements: available paths Sent by: trill-bounces@ietf.org I like that Donald.. We can use "all least cost paths", that is technically more precise and represent exactly what IS-IS does. Thanks Tissa -----Original Message----- From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of Donald Eastlake Sent: Sunday, April 29, 2012 6:27 PM To: trill@ietf.org Subject: Re: [trill] TRILL OAM Requirements: available paths I don't think the wording "all paths" should ever be used. If you the it literally, it would even include paths that go through some RBridges more than once. I don't particularly like "all ECMP paths" either. I think the clearest wording is "all least cost paths" if you are talking about known unicast. (And "all distribution tree paths" if you were talking about multi-destination frames.) Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Sat, Apr 28, 2012 at 11:45 PM, Erik Nordmark wrote: > On 4/27/12 5:12 PM, Tissa Senevirathne (tsenevir) wrote: >> >> Of course it is possible. The IS-IS topology table provide the >> information on all available ECMP paths to a specific destination >> when the egress RBRidge nickname is known. That is what TRILL unicast >> forwarding table all about. Not sure why you are saying it is not >> possible to know all ECMP paths. > > > You are talking about what Santosh called "all theoretically available > paths". Those can be determined from IS-IS. > > But the document talks about "all available paths" and I don't know > what that is supposed to mean. Do you have a succinct definition? > > What is clear to me is that there can be a subset of the paths that > are determined from IS-IS that would never be used, because no entropy > in a packet would every pick that path. > > Is the requirement in the document that the OAM solution should be > able to test those paths? > > >> What path among available paths to be selected for a specified is a >> local matter. That is what all about flow entropy discovery. Like I >> stated earlier how it is discovered is a framework and solution issue. > > > Agreed. > > >> If you need some reference how it is done in the MPLS world RFC 4379 >> is a good reference. > > > AFAIK MPLS doesn't have a locally defined ECMP hash function in every hop. > TRILL does, which makes these aspects different. > > Regards, > Erik > > >> -----Original Message----- >> From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On >> Behalf Of Erik Nordmark >> Sent: Friday, April 27, 2012 4:07 PM >> To: Santosh Rajagopalan >> Cc: trill@ietf.org >> Subject: Re: [trill] TRILL OAM Requirements: available paths >> >> On 4/27/12 2:15 PM, Santosh Rajagopalan wrote: >>> >>> I agree, the wording needs to be tightened to say "all possible ecmp >>> paths" rather than "all available paths". An operator working out >>> R1-R2 communication is interested in all possible paths data traffic >>> could take rather than all theoretically available paths. >> >> >> The issue is that there is nothing in the TRILL dataplane nor IS-IS >> control plane which helps the operator determine that some paths >> (through RB121 and RB112 in the example) are not possible; the ECMP >> input and hashing is a completely local matter on each RBridge. >> >> It isn't useful to state a requirement around something that can't be >> determined. >> >> Erik >> >>> >>> >>> From: Erik Nordmark >>> To: trill@ietf.org >>> Date: 04/27/2012 09:53 AM >>> Subject: [trill] TRILL OAM Requirements: available paths Sent by: >>> trill-bounces@ietf.org >>> -------------------------------------------------------------------- >>> -- >>> -- >>> >>> >>> >>> >>> Two requirements use the wording "all available paths." and "all >>> available ECMP paths.", respectively and I'm not sure I know what >>> that >> >> >>> means. >>> >>> Take the following example picture: >>> >>> R1 >>> / \ >>> / \ >>> / \ >>> / \ >>> / \ >>> RB11 RB12 >>> / \ / \ >>> / \ / \ >>> RB111 RB112 RB121 RB122 >>> \ \ / / >>> \ \ / / >>> \ \/ / >>> ------R2------ >>> >>> We can see that there are 4 paths with 3 hops to get from R1 to R2, >>> with two layers of ECMP decisions. But how many available paths are >> >> there? >>> >>> >>> Given that the RBridges make independent ECMP decisions, and how >>> they do that is a local matter, it could be the case that for any >>> packet, if R1 picks the left link, then R11 would also pick the left >>> link; if >>> R1 picks the right link, then R12 also picks the right link. >>> Thus there would be no packet (data or OAM) that would cause packets >>> between R1 and R2 to pass via RB112 or RB121. >>> >>> Even if we ignore that as unlikely, there is still the fact that R1 >>> can't easily tell how many (shortest) paths there might be between >>> it and R2. With single-level TRILL the LSDB could be used to tell, >>> but if >> >> >>> we ever go to multi-level that wouldn't be the case any more. >>> And even if R1 knows that there are 4 potential paths, it can't >>> format >> >> >>> a data packet (or format the flow entropy in an OAM packet) in such >>> a way that particular paths get chosen by downstream ECMP decisions. >>> >>> Thus for any notion of "all available paths" that make sense to me, >>> we'd need an OAM approach that can explore the topology one hop at a >>> time and at each hop explore all the possible ECMP choices. Using >>> the entropy doesn't help with this (but the entropy is critical for >>> following the path taken by a particular flow of data packets). >>> >>> Hence it would be good to clarify what the assumptions are behind >>> this >> >> >>> notion of all available paths. >>> >>> Thanks, >>> Erik >>> >>> _______________________________________________ >>> trill mailing list >>> trill@ietf.org >>> https://www.ietf.org/mailman/listinfo/trill >>> >>> >> >> _______________________________________________ >> trill mailing list >> trill@ietf.org >> https://www.ietf.org/mailman/listinfo/trill >> > > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill --=_alternative 00621AE0882579F0_= Content-Type: text/html; charset="US-ASCII" I think OAM should only be concerned about option 3. Option 2 can easily be discovered by doing a route query using the cli or snmp etc. Given that the operator already knows that "route to RB X has 4 ecmps", she's probably interested in finding out how many of those will actually ever be used, which is (3).
--
Sunny Rajagopalan



From:        "Puneet Agarwal" <pagarwal@broadcom.com>
To:        David M Bond/Bedford/IBM@IBMUS, "Tissa Senevirathne (tsenevir)" <tsenevir@cisco.com>
Cc:        Donald Eastlake <d3e3e3@gmail.com>, "trill-bounces@ietf.org" <trill-bounces@ietf.org>, "trill@ietf.org" <trill@ietf.org>
Date:        04/30/2012 10:45 AM
Subject:        Re: [trill] TRILL OAM Requirements: available paths
Sent by:        trill-bounces@ietf.org



Protocol should be based on option 2 ie all ECMP paths.
 
Thanks.
 
-Puneet
From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of David M Bond
Sent: Monday, April 30, 2012 8:39 AM
To: Tissa Senevirathne (tsenevir)
Cc: Donald Eastlake; trill-bounces@ietf.org; trill@ietf.org
Subject: Re: [trill] TRILL OAM Requirements: available paths
 

Just a question coming from this conversation that I want to clarify:

So we have 'all possible paths' (1) which could include non-least cost paths and so of course we don't want to use this definition.

Then we have 'all ecmp paths' or 'all least cost paths' (2) which MAY include paths never chosen by a transit Rbridge because of the local hashing choices.

Then we have 'all the least cost paths which may be chosen given the hashing implementation on the local Rbridges' (3).

I wonder if choice (2) is useful or do we only really care about choice (3). For instance, if you have 16 equal cost paths from A to B and your hashing only will ever use 2 of those paths do we care about reporting back ecmp paths that will never in practice be used? Perhaps the definition should be tightened to only require determination of all least cost paths that could be used given the local hashing implementation. Or am I misunderstanding the conversation and is this already the point being made between theoretical paths and least cost paths.

Thanks,
David

Inactive hide details for "Tissa Senevirathne (tsenevir)" ---04/29/2012 11:43:07 PM---I like that Donald.. We can use "all leas"Tissa Senevirathne (tsenevir)" ---04/29/2012 11:43:07 PM---I like that Donald.. We can use "all least cost paths", that is technically more precise and represe

From: "Tissa Senevirathne (tsenevir)" <tsenevir@cisco.com>
To: "Donald Eastlake" <d3e3e3@gmail.com>, <trill@ietf.org>
Date: 04/29/2012 11:43 PM
Subject: Re: [trill] TRILL OAM Requirements: available paths
Sent by: trill-bounces@ietf.org





I like that Donald.. We can use "all least cost paths", that is technically more precise and represent exactly what IS-IS does.

Thanks
Tissa

-----Original Message-----
From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of Donald Eastlake
Sent: Sunday, April 29, 2012 6:27 PM
To: trill@ietf.org
Subject: Re: [trill] TRILL OAM Requirements: available paths

I don't think the wording "all paths" should ever be used. If you the it literally, it would even include paths that go through some RBridges more than once.

I don't particularly like "all ECMP paths" either. I think the clearest wording is "all least cost paths" if you are talking about known unicast. (And "all distribution tree paths" if you were talking about multi-destination frames.)

Thanks,
Donald
=============================
Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 USA
d3e3e3@gmail.com


On Sat, Apr 28, 2012 at 11:45 PM, Erik Nordmark <nordmark@acm.org> wrote:
> On 4/27/12 5:12 PM, Tissa Senevirathne (tsenevir) wrote:
>>
>> Of course it is possible. The IS-IS topology table provide the
>> information on all available ECMP paths to a specific destination
>> when the egress RBRidge nickname is known. That is what TRILL unicast
>> forwarding table all about. Not sure why you are saying it is not
>> possible to know all ECMP paths.
>
>
> You are talking about what Santosh called "all theoretically available
> paths". Those can be determined from IS-IS.
>
> But the document talks about "all available paths" and I don't know
> what that is supposed to mean. Do you have a succinct definition?
>
> What is clear to me is that there can be a subset of the paths that
> are determined from IS-IS that would never be used, because no entropy
> in a packet would every pick that path.
>
> Is the requirement in the document that the OAM solution should be
> able to test those paths?
>
>
>> What path among available paths to be selected for a specified is a
>> local matter. That is what all about flow entropy discovery. Like I
>> stated earlier how it is discovered is a framework and solution issue.
>
>
> Agreed.
>
>
>> If you need some reference how it is done in the MPLS world RFC 4379
>> is a good reference.
>
>
> AFAIK MPLS doesn't have a locally defined ECMP hash function in every hop.
> TRILL does, which makes these aspects different.
>
> Regards,
>   Erik
>
>
>> -----Original Message-----
>> From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On
>> Behalf Of Erik Nordmark
>> Sent: Friday, April 27, 2012 4:07 PM
>> To: Santosh Rajagopalan
>> Cc: trill@ietf.org
>> Subject: Re: [trill] TRILL OAM Requirements: available paths
>>
>> On 4/27/12 2:15 PM, Santosh Rajagopalan wrote:
>>>
>>> I agree, the wording needs to be tightened to say "all possible ecmp
>>> paths" rather than "all available paths". An operator working out
>>> R1-R2 communication is interested in all possible paths data traffic
>>> could take rather than all theoretically available paths.
>>
>>
>> The issue is that there is nothing in the TRILL dataplane nor IS-IS
>> control plane which helps the operator determine that some paths
>> (through RB121 and RB112 in the example) are not possible; the ECMP
>> input and hashing is a completely local matter on each RBridge.
>>
>> It isn't useful to state a requirement around something that can't be
>> determined.
>>
>>     Erik
>>
>>>
>>>
>>> From: Erik Nordmark<nordmark@acm.org>
>>> To: trill@ietf.org
>>> Date: 04/27/2012 09:53 AM
>>> Subject: [trill] TRILL OAM Requirements: available paths Sent by:
>>> trill-bounces@ietf.org
>>> --------------------------------------------------------------------
>>> --
>>> --
>>>
>>>
>>>
>>>
>>> Two requirements use the wording "all available paths." and "all
>>> available ECMP paths.", respectively and I'm not sure I know what
>>> that
>>
>>
>>> means.
>>>
>>> Take the following example picture:
>>>
>>> R1
>>> / \
>>> / \
>>> / \
>>> / \
>>> / \
>>> RB11 RB12
>>> / \ / \
>>> / \ / \
>>> RB111 RB112 RB121 RB122
>>> \ \ / /
>>> \ \ / /
>>> \ \/ /
>>> ------R2------
>>>
>>> We can see that there are 4 paths with 3 hops to get from R1 to R2,
>>> with two layers of ECMP decisions. But how many available paths are
>>
>> there?
>>>
>>>
>>> Given that the RBridges make independent ECMP decisions, and how
>>> they do that is a local matter, it could be the case that for any
>>> packet, if R1 picks the left link, then R11 would also pick the left
>>> link; if
>>> R1 picks the right link, then R12 also picks the right link.
>>> Thus there would be no packet (data or OAM) that would cause packets
>>> between R1 and R2 to pass via RB112 or RB121.
>>>
>>> Even if we ignore that as unlikely, there is still the fact that R1
>>> can't easily tell how many (shortest) paths there might be between
>>> it and R2. With single-level TRILL the LSDB could be used to tell,
>>> but if
>>
>>
>>> we ever go to multi-level that wouldn't be the case any more.
>>> And even if R1 knows that there are 4 potential paths, it can't
>>> format
>>
>>
>>> a data packet (or format the flow entropy in an OAM packet) in such
>>> a way that particular paths get chosen by downstream ECMP decisions.
>>>
>>> Thus for any notion of "all available paths" that make sense to me,
>>> we'd need an OAM approach that can explore the topology one hop at a
>>> time and at each hop explore all the possible ECMP choices. Using
>>> the entropy doesn't help with this (but the entropy is critical for
>>> following the path taken by a particular flow of data packets).
>>>
>>> Hence it would be good to clarify what the assumptions are behind
>>> this
>>
>>
>>> notion of all available paths.
>>>
>>> Thanks,
>>> Erik
>>>
>>> _______________________________________________
>>> trill mailing list
>>> trill@ietf.org
>>> https://www.ietf.org/mailman/listinfo/trill
>>>
>>>
>>
>> _______________________________________________
>> trill mailing list
>> trill@ietf.org
>> https://www.ietf.org/mailman/listinfo/trill
>>
>
> _______________________________________________
> trill mailing list
> trill@ietf.org
> https://www.ietf.org/mailman/listinfo/trill
_______________________________________________
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill
_______________________________________________
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill
_______________________________________________
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill
--=_alternative 00621AE0882579F0_=-- --=_related 00621AE0882579F0_= Content-Type: image/gif Content-ID: <_1_0C3A504C0C3A45BC00621AE0882579F0> Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --=_related 00621AE0882579F0_=-- From tsenevir@cisco.com Mon Apr 30 12:28:47 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6237021E8025; Mon, 30 Apr 2012 12:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.578 X-Spam-Level: X-Spam-Status: No, score=-7.578 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42] 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 VnVkixGMyz9i; Mon, 30 Apr 2012 12:28:42 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id E50D721E8024; Mon, 30 Apr 2012 12:28:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tsenevir@cisco.com; l=34557; q=dns/txt; s=iport; t=1335814121; x=1337023721; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=Jss9C+9mh90UhSpZ8QAqf/NKk3GJws4cMD/iJXTJVmw=; b=cK14eK6jp54Vu7WfAC8vlu1RYrCJrgVwHVDe9A1mBWRIqWgwPNLw6txq J+5dT8DPEq2m8TQ9jvqtcDfSOfmQOlc7+8FjAlueStYIZc0oojwRhZXb6 qGttJ24ATeanI1rGYdR1LXWRRcg+hQRqR313MvaS0vUzI8yg2f021XhsN 4=; X-Files: image001.gif : 105 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAKzmnk+rRDoI/2dsb2JhbABBA4JGrQ2DAIEHggkBAQEDAQEBAQIBBgYBCQkIAQI0CgsFBwQCAQgRAwEBAQEFAQICBhABBgEGAQEFEAEFBAUBHwkIAQEEEgEGAhMHh10DBgQBC5otliQNiU8EigyDbIJHYwSIZIQXgyCBd48rgxqBaYMI X-IronPort-AV: E=Sophos;i="4.75,505,1330905600"; d="gif'147?scan'147,208,217,147";a="39730214" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 30 Apr 2012 19:28:41 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3UJSf2l030768; Mon, 30 Apr 2012 19:28:41 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Apr 2012 12:28:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CD2707.72A7E56A" Date: Mon, 30 Apr 2012 12:28:39 -0700 Message-ID: <344037D7CFEFE84E97E9CC1F56C5F4A5010A32ED@xmb-sjc-214.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [trill] TRILL OAM Requirements: available paths Thread-Index: Ac0m53zq+kUrCWV1TDyrR4ibJA6ywQAGD0fQ References: <4F9ACE0E.7030408@sonic.net> <4F9ACF05.9070302@acm.org><4F9B2697.8080401@acm.org><344037D7CFEFE84E97E9CC1F56C5F4A5010A2FFF@xmb-sjc-214.amer.cisco.com><4F9CB95E.4030902@acm.org> <344037D7CFEFE84E97E9CC1F56C5F4A5010A30CC@xmb-sjc-214.amer.cisco.com> From: "Tissa Senevirathne (tsenevir)" To: "David M Bond" X-OriginalArrivalTime: 30 Apr 2012 19:28:40.0938 (UTC) FILETIME=[72E384A0:01CD2707] Cc: Donald Eastlake , trill-bounces@ietf.org, trill@ietf.org Subject: Re: [trill] TRILL OAM Requirements: available paths X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 19:28:47 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD2707.72A7E56A Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CD2707.72A7E56A" ------_=_NextPart_002_01CD2707.72A7E56A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Let me start from the basics. =20 1. TRILL is all about multiple active paths. 2. Multiple active paths are derived from least cost paths to a specific destinations. 3. Well defined and implemented Hashing algorithms provide an almost even distribution across all of the available least cost paths to a destination 4. If a given flow "x" does not map to a specific least cost path, does not map to a specific least cost path does not mean another flow "y" to the sam destination will not map to the that path.=20 5. Well implemented hashing algorithms provide even distribution of flows. 6. Hence it is important to have ability to test all available least cost paths to a destination. 7. It is an implementation defect, If there is an implementation out there which does not hash flows (over a longer sampling period) in to a specific "least cost path" of set of least cost paths to a destination, among all available "least cost paths" to that destination. =20 From: David M Bond [mailto:dmbond@us.ibm.com]=20 Sent: Monday, April 30, 2012 8:39 AM To: Tissa Senevirathne (tsenevir) Cc: Donald Eastlake; trill@ietf.org; trill-bounces@ietf.org Subject: Re: [trill] TRILL OAM Requirements: available paths =20 Just a question coming from this conversation that I want to clarify: So we have 'all possible paths' (1) which could include non-least cost paths and so of course we don't want to use this definition. Then we have 'all ecmp paths' or 'all least cost paths' (2) which MAY include paths never chosen by a transit Rbridge because of the local hashing choices. Then we have 'all the least cost paths which may be chosen given the hashing implementation on the local Rbridges' (3). I wonder if choice (2) is useful or do we only really care about choice (3). For instance, if you have 16 equal cost paths from A to B and your hashing only will ever use 2 of those paths do we care about reporting back ecmp paths that will never in practice be used? Perhaps the definition should be tightened to only require determination of all least cost paths that could be used given the local hashing implementation. Or am I misunderstanding the conversation and is this already the point being made between theoretical paths and least cost paths. Thanks, David "Tissa Senevirathne (tsenevir)" ---04/29/2012 11:43:07 PM---I like that Donald.. We can use "all least cost paths", that is technically more precise and represe From: "Tissa Senevirathne (tsenevir)" To: "Donald Eastlake" , Date: 04/29/2012 11:43 PM Subject: Re: [trill] TRILL OAM Requirements: available paths Sent by: trill-bounces@ietf.org ________________________________ I like that Donald.. We can use "all least cost paths", that is technically more precise and represent exactly what IS-IS does. Thanks Tissa -----Original Message----- From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of Donald Eastlake Sent: Sunday, April 29, 2012 6:27 PM To: trill@ietf.org Subject: Re: [trill] TRILL OAM Requirements: available paths I don't think the wording "all paths" should ever be used. If you the it literally, it would even include paths that go through some RBridges more than once. I don't particularly like "all ECMP paths" either. I think the clearest wording is "all least cost paths" if you are talking about known unicast. (And "all distribution tree paths" if you were talking about multi-destination frames.) Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Sat, Apr 28, 2012 at 11:45 PM, Erik Nordmark wrote: > On 4/27/12 5:12 PM, Tissa Senevirathne (tsenevir) wrote: >> >> Of course it is possible. The IS-IS topology table provide the=20 >> information on all available ECMP paths to a specific destination=20 >> when the egress RBRidge nickname is known. That is what TRILL unicast >> forwarding table all about. Not sure why you are saying it is not=20 >> possible to know all ECMP paths. > > > You are talking about what Santosh called "all theoretically available > paths". Those can be determined from IS-IS. > > But the document talks about "all available paths" and I don't know=20 > what that is supposed to mean. Do you have a succinct definition? > > What is clear to me is that there can be a subset of the paths that=20 > are determined from IS-IS that would never be used, because no entropy > in a packet would every pick that path. > > Is the requirement in the document that the OAM solution should be=20 > able to test those paths? > > >> What path among available paths to be selected for a specified is a=20 >> local matter. That is what all about flow entropy discovery. Like I=20 >> stated earlier how it is discovered is a framework and solution issue. > > > Agreed. > > >> If you need some reference how it is done in the MPLS world RFC 4379=20 >> is a good reference. > > > AFAIK MPLS doesn't have a locally defined ECMP hash function in every hop. > TRILL does, which makes these aspects different. > > Regards, > Erik > > >> -----Original Message----- >> From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On=20 >> Behalf Of Erik Nordmark >> Sent: Friday, April 27, 2012 4:07 PM >> To: Santosh Rajagopalan >> Cc: trill@ietf.org >> Subject: Re: [trill] TRILL OAM Requirements: available paths >> >> On 4/27/12 2:15 PM, Santosh Rajagopalan wrote: >>> >>> I agree, the wording needs to be tightened to say "all possible ecmp >>> paths" rather than "all available paths". An operator working out >>> R1-R2 communication is interested in all possible paths data traffic >>> could take rather than all theoretically available paths. >> >> >> The issue is that there is nothing in the TRILL dataplane nor IS-IS=20 >> control plane which helps the operator determine that some paths=20 >> (through RB121 and RB112 in the example) are not possible; the ECMP=20 >> input and hashing is a completely local matter on each RBridge. >> >> It isn't useful to state a requirement around something that can't be >> determined. >> >> Erik >> >>> >>> >>> From: Erik Nordmark >>> To: trill@ietf.org >>> Date: 04/27/2012 09:53 AM >>> Subject: [trill] TRILL OAM Requirements: available paths Sent by: >>> trill-bounces@ietf.org >>> -------------------------------------------------------------------- >>> -- >>> -- >>> >>> >>> >>> >>> Two requirements use the wording "all available paths." and "all=20 >>> available ECMP paths.", respectively and I'm not sure I know what=20 >>> that >> >> >>> means. >>> >>> Take the following example picture: >>> >>> R1 >>> / \ >>> / \ >>> / \ >>> / \ >>> / \ >>> RB11 RB12 >>> / \ / \ >>> / \ / \ >>> RB111 RB112 RB121 RB122 >>> \ \ / / >>> \ \ / / >>> \ \/ / >>> ------R2------ >>> >>> We can see that there are 4 paths with 3 hops to get from R1 to R2,=20 >>> with two layers of ECMP decisions. But how many available paths are >> >> there? >>> >>> >>> Given that the RBridges make independent ECMP decisions, and how=20 >>> they do that is a local matter, it could be the case that for any=20 >>> packet, if R1 picks the left link, then R11 would also pick the left >>> link; if >>> R1 picks the right link, then R12 also picks the right link. >>> Thus there would be no packet (data or OAM) that would cause packets >>> between R1 and R2 to pass via RB112 or RB121. >>> >>> Even if we ignore that as unlikely, there is still the fact that R1=20 >>> can't easily tell how many (shortest) paths there might be between=20 >>> it and R2. With single-level TRILL the LSDB could be used to tell,=20 >>> but if >> >> >>> we ever go to multi-level that wouldn't be the case any more. >>> And even if R1 knows that there are 4 potential paths, it can't=20 >>> format >> >> >>> a data packet (or format the flow entropy in an OAM packet) in such=20 >>> a way that particular paths get chosen by downstream ECMP decisions. >>> >>> Thus for any notion of "all available paths" that make sense to me,=20 >>> we'd need an OAM approach that can explore the topology one hop at a >>> time and at each hop explore all the possible ECMP choices. Using=20 >>> the entropy doesn't help with this (but the entropy is critical for=20 >>> following the path taken by a particular flow of data packets). >>> >>> Hence it would be good to clarify what the assumptions are behind=20 >>> this >> >> >>> notion of all available paths. >>> >>> Thanks, >>> Erik >>> >>> _______________________________________________ >>> trill mailing list >>> trill@ietf.org >>> https://www.ietf.org/mailman/listinfo/trill >>> >>> >> >> _______________________________________________ >> trill mailing list >> trill@ietf.org >> https://www.ietf.org/mailman/listinfo/trill >> > > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill ------_=_NextPart_002_01CD2707.72A7E56A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Let me start from the basics.

 

1.       = TRILL is all about multiple active paths.

2.       = Multiple active paths are derived from least cost paths to a specific = destinations.

3.       = Well defined and implemented Hashing algorithms provide an almost = even distribution across all of the available least cost paths to a = destination

4.       = If a given flow “x” does not map to  a specific = least cost path, does not map to a specific least cost path does not = mean another flow “y” to the sam destination will not map to = the that path.

5.       = Well implemented hashing algorithms provide even distribution of = flows.

6.       = Hence it is important to have ability to test all available least = cost paths to a destination.

7.       = It is an implementation defect, If there is an implementation out = there which does not hash flows (over a longer sampling period)  in = to a specific “least cost path” of set of least cost paths = to a destination, among all available “least cost paths” to = that destination.

 

From:= = David M Bond [mailto:dmbond@us.ibm.com]
Sent: Monday, April = 30, 2012 8:39 AM
To: Tissa Senevirathne = (tsenevir)
Cc: Donald Eastlake; trill@ietf.org; = trill-bounces@ietf.org
Subject: Re: [trill] TRILL OAM = Requirements: available paths

 

Just a = question coming from this conversation that I want to = clarify:

So we have = 'all possible paths' (1) which could include non-least cost paths and so = of course we don't want to use this definition.

Then we have = 'all ecmp paths' or 'all least cost paths' (2) which MAY include paths = never chosen by a transit Rbridge because of the local hashing = choices.

Then we have = 'all the least cost paths which may be chosen given the hashing = implementation on the local Rbridges' (3).

I wonder if = choice (2) is useful or do we only really care about choice (3). For = instance, if you have 16 equal cost paths from A to B and your hashing = only will ever use 2 of those paths do we care about reporting back ecmp = paths that will never in practice be used? Perhaps the definition should = be tightened to only require determination of all least cost paths that = could be used given the local hashing implementation. Or am I = misunderstanding the conversation and is this already the point being = made between theoretical paths and least cost paths.

Thanks,
David<= br>
3D"Inactive"Tissa Senevirathne (tsenevir)" ---04/29/2012 11:43:07 PM---I = like that Donald.. We can use "all least cost paths", that is = technically more precise and represe

= From: "Tissa = Senevirathne (tsenevir)" <tsenevir@cisco.com>
<= span = style=3D'font-size:7.5pt;font-family:"Arial","sans-serif";color:#5F5F5F'>= To: "Donald = Eastlake" <d3e3e3@gmail.com>, <trill@ietf.org>
= Date: 04/29/2012 = 11:43 PM
= Subject: Re: [trill] = TRILL OAM Requirements: available paths
= Sent by: trill-bounces@ietf.org<= o:p>




I like that Donald.. We can use "all = least cost paths", that is technically more precise and represent = exactly what IS-IS does.

Thanks
Tissa

-----Original = Message-----
From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org]= On Behalf Of Donald Eastlake
Sent: Sunday, April 29, 2012 = 6:27 PM
To: trill@ietf.org
Subject: = Re: [trill] TRILL OAM Requirements: available paths

I = don't think the wording "all paths" should ever be used. If = you the it literally, it would even include paths that go through some = RBridges more than once.

I don't particularly like = "all ECMP paths" either. I think the clearest wording is = "all least cost paths" if you are talking about known unicast. = (And "all distribution tree paths" if you were talking about = multi-destination = frames.)

Thanks,
Donald
=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
 Donald E. Eastlake 3rd   +1-508-333-2270 = (cell)
 155 Beaver Street, Milford, MA 01757 = USA
 d3e3e3@gmail.com


On Sat, Apr 28, 2012 at 11:45 PM, Erik Nordmark <nordmark@acm.org> = wrote:
> On 4/27/12 5:12 PM, Tissa Senevirathne = (tsenevir) wrote:
>>
>> Of course it = is possible. The IS-IS topology table provide the
>> = information on all available ECMP paths to a specific destination =
>> when the egress RBRidge nickname is known. That is = what TRILL unicast
>> forwarding table all about. Not = sure why you are saying it is not
>> possible to know = all ECMP paths.
>
>
> You = are talking about what Santosh called "all theoretically available =
> paths". Those can be determined from = IS-IS.
>
> But the document talks about = "all available paths" and I don't know
> what = that is supposed to mean. Do you have a succinct = definition?
>
> What is clear to me is = that there can be a subset of the paths that
> are = determined from IS-IS that would never be used, because no entropy =
> in a packet would every pick that = path.
>
> Is the requirement in the = document that the OAM solution should be
> able to test = those paths?
>
>
>> What = path among available paths to be selected for a specified is a =
>> local matter. That is what all about flow entropy = discovery. Like I
>> stated earlier how it is = discovered is a framework and solution = issue.
>
>
> = Agreed.
>
>
>> If you = need some reference how it is done in the MPLS world RFC 4379 =
>> is a good = reference.
>
>
> AFAIK MPLS = doesn't have a locally defined ECMP hash function in every = hop.
> TRILL does, which makes these aspects = different.
>
> Regards,
> =   Erik
>
>
>> = -----Original Message-----
>> From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org]= On
>> Behalf Of Erik Nordmark
>> = Sent: Friday, April 27, 2012 4:07 PM
>> To: Santosh = Rajagopalan
>> Cc: trill@ietf.org
>> = Subject: Re: [trill] TRILL OAM Requirements: available = paths
>>
>> On 4/27/12 2:15 PM, = Santosh Rajagopalan = wrote:
>>>
>>> I agree, the = wording needs to be tightened to say "all possible ecmp =
>>> paths" rather than "all available = paths". An operator working out
>>> R1-R2 = communication is interested in all possible paths data traffic =
>>> could take rather than all theoretically = available = paths.
>>
>>
>> = The issue is that there is nothing in the TRILL dataplane nor IS-IS =
>> control plane which helps the operator determine = that some paths
>> (through RB121 and RB112 in the = example) are not possible; the ECMP
>> input and = hashing is a completely local matter on each = RBridge.
>>
>> It isn't useful to = state a requirement around something that can't be
>> = determined.
>>
>>     = Erik
>>
>>>
>>&g= t;
>>> From: Erik Nordmark<nordmark@acm.org>
>= ;>> To: trill@ietf.org
>>>= ; Date: 04/27/2012 09:53 AM
>>> Subject: [trill] = TRILL OAM Requirements: available paths Sent = by:
>>> trill-bounces@ietf.org>>> = --------------------------------------------------------------------=
>>> --
>>> = --
>>>
>>>
>>= >
>>>
>>> Two requirements = use the wording "all available paths." and "all =
>>> available ECMP paths.", respectively and = I'm not sure I know what
>>> = that
>>
>>
>>> = means.
>>>
>>> Take the = following example = picture:
>>>
>>> = R1
>>> / \
>>> / = \
>>> / \
>>> / = \
>>> / \
>>> RB11 = RB12
>>> / \ / \
>>> / \ / = \
>>> RB111 RB112 RB121 = RB122
>>> \ \ / /
>>> \ \ / = /
>>> \ \/ /
>>> = ------R2------
>>>
>>> We can = see that there are 4 paths with 3 hops to get from R1 to R2, =
>>> with two layers of ECMP decisions. But how = many available paths are
>>
>> = there?
>>>
>>>
>= >> Given that the RBridges make independent ECMP decisions, and = how
>>> they do that is a local matter, it could = be the case that for any
>>> packet, if R1 picks = the left link, then R11 would also pick the left =
>>> link; if
>>> R1 picks the = right link, then R12 also picks the right link.
>>> = Thus there would be no packet (data or OAM) that would cause packets =
>>> between R1 and R2 to pass via RB112 or = RB121.
>>>
>>> Even if we = ignore that as unlikely, there is still the fact that R1 =
>>> can't easily tell how many (shortest) paths = there might be between
>>> it and R2. With = single-level TRILL the LSDB could be used to tell, =
>>> but = if
>>
>>
>>> we = ever go to multi-level that wouldn't be the case any = more.
>>> And even if R1 knows that there are 4 = potential paths, it can't
>>> = format
>>
>>
>>>= a data packet (or format the flow entropy in an OAM packet) in such =
>>> a way that particular paths get chosen by = downstream ECMP = decisions.
>>>
>>> Thus for = any notion of "all available paths" that make sense to me, =
>>> we'd need an OAM approach that can explore the = topology one hop at a
>>> time and at each hop = explore all the possible ECMP choices. Using
>>> = the entropy doesn't help with this (but the entropy is critical for =
>>> following the path taken by a particular flow = of data packets).
>>>
>>> = Hence it would be good to clarify what the assumptions are behind =
>>> = this
>>
>>
>>> = notion of all available = paths.
>>>
>>> = Thanks,
>>> = Erik
>>>
>>> = _______________________________________________
>>> = trill mailing list
>>> trill@ietf.org
>>>= ; https://www.ietf.org= /mailman/listinfo/trill
>>>
>>= >
>>
>> = _______________________________________________
>> = trill mailing list
>> trill@ietf.org
>> = https://www.ietf.org= /mailman/listinfo/trill
>>
>> = _______________________________________________
> trill = mailing list
> trill@ietf.org
> https://www.ietf.org= /mailman/listinfo/trill
_________________________________= ______________
trill mailing list
trill@ietf.org
https://www.ietf.org= /mailman/listinfo/trill
_________________________________= ______________
trill mailing list
trill@ietf.org
https://www.ietf.org= /mailman/listinfo/trill

------_=_NextPart_002_01CD2707.72A7E56A-- ------_=_NextPart_001_01CD2707.72A7E56A Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.gif Content-Location: image001.gif R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 ------_=_NextPart_001_01CD2707.72A7E56A-- From sunny.rajagopalan@us.ibm.com Mon Apr 30 13:04:55 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B5511E8089 for ; Mon, 30 Apr 2012 13:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.431 X-Spam-Level: X-Spam-Status: No, score=-10.431 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 gI8OSmjq5HJj for ; Mon, 30 Apr 2012 13:04:53 -0700 (PDT) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by ietfa.amsl.com (Postfix) with ESMTP id 80D5C21F866A for ; Mon, 30 Apr 2012 13:04:52 -0700 (PDT) Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 30 Apr 2012 16:04:50 -0400 Received: from d01dlp02.pok.ibm.com (9.56.224.85) by e9.ny.us.ibm.com (192.168.1.109) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 30 Apr 2012 16:04:47 -0400 Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id ACB866E805D; Mon, 30 Apr 2012 16:04:46 -0400 (EDT) Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q3UK4ifY060252; Mon, 30 Apr 2012 16:04:45 -0400 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q3UK4WLR021395; Mon, 30 Apr 2012 14:04:36 -0600 Received: from d03nm127.boulder.ibm.com (d03nm127.boulder.ibm.com [9.17.195.18]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q3UK4N02020732; Mon, 30 Apr 2012 14:04:29 -0600 In-Reply-To: <344037D7CFEFE84E97E9CC1F56C5F4A5010A32ED@xmb-sjc-214.amer.cisco.com> References: <4F9ACE0E.7030408@sonic.net> <4F9ACF05.9070302@acm.org><4F9B2697.8080401@acm.org><344037D7CFEFE84E97E9CC1F56C5F4A5010A2FFF@xmb-sjc-214.amer.cisco.com><4F9CB95E.4030902@acm.org> <344037D7CFEFE84E97E9CC1F56C5F4A5010A30CC@xmb-sjc-214.amer.cisco.com> <344037D7CFEFE84E97E9CC1F56C5F4A5010A32ED@xmb-sjc-214.amer.cisco.com> To: "Tissa Senevirathne (tsenevir)" MIME-Version: 1.0 X-KeepSent: 8B52FAF1:05272CE8-872579F0:006CEAF8; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: Santosh Rajagopalan Date: Mon, 30 Apr 2012 13:04:34 -0700 X-MIMETrack: Serialize by Router on D03NM127/03/M/IBM(Release 8.5.1FP2|March 17, 2010) at 04/30/2012 14:04:28, Serialize complete at 04/30/2012 14:04:28 Content-Type: multipart/related; boundary="=_related 006E4DAD882579F0_=" X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12043020-7182-0000-0000-000001644858 Cc: Donald Eastlake , trill-bounces@ietf.org, David M Bond , trill@ietf.org Subject: Re: [trill] TRILL OAM Requirements: available paths X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 20:04:55 -0000 This is a multipart message in MIME format. --=_related 006E4DAD882579F0_= Content-Type: multipart/alternative; boundary="=_alternative 006E4DAE882579F0_=" --=_alternative 006E4DAE882579F0_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 VGlzc2EsDQpIYXNoIHBvbGFyaXphdGlvbiBjYW4gcmVzdWx0IGluIHNvbWUgb2YgdGhlIGVjbXAg cGF0aHMgYmVpbmcgdW51dGlsaXplZC4gDQpJbiBFcmljJ3MgZXhhbXBsZToNCg0KDQogICAgICAg ICAgICAgICAgUjENCiAgICAgICAgICAgICAgIC8gIFwNCiAgICAgICAgICAgICAgLyAgICBcDQog ICAgICAgICAgICAgLyAgICAgIFwNCiAgICAgICAgICAgIC8gICAgICAgIFwNCiAgICAgICAgICAg LyAgICAgICAgICBcDQogICAgICAgIFJCMTEgICAgICAgICAgUkIxMg0KICAgICAgICAvICBcICAg ICAgICAgIC8gIFwNCiAgICAgICAvICAgIFwgICAgICAgIC8gICAgXA0KICAgIFJCMTExICBSQjEx MiAgUkIxMjEgIFJCMTIyDQogICAgICAgXCAgICAgIFwgICAgLyAgICAgIC8NCiAgICAgICAgXCAg ICAgIFwgIC8gICAgICAvDQogICAgICAgICBcICAgICAgXC8gICAgICAvDQogICAgICAgICAgLS0t LS0tUjItLS0tLS0NCg0KSWYgUjEgYW5kIFJCMTIgdXNlIHRoZSBzYW1lIGhhc2ggcG9seW5vbWlh bCAmIHNlZWQsIHRoZW4gKmFsbCogZmxvd3Mgd2hpY2ggDQphcnJpdmUgYXQgUkIxMiB3aWxsIGdv IGFsb25nIHRoZSBsaW5rIHRvIFJCMTIyIC0gdGhlIGxpbmsgdG8gUkIxMjEgZnJvbSANClJCMTIg d2lsbCBuZXZlciBiZSB1c2VkLiBUaGUgT0FNIHRvb2wgc2hvdWxkIGFsbG93IHVzIHRvIGZpZ3Vy ZSBvdXQgdGhpcyANCmlzIGhhcHBlbmluZywgaW5zdGVhZCBvZiBnaXZpbmcgdXMgcmVkdW5kYW50 IGluZm9ybWF0aW9uIGFscmVhZHkgYXZhaWxhYmxlIA0KaW4gSVNJUyBsc2RiLg0KSSB3b3VsZCBo ZXNpdGF0ZSB0byBjYWxsIHRoaXMgYSBkZWZlY3QuIFdoaWxlIGl0IGlzIHRydWUgdGhhdCBhIGxv dCBvZiANCmFzaWNzIGhhdmUgY291bnRlcm1lYXN1cmVzIGZvciB0aGlzICh1c3VhbGx5IGJ5IGlu Y2x1ZGluZyBhIHJhbmRvbSBzZWVkIGFzIA0KaW5wdXQgdG8gdGhlIGhhc2ggcG9seW5vbWlhbCks IHlvdSBjYW5ub3QgcnVsZSB0aGlzIG91dCAxMDAlLiBQbGVhc2UgbG9vayANCmF0IHRoaXMgZG9j dW1lbnRhdGlvbiBmcm9tIGEgd2VsbCBrbm93biBuZXR3b3JraW5nIGNvbXBhbnkgOy0pDQpodHRw Oi8vd3d3LmNpc2NvLmNvbS9lbi9VUy9kb2NzL2lvcy8xMl80dC9pcF9tY2FzdC9jb25maWd1cmF0 aW9uL2d1aWRlL21jdGxzcGx0Lmh0bWwjd3AxMDY0NTAxIA0KDQoNCi0tDQpTdW5ueQ0KDQoNCg0K DQpGcm9tOiAgICJUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKSIgPHRzZW5ldmlyQGNpc2Nv LmNvbT4NClRvOiAgICAgRGF2aWQgTSBCb25kL0JlZGZvcmQvSUJNQElCTVVTDQpDYzogICAgIERv bmFsZCBFYXN0bGFrZSA8ZDNlM2UzQGdtYWlsLmNvbT4sIHRyaWxsLWJvdW5jZXNAaWV0Zi5vcmcs IA0KdHJpbGxAaWV0Zi5vcmcNCkRhdGU6ICAgMDQvMzAvMjAxMiAxMjoyOSBQTQ0KU3ViamVjdDog ICAgICAgIFJlOiBbdHJpbGxdIFRSSUxMIE9BTSBSZXF1aXJlbWVudHM6IGF2YWlsYWJsZSBwYXRo cw0KU2VudCBieTogICAgICAgIHRyaWxsLWJvdW5jZXNAaWV0Zi5vcmcNCg0KDQoNCkxldCBtZSBz dGFydCBmcm9tIHRoZSBiYXNpY3MuDQogDQoxLiAgICAgICBUUklMTCBpcyBhbGwgYWJvdXQgbXVs dGlwbGUgYWN0aXZlIHBhdGhzLg0KMi4gICAgICAgTXVsdGlwbGUgYWN0aXZlIHBhdGhzIGFyZSBk ZXJpdmVkIGZyb20gbGVhc3QgY29zdCBwYXRocyB0byBhIA0Kc3BlY2lmaWMgZGVzdGluYXRpb25z Lg0KMy4gICAgICAgV2VsbCBkZWZpbmVkIGFuZCBpbXBsZW1lbnRlZCBIYXNoaW5nIGFsZ29yaXRo bXMgcHJvdmlkZSBhbiBhbG1vc3QgDQpldmVuIGRpc3RyaWJ1dGlvbiBhY3Jvc3MgYWxsIG9mIHRo ZSBhdmFpbGFibGUgbGVhc3QgY29zdCBwYXRocyB0byBhIA0KZGVzdGluYXRpb24NCjQuICAgICAg IElmIGEgZ2l2ZW4gZmxvdyDigJx44oCdIGRvZXMgbm90IG1hcCB0byAgYSBzcGVjaWZpYyBsZWFz dCBjb3N0IHBhdGgsIA0KZG9lcyBub3QgbWFwIHRvIGEgc3BlY2lmaWMgbGVhc3QgY29zdCBwYXRo IGRvZXMgbm90IG1lYW4gYW5vdGhlciBmbG93IOKAnHnigJ0gDQp0byB0aGUgc2FtIGRlc3RpbmF0 aW9uIHdpbGwgbm90IG1hcCB0byB0aGUgdGhhdCBwYXRoLiANCjUuICAgICAgIFdlbGwgaW1wbGVt ZW50ZWQgaGFzaGluZyBhbGdvcml0aG1zIHByb3ZpZGUgZXZlbiBkaXN0cmlidXRpb24gb2YgDQpm bG93cy4NCjYuICAgICAgIEhlbmNlIGl0IGlzIGltcG9ydGFudCB0byBoYXZlIGFiaWxpdHkgdG8g dGVzdCBhbGwgYXZhaWxhYmxlIGxlYXN0IA0KY29zdCBwYXRocyB0byBhIGRlc3RpbmF0aW9uLg0K Ny4gICAgICAgSXQgaXMgYW4gaW1wbGVtZW50YXRpb24gZGVmZWN0LCBJZiB0aGVyZSBpcyBhbiBp bXBsZW1lbnRhdGlvbiBvdXQgDQp0aGVyZSB3aGljaCBkb2VzIG5vdCBoYXNoIGZsb3dzIChvdmVy IGEgbG9uZ2VyIHNhbXBsaW5nIHBlcmlvZCkgIGluIHRvIGEgDQpzcGVjaWZpYyDigJxsZWFzdCBj b3N0IHBhdGjigJ0gb2Ygc2V0IG9mIGxlYXN0IGNvc3QgcGF0aHMgdG8gYSBkZXN0aW5hdGlvbiwg DQphbW9uZyBhbGwgYXZhaWxhYmxlIOKAnGxlYXN0IGNvc3QgcGF0aHPigJ0gdG8gdGhhdCBkZXN0 aW5hdGlvbi4NCiANCkZyb206IERhdmlkIE0gQm9uZCBbbWFpbHRvOmRtYm9uZEB1cy5pYm0uY29t XSANClNlbnQ6IE1vbmRheSwgQXByaWwgMzAsIDIwMTIgODozOSBBTQ0KVG86IFRpc3NhIFNlbmV2 aXJhdGhuZSAodHNlbmV2aXIpDQpDYzogRG9uYWxkIEVhc3RsYWtlOyB0cmlsbEBpZXRmLm9yZzsg dHJpbGwtYm91bmNlc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFt0cmlsbF0gVFJJTEwgT0FNIFJl cXVpcmVtZW50czogYXZhaWxhYmxlIHBhdGhzDQogDQpKdXN0IGEgcXVlc3Rpb24gY29taW5nIGZy b20gdGhpcyBjb252ZXJzYXRpb24gdGhhdCBJIHdhbnQgdG8gY2xhcmlmeToNCg0KU28gd2UgaGF2 ZSAnYWxsIHBvc3NpYmxlIHBhdGhzJyAoMSkgd2hpY2ggY291bGQgaW5jbHVkZSBub24tbGVhc3Qg Y29zdCANCnBhdGhzIGFuZCBzbyBvZiBjb3Vyc2Ugd2UgZG9uJ3Qgd2FudCB0byB1c2UgdGhpcyBk ZWZpbml0aW9uLg0KDQpUaGVuIHdlIGhhdmUgJ2FsbCBlY21wIHBhdGhzJyBvciAnYWxsIGxlYXN0 IGNvc3QgcGF0aHMnICgyKSB3aGljaCBNQVkgDQppbmNsdWRlIHBhdGhzIG5ldmVyIGNob3NlbiBi eSBhIHRyYW5zaXQgUmJyaWRnZSBiZWNhdXNlIG9mIHRoZSBsb2NhbCANCmhhc2hpbmcgY2hvaWNl cy4NCg0KVGhlbiB3ZSBoYXZlICdhbGwgdGhlIGxlYXN0IGNvc3QgcGF0aHMgd2hpY2ggbWF5IGJl IGNob3NlbiBnaXZlbiB0aGUgDQpoYXNoaW5nIGltcGxlbWVudGF0aW9uIG9uIHRoZSBsb2NhbCBS YnJpZGdlcycgKDMpLg0KDQpJIHdvbmRlciBpZiBjaG9pY2UgKDIpIGlzIHVzZWZ1bCBvciBkbyB3 ZSBvbmx5IHJlYWxseSBjYXJlIGFib3V0IGNob2ljZSANCigzKS4gRm9yIGluc3RhbmNlLCBpZiB5 b3UgaGF2ZSAxNiBlcXVhbCBjb3N0IHBhdGhzIGZyb20gQSB0byBCIGFuZCB5b3VyIA0KaGFzaGlu ZyBvbmx5IHdpbGwgZXZlciB1c2UgMiBvZiB0aG9zZSBwYXRocyBkbyB3ZSBjYXJlIGFib3V0IHJl cG9ydGluZyANCmJhY2sgZWNtcCBwYXRocyB0aGF0IHdpbGwgbmV2ZXIgaW4gcHJhY3RpY2UgYmUg dXNlZD8gUGVyaGFwcyB0aGUgDQpkZWZpbml0aW9uIHNob3VsZCBiZSB0aWdodGVuZWQgdG8gb25s eSByZXF1aXJlIGRldGVybWluYXRpb24gb2YgYWxsIGxlYXN0IA0KY29zdCBwYXRocyB0aGF0IGNv dWxkIGJlIHVzZWQgZ2l2ZW4gdGhlIGxvY2FsIGhhc2hpbmcgaW1wbGVtZW50YXRpb24uIE9yIA0K YW0gSSBtaXN1bmRlcnN0YW5kaW5nIHRoZSBjb252ZXJzYXRpb24gYW5kIGlzIHRoaXMgYWxyZWFk eSB0aGUgcG9pbnQgYmVpbmcgDQptYWRlIGJldHdlZW4gdGhlb3JldGljYWwgcGF0aHMgYW5kIGxl YXN0IGNvc3QgcGF0aHMuDQoNClRoYW5rcywNCkRhdmlkDQoNCiJUaXNzYSBTZW5ldmlyYXRobmUg KHRzZW5ldmlyKSIgLS0tMDQvMjkvMjAxMiAxMTo0MzowNyBQTS0tLUkgbGlrZSB0aGF0IA0KRG9u YWxkLi4gV2UgY2FuIHVzZSAiYWxsIGxlYXN0IGNvc3QgcGF0aHMiLCB0aGF0IGlzIHRlY2huaWNh bGx5IG1vcmUgDQpwcmVjaXNlIGFuZCByZXByZXNlDQoNCkZyb206ICJUaXNzYSBTZW5ldmlyYXRo bmUgKHRzZW5ldmlyKSIgPHRzZW5ldmlyQGNpc2NvLmNvbT4NClRvOiAiRG9uYWxkIEVhc3RsYWtl IiA8ZDNlM2UzQGdtYWlsLmNvbT4sIDx0cmlsbEBpZXRmLm9yZz4NCkRhdGU6IDA0LzI5LzIwMTIg MTE6NDMgUE0NClN1YmplY3Q6IFJlOiBbdHJpbGxdIFRSSUxMIE9BTSBSZXF1aXJlbWVudHM6IGF2 YWlsYWJsZSBwYXRocw0KU2VudCBieTogdHJpbGwtYm91bmNlc0BpZXRmLm9yZw0KDQoNCg0KDQpJ IGxpa2UgdGhhdCBEb25hbGQuLiBXZSBjYW4gdXNlICJhbGwgbGVhc3QgY29zdCBwYXRocyIsIHRo YXQgaXMgDQp0ZWNobmljYWxseSBtb3JlIHByZWNpc2UgYW5kIHJlcHJlc2VudCBleGFjdGx5IHdo YXQgSVMtSVMgZG9lcy4NCg0KVGhhbmtzDQpUaXNzYQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogdHJpbGwtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnRyaWxsLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiANCkRvbmFsZCBFYXN0bGFrZQ0KU2VudDogU3VuZGF5LCBB cHJpbCAyOSwgMjAxMiA2OjI3IFBNDQpUbzogdHJpbGxAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBb dHJpbGxdIFRSSUxMIE9BTSBSZXF1aXJlbWVudHM6IGF2YWlsYWJsZSBwYXRocw0KDQpJIGRvbid0 IHRoaW5rIHRoZSB3b3JkaW5nICJhbGwgcGF0aHMiIHNob3VsZCBldmVyIGJlIHVzZWQuIElmIHlv dSB0aGUgaXQgDQpsaXRlcmFsbHksIGl0IHdvdWxkIGV2ZW4gaW5jbHVkZSBwYXRocyB0aGF0IGdv IHRocm91Z2ggc29tZSBSQnJpZGdlcyBtb3JlIA0KdGhhbiBvbmNlLg0KDQpJIGRvbid0IHBhcnRp Y3VsYXJseSBsaWtlICJhbGwgRUNNUCBwYXRocyIgZWl0aGVyLiBJIHRoaW5rIHRoZSBjbGVhcmVz dCANCndvcmRpbmcgaXMgImFsbCBsZWFzdCBjb3N0IHBhdGhzIiBpZiB5b3UgYXJlIHRhbGtpbmcg YWJvdXQga25vd24gdW5pY2FzdC4gDQooQW5kICJhbGwgZGlzdHJpYnV0aW9uIHRyZWUgcGF0aHMi IGlmIHlvdSB3ZXJlIHRhbGtpbmcgYWJvdXQgDQptdWx0aS1kZXN0aW5hdGlvbiBmcmFtZXMuKQ0K DQpUaGFua3MsDQpEb25hbGQNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQogRG9uYWxk IEUuIEVhc3RsYWtlIDNyZCAgICsxLTUwOC0zMzMtMjI3MCAoY2VsbCkNCiAxNTUgQmVhdmVyIFN0 cmVldCwgTWlsZm9yZCwgTUEgMDE3NTcgVVNBDQogZDNlM2UzQGdtYWlsLmNvbQ0KDQoNCk9uIFNh dCwgQXByIDI4LCAyMDEyIGF0IDExOjQ1IFBNLCBFcmlrIE5vcmRtYXJrIDxub3JkbWFya0BhY20u b3JnPiB3cm90ZToNCj4gT24gNC8yNy8xMiA1OjEyIFBNLCBUaXNzYSBTZW5ldmlyYXRobmUgKHRz ZW5ldmlyKSB3cm90ZToNCj4+DQo+PiBPZiBjb3Vyc2UgaXQgaXMgcG9zc2libGUuIFRoZSBJUy1J UyB0b3BvbG9neSB0YWJsZSBwcm92aWRlIHRoZSANCj4+IGluZm9ybWF0aW9uIG9uIGFsbCBhdmFp bGFibGUgRUNNUCBwYXRocyB0byBhIHNwZWNpZmljIGRlc3RpbmF0aW9uIA0KPj4gd2hlbiB0aGUg ZWdyZXNzIFJCUmlkZ2Ugbmlja25hbWUgaXMga25vd24uIFRoYXQgaXMgd2hhdCBUUklMTCB1bmlj YXN0IA0KPj4gZm9yd2FyZGluZyB0YWJsZSBhbGwgYWJvdXQuIE5vdCBzdXJlIHdoeSB5b3UgYXJl IHNheWluZyBpdCBpcyBub3QgDQo+PiBwb3NzaWJsZSB0byBrbm93IGFsbCBFQ01QIHBhdGhzLg0K Pg0KPg0KPiBZb3UgYXJlIHRhbGtpbmcgYWJvdXQgd2hhdCBTYW50b3NoIGNhbGxlZCAiYWxsIHRo ZW9yZXRpY2FsbHkgYXZhaWxhYmxlIA0KPiBwYXRocyIuIFRob3NlIGNhbiBiZSBkZXRlcm1pbmVk IGZyb20gSVMtSVMuDQo+DQo+IEJ1dCB0aGUgZG9jdW1lbnQgdGFsa3MgYWJvdXQgImFsbCBhdmFp bGFibGUgcGF0aHMiIGFuZCBJIGRvbid0IGtub3cgDQo+IHdoYXQgdGhhdCBpcyBzdXBwb3NlZCB0 byBtZWFuLiBEbyB5b3UgaGF2ZSBhIHN1Y2NpbmN0IGRlZmluaXRpb24/DQo+DQo+IFdoYXQgaXMg Y2xlYXIgdG8gbWUgaXMgdGhhdCB0aGVyZSBjYW4gYmUgYSBzdWJzZXQgb2YgdGhlIHBhdGhzIHRo YXQgDQo+IGFyZSBkZXRlcm1pbmVkIGZyb20gSVMtSVMgdGhhdCB3b3VsZCBuZXZlciBiZSB1c2Vk LCBiZWNhdXNlIG5vIGVudHJvcHkgDQo+IGluIGEgcGFja2V0IHdvdWxkIGV2ZXJ5IHBpY2sgdGhh dCBwYXRoLg0KPg0KPiBJcyB0aGUgcmVxdWlyZW1lbnQgaW4gdGhlIGRvY3VtZW50IHRoYXQgdGhl IE9BTSBzb2x1dGlvbiBzaG91bGQgYmUgDQo+IGFibGUgdG8gdGVzdCB0aG9zZSBwYXRocz8NCj4N Cj4NCj4+IFdoYXQgcGF0aCBhbW9uZyBhdmFpbGFibGUgcGF0aHMgdG8gYmUgc2VsZWN0ZWQgZm9y IGEgc3BlY2lmaWVkIGlzIGEgDQo+PiBsb2NhbCBtYXR0ZXIuIFRoYXQgaXMgd2hhdCBhbGwgYWJv dXQgZmxvdyBlbnRyb3B5IGRpc2NvdmVyeS4gTGlrZSBJIA0KPj4gc3RhdGVkIGVhcmxpZXIgaG93 IGl0IGlzIGRpc2NvdmVyZWQgaXMgYSBmcmFtZXdvcmsgYW5kIHNvbHV0aW9uIGlzc3VlLg0KPg0K Pg0KPiBBZ3JlZWQuDQo+DQo+DQo+PiBJZiB5b3UgbmVlZCBzb21lIHJlZmVyZW5jZSBob3cgaXQg aXMgZG9uZSBpbiB0aGUgTVBMUyB3b3JsZCBSRkMgNDM3OSANCj4+IGlzIGEgZ29vZCByZWZlcmVu Y2UuDQo+DQo+DQo+IEFGQUlLIE1QTFMgZG9lc24ndCBoYXZlIGEgbG9jYWxseSBkZWZpbmVkIEVD TVAgaGFzaCBmdW5jdGlvbiBpbiBldmVyeSANCmhvcC4NCj4gVFJJTEwgZG9lcywgd2hpY2ggbWFr ZXMgdGhlc2UgYXNwZWN0cyBkaWZmZXJlbnQuDQo+DQo+IFJlZ2FyZHMsDQo+ICAgRXJpaw0KPg0K Pg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IHRyaWxsLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzp0cmlsbC1ib3VuY2VzQGlldGYub3JnXSBPbiANCj4+IEJlaGFsZiBP ZiBFcmlrIE5vcmRtYXJrDQo+PiBTZW50OiBGcmlkYXksIEFwcmlsIDI3LCAyMDEyIDQ6MDcgUE0N Cj4+IFRvOiBTYW50b3NoIFJhamFnb3BhbGFuDQo+PiBDYzogdHJpbGxAaWV0Zi5vcmcNCj4+IFN1 YmplY3Q6IFJlOiBbdHJpbGxdIFRSSUxMIE9BTSBSZXF1aXJlbWVudHM6IGF2YWlsYWJsZSBwYXRo cw0KPj4NCj4+IE9uIDQvMjcvMTIgMjoxNSBQTSwgU2FudG9zaCBSYWphZ29wYWxhbiB3cm90ZToN Cj4+Pg0KPj4+IEkgYWdyZWUsIHRoZSB3b3JkaW5nIG5lZWRzIHRvIGJlIHRpZ2h0ZW5lZCB0byBz YXkgImFsbCBwb3NzaWJsZSBlY21wIA0KPj4+IHBhdGhzIiByYXRoZXIgdGhhbiAiYWxsIGF2YWls YWJsZSBwYXRocyIuIEFuIG9wZXJhdG9yIHdvcmtpbmcgb3V0DQo+Pj4gUjEtUjIgY29tbXVuaWNh dGlvbiBpcyBpbnRlcmVzdGVkIGluIGFsbCBwb3NzaWJsZSBwYXRocyBkYXRhIHRyYWZmaWMgDQo+ Pj4gY291bGQgdGFrZSByYXRoZXIgdGhhbiBhbGwgdGhlb3JldGljYWxseSBhdmFpbGFibGUgcGF0 aHMuDQo+Pg0KPj4NCj4+IFRoZSBpc3N1ZSBpcyB0aGF0IHRoZXJlIGlzIG5vdGhpbmcgaW4gdGhl IFRSSUxMIGRhdGFwbGFuZSBub3IgSVMtSVMgDQo+PiBjb250cm9sIHBsYW5lIHdoaWNoIGhlbHBz IHRoZSBvcGVyYXRvciBkZXRlcm1pbmUgdGhhdCBzb21lIHBhdGhzIA0KPj4gKHRocm91Z2ggUkIx MjEgYW5kIFJCMTEyIGluIHRoZSBleGFtcGxlKSBhcmUgbm90IHBvc3NpYmxlOyB0aGUgRUNNUCAN Cj4+IGlucHV0IGFuZCBoYXNoaW5nIGlzIGEgY29tcGxldGVseSBsb2NhbCBtYXR0ZXIgb24gZWFj aCBSQnJpZGdlLg0KPj4NCj4+IEl0IGlzbid0IHVzZWZ1bCB0byBzdGF0ZSBhIHJlcXVpcmVtZW50 IGFyb3VuZCBzb21ldGhpbmcgdGhhdCBjYW4ndCBiZSANCj4+IGRldGVybWluZWQuDQo+Pg0KPj4g ICAgIEVyaWsNCj4+DQo+Pj4NCj4+Pg0KPj4+IEZyb206IEVyaWsgTm9yZG1hcms8bm9yZG1hcmtA YWNtLm9yZz4NCj4+PiBUbzogdHJpbGxAaWV0Zi5vcmcNCj4+PiBEYXRlOiAwNC8yNy8yMDEyIDA5 OjUzIEFNDQo+Pj4gU3ViamVjdDogW3RyaWxsXSBUUklMTCBPQU0gUmVxdWlyZW1lbnRzOiBhdmFp bGFibGUgcGF0aHMgU2VudCBieToNCj4+PiB0cmlsbC1ib3VuY2VzQGlldGYub3JnDQo+Pj4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4+PiAtLQ0KPj4+IC0tDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+PiBUd28gcmVx dWlyZW1lbnRzIHVzZSB0aGUgd29yZGluZyAiYWxsIGF2YWlsYWJsZSBwYXRocy4iIGFuZCAiYWxs IA0KPj4+IGF2YWlsYWJsZSBFQ01QIHBhdGhzLiIsIHJlc3BlY3RpdmVseSBhbmQgSSdtIG5vdCBz dXJlIEkga25vdyB3aGF0IA0KPj4+IHRoYXQNCj4+DQo+Pg0KPj4+IG1lYW5zLg0KPj4+DQo+Pj4g VGFrZSB0aGUgZm9sbG93aW5nIGV4YW1wbGUgcGljdHVyZToNCj4+Pg0KPj4+IFIxDQo+Pj4gLyBc DQo+Pj4gLyBcDQo+Pj4gLyBcDQo+Pj4gLyBcDQo+Pj4gLyBcDQo+Pj4gUkIxMSBSQjEyDQo+Pj4g LyBcIC8gXA0KPj4+IC8gXCAvIFwNCj4+PiBSQjExMSBSQjExMiBSQjEyMSBSQjEyMg0KPj4+IFwg XCAvIC8NCj4+PiBcIFwgLyAvDQo+Pj4gXCBcLyAvDQo+Pj4gLS0tLS0tUjItLS0tLS0NCj4+Pg0K Pj4+IFdlIGNhbiBzZWUgdGhhdCB0aGVyZSBhcmUgNCBwYXRocyB3aXRoIDMgaG9wcyB0byBnZXQg ZnJvbSBSMSB0byBSMiwgDQo+Pj4gd2l0aCB0d28gbGF5ZXJzIG9mIEVDTVAgZGVjaXNpb25zLiBC dXQgaG93IG1hbnkgYXZhaWxhYmxlIHBhdGhzIGFyZQ0KPj4NCj4+IHRoZXJlPw0KPj4+DQo+Pj4N Cj4+PiBHaXZlbiB0aGF0IHRoZSBSQnJpZGdlcyBtYWtlIGluZGVwZW5kZW50IEVDTVAgZGVjaXNp b25zLCBhbmQgaG93IA0KPj4+IHRoZXkgZG8gdGhhdCBpcyBhIGxvY2FsIG1hdHRlciwgaXQgY291 bGQgYmUgdGhlIGNhc2UgdGhhdCBmb3IgYW55IA0KPj4+IHBhY2tldCwgaWYgUjEgcGlja3MgdGhl IGxlZnQgbGluaywgdGhlbiBSMTEgd291bGQgYWxzbyBwaWNrIHRoZSBsZWZ0IA0KPj4+IGxpbms7 IGlmDQo+Pj4gUjEgcGlja3MgdGhlIHJpZ2h0IGxpbmssIHRoZW4gUjEyIGFsc28gcGlja3MgdGhl IHJpZ2h0IGxpbmsuDQo+Pj4gVGh1cyB0aGVyZSB3b3VsZCBiZSBubyBwYWNrZXQgKGRhdGEgb3Ig T0FNKSB0aGF0IHdvdWxkIGNhdXNlIHBhY2tldHMgDQo+Pj4gYmV0d2VlbiBSMSBhbmQgUjIgdG8g cGFzcyB2aWEgUkIxMTIgb3IgUkIxMjEuDQo+Pj4NCj4+PiBFdmVuIGlmIHdlIGlnbm9yZSB0aGF0 IGFzIHVubGlrZWx5LCB0aGVyZSBpcyBzdGlsbCB0aGUgZmFjdCB0aGF0IFIxIA0KPj4+IGNhbid0 IGVhc2lseSB0ZWxsIGhvdyBtYW55IChzaG9ydGVzdCkgcGF0aHMgdGhlcmUgbWlnaHQgYmUgYmV0 d2VlbiANCj4+PiBpdCBhbmQgUjIuIFdpdGggc2luZ2xlLWxldmVsIFRSSUxMIHRoZSBMU0RCIGNv dWxkIGJlIHVzZWQgdG8gdGVsbCwgDQo+Pj4gYnV0IGlmDQo+Pg0KPj4NCj4+PiB3ZSBldmVyIGdv IHRvIG11bHRpLWxldmVsIHRoYXQgd291bGRuJ3QgYmUgdGhlIGNhc2UgYW55IG1vcmUuDQo+Pj4g QW5kIGV2ZW4gaWYgUjEga25vd3MgdGhhdCB0aGVyZSBhcmUgNCBwb3RlbnRpYWwgcGF0aHMsIGl0 IGNhbid0IA0KPj4+IGZvcm1hdA0KPj4NCj4+DQo+Pj4gYSBkYXRhIHBhY2tldCAob3IgZm9ybWF0 IHRoZSBmbG93IGVudHJvcHkgaW4gYW4gT0FNIHBhY2tldCkgaW4gc3VjaCANCj4+PiBhIHdheSB0 aGF0IHBhcnRpY3VsYXIgcGF0aHMgZ2V0IGNob3NlbiBieSBkb3duc3RyZWFtIEVDTVAgZGVjaXNp b25zLg0KPj4+DQo+Pj4gVGh1cyBmb3IgYW55IG5vdGlvbiBvZiAiYWxsIGF2YWlsYWJsZSBwYXRo cyIgdGhhdCBtYWtlIHNlbnNlIHRvIG1lLCANCj4+PiB3ZSdkIG5lZWQgYW4gT0FNIGFwcHJvYWNo IHRoYXQgY2FuIGV4cGxvcmUgdGhlIHRvcG9sb2d5IG9uZSBob3AgYXQgYSANCj4+PiB0aW1lIGFu ZCBhdCBlYWNoIGhvcCBleHBsb3JlIGFsbCB0aGUgcG9zc2libGUgRUNNUCBjaG9pY2VzLiBVc2lu ZyANCj4+PiB0aGUgZW50cm9weSBkb2Vzbid0IGhlbHAgd2l0aCB0aGlzIChidXQgdGhlIGVudHJv cHkgaXMgY3JpdGljYWwgZm9yIA0KPj4+IGZvbGxvd2luZyB0aGUgcGF0aCB0YWtlbiBieSBhIHBh cnRpY3VsYXIgZmxvdyBvZiBkYXRhIHBhY2tldHMpLg0KPj4+DQo+Pj4gSGVuY2UgaXQgd291bGQg YmUgZ29vZCB0byBjbGFyaWZ5IHdoYXQgdGhlIGFzc3VtcHRpb25zIGFyZSBiZWhpbmQgDQo+Pj4g dGhpcw0KPj4NCj4+DQo+Pj4gbm90aW9uIG9mIGFsbCBhdmFpbGFibGUgcGF0aHMuDQo+Pj4NCj4+ PiBUaGFua3MsDQo+Pj4gRXJpaw0KPj4+DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+PiB0cmlsbCBtYWlsaW5nIGxpc3QNCj4+PiB0cmlsbEBp ZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJpbGwN Cj4+Pg0KPj4+DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+IHRyaWxsIG1haWxpbmcgbGlzdA0KPj4gdHJpbGxAaWV0Zi5vcmcNCj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJpbGwNCj4+DQo+DQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHRyaWxsIG1haWxp bmcgbGlzdA0KPiB0cmlsbEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3RyaWxsDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KdHJpbGwgbWFpbGluZyBsaXN0DQp0cmlsbEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmlsbA0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCnRyaWxsIG1haWxpbmcgbGlzdA0KdHJpbGxAaWV0Zi5v cmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJpbGwNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQp0cmlsbCBtYWlsaW5nIGxp c3QNCnRyaWxsQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3RyaWxsDQoNCg0K --=_alternative 006E4DAE882579F0_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRpc3NhLDwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SGFzaCBwb2xhcml6YXRpb24gY2FuIHJlc3VsdCBpbiBz b21lDQpvZiB0aGUgZWNtcCBwYXRocyBiZWluZyB1bnV0aWxpemVkLiBJbiBFcmljJ3MgZXhhbXBs ZTo8L2ZvbnQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj48YnI+DQo8YnI+DQogJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1IxPGJyPg0KICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAvICZuYnNwO1w8YnI+ DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7LyAmbmJz cDsgJm5ic3A7XDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAvICZuYnNwOyAmbmJzcDsgJm5ic3A7XDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOy8gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7XDxicj4NCiAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC8gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO1w8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7UkIxMSAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7UkIxMjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsvICZuYnNwO1wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy8NCiZu YnNwO1w8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgLyAmbmJzcDsgJm5ic3A7XCAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsvICZuYnNwOw0KJm5ic3A7XDxicj4NCiAmbmJzcDsgJm5ic3A7 UkIxMTEgJm5ic3A7UkIxMTIgJm5ic3A7UkIxMjEgJm5ic3A7UkIxMjI8YnI+DQogJm5ic3A7ICZu YnNwOyAmbmJzcDsgXCAmbmJzcDsgJm5ic3A7ICZuYnNwO1wgJm5ic3A7ICZuYnNwOy8gJm5ic3A7 ICZuYnNwOw0KJm5ic3A7Lzxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtcICZuYnNw OyAmbmJzcDsgJm5ic3A7XCAmbmJzcDsvICZuYnNwOyAmbmJzcDsNCiZuYnNwOy88YnI+DQogJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFwgJm5ic3A7ICZuYnNwOyAmbmJzcDtcLyAmbmJzcDsg Jm5ic3A7ICZuYnNwOy88YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy0t LS0tLVIyLS0tLS0tPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPklmIFIxIGFuZCBSQjEyIHVzZSB0aGUgc2FtZSBoYXNoIHBvbHlub21pYWwNCiZh bXA7IHNlZWQsIHRoZW4gKmFsbCogZmxvd3Mgd2hpY2ggYXJyaXZlIGF0IFJCMTIgd2lsbCBnbyBh bG9uZyB0aGUgbGluaw0KdG8gUkIxMjIgLSB0aGUgbGluayB0byBSQjEyMSBmcm9tIFJCMTIgd2ls bCBuZXZlciBiZSB1c2VkLiBUaGUgT0FNIHRvb2wNCnNob3VsZCBhbGxvdyB1cyB0byBmaWd1cmUg b3V0IHRoaXMgaXMgaGFwcGVuaW5nLCBpbnN0ZWFkIG9mIGdpdmluZyB1cyByZWR1bmRhbnQNCmlu Zm9ybWF0aW9uIGFscmVhZHkgYXZhaWxhYmxlIGluIElTSVMgbHNkYi48L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgd291bGQgaGVzaXRhdGUgdG8gY2FsbCB0aGlz IGEgZGVmZWN0Lg0KV2hpbGUgaXQgaXMgdHJ1ZSB0aGF0IGEgbG90IG9mIGFzaWNzIGhhdmUgY291 bnRlcm1lYXN1cmVzIGZvciB0aGlzICh1c3VhbGx5DQpieSBpbmNsdWRpbmcgYSByYW5kb20gc2Vl ZCBhcyBpbnB1dCB0byB0aGUgaGFzaCBwb2x5bm9taWFsKSwgeW91IGNhbm5vdA0KcnVsZSB0aGlz IG91dCAxMDAlLiBQbGVhc2UgbG9vayBhdCB0aGlzIGRvY3VtZW50YXRpb24gZnJvbSBhIHdlbGwg a25vd24NCm5ldHdvcmtpbmcgY29tcGFueSA7LSk8L2ZvbnQ+DQo8YnI+PGEgaHJlZj1odHRwOi8v d3d3LmNpc2NvLmNvbS9lbi9VUy9kb2NzL2lvcy8xMl80dC9pcF9tY2FzdC9jb25maWd1cmF0aW9u L2d1aWRlL21jdGxzcGx0Lmh0bWwjd3AxMDY0NTAxPjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx1 Pmh0dHA6Ly93d3cuY2lzY28uY29tL2VuL1VTL2RvY3MvaW9zLzEyXzR0L2lwX21jYXN0L2NvbmZp Z3VyYXRpb24vZ3VpZGUvbWN0bHNwbHQuaHRtbCN3cDEwNjQ1MDE8L3U+PC9mb250PjwvYT48Zm9u dCBzaXplPTM+DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPi0tPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5TdW5ueTwv Zm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTEgY29sb3I9IzVm NWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5Gcm9tOiAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7 PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtUaXNzYSBTZW5ldmly YXRobmUNCih0c2VuZXZpcikmcXVvdDsgJmx0O3RzZW5ldmlyQGNpc2NvLmNvbSZndDs8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+VG86ICZu YnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPkRhdmlkIE0gQm9uZC9CZWRmb3JkL0lCTUBJQk1VUzwvZm9udD4NCjxicj48Zm9udCBz aXplPTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5DYzogJm5ic3A7ICZuYnNwOyAm bmJzcDsNCiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+RG9uYWxk IEVhc3RsYWtlICZsdDtkM2UzZTNAZ21haWwuY29tJmd0OywNCnRyaWxsLWJvdW5jZXNAaWV0Zi5v cmcsIHRyaWxsQGlldGYub3JnPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBjb2xvcj0jNWY1ZjVm IGZhY2U9InNhbnMtc2VyaWYiPkRhdGU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDs8L2Zv bnQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjA0LzMwLzIwMTIgMTI6MjkgUE08L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+U3Vi amVjdDogJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOzwvZm9udD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+UmU6IFt0cmlsbF0NClRSSUxMIE9BTSBSZXF1aXJlbWVudHM6IGF2YWls YWJsZSBwYXRoczwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJz YW5zLXNlcmlmIj5TZW50IGJ5OiAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7PC9mb250Pjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj50cmlsbC1ib3VuY2VzQGlldGYub3JnPC9mb250 Pg0KPGJyPg0KPGhyIG5vc2hhZGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9y PSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+TGV0IG1lIHN0YXJ0IGZyb20gdGhlIGJhc2ljcy48L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7 PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPjEu ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRSSUxMDQppcyBhbGwgYWJvdXQgbXVsdGlwbGUgYWN0aXZl IHBhdGhzLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwNDA4MCBmYWNlPSJDYWxp YnJpIj4yLiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBNdWx0aXBsZQ0KYWN0aXZlIHBhdGhzIGFyZSBk ZXJpdmVkIGZyb20gbGVhc3QgY29zdCBwYXRocyB0byBhIHNwZWNpZmljIGRlc3RpbmF0aW9ucy48 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+My4g Jm5ic3A7ICZuYnNwOyAmbmJzcDsgV2VsbA0KZGVmaW5lZCBhbmQgaW1wbGVtZW50ZWQgSGFzaGlu ZyBhbGdvcml0aG1zIHByb3ZpZGUgYW4gYWxtb3N0IGV2ZW4gZGlzdHJpYnV0aW9uDQphY3Jvc3Mg YWxsIG9mIHRoZSBhdmFpbGFibGUgbGVhc3QgY29zdCBwYXRocyB0byBhIGRlc3RpbmF0aW9uPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPjQuICZu YnNwOyAmbmJzcDsgJm5ic3A7IElmDQphIGdpdmVuIGZsb3cg4oCceOKAnSBkb2VzIG5vdCBtYXAg dG8gJm5ic3A7YSBzcGVjaWZpYyBsZWFzdCBjb3N0IHBhdGgsIGRvZXMNCm5vdCBtYXAgdG8gYSBz cGVjaWZpYyBsZWFzdCBjb3N0IHBhdGggZG9lcyBub3QgbWVhbiBhbm90aGVyIGZsb3cg4oCceeKA nQ0KdG8gdGhlIHNhbSBkZXN0aW5hdGlvbiB3aWxsIG5vdCBtYXAgdG8gdGhlIHRoYXQgcGF0aC4g PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPjUu ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFdlbGwNCmltcGxlbWVudGVkIGhhc2hpbmcgYWxnb3JpdGht cyBwcm92aWRlIGV2ZW4gZGlzdHJpYnV0aW9uIG9mIGZsb3dzLjwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgY29sb3I9IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj42LiAmbmJzcDsgJm5ic3A7ICZuYnNw OyBIZW5jZQ0KaXQgaXMgaW1wb3J0YW50IHRvIGhhdmUgYWJpbGl0eSB0byB0ZXN0IGFsbCBhdmFp bGFibGUgbGVhc3QgY29zdCBwYXRocw0KdG8gYSBkZXN0aW5hdGlvbi48L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+Ny4gJm5ic3A7ICZuYnNwOyAm bmJzcDsgSXQNCmlzIGFuIGltcGxlbWVudGF0aW9uIGRlZmVjdCwgSWYgdGhlcmUgaXMgYW4gaW1w bGVtZW50YXRpb24gb3V0IHRoZXJlIHdoaWNoDQpkb2VzIG5vdCBoYXNoIGZsb3dzIChvdmVyIGEg bG9uZ2VyIHNhbXBsaW5nIHBlcmlvZCkgJm5ic3A7aW4gdG8gYSBzcGVjaWZpYw0K4oCcbGVhc3Qg Y29zdCBwYXRo4oCdIG9mIHNldCBvZiBsZWFzdCBjb3N0IHBhdGhzIHRvIGEgZGVzdGluYXRpb24s IGFtb25nDQphbGwgYXZhaWxhYmxlIOKAnGxlYXN0IGNvc3QgcGF0aHPigJ0gdG8gdGhhdCBkZXN0 aW5hdGlvbi48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2Fs aWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxiPkZy b206PC9iPiBEYXZpZCBNIEJvbmQgWzwvZm9udD48YSBocmVmPW1haWx0bzpkbWJvbmRAdXMuaWJt LmNvbT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj5tYWlsdG86ZG1ib25kQHVzLmlibS5jb208 L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPl0NCjxiPjxicj4NClNlbnQ6PC9i PiBNb25kYXksIEFwcmlsIDMwLCAyMDEyIDg6MzkgQU08Yj48YnI+DQpUbzo8L2I+IFRpc3NhIFNl bmV2aXJhdGhuZSAodHNlbmV2aXIpPGI+PGJyPg0KQ2M6PC9iPiBEb25hbGQgRWFzdGxha2U7IHRy aWxsQGlldGYub3JnOyB0cmlsbC1ib3VuY2VzQGlldGYub3JnPGI+PGJyPg0KU3ViamVjdDo8L2I+ IFJlOiBbdHJpbGxdIFRSSUxMIE9BTSBSZXF1aXJlbWVudHM6IGF2YWlsYWJsZSBwYXRoczwvZm9u dD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+ DQo8cD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPkp1c3QgYSBxdWVzdGlvbiBjb21pbmcgZnJv bSB0aGlzIGNvbnZlcnNhdGlvbg0KdGhhdCBJIHdhbnQgdG8gY2xhcmlmeTo8L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBm YWNlPSJBcmlhbCI+PGJyPg0KU28gd2UgaGF2ZSAnYWxsIHBvc3NpYmxlIHBhdGhzJyAoMSkgd2hp Y2ggY291bGQgaW5jbHVkZSBub24tbGVhc3QgY29zdA0KcGF0aHMgYW5kIHNvIG9mIGNvdXJzZSB3 ZSBkb24ndCB3YW50IHRvIHVzZSB0aGlzIGRlZmluaXRpb24uPC9mb250Pjxmb250IHNpemU9MyBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJp YWwiPjxicj4NClRoZW4gd2UgaGF2ZSAnYWxsIGVjbXAgcGF0aHMnIG9yICdhbGwgbGVhc3QgY29z dCBwYXRocycgKDIpIHdoaWNoIE1BWSBpbmNsdWRlDQpwYXRocyBuZXZlciBjaG9zZW4gYnkgYSB0 cmFuc2l0IFJicmlkZ2UgYmVjYXVzZSBvZiB0aGUgbG9jYWwgaGFzaGluZyBjaG9pY2VzLjwvZm9u dD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48YnI+DQo8L2ZvbnQ+PGZvbnQg c2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpUaGVuIHdlIGhhdmUgJ2FsbCB0aGUgbGVhc3QgY29z dCBwYXRocyB3aGljaCBtYXkgYmUgY2hvc2VuIGdpdmVuIHRoZSBoYXNoaW5nDQppbXBsZW1lbnRh dGlvbiBvbiB0aGUgbG9jYWwgUmJyaWRnZXMnICgzKS48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+ PGJyPg0KSSB3b25kZXIgaWYgY2hvaWNlICgyKSBpcyB1c2VmdWwgb3IgZG8gd2Ugb25seSByZWFs bHkgY2FyZSBhYm91dCBjaG9pY2UNCigzKS4gRm9yIGluc3RhbmNlLCBpZiB5b3UgaGF2ZSAxNiBl cXVhbCBjb3N0IHBhdGhzIGZyb20gQSB0byBCIGFuZCB5b3VyDQpoYXNoaW5nIG9ubHkgd2lsbCBl dmVyIHVzZSAyIG9mIHRob3NlIHBhdGhzIGRvIHdlIGNhcmUgYWJvdXQgcmVwb3J0aW5nDQpiYWNr IGVjbXAgcGF0aHMgdGhhdCB3aWxsIG5ldmVyIGluIHByYWN0aWNlIGJlIHVzZWQ/IFBlcmhhcHMg dGhlIGRlZmluaXRpb24NCnNob3VsZCBiZSB0aWdodGVuZWQgdG8gb25seSByZXF1aXJlIGRldGVy bWluYXRpb24gb2YgYWxsIGxlYXN0IGNvc3QgcGF0aHMNCnRoYXQgY291bGQgYmUgdXNlZCBnaXZl biB0aGUgbG9jYWwgaGFzaGluZyBpbXBsZW1lbnRhdGlvbi4gT3IgYW0gSSBtaXN1bmRlcnN0YW5k aW5nDQp0aGUgY29udmVyc2F0aW9uIGFuZCBpcyB0aGlzIGFscmVhZHkgdGhlIHBvaW50IGJlaW5n IG1hZGUgYmV0d2VlbiB0aGVvcmV0aWNhbA0KcGF0aHMgYW5kIGxlYXN0IGNvc3QgcGF0aHMuPC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxicj4NCjwvZm9udD48Zm9u dCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NClRoYW5rcyw8YnI+DQpEYXZpZDwvZm9udD48Zm9u dCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48YnI+DQo8YnI+DQo8L2ZvbnQ+PGltZyBz cmM9Y2lkOl8xXzBCOEU3MjgwMEI4RTY3RjAwMDZFNEFFNTg4MjU3OUYwIGFsdD0iSW5hY3RpdmUg aGlkZSBkZXRhaWxzIGZvciAmcXVvdDtUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKSZxdW90 OyAtLS0wNC8yOS8yMDEyIDExOjQzOjA3IFBNLS0tSSBsaWtlIHRoYXQgRG9uYWxkLi4gV2UgY2Fu IHVzZSAmcXVvdDthbGwgbGVhcyI+PGZvbnQgc2l6ZT0yIGNvbG9yPSM0MjQyODIgZmFjZT0iQXJp YWwiPiZxdW90O1Rpc3NhDQpTZW5ldmlyYXRobmUgKHRzZW5ldmlyKSZxdW90OyAtLS0wNC8yOS8y MDEyIDExOjQzOjA3IFBNLS0tSSBsaWtlIHRoYXQgRG9uYWxkLi4NCldlIGNhbiB1c2UgJnF1b3Q7 YWxsIGxlYXN0IGNvc3QgcGF0aHMmcXVvdDssIHRoYXQgaXMgdGVjaG5pY2FsbHkgbW9yZSBwcmVj aXNlDQphbmQgcmVwcmVzZTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFu Ij48YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0iQXJpYWwiPjxi cj4NCkZyb206IDwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPiZxdW90O1Rpc3NhIFNl bmV2aXJhdGhuZSAodHNlbmV2aXIpJnF1b3Q7DQombHQ7PC9mb250PjxhIGhyZWY9bWFpbHRvOnRz ZW5ldmlyQGNpc2NvLmNvbT48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PHU+ dHNlbmV2aXJAY2lzY28uY29tPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFs Ij4mZ3Q7PC9mb250Pjxmb250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9IkFyaWFsIj48YnI+ DQpUbzogPC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+JnF1b3Q7RG9uYWxkIEVhc3Rs YWtlJnF1b3Q7ICZsdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86ZDNlM2UzQGdtYWlsLmNvbT48Zm9u dCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PHU+ZDNlM2UzQGdtYWlsLmNvbTwvdT48 L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+Jmd0OywNCiZsdDs8L2ZvbnQ+PGEg aHJlZj1tYWlsdG86dHJpbGxAaWV0Zi5vcmc+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0i QXJpYWwiPjx1PnRyaWxsQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0xIGZhY2U9 IkFyaWFsIj4mZ3Q7PC9mb250Pjxmb250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9IkFyaWFs Ij48YnI+DQpEYXRlOiA8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj4wNC8yOS8yMDEy IDExOjQzIFBNPC9mb250Pjxmb250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9IkFyaWFsIj48 YnI+DQpTdWJqZWN0OiA8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj5SZTogW3RyaWxs XSBUUklMTCBPQU0gUmVxdWlyZW1lbnRzOg0KYXZhaWxhYmxlIHBhdGhzPC9mb250Pjxmb250IHNp emU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9IkFyaWFsIj48YnI+DQpTZW50IGJ5OiA8L2ZvbnQ+PGEg aHJlZj0ibWFpbHRvOnRyaWxsLWJvdW5jZXNAaWV0Zi5vcmciPjxmb250IHNpemU9MSBjb2xvcj1i bHVlIGZhY2U9IkFyaWFsIj48dT50cmlsbC1ib3VuY2VzQGlldGYub3JnPC91PjwvZm9udD48L2E+ DQo8YnI+DQo8aHIgbm9zaGFkZT4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj48YnI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48 YnI+DQpJIGxpa2UgdGhhdCBEb25hbGQuLiBXZSBjYW4gdXNlICZxdW90O2FsbCBsZWFzdCBjb3N0 IHBhdGhzJnF1b3Q7LCB0aGF0DQppcyB0ZWNobmljYWxseSBtb3JlIHByZWNpc2UgYW5kIHJlcHJl c2VudCBleGFjdGx5IHdoYXQgSVMtSVMgZG9lcy48YnI+DQo8YnI+DQpUaGFua3M8YnI+DQpUaXNz YTxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogPC9mb250 PjxhIGhyZWY9Im1haWx0bzp0cmlsbC1ib3VuY2VzQGlldGYub3JnIj48Zm9udCBzaXplPTIgY29s b3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIE5ldyI+PHU+dHJpbGwtYm91bmNlc0BpZXRmLm9yZzwvdT48 L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+DQpbPC9mb250PjxhIGhy ZWY9Im1haWx0bzp0cmlsbC1ib3VuY2VzQGlldGYub3JnIj48Zm9udCBzaXplPTIgY29sb3I9Ymx1 ZSBmYWNlPSJDb3VyaWVyIE5ldyI+PHU+bWFpbHRvOnRyaWxsLWJvdW5jZXNAaWV0Zi5vcmc8L3U+ PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPl0NCk9uIEJlaGFsZiBP ZiBEb25hbGQgRWFzdGxha2U8YnI+DQpTZW50OiBTdW5kYXksIEFwcmlsIDI5LCAyMDEyIDY6Mjcg UE08YnI+DQpUbzogPC9mb250PjxhIGhyZWY9bWFpbHRvOnRyaWxsQGlldGYub3JnPjxmb250IHNp emU9MiBjb2xvcj1ibHVlIGZhY2U9IkNvdXJpZXIgTmV3Ij48dT50cmlsbEBpZXRmLm9yZzwvdT48 L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KU3ViamVjdDog UmU6IFt0cmlsbF0gVFJJTEwgT0FNIFJlcXVpcmVtZW50czogYXZhaWxhYmxlIHBhdGhzPGJyPg0K PGJyPg0KSSBkb24ndCB0aGluayB0aGUgd29yZGluZyAmcXVvdDthbGwgcGF0aHMmcXVvdDsgc2hv dWxkIGV2ZXIgYmUgdXNlZC4gSWYNCnlvdSB0aGUgaXQgbGl0ZXJhbGx5LCBpdCB3b3VsZCBldmVu IGluY2x1ZGUgcGF0aHMgdGhhdCBnbyB0aHJvdWdoIHNvbWUNClJCcmlkZ2VzIG1vcmUgdGhhbiBv bmNlLjxicj4NCjxicj4NCkkgZG9uJ3QgcGFydGljdWxhcmx5IGxpa2UgJnF1b3Q7YWxsIEVDTVAg cGF0aHMmcXVvdDsgZWl0aGVyLiBJIHRoaW5rIHRoZQ0KY2xlYXJlc3Qgd29yZGluZyBpcyAmcXVv dDthbGwgbGVhc3QgY29zdCBwYXRocyZxdW90OyBpZiB5b3UgYXJlIHRhbGtpbmcNCmFib3V0IGtu b3duIHVuaWNhc3QuIChBbmQgJnF1b3Q7YWxsIGRpc3RyaWJ1dGlvbiB0cmVlIHBhdGhzJnF1b3Q7 IGlmIHlvdQ0Kd2VyZSB0YWxraW5nIGFib3V0IG11bHRpLWRlc3RpbmF0aW9uIGZyYW1lcy4pPGJy Pg0KPGJyPg0KVGhhbmtzLDxicj4NCkRvbmFsZDxicj4NCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PGJyPg0KIERvbmFsZCBFLiBFYXN0bGFrZSAzcmQgJm5ic3A7ICsxLTUwOC0zMzMtMjI3 MCAoY2VsbCk8YnI+DQogMTU1IEJlYXZlciBTdHJlZXQsIE1pbGZvcmQsIE1BIDAxNzU3IFVTQTxi cj4NCiA8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86ZDNlM2UzQGdtYWlsLmNvbT48Zm9udCBzaXplPTIg Y29sb3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIE5ldyI+PHU+ZDNlM2UzQGdtYWlsLmNvbTwvdT48L2Zv bnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KPGJyPg0KPGJyPg0K T24gU2F0LCBBcHIgMjgsIDIwMTIgYXQgMTE6NDUgUE0sIEVyaWsgTm9yZG1hcmsgJmx0OzwvZm9u dD48YSBocmVmPW1haWx0bzpub3JkbWFya0BhY20ub3JnPjxmb250IHNpemU9MiBjb2xvcj1ibHVl IGZhY2U9IkNvdXJpZXIgTmV3Ij48dT5ub3JkbWFya0BhY20ub3JnPC91PjwvZm9udD48L2E+PGZv bnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7DQp3cm90ZTo8YnI+DQomZ3Q7IE9uIDQv MjcvMTIgNToxMiBQTSwgVGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZpcikgd3JvdGU6PGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBPZiBjb3Vyc2UgaXQgaXMgcG9zc2libGUuIFRoZSBJUy1J UyB0b3BvbG9neSB0YWJsZSBwcm92aWRlIHRoZQ0KPGJyPg0KJmd0OyZndDsgaW5mb3JtYXRpb24g b24gYWxsIGF2YWlsYWJsZSBFQ01QIHBhdGhzIHRvIGEgc3BlY2lmaWMgZGVzdGluYXRpb24NCjxi cj4NCiZndDsmZ3Q7IHdoZW4gdGhlIGVncmVzcyBSQlJpZGdlIG5pY2tuYW1lIGlzIGtub3duLiBU aGF0IGlzIHdoYXQgVFJJTEwNCnVuaWNhc3QgPGJyPg0KJmd0OyZndDsgZm9yd2FyZGluZyB0YWJs ZSBhbGwgYWJvdXQuIE5vdCBzdXJlIHdoeSB5b3UgYXJlIHNheWluZyBpdCBpcw0Kbm90IDxicj4N CiZndDsmZ3Q7IHBvc3NpYmxlIHRvIGtub3cgYWxsIEVDTVAgcGF0aHMuPGJyPg0KJmd0Ozxicj4N CiZndDs8YnI+DQomZ3Q7IFlvdSBhcmUgdGFsa2luZyBhYm91dCB3aGF0IFNhbnRvc2ggY2FsbGVk ICZxdW90O2FsbCB0aGVvcmV0aWNhbGx5DQphdmFpbGFibGUgPGJyPg0KJmd0OyBwYXRocyZxdW90 Oy4gVGhvc2UgY2FuIGJlIGRldGVybWluZWQgZnJvbSBJUy1JUy48YnI+DQomZ3Q7PGJyPg0KJmd0 OyBCdXQgdGhlIGRvY3VtZW50IHRhbGtzIGFib3V0ICZxdW90O2FsbCBhdmFpbGFibGUgcGF0aHMm cXVvdDsgYW5kIEkNCmRvbid0IGtub3cgPGJyPg0KJmd0OyB3aGF0IHRoYXQgaXMgc3VwcG9zZWQg dG8gbWVhbi4gRG8geW91IGhhdmUgYSBzdWNjaW5jdCBkZWZpbml0aW9uPzxicj4NCiZndDs8YnI+ DQomZ3Q7IFdoYXQgaXMgY2xlYXIgdG8gbWUgaXMgdGhhdCB0aGVyZSBjYW4gYmUgYSBzdWJzZXQg b2YgdGhlIHBhdGhzIHRoYXQNCjxicj4NCiZndDsgYXJlIGRldGVybWluZWQgZnJvbSBJUy1JUyB0 aGF0IHdvdWxkIG5ldmVyIGJlIHVzZWQsIGJlY2F1c2Ugbm8gZW50cm9weQ0KPGJyPg0KJmd0OyBp biBhIHBhY2tldCB3b3VsZCBldmVyeSBwaWNrIHRoYXQgcGF0aC48YnI+DQomZ3Q7PGJyPg0KJmd0 OyBJcyB0aGUgcmVxdWlyZW1lbnQgaW4gdGhlIGRvY3VtZW50IHRoYXQgdGhlIE9BTSBzb2x1dGlv biBzaG91bGQgYmUNCjxicj4NCiZndDsgYWJsZSB0byB0ZXN0IHRob3NlIHBhdGhzPzxicj4NCiZn dDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDsgV2hhdCBwYXRoIGFtb25nIGF2YWlsYWJsZSBwYXRo cyB0byBiZSBzZWxlY3RlZCBmb3IgYSBzcGVjaWZpZWQNCmlzIGEgPGJyPg0KJmd0OyZndDsgbG9j YWwgbWF0dGVyLiBUaGF0IGlzIHdoYXQgYWxsIGFib3V0IGZsb3cgZW50cm9weSBkaXNjb3Zlcnku IExpa2UNCkkgPGJyPg0KJmd0OyZndDsgc3RhdGVkIGVhcmxpZXIgaG93IGl0IGlzIGRpc2NvdmVy ZWQgaXMgYSBmcmFtZXdvcmsgYW5kIHNvbHV0aW9uDQppc3N1ZS48YnI+DQomZ3Q7PGJyPg0KJmd0 Ozxicj4NCiZndDsgQWdyZWVkLjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDsgSWYg eW91IG5lZWQgc29tZSByZWZlcmVuY2UgaG93IGl0IGlzIGRvbmUgaW4gdGhlIE1QTFMgd29ybGQg UkZDDQo0Mzc5IDxicj4NCiZndDsmZ3Q7IGlzIGEgZ29vZCByZWZlcmVuY2UuPGJyPg0KJmd0Ozxi cj4NCiZndDs8YnI+DQomZ3Q7IEFGQUlLIE1QTFMgZG9lc24ndCBoYXZlIGEgbG9jYWxseSBkZWZp bmVkIEVDTVAgaGFzaCBmdW5jdGlvbiBpbiBldmVyeQ0KaG9wLjxicj4NCiZndDsgVFJJTEwgZG9l cywgd2hpY2ggbWFrZXMgdGhlc2UgYXNwZWN0cyBkaWZmZXJlbnQuPGJyPg0KJmd0Ozxicj4NCiZn dDsgUmVnYXJkcyw8YnI+DQomZ3Q7ICZuYnNwOyBFcmlrPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+ DQomZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsmZ3Q7IEZyb206 IDwvZm9udD48YSBocmVmPSJtYWlsdG86dHJpbGwtYm91bmNlc0BpZXRmLm9yZyI+PGZvbnQgc2l6 ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291cmllciBOZXciPjx1PnRyaWxsLWJvdW5jZXNAaWV0Zi5v cmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPg0KWzwvZm9u dD48YSBocmVmPSJtYWlsdG86dHJpbGwtYm91bmNlc0BpZXRmLm9yZyI+PGZvbnQgc2l6ZT0yIGNv bG9yPWJsdWUgZmFjZT0iQ291cmllciBOZXciPjx1Pm1haWx0bzp0cmlsbC1ib3VuY2VzQGlldGYu b3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5dDQpPbiA8 YnI+DQomZ3Q7Jmd0OyBCZWhhbGYgT2YgRXJpayBOb3JkbWFyazxicj4NCiZndDsmZ3Q7IFNlbnQ6 IEZyaWRheSwgQXByaWwgMjcsIDIwMTIgNDowNyBQTTxicj4NCiZndDsmZ3Q7IFRvOiBTYW50b3No IFJhamFnb3BhbGFuPGJyPg0KJmd0OyZndDsgQ2M6IDwvZm9udD48YSBocmVmPW1haWx0bzp0cmls bEBpZXRmLm9yZz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIE5ldyI+PHU+ dHJpbGxAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBO ZXciPjxicj4NCiZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBbdHJpbGxdIFRSSUxMIE9BTSBSZXF1aXJl bWVudHM6IGF2YWlsYWJsZSBwYXRoczxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgT24gNC8y Ny8xMiAyOjE1IFBNLCBTYW50b3NoIFJhamFnb3BhbGFuIHdyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0OyBJIGFncmVlLCB0aGUgd29yZGluZyBuZWVkcyB0byBiZSB0aWdo dGVuZWQgdG8gc2F5ICZxdW90O2FsbA0KcG9zc2libGUgZWNtcCA8YnI+DQomZ3Q7Jmd0OyZndDsg cGF0aHMmcXVvdDsgcmF0aGVyIHRoYW4gJnF1b3Q7YWxsIGF2YWlsYWJsZSBwYXRocyZxdW90Oy4g QW4NCm9wZXJhdG9yIHdvcmtpbmcgb3V0PGJyPg0KJmd0OyZndDsmZ3Q7IFIxLVIyIGNvbW11bmlj YXRpb24gaXMgaW50ZXJlc3RlZCBpbiBhbGwgcG9zc2libGUgcGF0aHMgZGF0YQ0KdHJhZmZpYyA8 YnI+DQomZ3Q7Jmd0OyZndDsgY291bGQgdGFrZSByYXRoZXIgdGhhbiBhbGwgdGhlb3JldGljYWxs eSBhdmFpbGFibGUgcGF0aHMuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7IFRoZSBpc3N1ZSBpcyB0aGF0IHRoZXJlIGlzIG5vdGhpbmcgaW4gdGhlIFRSSUxMIGRhdGFw bGFuZSBub3INCklTLUlTIDxicj4NCiZndDsmZ3Q7IGNvbnRyb2wgcGxhbmUgd2hpY2ggaGVscHMg dGhlIG9wZXJhdG9yIGRldGVybWluZSB0aGF0IHNvbWUgcGF0aHMNCjxicj4NCiZndDsmZ3Q7ICh0 aHJvdWdoIFJCMTIxIGFuZCBSQjExMiBpbiB0aGUgZXhhbXBsZSkgYXJlIG5vdCBwb3NzaWJsZTsg dGhlDQpFQ01QIDxicj4NCiZndDsmZ3Q7IGlucHV0IGFuZCBoYXNoaW5nIGlzIGEgY29tcGxldGVs eSBsb2NhbCBtYXR0ZXIgb24gZWFjaCBSQnJpZGdlLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgSXQgaXNuJ3QgdXNlZnVsIHRvIHN0YXRlIGEgcmVxdWlyZW1lbnQgYXJvdW5kIHNvbWV0aGlu ZyB0aGF0IGNhbid0DQpiZSA8YnI+DQomZ3Q7Jmd0OyBkZXRlcm1pbmVkLjxicj4NCiZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyBFcmlrPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgRnJvbTogRXJpayBO b3JkbWFyayZsdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86bm9yZG1hcmtAYWNtLm9yZz48Zm9udCBz aXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIE5ldyI+PHU+bm9yZG1hcmtAYWNtLm9yZzwv dT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0Ozxicj4NCiZn dDsmZ3Q7Jmd0OyBUbzogPC9mb250PjxhIGhyZWY9bWFpbHRvOnRyaWxsQGlldGYub3JnPjxmb250 IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkNvdXJpZXIgTmV3Ij48dT50cmlsbEBpZXRmLm9yZzwv dT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KJmd0OyZn dDsmZ3Q7IERhdGU6IDA0LzI3LzIwMTIgMDk6NTMgQU08YnI+DQomZ3Q7Jmd0OyZndDsgU3ViamVj dDogW3RyaWxsXSBUUklMTCBPQU0gUmVxdWlyZW1lbnRzOiBhdmFpbGFibGUgcGF0aHMgU2VudA0K Ynk6PGJyPg0KJmd0OyZndDsmZ3Q7IDwvZm9udD48YSBocmVmPSJtYWlsdG86dHJpbGwtYm91bmNl c0BpZXRmLm9yZyI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291cmllciBOZXciPjx1 PnRyaWxsLWJvdW5jZXNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0i Q291cmllciBOZXciPjxicj4NCiZndDsmZ3Q7Jmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsmZ3Q7 Jmd0OyAtLTxicj4NCiZndDsmZ3Q7Jmd0OyAtLTxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 Jmd0OyBUd28gcmVxdWlyZW1lbnRzIHVzZSB0aGUgd29yZGluZyAmcXVvdDthbGwgYXZhaWxhYmxl IHBhdGhzLiZxdW90Ow0KYW5kICZxdW90O2FsbCA8YnI+DQomZ3Q7Jmd0OyZndDsgYXZhaWxhYmxl IEVDTVAgcGF0aHMuJnF1b3Q7LCByZXNwZWN0aXZlbHkgYW5kIEknbSBub3Qgc3VyZQ0KSSBrbm93 IHdoYXQgPGJyPg0KJmd0OyZndDsmZ3Q7IHRoYXQ8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsmZ3Q7IG1lYW5zLjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 Jmd0OyBUYWtlIHRoZSBmb2xsb3dpbmcgZXhhbXBsZSBwaWN0dXJlOjxicj4NCiZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0OyBSMTxicj4NCiZndDsmZ3Q7Jmd0OyAvIFw8YnI+DQomZ3Q7Jmd0 OyZndDsgLyBcPGJyPg0KJmd0OyZndDsmZ3Q7IC8gXDxicj4NCiZndDsmZ3Q7Jmd0OyAvIFw8YnI+ DQomZ3Q7Jmd0OyZndDsgLyBcPGJyPg0KJmd0OyZndDsmZ3Q7IFJCMTEgUkIxMjxicj4NCiZndDsm Z3Q7Jmd0OyAvIFwgLyBcPGJyPg0KJmd0OyZndDsmZ3Q7IC8gXCAvIFw8YnI+DQomZ3Q7Jmd0OyZn dDsgUkIxMTEgUkIxMTIgUkIxMjEgUkIxMjI8YnI+DQomZ3Q7Jmd0OyZndDsgXCBcIC8gLzxicj4N CiZndDsmZ3Q7Jmd0OyBcIFwgLyAvPGJyPg0KJmd0OyZndDsmZ3Q7IFwgXC8gLzxicj4NCiZndDsm Z3Q7Jmd0OyAtLS0tLS1SMi0tLS0tLTxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0 OyBXZSBjYW4gc2VlIHRoYXQgdGhlcmUgYXJlIDQgcGF0aHMgd2l0aCAzIGhvcHMgdG8gZ2V0IGZy b20NClIxIHRvIFIyLCA8YnI+DQomZ3Q7Jmd0OyZndDsgd2l0aCB0d28gbGF5ZXJzIG9mIEVDTVAg ZGVjaXNpb25zLiBCdXQgaG93IG1hbnkgYXZhaWxhYmxlDQpwYXRocyBhcmU8YnI+DQomZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7IHRoZXJlPzxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0OyBHaXZlbiB0aGF0IHRoZSBSQnJpZGdlcyBtYWtlIGluZGVwZW5k ZW50IEVDTVAgZGVjaXNpb25zLCBhbmQNCmhvdyA8YnI+DQomZ3Q7Jmd0OyZndDsgdGhleSBkbyB0 aGF0IGlzIGEgbG9jYWwgbWF0dGVyLCBpdCBjb3VsZCBiZSB0aGUgY2FzZSB0aGF0DQpmb3IgYW55 IDxicj4NCiZndDsmZ3Q7Jmd0OyBwYWNrZXQsIGlmIFIxIHBpY2tzIHRoZSBsZWZ0IGxpbmssIHRo ZW4gUjExIHdvdWxkIGFsc28gcGljaw0KdGhlIGxlZnQgPGJyPg0KJmd0OyZndDsmZ3Q7IGxpbms7 IGlmPGJyPg0KJmd0OyZndDsmZ3Q7IFIxIHBpY2tzIHRoZSByaWdodCBsaW5rLCB0aGVuIFIxMiBh bHNvIHBpY2tzIHRoZSByaWdodCBsaW5rLjxicj4NCiZndDsmZ3Q7Jmd0OyBUaHVzIHRoZXJlIHdv dWxkIGJlIG5vIHBhY2tldCAoZGF0YSBvciBPQU0pIHRoYXQgd291bGQgY2F1c2UNCnBhY2tldHMg PGJyPg0KJmd0OyZndDsmZ3Q7IGJldHdlZW4gUjEgYW5kIFIyIHRvIHBhc3MgdmlhIFJCMTEyIG9y IFJCMTIxLjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBFdmVuIGlmIHdlIGln bm9yZSB0aGF0IGFzIHVubGlrZWx5LCB0aGVyZSBpcyBzdGlsbCB0aGUgZmFjdA0KdGhhdCBSMSA8 YnI+DQomZ3Q7Jmd0OyZndDsgY2FuJ3QgZWFzaWx5IHRlbGwgaG93IG1hbnkgKHNob3J0ZXN0KSBw YXRocyB0aGVyZSBtaWdodCBiZQ0KYmV0d2VlbiA8YnI+DQomZ3Q7Jmd0OyZndDsgaXQgYW5kIFIy LiBXaXRoIHNpbmdsZS1sZXZlbCBUUklMTCB0aGUgTFNEQiBjb3VsZCBiZSB1c2VkDQp0byB0ZWxs LCA8YnI+DQomZ3Q7Jmd0OyZndDsgYnV0IGlmPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7Jmd0OyB3ZSBldmVyIGdvIHRvIG11bHRpLWxldmVsIHRoYXQgd291bGRuJ3Qg YmUgdGhlIGNhc2UgYW55IG1vcmUuPGJyPg0KJmd0OyZndDsmZ3Q7IEFuZCBldmVuIGlmIFIxIGtu b3dzIHRoYXQgdGhlcmUgYXJlIDQgcG90ZW50aWFsIHBhdGhzLCBpdA0KY2FuJ3QgPGJyPg0KJmd0 OyZndDsmZ3Q7IGZvcm1hdDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyZndDsgYSBkYXRhIHBhY2tldCAob3IgZm9ybWF0IHRoZSBmbG93IGVudHJvcHkgaW4gYW4gT0FN IHBhY2tldCkNCmluIHN1Y2ggPGJyPg0KJmd0OyZndDsmZ3Q7IGEgd2F5IHRoYXQgcGFydGljdWxh ciBwYXRocyBnZXQgY2hvc2VuIGJ5IGRvd25zdHJlYW0gRUNNUA0KZGVjaXNpb25zLjxicj4NCiZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBUaHVzIGZvciBhbnkgbm90aW9uIG9mICZxdW90 O2FsbCBhdmFpbGFibGUgcGF0aHMmcXVvdDsgdGhhdA0KbWFrZSBzZW5zZSB0byBtZSwgPGJyPg0K Jmd0OyZndDsmZ3Q7IHdlJ2QgbmVlZCBhbiBPQU0gYXBwcm9hY2ggdGhhdCBjYW4gZXhwbG9yZSB0 aGUgdG9wb2xvZ3kgb25lDQpob3AgYXQgYSA8YnI+DQomZ3Q7Jmd0OyZndDsgdGltZSBhbmQgYXQg ZWFjaCBob3AgZXhwbG9yZSBhbGwgdGhlIHBvc3NpYmxlIEVDTVAgY2hvaWNlcy4NClVzaW5nIDxi cj4NCiZndDsmZ3Q7Jmd0OyB0aGUgZW50cm9weSBkb2Vzbid0IGhlbHAgd2l0aCB0aGlzIChidXQg dGhlIGVudHJvcHkgaXMgY3JpdGljYWwNCmZvciA8YnI+DQomZ3Q7Jmd0OyZndDsgZm9sbG93aW5n IHRoZSBwYXRoIHRha2VuIGJ5IGEgcGFydGljdWxhciBmbG93IG9mIGRhdGEgcGFja2V0cykuPGJy Pg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEhlbmNlIGl0IHdvdWxkIGJlIGdvb2Qg dG8gY2xhcmlmeSB3aGF0IHRoZSBhc3N1bXB0aW9ucyBhcmUNCmJlaGluZCA8YnI+DQomZ3Q7Jmd0 OyZndDsgdGhpczxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsg bm90aW9uIG9mIGFsbCBhdmFpbGFibGUgcGF0aHMuPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsmZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7Jmd0OyZndDsgRXJpazxicj4NCiZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCiZndDsmZ3Q7Jmd0OyB0cmlsbCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7 Jmd0OyZndDsgPC9mb250PjxhIGhyZWY9bWFpbHRvOnRyaWxsQGlldGYub3JnPjxmb250IHNpemU9 MiBjb2xvcj1ibHVlIGZhY2U9IkNvdXJpZXIgTmV3Ij48dT50cmlsbEBpZXRmLm9yZzwvdT48L2Zv bnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KJmd0OyZndDsmZ3Q7 IDwvZm9udD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJp bGw+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291cmllciBOZXciPjx1Pmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJpbGw8L3U+PC9mb250PjwvYT48Zm9udCBz aXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyB0cmlsbCBtYWlsaW5nIGxpc3Q8 YnI+DQomZ3Q7Jmd0OyA8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86dHJpbGxAaWV0Zi5vcmc+PGZvbnQg c2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291cmllciBOZXciPjx1PnRyaWxsQGlldGYub3JnPC91 PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQomZ3Q7Jmd0 OyA8L2ZvbnQ+PGEgaHJlZj1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Ry aWxsPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkNvdXJpZXIgTmV3Ij48dT5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsPC91PjwvZm9udD48L2E+PGZvbnQg c2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDs8YnI+DQom Z3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K Jmd0OyB0cmlsbCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDwvZm9udD48YSBocmVmPW1haWx0bzp0 cmlsbEBpZXRmLm9yZz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIE5ldyI+ PHU+dHJpbGxAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iQ291cmll ciBOZXciPjxicj4NCiZndDsgPC9mb250PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby90cmlsbD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJDb3VyaWVy IE5ldyI+PHU+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmlsbDwvdT48 L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQp0cmlsbCBtYWlsaW5n IGxpc3Q8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291cmllciBOZXciPjx1 Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj1tYWlsdG86dHJpbGxAaWV0Zi5vcmc+PGZvbnQgc2l6 ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291cmllciBOZXciPjx1PnRyaWxsQGlldGYub3JnPC91Pjwv Zm9udD48L2E+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291cmllciBOZXciPjx1Pjxi cj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3RyaWxsPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkNvdXJpZXIgTmV3Ij48dT5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsPC91PjwvZm9udD48L2E+ PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnRyaWxsIG1haWxpbmcgbGlzdDwvZm9u dD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIE5ldyI+PHU+PGJyPg0KPC91 PjwvZm9udD48YSBocmVmPW1haWx0bzp0cmlsbEBpZXRmLm9yZz48Zm9udCBzaXplPTIgY29sb3I9 Ymx1ZSBmYWNlPSJDb3VyaWVyIE5ldyI+PHU+dHJpbGxAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48 Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIE5ldyI+PHU+PGJyPg0KPC91Pjwv Zm9udD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJpbGw+ PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291cmllciBOZXciPjx1Pmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJpbGw8L3U+PC9mb250PjwvYT48Zm9udCBzaXpl PTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCjwvZm9udD48dHQ+PGZvbnQgc2l6ZT0yPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KdHJpbGwgbWFp bGluZyBsaXN0PGJyPg0KdHJpbGxAaWV0Zi5vcmc8YnI+DQo8L2ZvbnQ+PC90dD48YSBocmVmPWh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJpbGw+PHR0Pjxmb250IHNpemU9 Mj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsPC9mb250PjwvdHQ+ PC9hPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+DQo= --=_alternative 006E4DAE882579F0_=-- --=_related 006E4DAD882579F0_= Content-Type: image/gif Content-ID: <_1_0B8E72800B8E67F0006E4AE5882579F0> Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --=_related 006E4DAD882579F0_=-- From tsenevir@cisco.com Mon Apr 30 13:13:50 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4CB21F878A; Mon, 30 Apr 2012 13:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.618 X-Spam-Level: X-Spam-Status: No, score=-7.618 tagged_above=-999 required=5 tests=[AWL=0.560, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42] 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 JrAkVyoTFVdB; Mon, 30 Apr 2012 13:13:47 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id D304421F8786; Mon, 30 Apr 2012 13:13:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tsenevir@cisco.com; l=54606; q=dns/txt; s=iport; t=1335816828; x=1337026428; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=gebS7Odp2A2fVz1zkINBAuBx+HPCwQt6X/Gsl/b04Ps=; b=MWSe/dABEopp+W+VkwgkiBABRU6gaiK6WxuWB9gvIj/02uEiPRI5X7zz qG7kEkWf6smtjelroBIzE3zluW+Hgi41FR4QxghDEnq5qCMsXoj4ERON5 D3P04eee/llS0pidEy3Ny2Run7JzvTNJ1EOXTUzoPu1HAWjLRowGx3PFR I=; X-Files: image001.gif : 105 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoEFAIPxnk+rRDoI/2dsb2JhbABBA4JGgk5VqXOBcoEOgQeCCQEBAQQBAQECBwYBBwIHAggBAjQKCwwEAgEGAg4DAwEBAQEFAQICBhABBgECAgIBAQUQAQUEBQEfCQgBAQQSAQYCEweHXQMKAQuaOY0TiRANiVOKDINZghI1YwSIZIQXgyCBd48rgxqBaYMI X-IronPort-AV: E=Sophos;i="4.75,506,1330905600"; d="gif'147?scan'147,208,217,147";a="42849249" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 30 Apr 2012 20:13:47 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3UKDld7002360; Mon, 30 Apr 2012 20:13:47 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Apr 2012 13:13:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CD270D.BF909872" Date: Mon, 30 Apr 2012 13:13:45 -0700 Message-ID: <344037D7CFEFE84E97E9CC1F56C5F4A5010A332E@xmb-sjc-214.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [trill] TRILL OAM Requirements: available paths Thread-Index: Ac0nDIgn+jimHnsATCCfrJ6mcBEZ0gAASD0g References: <4F9ACE0E.7030408@sonic.net> <4F9ACF05.9070302@acm.org><4F9B2697.8080401@acm.org><344037D7CFEFE84E97E9CC1F56C5F4A5010A2FFF@xmb-sjc-214.amer.cisco.com><4F9CB95E.4030902@acm.org><344037D7CFEFE84E97E9CC1F56C5F4A5010A30CC@xmb-sjc-214.amer.cisco.com> <344037D7CFEFE84E97E9CC1F56C5F4A5010A32ED@xmb-sjc-214.amer.cisco.com> From: "Tissa Senevirathne (tsenevir)" To: "Santosh Rajagopalan" X-OriginalArrivalTime: 30 Apr 2012 20:13:46.0904 (UTC) FILETIME=[BFC52980:01CD270D] Cc: Donald Eastlake , trill-bounces@ietf.org, David M Bond , trill@ietf.org Subject: Re: [trill] TRILL OAM Requirements: available paths X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 20:13:50 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD270D.BF909872 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CD270D.BF909872" ------_=_NextPart_002_01CD270D.BF909872 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 U3VubnkNCg0KIA0KDQpBcmUgd2UgdGFsa2luZyBhYm91dCBhIHNpbmdsZSBmbG93IGhlcmUgb3Ig bXVsdGlwbGUgZmxvd3MgPw0KDQogDQoNCiANCg0KRnJvbTogdHJpbGwtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOnRyaWxsLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTYW50b3NoIFJh amFnb3BhbGFuDQpTZW50OiBNb25kYXksIEFwcmlsIDMwLCAyMDEyIDE6MDUgUE0NClRvOiBUaXNz YSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKQ0KQ2M6IERvbmFsZCBFYXN0bGFrZTsgdHJpbGwtYm91 bmNlc0BpZXRmLm9yZzsgRGF2aWQgTSBCb25kOyB0cmlsbEBpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFt0cmlsbF0gVFJJTEwgT0FNIFJlcXVpcmVtZW50czogYXZhaWxhYmxlIHBhdGhzDQoNCiANCg0K VGlzc2EsIA0KSGFzaCBwb2xhcml6YXRpb24gY2FuIHJlc3VsdCBpbiBzb21lIG9mIHRoZSBlY21w IHBhdGhzIGJlaW5nIHVudXRpbGl6ZWQuIEluIEVyaWMncyBleGFtcGxlOiANCg0KDQogICAgICAg ICAgICAgICBSMQ0KICAgICAgICAgICAgICAvICBcDQogICAgICAgICAgICAgLyAgICBcDQogICAg ICAgICAgICAvICAgICAgXA0KICAgICAgICAgICAvICAgICAgICBcDQogICAgICAgICAgLyAgICAg ICAgICBcDQogICAgICAgUkIxMSAgICAgICAgICBSQjEyDQogICAgICAgLyAgXCAgICAgICAgICAv ICBcDQogICAgICAvICAgIFwgICAgICAgIC8gICAgXA0KICAgUkIxMTEgIFJCMTEyICBSQjEyMSAg UkIxMjINCiAgICAgIFwgICAgICBcICAgIC8gICAgICAvDQogICAgICAgXCAgICAgIFwgIC8gICAg ICAvDQogICAgICAgIFwgICAgICBcLyAgICAgIC8NCiAgICAgICAgIC0tLS0tLVIyLS0tLS0tDQoN CklmIFIxIGFuZCBSQjEyIHVzZSB0aGUgc2FtZSBoYXNoIHBvbHlub21pYWwgJiBzZWVkLCB0aGVu ICphbGwqIGZsb3dzIHdoaWNoIGFycml2ZSBhdCBSQjEyIHdpbGwgZ28gYWxvbmcgdGhlIGxpbmsg dG8gUkIxMjIgLSB0aGUgbGluayB0byBSQjEyMSBmcm9tIFJCMTIgd2lsbCBuZXZlciBiZSB1c2Vk LiBUaGUgT0FNIHRvb2wgc2hvdWxkIGFsbG93IHVzIHRvIGZpZ3VyZSBvdXQgdGhpcyBpcyBoYXBw ZW5pbmcsIGluc3RlYWQgb2YgZ2l2aW5nIHVzIHJlZHVuZGFudCBpbmZvcm1hdGlvbiBhbHJlYWR5 IGF2YWlsYWJsZSBpbiBJU0lTIGxzZGIuIA0KSSB3b3VsZCBoZXNpdGF0ZSB0byBjYWxsIHRoaXMg YSBkZWZlY3QuIFdoaWxlIGl0IGlzIHRydWUgdGhhdCBhIGxvdCBvZiBhc2ljcyBoYXZlIGNvdW50 ZXJtZWFzdXJlcyBmb3IgdGhpcyAodXN1YWxseSBieSBpbmNsdWRpbmcgYSByYW5kb20gc2VlZCBh cyBpbnB1dCB0byB0aGUgaGFzaCBwb2x5bm9taWFsKSwgeW91IGNhbm5vdCBydWxlIHRoaXMgb3V0 IDEwMCUuIFBsZWFzZSBsb29rIGF0IHRoaXMgZG9jdW1lbnRhdGlvbiBmcm9tIGEgd2VsbCBrbm93 biBuZXR3b3JraW5nIGNvbXBhbnkgOy0pIA0KaHR0cDovL3d3dy5jaXNjby5jb20vZW4vVVMvZG9j cy9pb3MvMTJfNHQvaXBfbWNhc3QvY29uZmlndXJhdGlvbi9ndWlkZS9tY3Rsc3BsdC5odG1sI3dw MTA2NDUwMSANCg0KLS0gDQpTdW5ueSANCg0KDQoNCg0KRnJvbTogICAgICAgICJUaXNzYSBTZW5l dmlyYXRobmUgKHRzZW5ldmlyKSIgPHRzZW5ldmlyQGNpc2NvLmNvbT4gDQpUbzogICAgICAgIERh dmlkIE0gQm9uZC9CZWRmb3JkL0lCTUBJQk1VUyANCkNjOiAgICAgICAgRG9uYWxkIEVhc3RsYWtl IDxkM2UzZTNAZ21haWwuY29tPiwgdHJpbGwtYm91bmNlc0BpZXRmLm9yZywgdHJpbGxAaWV0Zi5v cmcgDQpEYXRlOiAgICAgICAgMDQvMzAvMjAxMiAxMjoyOSBQTSANClN1YmplY3Q6ICAgICAgICBS ZTogW3RyaWxsXSBUUklMTCBPQU0gUmVxdWlyZW1lbnRzOiBhdmFpbGFibGUgcGF0aHMgDQpTZW50 IGJ5OiAgICAgICAgdHJpbGwtYm91bmNlc0BpZXRmLm9yZyANCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCg0KDQoNCg0KTGV0IG1lIHN0YXJ0IGZyb20gdGhlIGJhc2ljcy4gDQog IA0KMS4gICAgICAgVFJJTEwgaXMgYWxsIGFib3V0IG11bHRpcGxlIGFjdGl2ZSBwYXRocy4gDQoy LiAgICAgICBNdWx0aXBsZSBhY3RpdmUgcGF0aHMgYXJlIGRlcml2ZWQgZnJvbSBsZWFzdCBjb3N0 IHBhdGhzIHRvIGEgc3BlY2lmaWMgZGVzdGluYXRpb25zLiANCjMuICAgICAgIFdlbGwgZGVmaW5l ZCBhbmQgaW1wbGVtZW50ZWQgSGFzaGluZyBhbGdvcml0aG1zIHByb3ZpZGUgYW4gYWxtb3N0IGV2 ZW4gZGlzdHJpYnV0aW9uIGFjcm9zcyBhbGwgb2YgdGhlIGF2YWlsYWJsZSBsZWFzdCBjb3N0IHBh dGhzIHRvIGEgZGVzdGluYXRpb24gDQo0LiAgICAgICBJZiBhIGdpdmVuIGZsb3cg4oCceOKAnSBk b2VzIG5vdCBtYXAgdG8gIGEgc3BlY2lmaWMgbGVhc3QgY29zdCBwYXRoLCBkb2VzIG5vdCBtYXAg dG8gYSBzcGVjaWZpYyBsZWFzdCBjb3N0IHBhdGggZG9lcyBub3QgbWVhbiBhbm90aGVyIGZsb3cg 4oCceeKAnSB0byB0aGUgc2FtIGRlc3RpbmF0aW9uIHdpbGwgbm90IG1hcCB0byB0aGUgdGhhdCBw YXRoLiANCjUuICAgICAgIFdlbGwgaW1wbGVtZW50ZWQgaGFzaGluZyBhbGdvcml0aG1zIHByb3Zp ZGUgZXZlbiBkaXN0cmlidXRpb24gb2YgZmxvd3MuIA0KNi4gICAgICAgSGVuY2UgaXQgaXMgaW1w b3J0YW50IHRvIGhhdmUgYWJpbGl0eSB0byB0ZXN0IGFsbCBhdmFpbGFibGUgbGVhc3QgY29zdCBw YXRocyB0byBhIGRlc3RpbmF0aW9uLiANCjcuICAgICAgIEl0IGlzIGFuIGltcGxlbWVudGF0aW9u IGRlZmVjdCwgSWYgdGhlcmUgaXMgYW4gaW1wbGVtZW50YXRpb24gb3V0IHRoZXJlIHdoaWNoIGRv ZXMgbm90IGhhc2ggZmxvd3MgKG92ZXIgYSBsb25nZXIgc2FtcGxpbmcgcGVyaW9kKSAgaW4gdG8g YSBzcGVjaWZpYyDigJxsZWFzdCBjb3N0IHBhdGjigJ0gb2Ygc2V0IG9mIGxlYXN0IGNvc3QgcGF0 aHMgdG8gYSBkZXN0aW5hdGlvbiwgYW1vbmcgYWxsIGF2YWlsYWJsZSDigJxsZWFzdCBjb3N0IHBh dGhz4oCdIHRvIHRoYXQgZGVzdGluYXRpb24uIA0KICANCkZyb206IERhdmlkIE0gQm9uZCBbbWFp bHRvOmRtYm9uZEB1cy5pYm0uY29tIDxtYWlsdG86ZG1ib25kQHVzLmlibS5jb20+IF0gDQpTZW50 OiBNb25kYXksIEFwcmlsIDMwLCAyMDEyIDg6MzkgQU0NClRvOiBUaXNzYSBTZW5ldmlyYXRobmUg KHRzZW5ldmlyKQ0KQ2M6IERvbmFsZCBFYXN0bGFrZTsgdHJpbGxAaWV0Zi5vcmc7IHRyaWxsLWJv dW5jZXNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdHJpbGxdIFRSSUxMIE9BTSBSZXF1aXJlbWVu dHM6IGF2YWlsYWJsZSBwYXRocyANCiAgDQoNCkp1c3QgYSBxdWVzdGlvbiBjb21pbmcgZnJvbSB0 aGlzIGNvbnZlcnNhdGlvbiB0aGF0IEkgd2FudCB0byBjbGFyaWZ5Og0KDQpTbyB3ZSBoYXZlICdh bGwgcG9zc2libGUgcGF0aHMnICgxKSB3aGljaCBjb3VsZCBpbmNsdWRlIG5vbi1sZWFzdCBjb3N0 IHBhdGhzIGFuZCBzbyBvZiBjb3Vyc2Ugd2UgZG9uJ3Qgd2FudCB0byB1c2UgdGhpcyBkZWZpbml0 aW9uLg0KDQpUaGVuIHdlIGhhdmUgJ2FsbCBlY21wIHBhdGhzJyBvciAnYWxsIGxlYXN0IGNvc3Qg cGF0aHMnICgyKSB3aGljaCBNQVkgaW5jbHVkZSBwYXRocyBuZXZlciBjaG9zZW4gYnkgYSB0cmFu c2l0IFJicmlkZ2UgYmVjYXVzZSBvZiB0aGUgbG9jYWwgaGFzaGluZyBjaG9pY2VzLg0KDQpUaGVu IHdlIGhhdmUgJ2FsbCB0aGUgbGVhc3QgY29zdCBwYXRocyB3aGljaCBtYXkgYmUgY2hvc2VuIGdp dmVuIHRoZSBoYXNoaW5nIGltcGxlbWVudGF0aW9uIG9uIHRoZSBsb2NhbCBSYnJpZGdlcycgKDMp Lg0KDQpJIHdvbmRlciBpZiBjaG9pY2UgKDIpIGlzIHVzZWZ1bCBvciBkbyB3ZSBvbmx5IHJlYWxs eSBjYXJlIGFib3V0IGNob2ljZSAoMykuIEZvciBpbnN0YW5jZSwgaWYgeW91IGhhdmUgMTYgZXF1 YWwgY29zdCBwYXRocyBmcm9tIEEgdG8gQiBhbmQgeW91ciBoYXNoaW5nIG9ubHkgd2lsbCBldmVy IHVzZSAyIG9mIHRob3NlIHBhdGhzIGRvIHdlIGNhcmUgYWJvdXQgcmVwb3J0aW5nIGJhY2sgZWNt cCBwYXRocyB0aGF0IHdpbGwgbmV2ZXIgaW4gcHJhY3RpY2UgYmUgdXNlZD8gUGVyaGFwcyB0aGUg ZGVmaW5pdGlvbiBzaG91bGQgYmUgdGlnaHRlbmVkIHRvIG9ubHkgcmVxdWlyZSBkZXRlcm1pbmF0 aW9uIG9mIGFsbCBsZWFzdCBjb3N0IHBhdGhzIHRoYXQgY291bGQgYmUgdXNlZCBnaXZlbiB0aGUg bG9jYWwgaGFzaGluZyBpbXBsZW1lbnRhdGlvbi4gT3IgYW0gSSBtaXN1bmRlcnN0YW5kaW5nIHRo ZSBjb252ZXJzYXRpb24gYW5kIGlzIHRoaXMgYWxyZWFkeSB0aGUgcG9pbnQgYmVpbmcgbWFkZSBi ZXR3ZWVuIHRoZW9yZXRpY2FsIHBhdGhzIGFuZCBsZWFzdCBjb3N0IHBhdGhzLg0KDQpUaGFua3Ms DQpEYXZpZA0KDQogIlRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpIiAtLS0wNC8yOS8yMDEy IDExOjQzOjA3IFBNLS0tSSBsaWtlIHRoYXQgRG9uYWxkLi4gV2UgY2FuIHVzZSAiYWxsIGxlYXN0 IGNvc3QgcGF0aHMiLCB0aGF0IGlzIHRlY2huaWNhbGx5IG1vcmUgcHJlY2lzZSBhbmQgcmVwcmVz ZQ0KDQpGcm9tOiAiVGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZpcikiIDx0c2VuZXZpckBjaXNj by5jb20gPG1haWx0bzp0c2VuZXZpckBjaXNjby5jb20+ID4NClRvOiAiRG9uYWxkIEVhc3RsYWtl IiA8ZDNlM2UzQGdtYWlsLmNvbSA8bWFpbHRvOmQzZTNlM0BnbWFpbC5jb20+ID4sIDx0cmlsbEBp ZXRmLm9yZyA8bWFpbHRvOnRyaWxsQGlldGYub3JnPiA+DQpEYXRlOiAwNC8yOS8yMDEyIDExOjQz IFBNDQpTdWJqZWN0OiBSZTogW3RyaWxsXSBUUklMTCBPQU0gUmVxdWlyZW1lbnRzOiBhdmFpbGFi bGUgcGF0aHMNClNlbnQgYnk6IHRyaWxsLWJvdW5jZXNAaWV0Zi5vcmcgPG1haWx0bzp0cmlsbC1i b3VuY2VzQGlldGYub3JnPiAgDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoN Cg0KDQoNCg0KSSBsaWtlIHRoYXQgRG9uYWxkLi4gV2UgY2FuIHVzZSAiYWxsIGxlYXN0IGNvc3Qg cGF0aHMiLCB0aGF0IGlzIHRlY2huaWNhbGx5IG1vcmUgcHJlY2lzZSBhbmQgcmVwcmVzZW50IGV4 YWN0bHkgd2hhdCBJUy1JUyBkb2VzLg0KDQpUaGFua3MNClRpc3NhDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiB0cmlsbC1ib3VuY2VzQGlldGYub3JnIDxtYWlsdG86dHJpbGwt Ym91bmNlc0BpZXRmLm9yZz4gIFttYWlsdG86dHJpbGwtYm91bmNlc0BpZXRmLm9yZyA8bWFpbHRv OnRyaWxsLWJvdW5jZXNAaWV0Zi5vcmc+IF0gT24gQmVoYWxmIE9mIERvbmFsZCBFYXN0bGFrZQ0K U2VudDogU3VuZGF5LCBBcHJpbCAyOSwgMjAxMiA2OjI3IFBNDQpUbzogdHJpbGxAaWV0Zi5vcmcg PG1haWx0bzp0cmlsbEBpZXRmLm9yZz4gDQpTdWJqZWN0OiBSZTogW3RyaWxsXSBUUklMTCBPQU0g UmVxdWlyZW1lbnRzOiBhdmFpbGFibGUgcGF0aHMNCg0KSSBkb24ndCB0aGluayB0aGUgd29yZGlu ZyAiYWxsIHBhdGhzIiBzaG91bGQgZXZlciBiZSB1c2VkLiBJZiB5b3UgdGhlIGl0IGxpdGVyYWxs eSwgaXQgd291bGQgZXZlbiBpbmNsdWRlIHBhdGhzIHRoYXQgZ28gdGhyb3VnaCBzb21lIFJCcmlk Z2VzIG1vcmUgdGhhbiBvbmNlLg0KDQpJIGRvbid0IHBhcnRpY3VsYXJseSBsaWtlICJhbGwgRUNN UCBwYXRocyIgZWl0aGVyLiBJIHRoaW5rIHRoZSBjbGVhcmVzdCB3b3JkaW5nIGlzICJhbGwgbGVh c3QgY29zdCBwYXRocyIgaWYgeW91IGFyZSB0YWxraW5nIGFib3V0IGtub3duIHVuaWNhc3QuIChB bmQgImFsbCBkaXN0cmlidXRpb24gdHJlZSBwYXRocyIgaWYgeW91IHdlcmUgdGFsa2luZyBhYm91 dCBtdWx0aS1kZXN0aW5hdGlvbiBmcmFtZXMuKQ0KDQpUaGFua3MsDQpEb25hbGQNCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09DQpEb25hbGQgRS4gRWFzdGxha2UgM3JkICAgKzEtNTA4LTMz My0yMjcwIChjZWxsKQ0KMTU1IEJlYXZlciBTdHJlZXQsIE1pbGZvcmQsIE1BIDAxNzU3IFVTQQ0K ZDNlM2UzQGdtYWlsLmNvbSA8bWFpbHRvOmQzZTNlM0BnbWFpbC5jb20+IA0KDQoNCk9uIFNhdCwg QXByIDI4LCAyMDEyIGF0IDExOjQ1IFBNLCBFcmlrIE5vcmRtYXJrIDxub3JkbWFya0BhY20ub3Jn IDxtYWlsdG86bm9yZG1hcmtAYWNtLm9yZz4gPiB3cm90ZToNCj4gT24gNC8yNy8xMiA1OjEyIFBN LCBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKSB3cm90ZToNCj4+DQo+PiBPZiBjb3Vyc2Ug aXQgaXMgcG9zc2libGUuIFRoZSBJUy1JUyB0b3BvbG9neSB0YWJsZSBwcm92aWRlIHRoZSANCj4+ IGluZm9ybWF0aW9uIG9uIGFsbCBhdmFpbGFibGUgRUNNUCBwYXRocyB0byBhIHNwZWNpZmljIGRl c3RpbmF0aW9uIA0KPj4gd2hlbiB0aGUgZWdyZXNzIFJCUmlkZ2Ugbmlja25hbWUgaXMga25vd24u IFRoYXQgaXMgd2hhdCBUUklMTCB1bmljYXN0IA0KPj4gZm9yd2FyZGluZyB0YWJsZSBhbGwgYWJv dXQuIE5vdCBzdXJlIHdoeSB5b3UgYXJlIHNheWluZyBpdCBpcyBub3QgDQo+PiBwb3NzaWJsZSB0 byBrbm93IGFsbCBFQ01QIHBhdGhzLg0KPg0KPg0KPiBZb3UgYXJlIHRhbGtpbmcgYWJvdXQgd2hh dCBTYW50b3NoIGNhbGxlZCAiYWxsIHRoZW9yZXRpY2FsbHkgYXZhaWxhYmxlIA0KPiBwYXRocyIu IFRob3NlIGNhbiBiZSBkZXRlcm1pbmVkIGZyb20gSVMtSVMuDQo+DQo+IEJ1dCB0aGUgZG9jdW1l bnQgdGFsa3MgYWJvdXQgImFsbCBhdmFpbGFibGUgcGF0aHMiIGFuZCBJIGRvbid0IGtub3cgDQo+ IHdoYXQgdGhhdCBpcyBzdXBwb3NlZCB0byBtZWFuLiBEbyB5b3UgaGF2ZSBhIHN1Y2NpbmN0IGRl ZmluaXRpb24/DQo+DQo+IFdoYXQgaXMgY2xlYXIgdG8gbWUgaXMgdGhhdCB0aGVyZSBjYW4gYmUg YSBzdWJzZXQgb2YgdGhlIHBhdGhzIHRoYXQgDQo+IGFyZSBkZXRlcm1pbmVkIGZyb20gSVMtSVMg dGhhdCB3b3VsZCBuZXZlciBiZSB1c2VkLCBiZWNhdXNlIG5vIGVudHJvcHkgDQo+IGluIGEgcGFj a2V0IHdvdWxkIGV2ZXJ5IHBpY2sgdGhhdCBwYXRoLg0KPg0KPiBJcyB0aGUgcmVxdWlyZW1lbnQg aW4gdGhlIGRvY3VtZW50IHRoYXQgdGhlIE9BTSBzb2x1dGlvbiBzaG91bGQgYmUgDQo+IGFibGUg dG8gdGVzdCB0aG9zZSBwYXRocz8NCj4NCj4NCj4+IFdoYXQgcGF0aCBhbW9uZyBhdmFpbGFibGUg cGF0aHMgdG8gYmUgc2VsZWN0ZWQgZm9yIGEgc3BlY2lmaWVkIGlzIGEgDQo+PiBsb2NhbCBtYXR0 ZXIuIFRoYXQgaXMgd2hhdCBhbGwgYWJvdXQgZmxvdyBlbnRyb3B5IGRpc2NvdmVyeS4gTGlrZSBJ IA0KPj4gc3RhdGVkIGVhcmxpZXIgaG93IGl0IGlzIGRpc2NvdmVyZWQgaXMgYSBmcmFtZXdvcmsg YW5kIHNvbHV0aW9uIGlzc3VlLg0KPg0KPg0KPiBBZ3JlZWQuDQo+DQo+DQo+PiBJZiB5b3UgbmVl ZCBzb21lIHJlZmVyZW5jZSBob3cgaXQgaXMgZG9uZSBpbiB0aGUgTVBMUyB3b3JsZCBSRkMgNDM3 OSANCj4+IGlzIGEgZ29vZCByZWZlcmVuY2UuDQo+DQo+DQo+IEFGQUlLIE1QTFMgZG9lc24ndCBo YXZlIGEgbG9jYWxseSBkZWZpbmVkIEVDTVAgaGFzaCBmdW5jdGlvbiBpbiBldmVyeSBob3AuDQo+ IFRSSUxMIGRvZXMsIHdoaWNoIG1ha2VzIHRoZXNlIGFzcGVjdHMgZGlmZmVyZW50Lg0KPg0KPiBS ZWdhcmRzLA0KPiAgIEVyaWsNCj4NCj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ PiBGcm9tOiB0cmlsbC1ib3VuY2VzQGlldGYub3JnIDxtYWlsdG86dHJpbGwtYm91bmNlc0BpZXRm Lm9yZz4gIFttYWlsdG86dHJpbGwtYm91bmNlc0BpZXRmLm9yZyA8bWFpbHRvOnRyaWxsLWJvdW5j ZXNAaWV0Zi5vcmc+IF0gT24gDQo+PiBCZWhhbGYgT2YgRXJpayBOb3JkbWFyaw0KPj4gU2VudDog RnJpZGF5LCBBcHJpbCAyNywgMjAxMiA0OjA3IFBNDQo+PiBUbzogU2FudG9zaCBSYWphZ29wYWxh bg0KPj4gQ2M6IHRyaWxsQGlldGYub3JnIDxtYWlsdG86dHJpbGxAaWV0Zi5vcmc+IA0KPj4gU3Vi amVjdDogUmU6IFt0cmlsbF0gVFJJTEwgT0FNIFJlcXVpcmVtZW50czogYXZhaWxhYmxlIHBhdGhz DQo+Pg0KPj4gT24gNC8yNy8xMiAyOjE1IFBNLCBTYW50b3NoIFJhamFnb3BhbGFuIHdyb3RlOg0K Pj4+DQo+Pj4gSSBhZ3JlZSwgdGhlIHdvcmRpbmcgbmVlZHMgdG8gYmUgdGlnaHRlbmVkIHRvIHNh eSAiYWxsIHBvc3NpYmxlIGVjbXAgDQo+Pj4gcGF0aHMiIHJhdGhlciB0aGFuICJhbGwgYXZhaWxh YmxlIHBhdGhzIi4gQW4gb3BlcmF0b3Igd29ya2luZyBvdXQNCj4+PiBSMS1SMiBjb21tdW5pY2F0 aW9uIGlzIGludGVyZXN0ZWQgaW4gYWxsIHBvc3NpYmxlIHBhdGhzIGRhdGEgdHJhZmZpYyANCj4+ PiBjb3VsZCB0YWtlIHJhdGhlciB0aGFuIGFsbCB0aGVvcmV0aWNhbGx5IGF2YWlsYWJsZSBwYXRo cy4NCj4+DQo+Pg0KPj4gVGhlIGlzc3VlIGlzIHRoYXQgdGhlcmUgaXMgbm90aGluZyBpbiB0aGUg VFJJTEwgZGF0YXBsYW5lIG5vciBJUy1JUyANCj4+IGNvbnRyb2wgcGxhbmUgd2hpY2ggaGVscHMg dGhlIG9wZXJhdG9yIGRldGVybWluZSB0aGF0IHNvbWUgcGF0aHMgDQo+PiAodGhyb3VnaCBSQjEy MSBhbmQgUkIxMTIgaW4gdGhlIGV4YW1wbGUpIGFyZSBub3QgcG9zc2libGU7IHRoZSBFQ01QIA0K Pj4gaW5wdXQgYW5kIGhhc2hpbmcgaXMgYSBjb21wbGV0ZWx5IGxvY2FsIG1hdHRlciBvbiBlYWNo IFJCcmlkZ2UuDQo+Pg0KPj4gSXQgaXNuJ3QgdXNlZnVsIHRvIHN0YXRlIGEgcmVxdWlyZW1lbnQg YXJvdW5kIHNvbWV0aGluZyB0aGF0IGNhbid0IGJlIA0KPj4gZGV0ZXJtaW5lZC4NCj4+DQo+PiAg ICAgRXJpaw0KPj4NCj4+Pg0KPj4+DQo+Pj4gRnJvbTogRXJpayBOb3JkbWFyazxub3JkbWFya0Bh Y20ub3JnIDxtYWlsdG86bm9yZG1hcmtAYWNtLm9yZz4gPg0KPj4+IFRvOiB0cmlsbEBpZXRmLm9y ZyA8bWFpbHRvOnRyaWxsQGlldGYub3JnPiANCj4+PiBEYXRlOiAwNC8yNy8yMDEyIDA5OjUzIEFN DQo+Pj4gU3ViamVjdDogW3RyaWxsXSBUUklMTCBPQU0gUmVxdWlyZW1lbnRzOiBhdmFpbGFibGUg cGF0aHMgU2VudCBieToNCj4+PiB0cmlsbC1ib3VuY2VzQGlldGYub3JnIDxtYWlsdG86dHJpbGwt Ym91bmNlc0BpZXRmLm9yZz4gDQo+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+PiAtLQ0KPj4+IC0tDQo+Pj4N Cj4+Pg0KPj4+DQo+Pj4NCj4+PiBUd28gcmVxdWlyZW1lbnRzIHVzZSB0aGUgd29yZGluZyAiYWxs IGF2YWlsYWJsZSBwYXRocy4iIGFuZCAiYWxsIA0KPj4+IGF2YWlsYWJsZSBFQ01QIHBhdGhzLiIs IHJlc3BlY3RpdmVseSBhbmQgSSdtIG5vdCBzdXJlIEkga25vdyB3aGF0IA0KPj4+IHRoYXQNCj4+ DQo+Pg0KPj4+IG1lYW5zLg0KPj4+DQo+Pj4gVGFrZSB0aGUgZm9sbG93aW5nIGV4YW1wbGUgcGlj dHVyZToNCj4+Pg0KPj4+IFIxDQo+Pj4gLyBcDQo+Pj4gLyBcDQo+Pj4gLyBcDQo+Pj4gLyBcDQo+ Pj4gLyBcDQo+Pj4gUkIxMSBSQjEyDQo+Pj4gLyBcIC8gXA0KPj4+IC8gXCAvIFwNCj4+PiBSQjEx MSBSQjExMiBSQjEyMSBSQjEyMg0KPj4+IFwgXCAvIC8NCj4+PiBcIFwgLyAvDQo+Pj4gXCBcLyAv DQo+Pj4gLS0tLS0tUjItLS0tLS0NCj4+Pg0KPj4+IFdlIGNhbiBzZWUgdGhhdCB0aGVyZSBhcmUg NCBwYXRocyB3aXRoIDMgaG9wcyB0byBnZXQgZnJvbSBSMSB0byBSMiwgDQo+Pj4gd2l0aCB0d28g bGF5ZXJzIG9mIEVDTVAgZGVjaXNpb25zLiBCdXQgaG93IG1hbnkgYXZhaWxhYmxlIHBhdGhzIGFy ZQ0KPj4NCj4+IHRoZXJlPw0KPj4+DQo+Pj4NCj4+PiBHaXZlbiB0aGF0IHRoZSBSQnJpZGdlcyBt YWtlIGluZGVwZW5kZW50IEVDTVAgZGVjaXNpb25zLCBhbmQgaG93IA0KPj4+IHRoZXkgZG8gdGhh dCBpcyBhIGxvY2FsIG1hdHRlciwgaXQgY291bGQgYmUgdGhlIGNhc2UgdGhhdCBmb3IgYW55IA0K Pj4+IHBhY2tldCwgaWYgUjEgcGlja3MgdGhlIGxlZnQgbGluaywgdGhlbiBSMTEgd291bGQgYWxz byBwaWNrIHRoZSBsZWZ0IA0KPj4+IGxpbms7IGlmDQo+Pj4gUjEgcGlja3MgdGhlIHJpZ2h0IGxp bmssIHRoZW4gUjEyIGFsc28gcGlja3MgdGhlIHJpZ2h0IGxpbmsuDQo+Pj4gVGh1cyB0aGVyZSB3 b3VsZCBiZSBubyBwYWNrZXQgKGRhdGEgb3IgT0FNKSB0aGF0IHdvdWxkIGNhdXNlIHBhY2tldHMg DQo+Pj4gYmV0d2VlbiBSMSBhbmQgUjIgdG8gcGFzcyB2aWEgUkIxMTIgb3IgUkIxMjEuDQo+Pj4N Cj4+PiBFdmVuIGlmIHdlIGlnbm9yZSB0aGF0IGFzIHVubGlrZWx5LCB0aGVyZSBpcyBzdGlsbCB0 aGUgZmFjdCB0aGF0IFIxIA0KPj4+IGNhbid0IGVhc2lseSB0ZWxsIGhvdyBtYW55IChzaG9ydGVz dCkgcGF0aHMgdGhlcmUgbWlnaHQgYmUgYmV0d2VlbiANCj4+PiBpdCBhbmQgUjIuIFdpdGggc2lu Z2xlLWxldmVsIFRSSUxMIHRoZSBMU0RCIGNvdWxkIGJlIHVzZWQgdG8gdGVsbCwgDQo+Pj4gYnV0 IGlmDQo+Pg0KPj4NCj4+PiB3ZSBldmVyIGdvIHRvIG11bHRpLWxldmVsIHRoYXQgd291bGRuJ3Qg YmUgdGhlIGNhc2UgYW55IG1vcmUuDQo+Pj4gQW5kIGV2ZW4gaWYgUjEga25vd3MgdGhhdCB0aGVy ZSBhcmUgNCBwb3RlbnRpYWwgcGF0aHMsIGl0IGNhbid0IA0KPj4+IGZvcm1hdA0KPj4NCj4+DQo+ Pj4gYSBkYXRhIHBhY2tldCAob3IgZm9ybWF0IHRoZSBmbG93IGVudHJvcHkgaW4gYW4gT0FNIHBh Y2tldCkgaW4gc3VjaCANCj4+PiBhIHdheSB0aGF0IHBhcnRpY3VsYXIgcGF0aHMgZ2V0IGNob3Nl biBieSBkb3duc3RyZWFtIEVDTVAgZGVjaXNpb25zLg0KPj4+DQo+Pj4gVGh1cyBmb3IgYW55IG5v dGlvbiBvZiAiYWxsIGF2YWlsYWJsZSBwYXRocyIgdGhhdCBtYWtlIHNlbnNlIHRvIG1lLCANCj4+ PiB3ZSdkIG5lZWQgYW4gT0FNIGFwcHJvYWNoIHRoYXQgY2FuIGV4cGxvcmUgdGhlIHRvcG9sb2d5 IG9uZSBob3AgYXQgYSANCj4+PiB0aW1lIGFuZCBhdCBlYWNoIGhvcCBleHBsb3JlIGFsbCB0aGUg cG9zc2libGUgRUNNUCBjaG9pY2VzLiBVc2luZyANCj4+PiB0aGUgZW50cm9weSBkb2Vzbid0IGhl bHAgd2l0aCB0aGlzIChidXQgdGhlIGVudHJvcHkgaXMgY3JpdGljYWwgZm9yIA0KPj4+IGZvbGxv d2luZyB0aGUgcGF0aCB0YWtlbiBieSBhIHBhcnRpY3VsYXIgZmxvdyBvZiBkYXRhIHBhY2tldHMp Lg0KPj4+DQo+Pj4gSGVuY2UgaXQgd291bGQgYmUgZ29vZCB0byBjbGFyaWZ5IHdoYXQgdGhlIGFz c3VtcHRpb25zIGFyZSBiZWhpbmQgDQo+Pj4gdGhpcw0KPj4NCj4+DQo+Pj4gbm90aW9uIG9mIGFs bCBhdmFpbGFibGUgcGF0aHMuDQo+Pj4NCj4+PiBUaGFua3MsDQo+Pj4gRXJpaw0KPj4+DQo+Pj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiB0cmls bCBtYWlsaW5nIGxpc3QNCj4+PiB0cmlsbEBpZXRmLm9yZyA8bWFpbHRvOnRyaWxsQGlldGYub3Jn PiANCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsIDxodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsPiANCj4+Pg0KPj4+DQo+Pg0K Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IHRy aWxsIG1haWxpbmcgbGlzdA0KPj4gdHJpbGxAaWV0Zi5vcmcgPG1haWx0bzp0cmlsbEBpZXRmLm9y Zz4gDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsIDxodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsPiANCj4+DQo+DQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHRyaWxsIG1haWxp bmcgbGlzdA0KPiB0cmlsbEBpZXRmLm9yZyA8bWFpbHRvOnRyaWxsQGlldGYub3JnPiANCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmlsbCA8aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmlsbD4gDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KdHJpbGwgbWFpbGluZyBsaXN0DQp0cmlsbEBpZXRmLm9y ZyA8bWFpbHRvOnRyaWxsQGlldGYub3JnPiANCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdHJpbGwgPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJp bGw+IA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnRy aWxsIG1haWxpbmcgbGlzdA0KdHJpbGxAaWV0Zi5vcmcgPG1haWx0bzp0cmlsbEBpZXRmLm9yZz4g DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsIDxodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsPiANCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQp0cmlsbCBtYWlsaW5nIGxpc3QNCnRyaWxsQGll dGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsIDxodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsPiANCg0K ------_=_NextPart_002_01CD270D.BF909872 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIg MTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCglt YXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1s ZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iLCJzZXJpZiI7fQ0KdHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNl dGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24g VGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4u RW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkJhbGxv b25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250 LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1VUyBsaW5r PWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlN1bm55PG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5BcmUg d2UgdGFsa2luZyBhYm91dCBhIHNpbmdsZSBmbG93IGhlcmUgb3IgbXVsdGlwbGUgZmxvd3MgPzxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9 J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNh bnMtc2VyaWYiJz4gdHJpbGwtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnRyaWxsLWJvdW5jZXNA aWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+U2FudG9zaCBSYWphZ29wYWxhbjxicj48Yj5T ZW50OjwvYj4gTW9uZGF5LCBBcHJpbCAzMCwgMjAxMiAxOjA1IFBNPGJyPjxiPlRvOjwvYj4gVGlz c2EgU2VuZXZpcmF0aG5lICh0c2VuZXZpcik8YnI+PGI+Q2M6PC9iPiBEb25hbGQgRWFzdGxha2U7 IHRyaWxsLWJvdW5jZXNAaWV0Zi5vcmc7IERhdmlkIE0gQm9uZDsgdHJpbGxAaWV0Zi5vcmc8YnI+ PGI+U3ViamVjdDo8L2I+IFJlOiBbdHJpbGxdIFRSSUxMIE9BTSBSZXF1aXJlbWVudHM6IGF2YWls YWJsZSBwYXRoczxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5UaXNzYSw8L3Nw YW4+IDxicj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwi LCJzYW5zLXNlcmlmIic+SGFzaCBwb2xhcml6YXRpb24gY2FuIHJlc3VsdCBpbiBzb21lIG9mIHRo ZSBlY21wIHBhdGhzIGJlaW5nIHVudXRpbGl6ZWQuIEluIEVyaWMncyBleGFtcGxlOjwvc3Bhbj4g PGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyInPjxicj48YnI+PHR0PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtSMTwvdHQ+PGJyPjx0dD4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgLyAmbmJzcDtcPC90dD48YnI+PHR0PiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy8gJm5ic3A7ICZuYnNwO1w8L3R0Pjxi cj48dHQ+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLyAmbmJzcDsg Jm5ic3A7ICZuYnNwO1w8L3R0Pjxicj48dHQ+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsvICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1w8L3R0Pjxicj48dHQ+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAvICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtcPC90dD48YnI+PHR0PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1JCMTEg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1JCMTI8L3R0Pjxicj48dHQ+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7LyAmbmJzcDtcICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsvICZuYnNwO1w8L3R0Pjxicj48dHQ+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgLyAmbmJz cDsgJm5ic3A7XCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsvICZuYnNwOyAmbmJzcDtcPC90 dD48YnI+PHR0PiZuYnNwOyAmbmJzcDtSQjExMSAmbmJzcDtSQjExMiAmbmJzcDtSQjEyMSAmbmJz cDtSQjEyMjwvdHQ+PGJyPjx0dD4mbmJzcDsgJm5ic3A7ICZuYnNwOyBcICZuYnNwOyAmbmJzcDsg Jm5ic3A7XCAmbmJzcDsgJm5ic3A7LyAmbmJzcDsgJm5ic3A7ICZuYnNwOy88L3R0Pjxicj48dHQ+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7XCAmbmJzcDsgJm5ic3A7ICZuYnNwO1wgJm5ic3A7 LyAmbmJzcDsgJm5ic3A7ICZuYnNwOy88L3R0Pjxicj48dHQ+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IFwgJm5ic3A7ICZuYnNwOyAmbmJzcDtcLyAmbmJzcDsgJm5ic3A7ICZuYnNwOy88L3R0 Pjxicj48dHQ+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy0tLS0tLVIyLS0tLS0t PC90dD48YnI+PC9zcGFuPjxicj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+SWYgUjEgYW5kIFJCMTIgdXNlIHRoZSBzYW1lIGhh c2ggcG9seW5vbWlhbCAmYW1wOyBzZWVkLCB0aGVuICphbGwqIGZsb3dzIHdoaWNoIGFycml2ZSBh dCBSQjEyIHdpbGwgZ28gYWxvbmcgdGhlIGxpbmsgdG8gUkIxMjIgLSB0aGUgbGluayB0byBSQjEy MSBmcm9tIFJCMTIgd2lsbCBuZXZlciBiZSB1c2VkLiBUaGUgT0FNIHRvb2wgc2hvdWxkIGFsbG93 IHVzIHRvIGZpZ3VyZSBvdXQgdGhpcyBpcyBoYXBwZW5pbmcsIGluc3RlYWQgb2YgZ2l2aW5nIHVz IHJlZHVuZGFudCBpbmZvcm1hdGlvbiBhbHJlYWR5IGF2YWlsYWJsZSBpbiBJU0lTIGxzZGIuPC9z cGFuPiA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFs Iiwic2Fucy1zZXJpZiInPkkgd291bGQgaGVzaXRhdGUgdG8gY2FsbCB0aGlzIGEgZGVmZWN0LiBX aGlsZSBpdCBpcyB0cnVlIHRoYXQgYSBsb3Qgb2YgYXNpY3MgaGF2ZSBjb3VudGVybWVhc3VyZXMg Zm9yIHRoaXMgKHVzdWFsbHkgYnkgaW5jbHVkaW5nIGEgcmFuZG9tIHNlZWQgYXMgaW5wdXQgdG8g dGhlIGhhc2ggcG9seW5vbWlhbCksIHlvdSBjYW5ub3QgcnVsZSB0aGlzIG91dCAxMDAlLiBQbGVh c2UgbG9vayBhdCB0aGlzIGRvY3VtZW50YXRpb24gZnJvbSBhIHdlbGwga25vd24gbmV0d29ya2lu ZyBjb21wYW55IDstKTwvc3Bhbj4gPGJyPjxhIGhyZWY9Imh0dHA6Ly93d3cuY2lzY28uY29tL2Vu L1VTL2RvY3MvaW9zLzEyXzR0L2lwX21jYXN0L2NvbmZpZ3VyYXRpb24vZ3VpZGUvbWN0bHNwbHQu aHRtbCN3cDEwNjQ1MDEiPmh0dHA6Ly93d3cuY2lzY28uY29tL2VuL1VTL2RvY3MvaW9zLzEyXzR0 L2lwX21jYXN0L2NvbmZpZ3VyYXRpb24vZ3VpZGUvbWN0bHNwbHQuaHRtbCN3cDEwNjQ1MDE8L2E+ IDxicj48YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFs Iiwic2Fucy1zZXJpZiInPi0tPC9zcGFuPiA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPlN1bm55PC9zcGFuPiA8YnI+PGJy Pjxicj48YnI+PGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFy aWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzVGNUY1Ric+RnJvbTogJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6 IkFyaWFsIiwic2Fucy1zZXJpZiInPiZxdW90O1Rpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIp JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86dHNlbmV2aXJAY2lzY28uY29tIj50c2VuZXZpckBj aXNjby5jb208L2E+Jmd0Ozwvc3Bhbj4gPGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7 Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzVGNUY1Ric+VG86ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuNXB0 O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5EYXZpZCBNIEJvbmQvQmVkZm9yZC9J Qk1ASUJNVVM8L3NwYW4+IDxicj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiM1RjVGNUYnPkNjOiAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZh bWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+RG9uYWxkIEVhc3RsYWtlICZsdDs8YSBocmVmPSJt YWlsdG86ZDNlM2UzQGdtYWlsLmNvbSI+ZDNlM2UzQGdtYWlsLmNvbTwvYT4mZ3Q7LCA8YSBocmVm PSJtYWlsdG86dHJpbGwtYm91bmNlc0BpZXRmLm9yZyI+dHJpbGwtYm91bmNlc0BpZXRmLm9yZzwv YT4sIDxhIGhyZWY9Im1haWx0bzp0cmlsbEBpZXRmLm9yZyI+dHJpbGxAaWV0Zi5vcmc8L2E+PC9z cGFuPiA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiQXJpYWwi LCJzYW5zLXNlcmlmIjtjb2xvcjojNUY1RjVGJz5EYXRlOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIic+MDQvMzAvMjAxMiAxMjoyOSBQTTwvc3Bhbj4gPGJyPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29s b3I6IzVGNUY1Ric+U3ViamVjdDogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9zcGFuPjxz cGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp ZiInPlJlOiBbdHJpbGxdIFRSSUxMIE9BTSBSZXF1aXJlbWVudHM6IGF2YWlsYWJsZSBwYXRoczwv c3Bhbj4gPGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFs Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzVGNUY1Ric+U2VudCBieTogJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6 IkFyaWFsIiwic2Fucy1zZXJpZiInPjxhIGhyZWY9Im1haWx0bzp0cmlsbC1ib3VuY2VzQGlldGYu b3JnIj50cmlsbC1ib3VuY2VzQGlldGYub3JnPC9hPjwvc3Bhbj4gPG86cD48L286cD48L3A+PGRp diBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+ PGhyIHNpemU9MiB3aWR0aD0iMTAwJSIgbm9zaGFkZSBzdHlsZT0nY29sb3I6I0EwQTBBMCcgYWxp Z249Y2VudGVyPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48YnI+PGJyPjxicj48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMwMDQwODAnPkxldCBtZSBzdGFydCBmcm9tIHRoZSBiYXNpY3MuPC9zcGFuPiA8YnI+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMDA0MDgwJz4mbmJzcDs8L3NwYW4+IDxicj48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMwMDQw ODAnPjEuICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRSSUxMIGlzIGFsbCBhYm91dCBtdWx0aXBsZSBh Y3RpdmUgcGF0aHMuPC9zcGFuPiA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMDA0MDgwJz4yLiAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBNdWx0aXBsZSBhY3RpdmUgcGF0aHMgYXJlIGRlcml2ZWQgZnJvbSBsZWFz dCBjb3N0IHBhdGhzIHRvIGEgc3BlY2lmaWMgZGVzdGluYXRpb25zLjwvc3Bhbj4gPGJyPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzAwNDA4MCc+My4gJm5ic3A7ICZuYnNwOyAmbmJzcDsgV2VsbCBkZWZpbmVkIGFu ZCBpbXBsZW1lbnRlZCBIYXNoaW5nIGFsZ29yaXRobXMgcHJvdmlkZSBhbiBhbG1vc3QgZXZlbiBk aXN0cmlidXRpb24gYWNyb3NzIGFsbCBvZiB0aGUgYXZhaWxhYmxlIGxlYXN0IGNvc3QgcGF0aHMg dG8gYSBkZXN0aW5hdGlvbjwvc3Bhbj4gPGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzAwNDA4MCc+NC4gJm5i c3A7ICZuYnNwOyAmbmJzcDsgSWYgYSBnaXZlbiBmbG93IOKAnHjigJ0gZG9lcyBub3QgbWFwIHRv ICZuYnNwO2Egc3BlY2lmaWMgbGVhc3QgY29zdCBwYXRoLCBkb2VzIG5vdCBtYXAgdG8gYSBzcGVj aWZpYyBsZWFzdCBjb3N0IHBhdGggZG9lcyBub3QgbWVhbiBhbm90aGVyIGZsb3cg4oCceeKAnSB0 byB0aGUgc2FtIGRlc3RpbmF0aW9uIHdpbGwgbm90IG1hcCB0byB0aGUgdGhhdCBwYXRoLiA8L3Nw YW4+PGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzAwNDA4MCc+NS4gJm5ic3A7ICZuYnNwOyAmbmJzcDsgV2Vs bCBpbXBsZW1lbnRlZCBoYXNoaW5nIGFsZ29yaXRobXMgcHJvdmlkZSBldmVuIGRpc3RyaWJ1dGlv biBvZiBmbG93cy48L3NwYW4+IDxicj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMwMDQwODAnPjYuICZuYnNwOyAm bmJzcDsgJm5ic3A7IEhlbmNlIGl0IGlzIGltcG9ydGFudCB0byBoYXZlIGFiaWxpdHkgdG8gdGVz dCBhbGwgYXZhaWxhYmxlIGxlYXN0IGNvc3QgcGF0aHMgdG8gYSBkZXN0aW5hdGlvbi48L3NwYW4+ IDxicj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMwMDQwODAnPjcuICZuYnNwOyAmbmJzcDsgJm5ic3A7IEl0IGlz IGFuIGltcGxlbWVudGF0aW9uIGRlZmVjdCwgSWYgdGhlcmUgaXMgYW4gaW1wbGVtZW50YXRpb24g b3V0IHRoZXJlIHdoaWNoIGRvZXMgbm90IGhhc2ggZmxvd3MgKG92ZXIgYSBsb25nZXIgc2FtcGxp bmcgcGVyaW9kKSAmbmJzcDtpbiB0byBhIHNwZWNpZmljIOKAnGxlYXN0IGNvc3QgcGF0aOKAnSBv ZiBzZXQgb2YgbGVhc3QgY29zdCBwYXRocyB0byBhIGRlc3RpbmF0aW9uLCBhbW9uZyBhbGwgYXZh aWxhYmxlIOKAnGxlYXN0IGNvc3QgcGF0aHPigJ0gdG8gdGhhdCBkZXN0aW5hdGlvbi48L3NwYW4+ IDxicj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMwMDQwODAnPiZuYnNwOzwvc3Bhbj4gPGJyPjxiPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IERhdmlkIE0gQm9uZCBbPC9zcGFuPjxhIGhyZWY9Im1h aWx0bzpkbWJvbmRAdXMuaWJtLmNvbSI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5tYWlsdG86ZG1ib25kQHVzLmlibS5jb208 L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhv bWEiLCJzYW5zLXNlcmlmIic+XSA8Yj48YnI+U2VudDo8L2I+IE1vbmRheSwgQXByaWwgMzAsIDIw MTIgODozOSBBTTxiPjxicj5Ubzo8L2I+IFRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpPGI+ PGJyPkNjOjwvYj4gRG9uYWxkIEVhc3RsYWtlOyA8YSBocmVmPSJtYWlsdG86dHJpbGxAaWV0Zi5v cmciPnRyaWxsQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnRyaWxsLWJvdW5jZXNAaWV0 Zi5vcmciPnRyaWxsLWJvdW5jZXNAaWV0Zi5vcmc8L2E+PGI+PGJyPlN1YmplY3Q6PC9iPiBSZTog W3RyaWxsXSBUUklMTCBPQU0gUmVxdWlyZW1lbnRzOiBhdmFpbGFibGUgcGF0aHM8L3NwYW4+IDxi cj4mbmJzcDsgPG86cD48L286cD48L3A+PHA+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPkp1c3QgYSBxdWVzdGlvbiBjb21pbmcg ZnJvbSB0aGlzIGNvbnZlcnNhdGlvbiB0aGF0IEkgd2FudCB0byBjbGFyaWZ5Ojwvc3Bhbj48YnI+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiInPjxicj5TbyB3ZSBoYXZlICdhbGwgcG9zc2libGUgcGF0aHMnICgxKSB3aGljaCBjb3Vs ZCBpbmNsdWRlIG5vbi1sZWFzdCBjb3N0IHBhdGhzIGFuZCBzbyBvZiBjb3Vyc2Ugd2UgZG9uJ3Qg d2FudCB0byB1c2UgdGhpcyBkZWZpbml0aW9uLjwvc3Bhbj48YnI+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPjxicj5UaGVuIHdl IGhhdmUgJ2FsbCBlY21wIHBhdGhzJyBvciAnYWxsIGxlYXN0IGNvc3QgcGF0aHMnICgyKSB3aGlj aCBNQVkgaW5jbHVkZSBwYXRocyBuZXZlciBjaG9zZW4gYnkgYSB0cmFuc2l0IFJicmlkZ2UgYmVj YXVzZSBvZiB0aGUgbG9jYWwgaGFzaGluZyBjaG9pY2VzLjwvc3Bhbj48YnI+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPjxicj5U aGVuIHdlIGhhdmUgJ2FsbCB0aGUgbGVhc3QgY29zdCBwYXRocyB3aGljaCBtYXkgYmUgY2hvc2Vu IGdpdmVuIHRoZSBoYXNoaW5nIGltcGxlbWVudGF0aW9uIG9uIHRoZSBsb2NhbCBSYnJpZGdlcycg KDMpLjwvc3Bhbj48YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IkFyaWFsIiwic2Fucy1zZXJpZiInPjxicj5JIHdvbmRlciBpZiBjaG9pY2UgKDIpIGlzIHVzZWZ1 bCBvciBkbyB3ZSBvbmx5IHJlYWxseSBjYXJlIGFib3V0IGNob2ljZSAoMykuIEZvciBpbnN0YW5j ZSwgaWYgeW91IGhhdmUgMTYgZXF1YWwgY29zdCBwYXRocyBmcm9tIEEgdG8gQiBhbmQgeW91ciBo YXNoaW5nIG9ubHkgd2lsbCBldmVyIHVzZSAyIG9mIHRob3NlIHBhdGhzIGRvIHdlIGNhcmUgYWJv dXQgcmVwb3J0aW5nIGJhY2sgZWNtcCBwYXRocyB0aGF0IHdpbGwgbmV2ZXIgaW4gcHJhY3RpY2Ug YmUgdXNlZD8gUGVyaGFwcyB0aGUgZGVmaW5pdGlvbiBzaG91bGQgYmUgdGlnaHRlbmVkIHRvIG9u bHkgcmVxdWlyZSBkZXRlcm1pbmF0aW9uIG9mIGFsbCBsZWFzdCBjb3N0IHBhdGhzIHRoYXQgY291 bGQgYmUgdXNlZCBnaXZlbiB0aGUgbG9jYWwgaGFzaGluZyBpbXBsZW1lbnRhdGlvbi4gT3IgYW0g SSBtaXN1bmRlcnN0YW5kaW5nIHRoZSBjb252ZXJzYXRpb24gYW5kIGlzIHRoaXMgYWxyZWFkeSB0 aGUgcG9pbnQgYmVpbmcgbWFkZSBiZXR3ZWVuIHRoZW9yZXRpY2FsIHBhdGhzIGFuZCBsZWFzdCBj b3N0IHBhdGhzLjwvc3Bhbj48YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPjxicj5UaGFua3MsPGJyPkRhdmlkPC9zcGFuPjxi cj48YnI+PGltZyBib3JkZXI9MCB3aWR0aD0xNiBoZWlnaHQ9MTYgaWQ9Il94MDAwMF9pMTAyNiIg c3JjPSJjaWQ6aW1hZ2UwMDEuZ2lmQDAxQ0QyNkQzLjExMEMzNEUwIiBhbHQ9IkluYWN0aXZlIGhp ZGUgZGV0YWlscyBmb3IgJnF1b3Q7VGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZpcikmcXVvdDsg LS0tMDQvMjkvMjAxMiAxMTo0MzowNyBQTS0tLUkgbGlrZSB0aGF0IERvbmFsZC4uIFdlIGNhbiB1 c2UgJnF1b3Q7YWxsIGxlYXMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiM0MjQyODInPiZxdW90O1Rpc3NhIFNlbmV2 aXJhdGhuZSAodHNlbmV2aXIpJnF1b3Q7IC0tLTA0LzI5LzIwMTIgMTE6NDM6MDcgUE0tLS1JIGxp a2UgdGhhdCBEb25hbGQuLiBXZSBjYW4gdXNlICZxdW90O2FsbCBsZWFzdCBjb3N0IHBhdGhzJnF1 b3Q7LCB0aGF0IGlzIHRlY2huaWNhbGx5IG1vcmUgcHJlY2lzZSBhbmQgcmVwcmVzZTwvc3Bhbj48 YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIjtjb2xvcjojNUY1RjVGJz48YnI+RnJvbTogPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPiZxdW90O1Rpc3Nh IFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpJnF1b3Q7ICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRv OnRzZW5ldmlyQGNpc2NvLmNvbSI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZh bWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+dHNlbmV2aXJAY2lzY28uY29tPC9zcGFuPjwvYT48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2Vy aWYiJz4mZ3Q7PHNwYW4gc3R5bGU9J2NvbG9yOiM1RjVGNUYnPjxicj5UbzogPC9zcGFuPiZxdW90 O0RvbmFsZCBFYXN0bGFrZSZxdW90OyAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpkM2UzZTNA Z21haWwuY29tIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlh bCIsInNhbnMtc2VyaWYiJz5kM2UzZTNAZ21haWwuY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4mZ3Q7LCAm bHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzp0cmlsbEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+dHJpbGxAaWV0 Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6 IkFyaWFsIiwic2Fucy1zZXJpZiInPiZndDs8c3BhbiBzdHlsZT0nY29sb3I6IzVGNUY1Ric+PGJy PkRhdGU6IDwvc3Bhbj4wNC8yOS8yMDEyIDExOjQzIFBNPHNwYW4gc3R5bGU9J2NvbG9yOiM1RjVG NUYnPjxicj5TdWJqZWN0OiA8L3NwYW4+UmU6IFt0cmlsbF0gVFJJTEwgT0FNIFJlcXVpcmVtZW50 czogYXZhaWxhYmxlIHBhdGhzPHNwYW4gc3R5bGU9J2NvbG9yOiM1RjVGNUYnPjxicj5TZW50IGJ5 OiA8L3NwYW4+PC9zcGFuPjxhIGhyZWY9Im1haWx0bzp0cmlsbC1ib3VuY2VzQGlldGYub3JnIj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2Vy aWYiJz50cmlsbC1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT4gPG86cD48L286cD48L3A+PGRp diBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+ PGhyIHNpemU9MiB3aWR0aD0iMTAwJSIgbm9zaGFkZSBzdHlsZT0nY29sb3I6I0EwQTBBMCcgYWxp Z249Y2VudGVyPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbTox Mi4wcHQnPjxicj48YnI+PGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyInPjxicj5JIGxpa2UgdGhhdCBEb25hbGQuLiBXZSBjYW4gdXNlICZx dW90O2FsbCBsZWFzdCBjb3N0IHBhdGhzJnF1b3Q7LCB0aGF0IGlzIHRlY2huaWNhbGx5IG1vcmUg cHJlY2lzZSBhbmQgcmVwcmVzZW50IGV4YWN0bHkgd2hhdCBJUy1JUyBkb2VzLjxicj48YnI+VGhh bmtzPGJyPlRpc3NhPGJyPjxicj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj5Gcm9tOiA8 L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnRyaWxsLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPnRyaWxsLWJvdW5j ZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyInPiBbPC9zcGFuPjxhIGhyZWY9Im1haWx0bzp0cmlsbC1ib3Vu Y2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi Q291cmllciBOZXciJz5tYWlsdG86dHJpbGwtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+XSBP biBCZWhhbGYgT2YgRG9uYWxkIEVhc3RsYWtlPGJyPlNlbnQ6IFN1bmRheSwgQXByaWwgMjksIDIw MTIgNjoyNyBQTTxicj5UbzogPC9zcGFuPjxhIGhyZWY9Im1haWx0bzp0cmlsbEBpZXRmLm9yZyI+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+ dHJpbGxAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxicj5TdWJqZWN0OiBSZTogW3RyaWxsXSBUUklMTCBP QU0gUmVxdWlyZW1lbnRzOiBhdmFpbGFibGUgcGF0aHM8YnI+PGJyPkkgZG9uJ3QgdGhpbmsgdGhl IHdvcmRpbmcgJnF1b3Q7YWxsIHBhdGhzJnF1b3Q7IHNob3VsZCBldmVyIGJlIHVzZWQuIElmIHlv dSB0aGUgaXQgbGl0ZXJhbGx5LCBpdCB3b3VsZCBldmVuIGluY2x1ZGUgcGF0aHMgdGhhdCBnbyB0 aHJvdWdoIHNvbWUgUkJyaWRnZXMgbW9yZSB0aGFuIG9uY2UuPGJyPjxicj5JIGRvbid0IHBhcnRp Y3VsYXJseSBsaWtlICZxdW90O2FsbCBFQ01QIHBhdGhzJnF1b3Q7IGVpdGhlci4gSSB0aGluayB0 aGUgY2xlYXJlc3Qgd29yZGluZyBpcyAmcXVvdDthbGwgbGVhc3QgY29zdCBwYXRocyZxdW90OyBp ZiB5b3UgYXJlIHRhbGtpbmcgYWJvdXQga25vd24gdW5pY2FzdC4gKEFuZCAmcXVvdDthbGwgZGlz dHJpYnV0aW9uIHRyZWUgcGF0aHMmcXVvdDsgaWYgeW91IHdlcmUgdGFsa2luZyBhYm91dCBtdWx0 aS1kZXN0aW5hdGlvbiBmcmFtZXMuKTxicj48YnI+VGhhbmtzLDxicj5Eb25hbGQ8YnI+PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT08YnI+RG9uYWxkIEUuIEVhc3RsYWtlIDNyZCAmbmJzcDsg KzEtNTA4LTMzMy0yMjcwIChjZWxsKTxicj4xNTUgQmVhdmVyIFN0cmVldCwgTWlsZm9yZCwgTUEg MDE3NTcgVVNBPGJyPjwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZDNlM2UzQGdtYWlsLmNvbSI+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+ZDNl M2UzQGdtYWlsLmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PGJyPjxicj48YnI+T24gU2F0LCBBcHIgMjgsIDIwMTIg YXQgMTE6NDUgUE0sIEVyaWsgTm9yZG1hcmsgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86bm9y ZG1hcmtAYWNtLm9yZyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Iic+bm9yZG1hcmtAYWNtLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyB3cm90ZTo8YnI+ Jmd0OyBPbiA0LzI3LzEyIDU6MTIgUE0sIFRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpIHdy b3RlOjxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBPZiBjb3Vyc2UgaXQgaXMgcG9zc2libGUuIFRo ZSBJUy1JUyB0b3BvbG9neSB0YWJsZSBwcm92aWRlIHRoZSA8YnI+Jmd0OyZndDsgaW5mb3JtYXRp b24gb24gYWxsIGF2YWlsYWJsZSBFQ01QIHBhdGhzIHRvIGEgc3BlY2lmaWMgZGVzdGluYXRpb24g PGJyPiZndDsmZ3Q7IHdoZW4gdGhlIGVncmVzcyBSQlJpZGdlIG5pY2tuYW1lIGlzIGtub3duLiBU aGF0IGlzIHdoYXQgVFJJTEwgdW5pY2FzdCA8YnI+Jmd0OyZndDsgZm9yd2FyZGluZyB0YWJsZSBh bGwgYWJvdXQuIE5vdCBzdXJlIHdoeSB5b3UgYXJlIHNheWluZyBpdCBpcyBub3QgPGJyPiZndDsm Z3Q7IHBvc3NpYmxlIHRvIGtub3cgYWxsIEVDTVAgcGF0aHMuPGJyPiZndDs8YnI+Jmd0Ozxicj4m Z3Q7IFlvdSBhcmUgdGFsa2luZyBhYm91dCB3aGF0IFNhbnRvc2ggY2FsbGVkICZxdW90O2FsbCB0 aGVvcmV0aWNhbGx5IGF2YWlsYWJsZSA8YnI+Jmd0OyBwYXRocyZxdW90Oy4gVGhvc2UgY2FuIGJl IGRldGVybWluZWQgZnJvbSBJUy1JUy48YnI+Jmd0Ozxicj4mZ3Q7IEJ1dCB0aGUgZG9jdW1lbnQg dGFsa3MgYWJvdXQgJnF1b3Q7YWxsIGF2YWlsYWJsZSBwYXRocyZxdW90OyBhbmQgSSBkb24ndCBr bm93IDxicj4mZ3Q7IHdoYXQgdGhhdCBpcyBzdXBwb3NlZCB0byBtZWFuLiBEbyB5b3UgaGF2ZSBh IHN1Y2NpbmN0IGRlZmluaXRpb24/PGJyPiZndDs8YnI+Jmd0OyBXaGF0IGlzIGNsZWFyIHRvIG1l IGlzIHRoYXQgdGhlcmUgY2FuIGJlIGEgc3Vic2V0IG9mIHRoZSBwYXRocyB0aGF0IDxicj4mZ3Q7 IGFyZSBkZXRlcm1pbmVkIGZyb20gSVMtSVMgdGhhdCB3b3VsZCBuZXZlciBiZSB1c2VkLCBiZWNh dXNlIG5vIGVudHJvcHkgPGJyPiZndDsgaW4gYSBwYWNrZXQgd291bGQgZXZlcnkgcGljayB0aGF0 IHBhdGguPGJyPiZndDs8YnI+Jmd0OyBJcyB0aGUgcmVxdWlyZW1lbnQgaW4gdGhlIGRvY3VtZW50 IHRoYXQgdGhlIE9BTSBzb2x1dGlvbiBzaG91bGQgYmUgPGJyPiZndDsgYWJsZSB0byB0ZXN0IHRo b3NlIHBhdGhzPzxicj4mZ3Q7PGJyPiZndDs8YnI+Jmd0OyZndDsgV2hhdCBwYXRoIGFtb25nIGF2 YWlsYWJsZSBwYXRocyB0byBiZSBzZWxlY3RlZCBmb3IgYSBzcGVjaWZpZWQgaXMgYSA8YnI+Jmd0 OyZndDsgbG9jYWwgbWF0dGVyLiBUaGF0IGlzIHdoYXQgYWxsIGFib3V0IGZsb3cgZW50cm9weSBk aXNjb3ZlcnkuIExpa2UgSSA8YnI+Jmd0OyZndDsgc3RhdGVkIGVhcmxpZXIgaG93IGl0IGlzIGRp c2NvdmVyZWQgaXMgYSBmcmFtZXdvcmsgYW5kIHNvbHV0aW9uIGlzc3VlLjxicj4mZ3Q7PGJyPiZn dDs8YnI+Jmd0OyBBZ3JlZWQuPGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7Jmd0OyBJZiB5b3UgbmVl ZCBzb21lIHJlZmVyZW5jZSBob3cgaXQgaXMgZG9uZSBpbiB0aGUgTVBMUyB3b3JsZCBSRkMgNDM3 OSA8YnI+Jmd0OyZndDsgaXMgYSBnb29kIHJlZmVyZW5jZS48YnI+Jmd0Ozxicj4mZ3Q7PGJyPiZn dDsgQUZBSUsgTVBMUyBkb2Vzbid0IGhhdmUgYSBsb2NhbGx5IGRlZmluZWQgRUNNUCBoYXNoIGZ1 bmN0aW9uIGluIGV2ZXJ5IGhvcC48YnI+Jmd0OyBUUklMTCBkb2VzLCB3aGljaCBtYWtlcyB0aGVz ZSBhc3BlY3RzIGRpZmZlcmVudC48YnI+Jmd0Ozxicj4mZ3Q7IFJlZ2FyZHMsPGJyPiZndDsgJm5i c3A7IEVyaWs8YnI+Jmd0Ozxicj4mZ3Q7PGJyPiZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tPGJyPiZndDsmZ3Q7IEZyb206IDwvc3Bhbj48YSBocmVmPSJtYWlsdG86dHJpbGwtYm91 bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Iic+dHJpbGwtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+IFs8L3NwYW4+ PGEgaHJlZj0ibWFpbHRvOnRyaWxsLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPm1haWx0bzp0cmlsbC1ib3Vu Y2VzQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiQ291cmllciBOZXciJz5dIE9uIDxicj4mZ3Q7Jmd0OyBCZWhhbGYgT2YgRXJpayBO b3JkbWFyazxicj4mZ3Q7Jmd0OyBTZW50OiBGcmlkYXksIEFwcmlsIDI3LCAyMDEyIDQ6MDcgUE08 YnI+Jmd0OyZndDsgVG86IFNhbnRvc2ggUmFqYWdvcGFsYW48YnI+Jmd0OyZndDsgQ2M6IDwvc3Bh bj48YSBocmVmPSJtYWlsdG86dHJpbGxAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPnRyaWxsQGlldGYub3JnPC9zcGFuPjwv YT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXci Jz48YnI+Jmd0OyZndDsgU3ViamVjdDogUmU6IFt0cmlsbF0gVFJJTEwgT0FNIFJlcXVpcmVtZW50 czogYXZhaWxhYmxlIHBhdGhzPGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7IE9uIDQvMjcvMTIgMjox NSBQTSwgU2FudG9zaCBSYWphZ29wYWxhbiB3cm90ZTo8YnI+Jmd0OyZndDsmZ3Q7PGJyPiZndDsm Z3Q7Jmd0OyBJIGFncmVlLCB0aGUgd29yZGluZyBuZWVkcyB0byBiZSB0aWdodGVuZWQgdG8gc2F5 ICZxdW90O2FsbCBwb3NzaWJsZSBlY21wIDxicj4mZ3Q7Jmd0OyZndDsgcGF0aHMmcXVvdDsgcmF0 aGVyIHRoYW4gJnF1b3Q7YWxsIGF2YWlsYWJsZSBwYXRocyZxdW90Oy4gQW4gb3BlcmF0b3Igd29y a2luZyBvdXQ8YnI+Jmd0OyZndDsmZ3Q7IFIxLVIyIGNvbW11bmljYXRpb24gaXMgaW50ZXJlc3Rl ZCBpbiBhbGwgcG9zc2libGUgcGF0aHMgZGF0YSB0cmFmZmljIDxicj4mZ3Q7Jmd0OyZndDsgY291 bGQgdGFrZSByYXRoZXIgdGhhbiBhbGwgdGhlb3JldGljYWxseSBhdmFpbGFibGUgcGF0aHMuPGJy PiZndDsmZ3Q7PGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7IFRoZSBpc3N1ZSBpcyB0aGF0IHRoZXJl IGlzIG5vdGhpbmcgaW4gdGhlIFRSSUxMIGRhdGFwbGFuZSBub3IgSVMtSVMgPGJyPiZndDsmZ3Q7 IGNvbnRyb2wgcGxhbmUgd2hpY2ggaGVscHMgdGhlIG9wZXJhdG9yIGRldGVybWluZSB0aGF0IHNv bWUgcGF0aHMgPGJyPiZndDsmZ3Q7ICh0aHJvdWdoIFJCMTIxIGFuZCBSQjExMiBpbiB0aGUgZXhh bXBsZSkgYXJlIG5vdCBwb3NzaWJsZTsgdGhlIEVDTVAgPGJyPiZndDsmZ3Q7IGlucHV0IGFuZCBo YXNoaW5nIGlzIGEgY29tcGxldGVseSBsb2NhbCBtYXR0ZXIgb24gZWFjaCBSQnJpZGdlLjxicj4m Z3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBJdCBpc24ndCB1c2VmdWwgdG8gc3RhdGUgYSByZXF1aXJlbWVu dCBhcm91bmQgc29tZXRoaW5nIHRoYXQgY2FuJ3QgYmUgPGJyPiZndDsmZ3Q7IGRldGVybWluZWQu PGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgRXJpazxicj4mZ3Q7Jmd0Ozxi cj4mZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyBGcm9tOiBFcmlr IE5vcmRtYXJrJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86bm9yZG1hcmtAYWNtLm9yZyI+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+bm9y ZG1hcmtAYWNtLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsgVG86IDwvc3Bhbj48 YSBocmVmPSJtYWlsdG86dHJpbGxAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPnRyaWxsQGlldGYub3JnPC9zcGFuPjwvYT48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48 YnI+Jmd0OyZndDsmZ3Q7IERhdGU6IDA0LzI3LzIwMTIgMDk6NTMgQU08YnI+Jmd0OyZndDsmZ3Q7 IFN1YmplY3Q6IFt0cmlsbF0gVFJJTEwgT0FNIFJlcXVpcmVtZW50czogYXZhaWxhYmxlIHBhdGhz IFNlbnQgYnk6PGJyPiZndDsmZ3Q7Jmd0OyA8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnRyaWxsLWJv dW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyInPnRyaWxsLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxicj4mZ3Q7 Jmd0OyZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+Jmd0OyZndDsmZ3Q7IC0tPGJyPiZndDsmZ3Q7Jmd0OyAt LTxicj4mZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7 Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7IFR3byByZXF1aXJlbWVudHMgdXNlIHRoZSB3b3JkaW5n ICZxdW90O2FsbCBhdmFpbGFibGUgcGF0aHMuJnF1b3Q7IGFuZCAmcXVvdDthbGwgPGJyPiZndDsm Z3Q7Jmd0OyBhdmFpbGFibGUgRUNNUCBwYXRocy4mcXVvdDssIHJlc3BlY3RpdmVseSBhbmQgSSdt IG5vdCBzdXJlIEkga25vdyB3aGF0IDxicj4mZ3Q7Jmd0OyZndDsgdGhhdDxicj4mZ3Q7Jmd0Ozxi cj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsgbWVhbnMuPGJyPiZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7 Jmd0OyZndDsgVGFrZSB0aGUgZm9sbG93aW5nIGV4YW1wbGUgcGljdHVyZTo8YnI+Jmd0OyZndDsm Z3Q7PGJyPiZndDsmZ3Q7Jmd0OyBSMTxicj4mZ3Q7Jmd0OyZndDsgLyBcPGJyPiZndDsmZ3Q7Jmd0 OyAvIFw8YnI+Jmd0OyZndDsmZ3Q7IC8gXDxicj4mZ3Q7Jmd0OyZndDsgLyBcPGJyPiZndDsmZ3Q7 Jmd0OyAvIFw8YnI+Jmd0OyZndDsmZ3Q7IFJCMTEgUkIxMjxicj4mZ3Q7Jmd0OyZndDsgLyBcIC8g XDxicj4mZ3Q7Jmd0OyZndDsgLyBcIC8gXDxicj4mZ3Q7Jmd0OyZndDsgUkIxMTEgUkIxMTIgUkIx MjEgUkIxMjI8YnI+Jmd0OyZndDsmZ3Q7IFwgXCAvIC88YnI+Jmd0OyZndDsmZ3Q7IFwgXCAvIC88 YnI+Jmd0OyZndDsmZ3Q7IFwgXC8gLzxicj4mZ3Q7Jmd0OyZndDsgLS0tLS0tUjItLS0tLS08YnI+ Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyBXZSBjYW4gc2VlIHRoYXQgdGhlcmUgYXJlIDQg cGF0aHMgd2l0aCAzIGhvcHMgdG8gZ2V0IGZyb20gUjEgdG8gUjIsIDxicj4mZ3Q7Jmd0OyZndDsg d2l0aCB0d28gbGF5ZXJzIG9mIEVDTVAgZGVjaXNpb25zLiBCdXQgaG93IG1hbnkgYXZhaWxhYmxl IHBhdGhzIGFyZTxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyB0aGVyZT88YnI+Jmd0OyZndDsmZ3Q7 PGJyPiZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsgR2l2ZW4gdGhhdCB0aGUgUkJyaWRnZXMg bWFrZSBpbmRlcGVuZGVudCBFQ01QIGRlY2lzaW9ucywgYW5kIGhvdyA8YnI+Jmd0OyZndDsmZ3Q7 IHRoZXkgZG8gdGhhdCBpcyBhIGxvY2FsIG1hdHRlciwgaXQgY291bGQgYmUgdGhlIGNhc2UgdGhh dCBmb3IgYW55IDxicj4mZ3Q7Jmd0OyZndDsgcGFja2V0LCBpZiBSMSBwaWNrcyB0aGUgbGVmdCBs aW5rLCB0aGVuIFIxMSB3b3VsZCBhbHNvIHBpY2sgdGhlIGxlZnQgPGJyPiZndDsmZ3Q7Jmd0OyBs aW5rOyBpZjxicj4mZ3Q7Jmd0OyZndDsgUjEgcGlja3MgdGhlIHJpZ2h0IGxpbmssIHRoZW4gUjEy IGFsc28gcGlja3MgdGhlIHJpZ2h0IGxpbmsuPGJyPiZndDsmZ3Q7Jmd0OyBUaHVzIHRoZXJlIHdv dWxkIGJlIG5vIHBhY2tldCAoZGF0YSBvciBPQU0pIHRoYXQgd291bGQgY2F1c2UgcGFja2V0cyA8 YnI+Jmd0OyZndDsmZ3Q7IGJldHdlZW4gUjEgYW5kIFIyIHRvIHBhc3MgdmlhIFJCMTEyIG9yIFJC MTIxLjxicj4mZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7IEV2ZW4gaWYgd2UgaWdub3JlIHRo YXQgYXMgdW5saWtlbHksIHRoZXJlIGlzIHN0aWxsIHRoZSBmYWN0IHRoYXQgUjEgPGJyPiZndDsm Z3Q7Jmd0OyBjYW4ndCBlYXNpbHkgdGVsbCBob3cgbWFueSAoc2hvcnRlc3QpIHBhdGhzIHRoZXJl IG1pZ2h0IGJlIGJldHdlZW4gPGJyPiZndDsmZ3Q7Jmd0OyBpdCBhbmQgUjIuIFdpdGggc2luZ2xl LWxldmVsIFRSSUxMIHRoZSBMU0RCIGNvdWxkIGJlIHVzZWQgdG8gdGVsbCwgPGJyPiZndDsmZ3Q7 Jmd0OyBidXQgaWY8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7IHdlIGV2 ZXIgZ28gdG8gbXVsdGktbGV2ZWwgdGhhdCB3b3VsZG4ndCBiZSB0aGUgY2FzZSBhbnkgbW9yZS48 YnI+Jmd0OyZndDsmZ3Q7IEFuZCBldmVuIGlmIFIxIGtub3dzIHRoYXQgdGhlcmUgYXJlIDQgcG90 ZW50aWFsIHBhdGhzLCBpdCBjYW4ndCA8YnI+Jmd0OyZndDsmZ3Q7IGZvcm1hdDxicj4mZ3Q7Jmd0 Ozxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsgYSBkYXRhIHBhY2tldCAob3IgZm9ybWF0IHRo ZSBmbG93IGVudHJvcHkgaW4gYW4gT0FNIHBhY2tldCkgaW4gc3VjaCA8YnI+Jmd0OyZndDsmZ3Q7 IGEgd2F5IHRoYXQgcGFydGljdWxhciBwYXRocyBnZXQgY2hvc2VuIGJ5IGRvd25zdHJlYW0gRUNN UCBkZWNpc2lvbnMuPGJyPiZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsgVGh1cyBmb3IgYW55 IG5vdGlvbiBvZiAmcXVvdDthbGwgYXZhaWxhYmxlIHBhdGhzJnF1b3Q7IHRoYXQgbWFrZSBzZW5z ZSB0byBtZSwgPGJyPiZndDsmZ3Q7Jmd0OyB3ZSdkIG5lZWQgYW4gT0FNIGFwcHJvYWNoIHRoYXQg Y2FuIGV4cGxvcmUgdGhlIHRvcG9sb2d5IG9uZSBob3AgYXQgYSA8YnI+Jmd0OyZndDsmZ3Q7IHRp bWUgYW5kIGF0IGVhY2ggaG9wIGV4cGxvcmUgYWxsIHRoZSBwb3NzaWJsZSBFQ01QIGNob2ljZXMu IFVzaW5nIDxicj4mZ3Q7Jmd0OyZndDsgdGhlIGVudHJvcHkgZG9lc24ndCBoZWxwIHdpdGggdGhp cyAoYnV0IHRoZSBlbnRyb3B5IGlzIGNyaXRpY2FsIGZvciA8YnI+Jmd0OyZndDsmZ3Q7IGZvbGxv d2luZyB0aGUgcGF0aCB0YWtlbiBieSBhIHBhcnRpY3VsYXIgZmxvdyBvZiBkYXRhIHBhY2tldHMp Ljxicj4mZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7IEhlbmNlIGl0IHdvdWxkIGJlIGdvb2Qg dG8gY2xhcmlmeSB3aGF0IHRoZSBhc3N1bXB0aW9ucyBhcmUgYmVoaW5kIDxicj4mZ3Q7Jmd0OyZn dDsgdGhpczxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsgbm90aW9uIG9m IGFsbCBhdmFpbGFibGUgcGF0aHMuPGJyPiZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsgVGhh bmtzLDxicj4mZ3Q7Jmd0OyZndDsgRXJpazxicj4mZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7 IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPiZndDsm Z3Q7Jmd0OyB0cmlsbCBtYWlsaW5nIGxpc3Q8YnI+Jmd0OyZndDsmZ3Q7IDwvc3Bhbj48YSBocmVm PSJtYWlsdG86dHJpbGxAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPnRyaWxsQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48YnI+Jmd0 OyZndDsmZ3Q7IDwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3RyaWxsIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi Q291cmllciBOZXciJz5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxs PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291 cmllciBOZXciJz48YnI+Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0Ozxi cj4mZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4mZ3Q7Jmd0OyB0cmlsbCBtYWlsaW5nIGxpc3Q8YnI+Jmd0OyZndDsgPC9zcGFuPjxhIGhy ZWY9Im1haWx0bzp0cmlsbEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+dHJpbGxAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxicj4m Z3Q7Jmd0OyA8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby90cmlsbCI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Iic+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmlsbDwv c3Bhbj48L2E+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Iic+PGJyPiZndDsmZ3Q7PGJyPiZndDs8YnI+Jmd0OyBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7IHRyaWxsIG1haWxpbmcgbGlzdDxi cj4mZ3Q7IDwvc3Bhbj48YSBocmVmPSJtYWlsdG86dHJpbGxAaWV0Zi5vcmciPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPnRyaWxsQGlldGYu b3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi Q291cmllciBOZXciJz48YnI+Jmd0OyA8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby90cmlsbCI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby90cmlsbDwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPnRyaWxsIG1haWxpbmcgbGlzdDx1PjxzcGFuIHN0eWxlPSdj b2xvcjpibHVlJz48YnI+PC9zcGFuPjwvdT48L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnRyaWxsQGll dGYub3JnIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmll ciBOZXciJz50cmlsbEBpZXRmLm9yZzwvc3Bhbj48L2E+PHU+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibHVlJz48YnI+PC9zcGFu PjwvdT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxs Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXci Jz5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsPC9zcGFuPjwvYT48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48 YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+dHJp bGwgbWFpbGluZyBsaXN0PHU+PHNwYW4gc3R5bGU9J2NvbG9yOmJsdWUnPjxicj48L3NwYW4+PC91 Pjwvc3Bhbj48YSBocmVmPSJtYWlsdG86dHJpbGxAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPnRyaWxsQGlldGYub3JnPC9z cGFuPjwvYT48dT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291 cmllciBOZXciO2NvbG9yOmJsdWUnPjxicj48L3NwYW4+PC91PjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJpbGwiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdHJpbGw8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxicj48dHQ+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3R0Pjxicj48dHQ+dHJpbGwgbWFpbGluZyBs aXN0PC90dD48YnI+PHR0PjxhIGhyZWY9Im1haWx0bzp0cmlsbEBpZXRmLm9yZyI+dHJpbGxAaWV0 Zi5vcmc8L2E+PC90dD48YnI+PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdHJpbGwiPjx0dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmlsbDwvc3Bhbj48L3R0Pjwv YT48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2JvZHk+PC9odG1sPg== ------_=_NextPart_002_01CD270D.BF909872-- ------_=_NextPart_001_01CD270D.BF909872 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.gif Content-Location: image001.gif R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 ------_=_NextPart_001_01CD270D.BF909872-- From sunny.rajagopalan@us.ibm.com Mon Apr 30 13:26:22 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9610921E8097 for ; Mon, 30 Apr 2012 13:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.444 X-Spam-Level: X-Spam-Status: No, score=-10.444 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 4oFncu4c6mbj for ; Mon, 30 Apr 2012 13:26:20 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by ietfa.amsl.com (Postfix) with ESMTP id 881FF21E804E for ; Mon, 30 Apr 2012 13:26:20 -0700 (PDT) Received: from /spool/local by e32.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 30 Apr 2012 14:26:18 -0600 Received: from d03dlp02.boulder.ibm.com (9.17.202.178) by e32.co.us.ibm.com (192.168.1.132) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 30 Apr 2012 14:25:33 -0600 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id F25B03E4004C; Mon, 30 Apr 2012 14:25:30 -0600 (MDT) Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q3UKPIjQ016260; Mon, 30 Apr 2012 14:25:23 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q3UKPICE012508; Mon, 30 Apr 2012 14:25:18 -0600 Received: from d03nm127.boulder.ibm.com (d03nm127.boulder.ibm.com [9.17.195.18]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q3UKPGeK012380; Mon, 30 Apr 2012 14:25:18 -0600 In-Reply-To: <344037D7CFEFE84E97E9CC1F56C5F4A5010A332E@xmb-sjc-214.amer.cisco.com> References: <4F9ACE0E.7030408@sonic.net> <4F9ACF05.9070302@acm.org><4F9B2697.8080401@acm.org><344037D7CFEFE84E97E9CC1F56C5F4A5010A2FFF@xmb-sjc-214.amer.cisco.com><4F9CB95E.4030902@acm.org><344037D7CFEFE84E97E9CC1F56C5F4A5010A30CC@xmb-sjc-214.amer.cisco.com> <344037D7CFEFE84E97E9CC1F56C5F4A5010A32ED@xmb-sjc-214.amer.cisco.com> <344037D7CFEFE84E97E9CC1F56C5F4A5010A332E@xmb-sjc-214.amer.cisco.com> To: "Tissa Senevirathne (tsenevir)" MIME-Version: 1.0 X-KeepSent: B2A60F29:60C2AE22-872579F0:006F3682; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: Santosh Rajagopalan Date: Mon, 30 Apr 2012 13:25:22 -0700 X-MIMETrack: Serialize by Router on D03NM127/03/M/IBM(Release 8.5.1FP2|March 17, 2010) at 04/30/2012 14:25:17, Serialize complete at 04/30/2012 14:25:17 Content-Type: multipart/related; boundary="=_related 007034E7882579F0_=" X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12043020-3270-0000-0000-000005F2F5F3 Cc: Donald Eastlake , trill-bounces@ietf.org, David M Bond , trill@ietf.org Subject: Re: [trill] TRILL OAM Requirements: available paths X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 20:26:22 -0000 This is a multipart message in MIME format. --=_related 007034E7882579F0_= Content-Type: multipart/alternative; boundary="=_alternative 007034E7882579F0_=" --=_alternative 007034E7882579F0_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 V2hlbiBwb2xhcml6YXRpb24gc3RyaWtlcywgaW4gdGhlIGV4YW1wbGUgYmVsb3csIGFsbCBmbG93 cyBzdGFydGluZyBmcm9tIA0KUjEgd291bGQgdXNlIFJCMTItUkIxMjIgKGJlY2F1c2UgdGhlIGhh c2ggcmVzdWx0IHdhcyAiMiIgYXQgUjEgYXMgd2VsbCBhcyANCmF0IFJCMTIpLiBObyBmbG93cyBz dGFydGluZyBmcm9tIFIxIHdvdWxkIGV2ZXIgZ28gYWxvbmcgdGhlICBSQjEyLVJCMTIxIA0KcGF0 aC4gSXQgaXMgY29tbW9uIHRvIGV4cG9ydCBhbiBpbnRlcmZhY2UgZm9yIHRoZSB1c2VyIHRvIGNo YW5nZSB0aGUgc2VlZCANCnRvIHRoZSBoYXNoIHdoZW4gc2hlIGRldGVjdHMgcG9sYXJpemF0aW9u IGhhcyBvY2N1cnJlZDoNCg0KaHR0cDovL3d3dy5jaXNjby5jb20vZW4vVVMvcHJvZC9jb2xsYXRl cmFsL3N3aXRjaGVzL3BzOTQ0MS9wczk0MDIvd2hpdGVfcGFwZXJfYzExLTY4NzU1NC5odG1sI3dw OTAwMDI4NiANCg0KDQoNCg0KDQpGcm9tOiAgICJUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmly KSIgPHRzZW5ldmlyQGNpc2NvLmNvbT4NClRvOiAgICAgU2FudG9zaCBSYWphZ29wYWxhbi9TYW50 YSBDbGFyYS9JQk1ASUJNVVMNCkNjOiAgICAgIkRvbmFsZCBFYXN0bGFrZSIgPGQzZTNlM0BnbWFp bC5jb20+LCA8dHJpbGwtYm91bmNlc0BpZXRmLm9yZz4sIA0KRGF2aWQgTSBCb25kL0JlZGZvcmQv SUJNQElCTVVTLCA8dHJpbGxAaWV0Zi5vcmc+DQpEYXRlOiAgIDA0LzMwLzIwMTIgMDE6MTQgUE0N ClN1YmplY3Q6ICAgICAgICBSRTogW3RyaWxsXSBUUklMTCBPQU0gUmVxdWlyZW1lbnRzOiBhdmFp bGFibGUgcGF0aHMNCg0KDQoNClN1bm55DQogDQpBcmUgd2UgdGFsa2luZyBhYm91dCBhIHNpbmds ZSBmbG93IGhlcmUgb3IgbXVsdGlwbGUgZmxvd3MgPw0KIA0KIA0KRnJvbTogdHJpbGwtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOnRyaWxsLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiAN ClNhbnRvc2ggUmFqYWdvcGFsYW4NClNlbnQ6IE1vbmRheSwgQXByaWwgMzAsIDIwMTIgMTowNSBQ TQ0KVG86IFRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpDQpDYzogRG9uYWxkIEVhc3RsYWtl OyB0cmlsbC1ib3VuY2VzQGlldGYub3JnOyBEYXZpZCBNIEJvbmQ7IHRyaWxsQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW3RyaWxsXSBUUklMTCBPQU0gUmVxdWlyZW1lbnRzOiBhdmFpbGFibGUgcGF0 aHMNCiANClRpc3NhLCANCkhhc2ggcG9sYXJpemF0aW9uIGNhbiByZXN1bHQgaW4gc29tZSBvZiB0 aGUgZWNtcCBwYXRocyBiZWluZyB1bnV0aWxpemVkLiANCkluIEVyaWMncyBleGFtcGxlOiANCg0K DQogICAgICAgICAgICAgICBSMQ0KICAgICAgICAgICAgICAvICBcDQogICAgICAgICAgICAgLyAg ICBcDQogICAgICAgICAgICAvICAgICAgXA0KICAgICAgICAgICAvICAgICAgICBcDQogICAgICAg ICAgLyAgICAgICAgICBcDQogICAgICAgUkIxMSAgICAgICAgICBSQjEyDQogICAgICAgLyAgXCAg ICAgICAgICAvICBcDQogICAgICAvICAgIFwgICAgICAgIC8gICAgXA0KICAgUkIxMTEgIFJCMTEy ICBSQjEyMSAgUkIxMjINCiAgICAgIFwgICAgICBcICAgIC8gICAgICAvDQogICAgICAgXCAgICAg IFwgIC8gICAgICAvDQogICAgICAgIFwgICAgICBcLyAgICAgIC8NCiAgICAgICAgIC0tLS0tLVIy LS0tLS0tDQoNCklmIFIxIGFuZCBSQjEyIHVzZSB0aGUgc2FtZSBoYXNoIHBvbHlub21pYWwgJiBz ZWVkLCB0aGVuICphbGwqIGZsb3dzIHdoaWNoIA0KYXJyaXZlIGF0IFJCMTIgd2lsbCBnbyBhbG9u ZyB0aGUgbGluayB0byBSQjEyMiAtIHRoZSBsaW5rIHRvIFJCMTIxIGZyb20gDQpSQjEyIHdpbGwg bmV2ZXIgYmUgdXNlZC4gVGhlIE9BTSB0b29sIHNob3VsZCBhbGxvdyB1cyB0byBmaWd1cmUgb3V0 IHRoaXMgDQppcyBoYXBwZW5pbmcsIGluc3RlYWQgb2YgZ2l2aW5nIHVzIHJlZHVuZGFudCBpbmZv cm1hdGlvbiBhbHJlYWR5IGF2YWlsYWJsZSANCmluIElTSVMgbHNkYi4gDQpJIHdvdWxkIGhlc2l0 YXRlIHRvIGNhbGwgdGhpcyBhIGRlZmVjdC4gV2hpbGUgaXQgaXMgdHJ1ZSB0aGF0IGEgbG90IG9m IA0KYXNpY3MgaGF2ZSBjb3VudGVybWVhc3VyZXMgZm9yIHRoaXMgKHVzdWFsbHkgYnkgaW5jbHVk aW5nIGEgcmFuZG9tIHNlZWQgYXMgDQppbnB1dCB0byB0aGUgaGFzaCBwb2x5bm9taWFsKSwgeW91 IGNhbm5vdCBydWxlIHRoaXMgb3V0IDEwMCUuIFBsZWFzZSBsb29rIA0KYXQgdGhpcyBkb2N1bWVu dGF0aW9uIGZyb20gYSB3ZWxsIGtub3duIG5ldHdvcmtpbmcgY29tcGFueSA7LSkgDQpodHRwOi8v d3d3LmNpc2NvLmNvbS9lbi9VUy9kb2NzL2lvcy8xMl80dC9pcF9tY2FzdC9jb25maWd1cmF0aW9u L2d1aWRlL21jdGxzcGx0Lmh0bWwjd3AxMDY0NTAxIA0KDQoNCi0tIA0KU3VubnkgDQoNCg0KDQoN CkZyb206ICAgICAgICAiVGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZpcikiIDx0c2VuZXZpckBj aXNjby5jb20+IA0KVG86ICAgICAgICBEYXZpZCBNIEJvbmQvQmVkZm9yZC9JQk1ASUJNVVMgDQpD YzogICAgICAgIERvbmFsZCBFYXN0bGFrZSA8ZDNlM2UzQGdtYWlsLmNvbT4sIHRyaWxsLWJvdW5j ZXNAaWV0Zi5vcmcsIA0KdHJpbGxAaWV0Zi5vcmcgDQpEYXRlOiAgICAgICAgMDQvMzAvMjAxMiAx MjoyOSBQTSANClN1YmplY3Q6ICAgICAgICBSZTogW3RyaWxsXSBUUklMTCBPQU0gUmVxdWlyZW1l bnRzOiBhdmFpbGFibGUgcGF0aHMgDQpTZW50IGJ5OiAgICAgICAgdHJpbGwtYm91bmNlc0BpZXRm Lm9yZyANCg0KDQoNCg0KTGV0IG1lIHN0YXJ0IGZyb20gdGhlIGJhc2ljcy4gDQogIA0KMS4gICAg ICAgVFJJTEwgaXMgYWxsIGFib3V0IG11bHRpcGxlIGFjdGl2ZSBwYXRocy4gDQoyLiAgICAgICBN dWx0aXBsZSBhY3RpdmUgcGF0aHMgYXJlIGRlcml2ZWQgZnJvbSBsZWFzdCBjb3N0IHBhdGhzIHRv IGEgDQpzcGVjaWZpYyBkZXN0aW5hdGlvbnMuIA0KMy4gICAgICAgV2VsbCBkZWZpbmVkIGFuZCBp bXBsZW1lbnRlZCBIYXNoaW5nIGFsZ29yaXRobXMgcHJvdmlkZSBhbiBhbG1vc3QgDQpldmVuIGRp c3RyaWJ1dGlvbiBhY3Jvc3MgYWxsIG9mIHRoZSBhdmFpbGFibGUgbGVhc3QgY29zdCBwYXRocyB0 byBhIA0KZGVzdGluYXRpb24gDQo0LiAgICAgICBJZiBhIGdpdmVuIGZsb3cg4oCceOKAnSBkb2Vz IG5vdCBtYXAgdG8gIGEgc3BlY2lmaWMgbGVhc3QgY29zdCBwYXRoLCANCmRvZXMgbm90IG1hcCB0 byBhIHNwZWNpZmljIGxlYXN0IGNvc3QgcGF0aCBkb2VzIG5vdCBtZWFuIGFub3RoZXIgZmxvdyDi gJx54oCdIA0KdG8gdGhlIHNhbSBkZXN0aW5hdGlvbiB3aWxsIG5vdCBtYXAgdG8gdGhlIHRoYXQg cGF0aC4gDQo1LiAgICAgICBXZWxsIGltcGxlbWVudGVkIGhhc2hpbmcgYWxnb3JpdGhtcyBwcm92 aWRlIGV2ZW4gZGlzdHJpYnV0aW9uIG9mIA0KZmxvd3MuIA0KNi4gICAgICAgSGVuY2UgaXQgaXMg aW1wb3J0YW50IHRvIGhhdmUgYWJpbGl0eSB0byB0ZXN0IGFsbCBhdmFpbGFibGUgbGVhc3QgDQpj b3N0IHBhdGhzIHRvIGEgZGVzdGluYXRpb24uIA0KNy4gICAgICAgSXQgaXMgYW4gaW1wbGVtZW50 YXRpb24gZGVmZWN0LCBJZiB0aGVyZSBpcyBhbiBpbXBsZW1lbnRhdGlvbiBvdXQgDQp0aGVyZSB3 aGljaCBkb2VzIG5vdCBoYXNoIGZsb3dzIChvdmVyIGEgbG9uZ2VyIHNhbXBsaW5nIHBlcmlvZCkg IGluIHRvIGEgDQpzcGVjaWZpYyDigJxsZWFzdCBjb3N0IHBhdGjigJ0gb2Ygc2V0IG9mIGxlYXN0 IGNvc3QgcGF0aHMgdG8gYSBkZXN0aW5hdGlvbiwgDQphbW9uZyBhbGwgYXZhaWxhYmxlIOKAnGxl YXN0IGNvc3QgcGF0aHPigJ0gdG8gdGhhdCBkZXN0aW5hdGlvbi4gDQogIA0KRnJvbTogRGF2aWQg TSBCb25kIFttYWlsdG86ZG1ib25kQHVzLmlibS5jb21dIA0KU2VudDogTW9uZGF5LCBBcHJpbCAz MCwgMjAxMiA4OjM5IEFNDQpUbzogVGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZpcikNCkNjOiBE b25hbGQgRWFzdGxha2U7IHRyaWxsQGlldGYub3JnOyB0cmlsbC1ib3VuY2VzQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW3RyaWxsXSBUUklMTCBPQU0gUmVxdWlyZW1lbnRzOiBhdmFpbGFibGUgcGF0 aHMgDQogDQpKdXN0IGEgcXVlc3Rpb24gY29taW5nIGZyb20gdGhpcyBjb252ZXJzYXRpb24gdGhh dCBJIHdhbnQgdG8gY2xhcmlmeToNCg0KU28gd2UgaGF2ZSAnYWxsIHBvc3NpYmxlIHBhdGhzJyAo MSkgd2hpY2ggY291bGQgaW5jbHVkZSBub24tbGVhc3QgY29zdCANCnBhdGhzIGFuZCBzbyBvZiBj b3Vyc2Ugd2UgZG9uJ3Qgd2FudCB0byB1c2UgdGhpcyBkZWZpbml0aW9uLg0KDQpUaGVuIHdlIGhh dmUgJ2FsbCBlY21wIHBhdGhzJyBvciAnYWxsIGxlYXN0IGNvc3QgcGF0aHMnICgyKSB3aGljaCBN QVkgDQppbmNsdWRlIHBhdGhzIG5ldmVyIGNob3NlbiBieSBhIHRyYW5zaXQgUmJyaWRnZSBiZWNh dXNlIG9mIHRoZSBsb2NhbCANCmhhc2hpbmcgY2hvaWNlcy4NCg0KVGhlbiB3ZSBoYXZlICdhbGwg dGhlIGxlYXN0IGNvc3QgcGF0aHMgd2hpY2ggbWF5IGJlIGNob3NlbiBnaXZlbiB0aGUgDQpoYXNo aW5nIGltcGxlbWVudGF0aW9uIG9uIHRoZSBsb2NhbCBSYnJpZGdlcycgKDMpLg0KDQpJIHdvbmRl ciBpZiBjaG9pY2UgKDIpIGlzIHVzZWZ1bCBvciBkbyB3ZSBvbmx5IHJlYWxseSBjYXJlIGFib3V0 IGNob2ljZSANCigzKS4gRm9yIGluc3RhbmNlLCBpZiB5b3UgaGF2ZSAxNiBlcXVhbCBjb3N0IHBh dGhzIGZyb20gQSB0byBCIGFuZCB5b3VyIA0KaGFzaGluZyBvbmx5IHdpbGwgZXZlciB1c2UgMiBv ZiB0aG9zZSBwYXRocyBkbyB3ZSBjYXJlIGFib3V0IHJlcG9ydGluZyANCmJhY2sgZWNtcCBwYXRo cyB0aGF0IHdpbGwgbmV2ZXIgaW4gcHJhY3RpY2UgYmUgdXNlZD8gUGVyaGFwcyB0aGUgDQpkZWZp bml0aW9uIHNob3VsZCBiZSB0aWdodGVuZWQgdG8gb25seSByZXF1aXJlIGRldGVybWluYXRpb24g b2YgYWxsIGxlYXN0IA0KY29zdCBwYXRocyB0aGF0IGNvdWxkIGJlIHVzZWQgZ2l2ZW4gdGhlIGxv Y2FsIGhhc2hpbmcgaW1wbGVtZW50YXRpb24uIE9yIA0KYW0gSSBtaXN1bmRlcnN0YW5kaW5nIHRo ZSBjb252ZXJzYXRpb24gYW5kIGlzIHRoaXMgYWxyZWFkeSB0aGUgcG9pbnQgYmVpbmcgDQptYWRl IGJldHdlZW4gdGhlb3JldGljYWwgcGF0aHMgYW5kIGxlYXN0IGNvc3QgcGF0aHMuDQoNClRoYW5r cywNCkRhdmlkDQoNCiJUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKSIgLS0tMDQvMjkvMjAx MiAxMTo0MzowNyBQTS0tLUkgbGlrZSB0aGF0IA0KRG9uYWxkLi4gV2UgY2FuIHVzZSAiYWxsIGxl YXN0IGNvc3QgcGF0aHMiLCB0aGF0IGlzIHRlY2huaWNhbGx5IG1vcmUgDQpwcmVjaXNlIGFuZCBy ZXByZXNlDQoNCkZyb206ICJUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKSIgPHRzZW5ldmly QGNpc2NvLmNvbT4NClRvOiAiRG9uYWxkIEVhc3RsYWtlIiA8ZDNlM2UzQGdtYWlsLmNvbT4sIDx0 cmlsbEBpZXRmLm9yZz4NCkRhdGU6IDA0LzI5LzIwMTIgMTE6NDMgUE0NClN1YmplY3Q6IFJlOiBb dHJpbGxdIFRSSUxMIE9BTSBSZXF1aXJlbWVudHM6IGF2YWlsYWJsZSBwYXRocw0KU2VudCBieTog dHJpbGwtYm91bmNlc0BpZXRmLm9yZyANCg0KDQoNCg0KDQpJIGxpa2UgdGhhdCBEb25hbGQuLiBX ZSBjYW4gdXNlICJhbGwgbGVhc3QgY29zdCBwYXRocyIsIHRoYXQgaXMgDQp0ZWNobmljYWxseSBt b3JlIHByZWNpc2UgYW5kIHJlcHJlc2VudCBleGFjdGx5IHdoYXQgSVMtSVMgZG9lcy4NCg0KVGhh bmtzDQpUaXNzYQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogdHJpbGwtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnRyaWxsLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiANCkRvbmFsZCBFYXN0bGFrZQ0KU2VudDogU3VuZGF5LCBBcHJpbCAyOSwgMjAxMiA2OjI3IFBN DQpUbzogdHJpbGxAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdHJpbGxdIFRSSUxMIE9BTSBSZXF1 aXJlbWVudHM6IGF2YWlsYWJsZSBwYXRocw0KDQpJIGRvbid0IHRoaW5rIHRoZSB3b3JkaW5nICJh bGwgcGF0aHMiIHNob3VsZCBldmVyIGJlIHVzZWQuIElmIHlvdSB0aGUgaXQgDQpsaXRlcmFsbHks IGl0IHdvdWxkIGV2ZW4gaW5jbHVkZSBwYXRocyB0aGF0IGdvIHRocm91Z2ggc29tZSBSQnJpZGdl cyBtb3JlIA0KdGhhbiBvbmNlLg0KDQpJIGRvbid0IHBhcnRpY3VsYXJseSBsaWtlICJhbGwgRUNN UCBwYXRocyIgZWl0aGVyLiBJIHRoaW5rIHRoZSBjbGVhcmVzdCANCndvcmRpbmcgaXMgImFsbCBs ZWFzdCBjb3N0IHBhdGhzIiBpZiB5b3UgYXJlIHRhbGtpbmcgYWJvdXQga25vd24gdW5pY2FzdC4g DQooQW5kICJhbGwgZGlzdHJpYnV0aW9uIHRyZWUgcGF0aHMiIGlmIHlvdSB3ZXJlIHRhbGtpbmcg YWJvdXQgDQptdWx0aS1kZXN0aW5hdGlvbiBmcmFtZXMuKQ0KDQpUaGFua3MsDQpEb25hbGQNCj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpEb25hbGQgRS4gRWFzdGxha2UgM3JkICAgKzEt NTA4LTMzMy0yMjcwIChjZWxsKQ0KMTU1IEJlYXZlciBTdHJlZXQsIE1pbGZvcmQsIE1BIDAxNzU3 IFVTQQ0KZDNlM2UzQGdtYWlsLmNvbQ0KDQoNCk9uIFNhdCwgQXByIDI4LCAyMDEyIGF0IDExOjQ1 IFBNLCBFcmlrIE5vcmRtYXJrIDxub3JkbWFya0BhY20ub3JnPiB3cm90ZToNCj4gT24gNC8yNy8x MiA1OjEyIFBNLCBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKSB3cm90ZToNCj4+DQo+PiBP ZiBjb3Vyc2UgaXQgaXMgcG9zc2libGUuIFRoZSBJUy1JUyB0b3BvbG9neSB0YWJsZSBwcm92aWRl IHRoZSANCj4+IGluZm9ybWF0aW9uIG9uIGFsbCBhdmFpbGFibGUgRUNNUCBwYXRocyB0byBhIHNw ZWNpZmljIGRlc3RpbmF0aW9uIA0KPj4gd2hlbiB0aGUgZWdyZXNzIFJCUmlkZ2Ugbmlja25hbWUg aXMga25vd24uIFRoYXQgaXMgd2hhdCBUUklMTCB1bmljYXN0IA0KPj4gZm9yd2FyZGluZyB0YWJs ZSBhbGwgYWJvdXQuIE5vdCBzdXJlIHdoeSB5b3UgYXJlIHNheWluZyBpdCBpcyBub3QgDQo+PiBw b3NzaWJsZSB0byBrbm93IGFsbCBFQ01QIHBhdGhzLg0KPg0KPg0KPiBZb3UgYXJlIHRhbGtpbmcg YWJvdXQgd2hhdCBTYW50b3NoIGNhbGxlZCAiYWxsIHRoZW9yZXRpY2FsbHkgYXZhaWxhYmxlIA0K PiBwYXRocyIuIFRob3NlIGNhbiBiZSBkZXRlcm1pbmVkIGZyb20gSVMtSVMuDQo+DQo+IEJ1dCB0 aGUgZG9jdW1lbnQgdGFsa3MgYWJvdXQgImFsbCBhdmFpbGFibGUgcGF0aHMiIGFuZCBJIGRvbid0 IGtub3cgDQo+IHdoYXQgdGhhdCBpcyBzdXBwb3NlZCB0byBtZWFuLiBEbyB5b3UgaGF2ZSBhIHN1 Y2NpbmN0IGRlZmluaXRpb24/DQo+DQo+IFdoYXQgaXMgY2xlYXIgdG8gbWUgaXMgdGhhdCB0aGVy ZSBjYW4gYmUgYSBzdWJzZXQgb2YgdGhlIHBhdGhzIHRoYXQgDQo+IGFyZSBkZXRlcm1pbmVkIGZy b20gSVMtSVMgdGhhdCB3b3VsZCBuZXZlciBiZSB1c2VkLCBiZWNhdXNlIG5vIGVudHJvcHkgDQo+ IGluIGEgcGFja2V0IHdvdWxkIGV2ZXJ5IHBpY2sgdGhhdCBwYXRoLg0KPg0KPiBJcyB0aGUgcmVx dWlyZW1lbnQgaW4gdGhlIGRvY3VtZW50IHRoYXQgdGhlIE9BTSBzb2x1dGlvbiBzaG91bGQgYmUg DQo+IGFibGUgdG8gdGVzdCB0aG9zZSBwYXRocz8NCj4NCj4NCj4+IFdoYXQgcGF0aCBhbW9uZyBh dmFpbGFibGUgcGF0aHMgdG8gYmUgc2VsZWN0ZWQgZm9yIGEgc3BlY2lmaWVkIGlzIGEgDQo+PiBs b2NhbCBtYXR0ZXIuIFRoYXQgaXMgd2hhdCBhbGwgYWJvdXQgZmxvdyBlbnRyb3B5IGRpc2NvdmVy eS4gTGlrZSBJIA0KPj4gc3RhdGVkIGVhcmxpZXIgaG93IGl0IGlzIGRpc2NvdmVyZWQgaXMgYSBm cmFtZXdvcmsgYW5kIHNvbHV0aW9uIGlzc3VlLg0KPg0KPg0KPiBBZ3JlZWQuDQo+DQo+DQo+PiBJ ZiB5b3UgbmVlZCBzb21lIHJlZmVyZW5jZSBob3cgaXQgaXMgZG9uZSBpbiB0aGUgTVBMUyB3b3Js ZCBSRkMgNDM3OSANCj4+IGlzIGEgZ29vZCByZWZlcmVuY2UuDQo+DQo+DQo+IEFGQUlLIE1QTFMg ZG9lc24ndCBoYXZlIGEgbG9jYWxseSBkZWZpbmVkIEVDTVAgaGFzaCBmdW5jdGlvbiBpbiBldmVy eSANCmhvcC4NCj4gVFJJTEwgZG9lcywgd2hpY2ggbWFrZXMgdGhlc2UgYXNwZWN0cyBkaWZmZXJl bnQuDQo+DQo+IFJlZ2FyZHMsDQo+ICAgRXJpaw0KPg0KPg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4+IEZyb206IHRyaWxsLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzp0cmlsbC1i b3VuY2VzQGlldGYub3JnXSBPbiANCj4+IEJlaGFsZiBPZiBFcmlrIE5vcmRtYXJrDQo+PiBTZW50 OiBGcmlkYXksIEFwcmlsIDI3LCAyMDEyIDQ6MDcgUE0NCj4+IFRvOiBTYW50b3NoIFJhamFnb3Bh bGFuDQo+PiBDYzogdHJpbGxAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbdHJpbGxdIFRSSUxM IE9BTSBSZXF1aXJlbWVudHM6IGF2YWlsYWJsZSBwYXRocw0KPj4NCj4+IE9uIDQvMjcvMTIgMjox NSBQTSwgU2FudG9zaCBSYWphZ29wYWxhbiB3cm90ZToNCj4+Pg0KPj4+IEkgYWdyZWUsIHRoZSB3 b3JkaW5nIG5lZWRzIHRvIGJlIHRpZ2h0ZW5lZCB0byBzYXkgImFsbCBwb3NzaWJsZSBlY21wIA0K Pj4+IHBhdGhzIiByYXRoZXIgdGhhbiAiYWxsIGF2YWlsYWJsZSBwYXRocyIuIEFuIG9wZXJhdG9y IHdvcmtpbmcgb3V0DQo+Pj4gUjEtUjIgY29tbXVuaWNhdGlvbiBpcyBpbnRlcmVzdGVkIGluIGFs bCBwb3NzaWJsZSBwYXRocyBkYXRhIHRyYWZmaWMgDQo+Pj4gY291bGQgdGFrZSByYXRoZXIgdGhh biBhbGwgdGhlb3JldGljYWxseSBhdmFpbGFibGUgcGF0aHMuDQo+Pg0KPj4NCj4+IFRoZSBpc3N1 ZSBpcyB0aGF0IHRoZXJlIGlzIG5vdGhpbmcgaW4gdGhlIFRSSUxMIGRhdGFwbGFuZSBub3IgSVMt SVMgDQo+PiBjb250cm9sIHBsYW5lIHdoaWNoIGhlbHBzIHRoZSBvcGVyYXRvciBkZXRlcm1pbmUg dGhhdCBzb21lIHBhdGhzIA0KPj4gKHRocm91Z2ggUkIxMjEgYW5kIFJCMTEyIGluIHRoZSBleGFt cGxlKSBhcmUgbm90IHBvc3NpYmxlOyB0aGUgRUNNUCANCj4+IGlucHV0IGFuZCBoYXNoaW5nIGlz IGEgY29tcGxldGVseSBsb2NhbCBtYXR0ZXIgb24gZWFjaCBSQnJpZGdlLg0KPj4NCj4+IEl0IGlz bid0IHVzZWZ1bCB0byBzdGF0ZSBhIHJlcXVpcmVtZW50IGFyb3VuZCBzb21ldGhpbmcgdGhhdCBj YW4ndCBiZSANCj4+IGRldGVybWluZWQuDQo+Pg0KPj4gICAgIEVyaWsNCj4+DQo+Pj4NCj4+Pg0K Pj4+IEZyb206IEVyaWsgTm9yZG1hcms8bm9yZG1hcmtAYWNtLm9yZz4NCj4+PiBUbzogdHJpbGxA aWV0Zi5vcmcNCj4+PiBEYXRlOiAwNC8yNy8yMDEyIDA5OjUzIEFNDQo+Pj4gU3ViamVjdDogW3Ry aWxsXSBUUklMTCBPQU0gUmVxdWlyZW1lbnRzOiBhdmFpbGFibGUgcGF0aHMgU2VudCBieToNCj4+ PiB0cmlsbC1ib3VuY2VzQGlldGYub3JnDQo+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+PiAtLQ0KPj4+IC0t DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+PiBUd28gcmVxdWlyZW1lbnRzIHVzZSB0aGUgd29yZGlu ZyAiYWxsIGF2YWlsYWJsZSBwYXRocy4iIGFuZCAiYWxsIA0KPj4+IGF2YWlsYWJsZSBFQ01QIHBh dGhzLiIsIHJlc3BlY3RpdmVseSBhbmQgSSdtIG5vdCBzdXJlIEkga25vdyB3aGF0IA0KPj4+IHRo YXQNCj4+DQo+Pg0KPj4+IG1lYW5zLg0KPj4+DQo+Pj4gVGFrZSB0aGUgZm9sbG93aW5nIGV4YW1w bGUgcGljdHVyZToNCj4+Pg0KPj4+IFIxDQo+Pj4gLyBcDQo+Pj4gLyBcDQo+Pj4gLyBcDQo+Pj4g LyBcDQo+Pj4gLyBcDQo+Pj4gUkIxMSBSQjEyDQo+Pj4gLyBcIC8gXA0KPj4+IC8gXCAvIFwNCj4+ PiBSQjExMSBSQjExMiBSQjEyMSBSQjEyMg0KPj4+IFwgXCAvIC8NCj4+PiBcIFwgLyAvDQo+Pj4g XCBcLyAvDQo+Pj4gLS0tLS0tUjItLS0tLS0NCj4+Pg0KPj4+IFdlIGNhbiBzZWUgdGhhdCB0aGVy ZSBhcmUgNCBwYXRocyB3aXRoIDMgaG9wcyB0byBnZXQgZnJvbSBSMSB0byBSMiwgDQo+Pj4gd2l0 aCB0d28gbGF5ZXJzIG9mIEVDTVAgZGVjaXNpb25zLiBCdXQgaG93IG1hbnkgYXZhaWxhYmxlIHBh dGhzIGFyZQ0KPj4NCj4+IHRoZXJlPw0KPj4+DQo+Pj4NCj4+PiBHaXZlbiB0aGF0IHRoZSBSQnJp ZGdlcyBtYWtlIGluZGVwZW5kZW50IEVDTVAgZGVjaXNpb25zLCBhbmQgaG93IA0KPj4+IHRoZXkg ZG8gdGhhdCBpcyBhIGxvY2FsIG1hdHRlciwgaXQgY291bGQgYmUgdGhlIGNhc2UgdGhhdCBmb3Ig YW55IA0KPj4+IHBhY2tldCwgaWYgUjEgcGlja3MgdGhlIGxlZnQgbGluaywgdGhlbiBSMTEgd291 bGQgYWxzbyBwaWNrIHRoZSBsZWZ0IA0KPj4+IGxpbms7IGlmDQo+Pj4gUjEgcGlja3MgdGhlIHJp Z2h0IGxpbmssIHRoZW4gUjEyIGFsc28gcGlja3MgdGhlIHJpZ2h0IGxpbmsuDQo+Pj4gVGh1cyB0 aGVyZSB3b3VsZCBiZSBubyBwYWNrZXQgKGRhdGEgb3IgT0FNKSB0aGF0IHdvdWxkIGNhdXNlIHBh Y2tldHMgDQo+Pj4gYmV0d2VlbiBSMSBhbmQgUjIgdG8gcGFzcyB2aWEgUkIxMTIgb3IgUkIxMjEu DQo+Pj4NCj4+PiBFdmVuIGlmIHdlIGlnbm9yZSB0aGF0IGFzIHVubGlrZWx5LCB0aGVyZSBpcyBz dGlsbCB0aGUgZmFjdCB0aGF0IFIxIA0KPj4+IGNhbid0IGVhc2lseSB0ZWxsIGhvdyBtYW55IChz aG9ydGVzdCkgcGF0aHMgdGhlcmUgbWlnaHQgYmUgYmV0d2VlbiANCj4+PiBpdCBhbmQgUjIuIFdp dGggc2luZ2xlLWxldmVsIFRSSUxMIHRoZSBMU0RCIGNvdWxkIGJlIHVzZWQgdG8gdGVsbCwgDQo+ Pj4gYnV0IGlmDQo+Pg0KPj4NCj4+PiB3ZSBldmVyIGdvIHRvIG11bHRpLWxldmVsIHRoYXQgd291 bGRuJ3QgYmUgdGhlIGNhc2UgYW55IG1vcmUuDQo+Pj4gQW5kIGV2ZW4gaWYgUjEga25vd3MgdGhh dCB0aGVyZSBhcmUgNCBwb3RlbnRpYWwgcGF0aHMsIGl0IGNhbid0IA0KPj4+IGZvcm1hdA0KPj4N Cj4+DQo+Pj4gYSBkYXRhIHBhY2tldCAob3IgZm9ybWF0IHRoZSBmbG93IGVudHJvcHkgaW4gYW4g T0FNIHBhY2tldCkgaW4gc3VjaCANCj4+PiBhIHdheSB0aGF0IHBhcnRpY3VsYXIgcGF0aHMgZ2V0 IGNob3NlbiBieSBkb3duc3RyZWFtIEVDTVAgZGVjaXNpb25zLg0KPj4+DQo+Pj4gVGh1cyBmb3Ig YW55IG5vdGlvbiBvZiAiYWxsIGF2YWlsYWJsZSBwYXRocyIgdGhhdCBtYWtlIHNlbnNlIHRvIG1l LCANCj4+PiB3ZSdkIG5lZWQgYW4gT0FNIGFwcHJvYWNoIHRoYXQgY2FuIGV4cGxvcmUgdGhlIHRv cG9sb2d5IG9uZSBob3AgYXQgYSANCj4+PiB0aW1lIGFuZCBhdCBlYWNoIGhvcCBleHBsb3JlIGFs bCB0aGUgcG9zc2libGUgRUNNUCBjaG9pY2VzLiBVc2luZyANCj4+PiB0aGUgZW50cm9weSBkb2Vz bid0IGhlbHAgd2l0aCB0aGlzIChidXQgdGhlIGVudHJvcHkgaXMgY3JpdGljYWwgZm9yIA0KPj4+ IGZvbGxvd2luZyB0aGUgcGF0aCB0YWtlbiBieSBhIHBhcnRpY3VsYXIgZmxvdyBvZiBkYXRhIHBh Y2tldHMpLg0KPj4+DQo+Pj4gSGVuY2UgaXQgd291bGQgYmUgZ29vZCB0byBjbGFyaWZ5IHdoYXQg dGhlIGFzc3VtcHRpb25zIGFyZSBiZWhpbmQgDQo+Pj4gdGhpcw0KPj4NCj4+DQo+Pj4gbm90aW9u IG9mIGFsbCBhdmFpbGFibGUgcGF0aHMuDQo+Pj4NCj4+PiBUaGFua3MsDQo+Pj4gRXJpaw0KPj4+ DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ PiB0cmlsbCBtYWlsaW5nIGxpc3QNCj4+PiB0cmlsbEBpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJpbGwNCj4+Pg0KPj4+DQo+Pg0KPj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IHRyaWxsIG1haWxp bmcgbGlzdA0KPj4gdHJpbGxAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdHJpbGwNCj4+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IHRyaWxsIG1haWxpbmcgbGlzdA0KPiB0cmlsbEBpZXRmLm9y Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdHJpbGwgbWFpbGluZyBs aXN0DQp0cmlsbEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by90cmlsbA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CnRyaWxsIG1haWxpbmcgbGlzdA0KdHJpbGxAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vdHJpbGwNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQp0cmlsbCBtYWlsaW5nIGxpc3QNCnRyaWxsQGlldGYub3JnDQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsDQoNCg== --=_alternative 007034E7882579F0_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPldoZW4gcG9sYXJpemF0aW9uIHN0cmlrZXMs IGluIHRoZSBleGFtcGxlDQpiZWxvdywgYWxsIGZsb3dzIHN0YXJ0aW5nIGZyb20gUjEgd291bGQg dXNlIFJCMTItUkIxMjIgKGJlY2F1c2UgdGhlIGhhc2gNCnJlc3VsdCB3YXMgJnF1b3Q7MiZxdW90 OyBhdCBSMSBhcyB3ZWxsIGFzIGF0IFJCMTIpLiBObyBmbG93cyBzdGFydGluZyBmcm9tDQpSMSB3 b3VsZCBldmVyIGdvIGFsb25nIHRoZSAmbmJzcDtSQjEyLVJCMTIxIHBhdGguIEl0IGlzIGNvbW1v biB0byBleHBvcnQNCmFuIGludGVyZmFjZSBmb3IgdGhlIHVzZXIgdG8gY2hhbmdlIHRoZSBzZWVk IHRvIHRoZSBoYXNoIHdoZW4gc2hlIGRldGVjdHMNCnBvbGFyaXphdGlvbiBoYXMgb2NjdXJyZWQ6 PC9mb250Pg0KPGJyPg0KPGJyPjxhIGhyZWY9Imh0dHA6Ly93d3cuY2lzY28uY29tL2VuL1VTL3By b2QvY29sbGF0ZXJhbC9zd2l0Y2hlcy9wczk0NDEvcHM5NDAyL3doaXRlX3BhcGVyX2MxMS02ODc1 NTQuaHRtbCN3cDkwMDAyODYiPjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx1Pmh0dHA6Ly93d3cu Y2lzY28uY29tL2VuL1VTL3Byb2QvY29sbGF0ZXJhbC9zd2l0Y2hlcy9wczk0NDEvcHM5NDAyL3do aXRlX3BhcGVyX2MxMS02ODc1NTQuaHRtbCN3cDkwMDAyODY8L3U+PC9mb250PjwvYT48Zm9udCBz aXplPTM+DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0x IGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+RnJvbTogJm5ic3A7ICZuYnNwOyAmbmJz cDsNCiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7VGlz c2EgU2VuZXZpcmF0aG5lDQoodHNlbmV2aXIpJnF1b3Q7ICZsdDt0c2VuZXZpckBjaXNjby5jb20m Z3Q7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9InNhbnMtc2Vy aWYiPlRvOiAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7PC9mb250Pjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj5TYW50b3NoIFJhamFnb3BhbGFuL1NhbnRhDQpDbGFyYS9JQk1ASUJN VVM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJp ZiI+Q2M6ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPiZxdW90O0RvbmFsZCBFYXN0bGFrZSZxdW90Ow0KJmx0O2QzZTNlM0Bn bWFpbC5jb20mZ3Q7LCAmbHQ7dHJpbGwtYm91bmNlc0BpZXRmLm9yZyZndDssIERhdmlkIE0gQm9u ZC9CZWRmb3JkL0lCTUBJQk1VUywNCiZsdDt0cmlsbEBpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+RGF0ZTogJm5ic3A7 ICZuYnNwOyAmbmJzcDsNCiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+MDQvMzAvMjAxMiAwMToxNCBQTTwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgY29sb3I9IzVm NWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5TdWJqZWN0OiAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5i c3A7PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SRTogW3RyaWxsXQ0KVFJJ TEwgT0FNIFJlcXVpcmVtZW50czogYXZhaWxhYmxlIHBhdGhzPC9mb250Pg0KPGJyPg0KPGhyIG5v c2hhZGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0i Q2FsaWJyaSI+U3Vubnk8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFj ZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgw IGZhY2U9IkNhbGlicmkiPkFyZSB3ZSB0YWxraW5nIGFib3V0IGEgc2luZ2xlDQpmbG93IGhlcmUg b3IgbXVsdGlwbGUgZmxvd3MgPzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwNDA4 MCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMw MDQwODAgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJUYWhvbWEiPjxiPkZyb206PC9iPiB0cmlsbC1ib3VuY2VzQGlldGYub3JnIFs8L2ZvbnQ+PGEg aHJlZj0ibWFpbHRvOnRyaWxsLWJvdW5jZXNAaWV0Zi5vcmciPjxmb250IHNpemU9MiBmYWNlPSJU YWhvbWEiPm1haWx0bzp0cmlsbC1ib3VuY2VzQGlldGYub3JnPC9mb250PjwvYT48Zm9udCBzaXpl PTIgZmFjZT0iVGFob21hIj5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlNhbnRvc2ggUmFqYWdvcGFs YW48Yj48YnI+DQpTZW50OjwvYj4gTW9uZGF5LCBBcHJpbCAzMCwgMjAxMiAxOjA1IFBNPGI+PGJy Pg0KVG86PC9iPiBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKTxiPjxicj4NCkNjOjwvYj4g RG9uYWxkIEVhc3RsYWtlOyB0cmlsbC1ib3VuY2VzQGlldGYub3JnOyBEYXZpZCBNIEJvbmQ7IHRy aWxsQGlldGYub3JnPGI+PGJyPg0KU3ViamVjdDo8L2I+IFJlOiBbdHJpbGxdIFRSSUxMIE9BTSBS ZXF1aXJlbWVudHM6IGF2YWlsYWJsZSBwYXRoczwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 IkFyaWFsIj5UaXNzYSw8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpIYXNoIHBvbGFyaXphdGlv biBjYW4gcmVzdWx0IGluIHNvbWUgb2YgdGhlIGVjbXAgcGF0aHMgYmVpbmcgdW51dGlsaXplZC4N CkluIEVyaWMncyBleGFtcGxlOjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KPGJyPg0K PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBS MTxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsv ICZuYnNwO1w8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg LyAmbmJzcDsgJm5ic3A7XDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOy8gJm5ic3A7ICZuYnNwOyAmbmJzcDtcPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgLyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtcPGJyPg0KICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsvICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtcPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7IFJCMTEgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO1JCMTI8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgLyAmbmJz cDtcICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsvICZuYnNwO1w8YnI+DQogJm5i c3A7ICZuYnNwOyAmbmJzcDsvICZuYnNwOyAmbmJzcDtcICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOy8gJm5ic3A7DQombmJzcDtcPGJyPg0KICZuYnNwOyBSQjExMSAmbmJzcDtSQjExMiAmbmJz cDtSQjEyMSAmbmJzcDtSQjEyMjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwO1wgJm5ic3A7ICZu YnNwOyAmbmJzcDtcICZuYnNwOyAmbmJzcDsvICZuYnNwOyAmbmJzcDsNCiZuYnNwOy88YnI+DQog Jm5ic3A7ICZuYnNwOyAmbmJzcDsgXCAmbmJzcDsgJm5ic3A7ICZuYnNwO1wgJm5ic3A7LyAmbmJz cDsgJm5ic3A7ICZuYnNwOy88YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7XCAmbmJz cDsgJm5ic3A7ICZuYnNwO1wvICZuYnNwOyAmbmJzcDsgJm5ic3A7Lzxicj4NCiAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgLS0tLS0tUjItLS0tLS08L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+ PGJyPg0KSWYgUjEgYW5kIFJCMTIgdXNlIHRoZSBzYW1lIGhhc2ggcG9seW5vbWlhbCAmYW1wOyBz ZWVkLCB0aGVuICphbGwqIGZsb3dzDQp3aGljaCBhcnJpdmUgYXQgUkIxMiB3aWxsIGdvIGFsb25n IHRoZSBsaW5rIHRvIFJCMTIyIC0gdGhlIGxpbmsgdG8gUkIxMjENCmZyb20gUkIxMiB3aWxsIG5l dmVyIGJlIHVzZWQuIFRoZSBPQU0gdG9vbCBzaG91bGQgYWxsb3cgdXMgdG8gZmlndXJlIG91dA0K dGhpcyBpcyBoYXBwZW5pbmcsIGluc3RlYWQgb2YgZ2l2aW5nIHVzIHJlZHVuZGFudCBpbmZvcm1h dGlvbiBhbHJlYWR5IGF2YWlsYWJsZQ0KaW4gSVNJUyBsc2RiLjwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+ PGJyPg0KSSB3b3VsZCBoZXNpdGF0ZSB0byBjYWxsIHRoaXMgYSBkZWZlY3QuIFdoaWxlIGl0IGlz IHRydWUgdGhhdCBhIGxvdCBvZg0KYXNpY3MgaGF2ZSBjb3VudGVybWVhc3VyZXMgZm9yIHRoaXMg KHVzdWFsbHkgYnkgaW5jbHVkaW5nIGEgcmFuZG9tIHNlZWQNCmFzIGlucHV0IHRvIHRoZSBoYXNo IHBvbHlub21pYWwpLCB5b3UgY2Fubm90IHJ1bGUgdGhpcyBvdXQgMTAwJS4gUGxlYXNlDQpsb29r IGF0IHRoaXMgZG9jdW1lbnRhdGlvbiBmcm9tIGEgd2VsbCBrbm93biBuZXR3b3JraW5nIGNvbXBh bnkgOy0pPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250 Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHU+PGJyPg0K PC91PjwvZm9udD48YSBocmVmPWh0dHA6Ly93d3cuY2lzY28uY29tL2VuL1VTL2RvY3MvaW9zLzEy XzR0L2lwX21jYXN0L2NvbmZpZ3VyYXRpb24vZ3VpZGUvbWN0bHNwbHQuaHRtbCN3cDEwNjQ1MDE+ PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48dT5odHRwOi8v d3d3LmNpc2NvLmNvbS9lbi9VUy9kb2NzL2lvcy8xMl80dC9pcF9tY2FzdC9jb25maWd1cmF0aW9u L2d1aWRlL21jdGxzcGx0Lmh0bWwjd3AxMDY0NTAxPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0z IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9 IkFyaWFsIj48YnI+DQotLTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFu Ij4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KU3Vubnk8L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDxicj4NCjxicj4NCjxicj4NCjxicj4N CjwvZm9udD48Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJBcmlhbCI+PGJyPg0KRnJv bTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJB cmlhbCI+JnF1b3Q7VGlzc2ENClNlbmV2aXJhdGhuZSAodHNlbmV2aXIpJnF1b3Q7ICZsdDs8L2Zv bnQ+PGEgaHJlZj1tYWlsdG86dHNlbmV2aXJAY2lzY28uY29tPjxmb250IHNpemU9MSBjb2xvcj1i bHVlIGZhY2U9IkFyaWFsIj48dT50c2VuZXZpckBjaXNjby5jb208L3U+PC9mb250PjwvYT48Zm9u dCBzaXplPTEgZmFjZT0iQXJpYWwiPiZndDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0iQXJp YWwiPjxicj4NClRvOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6 ZT0xIGZhY2U9IkFyaWFsIj5EYXZpZCBNDQpCb25kL0JlZGZvcmQvSUJNQElCTVVTPC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGNv bG9yPSM1ZjVmNWYgZmFjZT0iQXJpYWwiPjxicj4NCkNjOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj5Eb25hbGQNCkVhc3RsYWtlICZs dDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86ZDNlM2UzQGdtYWlsLmNvbT48Zm9udCBzaXplPTEgY29s b3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PHU+ZDNlM2UzQGdtYWlsLmNvbTwvdT48L2ZvbnQ+PC9hPjxm b250IHNpemU9MSBmYWNlPSJBcmlhbCI+Jmd0OywNCjwvZm9udD48YSBocmVmPSJtYWlsdG86dHJp bGwtYm91bmNlc0BpZXRmLm9yZyI+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwi Pjx1PnRyaWxsLWJvdW5jZXNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTEgZmFj ZT0iQXJpYWwiPiwNCjwvZm9udD48YSBocmVmPW1haWx0bzp0cmlsbEBpZXRmLm9yZz48Zm9udCBz aXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PHU+dHJpbGxAaWV0Zi5vcmc8L3U+PC9mb250 PjwvYT48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBz aXplPTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJBcmlhbCI+PGJyPg0KRGF0ZTogJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+MDQvMzAvMjAx Mg0KMTI6MjkgUE08L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDwv Zm9udD48Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJBcmlhbCI+PGJyPg0KU3ViamVj dDogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJB cmlhbCI+UmU6DQpbdHJpbGxdIFRSSUxMIE9BTSBSZXF1aXJlbWVudHM6IGF2YWlsYWJsZSBwYXRo czwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9u dCBzaXplPTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJBcmlhbCI+PGJyPg0KU2VudCBieTogJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9mb250PjxhIGhyZWY9Im1haWx0bzp0cmlsbC1ib3VuY2Vz QGlldGYub3JnIj48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PHU+dHJpbGwt Ym91bmNlc0BpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPg0KPC9mb250Pg0KPGRpdiBhbGlnbj1jZW50ZXI+DQo8YnI+DQo8aHIgbm9zaGFk ZT48L2Rpdj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48YnI+DQo8 YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+PGJy Pg0KTGV0IG1lIHN0YXJ0IGZyb20gdGhlIGJhc2ljcy48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFj ZT0iQ2FsaWJyaSI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJy aSI+PGJyPg0KMS4gJm5ic3A7ICZuYnNwOyAmbmJzcDsgVFJJTEwgaXMgYWxsIGFib3V0IG11bHRp cGxlIGFjdGl2ZSBwYXRocy48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+PGJy Pg0KMi4gJm5ic3A7ICZuYnNwOyAmbmJzcDsgTXVsdGlwbGUgYWN0aXZlIHBhdGhzIGFyZSBkZXJp dmVkIGZyb20gbGVhc3QgY29zdA0KcGF0aHMgdG8gYSBzcGVjaWZpYyBkZXN0aW5hdGlvbnMuPC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pjxmb250IHNp emU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPjxicj4NCjMuICZuYnNwOyAmbmJzcDsg Jm5ic3A7IFdlbGwgZGVmaW5lZCBhbmQgaW1wbGVtZW50ZWQgSGFzaGluZyBhbGdvcml0aG1zDQpw cm92aWRlIGFuIGFsbW9zdCBldmVuIGRpc3RyaWJ1dGlvbiBhY3Jvc3MgYWxsIG9mIHRoZSBhdmFp bGFibGUgbGVhc3QgY29zdA0KcGF0aHMgdG8gYSBkZXN0aW5hdGlvbjwvZm9udD48Zm9udCBzaXpl PTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMDA0 MDgwIGZhY2U9IkNhbGlicmkiPjxicj4NCjQuICZuYnNwOyAmbmJzcDsgJm5ic3A7IElmIGEgZ2l2 ZW4gZmxvdyDigJx44oCdIGRvZXMgbm90IG1hcCB0byAmbmJzcDthIHNwZWNpZmljDQpsZWFzdCBj b3N0IHBhdGgsIGRvZXMgbm90IG1hcCB0byBhIHNwZWNpZmljIGxlYXN0IGNvc3QgcGF0aCBkb2Vz IG5vdCBtZWFuDQphbm90aGVyIGZsb3cg4oCceeKAnSB0byB0aGUgc2FtIGRlc3RpbmF0aW9uIHdp bGwgbm90IG1hcCB0byB0aGUgdGhhdCBwYXRoLg0KPGJyPg0KNS4gJm5ic3A7ICZuYnNwOyAmbmJz cDsgV2VsbCBpbXBsZW1lbnRlZCBoYXNoaW5nIGFsZ29yaXRobXMgcHJvdmlkZSBldmVuDQpkaXN0 cmlidXRpb24gb2YgZmxvd3MuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+PGJy Pg0KNi4gJm5ic3A7ICZuYnNwOyAmbmJzcDsgSGVuY2UgaXQgaXMgaW1wb3J0YW50IHRvIGhhdmUg YWJpbGl0eSB0byB0ZXN0IGFsbA0KYXZhaWxhYmxlIGxlYXN0IGNvc3QgcGF0aHMgdG8gYSBkZXN0 aW5hdGlvbi48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2Zv bnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KNy4gJm5i c3A7ICZuYnNwOyAmbmJzcDsgSXQgaXMgYW4gaW1wbGVtZW50YXRpb24gZGVmZWN0LCBJZiB0aGVy ZSBpcyBhbg0KaW1wbGVtZW50YXRpb24gb3V0IHRoZXJlIHdoaWNoIGRvZXMgbm90IGhhc2ggZmxv d3MgKG92ZXIgYSBsb25nZXIgc2FtcGxpbmcNCnBlcmlvZCkgJm5ic3A7aW4gdG8gYSBzcGVjaWZp YyDigJxsZWFzdCBjb3N0IHBhdGjigJ0gb2Ygc2V0IG9mIGxlYXN0IGNvc3QNCnBhdGhzIHRvIGEg ZGVzdGluYXRpb24sIGFtb25nIGFsbCBhdmFpbGFibGUg4oCcbGVhc3QgY29zdCBwYXRoc+KAnSB0 byB0aGF0DQpkZXN0aW5hdGlvbi48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+IDwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj48 YnI+DQogPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwv Zm9udD48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj48Yj48YnI+DQpGcm9tOjwvYj4gRGF2aWQg TSBCb25kIFs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86ZG1ib25kQHVzLmlibS5jb20+PGZvbnQgc2l6 ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVGFob21hIj48dT5tYWlsdG86ZG1ib25kQHVzLmlibS5jb208 L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj5dDQo8Yj48YnI+DQpTZW50 OjwvYj4gTW9uZGF5LCBBcHJpbCAzMCwgMjAxMiA4OjM5IEFNPGI+PGJyPg0KVG86PC9iPiBUaXNz YSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKTxiPjxicj4NCkNjOjwvYj4gRG9uYWxkIEVhc3RsYWtl OyA8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86dHJpbGxAaWV0Zi5vcmc+PGZvbnQgc2l6ZT0yIGNvbG9y PWJsdWUgZmFjZT0iVGFob21hIj48dT50cmlsbEBpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250 IHNpemU9MiBmYWNlPSJUYWhvbWEiPjsNCjwvZm9udD48YSBocmVmPSJtYWlsdG86dHJpbGwtYm91 bmNlc0BpZXRmLm9yZyI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVGFob21hIj48dT50 cmlsbC1ib3VuY2VzQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRh aG9tYSI+PGI+PGJyPg0KU3ViamVjdDo8L2I+IFJlOiBbdHJpbGxdIFRSSUxMIE9BTSBSZXF1aXJl bWVudHM6IGF2YWlsYWJsZSBwYXRoczwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj4NCjxicj4NCiAmbmJzcDs8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTIgZmFjZT0iQXJp YWwiPkp1c3QgYSBxdWVzdGlvbiBjb21pbmcgZnJvbSB0aGlzIGNvbnZlcnNhdGlvbg0KdGhhdCBJ IHdhbnQgdG8gY2xhcmlmeTo8YnI+DQo8YnI+DQpTbyB3ZSBoYXZlICdhbGwgcG9zc2libGUgcGF0 aHMnICgxKSB3aGljaCBjb3VsZCBpbmNsdWRlIG5vbi1sZWFzdCBjb3N0DQpwYXRocyBhbmQgc28g b2YgY291cnNlIHdlIGRvbid0IHdhbnQgdG8gdXNlIHRoaXMgZGVmaW5pdGlvbi48YnI+DQo8YnI+ DQpUaGVuIHdlIGhhdmUgJ2FsbCBlY21wIHBhdGhzJyBvciAnYWxsIGxlYXN0IGNvc3QgcGF0aHMn ICgyKSB3aGljaCBNQVkgaW5jbHVkZQ0KcGF0aHMgbmV2ZXIgY2hvc2VuIGJ5IGEgdHJhbnNpdCBS YnJpZGdlIGJlY2F1c2Ugb2YgdGhlIGxvY2FsIGhhc2hpbmcgY2hvaWNlcy48YnI+DQo8YnI+DQpU aGVuIHdlIGhhdmUgJ2FsbCB0aGUgbGVhc3QgY29zdCBwYXRocyB3aGljaCBtYXkgYmUgY2hvc2Vu IGdpdmVuIHRoZSBoYXNoaW5nDQppbXBsZW1lbnRhdGlvbiBvbiB0aGUgbG9jYWwgUmJyaWRnZXMn ICgzKS48YnI+DQo8YnI+DQpJIHdvbmRlciBpZiBjaG9pY2UgKDIpIGlzIHVzZWZ1bCBvciBkbyB3 ZSBvbmx5IHJlYWxseSBjYXJlIGFib3V0IGNob2ljZQ0KKDMpLiBGb3IgaW5zdGFuY2UsIGlmIHlv dSBoYXZlIDE2IGVxdWFsIGNvc3QgcGF0aHMgZnJvbSBBIHRvIEIgYW5kIHlvdXINCmhhc2hpbmcg b25seSB3aWxsIGV2ZXIgdXNlIDIgb2YgdGhvc2UgcGF0aHMgZG8gd2UgY2FyZSBhYm91dCByZXBv cnRpbmcNCmJhY2sgZWNtcCBwYXRocyB0aGF0IHdpbGwgbmV2ZXIgaW4gcHJhY3RpY2UgYmUgdXNl ZD8gUGVyaGFwcyB0aGUgZGVmaW5pdGlvbg0Kc2hvdWxkIGJlIHRpZ2h0ZW5lZCB0byBvbmx5IHJl cXVpcmUgZGV0ZXJtaW5hdGlvbiBvZiBhbGwgbGVhc3QgY29zdCBwYXRocw0KdGhhdCBjb3VsZCBi ZSB1c2VkIGdpdmVuIHRoZSBsb2NhbCBoYXNoaW5nIGltcGxlbWVudGF0aW9uLiBPciBhbSBJIG1p c3VuZGVyc3RhbmRpbmcNCnRoZSBjb252ZXJzYXRpb24gYW5kIGlzIHRoaXMgYWxyZWFkeSB0aGUg cG9pbnQgYmVpbmcgbWFkZSBiZXR3ZWVuIHRoZW9yZXRpY2FsDQpwYXRocyBhbmQgbGVhc3QgY29z dCBwYXRocy48YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KRGF2aWQ8L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGJyPg0KPGJyPg0KPC9mb250PjxpbWcgc3JjPWNpZDpf MV8wQjhGMTU0MDBCOEYwQ0Q4MDA3MDMzOEQ4ODI1NzlGMCBhbHQ9IkluYWN0aXZlIGhpZGUgZGV0 YWlscyBmb3IgJnF1b3Q7VGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZpcikmcXVvdDsgLS0tMDQv MjkvMjAxMiAxMTo0MzowNyBQTS0tLUkgbGlrZSB0aGF0IERvbmFsZC4uIFdlIGNhbiB1c2UgJnF1 b3Q7YWxsIGxlYXMiPjxmb250IHNpemU9MiBjb2xvcj0jNDI0MjgyIGZhY2U9IkFyaWFsIj4mcXVv dDtUaXNzYQ0KU2VuZXZpcmF0aG5lICh0c2VuZXZpcikmcXVvdDsgLS0tMDQvMjkvMjAxMiAxMTo0 MzowNyBQTS0tLUkgbGlrZSB0aGF0IERvbmFsZC4uDQpXZSBjYW4gdXNlICZxdW90O2FsbCBsZWFz dCBjb3N0IHBhdGhzJnF1b3Q7LCB0aGF0IGlzIHRlY2huaWNhbGx5IG1vcmUgcHJlY2lzZQ0KYW5k IHJlcHJlc2U8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0iQXJpYWwiPjxi cj4NCjxicj4NCkZyb206IDwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPiZxdW90O1Rp c3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpJnF1b3Q7DQombHQ7PC9mb250PjxhIGhyZWY9bWFp bHRvOnRzZW5ldmlyQGNpc2NvLmNvbT48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJBcmlh bCI+PHU+dHNlbmV2aXJAY2lzY28uY29tPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0xIGZhY2U9 IkFyaWFsIj4mZ3Q7PC9mb250Pjxmb250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9IkFyaWFs Ij48YnI+DQpUbzogPC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+JnF1b3Q7RG9uYWxk IEVhc3RsYWtlJnF1b3Q7ICZsdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86ZDNlM2UzQGdtYWlsLmNv bT48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PHU+ZDNlM2UzQGdtYWlsLmNv bTwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+Jmd0OywNCiZsdDs8L2Zv bnQ+PGEgaHJlZj1tYWlsdG86dHJpbGxAaWV0Zi5vcmc+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUg ZmFjZT0iQXJpYWwiPjx1PnRyaWxsQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0x IGZhY2U9IkFyaWFsIj4mZ3Q7PC9mb250Pjxmb250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9 IkFyaWFsIj48YnI+DQpEYXRlOiA8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj4wNC8y OS8yMDEyIDExOjQzIFBNPC9mb250Pjxmb250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9IkFy aWFsIj48YnI+DQpTdWJqZWN0OiA8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj5SZTog W3RyaWxsXSBUUklMTCBPQU0gUmVxdWlyZW1lbnRzOg0KYXZhaWxhYmxlIHBhdGhzPC9mb250Pjxm b250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9IkFyaWFsIj48YnI+DQpTZW50IGJ5OiA8L2Zv bnQ+PGEgaHJlZj0ibWFpbHRvOnRyaWxsLWJvdW5jZXNAaWV0Zi5vcmciPjxmb250IHNpemU9MSBj b2xvcj1ibHVlIGZhY2U9IkFyaWFsIj48dT50cmlsbC1ib3VuY2VzQGlldGYub3JnPC91PjwvZm9u dD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+DQo8ZGl2 IGFsaWduPWNlbnRlcj4NCjxicj4NCjxociBub3NoYWRlPjwvZGl2Pg0KPGJyPjxmb250IHNpemU9 MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxicj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIg ZmFjZT0iQ291cmllciBOZXciPjxicj4NCjxicj4NCkkgbGlrZSB0aGF0IERvbmFsZC4uIFdlIGNh biB1c2UgJnF1b3Q7YWxsIGxlYXN0IGNvc3QgcGF0aHMmcXVvdDssIHRoYXQNCmlzIHRlY2huaWNh bGx5IG1vcmUgcHJlY2lzZSBhbmQgcmVwcmVzZW50IGV4YWN0bHkgd2hhdCBJUy1JUyBkb2VzLjxi cj4NCjxicj4NClRoYW5rczxicj4NClRpc3NhPGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS08YnI+DQpGcm9tOiA8L2ZvbnQ+PGEgaHJlZj0ibWFpbHRvOnRyaWxsLWJvdW5jZXNA aWV0Zi5vcmciPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkNvdXJpZXIgTmV3Ij48dT50 cmlsbC1ib3VuY2VzQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IkNv dXJpZXIgTmV3Ij4NCls8L2ZvbnQ+PGEgaHJlZj0ibWFpbHRvOnRyaWxsLWJvdW5jZXNAaWV0Zi5v cmciPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkNvdXJpZXIgTmV3Ij48dT5tYWlsdG86 dHJpbGwtYm91bmNlc0BpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJD b3VyaWVyIE5ldyI+XQ0KT24gQmVoYWxmIE9mIERvbmFsZCBFYXN0bGFrZTxicj4NClNlbnQ6IFN1 bmRheSwgQXByaWwgMjksIDIwMTIgNjoyNyBQTTxicj4NClRvOiA8L2ZvbnQ+PGEgaHJlZj1tYWls dG86dHJpbGxAaWV0Zi5vcmc+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291cmllciBO ZXciPjx1PnRyaWxsQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IkNv dXJpZXIgTmV3Ij48YnI+DQpTdWJqZWN0OiBSZTogW3RyaWxsXSBUUklMTCBPQU0gUmVxdWlyZW1l bnRzOiBhdmFpbGFibGUgcGF0aHM8YnI+DQo8YnI+DQpJIGRvbid0IHRoaW5rIHRoZSB3b3JkaW5n ICZxdW90O2FsbCBwYXRocyZxdW90OyBzaG91bGQgZXZlciBiZSB1c2VkLiBJZg0KeW91IHRoZSBp dCBsaXRlcmFsbHksIGl0IHdvdWxkIGV2ZW4gaW5jbHVkZSBwYXRocyB0aGF0IGdvIHRocm91Z2gg c29tZQ0KUkJyaWRnZXMgbW9yZSB0aGFuIG9uY2UuPGJyPg0KPGJyPg0KSSBkb24ndCBwYXJ0aWN1 bGFybHkgbGlrZSAmcXVvdDthbGwgRUNNUCBwYXRocyZxdW90OyBlaXRoZXIuIEkgdGhpbmsgdGhl DQpjbGVhcmVzdCB3b3JkaW5nIGlzICZxdW90O2FsbCBsZWFzdCBjb3N0IHBhdGhzJnF1b3Q7IGlm IHlvdSBhcmUgdGFsa2luZw0KYWJvdXQga25vd24gdW5pY2FzdC4gKEFuZCAmcXVvdDthbGwgZGlz dHJpYnV0aW9uIHRyZWUgcGF0aHMmcXVvdDsgaWYgeW91DQp3ZXJlIHRhbGtpbmcgYWJvdXQgbXVs dGktZGVzdGluYXRpb24gZnJhbWVzLik8YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KRG9uYWxkPGJy Pg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQpEb25hbGQgRS4gRWFzdGxha2Ug M3JkICZuYnNwOyArMS01MDgtMzMzLTIyNzAgKGNlbGwpPGJyPg0KMTU1IEJlYXZlciBTdHJlZXQs IE1pbGZvcmQsIE1BIDAxNzU3IFVTQTwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPjx1Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj1tYWlsdG86ZDNl M2UzQGdtYWlsLmNvbT48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIE5ldyI+ PHU+ZDNlM2UzQGdtYWlsLmNvbTwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJDb3Vy aWVyIE5ldyI+PGJyPg0KPGJyPg0KPGJyPg0KT24gU2F0LCBBcHIgMjgsIDIwMTIgYXQgMTE6NDUg UE0sIEVyaWsgTm9yZG1hcmsgJmx0OzwvZm9udD48YSBocmVmPW1haWx0bzpub3JkbWFya0BhY20u b3JnPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkNvdXJpZXIgTmV3Ij48dT5ub3JkbWFy a0BhY20ub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4m Z3Q7DQp3cm90ZTo8YnI+DQomZ3Q7IE9uIDQvMjcvMTIgNToxMiBQTSwgVGlzc2EgU2VuZXZpcmF0 aG5lICh0c2VuZXZpcikgd3JvdGU6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBPZiBjb3Vy c2UgaXQgaXMgcG9zc2libGUuIFRoZSBJUy1JUyB0b3BvbG9neSB0YWJsZSBwcm92aWRlIHRoZQ0K PGJyPg0KJmd0OyZndDsgaW5mb3JtYXRpb24gb24gYWxsIGF2YWlsYWJsZSBFQ01QIHBhdGhzIHRv IGEgc3BlY2lmaWMgZGVzdGluYXRpb24NCjxicj4NCiZndDsmZ3Q7IHdoZW4gdGhlIGVncmVzcyBS QlJpZGdlIG5pY2tuYW1lIGlzIGtub3duLiBUaGF0IGlzIHdoYXQgVFJJTEwNCnVuaWNhc3QgPGJy Pg0KJmd0OyZndDsgZm9yd2FyZGluZyB0YWJsZSBhbGwgYWJvdXQuIE5vdCBzdXJlIHdoeSB5b3Ug YXJlIHNheWluZyBpdCBpcw0Kbm90IDxicj4NCiZndDsmZ3Q7IHBvc3NpYmxlIHRvIGtub3cgYWxs IEVDTVAgcGF0aHMuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFlvdSBhcmUgdGFsa2lu ZyBhYm91dCB3aGF0IFNhbnRvc2ggY2FsbGVkICZxdW90O2FsbCB0aGVvcmV0aWNhbGx5DQphdmFp bGFibGUgPGJyPg0KJmd0OyBwYXRocyZxdW90Oy4gVGhvc2UgY2FuIGJlIGRldGVybWluZWQgZnJv bSBJUy1JUy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBCdXQgdGhlIGRvY3VtZW50IHRhbGtzIGFib3V0 ICZxdW90O2FsbCBhdmFpbGFibGUgcGF0aHMmcXVvdDsgYW5kIEkNCmRvbid0IGtub3cgPGJyPg0K Jmd0OyB3aGF0IHRoYXQgaXMgc3VwcG9zZWQgdG8gbWVhbi4gRG8geW91IGhhdmUgYSBzdWNjaW5j dCBkZWZpbml0aW9uPzxicj4NCiZndDs8YnI+DQomZ3Q7IFdoYXQgaXMgY2xlYXIgdG8gbWUgaXMg dGhhdCB0aGVyZSBjYW4gYmUgYSBzdWJzZXQgb2YgdGhlIHBhdGhzIHRoYXQNCjxicj4NCiZndDsg YXJlIGRldGVybWluZWQgZnJvbSBJUy1JUyB0aGF0IHdvdWxkIG5ldmVyIGJlIHVzZWQsIGJlY2F1 c2Ugbm8gZW50cm9weQ0KPGJyPg0KJmd0OyBpbiBhIHBhY2tldCB3b3VsZCBldmVyeSBwaWNrIHRo YXQgcGF0aC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJcyB0aGUgcmVxdWlyZW1lbnQgaW4gdGhlIGRv Y3VtZW50IHRoYXQgdGhlIE9BTSBzb2x1dGlvbiBzaG91bGQgYmUNCjxicj4NCiZndDsgYWJsZSB0 byB0ZXN0IHRob3NlIHBhdGhzPzxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDsgV2hh dCBwYXRoIGFtb25nIGF2YWlsYWJsZSBwYXRocyB0byBiZSBzZWxlY3RlZCBmb3IgYSBzcGVjaWZp ZWQNCmlzIGEgPGJyPg0KJmd0OyZndDsgbG9jYWwgbWF0dGVyLiBUaGF0IGlzIHdoYXQgYWxsIGFi b3V0IGZsb3cgZW50cm9weSBkaXNjb3ZlcnkuIExpa2UNCkkgPGJyPg0KJmd0OyZndDsgc3RhdGVk IGVhcmxpZXIgaG93IGl0IGlzIGRpc2NvdmVyZWQgaXMgYSBmcmFtZXdvcmsgYW5kIHNvbHV0aW9u DQppc3N1ZS48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgQWdyZWVkLjxicj4NCiZndDs8 YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDsgSWYgeW91IG5lZWQgc29tZSByZWZlcmVuY2UgaG93IGl0 IGlzIGRvbmUgaW4gdGhlIE1QTFMgd29ybGQgUkZDDQo0Mzc5IDxicj4NCiZndDsmZ3Q7IGlzIGEg Z29vZCByZWZlcmVuY2UuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IEFGQUlLIE1QTFMg ZG9lc24ndCBoYXZlIGEgbG9jYWxseSBkZWZpbmVkIEVDTVAgaGFzaCBmdW5jdGlvbiBpbiBldmVy eQ0KaG9wLjxicj4NCiZndDsgVFJJTEwgZG9lcywgd2hpY2ggbWFrZXMgdGhlc2UgYXNwZWN0cyBk aWZmZXJlbnQuPGJyPg0KJmd0Ozxicj4NCiZndDsgUmVnYXJkcyw8YnI+DQomZ3Q7ICZuYnNwOyBF cmlrPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLTxicj4NCiZndDsmZ3Q7IEZyb206IDwvZm9udD48YSBocmVmPSJtYWlsdG86dHJpbGwt Ym91bmNlc0BpZXRmLm9yZyI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291cmllciBO ZXciPjx1PnRyaWxsLWJvdW5jZXNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIg ZmFjZT0iQ291cmllciBOZXciPg0KWzwvZm9udD48YSBocmVmPSJtYWlsdG86dHJpbGwtYm91bmNl c0BpZXRmLm9yZyI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291cmllciBOZXciPjx1 Pm1haWx0bzp0cmlsbC1ib3VuY2VzQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0y IGZhY2U9IkNvdXJpZXIgTmV3Ij5dDQpPbiA8YnI+DQomZ3Q7Jmd0OyBCZWhhbGYgT2YgRXJpayBO b3JkbWFyazxicj4NCiZndDsmZ3Q7IFNlbnQ6IEZyaWRheSwgQXByaWwgMjcsIDIwMTIgNDowNyBQ TTxicj4NCiZndDsmZ3Q7IFRvOiBTYW50b3NoIFJhamFnb3BhbGFuPGJyPg0KJmd0OyZndDsgQ2M6 IDwvZm9udD48YSBocmVmPW1haWx0bzp0cmlsbEBpZXRmLm9yZz48Zm9udCBzaXplPTIgY29sb3I9 Ymx1ZSBmYWNlPSJDb3VyaWVyIE5ldyI+PHU+dHJpbGxAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48 Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCiZndDsmZ3Q7IFN1YmplY3Q6IFJl OiBbdHJpbGxdIFRSSUxMIE9BTSBSZXF1aXJlbWVudHM6IGF2YWlsYWJsZSBwYXRoczxicj4NCiZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgT24gNC8yNy8xMiAyOjE1IFBNLCBTYW50b3NoIFJhamFnb3Bh bGFuIHdyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBJIGFncmVlLCB0 aGUgd29yZGluZyBuZWVkcyB0byBiZSB0aWdodGVuZWQgdG8gc2F5ICZxdW90O2FsbA0KcG9zc2li bGUgZWNtcCA8YnI+DQomZ3Q7Jmd0OyZndDsgcGF0aHMmcXVvdDsgcmF0aGVyIHRoYW4gJnF1b3Q7 YWxsIGF2YWlsYWJsZSBwYXRocyZxdW90Oy4gQW4NCm9wZXJhdG9yIHdvcmtpbmcgb3V0PGJyPg0K Jmd0OyZndDsmZ3Q7IFIxLVIyIGNvbW11bmljYXRpb24gaXMgaW50ZXJlc3RlZCBpbiBhbGwgcG9z c2libGUgcGF0aHMgZGF0YQ0KdHJhZmZpYyA8YnI+DQomZ3Q7Jmd0OyZndDsgY291bGQgdGFrZSBy YXRoZXIgdGhhbiBhbGwgdGhlb3JldGljYWxseSBhdmFpbGFibGUgcGF0aHMuPGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFRoZSBpc3N1ZSBpcyB0aGF0IHRoZXJlIGlz IG5vdGhpbmcgaW4gdGhlIFRSSUxMIGRhdGFwbGFuZSBub3INCklTLUlTIDxicj4NCiZndDsmZ3Q7 IGNvbnRyb2wgcGxhbmUgd2hpY2ggaGVscHMgdGhlIG9wZXJhdG9yIGRldGVybWluZSB0aGF0IHNv bWUgcGF0aHMNCjxicj4NCiZndDsmZ3Q7ICh0aHJvdWdoIFJCMTIxIGFuZCBSQjExMiBpbiB0aGUg ZXhhbXBsZSkgYXJlIG5vdCBwb3NzaWJsZTsgdGhlDQpFQ01QIDxicj4NCiZndDsmZ3Q7IGlucHV0 IGFuZCBoYXNoaW5nIGlzIGEgY29tcGxldGVseSBsb2NhbCBtYXR0ZXIgb24gZWFjaCBSQnJpZGdl Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSXQgaXNuJ3QgdXNlZnVsIHRvIHN0YXRlIGEg cmVxdWlyZW1lbnQgYXJvdW5kIHNvbWV0aGluZyB0aGF0IGNhbid0DQpiZSA8YnI+DQomZ3Q7Jmd0 OyBkZXRlcm1pbmVkLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyBF cmlrPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsgRnJvbTogRXJpayBOb3JkbWFyayZsdDs8L2ZvbnQ+PGEgaHJlZj1tYWls dG86bm9yZG1hcmtAYWNtLm9yZz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJDb3VyaWVy IE5ldyI+PHU+bm9yZG1hcmtAYWNtLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNl PSJDb3VyaWVyIE5ldyI+Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBUbzogPC9mb250PjxhIGhyZWY9 bWFpbHRvOnRyaWxsQGlldGYub3JnPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkNvdXJp ZXIgTmV3Ij48dT50cmlsbEBpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNl PSJDb3VyaWVyIE5ldyI+PGJyPg0KJmd0OyZndDsmZ3Q7IERhdGU6IDA0LzI3LzIwMTIgMDk6NTMg QU08YnI+DQomZ3Q7Jmd0OyZndDsgU3ViamVjdDogW3RyaWxsXSBUUklMTCBPQU0gUmVxdWlyZW1l bnRzOiBhdmFpbGFibGUgcGF0aHMgU2VudA0KYnk6PGJyPg0KJmd0OyZndDsmZ3Q7IDwvZm9udD48 YSBocmVmPSJtYWlsdG86dHJpbGwtYm91bmNlc0BpZXRmLm9yZyI+PGZvbnQgc2l6ZT0yIGNvbG9y PWJsdWUgZmFjZT0iQ291cmllciBOZXciPjx1PnRyaWxsLWJvdW5jZXNAaWV0Zi5vcmc8L3U+PC9m b250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCiZndDsmZ3Q7Jmd0 OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLTxicj4NCiZndDsmZ3Q7Jmd0OyAtLTxicj4NCiZndDsmZ3Q7Jmd0OyAtLTxi cj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBUd28gcmVxdWlyZW1lbnRzIHVzZSB0aGUg d29yZGluZyAmcXVvdDthbGwgYXZhaWxhYmxlIHBhdGhzLiZxdW90Ow0KYW5kICZxdW90O2FsbCA8 YnI+DQomZ3Q7Jmd0OyZndDsgYXZhaWxhYmxlIEVDTVAgcGF0aHMuJnF1b3Q7LCByZXNwZWN0aXZl bHkgYW5kIEknbSBub3Qgc3VyZQ0KSSBrbm93IHdoYXQgPGJyPg0KJmd0OyZndDsmZ3Q7IHRoYXQ8 YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IG1lYW5zLjxicj4N CiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBUYWtlIHRoZSBmb2xsb3dpbmcgZXhhbXBs ZSBwaWN0dXJlOjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBSMTxicj4NCiZn dDsmZ3Q7Jmd0OyAvIFw8YnI+DQomZ3Q7Jmd0OyZndDsgLyBcPGJyPg0KJmd0OyZndDsmZ3Q7IC8g XDxicj4NCiZndDsmZ3Q7Jmd0OyAvIFw8YnI+DQomZ3Q7Jmd0OyZndDsgLyBcPGJyPg0KJmd0OyZn dDsmZ3Q7IFJCMTEgUkIxMjxicj4NCiZndDsmZ3Q7Jmd0OyAvIFwgLyBcPGJyPg0KJmd0OyZndDsm Z3Q7IC8gXCAvIFw8YnI+DQomZ3Q7Jmd0OyZndDsgUkIxMTEgUkIxMTIgUkIxMjEgUkIxMjI8YnI+ DQomZ3Q7Jmd0OyZndDsgXCBcIC8gLzxicj4NCiZndDsmZ3Q7Jmd0OyBcIFwgLyAvPGJyPg0KJmd0 OyZndDsmZ3Q7IFwgXC8gLzxicj4NCiZndDsmZ3Q7Jmd0OyAtLS0tLS1SMi0tLS0tLTxicj4NCiZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBXZSBjYW4gc2VlIHRoYXQgdGhlcmUgYXJlIDQg cGF0aHMgd2l0aCAzIGhvcHMgdG8gZ2V0IGZyb20NClIxIHRvIFIyLCA8YnI+DQomZ3Q7Jmd0OyZn dDsgd2l0aCB0d28gbGF5ZXJzIG9mIEVDTVAgZGVjaXNpb25zLiBCdXQgaG93IG1hbnkgYXZhaWxh YmxlDQpwYXRocyBhcmU8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IHRoZXJlPzxicj4NCiZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBHaXZlbiB0aGF0 IHRoZSBSQnJpZGdlcyBtYWtlIGluZGVwZW5kZW50IEVDTVAgZGVjaXNpb25zLCBhbmQNCmhvdyA8 YnI+DQomZ3Q7Jmd0OyZndDsgdGhleSBkbyB0aGF0IGlzIGEgbG9jYWwgbWF0dGVyLCBpdCBjb3Vs ZCBiZSB0aGUgY2FzZSB0aGF0DQpmb3IgYW55IDxicj4NCiZndDsmZ3Q7Jmd0OyBwYWNrZXQsIGlm IFIxIHBpY2tzIHRoZSBsZWZ0IGxpbmssIHRoZW4gUjExIHdvdWxkIGFsc28gcGljaw0KdGhlIGxl ZnQgPGJyPg0KJmd0OyZndDsmZ3Q7IGxpbms7IGlmPGJyPg0KJmd0OyZndDsmZ3Q7IFIxIHBpY2tz IHRoZSByaWdodCBsaW5rLCB0aGVuIFIxMiBhbHNvIHBpY2tzIHRoZSByaWdodCBsaW5rLjxicj4N CiZndDsmZ3Q7Jmd0OyBUaHVzIHRoZXJlIHdvdWxkIGJlIG5vIHBhY2tldCAoZGF0YSBvciBPQU0p IHRoYXQgd291bGQgY2F1c2UNCnBhY2tldHMgPGJyPg0KJmd0OyZndDsmZ3Q7IGJldHdlZW4gUjEg YW5kIFIyIHRvIHBhc3MgdmlhIFJCMTEyIG9yIFJCMTIxLjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7Jmd0OyBFdmVuIGlmIHdlIGlnbm9yZSB0aGF0IGFzIHVubGlrZWx5LCB0aGVyZSBp cyBzdGlsbCB0aGUgZmFjdA0KdGhhdCBSMSA8YnI+DQomZ3Q7Jmd0OyZndDsgY2FuJ3QgZWFzaWx5 IHRlbGwgaG93IG1hbnkgKHNob3J0ZXN0KSBwYXRocyB0aGVyZSBtaWdodCBiZQ0KYmV0d2VlbiA8 YnI+DQomZ3Q7Jmd0OyZndDsgaXQgYW5kIFIyLiBXaXRoIHNpbmdsZS1sZXZlbCBUUklMTCB0aGUg TFNEQiBjb3VsZCBiZSB1c2VkDQp0byB0ZWxsLCA8YnI+DQomZ3Q7Jmd0OyZndDsgYnV0IGlmPGJy Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyB3ZSBldmVyIGdvIHRv IG11bHRpLWxldmVsIHRoYXQgd291bGRuJ3QgYmUgdGhlIGNhc2UgYW55IG1vcmUuPGJyPg0KJmd0 OyZndDsmZ3Q7IEFuZCBldmVuIGlmIFIxIGtub3dzIHRoYXQgdGhlcmUgYXJlIDQgcG90ZW50aWFs IHBhdGhzLCBpdA0KY2FuJ3QgPGJyPg0KJmd0OyZndDsmZ3Q7IGZvcm1hdDxicj4NCiZndDsmZ3Q7 PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgYSBkYXRhIHBhY2tldCAob3IgZm9ybWF0 IHRoZSBmbG93IGVudHJvcHkgaW4gYW4gT0FNIHBhY2tldCkNCmluIHN1Y2ggPGJyPg0KJmd0OyZn dDsmZ3Q7IGEgd2F5IHRoYXQgcGFydGljdWxhciBwYXRocyBnZXQgY2hvc2VuIGJ5IGRvd25zdHJl YW0gRUNNUA0KZGVjaXNpb25zLjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBU aHVzIGZvciBhbnkgbm90aW9uIG9mICZxdW90O2FsbCBhdmFpbGFibGUgcGF0aHMmcXVvdDsgdGhh dA0KbWFrZSBzZW5zZSB0byBtZSwgPGJyPg0KJmd0OyZndDsmZ3Q7IHdlJ2QgbmVlZCBhbiBPQU0g YXBwcm9hY2ggdGhhdCBjYW4gZXhwbG9yZSB0aGUgdG9wb2xvZ3kgb25lDQpob3AgYXQgYSA8YnI+ DQomZ3Q7Jmd0OyZndDsgdGltZSBhbmQgYXQgZWFjaCBob3AgZXhwbG9yZSBhbGwgdGhlIHBvc3Np YmxlIEVDTVAgY2hvaWNlcy4NClVzaW5nIDxicj4NCiZndDsmZ3Q7Jmd0OyB0aGUgZW50cm9weSBk b2Vzbid0IGhlbHAgd2l0aCB0aGlzIChidXQgdGhlIGVudHJvcHkgaXMgY3JpdGljYWwNCmZvciA8 YnI+DQomZ3Q7Jmd0OyZndDsgZm9sbG93aW5nIHRoZSBwYXRoIHRha2VuIGJ5IGEgcGFydGljdWxh ciBmbG93IG9mIGRhdGEgcGFja2V0cykuPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsm Z3Q7IEhlbmNlIGl0IHdvdWxkIGJlIGdvb2QgdG8gY2xhcmlmeSB3aGF0IHRoZSBhc3N1bXB0aW9u cyBhcmUNCmJlaGluZCA8YnI+DQomZ3Q7Jmd0OyZndDsgdGhpczxicj4NCiZndDsmZ3Q7PGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgbm90aW9uIG9mIGFsbCBhdmFpbGFibGUgcGF0aHMu PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7Jmd0 OyZndDsgRXJpazxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7Jmd0OyB0 cmlsbCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyZndDsgPC9mb250PjxhIGhyZWY9bWFpbHRv OnRyaWxsQGlldGYub3JnPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkNvdXJpZXIgTmV3 Ij48dT50cmlsbEBpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJDb3Vy aWVyIE5ldyI+PGJyPg0KJmd0OyZndDsmZ3Q7IDwvZm9udD48YSBocmVmPWh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJpbGw+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFj ZT0iQ291cmllciBOZXciPjx1Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v dHJpbGw8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4N CiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQom Z3Q7Jmd0OyB0cmlsbCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyA8L2ZvbnQ+PGEgaHJlZj1t YWlsdG86dHJpbGxAaWV0Zi5vcmc+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291cmll ciBOZXciPjx1PnRyaWxsQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9 IkNvdXJpZXIgTmV3Ij48YnI+DQomZ3Q7Jmd0OyA8L2ZvbnQ+PGEgaHJlZj1odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZh Y2U9IkNvdXJpZXIgTmV3Ij48dT5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3RyaWxsPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+ DQomZ3Q7Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyB0cmlsbCBtYWlsaW5nIGxpc3Q8YnI+DQom Z3Q7IDwvZm9udD48YSBocmVmPW1haWx0bzp0cmlsbEBpZXRmLm9yZz48Zm9udCBzaXplPTIgY29s b3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIE5ldyI+PHU+dHJpbGxAaWV0Zi5vcmc8L3U+PC9mb250Pjwv YT48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCiZndDsgPC9mb250PjxhIGhy ZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmlsbD48Zm9udCBzaXpl PTIgY29sb3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIE5ldyI+PHU+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby90cmlsbDwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJD b3VyaWVyIE5ldyI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQp0cmlsbCBtYWlsaW5nIGxpc3Q8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9y PWJsdWUgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48dT48YnI+DQo8L3U+PC9mb250PjxhIGhyZWY9 bWFpbHRvOnRyaWxsQGlldGYub3JnPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkNvdXJp ZXIgTmV3Ij48dT50cmlsbEBpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBjb2xv cj1ibHVlIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHU+PGJyPg0KPC91PjwvZm9udD48YSBocmVm PWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJpbGw+PGZvbnQgc2l6ZT0y IGNvbG9yPWJsdWUgZmFjZT0iQ291cmllciBOZXciPjx1Pmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdHJpbGw8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iQ291 cmllciBOZXciPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KdHJpbGwgbWFpbGluZyBsaXN0PC9mb250Pjxmb250IHNpemU9MyBjb2xvcj1i bHVlIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHU+PGJyPg0KPC91PjwvZm9udD48YSBocmVmPW1h aWx0bzp0cmlsbEBpZXRmLm9yZz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJDb3VyaWVy IE5ldyI+PHU+dHJpbGxAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgY29sb3I9 Ymx1ZSBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjx1Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj1o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsPjxmb250IHNpemU9MiBj b2xvcj1ibHVlIGZhY2U9IkNvdXJpZXIgTmV3Ij48dT5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3RyaWxsPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJp ZXIgTmV3Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCnRyaWxsIG1haWxpbmcgbGlzdDwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9Ymx1 ZSBmYWNlPSJDb3VyaWVyIE5ldyI+PHU+PGJyPg0KPC91PjwvZm9udD48YSBocmVmPW1haWx0bzp0 cmlsbEBpZXRmLm9yZz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIE5ldyI+ PHU+dHJpbGxAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPjx1Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj1odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsPjxmb250IHNpemU9MiBjb2xvcj1i bHVlIGZhY2U9IkNvdXJpZXIgTmV3Ij48dT5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3RyaWxsPC91PjwvZm9udD48L2E+DQo8YnI+DQo= --=_alternative 007034E7882579F0_=-- --=_related 007034E7882579F0_= Content-Type: image/gif Content-ID: <_1_0B8F15400B8F0CD80070338D882579F0> Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --=_related 007034E7882579F0_=-- From tsenevir@cisco.com Mon Apr 30 14:14:06 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 327E921F861C; Mon, 30 Apr 2012 14:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.653 X-Spam-Level: X-Spam-Status: No, score=-7.653 tagged_above=-999 required=5 tests=[AWL=0.525, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42] 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 ZKfNPXJZ1t5a; Mon, 30 Apr 2012 14:14:04 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 3D95821F8603; Mon, 30 Apr 2012 14:14:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tsenevir@cisco.com; l=62686; q=dns/txt; s=iport; t=1335820444; x=1337030044; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=STnzcbNAz0FxEbsxmFoTPiLt71kghycRAoUEW/cm8Bw=; b=h0HPAUFeNED4/LpgIoaaCv++8J7m/LwU+Kk3AnpQXWewz9t+Y06iv2gP BpVg7FwKAJXyeXNp3DnGnXVGFQ4DQwzC1dcL31xK9vFoMLpRHvC62iSdS WyvHItQLrXTEgOMB9n6D3efOxRdKIjnXRe4KwDhtEfvCU5Vq7KWF4WNNX 0=; X-Files: image001.gif : 105 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoEFAIL/nk+rRDoI/2dsb2JhbABBA4JGgk5VqXeBcoEOgQeCCQEBAQQBAQECBwYBBwIHAggBAjQKCwwEAgEGAg4DAwEBAQEFAQICBhABBgECAgIBAQUQAQUEBQEfCQgBAQQSAQYCEweHXQMKAQuaOo0TiRANiVOKDINZghI1YwSIZIQXgyCBd48rgxqBaYMI X-IronPort-AV: E=Sophos;i="4.75,506,1330905600"; d="gif'147?scan'147,208,217,147";a="40281725" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 30 Apr 2012 21:14:03 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3ULE3Yx023811; Mon, 30 Apr 2012 21:14:03 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Apr 2012 14:14:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CD2716.2AF8B942" Date: Mon, 30 Apr 2012 14:14:02 -0700 Message-ID: <344037D7CFEFE84E97E9CC1F56C5F4A5010A3385@xmb-sjc-214.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [trill] TRILL OAM Requirements: available paths Thread-Index: Ac0nD4NAC3EViDrXRbK/RUnBGZl+gQAADZgA References: <4F9ACE0E.7030408@sonic.net> <4F9ACF05.9070302@acm.org><4F9B2697.8080401@acm.org><344037D7CFEFE84E97E9CC1F56C5F4A5010A2FFF@xmb-sjc-214.amer.cisco.com><4F9CB95E.4030902@acm.org><344037D7CFEFE84E97E9CC1F56C5F4A5010A30CC@xmb-sjc-214.amer.cisco.com><344037D7CFEFE84E97E9CC1F56C5F4A5010A32ED@xmb-sjc-214.amer.cisco.com> <344037D7CFEFE84E97E9CC1F56C5F4A5010A332E@xmb-sjc-214.amer.cisco.com> From: "Tissa Senevirathne (tsenevir)" To: "Santosh Rajagopalan" X-OriginalArrivalTime: 30 Apr 2012 21:14:03.0169 (UTC) FILETIME=[2B3B6910:01CD2716] Cc: Donald Eastlake , trill-bounces@ietf.org, David M Bond , trill@ietf.org Subject: Re: [trill] TRILL OAM Requirements: available paths X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 21:14:06 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD2716.2AF8B942 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CD2716.2AF8B942" ------_=_NextPart_002_01CD2716.2AF8B942 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 V2UgYXJlIG5vdyBkaXNjdXNzaW9uIGFib3V0IHN1YiBzdGFuZGFyZCBpbXBsZW1lbnRhdGlvbnMg dGhhdCBnZXQgdG8gc3VjaCBwb2xhcml6YXRpb25zLiAgV2Ugc2hvdWxkIG5vdCB3YXRlciBkb3du IHRoZSByZXF1aXJlbWVudHMgdG8gY2F0ZXIgaW4gc3ViIHN0YW5kYXJkIGltcGxlbWVudGF0aW9u cy4NCg0KIA0KDQpXaGF0IHdlIHNob3VsZCBkbyBpcyB0byBhZGQgYSByZXF1aXJlbWVudHMgc3Vj aCB0aGUgUkJyaWRnZXMgaGF2ZSBhYmlsaXR5IHRvIHByb3ZpZGUgc3RhdGlzdGljYWwgY291bnRz IG9uICBmbG93IGRpc3RyaWJ1dGlvbiBvdmVyIEVDTVAuDQoNCiANCg0KRnJvbTogU2FudG9zaCBS YWphZ29wYWxhbiBbbWFpbHRvOnN1bm55LnJhamFnb3BhbGFuQHVzLmlibS5jb21dIA0KU2VudDog TW9uZGF5LCBBcHJpbCAzMCwgMjAxMiAxOjI1IFBNDQpUbzogVGlzc2EgU2VuZXZpcmF0aG5lICh0 c2VuZXZpcikNCkNjOiBEb25hbGQgRWFzdGxha2U7IERhdmlkIE0gQm9uZDsgdHJpbGxAaWV0Zi5v cmc7IHRyaWxsLWJvdW5jZXNAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbdHJpbGxdIFRSSUxMIE9B TSBSZXF1aXJlbWVudHM6IGF2YWlsYWJsZSBwYXRocw0KDQogDQoNCldoZW4gcG9sYXJpemF0aW9u IHN0cmlrZXMsIGluIHRoZSBleGFtcGxlIGJlbG93LCBhbGwgZmxvd3Mgc3RhcnRpbmcgZnJvbSBS MSB3b3VsZCB1c2UgUkIxMi1SQjEyMiAoYmVjYXVzZSB0aGUgaGFzaCByZXN1bHQgd2FzICIyIiBh dCBSMSBhcyB3ZWxsIGFzIGF0IFJCMTIpLiBObyBmbG93cyBzdGFydGluZyBmcm9tIFIxIHdvdWxk IGV2ZXIgZ28gYWxvbmcgdGhlICBSQjEyLVJCMTIxIHBhdGguIEl0IGlzIGNvbW1vbiB0byBleHBv cnQgYW4gaW50ZXJmYWNlIGZvciB0aGUgdXNlciB0byBjaGFuZ2UgdGhlIHNlZWQgdG8gdGhlIGhh c2ggd2hlbiBzaGUgZGV0ZWN0cyBwb2xhcml6YXRpb24gaGFzIG9jY3VycmVkOiANCg0KaHR0cDov L3d3dy5jaXNjby5jb20vZW4vVVMvcHJvZC9jb2xsYXRlcmFsL3N3aXRjaGVzL3BzOTQ0MS9wczk0 MDIvd2hpdGVfcGFwZXJfYzExLTY4NzU1NC5odG1sI3dwOTAwMDI4NiANCg0KDQoNCg0KRnJvbTog ICAgICAgICJUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKSIgPHRzZW5ldmlyQGNpc2NvLmNv bT4gDQpUbzogICAgICAgIFNhbnRvc2ggUmFqYWdvcGFsYW4vU2FudGEgQ2xhcmEvSUJNQElCTVVT IA0KQ2M6ICAgICAgICAiRG9uYWxkIEVhc3RsYWtlIiA8ZDNlM2UzQGdtYWlsLmNvbT4sIDx0cmls bC1ib3VuY2VzQGlldGYub3JnPiwgRGF2aWQgTSBCb25kL0JlZGZvcmQvSUJNQElCTVVTLCA8dHJp bGxAaWV0Zi5vcmc+IA0KRGF0ZTogICAgICAgIDA0LzMwLzIwMTIgMDE6MTQgUE0gDQpTdWJqZWN0 OiAgICAgICAgUkU6IFt0cmlsbF0gVFJJTEwgT0FNIFJlcXVpcmVtZW50czogYXZhaWxhYmxlIHBh dGhzIA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoNCg0KDQpTdW5ueSAN CiAgDQpBcmUgd2UgdGFsa2luZyBhYm91dCBhIHNpbmdsZSBmbG93IGhlcmUgb3IgbXVsdGlwbGUg Zmxvd3MgPyANCiAgDQogIA0KRnJvbTogdHJpbGwtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnRy aWxsLWJvdW5jZXNAaWV0Zi5vcmcgPG1haWx0bzp0cmlsbC1ib3VuY2VzQGlldGYub3JnPiBdIE9u IEJlaGFsZiBPZiBTYW50b3NoIFJhamFnb3BhbGFuDQpTZW50OiBNb25kYXksIEFwcmlsIDMwLCAy MDEyIDE6MDUgUE0NClRvOiBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKQ0KQ2M6IERvbmFs ZCBFYXN0bGFrZTsgdHJpbGwtYm91bmNlc0BpZXRmLm9yZzsgRGF2aWQgTSBCb25kOyB0cmlsbEBp ZXRmLm9yZw0KU3ViamVjdDogUmU6IFt0cmlsbF0gVFJJTEwgT0FNIFJlcXVpcmVtZW50czogYXZh aWxhYmxlIHBhdGhzIA0KICANClRpc3NhLCANCkhhc2ggcG9sYXJpemF0aW9uIGNhbiByZXN1bHQg aW4gc29tZSBvZiB0aGUgZWNtcCBwYXRocyBiZWluZyB1bnV0aWxpemVkLiBJbiBFcmljJ3MgZXhh bXBsZTogDQoNCg0KICAgICAgICAgICAgICBSMQ0KICAgICAgICAgICAgIC8gIFwNCiAgICAgICAg ICAgIC8gICAgXA0KICAgICAgICAgICAvICAgICAgXA0KICAgICAgICAgIC8gICAgICAgIFwNCiAg ICAgICAgIC8gICAgICAgICAgXA0KICAgICAgUkIxMSAgICAgICAgICBSQjEyDQogICAgICAvICBc ICAgICAgICAgIC8gIFwNCiAgICAgLyAgICBcICAgICAgICAvICAgIFwNCiAgUkIxMTEgIFJCMTEy ICBSQjEyMSAgUkIxMjINCiAgICAgXCAgICAgIFwgICAgLyAgICAgIC8NCiAgICAgIFwgICAgICBc ICAvICAgICAgLw0KICAgICAgIFwgICAgICBcLyAgICAgIC8NCiAgICAgICAgLS0tLS0tUjItLS0t LS0NCg0KSWYgUjEgYW5kIFJCMTIgdXNlIHRoZSBzYW1lIGhhc2ggcG9seW5vbWlhbCAmIHNlZWQs IHRoZW4gKmFsbCogZmxvd3Mgd2hpY2ggYXJyaXZlIGF0IFJCMTIgd2lsbCBnbyBhbG9uZyB0aGUg bGluayB0byBSQjEyMiAtIHRoZSBsaW5rIHRvIFJCMTIxIGZyb20gUkIxMiB3aWxsIG5ldmVyIGJl IHVzZWQuIFRoZSBPQU0gdG9vbCBzaG91bGQgYWxsb3cgdXMgdG8gZmlndXJlIG91dCB0aGlzIGlz IGhhcHBlbmluZywgaW5zdGVhZCBvZiBnaXZpbmcgdXMgcmVkdW5kYW50IGluZm9ybWF0aW9uIGFs cmVhZHkgYXZhaWxhYmxlIGluIElTSVMgbHNkYi4gDQpJIHdvdWxkIGhlc2l0YXRlIHRvIGNhbGwg dGhpcyBhIGRlZmVjdC4gV2hpbGUgaXQgaXMgdHJ1ZSB0aGF0IGEgbG90IG9mIGFzaWNzIGhhdmUg Y291bnRlcm1lYXN1cmVzIGZvciB0aGlzICh1c3VhbGx5IGJ5IGluY2x1ZGluZyBhIHJhbmRvbSBz ZWVkIGFzIGlucHV0IHRvIHRoZSBoYXNoIHBvbHlub21pYWwpLCB5b3UgY2Fubm90IHJ1bGUgdGhp cyBvdXQgMTAwJS4gUGxlYXNlIGxvb2sgYXQgdGhpcyBkb2N1bWVudGF0aW9uIGZyb20gYSB3ZWxs IGtub3duIG5ldHdvcmtpbmcgY29tcGFueSA7LSkgDQpodHRwOi8vd3d3LmNpc2NvLmNvbS9lbi9V Uy9kb2NzL2lvcy8xMl80dC9pcF9tY2FzdC9jb25maWd1cmF0aW9uL2d1aWRlL21jdGxzcGx0Lmh0 bWwjd3AxMDY0NTAxIA0KDQotLSANClN1bm55IA0KDQoNCg0KDQpGcm9tOiAgICAgICAgIlRpc3Nh IFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpIiA8dHNlbmV2aXJAY2lzY28uY29tIDxtYWlsdG86dHNl bmV2aXJAY2lzY28uY29tPiA+IA0KVG86ICAgICAgICBEYXZpZCBNIEJvbmQvQmVkZm9yZC9JQk1A SUJNVVMgDQpDYzogICAgICAgIERvbmFsZCBFYXN0bGFrZSA8ZDNlM2UzQGdtYWlsLmNvbSA8bWFp bHRvOmQzZTNlM0BnbWFpbC5jb20+ID4sIHRyaWxsLWJvdW5jZXNAaWV0Zi5vcmcgPG1haWx0bzp0 cmlsbC1ib3VuY2VzQGlldGYub3JnPiAsIHRyaWxsQGlldGYub3JnIDxtYWlsdG86dHJpbGxAaWV0 Zi5vcmc+ICANCkRhdGU6ICAgICAgICAwNC8zMC8yMDEyIDEyOjI5IFBNIA0KU3ViamVjdDogICAg ICAgIFJlOiBbdHJpbGxdIFRSSUxMIE9BTSBSZXF1aXJlbWVudHM6IGF2YWlsYWJsZSBwYXRocyAN ClNlbnQgYnk6ICAgICAgICB0cmlsbC1ib3VuY2VzQGlldGYub3JnIDxtYWlsdG86dHJpbGwtYm91 bmNlc0BpZXRmLm9yZz4gIA0KDQogDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQoNCg0KDQoNCg0KTGV0IG1lIHN0YXJ0IGZyb20gdGhlIGJhc2ljcy4gDQogDQoxLiAgICAgICBU UklMTCBpcyBhbGwgYWJvdXQgbXVsdGlwbGUgYWN0aXZlIHBhdGhzLiANCjIuICAgICAgIE11bHRp cGxlIGFjdGl2ZSBwYXRocyBhcmUgZGVyaXZlZCBmcm9tIGxlYXN0IGNvc3QgcGF0aHMgdG8gYSBz cGVjaWZpYyBkZXN0aW5hdGlvbnMuIA0KMy4gICAgICAgV2VsbCBkZWZpbmVkIGFuZCBpbXBsZW1l bnRlZCBIYXNoaW5nIGFsZ29yaXRobXMgcHJvdmlkZSBhbiBhbG1vc3QgZXZlbiBkaXN0cmlidXRp b24gYWNyb3NzIGFsbCBvZiB0aGUgYXZhaWxhYmxlIGxlYXN0IGNvc3QgcGF0aHMgdG8gYSBkZXN0 aW5hdGlvbiANCjQuICAgICAgIElmIGEgZ2l2ZW4gZmxvdyDigJx44oCdIGRvZXMgbm90IG1hcCB0 byAgYSBzcGVjaWZpYyBsZWFzdCBjb3N0IHBhdGgsIGRvZXMgbm90IG1hcCB0byBhIHNwZWNpZmlj IGxlYXN0IGNvc3QgcGF0aCBkb2VzIG5vdCBtZWFuIGFub3RoZXIgZmxvdyDigJx54oCdIHRvIHRo ZSBzYW0gZGVzdGluYXRpb24gd2lsbCBub3QgbWFwIHRvIHRoZSB0aGF0IHBhdGguIA0KNS4gICAg ICAgV2VsbCBpbXBsZW1lbnRlZCBoYXNoaW5nIGFsZ29yaXRobXMgcHJvdmlkZSBldmVuIGRpc3Ry aWJ1dGlvbiBvZiBmbG93cy4gDQo2LiAgICAgICBIZW5jZSBpdCBpcyBpbXBvcnRhbnQgdG8gaGF2 ZSBhYmlsaXR5IHRvIHRlc3QgYWxsIGF2YWlsYWJsZSBsZWFzdCBjb3N0IHBhdGhzIHRvIGEgZGVz dGluYXRpb24uIA0KNy4gICAgICAgSXQgaXMgYW4gaW1wbGVtZW50YXRpb24gZGVmZWN0LCBJZiB0 aGVyZSBpcyBhbiBpbXBsZW1lbnRhdGlvbiBvdXQgdGhlcmUgd2hpY2ggZG9lcyBub3QgaGFzaCBm bG93cyAob3ZlciBhIGxvbmdlciBzYW1wbGluZyBwZXJpb2QpICBpbiB0byBhIHNwZWNpZmljIOKA nGxlYXN0IGNvc3QgcGF0aOKAnSBvZiBzZXQgb2YgbGVhc3QgY29zdCBwYXRocyB0byBhIGRlc3Rp bmF0aW9uLCBhbW9uZyBhbGwgYXZhaWxhYmxlIOKAnGxlYXN0IGNvc3QgcGF0aHPigJ0gdG8gdGhh dCBkZXN0aW5hdGlvbi4gDQogDQpGcm9tOiBEYXZpZCBNIEJvbmQgW21haWx0bzpkbWJvbmRAdXMu aWJtLmNvbSA8bWFpbHRvOmRtYm9uZEB1cy5pYm0uY29tPiBdIA0KU2VudDogTW9uZGF5LCBBcHJp bCAzMCwgMjAxMiA4OjM5IEFNDQpUbzogVGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZpcikNCkNj OiBEb25hbGQgRWFzdGxha2U7IHRyaWxsQGlldGYub3JnIDxtYWlsdG86dHJpbGxAaWV0Zi5vcmc+ IDsgdHJpbGwtYm91bmNlc0BpZXRmLm9yZyA8bWFpbHRvOnRyaWxsLWJvdW5jZXNAaWV0Zi5vcmc+ IA0KU3ViamVjdDogUmU6IFt0cmlsbF0gVFJJTEwgT0FNIFJlcXVpcmVtZW50czogYXZhaWxhYmxl IHBhdGhzIA0KICANCg0KSnVzdCBhIHF1ZXN0aW9uIGNvbWluZyBmcm9tIHRoaXMgY29udmVyc2F0 aW9uIHRoYXQgSSB3YW50IHRvIGNsYXJpZnk6DQoNClNvIHdlIGhhdmUgJ2FsbCBwb3NzaWJsZSBw YXRocycgKDEpIHdoaWNoIGNvdWxkIGluY2x1ZGUgbm9uLWxlYXN0IGNvc3QgcGF0aHMgYW5kIHNv IG9mIGNvdXJzZSB3ZSBkb24ndCB3YW50IHRvIHVzZSB0aGlzIGRlZmluaXRpb24uDQoNClRoZW4g d2UgaGF2ZSAnYWxsIGVjbXAgcGF0aHMnIG9yICdhbGwgbGVhc3QgY29zdCBwYXRocycgKDIpIHdo aWNoIE1BWSBpbmNsdWRlIHBhdGhzIG5ldmVyIGNob3NlbiBieSBhIHRyYW5zaXQgUmJyaWRnZSBi ZWNhdXNlIG9mIHRoZSBsb2NhbCBoYXNoaW5nIGNob2ljZXMuDQoNClRoZW4gd2UgaGF2ZSAnYWxs IHRoZSBsZWFzdCBjb3N0IHBhdGhzIHdoaWNoIG1heSBiZSBjaG9zZW4gZ2l2ZW4gdGhlIGhhc2hp bmcgaW1wbGVtZW50YXRpb24gb24gdGhlIGxvY2FsIFJicmlkZ2VzJyAoMykuDQoNCkkgd29uZGVy IGlmIGNob2ljZSAoMikgaXMgdXNlZnVsIG9yIGRvIHdlIG9ubHkgcmVhbGx5IGNhcmUgYWJvdXQg Y2hvaWNlICgzKS4gRm9yIGluc3RhbmNlLCBpZiB5b3UgaGF2ZSAxNiBlcXVhbCBjb3N0IHBhdGhz IGZyb20gQSB0byBCIGFuZCB5b3VyIGhhc2hpbmcgb25seSB3aWxsIGV2ZXIgdXNlIDIgb2YgdGhv c2UgcGF0aHMgZG8gd2UgY2FyZSBhYm91dCByZXBvcnRpbmcgYmFjayBlY21wIHBhdGhzIHRoYXQg d2lsbCBuZXZlciBpbiBwcmFjdGljZSBiZSB1c2VkPyBQZXJoYXBzIHRoZSBkZWZpbml0aW9uIHNo b3VsZCBiZSB0aWdodGVuZWQgdG8gb25seSByZXF1aXJlIGRldGVybWluYXRpb24gb2YgYWxsIGxl YXN0IGNvc3QgcGF0aHMgdGhhdCBjb3VsZCBiZSB1c2VkIGdpdmVuIHRoZSBsb2NhbCBoYXNoaW5n IGltcGxlbWVudGF0aW9uLiBPciBhbSBJIG1pc3VuZGVyc3RhbmRpbmcgdGhlIGNvbnZlcnNhdGlv biBhbmQgaXMgdGhpcyBhbHJlYWR5IHRoZSBwb2ludCBiZWluZyBtYWRlIGJldHdlZW4gdGhlb3Jl dGljYWwgcGF0aHMgYW5kIGxlYXN0IGNvc3QgcGF0aHMuDQoNClRoYW5rcywNCkRhdmlkDQoNCiAi VGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZpcikiIC0tLTA0LzI5LzIwMTIgMTE6NDM6MDcgUE0t LS1JIGxpa2UgdGhhdCBEb25hbGQuLiBXZSBjYW4gdXNlICJhbGwgbGVhc3QgY29zdCBwYXRocyIs IHRoYXQgaXMgdGVjaG5pY2FsbHkgbW9yZSBwcmVjaXNlIGFuZCByZXByZXNlDQoNCkZyb206ICJU aXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKSIgPHRzZW5ldmlyQGNpc2NvLmNvbSA8bWFpbHRv OnRzZW5ldmlyQGNpc2NvLmNvbT4gPg0KVG86ICJEb25hbGQgRWFzdGxha2UiIDxkM2UzZTNAZ21h aWwuY29tIDxtYWlsdG86ZDNlM2UzQGdtYWlsLmNvbT4gPiwgPHRyaWxsQGlldGYub3JnIDxtYWls dG86dHJpbGxAaWV0Zi5vcmc+ID4NCkRhdGU6IDA0LzI5LzIwMTIgMTE6NDMgUE0NClN1YmplY3Q6 IFJlOiBbdHJpbGxdIFRSSUxMIE9BTSBSZXF1aXJlbWVudHM6IGF2YWlsYWJsZSBwYXRocw0KU2Vu dCBieTogdHJpbGwtYm91bmNlc0BpZXRmLm9yZyA8bWFpbHRvOnRyaWxsLWJvdW5jZXNAaWV0Zi5v cmc+ICANCg0KIA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoNCg0KDQoN Cg0KSSBsaWtlIHRoYXQgRG9uYWxkLi4gV2UgY2FuIHVzZSAiYWxsIGxlYXN0IGNvc3QgcGF0aHMi LCB0aGF0IGlzIHRlY2huaWNhbGx5IG1vcmUgcHJlY2lzZSBhbmQgcmVwcmVzZW50IGV4YWN0bHkg d2hhdCBJUy1JUyBkb2VzLg0KDQpUaGFua3MNClRpc3NhDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiB0cmlsbC1ib3VuY2VzQGlldGYub3JnIDxtYWlsdG86dHJpbGwtYm91bmNl c0BpZXRmLm9yZz4gIFttYWlsdG86dHJpbGwtYm91bmNlc0BpZXRmLm9yZyA8bWFpbHRvOnRyaWxs LWJvdW5jZXNAaWV0Zi5vcmc+IF0gT24gQmVoYWxmIE9mIERvbmFsZCBFYXN0bGFrZQ0KU2VudDog U3VuZGF5LCBBcHJpbCAyOSwgMjAxMiA2OjI3IFBNDQpUbzogdHJpbGxAaWV0Zi5vcmcgPG1haWx0 bzp0cmlsbEBpZXRmLm9yZz4gDQpTdWJqZWN0OiBSZTogW3RyaWxsXSBUUklMTCBPQU0gUmVxdWly ZW1lbnRzOiBhdmFpbGFibGUgcGF0aHMNCg0KSSBkb24ndCB0aGluayB0aGUgd29yZGluZyAiYWxs IHBhdGhzIiBzaG91bGQgZXZlciBiZSB1c2VkLiBJZiB5b3UgdGhlIGl0IGxpdGVyYWxseSwgaXQg d291bGQgZXZlbiBpbmNsdWRlIHBhdGhzIHRoYXQgZ28gdGhyb3VnaCBzb21lIFJCcmlkZ2VzIG1v cmUgdGhhbiBvbmNlLg0KDQpJIGRvbid0IHBhcnRpY3VsYXJseSBsaWtlICJhbGwgRUNNUCBwYXRo cyIgZWl0aGVyLiBJIHRoaW5rIHRoZSBjbGVhcmVzdCB3b3JkaW5nIGlzICJhbGwgbGVhc3QgY29z dCBwYXRocyIgaWYgeW91IGFyZSB0YWxraW5nIGFib3V0IGtub3duIHVuaWNhc3QuIChBbmQgImFs bCBkaXN0cmlidXRpb24gdHJlZSBwYXRocyIgaWYgeW91IHdlcmUgdGFsa2luZyBhYm91dCBtdWx0 aS1kZXN0aW5hdGlvbiBmcmFtZXMuKQ0KDQpUaGFua3MsDQpEb25hbGQNCj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09DQpEb25hbGQgRS4gRWFzdGxha2UgM3JkICAgKzEtNTA4LTMzMy0yMjcw IChjZWxsKQ0KMTU1IEJlYXZlciBTdHJlZXQsIE1pbGZvcmQsIE1BIDAxNzU3IFVTQQ0KZDNlM2Uz QGdtYWlsLmNvbSA8bWFpbHRvOmQzZTNlM0BnbWFpbC5jb20+IA0KDQoNCk9uIFNhdCwgQXByIDI4 LCAyMDEyIGF0IDExOjQ1IFBNLCBFcmlrIE5vcmRtYXJrIDxub3JkbWFya0BhY20ub3JnIDxtYWls dG86bm9yZG1hcmtAYWNtLm9yZz4gPiB3cm90ZToNCj4gT24gNC8yNy8xMiA1OjEyIFBNLCBUaXNz YSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKSB3cm90ZToNCj4+DQo+PiBPZiBjb3Vyc2UgaXQgaXMg cG9zc2libGUuIFRoZSBJUy1JUyB0b3BvbG9neSB0YWJsZSBwcm92aWRlIHRoZSANCj4+IGluZm9y bWF0aW9uIG9uIGFsbCBhdmFpbGFibGUgRUNNUCBwYXRocyB0byBhIHNwZWNpZmljIGRlc3RpbmF0 aW9uIA0KPj4gd2hlbiB0aGUgZWdyZXNzIFJCUmlkZ2Ugbmlja25hbWUgaXMga25vd24uIFRoYXQg aXMgd2hhdCBUUklMTCB1bmljYXN0IA0KPj4gZm9yd2FyZGluZyB0YWJsZSBhbGwgYWJvdXQuIE5v dCBzdXJlIHdoeSB5b3UgYXJlIHNheWluZyBpdCBpcyBub3QgDQo+PiBwb3NzaWJsZSB0byBrbm93 IGFsbCBFQ01QIHBhdGhzLg0KPg0KPg0KPiBZb3UgYXJlIHRhbGtpbmcgYWJvdXQgd2hhdCBTYW50 b3NoIGNhbGxlZCAiYWxsIHRoZW9yZXRpY2FsbHkgYXZhaWxhYmxlIA0KPiBwYXRocyIuIFRob3Nl IGNhbiBiZSBkZXRlcm1pbmVkIGZyb20gSVMtSVMuDQo+DQo+IEJ1dCB0aGUgZG9jdW1lbnQgdGFs a3MgYWJvdXQgImFsbCBhdmFpbGFibGUgcGF0aHMiIGFuZCBJIGRvbid0IGtub3cgDQo+IHdoYXQg dGhhdCBpcyBzdXBwb3NlZCB0byBtZWFuLiBEbyB5b3UgaGF2ZSBhIHN1Y2NpbmN0IGRlZmluaXRp b24/DQo+DQo+IFdoYXQgaXMgY2xlYXIgdG8gbWUgaXMgdGhhdCB0aGVyZSBjYW4gYmUgYSBzdWJz ZXQgb2YgdGhlIHBhdGhzIHRoYXQgDQo+IGFyZSBkZXRlcm1pbmVkIGZyb20gSVMtSVMgdGhhdCB3 b3VsZCBuZXZlciBiZSB1c2VkLCBiZWNhdXNlIG5vIGVudHJvcHkgDQo+IGluIGEgcGFja2V0IHdv dWxkIGV2ZXJ5IHBpY2sgdGhhdCBwYXRoLg0KPg0KPiBJcyB0aGUgcmVxdWlyZW1lbnQgaW4gdGhl IGRvY3VtZW50IHRoYXQgdGhlIE9BTSBzb2x1dGlvbiBzaG91bGQgYmUgDQo+IGFibGUgdG8gdGVz dCB0aG9zZSBwYXRocz8NCj4NCj4NCj4+IFdoYXQgcGF0aCBhbW9uZyBhdmFpbGFibGUgcGF0aHMg dG8gYmUgc2VsZWN0ZWQgZm9yIGEgc3BlY2lmaWVkIGlzIGEgDQo+PiBsb2NhbCBtYXR0ZXIuIFRo YXQgaXMgd2hhdCBhbGwgYWJvdXQgZmxvdyBlbnRyb3B5IGRpc2NvdmVyeS4gTGlrZSBJIA0KPj4g c3RhdGVkIGVhcmxpZXIgaG93IGl0IGlzIGRpc2NvdmVyZWQgaXMgYSBmcmFtZXdvcmsgYW5kIHNv bHV0aW9uIGlzc3VlLg0KPg0KPg0KPiBBZ3JlZWQuDQo+DQo+DQo+PiBJZiB5b3UgbmVlZCBzb21l IHJlZmVyZW5jZSBob3cgaXQgaXMgZG9uZSBpbiB0aGUgTVBMUyB3b3JsZCBSRkMgNDM3OSANCj4+ IGlzIGEgZ29vZCByZWZlcmVuY2UuDQo+DQo+DQo+IEFGQUlLIE1QTFMgZG9lc24ndCBoYXZlIGEg bG9jYWxseSBkZWZpbmVkIEVDTVAgaGFzaCBmdW5jdGlvbiBpbiBldmVyeSBob3AuDQo+IFRSSUxM IGRvZXMsIHdoaWNoIG1ha2VzIHRoZXNlIGFzcGVjdHMgZGlmZmVyZW50Lg0KPg0KPiBSZWdhcmRz LA0KPiAgIEVyaWsNCj4NCj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9t OiB0cmlsbC1ib3VuY2VzQGlldGYub3JnIDxtYWlsdG86dHJpbGwtYm91bmNlc0BpZXRmLm9yZz4g IFttYWlsdG86dHJpbGwtYm91bmNlc0BpZXRmLm9yZyA8bWFpbHRvOnRyaWxsLWJvdW5jZXNAaWV0 Zi5vcmc+IF0gT24gDQo+PiBCZWhhbGYgT2YgRXJpayBOb3JkbWFyaw0KPj4gU2VudDogRnJpZGF5 LCBBcHJpbCAyNywgMjAxMiA0OjA3IFBNDQo+PiBUbzogU2FudG9zaCBSYWphZ29wYWxhbg0KPj4g Q2M6IHRyaWxsQGlldGYub3JnIDxtYWlsdG86dHJpbGxAaWV0Zi5vcmc+IA0KPj4gU3ViamVjdDog UmU6IFt0cmlsbF0gVFJJTEwgT0FNIFJlcXVpcmVtZW50czogYXZhaWxhYmxlIHBhdGhzDQo+Pg0K Pj4gT24gNC8yNy8xMiAyOjE1IFBNLCBTYW50b3NoIFJhamFnb3BhbGFuIHdyb3RlOg0KPj4+DQo+ Pj4gSSBhZ3JlZSwgdGhlIHdvcmRpbmcgbmVlZHMgdG8gYmUgdGlnaHRlbmVkIHRvIHNheSAiYWxs IHBvc3NpYmxlIGVjbXAgDQo+Pj4gcGF0aHMiIHJhdGhlciB0aGFuICJhbGwgYXZhaWxhYmxlIHBh dGhzIi4gQW4gb3BlcmF0b3Igd29ya2luZyBvdXQNCj4+PiBSMS1SMiBjb21tdW5pY2F0aW9uIGlz IGludGVyZXN0ZWQgaW4gYWxsIHBvc3NpYmxlIHBhdGhzIGRhdGEgdHJhZmZpYyANCj4+PiBjb3Vs ZCB0YWtlIHJhdGhlciB0aGFuIGFsbCB0aGVvcmV0aWNhbGx5IGF2YWlsYWJsZSBwYXRocy4NCj4+ DQo+Pg0KPj4gVGhlIGlzc3VlIGlzIHRoYXQgdGhlcmUgaXMgbm90aGluZyBpbiB0aGUgVFJJTEwg ZGF0YXBsYW5lIG5vciBJUy1JUyANCj4+IGNvbnRyb2wgcGxhbmUgd2hpY2ggaGVscHMgdGhlIG9w ZXJhdG9yIGRldGVybWluZSB0aGF0IHNvbWUgcGF0aHMgDQo+PiAodGhyb3VnaCBSQjEyMSBhbmQg UkIxMTIgaW4gdGhlIGV4YW1wbGUpIGFyZSBub3QgcG9zc2libGU7IHRoZSBFQ01QIA0KPj4gaW5w dXQgYW5kIGhhc2hpbmcgaXMgYSBjb21wbGV0ZWx5IGxvY2FsIG1hdHRlciBvbiBlYWNoIFJCcmlk Z2UuDQo+Pg0KPj4gSXQgaXNuJ3QgdXNlZnVsIHRvIHN0YXRlIGEgcmVxdWlyZW1lbnQgYXJvdW5k IHNvbWV0aGluZyB0aGF0IGNhbid0IGJlIA0KPj4gZGV0ZXJtaW5lZC4NCj4+DQo+PiAgICAgRXJp aw0KPj4NCj4+Pg0KPj4+DQo+Pj4gRnJvbTogRXJpayBOb3JkbWFyazxub3JkbWFya0BhY20ub3Jn IDxtYWlsdG86bm9yZG1hcmtAYWNtLm9yZz4gPg0KPj4+IFRvOiB0cmlsbEBpZXRmLm9yZyA8bWFp bHRvOnRyaWxsQGlldGYub3JnPiANCj4+PiBEYXRlOiAwNC8yNy8yMDEyIDA5OjUzIEFNDQo+Pj4g U3ViamVjdDogW3RyaWxsXSBUUklMTCBPQU0gUmVxdWlyZW1lbnRzOiBhdmFpbGFibGUgcGF0aHMg U2VudCBieToNCj4+PiB0cmlsbC1ib3VuY2VzQGlldGYub3JnIDxtYWlsdG86dHJpbGwtYm91bmNl c0BpZXRmLm9yZz4gDQo+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+PiAtLQ0KPj4+IC0tDQo+Pj4NCj4+Pg0K Pj4+DQo+Pj4NCj4+PiBUd28gcmVxdWlyZW1lbnRzIHVzZSB0aGUgd29yZGluZyAiYWxsIGF2YWls YWJsZSBwYXRocy4iIGFuZCAiYWxsIA0KPj4+IGF2YWlsYWJsZSBFQ01QIHBhdGhzLiIsIHJlc3Bl Y3RpdmVseSBhbmQgSSdtIG5vdCBzdXJlIEkga25vdyB3aGF0IA0KPj4+IHRoYXQNCj4+DQo+Pg0K Pj4+IG1lYW5zLg0KPj4+DQo+Pj4gVGFrZSB0aGUgZm9sbG93aW5nIGV4YW1wbGUgcGljdHVyZToN Cj4+Pg0KPj4+IFIxDQo+Pj4gLyBcDQo+Pj4gLyBcDQo+Pj4gLyBcDQo+Pj4gLyBcDQo+Pj4gLyBc DQo+Pj4gUkIxMSBSQjEyDQo+Pj4gLyBcIC8gXA0KPj4+IC8gXCAvIFwNCj4+PiBSQjExMSBSQjEx MiBSQjEyMSBSQjEyMg0KPj4+IFwgXCAvIC8NCj4+PiBcIFwgLyAvDQo+Pj4gXCBcLyAvDQo+Pj4g LS0tLS0tUjItLS0tLS0NCj4+Pg0KPj4+IFdlIGNhbiBzZWUgdGhhdCB0aGVyZSBhcmUgNCBwYXRo cyB3aXRoIDMgaG9wcyB0byBnZXQgZnJvbSBSMSB0byBSMiwgDQo+Pj4gd2l0aCB0d28gbGF5ZXJz IG9mIEVDTVAgZGVjaXNpb25zLiBCdXQgaG93IG1hbnkgYXZhaWxhYmxlIHBhdGhzIGFyZQ0KPj4N Cj4+IHRoZXJlPw0KPj4+DQo+Pj4NCj4+PiBHaXZlbiB0aGF0IHRoZSBSQnJpZGdlcyBtYWtlIGlu ZGVwZW5kZW50IEVDTVAgZGVjaXNpb25zLCBhbmQgaG93IA0KPj4+IHRoZXkgZG8gdGhhdCBpcyBh IGxvY2FsIG1hdHRlciwgaXQgY291bGQgYmUgdGhlIGNhc2UgdGhhdCBmb3IgYW55IA0KPj4+IHBh Y2tldCwgaWYgUjEgcGlja3MgdGhlIGxlZnQgbGluaywgdGhlbiBSMTEgd291bGQgYWxzbyBwaWNr IHRoZSBsZWZ0IA0KPj4+IGxpbms7IGlmDQo+Pj4gUjEgcGlja3MgdGhlIHJpZ2h0IGxpbmssIHRo ZW4gUjEyIGFsc28gcGlja3MgdGhlIHJpZ2h0IGxpbmsuDQo+Pj4gVGh1cyB0aGVyZSB3b3VsZCBi ZSBubyBwYWNrZXQgKGRhdGEgb3IgT0FNKSB0aGF0IHdvdWxkIGNhdXNlIHBhY2tldHMgDQo+Pj4g YmV0d2VlbiBSMSBhbmQgUjIgdG8gcGFzcyB2aWEgUkIxMTIgb3IgUkIxMjEuDQo+Pj4NCj4+PiBF dmVuIGlmIHdlIGlnbm9yZSB0aGF0IGFzIHVubGlrZWx5LCB0aGVyZSBpcyBzdGlsbCB0aGUgZmFj dCB0aGF0IFIxIA0KPj4+IGNhbid0IGVhc2lseSB0ZWxsIGhvdyBtYW55IChzaG9ydGVzdCkgcGF0 aHMgdGhlcmUgbWlnaHQgYmUgYmV0d2VlbiANCj4+PiBpdCBhbmQgUjIuIFdpdGggc2luZ2xlLWxl dmVsIFRSSUxMIHRoZSBMU0RCIGNvdWxkIGJlIHVzZWQgdG8gdGVsbCwgDQo+Pj4gYnV0IGlmDQo+ Pg0KPj4NCj4+PiB3ZSBldmVyIGdvIHRvIG11bHRpLWxldmVsIHRoYXQgd291bGRuJ3QgYmUgdGhl IGNhc2UgYW55IG1vcmUuDQo+Pj4gQW5kIGV2ZW4gaWYgUjEga25vd3MgdGhhdCB0aGVyZSBhcmUg NCBwb3RlbnRpYWwgcGF0aHMsIGl0IGNhbid0IA0KPj4+IGZvcm1hdA0KPj4NCj4+DQo+Pj4gYSBk YXRhIHBhY2tldCAob3IgZm9ybWF0IHRoZSBmbG93IGVudHJvcHkgaW4gYW4gT0FNIHBhY2tldCkg aW4gc3VjaCANCj4+PiBhIHdheSB0aGF0IHBhcnRpY3VsYXIgcGF0aHMgZ2V0IGNob3NlbiBieSBk b3duc3RyZWFtIEVDTVAgZGVjaXNpb25zLg0KPj4+DQo+Pj4gVGh1cyBmb3IgYW55IG5vdGlvbiBv ZiAiYWxsIGF2YWlsYWJsZSBwYXRocyIgdGhhdCBtYWtlIHNlbnNlIHRvIG1lLCANCj4+PiB3ZSdk IG5lZWQgYW4gT0FNIGFwcHJvYWNoIHRoYXQgY2FuIGV4cGxvcmUgdGhlIHRvcG9sb2d5IG9uZSBo b3AgYXQgYSANCj4+PiB0aW1lIGFuZCBhdCBlYWNoIGhvcCBleHBsb3JlIGFsbCB0aGUgcG9zc2li bGUgRUNNUCBjaG9pY2VzLiBVc2luZyANCj4+PiB0aGUgZW50cm9weSBkb2Vzbid0IGhlbHAgd2l0 aCB0aGlzIChidXQgdGhlIGVudHJvcHkgaXMgY3JpdGljYWwgZm9yIA0KPj4+IGZvbGxvd2luZyB0 aGUgcGF0aCB0YWtlbiBieSBhIHBhcnRpY3VsYXIgZmxvdyBvZiBkYXRhIHBhY2tldHMpLg0KPj4+ DQo+Pj4gSGVuY2UgaXQgd291bGQgYmUgZ29vZCB0byBjbGFyaWZ5IHdoYXQgdGhlIGFzc3VtcHRp b25zIGFyZSBiZWhpbmQgDQo+Pj4gdGhpcw0KPj4NCj4+DQo+Pj4gbm90aW9uIG9mIGFsbCBhdmFp bGFibGUgcGF0aHMuDQo+Pj4NCj4+PiBUaGFua3MsDQo+Pj4gRXJpaw0KPj4+DQo+Pj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiB0cmlsbCBtYWls aW5nIGxpc3QNCj4+PiB0cmlsbEBpZXRmLm9yZyA8bWFpbHRvOnRyaWxsQGlldGYub3JnPiANCj4+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsIDxodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsPiANCj4+Pg0KPj4+DQo+Pg0KPj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IHRyaWxsIG1h aWxpbmcgbGlzdA0KPj4gdHJpbGxAaWV0Zi5vcmcgPG1haWx0bzp0cmlsbEBpZXRmLm9yZz4gDQo+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsIDxodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsPiANCj4+DQo+DQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHRyaWxsIG1haWxpbmcgbGlz dA0KPiB0cmlsbEBpZXRmLm9yZyA8bWFpbHRvOnRyaWxsQGlldGYub3JnPiANCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmlsbCA8aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby90cmlsbD4gDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KdHJpbGwgbWFpbGluZyBsaXN0DQp0cmlsbEBpZXRmLm9yZyA8bWFp bHRvOnRyaWxsQGlldGYub3JnPiANCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vdHJpbGwgPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJpbGw+IA0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnRyaWxsIG1h aWxpbmcgbGlzdA0KdHJpbGxAaWV0Zi5vcmcgPG1haWx0bzp0cmlsbEBpZXRmLm9yZz4gDQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsIDxodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsPiANCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQp0cmlsbCBtYWlsaW5nIGxpc3QNCnRyaWxsQGlldGYub3Jn IDxtYWlsdG86dHJpbGxAaWV0Zi5vcmc+IA0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby90cmlsbCA8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmls bD4gIA0KDQo= ------_=_NextPart_002_01CD2716.2AF8B942 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIg MTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCglt YXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1s ZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iLCJzZXJpZiI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0 ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4 dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1h aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkJhbGxvb25U ZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJs dWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPldlIGFyZSBub3cgZGlzY3Vzc2lvbiBhYm91dCBzdWIg c3RhbmRhcmQgaW1wbGVtZW50YXRpb25zIHRoYXQgZ2V0IHRvIHN1Y2ggcG9sYXJpemF0aW9ucy4g wqBXZSBzaG91bGQgbm90IHdhdGVyIGRvd24gdGhlIHJlcXVpcmVtZW50cyB0byBjYXRlciBpbiBz dWIgc3RhbmRhcmQgaW1wbGVtZW50YXRpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+V2hhdCB3ZSBz aG91bGQgZG8gaXMgdG8gYWRkIGEgcmVxdWlyZW1lbnRzIHN1Y2ggdGhlIFJCcmlkZ2VzIGhhdmUg YWJpbGl0eSB0byBwcm92aWRlIHN0YXRpc3RpY2FsIGNvdW50cyBvbiDCoGZsb3cgZGlzdHJpYnV0 aW9uIG92ZXIgRUNNUC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYgc3R5 bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiJz4gU2FudG9zaCBSYWphZ29wYWxhbiBbbWFpbHRvOnN1bm55LnJhamFnb3Bh bGFuQHVzLmlibS5jb21dIDxicj48Yj5TZW50OjwvYj4gTW9uZGF5LCBBcHJpbCAzMCwgMjAxMiAx OjI1IFBNPGJyPjxiPlRvOjwvYj4gVGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZpcik8YnI+PGI+ Q2M6PC9iPiBEb25hbGQgRWFzdGxha2U7IERhdmlkIE0gQm9uZDsgdHJpbGxAaWV0Zi5vcmc7IHRy aWxsLWJvdW5jZXNAaWV0Zi5vcmc8YnI+PGI+U3ViamVjdDo8L2I+IFJFOiBbdHJpbGxdIFRSSUxM IE9BTSBSZXF1aXJlbWVudHM6IGF2YWlsYWJsZSBwYXRoczxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIs InNhbnMtc2VyaWYiJz5XaGVuIHBvbGFyaXphdGlvbiBzdHJpa2VzLCBpbiB0aGUgZXhhbXBsZSBi ZWxvdywgYWxsIGZsb3dzIHN0YXJ0aW5nIGZyb20gUjEgd291bGQgdXNlIFJCMTItUkIxMjIgKGJl Y2F1c2UgdGhlIGhhc2ggcmVzdWx0IHdhcyAmcXVvdDsyJnF1b3Q7IGF0IFIxIGFzIHdlbGwgYXMg YXQgUkIxMikuIE5vIGZsb3dzIHN0YXJ0aW5nIGZyb20gUjEgd291bGQgZXZlciBnbyBhbG9uZyB0 aGUgJm5ic3A7UkIxMi1SQjEyMSBwYXRoLiBJdCBpcyBjb21tb24gdG8gZXhwb3J0IGFuIGludGVy ZmFjZSBmb3IgdGhlIHVzZXIgdG8gY2hhbmdlIHRoZSBzZWVkIHRvIHRoZSBoYXNoIHdoZW4gc2hl IGRldGVjdHMgcG9sYXJpemF0aW9uIGhhcyBvY2N1cnJlZDo8L3NwYW4+IDxicj48YnI+PGEgaHJl Zj0iaHR0cDovL3d3dy5jaXNjby5jb20vZW4vVVMvcHJvZC9jb2xsYXRlcmFsL3N3aXRjaGVzL3Bz OTQ0MS9wczk0MDIvd2hpdGVfcGFwZXJfYzExLTY4NzU1NC5odG1sI3dwOTAwMDI4NiI+aHR0cDov L3d3dy5jaXNjby5jb20vZW4vVVMvcHJvZC9jb2xsYXRlcmFsL3N3aXRjaGVzL3BzOTQ0MS9wczk0 MDIvd2hpdGVfcGFwZXJfYzExLTY4NzU1NC5odG1sI3dwOTAwMDI4NjwvYT4gPGJyPjxicj48YnI+ PGJyPjxicj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIs InNhbnMtc2VyaWYiO2NvbG9yOiM1RjVGNUYnPkZyb206ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlh bCIsInNhbnMtc2VyaWYiJz4mcXVvdDtUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKSZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRzZW5ldmlyQGNpc2NvLmNvbSI+dHNlbmV2aXJAY2lzY28u Y29tPC9hPiZndDs8L3NwYW4+IDxicj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuNXB0O2ZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiM1RjVGNUYnPlRvOiAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250 LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+U2FudG9zaCBSYWphZ29wYWxhbi9TYW50YSBD bGFyYS9JQk1ASUJNVVM8L3NwYW4+IDxicj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuNXB0O2Zv bnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiM1RjVGNUYnPkNjOiAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtm b250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+JnF1b3Q7RG9uYWxkIEVhc3RsYWtlJnF1 b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86ZDNlM2UzQGdtYWlsLmNvbSI+ZDNlM2UzQGdtYWlsLmNv bTwvYT4mZ3Q7LCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRyaWxsLWJvdW5jZXNAaWV0Zi5vcmciPnRy aWxsLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OywgRGF2aWQgTSBCb25kL0JlZGZvcmQvSUJNQElC TVVTLCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRyaWxsQGlldGYub3JnIj50cmlsbEBpZXRmLm9yZzwv YT4mZ3Q7PC9zcGFuPiA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWls eToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojNUY1RjVGJz5EYXRlOiAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZh bWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+MDQvMzAvMjAxMiAwMToxNCBQTTwvc3Bhbj4gPGJy PjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzVGNUY1Ric+U3ViamVjdDogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwi c2Fucy1zZXJpZiInPlJFOiBbdHJpbGxdIFRSSUxMIE9BTSBSZXF1aXJlbWVudHM6IGF2YWlsYWJs ZSBwYXRoczwvc3Bhbj4gPG86cD48L286cD48L3A+PGRpdiBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249 Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+PGhyIHNpemU9MiB3aWR0aD0iMTAwJSIg bm9zaGFkZSBzdHlsZT0nY29sb3I6I0EwQTBBMCcgYWxpZ249Y2VudGVyPjwvZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48YnI+PGJyPjxicj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMwMDQwODAnPlN1bm55PC9zcGFu PiA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMDA0MDgwJz4mbmJzcDs8L3NwYW4+IDxicj48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMwMDQwODAnPkFyZSB3ZSB0YWxraW5nIGFib3V0IGEgc2luZ2xlIGZsb3cgaGVyZSBvciBt dWx0aXBsZSBmbG93cyA/PC9zcGFuPiA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMDA0MDgwJz4mbmJzcDs8 L3NwYW4+IDxicj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMwMDQwODAnPiZuYnNwOzwvc3Bhbj4gPGJyPjxiPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl cmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IDxhIGhyZWY9Im1haWx0bzp0cmlsbC1ib3Vu Y2VzQGlldGYub3JnIj50cmlsbC1ib3VuY2VzQGlldGYub3JnPC9hPiBbPC9zcGFuPjxhIGhyZWY9 Im1haWx0bzp0cmlsbC1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPm1haWx0bzp0cmlsbC1ib3Vu Y2VzQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPl0gPGI+T24gQmVoYWxmIE9mIDwvYj5TYW50 b3NoIFJhamFnb3BhbGFuPGI+PGJyPlNlbnQ6PC9iPiBNb25kYXksIEFwcmlsIDMwLCAyMDEyIDE6 MDUgUE08Yj48YnI+VG86PC9iPiBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKTxiPjxicj5D Yzo8L2I+IERvbmFsZCBFYXN0bGFrZTsgPGEgaHJlZj0ibWFpbHRvOnRyaWxsLWJvdW5jZXNAaWV0 Zi5vcmciPnRyaWxsLWJvdW5jZXNAaWV0Zi5vcmc8L2E+OyBEYXZpZCBNIEJvbmQ7IDxhIGhyZWY9 Im1haWx0bzp0cmlsbEBpZXRmLm9yZyI+dHJpbGxAaWV0Zi5vcmc8L2E+PGI+PGJyPlN1YmplY3Q6 PC9iPiBSZTogW3RyaWxsXSBUUklMTCBPQU0gUmVxdWlyZW1lbnRzOiBhdmFpbGFibGUgcGF0aHM8 L3NwYW4+IDxicj4mbmJzcDsgPGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5UaXNzYSw8L3NwYW4+IDxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz48YnI+SGFz aCBwb2xhcml6YXRpb24gY2FuIHJlc3VsdCBpbiBzb21lIG9mIHRoZSBlY21wIHBhdGhzIGJlaW5n IHVudXRpbGl6ZWQuIEluIEVyaWMncyBleGFtcGxlOjwvc3Bhbj4gPHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PGJyPjxicj48YnI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFIxPGJyPiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy8gJm5ic3A7XDxicj4mbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAvICZuYnNwOyAmbmJzcDtcPGJy PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7LyAmbmJzcDsgJm5ic3A7 ICZuYnNwO1w8YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAvICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO1w8YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw Oy8gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1w8YnI+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgUkIxMSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7UkIxMjxicj4mbmJz cDsgJm5ic3A7ICZuYnNwOyAvICZuYnNwO1wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOy8gJm5ic3A7XDxicj4mbmJzcDsgJm5ic3A7ICZuYnNwOy8gJm5ic3A7ICZuYnNwO1wgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7LyAmbmJzcDsgJm5ic3A7XDxicj4mbmJzcDsgUkIxMTEg Jm5ic3A7UkIxMTIgJm5ic3A7UkIxMjEgJm5ic3A7UkIxMjI8YnI+Jm5ic3A7ICZuYnNwOyAmbmJz cDtcICZuYnNwOyAmbmJzcDsgJm5ic3A7XCAmbmJzcDsgJm5ic3A7LyAmbmJzcDsgJm5ic3A7ICZu YnNwOy88YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgXCAmbmJzcDsgJm5ic3A7ICZuYnNwO1wgJm5i c3A7LyAmbmJzcDsgJm5ic3A7ICZuYnNwOy88YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 XCAmbmJzcDsgJm5ic3A7ICZuYnNwO1wvICZuYnNwOyAmbmJzcDsgJm5ic3A7Lzxicj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgLS0tLS0tUjItLS0tLS08L3NwYW4+PGJyPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz48YnI+ SWYgUjEgYW5kIFJCMTIgdXNlIHRoZSBzYW1lIGhhc2ggcG9seW5vbWlhbCAmYW1wOyBzZWVkLCB0 aGVuICphbGwqIGZsb3dzIHdoaWNoIGFycml2ZSBhdCBSQjEyIHdpbGwgZ28gYWxvbmcgdGhlIGxp bmsgdG8gUkIxMjIgLSB0aGUgbGluayB0byBSQjEyMSBmcm9tIFJCMTIgd2lsbCBuZXZlciBiZSB1 c2VkLiBUaGUgT0FNIHRvb2wgc2hvdWxkIGFsbG93IHVzIHRvIGZpZ3VyZSBvdXQgdGhpcyBpcyBo YXBwZW5pbmcsIGluc3RlYWQgb2YgZ2l2aW5nIHVzIHJlZHVuZGFudCBpbmZvcm1hdGlvbiBhbHJl YWR5IGF2YWlsYWJsZSBpbiBJU0lTIGxzZGIuPC9zcGFuPiA8c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+PGJyPkkgd291bGQgaGVz aXRhdGUgdG8gY2FsbCB0aGlzIGEgZGVmZWN0LiBXaGlsZSBpdCBpcyB0cnVlIHRoYXQgYSBsb3Qg b2YgYXNpY3MgaGF2ZSBjb3VudGVybWVhc3VyZXMgZm9yIHRoaXMgKHVzdWFsbHkgYnkgaW5jbHVk aW5nIGEgcmFuZG9tIHNlZWQgYXMgaW5wdXQgdG8gdGhlIGhhc2ggcG9seW5vbWlhbCksIHlvdSBj YW5ub3QgcnVsZSB0aGlzIG91dCAxMDAlLiBQbGVhc2UgbG9vayBhdCB0aGlzIGRvY3VtZW50YXRp b24gZnJvbSBhIHdlbGwga25vd24gbmV0d29ya2luZyBjb21wYW55IDstKTwvc3Bhbj4gPHU+PHNw YW4gc3R5bGU9J2NvbG9yOmJsdWUnPjxicj48L3NwYW4+PC91PjxhIGhyZWY9Imh0dHA6Ly93d3cu Y2lzY28uY29tL2VuL1VTL2RvY3MvaW9zLzEyXzR0L2lwX21jYXN0L2NvbmZpZ3VyYXRpb24vZ3Vp ZGUvbWN0bHNwbHQuaHRtbCN3cDEwNjQ1MDEiPmh0dHA6Ly93d3cuY2lzY28uY29tL2VuL1VTL2Rv Y3MvaW9zLzEyXzR0L2lwX21jYXN0L2NvbmZpZ3VyYXRpb24vZ3VpZGUvbWN0bHNwbHQuaHRtbCN3 cDEwNjQ1MDE8L2E+IDxicj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiQXJpYWwiLCJzYW5zLXNlcmlmIic+PGJyPi0tPC9zcGFuPiA8c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+PGJyPlN1bm55PC9z cGFuPiA8YnI+PGJyPjxicj48YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZh bWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojNUY1RjVGJz48YnI+RnJvbTogJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7 Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPiZxdW90O1Rpc3NhIFNlbmV2aXJhdGhu ZSAodHNlbmV2aXIpJnF1b3Q7ICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnRzZW5ldmlyQGNp c2NvLmNvbSI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiQXJpYWwi LCJzYW5zLXNlcmlmIic+dHNlbmV2aXJAY2lzY28uY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4mZ3Q7PC9z cGFuPiA8c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiO2NvbG9yOiM1RjVGNUYnPjxicj5UbzogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFs Iiwic2Fucy1zZXJpZiInPkRhdmlkIE0gQm9uZC9CZWRmb3JkL0lCTUBJQk1VUzwvc3Bhbj4gPHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm Ijtjb2xvcjojNUY1RjVGJz48YnI+Q2M6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvc3Bh bj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMt c2VyaWYiJz5Eb25hbGQgRWFzdGxha2UgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZDNlM2Uz QGdtYWlsLmNvbSI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIic+ZDNlM2UzQGdtYWlsLmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+Jmd0Oywg PC9zcGFuPjxhIGhyZWY9Im1haWx0bzp0cmlsbC1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHls ZT0nZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz50cmls bC1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuNXB0 O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4sIDwvc3Bhbj48YSBocmVmPSJtYWls dG86dHJpbGxAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1p bHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPnRyaWxsQGlldGYub3JnPC9zcGFuPjwvYT4gPHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtj b2xvcjojNUY1RjVGJz48YnI+RGF0ZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiInPjA0LzMwLzIwMTIgMTI6MjkgUE08L3NwYW4+IDxzcGFuIHN0eWxlPSdmb250LXNpemU6 Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzVGNUY1Ric+PGJy PlN1YmplY3Q6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5SZTogW3Ry aWxsXSBUUklMTCBPQU0gUmVxdWlyZW1lbnRzOiBhdmFpbGFibGUgcGF0aHM8L3NwYW4+IDxzcGFu IHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzVGNUY1Ric+PGJyPlNlbnQgYnk6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwv c3Bhbj48YSBocmVmPSJtYWlsdG86dHJpbGwtYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+dHJpbGwt Ym91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05v cm1hbCBhbGlnbj1jZW50ZXIgc3R5bGU9J3RleHQtYWxpZ246Y2VudGVyJz48bzpwPiZuYnNwOzwv bzpwPjwvcD48ZGl2IGNsYXNzPU1zb05vcm1hbCBhbGlnbj1jZW50ZXIgc3R5bGU9J3RleHQtYWxp Z246Y2VudGVyJz48aHIgc2l6ZT0yIHdpZHRoPSIxMDAlIiBub3NoYWRlIHN0eWxlPSdjb2xvcjoj QTBBMEEwJyBhbGlnbj1jZW50ZXI+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxicj48YnI+PGJy PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzAwNDA4MCc+PGJyPkxldCBtZSBzdGFydCBmcm9tIHRoZSBiYXNpY3Mu PC9zcGFuPiA8c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMwMDQwODAnPjxicj48L3NwYW4+Jm5ic3A7PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMDA0MDgwJz48YnI+MS4gJm5ic3A7ICZuYnNwOyAmbmJzcDsgVFJJTEwgaXMgYWxsIGFi b3V0IG11bHRpcGxlIGFjdGl2ZSBwYXRocy48L3NwYW4+IDxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzAwNDA4MCc+ PGJyPjIuICZuYnNwOyAmbmJzcDsgJm5ic3A7IE11bHRpcGxlIGFjdGl2ZSBwYXRocyBhcmUgZGVy aXZlZCBmcm9tIGxlYXN0IGNvc3QgcGF0aHMgdG8gYSBzcGVjaWZpYyBkZXN0aW5hdGlvbnMuPC9z cGFuPiA8c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMwMDQwODAnPjxicj4zLiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBX ZWxsIGRlZmluZWQgYW5kIGltcGxlbWVudGVkIEhhc2hpbmcgYWxnb3JpdGhtcyBwcm92aWRlIGFu IGFsbW9zdCBldmVuIGRpc3RyaWJ1dGlvbiBhY3Jvc3MgYWxsIG9mIHRoZSBhdmFpbGFibGUgbGVh c3QgY29zdCBwYXRocyB0byBhIGRlc3RpbmF0aW9uPC9zcGFuPiA8c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMwMDQw ODAnPjxicj40LiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJZiBhIGdpdmVuIGZsb3cg4oCceOKAnSBk b2VzIG5vdCBtYXAgdG8gJm5ic3A7YSBzcGVjaWZpYyBsZWFzdCBjb3N0IHBhdGgsIGRvZXMgbm90 IG1hcCB0byBhIHNwZWNpZmljIGxlYXN0IGNvc3QgcGF0aCBkb2VzIG5vdCBtZWFuIGFub3RoZXIg ZmxvdyDigJx54oCdIHRvIHRoZSBzYW0gZGVzdGluYXRpb24gd2lsbCBub3QgbWFwIHRvIHRoZSB0 aGF0IHBhdGguIDxicj41LiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBXZWxsIGltcGxlbWVudGVkIGhh c2hpbmcgYWxnb3JpdGhtcyBwcm92aWRlIGV2ZW4gZGlzdHJpYnV0aW9uIG9mIGZsb3dzLjwvc3Bh bj4gPHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMDA0MDgwJz48YnI+Ni4gJm5ic3A7ICZuYnNwOyAmbmJzcDsgSGVu Y2UgaXQgaXMgaW1wb3J0YW50IHRvIGhhdmUgYWJpbGl0eSB0byB0ZXN0IGFsbCBhdmFpbGFibGUg bGVhc3QgY29zdCBwYXRocyB0byBhIGRlc3RpbmF0aW9uLjwvc3Bhbj4gPHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MDA0MDgwJz48YnI+Ny4gJm5ic3A7ICZuYnNwOyAmbmJzcDsgSXQgaXMgYW4gaW1wbGVtZW50YXRp b24gZGVmZWN0LCBJZiB0aGVyZSBpcyBhbiBpbXBsZW1lbnRhdGlvbiBvdXQgdGhlcmUgd2hpY2gg ZG9lcyBub3QgaGFzaCBmbG93cyAob3ZlciBhIGxvbmdlciBzYW1wbGluZyBwZXJpb2QpICZuYnNw O2luIHRvIGEgc3BlY2lmaWMg4oCcbGVhc3QgY29zdCBwYXRo4oCdIG9mIHNldCBvZiBsZWFzdCBj b3N0IHBhdGhzIHRvIGEgZGVzdGluYXRpb24sIGFtb25nIGFsbCBhdmFpbGFibGUg4oCcbGVhc3Qg Y29zdCBwYXRoc+KAnSB0byB0aGF0IGRlc3RpbmF0aW9uLjwvc3Bhbj4gPHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MDA0MDgwJz48YnI+PC9zcGFuPiZuYnNwOzxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+PGJyPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1z ZXJpZiInPiBEYXZpZCBNIEJvbmQgWzwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZG1ib25kQHVzLmli bS5jb20iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIic+bWFpbHRvOmRtYm9uZEB1cy5pYm0uY29tPC9zcGFuPjwvYT48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiIn Pl0gPGI+PGJyPlNlbnQ6PC9iPiBNb25kYXksIEFwcmlsIDMwLCAyMDEyIDg6MzkgQU08Yj48YnI+ VG86PC9iPiBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKTxiPjxicj5DYzo8L2I+IERvbmFs ZCBFYXN0bGFrZTsgPC9zcGFuPjxhIGhyZWY9Im1haWx0bzp0cmlsbEBpZXRmLm9yZyI+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi Jz50cmlsbEBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz47IDwvc3Bhbj48YSBocmVmPSJtYWls dG86dHJpbGwtYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz50cmlsbC1ib3VuY2VzQGlldGYub3Jn PC9zcGFuPjwvYT48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi VGFob21hIiwic2Fucy1zZXJpZiInPjxicj5TdWJqZWN0Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gUmU6 IFt0cmlsbF0gVFJJTEwgT0FNIFJlcXVpcmVtZW50czogYXZhaWxhYmxlIHBhdGhzPC9zcGFuPiA8 YnI+Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPjxwPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5KdXN0IGEgcXVlc3Rpb24gY29taW5n IGZyb20gdGhpcyBjb252ZXJzYXRpb24gdGhhdCBJIHdhbnQgdG8gY2xhcmlmeTo8YnI+PGJyPlNv IHdlIGhhdmUgJ2FsbCBwb3NzaWJsZSBwYXRocycgKDEpIHdoaWNoIGNvdWxkIGluY2x1ZGUgbm9u LWxlYXN0IGNvc3QgcGF0aHMgYW5kIHNvIG9mIGNvdXJzZSB3ZSBkb24ndCB3YW50IHRvIHVzZSB0 aGlzIGRlZmluaXRpb24uPGJyPjxicj5UaGVuIHdlIGhhdmUgJ2FsbCBlY21wIHBhdGhzJyBvciAn YWxsIGxlYXN0IGNvc3QgcGF0aHMnICgyKSB3aGljaCBNQVkgaW5jbHVkZSBwYXRocyBuZXZlciBj aG9zZW4gYnkgYSB0cmFuc2l0IFJicmlkZ2UgYmVjYXVzZSBvZiB0aGUgbG9jYWwgaGFzaGluZyBj aG9pY2VzLjxicj48YnI+VGhlbiB3ZSBoYXZlICdhbGwgdGhlIGxlYXN0IGNvc3QgcGF0aHMgd2hp Y2ggbWF5IGJlIGNob3NlbiBnaXZlbiB0aGUgaGFzaGluZyBpbXBsZW1lbnRhdGlvbiBvbiB0aGUg bG9jYWwgUmJyaWRnZXMnICgzKS48YnI+PGJyPkkgd29uZGVyIGlmIGNob2ljZSAoMikgaXMgdXNl ZnVsIG9yIGRvIHdlIG9ubHkgcmVhbGx5IGNhcmUgYWJvdXQgY2hvaWNlICgzKS4gRm9yIGluc3Rh bmNlLCBpZiB5b3UgaGF2ZSAxNiBlcXVhbCBjb3N0IHBhdGhzIGZyb20gQSB0byBCIGFuZCB5b3Vy IGhhc2hpbmcgb25seSB3aWxsIGV2ZXIgdXNlIDIgb2YgdGhvc2UgcGF0aHMgZG8gd2UgY2FyZSBh Ym91dCByZXBvcnRpbmcgYmFjayBlY21wIHBhdGhzIHRoYXQgd2lsbCBuZXZlciBpbiBwcmFjdGlj ZSBiZSB1c2VkPyBQZXJoYXBzIHRoZSBkZWZpbml0aW9uIHNob3VsZCBiZSB0aWdodGVuZWQgdG8g b25seSByZXF1aXJlIGRldGVybWluYXRpb24gb2YgYWxsIGxlYXN0IGNvc3QgcGF0aHMgdGhhdCBj b3VsZCBiZSB1c2VkIGdpdmVuIHRoZSBsb2NhbCBoYXNoaW5nIGltcGxlbWVudGF0aW9uLiBPciBh bSBJIG1pc3VuZGVyc3RhbmRpbmcgdGhlIGNvbnZlcnNhdGlvbiBhbmQgaXMgdGhpcyBhbHJlYWR5 IHRoZSBwb2ludCBiZWluZyBtYWRlIGJldHdlZW4gdGhlb3JldGljYWwgcGF0aHMgYW5kIGxlYXN0 IGNvc3QgcGF0aHMuPGJyPjxicj5UaGFua3MsPGJyPkRhdmlkPC9zcGFuPjxicj48YnI+PGltZyBi b3JkZXI9MCB3aWR0aD0xNiBoZWlnaHQ9MTYgaWQ9Il94MDAwMF9pMTAyNyIgc3JjPSJjaWQ6aW1h Z2UwMDEuZ2lmQDAxQ0QyNkQ1LjdCRjE4REQwIiBhbHQ9IkluYWN0aXZlIGhpZGUgZGV0YWlscyBm b3IgJnF1b3Q7VGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZpcikmcXVvdDsgLS0tMDQvMjkvMjAx MiAxMTo0MzowNyBQTS0tLUkgbGlrZSB0aGF0IERvbmFsZC4uIFdlIGNhbiB1c2UgJnF1b3Q7YWxs IGxlYXMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIs InNhbnMtc2VyaWYiO2NvbG9yOiM0MjQyODInPiZxdW90O1Rpc3NhIFNlbmV2aXJhdGhuZSAodHNl bmV2aXIpJnF1b3Q7IC0tLTA0LzI5LzIwMTIgMTE6NDM6MDcgUE0tLS1JIGxpa2UgdGhhdCBEb25h bGQuLiBXZSBjYW4gdXNlICZxdW90O2FsbCBsZWFzdCBjb3N0IHBhdGhzJnF1b3Q7LCB0aGF0IGlz IHRlY2huaWNhbGx5IG1vcmUgcHJlY2lzZSBhbmQgcmVwcmVzZTwvc3Bhbj48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiM1 RjVGNUYnPjxicj48YnI+RnJvbTogPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7 Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPiZxdW90O1Rpc3NhIFNlbmV2aXJhdGhu ZSAodHNlbmV2aXIpJnF1b3Q7ICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnRzZW5ldmlyQGNp c2NvLmNvbSI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiQXJpYWwi LCJzYW5zLXNlcmlmIic+dHNlbmV2aXJAY2lzY28uY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4mZ3Q7PHNw YW4gc3R5bGU9J2NvbG9yOiM1RjVGNUYnPjxicj5UbzogPC9zcGFuPiZxdW90O0RvbmFsZCBFYXN0 bGFrZSZxdW90OyAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpkM2UzZTNAZ21haWwuY29tIj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2Vy aWYiJz5kM2UzZTNAZ21haWwuY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcu NXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4mZ3Q7LCAmbHQ7PC9zcGFuPjxh IGhyZWY9Im1haWx0bzp0cmlsbEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVw dDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+dHJpbGxAaWV0Zi5vcmc8L3NwYW4+ PC9hPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fu cy1zZXJpZiInPiZndDs8c3BhbiBzdHlsZT0nY29sb3I6IzVGNUY1Ric+PGJyPkRhdGU6IDwvc3Bh bj4wNC8yOS8yMDEyIDExOjQzIFBNPHNwYW4gc3R5bGU9J2NvbG9yOiM1RjVGNUYnPjxicj5TdWJq ZWN0OiA8L3NwYW4+UmU6IFt0cmlsbF0gVFJJTEwgT0FNIFJlcXVpcmVtZW50czogYXZhaWxhYmxl IHBhdGhzPHNwYW4gc3R5bGU9J2NvbG9yOiM1RjVGNUYnPjxicj5TZW50IGJ5OiA8L3NwYW4+PC9z cGFuPjxhIGhyZWY9Im1haWx0bzp0cmlsbC1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz50cmlsbC1i b3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT4gPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9y bWFsIGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50ZXInPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPjxkaXYgY2xhc3M9TXNvTm9ybWFsIGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGln bjpjZW50ZXInPjxociBzaXplPTIgd2lkdGg9IjEwMCUiIG5vc2hhZGUgc3R5bGU9J2NvbG9yOiNB MEEwQTAnIGFsaWduPWNlbnRlcj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGJyPjxicj48YnI+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+ PGJyPjxicj5JIGxpa2UgdGhhdCBEb25hbGQuLiBXZSBjYW4gdXNlICZxdW90O2FsbCBsZWFzdCBj b3N0IHBhdGhzJnF1b3Q7LCB0aGF0IGlzIHRlY2huaWNhbGx5IG1vcmUgcHJlY2lzZSBhbmQgcmVw cmVzZW50IGV4YWN0bHkgd2hhdCBJUy1JUyBkb2VzLjxicj48YnI+VGhhbmtzPGJyPlRpc3NhPGJy Pjxicj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj5Gcm9tOiA8L3NwYW4+PGEgaHJlZj0i bWFpbHRvOnRyaWxsLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPnRyaWxsLWJvdW5jZXNAaWV0Zi5vcmc8L3Nw YW4+PC9hPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyInPiBbPC9zcGFuPjxhIGhyZWY9Im1haWx0bzp0cmlsbC1ib3VuY2VzQGlldGYub3JnIj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz5t YWlsdG86dHJpbGwtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+XSBPbiBCZWhhbGYgT2YgRG9u YWxkIEVhc3RsYWtlPGJyPlNlbnQ6IFN1bmRheSwgQXByaWwgMjksIDIwMTIgNjoyNyBQTTxicj5U bzogPC9zcGFuPjxhIGhyZWY9Im1haWx0bzp0cmlsbEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+dHJpbGxAaWV0Zi5vcmc8 L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyInPjxicj5TdWJqZWN0OiBSZTogW3RyaWxsXSBUUklMTCBPQU0gUmVxdWlyZW1lbnRz OiBhdmFpbGFibGUgcGF0aHM8YnI+PGJyPkkgZG9uJ3QgdGhpbmsgdGhlIHdvcmRpbmcgJnF1b3Q7 YWxsIHBhdGhzJnF1b3Q7IHNob3VsZCBldmVyIGJlIHVzZWQuIElmIHlvdSB0aGUgaXQgbGl0ZXJh bGx5LCBpdCB3b3VsZCBldmVuIGluY2x1ZGUgcGF0aHMgdGhhdCBnbyB0aHJvdWdoIHNvbWUgUkJy aWRnZXMgbW9yZSB0aGFuIG9uY2UuPGJyPjxicj5JIGRvbid0IHBhcnRpY3VsYXJseSBsaWtlICZx dW90O2FsbCBFQ01QIHBhdGhzJnF1b3Q7IGVpdGhlci4gSSB0aGluayB0aGUgY2xlYXJlc3Qgd29y ZGluZyBpcyAmcXVvdDthbGwgbGVhc3QgY29zdCBwYXRocyZxdW90OyBpZiB5b3UgYXJlIHRhbGtp bmcgYWJvdXQga25vd24gdW5pY2FzdC4gKEFuZCAmcXVvdDthbGwgZGlzdHJpYnV0aW9uIHRyZWUg cGF0aHMmcXVvdDsgaWYgeW91IHdlcmUgdGFsa2luZyBhYm91dCBtdWx0aS1kZXN0aW5hdGlvbiBm cmFtZXMuKTxicj48YnI+VGhhbmtzLDxicj5Eb25hbGQ8YnI+PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT08YnI+RG9uYWxkIEUuIEVhc3RsYWtlIDNyZCAmbmJzcDsgKzEtNTA4LTMzMy0yMjcw IChjZWxsKTxicj4xNTUgQmVhdmVyIFN0cmVldCwgTWlsZm9yZCwgTUEgMDE3NTcgVVNBPC9zcGFu Pjx1PjxzcGFuIHN0eWxlPSdjb2xvcjpibHVlJz48YnI+PC9zcGFuPjwvdT48YSBocmVmPSJtYWls dG86ZDNlM2UzQGdtYWlsLmNvbSI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Iic+ZDNlM2UzQGdtYWlsLmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PGJyPjxicj48 YnI+T24gU2F0LCBBcHIgMjgsIDIwMTIgYXQgMTE6NDUgUE0sIEVyaWsgTm9yZG1hcmsgJmx0Ozwv c3Bhbj48YSBocmVmPSJtYWlsdG86bm9yZG1hcmtAYWNtLm9yZyI+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+bm9yZG1hcmtAYWNtLm9yZzwv c3Bhbj48L2E+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Iic+Jmd0OyB3cm90ZTo8YnI+Jmd0OyBPbiA0LzI3LzEyIDU6MTIgUE0sIFRpc3NhIFNl bmV2aXJhdGhuZSAodHNlbmV2aXIpIHdyb3RlOjxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBPZiBj b3Vyc2UgaXQgaXMgcG9zc2libGUuIFRoZSBJUy1JUyB0b3BvbG9neSB0YWJsZSBwcm92aWRlIHRo ZSA8YnI+Jmd0OyZndDsgaW5mb3JtYXRpb24gb24gYWxsIGF2YWlsYWJsZSBFQ01QIHBhdGhzIHRv IGEgc3BlY2lmaWMgZGVzdGluYXRpb24gPGJyPiZndDsmZ3Q7IHdoZW4gdGhlIGVncmVzcyBSQlJp ZGdlIG5pY2tuYW1lIGlzIGtub3duLiBUaGF0IGlzIHdoYXQgVFJJTEwgdW5pY2FzdCA8YnI+Jmd0 OyZndDsgZm9yd2FyZGluZyB0YWJsZSBhbGwgYWJvdXQuIE5vdCBzdXJlIHdoeSB5b3UgYXJlIHNh eWluZyBpdCBpcyBub3QgPGJyPiZndDsmZ3Q7IHBvc3NpYmxlIHRvIGtub3cgYWxsIEVDTVAgcGF0 aHMuPGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7IFlvdSBhcmUgdGFsa2luZyBhYm91dCB3aGF0IFNh bnRvc2ggY2FsbGVkICZxdW90O2FsbCB0aGVvcmV0aWNhbGx5IGF2YWlsYWJsZSA8YnI+Jmd0OyBw YXRocyZxdW90Oy4gVGhvc2UgY2FuIGJlIGRldGVybWluZWQgZnJvbSBJUy1JUy48YnI+Jmd0Ozxi cj4mZ3Q7IEJ1dCB0aGUgZG9jdW1lbnQgdGFsa3MgYWJvdXQgJnF1b3Q7YWxsIGF2YWlsYWJsZSBw YXRocyZxdW90OyBhbmQgSSBkb24ndCBrbm93IDxicj4mZ3Q7IHdoYXQgdGhhdCBpcyBzdXBwb3Nl ZCB0byBtZWFuLiBEbyB5b3UgaGF2ZSBhIHN1Y2NpbmN0IGRlZmluaXRpb24/PGJyPiZndDs8YnI+ Jmd0OyBXaGF0IGlzIGNsZWFyIHRvIG1lIGlzIHRoYXQgdGhlcmUgY2FuIGJlIGEgc3Vic2V0IG9m IHRoZSBwYXRocyB0aGF0IDxicj4mZ3Q7IGFyZSBkZXRlcm1pbmVkIGZyb20gSVMtSVMgdGhhdCB3 b3VsZCBuZXZlciBiZSB1c2VkLCBiZWNhdXNlIG5vIGVudHJvcHkgPGJyPiZndDsgaW4gYSBwYWNr ZXQgd291bGQgZXZlcnkgcGljayB0aGF0IHBhdGguPGJyPiZndDs8YnI+Jmd0OyBJcyB0aGUgcmVx dWlyZW1lbnQgaW4gdGhlIGRvY3VtZW50IHRoYXQgdGhlIE9BTSBzb2x1dGlvbiBzaG91bGQgYmUg PGJyPiZndDsgYWJsZSB0byB0ZXN0IHRob3NlIHBhdGhzPzxicj4mZ3Q7PGJyPiZndDs8YnI+Jmd0 OyZndDsgV2hhdCBwYXRoIGFtb25nIGF2YWlsYWJsZSBwYXRocyB0byBiZSBzZWxlY3RlZCBmb3Ig YSBzcGVjaWZpZWQgaXMgYSA8YnI+Jmd0OyZndDsgbG9jYWwgbWF0dGVyLiBUaGF0IGlzIHdoYXQg YWxsIGFib3V0IGZsb3cgZW50cm9weSBkaXNjb3ZlcnkuIExpa2UgSSA8YnI+Jmd0OyZndDsgc3Rh dGVkIGVhcmxpZXIgaG93IGl0IGlzIGRpc2NvdmVyZWQgaXMgYSBmcmFtZXdvcmsgYW5kIHNvbHV0 aW9uIGlzc3VlLjxicj4mZ3Q7PGJyPiZndDs8YnI+Jmd0OyBBZ3JlZWQuPGJyPiZndDs8YnI+Jmd0 Ozxicj4mZ3Q7Jmd0OyBJZiB5b3UgbmVlZCBzb21lIHJlZmVyZW5jZSBob3cgaXQgaXMgZG9uZSBp biB0aGUgTVBMUyB3b3JsZCBSRkMgNDM3OSA8YnI+Jmd0OyZndDsgaXMgYSBnb29kIHJlZmVyZW5j ZS48YnI+Jmd0Ozxicj4mZ3Q7PGJyPiZndDsgQUZBSUsgTVBMUyBkb2Vzbid0IGhhdmUgYSBsb2Nh bGx5IGRlZmluZWQgRUNNUCBoYXNoIGZ1bmN0aW9uIGluIGV2ZXJ5IGhvcC48YnI+Jmd0OyBUUklM TCBkb2VzLCB3aGljaCBtYWtlcyB0aGVzZSBhc3BlY3RzIGRpZmZlcmVudC48YnI+Jmd0Ozxicj4m Z3Q7IFJlZ2FyZHMsPGJyPiZndDsgJm5ic3A7IEVyaWs8YnI+Jmd0Ozxicj4mZ3Q7PGJyPiZndDsm Z3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPiZndDsmZ3Q7IEZyb206IDwvc3Bhbj48 YSBocmVmPSJtYWlsdG86dHJpbGwtYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+dHJpbGwtYm91bmNlc0BpZXRm Lm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Iic+IFs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnRyaWxsLWJvdW5jZXNAaWV0 Zi5vcmciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyInPm1haWx0bzp0cmlsbC1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz5dIE9uIDxicj4m Z3Q7Jmd0OyBCZWhhbGYgT2YgRXJpayBOb3JkbWFyazxicj4mZ3Q7Jmd0OyBTZW50OiBGcmlkYXks IEFwcmlsIDI3LCAyMDEyIDQ6MDcgUE08YnI+Jmd0OyZndDsgVG86IFNhbnRvc2ggUmFqYWdvcGFs YW48YnI+Jmd0OyZndDsgQ2M6IDwvc3Bhbj48YSBocmVmPSJtYWlsdG86dHJpbGxAaWV0Zi5vcmci PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIn PnRyaWxsQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiQ291cmllciBOZXciJz48YnI+Jmd0OyZndDsgU3ViamVjdDogUmU6IFt0cmls bF0gVFJJTEwgT0FNIFJlcXVpcmVtZW50czogYXZhaWxhYmxlIHBhdGhzPGJyPiZndDsmZ3Q7PGJy PiZndDsmZ3Q7IE9uIDQvMjcvMTIgMjoxNSBQTSwgU2FudG9zaCBSYWphZ29wYWxhbiB3cm90ZTo8 YnI+Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyBJIGFncmVlLCB0aGUgd29yZGluZyBuZWVk cyB0byBiZSB0aWdodGVuZWQgdG8gc2F5ICZxdW90O2FsbCBwb3NzaWJsZSBlY21wIDxicj4mZ3Q7 Jmd0OyZndDsgcGF0aHMmcXVvdDsgcmF0aGVyIHRoYW4gJnF1b3Q7YWxsIGF2YWlsYWJsZSBwYXRo cyZxdW90Oy4gQW4gb3BlcmF0b3Igd29ya2luZyBvdXQ8YnI+Jmd0OyZndDsmZ3Q7IFIxLVIyIGNv bW11bmljYXRpb24gaXMgaW50ZXJlc3RlZCBpbiBhbGwgcG9zc2libGUgcGF0aHMgZGF0YSB0cmFm ZmljIDxicj4mZ3Q7Jmd0OyZndDsgY291bGQgdGFrZSByYXRoZXIgdGhhbiBhbGwgdGhlb3JldGlj YWxseSBhdmFpbGFibGUgcGF0aHMuPGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7 IFRoZSBpc3N1ZSBpcyB0aGF0IHRoZXJlIGlzIG5vdGhpbmcgaW4gdGhlIFRSSUxMIGRhdGFwbGFu ZSBub3IgSVMtSVMgPGJyPiZndDsmZ3Q7IGNvbnRyb2wgcGxhbmUgd2hpY2ggaGVscHMgdGhlIG9w ZXJhdG9yIGRldGVybWluZSB0aGF0IHNvbWUgcGF0aHMgPGJyPiZndDsmZ3Q7ICh0aHJvdWdoIFJC MTIxIGFuZCBSQjExMiBpbiB0aGUgZXhhbXBsZSkgYXJlIG5vdCBwb3NzaWJsZTsgdGhlIEVDTVAg PGJyPiZndDsmZ3Q7IGlucHV0IGFuZCBoYXNoaW5nIGlzIGEgY29tcGxldGVseSBsb2NhbCBtYXR0 ZXIgb24gZWFjaCBSQnJpZGdlLjxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBJdCBpc24ndCB1c2Vm dWwgdG8gc3RhdGUgYSByZXF1aXJlbWVudCBhcm91bmQgc29tZXRoaW5nIHRoYXQgY2FuJ3QgYmUg PGJyPiZndDsmZ3Q7IGRldGVybWluZWQuPGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7ICZuYnNwOyAm bmJzcDsgRXJpazxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7PGJy PiZndDsmZ3Q7Jmd0OyBGcm9tOiBFcmlrIE5vcmRtYXJrJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWls dG86bm9yZG1hcmtAYWNtLm9yZyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Iic+bm9yZG1hcmtAYWNtLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0Ozxicj4m Z3Q7Jmd0OyZndDsgVG86IDwvc3Bhbj48YSBocmVmPSJtYWlsdG86dHJpbGxAaWV0Zi5vcmciPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPnRy aWxsQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiQ291cmllciBOZXciJz48YnI+Jmd0OyZndDsmZ3Q7IERhdGU6IDA0LzI3LzIwMTIg MDk6NTMgQU08YnI+Jmd0OyZndDsmZ3Q7IFN1YmplY3Q6IFt0cmlsbF0gVFJJTEwgT0FNIFJlcXVp cmVtZW50czogYXZhaWxhYmxlIHBhdGhzIFNlbnQgYnk6PGJyPiZndDsmZ3Q7Jmd0OyA8L3NwYW4+ PGEgaHJlZj0ibWFpbHRvOnRyaWxsLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPnRyaWxsLWJvdW5jZXNAaWV0 Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyInPjxicj4mZ3Q7Jmd0OyZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+Jmd0OyZndDsm Z3Q7IC0tPGJyPiZndDsmZ3Q7Jmd0OyAtLTxicj4mZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7 PGJyPiZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7IFR3byByZXF1 aXJlbWVudHMgdXNlIHRoZSB3b3JkaW5nICZxdW90O2FsbCBhdmFpbGFibGUgcGF0aHMuJnF1b3Q7 IGFuZCAmcXVvdDthbGwgPGJyPiZndDsmZ3Q7Jmd0OyBhdmFpbGFibGUgRUNNUCBwYXRocy4mcXVv dDssIHJlc3BlY3RpdmVseSBhbmQgSSdtIG5vdCBzdXJlIEkga25vdyB3aGF0IDxicj4mZ3Q7Jmd0 OyZndDsgdGhhdDxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsgbWVhbnMu PGJyPiZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsgVGFrZSB0aGUgZm9sbG93aW5nIGV4YW1w bGUgcGljdHVyZTo8YnI+Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyBSMTxicj4mZ3Q7Jmd0 OyZndDsgLyBcPGJyPiZndDsmZ3Q7Jmd0OyAvIFw8YnI+Jmd0OyZndDsmZ3Q7IC8gXDxicj4mZ3Q7 Jmd0OyZndDsgLyBcPGJyPiZndDsmZ3Q7Jmd0OyAvIFw8YnI+Jmd0OyZndDsmZ3Q7IFJCMTEgUkIx Mjxicj4mZ3Q7Jmd0OyZndDsgLyBcIC8gXDxicj4mZ3Q7Jmd0OyZndDsgLyBcIC8gXDxicj4mZ3Q7 Jmd0OyZndDsgUkIxMTEgUkIxMTIgUkIxMjEgUkIxMjI8YnI+Jmd0OyZndDsmZ3Q7IFwgXCAvIC88 YnI+Jmd0OyZndDsmZ3Q7IFwgXCAvIC88YnI+Jmd0OyZndDsmZ3Q7IFwgXC8gLzxicj4mZ3Q7Jmd0 OyZndDsgLS0tLS0tUjItLS0tLS08YnI+Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyBXZSBj YW4gc2VlIHRoYXQgdGhlcmUgYXJlIDQgcGF0aHMgd2l0aCAzIGhvcHMgdG8gZ2V0IGZyb20gUjEg dG8gUjIsIDxicj4mZ3Q7Jmd0OyZndDsgd2l0aCB0d28gbGF5ZXJzIG9mIEVDTVAgZGVjaXNpb25z LiBCdXQgaG93IG1hbnkgYXZhaWxhYmxlIHBhdGhzIGFyZTxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0 OyB0aGVyZT88YnI+Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsg R2l2ZW4gdGhhdCB0aGUgUkJyaWRnZXMgbWFrZSBpbmRlcGVuZGVudCBFQ01QIGRlY2lzaW9ucywg YW5kIGhvdyA8YnI+Jmd0OyZndDsmZ3Q7IHRoZXkgZG8gdGhhdCBpcyBhIGxvY2FsIG1hdHRlciwg aXQgY291bGQgYmUgdGhlIGNhc2UgdGhhdCBmb3IgYW55IDxicj4mZ3Q7Jmd0OyZndDsgcGFja2V0 LCBpZiBSMSBwaWNrcyB0aGUgbGVmdCBsaW5rLCB0aGVuIFIxMSB3b3VsZCBhbHNvIHBpY2sgdGhl IGxlZnQgPGJyPiZndDsmZ3Q7Jmd0OyBsaW5rOyBpZjxicj4mZ3Q7Jmd0OyZndDsgUjEgcGlja3Mg dGhlIHJpZ2h0IGxpbmssIHRoZW4gUjEyIGFsc28gcGlja3MgdGhlIHJpZ2h0IGxpbmsuPGJyPiZn dDsmZ3Q7Jmd0OyBUaHVzIHRoZXJlIHdvdWxkIGJlIG5vIHBhY2tldCAoZGF0YSBvciBPQU0pIHRo YXQgd291bGQgY2F1c2UgcGFja2V0cyA8YnI+Jmd0OyZndDsmZ3Q7IGJldHdlZW4gUjEgYW5kIFIy IHRvIHBhc3MgdmlhIFJCMTEyIG9yIFJCMTIxLjxicj4mZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsm Z3Q7IEV2ZW4gaWYgd2UgaWdub3JlIHRoYXQgYXMgdW5saWtlbHksIHRoZXJlIGlzIHN0aWxsIHRo ZSBmYWN0IHRoYXQgUjEgPGJyPiZndDsmZ3Q7Jmd0OyBjYW4ndCBlYXNpbHkgdGVsbCBob3cgbWFu eSAoc2hvcnRlc3QpIHBhdGhzIHRoZXJlIG1pZ2h0IGJlIGJldHdlZW4gPGJyPiZndDsmZ3Q7Jmd0 OyBpdCBhbmQgUjIuIFdpdGggc2luZ2xlLWxldmVsIFRSSUxMIHRoZSBMU0RCIGNvdWxkIGJlIHVz ZWQgdG8gdGVsbCwgPGJyPiZndDsmZ3Q7Jmd0OyBidXQgaWY8YnI+Jmd0OyZndDs8YnI+Jmd0OyZn dDs8YnI+Jmd0OyZndDsmZ3Q7IHdlIGV2ZXIgZ28gdG8gbXVsdGktbGV2ZWwgdGhhdCB3b3VsZG4n dCBiZSB0aGUgY2FzZSBhbnkgbW9yZS48YnI+Jmd0OyZndDsmZ3Q7IEFuZCBldmVuIGlmIFIxIGtu b3dzIHRoYXQgdGhlcmUgYXJlIDQgcG90ZW50aWFsIHBhdGhzLCBpdCBjYW4ndCA8YnI+Jmd0OyZn dDsmZ3Q7IGZvcm1hdDxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsgYSBk YXRhIHBhY2tldCAob3IgZm9ybWF0IHRoZSBmbG93IGVudHJvcHkgaW4gYW4gT0FNIHBhY2tldCkg aW4gc3VjaCA8YnI+Jmd0OyZndDsmZ3Q7IGEgd2F5IHRoYXQgcGFydGljdWxhciBwYXRocyBnZXQg Y2hvc2VuIGJ5IGRvd25zdHJlYW0gRUNNUCBkZWNpc2lvbnMuPGJyPiZndDsmZ3Q7Jmd0Ozxicj4m Z3Q7Jmd0OyZndDsgVGh1cyBmb3IgYW55IG5vdGlvbiBvZiAmcXVvdDthbGwgYXZhaWxhYmxlIHBh dGhzJnF1b3Q7IHRoYXQgbWFrZSBzZW5zZSB0byBtZSwgPGJyPiZndDsmZ3Q7Jmd0OyB3ZSdkIG5l ZWQgYW4gT0FNIGFwcHJvYWNoIHRoYXQgY2FuIGV4cGxvcmUgdGhlIHRvcG9sb2d5IG9uZSBob3Ag YXQgYSA8YnI+Jmd0OyZndDsmZ3Q7IHRpbWUgYW5kIGF0IGVhY2ggaG9wIGV4cGxvcmUgYWxsIHRo ZSBwb3NzaWJsZSBFQ01QIGNob2ljZXMuIFVzaW5nIDxicj4mZ3Q7Jmd0OyZndDsgdGhlIGVudHJv cHkgZG9lc24ndCBoZWxwIHdpdGggdGhpcyAoYnV0IHRoZSBlbnRyb3B5IGlzIGNyaXRpY2FsIGZv ciA8YnI+Jmd0OyZndDsmZ3Q7IGZvbGxvd2luZyB0aGUgcGF0aCB0YWtlbiBieSBhIHBhcnRpY3Vs YXIgZmxvdyBvZiBkYXRhIHBhY2tldHMpLjxicj4mZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7 IEhlbmNlIGl0IHdvdWxkIGJlIGdvb2QgdG8gY2xhcmlmeSB3aGF0IHRoZSBhc3N1bXB0aW9ucyBh cmUgYmVoaW5kIDxicj4mZ3Q7Jmd0OyZndDsgdGhpczxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0Ozxi cj4mZ3Q7Jmd0OyZndDsgbm90aW9uIG9mIGFsbCBhdmFpbGFibGUgcGF0aHMuPGJyPiZndDsmZ3Q7 Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsgVGhhbmtzLDxicj4mZ3Q7Jmd0OyZndDsgRXJpazxicj4mZ3Q7 Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPiZndDsmZ3Q7Jmd0OyB0cmlsbCBtYWlsaW5nIGxpc3Q8YnI+Jmd0 OyZndDsmZ3Q7IDwvc3Bhbj48YSBocmVmPSJtYWlsdG86dHJpbGxAaWV0Zi5vcmciPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPnRyaWxsQGll dGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiQ291cmllciBOZXciJz48YnI+Jmd0OyZndDsmZ3Q7IDwvc3Bhbj48YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsIj48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48YnI+Jmd0OyZndDsmZ3Q7PGJyPiZn dDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7Jmd0OyB0cmlsbCBtYWlsaW5nIGxpc3Q8 YnI+Jmd0OyZndDsgPC9zcGFuPjxhIGhyZWY9Im1haWx0bzp0cmlsbEBpZXRmLm9yZyI+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+dHJpbGxA aWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyInPjxicj4mZ3Q7Jmd0OyA8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmlsbCI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby90cmlsbDwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PGJyPiZndDsmZ3Q7PGJyPiZndDs8YnI+ Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4m Z3Q7IHRyaWxsIG1haWxpbmcgbGlzdDxicj4mZ3Q7IDwvc3Bhbj48YSBocmVmPSJtYWlsdG86dHJp bGxAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyInPnRyaWxsQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48YnI+Jmd0OyA8L3NwYW4+PGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmlsbCI+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmlsbDwvc3Bhbj48L2E+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PGJyPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPnRyaWxsIG1haWxp bmcgbGlzdDwvc3Bhbj48dT48c3BhbiBzdHlsZT0nY29sb3I6Ymx1ZSc+PGJyPjwvc3Bhbj48L3U+ PGEgaHJlZj0ibWFpbHRvOnRyaWxsQGlldGYub3JnIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz50cmlsbEBpZXRmLm9yZzwvc3Bhbj48L2E+ PHU+PHNwYW4gc3R5bGU9J2NvbG9yOmJsdWUnPjxicj48L3NwYW4+PC91PjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJpbGwiPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdHJpbGw8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxicj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj50cmlsbCBtYWlsaW5nIGxpc3Q8L3Nw YW4+PHU+PHNwYW4gc3R5bGU9J2NvbG9yOmJsdWUnPjxicj48L3NwYW4+PC91PjxhIGhyZWY9Im1h aWx0bzp0cmlsbEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Iic+dHJpbGxAaWV0Zi5vcmc8L3NwYW4+PC9hPjx1PjxzcGFuIHN0 eWxlPSdjb2xvcjpibHVlJz48YnI+PC9zcGFuPjwvdT48YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiQ291cmllciBOZXciJz5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3RyaWxsPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiQ291cmllciBOZXciJz48YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+dHJpbGwgbWFpbGluZyBsaXN0PHU+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsdWUnPjxicj48L3NwYW4+PC91Pjwvc3Bhbj48YSBocmVmPSJtYWlsdG86dHJpbGxA aWV0Zi5vcmciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyInPnRyaWxsQGlldGYub3JnPC9zcGFuPjwvYT48dT48c3BhbiBzdHlsZT0nY29sb3I6 Ymx1ZSc+PGJyPjwvc3Bhbj48L3U+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby90cmlsbCI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Iic+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90 cmlsbDwvc3Bhbj48L2E+IDxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvYm9keT48L2h0bWw+ ------_=_NextPart_002_01CD2716.2AF8B942-- ------_=_NextPart_001_01CD2716.2AF8B942 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.gif Content-Location: image001.gif R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 ------_=_NextPart_001_01CD2716.2AF8B942-- From d3e3e3@gmail.com Mon Apr 30 14:50:22 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A714821E80C3 for ; Mon, 30 Apr 2012 14:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.028 X-Spam-Level: X-Spam-Status: No, score=-103.028 tagged_above=-999 required=5 tests=[AWL=-0.850, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_GIF_ATTACH=1.42, USER_IN_WHITELIST=-100] 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 U2XYP3dIxoSw for ; Mon, 30 Apr 2012 14:50:20 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0BC21E80C0 for ; Mon, 30 Apr 2012 14:50:20 -0700 (PDT) Received: by iazz13 with SMTP id z13so5794234iaz.31 for ; Mon, 30 Apr 2012 14:50:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=vnaDCaKXdxT97sqE5MNUL7sUKmbe5fxXP8VLQ+bKpxY=; b=oXh10lHB/rNHhKDedE1LqcXROxBi8abGB6Pj1RsVhiaClXDSPA2Q3zIfs0/VkLO6Sb 9CQkrQ/sox4Zzde3YQ5QN1KBuD/idwZ9plEKiL+e04w1aI4a9sMb2NLaqyE5Ki4YX1GI 6NKJuOY6y9Cp5moQ3Yq7AmXGDAzEZw9KAoe4OJNKPz91gznTSniaOfx11ouGhSOy83Jl zWommnqp2b3PCrgpmv75Ms8JA4R/W/F+7zrPLy8qWJT83CjSf2UGp2NwNT5E4ULEd32F 9fBM2rMCqw84ourmuIADZvHHnFAd0esR9fdihwrJSD+Is0o1Csw/kqTCz53/LLUuyyrx 7x3Q== Received: by 10.50.89.168 with SMTP id bp8mr11546452igb.3.1335822619733; Mon, 30 Apr 2012 14:50:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.59.201 with HTTP; Mon, 30 Apr 2012 14:49:59 -0700 (PDT) In-Reply-To: <344037D7CFEFE84E97E9CC1F56C5F4A5010A3385@xmb-sjc-214.amer.cisco.com> References: <4F9ACE0E.7030408@sonic.net> <4F9ACF05.9070302@acm.org> <4F9B2697.8080401@acm.org> <344037D7CFEFE84E97E9CC1F56C5F4A5010A2FFF@xmb-sjc-214.amer.cisco.com> <4F9CB95E.4030902@acm.org> <344037D7CFEFE84E97E9CC1F56C5F4A5010A30CC@xmb-sjc-214.amer.cisco.com> <344037D7CFEFE84E97E9CC1F56C5F4A5010A32ED@xmb-sjc-214.amer.cisco.com> <344037D7CFEFE84E97E9CC1F56C5F4A5010A332E@xmb-sjc-214.amer.cisco.com> <344037D7CFEFE84E97E9CC1F56C5F4A5010A3385@xmb-sjc-214.amer.cisco.com> From: Donald Eastlake Date: Mon, 30 Apr 2012 17:49:59 -0400 Message-ID: To: Santosh Rajagopalan Content-Type: multipart/related; boundary=e89a8f3ba959bb6d1e04beec70ed Cc: trill@ietf.org Subject: Re: [trill] TRILL OAM Requirements: available paths X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 21:50:22 -0000 --e89a8f3ba959bb6d1e04beec70ed Content-Type: multipart/alternative; boundary=e89a8f3ba959bb6d1204beec70ec --e89a8f3ba959bb6d1204beec70ec Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Sunny: You may hesitate to call an ECMP implementation subject to polarization defective but I wouldn't hesitate. Polarization is a well known problem. It's easy to avoid with TRILL: An RBridge can just hash in its nickname (or one of its nicknames picked consistently if it has more than one). This seems better than some interface to set a seed or the like. TRILL tries to be minimum configuration and the nickname is known to be unique. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Mon, Apr 30, 2012 at 5:14 PM, Tissa Senevirathne (tsenevir) < tsenevir@cisco.com> wrote: > We are now discussion about sub standard implementations that get to such > polarizations. We should not water down the requirements to cater in sub > standard implementations.**** > > ** ** > > What we should do is to add a requirements such the RBridges have ability > to provide statistical counts on flow distribution over ECMP.**** > > ** ** > > *From:* Santosh Rajagopalan [mailto:sunny.rajagopalan@us.ibm.com] > *Sent:* Monday, April 30, 2012 1:25 PM > *To:* Tissa Senevirathne (tsenevir) > *Cc:* Donald Eastlake; David M Bond; trill@ietf.org; > trill-bounces@ietf.org > > *Subject:* RE: [trill] TRILL OAM Requirements: available paths**** > > ** ** > > When polarization strikes, in the example below, all flows starting from > R1 would use RB12-RB122 (because the hash result was "2" at R1 as well as > at RB12). No flows starting from R1 would ever go along the RB12-RB121 > path. It is common to export an interface for the user to change the seed > to the hash when she detects polarization has occurred: > > > http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9402/white_p= aper_c11-687554.html#wp9000286 > > > > > From: "Tissa Senevirathne (tsenevir)" > To: Santosh Rajagopalan/Santa Clara/IBM@IBMUS > Cc: "Donald Eastlake" , = , > David M Bond/Bedford/IBM@IBMUS, > Date: 04/30/2012 01:14 PM > Subject: RE: [trill] TRILL OAM Requirements: available paths **** > ------------------------------ > > > > > Sunny > > Are we talking about a single flow here or multiple flows ? > > > *From:* trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] > *On Behalf Of *Santosh Rajagopalan* > Sent:* Monday, April 30, 2012 1:05 PM* > To:* Tissa Senevirathne (tsenevir)* > Cc:* Donald Eastlake; trill-bounces@ietf.org; David M Bond; trill@ietf.or= g > * > Subject:* Re: [trill] TRILL OAM Requirements: available paths > > Tissa, > Hash polarization can result in some of the ecmp paths being unutilized. > In Eric's example: > > > R1 > / \ > / \ > / \ > / \ > / \ > RB11 RB12 > / \ / \ > / \ / \ > RB111 RB112 RB121 RB122 > \ \ / / > \ \ / / > \ \/ / > ------R2------ > > If R1 and RB12 use the same hash polynomial & seed, then *all* flows whic= h > arrive at RB12 will go along the link to RB122 - the link to RB121 from > RB12 will never be used. The OAM tool should allow us to figure out this = is > happening, instead of giving us redundant information already available i= n > ISIS lsdb. > I would hesitate to call this a defect. While it is true that a lot of > asics have countermeasures for this (usually by including a random seed a= s > input to the hash polynomial), you cannot rule this out 100%. Please look > at this documentation from a well known networking company ;-) * > * > http://www.cisco.com/en/US/docs/ios/12_4t/ip_mcast/configuration/guide/mc= tlsplt.html#wp1064501 > > -- > Sunny > > > > > From: "Tissa Senevirathne (tsenevir)" > To: David M Bond/Bedford/IBM@IBMUS > Cc: Donald Eastlake , trill-bounces@ietf.org, > trill@ietf.org > Date: 04/30/2012 12:29 PM > Subject: Re: [trill] TRILL OAM Requirements: available paths > Sent by: trill-bounces@ietf.org **** > > ** ** > ------------------------------ > > > > > > Let me start from the basics. > > 1. TRILL is all about multiple active paths. > 2. Multiple active paths are derived from least cost paths to a > specific destinations. > 3. Well defined and implemented Hashing algorithms provide an almos= t > even distribution across all of the available least cost paths to a > destination > 4. If a given flow =93x=94 does not map to a specific least cost p= ath, > does not map to a specific least cost path does not mean another flow =93= y=94 > to the sam destination will not map to the that path. > 5. Well implemented hashing algorithms provide even distribution of > flows. > 6. Hence it is important to have ability to test all available leas= t > cost paths to a destination. > 7. It is an implementation defect, If there is an implementation ou= t > there which does not hash flows (over a longer sampling period) in to a > specific =93least cost path=94 of set of least cost paths to a destinatio= n, > among all available =93least cost paths=94 to that destination. > * > From:* David M Bond [mailto:dmbond@us.ibm.com ] * > Sent:* Monday, April 30, 2012 8:39 AM* > To:* Tissa Senevirathne (tsenevir)* > Cc:* Donald Eastlake; trill@ietf.org; trill-bounces@ietf.org* > Subject:* Re: [trill] TRILL OAM Requirements: available paths > **** > > Just a question coming from this conversation that I want to clarify: > > So we have 'all possible paths' (1) which could include non-least cost > paths and so of course we don't want to use this definition. > > Then we have 'all ecmp paths' or 'all least cost paths' (2) which MAY > include paths never chosen by a transit Rbridge because of the local > hashing choices. > > Then we have 'all the least cost paths which may be chosen given the > hashing implementation on the local Rbridges' (3). > > I wonder if choice (2) is useful or do we only really care about choice > (3). For instance, if you have 16 equal cost paths from A to B and your > hashing only will ever use 2 of those paths do we care about reporting ba= ck > ecmp paths that will never in practice be used? Perhaps the definition > should be tightened to only require determination of all least cost paths > that could be used given the local hashing implementation. Or am I > misunderstanding the conversation and is this already the point being mad= e > between theoretical paths and least cost paths. > > Thanks, > David > > [image: Inactive hide details for "Tissa Senevirathne (tsenevir)" > ---04/29/2012 11:43:07 PM---I like that Donald.. We can use "all leas]"Ti= ssa > Senevirathne (tsenevir)" ---04/29/2012 11:43:07 PM---I like that Donald.. > We can use "all least cost paths", that is technically more precise and > represe > > From: "Tissa Senevirathne (tsenevir)" > To: "Donald Eastlake" , > Date: 04/29/2012 11:43 PM > Subject: Re: [trill] TRILL OAM Requirements: available paths > Sent by: trill-bounces@ietf.org **** > > ** ** > ------------------------------ > > > > > > > I like that Donald.. We can use "all least cost paths", that is > technically more precise and represent exactly what IS-IS does. > > Thanks > Tissa > > -----Original Message----- > From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] > On Behalf Of Donald Eastlake > Sent: Sunday, April 29, 2012 6:27 PM > To: trill@ietf.org > Subject: Re: [trill] TRILL OAM Requirements: available paths > > I don't think the wording "all paths" should ever be used. If you the it > literally, it would even include paths that go through some RBridges more > than once. > > I don't particularly like "all ECMP paths" either. I think the clearest > wording is "all least cost paths" if you are talking about known unicast. > (And "all distribution tree paths" if you were talking about > multi-destination frames.) > > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA* > *d3e3e3@gmail.com > > > On Sat, Apr 28, 2012 at 11:45 PM, Erik Nordmark wrote: > > On 4/27/12 5:12 PM, Tissa Senevirathne (tsenevir) wrote: > >> > >> Of course it is possible. The IS-IS topology table provide the > >> information on all available ECMP paths to a specific destination > >> when the egress RBRidge nickname is known. That is what TRILL unicast > >> forwarding table all about. Not sure why you are saying it is not > >> possible to know all ECMP paths. > > > > > > You are talking about what Santosh called "all theoretically available > > paths". Those can be determined from IS-IS. > > > > But the document talks about "all available paths" and I don't know > > what that is supposed to mean. Do you have a succinct definition? > > > > What is clear to me is that there can be a subset of the paths that > > are determined from IS-IS that would never be used, because no entropy > > in a packet would every pick that path. > > > > Is the requirement in the document that the OAM solution should be > > able to test those paths? > > > > > >> What path among available paths to be selected for a specified is a > >> local matter. That is what all about flow entropy discovery. Like I > >> stated earlier how it is discovered is a framework and solution issue. > > > > > > Agreed. > > > > > >> If you need some reference how it is done in the MPLS world RFC 4379 > >> is a good reference. > > > > > > AFAIK MPLS doesn't have a locally defined ECMP hash function in every > hop. > > TRILL does, which makes these aspects different. > > > > Regards, > > Erik > > > > > >> -----Original Message----- > >> From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] > On > >> Behalf Of Erik Nordmark > >> Sent: Friday, April 27, 2012 4:07 PM > >> To: Santosh Rajagopalan > >> Cc: trill@ietf.org > >> Subject: Re: [trill] TRILL OAM Requirements: available paths > >> > >> On 4/27/12 2:15 PM, Santosh Rajagopalan wrote: > >>> > >>> I agree, the wording needs to be tightened to say "all possible ecmp > >>> paths" rather than "all available paths". An operator working out > >>> R1-R2 communication is interested in all possible paths data traffic > >>> could take rather than all theoretically available paths. > >> > >> > >> The issue is that there is nothing in the TRILL dataplane nor IS-IS > >> control plane which helps the operator determine that some paths > >> (through RB121 and RB112 in the example) are not possible; the ECMP > >> input and hashing is a completely local matter on each RBridge. > >> > >> It isn't useful to state a requirement around something that can't be > >> determined. > >> > >> Erik > >> > >>> > >>> > >>> From: Erik Nordmark > >>> To: trill@ietf.org > >>> Date: 04/27/2012 09:53 AM > >>> Subject: [trill] TRILL OAM Requirements: available paths Sent by: > >>> trill-bounces@ietf.org > >>> -------------------------------------------------------------------- > >>> -- > >>> -- > >>> > >>> > >>> > >>> > >>> Two requirements use the wording "all available paths." and "all > >>> available ECMP paths.", respectively and I'm not sure I know what > >>> that > >> > >> > >>> means. > >>> > >>> Take the following example picture: > >>> > >>> R1 > >>> / \ > >>> / \ > >>> / \ > >>> / \ > >>> / \ > >>> RB11 RB12 > >>> / \ / \ > >>> / \ / \ > >>> RB111 RB112 RB121 RB122 > >>> \ \ / / > >>> \ \ / / > >>> \ \/ / > >>> ------R2------ > >>> > >>> We can see that there are 4 paths with 3 hops to get from R1 to R2, > >>> with two layers of ECMP decisions. But how many available paths are > >> > >> there? > >>> > >>> > >>> Given that the RBridges make independent ECMP decisions, and how > >>> they do that is a local matter, it could be the case that for any > >>> packet, if R1 picks the left link, then R11 would also pick the left > >>> link; if > >>> R1 picks the right link, then R12 also picks the right link. > >>> Thus there would be no packet (data or OAM) that would cause packets > >>> between R1 and R2 to pass via RB112 or RB121. > >>> > >>> Even if we ignore that as unlikely, there is still the fact that R1 > >>> can't easily tell how many (shortest) paths there might be between > >>> it and R2. With single-level TRILL the LSDB could be used to tell, > >>> but if > >> > >> > >>> we ever go to multi-level that wouldn't be the case any more. > >>> And even if R1 knows that there are 4 potential paths, it can't > >>> format > >> > >> > >>> a data packet (or format the flow entropy in an OAM packet) in such > >>> a way that particular paths get chosen by downstream ECMP decisions. > >>> > >>> Thus for any notion of "all available paths" that make sense to me, > >>> we'd need an OAM approach that can explore the topology one hop at a > >>> time and at each hop explore all the possible ECMP choices. Using > >>> the entropy doesn't help with this (but the entropy is critical for > >>> following the path taken by a particular flow of data packets). > >>> > >>> Hence it would be good to clarify what the assumptions are behind > >>> this > >> > >> > >>> notion of all available paths. > >>> > >>> Thanks, > >>> Erik > >>> > >>> _______________________________________________ > >>> trill mailing list > >>> trill@ietf.org > >>> https://www.ietf.org/mailman/listinfo/trill > >>> > >>> > >> > >> _______________________________________________ > >> trill mailing list > >> trill@ietf.org > >> https://www.ietf.org/mailman/listinfo/trill > >> > > > > _______________________________________________ > > trill mailing list > > trill@ietf.org > > https://www.ietf.org/mailman/listinfo/trill > _______________________________________________ > trill mailing list* > *trill@ietf.org* > *https://www.ietf.org/mailman/listinfo/trill > _______________________________________________ > trill mailing list* > *trill@ietf.org* > *https://www.ietf.org/mailman/listinfo/trill > _______________________________________________ > trill mailing list* > *trill@ietf.org* > *https://www.ietf.org/mailman/listinfo/trill **** > --e89a8f3ba959bb6d1204beec70ec Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Sunny:

You may hesitate to call an ECMP implementation s= ubject to polarization defective but I wouldn't hesitate.=A0Polarizatio= n is a well known problem.=A0It's easy to avoid with TRILL: An RBridge = can just hash in its nickname (or one of its nicknames picked consistently = if it has more than one). This seems better than some interface to set a se= ed or the like. TRILL tries to be minimum configuration and the nickname is= known to be unique.

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=A0Donald E. E= astlake 3rd=A0=A0 +1-508-333-2270 (cell)
=A0155 Beaver Street,=A0Milford= , MA 01757 USA
=A0= d3e3e3@gmail.com


On Mon, Apr 30, 2012 at 5:14 PM, Tissa S= enevirathne (tsenevir) <tsenevir@cisco.com> wrote:

We are now discussion about sub standard imp= lementations that get to such polarizations. =A0We should not water down th= e requirements to cater in sub standard implementations.

=A0<= /p>

What we should do is t= o add a requirements such the RBridges have ability to provide statistical = counts on =A0flow distribution over ECMP.

=A0<= /p>

From: Santosh = Rajagopalan [mailto:sunny.rajagopalan@us.ibm.com]
Sent: Monday, April 30, 2012 1:25 PM
To: Tissa Senevirathn= e (tsenevir)
Cc: Donald Eastlake; David M Bond; trill@ietf.org; trill-bounces@ietf.org


Subject: RE: [trill] TRILL OAM Requiremen= ts: available paths

=A0

= When polarization strikes, in the example below, all flows start= ing from R1 would use RB12-RB122 (because the hash result was "2"= at R1 as well as at RB12). No flows starting from R1 would ever go along t= he =A0RB12-RB121 path. It is common to export an interface for the user to = change the seed to the hash when she detects polarization has occurred:

http://www.c= isco.com/en/US/prod/collateral/switches/ps9441/ps9402/white_paper_c11-68755= 4.html#wp9000286




From: =A0 =A0 =A0 =A0"Tissa Senevirathne (tsenevir)" <tsenevir@cisco.com>
To: =A0 =A0 =A0 =A0Santosh Rajagop= alan/Santa Clara/IBM@IBMUS
Cc: =A0 =A0 =A0 =A0"Donald Ea= stlake" <d3e3= e3@gmail.com>, <trill-bounces@ietf.org>, David M Bond/Bedford/IBM@IBMUS,= <trill@ietf.org= >
Date: =A0 =A0 =A0 =A004/30/2012 01= :14 PM
Subject: =A0 =A0 =A0 =A0RE: [trill= ] TRILL OAM Requirements: available paths

<= /div>




Sunny
=A0
Are we= talking about a single flow here or multiple flows ?
=A0
=A0
From: trill-bounces@ietf.org [mailto:trill-b= ounces@ietf.org] On Behalf Of Santosh Rajagop= alan
Sent: Monday, April 30, 2012 1:05 PM
To: Tissa Senevirathne (= tsenevir)
Cc: Donald Eastlake; trill-bounces@ietf.org; David M Bond; trill@ietf.org
Subject: Re: [trill] TRILL OAM Requirements: available paths =A0
Tissa,
Hash polarization can result in some of the ecmp paths being unutilized. In= Eric's example:


=A0 =A0 =A0 =A0 =A0 =A0 =A0 R1
=A0 =A0= =A0 =A0 =A0 =A0 =A0/ =A0\
=A0 =A0 =A0 =A0 =A0 =A0 / =A0 =A0\
=A0 =A0 =A0 =A0 =A0 =A0/ =A0 =A0 =A0\=
=A0 =A0 =A0 =A0 =A0 / =A0 =A0 =A0 =A0\
=A0 =A0 =A0 =A0 =A0/ =A0 =A0 = =A0 =A0 =A0\
=A0 =A0 =A0 RB11 =A0 =A0 =A0 =A0 =A0RB12
=A0 =A0 =A0 / = =A0\ =A0 =A0 =A0 =A0 =A0/ =A0\
=A0 =A0 =A0/ =A0 =A0\ =A0 =A0 =A0 =A0/ = =A0 =A0\
=A0 RB111 =A0RB112 =A0RB121 =A0RB122
=A0 =A0 =A0\ =A0 =A0 = =A0\ =A0 =A0/ =A0 =A0 =A0/
=A0 =A0 =A0 \ =A0 =A0 =A0\ =A0/ =A0 =A0 =A0/
=A0 =A0 =A0 =A0\ =A0 =A0 = =A0\/ =A0 =A0 =A0/
=A0 =A0 =A0 =A0 ------R2------
=
If R1 and RB12 use the same hash polynomial & seed, then *all* flow= s which arrive at RB12 will go along the link to RB122 - the link to RB121 = from RB12 will never be used. The OAM tool should allow us to figure out th= is is happening, instead of giving us redundant information already availab= le in ISIS lsdb.
I would hesitate to call this a defect. While it is true that a lot of asic= s have countermeasures for this (usually by including a random seed as inpu= t to the hash polynomial), you cannot rule this out 100%. Please look at th= is documentation from a well known networking company ;-)
http://www.cis= co.com/en/US/docs/ios/12_4t/ip_mcast/configuration/guide/mctlsplt.html#wp10= 64501

--
Sunny




From: =A0 =A0 =A0 =A0"Tissa Senevirathne (tsenevir)&q= uot; <tsenevir@cisco.com>
To: =A0 =A0 =A0 =A0David M Bond/Bedford/IBM@IBMUS <= span style=3D"font-size:7.5pt;font-family:"Arial","sans-seri= f";color:#5f5f5f">
Cc: =A0 =A0 =A0 =A0Donald Eastlake <d3e3e3@gmail.com= >, trill-bounces@ietf.org, <= a href=3D"mailto:trill@ietf.org" target=3D"_blank">trill@ietf.org=
Date: =A0 =A0 =A0 =A004/30/2012 12:29 PM
Subject: =A0 =A0 =A0 =A0Re: [trill] TRILL OAM Requirements= : available paths
Sent by: =A0 =A0 =A0 =A0trill-bounces@ietf.org <= /p>

=A0





Let me start from the basics.
= =A0
1. =A0 =A0 =A0 TRILL is all about multiple active paths.
2. =A0 =A0 =A0 Multiple active paths are derived from l= east cost paths to a specific destinations.
3. =A0 =A0 =A0 Well defined and implemented Hashing algorithms provide an a= lmost even distribution across all of the available least cost paths to a d= estination
4. =A0 =A0 =A0 If a given flow =93x=94 does not map to =A0a specific least = cost path, does not map to a specific least cost path does not mean another= flow =93y=94 to the sam destination will not map to the that path.
5. = =A0 =A0 =A0 Well implemented hashing algorithms provide even distribution o= f flows.
6. =A0 =A0 =A0 Hence it is important to have ability to test all available = least cost paths to a destination.
7.= =A0 =A0 =A0 It is an implementation defect, If there is an implementation = out there which does not hash flows (over a longer sampling period) =A0in t= o a specific =93least cost path=94 of set of least cost paths to a destinat= ion, among all available =93least cost paths=94 to that destination.=
=A0
From: David M Bond [mail= to:dmbond@us.ibm.com]
Sent: Monday, April 30, 2012 8:39 AM
To: Tissa Senevirathne (= tsenevir)
Cc: Donald Eastlake; trill@ietf.org; trill-bounces@ietf.org
Subject: Re: [trill] TRILL OAM Requirements: availab= le paths
=A0

Just a question com= ing from this conversation that I want to clarify:

So we have 'all possible paths' (1) which could include non-lea= st cost paths and so of course we don't want to use this definition.
Then we have 'all ecmp paths' or 'all least cost paths'= ; (2) which MAY include paths never chosen by a transit Rbridge because of = the local hashing choices.

Then we have 'all the least cost paths which may be chosen given th= e hashing implementation on the local Rbridges' (3).

I wonder if= choice (2) is useful or do we only really care about choice (3). For insta= nce, if you have 16 equal cost paths from A to B and your hashing only will= ever use 2 of those paths do we care about reporting back ecmp paths that = will never in practice be used? Perhaps the definition should be tightened = to only require determination of all least cost paths that could be used gi= ven the local hashing implementation. Or am I misunderstanding the conversa= tion and is this already the point being made between theoretical paths and= least cost paths.

Thanks,
David

3D"Inactive&= quot;Tissa Senevirathne (tsenevir)" ---04/29/2012 11:43:07 PM---I like= that Donald.. We can use "all least cost paths", that is technic= ally more precise and represe

From: "Tissa Senevirathne (tsenevir)" <tsen= evir@cisco.com>
To: "Donald Eastlake" <d3e3e3@gmail.com>, <trill@ietf.org><= br> Date: 04/29/2012 11:43 PM
Subject: = Re: [trill] TRILL OAM Requirements: available paths
Sent by: trill-bounces@ietf.org

= =A0






I like that Donald.. We can use "= all least cost paths", that is technically more precise and represent = exactly what IS-IS does.

Thanks
Tissa

-----Original Message-----
From: trill-bounces@ietf.org [mailto:tril= l-bounces@ietf.org] On Behalf Of Donald Eastlake
Sent: Sunday, April 29, 2012 6:27 PM
To: trill@ietf.org
Subject: Re: [trill] TRILL OAM Requirements: available paths

I don&#= 39;t think the wording "all paths" should ever be used. If you th= e it literally, it would even include paths that go through some RBridges m= ore than once.

I don't particularly like "all ECMP paths" either. I thin= k the clearest wording is "all least cost paths" if you are talki= ng about known unicast. (And "all distribution tree paths" if you= were talking about multi-destination frames.)

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Donald E. Eastlake 3rd =A0 +1-50= 8-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 USA=
d3e3e3@gmail.com=


On Sat, Apr 28, 2012 at 11:45 PM, Erik Nordmark <nordmark@acm.org> wrote: > On 4/27/12 5:12 PM, Tissa Senevirathne (tsenevir) wrote:
>>>> Of course it is possible. The IS-IS topology table provide the <= br>>> information on all available ECMP paths to a specific destinati= on
>> when the egress RBRidge nickname is known. That is what TRILL unic= ast
>> forwarding table all about. Not sure why you are saying it= is not
>> possible to know all ECMP paths.
>
>
> You are talking about what Santosh called "all theoretically avai= lable
> paths". Those can be determined from IS-IS.
>
= > But the document talks about "all available paths" and I don= 't know
> what that is supposed to mean. Do you have a succinct definition?
&= gt;
> What is clear to me is that there can be a subset of the paths = that
> are determined from IS-IS that would never be used, because n= o entropy
> in a packet would every pick that path.
>
> Is the require= ment in the document that the OAM solution should be
> able to test = those paths?
>
>
>> What path among available paths to= be selected for a specified is a
>> local matter. That is what all about flow entropy discovery. Like = I
>> stated earlier how it is discovered is a framework and solut= ion issue.
>
>
> Agreed.
>
>
>> If y= ou need some reference how it is done in the MPLS world RFC 4379
>> is a good reference.
>
>
> AFAIK MPLS doesn'= t have a locally defined ECMP hash function in every hop.
> TRILL doe= s, which makes these aspects different.
>
> Regards,
> = =A0 Erik
>
>
>> -----Original Message-----
>> From: trill-bounces@iet= f.org [ma= ilto:trill-bounces@ietf.org] On
>> Behalf Of Erik Nordmark
>> Sent: Friday, April 27, 2012 4= :07 PM
>> To: Santosh Rajagopalan
>> Cc: trill@ietf.org
>> Subject: Re: [trill] TRILL OAM Requirements: available paths
&g= t;>
>> On 4/27/12 2:15 PM, Santosh Rajagopalan wrote:
>&g= t;>
>>> I agree, the wording needs to be tightened to say &q= uot;all possible ecmp
>>> paths" rather than "all available paths". An op= erator working out
>>> R1-R2 communication is interested in all= possible paths data traffic
>>> could take rather than all th= eoretically available paths.
>>
>>
>> The issue is that there is nothing in the = TRILL dataplane nor IS-IS
>> control plane which helps the operat= or determine that some paths
>> (through RB121 and RB112 in the e= xample) are not possible; the ECMP
>> input and hashing is a completely local matter on each RBridge.>>
>> It isn't useful to state a requirement around som= ething that can't be
>> determined.
>>
>> = =A0 =A0 Erik
>>
>>>
>>>
>>> From: Erik Nordmar= k<nordmark@acm.or= g>
>>> To: trill= @ietf.org
>>> Date: 04/27/2012 09:53 AM
>>> Subject: [trill] TRI= LL OAM Requirements: available paths Sent by:
>>> trill-bounces@ietf.org=
>>> --------------------------------------------------------------= ------
>>> --
>>> --
>>>
>>>= ;
>>>
>>>
>>> Two requirements use the = wording "all available paths." and "all
>>> available ECMP paths.", respectively and I'm not sure= I know what
>>> that
>>
>>
>>> = means.
>>>
>>> Take the following example picture:<= br> >>>
>>> R1
>>> / \
>>> / \
= >>> / \
>>> / \
>>> / \
>>> RB= 11 RB12
>>> / \ / \
>>> / \ / \
>>> RB1= 11 RB112 RB121 RB122
>>> \ \ / /
>>> \ \ / /
>>> \ \/ /
>= >> ------R2------
>>>
>>> We can see that the= re are 4 paths with 3 hops to get from R1 to R2,
>>> with two = layers of ECMP decisions. But how many available paths are
>>
>> there?
>>>
>>>
>>>= Given that the RBridges make independent ECMP decisions, and how
>&= gt;> they do that is a local matter, it could be the case that for any <= br> >>> packet, if R1 picks the left link, then R11 would also pick th= e left
>>> link; if
>>> R1 picks the right link, t= hen R12 also picks the right link.
>>> Thus there would be no p= acket (data or OAM) that would cause packets
>>> between R1 and R2 to pass via RB112 or RB121.
>>><= br>>>> Even if we ignore that as unlikely, there is still the fact= that R1
>>> can't easily tell how many (shortest) paths t= here might be between
>>> it and R2. With single-level TRILL the LSDB could be used to t= ell,
>>> but if
>>
>>
>>> we eve= r go to multi-level that wouldn't be the case any more.
>>>= And even if R1 knows that there are 4 potential paths, it can't
>>> format
>>
>>
>>> a data packet (= or format the flow entropy in an OAM packet) in such
>>> a way= that particular paths get chosen by downstream ECMP decisions.
>>= >
>>> Thus for any notion of "all available paths" that ma= ke sense to me,
>>> we'd need an OAM approach that can exp= lore the topology one hop at a
>>> time and at each hop explor= e all the possible ECMP choices. Using
>>> the entropy doesn't help with this (but the entropy is cri= tical for
>>> following the path taken by a particular flow of= data packets).
>>>
>>> Hence it would be good to c= larify what the assumptions are behind
>>> this
>>
>>
>>> notion of all ava= ilable paths.
>>>
>>> Thanks,
>>> Erik<= br>>>>
>>> ___________________________________________= ____
>>> trill mailing list
>>> trill@ietf.org
>>> https://www.ietf.org/mailman/listinfo/trill
>>>
>>>
>>
>> ______________________= _________________________
>> trill mailing list
>> trill@ietf.org
>> https://www.ietf.org/mailman/listinfo/trill
>>
>
> _______________________________________________> trill mailing list
> trill@ietf.org
> https://www.ietf.org/mailman/listinfo/trill
_______________________________________________
trill mailing list
trill@ietf.org https://www.ietf.org/mailman/listinfo/trill
_______________________________________________
trill mailing list
trill@ietf.org https://www.ietf.org/mailman/listinfo/trill
_______________________________________________
trill mailing list
trill@ietf.org https://www.ietf.org/mailman/listinfo/trill =


--e89a8f3ba959bb6d1204beec70ec-- --e89a8f3ba959bb6d1e04beec70ed Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 2c58cc6817cd85bb_0.1 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --e89a8f3ba959bb6d1e04beec70ed--