From rbridge-bounces@postel.org Wed Feb 1 11:43:11 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 63AE911E8071 for ; Wed, 1 Feb 2012 11:43:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 muHYux0VDfIT for ; Wed, 1 Feb 2012 11:43:10 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id C914C11E80BA for ; Wed, 1 Feb 2012 11:43:10 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q11JVkcI000790; Wed, 1 Feb 2012 11:31:47 -0800 (PST) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q11JVHFM000730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 1 Feb 2012 11:31:26 -0800 (PST) Received: from sjc-vpn6-1304.cisco.com (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 q11JVFB9028644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Feb 2012 11:31:15 -0800 Message-ID: <4F299302.3000804@acm.org> Date: Wed, 01 Feb 2012 11:31:14 -0800 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "rbridge@postel.org" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: nordmark@acm.org Subject: [rbridge] WG last call of draft-ietf-trill-rbridge-extension-02 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 Last year we had a last call on draft-ietf-trill-rbridge-options, and that resulted in separating out the minimum set of flags and associated behavior into a this extensions document. The WG last call ends on Feb 15th. Please send comments (including ones that say you've read the document and it is fine) to the rbridge list. Erik _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge From rbridge-bounces@postel.org Wed Feb 1 12:04: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 83A9811E80A4 for ; Wed, 1 Feb 2012 12:04:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 KkfjIpBgtXtV for ; Wed, 1 Feb 2012 12:04:21 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id A286811E80BA for ; Wed, 1 Feb 2012 12:04:21 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q11JQjLj029796; Wed, 1 Feb 2012 11:26:46 -0800 (PST) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q11JQ0KD029673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 1 Feb 2012 11:26:09 -0800 (PST) Received: from sjc-vpn6-1304.cisco.com (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 q11JPwIX024817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Feb 2012 11:25:58 -0800 Message-ID: <4F2991C6.7070904@acm.org> Date: Wed, 01 Feb 2012 11:25:58 -0800 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "rbridge@postel.org" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: nordmark@acm.org Subject: [rbridge] WG last call of draft-ietf-trill-rbridge-channel-03 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 We're starting three separate last calls this week, but they are all very short documents. We had an earlier WG last call on this document 6 months ago, and there were some concerns about using the IS-IS genapp mechanism, so that use has been removed. The WG last call ends on Feb 15th. Please send comments (including ones that say you've read the document and it is fine) to the rbridge list. Erik _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge From rbridge-bounces@postel.org Wed Feb 1 12:11: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 53F7C21F8796 for ; Wed, 1 Feb 2012 12:11:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 V7EJoXPXYPTs for ; Wed, 1 Feb 2012 12:11:29 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id B963B21F86E2 for ; Wed, 1 Feb 2012 12:11:29 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q11JjG38003272; Wed, 1 Feb 2012 11:45:17 -0800 (PST) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q11Jiv17003210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 1 Feb 2012 11:45:06 -0800 (PST) Received: from sjc-vpn6-1304.cisco.com (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 q11Jis55026822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Feb 2012 11:44:55 -0800 Message-ID: <4F299636.7060604@acm.org> Date: Wed, 01 Feb 2012 11:44:54 -0800 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "rbridge@postel.org" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: nordmark@acm.org Subject: [rbridge] WG last call on draft-ietf-trill-rbridge-bfd-02 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 The WG last call ends on Feb 15th. Please send comments (including ones that say you've read the document and it is fine) to the rbridge list. Erik _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge From rbridge-bounces@postel.org Wed Feb 1 17:54:06 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 B94B811E80AD for ; Wed, 1 Feb 2012 17:54:06 -0800 (PST) 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 kYecw8HCoiNL for ; Wed, 1 Feb 2012 17:54:06 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 307DD11E8087 for ; Wed, 1 Feb 2012 17:54:06 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q121YOD6006668; Wed, 1 Feb 2012 17:34:25 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q121Xh4S006564 for ; Wed, 1 Feb 2012 17:33:53 -0800 (PST) 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 <0LYQ00CEQSC5B9@szxga04-in.huawei.com> for rbridge@postel.org; Thu, 02 Feb 2012 09:33:42 +0800 (CST) Received: from szxrg02-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 <0LYQ00I4PSC5LL@szxga04-in.huawei.com> for rbridge@postel.org; Thu, 02 Feb 2012 09:33:41 +0800 (CST) Received: from szxeml212-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGT04827; Thu, 02 Feb 2012 09:33:41 +0800 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by szxeml212-edg.china.huawei.com (172.24.2.181) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 02 Feb 2012 09:32:48 +0800 Received: from l63746 (10.138.41.136) by smtpscn.huawei.com (10.82.67.162) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 02 Feb 2012 09:33:52 +0800 Date: Thu, 02 Feb 2012 09:33:02 +0800 From: Yizhou Li In-reply-to: <4F2991C6.7070904@acm.org> X-Originating-IP: [10.138.41.136] To: "'Erik Nordmark'" , rbridge@postel.org Message-id: <012b01cce14a$9b0dbca0$d12935e0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-language: zh-cn Thread-index: AczhHJ8CSzdzPP4tTke+atptkAD6dQALeSnQ X-CFilter-Loop: Reflected References: <4F2991C6.7070904@acm.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: liyizhou@huawei.com Subject: Re: [rbridge] WG last call of draft-ietf-trill-rbridge-channel-03 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 The latest version should be 04. Yizhou -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Erik Nordmark Sent: Thursday, February 02, 2012 3:26 AM To: rbridge@postel.org Subject: [rbridge] WG last call of draft-ietf-trill-rbridge-channel-03 We're starting three separate last calls this week, but they are all very short documents. We had an earlier WG last call on this document 6 months ago, and there were some concerns about using the IS-IS genapp mechanism, so that use has been removed. The WG last call ends on Feb 15th. Please send comments (including ones that say you've read the document and it is fine) to the rbridge list. Erik _______________________________________________ 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 Feb 1 20:19:28 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 D023311E8083 for ; Wed, 1 Feb 2012 20:19:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 LKyZ5q0KlN0K for ; Wed, 1 Feb 2012 20:19:28 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 3B89211E807F for ; Wed, 1 Feb 2012 20:19:28 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1240wrh026342; Wed, 1 Feb 2012 20:00:59 -0800 (PST) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1240gIj026317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 1 Feb 2012 20:00:50 -0800 (PST) Received: from sjc-vpn6-1304.cisco.com (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 q1240asX019555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Feb 2012 20:00:36 -0800 Message-ID: <4F2A0A63.30907@acm.org> Date: Wed, 01 Feb 2012 20:00:35 -0800 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Yizhou Li References: <4F2991C6.7070904@acm.org> <012b01cce14a$9b0dbca0$d12935e0$@com> In-Reply-To: <012b01cce14a$9b0dbca0$d12935e0$@com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: nordmark@acm.org Cc: rbridge@postel.org, "'Erik Nordmark'" Subject: Re: [rbridge] WG last call of draft-ietf-trill-rbridge-channel-04 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 2/1/12 5:33 PM, Yizhou Li wrote: > The latest version should be 04. Yes. Thanks for the correction. Erik > Yizhou > > -----Original Message----- > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Erik Nordmark > Sent: Thursday, February 02, 2012 3:26 AM > To: rbridge@postel.org > Subject: [rbridge] WG last call of draft-ietf-trill-rbridge-channel-03 > > > We're starting three separate last calls this week, but they are all > very short documents. > > We had an earlier WG last call on this document 6 months ago, and there > were some concerns about using the IS-IS genapp mechanism, so that use > has been removed. > > The WG last call ends on Feb 15th. > Please send comments (including ones that say you've read the document > and it is fine) to the rbridge list. > > Erik > > _______________________________________________ > 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 Mon Feb 6 03:34:48 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 6F4EF21F862D for ; Mon, 6 Feb 2012 03:34:48 -0800 (PST) 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 NUgN7IVsohyP for ; Mon, 6 Feb 2012 03:34:47 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id C5CD321F85C3 for ; Mon, 6 Feb 2012 03:34:47 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q16BL61Y009248; Mon, 6 Feb 2012 03:21:08 -0800 (PST) Received: from mail-bk0-f52.google.com (mail-bk0-f52.google.com [209.85.214.52]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q16BKaCl009196 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 6 Feb 2012 03:20:46 -0800 (PST) Received: by bkar19 with SMTP id r19so7708826bka.39 for ; Mon, 06 Feb 2012 03:20:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=4k0e+gfMQPBoUlOdiA9MLEXsjvVBo1s6jMmwVznFtO4=; b=ifIWHNtUKb2JtDCq4utog8gmu0c9Eo5LcPbKDq4b2Ur7XYEf0DLx34o/pKnvDeC8eo 1XSU9BSlsZbrumrkvP5pibaVuRYHyozvQlsJCQdH42saxj8ff1ukNf23HRdTfK6gCIks APf+JX15Oa2F1r9VcYYSn4fOK8Y+7YT1jAAEU= MIME-Version: 1.0 Received: by 10.204.136.220 with SMTP id s28mr8392576bkt.59.1328527235751; Mon, 06 Feb 2012 03:20:35 -0800 (PST) Received: by 10.204.149.218 with HTTP; Mon, 6 Feb 2012 03:20:35 -0800 (PST) Date: Mon, 6 Feb 2012 16:50:35 +0530 Message-ID: From: Abhinav Bhatia To: rbridge@postel.org X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: nitks.abhinav@gmail.com Subject: [rbridge] Query Reg: RBridges: The ESADI Protocol 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="===============0564424801==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org --===============0564424801== Content-Type: multipart/alternative; boundary=0015175cffe8f61e3204b849d953 --0015175cffe8f61e3204b849d953 Content-Type: text/plain; charset=ISO-8859-1 Hi, I have queries related to esadi protocol draft . 1) In the draft : *"In this state, the Holding Timer will be recycled if the timer is expired or the found neighbor has a higher priority than the local priority."* I could not understand the above line, i think it should something like*: "In this state, the Holding Timer will be recycled every time an lsp is received with higher priority"* 2) ESADI will only help in fast updates of end station addresses, It will not help in the initial learning of macs by RBrides the encapsulation and decapitation. Please correct me if i am wrong. Thanks and Regards, Abhinav --0015175cffe8f61e3204b849d953 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I have queries related to esadi protocol draft <draft-hu-tril= l-rbridge-esadi-01.txt>.

1) In the draft : "In this state= , the Holding Timer will be recycled if the timer is expired or the found n= eighbor has a higher priority than the local priority."

=A0=A0=A0=A0 I could not understand the above line, i think it should= =A0 something like: "In this state,=A0 the Holding Timer will be re= cycled every time an lsp is received with higher priority"

= 2) ESADI will only help in fast updates of end station=A0 addresses, It wil= l not help in the initial learning of macs by RBrides the encapsulation and= decapitation.

Please correct me if i am wrong.

Thanks and Regards,
Abhinav<= br> --0015175cffe8f61e3204b849d953-- --===============0564424801== 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 --===============0564424801==-- From rbridge-bounces@postel.org Tue Feb 7 04:47: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 271B721F8745 for ; Tue, 7 Feb 2012 04:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.94 X-Spam-Level: X-Spam-Status: No, score=-100.94 tagged_above=-999 required=5 tests=[AWL=3.502, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 bd5CAsbbh74p for ; Tue, 7 Feb 2012 04:47:12 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC0E21F86EA for ; Tue, 7 Feb 2012 04:47:11 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q17C5N5o020185; Tue, 7 Feb 2012 04:05:25 -0800 (PST) Received: from mx7.zte.com.cn (mx7.zte.com.cn [202.103.147.169]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q17C4hc2020093 for ; Tue, 7 Feb 2012 04:04:53 -0800 (PST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 5467.3216957456; Tue, 7 Feb 2012 20:04:39 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q17C4Y92065583; Tue, 7 Feb 2012 20:04:34 +0800 (GMT-8) (envelope-from zhai.hongjun@zte.com.cn) In-Reply-To: To: Abhinav Bhatia MIME-Version: 1.0 X-KeepSent: 174AC294:C052862A-4825799D:00415D39; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhai.hongjun@zte.com.cn Date: Tue, 7 Feb 2012 20:04:36 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-02-07 20:04:36, Serialize complete at 2012-02-07 20:04:36 X-MAIL: mse01.zte.com.cn q17C4Y92065583 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: zhai.hongjun@zte.com.cn Cc: rbridge@postel.org, Donald Eastlake , Radia Perlman , hu.fangwei@zte.com.cn Subject: Re: [rbridge] rbridge Digest, Vol 93, Issue 3 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="===============1332407372==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org This is a multipart message in MIME format. --===============1332407372== Content-Type: multipart/alternative; boundary="=_alternative 00428B324825799D_=" This is a multipart message in MIME format. --=_alternative 00428B324825799D_= Content-Type: text/plain; charset="US-ASCII" Hi Abhinav > 1) In the draft : *"In this state, the Holding Timer will be recycled if > the timer is expired or the found neighbor has a higher priority than the > local priority."* I think this sentence is some confusing, so I try to give a clearer explanation of the above line. The cyclic Holding Timer is mainly used to trigger the DRB election process for the ESADI instances being in Not-DRB state. If this timer expires, the state of this ESADI moves from Not-DRB to DRB. In order to fasten the election process, this timer is started in Initial state. The timer may expire, if so, it will also be recycled in Initial state. On an ESADI virtual link, only the ESADI RBridge that has the highest priority (with IS-IS system ID as ties breaking) is finally elected as DRB. If receiving an ESADI-LSP number zero from a neighbor with higher priority than the local priority, the local ESADI instance can not become DRB finally. Therefore, recycling this timer by such an ESADI instance can reduce the possibility of the ESADI instance entering into DRB state if such a neighbor is found. > I could not understand the above line, i think it should something > like*: "In this state, the Holding Timer will be recycled every time an > lsp is received with higher priority"* For an ESADI instance in Initial state, it will leave this state and enter into Not-DRB state as long as it find a valid neighbor by receiving ESADI-LSP. So no more than one valid LSP number zero can be received by such an ESADI instance. For an ESADI in Not-DRB state, you are right. > 2) ESADI will only help in fast updates of end station addresses, It will > not help in the initial learning of macs by RBrides the encapsulation and > decapitation. Besides fasten update of end station addressed, I think that ESADI can also help in fasten the initial learning of MACs by RBridges. For example, local RBridge RB1 provides services for local end stations E1 and E2 in VLAN 1, remote RBridge RBx serves for remote end station Ex in VLAN 1. At first, E1 communicates with E2 through RB1 in VLAN 1, so RB1 learns the MACs of E1 and E2. If ESADI for VLAN 1 is running on RB1 and RBx, RB1 can tell RBx the MACs addresses of E1 and/or E2 with the help of ESADI before E1 or E2 communicates with Ex, > Thanks and Regards, > Abhinav Thanks, Zhai Hongjun """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" Protocol Development Dept.VI, Central R&D Institute, ZTE Corporation No. 68, Zijinghua Road, Yuhuatai District, Nanjing, P.R.China, 210012 Zhai Hongjun Tel: +86-25-52877345 Email: zhai.hongjun@zte.com.cn """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 00428B324825799D_= Content-Type: text/html; charset="US-ASCII"
Hi Abhinav

> 1) In the draft : *"In this state, the Holding Timer will be recycled if
> the timer is expired or the found neighbor has a higher priority than the
> local priority."*

I think this sentence is some confusing, so I try to give a clearer explanation
of the above line.

The cyclic Holding Timer is mainly used to trigger the DRB election process for
the ESADI instances being in Not-DRB state. If this timer expires, the state of
this ESADI moves from Not-DRB to DRB. In order to fasten the election process,
this timer is started in Initial state. The timer may expire, if so, it will also
be recycled in Initial state.

On an ESADI virtual link, only the ESADI RBridge that has the highest priority
(with IS-IS system ID as ties breaking) is finally elected as DRB. If receiving
an ESADI-LSP number zero from a neighbor with higher priority than the local
priority, the local ESADI instance can not become DRB finally. Therefore,
recycling this timer by such an ESADI instance can reduce the possibility of
the ESADI instance entering into DRB state if such a neighbor is found.

>     I could not understand the above line, i think it should  something
> like*: "In this state,  the Holding Timer will be recycled every time an
> lsp is received with higher priority"*

For an ESADI instance in Initial state, it will leave this state and enter into
Not-DRB state as long as it find a valid neighbor by receiving ESADI-LSP. So no
more than one valid LSP number zero can be received by such an ESADI instance.
For an ESADI in Not-DRB state, you are right.

> 2) ESADI will only help in fast updates of end station addresses, It will
> not help in the initial learning of macs by RBrides the encapsulation and
> decapitation.

Besides fasten update of end station addressed, I think that ESADI can also help
in fasten the initial learning of MACs by RBridges. For example, local RBridge RB1
provides services for local end stations E1 and E2 in VLAN 1, remote RBridge RBx
serves for remote end station Ex in VLAN 1. At first, E1 communicates with E2
through RB1 in VLAN 1, so RB1 learns the MACs of E1 and E2. If ESADI for VLAN 1 is
running on RB1 and RBx, RB1 can tell RBx the MACs addresses of E1 and/or E2 with
the help of ESADI before E1 or E2 communicates with Ex,


> Thanks and Regards,
> Abhinav


Thanks,
Zhai Hongjun
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
Protocol Development Dept.VI, Central R&D Institute, ZTE Corporation
No. 68, Zijinghua Road, Yuhuatai District, Nanjing, P.R.China, 210012

Zhai Hongjun

Tel: +86-25-52877345
Email: zhai.hongjun@zte.com.cn
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 00428B324825799D_=-- --===============1332407372== 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 --===============1332407372==-- From rbridge-bounces@postel.org Thu Feb 9 12:06: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 F270211E808D for ; Thu, 9 Feb 2012 12:06:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.377 X-Spam-Level: X-Spam-Status: No, score=-5.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 BiYleEdghX1w for ; Thu, 9 Feb 2012 12:06:50 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 02D6D11E808E for ; Thu, 9 Feb 2012 12:06:49 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q19JpJM2015050; Thu, 9 Feb 2012 11:51:21 -0800 (PST) Received: from mail-qy0-f180.google.com (mail-qy0-f180.google.com [209.85.216.180]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q19JobOC014973 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 9 Feb 2012 11:50:46 -0800 (PST) Received: by qcsd15 with SMTP id d15so1708683qcs.39 for ; Thu, 09 Feb 2012 11:50:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UA6d8bGVNGuK2RfLHKoABGZTwRjPlIG9AjA0P9livCQ=; b=Q4lcRi2+qUpxvs2EgMhE7ngC/WBMLGxgd3qqQ5TgmJluFjzDArn4TNUnUW/Ip9rkGa 1CvClfvY8h+88tdy5b0FIWLfoMz8Tv6+20ZG7C3fUwcn9ZSmBSc4v1HWGILe50X2e1B7 rIW2j++58w/t5qrPH5AtDzZke4IHnRvCGY+UU= MIME-Version: 1.0 Received: by 10.229.78.159 with SMTP id l31mr2003360qck.114.1328817037088; Thu, 09 Feb 2012 11:50:37 -0800 (PST) Received: by 10.229.155.206 with HTTP; Thu, 9 Feb 2012 11:50:37 -0800 (PST) In-Reply-To: <4F2A0A63.30907@acm.org> References: <4F2991C6.7070904@acm.org> <012b01cce14a$9b0dbca0$d12935e0$@com> <4F2A0A63.30907@acm.org> Date: Thu, 9 Feb 2012 11:50:37 -0800 X-Google-Sender-Auth: y8hqoWA0tz49WpvxUseKgPlMDQE Message-ID: From: Anoop Ghanwani To: Erik Nordmark X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: ghanwani@gmail.com X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id q19JobOC014973 Cc: rbridge@postel.org, Yizhou Li Subject: Re: [rbridge] WG last call of draft-ietf-trill-rbridge-channel-04 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 Here are some comments on the document. Technical comments =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - I'm a bit concerned about the hop-by-hop processing which requires the ability to look at a bit in the extended header. I don't know if any alternatives were discussed...perhaps using a different inner.MACDA multicast address which indicates hop-by-hop processing is desired would work much better and would be compatible with existing silicon. Would there be any issues with using a separate multicast address for indicating hop-by-hop processing? - State that the "Available Flags" part is reserved; i.e. set to zero on transmit, ignore on receipt. - Section 3 >>> 2. If an RBridge Channel Alert extended header flag is set, then the RBridge MUST process the RBridge Channel message as described below even if it is not egressing the frame. If it is egressing the frame, then no additional processing beyond egress processing is needed even if an RBridge Channel Alert flag is set. >>> Since the inner.MACDA is always All-Egress-RBridges, how would such a frame ever be allowed to be sent out an egress RBridge? It seems like end station can send a channel message, but an RBridge can't send one to an end station. - Section 3.2 >>> For the protocol specific data area, an RBridge Channel Message Error frame has at least the first 256 bytes (or less if less are available) of the erroneous decapsulated channel message starting with the TRILL Header. (Note: The TRILL Header does not include the TRILL Ethertype that is part of the Link Header on Ethernet Links and may be absent for other link technologies.) >>> What if the channel frame is a native frame? This aspect is not dealt with even in the section concerning native frames. - Section 4 >>> 2. If the frame is unicast, the destination MAC address is the unicast MAC address of the RBridge or end-station port that is its intended destination. If the frame is multicast by an end station to all the RBridges on a link that support an RBridge Channel protocol that uses this transport, the destination MAC address is the All-Edge-RBridges multicast address. If the frame is multicast by an RBridge to all the devices that TRILL considers to be end stations on a link that support an RBridge Channel protocol that uses this transport, the destination MAC address is the TRILL-End-Stations multicast address (see Section 6). The RBridge-Channel Ethertype must be present. In the future there may be other protocols using the All-Edge- RBridges and/or TRILL-End-Stations multicast addresses on native frames distinguished by different Ethertypes. >>> This imposes some interesting requirements for filtering on ingress to the RBridge. For example, what if the address on a channel frame does not match any of the ones specified above? Do we assume that channel messages received in native format must either be processed by the receiving RBridge or discarded? In other words it should not be possible to send a channel protocol frame from outside the TRILL network that enters or transits the TRILL network. Editorial comments =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - Section 1, 4th line "the implement" -> "that implement. - Pg 5, line 9 from bottom depend -> and depending On Wed, Feb 1, 2012 at 8:00 PM, Erik Nordmark wrote: > On 2/1/12 5:33 PM, Yizhou Li wrote: >> The latest version should be 04. > > Yes. Thanks for the correction. > > =A0 =A0Erik > >> Yizhou >> >> -----Original Message----- >> From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On >> Behalf Of Erik Nordmark >> Sent: Thursday, February 02, 2012 3:26 AM >> To: rbridge@postel.org >> Subject: [rbridge] WG last call of draft-ietf-trill-rbridge-channel-03 >> >> >> We're starting three separate last calls this week, but they are all >> very short documents. >> >> We had an earlier WG last call on this document 6 months ago, and there >> were some concerns about using the IS-IS genapp mechanism, so that use >> has been removed. >> >> The WG last call ends on Feb 15th. >> Please send comments (including ones that say you've read the document >> and it is fine) to the rbridge list. >> >> =A0 =A0 Erik >> >> _______________________________________________ >> 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 Sun Feb 12 22:55: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 AC92621F8687 for ; Sun, 12 Feb 2012 22:55:09 -0800 (PST) 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_73=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 1QfEeU1A0HqO for ; Sun, 12 Feb 2012 22:55:08 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id AB48921F867E for ; Sun, 12 Feb 2012 22:55:08 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1D6VfEn019803; Sun, 12 Feb 2012 22:31:43 -0800 (PST) Received: from mail-vw0-f52.google.com (mail-vw0-f52.google.com [209.85.212.52]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1D6VHoX019773 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 12 Feb 2012 22:31:26 -0800 (PST) Received: by vbih1 with SMTP id h1so5107688vbi.39 for ; Sun, 12 Feb 2012 22:31:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=TAMwYLE86kSzCBFPjioRkdnL3AZzWicLWqKyvG+uVJ8=; b=J+5FVRpot3m9LeZQtlYrovjrAZVVosBvTv36C082V0YHrN+wVaxiKuxIkIu8Husbio IFKYwn5bIfxX4RbFOfORex2fvau1my8zOqjSXTGBVXyDWmFK9BZAa7ymdjR0ikQz8eWk dy6h70Zu6K00Q1duxXp6eqA5bAhTH5K1oy9Yc= MIME-Version: 1.0 Received: by 10.220.108.138 with SMTP id f10mr7688249vcp.16.1329114676669; Sun, 12 Feb 2012 22:31:16 -0800 (PST) Received: by 10.52.26.207 with HTTP; Sun, 12 Feb 2012 22:31:16 -0800 (PST) In-Reply-To: References: Date: Mon, 13 Feb 2012 12:01:16 +0530 Message-ID: From: somnath chatterjee To: rbridge@postel.org X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: somnath.chatterjee01@gmail.com X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id q1D6VHoX019773 Subject: [rbridge] draft-ietf-trill-rbridge-channel-04 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 Authors, In draft-ietf-trill-rbridge-channel-04 Section 2.4 " =A0 However, special considerations apply to the first hop because,for some RBridge Channel protocols, it may be desirable to send RBridge Channel messages on links that are not yet fully up. In particular, it is permissible, if specified by the particular channel protocol, for the source RBridge that has created an RBridge Channel message to attempt to transmit it to a next hop RBridge when the link is in the Detect or Two-Way states, as specified in [RFC6327], as well as when it is in the Report state." As per my understanding this does not apply to multi-hop Channel messages. It would be good if we replace the "first hop" to "single hop messages" in the sentence or modify the sentence to add it is applicable to "single hop messages" only. I have read this draft and it looks good to me. Thank you, Regards, Somnath _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge From rbridge-bounces@postel.org Mon Feb 13 12:12: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 5993821F86DE for ; Mon, 13 Feb 2012 12:12:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.307 X-Spam-Level: X-Spam-Status: No, score=-105.307 tagged_above=-999 required=5 tests=[AWL=0.692, BAYES_00=-2.599, J_CHICKENPOX_73=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 WMXbjOsLJClB for ; Mon, 13 Feb 2012 12:12:28 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 48F0E21F86EB for ; Mon, 13 Feb 2012 12:12:27 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1DJlWbS028381; Mon, 13 Feb 2012 11:47:33 -0800 (PST) Received: from mail-lpp01m020-f180.google.com (mail-lpp01m020-f180.google.com [209.85.217.180]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1DJkkMN028305 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 13 Feb 2012 11:46:56 -0800 (PST) Received: by lbok6 with SMTP id k6so1242576lbo.39 for ; Mon, 13 Feb 2012 11:46:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=Yz/XPLRRA53IkSZ2zUSTyeCmsBC60HkQhttgkhO1tvo=; b=rGsMRTbac/tLd8tK8Kn1YX+dcEFxXbTMFAUEdeUO/YzUp1alXhRiRwIdC42aHN8ZUe F2aJMwzVfeYQ0D2lKzoDIa3SejqrNNfZhehVMUqt7M7gXnWmxvokB1sfVII5+1UkpYUr eztSHIujtxoygsz36MKCAc+M0BuDpDS4d3czc= Received: by 10.152.133.229 with SMTP id pf5mr12172757lab.18.1329162405553; Mon, 13 Feb 2012 11:46:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.88.42 with HTTP; Mon, 13 Feb 2012 11:46:25 -0800 (PST) In-Reply-To: References: From: Donald Eastlake Date: Mon, 13 Feb 2012 14:46:25 -0500 Message-ID: To: somnath chatterjee 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 q1DJkkMN028305 Cc: rbridge@postel.org Subject: Re: [rbridge] draft-ietf-trill-rbridge-channel-04 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 Somnath, On Mon, Feb 13, 2012 at 1:31 AM, somnath chatterjee wrote: > Hi Authors, > > In draft-ietf-trill-rbridge-channel-04 Section 2.4 > > " =A0 However, special considerations apply to the first hop because,for > some RBridge Channel protocols, it may be desirable to send RBridge > Channel messages on links that are not yet fully up. In particular, it > is permissible, if specified by the particular channel protocol, for > the source RBridge that has created an RBridge Channel message to > attempt to transmit it to a next hop RBridge when the link is in the > Detect or Two-Way states, as specified in [RFC6327], as well as when > it is in the Report state." > > As per my understanding this does not apply to multi-hop Channel > messages. It would be good if we replace the "first hop" to "single > hop messages" in the sentence or modify the sentence to add it is > applicable to "single hop messages" only. I'm OK with that change. I'll make it unless there are objections. 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 > I have read this draft and it looks good to me. > > Thank you, > Regards, > Somnath _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge From rbridge-bounces@postel.org Mon Feb 13 19:38: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 2A27721F853B for ; Mon, 13 Feb 2012 19:38:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.324 X-Spam-Level: X-Spam-Status: No, score=-105.324 tagged_above=-999 required=5 tests=[AWL=0.675, 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 rLTZfmMQ7AoI for ; Mon, 13 Feb 2012 19:38:01 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id DA70421F84D5 for ; Mon, 13 Feb 2012 19:38:01 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1E3NHr5011505; Mon, 13 Feb 2012 19:23:20 -0800 (PST) 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 q1E3MnhR011461 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 13 Feb 2012 19:22:59 -0800 (PST) Received: by lagy4 with SMTP id y4so7678199lag.39 for ; Mon, 13 Feb 2012 19:22:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=ua0wDL1Irqys/NNuUzw7NCpbpVADkpmsxo5yce2nF6k=; b=Ttyh0z9Pj5FbzwCTBDnxQLCZUtPxrMXYz+eV+zU8bhW2t1bWVZFT+GkRFZpCPYJqsX yTViece60zx2uOzZoRX6Z23mdicKd0EuKCV3SPcxZnyupDIR4VlFdXGi51ecbRRJTcau 9xRIsV5kFvjl+3zEbn+oK13i8C9pk0gLP+VB4= Received: by 10.112.10.72 with SMTP id g8mr6870986lbb.12.1329189768244; Mon, 13 Feb 2012 19:22:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.88.42 with HTTP; Mon, 13 Feb 2012 19:22:28 -0800 (PST) In-Reply-To: References: <4F2991C6.7070904@acm.org> <012b01cce14a$9b0dbca0$d12935e0$@com> <4F2A0A63.30907@acm.org> From: Donald Eastlake Date: Mon, 13 Feb 2012 22:22:28 -0500 Message-ID: To: Anoop Ghanwani 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 q1E3MnhR011461 Cc: rbridge@postel.org, Erik Nordmark , Yizhou Li Subject: Re: [rbridge] WG last call of draft-ietf-trill-rbridge-channel-04 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 Anoop, Thanks for the comments. See below: On Thu, Feb 9, 2012 at 2:50 PM, Anoop Ghanwani wrot= e: > Here are some comments on the document. > > Technical comments > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > - I'm a bit concerned about the hop-by-hop processing which requires > the ability to look at a bit in the extended header. I don't know if > any alternatives were discussed...perhaps using a different > inner.MACDA multicast address which indicates hop-by-hop processing > is desired would work much better and would be compatible with > existing silicon. Would there be any issues with using a separate > multicast address for indicating hop-by-hop processing? I think the vast majority of channel protocols will either be (1) one hop or (2) multi-hop with no per hop processing. In the case of a multi-hop channel protocol frame that needs hop-by-hop processing (for example something like record route or some protocol that wants source routing), there are lots of ways you could modify such a frame to alert the transit RBridges along the way. But these frames will commonly be unicast, in which case there is no reason in the TRILL base protocol for a transit RBridge to look at anything after the TRILL Header, such as the Inner.MacDA. So you need to change something in the TRILL Header. You could use a bit in the V field and/or the R field, but people seemed to be against using those bits. Anyway, setting the TRILL Header Extension Length (called Options Length in RFC 6325) non-zero causes all the TRILL silicon I know about to divert the frame to the slow path, which is the desired effect for now. There is no need for the fast path logic to "look at" the extended header at this time. This is exactly how it was in the earlier version of this draft which passed WGLC: http://tools.ietf.org/html/draft-ietf-trill-rbridge-channel-01 The only difference is that, in response to comments on this list, the previous non-critical Alert Flag was supplemented by a critical Alert Flag. > - State that the "Available Flags" part is reserved; i.e. set to >zero on transmit, ignore on receipt. An excellent suggestion. How about, in Section 2.1.1, changing the figure so the bits are labeled "Reserved" instead of "Available Flags" and, after the descriptions of bits 0 thorugh 2, adding something like: "Reserved: Bits reserved for future specification that MUST be sent as zero and ignored on receipt." > - Section 3 > >>> > =A0 =A0 =A02. If an RBridge Channel Alert extended header flag is set, th= en > =A0 =A0 =A0 =A0 the RBridge MUST process the RBridge Channel message as > =A0 =A0 =A0 =A0 described below even if it is not egressing the frame. If= it is > =A0 =A0 =A0 =A0 egressing the frame, then no additional processing beyond > =A0 =A0 =A0 =A0 egress processing is needed even if an RBridge Channel Al= ert > =A0 =A0 =A0 =A0 flag is set. > >>> > Since the inner.MACDA is always All-Egress-RBridges, how would such > a frame ever be allowed to be sent out an egress RBridge? It seems > like end station can send a channel message, but an RBridge can't > send one to an end station. "Egressing" means being decapsulated, that is, leaving the TRILL tunnel. You are correct that RBridge Channel protocol frames are only intended to go between RBridges. But there are native RBridge Channel messages that go between RBridges and end stations on the same link as described in Section 4. An RBridge can create a native RBridge Channel frame and unicast it to an attached end station, etc. You could also have a channel protocol, for example, that went from an RBridge RB1, through RB2, to an end station or from that end station through RB2 to RB1, but the frames would have to be manipulated by that channel protocol at RB2 to convert between non-native and native forms. At a minimum, the native channel frame has no TRILL Header while the non-native inter-RBridge channel frame does. In addition, you would have to complement the NA bit in the Channel Header and adjust MAC addresses. That's what the next to the last paragraph in Section 4 is about. But I would think that almost all channel protocols would either be between RBridges or between an edge RBridge and an end station. > - Section 3.2 > >>> > =A0 For the protocol specific data area, an > =A0 RBridge Channel Message Error frame has at least the first 256 bytes > =A0 (or less if less are available) of the erroneous decapsulated channel > =A0 message starting with the TRILL Header. (Note: The TRILL Header does > =A0 not include the TRILL Ethertype that is part of the Link Header on > =A0 Ethernet Links and may be absent for other link technologies.) > >>> > > What if the channel frame is a native frame? This aspect is not > dealt with even in the section concerning native frames. Good point. The idea is to have all the differences between native and non-native channel frames described in Section 4. The last paragraph of Section 4 already mentions one native RBridge channel error message difference. That last pragraph in Section 4 should have something like the following added: "Also, since there is no TRILL Header in native RBridge Channel protocol frames, the beginning part of the frame in which the error was detected that is included in native RBridge Channel error frames starts with the RBridge Channel Header." > - Section 4 > =A0>>> > =A0 =A0 =A02. If the frame is unicast, the destination MAC address is the > =A0 =A0 =A0 =A0 unicast MAC address of the RBridge or end-station port th= at is > =A0 =A0 =A0 =A0 its intended destination. If the frame is multicast by an= end > =A0 =A0 =A0 =A0 station to all the RBridges on a link that support an RBr= idge > =A0 =A0 =A0 =A0 Channel protocol that uses this transport, the destinatio= n MAC > =A0 =A0 =A0 =A0 address is the All-Edge-RBridges multicast address. If the > =A0 =A0 =A0 =A0 frame is multicast by an RBridge to all the devices that = TRILL > =A0 =A0 =A0 =A0 considers to be end stations on a link that support an RB= ridge > =A0 =A0 =A0 =A0 Channel protocol that uses this transport, the destinatio= n MAC > =A0 =A0 =A0 =A0 address is the TRILL-End-Stations multicast address (see > =A0 =A0 =A0 =A0 Section 6). The RBridge-Channel Ethertype must be present= . In > =A0 =A0 =A0 =A0 the future there may be other protocols using the All-Edg= e- > =A0 =A0 =A0 =A0 RBridges and/or TRILL-End-Stations multicast addresses on > =A0 =A0 =A0 =A0 native frames distinguished by different Ethertypes. > >>> > This imposes some interesting requirements for filtering on ingress > to the RBridge. It only imposes requirements on edge RBridges (or end stations) that want to support one or more native RBridge channel protocols... > For example, what if the address on a channel frame > does not match any of the ones specified above? I assume you are talking about a native RBridge channel frame since the requirements on the Outer.MacDA of non-native RBridge channel frames is the same as on TRILL Data frames. So, as per the text above, a native RBridge channel frame arriving at an edge RBridge must have an Outer.MacDA of either the port's unicast MAC address of the All-Edge-RBridges multicast address. If it has a different unicast address, it is presumably intended for another RBridge on the link and is discarded. If it has a different multicast address, it is discarded. > Do we assume that > channel messages received in native format must either be processed > by the receiving RBridge or discarded? In other words it should not > be possible to send a channel protocol frame from outside the TRILL > network that enters or transits the TRILL network. Yes, that is my assumption. Probably a specific statement to that effect should be added. > Editorial comments > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > - Section 1, 4th line > =A0"the implement" -> "that implement. Thanks for spotting that. > - Pg 5, line 9 from bottom > =A0depend -> and depending Thanks again. For a version show suggested resolutions of your comments and a comparison to the current -04, see http://www.pothole.com/~dee3/drafts/ 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 Wed, Feb 1, 2012 at 8:00 PM, Erik Nordmark wrote: >> On 2/1/12 5:33 PM, Yizhou Li wrote: >>> The latest version should be 04. >> >> Yes. Thanks for the correction. >> >> =A0 =A0Erik >> >>> Yizhou >>> >>> -----Original Message----- >>> From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On >>> Behalf Of Erik Nordmark >>> Sent: Thursday, February 02, 2012 3:26 AM >>> To: rbridge@postel.org >>> Subject: [rbridge] WG last call of draft-ietf-trill-rbridge-channel-03 >>> >>> >>> We're starting three separate last calls this week, but they are all >>> very short documents. >>> >>> We had an earlier WG last call on this document 6 months ago, and there >>> were some concerns about using the IS-IS genapp mechanism, so that use >>> has been removed. >>> >>> The WG last call ends on Feb 15th. >>> Please send comments (including ones that say you've read the document >>> and it is fine) to the rbridge list. >>> >>> =A0 =A0 Erik _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge From rbridge-bounces@postel.org Mon Feb 13 22:06:39 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 D269D21F8705 for ; Mon, 13 Feb 2012 22:06:39 -0800 (PST) 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 yk3iMNDLoOUH for ; Mon, 13 Feb 2012 22:06:39 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id F10E421F8703 for ; Mon, 13 Feb 2012 22:06:38 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1E5inYQ000726; Mon, 13 Feb 2012 21:44:49 -0800 (PST) Received: from mail-lpp01m020-f180.google.com (mail-lpp01m020-f180.google.com [209.85.217.180]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1E5i7kd000594 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 13 Feb 2012 21:44:17 -0800 (PST) Received: by lbok6 with SMTP id k6so1620819lbo.39 for ; Mon, 13 Feb 2012 21:44:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=W+PQ6Lz98o0ZBTTrZPLZyJZnwmZctuseM4Pt1GL4/ac=; b=ovGxgF9I517OSxN6HnmyiwhTq9XX6e0LegYMtof3H0MaEbFg36IWiy7JX/8rKOzGr4 pQaHWdTWgyYqHSsOOIv3KINrfsGstO7imrZT8doOaKi4uMjDGOCKDcwjCS0ST/T0AXPJ idfq7rNJUuCsV12G9LSo2NZJh439nJ89F4xeY= Received: by 10.112.85.137 with SMTP id h9mr6538293lbz.51.1329198246273; Mon, 13 Feb 2012 21:44:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.88.42 with HTTP; Mon, 13 Feb 2012 21:43:46 -0800 (PST) In-Reply-To: References: From: Donald Eastlake Date: Tue, 14 Feb 2012 00:43:46 -0500 Message-ID: To: Abhinav Bhatia 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 q1E5i7kd000594 Cc: rbridge@postel.org Subject: Re: [rbridge] Query Reg: RBridges: The ESADI Protocol 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 Abhinav, On Mon, Feb 6, 2012 at 6:20 AM, Abhinav Bhatia wr= ote: > Hi, > > I have queries related to esadi protocol draft > . > > 1) In the draft : "In this state, the Holding Timer will be recycled if t= he > timer is expired or the found neighbor has a higher priority than the loc= al > priority." > > =A0=A0=A0=A0 I could not understand the above line, i think it should=A0 = something > like: "In this state,=A0 the Holding Timer will be recycled every time an= lsp > is received with higher priority" Note that this is not yet a WG draft... As currently described, the ESADI Holding Timer has to recycle to cause the repeated transmission of ESADI-LSP number zero until a neighbor is found. Perhaps that mechanism should be replaced by a VLAN scoped flag bit in the core TRILL IS-IS instance. > 2) ESADI will only help in fast updates of end station=A0 addresses, It w= ill > not help in the initial learning of macs by RBrides the encapsulation and > decapitation. Yes, leaning from ESADI and learning from the data plane are different and ESADI does not affect learning from the data plane. I assume data plane learning is what you refer to as "encapsulation and decapsulation" -- but it isn't exactly "encapsulation". It is actually from the receipt of any Ethernet frame with a unicast source address. However, if other RBridges are participating in ESADI for VLAN-x then, when an RBridge starts participating in ESADI for VLAN-x, it will fairly soon get updates with such MAC attachment information for VLAN-x as other RBridges choose to include in ESADI. 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 > Please correct me if i am wrong. > > Thanks and Regards, > Abhinav > > _______________________________________________ > 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 Mon Feb 13 23:09:39 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 AC11221F8501 for ; Mon, 13 Feb 2012 23:09:38 -0800 (PST) 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 SGOBqcjQTekA for ; Mon, 13 Feb 2012 23:09:37 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 34F1D21E800F for ; Mon, 13 Feb 2012 23:09:34 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1E6pM0p012672; Mon, 13 Feb 2012 22:51:22 -0800 (PST) Received: from mail-pz0-f52.google.com (mail-pz0-f52.google.com [209.85.210.52]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1E6ouVJ012604 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 13 Feb 2012 22:51:05 -0800 (PST) Received: by dado14 with SMTP id o14so6769556dad.39 for ; Mon, 13 Feb 2012 22:50:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=d9IK5Fc1FlVZD52lhHEWZxsY9ZwCY6Ka478yUN491CE=; b=OnAWIGUJ/uyqPvpXnDqZFnK+1xxo7PcYpx037gN+Sj3OThtToFOFCFdXuhDhfvN5JW sh67Ixn8cCJl377K9hKSArHE2lKGfE5eyXADT6rgcWYNZwXhu8Rwg0kLjNpFCoRsfF2e afhfbQpX0M9aYJzw/yxT6Bvco87uEQic8qva0= MIME-Version: 1.0 Received: by 10.68.238.68 with SMTP id vi4mr55471412pbc.65.1329202255899; Mon, 13 Feb 2012 22:50:55 -0800 (PST) Received: by 10.142.195.15 with HTTP; Mon, 13 Feb 2012 22:50:55 -0800 (PST) In-Reply-To: References: Date: Tue, 14 Feb 2012 12:20:55 +0530 Message-ID: From: rakesh kumar To: rbridge@postel.org X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rakesh51086@gmail.com Subject: [rbridge] draft-ietf-trill-rbridge-channel-04 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="===============1508663497==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org --===============1508663497== Content-Type: multipart/alternative; boundary=047d7b3396014c2b8304b8e70461 --047d7b3396014c2b8304b8e70461 Content-Type: text/plain; charset=ISO-8859-1 Hi Authors, In draft-ietf-trill-rbridge-channel-04 Section 2.4 "However, special considerations apply to the first hop because, for some RBridge Channel protocols, it may be desirable to send RBridge Channel messages on links that are not yet fully up. In particular, it is permissible, if specified by the particular channel protocol, for the source RBridge that has created an RBridge Channel message to attempt to transmit it to a next hop RBridge when the link is in the Detect or Two-Way states, as specified in [RFC6327], as well as when it is in the Report state." This doesn't talk about Point-to-point link.I think Point-to-point link also needs to be addressed here. Regards, Rakesh --047d7b3396014c2b8304b8e70461 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Authors,

In draft-ietf-trill-rbridge-channel-04 Section 2.4

&= quot;However, special considerations apply to the first hop because,
for some RBridge Channel protocols, it may be desirable to send
RBridge Channel messages on links that are not yet fully up. In
particular, it is permissible, if specified by the particular channel
protocol, for the source RBridge that has created an RBridge Channel
message to attempt to transmit it to a next hop RBridge when the link
is in the Detect or Two-Way states, as specified in [RFC6327], as well
as when it is in the Report state."

This = doesn't talk about =A0Point-to-point link.I think=A0Point-to-point link= also needs to be addressed here.

Regards,
Rakesh

--047d7b3396014c2b8304b8e70461-- --===============1508663497== 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 --===============1508663497==-- From rbridge-bounces@postel.org Tue Feb 14 04:35:44 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 C0FA221F87D5 for ; Tue, 14 Feb 2012 04:35:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.66 X-Spam-Level: X-Spam-Status: No, score=-105.66 tagged_above=-999 required=5 tests=[AWL=0.939, 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 R-EdIuEltI-J for ; Tue, 14 Feb 2012 04:35:43 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id D977F21F87BA for ; Tue, 14 Feb 2012 04:35:43 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1ECGvvQ009582; Tue, 14 Feb 2012 04:16:58 -0800 (PST) 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 q1ECGHpW009460 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 14 Feb 2012 04:16:27 -0800 (PST) Received: by lagy4 with SMTP id y4so8156773lag.39 for ; Tue, 14 Feb 2012 04:16:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=e76v9XdozTVfc3iHMYMJH5L1QAFNrvJ75SXaQnautx8=; b=W2rfccd8d85xG2GN0BIzalnjf4MKgaj6GJQ6RuB2NGdUQniLx83YmtkoI3fOApKH9c GXyiJ58Q9t/VMIVFoAlyvYNVq3ysQDVAYZUMnofWI7OJCKbvi8SwKgq+LIf/a/XHM1ca Q9B15mg3kBWl6JG9PialTiuUj3RPmxXlvLKlM= Received: by 10.112.101.194 with SMTP id fi2mr7150295lbb.25.1329221776289; Tue, 14 Feb 2012 04:16:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.88.42 with HTTP; Tue, 14 Feb 2012 04:15:56 -0800 (PST) In-Reply-To: References: From: Donald Eastlake Date: Tue, 14 Feb 2012 07:15:56 -0500 Message-ID: To: rakesh kumar 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 q1ECGHpW009460 Cc: rbridge@postel.org Subject: Re: [rbridge] draft-ietf-trill-rbridge-channel-04 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 Rakesh, On Tue, Feb 14, 2012 at 1:50 AM, rakesh kumar wrote: > Hi Authors, > > In draft-ietf-trill-rbridge-channel-04 Section 2.4 > > "However, special considerations apply to the first hop because, > for some RBridge Channel protocols, it may be desirable to send > RBridge Channel messages on links that are not yet fully up. In > particular, it is permissible, if specified by the particular channel > protocol, for the source RBridge that has created an RBridge Channel > message to attempt to transmit it to a next hop RBridge when the link > is in the Detect or Two-Way states, as specified in [RFC6327], as well > as when it is in the Report state." > > This doesn't talk about =A0Point-to-point link.I think=A0Point-to-point l= ink > also needs to be addressed here. What kind of thing do you think it should say? If, for example, you are unicasting an RBridge channel frame to a next hop RBridge, why does it matter if the link is point-to-point or multi-access? > Regards, > Rakesh 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 Tue Feb 14 09:14: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 186C721E8080 for ; Tue, 14 Feb 2012 09:14:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.577 X-Spam-Level: X-Spam-Status: No, score=-4.577 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 gXvWPky0qicr for ; Tue, 14 Feb 2012 09:14:30 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC6821F87B4 for ; Tue, 14 Feb 2012 09:14:29 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1EGkgQ7029386; Tue, 14 Feb 2012 08:46:45 -0800 (PST) Received: from mail-qy0-f180.google.com (mail-qy0-f180.google.com [209.85.216.180]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1EGjiZT029201 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 14 Feb 2012 08:45:53 -0800 (PST) Received: by qcsd15 with SMTP id d15so141969qcs.39 for ; Tue, 14 Feb 2012 08:45:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EEY7CmXPzFKVZp+Wkk+LYXtyJfGt/+AnoFE3PuIafPM=; b=Q88IkcLXNuNrpX4Dieyfcg7fB/6yNyAoVjtTmihuB4RX7hEXKetGutJJLgk1D1XSDb b2+IlZtD7b3USd+V4WOjDwdgyFL1sIjJSOh4Im7pMcnZmW1+DkTgoxKwD2pjVSIXNdc5 OIL8PRbmmJWbJnu11KoAi+x/y5VyA/VJSnPpY= MIME-Version: 1.0 Received: by 10.229.76.132 with SMTP id c4mr12522147qck.134.1329237943338; Tue, 14 Feb 2012 08:45:43 -0800 (PST) Received: by 10.229.155.206 with HTTP; Tue, 14 Feb 2012 08:45:43 -0800 (PST) In-Reply-To: References: <4F2991C6.7070904@acm.org> <012b01cce14a$9b0dbca0$d12935e0$@com> <4F2A0A63.30907@acm.org> Date: Tue, 14 Feb 2012 08:45:43 -0800 X-Google-Sender-Auth: TNAyjJCZ7RbqCf1IL9CMOGm4Ec4 Message-ID: From: Anoop Ghanwani To: Donald Eastlake X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: ghanwani@gmail.com X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id q1EGjiZT029201 Cc: rbridge@postel.org, Erik Nordmark , Yizhou Li Subject: Re: [rbridge] WG last call of draft-ietf-trill-rbridge-channel-04 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, Thanks for the response. I have pulled out sections of the text that I want to respond to. > Anyway, setting the TRILL Header Extension Length (called Options > Length in RFC 6325) non-zero causes all the TRILL silicon I know about > to divert the frame to the slow path, which is the desired effect for > now. There is no need for the fast path logic to "look at" the > extended header at this time. But it probably won't be able to prioritize the frame correctly. If a message is going to be processed hop-by-hop, and it is unicast, would it not be better to just use the "AnyRBridge" nickname and embed the eventual egress RBridge in the payload? That way it becomes easily compatible with existing hardware. So, for the multicast case, we use a different reserved MAC, and for the unicast case we use AnyRBridge. I don't see that there would be any loss of functionality if we did that. > "Egressing" means being decapsulated, that is, leaving the TRILL > tunnel. You are correct that RBridge Channel protocol frames are only > intended to go between RBridges. But there are native RBridge Channel > messages that go between RBridges and end stations on the same link as > described in Section 4. An RBridge can create a native RBridge Channel > frame and unicast it to an attached end station, etc. Per your description, this would not be a valid case of "egressing", so the above text wouldn't apply to this case. > You could also have a channel protocol, for example, that went from an > RBridge RB1, through RB2, to an end station or from that end station > through RB2 to RB1, but the frames would have to be manipulated by > that channel protocol at RB2 to convert between non-native and native > forms. At a minimum, the native channel frame has no TRILL Header > while the non-native inter-RBridge channel frame does. In addition, > you would have to complement the NA bit in the Channel Header and > adjust MAC addresses. That's what the next to the last paragraph in > Section 4 is about. But I would think that almost all channel > protocols would either be between RBridges or between an edge RBridge > and an end station. Would the case of manipulation be considered "egressing"? Since egressing in the strict sense is simplying decapsulating the frame and sending it out as a native frame, it seems to me that the scenario described in the quoted text should never happen. Anoop On Mon, Feb 13, 2012 at 7:22 PM, Donald Eastlake wrote: > Hi Anoop, > > Thanks for the comments. See below: > > On Thu, Feb 9, 2012 at 2:50 PM, Anoop Ghanwani wr= ote: >> Here are some comments on the document. >> >> Technical comments >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> - I'm a bit concerned about the hop-by-hop processing which requires >> the ability to look at a bit in the extended header. I don't know if >> any alternatives were discussed...perhaps using a different >> inner.MACDA multicast address which indicates hop-by-hop processing >> is desired would work much better and would be compatible with >> existing silicon. Would there be any issues with using a separate >> multicast address for indicating hop-by-hop processing? > > I think the vast majority of channel protocols will either be (1) one > hop or (2) multi-hop with no per hop processing. In the case of a > multi-hop channel protocol frame that needs hop-by-hop processing (for > example something like record route or some protocol that wants source > routing), there are lots of ways you could modify such a frame to > alert the transit RBridges along the way. But these frames will > commonly be unicast, in which case there is no reason in the TRILL > base protocol for a transit RBridge to look at anything after the > TRILL Header, such as the Inner.MacDA. So you need to change something > in the TRILL Header. You could use a bit in the V field and/or the R > field, but people seemed to be against using those bits. > > Anyway, setting the TRILL Header Extension Length (called Options > Length in RFC 6325) non-zero causes all the TRILL silicon I know about > to divert the frame to the slow path, which is the desired effect for > now. There is no need for the fast path logic to "look at" the > extended header at this time. > > This is exactly how it was in the earlier version of this draft which > passed WGLC: > http://tools.ietf.org/html/draft-ietf-trill-rbridge-channel-01 > The only difference is that, in response to comments on this list, the > previous non-critical Alert Flag was supplemented by a critical Alert > Flag. > >> - State that the "Available Flags" part is reserved; i.e. set to >>zero on transmit, ignore on receipt. > > An excellent suggestion. How about, in Section 2.1.1, changing the > figure so the bits are labeled "Reserved" instead of "Available Flags" > and, after the descriptions of bits 0 thorugh 2, adding something > like: > > =A0 "Reserved: Bits reserved for future specification that MUST be sent > as zero and ignored on receipt." > >> - Section 3 >> >>> >> =A0 =A0 =A02. If an RBridge Channel Alert extended header flag is set, t= hen >> =A0 =A0 =A0 =A0 the RBridge MUST process the RBridge Channel message as >> =A0 =A0 =A0 =A0 described below even if it is not egressing the frame. I= f it is >> =A0 =A0 =A0 =A0 egressing the frame, then no additional processing beyond >> =A0 =A0 =A0 =A0 egress processing is needed even if an RBridge Channel A= lert >> =A0 =A0 =A0 =A0 flag is set. >> >>> >> Since the inner.MACDA is always All-Egress-RBridges, how would such >> a frame ever be allowed to be sent out an egress RBridge? It seems >> like end station can send a channel message, but an RBridge can't >> send one to an end station. > > "Egressing" means being decapsulated, that is, leaving the TRILL > tunnel. You are correct that RBridge Channel protocol frames are only > intended to go between RBridges. But there are native RBridge Channel > messages that go between RBridges and end stations on the same link as > described in Section 4. An RBridge can create a native RBridge Channel > frame and unicast it to an attached end station, etc. > > You could also have a channel protocol, for example, that went from an > RBridge RB1, through RB2, to an end station or from that end station > through RB2 to RB1, but the frames would have to be manipulated by > that channel protocol at RB2 to convert between non-native and native > forms. At a minimum, the native channel frame has no TRILL Header > while the non-native inter-RBridge channel frame does. In addition, > you would have to complement the NA bit in the Channel Header and > adjust MAC addresses. That's what the next to the last paragraph in > Section 4 is about. But I would think that almost all channel > protocols would either be between RBridges or between an edge RBridge > and an end station. > >> - Section 3.2 >> >>> >> =A0 For the protocol specific data area, an >> =A0 RBridge Channel Message Error frame has at least the first 256 bytes >> =A0 (or less if less are available) of the erroneous decapsulated channel >> =A0 message starting with the TRILL Header. (Note: The TRILL Header does >> =A0 not include the TRILL Ethertype that is part of the Link Header on >> =A0 Ethernet Links and may be absent for other link technologies.) >> >>> >> >> What if the channel frame is a native frame? This aspect is not >> dealt with even in the section concerning native frames. > > Good point. The idea is to have all the differences between native and > non-native channel frames described in Section 4. The last paragraph > of Section 4 already mentions one native RBridge channel error message > difference. That last pragraph in Section 4 should have something like > the following added: > > =A0 "Also, since there is no TRILL Header in native RBridge Channel > =A0 protocol frames, the beginning part of the frame in which the error > =A0 was detected that is included in native RBridge Channel error > =A0 frames starts with the RBridge Channel Header." > >> - Section 4 >> =A0>>> >> =A0 =A0 =A02. If the frame is unicast, the destination MAC address is the >> =A0 =A0 =A0 =A0 unicast MAC address of the RBridge or end-station port t= hat is >> =A0 =A0 =A0 =A0 its intended destination. If the frame is multicast by a= n end >> =A0 =A0 =A0 =A0 station to all the RBridges on a link that support an RB= ridge >> =A0 =A0 =A0 =A0 Channel protocol that uses this transport, the destinati= on MAC >> =A0 =A0 =A0 =A0 address is the All-Edge-RBridges multicast address. If t= he >> =A0 =A0 =A0 =A0 frame is multicast by an RBridge to all the devices that= TRILL >> =A0 =A0 =A0 =A0 considers to be end stations on a link that support an R= Bridge >> =A0 =A0 =A0 =A0 Channel protocol that uses this transport, the destinati= on MAC >> =A0 =A0 =A0 =A0 address is the TRILL-End-Stations multicast address (see >> =A0 =A0 =A0 =A0 Section 6). The RBridge-Channel Ethertype must be presen= t. In >> =A0 =A0 =A0 =A0 the future there may be other protocols using the All-Ed= ge- >> =A0 =A0 =A0 =A0 RBridges and/or TRILL-End-Stations multicast addresses on >> =A0 =A0 =A0 =A0 native frames distinguished by different Ethertypes. >> >>> >> This imposes some interesting requirements for filtering on ingress >> to the RBridge. > > It only imposes requirements on edge RBridges (or end stations) that > want to support one or more native RBridge channel protocols... > >> For example, what if the address on a channel frame >> does not match any of the ones specified above? > > I assume you are talking about a native RBridge channel frame since > the requirements on the Outer.MacDA of non-native RBridge channel > frames is the same as on TRILL Data frames. > > So, as per the text above, a native RBridge channel frame arriving at > an edge RBridge must have an Outer.MacDA of either the port's unicast > MAC address of the All-Edge-RBridges multicast address. If it has a > different unicast address, it is presumably intended for another > RBridge on the link and is discarded. If it has a different multicast > address, it is discarded. > >> Do we assume that >> channel messages received in native format must either be processed >> by the receiving RBridge or discarded? In other words it should not >> be possible to send a channel protocol frame from outside the TRILL >> network that enters or transits the TRILL network. > > Yes, that is my assumption. Probably a specific statement to that > effect should be added. > >> Editorial comments >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> - Section 1, 4th line >> =A0"the implement" -> "that implement. > > Thanks for spotting that. > >> - Pg 5, line 9 from bottom >> =A0depend -> and depending > > Thanks again. > > For a version show suggested resolutions of your comments and a > comparison to the current -04, see > http://www.pothole.com/~dee3/drafts/ > > 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 +1-508-333-2270 (cell) > =A0155 Beaver Street, Milford, MA 01757 USA > =A0d3e3e3@gmail.com > >> On Wed, Feb 1, 2012 at 8:00 PM, Erik Nordmark wrote: >>> On 2/1/12 5:33 PM, Yizhou Li wrote: >>>> The latest version should be 04. >>> >>> Yes. Thanks for the correction. >>> >>> =A0 =A0Erik >>> >>>> Yizhou >>>> >>>> -----Original Message----- >>>> From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On >>>> Behalf Of Erik Nordmark >>>> Sent: Thursday, February 02, 2012 3:26 AM >>>> To: rbridge@postel.org >>>> Subject: [rbridge] WG last call of draft-ietf-trill-rbridge-channel-03 >>>> >>>> >>>> We're starting three separate last calls this week, but they are all >>>> very short documents. >>>> >>>> We had an earlier WG last call on this document 6 months ago, and there >>>> were some concerns about using the IS-IS genapp mechanism, so that use >>>> has been removed. >>>> >>>> The WG last call ends on Feb 15th. >>>> Please send comments (including ones that say you've read the document >>>> and it is fine) to the rbridge list. >>>> >>>> =A0 =A0 Erik _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge From rbridge-bounces@postel.org Tue Feb 14 21:02:02 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 0369411E8089 for ; Tue, 14 Feb 2012 21:02:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.636 X-Spam-Level: X-Spam-Status: No, score=-105.636 tagged_above=-999 required=5 tests=[AWL=0.963, 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 alghY7UlCKMc for ; Tue, 14 Feb 2012 21:02:01 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7DD11E8073 for ; Tue, 14 Feb 2012 21:02:01 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1F4hWer007446; Tue, 14 Feb 2012 20:43:33 -0800 (PST) Received: from mail-lpp01m020-f180.google.com (mail-lpp01m020-f180.google.com [209.85.217.180]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1F4ghKT007326 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 14 Feb 2012 20:42:53 -0800 (PST) Received: by lbok6 with SMTP id k6so520205lbo.39 for ; Tue, 14 Feb 2012 20:42:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=9nJTgVtdnY3xCCV6RYlISzI7zepgNJyY/PLaXtV0HeI=; b=q7NslXNjylIgnzvb7u01MeZW98y1LuoMlvPFcIUedRMQqvE2TmLoWJeJ6MlNXgqkqk tSyZxpnqLveN6xSgmDStcbngJV9W67vsSp+15THQIilcHuaANRVtbemLUUDXWfZVGf0Y lM5hGR5yn63Iwv+vw2VrwlmgnQpx+kgArm4+I= Received: by 10.112.10.72 with SMTP id g8mr8748313lbb.12.1329280962468; Tue, 14 Feb 2012 20:42:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.88.42 with HTTP; Tue, 14 Feb 2012 20:42:22 -0800 (PST) In-Reply-To: <4F299636.7060604@acm.org> References: <4F299636.7060604@acm.org> From: Donald Eastlake Date: Tue, 14 Feb 2012 23:42:22 -0500 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 q1F4ghKT007326 Subject: Re: [rbridge] WG last call on draft-ietf-trill-rbridge-bfd-02 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 I would like to suggest the addition of some material to the Security Considerations section. Something like what I've pasted below my .sig and above Erik's message blow... 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 Consist with TRILL's goal of minimum configuration, the default for BFD security between neighbor RBridges is based on that state of IS-IS shared secret authentication for Hello between those RBridges. If such IS-IS authentication is not in effect then, by default, TRILL BFD between those RBridges is also unsecured. But the RBridges may be configured to use BFD Security. If such IS-IS authentication is in effect then, unless configured otherwise, TRILL BFD Control frames sent between those RBridges use BFD Meticulous Keyed SHA1 authentication [RF5880] with keying material derived as shown below HMAC-SHA256 ( ( "TRILL BFD Control" | originatorMAC | originatorPortID ), IS-IS-shared-key ) where HMAC-SHA256 [RFC6234], "TRILL BFD Control" is the seventeen byte US ASCII [RFC20] string indicated that is then concatenated with the 6-byte MAC of the originating port and then the 2-byte Port ID as would be sent in a TRILL Hello on that port. These quantities are included to minimize expose of the same key to improve resistance to cryptanalysis. IS-IS-key is the secret keying material being used for IS-IS authentication on the link. In the Authentication Section of the BFD Control frame OAM protocol specific data, Auth Type would be 5, Auth Len would be 28, and Auth Key ID is zero. The RBridges MAY be configured to use other BFD security modes or keying material including configuration to use no security. Authentication for TRILL BFD Echo SHOULD be provided but is a local implementation issue as BFD Echo frames are authenticated by their sender when received in the form of Echo responses. However, if TRILL IS-IS and BFD Control are being authenticated to a neighbor and BFD Echo is in use, BFD Echo frames to be returned by that neighbor SHOULD be authenticated and such authenticate SHOULD use different keying material from other types of authentication. For example, it could use keying material derived as follows: HMAC-SHA256 ( ( "TRILL BFD Echo" | originatorMAC | originatorPortID ), IS-IS-shared-key ) On Wed, Feb 1, 2012 at 2:44 PM, Erik Nordmark wrote: > > The WG last call ends on Feb 15th. > Please send comments (including ones that say you've read the document > and it is fine) to the rbridge list. > > =A0 Erik > _______________________________________________ > 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 Tue Feb 14 21:19:12 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 3294B11E808A for ; Tue, 14 Feb 2012 21:19:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.055 X-Spam-Level: X-Spam-Status: No, score=-105.055 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, 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 HEXzGPeuLR8M for ; Tue, 14 Feb 2012 21:19:10 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id A20C611E8073 for ; Tue, 14 Feb 2012 21:19:10 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1F53we4011123; Tue, 14 Feb 2012 21:04:00 -0800 (PST) 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 q1F53G09010769 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 14 Feb 2012 21:03:26 -0800 (PST) Received: by lagy4 with SMTP id y4so969354lag.39 for ; Tue, 14 Feb 2012 21:03:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=Y+AzerWpNS/hSSW7c9QpCxnNjHJs/yuYA0ZwVxl9S5E=; b=VCXnvZT5VmjbzZra3k/nxIDyAoRclhQCcG3t8H0lKCzaDAVUrhXj0ThY3FAJK90fDk 8gevykVjmJ6XdJLEN/apFogdgasOdvcAg8L7wpeqR6R76DcUgtdZfz/qq0/icBjRXyE8 xtFrWh+T3XYQn72BQMYeO14ecJ0s3pS+T42Bg= Received: by 10.112.101.194 with SMTP id fi2mr8415521lbb.25.1329282195285; Tue, 14 Feb 2012 21:03:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.88.42 with HTTP; Tue, 14 Feb 2012 21:02:55 -0800 (PST) In-Reply-To: References: <4F2991C6.7070904@acm.org> <012b01cce14a$9b0dbca0$d12935e0$@com> <4F2A0A63.30907@acm.org> From: Donald Eastlake Date: Wed, 15 Feb 2012 00:02:55 -0500 Message-ID: To: Anoop Ghanwani 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 q1F53G09010769 Cc: rbridge@postel.org, Erik Nordmark , Yizhou Li Subject: Re: [rbridge] WG last call of draft-ietf-trill-rbridge-channel-04 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 Anoop, On Tue, Feb 14, 2012 at 11:45 AM, Anoop Ghanwani wr= ote: > Hi Donald, > > Thanks for the response. =A0I have pulled out sections of the > text that I want to respond to. > >> Anyway, setting the TRILL Header Extension Length (called Options >> Length in RFC 6325) non-zero causes all the TRILL silicon I know about >> to divert the frame to the slow path, which is the desired effect for >> now. There is no need for the fast path logic to "look at" the >> extended header at this time. > > But it probably won't be able to prioritize the frame > correctly. I don't see why there would be a prioritization problem. The Inner.VLAN tag is still there with the priority for re-queueing the frame if it is forwarded. > If a message is going to be processed hop-by-hop, and it is > unicast, would it not be better to just use the "AnyRBridge" nickname > and embed the eventual egress RBridge in the payload? =A0That way > it becomes easily compatible with existing hardware. =A0So, for the > multicast case, we use a different reserved MAC, and for the > unicast case we use AnyRBridge. =A0I don't see that there would be > any loss of functionality if we did that. The technique currently in the draft also seems to work fine and, given that it previously got WG consensus, I don't particularly want to change it. >> "Egressing" means being decapsulated, that is, leaving the TRILL >> tunnel. You are correct that RBridge Channel protocol frames are only >> intended to go between RBridges. But there are native RBridge Channel >> messages that go between RBridges and end stations on the same link as >> described in Section 4. An RBridge can create a native RBridge Channel >> frame and unicast it to an attached end station, etc. > > Per your description, this would not be a valid case of > "egressing", so the above text wouldn't apply to this case. There are two things being discussed. An RBridge-to-RBridge channel message does get de-capsulated/egressed at its egress RBridge(s) (can be more than one if multi-destination). But you are right that creation and transmission and the reception and processing of a native channel message does not involve "egressing" or "engrossing". >> You could also have a channel protocol, for example, that went from an >> RBridge RB1, through RB2, to an end station or from that end station >> through RB2 to RB1, but the frames would have to be manipulated by >> that channel protocol at RB2 to convert between non-native and native >> forms. At a minimum, the native channel frame has no TRILL Header >> while the non-native inter-RBridge channel frame does. In addition, >> you would have to complement the NA bit in the Channel Header and >> adjust MAC addresses. That's what the next to the last paragraph in >> Section 4 is about. But I would think that almost all channel >> protocols would either be between RBridges or between an edge RBridge >> and an end station. > > Would the case of manipulation be considered "egressing"? No, I don't think so. If the message went from RB1 to edge RBridge RB2, it would be decapitated (egressed) at RB2. The manipulate would be after the egressing and before the transmission as a native frame. > Since egressing in the strict sense is simplying decapsulating the > frame and sending it out as a native frame, it seems to me that > the scenario described in the quoted text should never happen. I guess you are right. I was using "egressing" in other than the strictest sense -- as decapsulating and delivering, where delivering might be transmitting through an external port but could just be delivering to the slow path... > Anoop 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, Feb 13, 2012 at 7:22 PM, Donald Eastlake wrote: >> Hi Anoop, >> >> Thanks for the comments. See below: >> >> On Thu, Feb 9, 2012 at 2:50 PM, Anoop Ghanwani w= rote: >>> Here are some comments on the document. >>> >>> Technical comments >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> - I'm a bit concerned about the hop-by-hop processing which requires >>> the ability to look at a bit in the extended header. I don't know if >>> any alternatives were discussed...perhaps using a different >>> inner.MACDA multicast address which indicates hop-by-hop processing >>> is desired would work much better and would be compatible with >>> existing silicon. Would there be any issues with using a separate >>> multicast address for indicating hop-by-hop processing? >> >> I think the vast majority of channel protocols will either be (1) one >> hop or (2) multi-hop with no per hop processing. In the case of a >> multi-hop channel protocol frame that needs hop-by-hop processing (for >> example something like record route or some protocol that wants source >> routing), there are lots of ways you could modify such a frame to >> alert the transit RBridges along the way. But these frames will >> commonly be unicast, in which case there is no reason in the TRILL >> base protocol for a transit RBridge to look at anything after the >> TRILL Header, such as the Inner.MacDA. So you need to change something >> in the TRILL Header. You could use a bit in the V field and/or the R >> field, but people seemed to be against using those bits. >> >> Anyway, setting the TRILL Header Extension Length (called Options >> Length in RFC 6325) non-zero causes all the TRILL silicon I know about >> to divert the frame to the slow path, which is the desired effect for >> now. There is no need for the fast path logic to "look at" the >> extended header at this time. >> >> This is exactly how it was in the earlier version of this draft which >> passed WGLC: >> http://tools.ietf.org/html/draft-ietf-trill-rbridge-channel-01 >> The only difference is that, in response to comments on this list, the >> previous non-critical Alert Flag was supplemented by a critical Alert >> Flag. >> >>> - State that the "Available Flags" part is reserved; i.e. set to >>>zero on transmit, ignore on receipt. >> >> An excellent suggestion. How about, in Section 2.1.1, changing the >> figure so the bits are labeled "Reserved" instead of "Available Flags" >> and, after the descriptions of bits 0 thorugh 2, adding something >> like: >> >> =A0 "Reserved: Bits reserved for future specification that MUST be sent >> as zero and ignored on receipt." >> >>> - Section 3 >>> >>> >>> =A0 =A0 =A02. If an RBridge Channel Alert extended header flag is set, = then >>> =A0 =A0 =A0 =A0 the RBridge MUST process the RBridge Channel message as >>> =A0 =A0 =A0 =A0 described below even if it is not egressing the frame. = If it is >>> =A0 =A0 =A0 =A0 egressing the frame, then no additional processing beyo= nd >>> =A0 =A0 =A0 =A0 egress processing is needed even if an RBridge Channel = Alert >>> =A0 =A0 =A0 =A0 flag is set. >>> >>> >>> Since the inner.MACDA is always All-Egress-RBridges, how would such >>> a frame ever be allowed to be sent out an egress RBridge? It seems >>> like end station can send a channel message, but an RBridge can't >>> send one to an end station. >> >> "Egressing" means being decapsulated, that is, leaving the TRILL >> tunnel. You are correct that RBridge Channel protocol frames are only >> intended to go between RBridges. But there are native RBridge Channel >> messages that go between RBridges and end stations on the same link as >> described in Section 4. An RBridge can create a native RBridge Channel >> frame and unicast it to an attached end station, etc. >> >> You could also have a channel protocol, for example, that went from an >> RBridge RB1, through RB2, to an end station or from that end station >> through RB2 to RB1, but the frames would have to be manipulated by >> that channel protocol at RB2 to convert between non-native and native >> forms. At a minimum, the native channel frame has no TRILL Header >> while the non-native inter-RBridge channel frame does. In addition, >> you would have to complement the NA bit in the Channel Header and >> adjust MAC addresses. That's what the next to the last paragraph in >> Section 4 is about. But I would think that almost all channel >> protocols would either be between RBridges or between an edge RBridge >> and an end station. >> >>> - Section 3.2 >>> >>> >>> =A0 For the protocol specific data area, an >>> =A0 RBridge Channel Message Error frame has at least the first 256 bytes >>> =A0 (or less if less are available) of the erroneous decapsulated chann= el >>> =A0 message starting with the TRILL Header. (Note: The TRILL Header does >>> =A0 not include the TRILL Ethertype that is part of the Link Header on >>> =A0 Ethernet Links and may be absent for other link technologies.) >>> >>> >>> >>> What if the channel frame is a native frame? This aspect is not >>> dealt with even in the section concerning native frames. >> >> Good point. The idea is to have all the differences between native and >> non-native channel frames described in Section 4. The last paragraph >> of Section 4 already mentions one native RBridge channel error message >> difference. That last pragraph in Section 4 should have something like >> the following added: >> >> =A0 "Also, since there is no TRILL Header in native RBridge Channel >> =A0 protocol frames, the beginning part of the frame in which the error >> =A0 was detected that is included in native RBridge Channel error >> =A0 frames starts with the RBridge Channel Header." >> >>> - Section 4 >>> =A0>>> >>> =A0 =A0 =A02. If the frame is unicast, the destination MAC address is t= he >>> =A0 =A0 =A0 =A0 unicast MAC address of the RBridge or end-station port = that is >>> =A0 =A0 =A0 =A0 its intended destination. If the frame is multicast by = an end >>> =A0 =A0 =A0 =A0 station to all the RBridges on a link that support an R= Bridge >>> =A0 =A0 =A0 =A0 Channel protocol that uses this transport, the destinat= ion MAC >>> =A0 =A0 =A0 =A0 address is the All-Edge-RBridges multicast address. If = the >>> =A0 =A0 =A0 =A0 frame is multicast by an RBridge to all the devices tha= t TRILL >>> =A0 =A0 =A0 =A0 considers to be end stations on a link that support an = RBridge >>> =A0 =A0 =A0 =A0 Channel protocol that uses this transport, the destinat= ion MAC >>> =A0 =A0 =A0 =A0 address is the TRILL-End-Stations multicast address (see >>> =A0 =A0 =A0 =A0 Section 6). The RBridge-Channel Ethertype must be prese= nt. In >>> =A0 =A0 =A0 =A0 the future there may be other protocols using the All-E= dge- >>> =A0 =A0 =A0 =A0 RBridges and/or TRILL-End-Stations multicast addresses = on >>> =A0 =A0 =A0 =A0 native frames distinguished by different Ethertypes. >>> >>> >>> This imposes some interesting requirements for filtering on ingress >>> to the RBridge. >> >> It only imposes requirements on edge RBridges (or end stations) that >> want to support one or more native RBridge channel protocols... >> >>> For example, what if the address on a channel frame >>> does not match any of the ones specified above? >> >> I assume you are talking about a native RBridge channel frame since >> the requirements on the Outer.MacDA of non-native RBridge channel >> frames is the same as on TRILL Data frames. >> >> So, as per the text above, a native RBridge channel frame arriving at >> an edge RBridge must have an Outer.MacDA of either the port's unicast >> MAC address of the All-Edge-RBridges multicast address. If it has a >> different unicast address, it is presumably intended for another >> RBridge on the link and is discarded. If it has a different multicast >> address, it is discarded. >> >>> Do we assume that >>> channel messages received in native format must either be processed >>> by the receiving RBridge or discarded? In other words it should not >>> be possible to send a channel protocol frame from outside the TRILL >>> network that enters or transits the TRILL network. >> >> Yes, that is my assumption. Probably a specific statement to that >> effect should be added. >> >>> Editorial comments >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> - Section 1, 4th line >>> =A0"the implement" -> "that implement. >> >> Thanks for spotting that. >> >>> - Pg 5, line 9 from bottom >>> =A0depend -> and depending >> >> Thanks again. >> >> For a version show suggested resolutions of your comments and a >> comparison to the current -04, see >> http://www.pothole.com/~dee3/drafts/ >> >> 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 +1-508-333-2270 (cell) >> =A0155 Beaver Street, Milford, MA 01757 USA >> =A0d3e3e3@gmail.com >> >>> On Wed, Feb 1, 2012 at 8:00 PM, Erik Nordmark wrote: >>>> On 2/1/12 5:33 PM, Yizhou Li wrote: >>>>> The latest version should be 04. >>>> >>>> Yes. Thanks for the correction. >>>> >>>> =A0 =A0Erik >>>> >>>>> Yizhou >>>>> >>>>> -----Original Message----- >>>>> From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] = On >>>>> Behalf Of Erik Nordmark >>>>> Sent: Thursday, February 02, 2012 3:26 AM >>>>> To: rbridge@postel.org >>>>> Subject: [rbridge] WG last call of draft-ietf-trill-rbridge-channel-03 >>>>> >>>>> >>>>> We're starting three separate last calls this week, but they are all >>>>> very short documents. >>>>> >>>>> We had an earlier WG last call on this document 6 months ago, and the= re >>>>> were some concerns about using the IS-IS genapp mechanism, so that use >>>>> has been removed. >>>>> >>>>> The WG last call ends on Feb 15th. >>>>> Please send comments (including ones that say you've read the document >>>>> and it is fine) to the rbridge list. >>>>> >>>>> =A0 =A0 Erik _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge From rbridge-bounces@postel.org Tue Feb 14 23:11:24 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 3CDCD21E8050 for ; Tue, 14 Feb 2012 23:11:24 -0800 (PST) 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 tOjiWGN1qpiz for ; Tue, 14 Feb 2012 23:11:22 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id C752421E8013 for ; Tue, 14 Feb 2012 23:11:21 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1F6kXx3028080; Tue, 14 Feb 2012 22:46:34 -0800 (PST) Received: from mail-pz0-f52.google.com (mail-pz0-f52.google.com [209.85.210.52]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1F6k5ct028001 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 14 Feb 2012 22:46:14 -0800 (PST) Received: by dado14 with SMTP id o14so869588dad.39 for ; Tue, 14 Feb 2012 22:46:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=I4DNXDVIjmIIecxm/9tWX3o5jTpbggvFhuKIW6LSSRs=; b=dvVxl3f8z2PTeqJCmfZfpYR5PMRE/KCiCxuI515MQPpTX8mp+rJeAPlsAhrFV1OvyN wHxj+AE6C/ddNyJTlukTpHpBrZseM2hDt6do4X3BUurlcp+U3G98XUrNWz4IrU5P+ANY Qq22J6nnNIla7Bgc8v8xyp/c06oUl9ZLgXflM= MIME-Version: 1.0 Received: by 10.68.226.98 with SMTP id rr2mr285248pbc.115.1329288365051; Tue, 14 Feb 2012 22:46:05 -0800 (PST) Received: by 10.142.195.15 with HTTP; Tue, 14 Feb 2012 22:46:05 -0800 (PST) In-Reply-To: References: Date: Wed, 15 Feb 2012 12:16:05 +0530 Message-ID: From: rakesh kumar To: Donald Eastlake X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rakesh51086@gmail.com Cc: rbridge@postel.org Subject: Re: [rbridge] draft-ietf-trill-rbridge-channel-04 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="===============0459710646==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org --===============0459710646== Content-Type: multipart/alternative; boundary=e89a8ff256f8cd8d4204b8fb10cb --e89a8ff256f8cd8d4204b8fb10cb Content-Type: text/plain; charset=ISO-8859-1 Hi Donald, I felt ,RBridge Channel messages should be send on point-to-point link during different states of point-to-point adjacency formation i.e.before and after formation of adjacency.I agree this is implicit but it is better if it is specified explicitly in draft. Please correct me if am wrong. Regards, Rakesh On Tue, Feb 14, 2012 at 5:45 PM, Donald Eastlake wrote: > Hi Rakesh, > > On Tue, Feb 14, 2012 at 1:50 AM, rakesh kumar > wrote: > > Hi Authors, > > > > In draft-ietf-trill-rbridge-channel-04 Section 2.4 > > > > "However, special considerations apply to the first hop because, > > for some RBridge Channel protocols, it may be desirable to send > > RBridge Channel messages on links that are not yet fully up. In > > particular, it is permissible, if specified by the particular channel > > protocol, for the source RBridge that has created an RBridge Channel > > message to attempt to transmit it to a next hop RBridge when the link > > is in the Detect or Two-Way states, as specified in [RFC6327], as well > > as when it is in the Report state." > > > > This doesn't talk about Point-to-point link.I think Point-to-point link > > also needs to be addressed here. > > What kind of thing do you think it should say? If, for example, you > are unicasting an RBridge channel frame to a next hop RBridge, why > does it matter if the link is point-to-point or multi-access? > > > Regards, > > Rakesh > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > --e89a8ff256f8cd8d4204b8fb10cb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Donald,
=A0 =A0 =A0=A0 I felt ,RBridge Channel messages should be sen= d on point-to-point link during different states of point-to-point adjacenc= y formation i.e.before and after formation of adjacency.I agree this is imp= licit but it is better if it is specified explicitly in draft.

=A0Please correct me if am wrong.

Regards,
Rakesh

On Tue, Feb 14, 2012 at 5:45 PM, Donald Eastlake <d3e3e3@gmail.com= > wrote:
Hi Rakesh,

On Tue, Feb 14, 2012 at 1:50 AM, rakesh kumar <rakesh51086@gmail.com> wrote:
> Hi Authors,
>
> In draft-ietf-trill-rbridge-channel-04 Section 2.4
>
> "However, special considerations apply to the first hop because,<= br> > for some RBridge Channel protocols, it may be desirable to send
> RBridge Channel messages on links that are not yet fully up. In
> particular, it is permissible, if specified by the particular channel<= br> > protocol, for the source RBridge that has created an RBridge Channel > message to attempt to transmit it to a next hop RBridge when the link<= br> > is in the Detect or Two-Way states, as specified in [RFC6327], as well=
> as when it is in the Report state."
>
> This doesn't talk about =A0Point-to-point link.I think=A0Point-to-= point link
> also needs to be addressed here.

What kind of thing do you think it should say? If, for example,= you
are unicasting an RBridge channel frame to a next hop RBridge, why
does it matter if the link is point-to-point or multi-access?

> Regards,
> Rakesh

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

--e89a8ff256f8cd8d4204b8fb10cb-- --===============0459710646== 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 --===============0459710646==-- From rbridge-bounces@postel.org Wed Feb 15 08:37:44 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 981DE21E8069 for ; Wed, 15 Feb 2012 08:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.662 X-Spam-Level: X-Spam-Status: No, score=-105.662 tagged_above=-999 required=5 tests=[AWL=0.937, 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 Tnw8w3xAqHDb for ; Wed, 15 Feb 2012 08:37:40 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 5C44B21E8067 for ; Wed, 15 Feb 2012 08:37:40 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1FGJCeA001899; Wed, 15 Feb 2012 08:19:14 -0800 (PST) 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 q1FGIYql001699 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 15 Feb 2012 08:18:44 -0800 (PST) Received: by lagy4 with SMTP id y4so1933228lag.39 for ; Wed, 15 Feb 2012 08:18:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=Q3ew+mT9k1KOVZQJMv7/f8SOIiFYIb5CMttIYPq5o7s=; b=Y7lwTE4fwif9k5WD4Y4MFbajppV9jCpvM3HzFKtgj9lxT7fl95QQYGDki9fD5kXtM5 FDBa2JHvyuDvtg3mK+wpDC4nV5RzNqsx3s5OSzForuWIBWex0CZoLWTqyBYayo93IYB6 LCrMnqWfKVeAdMW+BNIJ4WRfrnv6Og9iYDrxE= Received: by 10.112.85.137 with SMTP id h9mr350756lbz.51.1329322713303; Wed, 15 Feb 2012 08:18:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.21.7 with HTTP; Wed, 15 Feb 2012 08:18:13 -0800 (PST) In-Reply-To: <4F299636.7060604@acm.org> References: <4F299636.7060604@acm.org> From: Donald Eastlake Date: Wed, 15 Feb 2012 11:18:13 -0500 Message-ID: To: Erik Nordmark 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 q1FGIYql001699 Cc: "rbridge@postel.org" Subject: Re: [rbridge] WG last call on draft-ietf-trill-rbridge-bfd-02 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 Editorial Comments on draft-ietf-trill-rbridge-bfd-02.txt In the body of the text, the RBridge Channel draft is sometimes references as "[TRILLChannel]" and sometimes as "[TRILLoam]". Since TRILLChannel seems clearer and is how it actually appears in the Normative References section, suggest globally replacing "TRILLoam" with "TRILLChannel". In Section 12, it would be clearer if "range" was replaced by "range of RBridge Channel protocol numbers". In the References, I believe RFCs 5082 and 5586 should be moved from Normative to Informational. Typos: "plaen" -> "plane" 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, Feb 1, 2012 at 2:44 PM, Erik Nordmark wrote: > > The WG last call ends on Feb 15th. > Please send comments (including ones that say you've read the document > and it is fine) to the rbridge list. > > =A0 Erik > _______________________________________________ > 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 Feb 15 15:17: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 5F55221E804B for ; Wed, 15 Feb 2012 15:17:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.614 X-Spam-Level: X-Spam-Status: No, score=-4.614 tagged_above=-999 required=5 tests=[AWL=1.985, 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 DGKY1B7h083b for ; Wed, 15 Feb 2012 15:17:09 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 0B35A21E8032 for ; Wed, 15 Feb 2012 15:17:08 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1FN2W5O012141; Wed, 15 Feb 2012 15:02:32 -0800 (PST) Received: from mail-pz0-f52.google.com (mail-pz0-f52.google.com [209.85.210.52]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1FN2BIp012094 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 15 Feb 2012 15:02:20 -0800 (PST) Received: by dado14 with SMTP id o14so1816193dad.39 for ; Wed, 15 Feb 2012 15:02:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=rW0WJgcTOU9iilbcBv9SJcE3MS9cNkujk7O4d2F73Jw=; b=h0Ix8+kcJMtCgwKPLyzx77SendzE7P1s6T/+EyoDlXn1GLSEcEl7javyDHUGue2ETm 1DZMyhp1YbQmpvRAk0nT+Q6xRXmbB0VHpf109WYp739s0GWM4rAtj7woqw4/1s0n0SjZ MHPsMYwRqwxIqXJSVmB6Ico0dWK/JWsmALzbM= Received: by 10.68.216.4 with SMTP id om4mr7706160pbc.19.1329346929852; Wed, 15 Feb 2012 15:02:09 -0800 (PST) Received: from [192.168.255.74] ([12.207.18.42]) by mx.google.com with ESMTPS id f9sm579740pbq.60.2012.02.15.15.02.08 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 15 Feb 2012 15:02:08 -0800 (PST) References: <20120109132058.9151.5560.idtracker@ietfa.amsl.com> In-Reply-To: Mime-Version: 1.0 (1.0) Message-Id: <5BA18EC2-5CB1-432B-A9D4-BA6BE151CB17@gmail.com> X-Mailer: iPad Mail (9A405) From: Sam Aldrin Date: Wed, 15 Feb 2012 15:02:06 -0800 To: Donald Eastlake X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: aldrin.ietf@gmail.com X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id q1FN2BIp012094 Cc: "rbridge@postel.org" Subject: Re: [rbridge] I-D Action: draft-ietf-trill-rbridge-extension-02.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 Dear authors of the draft, I have read thought the latest version of the draft. I feel this is very useful extension to the header and I support this publication. I do have few questions, which I hope could be addressed easily. Apologize if they got answered already during earlier versions of the draft. You could safely drop the questions, in the true spirit of this draft :D 1. I understand from the draft wording that, if the rbridge do not support all of the critical header flag extensions, the frame should be dropped. What exactly is the definition of support. Does that mean, it do cannot parse the header extension OR it can understand the flag but chose not to implement? For example, if a frame is sent with critical ingress to egress extension, then only RBridges which support the extension can egress that. Wouldn't that create backward compatibility problem, as frames get dropped? 2. What if the rbridge could interpret these critical flags but chose to not implement? Should it drop the frames as well? 3. Keeping my OAM hat on, how would I know a rbridge do or do not support critical options? Instead of mandating the frame be dropped, if the frame is OAM frame, it should get punted for local processing. That way, an appropriate code could be sent back in the response for the OAM frame. Cheers Sam Sent from my iPad On Jan 9, 2012, at 8:18 PM, Donald Eastlake wrote: > This version incorporates change discussed on the WG mailing list. > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > > > On Mon, Jan 9, 2012 at 8:20 AM, wrote: >> >> 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: Header Extension >> Author(s) : Donald Eastlake >> Anoop Ghanwani >> Vishwas Manral >> Yizhou Li >> Caitlin Bestler >> Filename : draft-ietf-trill-rbridge-extension-02.txt >> Pages : 16 >> Date : 2012-01-09 >> >> The IETF TRILL (Transparent Interconnection of Lots of Links) base >> protocol specifies minimal hooks to safely support TRILL Header >> extensions. This document specifies an initial extension providing >> additional flag bits and specifies two of those bits. >> >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-extension-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-rbridge-extension-02.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 Feb 15 15:35:36 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 BF18D21E8086 for ; Wed, 15 Feb 2012 15:35:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.945 X-Spam-Level: X-Spam-Status: No, score=-4.945 tagged_above=-999 required=5 tests=[AWL=1.654, 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 It3v0wDFxg1K for ; Wed, 15 Feb 2012 15:35:32 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id AD87221E801D for ; Wed, 15 Feb 2012 15:35:32 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1FNEt4E014211; Wed, 15 Feb 2012 15:14:56 -0800 (PST) Received: from mail-pw0-f52.google.com (mail-pw0-f52.google.com [209.85.160.52]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1FNEehc014133 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 15 Feb 2012 15:14:49 -0800 (PST) Received: by pbbjt11 with SMTP id jt11so2445748pbb.39 for ; Wed, 15 Feb 2012 15:14:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=3eqWEDbxzSpbteEtGrPYPT6w8K4qDUg9HarpaeydgKE=; b=IWRF6M3uPU07yvMJCso6tHFtha2X5ZR4iJV/tMs7vgnTHmoBc16DTLB1NWRseRnQ4F hJiXs+09DzAovF/w/TDtAI8FjVj3ysD+Ra0CyIvRdXPrrepjIA6x26UtvoySkKEIbbv6 qkXrU4R/0C47lJivUTdFTtkJgQE6XuPh+VRvw= Received: by 10.68.138.194 with SMTP id qs2mr7430066pbb.53.1329347679759; Wed, 15 Feb 2012 15:14:39 -0800 (PST) Received: from [192.168.255.74] ([12.207.18.42]) by mx.google.com with ESMTPS id li19sm12159349pbb.17.2012.02.15.15.14.38 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 15 Feb 2012 15:14:39 -0800 (PST) References: <4F299636.7060604@acm.org> In-Reply-To: <4F299636.7060604@acm.org> Mime-Version: 1.0 (1.0) Message-Id: X-Mailer: iPad Mail (9A405) From: Sam Aldrin Date: Wed, 15 Feb 2012 15:14:37 -0800 To: Erik Nordmark X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: aldrin.ietf@gmail.com X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id q1FNEehc014133 Cc: "rbridge@postel.org" Subject: Re: [rbridge] WG last call on draft-ietf-trill-rbridge-bfd-02 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 I've read the latest version of the draft and looks fine. Have no further comments. Cheers Sam Sent from my iPad On Feb 1, 2012, at 11:44 AM, Erik Nordmark wrote: > > The WG last call ends on Feb 15th. > Please send comments (including ones that say you've read the document > and it is fine) to the rbridge list. > > Erik > _______________________________________________ > 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 Feb 15 18:08:19 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 1E2A921E8053 for ; Wed, 15 Feb 2012 18:08:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.177 X-Spam-Level: X-Spam-Status: No, score=-4.177 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_54=0.6, 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 kAbTTRYFIPN0 for ; Wed, 15 Feb 2012 18:08:14 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 68EDF21E80BD for ; Wed, 15 Feb 2012 18:08:10 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1G1k3HV009194; Wed, 15 Feb 2012 17:46:05 -0800 (PST) Received: from mail-qw0-f45.google.com (mail-qw0-f45.google.com [209.85.216.45]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1G1jec7009121 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 15 Feb 2012 17:45:49 -0800 (PST) Received: by qabg40 with SMTP id g40so4860727qab.18 for ; Wed, 15 Feb 2012 17:45:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+rrVf35EjA/KuQ1ujE36egZGqeAM2qNZZxQYslGv+5M=; b=mjH6Dnhn9+req71WLALSn7lOl5jn64ji7Tbb1AFWT5scIaxtrSG6AnKc/V3OTJCw08 OSKgc/tmdBtxeAePuw3bP/u51i+nBYR47SVbgoAq3Vjomwbs6MsXITI+jFiQa9q6QF22 hZn/NQm5H6y/byQ95UXLpZuaK7wEf4CrRB0rc= MIME-Version: 1.0 Received: by 10.229.114.210 with SMTP id f18mr445466qcq.54.1329356739982; Wed, 15 Feb 2012 17:45:39 -0800 (PST) Received: by 10.229.155.206 with HTTP; Wed, 15 Feb 2012 17:45:39 -0800 (PST) In-Reply-To: References: <4F2991C6.7070904@acm.org> <012b01cce14a$9b0dbca0$d12935e0$@com> <4F2A0A63.30907@acm.org> Date: Wed, 15 Feb 2012 17:45:39 -0800 X-Google-Sender-Auth: spxquTSf04n6EzhwWMC8sq4FGWc Message-ID: From: Anoop Ghanwani To: Donald Eastlake X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: ghanwani@gmail.com X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id q1G1jec7009121 Cc: rbridge@postel.org, Erik Nordmark , Yizhou Li Subject: Re: [rbridge] WG last call of draft-ietf-trill-rbridge-channel-04 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, OK, regarding the use of the extended header, I guess I can live with it, assuming others are OK with it. Regarding the "egressing" issue, I assume you'll be modifying the text to make it clearer. It might also be good to have a statement that says channel messages only go between RBridges, or between an Rbridge and an end station; i.e. you can't have a channel message that goes from a "core" Rbridge to an end station without going through processing (which is more than simple egress decapsulation) at the egress RBridge. Thanks, Anoop On Tue, Feb 14, 2012 at 9:02 PM, Donald Eastlake wrote: > Hi Anoop, > > On Tue, Feb 14, 2012 at 11:45 AM, Anoop Ghanwani = wrote: >> Hi Donald, >> >> Thanks for the response. =A0I have pulled out sections of the >> text that I want to respond to. >> >>> Anyway, setting the TRILL Header Extension Length (called Options >>> Length in RFC 6325) non-zero causes all the TRILL silicon I know about >>> to divert the frame to the slow path, which is the desired effect for >>> now. There is no need for the fast path logic to "look at" the >>> extended header at this time. >> >> But it probably won't be able to prioritize the frame >> correctly. > > I don't see why there would be a prioritization problem. The > Inner.VLAN tag is still there with the priority for re-queueing the > frame if it is forwarded. > >> If a message is going to be processed hop-by-hop, and it is >> unicast, would it not be better to just use the "AnyRBridge" nickname >> and embed the eventual egress RBridge in the payload? =A0That way >> it becomes easily compatible with existing hardware. =A0So, for the >> multicast case, we use a different reserved MAC, and for the >> unicast case we use AnyRBridge. =A0I don't see that there would be >> any loss of functionality if we did that. > > The technique currently in the draft also seems to work fine and, > given that it previously got WG consensus, I don't particularly want > to change it. > >>> "Egressing" means being decapsulated, that is, leaving the TRILL >>> tunnel. You are correct that RBridge Channel protocol frames are only >>> intended to go between RBridges. But there are native RBridge Channel >>> messages that go between RBridges and end stations on the same link as >>> described in Section 4. An RBridge can create a native RBridge Channel >>> frame and unicast it to an attached end station, etc. >> >> Per your description, this would not be a valid case of >> "egressing", so the above text wouldn't apply to this case. > > There are two things being discussed. An RBridge-to-RBridge channel > message does get de-capsulated/egressed at its egress RBridge(s) (can > be more than one if multi-destination). But you are right that > creation and transmission and the reception and processing of a native > channel message does not involve "egressing" or "engrossing". > >>> You could also have a channel protocol, for example, that went from an >>> RBridge RB1, through RB2, to an end station or from that end station >>> through RB2 to RB1, but the frames would have to be manipulated by >>> that channel protocol at RB2 to convert between non-native and native >>> forms. At a minimum, the native channel frame has no TRILL Header >>> while the non-native inter-RBridge channel frame does. In addition, >>> you would have to complement the NA bit in the Channel Header and >>> adjust MAC addresses. That's what the next to the last paragraph in >>> Section 4 is about. But I would think that almost all channel >>> protocols would either be between RBridges or between an edge RBridge >>> and an end station. >> >> Would the case of manipulation be considered "egressing"? > > No, I don't think so. If the message went from RB1 to edge RBridge > RB2, it would be decapitated (egressed) at RB2. The manipulate would > be after the egressing and before the transmission as a native frame. > >> Since egressing in the strict sense is simplying decapsulating the >> frame and sending it out as a native frame, it seems to me that >> the scenario described in the quoted text should never happen. > > I guess you are right. I was using "egressing" in other than the > strictest sense -- as decapsulating and delivering, where delivering > might be transmitting through an external port but could just be > delivering to the slow path... > >> Anoop > > 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, Feb 13, 2012 at 7:22 PM, Donald Eastlake wrot= e: >>> Hi Anoop, >>> >>> Thanks for the comments. See below: >>> >>> On Thu, Feb 9, 2012 at 2:50 PM, Anoop Ghanwani = wrote: >>>> Here are some comments on the document. >>>> >>>> Technical comments >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> >>>> - I'm a bit concerned about the hop-by-hop processing which requires >>>> the ability to look at a bit in the extended header. I don't know if >>>> any alternatives were discussed...perhaps using a different >>>> inner.MACDA multicast address which indicates hop-by-hop processing >>>> is desired would work much better and would be compatible with >>>> existing silicon. Would there be any issues with using a separate >>>> multicast address for indicating hop-by-hop processing? >>> >>> I think the vast majority of channel protocols will either be (1) one >>> hop or (2) multi-hop with no per hop processing. In the case of a >>> multi-hop channel protocol frame that needs hop-by-hop processing (for >>> example something like record route or some protocol that wants source >>> routing), there are lots of ways you could modify such a frame to >>> alert the transit RBridges along the way. But these frames will >>> commonly be unicast, in which case there is no reason in the TRILL >>> base protocol for a transit RBridge to look at anything after the >>> TRILL Header, such as the Inner.MacDA. So you need to change something >>> in the TRILL Header. You could use a bit in the V field and/or the R >>> field, but people seemed to be against using those bits. >>> >>> Anyway, setting the TRILL Header Extension Length (called Options >>> Length in RFC 6325) non-zero causes all the TRILL silicon I know about >>> to divert the frame to the slow path, which is the desired effect for >>> now. There is no need for the fast path logic to "look at" the >>> extended header at this time. >>> >>> This is exactly how it was in the earlier version of this draft which >>> passed WGLC: >>> http://tools.ietf.org/html/draft-ietf-trill-rbridge-channel-01 >>> The only difference is that, in response to comments on this list, the >>> previous non-critical Alert Flag was supplemented by a critical Alert >>> Flag. >>> >>>> - State that the "Available Flags" part is reserved; i.e. set to >>>>zero on transmit, ignore on receipt. >>> >>> An excellent suggestion. How about, in Section 2.1.1, changing the >>> figure so the bits are labeled "Reserved" instead of "Available Flags" >>> and, after the descriptions of bits 0 thorugh 2, adding something >>> like: >>> >>> =A0 "Reserved: Bits reserved for future specification that MUST be sent >>> as zero and ignored on receipt." >>> >>>> - Section 3 >>>> >>> >>>> =A0 =A0 =A02. If an RBridge Channel Alert extended header flag is set,= then >>>> =A0 =A0 =A0 =A0 the RBridge MUST process the RBridge Channel message as >>>> =A0 =A0 =A0 =A0 described below even if it is not egressing the frame.= If it is >>>> =A0 =A0 =A0 =A0 egressing the frame, then no additional processing bey= ond >>>> =A0 =A0 =A0 =A0 egress processing is needed even if an RBridge Channel= Alert >>>> =A0 =A0 =A0 =A0 flag is set. >>>> >>> >>>> Since the inner.MACDA is always All-Egress-RBridges, how would such >>>> a frame ever be allowed to be sent out an egress RBridge? It seems >>>> like end station can send a channel message, but an RBridge can't >>>> send one to an end station. >>> >>> "Egressing" means being decapsulated, that is, leaving the TRILL >>> tunnel. You are correct that RBridge Channel protocol frames are only >>> intended to go between RBridges. But there are native RBridge Channel >>> messages that go between RBridges and end stations on the same link as >>> described in Section 4. An RBridge can create a native RBridge Channel >>> frame and unicast it to an attached end station, etc. >>> >>> You could also have a channel protocol, for example, that went from an >>> RBridge RB1, through RB2, to an end station or from that end station >>> through RB2 to RB1, but the frames would have to be manipulated by >>> that channel protocol at RB2 to convert between non-native and native >>> forms. At a minimum, the native channel frame has no TRILL Header >>> while the non-native inter-RBridge channel frame does. In addition, >>> you would have to complement the NA bit in the Channel Header and >>> adjust MAC addresses. That's what the next to the last paragraph in >>> Section 4 is about. But I would think that almost all channel >>> protocols would either be between RBridges or between an edge RBridge >>> and an end station. >>> >>>> - Section 3.2 >>>> >>> >>>> =A0 For the protocol specific data area, an >>>> =A0 RBridge Channel Message Error frame has at least the first 256 byt= es >>>> =A0 (or less if less are available) of the erroneous decapsulated chan= nel >>>> =A0 message starting with the TRILL Header. (Note: The TRILL Header do= es >>>> =A0 not include the TRILL Ethertype that is part of the Link Header on >>>> =A0 Ethernet Links and may be absent for other link technologies.) >>>> >>> >>>> >>>> What if the channel frame is a native frame? This aspect is not >>>> dealt with even in the section concerning native frames. >>> >>> Good point. The idea is to have all the differences between native and >>> non-native channel frames described in Section 4. The last paragraph >>> of Section 4 already mentions one native RBridge channel error message >>> difference. That last pragraph in Section 4 should have something like >>> the following added: >>> >>> =A0 "Also, since there is no TRILL Header in native RBridge Channel >>> =A0 protocol frames, the beginning part of the frame in which the error >>> =A0 was detected that is included in native RBridge Channel error >>> =A0 frames starts with the RBridge Channel Header." >>> >>>> - Section 4 >>>> =A0>>> >>>> =A0 =A0 =A02. If the frame is unicast, the destination MAC address is = the >>>> =A0 =A0 =A0 =A0 unicast MAC address of the RBridge or end-station port= that is >>>> =A0 =A0 =A0 =A0 its intended destination. If the frame is multicast by= an end >>>> =A0 =A0 =A0 =A0 station to all the RBridges on a link that support an = RBridge >>>> =A0 =A0 =A0 =A0 Channel protocol that uses this transport, the destina= tion MAC >>>> =A0 =A0 =A0 =A0 address is the All-Edge-RBridges multicast address. If= the >>>> =A0 =A0 =A0 =A0 frame is multicast by an RBridge to all the devices th= at TRILL >>>> =A0 =A0 =A0 =A0 considers to be end stations on a link that support an= RBridge >>>> =A0 =A0 =A0 =A0 Channel protocol that uses this transport, the destina= tion MAC >>>> =A0 =A0 =A0 =A0 address is the TRILL-End-Stations multicast address (s= ee >>>> =A0 =A0 =A0 =A0 Section 6). The RBridge-Channel Ethertype must be pres= ent. In >>>> =A0 =A0 =A0 =A0 the future there may be other protocols using the All-= Edge- >>>> =A0 =A0 =A0 =A0 RBridges and/or TRILL-End-Stations multicast addresses= on >>>> =A0 =A0 =A0 =A0 native frames distinguished by different Ethertypes. >>>> >>> >>>> This imposes some interesting requirements for filtering on ingress >>>> to the RBridge. >>> >>> It only imposes requirements on edge RBridges (or end stations) that >>> want to support one or more native RBridge channel protocols... >>> >>>> For example, what if the address on a channel frame >>>> does not match any of the ones specified above? >>> >>> I assume you are talking about a native RBridge channel frame since >>> the requirements on the Outer.MacDA of non-native RBridge channel >>> frames is the same as on TRILL Data frames. >>> >>> So, as per the text above, a native RBridge channel frame arriving at >>> an edge RBridge must have an Outer.MacDA of either the port's unicast >>> MAC address of the All-Edge-RBridges multicast address. If it has a >>> different unicast address, it is presumably intended for another >>> RBridge on the link and is discarded. If it has a different multicast >>> address, it is discarded. >>> >>>> Do we assume that >>>> channel messages received in native format must either be processed >>>> by the receiving RBridge or discarded? In other words it should not >>>> be possible to send a channel protocol frame from outside the TRILL >>>> network that enters or transits the TRILL network. >>> >>> Yes, that is my assumption. Probably a specific statement to that >>> effect should be added. >>> >>>> Editorial comments >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> - Section 1, 4th line >>>> =A0"the implement" -> "that implement. >>> >>> Thanks for spotting that. >>> >>>> - Pg 5, line 9 from bottom >>>> =A0depend -> and depending >>> >>> Thanks again. >>> >>> For a version show suggested resolutions of your comments and a >>> comparison to the current -04, see >>> http://www.pothole.com/~dee3/drafts/ >>> >>> 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 +1-508-333-2270 (cell) >>> =A0155 Beaver Street, Milford, MA 01757 USA >>> =A0d3e3e3@gmail.com >>> >>>> On Wed, Feb 1, 2012 at 8:00 PM, Erik Nordmark wrote: >>>>> On 2/1/12 5:33 PM, Yizhou Li wrote: >>>>>> The latest version should be 04. >>>>> >>>>> Yes. Thanks for the correction. >>>>> >>>>> =A0 =A0Erik >>>>> >>>>>> Yizhou >>>>>> >>>>>> -----Original Message----- >>>>>> From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org]= On >>>>>> Behalf Of Erik Nordmark >>>>>> Sent: Thursday, February 02, 2012 3:26 AM >>>>>> To: rbridge@postel.org >>>>>> Subject: [rbridge] WG last call of draft-ietf-trill-rbridge-channel-= 03 >>>>>> >>>>>> >>>>>> We're starting three separate last calls this week, but they are all >>>>>> very short documents. >>>>>> >>>>>> We had an earlier WG last call on this document 6 months ago, and th= ere >>>>>> were some concerns about using the IS-IS genapp mechanism, so that u= se >>>>>> has been removed. >>>>>> >>>>>> The WG last call ends on Feb 15th. >>>>>> Please send comments (including ones that say you've read the docume= nt >>>>>> and it is fine) to the rbridge list. >>>>>> >>>>>> =A0 =A0 Erik _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge From rbridge-bounces@postel.org Wed Feb 15 20:31:02 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 4F7DA21E803C for ; Wed, 15 Feb 2012 20:31:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.68 X-Spam-Level: X-Spam-Status: No, score=-105.68 tagged_above=-999 required=5 tests=[AWL=0.919, 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 e1jdrgbDr2rm for ; Wed, 15 Feb 2012 20:30:58 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 1787C21E801A for ; Wed, 15 Feb 2012 20:30:58 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1G48beS028712; Wed, 15 Feb 2012 20:08:38 -0800 (PST) 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 q1G47tAn028428 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 15 Feb 2012 20:08:05 -0800 (PST) Received: by lagy4 with SMTP id y4so3033874lag.39 for ; Wed, 15 Feb 2012 20:07:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=QpEZDr8uTJodYQP4nCXGq7BNMBGIzC7MFlgk0UhioqE=; b=VFlvNOqtGHihO9LKC9s7mXpopT21zAF8YLKTY828ipEnP8CExEePTdUVuTaP1Cgu+p 4pERFpIPA5siQMYw6MHjRBn1YdvCRZRK2kqiGekx1Ax1o7+B33B+fHhB/8ZWoHOD73qS 31zVUZNWDACDUlnAWHHO7a3LUWp+9/uOdE5Kc= Received: by 10.152.128.202 with SMTP id nq10mr603688lab.11.1329365274319; Wed, 15 Feb 2012 20:07:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.21.7 with HTTP; Wed, 15 Feb 2012 20:07:34 -0800 (PST) In-Reply-To: References: From: Donald Eastlake Date: Wed, 15 Feb 2012 23:07:34 -0500 Message-ID: To: rakesh kumar 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 q1G47tAn028428 Cc: rbridge@postel.org Subject: Re: [rbridge] draft-ietf-trill-rbridge-channel-04 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 Rakesh, On Wed, Feb 15, 2012 at 1:46 AM, rakesh kumar wrote: > Hi Donald, > =A0 =A0 =A0=A0 I felt ,RBridge Channel messages should be send on point-t= o-point > link during different states of point-to-point adjacency formation > i.e.before and after formation of adjacency.I agree this is implicit but = it > is better if it is specified explicitly in draft. OK. How about adding, to the end of the second paragraph of Section 2.4 of the draft "Such messages can also be sent on point-to-point links that are not in the Up state." > =A0Please correct me if am wrong. 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 > Regards, > Rakesh > > > On Tue, Feb 14, 2012 at 5:45 PM, Donald Eastlake wrote: >> >> Hi Rakesh, >> >> On Tue, Feb 14, 2012 at 1:50 AM, rakesh kumar >> wrote: >> > Hi Authors, >> > >> > In draft-ietf-trill-rbridge-channel-04 Section 2.4 >> > >> > "However, special considerations apply to the first hop because, >> > for some RBridge Channel protocols, it may be desirable to send >> > RBridge Channel messages on links that are not yet fully up. In >> > particular, it is permissible, if specified by the particular channel >> > protocol, for the source RBridge that has created an RBridge Channel >> > message to attempt to transmit it to a next hop RBridge when the link >> > is in the Detect or Two-Way states, as specified in [RFC6327], as well >> > as when it is in the Report state." >> > >> > This doesn't talk about =A0Point-to-point link.I think=A0Point-to-poin= t link >> > also needs to be addressed here. >> >> What kind of thing do you think it should say? If, for example, you >> are unicasting an RBridge channel frame to a next hop RBridge, why >> does it matter if the link is point-to-point or multi-access? >> >> > Regards, >> > Rakesh >> >> 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 Wed Feb 15 21:20:12 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 3373C21E8010 for ; Wed, 15 Feb 2012 21:20:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.098 X-Spam-Level: X-Spam-Status: No, score=-105.098 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, 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 nNaDFt1LKEwL for ; Wed, 15 Feb 2012 21:20:07 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 502F411E8074 for ; Wed, 15 Feb 2012 21:20:07 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1G4wb4b005425; Wed, 15 Feb 2012 20:58:40 -0800 (PST) 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 q1G4w72J005058 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 15 Feb 2012 20:58:17 -0800 (PST) Received: by lagy4 with SMTP id y4so3091507lag.39 for ; Wed, 15 Feb 2012 20:58:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=buV4YtK7TyGoz3tDsqKsolD5EFzXSC/CzsEEAKGc7z8=; b=Ahw5zjrMJXCzPY0XYbFsKxb2XmN/QMNIWmh7Sx3gxw79vcTjavd17+OGc8+eUG5gsn ebwPccPU/F3ArtwoDjQDO8r6cRv0AaYZeuWuAKjYuQjJO8Nsw3191bLr2Tb5LN1K7o+j fBFSqHcvsZik8APJqZetQCtlSIlPsSMDckNvc= Received: by 10.112.41.169 with SMTP id g9mr281302lbl.94.1329368286377; Wed, 15 Feb 2012 20:58:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.21.7 with HTTP; Wed, 15 Feb 2012 20:57:46 -0800 (PST) In-Reply-To: References: <4F2991C6.7070904@acm.org> <012b01cce14a$9b0dbca0$d12935e0$@com> <4F2A0A63.30907@acm.org> From: Donald Eastlake Date: Wed, 15 Feb 2012 23:57:46 -0500 Message-ID: To: Anoop Ghanwani 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 q1G4w72J005058 Cc: rbridge@postel.org, Erik Nordmark , Yizhou Li Subject: Re: [rbridge] WG last call of draft-ietf-trill-rbridge-channel-04 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 Anoop, On Wed, Feb 15, 2012 at 8:45 PM, Anoop Ghanwani wro= te: > Hi Donald, > > ... > > Regarding the "egressing" issue, I assume you'll be modifying > the text to make it clearer. =A0It might also be good to have a statement > that says channel messages only go between RBridges, > or between an Rbridge and an end station; i.e. you can't > have a channel message that goes from a "core" Rbridge > to an end station without going through processing (which > is more than simple egress decapsulation) at the egress > RBridge. OK. I'll try to make that clearer. 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, > Anoop > > On Tue, Feb 14, 2012 at 9:02 PM, Donald Eastlake wrote: >> Hi Anoop, >> >> On Tue, Feb 14, 2012 at 11:45 AM, Anoop Ghanwani = wrote: >>> Hi Donald, >>> >>> Thanks for the response. =A0I have pulled out sections of the >>> text that I want to respond to. >>> >>>> Anyway, setting the TRILL Header Extension Length (called Options >>>> Length in RFC 6325) non-zero causes all the TRILL silicon I know about >>>> to divert the frame to the slow path, which is the desired effect for >>>> now. There is no need for the fast path logic to "look at" the >>>> extended header at this time. >>> >>> But it probably won't be able to prioritize the frame >>> correctly. >> >> I don't see why there would be a prioritization problem. The >> Inner.VLAN tag is still there with the priority for re-queueing the >> frame if it is forwarded. >> >>> If a message is going to be processed hop-by-hop, and it is >>> unicast, would it not be better to just use the "AnyRBridge" nickname >>> and embed the eventual egress RBridge in the payload? =A0That way >>> it becomes easily compatible with existing hardware. =A0So, for the >>> multicast case, we use a different reserved MAC, and for the >>> unicast case we use AnyRBridge. =A0I don't see that there would be >>> any loss of functionality if we did that. >> >> The technique currently in the draft also seems to work fine and, >> given that it previously got WG consensus, I don't particularly want >> to change it. >> >>>> "Egressing" means being decapsulated, that is, leaving the TRILL >>>> tunnel. You are correct that RBridge Channel protocol frames are only >>>> intended to go between RBridges. But there are native RBridge Channel >>>> messages that go between RBridges and end stations on the same link as >>>> described in Section 4. An RBridge can create a native RBridge Channel >>>> frame and unicast it to an attached end station, etc. >>> >>> Per your description, this would not be a valid case of >>> "egressing", so the above text wouldn't apply to this case. >> >> There are two things being discussed. An RBridge-to-RBridge channel >> message does get de-capsulated/egressed at its egress RBridge(s) (can >> be more than one if multi-destination). But you are right that >> creation and transmission and the reception and processing of a native >> channel message does not involve "egressing" or "engrossing". >> >>>> You could also have a channel protocol, for example, that went from an >>>> RBridge RB1, through RB2, to an end station or from that end station >>>> through RB2 to RB1, but the frames would have to be manipulated by >>>> that channel protocol at RB2 to convert between non-native and native >>>> forms. At a minimum, the native channel frame has no TRILL Header >>>> while the non-native inter-RBridge channel frame does. In addition, >>>> you would have to complement the NA bit in the Channel Header and >>>> adjust MAC addresses. That's what the next to the last paragraph in >>>> Section 4 is about. But I would think that almost all channel >>>> protocols would either be between RBridges or between an edge RBridge >>>> and an end station. >>> >>> Would the case of manipulation be considered "egressing"? >> >> No, I don't think so. If the message went from RB1 to edge RBridge >> RB2, it would be decapitated (egressed) at RB2. The manipulate would >> be after the egressing and before the transmission as a native frame. >> >>> Since egressing in the strict sense is simplying decapsulating the >>> frame and sending it out as a native frame, it seems to me that >>> the scenario described in the quoted text should never happen. >> >> I guess you are right. I was using "egressing" in other than the >> strictest sense -- as decapsulating and delivering, where delivering >> might be transmitting through an external port but could just be >> delivering to the slow path... >> >>> Anoop >> >> 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, Feb 13, 2012 at 7:22 PM, Donald Eastlake wro= te: >>>> Hi Anoop, >>>> >>>> Thanks for the comments. See below: >>>> >>>> On Thu, Feb 9, 2012 at 2:50 PM, Anoop Ghanwani = wrote: >>>>> Here are some comments on the document. >>>>> >>>>> Technical comments >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> >>>>> - I'm a bit concerned about the hop-by-hop processing which requires >>>>> the ability to look at a bit in the extended header. I don't know if >>>>> any alternatives were discussed...perhaps using a different >>>>> inner.MACDA multicast address which indicates hop-by-hop processing >>>>> is desired would work much better and would be compatible with >>>>> existing silicon. Would there be any issues with using a separate >>>>> multicast address for indicating hop-by-hop processing? >>>> >>>> I think the vast majority of channel protocols will either be (1) one >>>> hop or (2) multi-hop with no per hop processing. In the case of a >>>> multi-hop channel protocol frame that needs hop-by-hop processing (for >>>> example something like record route or some protocol that wants source >>>> routing), there are lots of ways you could modify such a frame to >>>> alert the transit RBridges along the way. But these frames will >>>> commonly be unicast, in which case there is no reason in the TRILL >>>> base protocol for a transit RBridge to look at anything after the >>>> TRILL Header, such as the Inner.MacDA. So you need to change something >>>> in the TRILL Header. You could use a bit in the V field and/or the R >>>> field, but people seemed to be against using those bits. >>>> >>>> Anyway, setting the TRILL Header Extension Length (called Options >>>> Length in RFC 6325) non-zero causes all the TRILL silicon I know about >>>> to divert the frame to the slow path, which is the desired effect for >>>> now. There is no need for the fast path logic to "look at" the >>>> extended header at this time. >>>> >>>> This is exactly how it was in the earlier version of this draft which >>>> passed WGLC: >>>> http://tools.ietf.org/html/draft-ietf-trill-rbridge-channel-01 >>>> The only difference is that, in response to comments on this list, the >>>> previous non-critical Alert Flag was supplemented by a critical Alert >>>> Flag. >>>> >>>>> - State that the "Available Flags" part is reserved; i.e. set to >>>>>zero on transmit, ignore on receipt. >>>> >>>> An excellent suggestion. How about, in Section 2.1.1, changing the >>>> figure so the bits are labeled "Reserved" instead of "Available Flags" >>>> and, after the descriptions of bits 0 thorugh 2, adding something >>>> like: >>>> >>>> =A0 "Reserved: Bits reserved for future specification that MUST be sent >>>> as zero and ignored on receipt." >>>> >>>>> - Section 3 >>>>> >>> >>>>> =A0 =A0 =A02. If an RBridge Channel Alert extended header flag is set= , then >>>>> =A0 =A0 =A0 =A0 the RBridge MUST process the RBridge Channel message = as >>>>> =A0 =A0 =A0 =A0 described below even if it is not egressing the frame= . If it is >>>>> =A0 =A0 =A0 =A0 egressing the frame, then no additional processing be= yond >>>>> =A0 =A0 =A0 =A0 egress processing is needed even if an RBridge Channe= l Alert >>>>> =A0 =A0 =A0 =A0 flag is set. >>>>> >>> >>>>> Since the inner.MACDA is always All-Egress-RBridges, how would such >>>>> a frame ever be allowed to be sent out an egress RBridge? It seems >>>>> like end station can send a channel message, but an RBridge can't >>>>> send one to an end station. >>>> >>>> "Egressing" means being decapsulated, that is, leaving the TRILL >>>> tunnel. You are correct that RBridge Channel protocol frames are only >>>> intended to go between RBridges. But there are native RBridge Channel >>>> messages that go between RBridges and end stations on the same link as >>>> described in Section 4. An RBridge can create a native RBridge Channel >>>> frame and unicast it to an attached end station, etc. >>>> >>>> You could also have a channel protocol, for example, that went from an >>>> RBridge RB1, through RB2, to an end station or from that end station >>>> through RB2 to RB1, but the frames would have to be manipulated by >>>> that channel protocol at RB2 to convert between non-native and native >>>> forms. At a minimum, the native channel frame has no TRILL Header >>>> while the non-native inter-RBridge channel frame does. In addition, >>>> you would have to complement the NA bit in the Channel Header and >>>> adjust MAC addresses. That's what the next to the last paragraph in >>>> Section 4 is about. But I would think that almost all channel >>>> protocols would either be between RBridges or between an edge RBridge >>>> and an end station. >>>> >>>>> - Section 3.2 >>>>> >>> >>>>> =A0 For the protocol specific data area, an >>>>> =A0 RBridge Channel Message Error frame has at least the first 256 by= tes >>>>> =A0 (or less if less are available) of the erroneous decapsulated cha= nnel >>>>> =A0 message starting with the TRILL Header. (Note: The TRILL Header d= oes >>>>> =A0 not include the TRILL Ethertype that is part of the Link Header on >>>>> =A0 Ethernet Links and may be absent for other link technologies.) >>>>> >>> >>>>> >>>>> What if the channel frame is a native frame? This aspect is not >>>>> dealt with even in the section concerning native frames. >>>> >>>> Good point. The idea is to have all the differences between native and >>>> non-native channel frames described in Section 4. The last paragraph >>>> of Section 4 already mentions one native RBridge channel error message >>>> difference. That last pragraph in Section 4 should have something like >>>> the following added: >>>> >>>> =A0 "Also, since there is no TRILL Header in native RBridge Channel >>>> =A0 protocol frames, the beginning part of the frame in which the error >>>> =A0 was detected that is included in native RBridge Channel error >>>> =A0 frames starts with the RBridge Channel Header." >>>> >>>>> - Section 4 >>>>> =A0>>> >>>>> =A0 =A0 =A02. If the frame is unicast, the destination MAC address is= the >>>>> =A0 =A0 =A0 =A0 unicast MAC address of the RBridge or end-station por= t that is >>>>> =A0 =A0 =A0 =A0 its intended destination. If the frame is multicast b= y an end >>>>> =A0 =A0 =A0 =A0 station to all the RBridges on a link that support an= RBridge >>>>> =A0 =A0 =A0 =A0 Channel protocol that uses this transport, the destin= ation MAC >>>>> =A0 =A0 =A0 =A0 address is the All-Edge-RBridges multicast address. I= f the >>>>> =A0 =A0 =A0 =A0 frame is multicast by an RBridge to all the devices t= hat TRILL >>>>> =A0 =A0 =A0 =A0 considers to be end stations on a link that support a= n RBridge >>>>> =A0 =A0 =A0 =A0 Channel protocol that uses this transport, the destin= ation MAC >>>>> =A0 =A0 =A0 =A0 address is the TRILL-End-Stations multicast address (= see >>>>> =A0 =A0 =A0 =A0 Section 6). The RBridge-Channel Ethertype must be pre= sent. In >>>>> =A0 =A0 =A0 =A0 the future there may be other protocols using the All= -Edge- >>>>> =A0 =A0 =A0 =A0 RBridges and/or TRILL-End-Stations multicast addresse= s on >>>>> =A0 =A0 =A0 =A0 native frames distinguished by different Ethertypes. >>>>> >>> >>>>> This imposes some interesting requirements for filtering on ingress >>>>> to the RBridge. >>>> >>>> It only imposes requirements on edge RBridges (or end stations) that >>>> want to support one or more native RBridge channel protocols... >>>> >>>>> For example, what if the address on a channel frame >>>>> does not match any of the ones specified above? >>>> >>>> I assume you are talking about a native RBridge channel frame since >>>> the requirements on the Outer.MacDA of non-native RBridge channel >>>> frames is the same as on TRILL Data frames. >>>> >>>> So, as per the text above, a native RBridge channel frame arriving at >>>> an edge RBridge must have an Outer.MacDA of either the port's unicast >>>> MAC address of the All-Edge-RBridges multicast address. If it has a >>>> different unicast address, it is presumably intended for another >>>> RBridge on the link and is discarded. If it has a different multicast >>>> address, it is discarded. >>>> >>>>> Do we assume that >>>>> channel messages received in native format must either be processed >>>>> by the receiving RBridge or discarded? In other words it should not >>>>> be possible to send a channel protocol frame from outside the TRILL >>>>> network that enters or transits the TRILL network. >>>> >>>> Yes, that is my assumption. Probably a specific statement to that >>>> effect should be added. >>>> >>>>> Editorial comments >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> - Section 1, 4th line >>>>> =A0"the implement" -> "that implement. >>>> >>>> Thanks for spotting that. >>>> >>>>> - Pg 5, line 9 from bottom >>>>> =A0depend -> and depending >>>> >>>> Thanks again. >>>> >>>> For a version show suggested resolutions of your comments and a >>>> comparison to the current -04, see >>>> http://www.pothole.com/~dee3/drafts/ >>>> >>>> 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 +1-508-333-2270 (cell) >>>> =A0155 Beaver Street, Milford, MA 01757 USA >>>> =A0d3e3e3@gmail.com >>>> >>>>> On Wed, Feb 1, 2012 at 8:00 PM, Erik Nordmark wrot= e: >>>>>> On 2/1/12 5:33 PM, Yizhou Li wrote: >>>>>>> The latest version should be 04. >>>>>> >>>>>> Yes. Thanks for the correction. >>>>>> >>>>>> =A0 =A0Erik >>>>>> >>>>>>> Yizhou >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org= ] On >>>>>>> Behalf Of Erik Nordmark >>>>>>> Sent: Thursday, February 02, 2012 3:26 AM >>>>>>> To: rbridge@postel.org >>>>>>> Subject: [rbridge] WG last call of draft-ietf-trill-rbridge-channel= -03 >>>>>>> >>>>>>> >>>>>>> We're starting three separate last calls this week, but they are all >>>>>>> very short documents. >>>>>>> >>>>>>> We had an earlier WG last call on this document 6 months ago, and t= here >>>>>>> were some concerns about using the IS-IS genapp mechanism, so that = use >>>>>>> has been removed. >>>>>>> >>>>>>> The WG last call ends on Feb 15th. >>>>>>> Please send comments (including ones that say you've read the docum= ent >>>>>>> and it is fine) to the rbridge list. >>>>>>> >>>>>>> =A0 =A0 Erik _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge From rbridge-bounces@postel.org Wed Feb 15 21:40:24 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 DE28921E801A for ; Wed, 15 Feb 2012 21:40:22 -0800 (PST) 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 V-V8FwZ5JGqk for ; Wed, 15 Feb 2012 21:40:17 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id E786B21E804D for ; Wed, 15 Feb 2012 21:40:15 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1G5ScvO010090; Wed, 15 Feb 2012 21:28:40 -0800 (PST) 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 q1G5RvKm009692 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 15 Feb 2012 21:28:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ayabaner@cisco.com; l=3879; q=dns/txt; s=iport; t=1329370086; x=1330579686; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=bqFTu+rNVcAW4CldYMzmlOZ608obF2W9oktQDY4wWvI=; b=Oe8qPqhXjfQV2vdcOFfzYPKrwX6s8+lqOdtZ5aQrkaKWBDNUu/VjNjk2 MN188/khuvdWBWp2B6zMVasaXXe8qJbFx7NlC2WvmMKpRRNyXFe41IHND Cw/l2zqoAzwx2o9N7Fzwl7H5IAR/OvH0cfn2DmB8+69f1i8Ssnbv/NJsk o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAD6TPE+rRDoG/2dsb2JhbABAA7AEa4EHgXIBAQEDAQEBAQ8BKQExEA0BCAkFCk8GMAEBBAESIoddCZ5xAZZliESDBAMJAQgMBRMIAUkBBw2EJQIFCQwOgyIEiBozhRyHTYsTh3Y X-IronPort-AV: E=Sophos;i="4.73,427,1325462400"; d="scan'208";a="30779550" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 16 Feb 2012 05:27:57 +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 q1G5Ru2I020307; Thu, 16 Feb 2012 05:27:56 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, 15 Feb 2012 21:27:56 -0800 Received: from 10.21.151.247 ([10.21.151.247]) by xmb-sjc-22b.amer.cisco.com ([128.107.191.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 16 Feb 2012 05:27:56 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 15 Feb 2012 21:27:54 -0800 From: ayabaner To: Donald Eastlake , "rbridge@postel.org" Message-ID: Thread-Topic: [rbridge] WG last call on draft-ietf-trill-rbridge-bfd-02 Thread-Index: Aczsa7uazUPiTLEvdEmhCQxlWWbmtw== In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 16 Feb 2012 05:27:56.0564 (UTC) FILETIME=[BD216540:01CCEC6B] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: ayabaner@cisco.com X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id q1G5RvKm009692 Subject: Re: [rbridge] WG last call on draft-ietf-trill-rbridge-bfd-02 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 Donald, Some comments in-line. Thanks, Ayan On 2/14/12 8:42 PM, "Donald Eastlake" wrote: > I would like to suggest the addition of some material to the Security > Considerations section. Something like what I've pasted below my .sig > and above Erik's message blow... > = > 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 > = > = > Consist with TRILL's goal of minimum configuration, the default for > BFD security between neighbor RBridges is based on that state of > IS-IS shared secret authentication for Hello between those > RBridges. If such IS-IS authentication is not in effect then, by > default, TRILL BFD between those RBridges is also unsecured. But > the RBridges may be configured to use BFD Security. [Ayan] I am assuming that the configuration above for the BFD Security is independent on the IS-IS authentication configurations (if any). > = > If such IS-IS authentication is in effect then, unless configured > otherwise, TRILL BFD Control frames sent between those RBridges use > BFD Meticulous Keyed SHA1 authentication [RF5880] with keying > material derived as shown below > = > HMAC-SHA256 ( ( "TRILL BFD Control" | originatorMAC | > originatorPortID ), IS-IS-shared-key ) > = > where HMAC-SHA256 [RFC6234], "TRILL BFD Control" is the seventeen > byte US ASCII [RFC20] string indicated that is then concatenated > with the 6-byte MAC of the originating port and then the 2-byte > Port ID as would be sent in a TRILL Hello on that port. These > quantities are included to minimize expose of the same key to > improve resistance to cryptanalysis. IS-IS-key is the secret keying > material being used for IS-IS authentication on the link. [Ayan] Should we be sharing the "secret" key between the two protocols or mandate the user to configure both to be identical. I realize the minimal configuration goals, but I am wondering if it would be nice to keep the core TRILL-BFD pieces TRILL-IS-IS agnostic. > In the > Authentication Section of the BFD Control frame OAM protocol > specific data, Auth Type would be 5, Auth Len would be 28, and Auth > Key ID is zero. The RBridges MAY be configured to use other BFD > security modes or keying material including configuration to use no > security. > = > Authentication for TRILL BFD Echo SHOULD be provided but is a local > implementation issue as BFD Echo frames are authenticated by their > sender when received in the form of Echo responses. However, if > TRILL IS-IS and BFD Control are being authenticated to a neighbor > and BFD Echo is in use, BFD Echo frames to be returned by that > neighbor SHOULD be authenticated and such authenticate SHOULD use > different keying material from other types of authentication. For > example, it could use keying material derived as follows: > = > HMAC-SHA256 ( ( "TRILL BFD Echo" | originatorMAC | > originatorPortID ), IS-IS-shared-key ) > = > = > On Wed, Feb 1, 2012 at 2:44 PM, Erik Nordmark wrote: >> = >> The WG last call ends on Feb 15th. >> Please send comments (including ones that say you've read the document >> and it is fine) to the rbridge list. >> = >> =A0 Erik >> _______________________________________________ >> 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 Feb 15 23:02:19 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 550E521E8034 for ; Wed, 15 Feb 2012 23:02:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, 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 jLyZ5RaNUpBW for ; Wed, 15 Feb 2012 23:02:15 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 0B44821E8010 for ; Wed, 15 Feb 2012 23:02:14 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1G6qbqn021983; Wed, 15 Feb 2012 22:52:38 -0800 (PST) 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 q1G6q3uv021950 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 15 Feb 2012 22:52:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ayabaner@cisco.com; l=1836; q=dns/txt; s=iport; t=1329375132; x=1330584732; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=yvwyBpuGyGXmB1pn+o613SMW5qeZKg33Ir/uUgImMjw=; b=B0wTH7o/BHm0FHRokQe3z/MprHZUxZGg21IGqj/03xqYMnEhswS/vN30 BF9sBWLcCiihbu8ueZuKhBhgHuykB5XvgXCNn4ZeR9bE167RgaeouuqV+ 9X9i0P5BZ8ckWVxx8TJByCGLIKJIX59lCOpQeseDeUxrjnJSolh3nj79a A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EADanPE+rRDoH/2dsb2JhbABEsGuBB4FyAQEBAwEBAQEPAScCATEdAQgJZDABAQQBEiKHXQmaXgGeSItLDB0lAQI3AQcIAwKEJQIODIMwBIhNhRyHTZMJ X-IronPort-AV: E=Sophos;i="4.73,427,1325462400"; d="scan'208";a="30580304" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 16 Feb 2012 06:52:03 +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 q1G6q3sV026598; Thu, 16 Feb 2012 06:52:03 GMT Received: from xmb-sjc-22b.amer.cisco.com ([128.107.191.112]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 Feb 2012 22:52:03 -0800 Received: from 10.21.151.247 ([10.21.151.247]) by xmb-sjc-22b.amer.cisco.com ([128.107.191.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 16 Feb 2012 06:52:01 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 15 Feb 2012 22:51:58 -0800 From: ayabaner To: Erik Nordmark , "rbridge@postel.org" Message-ID: Thread-Topic: [rbridge] WG last call of draft-ietf-trill-rbridge-channel-03 Thread-Index: Aczsd3oPmXtIyRWzb0Oax5VrVhzToA== In-Reply-To: <4F2991C6.7070904@acm.org> Mime-version: 1.0 X-OriginalArrivalTime: 16 Feb 2012 06:52:03.0014 (UTC) FILETIME=[7D0C8E60:01CCEC77] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: ayabaner@cisco.com Subject: Re: [rbridge] WG last call of draft-ietf-trill-rbridge-channel-03 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 Had a quick question on the following: The RBridge-Channel Ethertype indicates that the frame is an RBridge Channel message. The only other Ethertype currently specified for use with the All-Egress-RBridges Inner.MacDA is L2-IS- IS to indicate an ESADI frame [RFC6325]. In the future additional Ethertypes may be specified for use with the All-Egress-RBridges multicast address. Would there be an easy method to see this list in the future? Also, in Section 4, from the below paragraph: If provided for by the channel protocol involved, the receipt of such a native RBridge Channel frame MAY lead to the generation and transmission of one or more native or TRILL Data RBridge Channel frames. The decapsulation and processing of a TRILL Data RBridge Channel frame MAY, if provided for by the channel protocol involved, result in the sending of one or more native RBridge channel frames to one or more end stations. Does this imply the original frame may be modified by the transit nodes, say with respect to the destination address used. If so, can we make that a bit more explicit. Thanks, Ayan On 2/1/12 11:25 AM, "Erik Nordmark" wrote: > > We're starting three separate last calls this week, but they are all > very short documents. > > We had an earlier WG last call on this document 6 months ago, and there > were some concerns about using the IS-IS genapp mechanism, so that use > has been removed. > > The WG last call ends on Feb 15th. > Please send comments (including ones that say you've read the document > and it is fine) to the rbridge list. > > Erik > > _______________________________________________ > 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 Thu Feb 16 10:09: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 CEA6421F87AD for ; Thu, 16 Feb 2012 10:09:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.704 X-Spam-Level: X-Spam-Status: No, score=-105.704 tagged_above=-999 required=5 tests=[AWL=0.895, 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 6HnAdqUzysTO for ; Thu, 16 Feb 2012 10:09:14 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id EEAFB21F87DE for ; Thu, 16 Feb 2012 10:09:13 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1GHpRYZ011423; Thu, 16 Feb 2012 09:51:28 -0800 (PST) Received: from mail-ey0-f180.google.com (mail-ey0-f180.google.com [209.85.215.180]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1GHoorD011362 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 16 Feb 2012 09:51:00 -0800 (PST) Received: by eaad14 with SMTP id d14so1178980eaa.39 for ; Thu, 16 Feb 2012 09:50:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=OzWtLP6NAol46rkTqeszFjfObgY9GUjNtaYv1KfOxkY=; b=IFr7ZjgJA5ubXELFrWs3Cmpgkf4Yd0SlCvk3+KhKCTr7sjP8s/tKkkYV8tOc0+mcyu OVbVbmgia8VvSKZ7c7caAsg1kZCIjOy8jjecpJpefP+UX9Wp8m512iGmmB9Gksej9pe5 FPpolAE8HjFmhmyAQDRRt9xwYYGmFpFi+IMnk= Received: by 10.112.10.70 with SMTP id g6mr1359572lbb.0.1329414649157; Thu, 16 Feb 2012 09:50:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.21.7 with HTTP; Thu, 16 Feb 2012 09:50:26 -0800 (PST) In-Reply-To: <5BA18EC2-5CB1-432B-A9D4-BA6BE151CB17@gmail.com> References: <20120109132058.9151.5560.idtracker@ietfa.amsl.com> <5BA18EC2-5CB1-432B-A9D4-BA6BE151CB17@gmail.com> From: Donald Eastlake Date: Thu, 16 Feb 2012 12:50:26 -0500 Message-ID: To: Sam Aldrin 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 q1GHoorD011362 Cc: "rbridge@postel.org" Subject: Re: [rbridge] I-D Action: draft-ietf-trill-rbridge-extension-02.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 Sam, On Wed, Feb 15, 2012 at 6:02 PM, Sam Aldrin wrote: > Dear authors of the draft, > > I have read thought the latest version of the draft. I feel this is > very useful extension to the header and I support this publication. Thanks. > I do have few questions, which I hope could be addressed > easily. Apologize if they got answered already during earlier > versions of the draft. You could safely drop the questions, in the > true spirit of this draft :D Well, I like to try to answer all the comments if I can... > 1. I understand from the draft wording that, if the rbridge does not > support all of the critical header flag extensions, the frame should > be dropped. The RBridge only needs to support the applicable critical header flags. A transit RBridge doesn't care what ingress-to-egress flags are set. > What exactly is the definition of support. Does that > mean, if you cannot parse the header extension OR it can understand > the flag but chose not to implement? Support is whatever the extension says you need to do to support it. If it's critical and you can't do what the extension says you need to do to support it, by the definition of critical, you can't continue processing without bad things happening, like violations of security policy, misdeliverly and/or garbling of data, etc. For example (although this sounds like a bad idea and I'm not suggesting it), you could have a flag that says the frame payload was gzipped at the ingress and has to be ungzipped before delivery. Ignorning this and just delivering the gzipped payload to an unsuspeting end station would probably not work out so well :-) I don't know what you mean by "understand the flag but choose not to implemnt". Being able to tell how long some structure is, for example, and skipping over it is not "understanding" in a useful sense. If the structure is non-critical, then by the definition of non-critical, skipping over it and not doing anything with it is safe. If the structure is critical, then by the definition of critical, skipping over it and not doing anything with it but continuing to process the frame is unsafe and bad things are likely to happen. > For example, if a frame is sent > with critical ingress to egress extension, then only RBridges which > support the extension can egress that. Wouldn't that create backward > compatibility problem, as frames get dropped? You can't have it both ways. Either you can never extend the protocol in a way which is critical or you have to accept the possibility of encountering a legacy device that will be unable to process the message. At least here there are ways to find out if some extension is supported (see below) and ways for the legacy device to know it is getting something it can't process. > 2. What if the rbridge could interpret these critical flags but > chose to not implement? Should it drop the frames as well? If you could safely ignore something, then it would be non-critical. If something is critical and you ignore it (either because you didn't implement it, or you implemented it but choose not to enable that code, or whatever), then, by the definition of "critical", continuing to process the frame is unsafe. According to this draft, the frame is dropped, but a later draft could update this to provide for an error response as mentioned below. > 3. Keeping my OAM hat on, how would I know an rbridge does or does > not support critical options? This draft just specifies extended header flags, not all possible types of extensions that could be specified in the future. But for extended header flags, as the draft says, RBridges advertise the extended header flags they support in IS-IS PDUs. To be specific, see draft-eastlake-isis-rfc6326bis, which is referenced in the draft, in Sections 2.3.1 and 2.2.4 of the 6326bis draft. > Instead of mandating the frame be dropped, > if the frame is OAM frame, it should get punted for local > processing. That way, an appropriate code could be sent back in the > response for the OAM frame. Good advice for OAM messages which is why such a mechanism is in draft-ietf-trill-rbridge-channel, also in WGLC, and why there is a mechanism of that general type in draft-ietf-trill-rbridge-oam. But since the rbridge-oam draft is not in WGLC right now, I believe the right thing is for the rbridge-extension draft to say "dropped" and if/when some later draft specifies an appropriate error response message at this level, that later draft can say that it updates this extension draft/RFC. 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 > Cheers > Sam > > Sent from my iPad > > On Jan 9, 2012, at 8:18 PM, Donald Eastlake wrote: > >> This version incorporates change discussed on the WG mailing 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 +1-508-333-2270 (cell) >> =A0155 Beaver Street, Milford, MA 01757 USA >> =A0d3e3e3@gmail.com >> >> >> On Mon, Jan 9, 2012 at 8:20 AM, =A0 wrote: >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. This draft is a work item of the Transparent Interconnection of Lo= ts of Links Working Group of the IETF. >>> >>> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : TRILL: Header Extension >>> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Donald Eastlake >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Anoop Ghanwani >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Vishwas Manral >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Yizhou Li >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Caitlin Bestler >>> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-trill-rbridge-exten= sion-02.txt >>> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 16 >>> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-01-09 >>> >>> =A0 The IETF TRILL (Transparent Interconnection of Lots of Links) base >>> =A0 protocol specifies minimal hooks to safely support TRILL Header >>> =A0 extensions. This document specifies an initial extension providing >>> =A0 additional flag bits and specifies two of those bits. >>> >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-extension-= 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-rbridge-extension-0= 2.txt _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge From rbridge-bounces@postel.org Thu Feb 16 11:49: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 19D0221E807B for ; Thu, 16 Feb 2012 11:49:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.42 X-Spam-Level: X-Spam-Status: No, score=-105.42 tagged_above=-999 required=5 tests=[AWL=0.579, 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 I7ihl-d-JqhO for ; Thu, 16 Feb 2012 11:49:11 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 677B821E809A for ; Thu, 16 Feb 2012 11:49:11 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1GJOtt2028381; Thu, 16 Feb 2012 11:24:56 -0800 (PST) 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 q1GJOL2u028292 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 16 Feb 2012 11:24:31 -0800 (PST) Received: by lagy4 with SMTP id y4so4611240lag.39 for ; Thu, 16 Feb 2012 11:24:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=i5NuWHZf7Jub6e7SZJeITL8/9oPJIQSILkvd/ZhbrVI=; b=SzdjpCcmrThJAER5HQaiXMKADlXZNwjT2/cNsEbe4mQ3wquXJK79rIsARb3lpENNs2 riY3fIppyMuLrs5q3x5anOJ3eRdWFLD2SmVEj/qrEzYGGbEnP5HBNURulRLBvd337MZH 2DtxcILqlygFmAm/+/Co5RlSj326ap7oiAgNs= Received: by 10.112.10.70 with SMTP id g6mr1493208lbb.0.1329420260291; Thu, 16 Feb 2012 11:24:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.21.7 with HTTP; Thu, 16 Feb 2012 11:24:00 -0800 (PST) In-Reply-To: References: <4F2991C6.7070904@acm.org> From: Donald Eastlake Date: Thu, 16 Feb 2012 14:24:00 -0500 Message-ID: To: ayabaner 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 q1GJOL2u028292 Cc: "rbridge@postel.org" , Erik Nordmark Subject: Re: [rbridge] WG last call of draft-ietf-trill-rbridge-channel-03 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 Ayan, On Thu, Feb 16, 2012 at 1:51 AM, ayabaner wrote: > Had a quick question on the following: > > =A0 The RBridge-Channel Ethertype indicates that the frame > =A0 is an RBridge Channel message. The only other Ethertype currently > =A0 specified for use with the All-Egress-RBridges Inner.MacDA is L2-IS- > =A0 IS to indicate an ESADI frame [RFC6325]. In the future additional > =A0 Ethertypes may be specified for use with the All-Egress-RBridges > =A0 multicast address. > > Would there be an easy method to see this list in the future? I would think so for Ethertypes to the IETF. But I don't know of any beyond the above two that are currently being suggested. I don't think there would be anything stopping a proprietary extension of some sort with a different Ethertype here and the IETF might not even know about such an extension. > Also, in Section 4, from the below paragraph: > > =A0 If provided for by the channel protocol involved, the receipt of such > =A0 a native RBridge Channel frame MAY lead to the generation and > =A0 transmission of one or more native or TRILL Data RBridge Channel > =A0 frames. =A0The decapsulation and processing of a TRILL Data RBridge > =A0 Channel frame MAY, if provided for by the channel protocol involved, > =A0 result in the sending of one or more native RBridge channel frames to > =A0 one or more end stations. > > Does this imply the original frame may be modified by the transit nodes, = say > with respect to the destination address used. If so, can we make that a b= it > more explicit. That paragraph is not meant to say anything about transit nodes. But it could be modified at the egress (decapsulation) / ingress (encapsulation) node. I've tried to make things clearer in a -05candidate1 version which is available along with a wdiff at http://www.pothole.com/~dee3/drafts/ 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, > Ayan > > On 2/1/12 11:25 AM, "Erik Nordmark" wrote: > >> >> We're starting three separate last calls this week, but they are all >> very short documents. >> >> We had an earlier WG last call on this document 6 months ago, and there >> were some concerns about using the IS-IS genapp mechanism, so that use >> has been removed. >> >> The WG last call ends on Feb 15th. >> Please send comments (including ones that say you've read the document >> and it is fine) to the rbridge list. >> >> =A0 =A0Erik >> >> _______________________________________________ >> 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 Thu Feb 16 12:20: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 4212221E8022 for ; Thu, 16 Feb 2012 12:20:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.932 X-Spam-Level: X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 3rYUoyTjcAtW for ; Thu, 16 Feb 2012 12:20:14 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 5944921E8083 for ; Thu, 16 Feb 2012 12:20:14 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1GK2UxD004686; Thu, 16 Feb 2012 12:02:31 -0800 (PST) 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 q1GK2CrR004658 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 16 Feb 2012 12:02:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ayabaner@cisco.com; l=3519; q=dns/txt; s=iport; t=1329422541; x=1330632141; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=Zn45KaggUlwnedqmo7UgpgbQ3IsSPd84lEMkunko69E=; b=IySUWSANkB66PEMdm43MqZLJ2AQGbawPULu1pSVxNX+/US7oMTEcVbM/ B5Ddyw5SXSGQRYeaZsuTZixPtpcbkZN1bnxrHH9UvIJTdFbGrM415SjWK +sop2RYi7p1cefkCmTGki2epLdM7vMlGpOrJL4uBXMRWy/A6AP5EpFYdp o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuIIAIFgPU+rRDoH/2dsb2JhbABBAxavamYCgQeBcgEBAQMBAQEBDwEpATELBQ0BCAkFCk8GMAEBBA4FIoddCZpNAZ5IiF6DCAQEBAQBAwgfMgQBBQILhBIHBAcTgyIEiBszhRyHTYsTgzSEQg X-IronPort-AV: E=Sophos;i="4.73,431,1325462400"; d="scan'208";a="30690469" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 16 Feb 2012 20:02:12 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q1GK2CW0030859; Thu, 16 Feb 2012 20:02:12 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); Thu, 16 Feb 2012 12:02:12 -0800 Received: from 171.70.225.252 ([171.70.225.252]) by xmb-sjc-22b.amer.cisco.com ([128.107.191.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 16 Feb 2012 20:02:12 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Thu, 16 Feb 2012 12:02:09 -0800 From: ayabaner To: Donald Eastlake Message-ID: Thread-Topic: [rbridge] WG last call of draft-ietf-trill-rbridge-channel-03 Thread-Index: Aczs5d03LuqULXcRnkibVBsDMWtonw== In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 16 Feb 2012 20:02:12.0500 (UTC) FILETIME=[DF4E0540:01CCECE5] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: ayabaner@cisco.com X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id q1GK2CrR004658 Cc: "rbridge@postel.org" , Erik Nordmark Subject: Re: [rbridge] WG last call of draft-ietf-trill-rbridge-channel-03 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 Donald, Responses in-line. Thanks, Ayan On 2/16/12 11:24 AM, "Donald Eastlake" wrote: > Hi Ayan, > = > On Thu, Feb 16, 2012 at 1:51 AM, ayabaner wrote: >> Had a quick question on the following: >> = >> =A0 The RBridge-Channel Ethertype indicates that the frame >> =A0 is an RBridge Channel message. The only other Ethertype currently >> =A0 specified for use with the All-Egress-RBridges Inner.MacDA is L2-IS- >> =A0 IS to indicate an ESADI frame [RFC6325]. In the future additional >> =A0 Ethertypes may be specified for use with the All-Egress-RBridges >> =A0 multicast address. >> = >> Would there be an easy method to see this list in the future? > = > I would think so for Ethertypes to the IETF. But I don't know of any > beyond the above two that are currently being suggested. > = > I don't think there would be anything stopping a proprietary extension > of some sort with a different Ethertype here and the IETF might not > even know about such an extension. > = >> Also, in Section 4, from the below paragraph: >> = >> =A0 If provided for by the channel protocol involved, the receipt of such >> =A0 a native RBridge Channel frame MAY lead to the generation and >> =A0 transmission of one or more native or TRILL Data RBridge Channel >> =A0 frames. =A0The decapsulation and processing of a TRILL Data RBridge >> =A0 Channel frame MAY, if provided for by the channel protocol involved, >> =A0 result in the sending of one or more native RBridge channel frames to >> =A0 one or more end stations. >> = >> Does this imply the original frame may be modified by the transit nodes,= say >> with respect to the destination address used. If so, can we make that a = bit >> more explicit. > = > That paragraph is not meant to say anything about transit nodes. But > it could be modified at the egress (decapsulation) / ingress > (encapsulation) node. I've tried to make things clearer in a > -05candidate1 version which is available along with a wdiff at > http://www.pothole.com/~dee3/drafts/ I have read through the candidate draft and it is much easier to follow. I did mean the egress/ingress node that was changing the message from a TRILL frame to a native frame and vice versa (wrong terminology choice :)). Thanks, Ayan > = > 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, >> Ayan >> = >> On 2/1/12 11:25 AM, "Erik Nordmark" wrote: >> = >>> = >>> We're starting three separate last calls this week, but they are all >>> very short documents. >>> = >>> We had an earlier WG last call on this document 6 months ago, and there >>> were some concerns about using the IS-IS genapp mechanism, so that use >>> has been removed. >>> = >>> The WG last call ends on Feb 15th. >>> Please send comments (including ones that say you've read the document >>> and it is fine) to the rbridge list. >>> = >>> =A0 =A0Erik >>> = >>> _______________________________________________ >>> 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 Thu Feb 16 17:48: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 75F4B21E8080 for ; Thu, 16 Feb 2012 17:48:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.181 X-Spam-Level: X-Spam-Status: No, score=-5.181 tagged_above=-999 required=5 tests=[AWL=1.418, 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 Nl7yRdhBev6f for ; Thu, 16 Feb 2012 17:48:34 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 1A59C21E807E for ; Thu, 16 Feb 2012 17:48:33 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1H1Qi5H028964; Thu, 16 Feb 2012 17:26:45 -0800 (PST) Received: from mail-pz0-f52.google.com (mail-pz0-f52.google.com [209.85.210.52]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1H1QCuH028907 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 16 Feb 2012 17:26:21 -0800 (PST) Received: by dado14 with SMTP id o14so3504570dad.39 for ; Thu, 16 Feb 2012 17:26:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=3QCCYQyU98P9CATdVgDFEb2Uy4Ifyg65T9ztz0hfzQ0=; b=S+OyYikqB1+um3LvQab2W453ZORfke7NXs1dIUsYp+7/m+xWTjicO6zuZ6bnrl9MzX 1sw61tVr77vUIEcIAZMVpG8yHZMnydDe4WP10qSCmLyXOC9onyAuI6x9ZUMXYXJG+0lA LRRDst+aEPRoZTSrpUS9CXJAMcGYsFH+GZWeQ= Received: by 10.68.231.134 with SMTP id tg6mr11608574pbc.115.1329441972450; Thu, 16 Feb 2012 17:26:12 -0800 (PST) Received: from [192.168.255.74] ([12.207.18.42]) by mx.google.com with ESMTPS id 2sm3712659pbw.57.2012.02.16.17.26.11 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 16 Feb 2012 17:26:11 -0800 (PST) References: <20120109132058.9151.5560.idtracker@ietfa.amsl.com> <5BA18EC2-5CB1-432B-A9D4-BA6BE151CB17@gmail.com> In-Reply-To: Mime-Version: 1.0 (1.0) Message-Id: <73AD38DB-7C67-4562-B189-14E89C7E4025@gmail.com> X-Mailer: iPad Mail (9A405) From: Sam Aldrin Date: Thu, 16 Feb 2012 17:26:11 -0800 To: Donald Eastlake X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: aldrin.ietf@gmail.com X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id q1H1QCuH028907 Cc: "rbridge@postel.org" Subject: Re: [rbridge] I-D Action: draft-ietf-trill-rbridge-extension-02.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 Hi Donald, Thank you for the detailed reply. Please find my comments inline with %sam. Cheers Sam Sent from my iPad On Feb 16, 2012, at 9:50 AM, Donald Eastlake wrote: > Hi Sam, > > On Wed, Feb 15, 2012 at 6:02 PM, Sam Aldrin wrote: >> Dear authors of the draft, >> > >> I have read thought the latest version of the draft. I feel this is >> very useful extension to the header and I support this publication. > > Thanks. > >> I do have few questions, which I hope could be addressed >> easily. Apologize if they got answered already during earlier >> versions of the draft. You could safely drop the questions, in the >> true spirit of this draft :D > > Well, I like to try to answer all the comments if I can... > >> 1. I understand from the draft wording that, if the rbridge does not >> support all of the critical header flag extensions, the frame should >> be dropped. > > The RBridge only needs to support the applicable critical header > flags. A transit RBridge doesn't care what ingress-to-egress flags are > set. > >> What exactly is the definition of support. Does that >> mean, if you cannot parse the header extension OR it can understand >> the flag but chose not to implement? > > Support is whatever the extension says you need to do to support it. > If it's critical and you can't do what the extension says you need to > do to support it, by the definition of critical, you can't continue > processing without bad things happening, like violations of security > policy, misdeliverly and/or garbling of data, etc. For example > (although this sounds like a bad idea and I'm not suggesting it), you > could have a flag that says the frame payload was gzipped at the > ingress and has to be ungzipped before delivery. Ignorning this and > just delivering the gzipped payload to an unsuspeting end station > would probably not work out so well :-) > > I don't know what you mean by "understand the flag but choose not to > implemnt". Being able to tell how long some structure is, for example, > and skipping over it is not "understanding" in a useful sense. If the > structure is non-critical, then by the definition of non-critical, > skipping over it and not doing anything with it is safe. If the > structure is critical, then by the definition of critical, skipping > over it and not doing anything with it but continuing to process the > frame is unsafe and bad things are likely to happen. %sounds good. I do hope the flags defined will be really critical. Reason I had this question in the first place was, if the flags are so critical in functioning of TRILL, it would have had been defined already. It wouldn't be in the extended flags fields. If the RBridge advertises it cannot support but still part of the network and function, then the flags are not critical after all. I could be way off, but, that was my line of thinking, when I asked first. > >> For example, if a frame is sent >> with critical ingress to egress extension, then only RBridges which >> support the extension can egress that. Wouldn't that create backward >> compatibility problem, as frames get dropped? > > You can't have it both ways. Either you can never extend the protocol > in a way which is critical or you have to accept the possibility of > encountering a legacy device that will be unable to process the > message. At least here there are ways to find out if some extension is > supported (see below) and ways for the legacy device to know it is > getting something it can't process. > >> 2. What if the rbridge could interpret these critical flags but >> chose to not implement? Should it drop the frames as well? > > If you could safely ignore something, then it would be non-critical. > If something is critical and you ignore it (either because you didn't > implement it, or you implemented it but choose not to enable that > code, or whatever), then, by the definition of "critical", continuing > to process the frame is unsafe. According to this draft, the frame is > dropped, but a later draft could update this to provide for an error > response as mentioned below. %sam - I do agree if the flag is really critical that further processing of the frame is detrimental to the functioning of Rbridge, it should be dropped. > >> 3. Keeping my OAM hat on, how would I know an rbridge does or does >> not support critical options? > > This draft just specifies extended header flags, not all possible > types of extensions that could be specified in the future. But for > extended header flags, as the draft says, RBridges advertise the > extended header flags they support in IS-IS PDUs. To be specific, see > draft-eastlake-isis-rfc6326bis, which is referenced in the draft, in > Sections 2.3.1 and 2.2.4 of the 6326bis draft. %sam - ah! Thanks for pointing it out. I didn't realize that rbridge has to keep track of rbridge capabilities, prior to setting the extender header flag in the frame. > >> Instead of mandating the frame be dropped, >> if the frame is OAM frame, it should get punted for local >> processing. That way, an appropriate code could be sent back in the >> response for the OAM frame. > > Good advice for OAM messages which is why such a mechanism is in > draft-ietf-trill-rbridge-channel, also in WGLC, and why there is a > mechanism of that general type in draft-ietf-trill-rbridge-oam. But > since the rbridge-oam draft is not in WGLC right now, I believe the > right thing is for the rbridge-extension draft to say "dropped" and > if/when some later draft specifies an appropriate error response > message at this level, that later draft can say that it updates this > extension draft/RFC. %sam - ok, thanks. > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > >> Cheers >> Sam >> >> Sent from my iPad >> >> On Jan 9, 2012, at 8:18 PM, Donald Eastlake wrote: >> >>> This version incorporates change discussed on the WG mailing list. >>> >>> Thanks, >>> Donald >>> ============================= >>> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >>> 155 Beaver Street, Milford, MA 01757 USA >>> d3e3e3@gmail.com >>> >>> >>> On Mon, Jan 9, 2012 at 8:20 AM, wrote: >>>> >>>> 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: Header Extension >>>> Author(s) : Donald Eastlake >>>> Anoop Ghanwani >>>> Vishwas Manral >>>> Yizhou Li >>>> Caitlin Bestler >>>> Filename : draft-ietf-trill-rbridge-extension-02.txt >>>> Pages : 16 >>>> Date : 2012-01-09 >>>> >>>> The IETF TRILL (Transparent Interconnection of Lots of Links) base >>>> protocol specifies minimal hooks to safely support TRILL Header >>>> extensions. This document specifies an initial extension providing >>>> additional flag bits and specifies two of those bits. >>>> >>>> >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-extension-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-rbridge-extension-02.txt _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge From rbridge-bounces@postel.org Thu Feb 16 20:00:02 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 1EC2821E804E for ; Thu, 16 Feb 2012 20:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.731 X-Spam-Level: X-Spam-Status: No, score=-105.731 tagged_above=-999 required=5 tests=[AWL=0.868, 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 KVIwALJ2-ev1 for ; Thu, 16 Feb 2012 19:59:57 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id D7BE021E8021 for ; Thu, 16 Feb 2012 19:59:57 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1H3cF4c019082; Thu, 16 Feb 2012 19:38:17 -0800 (PST) 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 q1H3bX7V018999 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 16 Feb 2012 19:37:42 -0800 (PST) Received: by iabz7 with SMTP id z7so5752101iab.39 for ; Thu, 16 Feb 2012 19:37:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=8+8e33bOQf7q3+J11sLpnCxLTj7NpXyHczIcvBQVxoI=; b=Ue0IbOq65/daGJJL9uDG9Zg1ydUycMoSFSeq458hPv0Ztl2RcPCVS46cuC1KZb0kx/ yVzWvJIpaQzOIZ7TKtFh+FrOA+m7xgT6IHvC6oU6p59FtyReQwTZTlw8/S4hVHfwdCI5 qGrJYVrKKnUkWsoP5G0jWPusUEwBLMbMTv3X8= Received: by 10.50.76.130 with SMTP id k2mr6498190igw.22.1329449853297; Thu, 16 Feb 2012 19:37:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.222.130 with HTTP; Thu, 16 Feb 2012 19:37:12 -0800 (PST) In-Reply-To: References: From: Donald Eastlake Date: Thu, 16 Feb 2012 22:37:12 -0500 Message-ID: To: ayabaner 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 q1H3bX7V018999 Cc: "rbridge@postel.org" Subject: Re: [rbridge] WG last call on draft-ietf-trill-rbridge-bfd-02 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 Ayan, On Thu, Feb 16, 2012 at 12:27 AM, ayabaner wrote: > Donald, > > Some comments in-line. > > Thanks, > Ayan > > On 2/14/12 8:42 PM, "Donald Eastlake" wrote: > >> I would like to suggest the addition of some material to the Security >> Considerations section. Something like what I've pasted below my .sig >> and above Erik's message blow... >> >> 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 >> >> >> =A0 =A0Consist with TRILL's goal of minimum configuration, the default f= or >> =A0 =A0BFD security between neighbor RBridges is based on that state of >> =A0 =A0IS-IS shared secret authentication for Hello between those >> =A0 =A0RBridges. =A0If such IS-IS authentication is not in effect then, = by >> =A0 =A0default, TRILL BFD between those RBridges is also unsecured. But >> =A0 =A0the RBridges may be configured to use BFD Security. > > [Ayan] I am assuming that the configuration above for the BFD Security is > independent on the IS-IS authentication configurations (if any). Yes. The idea is just that, in the normal case where if you are going to secure one, you are probably going to secure both Hellos and BFD, consistent with TRILL's goal of minimal required configuration, you should only have to configure IS-IS security if you are willing to take the default BFD security. >> =A0 =A0If such IS-IS authentication is in effect then, unless configured >> =A0 =A0otherwise, TRILL BFD Control frames sent between those RBridges u= se >> =A0 =A0BFD Meticulous Keyed SHA1 authentication [RF5880] with keying >> =A0 =A0material derived as shown below >> >> =A0 =A0 =A0 =A0HMAC-SHA256 ( ( "TRILL BFD Control" | originatorMAC | >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 originatorPortID ), IS-I= S-shared-key ) >> >> =A0 =A0where HMAC-SHA256 [RFC6234], "TRILL BFD Control" is the seventeen >> =A0 =A0byte US ASCII [RFC20] string indicated that is then concatenated >> =A0 =A0with the 6-byte MAC of the originating port and then the 2-byte >> =A0 =A0Port ID as would be sent in a TRILL Hello on that port. These >> =A0 =A0quantities are included to minimize expose of the same key to >> =A0 =A0improve resistance to cryptanalysis. IS-IS-key is the secret keyi= ng >> =A0 =A0material being used for IS-IS authentication on the link. > > [Ayan] Should we be sharing the "secret" key between the two protocols or > mandate the user to configure both to be identical. I realize the minimal > configuration goals, but I am wondering if it would be nice to keep the c= ore > TRILL-BFD pieces TRILL-IS-IS agnostic. This text doesn't go into implementation details, and I don't think it should, you just need some way to give the key to the BFD code. Since the BFD is derived in a cryptographically secure way from the IS-IS key, neither one reveals anything about the other. Actually, the expression for the key could be simplified. Since the PortID isn't actually in the BFD messages, including it causes some complications so it should probably be removed... Improved text, including typo fixes, at bottom of message below. 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 >> =A0 =A0In the >> =A0 =A0Authentication Section of the BFD Control frame OAM protocol >> =A0 =A0specific data, Auth Type would be 5, Auth Len would be 28, and Au= th >> =A0 =A0Key ID is zero. The RBridges MAY be configured to use other BFD >> =A0 =A0security modes or keying material including configuration to use = no >> =A0 =A0security. >> >> =A0 =A0Authentication for TRILL BFD Echo SHOULD be provided but is a loc= al >> =A0 =A0implementation issue as BFD Echo frames are authenticated by their >> =A0 =A0sender when received in the form of Echo responses. However, if >> =A0 =A0TRILL IS-IS and BFD Control are being authenticated to a neighbor >> =A0 =A0and BFD Echo is in use, BFD Echo frames to be returned by that >> =A0 =A0neighbor SHOULD be authenticated and such authenticate SHOULD use >> =A0 =A0different keying material from other types of authentication. =A0= For >> =A0 =A0example, it could use keying material derived as follows: >> >> =A0 =A0 =A0 HMAC-SHA256 ( ( "TRILL BFD Echo" | originatorMAC | >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 originatorPortID ), IS-IS-sh= ared-key ) >> >> >> On Wed, Feb 1, 2012 at 2:44 PM, Erik Nordmark wrote: >>> >>> The WG last call ends on Feb 15th. >>> Please send comments (including ones that say you've read the document >>> and it is fine) to the rbridge list. >>> >>> =A0 Erik Consistent with TRILL's goal of being able to operate with minimum configuration, the default for BFD security between neighbor RBridges is based on that state of IS-IS shared secret authentication for Hello between those RBridges. However, if such BFD security is configured then its configuration is independent of that for IS-IS security. If IS-IS authentication is not in effect between neighbor RBridges then, by default, TRILL BFD between those RBridges is also unsecured. If such IS-IS authentication is in effect then, unless configured otherwise, TRILL BFD Control frames sent between those RBridges use BFD Meticulous Keyed SHA1 authentication [RF5880] with keying material derived as shown below HMAC-SHA256 ( ( "TRILL BFD Control" | originatorMAC ), IS-IS-shared-key ) where HMAC-SHA256 is described in [RFC6234], "TRILL BFD Control" is the seventeen byte US ASCII [RFC20] string indicated that is then concatenated with the 6-byte MAC of the originating port. The MAC is included to minimize exposure of the same key to improve resistance to cryptanalysis. IS-IS-key is the secret keying material being used for IS-IS authentication on the link. In the Authentication Section of the BFD Control frame OAM protocol specific data, Auth Type would be 5, Auth Len would be 28, and Auth Key ID is zero. The RBridges MAY be configured to use other BFD security modes or keying material or configured to use no security. Authentication for TRILL BFD Echo is a local implementation issue as BFD Echo frames are authenticated by their sender when received in the form of Echo responses. However, if TRILL IS-IS and BFD Control are being authenticated to a neighbor and BFD Echo is in use, BFD Echo frames to be returned by that neighbor SHOULD be authenticated and such authenticate SHOULD use different keying material from other types of authentication. For example, it could use keying material derived as follows: HMAC-SHA256 ( ( "TRILL BFD Echo" | originatorMAC ), IS-IS-shared-key ) _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge From rbridge-bounces@postel.org Thu Feb 16 22:25: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 A42AD21F8697 for ; Thu, 16 Feb 2012 22:25:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.172 X-Spam-Level: X-Spam-Status: No, score=-5.172 tagged_above=-999 required=5 tests=[AWL=1.427, 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 m1t9IIgKeJ6Y for ; Thu, 16 Feb 2012 22:25:19 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 74B0721F8690 for ; Thu, 16 Feb 2012 22:25:19 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1H5wlOx009859; Thu, 16 Feb 2012 21:58:48 -0800 (PST) Received: from mail-ey0-f180.google.com (mail-ey0-f180.google.com [209.85.215.180]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1H5w4nA009505 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 16 Feb 2012 21:58:13 -0800 (PST) Received: by eaad14 with SMTP id d14so1483021eaa.39 for ; Thu, 16 Feb 2012 21:58:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=R/JxowpUN2X6wMZ9MzK/R6rObvFoi4TZC2dBdRNR1gg=; b=rBW5p39vWSlYZ/+t8oob66cccIlXbAzBIhBlOGAS+bN73uxL7OniUaIFR96I41yL0A sSqQ5+edH3Rctx70vYRn1Rbypec6pZFqAmJs0DnV9JWadjh6fEumOCZqTc+qG9wIf0tC 19PzlMPMId0+AiQdRErWorVENzEoLYylmxGoU= MIME-Version: 1.0 Received: by 10.213.33.72 with SMTP id g8mr806528ebd.8.1329458281561; Thu, 16 Feb 2012 21:58:01 -0800 (PST) Received: by 10.213.16.205 with HTTP; Thu, 16 Feb 2012 21:58:01 -0800 (PST) In-Reply-To: <4F299636.7060604@acm.org> References: <4F299636.7060604@acm.org> Date: Thu, 16 Feb 2012 21:58:01 -0800 Message-ID: From: Radia Perlman To: Erik Nordmark X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radiaperlman@gmail.com X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id q1H5w4nA009505 Cc: "rbridge@postel.org" Subject: Re: [rbridge] WG last call on draft-ietf-trill-rbridge-bfd-02 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 I've read it and it seems fine. Radia On Wed, Feb 1, 2012 at 11:44 AM, Erik Nordmark wrote: > > The WG last call ends on Feb 15th. > Please send comments (including ones that say you've read the document > and it is fine) to the rbridge list. > > =A0 Erik > _______________________________________________ > 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 Fri Feb 17 00:41:02 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 EA27021F8888 for ; Fri, 17 Feb 2012 00:41:02 -0800 (PST) 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 936ro7dWN4Kz for ; Fri, 17 Feb 2012 00:41:02 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 352E221F8887 for ; Fri, 17 Feb 2012 00:41:02 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1H8WN26003680; Fri, 17 Feb 2012 00:32:24 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1H8Vam6003606 for ; Fri, 17 Feb 2012 00:31:46 -0800 (PST) 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 <0LZJ0060O3MW3E@szxga05-in.huawei.com> for rbridge@postel.org; Fri, 17 Feb 2012 16:30:33 +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 <0LZJ00IUF3L421@szxga05-in.huawei.com> for rbridge@postel.org; Fri, 17 Feb 2012 16:30:32 +0800 (CST) Received: from szxeml211-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGX38818; Fri, 17 Feb 2012 16:30:32 +0800 Received: from SZXEML422-HUB.china.huawei.com (10.82.67.161) by szxeml211-edg.china.huawei.com (172.24.2.182) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 17 Feb 2012 16:30:22 +0800 Received: from SZXEML507-MBX.china.huawei.com ([169.254.8.166]) by szxeml422-hub.china.huawei.com ([10.82.67.161]) with mapi id 14.01.0323.003; Fri, 17 Feb 2012 16:30:27 +0800 Date: Fri, 17 Feb 2012 08:30:27 +0000 From: Mingui Zhang In-reply-to: <4F299636.7060604@acm.org> X-Originating-IP: [10.108.4.52] To: Erik Nordmark , "rbridge@postel.org" Message-id: <4552F0907735844E9204A62BBDD325E71F40B72D@SZXEML507-MBX.china.huawei.com> MIME-version: 1.0 Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: [rbridge] WG last call on draft-ietf-trill-rbridge-bfd-02 Thread-index: AQHM4R2yxNL7hzyeJ0O5+0vBjMXaYZZA2jgw X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4F299636.7060604@acm.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: zhangmingui@huawei.com Subject: Re: [rbridge] WG last call on draft-ietf-trill-rbridge-bfd-02 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 I've read it. It looks fine. Mingui > -----Original Message----- > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Erik Nordmark > Sent: Thursday, February 02, 2012 3:45 AM > To: rbridge@postel.org > Subject: [rbridge] WG last call on draft-ietf-trill-rbridge-bfd-02 > > > The WG last call ends on Feb 15th. > Please send comments (including ones that say you've read the document > and it is fine) to the rbridge list. > > Erik > _______________________________________________ > 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 Fri Feb 17 21:44:36 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 09E0221E8023 for ; Fri, 17 Feb 2012 21:44:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.146 X-Spam-Level: X-Spam-Status: No, score=-6.146 tagged_above=-999 required=5 tests=[AWL=0.453, 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 hJuYr1hnOqW0 for ; Fri, 17 Feb 2012 21:44:35 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id E4BD821E8014 for ; Fri, 17 Feb 2012 21:44:34 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1I5ULxr003580; Fri, 17 Feb 2012 21:30:22 -0800 (PST) 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 q1I5TwPj003563 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 17 Feb 2012 21:30:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tsenevir@cisco.com; l=2065; q=dns/txt; s=iport; t=1329543007; x=1330752607; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=FGzU2DXM4G2PMiuAPkKU2b5kZFHNUl8DGCskIOIdkZk=; b=MFPNuxWkuhbdmIj3p0Qhgf+SN98DScoT0DH9s9ef5pqniutmUxDPDIgy wm4wg59lD1Hc8WfHJUa1AMFLpkVG+qPl/ynyK9G3WtMe2K8clunUYXQzh 5+6YoY94Jn47TdNYk1nJ/EOyUCWwx4qVHkOsEHXSxOqBUrAhv54pYgnjg E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEo2P0+rRDoI/2dsb2JhbABEsiKBB4F1AQEBBAEBAQ8BHQo0FwQCAQgRBAEBCwYXAQYBJh8JCAEBBAESCBqHZ5o0AZ5Pi3EHAggBBQ0JEkODFFEYglFjBIhOn3M X-IronPort-AV: E=Sophos;i="4.73,442,1325462400"; d="scan'208";a="30953123" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 18 Feb 2012 05:29:58 +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 q1I5TvAD012253; Sat, 18 Feb 2012 05:29:57 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); Fri, 17 Feb 2012 21:29:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 17 Feb 2012 21:29:56 -0800 Message-ID: <344037D7CFEFE84E97E9CC1F56C5F4A59BC38C@xmb-sjc-214.amer.cisco.com> In-Reply-To: <4F2991C6.7070904@acm.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] WG last call of draft-ietf-trill-rbridge-channel-03 Thread-Index: AczhHJupePPA+cr/TbeGORRSl497BwM35Itg References: <4F2991C6.7070904@acm.org> From: "Tissa Senevirathne (tsenevir)" To: "Erik Nordmark" , X-OriginalArrivalTime: 18 Feb 2012 05:29:57.0856 (UTC) FILETIME=[5A409600:01CCEDFE] 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 q1I5TwPj003563 Subject: Re: [rbridge] WG last call of draft-ietf-trill-rbridge-channel-03 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 I have read this draft and have following comments. 1. This draft indicates the channels encaps proposed can be utilized as a general method of sending OAM messages. [Comment] I disagree with that comment. As the channel it is defined currently. Utilize a fixed Multicast MAC address and specific Ethtype. Additionally it require to use Source MAC address that belong to the originating switch. In OAM the messages need to follow the path that the data frames takes. With the above methods these channel frames follow a different path than the data. Hence this cannot be effectively used for OAM. 2. This draft propos to use Channel header extended header flags for certain conditions. [comment] This may alter the forwarding path of the channel frame from the original frames. Again that may reduce the coverage of OAM. What is not clear is can a RBridges that cannot support extended header can advertise itself as channel capable ? I propose this draft if needed to be moved to RFC state to remove all reference to OAM. During the last WG in Taipei it was discussed that OAM proposals that are based on the channel encapsulations may not really provide the ECMP coverage -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Erik Nordmark Sent: Wednesday, February 01, 2012 11:26 AM To: rbridge@postel.org Subject: [rbridge] WG last call of draft-ietf-trill-rbridge-channel-03 We're starting three separate last calls this week, but they are all very short documents. We had an earlier WG last call on this document 6 months ago, and there were some concerns about using the IS-IS genapp mechanism, so that use has been removed. The WG last call ends on Feb 15th. Please send comments (including ones that say you've read the document and it is fine) to the rbridge list. Erik _______________________________________________ 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 Sat Feb 18 00:50:41 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 68D8821F86C3 for ; Sat, 18 Feb 2012 00:50:41 -0800 (PST) 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 ZiljoLdoT+Jd for ; Sat, 18 Feb 2012 00:50:40 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6AFA021F86B9 for ; Sat, 18 Feb 2012 00:50:40 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1I8QODd025929; Sat, 18 Feb 2012 00:26:25 -0800 (PST) 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 q1I8Pmj9025858 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sat, 18 Feb 2012 00:25:58 -0800 (PST) Received: by lagy4 with SMTP id y4so7678310lag.39 for ; Sat, 18 Feb 2012 00:25:47 -0800 (PST) Received-SPF: pass (google.com: domain of jon.hudson@gmail.com designates 10.112.10.169 as permitted sender) client-ip=10.112.10.169; Authentication-Results: mr.google.com; spf=pass (google.com: domain of jon.hudson@gmail.com designates 10.112.10.169 as permitted sender) smtp.mail=jon.hudson@gmail.com; dkim=pass header.i=jon.hudson@gmail.com Received: from mr.google.com ([10.112.10.169]) by 10.112.10.169 with SMTP id j9mr4703558lbb.70.1329553547280 (num_hops = 1); Sat, 18 Feb 2012 00:25:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=dJ/ghFnJ8MF50ps3Ca0NZduUUeW01YqtfeX3UJbM7m0=; b=stKRerXTeLtLTstzB9xoNlXB7G6jYzGbr/ij4NL1i6aDk84OrC2QSqFYg/Q+K6PNle E8Q1MrVQOUXuk9NPz3FrsAAuYllpUTOmalGDPHNY4Ca5NuhUNXYNDGqul9vFWlblWp2+ 2Yq9lP4OrbdJpJjYhrbhl/89IkgO3nM7VE2aY= MIME-Version: 1.0 Received: by 10.112.10.169 with SMTP id j9mr3931629lbb.70.1329553547188; Sat, 18 Feb 2012 00:25:47 -0800 (PST) Received: by 10.112.10.196 with HTTP; Sat, 18 Feb 2012 00:25:47 -0800 (PST) In-Reply-To: References: <20120109132058.9151.5560.idtracker@ietfa.amsl.com> Date: Sat, 18 Feb 2012 00:25:47 -0800 Message-ID: From: Jon Hudson To: rbridge@postel.org X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: jon.hudson@gmail.com Subject: Re: [rbridge] I-D Action: draft-ietf-trill-rbridge-extension-02.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: multipart/mixed; boundary="===============1859948834==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org --===============1859948834== Content-Type: multipart/alternative; boundary=e0cb4efe34fae3db6204b938ce71 --e0cb4efe34fae3db6204b938ce71 Content-Type: text/plain; charset=ISO-8859-1 I have read this and support the document. Very sorry for missing the 15th deadline, I have been ofline. On Mon, Jan 9, 2012 at 8:18 PM, Donald Eastlake wrote: > This version incorporates change discussed on the WG mailing list. > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > > > On Mon, Jan 9, 2012 at 8:20 AM, wrote: > > > > 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: Header Extension > > Author(s) : Donald Eastlake > > Anoop Ghanwani > > Vishwas Manral > > Yizhou Li > > Caitlin Bestler > > Filename : draft-ietf-trill-rbridge-extension-02.txt > > Pages : 16 > > Date : 2012-01-09 > > > > The IETF TRILL (Transparent Interconnection of Lots of Links) base > > protocol specifies minimal hooks to safely support TRILL Header > > extensions. This document specifies an initial extension providing > > additional flag bits and specifies two of those bits. > > > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-extension-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-rbridge-extension-02.txt > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > --e0cb4efe34fae3db6204b938ce71 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have read this and support the document.=A0

Very sorry= for missing the 15th deadline, I have been ofline.=A0

On Mon, Jan 9, 2012 at 8:18 PM, Donald Eastlake <d3e3e3@gmail.com> wrote:
This version incorporates change discussed o= n the WG mailing 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, Jan 9, 2012 at 8:20 AM, =A0<internet-drafts@ietf.org> wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. This draft is a work item of the Transparent Interconnection of L= ots of Links Working Group of the IETF.
>
> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : TRILL: Header Extension
> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Donald Eastlake
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Anoop Ghanwani
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Vishwas Manral
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Yizhou Li
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Caitlin Bestler
> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-trill-rbridge-exte= nsion-02.txt
> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 16
> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-01-09
>
> =A0 The IETF TRILL (Transparent Interconnection of Lots of Links) base=
> =A0 protocol specifies minimal hooks to safely support TRILL Header > =A0 extensions. This document specifies an initial extension providing=
> =A0 additional flag bits and specifies two of those bits.
>
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/d= raft-ietf-trill-rbridge-extension-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/dra= ft-ietf-trill-rbridge-extension-02.txt

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




--e0cb4efe34fae3db6204b938ce71-- --===============1859948834== 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 --===============1859948834==-- From rbridge-bounces@postel.org Sat Feb 18 01:05: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 A0D5221F86E4 for ; Sat, 18 Feb 2012 01:05:51 -0800 (PST) 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 BmgXI4CBVQJc for ; Sat, 18 Feb 2012 01:05:49 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id E412C21F85E6 for ; Sat, 18 Feb 2012 01:05:48 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1I8nPTZ029068; Sat, 18 Feb 2012 00:49:26 -0800 (PST) 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 q1I8mgCv029002 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sat, 18 Feb 2012 00:48:53 -0800 (PST) Received: by lagy4 with SMTP id y4so7698246lag.39 for ; Sat, 18 Feb 2012 00:48:42 -0800 (PST) Received-SPF: pass (google.com: domain of jon.hudson@gmail.com designates 10.112.10.169 as permitted sender) client-ip=10.112.10.169; Authentication-Results: mr.google.com; spf=pass (google.com: domain of jon.hudson@gmail.com designates 10.112.10.169 as permitted sender) smtp.mail=jon.hudson@gmail.com; dkim=pass header.i=jon.hudson@gmail.com Received: from mr.google.com ([10.112.10.169]) by 10.112.10.169 with SMTP id j9mr4726777lbb.70.1329554922163 (num_hops = 1); Sat, 18 Feb 2012 00:48:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QCEshFZ5t1WTACduzQkdzOwIZxrOswI4nzQvbAWwB6g=; b=N50wd5BioFUcjBgKHRxbVJb/5PNXHZePkOURuvS8c/CA11ACBwsixyY05cw9KXooY/ cY8B5s4V551vDb2d8h/FyTzh1UPJqPk9f6ZRzGDenX8A0o5qUXWiLItmDBFxA1IMwEv4 21d+LzNbYx591Sxgvj73/rpgPTW/E5ZpVaNxU= MIME-Version: 1.0 Received: by 10.112.10.169 with SMTP id j9mr3951220lbb.70.1329554922061; Sat, 18 Feb 2012 00:48:42 -0800 (PST) Received: by 10.112.10.196 with HTTP; Sat, 18 Feb 2012 00:48:42 -0800 (PST) In-Reply-To: References: Date: Sat, 18 Feb 2012 00:48:42 -0800 Message-ID: From: Jon Hudson To: rbridge@postel.org X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: jon.hudson@gmail.com Cc: Donald Eastlake Subject: Re: [rbridge] WG last call on draft-ietf-trill-rbridge-bfd-02 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="===============1441964125==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org --===============1441964125== Content-Type: multipart/alternative; boundary=e0cb4efe34fad6c15e04b939206f --e0cb4efe34fad6c15e04b939206f Content-Type: text/plain; charset=ISO-8859-1 I have read and support this. it's especially nice to see security being discussed. This is becoming more and more a frequent conversation point when talking TRILL with certain customers. ....the same customers that keep me offline for 2 days :-/ On Thu, Feb 16, 2012 at 7:37 PM, Donald Eastlake wrote: > Hi Ayan, > > On Thu, Feb 16, 2012 at 12:27 AM, ayabaner wrote: > > Donald, > > > > Some comments in-line. > > > > Thanks, > > Ayan > > > > On 2/14/12 8:42 PM, "Donald Eastlake" wrote: > > > >> I would like to suggest the addition of some material to the Security > >> Considerations section. Something like what I've pasted below my .sig > >> and above Erik's message blow... > >> > >> Thanks, > >> Donald > >> ============================= > >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) > >> 155 Beaver Street, Milford, MA 01757 USA > >> d3e3e3@gmail.com > >> > >> > >> Consist with TRILL's goal of minimum configuration, the default for > >> BFD security between neighbor RBridges is based on that state of > >> IS-IS shared secret authentication for Hello between those > >> RBridges. If such IS-IS authentication is not in effect then, by > >> default, TRILL BFD between those RBridges is also unsecured. But > >> the RBridges may be configured to use BFD Security. > > > > [Ayan] I am assuming that the configuration above for the BFD Security is > > independent on the IS-IS authentication configurations (if any). > > Yes. The idea is just that, in the normal case where if you are going > to secure one, you are probably going to secure both Hellos and BFD, > consistent with TRILL's goal of minimal required configuration, you > should only have to configure IS-IS security if you are willing to > take the default BFD security. > > >> If such IS-IS authentication is in effect then, unless configured > >> otherwise, TRILL BFD Control frames sent between those RBridges use > >> BFD Meticulous Keyed SHA1 authentication [RF5880] with keying > >> material derived as shown below > >> > >> HMAC-SHA256 ( ( "TRILL BFD Control" | originatorMAC | > >> originatorPortID ), IS-IS-shared-key ) > >> > >> where HMAC-SHA256 [RFC6234], "TRILL BFD Control" is the seventeen > >> byte US ASCII [RFC20] string indicated that is then concatenated > >> with the 6-byte MAC of the originating port and then the 2-byte > >> Port ID as would be sent in a TRILL Hello on that port. These > >> quantities are included to minimize expose of the same key to > >> improve resistance to cryptanalysis. IS-IS-key is the secret keying > >> material being used for IS-IS authentication on the link. > > > > [Ayan] Should we be sharing the "secret" key between the two protocols or > > mandate the user to configure both to be identical. I realize the minimal > > configuration goals, but I am wondering if it would be nice to keep the > core > > TRILL-BFD pieces TRILL-IS-IS agnostic. > > This text doesn't go into implementation details, and I don't think it > should, you just need some way to give the key to the BFD code. Since > the BFD is derived in a cryptographically secure way from the IS-IS > key, neither one reveals anything about the other. Actually, the > expression for the key could be simplified. Since the PortID isn't > actually in the BFD messages, including it causes some complications > so it should probably be removed... > > Improved text, including typo fixes, at bottom of message below. > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > > >> In the > >> Authentication Section of the BFD Control frame OAM protocol > >> specific data, Auth Type would be 5, Auth Len would be 28, and Auth > >> Key ID is zero. The RBridges MAY be configured to use other BFD > >> security modes or keying material including configuration to use no > >> security. > >> > >> Authentication for TRILL BFD Echo SHOULD be provided but is a local > >> implementation issue as BFD Echo frames are authenticated by their > >> sender when received in the form of Echo responses. However, if > >> TRILL IS-IS and BFD Control are being authenticated to a neighbor > >> and BFD Echo is in use, BFD Echo frames to be returned by that > >> neighbor SHOULD be authenticated and such authenticate SHOULD use > >> different keying material from other types of authentication. For > >> example, it could use keying material derived as follows: > >> > >> HMAC-SHA256 ( ( "TRILL BFD Echo" | originatorMAC | > >> originatorPortID ), IS-IS-shared-key ) > >> > >> > >> On Wed, Feb 1, 2012 at 2:44 PM, Erik Nordmark wrote: > >>> > >>> The WG last call ends on Feb 15th. > >>> Please send comments (including ones that say you've read the document > >>> and it is fine) to the rbridge list. > >>> > >>> Erik > > > Consistent with TRILL's goal of being able to operate with minimum > configuration, the default for BFD security between neighbor > RBridges is based on that state of IS-IS shared secret > authentication for Hello between those RBridges. However, if such > BFD security is configured then its configuration is independent of > that for IS-IS security. > > If IS-IS authentication is not in effect between neighbor RBridges > then, by default, TRILL BFD between those RBridges is also > unsecured. If such IS-IS authentication is in effect then, unless > configured otherwise, TRILL BFD Control frames sent between those > RBridges use BFD Meticulous Keyed SHA1 authentication [RF5880] with > keying material derived as shown below > > HMAC-SHA256 ( ( "TRILL BFD Control" | originatorMAC ), > IS-IS-shared-key ) > > where HMAC-SHA256 is described in [RFC6234], "TRILL BFD Control" is > the seventeen byte US ASCII [RFC20] string indicated that is then > concatenated with the 6-byte MAC of the originating port. The MAC > is included to minimize exposure of the same key to improve > resistance to cryptanalysis. IS-IS-key is the secret keying > material being used for IS-IS authentication on the link. In the > Authentication Section of the BFD Control frame OAM protocol > specific data, Auth Type would be 5, Auth Len would be 28, and Auth > Key ID is zero. The RBridges MAY be configured to use other BFD > security modes or keying material or configured to use no security. > > Authentication for TRILL BFD Echo is a local implementation issue > as BFD Echo frames are authenticated by their sender when received > in the form of Echo responses. However, if TRILL IS-IS and BFD > Control are being authenticated to a neighbor and BFD Echo is in > use, BFD Echo frames to be returned by that neighbor SHOULD be > authenticated and such authenticate SHOULD use different keying > material from other types of authentication. For example, it could > use keying material derived as follows: > > HMAC-SHA256 ( ( "TRILL BFD Echo" | originatorMAC ), > IS-IS-shared-key ) > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > -- "Do not lie. And do not do what you hate." "Don't worry, be happy" --e0cb4efe34fad6c15e04b939206f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have read and support this.=A0

it's especially nic= e to see security being discussed. This is becoming more and more a frequen= t conversation point when talking TRILL with certain customers.=A0

....the same customers that keep me offline for 2 days :-/


On Thu, Feb 16, 2012 at 7:37 PM= , Donald Eastlake <d3e3e3@gmail.com> wrote:
Hi Ayan,

On Thu, Feb 16, 2012 at 12:27 AM, ayabaner <ayabaner@cisco.com> wrote:
> Donald,
>
> Some comments in-line.
>
> Thanks,
> Ayan
>
> On 2/14/12 8:42 PM, "Donald Eastlake" <d3e3e3@gmail.com> wrote:
>
>> I would like to suggest the addition of some material to the Secur= ity
>> Considerations section. Something like what I've pasted below = my .sig
>> and above Erik's message blow...
>>
>> 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
>>
>>
>> =A0 =A0Consist with TRILL's goal of minimum configuration, the= default for
>> =A0 =A0BFD security between neighbor RBridges is based on that sta= te of
>> =A0 =A0IS-IS shared secret authentication for Hello between those<= br> >> =A0 =A0RBridges. =A0If such IS-IS authentication is not in effect = then, by
>> =A0 =A0default, TRILL BFD between those RBridges is also unsecured= . But
>> =A0 =A0the RBridges may be configured to use BFD Security.
>
> [Ayan] I am assuming that the configuration above for the BFD Security= is
> independent on the IS-IS authentication configurations (if any).

Yes. The idea is just that, in the normal case where if you are going=
to secure one, you are probably going to secure both Hellos and BFD,
consistent with TRILL's goal of minimal required configuration, you
should only have to configure IS-IS security if you are willing to
take the default BFD security.

>> =A0 =A0If such IS-IS authentication is in effect then, unless conf= igured
>> =A0 =A0otherwise, TRILL BFD Control frames sent between those RBri= dges use
>> =A0 =A0BFD Meticulous Keyed SHA1 authentication [RF5880] with keyi= ng
>> =A0 =A0material derived as shown below
>>
>> =A0 =A0 =A0 =A0HMAC-SHA256 ( ( "TRILL BFD Control" | ori= ginatorMAC |
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 originatorPortID )= , IS-IS-shared-key )
>>
>> =A0 =A0where HMAC-SHA256 [RFC6234], "TRILL BFD Control" = is the seventeen
>> =A0 =A0byte US ASCII [RFC20] string indicated that is then concate= nated
>> =A0 =A0with the 6-byte MAC of the originating port and then the 2-= byte
>> =A0 =A0Port ID as would be sent in a TRILL Hello on that port. The= se
>> =A0 =A0quantities are included to minimize expose of the same key = to
>> =A0 =A0improve resistance to cryptanalysis. IS-IS-key is the secre= t keying
>> =A0 =A0material being used for IS-IS authentication on the link. >
> [Ayan] Should we be sharing the "secret" key between the two= protocols or
> mandate the user to configure both to be identical. I realize the mini= mal
> configuration goals, but I am wondering if it would be nice to keep th= e core
> TRILL-BFD pieces TRILL-IS-IS agnostic.

This text doesn't go into implementation details, and I don't= think it
should, you just need some way to give the key to the BFD code. Since
the BFD is derived in a cryptographically secure way from the IS-IS
key, neither one reveals anything about the other. Actually, the
expression for the key could be simplified. Since the PortID isn't
actually in the BFD messages, including it causes some complications
so it should probably be removed...

Improved text, including typo fixes, at bottom of message below.

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

>> =A0 =A0In the
>> =A0 =A0Authentication Section of the BFD Control frame OAM protoco= l
>> =A0 =A0specific data, Auth Type would be 5, Auth Len would be 28, = and Auth
>> =A0 =A0Key ID is zero. The RBridges MAY be configured to use other= BFD
>> =A0 =A0security modes or keying material including configuration t= o use no
>> =A0 =A0security.
>>
>> =A0 =A0Authentication for TRILL BFD Echo SHOULD be provided but is= a local
>> =A0 =A0implementation issue as BFD Echo frames are authenticated b= y their
>> =A0 =A0sender when received in the form of Echo responses. However= , if
>> =A0 =A0TRILL IS-IS and BFD Control are being authenticated to a ne= ighbor
>> =A0 =A0and BFD Echo is in use, BFD Echo frames to be returned by t= hat
>> =A0 =A0neighbor SHOULD be authenticated and such authenticate SHOU= LD use
>> =A0 =A0different keying material from other types of authenticatio= n. =A0For
>> =A0 =A0example, it could use keying material derived as follows: >>
>> =A0 =A0 =A0 HMAC-SHA256 ( ( "TRILL BFD Echo" | originato= rMAC |
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 originatorPortID ), IS= -IS-shared-key )
>>
>>
>> On Wed, Feb 1, 2012 at 2:44 PM, Erik Nordmark <nordmark@acm.org> wrote:
>>>
>>> The WG last call ends on Feb 15th.
>>> Please send comments (including ones that say you've read = the document
>>> and it is fine) to the rbridge list.
>>>
>>> =A0 Erik


=A0 Consistent with TRILL's goal of being able to operate with m= inimum
=A0 configuration, the default for BFD security between = neighbor
=A0 RBridges is based on that state of IS-IS shared secret
=A0 authentication for Hello between those RBridges. However, if suc= h
=A0 BFD security is configured then its configuration is independent of =A0 that for IS-IS security.

=A0 If IS-IS authentication is not in effect between neighbor RBridges
=A0 then, by default, TRILL BFD between those RBridges i= s also
=A0 unsecured. If such IS-IS authentication is in effect then, unles= s
=A0 configured otherwise, TRILL BFD Control frames sent = between those
=A0 RBridges use BFD Meticulous Keyed SHA1 authentication [RF5880] with =A0 keying material derived as shown below

=A0 =A0 =A0 HMAC-SHA256 ( ( "TRILL BFD Control" | originat= orMAC ),
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 IS-IS-shared-key )

=A0 where HMAC-SHA256 is described in [RFC6234], "TRILL BFD Control&q= uot; is
=A0 the seventeen byte US ASCII [RFC20] string indicated= that is then
=A0 concatenated with the 6-byte MAC of the originating port. The MA= C
=A0 is included to minimize exposure of the same key to improve
=A0 resistance to cryptanalysis. IS-IS-key is the secret= keying
=A0 material being used for IS-IS authentication on the link. In the=
=A0 Authentication Section of the BFD Control frame OAM = protocol
=A0 specific data, Auth Type would be 5, Auth Len would be 28, and Auth =A0 Key ID is zero. The RBridges MAY be configured to use other BFD
=A0 security modes or keying material or configured to use no securi= ty.

=A0 Authentication for TRILL BFD Echo is a local implementation issue
=A0 as BFD Echo frames are authenticated by their sender= when received
=A0 in the form of Echo responses. However, if TRILL IS-IS and BFD
=A0 Control are being authenticated to a neighbor and BFD Echo is in
=A0 use, BFD Echo frames to be returned by that neighbor SHOULD be
=A0 authenticated and such authenticate SHOULD use different keying
=A0 material from other types of authentication. =A0For example, it could<= br> =A0 use keying material derived as follows:

=A0 =A0 =A0HMAC-SHA256 ( ( "TRILL BFD Echo" | originatorMA= C ),
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IS-IS-shared-key )

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



--
= "Do not lie. And do not do what you hate."
"Don't wor= ry, be happy"
--e0cb4efe34fad6c15e04b939206f-- --===============1441964125== 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 --===============1441964125==-- From rbridge-bounces@postel.org Sat Feb 18 01: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 C45E021F85DD for ; Sat, 18 Feb 2012 01:17:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=0.6, 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 jw0f1kzi2Abx for ; Sat, 18 Feb 2012 01:17:03 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE4F21F865B for ; Sat, 18 Feb 2012 01:17:03 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1I8cupP027706; Sat, 18 Feb 2012 00:38:58 -0800 (PST) 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 q1I8c7Bj027312 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sat, 18 Feb 2012 00:38:17 -0800 (PST) Received: by lagy4 with SMTP id y4so7689260lag.39 for ; Sat, 18 Feb 2012 00:38:06 -0800 (PST) Received-SPF: pass (google.com: domain of jon.hudson@gmail.com designates 10.152.136.20 as permitted sender) client-ip=10.152.136.20; Authentication-Results: mr.google.com; spf=pass (google.com: domain of jon.hudson@gmail.com designates 10.152.136.20 as permitted sender) smtp.mail=jon.hudson@gmail.com; dkim=pass header.i=jon.hudson@gmail.com Received: from mr.google.com ([10.152.136.20]) by 10.152.136.20 with SMTP id pw20mr9111498lab.32.1329554286850 (num_hops = 1); Sat, 18 Feb 2012 00:38:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kHH3m7YqejO0dVqbkUjR/v5KCdYDFS2KmXnjPSgAzx4=; b=q24q+ft76pV9GGSDTw4i1wlNXTDOpNM+Pn4P8kTZPNOQEwiMi/rcY3MEbaQGleN14P tPisGrcSX3DOvS4U22P84OhV+j/QxFPHJ+kWLbEhj6O95+LxiyKmb/ql9AGydAj71zj5 jK01eTvmzuNVpa1hxykT3VoWxEp1YFOQwGeaw= MIME-Version: 1.0 Received: by 10.152.136.20 with SMTP id pw20mr7614500lab.32.1329554284921; Sat, 18 Feb 2012 00:38:04 -0800 (PST) Received: by 10.112.10.196 with HTTP; Sat, 18 Feb 2012 00:38:04 -0800 (PST) In-Reply-To: References: <4F2991C6.7070904@acm.org> <012b01cce14a$9b0dbca0$d12935e0$@com> <4F2A0A63.30907@acm.org> Date: Sat, 18 Feb 2012 00:38:04 -0800 Message-ID: From: Jon Hudson To: rbridge@postel.org, Donald Eastlake X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: jon.hudson@gmail.com Cc: Erik Nordmark , Anoop Ghanwani , Yizhou Li Subject: Re: [rbridge] WG last call of draft-ietf-trill-rbridge-channel-04 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="===============0364999143==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org --===============0364999143== Content-Type: multipart/alternative; boundary=f46d042f9210dcc3fc04b938fa01 --f46d042f9210dcc3fc04b938fa01 Content-Type: text/plain; charset=ISO-8859-1 May I also suggest that if another version is created that TRILL-channel may be a more appropriate name than rbridge-channel. On Wed, Feb 15, 2012 at 8:57 PM, Donald Eastlake wrote: > Hi Anoop, > > On Wed, Feb 15, 2012 at 8:45 PM, Anoop Ghanwani > wrote: > > Hi Donald, > > > > ... > > > > Regarding the "egressing" issue, I assume you'll be modifying > > the text to make it clearer. It might also be good to have a statement > > that says channel messages only go between RBridges, > > or between an Rbridge and an end station; i.e. you can't > > have a channel message that goes from a "core" Rbridge > > to an end station without going through processing (which > > is more than simple egress decapsulation) at the egress > > RBridge. > > OK. I'll try to make that clearer. > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > > > Thanks, > > Anoop > > > > On Tue, Feb 14, 2012 at 9:02 PM, Donald Eastlake > wrote: > >> Hi Anoop, > >> > >> On Tue, Feb 14, 2012 at 11:45 AM, Anoop Ghanwani > wrote: > >>> Hi Donald, > >>> > >>> Thanks for the response. I have pulled out sections of the > >>> text that I want to respond to. > >>> > >>>> Anyway, setting the TRILL Header Extension Length (called Options > >>>> Length in RFC 6325) non-zero causes all the TRILL silicon I know about > >>>> to divert the frame to the slow path, which is the desired effect for > >>>> now. There is no need for the fast path logic to "look at" the > >>>> extended header at this time. > >>> > >>> But it probably won't be able to prioritize the frame > >>> correctly. > >> > >> I don't see why there would be a prioritization problem. The > >> Inner.VLAN tag is still there with the priority for re-queueing the > >> frame if it is forwarded. > >> > >>> If a message is going to be processed hop-by-hop, and it is > >>> unicast, would it not be better to just use the "AnyRBridge" nickname > >>> and embed the eventual egress RBridge in the payload? That way > >>> it becomes easily compatible with existing hardware. So, for the > >>> multicast case, we use a different reserved MAC, and for the > >>> unicast case we use AnyRBridge. I don't see that there would be > >>> any loss of functionality if we did that. > >> > >> The technique currently in the draft also seems to work fine and, > >> given that it previously got WG consensus, I don't particularly want > >> to change it. > >> > >>>> "Egressing" means being decapsulated, that is, leaving the TRILL > >>>> tunnel. You are correct that RBridge Channel protocol frames are only > >>>> intended to go between RBridges. But there are native RBridge Channel > >>>> messages that go between RBridges and end stations on the same link as > >>>> described in Section 4. An RBridge can create a native RBridge Channel > >>>> frame and unicast it to an attached end station, etc. > >>> > >>> Per your description, this would not be a valid case of > >>> "egressing", so the above text wouldn't apply to this case. > >> > >> There are two things being discussed. An RBridge-to-RBridge channel > >> message does get de-capsulated/egressed at its egress RBridge(s) (can > >> be more than one if multi-destination). But you are right that > >> creation and transmission and the reception and processing of a native > >> channel message does not involve "egressing" or "engrossing". > >> > >>>> You could also have a channel protocol, for example, that went from an > >>>> RBridge RB1, through RB2, to an end station or from that end station > >>>> through RB2 to RB1, but the frames would have to be manipulated by > >>>> that channel protocol at RB2 to convert between non-native and native > >>>> forms. At a minimum, the native channel frame has no TRILL Header > >>>> while the non-native inter-RBridge channel frame does. In addition, > >>>> you would have to complement the NA bit in the Channel Header and > >>>> adjust MAC addresses. That's what the next to the last paragraph in > >>>> Section 4 is about. But I would think that almost all channel > >>>> protocols would either be between RBridges or between an edge RBridge > >>>> and an end station. > >>> > >>> Would the case of manipulation be considered "egressing"? > >> > >> No, I don't think so. If the message went from RB1 to edge RBridge > >> RB2, it would be decapitated (egressed) at RB2. The manipulate would > >> be after the egressing and before the transmission as a native frame. > >> > >>> Since egressing in the strict sense is simplying decapsulating the > >>> frame and sending it out as a native frame, it seems to me that > >>> the scenario described in the quoted text should never happen. > >> > >> I guess you are right. I was using "egressing" in other than the > >> strictest sense -- as decapsulating and delivering, where delivering > >> might be transmitting through an external port but could just be > >> delivering to the slow path... > >> > >>> Anoop > >> > >> Thanks, > >> Donald > >> ============================= > >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) > >> 155 Beaver Street, Milford, MA 01757 USA > >> d3e3e3@gmail.com > >> > >>> On Mon, Feb 13, 2012 at 7:22 PM, Donald Eastlake > wrote: > >>>> Hi Anoop, > >>>> > >>>> Thanks for the comments. See below: > >>>> > >>>> On Thu, Feb 9, 2012 at 2:50 PM, Anoop Ghanwani > wrote: > >>>>> Here are some comments on the document. > >>>>> > >>>>> Technical comments > >>>>> =============== > >>>>> > >>>>> - I'm a bit concerned about the hop-by-hop processing which requires > >>>>> the ability to look at a bit in the extended header. I don't know if > >>>>> any alternatives were discussed...perhaps using a different > >>>>> inner.MACDA multicast address which indicates hop-by-hop processing > >>>>> is desired would work much better and would be compatible with > >>>>> existing silicon. Would there be any issues with using a separate > >>>>> multicast address for indicating hop-by-hop processing? > >>>> > >>>> I think the vast majority of channel protocols will either be (1) one > >>>> hop or (2) multi-hop with no per hop processing. In the case of a > >>>> multi-hop channel protocol frame that needs hop-by-hop processing (for > >>>> example something like record route or some protocol that wants source > >>>> routing), there are lots of ways you could modify such a frame to > >>>> alert the transit RBridges along the way. But these frames will > >>>> commonly be unicast, in which case there is no reason in the TRILL > >>>> base protocol for a transit RBridge to look at anything after the > >>>> TRILL Header, such as the Inner.MacDA. So you need to change something > >>>> in the TRILL Header. You could use a bit in the V field and/or the R > >>>> field, but people seemed to be against using those bits. > >>>> > >>>> Anyway, setting the TRILL Header Extension Length (called Options > >>>> Length in RFC 6325) non-zero causes all the TRILL silicon I know about > >>>> to divert the frame to the slow path, which is the desired effect for > >>>> now. There is no need for the fast path logic to "look at" the > >>>> extended header at this time. > >>>> > >>>> This is exactly how it was in the earlier version of this draft which > >>>> passed WGLC: > >>>> http://tools.ietf.org/html/draft-ietf-trill-rbridge-channel-01 > >>>> The only difference is that, in response to comments on this list, the > >>>> previous non-critical Alert Flag was supplemented by a critical Alert > >>>> Flag. > >>>> > >>>>> - State that the "Available Flags" part is reserved; i.e. set to > >>>>>zero on transmit, ignore on receipt. > >>>> > >>>> An excellent suggestion. How about, in Section 2.1.1, changing the > >>>> figure so the bits are labeled "Reserved" instead of "Available Flags" > >>>> and, after the descriptions of bits 0 thorugh 2, adding something > >>>> like: > >>>> > >>>> "Reserved: Bits reserved for future specification that MUST be sent > >>>> as zero and ignored on receipt." > >>>> > >>>>> - Section 3 > >>>>> >>> > >>>>> 2. If an RBridge Channel Alert extended header flag is set, then > >>>>> the RBridge MUST process the RBridge Channel message as > >>>>> described below even if it is not egressing the frame. If it > is > >>>>> egressing the frame, then no additional processing beyond > >>>>> egress processing is needed even if an RBridge Channel Alert > >>>>> flag is set. > >>>>> >>> > >>>>> Since the inner.MACDA is always All-Egress-RBridges, how would such > >>>>> a frame ever be allowed to be sent out an egress RBridge? It seems > >>>>> like end station can send a channel message, but an RBridge can't > >>>>> send one to an end station. > >>>> > >>>> "Egressing" means being decapsulated, that is, leaving the TRILL > >>>> tunnel. You are correct that RBridge Channel protocol frames are only > >>>> intended to go between RBridges. But there are native RBridge Channel > >>>> messages that go between RBridges and end stations on the same link as > >>>> described in Section 4. An RBridge can create a native RBridge Channel > >>>> frame and unicast it to an attached end station, etc. > >>>> > >>>> You could also have a channel protocol, for example, that went from an > >>>> RBridge RB1, through RB2, to an end station or from that end station > >>>> through RB2 to RB1, but the frames would have to be manipulated by > >>>> that channel protocol at RB2 to convert between non-native and native > >>>> forms. At a minimum, the native channel frame has no TRILL Header > >>>> while the non-native inter-RBridge channel frame does. In addition, > >>>> you would have to complement the NA bit in the Channel Header and > >>>> adjust MAC addresses. That's what the next to the last paragraph in > >>>> Section 4 is about. But I would think that almost all channel > >>>> protocols would either be between RBridges or between an edge RBridge > >>>> and an end station. > >>>> > >>>>> - Section 3.2 > >>>>> >>> > >>>>> For the protocol specific data area, an > >>>>> RBridge Channel Message Error frame has at least the first 256 > bytes > >>>>> (or less if less are available) of the erroneous decapsulated > channel > >>>>> message starting with the TRILL Header. (Note: The TRILL Header > does > >>>>> not include the TRILL Ethertype that is part of the Link Header on > >>>>> Ethernet Links and may be absent for other link technologies.) > >>>>> >>> > >>>>> > >>>>> What if the channel frame is a native frame? This aspect is not > >>>>> dealt with even in the section concerning native frames. > >>>> > >>>> Good point. The idea is to have all the differences between native and > >>>> non-native channel frames described in Section 4. The last paragraph > >>>> of Section 4 already mentions one native RBridge channel error message > >>>> difference. That last pragraph in Section 4 should have something like > >>>> the following added: > >>>> > >>>> "Also, since there is no TRILL Header in native RBridge Channel > >>>> protocol frames, the beginning part of the frame in which the error > >>>> was detected that is included in native RBridge Channel error > >>>> frames starts with the RBridge Channel Header." > >>>> > >>>>> - Section 4 > >>>>> >>> > >>>>> 2. If the frame is unicast, the destination MAC address is the > >>>>> unicast MAC address of the RBridge or end-station port that > is > >>>>> its intended destination. If the frame is multicast by an end > >>>>> station to all the RBridges on a link that support an RBridge > >>>>> Channel protocol that uses this transport, the destination > MAC > >>>>> address is the All-Edge-RBridges multicast address. If the > >>>>> frame is multicast by an RBridge to all the devices that > TRILL > >>>>> considers to be end stations on a link that support an > RBridge > >>>>> Channel protocol that uses this transport, the destination > MAC > >>>>> address is the TRILL-End-Stations multicast address (see > >>>>> Section 6). The RBridge-Channel Ethertype must be present. In > >>>>> the future there may be other protocols using the All-Edge- > >>>>> RBridges and/or TRILL-End-Stations multicast addresses on > >>>>> native frames distinguished by different Ethertypes. > >>>>> >>> > >>>>> This imposes some interesting requirements for filtering on ingress > >>>>> to the RBridge. > >>>> > >>>> It only imposes requirements on edge RBridges (or end stations) that > >>>> want to support one or more native RBridge channel protocols... > >>>> > >>>>> For example, what if the address on a channel frame > >>>>> does not match any of the ones specified above? > >>>> > >>>> I assume you are talking about a native RBridge channel frame since > >>>> the requirements on the Outer.MacDA of non-native RBridge channel > >>>> frames is the same as on TRILL Data frames. > >>>> > >>>> So, as per the text above, a native RBridge channel frame arriving at > >>>> an edge RBridge must have an Outer.MacDA of either the port's unicast > >>>> MAC address of the All-Edge-RBridges multicast address. If it has a > >>>> different unicast address, it is presumably intended for another > >>>> RBridge on the link and is discarded. If it has a different multicast > >>>> address, it is discarded. > >>>> > >>>>> Do we assume that > >>>>> channel messages received in native format must either be processed > >>>>> by the receiving RBridge or discarded? In other words it should not > >>>>> be possible to send a channel protocol frame from outside the TRILL > >>>>> network that enters or transits the TRILL network. > >>>> > >>>> Yes, that is my assumption. Probably a specific statement to that > >>>> effect should be added. > >>>> > >>>>> Editorial comments > >>>>> ============== > >>>>> - Section 1, 4th line > >>>>> "the implement" -> "that implement. > >>>> > >>>> Thanks for spotting that. > >>>> > >>>>> - Pg 5, line 9 from bottom > >>>>> depend -> and depending > >>>> > >>>> Thanks again. > >>>> > >>>> For a version show suggested resolutions of your comments and a > >>>> comparison to the current -04, see > >>>> http://www.pothole.com/~dee3/drafts/ > >>>> > >>>> Donald > >>>> ============================= > >>>> Donald E. Eastlake 3rd +1-508-333-2270 (cell) > >>>> 155 Beaver Street, Milford, MA 01757 USA > >>>> d3e3e3@gmail.com > >>>> > >>>>> On Wed, Feb 1, 2012 at 8:00 PM, Erik Nordmark > wrote: > >>>>>> On 2/1/12 5:33 PM, Yizhou Li wrote: > >>>>>>> The latest version should be 04. > >>>>>> > >>>>>> Yes. Thanks for the correction. > >>>>>> > >>>>>> Erik > >>>>>> > >>>>>>> Yizhou > >>>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: rbridge-bounces@postel.org [mailto: > rbridge-bounces@postel.org] On > >>>>>>> Behalf Of Erik Nordmark > >>>>>>> Sent: Thursday, February 02, 2012 3:26 AM > >>>>>>> To: rbridge@postel.org > >>>>>>> Subject: [rbridge] WG last call of > draft-ietf-trill-rbridge-channel-03 > >>>>>>> > >>>>>>> > >>>>>>> We're starting three separate last calls this week, but they are > all > >>>>>>> very short documents. > >>>>>>> > >>>>>>> We had an earlier WG last call on this document 6 months ago, and > there > >>>>>>> were some concerns about using the IS-IS genapp mechanism, so that > use > >>>>>>> has been removed. > >>>>>>> > >>>>>>> The WG last call ends on Feb 15th. > >>>>>>> Please send comments (including ones that say you've read the > document > >>>>>>> and it is fine) to the rbridge list. > >>>>>>> > >>>>>>> Erik > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > -- "Do not lie. And do not do what you hate." "Don't worry, be happy" --f46d042f9210dcc3fc04b938fa01 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable May I also suggest that if another version is created that TRILL-channel ma= y be a more appropriate name than rbridge-channel.

On Wed, Feb 15, 2012 at 8:57 PM, Donald Eastlake <d3e3e3@gmail.com> w= rote:
Hi Anoop,

On Wed, Feb 15, 2012 at 8:45 PM, Anoop Ghanwani <anoop@alumni.duke.edu> wrote:
> Hi Donald,
>
> ...
>
> Regarding the "egressing" issue, I assume you'll be modi= fying
> the text to make it clearer. =A0It might also be good to have a statem= ent
> that says channel messages only go between RBridges,
> or between an Rbridge and an end station; i.e. you can't
> have a channel message that goes from a "core" Rbridge
> to an end station without going through processing (which
> is more than simple egress decapsulation) at the egress
> RBridge.

OK. I'll try to make that clearer.

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,
> Anoop
>
> On Tue, Feb 14, 2012 at 9:02 PM, Donald Eastlake <d3e3e3@gmail.com> wrote:
>> Hi Anoop,
>>
>> On Tue, Feb 14, 2012 at 11:45 AM, Anoop Ghanwani <anoop@alumni.duke.edu> wrote:
>>> Hi Donald,
>>>
>>> Thanks for the response. =A0I have pulled out sections of the<= br> >>> text that I want to respond to.
>>>
>>>> Anyway, setting the TRILL Header Extension Length (called = Options
>>>> Length in RFC 6325) non-zero causes all the TRILL silicon = I know about
>>>> to divert the frame to the slow path, which is the desired= effect for
>>>> now. There is no need for the fast path logic to "loo= k at" the
>>>> extended header at this time.
>>>
>>> But it probably won't be able to prioritize the frame
>>> correctly.
>>
>> I don't see why there would be a prioritization problem. The >> Inner.VLAN tag is still there with the priority for re-queueing th= e
>> frame if it is forwarded.
>>
>>> If a message is going to be processed hop-by-hop, and it is >>> unicast, would it not be better to just use the "AnyRBrid= ge" nickname
>>> and embed the eventual egress RBridge in the payload? =A0That = way
>>> it becomes easily compatible with existing hardware. =A0So, fo= r the
>>> multicast case, we use a different reserved MAC, and for the >>> unicast case we use AnyRBridge. =A0I don't see that there = would be
>>> any loss of functionality if we did that.
>>
>> The technique currently in the draft also seems to work fine and,<= br> >> given that it previously got WG consensus, I don't particularl= y want
>> to change it.
>>
>>>> "Egressing" means being decapsulated, that is, l= eaving the TRILL
>>>> tunnel. You are correct that RBridge Channel protocol fram= es are only
>>>> intended to go between RBridges. But there are native RBri= dge Channel
>>>> messages that go between RBridges and end stations on the = same link as
>>>> described in Section 4. An RBridge can create a native RBr= idge Channel
>>>> frame and unicast it to an attached end station, etc.
>>>
>>> Per your description, this would not be a valid case of
>>> "egressing", so the above text wouldn't apply to= this case.
>>
>> There are two things being discussed. An RBridge-to-RBridge channe= l
>> message does get de-capsulated/egressed at its egress RBridge(s) (= can
>> be more than one if multi-destination). But you are right that
>> creation and transmission and the reception and processing of a na= tive
>> channel message does not involve "egressing" or "en= grossing".
>>
>>>> You could also have a channel protocol, for example, that = went from an
>>>> RBridge RB1, through RB2, to an end station or from that e= nd station
>>>> through RB2 to RB1, but the frames would have to be manipu= lated by
>>>> that channel protocol at RB2 to convert between non-native= and native
>>>> forms. At a minimum, the native channel frame has no TRILL= Header
>>>> while the non-native inter-RBridge channel frame does. In = addition,
>>>> you would have to complement the NA bit in the Channel Hea= der and
>>>> adjust MAC addresses. That's what the next to the last= paragraph in
>>>> Section 4 is about. But I would think that almost all chan= nel
>>>> protocols would either be between RBridges or between an e= dge RBridge
>>>> and an end station.
>>>
>>> Would the case of manipulation be considered "egressing&q= uot;?
>>
>> No, I don't think so. If the message went from RB1 to edge RBr= idge
>> RB2, it would be decapitated (egressed) at RB2. The manipulate wou= ld
>> be after the egressing and before the transmission as a native fra= me.
>>
>>> Since egressing in the strict sense is simplying decapsulating= the
>>> frame and sending it out as a native frame, it seems to me tha= t
>>> the scenario described in the quoted text should never happen.=
>>
>> I guess you are right. I was using "egressing" in other = than the
>> strictest sense -- as decapsulating and delivering, where deliveri= ng
>> might be transmitting through an external port but could just be >> delivering to the slow path...
>>
>>> Anoop
>>
>> 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, Feb 13, 2012 at 7:22 PM, Donald Eastlake <d3e3e3@gmail.com> wrote:
>>>> Hi Anoop,
>>>>
>>>> Thanks for the comments. See below:
>>>>
>>>> On Thu, Feb 9, 2012 at 2:50 PM, Anoop Ghanwani <anoop@alumni.duke.edu> wrote:
>>>>> Here are some comments on the document.
>>>>>
>>>>> Technical comments
>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>>>
>>>>> - I'm a bit concerned about the hop-by-hop process= ing which requires
>>>>> the ability to look at a bit in the extended header. I= don't know if
>>>>> any alternatives were discussed...perhaps using a diff= erent
>>>>> inner.MACDA multicast address which indicates hop-by-h= op processing
>>>>> is desired would work much better and would be compati= ble with
>>>>> existing silicon. Would there be any issues with using= a separate
>>>>> multicast address for indicating hop-by-hop processing= ?
>>>>
>>>> I think the vast majority of channel protocols will either= be (1) one
>>>> hop or (2) multi-hop with no per hop processing. In the ca= se of a
>>>> multi-hop channel protocol frame that needs hop-by-hop pro= cessing (for
>>>> example something like record route or some protocol that = wants source
>>>> routing), there are lots of ways you could modify such a f= rame to
>>>> alert the transit RBridges along the way. But these frames= will
>>>> commonly be unicast, in which case there is no reason in t= he TRILL
>>>> base protocol for a transit RBridge to look at anything af= ter the
>>>> TRILL Header, such as the Inner.MacDA. So you need to chan= ge something
>>>> in the TRILL Header. You could use a bit in the V field an= d/or the R
>>>> field, but people seemed to be against using those bits. >>>>
>>>> Anyway, setting the TRILL Header Extension Length (called = Options
>>>> Length in RFC 6325) non-zero causes all the TRILL silicon = I know about
>>>> to divert the frame to the slow path, which is the desired= effect for
>>>> now. There is no need for the fast path logic to "loo= k at" the
>>>> extended header at this time.
>>>>
>>>> This is exactly how it was in the earlier version of this = draft which
>>>> passed WGLC:
>>>> http://tools.ietf.org/html/draft-ietf-tr= ill-rbridge-channel-01
>>>> The only difference is that, in response to comments on th= is list, the
>>>> previous non-critical Alert Flag was supplemented by a cri= tical Alert
>>>> Flag.
>>>>
>>>>> - State that the "Available Flags" part is r= eserved; i.e. set to
>>>>>zero on transmit, ignore on receipt.
>>>>
>>>> An excellent suggestion. How about, in Section 2.1.1, chan= ging the
>>>> figure so the bits are labeled "Reserved" instea= d of "Available Flags"
>>>> and, after the descriptions of bits 0 thorugh 2, adding so= mething
>>>> like:
>>>>
>>>> =A0 "Reserved: Bits reserved for future specification= that MUST be sent
>>>> as zero and ignored on receipt."
>>>>
>>>>> - Section 3
>>>>> >>>
>>>>> =A0 =A0 =A02. If an RBridge Channel Alert extended hea= der flag is set, then
>>>>> =A0 =A0 =A0 =A0 the RBridge MUST process the RBridge C= hannel message as
>>>>> =A0 =A0 =A0 =A0 described below even if it is not egre= ssing the frame. If it is
>>>>> =A0 =A0 =A0 =A0 egressing the frame, then no additiona= l processing beyond
>>>>> =A0 =A0 =A0 =A0 egress processing is needed even if an= RBridge Channel Alert
>>>>> =A0 =A0 =A0 =A0 flag is set.
>>>>> >>>
>>>>> Since the inner.MACDA is always All-Egress-RBridges, h= ow would such
>>>>> a frame ever be allowed to be sent out an egress RBrid= ge? It seems
>>>>> like end station can send a channel message, but an RB= ridge can't
>>>>> send one to an end station.
>>>>
>>>> "Egressing" means being decapsulated, that is, l= eaving the TRILL
>>>> tunnel. You are correct that RBridge Channel protocol fram= es are only
>>>> intended to go between RBridges. But there are native RBri= dge Channel
>>>> messages that go between RBridges and end stations on the = same link as
>>>> described in Section 4. An RBridge can create a native RBr= idge Channel
>>>> frame and unicast it to an attached end station, etc.
>>>>
>>>> You could also have a channel protocol, for example, that = went from an
>>>> RBridge RB1, through RB2, to an end station or from that e= nd station
>>>> through RB2 to RB1, but the frames would have to be manipu= lated by
>>>> that channel protocol at RB2 to convert between non-native= and native
>>>> forms. At a minimum, the native channel frame has no TRILL= Header
>>>> while the non-native inter-RBridge channel frame does. In = addition,
>>>> you would have to complement the NA bit in the Channel Hea= der and
>>>> adjust MAC addresses. That's what the next to the last= paragraph in
>>>> Section 4 is about. But I would think that almost all chan= nel
>>>> protocols would either be between RBridges or between an e= dge RBridge
>>>> and an end station.
>>>>
>>>>> - Section 3.2
>>>>> >>>
>>>>> =A0 For the protocol specific data area, an
>>>>> =A0 RBridge Channel Message Error frame has at least t= he first 256 bytes
>>>>> =A0 (or less if less are available) of the erroneous d= ecapsulated channel
>>>>> =A0 message starting with the TRILL Header. (Note: The= TRILL Header does
>>>>> =A0 not include the TRILL Ethertype that is part of th= e Link Header on
>>>>> =A0 Ethernet Links and may be absent for other link te= chnologies.)
>>>>> >>>
>>>>>
>>>>> What if the channel frame is a native frame? This aspe= ct is not
>>>>> dealt with even in the section concerning native frame= s.
>>>>
>>>> Good point. The idea is to have all the differences betwee= n native and
>>>> non-native channel frames described in Section 4. The last= paragraph
>>>> of Section 4 already mentions one native RBridge channel e= rror message
>>>> difference. That last pragraph in Section 4 should have so= mething like
>>>> the following added:
>>>>
>>>> =A0 "Also, since there is no TRILL Header in native R= Bridge Channel
>>>> =A0 protocol frames, the beginning part of the frame in wh= ich the error
>>>> =A0 was detected that is included in native RBridge Channe= l error
>>>> =A0 frames starts with the RBridge Channel Header." >>>>
>>>>> - Section 4
>>>>> =A0>>>
>>>>> =A0 =A0 =A02. If the frame is unicast, the destination= MAC address is the
>>>>> =A0 =A0 =A0 =A0 unicast MAC address of the RBridge or = end-station port that is
>>>>> =A0 =A0 =A0 =A0 its intended destination. If the frame= is multicast by an end
>>>>> =A0 =A0 =A0 =A0 station to all the RBridges on a link = that support an RBridge
>>>>> =A0 =A0 =A0 =A0 Channel protocol that uses this transp= ort, the destination MAC
>>>>> =A0 =A0 =A0 =A0 address is the All-Edge-RBridges multi= cast address. If the
>>>>> =A0 =A0 =A0 =A0 frame is multicast by an RBridge to al= l the devices that TRILL
>>>>> =A0 =A0 =A0 =A0 considers to be end stations on a link= that support an RBridge
>>>>> =A0 =A0 =A0 =A0 Channel protocol that uses this transp= ort, the destination MAC
>>>>> =A0 =A0 =A0 =A0 address is the TRILL-End-Stations mult= icast address (see
>>>>> =A0 =A0 =A0 =A0 Section 6). The RBridge-Channel Ethert= ype must be present. In
>>>>> =A0 =A0 =A0 =A0 the future there may be other protocol= s using the All-Edge-
>>>>> =A0 =A0 =A0 =A0 RBridges and/or TRILL-End-Stations mul= ticast addresses on
>>>>> =A0 =A0 =A0 =A0 native frames distinguished by differe= nt Ethertypes.
>>>>> >>>
>>>>> This imposes some interesting requirements for filteri= ng on ingress
>>>>> to the RBridge.
>>>>
>>>> It only imposes requirements on edge RBridges (or end stat= ions) that
>>>> want to support one or more native RBridge channel protoco= ls...
>>>>
>>>>> For example, what if the address on a channel frame >>>>> does not match any of the ones specified above?
>>>>
>>>> I assume you are talking about a native RBridge channel fr= ame since
>>>> the requirements on the Outer.MacDA of non-native RBridge = channel
>>>> frames is the same as on TRILL Data frames.
>>>>
>>>> So, as per the text above, a native RBridge channel frame = arriving at
>>>> an edge RBridge must have an Outer.MacDA of either the por= t's unicast
>>>> MAC address of the All-Edge-RBridges multicast address. If= it has a
>>>> different unicast address, it is presumably intended for a= nother
>>>> RBridge on the link and is discarded. If it has a differen= t multicast
>>>> address, it is discarded.
>>>>
>>>>> Do we assume that
>>>>> channel messages received in native format must either= be processed
>>>>> by the receiving RBridge or discarded? In other words = it should not
>>>>> be possible to send a channel protocol frame from outs= ide the TRILL
>>>>> network that enters or transits the TRILL network.
>>>>
>>>> Yes, that is my assumption. Probably a specific statement = to that
>>>> effect should be added.
>>>>
>>>>> Editorial comments
>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>>> - Section 1, 4th line
>>>>> =A0"the implement" -> "that implemen= t.
>>>>
>>>> Thanks for spotting that.
>>>>
>>>>> - Pg 5, line 9 from bottom
>>>>> =A0depend -> and depending
>>>>
>>>> Thanks again.
>>>>
>>>> For a version show suggested resolutions of your comments = and a
>>>> comparison to the current -04, see
>>>> http://www.pothole.com/~dee3/drafts/
>>>>
>>>> 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 +1-508-333-2270 (cell)
>>>> =A0155 Beaver Street, Milford, MA 01757 USA
>>>> =A0d3e3e3@gmail.com
>>>>
>>>>> On Wed, Feb 1, 2012 at 8:00 PM, Erik Nordmark <nordmark@acm.org> wrote:
>>>>>> On 2/1/12 5:33 PM, Yizhou Li wrote:
>>>>>>> The latest version should be 04.
>>>>>>
>>>>>> Yes. Thanks for the correction.
>>>>>>
>>>>>> =A0 =A0Erik
>>>>>>
>>>>>>> Yizhou
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On
>>>>>>> Behalf Of Erik Nordmark
>>>>>>> Sent: Thursday, February 02, 2012 3:26 AM
>>>>>>> To: rbri= dge@postel.org
>>>>>>> Subject: [rbridge] WG last call of draft-ietf-= trill-rbridge-channel-03
>>>>>>>
>>>>>>>
>>>>>>> We're starting three separate last calls t= his week, but they are all
>>>>>>> very short documents.
>>>>>>>
>>>>>>> We had an earlier WG last call on this documen= t 6 months ago, and there
>>>>>>> were some concerns about using the IS-IS genap= p mechanism, so that use
>>>>>>> has been removed.
>>>>>>>
>>>>>>> The WG last call ends on Feb 15th.
>>>>>>> Please send comments (including ones that say = you've read the document
>>>>>>> and it is fine) to the rbridge list.
>>>>>>>
>>>>>>> =A0 =A0 Erik

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



--
= "Do not lie. And do not do what you hate."
"Don't wor= ry, be happy"
--f46d042f9210dcc3fc04b938fa01-- --===============0364999143== 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 --===============0364999143==-- From rbridge-bounces@postel.org Sat Feb 18 06:11:32 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 CE8C521F8547 for ; Sat, 18 Feb 2012 06:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.746 X-Spam-Level: X-Spam-Status: No, score=-105.746 tagged_above=-999 required=5 tests=[AWL=0.853, 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 qta4VKBQ2Fv6 for ; Sat, 18 Feb 2012 06:11:30 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 21A5621F8532 for ; Sat, 18 Feb 2012 06:11:30 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1IDw4g1008742; Sat, 18 Feb 2012 05:58:05 -0800 (PST) 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 q1IDvblP008724 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sat, 18 Feb 2012 05:57:47 -0800 (PST) Received: by lagy4 with SMTP id y4so7953458lag.39 for ; Sat, 18 Feb 2012 05:57:36 -0800 (PST) Received-SPF: pass (google.com: domain of d3e3e3@gmail.com designates 10.112.11.5 as permitted sender) client-ip=10.112.11.5; Authentication-Results: mr.google.com; spf=pass (google.com: domain of d3e3e3@gmail.com designates 10.112.11.5 as permitted sender) smtp.mail=d3e3e3@gmail.com; dkim=pass header.i=d3e3e3@gmail.com Received: from mr.google.com ([10.112.11.5]) by 10.112.11.5 with SMTP id m5mr4483381lbb.66.1329573456627 (num_hops = 1); Sat, 18 Feb 2012 05:57:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=0ijIrMnVsD85U4gP9HCuwwBga1RVBeVRgPAZPqsFSls=; b=SVtI7mFD08LXaxF6BCpo0JHzLvAuR07SYxvVDSs5PMn71InaXhhk5hWUaLHvcQjhM0 LivmGRLF/600tbuWrt2Ln68QDCGuLOp0FU+zj1fnzsJ3jaXp9T87G628Z0pyswHQrbM3 Y5jqFZuALA1RlFwi2mVR67qCcQLUQN5wD+dOo= Received: by 10.112.11.5 with SMTP id m5mr3741213lbb.66.1329573454799; Sat, 18 Feb 2012 05:57:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.80.234 with HTTP; Sat, 18 Feb 2012 05:57:14 -0800 (PST) In-Reply-To: <344037D7CFEFE84E97E9CC1F56C5F4A59BC38C@xmb-sjc-214.amer.cisco.com> References: <4F2991C6.7070904@acm.org> <344037D7CFEFE84E97E9CC1F56C5F4A59BC38C@xmb-sjc-214.amer.cisco.com> From: Donald Eastlake Date: Sat, 18 Feb 2012 08:57:14 -0500 Message-ID: To: "Tissa Senevirathne (tsenevir)" 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 q1IDvblP008724 Cc: rbridge@postel.org, Erik Nordmark Subject: Re: [rbridge] WG last call of draft-ietf-trill-rbridge-channel-03 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 Tissa, On Sat, Feb 18, 2012 at 12:29 AM, Tissa Senevirathne (tsenevir) wrote: > I have read this draft and have following comments. > > 1. This draft indicates the channels encaps proposed can be utilized as > a general method of sending OAM messages. > [Comment] I disagree with that comment. As the channel it is defined > currently. Utilize a fixed Multicast MAC address and specific Ethtype. > Additionally it require to use Source MAC address that belong to the > originating switch. > > In OAM the messages need to follow the path that the data frames takes. > With the above methods these channel frames follow a different path than > the data. Hence this cannot be effectively used for OAM. I guess you would have really hated the earlier versions where it was called the "OAM Channel" instead of the "RBridge Channel"... :-) You can use the channel mechanism for a variety of purposes including sending certain limited kinds of OAM messages. For example, it seems to me that it works fine for one-hop BFD messages or BFD Echo to a neighbor. > 2. This draft propos to use Channel header extended header flags for > certain conditions. > [comment] This may alter the forwarding path of the channel frame from > the original frames. Again that may reduce the coverage of OAM. What is > not clear is can a RBridges that cannot support extended header can > advertise itself as channel capable ? > > I propose this draft if needed to be moved to RFC state to remove all > reference to OAM. I think it is a good thing to reference at least one use as motivation when adding a new facility. "OAM" is currently mentioned only in the Abstract and the first section of the Introduction. How about if I replace that with a reference to BFD? > During the last WG in Taipei it was discussed that OAM proposals that > are based on the channel encapsulations may not really provide the ECMP > coverage Yes, that's right. Other mechanisms, similar to draft-tissa-trill-oam are probably better for general OAM. 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 > -----Original Message----- > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Erik Nordmark > Sent: Wednesday, February 01, 2012 11:26 AM > To: rbridge@postel.org > Subject: [rbridge] WG last call of draft-ietf-trill-rbridge-channel-03 > > > We're starting three separate last calls this week, but they are all > very short documents. > > We had an earlier WG last call on this document 6 months ago, and there > were some concerns about using the IS-IS genapp mechanism, so that use > has been removed. > > The WG last call ends on Feb 15th. > Please send comments (including ones that say you've read the document > and it is fine) to the rbridge list. > > =A0 Erik > > _______________________________________________ > 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 Sat Feb 18 09:29:17 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 5290021F853D for ; Sat, 18 Feb 2012 09:29:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.179 X-Spam-Level: X-Spam-Status: No, score=-6.179 tagged_above=-999 required=5 tests=[AWL=0.420, 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 hYlN6zSYHJRS for ; Sat, 18 Feb 2012 09:29:16 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 84B3121F852D for ; Sat, 18 Feb 2012 09:29:16 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1IHA74A004268; Sat, 18 Feb 2012 09:10:07 -0800 (PST) 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 q1IH9Y9J004231 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 18 Feb 2012 09:09:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tsenevir@cisco.com; l=3702; q=dns/txt; s=iport; t=1329584984; x=1330794584; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=6/cGg6eUh+9qg8K0ruaUGamJehXQQOzO1n8It3u8FYI=; b=ASwEhvNcSULj8+8A/DmVvZiLs+dbIUNCpHP5DcEv0cxVgQjywySbksR8 I5kUJKKDTKUivxxClXRhD2f4xvNMViqpR846ufFyX9SJUficO4p6sQh6b f/aw6Saj6fwzas1JvWTrLtvDHCH2Gad1/1MlX+1JlPd3sBP3kkRcgfBJY s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGvaP0+rRDoI/2dsb2JhbABBA7IlgQeBcwEBAQMBAQEBDwEdPgsFBwQCAQgOAwQBAQEKBhcBBgEgBh8JCAEBBBMIGodeCZpeAZ41iGpegkcZBg+DV1EEFAUMgkBjBIgbM5gAh3eBMg X-IronPort-AV: E=Sophos;i="4.73,443,1325462400"; d="scan'208";a="31210527" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 18 Feb 2012 17:09:34 +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 q1IH9YWI020831; Sat, 18 Feb 2012 17:09:34 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); Sat, 18 Feb 2012 09:09:34 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 18 Feb 2012 09:09:33 -0800 Message-ID: <344037D7CFEFE84E97E9CC1F56C5F4A59BC3B4@xmb-sjc-214.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] WG last call of draft-ietf-trill-rbridge-channel-03 Thread-Index: AczuRUbr4BdiJhMCQB6J3gLEVEjG3gAD4jAQ References: <4F2991C6.7070904@acm.org> <344037D7CFEFE84E97E9CC1F56C5F4A59BC38C@xmb-sjc-214.amer.cisco.com> From: "Tissa Senevirathne (tsenevir)" To: "Donald Eastlake" X-OriginalArrivalTime: 18 Feb 2012 17:09:34.0478 (UTC) FILETIME=[1644CAE0:01CCEE60] 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 q1IH9Y9J004231 Cc: rbridge@postel.org, Erik Nordmark Subject: Re: [rbridge] WG last call of draft-ietf-trill-rbridge-channel-03 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 I am ok, replacing OAM with BFD Thanks Tissa -----Original Message----- From: Donald Eastlake [mailto:d3e3e3@gmail.com] = Sent: Saturday, February 18, 2012 5:57 AM To: Tissa Senevirathne (tsenevir) Cc: Erik Nordmark; rbridge@postel.org Subject: Re: [rbridge] WG last call of draft-ietf-trill-rbridge-channel-03 Hi Tissa, On Sat, Feb 18, 2012 at 12:29 AM, Tissa Senevirathne (tsenevir) wrote: > I have read this draft and have following comments. > > 1. This draft indicates the channels encaps proposed can be utilized as > a general method of sending OAM messages. > [Comment] I disagree with that comment. As the channel it is defined > currently. Utilize a fixed Multicast MAC address and specific Ethtype. > Additionally it require to use Source MAC address that belong to the > originating switch. > > In OAM the messages need to follow the path that the data frames takes. > With the above methods these channel frames follow a different path than > the data. Hence this cannot be effectively used for OAM. I guess you would have really hated the earlier versions where it was called the "OAM Channel" instead of the "RBridge Channel"... :-) You can use the channel mechanism for a variety of purposes including sending certain limited kinds of OAM messages. For example, it seems to me that it works fine for one-hop BFD messages or BFD Echo to a neighbor. > 2. This draft propos to use Channel header extended header flags for > certain conditions. > [comment] This may alter the forwarding path of the channel frame from > the original frames. Again that may reduce the coverage of OAM. What is > not clear is can a RBridges that cannot support extended header can > advertise itself as channel capable ? > > I propose this draft if needed to be moved to RFC state to remove all > reference to OAM. I think it is a good thing to reference at least one use as motivation when adding a new facility. "OAM" is currently mentioned only in the Abstract and the first section of the Introduction. How about if I replace that with a reference to BFD? > During the last WG in Taipei it was discussed that OAM proposals that > are based on the channel encapsulations may not really provide the ECMP > coverage Yes, that's right. Other mechanisms, similar to draft-tissa-trill-oam are probably better for general OAM. 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 > -----Original Message----- > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Erik Nordmark > Sent: Wednesday, February 01, 2012 11:26 AM > To: rbridge@postel.org > Subject: [rbridge] WG last call of draft-ietf-trill-rbridge-channel-03 > > > We're starting three separate last calls this week, but they are all > very short documents. > > We had an earlier WG last call on this document 6 months ago, and there > were some concerns about using the IS-IS genapp mechanism, so that use > has been removed. > > The WG last call ends on Feb 15th. > Please send comments (including ones that say you've read the document > and it is fine) to the rbridge list. > > =A0 Erik > > _______________________________________________ > 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 Sat Feb 18 22:45:00 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 7D00D21F84DC for ; Sat, 18 Feb 2012 22:45:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.053 X-Spam-Level: X-Spam-Status: No, score=-5.053 tagged_above=-999 required=5 tests=[AWL=1.545, 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 TJ82-CcU2pD9 for ; Sat, 18 Feb 2012 22:44:59 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6A221F84D6 for ; Sat, 18 Feb 2012 22:44:59 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1J6XQh3010556; Sat, 18 Feb 2012 22:33:27 -0800 (PST) Received: from mail-tul01m020-f180.google.com (mail-tul01m020-f180.google.com [209.85.214.180]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1J6X74O010538 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 18 Feb 2012 22:33:16 -0800 (PST) Received: by obbuo19 with SMTP id uo19so10080762obb.39 for ; Sat, 18 Feb 2012 22:33:07 -0800 (PST) Received-SPF: pass (google.com: domain of vishwas.ietf@gmail.com designates 10.60.29.68 as permitted sender) client-ip=10.60.29.68; Authentication-Results: mr.google.com; spf=pass (google.com: domain of vishwas.ietf@gmail.com designates 10.60.29.68 as permitted sender) smtp.mail=vishwas.ietf@gmail.com; dkim=pass header.i=vishwas.ietf@gmail.com Received: from mr.google.com ([10.60.29.68]) by 10.60.29.68 with SMTP id i4mr6808163oeh.7.1329633187220 (num_hops = 1); Sat, 18 Feb 2012 22:33:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cp+JKoP3CDc40HaLv/GdDqu+HGl7nOBF1S+OCdbFNeE=; b=mbEeFRz8w0FOaVZX/EFTD6Ytl8lNTxGTnNpCwW2WqNoARZQnpiBL3wwPdJXqjJlD07 R933Bp9UqL6A/tSPvNn+Y57z/Jg4Za56A3ZqysvcNgD4dLlcJJm3UswCvUopon0ATnCs NEcV/d1DwSSYW2ziQ76t4hL9tLtMPzPF/dxrk= MIME-Version: 1.0 Received: by 10.60.29.68 with SMTP id i4mr5793937oeh.7.1329633187134; Sat, 18 Feb 2012 22:33:07 -0800 (PST) Received: by 10.182.165.1 with HTTP; Sat, 18 Feb 2012 22:33:07 -0800 (PST) In-Reply-To: <344037D7CFEFE84E97E9CC1F56C5F4A59BC38C@xmb-sjc-214.amer.cisco.com> References: <4F2991C6.7070904@acm.org> <344037D7CFEFE84E97E9CC1F56C5F4A59BC38C@xmb-sjc-214.amer.cisco.com> Date: Sat, 18 Feb 2012 22:33:07 -0800 Message-ID: From: Vishwas Manral To: "Tissa Senevirathne (tsenevir)" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: vishwas.ietf@gmail.com Cc: rbridge@postel.org, Erik Nordmark Subject: Re: [rbridge] WG last call of draft-ietf-trill-rbridge-channel-03 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="===============0646539102==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org --===============0646539102== Content-Type: multipart/alternative; boundary=e89a8fb20272ccfd0904b94b59f7 --e89a8fb20272ccfd0904b94b59f7 Content-Type: text/plain; charset=ISO-8859-1 Hi Tissa, > 1. This draft indicates the channels encaps proposed can be utilized as > a general method of sending OAM messages. > [Comment] I disagree with that comment. As the channel it is defined > currently. Utilize a fixed Multicast MAC address and specific Ethtype. > Additionally it require to use Source MAC address that belong to the > originating switch. > > In OAM the messages need to follow the path that the data frames takes. > With the above methods these channel frames follow a different path than > the data. Hence this cannot be effectively used for OAM. > I agree partially with what you say. The channel is to allow sending. receiving packets directly over the TRILL layer. It gives a way to demultiplex different kinds of packets and can be used for OAM packets. If I understand correctly not all data frames in the DC are TCP/ UDP based? Also in the ideal case the forwarding in the TRILL layer should depend on the TRILL header. In this case the TRILL of the channel header is the same as that of the data packet. I however understand for good multiplexing we do look deeper into the packet, but what that also leads to is the fact that all DC switches should now be able to support looking deeper into IPv6 and all its present/ future extension headers to provide the ideal de/multiplexing, which may not be the case . > 2. This draft propos to use Channel header extended header flags for > certain conditions. > [comment] This may alter the forwarding path of the channel frame from > the original frames. Again that may reduce the coverage of OAM. What is > not clear is can a RBridges that cannot support extended header can > advertise itself as channel capable ? > I propose this draft if needed to be moved to RFC state to remove all > reference to OAM. > > During the last WG in Taipei it was discussed that OAM proposals that > are based on the channel encapsulations may not really provide the ECMP > coverage > VM> Like I mentioned, I agree there are limitations because of the fact we do deeper packet inspection for doing ECMP/ LAG mux/ demux. I however do not see why it cannot be used in cases I have mentioned above. Thanks, Vishwas > > -----Original Message----- > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Erik Nordmark > Sent: Wednesday, February 01, 2012 11:26 AM > To: rbridge@postel.org > Subject: [rbridge] WG last call of draft-ietf-trill-rbridge-channel-03 > > > We're starting three separate last calls this week, but they are all > very short documents. > > We had an earlier WG last call on this document 6 months ago, and there > were some concerns about using the IS-IS genapp mechanism, so that use > has been removed. > > The WG last call ends on Feb 15th. > Please send comments (including ones that say you've read the document > and it is fine) to the rbridge list. > > Erik > --e89a8fb20272ccfd0904b94b59f7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Tissa,


1. This draft indicates the channels encaps proposed can be utilized as
a general method of sending OAM messages.
[Comment] I disagree with that comment. As the channel it is defined
currently. Utilize a fixed Multicast MAC address and specific Ethtype.
Additionally it require to use Source MAC address that belong to the
originating switch.

In OAM the messages need to follow the path that the data frames takes.
With the above methods these channel frames follow a different path than the data. Hence this cannot be effectively used for OAM.
I agree partially with what you say. The channel is to allow sending. re= ceiving packets directly over the TRILL layer. It gives a way to demultiple= x different kinds of packets and can be used for OAM packets. If I understa= nd correctly not all data frames in the DC are TCP/ UDP based?

Also in the ideal case the forwarding in the TRILL layer should depend = on the TRILL header. In this case the TRILL of the channel header is the sa= me as that of the data packet. I however understand for good multiplexing w= e do look deeper into the packet, but what that also leads to is the fact t= hat all DC switches should now be able to support looking deeper into IPv6 = and all its present/ future extension headers to provide the ideal de/multi= plexing, which may not be the case .
=A0
2. This draft propos to use Channel header extended header flags for
certain conditions.
[comment] This may alter the forwarding path of the channel frame from
the original frames. Again that may reduce the coverage of OAM. What is
not clear is can a RBridges that cannot support extended header can
advertise itself as channel capable ?
I propose this draft if needed to be moved to RFC state to remove all
reference to OAM.

During the last WG in Taipei it was discussed that OAM proposals that
are based on the channel encapsulations may not really provide the ECMP
coverage
VM> Like I mentioned, I agree there are li= mitations because of the fact we do deeper packet inspection for doing ECMP= / LAG mux/ demux. I however do not see why it cannot be used in cases I hav= e mentioned above.

Thanks,
Vishwas
=A0

-----Original Message-----
From: rbridge-bounces@postel.= org [mailto:rbridge-bounc= es@postel.org] On
Behalf Of Erik Nordmark
Sent: Wednesday, February 01, 2012 11:26 AM
To: rbridge@postel.org
Subject: [rbridge] WG last call of draft-ietf-trill-rbridge-channel-03


We're starting three separate last calls this week, but they are all very short documents.

We had an earlier WG last call on this document 6 months ago, and there
were some concerns about using the IS-IS genapp mechanism, so that use
has been removed.

The WG last call ends on Feb 15th.
Please send comments (including ones that say you've read the document<= br> and it is fine) to the rbridge list.

=A0 Erik

--e89a8fb20272ccfd0904b94b59f7-- --===============0646539102== 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 --===============0646539102==-- From rbridge-bounces@postel.org Mon Feb 20 09:11: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 97BC221F8729 for ; Mon, 20 Feb 2012 09:10:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.206 X-Spam-Level: X-Spam-Status: No, score=-6.206 tagged_above=-999 required=5 tests=[AWL=0.392, 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 SMNXjx9XIgff for ; Mon, 20 Feb 2012 09:10:35 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 7C26521F85A5 for ; Mon, 20 Feb 2012 09:10:34 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1KGplkl001325; Mon, 20 Feb 2012 08:51:48 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1KGpDx5001210 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 20 Feb 2012 08:51:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tsenevir@cisco.com; l=14304; q=dns/txt; s=iport; t=1329756682; x=1330966282; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=abecM5LUoP82vZZ72HBJzgDOFwdYr+/hNYyLExS6ohw=; b=iImzYgyTS37iYsuL7WvzYhYaVvsgjJinOuLTf65524FcUAOsa13djzi/ 8pJK4BuMpQpEsoK9zdtxrSDz+zoHVOVt5OUEXdWqi82Y4rQu+kKgRCCBt ItyXdsVa2qChiWMpeOozWqPsGXJAoei9e0+KUA6f/5PTSGrCpF9GbT5kx Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAOd5Qk+rRDoH/2dsb2JhbABEgk2vCYEHgXMBAQEEEgEJEQNJDAQCAQgRBAEBCwYXAQYBICUJCAEBBBMIGqJuAZ54iGqDFQMID4QKDIM2YwSITokJjneHdw X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208,217";a="29630845" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 20 Feb 2012 16:50:57 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q1KGovIN007374; Mon, 20 Feb 2012 16:50:57 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, 20 Feb 2012 08:50:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 20 Feb 2012 08:50:01 -0800 Message-ID: <344037D7CFEFE84E97E9CC1F56C5F4A59BC54D@xmb-sjc-214.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] WG last call of draft-ietf-trill-rbridge-channel-03 Thread-Index: Aczu0FhZPQirsO/lQuW84N87NPUO2wBHJMPw References: <4F2991C6.7070904@acm.org><344037D7CFEFE84E97E9CC1F56C5F4A59BC38C@xmb-sjc-214.amer.cisco.com> From: "Tissa Senevirathne (tsenevir)" To: "Vishwas Manral" X-OriginalArrivalTime: 20 Feb 2012 16:50:57.0238 (UTC) FILETIME=[D12AFF60:01CCEFEF] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: tsenevir@cisco.com Cc: rbridge@postel.org, Erik Nordmark Subject: Re: [rbridge] WG last call of draft-ietf-trill-rbridge-channel-03 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="===============0302305811==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org This is a multi-part message in MIME format. --===============0302305811== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCEFEF.AFD8DBAE" This is a multi-part message in MIME format. ------_=_NextPart_001_01CCEFEF.AFD8DBAE Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Vishwas =20 Very interesting comment "not all traffic in networks are IP". Yes not all traffic in networks are IP, in the same token majority of traffic in networks are IP. =20 While TRILL does forwarding based on TRILL header and supports Equal cost multi-pathing. Traffic is allocated to multiple equal cost paths per flow basis. While definition of a flow is outside the scope of RFC6325, in classical Ethernet Ling Aggregation bundles, traffic is hashed to different links based on L3 information. This is a very common practice.=20 =20 When you are defining generic OAM channel it is important to provide flexibility to address full set of issues rather than sub-set. =20 My objection on presenting rbridge-channel draft as a generic OAM messaging channel is based on the fact that it covers only a subset. It may cover some specific needs of applications such as BFD. =20 I am ok if wording of reference to generic OAM is replaced with wording of like "messaging channel for applications such as BFD" =20 =20 =20 =20 =20 From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]=20 Sent: Saturday, February 18, 2012 10:33 PM To: Tissa Senevirathne (tsenevir) Cc: Erik Nordmark; rbridge@postel.org Subject: Re: [rbridge] WG last call of draft-ietf-trill-rbridge-channel-03 =20 Hi Tissa, =09 1. This draft indicates the channels encaps proposed can be utilized as a general method of sending OAM messages. [Comment] I disagree with that comment. As the channel it is defined currently. Utilize a fixed Multicast MAC address and specific Ethtype. Additionally it require to use Source MAC address that belong to the originating switch. =09 In OAM the messages need to follow the path that the data frames takes. With the above methods these channel frames follow a different path than the data. Hence this cannot be effectively used for OAM. I agree partially with what you say. The channel is to allow sending. receiving packets directly over the TRILL layer. It gives a way to demultiplex different kinds of packets and can be used for OAM packets. If I understand correctly not all data frames in the DC are TCP/ UDP based? Also in the ideal case the forwarding in the TRILL layer should depend on the TRILL header. In this case the TRILL of the channel header is the same as that of the data packet. I however understand for good multiplexing we do look deeper into the packet, but what that also leads to is the fact that all DC switches should now be able to support looking deeper into IPv6 and all its present/ future extension headers to provide the ideal de/multiplexing, which may not be the case . =20 2. This draft propos to use Channel header extended header flags for certain conditions. [comment] This may alter the forwarding path of the channel frame from the original frames. Again that may reduce the coverage of OAM. What is not clear is can a RBridges that cannot support extended header can advertise itself as channel capable ? I propose this draft if needed to be moved to RFC state to remove all reference to OAM. =09 During the last WG in Taipei it was discussed that OAM proposals that are based on the channel encapsulations may not really provide the ECMP coverage VM> Like I mentioned, I agree there are limitations because of the fact we do deeper packet inspection for doing ECMP/ LAG mux/ demux. I however do not see why it cannot be used in cases I have mentioned above. Thanks, Vishwas =20 =09 -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Erik Nordmark Sent: Wednesday, February 01, 2012 11:26 AM To: rbridge@postel.org Subject: [rbridge] WG last call of draft-ietf-trill-rbridge-channel-03 =09 =09 We're starting three separate last calls this week, but they are all very short documents. =09 We had an earlier WG last call on this document 6 months ago, and there were some concerns about using the IS-IS genapp mechanism, so that use has been removed. =09 The WG last call ends on Feb 15th. Please send comments (including ones that say you've read the document and it is fine) to the rbridge list. =09 Erik =20 ------_=_NextPart_001_01CCEFEF.AFD8DBAE Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi Vishwas

 

Very interesting comment “not all traffic in networks are = IP”. Yes not all traffic in networks are IP, in the same token = majority of traffic in networks are IP.

 

While TRILL does forwarding based on TRILL header and supports Equal = cost multi-pathing. Traffic is allocated to multiple equal cost paths =  per flow basis. While definition of a flow is outside the scope of = RFC6325, in classical Ethernet Ling Aggregation bundles, traffic is = hashed to different links based on L3 information. This is a very common = practice.

 

When you are defining generic OAM channel it is important to provide = flexibility to address full set of issues rather than = sub-set.

 

My objection on presenting rbridge-channel draft as a generic OAM = messaging channel is based on the fact that it covers only a subset. It = may cover some specific needs of applications such as = BFD.

 

I am ok if wording of reference to generic OAM is replaced with = wording of like “messaging channel for applications such as = BFD”

 

 

 

 

 

From:= = Vishwas Manral [mailto:vishwas.ietf@gmail.com]
Sent: = Saturday, February 18, 2012 10:33 PM
To: Tissa Senevirathne = (tsenevir)
Cc: Erik Nordmark; = rbridge@postel.org
Subject: Re: [rbridge] WG last call of = draft-ietf-trill-rbridge-channel-03

 

Hi Tissa,


1. = This draft indicates the channels encaps proposed can be utilized = as
a general method of sending OAM messages.
[Comment] I disagree = with that comment. As the channel it is defined
currently. Utilize a = fixed Multicast MAC address and specific Ethtype.
Additionally it = require to use Source MAC address that belong to the
originating = switch.

In OAM the messages need to follow the path that the data = frames takes.
With the above methods these channel frames follow a = different path than
the data. Hence this cannot be effectively used = for OAM.

I agree = partially with what you say. The channel is to allow sending. receiving = packets directly over the TRILL layer. It gives a way to demultiplex = different kinds of packets and can be used for OAM packets. If I = understand correctly not all data frames in the DC are TCP/ UDP = based?

Also in the ideal case the forwarding in the TRILL layer = should depend on the TRILL header. In this case the TRILL of the channel = header is the same as that of the data packet. I however understand for = good multiplexing we do look deeper into the packet, but what that also = leads to is the fact that all DC switches should now be able to support = looking deeper into IPv6 and all its present/ future extension headers = to provide the ideal de/multiplexing, which may not be the case = .

 

2. This = draft propos to use Channel header extended header flags for
certain = conditions.
[comment] This may alter the forwarding path of the = channel frame from
the original frames. Again that may reduce the = coverage of OAM. What is
not clear is can a RBridges that cannot = support extended header can
advertise itself as channel capable = ?
I propose this draft if needed to be moved to RFC state to remove = all
reference to OAM.

During the last WG in Taipei it was = discussed that OAM proposals that
are based on the channel = encapsulations may not really provide the = ECMP
coverage

VM> Like I mentioned, I agree there are limitations = because of the fact we do deeper packet inspection for doing ECMP/ LAG = mux/ demux. I however do not see why it cannot be used in cases I have = mentioned = above.

Thanks,
Vishwas
 


-----Original Message-----
From: rbridge-bounces@postel.org= [mailto:rbridge-bounces@postel.org= ] On
Behalf Of Erik Nordmark
Sent: Wednesday, February 01, 2012 = 11:26 AM
To: rbridge@postel.org
Subject: = [rbridge] WG last call of = draft-ietf-trill-rbridge-channel-03


We're starting three = separate last calls this week, but they are all
very short = documents.

We had an earlier WG last call on this document 6 = months ago, and there
were some concerns about using the IS-IS genapp = mechanism, so that use
has been removed.

The WG last call ends = on Feb 15th.
Please send comments (including ones that say you've = read the document
and it is fine) to the rbridge list.

  = Erik

 

------_=_NextPart_001_01CCEFEF.AFD8DBAE-- --===============0302305811== 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 --===============0302305811==-- From rbridge-bounces@postel.org Mon Feb 20 19:16: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 65E1D21F8598 for ; Mon, 20 Feb 2012 19:16:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.842 X-Spam-Level: X-Spam-Status: No, score=-4.842 tagged_above=-999 required=5 tests=[AWL=1.757, 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 0BBDSQyYMGOG for ; Mon, 20 Feb 2012 19:16:55 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 955D821F8594 for ; Mon, 20 Feb 2012 19:16:55 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1L2xW3P006913; Mon, 20 Feb 2012 18:59:33 -0800 (PST) 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 q1L2xA0d006866 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 20 Feb 2012 18:59:20 -0800 (PST) Received: by lagy4 with SMTP id y4so11746209lag.39 for ; Mon, 20 Feb 2012 18:59:09 -0800 (PST) Received-SPF: pass (google.com: domain of mmcbride7@gmail.com designates 10.152.112.132 as permitted sender) client-ip=10.152.112.132; Authentication-Results: mr.google.com; spf=pass (google.com: domain of mmcbride7@gmail.com designates 10.152.112.132 as permitted sender) smtp.mail=mmcbride7@gmail.com; dkim=pass header.i=mmcbride7@gmail.com Received: from mr.google.com ([10.152.112.132]) by 10.152.112.132 with SMTP id iq4mr17172922lab.28.1329793149287 (num_hops = 1); Mon, 20 Feb 2012 18:59:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=KK11uaQHIGPvU0tB4vJvMw2XpZEVy9/A6m5DTVCip50=; b=OqCAKo9lKDoZO5/tqU5UBfYIjJa+NVKARu8UIYqaYB2D4KIqql9QkPwE6tc/U6hSHt JldJ6rKUHLwaU6HMAOTp5tJQOZqYQVsBEQp4Nzv6+LJsHDXjhOtU6GF/KbFRFI435kSs EQPIf93S2F2JrOpSWdARzpW/sUf4saknjFQfk= MIME-Version: 1.0 Received: by 10.152.112.132 with SMTP id iq4mr14300632lab.28.1329793149212; Mon, 20 Feb 2012 18:59:09 -0800 (PST) Received: by 10.112.45.99 with HTTP; Mon, 20 Feb 2012 18:59:09 -0800 (PST) In-Reply-To: References: <20120109132058.9151.5560.idtracker@ietfa.amsl.com> Date: Mon, 20 Feb 2012 18:59:09 -0800 Message-ID: From: Mike McBride To: Jon Hudson X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: mmcbride7@gmail.com X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id q1L2xA0d006866 Cc: rbridge@postel.org Subject: Re: [rbridge] I-D Action: draft-ietf-trill-rbridge-extension-02.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 Likewise. I support the document. mike On Sat, Feb 18, 2012 at 12:25 AM, Jon Hudson wrote: > I have read this and support the document. > > Very sorry for missing the 15th deadline, I have been ofline. > > On Mon, Jan 9, 2012 at 8:18 PM, Donald Eastlake wrote: >> >> This version incorporates change discussed on the WG mailing 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, Jan 9, 2012 at 8:20 AM, =A0 wrote: >> > >> > A New Internet-Draft is available from the on-line Internet-Drafts >> > directories. This draft is a work item of the Transparent Interconnect= ion of >> > Lots of Links Working Group of the IETF. >> > >> > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : TRILL: Header Extension >> > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Donald Eastlake >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Anoop Ghanwani >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Vishwas Manral >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Yizhou Li >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Caitlin Bestler >> > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-trill-rbridge-exte= nsion-02.txt >> > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 16 >> > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-01-09 >> > >> > =A0 The IETF TRILL (Transparent Interconnection of Lots of Links) base >> > =A0 protocol specifies minimal hooks to safely support TRILL Header >> > =A0 extensions. This document specifies an initial extension providing >> > =A0 additional flag bits and specifies two of those bits. >> > >> > >> > >> > A URL for this Internet-Draft is: >> > >> > http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-extension= -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-rbridge-extension-= 02.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 > _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge From rbridge-bounces@postel.org Tue Feb 21 01:38: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 950DB21F8601 for ; Tue, 21 Feb 2012 01:38:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.571 X-Spam-Level: X-Spam-Status: No, score=-104.571 tagged_above=-999 required=5 tests=[AWL=2.028, 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 Rx69u54pNpAx for ; Tue, 21 Feb 2012 01:38:03 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id BFF0C21F85F2 for ; Tue, 21 Feb 2012 01:38:03 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1L97CXG003782; Tue, 21 Feb 2012 01:07:12 -0800 (PST) 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 q1L96j24003733 for ; Tue, 21 Feb 2012 01:06:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C4921F8611 for ; Tue, 21 Feb 2012 01:06:43 -0800 (PST) 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 ulYnpEfONpr1; Tue, 21 Feb 2012 01:06:39 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17D1C21F8607; Tue, 21 Feb 2012 01:06:39 -0800 (PST) MIME-Version: 1.0 From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120221090639.22723.50618.idtracker@ietfa.amsl.com> Date: Tue, 21 Feb 2012 01:06:39 -0800 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 q1L96j24003733 Cc: rbridge@postel.org Subject: [rbridge] I-D Action: draft-ietf-trill-rbridge-channel-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: RBridge Channel Support Author(s) : Donald Eastlake Vishwas Manral Yizhou Li Sam Aldrin Dave Ward Filename : draft-ietf-trill-rbridge-channel-05.txt Pages : 26 Date : 2012-02-21 This document specifies a general channel mechanism for sending messages, such as BFD (Bidirectional Forwarding Detection) messages, between RBridges (Routing Bridges) and between RBridges and end stations in an RBridge campus through extensions to the 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-channel-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-channel-05.txt _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge From rbridge-bounces@postel.org Tue Feb 21 02:04: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 ECC0521F8609 for ; Tue, 21 Feb 2012 02:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.761 X-Spam-Level: X-Spam-Status: No, score=-105.761 tagged_above=-999 required=5 tests=[AWL=0.838, 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 CnFJr9u5fh1r for ; Tue, 21 Feb 2012 02:04:42 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 74B1121F85CD for ; Tue, 21 Feb 2012 02:04:41 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1L9aAJ5008807; Tue, 21 Feb 2012 01:36:11 -0800 (PST) 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 q1L9ZTFc008717 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 21 Feb 2012 01:35:39 -0800 (PST) Received: by lagy4 with SMTP id y4so12274624lag.39 for ; Tue, 21 Feb 2012 01:35:28 -0800 (PST) Received-SPF: pass (google.com: domain of d3e3e3@gmail.com designates 10.152.123.68 as permitted sender) client-ip=10.152.123.68; Authentication-Results: mr.google.com; spf=pass (google.com: domain of d3e3e3@gmail.com designates 10.152.123.68 as permitted sender) smtp.mail=d3e3e3@gmail.com; dkim=pass header.i=d3e3e3@gmail.com Received: from mr.google.com ([10.152.123.68]) by 10.152.123.68 with SMTP id ly4mr18161877lab.13.1329816928320 (num_hops = 1); Tue, 21 Feb 2012 01:35:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=YmFoQnGArKpvdraGzZfvI3EgZkRGTqI+++bm25SDDF8=; b=DWYG8xUmDHpWq2Mcm71B1UWxTJ0ioW1oJL0Tm7U2JkFGanYGIZ0WnYR1MHYVBoq9Go +/8cPjqwa4z4G3T/Ud42iOwoWpdUvpl4j54T6VXd/uuZCejk7ceYb5U3BAIkU5HjgtSs aPvsOO2q48O2uIZSHwEF/Rv7l6vNJjuFdOrAA= Received: by 10.152.123.68 with SMTP id ly4mr15216002lab.13.1329816928250; Tue, 21 Feb 2012 01:35:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.80.234 with HTTP; Tue, 21 Feb 2012 01:35:08 -0800 (PST) In-Reply-To: <20120221090639.22723.50618.idtracker@ietfa.amsl.com> References: <20120221090639.22723.50618.idtracker@ietfa.amsl.com> From: Donald Eastlake Date: Tue, 21 Feb 2012 04:35:08 -0500 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 q1L9ZTFc008717 Subject: Re: [rbridge] I-D Action: draft-ietf-trill-rbridge-channel-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, I believe this updated version resolves the WGLC comments on this draft. 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, Feb 21, 2012 at 4:06 AM, 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: RBridge Channel Support > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Donald Eastlake > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Vishwas Manral > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Yizhou Li > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Sam Aldrin > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Dave Ward > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-trill-rbridge-channel= -05.txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 26 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-02-21 > > =A0 This document specifies a general channel mechanism for sending > =A0 messages, such as BFD (Bidirectional Forwarding Detection) messages, > =A0 between RBridges (Routing Bridges) and between RBridges and end > =A0 stations in an RBridge campus through extensions to the TRILL > =A0 (TRansparent Interconnection of Lots of Links) protocol. > > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-channel-05.t= xt > > 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-channel-05.txt _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge From rbridge-bounces@postel.org Tue Feb 21 06:48:59 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 B319721F8824 for ; Tue, 21 Feb 2012 06:48:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.506 X-Spam-Level: X-Spam-Status: No, score=-107.506 tagged_above=-999 required=5 tests=[AWL=-0.907, 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 Yz3OTZYpNeK7 for ; Tue, 21 Feb 2012 06:48:55 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id DD36D21F87B1 for ; Tue, 21 Feb 2012 06:48:55 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1LEQMSV001499; Tue, 21 Feb 2012 06:26:23 -0800 (PST) Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1LEPh6P001450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 21 Feb 2012 06:25:52 -0800 (PST) Received: from /spool/local by e7.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 21 Feb 2012 09:25:42 -0500 Received: from d01dlp01.pok.ibm.com (9.56.224.56) by e7.ny.us.ibm.com (192.168.1.107) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 21 Feb 2012 09:23:02 -0500 Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id B5C6038C8095 for ; Tue, 21 Feb 2012 09:22:53 -0500 (EST) Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q1LEMrLb262992 for ; Tue, 21 Feb 2012 09:22:53 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q1LEMqBB032032 for ; Tue, 21 Feb 2012 12:22:52 -0200 Received: from cichlid.raleigh.ibm.com (sig-9-65-242-81.mts.ibm.com [9.65.242.81]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q1LEMpVc031990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 21 Feb 2012 12:22:51 -0200 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 q1LEMDin024613 for ; Tue, 21 Feb 2012 09:22:14 -0500 Message-Id: <201202211422.q1LEMDin024613@cichlid.raleigh.ibm.com> To: rbridge@postel.org Date: Tue, 21 Feb 2012 09:22:13 -0500 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12022114-5806-0000-0000-000012B68BED X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: narten@us.ibm.com Subject: [rbridge] Trill Extensions and options 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org There are a number of WG LC's going on at the moment, including rbridge-extension. I've also been reviewing and thinking about the entire set and looking at OAM approaches as well. At this point, I guess I have to say am am unsold on the need for the extensions document and options at all. I'm raising this issue from the perspective of wanting to be convinced that there is something important I haven't considered. At a high level, why does TRILL we need extensions and options (at the trill header level) in the first place? Looking at draft-ietf-trill-rbridge-options-06.txt, for example, I don't see anything defined that seems particularly useful or necessary. That is, the proposed options either seem to be like not really necessary, or there are alternate ways of achieving equivalent functionality that don't require the use of extensions (which would require changes in the implementation of the forwarding processing). Indeed, it almost seems like the extensibility mechanism is a solution in search of a problem. Second, I feel like draft-ietf-trill-rbridge-extension-02.txt has a lot of things in it that have been proposed "just in case they might be useful". But for which (again) I'm not aware of any compelling possible use. And having watched the various attempts to define new IPv4 options (or make use of even the existing ones) with similiar issues coming up w.r.t. IPv6 option processing, I've become increasingly skeptical with the approaches that have been proposed for allowing for possible future extensions can be made to work in practice. It just turns out (for many reasons) to be very hard to deploy new functionality. Without a compelling "must have" feature, I don't see vendors ever implementing TRILL options/extensions. And even if they did, they would certainly do so in the "slow path" initially (just like in IPv4/IPv6), which severely limits the utility (and deployability) of such extensions. I fear that these extensions will never be implemented in practice, because they'll never be able to get past the chicken-and-egg problem. Do we *really* need to define options and extensions in Trill? Does anyone think they will ever be implemented? The main argument I can see in favor of defining extensions now is so that folk can implement: 1) the checking of the critical bits 2) being able to skip over unknown extensions in the future, should any ever be defined. But is that enough, and will today's implementations bother to do so? (The one implementation I am familiar with cannot). But even with the above motivation I'm skeptical we will see even the simple steps outlined above happening in actual implementations. The issue goes beyond just skipping extension header on egress, transit RBs doing ECMP will also need to skip the extension headers too, in order to peek into the IP header fields. As will those doing pruning of multicast trees. But will implementations bother to do so? I have real doubts. In terms of OAM (and the Channel draft), the channel draft currently has a normative dependency on the extensions draft. This is for examination of the critical "rbridge channel alert" flag is set. But I think that normative dependency can be removed. My current thinking is that the "Rbridge Channel Alert" flag does not need to exist at all, as this is again a solution in search of a problem. Thoughts? Thomas _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge From rbridge-bounces@postel.org Tue Feb 21 10:50:58 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 91BFE21F88CD for ; Tue, 21 Feb 2012 10:50:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.524 X-Spam-Level: X-Spam-Status: No, score=-4.524 tagged_above=-999 required=5 tests=[AWL=2.075, 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 n-75PHMuVVCL for ; Tue, 21 Feb 2012 10:50:53 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id EB6FE21F8866 for ; Tue, 21 Feb 2012 10:50:50 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1LIW6KJ015242; Tue, 21 Feb 2012 10:32:07 -0800 (PST) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1LIUraV015060 for ; Tue, 21 Feb 2012 10:31:03 -0800 (PST) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id ADT97186; Tue, 21 Feb 2012 13:30:52 -0500 (EST) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 21 Feb 2012 10:30:39 -0800 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Tue, 21 Feb 2012 10:30:01 -0800 From: Linda Dunbar To: Jon Hudson Thread-Topic: [rbridge] I-D Action: draft-ietf-trill-rbridge-extension-02.txt Thread-Index: AQHM8EY6xcK1uIYSaUGQrHU8zFHt2JZHrSXg Date: Tue, 21 Feb 2012 18:30:01 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F632E216B8@dfweml505-mbx> References: <20120109132058.9151.5560.idtracker@ietfa.amsl.com> 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.97] MIME-Version: 1.0 X-CFilter-Loop: Reflected X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: linda.dunbar@huawei.com X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id q1LIUraV015060 Cc: "rbridge@postel.org" Subject: Re: [rbridge] I-D Action: draft-ietf-trill-rbridge-extension-02.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 Support. = Linda Dunbar > = > On Sat, Feb 18, 2012 at 12:25 AM, Jon Hudson > wrote: > > I have read this and support the document. > > > > Very sorry for missing the 15th deadline, I have been ofline. > > > > On Mon, Jan 9, 2012 at 8:18 PM, Donald Eastlake > wrote: > >> > >> This version incorporates change discussed on the WG mailing 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, Jan 9, 2012 at 8:20 AM, =A0 wrote: > >> > > >> > 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. > >> > > >> > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : TRILL: Header Extension > >> > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Donald Eastlake > >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Anoop Ghanwani > >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Vishwas Manral > >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Yizhou Li > >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Caitlin Bestler > >> > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-trill-rbridge-ex= tension-02.txt > >> > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 16 > >> > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-01-09 > >> > > >> > =A0 The IETF TRILL (Transparent Interconnection of Lots of Links) > base > >> > =A0 protocol specifies minimal hooks to safely support TRILL Header > >> > =A0 extensions. This document specifies an initial extension > providing > >> > =A0 additional flag bits and specifies two of those bits. > >> > > >> > > >> > > >> > A URL for this Internet-Draft is: > >> > > >> > http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge- > extension-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-rbridge- > extension-02.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 > > > = > _______________________________________________ > 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 Feb 22 20:18:06 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 1A89421E8013 for ; Wed, 22 Feb 2012 20:18:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.231 X-Spam-Level: X-Spam-Status: No, score=-6.231 tagged_above=-999 required=5 tests=[AWL=0.368, 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 IrrhIrDcrihx for ; Wed, 22 Feb 2012 20:18:05 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 13CBD21E801B for ; Wed, 22 Feb 2012 20:18:03 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1N3uJ9d025916; Wed, 22 Feb 2012 19:56:19 -0800 (PST) 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 q1N3tkac025879 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 22 Feb 2012 19:55:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tsenevir@cisco.com; l=1532; q=dns/txt; s=iport; t=1329969355; x=1331178955; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=7cUvxJiuLnbMNHl36Gku6ATk/RDjxJ+fobYIG4oafCs=; b=YlXkvJqFnep3XNjcRWKuEFpi9uDFOjFtfjWvKOvcfg8eyfzUjHdmSn0/ BWZeKJDd2fg0+0nQgKPHkQLnQo9mj6wVzDvdrZwPFLVH/bf3AtG/RJvOG +8KIhL9QwJ+8aie4fl9v+AkJpPyQ73AE0YPY8tUyNBtH5PtXOe+D3nS3B 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAMe3RU+rRDoH/2dsb2JhbABEhTSsL3mBB4F1AQQSARANBFcBIgIGBhgCAgMBVgEEGxqmJIEnAYxliieBL4tQBRUaRBEFAwKETAFeBwQEAgMFAwQBUoIIM2MEiE+fdw X-IronPort-AV: E=Sophos;i="4.73,468,1325462400"; d="scan'208";a="31782881" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 23 Feb 2012 03:55:46 +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 q1N3tkCL008367 for ; Thu, 23 Feb 2012 03:55:46 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); Wed, 22 Feb 2012 19:55:46 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 22 Feb 2012 19:55:45 -0800 Message-ID: <344037D7CFEFE84E97E9CC1F56C5F4A5A45E88@xmb-sjc-214.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.txt Thread-Index: Aczwwgvgbt2qI1nfQfiYK8zrqzIBUABHHNaQ From: "Tissa Senevirathne (tsenevir)" To: X-OriginalArrivalTime: 23 Feb 2012 03:55:46.0623 (UTC) FILETIME=[05EB9CF0:01CCF1DF] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: tsenevir@cisco.com X-MIME-Autoconverted: from base64 to 8bit by boreas.isi.edu id q1N3tkac025879 Subject: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.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 Dear All We have submitted draft-tissa-trill-multilevel, present multilevel TRILL based on default nickname approach. Additionally we discuss construction of multi-destination trees and related RPF in multilevel TRILL. Please could you review and comment Detail of the draft and abstract are below. Filename: draft-tissa-trill-multilevel Revision: 00 Title: Default Nickname Based Approach for Multilevel TRILL Creation date: 2012-02-21 WG ID: Individual Submission Number of pages: 26 Abstract: Multilevel TRILL allows the interconnection of multiple TRILL networks to form a larger TRILL network without proportionally increasing the size of the IS-IS LSP DB. In this document, an approach based on default route concept is presented. Also, presented in the document is a novel method of constructing multi- destination trees using partial nickname space. Methods presented in this document are compatible with the RFC6325 specified data plane operations. Thanks Tissa _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge From rbridge-bounces@postel.org Thu Feb 23 12:27:00 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 DB8ED21F8889 for ; Thu, 23 Feb 2012 12:27:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.776 X-Spam-Level: X-Spam-Status: No, score=-105.776 tagged_above=-999 required=5 tests=[AWL=0.823, 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 IbEwr3PodATB for ; Thu, 23 Feb 2012 12:26:59 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id B958421F8888 for ; Thu, 23 Feb 2012 12:26:59 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1NK3E4I026688; Thu, 23 Feb 2012 12:03:17 -0800 (PST) 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 q1NK2dao026592 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 23 Feb 2012 12:02:49 -0800 (PST) Received: by lagy4 with SMTP id y4so3255498lag.39 for ; Thu, 23 Feb 2012 12:02:38 -0800 (PST) Received-SPF: pass (google.com: domain of d3e3e3@gmail.com designates 10.152.125.20 as permitted sender) client-ip=10.152.125.20; Authentication-Results: mr.google.com; spf=pass (google.com: domain of d3e3e3@gmail.com designates 10.152.125.20 as permitted sender) smtp.mail=d3e3e3@gmail.com; dkim=pass header.i=d3e3e3@gmail.com Received: from mr.google.com ([10.152.125.20]) by 10.152.125.20 with SMTP id mm20mr2363347lab.6.1330027358378 (num_hops = 1); Thu, 23 Feb 2012 12:02:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=xE2UC1hxZ46tG4i2dkpaiH/ccogRpsQL9MSIOYcJYZA=; b=ScWTZCjdbMArI6WvoRG48Bg1krnqzrfmczT7Zgpvgizctq61X/AffMPFQ7Bj6x+MNB r8D8yJvgO99Xk3vkWZWsdXH6zPXVrjgTSxbClg//SrZm7gymgYOhsKOWQLvz8fRBkCWT yQ+Atu0ESaysnBkeNuDdLmHN9+ZWkpyF52bic= Received: by 10.152.125.20 with SMTP id mm20mr1998285lab.6.1330027358261; Thu, 23 Feb 2012 12:02:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.80.234 with HTTP; Thu, 23 Feb 2012 12:02:18 -0800 (PST) In-Reply-To: <201202211422.q1LEMDin024613@cichlid.raleigh.ibm.com> References: <201202211422.q1LEMDin024613@cichlid.raleigh.ibm.com> From: Donald Eastlake Date: Thu, 23 Feb 2012 15:02:18 -0500 Message-ID: To: Thomas Narten 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 q1NK2dao026592 Cc: rbridge@postel.org Subject: Re: [rbridge] Trill Extensions and options 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 Thomas, On Tue, Feb 21, 2012 at 9:22 AM, Thomas Narten wrote: > There are a number of WG LC's going on at the moment, including > rbridge-extension. I've also been reviewing and thinking about the > entire set and looking at OAM approaches as well. You seem to be looking considerably beyond the Extension draft currently in WGLC. Primarily, the Extension draft provides more flag bits and some ground rules. > At this point, I guess I have to say am unsold on the need for the > extensions document and options at all. I'm raising this issue from > the perspective of wanting to be convinced that there is something > important I haven't considered. The Options draft is not being proposed for advancement. The Extension draft, which is in WGLC, mostly provides more detail on facilities that are there in RFC 6325, which already provides that the first word of the extension area is special. I wouldn't mind removing from the Extension draft the two very minor passing references to the possibility of the future specification of TLV options. > At a high level, why does TRILL we need extensions and options (at the > trill header level) in the first place? > > Looking at draft-ietf-trill-rbridge-options-06.txt, for example, I > don't see anything defined that seems particularly useful or > necessary. ... It seems pretty remarkable to me that you can determine that there is nothing useful in ietf-trill-rbridge-options or in eastlake-trill-rbridge-more-options or in anything else that someone might think of in the future. Even if that were true, it isn't want's being last called. What's being last called is more header flags. > Second, I feel like draft-ietf-trill-rbridge-extension-02.txt has a > lot of things in it that have been proposed "just in case they might > be useful". ... I don't think there is a "lot" of anything in the Extension draft. The concrete content of the Extension draft is just to take the rest of the bits in the first 32-bit word of the extension area (a word provided for and whose top two bits are specified in RFC 6325), specify the type of the remaining bits in that word as extended header flags, and specify the actually use of two of those bits. > Without a compelling "must have" feature, I don't see vendors ever > implementing TRILL options/extensions. ... The functionality of the two particular extended header flags specified in the Extension draft are, as far as I know, supported by all existing TRILL silicon. To repeat, the Options draft is not currently being proposed for advancement. > The main argument I can see in favor of defining extensions now is so > that folk can implement: > > 1) the checking of the critical bits > 2) being able to =A0skip over unknown extensions in the future, should > =A0 any ever be defined. I agree that 1 is an significant argument but on your 2, I would say it is more to be able to do things like tunnel some known information from ingress to egress, or the like, not necessarily that that information be "unknown". > But is that enough, and will today's implementations bother to do so? > (The one implementation I am familiar with cannot). I can't guarantee anything but I would say that if the Extension draft is not adopted, its content is unlikely to be implemented :-) > But even with the above motivation I'm skeptical we will see even the > simple steps outlined above happening in actual implementations. > ... skipping extension header ... > But will implementations bother to do so? =A0I have real doubts. > > In terms of OAM (and the Channel draft), the channel draft currently > has a normative dependency on the extensions draft. This is for > examination of the critical "rbridge channel alert" flag is set. =A0But > I think that normative dependency can be removed. My current thinking > is that the "Rbridge Channel Alert" flag does not need to exist at > all, as this is again a solution in search of a problem. One person's "solution in search of a problem" is another person's simple foundation facilities that should be specified early so they at least have a chance of being available later if needed. Although specific concrete example uses are given for the channel Alert flags, I can't guarantee they will actually be used in the future. But since their functionality is supported by all existing silicon I know about and the cost of supporting the Alert flags, for an RBridge that supports the channel feature at all, would be very low, I believe they should be specified and the Extension draft should advance. 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 > Thoughts? > > Thomas _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge From rbridge-bounces@postel.org Thu Feb 23 15:37:36 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 8A72121E8025 for ; Thu, 23 Feb 2012 15:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.483 X-Spam-Level: X-Spam-Status: No, score=-107.483 tagged_above=-999 required=5 tests=[AWL=-0.884, 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 m6Jt3OUSyzs0 for ; Thu, 23 Feb 2012 15:37:35 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2241121F86B6 for ; Thu, 23 Feb 2012 15:37:35 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1NNIMMw029143; Thu, 23 Feb 2012 15:18:23 -0800 (PST) Received: from e39.co.us.ibm.com (e39.co.us.ibm.com [32.97.110.160]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1NNI2bA029116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 23 Feb 2012 15:18:11 -0800 (PST) Received: from /spool/local by e39.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 23 Feb 2012 16:18:00 -0700 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; Thu, 23 Feb 2012 16:16:54 -0700 Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id D3DEDC90055 for ; Thu, 23 Feb 2012 18:16:53 -0500 (EST) Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q1NNGrDL3596428 for ; Thu, 23 Feb 2012 18:16:53 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q1NNGrn1002932 for ; Thu, 23 Feb 2012 18:16:53 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-206-5.mts.ibm.com [9.65.206.5]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q1NNGqBi002888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Feb 2012 18:16:52 -0500 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 q1NNG7qK004098; Thu, 23 Feb 2012 18:16:07 -0500 Message-Id: <201202232316.q1NNG7qK004098@cichlid.raleigh.ibm.com> To: Erik Nordmark In-reply-to: <4F299302.3000804@acm.org> References: <4F299302.3000804@acm.org> Comments: In-reply-to Erik Nordmark message dated "Wed, 01 Feb 2012 11:31:14 -0800." Date: Thu, 23 Feb 2012 18:16:06 -0500 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12022323-4242-0000-0000-000000DBEC6A X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: narten@us.ibm.com Cc: "rbridge@postel.org" Subject: Re: [rbridge] WG last call of draft-ietf-trill-rbridge-extension-02 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org Here are my comments on this document. Note that I've also read a number of related documents, in order to understand how they all fit together. Summary 1) I do not think we need this document at this time. It defines a bunch of (IMO) speculative uses for which it is not clear we have a compelling use case (yet). My overall IETF experience has led me to be very wary of trying to design for future functionality without a clear use case. I think we should wait on specifying the details of the extension word until we have such a use case (e.g., drafts that are ready to publish that depend on the functionality in trill-rbridge-extension). That is, just leave the bits "reserved" for now and do not specify them further. Does anyone think this document will be implemented anytime soon? I would argue there is little reason to do so (given no compelling use case), so implementations most likely won't. 2) It seems to me that the critical definitions are already in the base Trill specification, namely that the first 2 bits of the extensions header are for critical HbH or critical Ingress to Egress options. Until there are some specific critical options defined, there is no need to define the remaining bits in the extension word. By defining them now, we run the risk of getting them wrong, and we may later conclude that we made poor use of them. 3) The one new bit in the extensions draft that is potentially important is the Channel Alert bit. IMO, this bit is unnecessary and should be dropped. We already have a critical HbH bit, which does mostly (if not entirely) the same thing. Moreover, I think that having hop-by-hop channel protocols is a dubious idea. Without a concrete proposal for one, where the WG has agreement that there is no better way to solve the problem than to have a channel-specific HbH bit, we should not define one. 4) I've also been looking at the OAM in draft-ietf-trill-rbridge-oam-01.txt, and I do not see any need for OAM to have a special hop-by-hop processing (in any case trill-rbridge-oam does not call for use of hop-by-hop processing). There are other ways of achieving the necessary functionality. Arguably, the alternatives are to be preferred if for no other reason than they keep the core data plan processsing simple. My recommendation: 1) table this document for now, it is not needed. 2) in the channel draft, remove the normative depedency to this document. (The channel document should go forward.) That said, if the WG believes this document should go forward anyway, I'd like to suggest that it be published as experimental rather than on standards track. When and if there is a concrete usage for the extended functionality, we could move it to standards track (possibly with modifications) as appropriate. I have some other comments on the document itself, if it goes forward. My main comment concerns Section 2.4. I think it should be deleted entirely. We should just not allow the definition of conflicting options. Or if we do, we should say mutually incompatable options MUST NOT be used together at the same time. If someone ends up generating Trill packets with conflicting options, let the behavior be undefined. Looking at Section 2.4, it seems that implementations may end up having to do a lot of work to adhere to the rules -- and for what ends? We should just strongly discourage the use of conflicting extensions, and when they happen, buyer beware. We should not complicate implementations to handle cases that really shouldn't be allowed to happen. That is IMO a bad tradeoff. Alternatively, if we ever decide we need to define a conflicting extension, that is the time to define how to handle the two when they occur together. We may find that the proposed rules in Section 2.4 end up being wrong for those specific options anyway, in which case we find ourselves in a bind. Thomas _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge From rbridge-bounces@postel.org Thu Feb 23 17:37:49 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 BFF6C21E802C for ; Thu, 23 Feb 2012 17:37:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.462 X-Spam-Level: X-Spam-Status: No, score=-107.462 tagged_above=-999 required=5 tests=[AWL=-0.863, 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 g1lDnU+daNym for ; Thu, 23 Feb 2012 17:37:48 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id D5BFF21F85F9 for ; Thu, 23 Feb 2012 17:37:48 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1O1NMe6019416; Thu, 23 Feb 2012 17:23:23 -0800 (PST) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1O1MxEN019378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 23 Feb 2012 17:23:08 -0800 (PST) Received: from /spool/local by e6.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 23 Feb 2012 20:22:55 -0500 Received: from d01dlp02.pok.ibm.com (9.56.224.85) by e6.ny.us.ibm.com (192.168.1.106) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 23 Feb 2012 20:22:03 -0500 Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 702F76E804A for ; Thu, 23 Feb 2012 20:22:02 -0500 (EST) Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q1O1M2rK3588340 for ; Thu, 23 Feb 2012 20:22:02 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q1O1M0vG002332 for ; Thu, 23 Feb 2012 20:22:02 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-206-5.mts.ibm.com [9.65.206.5]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q1O1LxrB002218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Feb 2012 20:21:59 -0500 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 q1O1LJ5L004767; Thu, 23 Feb 2012 20:21:19 -0500 Message-Id: <201202240121.q1O1LJ5L004767@cichlid.raleigh.ibm.com> To: Erik Nordmark In-reply-to: <4F299636.7060604@acm.org> References: <4F299636.7060604@acm.org> Comments: In-reply-to Erik Nordmark message dated "Wed, 01 Feb 2012 11:44:54 -0800." Date: Thu, 23 Feb 2012 20:21:18 -0500 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12022401-1976-0000-0000-00000ADFAEDE X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: narten@us.ibm.com Cc: "rbridge@postel.org" Subject: Re: [rbridge] WG last call on draft-ietf-trill-rbridge-bfd-02 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org Overall, I support this document. It does need a respin to clean up what appear to be straightforward editing issues. Thomas Document probably should have a reference to core BFD RFCs earlier in the document than it does (e.g., first use). there is work in the area. The Rbridge Channel facility is specified in [TRILLoam]. s/TRILLoam/CHANNELoam/ it and TRILL data plaen layer OAM, such as TRILL BFD, is beyond the s/plaen/plane/ TRILL BFD Control frames are unicast TRILL Rbridge Message Channel frames [TRILLChannel]. The Rbridge Channel Protocol value is given in Section 10. There is no such term as "TRILL Rbridge Message Channel frames". I think you want to just say "Trill Rbridge Channel frames" (i.e., drop "Message"). Multiple occurances throughout document. A TRILL BFD Echo frame is a unicast TRILL OAM Message Channel frame, Drop "OAM"? Indeed, the entire document needs a pass to remove references to "OAM" that are no longer valid. BFD is now just part of the channel draft. A TRILL BFD Echo frame is a unicast TRILL OAM Message Channel frame, as specified in [TRILLoam], which should be forwarded back by an Drop "OAM" from above. Also, drop "Message", as that isn't the proper term (I think). Better: A TRILL BFD Echo frame is a unicast TRILL Channel frame as specified in [TRILLoam] with a Channel Protocol value of "BFD Echo". Such packets should be forwarded back ... Need a reference in references section to TRILLoam document TRILL BFD Echo frames SHOULD only be sent on a link if A TRILL BFD Control session has been established, Format problem above. Truncated sentence? TRILL BFD Echo support is indicated by the potentially echo responding RBridge. This sentence reads awkward. The adjacency is in the Report state [RFC6327], and Truncated sentence again? It is required that the operator of an RBridge campus configure the rates at which TRILL BFD frames are transmitted on a link to avoid congestion (e.g., link, I/O, CPU) and false failure detection. Don't like the "required" wording. Better to say something like "it is up to the operator to ..." IANA is request to allocate two TRILL OAM Protocol numbers from the range allocated by Standards Actions, as follows: Change wording of "OAM Protocol numbers"? _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge From rbridge-bounces@postel.org Thu Feb 23 22:21:02 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 3C52021F8863 for ; Thu, 23 Feb 2012 22:21:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.635 X-Spam-Level: X-Spam-Status: No, score=-101.635 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] 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 UYaoHvn--ynk for ; Thu, 23 Feb 2012 22:21:01 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id EF7A421F8850 for ; Thu, 23 Feb 2012 22:21:00 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1O640rs027302; Thu, 23 Feb 2012 22:04:02 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1O63bpT027283; Thu, 23 Feb 2012 22:03:47 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 523732371461274; Fri, 24 Feb 2012 13:56:37 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 60473.2865015372; Fri, 24 Feb 2012 14:03:08 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q1O63GHZ028610; Fri, 24 Feb 2012 14:03:16 +0800 (GMT-8) (envelope-from hu.fangwei@zte.com.cn) In-Reply-To: <344037D7CFEFE84E97E9CC1F56C5F4A5A45E88@xmb-sjc-214.amer.cisco.com> To: "Tissa Senevirathne (tsenevir)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.4 June 01, 2004 Message-ID: From: hu.fangwei@zte.com.cn Date: Fri, 24 Feb 2012 14:03:10 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-02-24 14:03:18, Serialize complete at 2012-02-24 14:03:18 X-MAIL: mse01.zte.com.cn q1O63GHZ028610 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: hu.fangwei@zte.com.cn Cc: rbridge@postel.org, rbridge-bounces@postel.org Subject: Re: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.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: multipart/mixed; boundary="===============1545242784==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org This is a multipart message in MIME format. --===============1545242784== Content-Type: multipart/alternative; boundary="=_alternative 0021414B482579AE_=" This is a multipart message in MIME format. --=_alternative 0021414B482579AE_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksIFRpc3NhLg0KDQpJIGhhdmUgc2V2ZXJhbCBjb21tZW50cyBhYm91dCB0aGUgZHJhZnQuDQoN CigxKSBpbiBzZWN0aW9uIDQuNCAoTXVsdGljYXN0KSwgIlRoZSBzY29wZSBvZiBnbG9iYWwgdHJh ZmZpYyBtYXkgYmUgDQppZGVudGlmaWVkIGVpdGhlciB0aHJvdWdoIFZMQU4gb3IgdmlhIGZpbmVn cmFpbiANCmxhYmVsIHRoYXQgc3BhbnMgYWNyb3NzIHRoZSBlbnRpcmUgVFJJTEwgY2FtcHVzLiIN ClZsYW4gYW5kIEZpbmUtZ3JhaW4gTGFiZWwgaXMgdXNlZCBmb3Igc2VydmljZSBkaWZmZXJlbnRp YXRpb24gYW5kIA0KaXNvbGF0aW9uLiBJIGRvIG5vdCBxdWl0ZSB1bmRlcnN0YW5kIHRoYXQgaG93 IHRvDQp1c2UgVkxBTiBhbmQgZmluZS1ncmFpbiBMYWJsZSB0byBpZGVudGlmeSB0aGUgdHJhZmZp YyBzY29wZS4gVGhlIGRhdGEgDQp0cmFmZmljIHdpdGggYSBnaXZlbiBWTEFOLXgsIGNhbiANCmJl IGZvcndhcmRlZCB0byBvdGhlciBlbmQgc3RhdGlvbiBpbiB0aGUgbG9jYWwgYXJlYSwgb3IgdG8g dGhlIGVuZCBzdGF0aW9uIA0KaW4gcmVtb3RlIGFyZWFzLiANCg0KKDIpIG5pY2tuYW1lIGFsbG9j YXRpb24NClRoZSBuaWNrbmFtZSBtYW5hZ2VtZW50IHN1Yi1UTFYgaXMgcHJvcG9zZWQgaW4gdGhl IGRvY3VtZW50LiBJIHdvbmRlciB0aGlzIA0KbWVjaGFuaXNtIGFkZHMgdGhlIGNvbXBsaWNhdGlv biBvZiANCm5pY2tuYW1lIGFsbG9jYXRpb24uIEFzIHRoZSBzZWN0aW9uIDEgKGludHJvZHVjdGlv bikgb2YgUkZDNjMyNSwgb25lIG9mIA0KdGhlIGltcG9ydGFudCBhZHZhbnRhZ2Ugb2YgVFJJTEwg aXMgdGhhdCANCml0IGF2b2lkcyB0aGUgY3JlYXRpbmcgc3VibmV0cyBvZiBJUCBhZGRyZXNzIGFu ZCB3YXN0aW5nIGFkZHJlc3MuIFRoZSANCm5pY2tuYW1lIGFjcXVpc2l0aW9uICBtZXRob2QgaW4g dGhpcyBkcmFmdCB2aW9sYXRlcyB0aGUgDQppZGVhIG9mIFRSSUxMIEJhc2ljIHNwZWNpZmljYXRp b24sIGFuZCByZWR1Y2VzIHRoZSBmbGV4aWJpbGl0eSBvZiBuaWNrbmFtZSANCmFsbG9jYXRpb24u IEFzIHRoZSBkcmFmdCBhc3N1bWVkLCBBMSBoYWQgDQpuaWNrbmFtZSByYW5nZSBvZiAxMDAtMjAw LCBBMiBoYXMgYSBsb2NhbCBuaWNrbmFtZSByYW5nZSBvZiAyMDEtMzAwLiBJZiANCnRoZSBudW1i ZXJzIG9mIEExIGFyZWEgaXMgb25seSA1MCwgc28gNTAgDQpuaWNrbmFtZXMgaW4gQTEgaXMgd2Fz dGVkLiBBcyB0aGUgbmV0d29yayBncm93aW5nLCB0aGUgbnVtYmVyIG9mIHNvbWUgDQphcmVhcyBt YXkgZXhjZWVkIHRoZSBudW1iZXIgYmVpbmcgYWxsb2NhdGlvbiANCmJ5IEJvcmRlciBSQnJpZGdl cy4gVGhlIGRlc2lnbiBhbmQgbWFpbnRhaW5pbmcgb2Ygbmlja25hbWUgcmFuZ2VzIGZvciBlYWNo IA0KYXJlYSBpcyBhIHZlcnkgaGFyZCB3b3JrLiBFdmVuIHdvcnN0LCBpdCANCmNhbiBub3QgYXZv aWQgdG8gd2FzdGUgbmlja25hbWUgc3BhY2UuDQoNCigzKSBEeW5hbWljIHJhbmdlcyANCiBUaGUg bmlja25hbWUgcmFuZ2UgaXMgZGl2aWRlZCBpbnRvIHR3byByYW5nZTogbG9jYWwgcmFuZ2UgYW5k IGR5bmFtaWNhbCANCnJhbmdlLiBJIHdvbmRlciB0aGUgbmlja25hbWUgY29uZmxpY3QgDQpyZXNv bHV0aW9uIGNhbiBub3Qgd29yayBpZiB0aGUgUkJyaWRnZSBnZXQgdGhlIG5pY2tuYW1lIGZyb20g dGhlIGR5bmFtaWNhbCANCnJhbmdlIHdoaWxlIHRoZSB0d28gUkJyaWRnZSBiZWxvbmdzIHRvIA0K ZGlmZmVyZW50IGFyZWFzLiBGb3IgZXhhbXBsZSwgUkIxIGlzIGluIGFyZWEgQTEsIGFuZCBSQjIg aXMgaW4gYXJlYSBBMi4gSWYgDQpSQjEgZ2V0cyB0aGUgbmlja25hbWUgTjEgZnJvbSBkeW5hbWlj IA0KcmFuZ2UsIGFuZCBpdCB3aWxsIGZsb29kcyBpbiBhcmVhIEExLCBhbmQgb3RoZXIgUkJyaWRn ZXMgaW4gYXJlYSBBMSBjYW4gDQpub3QgZ2V0IG5pY2tuYW1lIE4xIGJlY2F1c2Ugb2Ygbmlja25h bWUgDQpjb25mbGljdGlvbiBtZWNoYW5pc20sIGJ1dCBSQjIgaW4gYXJlYSBBMiBjYW4gbm90IHJl Y2VpdmUgdGhlIFBEVSBmcm9tIA0KUkIxLCBhbmQgaXQgIGNhbiBhbHNvIGdldCB0aGUgbmlja25h bWUgTjEgZnJvbSANCmR5bmFtaWNhbCByYW5nZS4gU28gdGhlIHF1ZXN0aW9uIGlzIGhvdyB0byBh dm9pZCB0aGUgZHVwbGljYXRpb24gZHluYW1pY2FsIA0KcmFuZ2Ugbmlja25hbWUgZm9yIGRpZmZl cmVudCBhcmVhcy4NCg0KKDQpIFRoZSByaXNrIG9mIHJ1bm5pbmcgb3V0IG9mIG5pY2tuYW1lIG1h eWJlIGEgaXNzdWUgZm9yIFRSSUxMLiBUaGUgDQpudW1iZXIgb2YgMioqMTYgbmlja25hbWUgaXMg ZW5vdWdoIGZvciB0aGUgY3VycmVudCBkYXRhIGNlbnRlciwNCiBidXQgaXQgbWF5YmUgbm90IGVu b3VnaCBpbiB0aGUgZnV0dXJlLCBlc3BlY2FpbGx5IGlmIFRSSUxMIG92ZXIgSVAgLCANClRSSUxM IG92ZXIgTVBMUyB0ZWNobm9sb2d5IG9yIHNvbWUgb3RoZXIgZGF0YSBjZW50ZXIgdGVjaG5vbG9n aWVzDQogYXJlIGRlcGxveWVkLCB0aGUgZGF0YSBjZW50ZXIgbmV0d29yayBjYW4gYmUgYSB2ZXJ5 IGxhcmRnZSBuZXR3b3JrLiBTbyBpIA0KdGhpbmsgdGhlIHZlcnkgaW1wb3J0YW50IGFuZCBlc3Nl bnRpYWwgZ29hbCBvZiBtdWx0aS1sZXZlbCBkcmFmdCBpcyB0byANCnNhdmUgbmlja25hbWVzLg0K DQpCZXN0IHJlZ2FyZHMNCkZhbmd3ZWkgSHUNCg0KDQoNCg0KIlRpc3NhIFNlbmV2aXJhdGhuZSAo dHNlbmV2aXIpIiA8dHNlbmV2aXJAY2lzY28uY29tPiANCreivP7IyzogIHJicmlkZ2UtYm91bmNl c0Bwb3N0ZWwub3JnDQoyMDEyLTAyLTIzIDExOjU1DQoNCsrVvP7Iyw0KPHJicmlkZ2VAcG9zdGVs Lm9yZz4NCrOty80NCg0K1vfM4g0KW3JicmlkZ2VdIERlZmF1bHQgbmlja25hbWUgYmFzZSBhcHBy b2FjaCBmb3IgbXVsdGlsZXZlbCBUUklMTC0gDQpkcmFmdC10aXNzYS10cmlsbC1tdWx0aWxldmVs LTAwLnR4dA0KDQoNCg0KDQoNCg0KRGVhciBBbGwNCg0KV2UgaGF2ZSBzdWJtaXR0ZWQgZHJhZnQt dGlzc2EtdHJpbGwtbXVsdGlsZXZlbCwgcHJlc2VudCBtdWx0aWxldmVsIFRSSUxMIA0KYmFzZWQg b24gZGVmYXVsdCBuaWNrbmFtZSBhcHByb2FjaC4gQWRkaXRpb25hbGx5IHdlIGRpc2N1c3MgY29u c3RydWN0aW9uIA0Kb2YgbXVsdGktZGVzdGluYXRpb24gdHJlZXMgYW5kIHJlbGF0ZWQgUlBGIGlu IG11bHRpbGV2ZWwgVFJJTEwuIFBsZWFzZSANCmNvdWxkIHlvdSByZXZpZXcgYW5kIGNvbW1lbnQg DQoNCkRldGFpbCBvZiB0aGUgZHJhZnQgYW5kIGFic3RyYWN0IGFyZSBiZWxvdy4NCg0KRmlsZW5h bWU6ICAgICAgICAgICAgICAgICBkcmFmdC10aXNzYS10cmlsbC1tdWx0aWxldmVsDQpSZXZpc2lv bjogICAgICAgICAgICAgICAgIDAwDQpUaXRsZTogICAgICAgICAgICAgICAgICAgICAgICAgICAg RGVmYXVsdCBOaWNrbmFtZSBCYXNlZCBBcHByb2FjaCBmb3IgDQpNdWx0aWxldmVsIFRSSUxMDQpD cmVhdGlvbiBkYXRlOiAgICAgICAgICAgIDIwMTItMDItMjENCldHIElEOiAgICAgICAgICAgICAg ICAgICAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogMjYN Cg0KQWJzdHJhY3Q6DQogICBNdWx0aWxldmVsIFRSSUxMIGFsbG93cyB0aGUgaW50ZXJjb25uZWN0 aW9uIG9mIG11bHRpcGxlIFRSSUxMDQogICBuZXR3b3JrcyB0byBmb3JtIGEgbGFyZ2VyIFRSSUxM IG5ldHdvcmsgd2l0aG91dCBwcm9wb3J0aW9uYWxseQ0KICAgaW5jcmVhc2luZyB0aGUgc2l6ZSBv ZiB0aGUgSVMtSVMgTFNQIERCLiBJbiB0aGlzIGRvY3VtZW50LCBhbg0KICAgYXBwcm9hY2ggYmFz ZWQgb24gZGVmYXVsdCByb3V0ZSBjb25jZXB0IGlzIHByZXNlbnRlZC4gQWxzbywNCiAgIHByZXNl bnRlZCBpbiB0aGUgZG9jdW1lbnQgaXMgYSBub3ZlbCBtZXRob2Qgb2YgY29uc3RydWN0aW5nIG11 bHRpLQ0KICAgZGVzdGluYXRpb24gdHJlZXMgdXNpbmcgcGFydGlhbCBuaWNrbmFtZSBzcGFjZS4g TWV0aG9kcyBwcmVzZW50ZWQgaW4NCiAgIHRoaXMgZG9jdW1lbnQgYXJlIGNvbXBhdGlibGUgd2l0 aCB0aGUgUkZDNjMyNSBzcGVjaWZpZWQgZGF0YSBwbGFuZQ0KICAgb3BlcmF0aW9ucy4NCg0KICAN ClRoYW5rcw0KVGlzc2ENCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCnJicmlkZ2UgbWFpbGluZyBsaXN0DQpyYnJpZGdlQHBvc3RlbC5vcmcNCmh0dHA6 Ly9tYWlsbWFuLnBvc3RlbC5vcmcvbWFpbG1hbi9saXN0aW5mby9yYnJpZGdlDQoNCg0KDQo= --=_alternative 0021414B482579AE_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLCBUaXNzYS48L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgaGF2ZSBzZXZlcmFsIGNv bW1lbnRzIGFib3V0IHRoZSBkcmFmdC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPigxKSBpbiBzZWN0aW9uIDQuNCAoTXVsdGljYXN0KSwgJnF1b3Q7VGhl DQpzY29wZSBvZiBnbG9iYWwgdHJhZmZpYyBtYXkgYmUgaWRlbnRpZmllZCBlaXRoZXIgdGhyb3Vn aCBWTEFOIG9yIHZpYSBmaW5lZ3JhaW4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+bGFiZWwgdGhhdCBzcGFucyBhY3Jvc3MgdGhlIGVudGlyZSBUUklMTA0KY2Ft cHVzLiZxdW90OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Vmxh biBhbmQgRmluZS1ncmFpbiBMYWJlbCBpcyB1c2VkIGZvcg0Kc2VydmljZSBkaWZmZXJlbnRpYXRp b24gYW5kIGlzb2xhdGlvbi4gSSBkbyBub3QgcXVpdGUgdW5kZXJzdGFuZCB0aGF0IGhvdw0KdG88 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnVzZSBWTEFOIGFuZCBm aW5lLWdyYWluIExhYmxlIHRvIGlkZW50aWZ5DQp0aGUgdHJhZmZpYyBzY29wZS4gVGhlIGRhdGEg dHJhZmZpYyB3aXRoIGEgZ2l2ZW4gVkxBTi14LCBjYW4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj5iZSBmb3J3YXJkZWQgdG8gb3RoZXIgZW5kIHN0YXRpb24gaW4N CnRoZSBsb2NhbCBhcmVhLCBvciB0byB0aGUgZW5kIHN0YXRpb24gaW4gcmVtb3RlIGFyZWFzLiA8 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPigyKSBuaWNr bmFtZSBhbGxvY2F0aW9uPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij5UaGUgbmlja25hbWUgbWFuYWdlbWVudCBzdWItVExWIGlzIHByb3Bvc2VkDQppbiB0aGUgZG9j dW1lbnQuIEkgd29uZGVyIHRoaXMgbWVjaGFuaXNtIGFkZHMgdGhlIGNvbXBsaWNhdGlvbiBvZiAm bmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPm5pY2tuYW1l IGFsbG9jYXRpb24uIEFzIHRoZSBzZWN0aW9uDQoxIChpbnRyb2R1Y3Rpb24pIG9mIFJGQzYzMjUs IG9uZSBvZiB0aGUgaW1wb3J0YW50IGFkdmFudGFnZSBvZiBUUklMTCBpcw0KdGhhdCAmbmJzcDs8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPml0IGF2b2lkcyB0aGUg Y3JlYXRpbmcgc3VibmV0cyBvZiBJUA0KYWRkcmVzcyBhbmQgd2FzdGluZyBhZGRyZXNzLiBUaGUg bmlja25hbWUgYWNxdWlzaXRpb24gJm5ic3A7bWV0aG9kIGluIHRoaXMNCmRyYWZ0IHZpb2xhdGVz IHRoZSAmbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmlk ZWEgb2YgVFJJTEwgQmFzaWMgc3BlY2lmaWNhdGlvbiwgYW5kDQpyZWR1Y2VzIHRoZSBmbGV4aWJp bGl0eSBvZiBuaWNrbmFtZSBhbGxvY2F0aW9uLiBBcyB0aGUgZHJhZnQgYXNzdW1lZCwgQTENCmhh ZCAmbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPm5pY2tu YW1lIHJhbmdlIG9mIDEwMC0yMDAsIEEyIGhhcyBhDQpsb2NhbCBuaWNrbmFtZSByYW5nZSBvZiAy MDEtMzAwLiBJZiB0aGUgbnVtYmVycyBvZiBBMSBhcmVhIGlzIG9ubHkgNTAsDQpzbyA1MCAmbmJz cDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPm5pY2tuYW1lcyBp biBBMSBpcyB3YXN0ZWQuIEFzIHRoZSBuZXR3b3JrDQpncm93aW5nLCB0aGUgbnVtYmVyIG9mIHNv bWUgYXJlYXMgbWF5IGV4Y2VlZCB0aGUgbnVtYmVyIGJlaW5nIGFsbG9jYXRpb24NCiZuYnNwOzwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+YnkgQm9yZGVyIFJCcmlk Z2VzLiBUaGUgZGVzaWduIGFuZCBtYWludGFpbmluZw0Kb2Ygbmlja25hbWUgcmFuZ2VzIGZvciBl YWNoIGFyZWEgaXMgYSB2ZXJ5IGhhcmQgd29yay4gRXZlbiB3b3JzdCwgaXQgJm5ic3A7PC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5jYW4gbm90IGF2b2lkIHRvIHdh c3RlIG5pY2tuYW1lIHNwYWNlLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+KDMpIER5bmFtaWMgcmFuZ2VzIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7VGhlIG5pY2tuYW1lIHJhbmdlIGlzIGRpdmlkZWQNCmlu dG8gdHdvIHJhbmdlOiBsb2NhbCByYW5nZSBhbmQgZHluYW1pY2FsIHJhbmdlLiBJIHdvbmRlciB0 aGUgbmlja25hbWUNCmNvbmZsaWN0ICZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+cmVzb2x1dGlvbiBjYW4gbm90IHdvcmsgaWYgdGhlIFJCcmlkZ2UNCmdl dCB0aGUgbmlja25hbWUgZnJvbSB0aGUgZHluYW1pY2FsIHJhbmdlIHdoaWxlIHRoZSB0d28gUkJy aWRnZSBiZWxvbmdzDQp0byAmbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPmRpZmZlcmVudCBhcmVhcy4gRm9yIGV4YW1wbGUsIFJCMSBpcw0KaW4gYXJlYSBB MSwgYW5kIFJCMiBpcyBpbiBhcmVhIEEyLiBJZiBSQjEgZ2V0cyB0aGUgbmlja25hbWUgTjEgZnJv bSBkeW5hbWljDQombmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPnJhbmdlLCBhbmQgaXQgd2lsbCBmbG9vZHMgaW4gYXJlYSBBMSwNCmFuZCBvdGhlciBSQnJp ZGdlcyBpbiBhcmVhIEExIGNhbiBub3QgZ2V0IG5pY2tuYW1lIE4xIGJlY2F1c2Ugb2Ygbmlja25h bWUNCiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Y29u ZmxpY3Rpb24gbWVjaGFuaXNtLCBidXQgUkIyIGluIGFyZWENCkEyIGNhbiBub3QgcmVjZWl2ZSB0 aGUgUERVIGZyb20gUkIxLCBhbmQgaXQgJm5ic3A7Y2FuIGFsc28gZ2V0IHRoZSBuaWNrbmFtZQ0K TjEgZnJvbSAmbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PmR5bmFtaWNhbCByYW5nZS4gU28gdGhlIHF1ZXN0aW9uIGlzDQpob3cgdG8gYXZvaWQgdGhlIGR1 cGxpY2F0aW9uIGR5bmFtaWNhbCByYW5nZSBuaWNrbmFtZSBmb3IgZGlmZmVyZW50IGFyZWFzLjwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+KDQpIFRoZSBy aXNrIG9mIHJ1bm5pbmcgb3V0IG9mIG5pY2tuYW1lDQptYXliZSBhIGlzc3VlIGZvciBUUklMTC4g VGhlIG51bWJlciBvZiAyKioxNiBuaWNrbmFtZSBpcyBlbm91Z2ggZm9yIHRoZQ0KY3VycmVudCBk YXRhIGNlbnRlciw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZu YnNwO2J1dCBpdCBtYXliZSBub3QgZW5vdWdoIGluIHRoZQ0KZnV0dXJlLCBlc3BlY2FpbGx5IGlm IFRSSUxMIG92ZXIgSVAgLCBUUklMTCBvdmVyIE1QTFMgdGVjaG5vbG9neSBvciBzb21lDQpvdGhl ciBkYXRhIGNlbnRlciB0ZWNobm9sb2dpZXM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPiZuYnNwO2FyZSBkZXBsb3llZCwgdGhlIGRhdGEgY2VudGVyDQpuZXR3b3Jr IGNhbiBiZSBhIHZlcnkgbGFyZGdlIG5ldHdvcmsuIFNvIGkgdGhpbmsgdGhlIHZlcnkgaW1wb3J0 YW50IGFuZA0KZXNzZW50aWFsIGdvYWwgb2YgbXVsdGktbGV2ZWwgZHJhZnQgaXMgdG8gc2F2ZSBu aWNrbmFtZXMuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij5CZXN0IHJlZ2FyZHM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PkZhbmd3ZWkgSHU8YnI+DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9 MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM1JT48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+PGI+JnF1b3Q7VGlzc2EgU2VuZXZpcmF0aG5lDQoodHNlbmV2aXIpJnF1b3Q7 ICZsdDt0c2VuZXZpckBjaXNjby5jb20mZ3Q7PC9iPiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7cmJyaWRnZS1ib3VuY2VzQHBvc3RlbC5v cmc8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMi0wMi0yMyAx MTo1NTwvZm9udD4NCjx0ZCB3aWR0aD02NCU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxp Z249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj4mbHQ7cmJyaWRnZUBwb3N0ZWwub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0K PHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63L zTwvZm9udD48L2Rpdj4NCjx0ZD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1y aWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0 ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+W3JicmlkZ2VdIERlZmF1bHQgbmlja25h bWUgYmFzZSBhcHByb2FjaA0KZm9yIG11bHRpbGV2ZWwgVFJJTEwtICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO2RyYWZ0LXRpc3NhLXRyaWxsLW11bHRpbGV2ZWwtMDAudHh0PC9mb250PjwvdGFi bGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0K PGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5EZWFyIEFsbDxi cj4NCjxicj4NCldlIGhhdmUgc3VibWl0dGVkIGRyYWZ0LXRpc3NhLXRyaWxsLW11bHRpbGV2ZWws IHByZXNlbnQgbXVsdGlsZXZlbCBUUklMTA0KYmFzZWQgb24gZGVmYXVsdCBuaWNrbmFtZSBhcHBy b2FjaC4gQWRkaXRpb25hbGx5IHdlIGRpc2N1c3MgY29uc3RydWN0aW9uDQpvZiBtdWx0aS1kZXN0 aW5hdGlvbiB0cmVlcyBhbmQgcmVsYXRlZCBSUEYgaW4gbXVsdGlsZXZlbCBUUklMTC4gUGxlYXNl DQpjb3VsZCB5b3UgcmV2aWV3IGFuZCBjb21tZW50IDxicj4NCjxicj4NCkRldGFpbCBvZiB0aGUg ZHJhZnQgYW5kIGFic3RyYWN0IGFyZSBiZWxvdy48YnI+DQo8YnI+DQpGaWxlbmFtZTogJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7 ZHJhZnQtdGlzc2EtdHJpbGwtbXVsdGlsZXZlbDxicj4NClJldmlzaW9uOiAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDswMDxicj4N ClRpdGxlOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOw0KRGVmYXVsdCBOaWNrbmFtZSBCYXNlZCBBcHByb2FjaCBmb3IgTXVsdGls ZXZlbCBUUklMTDxicj4NCkNyZWF0aW9uIGRhdGU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOzIwMTItMDItMjE8YnI+DQpXRyBJ RDogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw Ow0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsNCkluZGl2aWR1YWwgU3VibWlzc2lvbjxicj4NCk51bWJlciBvZiBwYWdlczogMjY8 YnI+DQo8YnI+DQpBYnN0cmFjdDo8YnI+DQogJm5ic3A7IE11bHRpbGV2ZWwgVFJJTEwgYWxsb3dz IHRoZSBpbnRlcmNvbm5lY3Rpb24gb2YgbXVsdGlwbGUgVFJJTEw8YnI+DQogJm5ic3A7IG5ldHdv cmtzIHRvIGZvcm0gYSBsYXJnZXIgVFJJTEwgbmV0d29yayB3aXRob3V0IHByb3BvcnRpb25hbGx5 PGJyPg0KICZuYnNwOyBpbmNyZWFzaW5nIHRoZSBzaXplIG9mIHRoZSBJUy1JUyBMU1AgREIuIElu IHRoaXMgZG9jdW1lbnQsIGFuPGJyPg0KICZuYnNwOyBhcHByb2FjaCBiYXNlZCBvbiBkZWZhdWx0 IHJvdXRlIGNvbmNlcHQgaXMgcHJlc2VudGVkLiBBbHNvLDxicj4NCiAmbmJzcDsgcHJlc2VudGVk IGluIHRoZSBkb2N1bWVudCBpcyBhIG5vdmVsIG1ldGhvZCBvZiBjb25zdHJ1Y3RpbmcgbXVsdGkt PGJyPg0KICZuYnNwOyBkZXN0aW5hdGlvbiB0cmVlcyB1c2luZyBwYXJ0aWFsIG5pY2tuYW1lIHNw YWNlLiBNZXRob2RzIHByZXNlbnRlZA0KaW48YnI+DQogJm5ic3A7IHRoaXMgZG9jdW1lbnQgYXJl IGNvbXBhdGlibGUgd2l0aCB0aGUgUkZDNjMyNSBzcGVjaWZpZWQgZGF0YSBwbGFuZTxicj4NCiAm bmJzcDsgb3BlcmF0aW9ucy48YnI+DQo8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxicj4NClRoYW5rczxicj4NClRpc3Nh PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpyYnJpZGdlIG1haWxpbmcgbGlzdDxicj4NCnJicmlkZ2VAcG9zdGVsLm9yZzxicj4N Cmh0dHA6Ly9tYWlsbWFuLnBvc3RlbC5vcmcvbWFpbG1hbi9saXN0aW5mby9yYnJpZGdlPGJyPg0K PGJyPg0KPC90dD48L2ZvbnQ+DQo8YnI+DQo= --=_alternative 0021414B482579AE_=-- --===============1545242784== 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 --===============1545242784==-- From rbridge-bounces@postel.org Fri Feb 24 06:32: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 7F5B921F87B5 for ; Fri, 24 Feb 2012 06:32:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.161 X-Spam-Level: X-Spam-Status: No, score=-107.161 tagged_above=-999 required=5 tests=[AWL=-1.122, BAYES_00=-2.599, MIME_HEADER_CTYPE_ONLY=0.56, 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 hL1EbfKpX7gY for ; Fri, 24 Feb 2012 06:32:42 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 9F89521F87AA for ; Fri, 24 Feb 2012 06:32:42 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1OEIjGx011998; Fri, 24 Feb 2012 06:18:46 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1OEIFAJ011653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 24 Feb 2012 06:18:24 -0800 (PST) Received: from /spool/local by e32.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 24 Feb 2012 07:18:06 -0700 Received: from d01dlp03.pok.ibm.com (9.56.224.17) by e32.co.us.ibm.com (192.168.1.132) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 24 Feb 2012 07:17:09 -0700 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id B96C4C9005A for ; Fri, 24 Feb 2012 09:17:07 -0500 (EST) Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q1OEH5lN234064 for ; Fri, 24 Feb 2012 09:17:06 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q1OEH1as002963 for ; Fri, 24 Feb 2012 12:17:01 -0200 Received: from cichlid.raleigh.ibm.com (sig-9-65-253-63.mts.ibm.com [9.65.253.63]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q1OEH0va002892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Feb 2012 12:17:01 -0200 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 q1OEGKrl010152; Fri, 24 Feb 2012 09:16:21 -0500 Message-Id: <201202241416.q1OEGKrl010152@cichlid.raleigh.ibm.com> To: Donald Eastlake In-reply-to: References: <201202211422.q1LEMDin024613@cichlid.raleigh.ibm.com> Comments: In-reply-to Donald Eastlake message dated "Thu, 23 Feb 2012 15:02:18 -0500." Date: Fri, 24 Feb 2012 09:16:20 -0500 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12022414-3270-0000-0000-00000449BFE3 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: narten@us.ibm.com Cc: rbridge@postel.org Subject: Re: [rbridge] Trill Extensions and options 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="===============2115011321==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org --===============2115011321== Hi Donald. Donald Eastlake writes: > On Tue, Feb 21, 2012 at 9:22 AM, Thomas Narten wrote: > > There are a number of WG LC's going on at the moment, including > > rbridge-extension. I've also been reviewing and thinking about the > > entire set and looking at OAM approaches as well. > You seem to be looking considerably beyond the Extension draft > currently in WGLC. Primarily, the Extension draft provides more flag > bits and some ground rules. I'm looking beyond the extensions draft because presumably the extensions draft is being defined to support some future facility. But absent such a future facility (and a compelling argument for its utility), I think we are better off not defining the bits in the extensions draft at this time. Rather, we should just leave them reserved. This is driven by my overall sense that it is very hard to design (correctly) facilities for some future unspecified use. The IETF has done so with many protocols, only to find out later that our attempts were not helpful. IMO, as a general principle, we are better off leaving fields undefined and reserved until there is a specific, concrete proposed use case. Only with a concrete proposed use case can we properly design the mechanism for providing that facility. Moreover, if we define facilities for which there is no compelling current use, it is unlikely that implementors will bother to implement them anyway. In which case, we haven't really acheived anything. > > At this point, I guess I have to say am unsold on the need for the > > extensions document and options at all. I'm raising this issue from > > the perspective of wanting to be convinced that there is something > > important I haven't considered. > The Options draft is not being proposed for advancement. Understood. > The Extension draft, which is in WGLC, mostly provides more detail on > facilities that are there in RFC 6325, which already provides that the > first word of the extension area is special. I wouldn't mind removing > from the Extension draft the two very minor passing references to the > possibility of the future specification of TLV options. The current reference to possible future TLV options doesn't concern me. I'm OK leaving it as it is. > > At a high level, why does TRILL we need extensions and options (at the > > trill header level) in the first place? > > > > Looking at draft-ietf-trill-rbridge-options-06.txt, for example, I > > don't see anything defined that seems particularly useful or > > necessary. ... > It seems pretty remarkable to me that you can determine that there is > nothing useful in ietf-trill-rbridge-options or in > eastlake-trill-rbridge-more-options or in anything else that someone > might think of in the future. Even if that were true, it isn't want's > being last called. What's being last called is more header flags. What I mean is that nothing that is in rbridge options to me provides important or critical functionality that couldn't be provided in some other way without using extensions. Sure, there are some possible features that *might* be useful, but to me, that is not sufficient justification. The Trill data plane should be optimized for the common case, and not be burdened with facilities that are not critical. > > Second, I feel like draft-ietf-trill-rbridge-extension-02.txt has a > > lot of things in it that have been proposed "just in case they might > > be useful". ... > I don't think there is a "lot" of anything in the Extension draft. The > concrete content of the Extension draft is just to take the rest of > the bits in the first 32-bit word of the extension area (a word > provided for and whose top two bits are specified in RFC 6325), > specify the type of the remaining bits in that word as extended header > flags, and specify the actually use of two of those bits. I think the entire concept of reserving ranges of bits for individual classes of flags is speculative. > > Without a compelling "must have" feature, I don't see vendors ever > > implementing TRILL options/extensions. ... > The functionality of the two particular extended header flags > specified in the Extension draft are, as far as I know, supported by > all existing TRILL silicon. To repeat, the Options draft is not > currently being proposed for advancement. I think we have different views on what "supported" means. Sure, existing silicon most likely can check for the critical bits and when present, punt the packet to the service processor. But IMO, that is not "support". The cost of shunting packets to the service processor is *very* high. Such extensions cannot be commonly used (else the service processor will be overloaded), meaning that in practice one cannot use such extensions on any *data* packet. Thus, such extensions are IMO very likely unusable/undeployable in practice. Thus, I think it is very misleading to say that existing silicon "supports" such extensions. > > The main argument I can see in favor of defining extensions now is so > > that folk can implement: > > > > 1) the checking of the critical bits > > 2) being able to  skip over unknown extensions in the future, should > >   any ever be defined. > I agree that 1 is an significant argument but on your 2, I would say > it is more to be able to do things like tunnel some known information > from ingress to egress, or the like, not necessarily that that > information be "unknown". I think you miss my point on 2). Trill (for ECMP and for multicast tree prunning) requires that the forwarding plane be able to find the inner header and extract relevant fields. In order to do this (in the fast path), ASICs must be able to use the Op Length field in order to skip over any extensions to find the inner header fields Are you saying existing silicon can do that? I do not believe this is the case. And if not, it means that any packet with an extension will get shunted to the service processor, which means use of such options in a typical Trill data packet will be a non-starter. Do you disagree? > One person's "solution in search of a problem" is another person's > simple foundation facilities that should be specified early so they at > least have a chance of being available later if needed. Although > specific concrete example uses are given for the channel Alert > flags, Note that per my other message, I don't believe the case for a Channel Alert flag has been made. I'd prefer to wait before defining it. > I can't guarantee they will actually be used in the future. But since > their functionality is supported by all existing silicon I know about > and the cost of supporting the Alert flags, for an RBridge that > supports the channel feature at all, would be very low, I believe they > should be specified and the Extension draft should advance. Again, we disagree on what "supported by all existing silicon" means. Thomas --===============2115011321== 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 --===============2115011321==-- From rbridge-bounces@postel.org Fri Feb 24 06:56: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 C09B721F87E4 for ; Fri, 24 Feb 2012 06:56:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.056 X-Spam-Level: X-Spam-Status: No, score=-4.056 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 8tjd7mGbUgTl for ; Fri, 24 Feb 2012 06:56:06 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 97F8B21F867A for ; Fri, 24 Feb 2012 06:56:06 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1OEFir7011516; Fri, 24 Feb 2012 06:15:45 -0800 (PST) Received: from mail-ey0-f180.google.com (mail-ey0-f180.google.com [209.85.215.180]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1OEFMH9011485 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 24 Feb 2012 06:15:32 -0800 (PST) Received: by eaad14 with SMTP id d14so1099825eaa.39 for ; Fri, 24 Feb 2012 06:15:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=t8suXIeYS2LAd39tYQtBCokbkGTH/LDtUbABNa6eJhM=; b=Z2p2hgcirJKqNXvW6XALHFoqd8LCu0Iko4h7Cc4TypGsPm77YFoZ9B2mBpn618GsFs XKRvBUDGn4XG6GQfTOZHFW++rzoilUVb5Ct6t3vlDofTw/6y1ZCG7WqcWYsx9dwL7h2L /FPaF6LVt5IW7vgMjlhaK22I4TRPALz7Q3mYs= MIME-Version: 1.0 Received: by 10.14.99.2 with SMTP id w2mr1228653eef.69.1330092921304; Fri, 24 Feb 2012 06:15:21 -0800 (PST) Received: by 10.213.28.14 with HTTP; Fri, 24 Feb 2012 06:15:21 -0800 (PST) In-Reply-To: References: <344037D7CFEFE84E97E9CC1F56C5F4A5A45E88@xmb-sjc-214.amer.cisco.com> Date: Fri, 24 Feb 2012 06:15:21 -0800 Message-ID: From: Radia Perlman To: hu.fangwei@zte.com.cn X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radiaperlman@gmail.com Cc: "Tissa Senevirathne \(tsenevir\)" , rbridge@postel.org, rbridge-bounces@postel.org Subject: Re: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.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: multipart/mixed; boundary="===============1286324913==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org --===============1286324913== Content-Type: multipart/alternative; boundary=bcaec52be49317b84604b9b66442 --bcaec52be49317b84604b9b66442 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable People have mentioned to me that they are nervous about running out of nicknames, especially since there are reasonson why they might want to assign nicknames to hypervisors. With the alternate approach of allowing nicknames to be reused in different areas, it makes automatic nickname assignment much simpler and makes TRILL a lot more scalable. It does have the downside of requiring mapping of nicknames at the border RBridges. And by the way, the affinity TLV can be used for multidestination frames transiting between level 1 and level 2. Radia 2012/2/23 > > Hi, Tissa. > > I have several comments about the draft. > > (1) in section 4.4 (Multicast), "The scope of global traffic may be > identified either through VLAN or via finegrain > label that spans across the entire TRILL campus." > Vlan and Fine-grain Label is used for service differentiation and > isolation. I do not quite understand that how to > use VLAN and fine-grain Lable to identify the traffic scope. The data > traffic with a given VLAN-x, can > be forwarded to other end station in the local area, or to the end statio= n > in remote areas. > > (2) nickname allocation > The nickname management sub-TLV is proposed in the document. I wonder thi= s > mechanism adds the complication of > nickname allocation. As the section 1 (introduction) of RFC6325, one of > the important advantage of TRILL is that > it avoids the creating subnets of IP address and wasting address. The > nickname acquisition method in this draft violates the > idea of TRILL Basic specification, and reduces the flexibility of nicknam= e > allocation. As the draft assumed, A1 had > nickname range of 100-200, A2 has a local nickname range of 201-300. If > the numbers of A1 area is only 50, so 50 > nicknames in A1 is wasted. As the network growing, the number of some > areas may exceed the number being allocation > by Border RBridges. The design and maintaining of nickname ranges for eac= h > area is a very hard work. Even worst, it > can not avoid to waste nickname space. > > (3) Dynamic ranges > The nickname range is divided into two range: local range and dynamical > range. I wonder the nickname conflict > resolution can not work if the RBridge get the nickname from the dynamica= l > range while the two RBridge belongs to > different areas. For example, RB1 is in area A1, and RB2 is in area A2. I= f > RB1 gets the nickname N1 from dynamic > range, and it will floods in area A1, and other RBridges in area A1 can > not get nickname N1 because of nickname > confliction mechanism, but RB2 in area A2 can not receive the PDU from > RB1, and it can also get the nickname N1 from > dynamical range. So the question is how to avoid the duplication dynamica= l > range nickname for different areas. > > (4) The risk of running out of nickname maybe a issue for TRILL. The > number of 2**16 nickname is enough for the current data center, > but it maybe not enough in the future, especailly if TRILL over IP , > TRILL over MPLS technology or some other data center technologies > are deployed, the data center network can be a very lardge network. So i > think the very important and essential goal of multi-level draft is to sa= ve > nicknames. > > Best regards > Fangwei Hu > > > > *"Tissa Senevirathne (tsenevir)" * > =B7=A2=BC=FE=C8=CB: rbridge-bounces@postel.org > > 2012-02-23 11:55 > =CA=D5=BC=FE=C8=CB > > =B3=AD=CB=CD > =D6=F7=CC=E2 > [rbridge] Default nickname base approach for multilevel TRILL- > draft-tissa-trill-multilevel-00.txt > > > > > Dear All > > We have submitted draft-tissa-trill-multilevel, present multilevel TRILL > based on default nickname approach. Additionally we discuss construction = of > multi-destination trees and related RPF in multilevel TRILL. Please could > you review and comment > > Detail of the draft and abstract are below. > > Filename: draft-tissa-trill-multilevel > Revision: 00 > Title: Default Nickname Based Approach > for Multilevel TRILL > Creation date: 2012-02-21 > WG ID: Individual Submission > Number of pages: 26 > > Abstract: > Multilevel TRILL allows the interconnection of multiple TRILL > networks to form a larger TRILL network without proportionally > increasing the size of the IS-IS LSP DB. In this document, an > approach based on default route concept is presented. Also, > presented in the document is a novel method of constructing multi- > destination trees using partial nickname space. Methods presented in > this document are compatible with the RFC6325 specified data plane > operations. > > > > Thanks > Tissa > > _______________________________________________ > 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 > > --bcaec52be49317b84604b9b66442 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
People have mentioned to me that they are nervous about running out of= nicknames, especially since there are reasonson why they might want to ass= ign nicknames to hypervisors.  With the alternate approach of allowing= nicknames to be reused in different areas, it makes automatic nickname ass= ignment much simpler and makes TRILL a lot more scalable.
 
It does have the downside of requiring mapping of nicknames at the bor= der RBridges.
 
And by the way, the affinity TLV can be used for multidestination fram= es transiting between level 1 and level 2.
 
Radia

2012/2/23 <hu.fangwei@zte.com.cn>

Hi, Tis= sa.

I have several comments about = the draft.

(1) in section 4.4 (Multicast), "The sco= pe of global traffic may be identified either through VLAN or via finegrain=
label that spans across the entire TR= ILL campus."
Vlan and Fine-grain Label is used for service dif= ferentiation and isolation. I do not quite understand that how to use VLAN and fine-grain Lable to identify the t= raffic scope. The data traffic with a given VLAN-x, can
be forwarded to other end station in the local ar= ea, or to the end station in remote areas.

(2) nickname allocation
The n= ickname management sub-TLV is proposed in the document. I wonder this mecha= nism adds the complication of  
nickname allocation. As the section 1 (introducti= on) of RFC6325, one of the important advantage of TRILL is that  
it avoids the creating subnets of IP addre= ss and wasting address. The nickname acquisition  method in this draft= violates the  
idea of TRILL Basic specification, and reduces th= e flexibility of nickname allocation. As the draft assumed, A1 had  
nickname range of 100-200, A2 has a loc= al nickname range of 201-300. If the numbers of A1 area is only 50, so 50 &= nbsp;
nicknames in A1 is wasted. As the network growing= , the number of some areas may exceed the number being allocation  
by Border RBridges. The design and maint= aining of nickname ranges for each area is a very hard work. Even worst, it=  
can not avoid to waste nickname space.
(3) Dynamic ranges
 The nickname range is divided into two range: local range= and dynamical range. I wonder the nickname conflict  
resolution can not work if the RBridge get the ni= ckname from the dynamical range while the two RBridge belongs to  
different areas. For example, RB1 is in a= rea A1, and RB2 is in area A2. If RB1 gets the nickname N1 from dynamic &nb= sp;
range, and it will floods in area A1, and other R= Bridges in area A1 can not get nickname N1 because of nickname  
confliction mechanism, but RB2 in area A2 c= an not receive the PDU from RB1, and it  can also get the nickname N1 = from  
dynamical range. So the question is how to avoid = the duplication dynamical range nickname for different areas.
(4) The risk of running out of nickname maybe a= issue for TRILL. The number of 2**16 nickname is enough for the current da= ta center,
 but it maybe not enough in the future, espe= cailly if TRILL over IP , TRILL over MPLS technology or some other data cen= ter technologies
 are deployed, t= he data center network can be a very lardge network. So i think the very im= portant and essential goal of multi-level draft is to save nicknames.

Best regards
Fangwei Hu



"Tissa Senev= irathne (tsenevir)" <tsenevir@cisco.com>
=B7=A2=BC=FE=C8=CB:  rbridge-bounces@postel.org=20

2012-02-23 11:55

=CA=D5=BC=FE=C8= =CB
<rbridge@postel.org>=20
=B3=AD=CB=CD
=D6=F7=CC=E2
[rbridge] Default nickname base ap= proach for multilevel TRILL-        draft-tissa-trill-m= ultilevel-00.txt




Dear All

We have submitted d= raft-tissa-trill-multilevel, present multilevel TRILL based on default nick= name approach. Additionally we discuss construction of multi-destination tr= ees and related RPF in multilevel TRILL. Please could you review and commen= t

Detail of the draft and abstract are below.

Filename:   &nb= sp;              draft-tissa-trill-multi= level
Revision:                 =  00
Title:                 =                   Default Nick= name Based Approach for Multilevel TRILL
Creation date:                 &nbs= p;2012-02-21
WG ID:               &nb= sp;                   Individu= al Submission
Number of pages: 26

Abstract:
  Multilevel = TRILL allows the interconnection of multiple TRILL
  networks to fo= rm a larger TRILL network without proportionally
  increasing the size of the IS-IS LSP DB. In this document, an
&nb= sp; approach based on default route concept is presented. Also,
  p= resented in the document is a novel method of constructing multi-
 = destination trees using partial nickname space. Methods presented in
  this document are compatible with the RFC6325 specified data plane  operations.

             = ;                     &nb= sp;                     &= nbsp;                    =    
Thanks
Tissa

__________________________________= _____________
rbridge mailing list
rbridge@postel.org
http://mailman.postel.org/mailman/list= info/rbridge



_______________________________________= ________
rbridge mailing list
r= bridge@postel.org
http://mailman.postel.org/mailman/listinfo/r= bridge


--bcaec52be49317b84604b9b66442-- --===============1286324913== 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 --===============1286324913==-- From rbridge-bounces@postel.org Fri Feb 24 08:52:12 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 1786021F8797 for ; Fri, 24 Feb 2012 08:52:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.027 X-Spam-Level: X-Spam-Status: No, score=-5.027 tagged_above=-999 required=5 tests=[AWL=-0.880, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 tvgrg7cUTKkb for ; Fri, 24 Feb 2012 08:52:10 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 34F0821F8736 for ; Fri, 24 Feb 2012 08:52:10 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1OGNnOG004111; Fri, 24 Feb 2012 08:23:51 -0800 (PST) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1OGNPLG003730; Fri, 24 Feb 2012 08:23:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tsenevir@cisco.com; l=24951; q=dns/txt; s=iport; t=1330100615; x=1331310215; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=6YX/uE7FDwD5BsNz3klytE5Ta3V+zCc3ACpYxal7Nk0=; b=L+gRDr7NFNAyu52czTo234KEE6UxOSCd1sXKs6HW3z3hyUZkP36ce7xx tUNhWVdQOOYcKlx7zCnE/GvXs+HG8skXKCP5XbrgjYezQc0dv3S9JGGwU hyiaMLH5elS6kMP10j7fOEqHJ8Ghmfj/0uqQ4ecAt/cFjDCmEj/OL/P3j E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcEAOS4R09Io8UY/2dsb2JhbAA6CoI/gmmkUgGKE4FzAQEBBAEBAQ8BCREDPgsQAgEGAhEEAQELBhADBAEEAgEgBh8JCAEBBAESCBqHYwELmjABjF8IkX6JDmGDDQICBQEEAQgBAQMIDQdKAYRmAQQZIxECCwcEBAIDBQMEARQGGgwDghM3YwSIT5gEh3iBMgU X-IronPort-AV: E=Sophos;i="4.73,476,1325462400"; d="scan'208,217";a="6334681" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 24 Feb 2012 16:23:24 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q1OGNEUx018666; Fri, 24 Feb 2012 16:23:23 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, 24 Feb 2012 08:23:19 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 24 Feb 2012 08:23:17 -0800 Message-ID: <344037D7CFEFE84E97E9CC1F56C5F4A5A462E7@xmb-sjc-214.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.txt Thread-Index: Aczy/sA5S8+rQ7LjRbiodcCTpocBqgAD1fiA References: <344037D7CFEFE84E97E9CC1F56C5F4A5A45E88@xmb-sjc-214.amer.cisco.com> From: "Tissa Senevirathne (tsenevir)" To: "Radia Perlman" , X-OriginalArrivalTime: 24 Feb 2012 16:23:19.0150 (UTC) FILETIME=[9E85D8E0:01CCF310] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: tsenevir@cisco.com Cc: rbridge@postel.org, rbridge-bounces@postel.org Subject: Re: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.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: multipart/mixed; boundary="===============0914320872==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org This is a multi-part message in MIME format. --===============0914320872== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCF310.9E2C1341" This is a multi-part message in MIME format. ------_=_NextPart_001_01CCF310.9E2C1341 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable Mutli-topology is the answer to increase the nickname space. =20 Nickname translation is very similar to NAT, which has it=A1=AFs own = down side, not to mention special hardware etc. to do the translations, = additionally. We also know from our experience, in IP world NATing is = not the most desired behavior and we live with it. So we should not be = going down that path instead need to look forward from that experience. =20 Multi-topology not only address nickname space issue but also enables = various other applications such as overlay topologies, traffic = engineering. =20 The draft-tiss-trill-multilevel present approaches that are generic, = which mean it can be applied for multi-topology, or base topology. It = utilizes the fundamentals of IS-IS , such as Area hierarchy for = reduction of the LSP-DB. It utilize affinity TLV concepts to effectively = solve multi-destination issues.=20 =20 We should not mix-up between Data center interconnects with data center = node scaling. They are two different and orthogonal issues. =20 Objective of multi-level trill is to interconnect different datacenters, = and maintain LSP-DB small as possible to avoid scaling and volatility. =20 Increasing nickname space a different requirement and has nothing to do = with data-center interconnects. =20 =20 From: Radia Perlman [mailto:radiaperlman@gmail.com]=20 Sent: Friday, February 24, 2012 6:15 AM To: hu.fangwei@zte.com.cn Cc: Tissa Senevirathne (tsenevir); rbridge@postel.org; = rbridge-bounces@postel.org Subject: Re: [rbridge] Default nickname base approach for multilevel = TRILL- draft-tissa-trill-multilevel-00.txt =20 People have mentioned to me that they are nervous about running out of = nicknames, especially since there are reasonson why they might want to = assign nicknames to hypervisors. With the alternate approach of = allowing nicknames to be reused in different areas, it makes automatic = nickname assignment much simpler and makes TRILL a lot more scalable. =20 It does have the downside of requiring mapping of nicknames at the = border RBridges. =20 And by the way, the affinity TLV can be used for multidestination frames = transiting between level 1 and level 2. =20 Radia 2012/2/23 Hi, Tissa.=20 I have several comments about the draft.=20 (1) in section 4.4 (Multicast), "The scope of global traffic may be = identified either through VLAN or via finegrain=20 label that spans across the entire TRILL campus."=20 Vlan and Fine-grain Label is used for service differentiation and = isolation. I do not quite understand that how to=20 use VLAN and fine-grain Lable to identify the traffic scope. The data = traffic with a given VLAN-x, can=20 be forwarded to other end station in the local area, or to the end = station in remote areas.=20 (2) nickname allocation=20 The nickname management sub-TLV is proposed in the document. I wonder = this mechanism adds the complication of =20 nickname allocation. As the section 1 (introduction) of RFC6325, one of = the important advantage of TRILL is that =20 it avoids the creating subnets of IP address and wasting address. The = nickname acquisition method in this draft violates the =20 idea of TRILL Basic specification, and reduces the flexibility of = nickname allocation. As the draft assumed, A1 had =20 nickname range of 100-200, A2 has a local nickname range of 201-300. If = the numbers of A1 area is only 50, so 50 =20 nicknames in A1 is wasted. As the network growing, the number of some = areas may exceed the number being allocation =20 by Border RBridges. The design and maintaining of nickname ranges for = each area is a very hard work. Even worst, it =20 can not avoid to waste nickname space.=20 (3) Dynamic ranges=20 The nickname range is divided into two range: local range and dynamical = range. I wonder the nickname conflict =20 resolution can not work if the RBridge get the nickname from the = dynamical range while the two RBridge belongs to =20 different areas. For example, RB1 is in area A1, and RB2 is in area A2. = If RB1 gets the nickname N1 from dynamic =20 range, and it will floods in area A1, and other RBridges in area A1 can = not get nickname N1 because of nickname =20 confliction mechanism, but RB2 in area A2 can not receive the PDU from = RB1, and it can also get the nickname N1 from =20 dynamical range. So the question is how to avoid the duplication = dynamical range nickname for different areas.=20 (4) The risk of running out of nickname maybe a issue for TRILL. The = number of 2**16 nickname is enough for the current data center,=20 but it maybe not enough in the future, especailly if TRILL over IP , = TRILL over MPLS technology or some other data center technologies=20 are deployed, the data center network can be a very lardge network. So = i think the very important and essential goal of multi-level draft is to = save nicknames.=20 Best regards=20 Fangwei Hu "Tissa Senevirathne (tsenevir)" =20 =B7=A2=BC=FE=C8=CB: rbridge-bounces@postel.org=20 2012-02-23 11:55=20 =CA=D5=BC=FE=C8=CB =20 =B3=AD=CB=CD =09 =D6=F7=CC=E2 [rbridge] Default nickname base approach for multilevel TRILL- = draft-tissa-trill-multilevel-00.txt =20 =09 =09 Dear All We have submitted draft-tissa-trill-multilevel, present multilevel TRILL = based on default nickname approach. Additionally we discuss construction = of multi-destination trees and related RPF in multilevel TRILL. Please = could you review and comment=20 Detail of the draft and abstract are below. Filename: draft-tissa-trill-multilevel Revision: 00 Title: Default Nickname Based Approach = for Multilevel TRILL Creation date: 2012-02-21 WG ID: Individual Submission Number of pages: 26 Abstract: Multilevel TRILL allows the interconnection of multiple TRILL networks to form a larger TRILL network without proportionally increasing the size of the IS-IS LSP DB. In this document, an approach based on default route concept is presented. Also, presented in the document is a novel method of constructing multi- destination trees using partial nickname space. Methods presented in this document are compatible with the RFC6325 specified data plane operations. = =20 Thanks Tissa _______________________________________________ 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 =20 ------_=_NextPart_001_01CCF310.9E2C1341 Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable

Mutli-topology is the answer to increase the nickname = space.

 

Nickname translation is very similar to NAT, which has it=A1=AFs own = down side, not to mention special hardware etc. to do the translations, = additionally. We also know from our experience, in IP world NATing is = not the most desired behavior and we live with it. So we should not be = going down that path instead need to look forward from that = experience.

 

Multi-topology not only address nickname space issue but also enables = various other applications such as overlay topologies, traffic = engineering.

 

The draft-tiss-trill-multilevel present approaches that are generic, = which mean it can be applied for multi-topology, or base topology. It = utilizes the fundamentals of IS-IS , such as Area hierarchy for = reduction of the LSP-DB. It utilize affinity TLV concepts to effectively = solve multi-destination issues.

 

We should not mix-up between Data center interconnects with data = center node scaling. They are two different and orthogonal = issues.

 

Objective of multi-level trill is to interconnect different = datacenters, and maintain LSP-DB small as possible to avoid scaling and = volatility.

 

Increasing nickname space a different requirement and has nothing to = do with data-center interconnects.

 

 

From:= = Radia Perlman [mailto:radiaperlman@gmail.com]
Sent: Friday, = February 24, 2012 6:15 AM
To: = hu.fangwei@zte.com.cn
Cc: Tissa Senevirathne (tsenevir); = rbridge@postel.org; rbridge-bounces@postel.org
Subject: Re: = [rbridge] Default nickname base approach for multilevel TRILL- = draft-tissa-trill-multilevel-00.txt

 

People = have mentioned to me that they are nervous about running out of = nicknames, especially since there are reasonson why they might want to = assign nicknames to hypervisors.  With the alternate approach of = allowing nicknames to be reused in different areas, it makes automatic = nickname assignment much simpler and makes TRILL a lot more = scalable.

 

It does have the downside of requiring mapping of = nicknames at the border RBridges.

 

And by the way, the affinity TLV can be used for = multidestination frames transiting between level 1 and level = 2.

 

Radia

2012/2/23 <hu.fangwei@zte.com.cn><= /o:p>


Hi, Tissa. =

I have several = comments about the draft.

(1) in section 4.4 = (Multicast), "The scope of global traffic may be identified either = through VLAN or via finegrain
label that spans across the = entire TRILL campus."
Vlan and Fine-grain Label is = used for service differentiation and isolation. I do not quite = understand that how to
use VLAN and fine-grain Lable = to identify the traffic scope. The data traffic with a given VLAN-x, can =
be forwarded = to other end station in the local area, or to the end station in remote = areas.

(2) nickname = allocation
The nickname management = sub-TLV is proposed in the document. I wonder this mechanism adds the = complication of  
nickname allocation. As the = section 1 (introduction) of RFC6325, one of the important advantage of = TRILL is that  
it avoids the creating = subnets of IP address and wasting address. The nickname acquisition =  method in this draft violates the  
idea of TRILL Basic = specification, and reduces the flexibility of nickname allocation. As = the draft assumed, A1 had  
nickname range of 100-200, A2 = has a local nickname range of 201-300. If the numbers of A1 area is only = 50, so 50  
nicknames in A1 is wasted. As = the network growing, the number of some areas may exceed the number = being allocation  
by Border RBridges. The = design and maintaining of nickname ranges for each area is a very hard = work. Even worst, it  
can not avoid to waste = nickname space.

(3) Dynamic ranges =
 The = nickname range is divided into two range: local range and dynamical = range. I wonder the nickname conflict  
resolution can not work if = the RBridge get the nickname from the dynamical range while the two = RBridge belongs to  
different areas. For example, = RB1 is in area A1, and RB2 is in area A2. If RB1 gets the nickname N1 = from dynamic  
range, and it will floods in = area A1, and other RBridges in area A1 can not get nickname N1 because = of nickname  
confliction mechanism, but = RB2 in area A2 can not receive the PDU from RB1, and it  can also = get the nickname N1 from  
dynamical range. So the = question is how to avoid the duplication dynamical range nickname for = different areas.

(4) The risk of running out = of nickname maybe a issue for TRILL. The number of 2**16 nickname is = enough for the current data center,
 but it maybe not enough = in the future, especailly if TRILL over IP , TRILL over MPLS technology = or some other data center technologies
 are deployed, the data = center network can be a very lardge network. So i think the very = important and essential goal of multi-level draft is to save = nicknames.

Best regards
Fangwei = Hu


"Tissa = Senevirathne (tsenevir)" <tsenevir@cisco.com> =
=B7=A2=BC=FE=C8=CB:  rbridge-bounces@postel.org =

2012-02-23 = 11:55

<rbridge@postel.org> =

=

=CA=D5=BC=FE=C8=CB

=B3=AD=CB=CD

=D6=F7=CC=E2

[rbridge] = Default nickname base approach for multilevel TRILL-     =   =  draft-tissa-trill-multilevel-00.txt

 




Dear = All

We have submitted draft-tissa-trill-multilevel, = present multilevel TRILL based on default nickname approach. = Additionally we discuss construction of multi-destination trees and = related RPF in multilevel TRILL. Please could you review and comment =

Detail of the draft and abstract are = below.

Filename:           =       =  draft-tissa-trill-multilevel
Revision:     =              00
Title: =                     =               Default Nickname Based = Approach for Multilevel TRILL
Creation date:     =             =  2012-02-21
WG ID:           =                     =     Individual Submission
Number of pages: = 26

Abstract:
  Multilevel TRILL allows = the interconnection of multiple TRILL
  networks to = form a larger TRILL network without proportionally
  = increasing the size of the IS-IS LSP DB. In this document, = an
  approach based on default route concept is = presented. Also,
  presented in the document is a novel = method of constructing multi-
  destination trees using = partial nickname space. Methods presented in
  this = document are compatible with the RFC6325 specified data = plane
  operations.

    =                     =                     =                     =                 =  
Thanks
Tissa

_____________= __________________________________
rbridge mailing = list
rbridge@postel.org
http://mailman.postel.org/mailman/listinfo/rbridge<= /tt>


______________________________________= _________
rbridge mailing list
rbridge@postel.org
http://mailman.postel.org/mailman/listinfo/rbridge<= o:p>

 

------_=_NextPart_001_01CCF310.9E2C1341-- --===============0914320872== 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 --===============0914320872==-- From rbridge-bounces@postel.org Fri Feb 24 09:24:39 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 BEFDA21F8726 for ; Fri, 24 Feb 2012 09:24:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.79 X-Spam-Level: X-Spam-Status: No, score=-105.79 tagged_above=-999 required=5 tests=[AWL=0.809, 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 5Y+ysbJcgLUG for ; Fri, 24 Feb 2012 09:24:38 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id C9ED521F85AD for ; Fri, 24 Feb 2012 09:24:32 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1OH3Hpo010718; Fri, 24 Feb 2012 09:03:18 -0800 (PST) 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 q1OH2X2r010594 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 24 Feb 2012 09:02:43 -0800 (PST) Received: by lagy4 with SMTP id y4so5169025lag.39 for ; Fri, 24 Feb 2012 09:02:32 -0800 (PST) Received-SPF: pass (google.com: domain of d3e3e3@gmail.com designates 10.152.125.20 as permitted sender) client-ip=10.152.125.20; Authentication-Results: mr.google.com; spf=pass (google.com: domain of d3e3e3@gmail.com designates 10.152.125.20 as permitted sender) smtp.mail=d3e3e3@gmail.com; dkim=pass header.i=d3e3e3@gmail.com Received: from mr.google.com ([10.152.125.20]) by 10.152.125.20 with SMTP id mm20mr2530509lab.6.1330102952454 (num_hops = 1); Fri, 24 Feb 2012 09:02:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=nmxLjxO43AzHo4u5bFOMyshUzdsKap0lASDvZBygdmw=; b=l3ch0A+E8gPRAm9MdFrdxzXjwAaFPVovNElZ69877LR1RN9gCRu0CNbEAvk/rWlJrG AEr8kdepGlxF/T5cFCPWXHmuvrG5tGXjMAisUy+HSf7UBTyKvnoxjxHX6nk9VrTSpj/3 aSimKZFOPCihPpZvAQPawPAHYMz2vFUO+ZOjY= Received: by 10.152.125.20 with SMTP id mm20mr2090630lab.6.1330102952362; Fri, 24 Feb 2012 09:02:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.80.234 with HTTP; Fri, 24 Feb 2012 09:02:11 -0800 (PST) In-Reply-To: <201202240121.q1O1LJ5L004767@cichlid.raleigh.ibm.com> References: <4F299636.7060604@acm.org> <201202240121.q1O1LJ5L004767@cichlid.raleigh.ibm.com> From: Donald Eastlake Date: Fri, 24 Feb 2012 12:02:11 -0500 Message-ID: To: Thomas Narten 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 q1OH2X2r010594 Cc: "rbridge@postel.org" , Erik Nordmark Subject: Re: [rbridge] WG last call on draft-ietf-trill-rbridge-bfd-02 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 Thomas, Thanks for your corrections below. Some of these were previously posted to the list or communicated to Vishwas Manral who is the current editor of the document. Vishwas has been asked to spin a new version. On the "sentence fragments" you mention, I believe that is supposed to be a bulleted list and should be indented with bullets. On the last comment in your message, concerning the use of "required", that word was copied from RFC 5881 but I think your suggested change is fine. Thanks again, 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 Thu, Feb 23, 2012 at 8:21 PM, Thomas Narten wrote: > Overall, I support this document. It does need a respin to clean up > what appear to be straightforward editing issues. > > Thomas > > Document probably should have a reference to core BFD RFCs earlier in > the document than it does (e.g., first use). > > =A0 there is work in the area. =A0The Rbridge Channel facility is specifi= ed > =A0 in [TRILLoam]. > > s/TRILLoam/CHANNELoam/ > > =A0 it and TRILL data plaen layer OAM, such as TRILL BFD, is beyond the > > s/plaen/plane/ > > =A0 TRILL BFD Control frames are unicast TRILL Rbridge Message Channel > =A0 frames [TRILLChannel]. =A0The Rbridge Channel Protocol value is given > =A0 in Section 10. > > There is no such term as "TRILL Rbridge Message Channel frames". I > think you want to just say "Trill Rbridge Channel frames" (i.e., drop > "Message"). Multiple occurances throughout document. > > =A0 A TRILL BFD Echo frame is a unicast TRILL OAM Message Channel > =A0 frame, > > Drop "OAM"? Indeed, the entire document needs a pass to remove > references to "OAM" that are no longer valid. BFD is now just part of > the channel draft. > > =A0 A TRILL BFD Echo frame is a unicast TRILL OAM Message Channel frame, > =A0 as specified in [TRILLoam], which should be forwarded back by an > > Drop "OAM" from above. Also, drop "Message", as that isn't the proper > term (I think). > > Better: > > =A0 A TRILL BFD Echo frame is a unicast TRILL Channel frame as > =A0 specified in [TRILLoam] with a Channel Protocol value of "BFD > =A0 Echo". Such packets should be forwarded back ... > > Need a reference in references section to TRILLoam document > > =A0 TRILL BFD Echo frames SHOULD only be sent on a link if > > =A0 A TRILL BFD Control session has been established, > > Format problem above. Truncated sentence? > > =A0 TRILL BFD Echo support is indicated by the potentially echo > =A0 responding RBridge. > > This sentence reads awkward. > > =A0 The adjacency is in the Report state [RFC6327], and > > Truncated sentence again? > > =A0 It is required that the operator of an RBridge campus configure the > =A0 rates at which TRILL BFD frames are transmitted on a link to avoid > =A0 congestion (e.g., link, I/O, CPU) and false failure detection. > > Don't like the "required" wording. =A0 Better to say something like "it > is up to the operator to ..." > > =A0 IANA is request to allocate two TRILL OAM Protocol numbers from the > =A0 range allocated by Standards Actions, as follows: > > Change wording of "OAM Protocol numbers"? > > _______________________________________________ > 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 Fri Feb 24 09:55: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 BAF5921F8591 for ; Fri, 24 Feb 2012 09:55:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.803 X-Spam-Level: X-Spam-Status: No, score=-105.803 tagged_above=-999 required=5 tests=[AWL=0.796, 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 k9CE+nJBS5PZ for ; Fri, 24 Feb 2012 09:55:08 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id A9AF521F853E for ; Fri, 24 Feb 2012 09:55:06 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1OHXnD4016888; Fri, 24 Feb 2012 09:33:50 -0800 (PST) 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 q1OHX2Kq016491 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 24 Feb 2012 09:33:12 -0800 (PST) Received: by lagy4 with SMTP id y4so5221409lag.39 for ; Fri, 24 Feb 2012 09:33:01 -0800 (PST) Received-SPF: pass (google.com: domain of d3e3e3@gmail.com designates 10.112.102.65 as permitted sender) client-ip=10.112.102.65; Authentication-Results: mr.google.com; spf=pass (google.com: domain of d3e3e3@gmail.com designates 10.112.102.65 as permitted sender) smtp.mail=d3e3e3@gmail.com; dkim=pass header.i=d3e3e3@gmail.com Received: from mr.google.com ([10.112.102.65]) by 10.112.102.65 with SMTP id fm1mr1238492lbb.88.1330104781414 (num_hops = 1); Fri, 24 Feb 2012 09:33:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=Vw8a8NMv7phOxDYVdSwtwnAAspmHqRZ2G2ZmMuCJimo=; b=GxGjXJhWao/GMYd2Ykt7JA6BUrmyS2I6Cjqd0CuCvBQg6cFU7G8EwNzvtUU9SK5BGq 4mxDw74Xnv1XdG0gOPgcg1ASJfVpSXYYUlJcQA/RtHZo0S98uJwwQUasOb8g2apfMYdS 0ChPxxeWgWSltL2oDu7NlCAwQELQDxmBRnaXk= Received: by 10.112.102.65 with SMTP id fm1mr1021717lbb.88.1330104781314; Fri, 24 Feb 2012 09:33:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.80.234 with HTTP; Fri, 24 Feb 2012 09:32:41 -0800 (PST) In-Reply-To: <201202232316.q1NNG7qK004098@cichlid.raleigh.ibm.com> References: <4F299302.3000804@acm.org> <201202232316.q1NNG7qK004098@cichlid.raleigh.ibm.com> From: Donald Eastlake Date: Fri, 24 Feb 2012 12:32:41 -0500 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 q1OHX2Kq016491 Subject: Re: [rbridge] WG last call of draft-ietf-trill-rbridge-extension-02 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 Thu, Feb 23, 2012 at 6:16 PM, Thomas Narten wrote: > > ... > > I have some other comments on the document itself, if it goes > forward. My main comment concerns Section 2.4. I think it should be > deleted entirely. We should just not allow the definition of > conflicting options. Or if we do, we should say mutually incompatable > options MUST NOT be used together at the same time. If someone ends up > generating Trill packets with conflicting options, let the behavior be > undefined. Looking at Section 2.4, it seems that implementations may > end up having to do a lot of work to adhere to the rules -- and for > what ends? =A0We should just strongly discourage the use of conflicting > extensions, and when they happen, buyer beware. We should not > complicate implementations to handle cases that really shouldn't be > allowed to happen. That is IMO a bad tradeoff. While I think it would be unreasonable to forbid ever defining options that could conflict, prohibiting the simultaneous use of such options and stating that the results would be unspecified is reasonable. This would be consistent with other parts of the TRILL specification that make checking various frame constraints optional for transit RBridges to reduce the burden on such RBridges. 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 > Alternatively, if we ever decide we need to define a conflicting > extension, that is the time to define how to handle the two when they > occur together. We may find that the proposed rules in Section 2.4 end > up being wrong for those specific options anyway, in which case we > find ourselves in a bind. > Thomas _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge From rbridge-bounces@postel.org Fri Feb 24 10:00:26 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 0328921F8720 for ; Fri, 24 Feb 2012 10:00:26 -0800 (PST) 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=0.085, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 RO20aop2vu3h for ; Fri, 24 Feb 2012 10:00:21 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 8814C21F8749 for ; Fri, 24 Feb 2012 10:00:21 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1OH68O3011323; Fri, 24 Feb 2012 09:06:09 -0800 (PST) Received: from mail-ey0-f180.google.com (mail-ey0-f180.google.com [209.85.215.180]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1OH59lk011140 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 24 Feb 2012 09:05:19 -0800 (PST) Received: by eaad14 with SMTP id d14so1204712eaa.39 for ; Fri, 24 Feb 2012 09:05:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Exsr5CdGqFhdmr4jB2JDAVO1zhJXghH++O1GH3n/nws=; b=gFEdTCHiqe9cw4K2CDjiKTh9A4VpW9vZ+9qP9o1SMYTtdckmROTQvGPeUY/whYlprZ NMl+5i170LzQCITnj111GxmCv/fek6a32Q4m0STvjNjcJZ/lhD0g3u7VaT36mWBsCMu0 Vq5Xnb3Z/r+t89j9fwZ6vj8T2At/XvRo0os80= MIME-Version: 1.0 Received: by 10.213.31.67 with SMTP id x3mr753867ebc.73.1330103109161; Fri, 24 Feb 2012 09:05:09 -0800 (PST) Received: by 10.213.28.14 with HTTP; Fri, 24 Feb 2012 09:05:09 -0800 (PST) In-Reply-To: <344037D7CFEFE84E97E9CC1F56C5F4A5A462E7@xmb-sjc-214.amer.cisco.com> References: <344037D7CFEFE84E97E9CC1F56C5F4A5A45E88@xmb-sjc-214.amer.cisco.com> <344037D7CFEFE84E97E9CC1F56C5F4A5A462E7@xmb-sjc-214.amer.cisco.com> Date: Fri, 24 Feb 2012 09:05:09 -0800 Message-ID: From: Radia Perlman To: "Tissa Senevirathne (tsenevir)" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radiaperlman@gmail.com Cc: rbridge@postel.org, rbridge-bounces@postel.org, hu.fangwei@zte.com.cn Subject: Re: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.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: multipart/mixed; boundary="===============0950711893==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org --===============0950711893== Content-Type: multipart/alternative; boundary=0015174bf1ec56132c04b9b8c31d --0015174bf1ec56132c04b9b8c31d Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable I don't understand how multi-topology helps with the nickname exhaustion issue. As a matter of fact, the only plausible way of marking a packet for which topology that has been suggested on the mailing list (I asked a efw times if there were any other possibilities), was to steal 2 or 3 bits of the nickname to encode which topology, in effect, making a destination appear as multiple destinations and multiple forwarding table entries (which you'd want anyway, for multitopology). Radia 2012/2/24 Tissa Senevirathne (tsenevir) > Mutli-topology is the answer to increase the nickname space.**** > > ** ** > > Nickname translation is very similar to NAT, which has it=A1=AFs own down= side, > not to mention special hardware etc. to do the translations, additionally= . > We also know from our experience, in IP world NATing is not the most > desired behavior and we live with it. So we should not be going down that > path instead need to look forward from that experience.**** > > ** ** > > Multi-topology not only address nickname space issue but also enables > various other applications such as overlay topologies, traffic engineerin= g. > **** > > ** ** > > The draft-tiss-trill-multilevel present approaches that are generic, whic= h > mean it can be applied for multi-topology, or base topology. It utilizes > the fundamentals of IS-IS , such as Area hierarchy for reduction of the > LSP-DB. It utilize affinity TLV concepts to effectively solve > multi-destination issues. **** > > ** ** > > We should not mix-up between Data center interconnects with data center > node scaling. They are two different and orthogonal issues.**** > > ** ** > > Objective of multi-level trill is to interconnect different datacenters, > and maintain LSP-DB small as possible to avoid scaling and volatility.***= * > > ** ** > > Increasing nickname space a different requirement and has nothing to do > with data-center interconnects.**** > > ** ** > > ** ** > > *From:* Radia Perlman [mailto:radiaperlman@gmail.com] > *Sent:* Friday, February 24, 2012 6:15 AM > *To:* hu.fangwei@zte.com.cn > *Cc:* Tissa Senevirathne (tsenevir); rbridge@postel.org; > rbridge-bounces@postel.org > *Subject:* Re: [rbridge] Default nickname base approach for multilevel > TRILL- draft-tissa-trill-multilevel-00.txt**** > > ** ** > > People have mentioned to me that they are nervous about running out of > nicknames, especially since there are reasonson why they might want to > assign nicknames to hypervisors. With the alternate approach of allowing > nicknames to be reused in different areas, it makes automatic nickname > assignment much simpler and makes TRILL a lot more scalable.**** > > **** > > It does have the downside of requiring mapping of nicknames at the border > RBridges.**** > > **** > > And by the way, the affinity TLV can be used for multidestination frames > transiting between level 1 and level 2.**** > > **** > > Radia**** > > 2012/2/23 **** > > > Hi, Tissa. > > I have several comments about the draft. > > (1) in section 4.4 (Multicast), "The scope of global traffic may be > identified either through VLAN or via finegrain > label that spans across the entire TRILL campus." > Vlan and Fine-grain Label is used for service differentiation and > isolation. I do not quite understand that how to > use VLAN and fine-grain Lable to identify the traffic scope. The data > traffic with a given VLAN-x, can > be forwarded to other end station in the local area, or to the end statio= n > in remote areas. > > (2) nickname allocation > The nickname management sub-TLV is proposed in the document. I wonder thi= s > mechanism adds the complication of > nickname allocation. As the section 1 (introduction) of RFC6325, one of > the important advantage of TRILL is that > it avoids the creating subnets of IP address and wasting address. The > nickname acquisition method in this draft violates the > idea of TRILL Basic specification, and reduces the flexibility of nicknam= e > allocation. As the draft assumed, A1 had > nickname range of 100-200, A2 has a local nickname range of 201-300. If > the numbers of A1 area is only 50, so 50 > nicknames in A1 is wasted. As the network growing, the number of some > areas may exceed the number being allocation > by Border RBridges. The design and maintaining of nickname ranges for eac= h > area is a very hard work. Even worst, it > can not avoid to waste nickname space. > > (3) Dynamic ranges > The nickname range is divided into two range: local range and dynamical > range. I wonder the nickname conflict > resolution can not work if the RBridge get the nickname from the dynamica= l > range while the two RBridge belongs to > different areas. For example, RB1 is in area A1, and RB2 is in area A2. I= f > RB1 gets the nickname N1 from dynamic > range, and it will floods in area A1, and other RBridges in area A1 can > not get nickname N1 because of nickname > confliction mechanism, but RB2 in area A2 can not receive the PDU from > RB1, and it can also get the nickname N1 from > dynamical range. So the question is how to avoid the duplication dynamica= l > range nickname for different areas. > > (4) The risk of running out of nickname maybe a issue for TRILL. The > number of 2**16 nickname is enough for the current data center, > but it maybe not enough in the future, especailly if TRILL over IP , > TRILL over MPLS technology or some other data center technologies > are deployed, the data center network can be a very lardge network. So i > think the very important and essential goal of multi-level draft is to sa= ve > nicknames. > > Best regards > Fangwei Hu > > > **** > > *"Tissa Senevirathne (tsenevir)" * > =B7=A2=BC=FE=C8=CB: rbridge-bounces@postel.org **** > > 2012-02-23 11:55 **** > > =CA=D5=BC=FE=C8=CB**** > > **** > > =B3=AD=CB=CD**** > > =D6=F7=CC=E2**** > > [rbridge] Default nickname base approach for multilevel TRILL- > draft-tissa-trill-multilevel-00.txt**** > > ** ** > > > > > Dear All > > We have submitted draft-tissa-trill-multilevel, present multilevel TRILL > based on default nickname approach. Additionally we discuss construction = of > multi-destination trees and related RPF in multilevel TRILL. Please could > you review and comment > > Detail of the draft and abstract are below. > > Filename: draft-tissa-trill-multilevel > Revision: 00 > Title: Default Nickname Based Approach > for Multilevel TRILL > Creation date: 2012-02-21 > WG ID: Individual Submission > Number of pages: 26 > > Abstract: > Multilevel TRILL allows the interconnection of multiple TRILL > networks to form a larger TRILL network without proportionally > increasing the size of the IS-IS LSP DB. In this document, an > approach based on default route concept is presented. Also, > presented in the document is a novel method of constructing multi- > destination trees using partial nickname space. Methods presented in > this document are compatible with the RFC6325 specified data plane > operations. > > > > Thanks > Tissa > > _______________________________________________ > 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**** > > ** ** > --0015174bf1ec56132c04b9b8c31d Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
I don't understand how multi-topology helps with the nickname exha= ustion issue.  As a matter of fact, the only plausible way of marking = a packet for which topology that has been suggested on the mailing list (I = asked a efw times if there were any other possibilities), was to steal 2 or= 3 bits of the nickname to encode which topology, in effect, making a desti= nation appear as multiple destinations and multiple forwarding table entrie= s (which you'd want anyway, for multitopology).
 
 
Radia

2012/2/24 Tissa Senevirathne (tsenevir) <tsenevir@cisco.com&= gt;

Mutli-topology is the answer to= increase the nickname space.

 

Nickname translation is very si= milar to NAT, which has it’s own down side, not to mention special ha= rdware etc. to do the translations, additionally. We also know from our exp= erience, in IP world NATing is not the most desired behavior and we live wi= th it. So we should not be going down that path instead need to look forwar= d from that experience.

 

Multi-topology not only address= nickname space issue but also enables various other applications such as o= verlay topologies, traffic engineering.

 

The draft-tiss-trill-multilevel= present approaches that are generic, which mean it can be applied for mult= i-topology, or base topology. It utilizes the fundamentals of IS-IS , such = as Area hierarchy for reduction of the LSP-DB. It utilize affinity TLV conc= epts to effectively solve multi-destination issues.

 

We should not mix-up between Da= ta center interconnects with data center node scaling. They are two differe= nt and orthogonal issues.

 

Objective of multi-level trill = is to interconnect different datacenters, and maintain LSP-DB small as poss= ible to avoid scaling and volatility.

 

Increasing nickname space a dif= ferent requirement and has nothing to do with data-center interconnects.=

 

 

From: Radia Perlman [mailt= o:radiaperlman@= gmail.com]
Sent: Friday, February 24, 2012 6:15 AM
To: hu.fangwei@zte.com.cn
<= b>Cc: Tissa Senevirathne (tsenevir); rbridge@postel.org; rbridge-bounces@postel.org
Subject: Re: [rbridge] Default nickname base approach for multilevel= TRILL- draft-tissa-trill-multilevel-00.txt

 

People have mentioned to me that they are nervous ab= out running out of nicknames, especially since there are reasonson why they= might want to assign nicknames to hypervisors.  With the alternate ap= proach of allowing nicknames to be reused in different areas, it makes auto= matic nickname assignment much simpler and makes TRILL a lot more scalable.=

 

It does have the downside of requiring mapping of ni= cknames at the border RBridges.

 

And by the way, the affinity TLV can be used for mul= tidestination frames transiting between level 1 and level 2.<= /p>

 

Radia

=

2012/2/23 <hu.fangwei@zte.com.cn>


Hi, Tissa.

I have severa= l comments about the draft.

(1) in= section 4.4 (Multicast), "The scope of global traffic may be identifi= ed either through VLAN or via finegrain
label that spans across the entire= TRILL campus."
Vlan and F= ine-grain Label is used for service differentiation and isolation. I do not= quite understand that how to
use VLAN and fine-grain Lable to identify th= e traffic scope. The data traffic with a given VLAN-x, can
be forward= ed to other end station in the local area, or to the end station in remote = areas.

(2) nickname allocation
The nickna= me management sub-TLV is proposed in the document. I wonder this mechanism = adds the complication of  
nickname allocation. As the section 1 (int= roduction) of RFC6325, one of the important advantage of TRILL is that &nbs= p;
it avoids = the creating subnets of IP address and wasting address. The nickname acquis= ition  method in this draft violates the  
idea of TRILL Basic s= pecification, and reduces the flexibility of nickname allocation. As the dr= aft assumed, A1 had  
nickname r= ange of 100-200, A2 has a local nickname range of 201-300. If the numbers o= f A1 area is only 50, so 50  
nicknames in A1 is wasted. As the netwo= rk growing, the number of some areas may exceed the number being allocation=  
by Border = RBridges. The design and maintaining of nickname ranges for each area is a = very hard work. Even worst, it  
can not avoid to waste nickname spac= e.

(3) Dy= namic ranges
 The nickname range is divided into two range: local ran= ge and dynamical range. I wonder the nickname conflict  
resolution= can not work if the RBridge get the nickname from the dynamical range whil= e the two RBridge belongs to  
different areas. For example, RB1 is i= n area A1, and RB2 is in area A2. If RB1 gets the nickname N1 from dynamic =  
range, and= it will floods in area A1, and other RBridges in area A1 can not get nickn= ame N1 because of nickname  
confliction mechanism, but RB2 in area A= 2 can not receive the PDU from RB1, and it  can also get the nickname = N1 from  
dynamical = range. So the question is how to avoid the duplication dynamical range nick= name for different areas.

(4) The risk of running out of nickname mayb= e a issue for TRILL. The number of 2**16 nickname is enough for the current= data center,
 but = it maybe not enough in the future, especailly if TRILL over IP , TRILL over= MPLS technology or some other data center technologies
 are deployed= , the data center network can be a very lardge network. So i think the very= important and essential goal of multi-level draft is to save nicknames.

Best r= egards
Fangwei Hu


"Tissa Senevirathne (tsenevir)" &= lt;tsenevir@cisco.c= om>
=B7=A2=BC=FE=C8=CB:  = rbridge-bounces@postel.org

2012-02-23 11:55

=CA=D5=BC=FE=C8=CB

<rbridge@postel.org>

=B3=AD=CB=CD

=

=D6=F7=CC=E2

=

[rbridge] Default nickname base approach for m= ultilevel TRILL-        draft-tissa-trill-multilevel-00= .txt

 




Dear Al= l

We have submitted draft-tissa-trill-multilevel, present m= ultilevel TRILL based on default nickname approach. Additionally we discuss= construction of multi-destination trees and related RPF in multilevel TRIL= L. Please could you review and comment

Detail of the draft and abstract are below.

Filenam= e:                  draft-tiss= a-trill-multilevel
Revision:          =        00
Title:       &nbs= p;                     &n= bsp;     Default Nickname Based Approach for Multilevel TRILL
Creation date:                 =  2012-02-21
WG ID:           &nbs= p;                     &n= bsp; Individual Submission
Number of pages: 26

= Abstract:
  Multilevel TRILL allows the interconnection of= multiple TRILL
  networks to form a larger TRILL network without proportionally
  increasing the size of the IS-IS LSP DB. In this document= , an
  approach based on default route concept is presente= d. Also,
  presented in the document is a novel method of constructing mult= i-
  destination trees using partial nickname space. Metho= ds presented in
  this document are compatible with the RF= C6325 specified data plane
  operations.

          &= nbsp;                    =                     &nbs= p;                     &n= bsp;      
Thanks
Tissa

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


___________________= ____________________________
rbridge mailing list
rbridge@postel.org
http:/= /mailman.postel.org/mailman/listinfo/rbridge

 


--0015174bf1ec56132c04b9b8c31d-- --===============0950711893== 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 --===============0950711893==-- From rbridge-bounces@postel.org Fri Feb 24 10:03:02 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 B3FAC21F87E3 for ; Fri, 24 Feb 2012 10:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.068 X-Spam-Level: X-Spam-Status: No, score=-4.068 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 lOe7ArbTH-fS for ; Fri, 24 Feb 2012 10:02:56 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 4C64221F87CF for ; Fri, 24 Feb 2012 10:02:56 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1OHNtH5014906; Fri, 24 Feb 2012 09:23:57 -0800 (PST) Received: from mail-ey0-f180.google.com (mail-ey0-f180.google.com [209.85.215.180]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1OHN8uX014498 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 24 Feb 2012 09:23:17 -0800 (PST) Received: by eaad14 with SMTP id d14so1215911eaa.39 for ; Fri, 24 Feb 2012 09:23:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MyrhkNr9FwXWIUbK8Mtv+DwUfmD3pqZKvEraaQZUjsE=; b=Wx8Dow+mHc8ZC2Yshrl9KrUXNthEem7+CiCruLelJK2PFtQHwEVF4fh+H83K8AMxai c62N5HBCE0Ri40zlP3rJskdT6EVaABaH+8RAOR+JYtWozWBPtFFxXAhWZFLbOZiwH28I xBDhKFFR7wsxhkOsZ1CNRQ1E5B9IdN2Vb8UpQ= MIME-Version: 1.0 Received: by 10.14.28.142 with SMTP id g14mr1492859eea.86.1330104187371; Fri, 24 Feb 2012 09:23:07 -0800 (PST) Received: by 10.213.28.14 with HTTP; Fri, 24 Feb 2012 09:23:06 -0800 (PST) In-Reply-To: <344037D7CFEFE84E97E9CC1F56C5F4A5A46325@xmb-sjc-214.amer.cisco.com> References: <344037D7CFEFE84E97E9CC1F56C5F4A5A45E88@xmb-sjc-214.amer.cisco.com> <344037D7CFEFE84E97E9CC1F56C5F4A5A462E7@xmb-sjc-214.amer.cisco.com> <344037D7CFEFE84E97E9CC1F56C5F4A5A46325@xmb-sjc-214.amer.cisco.com> Date: Fri, 24 Feb 2012 09:23:06 -0800 Message-ID: From: Radia Perlman To: "Tissa Senevirathne (tsenevir)" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radiaperlman@gmail.com Cc: rbridge@postel.org, rbridge-bounces@postel.org, hu.fangwei@zte.com.cn Subject: Re: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.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: multipart/mixed; boundary="===============0689288538==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org --===============0689288538== Content-Type: multipart/alternative; boundary=bcaec52be6ab9a412704b9b90322 --bcaec52be6ab9a412704b9b90322 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable I assume that all RBridges will need to be in all topologies, so multitopology will not help with nickname exhaustion. Plus you haven't explained how a TRILL packet would be marked as to which topology the packet should be routed according to (other than what I mentioned, which actually eats up nicknames by a factor of the number of topologies supported). Plus, rather than just lumping potential issues into a phrase such as "NAT-like", be explicit about what issues there actually are. I believe the Fulcrum chip would have no problem with translating the nickname fields= . And rather than assuming that nickname exhaustion can be solved "some other way", there should be a palatable solution before rejecting a chance to solve it with multilevel. Radia 2012/2/24 Tissa Senevirathne (tsenevir) > Because you can have same nickname for different topology. It is not a > nickname that will identify an RBRidge, it is topology,nickname combinati= on > that will identify an RBRidge. So RB1 can have nickname 1 in topo-1 and R= B2 > can have nickname 1 in topo2. Now total nicknames in the campus is 2**16 = x > topologies.**** > > ** ** > > Stealing bits to represent topo id is only a workaround there can be (are > ) more elegant ways of doing it that.**** > > ** ** > > Bottom line is we need to look for more creative methods of solving > nickname space issue than doing NAT like behavior. **** > > ** ** > > *From:* Radia Perlman [mailto:radiaperlman@gmail.com] > *Sent:* Friday, February 24, 2012 9:05 AM > *To:* Tissa Senevirathne (tsenevir) > *Cc:* hu.fangwei@zte.com.cn; rbridge@postel.org; > rbridge-bounces@postel.org > > *Subject:* Re: [rbridge] Default nickname base approach for multilevel > TRILL- draft-tissa-trill-multilevel-00.txt**** > > ** ** > > I don't understand how multi-topology helps with the nickname exhaustion > issue. As a matter of fact, the only plausible way of marking a packet f= or > which topology that has been suggested on the mailing list (I asked a efw > times if there were any other possibilities), was to steal 2 or 3 bits of > the nickname to encode which topology, in effect, making a destination > appear as multiple destinations and multiple forwarding table entries > (which you'd want anyway, for multitopology).**** > > **** > > **** > > Radia**** > > 2012/2/24 Tissa Senevirathne (tsenevir) **** > > Mutli-topology is the answer to increase the nickname space.**** > > **** > > Nickname translation is very similar to NAT, which has it=A1=AFs own down= side, > not to mention special hardware etc. to do the translations, additionally= . > We also know from our experience, in IP world NATing is not the most > desired behavior and we live with it. So we should not be going down that > path instead need to look forward from that experience.**** > > **** > > Multi-topology not only address nickname space issue but also enables > various other applications such as overlay topologies, traffic engineerin= g. > **** > > **** > > The draft-tiss-trill-multilevel present approaches that are generic, whic= h > mean it can be applied for multi-topology, or base topology. It utilizes > the fundamentals of IS-IS , such as Area hierarchy for reduction of the > LSP-DB. It utilize affinity TLV concepts to effectively solve > multi-destination issues. **** > > **** > > We should not mix-up between Data center interconnects with data center > node scaling. They are two different and orthogonal issues.**** > > **** > > Objective of multi-level trill is to interconnect different datacenters, > and maintain LSP-DB small as possible to avoid scaling and volatility.***= * > > **** > > Increasing nickname space a different requirement and has nothing to do > with data-center interconnects.**** > > **** > > **** > > *From:* Radia Perlman [mailto:radiaperlman@gmail.com] > *Sent:* Friday, February 24, 2012 6:15 AM > *To:* hu.fangwei@zte.com.cn > *Cc:* Tissa Senevirathne (tsenevir); rbridge@postel.org; > rbridge-bounces@postel.org > *Subject:* Re: [rbridge] Default nickname base approach for multilevel > TRILL- draft-tissa-trill-multilevel-00.txt**** > > **** > > People have mentioned to me that they are nervous about running out of > nicknames, especially since there are reasonson why they might want to > assign nicknames to hypervisors. With the alternate approach of allowing > nicknames to be reused in different areas, it makes automatic nickname > assignment much simpler and makes TRILL a lot more scalable.**** > > **** > > It does have the downside of requiring mapping of nicknames at the border > RBridges.**** > > **** > > And by the way, the affinity TLV can be used for multidestination frames > transiting between level 1 and level 2.**** > > **** > > Radia**** > > 2012/2/23 **** > > > Hi, Tissa. > > I have several comments about the draft. > > (1) in section 4.4 (Multicast), "The scope of global traffic may be > identified either through VLAN or via finegrain > label that spans across the entire TRILL campus." > Vlan and Fine-grain Label is used for service differentiation and > isolation. I do not quite understand that how to > use VLAN and fine-grain Lable to identify the traffic scope. The data > traffic with a given VLAN-x, can > be forwarded to other end station in the local area, or to the end statio= n > in remote areas. > > (2) nickname allocation > The nickname management sub-TLV is proposed in the document. I wonder thi= s > mechanism adds the complication of > nickname allocation. As the section 1 (introduction) of RFC6325, one of > the important advantage of TRILL is that > it avoids the creating subnets of IP address and wasting address. The > nickname acquisition method in this draft violates the > idea of TRILL Basic specification, and reduces the flexibility of nicknam= e > allocation. As the draft assumed, A1 had > nickname range of 100-200, A2 has a local nickname range of 201-300. If > the numbers of A1 area is only 50, so 50 > nicknames in A1 is wasted. As the network growing, the number of some > areas may exceed the number being allocation > by Border RBridges. The design and maintaining of nickname ranges for eac= h > area is a very hard work. Even worst, it > can not avoid to waste nickname space. > > (3) Dynamic ranges > The nickname range is divided into two range: local range and dynamical > range. I wonder the nickname conflict > resolution can not work if the RBridge get the nickname from the dynamica= l > range while the two RBridge belongs to > different areas. For example, RB1 is in area A1, and RB2 is in area A2. I= f > RB1 gets the nickname N1 from dynamic > range, and it will floods in area A1, and other RBridges in area A1 can > not get nickname N1 because of nickname > confliction mechanism, but RB2 in area A2 can not receive the PDU from > RB1, and it can also get the nickname N1 from > dynamical range. So the question is how to avoid the duplication dynamica= l > range nickname for different areas. > > (4) The risk of running out of nickname maybe a issue for TRILL. The > number of 2**16 nickname is enough for the current data center, > but it maybe not enough in the future, especailly if TRILL over IP , > TRILL over MPLS technology or some other data center technologies > are deployed, the data center network can be a very lardge network. So i > think the very important and essential goal of multi-level draft is to sa= ve > nicknames. > > Best regards > Fangwei Hu > > **** > > *"Tissa Senevirathne (tsenevir)" * > =B7=A2=BC=FE=C8=CB: rbridge-bounces@postel.org **** > > 2012-02-23 11:55 **** > > =CA=D5=BC=FE=C8=CB**** > > **** > > =B3=AD=CB=CD**** > > =D6=F7=CC=E2**** > > [rbridge] Default nickname base approach for multilevel TRILL- > draft-tissa-trill-multilevel-00.txt**** > > **** > > > > > Dear All > > We have submitted draft-tissa-trill-multilevel, present multilevel TRILL > based on default nickname approach. Additionally we discuss construction = of > multi-destination trees and related RPF in multilevel TRILL. Please could > you review and comment > > Detail of the draft and abstract are below. > > Filename: draft-tissa-trill-multilevel > Revision: 00 > Title: Default Nickname Based Approach > for Multilevel TRILL > Creation date: 2012-02-21 > WG ID: Individual Submission > Number of pages: 26 > > Abstract: > Multilevel TRILL allows the interconnection of multiple TRILL > networks to form a larger TRILL network without proportionally > increasing the size of the IS-IS LSP DB. In this document, an > approach based on default route concept is presented. Also, > presented in the document is a novel method of constructing multi- > destination trees using partial nickname space. Methods presented in > this document are compatible with the RFC6325 specified data plane > operations. > > > > Thanks > Tissa > > _______________________________________________ > 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**** > > **** > > ** ** > --bcaec52be6ab9a412704b9b90322 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
I assume that all RBridges will need to be in all topologies, so = multitopology will not help with nickname exhaustion.  Plus you haven&= #39;t explained how a TRILL packet would be marked as to which topology the= packet should be routed according to (other than what I mentioned, which a= ctually eats up nicknames by a factor of the number of topologies supported= ).
 
Plus, rather than just lumping potential issues into a phrase such as = "NAT-like", be explicit about what issues there actually are.&nbs= p; I believe the Fulcrum chip would have no problem with translating the ni= ckname fields.
 
And rather than assuming that nickname exhaustion can be solved "= some other way", there should be a palatable solution before rejecting= a chance to solve it with multilevel.
 
Radia

2012/2/24 Tissa Senevirathne (tsenevir) <tsenevir@cisco.com&= gt;

Because you can have same nickn= ame for different topology. It is not a nickname that will identify an RBRi= dge, it is topology,nickname combination that will identify an RBRidge. So = RB1 can have nickname 1 in topo-1 and RB2 can have nickname 1 in topo2. Now= total nicknames in the campus is 2**16 x topologies.<= /p>

 

Stealing bits to represent topo= id is only a workaround there can be (are ) more elegant ways of doing it = that.

 

Bottom line is we need to look = for more creative methods of solving nickname space issue than doing NAT li= ke behavior.

 

From: Radia Perlman [mailt= o:radiaperlman@= gmail.com]
Sent: Friday, February 24, 2012 9:05 AM
To: Tissa Senevira= thne (tsenevir)
Cc: hu.fangwei@zte.com.cn; rbridge@postel.org; rbridge-bounces@postel.org=20


Subject: Re: [rbridge] Default nickname base a= pproach for multilevel TRILL- draft-tissa-trill-multilevel-00.txt=

 

I don't understand how multi-topology helps with= the nickname exhaustion issue.  As a matter of fact, the only plausib= le way of marking a packet for which topology that has been suggested on th= e mailing list (I asked a efw times if there were any other possibilities),= was to steal 2 or 3 bits of the nickname to encode which topology, in effe= ct, making a destination appear as multiple destinations and multiple forwa= rding table entries (which you'd want anyway, for multitopology).

 

 

Radia

=

2012/2/24 Tissa Senevirathne (tsenevir) <tsenevir@cisco.com>=

Mutli-topology is the answer to= increase the nickname space.

 

Nickname translation is very si= milar to NAT, which has it’s own down side, not to mention special ha= rdware etc. to do the translations, additionally. We also know from our exp= erience, in IP world NATing is not the most desired behavior and we live wi= th it. So we should not be going down that path instead need to look forwar= d from that experience.

 

Multi-topology not only address= nickname space issue but also enables various other applications such as o= verlay topologies, traffic engineering.

 

The draft-tiss-trill-multilevel= present approaches that are generic, which mean it can be applied for mult= i-topology, or base topology. It utilizes the fundamentals of IS-IS , such = as Area hierarchy for reduction of the LSP-DB. It utilize affinity TLV conc= epts to effectively solve multi-destination issues.

 

We should not mix-up between Da= ta center interconnects with data center node scaling. They are two differe= nt and orthogonal issues.

 

Objective of multi-level trill = is to interconnect different datacenters, and maintain LSP-DB small as poss= ible to avoid scaling and volatility.

 

Increasing nickname space a dif= ferent requirement and has nothing to do with data-center interconnects.

 

 

From: Radia Perlman [mailt= o:radiaperlman@= gmail.com]
Sent: Friday, February 24, 2012 6:15 AM
To: hu.fangwei@zte.com.cn
<= b>Cc: Tissa Senevirathne (tsenevir); rbridge@postel.org; rbridge-bounces@postel.org
Subject: Re: [rbridge] Default nickname base approach for multilevel= TRILL- draft-tissa-trill-multilevel-00.txt

 

People have mentioned to me that they are nervous ab= out running out of nicknames, especially since there are reasonson why they= might want to assign nicknames to hypervisors.  With the alternate ap= proach of allowing nicknames to be reused in different areas, it makes auto= matic nickname assignment much simpler and makes TRILL a lot more scalable.=

 

It does have the downside of requiring mapping of ni= cknames at the border RBridges.

 

And by the way, the affinity TLV can be used for mul= tidestination frames transiting between level 1 and level 2.<= /p>

 

Radia

=

2012/2/23 <hu.fangwei@zte.com.cn>


Hi, Tissa.

I have severa= l comments about the draft.

(1) in= section 4.4 (Multicast), "The scope of global traffic may be identifi= ed either through VLAN or via finegrain
label that spans across the entire= TRILL campus."
Vlan and F= ine-grain Label is used for service differentiation and isolation. I do not= quite understand that how to
use VLAN and fine-grain Lable to identify th= e traffic scope. The data traffic with a given VLAN-x, can
be forward= ed to other end station in the local area, or to the end station in remote = areas.

(2) nickname allocation
The nickna= me management sub-TLV is proposed in the document. I wonder this mechanism = adds the complication of  
nickname allocation. As the section 1 (int= roduction) of RFC6325, one of the important advantage of TRILL is that &nbs= p;
it avoids = the creating subnets of IP address and wasting address. The nickname acquis= ition  method in this draft violates the  
idea of TRILL Basic s= pecification, and reduces the flexibility of nickname allocation. As the dr= aft assumed, A1 had  
nickname r= ange of 100-200, A2 has a local nickname range of 201-300. If the numbers o= f A1 area is only 50, so 50  
nicknames in A1 is wasted. As the netwo= rk growing, the number of some areas may exceed the number being allocation=  
by Border = RBridges. The design and maintaining of nickname ranges for each area is a = very hard work. Even worst, it  
can not avoid to waste nickname spac= e.

(3) Dy= namic ranges
 The nickname range is divided into two range: local ran= ge and dynamical range. I wonder the nickname conflict  
resolution= can not work if the RBridge get the nickname from the dynamical range whil= e the two RBridge belongs to  
different areas. For example, RB1 is i= n area A1, and RB2 is in area A2. If RB1 gets the nickname N1 from dynamic =  
range, and= it will floods in area A1, and other RBridges in area A1 can not get nickn= ame N1 because of nickname  
confliction mechanism, but RB2 in area A= 2 can not receive the PDU from RB1, and it  can also get the nickname = N1 from  
dynamical = range. So the question is how to avoid the duplication dynamical range nick= name for different areas.

(4) The risk of running out of nickname mayb= e a issue for TRILL. The number of 2**16 nickname is enough for the current= data center,
 but = it maybe not enough in the future, especailly if TRILL over IP , TRILL over= MPLS technology or some other data center technologies
 are deployed= , the data center network can be a very lardge network. So i think the very= important and essential goal of multi-level draft is to save nicknames.

Best r= egards
Fangwei Hu

"Tissa Senevirathne (tsenevir)" &= lt;tsenevir@cisco.c= om>
=B7=A2=BC=FE=C8=CB:  = rbridge-bounces@postel.org

2012-02-23 11:55

=CA=D5=BC=FE=C8=CB

<rbridge@postel.org>

=B3=AD=CB=CD

=

=D6=F7=CC=E2

=

[rbridge] Default nickname base approach for m= ultilevel TRILL-        draft-tissa-trill-multilevel-00= .txt

 




Dear Al= l

We have submitted draft-tissa-trill-multilevel, present m= ultilevel TRILL based on default nickname approach. Additionally we discuss= construction of multi-destination trees and related RPF in multilevel TRIL= L. Please could you review and comment

Detail of the draft and abstract are below.

Filenam= e:                  draft-tiss= a-trill-multilevel
Revision:          =        00
Title:       &nbs= p;                     &n= bsp;     Default Nickname Based Approach for Multilevel TRILL
Creation date:                 =  2012-02-21
WG ID:           &nbs= p;                     &n= bsp; Individual Submission
Number of pages: 26

= Abstract:
  Multilevel TRILL allows the interconnection of= multiple TRILL
  networks to form a larger TRILL network without proportionally
  increasing the size of the IS-IS LSP DB. In this document= , an
  approach based on default route concept is presente= d. Also,
  presented in the document is a novel method of constructing mult= i-
  destination trees using partial nickname space. Metho= ds presented in
  this document are compatible with the RF= C6325 specified data plane
  operations.

          &= nbsp;                    =                     &nbs= p;                     &n= bsp;      
Thanks
Tissa

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


___________________= ____________________________
rbridge mailing list
rbridge@postel.org
http:/= /mailman.postel.org/mailman/listinfo/rbridge

 

 


--bcaec52be6ab9a412704b9b90322-- --===============0689288538== 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 --===============0689288538==-- From rbridge-bounces@postel.org Fri Feb 24 10:23: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 C42D721F8836 for ; Fri, 24 Feb 2012 10:23:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.978 X-Spam-Level: X-Spam-Status: No, score=-4.978 tagged_above=-999 required=5 tests=[AWL=-0.831, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 O6C0hkRvWYz9 for ; Fri, 24 Feb 2012 10:23:21 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 5A94321F8835 for ; Fri, 24 Feb 2012 10:23:19 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1OHF5NS012890; Fri, 24 Feb 2012 09:15:06 -0800 (PST) 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 q1OHEHBO012797 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 24 Feb 2012 09:14:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tsenevir@cisco.com; l=31979; q=dns/txt; s=iport; t=1330103666; x=1331313266; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=oBKJ0hn11QLdPNwgH8oXjME6GOjV4Li4Fpa7RXE64wE=; b=KcOzu2cxEDLkJyD11K9L4GxcmK2zPJtwmc1oVEZJYL7/OW3AJPUUViOv Zo5ySXzd60C3/I3kYzlR74CkKyjK+dAp6w+tjbpkXtLymhTfpKDmP0BJo tV6ww0NR68uMzjdNj+N3Mb1zJi6zVO6onS7bCCYISM7wMf+Ba5WZpxF35 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFALzER0+rRDoJ/2dsb2JhbAA5CoJRgmmkUgGJC4EHgXMBAQEEAQEBDwEJEQM+CxACAQYCEQQBAQsGEAECBAEEAgEgBh8JCAEBBBMIGodjAQugNgGMXwiKEYkOYYMNAgIFAQQBAgQCAQEDCA0HAkiEZwEEGSMeBwQEAgMFAwQBFAYaDAOCEzdjBIhPmASHeIEyBQ X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208,217";a="32296359" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 24 Feb 2012 17:14:16 +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 q1OHEGOW010932; Fri, 24 Feb 2012 17:14:16 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, 24 Feb 2012 09:14:16 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 24 Feb 2012 09:14:15 -0800 Message-ID: <344037D7CFEFE84E97E9CC1F56C5F4A5A46325@xmb-sjc-214.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.txt Thread-Index: AczzFnpFErfB/iHHSkinYlm0xfhmCgAAEIsQ References: <344037D7CFEFE84E97E9CC1F56C5F4A5A45E88@xmb-sjc-214.amer.cisco.com><344037D7CFEFE84E97E9CC1F56C5F4A5A462E7@xmb-sjc-214.amer.cisco.com> From: "Tissa Senevirathne (tsenevir)" To: "Radia Perlman" X-OriginalArrivalTime: 24 Feb 2012 17:14:16.0615 (UTC) FILETIME=[BCE9FB70:01CCF317] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: tsenevir@cisco.com Cc: rbridge@postel.org, rbridge-bounces@postel.org, hu.fangwei@zte.com.cn Subject: Re: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.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: multipart/mixed; boundary="===============0628662299==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org This is a multi-part message in MIME format. --===============0628662299== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCF317.BC9E7C5E" This is a multi-part message in MIME format. ------_=_NextPart_001_01CCF317.BC9E7C5E Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable Because you can have same nickname for different topology. It is not a = nickname that will identify an RBRidge, it is topology,nickname = combination that will identify an RBRidge. So RB1 can have nickname 1 in = topo-1 and RB2 can have nickname 1 in topo2. Now total nicknames in the = campus is 2**16 x topologies. =20 Stealing bits to represent topo id is only a workaround there can be = (are ) more elegant ways of doing it that. =20 Bottom line is we need to look for more creative methods of solving = nickname space issue than doing NAT like behavior.=20 =20 From: Radia Perlman [mailto:radiaperlman@gmail.com]=20 Sent: Friday, February 24, 2012 9:05 AM To: Tissa Senevirathne (tsenevir) Cc: hu.fangwei@zte.com.cn; rbridge@postel.org; = rbridge-bounces@postel.org Subject: Re: [rbridge] Default nickname base approach for multilevel = TRILL- draft-tissa-trill-multilevel-00.txt =20 I don't understand how multi-topology helps with the nickname exhaustion = issue. As a matter of fact, the only plausible way of marking a packet = for which topology that has been suggested on the mailing list (I asked = a efw times if there were any other possibilities), was to steal 2 or 3 = bits of the nickname to encode which topology, in effect, making a = destination appear as multiple destinations and multiple forwarding = table entries (which you'd want anyway, for multitopology). =20 =20 Radia 2012/2/24 Tissa Senevirathne (tsenevir) Mutli-topology is the answer to increase the nickname space. =20 Nickname translation is very similar to NAT, which has it=A1=AFs own = down side, not to mention special hardware etc. to do the translations, = additionally. We also know from our experience, in IP world NATing is = not the most desired behavior and we live with it. So we should not be = going down that path instead need to look forward from that experience. =20 Multi-topology not only address nickname space issue but also enables = various other applications such as overlay topologies, traffic = engineering. =20 The draft-tiss-trill-multilevel present approaches that are generic, = which mean it can be applied for multi-topology, or base topology. It = utilizes the fundamentals of IS-IS , such as Area hierarchy for = reduction of the LSP-DB. It utilize affinity TLV concepts to effectively = solve multi-destination issues.=20 =20 We should not mix-up between Data center interconnects with data center = node scaling. They are two different and orthogonal issues. =20 Objective of multi-level trill is to interconnect different datacenters, = and maintain LSP-DB small as possible to avoid scaling and volatility. =20 Increasing nickname space a different requirement and has nothing to do = with data-center interconnects. =20 =20 From: Radia Perlman [mailto:radiaperlman@gmail.com]=20 Sent: Friday, February 24, 2012 6:15 AM To: hu.fangwei@zte.com.cn Cc: Tissa Senevirathne (tsenevir); rbridge@postel.org; = rbridge-bounces@postel.org Subject: Re: [rbridge] Default nickname base approach for multilevel = TRILL- draft-tissa-trill-multilevel-00.txt =20 People have mentioned to me that they are nervous about running out of = nicknames, especially since there are reasonson why they might want to = assign nicknames to hypervisors. With the alternate approach of = allowing nicknames to be reused in different areas, it makes automatic = nickname assignment much simpler and makes TRILL a lot more scalable. =20 It does have the downside of requiring mapping of nicknames at the = border RBridges. =20 And by the way, the affinity TLV can be used for multidestination frames = transiting between level 1 and level 2. =20 Radia 2012/2/23 Hi, Tissa.=20 I have several comments about the draft.=20 (1) in section 4.4 (Multicast), "The scope of global traffic may be = identified either through VLAN or via finegrain=20 label that spans across the entire TRILL campus."=20 Vlan and Fine-grain Label is used for service differentiation and = isolation. I do not quite understand that how to=20 use VLAN and fine-grain Lable to identify the traffic scope. The data = traffic with a given VLAN-x, can=20 be forwarded to other end station in the local area, or to the end = station in remote areas.=20 (2) nickname allocation=20 The nickname management sub-TLV is proposed in the document. I wonder = this mechanism adds the complication of =20 nickname allocation. As the section 1 (introduction) of RFC6325, one of = the important advantage of TRILL is that =20 it avoids the creating subnets of IP address and wasting address. The = nickname acquisition method in this draft violates the =20 idea of TRILL Basic specification, and reduces the flexibility of = nickname allocation. As the draft assumed, A1 had =20 nickname range of 100-200, A2 has a local nickname range of 201-300. If = the numbers of A1 area is only 50, so 50 =20 nicknames in A1 is wasted. As the network growing, the number of some = areas may exceed the number being allocation =20 by Border RBridges. The design and maintaining of nickname ranges for = each area is a very hard work. Even worst, it =20 can not avoid to waste nickname space.=20 (3) Dynamic ranges=20 The nickname range is divided into two range: local range and dynamical = range. I wonder the nickname conflict =20 resolution can not work if the RBridge get the nickname from the = dynamical range while the two RBridge belongs to =20 different areas. For example, RB1 is in area A1, and RB2 is in area A2. = If RB1 gets the nickname N1 from dynamic =20 range, and it will floods in area A1, and other RBridges in area A1 can = not get nickname N1 because of nickname =20 confliction mechanism, but RB2 in area A2 can not receive the PDU from = RB1, and it can also get the nickname N1 from =20 dynamical range. So the question is how to avoid the duplication = dynamical range nickname for different areas.=20 (4) The risk of running out of nickname maybe a issue for TRILL. The = number of 2**16 nickname is enough for the current data center,=20 but it maybe not enough in the future, especailly if TRILL over IP , = TRILL over MPLS technology or some other data center technologies=20 are deployed, the data center network can be a very lardge network. So = i think the very important and essential goal of multi-level draft is to = save nicknames.=20 Best regards=20 Fangwei Hu "Tissa Senevirathne (tsenevir)" =20 =B7=A2=BC=FE=C8=CB: rbridge-bounces@postel.org=20 2012-02-23 11:55=20 =CA=D5=BC=FE=C8=CB =20 =B3=AD=CB=CD =09 =D6=F7=CC=E2 [rbridge] Default nickname base approach for multilevel TRILL- = draft-tissa-trill-multilevel-00.txt =20 =09 =09 Dear All We have submitted draft-tissa-trill-multilevel, present multilevel TRILL = based on default nickname approach. Additionally we discuss construction = of multi-destination trees and related RPF in multilevel TRILL. Please = could you review and comment=20 Detail of the draft and abstract are below. Filename: draft-tissa-trill-multilevel Revision: 00 Title: Default Nickname Based Approach = for Multilevel TRILL Creation date: 2012-02-21 WG ID: Individual Submission Number of pages: 26 Abstract: Multilevel TRILL allows the interconnection of multiple TRILL networks to form a larger TRILL network without proportionally increasing the size of the IS-IS LSP DB. In this document, an approach based on default route concept is presented. Also, presented in the document is a novel method of constructing multi- destination trees using partial nickname space. Methods presented in this document are compatible with the RFC6325 specified data plane operations. = =20 Thanks Tissa _______________________________________________ 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 =20 =20 ------_=_NextPart_001_01CCF317.BC9E7C5E Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable

Because you can have same nickname for different topology. It is not = a nickname that will identify an RBRidge, it is topology,nickname = combination that will identify an RBRidge. So RB1 can have nickname 1 in = topo-1 and RB2 can have nickname 1 in topo2. Now total nicknames in the = campus is 2**16 x topologies.

 

Stealing bits to represent topo id is only a workaround there can be = (are ) more elegant ways of doing it that.

 

Bottom line is we need to look for more creative methods of solving = nickname space issue than doing NAT like behavior. =

 

From:= = Radia Perlman [mailto:radiaperlman@gmail.com]
Sent: Friday, = February 24, 2012 9:05 AM
To: Tissa Senevirathne = (tsenevir)
Cc: hu.fangwei@zte.com.cn; rbridge@postel.org; = rbridge-bounces@postel.org
Subject: Re: [rbridge] Default = nickname base approach for multilevel TRILL- = draft-tissa-trill-multilevel-00.txt

 

I don't = understand how multi-topology helps with the nickname exhaustion = issue.  As a matter of fact, the only plausible way of marking a = packet for which topology that has been suggested on the mailing list (I = asked a efw times if there were any other possibilities), was to steal 2 = or 3 bits of the nickname to encode which topology, in effect, making a = destination appear as multiple destinations and multiple forwarding = table entries (which you'd want anyway, for = multitopology).

 

 

Radia

2012/2/24 Tissa Senevirathne (tsenevir) <tsenevir@cisco.com><= /p>

Mutli-topology is the answer to increase the nickname = space.

 

Nickname translation is very similar to NAT, which has it=A1=AFs own = down side, not to mention special hardware etc. to do the translations, = additionally. We also know from our experience, in IP world NATing is = not the most desired behavior and we live with it. So we should not be = going down that path instead need to look forward from that = experience.

 

Multi-topology not only address nickname space issue but also enables = various other applications such as overlay topologies, traffic = engineering.

 

The draft-tiss-trill-multilevel present approaches that are generic, = which mean it can be applied for multi-topology, or base topology. It = utilizes the fundamentals of IS-IS , such as Area hierarchy for = reduction of the LSP-DB. It utilize affinity TLV concepts to effectively = solve multi-destination issues.

 

We should not mix-up between Data center interconnects with data = center node scaling. They are two different and orthogonal = issues.

 

Objective of multi-level trill is to interconnect different = datacenters, and maintain LSP-DB small as possible to avoid scaling and = volatility.

 

Increasing nickname space a different requirement and has nothing to = do with data-center interconnects.

 

 

From:= = Radia Perlman [mailto:radiaperlman@gmail.com]
Sent: Friday, = February 24, 2012 6:15 AM
To: hu.fangwei@zte.com.cn
Cc: Tissa = Senevirathne (tsenevir); rbridge@postel.org; rbridge-bounces@postel.org
Subject: Re: = [rbridge] Default nickname base approach for multilevel TRILL- = draft-tissa-trill-multilevel-00.txt

=

 <= /o:p>

People have = mentioned to me that they are nervous about running out of nicknames, = especially since there are reasonson why they might want to assign = nicknames to hypervisors.  With the alternate approach of allowing = nicknames to be reused in different areas, it makes automatic nickname = assignment much simpler and makes TRILL a lot more = scalable.

 <= /o:p>

It does = have the downside of requiring mapping of nicknames at the border = RBridges.

 <= /o:p>

And by the = way, the affinity TLV can be used for multidestination frames transiting = between level 1 and level 2.

 <= /o:p>

Radia

2012/2/23 = <hu.fangwei@zte.com.cn>


Hi, Tissa. =

I have several = comments about the draft.

(1) in section 4.4 = (Multicast), "The scope of global traffic may be identified either = through VLAN or via finegrain
label that spans across the = entire TRILL campus."
Vlan and Fine-grain Label is = used for service differentiation and isolation. I do not quite = understand that how to
use VLAN and fine-grain Lable = to identify the traffic scope. The data traffic with a given VLAN-x, can =
be forwarded = to other end station in the local area, or to the end station in remote = areas.

(2) nickname = allocation
The nickname management = sub-TLV is proposed in the document. I wonder this mechanism adds the = complication of  
nickname allocation. As the = section 1 (introduction) of RFC6325, one of the important advantage of = TRILL is that  
it avoids the creating = subnets of IP address and wasting address. The nickname acquisition =  method in this draft violates the  
idea of TRILL Basic = specification, and reduces the flexibility of nickname allocation. As = the draft assumed, A1 had  
nickname range of 100-200, A2 = has a local nickname range of 201-300. If the numbers of A1 area is only = 50, so 50  
nicknames in A1 is wasted. As = the network growing, the number of some areas may exceed the number = being allocation  
by Border RBridges. The = design and maintaining of nickname ranges for each area is a very hard = work. Even worst, it  
can not avoid to waste = nickname space.

(3) Dynamic ranges =
 The = nickname range is divided into two range: local range and dynamical = range. I wonder the nickname conflict  
resolution can not work if = the RBridge get the nickname from the dynamical range while the two = RBridge belongs to  
different areas. For example, = RB1 is in area A1, and RB2 is in area A2. If RB1 gets the nickname N1 = from dynamic  
range, and it will floods in = area A1, and other RBridges in area A1 can not get nickname N1 because = of nickname  
confliction mechanism, but = RB2 in area A2 can not receive the PDU from RB1, and it  can also = get the nickname N1 from  
dynamical range. So the = question is how to avoid the duplication dynamical range nickname for = different areas.

(4) The risk of running out = of nickname maybe a issue for TRILL. The number of 2**16 nickname is = enough for the current data center,
 but it maybe not enough = in the future, especailly if TRILL over IP , TRILL over MPLS technology = or some other data center technologies
 are deployed, the data = center network can be a very lardge network. So i think the very = important and essential goal of multi-level draft is to save = nicknames.

Best regards
Fangwei = Hu

"Tissa = Senevirathne (tsenevir)" <tsenevir@cisco.com> =
=B7=A2=BC=FE=C8=CB:  rbridge-bounces@postel.org =

2012-02-23 = 11:55

<rbridge@postel.org> =

=

=CA=D5=BC=FE=C8=CB

=B3=AD=CB=CD

=D6=F7=CC=E2

[rbridge] = Default nickname base approach for multilevel TRILL-     =   =  draft-tissa-trill-multilevel-00.txt

 <= /o:p>




De= ar All

We have submitted draft-tissa-trill-multilevel, = present multilevel TRILL based on default nickname approach. = Additionally we discuss construction of multi-destination trees and = related RPF in multilevel TRILL. Please could you review and comment =

Detail of the draft and abstract are = below.

Filename:           =       =  draft-tissa-trill-multilevel
Revision:     =              00
Title: =                     =               Default Nickname Based = Approach for Multilevel TRILL
Creation date:     =             =  2012-02-21
WG ID:           =                     =     Individual Submission
Number of pages: = 26

Abstract:
  Multilevel TRILL allows = the interconnection of multiple TRILL
  networks to = form a larger TRILL network without proportionally
  = increasing the size of the IS-IS LSP DB. In this document, = an
  approach based on default route concept is = presented. Also,
  presented in the document is a novel = method of constructing multi-
  destination trees using = partial nickname space. Methods presented in
  this = document are compatible with the RFC6325 specified data = plane
  operations.

    =                     =                     =                     =                 =  
Thanks
Tissa

_____________= __________________________________
rbridge mailing = list
rbridge@postel.org
http://mailman.postel.org/mailman/listinfo/rbridge<= /tt>


______________= _________________________________
rbridge mailing list
rbridge@postel.org
http://mailman.postel.org/mailman/listinfo/rbridge<= o:p>

 <= /o:p>

 

------_=_NextPart_001_01CCF317.BC9E7C5E-- --===============0628662299== 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 --===============0628662299==-- From rbridge-bounces@postel.org Fri Feb 24 10:37:49 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 3CFDB21F871B for ; Fri, 24 Feb 2012 10:37:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.934 X-Spam-Level: X-Spam-Status: No, score=-4.934 tagged_above=-999 required=5 tests=[AWL=-0.787, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 NU7jCHsBUSz5 for ; Fri, 24 Feb 2012 10:37:43 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 62FD121F86C6 for ; Fri, 24 Feb 2012 10:37:43 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1OI0ef9022212; Fri, 24 Feb 2012 10:00:41 -0800 (PST) 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 q1OHxl1p022082 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 24 Feb 2012 09:59:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tsenevir@cisco.com; l=37862; q=dns/txt; s=iport; t=1330106396; x=1331315996; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=QY76JpcPI8mcHVdHu+faYwuiNsElCsvq/GGUpaoyRbw=; b=TpLqB3VZS5ueVilvDzW6DhrYV/KXET7MeibAb43CmPjtj0NTuwrJRsed wbyqQgWM/Sk5klz4O7OjQRTKm6GjImuRQIIiXB5luGTrwWj2nWUGmjS/J tUqVhr9L6xOQ+Ak0KASa2PeZlupj3yk/owvxyoUPhh1Ms5xhI+Nx2+g31 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFABHPR0+rRDoI/2dsb2JhbAA6CoI/gmmkUgGJDIEHgXMBAQEEAQEBDwEJEQM+CxACAQYCEQQBAQsGEAECBAEEAgEgBh8JCAEBBBMIEweHYwELmW4BjF8IkXaJDmGDDQICBQEEAQIEAgEBAwgNBwJIhGcBBBkjHgcEBAIDBQMEARQGGgwDghM3YwSIT5gEh3iBMgU X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208,217";a="32175748" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 24 Feb 2012 17:59: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 q1OHxkeW002028; Fri, 24 Feb 2012 17:59: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); Fri, 24 Feb 2012 09:59:46 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 24 Feb 2012 09:59:45 -0800 Message-ID: <344037D7CFEFE84E97E9CC1F56C5F4A5A46358@xmb-sjc-214.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.txt Thread-Index: AczzGPt0mgzA1RnSQgGsce1THRRoOQABKeiA References: <344037D7CFEFE84E97E9CC1F56C5F4A5A45E88@xmb-sjc-214.amer.cisco.com><344037D7CFEFE84E97E9CC1F56C5F4A5A462E7@xmb-sjc-214.amer.cisco.com><344037D7CFEFE84E97E9CC1F56C5F4A5A46325@xmb-sjc-214.amer.cisco.com> From: "Tissa Senevirathne (tsenevir)" To: "Radia Perlman" X-OriginalArrivalTime: 24 Feb 2012 17:59:46.0801 (UTC) FILETIME=[183B4E10:01CCF31E] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: tsenevir@cisco.com Cc: rbridge@postel.org, rbridge-bounces@postel.org, hu.fangwei@zte.com.cn Subject: Re: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.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: multipart/mixed; boundary="===============0112536213==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org This is a multi-part message in MIME format. --===============0112536213== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCF31E.17EB7B6E" This is a multi-part message in MIME format. ------_=_NextPart_001_01CCF31E.17EB7B6E Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable RBridges do not have to be in all topologies. Why would they should be? =20 What is Fulrcrum chip ?=20 =20 =20 =20 =20 From: Radia Perlman [mailto:radiaperlman@gmail.com]=20 Sent: Friday, February 24, 2012 9:23 AM To: Tissa Senevirathne (tsenevir) Cc: hu.fangwei@zte.com.cn; rbridge@postel.org; = rbridge-bounces@postel.org Subject: Re: [rbridge] Default nickname base approach for multilevel = TRILL- draft-tissa-trill-multilevel-00.txt =20 I assume that all RBridges will need to be in all topologies, so = multitopology will not help with nickname exhaustion. Plus you haven't = explained how a TRILL packet would be marked as to which topology the = packet should be routed according to (other than what I mentioned, which = actually eats up nicknames by a factor of the number of topologies = supported). =20 Plus, rather than just lumping potential issues into a phrase such as = "NAT-like", be explicit about what issues there actually are. I believe = the Fulcrum chip would have no problem with translating the nickname = fields. =20 And rather than assuming that nickname exhaustion can be solved "some = other way", there should be a palatable solution before rejecting a = chance to solve it with multilevel. =20 Radia 2012/2/24 Tissa Senevirathne (tsenevir) Because you can have same nickname for different topology. It is not a = nickname that will identify an RBRidge, it is topology,nickname = combination that will identify an RBRidge. So RB1 can have nickname 1 in = topo-1 and RB2 can have nickname 1 in topo2. Now total nicknames in the = campus is 2**16 x topologies. =20 Stealing bits to represent topo id is only a workaround there can be = (are ) more elegant ways of doing it that. =20 Bottom line is we need to look for more creative methods of solving = nickname space issue than doing NAT like behavior.=20 =20 From: Radia Perlman [mailto:radiaperlman@gmail.com]=20 Sent: Friday, February 24, 2012 9:05 AM To: Tissa Senevirathne (tsenevir) Cc: hu.fangwei@zte.com.cn; rbridge@postel.org; = rbridge-bounces@postel.org=20 Subject: Re: [rbridge] Default nickname base approach for multilevel = TRILL- draft-tissa-trill-multilevel-00.txt =20 I don't understand how multi-topology helps with the nickname exhaustion = issue. As a matter of fact, the only plausible way of marking a packet = for which topology that has been suggested on the mailing list (I asked = a efw times if there were any other possibilities), was to steal 2 or 3 = bits of the nickname to encode which topology, in effect, making a = destination appear as multiple destinations and multiple forwarding = table entries (which you'd want anyway, for multitopology). =20 =20 Radia 2012/2/24 Tissa Senevirathne (tsenevir) Mutli-topology is the answer to increase the nickname space. =20 Nickname translation is very similar to NAT, which has it=A1=AFs own = down side, not to mention special hardware etc. to do the translations, = additionally. We also know from our experience, in IP world NATing is = not the most desired behavior and we live with it. So we should not be = going down that path instead need to look forward from that experience. =20 Multi-topology not only address nickname space issue but also enables = various other applications such as overlay topologies, traffic = engineering. =20 The draft-tiss-trill-multilevel present approaches that are generic, = which mean it can be applied for multi-topology, or base topology. It = utilizes the fundamentals of IS-IS , such as Area hierarchy for = reduction of the LSP-DB. It utilize affinity TLV concepts to effectively = solve multi-destination issues.=20 =20 We should not mix-up between Data center interconnects with data center = node scaling. They are two different and orthogonal issues. =20 Objective of multi-level trill is to interconnect different datacenters, = and maintain LSP-DB small as possible to avoid scaling and volatility. =20 Increasing nickname space a different requirement and has nothing to do = with data-center interconnects. =20 =20 From: Radia Perlman [mailto:radiaperlman@gmail.com]=20 Sent: Friday, February 24, 2012 6:15 AM To: hu.fangwei@zte.com.cn Cc: Tissa Senevirathne (tsenevir); rbridge@postel.org; = rbridge-bounces@postel.org Subject: Re: [rbridge] Default nickname base approach for multilevel = TRILL- draft-tissa-trill-multilevel-00.txt =20 People have mentioned to me that they are nervous about running out of = nicknames, especially since there are reasonson why they might want to = assign nicknames to hypervisors. With the alternate approach of = allowing nicknames to be reused in different areas, it makes automatic = nickname assignment much simpler and makes TRILL a lot more scalable. =20 It does have the downside of requiring mapping of nicknames at the = border RBridges. =20 And by the way, the affinity TLV can be used for multidestination frames = transiting between level 1 and level 2. =20 Radia 2012/2/23 Hi, Tissa.=20 I have several comments about the draft.=20 (1) in section 4.4 (Multicast), "The scope of global traffic may be = identified either through VLAN or via finegrain=20 label that spans across the entire TRILL campus."=20 Vlan and Fine-grain Label is used for service differentiation and = isolation. I do not quite understand that how to=20 use VLAN and fine-grain Lable to identify the traffic scope. The data = traffic with a given VLAN-x, can=20 be forwarded to other end station in the local area, or to the end = station in remote areas.=20 (2) nickname allocation=20 The nickname management sub-TLV is proposed in the document. I wonder = this mechanism adds the complication of =20 nickname allocation. As the section 1 (introduction) of RFC6325, one of = the important advantage of TRILL is that =20 it avoids the creating subnets of IP address and wasting address. The = nickname acquisition method in this draft violates the =20 idea of TRILL Basic specification, and reduces the flexibility of = nickname allocation. As the draft assumed, A1 had =20 nickname range of 100-200, A2 has a local nickname range of 201-300. If = the numbers of A1 area is only 50, so 50 =20 nicknames in A1 is wasted. As the network growing, the number of some = areas may exceed the number being allocation =20 by Border RBridges. The design and maintaining of nickname ranges for = each area is a very hard work. Even worst, it =20 can not avoid to waste nickname space.=20 (3) Dynamic ranges=20 The nickname range is divided into two range: local range and dynamical = range. I wonder the nickname conflict =20 resolution can not work if the RBridge get the nickname from the = dynamical range while the two RBridge belongs to =20 different areas. For example, RB1 is in area A1, and RB2 is in area A2. = If RB1 gets the nickname N1 from dynamic =20 range, and it will floods in area A1, and other RBridges in area A1 can = not get nickname N1 because of nickname =20 confliction mechanism, but RB2 in area A2 can not receive the PDU from = RB1, and it can also get the nickname N1 from =20 dynamical range. So the question is how to avoid the duplication = dynamical range nickname for different areas.=20 (4) The risk of running out of nickname maybe a issue for TRILL. The = number of 2**16 nickname is enough for the current data center,=20 but it maybe not enough in the future, especailly if TRILL over IP , = TRILL over MPLS technology or some other data center technologies=20 are deployed, the data center network can be a very lardge network. So = i think the very important and essential goal of multi-level draft is to = save nicknames.=20 Best regards=20 Fangwei Hu "Tissa Senevirathne (tsenevir)" =20 =B7=A2=BC=FE=C8=CB: rbridge-bounces@postel.org=20 2012-02-23 11:55=20 =CA=D5=BC=FE=C8=CB =20 =B3=AD=CB=CD =09 =D6=F7=CC=E2 [rbridge] Default nickname base approach for multilevel TRILL- = draft-tissa-trill-multilevel-00.txt =20 =09 =09 Dear All We have submitted draft-tissa-trill-multilevel, present multilevel TRILL = based on default nickname approach. Additionally we discuss construction = of multi-destination trees and related RPF in multilevel TRILL. Please = could you review and comment=20 Detail of the draft and abstract are below. Filename: draft-tissa-trill-multilevel Revision: 00 Title: Default Nickname Based Approach = for Multilevel TRILL Creation date: 2012-02-21 WG ID: Individual Submission Number of pages: 26 Abstract: Multilevel TRILL allows the interconnection of multiple TRILL networks to form a larger TRILL network without proportionally increasing the size of the IS-IS LSP DB. In this document, an approach based on default route concept is presented. Also, presented in the document is a novel method of constructing multi- destination trees using partial nickname space. Methods presented in this document are compatible with the RFC6325 specified data plane operations. = =20 Thanks Tissa _______________________________________________ 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 =20 =20 =20 ------_=_NextPart_001_01CCF31E.17EB7B6E Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable

RBridges do not have to be in all topologies. Why would they should = be?

 

What is Fulrcrum chip ?

 

 

 

 

From:= = Radia Perlman [mailto:radiaperlman@gmail.com]
Sent: Friday, = February 24, 2012 9:23 AM
To: Tissa Senevirathne = (tsenevir)
Cc: hu.fangwei@zte.com.cn; rbridge@postel.org; = rbridge-bounces@postel.org
Subject: Re: [rbridge] Default = nickname base approach for multilevel TRILL- = draft-tissa-trill-multilevel-00.txt

 

I = assume that all RBridges will need to be in all topologies, = so multitopology will not help with nickname exhaustion.  Plus = you haven't explained how a TRILL packet would be marked as to which = topology the packet should be routed according to (other than what I = mentioned, which actually eats up nicknames by a factor of the number of = topologies supported).

 

Plus, rather than just lumping potential issues into a = phrase such as "NAT-like", be explicit about what issues there = actually are.  I believe the Fulcrum chip would have no problem = with translating the nickname fields.

 

And rather than assuming that nickname exhaustion can = be solved "some other way", there should be a palatable = solution before rejecting a chance to solve it with = multilevel.

 

Radia

2012/2/24 Tissa Senevirathne (tsenevir) <tsenevir@cisco.com><= /p>

Because you can have same nickname for different topology. It is not = a nickname that will identify an RBRidge, it is topology,nickname = combination that will identify an RBRidge. So RB1 can have nickname 1 in = topo-1 and RB2 can have nickname 1 in topo2. Now total nicknames in the = campus is 2**16 x topologies.

 

Stealing bits to represent topo id is only a workaround there can be = (are ) more elegant ways of doing it that.

 

Bottom line is we need to look for more creative methods of solving = nickname space issue than doing NAT like behavior. =

 

From:= = Radia Perlman [mailto:radiaperlman@gmail.com]
Sent: Friday, = February 24, 2012 9:05 AM
To: Tissa Senevirathne = (tsenevir)
Cc: hu.fangwei@zte.com.cn; rbridge@postel.org; rbridge-bounces@postel.org =


Subje= ct: Re: [rbridge] Default nickname base approach for multilevel = TRILL- = draft-tissa-trill-multilevel-00.txt

 <= /o:p>

I don't = understand how multi-topology helps with the nickname exhaustion = issue.  As a matter of fact, the only plausible way of marking a = packet for which topology that has been suggested on the mailing list (I = asked a efw times if there were any other possibilities), was to steal 2 = or 3 bits of the nickname to encode which topology, in effect, making a = destination appear as multiple destinations and multiple forwarding = table entries (which you'd want anyway, for = multitopology).

 <= /o:p>

 <= /o:p>

Radia

2012/2/24 = Tissa Senevirathne (tsenevir) <tsenevir@cisco.com>

Mutli-topology is the answer to increase the nickname = space.

 

Nickname translation is very similar to NAT, which has it=A1=AFs own = down side, not to mention special hardware etc. to do the translations, = additionally. We also know from our experience, in IP world NATing is = not the most desired behavior and we live with it. So we should not be = going down that path instead need to look forward from that = experience.

 

Multi-topology not only address nickname space issue but also enables = various other applications such as overlay topologies, traffic = engineering.

 

The draft-tiss-trill-multilevel present approaches that are generic, = which mean it can be applied for multi-topology, or base topology. It = utilizes the fundamentals of IS-IS , such as Area hierarchy for = reduction of the LSP-DB. It utilize affinity TLV concepts to effectively = solve multi-destination issues.

 

We should not mix-up between Data center interconnects with data = center node scaling. They are two different and orthogonal = issues.

 

Objective of multi-level trill is to interconnect different = datacenters, and maintain LSP-DB small as possible to avoid scaling and = volatility.

 

Increasing nickname space a different requirement and has nothing to = do with data-center interconnects.

 

 

From:= = Radia Perlman [mailto:radiaperlman@gmail.com]
Sent: Friday, = February 24, 2012 6:15 AM
To: hu.fangwei@zte.com.cn
Cc: Tissa = Senevirathne (tsenevir); rbridge@postel.org; rbridge-bounces@postel.org
Subject: Re: = [rbridge] Default nickname base approach for multilevel TRILL- = draft-tissa-trill-multilevel-00.txt

=

 <= /o:p>

People have = mentioned to me that they are nervous about running out of nicknames, = especially since there are reasonson why they might want to assign = nicknames to hypervisors.  With the alternate approach of allowing = nicknames to be reused in different areas, it makes automatic nickname = assignment much simpler and makes TRILL a lot more = scalable.

 <= /o:p>

It does = have the downside of requiring mapping of nicknames at the border = RBridges.

 <= /o:p>

And by the = way, the affinity TLV can be used for multidestination frames transiting = between level 1 and level 2.

 <= /o:p>

Radia

2012/2/23 = <hu.fangwei@zte.com.cn>


Hi, Tissa. =

I have several = comments about the draft.

(1) in section 4.4 = (Multicast), "The scope of global traffic may be identified either = through VLAN or via finegrain
label that spans across the = entire TRILL campus."
Vlan and Fine-grain Label is = used for service differentiation and isolation. I do not quite = understand that how to
use VLAN and fine-grain Lable = to identify the traffic scope. The data traffic with a given VLAN-x, can =
be forwarded = to other end station in the local area, or to the end station in remote = areas.

(2) nickname = allocation
The nickname management = sub-TLV is proposed in the document. I wonder this mechanism adds the = complication of  
nickname allocation. As the = section 1 (introduction) of RFC6325, one of the important advantage of = TRILL is that  
it avoids the creating = subnets of IP address and wasting address. The nickname acquisition =  method in this draft violates the  
idea of TRILL Basic = specification, and reduces the flexibility of nickname allocation. As = the draft assumed, A1 had  
nickname range of 100-200, A2 = has a local nickname range of 201-300. If the numbers of A1 area is only = 50, so 50  
nicknames in A1 is wasted. As = the network growing, the number of some areas may exceed the number = being allocation  
by Border RBridges. The = design and maintaining of nickname ranges for each area is a very hard = work. Even worst, it  
can not avoid to waste = nickname space.

(3) Dynamic ranges =
 The = nickname range is divided into two range: local range and dynamical = range. I wonder the nickname conflict  
resolution can not work if = the RBridge get the nickname from the dynamical range while the two = RBridge belongs to  
different areas. For example, = RB1 is in area A1, and RB2 is in area A2. If RB1 gets the nickname N1 = from dynamic  
range, and it will floods in = area A1, and other RBridges in area A1 can not get nickname N1 because = of nickname  
confliction mechanism, but = RB2 in area A2 can not receive the PDU from RB1, and it  can also = get the nickname N1 from  
dynamical range. So the = question is how to avoid the duplication dynamical range nickname for = different areas.

(4) The risk of running out = of nickname maybe a issue for TRILL. The number of 2**16 nickname is = enough for the current data center,
 but it maybe not enough = in the future, especailly if TRILL over IP , TRILL over MPLS technology = or some other data center technologies
 are deployed, the data = center network can be a very lardge network. So i think the very = important and essential goal of multi-level draft is to save = nicknames.

Best regards
Fangwei = Hu

"Tissa = Senevirathne (tsenevir)" <tsenevir@cisco.com> =
=B7=A2=BC=FE=C8=CB:  rbridge-bounces@postel.org =

2012-02-23 = 11:55

<rbridge@postel.org> =

=

=CA=D5=BC=FE=C8=CB

=B3=AD=CB=CD

=D6=F7=CC=E2

[rbridge] = Default nickname base approach for multilevel TRILL-     =   =  draft-tissa-trill-multilevel-00.txt

 <= /o:p>




De= ar All

We have submitted draft-tissa-trill-multilevel, = present multilevel TRILL based on default nickname approach. = Additionally we discuss construction of multi-destination trees and = related RPF in multilevel TRILL. Please could you review and comment =

Detail of the draft and abstract are = below.

Filename:           =       =  draft-tissa-trill-multilevel
Revision:     =              00
Title: =                     =               Default Nickname Based = Approach for Multilevel TRILL
Creation date:     =             =  2012-02-21
WG ID:           =                     =     Individual Submission
Number of pages: = 26

Abstract:
  Multilevel TRILL allows = the interconnection of multiple TRILL
  networks to = form a larger TRILL network without proportionally
  = increasing the size of the IS-IS LSP DB. In this document, = an
  approach based on default route concept is = presented. Also,
  presented in the document is a novel = method of constructing multi-
  destination trees using = partial nickname space. Methods presented in
  this = document are compatible with the RFC6325 specified data = plane
  operations.

    =                     =                     =                     =                 =  
Thanks
Tissa

_____________= __________________________________
rbridge mailing = list
rbridge@postel.org
http://mailman.postel.org/mailman/listinfo/rbridge<= /tt>


______________= _________________________________
rbridge mailing list
rbridge@postel.org
http://mailman.postel.org/mailman/listinfo/rbridge<= o:p>

 <= /o:p>

 <= /o:p>

 

------_=_NextPart_001_01CCF31E.17EB7B6E-- --===============0112536213== 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 --===============0112536213==-- From rbridge-bounces@postel.org Fri Feb 24 10:44: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 B388121F85C9 for ; Fri, 24 Feb 2012 10:44:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.895 X-Spam-Level: X-Spam-Status: No, score=-4.895 tagged_above=-999 required=5 tests=[AWL=-0.748, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ZjO2F4pybQvA for ; Fri, 24 Feb 2012 10:44:55 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 487C021F85B8 for ; Fri, 24 Feb 2012 10:44:54 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1OI7x6Z023645; Fri, 24 Feb 2012 10:08:01 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1OI7L0U023559 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 24 Feb 2012 10:07:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tsenevir@cisco.com; l=38017; q=dns/txt; s=iport; t=1330106849; x=1331316449; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=5MyQVIlUjrWXG7dRXXTnLAKFCeG5mN2jS1CDHY3LtV4=; b=CrHHHBq31jLM34Hb7wZgEw1vCyvL6eAQsxVrMgCwTAWioSs3Mkvc336r cGayYRzlPNzsjXP3fHfLgR+Ffigr4itsDD0OuStO6zo+kit1qxt4IMh22 Jf468Kh1rzb5WqOBpxLGvNTB39t95c8gUE0NNL6deoraGjPh6ha6HNdT0 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAHHRR0+rRDoH/2dsb2JhbAA6AQmCP4JppFIBiQyBB4FzAQEBBAEBAQ8BCREDPgsQAgEGAhEEAQELBhABAgQBBAIBIAYfCQgBAQQTCBMHh2MMmWUBjF8IkXeJDmEBBIMIAgIFAQQBAgQCAQEDCA0HAkYChGcBBBkjHgcEBAIDBQMEARQGGgwDghM3YwSIT5gEh3iBMgEE X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208,217";a="30340606" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 24 Feb 2012 18:07:20 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q1OI7Ker020828; Fri, 24 Feb 2012 18:07:20 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); Fri, 24 Feb 2012 10:07:20 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 24 Feb 2012 10:07:19 -0800 Message-ID: <344037D7CFEFE84E97E9CC1F56C5F4A5A46360@xmb-sjc-214.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.txt Thread-Index: AczzGPt0mgzA1RnSQgGsce1THRRoOQABXxRQ References: <344037D7CFEFE84E97E9CC1F56C5F4A5A45E88@xmb-sjc-214.amer.cisco.com><344037D7CFEFE84E97E9CC1F56C5F4A5A462E7@xmb-sjc-214.amer.cisco.com><344037D7CFEFE84E97E9CC1F56C5F4A5A46325@xmb-sjc-214.amer.cisco.com> From: "Tissa Senevirathne (tsenevir)" To: "Radia Perlman" X-OriginalArrivalTime: 24 Feb 2012 18:07:20.0681 (UTC) FILETIME=[26C3E590:01CCF31F] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: tsenevir@cisco.com Cc: rbridge@postel.org, rbridge-bounces@postel.org, hu.fangwei@zte.com.cn Subject: Re: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.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: multipart/mixed; boundary="===============1054201314==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org This is a multi-part message in MIME format. --===============1054201314== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCF31F.26812C3C" This is a multi-part message in MIME format. ------_=_NextPart_001_01CCF31F.26812C3C Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable Also, there are so many well known issues with NAT like approaches. #1 = is you would lose identity of originator, and it becomes an OAM = nightmare. It limit ability apply certain ACL, rate-limiting etc. =20 There is a whole series of issues associated with NATs. That is one of = the reasons folks in IP world are pushing hard to go to IPv6. I was = assuming people are aware of those. =20 From: Radia Perlman [mailto:radiaperlman@gmail.com]=20 Sent: Friday, February 24, 2012 9:23 AM To: Tissa Senevirathne (tsenevir) Cc: hu.fangwei@zte.com.cn; rbridge@postel.org; = rbridge-bounces@postel.org Subject: Re: [rbridge] Default nickname base approach for multilevel = TRILL- draft-tissa-trill-multilevel-00.txt =20 I assume that all RBridges will need to be in all topologies, so = multitopology will not help with nickname exhaustion. Plus you haven't = explained how a TRILL packet would be marked as to which topology the = packet should be routed according to (other than what I mentioned, which = actually eats up nicknames by a factor of the number of topologies = supported). =20 Plus, rather than just lumping potential issues into a phrase such as = "NAT-like", be explicit about what issues there actually are. I believe = the Fulcrum chip would have no problem with translating the nickname = fields. =20 And rather than assuming that nickname exhaustion can be solved "some = other way", there should be a palatable solution before rejecting a = chance to solve it with multilevel. =20 Radia 2012/2/24 Tissa Senevirathne (tsenevir) Because you can have same nickname for different topology. It is not a = nickname that will identify an RBRidge, it is topology,nickname = combination that will identify an RBRidge. So RB1 can have nickname 1 in = topo-1 and RB2 can have nickname 1 in topo2. Now total nicknames in the = campus is 2**16 x topologies. =20 Stealing bits to represent topo id is only a workaround there can be = (are ) more elegant ways of doing it that. =20 Bottom line is we need to look for more creative methods of solving = nickname space issue than doing NAT like behavior.=20 =20 From: Radia Perlman [mailto:radiaperlman@gmail.com]=20 Sent: Friday, February 24, 2012 9:05 AM To: Tissa Senevirathne (tsenevir) Cc: hu.fangwei@zte.com.cn; rbridge@postel.org; = rbridge-bounces@postel.org=20 Subject: Re: [rbridge] Default nickname base approach for multilevel = TRILL- draft-tissa-trill-multilevel-00.txt =20 I don't understand how multi-topology helps with the nickname exhaustion = issue. As a matter of fact, the only plausible way of marking a packet = for which topology that has been suggested on the mailing list (I asked = a efw times if there were any other possibilities), was to steal 2 or 3 = bits of the nickname to encode which topology, in effect, making a = destination appear as multiple destinations and multiple forwarding = table entries (which you'd want anyway, for multitopology). =20 =20 Radia 2012/2/24 Tissa Senevirathne (tsenevir) Mutli-topology is the answer to increase the nickname space. =20 Nickname translation is very similar to NAT, which has it=A1=AFs own = down side, not to mention special hardware etc. to do the translations, = additionally. We also know from our experience, in IP world NATing is = not the most desired behavior and we live with it. So we should not be = going down that path instead need to look forward from that experience. =20 Multi-topology not only address nickname space issue but also enables = various other applications such as overlay topologies, traffic = engineering. =20 The draft-tiss-trill-multilevel present approaches that are generic, = which mean it can be applied for multi-topology, or base topology. It = utilizes the fundamentals of IS-IS , such as Area hierarchy for = reduction of the LSP-DB. It utilize affinity TLV concepts to effectively = solve multi-destination issues.=20 =20 We should not mix-up between Data center interconnects with data center = node scaling. They are two different and orthogonal issues. =20 Objective of multi-level trill is to interconnect different datacenters, = and maintain LSP-DB small as possible to avoid scaling and volatility. =20 Increasing nickname space a different requirement and has nothing to do = with data-center interconnects. =20 =20 From: Radia Perlman [mailto:radiaperlman@gmail.com]=20 Sent: Friday, February 24, 2012 6:15 AM To: hu.fangwei@zte.com.cn Cc: Tissa Senevirathne (tsenevir); rbridge@postel.org; = rbridge-bounces@postel.org Subject: Re: [rbridge] Default nickname base approach for multilevel = TRILL- draft-tissa-trill-multilevel-00.txt =20 People have mentioned to me that they are nervous about running out of = nicknames, especially since there are reasonson why they might want to = assign nicknames to hypervisors. With the alternate approach of = allowing nicknames to be reused in different areas, it makes automatic = nickname assignment much simpler and makes TRILL a lot more scalable. =20 It does have the downside of requiring mapping of nicknames at the = border RBridges. =20 And by the way, the affinity TLV can be used for multidestination frames = transiting between level 1 and level 2. =20 Radia 2012/2/23 Hi, Tissa.=20 I have several comments about the draft.=20 (1) in section 4.4 (Multicast), "The scope of global traffic may be = identified either through VLAN or via finegrain=20 label that spans across the entire TRILL campus."=20 Vlan and Fine-grain Label is used for service differentiation and = isolation. I do not quite understand that how to=20 use VLAN and fine-grain Lable to identify the traffic scope. The data = traffic with a given VLAN-x, can=20 be forwarded to other end station in the local area, or to the end = station in remote areas.=20 (2) nickname allocation=20 The nickname management sub-TLV is proposed in the document. I wonder = this mechanism adds the complication of =20 nickname allocation. As the section 1 (introduction) of RFC6325, one of = the important advantage of TRILL is that =20 it avoids the creating subnets of IP address and wasting address. The = nickname acquisition method in this draft violates the =20 idea of TRILL Basic specification, and reduces the flexibility of = nickname allocation. As the draft assumed, A1 had =20 nickname range of 100-200, A2 has a local nickname range of 201-300. If = the numbers of A1 area is only 50, so 50 =20 nicknames in A1 is wasted. As the network growing, the number of some = areas may exceed the number being allocation =20 by Border RBridges. The design and maintaining of nickname ranges for = each area is a very hard work. Even worst, it =20 can not avoid to waste nickname space.=20 (3) Dynamic ranges=20 The nickname range is divided into two range: local range and dynamical = range. I wonder the nickname conflict =20 resolution can not work if the RBridge get the nickname from the = dynamical range while the two RBridge belongs to =20 different areas. For example, RB1 is in area A1, and RB2 is in area A2. = If RB1 gets the nickname N1 from dynamic =20 range, and it will floods in area A1, and other RBridges in area A1 can = not get nickname N1 because of nickname =20 confliction mechanism, but RB2 in area A2 can not receive the PDU from = RB1, and it can also get the nickname N1 from =20 dynamical range. So the question is how to avoid the duplication = dynamical range nickname for different areas.=20 (4) The risk of running out of nickname maybe a issue for TRILL. The = number of 2**16 nickname is enough for the current data center,=20 but it maybe not enough in the future, especailly if TRILL over IP , = TRILL over MPLS technology or some other data center technologies=20 are deployed, the data center network can be a very lardge network. So = i think the very important and essential goal of multi-level draft is to = save nicknames.=20 Best regards=20 Fangwei Hu "Tissa Senevirathne (tsenevir)" =20 =B7=A2=BC=FE=C8=CB: rbridge-bounces@postel.org=20 2012-02-23 11:55=20 =CA=D5=BC=FE=C8=CB =20 =B3=AD=CB=CD =09 =D6=F7=CC=E2 [rbridge] Default nickname base approach for multilevel TRILL- = draft-tissa-trill-multilevel-00.txt =20 =09 =09 Dear All We have submitted draft-tissa-trill-multilevel, present multilevel TRILL = based on default nickname approach. Additionally we discuss construction = of multi-destination trees and related RPF in multilevel TRILL. Please = could you review and comment=20 Detail of the draft and abstract are below. Filename: draft-tissa-trill-multilevel Revision: 00 Title: Default Nickname Based Approach = for Multilevel TRILL Creation date: 2012-02-21 WG ID: Individual Submission Number of pages: 26 Abstract: Multilevel TRILL allows the interconnection of multiple TRILL networks to form a larger TRILL network without proportionally increasing the size of the IS-IS LSP DB. In this document, an approach based on default route concept is presented. Also, presented in the document is a novel method of constructing multi- destination trees using partial nickname space. Methods presented in this document are compatible with the RFC6325 specified data plane operations. = =20 Thanks Tissa _______________________________________________ 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 =20 =20 =20 ------_=_NextPart_001_01CCF31F.26812C3C Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable

Also, there are so many well known issues with NAT like approaches. = #1 is you would lose identity of originator, and it becomes an OAM = nightmare.  It limit ability apply certain ACL, rate-limiting = etc.

 

There is a whole series of issues associated with NATs. That is one = of the reasons folks in IP world are pushing hard to go to IPv6. I was = assuming people are aware of those.

 

From:= = Radia Perlman [mailto:radiaperlman@gmail.com]
Sent: Friday, = February 24, 2012 9:23 AM
To: Tissa Senevirathne = (tsenevir)
Cc: hu.fangwei@zte.com.cn; rbridge@postel.org; = rbridge-bounces@postel.org
Subject: Re: [rbridge] Default = nickname base approach for multilevel TRILL- = draft-tissa-trill-multilevel-00.txt

 

I = assume that all RBridges will need to be in all topologies, = so multitopology will not help with nickname exhaustion.  Plus = you haven't explained how a TRILL packet would be marked as to which = topology the packet should be routed according to (other than what I = mentioned, which actually eats up nicknames by a factor of the number of = topologies supported).

 

Plus, rather than just lumping potential issues into a = phrase such as "NAT-like", be explicit about what issues there = actually are.  I believe the Fulcrum chip would have no problem = with translating the nickname fields.

 

And rather than assuming that nickname exhaustion can = be solved "some other way", there should be a palatable = solution before rejecting a chance to solve it with = multilevel.

 

Radia

2012/2/24 Tissa Senevirathne (tsenevir) <tsenevir@cisco.com><= /p>

Because you can have same nickname for different topology. It is not = a nickname that will identify an RBRidge, it is topology,nickname = combination that will identify an RBRidge. So RB1 can have nickname 1 in = topo-1 and RB2 can have nickname 1 in topo2. Now total nicknames in the = campus is 2**16 x topologies.

 

Stealing bits to represent topo id is only a workaround there can be = (are ) more elegant ways of doing it that.

 

Bottom line is we need to look for more creative methods of solving = nickname space issue than doing NAT like behavior. =

 

From:= = Radia Perlman [mailto:radiaperlman@gmail.com]
Sent: Friday, = February 24, 2012 9:05 AM
To: Tissa Senevirathne = (tsenevir)
Cc: hu.fangwei@zte.com.cn; rbridge@postel.org; rbridge-bounces@postel.org =


Subje= ct: Re: [rbridge] Default nickname base approach for multilevel = TRILL- = draft-tissa-trill-multilevel-00.txt

 <= /o:p>

I don't = understand how multi-topology helps with the nickname exhaustion = issue.  As a matter of fact, the only plausible way of marking a = packet for which topology that has been suggested on the mailing list (I = asked a efw times if there were any other possibilities), was to steal 2 = or 3 bits of the nickname to encode which topology, in effect, making a = destination appear as multiple destinations and multiple forwarding = table entries (which you'd want anyway, for = multitopology).

 <= /o:p>

 <= /o:p>

Radia

2012/2/24 = Tissa Senevirathne (tsenevir) <tsenevir@cisco.com>

Mutli-topology is the answer to increase the nickname = space.

 

Nickname translation is very similar to NAT, which has it=A1=AFs own = down side, not to mention special hardware etc. to do the translations, = additionally. We also know from our experience, in IP world NATing is = not the most desired behavior and we live with it. So we should not be = going down that path instead need to look forward from that = experience.

 

Multi-topology not only address nickname space issue but also enables = various other applications such as overlay topologies, traffic = engineering.

 

The draft-tiss-trill-multilevel present approaches that are generic, = which mean it can be applied for multi-topology, or base topology. It = utilizes the fundamentals of IS-IS , such as Area hierarchy for = reduction of the LSP-DB. It utilize affinity TLV concepts to effectively = solve multi-destination issues.

 

We should not mix-up between Data center interconnects with data = center node scaling. They are two different and orthogonal = issues.

 

Objective of multi-level trill is to interconnect different = datacenters, and maintain LSP-DB small as possible to avoid scaling and = volatility.

 

Increasing nickname space a different requirement and has nothing to = do with data-center interconnects.

 

 

From:= = Radia Perlman [mailto:radiaperlman@gmail.com]
Sent: Friday, = February 24, 2012 6:15 AM
To: hu.fangwei@zte.com.cn
Cc: Tissa = Senevirathne (tsenevir); rbridge@postel.org; rbridge-bounces@postel.org
Subject: Re: = [rbridge] Default nickname base approach for multilevel TRILL- = draft-tissa-trill-multilevel-00.txt

=

 <= /o:p>

People have = mentioned to me that they are nervous about running out of nicknames, = especially since there are reasonson why they might want to assign = nicknames to hypervisors.  With the alternate approach of allowing = nicknames to be reused in different areas, it makes automatic nickname = assignment much simpler and makes TRILL a lot more = scalable.

 <= /o:p>

It does = have the downside of requiring mapping of nicknames at the border = RBridges.

 <= /o:p>

And by the = way, the affinity TLV can be used for multidestination frames transiting = between level 1 and level 2.

 <= /o:p>

Radia

2012/2/23 = <hu.fangwei@zte.com.cn>


Hi, Tissa. =

I have several = comments about the draft.

(1) in section 4.4 = (Multicast), "The scope of global traffic may be identified either = through VLAN or via finegrain
label that spans across the = entire TRILL campus."
Vlan and Fine-grain Label is = used for service differentiation and isolation. I do not quite = understand that how to
use VLAN and fine-grain Lable = to identify the traffic scope. The data traffic with a given VLAN-x, can =
be forwarded = to other end station in the local area, or to the end station in remote = areas.

(2) nickname = allocation
The nickname management = sub-TLV is proposed in the document. I wonder this mechanism adds the = complication of  
nickname allocation. As the = section 1 (introduction) of RFC6325, one of the important advantage of = TRILL is that  
it avoids the creating = subnets of IP address and wasting address. The nickname acquisition =  method in this draft violates the  
idea of TRILL Basic = specification, and reduces the flexibility of nickname allocation. As = the draft assumed, A1 had  
nickname range of 100-200, A2 = has a local nickname range of 201-300. If the numbers of A1 area is only = 50, so 50  
nicknames in A1 is wasted. As = the network growing, the number of some areas may exceed the number = being allocation  
by Border RBridges. The = design and maintaining of nickname ranges for each area is a very hard = work. Even worst, it  
can not avoid to waste = nickname space.

(3) Dynamic ranges =
 The = nickname range is divided into two range: local range and dynamical = range. I wonder the nickname conflict  
resolution can not work if = the RBridge get the nickname from the dynamical range while the two = RBridge belongs to  
different areas. For example, = RB1 is in area A1, and RB2 is in area A2. If RB1 gets the nickname N1 = from dynamic  
range, and it will floods in = area A1, and other RBridges in area A1 can not get nickname N1 because = of nickname  
confliction mechanism, but = RB2 in area A2 can not receive the PDU from RB1, and it  can also = get the nickname N1 from  
dynamical range. So the = question is how to avoid the duplication dynamical range nickname for = different areas.

(4) The risk of running out = of nickname maybe a issue for TRILL. The number of 2**16 nickname is = enough for the current data center,
 but it maybe not enough = in the future, especailly if TRILL over IP , TRILL over MPLS technology = or some other data center technologies
 are deployed, the data = center network can be a very lardge network. So i think the very = important and essential goal of multi-level draft is to save = nicknames.

Best regards
Fangwei = Hu

"Tissa = Senevirathne (tsenevir)" <tsenevir@cisco.com> =
=B7=A2=BC=FE=C8=CB:  rbridge-bounces@postel.org =

2012-02-23 = 11:55

<rbridge@postel.org> =

=

=CA=D5=BC=FE=C8=CB

=B3=AD=CB=CD

=D6=F7=CC=E2

[rbridge] = Default nickname base approach for multilevel TRILL-     =   =  draft-tissa-trill-multilevel-00.txt

 <= /o:p>




De= ar All

We have submitted draft-tissa-trill-multilevel, = present multilevel TRILL based on default nickname approach. = Additionally we discuss construction of multi-destination trees and = related RPF in multilevel TRILL. Please could you review and comment =

Detail of the draft and abstract are = below.

Filename:           =       =  draft-tissa-trill-multilevel
Revision:     =              00
Title: =                     =               Default Nickname Based = Approach for Multilevel TRILL
Creation date:     =             =  2012-02-21
WG ID:           =                     =     Individual Submission
Number of pages: = 26

Abstract:
  Multilevel TRILL allows = the interconnection of multiple TRILL
  networks to = form a larger TRILL network without proportionally
  = increasing the size of the IS-IS LSP DB. In this document, = an
  approach based on default route concept is = presented. Also,
  presented in the document is a novel = method of constructing multi-
  destination trees using = partial nickname space. Methods presented in
  this = document are compatible with the RFC6325 specified data = plane
  operations.

    =                     =                     =                     =                 =  
Thanks
Tissa

_____________= __________________________________
rbridge mailing = list
rbridge@postel.org
http://mailman.postel.org/mailman/listinfo/rbridge<= /tt>


______________= _________________________________
rbridge mailing list
rbridge@postel.org
http://mailman.postel.org/mailman/listinfo/rbridge<= o:p>

 <= /o:p>

 <= /o:p>

 

------_=_NextPart_001_01CCF31F.26812C3C-- --===============1054201314== 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 --===============1054201314==-- From rbridge-bounces@postel.org Fri Feb 24 10:57: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 433CC21F87EA for ; Fri, 24 Feb 2012 10:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.394 X-Spam-Level: X-Spam-Status: No, score=-2.394 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 92nASsh0n0jc for ; Fri, 24 Feb 2012 10:57:35 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id AAF7821F87C8 for ; Fri, 24 Feb 2012 10:57:35 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1OIXKWn028795; Fri, 24 Feb 2012 10:33:22 -0800 (PST) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1OIWsbV028757 for ; Fri, 24 Feb 2012 10:33:03 -0800 (PST) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id ADW22052; Fri, 24 Feb 2012 13:32:52 -0500 (EST) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 24 Feb 2012 10:30:52 -0800 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Fri, 24 Feb 2012 10:30:46 -0800 From: Donald Eastlake To: "Tissa Senevirathne (tsenevir)" , Radia Perlman , "hu.fangwei@zte.com.cn" Thread-Topic: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.txt Thread-Index: Aczwwgvgbt2qI1nfQfiYK8zrqzIBUABHHNaQAEeiwwAAETB3gP//F4WA//9XMkA= Date: Fri, 24 Feb 2012 18:29:59 +0000 Message-ID: References: <344037D7CFEFE84E97E9CC1F56C5F4A5A45E88@xmb-sjc-214.amer.cisco.com> <344037D7CFEFE84E97E9CC1F56C5F4A5A462E7@xmb-sjc-214.amer.cisco.com> In-Reply-To: <344037D7CFEFE84E97E9CC1F56C5F4A5A462E7@xmb-sjc-214.amer.cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.34.150] MIME-Version: 1.0 X-CFilter-Loop: Reflected X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@huawei.com Cc: "rbridge@postel.org" Subject: Re: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.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: multipart/mixed; boundary="===============1988093119==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org --===============1988093119== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_C5BD54C085F1DB4D9B6B5BFF7ACE182B355A42D0dfweml505mbx_" --_000_C5BD54C085F1DB4D9B6B5BFF7ACE182B355A42D0dfweml505mbx_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Q2hhbmdpbmcgdGhlIHZhbHVlIGluIHRoZSBleGlzdGluZyBuaWNrbmFtZSBUUklMTCBIZWFkZXIg c2xvdHMgYXQgYm9yZGVyIFJCcmlkZ2VzIGNhbiBiZSBkb25lIGluIGEgTkFULWxpa2Ugd2F5IG9y LCB3aXRoIHN3YXAtbmlja25hbWVzLCBpbiBhIHdheSB3aGljaCBpcyBub3QgYXQgYWxsIGxpa2Ug TkFULg0KDQpUaGFua3MsDQpEb25hbGQNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQ0KRG9uYWxkIEUuIEVhc3RsYWtlLCAzcmQgICAgIERvbmFsZC5FYXN0bGFrZUBo dWF3ZWkuY29tDQoxNTUgQmVhdmVyIFN0cmVldCAgICAgICAgICAgICAgKzEtNTA4LTMzMy0yMjcw DQogTWlsZm9yZCwgTUEgMDE3NTcgVVNBDQoNCkZyb206IHJicmlkZ2UtYm91bmNlc0Bwb3N0ZWwu b3JnIFttYWlsdG86cmJyaWRnZS1ib3VuY2VzQHBvc3RlbC5vcmddIE9uIEJlaGFsZiBPZiBUaXNz YSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKQ0KU2VudDogRnJpZGF5LCBGZWJydWFyeSAyNCwgMjAx MiAxMToyMyBBTQ0KVG86IFJhZGlhIFBlcmxtYW47IGh1LmZhbmd3ZWlAenRlLmNvbS5jbg0KQ2M6 IHJicmlkZ2VAcG9zdGVsLm9yZzsgcmJyaWRnZS1ib3VuY2VzQHBvc3RlbC5vcmcNClN1YmplY3Q6 IFJlOiBbcmJyaWRnZV0gRGVmYXVsdCBuaWNrbmFtZSBiYXNlIGFwcHJvYWNoIGZvciBtdWx0aWxl dmVsIFRSSUxMLSBkcmFmdC10aXNzYS10cmlsbC1tdWx0aWxldmVsLTAwLnR4dA0KDQpNdXRsaS10 b3BvbG9neSBpcyB0aGUgYW5zd2VyIHRvIGluY3JlYXNlIHRoZSBuaWNrbmFtZSBzcGFjZS4NCg0K Tmlja25hbWUgdHJhbnNsYXRpb24gaXMgdmVyeSBzaW1pbGFyIHRvIE5BVCwgd2hpY2ggaGFzIGl0 oa9zIG93biBkb3duIHNpZGUsIG5vdCB0byBtZW50aW9uIHNwZWNpYWwgaGFyZHdhcmUgZXRjLiB0 byBkbyB0aGUgdHJhbnNsYXRpb25zLCBhZGRpdGlvbmFsbHkuIFdlIGFsc28ga25vdyBmcm9tIG91 ciBleHBlcmllbmNlLCBpbiBJUCB3b3JsZCBOQVRpbmcgaXMgbm90IHRoZSBtb3N0IGRlc2lyZWQg YmVoYXZpb3IgYW5kIHdlIGxpdmUgd2l0aCBpdC4gU28gd2Ugc2hvdWxkIG5vdCBiZSBnb2luZyBk b3duIHRoYXQgcGF0aCBpbnN0ZWFkIG5lZWQgdG8gbG9vayBmb3J3YXJkIGZyb20gdGhhdCBleHBl cmllbmNlLg0KDQpNdWx0aS10b3BvbG9neSBub3Qgb25seSBhZGRyZXNzIG5pY2tuYW1lIHNwYWNl IGlzc3VlIGJ1dCBhbHNvIGVuYWJsZXMgdmFyaW91cyBvdGhlciBhcHBsaWNhdGlvbnMgc3VjaCBh cyBvdmVybGF5IHRvcG9sb2dpZXMsIHRyYWZmaWMgZW5naW5lZXJpbmcuDQoNClRoZSBkcmFmdC10 aXNzLXRyaWxsLW11bHRpbGV2ZWwgcHJlc2VudCBhcHByb2FjaGVzIHRoYXQgYXJlIGdlbmVyaWMs IHdoaWNoIG1lYW4gaXQgY2FuIGJlIGFwcGxpZWQgZm9yIG11bHRpLXRvcG9sb2d5LCBvciBiYXNl IHRvcG9sb2d5LiBJdCB1dGlsaXplcyB0aGUgZnVuZGFtZW50YWxzIG9mIElTLUlTICwgc3VjaCBh cyBBcmVhIGhpZXJhcmNoeSBmb3IgcmVkdWN0aW9uIG9mIHRoZSBMU1AtREIuIEl0IHV0aWxpemUg YWZmaW5pdHkgVExWIGNvbmNlcHRzIHRvIGVmZmVjdGl2ZWx5IHNvbHZlIG11bHRpLWRlc3RpbmF0 aW9uIGlzc3Vlcy4NCg0KV2Ugc2hvdWxkIG5vdCBtaXgtdXAgYmV0d2VlbiBEYXRhIGNlbnRlciBp bnRlcmNvbm5lY3RzIHdpdGggZGF0YSBjZW50ZXIgbm9kZSBzY2FsaW5nLiBUaGV5IGFyZSB0d28g ZGlmZmVyZW50IGFuZCBvcnRob2dvbmFsIGlzc3Vlcy4NCg0KT2JqZWN0aXZlIG9mIG11bHRpLWxl dmVsIHRyaWxsIGlzIHRvIGludGVyY29ubmVjdCBkaWZmZXJlbnQgZGF0YWNlbnRlcnMsIGFuZCBt YWludGFpbiBMU1AtREIgc21hbGwgYXMgcG9zc2libGUgdG8gYXZvaWQgc2NhbGluZyBhbmQgdm9s YXRpbGl0eS4NCg0KSW5jcmVhc2luZyBuaWNrbmFtZSBzcGFjZSBhIGRpZmZlcmVudCByZXF1aXJl bWVudCBhbmQgaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCBkYXRhLWNlbnRlciBpbnRlcmNvbm5lY3Rz Lg0KDQoNCkZyb206IFJhZGlhIFBlcmxtYW4gW21haWx0bzpyYWRpYXBlcmxtYW5AZ21haWwuY29t XQ0KU2VudDogRnJpZGF5LCBGZWJydWFyeSAyNCwgMjAxMiA2OjE1IEFNDQpUbzogaHUuZmFuZ3dl aUB6dGUuY29tLmNuDQpDYzogVGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZpcik7IHJicmlkZ2VA cG9zdGVsLm9yZzsgcmJyaWRnZS1ib3VuY2VzQHBvc3RlbC5vcmcNClN1YmplY3Q6IFJlOiBbcmJy aWRnZV0gRGVmYXVsdCBuaWNrbmFtZSBiYXNlIGFwcHJvYWNoIGZvciBtdWx0aWxldmVsIFRSSUxM LSBkcmFmdC10aXNzYS10cmlsbC1tdWx0aWxldmVsLTAwLnR4dA0KDQpQZW9wbGUgaGF2ZSBtZW50 aW9uZWQgdG8gbWUgdGhhdCB0aGV5IGFyZSBuZXJ2b3VzIGFib3V0IHJ1bm5pbmcgb3V0IG9mIG5p Y2tuYW1lcywgZXNwZWNpYWxseSBzaW5jZSB0aGVyZSBhcmUgcmVhc29uc29uIHdoeSB0aGV5IG1p Z2h0IHdhbnQgdG8gYXNzaWduIG5pY2tuYW1lcyB0byBoeXBlcnZpc29ycy4gIFdpdGggdGhlIGFs dGVybmF0ZSBhcHByb2FjaCBvZiBhbGxvd2luZyBuaWNrbmFtZXMgdG8gYmUgcmV1c2VkIGluIGRp ZmZlcmVudCBhcmVhcywgaXQgbWFrZXMgYXV0b21hdGljIG5pY2tuYW1lIGFzc2lnbm1lbnQgbXVj aCBzaW1wbGVyIGFuZCBtYWtlcyBUUklMTCBhIGxvdCBtb3JlIHNjYWxhYmxlLg0KDQpJdCBkb2Vz IGhhdmUgdGhlIGRvd25zaWRlIG9mIHJlcXVpcmluZyBtYXBwaW5nIG9mIG5pY2tuYW1lcyBhdCB0 aGUgYm9yZGVyIFJCcmlkZ2VzLg0KDQpBbmQgYnkgdGhlIHdheSwgdGhlIGFmZmluaXR5IFRMViBj YW4gYmUgdXNlZCBmb3IgbXVsdGlkZXN0aW5hdGlvbiBmcmFtZXMgdHJhbnNpdGluZyBiZXR3ZWVu IGxldmVsIDEgYW5kIGxldmVsIDIuDQoNClJhZGlhDQoyMDEyLzIvMjMgPGh1LmZhbmd3ZWlAenRl LmNvbS5jbjxtYWlsdG86aHUuZmFuZ3dlaUB6dGUuY29tLmNuPj4NCg0KSGksIFRpc3NhLg0KDQpJ IGhhdmUgc2V2ZXJhbCBjb21tZW50cyBhYm91dCB0aGUgZHJhZnQuDQoNCigxKSBpbiBzZWN0aW9u IDQuNCAoTXVsdGljYXN0KSwgIlRoZSBzY29wZSBvZiBnbG9iYWwgdHJhZmZpYyBtYXkgYmUgaWRl bnRpZmllZCBlaXRoZXIgdGhyb3VnaCBWTEFOIG9yIHZpYSBmaW5lZ3JhaW4NCmxhYmVsIHRoYXQg c3BhbnMgYWNyb3NzIHRoZSBlbnRpcmUgVFJJTEwgY2FtcHVzLiINClZsYW4gYW5kIEZpbmUtZ3Jh aW4gTGFiZWwgaXMgdXNlZCBmb3Igc2VydmljZSBkaWZmZXJlbnRpYXRpb24gYW5kIGlzb2xhdGlv bi4gSSBkbyBub3QgcXVpdGUgdW5kZXJzdGFuZCB0aGF0IGhvdyB0bw0KdXNlIFZMQU4gYW5kIGZp bmUtZ3JhaW4gTGFibGUgdG8gaWRlbnRpZnkgdGhlIHRyYWZmaWMgc2NvcGUuIFRoZSBkYXRhIHRy YWZmaWMgd2l0aCBhIGdpdmVuIFZMQU4teCwgY2FuDQpiZSBmb3J3YXJkZWQgdG8gb3RoZXIgZW5k IHN0YXRpb24gaW4gdGhlIGxvY2FsIGFyZWEsIG9yIHRvIHRoZSBlbmQgc3RhdGlvbiBpbiByZW1v dGUgYXJlYXMuDQoNCigyKSBuaWNrbmFtZSBhbGxvY2F0aW9uDQpUaGUgbmlja25hbWUgbWFuYWdl bWVudCBzdWItVExWIGlzIHByb3Bvc2VkIGluIHRoZSBkb2N1bWVudC4gSSB3b25kZXIgdGhpcyBt ZWNoYW5pc20gYWRkcyB0aGUgY29tcGxpY2F0aW9uIG9mDQpuaWNrbmFtZSBhbGxvY2F0aW9uLiBB cyB0aGUgc2VjdGlvbiAxIChpbnRyb2R1Y3Rpb24pIG9mIFJGQzYzMjUsIG9uZSBvZiB0aGUgaW1w b3J0YW50IGFkdmFudGFnZSBvZiBUUklMTCBpcyB0aGF0DQppdCBhdm9pZHMgdGhlIGNyZWF0aW5n IHN1Ym5ldHMgb2YgSVAgYWRkcmVzcyBhbmQgd2FzdGluZyBhZGRyZXNzLiBUaGUgbmlja25hbWUg YWNxdWlzaXRpb24gIG1ldGhvZCBpbiB0aGlzIGRyYWZ0IHZpb2xhdGVzIHRoZQ0KaWRlYSBvZiBU UklMTCBCYXNpYyBzcGVjaWZpY2F0aW9uLCBhbmQgcmVkdWNlcyB0aGUgZmxleGliaWxpdHkgb2Yg bmlja25hbWUgYWxsb2NhdGlvbi4gQXMgdGhlIGRyYWZ0IGFzc3VtZWQsIEExIGhhZA0Kbmlja25h bWUgcmFuZ2Ugb2YgMTAwLTIwMCwgQTIgaGFzIGEgbG9jYWwgbmlja25hbWUgcmFuZ2Ugb2YgMjAx LTMwMC4gSWYgdGhlIG51bWJlcnMgb2YgQTEgYXJlYSBpcyBvbmx5IDUwLCBzbyA1MA0Kbmlja25h bWVzIGluIEExIGlzIHdhc3RlZC4gQXMgdGhlIG5ldHdvcmsgZ3Jvd2luZywgdGhlIG51bWJlciBv ZiBzb21lIGFyZWFzIG1heSBleGNlZWQgdGhlIG51bWJlciBiZWluZyBhbGxvY2F0aW9uDQpieSBC b3JkZXIgUkJyaWRnZXMuIFRoZSBkZXNpZ24gYW5kIG1haW50YWluaW5nIG9mIG5pY2tuYW1lIHJh bmdlcyBmb3IgZWFjaCBhcmVhIGlzIGEgdmVyeSBoYXJkIHdvcmsuIEV2ZW4gd29yc3QsIGl0DQpj YW4gbm90IGF2b2lkIHRvIHdhc3RlIG5pY2tuYW1lIHNwYWNlLg0KDQooMykgRHluYW1pYyByYW5n ZXMNCiBUaGUgbmlja25hbWUgcmFuZ2UgaXMgZGl2aWRlZCBpbnRvIHR3byByYW5nZTogbG9jYWwg cmFuZ2UgYW5kIGR5bmFtaWNhbCByYW5nZS4gSSB3b25kZXIgdGhlIG5pY2tuYW1lIGNvbmZsaWN0 DQpyZXNvbHV0aW9uIGNhbiBub3Qgd29yayBpZiB0aGUgUkJyaWRnZSBnZXQgdGhlIG5pY2tuYW1l IGZyb20gdGhlIGR5bmFtaWNhbCByYW5nZSB3aGlsZSB0aGUgdHdvIFJCcmlkZ2UgYmVsb25ncyB0 bw0KZGlmZmVyZW50IGFyZWFzLiBGb3IgZXhhbXBsZSwgUkIxIGlzIGluIGFyZWEgQTEsIGFuZCBS QjIgaXMgaW4gYXJlYSBBMi4gSWYgUkIxIGdldHMgdGhlIG5pY2tuYW1lIE4xIGZyb20gZHluYW1p Yw0KcmFuZ2UsIGFuZCBpdCB3aWxsIGZsb29kcyBpbiBhcmVhIEExLCBhbmQgb3RoZXIgUkJyaWRn ZXMgaW4gYXJlYSBBMSBjYW4gbm90IGdldCBuaWNrbmFtZSBOMSBiZWNhdXNlIG9mIG5pY2tuYW1l DQpjb25mbGljdGlvbiBtZWNoYW5pc20sIGJ1dCBSQjIgaW4gYXJlYSBBMiBjYW4gbm90IHJlY2Vp dmUgdGhlIFBEVSBmcm9tIFJCMSwgYW5kIGl0ICBjYW4gYWxzbyBnZXQgdGhlIG5pY2tuYW1lIE4x IGZyb20NCmR5bmFtaWNhbCByYW5nZS4gU28gdGhlIHF1ZXN0aW9uIGlzIGhvdyB0byBhdm9pZCB0 aGUgZHVwbGljYXRpb24gZHluYW1pY2FsIHJhbmdlIG5pY2tuYW1lIGZvciBkaWZmZXJlbnQgYXJl YXMuDQoNCig0KSBUaGUgcmlzayBvZiBydW5uaW5nIG91dCBvZiBuaWNrbmFtZSBtYXliZSBhIGlz c3VlIGZvciBUUklMTC4gVGhlIG51bWJlciBvZiAyKioxNiBuaWNrbmFtZSBpcyBlbm91Z2ggZm9y IHRoZSBjdXJyZW50IGRhdGEgY2VudGVyLA0KIGJ1dCBpdCBtYXliZSBub3QgZW5vdWdoIGluIHRo ZSBmdXR1cmUsIGVzcGVjYWlsbHkgaWYgVFJJTEwgb3ZlciBJUCAsIFRSSUxMIG92ZXIgTVBMUyB0 ZWNobm9sb2d5IG9yIHNvbWUgb3RoZXIgZGF0YSBjZW50ZXIgdGVjaG5vbG9naWVzDQogYXJlIGRl cGxveWVkLCB0aGUgZGF0YSBjZW50ZXIgbmV0d29yayBjYW4gYmUgYSB2ZXJ5IGxhcmRnZSBuZXR3 b3JrLiBTbyBpIHRoaW5rIHRoZSB2ZXJ5IGltcG9ydGFudCBhbmQgZXNzZW50aWFsIGdvYWwgb2Yg bXVsdGktbGV2ZWwgZHJhZnQgaXMgdG8gc2F2ZSBuaWNrbmFtZXMuDQoNCkJlc3QgcmVnYXJkcw0K RmFuZ3dlaSBIdQ0KDQoiVGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZpcikiIDx0c2VuZXZpckBj aXNjby5jb208bWFpbHRvOnRzZW5ldmlyQGNpc2NvLmNvbT4+DQq3orz+yMs6ICByYnJpZGdlLWJv dW5jZXNAcG9zdGVsLm9yZzxtYWlsdG86cmJyaWRnZS1ib3VuY2VzQHBvc3RlbC5vcmc+DQoNCjIw MTItMDItMjMgMTE6NTUNCg0KytW8/sjLDQoNCjxyYnJpZGdlQHBvc3RlbC5vcmc8bWFpbHRvOnJi cmlkZ2VAcG9zdGVsLm9yZz4+DQoNCrOty80NCg0K1vfM4g0KDQpbcmJyaWRnZV0gRGVmYXVsdCBu aWNrbmFtZSBiYXNlIGFwcHJvYWNoIGZvciBtdWx0aWxldmVsIFRSSUxMLSAgICAgICAgZHJhZnQt dGlzc2EtdHJpbGwtbXVsdGlsZXZlbC0wMC50eHQNCg0KDQoNCg0KDQoNCg0KRGVhciBBbGwNCg0K V2UgaGF2ZSBzdWJtaXR0ZWQgZHJhZnQtdGlzc2EtdHJpbGwtbXVsdGlsZXZlbCwgcHJlc2VudCBt dWx0aWxldmVsIFRSSUxMIGJhc2VkIG9uIGRlZmF1bHQgbmlja25hbWUgYXBwcm9hY2guIEFkZGl0 aW9uYWxseSB3ZSBkaXNjdXNzIGNvbnN0cnVjdGlvbiBvZiBtdWx0aS1kZXN0aW5hdGlvbiB0cmVl cyBhbmQgcmVsYXRlZCBSUEYgaW4gbXVsdGlsZXZlbCBUUklMTC4gUGxlYXNlIGNvdWxkIHlvdSBy ZXZpZXcgYW5kIGNvbW1lbnQNCg0KRGV0YWlsIG9mIHRoZSBkcmFmdCBhbmQgYWJzdHJhY3QgYXJl IGJlbG93Lg0KDQpGaWxlbmFtZTogICAgICAgICAgICAgICAgICBkcmFmdC10aXNzYS10cmlsbC1t dWx0aWxldmVsDQpSZXZpc2lvbjogICAgICAgICAgICAgICAgICAwMA0KVGl0bGU6ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBEZWZhdWx0IE5pY2tuYW1lIEJhc2VkIEFwcHJvYWNo IGZvciBNdWx0aWxldmVsIFRSSUxMDQpDcmVhdGlvbiBkYXRlOiAgICAgICAgICAgICAgICAgIDIw MTItMDItMjENCldHIElEOiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSW5kaXZp ZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDI2DQoNCkFic3RyYWN0Og0KICBNdWx0 aWxldmVsIFRSSUxMIGFsbG93cyB0aGUgaW50ZXJjb25uZWN0aW9uIG9mIG11bHRpcGxlIFRSSUxM DQogIG5ldHdvcmtzIHRvIGZvcm0gYSBsYXJnZXIgVFJJTEwgbmV0d29yayB3aXRob3V0IHByb3Bv cnRpb25hbGx5DQogIGluY3JlYXNpbmcgdGhlIHNpemUgb2YgdGhlIElTLUlTIExTUCBEQi4gSW4g dGhpcyBkb2N1bWVudCwgYW4NCiAgYXBwcm9hY2ggYmFzZWQgb24gZGVmYXVsdCByb3V0ZSBjb25j ZXB0IGlzIHByZXNlbnRlZC4gQWxzbywNCiAgcHJlc2VudGVkIGluIHRoZSBkb2N1bWVudCBpcyBh IG5vdmVsIG1ldGhvZCBvZiBjb25zdHJ1Y3RpbmcgbXVsdGktDQogIGRlc3RpbmF0aW9uIHRyZWVz IHVzaW5nIHBhcnRpYWwgbmlja25hbWUgc3BhY2UuIE1ldGhvZHMgcHJlc2VudGVkIGluDQogIHRo aXMgZG9jdW1lbnQgYXJlIGNvbXBhdGlibGUgd2l0aCB0aGUgUkZDNjMyNSBzcGVjaWZpZWQgZGF0 YSBwbGFuZQ0KICBvcGVyYXRpb25zLg0KDQoNClRoYW5rcw0KVGlzc2ENCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnJicmlkZ2UgbWFpbGluZyBsaXN0 DQpyYnJpZGdlQHBvc3RlbC5vcmc8bWFpbHRvOnJicmlkZ2VAcG9zdGVsLm9yZz4NCmh0dHA6Ly9t YWlsbWFuLnBvc3RlbC5vcmcvbWFpbG1hbi9saXN0aW5mby9yYnJpZGdlDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpyYnJpZGdlIG1haWxpbmcgbGlz dA0KcmJyaWRnZUBwb3N0ZWwub3JnPG1haWx0bzpyYnJpZGdlQHBvc3RlbC5vcmc+DQpodHRwOi8v bWFpbG1hbi5wb3N0ZWwub3JnL21haWxtYW4vbGlzdGluZm8vcmJyaWRnZQ0KDQo= --_000_C5BD54C085F1DB4D9B6B5BFF7ACE182B355A42D0dfweml505mbx_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Changing the value in the= existing nickname TRILL Header slots at border RBridges can be done in a N= AT-like way or, with swap-nicknames, in a way which is not at all like NAT.

 <= /p>

Thanks,=

Donald<= /p>

=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=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D

Donald E. Eastlake, 3rd&n= bsp;    Donald.Eastlake@huawei.com

155 Beaver Street &n= bsp;            += ;1-508-333-2270

 Milford, MA 01757 U= SA

 <= /p>

From: rbridge-= bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Tissa Senevirathne (tsenevir)
Sent: Friday, February 24, 2012 11:23 AM
To: Radia Perlman; hu.fangwei@zte.com.cn
Cc: rbridge@postel.org; rbridge-bounces@postel.org
Subject: Re: [rbridge] Default nickname base approach for multilevel= TRILL- draft-tissa-trill-multilevel-00.txt

 

Mutli-topology is the ans= wer to increase the nickname space.

 <= /p>

Nickname translation is v= ery similar to NAT, which has it=A1=AFs own down side, not to mention speci= al hardware etc. to do the translations, additionally. We also know from our experience, in IP world NATing is not the most desired behav= ior and we live with it. So we should not be going down that path instead n= eed to look forward from that experience.

 <= /p>

Multi-topology not only a= ddress nickname space issue but also enables various other applications suc= h as overlay topologies, traffic engineering.

 <= /p>

The draft-tiss-trill-mult= ilevel present approaches that are generic, which mean it can be applied fo= r multi-topology, or base topology. It utilizes the fundamentals of IS-IS , such as Area hierarchy for reduction of the LSP-DB. It utilize = affinity TLV concepts to effectively solve multi-destination issues.

 <= /p>

We should not mix-up betw= een Data center interconnects with data center node scaling. They are two d= ifferent and orthogonal issues.

 <= /p>

Objective of multi-level = trill is to interconnect different datacenters, and maintain LSP-DB small a= s possible to avoid scaling and volatility.

 <= /p>

Increasing nickname space= a different requirement and has nothing to do with data-center interconnec= ts.

 <= /p>

 <= /p>

From: Radia Pe= rlman [mailto:radiaperlman@gmail.com]
Sent: Friday, February 24, 2012 6:15 AM
To: hu.fangwei@zte.com.cn
Cc: Tissa Senevirathne (tsenevir); rbridge@postel.org; rbridge-bounc= es@postel.org
Subject: Re: [rbridge] Default nickname base approach for multilevel= TRILL- draft-tissa-trill-multilevel-00.txt

 

People have mentioned to me that they are nervous ab= out running out of nicknames, especially since there are reasonson why they= might want to assign nicknames to hypervisors.  With the alternate ap= proach of allowing nicknames to be reused in different areas, it makes automatic nickname assignment much simpler an= d makes TRILL a lot more scalable.

 

It does have the downside of requiring mapping of ni= cknames at the border RBridges.

 

And by the way, the affinity TLV can be used for mul= tidestination frames transiting between level 1 and level 2.

 

Radia

2012/2/23 <hu.fangwei@zte.com.cn>


Hi, Ti= ssa.

I have= several comments about the draft.

(1) in= section 4.4 (Multicast), "The scope of global traffic may be identifi= ed either through VLAN or via finegrain
label = that spans across the entire TRILL campus."
Vlan a= nd Fine-grain Label is used for service differentiation and isolation. I do= not quite understand that how to
use VL= AN and fine-grain Lable to identify the traffic scope. The data traffic wit= h a given VLAN-x, can
be for= warded to other end station in the local area, or to the end station in rem= ote areas.

(2) ni= ckname allocation
The ni= ckname management sub-TLV is proposed in the document. I wonder this mechan= ism adds the complication of  
nickna= me allocation. As the section 1 (introduction) of RFC6325, one of the impor= tant advantage of TRILL is that  
it avo= ids the creating subnets of IP address and wasting address. The nickname ac= quisition  method in this draft violates the  
idea o= f TRILL Basic specification, and reduces the flexibility of nickname alloca= tion. As the draft assumed, A1 had  
nickna= me range of 100-200, A2 has a local nickname range of 201-300. If the numbe= rs of A1 area is only 50, so 50  
nickna= mes in A1 is wasted. As the network growing, the number of some areas may e= xceed the number being allocation  
by Bor= der RBridges. The design and maintaining of nickname ranges for each area i= s a very hard work. Even worst, it  
can no= t avoid to waste nickname space.

(3) Dy= namic ranges
 = The nickname range is divided into two range: local range and dynamical ran= ge. I wonder the nickname conflict  
resolu= tion can not work if the RBridge get the nickname from the dynamical range = while the two RBridge belongs to  
differ= ent areas. For example, RB1 is in area A1, and RB2 is in area A2. If RB1 ge= ts the nickname N1 from dynamic  
range,= and it will floods in area A1, and other RBridges in area A1 can not get n= ickname N1 because of nickname  
confli= ction mechanism, but RB2 in area A2 can not receive the PDU from RB1, and i= t  can also get the nickname N1 from  
dynami= cal range. So the question is how to avoid the duplication dynamical range = nickname for different areas.

(4) Th= e risk of running out of nickname maybe a issue for TRILL. The number of 2*= *16 nickname is enough for the current data center,
 = but it maybe not enough in the future, especailly if TRILL over IP , TRILL = over MPLS technology or some other data center technologies
 = are deployed, the data center network can be a very lardge network. So i th= ink the very important and essential goal of multi-level draft is to save n= icknames.

Best r= egards
Fangwe= i Hu

"Tissa Senevirathne (tsenevir)&quo= t; <tsenevir@cis= co.com>
=B7=A2=BC=FE=C8=CB:  rbridge-bounces@postel.org

2012-02-23 11:55

=CA=D5=BC=FE=C8=CB<= /p>

<rbridge@postel.org>

=B3=AD=CB=CD

=D6=F7=CC=E2

[rbridge] Default nickname base approach f= or multilevel TRILL-        draft-tissa-trill-multileve= l-00.txt

 




Dear All

We have submitted draft-tissa-trill-multilevel, present multilevel TRIL= L based on default nickname approach. Additionally we discuss construction = of multi-destination trees and related RPF in multilevel TRILL. Please coul= d you review and comment

Detail of the draft and abstract are below.

Filename:                  = ;draft-tissa-trill-multilevel
Revision:                  = ;00
Title:                   &= nbsp;               Default Nickname Bas= ed Approach for Multilevel TRILL
Creation date:                 =  2012-02-21
WG ID:                   &= nbsp;               Individual Submissio= n
Number of pages: 26

Abstract:
  Multilevel TRILL allows the interconnection of multiple TRILL
  networks to form a larger TRILL network without proportionally
  increasing the size of the IS-IS LSP DB. In this document, an
  approach based on default route concept is presented. Also,=
  presented in the document is a novel method of constructing mult= i-
  destination trees using partial nickname space. Methods presente= d in
  this document are compatible with the RFC6325 specified data pla= ne
  operations.

                    &= nbsp;                    =                     &nbs= p;                  
Thanks
Tissa

_______________________________________________
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

 

--_000_C5BD54C085F1DB4D9B6B5BFF7ACE182B355A42D0dfweml505mbx_-- --===============1988093119== 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 --===============1988093119==-- From rbridge-bounces@postel.org Fri Feb 24 11:14:39 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 7BDBF21F86E2 for ; Fri, 24 Feb 2012 11:14:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.394 X-Spam-Level: X-Spam-Status: No, score=-2.394 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 yJSR22U3vpld for ; Fri, 24 Feb 2012 11:14:37 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 78E7921F86CA for ; Fri, 24 Feb 2012 11:14:37 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1OIloqS001682; Fri, 24 Feb 2012 10:47:53 -0800 (PST) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1OIlOeH001651 for ; Fri, 24 Feb 2012 10:47:33 -0800 (PST) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id ADW22957; Fri, 24 Feb 2012 13:47:24 -0500 (EST) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 24 Feb 2012 10:44:50 -0800 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Sat, 25 Feb 2012 02:44:54 +0800 From: Donald Eastlake To: "Tissa Senevirathne (tsenevir)" , Radia Perlman Thread-Topic: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.txt Thread-Index: AQHM8xj4bt2qI1nfQfiYK8zrqzIBUJZM3BiA//+EDXA= Date: Fri, 24 Feb 2012 18:44:07 +0000 Message-ID: References: <344037D7CFEFE84E97E9CC1F56C5F4A5A45E88@xmb-sjc-214.amer.cisco.com><344037D7CFEFE84E97E9CC1F56C5F4A5A462E7@xmb-sjc-214.amer.cisco.com><344037D7CFEFE84E97E9CC1F56C5F4A5A46325@xmb-sjc-214.amer.cisco.com> <344037D7CFEFE84E97E9CC1F56C5F4A5A46358@xmb-sjc-214.amer.cisco.com> In-Reply-To: <344037D7CFEFE84E97E9CC1F56C5F4A5A46358@xmb-sjc-214.amer.cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.34.150] MIME-Version: 1.0 X-CFilter-Loop: Reflected X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@huawei.com Cc: "rbridge@postel.org" , "hu.fangwei@zte.com.cn" Subject: Re: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.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: multipart/mixed; boundary="===============1662230294==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org --===============1662230294== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_C5BD54C085F1DB4D9B6B5BFF7ACE182B355A4302dfweml505mbx_" --_000_C5BD54C085F1DB4D9B6B5BFF7ACE182B355A4302dfweml505mbx_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 U2VlIGJlbG93IGF0IDxkZWUzPi4NCg0KRnJvbTogcmJyaWRnZS1ib3VuY2VzQHBvc3RlbC5vcmcg W21haWx0bzpyYnJpZGdlLWJvdW5jZXNAcG9zdGVsLm9yZ10gT24gQmVoYWxmIE9mIFRpc3NhIFNl bmV2aXJhdGhuZSAodHNlbmV2aXIpDQpTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDI0LCAyMDEyIDE6 MDAgUE0NClRvOiBSYWRpYSBQZXJsbWFuDQpDYzogcmJyaWRnZUBwb3N0ZWwub3JnOyByYnJpZGdl LWJvdW5jZXNAcG9zdGVsLm9yZzsgaHUuZmFuZ3dlaUB6dGUuY29tLmNuDQpTdWJqZWN0OiBSZTog W3JicmlkZ2VdIERlZmF1bHQgbmlja25hbWUgYmFzZSBhcHByb2FjaCBmb3IgbXVsdGlsZXZlbCBU UklMTC0gZHJhZnQtdGlzc2EtdHJpbGwtbXVsdGlsZXZlbC0wMC50eHQNCg0KUkJyaWRnZXMgZG8g bm90IGhhdmUgdG8gYmUgaW4gYWxsIHRvcG9sb2dpZXMuIFdoeSB3b3VsZCB0aGV5IHNob3VsZCBi ZT8NCg0KPGRlZTM+IEkgd291bGQgYWdyZWUgdGhhdCBhbiBSQnJpZGdlIGRvZXMgbm90IGhhdmUg dG8gYmUgaW4gYWxsIHRvcG9sb2dpZXMgYWx0aG91Z2ggSSB0aGluayBpdCB3aWxsIGJlIGNvbW1v biBmb3Igc29tZSBSQnJpZGdlcyB0byBiZSBpbiBtYW55IHRvcG9sb2dpZXMuDQoNCjxkZWUzPiBJ IHZpZXcgYSBuaWNrbmFtZSBhcyBhbiBhYmJyZXZpYXRpb24gb2YgdGhlIDQ4LWJpdCBJUy1JUyBT eXN0ZW0gSUQuIFRoZSBkaWZmZXJlbmNlcyBiZWluZyB0aGF0IGl0IGlzIHNob3J0ZXIsIGlzIGF1 dG8gYWxsb2NhdGVkIGJ5IGRlZmF1bHQsIGFuZCB0aGVyZSBjYW4gYmUgbW9yZSB0aGFuIG9uZSBv ZiB0aGVtIHRoYXQgbWFwIHRvIHRoZSBzYW1lIFN5c3RlbSBJRCBzbyB0aGF0IGFuIFJCcmlkZ2Ug Y2FuIGJlIHRoZSByb290IG9mIG1vcmUgdGhhbiBvbmUgZGlzdHJpYnV0aW9uIHRyZWUgYW5kIHNv IHRoYXQgdGhlcmUgY291bGQgYmUgYW4gZWdyZXNzIG5pY2tuYW1lIHRoYXQgdXNlcyB0cmFmZmlj IGVuZ2luZWVyZWQgcm91dGluZyByYXRoZXIgdGhhbiB0aGUgZGVmYXVsdCBsZWFzdCBjb3N0IHJv dXRpbmcuIEludGVybWVkaWF0ZSBTeXN0ZW1zIGRvIG5vdCBoYXZlIGRpZmZlcmVudCBTeXN0ZW0g IElEcyBpbiBkaWZmZXJlbnQgdG9wb2xvZ2llcywgYXMgZmFyIGFzIEkga25vdy4gSSBkb26hr3Qg c2VlIGhvdy93aHkgdGhleSB3b3VsZCBoYXZlIGRpZmZlcmVudCBuaWNrbmFtZXMgaW4gZGlmZmVy ZW50IHRvcG9sb2dpZXMuDQoNCldoYXQgaXMgRnVsY3J1bSBjaGlwID8NCg0KPGRlZTM+IFRoZSBm b3VyIG1lcmNoYW50IHNpbGljb24gbWFudWZhY3R1cmVycyB0aGF0IEkga25vdyBvZiB0aGF0IGhh dmUgYW5ub3VuY2VkIHN1cHBvcnQgZm9yIFRSSUxMIGFyZSwgaW4gYWxwaGFiZXRpYyBvcmRlciwg QnJvYWRjb20sIEZ1bGNydW0sIE1hcnZlbCwgYW5kIE1lbGxhbm94LiAoRnVsY3J1bSBoYXMgYmVl biBhY3F1aXJlZCBieSBJbnRlbC4pDQoNClRoYW5rcywNCkRvbmFsZA0KPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpEb25hbGQgRS4gRWFzdGxha2UsIDNyZCAgICAg RG9uYWxkLkVhc3RsYWtlQGh1YXdlaS5jb20NCjE1NSBCZWF2ZXIgU3RyZWV0ICAgICAgICAgICAg ICArMS01MDgtMzMzLTIyNzANCiBNaWxmb3JkLCBNQSAwMTc1NyBVU0ENCg0KDQpGcm9tOiBSYWRp YSBQZXJsbWFuIFttYWlsdG86cmFkaWFwZXJsbWFuQGdtYWlsLmNvbV0NClNlbnQ6IEZyaWRheSwg RmVicnVhcnkgMjQsIDIwMTIgOToyMyBBTQ0KVG86IFRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2 aXIpDQpDYzogaHUuZmFuZ3dlaUB6dGUuY29tLmNuOyByYnJpZGdlQHBvc3RlbC5vcmc7IHJicmlk Z2UtYm91bmNlc0Bwb3N0ZWwub3JnDQpTdWJqZWN0OiBSZTogW3JicmlkZ2VdIERlZmF1bHQgbmlj a25hbWUgYmFzZSBhcHByb2FjaCBmb3IgbXVsdGlsZXZlbCBUUklMTC0gZHJhZnQtdGlzc2EtdHJp bGwtbXVsdGlsZXZlbC0wMC50eHQNCg0KSSBhc3N1bWUgdGhhdCBhbGwgUkJyaWRnZXMgd2lsbCBu ZWVkIHRvIGJlIGluIGFsbCB0b3BvbG9naWVzLCBzbyBtdWx0aXRvcG9sb2d5IHdpbGwgbm90IGhl bHAgd2l0aCBuaWNrbmFtZSBleGhhdXN0aW9uLiAgUGx1cyB5b3UgaGF2ZW4ndCBleHBsYWluZWQg aG93IGEgVFJJTEwgcGFja2V0IHdvdWxkIGJlIG1hcmtlZCBhcyB0byB3aGljaCB0b3BvbG9neSB0 aGUgcGFja2V0IHNob3VsZCBiZSByb3V0ZWQgYWNjb3JkaW5nIHRvIChvdGhlciB0aGFuIHdoYXQg SSBtZW50aW9uZWQsIHdoaWNoIGFjdHVhbGx5IGVhdHMgdXAgbmlja25hbWVzIGJ5IGEgZmFjdG9y IG9mIHRoZSBudW1iZXIgb2YgdG9wb2xvZ2llcyBzdXBwb3J0ZWQpLg0KDQpQbHVzLCByYXRoZXIg dGhhbiBqdXN0IGx1bXBpbmcgcG90ZW50aWFsIGlzc3VlcyBpbnRvIGEgcGhyYXNlIHN1Y2ggYXMg Ik5BVC1saWtlIiwgYmUgZXhwbGljaXQgYWJvdXQgd2hhdCBpc3N1ZXMgdGhlcmUgYWN0dWFsbHkg YXJlLiAgSSBiZWxpZXZlIHRoZSBGdWxjcnVtIGNoaXAgd291bGQgaGF2ZSBubyBwcm9ibGVtIHdp dGggdHJhbnNsYXRpbmcgdGhlIG5pY2tuYW1lIGZpZWxkcy4NCg0KQW5kIHJhdGhlciB0aGFuIGFz c3VtaW5nIHRoYXQgbmlja25hbWUgZXhoYXVzdGlvbiBjYW4gYmUgc29sdmVkICJzb21lIG90aGVy IHdheSIsIHRoZXJlIHNob3VsZCBiZSBhIHBhbGF0YWJsZSBzb2x1dGlvbiBiZWZvcmUgcmVqZWN0 aW5nIGEgY2hhbmNlIHRvIHNvbHZlIGl0IHdpdGggbXVsdGlsZXZlbC4NCg0KUmFkaWENCjIwMTIv Mi8yNCBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKSA8dHNlbmV2aXJAY2lzY28uY29tPG1h aWx0bzp0c2VuZXZpckBjaXNjby5jb20+Pg0KQmVjYXVzZSB5b3UgY2FuIGhhdmUgc2FtZSBuaWNr bmFtZSBmb3IgZGlmZmVyZW50IHRvcG9sb2d5LiBJdCBpcyBub3QgYSBuaWNrbmFtZSB0aGF0IHdp bGwgaWRlbnRpZnkgYW4gUkJSaWRnZSwgaXQgaXMgdG9wb2xvZ3ksbmlja25hbWUgY29tYmluYXRp b24gdGhhdCB3aWxsIGlkZW50aWZ5IGFuIFJCUmlkZ2UuIFNvIFJCMSBjYW4gaGF2ZSBuaWNrbmFt ZSAxIGluIHRvcG8tMSBhbmQgUkIyIGNhbiBoYXZlIG5pY2tuYW1lIDEgaW4gdG9wbzIuIE5vdyB0 b3RhbCBuaWNrbmFtZXMgaW4gdGhlIGNhbXB1cyBpcyAyKioxNiB4IHRvcG9sb2dpZXMuDQoNClN0 ZWFsaW5nIGJpdHMgdG8gcmVwcmVzZW50IHRvcG8gaWQgaXMgb25seSBhIHdvcmthcm91bmQgdGhl cmUgY2FuIGJlIChhcmUgKSBtb3JlIGVsZWdhbnQgd2F5cyBvZiBkb2luZyBpdCB0aGF0Lg0KDQpC b3R0b20gbGluZSBpcyB3ZSBuZWVkIHRvIGxvb2sgZm9yIG1vcmUgY3JlYXRpdmUgbWV0aG9kcyBv ZiBzb2x2aW5nIG5pY2tuYW1lIHNwYWNlIGlzc3VlIHRoYW4gZG9pbmcgTkFUIGxpa2UgYmVoYXZp b3IuDQoNCkZyb206IFJhZGlhIFBlcmxtYW4gW21haWx0bzpyYWRpYXBlcmxtYW5AZ21haWwuY29t PG1haWx0bzpyYWRpYXBlcmxtYW5AZ21haWwuY29tPl0NClNlbnQ6IEZyaWRheSwgRmVicnVhcnkg MjQsIDIwMTIgOTowNSBBTQ0KVG86IFRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpDQpDYzog aHUuZmFuZ3dlaUB6dGUuY29tLmNuPG1haWx0bzpodS5mYW5nd2VpQHp0ZS5jb20uY24+OyByYnJp ZGdlQHBvc3RlbC5vcmc8bWFpbHRvOnJicmlkZ2VAcG9zdGVsLm9yZz47IHJicmlkZ2UtYm91bmNl c0Bwb3N0ZWwub3JnPG1haWx0bzpyYnJpZGdlLWJvdW5jZXNAcG9zdGVsLm9yZz4NCg0KU3ViamVj dDogUmU6IFtyYnJpZGdlXSBEZWZhdWx0IG5pY2tuYW1lIGJhc2UgYXBwcm9hY2ggZm9yIG11bHRp bGV2ZWwgVFJJTEwtIGRyYWZ0LXRpc3NhLXRyaWxsLW11bHRpbGV2ZWwtMDAudHh0DQoNCkkgZG9u J3QgdW5kZXJzdGFuZCBob3cgbXVsdGktdG9wb2xvZ3kgaGVscHMgd2l0aCB0aGUgbmlja25hbWUg ZXhoYXVzdGlvbiBpc3N1ZS4gIEFzIGEgbWF0dGVyIG9mIGZhY3QsIHRoZSBvbmx5IHBsYXVzaWJs ZSB3YXkgb2YgbWFya2luZyBhIHBhY2tldCBmb3Igd2hpY2ggdG9wb2xvZ3kgdGhhdCBoYXMgYmVl biBzdWdnZXN0ZWQgb24gdGhlIG1haWxpbmcgbGlzdCAoSSBhc2tlZCBhIGVmdyB0aW1lcyBpZiB0 aGVyZSB3ZXJlIGFueSBvdGhlciBwb3NzaWJpbGl0aWVzKSwgd2FzIHRvIHN0ZWFsIDIgb3IgMyBi aXRzIG9mIHRoZSBuaWNrbmFtZSB0byBlbmNvZGUgd2hpY2ggdG9wb2xvZ3ksIGluIGVmZmVjdCwg bWFraW5nIGEgZGVzdGluYXRpb24gYXBwZWFyIGFzIG11bHRpcGxlIGRlc3RpbmF0aW9ucyBhbmQg bXVsdGlwbGUgZm9yd2FyZGluZyB0YWJsZSBlbnRyaWVzICh3aGljaCB5b3UnZCB3YW50IGFueXdh eSwgZm9yIG11bHRpdG9wb2xvZ3kpLg0KDQoNClJhZGlhDQoyMDEyLzIvMjQgVGlzc2EgU2VuZXZp cmF0aG5lICh0c2VuZXZpcikgPHRzZW5ldmlyQGNpc2NvLmNvbTxtYWlsdG86dHNlbmV2aXJAY2lz Y28uY29tPj4NCk11dGxpLXRvcG9sb2d5IGlzIHRoZSBhbnN3ZXIgdG8gaW5jcmVhc2UgdGhlIG5p Y2tuYW1lIHNwYWNlLg0KDQpOaWNrbmFtZSB0cmFuc2xhdGlvbiBpcyB2ZXJ5IHNpbWlsYXIgdG8g TkFULCB3aGljaCBoYXMgaXShr3Mgb3duIGRvd24gc2lkZSwgbm90IHRvIG1lbnRpb24gc3BlY2lh bCBoYXJkd2FyZSBldGMuIHRvIGRvIHRoZSB0cmFuc2xhdGlvbnMsIGFkZGl0aW9uYWxseS4gV2Ug YWxzbyBrbm93IGZyb20gb3VyIGV4cGVyaWVuY2UsIGluIElQIHdvcmxkIE5BVGluZyBpcyBub3Qg dGhlIG1vc3QgZGVzaXJlZCBiZWhhdmlvciBhbmQgd2UgbGl2ZSB3aXRoIGl0LiBTbyB3ZSBzaG91 bGQgbm90IGJlIGdvaW5nIGRvd24gdGhhdCBwYXRoIGluc3RlYWQgbmVlZCB0byBsb29rIGZvcndh cmQgZnJvbSB0aGF0IGV4cGVyaWVuY2UuDQoNCk11bHRpLXRvcG9sb2d5IG5vdCBvbmx5IGFkZHJl c3Mgbmlja25hbWUgc3BhY2UgaXNzdWUgYnV0IGFsc28gZW5hYmxlcyB2YXJpb3VzIG90aGVyIGFw cGxpY2F0aW9ucyBzdWNoIGFzIG92ZXJsYXkgdG9wb2xvZ2llcywgdHJhZmZpYyBlbmdpbmVlcmlu Zy4NCg0KVGhlIGRyYWZ0LXRpc3MtdHJpbGwtbXVsdGlsZXZlbCBwcmVzZW50IGFwcHJvYWNoZXMg dGhhdCBhcmUgZ2VuZXJpYywgd2hpY2ggbWVhbiBpdCBjYW4gYmUgYXBwbGllZCBmb3IgbXVsdGkt dG9wb2xvZ3ksIG9yIGJhc2UgdG9wb2xvZ3kuIEl0IHV0aWxpemVzIHRoZSBmdW5kYW1lbnRhbHMg b2YgSVMtSVMgLCBzdWNoIGFzIEFyZWEgaGllcmFyY2h5IGZvciByZWR1Y3Rpb24gb2YgdGhlIExT UC1EQi4gSXQgdXRpbGl6ZSBhZmZpbml0eSBUTFYgY29uY2VwdHMgdG8gZWZmZWN0aXZlbHkgc29s dmUgbXVsdGktZGVzdGluYXRpb24gaXNzdWVzLg0KDQpXZSBzaG91bGQgbm90IG1peC11cCBiZXR3 ZWVuIERhdGEgY2VudGVyIGludGVyY29ubmVjdHMgd2l0aCBkYXRhIGNlbnRlciBub2RlIHNjYWxp bmcuIFRoZXkgYXJlIHR3byBkaWZmZXJlbnQgYW5kIG9ydGhvZ29uYWwgaXNzdWVzLg0KDQpPYmpl Y3RpdmUgb2YgbXVsdGktbGV2ZWwgdHJpbGwgaXMgdG8gaW50ZXJjb25uZWN0IGRpZmZlcmVudCBk YXRhY2VudGVycywgYW5kIG1haW50YWluIExTUC1EQiBzbWFsbCBhcyBwb3NzaWJsZSB0byBhdm9p ZCBzY2FsaW5nIGFuZCB2b2xhdGlsaXR5Lg0KDQpJbmNyZWFzaW5nIG5pY2tuYW1lIHNwYWNlIGEg ZGlmZmVyZW50IHJlcXVpcmVtZW50IGFuZCBoYXMgbm90aGluZyB0byBkbyB3aXRoIGRhdGEtY2Vu dGVyIGludGVyY29ubmVjdHMuDQoNCg0KRnJvbTogUmFkaWEgUGVybG1hbiBbbWFpbHRvOnJhZGlh cGVybG1hbkBnbWFpbC5jb208bWFpbHRvOnJhZGlhcGVybG1hbkBnbWFpbC5jb20+XQ0KU2VudDog RnJpZGF5LCBGZWJydWFyeSAyNCwgMjAxMiA2OjE1IEFNDQpUbzogaHUuZmFuZ3dlaUB6dGUuY29t LmNuPG1haWx0bzpodS5mYW5nd2VpQHp0ZS5jb20uY24+DQpDYzogVGlzc2EgU2VuZXZpcmF0aG5l ICh0c2VuZXZpcik7IHJicmlkZ2VAcG9zdGVsLm9yZzxtYWlsdG86cmJyaWRnZUBwb3N0ZWwub3Jn PjsgcmJyaWRnZS1ib3VuY2VzQHBvc3RlbC5vcmc8bWFpbHRvOnJicmlkZ2UtYm91bmNlc0Bwb3N0 ZWwub3JnPg0KU3ViamVjdDogUmU6IFtyYnJpZGdlXSBEZWZhdWx0IG5pY2tuYW1lIGJhc2UgYXBw cm9hY2ggZm9yIG11bHRpbGV2ZWwgVFJJTEwtIGRyYWZ0LXRpc3NhLXRyaWxsLW11bHRpbGV2ZWwt MDAudHh0DQoNClBlb3BsZSBoYXZlIG1lbnRpb25lZCB0byBtZSB0aGF0IHRoZXkgYXJlIG5lcnZv dXMgYWJvdXQgcnVubmluZyBvdXQgb2Ygbmlja25hbWVzLCBlc3BlY2lhbGx5IHNpbmNlIHRoZXJl IGFyZSByZWFzb25zb24gd2h5IHRoZXkgbWlnaHQgd2FudCB0byBhc3NpZ24gbmlja25hbWVzIHRv IGh5cGVydmlzb3JzLiAgV2l0aCB0aGUgYWx0ZXJuYXRlIGFwcHJvYWNoIG9mIGFsbG93aW5nIG5p Y2tuYW1lcyB0byBiZSByZXVzZWQgaW4gZGlmZmVyZW50IGFyZWFzLCBpdCBtYWtlcyBhdXRvbWF0 aWMgbmlja25hbWUgYXNzaWdubWVudCBtdWNoIHNpbXBsZXIgYW5kIG1ha2VzIFRSSUxMIGEgbG90 IG1vcmUgc2NhbGFibGUuDQoNCkl0IGRvZXMgaGF2ZSB0aGUgZG93bnNpZGUgb2YgcmVxdWlyaW5n IG1hcHBpbmcgb2Ygbmlja25hbWVzIGF0IHRoZSBib3JkZXIgUkJyaWRnZXMuDQoNCkFuZCBieSB0 aGUgd2F5LCB0aGUgYWZmaW5pdHkgVExWIGNhbiBiZSB1c2VkIGZvciBtdWx0aWRlc3RpbmF0aW9u IGZyYW1lcyB0cmFuc2l0aW5nIGJldHdlZW4gbGV2ZWwgMSBhbmQgbGV2ZWwgMi4NCg0KUmFkaWEN CjIwMTIvMi8yMyA8aHUuZmFuZ3dlaUB6dGUuY29tLmNuPG1haWx0bzpodS5mYW5nd2VpQHp0ZS5j b20uY24+Pg0KDQpIaSwgVGlzc2EuDQoNCkkgaGF2ZSBzZXZlcmFsIGNvbW1lbnRzIGFib3V0IHRo ZSBkcmFmdC4NCg0KKDEpIGluIHNlY3Rpb24gNC40IChNdWx0aWNhc3QpLCAiVGhlIHNjb3BlIG9m IGdsb2JhbCB0cmFmZmljIG1heSBiZSBpZGVudGlmaWVkIGVpdGhlciB0aHJvdWdoIFZMQU4gb3Ig dmlhIGZpbmVncmFpbg0KbGFiZWwgdGhhdCBzcGFucyBhY3Jvc3MgdGhlIGVudGlyZSBUUklMTCBj YW1wdXMuIg0KVmxhbiBhbmQgRmluZS1ncmFpbiBMYWJlbCBpcyB1c2VkIGZvciBzZXJ2aWNlIGRp ZmZlcmVudGlhdGlvbiBhbmQgaXNvbGF0aW9uLiBJIGRvIG5vdCBxdWl0ZSB1bmRlcnN0YW5kIHRo YXQgaG93IHRvDQp1c2UgVkxBTiBhbmQgZmluZS1ncmFpbiBMYWJsZSB0byBpZGVudGlmeSB0aGUg dHJhZmZpYyBzY29wZS4gVGhlIGRhdGEgdHJhZmZpYyB3aXRoIGEgZ2l2ZW4gVkxBTi14LCBjYW4N CmJlIGZvcndhcmRlZCB0byBvdGhlciBlbmQgc3RhdGlvbiBpbiB0aGUgbG9jYWwgYXJlYSwgb3Ig dG8gdGhlIGVuZCBzdGF0aW9uIGluIHJlbW90ZSBhcmVhcy4NCg0KKDIpIG5pY2tuYW1lIGFsbG9j YXRpb24NClRoZSBuaWNrbmFtZSBtYW5hZ2VtZW50IHN1Yi1UTFYgaXMgcHJvcG9zZWQgaW4gdGhl IGRvY3VtZW50LiBJIHdvbmRlciB0aGlzIG1lY2hhbmlzbSBhZGRzIHRoZSBjb21wbGljYXRpb24g b2YNCm5pY2tuYW1lIGFsbG9jYXRpb24uIEFzIHRoZSBzZWN0aW9uIDEgKGludHJvZHVjdGlvbikg b2YgUkZDNjMyNSwgb25lIG9mIHRoZSBpbXBvcnRhbnQgYWR2YW50YWdlIG9mIFRSSUxMIGlzIHRo YXQNCml0IGF2b2lkcyB0aGUgY3JlYXRpbmcgc3VibmV0cyBvZiBJUCBhZGRyZXNzIGFuZCB3YXN0 aW5nIGFkZHJlc3MuIFRoZSBuaWNrbmFtZSBhY3F1aXNpdGlvbiAgbWV0aG9kIGluIHRoaXMgZHJh ZnQgdmlvbGF0ZXMgdGhlDQppZGVhIG9mIFRSSUxMIEJhc2ljIHNwZWNpZmljYXRpb24sIGFuZCBy ZWR1Y2VzIHRoZSBmbGV4aWJpbGl0eSBvZiBuaWNrbmFtZSBhbGxvY2F0aW9uLiBBcyB0aGUgZHJh ZnQgYXNzdW1lZCwgQTEgaGFkDQpuaWNrbmFtZSByYW5nZSBvZiAxMDAtMjAwLCBBMiBoYXMgYSBs b2NhbCBuaWNrbmFtZSByYW5nZSBvZiAyMDEtMzAwLiBJZiB0aGUgbnVtYmVycyBvZiBBMSBhcmVh IGlzIG9ubHkgNTAsIHNvIDUwDQpuaWNrbmFtZXMgaW4gQTEgaXMgd2FzdGVkLiBBcyB0aGUgbmV0 d29yayBncm93aW5nLCB0aGUgbnVtYmVyIG9mIHNvbWUgYXJlYXMgbWF5IGV4Y2VlZCB0aGUgbnVt YmVyIGJlaW5nIGFsbG9jYXRpb24NCmJ5IEJvcmRlciBSQnJpZGdlcy4gVGhlIGRlc2lnbiBhbmQg bWFpbnRhaW5pbmcgb2Ygbmlja25hbWUgcmFuZ2VzIGZvciBlYWNoIGFyZWEgaXMgYSB2ZXJ5IGhh cmQgd29yay4gRXZlbiB3b3JzdCwgaXQNCmNhbiBub3QgYXZvaWQgdG8gd2FzdGUgbmlja25hbWUg c3BhY2UuDQoNCigzKSBEeW5hbWljIHJhbmdlcw0KIFRoZSBuaWNrbmFtZSByYW5nZSBpcyBkaXZp ZGVkIGludG8gdHdvIHJhbmdlOiBsb2NhbCByYW5nZSBhbmQgZHluYW1pY2FsIHJhbmdlLiBJIHdv bmRlciB0aGUgbmlja25hbWUgY29uZmxpY3QNCnJlc29sdXRpb24gY2FuIG5vdCB3b3JrIGlmIHRo ZSBSQnJpZGdlIGdldCB0aGUgbmlja25hbWUgZnJvbSB0aGUgZHluYW1pY2FsIHJhbmdlIHdoaWxl IHRoZSB0d28gUkJyaWRnZSBiZWxvbmdzIHRvDQpkaWZmZXJlbnQgYXJlYXMuIEZvciBleGFtcGxl LCBSQjEgaXMgaW4gYXJlYSBBMSwgYW5kIFJCMiBpcyBpbiBhcmVhIEEyLiBJZiBSQjEgZ2V0cyB0 aGUgbmlja25hbWUgTjEgZnJvbSBkeW5hbWljDQpyYW5nZSwgYW5kIGl0IHdpbGwgZmxvb2RzIGlu IGFyZWEgQTEsIGFuZCBvdGhlciBSQnJpZGdlcyBpbiBhcmVhIEExIGNhbiBub3QgZ2V0IG5pY2tu YW1lIE4xIGJlY2F1c2Ugb2Ygbmlja25hbWUNCmNvbmZsaWN0aW9uIG1lY2hhbmlzbSwgYnV0IFJC MiBpbiBhcmVhIEEyIGNhbiBub3QgcmVjZWl2ZSB0aGUgUERVIGZyb20gUkIxLCBhbmQgaXQgIGNh biBhbHNvIGdldCB0aGUgbmlja25hbWUgTjEgZnJvbQ0KZHluYW1pY2FsIHJhbmdlLiBTbyB0aGUg cXVlc3Rpb24gaXMgaG93IHRvIGF2b2lkIHRoZSBkdXBsaWNhdGlvbiBkeW5hbWljYWwgcmFuZ2Ug bmlja25hbWUgZm9yIGRpZmZlcmVudCBhcmVhcy4NCg0KKDQpIFRoZSByaXNrIG9mIHJ1bm5pbmcg b3V0IG9mIG5pY2tuYW1lIG1heWJlIGEgaXNzdWUgZm9yIFRSSUxMLiBUaGUgbnVtYmVyIG9mIDIq KjE2IG5pY2tuYW1lIGlzIGVub3VnaCBmb3IgdGhlIGN1cnJlbnQgZGF0YSBjZW50ZXIsDQogYnV0 IGl0IG1heWJlIG5vdCBlbm91Z2ggaW4gdGhlIGZ1dHVyZSwgZXNwZWNhaWxseSBpZiBUUklMTCBv dmVyIElQICwgVFJJTEwgb3ZlciBNUExTIHRlY2hub2xvZ3kgb3Igc29tZSBvdGhlciBkYXRhIGNl bnRlciB0ZWNobm9sb2dpZXMNCiBhcmUgZGVwbG95ZWQsIHRoZSBkYXRhIGNlbnRlciBuZXR3b3Jr IGNhbiBiZSBhIHZlcnkgbGFyZGdlIG5ldHdvcmsuIFNvIGkgdGhpbmsgdGhlIHZlcnkgaW1wb3J0 YW50IGFuZCBlc3NlbnRpYWwgZ29hbCBvZiBtdWx0aS1sZXZlbCBkcmFmdCBpcyB0byBzYXZlIG5p Y2tuYW1lcy4NCg0KQmVzdCByZWdhcmRzDQpGYW5nd2VpIEh1DQoiVGlzc2EgU2VuZXZpcmF0aG5l ICh0c2VuZXZpcikiIDx0c2VuZXZpckBjaXNjby5jb208bWFpbHRvOnRzZW5ldmlyQGNpc2NvLmNv bT4+DQq3orz+yMs6ICByYnJpZGdlLWJvdW5jZXNAcG9zdGVsLm9yZzxtYWlsdG86cmJyaWRnZS1i b3VuY2VzQHBvc3RlbC5vcmc+DQoNCjIwMTItMDItMjMgMTE6NTUNCg0KytW8/sjLDQoNCjxyYnJp ZGdlQHBvc3RlbC5vcmc8bWFpbHRvOnJicmlkZ2VAcG9zdGVsLm9yZz4+DQoNCrOty80NCg0K1vfM 4g0KDQpbcmJyaWRnZV0gRGVmYXVsdCBuaWNrbmFtZSBiYXNlIGFwcHJvYWNoIGZvciBtdWx0aWxl dmVsIFRSSUxMLSAgICAgICAgZHJhZnQtdGlzc2EtdHJpbGwtbXVsdGlsZXZlbC0wMC50eHQNCg0K DQoNCg0KDQoNCg0KRGVhciBBbGwNCg0KV2UgaGF2ZSBzdWJtaXR0ZWQgZHJhZnQtdGlzc2EtdHJp bGwtbXVsdGlsZXZlbCwgcHJlc2VudCBtdWx0aWxldmVsIFRSSUxMIGJhc2VkIG9uIGRlZmF1bHQg bmlja25hbWUgYXBwcm9hY2guIEFkZGl0aW9uYWxseSB3ZSBkaXNjdXNzIGNvbnN0cnVjdGlvbiBv ZiBtdWx0aS1kZXN0aW5hdGlvbiB0cmVlcyBhbmQgcmVsYXRlZCBSUEYgaW4gbXVsdGlsZXZlbCBU UklMTC4gUGxlYXNlIGNvdWxkIHlvdSByZXZpZXcgYW5kIGNvbW1lbnQNCg0KRGV0YWlsIG9mIHRo ZSBkcmFmdCBhbmQgYWJzdHJhY3QgYXJlIGJlbG93Lg0KDQpGaWxlbmFtZTogICAgICAgICAgICAg ICAgICBkcmFmdC10aXNzYS10cmlsbC1tdWx0aWxldmVsDQpSZXZpc2lvbjogICAgICAgICAgICAg ICAgICAwMA0KVGl0bGU6ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBEZWZhdWx0 IE5pY2tuYW1lIEJhc2VkIEFwcHJvYWNoIGZvciBNdWx0aWxldmVsIFRSSUxMDQpDcmVhdGlvbiBk YXRlOiAgICAgICAgICAgICAgICAgIDIwMTItMDItMjENCldHIElEOiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6 IDI2DQoNCkFic3RyYWN0Og0KICBNdWx0aWxldmVsIFRSSUxMIGFsbG93cyB0aGUgaW50ZXJjb25u ZWN0aW9uIG9mIG11bHRpcGxlIFRSSUxMDQogIG5ldHdvcmtzIHRvIGZvcm0gYSBsYXJnZXIgVFJJ TEwgbmV0d29yayB3aXRob3V0IHByb3BvcnRpb25hbGx5DQogIGluY3JlYXNpbmcgdGhlIHNpemUg b2YgdGhlIElTLUlTIExTUCBEQi4gSW4gdGhpcyBkb2N1bWVudCwgYW4NCiAgYXBwcm9hY2ggYmFz ZWQgb24gZGVmYXVsdCByb3V0ZSBjb25jZXB0IGlzIHByZXNlbnRlZC4gQWxzbywNCiAgcHJlc2Vu dGVkIGluIHRoZSBkb2N1bWVudCBpcyBhIG5vdmVsIG1ldGhvZCBvZiBjb25zdHJ1Y3RpbmcgbXVs dGktDQogIGRlc3RpbmF0aW9uIHRyZWVzIHVzaW5nIHBhcnRpYWwgbmlja25hbWUgc3BhY2UuIE1l dGhvZHMgcHJlc2VudGVkIGluDQogIHRoaXMgZG9jdW1lbnQgYXJlIGNvbXBhdGlibGUgd2l0aCB0 aGUgUkZDNjMyNSBzcGVjaWZpZWQgZGF0YSBwbGFuZQ0KICBvcGVyYXRpb25zLg0KDQoNClRoYW5r cw0KVGlzc2ENCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCnJicmlkZ2UgbWFpbGluZyBsaXN0DQpyYnJpZGdlQHBvc3RlbC5vcmc8bWFpbHRvOnJicmlk Z2VAcG9zdGVsLm9yZz4NCmh0dHA6Ly9tYWlsbWFuLnBvc3RlbC5vcmcvbWFpbG1hbi9saXN0aW5m by9yYnJpZGdlDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpyYnJpZGdlIG1haWxpbmcgbGlzdA0KcmJyaWRnZUBwb3N0ZWwub3JnPG1haWx0bzpyYnJp ZGdlQHBvc3RlbC5vcmc+DQpodHRwOi8vbWFpbG1hbi5wb3N0ZWwub3JnL21haWxtYW4vbGlzdGlu Zm8vcmJyaWRnZQ0KDQoNCg0K --_000_C5BD54C085F1DB4D9B6B5BFF7ACE182B355A4302dfweml505mbx_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

See below at <dee3>= .

 <= /p>

From: rbridge-= bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Tissa Senevirathne (tsenevir)
Sent: Friday, February 24, 2012 1:00 PM
To: Radia Perlman
Cc: rbridge@postel.org; rbridge-bounces@postel.org; hu.fangwei@zte.c= om.cn
Subject: Re: [rbridge] Default nickname base approach for multilevel= TRILL- draft-tissa-trill-multilevel-00.txt

 

RBridges do not have to b= e in all topologies. Why would they should be?

 <= /p>

<dee3> I would agre= e that an RBridge does not have to be in all topologies although I think it= will be common for some RBridges to be in many topologies.

 <= /p>

<dee3> I view a nic= kname as an abbreviation of the 48-bit IS-IS System ID. The differences bei= ng that it is shorter, is auto allocated by default, and there can be more than one of them that map to the same System ID so that an RBr= idge can be the root of more than one distribution tree and so that there c= ould be an egress nickname that uses traffic engineered routing rather than= the default least cost routing. Intermediate Systems do not have different System  IDs in different t= opologies, as far as I know. I don=A1=AFt see how/why they would have diffe= rent nicknames in different topologies.

 

What is Fulcrum chip ?

 <= /p>

<dee3> The four mer= chant silicon manufacturers that I know of that have announced support for = TRILL are, in alphabetic order, Broadcom, Fulcrum, Marvel, and Mellanox. (Fulcrum has been acquired by Intel.)

 <= /p>

Thanks,=

Donald<= /p>

=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=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D

Donald E. Eastlake, 3rd&n= bsp;    Donald.Eastlake@huawei.com

155 Beaver Street &n= bsp;            += ;1-508-333-2270

 Milford, MA 01757 U= SA

 <= /p>

 <= /p>

From: Radia Pe= rlman [mailto:radiaperlman@gmail.com]
Sent: Friday, February 24, 2012 9:23 AM
To: Tissa Senevirathne (tsenevir)
Cc: hu.fangwei@zte.com.cn; rbridge@postel.org; rbridge-bounces@poste= l.org
Subject: Re: [rbridge] Default nickname base approach for multilevel= TRILL- draft-tissa-trill-multilevel-00.txt

 

I assume that all RBridges will need to be in all to= pologies, so multitopology will not help with nickname exhaustion.&nbs= p; Plus you haven't explained how a TRILL packet would be marked as to whic= h topology the packet should be routed according to (other than what I mentioned, which actually eats up nicknames by a fac= tor of the number of topologies supported).

 

Plus, rather than just lumping potential issues into= a phrase such as "NAT-like", be explicit about what issues there= actually are.  I believe the Fulcrum chip would have no problem with = translating the nickname fields.

 

And rather than assuming that nickname exhaustion ca= n be solved "some other way", there should be a palatable solutio= n before rejecting a chance to solve it with multilevel.

 

Radia

2012/2/24 Tissa Senevirathne (tsenevir) <tsenevir@cisco.com>

Because you can have same nickname for = different topology. It is not a nickname that will identify an RBRidge, it is topology,nickname combination that will identify an RBRi= dge. So RB1 can have nickname 1 in topo-1 and RB2 can have nickname 1 in to= po2. Now total nicknames in the campus is 2**16 x topologies.

 

Stealing bits to represent topo id is o= nly a workaround there can be (are ) more elegant ways of doing it that.

 

Bottom line is we need to look for more= creative methods of solving nickname space issue than doing NAT like behavior.

 

From: Radia Perlman [mailto:= radiaperlman@gm= ail.com]
Sent: Friday, February 24, 2012 9:05 AM
To: Tissa Senevirathne (tsenevir)
Cc: hu.fa= ngwei@zte.com.cn; rbridge@postel.org<= /a>; rbridge-bounces@postel.org


Subject: Re: [rbridge] Default nickname base approach for multilevel= TRILL- draft-tissa-trill-multilevel-00.txt

 

I don't understand how multi-topology helps with the nickname exha= ustion issue.  As a matter of fact, the only plausible way of marking = a packet for which topology that has been suggested on the mailing list (I asked a efw times if there were any other= possibilities), was to steal 2 or 3 bits of the nickname to encode which t= opology, in effect, making a destination appear as multiple destinations an= d multiple forwarding table entries (which you'd want anyway, for multitopology).

 

 

Radia

2012/2/24 Tissa Senevirathne (tsenevir) <tsenevir@cisco.com>

Mutli-topology is the answer to increas= e the nickname space.

 

Nickname translation is very similar to= NAT, which has it=A1=AFs own down side, not to mention special hardware etc. to do the translations, additionally. We also know from our = experience, in IP world NATing is not the most desired behavior and we live= with it. So we should not be going down that path instead need to look for= ward from that experience.

 

Multi-topology not only address nicknam= e space issue but also enables various other applications such as overlay topologies, traffic engineering.

 

The draft-tiss-trill-multilevel present= approaches that are generic, which mean it can be applied for multi-topology, or base topology. It utilizes the fundamentals of IS-I= S , such as Area hierarchy for reduction of the LSP-DB. It utilize affinity= TLV concepts to effectively solve multi-destination issues.

 

We should not mix-up between Data cente= r interconnects with data center node scaling. They are two different and orthogonal issues.

 

Objective of multi-level trill is to in= terconnect different datacenters, and maintain LSP-DB small as possible to avoid scaling and volatility.

 

Increasing nickname space a different r= equirement and has nothing to do with data-center interconnects.

 

 

From: Radia Perlman [mailto:= radiaperlman@gm= ail.com]
Sent: Friday, February 24, 2012 6:15 AM
To: hu.fa= ngwei@zte.com.cn
Cc: Tissa Senevirathne (tsenevir); rbridge@postel.org; rbridge-bounces@postel.org
Subject: Re: [rbridge] Default nickname base approach for multilevel= TRILL- draft-tissa-trill-multilevel-00.txt

 

People have mentioned to me that they are nervous about running ou= t of nicknames, especially since there are reasonson why they might want to= assign nicknames to hypervisors.  With the alternate approach of allowing nicknames to be reused in different are= as, it makes automatic nickname assignment much simpler and makes TRILL a l= ot more scalable.

 

It does have the downside of requiring mapping of nicknames at the= border RBridges.

 

And by the way, the affinity TLV can be used for multidestination = frames transiting between level 1 and level 2.

 

Radia

2012/2/23 <hu.fangwei@zte.com.cn>


Hi, Ti= ssa.

I have= several comments about the draft.

(1) in= section 4.4 (Multicast), "The scope of global traffic may be identifi= ed either through VLAN or via finegrain
label = that spans across the entire TRILL campus."
Vlan a= nd Fine-grain Label is used for service differentiation and isolation. I do= not quite understand that how to
use VL= AN and fine-grain Lable to identify the traffic scope. The data traffic wit= h a given VLAN-x, can
be for= warded to other end station in the local area, or to the end station in rem= ote areas.

(2) ni= ckname allocation
The ni= ckname management sub-TLV is proposed in the document. I wonder this mechan= ism adds the complication of  
nickna= me allocation. As the section 1 (introduction) of RFC6325, one of the impor= tant advantage of TRILL is that  
it avo= ids the creating subnets of IP address and wasting address. The nickname ac= quisition  method in this draft violates the  
idea o= f TRILL Basic specification, and reduces the flexibility of nickname alloca= tion. As the draft assumed, A1 had  
nickna= me range of 100-200, A2 has a local nickname range of 201-300. If the numbe= rs of A1 area is only 50, so 50  
nickna= mes in A1 is wasted. As the network growing, the number of some areas may e= xceed the number being allocation  
by Bor= der RBridges. The design and maintaining of nickname ranges for each area i= s a very hard work. Even worst, it  
can no= t avoid to waste nickname space.

(3) Dy= namic ranges
 = The nickname range is divided into two range: local range and dynamical ran= ge. I wonder the nickname conflict  
resolu= tion can not work if the RBridge get the nickname from the dynamical range = while the two RBridge belongs to  
differ= ent areas. For example, RB1 is in area A1, and RB2 is in area A2. If RB1 ge= ts the nickname N1 from dynamic  
range,= and it will floods in area A1, and other RBridges in area A1 can not get n= ickname N1 because of nickname  
confli= ction mechanism, but RB2 in area A2 can not receive the PDU from RB1, and i= t  can also get the nickname N1 from  
dynami= cal range. So the question is how to avoid the duplication dynamical range = nickname for different areas.

(4) Th= e risk of running out of nickname maybe a issue for TRILL. The number of 2*= *16 nickname is enough for the current data center,
 = but it maybe not enough in the future, especailly if TRILL over IP , TRILL = over MPLS technology or some other data center technologies
 = are deployed, the data center network can be a very lardge network. So i th= ink the very important and essential goal of multi-level draft is to save n= icknames.

Best r= egards
Fangwe= i Hu

"Tissa Senevirathne (tsenevir)" <tsenevir@cisco.com>=
=B7=A2=BC=FE=C8=CB:  rbridge-bounces@postel.org

2012-02-23 11:55

=CA=D5=BC=FE=C8=CB

<rbridge@postel.org>

=B3=AD=CB=CD

=D6=F7=CC=E2

[rbridge] Default nickname base approach for multilevel = TRILL-        draft-tissa-trill-multilevel-00.txt

 




Dear All

We have submitted draft-tissa-trill-multilevel, present multilevel TRIL= L based on default nickname approach. Additionally we discuss construction = of multi-destination trees and related RPF in multilevel TRILL. Please coul= d you review and comment

Detail of the draft and abstract are below.

Filename:                  = ;draft-tissa-trill-multilevel
Revision:                  = ;00
Title:                   &= nbsp;               Default Nickname Bas= ed Approach for Multilevel TRILL
Creation date:                 =  2012-02-21
WG ID:                   &= nbsp;               Individual Submissio= n
Number of pages: 26

Abstract:
  Multilevel TRILL allows the interconnection of multiple TRILL
  networks to form a larger TRILL network without proportionally
  increasing the size of the IS-IS LSP DB. In this document, an
  approach based on default route concept is presented. Also,=
  presented in the document is a novel method of constructing mult= i-
  destination trees using partial nickname space. Methods presente= d in
  this document are compatible with the RFC6325 specified data pla= ne
  operations.

                    &= nbsp;                    =                     &nbs= p;                  
Thanks
Tissa

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


_______________________________________________
rbridge mailing list
rbridge@postel.org<= /a>
http://mailman.postel.org/mailman/listinfo/rbridge

 

 

 

--_000_C5BD54C085F1DB4D9B6B5BFF7ACE182B355A4302dfweml505mbx_-- --===============1662230294== 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 --===============1662230294==-- From rbridge-bounces@postel.org Fri Feb 24 15:17: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 C60F321F8655 for ; Fri, 24 Feb 2012 15:17:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.985 X-Spam-Level: X-Spam-Status: No, score=-105.985 tagged_above=-999 required=5 tests=[AWL=0.614, 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 V1mer+IqWJc6 for ; Fri, 24 Feb 2012 15:17:29 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 44DD621F8677 for ; Fri, 24 Feb 2012 15:16:45 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1ON8ZkI016676; Fri, 24 Feb 2012 15:08:35 -0800 (PST) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1ON89aE016236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 24 Feb 2012 15:08:18 -0800 (PST) Received: from Erik-Nordmarks-MacBook-Pro-2.local (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 q1ON8650009082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Feb 2012 15:08:06 -0800 Message-ID: <4F481869.1030301@acm.org> Date: Fri, 24 Feb 2012 15:08:25 -0800 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "rbridge@postel.org" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: nordmark@acm.org Subject: [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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org 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 From rbridge-bounces@postel.org Fri Feb 24 15:24: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 6643E21F86F6 for ; Fri, 24 Feb 2012 15:24:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.927 X-Spam-Level: X-Spam-Status: No, score=-3.927 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 RY-9C0RULUbC for ; Fri, 24 Feb 2012 15:24:02 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6124D21F86E4 for ; Fri, 24 Feb 2012 15:24:02 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1OMwhi3015135; Fri, 24 Feb 2012 14:58:46 -0800 (PST) Received: from mail-tul01m020-f180.google.com (mail-tul01m020-f180.google.com [209.85.214.180]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1OMwIZx014785 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 24 Feb 2012 14:58:27 -0800 (PST) Received: by obqv19 with SMTP id v19so445362obq.39 for ; Fri, 24 Feb 2012 14:58:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=R409cfyJXj4lqxQq3/5prcM2SDdMIsvuOe0c5zBIhUc=; b=qiNp3Dy1l/xkSCcU1edwgeZ7EFf+8aZdQkm8nPdWZulYXrHkjv8/iqxXCObViQWr/M JGOeNz05tRveZ3bSR9dFRIR/lZOe4Ug5YPxV14Ewaz7nLhmUtSDybzSwD53Hu9luOyA8 2muQo80cB13AEnJ0j/CuB/4H3lwoDUsoXgxEc= MIME-Version: 1.0 Received: by 10.182.16.65 with SMTP id e1mr1437958obd.26.1330124298103; Fri, 24 Feb 2012 14:58:18 -0800 (PST) Received: by 10.182.165.1 with HTTP; Fri, 24 Feb 2012 14:58:18 -0800 (PST) In-Reply-To: References: <344037D7CFEFE84E97E9CC1F56C5F4A5A45E88@xmb-sjc-214.amer.cisco.com> <344037D7CFEFE84E97E9CC1F56C5F4A5A462E7@xmb-sjc-214.amer.cisco.com> Date: Fri, 24 Feb 2012 14:58:18 -0800 Message-ID: From: Vishwas Manral To: Radia Perlman X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: vishwas.ietf@gmail.com Cc: "Tissa Senevirathne \(tsenevir\)" , rbridge@postel.org, rbridge-bounces@postel.org, hu.fangwei@zte.com.cn Subject: Re: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.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: multipart/mixed; boundary="===============0137846408==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org --===============0137846408== Content-Type: multipart/alternative; boundary=bcaec55551124ba9f404b9bdb25a --bcaec55551124ba9f404b9bdb25a Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi Radia, I would agree with Tissa here. Any translation is bad for running any end-to-end applications. Examples would be OAM/ security etc. With this we will restrict applications that carry a nickname we would require ALG's on translation. With that said I find that for IP generally IS-IS is deployed as a single level. Tissa, Fulcrum is an ASIC company bought by Intel recently. They specialize in Low Latency DC equipment. Thanks, Vishwas 2012/2/24 Radia Perlman > I don't understand how multi-topology helps with the nickname exhaustion > issue. As a matter of fact, the only plausible way of marking a packet f= or > which topology that has been suggested on the mailing list (I asked a efw > times if there were any other possibilities), was to steal 2 or 3 bits of > the nickname to encode which topology, in effect, making a destination > appear as multiple destinations and multiple forwarding table entries > (which you'd want anyway, for multitopology). > > > Radia > > 2012/2/24 Tissa Senevirathne (tsenevir) > > Mutli-topology is the answer to increase the nickname space.**** >> >> ** ** >> >> Nickname translation is very similar to NAT, which has it=A1=AFs own dow= n >> side, not to mention special hardware etc. to do the translations, >> additionally. We also know from our experience, in IP world NATing is no= t >> the most desired behavior and we live with it. So we should not be going >> down that path instead need to look forward from that experience.**** >> >> ** ** >> >> Multi-topology not only address nickname space issue but also enables >> various other applications such as overlay topologies, traffic engineeri= ng. >> **** >> >> ** ** >> >> The draft-tiss-trill-multilevel present approaches that are generic, >> which mean it can be applied for multi-topology, or base topology. It >> utilizes the fundamentals of IS-IS , such as Area hierarchy for reductio= n >> of the LSP-DB. It utilize affinity TLV concepts to effectively solve >> multi-destination issues. **** >> >> ** ** >> >> We should not mix-up between Data center interconnects with data center >> node scaling. They are two different and orthogonal issues.**** >> >> ** ** >> >> Objective of multi-level trill is to interconnect different datacenters, >> and maintain LSP-DB small as possible to avoid scaling and volatility.**= * >> * >> >> ** ** >> >> Increasing nickname space a different requirement and has nothing to do >> with data-center interconnects.**** >> >> ** ** >> >> ** ** >> >> *From:* Radia Perlman [mailto:radiaperlman@gmail.com] >> *Sent:* Friday, February 24, 2012 6:15 AM >> *To:* hu.fangwei@zte.com.cn >> *Cc:* Tissa Senevirathne (tsenevir); rbridge@postel.org; >> rbridge-bounces@postel.org >> *Subject:* Re: [rbridge] Default nickname base approach for multilevel >> TRILL- draft-tissa-trill-multilevel-00.txt**** >> >> ** ** >> >> People have mentioned to me that they are nervous about running out of >> nicknames, especially since there are reasonson why they might want to >> assign nicknames to hypervisors. With the alternate approach of allowin= g >> nicknames to be reused in different areas, it makes automatic nickname >> assignment much simpler and makes TRILL a lot more scalable.**** >> >> **** >> >> It does have the downside of requiring mapping of nicknames at the borde= r >> RBridges.**** >> >> **** >> >> And by the way, the affinity TLV can be used for multidestination frames >> transiting between level 1 and level 2.**** >> >> **** >> >> Radia**** >> >> 2012/2/23 **** >> >> >> Hi, Tissa. >> >> I have several comments about the draft. >> >> (1) in section 4.4 (Multicast), "The scope of global traffic may be >> identified either through VLAN or via finegrain >> label that spans across the entire TRILL campus." >> Vlan and Fine-grain Label is used for service differentiation and >> isolation. I do not quite understand that how to >> use VLAN and fine-grain Lable to identify the traffic scope. The data >> traffic with a given VLAN-x, can >> be forwarded to other end station in the local area, or to the end >> station in remote areas. >> >> (2) nickname allocation >> The nickname management sub-TLV is proposed in the document. I wonder >> this mechanism adds the complication of >> nickname allocation. As the section 1 (introduction) of RFC6325, one of >> the important advantage of TRILL is that >> it avoids the creating subnets of IP address and wasting address. The >> nickname acquisition method in this draft violates the >> idea of TRILL Basic specification, and reduces the flexibility of >> nickname allocation. As the draft assumed, A1 had >> nickname range of 100-200, A2 has a local nickname range of 201-300. If >> the numbers of A1 area is only 50, so 50 >> nicknames in A1 is wasted. As the network growing, the number of some >> areas may exceed the number being allocation >> by Border RBridges. The design and maintaining of nickname ranges for >> each area is a very hard work. Even worst, it >> can not avoid to waste nickname space. >> >> (3) Dynamic ranges >> The nickname range is divided into two range: local range and dynamical >> range. I wonder the nickname conflict >> resolution can not work if the RBridge get the nickname from the >> dynamical range while the two RBridge belongs to >> different areas. For example, RB1 is in area A1, and RB2 is in area A2. >> If RB1 gets the nickname N1 from dynamic >> range, and it will floods in area A1, and other RBridges in area A1 can >> not get nickname N1 because of nickname >> confliction mechanism, but RB2 in area A2 can not receive the PDU from >> RB1, and it can also get the nickname N1 from >> dynamical range. So the question is how to avoid the duplication >> dynamical range nickname for different areas. >> >> (4) The risk of running out of nickname maybe a issue for TRILL. The >> number of 2**16 nickname is enough for the current data center, >> but it maybe not enough in the future, especailly if TRILL over IP , >> TRILL over MPLS technology or some other data center technologies >> are deployed, the data center network can be a very lardge network. So = i >> think the very important and essential goal of multi-level draft is to s= ave >> nicknames. >> >> Best regards >> Fangwei Hu >> >> >> **** >> >> *"Tissa Senevirathne (tsenevir)" * >> =B7=A2=BC=FE=C8=CB: rbridge-bounces@postel.org **** >> >> 2012-02-23 11:55 **** >> >> =CA=D5=BC=FE=C8=CB**** >> >> **** >> >> =B3=AD=CB=CD**** >> >> =D6=F7=CC=E2**** >> >> [rbridge] Default nickname base approach for multilevel TRILL- >> draft-tissa-trill-multilevel-00.txt**** >> >> ** ** >> >> >> >> >> Dear All >> >> We have submitted draft-tissa-trill-multilevel, present multilevel TRILL >> based on default nickname approach. Additionally we discuss construction= of >> multi-destination trees and related RPF in multilevel TRILL. Please coul= d >> you review and comment >> >> Detail of the draft and abstract are below. >> >> Filename: draft-tissa-trill-multilevel >> Revision: 00 >> Title: Default Nickname Based Approach >> for Multilevel TRILL >> Creation date: 2012-02-21 >> WG ID: Individual Submission >> Number of pages: 26 >> >> Abstract: >> Multilevel TRILL allows the interconnection of multiple TRILL >> networks to form a larger TRILL network without proportionally >> increasing the size of the IS-IS LSP DB. In this document, an >> approach based on default route concept is presented. Also, >> presented in the document is a novel method of constructing multi- >> destination trees using partial nickname space. Methods presented in >> this document are compatible with the RFC6325 specified data plane >> operations. >> >> >> >> Thanks >> Tissa >> >> _______________________________________________ >> 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 > > --bcaec55551124ba9f404b9bdb25a Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi Radia,

I would agree with Tissa here.

Any translation is = bad for running any end-to-end applications. Examples would be OAM/ securit= y etc. With this we will restrict applications that carry a nickname we wou= ld require ALG's on translation.

With that said I find that for IP generally IS-IS is deployed as a sing= le level.

Tissa, Fulcrum is an ASIC company bought by Intel recently= . They specialize in Low Latency DC equipment.

Thanks,
Vishwas
2012/2/24 Radia Perlman &l= t;radiaperlman@gmail.com><= /span>
I don't understand how multi-topology helps with the nickname exha= ustion issue.  As a matter of fact, the only plausible way of marking = a packet for which topology that has been suggested on the mailing list (I = asked a efw times if there were any other possibilities), was to steal 2 or= 3 bits of the nickname to encode which topology, in effect, making a desti= nation appear as multiple destinations and multiple forwarding table entrie= s (which you'd want anyway, for multitopology).
 
 
Radia

2012/2/24 Tissa Senevirathne (tsenevir) <tsene= vir@cisco.com>

Mutli-topology is the answer to= increase the nickname space.

 

Nickname translation is very si= milar to NAT, which has it’s own down side, not to mention special ha= rdware etc. to do the translations, additionally. We also know from our exp= erience, in IP world NATing is not the most desired behavior and we live wi= th it. So we should not be going down that path instead need to look forwar= d from that experience.

 

Multi-topology not only address= nickname space issue but also enables various other applications such as o= verlay topologies, traffic engineering.

 

The draft-tiss-trill-multilevel= present approaches that are generic, which mean it can be applied for mult= i-topology, or base topology. It utilizes the fundamentals of IS-IS , such = as Area hierarchy for reduction of the LSP-DB. It utilize affinity TLV conc= epts to effectively solve multi-destination issues.

 

We should not mix-up between Da= ta center interconnects with data center node scaling. They are two differe= nt and orthogonal issues.

 

Objective of multi-level trill = is to interconnect different datacenters, and maintain LSP-DB small as poss= ible to avoid scaling and volatility.

 

Increasing nickname space a dif= ferent requirement and has nothing to do with data-center interconnects.=

 

 

From: Radia Perlman [mailt= o:radiaperlman@= gmail.com]
Sent: Friday, February 24, 2012 6:15 AM
To: hu.fangwei@zte.com.cn
<= b>Cc: Tissa Senevirathne (tsenevir); rbridge@postel.org; rbridge-bounces@postel.org
Subject: Re: [rbridge] Default nickname base approach for multilevel= TRILL- draft-tissa-trill-multilevel-00.txt

 

People have mentioned to me that they are nervous ab= out running out of nicknames, especially since there are reasonson why they= might want to assign nicknames to hypervisors.  With the alternate ap= proach of allowing nicknames to be reused in different areas, it makes auto= matic nickname assignment much simpler and makes TRILL a lot more scalable.=

 

It does have the downside of requiring mapping of ni= cknames at the border RBridges.

 

And by the way, the affinity TLV can be used for mul= tidestination frames transiting between level 1 and level 2.<= /p>

 

Radia

=

2012/2/23 <hu.fangwei@zte.com.cn>


Hi, Tissa.

I have severa= l comments about the draft.

(1) in= section 4.4 (Multicast), "The scope of global traffic may be identifi= ed either through VLAN or via finegrain
label that spans across the entire= TRILL campus."
Vlan and F= ine-grain Label is used for service differentiation and isolation. I do not= quite understand that how to
use VLAN and fine-grain Lable to identify th= e traffic scope. The data traffic with a given VLAN-x, can
be forward= ed to other end station in the local area, or to the end station in remote = areas.

(2) nickname allocation
The nickna= me management sub-TLV is proposed in the document. I wonder this mechanism = adds the complication of  
nickname allocation. As the section 1 (int= roduction) of RFC6325, one of the important advantage of TRILL is that &nbs= p;
it avoids = the creating subnets of IP address and wasting address. The nickname acquis= ition  method in this draft violates the  
idea of TRILL Basic s= pecification, and reduces the flexibility of nickname allocation. As the dr= aft assumed, A1 had  
nickname r= ange of 100-200, A2 has a local nickname range of 201-300. If the numbers o= f A1 area is only 50, so 50  
nicknames in A1 is wasted. As the netwo= rk growing, the number of some areas may exceed the number being allocation=  
by Border = RBridges. The design and maintaining of nickname ranges for each area is a = very hard work. Even worst, it  
can not avoid to waste nickname spac= e.

(3) Dy= namic ranges
 The nickname range is divided into two range: local ran= ge and dynamical range. I wonder the nickname conflict  
resolution= can not work if the RBridge get the nickname from the dynamical range whil= e the two RBridge belongs to  
different areas. For example, RB1 is i= n area A1, and RB2 is in area A2. If RB1 gets the nickname N1 from dynamic =  
range, and= it will floods in area A1, and other RBridges in area A1 can not get nickn= ame N1 because of nickname  
confliction mechanism, but RB2 in area A= 2 can not receive the PDU from RB1, and it  can also get the nickname = N1 from  
dynamical = range. So the question is how to avoid the duplication dynamical range nick= name for different areas.

(4) The risk of running out of nickname mayb= e a issue for TRILL. The number of 2**16 nickname is enough for the current= data center,
 but = it maybe not enough in the future, especailly if TRILL over IP , TRILL over= MPLS technology or some other data center technologies
 are deployed= , the data center network can be a very lardge network. So i think the very= important and essential goal of multi-level draft is to save nicknames.

Best r= egards
Fangwei Hu


"Tissa Senevirathne (tsenevir)" &= lt;tsenevir@cisco.c= om>
=B7=A2=BC=FE=C8=CB:  = rbridge-bounces@postel.org

2012-02-23 11:55

=CA=D5=BC=FE=C8=CB

<rbridge@postel.org>

=B3=AD=CB=CD

=

=D6=F7=CC=E2

=

[rbridge] Default nickname base approach for m= ultilevel TRILL-        draft-tissa-trill-multilevel-00= .txt

 




Dear Al= l

We have submitted draft-tissa-trill-multilevel, present m= ultilevel TRILL based on default nickname approach. Additionally we discuss= construction of multi-destination trees and related RPF in multilevel TRIL= L. Please could you review and comment

Detail of the draft and abstract are below.

Filenam= e:                  draft-tiss= a-trill-multilevel
Revision:          =        00
Title:       &nbs= p;                     &n= bsp;     Default Nickname Based Approach for Multilevel TRILL
Creation date:                 =  2012-02-21
WG ID:           &nbs= p;                     &n= bsp; Individual Submission
Number of pages: 26

= Abstract:
  Multilevel TRILL allows the interconnection of= multiple TRILL
  networks to form a larger TRILL network without proportionally
  increasing the size of the IS-IS LSP DB. In this document= , an
  approach based on default route concept is presente= d. Also,
  presented in the document is a novel method of constructing mult= i-
  destination trees using partial nickname space. Metho= ds presented in
  this document are compatible with the RF= C6325 specified data plane
  operations.

          &= nbsp;                    =                     &nbs= p;                     &n= bsp;      
Thanks
Tissa

= _______________________________________________
rbridge mailing list
rbridge@postel.org
http://mailman.p= ostel.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


--bcaec55551124ba9f404b9bdb25a-- --===============0137846408== 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 --===============0137846408==-- From rbridge-bounces@postel.org Fri Feb 24 15:41: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 7BE3021F8720 for ; Fri, 24 Feb 2012 15:41:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.062 X-Spam-Level: X-Spam-Status: No, score=-106.062 tagged_above=-999 required=5 tests=[AWL=0.538, 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 2Df31LSGTSQv for ; Fri, 24 Feb 2012 15:41:06 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id A41EC21F871E for ; Fri, 24 Feb 2012 15:41:06 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1ONFZSs017581; Fri, 24 Feb 2012 15:15:36 -0800 (PST) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1ONFM7x017540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 24 Feb 2012 15:15:30 -0800 (PST) Received: from Erik-Nordmarks-MacBook-Pro-2.local (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 q1ONFJaE018705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Feb 2012 15:15:20 -0800 Message-ID: <4F481A19.3060808@acm.org> Date: Fri, 24 Feb 2012 15:15:37 -0800 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "rbridge@postel.org" References: <4F299636.7060604@acm.org> In-Reply-To: <4F299636.7060604@acm.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: nordmark@acm.org Subject: [rbridge] Conclusion of WG last call on draft-ietf-trill-rbridge-bfd-02 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 The WG last call on the bfd draft shows overall support for advancing this document to the IESG. Some editorial suggestions have been made, and it makes sense to apply those and produce an updated draft before we forward the document to the IESG. Thanks for the reviews, Erik and Donald _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge From rbridge-bounces@postel.org Fri Feb 24 15:46: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 8D54821E8012 for ; Fri, 24 Feb 2012 15:46:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.121 X-Spam-Level: X-Spam-Status: No, score=-106.121 tagged_above=-999 required=5 tests=[AWL=0.478, 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 71hChtTmKTPY for ; Fri, 24 Feb 2012 15:46:02 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 81A8D21E800E for ; Fri, 24 Feb 2012 15:46:02 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1ON74cj016153; Fri, 24 Feb 2012 15:07:05 -0800 (PST) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1ON6gcI016139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 24 Feb 2012 15:06:51 -0800 (PST) Received: from Erik-Nordmarks-MacBook-Pro-2.local (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 q1ON6bAf021420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Feb 2012 15:06:39 -0800 Message-ID: <4F481810.6080200@acm.org> Date: Fri, 24 Feb 2012 15:06:56 -0800 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Donald Eastlake References: <4F299636.7060604@acm.org> In-Reply-To: X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: nordmark@acm.org Cc: "rbridge@postel.org" Subject: Re: [rbridge] WG last call on draft-ietf-trill-rbridge-bfd-02 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 2/14/12 8:42 PM, Donald Eastlake wrote: > I would like to suggest the addition of some material to the Security > Considerations section. Something like what I've pasted below my .sig > and above Erik's message blow... A few editorial nits and an editorial question below. > Consist with TRILL's goal of minimum configuration, the default for s/Consist/Consistent/ > BFD security between neighbor RBridges is based on that state of > IS-IS shared secret authentication for Hello between those > RBridges. If such IS-IS authentication is not in effect then, by > default, TRILL BFD between those RBridges is also unsecured. But > the RBridges may be configured to use BFD Security. > > If such IS-IS authentication is in effect then, unless configured > otherwise, TRILL BFD Control frames sent between those RBridges use > BFD Meticulous Keyed SHA1 authentication [RF5880] with keying > material derived as shown below > > HMAC-SHA256 ( ( "TRILL BFD Control" | originatorMAC | > originatorPortID ), IS-IS-shared-key ) > > where HMAC-SHA256 [RFC6234], "TRILL BFD Control" is the seventeen > byte US ASCII [RFC20] string indicated that is then concatenated > with the 6-byte MAC of the originating port and then the 2-byte > Port ID as would be sent in a TRILL Hello on that port. Do we need to specify the byte order for the originatorMAC and originatorPortID to make sure that the sender and receiver use the same byte order when deriving the key? > These > quantities are included to minimize expose of the same key to Should it be "exposure" instead of "expose"? > improve resistance to cryptanalysis. IS-IS-key is the secret keying s/IS-IS-key/IS-IS-shared-key/ > material being used for IS-IS authentication on the link. In the > Authentication Section of the BFD Control frame OAM protocol > specific data, Auth Type would be 5, Auth Len would be 28, and Auth > Key ID is zero. The RBridges MAY be configured to use other BFD > security modes or keying material including configuration to use no > security. > > Authentication for TRILL BFD Echo SHOULD be provided but is a local > implementation issue as BFD Echo frames are authenticated by their > sender when received in the form of Echo responses. However, if > TRILL IS-IS and BFD Control are being authenticated to a neighbor > and BFD Echo is in use, BFD Echo frames to be returned by that > neighbor SHOULD be authenticated and such authenticate SHOULD use > different keying material from other types of authentication. For > example, it could use keying material derived as follows: > > HMAC-SHA256 ( ( "TRILL BFD Echo" | originatorMAC | > originatorPortID ), IS-IS-shared-key ) > Erik _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge From rbridge-bounces@postel.org Fri Feb 24 15:51: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 C099921F8659 for ; Fri, 24 Feb 2012 15:51:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.165 X-Spam-Level: X-Spam-Status: No, score=-5.165 tagged_above=-999 required=5 tests=[AWL=1.433, 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 jpEdZ8gU2rnv for ; Fri, 24 Feb 2012 15:51:04 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 353C421F84B5 for ; Fri, 24 Feb 2012 15:51:01 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1ONJ9qa018254; Fri, 24 Feb 2012 15:19:11 -0800 (PST) Received: from mail-tul01m020-f180.google.com (mail-tul01m020-f180.google.com [209.85.214.180]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1ONIYog018192 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 24 Feb 2012 15:18:43 -0800 (PST) Received: by obqv19 with SMTP id v19so475977obq.39 for ; Fri, 24 Feb 2012 15:18:34 -0800 (PST) Received-SPF: pass (google.com: domain of vishwas.ietf@gmail.com designates 10.60.1.2 as permitted sender) client-ip=10.60.1.2; Authentication-Results: mr.google.com; spf=pass (google.com: domain of vishwas.ietf@gmail.com designates 10.60.1.2 as permitted sender) smtp.mail=vishwas.ietf@gmail.com; dkim=pass header.i=vishwas.ietf@gmail.com Received: from mr.google.com ([10.60.1.2]) by 10.60.1.2 with SMTP id 2mr1953054oei.16.1330125514615 (num_hops = 1); Fri, 24 Feb 2012 15:18:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xplJHSbMoHsINFLnkwUR8v5L83Crg8QruT/d6Vv8SB0=; b=NAu34AfUKaaFKURcbV//F8xK4iUhdnr6Kej/69tkIbrwO3weBBOn19DRbVmnw9ApHd s4LYT5h7NcO0lhSu6jzD3fT274OBPxliLRbPJUMQr+KJDFd+rRb0S3+GFqyqoxpmE8on Q9E02xgadlnH4hUvE0nItjvuhAh9kdQFnGCJk= MIME-Version: 1.0 Received: by 10.60.1.2 with SMTP id 2mr1651701oei.16.1330125514460; Fri, 24 Feb 2012 15:18:34 -0800 (PST) Received: by 10.182.165.1 with HTTP; Fri, 24 Feb 2012 15:18:34 -0800 (PST) In-Reply-To: References: <4F299636.7060604@acm.org> <201202240121.q1O1LJ5L004767@cichlid.raleigh.ibm.com> Date: Fri, 24 Feb 2012 15:18:34 -0800 Message-ID: From: Vishwas Manral To: Donald Eastlake X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: vishwas.ietf@gmail.com Cc: Thomas Narten , "rbridge@postel.org" , Erik Nordmark Subject: Re: [rbridge] WG last call on draft-ietf-trill-rbridge-bfd-02 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="===============0886051811==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org --===============0886051811== Content-Type: multipart/alternative; boundary=e89a8fb1fe28cbcda404b9bdfadd --e89a8fb1fe28cbcda404b9bdfadd Content-Type: text/plain; charset=ISO-8859-1 Yes, I will edit the draft over the weekend. -Vishwas On Fri, Feb 24, 2012 at 9:02 AM, Donald Eastlake wrote: > Hi Thomas, > > Thanks for your corrections below. Some of these were previously > posted to the list or communicated to Vishwas Manral who is the > current editor of the document. Vishwas has been asked to spin a new > version. > > On the "sentence fragments" you mention, I believe that is supposed to > be a bulleted list and should be indented with bullets. > > On the last comment in your message, concerning the use of "required", > that word was copied from RFC 5881 but I think your suggested change > is fine. > > Thanks again, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > > > > On Thu, Feb 23, 2012 at 8:21 PM, Thomas Narten wrote: > > Overall, I support this document. It does need a respin to clean up > > what appear to be straightforward editing issues. > > > > Thomas > > > > Document probably should have a reference to core BFD RFCs earlier in > > the document than it does (e.g., first use). > > > > there is work in the area. The Rbridge Channel facility is specified > > in [TRILLoam]. > > > > s/TRILLoam/CHANNELoam/ > > > > it and TRILL data plaen layer OAM, such as TRILL BFD, is beyond the > > > > s/plaen/plane/ > > > > TRILL BFD Control frames are unicast TRILL Rbridge Message Channel > > frames [TRILLChannel]. The Rbridge Channel Protocol value is given > > in Section 10. > > > > There is no such term as "TRILL Rbridge Message Channel frames". I > > think you want to just say "Trill Rbridge Channel frames" (i.e., drop > > "Message"). Multiple occurances throughout document. > > > > A TRILL BFD Echo frame is a unicast TRILL OAM Message Channel > > frame, > > > > Drop "OAM"? Indeed, the entire document needs a pass to remove > > references to "OAM" that are no longer valid. BFD is now just part of > > the channel draft. > > > > A TRILL BFD Echo frame is a unicast TRILL OAM Message Channel frame, > > as specified in [TRILLoam], which should be forwarded back by an > > > > Drop "OAM" from above. Also, drop "Message", as that isn't the proper > > term (I think). > > > > Better: > > > > A TRILL BFD Echo frame is a unicast TRILL Channel frame as > > specified in [TRILLoam] with a Channel Protocol value of "BFD > > Echo". Such packets should be forwarded back ... > > > > Need a reference in references section to TRILLoam document > > > > TRILL BFD Echo frames SHOULD only be sent on a link if > > > > A TRILL BFD Control session has been established, > > > > Format problem above. Truncated sentence? > > > > TRILL BFD Echo support is indicated by the potentially echo > > responding RBridge. > > > > This sentence reads awkward. > > > > The adjacency is in the Report state [RFC6327], and > > > > Truncated sentence again? > > > > It is required that the operator of an RBridge campus configure the > > rates at which TRILL BFD frames are transmitted on a link to avoid > > congestion (e.g., link, I/O, CPU) and false failure detection. > > > > Don't like the "required" wording. Better to say something like "it > > is up to the operator to ..." > > > > IANA is request to allocate two TRILL OAM Protocol numbers from the > > range allocated by Standards Actions, as follows: > > > > Change wording of "OAM Protocol numbers"? > > > > _______________________________________________ > > 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 > --e89a8fb1fe28cbcda404b9bdfadd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes, I will edit the draft over the weekend.

-Vishwas

On Fri, Feb 24, 2012 at 9:02 AM, Donald Eastlake <d3e3e3@gmail.com>= ; wrote:
Hi Thomas,

Thanks for your corrections below. Some of these were previously
posted to the list or communicated to Vishwas Manral who is the
current editor of the document. Vishwas has been asked to spin a new
version.

On the "sentence fragments" you mention, I believe that is suppos= ed to
be a bulleted list and should be indented with bullets.

On the last comment in your message, concerning the use of "required&q= uot;,
that word was copied from RFC 5881 but I think your suggested change
is fine.

Thanks again,
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 Thu, Feb 23, 2012 at 8:21 = PM, Thomas Narten <narten@us.ibm.co= m> wrote:
> Overall, I support this document. It does need a respin to clean up > what appear to be straightforward editing issues.
>
> Thomas
>
> Document probably should have a reference to core BFD RFCs earlier in<= br> > the document than it does (e.g., first use).
>
> =A0 there is work in the area. =A0The Rbridge Channel facility is spec= ified
> =A0 in [TRILLoam].
>
> s/TRILLoam/CHANNELoam/
>
> =A0 it and TRILL data plaen layer OAM, such as TRILL BFD, is beyond th= e
>
> s/plaen/plane/
>
> =A0 TRILL BFD Control frames are unicast TRILL Rbridge Message Channel=
> =A0 frames [TRILLChannel]. =A0The Rbridge Channel Protocol value is gi= ven
> =A0 in Section 10.
>
> There is no such term as "TRILL Rbridge Message Channel frames&qu= ot;. I
> think you want to just say "Trill Rbridge Channel frames" (i= .e., drop
> "Message"). Multiple occurances throughout document.
>
> =A0 A TRILL BFD Echo frame is a unicast TRILL OAM Message Channel
> =A0 frame,
>
> Drop "OAM"? Indeed, the entire document needs a pass to remo= ve
> references to "OAM" that are no longer valid. BFD is now jus= t part of
> the channel draft.
>
> =A0 A TRILL BFD Echo frame is a unicast TRILL OAM Message Channel fram= e,
> =A0 as specified in [TRILLoam], which should be forwarded back by an >
> Drop "OAM" from above. Also, drop "Message", as th= at isn't the proper
> term (I think).
>
> Better:
>
> =A0 A TRILL BFD Echo frame is a unicast TRILL Channel frame as
> =A0 specified in [TRILLoam] with a Channel Protocol value of "BFD=
> =A0 Echo". Such packets should be forwarded back ...
>
> Need a reference in references section to TRILLoam document
>
> =A0 TRILL BFD Echo frames SHOULD only be sent on a link if
>
> =A0 A TRILL BFD Control session has been established,
>
> Format problem above. Truncated sentence?
>
> =A0 TRILL BFD Echo support is indicated by the potentially echo
> =A0 responding RBridge.
>
> This sentence reads awkward.
>
> =A0 The adjacency is in the Report state [RFC6327], and
>
> Truncated sentence again?
>
> =A0 It is required that the operator of an RBridge campus configure th= e
> =A0 rates at which TRILL BFD frames are transmitted on a link to avoid=
> =A0 congestion (e.g., link, I/O, CPU) and false failure detection.
>
> Don't like the "required" wording. =A0 Better to say som= ething like "it
> is up to the operator to ..."
>
> =A0 IANA is request to allocate two TRILL OAM Protocol numbers from th= e
> =A0 range allocated by Standards Actions, as follows:
>
> Change wording of "OAM Protocol numbers"?
>
> _______________________________________________
> 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

--e89a8fb1fe28cbcda404b9bdfadd-- --===============0886051811== 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 --===============0886051811==-- From rbridge-bounces@postel.org Fri Feb 24 18:17: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 93CDC21F85C9 for ; Fri, 24 Feb 2012 18:17:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.8 X-Spam-Level: X-Spam-Status: No, score=-105.8 tagged_above=-999 required=5 tests=[AWL=0.799, 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 UqdLkYU0Ymjn for ; Fri, 24 Feb 2012 18:17:21 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id DA22621F85C0 for ; Fri, 24 Feb 2012 18:17:21 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1P2Efbg014813; Fri, 24 Feb 2012 18:14:42 -0800 (PST) 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 q1P2EM54014803 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 24 Feb 2012 18:14:32 -0800 (PST) Received: by lagy4 with SMTP id y4so5971159lag.39 for ; Fri, 24 Feb 2012 18:14:21 -0800 (PST) Received-SPF: pass (google.com: domain of d3e3e3@gmail.com designates 10.112.29.38 as permitted sender) client-ip=10.112.29.38; Authentication-Results: mr.google.com; spf=pass (google.com: domain of d3e3e3@gmail.com designates 10.112.29.38 as permitted sender) smtp.mail=d3e3e3@gmail.com; dkim=pass header.i=d3e3e3@gmail.com Received: from mr.google.com ([10.112.29.38]) by 10.112.29.38 with SMTP id g6mr107853lbh.102.1330136061395 (num_hops = 1); Fri, 24 Feb 2012 18:14:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=ccARcM9C2y5AjLEAElAR2zKECquX59Jb1/rV51wPMts=; b=JpUctRMpXkMNWRbjZvbKR+fP1bnd/8ATZL+oYyHPCrSp/YRPsNR5zp2DbMu2Vxwn82 W3OEO/LXX+SZ4RJgmst157jxiI90yBi/7UUgAOMcaZkCyLEWyTjGdrV7OEiLvyw23F/F /owpYtjWgEHVm/rgYwDCKPNx1YWbD8iUX/r20= Received: by 10.112.29.38 with SMTP id g6mr92618lbh.102.1330136061274; Fri, 24 Feb 2012 18:14:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.80.234 with HTTP; Fri, 24 Feb 2012 18:14:01 -0800 (PST) In-Reply-To: <4F481810.6080200@acm.org> References: <4F299636.7060604@acm.org> <4F481810.6080200@acm.org> From: Donald Eastlake Date: Fri, 24 Feb 2012 21:14:01 -0500 Message-ID: To: Erik Nordmark 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 q1P2EM54014803 Cc: "rbridge@postel.org" Subject: Re: [rbridge] WG last call on draft-ietf-trill-rbridge-bfd-02 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 Erik, A later improved version is here http://www.postel.org/pipermail/rbridge/2012-February/004768.html It should probably specify "network byte order". 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 Fri, Feb 24, 2012 at 6:06 PM, Erik Nordmark wrote: > On 2/14/12 8:42 PM, Donald Eastlake wrote: >> >> I would like to suggest the addition of some material to the Security >> Considerations section. Something like what I've pasted below my .sig >> and above Erik's message blow... > > > A few editorial nits and an editorial question below. > > >> =A0 =A0Consist with TRILL's goal of minimum configuration, the default f= or > > > s/Consist/Consistent/ > > >> =A0 =A0BFD security between neighbor RBridges is based on that state of >> =A0 =A0IS-IS shared secret authentication for Hello between those >> =A0 =A0RBridges. =A0If such IS-IS authentication is not in effect then, = by >> =A0 =A0default, TRILL BFD between those RBridges is also unsecured. But >> =A0 =A0the RBridges may be configured to use BFD Security. >> >> =A0 =A0If such IS-IS authentication is in effect then, unless configured >> =A0 =A0otherwise, TRILL BFD Control frames sent between those RBridges u= se >> =A0 =A0BFD Meticulous Keyed SHA1 authentication [RF5880] with keying >> =A0 =A0material derived as shown below >> >> =A0 =A0 =A0 =A0HMAC-SHA256 ( ( "TRILL BFD Control" | originatorMAC | >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 originatorPortID ), IS-I= S-shared-key ) >> >> =A0 =A0where HMAC-SHA256 [RFC6234], "TRILL BFD Control" is the seventeen >> =A0 =A0byte US ASCII [RFC20] string indicated that is then concatenated >> =A0 =A0with the 6-byte MAC of the originating port and then the 2-byte >> =A0 =A0Port ID as would be sent in a TRILL Hello on that port. > > > Do we need to specify the byte order for the originatorMAC and > originatorPortID to make sure that the sender and receiver use the same b= yte > order when deriving the key? > > >> These >> =A0 =A0quantities are included to minimize expose of the same key to > > > Should it be "exposure" instead of "expose"? > > >> =A0 =A0improve resistance to cryptanalysis. IS-IS-key is the secret keyi= ng > > > s/IS-IS-key/IS-IS-shared-key/ > > >> =A0 =A0material being used for IS-IS authentication on the link. In the >> =A0 =A0Authentication Section of the BFD Control frame OAM protocol >> =A0 =A0specific data, Auth Type would be 5, Auth Len would be 28, and Au= th >> =A0 =A0Key ID is zero. The RBridges MAY be configured to use other BFD >> =A0 =A0security modes or keying material including configuration to use = no >> =A0 =A0security. >> >> =A0 =A0Authentication for TRILL BFD Echo SHOULD be provided but is a loc= al >> =A0 =A0implementation issue as BFD Echo frames are authenticated by their >> =A0 =A0sender when received in the form of Echo responses. However, if >> =A0 =A0TRILL IS-IS and BFD Control are being authenticated to a neighbor >> =A0 =A0and BFD Echo is in use, BFD Echo frames to be returned by that >> =A0 =A0neighbor SHOULD be authenticated and such authenticate SHOULD use >> =A0 =A0different keying material from other types of authentication. =A0= For >> =A0 =A0example, it could use keying material derived as follows: >> >> =A0 =A0 =A0 HMAC-SHA256 ( ( "TRILL BFD Echo" | originatorMAC | >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 originatorPortID ), IS-IS-sh= ared-key ) >> > > =A0 Erik _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge From rbridge-bounces@postel.org Fri Feb 24 19:27: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 EAC8421E8015 for ; Fri, 24 Feb 2012 19:27:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.859 X-Spam-Level: X-Spam-Status: No, score=-4.859 tagged_above=-999 required=5 tests=[AWL=-0.712, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 iwPnlRelYQmG for ; Fri, 24 Feb 2012 19:27:46 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 06A5B11E8072 for ; Fri, 24 Feb 2012 19:27:45 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1P31j4E021195; Fri, 24 Feb 2012 19:01:46 -0800 (PST) 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 q1P312G7021144 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 24 Feb 2012 19:01:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tsenevir@cisco.com; l=48091; q=dns/txt; s=iport; t=1330138871; x=1331348471; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=PWiO0PYGBOvpPc/afLW+BTF3Ce2BNK4tLiuJSDSwZq8=; b=PNMY2MEb1n9Sv6E/1p3BCTPbaTG5KFOeUfrqJgPeu3j0AWFxmzBt5B3S q4p8wydFyqhw1CYkKAMmbG5pb2Y8SFvL3KbVvg5P8W6i5lEgV7Vbxw0Ts xcx1oJGfa/PF/H+LtOeyhARa5FxOhJSvN7guZ1F8X5JLQ6L/fhHVLcZpR M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAONNSE+rRDoG/2dsb2JhbAA5BwOCUYJppFwBiQuBB4FzAQEBBAEBAQ8BBwIRAz4LEAIBBgIOAwQBAQsGEAECBAEEAgEgBh8JCAIEEwgTB4djAQugOQGMXwiKBIkOYYMNAgIFAQQBAgQCAQEDCA0HAkiEZwEEGSMeBwQEAgMFAwQBFAYaDAMKggk3YwSIT5gEh3iBMgU X-IronPort-AV: E=Sophos;i="4.73,480,1325462400"; d="scan'208,217";a="32294472" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 25 Feb 2012 03:01:02 +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 q1P311RV008625; Sat, 25 Feb 2012 03:01:02 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, 24 Feb 2012 19:01:01 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 24 Feb 2012 19:01:00 -0800 Message-ID: <344037D7CFEFE84E97E9CC1F56C5F4A5A4656B@xmb-sjc-214.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Default nickname base approach for multilevel TRILL-draft-tissa-trill-multilevel-00.txt Thread-Index: AQHM8xj4bt2qI1nfQfiYK8zrqzIBUJZM3BiA//+EDXCAAIg2UA== References: <344037D7CFEFE84E97E9CC1F56C5F4A5A45E88@xmb-sjc-214.amer.cisco.com><344037D7CFEFE84E97E9CC1F56C5F4A5A462E7@xmb-sjc-214.amer.cisco.com><344037D7CFEFE84E97E9CC1F56C5F4A5A46325@xmb-sjc-214.amer.cisco.com> <344037D7CFEFE84E97E9CC1F56C5F4A5A46358@xmb-sjc-214.amer.cisco.com> From: "Tissa Senevirathne (tsenevir)" To: "Donald Eastlake" X-OriginalArrivalTime: 25 Feb 2012 03:01:01.0928 (UTC) FILETIME=[B4EA6E80:01CCF369] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: tsenevir@cisco.com Cc: rbridge@postel.org Subject: Re: [rbridge] Default nickname base approach for multilevel TRILL-draft-tissa-trill-multilevel-00.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: multipart/mixed; boundary="===============1371440615==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org This is a multi-part message in MIME format. --===============1371440615== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCF369.B498B0B8" This is a multi-part message in MIME format. ------_=_NextPart_001_01CCF369.B498B0B8 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable Hi Donald =20 Thanks for the reply and as always very thoughtful answers. Please see = in-line, below. =20 From: Donald Eastlake [mailto:Donald.Eastlake@huawei.com]=20 Sent: Friday, February 24, 2012 10:44 AM To: Tissa Senevirathne (tsenevir); Radia Perlman Cc: rbridge@postel.org; hu.fangwei@zte.com.cn Subject: RE: [rbridge] Default nickname base approach for multilevel = TRILL-draft-tissa-trill-multilevel-00.txt =20 See below at . =20 From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On = Behalf Of Tissa Senevirathne (tsenevir) Sent: Friday, February 24, 2012 1:00 PM To: Radia Perlman Cc: rbridge@postel.org; rbridge-bounces@postel.org; = hu.fangwei@zte.com.cn Subject: Re: [rbridge] Default nickname base approach for multilevel = TRILL- draft-tissa-trill-multilevel-00.txt =20 RBridges do not have to be in all topologies. Why would they should be? =20 I would agree that an RBridge does not have to be in all = topologies although I think it will be common for some RBridges to be in = many topologies. =20 I view a nickname as an abbreviation of the 48-bit IS-IS System = ID. The differences being that it is shorter, is auto allocated by = default, and there can be more than one of them that map to the same = System ID so that an RBridge can be the root of more than one = distribution tree and so that there could be an egress nickname that = uses traffic engineered routing rather than the default least cost = routing. Intermediate Systems do not have different System IDs in = different topologies, as far as I know. I don=A1=AFt see how/why they = would have different nicknames in different topologies. =20 =20 [Tissa] According to Section 5 of, RFC5120 (IS-IS Multi Topology), each = topology maintain it=A1=AFs own address space. The addresses in each = address space can be same or different with each other. Section 3 of RFC = 5120 explains how LSP needed to be exchanged between different IS when = MT is implemented. Section 6 explain how SPF needed to be run, in = summary SPF is per topology basis. Only difference between 5120 and = TRILL is 16 bit nickname vs. IP address. In short RB1 with systemID-1 = can have nickname 1 in topology 1, topology 2 and so on or nickname 1, = in topo 1, nickname 2 in topo 2 and so on. =20 =20 What is Fulcrum chip ?=20 =20 The four merchant silicon manufacturers that I know of that have = announced support for TRILL are, in alphabetic order, Broadcom, Fulcrum, = Marvel, and Mellanox. (Fulcrum has been acquired by Intel.) =20 [Tissa], I know you did not started discussion of these commercial = names, I was told IETF mailing lists should not be used for discussing = vendor capabilities. So I will refrain from further commenting on this. =20 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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Donald E. Eastlake, 3rd Donald.Eastlake@huawei.com 155 Beaver Street +1-508-333-2270=20 Milford, MA 01757 USA =20 =20 From: Radia Perlman [mailto:radiaperlman@gmail.com]=20 Sent: Friday, February 24, 2012 9:23 AM To: Tissa Senevirathne (tsenevir) Cc: hu.fangwei@zte.com.cn; rbridge@postel.org; = rbridge-bounces@postel.org Subject: Re: [rbridge] Default nickname base approach for multilevel = TRILL- draft-tissa-trill-multilevel-00.txt =20 I assume that all RBridges will need to be in all topologies, so = multitopology will not help with nickname exhaustion. Plus you haven't = explained how a TRILL packet would be marked as to which topology the = packet should be routed according to (other than what I mentioned, which = actually eats up nicknames by a factor of the number of topologies = supported). =20 Plus, rather than just lumping potential issues into a phrase such as = "NAT-like", be explicit about what issues there actually are. I believe = the Fulcrum chip would have no problem with translating the nickname = fields. =20 And rather than assuming that nickname exhaustion can be solved "some = other way", there should be a palatable solution before rejecting a = chance to solve it with multilevel. =20 Radia 2012/2/24 Tissa Senevirathne (tsenevir) Because you can have same nickname for different topology. It is not a = nickname that will identify an RBRidge, it is topology,nickname = combination that will identify an RBRidge. So RB1 can have nickname 1 in = topo-1 and RB2 can have nickname 1 in topo2. Now total nicknames in the = campus is 2**16 x topologies. =20 Stealing bits to represent topo id is only a workaround there can be = (are ) more elegant ways of doing it that. =20 Bottom line is we need to look for more creative methods of solving = nickname space issue than doing NAT like behavior.=20 =20 From: Radia Perlman [mailto:radiaperlman@gmail.com]=20 Sent: Friday, February 24, 2012 9:05 AM To: Tissa Senevirathne (tsenevir) Cc: hu.fangwei@zte.com.cn; rbridge@postel.org; = rbridge-bounces@postel.org=20 Subject: Re: [rbridge] Default nickname base approach for multilevel = TRILL- draft-tissa-trill-multilevel-00.txt =20 I don't understand how multi-topology helps with the nickname exhaustion = issue. As a matter of fact, the only plausible way of marking a packet = for which topology that has been suggested on the mailing list (I asked = a efw times if there were any other possibilities), was to steal 2 or 3 = bits of the nickname to encode which topology, in effect, making a = destination appear as multiple destinations and multiple forwarding = table entries (which you'd want anyway, for multitopology). =20 =20 Radia 2012/2/24 Tissa Senevirathne (tsenevir) Mutli-topology is the answer to increase the nickname space. =20 Nickname translation is very similar to NAT, which has it=A1=AFs own = down side, not to mention special hardware etc. to do the translations, = additionally. We also know from our experience, in IP world NATing is = not the most desired behavior and we live with it. So we should not be = going down that path instead need to look forward from that experience. =20 Multi-topology not only address nickname space issue but also enables = various other applications such as overlay topologies, traffic = engineering. =20 The draft-tiss-trill-multilevel present approaches that are generic, = which mean it can be applied for multi-topology, or base topology. It = utilizes the fundamentals of IS-IS , such as Area hierarchy for = reduction of the LSP-DB. It utilize affinity TLV concepts to effectively = solve multi-destination issues.=20 =20 We should not mix-up between Data center interconnects with data center = node scaling. They are two different and orthogonal issues. =20 Objective of multi-level trill is to interconnect different datacenters, = and maintain LSP-DB small as possible to avoid scaling and volatility. =20 Increasing nickname space a different requirement and has nothing to do = with data-center interconnects. =20 =20 From: Radia Perlman [mailto:radiaperlman@gmail.com]=20 Sent: Friday, February 24, 2012 6:15 AM To: hu.fangwei@zte.com.cn Cc: Tissa Senevirathne (tsenevir); rbridge@postel.org; = rbridge-bounces@postel.org Subject: Re: [rbridge] Default nickname base approach for multilevel = TRILL- draft-tissa-trill-multilevel-00.txt =20 People have mentioned to me that they are nervous about running out of = nicknames, especially since there are reasonson why they might want to = assign nicknames to hypervisors. With the alternate approach of = allowing nicknames to be reused in different areas, it makes automatic = nickname assignment much simpler and makes TRILL a lot more scalable. =20 It does have the downside of requiring mapping of nicknames at the = border RBridges. =20 And by the way, the affinity TLV can be used for multidestination frames = transiting between level 1 and level 2. =20 Radia 2012/2/23 Hi, Tissa.=20 I have several comments about the draft.=20 (1) in section 4.4 (Multicast), "The scope of global traffic may be = identified either through VLAN or via finegrain=20 label that spans across the entire TRILL campus."=20 Vlan and Fine-grain Label is used for service differentiation and = isolation. I do not quite understand that how to=20 use VLAN and fine-grain Lable to identify the traffic scope. The data = traffic with a given VLAN-x, can=20 be forwarded to other end station in the local area, or to the end = station in remote areas.=20 (2) nickname allocation=20 The nickname management sub-TLV is proposed in the document. I wonder = this mechanism adds the complication of =20 nickname allocation. As the section 1 (introduction) of RFC6325, one of = the important advantage of TRILL is that =20 it avoids the creating subnets of IP address and wasting address. The = nickname acquisition method in this draft violates the =20 idea of TRILL Basic specification, and reduces the flexibility of = nickname allocation. As the draft assumed, A1 had =20 nickname range of 100-200, A2 has a local nickname range of 201-300. If = the numbers of A1 area is only 50, so 50 =20 nicknames in A1 is wasted. As the network growing, the number of some = areas may exceed the number being allocation =20 by Border RBridges. The design and maintaining of nickname ranges for = each area is a very hard work. Even worst, it =20 can not avoid to waste nickname space.=20 (3) Dynamic ranges=20 The nickname range is divided into two range: local range and dynamical = range. I wonder the nickname conflict =20 resolution can not work if the RBridge get the nickname from the = dynamical range while the two RBridge belongs to =20 different areas. For example, RB1 is in area A1, and RB2 is in area A2. = If RB1 gets the nickname N1 from dynamic =20 range, and it will floods in area A1, and other RBridges in area A1 can = not get nickname N1 because of nickname =20 confliction mechanism, but RB2 in area A2 can not receive the PDU from = RB1, and it can also get the nickname N1 from =20 dynamical range. So the question is how to avoid the duplication = dynamical range nickname for different areas.=20 (4) The risk of running out of nickname maybe a issue for TRILL. The = number of 2**16 nickname is enough for the current data center,=20 but it maybe not enough in the future, especailly if TRILL over IP , = TRILL over MPLS technology or some other data center technologies=20 are deployed, the data center network can be a very lardge network. So = i think the very important and essential goal of multi-level draft is to = save nicknames.=20 Best regards=20 Fangwei Hu "Tissa Senevirathne (tsenevir)" =20 =B7=A2=BC=FE=C8=CB: rbridge-bounces@postel.org=20 2012-02-23 11:55=20 =CA=D5=BC=FE=C8=CB =20 =B3=AD=CB=CD =09 =D6=F7=CC=E2 [rbridge] Default nickname base approach for multilevel TRILL- = draft-tissa-trill-multilevel-00.txt =20 =09 =09 Dear All We have submitted draft-tissa-trill-multilevel, present multilevel TRILL = based on default nickname approach. Additionally we discuss construction = of multi-destination trees and related RPF in multilevel TRILL. Please = could you review and comment=20 Detail of the draft and abstract are below. Filename: draft-tissa-trill-multilevel Revision: 00 Title: Default Nickname Based Approach = for Multilevel TRILL Creation date: 2012-02-21 WG ID: Individual Submission Number of pages: 26 Abstract: Multilevel TRILL allows the interconnection of multiple TRILL networks to form a larger TRILL network without proportionally increasing the size of the IS-IS LSP DB. In this document, an approach based on default route concept is presented. Also, presented in the document is a novel method of constructing multi- destination trees using partial nickname space. Methods presented in this document are compatible with the RFC6325 specified data plane operations. = =20 Thanks Tissa _______________________________________________ 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 =20 =20 =20 ------_=_NextPart_001_01CCF369.B498B0B8 Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable

Hi Donald

 

Thanks for the reply and as always very thoughtful answers. Please = see in-line, below.

 

From:= = Donald Eastlake [mailto:Donald.Eastlake@huawei.com]
Sent: = Friday, February 24, 2012 10:44 AM
To: Tissa Senevirathne = (tsenevir); Radia Perlman
Cc: rbridge@postel.org; = hu.fangwei@zte.com.cn
Subject: RE: [rbridge] Default nickname = base approach for multilevel = TRILL-draft-tissa-trill-multilevel-00.txt

 

See below at <dee3>.

 

From:= = rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On = Behalf Of Tissa Senevirathne (tsenevir)
Sent: Friday, = February 24, 2012 1:00 PM
To: Radia Perlman
Cc: = rbridge@postel.org; rbridge-bounces@postel.org; = hu.fangwei@zte.com.cn
Subject: Re: [rbridge] Default nickname = base approach for multilevel TRILL- = draft-tissa-trill-multilevel-00.txt

 

RBridges do not have to be in all topologies. Why would they should = be?

 

<dee3> I would agree that an RBridge does not have to be in all = topologies although I think it will be common for some RBridges to be in = many topologies.

 

<dee3> I view a nickname as an abbreviation of the 48-bit IS-IS = System ID. The differences being that it is shorter, is auto allocated = by default, and there can be more than one of them that map to the same = System ID so that an RBridge can be the root of more than one = distribution tree and so that there could be an egress nickname that = uses traffic engineered routing rather than the default least cost = routing. Intermediate Systems do not have different System  IDs in = different topologies, as far as I know. I don=A1=AFt see how/why they = would have different nicknames in different = topologies.

 

 

[Tissa] According to Section 5 of, RFC5120 (IS-IS Multi Topology), = each topology maintain it=A1=AFs own address space. The addresses in = each address space can be same or different with each other. Section 3 = of RFC 5120 explains how LSP needed to be exchanged between different IS = when MT is implemented. Section 6 explain how SPF needed to be run, in = summary SPF is per topology basis. Only difference between 5120 and = TRILL is 16 bit nickname vs. IP address. In short RB1 with systemID-1 = can have nickname 1 in topology 1, topology 2 and so on or nickname 1, = in topo 1, nickname 2 in topo 2 and so on.

 

 

What is Fulcrum chip ?

 

<dee3> The four merchant silicon manufacturers that I know of = that have announced support for TRILL are, in alphabetic order, = Broadcom, Fulcrum, Marvel, and Mellanox. (Fulcrum has been acquired by = Intel.)

 

[Tissa], I know you did not started discussion of these commercial = names, I was told IETF mailing lists should not be used for discussing = vendor capabilities. So I will refrain from further commenting on = this.

 

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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /p>

Donald E. Eastlake, 3rd     = Donald.Eastlake@huawei.com

155 Beaver = Street           &= nbsp;  +1-508-333-2270

 Milford, MA 01757 USA

 

 

From:= = Radia Perlman [mailto:radiaperlman@gmail.com]
Sent: Friday, = February 24, 2012 9:23 AM
To: Tissa Senevirathne = (tsenevir)
Cc: hu.fangwei@zte.com.cn; rbridge@postel.org; = rbridge-bounces@postel.org
Subject: Re: [rbridge] Default = nickname base approach for multilevel TRILL- = draft-tissa-trill-multilevel-00.txt

 

I = assume that all RBridges will need to be in all topologies, = so multitopology will not help with nickname exhaustion.  Plus = you haven't explained how a TRILL packet would be marked as to which = topology the packet should be routed according to (other than what I = mentioned, which actually eats up nicknames by a factor of the number of = topologies supported).

 

Plus, rather than just lumping potential issues into a = phrase such as "NAT-like", be explicit about what issues there = actually are.  I believe the Fulcrum chip would have no problem = with translating the nickname fields.

 

And rather than assuming that nickname exhaustion can = be solved "some other way", there should be a palatable = solution before rejecting a chance to solve it with = multilevel.

 

Radia

2012/2/24 Tissa Senevirathne (tsenevir) <tsenevir@cisco.com><= /p>

Because you can have same nickname for different topology. It is not = a nickname that will identify an RBRidge, it is topology,nickname = combination that will identify an RBRidge. So RB1 can have nickname 1 in = topo-1 and RB2 can have nickname 1 in topo2. Now total nicknames in the = campus is 2**16 x topologies.

 

Stealing bits to represent topo id is only a workaround there can be = (are ) more elegant ways of doing it that.

 

Bottom line is we need to look for more creative methods of solving = nickname space issue than doing NAT like behavior. =

 

From:= = Radia Perlman [mailto:radiaperlman@gmail.com]
Sent: Friday, = February 24, 2012 9:05 AM
To: Tissa Senevirathne = (tsenevir)
Cc: hu.fangwei@zte.com.cn; rbridge@postel.org; rbridge-bounces@postel.org =


Subje= ct: Re: [rbridge] Default nickname base approach for multilevel = TRILL- = draft-tissa-trill-multilevel-00.txt

 <= /o:p>

I don't = understand how multi-topology helps with the nickname exhaustion = issue.  As a matter of fact, the only plausible way of marking a = packet for which topology that has been suggested on the mailing list (I = asked a efw times if there were any other possibilities), was to steal 2 = or 3 bits of the nickname to encode which topology, in effect, making a = destination appear as multiple destinations and multiple forwarding = table entries (which you'd want anyway, for = multitopology).

 <= /o:p>

 <= /o:p>

Radia

2012/2/24 = Tissa Senevirathne (tsenevir) <tsenevir@cisco.com>

Mutli-topology is the answer to increase the nickname = space.

 

Nickname translation is very similar to NAT, which has it=A1=AFs own = down side, not to mention special hardware etc. to do the translations, = additionally. We also know from our experience, in IP world NATing is = not the most desired behavior and we live with it. So we should not be = going down that path instead need to look forward from that = experience.

 

Multi-topology not only address nickname space issue but also enables = various other applications such as overlay topologies, traffic = engineering.

 

The draft-tiss-trill-multilevel present approaches that are generic, = which mean it can be applied for multi-topology, or base topology. It = utilizes the fundamentals of IS-IS , such as Area hierarchy for = reduction of the LSP-DB. It utilize affinity TLV concepts to effectively = solve multi-destination issues.

 

We should not mix-up between Data center interconnects with data = center node scaling. They are two different and orthogonal = issues.

 

Objective of multi-level trill is to interconnect different = datacenters, and maintain LSP-DB small as possible to avoid scaling and = volatility.

 

Increasing nickname space a different requirement and has nothing to = do with data-center interconnects.

 

 

From:= = Radia Perlman [mailto:radiaperlman@gmail.com]
Sent: Friday, = February 24, 2012 6:15 AM
To: hu.fangwei@zte.com.cn
Cc: Tissa = Senevirathne (tsenevir); rbridge@postel.org; rbridge-bounces@postel.org
Subject: Re: = [rbridge] Default nickname base approach for multilevel TRILL- = draft-tissa-trill-multilevel-00.txt

=

 <= /o:p>

People have = mentioned to me that they are nervous about running out of nicknames, = especially since there are reasonson why they might want to assign = nicknames to hypervisors.  With the alternate approach of allowing = nicknames to be reused in different areas, it makes automatic nickname = assignment much simpler and makes TRILL a lot more = scalable.

 <= /o:p>

It does = have the downside of requiring mapping of nicknames at the border = RBridges.

 <= /o:p>

And by the = way, the affinity TLV can be used for multidestination frames transiting = between level 1 and level 2.

 <= /o:p>

Radia

2012/2/23 = <hu.fangwei@zte.com.cn>


Hi, Tissa. =

I have several = comments about the draft.

(1) in section 4.4 = (Multicast), "The scope of global traffic may be identified either = through VLAN or via finegrain
label that spans across the = entire TRILL campus."
Vlan and Fine-grain Label is = used for service differentiation and isolation. I do not quite = understand that how to
use VLAN and fine-grain Lable = to identify the traffic scope. The data traffic with a given VLAN-x, can =
be forwarded = to other end station in the local area, or to the end station in remote = areas.

(2) nickname = allocation
The nickname management = sub-TLV is proposed in the document. I wonder this mechanism adds the = complication of  
nickname allocation. As the = section 1 (introduction) of RFC6325, one of the important advantage of = TRILL is that  
it avoids the creating = subnets of IP address and wasting address. The nickname acquisition =  method in this draft violates the  
idea of TRILL Basic = specification, and reduces the flexibility of nickname allocation. As = the draft assumed, A1 had  
nickname range of 100-200, A2 = has a local nickname range of 201-300. If the numbers of A1 area is only = 50, so 50  
nicknames in A1 is wasted. As = the network growing, the number of some areas may exceed the number = being allocation  
by Border RBridges. The = design and maintaining of nickname ranges for each area is a very hard = work. Even worst, it  
can not avoid to waste = nickname space.

(3) Dynamic ranges =
 The = nickname range is divided into two range: local range and dynamical = range. I wonder the nickname conflict  
resolution can not work if = the RBridge get the nickname from the dynamical range while the two = RBridge belongs to  
different areas. For example, = RB1 is in area A1, and RB2 is in area A2. If RB1 gets the nickname N1 = from dynamic  
range, and it will floods in = area A1, and other RBridges in area A1 can not get nickname N1 because = of nickname  
confliction mechanism, but = RB2 in area A2 can not receive the PDU from RB1, and it  can also = get the nickname N1 from  
dynamical range. So the = question is how to avoid the duplication dynamical range nickname for = different areas.

(4) The risk of running out = of nickname maybe a issue for TRILL. The number of 2**16 nickname is = enough for the current data center,
 but it maybe not enough = in the future, especailly if TRILL over IP , TRILL over MPLS technology = or some other data center technologies
 are deployed, the data = center network can be a very lardge network. So i think the very = important and essential goal of multi-level draft is to save = nicknames.

Best regards
Fangwei = Hu

"Tissa = Senevirathne (tsenevir)" <tsenevir@cisco.com> =
=B7=A2=BC=FE=C8=CB:  rbridge-bounces@postel.org =

2012-02-23 = 11:55

<rbridge@postel.org> =

=

=CA=D5=BC=FE=C8=CB

=B3=AD=CB=CD

=D6=F7=CC=E2

[rbridge] = Default nickname base approach for multilevel TRILL-     =   =  draft-tissa-trill-multilevel-00.txt

 <= /o:p>




De= ar All

We have submitted draft-tissa-trill-multilevel, = present multilevel TRILL based on default nickname approach. = Additionally we discuss construction of multi-destination trees and = related RPF in multilevel TRILL. Please could you review and comment =

Detail of the draft and abstract are = below.

Filename:           =       =  draft-tissa-trill-multilevel
Revision:     =              00
Title: =                     =               Default Nickname Based = Approach for Multilevel TRILL
Creation date:     =             =  2012-02-21
WG ID:           =                     =     Individual Submission
Number of pages: = 26

Abstract:
  Multilevel TRILL allows = the interconnection of multiple TRILL
  networks to = form a larger TRILL network without proportionally
  = increasing the size of the IS-IS LSP DB. In this document, = an
  approach based on default route concept is = presented. Also,
  presented in the document is a novel = method of constructing multi-
  destination trees using = partial nickname space. Methods presented in
  this = document are compatible with the RFC6325 specified data = plane
  operations.

    =                     =                     =                     =                 =  
Thanks
Tissa

_____________= __________________________________
rbridge mailing = list
rbridge@postel.org
http://mailman.postel.org/mailman/listinfo/rbridge<= /tt>


______________= _________________________________
rbridge mailing list
rbridge@postel.org
http://mailman.postel.org/mailman/listinfo/rbridge<= o:p>

 <= /o:p>

 <= /o:p>

 

------_=_NextPart_001_01CCF369.B498B0B8-- --===============1371440615== 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 --===============1371440615==-- From rbridge-bounces@postel.org Sat Feb 25 17:33: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 489A421F85F3 for ; Sat, 25 Feb 2012 17:33:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.245 X-Spam-Level: X-Spam-Status: No, score=-5.245 tagged_above=-999 required=5 tests=[AWL=1.353, 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 yaqjnRlslLts for ; Sat, 25 Feb 2012 17:33:35 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id A7CFF21F847C for ; Sat, 25 Feb 2012 17:33:35 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1Q18hPO011711; Sat, 25 Feb 2012 17:08:45 -0800 (PST) Received: from mail-tul01m020-f180.google.com (mail-tul01m020-f180.google.com [209.85.214.180]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1Q18882011366 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 25 Feb 2012 17:08:17 -0800 (PST) Received: by obbwd18 with SMTP id wd18so434847obb.39 for ; Sat, 25 Feb 2012 17:08:07 -0800 (PST) Received-SPF: pass (google.com: domain of vishwas.ietf@gmail.com designates 10.182.232.106 as permitted sender) client-ip=10.182.232.106; Authentication-Results: mr.google.com; spf=pass (google.com: domain of vishwas.ietf@gmail.com designates 10.182.232.106 as permitted sender) smtp.mail=vishwas.ietf@gmail.com; dkim=pass header.i=vishwas.ietf@gmail.com Received: from mr.google.com ([10.182.232.106]) by 10.182.232.106 with SMTP id tn10mr3127979obc.6.1330218487704 (num_hops = 1); Sat, 25 Feb 2012 17:08:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=H0acBJXD6wVES3qSW7u/BXwyxGzZ7PvoEAwMpEM+yJA=; b=U/TFr3z8cU61d2XcunAv2lQQiRBQ8aNF72miqLjsuoKsA7cQFotBWE50K9ujoi+VI3 A4RwQxWH4zQ1I/KrMGQAeDlGeJZC0t79r03wQKO2s+n1o16DRASjI8/+T1Ag/o0XNH81 gsGRIYtErqwXfjOBXNZ+YYg3bDVpou3Fhq/lo= MIME-Version: 1.0 Received: by 10.182.232.106 with SMTP id tn10mr2738723obc.6.1330218487604; Sat, 25 Feb 2012 17:08:07 -0800 (PST) Received: by 10.182.165.1 with HTTP; Sat, 25 Feb 2012 17:08:07 -0800 (PST) In-Reply-To: References: Date: Sat, 25 Feb 2012 17:08:07 -0800 Message-ID: From: Vishwas Manral To: Donald Eastlake Content-Type: multipart/mixed; boundary=f46d044473676d674504b9d3a0a1 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: vishwas.ietf@gmail.com Cc: "rbridge@postel.org" Subject: Re: [rbridge] WG last call on draft-ietf-trill-rbridge-bfd-02 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 --f46d044473676d674504b9d3a0a1 Content-Type: multipart/alternative; boundary=f46d044473676d672d04b9d3a09f --f46d044473676d672d04b9d3a09f Content-Type: text/plain; charset=ISO-8859-1 Hi Donald, I started to edit the document. I agree with the general concept of what we are trying to achieve but I disagree with the changes you mention below. I think BFD security should be in the BFD spec (infact there is BFD WG work on the same ). We can talk about keys used in the BFD. We already have work on the algorithms of BFD located in the link below. I do not see a reason BFD should use Keying mechanisms any different from what base BFD specification provides. Guess a reference to the below draft could be good enough. http://tools.ietf.org/html/draft-ietf-bfd-hmac-sha-00 I have attached the documents with the changes discussed in the WG though. Thanks, Vishwas On Thu, Feb 16, 2012 at 7:37 PM, Donald Eastlake wrote: > Hi Ayan, > > On Thu, Feb 16, 2012 at 12:27 AM, ayabaner wrote: > > Donald, > > > > Some comments in-line. > > > > Thanks, > > Ayan > > > > On 2/14/12 8:42 PM, "Donald Eastlake" wrote: > > > >> I would like to suggest the addition of some material to the Security > >> Considerations section. Something like what I've pasted below my .sig > >> and above Erik's message blow... > >> > >> Thanks, > >> Donald > >> ============================= > >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) > >> 155 Beaver Street, Milford, MA 01757 USA > >> d3e3e3@gmail.com > >> > >> > >> Consist with TRILL's goal of minimum configuration, the default for > >> BFD security between neighbor RBridges is based on that state of > >> IS-IS shared secret authentication for Hello between those > >> RBridges. If such IS-IS authentication is not in effect then, by > >> default, TRILL BFD between those RBridges is also unsecured. But > >> the RBridges may be configured to use BFD Security. > > > > [Ayan] I am assuming that the configuration above for the BFD Security is > > independent on the IS-IS authentication configurations (if any). > > Yes. The idea is just that, in the normal case where if you are going > to secure one, you are probably going to secure both Hellos and BFD, > consistent with TRILL's goal of minimal required configuration, you > should only have to configure IS-IS security if you are willing to > take the default BFD security. > > >> If such IS-IS authentication is in effect then, unless configured > >> otherwise, TRILL BFD Control frames sent between those RBridges use > >> BFD Meticulous Keyed SHA1 authentication [RF5880] with keying > >> material derived as shown below > >> > >> HMAC-SHA256 ( ( "TRILL BFD Control" | originatorMAC | > >> originatorPortID ), IS-IS-shared-key ) > >> > >> where HMAC-SHA256 [RFC6234], "TRILL BFD Control" is the seventeen > >> byte US ASCII [RFC20] string indicated that is then concatenated > >> with the 6-byte MAC of the originating port and then the 2-byte > >> Port ID as would be sent in a TRILL Hello on that port. These > >> quantities are included to minimize expose of the same key to > >> improve resistance to cryptanalysis. IS-IS-key is the secret keying > >> material being used for IS-IS authentication on the link. > > > > [Ayan] Should we be sharing the "secret" key between the two protocols or > > mandate the user to configure both to be identical. I realize the minimal > > configuration goals, but I am wondering if it would be nice to keep the > core > > TRILL-BFD pieces TRILL-IS-IS agnostic. > > This text doesn't go into implementation details, and I don't think it > should, you just need some way to give the key to the BFD code. Since > the BFD is derived in a cryptographically secure way from the IS-IS > key, neither one reveals anything about the other. Actually, the > expression for the key could be simplified. Since the PortID isn't > actually in the BFD messages, including it causes some complications > so it should probably be removed... > > Improved text, including typo fixes, at bottom of message below. > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > > >> In the > >> Authentication Section of the BFD Control frame OAM protocol > >> specific data, Auth Type would be 5, Auth Len would be 28, and Auth > >> Key ID is zero. The RBridges MAY be configured to use other BFD > >> security modes or keying material including configuration to use no > >> security. > >> > >> Authentication for TRILL BFD Echo SHOULD be provided but is a local > >> implementation issue as BFD Echo frames are authenticated by their > >> sender when received in the form of Echo responses. However, if > >> TRILL IS-IS and BFD Control are being authenticated to a neighbor > >> and BFD Echo is in use, BFD Echo frames to be returned by that > >> neighbor SHOULD be authenticated and such authenticate SHOULD use > >> different keying material from other types of authentication. For > >> example, it could use keying material derived as follows: > >> > >> HMAC-SHA256 ( ( "TRILL BFD Echo" | originatorMAC | > >> originatorPortID ), IS-IS-shared-key ) > >> > >> > >> On Wed, Feb 1, 2012 at 2:44 PM, Erik Nordmark wrote: > >>> > >>> The WG last call ends on Feb 15th. > >>> Please send comments (including ones that say you've read the document > >>> and it is fine) to the rbridge list. > >>> > >>> Erik > > > Consistent with TRILL's goal of being able to operate with minimum > configuration, the default for BFD security between neighbor > RBridges is based on that state of IS-IS shared secret > authentication for Hello between those RBridges. However, if such > BFD security is configured then its configuration is independent of > that for IS-IS security. > > If IS-IS authentication is not in effect between neighbor RBridges > then, by default, TRILL BFD between those RBridges is also > unsecured. If such IS-IS authentication is in effect then, unless > configured otherwise, TRILL BFD Control frames sent between those > RBridges use BFD Meticulous Keyed SHA1 authentication [RF5880] with > keying material derived as shown below > > HMAC-SHA256 ( ( "TRILL BFD Control" | originatorMAC ), > IS-IS-shared-key ) > > where HMAC-SHA256 is described in [RFC6234], "TRILL BFD Control" is > the seventeen byte US ASCII [RFC20] string indicated that is then > concatenated with the 6-byte MAC of the originating port. The MAC > is included to minimize exposure of the same key to improve > resistance to cryptanalysis. IS-IS-key is the secret keying > material being used for IS-IS authentication on the link. In the > Authentication Section of the BFD Control frame OAM protocol > specific data, Auth Type would be 5, Auth Len would be 28, and Auth > Key ID is zero. The RBridges MAY be configured to use other BFD > security modes or keying material or configured to use no security. > > Authentication for TRILL BFD Echo is a local implementation issue > as BFD Echo frames are authenticated by their sender when received > in the form of Echo responses. However, if TRILL IS-IS and BFD > Control are being authenticated to a neighbor and BFD Echo is in > use, BFD Echo frames to be returned by that neighbor SHOULD be > authenticated and such authenticate SHOULD use different keying > material from other types of authentication. For example, it could > use keying material derived as follows: > > HMAC-SHA256 ( ( "TRILL BFD Echo" | originatorMAC ), > IS-IS-shared-key ) > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > --f46d044473676d672d04b9d3a09f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Donald,

I started to edit the document. I agree with the general = concept of what we are trying to achieve but I disagree with the changes yo= u mention below.

I think BFD security should be in the BFD spec (inf= act there is BFD WG work on the same ). We can talk about keys used in the = BFD. We already have work on the algorithms of BFD located in the link belo= w. I do not see a reason BFD should use Keying mechanisms any different fro= m what base BFD specification provides. Guess a reference to the below draf= t could be good enough.

http:= //tools.ietf.org/html/draft-ietf-bfd-hmac-sha-00

I have attached= the documents with the changes discussed in the WG though.

Thanks,<= br> Vishwas

On Thu, Feb 16, 2012 at 7:37 PM, = Donald Eastlake <d= 3e3e3@gmail.com> wrote:
Hi Ayan,

On Thu, Feb 16, 2012 at 12:27 AM, ayabaner <ayabaner@cisco.com> wrote:
> Donald,
>
> Some comments in-line.
>
> Thanks,
> Ayan
>
> On 2/14/12 8:42 PM, "Donald Eastlake" <d3e3e3@gmail.com> wrote:
>
>> I would like to suggest the addition of some material to the Secur= ity
>> Considerations section. Something like what I've pasted below = my .sig
>> and above Erik's message blow...
>>
>> 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
>>
>>
>> =A0 =A0Consist with TRILL's goal of minimum configuration, the= default for
>> =A0 =A0BFD security between neighbor RBridges is based on that sta= te of
>> =A0 =A0IS-IS shared secret authentication for Hello between those<= br> >> =A0 =A0RBridges. =A0If such IS-IS authentication is not in effect = then, by
>> =A0 =A0default, TRILL BFD between those RBridges is also unsecured= . But
>> =A0 =A0the RBridges may be configured to use BFD Security.
>
> [Ayan] I am assuming that the configuration above for the BFD Security= is
> independent on the IS-IS authentication configurations (if any).

Yes. The idea is just that, in the normal case where if you are going=
to secure one, you are probably going to secure both Hellos and BFD,
consistent with TRILL's goal of minimal required configuration, you
should only have to configure IS-IS security if you are willing to
take the default BFD security.

>> =A0 =A0If such IS-IS authentication is in effect then, unless conf= igured
>> =A0 =A0otherwise, TRILL BFD Control frames sent between those RBri= dges use
>> =A0 =A0BFD Meticulous Keyed SHA1 authentication [RF5880] with keyi= ng
>> =A0 =A0material derived as shown below
>>
>> =A0 =A0 =A0 =A0HMAC-SHA256 ( ( "TRILL BFD Control" | ori= ginatorMAC |
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 originatorPortID )= , IS-IS-shared-key )
>>
>> =A0 =A0where HMAC-SHA256 [RFC6234], "TRILL BFD Control" = is the seventeen
>> =A0 =A0byte US ASCII [RFC20] string indicated that is then concate= nated
>> =A0 =A0with the 6-byte MAC of the originating port and then the 2-= byte
>> =A0 =A0Port ID as would be sent in a TRILL Hello on that port. The= se
>> =A0 =A0quantities are included to minimize expose of the same key = to
>> =A0 =A0improve resistance to cryptanalysis. IS-IS-key is the secre= t keying
>> =A0 =A0material being used for IS-IS authentication on the link. >
> [Ayan] Should we be sharing the "secret" key between the two= protocols or
> mandate the user to configure both to be identical. I realize the mini= mal
> configuration goals, but I am wondering if it would be nice to keep th= e core
> TRILL-BFD pieces TRILL-IS-IS agnostic.

This text doesn't go into implementation details, and I don't= think it
should, you just need some way to give the key to the BFD code. Since
the BFD is derived in a cryptographically secure way from the IS-IS
key, neither one reveals anything about the other. Actually, the
expression for the key could be simplified. Since the PortID isn't
actually in the BFD messages, including it causes some complications
so it should probably be removed...

Improved text, including typo fixes, at bottom of message below.

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

>> =A0 =A0In the
>> =A0 =A0Authentication Section of the BFD Control frame OAM protoco= l
>> =A0 =A0specific data, Auth Type would be 5, Auth Len would be 28, = and Auth
>> =A0 =A0Key ID is zero. The RBridges MAY be configured to use other= BFD
>> =A0 =A0security modes or keying material including configuration t= o use no
>> =A0 =A0security.
>>
>> =A0 =A0Authentication for TRILL BFD Echo SHOULD be provided but is= a local
>> =A0 =A0implementation issue as BFD Echo frames are authenticated b= y their
>> =A0 =A0sender when received in the form of Echo responses. However= , if
>> =A0 =A0TRILL IS-IS and BFD Control are being authenticated to a ne= ighbor
>> =A0 =A0and BFD Echo is in use, BFD Echo frames to be returned by t= hat
>> =A0 =A0neighbor SHOULD be authenticated and such authenticate SHOU= LD use
>> =A0 =A0different keying material from other types of authenticatio= n. =A0For
>> =A0 =A0example, it could use keying material derived as follows: >>
>> =A0 =A0 =A0 HMAC-SHA256 ( ( "TRILL BFD Echo" | originato= rMAC |
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 originatorPortID ), IS= -IS-shared-key )
>>
>>
>> On Wed, Feb 1, 2012 at 2:44 PM, Erik Nordmark <nordmark@acm.org> wrote:
>>>
>>> The WG last call ends on Feb 15th.
>>> Please send comments (including ones that say you've read = the document
>>> and it is fine) to the rbridge list.
>>>
>>> =A0 Erik


=A0 Consistent with TRILL's goal of being able to operate with m= inimum
=A0 configuration, the default for BFD security between = neighbor
=A0 RBridges is based on that state of IS-IS shared secret
=A0 authentication for Hello between those RBridges. However, if suc= h
=A0 BFD security is configured then its configuration is independent of =A0 that for IS-IS security.

=A0 If IS-IS authentication is not in effect between neighbor RBridges
=A0 then, by default, TRILL BFD between those RBridges i= s also
=A0 unsecured. If such IS-IS authentication is in effect then, unles= s
=A0 configured otherwise, TRILL BFD Control frames sent = between those
=A0 RBridges use BFD Meticulous Keyed SHA1 authentication [RF5880] with =A0 keying material derived as shown below

=A0 =A0 =A0 HMAC-SHA256 ( ( "TRILL BFD Control" | originat= orMAC ),
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 IS-IS-shared-key )

=A0 where HMAC-SHA256 is described in [RFC6234], "TRILL BFD Control&q= uot; is
=A0 the seventeen byte US ASCII [RFC20] string indicated= that is then
=A0 concatenated with the 6-byte MAC of the originating port. The MA= C
=A0 is included to minimize exposure of the same key to improve
=A0 resistance to cryptanalysis. IS-IS-key is the secret= keying
=A0 material being used for IS-IS authentication on the link. In the=
=A0 Authentication Section of the BFD Control frame OAM = protocol
=A0 specific data, Auth Type would be 5, Auth Len would be 28, and Auth =A0 Key ID is zero. The RBridges MAY be configured to use other BFD
=A0 security modes or keying material or configured to use no securi= ty.

=A0 Authentication for TRILL BFD Echo is a local implementation issue
=A0 as BFD Echo frames are authenticated by their sender= when received
=A0 in the form of Echo responses. However, if TRILL IS-IS and BFD
=A0 Control are being authenticated to a neighbor and BFD Echo is in
=A0 use, BFD Echo frames to be returned by that neighbor SHOULD be
=A0 authenticated and such authenticate SHOULD use different keying
=A0 material from other types of authentication. =A0For example, it could<= br> =A0 use keying material derived as follows:

=A0 =A0 =A0HMAC-SHA256 ( ( "TRILL BFD Echo" | originatorMA= C ),
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IS-IS-shared-key )

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

--f46d044473676d672d04b9d3a09f-- --f46d044473676d674504b9d3a0a1 Content-Type: text/plain; charset=US-ASCII; name="draft-ietf-trill-rbridge-bfd-03.txt" Content-Disposition: attachment; filename="draft-ietf-trill-rbridge-bfd-03.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gz3dq4st0 DQpOZXR3b3JrIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBWLiBNYW5yYWwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgSGV3bGV0dCBQYWNrYXJkIENvLg0KSW50ZW5kZWQgc3RhdHVzOiBTdGFu ZGFyZHMtVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEQuIEVhc3RsYWtlDQpFeHBp cmVzOiBKdWx5IDI3LCAyMDEyICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSHVh d2VpIFImRCBVU0ENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgRC4gV2FyZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEEuIEJhbmVyamVlDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENpc2NvIFN5 c3RlbXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgSmFudWFyeSAyNCwgMjAxMg0KDQoNCiAgUmJyaWRnZXM6IEJpZGlyZWN0aW9uYWwgRm9y d2FyZGluZyBEZXRlY3Rpb24gKEJGRCkgc3VwcG9ydCBmb3IgVFJJTEwNCiAgICAgICAgICAgICAg ICAgICAgZHJhZnQtaWV0Zi10cmlsbC1yYnJpZGdlLWJmZC0wMg0KDQpBYnN0cmFjdA0KDQogICBU aGlzIGRvY3VtZW50IHNwZWNpZmllcyB1c2Ugb2YgdGhlIEJGRCAoQmlkaXJlY3Rpb25hbCBGb3J3 YXJkaW5nDQogICBEZXRlY3Rpb24pIHByb3RvY29sIGluIFJCcmlkZ2UgY2FtcHVzZXMgYmFzZWQg b24gdGhlIFJicmlkZ2UgDQogICBleHRlbnNpb24gdG8gdGhlIHRoZSBUUklMTCAoVFJhbnNwYXJl bnQgSW50ZXJjb25uZWN0aW9uIG9mIExvdHMgb2YNCiAgIExpbmtzKSBwcm90b2NvbC4NCg0KICAg QkZEIGlzIGEgd2lkZWx5IGRlcGxveWVkIE9BTSAoT3BlcmF0aW9ucywgQWRtaW5pc3RyYXRpb24s IGFuZA0KICAgTWFpbnRlbmFuY2UpIG1lY2hhbmlzbSBpbiBJUCBhbmQgTVBMUyBuZXR3b3Jrcywg dXNpbmcgVURQIGFuZCBBQ0gNCiAgIGVuY2Fwc3VsYXRpb24gcmVzcGVjdGl2ZWx5LiAgVGhpcyBk b2N1bWVudCBzcGVjaWZpZXMgdGhlIEJGRA0KICAgZW5jYXBzdWxhdGlvbiBvdmVyIFRSSUxMLg0K DQpSZXF1aXJlbWVudHMgTGFuZ3VhZ2UNCg0KICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNU IE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLA0KICAgIlNIT1VMRCIsICJT SE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMN CiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gW1JGQzIx MTldLg0KDQpTdGF0dXMgb2YgdGhpcyBNZW1vDQoNCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgaXMg c3VibWl0dGVkIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGUNCiAgIHByb3Zpc2lvbnMgb2Yg QkNQIDc4IGFuZCBCQ1AgNzkuDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1 bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nDQogICBUYXNrIEZvcmNlIChJRVRGKS4g IE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZQ0KICAgd29ya2luZyBk b2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5l dC0NCiAgIERyYWZ0cyBpcyBhdCBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZHJhZnRzL2N1 cnJlbnQvLg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBm b3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMNCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFj ZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55DQogICB0aW1lLiAgSXQg aXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQ0KICAg bWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3Mu Ig0KDQogICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIEp1bHkgMjcsIDIwMTIu DQoNCg0KDQoNCk1hbnJhbCwgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBKdWx5IDI3LCAyMDEy ICAgICAgICAgICAgICAgICBbUGFnZSAxXQ0KDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgQkZE IFRSSUxMIEVuY2Fwc3VsYXRpb24gICAgICAgICAgICBKYW51YXJ5IDIwMTINCg0KDQpDb3B5cmln aHQgTm90aWNlDQoNCiAgIENvcHlyaWdodCAoYykgMjAxMiBJRVRGIFRydXN0IGFuZCB0aGUgcGVy c29ucyBpZGVudGlmaWVkIGFzIHRoZQ0KICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMg cmVzZXJ2ZWQuDQoNCiAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRo ZSBJRVRGIFRydXN0J3MgTGVnYWwNCiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1 bWVudHMNCiAgIChodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVmZmVj dCBvbiB0aGUgZGF0ZSBvZg0KICAgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudC4gIFBsZWFz ZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzDQogICBjYXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUg eW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3QNCiAgIHRvIHRoaXMgZG9j dW1lbnQuICBDb2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVudCBtdXN0 DQogICBpbmNsdWRlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UgdGV4dCBhcyBkZXNjcmliZWQgaW4g U2VjdGlvbiA0LmUgb2YNCiAgIHRoZSBUcnVzdCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJv dmlkZWQgd2l0aG91dCB3YXJyYW50eSBhcw0KICAgZGVzY3JpYmVkIGluIHRoZSBTaW1wbGlmaWVk IEJTRCBMaWNlbnNlLg0KDQoNClRhYmxlIG9mIENvbnRlbnRzDQoNCiAgIDEuICBJbnRyb2R1Y3Rp b24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMw0K ICAgMi4gIFRlcm1pbm9sb2d5IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAzDQogICAzLiAgQkZEIG92ZXIgVFJJTEwgIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQNCiAgIDQuICBTZXNzaW9ucyBhbmQgSW5p dGlhbGl6YXRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNA0KICAgNS4g IFJlbGF0aW9uc2hpcCB0byBNUExTIE9BTSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiA1DQogICA2LiAgVFJJTEwgQkZEIENvbnRyb2wgUHJvdG9jb2wgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDUNCiAgIDcuICBPbmUtSG9wIFRSSUxMIEJGRCBDb250 cm9sIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNg0KICAgOC4gIEJGRCBD b250cm9sIEZyYW1lIFByb2Nlc3NpbmcgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiA2DQogICA5LiAgVFJJTEwgQkZEIEVjaG8gUHJvdG9jb2wgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDcNCiAgICAgOS4xLiAgQkZEIEVjaG8gRnJhbWUgUHJvY2Vzc2lu ZyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNw0KICAgMTAuIE1hbmFnZW1lbnQg YW5kIE9wZXJhdGlvbnMgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA4DQog ICAxMS4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDgNCiAgIDEyLiBJQU5BIENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gOQ0KICAgMTMuIEFja25vd2xlZGdlbWVudHMg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA5DQogICAxNC4g UmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgMTANCiAgICAgMTQuMS4gTm9ybWF0aXZlIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMA0KICAgICAxNC4yLiBJbmZvcm1hdGl2ZSBSZWZlcmVu Y2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEwDQogICBBdXRob3JzJyBB ZGRyZXNzZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg MTENCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCk1hbnJhbCwgZXQgYWwuICAgICAgICAg ICAgRXhwaXJlcyBKdWx5IDI3LCAyMDEyICAgICAgICAgICAgICAgICBbUGFnZSAyXQ0KDQpJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgQkZEIFRSSUxMIEVuY2Fwc3VsYXRpb24gICAgICAgICAgICBK YW51YXJ5IDIwMTINCg0KDQoxLiAgSW50cm9kdWN0aW9uDQoNCiAgIEZhc3RlciBjb252ZXJnZW5j ZSBpcyBhIGNyaXRpY2FsIGZlYXR1cmUgb2YgVFJJTEwgbmV0d29ya3MuICBUaGUNCiAgIFRSSUxM IElTLUlTIEhlbGxvcyB1c2VkIGJldHdlZW4gUkJyaWRnZXMgcHJvdmlkZSBhIGJhc2ljIG5laWdo Ym9yIGFuZA0KICAgY29udGludWl0eSBjaGVjayBmb3IgVFJJTEwgbGlua3MuICBIb3dldmVyLCBm YWlsdXJlIGRldGVjdGlvbiBieSBub24tDQogICByZWNlaXB0IG9mIHN1Y2ggSGVsbG9zIGlzIGJh c2VkIG9uIHRoZSBob2xkaW5nIHRpbWUgcGFyYW1ldGVyIHRoYXQgaXMNCiAgIGNvbW1vbmx5IHNl dCB0byBhIHZhbHVlIG9mIHRlbnMgb2Ygc2Vjb25kcyBhbmQsIGluIGFueSBjYXNlLCBoYXMgYQ0K ICAgbWluaW11bSBleHByZXNzaWJsZSB2YWx1ZSBvZiBvbmUgc2Vjb25kLg0KDQogICBTb21lIGFw cGxpY2F0aW9ucywgaW5jbHVkaW5nIHZvaWNlIG92ZXIgSVAsIG1heSB3aXNoLCB3aXRoIGhpZ2gN CiAgIHByb2JhYmlsaXR5LCB0byBkZXRlY3QgaW50ZXJydXB0aW9ucyBpbiBjb250aW51aXR5IHdp dGhpbiBhIG11Y2gNCiAgIHNob3J0ZXIgdGltZSBwZXJpb2QuICBJbiBzb21lIGNhc2VzIHBoeXNp Y2FsIGxheWVyIGZhaWx1cmVzIGNhbiBiZQ0KICAgZGV0ZWN0ZWQgdmVyeSByYXBpZGx5IGJ1dCB0 aGlzIGlzIG5vdCBhbHdheXMgcG9zc2libGUsIHN1Y2ggYXMgd2hlbg0KICAgdGhlcmUgaXMgYSBm YWlsdXJlIGJldHdlZW4gdHdvIGJyaWRnZXMgdGhhdCBhcmUgaW4gdHVybiBiZXR3ZWVuIHR3bw0K ICAgUkJyaWRnZXMuICBUaGVyZSBhcmUgYWxzbyBtYW55IHN1YnRsZSBmYWlsdXJlcyBwb3NzaWJs ZSBhdCBoaWdoZXINCiAgIGxldmVscy4gIEZvciBleGFtcGxlLCBzb21lIGZvcm1zIG9mIGZhaWx1 cmUgY291bGQgYWZmZWN0IHVuaWNhc3QNCiAgIGZyYW1lcyB3aGlsZSBzdGlsbCBsZXR0aW5nIG11 bHRpY2FzdCBmcmFtZXMgdGhyb3VnaDsgc2luY2UgYWxsIFRSSUxMDQogICBJUy1JUyBIZWxsb3Mg YXJlIG11bHRpY2FzdCBzdWNoIGEgZmFpbHVyZSBjYW5ub3QgYmUgZGV0ZWN0ZWQgd2l0aA0KICAg SGVsbG9zLiAgVGh1cywgYSBsb3cgb3ZlcmhlYWQgbWV0aG9kIGZvciBmcmVxdWVudGx5IHRlc3Rp bmcNCiAgIGNvbnRpbnVpdHkgZm9yIHRoZSBUUklMTCBEYXRhIGJldHdlZW4gbmVpZ2hib3IgUkJy aWRnZXMgaXMgbmVjZXNzYXJ5DQogICBmb3Igc29tZSBhcHBsaWNhdGlvbnMuICBCRkQgcHJvdG9j b2wgcHJvdmlkZXMgYSBsb3ctb3ZlcmhlYWQsIHNob3J0LQ0KICAgZHVyYXRpb24gZGV0ZWN0aW9u IG9mIGZhaWx1cmVzIGluIHRoZSBwYXRoIGJldHdlZW4gZm9yd2FyZGluZw0KICAgZW5naW5lcy4N Cg0KICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBUUklMTCBlbmNhcHN1bGF0aW9uIGZvciBC RkQgcGFja2V0cyBmb3INCiAgIG5ldHdvcmtzIHRoYXQgZG8gbm90IHVzZSBJUCBhZGRyZXNzaW5n IG9yIGZvciBvbmVzIHdoZXJlIGl0IGlzIG5vdA0KICAgZGVzaXJlYWJsZS4NCg0KDQoyLiAgVGVy bWlub2xvZ3kNCg0KICAgQUNIOiBBc3NvY2lhdGVkICBIZWFkZXINCg0KICAgQkZEOiBCaS1kaXJl Y3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbg0KDQogICBJUDogSW50ZXJuZXQgUHJvdG9jb2wN Cg0KICAgSVMtSVM6IEludGVybWVkaWF0ZS1TeXN0ZW0gdG8gSW50ZXJtZWRpYXRlLVN5c3RlbQ0K DQogICBNUExTOiBNdWx0aSBQcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcNCg0KICAgUFBQOiBQb2lu dC10by1Qb2ludCBQcm90b2NvbA0KDQogICBPQU06IE9wZXJhdGlvbnMsIEFkbWluaXN0cmF0aW9u LCBhbmQgTWFpbnRlbmFuY2UNCg0KDQoNCg0KDQoNCg0KTWFucmFsLCBldCBhbC4gICAgICAgICAg ICBFeHBpcmVzIEp1bHkgMjcsIDIwMTIgICAgICAgICAgICAgICAgIFtQYWdlIDNdDQoNCkludGVy bmV0LURyYWZ0ICAgICAgICAgICBCRkQgVFJJTEwgRW5jYXBzdWxhdGlvbiAgICAgICAgICAgIEph bnVhcnkgMjAxMg0KDQoNCjMuICBCRkQgb3ZlciBUUklMTA0KDQogICBUUklMTCBzdXBwb3J0cyBu ZWlnaGJvciBCRkQgRWNobyBhbmQgb25lLWhvcCBhbmQgbXVsdGktaG9wIEJGRA0KICAgQ29udHJv bCwgYXMgc3BlY2lmaWVkIGJlbG93LCBvdmVyIHRoZSBSYnJpZGdlIENoYW5uZWwgZmFjaWxpdHku DQogICBNdWx0aS1kZXN0aW5hdGlvbiBCRkQgaXMgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIGRv Y3VtZW50LCBhbHRob3VnaA0KICAgdGhlcmUgaXMgd29yayBpbiB0aGUgYXJlYS4gIFRoZSBSYnJp ZGdlIENoYW5uZWwgZmFjaWxpdHkgaXMgc3BlY2lmaWVkDQogICBpbiBbVFJJTExvYW1dLg0KDQog ICBCRkQgb3ZlciBUUklMTCBzdXBwb3J0IGlzIHNpbWlsYXIgdG8gQkZEIG92ZXIgSVAgc3VwcG9y dCBbUkZDNTg4MV0NCiAgIGV4Y2VwdCB3aGVyZSBkaWZmZXJlbmNlcyBhcmUgZXhwbGljaXRseSBt ZW50aW9uZWQuICBXaGVuIHJ1bm5pbmcgQkZEDQogICBvdmVyIFRSSUxMIGJvdGggU2luZ2xlIEhv cCBhcyB3ZWxsIGFzIGluIE11bHRpIEhvcCBzZXNzaW9ucyBhcmUNCiAgIHN1cHBvcnRlZC4NCg0K ICAgQXN5bmNocm9ub3VzIG1vZGUgaXMgc3VwcG9ydGVkLCBhbmQgdGhlIGRlbWFuZCBtb2RlIGlz IG5vdCBzdXBwb3J0ZWQNCiAgIGZvciBUUklMTC4gIEJGRCBvdmVyIFRSSUxMIHN1cHBvcnRzIHRo ZSBFY2hvIGZ1bmN0aW9uLCBob3dldmVyIHRoaXMNCiAgIGNhbiBiZSB1c2VkIGZvciBvbmx5IFNp bmdsZSBob3Agc2Vzc2lvbnMuDQoNCiAgIFRoZSBUUklMTCBIZWFkZXIgSG9wIGNvdW50IGluIHRo ZSBCRkQgcGFja2V0cyBpcyBzZW50IG91dCB3aXRoIHRoZQ0KICAgbWF4aW11bSB2YWx1ZSBvZiA2 My4gIFRvIHByZXZlbnQgc3Bvb2ZpbmcgYXR0YWNrcywgdGhlIFRSSUxMIEhvcA0KICAgY291bnQg b2YgYSByZWNlaXZlZCBzZXNzaW9uIGlzIGNoZWNrZWQgW1JGQzUwODJdLiAgRm9yIGEgc2luZ2xl IEhvcA0KICAgc2Vzc2lvbiBpZiB0aGUgSG9wIGNvdW50IGlzIGxlc3MgdGhhbiA2MywgYW5kIHRo ZSBSYnJpZGdlIENoYW5uZWwNCiAgIEhlYWRlciBNSCBmbGFnIGlzIHplcm8sIHRoZSBwYWNrZXQg aXMgZGlzY2FyZGVkLiAgRm9yIE11bHRpIEhvcA0KICAgc2Vzc2lvbnMgdGhlIEhvcCBjb3VudCBj aGVjayBjYW4gYmUgZGlzYWJsZWQgaWYgdGhlIE1IIGZsYWcgaXMgb25lLg0KDQogICBMaWtlIGlu IEJGRCBmb3IgSVAgdGhlIGZvcm1hdCBvZiB0aGUgRWNobyBQYWNrZXQgY29udGVudCBpcyBub3QN CiAgIGRlZmluZWQuDQoNCiAgIE5ldyBSYnJpZGdlIENoYW5uZWwgdHlwZXMgZm9yIEJGRCBUUklM TCBDb250cm9sIGZyYW1lIGFuZCBCRkQgZWNobw0KICAgcGFja2V0IGFyZSBzcGVjaWZpZWQuDQoN CiAgIEF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbXMgYXMgc3VwcG9ydGVkIGluIEJGRCBhcmUgYWxz byBzdXBwb3J0ZWQgZm9yDQogICBCRkQgcnVubmluZyBvdmVyIFRSSUxMLg0KDQoNCjQuICBTZXNz aW9ucyBhbmQgSW5pdGlhbGl6YXRpb24NCg0KICAgV2l0aGluIGFuIFJCcmlkZ2UgY2FtcHVzLCB0 aGVyZSB3aWxsIGJlIG9ubHkgYSBzaW5nbGUgVFJJTEwgQkZEDQogICBDb250cm9sIHNlc3Npb24g YmV0d2VlbiB0d28gUkJyaWRnZXMgb3ZlciBhIGdpdmVuIGludGVyZmFjZSB2aXNpYmxlDQogICB0 byBUUklMTC4gIFRoaXMgQkZEIHNlc3Npb24gbXVzdCBiZSBib3VuZCB0byB0aGlzIGludGVyZmFj ZS4gIEFzDQogICBzdWNoLCBib3RoIHNpZGVzIG9mIGEgc2Vzc2lvbiBNVVNUIHRha2UgdGhlICJB Y3RpdmUiIHJvbGUgKHNlbmRpbmcNCiAgIGluaXRpYWwgQkZEIENvbnRyb2wgcGFja2V0cyB3aXRo IGEgemVybyB2YWx1ZSBvZiBZb3VyIERpc2NyaW1pbmF0b3IpLA0KICAgYW5kIGFueSBCRkQgcGFj a2V0IGZyb20gdGhlIHJlbW90ZSBtYWNoaW5lIHdpdGggYSB6ZXJvIHZhbHVlIG9mIFlvdXINCiAg IERpc2NyaW1pbmF0b3IgTVVTVCBiZSBhc3NvY2lhdGVkIHdpdGggdGhlIHNlc3Npb24gYm91bmQg dG8gdGhlIHJlbW90ZQ0KICAgc3lzdGVtIGFuZCBpbnRlcmZhY2UuDQoNCiAgIE5vdGUgdGhhdCBU UklMTCBCRkQgcHJvdmlkZXMgT0FNIGZhY2lsaXRpZXMgZm9yIHRoZSBUUklMTCBEYXRhIHBsYW5l Lg0KICAgVGhpcyBpcyBhYm92ZSB3aGF0ZXZlciBwcm90b2NvbCBpcyBpbiB1c2Ugb24gYSBwYXJ0 aWN1bGFyIGxpbmssIHN1Y2gNCiAgIGFzIGEgUFBQIFtUcmlsbFBQUF0gbGluayBvciBhbiBFdGhl cm5ldCBsaW5rLiAgTGluayB0ZWNobm9sb2d5DQoNCg0KDQpNYW5yYWwsIGV0IGFsLiAgICAgICAg ICAgIEV4cGlyZXMgSnVseSAyNywgMjAxMiAgICAgICAgICAgICAgICAgW1BhZ2UgNF0NCg0KSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgIEJGRCBUUklMTCBFbmNhcHN1bGF0aW9uICAgICAgICAgICAg SmFudWFyeSAyMDEyDQoNCg0KICAgc3BlY2lmaWMgT0FNIHByb3RvY29scyBtYXkgYmUgdXNlZCBv biBhIGxpbmsgYmV0d2VlbiBuZWlnaGJvcg0KICAgUkJyaWRnZXMsIGZvciBleGFtcGxlIENvbnRp bnVpdHkgRmF1bHQgTWFuYWdlbWVudCBbODAyLjFRXSBpZiB0aGUNCiAgIGxpbmsgaXMgRXRoZXJu ZXQuICBCdXQgc3VjaCBsaW5rIGxheWVyIE9BTSBhbmQgY29vcmRpbmF0aW9uIGJldHdlZW4NCiAg IGl0IGFuZCBUUklMTCBkYXRhIHBsYWVuIGxheWVyIE9BTSwgc3VjaCBhcyBUUklMTCBCRkQsIGlz IGJleW9uZCB0aGUNCiAgIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuDQoNCiAgIElmIGxvd2VyIGxl dmVsIG1lY2hhbmlzbXMsIHN1Y2ggYXMgbGluayBhZ2dyZWdhdGlvbiBbODAyLjFBWF0sIGFyZSBp bg0KICAgdXNlIHRoYXQgcHJlc2VudCBhIHNpbmdsZSBsb2dpY2FsIGludGVyZmFjZSB0byBUUklM TCBJUy1JUywgb25seSBhDQogICBzaW5nbGUgVFJJTEwgQkZEIHNlc3Npb24gY2FuIGJlIGVzdGFi bGlzaGVkIHRvIGFueSBvdGhlciBSQnJpZGdlIG92ZXINCiAgIHRoaXMgbG9naWNhbCBpbnRlcmZh Y2UuICBIb3dldmVyLCBsb3dlciBsYXllciBPQU0gY291bGQgYmUgYXdhcmUgb2YNCiAgIGFuZC9v ciBydW4gc2VwYXJhdGVseSBvbiBlYWNoIG9mIHRoZSBjb21wb25lbnRzIG9mIGFuIGFnZ3JlZ2F0 aW9uLg0KDQoNCjUuICBSZWxhdGlvbnNoaXAgdG8gTVBMUyBPQU0NCg0KICAgVFJJTEwgQkZEIHVz ZXMgdGhlIFRSSUxMIFJicmlkZ2UgQ2hhbm5lbCBbVFJJTExDaGFubmVsXSBzaW1pbGFyIHRvDQog ICB0aGUgd2F5IHRoYXQgTVBMUyBPQU0gcHJvdG9jb2xzIHVzZSB0aGUgTVBMUyBHZW5lcmljIEFz c29jaWF0ZWQNCiAgIENoYW5uZWwgW1JGQzU1ODZdLiAgSG93ZXZlciwgdGhlIFJCcmlkZ2VzIHRo YXQgaW1wbGVtZW50IFRSSUxMIGFyZQ0KICAgSVMtSVMgW0lTLUlTXSBiYXNlZCByb3V0ZXJzLCBu b3QgbGFiZWwgc3dpdGNoZWQgcm91dGVyczsgdGh1cyBUUklMTA0KICAgQkZEIGlzIGNsb3NlciB0 byBJUHY0L0lQdjYgQkZEIHRoYW4gdG8gTVBMUyBCRkQuDQoNCiAgIFRSSUxMIEJGRCBvcHRpb25h bGx5IGluY2x1ZGVzIHN1cHBvcnQgb2YgQkZEIEVjaG8gdGhhdCBpcyBub3QNCiAgIHNwZWNpZmll ZCBmb3IgTVBMUyBCRkQsIGR1ZSB0byB0aGUgb25lIHdheSBuYXR1cmUgb2YgdGhlIGJhc2ljIE1Q TFMNCiAgIHNlcnZpY2UuDQoNCg0KNi4gIFRSSUxMIEJGRCBDb250cm9sIFByb3RvY29sDQoNCiAg IFRSSUxMIEJGRCBDb250cm9sIGZyYW1lcyBhcmUgdW5pY2FzdCBUUklMTCBSYnJpZGdlIENoYW5u ZWwNCiAgIGZyYW1lcyBbVFJJTExDaGFubmVsXS4gIFRoZSBSYnJpZGdlIENoYW5uZWwgUHJvdG9j b2wgdmFsdWUgaXMgZ2l2ZW4NCiAgIGluIFNlY3Rpb24gMTAuDQoNCiAgIFRoZSBwcm90b2NvbCBz cGVjaWZpYyBkYXRhIGFzc29jaWF0ZWQgd2l0aCB0aGUgVFJJTEwgQkZEIENvbnRyb2wNCiAgIHBy b3RvY29sIGlzIGFzIHNob3duIGJlbG93LiAgU2VlIFtSRkM1ODgwXSBmb3IgZnVydGhlciBpbmZv cm1hdGlvbiBvbg0KICAgdGhlc2UgZmllbGRzLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQpNYW5yYWwsIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgSnVseSAyNywgMjAxMiAgICAg ICAgICAgICAgICAgW1BhZ2UgNV0NCg0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgIEJGRCBUUklM TCBFbmNhcHN1bGF0aW9uICAgICAgICAgICAgSmFudWFyeSAyMDEyDQoNCg0KICAgIFRSSUxMIEJG RCBDb250cm9sIFByb3RvY29sIERhdGE6DQogICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgICB8VmVycyB8 ICBEaWFnICAgfFN0YXxQfEZ8Q3xBfER8TXwgIERldGVjdCBNdWx0ICB8ICAgIExlbmd0aCAgICAg fA0KICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rDQogICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgTXkgRGlz Y3JpbWluYXRvciAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICArLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgWW91ciBEaXNjcmltaW5hdG9yICAgICAgICAgICAg ICAgICAgICAgICB8DQogICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgICB8ICAgICAgICAgICAgICAgICAg ICBEZXNpcmVkIE1pbiBUWCBJbnRlcnZhbCAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rDQogICAgICAgfCAgICAgICAgICAgICAgICAgICBSZXF1aXJlZCBNaW4gUlggSW50ZXJ2 YWwgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICAgIHwgICAgICAg ICAgICAgICAgIFJlcXVpcmVkIE1pbiBFY2hvIFJYIEludGVydmFsICAgICAgICAgICAgICAgICB8 DQogICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSsNCiAgICBPcHRpb25hbCBBdXRoZW50aWNhdGlvbiBTZWN0aW9uOg0K ICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rDQogICAgICAgfCAgIEF1dGggVHlwZSAgIHwgICBBdXRoIExlbiAgICB8 ICAgIEF1dGhlbnRpY2F0aW9uIERhdGEuLi4gICAgIHwNCiAgICAgICArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQoNCjcu ICBPbmUtSG9wIFRSSUxMIEJGRCBDb250cm9sDQoNCiAgIE9uZS1ob3AgVFJJTEwgQkZEIENvbnRy b2wgaXMgdHlwaWNhbGx5IHVzZWQgdG8gcmFwaWRseSBkZXRlY3QgbGluaw0KICAgYW5kIFJCcmlk Z2UgZmFpbHVyZXMuICBUUklMTCBCRkQgZnJhbWVzIG92ZXIgb25lIGhvcCBmb3Igc3VjaA0KICAg cHVycG9zZXMgU0hPVUxEIGJlIHNlbnQgd2l0aCBwcmlvcml0eSA3Lg0KDQogICBGb3IgbmVpZ2hi b3IgUkJyaWRnZXMgUkIxIGFuZCBSQjIsIGVhY2ggUkJyaWRnZSBzZW5kcyBvbmUtaG9wIFRSSUxM DQogICBCRkQgQ29udHJvbCBmcmFtZXMgdG8gdGhlIG90aGVyIG9ubHkgaWYgVFJJTEwgSVMtSVMg aGFzIGRldGVjdGVkIGJpLQ0KICAgZGlyZWN0aW9uYWwgY29ubmVjdGl2aXR5ICwgdGhhdCBpcywg dGhlIGFkamFjZW5jeSBpcyBpbiB0aGUgVHdvLVdheQ0KICAgb3IgcmVwb3J0IFJlcG9ydCBzdGF0 ZXMgW1JGQzYzMjddIGFuZCBib3RoIFJCcmlkZ2VzIGluZGljYXRlIHN1cHBvcnQNCiAgIG9mIFRS SUxMIEJGRCBpcyBlbmFibGVkLiAgVGhlIEJGRCBFbmFibGVkIFRMViBpcyB1c2VkIHRvIGluZGlj YXRlDQogICB0aGlzIGFzIHNwZWNpZmllZCBpbiBbUkZDNjIxM10uDQoNCg0KOC4gIEJGRCBDb250 cm9sIEZyYW1lIFByb2Nlc3NpbmcNCg0KICAgVGhlIGZvbGxvd2luZyB0ZXN0cyBTSE9VTEQgYmUg cGVyZm9ybWVkIG9uIHJlY2VpdmVkIFRSSUxMIEJGRCBDb250cm9sDQogICBmcmFtZXMgYmVmb3Jl IGdlbmVyaWMgQkZEIHByb2Nlc3NpbmcuDQoNCiAgIElzIHRoZSBNIGJpdCBpbiB0aGUgVFJJTEwg SGVhZGVyIG5vbi16ZXJvPyAgSWYgc28sIGRpc2NhcmQgdGhlIGZyYW1lLg0KICAgVFJJTEwgc3Vw cG9ydCBvZiBtdWx0aS1kZXN0aW5hdGlvbiBCRkQgQ29udHJvbCBpcyBiZXlvbmQgdGhlIHNjb3Bl IG9mDQogICB0aGlzIGRvY3VtZW50LCBhbHRob3VnaCB3b3JrIGlzIGJlaW5nIGRvbmUgaW4gdGhl IEFyZWEgW011bHRpQkZEXS4NCg0KICAgSWYgdGhlIENoYW5uZWwgSGVhZGVyIE1IIGZsYWcgaXMg emVybywgaW5kaWNhdGluZyBvbmUtaG9wLCB0ZXN0IHRoYXQNCiAgIHRoZSBUUklMTCBIZWFkZXIg aG9wIGNvdW50IHJlY2VpdmVkIHdhcyAweDNGIChpLmUuLCBpcyAweDNFIGlmIGl0IGhhcw0KICAg YWxyZWFkeSBiZWVuIGRlY3JlbWVudGVkKSBhbmQgaWYgaXQgaXMgYW55IG90aGVyIHZhbHVlIGRp c2NhcmQgdGhlDQogICBmcmFtZS4gIElmIHRoZSBNSCBDaGFubmVsIGZsYWcgaXMgb25lLCBpbmRp Y2F0aW5nIG11bHRpLWhvcCwgdGVzdA0KICAgdGhhdCB0aGUgVFJJTEwgSGVhZGVyIGhvcCBjb3Vu dCByZWNlaXZlZCB3YXMgbm90IGxlc3MgdGhhbiBhDQoNCg0KDQpNYW5yYWwsIGV0IGFsLiAgICAg ICAgICAgIEV4cGlyZXMgSnVseSAyNywgMjAxMiAgICAgICAgICAgICAgICAgW1BhZ2UgNl0NCg0K SW50ZXJuZXQtRHJhZnQgICAgICAgICAgIEJGRCBUUklMTCBFbmNhcHN1bGF0aW9uICAgICAgICAg ICAgSmFudWFyeSAyMDEyDQoNCg0KICAgY29uZmlndXJhYmxlIHZhbHVlIHRoYXQgZGVmYXVsdHMg dG8gMHgzMC4gIElmIGl0IGlzIGxlc3MsIGRpc2NhcmQgdGhlDQogICBmcmFtZS4NCg0KDQo5LiAg VFJJTEwgQkZEIEVjaG8gUHJvdG9jb2wNCg0KICAgQSBUUklMTCBCRkQgRWNobyBmcmFtZSBpcyBh IHVuaWNhc3QgUmJyaWRnZSBDaGFubmVsIGZyYW1lLA0KICAgYXMgc3BlY2lmaWVkIGluIFtUUklM TG9hbV0sIHdoaWNoIHNob3VsZCBiZSBmb3J3YXJkZWQgYmFjayBieSBhbg0KICAgaW1tZWRpYXRl IG5laWdoYm9yIGJlY2F1c2UgYm90aCB0aGUgaW5ncmVzcyBhbmQgZWdyZXNzIG5pY2tuYW1lcyBh cmUNCiAgIHNldCB0byBhIG5pY2tuYW1lIG9mIHRoZSBvcmlnaW5hdGluZyBSQnJpZGdlLiAgTm9y bWFsIFRSSUxMIERhdGENCiAgIGZyYW1lIGZvcndhcmRpbmcgd2lsbCBjYXVzZSB0aGUgZnJhbWUg dG8gYmUgcmV0dXJuZWQuICBUaGUgVFJJTEwgT0FNDQogICBwcm90b2NvbCBudW1iZXIgZm9yIEJG RCBFY2hvIGlzIGdpdmVuIGluIFNlY3Rpb24gNC4NCg0KICAgVFJJTEwgQkZEIEVjaG8gZnJhbWVz IFNIT1VMRCBvbmx5IGJlIHNlbnQgb24gYSBsaW5rIGlmDQoNCiAgIEEgVFJJTEwgQkZEIENvbnRy b2wgc2Vzc2lvbiBoYXMgYmVlbiBlc3RhYmxpc2hlZCwNCg0KICAgVFJJTEwgQkZEIEVjaG8gc3Vw cG9ydCBpcyBpbmRpY2F0ZWQgYnkgdGhlIHBvdGVudGlhbGx5IGVjaG8NCiAgIHJlc3BvbmRpbmcg UkJyaWRnZS4NCg0KICAgVGhlIGFkamFjZW5jeSBpcyBpbiB0aGUgUmVwb3J0IHN0YXRlIFtSRkM2 MzI3XSwgYW5kDQoNCiAgIFRoZSBUUklMTCBCRkQgRWNobyBvcmlnaW5hdGluZyBSQnJpZGdlIHdp c2hlcyB0byBtYWtlIHVzZSBvZiB0aGlzDQogICBvcHRpb25hbCBmZWF0dXJlLg0KDQogICBTaW5j ZSB0aGUgb3JpZ2luYXRpbmcgUkJyaWRnZSBpcyB0aGUgUkJyaWRnZSB0aGF0IHdpbGwgYmUgcHJv Y2Vzc2luZw0KICAgYSByZXR1cm5lZCBFY2hvIGZyYW1lLCB0aGUgZW50aXJlIFRSSUxMIEJGRCBF Y2hvIHByb3RvY29sIHNwZWNpZmljDQogICBkYXRhIGFyZWEgaXMgY29uc2lkZXJlZCBvcGFxdWUg YW5kIGxlZnQgdG8gdGhlIGRpc2NyZXRpb24gb2YgdGhlDQogICBvcmlnaW5hdGluZyBSQnJpZGdl LiAgTmV2ZXJ0aGVsZXNzLCBpdCBpcyBSRUNPTU1FTkRFRCB0aGF0IHRoaXMgZGF0YQ0KICAgaW5j bHVkZSBpbmZvcm1hdGlvbiBieSB3aGljaCB0aGUgb3JpZ2luYXRpbmcgUkJyaWRnZSBjYW4gYXV0 aGVudGljYXRlDQogICB0aGUgcmV0dXJuZWQgQkZEIEVjaG8gZnJhbWUgYW5kIGNvbmZpcm0gdGhl IG5laWdoYm9yIHRoYXQgZWNob2VkIHRoZQ0KICAgZnJhbWUgYmFjay4gIEZvciBleGFtcGxlLCBp dCBjb3VsZCBpbmNsdWRlIGl0cyBvd24gU3lzdGVtSUQsIHRoZQ0KICAgbmVpZ2hib3IncyBTeXN0 ZW1JRCwgYSBzZXNzaW9uIGlkZW50aWZpZXIgYW5kIGEgc2VxdWVuY2UgY291bnQgYXMNCiAgIHdl bGwgYXMgYSBNZXNzYWdlIEF1dGhlbnRpY2F0aW9uIENvZGUuDQoNCjkuMS4gIEJGRCBFY2hvIEZy YW1lIFByb2Nlc3NpbmcNCg0KICAgVGhlIGZvbGxvd2luZyB0ZXN0cyBNVVNUIGJlIHBlcmZvcm1l ZCBvbiByZXR1cm5lZCBUUklMTCBCRkQgRWNobw0KICAgZnJhbWVzIGJlZm9yZSBvdGhlciBwcm9j ZXNzaW5nLiAgVGhlIFJCcmlkZ2UgQ2hhbm5lbCBkb2N1bWVudA0KICAgcmVxdWlyZXMgdGhhdCB0 aGUgaW5mb3JtYXRpb24gaW4gdGhlIFRSSUxMIEhlYWRlciBiZSBnaXZlbiB0byB0aGUgQkZEDQog ICBwcm90b2NvbC4NCg0KICAgSXMgdGhlIE0tYml0IGluIHRoZSBUUklMTCBIZWFkZXIgbm9uLXpl cm8/ICBJZiBzbywgZGlzY2FyZCB0aGUgZnJhbWUuDQogICBUUklMTCBzdXBwb3J0IG9mIG11bHRp LWRlc3RpbmF0aW9uIEJGRCBFY2hvIGlzIGJleW9uZCB0aGUgc2NvcGUgb2YNCiAgIHRoaXMgZG9j dW1lbnQuDQoNCiAgIFRoZSBUUklMTCBCRkQgRWNobyBmcmFtZSBzaG91bGQgaGF2ZSBnb25lIGV4 YWN0bHkgdHdvIGhvcHMgc28gdGVzdA0KICAgdGhhdCB0aGUgVFJJTEwgSGVhZGVyIGhvcCBjb3Vu dCBhcyByZWNlaXZlZCB3YXMgMHgzRSAoaS5lLiwgMHgzRCBpZg0KDQoNCg0KTWFucmFsLCBldCBh bC4gICAgICAgICAgICBFeHBpcmVzIEp1bHkgMjcsIDIwMTIgICAgICAgICAgICAgICAgIFtQYWdl IDddDQoNCkludGVybmV0LURyYWZ0ICAgICAgICAgICBCRkQgVFJJTEwgRW5jYXBzdWxhdGlvbiAg ICAgICAgICAgIEphbnVhcnkgMjAxMg0KDQoNCiAgIGl0IGhhcyBhbHJlYWR5IGJlZW4gZGVjcmVt ZW50ZWQpIGFuZCBpZiBpdCBpcyBhbnkgb3RoZXIgdmFsdWUgZGlzY2FyZA0KICAgdGhlIGZyYW1l LiAgVGhlIFJicmlkZ2UgQ2hhbm5lbCBIZWFkZXIgaW4gdGhlIGZyYW1lIHNob3VsZCBoYXZlIHRo ZSBNSCBiaXQNCiAgIGVxdWFsIHRvIG9uZSBhbmQgaWYgaXQgaXMgemVybywgdGhlIGZyYW1lIGlz IGRpc2NhcmRlZC4NCg0KDQoxMC4gIE1hbmFnZW1lbnQgYW5kIE9wZXJhdGlvbnMgQ29uc2lkZXJh dGlvbnMNCg0KICAgVGhlIFRSSUxMIEJGRCBwYXJhbWV0ZXJzIG9uIGFuIFJCcmlkZ2UgYXJlIGNv bmZpZ3VyYWJsZS4gIFRoZSBkZWZhdWx0DQogICB2YWx1ZXMgYXJlIHRoZSBzYW1lIGFzIGluIHRo ZSBJUCBCRkQgY2FzZSBbUkZDNTg4MV0sIGV4Y2VwdCB3aGVyZQ0KICAgc3BlY2lmaWVkIGluIHRo aXMgZG9jdW1lbnQgc3VjaCBhcyBmb3IgSG9wIENvdW50Lg0KDQogICBJdCBpcyByZXF1aXJlZCB0 aGF0IHRoZSBvcGVyYXRvciBvZiBhbiBSQnJpZGdlIGNhbXB1cyBjb25maWd1cmUgdGhlDQogICBy YXRlcyBhdCB3aGljaCBUUklMTCBCRkQgZnJhbWVzIGFyZSB0cmFuc21pdHRlZCBvbiBhIGxpbmsg dG8gYXZvaWQNCiAgIGNvbmdlc3Rpb24gKGUuZy4sIGxpbmssIEkvTywgQ1BVKSBhbmQgZmFsc2Ug ZmFpbHVyZSBkZXRlY3Rpb24uDQoNCg0KMTEuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KDQog IENvbnNpc3RlbnQgd2l0aCBUUklMTCdzIGdvYWwgb2YgYmVpbmcgYWJsZSB0byBvcGVyYXRlIHdp dGggbWluaW11bQ0KICBjb25maWd1cmF0aW9uLCB0aGUgZGVmYXVsdCBmb3IgQkZEIHNlY3VyaXR5 IGJldHdlZW4gbmVpZ2hib3INCiAgUkJyaWRnZXMgaXMgYmFzZWQgb24gdGhhdCBzdGF0ZSBvZiBJ Uy1JUyBzaGFyZWQgc2VjcmV0DQogIGF1dGhlbnRpY2F0aW9uIGZvciBIZWxsbyBiZXR3ZWVuIHRo b3NlIFJCcmlkZ2VzLiBIb3dldmVyLCBpZiBzdWNoDQogIEJGRCBzZWN1cml0eSBpcyBjb25maWd1 cmVkIHRoZW4gaXRzIGNvbmZpZ3VyYXRpb24gaXMgaW5kZXBlbmRlbnQgb2YNCiAgdGhhdCBmb3Ig SVMtSVMgc2VjdXJpdHkuDQoNCiAgSWYgSVMtSVMgYXV0aGVudGljYXRpb24gaXMgbm90IGluIGVm ZmVjdCBiZXR3ZWVuIG5laWdoYm9yIFJCcmlkZ2VzDQogIHRoZW4sIGJ5IGRlZmF1bHQsIFRSSUxM IEJGRCBiZXR3ZWVuIHRob3NlIFJCcmlkZ2VzIGlzIGFsc28NCiAgdW5zZWN1cmVkLiBJZiBzdWNo IElTLUlTIGF1dGhlbnRpY2F0aW9uIGlzIGluIGVmZmVjdCB0aGVuLCB1bmxlc3MNCiAgY29uZmln dXJlZCBvdGhlcndpc2UsIFRSSUxMIEJGRCBDb250cm9sIGZyYW1lcyBzZW50IGJldHdlZW4gdGhv c2UNCiAgUkJyaWRnZXMgdXNlIEJGRCBNZXRpY3Vsb3VzIEtleWVkIFNIQTEgYXV0aGVudGljYXRp b24gW1JGNTg4MF0gd2l0aA0KICBrZXlpbmcgbWF0ZXJpYWwgZGVyaXZlZCBhcyBzaG93biBiZWxv dw0KDQoNCk1hbnJhbCwgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBKdWx5IDI3LCAyMDEyICAg ICAgICAgICAgICAgICBbUGFnZSA4XQ0KDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgQkZEIFRS SUxMIEVuY2Fwc3VsYXRpb24gICAgICAgICAgICBKYW51YXJ5IDIwMTINCg0KDQoNCiAgICAgIEhN QUMtU0hBMjU2ICggKCAiVFJJTEwgQkZEIENvbnRyb2wiIHwgb3JpZ2luYXRvck1BQyApLA0KICAg ICAgICAgICAgICAgICAgICBJUy1JUy1zaGFyZWQta2V5ICkNCg0KICB3aGVyZSBITUFDLVNIQTI1 NiBpcyBkZXNjcmliZWQgaW4gW1JGQzYyMzRdLCAiVFJJTEwgQkZEIENvbnRyb2wiIGlzDQogIHRo ZSBzZXZlbnRlZW4gYnl0ZSBVUyBBU0NJSSBbUkZDMjBdIHN0cmluZyBpbmRpY2F0ZWQgdGhhdCBp cyB0aGVuDQogIGNvbmNhdGVuYXRlZCB3aXRoIHRoZSA2LWJ5dGUgTUFDIG9mIHRoZSBvcmlnaW5h dGluZyBwb3J0LiBUaGUgTUFDDQogIGlzIGluY2x1ZGVkIHRvIG1pbmltaXplIGV4cG9zdXJlIG9m IHRoZSBzYW1lIGtleSB0byBpbXByb3ZlDQogIHJlc2lzdGFuY2UgdG8gY3J5cHRhbmFseXNpcy4g SVMtSVMta2V5IGlzIHRoZSBzZWNyZXQga2V5aW5nDQogIG1hdGVyaWFsIGJlaW5nIHVzZWQgZm9y IElTLUlTIGF1dGhlbnRpY2F0aW9uIG9uIHRoZSBsaW5rLiBJbiB0aGUNCiAgQXV0aGVudGljYXRp b24gU2VjdGlvbiBvZiB0aGUgQkZEIENvbnRyb2wgZnJhbWUgT0FNIHByb3RvY29sDQogIHNwZWNp ZmljIGRhdGEsIEF1dGggVHlwZSB3b3VsZCBiZSA1LCBBdXRoIExlbiB3b3VsZCBiZSAyOCwgYW5k IEF1dGgNCiAgS2V5IElEIGlzIHplcm8uIFRoZSBSQnJpZGdlcyBNQVkgYmUgY29uZmlndXJlZCB0 byB1c2Ugb3RoZXIgQkZEDQogIHNlY3VyaXR5IG1vZGVzIG9yIGtleWluZyBtYXRlcmlhbCBvciBj b25maWd1cmVkIHRvIHVzZSBubyBzZWN1cml0eS4NCg0KICBBdXRoZW50aWNhdGlvbiBmb3IgVFJJ TEwgQkZEIEVjaG8gaXMgYSBsb2NhbCBpbXBsZW1lbnRhdGlvbiBpc3N1ZQ0KICBhcyBCRkQgRWNo byBmcmFtZXMgYXJlIGF1dGhlbnRpY2F0ZWQgYnkgdGhlaXIgc2VuZGVyIHdoZW4gcmVjZWl2ZWQN CiAgaW4gdGhlIGZvcm0gb2YgRWNobyByZXNwb25zZXMuIEhvd2V2ZXIsIGlmIFRSSUxMIElTLUlT IGFuZCBCRkQNCiAgQ29udHJvbCBhcmUgYmVpbmcgYXV0aGVudGljYXRlZCB0byBhIG5laWdoYm9y IGFuZCBCRkQgRWNobyBpcyBpbg0KICB1c2UsIEJGRCBFY2hvIGZyYW1lcyB0byBiZSByZXR1cm5l ZCBieSB0aGF0IG5laWdoYm9yIFNIT1VMRCBiZQ0KICBhdXRoZW50aWNhdGVkIGFuZCBzdWNoIGF1 dGhlbnRpY2F0ZSBTSE9VTEQgdXNlIGRpZmZlcmVudCBrZXlpbmcNCiAgbWF0ZXJpYWwgZnJvbSBv dGhlciB0eXBlcyBvZiBhdXRoZW50aWNhdGlvbi4gIEZvciBleGFtcGxlLCBpdCBjb3VsZA0KICB1 c2Uga2V5aW5nIG1hdGVyaWFsIGRlcml2ZWQgYXMgZm9sbG93czoNCg0KICAgICBITUFDLVNIQTI1 NiAoICggIlRSSUxMIEJGRCBFY2hvIiB8IG9yaWdpbmF0b3JNQUMgKSwNCiAgICAgICAgICAgICAg ICAgICBJUy1JUy1zaGFyZWQta2V5ICkNCg0KDQoxMi4gIElBTkEgQ29uc2lkZXJhdGlvbnMNCg0K ICAgSUFOQSBpcyByZXF1ZXN0IHRvIGFsbG9jYXRlIHR3byBSYnJpZGdlIENoYW5uZWwgUHJvdG9j b2wgbnVtYmVycyBmcm9tIHRoZQ0KICAgcmFuZ2UgYWxsb2NhdGVkIGJ5IFN0YW5kYXJkcyBBY3Rp b25zLCBhcyBmb2xsb3dzOg0KDQoNCiAgICAgICBQcm90b2NvbCAgICAgTnVtYmVyDQogICAgICAg LS0tLS0tLS0gICAgIC0tLS0tLQ0KICAgICAgIEJGRCBDb250cm9sICAgVEJEICgyIHN1Z2dlc3Rl ZCkNCiAgICAgICBCRkQgRWNobyAgICAgIFRCRCAoMyBzdWdnZXN0ZWQpDQoNCg0KDQoxMy4gIEFj a25vd2xlZGdlbWVudHMNCg0KICAgVGhlIGF1dGhvcnMgd291bGQgbGlrZSB0byB0aGFuayBEYXZl IEthdHogdGhlIGF1dGhvciBvZiBbUkZDNTg4MF0gYW5kDQogICBbUkZDNTg4MV0uDQoNCg0KMTQu ICBSZWZlcmVuY2VzDQoNCg0KDQpNYW5yYWwsIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgSnVs eSAyNywgMjAxMiAgICAgICAgICAgICAgICAgW1BhZ2UgOV0NCg0KSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgIEJGRCBUUklMTCBFbmNhcHN1bGF0aW9uICAgICAgICAgICAgSmFudWFyeSAyMDEyDQoN Cg0KMTQuMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzDQoNCiAgIFtSRkMyMTE5XSAgQnJhZG5lciwg Uy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlDQogICAgICAgICAgICAg IFJlcXVpcmVtZW50IExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTksIE1hcmNoIDE5OTcuDQogICBb UkZDNTA4Ml0gIEdpbGwsIFYuLCBIZWFzbGV5LCBKLiwgTWV5ZXIsIEQuLCBTYXZvbGEsIFAuLCBh bmQgQy4NCiAgICAgICAgICAgICAgUGlnbmF0YXJvLCAiVGhlIEdlbmVyYWxpemVkIFRUTCBTZWN1 cml0eSBNZWNoYW5pc20NCiAgICAgICAgICAgICAgKEdUU00pIiwgUkZDIDUwODIsIE9jdG9iZXIg MjAwNy4NCg0KICAgW1JGQzU1ODZdICBCb2NjaSwgTS4sIFZpZ291cmV1eCwgTS4sIGFuZCBTLiBC cnlhbnQsICJNUExTIEdlbmVyaWMNCiAgICAgICAgICAgICAgQXNzb2NpYXRlZCBDaGFubmVsIiwg UkZDIDU1ODYsIEp1bmUgMjAwOS4NCg0KICAgW1JGQzU4ODBdICBLYXR6LCBELiBhbmQgRC4gV2Fy ZCwgIkJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24NCiAgICAgICAgICAgICAgKEJG RCkiLCBSRkMgNTg4MCwgSnVuZSAyMDEwLg0KDQogICBbUkZDNTg4MV0gIEthdHosIEQuIGFuZCBE LiBXYXJkLCAiQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbg0KICAgICAgICAgICAg IChCRkQpIGZvciBJUHY0IGFuZCBJUHY2IChTaW5nbGUgSG9wKSIsIFJGQyA1ODgxLCBKdW5lIDIw MTAuDQoNCiAgIFtSRkM2MjEzXSBIb3BwcywgQy4gYW5kIEwuIEdpbnNiZXJnLCAiSVMtSVMgQkZE LUVuYWJsZWQgVExWIiwgDQogICAgICAgICAgICAgUkZDIDYyMTMsIEFwcmlsIDIwMTEuDQoNCiAg IFtSRkM2MzI1XSBQZXJsbWFuLCBSLiwgRWFzdGxha2UgM3JkLCBELiwgRHV0dCwgRC4sIEdhaSwg Uy4sIGFuZCANCiAgICAgICAgICAgICBBLiBHaGFud2FuaSwgIlJvdXRpbmcgQnJpZGdlcyAoUkJy aWRnZXMpOiBCYXNlIFByb3RvY29sIA0KICAgICAgICAgICAgIFNwZWNpZmljYXRpb24iLCBSRkMg NjMyNSwgSnVseSAyMDExLg0KDQogICBbUkZDNjMyN10gRWFzdGxha2UsIEQuLCBSLiBQZXJsbWFu LCBBLiBHaGFud2FuaSwgRC4gRHV0dCwgVi4gTWFucmFsLA0KICAgICAgICAgICAgICAgIlJCcmlk Z2VzOiBBZGphY2VuY3kiLCBSRkMgNjMyNywgSnVseSAyMDExLg0KDQogICBbVFJJTExDaGFubmVs XSBFYXN0bGFrZSwgRC4sIFYuIE1hbnJhbCwgWS4gTGksIFMuIEFsZHJpbiwgRC4gV2FyZCwgDQog ICAgICAgICAgICAgICJSQnJpZGdlczogUkJyaWRnZSBDaGFubmVsIFN1cHBvcnQgaW4gVFJJTEwi LCANCiAgICAgICAgICAgICAgZHJhZnQtaWV0Zi10cmlsbC1yYnJpZGdlLWNoYW5uZWwsIHdvcmsg aW4gcHJvZ3Jlc3MuDQoNCjE0LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzDQoNCiAgIFs4MDIu MUFYXSAgSUVFRSwgIklFRUUgU3RhbmRhcmQgZm9yIExvY2FsIGFuZCBtZXRyb3BvbGl0YW4gYXJl YQ0KICAgICAgICAgICAgICBuZXR3b3JrcyAvIExpbmsgQWdncmVnYXRpb24iLCA4MDIuMUFYLTIw MDgsIA0KICAgICAgICAgICAgICAxIEphbnVhcnkgMjAwOC4NCg0KDQogICBbODAyLjFRXSBJRUVF IDgwMi4xLCAiSUVFRSBTdGFuZGFyZCBmb3IgTG9jYWwgYW5kIG1ldHJvcG9saXRhbg0KICAgICAg ICAgYXJlYSBuZXR3b3JrcyAtIFZpcnR1YWwgQnJpZGdlZCBMb2NhbCBBcmVhIE5ldHdvcmtzIiwg SUVFRSBTdGQNCiAgICAgICAgIDgwMi4xUS0yMDExLCBNYXkgMjAxMS4NCg0KICAgW1JGQzYzNjFd ICBDYXJsc29uLCBKLiBhbmQgRC4gRWFzdGxha2UgM3JkLCAiUFBQIFRyYW5zcGFyZW50IA0KICAg ICAgICAgICAgICBJbnRlcmNvbm5lY3Rpb24gb2YgTG90cyBvZiBMaW5rcyAoVFJJTEwpIFByb3Rv Y29sIA0KICAgICAgICAgICAgICBDb250cm9sIFByb3RvY29sIiwgUkZDIDYzNjEsIEF1Z3VzdCAy MDExLg0KDQogICBbSVMtSVNdIElTTy9JRUMgMTA1ODk6MjAwMiwgIkludGVybWVkaWF0ZSBzeXN0 ZW0gdG8gSW50ZXJtZWRpYXRlDQogICAgICAgICAgIHN5c3RlbSByb3V0ZWluZyBpbmZvcm1hdGlv biBleGNoYW5nZSBwcm90b2NvbCBmb3IgdXNlIGluDQogICAgICAgICAgIGNvbmp1bmN0aW9uIHdp dGggdGhlIFByb3RvY29sIGZvciBwcm92aWRpbmcgdGhlIA0KICAgICAgICAgICBDb25uZWN0aW9u bGVzcy1tb2RlIE5ldHdvcmtTZXJ2aWNlIChJU08gODQ3MyksIiANCiAgICAgICAgICAgSVNPL0lF QyAxMDU4OToyMDAyLg0KDQogICBbTXVsdGlCRkRdIEthdHosIEQuIGFuZCBELiBXYXJkLCAiZHJh ZnQtaWV0Zi1iZmQtbXVsdGlwb2ludCIsDQogICAgICAgICAgIHdvcmsgaW4gcHJvZ3Jlc3MuDQoN Ck1hbnJhbCwgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBKdWx5IDI3LCAyMDEyICAgICAgICAg ICAgICAgICBbUGFnZSAxMF0NCg0KDQpBdXRob3JzJyBBZGRyZXNzZXMNCg0KICAgVmlzaHdhcyBN YW5yYWwNCiAgIEhld2xldHQgUGFja2FyZCBDby4NCiAgIDE5MTExIFBydW5lcmlkZ2UgQXZlLg0K ICAgQ3VwZXJ0aW5vLCBDQSAgOTUwODkNCiAgIFVTQQ0KDQogICBQaG9uZTogMS00MDgtNDQ3LTAw MDAgICAgICANCiAgIEVtYWlsOiB2aXNod2FzLm1hbnJhbEBocC5jb20NCg0KDQogICBEb25hbGQg RWFzdGxha2UgM3JkDQogICBIdWF3ZWkgUiZEIFVTQQ0KICAgMTU1IEJlYXZlciBTdHJlZXQNCiAg IE1pbGZvcmQsIE1BICAwMTc1Nw0KICAgVVNBDQoNCiAgIFBob25lOiAxLTUwOC0zMzMtMjI3MCAg ICAgIA0KICAgRW1haWw6IGQzZTNlM0BnbWFpbC5jb20NCg0KDQogICBEYXZlIFdhcmQNCiAgIENp c2NvIFN5c3RlbXMNCiAgIDE3MCBXLiBUYXNtYW4gRHJpdmUNCiAgIFNhbiBKb3NlLCBDQSAgOTUx MzgNCiAgIFVTQQ0KDQogICBFbWFpbDogZHdhcmRAY2lzY28uY29tDQoNCg0KICAgQXlhbiBCYW5l cmplZQ0KICAgQ2lzY28gU3lzdGVtcw0KICAgMTcwIFcuIFRhc21hbiBEcml2ZQ0KICAgU2FuIEpv c2UsIENBICA5NTEzOA0KICAgVVNBDQoNCiAgIFBob25lOiAxLTQwOC01MjUtODc4MSAgICAgIA0K ICAgRW1haWw6IGF5YWJhbmVyQGNpc2NvLmNvbQ0KDQoNCg0KDQpNYW5yYWwsIGV0IGFsLiAgICAg ICAgICAgIEV4cGlyZXMgSnVseSAyNywgMjAxMiAgICAgICAgICAgICAgICAgW1BhZ2UgMTFd --f46d044473676d674504b9d3a0a1 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 --f46d044473676d674504b9d3a0a1-- From rbridge-bounces@postel.org Sun Feb 26 18:59:26 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 E052C21E800F for ; Sun, 26 Feb 2012 18:59:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.775 X-Spam-Level: X-Spam-Status: No, score=-99.775 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, MIME_HTML_MOSTLY=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, 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 VAvW3gfbcXGr for ; Sun, 26 Feb 2012 18:59:25 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 321E421F84A5 for ; Sun, 26 Feb 2012 18:59:25 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1R2YI9L027918; Sun, 26 Feb 2012 18:34:21 -0800 (PST) Received: from mx7.zte.com.cn (mx7.zte.com.cn [202.103.147.169]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1R2XXZI027586; Sun, 26 Feb 2012 18:33:43 -0800 (PST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 35739.3928560221; Mon, 27 Feb 2012 10:33:28 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q1R2XIxJ081017; Mon, 27 Feb 2012 10:33:19 +0800 (GMT-8) (envelope-from hu.fangwei@zte.com.cn) In-Reply-To: To: Radia Perlman 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, 27 Feb 2012 10:33:16 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-02-27 10:33:21, Serialize complete at 2012-02-27 10:33:21 X-MAIL: mse02.zte.com.cn q1R2XIxJ081017 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: hu.fangwei@zte.com.cn Cc: rbridge@postel.org, rbridge-bounces@postel.org, "Tissa Senevirathne \(tsenevir\)" Subject: Re: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.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: multipart/mixed; boundary="===============0463851584==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org This is a multipart message in MIME format. --===============0463851584== Content-Type: multipart/alternative; boundary="=_alternative 000E074D482579B1_=" This is a multipart message in MIME format. --=_alternative 000E074D482579B1_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIFJhZGlhLCBhbmQgZG8gbm90IHRoaW5rIHRoYXQgTXVsdGktdG9wb2xvZ3kg Y2FuIHNsb3ZlIHRoZSANCm5pY2tuYW1lIHNwYWNlIGlzc3VlLg0KDQpUaGVyZSBhcmUgdHdvIGNh c2VzIGZvciBNVCAoUkZDNTEyMCk6DQoNCigxKSBSQnJpZGdlIHdpdGggTm9uLW92ZXJsYXAgbmlj a25hbWUgYWRkcmVzcy4gVGhlIG5pY2tuYW1lIHJvdXRlcyBjYW4gYmUgDQppbnN0YWxsZWQgaW50 byBhIHNoYXJlZCBuaWNrbmFtZSBSSUIgdGFibGUuIEFuZCB0aGVyZSBpcyBubyBuZWVkIGZvciAN Cm1hcmtpbmcgdGhlIGRhdGEgd2l0aCBkaWZmZXJlbnQgVG9wb2xvZ3kuIFRoaXMgc2l0dWF0aW9u IGNhbiBub3QgaGVscCB0byANCm5pY2tuYW1lIGV4aGF1c3Rpb24gaXNzdWUuDQoNCigyKSBSQnJp ZGdlIHdpdGggb3ZlcmxhcCBuaWNrbmFtZSBhZGRyZXNzLiBUaGUgUkJyaWRnZSBjYW4gYmUgYXNz aWduZWQgdGhlIA0Kc2FtZSBuaWNrbmFtZSBmb3IgZGlmZmVyZW50IHRvcG9sb2d5LiBCdXQgd2Ug c2hvdWxkIGNvbnNpZGVyIHRvIG1hcmsgdGhlIA0KZGF0YSB3aXRoIGRpZmZlcmVudCB0b3Bsb2xv Z3kuIEJlc2lkZXMgdGhlIHN0ZWFsaW5nIGJpdHMgbWV0aG9kcywgd2UgaGF2ZSANCm5vIGdvb2Qg aWRlYXMgdG8gZG8gdGhhdC4gVGhlIHN0ZWFsaW5nIGJpdHMgbWV0aG9kcyBjYW4gbm90IHJldWRj ZSB0aGUgDQpuaWNrbmFtZSBleGhhdXN0aW5nIGlzc3VlIGFjdHVhbGx5LCBiZWNhdXNlIGl0IHJl dWRjZSB0aGUgdmFsaWQgbGVuZ2ggb2YgDQpuaWNrbmFtZS4gDQoNCg0KDQoNClJhZGlhIFBlcmxt YW4gPHJhZGlhcGVybG1hbkBnbWFpbC5jb20+IA0KMjAxMi0wMi0yNSAwMToyMw0KDQrK1bz+yMsN CiJUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKSIgPHRzZW5ldmlyQGNpc2NvLmNvbT4NCrOt y80NCmh1LmZhbmd3ZWlAenRlLmNvbS5jbiwgcmJyaWRnZUBwb3N0ZWwub3JnLCByYnJpZGdlLWJv dW5jZXNAcG9zdGVsLm9yZw0K1vfM4g0KUmU6IFtyYnJpZGdlXSBEZWZhdWx0IG5pY2tuYW1lIGJh c2UgYXBwcm9hY2ggZm9yIG11bHRpbGV2ZWwgVFJJTEwtIA0KZHJhZnQtdGlzc2EtdHJpbGwtbXVs dGlsZXZlbC0wMC50eHQNCg0KDQoNCg0KDQoNCkkgYXNzdW1lIHRoYXQgYWxsIFJCcmlkZ2VzIHdp bGwgbmVlZCB0byBiZSBpbiBhbGwgdG9wb2xvZ2llcywgc28gDQptdWx0aXRvcG9sb2d5IHdpbGwg bm90IGhlbHAgd2l0aCBuaWNrbmFtZSBleGhhdXN0aW9uLiAgUGx1cyB5b3UgaGF2ZW4ndCANCmV4 cGxhaW5lZCBob3cgYSBUUklMTCBwYWNrZXQgd291bGQgYmUgbWFya2VkIGFzIHRvIHdoaWNoIHRv cG9sb2d5IHRoZSANCnBhY2tldCBzaG91bGQgYmUgcm91dGVkIGFjY29yZGluZyB0byAob3RoZXIg dGhhbiB3aGF0IEkgbWVudGlvbmVkLCB3aGljaCANCmFjdHVhbGx5IGVhdHMgdXAgbmlja25hbWVz IGJ5IGEgZmFjdG9yIG9mIHRoZSBudW1iZXIgb2YgdG9wb2xvZ2llcyANCnN1cHBvcnRlZCkuDQog DQpQbHVzLCByYXRoZXIgdGhhbiBqdXN0IGx1bXBpbmcgcG90ZW50aWFsIGlzc3VlcyBpbnRvIGEg cGhyYXNlIHN1Y2ggYXMgDQoiTkFULWxpa2UiLCBiZSBleHBsaWNpdCBhYm91dCB3aGF0IGlzc3Vl cyB0aGVyZSBhY3R1YWxseSBhcmUuICBJIGJlbGlldmUgDQp0aGUgRnVsY3J1bSBjaGlwIHdvdWxk IGhhdmUgbm8gcHJvYmxlbSB3aXRoIHRyYW5zbGF0aW5nIHRoZSBuaWNrbmFtZSANCmZpZWxkcy4N CiANCkFuZCByYXRoZXIgdGhhbiBhc3N1bWluZyB0aGF0IG5pY2tuYW1lIGV4aGF1c3Rpb24gY2Fu IGJlIHNvbHZlZCAic29tZSANCm90aGVyIHdheSIsIHRoZXJlIHNob3VsZCBiZSBhIHBhbGF0YWJs ZSBzb2x1dGlvbiBiZWZvcmUgcmVqZWN0aW5nIGEgY2hhbmNlIA0KdG8gc29sdmUgaXQgd2l0aCBt dWx0aWxldmVsLg0KIA0KUmFkaWENCg0KMjAxMi8yLzI0IFRpc3NhIFNlbmV2aXJhdGhuZSAodHNl bmV2aXIpIDx0c2VuZXZpckBjaXNjby5jb20+DQpCZWNhdXNlIHlvdSBjYW4gaGF2ZSBzYW1lIG5p Y2tuYW1lIGZvciBkaWZmZXJlbnQgdG9wb2xvZ3kuIEl0IGlzIG5vdCBhIA0Kbmlja25hbWUgdGhh dCB3aWxsIGlkZW50aWZ5IGFuIFJCUmlkZ2UsIGl0IGlzIHRvcG9sb2d5LG5pY2tuYW1lIA0KY29t YmluYXRpb24gdGhhdCB3aWxsIGlkZW50aWZ5IGFuIFJCUmlkZ2UuIFNvIFJCMSBjYW4gaGF2ZSBu aWNrbmFtZSAxIGluIA0KdG9wby0xIGFuZCBSQjIgY2FuIGhhdmUgbmlja25hbWUgMSBpbiB0b3Bv Mi4gTm93IHRvdGFsIG5pY2tuYW1lcyBpbiB0aGUgDQpjYW1wdXMgaXMgMioqMTYgeCB0b3BvbG9n aWVzLg0KIA0KU3RlYWxpbmcgYml0cyB0byByZXByZXNlbnQgdG9wbyBpZCBpcyBvbmx5IGEgd29y a2Fyb3VuZCB0aGVyZSBjYW4gYmUgKGFyZSANCikgbW9yZSBlbGVnYW50IHdheXMgb2YgZG9pbmcg aXQgdGhhdC4NCiANCkJvdHRvbSBsaW5lIGlzIHdlIG5lZWQgdG8gbG9vayBmb3IgbW9yZSBjcmVh dGl2ZSBtZXRob2RzIG9mIHNvbHZpbmcgDQpuaWNrbmFtZSBzcGFjZSBpc3N1ZSB0aGFuIGRvaW5n IE5BVCBsaWtlIGJlaGF2aW9yLiANCiANCkZyb206IFJhZGlhIFBlcmxtYW4gW21haWx0bzpyYWRp YXBlcmxtYW5AZ21haWwuY29tXSANClNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMjQsIDIwMTIgOTow NSBBTQ0KVG86IFRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpDQpDYzogaHUuZmFuZ3dlaUB6 dGUuY29tLmNuOyByYnJpZGdlQHBvc3RlbC5vcmc7IHJicmlkZ2UtYm91bmNlc0Bwb3N0ZWwub3Jn IA0KDQpTdWJqZWN0OiBSZTogW3JicmlkZ2VdIERlZmF1bHQgbmlja25hbWUgYmFzZSBhcHByb2Fj aCBmb3IgbXVsdGlsZXZlbCANClRSSUxMLSBkcmFmdC10aXNzYS10cmlsbC1tdWx0aWxldmVsLTAw LnR4dA0KIA0KSSBkb24ndCB1bmRlcnN0YW5kIGhvdyBtdWx0aS10b3BvbG9neSBoZWxwcyB3aXRo IHRoZSBuaWNrbmFtZSBleGhhdXN0aW9uIA0KaXNzdWUuICBBcyBhIG1hdHRlciBvZiBmYWN0LCB0 aGUgb25seSBwbGF1c2libGUgd2F5IG9mIG1hcmtpbmcgYSBwYWNrZXQgDQpmb3Igd2hpY2ggdG9w b2xvZ3kgdGhhdCBoYXMgYmVlbiBzdWdnZXN0ZWQgb24gdGhlIG1haWxpbmcgbGlzdCAoSSBhc2tl ZCBhIA0KZWZ3IHRpbWVzIGlmIHRoZXJlIHdlcmUgYW55IG90aGVyIHBvc3NpYmlsaXRpZXMpLCB3 YXMgdG8gc3RlYWwgMiBvciAzIGJpdHMgDQpvZiB0aGUgbmlja25hbWUgdG8gZW5jb2RlIHdoaWNo IHRvcG9sb2d5LCBpbiBlZmZlY3QsIG1ha2luZyBhIGRlc3RpbmF0aW9uIA0KYXBwZWFyIGFzIG11 bHRpcGxlIGRlc3RpbmF0aW9ucyBhbmQgbXVsdGlwbGUgZm9yd2FyZGluZyB0YWJsZSBlbnRyaWVz IA0KKHdoaWNoIHlvdSdkIHdhbnQgYW55d2F5LCBmb3IgbXVsdGl0b3BvbG9neSkuDQogDQogDQpS YWRpYQ0KMjAxMi8yLzI0IFRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpIDx0c2VuZXZpckBj aXNjby5jb20+DQpNdXRsaS10b3BvbG9neSBpcyB0aGUgYW5zd2VyIHRvIGluY3JlYXNlIHRoZSBu aWNrbmFtZSBzcGFjZS4NCiANCk5pY2tuYW1lIHRyYW5zbGF0aW9uIGlzIHZlcnkgc2ltaWxhciB0 byBOQVQsIHdoaWNoIGhhcyBpdKGvcyBvd24gZG93biANCnNpZGUsIG5vdCB0byBtZW50aW9uIHNw ZWNpYWwgaGFyZHdhcmUgZXRjLiB0byBkbyB0aGUgdHJhbnNsYXRpb25zLCANCmFkZGl0aW9uYWxs eS4gV2UgYWxzbyBrbm93IGZyb20gb3VyIGV4cGVyaWVuY2UsIGluIElQIHdvcmxkIE5BVGluZyBp cyBub3QgDQp0aGUgbW9zdCBkZXNpcmVkIGJlaGF2aW9yIGFuZCB3ZSBsaXZlIHdpdGggaXQuIFNv IHdlIHNob3VsZCBub3QgYmUgZ29pbmcgDQpkb3duIHRoYXQgcGF0aCBpbnN0ZWFkIG5lZWQgdG8g bG9vayBmb3J3YXJkIGZyb20gdGhhdCBleHBlcmllbmNlLg0KIA0KTXVsdGktdG9wb2xvZ3kgbm90 IG9ubHkgYWRkcmVzcyBuaWNrbmFtZSBzcGFjZSBpc3N1ZSBidXQgYWxzbyBlbmFibGVzIA0KdmFy aW91cyBvdGhlciBhcHBsaWNhdGlvbnMgc3VjaCBhcyBvdmVybGF5IHRvcG9sb2dpZXMsIHRyYWZm aWMgDQplbmdpbmVlcmluZy4NCiANClRoZSBkcmFmdC10aXNzLXRyaWxsLW11bHRpbGV2ZWwgcHJl c2VudCBhcHByb2FjaGVzIHRoYXQgYXJlIGdlbmVyaWMsIHdoaWNoIA0KbWVhbiBpdCBjYW4gYmUg YXBwbGllZCBmb3IgbXVsdGktdG9wb2xvZ3ksIG9yIGJhc2UgdG9wb2xvZ3kuIEl0IHV0aWxpemVz IA0KdGhlIGZ1bmRhbWVudGFscyBvZiBJUy1JUyAsIHN1Y2ggYXMgQXJlYSBoaWVyYXJjaHkgZm9y IHJlZHVjdGlvbiBvZiB0aGUgDQpMU1AtREIuIEl0IHV0aWxpemUgYWZmaW5pdHkgVExWIGNvbmNl cHRzIHRvIGVmZmVjdGl2ZWx5IHNvbHZlIA0KbXVsdGktZGVzdGluYXRpb24gaXNzdWVzLiANCiAN CldlIHNob3VsZCBub3QgbWl4LXVwIGJldHdlZW4gRGF0YSBjZW50ZXIgaW50ZXJjb25uZWN0cyB3 aXRoIGRhdGEgY2VudGVyIA0Kbm9kZSBzY2FsaW5nLiBUaGV5IGFyZSB0d28gZGlmZmVyZW50IGFu ZCBvcnRob2dvbmFsIGlzc3Vlcy4NCiANCk9iamVjdGl2ZSBvZiBtdWx0aS1sZXZlbCB0cmlsbCBp cyB0byBpbnRlcmNvbm5lY3QgZGlmZmVyZW50IGRhdGFjZW50ZXJzLCANCmFuZCBtYWludGFpbiBM U1AtREIgc21hbGwgYXMgcG9zc2libGUgdG8gYXZvaWQgc2NhbGluZyBhbmQgdm9sYXRpbGl0eS4N CiANCkluY3JlYXNpbmcgbmlja25hbWUgc3BhY2UgYSBkaWZmZXJlbnQgcmVxdWlyZW1lbnQgYW5k IGhhcyBub3RoaW5nIHRvIGRvIA0Kd2l0aCBkYXRhLWNlbnRlciBpbnRlcmNvbm5lY3RzLg0KIA0K IA0KRnJvbTogUmFkaWEgUGVybG1hbiBbbWFpbHRvOnJhZGlhcGVybG1hbkBnbWFpbC5jb21dIA0K U2VudDogRnJpZGF5LCBGZWJydWFyeSAyNCwgMjAxMiA2OjE1IEFNDQpUbzogaHUuZmFuZ3dlaUB6 dGUuY29tLmNuDQpDYzogVGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZpcik7IHJicmlkZ2VAcG9z dGVsLm9yZzsgDQpyYnJpZGdlLWJvdW5jZXNAcG9zdGVsLm9yZw0KU3ViamVjdDogUmU6IFtyYnJp ZGdlXSBEZWZhdWx0IG5pY2tuYW1lIGJhc2UgYXBwcm9hY2ggZm9yIG11bHRpbGV2ZWwgDQpUUklM TC0gZHJhZnQtdGlzc2EtdHJpbGwtbXVsdGlsZXZlbC0wMC50eHQNCiANClBlb3BsZSBoYXZlIG1l bnRpb25lZCB0byBtZSB0aGF0IHRoZXkgYXJlIG5lcnZvdXMgYWJvdXQgcnVubmluZyBvdXQgb2Yg DQpuaWNrbmFtZXMsIGVzcGVjaWFsbHkgc2luY2UgdGhlcmUgYXJlIHJlYXNvbnNvbiB3aHkgdGhl eSBtaWdodCB3YW50IHRvIA0KYXNzaWduIG5pY2tuYW1lcyB0byBoeXBlcnZpc29ycy4gIFdpdGgg dGhlIGFsdGVybmF0ZSBhcHByb2FjaCBvZiBhbGxvd2luZyANCm5pY2tuYW1lcyB0byBiZSByZXVz ZWQgaW4gZGlmZmVyZW50IGFyZWFzLCBpdCBtYWtlcyBhdXRvbWF0aWMgbmlja25hbWUgDQphc3Np Z25tZW50IG11Y2ggc2ltcGxlciBhbmQgbWFrZXMgVFJJTEwgYSBsb3QgbW9yZSBzY2FsYWJsZS4N CiANCkl0IGRvZXMgaGF2ZSB0aGUgZG93bnNpZGUgb2YgcmVxdWlyaW5nIG1hcHBpbmcgb2Ygbmlj a25hbWVzIGF0IHRoZSBib3JkZXIgDQpSQnJpZGdlcy4NCiANCkFuZCBieSB0aGUgd2F5LCB0aGUg YWZmaW5pdHkgVExWIGNhbiBiZSB1c2VkIGZvciBtdWx0aWRlc3RpbmF0aW9uIGZyYW1lcyANCnRy YW5zaXRpbmcgYmV0d2VlbiBsZXZlbCAxIGFuZCBsZXZlbCAyLg0KIA0KUmFkaWENCjIwMTIvMi8y MyA8aHUuZmFuZ3dlaUB6dGUuY29tLmNuPg0KDQpIaSwgVGlzc2EuIA0KDQpJIGhhdmUgc2V2ZXJh bCBjb21tZW50cyBhYm91dCB0aGUgZHJhZnQuIA0KDQooMSkgaW4gc2VjdGlvbiA0LjQgKE11bHRp Y2FzdCksICJUaGUgc2NvcGUgb2YgZ2xvYmFsIHRyYWZmaWMgbWF5IGJlIA0KaWRlbnRpZmllZCBl aXRoZXIgdGhyb3VnaCBWTEFOIG9yIHZpYSBmaW5lZ3JhaW4gDQpsYWJlbCB0aGF0IHNwYW5zIGFj cm9zcyB0aGUgZW50aXJlIFRSSUxMIGNhbXB1cy4iIA0KVmxhbiBhbmQgRmluZS1ncmFpbiBMYWJl bCBpcyB1c2VkIGZvciBzZXJ2aWNlIGRpZmZlcmVudGlhdGlvbiBhbmQgDQppc29sYXRpb24uIEkg ZG8gbm90IHF1aXRlIHVuZGVyc3RhbmQgdGhhdCBob3cgdG8gDQp1c2UgVkxBTiBhbmQgZmluZS1n cmFpbiBMYWJsZSB0byBpZGVudGlmeSB0aGUgdHJhZmZpYyBzY29wZS4gVGhlIGRhdGEgDQp0cmFm ZmljIHdpdGggYSBnaXZlbiBWTEFOLXgsIGNhbiANCmJlIGZvcndhcmRlZCB0byBvdGhlciBlbmQg c3RhdGlvbiBpbiB0aGUgbG9jYWwgYXJlYSwgb3IgdG8gdGhlIGVuZCBzdGF0aW9uIA0KaW4gcmVt b3RlIGFyZWFzLiANCg0KKDIpIG5pY2tuYW1lIGFsbG9jYXRpb24gDQpUaGUgbmlja25hbWUgbWFu YWdlbWVudCBzdWItVExWIGlzIHByb3Bvc2VkIGluIHRoZSBkb2N1bWVudC4gSSB3b25kZXIgdGhp cyANCm1lY2hhbmlzbSBhZGRzIHRoZSBjb21wbGljYXRpb24gb2YgICANCm5pY2tuYW1lIGFsbG9j YXRpb24uIEFzIHRoZSBzZWN0aW9uIDEgKGludHJvZHVjdGlvbikgb2YgUkZDNjMyNSwgb25lIG9m IA0KdGhlIGltcG9ydGFudCBhZHZhbnRhZ2Ugb2YgVFJJTEwgaXMgdGhhdCAgIA0KaXQgYXZvaWRz IHRoZSBjcmVhdGluZyBzdWJuZXRzIG9mIElQIGFkZHJlc3MgYW5kIHdhc3RpbmcgYWRkcmVzcy4g VGhlIA0Kbmlja25hbWUgYWNxdWlzaXRpb24gIG1ldGhvZCBpbiB0aGlzIGRyYWZ0IHZpb2xhdGVz IHRoZSAgIA0KaWRlYSBvZiBUUklMTCBCYXNpYyBzcGVjaWZpY2F0aW9uLCBhbmQgcmVkdWNlcyB0 aGUgZmxleGliaWxpdHkgb2Ygbmlja25hbWUgDQphbGxvY2F0aW9uLiBBcyB0aGUgZHJhZnQgYXNz dW1lZCwgQTEgaGFkICAgDQpuaWNrbmFtZSByYW5nZSBvZiAxMDAtMjAwLCBBMiBoYXMgYSBsb2Nh bCBuaWNrbmFtZSByYW5nZSBvZiAyMDEtMzAwLiBJZiANCnRoZSBudW1iZXJzIG9mIEExIGFyZWEg aXMgb25seSA1MCwgc28gNTAgICANCm5pY2tuYW1lcyBpbiBBMSBpcyB3YXN0ZWQuIEFzIHRoZSBu ZXR3b3JrIGdyb3dpbmcsIHRoZSBudW1iZXIgb2Ygc29tZSANCmFyZWFzIG1heSBleGNlZWQgdGhl IG51bWJlciBiZWluZyBhbGxvY2F0aW9uICAgDQpieSBCb3JkZXIgUkJyaWRnZXMuIFRoZSBkZXNp Z24gYW5kIG1haW50YWluaW5nIG9mIG5pY2tuYW1lIHJhbmdlcyBmb3IgZWFjaCANCmFyZWEgaXMg YSB2ZXJ5IGhhcmQgd29yay4gRXZlbiB3b3JzdCwgaXQgICANCmNhbiBub3QgYXZvaWQgdG8gd2Fz dGUgbmlja25hbWUgc3BhY2UuIA0KDQooMykgRHluYW1pYyByYW5nZXMgDQogVGhlIG5pY2tuYW1l IHJhbmdlIGlzIGRpdmlkZWQgaW50byB0d28gcmFuZ2U6IGxvY2FsIHJhbmdlIGFuZCBkeW5hbWlj YWwgDQpyYW5nZS4gSSB3b25kZXIgdGhlIG5pY2tuYW1lIGNvbmZsaWN0ICAgDQpyZXNvbHV0aW9u IGNhbiBub3Qgd29yayBpZiB0aGUgUkJyaWRnZSBnZXQgdGhlIG5pY2tuYW1lIGZyb20gdGhlIGR5 bmFtaWNhbCANCnJhbmdlIHdoaWxlIHRoZSB0d28gUkJyaWRnZSBiZWxvbmdzIHRvICAgDQpkaWZm ZXJlbnQgYXJlYXMuIEZvciBleGFtcGxlLCBSQjEgaXMgaW4gYXJlYSBBMSwgYW5kIFJCMiBpcyBp biBhcmVhIEEyLiBJZiANClJCMSBnZXRzIHRoZSBuaWNrbmFtZSBOMSBmcm9tIGR5bmFtaWMgICAN CnJhbmdlLCBhbmQgaXQgd2lsbCBmbG9vZHMgaW4gYXJlYSBBMSwgYW5kIG90aGVyIFJCcmlkZ2Vz IGluIGFyZWEgQTEgY2FuIA0Kbm90IGdldCBuaWNrbmFtZSBOMSBiZWNhdXNlIG9mIG5pY2tuYW1l ICAgDQpjb25mbGljdGlvbiBtZWNoYW5pc20sIGJ1dCBSQjIgaW4gYXJlYSBBMiBjYW4gbm90IHJl Y2VpdmUgdGhlIFBEVSBmcm9tIA0KUkIxLCBhbmQgaXQgIGNhbiBhbHNvIGdldCB0aGUgbmlja25h bWUgTjEgZnJvbSAgIA0KZHluYW1pY2FsIHJhbmdlLiBTbyB0aGUgcXVlc3Rpb24gaXMgaG93IHRv IGF2b2lkIHRoZSBkdXBsaWNhdGlvbiBkeW5hbWljYWwgDQpyYW5nZSBuaWNrbmFtZSBmb3IgZGlm ZmVyZW50IGFyZWFzLiANCg0KKDQpIFRoZSByaXNrIG9mIHJ1bm5pbmcgb3V0IG9mIG5pY2tuYW1l IG1heWJlIGEgaXNzdWUgZm9yIFRSSUxMLiBUaGUgDQpudW1iZXIgb2YgMioqMTYgbmlja25hbWUg aXMgZW5vdWdoIGZvciB0aGUgY3VycmVudCBkYXRhIGNlbnRlciwgDQogYnV0IGl0IG1heWJlIG5v dCBlbm91Z2ggaW4gdGhlIGZ1dHVyZSwgZXNwZWNhaWxseSBpZiBUUklMTCBvdmVyIElQICwgDQpU UklMTCBvdmVyIE1QTFMgdGVjaG5vbG9neSBvciBzb21lIG90aGVyIGRhdGEgY2VudGVyIHRlY2hu b2xvZ2llcyANCiBhcmUgZGVwbG95ZWQsIHRoZSBkYXRhIGNlbnRlciBuZXR3b3JrIGNhbiBiZSBh IHZlcnkgbGFyZGdlIG5ldHdvcmsuIFNvIGkgDQp0aGluayB0aGUgdmVyeSBpbXBvcnRhbnQgYW5k IGVzc2VudGlhbCBnb2FsIG9mIG11bHRpLWxldmVsIGRyYWZ0IGlzIHRvIA0Kc2F2ZSBuaWNrbmFt ZXMuIA0KDQpCZXN0IHJlZ2FyZHMgDQpGYW5nd2VpIEh1DQoNCg0KIlRpc3NhIFNlbmV2aXJhdGhu ZSAodHNlbmV2aXIpIiA8dHNlbmV2aXJAY2lzY28uY29tPiANCreivP7IyzogIHJicmlkZ2UtYm91 bmNlc0Bwb3N0ZWwub3JnIA0KMjAxMi0wMi0yMyAxMTo1NSANCg0KDQrK1bz+yMsNCjxyYnJpZGdl QHBvc3RlbC5vcmc+IA0Ks63LzQ0KDQrW98ziDQpbcmJyaWRnZV0gRGVmYXVsdCBuaWNrbmFtZSBi YXNlIGFwcHJvYWNoIGZvciBtdWx0aWxldmVsIFRSSUxMLSANCmRyYWZ0LXRpc3NhLXRyaWxsLW11 bHRpbGV2ZWwtMDAudHh0DQogDQoNCg0KDQoNCg0KDQoNCg0KDQpEZWFyIEFsbA0KDQpXZSBoYXZl IHN1Ym1pdHRlZCBkcmFmdC10aXNzYS10cmlsbC1tdWx0aWxldmVsLCBwcmVzZW50IG11bHRpbGV2 ZWwgVFJJTEwgDQpiYXNlZCBvbiBkZWZhdWx0IG5pY2tuYW1lIGFwcHJvYWNoLiBBZGRpdGlvbmFs bHkgd2UgZGlzY3VzcyBjb25zdHJ1Y3Rpb24gDQpvZiBtdWx0aS1kZXN0aW5hdGlvbiB0cmVlcyBh bmQgcmVsYXRlZCBSUEYgaW4gbXVsdGlsZXZlbCBUUklMTC4gUGxlYXNlIA0KY291bGQgeW91IHJl dmlldyBhbmQgY29tbWVudCANCg0KRGV0YWlsIG9mIHRoZSBkcmFmdCBhbmQgYWJzdHJhY3QgYXJl IGJlbG93Lg0KDQpGaWxlbmFtZTogICAgICAgICAgICAgICAgICBkcmFmdC10aXNzYS10cmlsbC1t dWx0aWxldmVsDQpSZXZpc2lvbjogICAgICAgICAgICAgICAgICAwMA0KVGl0bGU6ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBEZWZhdWx0IE5pY2tuYW1lIEJhc2VkIEFwcHJvYWNo IA0KZm9yIE11bHRpbGV2ZWwgVFJJTEwNCkNyZWF0aW9uIGRhdGU6ICAgICAgICAgICAgICAgICAg MjAxMi0wMi0yMQ0KV0cgSUQ6ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJbmRp dmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogMjYNCg0KQWJzdHJhY3Q6DQogIE11 bHRpbGV2ZWwgVFJJTEwgYWxsb3dzIHRoZSBpbnRlcmNvbm5lY3Rpb24gb2YgbXVsdGlwbGUgVFJJ TEwNCiAgbmV0d29ya3MgdG8gZm9ybSBhIGxhcmdlciBUUklMTCBuZXR3b3JrIHdpdGhvdXQgcHJv cG9ydGlvbmFsbHkNCiAgaW5jcmVhc2luZyB0aGUgc2l6ZSBvZiB0aGUgSVMtSVMgTFNQIERCLiBJ biB0aGlzIGRvY3VtZW50LCBhbg0KICBhcHByb2FjaCBiYXNlZCBvbiBkZWZhdWx0IHJvdXRlIGNv bmNlcHQgaXMgcHJlc2VudGVkLiBBbHNvLA0KICBwcmVzZW50ZWQgaW4gdGhlIGRvY3VtZW50IGlz IGEgbm92ZWwgbWV0aG9kIG9mIGNvbnN0cnVjdGluZyBtdWx0aS0NCiAgZGVzdGluYXRpb24gdHJl ZXMgdXNpbmcgcGFydGlhbCBuaWNrbmFtZSBzcGFjZS4gTWV0aG9kcyBwcmVzZW50ZWQgaW4NCiAg dGhpcyBkb2N1bWVudCBhcmUgY29tcGF0aWJsZSB3aXRoIHRoZSBSRkM2MzI1IHNwZWNpZmllZCBk YXRhIHBsYW5lDQogIG9wZXJhdGlvbnMuDQoNCiAgDQpUaGFua3MNClRpc3NhDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpyYnJpZGdlIG1haWxpbmcg bGlzdA0KcmJyaWRnZUBwb3N0ZWwub3JnDQpodHRwOi8vbWFpbG1hbi5wb3N0ZWwub3JnL21haWxt YW4vbGlzdGluZm8vcmJyaWRnZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KcmJyaWRnZSBtYWlsaW5nIGxpc3QNCnJicmlkZ2VAcG9zdGVsLm9yZw0K aHR0cDovL21haWxtYW4ucG9zdGVsLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JicmlkZ2UNCiANCiAN Cg0KDQo= --=_alternative 000E074D482579B1_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgYWdyZWUgd2l0aCBSYWRpYSwg YW5kIGRvIG5vdCB0aGluaw0KdGhhdCBNdWx0aS10b3BvbG9neSBjYW4gc2xvdmUgdGhlIG5pY2tu YW1lIHNwYWNlIGlzc3VlLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+VGhlcmUgYXJlIHR3byBjYXNlcyBmb3IgTVQgKFJGQzUxMjApOjwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+KDEpIFJCcmlkZ2Ugd2l0aCBO b24tb3ZlcmxhcCBuaWNrbmFtZQ0KYWRkcmVzcy4gVGhlIG5pY2tuYW1lIHJvdXRlcyBjYW4gYmUg aW5zdGFsbGVkIGludG8gYSBzaGFyZWQgbmlja25hbWUgUklCDQp0YWJsZS4gQW5kIHRoZXJlIGlz IG5vIG5lZWQgZm9yIG1hcmtpbmcgdGhlIGRhdGEgd2l0aCBkaWZmZXJlbnQgVG9wb2xvZ3kuDQpU aGlzIHNpdHVhdGlvbiBjYW4gbm90IGhlbHAgdG8gbmlja25hbWUgZXhoYXVzdGlvbiBpc3N1ZS48 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPigyKSBSQnJp ZGdlIHdpdGggb3ZlcmxhcCBuaWNrbmFtZSBhZGRyZXNzLg0KVGhlIFJCcmlkZ2UgY2FuIGJlIGFz c2lnbmVkIHRoZSBzYW1lIG5pY2tuYW1lIGZvciBkaWZmZXJlbnQgdG9wb2xvZ3kuIEJ1dA0Kd2Ug c2hvdWxkIGNvbnNpZGVyIHRvIG1hcmsgdGhlIGRhdGEgd2l0aCBkaWZmZXJlbnQgdG9wbG9sb2d5 LiBCZXNpZGVzIHRoZQ0Kc3RlYWxpbmcgYml0cyBtZXRob2RzLCB3ZSBoYXZlIG5vIGdvb2QgaWRl YXMgdG8gZG8gdGhhdC4gVGhlIHN0ZWFsaW5nIGJpdHMNCm1ldGhvZHMgY2FuIG5vdCByZXVkY2Ug dGhlIG5pY2tuYW1lIGV4aGF1c3RpbmcgaXNzdWUgYWN0dWFsbHksIGJlY2F1c2UNCml0IHJldWRj ZSB0aGUgdmFsaWQgbGVuZ2ggb2Ygbmlja25hbWUuIDwvZm9udD4NCjxicj4NCjxicj4NCjxicj4N Cjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzUl Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5SYWRpYSBQZXJsbWFuICZsdDtyYWRp YXBlcmxtYW5AZ21haWwuY29tJmd0OzwvYj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj4yMDEyLTAyLTI1IDAxOjIzPC9mb250Pg0KPHRkIHdpZHRoPTY0JT4NCjx0 YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0 Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O1Rpc3NhIFNlbmV2aXJhdGhuZSAo dHNlbmV2aXIpJnF1b3Q7DQombHQ7dHNlbmV2aXJAY2lzY28uY29tJmd0OzwvZm9udD4NCjx0ciB2 YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+aHUuZmFuZ3dlaUB6dGUuY29tLmNuLCByYnJpZGdlQHBvc3RlbC5vcmcsDQpyYnJpZGdl LWJvdW5jZXNAcG9zdGVsLm9yZzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBh bGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rp dj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtyYnJpZGdlXSBEZWZh dWx0IG5pY2tuYW1lIGJhc2UNCmFwcHJvYWNoIGZvciBtdWx0aWxldmVsIFRSSUxMLSBkcmFmdC10 aXNzYS10cmlsbC1tdWx0aWxldmVsLTAwLnR4dDwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxl Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJy Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5JIGFzc3VtZSB0aGF0 IGFsbCBSQnJpZGdlcyB3aWxsIG5lZWQNCnRvIGJlIGluIGFsbCB0b3BvbG9naWVzLCBzbyBtdWx0 aXRvcG9sb2d5IHdpbGwgbm90IGhlbHAgd2l0aCBuaWNrbmFtZSBleGhhdXN0aW9uLg0KJm5ic3A7 UGx1cyB5b3UgaGF2ZW4ndCBleHBsYWluZWQgaG93IGEgVFJJTEwgcGFja2V0IHdvdWxkIGJlIG1h cmtlZCBhcw0KdG8gd2hpY2ggdG9wb2xvZ3kgdGhlIHBhY2tldCBzaG91bGQgYmUgcm91dGVkIGFj Y29yZGluZyB0byAob3RoZXIgdGhhbg0Kd2hhdCBJIG1lbnRpb25lZCwgd2hpY2ggYWN0dWFsbHkg ZWF0cyB1cCBuaWNrbmFtZXMgYnkgYSBmYWN0b3Igb2YgdGhlIG51bWJlcg0Kb2YgdG9wb2xvZ2ll cyBzdXBwb3J0ZWQpLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5QbHVzLCBy YXRoZXIgdGhhbiBqdXN0IGx1bXBpbmcgcG90ZW50aWFsDQppc3N1ZXMgaW50byBhIHBocmFzZSBz dWNoIGFzICZxdW90O05BVC1saWtlJnF1b3Q7LCBiZSBleHBsaWNpdCBhYm91dCB3aGF0DQppc3N1 ZXMgdGhlcmUgYWN0dWFsbHkgYXJlLiAmbmJzcDtJIGJlbGlldmUgdGhlIEZ1bGNydW0gY2hpcCB3 b3VsZCBoYXZlDQpubyBwcm9ibGVtIHdpdGggdHJhbnNsYXRpbmcgdGhlIG5pY2tuYW1lIGZpZWxk cy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9u dD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+QW5kIHJhdGhlciB0aGFuIGFz c3VtaW5nIHRoYXQgbmlja25hbWUNCmV4aGF1c3Rpb24gY2FuIGJlIHNvbHZlZCAmcXVvdDtzb21l IG90aGVyIHdheSZxdW90OywgdGhlcmUgc2hvdWxkIGJlIGENCnBhbGF0YWJsZSBzb2x1dGlvbiBi ZWZvcmUgcmVqZWN0aW5nIGEgY2hhbmNlIHRvIHNvbHZlIGl0IHdpdGggbXVsdGlsZXZlbC48L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD4NCjxi cj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+UmFkaWE8YnI+DQo8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjIwMTIvMi8yNCBUaXNzYSBTZW5ldmlyYXRo bmUgKHRzZW5ldmlyKQ0KJmx0OzwvZm9udD48YSBocmVmPW1haWx0bzp0c2VuZXZpckBjaXNjby5j b20+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+dHNlbmV2aXJA Y2lzY28uY29tPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZn dDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+ QmVjYXVzZSB5b3UgY2FuIGhhdmUgc2FtZQ0Kbmlja25hbWUgZm9yIGRpZmZlcmVudCB0b3BvbG9n eS4gSXQgaXMgbm90IGEgbmlja25hbWUgdGhhdCB3aWxsIGlkZW50aWZ5DQphbiBSQlJpZGdlLCBp dCBpcyB0b3BvbG9neSxuaWNrbmFtZSBjb21iaW5hdGlvbiB0aGF0IHdpbGwgaWRlbnRpZnkgYW4g UkJSaWRnZS4NClNvIFJCMSBjYW4gaGF2ZSBuaWNrbmFtZSAxIGluIHRvcG8tMSBhbmQgUkIyIGNh biBoYXZlIG5pY2tuYW1lIDEgaW4gdG9wbzIuDQpOb3cgdG90YWwgbmlja25hbWVzIGluIHRoZSBj YW1wdXMgaXMgMioqMTYgeCB0b3BvbG9naWVzLjwvZm9udD4NCjxwPjxmb250IHNpemU9MiBjb2xv cj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxwPjxmb250IHNpemU9MiBj b2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPlN0ZWFsaW5nIGJpdHMgdG8gcmVwcmVzZW50DQp0 b3BvIGlkIGlzIG9ubHkgYSB3b3JrYXJvdW5kIHRoZXJlIGNhbiBiZSAoYXJlICkgbW9yZSBlbGVn YW50IHdheXMgb2YgZG9pbmcNCml0IHRoYXQuPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0yIGNvbG9y PSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0yIGNv bG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+Qm90dG9tIGxpbmUgaXMgd2UgbmVlZCB0bw0KbG9v ayBmb3IgbW9yZSBjcmVhdGl2ZSBtZXRob2RzIG9mIHNvbHZpbmcgbmlja25hbWUgc3BhY2UgaXNz dWUgdGhhbiBkb2luZw0KTkFUIGxpa2UgYmVoYXZpb3IuIDwvZm9udD4NCjxwPjxmb250IHNpemU9 MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxwPjxmb250IHNp emU9MiBmYWNlPSJUYWhvbWEiPjxiPkZyb206PC9iPiBSYWRpYSBQZXJsbWFuIFttYWlsdG86PC9m b250PjxhIGhyZWY9bWFpbHRvOnJhZGlhcGVybG1hbkBnbWFpbC5jb20gdGFyZ2V0PV9ibGFuaz48 Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1PnJhZGlhcGVybG1hbkBnbWFp bC5jb208L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj5dDQo8Yj48YnI+ DQpTZW50OjwvYj4gRnJpZGF5LCBGZWJydWFyeSAyNCwgMjAxMiA5OjA1IEFNPGI+PGJyPg0KVG86 PC9iPiBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKTxiPjxicj4NCkNjOjwvYj4gPC9mb250 PjxhIGhyZWY9bWFpbHRvOmh1LmZhbmd3ZWlAenRlLmNvbS5jbiB0YXJnZXQ9X2JsYW5rPjxmb250 IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+aHUuZmFuZ3dlaUB6dGUuY29tLmNu PC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+Ow0KPC9mb250PjxhIGhy ZWY9bWFpbHRvOnJicmlkZ2VAcG9zdGVsLm9yZyB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MiBj b2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+cmJyaWRnZUBwb3N0ZWwub3JnPC91PjwvZm9udD48 L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+Ow0KPC9mb250PjxhIGhyZWY9Im1haWx0bzpy YnJpZGdlLWJvdW5jZXNAcG9zdGVsLm9yZyIgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTIgY29s b3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1PnJicmlkZ2UtYm91bmNlc0Bwb3N0ZWwub3JnPC91Pjwv Zm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGI+PGJyPg0KU3ViamVjdDo8L2I+IFJlOiBbcmJyaWRnZV0g RGVmYXVsdCBuaWNrbmFtZSBiYXNlIGFwcHJvYWNoIGZvciBtdWx0aWxldmVsDQpUUklMTC0gZHJh ZnQtdGlzc2EtdHJpbGwtbXVsdGlsZXZlbC0wMC50eHQ8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPkkgZG9uJ3QgdW5kZXJzdGFuZCBob3cgbXVsdGktdG9wb2xvZ3kNCmhlbHBzIHdp dGggdGhlIG5pY2tuYW1lIGV4aGF1c3Rpb24gaXNzdWUuICZuYnNwO0FzIGEgbWF0dGVyIG9mIGZh Y3QsIHRoZQ0Kb25seSBwbGF1c2libGUgd2F5IG9mIG1hcmtpbmcgYSBwYWNrZXQgZm9yIHdoaWNo IHRvcG9sb2d5IHRoYXQgaGFzIGJlZW4NCnN1Z2dlc3RlZCBvbiB0aGUgbWFpbGluZyBsaXN0IChJ IGFza2VkIGEgZWZ3IHRpbWVzIGlmIHRoZXJlIHdlcmUgYW55IG90aGVyDQpwb3NzaWJpbGl0aWVz KSwgd2FzIHRvIHN0ZWFsIDIgb3IgMyBiaXRzIG9mIHRoZSBuaWNrbmFtZSB0byBlbmNvZGUgd2hp Y2gNCnRvcG9sb2d5LCBpbiBlZmZlY3QsIG1ha2luZyBhIGRlc3RpbmF0aW9uIGFwcGVhciBhcyBt dWx0aXBsZSBkZXN0aW5hdGlvbnMNCmFuZCBtdWx0aXBsZSBmb3J3YXJkaW5nIHRhYmxlIGVudHJp ZXMgKHdoaWNoIHlvdSdkIHdhbnQgYW55d2F5LCBmb3IgbXVsdGl0b3BvbG9neSkuPC9mb250Pg0K PHA+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD4NCjxwPjxmb250 IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+UmFkaWE8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTMgZmFjZT0ic2Fu cy1zZXJpZiI+MjAxMi8yLzI0IFRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpDQombHQ7PC9m b250PjxhIGhyZWY9bWFpbHRvOnRzZW5ldmlyQGNpc2NvLmNvbSB0YXJnZXQ9X2JsYW5rPjxmb250 IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1PnRzZW5ldmlyQGNpc2NvLmNv bTwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7PC9mb250 Pg0KPHA+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+TXV0bGktdG9w b2xvZ3kgaXMgdGhlIGFuc3dlcg0KdG8gaW5jcmVhc2UgdGhlIG5pY2tuYW1lIHNwYWNlLjwvZm9u dD4NCjxwPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwv Zm9udD4NCjxwPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPk5pY2tu YW1lIHRyYW5zbGF0aW9uIGlzIHZlcnkNCnNpbWlsYXIgdG8gTkFULCB3aGljaCBoYXMgaXShr3Mg b3duIGRvd24gc2lkZSwgbm90IHRvIG1lbnRpb24gc3BlY2lhbA0KaGFyZHdhcmUgZXRjLiB0byBk byB0aGUgdHJhbnNsYXRpb25zLCBhZGRpdGlvbmFsbHkuIFdlIGFsc28ga25vdyBmcm9tIG91cg0K ZXhwZXJpZW5jZSwgaW4gSVAgd29ybGQgTkFUaW5nIGlzIG5vdCB0aGUgbW9zdCBkZXNpcmVkIGJl aGF2aW9yIGFuZCB3ZQ0KbGl2ZSB3aXRoIGl0LiBTbyB3ZSBzaG91bGQgbm90IGJlIGdvaW5nIGRv d24gdGhhdCBwYXRoIGluc3RlYWQgbmVlZCB0bw0KbG9vayBmb3J3YXJkIGZyb20gdGhhdCBleHBl cmllbmNlLjwvZm9udD4NCjxwPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGli cmkiPiZuYnNwOzwvZm9udD4NCjxwPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNh bGlicmkiPk11bHRpLXRvcG9sb2d5IG5vdCBvbmx5IGFkZHJlc3MNCm5pY2tuYW1lIHNwYWNlIGlz c3VlIGJ1dCBhbHNvIGVuYWJsZXMgdmFyaW91cyBvdGhlciBhcHBsaWNhdGlvbnMgc3VjaCBhcw0K b3ZlcmxheSB0b3BvbG9naWVzLCB0cmFmZmljIGVuZ2luZWVyaW5nLjwvZm9udD4NCjxwPjxmb250 IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxwPjxm b250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPlRoZSBkcmFmdC10aXNzLXRy aWxsLW11bHRpbGV2ZWwNCnByZXNlbnQgYXBwcm9hY2hlcyB0aGF0IGFyZSBnZW5lcmljLCB3aGlj aCBtZWFuIGl0IGNhbiBiZSBhcHBsaWVkIGZvciBtdWx0aS10b3BvbG9neSwNCm9yIGJhc2UgdG9w b2xvZ3kuIEl0IHV0aWxpemVzIHRoZSBmdW5kYW1lbnRhbHMgb2YgSVMtSVMgLCBzdWNoIGFzIEFy ZWENCmhpZXJhcmNoeSBmb3IgcmVkdWN0aW9uIG9mIHRoZSBMU1AtREIuIEl0IHV0aWxpemUgYWZm aW5pdHkgVExWIGNvbmNlcHRzDQp0byBlZmZlY3RpdmVseSBzb2x2ZSBtdWx0aS1kZXN0aW5hdGlv biBpc3N1ZXMuIDwvZm9udD4NCjxwPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNh bGlicmkiPiZuYnNwOzwvZm9udD4NCjxwPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9 IkNhbGlicmkiPldlIHNob3VsZCBub3QgbWl4LXVwIGJldHdlZW4NCkRhdGEgY2VudGVyIGludGVy Y29ubmVjdHMgd2l0aCBkYXRhIGNlbnRlciBub2RlIHNjYWxpbmcuIFRoZXkgYXJlIHR3byBkaWZm ZXJlbnQNCmFuZCBvcnRob2dvbmFsIGlzc3Vlcy48L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTIgY29s b3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTIg Y29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5PYmplY3RpdmUgb2YgbXVsdGktbGV2ZWwgdHJp bGwNCmlzIHRvIGludGVyY29ubmVjdCBkaWZmZXJlbnQgZGF0YWNlbnRlcnMsIGFuZCBtYWludGFp biBMU1AtREIgc21hbGwgYXMNCnBvc3NpYmxlIHRvIGF2b2lkIHNjYWxpbmcgYW5kIHZvbGF0aWxp dHkuPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+ Jm5ic3A7PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJy aSI+SW5jcmVhc2luZyBuaWNrbmFtZSBzcGFjZQ0KYSBkaWZmZXJlbnQgcmVxdWlyZW1lbnQgYW5k IGhhcyBub3RoaW5nIHRvIGRvIHdpdGggZGF0YS1jZW50ZXIgaW50ZXJjb25uZWN0cy48L2ZvbnQ+ DQo8cD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2Zv bnQ+DQo8cD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8 L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj48Yj5Gcm9tOjwvYj4gUmFkaWEg UGVybG1hbiBbbWFpbHRvOjwvZm9udD48YSBocmVmPW1haWx0bzpyYWRpYXBlcmxtYW5AZ21haWwu Y29tIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVGFob21hIj48 dT5yYWRpYXBlcmxtYW5AZ21haWwuY29tPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9 IlRhaG9tYSI+XQ0KPGI+PGJyPg0KU2VudDo8L2I+IEZyaWRheSwgRmVicnVhcnkgMjQsIDIwMTIg NjoxNSBBTTxiPjxicj4NClRvOjwvYj4gPC9mb250PjxhIGhyZWY9bWFpbHRvOmh1LmZhbmd3ZWlA enRlLmNvbS5jbiB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRh aG9tYSI+PHU+aHUuZmFuZ3dlaUB6dGUuY29tLmNuPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0y IGZhY2U9IlRhaG9tYSI+PGI+PGJyPg0KQ2M6PC9iPiBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5l dmlyKTsgPC9mb250PjxhIGhyZWY9bWFpbHRvOnJicmlkZ2VAcG9zdGVsLm9yZyB0YXJnZXQ9X2Js YW5rPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+cmJyaWRnZUBwb3N0 ZWwub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+Ow0KPC9mb250 PjxhIGhyZWY9Im1haWx0bzpyYnJpZGdlLWJvdW5jZXNAcG9zdGVsLm9yZyIgdGFyZ2V0PV9ibGFu az48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1PnJicmlkZ2UtYm91bmNl c0Bwb3N0ZWwub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGI+ PGJyPg0KU3ViamVjdDo8L2I+IFJlOiBbcmJyaWRnZV0gRGVmYXVsdCBuaWNrbmFtZSBiYXNlIGFw cHJvYWNoIGZvciBtdWx0aWxldmVsDQpUUklMTC0gZHJhZnQtdGlzc2EtdHJpbGwtbXVsdGlsZXZl bC0wMC50eHQ8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7 PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPlBlb3BsZSBoYXZlIG1l bnRpb25lZCB0byBtZSB0aGF0IHRoZXkNCmFyZSBuZXJ2b3VzIGFib3V0IHJ1bm5pbmcgb3V0IG9m IG5pY2tuYW1lcywgZXNwZWNpYWxseSBzaW5jZSB0aGVyZSBhcmUNCnJlYXNvbnNvbiB3aHkgdGhl eSBtaWdodCB3YW50IHRvIGFzc2lnbiBuaWNrbmFtZXMgdG8gaHlwZXJ2aXNvcnMuICZuYnNwO1dp dGgNCnRoZSBhbHRlcm5hdGUgYXBwcm9hY2ggb2YgYWxsb3dpbmcgbmlja25hbWVzIHRvIGJlIHJl dXNlZCBpbiBkaWZmZXJlbnQNCmFyZWFzLCBpdCBtYWtlcyBhdXRvbWF0aWMgbmlja25hbWUgYXNz aWdubWVudCBtdWNoIHNpbXBsZXIgYW5kIG1ha2VzIFRSSUxMDQphIGxvdCBtb3JlIHNjYWxhYmxl LjwvZm9udD4NCjxwPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+ DQo8cD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+SXQgZG9lcyBoYXZlIHRoZSBkb3du c2lkZSBvZiByZXF1aXJpbmcNCm1hcHBpbmcgb2Ygbmlja25hbWVzIGF0IHRoZSBib3JkZXIgUkJy aWRnZXMuPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwv Zm9udD4NCjxwPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5BbmQgYnkgdGhlIHdheSwg dGhlIGFmZmluaXR5IFRMViBjYW4NCmJlIHVzZWQgZm9yIG11bHRpZGVzdGluYXRpb24gZnJhbWVz IHRyYW5zaXRpbmcgYmV0d2VlbiBsZXZlbCAxIGFuZCBsZXZlbA0KMi48L2ZvbnQ+DQo8cD48Zm9u dCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0z IGZhY2U9InNhbnMtc2VyaWYiPlJhZGlhPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPjIwMTIvMi8yMyAmbHQ7PC9mb250PjxhIGhyZWY9bWFpbHRvOmh1LmZhbmd3ZWlA enRlLmNvbS5jbiB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNh bnMtc2VyaWYiPjx1Pmh1LmZhbmd3ZWlAenRlLmNvbS5jbjwvdT48L2ZvbnQ+PC9hPjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0zIGZhY2U9 IkFyaWFsIj48YnI+DQpIaSwgVGlzc2EuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNl cmlmIj4gPGJyPg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJBcmlhbCI+PGJyPg0KSSBoYXZl IHNldmVyYWwgY29tbWVudHMgYWJvdXQgdGhlIGRyYWZ0LjwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj48 YnI+DQooMSkgaW4gc2VjdGlvbiA0LjQgKE11bHRpY2FzdCksICZxdW90O1RoZSBzY29wZSBvZiBn bG9iYWwgdHJhZmZpYyBtYXkgYmUNCmlkZW50aWZpZWQgZWl0aGVyIHRocm91Z2ggVkxBTiBvciB2 aWEgZmluZWdyYWluIDxicj4NCmxhYmVsIHRoYXQgc3BhbnMgYWNyb3NzIHRoZSBlbnRpcmUgVFJJ TEwgY2FtcHVzLiZxdW90OzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj48YnI+DQpWbGFuIGFuZCBGaW5lLWdyYWlu IExhYmVsIGlzIHVzZWQgZm9yIHNlcnZpY2UgZGlmZmVyZW50aWF0aW9uIGFuZCBpc29sYXRpb24u DQpJIGRvIG5vdCBxdWl0ZSB1bmRlcnN0YW5kIHRoYXQgaG93IHRvPC9mb250Pjxmb250IHNpemU9 MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPjxi cj4NCnVzZSBWTEFOIGFuZCBmaW5lLWdyYWluIExhYmxlIHRvIGlkZW50aWZ5IHRoZSB0cmFmZmlj IHNjb3BlLiBUaGUgZGF0YSB0cmFmZmljDQp3aXRoIGEgZ2l2ZW4gVkxBTi14LCBjYW4gPGJyPg0K YmUgZm9yd2FyZGVkIHRvIG90aGVyIGVuZCBzdGF0aW9uIGluIHRoZSBsb2NhbCBhcmVhLCBvciB0 byB0aGUgZW5kIHN0YXRpb24NCmluIHJlbW90ZSBhcmVhcy4gPC9mb250Pjxmb250IHNpemU9MyBm YWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj48 YnI+DQooMikgbmlja25hbWUgYWxsb2NhdGlvbjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fu cy1zZXJpZiI+IDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPjxicj4NClRoZSBuaWNr bmFtZSBtYW5hZ2VtZW50IHN1Yi1UTFYgaXMgcHJvcG9zZWQgaW4gdGhlIGRvY3VtZW50LiBJIHdv bmRlciB0aGlzDQptZWNoYW5pc20gYWRkcyB0aGUgY29tcGxpY2F0aW9uIG9mICZuYnNwOzwvZm9u dD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh Y2U9IkFyaWFsIj48YnI+DQpuaWNrbmFtZSBhbGxvY2F0aW9uLiBBcyB0aGUgc2VjdGlvbiAxIChp bnRyb2R1Y3Rpb24pIG9mIFJGQzYzMjUsIG9uZSBvZg0KdGhlIGltcG9ydGFudCBhZHZhbnRhZ2Ug b2YgVFJJTEwgaXMgdGhhdCAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2Vy aWYiPg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJBcmlhbCI+PGJyPg0KaXQgYXZvaWRzIHRo ZSBjcmVhdGluZyBzdWJuZXRzIG9mIElQIGFkZHJlc3MgYW5kIHdhc3RpbmcgYWRkcmVzcy4gVGhl IG5pY2tuYW1lDQphY3F1aXNpdGlvbiAmbmJzcDttZXRob2QgaW4gdGhpcyBkcmFmdCB2aW9sYXRl cyB0aGUgJm5ic3A7PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9u dD48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPjxicj4NCmlkZWEgb2YgVFJJTEwgQmFzaWMgc3Bl Y2lmaWNhdGlvbiwgYW5kIHJlZHVjZXMgdGhlIGZsZXhpYmlsaXR5IG9mIG5pY2tuYW1lDQphbGxv Y2F0aW9uLiBBcyB0aGUgZHJhZnQgYXNzdW1lZCwgQTEgaGFkICZuYnNwOzwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFs Ij48YnI+DQpuaWNrbmFtZSByYW5nZSBvZiAxMDAtMjAwLCBBMiBoYXMgYSBsb2NhbCBuaWNrbmFt ZSByYW5nZSBvZiAyMDEtMzAwLiBJZg0KdGhlIG51bWJlcnMgb2YgQTEgYXJlYSBpcyBvbmx5IDUw LCBzbyA1MCAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJBcmlhbCI+PGJyPg0Kbmlja25hbWVzIGluIEExIGlzIHdh c3RlZC4gQXMgdGhlIG5ldHdvcmsgZ3Jvd2luZywgdGhlIG51bWJlciBvZiBzb21lIGFyZWFzDQpt YXkgZXhjZWVkIHRoZSBudW1iZXIgYmVpbmcgYWxsb2NhdGlvbiAmbmJzcDs8L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJBcmlh bCI+PGJyPg0KYnkgQm9yZGVyIFJCcmlkZ2VzLiBUaGUgZGVzaWduIGFuZCBtYWludGFpbmluZyBv ZiBuaWNrbmFtZSByYW5nZXMgZm9yIGVhY2gNCmFyZWEgaXMgYSB2ZXJ5IGhhcmQgd29yay4gRXZl biB3b3JzdCwgaXQgJm5ic3A7PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4N CjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPjxicj4NCmNhbiBub3QgYXZvaWQgdG8g d2FzdGUgbmlja25hbWUgc3BhY2UuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlm Ij4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPjxicj4NCigzKSBEeW5h bWljIHJhbmdlcyA8YnI+DQogVGhlIG5pY2tuYW1lIHJhbmdlIGlzIGRpdmlkZWQgaW50byB0d28g cmFuZ2U6IGxvY2FsIHJhbmdlIGFuZCBkeW5hbWljYWwNCnJhbmdlLiBJIHdvbmRlciB0aGUgbmlj a25hbWUgY29uZmxpY3QgJm5ic3A7PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlm Ij4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPjxicj4NCnJlc29sdXRpb24gY2Fu IG5vdCB3b3JrIGlmIHRoZSBSQnJpZGdlIGdldCB0aGUgbmlja25hbWUgZnJvbSB0aGUgZHluYW1p Y2FsDQpyYW5nZSB3aGlsZSB0aGUgdHdvIFJCcmlkZ2UgYmVsb25ncyB0byAmbmJzcDs8L2ZvbnQ+ PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJBcmlhbCI+PGJyPg0KZGlmZmVyZW50IGFyZWFzLiBGb3IgZXhhbXBsZSwgUkIxIGlzIGluIGFy ZWEgQTEsIGFuZCBSQjIgaXMgaW4gYXJlYSBBMi4NCklmIFJCMSBnZXRzIHRoZSBuaWNrbmFtZSBO MSBmcm9tIGR5bmFtaWMgJm5ic3A7PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlm Ij4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPjxicj4NCnJhbmdlLCBhbmQgaXQg d2lsbCBmbG9vZHMgaW4gYXJlYSBBMSwgYW5kIG90aGVyIFJCcmlkZ2VzIGluIGFyZWEgQTEgY2Fu DQpub3QgZ2V0IG5pY2tuYW1lIE4xIGJlY2F1c2Ugb2Ygbmlja25hbWUgJm5ic3A7PC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0i QXJpYWwiPjxicj4NCmNvbmZsaWN0aW9uIG1lY2hhbmlzbSwgYnV0IFJCMiBpbiBhcmVhIEEyIGNh biBub3QgcmVjZWl2ZSB0aGUgUERVIGZyb20NClJCMSwgYW5kIGl0ICZuYnNwO2NhbiBhbHNvIGdl dCB0aGUgbmlja25hbWUgTjEgZnJvbSAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJBcmlhbCI+PGJyPg0KZHluYW1p Y2FsIHJhbmdlLiBTbyB0aGUgcXVlc3Rpb24gaXMgaG93IHRvIGF2b2lkIHRoZSBkdXBsaWNhdGlv biBkeW5hbWljYWwNCnJhbmdlIG5pY2tuYW1lIGZvciBkaWZmZXJlbnQgYXJlYXMuPC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0iQXJpYWwiPjxicj4NCig0KSBUaGUgcmlzayBvZiBydW5uaW5nIG91dCBvZiBuaWNrbmFt ZSBtYXliZSBhIGlzc3VlIGZvciBUUklMTC4gVGhlIG51bWJlcg0Kb2YgMioqMTYgbmlja25hbWUg aXMgZW5vdWdoIGZvciB0aGUgY3VycmVudCBkYXRhIGNlbnRlciw8L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJBcmlhbCI+PGJy Pg0KIGJ1dCBpdCBtYXliZSBub3QgZW5vdWdoIGluIHRoZSBmdXR1cmUsIGVzcGVjYWlsbHkgaWYg VFJJTEwgb3ZlciBJUCAsIFRSSUxMDQpvdmVyIE1QTFMgdGVjaG5vbG9neSBvciBzb21lIG90aGVy IGRhdGEgY2VudGVyIHRlY2hub2xvZ2llczwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1z ZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj48YnI+DQogYXJlIGRlcGxv eWVkLCB0aGUgZGF0YSBjZW50ZXIgbmV0d29yayBjYW4gYmUgYSB2ZXJ5IGxhcmRnZSBuZXR3b3Jr LiBTbw0KaSB0aGluayB0aGUgdmVyeSBpbXBvcnRhbnQgYW5kIGVzc2VudGlhbCBnb2FsIG9mIG11 bHRpLWxldmVsIGRyYWZ0IGlzIHRvDQpzYXZlIG5pY2tuYW1lcy48L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9InNhbnMtc2VyaWYiPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFs Ij48YnI+DQpCZXN0IHJlZ2FyZHM8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYi PiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj48YnI+DQpGYW5nd2VpIEh1PGJyPg0K PC9mb250Pg0KPHA+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdp ZHRoPTM3JT48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPjxiPiZxdW90O1Rpc3NhIFNlbmV2aXJh dGhuZSAodHNlbmV2aXIpJnF1b3Q7DQombHQ7PC9iPjwvZm9udD48YSBocmVmPW1haWx0bzp0c2Vu ZXZpckBjaXNjby5jb20gdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNl PSJBcmlhbCI+PGI+PHU+dHNlbmV2aXJAY2lzY28uY29tPC91PjwvYj48L2ZvbnQ+PC9hPjxmb250 IHNpemU9MSBmYWNlPSJBcmlhbCI+PGI+Jmd0OzwvYj4NCjwvZm9udD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+PGJyPg0Kt6K8/sjLPC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJBcmlh bCI+OiAmbmJzcDs8L2ZvbnQ+PGEgaHJlZj0ibWFpbHRvOnJicmlkZ2UtYm91bmNlc0Bwb3N0ZWwu b3JnIiB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj48 dT5yYnJpZGdlLWJvdW5jZXNAcG9zdGVsLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBm YWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+ MjAxMi0wMi0yMyAxMTo1NTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8 L2ZvbnQ+DQo8dGQgd2lkdGg9NjElPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZCB3aWR0aD0xNyU+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQgd2lkdGg9ODIlPjxmb250 IHNpemU9MSBmYWNlPSJBcmlhbCI+Jmx0OzwvZm9udD48YSBocmVmPW1haWx0bzpyYnJpZGdlQHBv c3RlbC5vcmcgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJBcmlh bCI+PHU+cmJyaWRnZUBwb3N0ZWwub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0xIGZhY2U9 IkFyaWFsIj4mZ3Q7PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9u dD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD4NCjx0ciB2YWxpZ249dG9w Pg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ 1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPltyYnJpZGdl XSBEZWZhdWx0IG5pY2tuYW1lIGJhc2UgYXBwcm9hY2gNCmZvciBtdWx0aWxldmVsIFRSSUxMLSAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkcmFmdC10aXNzYS10cmlsbC1tdWx0aWxldmVsLTAw LnR4dDwvZm9udD48L3RhYmxlPg0KPHA+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZu YnNwOzwvZm9udD4NCjxwPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRv cD4NCjx0ZCB3aWR0aD01MCU+DQo8dGQgd2lkdGg9NTAlPjwvdGFibGU+DQo8YnI+DQo8dGQgd2lk dGg9MSU+PC90YWJsZT4NCjxwPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8 YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zPjx0dD48YnI+DQpEZWFyIEFsbDwvdHQ+PC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zPjx0 dD48YnI+DQpXZSBoYXZlIHN1Ym1pdHRlZCBkcmFmdC10aXNzYS10cmlsbC1tdWx0aWxldmVsLCBw cmVzZW50IG11bHRpbGV2ZWwgVFJJTEwNCmJhc2VkIG9uIGRlZmF1bHQgbmlja25hbWUgYXBwcm9h Y2guIEFkZGl0aW9uYWxseSB3ZSBkaXNjdXNzIGNvbnN0cnVjdGlvbg0Kb2YgbXVsdGktZGVzdGlu YXRpb24gdHJlZXMgYW5kIHJlbGF0ZWQgUlBGIGluIG11bHRpbGV2ZWwgVFJJTEwuIFBsZWFzZQ0K Y291bGQgeW91IHJldmlldyBhbmQgY29tbWVudCA8L3R0PjwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+PGJyPg0KPC9mb250Pjxmb250IHNpemU9Mz48dHQ+PGJyPg0KRGV0YWls IG9mIHRoZSBkcmFmdCBhbmQgYWJzdHJhY3QgYXJlIGJlbG93LjwvdHQ+PC9mb250Pjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zPjx0dD48YnI+ DQpGaWxlbmFtZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtkcmFmdC10aXNzYS10cmlsbC1tdWx0aWxldmVsPGJyPg0KUmV2aXNp b246ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7MDA8YnI+DQpUaXRsZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgRGVmYXVsdCBOaWNrbmFtZSBCYXNlZA0KQXBw cm9hY2ggZm9yIE11bHRpbGV2ZWwgVFJJTEw8YnI+DQpDcmVhdGlvbiBkYXRlOiAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsyMDEy LTAyLTIxPGJyPg0KV0cgSUQ6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEluZGl2aWR1YWwgU3VibWlzc2lvbjxicj4NCk51bWJl ciBvZiBwYWdlczogMjY8L3R0PjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ PGJyPg0KPC9mb250Pjxmb250IHNpemU9Mz48dHQ+PGJyPg0KQWJzdHJhY3Q6PGJyPg0KICZuYnNw O011bHRpbGV2ZWwgVFJJTEwgYWxsb3dzIHRoZSBpbnRlcmNvbm5lY3Rpb24gb2YgbXVsdGlwbGUg VFJJTEw8YnI+DQogJm5ic3A7bmV0d29ya3MgdG8gZm9ybSBhIGxhcmdlciBUUklMTCBuZXR3b3Jr IHdpdGhvdXQgcHJvcG9ydGlvbmFsbHk8YnI+DQogJm5ic3A7aW5jcmVhc2luZyB0aGUgc2l6ZSBv ZiB0aGUgSVMtSVMgTFNQIERCLiBJbiB0aGlzIGRvY3VtZW50LCBhbjxicj4NCiAmbmJzcDthcHBy b2FjaCBiYXNlZCBvbiBkZWZhdWx0IHJvdXRlIGNvbmNlcHQgaXMgcHJlc2VudGVkLiBBbHNvLDxi cj4NCiAmbmJzcDtwcmVzZW50ZWQgaW4gdGhlIGRvY3VtZW50IGlzIGEgbm92ZWwgbWV0aG9kIG9m IGNvbnN0cnVjdGluZyBtdWx0aS08YnI+DQogJm5ic3A7ZGVzdGluYXRpb24gdHJlZXMgdXNpbmcg cGFydGlhbCBuaWNrbmFtZSBzcGFjZS4gTWV0aG9kcyBwcmVzZW50ZWQNCmluPGJyPg0KICZuYnNw O3RoaXMgZG9jdW1lbnQgYXJlIGNvbXBhdGlibGUgd2l0aCB0aGUgUkZDNjMyNSBzcGVjaWZpZWQg ZGF0YSBwbGFuZTxicj4NCiAmbmJzcDtvcGVyYXRpb25zLjwvdHQ+PC9mb250Pjxmb250IHNpemU9 MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zPjx0dD48YnI+DQog Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxi cj4NClRoYW5rczxicj4NClRpc3NhPC90dD48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMt c2VyaWYiPjxicj4NCjwvZm9udD48Zm9udCBzaXplPTM+PHR0Pjxicj4NCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KcmJyaWRnZSBtYWlsaW5nIGxp c3Q8L3R0PjwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dHQ+PHU+PGJyPg0KPC91Pjwv dHQ+PC9mb250PjxhIGhyZWY9bWFpbHRvOnJicmlkZ2VAcG9zdGVsLm9yZyB0YXJnZXQ9X2JsYW5r Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx0dD48dT5yYnJpZGdlQHBvc3RlbC5vcmc8L3U+PC90 dD48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx0dD48dT48YnI+DQo8L3U+PC90 dD48L2ZvbnQ+PGEgaHJlZj1odHRwOi8vbWFpbG1hbi5wb3N0ZWwub3JnL21haWxtYW4vbGlzdGlu Zm8vcmJyaWRnZSB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx0dD48dT5o dHRwOi8vbWFpbG1hbi5wb3N0ZWwub3JnL21haWxtYW4vbGlzdGluZm8vcmJyaWRnZTwvdT48L3R0 PjwvZm9udD48L2E+DQo8cD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpyYnJpZGdl IG1haWxpbmcgbGlzdDwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNl cmlmIj48dT48YnI+DQo8L3U+PC9mb250PjxhIGhyZWY9bWFpbHRvOnJicmlkZ2VAcG9zdGVsLm9y ZyB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYi Pjx1PnJicmlkZ2VAcG9zdGVsLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBjb2xvcj1i bHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj1odHRwOi8v bWFpbG1hbi5wb3N0ZWwub3JnL21haWxtYW4vbGlzdGluZm8vcmJyaWRnZSB0YXJnZXQ9X2JsYW5r Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1Pmh0dHA6Ly9tYWls bWFuLnBvc3RlbC5vcmcvbWFpbG1hbi9saXN0aW5mby9yYnJpZGdlPC91PjwvZm9udD48L2E+DQo8 cD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0KPHA+PGZvbnQg c2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD4NCjxwPg0KPHA+DQo= --=_alternative 000E074D482579B1_=-- --===============0463851584== 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 --===============0463851584==-- From rbridge-bounces@postel.org Sun Feb 26 19:29:28 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 514C921E800F for ; Sun, 26 Feb 2012 19:29:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.334 X-Spam-Level: X-Spam-Status: No, score=-101.334 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, MIME_HTML_MOSTLY=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, 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 uodkCciB4pNc for ; Sun, 26 Feb 2012 19:29:26 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 97DFE21E800C for ; Sun, 26 Feb 2012 19:29:26 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1R2ovFu000157; Sun, 26 Feb 2012 18:50:58 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1R2oPBR000102; Sun, 26 Feb 2012 18:50:34 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 523732371461274; Mon, 27 Feb 2012 10:42:40 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 73687.3928560221; Mon, 27 Feb 2012 10:50:09 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q1R2o5l8021654; Mon, 27 Feb 2012 10:50:05 +0800 (GMT-8) (envelope-from hu.fangwei@zte.com.cn) In-Reply-To: <344037D7CFEFE84E97E9CC1F56C5F4A5A46360@xmb-sjc-214.amer.cisco.com> To: "Tissa Senevirathne (tsenevir)" 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, 27 Feb 2012 10:50:04 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-02-27 10:50:06, Serialize complete at 2012-02-27 10:50:06 X-MAIL: mse01.zte.com.cn q1R2o5l8021654 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: hu.fangwei@zte.com.cn Cc: rbridge@postel.org, rbridge-bounces@postel.org, Radia Perlman Subject: Re: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.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: multipart/mixed; boundary="===============1250075799==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org This is a multipart message in MIME format. --===============1250075799== Content-Type: multipart/alternative; boundary="=_alternative 000F90ED482579B1_=" This is a multipart message in MIME format. --=_alternative 000F90ED482579B1_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 VGhlIHJlYXNvbiB3aHkgZm9sa3MgaW4gSVAgd29yZCBhcmUgcHVzaGluZyB0byBnbyB0byBJUHY2 IGlzIHRoYXQgdGhlIA0KZXhoYXVzdGluZyBvZiBJUHY0IGFkZHJlc3MsIG5vdCB0aGF0IHRoZSBO QVQgY2FuIG5vdCB3b3JrLiANCg0KVGhlIE5BVCB0ZWNobm9sb2d5IGlzIHdpZGVseSBkZXBsb3ll ZCBpbiBDaGluYSwgYW5kIGl0IGRvZXMgd29yayB3ZWxsLiANClRoZXJlIGlzIHZlcnkgbGl0dGxl IElQdjQgYWRkcmVzcyBjYW4gYmUgYXNzaWduZWQgdG8gdGhlIEJOQVMoTW9zdCBvZiB0aGUgDQph ZGRyZXNzIGFzc2lnbmVkIHRvIHRoZSB1c2VyIGFyZSBwcml2YXRlIElQdjQgYWRkcmVzcywgYW5k IG9ubHkgdGhlIE5OQVMgDQphbmQgYWJvdmUgZXF1aXRtZW50IGFyZSBhc3NpZ25lZCBwdWJsaWMg YWRkcmVzcyApLCBzbyBpdCBpcyBhbiBlbWVyZ2VudCANCnRoaW5nIHRvIHRyYW5zaXQgZnJvbSBJ UHY0IHRvIElQdjYuDQoNCklmIHdlIGNhbiBub3Qgc2xvdmUgdGhlIG5pY2tuYW1lIHNwYWNlIGlz c3VlIG5vdywgZG8gd2UgbmVlZCBhbm90aGVyIA0KTklDS05BTUV2NiBvciBzb21ldGhpbmcgZWxz ZT8gDQoNClNvIGkgdGhpbmcgdGhlIG5pY2tuYW1lIHNwYWNlIGlzc3VlIGlzIHRoZSBrZXkgaXNz dWUgd2Ugc2hvdWxkIHNsb3ZlIG5vdy4gDQoNCk11bHRpLWxldmVsIGRyYWZ0IGlzIGEgZ29vZCBw bGF0Zm9ybSB0byBzbG92ZSBpdCwgdGhvdWdoIHRoZXJlIGlzIHNvbWUgDQp0ZWNobm9sb2d5IHdl IHNob3VsZCBjb25zaWRlcmVkIGZ1dGhlci4gDQoNCg0KDQoNCiJUaXNzYSBTZW5ldmlyYXRobmUg KHRzZW5ldmlyKSIgPHRzZW5ldmlyQGNpc2NvLmNvbT4gDQq3orz+yMs6ICByYnJpZGdlLWJvdW5j ZXNAcG9zdGVsLm9yZw0KMjAxMi0wMi0yNSAwMjowNw0KDQrK1bz+yMsNCiJSYWRpYSBQZXJsbWFu IiA8cmFkaWFwZXJsbWFuQGdtYWlsLmNvbT4NCrOty80NCnJicmlkZ2VAcG9zdGVsLm9yZywgcmJy aWRnZS1ib3VuY2VzQHBvc3RlbC5vcmcsIGh1LmZhbmd3ZWlAenRlLmNvbS5jbg0K1vfM4g0KUmU6 IFtyYnJpZGdlXSBEZWZhdWx0IG5pY2tuYW1lIGJhc2UgYXBwcm9hY2ggZm9yIG11bHRpbGV2ZWwg VFJJTEwtIA0KZHJhZnQtdGlzc2EtdHJpbGwtbXVsdGlsZXZlbC0wMC50eHQNCg0KDQoNCg0KDQoN CkFsc28sIHRoZXJlIGFyZSBzbyBtYW55IHdlbGwga25vd24gaXNzdWVzIHdpdGggTkFUIGxpa2Ug YXBwcm9hY2hlcy4gIzEgaXMgDQp5b3Ugd291bGQgbG9zZSBpZGVudGl0eSBvZiBvcmlnaW5hdG9y LCBhbmQgaXQgYmVjb21lcyBhbiBPQU0gbmlnaHRtYXJlLiBJdCANCmxpbWl0IGFiaWxpdHkgYXBw bHkgY2VydGFpbiBBQ0wsIHJhdGUtbGltaXRpbmcgZXRjLg0KIA0KVGhlcmUgaXMgYSB3aG9sZSBz ZXJpZXMgb2YgaXNzdWVzIGFzc29jaWF0ZWQgd2l0aCBOQVRzLiBUaGF0IGlzIG9uZSBvZiB0aGUg DQpyZWFzb25zIGZvbGtzIGluIElQIHdvcmxkIGFyZSBwdXNoaW5nIGhhcmQgdG8gZ28gdG8gSVB2 Ni4gSSB3YXMgYXNzdW1pbmcgDQpwZW9wbGUgYXJlIGF3YXJlIG9mIHRob3NlLg0KIA0KRnJvbTog UmFkaWEgUGVybG1hbiBbbWFpbHRvOnJhZGlhcGVybG1hbkBnbWFpbC5jb21dIA0KU2VudDogRnJp ZGF5LCBGZWJydWFyeSAyNCwgMjAxMiA5OjIzIEFNDQpUbzogVGlzc2EgU2VuZXZpcmF0aG5lICh0 c2VuZXZpcikNCkNjOiBodS5mYW5nd2VpQHp0ZS5jb20uY247IHJicmlkZ2VAcG9zdGVsLm9yZzsg cmJyaWRnZS1ib3VuY2VzQHBvc3RlbC5vcmcNClN1YmplY3Q6IFJlOiBbcmJyaWRnZV0gRGVmYXVs dCBuaWNrbmFtZSBiYXNlIGFwcHJvYWNoIGZvciBtdWx0aWxldmVsIA0KVFJJTEwtIGRyYWZ0LXRp c3NhLXRyaWxsLW11bHRpbGV2ZWwtMDAudHh0DQogDQpJIGFzc3VtZSB0aGF0IGFsbCBSQnJpZGdl cyB3aWxsIG5lZWQgdG8gYmUgaW4gYWxsIHRvcG9sb2dpZXMsIHNvIA0KbXVsdGl0b3BvbG9neSB3 aWxsIG5vdCBoZWxwIHdpdGggbmlja25hbWUgZXhoYXVzdGlvbi4gIFBsdXMgeW91IGhhdmVuJ3Qg DQpleHBsYWluZWQgaG93IGEgVFJJTEwgcGFja2V0IHdvdWxkIGJlIG1hcmtlZCBhcyB0byB3aGlj aCB0b3BvbG9neSB0aGUgDQpwYWNrZXQgc2hvdWxkIGJlIHJvdXRlZCBhY2NvcmRpbmcgdG8gKG90 aGVyIHRoYW4gd2hhdCBJIG1lbnRpb25lZCwgd2hpY2ggDQphY3R1YWxseSBlYXRzIHVwIG5pY2tu YW1lcyBieSBhIGZhY3RvciBvZiB0aGUgbnVtYmVyIG9mIHRvcG9sb2dpZXMgDQpzdXBwb3J0ZWQp Lg0KIA0KUGx1cywgcmF0aGVyIHRoYW4ganVzdCBsdW1waW5nIHBvdGVudGlhbCBpc3N1ZXMgaW50 byBhIHBocmFzZSBzdWNoIGFzIA0KIk5BVC1saWtlIiwgYmUgZXhwbGljaXQgYWJvdXQgd2hhdCBp c3N1ZXMgdGhlcmUgYWN0dWFsbHkgYXJlLiAgSSBiZWxpZXZlIA0KdGhlIEZ1bGNydW0gY2hpcCB3 b3VsZCBoYXZlIG5vIHByb2JsZW0gd2l0aCB0cmFuc2xhdGluZyB0aGUgbmlja25hbWUgDQpmaWVs ZHMuDQogDQpBbmQgcmF0aGVyIHRoYW4gYXNzdW1pbmcgdGhhdCBuaWNrbmFtZSBleGhhdXN0aW9u IGNhbiBiZSBzb2x2ZWQgInNvbWUgDQpvdGhlciB3YXkiLCB0aGVyZSBzaG91bGQgYmUgYSBwYWxh dGFibGUgc29sdXRpb24gYmVmb3JlIHJlamVjdGluZyBhIGNoYW5jZSANCnRvIHNvbHZlIGl0IHdp dGggbXVsdGlsZXZlbC4NCiANClJhZGlhDQoyMDEyLzIvMjQgVGlzc2EgU2VuZXZpcmF0aG5lICh0 c2VuZXZpcikgPHRzZW5ldmlyQGNpc2NvLmNvbT4NCkJlY2F1c2UgeW91IGNhbiBoYXZlIHNhbWUg bmlja25hbWUgZm9yIGRpZmZlcmVudCB0b3BvbG9neS4gSXQgaXMgbm90IGEgDQpuaWNrbmFtZSB0 aGF0IHdpbGwgaWRlbnRpZnkgYW4gUkJSaWRnZSwgaXQgaXMgdG9wb2xvZ3ksbmlja25hbWUgDQpj b21iaW5hdGlvbiB0aGF0IHdpbGwgaWRlbnRpZnkgYW4gUkJSaWRnZS4gU28gUkIxIGNhbiBoYXZl IG5pY2tuYW1lIDEgaW4gDQp0b3BvLTEgYW5kIFJCMiBjYW4gaGF2ZSBuaWNrbmFtZSAxIGluIHRv cG8yLiBOb3cgdG90YWwgbmlja25hbWVzIGluIHRoZSANCmNhbXB1cyBpcyAyKioxNiB4IHRvcG9s b2dpZXMuDQogDQpTdGVhbGluZyBiaXRzIHRvIHJlcHJlc2VudCB0b3BvIGlkIGlzIG9ubHkgYSB3 b3JrYXJvdW5kIHRoZXJlIGNhbiBiZSAoYXJlIA0KKSBtb3JlIGVsZWdhbnQgd2F5cyBvZiBkb2lu ZyBpdCB0aGF0Lg0KIA0KQm90dG9tIGxpbmUgaXMgd2UgbmVlZCB0byBsb29rIGZvciBtb3JlIGNy ZWF0aXZlIG1ldGhvZHMgb2Ygc29sdmluZyANCm5pY2tuYW1lIHNwYWNlIGlzc3VlIHRoYW4gZG9p bmcgTkFUIGxpa2UgYmVoYXZpb3IuIA0KIA0KRnJvbTogUmFkaWEgUGVybG1hbiBbbWFpbHRvOnJh ZGlhcGVybG1hbkBnbWFpbC5jb21dIA0KU2VudDogRnJpZGF5LCBGZWJydWFyeSAyNCwgMjAxMiA5 OjA1IEFNDQpUbzogVGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZpcikNCkNjOiBodS5mYW5nd2Vp QHp0ZS5jb20uY247IHJicmlkZ2VAcG9zdGVsLm9yZzsgcmJyaWRnZS1ib3VuY2VzQHBvc3RlbC5v cmcgDQoNClN1YmplY3Q6IFJlOiBbcmJyaWRnZV0gRGVmYXVsdCBuaWNrbmFtZSBiYXNlIGFwcHJv YWNoIGZvciBtdWx0aWxldmVsIA0KVFJJTEwtIGRyYWZ0LXRpc3NhLXRyaWxsLW11bHRpbGV2ZWwt MDAudHh0DQogDQpJIGRvbid0IHVuZGVyc3RhbmQgaG93IG11bHRpLXRvcG9sb2d5IGhlbHBzIHdp dGggdGhlIG5pY2tuYW1lIGV4aGF1c3Rpb24gDQppc3N1ZS4gIEFzIGEgbWF0dGVyIG9mIGZhY3Qs IHRoZSBvbmx5IHBsYXVzaWJsZSB3YXkgb2YgbWFya2luZyBhIHBhY2tldCANCmZvciB3aGljaCB0 b3BvbG9neSB0aGF0IGhhcyBiZWVuIHN1Z2dlc3RlZCBvbiB0aGUgbWFpbGluZyBsaXN0IChJIGFz a2VkIGEgDQplZncgdGltZXMgaWYgdGhlcmUgd2VyZSBhbnkgb3RoZXIgcG9zc2liaWxpdGllcyks IHdhcyB0byBzdGVhbCAyIG9yIDMgYml0cyANCm9mIHRoZSBuaWNrbmFtZSB0byBlbmNvZGUgd2hp Y2ggdG9wb2xvZ3ksIGluIGVmZmVjdCwgbWFraW5nIGEgZGVzdGluYXRpb24gDQphcHBlYXIgYXMg bXVsdGlwbGUgZGVzdGluYXRpb25zIGFuZCBtdWx0aXBsZSBmb3J3YXJkaW5nIHRhYmxlIGVudHJp ZXMgDQood2hpY2ggeW91J2Qgd2FudCBhbnl3YXksIGZvciBtdWx0aXRvcG9sb2d5KS4NCiANCiAN ClJhZGlhDQoyMDEyLzIvMjQgVGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZpcikgPHRzZW5ldmly QGNpc2NvLmNvbT4NCk11dGxpLXRvcG9sb2d5IGlzIHRoZSBhbnN3ZXIgdG8gaW5jcmVhc2UgdGhl IG5pY2tuYW1lIHNwYWNlLg0KIA0KTmlja25hbWUgdHJhbnNsYXRpb24gaXMgdmVyeSBzaW1pbGFy IHRvIE5BVCwgd2hpY2ggaGFzIGl0oa9zIG93biBkb3duIA0Kc2lkZSwgbm90IHRvIG1lbnRpb24g c3BlY2lhbCBoYXJkd2FyZSBldGMuIHRvIGRvIHRoZSB0cmFuc2xhdGlvbnMsIA0KYWRkaXRpb25h bGx5LiBXZSBhbHNvIGtub3cgZnJvbSBvdXIgZXhwZXJpZW5jZSwgaW4gSVAgd29ybGQgTkFUaW5n IGlzIG5vdCANCnRoZSBtb3N0IGRlc2lyZWQgYmVoYXZpb3IgYW5kIHdlIGxpdmUgd2l0aCBpdC4g U28gd2Ugc2hvdWxkIG5vdCBiZSBnb2luZyANCmRvd24gdGhhdCBwYXRoIGluc3RlYWQgbmVlZCB0 byBsb29rIGZvcndhcmQgZnJvbSB0aGF0IGV4cGVyaWVuY2UuDQogDQpNdWx0aS10b3BvbG9neSBu b3Qgb25seSBhZGRyZXNzIG5pY2tuYW1lIHNwYWNlIGlzc3VlIGJ1dCBhbHNvIGVuYWJsZXMgDQp2 YXJpb3VzIG90aGVyIGFwcGxpY2F0aW9ucyBzdWNoIGFzIG92ZXJsYXkgdG9wb2xvZ2llcywgdHJh ZmZpYyANCmVuZ2luZWVyaW5nLg0KIA0KVGhlIGRyYWZ0LXRpc3MtdHJpbGwtbXVsdGlsZXZlbCBw cmVzZW50IGFwcHJvYWNoZXMgdGhhdCBhcmUgZ2VuZXJpYywgd2hpY2ggDQptZWFuIGl0IGNhbiBi ZSBhcHBsaWVkIGZvciBtdWx0aS10b3BvbG9neSwgb3IgYmFzZSB0b3BvbG9neS4gSXQgdXRpbGl6 ZXMgDQp0aGUgZnVuZGFtZW50YWxzIG9mIElTLUlTICwgc3VjaCBhcyBBcmVhIGhpZXJhcmNoeSBm b3IgcmVkdWN0aW9uIG9mIHRoZSANCkxTUC1EQi4gSXQgdXRpbGl6ZSBhZmZpbml0eSBUTFYgY29u Y2VwdHMgdG8gZWZmZWN0aXZlbHkgc29sdmUgDQptdWx0aS1kZXN0aW5hdGlvbiBpc3N1ZXMuIA0K IA0KV2Ugc2hvdWxkIG5vdCBtaXgtdXAgYmV0d2VlbiBEYXRhIGNlbnRlciBpbnRlcmNvbm5lY3Rz IHdpdGggZGF0YSBjZW50ZXIgDQpub2RlIHNjYWxpbmcuIFRoZXkgYXJlIHR3byBkaWZmZXJlbnQg YW5kIG9ydGhvZ29uYWwgaXNzdWVzLg0KIA0KT2JqZWN0aXZlIG9mIG11bHRpLWxldmVsIHRyaWxs IGlzIHRvIGludGVyY29ubmVjdCBkaWZmZXJlbnQgZGF0YWNlbnRlcnMsIA0KYW5kIG1haW50YWlu IExTUC1EQiBzbWFsbCBhcyBwb3NzaWJsZSB0byBhdm9pZCBzY2FsaW5nIGFuZCB2b2xhdGlsaXR5 Lg0KIA0KSW5jcmVhc2luZyBuaWNrbmFtZSBzcGFjZSBhIGRpZmZlcmVudCByZXF1aXJlbWVudCBh bmQgaGFzIG5vdGhpbmcgdG8gZG8gDQp3aXRoIGRhdGEtY2VudGVyIGludGVyY29ubmVjdHMuDQog DQogDQpGcm9tOiBSYWRpYSBQZXJsbWFuIFttYWlsdG86cmFkaWFwZXJsbWFuQGdtYWlsLmNvbV0g DQpTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDI0LCAyMDEyIDY6MTUgQU0NClRvOiBodS5mYW5nd2Vp QHp0ZS5jb20uY24NCkNjOiBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKTsgcmJyaWRnZUBw b3N0ZWwub3JnOyANCnJicmlkZ2UtYm91bmNlc0Bwb3N0ZWwub3JnDQpTdWJqZWN0OiBSZTogW3Ji cmlkZ2VdIERlZmF1bHQgbmlja25hbWUgYmFzZSBhcHByb2FjaCBmb3IgbXVsdGlsZXZlbCANClRS SUxMLSBkcmFmdC10aXNzYS10cmlsbC1tdWx0aWxldmVsLTAwLnR4dA0KIA0KUGVvcGxlIGhhdmUg bWVudGlvbmVkIHRvIG1lIHRoYXQgdGhleSBhcmUgbmVydm91cyBhYm91dCBydW5uaW5nIG91dCBv ZiANCm5pY2tuYW1lcywgZXNwZWNpYWxseSBzaW5jZSB0aGVyZSBhcmUgcmVhc29uc29uIHdoeSB0 aGV5IG1pZ2h0IHdhbnQgdG8gDQphc3NpZ24gbmlja25hbWVzIHRvIGh5cGVydmlzb3JzLiAgV2l0 aCB0aGUgYWx0ZXJuYXRlIGFwcHJvYWNoIG9mIGFsbG93aW5nIA0Kbmlja25hbWVzIHRvIGJlIHJl dXNlZCBpbiBkaWZmZXJlbnQgYXJlYXMsIGl0IG1ha2VzIGF1dG9tYXRpYyBuaWNrbmFtZSANCmFz c2lnbm1lbnQgbXVjaCBzaW1wbGVyIGFuZCBtYWtlcyBUUklMTCBhIGxvdCBtb3JlIHNjYWxhYmxl Lg0KIA0KSXQgZG9lcyBoYXZlIHRoZSBkb3duc2lkZSBvZiByZXF1aXJpbmcgbWFwcGluZyBvZiBu aWNrbmFtZXMgYXQgdGhlIGJvcmRlciANClJCcmlkZ2VzLg0KIA0KQW5kIGJ5IHRoZSB3YXksIHRo ZSBhZmZpbml0eSBUTFYgY2FuIGJlIHVzZWQgZm9yIG11bHRpZGVzdGluYXRpb24gZnJhbWVzIA0K dHJhbnNpdGluZyBiZXR3ZWVuIGxldmVsIDEgYW5kIGxldmVsIDIuDQogDQpSYWRpYQ0KMjAxMi8y LzIzIDxodS5mYW5nd2VpQHp0ZS5jb20uY24+DQoNCkhpLCBUaXNzYS4gDQoNCkkgaGF2ZSBzZXZl cmFsIGNvbW1lbnRzIGFib3V0IHRoZSBkcmFmdC4gDQoNCigxKSBpbiBzZWN0aW9uIDQuNCAoTXVs dGljYXN0KSwgIlRoZSBzY29wZSBvZiBnbG9iYWwgdHJhZmZpYyBtYXkgYmUgDQppZGVudGlmaWVk IGVpdGhlciB0aHJvdWdoIFZMQU4gb3IgdmlhIGZpbmVncmFpbiANCmxhYmVsIHRoYXQgc3BhbnMg YWNyb3NzIHRoZSBlbnRpcmUgVFJJTEwgY2FtcHVzLiIgDQpWbGFuIGFuZCBGaW5lLWdyYWluIExh YmVsIGlzIHVzZWQgZm9yIHNlcnZpY2UgZGlmZmVyZW50aWF0aW9uIGFuZCANCmlzb2xhdGlvbi4g SSBkbyBub3QgcXVpdGUgdW5kZXJzdGFuZCB0aGF0IGhvdyB0byANCnVzZSBWTEFOIGFuZCBmaW5l LWdyYWluIExhYmxlIHRvIGlkZW50aWZ5IHRoZSB0cmFmZmljIHNjb3BlLiBUaGUgZGF0YSANCnRy YWZmaWMgd2l0aCBhIGdpdmVuIFZMQU4teCwgY2FuIA0KYmUgZm9yd2FyZGVkIHRvIG90aGVyIGVu ZCBzdGF0aW9uIGluIHRoZSBsb2NhbCBhcmVhLCBvciB0byB0aGUgZW5kIHN0YXRpb24gDQppbiBy ZW1vdGUgYXJlYXMuIA0KDQooMikgbmlja25hbWUgYWxsb2NhdGlvbiANClRoZSBuaWNrbmFtZSBt YW5hZ2VtZW50IHN1Yi1UTFYgaXMgcHJvcG9zZWQgaW4gdGhlIGRvY3VtZW50LiBJIHdvbmRlciB0 aGlzIA0KbWVjaGFuaXNtIGFkZHMgdGhlIGNvbXBsaWNhdGlvbiBvZiAgIA0Kbmlja25hbWUgYWxs b2NhdGlvbi4gQXMgdGhlIHNlY3Rpb24gMSAoaW50cm9kdWN0aW9uKSBvZiBSRkM2MzI1LCBvbmUg b2YgDQp0aGUgaW1wb3J0YW50IGFkdmFudGFnZSBvZiBUUklMTCBpcyB0aGF0ICAgDQppdCBhdm9p ZHMgdGhlIGNyZWF0aW5nIHN1Ym5ldHMgb2YgSVAgYWRkcmVzcyBhbmQgd2FzdGluZyBhZGRyZXNz LiBUaGUgDQpuaWNrbmFtZSBhY3F1aXNpdGlvbiAgbWV0aG9kIGluIHRoaXMgZHJhZnQgdmlvbGF0 ZXMgdGhlICAgDQppZGVhIG9mIFRSSUxMIEJhc2ljIHNwZWNpZmljYXRpb24sIGFuZCByZWR1Y2Vz IHRoZSBmbGV4aWJpbGl0eSBvZiBuaWNrbmFtZSANCmFsbG9jYXRpb24uIEFzIHRoZSBkcmFmdCBh c3N1bWVkLCBBMSBoYWQgICANCm5pY2tuYW1lIHJhbmdlIG9mIDEwMC0yMDAsIEEyIGhhcyBhIGxv Y2FsIG5pY2tuYW1lIHJhbmdlIG9mIDIwMS0zMDAuIElmIA0KdGhlIG51bWJlcnMgb2YgQTEgYXJl YSBpcyBvbmx5IDUwLCBzbyA1MCAgIA0Kbmlja25hbWVzIGluIEExIGlzIHdhc3RlZC4gQXMgdGhl IG5ldHdvcmsgZ3Jvd2luZywgdGhlIG51bWJlciBvZiBzb21lIA0KYXJlYXMgbWF5IGV4Y2VlZCB0 aGUgbnVtYmVyIGJlaW5nIGFsbG9jYXRpb24gICANCmJ5IEJvcmRlciBSQnJpZGdlcy4gVGhlIGRl c2lnbiBhbmQgbWFpbnRhaW5pbmcgb2Ygbmlja25hbWUgcmFuZ2VzIGZvciBlYWNoIA0KYXJlYSBp cyBhIHZlcnkgaGFyZCB3b3JrLiBFdmVuIHdvcnN0LCBpdCAgIA0KY2FuIG5vdCBhdm9pZCB0byB3 YXN0ZSBuaWNrbmFtZSBzcGFjZS4gDQoNCigzKSBEeW5hbWljIHJhbmdlcyANCiBUaGUgbmlja25h bWUgcmFuZ2UgaXMgZGl2aWRlZCBpbnRvIHR3byByYW5nZTogbG9jYWwgcmFuZ2UgYW5kIGR5bmFt aWNhbCANCnJhbmdlLiBJIHdvbmRlciB0aGUgbmlja25hbWUgY29uZmxpY3QgICANCnJlc29sdXRp b24gY2FuIG5vdCB3b3JrIGlmIHRoZSBSQnJpZGdlIGdldCB0aGUgbmlja25hbWUgZnJvbSB0aGUg ZHluYW1pY2FsIA0KcmFuZ2Ugd2hpbGUgdGhlIHR3byBSQnJpZGdlIGJlbG9uZ3MgdG8gICANCmRp ZmZlcmVudCBhcmVhcy4gRm9yIGV4YW1wbGUsIFJCMSBpcyBpbiBhcmVhIEExLCBhbmQgUkIyIGlz IGluIGFyZWEgQTIuIElmIA0KUkIxIGdldHMgdGhlIG5pY2tuYW1lIE4xIGZyb20gZHluYW1pYyAg IA0KcmFuZ2UsIGFuZCBpdCB3aWxsIGZsb29kcyBpbiBhcmVhIEExLCBhbmQgb3RoZXIgUkJyaWRn ZXMgaW4gYXJlYSBBMSBjYW4gDQpub3QgZ2V0IG5pY2tuYW1lIE4xIGJlY2F1c2Ugb2Ygbmlja25h bWUgICANCmNvbmZsaWN0aW9uIG1lY2hhbmlzbSwgYnV0IFJCMiBpbiBhcmVhIEEyIGNhbiBub3Qg cmVjZWl2ZSB0aGUgUERVIGZyb20gDQpSQjEsIGFuZCBpdCAgY2FuIGFsc28gZ2V0IHRoZSBuaWNr bmFtZSBOMSBmcm9tICAgDQpkeW5hbWljYWwgcmFuZ2UuIFNvIHRoZSBxdWVzdGlvbiBpcyBob3cg dG8gYXZvaWQgdGhlIGR1cGxpY2F0aW9uIGR5bmFtaWNhbCANCnJhbmdlIG5pY2tuYW1lIGZvciBk aWZmZXJlbnQgYXJlYXMuIA0KDQooNCkgVGhlIHJpc2sgb2YgcnVubmluZyBvdXQgb2Ygbmlja25h bWUgbWF5YmUgYSBpc3N1ZSBmb3IgVFJJTEwuIFRoZSANCm51bWJlciBvZiAyKioxNiBuaWNrbmFt ZSBpcyBlbm91Z2ggZm9yIHRoZSBjdXJyZW50IGRhdGEgY2VudGVyLCANCiBidXQgaXQgbWF5YmUg bm90IGVub3VnaCBpbiB0aGUgZnV0dXJlLCBlc3BlY2FpbGx5IGlmIFRSSUxMIG92ZXIgSVAgLCAN ClRSSUxMIG92ZXIgTVBMUyB0ZWNobm9sb2d5IG9yIHNvbWUgb3RoZXIgZGF0YSBjZW50ZXIgdGVj aG5vbG9naWVzIA0KIGFyZSBkZXBsb3llZCwgdGhlIGRhdGEgY2VudGVyIG5ldHdvcmsgY2FuIGJl IGEgdmVyeSBsYXJkZ2UgbmV0d29yay4gU28gaSANCnRoaW5rIHRoZSB2ZXJ5IGltcG9ydGFudCBh bmQgZXNzZW50aWFsIGdvYWwgb2YgbXVsdGktbGV2ZWwgZHJhZnQgaXMgdG8gDQpzYXZlIG5pY2tu YW1lcy4gDQoNCkJlc3QgcmVnYXJkcyANCkZhbmd3ZWkgSHUNCg0KIlRpc3NhIFNlbmV2aXJhdGhu ZSAodHNlbmV2aXIpIiA8dHNlbmV2aXJAY2lzY28uY29tPiANCreivP7IyzogIHJicmlkZ2UtYm91 bmNlc0Bwb3N0ZWwub3JnIA0KMjAxMi0wMi0yMyAxMTo1NSANCg0KDQrK1bz+yMsNCjxyYnJpZGdl QHBvc3RlbC5vcmc+IA0Ks63LzQ0KDQrW98ziDQpbcmJyaWRnZV0gRGVmYXVsdCBuaWNrbmFtZSBi YXNlIGFwcHJvYWNoIGZvciBtdWx0aWxldmVsIFRSSUxMLSANCmRyYWZ0LXRpc3NhLXRyaWxsLW11 bHRpbGV2ZWwtMDAudHh0DQogDQoNCg0KDQoNCg0KDQoNCg0KDQpEZWFyIEFsbA0KDQpXZSBoYXZl IHN1Ym1pdHRlZCBkcmFmdC10aXNzYS10cmlsbC1tdWx0aWxldmVsLCBwcmVzZW50IG11bHRpbGV2 ZWwgVFJJTEwgDQpiYXNlZCBvbiBkZWZhdWx0IG5pY2tuYW1lIGFwcHJvYWNoLiBBZGRpdGlvbmFs bHkgd2UgZGlzY3VzcyBjb25zdHJ1Y3Rpb24gDQpvZiBtdWx0aS1kZXN0aW5hdGlvbiB0cmVlcyBh bmQgcmVsYXRlZCBSUEYgaW4gbXVsdGlsZXZlbCBUUklMTC4gUGxlYXNlIA0KY291bGQgeW91IHJl dmlldyBhbmQgY29tbWVudCANCg0KRGV0YWlsIG9mIHRoZSBkcmFmdCBhbmQgYWJzdHJhY3QgYXJl IGJlbG93Lg0KDQpGaWxlbmFtZTogICAgICAgICAgICAgICAgICBkcmFmdC10aXNzYS10cmlsbC1t dWx0aWxldmVsDQpSZXZpc2lvbjogICAgICAgICAgICAgICAgICAwMA0KVGl0bGU6ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBEZWZhdWx0IE5pY2tuYW1lIEJhc2VkIEFwcHJvYWNo IA0KZm9yIE11bHRpbGV2ZWwgVFJJTEwNCkNyZWF0aW9uIGRhdGU6ICAgICAgICAgICAgICAgICAg MjAxMi0wMi0yMQ0KV0cgSUQ6ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJbmRp dmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogMjYNCg0KQWJzdHJhY3Q6DQogIE11 bHRpbGV2ZWwgVFJJTEwgYWxsb3dzIHRoZSBpbnRlcmNvbm5lY3Rpb24gb2YgbXVsdGlwbGUgVFJJ TEwNCiAgbmV0d29ya3MgdG8gZm9ybSBhIGxhcmdlciBUUklMTCBuZXR3b3JrIHdpdGhvdXQgcHJv cG9ydGlvbmFsbHkNCiAgaW5jcmVhc2luZyB0aGUgc2l6ZSBvZiB0aGUgSVMtSVMgTFNQIERCLiBJ biB0aGlzIGRvY3VtZW50LCBhbg0KICBhcHByb2FjaCBiYXNlZCBvbiBkZWZhdWx0IHJvdXRlIGNv bmNlcHQgaXMgcHJlc2VudGVkLiBBbHNvLA0KICBwcmVzZW50ZWQgaW4gdGhlIGRvY3VtZW50IGlz IGEgbm92ZWwgbWV0aG9kIG9mIGNvbnN0cnVjdGluZyBtdWx0aS0NCiAgZGVzdGluYXRpb24gdHJl ZXMgdXNpbmcgcGFydGlhbCBuaWNrbmFtZSBzcGFjZS4gTWV0aG9kcyBwcmVzZW50ZWQgaW4NCiAg dGhpcyBkb2N1bWVudCBhcmUgY29tcGF0aWJsZSB3aXRoIHRoZSBSRkM2MzI1IHNwZWNpZmllZCBk YXRhIHBsYW5lDQogIG9wZXJhdGlvbnMuDQoNCiAgDQpUaGFua3MNClRpc3NhDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpyYnJpZGdlIG1haWxpbmcg bGlzdA0KcmJyaWRnZUBwb3N0ZWwub3JnDQpodHRwOi8vbWFpbG1hbi5wb3N0ZWwub3JnL21haWxt YW4vbGlzdGluZm8vcmJyaWRnZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KcmJyaWRnZSBtYWlsaW5nIGxpc3QNCnJicmlkZ2VAcG9zdGVsLm9yZw0K aHR0cDovL21haWxtYW4ucG9zdGVsLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JicmlkZ2UNCiANCiAN CiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcmJyaWRn ZSBtYWlsaW5nIGxpc3QNCnJicmlkZ2VAcG9zdGVsLm9yZw0KaHR0cDovL21haWxtYW4ucG9zdGVs Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JicmlkZ2UNCg0KDQo= --=_alternative 000F90ED482579B1_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoZSByZWFzb24gd2h5IGZvbGtz IGluIElQIHdvcmQgYXJlDQpwdXNoaW5nIHRvIGdvIHRvIElQdjYgaXMgdGhhdCB0aGUgZXhoYXVz dGluZyBvZiBJUHY0IGFkZHJlc3MsIG5vdCB0aGF0DQp0aGUgTkFUIGNhbiBub3Qgd29yay4gPC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGUgTkFUIHRl Y2hub2xvZ3kgaXMgd2lkZWx5IGRlcGxveWVkDQppbiBDaGluYSwgYW5kIGl0IGRvZXMgd29yayB3 ZWxsLiBUaGVyZSBpcyB2ZXJ5IGxpdHRsZSBJUHY0IGFkZHJlc3MgY2FuDQpiZSBhc3NpZ25lZCB0 byB0aGUgQk5BUyhNb3N0IG9mIHRoZSBhZGRyZXNzIGFzc2lnbmVkIHRvIHRoZSB1c2VyIGFyZSBw cml2YXRlDQpJUHY0IGFkZHJlc3MsIGFuZCBvbmx5IHRoZSBOTkFTIGFuZCBhYm92ZSBlcXVpdG1l bnQgYXJlIGFzc2lnbmVkIHB1YmxpYw0KYWRkcmVzcyApLCBzbyBpdCBpcyBhbiBlbWVyZ2VudCB0 aGluZyB0byB0cmFuc2l0IGZyb20gSVB2NCB0byBJUHY2LjwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SWYgd2UgY2FuIG5vdCBzbG92ZSB0aGUgbmlja25h bWUgc3BhY2UNCmlzc3VlIG5vdywgZG8gd2UgbmVlZCBhbm90aGVyIE5JQ0tOQU1FdjYgb3Igc29t ZXRoaW5nIGVsc2U/IDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+U28gaSB0aGluZyB0aGUgbmlja25hbWUgc3BhY2UgaXNzdWUNCmlzIHRoZSBrZXkgaXNz dWUgd2Ugc2hvdWxkIHNsb3ZlIG5vdy4gPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj5NdWx0aS1sZXZlbCBkcmFmdCBpcyBhIGdvb2QgcGxhdGZvcm0NCnRv IHNsb3ZlIGl0LCB0aG91Z2ggdGhlcmUgaXMgc29tZSB0ZWNobm9sb2d5IHdlIHNob3VsZCBjb25z aWRlcmVkIGZ1dGhlci4NCjwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3 aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzUlPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj48Yj4mcXVvdDtUaXNzYSBTZW5ldmlyYXRobmUNCih0c2VuZXZpcikm cXVvdDsgJmx0O3RzZW5ldmlyQGNpc2NvLmNvbSZndDs8L2I+IDwvZm9udD4NCjxicj48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDtyYnJpZGdlLWJvdW5jZXNAcG9z dGVsLm9yZzwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEyLTAy LTI1IDAyOjA3PC9mb250Pg0KPHRkIHdpZHRoPTY0JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRy IHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPiZxdW90O1JhZGlhIFBlcmxtYW4mcXVvdDsgJmx0O3JhZGlhcGVybG1hbkBnbWFp bC5jb20mZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0 Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5yYnJpZGdlQHBvc3RlbC5vcmcsIHJicmlkZ2Ut Ym91bmNlc0Bwb3N0ZWwub3JnLA0KaHUuZmFuZ3dlaUB6dGUuY29tLmNuPC9mb250Pg0KPHRyIHZh bGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj5SZTogW3JicmlkZ2VdIERlZmF1bHQgbmlja25hbWUgYmFzZQ0KYXBwcm9hY2ggZm9yIG11 bHRpbGV2ZWwgVFJJTEwtICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RyYWZ0LXRpc3NhLXRy aWxsLW11bHRpbGV2ZWwtMDAudHh0PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+QWxzbywgdGhl cmUgYXJlIHNvIG1hbnkgd2VsbA0Ka25vd24gaXNzdWVzIHdpdGggTkFUIGxpa2UgYXBwcm9hY2hl cy4gIzEgaXMgeW91IHdvdWxkIGxvc2UgaWRlbnRpdHkgb2YNCm9yaWdpbmF0b3IsIGFuZCBpdCBi ZWNvbWVzIGFuIE9BTSBuaWdodG1hcmUuICZuYnNwO0l0IGxpbWl0IGFiaWxpdHkgYXBwbHkNCmNl cnRhaW4gQUNMLCByYXRlLWxpbWl0aW5nIGV0Yy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNv bG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPlRoZXJlIGlzIGEgd2hvbGUgc2VyaWVzIG9m DQppc3N1ZXMgYXNzb2NpYXRlZCB3aXRoIE5BVHMuIFRoYXQgaXMgb25lIG9mIHRoZSByZWFzb25z IGZvbGtzIGluIElQIHdvcmxkDQphcmUgcHVzaGluZyBoYXJkIHRvIGdvIHRvIElQdjYuIEkgd2Fz IGFzc3VtaW5nIHBlb3BsZSBhcmUgYXdhcmUgb2YgdGhvc2UuPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0iVGFob21hIj48Yj5Gcm9tOjwvYj4gUmFkaWEgUGVybG1hbiBbbWFpbHRv OnJhZGlhcGVybG1hbkBnbWFpbC5jb21dDQo8Yj48YnI+DQpTZW50OjwvYj4gRnJpZGF5LCBGZWJy dWFyeSAyNCwgMjAxMiA5OjIzIEFNPGI+PGJyPg0KVG86PC9iPiBUaXNzYSBTZW5ldmlyYXRobmUg KHRzZW5ldmlyKTxiPjxicj4NCkNjOjwvYj4gaHUuZmFuZ3dlaUB6dGUuY29tLmNuOyByYnJpZGdl QHBvc3RlbC5vcmc7IHJicmlkZ2UtYm91bmNlc0Bwb3N0ZWwub3JnPGI+PGJyPg0KU3ViamVjdDo8 L2I+IFJlOiBbcmJyaWRnZV0gRGVmYXVsdCBuaWNrbmFtZSBiYXNlIGFwcHJvYWNoIGZvciBtdWx0 aWxldmVsDQpUUklMTC0gZHJhZnQtdGlzc2EtdHJpbGwtbXVsdGlsZXZlbC0wMC50eHQ8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD4NCjxicj48 Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+SSBhc3N1bWUgdGhhdCBhbGwgUkJyaWRnZXMg d2lsbCBuZWVkDQp0byBiZSBpbiBhbGwgdG9wb2xvZ2llcywgc28gbXVsdGl0b3BvbG9neSB3aWxs IG5vdCBoZWxwIHdpdGggbmlja25hbWUgZXhoYXVzdGlvbi4NCiZuYnNwO1BsdXMgeW91IGhhdmVu J3QgZXhwbGFpbmVkIGhvdyBhIFRSSUxMIHBhY2tldCB3b3VsZCBiZSBtYXJrZWQgYXMNCnRvIHdo aWNoIHRvcG9sb2d5IHRoZSBwYWNrZXQgc2hvdWxkIGJlIHJvdXRlZCBhY2NvcmRpbmcgdG8gKG90 aGVyIHRoYW4NCndoYXQgSSBtZW50aW9uZWQsIHdoaWNoIGFjdHVhbGx5IGVhdHMgdXAgbmlja25h bWVzIGJ5IGEgZmFjdG9yIG9mIHRoZSBudW1iZXINCm9mIHRvcG9sb2dpZXMgc3VwcG9ydGVkKS48 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD4N Cjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+UGx1cywgcmF0aGVyIHRoYW4ganVz dCBsdW1waW5nIHBvdGVudGlhbA0KaXNzdWVzIGludG8gYSBwaHJhc2Ugc3VjaCBhcyAmcXVvdDtO QVQtbGlrZSZxdW90OywgYmUgZXhwbGljaXQgYWJvdXQgd2hhdA0KaXNzdWVzIHRoZXJlIGFjdHVh bGx5IGFyZS4gJm5ic3A7SSBiZWxpZXZlIHRoZSBGdWxjcnVtIGNoaXAgd291bGQgaGF2ZQ0Kbm8g cHJvYmxlbSB3aXRoIHRyYW5zbGF0aW5nIHRoZSBuaWNrbmFtZSBmaWVsZHMuPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPkFuZCByYXRoZXIgdGhhbiBhc3N1bWluZyB0aGF0IG5p Y2tuYW1lDQpleGhhdXN0aW9uIGNhbiBiZSBzb2x2ZWQgJnF1b3Q7c29tZSBvdGhlciB3YXkmcXVv dDssIHRoZXJlIHNob3VsZCBiZSBhDQpwYWxhdGFibGUgc29sdXRpb24gYmVmb3JlIHJlamVjdGlu ZyBhIGNoYW5jZSB0byBzb2x2ZSBpdCB3aXRoIG11bHRpbGV2ZWwuPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0z IGZhY2U9InNhbnMtc2VyaWYiPlJhZGlhPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJz YW5zLXNlcmlmIj4yMDEyLzIvMjQgVGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZpcikNCiZsdDs8 L2ZvbnQ+PGEgaHJlZj1tYWlsdG86dHNlbmV2aXJAY2lzY28uY29tPjxmb250IHNpemU9MyBjb2xv cj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1PnRzZW5ldmlyQGNpc2NvLmNvbTwvdT48L2ZvbnQ+ PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7PC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPkJlY2F1c2UgeW91IGNhbiBoYXZl IHNhbWUNCm5pY2tuYW1lIGZvciBkaWZmZXJlbnQgdG9wb2xvZ3kuIEl0IGlzIG5vdCBhIG5pY2tu YW1lIHRoYXQgd2lsbCBpZGVudGlmeQ0KYW4gUkJSaWRnZSwgaXQgaXMgdG9wb2xvZ3ksbmlja25h bWUgY29tYmluYXRpb24gdGhhdCB3aWxsIGlkZW50aWZ5IGFuIFJCUmlkZ2UuDQpTbyBSQjEgY2Fu IGhhdmUgbmlja25hbWUgMSBpbiB0b3BvLTEgYW5kIFJCMiBjYW4gaGF2ZSBuaWNrbmFtZSAxIGlu IHRvcG8yLg0KTm93IHRvdGFsIG5pY2tuYW1lcyBpbiB0aGUgY2FtcHVzIGlzIDIqKjE2IHggdG9w b2xvZ2llcy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2Fs aWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9 IkNhbGlicmkiPlN0ZWFsaW5nIGJpdHMgdG8gcmVwcmVzZW50DQp0b3BvIGlkIGlzIG9ubHkgYSB3 b3JrYXJvdW5kIHRoZXJlIGNhbiBiZSAoYXJlICkgbW9yZSBlbGVnYW50IHdheXMgb2YgZG9pbmcN Cml0IHRoYXQuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNh bGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNl PSJDYWxpYnJpIj5Cb3R0b20gbGluZSBpcyB3ZSBuZWVkIHRvDQpsb29rIGZvciBtb3JlIGNyZWF0 aXZlIG1ldGhvZHMgb2Ygc29sdmluZyBuaWNrbmFtZSBzcGFjZSBpc3N1ZSB0aGFuIGRvaW5nDQpO QVQgbGlrZSBiZWhhdmlvci4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdk IGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iVGFo b21hIj48Yj5Gcm9tOjwvYj4gUmFkaWEgUGVybG1hbiBbbWFpbHRvOjwvZm9udD48YSBocmVmPW1h aWx0bzpyYWRpYXBlcmxtYW5AZ21haWwuY29tIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0yIGNv bG9yPWJsdWUgZmFjZT0iVGFob21hIj48dT5yYWRpYXBlcmxtYW5AZ21haWwuY29tPC91PjwvZm9u dD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+XQ0KPGI+PGJyPg0KU2VudDo8L2I+IEZy aWRheSwgRmVicnVhcnkgMjQsIDIwMTIgOTowNSBBTTxiPjxicj4NClRvOjwvYj4gVGlzc2EgU2Vu ZXZpcmF0aG5lICh0c2VuZXZpcik8Yj48YnI+DQpDYzo8L2I+IDwvZm9udD48YSBocmVmPW1haWx0 bzpodS5mYW5nd2VpQHp0ZS5jb20uY24gdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTIgY29sb3I9 Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1Pmh1LmZhbmd3ZWlAenRlLmNvbS5jbjwvdT48L2ZvbnQ+PC9h Pjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjsNCjwvZm9udD48YSBocmVmPW1haWx0bzpyYnJp ZGdlQHBvc3RlbC5vcmcgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNl PSJUYWhvbWEiPjx1PnJicmlkZ2VAcG9zdGVsLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9 MiBmYWNlPSJUYWhvbWEiPjsNCjwvZm9udD48YSBocmVmPSJtYWlsdG86cmJyaWRnZS1ib3VuY2Vz QHBvc3RlbC5vcmciIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0i VGFob21hIj48dT5yYnJpZGdlLWJvdW5jZXNAcG9zdGVsLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250 IHNpemU9MiBmYWNlPSJUYWhvbWEiPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJU YWhvbWEiPjxiPjxicj4NClN1YmplY3Q6PC9iPiBSZTogW3JicmlkZ2VdIERlZmF1bHQgbmlja25h bWUgYmFzZSBhcHByb2FjaCBmb3IgbXVsdGlsZXZlbA0KVFJJTEwtIGRyYWZ0LXRpc3NhLXRyaWxs LW11bHRpbGV2ZWwtMDAudHh0PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNl cmlmIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPkkg ZG9uJ3QgdW5kZXJzdGFuZCBob3cgbXVsdGktdG9wb2xvZ3kNCmhlbHBzIHdpdGggdGhlIG5pY2tu YW1lIGV4aGF1c3Rpb24gaXNzdWUuICZuYnNwO0FzIGEgbWF0dGVyIG9mIGZhY3QsIHRoZQ0Kb25s eSBwbGF1c2libGUgd2F5IG9mIG1hcmtpbmcgYSBwYWNrZXQgZm9yIHdoaWNoIHRvcG9sb2d5IHRo YXQgaGFzIGJlZW4NCnN1Z2dlc3RlZCBvbiB0aGUgbWFpbGluZyBsaXN0IChJIGFza2VkIGEgZWZ3 IHRpbWVzIGlmIHRoZXJlIHdlcmUgYW55IG90aGVyDQpwb3NzaWJpbGl0aWVzKSwgd2FzIHRvIHN0 ZWFsIDIgb3IgMyBiaXRzIG9mIHRoZSBuaWNrbmFtZSB0byBlbmNvZGUgd2hpY2gNCnRvcG9sb2d5 LCBpbiBlZmZlY3QsIG1ha2luZyBhIGRlc3RpbmF0aW9uIGFwcGVhciBhcyBtdWx0aXBsZSBkZXN0 aW5hdGlvbnMNCmFuZCBtdWx0aXBsZSBmb3J3YXJkaW5nIHRhYmxlIGVudHJpZXMgKHdoaWNoIHlv dSdkIHdhbnQgYW55d2F5LCBmb3IgbXVsdGl0b3BvbG9neSkuPC9mb250Pg0KPGJyPjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZh Y2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fu cy1zZXJpZiI+UmFkaWE8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYi PjIwMTIvMi8yNCBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKQ0KJmx0OzwvZm9udD48YSBo cmVmPW1haWx0bzp0c2VuZXZpckBjaXNjby5jb20gdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMg Y29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT50c2VuZXZpckBjaXNjby5jb208L3U+PC9m b250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0OzwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5NdXRsaS10b3BvbG9neSBp cyB0aGUgYW5zd2VyDQp0byBpbmNyZWFzZSB0aGUgbmlja25hbWUgc3BhY2UuPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5OaWNrbmFtZSB0 cmFuc2xhdGlvbiBpcyB2ZXJ5DQpzaW1pbGFyIHRvIE5BVCwgd2hpY2ggaGFzIGl0oa9zIG93biBk b3duIHNpZGUsIG5vdCB0byBtZW50aW9uIHNwZWNpYWwNCmhhcmR3YXJlIGV0Yy4gdG8gZG8gdGhl IHRyYW5zbGF0aW9ucywgYWRkaXRpb25hbGx5LiBXZSBhbHNvIGtub3cgZnJvbSBvdXINCmV4cGVy aWVuY2UsIGluIElQIHdvcmxkIE5BVGluZyBpcyBub3QgdGhlIG1vc3QgZGVzaXJlZCBiZWhhdmlv ciBhbmQgd2UNCmxpdmUgd2l0aCBpdC4gU28gd2Ugc2hvdWxkIG5vdCBiZSBnb2luZyBkb3duIHRo YXQgcGF0aCBpbnN0ZWFkIG5lZWQgdG8NCmxvb2sgZm9yd2FyZCBmcm9tIHRoYXQgZXhwZXJpZW5j ZS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+ Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGli cmkiPk11bHRpLXRvcG9sb2d5IG5vdCBvbmx5IGFkZHJlc3MNCm5pY2tuYW1lIHNwYWNlIGlzc3Vl IGJ1dCBhbHNvIGVuYWJsZXMgdmFyaW91cyBvdGhlciBhcHBsaWNhdGlvbnMgc3VjaCBhcw0Kb3Zl cmxheSB0b3BvbG9naWVzLCB0cmFmZmljIGVuZ2luZWVyaW5nLjwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+VGhlIGRyYWZ0LXRpc3MtdHJp bGwtbXVsdGlsZXZlbA0KcHJlc2VudCBhcHByb2FjaGVzIHRoYXQgYXJlIGdlbmVyaWMsIHdoaWNo IG1lYW4gaXQgY2FuIGJlIGFwcGxpZWQgZm9yIG11bHRpLXRvcG9sb2d5LA0Kb3IgYmFzZSB0b3Bv bG9neS4gSXQgdXRpbGl6ZXMgdGhlIGZ1bmRhbWVudGFscyBvZiBJUy1JUyAsIHN1Y2ggYXMgQXJl YQ0KaGllcmFyY2h5IGZvciByZWR1Y3Rpb24gb2YgdGhlIExTUC1EQi4gSXQgdXRpbGl6ZSBhZmZp bml0eSBUTFYgY29uY2VwdHMNCnRvIGVmZmVjdGl2ZWx5IHNvbHZlIG11bHRpLWRlc3RpbmF0aW9u IGlzc3Vlcy4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNh bGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNl PSJDYWxpYnJpIj5XZSBzaG91bGQgbm90IG1peC11cCBiZXR3ZWVuDQpEYXRhIGNlbnRlciBpbnRl cmNvbm5lY3RzIHdpdGggZGF0YSBjZW50ZXIgbm9kZSBzY2FsaW5nLiBUaGV5IGFyZSB0d28gZGlm ZmVyZW50DQphbmQgb3J0aG9nb25hbCBpc3N1ZXMuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBj b2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5PYmplY3RpdmUgb2YgbXVsdGktbGV2ZWwN CnRyaWxsIGlzIHRvIGludGVyY29ubmVjdCBkaWZmZXJlbnQgZGF0YWNlbnRlcnMsIGFuZCBtYWlu dGFpbiBMU1AtREIgc21hbGwNCmFzIHBvc3NpYmxlIHRvIGF2b2lkIHNjYWxpbmcgYW5kIHZvbGF0 aWxpdHkuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGli cmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJD YWxpYnJpIj5JbmNyZWFzaW5nIG5pY2tuYW1lIHNwYWNlDQphIGRpZmZlcmVudCByZXF1aXJlbWVu dCBhbmQgaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCBkYXRhLWNlbnRlciBpbnRlcmNvbm5lY3RzLjwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4mbmJz cDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+ Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxiPkZyb206PC9i PiBSYWRpYSBQZXJsbWFuIFttYWlsdG86PC9mb250PjxhIGhyZWY9bWFpbHRvOnJhZGlhcGVybG1h bkBnbWFpbC5jb20gdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJU YWhvbWEiPjx1PnJhZGlhcGVybG1hbkBnbWFpbC5jb208L3U+PC9mb250PjwvYT48Zm9udCBzaXpl PTIgZmFjZT0iVGFob21hIj5dDQo8Yj48YnI+DQpTZW50OjwvYj4gRnJpZGF5LCBGZWJydWFyeSAy NCwgMjAxMiA2OjE1IEFNPGI+PGJyPg0KVG86PC9iPiA8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86aHUu ZmFuZ3dlaUB6dGUuY29tLmNuIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUg ZmFjZT0iVGFob21hIj48dT5odS5mYW5nd2VpQHp0ZS5jb20uY248L3U+PC9mb250PjwvYT48Zm9u dCBzaXplPTIgZmFjZT0iVGFob21hIj48Yj48YnI+DQpDYzo8L2I+IFRpc3NhIFNlbmV2aXJhdGhu ZSAodHNlbmV2aXIpOyA8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86cmJyaWRnZUBwb3N0ZWwub3JnIHRh cmdldD1fYmxhbms+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVGFob21hIj48dT5yYnJp ZGdlQHBvc3RlbC5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj47 DQo8L2ZvbnQ+PGEgaHJlZj0ibWFpbHRvOnJicmlkZ2UtYm91bmNlc0Bwb3N0ZWwub3JnIiB0YXJn ZXQ9X2JsYW5rPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+cmJyaWRn ZS1ib3VuY2VzQHBvc3RlbC5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFo b21hIj48Yj48YnI+DQpTdWJqZWN0OjwvYj4gUmU6IFtyYnJpZGdlXSBEZWZhdWx0IG5pY2tuYW1l IGJhc2UgYXBwcm9hY2ggZm9yIG11bHRpbGV2ZWwNClRSSUxMLSBkcmFmdC10aXNzYS10cmlsbC1t dWx0aWxldmVsLTAwLnR4dDwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJp ZiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5QZW9w bGUgaGF2ZSBtZW50aW9uZWQgdG8gbWUgdGhhdCB0aGV5DQphcmUgbmVydm91cyBhYm91dCBydW5u aW5nIG91dCBvZiBuaWNrbmFtZXMsIGVzcGVjaWFsbHkgc2luY2UgdGhlcmUgYXJlDQpyZWFzb25z b24gd2h5IHRoZXkgbWlnaHQgd2FudCB0byBhc3NpZ24gbmlja25hbWVzIHRvIGh5cGVydmlzb3Jz LiAmbmJzcDtXaXRoDQp0aGUgYWx0ZXJuYXRlIGFwcHJvYWNoIG9mIGFsbG93aW5nIG5pY2tuYW1l cyB0byBiZSByZXVzZWQgaW4gZGlmZmVyZW50DQphcmVhcywgaXQgbWFrZXMgYXV0b21hdGljIG5p Y2tuYW1lIGFzc2lnbm1lbnQgbXVjaCBzaW1wbGVyIGFuZCBtYWtlcyBUUklMTA0KYSBsb3QgbW9y ZSBzY2FsYWJsZS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZu YnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+SXQgZG9lcyBo YXZlIHRoZSBkb3duc2lkZSBvZiByZXF1aXJpbmcNCm1hcHBpbmcgb2Ygbmlja25hbWVzIGF0IHRo ZSBib3JkZXIgUkJyaWRnZXMuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNl cmlmIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPkFu ZCBieSB0aGUgd2F5LCB0aGUgYWZmaW5pdHkgVExWIGNhbg0KYmUgdXNlZCBmb3IgbXVsdGlkZXN0 aW5hdGlvbiBmcmFtZXMgdHJhbnNpdGluZyBiZXR3ZWVuIGxldmVsIDEgYW5kIGxldmVsDQoyLjwv Zm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0K PGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5SYWRpYTwvZm9udD4NCjxicj48Zm9u dCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMi8yLzIzICZsdDs8L2ZvbnQ+PGEgaHJlZj1t YWlsdG86aHUuZmFuZ3dlaUB6dGUuY29tLmNuIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNv bG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+aHUuZmFuZ3dlaUB6dGUuY29tLmNuPC91Pjwv Zm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZndDs8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj48YnI+DQpIaSwgVGlzc2EuPC9mb250Pjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPGJyPg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJB cmlhbCI+PGJyPg0KSSBoYXZlIHNldmVyYWwgY29tbWVudHMgYWJvdXQgdGhlIGRyYWZ0LjwvZm9u dD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGZhY2U9IkFyaWFsIj48YnI+DQooMSkgaW4gc2VjdGlvbiA0LjQgKE11bHRpY2FzdCksICZx dW90O1RoZSBzY29wZSBvZiBnbG9iYWwgdHJhZmZpYyBtYXkgYmUNCmlkZW50aWZpZWQgZWl0aGVy IHRocm91Z2ggVkxBTiBvciB2aWEgZmluZWdyYWluIDxicj4NCmxhYmVsIHRoYXQgc3BhbnMgYWNy b3NzIHRoZSBlbnRpcmUgVFJJTEwgY2FtcHVzLiZxdW90OzwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj48YnI+DQpW bGFuIGFuZCBGaW5lLWdyYWluIExhYmVsIGlzIHVzZWQgZm9yIHNlcnZpY2UgZGlmZmVyZW50aWF0 aW9uIGFuZCBpc29sYXRpb24uDQpJIGRvIG5vdCBxdWl0ZSB1bmRlcnN0YW5kIHRoYXQgaG93IHRv PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXpl PTMgZmFjZT0iQXJpYWwiPjxicj4NCnVzZSBWTEFOIGFuZCBmaW5lLWdyYWluIExhYmxlIHRvIGlk ZW50aWZ5IHRoZSB0cmFmZmljIHNjb3BlLiBUaGUgZGF0YSB0cmFmZmljDQp3aXRoIGEgZ2l2ZW4g VkxBTi14LCBjYW4gPGJyPg0KYmUgZm9yd2FyZGVkIHRvIG90aGVyIGVuZCBzdGF0aW9uIGluIHRo ZSBsb2NhbCBhcmVhLCBvciB0byB0aGUgZW5kIHN0YXRpb24NCmluIHJlbW90ZSBhcmVhcy4gPC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGZhY2U9IkFyaWFsIj48YnI+DQooMikgbmlja25hbWUgYWxsb2NhdGlvbjwvZm9udD48Zm9u dCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQXJp YWwiPjxicj4NClRoZSBuaWNrbmFtZSBtYW5hZ2VtZW50IHN1Yi1UTFYgaXMgcHJvcG9zZWQgaW4g dGhlIGRvY3VtZW50LiBJIHdvbmRlciB0aGlzDQptZWNoYW5pc20gYWRkcyB0aGUgY29tcGxpY2F0 aW9uIG9mICZuYnNwOzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2Zv bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj48YnI+DQpuaWNrbmFtZSBhbGxvY2F0aW9uLiBB cyB0aGUgc2VjdGlvbiAxIChpbnRyb2R1Y3Rpb24pIG9mIFJGQzYzMjUsIG9uZSBvZg0KdGhlIGlt cG9ydGFudCBhZHZhbnRhZ2Ugb2YgVFJJTEwgaXMgdGhhdCAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJBcmlhbCI+ PGJyPg0KaXQgYXZvaWRzIHRoZSBjcmVhdGluZyBzdWJuZXRzIG9mIElQIGFkZHJlc3MgYW5kIHdh c3RpbmcgYWRkcmVzcy4gVGhlIG5pY2tuYW1lDQphY3F1aXNpdGlvbiAmbmJzcDttZXRob2QgaW4g dGhpcyBkcmFmdCB2aW9sYXRlcyB0aGUgJm5ic3A7PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJz YW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPjxicj4NCmlkZWEg b2YgVFJJTEwgQmFzaWMgc3BlY2lmaWNhdGlvbiwgYW5kIHJlZHVjZXMgdGhlIGZsZXhpYmlsaXR5 IG9mIG5pY2tuYW1lDQphbGxvY2F0aW9uLiBBcyB0aGUgZHJhZnQgYXNzdW1lZCwgQTEgaGFkICZu YnNwOzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9IkFyaWFsIj48YnI+DQpuaWNrbmFtZSByYW5nZSBvZiAxMDAtMjAwLCBBMiBo YXMgYSBsb2NhbCBuaWNrbmFtZSByYW5nZSBvZiAyMDEtMzAwLiBJZg0KdGhlIG51bWJlcnMgb2Yg QTEgYXJlYSBpcyBvbmx5IDUwLCBzbyA1MCAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJBcmlhbCI+PGJyPg0Kbmlj a25hbWVzIGluIEExIGlzIHdhc3RlZC4gQXMgdGhlIG5ldHdvcmsgZ3Jvd2luZywgdGhlIG51bWJl ciBvZiBzb21lIGFyZWFzDQptYXkgZXhjZWVkIHRoZSBudW1iZXIgYmVpbmcgYWxsb2NhdGlvbiAm bmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250 IHNpemU9MyBmYWNlPSJBcmlhbCI+PGJyPg0KYnkgQm9yZGVyIFJCcmlkZ2VzLiBUaGUgZGVzaWdu IGFuZCBtYWludGFpbmluZyBvZiBuaWNrbmFtZSByYW5nZXMgZm9yIGVhY2gNCmFyZWEgaXMgYSB2 ZXJ5IGhhcmQgd29yay4gRXZlbiB3b3JzdCwgaXQgJm5ic3A7PC9mb250Pjxmb250IHNpemU9MyBm YWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPjxicj4N CmNhbiBub3QgYXZvaWQgdG8gd2FzdGUgbmlja25hbWUgc3BhY2UuPC9mb250Pjxmb250IHNpemU9 MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQXJp YWwiPjxicj4NCigzKSBEeW5hbWljIHJhbmdlcyA8YnI+DQogVGhlIG5pY2tuYW1lIHJhbmdlIGlz IGRpdmlkZWQgaW50byB0d28gcmFuZ2U6IGxvY2FsIHJhbmdlIGFuZCBkeW5hbWljYWwNCnJhbmdl LiBJIHdvbmRlciB0aGUgbmlja25hbWUgY29uZmxpY3QgJm5ic3A7PC9mb250Pjxmb250IHNpemU9 MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPjxi cj4NCnJlc29sdXRpb24gY2FuIG5vdCB3b3JrIGlmIHRoZSBSQnJpZGdlIGdldCB0aGUgbmlja25h bWUgZnJvbSB0aGUgZHluYW1pY2FsDQpyYW5nZSB3aGlsZSB0aGUgdHdvIFJCcmlkZ2UgYmVsb25n cyB0byAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250 Pjxmb250IHNpemU9MyBmYWNlPSJBcmlhbCI+PGJyPg0KZGlmZmVyZW50IGFyZWFzLiBGb3IgZXhh bXBsZSwgUkIxIGlzIGluIGFyZWEgQTEsIGFuZCBSQjIgaXMgaW4gYXJlYSBBMi4NCklmIFJCMSBn ZXRzIHRoZSBuaWNrbmFtZSBOMSBmcm9tIGR5bmFtaWMgJm5ic3A7PC9mb250Pjxmb250IHNpemU9 MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPjxi cj4NCnJhbmdlLCBhbmQgaXQgd2lsbCBmbG9vZHMgaW4gYXJlYSBBMSwgYW5kIG90aGVyIFJCcmlk Z2VzIGluIGFyZWEgQTEgY2FuDQpub3QgZ2V0IG5pY2tuYW1lIE4xIGJlY2F1c2Ugb2Ygbmlja25h bWUgJm5ic3A7PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPjxicj4NCmNvbmZsaWN0aW9uIG1lY2hhbmlzbSwgYnV0 IFJCMiBpbiBhcmVhIEEyIGNhbiBub3QgcmVjZWl2ZSB0aGUgUERVIGZyb20NClJCMSwgYW5kIGl0 ICZuYnNwO2NhbiBhbHNvIGdldCB0aGUgbmlja25hbWUgTjEgZnJvbSAmbmJzcDs8L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJB cmlhbCI+PGJyPg0KZHluYW1pY2FsIHJhbmdlLiBTbyB0aGUgcXVlc3Rpb24gaXMgaG93IHRvIGF2 b2lkIHRoZSBkdXBsaWNhdGlvbiBkeW5hbWljYWwNCnJhbmdlIG5pY2tuYW1lIGZvciBkaWZmZXJl bnQgYXJlYXMuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjxicj4NCjwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPjxicj4NCig0KSBUaGUgcmlzayBvZiBydW5u aW5nIG91dCBvZiBuaWNrbmFtZSBtYXliZSBhIGlzc3VlIGZvciBUUklMTC4gVGhlIG51bWJlcg0K b2YgMioqMTYgbmlja25hbWUgaXMgZW5vdWdoIGZvciB0aGUgY3VycmVudCBkYXRhIGNlbnRlciw8 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9 MyBmYWNlPSJBcmlhbCI+PGJyPg0KIGJ1dCBpdCBtYXliZSBub3QgZW5vdWdoIGluIHRoZSBmdXR1 cmUsIGVzcGVjYWlsbHkgaWYgVFJJTEwgb3ZlciBJUCAsIFRSSUxMDQpvdmVyIE1QTFMgdGVjaG5v bG9neSBvciBzb21lIG90aGVyIGRhdGEgY2VudGVyIHRlY2hub2xvZ2llczwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFs Ij48YnI+DQogYXJlIGRlcGxveWVkLCB0aGUgZGF0YSBjZW50ZXIgbmV0d29yayBjYW4gYmUgYSB2 ZXJ5IGxhcmRnZSBuZXR3b3JrLiBTbw0KaSB0aGluayB0aGUgdmVyeSBpbXBvcnRhbnQgYW5kIGVz c2VudGlhbCBnb2FsIG9mIG11bHRpLWxldmVsIGRyYWZ0IGlzIHRvDQpzYXZlIG5pY2tuYW1lcy48 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8YnI+DQo8L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9IkFyaWFsIj48YnI+DQpCZXN0IHJlZ2FyZHM8L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj48YnI+ DQpGYW5nd2VpIEh1PC9mb250Pg0KPHA+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249 dG9wPg0KPHRkIHdpZHRoPTM3JT48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPjxiPiZxdW90O1Rp c3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpJnF1b3Q7DQombHQ7PC9iPjwvZm9udD48YSBocmVm PW1haWx0bzp0c2VuZXZpckBjaXNjby5jb20gdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTEgY29s b3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PGI+PHU+dHNlbmV2aXJAY2lzY28uY29tPC91PjwvYj48L2Zv bnQ+PC9hPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+PGI+Jmd0OzwvYj4NCjwvZm9udD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0Kt6K8/sjLPC9mb250Pjxmb250IHNpemU9 MSBmYWNlPSJBcmlhbCI+OiAmbmJzcDs8L2ZvbnQ+PGEgaHJlZj0ibWFpbHRvOnJicmlkZ2UtYm91 bmNlc0Bwb3N0ZWwub3JnIiB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZh Y2U9IkFyaWFsIj48dT5yYnJpZGdlLWJvdW5jZXNAcG9zdGVsLm9yZzwvdT48L2ZvbnQ+PC9hPjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MSBm YWNlPSJBcmlhbCI+MjAxMi0wMi0yMyAxMTo1NTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fu cy1zZXJpZiI+DQo8L2ZvbnQ+DQo8dGQgd2lkdGg9NjElPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEw MCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0xNyU+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQgd2lk dGg9ODIlPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+Jmx0OzwvZm9udD48YSBocmVmPW1haWx0 bzpyYnJpZGdlQHBvc3RlbC5vcmcgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTEgY29sb3I9Ymx1 ZSBmYWNlPSJBcmlhbCI+PHU+cmJyaWRnZUBwb3N0ZWwub3JnPC91PjwvZm9udD48L2E+PGZvbnQg c2l6ZT0xIGZhY2U9IkFyaWFsIj4mZ3Q7PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNl cmlmIj4NCjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD4NCjx0 ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0iQXJp YWwiPltyYnJpZGdlXSBEZWZhdWx0IG5pY2tuYW1lIGJhc2UgYXBwcm9hY2gNCmZvciBtdWx0aWxl dmVsIFRSSUxMLSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkcmFmdC10aXNzYS10cmlsbC1t dWx0aWxldmVsLTAwLnR4dDwvZm9udD48L3RhYmxlPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJz YW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+DQo8cD4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0K PHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9NTAlPg0KPHRkIHdpZHRoPTUwJT48L3RhYmxlPg0K PGJyPg0KPHRkIHdpZHRoPTElPjwvdGFibGU+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMt c2VyaWYiPjxicj4NCjxicj4NCjxicj4NCkRlYXIgQWxsPGJyPg0KPGJyPg0KV2UgaGF2ZSBzdWJt aXR0ZWQgZHJhZnQtdGlzc2EtdHJpbGwtbXVsdGlsZXZlbCwgcHJlc2VudCBtdWx0aWxldmVsIFRS SUxMDQpiYXNlZCBvbiBkZWZhdWx0IG5pY2tuYW1lIGFwcHJvYWNoLiBBZGRpdGlvbmFsbHkgd2Ug ZGlzY3VzcyBjb25zdHJ1Y3Rpb24NCm9mIG11bHRpLWRlc3RpbmF0aW9uIHRyZWVzIGFuZCByZWxh dGVkIFJQRiBpbiBtdWx0aWxldmVsIFRSSUxMLiBQbGVhc2UNCmNvdWxkIHlvdSByZXZpZXcgYW5k IGNvbW1lbnQgPGJyPg0KPGJyPg0KRGV0YWlsIG9mIHRoZSBkcmFmdCBhbmQgYWJzdHJhY3QgYXJl IGJlbG93Ljxicj4NCjxicj4NCkZpbGVuYW1lOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RyYWZ0LXRpc3NhLXRyaWxsLW11bHRp bGV2ZWw8YnI+DQpSZXZpc2lvbjogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDswMDxicj4NClRpdGxlOiAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBEZWZhdWx0IE5p Y2tuYW1lIEJhc2VkDQpBcHByb2FjaCBmb3IgTXVsdGlsZXZlbCBUUklMTDxicj4NCkNyZWF0aW9u IGRhdGU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsNCiZuYnNwOzIwMTItMDItMjE8YnI+DQpXRyBJRDogJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSW5kaXZpZHVhbCBTdWJt aXNzaW9uPGJyPg0KTnVtYmVyIG9mIHBhZ2VzOiAyNjxicj4NCjxicj4NCkFic3RyYWN0Ojxicj4N CiAmbmJzcDtNdWx0aWxldmVsIFRSSUxMIGFsbG93cyB0aGUgaW50ZXJjb25uZWN0aW9uIG9mIG11 bHRpcGxlIFRSSUxMPGJyPg0KICZuYnNwO25ldHdvcmtzIHRvIGZvcm0gYSBsYXJnZXIgVFJJTEwg bmV0d29yayB3aXRob3V0IHByb3BvcnRpb25hbGx5PGJyPg0KICZuYnNwO2luY3JlYXNpbmcgdGhl IHNpemUgb2YgdGhlIElTLUlTIExTUCBEQi4gSW4gdGhpcyBkb2N1bWVudCwgYW48YnI+DQogJm5i c3A7YXBwcm9hY2ggYmFzZWQgb24gZGVmYXVsdCByb3V0ZSBjb25jZXB0IGlzIHByZXNlbnRlZC4g QWxzbyw8YnI+DQogJm5ic3A7cHJlc2VudGVkIGluIHRoZSBkb2N1bWVudCBpcyBhIG5vdmVsIG1l dGhvZCBvZiBjb25zdHJ1Y3RpbmcgbXVsdGktPGJyPg0KICZuYnNwO2Rlc3RpbmF0aW9uIHRyZWVz IHVzaW5nIHBhcnRpYWwgbmlja25hbWUgc3BhY2UuIE1ldGhvZHMgcHJlc2VudGVkDQppbjxicj4N CiAmbmJzcDt0aGlzIGRvY3VtZW50IGFyZSBjb21wYXRpYmxlIHdpdGggdGhlIFJGQzYzMjUgc3Bl Y2lmaWVkIGRhdGEgcGxhbmU8YnI+DQogJm5ic3A7b3BlcmF0aW9ucy48YnI+DQo8YnI+DQogJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxicj4N ClRoYW5rczxicj4NClRpc3NhPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQpyYnJpZGdlIG1haWxpbmcgbGlzdDwvZm9udD48Zm9u dCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT48YnI+DQo8L3U+PC9mb250 PjxhIGhyZWY9bWFpbHRvOnJicmlkZ2VAcG9zdGVsLm9yZyB0YXJnZXQ9X2JsYW5rPjxmb250IHNp emU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1PnJicmlkZ2VAcG9zdGVsLm9yZzwv dT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1 Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj1odHRwOi8vbWFpbG1hbi5wb3N0ZWwub3JnL21haWxt YW4vbGlzdGluZm8vcmJyaWRnZSB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVl IGZhY2U9InNhbnMtc2VyaWYiPjx1Pmh0dHA6Ly9tYWlsbWFuLnBvc3RlbC5vcmcvbWFpbG1hbi9s aXN0aW5mby9yYnJpZGdlPC91PjwvZm9udD48L2E+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KcmJyaWRnZSBtYWlsaW5nIGxpc3Q8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9y PWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+PGJyPg0KPC91PjwvZm9udD48YSBocmVmPW1haWx0 bzpyYnJpZGdlQHBvc3RlbC5vcmcgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1 ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5yYnJpZGdlQHBvc3RlbC5vcmc8L3U+PC9mb250PjwvYT48 Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT48YnI+DQo8L3U+PC9m b250PjxhIGhyZWY9aHR0cDovL21haWxtYW4ucG9zdGVsLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Ji cmlkZ2UgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNl cmlmIj48dT5odHRwOi8vbWFpbG1hbi5wb3N0ZWwub3JnL21haWxtYW4vbGlzdGluZm8vcmJyaWRn ZTwvdT48L2ZvbnQ+PC9hPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJz cDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9u dD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pjxmb250 IHNpemU9Mj48dHQ+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpyYnJpZGdlIG1haWxpbmcgbGlzdDxicj4NCnJicmlkZ2VAcG9zdGVsLm9yZzxicj4N Cmh0dHA6Ly9tYWlsbWFuLnBvc3RlbC5vcmcvbWFpbG1hbi9saXN0aW5mby9yYnJpZGdlPGJyPg0K PC90dD48L2ZvbnQ+DQo8YnI+DQo= --=_alternative 000F90ED482579B1_=-- --===============1250075799== 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 --===============1250075799==-- From rbridge-bounces@postel.org Sun Feb 26 19:43: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 7D29E21F849D for ; Sun, 26 Feb 2012 19:43:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.827 X-Spam-Level: X-Spam-Status: No, score=-4.827 tagged_above=-999 required=5 tests=[AWL=-0.680, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Atgf-nL4URkA for ; Sun, 26 Feb 2012 19:43:07 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 8F08B21F849C for ; Sun, 26 Feb 2012 19:43:07 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1R2mx22029971; Sun, 26 Feb 2012 18:49:01 -0800 (PST) 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 q1R2mKKZ029621 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sun, 26 Feb 2012 18:48:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tsenevir@cisco.com; l=48105; q=dns/txt; s=iport; t=1330310909; x=1331520509; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=RI+fwym7jNiRk3DDCD2n/JPL0PrWh/wkeztKsnAF9Xg=; b=QG/fFzn4kAWIofyZZzq1HAMe4bhw9BWOMrUi5VbT7o6N1I4xDOHCe40L d24cao+eNS1DILF0AOIvgdh9pL1dTiytzmAAkYf77cvTwb+nR0iM8OQ9G /SzLOBvp9IjFyMjb1lQP8hAk0iCtTRmx8zRVnu5UQncFMT3+8sfdWme46 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcFAIHuSk+rRDoG/2dsb2JhbAA5CoJRgmilAAGJDYEHgXMBAQEEAQEBDwEHAhEDPgsQAgEGAhEEAQELBhABAgQBBAIBIAYfCQgBAQQBEggTB4djAQugXwGMXwiJMokPYYMeAQQDAQEBAQMBAwEEAQQFAQEBAQEEBUmEXQUIFgoOHgMFBgMDAQMGAQEKDQEGCwQUghM3YwSIT5gFh3iBMwU X-IronPort-AV: E=Sophos;i="4.73,488,1325462400"; d="scan'208,217";a="32667844" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 27 Feb 2012 02:48:19 +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 q1R2mIQG019882; Mon, 27 Feb 2012 02:48:18 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, 26 Feb 2012 18:48:18 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 26 Feb 2012 18:48:17 -0800 Message-ID: <344037D7CFEFE84E97E9CC1F56C5F4A5A46675@xmb-sjc-214.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.txt Thread-Index: Acz0+DZ+CUeRt0ttTEWi4bo82NaKeQAAEv/g References: From: "Tissa Senevirathne (tsenevir)" To: , "Radia Perlman" X-OriginalArrivalTime: 27 Feb 2012 02:48:18.0937 (UTC) FILETIME=[42F6BE90:01CCF4FA] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: tsenevir@cisco.com Cc: rbridge@postel.org, rbridge-bounces@postel.org Subject: Re: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.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: multipart/mixed; boundary="===============1545176185==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org This is a multi-part message in MIME format. --===============1545176185== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCF4FA.42CA1EB2" This is a multi-part message in MIME format. ------_=_NextPart_001_01CCF4FA.42CA1EB2 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable Lets leave multi topology a side for a moment. There are two broad = questions here: =20 1. Multi-level TRILL 2. Increase nickname space for TRILL. =20 If #2 is an issue then that needed to be properly looked it in to. #1 = has nothing do with #2. Contention is advocating nickname translation as = the solution for #2. Like it was highlighted earlier, nickname = translation has issues related OAM, inability to apply specific security = policies and so on. =20 Multi-level solution presented in draft-tissa-trill-multilevel does not = assume existence of any of the special feature, rather it provide data = center interconnect based on generic methods. =20 If #2 is an issue I suggest working group to prioritize the action and = work on it. =20 =20 From: hu.fangwei@zte.com.cn [mailto:hu.fangwei@zte.com.cn]=20 Sent: Sunday, February 26, 2012 6:33 PM To: Radia Perlman Cc: rbridge@postel.org; rbridge-bounces@postel.org; Tissa Senevirathne = (tsenevir) Subject: Re: Re: [rbridge] Default nickname base approach for multilevel = TRILL- draft-tissa-trill-multilevel-00.txt =20 I agree with Radia, and do not think that Multi-topology can slove the = nickname space issue.=20 There are two cases for MT (RFC5120):=20 (1) RBridge with Non-overlap nickname address. The nickname routes can = be installed into a shared nickname RIB table. And there is no need for = marking the data with different Topology. This situation can not help to = nickname exhaustion issue.=20 (2) RBridge with overlap nickname address. The RBridge can be assigned = the same nickname for different topology. But we should consider to mark = the data with different toplology. Besides the stealing bits methods, we = have no good ideas to do that. The stealing bits methods can not reudce = the nickname exhausting issue actually, because it reudce the valid = lengh of nickname.=20 Radia Perlman =20 2012-02-25 01:23=20 =CA=D5=BC=FE=C8=CB "Tissa Senevirathne (tsenevir)" =20 =B3=AD=CB=CD hu.fangwei@zte.com.cn, rbridge@postel.org, rbridge-bounces@postel.org=20 =D6=F7=CC=E2 Re: [rbridge] Default nickname base approach for multilevel TRILL- = draft-tissa-trill-multilevel-00.txt =20 =09 I assume that all RBridges will need to be in all topologies, so = multitopology will not help with nickname exhaustion. Plus you haven't = explained how a TRILL packet would be marked as to which topology the = packet should be routed according to (other than what I mentioned, which = actually eats up nicknames by a factor of the number of topologies = supported).=20 =20 Plus, rather than just lumping potential issues into a phrase such as = "NAT-like", be explicit about what issues there actually are. I believe = the Fulcrum chip would have no problem with translating the nickname = fields.=20 =20 And rather than assuming that nickname exhaustion can be solved "some = other way", there should be a palatable solution before rejecting a = chance to solve it with multilevel.=20 =20 Radia 2012/2/24 Tissa Senevirathne (tsenevir) >=20 Because you can have same nickname for different topology. It is not a = nickname that will identify an RBRidge, it is topology,nickname = combination that will identify an RBRidge. So RB1 can have nickname 1 in = topo-1 and RB2 can have nickname 1 in topo2. Now total nicknames in the = campus is 2**16 x topologies.=20 =20 Stealing bits to represent topo id is only a workaround there can be = (are ) more elegant ways of doing it that.=20 =20 Bottom line is we need to look for more creative methods of solving = nickname space issue than doing NAT like behavior.=20 =20 From: Radia Perlman [mailto:radiaperlman@gmail.com = ]=20 Sent: Friday, February 24, 2012 9:05 AM To: Tissa Senevirathne (tsenevir) Cc: hu.fangwei@zte.com.cn ; = rbridge@postel.org ; = rbridge-bounces@postel.org =20 Subject: Re: [rbridge] Default nickname base approach for multilevel = TRILL- draft-tissa-trill-multilevel-00.txt=20 =20 I don't understand how multi-topology helps with the nickname exhaustion = issue. As a matter of fact, the only plausible way of marking a packet = for which topology that has been suggested on the mailing list (I asked = a efw times if there were any other possibilities), was to steal 2 or 3 = bits of the nickname to encode which topology, in effect, making a = destination appear as multiple destinations and multiple forwarding = table entries (which you'd want anyway, for multitopology).=20 =20 =20 Radia=20 2012/2/24 Tissa Senevirathne (tsenevir) >=20 Mutli-topology is the answer to increase the nickname space.=20 =20 Nickname translation is very similar to NAT, which has it=A1=AFs own = down side, not to mention special hardware etc. to do the translations, = additionally. We also know from our experience, in IP world NATing is = not the most desired behavior and we live with it. So we should not be = going down that path instead need to look forward from that experience.=20 =20 Multi-topology not only address nickname space issue but also enables = various other applications such as overlay topologies, traffic = engineering.=20 =20 The draft-tiss-trill-multilevel present approaches that are generic, = which mean it can be applied for multi-topology, or base topology. It = utilizes the fundamentals of IS-IS , such as Area hierarchy for = reduction of the LSP-DB. It utilize affinity TLV concepts to effectively = solve multi-destination issues.=20 =20 We should not mix-up between Data center interconnects with data center = node scaling. They are two different and orthogonal issues.=20 =20 Objective of multi-level trill is to interconnect different datacenters, = and maintain LSP-DB small as possible to avoid scaling and volatility.=20 =20 Increasing nickname space a different requirement and has nothing to do = with data-center interconnects.=20 =20 =20 From: Radia Perlman [mailto:radiaperlman@gmail.com = ]=20 Sent: Friday, February 24, 2012 6:15 AM To: hu.fangwei@zte.com.cn =20 Cc: Tissa Senevirathne (tsenevir); rbridge@postel.org = ; rbridge-bounces@postel.org = =20 Subject: Re: [rbridge] Default nickname base approach for multilevel = TRILL- draft-tissa-trill-multilevel-00.txt=20 =20 People have mentioned to me that they are nervous about running out of = nicknames, especially since there are reasonson why they might want to = assign nicknames to hypervisors. With the alternate approach of = allowing nicknames to be reused in different areas, it makes automatic = nickname assignment much simpler and makes TRILL a lot more scalable.=20 =20 It does have the downside of requiring mapping of nicknames at the = border RBridges.=20 =20 And by the way, the affinity TLV can be used for multidestination frames = transiting between level 1 and level 2.=20 =20 Radia=20 2012/2/23 >=20 Hi, Tissa.=20 I have several comments about the draft.=20 (1) in section 4.4 (Multicast), "The scope of global traffic may be = identified either through VLAN or via finegrain=20 label that spans across the entire TRILL campus."=20 Vlan and Fine-grain Label is used for service differentiation and = isolation. I do not quite understand that how to=20 use VLAN and fine-grain Lable to identify the traffic scope. The data = traffic with a given VLAN-x, can=20 be forwarded to other end station in the local area, or to the end = station in remote areas.=20 (2) nickname allocation=20 The nickname management sub-TLV is proposed in the document. I wonder = this mechanism adds the complication of =20 nickname allocation. As the section 1 (introduction) of RFC6325, one of = the important advantage of TRILL is that =20 it avoids the creating subnets of IP address and wasting address. The = nickname acquisition method in this draft violates the =20 idea of TRILL Basic specification, and reduces the flexibility of = nickname allocation. As the draft assumed, A1 had =20 nickname range of 100-200, A2 has a local nickname range of 201-300. If = the numbers of A1 area is only 50, so 50 =20 nicknames in A1 is wasted. As the network growing, the number of some = areas may exceed the number being allocation =20 by Border RBridges. The design and maintaining of nickname ranges for = each area is a very hard work. Even worst, it =20 can not avoid to waste nickname space.=20 (3) Dynamic ranges=20 The nickname range is divided into two range: local range and dynamical = range. I wonder the nickname conflict =20 resolution can not work if the RBridge get the nickname from the = dynamical range while the two RBridge belongs to =20 different areas. For example, RB1 is in area A1, and RB2 is in area A2. = If RB1 gets the nickname N1 from dynamic =20 range, and it will floods in area A1, and other RBridges in area A1 can = not get nickname N1 because of nickname =20 confliction mechanism, but RB2 in area A2 can not receive the PDU from = RB1, and it can also get the nickname N1 from =20 dynamical range. So the question is how to avoid the duplication = dynamical range nickname for different areas.=20 (4) The risk of running out of nickname maybe a issue for TRILL. The = number of 2**16 nickname is enough for the current data center,=20 but it maybe not enough in the future, especailly if TRILL over IP , = TRILL over MPLS technology or some other data center technologies=20 are deployed, the data center network can be a very lardge network. So i = think the very important and essential goal of multi-level draft is to = save nicknames.=20 Best regards=20 Fangwei Hu "Tissa Senevirathne (tsenevir)" >=20 =B7=A2=BC=FE=C8=CB: rbridge-bounces@postel.org = =20 2012-02-23 11:55=20 =20 =CA=D5=BC=FE=C8=CB >=20 =B3=AD=CB=CD =09 =D6=F7=CC=E2 [rbridge] Default nickname base approach for multilevel TRILL- = draft-tissa-trill-multilevel-00.txt =20 =20 =09 =09 Dear All We have submitted draft-tissa-trill-multilevel, present multilevel TRILL = based on default nickname approach. Additionally we discuss construction = of multi-destination trees and related RPF in multilevel TRILL. Please = could you review and comment=20 Detail of the draft and abstract are below. Filename: draft-tissa-trill-multilevel Revision: 00 Title: Default Nickname Based Approach = for Multilevel TRILL Creation date: 2012-02-21 WG ID: Individual Submission Number of pages: 26 Abstract: Multilevel TRILL allows the interconnection of multiple TRILL networks to form a larger TRILL network without proportionally increasing the size of the IS-IS LSP DB. In this document, an approach based on default route concept is presented. Also, presented in the document is a novel method of constructing multi- destination trees using partial nickname space. Methods presented in this document are compatible with the RFC6325 specified data plane operations. = =20 Thanks Tissa _______________________________________________ rbridge mailing list rbridge@postel.org =20 http://mailman.postel.org/mailman/listinfo/rbridge = =20 _______________________________________________ rbridge mailing list rbridge@postel.org =20 http://mailman.postel.org/mailman/listinfo/rbridge = =20 =20 =20 ------_=_NextPart_001_01CCF4FA.42CA1EB2 Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable ------_=_NextPart_001_01CCF4FA.42CA1EB2-- --===============1545176185== 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 --===============1545176185==-- From rbridge-bounces@postel.org Sun Feb 26 20:14: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 3FEEF21F846A for ; Sun, 26 Feb 2012 20:14:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.623 X-Spam-Level: X-Spam-Status: No, score=-1.623 tagged_above=-999 required=5 tests=[AWL=1.924, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=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 IA3E9wVF08DF for ; Sun, 26 Feb 2012 20:14:27 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2CCA721F8469 for ; Sun, 26 Feb 2012 20:14:27 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1R3exE2007443; Sun, 26 Feb 2012 19:41:01 -0800 (PST) Received: from mail-pw0-f52.google.com (mail-pw0-f52.google.com [209.85.160.52]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1R3egLn007412 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sun, 26 Feb 2012 19:40:51 -0800 (PST) Received: by pbcum15 with SMTP id um15so1205619pbc.39 for ; Sun, 26 Feb 2012 19:40:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=7OgJStwTKF6HsQLoQ+HcFkTa8lbnEIsGrowqHmJ5mOI=; b=nSf+ccOi9oqOAugfKIqPznvH5ngkh/tFMDdy+9M2vdvYipmzA/cie90jxnyg8CqLed 7VMMSQcII6n2ZflLgIGjDUA71KSQAkU3ejR0f3iLa6DtaObX3BfzqSZKuit7p+lhb696 5q15woWydtMfD9+XbaL/4hBOeiyYpBc2bSEWA= Received: by 10.68.219.232 with SMTP id pr8mr30147432pbc.12.1330314042559; Sun, 26 Feb 2012 19:40:42 -0800 (PST) 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 s1sm11485742pbs.21.2012.02.26.19.40.40 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 26 Feb 2012 19:40:41 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) From: Sam Aldrin In-Reply-To: Date: Sun, 26 Feb 2012 19:40:34 -0800 Message-Id: <63D11BFF-F3DA-4D67-AAB4-434B0DB102E8@gmail.com> References: To: hu.fangwei@zte.com.cn X-Mailer: Apple Mail (2.1257) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: aldrin.ietf@gmail.com Cc: "Tissa Senevirathne \(tsenevir\)" , rbridge@postel.org, rbridge-bounces@postel.org, Radia Perlman Subject: Re: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.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: multipart/mixed; boundary="===============1724984528==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org --===============1724984528== Content-Type: multipart/alternative; boundary="Apple-Mail=_8854224B-7BB6-456E-AC39-83C19769127A" --Apple-Mail=_8854224B-7BB6-456E-AC39-83C19769127A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 On Feb 26, 2012, at 6:50 PM, hu.fangwei@zte.com.cn wrote: >=20 > The reason why folks in IP word are pushing to go to IPv6 is that the = exhausting of IPv4 address, not that the NAT can not work.=20 > The NAT technology is widely deployed in China, and it does work well. = There is very little IPv4 address can be assigned to the BNAS(Most of = the address assigned to the user are private IPv4 address, and only the = NNAS and above equitment are assigned public address ), so it is an = emergent thing to transit from IPv4 to IPv6.=20 And your point is? >=20 > If we can not slove the nickname space issue now, do we need another = NICKNAMEv6 or something else?=20 That could be a topic, which could be taken up to resolve nickname = exhaustion issue and not necessarily at multilevel draft. >=20 > So i thing the nickname space issue is the key issue we should slove = now.=20 That topic should be considered outside of this draft. >=20 > Multi-level draft is a good platform to slove it, though there is some = technology we should considered futher.=20 If multilevel draft is only to address 'nickname exhaustion' issue, then = it should be renamed accordingly and not 'multilevel'. The purpose of = multilevel draft is different, which is stated in the draft and the by = product of it is nickname exhaustion could be alleviated and not just = the primary problem/solution. Here is the snip from abstract "..novel = method of constructing multi-destination trees using partial nickname = space" cheers -sam >=20 >=20 >=20 > "Tissa Senevirathne (tsenevir)" =20 > =B7=A2=BC=FE=C8=CB: rbridge-bounces@postel.org > 2012-02-25 02:07 >=20 > =CA=D5=BC=FE=C8=CB > "Radia Perlman" > =B3=AD=CB=CD > rbridge@postel.org, rbridge-bounces@postel.org, hu.fangwei@zte.com.cn > =D6=F7=CC=E2 > Re: [rbridge] Default nickname base approach for multilevel TRILL- = draft-tissa-trill-multilevel-00.txt >=20 >=20 >=20 >=20 >=20 > Also, there are so many well known issues with NAT like approaches. #1 = is you would lose identity of originator, and it becomes an OAM = nightmare. It limit ability apply certain ACL, rate-limiting etc.=20 > =20 > There is a whole series of issues associated with NATs. That is one of = the reasons folks in IP world are pushing hard to go to IPv6. I was = assuming people are aware of those.=20 > =20 > From: Radia Perlman [mailto:radiaperlman@gmail.com]=20 > Sent: Friday, February 24, 2012 9:23 AM > To: Tissa Senevirathne (tsenevir) > Cc: hu.fangwei@zte.com.cn; rbridge@postel.org; = rbridge-bounces@postel.org > Subject: Re: [rbridge] Default nickname base approach for multilevel = TRILL- draft-tissa-trill-multilevel-00.txt=20 > =20 > I assume that all RBridges will need to be in all topologies, so = multitopology will not help with nickname exhaustion. Plus you haven't = explained how a TRILL packet would be marked as to which topology the = packet should be routed according to (other than what I mentioned, which = actually eats up nicknames by a factor of the number of topologies = supported).=20 > =20 > Plus, rather than just lumping potential issues into a phrase such as = "NAT-like", be explicit about what issues there actually are. I believe = the Fulcrum chip would have no problem with translating the nickname = fields.=20 > =20 > And rather than assuming that nickname exhaustion can be solved "some = other way", there should be a palatable solution before rejecting a = chance to solve it with multilevel.=20 > =20 > Radia=20 > 2012/2/24 Tissa Senevirathne (tsenevir) =20 > Because you can have same nickname for different topology. It is not a = nickname that will identify an RBRidge, it is topology,nickname = combination that will identify an RBRidge. So RB1 can have nickname 1 in = topo-1 and RB2 can have nickname 1 in topo2. Now total nicknames in the = campus is 2**16 x topologies.=20 > =20 > Stealing bits to represent topo id is only a workaround there can be = (are ) more elegant ways of doing it that.=20 > =20 > Bottom line is we need to look for more creative methods of solving = nickname space issue than doing NAT like behavior.=20 > =20 > From: Radia Perlman [mailto:radiaperlman@gmail.com]=20 > Sent: Friday, February 24, 2012 9:05 AM > To: Tissa Senevirathne (tsenevir) > Cc: hu.fangwei@zte.com.cn; rbridge@postel.org; = rbridge-bounces@postel.org=20 >=20 > Subject: Re: [rbridge] Default nickname base approach for multilevel = TRILL- draft-tissa-trill-multilevel-00.txt=20 > =20 > I don't understand how multi-topology helps with the nickname = exhaustion issue. As a matter of fact, the only plausible way of = marking a packet for which topology that has been suggested on the = mailing list (I asked a efw times if there were any other = possibilities), was to steal 2 or 3 bits of the nickname to encode which = topology, in effect, making a destination appear as multiple = destinations and multiple forwarding table entries (which you'd want = anyway, for multitopology).=20 > =20 > =20 > Radia=20 > 2012/2/24 Tissa Senevirathne (tsenevir) =20 > Mutli-topology is the answer to increase the nickname space.=20 > =20 > Nickname translation is very similar to NAT, which has it=A1=AFs own = down side, not to mention special hardware etc. to do the translations, = additionally. We also know from our experience, in IP world NATing is = not the most desired behavior and we live with it. So we should not be = going down that path instead need to look forward from that experience.=20= > =20 > Multi-topology not only address nickname space issue but also enables = various other applications such as overlay topologies, traffic = engineering.=20 > =20 > The draft-tiss-trill-multilevel present approaches that are generic, = which mean it can be applied for multi-topology, or base topology. It = utilizes the fundamentals of IS-IS , such as Area hierarchy for = reduction of the LSP-DB. It utilize affinity TLV concepts to effectively = solve multi-destination issues.=20 > =20 > We should not mix-up between Data center interconnects with data = center node scaling. They are two different and orthogonal issues.=20 > =20 > Objective of multi-level trill is to interconnect different = datacenters, and maintain LSP-DB small as possible to avoid scaling and = volatility.=20 > =20 > Increasing nickname space a different requirement and has nothing to = do with data-center interconnects.=20 > =20 > =20 > From: Radia Perlman [mailto:radiaperlman@gmail.com]=20 > Sent: Friday, February 24, 2012 6:15 AM > To: hu.fangwei@zte.com.cn > Cc: Tissa Senevirathne (tsenevir); rbridge@postel.org; = rbridge-bounces@postel.org > Subject: Re: [rbridge] Default nickname base approach for multilevel = TRILL- draft-tissa-trill-multilevel-00.txt=20 > =20 > People have mentioned to me that they are nervous about running out of = nicknames, especially since there are reasonson why they might want to = assign nicknames to hypervisors. With the alternate approach of = allowing nicknames to be reused in different areas, it makes automatic = nickname assignment much simpler and makes TRILL a lot more scalable.=20 > =20 > It does have the downside of requiring mapping of nicknames at the = border RBridges.=20 > =20 > And by the way, the affinity TLV can be used for multidestination = frames transiting between level 1 and level 2.=20 > =20 > Radia=20 > 2012/2/23 =20 >=20 > Hi, Tissa.=20 >=20 > I have several comments about the draft.=20 >=20 > (1) in section 4.4 (Multicast), "The scope of global traffic may be = identified either through VLAN or via finegrain=20 > label that spans across the entire TRILL campus."=20 > Vlan and Fine-grain Label is used for service differentiation and = isolation. I do not quite understand that how to=20 > use VLAN and fine-grain Lable to identify the traffic scope. The data = traffic with a given VLAN-x, can=20 > be forwarded to other end station in the local area, or to the end = station in remote areas.=20 >=20 > (2) nickname allocation=20 > The nickname management sub-TLV is proposed in the document. I wonder = this mechanism adds the complication of =20 > nickname allocation. As the section 1 (introduction) of RFC6325, one = of the important advantage of TRILL is that =20 > it avoids the creating subnets of IP address and wasting address. The = nickname acquisition method in this draft violates the =20 > idea of TRILL Basic specification, and reduces the flexibility of = nickname allocation. As the draft assumed, A1 had =20 > nickname range of 100-200, A2 has a local nickname range of 201-300. = If the numbers of A1 area is only 50, so 50 =20 > nicknames in A1 is wasted. As the network growing, the number of some = areas may exceed the number being allocation =20 > by Border RBridges. The design and maintaining of nickname ranges for = each area is a very hard work. Even worst, it =20 > can not avoid to waste nickname space.=20 >=20 > (3) Dynamic ranges=20 > The nickname range is divided into two range: local range and = dynamical range. I wonder the nickname conflict =20 > resolution can not work if the RBridge get the nickname from the = dynamical range while the two RBridge belongs to =20 > different areas. For example, RB1 is in area A1, and RB2 is in area = A2. If RB1 gets the nickname N1 from dynamic =20 > range, and it will floods in area A1, and other RBridges in area A1 = can not get nickname N1 because of nickname =20 > confliction mechanism, but RB2 in area A2 can not receive the PDU from = RB1, and it can also get the nickname N1 from =20 > dynamical range. So the question is how to avoid the duplication = dynamical range nickname for different areas.=20 >=20 > (4) The risk of running out of nickname maybe a issue for TRILL. The = number of 2**16 nickname is enough for the current data center,=20 > but it maybe not enough in the future, especailly if TRILL over IP , = TRILL over MPLS technology or some other data center technologies=20 > are deployed, the data center network can be a very lardge network. So = i think the very important and essential goal of multi-level draft is to = save nicknames.=20 >=20 > Best regards=20 > Fangwei Hu > "Tissa Senevirathne (tsenevir)" =20 > =B7=A2=BC=FE=C8=CB: rbridge-bounces@postel.org > 2012-02-23 11:55 >=20 >=20 > =CA=D5=BC=FE=C8=CB > > =B3=AD=CB=CD > =D6=F7=CC=E2 > [rbridge] Default nickname base approach for multilevel TRILL- = draft-tissa-trill-multilevel-00.txt >=20 > =20 >=20 >=20 >=20 >=20 >=20 >=20 > Dear All >=20 > We have submitted draft-tissa-trill-multilevel, present multilevel = TRILL based on default nickname approach. Additionally we discuss = construction of multi-destination trees and related RPF in multilevel = TRILL. Please could you review and comment=20 >=20 > Detail of the draft and abstract are below. >=20 > Filename: draft-tissa-trill-multilevel > Revision: 00 > Title: Default Nickname Based = Approach for Multilevel TRILL > Creation date: 2012-02-21 > WG ID: Individual Submission > Number of pages: 26 >=20 > Abstract: > Multilevel TRILL allows the interconnection of multiple TRILL > networks to form a larger TRILL network without proportionally > increasing the size of the IS-IS LSP DB. In this document, an > approach based on default route concept is presented. Also, > presented in the document is a novel method of constructing multi- > destination trees using partial nickname space. Methods presented in > this document are compatible with the RFC6325 specified data plane > operations. >=20 > = =20 > Thanks > Tissa >=20 > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge=20 >=20 > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge=20 > =20 > =20 > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge >=20 > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge >=20 --Apple-Mail=_8854224B-7BB6-456E-AC39-83C19769127A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=GB2312 hu.fangwei@zte.com.cn = wrote:

Lets leave multi topology a side for a moment. There are two broad = questions here:

 

1.       = Multi-level TRILL

2.       =  Increase nickname space for TRILL.

 

If #2 is an issue then that needed to be properly looked it in to. #1 = has nothing do with #2. Contention is advocating nickname translation as = the solution for #2. Like it was highlighted earlier, nickname = translation has issues related OAM, inability to apply specific security = policies and so on.

 

Multi-level solution presented in draft-tissa-trill-multilevel does = not assume existence of any of the special feature, rather it provide = data center interconnect based on generic = methods.

 

If #2 is an issue I suggest working group to prioritize the action = and work on it.

 

 

From:= = hu.fangwei@zte.com.cn [mailto:hu.fangwei@zte.com.cn]
Sent: = Sunday, February 26, 2012 6:33 PM
To: Radia = Perlman
Cc: rbridge@postel.org; rbridge-bounces@postel.org; = Tissa Senevirathne (tsenevir)
Subject: Re: Re: [rbridge] = Default nickname base approach for multilevel TRILL- = draft-tissa-trill-multilevel-00.txt

 


I agree with = Radia, and do not think that Multi-topology can slove the nickname space = issue.

There are = two cases for MT (RFC5120):

(1) RBridge = with Non-overlap nickname address. The nickname routes can be installed = into a shared nickname RIB table. And there is no need for marking the = data with different Topology. This situation can not help to nickname = exhaustion issue.

(2) RBridge = with overlap nickname address. The RBridge can be assigned the same = nickname for different topology. But we should consider to mark the data = with different toplology. Besides the stealing bits methods, we have no = good ideas to do that. The stealing bits methods can not reudce the = nickname exhausting issue actually, because it reudce the valid lengh of = nickname.

Radia Perlman = <radiaperlman@gmail.com> =

2012-02-25 = 01:23

"Tissa = Senevirathne (tsenevir)" <tsenevir@cisco.com> =

 

=CA=D5=BC=FE=C8=CB

=B3=AD=CB=CD

hu.fangwei@zte= .com.cn, rbridge@postel.org, rbridge-bounces@postel.org =

=D6=F7=CC=E2

Re: [rbridge] = Default nickname base approach for multilevel TRILL- = draft-tissa-trill-multilevel-00.txt




I assume that all RBridges = will need to be in all topologies, so multitopology will not help with = nickname exhaustion.  Plus you haven't explained how a TRILL packet = would be marked as to which topology the packet should be routed = according to (other than what I mentioned, which actually eats up = nicknames by a factor of the number of topologies supported). =
  =
Plus, rather than = just lumping potential issues into a phrase such as = "NAT-like", be explicit about what issues there actually are. =  I believe the Fulcrum chip would have no problem with translating = the nickname fields.
 
And rather than assuming that = nickname exhaustion can be solved "some other way", there = should be a palatable solution before rejecting a chance to solve it = with multilevel.
 
Radia

2012/2/24 Tissa Senevirathne = (tsenevir) <tsenevir@cisco.com<= span style=3D'font-family:"Arial","sans-serif"'>>
Because you can have same nickname for different topology. It is not = a nickname that will identify an RBRidge, it is topology,nickname = combination that will identify an RBRidge. So RB1 can have nickname 1 in = topo-1 and RB2 can have nickname 1 in topo2. Now total nicknames in the = campus is 2**16 x topologies.

 

Stealing bits to represent topo id is only a workaround there can be = (are ) more elegant ways of doing it that. =

 

Bottom line is we need to look for more creative methods of solving = nickname space issue than doing NAT like behavior. =

 

From:= = Radia Perlman [mailto:radiaperlman= @gmail.com] =
Sent: Friday, February 24, 2012 9:05 AM
To: Tissa = Senevirathne (tsenevir)
Cc: hu.fangwei@z= te.com.cn; rbridge@post= el.org; rbridge-boun= ces@postel.org =

Subject:= Re: = [rbridge] Default nickname base approach for multilevel TRILL- = draft-tissa-trill-multilevel-00.txt

  =

I = don't understand how multi-topology helps with the nickname exhaustion = issue.  As a matter of fact, the only plausible way of marking a = packet for which topology that has been suggested on the mailing list (I = asked a efw times if there were any other possibilities), was to steal 2 = or 3 bits of the nickname to encode which topology, in effect, making a = destination appear as multiple destinations and multiple forwarding = table entries (which you'd want anyway, for multitopology). =

  =

  =

Radia =

2012/2/24 Tissa Senevirathne = (tsenevir) <tsenevir@cisco.com<= span style=3D'font-family:"Arial","sans-serif"'>> =

Mutli-topology is the answer to increase the nickname space. =

 

Nickname translation is very similar to NAT, which has it=A1=AFs own = down side, not to mention special hardware etc. to do the translations, = additionally. We also know from our experience, in IP world NATing is = not the most desired behavior and we live with it. So we should not be = going down that path instead need to look forward from that = experience.

 

Multi-topology not only address nickname space issue but also enables = various other applications such as overlay topologies, traffic = engineering.

 

The draft-tiss-trill-multilevel present approaches that are generic, = which mean it can be applied for multi-topology, or base topology. It = utilizes the fundamentals of IS-IS , such as Area hierarchy for = reduction of the LSP-DB. It utilize affinity TLV concepts to effectively = solve multi-destination issues.

 

We should not mix-up between Data center interconnects with data = center node scaling. They are two different and orthogonal = issues.

 

Objective of multi-level trill is to interconnect different = datacenters, and maintain LSP-DB small as possible to avoid scaling and = volatility.

 

Increasing nickname space a different requirement and has nothing to = do with data-center interconnects.

 

 

From:= = Radia Perlman [mailto:radiaperlman= @gmail.com] =
Sent: Friday, February 24, 2012 6:15 AM
To: = hu.fangwei@z= te.com.cn
Cc: Tissa = Senevirathne (tsenevir); rbridge@post= el.org; rbridge-boun= ces@postel.org
Subject:= Re: = [rbridge] Default nickname base approach for multilevel TRILL- = draft-tissa-trill-multilevel-00.txt

  =

People have mentioned to me = that they are nervous about running out of nicknames, especially since = there are reasonson why they might want to assign nicknames to = hypervisors.  With the alternate approach of allowing nicknames to = be reused in different areas, it makes automatic nickname assignment = much simpler and makes TRILL a lot more scalable. =

  =

It = does have the downside of requiring mapping of nicknames at the border = RBridges.

  =

And = by the way, the affinity TLV can be used for multidestination frames = transiting between level 1 and level 2.

  =

Radia =

2012/2/23 <hu.fangwei@zte.com.cn> =


Hi, Tissa.

I have = several comments about the draft.

(1) in section 4.4 = (Multicast), "The scope of global traffic may be identified either = through VLAN or via finegrain
label that spans across the entire = TRILL campus."
Vlan and Fine-grain Label is used for service = differentiation and isolation. I do not quite understand that how to =
use VLAN and fine-grain Lable to identify the traffic scope. The = data traffic with a given VLAN-x, can
be forwarded to other end = station in the local area, or to the end station in remote areas. =

(2) nickname allocation
The nickname management sub-TLV is = proposed in the document. I wonder this mechanism adds the complication = of  
nickname allocation. As the section 1 (introduction) of = RFC6325, one of the important advantage of TRILL is that  
it = avoids the creating subnets of IP address and wasting address. The = nickname acquisition  method in this draft violates the   =
idea of TRILL Basic specification, and reduces the flexibility of = nickname allocation. As the draft assumed, A1 had  
nickname = range of 100-200, A2 has a local nickname range of 201-300. If the = numbers of A1 area is only 50, so 50  
nicknames in A1 is = wasted. As the network growing, the number of some areas may exceed the = number being allocation  
by Border RBridges. The design and = maintaining of nickname ranges for each area is a very hard work. Even = worst, it  
can not avoid to waste nickname space.

(3) = Dynamic ranges
The nickname range is divided into two range: local = range and dynamical range. I wonder the nickname conflict   =
resolution can not work if the RBridge get the nickname from the = dynamical range while the two RBridge belongs to  
different = areas. For example, RB1 is in area A1, and RB2 is in area A2. If RB1 = gets the nickname N1 from dynamic  
range, and it will floods = in area A1, and other RBridges in area A1 can not get nickname N1 = because of nickname  
confliction mechanism, but RB2 in area A2 = can not receive the PDU from RB1, and it  can also get the nickname = N1 from  
dynamical range. So the question is how to avoid the = duplication dynamical range nickname for different areas.

(4) = The risk of running out of nickname maybe a issue for TRILL. The number = of 2**16 nickname is enough for the current data center,
but it = maybe not enough in the future, especailly if TRILL over IP , TRILL over = MPLS technology or some other data center technologies
are deployed, = the data center network can be a very lardge network. So i think the = very important and essential goal of multi-level draft is to save = nicknames.

Best regards
Fangwei = Hu

"Tissa = Senevirathne (tsenevir)" <tsenevir@cisco= .com> =
=B7=A2=BC=FE=C8=CB: =  rbridge-bounce= s@postel.org =

2012-02-23 = 11:55 =

 

<rbridge@postel= .org> =

=

=CA=D5=BC=FE=C8=CB

=B3=AD=CB=CD

=D6=F7=CC=E2

[rbridge] = Default nickname base approach for multilevel TRILL-     =   =  draft-tissa-trill-multilevel-00.txt

  =

 




Dear = All

We have = submitted draft-tissa-trill-multilevel, present multilevel TRILL based = on default nickname approach. Additionally we discuss construction of = multi-destination trees and related RPF in multilevel TRILL. Please = could you review and comment

Detail of = the draft and abstract are below.

Filename: =                 =  draft-tissa-trill-multilevel
Revision:     =              00
Title: =                     =               Default Nickname Based = Approach for Multilevel TRILL
Creation date:     =             =  2012-02-21
WG ID:           =                     =     Individual Submission
Number of pages: = 26

Abstract:
 Multilevel TRILL allows the interconnection of multiple = TRILL
 networks to form a larger TRILL network without = proportionally
 increasing the size of the IS-IS LSP = DB. In this document, an
 approach based on default = route concept is presented. Also,
 presented in the = document is a novel method of constructing = multi-
 destination trees using partial nickname space. = Methods presented in
 this document are compatible with = the RFC6325 specified data plane
 operations.

  =                     =                     =                     =                   =
Thanks
Tissa

___________= ____________________________________
rbridge mailing = list
rbridge@postel.org
http://mailman.postel.org/mailman/listinfo/rbridge<= /tt>


__________________________= _____________________
rbridge mailing list
rbridge@postel.org<= u>
http://mailman.postel.org/mail= man/listinfo/rbridge

  =

  =



The reason why folks in IP word = are pushing to go to IPv6 is that the exhausting of IPv4 address, not that the NAT can not work. 
The NAT technology is = widely deployed in China, and it does work well. There is very little IPv4 address can be assigned to the BNAS(Most of the address assigned to the user are = private IPv4 address, and only the NNAS and above equitment are assigned public address ), so it is an emergent thing to transit from IPv4 to = IPv6.
And your point is?

If we can not slove the = nickname space issue now, do we need another NICKNAMEv6 or something else?
That could be a topic, which could be taken up to = resolve nickname exhaustion issue and not necessarily at multilevel = draft.

So i thing the nickname space = issue is the key issue we should slove now.
That topic should be considered outside of this = draft.

Multi-level draft is a good = platform to slove it, though there is some technology we should considered = futher.
If multilevel draft is only to address 'nickname = exhaustion' issue, then it should be renamed accordingly and not = 'multilevel'. The purpose of multilevel draft is different, which is = stated in the draft and the by product of it is nickname exhaustion = could be alleviated and not just the primary problem/solution. Here is = the snip from abstract "..novel method of constructing multi-destination trees using = partial nickname space"

cheers
-sam




"Tissa = Senevirathne (tsenevir)" <tsenevir@cisco.com> =
=B7=A2=BC=FE=C8=CB:  rbridge-bounces@postel.org<= /font>

2012-02-25 02:07

=CA=D5=BC=FE=C8=CB
"Radia Perlman" <radiaperlman@gmail.com>
=B3=AD=CB=CD
rbridge@postel.org, rbridge-bounces@postel.org,= hu.fangwei@zte.com.cn
=D6=F7=CC=E2
Re: [rbridge] Default = nickname base approach for multilevel TRILL-       =  draft-tissa-trill-multilevel-00.txt
=




Also, there are = so many well known issues with NAT like approaches. #1 is you would lose identity of originator, and it becomes an OAM nightmare.  It limit ability = apply certain ACL, rate-limiting etc.
 
There is a whole = series of issues associated with NATs. That is one of the reasons folks in IP = world are pushing hard to go to IPv6. I was assuming people are aware of = those.
 
From: Radia Perlman = [mailto:radiaperlman@gmail.com]
Sent: Friday, February 24, 2012 9:23 AM
To: Tissa Senevirathne (tsenevir)
Cc: hu.fangwei@zte.com.cn; rbridge@postel.org; rbridge-bounces@postel.org<= b>
Subject: Re: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.txt
 
I assume that all RBridges will = need to be in all topologies, so multitopology will not help with nickname = exhaustion.  Plus you haven't explained how a TRILL packet would be marked as to which topology the packet should be routed according to (other than what I mentioned, which actually eats up nicknames by a factor of the = number of topologies supported).
 
Plus, rather than just lumping = potential issues into a phrase such as "NAT-like", be explicit about what issues there actually are.  I believe the Fulcrum chip would have no problem with translating the nickname fields.
 
And rather than assuming that = nickname exhaustion can be solved "some other way", there should be a palatable solution before rejecting a chance to solve it with = multilevel.
 
Radia
2012/2/24 Tissa Senevirathne = (tsenevir) <tsenevir@cisco.com>
Because you can = have same nickname for different topology. It is not a nickname that will identify an RBRidge, it is topology,nickname combination that will identify an = RBRidge. So RB1 can have nickname 1 in topo-1 and RB2 can have nickname 1 in = topo2. Now total nicknames in the campus is 2**16 x topologies.
 
Stealing bits to = represent topo id is only a workaround there can be (are ) more elegant ways of = doing it that.
 
Bottom line is = we need to look for more creative methods of solving nickname space issue than = doing NAT like behavior.
 
From: Radia Perlman = [mailto:radiaperlman@gmail.com]
Sent: Friday, February 24, 2012 9:05 AM
To: Tissa Senevirathne (tsenevir)
Cc: hu.fangwei@zte.com.cn; rbridge@postel.org; rbridge-bounces@postel.org

Subject: Re: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.txt
 
I don't understand how = multi-topology helps with the nickname exhaustion issue.  As a matter of fact, the only plausible way of marking a packet for which topology that has been suggested on the mailing list (I asked a efw times if there were any = other possibilities), was to steal 2 or 3 bits of the nickname to encode which topology, in effect, making a destination appear as multiple = destinations and multiple forwarding table entries (which you'd want anyway, for = multitopology).
 
 
Radia
2012/2/24 Tissa Senevirathne = (tsenevir) <tsenevir@cisco.com>
Mutli-topology = is the answer to increase the nickname space.
 
Nickname = translation is very similar to NAT, which has it=A1=AFs own down side, not to mention = special hardware etc. to do the translations, additionally. We also know from = our experience, in IP world NATing is not the most desired behavior and we live with it. So we should not be going down that path instead need to look forward from that experience.
 
Multi-topology = not only address nickname space issue but also enables various other applications such as overlay topologies, traffic engineering.
 
The = draft-tiss-trill-multilevel present approaches that are generic, which mean it can be applied for = multi-topology, or base topology. It utilizes the fundamentals of IS-IS , such as Area hierarchy for reduction of the LSP-DB. It utilize affinity TLV concepts to effectively solve multi-destination issues.
 
We should not = mix-up between Data center interconnects with data center node scaling. They are two = different and orthogonal issues.
 
Objective of = multi-level trill is to interconnect different datacenters, and maintain LSP-DB = small as possible to avoid scaling and volatility.
 
Increasing = nickname space a different requirement and has nothing to do with data-center = interconnects.
 
 
From: Radia Perlman = [mailto:radiaperlman@gmail.com]
Sent: Friday, February 24, 2012 6:15 AM
To: hu.fangwei@zte.com.cn
Cc: Tissa Senevirathne (tsenevir); rbridge@postel.org; rbridge-bounces@postel.org
Subject: Re: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.txt
 
People have mentioned to me = that they are nervous about running out of nicknames, especially since there are reasonson why they might want to assign nicknames to hypervisors. =  With the alternate approach of allowing nicknames to be reused in different areas, it makes automatic nickname assignment much simpler and makes = TRILL a lot more scalable.
 
It does have the downside of = requiring mapping of nicknames at the border RBridges.
 
And by the way, the affinity = TLV can be used for multidestination frames transiting between level 1 and level 2.
 
Radia
2012/2/23 <hu.fangwei@zte.com.cn>

Hi, Tissa.

I have several comments about the draft.

(1) in section 4.4 (Multicast), "The scope of global traffic may be identified either through VLAN or via finegrain
label that spans across the entire TRILL campus."
Vlan and Fine-grain Label is used for service differentiation and = isolation. I do not quite understand that how to
use VLAN and fine-grain Lable to identify the traffic scope. The data = traffic with a given VLAN-x, can
be forwarded to other end station in the local area, or to the end = station in remote areas.

(2) nickname allocation =
The nickname management sub-TLV is proposed in the document. I wonder = this mechanism adds the complication of  
nickname allocation. As the section 1 (introduction) of RFC6325, one of the important advantage of TRILL is that  
it avoids the creating subnets of IP address and wasting address. The = nickname acquisition  method in this draft violates the  
idea of TRILL Basic specification, and reduces the flexibility of = nickname allocation. As the draft assumed, A1 had  
nickname range of 100-200, A2 has a local nickname range of 201-300. If the numbers of A1 area is only 50, so 50  
nicknames in A1 is wasted. As the network growing, the number of some = areas may exceed the number being allocation  
by Border RBridges. The design and maintaining of nickname ranges for = each area is a very hard work. Even worst, it  
can not avoid to waste nickname space.

(3) Dynamic ranges
The nickname range is divided into two range: local range and dynamical range. I wonder the nickname conflict  
resolution can not work if the RBridge get the nickname from the = dynamical range while the two RBridge belongs to  
different areas. For example, RB1 is in area A1, and RB2 is in area A2. If RB1 gets the nickname N1 from dynamic  
range, and it will floods in area A1, and other RBridges in area A1 can not get nickname N1 because of nickname  
confliction mechanism, but RB2 in area A2 can not receive the PDU from RB1, and it  can also get the nickname N1 from  
dynamical range. So the question is how to avoid the duplication = dynamical range nickname for different areas.

(4) The risk of running out of nickname maybe a issue for TRILL. The = number of 2**16 nickname is enough for the current data center,
but it maybe not enough in the future, especailly if TRILL over IP , = TRILL over MPLS technology or some other data center technologies
are deployed, the data center network can be a very lardge network. So i think the very important and essential goal of multi-level draft is to save nicknames.

Best regards
Fangwei Hu

"Tissa Senevirathne = (tsenevir)" <tsenevir@cisco.com>
=B7=A2=BC=FE=C8=CB: =  rbridge-bounces@postel.org

2012-02-23 11:55


=CA=D5=BC=FE=C8=CB
<rbridge@postel.org>=
=B3=AD=CB=CD
=D6=F7=CC=E2
[rbridge] Default nickname base = approach for multilevel TRILL-       =  draft-tissa-trill-multilevel-00.txt
=
 







Dear All

We have submitted draft-tissa-trill-multilevel, present multilevel TRILL based on default nickname approach. Additionally we discuss construction of multi-destination trees and related RPF in multilevel TRILL. Please could you review and comment

Detail of the draft and abstract are below.

Filename:                 =  draft-tissa-trill-multilevel
Revision:                 =  00
Title:                   =                 Default Nickname Based Approach for Multilevel TRILL
Creation date:                  2012-02-21
WG ID:                   =                 Individual = Submission
Number of pages: 26

Abstract:
 Multilevel TRILL allows the interconnection of multiple TRILL
 networks to form a larger TRILL network without = proportionally
 increasing the size of the IS-IS LSP DB. In this document, an
 approach based on default route concept is presented. Also,
 presented in the document is a novel method of constructing = multi-
 destination trees using partial nickname space. Methods presented in
 this document are compatible with the RFC6325 specified data = plane
 operations.

                                        =                       =                  
Thanks
Tissa

_______________________________________________
rbridge mailing list
rbridge@postel.org
http://mailman.postel.org/mailman/listinfo/rbridge<= /u>

_______________________________________________
rbridge mailing list
rbridge@postel.org
http://mailman.postel.org/mailman/listinfo/rbridge<= /u>
 
 
 _______________________________________________
rbridge mailing list
rbridge@postel.org
http://mailman= .postel.org/mailman/listinfo/rbridge
_______________________________________________
rbridge mailing = list
rbridge@postel.org
http://mailma= n.postel.org/mailman/listinfo/rbridge


= --Apple-Mail=_8854224B-7BB6-456E-AC39-83C19769127A-- --===============1724984528== 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 --===============1724984528==-- From rbridge-bounces@postel.org Sun Feb 26 20:15:10 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 6508921E801A for ; Sun, 26 Feb 2012 20:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.497 X-Spam-Level: X-Spam-Status: No, score=-4.497 tagged_above=-999 required=5 tests=[AWL=-0.950, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=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 O9JMlnQpERAF for ; Sun, 26 Feb 2012 20:15:04 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6020821E800F for ; Sun, 26 Feb 2012 20:15:04 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1R3M3U3004920; Sun, 26 Feb 2012 19:22:04 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1R3Ldsc004896 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 26 Feb 2012 19:21:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tsenevir@cisco.com; l=50316; q=dns/txt; s=iport; t=1330312907; x=1331522507; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=n6o9OF3CG9qVRBUuLldxA3HZFjNb9EK3jbXDoAYWqfw=; b=P+Tbd7rxVrWqudzHUg0wSy6XRHuZGF/9Oo57rFi5u70NLCZ/GY4Tc4cw +ic1RF/yKfmKbBde5Msi07iuUDImAar8nsaqGDMJE2XJB3zsyAD3BeSVk 4G9P8NqJxyFYiZiecFOR6aV5XALAgC478WeuMFTmdUu5C19Kdvem9T0nw E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcFAJX1Sk+rRDoH/2dsb2JhbAA5AQmCUYJopQABiQ2BB4FzAQEBBAEBAQ8BBwIRAz4LEAIBBgIRBAEBCwYQAQIEAQQCASAGHwkIAQEEEwgRAgeHYwygZAGMXwiJNYkPYQEEgxkBBAMBAQEBAwEBAgEEAQQFAQEBAQECAgVJhF0FCA4ICg4eAwUGAwMBAwYBAQoNAQYLBBSCEzdjBIhPmAWHeIEzAQQ X-IronPort-AV: E=Sophos;i="4.73,488,1325462400"; d="scan'208,217";a="30579495" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 27 Feb 2012 03:21:38 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q1R3LcmM004635; Mon, 27 Feb 2012 03:21:38 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); Sun, 26 Feb 2012 19:21:38 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 26 Feb 2012 19:21:37 -0800 Message-ID: <344037D7CFEFE84E97E9CC1F56C5F4A5A46681@xmb-sjc-214.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.txt Thread-Index: Acz0+pic/Eoo9OQeR3SrXJQ0cQRRxgAABEWQ References: <344037D7CFEFE84E97E9CC1F56C5F4A5A46360@xmb-sjc-214.amer.cisco.com> From: "Tissa Senevirathne (tsenevir)" To: X-OriginalArrivalTime: 27 Feb 2012 03:21:38.0581 (UTC) FILETIME=[EAD83450:01CCF4FE] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: tsenevir@cisco.com Cc: rbridge@postel.org Subject: Re: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.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: multipart/mixed; boundary="===============0608674501==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org This is a multi-part message in MIME format. --===============0608674501== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCF4FE.EAA6BA5A" This is a multi-part message in MIME format. ------_=_NextPart_001_01CCF4FE.EAA6BA5A Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable =20 Think about this way we have nickname translation method implemented and = in a data center, and you have taken TRILL to the hypervisors. I am = sitting on Data center A, I cannot reach to a specific MAC B. Only think = my forwarding table would say is MAC-B is sitting in Data center B. Now = trying to figure out where is MAC B exactly located requires lot more = screening. Additionally, I want to apply rate limiting features to = devices coming from public access area of Data Center B, if everything = is now translated to B there is no way one could apply the required = security policies, those are some examples. =20 I think we need to think progressively and novel, if we do that we have = a very good chance of making TRILL very very successful and even rival = out other competing technologies. If we try to utilize easier short cuts = results may not be that attractive. =20 I think you are saying we need work on nickname space increase, but I do = not think you are saying nickname translation as the solution correct ? = If so I am fully on board with you. =20 I respectfully disagree with you on your interpretation of reason of = doing IPv6. =20 I also suggest you to read the IPv6 deployment presentation that was = done during 82nd IETF on reasons for migrating to IPv6. It was said NAT = is like life support keeping a brain dead person alive. If you still = believe only reason of doing IPv6 is to increase the address space and = NAT solve other issues, then we can extend this thread to include ipv6 = and int-area mailing list to see what wider audience think about the = topic. =20 From: hu.fangwei@zte.com.cn [mailto:hu.fangwei@zte.com.cn]=20 Sent: Sunday, February 26, 2012 6:50 PM To: Tissa Senevirathne (tsenevir) Cc: Radia Perlman; rbridge@postel.org; rbridge-bounces@postel.org Subject: Re: Re: [rbridge] Default nickname base approach for multilevel = TRILL- draft-tissa-trill-multilevel-00.txt =20 The reason why folks in IP word are pushing to go to IPv6 is that the = exhausting of IPv4 address, not that the NAT can not work.=20 The NAT technology is widely deployed in China, and it does work well. = There is very little IPv4 address can be assigned to the BNAS(Most of = the address assigned to the user are private IPv4 address, and only the = NNAS and above equitment are assigned public address ), so it is an = emergent thing to transit from IPv4 to IPv6.=20 If we can not slove the nickname space issue now, do we need another = NICKNAMEv6 or something else?=20 So i thing the nickname space issue is the key issue we should slove = now.=20 Multi-level draft is a good platform to slove it, though there is some = technology we should considered futher.=20 "Tissa Senevirathne (tsenevir)" =20 =B7=A2=BC=FE=C8=CB: rbridge-bounces@postel.org=20 2012-02-25 02:07=20 =CA=D5=BC=FE=C8=CB "Radia Perlman" =20 =B3=AD=CB=CD rbridge@postel.org, rbridge-bounces@postel.org, hu.fangwei@zte.com.cn=20 =D6=F7=CC=E2 Re: [rbridge] Default nickname base approach for multilevel TRILL- = draft-tissa-trill-multilevel-00.txt =20 =09 Also, there are so many well known issues with NAT like approaches. #1 = is you would lose identity of originator, and it becomes an OAM = nightmare. It limit ability apply certain ACL, rate-limiting etc.=20 =20 There is a whole series of issues associated with NATs. That is one of = the reasons folks in IP world are pushing hard to go to IPv6. I was = assuming people are aware of those.=20 =20 From: Radia Perlman [mailto:radiaperlman@gmail.com]=20 Sent: Friday, February 24, 2012 9:23 AM To: Tissa Senevirathne (tsenevir) Cc: hu.fangwei@zte.com.cn; rbridge@postel.org; = rbridge-bounces@postel.org Subject: Re: [rbridge] Default nickname base approach for multilevel = TRILL- draft-tissa-trill-multilevel-00.txt=20 =20 I assume that all RBridges will need to be in all topologies, so = multitopology will not help with nickname exhaustion. Plus you haven't = explained how a TRILL packet would be marked as to which topology the = packet should be routed according to (other than what I mentioned, which = actually eats up nicknames by a factor of the number of topologies = supported).=20 =20 Plus, rather than just lumping potential issues into a phrase such as = "NAT-like", be explicit about what issues there actually are. I believe = the Fulcrum chip would have no problem with translating the nickname = fields.=20 =20 And rather than assuming that nickname exhaustion can be solved "some = other way", there should be a palatable solution before rejecting a = chance to solve it with multilevel.=20 =20 Radia=20 2012/2/24 Tissa Senevirathne (tsenevir) >=20 Because you can have same nickname for different topology. It is not a = nickname that will identify an RBRidge, it is topology,nickname = combination that will identify an RBRidge. So RB1 can have nickname 1 in = topo-1 and RB2 can have nickname 1 in topo2. Now total nicknames in the = campus is 2**16 x topologies.=20 =20 Stealing bits to represent topo id is only a workaround there can be = (are ) more elegant ways of doing it that.=20 =20 Bottom line is we need to look for more creative methods of solving = nickname space issue than doing NAT like behavior.=20 =20 From: Radia Perlman [mailto:radiaperlman@gmail.com = ]=20 Sent: Friday, February 24, 2012 9:05 AM To: Tissa Senevirathne (tsenevir) Cc: hu.fangwei@zte.com.cn ; = rbridge@postel.org ; = rbridge-bounces@postel.org =20 Subject: Re: [rbridge] Default nickname base approach for multilevel = TRILL- draft-tissa-trill-multilevel-00.txt=20 =20 I don't understand how multi-topology helps with the nickname exhaustion = issue. As a matter of fact, the only plausible way of marking a packet = for which topology that has been suggested on the mailing list (I asked = a efw times if there were any other possibilities), was to steal 2 or 3 = bits of the nickname to encode which topology, in effect, making a = destination appear as multiple destinations and multiple forwarding = table entries (which you'd want anyway, for multitopology).=20 =20 =20 Radia=20 2012/2/24 Tissa Senevirathne (tsenevir) >=20 Mutli-topology is the answer to increase the nickname space.=20 =20 Nickname translation is very similar to NAT, which has it=A1=AFs own = down side, not to mention special hardware etc. to do the translations, = additionally. We also know from our experience, in IP world NATing is = not the most desired behavior and we live with it. So we should not be = going down that path instead need to look forward from that experience.=20 =20 Multi-topology not only address nickname space issue but also enables = various other applications such as overlay topologies, traffic = engineering.=20 =20 The draft-tiss-trill-multilevel present approaches that are generic, = which mean it can be applied for multi-topology, or base topology. It = utilizes the fundamentals of IS-IS , such as Area hierarchy for = reduction of the LSP-DB. It utilize affinity TLV concepts to effectively = solve multi-destination issues.=20 =20 We should not mix-up between Data center interconnects with data center = node scaling. They are two different and orthogonal issues.=20 =20 Objective of multi-level trill is to interconnect different datacenters, = and maintain LSP-DB small as possible to avoid scaling and volatility.=20 =20 Increasing nickname space a different requirement and has nothing to do = with data-center interconnects.=20 =20 =20 From: Radia Perlman [mailto:radiaperlman@gmail.com = ]=20 Sent: Friday, February 24, 2012 6:15 AM To: hu.fangwei@zte.com.cn =20 Cc: Tissa Senevirathne (tsenevir); rbridge@postel.org = ; rbridge-bounces@postel.org = =20 Subject: Re: [rbridge] Default nickname base approach for multilevel = TRILL- draft-tissa-trill-multilevel-00.txt=20 =20 People have mentioned to me that they are nervous about running out of = nicknames, especially since there are reasonson why they might want to = assign nicknames to hypervisors. With the alternate approach of = allowing nicknames to be reused in different areas, it makes automatic = nickname assignment much simpler and makes TRILL a lot more scalable.=20 =20 It does have the downside of requiring mapping of nicknames at the = border RBridges.=20 =20 And by the way, the affinity TLV can be used for multidestination frames = transiting between level 1 and level 2.=20 =20 Radia=20 2012/2/23 >=20 Hi, Tissa.=20 I have several comments about the draft.=20 (1) in section 4.4 (Multicast), "The scope of global traffic may be = identified either through VLAN or via finegrain=20 label that spans across the entire TRILL campus."=20 Vlan and Fine-grain Label is used for service differentiation and = isolation. I do not quite understand that how to=20 use VLAN and fine-grain Lable to identify the traffic scope. The data = traffic with a given VLAN-x, can=20 be forwarded to other end station in the local area, or to the end = station in remote areas.=20 (2) nickname allocation=20 The nickname management sub-TLV is proposed in the document. I wonder = this mechanism adds the complication of =20 nickname allocation. As the section 1 (introduction) of RFC6325, one of = the important advantage of TRILL is that =20 it avoids the creating subnets of IP address and wasting address. The = nickname acquisition method in this draft violates the =20 idea of TRILL Basic specification, and reduces the flexibility of = nickname allocation. As the draft assumed, A1 had =20 nickname range of 100-200, A2 has a local nickname range of 201-300. If = the numbers of A1 area is only 50, so 50 =20 nicknames in A1 is wasted. As the network growing, the number of some = areas may exceed the number being allocation =20 by Border RBridges. The design and maintaining of nickname ranges for = each area is a very hard work. Even worst, it =20 can not avoid to waste nickname space.=20 (3) Dynamic ranges=20 The nickname range is divided into two range: local range and dynamical = range. I wonder the nickname conflict =20 resolution can not work if the RBridge get the nickname from the = dynamical range while the two RBridge belongs to =20 different areas. For example, RB1 is in area A1, and RB2 is in area A2. = If RB1 gets the nickname N1 from dynamic =20 range, and it will floods in area A1, and other RBridges in area A1 can = not get nickname N1 because of nickname =20 confliction mechanism, but RB2 in area A2 can not receive the PDU from = RB1, and it can also get the nickname N1 from =20 dynamical range. So the question is how to avoid the duplication = dynamical range nickname for different areas.=20 (4) The risk of running out of nickname maybe a issue for TRILL. The = number of 2**16 nickname is enough for the current data center,=20 but it maybe not enough in the future, especailly if TRILL over IP , = TRILL over MPLS technology or some other data center technologies=20 are deployed, the data center network can be a very lardge network. So i = think the very important and essential goal of multi-level draft is to = save nicknames.=20 Best regards=20 Fangwei Hu=20 "Tissa Senevirathne (tsenevir)" >=20 =B7=A2=BC=FE=C8=CB: rbridge-bounces@postel.org = =20 2012-02-23 11:55=20 =20 =CA=D5=BC=FE=C8=CB >=20 =B3=AD=CB=CD =09 =D6=F7=CC=E2 [rbridge] Default nickname base approach for multilevel TRILL- = draft-tissa-trill-multilevel-00.txt =20 =20 =09 =09 Dear All We have submitted draft-tissa-trill-multilevel, present multilevel TRILL = based on default nickname approach. Additionally we discuss construction = of multi-destination trees and related RPF in multilevel TRILL. Please = could you review and comment=20 Detail of the draft and abstract are below. Filename: draft-tissa-trill-multilevel Revision: 00 Title: Default Nickname Based Approach = for Multilevel TRILL Creation date: 2012-02-21 WG ID: Individual Submission Number of pages: 26 Abstract: Multilevel TRILL allows the interconnection of multiple TRILL networks to form a larger TRILL network without proportionally increasing the size of the IS-IS LSP DB. In this document, an approach based on default route concept is presented. Also, presented in the document is a novel method of constructing multi- destination trees using partial nickname space. Methods presented in this document are compatible with the RFC6325 specified data plane operations. = =20 Thanks Tissa _______________________________________________ rbridge mailing list rbridge@postel.org =20 http://mailman.postel.org/mailman/listinfo/rbridge = =20 _______________________________________________ rbridge mailing list rbridge@postel.org =20 http://mailman.postel.org/mailman/listinfo/rbridge = =20 =20 =20 _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge ------_=_NextPart_001_01CCF4FE.EAA6BA5A Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable

 

Think about this way we have nickname translation method implemented = and in a data center, and you have taken TRILL to the hypervisors. I am = sitting on Data center A, I cannot reach to a specific MAC B. Only think = my forwarding table would say is MAC-B is sitting in Data center B. Now = trying to figure out where is MAC B exactly located requires lot more = screening. Additionally, I want to apply rate limiting features to = devices coming from public access area of Data Center B, if everything = is now translated to B there is no way one could apply the required = security policies, those are some examples.

 

I think we need to think progressively and novel, if we do that we = have a very good chance of making TRILL very very successful and even = rival out other competing technologies. If we try to utilize easier = short cuts results may not be that attractive.

 

I think you are saying we need work on nickname space increase, but I = do not think you are saying nickname translation as the solution correct = ? If so I am fully on board with you.

 

I respectfully disagree with you on your interpretation of reason of = doing IPv6.

 

I also suggest you to read the  IPv6 deployment presentation = that was done during 82nd IETF on reasons for migrating to = IPv6. It was said NAT is like life support keeping a brain dead person = alive. If you still believe only reason of doing IPv6 is to increase the = address space and NAT solve other issues, then we can extend this thread = to include ipv6 and int-area mailing list to see what wider audience = think about the topic.

 

From:= = hu.fangwei@zte.com.cn [mailto:hu.fangwei@zte.com.cn]
Sent: = Sunday, February 26, 2012 6:50 PM
To: Tissa Senevirathne = (tsenevir)
Cc: Radia Perlman; rbridge@postel.org; = rbridge-bounces@postel.org
Subject: Re: Re: [rbridge] Default = nickname base approach for multilevel TRILL- = draft-tissa-trill-multilevel-00.txt

 


The reason = why folks in IP word are pushing to go to IPv6 is that the exhausting of = IPv4 address, not that the NAT can not work.

The NAT = technology is widely deployed in China, and it does work well. There is = very little IPv4 address can be assigned to the BNAS(Most of the address = assigned to the user are private IPv4 address, and only the NNAS and = above equitment are assigned public address ), so it is an emergent = thing to transit from IPv4 to IPv6.

If we can = not slove the nickname space issue now, do we need another NICKNAMEv6 or = something else?

So i thing = the nickname space issue is the key issue we should slove now. =

Multi-level = draft is a good platform to slove it, though there is some technology we = should considered futher.


"Tissa = Senevirathne (tsenevir)" <tsenevir@cisco.com> =
=B7=A2=BC=FE=C8=CB: =  rbridge-bounces@postel.org

2012-02-25 = 02:07

"Radia = Perlman" <radiaperlman@gmail.com> =

=

=CA=D5=BC=FE=C8=CB

=B3=AD=CB=CD

rbridge@postel= .org, rbridge-bounces@postel.org, hu.fangwei@zte.com.cn =

=D6=F7=CC=E2

Re: [rbridge] = Default nickname base approach for multilevel TRILL-     =   =  draft-tissa-trill-multilevel-00.txt

 




Also, there are so many well known issues with NAT like approaches. = #1 is you would lose identity of originator, and it becomes an OAM = nightmare.  It limit ability apply certain ACL, rate-limiting = etc.
 
There is a whole series of issues associated with NATs. That is one = of the reasons folks in IP world are pushing hard to go to IPv6. I was = assuming people are aware of those.
 
From:= = Radia Perlman [mailto:radiaperlman@gmail.com]
Sent: Friday, = February 24, 2012 9:23 AM
To: Tissa Senevirathne = (tsenevir)
Cc: hu.fangwei@zte.com.cn; rbridge@postel.org; = rbridge-bounces@postel.org
Subject: Re: [rbridge] Default = nickname base approach for multilevel TRILL- = draft-tissa-trill-multilevel-00.txt
 
I assume that all RBridges = will need to be in all topologies, so multitopology will not help with = nickname exhaustion.  Plus you haven't explained how a TRILL packet = would be marked as to which topology the packet should be routed = according to (other than what I mentioned, which actually eats up = nicknames by a factor of the number of topologies supported). =
  =
Plus, rather than = just lumping potential issues into a phrase such as = "NAT-like", be explicit about what issues there actually are. =  I believe the Fulcrum chip would have no problem with translating = the nickname fields.
 
And rather than assuming that = nickname exhaustion can be solved "some other way", there = should be a palatable solution before rejecting a chance to solve it = with multilevel.
 
Radia
2012/2/24 Tissa Senevirathne = (tsenevir) <tsenevir@cisco.com<= span style=3D'font-family:"Arial","sans-serif"'>>
Because you can have same nickname for different topology. It is not = a nickname that will identify an RBRidge, it is topology,nickname = combination that will identify an RBRidge. So RB1 can have nickname 1 in = topo-1 and RB2 can have nickname 1 in topo2. Now total nicknames in the = campus is 2**16 x topologies.
 
Stealing bits to represent topo id is only a workaround there can be = (are ) more elegant ways of doing it that.
 
Bottom line is we need to look for more creative methods of solving = nickname space issue than doing NAT like behavior.
 
From:= = Radia Perlman [mailto:radiaperlman= @gmail.com] =
Sent: Friday, February 24, 2012 9:05 AM
To: Tissa = Senevirathne (tsenevir)
Cc: hu.fangwei@z= te.com.cn; rbridge@post= el.org; rbridge-boun= ces@postel.org =

Subject:= Re: = [rbridge] Default nickname base approach for multilevel TRILL- = draft-tissa-trill-multilevel-00.txt
 
I don't understand how = multi-topology helps with the nickname exhaustion issue.  As a = matter of fact, the only plausible way of marking a packet for which = topology that has been suggested on the mailing list (I asked a efw = times if there were any other possibilities), was to steal 2 or 3 bits = of the nickname to encode which topology, in effect, making a = destination appear as multiple destinations and multiple forwarding = table entries (which you'd want anyway, for multitopology). =
  =
  =
Radia =
2012/2/24 Tissa = Senevirathne (tsenevir) <tsenevir@cisco.com<= span style=3D'font-family:"Arial","sans-serif"'>>
Mutli-topology is the answer to increase the nickname space. =
 
Nickname translation is very similar to NAT, which has it=A1=AFs own = down side, not to mention special hardware etc. to do the translations, = additionally. We also know from our experience, in IP world NATing is = not the most desired behavior and we live with it. So we should not be = going down that path instead need to look forward from that = experience.
 
Multi-topology not only address nickname space issue but also enables = various other applications such as overlay topologies, traffic = engineering.
 
The draft-tiss-trill-multilevel present approaches that are generic, = which mean it can be applied for multi-topology, or base topology. It = utilizes the fundamentals of IS-IS , such as Area hierarchy for = reduction of the LSP-DB. It utilize affinity TLV concepts to effectively = solve multi-destination issues.
 
We should not mix-up between Data center interconnects with data = center node scaling. They are two different and orthogonal = issues.
 
Objective of multi-level trill is to interconnect different = datacenters, and maintain LSP-DB small as possible to avoid scaling and = volatility.
 
Increasing nickname space a different requirement and has nothing to = do with data-center interconnects.
 
 
From:= = Radia Perlman [mailto:radiaperlman= @gmail.com] =
Sent: Friday, February 24, 2012 6:15 AM
To: = hu.fangwei@z= te.com.cn
Cc: Tissa = Senevirathne (tsenevir); rbridge@post= el.org; rbridge-boun= ces@postel.org
Subject:= Re: = [rbridge] Default nickname base approach for multilevel TRILL- = draft-tissa-trill-multilevel-00.txt
 
People have mentioned to me = that they are nervous about running out of nicknames, especially since = there are reasonson why they might want to assign nicknames to = hypervisors.  With the alternate approach of allowing nicknames to = be reused in different areas, it makes automatic nickname assignment = much simpler and makes TRILL a lot more scalable.
 
It does have the downside of = requiring mapping of nicknames at the border RBridges.
 
And by the way, the affinity = TLV can be used for multidestination frames transiting between level 1 = and level 2.
 
Radia
2012/2/23 <hu.fangwei@zte.com.cn>

Hi, Tissa.

I have = several comments about the draft.

(1) in section 4.4 = (Multicast), "The scope of global traffic may be identified either = through VLAN or via finegrain
label that spans across the entire = TRILL campus."
Vlan and Fine-grain Label is used for service = differentiation and isolation. I do not quite understand that how to =
use VLAN and fine-grain Lable to identify the traffic scope. The = data traffic with a given VLAN-x, can
be forwarded to other end = station in the local area, or to the end station in remote areas. =

(2) nickname allocation
The nickname management sub-TLV is = proposed in the document. I wonder this mechanism adds the complication = of  
nickname allocation. As the section 1 (introduction) of = RFC6325, one of the important advantage of TRILL is that  
it = avoids the creating subnets of IP address and wasting address. The = nickname acquisition  method in this draft violates the   =
idea of TRILL Basic specification, and reduces the flexibility of = nickname allocation. As the draft assumed, A1 had  
nickname = range of 100-200, A2 has a local nickname range of 201-300. If the = numbers of A1 area is only 50, so 50  
nicknames in A1 is = wasted. As the network growing, the number of some areas may exceed the = number being allocation  
by Border RBridges. The design and = maintaining of nickname ranges for each area is a very hard work. Even = worst, it  
can not avoid to waste nickname space.

(3) = Dynamic ranges
The nickname range is divided into two range: local = range and dynamical range. I wonder the nickname conflict   =
resolution can not work if the RBridge get the nickname from the = dynamical range while the two RBridge belongs to  
different = areas. For example, RB1 is in area A1, and RB2 is in area A2. If RB1 = gets the nickname N1 from dynamic  
range, and it will floods = in area A1, and other RBridges in area A1 can not get nickname N1 = because of nickname  
confliction mechanism, but RB2 in area A2 = can not receive the PDU from RB1, and it  can also get the nickname = N1 from  
dynamical range. So the question is how to avoid the = duplication dynamical range nickname for different areas.

(4) = The risk of running out of nickname maybe a issue for TRILL. The number = of 2**16 nickname is enough for the current data center,
but it = maybe not enough in the future, especailly if TRILL over IP , TRILL over = MPLS technology or some other data center technologies
are deployed, = the data center network can be a very lardge network. So i think the = very important and essential goal of multi-level draft is to save = nicknames.

Best regards
Fangwei Hu =

"Tissa = Senevirathne (tsenevir)" <tsenevir@cisco= .com> =
=B7=A2=BC=FE=C8=CB: =  rbridge-bounce= s@postel.org =

2012-02-23 = 11:55 =

 

<rbridge@postel= .org> =

=

=CA=D5=BC=FE=C8=CB

=B3=AD=CB=CD

=D6=F7=CC=E2

[rbridge] = Default nickname base approach for multilevel TRILL-     =   =  draft-tissa-trill-multilevel-00.txt


  =

 





Dear = All

We have submitted draft-tissa-trill-multilevel, present = multilevel TRILL based on default nickname approach. Additionally we = discuss construction of multi-destination trees and related RPF in = multilevel TRILL. Please could you review and comment

Detail of = the draft and abstract are below.

Filename:       =           =  draft-tissa-trill-multilevel
Revision:       =            00
Title:     =                     =           Default Nickname Based Approach for = Multilevel TRILL
Creation date:           =        2012-02-21
WG ID:       =                     =         Individual Submission
Number of pages: = 26

Abstract:
 Multilevel TRILL allows the interconnection = of multiple TRILL
 networks to form a larger TRILL network = without proportionally
 increasing the size of the IS-IS LSP DB. = In this document, an
 approach based on default route concept is = presented. Also,
 presented in the document is a novel method of = constructing multi-
 destination trees using partial nickname = space. Methods presented in
 this document are compatible with = the RFC6325 specified data plane
 operations.

  =                     =                     =                     =                   =
Thanks
Tissa

______________________________________________= _
rbridge mailing list
rbridge@postel.org<= u>
http://mailman.postel.org/mail= man/listinfo/rbridge

__________________________= _____________________
rbridge mailing list
rbridge@postel.org<= u>
http://mailman.postel.org/mail= man/listinfo/rbridge
 
 
 _____________= __________________________________
rbridge mailing = list
rbridge@postel.org
http://mailman.postel.org= /mailman/listinfo/rbridge

------_=_NextPart_001_01CCF4FE.EAA6BA5A-- --===============0608674501== 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 --===============0608674501==-- From rbridge-bounces@postel.org Sun Feb 26 20:29: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 A51A521E8019 for ; Sun, 26 Feb 2012 20:29:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.885 X-Spam-Level: X-Spam-Status: No, score=-2.885 tagged_above=-999 required=5 tests=[AWL=1.262, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 VPvayLQK3RMZ for ; Sun, 26 Feb 2012 20:29:55 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id D688D21E800F for ; Sun, 26 Feb 2012 20:29:55 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1R3n1qI008639; Sun, 26 Feb 2012 19:49:02 -0800 (PST) Received: from mail-pw0-f52.google.com (mail-pw0-f52.google.com [209.85.160.52]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1R3mWAM008579 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sun, 26 Feb 2012 19:48:41 -0800 (PST) Received: by pbcum15 with SMTP id um15so1211765pbc.39 for ; Sun, 26 Feb 2012 19:48:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=sYMaGq+79JwE8aLS8ofOeMxzltVBq/+luhoFgsKMgRo=; b=QzDt6YmWD0eg5JQBb1h2npZb/IcO7NuxpI4YPYa3lmObyTAOby96TDCIxbeqx8mo+Z TWWxd/D+hjXFG1d7ZW9neOisA62GeTgUQVzUZgQwU9zCWkaykDLuf8QxkvvAr7Lv6k0H e3lKUMG/uSKiu9a5sw4ESDP/F2gxBMP1AOkfI= Received: by 10.68.129.41 with SMTP id nt9mr30002556pbb.111.1330314511996; Sun, 26 Feb 2012 19:48:31 -0800 (PST) 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 k2sm11499174pba.28.2012.02.26.19.48.30 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 26 Feb 2012 19:48:31 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) From: Sam Aldrin In-Reply-To: Date: Sun, 26 Feb 2012 19:48:28 -0800 Message-Id: <9408FF6F-C165-4352-83D7-45D2B1EC7D6C@gmail.com> References: To: hu.fangwei@zte.com.cn X-Mailer: Apple Mail (2.1257) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: aldrin.ietf@gmail.com Cc: rbridge@postel.org, rbridge-bounces@postel.org, "Tissa Senevirathne \(tsenevir\)" , Radia Perlman Subject: Re: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.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: multipart/mixed; boundary="===============0835106105==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org --===============0835106105== Content-Type: multipart/alternative; boundary="Apple-Mail=_00CCAFBA-E094-491E-A582-5B5B09E73A0F" --Apple-Mail=_00CCAFBA-E094-491E-A582-5B5B09E73A0F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 On Feb 26, 2012, at 6:33 PM, hu.fangwei@zte.com.cn wrote: >=20 > I agree with Radia, and do not think that Multi-topology can slove the = nickname space issue.=20 As replied in other email, the draft is not to solve nickname exhaustion = but rather have multilevel topologies constructed without having the = need to change the identity of the original frame. >=20 > There are two cases for MT (RFC5120):=20 >=20 > (1) RBridge with Non-overlap nickname address. The nickname routes can = be installed into a shared nickname RIB table. And there is no need for = marking the data with different Topology. This situation can not help to = nickname exhaustion issue.=20 >=20 > (2) RBridge with overlap nickname address. The RBridge can be assigned = the same nickname for different topology. But we should consider to mark = the data with different toplology. Besides the stealing bits methods, we = have no good ideas to do that. The stealing bits methods can not reudce = the nickname exhausting issue actually, because it reudce the valid = lengh of nickname.=20 Stealing bits is not a good idea, IMHO. -sam >=20 >=20 >=20 > Radia Perlman > 2012-02-25 01:23 >=20 > =CA=D5=BC=FE=C8=CB > "Tissa Senevirathne (tsenevir)" > =B3=AD=CB=CD > hu.fangwei@zte.com.cn, rbridge@postel.org, rbridge-bounces@postel.org > =D6=F7=CC=E2 > Re: [rbridge] Default nickname base approach for multilevel TRILL- = draft-tissa-trill-multilevel-00.txt >=20 >=20 >=20 >=20 >=20 > I assume that all RBridges will need to be in all topologies, so = multitopology will not help with nickname exhaustion. Plus you haven't = explained how a TRILL packet would be marked as to which topology the = packet should be routed according to (other than what I mentioned, which = actually eats up nicknames by a factor of the number of topologies = supported).=20 > =20 > Plus, rather than just lumping potential issues into a phrase such as = "NAT-like", be explicit about what issues there actually are. I believe = the Fulcrum chip would have no problem with translating the nickname = fields.=20 > =20 > And rather than assuming that nickname exhaustion can be solved "some = other way", there should be a palatable solution before rejecting a = chance to solve it with multilevel.=20 > =20 > Radia >=20 > 2012/2/24 Tissa Senevirathne (tsenevir) =20 > Because you can have same nickname for different topology. It is not a = nickname that will identify an RBRidge, it is topology,nickname = combination that will identify an RBRidge. So RB1 can have nickname 1 in = topo-1 and RB2 can have nickname 1 in topo2. Now total nicknames in the = campus is 2**16 x topologies. > =20 > Stealing bits to represent topo id is only a workaround there can be = (are ) more elegant ways of doing it that. >=20 > =20 > Bottom line is we need to look for more creative methods of solving = nickname space issue than doing NAT like behavior. >=20 > =20 > From: Radia Perlman [mailto:radiaperlman@gmail.com]=20 > Sent: Friday, February 24, 2012 9:05 AM > To: Tissa Senevirathne (tsenevir) > Cc: hu.fangwei@zte.com.cn; rbridge@postel.org; = rbridge-bounces@postel.org=20 >=20 > Subject: Re: [rbridge] Default nickname base approach for multilevel = TRILL- draft-tissa-trill-multilevel-00.txt >=20 > =20 > I don't understand how multi-topology helps with the nickname = exhaustion issue. As a matter of fact, the only plausible way of = marking a packet for which topology that has been suggested on the = mailing list (I asked a efw times if there were any other = possibilities), was to steal 2 or 3 bits of the nickname to encode which = topology, in effect, making a destination appear as multiple = destinations and multiple forwarding table entries (which you'd want = anyway, for multitopology). >=20 > =20 > =20 > Radia >=20 > 2012/2/24 Tissa Senevirathne (tsenevir) >=20 > Mutli-topology is the answer to increase the nickname space. >=20 > =20 > Nickname translation is very similar to NAT, which has it=A1=AFs own = down side, not to mention special hardware etc. to do the translations, = additionally. We also know from our experience, in IP world NATing is = not the most desired behavior and we live with it. So we should not be = going down that path instead need to look forward from that experience. >=20 > =20 > Multi-topology not only address nickname space issue but also enables = various other applications such as overlay topologies, traffic = engineering. >=20 > =20 > The draft-tiss-trill-multilevel present approaches that are generic, = which mean it can be applied for multi-topology, or base topology. It = utilizes the fundamentals of IS-IS , such as Area hierarchy for = reduction of the LSP-DB. It utilize affinity TLV concepts to effectively = solve multi-destination issues. >=20 > =20 > We should not mix-up between Data center interconnects with data = center node scaling. They are two different and orthogonal issues. >=20 > =20 > Objective of multi-level trill is to interconnect different = datacenters, and maintain LSP-DB small as possible to avoid scaling and = volatility. >=20 > =20 > Increasing nickname space a different requirement and has nothing to = do with data-center interconnects. >=20 > =20 > =20 > From: Radia Perlman [mailto:radiaperlman@gmail.com]=20 > Sent: Friday, February 24, 2012 6:15 AM > To: hu.fangwei@zte.com.cn > Cc: Tissa Senevirathne (tsenevir); rbridge@postel.org; = rbridge-bounces@postel.org > Subject: Re: [rbridge] Default nickname base approach for multilevel = TRILL- draft-tissa-trill-multilevel-00.txt >=20 > =20 > People have mentioned to me that they are nervous about running out of = nicknames, especially since there are reasonson why they might want to = assign nicknames to hypervisors. With the alternate approach of = allowing nicknames to be reused in different areas, it makes automatic = nickname assignment much simpler and makes TRILL a lot more scalable. >=20 > =20 > It does have the downside of requiring mapping of nicknames at the = border RBridges. >=20 > =20 > And by the way, the affinity TLV can be used for multidestination = frames transiting between level 1 and level 2. >=20 > =20 > Radia >=20 > 2012/2/23 >=20 >=20 > Hi, Tissa.=20 >=20 > I have several comments about the draft.=20 >=20 > (1) in section 4.4 (Multicast), "The scope of global traffic may be = identified either through VLAN or via finegrain=20 > label that spans across the entire TRILL campus."=20 > Vlan and Fine-grain Label is used for service differentiation and = isolation. I do not quite understand that how to=20 > use VLAN and fine-grain Lable to identify the traffic scope. The data = traffic with a given VLAN-x, can=20 > be forwarded to other end station in the local area, or to the end = station in remote areas.=20 >=20 > (2) nickname allocation=20 > The nickname management sub-TLV is proposed in the document. I wonder = this mechanism adds the complication of =20 > nickname allocation. As the section 1 (introduction) of RFC6325, one = of the important advantage of TRILL is that =20 > it avoids the creating subnets of IP address and wasting address. The = nickname acquisition method in this draft violates the =20 > idea of TRILL Basic specification, and reduces the flexibility of = nickname allocation. As the draft assumed, A1 had =20 > nickname range of 100-200, A2 has a local nickname range of 201-300. = If the numbers of A1 area is only 50, so 50 =20 > nicknames in A1 is wasted. As the network growing, the number of some = areas may exceed the number being allocation =20 > by Border RBridges. The design and maintaining of nickname ranges for = each area is a very hard work. Even worst, it =20 > can not avoid to waste nickname space.=20 >=20 > (3) Dynamic ranges=20 > The nickname range is divided into two range: local range and = dynamical range. I wonder the nickname conflict =20 > resolution can not work if the RBridge get the nickname from the = dynamical range while the two RBridge belongs to =20 > different areas. For example, RB1 is in area A1, and RB2 is in area = A2. If RB1 gets the nickname N1 from dynamic =20 > range, and it will floods in area A1, and other RBridges in area A1 = can not get nickname N1 because of nickname =20 > confliction mechanism, but RB2 in area A2 can not receive the PDU from = RB1, and it can also get the nickname N1 from =20 > dynamical range. So the question is how to avoid the duplication = dynamical range nickname for different areas.=20 >=20 > (4) The risk of running out of nickname maybe a issue for TRILL. The = number of 2**16 nickname is enough for the current data center,=20 > but it maybe not enough in the future, especailly if TRILL over IP , = TRILL over MPLS technology or some other data center technologies=20 > are deployed, the data center network can be a very lardge network. So = i think the very important and essential goal of multi-level draft is to = save nicknames.=20 >=20 > Best regards=20 > Fangwei Hu >=20 > "Tissa Senevirathne (tsenevir)" =20 > =B7=A2=BC=FE=C8=CB: rbridge-bounces@postel.org > 2012-02-23 11:55 >=20 >=20 > =CA=D5=BC=FE=C8=CB > > =B3=AD=CB=CD > =D6=F7=CC=E2 > [rbridge] Default nickname base approach for multilevel TRILL- = draft-tissa-trill-multilevel-00.txt > =20 >=20 >=20 >=20 >=20 >=20 >=20 > Dear All >=20 > We have submitted draft-tissa-trill-multilevel, present multilevel = TRILL based on default nickname approach. Additionally we discuss = construction of multi-destination trees and related RPF in multilevel = TRILL. Please could you review and comment=20 >=20 > Detail of the draft and abstract are below. >=20 > Filename: draft-tissa-trill-multilevel > Revision: 00 > Title: Default Nickname Based = Approach for Multilevel TRILL > Creation date: 2012-02-21 > WG ID: Individual Submission > Number of pages: 26 >=20 > Abstract: > Multilevel TRILL allows the interconnection of multiple TRILL > networks to form a larger TRILL network without proportionally > increasing the size of the IS-IS LSP DB. In this document, an > approach based on default route concept is presented. Also, > presented in the document is a novel method of constructing multi- > destination trees using partial nickname space. Methods presented in > this document are compatible with the RFC6325 specified data plane > operations. >=20 > = =20 > Thanks > Tissa >=20 > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge >=20 >=20 > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge >=20 > =20 > =20 >=20 > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge >=20 --Apple-Mail=_00CCAFBA-E094-491E-A582-5B5B09E73A0F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=GB2312 hu.fangwei@zte.com.cn = wrote:


I agree with Radia, and do not = think that Multi-topology can slove the nickname space issue.
As replied in other email, the draft is not to solve = nickname exhaustion but rather have multilevel topologies constructed = without having the need to change the identity of the original = frame.

There are two cases for MT = (RFC5120):

(1) RBridge with Non-overlap = nickname address. The nickname routes can be installed into a shared nickname RIB table. And there is no need for marking the data with different = Topology. This situation can not help to nickname exhaustion issue.

(2) RBridge with overlap = nickname address. The RBridge can be assigned the same nickname for different topology. = But we should consider to mark the data with different toplology. Besides = the stealing bits methods, we have no good ideas to do that. The stealing = bits methods can not reudce the nickname exhausting issue actually, because it reudce the valid lengh of nickname.
Stealing bits is not a good idea, = IMHO.

-sam



Radia Perlman = <radiaperlman@gmail.com>

2012-02-25 01:23

=CA=D5=BC=FE=C8=CB
"Tissa Senevirathne = (tsenevir)" <tsenevir@cisco.com>
=B3=AD=CB=CD
hu.fangwei@zte.com.cn, rbridge@postel.org, rbridge-bounces@postel.org<= /font>
=D6=F7=CC=E2
Re: [rbridge] Default = nickname base approach for multilevel TRILL- = draft-tissa-trill-multilevel-00.txt





I assume that all RBridges will = need to be in all topologies, so multitopology will not help with nickname = exhaustion.  Plus you haven't explained how a TRILL packet would be marked as to which topology the packet should be routed according to (other than what I mentioned, which actually eats up nicknames by a factor of the = number of topologies supported).
 
Plus, rather than just lumping = potential issues into a phrase such as "NAT-like", be explicit about what issues there actually are.  I believe the Fulcrum chip would have no problem with translating the nickname fields.
 
And rather than assuming that = nickname exhaustion can be solved "some other way", there should be a palatable solution before rejecting a chance to solve it with = multilevel.
 
Radia
2012/2/24 Tissa Senevirathne = (tsenevir) <tsenevir@cisco.com>
Because you can = have same nickname for different topology. It is not a nickname that will identify an RBRidge, it is topology,nickname combination that will identify an = RBRidge. So RB1 can have nickname 1 in topo-1 and RB2 can have nickname 1 in = topo2. Now total nicknames in the campus is 2**16 x = topologies.
 

Stealing bits to represent topo id is only a workaround there can be (are ) more elegant ways of = doing it that.

 =

Bottom line is we need to look for more creative methods of solving nickname space issue than = doing NAT like behavior.

 =

From: Radia Perlman [mailto:radiaperlman@gmail.com]
Sent: Friday, February 24, 2012 9:05 AM
To: Tissa Senevirathne (tsenevir)
Cc: hu.fangwei@zte.com.cn; rbridge@postel.org; rbridge-bounces@postel.org

Subject: Re: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.txt

 

I don't understand how multi-topology helps with the nickname exhaustion issue.  As a matter of fact, the only plausible way of marking a packet for which topology that has been suggested on the mailing list (I asked a efw times if there were any = other possibilities), was to steal 2 or 3 bits of the nickname to encode which topology, in effect, making a destination appear as multiple = destinations and multiple forwarding table entries (which you'd want anyway, for = multitopology).

 
 

Radia

2012/2/24 Tissa Senevirathne = (tsenevir) <tsenevir@cisco.com>

Mutli-topology = is the answer to increase the nickname space.

 =

Nickname translation is very similar to NAT, which has it=A1=AFs own down side, not to mention = special hardware etc. to do the translations, additionally. We also know from = our experience, in IP world NATing is not the most desired behavior and we live with it. So we should not be going down that path instead need to look forward from that experience.

 =

Multi-topology not only address nickname space issue but also enables various other applications such as overlay topologies, traffic engineering.

 =

The draft-tiss-trill-multilevel present approaches that are generic, which mean it can be applied for = multi-topology, or base topology. It utilizes the fundamentals of IS-IS , such as Area hierarchy for reduction of the LSP-DB. It utilize affinity TLV concepts to effectively solve multi-destination issues.

 =

We should not mix-up between Data center interconnects with data center node scaling. They are two = different and orthogonal issues.

 =

Objective of multi-level trill is to interconnect different datacenters, and maintain LSP-DB small as possible to avoid scaling and volatility.

 =

Increasing nickname space a different requirement and has nothing to do with data-center = interconnects.

 =
 

From: Radia Perlman [mailto:radiaperlman@gmail.com]
Sent: Friday, February 24, 2012 6:15 AM
To: hu.fangwei@zte.com.cn
Cc: Tissa Senevirathne (tsenevir); rbridge@postel.org; rbridge-bounces@postel.org
Subject: Re: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.txt

 

People have mentioned to me that they are nervous about running out of nicknames, especially since there are reasonson why they might want to assign nicknames to hypervisors. =  With the alternate approach of allowing nicknames to be reused in different areas, it makes automatic nickname assignment much simpler and makes = TRILL a lot more scalable.

 

It does have the downside of requiring mapping of nicknames at the border RBridges.

 

And by the way, the affinity TLV can be used for multidestination frames transiting between level 1 and level 2.

 

Radia

2012/2/23 <hu.fangwei@zte.com.cn>


Hi, Tissa.

I have several comments about the draft.

(1) in section 4.4 (Multicast), "The scope of global traffic may be identified either through VLAN or via finegrain
label that spans across the entire TRILL campus."
Vlan and Fine-grain Label is used for service differentiation and = isolation. I do not quite understand that how to
use VLAN and fine-grain Lable to identify the traffic scope. The data = traffic with a given VLAN-x, can
be forwarded to other end station in the local area, or to the end = station in remote areas.

(2) nickname allocation =
The nickname management sub-TLV is proposed in the document. I wonder = this mechanism adds the complication of  
nickname allocation. As the section 1 (introduction) of RFC6325, one of the important advantage of TRILL is that  
it avoids the creating subnets of IP address and wasting address. The = nickname acquisition  method in this draft violates the  
idea of TRILL Basic specification, and reduces the flexibility of = nickname allocation. As the draft assumed, A1 had  
nickname range of 100-200, A2 has a local nickname range of 201-300. If the numbers of A1 area is only 50, so 50  
nicknames in A1 is wasted. As the network growing, the number of some = areas may exceed the number being allocation  
by Border RBridges. The design and maintaining of nickname ranges for = each area is a very hard work. Even worst, it  
can not avoid to waste nickname space.

(3) Dynamic ranges
The nickname range is divided into two range: local range and dynamical range. I wonder the nickname conflict  
resolution can not work if the RBridge get the nickname from the = dynamical range while the two RBridge belongs to  
different areas. For example, RB1 is in area A1, and RB2 is in area A2. If RB1 gets the nickname N1 from dynamic  
range, and it will floods in area A1, and other RBridges in area A1 can not get nickname N1 because of nickname  
confliction mechanism, but RB2 in area A2 can not receive the PDU from RB1, and it  can also get the nickname N1 from  
dynamical range. So the question is how to avoid the duplication = dynamical range nickname for different areas.

(4) The risk of running out of nickname maybe a issue for TRILL. The = number of 2**16 nickname is enough for the current data center,
but it maybe not enough in the future, especailly if TRILL over IP , = TRILL over MPLS technology or some other data center technologies
are deployed, the data center network can be a very lardge network. So i think the very important and essential goal of multi-level draft is to save nicknames.

Best regards
Fangwei Hu

"Tissa Senevirathne = (tsenevir)" <tsenevir@cisco.com>
=B7=A2=BC=FE=C8=CB: =  rbridge-bounces@postel.org

2012-02-23 11:55


=CA=D5=BC=FE=C8=CB
<rbridge@postel.org>=
=B3=AD=CB=CD
=D6=F7=CC=E2
[rbridge] Default nickname base = approach for multilevel TRILL-       =  draft-tissa-trill-multilevel-00.txt
=

 






Dear All

We have submitted draft-tissa-trill-multilevel, present multilevel TRILL based on default nickname approach. Additionally we discuss construction of multi-destination trees and related RPF in multilevel TRILL. Please could you review and comment

Detail of the draft and abstract are below.

Filename:                 =  draft-tissa-trill-multilevel
Revision:                 =  00
Title:                   =                 Default Nickname Based Approach for Multilevel TRILL
Creation date:                  2012-02-21
WG ID:                   =                 Individual = Submission
Number of pages: 26

Abstract:
 Multilevel TRILL allows the interconnection of multiple TRILL
 networks to form a larger TRILL network without = proportionally
 increasing the size of the IS-IS LSP DB. In this document, an
 approach based on default route concept is presented. Also,
 presented in the document is a novel method of constructing = multi-
 destination trees using partial nickname space. Methods presented in
 this document are compatible with the RFC6325 specified data = plane
 operations.

                                        =                       =                  
Thanks
Tissa

_______________________________________________
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<= /u>

 
 

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


= --Apple-Mail=_00CCAFBA-E094-491E-A582-5B5B09E73A0F-- --===============0835106105== 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 --===============0835106105==-- From rbridge-bounces@postel.org Sun Feb 26 20:43:39 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 F348221E8019 for ; Sun, 26 Feb 2012 20:43:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.006 X-Spam-Level: X-Spam-Status: No, score=-3.006 tagged_above=-999 required=5 tests=[AWL=0.541, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=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 W3AS-P3evNPJ for ; Sun, 26 Feb 2012 20:43:36 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id CF52C21E800F for ; Sun, 26 Feb 2012 20:43:36 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1R3wdMt010153; Sun, 26 Feb 2012 19:58:41 -0800 (PST) Received: from mail-pw0-f52.google.com (mail-pw0-f52.google.com [209.85.160.52]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1R3wDXv009780 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sun, 26 Feb 2012 19:58:22 -0800 (PST) Received: by pbcum15 with SMTP id um15so1219494pbc.39 for ; Sun, 26 Feb 2012 19:58:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=w0QLcJ3Su2mB0ybp6evXnjJJmfgTzAKsugQe8pZk+Fs=; b=rKlOX/mAKcUIE77jcZLm0YmwXUJZ7lIKvkU8T0AhG6SZ88MX04ZHNYhw4B/Dw+D967 ORQYHB59jQUqWu3ACI3PaNzaGhC1txumxLiaZs3jzijRmt5dEy0bDrxR5FiqsQZsTqTB mpEioF2Ug9iPpNKhesDlbHgjsOD+A/HHb9iTs= Received: by 10.68.225.231 with SMTP id rn7mr30161596pbc.64.1330315093134; Sun, 26 Feb 2012 19:58:13 -0800 (PST) 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 q10sm11527231pbb.10.2012.02.26.19.58.10 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 26 Feb 2012 19:58:12 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) From: Sam Aldrin In-Reply-To: Date: Sun, 26 Feb 2012 19:58:09 -0800 Message-Id: <521E9E8C-F557-43EA-A8C1-C1E49A668CF5@gmail.com> References: To: hu.fangwei@zte.com.cn X-Mailer: Apple Mail (2.1257) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: aldrin.ietf@gmail.com Cc: rbridge@postel.org, rbridge-bounces@postel.org, "Tissa Senevirathne \(tsenevir\)" , Radia Perlman Subject: Re: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.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: multipart/mixed; boundary="===============1022828286==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org --===============1022828286== Content-Type: multipart/alternative; boundary="Apple-Mail=_AA3BEF18-3834-4EBE-AE3E-A8403C337E29" --Apple-Mail=_AA3BEF18-3834-4EBE-AE3E-A8403C337E29 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 On Feb 26, 2012, at 7:47 PM, hu.fangwei@zte.com.cn wrote: >=20 > Pls see the following:=20 >=20 >=20 > The reason why folks in IP word are pushing to go to IPv6 is that the = exhausting of IPv4 address, not that the NAT can not work.=20 > The NAT technology is widely deployed in China, and it does work well. = There is very little IPv4 address can be assigned to the BNAS(Most of = the address assigned to the user are private IPv4 address, and only the = NNAS and above equitment are assigned public address ), so it is an = emergent thing to transit from IPv4 to IPv6.=20 > And your point is?=20 >=20 > [hfw] My point is that the multi-level draft should solve the nickname = space issue.=20 Then why is the draft not named accordingly? >=20 > There is a multi-level draft is proposed by Radia, we can optimize it = and make it better. There is no need to provide a new Multi-lelve draft = which can not solve the key issue of nickname space.=20 You mentioned that NAT couldn't solve the name exhaustion issue in IP = world, why do you say that similar model solves nickname exhaustion = issue in TRILL? If you truly want to solve nickname issue, attempted should be outside = of multilevel draft. As you said, we should rather have TrillIPv6 or = whatever. -sam >=20 >=20 >=20 >=20 > Sam Aldrin > 2012-02-27 11:40 >=20 > =CA=D5=BC=FE=C8=CB > hu.fangwei@zte.com.cn > =B3=AD=CB=CD > "Tissa Senevirathne (tsenevir)" , = rbridge@postel.org, rbridge-bounces@postel.org, Radia Perlman = > =D6=F7=CC=E2 > Re: [rbridge] Default nickname base approach for multilevel TRILL- = draft-tissa-trill-multilevel-00.txt >=20 >=20 >=20 >=20 >=20 >=20 > On Feb 26, 2012, at 6:50 PM, hu.fangwei@zte.com.cn wrote:=20 >=20 >=20 > The reason why folks in IP word are pushing to go to IPv6 is that the = exhausting of IPv4 address, not that the NAT can not work.=20 > The NAT technology is widely deployed in China, and it does work well. = There is very little IPv4 address can be assigned to the BNAS(Most of = the address assigned to the user are private IPv4 address, and only the = NNAS and above equitment are assigned public address ), so it is an = emergent thing to transit from IPv4 to IPv6.=20 > And your point is?=20 >=20 > If we can not slove the nickname space issue now, do we need another = NICKNAMEv6 or something else?=20 > That could be a topic, which could be taken up to resolve nickname = exhaustion issue and not necessarily at multilevel draft.=20 >=20 > So i thing the nickname space issue is the key issue we should slove = now.=20 > That topic should be considered outside of this draft.=20 >=20 > Multi-level draft is a good platform to slove it, though there is some = technology we should considered futher.=20 > If multilevel draft is only to address 'nickname exhaustion' issue, = then it should be renamed accordingly and not 'multilevel'. The purpose = of multilevel draft is different, which is stated in the draft and the = by product of it is nickname exhaustion could be alleviated and not just = the primary problem/solution. Here is the snip from abstract "..novel = method of constructing multi-destination trees using partial nickname = space"=20 >=20 > cheers=20 > -sam=20 >=20 >=20 >=20 > "Tissa Senevirathne (tsenevir)" =20 > =B7=A2=BC=FE=C8=CB: rbridge-bounces@postel.org > 2012-02-25 02:07 >=20 >=20 > =CA=D5=BC=FE=C8=CB > "Radia Perlman" > =B3=AD=CB=CD > rbridge@postel.org, rbridge-bounces@postel.org, hu.fangwei@zte.com.cn =20= > =D6=F7=CC=E2 > Re: [rbridge] Default nickname base approach for multilevel TRILL- = draft-tissa-trill-multilevel-00.txt >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Also, there are so many well known issues with NAT like approaches. #1 = is you would lose identity of originator, and it becomes an OAM = nightmare. It limit ability apply certain ACL, rate-limiting etc.=20 > =20 > There is a whole series of issues associated with NATs. That is one of = the reasons folks in IP world are pushing hard to go to IPv6. I was = assuming people are aware of those.=20 > =20 > From: Radia Perlman [mailto:radiaperlman@gmail.com]=20 > Sent: Friday, February 24, 2012 9:23 AM > To: Tissa Senevirathne (tsenevir) > Cc: hu.fangwei@zte.com.cn; rbridge@postel.org; = rbridge-bounces@postel.org > Subject: Re: [rbridge] Default nickname base approach for multilevel = TRILL- draft-tissa-trill-multilevel-00.txt=20 > =20 > I assume that all RBridges will need to be in all topologies, so = multitopology will not help with nickname exhaustion. Plus you haven't = explained how a TRILL packet would be marked as to which topology the = packet should be routed according to (other than what I mentioned, which = actually eats up nicknames by a factor of the number of topologies = supported).=20 > =20 > Plus, rather than just lumping potential issues into a phrase such as = "NAT-like", be explicit about what issues there actually are. I believe = the Fulcrum chip would have no problem with translating the nickname = fields.=20 > =20 > And rather than assuming that nickname exhaustion can be solved "some = other way", there should be a palatable solution before rejecting a = chance to solve it with multilevel.=20 > =20 > Radia=20 > 2012/2/24 Tissa Senevirathne (tsenevir) =20 > Because you can have same nickname for different topology. It is not a = nickname that will identify an RBRidge, it is topology,nickname = combination that will identify an RBRidge. So RB1 can have nickname 1 in = topo-1 and RB2 can have nickname 1 in topo2. Now total nicknames in the = campus is 2**16 x topologies.=20 > =20 > Stealing bits to represent topo id is only a workaround there can be = (are ) more elegant ways of doing it that.=20 > =20 > Bottom line is we need to look for more creative methods of solving = nickname space issue than doing NAT like behavior.=20 > =20 > From: Radia Perlman [mailto:radiaperlman@gmail.com]=20 > Sent: Friday, February 24, 2012 9:05 AM > To: Tissa Senevirathne (tsenevir) > Cc: hu.fangwei@zte.com.cn; rbridge@postel.org; = rbridge-bounces@postel.org=20 >=20 > Subject: Re: [rbridge] Default nickname base approach for multilevel = TRILL- draft-tissa-trill-multilevel-00.txt=20 > =20 > I don't understand how multi-topology helps with the nickname = exhaustion issue. As a matter of fact, the only plausible way of = marking a packet for which topology that has been suggested on the = mailing list (I asked a efw times if there were any other = possibilities), was to steal 2 or 3 bits of the nickname to encode which = topology, in effect, making a destination appear as multiple = destinations and multiple forwarding table entries (which you'd want = anyway, for multitopology).=20 > =20 > =20 > Radia=20 > 2012/2/24 Tissa Senevirathne (tsenevir) =20 > Mutli-topology is the answer to increase the nickname space.=20 > =20 > Nickname translation is very similar to NAT, which has it=A1=AFs own = down side, not to mention special hardware etc. to do the translations, = additionally. We also know from our experience, in IP world NATing is = not the most desired behavior and we live with it. So we should not be = going down that path instead need to look forward from that experience.=20= > =20 > Multi-topology not only address nickname space issue but also enables = various other applications such as overlay topologies, traffic = engineering.=20 > =20 > The draft-tiss-trill-multilevel present approaches that are generic, = which mean it can be applied for multi-topology, or base topology. It = utilizes the fundamentals of IS-IS , such as Area hierarchy for = reduction of the LSP-DB. It utilize affinity TLV concepts to effectively = solve multi-destination issues.=20 > =20 > We should not mix-up between Data center interconnects with data = center node scaling. They are two different and orthogonal issues.=20 > =20 > Objective of multi-level trill is to interconnect different = datacenters, and maintain LSP-DB small as possible to avoid scaling and = volatility.=20 > =20 > Increasing nickname space a different requirement and has nothing to = do with data-center interconnects.=20 > =20 > =20 > From: Radia Perlman [mailto:radiaperlman@gmail.com]=20 > Sent: Friday, February 24, 2012 6:15 AM > To: hu.fangwei@zte.com.cn > Cc: Tissa Senevirathne (tsenevir); rbridge@postel.org; = rbridge-bounces@postel.org > Subject: Re: [rbridge] Default nickname base approach for multilevel = TRILL- draft-tissa-trill-multilevel-00.txt=20 > =20 > People have mentioned to me that they are nervous about running out of = nicknames, especially since there are reasonson why they might want to = assign nicknames to hypervisors. With the alternate approach of = allowing nicknames to be reused in different areas, it makes automatic = nickname assignment much simpler and makes TRILL a lot more scalable.=20 > =20 > It does have the downside of requiring mapping of nicknames at the = border RBridges.=20 > =20 > And by the way, the affinity TLV can be used for multidestination = frames transiting between level 1 and level 2.=20 > =20 > Radia=20 > 2012/2/23 =20 >=20 > Hi, Tissa.=20 >=20 > I have several comments about the draft.=20 >=20 > (1) in section 4.4 (Multicast), "The scope of global traffic may be = identified either through VLAN or via finegrain=20 > label that spans across the entire TRILL campus."=20 > Vlan and Fine-grain Label is used for service differentiation and = isolation. I do not quite understand that how to=20 > use VLAN and fine-grain Lable to identify the traffic scope. The data = traffic with a given VLAN-x, can=20 > be forwarded to other end station in the local area, or to the end = station in remote areas.=20 >=20 > (2) nickname allocation=20 > The nickname management sub-TLV is proposed in the document. I wonder = this mechanism adds the complication of =20 > nickname allocation. As the section 1 (introduction) of RFC6325, one = of the important advantage of TRILL is that =20 > it avoids the creating subnets of IP address and wasting address. The = nickname acquisition method in this draft violates the =20 > idea of TRILL Basic specification, and reduces the flexibility of = nickname allocation. As the draft assumed, A1 had =20 > nickname range of 100-200, A2 has a local nickname range of 201-300. = If the numbers of A1 area is only 50, so 50 =20 > nicknames in A1 is wasted. As the network growing, the number of some = areas may exceed the number being allocation =20 > by Border RBridges. The design and maintaining of nickname ranges for = each area is a very hard work. Even worst, it =20 > can not avoid to waste nickname space.=20 >=20 > (3) Dynamic ranges=20 > The nickname range is divided into two range: local range and = dynamical range. I wonder the nickname conflict =20 > resolution can not work if the RBridge get the nickname from the = dynamical range while the two RBridge belongs to =20 > different areas. For example, RB1 is in area A1, and RB2 is in area = A2. If RB1 gets the nickname N1 from dynamic =20 > range, and it will floods in area A1, and other RBridges in area A1 = can not get nickname N1 because of nickname =20 > confliction mechanism, but RB2 in area A2 can not receive the PDU from = RB1, and it can also get the nickname N1 from =20 > dynamical range. So the question is how to avoid the duplication = dynamical range nickname for different areas.=20 >=20 > (4) The risk of running out of nickname maybe a issue for TRILL. The = number of 2**16 nickname is enough for the current data center,=20 > but it maybe not enough in the future, especailly if TRILL over IP , = TRILL over MPLS technology or some other data center technologies=20 > are deployed, the data center network can be a very lardge network. So = i think the very important and essential goal of multi-level draft is to = save nicknames.=20 >=20 > Best regards=20 > Fangwei Hu > "Tissa Senevirathne (tsenevir)" =20 > =B7=A2=BC=FE=C8=CB: rbridge-bounces@postel.org > 2012-02-23 11:55 >=20 >=20 > =CA=D5=BC=FE=C8=CB > > =B3=AD=CB=CD > =D6=F7=CC=E2 > [rbridge] Default nickname base approach for multilevel TRILL- = draft-tissa-trill-multilevel-00.txt >=20 >=20 > =20 >=20 >=20 >=20 >=20 >=20 > Dear All >=20 > We have submitted draft-tissa-trill-multilevel, present multilevel = TRILL based on default nickname approach. Additionally we discuss = construction of multi-destination trees and related RPF in multilevel = TRILL. Please could you review and comment=20 >=20 > Detail of the draft and abstract are below. >=20 > Filename: draft-tissa-trill-multilevel > Revision: 00 > Title: Default Nickname Based = Approach for Multilevel TRILL > Creation date: 2012-02-21 > WG ID: Individual Submission > Number of pages: 26 >=20 > Abstract: > Multilevel TRILL allows the interconnection of multiple TRILL > networks to form a larger TRILL network without proportionally > increasing the size of the IS-IS LSP DB. In this document, an > approach based on default route concept is presented. Also, > presented in the document is a novel method of constructing multi- > destination trees using partial nickname space. Methods presented in > this document are compatible with the RFC6325 specified data plane > operations. >=20 > = =20 > Thanks > Tissa >=20 > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge=20 >=20 > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge=20 > =20 > =20 > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge >=20 > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge >=20 >=20 >=20 --Apple-Mail=_AA3BEF18-3834-4EBE-AE3E-A8403C337E29 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=GB2312 hu.fangwei@zte.com.cn = wrote:


Pls see the following:


The reason why folks in IP word = are pushing to go to IPv6 is that the exhausting of IPv4 address, not that the NAT can not work.
The NAT technology is widely = deployed in China, and it does work well. There is very little IPv4 address can be assigned to the BNAS(Most of the address assigned to the user are = private IPv4 address, and only the NNAS and above equitment are assigned public address ), so it is an emergent thing to transit from IPv4 to = IPv6.
And your point is?

[hfw] My point is that the = multi-level draft should solve the nickname space issue.
Then why is the draft not named = accordingly?

There is a multi-level draft is = proposed by Radia, we can optimize it and make it better. There is no need to = provide a new Multi-lelve draft which can not solve the key issue of nickname = space.
You mentioned that NAT couldn't solve the name = exhaustion issue in IP world, why do you say that similar model solves = nickname exhaustion issue in TRILL?
If you truly want to solve = nickname issue, attempted should be outside of multilevel draft. As you = said, we should rather have TrillIPv6 or = whatever.

-sam


Sam Aldrin = <aldrin.ietf@gmail.com>

2012-02-27 11:40

=CA=D5=BC=FE=C8=CB
hu.fangwei@zte.com.cn
=B3=AD=CB=CD
"Tissa Senevirathne = (tsenevir)" <tsenevir@cisco.com>, rbridge@postel.org, rbridge-bounces@postel.org,= Radia Perlman <radiaperlman@gmail.com>
=D6=F7=CC=E2
Re: [rbridge] Default = nickname base approach for multilevel TRILL- = draft-tissa-trill-multilevel-00.txt






On Feb 26, 2012, at 6:50 PM, = hu.fangwei@zte.com.cn wrote:


The reason why folks in IP word are pushing to go to IPv6 is that the = exhausting of IPv4 address, not that the NAT can not work.
The NAT technology is widely = deployed in China, and it does work well. There is very little IPv4 address can be assigned to the BNAS(Most of the address assigned to the user are = private IPv4 address, and only the NNAS and above equitment are assigned public address ), so it is an emergent thing to transit from IPv4 to = IPv6.
And your point is?

If we can not slove the nickname space issue now, do we need another = NICKNAMEv6 or something else?
That could be a topic, which = could be taken up to resolve nickname exhaustion issue and not necessarily at = multilevel draft.

So i thing the nickname space issue is the key issue we should slove = now.
That topic should be considered = outside of this draft.

Multi-level draft is a good platform to slove it, though there is some technology we should considered futher.
If multilevel draft is only to = address 'nickname exhaustion' issue, then it should be renamed accordingly and not 'multilevel'. The purpose of multilevel draft is different, which is stated in the draft and the by product of it is nickname exhaustion = could be alleviated and not just the primary problem/solution. Here is the = snip from abstract "..novel method of = constructing multi-destination trees using partial nickname space"

cheers
-sam



"Tissa = Senevirathne (tsenevir)" <tsenevir@cisco.com>
=B7=A2=BC=FE=C8=CB:  rbridge-bounces@postel.org

2012-02-25 02:07


=CA=D5=BC=FE=C8=CB
"Radia = Perlman" <radiaperlman@gmail.com>
=B3=AD=CB=CD
rbridge@postel.org, rbridge-bounces@postel.org, hu.fangwei@zte.com.cn
=D6=F7=CC=E2
Re: [rbridge] Default = nickname base approach for multilevel TRILL-       =  draft-tissa-trill-multilevel-00.txt
=






Also, there are so many well known issues with NAT like approaches. #1 is you would lose identity of originator, and it becomes an OAM = nightmare.  It limit ability apply certain ACL, rate-limiting etc.
 
There is a whole series of issues associated with NATs. That is one of the reasons folks in IP world are pushing hard to go to IPv6. I was = assuming people are aware of those. =
 
From: Radia Perlman [mailto:radiaperlman@gmail.com]
Sent: Friday, February 24, 2012 9:23 AM
To: Tissa Senevirathne (tsenevir)
Cc: hu.fangwei@zte.com.cn; rbridge@postel.org; rbridge-bounces@postel.org
Subject: Re: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.txt
 
I assume that all RBridges will need to be in all topologies, so = multitopology will not help with nickname exhaustion.  Plus you haven't explained how a TRILL packet would be marked as to which topology the packet = should be routed according to (other than what I mentioned, which actually eats up nicknames by a factor of the number of topologies supported).
 
Plus, rather than just lumping potential issues into a phrase such as = "NAT-like", be explicit about what issues there actually are.  I believe the = Fulcrum chip would have no problem with translating the nickname fields.
 
And rather than assuming that nickname exhaustion can be solved "some other way", there should be a palatable solution before rejecting a chance to solve it with multilevel.
 
Radia
2012/2/24 Tissa Senevirathne (tsenevir) <tsenevir@cisco.com>
Because you can have same nickname for different topology. It is not a nickname that will identify an RBRidge, it is topology,nickname = combination that will identify an RBRidge. So RB1 can have nickname 1 in topo-1 and RB2 can have nickname 1 in topo2. Now total nicknames in the campus is 2**16 x topologies. =
 
Stealing bits to represent topo id is only a workaround there can be = (are ) more elegant ways of doing it that.
 
Bottom line is we need to look for more creative methods of solving = nickname space issue than doing NAT like behavior.
 
From: Radia Perlman [mailto:radiaperlman@gmail.com]
Sent: Friday, February 24, 2012 9:05 AM
To: Tissa Senevirathne (tsenevir)
Cc: hu.fangwei@zte.com.cn; rbridge@postel.org; rbridge-bounces@postel.org

Subject: Re: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.txt
 
I don't understand how multi-topology helps with the nickname exhaustion issue.  As a matter of fact, the only plausible way of marking a = packet for which topology that has been suggested on the mailing list (I asked a efw times if there were any other possibilities), was to steal 2 or 3 bits of the nickname to encode which topology, in effect, making a = destination appear as multiple destinations and multiple forwarding table entries = (which you'd want anyway, for multitopology).
 
 
Radia
2012/2/24 Tissa Senevirathne (tsenevir) <tsenevir@cisco.com>
Mutli-topology is the answer to increase the nickname space.
 
Nickname translation is very similar to NAT, which has it=A1=AFs own = down side, not to mention special hardware etc. to do the translations, = additionally. We also know from our experience, in IP world NATing is not the most = desired behavior and we live with it. So we should not be going down that path instead need to look forward from that experience.
 
Multi-topology not only address nickname space issue but also enables = various other applications such as overlay topologies, traffic = engineering.
 
The draft-tiss-trill-multilevel present approaches that are generic, = which mean it can be applied for multi-topology, or base topology. It utilizes the fundamentals of IS-IS , such as Area hierarchy for reduction of the LSP-DB. It utilize affinity TLV concepts to effectively solve = multi-destination issues.
 
We should not mix-up between Data center interconnects with data center node scaling. They are two different and orthogonal issues.
 
Objective of multi-level trill is to interconnect different datacenters, and maintain LSP-DB small as possible to avoid scaling and = volatility.
 
Increasing nickname space a different requirement and has nothing to do with data-center interconnects.
 
 
From: Radia Perlman [mailto:radiaperlman@gmail.com]
Sent: Friday, February 24, 2012 6:15 AM
To: hu.fangwei@zte.com.cn
Cc: Tissa Senevirathne (tsenevir); rbridge@postel.org; rbridge-bounces@postel.org
Subject: Re: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.txt
 
People have mentioned to me that they are nervous about running out of nicknames, especially since there are reasonson why they might want to assign nicknames to hypervisors.  With the alternate approach of = allowing nicknames to be reused in different areas, it makes automatic nickname assignment much simpler and makes TRILL a lot more scalable.
 
It does have the downside of requiring mapping of nicknames at the = border RBridges.
 
And by the way, the affinity TLV can be used for multidestination frames transiting between level 1 and level 2.
 
Radia
2012/2/23 <hu.fangwei@zte.com.cn>

Hi, Tissa.

I have several comments about the draft.

(1) in section 4.4 (Multicast), "The scope of global traffic may be identified either through VLAN or via finegrain
label that spans across the entire TRILL campus."
Vlan and Fine-grain Label is used for service differentiation and = isolation. I do not quite understand that how to
use VLAN and fine-grain Lable to identify the traffic scope. The data = traffic with a given VLAN-x, can
be forwarded to other end station in the local area, or to the end = station in remote areas.

(2) nickname allocation =
The nickname management sub-TLV is proposed in the document. I wonder = this mechanism adds the complication of  
nickname allocation. As the section 1 (introduction) of RFC6325, one of the important advantage of TRILL is that  
it avoids the creating subnets of IP address and wasting address. The = nickname acquisition  method in this draft violates the  
idea of TRILL Basic specification, and reduces the flexibility of = nickname allocation. As the draft assumed, A1 had  
nickname range of 100-200, A2 has a local nickname range of 201-300. If the numbers of A1 area is only 50, so 50  
nicknames in A1 is wasted. As the network growing, the number of some = areas may exceed the number being allocation  
by Border RBridges. The design and maintaining of nickname ranges for = each area is a very hard work. Even worst, it  
can not avoid to waste nickname space.

(3) Dynamic ranges
The nickname range is divided into two range: local range and dynamical range. I wonder the nickname conflict  
resolution can not work if the RBridge get the nickname from the = dynamical range while the two RBridge belongs to  
different areas. For example, RB1 is in area A1, and RB2 is in area A2. If RB1 gets the nickname N1 from dynamic  
range, and it will floods in area A1, and other RBridges in area A1 can not get nickname N1 because of nickname  
confliction mechanism, but RB2 in area A2 can not receive the PDU from RB1, and it  can also get the nickname N1 from  
dynamical range. So the question is how to avoid the duplication = dynamical range nickname for different areas.

(4) The risk of running out of nickname maybe a issue for TRILL. The = number of 2**16 nickname is enough for the current data center,
but it maybe not enough in the future, especailly if TRILL over IP , = TRILL over MPLS technology or some other data center technologies
are deployed, the data center network can be a very lardge network. So i think the very important and essential goal of multi-level draft is to save nicknames.

Best regards
Fangwei Hu

"Tissa Senevirathne = (tsenevir)" <tsenevir@cisco.com>
=B7=A2=BC=FE=C8=CB: =  rbridge-bounces@postel.org

2012-02-23 11:55


=CA=D5=BC=FE=C8=CB
<rbridge@postel.org>=
=B3=AD=CB=CD
=D6=F7=CC=E2
[rbridge] Default nickname base = approach for multilevel TRILL-       =  draft-tissa-trill-multilevel-00.txt
=

 






Dear All

We have submitted draft-tissa-trill-multilevel, present multilevel TRILL based on default nickname approach. Additionally we discuss construction of multi-destination trees and related RPF in multilevel TRILL. Please could you review and comment

Detail of the draft and abstract are below.

Filename:                 =  draft-tissa-trill-multilevel
Revision:                 =  00
Title:                   =                 Default Nickname Based Approach for Multilevel TRILL
Creation date:                  2012-02-21
WG ID:                   =                 Individual = Submission
Number of pages: 26

Abstract:
Multilevel TRILL allows the interconnection of multiple TRILL
networks to form a larger TRILL network without proportionally
increasing the size of the IS-IS LSP DB. In this document, an
approach based on default route concept is presented. Also,
presented in the document is a novel method of constructing multi-
destination trees using partial nickname space. Methods presented = in
this document are compatible with the RFC6325 specified data plane
operations.

                                        =                       =                  
Thanks
Tissa

_______________________________________________
rbridge mailing list
rbridge@postel.org
http://mailman.postel.org/mailman/listinfo/rbridge<= /u>

_______________________________________________
rbridge mailing list
rbridge@postel.org
http://mailman.postel.org/mailman/listinfo/rbridge<= /u>
 
 
_______________________________________________
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




= --Apple-Mail=_AA3BEF18-3834-4EBE-AE3E-A8403C337E29-- --===============1022828286== 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 --===============1022828286==-- From rbridge-bounces@postel.org Sun Feb 26 20:46: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 004A121E8015 for ; Sun, 26 Feb 2012 20:46:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.184 X-Spam-Level: X-Spam-Status: No, score=-101.184 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, MIME_HTML_MOSTLY=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, 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 SWhqYUnFmxlu for ; Sun, 26 Feb 2012 20:46:32 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 0883421E800F for ; Sun, 26 Feb 2012 20:46:31 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1R3maEb008611; Sun, 26 Feb 2012 19:48:38 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1R3lqdq008201; Sun, 26 Feb 2012 19:48:01 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 523732371461274; Mon, 27 Feb 2012 11:38:47 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 73687.4800652878; Mon, 27 Feb 2012 11:47:37 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q1R3lWiT084374; Mon, 27 Feb 2012 11:47:33 +0800 (GMT-8) (envelope-from hu.fangwei@zte.com.cn) In-Reply-To: <63D11BFF-F3DA-4D67-AAB4-434B0DB102E8@gmail.com> To: Sam Aldrin 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, 27 Feb 2012 11:47:33 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-02-27 11:47:35, Serialize complete at 2012-02-27 11:47:35 X-MAIL: mse02.zte.com.cn q1R3lWiT084374 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: hu.fangwei@zte.com.cn Cc: rbridge@postel.org, rbridge-bounces@postel.org, "Tissa Senevirathne \(tsenevir\)" , Radia Perlman Subject: Re: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.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: multipart/mixed; boundary="===============1889535298==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org This is a multipart message in MIME format. --===============1889535298== Content-Type: multipart/alternative; boundary="=_alternative 0014D40A482579B1_=" This is a multipart message in MIME format. --=_alternative 0014D40A482579B1_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 UGxzIHNlZSB0aGUgZm9sbG93aW5nOg0KDQoNClRoZSByZWFzb24gd2h5IGZvbGtzIGluIElQIHdv cmQgYXJlIHB1c2hpbmcgdG8gZ28gdG8gSVB2NiBpcyB0aGF0IHRoZSANCmV4aGF1c3Rpbmcgb2Yg SVB2NCBhZGRyZXNzLCBub3QgdGhhdCB0aGUgTkFUIGNhbiBub3Qgd29yay4gDQpUaGUgTkFUIHRl Y2hub2xvZ3kgaXMgd2lkZWx5IGRlcGxveWVkIGluIENoaW5hLCBhbmQgaXQgZG9lcyB3b3JrIHdl bGwuIA0KVGhlcmUgaXMgdmVyeSBsaXR0bGUgSVB2NCBhZGRyZXNzIGNhbiBiZSBhc3NpZ25lZCB0 byB0aGUgQk5BUyhNb3N0IG9mIHRoZSANCmFkZHJlc3MgYXNzaWduZWQgdG8gdGhlIHVzZXIgYXJl IHByaXZhdGUgSVB2NCBhZGRyZXNzLCBhbmQgb25seSB0aGUgTk5BUyANCmFuZCBhYm92ZSBlcXVp dG1lbnQgYXJlIGFzc2lnbmVkIHB1YmxpYyBhZGRyZXNzICksIHNvIGl0IGlzIGFuIGVtZXJnZW50 IA0KdGhpbmcgdG8gdHJhbnNpdCBmcm9tIElQdjQgdG8gSVB2Ni4gDQpBbmQgeW91ciBwb2ludCBp cz8NCg0KW2hmd10gTXkgcG9pbnQgaXMgdGhhdCB0aGUgbXVsdGktbGV2ZWwgZHJhZnQgc2hvdWxk IHNvbHZlIHRoZSBuaWNrbmFtZSANCnNwYWNlIGlzc3VlLg0KDQpUaGVyZSBpcyBhIG11bHRpLWxl dmVsIGRyYWZ0IGlzIHByb3Bvc2VkIGJ5IFJhZGlhLCB3ZSBjYW4gb3B0aW1pemUgaXQgYW5kIA0K bWFrZSBpdCBiZXR0ZXIuIFRoZXJlIGlzIG5vIG5lZWQgdG8gcHJvdmlkZSBhIG5ldyBNdWx0aS1s ZWx2ZSBkcmFmdCB3aGljaCANCmNhbiBub3Qgc29sdmUgdGhlIGtleSBpc3N1ZSBvZiBuaWNrbmFt ZSBzcGFjZS4NCg0KDQoNCg0KDQpTYW0gQWxkcmluIDxhbGRyaW4uaWV0ZkBnbWFpbC5jb20+IA0K MjAxMi0wMi0yNyAxMTo0MA0KDQrK1bz+yMsNCmh1LmZhbmd3ZWlAenRlLmNvbS5jbg0Ks63LzQ0K IlRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpIiA8dHNlbmV2aXJAY2lzY28uY29tPiwgcmJy aWRnZUBwb3N0ZWwub3JnLCANCnJicmlkZ2UtYm91bmNlc0Bwb3N0ZWwub3JnLCBSYWRpYSBQZXJs bWFuIDxyYWRpYXBlcmxtYW5AZ21haWwuY29tPg0K1vfM4g0KUmU6IFtyYnJpZGdlXSBEZWZhdWx0 IG5pY2tuYW1lIGJhc2UgYXBwcm9hY2ggZm9yIG11bHRpbGV2ZWwgVFJJTEwtIA0KZHJhZnQtdGlz c2EtdHJpbGwtbXVsdGlsZXZlbC0wMC50eHQNCg0KDQoNCg0KDQoNCg0KT24gRmViIDI2LCAyMDEy LCBhdCA2OjUwIFBNLCBodS5mYW5nd2VpQHp0ZS5jb20uY24gd3JvdGU6DQoNCg0KVGhlIHJlYXNv biB3aHkgZm9sa3MgaW4gSVAgd29yZCBhcmUgcHVzaGluZyB0byBnbyB0byBJUHY2IGlzIHRoYXQg dGhlIA0KZXhoYXVzdGluZyBvZiBJUHY0IGFkZHJlc3MsIG5vdCB0aGF0IHRoZSBOQVQgY2FuIG5v dCB3b3JrLiANClRoZSBOQVQgdGVjaG5vbG9neSBpcyB3aWRlbHkgZGVwbG95ZWQgaW4gQ2hpbmEs IGFuZCBpdCBkb2VzIHdvcmsgd2VsbC4gDQpUaGVyZSBpcyB2ZXJ5IGxpdHRsZSBJUHY0IGFkZHJl c3MgY2FuIGJlIGFzc2lnbmVkIHRvIHRoZSBCTkFTKE1vc3Qgb2YgdGhlIA0KYWRkcmVzcyBhc3Np Z25lZCB0byB0aGUgdXNlciBhcmUgcHJpdmF0ZSBJUHY0IGFkZHJlc3MsIGFuZCBvbmx5IHRoZSBO TkFTIA0KYW5kIGFib3ZlIGVxdWl0bWVudCBhcmUgYXNzaWduZWQgcHVibGljIGFkZHJlc3MgKSwg c28gaXQgaXMgYW4gZW1lcmdlbnQgDQp0aGluZyB0byB0cmFuc2l0IGZyb20gSVB2NCB0byBJUHY2 LiANCkFuZCB5b3VyIHBvaW50IGlzPw0KDQpJZiB3ZSBjYW4gbm90IHNsb3ZlIHRoZSBuaWNrbmFt ZSBzcGFjZSBpc3N1ZSBub3csIGRvIHdlIG5lZWQgYW5vdGhlciANCk5JQ0tOQU1FdjYgb3Igc29t ZXRoaW5nIGVsc2U/IA0KVGhhdCBjb3VsZCBiZSBhIHRvcGljLCB3aGljaCBjb3VsZCBiZSB0YWtl biB1cCB0byByZXNvbHZlIG5pY2tuYW1lIA0KZXhoYXVzdGlvbiBpc3N1ZSBhbmQgbm90IG5lY2Vz c2FyaWx5IGF0IG11bHRpbGV2ZWwgZHJhZnQuDQoNClNvIGkgdGhpbmcgdGhlIG5pY2tuYW1lIHNw YWNlIGlzc3VlIGlzIHRoZSBrZXkgaXNzdWUgd2Ugc2hvdWxkIHNsb3ZlIG5vdy4gDQpUaGF0IHRv cGljIHNob3VsZCBiZSBjb25zaWRlcmVkIG91dHNpZGUgb2YgdGhpcyBkcmFmdC4NCg0KTXVsdGkt bGV2ZWwgZHJhZnQgaXMgYSBnb29kIHBsYXRmb3JtIHRvIHNsb3ZlIGl0LCB0aG91Z2ggdGhlcmUg aXMgc29tZSANCnRlY2hub2xvZ3kgd2Ugc2hvdWxkIGNvbnNpZGVyZWQgZnV0aGVyLiANCklmIG11 bHRpbGV2ZWwgZHJhZnQgaXMgb25seSB0byBhZGRyZXNzICduaWNrbmFtZSBleGhhdXN0aW9uJyBp c3N1ZSwgdGhlbiANCml0IHNob3VsZCBiZSByZW5hbWVkIGFjY29yZGluZ2x5IGFuZCBub3QgJ211 bHRpbGV2ZWwnLiBUaGUgcHVycG9zZSBvZiANCm11bHRpbGV2ZWwgZHJhZnQgaXMgZGlmZmVyZW50 LCB3aGljaCBpcyBzdGF0ZWQgaW4gdGhlIGRyYWZ0IGFuZCB0aGUgYnkgDQpwcm9kdWN0IG9mIGl0 IGlzIG5pY2tuYW1lIGV4aGF1c3Rpb24gY291bGQgYmUgYWxsZXZpYXRlZCBhbmQgbm90IGp1c3Qg dGhlIA0KcHJpbWFyeSBwcm9ibGVtL3NvbHV0aW9uLiBIZXJlIGlzIHRoZSBzbmlwIGZyb20gYWJz dHJhY3QgIi4ubm92ZWwgbWV0aG9kIA0Kb2YgY29uc3RydWN0aW5nIG11bHRpLWRlc3RpbmF0aW9u IHRyZWVzIHVzaW5nIHBhcnRpYWwgbmlja25hbWUgc3BhY2UiDQoNCmNoZWVycw0KLXNhbQ0KDQoN Cg0KDQoiVGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZpcikiIDx0c2VuZXZpckBjaXNjby5jb20+ IA0Kt6K8/sjLOiAgcmJyaWRnZS1ib3VuY2VzQHBvc3RlbC5vcmcNCjIwMTItMDItMjUgMDI6MDcg DQoNCg0KytW8/sjLDQoiUmFkaWEgUGVybG1hbiIgPHJhZGlhcGVybG1hbkBnbWFpbC5jb20+IA0K s63LzQ0KcmJyaWRnZUBwb3N0ZWwub3JnLCByYnJpZGdlLWJvdW5jZXNAcG9zdGVsLm9yZywgaHUu ZmFuZ3dlaUB6dGUuY29tLmNuIA0K1vfM4g0KUmU6IFtyYnJpZGdlXSBEZWZhdWx0IG5pY2tuYW1l IGJhc2UgYXBwcm9hY2ggZm9yIG11bHRpbGV2ZWwgVFJJTEwtIA0KZHJhZnQtdGlzc2EtdHJpbGwt bXVsdGlsZXZlbC0wMC50eHQNCg0KDQoNCg0KDQoNCg0KDQpBbHNvLCB0aGVyZSBhcmUgc28gbWFu eSB3ZWxsIGtub3duIGlzc3VlcyB3aXRoIE5BVCBsaWtlIGFwcHJvYWNoZXMuICMxIGlzIA0KeW91 IHdvdWxkIGxvc2UgaWRlbnRpdHkgb2Ygb3JpZ2luYXRvciwgYW5kIGl0IGJlY29tZXMgYW4gT0FN IG5pZ2h0bWFyZS4gSXQgDQpsaW1pdCBhYmlsaXR5IGFwcGx5IGNlcnRhaW4gQUNMLCByYXRlLWxp bWl0aW5nIGV0Yy4gDQogIA0KVGhlcmUgaXMgYSB3aG9sZSBzZXJpZXMgb2YgaXNzdWVzIGFzc29j aWF0ZWQgd2l0aCBOQVRzLiBUaGF0IGlzIG9uZSBvZiB0aGUgDQpyZWFzb25zIGZvbGtzIGluIElQ IHdvcmxkIGFyZSBwdXNoaW5nIGhhcmQgdG8gZ28gdG8gSVB2Ni4gSSB3YXMgYXNzdW1pbmcgDQpw ZW9wbGUgYXJlIGF3YXJlIG9mIHRob3NlLiANCiAgDQpGcm9tOiBSYWRpYSBQZXJsbWFuIFttYWls dG86cmFkaWFwZXJsbWFuQGdtYWlsLmNvbV0gDQpTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDI0LCAy MDEyIDk6MjMgQU0NClRvOiBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKQ0KQ2M6IGh1LmZh bmd3ZWlAenRlLmNvbS5jbjsgcmJyaWRnZUBwb3N0ZWwub3JnOyByYnJpZGdlLWJvdW5jZXNAcG9z dGVsLm9yZw0KU3ViamVjdDogUmU6IFtyYnJpZGdlXSBEZWZhdWx0IG5pY2tuYW1lIGJhc2UgYXBw cm9hY2ggZm9yIG11bHRpbGV2ZWwgDQpUUklMTC0gZHJhZnQtdGlzc2EtdHJpbGwtbXVsdGlsZXZl bC0wMC50eHQgDQogDQpJIGFzc3VtZSB0aGF0IGFsbCBSQnJpZGdlcyB3aWxsIG5lZWQgdG8gYmUg aW4gYWxsIHRvcG9sb2dpZXMsIHNvIA0KbXVsdGl0b3BvbG9neSB3aWxsIG5vdCBoZWxwIHdpdGgg bmlja25hbWUgZXhoYXVzdGlvbi4gIFBsdXMgeW91IGhhdmVuJ3QgDQpleHBsYWluZWQgaG93IGEg VFJJTEwgcGFja2V0IHdvdWxkIGJlIG1hcmtlZCBhcyB0byB3aGljaCB0b3BvbG9neSB0aGUgDQpw YWNrZXQgc2hvdWxkIGJlIHJvdXRlZCBhY2NvcmRpbmcgdG8gKG90aGVyIHRoYW4gd2hhdCBJIG1l bnRpb25lZCwgd2hpY2ggDQphY3R1YWxseSBlYXRzIHVwIG5pY2tuYW1lcyBieSBhIGZhY3RvciBv ZiB0aGUgbnVtYmVyIG9mIHRvcG9sb2dpZXMgDQpzdXBwb3J0ZWQpLiANCiANClBsdXMsIHJhdGhl ciB0aGFuIGp1c3QgbHVtcGluZyBwb3RlbnRpYWwgaXNzdWVzIGludG8gYSBwaHJhc2Ugc3VjaCBh cyANCiJOQVQtbGlrZSIsIGJlIGV4cGxpY2l0IGFib3V0IHdoYXQgaXNzdWVzIHRoZXJlIGFjdHVh bGx5IGFyZS4gIEkgYmVsaWV2ZSANCnRoZSBGdWxjcnVtIGNoaXAgd291bGQgaGF2ZSBubyBwcm9i bGVtIHdpdGggdHJhbnNsYXRpbmcgdGhlIG5pY2tuYW1lIA0KZmllbGRzLiANCiANCkFuZCByYXRo ZXIgdGhhbiBhc3N1bWluZyB0aGF0IG5pY2tuYW1lIGV4aGF1c3Rpb24gY2FuIGJlIHNvbHZlZCAi c29tZSANCm90aGVyIHdheSIsIHRoZXJlIHNob3VsZCBiZSBhIHBhbGF0YWJsZSBzb2x1dGlvbiBi ZWZvcmUgcmVqZWN0aW5nIGEgY2hhbmNlIA0KdG8gc29sdmUgaXQgd2l0aCBtdWx0aWxldmVsLiAN CiANClJhZGlhIA0KMjAxMi8yLzI0IFRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpIDx0c2Vu ZXZpckBjaXNjby5jb20+IA0KQmVjYXVzZSB5b3UgY2FuIGhhdmUgc2FtZSBuaWNrbmFtZSBmb3Ig ZGlmZmVyZW50IHRvcG9sb2d5LiBJdCBpcyBub3QgYSANCm5pY2tuYW1lIHRoYXQgd2lsbCBpZGVu dGlmeSBhbiBSQlJpZGdlLCBpdCBpcyB0b3BvbG9neSxuaWNrbmFtZSANCmNvbWJpbmF0aW9uIHRo YXQgd2lsbCBpZGVudGlmeSBhbiBSQlJpZGdlLiBTbyBSQjEgY2FuIGhhdmUgbmlja25hbWUgMSBp biANCnRvcG8tMSBhbmQgUkIyIGNhbiBoYXZlIG5pY2tuYW1lIDEgaW4gdG9wbzIuIE5vdyB0b3Rh bCBuaWNrbmFtZXMgaW4gdGhlIA0KY2FtcHVzIGlzIDIqKjE2IHggdG9wb2xvZ2llcy4gDQogIA0K U3RlYWxpbmcgYml0cyB0byByZXByZXNlbnQgdG9wbyBpZCBpcyBvbmx5IGEgd29ya2Fyb3VuZCB0 aGVyZSBjYW4gYmUgKGFyZSANCikgbW9yZSBlbGVnYW50IHdheXMgb2YgZG9pbmcgaXQgdGhhdC4g DQogIA0KQm90dG9tIGxpbmUgaXMgd2UgbmVlZCB0byBsb29rIGZvciBtb3JlIGNyZWF0aXZlIG1l dGhvZHMgb2Ygc29sdmluZyANCm5pY2tuYW1lIHNwYWNlIGlzc3VlIHRoYW4gZG9pbmcgTkFUIGxp a2UgYmVoYXZpb3IuIA0KICANCkZyb206IFJhZGlhIFBlcmxtYW4gW21haWx0bzpyYWRpYXBlcmxt YW5AZ21haWwuY29tXSANClNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMjQsIDIwMTIgOTowNSBBTQ0K VG86IFRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpDQpDYzogaHUuZmFuZ3dlaUB6dGUuY29t LmNuOyByYnJpZGdlQHBvc3RlbC5vcmc7IHJicmlkZ2UtYm91bmNlc0Bwb3N0ZWwub3JnIA0KDQpT dWJqZWN0OiBSZTogW3JicmlkZ2VdIERlZmF1bHQgbmlja25hbWUgYmFzZSBhcHByb2FjaCBmb3Ig bXVsdGlsZXZlbCANClRSSUxMLSBkcmFmdC10aXNzYS10cmlsbC1tdWx0aWxldmVsLTAwLnR4dCAN CiANCkkgZG9uJ3QgdW5kZXJzdGFuZCBob3cgbXVsdGktdG9wb2xvZ3kgaGVscHMgd2l0aCB0aGUg bmlja25hbWUgZXhoYXVzdGlvbiANCmlzc3VlLiAgQXMgYSBtYXR0ZXIgb2YgZmFjdCwgdGhlIG9u bHkgcGxhdXNpYmxlIHdheSBvZiBtYXJraW5nIGEgcGFja2V0IA0KZm9yIHdoaWNoIHRvcG9sb2d5 IHRoYXQgaGFzIGJlZW4gc3VnZ2VzdGVkIG9uIHRoZSBtYWlsaW5nIGxpc3QgKEkgYXNrZWQgYSAN CmVmdyB0aW1lcyBpZiB0aGVyZSB3ZXJlIGFueSBvdGhlciBwb3NzaWJpbGl0aWVzKSwgd2FzIHRv IHN0ZWFsIDIgb3IgMyBiaXRzIA0Kb2YgdGhlIG5pY2tuYW1lIHRvIGVuY29kZSB3aGljaCB0b3Bv bG9neSwgaW4gZWZmZWN0LCBtYWtpbmcgYSBkZXN0aW5hdGlvbiANCmFwcGVhciBhcyBtdWx0aXBs ZSBkZXN0aW5hdGlvbnMgYW5kIG11bHRpcGxlIGZvcndhcmRpbmcgdGFibGUgZW50cmllcyANCih3 aGljaCB5b3UnZCB3YW50IGFueXdheSwgZm9yIG11bHRpdG9wb2xvZ3kpLiANCiANCiANClJhZGlh IA0KMjAxMi8yLzI0IFRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpIDx0c2VuZXZpckBjaXNj by5jb20+IA0KTXV0bGktdG9wb2xvZ3kgaXMgdGhlIGFuc3dlciB0byBpbmNyZWFzZSB0aGUgbmlj a25hbWUgc3BhY2UuIA0KICANCk5pY2tuYW1lIHRyYW5zbGF0aW9uIGlzIHZlcnkgc2ltaWxhciB0 byBOQVQsIHdoaWNoIGhhcyBpdKGvcyBvd24gZG93biANCnNpZGUsIG5vdCB0byBtZW50aW9uIHNw ZWNpYWwgaGFyZHdhcmUgZXRjLiB0byBkbyB0aGUgdHJhbnNsYXRpb25zLCANCmFkZGl0aW9uYWxs eS4gV2UgYWxzbyBrbm93IGZyb20gb3VyIGV4cGVyaWVuY2UsIGluIElQIHdvcmxkIE5BVGluZyBp cyBub3QgDQp0aGUgbW9zdCBkZXNpcmVkIGJlaGF2aW9yIGFuZCB3ZSBsaXZlIHdpdGggaXQuIFNv IHdlIHNob3VsZCBub3QgYmUgZ29pbmcgDQpkb3duIHRoYXQgcGF0aCBpbnN0ZWFkIG5lZWQgdG8g bG9vayBmb3J3YXJkIGZyb20gdGhhdCBleHBlcmllbmNlLiANCiAgDQpNdWx0aS10b3BvbG9neSBu b3Qgb25seSBhZGRyZXNzIG5pY2tuYW1lIHNwYWNlIGlzc3VlIGJ1dCBhbHNvIGVuYWJsZXMgDQp2 YXJpb3VzIG90aGVyIGFwcGxpY2F0aW9ucyBzdWNoIGFzIG92ZXJsYXkgdG9wb2xvZ2llcywgdHJh ZmZpYyANCmVuZ2luZWVyaW5nLiANCiAgDQpUaGUgZHJhZnQtdGlzcy10cmlsbC1tdWx0aWxldmVs IHByZXNlbnQgYXBwcm9hY2hlcyB0aGF0IGFyZSBnZW5lcmljLCB3aGljaCANCm1lYW4gaXQgY2Fu IGJlIGFwcGxpZWQgZm9yIG11bHRpLXRvcG9sb2d5LCBvciBiYXNlIHRvcG9sb2d5LiBJdCB1dGls aXplcyANCnRoZSBmdW5kYW1lbnRhbHMgb2YgSVMtSVMgLCBzdWNoIGFzIEFyZWEgaGllcmFyY2h5 IGZvciByZWR1Y3Rpb24gb2YgdGhlIA0KTFNQLURCLiBJdCB1dGlsaXplIGFmZmluaXR5IFRMViBj b25jZXB0cyB0byBlZmZlY3RpdmVseSBzb2x2ZSANCm11bHRpLWRlc3RpbmF0aW9uIGlzc3Vlcy4g DQogIA0KV2Ugc2hvdWxkIG5vdCBtaXgtdXAgYmV0d2VlbiBEYXRhIGNlbnRlciBpbnRlcmNvbm5l Y3RzIHdpdGggZGF0YSBjZW50ZXIgDQpub2RlIHNjYWxpbmcuIFRoZXkgYXJlIHR3byBkaWZmZXJl bnQgYW5kIG9ydGhvZ29uYWwgaXNzdWVzLiANCiAgDQpPYmplY3RpdmUgb2YgbXVsdGktbGV2ZWwg dHJpbGwgaXMgdG8gaW50ZXJjb25uZWN0IGRpZmZlcmVudCBkYXRhY2VudGVycywgDQphbmQgbWFp bnRhaW4gTFNQLURCIHNtYWxsIGFzIHBvc3NpYmxlIHRvIGF2b2lkIHNjYWxpbmcgYW5kIHZvbGF0 aWxpdHkuIA0KICANCkluY3JlYXNpbmcgbmlja25hbWUgc3BhY2UgYSBkaWZmZXJlbnQgcmVxdWly ZW1lbnQgYW5kIGhhcyBub3RoaW5nIHRvIGRvIA0Kd2l0aCBkYXRhLWNlbnRlciBpbnRlcmNvbm5l Y3RzLiANCiAgDQogIA0KRnJvbTogUmFkaWEgUGVybG1hbiBbbWFpbHRvOnJhZGlhcGVybG1hbkBn bWFpbC5jb21dIA0KU2VudDogRnJpZGF5LCBGZWJydWFyeSAyNCwgMjAxMiA2OjE1IEFNDQpUbzog aHUuZmFuZ3dlaUB6dGUuY29tLmNuDQpDYzogVGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZpcik7 IHJicmlkZ2VAcG9zdGVsLm9yZzsgDQpyYnJpZGdlLWJvdW5jZXNAcG9zdGVsLm9yZw0KU3ViamVj dDogUmU6IFtyYnJpZGdlXSBEZWZhdWx0IG5pY2tuYW1lIGJhc2UgYXBwcm9hY2ggZm9yIG11bHRp bGV2ZWwgDQpUUklMTC0gZHJhZnQtdGlzc2EtdHJpbGwtbXVsdGlsZXZlbC0wMC50eHQgDQogDQpQ ZW9wbGUgaGF2ZSBtZW50aW9uZWQgdG8gbWUgdGhhdCB0aGV5IGFyZSBuZXJ2b3VzIGFib3V0IHJ1 bm5pbmcgb3V0IG9mIA0Kbmlja25hbWVzLCBlc3BlY2lhbGx5IHNpbmNlIHRoZXJlIGFyZSByZWFz b25zb24gd2h5IHRoZXkgbWlnaHQgd2FudCB0byANCmFzc2lnbiBuaWNrbmFtZXMgdG8gaHlwZXJ2 aXNvcnMuICBXaXRoIHRoZSBhbHRlcm5hdGUgYXBwcm9hY2ggb2YgYWxsb3dpbmcgDQpuaWNrbmFt ZXMgdG8gYmUgcmV1c2VkIGluIGRpZmZlcmVudCBhcmVhcywgaXQgbWFrZXMgYXV0b21hdGljIG5p Y2tuYW1lIA0KYXNzaWdubWVudCBtdWNoIHNpbXBsZXIgYW5kIG1ha2VzIFRSSUxMIGEgbG90IG1v cmUgc2NhbGFibGUuIA0KIA0KSXQgZG9lcyBoYXZlIHRoZSBkb3duc2lkZSBvZiByZXF1aXJpbmcg bWFwcGluZyBvZiBuaWNrbmFtZXMgYXQgdGhlIGJvcmRlciANClJCcmlkZ2VzLiANCiANCkFuZCBi eSB0aGUgd2F5LCB0aGUgYWZmaW5pdHkgVExWIGNhbiBiZSB1c2VkIGZvciBtdWx0aWRlc3RpbmF0 aW9uIGZyYW1lcyANCnRyYW5zaXRpbmcgYmV0d2VlbiBsZXZlbCAxIGFuZCBsZXZlbCAyLiANCiAN ClJhZGlhIA0KMjAxMi8yLzIzIDxodS5mYW5nd2VpQHp0ZS5jb20uY24+IA0KDQpIaSwgVGlzc2Eu IA0KDQpJIGhhdmUgc2V2ZXJhbCBjb21tZW50cyBhYm91dCB0aGUgZHJhZnQuIA0KDQooMSkgaW4g c2VjdGlvbiA0LjQgKE11bHRpY2FzdCksICJUaGUgc2NvcGUgb2YgZ2xvYmFsIHRyYWZmaWMgbWF5 IGJlIA0KaWRlbnRpZmllZCBlaXRoZXIgdGhyb3VnaCBWTEFOIG9yIHZpYSBmaW5lZ3JhaW4gDQps YWJlbCB0aGF0IHNwYW5zIGFjcm9zcyB0aGUgZW50aXJlIFRSSUxMIGNhbXB1cy4iIA0KVmxhbiBh bmQgRmluZS1ncmFpbiBMYWJlbCBpcyB1c2VkIGZvciBzZXJ2aWNlIGRpZmZlcmVudGlhdGlvbiBh bmQgDQppc29sYXRpb24uIEkgZG8gbm90IHF1aXRlIHVuZGVyc3RhbmQgdGhhdCBob3cgdG8gDQp1 c2UgVkxBTiBhbmQgZmluZS1ncmFpbiBMYWJsZSB0byBpZGVudGlmeSB0aGUgdHJhZmZpYyBzY29w ZS4gVGhlIGRhdGEgDQp0cmFmZmljIHdpdGggYSBnaXZlbiBWTEFOLXgsIGNhbiANCmJlIGZvcndh cmRlZCB0byBvdGhlciBlbmQgc3RhdGlvbiBpbiB0aGUgbG9jYWwgYXJlYSwgb3IgdG8gdGhlIGVu ZCBzdGF0aW9uIA0KaW4gcmVtb3RlIGFyZWFzLiANCg0KKDIpIG5pY2tuYW1lIGFsbG9jYXRpb24g DQpUaGUgbmlja25hbWUgbWFuYWdlbWVudCBzdWItVExWIGlzIHByb3Bvc2VkIGluIHRoZSBkb2N1 bWVudC4gSSB3b25kZXIgdGhpcyANCm1lY2hhbmlzbSBhZGRzIHRoZSBjb21wbGljYXRpb24gb2Yg ICANCm5pY2tuYW1lIGFsbG9jYXRpb24uIEFzIHRoZSBzZWN0aW9uIDEgKGludHJvZHVjdGlvbikg b2YgUkZDNjMyNSwgb25lIG9mIA0KdGhlIGltcG9ydGFudCBhZHZhbnRhZ2Ugb2YgVFJJTEwgaXMg dGhhdCAgIA0KaXQgYXZvaWRzIHRoZSBjcmVhdGluZyBzdWJuZXRzIG9mIElQIGFkZHJlc3MgYW5k IHdhc3RpbmcgYWRkcmVzcy4gVGhlIA0Kbmlja25hbWUgYWNxdWlzaXRpb24gIG1ldGhvZCBpbiB0 aGlzIGRyYWZ0IHZpb2xhdGVzIHRoZSAgIA0KaWRlYSBvZiBUUklMTCBCYXNpYyBzcGVjaWZpY2F0 aW9uLCBhbmQgcmVkdWNlcyB0aGUgZmxleGliaWxpdHkgb2Ygbmlja25hbWUgDQphbGxvY2F0aW9u LiBBcyB0aGUgZHJhZnQgYXNzdW1lZCwgQTEgaGFkICAgDQpuaWNrbmFtZSByYW5nZSBvZiAxMDAt MjAwLCBBMiBoYXMgYSBsb2NhbCBuaWNrbmFtZSByYW5nZSBvZiAyMDEtMzAwLiBJZiANCnRoZSBu dW1iZXJzIG9mIEExIGFyZWEgaXMgb25seSA1MCwgc28gNTAgICANCm5pY2tuYW1lcyBpbiBBMSBp cyB3YXN0ZWQuIEFzIHRoZSBuZXR3b3JrIGdyb3dpbmcsIHRoZSBudW1iZXIgb2Ygc29tZSANCmFy ZWFzIG1heSBleGNlZWQgdGhlIG51bWJlciBiZWluZyBhbGxvY2F0aW9uICAgDQpieSBCb3JkZXIg UkJyaWRnZXMuIFRoZSBkZXNpZ24gYW5kIG1haW50YWluaW5nIG9mIG5pY2tuYW1lIHJhbmdlcyBm b3IgZWFjaCANCmFyZWEgaXMgYSB2ZXJ5IGhhcmQgd29yay4gRXZlbiB3b3JzdCwgaXQgICANCmNh biBub3QgYXZvaWQgdG8gd2FzdGUgbmlja25hbWUgc3BhY2UuIA0KDQooMykgRHluYW1pYyByYW5n ZXMgDQpUaGUgbmlja25hbWUgcmFuZ2UgaXMgZGl2aWRlZCBpbnRvIHR3byByYW5nZTogbG9jYWwg cmFuZ2UgYW5kIGR5bmFtaWNhbCANCnJhbmdlLiBJIHdvbmRlciB0aGUgbmlja25hbWUgY29uZmxp Y3QgICANCnJlc29sdXRpb24gY2FuIG5vdCB3b3JrIGlmIHRoZSBSQnJpZGdlIGdldCB0aGUgbmlj a25hbWUgZnJvbSB0aGUgZHluYW1pY2FsIA0KcmFuZ2Ugd2hpbGUgdGhlIHR3byBSQnJpZGdlIGJl bG9uZ3MgdG8gICANCmRpZmZlcmVudCBhcmVhcy4gRm9yIGV4YW1wbGUsIFJCMSBpcyBpbiBhcmVh IEExLCBhbmQgUkIyIGlzIGluIGFyZWEgQTIuIElmIA0KUkIxIGdldHMgdGhlIG5pY2tuYW1lIE4x IGZyb20gZHluYW1pYyAgIA0KcmFuZ2UsIGFuZCBpdCB3aWxsIGZsb29kcyBpbiBhcmVhIEExLCBh bmQgb3RoZXIgUkJyaWRnZXMgaW4gYXJlYSBBMSBjYW4gDQpub3QgZ2V0IG5pY2tuYW1lIE4xIGJl Y2F1c2Ugb2Ygbmlja25hbWUgICANCmNvbmZsaWN0aW9uIG1lY2hhbmlzbSwgYnV0IFJCMiBpbiBh cmVhIEEyIGNhbiBub3QgcmVjZWl2ZSB0aGUgUERVIGZyb20gDQpSQjEsIGFuZCBpdCAgY2FuIGFs c28gZ2V0IHRoZSBuaWNrbmFtZSBOMSBmcm9tICAgDQpkeW5hbWljYWwgcmFuZ2UuIFNvIHRoZSBx dWVzdGlvbiBpcyBob3cgdG8gYXZvaWQgdGhlIGR1cGxpY2F0aW9uIGR5bmFtaWNhbCANCnJhbmdl IG5pY2tuYW1lIGZvciBkaWZmZXJlbnQgYXJlYXMuIA0KDQooNCkgVGhlIHJpc2sgb2YgcnVubmlu ZyBvdXQgb2Ygbmlja25hbWUgbWF5YmUgYSBpc3N1ZSBmb3IgVFJJTEwuIFRoZSANCm51bWJlciBv ZiAyKioxNiBuaWNrbmFtZSBpcyBlbm91Z2ggZm9yIHRoZSBjdXJyZW50IGRhdGEgY2VudGVyLCAN CmJ1dCBpdCBtYXliZSBub3QgZW5vdWdoIGluIHRoZSBmdXR1cmUsIGVzcGVjYWlsbHkgaWYgVFJJ TEwgb3ZlciBJUCAsIFRSSUxMIA0Kb3ZlciBNUExTIHRlY2hub2xvZ3kgb3Igc29tZSBvdGhlciBk YXRhIGNlbnRlciB0ZWNobm9sb2dpZXMgDQphcmUgZGVwbG95ZWQsIHRoZSBkYXRhIGNlbnRlciBu ZXR3b3JrIGNhbiBiZSBhIHZlcnkgbGFyZGdlIG5ldHdvcmsuIFNvIGkgDQp0aGluayB0aGUgdmVy eSBpbXBvcnRhbnQgYW5kIGVzc2VudGlhbCBnb2FsIG9mIG11bHRpLWxldmVsIGRyYWZ0IGlzIHRv IA0Kc2F2ZSBuaWNrbmFtZXMuIA0KDQpCZXN0IHJlZ2FyZHMgDQpGYW5nd2VpIEh1DQoNCiJUaXNz YSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKSIgPHRzZW5ldmlyQGNpc2NvLmNvbT4gDQq3orz+yMs6 ICByYnJpZGdlLWJvdW5jZXNAcG9zdGVsLm9yZyANCjIwMTItMDItMjMgMTE6NTUgDQoNCg0KytW8 /sjLDQo8cmJyaWRnZUBwb3N0ZWwub3JnPiANCrOty80NCg0K1vfM4g0KW3JicmlkZ2VdIERlZmF1 bHQgbmlja25hbWUgYmFzZSBhcHByb2FjaCBmb3IgbXVsdGlsZXZlbCBUUklMTC0gDQpkcmFmdC10 aXNzYS10cmlsbC1tdWx0aWxldmVsLTAwLnR4dA0KDQogDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkRl YXIgQWxsDQoNCldlIGhhdmUgc3VibWl0dGVkIGRyYWZ0LXRpc3NhLXRyaWxsLW11bHRpbGV2ZWws IHByZXNlbnQgbXVsdGlsZXZlbCBUUklMTCANCmJhc2VkIG9uIGRlZmF1bHQgbmlja25hbWUgYXBw cm9hY2guIEFkZGl0aW9uYWxseSB3ZSBkaXNjdXNzIGNvbnN0cnVjdGlvbiANCm9mIG11bHRpLWRl c3RpbmF0aW9uIHRyZWVzIGFuZCByZWxhdGVkIFJQRiBpbiBtdWx0aWxldmVsIFRSSUxMLiBQbGVh c2UgDQpjb3VsZCB5b3UgcmV2aWV3IGFuZCBjb21tZW50IA0KDQpEZXRhaWwgb2YgdGhlIGRyYWZ0 IGFuZCBhYnN0cmFjdCBhcmUgYmVsb3cuDQoNCkZpbGVuYW1lOiAgICAgICAgICAgICAgICAgIGRy YWZ0LXRpc3NhLXRyaWxsLW11bHRpbGV2ZWwNClJldmlzaW9uOiAgICAgICAgICAgICAgICAgIDAw DQpUaXRsZTogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIERlZmF1bHQgTmlja25h bWUgQmFzZWQgQXBwcm9hY2ggDQpmb3IgTXVsdGlsZXZlbCBUUklMTA0KQ3JlYXRpb24gZGF0ZTog ICAgICAgICAgICAgICAgICAyMDEyLTAyLTIxDQpXRyBJRDogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAyNg0K DQpBYnN0cmFjdDoNCiBNdWx0aWxldmVsIFRSSUxMIGFsbG93cyB0aGUgaW50ZXJjb25uZWN0aW9u IG9mIG11bHRpcGxlIFRSSUxMDQogbmV0d29ya3MgdG8gZm9ybSBhIGxhcmdlciBUUklMTCBuZXR3 b3JrIHdpdGhvdXQgcHJvcG9ydGlvbmFsbHkNCiBpbmNyZWFzaW5nIHRoZSBzaXplIG9mIHRoZSBJ Uy1JUyBMU1AgREIuIEluIHRoaXMgZG9jdW1lbnQsIGFuDQogYXBwcm9hY2ggYmFzZWQgb24gZGVm YXVsdCByb3V0ZSBjb25jZXB0IGlzIHByZXNlbnRlZC4gQWxzbywNCiBwcmVzZW50ZWQgaW4gdGhl IGRvY3VtZW50IGlzIGEgbm92ZWwgbWV0aG9kIG9mIGNvbnN0cnVjdGluZyBtdWx0aS0NCiBkZXN0 aW5hdGlvbiB0cmVlcyB1c2luZyBwYXJ0aWFsIG5pY2tuYW1lIHNwYWNlLiBNZXRob2RzIHByZXNl bnRlZCBpbg0KIHRoaXMgZG9jdW1lbnQgYXJlIGNvbXBhdGlibGUgd2l0aCB0aGUgUkZDNjMyNSBz cGVjaWZpZWQgZGF0YSBwbGFuZQ0KIG9wZXJhdGlvbnMuDQoNCiAgDQpUaGFua3MNClRpc3NhDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpyYnJpZGdl IG1haWxpbmcgbGlzdA0KcmJyaWRnZUBwb3N0ZWwub3JnDQpodHRwOi8vbWFpbG1hbi5wb3N0ZWwu b3JnL21haWxtYW4vbGlzdGluZm8vcmJyaWRnZSANCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCnJicmlkZ2UgbWFpbGluZyBsaXN0DQpyYnJpZGdlQHBv c3RlbC5vcmcNCmh0dHA6Ly9tYWlsbWFuLnBvc3RlbC5vcmcvbWFpbG1hbi9saXN0aW5mby9yYnJp ZGdlIA0KIA0KIA0KIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpyYnJpZGdlIG1haWxpbmcgbGlzdA0KcmJyaWRnZUBwb3N0ZWwub3JnDQpodHRwOi8vbWFp bG1hbi5wb3N0ZWwub3JnL21haWxtYW4vbGlzdGluZm8vcmJyaWRnZQ0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcmJyaWRnZSBtYWlsaW5nIGxpc3QN CnJicmlkZ2VAcG9zdGVsLm9yZw0KaHR0cDovL21haWxtYW4ucG9zdGVsLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3JicmlkZ2UNCg0KDQo= --=_alternative 0014D40A482579B1_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlBscyBzZWUgdGhlIGZvbGxvd2lu Zzo8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PlRoZSByZWFzb24gd2h5IGZvbGtzIGluIElQIHdvcmQgYXJlDQpwdXNoaW5nIHRvIGdvIHRvIElQ djYgaXMgdGhhdCB0aGUgZXhoYXVzdGluZyBvZiBJUHY0IGFkZHJlc3MsIG5vdCB0aGF0DQp0aGUg TkFUIGNhbiBub3Qgd29yay4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj5UaGUgTkFUIHRlY2hub2xvZ3kgaXMgd2lkZWx5IGRlcGxveWVkDQppbiBDaGluYSwgYW5k IGl0IGRvZXMgd29yayB3ZWxsLiBUaGVyZSBpcyB2ZXJ5IGxpdHRsZSBJUHY0IGFkZHJlc3MgY2Fu DQpiZSBhc3NpZ25lZCB0byB0aGUgQk5BUyhNb3N0IG9mIHRoZSBhZGRyZXNzIGFzc2lnbmVkIHRv IHRoZSB1c2VyIGFyZSBwcml2YXRlDQpJUHY0IGFkZHJlc3MsIGFuZCBvbmx5IHRoZSBOTkFTIGFu ZCBhYm92ZSBlcXVpdG1lbnQgYXJlIGFzc2lnbmVkIHB1YmxpYw0KYWRkcmVzcyApLCBzbyBpdCBp cyBhbiBlbWVyZ2VudCB0aGluZyB0byB0cmFuc2l0IGZyb20gSVB2NCB0byBJUHY2LjwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0z IGZhY2U9InNhbnMtc2VyaWYiPkFuZCB5b3VyIHBvaW50IGlzPzwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+W2hmd10gTXkgcG9pbnQgaXMgdGhhdCB0aGUg bXVsdGktbGV2ZWwNCmRyYWZ0IHNob3VsZCBzb2x2ZSB0aGUgbmlja25hbWUgc3BhY2UgaXNzdWUu PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5UaGVyZSBp cyBhIG11bHRpLWxldmVsIGRyYWZ0IGlzIHByb3Bvc2VkDQpieSBSYWRpYSwgd2UgY2FuIG9wdGlt aXplIGl0IGFuZCBtYWtlIGl0IGJldHRlci4gVGhlcmUgaXMgbm8gbmVlZCB0byBwcm92aWRlDQph IG5ldyBNdWx0aS1sZWx2ZSBkcmFmdCB3aGljaCBjYW4gbm90IHNvbHZlIHRoZSBrZXkgaXNzdWUg b2Ygbmlja25hbWUgc3BhY2UuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj48YnI+DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM1JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+PGI+U2FtIEFsZHJpbiAmbHQ7YWxkcmluLmlldGZAZ21haWwuY29tJmd0OzwvYj4NCjwv Zm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEyLTAyLTI3IDExOjQw PC9mb250Pg0KPHRkIHdpZHRoPTY0JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi Pmh1LmZhbmd3ZWlAenRlLmNvbS5jbjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRp diBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48 L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7VGlzc2EgU2Vu ZXZpcmF0aG5lICh0c2VuZXZpcikmcXVvdDsNCiZsdDt0c2VuZXZpckBjaXNjby5jb20mZ3Q7LCBy YnJpZGdlQHBvc3RlbC5vcmcsIHJicmlkZ2UtYm91bmNlc0Bwb3N0ZWwub3JnLA0KUmFkaWEgUGVy bG1hbiAmbHQ7cmFkaWFwZXJsbWFuQGdtYWlsLmNvbSZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRv cD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi Ptb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJl OiBbcmJyaWRnZV0gRGVmYXVsdCBuaWNrbmFtZSBiYXNlDQphcHByb2FjaCBmb3IgbXVsdGlsZXZl bCBUUklMTC0gZHJhZnQtdGlzc2EtdHJpbGwtbXVsdGlsZXZlbC0wMC50eHQ8L2ZvbnQ+PC90YWJs ZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8 YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fu cy1zZXJpZiI+T24gRmViIDI2LCAyMDEyLCBhdCA2OjUwIFBNLCA8L2ZvbnQ+PGEgaHJlZj1tYWls dG86aHUuZmFuZ3dlaUB6dGUuY29tLmNuPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNh bnMtc2VyaWYiPjx1Pmh1LmZhbmd3ZWlAenRlLmNvbS5jbjwvdT48L2ZvbnQ+PC9hPjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCndyb3RlOjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KVGhlIHJlYXNvbiB3aHkgZm9sa3MgaW4gSVAg d29yZCBhcmUgcHVzaGluZyB0byBnbyB0byBJUHY2IGlzIHRoYXQgdGhlIGV4aGF1c3RpbmcNCm9m IElQdjQgYWRkcmVzcywgbm90IHRoYXQgdGhlIE5BVCBjYW4gbm90IHdvcmsuIDwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhlIE5BVCB0ZWNobm9sb2d5IGlzIHdp ZGVseSBkZXBsb3llZA0KaW4gQ2hpbmEsIGFuZCBpdCBkb2VzIHdvcmsgd2VsbC4gVGhlcmUgaXMg dmVyeSBsaXR0bGUgSVB2NCBhZGRyZXNzIGNhbg0KYmUgYXNzaWduZWQgdG8gdGhlIEJOQVMoTW9z dCBvZiB0aGUgYWRkcmVzcyBhc3NpZ25lZCB0byB0aGUgdXNlciBhcmUgcHJpdmF0ZQ0KSVB2NCBh ZGRyZXNzLCBhbmQgb25seSB0aGUgTk5BUyBhbmQgYWJvdmUgZXF1aXRtZW50IGFyZSBhc3NpZ25l ZCBwdWJsaWMNCmFkZHJlc3MgKSwgc28gaXQgaXMgYW4gZW1lcmdlbnQgdGhpbmcgdG8gdHJhbnNp dCBmcm9tIElQdjQgdG8gSVB2Ni48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYi Pg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5BbmQgeW91ciBw b2ludCBpcz88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4N CklmIHdlIGNhbiBub3Qgc2xvdmUgdGhlIG5pY2tuYW1lIHNwYWNlIGlzc3VlIG5vdywgZG8gd2Ug bmVlZCBhbm90aGVyIE5JQ0tOQU1FdjYNCm9yIHNvbWV0aGluZyBlbHNlPyA8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPlRoYXQgY291bGQgYmUgYSB0b3BpYywgd2hp Y2ggY291bGQgYmUNCnRha2VuIHVwIHRvIHJlc29sdmUgbmlja25hbWUgZXhoYXVzdGlvbiBpc3N1 ZSBhbmQgbm90IG5lY2Vzc2FyaWx5IGF0IG11bHRpbGV2ZWwNCmRyYWZ0LjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KU28gaSB0aGluZyB0aGUgbmlja25h bWUgc3BhY2UgaXNzdWUgaXMgdGhlIGtleSBpc3N1ZSB3ZSBzaG91bGQgc2xvdmUgbm93Lg0KPC9m b250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5UaGF0IHRvcGljIHNob3Vs ZCBiZSBjb25zaWRlcmVkIG91dHNpZGUNCm9mIHRoaXMgZHJhZnQuPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpNdWx0aS1sZXZlbCBkcmFmdCBpcyBhIGdv b2QgcGxhdGZvcm0gdG8gc2xvdmUgaXQsIHRob3VnaCB0aGVyZSBpcyBzb21lDQp0ZWNobm9sb2d5 IHdlIHNob3VsZCBjb25zaWRlcmVkIGZ1dGhlci4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBm YWNlPSJzYW5zLXNlcmlmIj5JZiBtdWx0aWxldmVsIGRyYWZ0IGlzIG9ubHkgdG8gYWRkcmVzcw0K J25pY2tuYW1lIGV4aGF1c3Rpb24nIGlzc3VlLCB0aGVuIGl0IHNob3VsZCBiZSByZW5hbWVkIGFj Y29yZGluZ2x5IGFuZA0Kbm90ICdtdWx0aWxldmVsJy4gVGhlIHB1cnBvc2Ugb2YgbXVsdGlsZXZl bCBkcmFmdCBpcyBkaWZmZXJlbnQsIHdoaWNoIGlzDQpzdGF0ZWQgaW4gdGhlIGRyYWZ0IGFuZCB0 aGUgYnkgcHJvZHVjdCBvZiBpdCBpcyBuaWNrbmFtZSBleGhhdXN0aW9uIGNvdWxkDQpiZSBhbGxl dmlhdGVkIGFuZCBub3QganVzdCB0aGUgcHJpbWFyeSBwcm9ibGVtL3NvbHV0aW9uLiBIZXJlIGlz IHRoZSBzbmlwDQpmcm9tIGFic3RyYWN0ICZxdW90Oy4uPC9mb250Pjxmb250IHNpemU9Mj48dHQ+ bm92ZWwgbWV0aG9kIG9mIGNvbnN0cnVjdGluZw0KbXVsdGktZGVzdGluYXRpb24gdHJlZXMgdXNp bmcgcGFydGlhbCBuaWNrbmFtZSBzcGFjZSZxdW90OzwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPjxm b250IHNpemU9Mj48dHQ+Y2hlZXJzPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4t c2FtPC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYi Pjxicj4NCjxicj4NCjwvZm9udD4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+ DQo8dGQgd2lkdGg9MzQlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj4mcXVvdDtU aXNzYSBTZW5ldmlyYXRobmUNCih0c2VuZXZpcikmcXVvdDsgJmx0OzwvYj48L2ZvbnQ+PGEgaHJl Zj1tYWlsdG86dHNlbmV2aXJAY2lzY28uY29tPjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9 InNhbnMtc2VyaWYiPjxiPjx1PnRzZW5ldmlyQGNpc2NvLmNvbTwvdT48L2I+PC9mb250PjwvYT48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+Jmd0OzwvYj4NCjxicj4NCreivP7Iyzog Jm5ic3A7PC9mb250PjxhIGhyZWY9Im1haWx0bzpyYnJpZGdlLWJvdW5jZXNAcG9zdGVsLm9yZyI+ PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+cmJyaWRnZS1ib3Vu Y2VzQHBvc3RlbC5vcmc8L3U+PC9mb250PjwvYT4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj4yMDEyLTAyLTI1IDAyOjA3PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNl cmlmIj4NCjwvZm9udD4NCjx0ZCB3aWR0aD02NSU+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTEyJT4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZCB3aWR0aD04 NyU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O1JhZGlhIFBlcmxtYW4mcXVv dDsNCiZsdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86cmFkaWFwZXJsbWFuQGdtYWlsLmNvbT48Zm9u dCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5yYWRpYXBlcmxtYW5AZ21h aWwuY29tPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZndDs8 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPHRyIHZhbGln bj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxhIGhyZWY9bWFpbHRvOnJicmlkZ2VAcG9zdGVs Lm9yZz48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5yYnJpZGdl QHBvc3RlbC5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ LA0KPC9mb250PjxhIGhyZWY9Im1haWx0bzpyYnJpZGdlLWJvdW5jZXNAcG9zdGVsLm9yZyI+PGZv bnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+cmJyaWRnZS1ib3VuY2Vz QHBvc3RlbC5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ LA0KPC9mb250PjxhIGhyZWY9bWFpbHRvOmh1LmZhbmd3ZWlAenRlLmNvbS5jbj48Zm9udCBzaXpl PTEgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5odS5mYW5nd2VpQHp0ZS5jb20uY248 L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPlJlOiBbcmJyaWRnZV0gRGVmYXVsdCBuaWNrbmFtZSBiYXNlDQphcHByb2FjaCBm b3IgbXVsdGlsZXZlbCBUUklMTC0gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZHJhZnQtdGlz c2EtdHJpbGwtbXVsdGlsZXZlbC0wMC50eHQ8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjxicj4NCjx0 YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9NDklPg0KPHRkIHdp ZHRoPTUwJT48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPjxicj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBm YWNlPSJDYWxpYnJpIj48YnI+DQpBbHNvLCB0aGVyZSBhcmUgc28gbWFueSB3ZWxsIGtub3duIGlz c3VlcyB3aXRoIE5BVCBsaWtlIGFwcHJvYWNoZXMuICMxDQppcyB5b3Ugd291bGQgbG9zZSBpZGVu dGl0eSBvZiBvcmlnaW5hdG9yLCBhbmQgaXQgYmVjb21lcyBhbiBPQU0gbmlnaHRtYXJlLg0KJm5i c3A7SXQgbGltaXQgYWJpbGl0eSBhcHBseSBjZXJ0YWluIEFDTCwgcmF0ZS1saW1pdGluZyBldGMu PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXpl PTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQogPC9mb250Pjxmb250IHNpemU9 MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5 N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KVGhlcmUgaXMgYSB3aG9sZSBzZXJpZXMgb2YgaXNzdWVz IGFzc29jaWF0ZWQgd2l0aCBOQVRzLiBUaGF0IGlzIG9uZSBvZg0KdGhlIHJlYXNvbnMgZm9sa3Mg aW4gSVAgd29ybGQgYXJlIHB1c2hpbmcgaGFyZCB0byBnbyB0byBJUHY2LiBJIHdhcyBhc3N1bWlu Zw0KcGVvcGxlIGFyZSBhd2FyZSBvZiB0aG9zZS48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJy aSI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9m b250Pjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxiPjxicj4NCkZyb206PC9iPiBSYWRpYSBQ ZXJsbWFuIFttYWlsdG86cmFkaWFwZXJsbWFuQGdtYWlsLmNvbV0gPGI+PGJyPg0KU2VudDo8L2I+ IEZyaWRheSwgRmVicnVhcnkgMjQsIDIwMTIgOToyMyBBTTxiPjxicj4NClRvOjwvYj4gVGlzc2Eg U2VuZXZpcmF0aG5lICh0c2VuZXZpcik8Yj48YnI+DQpDYzo8L2I+IDwvZm9udD48YSBocmVmPW1h aWx0bzpodS5mYW5nd2VpQHp0ZS5jb20uY24+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0i VGFob21hIj48dT5odS5mYW5nd2VpQHp0ZS5jb20uY248L3U+PC9mb250PjwvYT48Zm9udCBzaXpl PTIgZmFjZT0iVGFob21hIj47DQo8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86cmJyaWRnZUBwb3N0ZWwu b3JnPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+cmJyaWRnZUBwb3N0 ZWwub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+Ow0KPC9mb250 PjxhIGhyZWY9Im1haWx0bzpyYnJpZGdlLWJvdW5jZXNAcG9zdGVsLm9yZyI+PGZvbnQgc2l6ZT0y IGNvbG9yPWJsdWUgZmFjZT0iVGFob21hIj48dT5yYnJpZGdlLWJvdW5jZXNAcG9zdGVsLm9yZzwv dT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxiPjxicj4NClN1YmplY3Q6 PC9iPiBSZTogW3JicmlkZ2VdIERlZmF1bHQgbmlja25hbWUgYmFzZSBhcHByb2FjaCBmb3IgbXVs dGlsZXZlbA0KVFJJTEwtIGRyYWZ0LXRpc3NhLXRyaWxsLW11bHRpbGV2ZWwtMDAudHh0PC9mb250 Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjxicj4NCiAmbmJzcDs8YnI+DQpJIGFz c3VtZSB0aGF0IGFsbCBSQnJpZGdlcyB3aWxsIG5lZWQgdG8gYmUgaW4gYWxsIHRvcG9sb2dpZXMs IHNvIG11bHRpdG9wb2xvZ3kNCndpbGwgbm90IGhlbHAgd2l0aCBuaWNrbmFtZSBleGhhdXN0aW9u LiAmbmJzcDtQbHVzIHlvdSBoYXZlbid0IGV4cGxhaW5lZA0KaG93IGEgVFJJTEwgcGFja2V0IHdv dWxkIGJlIG1hcmtlZCBhcyB0byB3aGljaCB0b3BvbG9neSB0aGUgcGFja2V0IHNob3VsZA0KYmUg cm91dGVkIGFjY29yZGluZyB0byAob3RoZXIgdGhhbiB3aGF0IEkgbWVudGlvbmVkLCB3aGljaCBh Y3R1YWxseSBlYXRzDQp1cCBuaWNrbmFtZXMgYnkgYSBmYWN0b3Igb2YgdGhlIG51bWJlciBvZiB0 b3BvbG9naWVzIHN1cHBvcnRlZCkuIDxicj4NCiAmbmJzcDs8YnI+DQpQbHVzLCByYXRoZXIgdGhh biBqdXN0IGx1bXBpbmcgcG90ZW50aWFsIGlzc3VlcyBpbnRvIGEgcGhyYXNlIHN1Y2ggYXMgJnF1 b3Q7TkFULWxpa2UmcXVvdDssDQpiZSBleHBsaWNpdCBhYm91dCB3aGF0IGlzc3VlcyB0aGVyZSBh Y3R1YWxseSBhcmUuICZuYnNwO0kgYmVsaWV2ZSB0aGUgRnVsY3J1bQ0KY2hpcCB3b3VsZCBoYXZl IG5vIHByb2JsZW0gd2l0aCB0cmFuc2xhdGluZyB0aGUgbmlja25hbWUgZmllbGRzLiA8YnI+DQog Jm5ic3A7PGJyPg0KQW5kIHJhdGhlciB0aGFuIGFzc3VtaW5nIHRoYXQgbmlja25hbWUgZXhoYXVz dGlvbiBjYW4gYmUgc29sdmVkICZxdW90O3NvbWUNCm90aGVyIHdheSZxdW90OywgdGhlcmUgc2hv dWxkIGJlIGEgcGFsYXRhYmxlIHNvbHV0aW9uIGJlZm9yZSByZWplY3RpbmcNCmEgY2hhbmNlIHRv IHNvbHZlIGl0IHdpdGggbXVsdGlsZXZlbC4gPGJyPg0KICZuYnNwOzxicj4NClJhZGlhIDxicj4N CjIwMTIvMi8yNCBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKSAmbHQ7PC9mb250PjxhIGhy ZWY9bWFpbHRvOnRzZW5ldmlyQGNpc2NvLmNvbT48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNl PSJzYW5zLXNlcmlmIj48dT50c2VuZXZpckBjaXNjby5jb208L3U+PC9mb250PjwvYT48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0Ow0KPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0j MWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCkJlY2F1c2UgeW91IGNhbiBoYXZlIHNhbWUgbmlj a25hbWUgZm9yIGRpZmZlcmVudCB0b3BvbG9neS4gSXQgaXMgbm90IGENCm5pY2tuYW1lIHRoYXQg d2lsbCBpZGVudGlmeSBhbiBSQlJpZGdlLCBpdCBpcyB0b3BvbG9neSxuaWNrbmFtZSBjb21iaW5h dGlvbg0KdGhhdCB3aWxsIGlkZW50aWZ5IGFuIFJCUmlkZ2UuIFNvIFJCMSBjYW4gaGF2ZSBuaWNr bmFtZSAxIGluIHRvcG8tMSBhbmQNClJCMiBjYW4gaGF2ZSBuaWNrbmFtZSAxIGluIHRvcG8yLiBO b3cgdG90YWwgbmlja25hbWVzIGluIHRoZSBjYW1wdXMgaXMNCjIqKjE2IHggdG9wb2xvZ2llcy48 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0y IGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdk IGZhY2U9IkNhbGlicmkiPjxicj4NClN0ZWFsaW5nIGJpdHMgdG8gcmVwcmVzZW50IHRvcG8gaWQg aXMgb25seSBhIHdvcmthcm91bmQgdGhlcmUgY2FuIGJlIChhcmUNCikgbW9yZSBlbGVnYW50IHdh eXMgb2YgZG9pbmcgaXQgdGhhdC48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYi Pg0KPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4N CiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD48Zm9u dCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpCb3R0b20gbGluZSBp cyB3ZSBuZWVkIHRvIGxvb2sgZm9yIG1vcmUgY3JlYXRpdmUgbWV0aG9kcyBvZiBzb2x2aW5nIG5p Y2tuYW1lDQpzcGFjZSBpc3N1ZSB0aGFuIGRvaW5nIE5BVCBsaWtlIGJlaGF2aW9yLiA8YnI+DQog PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+PGZvbnQg c2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGI+PGJyPg0KRnJvbTo8L2I+IFJhZGlhIFBlcmxtYW4gW21h aWx0bzo8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86cmFkaWFwZXJsbWFuQGdtYWlsLmNvbSB0YXJnZXQ9 X2JsYW5rPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+cmFkaWFwZXJs bWFuQGdtYWlsLmNvbTwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPl0N CjxiPjxicj4NClNlbnQ6PC9iPiBGcmlkYXksIEZlYnJ1YXJ5IDI0LCAyMDEyIDk6MDUgQU08Yj48 YnI+DQpUbzo8L2I+IFRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpPGI+PGJyPg0KQ2M6PC9i PiA8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86aHUuZmFuZ3dlaUB6dGUuY29tLmNuIHRhcmdldD1fYmxh bms+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVGFob21hIj48dT5odS5mYW5nd2VpQHp0 ZS5jb20uY248L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj47DQo8L2Zv bnQ+PGEgaHJlZj1tYWlsdG86cmJyaWRnZUBwb3N0ZWwub3JnIHRhcmdldD1fYmxhbms+PGZvbnQg c2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVGFob21hIj48dT5yYnJpZGdlQHBvc3RlbC5vcmc8L3U+ PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj47DQo8L2ZvbnQ+PGEgaHJlZj0i bWFpbHRvOnJicmlkZ2UtYm91bmNlc0Bwb3N0ZWwub3JnIiB0YXJnZXQ9X2JsYW5rPjxmb250IHNp emU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+cmJyaWRnZS1ib3VuY2VzQHBvc3RlbC5v cmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj4NCjxiPjxicj4NCjxi cj4NClN1YmplY3Q6PC9iPiBSZTogW3JicmlkZ2VdIERlZmF1bHQgbmlja25hbWUgYmFzZSBhcHBy b2FjaCBmb3IgbXVsdGlsZXZlbA0KVFJJTEwtIGRyYWZ0LXRpc3NhLXRyaWxsLW11bHRpbGV2ZWwt MDAudHh0PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjxicj4NCiAmbmJz cDs8YnI+DQpJIGRvbid0IHVuZGVyc3RhbmQgaG93IG11bHRpLXRvcG9sb2d5IGhlbHBzIHdpdGgg dGhlIG5pY2tuYW1lIGV4aGF1c3Rpb24NCmlzc3VlLiAmbmJzcDtBcyBhIG1hdHRlciBvZiBmYWN0 LCB0aGUgb25seSBwbGF1c2libGUgd2F5IG9mIG1hcmtpbmcgYSBwYWNrZXQNCmZvciB3aGljaCB0 b3BvbG9neSB0aGF0IGhhcyBiZWVuIHN1Z2dlc3RlZCBvbiB0aGUgbWFpbGluZyBsaXN0IChJIGFz a2VkDQphIGVmdyB0aW1lcyBpZiB0aGVyZSB3ZXJlIGFueSBvdGhlciBwb3NzaWJpbGl0aWVzKSwg d2FzIHRvIHN0ZWFsIDIgb3IgMw0KYml0cyBvZiB0aGUgbmlja25hbWUgdG8gZW5jb2RlIHdoaWNo IHRvcG9sb2d5LCBpbiBlZmZlY3QsIG1ha2luZyBhIGRlc3RpbmF0aW9uDQphcHBlYXIgYXMgbXVs dGlwbGUgZGVzdGluYXRpb25zIGFuZCBtdWx0aXBsZSBmb3J3YXJkaW5nIHRhYmxlIGVudHJpZXMg KHdoaWNoDQp5b3UnZCB3YW50IGFueXdheSwgZm9yIG11bHRpdG9wb2xvZ3kpLiA8YnI+DQogJm5i c3A7PGJyPg0KICZuYnNwOzxicj4NClJhZGlhIDxicj4NCjIwMTIvMi8yNCBUaXNzYSBTZW5ldmly YXRobmUgKHRzZW5ldmlyKSAmbHQ7PC9mb250PjxhIGhyZWY9bWFpbHRvOnRzZW5ldmlyQGNpc2Nv LmNvbSB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2Vy aWYiPjx1PnRzZW5ldmlyQGNpc2NvLmNvbTwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNl PSJzYW5zLXNlcmlmIj4mZ3Q7DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFj ZT0iQ2FsaWJyaSI+PGJyPg0KTXV0bGktdG9wb2xvZ3kgaXMgdGhlIGFuc3dlciB0byBpbmNyZWFz ZSB0aGUgbmlja25hbWUgc3BhY2UuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlm Ij4NCjwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+ DQogPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+PGZv bnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KTmlja25hbWUgdHJh bnNsYXRpb24gaXMgdmVyeSBzaW1pbGFyIHRvIE5BVCwgd2hpY2ggaGFzIGl0oa9zIG93biBkb3du DQpzaWRlLCBub3QgdG8gbWVudGlvbiBzcGVjaWFsIGhhcmR3YXJlIGV0Yy4gdG8gZG8gdGhlIHRy YW5zbGF0aW9ucywgYWRkaXRpb25hbGx5Lg0KV2UgYWxzbyBrbm93IGZyb20gb3VyIGV4cGVyaWVu Y2UsIGluIElQIHdvcmxkIE5BVGluZyBpcyBub3QgdGhlIG1vc3QgZGVzaXJlZA0KYmVoYXZpb3Ig YW5kIHdlIGxpdmUgd2l0aCBpdC4gU28gd2Ugc2hvdWxkIG5vdCBiZSBnb2luZyBkb3duIHRoYXQg cGF0aA0KaW5zdGVhZCBuZWVkIHRvIGxvb2sgZm9yd2FyZCBmcm9tIHRoYXQgZXhwZXJpZW5jZS48 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9 MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3 ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpNdWx0aS10b3BvbG9neSBub3Qgb25seSBhZGRyZXNzIG5p Y2tuYW1lIHNwYWNlIGlzc3VlIGJ1dCBhbHNvIGVuYWJsZXMgdmFyaW91cw0Kb3RoZXIgYXBwbGlj YXRpb25zIHN1Y2ggYXMgb3ZlcmxheSB0b3BvbG9naWVzLCB0cmFmZmljIGVuZ2luZWVyaW5nLjwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0y IGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdk IGZhY2U9IkNhbGlicmkiPjxicj4NClRoZSBkcmFmdC10aXNzLXRyaWxsLW11bHRpbGV2ZWwgcHJl c2VudCBhcHByb2FjaGVzIHRoYXQgYXJlIGdlbmVyaWMsIHdoaWNoDQptZWFuIGl0IGNhbiBiZSBh cHBsaWVkIGZvciBtdWx0aS10b3BvbG9neSwgb3IgYmFzZSB0b3BvbG9neS4gSXQgdXRpbGl6ZXMN CnRoZSBmdW5kYW1lbnRhbHMgb2YgSVMtSVMgLCBzdWNoIGFzIEFyZWEgaGllcmFyY2h5IGZvciBy ZWR1Y3Rpb24gb2YgdGhlDQpMU1AtREIuIEl0IHV0aWxpemUgYWZmaW5pdHkgVExWIGNvbmNlcHRz IHRvIGVmZmVjdGl2ZWx5IHNvbHZlIG11bHRpLWRlc3RpbmF0aW9uDQppc3N1ZXMuIDxicj4NCiA8 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD48Zm9udCBz aXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpXZSBzaG91bGQgbm90IG1p eC11cCBiZXR3ZWVuIERhdGEgY2VudGVyIGludGVyY29ubmVjdHMgd2l0aCBkYXRhIGNlbnRlcg0K bm9kZSBzY2FsaW5nLiBUaGV5IGFyZSB0d28gZGlmZmVyZW50IGFuZCBvcnRob2dvbmFsIGlzc3Vl cy48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNp emU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFm NDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpPYmplY3RpdmUgb2YgbXVsdGktbGV2ZWwgdHJpbGwg aXMgdG8gaW50ZXJjb25uZWN0IGRpZmZlcmVudCBkYXRhY2VudGVycywNCmFuZCBtYWludGFpbiBM U1AtREIgc21hbGwgYXMgcG9zc2libGUgdG8gYXZvaWQgc2NhbGluZyBhbmQgdm9sYXRpbGl0eS48 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9 MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3 ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpJbmNyZWFzaW5nIG5pY2tuYW1lIHNwYWNlIGEgZGlmZmVy ZW50IHJlcXVpcmVtZW50IGFuZCBoYXMgbm90aGluZyB0byBkbw0Kd2l0aCBkYXRhLWNlbnRlciBp bnRlcmNvbm5lY3RzLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9u dD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQogPC9mb250 Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0y IGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEi PjxiPjxicj4NCkZyb206PC9iPiBSYWRpYSBQZXJsbWFuIFttYWlsdG86PC9mb250PjxhIGhyZWY9 bWFpbHRvOnJhZGlhcGVybG1hbkBnbWFpbC5jb20gdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTIg Y29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1PnJhZGlhcGVybG1hbkBnbWFpbC5jb208L3U+PC9m b250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj5dDQo8Yj48YnI+DQpTZW50OjwvYj4g RnJpZGF5LCBGZWJydWFyeSAyNCwgMjAxMiA2OjE1IEFNPGI+PGJyPg0KVG86PC9iPiA8L2ZvbnQ+ PGEgaHJlZj1tYWlsdG86aHUuZmFuZ3dlaUB6dGUuY29tLmNuIHRhcmdldD1fYmxhbms+PGZvbnQg c2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVGFob21hIj48dT5odS5mYW5nd2VpQHp0ZS5jb20uY248 L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj48Yj48YnI+DQpDYzo8L2I+ IFRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpOyA8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86cmJy aWRnZUBwb3N0ZWwub3JnIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFj ZT0iVGFob21hIj48dT5yYnJpZGdlQHBvc3RlbC5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXpl PTIgZmFjZT0iVGFob21hIj47DQo8L2ZvbnQ+PGEgaHJlZj0ibWFpbHRvOnJicmlkZ2UtYm91bmNl c0Bwb3N0ZWwub3JnIiB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9 IlRhaG9tYSI+PHU+cmJyaWRnZS1ib3VuY2VzQHBvc3RlbC5vcmc8L3U+PC9mb250PjwvYT48Zm9u dCBzaXplPTIgZmFjZT0iVGFob21hIj48Yj48YnI+DQpTdWJqZWN0OjwvYj4gUmU6IFtyYnJpZGdl XSBEZWZhdWx0IG5pY2tuYW1lIGJhc2UgYXBwcm9hY2ggZm9yIG11bHRpbGV2ZWwNClRSSUxMLSBk cmFmdC10aXNzYS10cmlsbC1tdWx0aWxldmVsLTAwLnR4dDwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+DQo8YnI+DQogJm5ic3A7PGJyPg0KUGVvcGxlIGhhdmUgbWVudGlvbmVk IHRvIG1lIHRoYXQgdGhleSBhcmUgbmVydm91cyBhYm91dCBydW5uaW5nIG91dCBvZg0Kbmlja25h bWVzLCBlc3BlY2lhbGx5IHNpbmNlIHRoZXJlIGFyZSByZWFzb25zb24gd2h5IHRoZXkgbWlnaHQg d2FudCB0bw0KYXNzaWduIG5pY2tuYW1lcyB0byBoeXBlcnZpc29ycy4gJm5ic3A7V2l0aCB0aGUg YWx0ZXJuYXRlIGFwcHJvYWNoIG9mIGFsbG93aW5nDQpuaWNrbmFtZXMgdG8gYmUgcmV1c2VkIGlu IGRpZmZlcmVudCBhcmVhcywgaXQgbWFrZXMgYXV0b21hdGljIG5pY2tuYW1lDQphc3NpZ25tZW50 IG11Y2ggc2ltcGxlciBhbmQgbWFrZXMgVFJJTEwgYSBsb3QgbW9yZSBzY2FsYWJsZS4gPGJyPg0K ICZuYnNwOzxicj4NCkl0IGRvZXMgaGF2ZSB0aGUgZG93bnNpZGUgb2YgcmVxdWlyaW5nIG1hcHBp bmcgb2Ygbmlja25hbWVzIGF0IHRoZSBib3JkZXINClJCcmlkZ2VzLiA8YnI+DQogJm5ic3A7PGJy Pg0KQW5kIGJ5IHRoZSB3YXksIHRoZSBhZmZpbml0eSBUTFYgY2FuIGJlIHVzZWQgZm9yIG11bHRp ZGVzdGluYXRpb24gZnJhbWVzDQp0cmFuc2l0aW5nIGJldHdlZW4gbGV2ZWwgMSBhbmQgbGV2ZWwg Mi4gPGJyPg0KICZuYnNwOzxicj4NClJhZGlhIDxicj4NCjIwMTIvMi8yMyAmbHQ7PC9mb250Pjxh IGhyZWY9bWFpbHRvOmh1LmZhbmd3ZWlAenRlLmNvbS5jbiB0YXJnZXQ9X2JsYW5rPjxmb250IHNp emU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1Pmh1LmZhbmd3ZWlAenRlLmNvbS5j bjwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7DQo8L2Zv bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj48YnI+DQo8YnI+DQpIaSwgVGlzc2EuPC9mb250 Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJBcmlhbCI+PGJyPg0KPGJyPg0KSSBoYXZlIHNldmVyYWwgY29tbWVudHMgYWJvdXQgdGhlIGRy YWZ0LjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9IkFyaWFsIj48YnI+DQo8YnI+DQooMSkgaW4gc2VjdGlvbiA0LjQgKE11bHRp Y2FzdCksICZxdW90O1RoZSBzY29wZSBvZiBnbG9iYWwgdHJhZmZpYyBtYXkgYmUNCmlkZW50aWZp ZWQgZWl0aGVyIHRocm91Z2ggVkxBTiBvciB2aWEgZmluZWdyYWluIDxicj4NCmxhYmVsIHRoYXQg c3BhbnMgYWNyb3NzIHRoZSBlbnRpcmUgVFJJTEwgY2FtcHVzLiZxdW90OzwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFs Ij48YnI+DQpWbGFuIGFuZCBGaW5lLWdyYWluIExhYmVsIGlzIHVzZWQgZm9yIHNlcnZpY2UgZGlm ZmVyZW50aWF0aW9uIGFuZCBpc29sYXRpb24uDQpJIGRvIG5vdCBxdWl0ZSB1bmRlcnN0YW5kIHRo YXQgaG93IHRvPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPjxicj4NCnVzZSBWTEFOIGFuZCBmaW5lLWdyYWluIExh YmxlIHRvIGlkZW50aWZ5IHRoZSB0cmFmZmljIHNjb3BlLiBUaGUgZGF0YSB0cmFmZmljDQp3aXRo IGEgZ2l2ZW4gVkxBTi14LCBjYW4gPGJyPg0KYmUgZm9yd2FyZGVkIHRvIG90aGVyIGVuZCBzdGF0 aW9uIGluIHRoZSBsb2NhbCBhcmVhLCBvciB0byB0aGUgZW5kIHN0YXRpb24NCmluIHJlbW90ZSBh cmVhcy4gPGJyPg0KPGJyPg0KKDIpIG5pY2tuYW1lIGFsbG9jYXRpb248L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj48 YnI+DQpUaGUgbmlja25hbWUgbWFuYWdlbWVudCBzdWItVExWIGlzIHByb3Bvc2VkIGluIHRoZSBk b2N1bWVudC4gSSB3b25kZXIgdGhpcw0KbWVjaGFuaXNtIGFkZHMgdGhlIGNvbXBsaWNhdGlvbiBv ZiAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJBcmlhbCI+PGJyPg0Kbmlja25hbWUgYWxsb2NhdGlvbi4gQXMgdGhl IHNlY3Rpb24gMSAoaW50cm9kdWN0aW9uKSBvZiBSRkM2MzI1LCBvbmUgb2YNCnRoZSBpbXBvcnRh bnQgYWR2YW50YWdlIG9mIFRSSUxMIGlzIHRoYXQgJm5ic3A7PC9mb250Pjxmb250IHNpemU9MyBm YWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPjxicj4N Cml0IGF2b2lkcyB0aGUgY3JlYXRpbmcgc3VibmV0cyBvZiBJUCBhZGRyZXNzIGFuZCB3YXN0aW5n IGFkZHJlc3MuIFRoZSBuaWNrbmFtZQ0KYWNxdWlzaXRpb24gJm5ic3A7bWV0aG9kIGluIHRoaXMg ZHJhZnQgdmlvbGF0ZXMgdGhlICZuYnNwOzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1z ZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj48YnI+DQppZGVhIG9mIFRS SUxMIEJhc2ljIHNwZWNpZmljYXRpb24sIGFuZCByZWR1Y2VzIHRoZSBmbGV4aWJpbGl0eSBvZiBu aWNrbmFtZQ0KYWxsb2NhdGlvbi4gQXMgdGhlIGRyYWZ0IGFzc3VtZWQsIEExIGhhZCAmbmJzcDs8 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9 MyBmYWNlPSJBcmlhbCI+PGJyPg0Kbmlja25hbWUgcmFuZ2Ugb2YgMTAwLTIwMCwgQTIgaGFzIGEg bG9jYWwgbmlja25hbWUgcmFuZ2Ugb2YgMjAxLTMwMC4gSWYNCnRoZSBudW1iZXJzIG9mIEExIGFy ZWEgaXMgb25seSA1MCwgc28gNTAgJm5ic3A7PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5z LXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPjxicj4NCm5pY2tuYW1l cyBpbiBBMSBpcyB3YXN0ZWQuIEFzIHRoZSBuZXR3b3JrIGdyb3dpbmcsIHRoZSBudW1iZXIgb2Yg c29tZSBhcmVhcw0KbWF5IGV4Y2VlZCB0aGUgbnVtYmVyIGJlaW5nIGFsbG9jYXRpb24gJm5ic3A7 PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXpl PTMgZmFjZT0iQXJpYWwiPjxicj4NCmJ5IEJvcmRlciBSQnJpZGdlcy4gVGhlIGRlc2lnbiBhbmQg bWFpbnRhaW5pbmcgb2Ygbmlja25hbWUgcmFuZ2VzIGZvciBlYWNoDQphcmVhIGlzIGEgdmVyeSBo YXJkIHdvcmsuIEV2ZW4gd29yc3QsIGl0ICZuYnNwOzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0i c2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj48YnI+DQpjYW4g bm90IGF2b2lkIHRvIHdhc3RlIG5pY2tuYW1lIHNwYWNlLjwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj48YnI+DQo8 YnI+DQooMykgRHluYW1pYyByYW5nZXMgPGJyPg0KVGhlIG5pY2tuYW1lIHJhbmdlIGlzIGRpdmlk ZWQgaW50byB0d28gcmFuZ2U6IGxvY2FsIHJhbmdlIGFuZCBkeW5hbWljYWwNCnJhbmdlLiBJIHdv bmRlciB0aGUgbmlja25hbWUgY29uZmxpY3QgJm5ic3A7PC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPjxicj4NCnJl c29sdXRpb24gY2FuIG5vdCB3b3JrIGlmIHRoZSBSQnJpZGdlIGdldCB0aGUgbmlja25hbWUgZnJv bSB0aGUgZHluYW1pY2FsDQpyYW5nZSB3aGlsZSB0aGUgdHdvIFJCcmlkZ2UgYmVsb25ncyB0byAm bmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250 IHNpemU9MyBmYWNlPSJBcmlhbCI+PGJyPg0KZGlmZmVyZW50IGFyZWFzLiBGb3IgZXhhbXBsZSwg UkIxIGlzIGluIGFyZWEgQTEsIGFuZCBSQjIgaXMgaW4gYXJlYSBBMi4NCklmIFJCMSBnZXRzIHRo ZSBuaWNrbmFtZSBOMSBmcm9tIGR5bmFtaWMgJm5ic3A7PC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPjxicj4NCnJh bmdlLCBhbmQgaXQgd2lsbCBmbG9vZHMgaW4gYXJlYSBBMSwgYW5kIG90aGVyIFJCcmlkZ2VzIGlu IGFyZWEgQTEgY2FuDQpub3QgZ2V0IG5pY2tuYW1lIE4xIGJlY2F1c2Ugb2Ygbmlja25hbWUgJm5i c3A7PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0iQXJpYWwiPjxicj4NCmNvbmZsaWN0aW9uIG1lY2hhbmlzbSwgYnV0IFJCMiBp biBhcmVhIEEyIGNhbiBub3QgcmVjZWl2ZSB0aGUgUERVIGZyb20NClJCMSwgYW5kIGl0ICZuYnNw O2NhbiBhbHNvIGdldCB0aGUgbmlja25hbWUgTjEgZnJvbSAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJBcmlhbCI+ PGJyPg0KZHluYW1pY2FsIHJhbmdlLiBTbyB0aGUgcXVlc3Rpb24gaXMgaG93IHRvIGF2b2lkIHRo ZSBkdXBsaWNhdGlvbiBkeW5hbWljYWwNCnJhbmdlIG5pY2tuYW1lIGZvciBkaWZmZXJlbnQgYXJl YXMuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0iQXJpYWwiPjxicj4NCjxicj4NCig0KSBUaGUgcmlzayBvZiBydW5uaW5nIG91 dCBvZiBuaWNrbmFtZSBtYXliZSBhIGlzc3VlIGZvciBUUklMTC4gVGhlIG51bWJlcg0Kb2YgMioq MTYgbmlja25hbWUgaXMgZW5vdWdoIGZvciB0aGUgY3VycmVudCBkYXRhIGNlbnRlciw8L2ZvbnQ+ PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJBcmlhbCI+PGJyPg0KYnV0IGl0IG1heWJlIG5vdCBlbm91Z2ggaW4gdGhlIGZ1dHVyZSwgZXNw ZWNhaWxseSBpZiBUUklMTCBvdmVyIElQICwgVFJJTEwNCm92ZXIgTVBMUyB0ZWNobm9sb2d5IG9y IHNvbWUgb3RoZXIgZGF0YSBjZW50ZXIgdGVjaG5vbG9naWVzPC9mb250Pjxmb250IHNpemU9MyBm YWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPjxicj4N CmFyZSBkZXBsb3llZCwgdGhlIGRhdGEgY2VudGVyIG5ldHdvcmsgY2FuIGJlIGEgdmVyeSBsYXJk Z2UgbmV0d29yay4gU28NCmkgdGhpbmsgdGhlIHZlcnkgaW1wb3J0YW50IGFuZCBlc3NlbnRpYWwg Z29hbCBvZiBtdWx0aS1sZXZlbCBkcmFmdCBpcyB0bw0Kc2F2ZSBuaWNrbmFtZXMuPC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJB cmlhbCI+PGJyPg0KPGJyPg0KQmVzdCByZWdhcmRzPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJz YW5zLXNlcmlmIj4gPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJBcmlhbCI+PGJyPg0KRmFuZ3dl aSBIdTwvZm9udD4NCjxwPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0 ZCB3aWR0aD0zNiU+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj48Yj4mcXVvdDtUaXNzYSBTZW5l dmlyYXRobmUgKHRzZW5ldmlyKSZxdW90Ow0KJmx0OzwvYj48L2ZvbnQ+PGEgaHJlZj1tYWlsdG86 dHNlbmV2aXJAY2lzY28uY29tIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUg ZmFjZT0iQXJpYWwiPjxiPjx1PnRzZW5ldmlyQGNpc2NvLmNvbTwvdT48L2I+PC9mb250PjwvYT48 Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPjxiPiZndDs8L2I+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCreivP7IyzwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0i QXJpYWwiPjogJm5ic3A7PC9mb250PjxhIGhyZWY9Im1haWx0bzpyYnJpZGdlLWJvdW5jZXNAcG9z dGVsLm9yZyIgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJBcmlh bCI+PHU+cmJyaWRnZS1ib3VuY2VzQHBvc3RlbC5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXpl PTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0iQXJp YWwiPjIwMTItMDItMjMgMTE6NTU8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYi Pg0KPC9mb250Pg0KPHRkIHdpZHRoPTYxJT4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRy IHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MTklPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkIHdpZHRoPTgwJT48 Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPiZsdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86cmJyaWRn ZUBwb3N0ZWwub3JnIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0i QXJpYWwiPjx1PnJicmlkZ2VAcG9zdGVsLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBm YWNlPSJBcmlhbCI+Jmd0OzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8 L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj5bcmJy aWRnZV0gRGVmYXVsdCBuaWNrbmFtZSBiYXNlIGFwcHJvYWNoDQpmb3IgbXVsdGlsZXZlbCBUUklM TC0gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZHJhZnQtdGlzc2EtdHJpbGwtbXVsdGlsZXZl bC0wMC50eHQ8L2ZvbnQ+PC90YWJsZT4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJp ZiI+PGJyPg0KICZuYnNwOzwvZm9udD4NCjxwPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD00OSU+DQo8dGQgd2lkdGg9NTAlPjwvdGFibGU+DQo8 cD4NCjx0ZCB3aWR0aD0xJT48L3RhYmxlPg0KPHA+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2Vy aWYiPjxicj4NCjxicj4NCjxicj4NCjxicj4NCkRlYXIgQWxsPGJyPg0KPGJyPg0KV2UgaGF2ZSBz dWJtaXR0ZWQgZHJhZnQtdGlzc2EtdHJpbGwtbXVsdGlsZXZlbCwgcHJlc2VudCBtdWx0aWxldmVs IFRSSUxMDQpiYXNlZCBvbiBkZWZhdWx0IG5pY2tuYW1lIGFwcHJvYWNoLiBBZGRpdGlvbmFsbHkg d2UgZGlzY3VzcyBjb25zdHJ1Y3Rpb24NCm9mIG11bHRpLWRlc3RpbmF0aW9uIHRyZWVzIGFuZCBy ZWxhdGVkIFJQRiBpbiBtdWx0aWxldmVsIFRSSUxMLiBQbGVhc2UNCmNvdWxkIHlvdSByZXZpZXcg YW5kIGNvbW1lbnQgPGJyPg0KPGJyPg0KRGV0YWlsIG9mIHRoZSBkcmFmdCBhbmQgYWJzdHJhY3Qg YXJlIGJlbG93Ljxicj4NCjxicj4NCkZpbGVuYW1lOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RyYWZ0LXRpc3NhLXRyaWxsLW11 bHRpbGV2ZWw8YnI+DQpSZXZpc2lvbjogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDswMDxicj4NClRpdGxlOiAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsN CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBEZWZhdWx0 IE5pY2tuYW1lIEJhc2VkDQpBcHByb2FjaCBmb3IgTXVsdGlsZXZlbCBUUklMTDxicj4NCkNyZWF0 aW9uIGRhdGU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsNCiZuYnNwOzIwMTItMDItMjE8YnI+DQpXRyBJRDogJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSW5kaXZpZHVhbCBT dWJtaXNzaW9uPGJyPg0KTnVtYmVyIG9mIHBhZ2VzOiAyNjxicj4NCjxicj4NCkFic3RyYWN0Ojxi cj4NCiBNdWx0aWxldmVsIFRSSUxMIGFsbG93cyB0aGUgaW50ZXJjb25uZWN0aW9uIG9mIG11bHRp cGxlIFRSSUxMPGJyPg0KIG5ldHdvcmtzIHRvIGZvcm0gYSBsYXJnZXIgVFJJTEwgbmV0d29yayB3 aXRob3V0IHByb3BvcnRpb25hbGx5PGJyPg0KIGluY3JlYXNpbmcgdGhlIHNpemUgb2YgdGhlIElT LUlTIExTUCBEQi4gSW4gdGhpcyBkb2N1bWVudCwgYW48YnI+DQogYXBwcm9hY2ggYmFzZWQgb24g ZGVmYXVsdCByb3V0ZSBjb25jZXB0IGlzIHByZXNlbnRlZC4gQWxzbyw8YnI+DQogcHJlc2VudGVk IGluIHRoZSBkb2N1bWVudCBpcyBhIG5vdmVsIG1ldGhvZCBvZiBjb25zdHJ1Y3RpbmcgbXVsdGkt PGJyPg0KIGRlc3RpbmF0aW9uIHRyZWVzIHVzaW5nIHBhcnRpYWwgbmlja25hbWUgc3BhY2UuIE1l dGhvZHMgcHJlc2VudGVkIGluPGJyPg0KIHRoaXMgZG9jdW1lbnQgYXJlIGNvbXBhdGlibGUgd2l0 aCB0aGUgUkZDNjMyNSBzcGVjaWZpZWQgZGF0YSBwbGFuZTxicj4NCiBvcGVyYXRpb25zLjxicj4N Cjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDs8YnI+DQpUaGFua3M8YnI+DQpUaXNzYTxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KcmJyaWRnZSBtYWlsaW5nIGxpc3Q8 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+PGJyPg0K PC91PjwvZm9udD48YSBocmVmPW1haWx0bzpyYnJpZGdlQHBvc3RlbC5vcmcgdGFyZ2V0PV9ibGFu az48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5yYnJpZGdlQHBv c3RlbC5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5z LXNlcmlmIj48dT48YnI+DQo8L3U+PC9mb250PjxhIGhyZWY9aHR0cDovL21haWxtYW4ucG9zdGVs Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JicmlkZ2UgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMg Y29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5odHRwOi8vbWFpbG1hbi5wb3N0ZWwub3Jn L21haWxtYW4vbGlzdGluZm8vcmJyaWRnZTwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNl PSJzYW5zLXNlcmlmIj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KcmJyaWRnZSBtYWlsaW5nIGxpc3Q8L2ZvbnQ+PGZvbnQg c2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+PGJyPg0KPC91PjwvZm9udD48 YSBocmVmPW1haWx0bzpyYnJpZGdlQHBvc3RlbC5vcmcgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXpl PTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5yYnJpZGdlQHBvc3RlbC5vcmc8L3U+ PC9mb250PjwvYT48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT48 YnI+DQo8L3U+PC9mb250PjxhIGhyZWY9aHR0cDovL21haWxtYW4ucG9zdGVsLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3JicmlkZ2UgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBm YWNlPSJzYW5zLXNlcmlmIj48dT5odHRwOi8vbWFpbG1hbi5wb3N0ZWwub3JnL21haWxtYW4vbGlz dGluZm8vcmJyaWRnZTwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlm Ij4NCjxicj4NCiAmbmJzcDs8YnI+DQogJm5ic3A7PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTI+ PHR0Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K cmJyaWRnZSBtYWlsaW5nIGxpc3Q8L3R0PjwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZT48 dHQ+PHU+PGJyPg0KPC91PjwvdHQ+PC9mb250PjxhIGhyZWY9bWFpbHRvOnJicmlkZ2VAcG9zdGVs Lm9yZz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZT48dHQ+PHU+cmJyaWRnZUBwb3N0ZWwub3JnPC91 PjwvdHQ+PC9mb250PjwvYT48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZT48dHQ+PHU+PGJyPg0KPC91 PjwvdHQ+PC9mb250PjxhIGhyZWY9aHR0cDovL21haWxtYW4ucG9zdGVsLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3JicmlkZ2U+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWU+PHR0Pjx1Pmh0dHA6Ly9tYWls bWFuLnBvc3RlbC5vcmcvbWFpbG1hbi9saXN0aW5mby9yYnJpZGdlPC91PjwvdHQ+PC9mb250Pjwv YT48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpyYnJpZGdlIG1haWxpbmcg bGlzdDwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT48 YnI+DQo8L3U+PC9mb250PjxhIGhyZWY9bWFpbHRvOnJicmlkZ2VAcG9zdGVsLm9yZz48Zm9udCBz aXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5yYnJpZGdlQHBvc3RlbC5vcmc8 L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KaHR0cDov L21haWxtYW4ucG9zdGVsLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JicmlkZ2U8L2ZvbnQ+DQo8cD4N CjxwPg0K --=_alternative 0014D40A482579B1_=-- --===============1889535298== 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 --===============1889535298==-- From rbridge-bounces@postel.org Sun Feb 26 20:56: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 17B3B21E800F for ; Sun, 26 Feb 2012 20:56:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.458 X-Spam-Level: X-Spam-Status: No, score=-4.458 tagged_above=-999 required=5 tests=[AWL=-0.911, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=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 A415ZFEIOSAi for ; Sun, 26 Feb 2012 20:56:31 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id DF85621F8464 for ; Sun, 26 Feb 2012 20:56:31 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1R3uZee009674; Sun, 26 Feb 2012 19:56:37 -0800 (PST) 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 q1R3twsO009581 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sun, 26 Feb 2012 19:56:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tsenevir@cisco.com; l=54664; q=dns/txt; s=iport; t=1330314967; x=1331524567; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=QlrxOCCKsTemz2odr7OjshjIk06MeexDwjfKO1HyjEI=; b=GiDCIIxP78nlZD0BjidTe7oxmDHkGpwD5Sgjbei+N2JvI8GIk7x+zLbT qUUSsvhvsvdTAoRpv9rQEfKVChbAOZBvcofVphNlYdXhRXGKk5VzAxMjV +Apg41PT29dga6CM6sQe7wW0SPUZbMed45Nnb/Cn2CNYR+0wtFIarD/pT k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcFAL39Sk+rRDoI/2dsb2JhbAA5AQmCUYJopQgBiQ2BB4FzAQEBBAEBAQ8BBwIRAz4LEAIBBgIRBAEBCwYQAQIEAQQCASAGHwkIAQEEARIIEweHYwygaAGMXwiJN4kPYQEEgxkBBAMBAQEBAwEBAgEEAQQFAQEBAQEEBUmEXQUIDggKDh4DBQYDAwEDBgEBCg0BBgsEFIITN2MEiE+YBYd4gTMBBA X-IronPort-AV: E=Sophos;i="4.73,489,1325462400"; d="scan'208,217";a="32542267" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 27 Feb 2012 03:55:58 +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 q1R3tw8L006622; Mon, 27 Feb 2012 03:55:58 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); Sun, 26 Feb 2012 19:55:58 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 26 Feb 2012 19:55:57 -0800 Message-ID: <344037D7CFEFE84E97E9CC1F56C5F4A5A4668C@xmb-sjc-214.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.txt Thread-Index: Acz1ApM/O5j962wwT2OkiBlkG7S4ywAAKc3Q References: <63D11BFF-F3DA-4D67-AAB4-434B0DB102E8@gmail.com> From: "Tissa Senevirathne (tsenevir)" To: , "Sam Aldrin" X-OriginalArrivalTime: 27 Feb 2012 03:55:58.0144 (UTC) FILETIME=[B6709400:01CCF503] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: tsenevir@cisco.com Cc: rbridge@postel.org, rbridge-bounces@postel.org, Radia Perlman Subject: Re: [rbridge] Default nickname base approach for multilevel TRILL- draft-tissa-trill-multilevel-00.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: multipart/mixed; boundary="===============0293641920==" Sender: rbridge-bounces@postel.org Errors-To: rbridge-bounces@postel.org This is a multi-part message in MIME format. --===============0293641920== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCF503.B641C850" This is a multi-part message in MIME format. ------_=_NextPart_001_01CCF503.B641C850 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable Like stated in other emails, nickname space expansion require proper = thoughts. =20 Radia=A1=AFs multi-level draft require new data plane changes to = implement nickname translation or nickname swap. What we are saying is = mult-level TRILL can be implemented with a simpler approach. =20 Nickname expansion needed to be solved with forward and progressive = looking approaches for that some careful thinking is required. =20 From: hu.fangwei@zte.com.cn [mailto:hu.fangwei@zte.com.cn]=20 Sent: Sunday, February 26, 2012 7:48 PM To: Sam Aldrin Cc: Radia Perlman; rbridge@postel.org; rbridge-bounces@postel.org; Tissa = Senevirathne (tsenevir) Subject: Re: Re: [rbridge] Default nickname base approach for multilevel = TRILL- draft-tissa-trill-multilevel-00.txt =20 Pls see the following:=20 The reason why folks in IP word are pushing to go to IPv6 is that the = exhausting of IPv4 address, not that the NAT can not work.=20 The NAT technology is widely deployed in China, and it does work well. = There is very little IPv4 address can be assigned to the BNAS(Most of = the address assigned to the user are private IPv4 address, and only the = NNAS and above equitment are assigned public address ), so it is an = emergent thing to transit from IPv4 to IPv6.=20 And your point is?=20 [hfw] My point is that the multi-level draft should solve the nickname = space issue.=20 There is a multi-level draft is proposed by Radia, we can optimize it = and make it better. There is no need to provide a new Multi-lelve draft = which can not solve the key issue of nickname space.=20 Sam Aldrin =20 2012-02-27 11:40=20 =CA=D5=BC=FE=C8=CB hu.fangwei@zte.com.cn=20 =B3=AD=CB=CD "Tissa Senevirathne (tsenevir)" , = rbridge@postel.org, rbridge-bounces@postel.org, Radia Perlman = =20 =D6=F7=CC=E2 Re: [rbridge] Default nickname base approach for multilevel TRILL- = draft-tissa-trill-multilevel-00.txt =20 =09 On Feb 26, 2012, at 6:50 PM, hu.fangwei@zte.com.cn = wrote:=20 The reason why folks in IP word are pushing to go to IPv6 is that the = exhausting of IPv4 address, not that the NAT can not work.=20 The NAT technology is widely deployed in China, and it does work well. = There is very little IPv4 address can be assigned to the BNAS(Most of = the address assigned to the user are private IPv4 address, and only the = NNAS and above equitment are assigned public address ), so it is an = emergent thing to transit from IPv4 to IPv6.=20 And your point is?=20 If we can not slove the nickname space issue now, do we need another = NICKNAMEv6 or something else?=20 That could be a topic, which could be taken up to resolve nickname = exhaustion issue and not necessarily at multilevel draft.=20 So i thing the nickname space issue is the key issue we should slove = now.=20 That topic should be considered outside of this draft.=20 Multi-level draft is a good platform to slove it, though there is some = technology we should considered futher.=20 If multilevel draft is only to address 'nickname exhaustion' issue, then = it should be renamed accordingly and not 'multilevel'. The purpose of = multilevel draft is different, which is stated in the draft and the by = product of it is nickname exhaustion could be alleviated and not just = the primary problem/solution. Here is the snip from abstract "..novel = method of constructing multi-destination trees using partial nickname = space"=20 cheers=20 -sam=20 "Tissa Senevirathne (tsenevir)" >=20 =B7=A2=BC=FE=C8=CB: rbridge-bounces@postel.org = =20 2012-02-25 02:07=20 =20 =CA=D5=BC=FE=C8=CB "Radia Perlman" = >=20 =B3=AD=CB=CD rbridge@postel.org , = rbridge-bounces@postel.org , = hu.fangwei@zte.com.cn =20 =D6=F7=CC=E2 Re: [rbridge] Default nickname base approach for multilevel TRILL- = draft-tissa-trill-multilevel-00.txt =20 =09 Also, there are so many well known issues with NAT like approaches. #1 = is you would lose identity of originator, and it becomes an OAM = nightmare. It limit ability apply certain ACL, rate-limiting etc.=20 =20 There is a whole series of issues associated with NATs. That is one of = the reasons folks in IP world are pushing hard to go to IPv6. I was = assuming people are aware of those.=20 =20 From: Radia Perlman [mailto:radiaperlman@gmail.com]=20 Sent: Friday, February 24, 2012 9:23 AM To: Tissa Senevirathne (tsenevir) Cc: hu.fangwei@zte.com.cn ; = rbridge@postel.org ; = rbridge-bounces@postel.org =20 Subject: Re: [rbridge] Default nickname base approach for multilevel = TRILL- draft-tissa-trill-multilevel-00.txt=20 =20 I assume that all RBridges will need to be in all topologies, so = multitopology will not help with nickname exhaustion. Plus you haven't = explained how a TRILL packet would be marked as to which topology the = packet should be routed according to (other than what I mentioned, which = actually eats up nicknames by a factor of the number of topologies = supported).=20 =20 Plus, rather than just lumping potential issues into a phrase such as = "NAT-like", be explicit about what issues there actually are. I believe = the Fulcrum chip would have no problem with translating the nickname = fields.=20 =20 And rather than assuming that nickname exhaustion can be solved "some = other way", there should be a palatable solution before rejecting a = chance to solve it with multilevel.=20 =20 Radia=20 2012/2/24 Tissa Senevirathne (tsenevir) >=20 Because you can have same nickname for different topology. It is not a = nickname that will identify an RBRidge, it is topology,nickname = combination that will identify an RBRidge. So RB1 can have nickname 1 in = topo-1 and RB2 can have nickname 1 in topo2. Now total nicknames in the = campus is 2**16 x topologies.=20 =20 Stealing bits to represent topo id is only a workaround there can be = (are ) more elegant ways of doing it that.=20 =20 Bottom line is we need to look for more creative methods of solving = nickname space issue than doing NAT like behavior.=20 =20 From: Radia Perlman [mailto:radiaperlman@gmail.com = ]=20 Sent: Friday, February 24, 2012 9:05 AM To: Tissa Senevirathne (tsenevir) Cc: hu.fangwei@zte.com.cn ; = rbridge@postel.org ; = rbridge-bounces@postel.org =20 Subject: Re: [rbridge] Default nickname base approach for multilevel = TRILL- draft-tissa-trill-multilevel-00.txt=20 =20 I don't understand how multi-topology helps with the nickname exhaustion = issue. As a matter of fact, the only plausible way of marking a packet = for which topology that has been suggested on the mailing list (I asked = a efw times if there were any other possibilities), was to steal 2 or 3 = bits of the nickname to encode which topology, in effect, making a = destination appear as multiple destinations and multiple forwarding = table entries (which you'd want anyway, for multitopology).=20 =20 =20 Radia=20 2012/2/24 Tissa Senevirathne (tsenevir) >=20 Mutli-topology is the answer to increase the nickname space.=20 =20 Nickname translation is very similar to NAT, which has it=A1=AFs own = down side, not to mention special hardware etc. to do the translations, = additionally. We also know from our experience, in IP world NATing is = not the most desired behavior and we live with it. So we should not be = going down that path instead need to look forward from that experience.=20 =20 Multi-topology not only address nickname space issue but also enables = various other applications such as overlay topologies, traffic = engineering.=20 =20 The draft-tiss-trill-multilevel present approaches that are generic, = which mean it can be applied for multi-topology, or base topology. It = utilizes the fundamentals of IS-IS , such as Area hierarchy for = reduction of the LSP-DB. It utilize affinity TLV concepts to effectively = solve multi-destination issues.=20 =20 We should not mix-up between Data center interconnects with data center = node scaling. They are two different and orthogonal issues.=20 =20 Objective of multi-level trill is to interconnect different datacenters, = and maintain LSP-DB small as possible to avoid scaling and volatility.=20 =20 Increasing nickname space a different requirement and has nothing to do = with data-center interconnects.=20 =20 =20 From: Radia Perlman [mailto:radiaperlman@gmail.com = ]=20 Sent: Friday, February 24, 2012 6:15 AM To: hu.fangwei@zte.com.cn =20 Cc: Tissa Senevirathne (tsenevir); rbridge@postel.org = ; rbridge-bounces@postel.org = =20 Subject: Re: [rbridge] Default nickname base approach for multilevel = TRILL- draft-tissa-trill-multilevel-00.txt=20 =20 People have mentioned to me that they are nervous about running out of = nicknames, especially since there are reasonson why they might want to = assign nicknames to hypervisors. With the alternate approach of = allowing nicknames to be reused in different areas, it makes automatic = nickname assignment much simpler and makes TRILL a lot more scalable.=20 =20 It does have the downside of requiring mapping of nicknames at the = border RBridges.=20 =20 And by the way, the affinity TLV can be used for multidestination frames = transiting between level 1 and level 2.=20 =20 Radia=20 2012/2/23 >=20 Hi, Tissa.=20 I have several comments about the draft.=20 (1) in section 4.4 (Multicast), "The scope of global traffic may be = identified either through VLAN or via finegrain=20 label that spans across the entire TRILL campus."=20 Vlan and Fine-grain Label is used for service differentiation and = isolation. I do not quite understand that how to=20 use VLAN and fine-grain Lable to identify the traffic scope. The data = traffic with a given VLAN-x, can=20 be forwarded to other end station in the local area, or to the end = station in remote areas.=20 (2) nickname allocation=20 The nickname management sub-TLV is proposed in the document. I wonder = this mechanism adds the complication of =20 nickname allocation. As the section 1 (introduction) of RFC6325, one of = the important advantage of TRILL is that =20 it avoids the creating subnets of IP address and wasting address. The = nickname acquisition method in this draft violates the =20 idea of TRILL Basic specification, and reduces the flexibility of = nickname allocation. As the draft assumed, A1 had =20 nickname range of 100-200, A2 has a local nickname range of 201-300. If = the numbers of A1 area is only 50, so 50 =20 nicknames in A1 is wasted. As the network growing, the number of some = areas may exceed the number being allocation =20 by Border RBridges. The design and maintaining of nickname ranges for = each area is a very hard work. Even worst, it =20 can not avoid to waste nickname space.=20 (3) Dynamic ranges=20 The nickname range is divided into two range: local range and dynamical = range. I wonder the nickname conflict =20 resolution can not work if the RBridge get the nickname from the = dynamical range while the two RBridge belongs to =20 different areas. For example, RB1 is in area A1, and RB2 is in area A2. = If RB1 gets the nickname N1 from dynamic =20 range, and it will floods in area A1, and other RBridges in area A1 can = not get nickname N1 because of nickname =20 confliction mechanism, but RB2 in area A2 can not receive the PDU from = RB1, and it can also get the nickname N1 from =20 dynamical range. So the question is how to avoid the duplication = dynamical range nickname for different areas.=20 (4) The risk of running out of nickname maybe a issue for TRILL. The = number of 2**16 nickname is enough for the current data center,=20 but it maybe not enough in the future, especailly if TRILL over IP , = TRILL over MPLS technology or some other data center technologies=20 are deployed, the data center network can be a very lardge network. So i = think the very important and essential goal of multi-level draft is to = save nicknames.=20 Best regards=20 Fangwei Hu=20 "Tissa Senevirathne (tsenevir)" >=20 =B7=A2=BC=FE=C8=CB: rbridge-bounces@postel.org = =20 2012-02-23 11:55=20 =20 =CA=D5=BC=FE=C8=CB >=20 =B3=AD=CB=CD =09 =D6=F7=CC=E2 [rbridge] Default nickname base approach for multilevel TRILL- = draft-tissa-trill-multilevel-00.txt =20 =20 =09 =09 Dear All We have submitted draft-tissa-trill-multilevel, present multilevel TRILL = based on default nickname approach. Additionally we discuss construction = of multi-destination trees and related RPF in multilevel TRILL. Please = could you review and comment=20 Detail of the draft and abstract are below. Filename: draft-tissa-trill-multilevel Revision: 00 Title: Default Nickname Based Approach = for Multilevel TRILL Creation date: 2012-02-21 WG ID: Individual Submission Number of pages: 26 Abstract: Multilevel TRILL allows the interconnection of multiple TRILL networks to form a larger TRILL network without proportionally increasing the size of the IS-IS LSP DB. In this document, an approach based on default route concept is presented. Also, presented in the document is a novel method of constructing multi- destination trees using partial nickname space. Methods presented in this document are compatible with the RFC6325 specified data plane operations. = =20 Thanks Tissa _______________________________________________ rbridge mailing list rbridge@postel.org =20 http://mailman.postel.org/mailman/listinfo/rbridge = =20 _______________________________________________ rbridge mailing list rbridge@postel.org =20 http://mailman.postel.org/mailman/listinfo/rbridge = =20 =20 =20 _______________________________________________ rbridge mailing list rbridge@postel.org =20 http://mailman.postel.org/mailman/listinfo/rbridge = =20 _______________________________________________ rbridge mailing list rbridge@postel.org =20 http://mailman.postel.org/mailman/listinfo/rbridge=20 ------_=_NextPart_001_01CCF503.B641C850 Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable

Like stated in other emails, nickname space expansion require proper = thoughts.

 

Radia=A1=AFs multi-level draft require new data plane changes to = implement nickname translation or nickname swap. What we are saying is = mult-level TRILL can  be implemented with a simpler = approach.

 

Nickname expansion needed to be solved with forward and progressive = looking approaches for that some careful thinking is = required.

 

From:= = hu.fangwei@zte.com.cn [mailto:hu.fangwei@zte.com.cn]
Sent: = Sunday, February 26, 2012 7:48 PM
To: Sam Aldrin
Cc: = Radia Perlman; rbridge@postel.org; rbridge-bounces@postel.org; Tissa = Senevirathne (tsenevir)
Subject: Re: Re: [rbridge] Default = nickname base approach for multilevel TRILL- = draft-tissa-trill-multilevel-00.txt

 


Pls see the = following:


The reason = why folks in IP word are pushing to go to IPv6 is that the exhausting of = IPv4 address, not that the NAT can not work.
The NAT = technology is widely deployed in China, and it does work well. There is = very little IPv4 address can be assigned to the BNAS(Most of the address = assigned to the user are private IPv4 address, and only the NNAS and = above equitment are assigned public address ), so it is an emergent = thing to transit from IPv4 to IPv6.
And your point is? =

[hfw] My point = is that the multi-level draft should solve the nickname space = issue.

There is a multi-level draft = is proposed by Radia, we can optimize it and make it better. There is no = need to provide a new Multi-lelve draft which can not solve the key = issue of nickname space.


Sam Aldrin = <aldrin.ietf@gmail.com> =

2012-02-27 = 11:40

hu.fangwei@zte= .com.cn

 

=CA=D5=BC=FE=C8=CB

=B3=AD=CB=CD

"Tissa = Senevirathne (tsenevir)" <tsenevir@cisco.com>, = rbridge@postel.org, rbridge-bounces@postel.org, Radia Perlman = <radiaperlman@gmail.com>

=D6=F7=CC=E2

Re: [rbridge] = Default nickname base approach for multilevel TRILL- = draft-tissa-trill-multilevel-00.txt





On Feb 26, 2012, at 6:50 PM, = hu.fangwei@zte.com.cn wrote: =


The = reason why folks in IP word are pushing to go to IPv6 is that the = exhausting of IPv4 address, not that the NAT can not work. =
The NAT = technology is widely deployed in China, and it does work well. There is = very little IPv4 address can be assigned to the BNAS(Most of the address = assigned to the user are private IPv4 address, and only the NNAS and = above equitment are assigned public address ), so it is an emergent = thing to transit from IPv4 to IPv6.
And your point is? =

If we = can not slove the nickname space issue now, do we need another = NICKNAMEv6 or something else?
That could be a topic, which = could be taken up to resolve nickname exhaustion issue and not = necessarily at multilevel draft.

So i = thing the nickname space issue is the key issue we should slove now. =
That topic = should be considered outside of this draft.

Multi-lev= el draft is a good platform to slove it, though there is some technology = we should considered futher.
If multilevel draft is only = to address 'nickname exhaustion' issue, then it should be renamed = accordingly and not 'multilevel'. The purpose of multilevel draft is = different, which is stated in the draft and the by product of it is = nickname exhaustion could be alleviated and not just the primary = problem/solution. Here is the snip from abstract = "..novel method of constructing multi-destination trees = using partial nickname space"

cheers =
-sam


"Tissa = Senevirathne (tsenevir)" <tsenevir@cisco= .com> =
=B7=A2=BC=FE=C8=CB: =  rbridge-bounce= s@postel.org

2012-02-25 = 02:07 =

 

"Radia = Perlman" <radiaperlman@g= mail.com> =

=

=CA=D5=BC=FE=C8=CB

=B3=AD=CB=CD

rbridge@postel= .org, rbridge-bounce= s@postel.org, hu.fangwei@zte= .com.cn =

=D6=F7=CC=E2

Re: [rbridge] = Default nickname base approach for multilevel TRILL-     =   =  draft-tissa-trill-multilevel-00.txt

 





Also, there are so many well known issues with NAT like = approaches. #1 is you would lose identity of originator, and it becomes = an OAM nightmare.  It limit ability apply certain ACL, = rate-limiting etc.
 
There is a whole series of issues associated with NATs. That is = one of the reasons folks in IP world are pushing hard to go to IPv6. I = was assuming people are aware of those.
 
From: Radia = Perlman [mailto:radiaperlman@gmail.com]
Sent: Friday, = February 24, 2012 9:23 AM
To: Tissa Senevirathne = (tsenevir)
Cc: hu.fangwei@z= te.com.cn; rbridge@post= el.org; rbridge-boun= ces@postel.org
Subject:= Re: = [rbridge] Default nickname base approach for multilevel TRILL- = draft-tissa-trill-multilevel-00.txt
 
I assume that = all RBridges will need to be in all topologies, so multitopology will = not help with nickname exhaustion.  Plus you haven't explained how = a TRILL packet would be marked as to which topology the packet should be = routed according to (other than what I mentioned, which actually eats up = nicknames by a factor of the number of topologies supported). =
 
Plus, rather than just lumping potential issues into a = phrase such as "NAT-like", be explicit about what issues there = actually are.  I believe the Fulcrum chip would have no problem = with translating the nickname fields.
 
And rather than = assuming that nickname exhaustion can be solved "some other = way", there should be a palatable solution before rejecting a = chance to solve it with multilevel.
 
Radia
2012/2/24 = Tissa Senevirathne (tsenevir) <tsenevir@cisco.com<= span style=3D'font-family:"Arial","sans-serif"'>>
Because you can have same nickname for different topology. It is = not a nickname that will identify an RBRidge, it is topology,nickname = combination that will identify an RBRidge. So RB1 can have nickname 1 in = topo-1 and RB2 can have nickname 1 in topo2. Now total nicknames in the = campus is 2**16 x topologies.
 
Stealing bits to represent topo id is only a workaround there can = be (are ) more elegant ways of doing it that.
 
Bottom line is we need to look for more creative methods of = solving nickname space issue than doing NAT like behavior. =
 
From: Radia = Perlman [mailto:radiaperlman= @gmail.com] =
Sent: Friday, February 24, 2012 9:05 AM
To: Tissa = Senevirathne (tsenevir)
Cc: hu.fangwei@z= te.com.cn; rbridge@post= el.org; rbridge-boun= ces@postel.org =

Subject: Re: [rbridge] Default nickname base approach for = multilevel TRILL- draft-tissa-trill-multilevel-00.txt
 
I don't = understand how multi-topology helps with the nickname exhaustion issue. =  As a matter of fact, the only plausible way of marking a packet = for which topology that has been suggested on the mailing list (I asked = a efw times if there were any other possibilities), was to steal 2 or 3 = bits of the nickname to encode which topology, in effect, making a = destination appear as multiple destinations and multiple forwarding = table entries (which you'd want anyway, for multitopology). =
 
 
Radia
2012/2/24 Tissa Senevirathne = (tsenevir) <tsenevir@cisco.com<= span style=3D'font-family:"Arial","sans-serif"'>>
Mutli-topology is the answer to increase the nickname = space. =
 
Nickname translation is very similar to NAT, which has it=A1=AFs = own down side, not to mention special hardware etc. to do the = translations, additionally. We also know from our experience, in IP = world NATing is not the most desired behavior and we live with it. So we = should not be going down that path instead need to look forward from = that experience. =
 
Multi-topology not only address nickname space issue but also = enables various other applications such as overlay topologies, traffic = engineering. =
 
The draft-tiss-trill-multilevel present approaches that are = generic, which mean it can be applied for multi-topology, or base = topology. It utilizes the fundamentals of IS-IS , such as Area hierarchy = for reduction of the LSP-DB. It utilize affinity TLV concepts to = effectively solve multi-destination issues.
 
We should not mix-up between Data center interconnects with data = center node scaling. They are two different and orthogonal = issues. =
 
Objective of multi-level trill is to interconnect different = datacenters, and maintain LSP-DB small as possible to avoid scaling and = volatility. =
 
Increasing nickname space a different requirement and has nothing = to do with data-center interconnects.
 
 
From: Radia = Perlman [mailto:radiaperlman= @gmail.com] =
Sent: Friday, February 24, 2012 6:15 AM
To: = hu.fangwei@z= te.com.cn
Cc: Tissa = Senevirathne (tsenevir); rbridge@post= el.org; rbridge-boun= ces@postel.org
Subject:= Re: = [rbridge] Default nickname base approach for multilevel TRILL- = draft-tissa-trill-multilevel-00.txt
 
People have = mentioned to me that they are nervous about running out of nicknames, = especially since there are reasonson why they might want to assign = nicknames to hypervisors.  With the alternate approach of allowing = nicknames to be reused in different areas, it makes automatic nickname = assignment much simpler and makes TRILL a lot more scalable. =
 
It does have the downside of requiring mapping of = nicknames at the border RBridges.
 
And by the way, the = affinity TLV can be used for multidestination frames transiting between = level 1 and level 2.
 
Radia
2012/2/23 <hu.fangwei@zte.com.cn>

Hi, = Tissa.

I have several comments about the draft.

(1) in = section 4.4 (Multicast), "The scope of global traffic may be = identified either through VLAN or via finegrain
label that spans = across the entire TRILL campus."
Vlan and Fine-grain Label is = used for service differentiation and isolation. I do not quite = understand that how to
use VLAN and fine-grain Lable to identify the = traffic scope. The data traffic with a given VLAN-x, can
be = forwarded to other end station in the local area, or to the end station = in remote areas.

(2) nickname allocation
The nickname = management sub-TLV is proposed in the document. I wonder this mechanism = adds the complication of  
nickname allocation. As the section = 1 (introduction) of RFC6325, one of the important advantage of TRILL is = that  
it avoids the creating subnets of IP address and wasting = address. The nickname acquisition  method in this draft violates = the  
idea of TRILL Basic specification, and reduces the = flexibility of nickname allocation. As the draft assumed, A1 had   =
nickname range of 100-200, A2 has a local nickname range of 201-300. = If the numbers of A1 area is only 50, so 50  
nicknames in A1 = is wasted. As the network growing, the number of some areas may exceed = the number being allocation  
by Border RBridges. The design = and maintaining of nickname ranges for each area is a very hard work. = Even worst, it  
can not avoid to waste nickname space. =

(3) Dynamic ranges
The nickname range is divided into two = range: local range and dynamical range. I wonder the nickname conflict =  
resolution can not work if the RBridge get the nickname from = the dynamical range while the two RBridge belongs to   =
different areas. For example, RB1 is in area A1, and RB2 is in area = A2. If RB1 gets the nickname N1 from dynamic  
range, and it = will floods in area A1, and other RBridges in area A1 can not get = nickname N1 because of nickname  
confliction mechanism, but = RB2 in area A2 can not receive the PDU from RB1, and it  can also = get the nickname N1 from  
dynamical range. So the question is = how to avoid the duplication dynamical range nickname for different = areas.

(4) The risk of running out of nickname maybe a issue for = TRILL. The number of 2**16 nickname is enough for the current data = center,
but it maybe not enough in the future, especailly if TRILL = over IP , TRILL over MPLS technology or some other data center = technologies
are deployed, the data center network can be a very = lardge network. So i think the very important and essential goal of = multi-level draft is to save nicknames.

Best regards
Fangwei = Hu

"Tissa = Senevirathne (tsenevir)" <tsenevir@cisco= .com> =
=B7=A2=BC=FE=C8=CB: =  rbridge-bounce= s@postel.org =

2012-02-23 = 11:55 =

 

<rbridge@postel= .org> =

=

=CA=D5=BC=FE=C8=CB

=B3=AD=CB=CD

=D6=F7=CC=E2

[rbridge] = Default nickname base approach for multilevel TRILL-     =   =  draft-tissa-trill-multilevel-00.txt



  =

 





Dear = All

We have submitted draft-tissa-trill-multilevel, present = multilevel TRILL based on default nickname approach. Additionally we = discuss construction of multi-destination trees and related RPF in = multilevel TRILL. Please could you review and comment

Detail of = the draft and abstract are below.

Filename:       =           =  draft-tissa-trill-multilevel
Revision:       =            00
Title:     =                     =           Default Nickname Based Approach for = Multilevel TRILL
Creation date:           =        2012-02-21
WG ID:       =                     =         Individual Submission
Number of pages: = 26

Abstract:
Multilevel TRILL allows the interconnection of = multiple TRILL
networks to form a larger TRILL network without = proportionally
increasing the size of the IS-IS LSP DB. In this = document, an
approach based on default route concept is presented. = Also,
presented in the document is a novel method of constructing = multi-
destination trees using partial nickname space. Methods = presented in
this document are compatible with the RFC6325 specified = data plane
operations.

          =                     =                     =                     =         =  
Thanks
Tissa

________________________________________= _______
rbridge mailing list
rbridge@postel.org<= u>
http://mailman.postel.org/mail= man/listinfo/rbridge =

_______________________________________________
rbridge = mailing list
rbridge@postel.org<= u>
http://mailman.postel.org/mail= man/listinfo/rbridge =
 
 
______________________________________= _________
rbridge mailing list
rbridge@postel.org
http://ma= ilman.postel.org/mailman/listinfo/rbridge

______________________= _________________________
rbridge mailing list
rbridge@postel.org<= span = style=3D'font-family:"Arial","sans-serif"'>
http://mailman.postel.org/= mailman/listinfo/rbridge

------_=_NextPart_001_01CCF503.B641C850-- --===============0293641920== 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 --===============0293641920==-- From rbridge-bounces@postel.org Mon Feb 27 10:27: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 F1E0C21F8794 for ; Mon, 27 Feb 2012 10:27:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.813 X-Spam-Level: X-Spam-Status: No, score=-106.813 tagged_above=-999 required=5 tests=[AWL=1.786, BAYES_00=-2.599, GB_I_LETTER=-2, 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 Zmse65uxUC7y for ; Mon, 27 Feb 2012 10:27:36 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id D10DD21F878B for ; Mon, 27 Feb 2012 10:27:36 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1RICiY3028374; Mon, 27 Feb 2012 10:12:47 -0800 (PST) Received: from mail-bk0-f52.google.com (mail-bk0-f52.google.com [209.85.214.52]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1RIBnDB028217 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 27 Feb 2012 10:11:59 -0800 (PST) Received: by bkcji1 with SMTP id ji1so6810594bkc.39 for ; Mon, 27 Feb 2012 10:11:48 -0800 (PST) Received-SPF: pass (google.com: domain of d3e3e3@gmail.com designates 10.112.29.38 as permitted sender) client-ip=10.112.29.38; Authentication-Results: mr.google.com; spf=pass (google.com: domain of d3e3e3@gmail.com designates 10.112.29.38 as permitted sender) smtp.mail=d3e3e3@gmail.com; dkim=pass header.i=d3e3e3@gmail.com Received: from mr.google.com ([10.112.29.38]) by 10.112.29.38 with SMTP id g6mr4171551lbh.102.1330366308437 (num_hops = 1); Mon, 27 Feb 2012 10:11:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=OwxfJaoOm4LM0D7SedEQRWchZlCXXjfoaRy7W2j1I8k=; b=DcbcuJolJt+sEfxJOVtzXHlHcx4+9TYUuRS6XlW+oLWvcboql6MJDy/2C3szMTUWfD UlwkOWbYSw+/95tjWg4wGc4AnHUbVqKXEW6GqoB/MqJsFOEIfcb7MupurvTk0kUyOfgS U/ar9WeWbHDCbCSvL4sadsvXdmrj/4BQBtyD0= Received: by 10.112.29.38 with SMTP id g6mr3526214lbh.102.1330366308310; Mon, 27 Feb 2012 10:11:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.80.234 with HTTP; Mon, 27 Feb 2012 10:11:28 -0800 (PST) In-Reply-To: References: From: Donald Eastlake Date: Mon, 27 Feb 2012 13:11:28 -0500 Message-ID: To: Vishwas Manral 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 q1RIBnDB028217 Cc: "rbridge@postel.org" Subject: Re: [rbridge] WG last call on draft-ietf-trill-rbridge-bfd-02 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 Vishwas, See separate response to be posted later on the Security Considerations material. On editorial changes: 1. I don't know why "Channel" was deleted in the first entry in Section 2. It is usual in acronym explanations to show what each letter stands for and it was my impression that the middle letter in ACH stood for Channel. 2. The two occurrences of "[TRILLoam]" need to be changed to "[TRILLChannel= ]". 3. The references to RFC 5082 and RFC 5586 should be moved from the lists of Normative References to Informative References. 4. Replace "plaen" with "plane". 5. After the first paragraph in Section 9, there is an introductory line followed by 4 points. (5a) The second point ends with a period and, to be consistent, should end in a comma. (5b) The 4 points should each be at least indented and probably bulleted (that is, each point started with "o " (a lower case oh followed by two spaces) or something like that. 6. In Section 10, replace "It is required that the operator of an RBridge campus configure ..." with "It is up to the operator of an RBridge campus to configure ...". 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, Feb 25, 2012 at 8:08 PM, Vishwas Manral wr= ote: > Hi Donald, > > I started to edit the document. I agree with the general concept of what = we > are trying to achieve but I disagree with the changes you mention below. > > I think BFD security should be in the BFD spec (infact there is BFD WG wo= rk > on the same ). We can talk about keys used in the BFD. We already have wo= rk > on the algorithms of BFD located in the link below. I do not see a reason > BFD should use Keying mechanisms any different from what base BFD > specification provides. Guess a reference to the below draft could be good > enough. > > http://tools.ietf.org/html/draft-ietf-bfd-hmac-sha-00 > > I have attached the documents with the changes discussed in the WG though. > > Thanks, > Vishwas > > On Thu, Feb 16, 2012 at 7:37 PM, Donald Eastlake wrote: >> >> Hi Ayan, >> >> On Thu, Feb 16, 2012 at 12:27 AM, ayabaner wrote: >> > Donald, >> > >> > Some comments in-line. >> > >> > Thanks, >> > Ayan >> > >> > On 2/14/12 8:42 PM, "Donald Eastlake" wrote: >> > >> >> I would like to suggest the addition of some material to the Security >> >> Considerations section. Something like what I've pasted below my .sig >> >> and above Erik's message blow... >> >> >> >> 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 >> >> >> >> >> >> =A0 =A0Consist with TRILL's goal of minimum configuration, the defaul= t for >> >> =A0 =A0BFD security between neighbor RBridges is based on that state = of >> >> =A0 =A0IS-IS shared secret authentication for Hello between those >> >> =A0 =A0RBridges. =A0If such IS-IS authentication is not in effect the= n, by >> >> =A0 =A0default, TRILL BFD between those RBridges is also unsecured. B= ut >> >> =A0 =A0the RBridges may be configured to use BFD Security. >> > >> > [Ayan] I am assuming that the configuration above for the BFD Security >> > is >> > independent on the IS-IS authentication configurations (if any). >> >> Yes. The idea is just that, in the normal case where if you are going >> to secure one, you are probably going to secure both Hellos and BFD, >> consistent with TRILL's goal of minimal required configuration, you >> should only have to configure IS-IS security if you are willing to >> take the default BFD security. >> >> >> =A0 =A0If such IS-IS authentication is in effect then, unless configu= red >> >> =A0 =A0otherwise, TRILL BFD Control frames sent between those RBridge= s use >> >> =A0 =A0BFD Meticulous Keyed SHA1 authentication [RF5880] with keying >> >> =A0 =A0material derived as shown below >> >> >> >> =A0 =A0 =A0 =A0HMAC-SHA256 ( ( "TRILL BFD Control" | originatorMAC | >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 originatorPortID ), I= S-IS-shared-key ) >> >> >> >> =A0 =A0where HMAC-SHA256 [RFC6234], "TRILL BFD Control" is the sevent= een >> >> =A0 =A0byte US ASCII [RFC20] string indicated that is then concatenat= ed >> >> =A0 =A0with the 6-byte MAC of the originating port and then the 2-byte >> >> =A0 =A0Port ID as would be sent in a TRILL Hello on that port. These >> >> =A0 =A0quantities are included to minimize expose of the same key to >> >> =A0 =A0improve resistance to cryptanalysis. IS-IS-key is the secret k= eying >> >> =A0 =A0material being used for IS-IS authentication on the link. >> > >> > [Ayan] Should we be sharing the "secret" key between the two protocols >> > or >> > mandate the user to configure both to be identical. I realize the >> > minimal >> > configuration goals, but I am wondering if it would be nice to keep the >> > core >> > TRILL-BFD pieces TRILL-IS-IS agnostic. >> >> This text doesn't go into implementation details, and I don't think it >> should, you just need some way to give the key to the BFD code. Since >> the BFD is derived in a cryptographically secure way from the IS-IS >> key, neither one reveals anything about the other. Actually, the >> expression for the key could be simplified. Since the PortID isn't >> actually in the BFD messages, including it causes some complications >> so it should probably be removed... >> >> Improved text, including typo fixes, at bottom of message below. >> >> 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 >> >> >> =A0 =A0In the >> >> =A0 =A0Authentication Section of the BFD Control frame OAM protocol >> >> =A0 =A0specific data, Auth Type would be 5, Auth Len would be 28, and= Auth >> >> =A0 =A0Key ID is zero. The RBridges MAY be configured to use other BFD >> >> =A0 =A0security modes or keying material including configuration to u= se no >> >> =A0 =A0security. >> >> >> >> =A0 =A0Authentication for TRILL BFD Echo SHOULD be provided but is a = local >> >> =A0 =A0implementation issue as BFD Echo frames are authenticated by t= heir >> >> =A0 =A0sender when received in the form of Echo responses. However, if >> >> =A0 =A0TRILL IS-IS and BFD Control are being authenticated to a neigh= bor >> >> =A0 =A0and BFD Echo is in use, BFD Echo frames to be returned by that >> >> =A0 =A0neighbor SHOULD be authenticated and such authenticate SHOULD = use >> >> =A0 =A0different keying material from other types of authentication. = =A0For >> >> =A0 =A0example, it could use keying material derived as follows: >> >> >> >> =A0 =A0 =A0 HMAC-SHA256 ( ( "TRILL BFD Echo" | originatorMAC | >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 originatorPortID ), IS-IS= -shared-key ) >> >> >> >> >> >> On Wed, Feb 1, 2012 at 2:44 PM, Erik Nordmark wrot= e: >> >>> >> >>> The WG last call ends on Feb 15th. >> >>> Please send comments (including ones that say you've read the docume= nt >> >>> and it is fine) to the rbridge list. >> >>> >> >>> =A0 Erik >> >> >> =A0 Consistent with TRILL's goal of being able to operate with minimum >> =A0 configuration, the default for BFD security between neighbor >> =A0 RBridges is based on that state of IS-IS shared secret >> =A0 authentication for Hello between those RBridges. However, if such >> =A0 BFD security is configured then its configuration is independent of >> =A0 that for IS-IS security. >> >> =A0 If IS-IS authentication is not in effect between neighbor RBridges >> =A0 then, by default, TRILL BFD between those RBridges is also >> =A0 unsecured. If such IS-IS authentication is in effect then, unless >> =A0 configured otherwise, TRILL BFD Control frames sent between those >> =A0 RBridges use BFD Meticulous Keyed SHA1 authentication [RF5880] with >> =A0 keying material derived as shown below >> >> =A0 =A0 =A0 HMAC-SHA256 ( ( "TRILL BFD Control" | originatorMAC ), >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 IS-IS-shared-key ) >> >> =A0 where HMAC-SHA256 is described in [RFC6234], "TRILL BFD Control" is >> =A0 the seventeen byte US ASCII [RFC20] string indicated that is then >> =A0 concatenated with the 6-byte MAC of the originating port. The MAC >> =A0 is included to minimize exposure of the same key to improve >> =A0 resistance to cryptanalysis. IS-IS-key is the secret keying >> =A0 material being used for IS-IS authentication on the link. In the >> =A0 Authentication Section of the BFD Control frame OAM protocol >> =A0 specific data, Auth Type would be 5, Auth Len would be 28, and Auth >> =A0 Key ID is zero. The RBridges MAY be configured to use other BFD >> =A0 security modes or keying material or configured to use no security. >> >> =A0 Authentication for TRILL BFD Echo is a local implementation issue >> =A0 as BFD Echo frames are authenticated by their sender when received >> =A0 in the form of Echo responses. However, if TRILL IS-IS and BFD >> =A0 Control are being authenticated to a neighbor and BFD Echo is in >> =A0 use, BFD Echo frames to be returned by that neighbor SHOULD be >> =A0 authenticated and such authenticate SHOULD use different keying >> =A0 material from other types of authentication. =A0For example, it could >> =A0 use keying material derived as follows: >> >> =A0 =A0 =A0HMAC-SHA256 ( ( "TRILL BFD Echo" | originatorMAC ), >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IS-IS-shared-key ) >> >> _______________________________________________ >> 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 Tue Feb 28 21:15:39 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 8EE9D21E8039 for ; Tue, 28 Feb 2012 21:15:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.84 X-Spam-Level: X-Spam-Status: No, score=-105.84 tagged_above=-999 required=5 tests=[AWL=0.759, 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 5pRWKaYMS0c0 for ; Tue, 28 Feb 2012 21:15:38 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 4B94E21E8012 for ; Tue, 28 Feb 2012 21:15:37 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1T4vmXr015255; Tue, 28 Feb 2012 20:57:50 -0800 (PST) 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 q1T4v6pb015208 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 28 Feb 2012 20:57:16 -0800 (PST) Received: by lahi5 with SMTP id i5so3323210lah.39 for ; Tue, 28 Feb 2012 20:57:05 -0800 (PST) Received-SPF: pass (google.com: domain of d3e3e3@gmail.com designates 10.112.102.65 as permitted sender) client-ip=10.112.102.65; Authentication-Results: mr.google.com; spf=pass (google.com: domain of d3e3e3@gmail.com designates 10.112.102.65 as permitted sender) smtp.mail=d3e3e3@gmail.com; dkim=pass header.i=d3e3e3@gmail.com Received: from mr.google.com ([10.112.102.65]) by 10.112.102.65 with SMTP id fm1mr8856933lbb.88.1330491425309 (num_hops = 1); Tue, 28 Feb 2012 20:57:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=3SO/oF8cbiVSjhGpGN/laGnokymniUeqYikmOGarcFM=; b=eQJ3dA0E+lyrwLHfs5pXOvl3ABT73aXstH4NkOIvx4XpZ6uoq4DudOhyoBiNSzWx7r CYT21sxvttOLQXBIT28z7rjaPw+D2dvzhavVyt1mC6QTQiLaaZHw/jhStSoxazKJu0z2 IguD6RPk67KjIB9gyGbukRLM7uY4Y5ickuamc= Received: by 10.112.102.65 with SMTP id fm1mr7410723lbb.88.1330491424942; Tue, 28 Feb 2012 20:57:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.80.234 with HTTP; Tue, 28 Feb 2012 20:56:00 -0800 (PST) In-Reply-To: References: From: Donald Eastlake Date: Tue, 28 Feb 2012 23:56:00 -0500 Message-ID: To: Vishwas Manral 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 q1T4v6pb015208 Cc: "rbridge@postel.org" Subject: Re: [rbridge] WG last call on draft-ietf-trill-rbridge-bfd-02 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 Vishwas, On Sat, Feb 25, 2012 at 8:08 PM, Vishwas Manral wr= ote: > Hi Donald, > > I started to edit the document. I agree with the general concept of what = we > are trying to achieve but I disagree with the changes you mention below. > > I think BFD security should be in the BFD spec (infact there is BFD WG wo= rk > on the same ). We can talk about keys used in the BFD. I agree with that. Perhaps there are a few missing words in the text I proposed. My goal was just to say that, if a bunch of conditions are met as stated, then the default algorithm ("authentication type" in BFD terminology) and keying material are as the proposed text states. The base BFD RFC 5880 says The same authentication type, and any keys or other necessary information, obviously must be in use by the two systems. The negotiation of authentication type, key exchange, etc., are all outside the scope of this specification and are expected to be performed by means outside of the protocol. So, specifying a default authentication type (Meticulous Keyed SHA1) and default keying material, the this TRILL BFD draft is specifying something which is explicitly outside the scope of the BFD protocol. > We already have work > on the algorithms of BFD located in the link below. In RFC 5880, I believe the algorithms you are talking about are called "authentication type". The TRILL BFD draft does not add any new authentication type. > I do not see a reason > BFD should use Keying mechanisms any different from what base BFD > specification provides. As far as I can see, the base BFD specification provides no mechanism for getting the same keying material at the communicating stations. > Guess a reference to the below draft could be good enough. > http://tools.ietf.org/html/draft-ietf-bfd-hmac-sha-00 I don't see what the above draft has to do with it as that draft simply specifies addition authentication types. Perhaps some aspects of the text are unclear. As editorial clarifications, I would suggest the following changes: (1) replace the three occurrences of "BFD security" with "BFD authenticatio= n". (2) as suggested by Erik Nordmark, replace "... the 6-byte MAC of the originating port." with "... the 6-byte MAC of the originating port in network byte order." (3) Inserting a new sentence just after "... used for IS-IS authentication on the link." as follows "This is accomplished by associating the above default authentication type and key with Key ID zero and using that Key ID." This is, to my mind, already implied when it later says the Key ID field is zero, but I think adding this sentence makes it clearer. > I have attached the documents with the changes discussed in the WG though. See http://www.postel.org/pipermail/rbridge/2012-February/004818.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 > Thanks, > Vishwas > > On Thu, Feb 16, 2012 at 7:37 PM, Donald Eastlake wrote: >> >> Hi Ayan, >> >> On Thu, Feb 16, 2012 at 12:27 AM, ayabaner wrote: >> > Donald, >> > >> > Some comments in-line. >> > >> > Thanks, >> > Ayan >> > >> > On 2/14/12 8:42 PM, "Donald Eastlake" wrote: >> > >> >> I would like to suggest the addition of some material to the Security >> >> Considerations section. Something like what I've pasted below my .sig >> >> and above Erik's message blow... >> >> >> >> 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 >> >> >> >> >> >> =A0 =A0Consist with TRILL's goal of minimum configuration, the defaul= t for >> >> =A0 =A0BFD security between neighbor RBridges is based on that state = of >> >> =A0 =A0IS-IS shared secret authentication for Hello between those >> >> =A0 =A0RBridges. =A0If such IS-IS authentication is not in effect the= n, by >> >> =A0 =A0default, TRILL BFD between those RBridges is also unsecured. B= ut >> >> =A0 =A0the RBridges may be configured to use BFD Security. >> > >> > [Ayan] I am assuming that the configuration above for the BFD Security >> > is >> > independent on the IS-IS authentication configurations (if any). >> >> Yes. The idea is just that, in the normal case where if you are going >> to secure one, you are probably going to secure both Hellos and BFD, >> consistent with TRILL's goal of minimal required configuration, you >> should only have to configure IS-IS security if you are willing to >> take the default BFD security. >> >> >> =A0 =A0If such IS-IS authentication is in effect then, unless configu= red >> >> =A0 =A0otherwise, TRILL BFD Control frames sent between those RBridge= s use >> >> =A0 =A0BFD Meticulous Keyed SHA1 authentication [RF5880] with keying >> >> =A0 =A0material derived as shown below >> >> >> >> =A0 =A0 =A0 =A0HMAC-SHA256 ( ( "TRILL BFD Control" | originatorMAC | >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 originatorPortID ), I= S-IS-shared-key ) >> >> >> >> =A0 =A0where HMAC-SHA256 [RFC6234], "TRILL BFD Control" is the sevent= een >> >> =A0 =A0byte US ASCII [RFC20] string indicated that is then concatenat= ed >> >> =A0 =A0with the 6-byte MAC of the originating port and then the 2-byte >> >> =A0 =A0Port ID as would be sent in a TRILL Hello on that port. These >> >> =A0 =A0quantities are included to minimize expose of the same key to >> >> =A0 =A0improve resistance to cryptanalysis. IS-IS-key is the secret k= eying >> >> =A0 =A0material being used for IS-IS authentication on the link. >> > >> > [Ayan] Should we be sharing the "secret" key between the two protocols >> > or >> > mandate the user to configure both to be identical. I realize the >> > minimal >> > configuration goals, but I am wondering if it would be nice to keep the >> > core >> > TRILL-BFD pieces TRILL-IS-IS agnostic. >> >> This text doesn't go into implementation details, and I don't think it >> should, you just need some way to give the key to the BFD code. Since >> the BFD is derived in a cryptographically secure way from the IS-IS >> key, neither one reveals anything about the other. Actually, the >> expression for the key could be simplified. Since the PortID isn't >> actually in the BFD messages, including it causes some complications >> so it should probably be removed... >> >> Improved text, including typo fixes, at bottom of message below. >> >> 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 >> >> >> =A0 =A0In the >> >> =A0 =A0Authentication Section of the BFD Control frame OAM protocol >> >> =A0 =A0specific data, Auth Type would be 5, Auth Len would be 28, and= Auth >> >> =A0 =A0Key ID is zero. The RBridges MAY be configured to use other BFD >> >> =A0 =A0security modes or keying material including configuration to u= se no >> >> =A0 =A0security. >> >> >> >> =A0 =A0Authentication for TRILL BFD Echo SHOULD be provided but is a = local >> >> =A0 =A0implementation issue as BFD Echo frames are authenticated by t= heir >> >> =A0 =A0sender when received in the form of Echo responses. However, if >> >> =A0 =A0TRILL IS-IS and BFD Control are being authenticated to a neigh= bor >> >> =A0 =A0and BFD Echo is in use, BFD Echo frames to be returned by that >> >> =A0 =A0neighbor SHOULD be authenticated and such authenticate SHOULD = use >> >> =A0 =A0different keying material from other types of authentication. = =A0For >> >> =A0 =A0example, it could use keying material derived as follows: >> >> >> >> =A0 =A0 =A0 HMAC-SHA256 ( ( "TRILL BFD Echo" | originatorMAC | >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 originatorPortID ), IS-IS= -shared-key ) >> >> >> >> >> >> On Wed, Feb 1, 2012 at 2:44 PM, Erik Nordmark wrot= e: >> >>> >> >>> The WG last call ends on Feb 15th. >> >>> Please send comments (including ones that say you've read the docume= nt >> >>> and it is fine) to the rbridge list. >> >>> >> >>> =A0 Erik >> >> >> =A0 Consistent with TRILL's goal of being able to operate with minimum >> =A0 configuration, the default for BFD security between neighbor >> =A0 RBridges is based on that state of IS-IS shared secret >> =A0 authentication for Hello between those RBridges. However, if such >> =A0 BFD security is configured then its configuration is independent of >> =A0 that for IS-IS security. >> >> =A0 If IS-IS authentication is not in effect between neighbor RBridges >> =A0 then, by default, TRILL BFD between those RBridges is also >> =A0 unsecured. If such IS-IS authentication is in effect then, unless >> =A0 configured otherwise, TRILL BFD Control frames sent between those >> =A0 RBridges use BFD Meticulous Keyed SHA1 authentication [RF5880] with >> =A0 keying material derived as shown below >> >> =A0 =A0 =A0 HMAC-SHA256 ( ( "TRILL BFD Control" | originatorMAC ), >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 IS-IS-shared-key ) >> >> =A0 where HMAC-SHA256 is described in [RFC6234], "TRILL BFD Control" is >> =A0 the seventeen byte US ASCII [RFC20] string indicated that is then >> =A0 concatenated with the 6-byte MAC of the originating port. The MAC >> =A0 is included to minimize exposure of the same key to improve >> =A0 resistance to cryptanalysis. IS-IS-key is the secret keying >> =A0 material being used for IS-IS authentication on the link. In the >> =A0 Authentication Section of the BFD Control frame OAM protocol >> =A0 specific data, Auth Type would be 5, Auth Len would be 28, and Auth >> =A0 Key ID is zero. The RBridges MAY be configured to use other BFD >> =A0 security modes or keying material or configured to use no security. >> >> =A0 Authentication for TRILL BFD Echo is a local implementation issue >> =A0 as BFD Echo frames are authenticated by their sender when received >> =A0 in the form of Echo responses. However, if TRILL IS-IS and BFD >> =A0 Control are being authenticated to a neighbor and BFD Echo is in >> =A0 use, BFD Echo frames to be returned by that neighbor SHOULD be >> =A0 authenticated and such authenticate SHOULD use different keying >> =A0 material from other types of authentication. =A0For example, it could >> =A0 use keying material derived as follows: >> >> =A0 =A0 =A0HMAC-SHA256 ( ( "TRILL BFD Echo" | originatorMAC ), >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IS-IS-shared-key ) >> >> _______________________________________________ >> 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