From ghanwani@gmail.com Mon Dec 3 19:05:27 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D1521F8921 for ; Mon, 3 Dec 2012 19:05:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62+tfWR0bEij for ; Mon, 3 Dec 2012 19:05:26 -0800 (PST) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) by ietfa.amsl.com (Postfix) with ESMTP id DA2EC21F8923 for ; Mon, 3 Dec 2012 19:05:14 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id c11so5424835ieb.19 for ; Mon, 03 Dec 2012 19:05:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=jOJi6/vPpzOXotStSdN5YWxXtR6niRvuBGdb3ifs+VI=; b=XwsIR93YAwj3M3YpBexK0a8kHCKG/ZHpyYVZUq7Ea9jm/yRU96mhg879L89gnVurqQ f5N8+RDs+VcXfzH/IAam43RjgjRFg8sXZz/YiKOmw9HWvxWPmEPvZC80m1vJCQ46VilV lD3ju1dqZ9VJ3DYkcPpl5oprsnjnA1RDsYQJsPGcf7hQ6Uvh4wk+TRlei4S3pzaQnj9E fjnB9y+4RfxxDQgyQYjkDtx3IRXqt0/XrAzHnU0l2mHzuSBCbixA+c+rkDMKsYCgyLtu 7P7z/g+EnGuSM3ccAzMdm6vGnfT+rCaG8NJ0mOtP0sXn68Ycc8LZJCSVYtaFc2ZOn1ou 2J3A== MIME-Version: 1.0 Received: by 10.50.106.227 with SMTP id gx3mr1294973igb.10.1354590313572; Mon, 03 Dec 2012 19:05:13 -0800 (PST) Sender: ghanwani@gmail.com Received: by 10.50.182.201 with HTTP; Mon, 3 Dec 2012 19:05:13 -0800 (PST) In-Reply-To: <4552F0907735844E9204A62BBDD325E732132977@SZXEML507-MBS.china.huawei.com> References: <4552F0907735844E9204A62BBDD325E732132977@SZXEML507-MBS.china.huawei.com> Date: Mon, 3 Dec 2012 19:05:13 -0800 X-Google-Sender-Auth: RAuz9LC6pveHv91pEGrIkGtRn2g Message-ID: From: Anoop Ghanwani To: Mingui Zhang Content-Type: multipart/alternative; boundary=e89a8f2351af74e8a204cffe22ab Cc: "trill@ietf.org" Subject: Re: [trill] TRILL Resilient Distribution Trees, who have read it? X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 03:05:27 -0000 --e89a8f2351af74e8a204cffe22ab Content-Type: text/plain; charset=ISO-8859-1 Just wanted to say that I support this work (as a co-author). I think this will make provisioning simpler and would allow an operator to create multiple trees that are maximally disjoint. In the case of fat trees, this is fairly trivial to do in a manual way (just use different "core" RBridges as roots), but in any other topology, this will help avoid overlapping links. Anoop On Fri, Nov 30, 2012 at 12:18 AM, Mingui Zhang wrote: > Hi all, > > When customers deploy TRILL in their networks, they concern much about > minimizing the disruption of their multicast service. So failure protection > mechanisms are desired. Protection solutions for IP Multicast service have > been developed and standardized. However, unlike unicast, multicast > protection solutions cannot be reused by TRILL because TRILL-multicast is > customized for TRILL. Therefore we composed the draft to provide the > multicast protection suitable for TRILL. > > As we know, TRILL can intrinsically calculate multiple distribution trees. > In the draft, this ability is leveraged to achieve multicast protection in > a way that the pay is insignificant. > > We believe this work deserves our exploration. So, we would like to know, > who have read this draft? > > The draft > TRILL Resilient Distribution Trees > http://datatracker.ietf.org/doc/draft-zhang-trill-resilient-trees/ > > Thanks, > Mingui > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill > --e89a8f2351af74e8a204cffe22ab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Just wanted to say that I support this work (as a co-author).

= I think this will make provisioning simpler and would allow an
op= erator to create multiple trees that are maximally disjoint.
In t= he case of fat trees, this is fairly trivial to do in a manual
way (just use different "core" RBridges as roots), but in an= y=A0
other topology, this will help avoid overlapping links.

Anoop

On Fri,= Nov 30, 2012 at 12:18 AM, Mingui Zhang <zhangmingui@huawei.com&g= t; wrote:
Hi all,

When customers deploy TRILL in their networks, they concern much about mini= mizing the disruption of their multicast service. So failure protection mec= hanisms are desired. Protection solutions for IP Multicast service have bee= n developed and standardized. However, unlike unicast, multicast protection= solutions cannot be reused by TRILL because TRILL-multicast is customized = for TRILL. Therefore we composed the draft to provide the multicast protect= ion suitable for TRILL.

As we know, TRILL can intrinsically calculate multiple distribution trees. = In the draft, this ability is leveraged to achieve multicast protection in = a way that the pay is insignificant.

We believe this work deserves our exploration. So, we would like to know, w= ho have read this draft?

The draft
TRILL Resilient Distribution Trees
http://datatracker.ietf.org/doc/draft-zhang-trill-res= ilient-trees/

Thanks,
Mingui
_______________________________________________
trill mailing list
trill@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/trill

--e89a8f2351af74e8a204cffe22ab-- From ayabaner@gmail.com Tue Dec 4 10:23:41 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6053021F8CA1 for ; Tue, 4 Dec 2012 10:23:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJO9So6EXX7U for ; Tue, 4 Dec 2012 10:23:39 -0800 (PST) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id 75BF821F8BFD for ; Tue, 4 Dec 2012 10:23:38 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id hj13so805928wib.13 for ; Tue, 04 Dec 2012 10:23:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=pwRSYiQJ9EQ7DAFkfSNs3dolEfNiMah0SUxwh6zpy70=; b=OtwbOZ/AYXwNvjRf+fvSM4glEQcpqOiYIuofdC/Q/tneWezhiSF03fHwwC6MeOUr7B qXuNpI2AinwQLBfqn3Z4u0z/SP+h/6mXV5y3CZeWgqsGzO/Tc0OIt5DDsVzcfSuK+9BM IQNgQV4ReBoOQ6LRwhNDcEClshoYtHrwyligV6NjEg6IsZfn9eoYHi5p2yzAQ3sH0sjH tlXKeuHBBmHDAQZSh6RlXbbEzKp/STPi+jgFODFEj39td9jWkS8nZh6ffYxQ3EZ9GyPa uEh5i6H+p4bldpkfatKsjg0MJnpozLY+xFynxuHjhi56yUVTmCrHEQaOo6NedOM7IUIW PkcA== MIME-Version: 1.0 Received: by 10.216.80.130 with SMTP id k2mr5332708wee.118.1354645413848; Tue, 04 Dec 2012 10:23:33 -0800 (PST) Received: by 10.194.14.200 with HTTP; Tue, 4 Dec 2012 10:23:33 -0800 (PST) In-Reply-To: References: <4552F0907735844E9204A62BBDD325E732132977@SZXEML507-MBS.china.huawei.com> Date: Tue, 4 Dec 2012 10:23:33 -0800 Message-ID: From: Ayan Banerjee To: "trill@ietf.org" Content-Type: multipart/alternative; boundary=0016e6deea62b0658d04d00af60c Subject: Re: [trill] TRILL Resilient Distribution Trees, who have read it? X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 18:23:41 -0000 --0016e6deea62b0658d04d00af60c Content-Type: text/plain; charset=ISO-8859-1 I would like to voice support for this work (as a co-author). It is important to have some determinism to the manner in which multi-destination trees are computed for operational purposes and this draft is a step in that direction. Thanks, Ayan On Mon, Dec 3, 2012 at 7:05 PM, Anoop Ghanwani wrote: > Just wanted to say that I support this work (as a co-author). > > I think this will make provisioning simpler and would allow an > operator to create multiple trees that are maximally disjoint. > In the case of fat trees, this is fairly trivial to do in a manual > way (just use different "core" RBridges as roots), but in any > other topology, this will help avoid overlapping links. > > Anoop > > On Fri, Nov 30, 2012 at 12:18 AM, Mingui Zhang wrote: > >> Hi all, >> >> When customers deploy TRILL in their networks, they concern much about >> minimizing the disruption of their multicast service. So failure protection >> mechanisms are desired. Protection solutions for IP Multicast service have >> been developed and standardized. However, unlike unicast, multicast >> protection solutions cannot be reused by TRILL because TRILL-multicast is >> customized for TRILL. Therefore we composed the draft to provide the >> multicast protection suitable for TRILL. >> >> As we know, TRILL can intrinsically calculate multiple distribution >> trees. In the draft, this ability is leveraged to achieve multicast >> protection in a way that the pay is insignificant. >> >> We believe this work deserves our exploration. So, we would like to know, >> who have read this draft? >> >> The draft >> TRILL Resilient Distribution Trees >> http://datatracker.ietf.org/doc/draft-zhang-trill-resilient-trees/ >> >> Thanks, >> Mingui >> _______________________________________________ >> trill mailing list >> trill@ietf.org >> https://www.ietf.org/mailman/listinfo/trill >> > > > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill > > --0016e6deea62b0658d04d00af60c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I would like to voice support for this work (as a co-author).

It is= important to have some determinism to the manner in which
multi-destina= tion trees are computed for operational purposes and
this draft is a ste= p in that direction.

Thanks,
Ayan



On Mon, Dec 3, 2012 at 7:05 PM, Anoop Ghanwani <anoop@al= umni.duke.edu> wrote:
Just wanted to say that I support this work = (as a co-author).

I think this will make provisioning simpler = and would allow an
operator to create multiple trees that are maximally disjoint.
In the case of fat trees, this is fairly trivial to do in a manual
way (just use different "core" RBridges as roots), but in an= y=A0
other topology, this will help avoid overlapping links.

Anoop

On= Fri, Nov 30, 2012 at 12:18 AM, Mingui Zhang <zhangmingui@huawei.com= > wrote:
Hi all,

When customers deploy TRILL in their networks, they concern much about mini= mizing the disruption of their multicast service. So failure protection mec= hanisms are desired. Protection solutions for IP Multicast service have bee= n developed and standardized. However, unlike unicast, multicast protection= solutions cannot be reused by TRILL because TRILL-multicast is customized = for TRILL. Therefore we composed the draft to provide the multicast protect= ion suitable for TRILL.

As we know, TRILL can intrinsically calculate multiple distribution trees. = In the draft, this ability is leveraged to achieve multicast protection in = a way that the pay is insignificant.

We believe this work deserves our exploration. So, we would like to know, w= ho have read this draft?

The draft
TRILL Resilient Distribution Trees
http://datatracker.ietf.org/doc/draft-zhang-trill-res= ilient-trees/

Thanks,
Mingui
_______________________________________________
trill mailing list
trill@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/trill


_______________________________________________
trill mailing list
trill@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/trill


--0016e6deea62b0658d04d00af60c-- From haoweiguo@huawei.com Tue Dec 4 16:39:24 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A072E21F8AA6 for ; Tue, 4 Dec 2012 16:39:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.449 X-Spam-Level: ** X-Spam-Status: No, score=2.449 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6UaTr9r96v4z for ; Tue, 4 Dec 2012 16:39:24 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A18C421F8A84 for ; Tue, 4 Dec 2012 16:39:23 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AME40035; Wed, 05 Dec 2012 00:39:22 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 5 Dec 2012 00:38:53 +0000 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 5 Dec 2012 00:39:21 +0000 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.138]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.003; Wed, 5 Dec 2012 08:39:11 +0800 From: Haoweiguo To: Mingui Zhang , "trill@ietf.org" Thread-Topic: [trill] TRILL Resilient Distribution Trees, who have read it? Thread-Index: AQHNzzVlitwMvQutCkaRTmAsoWqXQZgJYwyB Date: Wed, 5 Dec 2012 00:39:11 +0000 Message-ID: References: <4552F0907735844E9204A62BBDD325E732132977@SZXEML507-MBS.china.huawei.com> In-Reply-To: <4552F0907735844E9204A62BBDD325E732132977@SZXEML507-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.22.156] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [trill] =?gb2312?b?tPC4tDogIFRSSUxMIFJlc2lsaWVudCBEaXN0cmlidXRp?= =?gb2312?b?b24gVHJlZXMsIHdobyBoYXZlIHJlYWQgaXQ/?= X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 00:39:24 -0000 SSBoYXZlIHJlYWQgdGhlIGRyYWZ0IGFuZCB0aGluayBpdCdzIE9LIHRvIHByb3ZpZGUgbXVsdGlj YXN0IHByb3RlY3Rpb24gc29sdXRpb25zIQ0KVGhhbmtzDQp3ZWlndW8NCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8/sjLOiBNaW5ndWkgWmhhbmcgW3poYW5n bWluZ3VpQGh1YXdlaS5jb21dDQq3osvNyrG85DogMjAxMsTqMTHUwjMwyNUgMTY6MTgNCrW9OiB0 cmlsbEBpZXRmLm9yZw0K1vfM4jogW3RyaWxsXSBUUklMTCBSZXNpbGllbnQgRGlzdHJpYnV0aW9u IFRyZWVzLCB3aG8gaGF2ZSByZWFkIGl0Pw0KDQpIaSBhbGwsDQoNCldoZW4gY3VzdG9tZXJzIGRl cGxveSBUUklMTCBpbiB0aGVpciBuZXR3b3JrcywgdGhleSBjb25jZXJuIG11Y2ggYWJvdXQgbWlu aW1pemluZyB0aGUgZGlzcnVwdGlvbiBvZiB0aGVpciBtdWx0aWNhc3Qgc2VydmljZS4gU28gZmFp bHVyZSBwcm90ZWN0aW9uIG1lY2hhbmlzbXMgYXJlIGRlc2lyZWQuIFByb3RlY3Rpb24gc29sdXRp b25zIGZvciBJUCBNdWx0aWNhc3Qgc2VydmljZSBoYXZlIGJlZW4gZGV2ZWxvcGVkIGFuZCBzdGFu ZGFyZGl6ZWQuIEhvd2V2ZXIsIHVubGlrZSB1bmljYXN0LCBtdWx0aWNhc3QgcHJvdGVjdGlvbiBz b2x1dGlvbnMgY2Fubm90IGJlIHJldXNlZCBieSBUUklMTCBiZWNhdXNlIFRSSUxMLW11bHRpY2Fz dCBpcyBjdXN0b21pemVkIGZvciBUUklMTC4gVGhlcmVmb3JlIHdlIGNvbXBvc2VkIHRoZSBkcmFm dCB0byBwcm92aWRlIHRoZSBtdWx0aWNhc3QgcHJvdGVjdGlvbiBzdWl0YWJsZSBmb3IgVFJJTEwu DQoNCkFzIHdlIGtub3csIFRSSUxMIGNhbiBpbnRyaW5zaWNhbGx5IGNhbGN1bGF0ZSBtdWx0aXBs ZSBkaXN0cmlidXRpb24gdHJlZXMuIEluIHRoZSBkcmFmdCwgdGhpcyBhYmlsaXR5IGlzIGxldmVy YWdlZCB0byBhY2hpZXZlIG11bHRpY2FzdCBwcm90ZWN0aW9uIGluIGEgd2F5IHRoYXQgdGhlIHBh eSBpcyBpbnNpZ25pZmljYW50Lg0KDQpXZSBiZWxpZXZlIHRoaXMgd29yayBkZXNlcnZlcyBvdXIg ZXhwbG9yYXRpb24uIFNvLCB3ZSB3b3VsZCBsaWtlIHRvIGtub3csIHdobyBoYXZlIHJlYWQgdGhp cyBkcmFmdD8NCg0KVGhlIGRyYWZ0DQpUUklMTCBSZXNpbGllbnQgRGlzdHJpYnV0aW9uIFRyZWVz DQpodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXpoYW5nLXRyaWxsLXJlc2ls aWVudC10cmVlcy8NCg0KVGhhbmtzLA0KTWluZ3Vp From Pathangi_Janardhanan@Dell.com Tue Dec 4 20:48:27 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB16121F8BD9 for ; Tue, 4 Dec 2012 20:48:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAlBliMt8twj for ; Tue, 4 Dec 2012 20:48:27 -0800 (PST) Received: from ausc60pc101.us.dell.com (ausc60pc101.us.dell.com [143.166.85.206]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4EB21F8BC1 for ; Tue, 4 Dec 2012 20:48:26 -0800 (PST) X-Loopcount0: from 10.170.28.39 X-IronPort-AV: E=Sophos;i="4.84,219,1355119200"; d="scan'208,217";a="18116050" From: To: , Date: Wed, 5 Dec 2012 10:18:06 +0530 Thread-Topic: [trill] TRILL Resilient Distribution Trees, who have read it? Thread-Index: Ac3STISKqU6H81b7QVOXaQTTOQ8yrAAVy3mg Message-ID: References: <4552F0907735844E9204A62BBDD325E732132977@SZXEML507-MBS.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D5A6F3355F664C40AFB65BB1277D8D450185BC09C1MAAX7MCDC101A_" MIME-Version: 1.0 Subject: Re: [trill] TRILL Resilient Distribution Trees, who have read it? X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 04:48:27 -0000 --_000_D5A6F3355F664C40AFB65BB1277D8D450185BC09C1MAAX7MCDC101A_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support (As a co-author) Thanks Jana From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of A= yan Banerjee Sent: Tuesday, December 04, 2012 11:54 PM To: trill@ietf.org Subject: Re: [trill] TRILL Resilient Distribution Trees, who have read it? I would like to voice support for this work (as a co-author). It is important to have some determinism to the manner in which multi-destination trees are computed for operational purposes and this draft is a step in that direction. Thanks, Ayan On Mon, Dec 3, 2012 at 7:05 PM, Anoop Ghanwani > wrote: Just wanted to say that I support this work (as a co-author). I think this will make provisioning simpler and would allow an operator to create multiple trees that are maximally disjoint. In the case of fat trees, this is fairly trivial to do in a manual way (just use different "core" RBridges as roots), but in any other topology, this will help avoid overlapping links. Anoop On Fri, Nov 30, 2012 at 12:18 AM, Mingui Zhang > wrote: Hi all, When customers deploy TRILL in their networks, they concern much about mini= mizing the disruption of their multicast service. So failure protection mec= hanisms are desired. Protection solutions for IP Multicast service have bee= n developed and standardized. However, unlike unicast, multicast protection= solutions cannot be reused by TRILL because TRILL-multicast is customized = for TRILL. Therefore we composed the draft to provide the multicast protect= ion suitable for TRILL. As we know, TRILL can intrinsically calculate multiple distribution trees. = In the draft, this ability is leveraged to achieve multicast protection in = a way that the pay is insignificant. We believe this work deserves our exploration. So, we would like to know, w= ho have read this draft? The draft TRILL Resilient Distribution Trees http://datatracker.ietf.org/doc/draft-zhang-trill-resilient-trees/ Thanks, Mingui _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill --_000_D5A6F3355F664C40AFB65BB1277D8D450185BC09C1MAAX7MCDC101A_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support (= As a co-author)

 = ;

Thanks

<= p class=3DMsoNormal>Jana

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

 

From: trill-bounces@ietf.org [mailto:tril= l-bounces@ietf.org] On Behalf Of Ayan Banerjee
Sent: Tuesd= ay, December 04, 2012 11:54 PM
To: trill@ietf.org
Subject:<= /b> Re: [trill] TRILL Resilient Distribution Trees, who have read it?<= /o:p>

 

I would like to voice support for this w= ork (as a co-author).

It is important to have some determinism to t= he manner in which
multi-destination trees are computed for operational = purposes and
this draft is a step in that direction.

Thanks,
A= yan

=  

On Mon, Dec 3, 2012 at 7:05 = PM, Anoop Ghanwani <anoop@alumni.duke.edu> wrote:

Just wanted to say that I support this work (as a co-author).

 

I think this will make provisioning simpler and would allow an

operator to create multiple trees that= are maximally disjoint.

In t= he case of fat trees, this is fairly trivial to do in a manual

way (just use different "core" = RBridges as roots), but in any 

other topology, this will help avoid overlapping links.<= /p>

 = ;

Anoop

<= o:p> 

On Fri, Nov 30, 2012 at 12:18= AM, Mingui Zhang <zhangmingui@huawei.com> wrote:

Hi all,

When customers deploy TRILL in their networks, they con= cern much about minimizing the disruption of their multicast service. So fa= ilure protection mechanisms are desired. Protection solutions for IP Multic= ast service have been developed and standardized. However, unlike unicast, = multicast protection solutions cannot be reused by TRILL because TRILL-mult= icast is customized for TRILL. Therefore we composed the draft to provide t= he multicast protection suitable for TRILL.

As we know, TRILL can in= trinsically calculate multiple distribution trees. In the draft, this abili= ty is leveraged to achieve multicast protection in a way that the pay is in= significant.

We believe this work deserves our exploration. So, we w= ould like to know, who have read this draft?

The draft
TRILL Resi= lient Distribution Trees
http://datatracker.ietf.o= rg/doc/draft-zhang-trill-resilient-trees/

Thanks,
Mingui
_= ______________________________________________
trill mailing list
trill@ietf.org
https= ://www.ietf.org/mailman/listinfo/trill

 


________________________________________= _______
trill mailing list
trill@ie= tf.org
https://www.ietf.org/mailman/listinfo/trill

=

 

= --_000_D5A6F3355F664C40AFB65BB1277D8D450185BC09C1MAAX7MCDC101A_-- From guyingjie@huawei.com Tue Dec 4 22:31:10 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8840021F8C60 for ; Tue, 4 Dec 2012 22:31:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.55 X-Spam-Level: X-Spam-Status: No, score=-97.55 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kmjx2jis4qyP for ; Tue, 4 Dec 2012 22:31:10 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD4521F8C5E for ; Tue, 4 Dec 2012 22:31:08 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AME60070; Wed, 05 Dec 2012 06:31:06 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 5 Dec 2012 06:30:15 +0000 Received: from SZXEML426-HUB.china.huawei.com (10.72.61.34) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 5 Dec 2012 06:30:42 +0000 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.138]) by szxeml426-hub.china.huawei.com ([10.72.61.34]) with mapi id 14.01.0323.003; Wed, 5 Dec 2012 14:30:24 +0800 From: "Guyingjie (Yingjie)" To: "Pathangi_Janardhanan@Dell.com" , "ayabaner@gmail.com" , "trill@ietf.org" Thread-Topic: [trill] TRILL Resilient Distribution Trees, who have read it? Thread-Index: Ac3O0ux4S0JhVhpwS56Ahgx4dyNymwCtjLeAACASioAAFc/pAAAURs9Q Date: Wed, 5 Dec 2012 06:30:24 +0000 Message-ID: References: <4552F0907735844E9204A62BBDD325E732132977@SZXEML507-MBS.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.109.101] Content-Type: multipart/alternative; boundary="_000_A27496C192613C44A82D819E1B98DB57477F6F0CSZXEML511MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [trill] =?gb2312?b?tPC4tDogIFRSSUxMIFJlc2lsaWVudCBEaXN0cmlidXRp?= =?gb2312?b?b24gVHJlZXMsIHdobyBoYXZlIHJlYWQgaXQ/?= X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 06:31:10 -0000 --_000_A27496C192613C44A82D819E1B98DB57477F6F0CSZXEML511MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SSByZWFkIGl0IGFuZCBTdXBwb3J0IGl0Lg0KDQoNCk9uIEZyaSwgTm92IDMwLCAyMDEyIGF0IDEy OjE4IEFNLCBNaW5ndWkgWmhhbmcgPHpoYW5nbWluZ3VpQGh1YXdlaS5jb208bWFpbHRvOnpoYW5n bWluZ3VpQGh1YXdlaS5jb20+PiB3cm90ZToNCkhpIGFsbCwNCg0KV2hlbiBjdXN0b21lcnMgZGVw bG95IFRSSUxMIGluIHRoZWlyIG5ldHdvcmtzLCB0aGV5IGNvbmNlcm4gbXVjaCBhYm91dCBtaW5p bWl6aW5nIHRoZSBkaXNydXB0aW9uIG9mIHRoZWlyIG11bHRpY2FzdCBzZXJ2aWNlLiBTbyBmYWls dXJlIHByb3RlY3Rpb24gbWVjaGFuaXNtcyBhcmUgZGVzaXJlZC4gUHJvdGVjdGlvbiBzb2x1dGlv bnMgZm9yIElQIE11bHRpY2FzdCBzZXJ2aWNlIGhhdmUgYmVlbiBkZXZlbG9wZWQgYW5kIHN0YW5k YXJkaXplZC4gSG93ZXZlciwgdW5saWtlIHVuaWNhc3QsIG11bHRpY2FzdCBwcm90ZWN0aW9uIHNv bHV0aW9ucyBjYW5ub3QgYmUgcmV1c2VkIGJ5IFRSSUxMIGJlY2F1c2UgVFJJTEwtbXVsdGljYXN0 IGlzIGN1c3RvbWl6ZWQgZm9yIFRSSUxMLiBUaGVyZWZvcmUgd2UgY29tcG9zZWQgdGhlIGRyYWZ0 IHRvIHByb3ZpZGUgdGhlIG11bHRpY2FzdCBwcm90ZWN0aW9uIHN1aXRhYmxlIGZvciBUUklMTC4N Cg0KQXMgd2Uga25vdywgVFJJTEwgY2FuIGludHJpbnNpY2FsbHkgY2FsY3VsYXRlIG11bHRpcGxl IGRpc3RyaWJ1dGlvbiB0cmVlcy4gSW4gdGhlIGRyYWZ0LCB0aGlzIGFiaWxpdHkgaXMgbGV2ZXJh Z2VkIHRvIGFjaGlldmUgbXVsdGljYXN0IHByb3RlY3Rpb24gaW4gYSB3YXkgdGhhdCB0aGUgcGF5 IGlzIGluc2lnbmlmaWNhbnQuDQoNCldlIGJlbGlldmUgdGhpcyB3b3JrIGRlc2VydmVzIG91ciBl eHBsb3JhdGlvbi4gU28sIHdlIHdvdWxkIGxpa2UgdG8ga25vdywgd2hvIGhhdmUgcmVhZCB0aGlz IGRyYWZ0Pw0KDQpUaGUgZHJhZnQNClRSSUxMIFJlc2lsaWVudCBEaXN0cmlidXRpb24gVHJlZXMN Cmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemhhbmctdHJpbGwtcmVzaWxp ZW50LXRyZWVzLw0KDQpUaGFua3MsDQpNaW5ndWkNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQp0cmlsbCBtYWlsaW5nIGxpc3QNCnRyaWxsQGlldGYub3Jn PG1haWx0bzp0cmlsbEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdHJpbGwNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KdHJpbGwgbWFpbGluZyBsaXN0DQp0cmlsbEBpZXRmLm9yZzxtYWlsdG86dHJpbGxA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsDQoN Cg== --_000_A27496C192613C44A82D819E1B98DB57477F6F0CSZXEML511MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

I read it = and Support it.

 = ;

 

On Fri, Nov 30, 2012 at 12:18 A= M, Mingui Zhang <zhangmingui@huawei.com> wrote:

Hi all,

When customers deploy TRILL in their networks, they concern much about mini= mizing the disruption of their multicast service. So failure protection mec= hanisms are desired. Protection solutions for IP Multicast service have bee= n developed and standardized. However, unlike unicast, multicast protection solutions cannot be reused by TRILL b= ecause TRILL-multicast is customized for TRILL. Therefore we composed the d= raft to provide the multicast protection suitable for TRILL.

As we know, TRILL can intrinsically calculate multiple distribution trees. = In the draft, this ability is leveraged to achieve multicast protection in = a way that the pay is insignificant.

We believe this work deserves our exploration. So, we would like to know, w= ho have read this draft?

The draft
TRILL Resilient Distribution Trees
http://datatracker.ietf.org/doc/draft-zhang-trill-res= ilient-trees/

Thanks,
Mingui
_______________________________________________
trill mailing list
trill@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/trill

 

=
_______________________________________________
trill mailing list
trill@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/trill

 

--_000_A27496C192613C44A82D819E1B98DB57477F6F0CSZXEML511MBSchi_-- From linda.dunbar@huawei.com Wed Dec 5 08:31:51 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B92121F8CE5 for ; Wed, 5 Dec 2012 08:31:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.453 X-Spam-Level: X-Spam-Status: No, score=-6.453 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eV5Tsv77UODP for ; Wed, 5 Dec 2012 08:31:50 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 82FFF21F8CE3 for ; Wed, 5 Dec 2012 08:31:49 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMF09937; Wed, 05 Dec 2012 16:31:46 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 5 Dec 2012 16:31:12 +0000 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 6 Dec 2012 00:31:43 +0800 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.003; Wed, 5 Dec 2012 08:31:37 -0800 From: Linda Dunbar To: "Pathangi_Janardhanan@Dell.com" , "ayabaner@gmail.com" , "trill@ietf.org" Thread-Topic: [trill] TRILL Resilient Distribution Trees, who have read it? Thread-Index: Ac3STISKqU6H81b7QVOXaQTTOQ8yrAAVy3mgABiQ+OA= Date: Wed, 5 Dec 2012 16:31:36 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F6450D5272@dfweml505-mbx> References: <4552F0907735844E9204A62BBDD325E732132977@SZXEML507-MBS.china.huawei.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.170] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F6450D5272dfweml505mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [trill] TRILL Resilient Distribution Trees, who have read it? X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 16:31:51 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F6450D5272dfweml505mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support, Linda Dunbar From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of A= yan Banerjee Sent: Tuesday, December 04, 2012 11:54 PM To: trill@ietf.org Subject: Re: [trill] TRILL Resilient Distribution Trees, who have read it? I would like to voice support for this work (as a co-author). It is important to have some determinism to the manner in which multi-destination trees are computed for operational purposes and this draft is a step in that direction. Thanks, Ayan On Mon, Dec 3, 2012 at 7:05 PM, Anoop Ghanwani > wrote: Just wanted to say that I support this work (as a co-author). I think this will make provisioning simpler and would allow an operator to create multiple trees that are maximally disjoint. In the case of fat trees, this is fairly trivial to do in a manual way (just use different "core" RBridges as roots), but in any other topology, this will help avoid overlapping links. Anoop On Fri, Nov 30, 2012 at 12:18 AM, Mingui Zhang > wrote: Hi all, When customers deploy TRILL in their networks, they concern much about mini= mizing the disruption of their multicast service. So failure protection mec= hanisms are desired. Protection solutions for IP Multicast service have bee= n developed and standardized. However, unlike unicast, multicast protection= solutions cannot be reused by TRILL because TRILL-multicast is customized = for TRILL. Therefore we composed the draft to provide the multicast protect= ion suitable for TRILL. As we know, TRILL can intrinsically calculate multiple distribution trees. = In the draft, this ability is leveraged to achieve multicast protection in = a way that the pay is insignificant. We believe this work deserves our exploration. So, we would like to know, w= ho have read this draft? The draft TRILL Resilient Distribution Trees http://datatracker.ietf.org/doc/draft-zhang-trill-resilient-trees/ Thanks, Mingui _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill --_000_4A95BA014132FF49AE685FAB4B9F17F6450D5272dfweml505mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support,

 <= /p>

Linda Dunbar

 <= /p>

 <= /p>

From: trill-bo= unces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of Ayan Banerjee
Sent: Tuesday, December 04, 2012 11:54 PM
To: trill@ietf.org
Subject: Re: [trill] TRILL Resilient Distribution Trees, who have re= ad it?

 

I would like to voice= support for this work (as a co-author).

It is important to have some determinism to the manner in which
multi-destination trees are computed for operational purposes and
this draft is a step in that direction.

Thanks,
Ayan

 

On Mon, Dec 3, 2012 at 7:05 PM, Anoop Ghanwani <<= a href=3D"mailto:anoop@alumni.duke.edu" target=3D"_blank">anoop@alumni.duke= .edu> wrote:

Just wanted to say that I support this work (as a co= -author).

 

I think this will make provisioning simpler and woul= d allow an

operator to create multiple trees that are maximally= disjoint.

In the case of fat trees, this is fairly trivial to = do in a manual

way (just use different "core" RBridges as= roots), but in any 

other topology, this will help avoid overlapping lin= ks.

 

Anoop

 

On Fri, Nov 30, 2012 at 12:18 AM, Mingui Zhang <<= a href=3D"mailto:zhangmingui@huawei.com" target=3D"_blank">zhangmingui@huaw= ei.com> wrote:

Hi all,

When customers deploy TRILL in their networks, they concern much about mini= mizing the disruption of their multicast service. So failure protection mec= hanisms are desired. Protection solutions for IP Multicast service have bee= n developed and standardized. However, unlike unicast, multicast protection solutions cannot be reused by TRILL b= ecause TRILL-multicast is customized for TRILL. Therefore we composed the d= raft to provide the multicast protection suitable for TRILL.

As we know, TRILL can intrinsically calculate multiple distribution trees. = In the draft, this ability is leveraged to achieve multicast protection in = a way that the pay is insignificant.

We believe this work deserves our exploration. So, we would like to know, w= ho have read this draft?

The draft
TRILL Resilient Distribution Trees
http://datatracker.ietf.org/doc/draft-zhang-trill-res= ilient-trees/

Thanks,
Mingui
_______________________________________________
trill mailing list
trill@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/trill

 


_______________________________________________
trill mailing list
trill@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/trill

 

--_000_4A95BA014132FF49AE685FAB4B9F17F6450D5272dfweml505mbx_-- From aldrin.ietf@gmail.com Wed Dec 5 10:02:49 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37C7121F8B9A for ; Wed, 5 Dec 2012 10:02:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z62c0EbPHh5M for ; Wed, 5 Dec 2012 10:02:48 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id DD42021F8716 for ; Wed, 5 Dec 2012 10:02:47 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id hz11so3618152pad.31 for ; Wed, 05 Dec 2012 10:02:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=nuCbDEqgfP18S97K61f7xKyC+5YvvAhrUvRVHnHEJmM=; b=BtW00pIR6EvWpRRd+VdYwENcZ1sYs6mCBOCD706Xikff/WIFq4ATJDyqRs5E3bJ6Bf 8zmGtB/LtWEe4NYXxO3tmbendKTGEgrEnovNc5zNL3jRx0wDG68ML4WzLCJBB7e234VK frbblqfRIyRXBl06x01q77GaPluBkjQeJp7TvI/f6ZL9faqWMuXsuFgf6SriHahxQSVV jgqdd8riUK39Pr7wJHYco558M6Bl7TimvVPgjP57ZonweqgFaCkGdeelmQwkhwizvlDD Nt2k0RH6RQKx8tmDK6s0zRywvK97/sfvs/Loi/IGpAKEEeLYMGux7m7jpT9phmTm8Qt3 uPug== Received: by 10.66.88.102 with SMTP id bf6mr46841957pab.10.1354730567042; Wed, 05 Dec 2012 10:02:47 -0800 (PST) Received: from [192.168.1.3] (c-98-248-237-85.hsd1.ca.comcast.net. [98.248.237.85]) by mx.google.com with ESMTPS id sy1sm3238329pbc.66.2012.12.05.10.02.44 (version=SSLv3 cipher=OTHER); Wed, 05 Dec 2012 10:02:45 -0800 (PST) References: <4552F0907735844E9204A62BBDD325E732132977@SZXEML507-MBS.china.huawei.com> Mime-Version: 1.0 (1.0) In-Reply-To: <4552F0907735844E9204A62BBDD325E732132977@SZXEML507-MBS.china.huawei.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (10A523) From: Sam Aldrin Date: Wed, 5 Dec 2012 10:02:44 -0800 To: Mingui Zhang Cc: "trill@ietf.org" Subject: Re: [trill] TRILL Resilient Distribution Trees, who have read it? X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 18:02:49 -0000 I haven't paid too much attention into the details of the draft. Hence i wil= l defer questions related to draft, for later time. But I do have few questi= ons related to procedure. 1. I do not see this work item chartered for TRILL WG. Until it is done, it i= s not prudent for WG to focus on non-chartered items, atleast till the updat= ed charter is in place. 2. Is this email a WG adoption call? Not being aware IETF procedures, can in= dividuals call for WG adoption or is it done by chairs? If it is only by WG c= hairs, what is the purpose of this email. Cheers Sam Sent from my iPad On Nov 30, 2012, at 12:18 AM, Mingui Zhang wrote: > Hi all, >=20 > When customers deploy TRILL in their networks, they concern much about min= imizing the disruption of their multicast service. So failure protection mec= hanisms are desired. Protection solutions for IP Multicast service have been= developed and standardized. However, unlike unicast, multicast protection s= olutions cannot be reused by TRILL because TRILL-multicast is customized for= TRILL. Therefore we composed the draft to provide the multicast protection s= uitable for TRILL. >=20 > As we know, TRILL can intrinsically calculate multiple distribution trees.= In the draft, this ability is leveraged to achieve multicast protection in a= way that the pay is insignificant. >=20 > We believe this work deserves our exploration. So, we would like to know, w= ho have read this draft?=20 >=20 > The draft > TRILL Resilient Distribution Trees > http://datatracker.ietf.org/doc/draft-zhang-trill-resilient-trees/ >=20 > Thanks, > Mingui > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill From zhai.hongjun@zte.com.cn Wed Dec 5 16:58:29 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3C8021F8C07; Wed, 5 Dec 2012 16:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.999 X-Spam-Level: X-Spam-Status: No, score=-96.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100, WEIRD_QUOTING=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35sjbCAe0jqi; Wed, 5 Dec 2012 16:58:28 -0800 (PST) Received: from zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 43D0F21F8BCB; Wed, 5 Dec 2012 16:58:28 -0800 (PST) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 7CCFD19247D3; Thu, 6 Dec 2012 08:58:18 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id EAB667256AE; Thu, 6 Dec 2012 08:47:11 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id qB60vwMP076899; Thu, 6 Dec 2012 08:57:58 +0800 (GMT-8) (envelope-from zhai.hongjun@zte.com.cn) In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F6450D5272@dfweml505-mbx> To: Linda Dunbar MIME-Version: 1.0 X-KeepSent: CE3597B4:76C69243-48257ACC:00052C3F; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhai.hongjun@zte.com.cn Date: Thu, 6 Dec 2012 08:58:00 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-12-06 08:57:59, Serialize complete at 2012-12-06 08:57:59 Content-Type: multipart/alternative; boundary="=_alternative 0005872C48257ACC_=" X-MAIL: mse01.zte.com.cn qB60vwMP076899 Cc: "Pathangi_Janardhanan@Dell.com" , trill-bounces@ietf.org, "ayabaner@gmail.com" , "trill@ietf.org" Subject: Re: [trill] TRILL Resilient Distribution Trees, who have read it? X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 00:58:30 -0000 This is a multipart message in MIME format. --=_alternative 0005872C48257ACC_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SSBoYXZlIHJlYWQgdGhlIGRyYWZ0IGFuZCBzdXBwb3J0IGl0Lg0KDQoNCg0KQmVzdCBSZWdhcmRz LA0KWmhhaSBIb25nanVuDQoiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIi IiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiDQogUHJvdG9jb2wgRGV2ZWxvcG1lbnQgRGVw dC5WSSwgQ2VudHJhbCBSJkQgSW5zdGl0dXRlLCBaVEUgQ29ycG9yYXRpb24NCiBOby4gNjgsIFpp amluZ2h1YSBSb2FkLCBZdWh1YXRhaSBEaXN0cmljdCwgTmFuamluZywgUC5SLkNoaW5hLCAyMTAw MTINCiANCiBaaGFpIEhvbmdqdW4NCiANCiBUZWw6ICs4Ni0yNS01Mjg3NzM0NQ0KIEVtYWlsOiB6 aGFpLmhvbmdqdW5AenRlLmNvbS5jbg0KIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIi IiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiINCg0KDQoNCg0KDQpMaW5kYSBE dW5iYXIgPGxpbmRhLmR1bmJhckBodWF3ZWkuY29tPiANCreivP7IyzogIHRyaWxsLWJvdW5jZXNA aWV0Zi5vcmcNCjIwMTItMTItMDYgMDA6MzENCg0KytW8/sjLDQoiUGF0aGFuZ2lfSmFuYXJkaGFu YW5ARGVsbC5jb20iIDxQYXRoYW5naV9KYW5hcmRoYW5hbkBEZWxsLmNvbT4sIA0KImF5YWJhbmVy QGdtYWlsLmNvbSIgPGF5YWJhbmVyQGdtYWlsLmNvbT4sICJ0cmlsbEBpZXRmLm9yZyIgDQo8dHJp bGxAaWV0Zi5vcmc+DQqzrcvNDQoNCtb3zOINClJlOiBbdHJpbGxdIFRSSUxMIFJlc2lsaWVudCBE aXN0cmlidXRpb24gVHJlZXMsIHdobyBoYXZlIHJlYWQgaXQ/DQoNCg0KDQoNCg0KDQpTdXBwb3J0 LCANCiANCkxpbmRhIER1bmJhcg0KIA0KIA0KRnJvbTogdHJpbGwtYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOnRyaWxsLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiANCkF5YW4gQmFuZXJq ZWUNClNlbnQ6IFR1ZXNkYXksIERlY2VtYmVyIDA0LCAyMDEyIDExOjU0IFBNDQpUbzogdHJpbGxA aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdHJpbGxdIFRSSUxMIFJlc2lsaWVudCBEaXN0cmlidXRp b24gVHJlZXMsIHdobyBoYXZlIHJlYWQgaXQ/DQogDQpJIHdvdWxkIGxpa2UgdG8gdm9pY2Ugc3Vw cG9ydCBmb3IgdGhpcyB3b3JrIChhcyBhIGNvLWF1dGhvcikuIA0KDQpJdCBpcyBpbXBvcnRhbnQg dG8gaGF2ZSBzb21lIGRldGVybWluaXNtIHRvIHRoZSBtYW5uZXIgaW4gd2hpY2gNCm11bHRpLWRl c3RpbmF0aW9uIHRyZWVzIGFyZSBjb21wdXRlZCBmb3Igb3BlcmF0aW9uYWwgcHVycG9zZXMgYW5k DQp0aGlzIGRyYWZ0IGlzIGEgc3RlcCBpbiB0aGF0IGRpcmVjdGlvbi4NCg0KVGhhbmtzLA0KQXlh bg0KIA0KT24gTW9uLCBEZWMgMywgMjAxMiBhdCA3OjA1IFBNLCBBbm9vcCBHaGFud2FuaSA8YW5v b3BAYWx1bW5pLmR1a2UuZWR1PiANCndyb3RlOg0KSnVzdCB3YW50ZWQgdG8gc2F5IHRoYXQgSSBz dXBwb3J0IHRoaXMgd29yayAoYXMgYSBjby1hdXRob3IpLg0KIA0KSSB0aGluayB0aGlzIHdpbGwg bWFrZSBwcm92aXNpb25pbmcgc2ltcGxlciBhbmQgd291bGQgYWxsb3cgYW4NCm9wZXJhdG9yIHRv IGNyZWF0ZSBtdWx0aXBsZSB0cmVlcyB0aGF0IGFyZSBtYXhpbWFsbHkgZGlzam9pbnQuDQpJbiB0 aGUgY2FzZSBvZiBmYXQgdHJlZXMsIHRoaXMgaXMgZmFpcmx5IHRyaXZpYWwgdG8gZG8gaW4gYSBt YW51YWwNCndheSAoanVzdCB1c2UgZGlmZmVyZW50ICJjb3JlIiBSQnJpZGdlcyBhcyByb290cyks IGJ1dCBpbiBhbnkgDQpvdGhlciB0b3BvbG9neSwgdGhpcyB3aWxsIGhlbHAgYXZvaWQgb3Zlcmxh cHBpbmcgbGlua3MuDQogDQpBbm9vcA0KIA0KT24gRnJpLCBOb3YgMzAsIDIwMTIgYXQgMTI6MTgg QU0sIE1pbmd1aSBaaGFuZyA8emhhbmdtaW5ndWlAaHVhd2VpLmNvbT4gDQp3cm90ZToNCkhpIGFs bCwNCg0KV2hlbiBjdXN0b21lcnMgZGVwbG95IFRSSUxMIGluIHRoZWlyIG5ldHdvcmtzLCB0aGV5 IGNvbmNlcm4gbXVjaCBhYm91dCANCm1pbmltaXppbmcgdGhlIGRpc3J1cHRpb24gb2YgdGhlaXIg bXVsdGljYXN0IHNlcnZpY2UuIFNvIGZhaWx1cmUgDQpwcm90ZWN0aW9uIG1lY2hhbmlzbXMgYXJl IGRlc2lyZWQuIFByb3RlY3Rpb24gc29sdXRpb25zIGZvciBJUCBNdWx0aWNhc3QgDQpzZXJ2aWNl IGhhdmUgYmVlbiBkZXZlbG9wZWQgYW5kIHN0YW5kYXJkaXplZC4gSG93ZXZlciwgdW5saWtlIHVu aWNhc3QsIA0KbXVsdGljYXN0IHByb3RlY3Rpb24gc29sdXRpb25zIGNhbm5vdCBiZSByZXVzZWQg YnkgVFJJTEwgYmVjYXVzZSANClRSSUxMLW11bHRpY2FzdCBpcyBjdXN0b21pemVkIGZvciBUUklM TC4gVGhlcmVmb3JlIHdlIGNvbXBvc2VkIHRoZSBkcmFmdCANCnRvIHByb3ZpZGUgdGhlIG11bHRp Y2FzdCBwcm90ZWN0aW9uIHN1aXRhYmxlIGZvciBUUklMTC4NCg0KQXMgd2Uga25vdywgVFJJTEwg Y2FuIGludHJpbnNpY2FsbHkgY2FsY3VsYXRlIG11bHRpcGxlIGRpc3RyaWJ1dGlvbiB0cmVlcy4g DQpJbiB0aGUgZHJhZnQsIHRoaXMgYWJpbGl0eSBpcyBsZXZlcmFnZWQgdG8gYWNoaWV2ZSBtdWx0 aWNhc3QgcHJvdGVjdGlvbiBpbiANCmEgd2F5IHRoYXQgdGhlIHBheSBpcyBpbnNpZ25pZmljYW50 Lg0KDQpXZSBiZWxpZXZlIHRoaXMgd29yayBkZXNlcnZlcyBvdXIgZXhwbG9yYXRpb24uIFNvLCB3 ZSB3b3VsZCBsaWtlIHRvIGtub3csIA0Kd2hvIGhhdmUgcmVhZCB0aGlzIGRyYWZ0Pw0KDQpUaGUg ZHJhZnQNClRSSUxMIFJlc2lsaWVudCBEaXN0cmlidXRpb24gVHJlZXMNCmh0dHA6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemhhbmctdHJpbGwtcmVzaWxpZW50LXRyZWVzLw0KDQpU aGFua3MsDQpNaW5ndWkNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQp0cmlsbCBtYWlsaW5nIGxpc3QNCnRyaWxsQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsDQogDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQp0cmlsbCBtYWlsaW5nIGxpc3QNCnRyaWxsQGll dGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsDQogX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnRyaWxsIG1haWxp bmcgbGlzdA0KdHJpbGxAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdHJpbGwNCg0KDQo= --=_alternative 0005872C48257ACC_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgaGF2ZSByZWFkIHRoZSBkcmFm dCBhbmQgc3VwcG9ydCBpdC48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPjxicj4NCjxicj4NCjxicj4NCkJlc3QgUmVnYXJkcyw8YnI+DQpaaGFpIEhvbmdqdW48YnI+ DQomcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDs8YnI+DQogUHJvdG9jb2wgRGV2ZWxvcG1lbnQgRGVwdC5W SSwgQ2VudHJhbCBSJmFtcDtEIEluc3RpdHV0ZSwgWlRFIENvcnBvcmF0aW9uPGJyPg0KIE5vLiA2 OCwgWmlqaW5naHVhIFJvYWQsIFl1aHVhdGFpIERpc3RyaWN0LCBOYW5qaW5nLCBQLlIuQ2hpbmEs IDIxMDAxMjxicj4NCiA8YnI+DQogWmhhaSBIb25nanVuPGJyPg0KIDxicj4NCiBUZWw6ICs4Ni0y NS01Mjg3NzM0NTxicj4NCiBFbWFpbDogemhhaS5ob25nanVuQHp0ZS5jb20uY248YnI+DQomcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDs8YnI+DQo8YnI+DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8 YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM2JT48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+TGluZGEgRHVuYmFyICZsdDtsaW5kYS5k dW5iYXJAaHVhd2VpLmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7dHJpbGwtYm91bmNlc0BpZXRmLm9yZzwvZm9udD4N CjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEyLTEyLTA2IDAwOjMxPC9mb250 Pg0KPHRkIHdpZHRoPTYzJT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8 dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+ yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90 O1BhdGhhbmdpX0phbmFyZGhhbmFuQERlbGwuY29tJnF1b3Q7DQombHQ7UGF0aGFuZ2lfSmFuYXJk aGFuYW5ARGVsbC5jb20mZ3Q7LCAmcXVvdDtheWFiYW5lckBnbWFpbC5jb20mcXVvdDsgJmx0O2F5 YWJhbmVyQGdtYWlsLmNvbSZndDssDQomcXVvdDt0cmlsbEBpZXRmLm9yZyZxdW90OyAmbHQ7dHJp bGxAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWdu PXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0K PHRkPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj5SZTogW3RyaWxsXSBUUklMTCBSZXNpbGllbnQgRGlzdHJpYnV0aW9u DQpUcmVlcywgd2hvIGhhdmUgcmVhZCBpdD88L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5TdXBw b3J0LCA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJy aSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNh bGlicmkiPkxpbmRhIER1bmJhcjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3 ZCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMx ZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJUYWhvbWEiPjxiPkZyb206PC9iPiB0cmlsbC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86dHJp bGwtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QXlhbiBCYW5lcmplZTxi Pjxicj4NClNlbnQ6PC9iPiBUdWVzZGF5LCBEZWNlbWJlciAwNCwgMjAxMiAxMTo1NCBQTTxiPjxi cj4NClRvOjwvYj4gdHJpbGxAaWV0Zi5vcmc8Yj48YnI+DQpTdWJqZWN0OjwvYj4gUmU6IFt0cmls bF0gVFJJTEwgUmVzaWxpZW50IERpc3RyaWJ1dGlvbiBUcmVlcywgd2hvIGhhdmUgcmVhZA0KaXQ/ PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwv Zm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5JIHdvdWxkIGxp a2UgdG8gdm9pY2Ugc3VwcG9ydCBmb3INCnRoaXMgd29yayAoYXMgYSBjby1hdXRob3IpLiA8YnI+ DQo8YnI+DQpJdCBpcyBpbXBvcnRhbnQgdG8gaGF2ZSBzb21lIGRldGVybWluaXNtIHRvIHRoZSBt YW5uZXIgaW4gd2hpY2g8YnI+DQptdWx0aS1kZXN0aW5hdGlvbiB0cmVlcyBhcmUgY29tcHV0ZWQg Zm9yIG9wZXJhdGlvbmFsIHB1cnBvc2VzIGFuZDxicj4NCnRoaXMgZHJhZnQgaXMgYSBzdGVwIGlu IHRoYXQgZGlyZWN0aW9uLjxicj4NCjxicj4NClRoYW5rcyw8YnI+DQpBeWFuPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD4NCjxicj48 Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5PbiBNb24sIERlYyAzLCAyMDEyIGF0 IDc6MDUgUE0sDQpBbm9vcCBHaGFud2FuaSAmbHQ7PC9mb250PjxhIGhyZWY9bWFpbHRvOmFub29w QGFsdW1uaS5kdWtlLmVkdSB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PHU+YW5vb3BAYWx1bW5pLmR1a2UuZWR1PC91PjwvZm9udD48 L2E+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jmd0Ow0Kd3JvdGU6PC9mb250 Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPkp1c3Qgd2FudGVkIHRv IHNheSB0aGF0IEkgc3VwcG9ydA0KdGhpcyB3b3JrIChhcyBhIGNvLWF1dGhvcikuPC9mb250Pg0K PGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD4NCjxi cj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5JIHRoaW5rIHRoaXMgd2lsbCBt YWtlIHByb3Zpc2lvbmluZw0Kc2ltcGxlciBhbmQgd291bGQgYWxsb3cgYW48L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+b3BlcmF0b3IgdG8gY3JlYXRlIG11 bHRpcGxlIHRyZWVzDQp0aGF0IGFyZSBtYXhpbWFsbHkgZGlzam9pbnQuPC9mb250Pg0KPGJyPjxm b250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPkluIHRoZSBjYXNlIG9mIGZhdCB0cmVl cywgdGhpcw0KaXMgZmFpcmx5IHRyaXZpYWwgdG8gZG8gaW4gYSBtYW51YWw8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+d2F5IChqdXN0IHVzZSBkaWZmZXJl bnQgJnF1b3Q7Y29yZSZxdW90Ow0KUkJyaWRnZXMgYXMgcm9vdHMpLCBidXQgaW4gYW55IDwvZm9u dD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5vdGhlciB0b3BvbG9n eSwgdGhpcyB3aWxsIGhlbHANCmF2b2lkIG92ZXJsYXBwaW5nIGxpbmtzLjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTMgY29sb3I9Izg4ODg4OCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwv Zm9udD4NCjxicj48Zm9udCBzaXplPTMgY29sb3I9Izg4ODg4OCBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPkFub29wPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5P biBGcmksIE5vdiAzMCwgMjAxMiBhdCAxMjoxOCBBTSwNCk1pbmd1aSBaaGFuZyAmbHQ7PC9mb250 PjxhIGhyZWY9bWFpbHRvOnpoYW5nbWluZ3VpQGh1YXdlaS5jb20gdGFyZ2V0PV9ibGFuaz48Zm9u dCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjx1PnpoYW5nbWluZ3Vp QGh1YXdlaS5jb208L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj4mZ3Q7DQp3cm90ZTo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+SGkgYWxsLDxicj4NCjxicj4NCldoZW4gY3VzdG9tZXJzIGRlcGxveSBUUklMTCBp biB0aGVpciBuZXR3b3JrcywgdGhleSBjb25jZXJuIG11Y2ggYWJvdXQNCm1pbmltaXppbmcgdGhl IGRpc3J1cHRpb24gb2YgdGhlaXIgbXVsdGljYXN0IHNlcnZpY2UuIFNvIGZhaWx1cmUgcHJvdGVj dGlvbg0KbWVjaGFuaXNtcyBhcmUgZGVzaXJlZC4gUHJvdGVjdGlvbiBzb2x1dGlvbnMgZm9yIElQ IE11bHRpY2FzdCBzZXJ2aWNlIGhhdmUNCmJlZW4gZGV2ZWxvcGVkIGFuZCBzdGFuZGFyZGl6ZWQu IEhvd2V2ZXIsIHVubGlrZSB1bmljYXN0LCBtdWx0aWNhc3QgcHJvdGVjdGlvbg0Kc29sdXRpb25z IGNhbm5vdCBiZSByZXVzZWQgYnkgVFJJTEwgYmVjYXVzZSBUUklMTC1tdWx0aWNhc3QgaXMgY3Vz dG9taXplZA0KZm9yIFRSSUxMLiBUaGVyZWZvcmUgd2UgY29tcG9zZWQgdGhlIGRyYWZ0IHRvIHBy b3ZpZGUgdGhlIG11bHRpY2FzdCBwcm90ZWN0aW9uDQpzdWl0YWJsZSBmb3IgVFJJTEwuPGJyPg0K PGJyPg0KQXMgd2Uga25vdywgVFJJTEwgY2FuIGludHJpbnNpY2FsbHkgY2FsY3VsYXRlIG11bHRp cGxlIGRpc3RyaWJ1dGlvbiB0cmVlcy4NCkluIHRoZSBkcmFmdCwgdGhpcyBhYmlsaXR5IGlzIGxl dmVyYWdlZCB0byBhY2hpZXZlIG11bHRpY2FzdCBwcm90ZWN0aW9uDQppbiBhIHdheSB0aGF0IHRo ZSBwYXkgaXMgaW5zaWduaWZpY2FudC48YnI+DQo8YnI+DQpXZSBiZWxpZXZlIHRoaXMgd29yayBk ZXNlcnZlcyBvdXIgZXhwbG9yYXRpb24uIFNvLCB3ZSB3b3VsZCBsaWtlIHRvIGtub3csDQp3aG8g aGF2ZSByZWFkIHRoaXMgZHJhZnQ/PGJyPg0KPGJyPg0KVGhlIGRyYWZ0PGJyPg0KVFJJTEwgUmVz aWxpZW50IERpc3RyaWJ1dGlvbiBUcmVlczwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPjx1Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj0iaHR0cDov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16aGFuZy10cmlsbC1yZXNpbGllbnQtdHJl ZXMvIiB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+PHU+aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16aGFuZy10 cmlsbC1yZXNpbGllbnQtdHJlZXMvPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9IlRp bWVzIE5ldyBSb21hbiI+PGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NCk1pbmd1aTxicj4NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KdHJpbGwgbWFp bGluZyBsaXN0PC9mb250Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+PHU+PGJyPg0KPC91PjwvZm9udD48YSBocmVmPW1haWx0bzp0cmlsbEBpZXRmLm9yZyB0 YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+PHU+dHJpbGxAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgY29sb3I9Ymx1 ZSBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjx1Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj1odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsIHRhcmdldD1fYmxhbms+PGZv bnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48dT5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsPC91PjwvZm9udD48L2E+DQo8YnI+PGZv bnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250 IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxicj4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KdHJpbGwgbWFpbGluZyBsaXN0PC9mb250 Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHU+PGJyPg0K PC91PjwvZm9udD48YSBocmVmPW1haWx0bzp0cmlsbEBpZXRmLm9yZz48Zm9udCBzaXplPTMgY29s b3I9Ymx1ZSBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjx1PnRyaWxsQGlldGYub3JnPC91PjwvZm9u dD48L2E+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48dT48 YnI+DQo8L3U+PC9mb250PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby90cmlsbCB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9IlRp bWVzIE5ldyBSb21hbiI+PHU+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90 cmlsbDwvdT48L2ZvbnQ+PC9hPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPiZuYnNwOzwvZm9udD48dHQ+PGZvbnQgc2l6ZT0yPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KdHJpbGwgbWFpbGluZyBsaXN0PGJyPg0KdHJp bGxAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Ry aWxsPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+DQo= --=_alternative 0005872C48257ACC_=-- From zhangmingui@huawei.com Wed Dec 5 18:52:01 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71FC221F8B2A for ; Wed, 5 Dec 2012 18:52:01 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YpR3-H28Cyc3 for ; Wed, 5 Dec 2012 18:52:00 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2EF21F89FF for ; Wed, 5 Dec 2012 18:52:00 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANN42695; Thu, 06 Dec 2012 02:51:59 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 6 Dec 2012 02:51:26 +0000 Received: from SZXEML430-HUB.china.huawei.com (10.72.61.38) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 6 Dec 2012 10:51:58 +0800 Received: from SZXEML507-MBS.china.huawei.com ([169.254.7.234]) by szxeml430-hub.china.huawei.com ([10.72.61.38]) with mapi id 14.01.0323.003; Thu, 6 Dec 2012 10:51:51 +0800 From: Mingui Zhang To: Sam Aldrin Thread-Topic: [trill] TRILL Resilient Distribution Trees, who have read it? Thread-Index: Ac3O0ux4S0JhVhpwS56Ahgx4dyNymwD/L74AACMf82Q= Date: Thu, 6 Dec 2012 02:51:51 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E7321371A1@SZXEML507-MBS.china.huawei.com> References: <4552F0907735844E9204A62BBDD325E732132977@SZXEML507-MBS.china.huawei.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.47.97.230] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "trill@ietf.org" Subject: Re: [trill] TRILL Resilient Distribution Trees, who have read it? X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 02:52:01 -0000 Hi Sam, As you can see from the words of the email, it is not a WG adoption polling= . I am cautious about this. According to the decision that the WG had made at the Atlanta meeting, auth= ors were asked to make sure in the TRILL mailing-list whether there is enou= gh number of guys who have read this draft. So, this email actually intends= to help chairs to decide whether this draft deserves a call. I wish I have= clarified your confusion. Actually, this draft falls in the scope depicted by the recently updated ch= arter. It is one of those "additional ways to extend and optimize TRILL for= the properties of the networks on which it is deployed". Thanks, Mingui ________________________________________ From: trill-bounces@ietf.org [trill-bounces@ietf.org] on behalf of Sam Aldr= in [aldrin.ietf@gmail.com] Sent: Thursday, December 06, 2012 2:02 To: Mingui Zhang Cc: trill@ietf.org Subject: Re: [trill] TRILL Resilient Distribution Trees, who have read it? I haven't paid too much attention into the details of the draft. Hence i wi= ll defer questions related to draft, for later time. But I do have few ques= tions related to procedure. 1. I do not see this work item chartered for TRILL WG. Until it is done, it= is not prudent for WG to focus on non-chartered items, atleast till the up= dated charter is in place. 2. Is this email a WG adoption call? Not being aware IETF procedures, can i= ndividuals call for WG adoption or is it done by chairs? If it is only by W= G chairs, what is the purpose of this email. Cheers Sam Sent from my iPad On Nov 30, 2012, at 12:18 AM, Mingui Zhang wrote: > Hi all, > > When customers deploy TRILL in their networks, they concern much about mi= nimizing the disruption of their multicast service. So failure protection m= echanisms are desired. Protection solutions for IP Multicast service have b= een developed and standardized. However, unlike unicast, multicast protecti= on solutions cannot be reused by TRILL because TRILL-multicast is customize= d for TRILL. Therefore we composed the draft to provide the multicast prote= ction suitable for TRILL. > > As we know, TRILL can intrinsically calculate multiple distribution trees= . In the draft, this ability is leveraged to achieve multicast protection i= n a way that the pay is insignificant. > > We believe this work deserves our exploration. So, we would like to know,= who have read this draft? > > The draft > TRILL Resilient Distribution Trees > http://datatracker.ietf.org/doc/draft-zhang-trill-resilient-trees/ > > Thanks, > Mingui > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill= From aldrin.ietf@gmail.com Wed Dec 5 19:03:29 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9CE21F8D00 for ; Wed, 5 Dec 2012 19:03:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.366 X-Spam-Level: X-Spam-Status: No, score=-3.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spSweFBsT3f9 for ; Wed, 5 Dec 2012 19:03:28 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 47F0921F89CB for ; Wed, 5 Dec 2012 19:03:28 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so3960664pbc.31 for ; Wed, 05 Dec 2012 19:03:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=kToBDKwUn11UyCBz5oWpWWY3EMOvpRSrVbSDHOhgzY4=; b=D8jtviiXGvjkM0TgZKhzpqqgD8ObSRkGM8N84JEHFFTEzD8ihb0X2gkPjcjOUdpKho rMrwzI3XPSzZNXhYdRBZfb+hD028t/4/20zpQq4ShuE5SLofjUc3x4NrbKkU7r/3gP9Y ZcaNLpdLsyYZlbCEG/74gLn4dJuS+3BHudn5F7RXZf0XrmY3gK/7Dc513ltjKh1/p73G 3WHnvbjINIn1XkZAR0XyPNwjc/A4r7vSp5RjHIFE3FhQJCaj/0/C6fhNJXUc/cs78Dpe pmihpV3q8ywam9zM7miim5JJhlWZxc6CteqkNX175uKSHyw1i17W4MPWD6Wv9MfiPOXu Jzvg== Received: by 10.68.233.196 with SMTP id ty4mr2132596pbc.23.1354763007926; Wed, 05 Dec 2012 19:03:27 -0800 (PST) Received: from [192.168.1.7] (c-98-248-237-85.hsd1.ca.comcast.net. [98.248.237.85]) by mx.google.com with ESMTPS id gv9sm3926517pbc.21.2012.12.05.19.03.26 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 05 Dec 2012 19:03:26 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Sam Aldrin In-Reply-To: <4552F0907735844E9204A62BBDD325E7321371A1@SZXEML507-MBS.china.huawei.com> Date: Wed, 5 Dec 2012 19:03:23 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <892B6174-3271-4500-9EB5-75BBE95C7A3B@gmail.com> References: <4552F0907735844E9204A62BBDD325E732132977@SZXEML507-MBS.china.huawei.com>, <4552F0907735844E9204A62BBDD325E7321371A1@SZXEML507-MBS.china.huawei.com> To: Mingui Zhang X-Mailer: Apple Mail (2.1499) Cc: "trill@ietf.org" Subject: Re: [trill] TRILL Resilient Distribution Trees, who have read it? X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 03:03:29 -0000 Mingui, Thanks for the email. When everyone starts saying 'I support', was not sure what they want to = support.=20 I do not think 'I've read' is what they are saying. In regards to updated charter, where is the updated charter? I do not = see that at "http://datatracker.ietf.org/wg/trill/charter/" As far as basing the reason on ""additional ways to extend and optimize = TRILL for the properties of the networks on which it is deployed"". = Pretty much every personal draft of TRILL could argue with the same = reason. For ex: take example of #1 and #2 in the charter, where it clearly = outlines what work WG is chartered for.=20 I do not have problem with the draft as long it is clearly identified in = the WG charter. -sam On Dec 5, 2012, at 6:51 PM, Mingui Zhang wrote: > Hi Sam, >=20 > As you can see from the words of the email, it is not a WG adoption = polling. I am cautious about this. >=20 > According to the decision that the WG had made at the Atlanta meeting, = authors were asked to make sure in the TRILL mailing-list whether there = is enough number of guys who have read this draft. So, this email = actually intends to help chairs to decide whether this draft deserves a = call. I wish I have clarified your confusion. >=20 > Actually, this draft falls in the scope depicted by the recently = updated charter. It is one of those "additional ways to extend and = optimize TRILL for the properties of the networks on which it is = deployed". >=20 > Thanks, > Mingui >=20 >=20 > ________________________________________ > From: trill-bounces@ietf.org [trill-bounces@ietf.org] on behalf of Sam = Aldrin [aldrin.ietf@gmail.com] > Sent: Thursday, December 06, 2012 2:02 > To: Mingui Zhang > Cc: trill@ietf.org > Subject: Re: [trill] TRILL Resilient Distribution Trees, who have read = it? >=20 > I haven't paid too much attention into the details of the draft. Hence = i will defer questions related to draft, for later time. But I do have = few questions related to procedure. >=20 > 1. I do not see this work item chartered for TRILL WG. Until it is = done, it is not prudent for WG to focus on non-chartered items, atleast = till the updated charter is in place. > 2. Is this email a WG adoption call? Not being aware IETF procedures, = can individuals call for WG adoption or is it done by chairs? If it is = only by WG chairs, what is the purpose of this email. >=20 > Cheers > Sam >=20 > Sent from my iPad >=20 > On Nov 30, 2012, at 12:18 AM, Mingui Zhang = wrote: >=20 >> Hi all, >>=20 >> When customers deploy TRILL in their networks, they concern much = about minimizing the disruption of their multicast service. So failure = protection mechanisms are desired. Protection solutions for IP Multicast = service have been developed and standardized. However, unlike unicast, = multicast protection solutions cannot be reused by TRILL because = TRILL-multicast is customized for TRILL. Therefore we composed the draft = to provide the multicast protection suitable for TRILL. >>=20 >> As we know, TRILL can intrinsically calculate multiple distribution = trees. In the draft, this ability is leveraged to achieve multicast = protection in a way that the pay is insignificant. >>=20 >> We believe this work deserves our exploration. So, we would like to = know, who have read this draft? >>=20 >> The draft >> TRILL Resilient Distribution Trees >> http://datatracker.ietf.org/doc/draft-zhang-trill-resilient-trees/ >>=20 >> Thanks, >> Mingui >> _______________________________________________ >> trill mailing list >> trill@ietf.org >> https://www.ietf.org/mailman/listinfo/trill > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill From zhangxudong@huawei.com Wed Dec 5 23:14:48 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 737FD21F8D5A for ; Wed, 5 Dec 2012 23:14:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.45 X-Spam-Level: ** X-Spam-Status: No, score=2.45 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9bPrrYLM3tw for ; Wed, 5 Dec 2012 23:14:47 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C7B3721F8D5F for ; Wed, 5 Dec 2012 23:14:46 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANN59881; Thu, 06 Dec 2012 07:14:45 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 6 Dec 2012 07:13:34 +0000 Received: from SZXEML458-HUB.china.huawei.com (10.82.67.201) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 6 Dec 2012 07:14:03 +0000 Received: from SZXEML501-MBX.china.huawei.com ([169.254.1.15]) by SZXEML458-HUB.china.huawei.com ([10.82.67.201]) with mapi id 14.01.0323.003; Thu, 6 Dec 2012 15:13:56 +0800 From: Zhangxudong To: Linda Dunbar , "Pathangi_Janardhanan@Dell.com" , "ayabaner@gmail.com" , "trill@ietf.org" Thread-Topic: [trill] TRILL Resilient Distribution Trees, who have read it? Thread-Index: Ac3O0ux4S0JhVhpwS56Ahgx4dyNymwCtjLeAACASioAAFc/pAAAYkcgAAC+RmJA= Date: Thu, 6 Dec 2012 07:13:55 +0000 Message-ID: References: <4552F0907735844E9204A62BBDD325E732132977@SZXEML507-MBS.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F6450D5272@dfweml505-mbx> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F6450D5272@dfweml505-mbx> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.76.218] Content-Type: multipart/alternative; boundary="_000_A987F4BC55F40A408FB445FA5B021C34656363EEszxeml501mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [trill] =?gb2312?b?tPC4tDogIFRSSUxMIFJlc2lsaWVudCBEaXN0cmlidXRp?= =?gb2312?b?b24gVHJlZXMsIHdobyBoYXZlIHJlYWQgaXQ/?= X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 07:14:48 -0000 --_000_A987F4BC55F40A408FB445FA5B021C34656363EEszxeml501mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SSBoYXZlIHJlYWQgaXQgYW5kIHRoaW5rIGl0J3MgZ29vZCB0byBwcm92aWRlIG11bHRpY2FzdCBw cm90ZWN0aW9uIGluIFRSSUxMLg0KDQq3orz+yMs6IHRyaWxsLWJvdW5jZXNAaWV0Zi5vcmcgW21h aWx0bzp0cmlsbC1ib3VuY2VzQGlldGYub3JnXSC0+rHtIExpbmRhIER1bmJhcg0Kt6LLzcqxvOQ6 IDIwMTLE6jEy1MI2yNUgMDozMg0KytW8/sjLOiBQYXRoYW5naV9KYW5hcmRoYW5hbkBEZWxsLmNv bTsgYXlhYmFuZXJAZ21haWwuY29tOyB0cmlsbEBpZXRmLm9yZw0K1vfM4jogUmU6IFt0cmlsbF0g VFJJTEwgUmVzaWxpZW50IERpc3RyaWJ1dGlvbiBUcmVlcywgd2hvIGhhdmUgcmVhZCBpdD8NCg0K U3VwcG9ydCwNCg0KTGluZGEgRHVuYmFyDQoNCg0KRnJvbTogdHJpbGwtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOnRyaWxsLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBeWFuIEJhbmVy amVlDQpTZW50OiBUdWVzZGF5LCBEZWNlbWJlciAwNCwgMjAxMiAxMTo1NCBQTQ0KVG86IHRyaWxs QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3RyaWxsXSBUUklMTCBSZXNpbGllbnQgRGlzdHJpYnV0 aW9uIFRyZWVzLCB3aG8gaGF2ZSByZWFkIGl0Pw0KDQpJIHdvdWxkIGxpa2UgdG8gdm9pY2Ugc3Vw cG9ydCBmb3IgdGhpcyB3b3JrIChhcyBhIGNvLWF1dGhvcikuDQoNCkl0IGlzIGltcG9ydGFudCB0 byBoYXZlIHNvbWUgZGV0ZXJtaW5pc20gdG8gdGhlIG1hbm5lciBpbiB3aGljaA0KbXVsdGktZGVz dGluYXRpb24gdHJlZXMgYXJlIGNvbXB1dGVkIGZvciBvcGVyYXRpb25hbCBwdXJwb3NlcyBhbmQN CnRoaXMgZHJhZnQgaXMgYSBzdGVwIGluIHRoYXQgZGlyZWN0aW9uLg0KDQpUaGFua3MsDQpBeWFu DQoNCk9uIE1vbiwgRGVjIDMsIDIwMTIgYXQgNzowNSBQTSwgQW5vb3AgR2hhbndhbmkgPGFub29w QGFsdW1uaS5kdWtlLmVkdTxtYWlsdG86YW5vb3BAYWx1bW5pLmR1a2UuZWR1Pj4gd3JvdGU6DQpK dXN0IHdhbnRlZCB0byBzYXkgdGhhdCBJIHN1cHBvcnQgdGhpcyB3b3JrIChhcyBhIGNvLWF1dGhv cikuDQoNCkkgdGhpbmsgdGhpcyB3aWxsIG1ha2UgcHJvdmlzaW9uaW5nIHNpbXBsZXIgYW5kIHdv dWxkIGFsbG93IGFuDQpvcGVyYXRvciB0byBjcmVhdGUgbXVsdGlwbGUgdHJlZXMgdGhhdCBhcmUg bWF4aW1hbGx5IGRpc2pvaW50Lg0KSW4gdGhlIGNhc2Ugb2YgZmF0IHRyZWVzLCB0aGlzIGlzIGZh aXJseSB0cml2aWFsIHRvIGRvIGluIGEgbWFudWFsDQp3YXkgKGp1c3QgdXNlIGRpZmZlcmVudCAi Y29yZSIgUkJyaWRnZXMgYXMgcm9vdHMpLCBidXQgaW4gYW55DQpvdGhlciB0b3BvbG9neSwgdGhp cyB3aWxsIGhlbHAgYXZvaWQgb3ZlcmxhcHBpbmcgbGlua3MuDQoNCkFub29wDQoNCk9uIEZyaSwg Tm92IDMwLCAyMDEyIGF0IDEyOjE4IEFNLCBNaW5ndWkgWmhhbmcgPHpoYW5nbWluZ3VpQGh1YXdl aS5jb208bWFpbHRvOnpoYW5nbWluZ3VpQGh1YXdlaS5jb20+PiB3cm90ZToNCkhpIGFsbCwNCg0K V2hlbiBjdXN0b21lcnMgZGVwbG95IFRSSUxMIGluIHRoZWlyIG5ldHdvcmtzLCB0aGV5IGNvbmNl cm4gbXVjaCBhYm91dCBtaW5pbWl6aW5nIHRoZSBkaXNydXB0aW9uIG9mIHRoZWlyIG11bHRpY2Fz dCBzZXJ2aWNlLiBTbyBmYWlsdXJlIHByb3RlY3Rpb24gbWVjaGFuaXNtcyBhcmUgZGVzaXJlZC4g UHJvdGVjdGlvbiBzb2x1dGlvbnMgZm9yIElQIE11bHRpY2FzdCBzZXJ2aWNlIGhhdmUgYmVlbiBk ZXZlbG9wZWQgYW5kIHN0YW5kYXJkaXplZC4gSG93ZXZlciwgdW5saWtlIHVuaWNhc3QsIG11bHRp Y2FzdCBwcm90ZWN0aW9uIHNvbHV0aW9ucyBjYW5ub3QgYmUgcmV1c2VkIGJ5IFRSSUxMIGJlY2F1 c2UgVFJJTEwtbXVsdGljYXN0IGlzIGN1c3RvbWl6ZWQgZm9yIFRSSUxMLiBUaGVyZWZvcmUgd2Ug Y29tcG9zZWQgdGhlIGRyYWZ0IHRvIHByb3ZpZGUgdGhlIG11bHRpY2FzdCBwcm90ZWN0aW9uIHN1 aXRhYmxlIGZvciBUUklMTC4NCg0KQXMgd2Uga25vdywgVFJJTEwgY2FuIGludHJpbnNpY2FsbHkg Y2FsY3VsYXRlIG11bHRpcGxlIGRpc3RyaWJ1dGlvbiB0cmVlcy4gSW4gdGhlIGRyYWZ0LCB0aGlz IGFiaWxpdHkgaXMgbGV2ZXJhZ2VkIHRvIGFjaGlldmUgbXVsdGljYXN0IHByb3RlY3Rpb24gaW4g YSB3YXkgdGhhdCB0aGUgcGF5IGlzIGluc2lnbmlmaWNhbnQuDQoNCldlIGJlbGlldmUgdGhpcyB3 b3JrIGRlc2VydmVzIG91ciBleHBsb3JhdGlvbi4gU28sIHdlIHdvdWxkIGxpa2UgdG8ga25vdywg d2hvIGhhdmUgcmVhZCB0aGlzIGRyYWZ0Pw0KDQpUaGUgZHJhZnQNClRSSUxMIFJlc2lsaWVudCBE aXN0cmlidXRpb24gVHJlZXMNCmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt emhhbmctdHJpbGwtcmVzaWxpZW50LXRyZWVzLw0KDQpUaGFua3MsDQpNaW5ndWkNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQp0cmlsbCBtYWlsaW5nIGxp c3QNCnRyaWxsQGlldGYub3JnPG1haWx0bzp0cmlsbEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJpbGwNCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KdHJpbGwgbWFpbGluZyBsaXN0DQp0cmlsbEBpZXRm Lm9yZzxtYWlsdG86dHJpbGxAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3RyaWxsDQoNCg== --_000_A987F4BC55F40A408FB445FA5B021C34656363EEszxeml501mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

I have read it and think it's good to provide mul= ticast protection in TRILL.

 = ;

=B7=A2=BC=FE=C8=CB: trill-bounces@ietf.or= g [mailto:trill-bounces@ietf.org] =B4=FA=B1=ED = Linda Dunbar
=B7=A2=CB=CD= =CA=B1=BC=E4: 2012=C4=EA12=D4=C2= 6=C8=D5 0:32
=CA=D5=BC=FE=C8=CB: Pathangi_Janardhanan@Dell.com; ayabaner@gmail.com; trill@ietf.org =D6=F7=CC=E2: Re: [trill] TRILL Resilient Distribution Trees, who have read it?

 

Support,

 = ;

Linda Dunb= ar

 = ;

 = ;

From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org= ] On Behalf Of Ayan Banerjee
Sent: Tuesday, December 04, 2012 11:54 PM
To: trill@ietf.org
Subject: Re: [trill] TRILL Resilient Distribution Trees, who have re= ad it?

 

= I would like to voice support for this work (as a co-author).

It is important to have some determinism to the manner in which
multi-destination trees are computed for operational purposes and
this draft is a step in that direction.

Thanks,
Ayan

=  

On Mon, Dec 3, 2012 at 7:05 PM,= Anoop Ghanwani <anoop@alumni.duke.edu> wrote:

Just wanted to say that I suppo= rt this work (as a co-author).

 

I think this will make provisio= ning simpler and would allow an

operator to create multiple tre= es that are maximally disjoint.

In the case of fat trees, this = is fairly trivial to do in a manual

way (just use different "c= ore" RBridges as roots), but in any 

other topology, this will help = avoid overlapping links.

&n= bsp;

Anoop

 

On Fri, Nov 30, 2012 at 12:18 A= M, Mingui Zhang <zhangmingui@huawei.com> wrote:

Hi all,

When customers deploy TRILL in their networks, they concern much about mini= mizing the disruption of their multicast service. So failure protection mec= hanisms are desired. Protection solutions for IP Multicast service have bee= n developed and standardized. However, unlike unicast, multicast protection solutions cannot be reused by TRILL b= ecause TRILL-multicast is customized for TRILL. Therefore we composed the d= raft to provide the multicast protection suitable for TRILL.

As we know, TRILL can intrinsically calculate multiple distribution trees. = In the draft, this ability is leveraged to achieve multicast protection in = a way that the pay is insignificant.

We believe this work deserves our exploration. So, we would like to know, w= ho have read this draft?

The draft
TRILL Resilient Distribution Trees
http://datatracker.ietf.org/doc/draft-zhang-trill-res= ilient-trees/

Thanks,
Mingui
_______________________________________________
trill mailing list
trill@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/trill

 

=
_______________________________________________
trill mailing list
trill@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/trill

 

--_000_A987F4BC55F40A408FB445FA5B021C34656363EEszxeml501mbxchi_-- From windy_1@skyhighway.com Thu Dec 6 08:54:45 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2774C21F8623 for ; Thu, 6 Dec 2012 08:54:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.868 X-Spam-Level: **** X-Spam-Status: No, score=4.868 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_EXTRA_CLOSE=2.809, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ElGYi5p6YM0f for ; Thu, 6 Dec 2012 08:54:44 -0800 (PST) Received: from skyhighway.com (skyhighway.com [63.249.82.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADCF21F850E for ; Thu, 6 Dec 2012 08:54:44 -0800 (PST) Received: from Firefly.skyhighway.com (dsl-63-249-88-160.static.cruzio.com [63.249.88.160]) by skyhighway.com with ESMTP id qB6Gshnv041879 for ; Thu, 6 Dec 2012 08:54:43 -0800 (PST) Message-Id: <201212061654.qB6Gshnv041879@skyhighway.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 06 Dec 2012 08:54:40 -0800 To: "trill@ietf.org" From: gayle noble In-Reply-To: <892B6174-3271-4500-9EB5-75BBE95C7A3B@gmail.com> References: <4552F0907735844E9204A62BBDD325E732132977@SZXEML507-MBS.china.huawei.com> <4552F0907735844E9204A62BBDD325E7321371A1@SZXEML507-MBS.china.huawei.com> <892B6174-3271-4500-9EB5-75BBE95C7A3B@gmail.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Subject: Re: [trill] TRILL Resilient Distribution Trees, who have read it? X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 16:54:45 -0000

(in my opinion) corrections:
1. Introduction
Normally, network [Normally, a network] fault will be recovered through a network wide reconvergence of the forwarding states but [states, but] this process is too slow to meet the tight SLA requirements on the service disruption duration.

in the next paragraph:
With backup forwarding states installed in advance, a protection mechanism is possible to restore a interrupted [an interrupted] multicast stream in tens of milliseconds which guarantees the stringent SLA on service disruption

However, the way TRILL constructs distribution trees (DT) is different from the way multicast trees are computed under IP/MPLS therefore [IP/MPLS, therefore] a multicast protection mechanism suitable for TRILL is required.

Global 1:1 protection is used to refer to the mechanism having the multicast source RBridge normally injects [inject] one multicast stream onto the primary DT.

When this stream is detected to be interrupted, the source RBridge switches to the backup DT to inject subsequent multicast stream [streams] until the primary DT is recovered.

Global 1+1 protection is used to refer to the mechanism having the multicast source RBridge always injects [inject] two copies of multicast streams onto the primary DT and backup DT respectively.

In [the] normal case, multicast receivers pick the stream sent along the primary DT and egress it to its local link.


2.2
When RBridges receive an Affinity Link which is an incoming link of RB2. RB2's [RB2, RB2's] incoming links other than the Affinity Link are removed from the full graph of the campus to get a sub graph.

(point four)
  In order to protect a node on the primary tree, a backup tree can be
  set up as lack of this [setup without this] node [mMRT].

A DT does [DT that does] not span all RBridges in the campus may not cover all receivers of many a multicast [many multicast] group (This is different from the multicast trees construction signaled by PIM [RFC4601] or mLDP [RFC6388].).
3.2.1
For example, in Figure 3.1, the backup DT is set up maximally disjoint to the primary DT(The full topology is an combination [a combination] of these two DTs, which is not shown in the figure.).

Except the [Except for the] link between RB1 and RB2, all other links on the primary DT do not overlap with links on the backup DT.

It means that every link on the primary DT except link RB1-RB2 can DT, except link RB1-RB2, can] be protected by the backup DT.

3.2.1.1
But it is desirable that each RBridge independently computes Affinity Links for a backup DT while the same result is got across the whole campus, which enables a distributed deployment and also minimizes configuration . [ configuration.]

Question: if this computation is done independently what do they mean by "the same result is got across the whole campus" ??


Algorithms for MRT [mMRT] may be used to figure out Affinity Links on a backup DT which is maximally disjoint [disjointed] to the primary DT but it only provides a subset of all possible solutions.

Two disjoint [disjointed] (or maximally disjoint [disjointed ]) trees may root from  different nodes, which significantly augments the solution space.

In order to reduce the amount of Affinity TLVs flooded across the campus, only those will not [those not] picked by conventional DT calculation process ought to be recognized as Affinity Links.

3.2.1.2
Similar as [CMT], every Parent RBridge (PRB) of an Affinity Link take [takes] charge of announcing this link in the Affinity TLV.

question: Similar as [CMT] .. what does this mean?

3.2.2. Backup DT Calculation without Affinity Links

This section aims to provide an alternative method to set up the disjoint [disjointed] DT without Affinity Links.

In other words, the two trees will be maximally disjoint [disjointed ].

To sum up, RBridges do precompute [pre-compute] all the trees that might be used but [used, but] only install part of them according to each ingress.

Since the backup DT is intentionally built up maximally disjoint [disjointed ] to the primary DT, when a link fails and interrupts the ongoing multicast traffic sent along the primary DT, it is probably that the backup DT is not affected.


4.1. Pruning the Backup Distribution Tree
  Backup [The backup] DT should be pruned per-VLAN.
But the way backup [way a backup] DT being [is] pruned is different from the way that the primary DT is pruned.

Even though a branch contains no downstream receivers, it is probably [probable] that it should not be pruned for the purpose of protection.

Those redundant links [that] ought to be pruned will not be protected.

4.2
However, when global 1+1 protection or local protection is applied, traffic duplication will happen if multicast receivers accept both copies of multicast [of the multicast] frame from two RPF filters.

In order to avoid such duplication, multicast receivers (egress RBridge) MUST act as merge points to active [activate] a single RPF filter and discard the duplicated frames from the other RPF filter.

5.1
Upon [When] the ingress RBridge is notified about the failure, it immediately makes this switch over.

[The] Ingress RBridge will switch ongoing multicast traffic based on this judgment.

For example, if RB9 does not response while RB10 still responses [ responds], RB7 will presume that link RB1-RB5 and RB5-RB9 are failed.

Accurate link failure detection might help ingress RBridge [RBridges] to make smarter decision but it's out of the scope of this document.

RBridges may make use of [the] RBridge Channel to speed up the failure propagation [RBch]. LSPs for the purpose of failure notification may be sent to the ingress RBridge as unicast TRILL Data using [the] RBridge Channel.

5.2.2. Traffic Forking and Merging

For the sake of protection, transit RBridges SHOULD active [activate] both primary and backup RPF filters, therefore both copies of the multicast frames will pass through transit RBridges.

 5.3.
In the local protection, the Point of Local Repair (PLR) happens at the upstream RBridge connecting the failed link who [link. It is this RBridge that] makes the decision to replicate the multicast traffic to recover this link failure.

Since the ingress RBridge is not necessarily the root of the distribution tree in TRILL, a multicast downstream point may be not [may not be] the descendants of the ingress point on the distribution tree.

5.3.1
But the ingress of the multicast frame MUST be remained [MUST remain] unchanged.


5.3.2. Duplication Suppression

When a PLR starts to sent [send] replicated multicast frames on the backup DT, multicast frames sent along the primary DT are still going on.

5.4
c
However, if the PLR stops redirecting earlier than the ingress RBridge switches to the new primary DT, packet loss may happen; [.]



[my concern: Relaxing the Reverse Path Forwarding check could cause problems unless some additional magic is added. Could a tag be added stating path down. example: RB1-RB5 down. Thus the receiving RBridge knows it can relax its Reverse Path Forwarding check for that path. ]

From d3e3e3@gmail.com Thu Dec 6 15:37:57 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A9921F8564 for ; Thu, 6 Dec 2012 15:37:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.399 X-Spam-Level: X-Spam-Status: No, score=-103.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uulfftSSIF9H for ; Thu, 6 Dec 2012 15:37:56 -0800 (PST) Received: from mail-ia0-f181.google.com (mail-ia0-f181.google.com [209.85.210.181]) by ietfa.amsl.com (Postfix) with ESMTP id DB17621F8561 for ; Thu, 6 Dec 2012 15:37:54 -0800 (PST) Received: by mail-ia0-f181.google.com with SMTP id s32so4870902iak.26 for ; Thu, 06 Dec 2012 15:37:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=2pNtDKjLO7PDVca1dqdmPHPG35Ok3aRNp27wmx1XRqs=; b=Di/cdXv/bQTC9af/rb7+CbEGyBgo5tyU1zgUxn9bTlh4SpP5GBRe5ktVuNr738qL8Y 2+U9I610yu2ZILeExAYcKVbK3KydqQaDBAFr/75HsZLPrRqSKZP3Nc+zMurrOjd2+2fd lfcl6AzTHgfc0H8dbk/NCCFhbVuzw3fX8iQc4uAwgOcR7A2AfaSd1sOrSJiu0r0jK5gB mNZNLY/SjYDgyA5nYUjTaspGz0BUxHlBpQaxR2IX4eeFn3JVpnO5a0mLZ9E91xpcjk5N s/j5gGSRUwtY/TT23/w//Wl/JnCzshqHr7grEfEJ8HGFgT0VksfmwhzKGHDhxpgp+3n5 874g== Received: by 10.50.34.200 with SMTP id b8mr3213855igj.52.1354837074471; Thu, 06 Dec 2012 15:37:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.28.209 with HTTP; Thu, 6 Dec 2012 15:37:33 -0800 (PST) In-Reply-To: <201211291545.qATFj0YK005513@cichlid.raleigh.ibm.com> References: <201211281553.qASFrAgu013237@cichlid.raleigh.ibm.com> <201211291545.qATFj0YK005513@cichlid.raleigh.ibm.com> From: Donald Eastlake Date: Thu, 6 Dec 2012 18:37:33 -0500 Message-ID: To: Thomas Narten Content-Type: text/plain; charset=ISO-8859-1 Cc: "trill@ietf.org" Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 23:37:57 -0000 Hi Thomas, On Thu, Nov 29, 2012 at 10:45 AM, Thomas Narten wrote: > I think it is clear that there are circumstances where using unicast > rather than multicast would be a useful optimization. What the > document would benefit from is text explaining where that might be > useful and making it clear that implementations might want to do that > - as an optimization under appropriate circumstances. It doesn't have > that background, just a couple of MAY/SHOULD statements. Taking some > of the explanation in this email thread and putting it into the > document would probably help clarify the intent. I will incorporate such text. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > I suggested pulling out the text because it was apparently confusing, > and I didn't think it was necessary. There are lots of optimizations a > product might make besides this one. The document surely doesn't aim > to cover them all. > > Thomas From internet-drafts@ietf.org Thu Dec 6 17:12:37 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54E7821F86A7; Thu, 6 Dec 2012 17:12:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-7Q7AEi7Ma4; Thu, 6 Dec 2012 17:12:36 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C33E21F8659; Thu, 6 Dec 2012 17:12:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121207011207.23755.25107.idtracker@ietfa.amsl.com> Date: Thu, 06 Dec 2012 17:12:07 -0800 Cc: trill@ietf.org Subject: [trill] I-D Action: draft-ietf-trill-rbridge-mib-10.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 01:12:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transparent Interconnection of Lots of Li= nks Working Group of the IETF. Title : Definitions of Managed Objects for RBridges (Routing Bri= dges) Author(s) : Anil Rijhsinghani Kate Zebrose Filename : draft-ietf-trill-rbridge-mib-10.txt Pages : 56 Date : 2012-12-06 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing an RBridge (Routing Bridge), also known as a TRILL Switch, based on the IETF TRILL (Transparent Interconnection of Lots of Links) protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-trill-rbridge-mib-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-trill-rbridge-mib-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From zhangmingui@huawei.com Thu Dec 6 18:18:26 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E13F21F8658 for ; Thu, 6 Dec 2012 18:18:26 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qw7jv9N3Tq2 for ; Thu, 6 Dec 2012 18:18:25 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2380321F8643 for ; Thu, 6 Dec 2012 18:18:24 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMG21932; Fri, 07 Dec 2012 02:18:24 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 7 Dec 2012 02:17:49 +0000 Received: from SZXEML426-HUB.china.huawei.com (10.72.61.34) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 7 Dec 2012 02:18:23 +0000 Received: from SZXEML507-MBS.china.huawei.com ([169.254.7.234]) by szxeml426-hub.china.huawei.com ([10.72.61.34]) with mapi id 14.01.0323.003; Fri, 7 Dec 2012 10:18:14 +0800 From: Mingui Zhang To: Sam Aldrin Thread-Topic: [trill] TRILL Resilient Distribution Trees, who have read it? Thread-Index: Ac3O0ux4S0JhVhpwS56Ahgx4dyNymwD/L74AACMf82T//34OgIAAwBFm Date: Fri, 7 Dec 2012 02:18:14 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E732137228@SZXEML507-MBS.china.huawei.com> References: <4552F0907735844E9204A62BBDD325E732132977@SZXEML507-MBS.china.huawei.com>, <4552F0907735844E9204A62BBDD325E7321371A1@SZXEML507-MBS.china.huawei.com>, <892B6174-3271-4500-9EB5-75BBE95C7A3B@gmail.com> In-Reply-To: <892B6174-3271-4500-9EB5-75BBE95C7A3B@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.108.15] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "trill@ietf.org" Subject: Re: [trill] TRILL Resilient Distribution Trees, who have read it? X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 02:18:26 -0000 Hi Sam, Thanks for the points you offered. I believe people made their responses as the email required. I=92d better n= ot make any further assumption here. I=92d like to solicit the chairs to ta= ke further actions based on these feedbacks.=20 Thanks, Mingui ________________________________________ From: Sam Aldrin [aldrin.ietf@gmail.com] Sent: Thursday, December 06, 2012 11:03 To: Mingui Zhang Cc: trill@ietf.org Subject: Re: [trill] TRILL Resilient Distribution Trees, who have read it? Mingui, Thanks for the email. When everyone starts saying 'I support', was not sure what they want to sup= port. I do not think 'I've read' is what they are saying. In regards to updated charter, where is the updated charter? I do not see t= hat at "http://datatracker.ietf.org/wg/trill/charter/" As far as basing the reason on ""additional ways to extend and optimize TR= ILL for the properties of the networks on which it is deployed"". Pretty mu= ch every personal draft of TRILL could argue with the same reason. For ex: take example of #1 and #2 in the charter, where it clearly outlines= what work WG is chartered for. I do not have problem with the draft as long it is clearly identified in th= e WG charter. -sam On Dec 5, 2012, at 6:51 PM, Mingui Zhang wrote: > Hi Sam, > > As you can see from the words of the email, it is not a WG adoption polli= ng. I am cautious about this. > > According to the decision that the WG had made at the Atlanta meeting, au= thors were asked to make sure in the TRILL mailing-list whether there is en= ough number of guys who have read this draft. So, this email actually inten= ds to help chairs to decide whether this draft deserves a call. I wish I ha= ve clarified your confusion. > > Actually, this draft falls in the scope depicted by the recently updated = charter. It is one of those "additional ways to extend and optimize TRILL f= or the properties of the networks on which it is deployed". > > Thanks, > Mingui > > > ________________________________________ > From: trill-bounces@ietf.org [trill-bounces@ietf.org] on behalf of Sam Al= drin [aldrin.ietf@gmail.com] > Sent: Thursday, December 06, 2012 2:02 > To: Mingui Zhang > Cc: trill@ietf.org > Subject: Re: [trill] TRILL Resilient Distribution Trees, who have read it= ? > > I haven't paid too much attention into the details of the draft. Hence i = will defer questions related to draft, for later time. But I do have few qu= estions related to procedure. > > 1. I do not see this work item chartered for TRILL WG. Until it is done, = it is not prudent for WG to focus on non-chartered items, atleast till the = updated charter is in place. > 2. Is this email a WG adoption call? Not being aware IETF procedures, can= individuals call for WG adoption or is it done by chairs? If it is only by= WG chairs, what is the purpose of this email. > > Cheers > Sam > > Sent from my iPad > > On Nov 30, 2012, at 12:18 AM, Mingui Zhang wrote= : > >> Hi all, >> >> When customers deploy TRILL in their networks, they concern much about m= inimizing the disruption of their multicast service. So failure protection = mechanisms are desired. Protection solutions for IP Multicast service have = been developed and standardized. However, unlike unicast, multicast protect= ion solutions cannot be reused by TRILL because TRILL-multicast is customiz= ed for TRILL. Therefore we composed the draft to provide the multicast prot= ection suitable for TRILL. >> >> As we know, TRILL can intrinsically calculate multiple distribution tree= s. In the draft, this ability is leveraged to achieve multicast protection = in a way that the pay is insignificant. >> >> We believe this work deserves our exploration. So, we would like to know= , who have read this draft? >> >> The draft >> TRILL Resilient Distribution Trees >> http://datatracker.ietf.org/doc/draft-zhang-trill-resilient-trees/ >> >> Thanks, >> Mingui >> _______________________________________________ >> trill mailing list >> trill@ietf.org >> https://www.ietf.org/mailman/listinfo/trill > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill= From zhangmingui@huawei.com Thu Dec 6 18:19:48 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97A2F21E8044 for ; Thu, 6 Dec 2012 18:19:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gE+58fk6zPfG for ; Thu, 6 Dec 2012 18:19:47 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D8FBF21E8039 for ; Thu, 6 Dec 2012 18:19:45 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANO30530; Fri, 07 Dec 2012 02:19:42 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 7 Dec 2012 02:19:07 +0000 Received: from SZXEML463-HUB.china.huawei.com (10.82.67.206) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 7 Dec 2012 02:19:40 +0000 Received: from SZXEML507-MBS.china.huawei.com ([169.254.7.234]) by szxeml463-hub.china.huawei.com ([10.82.67.206]) with mapi id 14.01.0323.003; Fri, 7 Dec 2012 10:19:37 +0800 From: Mingui Zhang To: gayle noble , "trill@ietf.org" Thread-Topic: [trill] TRILL Resilient Distribution Trees, who have read it? Thread-Index: AQHN09JpZhve9DqD7EesU3cs7iLnFpgMmqFf Date: Fri, 7 Dec 2012 02:19:37 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E7321373B9@SZXEML507-MBS.china.huawei.com> References: <4552F0907735844E9204A62BBDD325E732132977@SZXEML507-MBS.china.huawei.com> <4552F0907735844E9204A62BBDD325E7321371A1@SZXEML507-MBS.china.huawei.com> <892B6174-3271-4500-9EB5-75BBE95C7A3B@gmail.com>, <201212061654.qB6Gshnv041879@skyhighway.com> In-Reply-To: <201212061654.qB6Gshnv041879@skyhighway.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.108.15] Content-Type: multipart/alternative; boundary="_000_4552F0907735844E9204A62BBDD325E7321373B9SZXEML507MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [trill] TRILL Resilient Distribution Trees, who have read it? X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 02:19:48 -0000 --_000_4552F0907735844E9204A62BBDD325E7321373B9SZXEML507MBSchi_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Gayle, Thanks for your review! I will soon update the draft and embody those chang= es you=92ve suggested. Responses to your questions are offered as follows. >Question: if this computation is done independently what do they mean by "= the same result is got across the whole campus" ?? same [consistent] >question: Similar as [CMT] .. what does this mean? In the CMT draft, the nickname of the originator of the Affinity TLV is not= explicitly included. When an RBridge receives this TLV, it knows the origi= nator, therefore it can pinpoint the Affinity Link (from =91originator=92 t= o the RB specified in the =91AFFINITY RECORD=92). This also means, only the= upstream-attached node can announce an Affinity Link. >tag for RPFC relaxing It would be great if we can introduce a tag here. I=92d like to take one st= ep further. I suggest using one bit from the Multi-Topology field as the ta= g. With this tag, RPFC relaxing will become unnecessary. I remember a guy a= lso mentioned whether we can make use of MT technique in an offline discuss= ion. Unfortunately, the MT feature is not supported by TRILL yet. RPFC relaxing is expensive. That is why I once suggested in a TRILL face-to= -face meeting that the content about the local protection is offered in the= draft for the clarification purpose. The rationale is like this: most guys= from vendors and operators prefer local protection to global protection. I= f no local protection content is included, they will be confused. If the MT feature is supported by TRILL in the future. We can treat the con= tent of local protection as the place-holder. It can easily be updated to m= ake use of the MT technique to replace the RPFC relaxing. Thanks, Mingui ________________________________ From: trill-bounces@ietf.org [trill-bounces@ietf.org] on behalf of gayle no= ble [windy_1@skyhighway.com] Sent: Friday, December 07, 2012 0:54 To: trill@ietf.org Subject: Re: [trill] TRILL Resilient Distribution Trees, who have read it? (in my opinion) corrections: 1. Introduction Normally, network [Normally, a network] fault will be recovered through a n= etwork wide reconvergence of the forwarding states but [states, but] this p= rocess is too slow to meet the tight SLA requirements on the service disrup= tion duration. in the next paragraph: With backup forwarding states installed in advance, a protection mechanism = is possible to restore a interrupted [an interrupted] multicast stream in t= ens of milliseconds which guarantees the stringent SLA on service disruptio= n However, the way TRILL constructs distribution trees (DT) is different from= the way multicast trees are computed under IP/MPLS therefore [IP/MPLS, the= refore] a multicast protection mechanism suitable for TRILL is required. Global 1:1 protection is used to refer to the mechanism having the multicas= t source RBridge normally injects [inject] one multicast stream onto the pr= imary DT. When this stream is detected to be interrupted, the source RBridge switches= to the backup DT to inject subsequent multicast stream [streams] until the= primary DT is recovered. Global 1+1 protection is used to refer to the mechanism having the multicas= t source RBridge always injects [inject] two copies of multicast streams on= to the primary DT and backup DT respectively. In [the] normal case, multicast receivers pick the stream sent along the pr= imary DT and egress it to its local link. 2.2 When RBridges receive an Affinity Link which is an incoming link of RB2. RB= 2's [RB2, RB2's] incoming links other than the Affinity Link are removed fr= om the full graph of the campus to get a sub graph. (point four) In order to protect a node on the primary tree, a backup tree can be set up as lack of this [setup without this] node [mMRT]. A DT does [DT that does] not span all RBridges in the campus may not cover = all receivers of many a multicast [many multicast] group (This is different= from the multicast trees construction signaled by PIM [RFC4601] or mLDP [R= FC6388].). 3.2.1 For example, in Figure 3.1, the backup DT is set up maximally disjoint to t= he primary DT(The full topology is an combination [a combination] of these = two DTs, which is not shown in the figure.). Except the [Except for the] link between RB1 and RB2, all other links on th= e primary DT do not overlap with links on the backup DT. It means that every link on the primary DT except link RB1-RB2 can DT, exce= pt link RB1-RB2, can] be protected by the backup DT. 3.2.1.1 But it is desirable that each RBridge independently computes Affinity Links= for a backup DT while the same result is got across the whole campus, whic= h enables a distributed deployment and also minimizes configuration . [ con= figuration.] Question: if this computation is done independently what do they mean by "t= he same result is got across the whole campus" ?? Algorithms for MRT [mMRT] may be used to figure out Affinity Links on a bac= kup DT which is maximally disjoint [disjointed] to the primary DT but it on= ly provides a subset of all possible solutions. Two disjoint [disjointed] (or maximally disjoint [disjointed ]) trees may r= oot from different nodes, which significantly augments the solution space. In order to reduce the amount of Affinity TLVs flooded across the campus, o= nly those will not [those not] picked by conventional DT calculation proces= s ought to be recognized as Affinity Links. 3.2.1.2 Similar as [CMT], every Parent RBridge (PRB) of an Affinity Link take [take= s] charge of announcing this link in the Affinity TLV. question: Similar as [CMT] .. what does this mean? 3.2.2. Backup DT Calculation without Affinity Links This section aims to provide an alternative method to set up the disjoint [= disjointed] DT without Affinity Links. In other words, the two trees will be maximally disjoint [disjointed ]. To sum up, RBridges do precompute [pre-compute] all the trees that might be= used but [used, but] only install part of them according to each ingress. Since the backup DT is intentionally built up maximally disjoint [disjointe= d ] to the primary DT, when a link fails and interrupts the ongoing multica= st traffic sent along the primary DT, it is probably that the backup DT is = not affected. 4.1. Pruning the Backup Distribution Tree Backup [The backup] DT should be pruned per-VLAN. But the way backup [way a backup] DT being [is] pruned is different from th= e way that the primary DT is pruned. Even though a branch contains no downstream receivers, it is probably [prob= able] that it should not be pruned for the purpose of protection. Those redundant links [that] ought to be pruned will not be protected. 4.2 However, when global 1+1 protection or local protection is applied, traffic= duplication will happen if multicast receivers accept both copies of multi= cast [of the multicast] frame from two RPF filters. In order to avoid such duplication, multicast receivers (egress RBridge) MU= ST act as merge points to active [activate] a single RPF filter and discard= the duplicated frames from the other RPF filter. 5.1 Upon [When] the ingress RBridge is notified about the failure, it immediate= ly makes this switch over. [The] Ingress RBridge will switch ongoing multicast traffic based on this j= udgment. For example, if RB9 does not response while RB10 still responses [ responds= ], RB7 will presume that link RB1-RB5 and RB5-RB9 are failed. Accurate link failure detection might help ingress RBridge [RBridges] to ma= ke smarter decision but it's out of the scope of this document. RBridges may make use of [the] RBridge Channel to speed up the failure prop= agation [RBch]. LSPs for the purpose of failure notification may be sent to= the ingress RBridge as unicast TRILL Data using [the] RBridge Channel. 5.2.2. Traffic Forking and Merging For the sake of protection, transit RBridges SHOULD active [activate] both = primary and backup RPF filters, therefore both copies of the multicast fram= es will pass through transit RBridges. 5.3. In the local protection, the Point of Local Repair (PLR) happens at the ups= tream RBridge connecting the failed link who [link. It is this RBridge that= ] makes the decision to replicate the multicast traffic to recover this lin= k failure. Since the ingress RBridge is not necessarily the root of the distribution t= ree in TRILL, a multicast downstream point may be not [may not be] the desc= endants of the ingress point on the distribution tree. 5.3.1 But the ingress of the multicast frame MUST be remained [MUST remain] uncha= nged. 5.3.2. Duplication Suppression When a PLR starts to sent [send] replicated multicast frames on the backup = DT, multicast frames sent along the primary DT are still going on. 5.4 c However, if the PLR stops redirecting earlier than the ingress RBridge swit= ches to the new primary DT, packet loss may happen; [.] [my concern: Relaxing the Reverse Path Forwarding check could cause problem= s unless some additional magic is added. Could a tag be added stating path = down. example: RB1-RB5 down. Thus the receiving RBridge knows it can relax = its Reverse Path Forwarding check for that path. ] --_000_4552F0907735844E9204A62BBDD325E7321373B9SZXEML507MBSchi_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

<= font size=3D"2" face=3D"Tahoma">Hi Gayle,

<= /span> 

<= font size=3D"2" face=3D"Tahoma">Thanks for your review! I will soon update = the draft and embody those changes you=92ve suggested.

<= font size=3D"2" face=3D"Tahoma">Responses to your questions are offered as = follows.

<= /span> 

<= font size=3D"2" face=3D"Tahoma">>Question: if this computation is done i= ndependently what do they mean by "the same result is got across the w= hole campus" ??

<= /span> 

<= font size=3D"2" face=3D"Tahoma">same [consistent]

<= /span> 

<= font size=3D"2" face=3D"Tahoma">>question: Similar as [CMT] .. what does= this mean?

<= /span> 

<= font size=3D"2" face=3D"Tahoma">In the CMT draft, the nickname of the origi= nator of the Affinity TLV is not explicitly included. When an RBridge recei= ves this TLV, it knows the originator, therefore it can pinpoint the Affinity Link (from =91originator=92 to the RB specifi= ed in the =91AFFINITY RECORD=92). This also means, only the upstream-attach= ed node can announce an Affinity Link.

<= /span> 

<= font size=3D"2" face=3D"Tahoma">>tag for RPFC relaxing

<= /span> 

<= font size=3D"2" face=3D"Tahoma">It would be great if we can introduce a tag= here. I=92d like to take one step further. I suggest using one bit from th= e Multi-Topology field as the tag. With this tag, RPFC relaxing will become unnecessary. I remember a guy also mentione= d whether we can make use of MT technique in an offline discussion. Unfortu= nately, the MT feature is not supported by TRILL yet.

<= /span> 

<= font size=3D"2" face=3D"Tahoma">RPFC relaxing is expensive. That is why I o= nce suggested in a TRILL face-to-face meeting that the content about the lo= cal protection is offered in the draft for the clarification purpose. The rationale is like this: most guys from vend= ors and operators prefer local protection to global protection. If no local= protection content is included, they will be confused.

<= /span> 

<= font size=3D"2" face=3D"Tahoma">If the MT feature is supported by TRILL in = the future. We can treat the content of local protection as the place-holde= r. It can easily be updated to make use of the MT technique to replace the RPFC relaxing.

<= /span> 

<= font size=3D"2" face=3D"Tahoma">Thanks,
Mingui

 

From: trill-bounces@ietf.org [trill-bounce= s@ietf.org] on behalf of gayle noble [windy_1@skyhighway.com]
Sent: Friday, December 07, 2012 0:54
To: trill@ietf.org
Subject: Re: [trill] TRILL Resilient Distribution Trees, who have re= ad it?


(in my opinion) corrections:
1. Introduction
Normally, network= [Normally, a network] fault will be recovered through a network wide= reconvergence of the forwarding states but [states, but] this process is too slow to meet the tigh= t SLA requirements on the service disruption duration.

in the next paragraph:
With backup forwarding states installed in advance, a protection m= echanism is possible to restore a interrupted [an interrupted] multicast stream in tens of milliseconds which guar= antees the stringent SLA on service disruption

However, the way TRILL constructs distribution trees (DT) is diffe= rent from the way multicast trees are computed under IP/MPLS therefore [IP/MPLS, therefore] a multicast protection mech= anism suitable for TRILL is required.

Global 1:1 protection is used to refer to the mechanism having the= multicast source RBridge normally injects [inject] one multicast stream onto the primary DT.

When this stream is detected to be interrupted, the source RBridge= switches to the backup DT to inject subsequent multicast stream [streams] until the primary DT is recovered.

Global 1+1 protection is used to refer to the mechanism having= the multicast source RBridge always injects [inject] two copies of multicast streams onto the primary = DT and backup DT respectively.

In [the] normal case, mu= lticast receivers pick the stream sent along the primary DT and egress it t= o its local link.


2.2
When RBridges receive an Affinity Link which is an incoming link o= f RB2. RB2's [RB2, RB2's] in= coming links other than the Affinity Link are removed from the full graph o= f the campus to get a sub graph.

(point four)
  In order to protect a node on the primary tree, a backup tr= ee can be
  set up as lack of this [setup without this] node [mMRT].

A DT does [DT that does] not span all RBridges in the campus may not cover all= receivers of many a multicast [many multicast]= group (This is different from the multicast trees construction signaled by= PIM [RFC4601] or mLDP [RFC6388].).
3.2.1
For example, in Figure 3.1, the backup DT is set up maximally disj= oint to the primary DT(The full topology is an combination [a combination] of these two DTs, which is not shown in the figure.)= .

Except the [Except for the] link between RB1 and RB2, al= l other links on the primary DT do not overlap with links on the backup DT.=

It means that every link on the primary DT except link RB1-RB2 can DT, except link RB1-RB2, can] be protected by the backup DT.

3.2.1.1
But it is desirable that each RBridge independently computes Affin= ity Links for a backup DT while the same result is got across the whole cam= pus, which enables a distributed deployment and also minimizes configuration . [ configuration.]

Question: if this computation is done independently what do they m= ean by "the same result is got across the whole campus" ??


Algorithms for MRT [mMRT] may be used to figure out Affinity Links= on a backup DT which is maximally disjoint [disjointed] to the primary DT but it only provides a sub= set of all possible solutions.

Two disjoint [disjointed] (or maximally disjoint [disjointed ]) trees may root from  different nodes, which signif= icantly augments the solution space.

In order to reduce the amount of Affinity TLVs flooded across the = campus, only those will not [those not] picked by conventional DT calcul= ation process ought to be recognized as Affinity Links.

3.2.1.2
Similar as [CMT], every Parent RBridge (PRB) of an Affinity Link <= font color=3D"#00b0f0" size=3D"1"> take [takes] charge of ann= ouncing this link in the Affinity TLV.

question: Similar as [CMT] .. what does this mean?

3.2.2. Backup DT Calculation without Affinity Links

This section aims to provide an alternative method to set up the <= font color=3D"#00b0f0" size=3D"1"> disjoint [disjointed] DT w= ithout Affinity Links.

In other words, the two trees will be maximally disjoint [disjointed ].

To sum up, RBridges do p= recompute [pre-compute] al= l the trees that might be used but [used, but] only install part of them according to each i= ngress.

Since the backup DT is intentionally built up maximally disjoint [disjointed ] to the primary DT, when a link fails and interrupts the ongoing multicast= traffic sent along the primary DT, it is probably that the backup DT is no= t affected.


4.1. Pruning the Backup Distribution Tree
  Backup [The backup] DT should be pruned per= -VLAN.
But the way backup [way a backup] DT being [is] pruned is different from the way that the primary DT is= pruned.

Even though a branch contains no downstream receivers, it is probably [probable] that i= t should not be pruned for the purpose of protection.

Those redundant links [that] ought to be pruned will not be protected.

4.2
However, when global 1+1 protection or local protection is app= lied, traffic duplication will happen if multicast receivers accept both co= pies of multicast [of the multicast] frame from two RPF filters.

In order to avoid such duplication, multicast receivers (egress RB= ridge) MUST act as merge points to active [activate] a single RPF filter and discard the duplicated f= rames from the other RPF filter.

5.1
Upon [When] the ingress RBridge is notified about the fai= lure, it immediately makes this switch over.

[The] Ingress RBridge wi= ll switch ongoing multicast traffic based on this judgment.

For example, if RB9 does not response while RB10 still responses [ responds], RB7= will presume that link RB1-RB5 and RB5-RB9 are failed.

Accurate link failure detection might help ingress RBridge [RBridges] to make= smarter decision but it's out of the scope of this document.

RBridges may make use of [the] RBridge Channel to speed up the failure propagation [RBch]. LSPs for= the purpose of failure notification may be sent to the ingress RBridge as = unicast TRILL Data using [the] RBridge Channel.

5.2.2. Traffic Forking and Merging

For the sake of protection, transit RBridges SHOULD active [activate] both pri= mary and backup RPF filters, therefore both copies of the multicast frames = will pass through transit RBridges.

 5.3.
In the local protection, the Point of Local Repair (PLR) happens a= t the upstream RBridge connecting the failed link who [link. It is this RBridge that] makes the decision to rep= licate the multicast traffic to recover this link failure.

Since the ingress RBridge is not necessarily the root of the distr= ibution tree in TRILL, a multicast downstream point may be not [may not be] the descendants of the ingress point on th= e distribution tree.

5.3.1
But the ingress of the multicast frame MUST be remained [MUST re= main] unchanged.


5.3.2. Duplication Suppression

When a PLR starts to sent [send] replicated multicast fra= mes on the backup DT, multicast frames sent along the primary DT are still = going on.

5.4
c
However, if the PLR stops redirecting earlier than the ingress RBr= idge switches to the new primary DT, packet loss may happen; [.]


[my concern: Relaxing the Reverse Path Forwarding check could caus= e problems unless some additional magic is added. Could a tag be added stat= ing path down. example: RB1-RB5 down. Thus the receiving RBridge knows it c= an relax its Reverse Path Forwarding check for that path. ]

--_000_4552F0907735844E9204A62BBDD325E7321373B9SZXEML507MBSchi_-- From windy_1@skyhighway.com Thu Dec 6 18:27:20 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB8D121E8043 for ; Thu, 6 Dec 2012 18:27:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.863 X-Spam-Level: * X-Spam-Status: No, score=1.863 tagged_above=-999 required=5 tests=[AWL=3.005, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTKtE2e8LDgM for ; Thu, 6 Dec 2012 18:27:20 -0800 (PST) Received: from skyhighway.com (skyhighway.com [63.249.82.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8119A21E8039 for ; Thu, 6 Dec 2012 18:27:20 -0800 (PST) Received: from Firefly.skyhighway.com (dsl-63-249-88-160.static.cruzio.com [63.249.88.160]) by skyhighway.com with ESMTP id qB72RKab095504 for ; Thu, 6 Dec 2012 18:27:20 -0800 (PST) Message-Id: <201212070227.qB72RKab095504@skyhighway.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 06 Dec 2012 18:27:22 -0800 To: "trill@ietf.org" From: gayle noble In-Reply-To: <4552F0907735844E9204A62BBDD325E7321373B9@SZXEML507-MBS.chi na.huawei.com> References: <4552F0907735844E9204A62BBDD325E732132977@SZXEML507-MBS.china.huawei.com> <4552F0907735844E9204A62BBDD325E7321371A1@SZXEML507-MBS.china.huawei.com> <892B6174-3271-4500-9EB5-75BBE95C7A3B@gmail.com> <201212061654.qB6Gshnv041879@skyhighway.com> <4552F0907735844E9204A62BBDD325E7321373B9@SZXEML507-MBS.china.huawei.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Subject: Re: [trill] TRILL Resilient Distribution Trees, who have read it? X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 02:27:21 -0000 Mingui
Thank you so much for taking the time to explain that to me! I now know to look up these references instead of staying confused.
gayle

At 06:19 PM 12/6/2012, Mingui Zhang wrote:
Hi Gayle,
Thanks for your review! I will soon update the draft and embody those changes you’ve suggested.
Responses to your questions are offered as follows.
>Question: if this computation is done independently what do they mean by "the same result is got across the whole campus" ??
same [consistent]
>question: Similar as [CMT] .. what does this mean?
In the CMT draft, the nickname of the originator of the Affinity TLV is not explicitly included. When an RBridge receives this TLV, it knows the originator, therefore it can pinpoint the Affinity Link (from ‘originator’ to the RB specified in the ‘AFFINITY RECORD’). This also means, only the upstream-attached node can announce an Affinity Link.
>tag for RPFC relaxing
It would be great if we can introduce a tag here. I’d like to take one step further. I suggest using one bit from the Multi-Topology field as the tag. With this tag, RPFC relaxing will become unnecessary. I remember a guy also mentioned whether we can make use of MT technique in an offline discussion. Unfortunately, the MT feature is not supported by TRILL yet.
RPFC relaxing is expensive. That is why I once suggested in a TRILL face-to-face meeting that the content about the local protection is offered in the draft for the clarification purpose. The rationale is like this: most guys from vendors and operators prefer local protection to global protection. If no local protection content is included, they will be confused.
If the MT feature is supported by TRILL in the future. We can treat the content of local protection as the place-holder. It can easily be updated to make use of the MT technique to replace the RPFC relaxing.
Thanks,
Mingui
From hu.fangwei@zte.com.cn Thu Dec 6 22:54:59 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39FD921F8965; Thu, 6 Dec 2012 22:54:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.395 X-Spam-Level: X-Spam-Status: No, score=-98.395 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J1mSiIkwoani; Thu, 6 Dec 2012 22:54:58 -0800 (PST) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 66DC321F8989; Thu, 6 Dec 2012 22:54:58 -0800 (PST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 6EDAB126DA8D; Fri, 7 Dec 2012 14:56:37 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id qB76scgK001243; Fri, 7 Dec 2012 14:54:38 +0800 (GMT-8) (envelope-from hu.fangwei@zte.com.cn) In-Reply-To: <4552F0907735844E9204A62BBDD325E732132977@SZXEML507-MBS.china.huawei.com> To: Mingui Zhang 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, 7 Dec 2012 14:54:30 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-12-07 14:54:38, Serialize complete at 2012-12-07 14:54:38 Content-Type: multipart/alternative; boundary="=_alternative 0025F54E48257ACD_=" X-MAIL: mse01.zte.com.cn qB76scgK001243 Cc: trill-bounces@ietf.org, "trill@ietf.org" Subject: Re: [trill] TRILL Resilient Distribution Trees, who have read it? X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 06:54:59 -0000 This is a multipart message in MIME format. --=_alternative 0025F54E48257ACD_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SSBoYXZlIHJlYWQgdGhlIGRyYWZ0Lg0KDQpUaGUgZHJhZnQgcHJvdmlkZXMgdG8gYnVpbGQgYmFj a3VwIGRpc3RyaWJ1dGlvbiB0cmVlIGZvciBsaW5rIHByb3RlY3Rpb24sIA0Kd2hpY2ggbWluaW5p emVzIHRoZSBzZXJpdmUgZGlzcnVwdGlvbiBmb3IgbXVsdGljYXN0IGRhdGEgZm9yd2FyZGluZy4N Cg0KSWYgdGhlcmUgaXMgYSBXRyBhZG9wdGlvbiBwb2xsaW5nLCBJIHN1cHBvcnQgaXQuDQoNCg0K DQoNCk1pbmd1aSBaaGFuZyA8emhhbmdtaW5ndWlAaHVhd2VpLmNvbT4gDQq3orz+yMs6ICB0cmls bC1ib3VuY2VzQGlldGYub3JnDQoyMDEyLTExLTMwIDE2OjE4DQoNCsrVvP7Iyw0KInRyaWxsQGll dGYub3JnIiA8dHJpbGxAaWV0Zi5vcmc+DQqzrcvNDQoNCtb3zOINClt0cmlsbF0gVFJJTEwgUmVz aWxpZW50IERpc3RyaWJ1dGlvbiBUcmVlcywgd2hvIGhhdmUgcmVhZCBpdD8NCg0KDQoNCg0KDQoN CkhpIGFsbCwNCg0KV2hlbiBjdXN0b21lcnMgZGVwbG95IFRSSUxMIGluIHRoZWlyIG5ldHdvcmtz LCB0aGV5IGNvbmNlcm4gbXVjaCBhYm91dCANCm1pbmltaXppbmcgdGhlIGRpc3J1cHRpb24gb2Yg dGhlaXIgbXVsdGljYXN0IHNlcnZpY2UuIFNvIGZhaWx1cmUgDQpwcm90ZWN0aW9uIG1lY2hhbmlz bXMgYXJlIGRlc2lyZWQuIFByb3RlY3Rpb24gc29sdXRpb25zIGZvciBJUCBNdWx0aWNhc3QgDQpz ZXJ2aWNlIGhhdmUgYmVlbiBkZXZlbG9wZWQgYW5kIHN0YW5kYXJkaXplZC4gSG93ZXZlciwgdW5s aWtlIHVuaWNhc3QsIA0KbXVsdGljYXN0IHByb3RlY3Rpb24gc29sdXRpb25zIGNhbm5vdCBiZSBy ZXVzZWQgYnkgVFJJTEwgYmVjYXVzZSANClRSSUxMLW11bHRpY2FzdCBpcyBjdXN0b21pemVkIGZv ciBUUklMTC4gVGhlcmVmb3JlIHdlIGNvbXBvc2VkIHRoZSBkcmFmdCANCnRvIHByb3ZpZGUgdGhl IG11bHRpY2FzdCBwcm90ZWN0aW9uIHN1aXRhYmxlIGZvciBUUklMTC4NCg0KQXMgd2Uga25vdywg VFJJTEwgY2FuIGludHJpbnNpY2FsbHkgY2FsY3VsYXRlIG11bHRpcGxlIGRpc3RyaWJ1dGlvbiB0 cmVlcy4gDQpJbiB0aGUgZHJhZnQsIHRoaXMgYWJpbGl0eSBpcyBsZXZlcmFnZWQgdG8gYWNoaWV2 ZSBtdWx0aWNhc3QgcHJvdGVjdGlvbiBpbiANCmEgd2F5IHRoYXQgdGhlIHBheSBpcyBpbnNpZ25p ZmljYW50Lg0KDQpXZSBiZWxpZXZlIHRoaXMgd29yayBkZXNlcnZlcyBvdXIgZXhwbG9yYXRpb24u IFNvLCB3ZSB3b3VsZCBsaWtlIHRvIGtub3csIA0Kd2hvIGhhdmUgcmVhZCB0aGlzIGRyYWZ0PyAN Cg0KVGhlIGRyYWZ0DQpUUklMTCBSZXNpbGllbnQgRGlzdHJpYnV0aW9uIFRyZWVzDQpodHRwOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXpoYW5nLXRyaWxsLXJlc2lsaWVudC10cmVl cy8NCg0KVGhhbmtzLA0KTWluZ3VpDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KdHJpbGwgbWFpbGluZyBsaXN0DQp0cmlsbEBpZXRmLm9yZw0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmlsbA0KDQoNCg== --=_alternative 0025F54E48257ACD_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgaGF2ZSByZWFkIHRoZSBkcmFm dC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoZSBk cmFmdCBwcm92aWRlcyB0byBidWlsZCBiYWNrdXAgZGlzdHJpYnV0aW9uDQp0cmVlIGZvciBsaW5r IHByb3RlY3Rpb24sIHdoaWNoIG1pbmluaXplcyB0aGUgc2VyaXZlIGRpc3J1cHRpb24gZm9yIG11 bHRpY2FzdA0KZGF0YSBmb3J3YXJkaW5nLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+SWYgdGhlcmUgaXMgYSBXRyBhZG9wdGlvbiBwb2xsaW5nLCBJDQpz dXBwb3J0IGl0LjwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0x MDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzYlPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj48Yj5NaW5ndWkgWmhhbmcgJmx0O3poYW5nbWluZ3VpQGh1YXdlaS5jb20mZ3Q7 PC9iPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj63orz+yMs6 ICZuYnNwO3RyaWxsLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+MjAxMi0xMS0zMCAxNjoxODwvZm9udD4NCjx0ZCB3aWR0aD02MyU+DQo8 dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdo dD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRk Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDt0cmlsbEBpZXRmLm9yZyZxdW90 OyAmbHQ7dHJpbGxAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8 ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250 PjwvZGl2Pg0KPHRkPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5bdHJpbGxdIFRSSUxMIFJlc2lsaWVudCBEaXN0cmli dXRpb24NClRyZWVzLCB3aG8gaGF2ZSByZWFkIGl0PzwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRh YmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0K PGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+SGkgYWxsLDxicj4NCjxicj4NCldoZW4g Y3VzdG9tZXJzIGRlcGxveSBUUklMTCBpbiB0aGVpciBuZXR3b3JrcywgdGhleSBjb25jZXJuIG11 Y2ggYWJvdXQNCm1pbmltaXppbmcgdGhlIGRpc3J1cHRpb24gb2YgdGhlaXIgbXVsdGljYXN0IHNl cnZpY2UuIFNvIGZhaWx1cmUgcHJvdGVjdGlvbg0KbWVjaGFuaXNtcyBhcmUgZGVzaXJlZC4gUHJv dGVjdGlvbiBzb2x1dGlvbnMgZm9yIElQIE11bHRpY2FzdCBzZXJ2aWNlIGhhdmUNCmJlZW4gZGV2 ZWxvcGVkIGFuZCBzdGFuZGFyZGl6ZWQuIEhvd2V2ZXIsIHVubGlrZSB1bmljYXN0LCBtdWx0aWNh c3QgcHJvdGVjdGlvbg0Kc29sdXRpb25zIGNhbm5vdCBiZSByZXVzZWQgYnkgVFJJTEwgYmVjYXVz ZSBUUklMTC1tdWx0aWNhc3QgaXMgY3VzdG9taXplZA0KZm9yIFRSSUxMLiBUaGVyZWZvcmUgd2Ug Y29tcG9zZWQgdGhlIGRyYWZ0IHRvIHByb3ZpZGUgdGhlIG11bHRpY2FzdCBwcm90ZWN0aW9uDQpz dWl0YWJsZSBmb3IgVFJJTEwuPGJyPg0KPGJyPg0KQXMgd2Uga25vdywgVFJJTEwgY2FuIGludHJp bnNpY2FsbHkgY2FsY3VsYXRlIG11bHRpcGxlIGRpc3RyaWJ1dGlvbiB0cmVlcy4NCkluIHRoZSBk cmFmdCwgdGhpcyBhYmlsaXR5IGlzIGxldmVyYWdlZCB0byBhY2hpZXZlIG11bHRpY2FzdCBwcm90 ZWN0aW9uDQppbiBhIHdheSB0aGF0IHRoZSBwYXkgaXMgaW5zaWduaWZpY2FudC48YnI+DQo8YnI+ DQpXZSBiZWxpZXZlIHRoaXMgd29yayBkZXNlcnZlcyBvdXIgZXhwbG9yYXRpb24uIFNvLCB3ZSB3 b3VsZCBsaWtlIHRvIGtub3csDQp3aG8gaGF2ZSByZWFkIHRoaXMgZHJhZnQ/IDxicj4NCjxicj4N ClRoZSBkcmFmdDxicj4NClRSSUxMIFJlc2lsaWVudCBEaXN0cmlidXRpb24gVHJlZXM8YnI+DQpo dHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXpoYW5nLXRyaWxsLXJlc2lsaWVu dC10cmVlcy88YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KTWluZ3VpPGJyPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQp0cmlsbCBtYWlsaW5nIGxp c3Q8YnI+DQp0cmlsbEBpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdHJpbGw8YnI+DQo8L3R0PjwvZm9udD4NCjxicj4NCg== --=_alternative 0025F54E48257ACD_=-- From ssalam@cisco.com Fri Dec 7 08:33:24 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B818521F85E3 for ; Fri, 7 Dec 2012 08:33:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ewnj5H52H0ck for ; Fri, 7 Dec 2012 08:33:20 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id DD70E21F860B for ; Fri, 7 Dec 2012 08:33:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10062; q=dns/txt; s=iport; t=1354898000; x=1356107600; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=iWJcnwTB17TSo7GmNXHgXhC7rKzt3R5siDLFtFuLkKk=; b=K+JTh8CQ3r/fQWBYWY0ylsl+gg9FIexqs4NEvnF2sLH5drfEMNF4zzVJ QPcaDFEn5/BMRMSjbCa2n6fo84fMo2/6PUMIZqK32UlqDi3EN3t6MrbnY +2WaqwB9K2Uz7qBRg8imFW0RZAzf4Sr1+6ZNSBfBJ64vDnQSXOUaZOF5Q k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAIMZwlCtJXHB/2dsb2JhbABEgkkjskeJAxZzgh4BAQEEeRIBCBEDAQILHSgRFAkIAgQBDQUIEYdmAw8BC7goDYlUi1Zpg2JhA5QvgnKKG4URgnOCIg X-IronPort-AV: E=McAfee;i="5400,1158,6918"; a="150528579" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 07 Dec 2012 16:33:16 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id qB7GXGUF013790 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Dec 2012 16:33:16 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.001; Fri, 7 Dec 2012 10:33:16 -0600 From: "Samer Salam (ssalam)" To: "dai.xuehui@zte.com.cn" , "Tissa Senevirathne (tsenevir)" , "sam.aldrin@gmail.com" , "d3e3e3@gmail.com" Thread-Topic: cc in "draft-ietf-trill-oam-framework-00" Thread-Index: AQHNzRpEavPGDd8Go0uh6VvMEcqUSZgNdVyA Date: Fri, 7 Dec 2012 16:33:15 +0000 Message-ID: <8F25FF8EA49D164EBE5F1B5AD33F3BC90D81801A@xmb-aln-x13.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.77.100] Content-Type: multipart/alternative; boundary="_000_8F25FF8EA49D164EBE5F1B5AD33F3BC90D81801Axmbalnx13ciscoc_" MIME-Version: 1.0 Cc: "trill@ietf.org" Subject: Re: [trill] cc in "draft-ietf-trill-oam-framework-00" X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 16:33:24 -0000 --_000_8F25FF8EA49D164EBE5F1B5AD33F3BC90D81801Axmbalnx13ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Xuehui, From: "dai.xuehui@zte.com.cn" > Date: Tuesday, November 27, 2012 7:41 PM To: "Samer Salam (ssalam)" >, "Ti= ssa Senevirathne (tsenevir)" = >, "sam.aldrin@gmail.com" >, "d3e3e3@gmail.com= " > Cc: "trill@ietf.org" > Subject: cc in "draft-ietf-trill-oam-framework-00" Hi, all trill-oam-framework authors I have some troubles on understanding cc function described in section 4.1.= 1 in draft-ietf-trill-oam-framework-00, wish you can help me for more clear= understanding. 1. 4.1.1 Fault Detection (Continuity Check) "..... The proactive fault detection function must detect the following types of defects: - Loss of continuity (LoC) to one or more remote MEPs - Unexpected connectivity between isolated VLANs (mismerge) - Unexpected connectivity to one or more remote MEPs - Period mis-configuration" In my mind, maybe the sencond and third types of defects should be defects= detected by CV ? The reason for having these functions part of CC as opposed to CV is primar= ily to allow for continuous checking of these defects, as they may be intro= duced at any point of time in the life-span of a live network, due to nodes= being commissioned/ de-commissioned or VLANs being added/deleted. As long = as these types of issues are being monitored by CC, the operator will be as= sured that there is pro-active detection, as opposed to only knowing of the= issues when a user complains. 2. 4.1.2.1 Forward Defect Indication "...... a simple network comprising of four RBridges connected in tandem: RB1, RB2,= RB3 and RB4. Both RB1 and RB4 are hosting TRILL OAM MEPs, whereas RB2 and = RB3 have MIPs. If the link between RB2 and RB3 fails, then RB2 can send a f= orward defect indication towards RB1 while RB3 sends a forward defect indic= ation towards RB4......" my question is how to detect the link faliure between RB2 and RB3 , through= TRILL oam? such as one hop TRILL BFD? The link failure may be detected through a number of mechanisms: * By observing the line-protocol state going down on the link. * Through some link OAM mechanism such as 802.3 clause 57 * Through TRILL BFD as you indicated 3.Does CC should be supported on sections? if it is, how the ingress and eg= ress nickname be set? the same as CV on sections( see the last paragraph in= section 4.2.1.1 in trill-oam-framework)? Per draft-ietf-trill-oam-req-04 section 4.3, this is a SHOULD requirement. = One way to support this, as you mention, is to follow the same nickname sch= eme as CV on sections. Regards, Samer please correct me if I have some misunderstanding :) Best Regards, xuehui --_000_8F25FF8EA49D164EBE5F1B5AD33F3BC90D81801Axmbalnx13ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <9B1761BE6331894AAD7D3368C67A4426@cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Xuehui,

From: "dai.xuehui@zte.com.cn" <dai.xuehui@zte.com.cn>
Date: Tuesday, November 27, 2012 7:= 41 PM
To: "Samer Salam (ssalam)"= ; <ssalam@cisco.com>, "T= issa Senevirathne (tsenevir)" <tsenevir@cisco.com>, "sam.aldrin@gmail.com" <sam.aldrin@gmail.com>, = "d3e3e3@gmail.com" <d3e3e3@gmail.com>
Cc: "trill@ietf.org" <tri= ll@ietf.org>
Subject: cc in "draft-ietf-tri= ll-oam-framework-00"


Hi, all trill-oam-framework authors

I have some troubles on understanding = cc function described in section 4.1.1 in draft-ietf-trill-oam-framework-00= , wish you can help me for more clear understanding.

1. 4.1.1 Fault Detection= (Continuity Check)
".....
The proactive fault detection function must detect the following
  types of defects:

  - Loss of continuity (LoC) to one or more remote MEPs
  - Unexpected connectivity between isolated VLANs (mismerge)
  - Unexpected connectivity to one or more remote MEPs
  - Period mis-configuration"

In my mind, maybe the senc= ond and third types of  defects should be defects detected by CV ?

The reason for having these functions part of CC as opposed to CV is p= rimarily to allow for continuous checking of these defects, as they may be = introduced at any point of time in the life-span of a live network, due to = nodes being commissioned/ de-commissioned or VLANs being added/deleted. As long as these types of issues are being m= onitored by CC, the operator will be assured that there is pro-active detec= tion, as opposed to only knowing of the issues when a user complains.
 

2. 4.1.2.1 Forward Defec= t Indication

"......
a simple network comprising of four RBridges connected in tandem: RB1, RB2,= RB3 and RB4. Both RB1 and RB4 are hosting TRILL OAM MEPs, whereas RB2 and = RB3 have MIPs. If the link between RB2 and RB3 fails, then RB2 can send a f= orward defect indication towards RB1 while RB3 sends a forward defect indication towards RB4......"

my question is how to detect the link faliure between = RB2 and RB3 , through TRILL oam? such as one hop TRILL BFD?

The link failure may be detected through a number of mechanisms:

  • By observing the line-protocol state going down on the link.
  • Th= rough some link OAM mechanism such as 802.3 clause 57
  • Through TRILL= BFD as you indicated


3.Does CC should be supported on sections? if it is, h= ow the ingress and egress nickname be set? the same as CV on sections( see = the last paragraph in section 4.2.1.1 in trill-oam-framework)?<= br>

Per draft-ietf-trill-oam-req-04 section 4.3, this is a SHOULD req= uirement. One way to support this, as you mention, is to follow the sa= me nickname scheme as CV on sections.

Regards,
Samer



please correct me if I have some misunderstanding :)


Best Regards,
xuehui


--_000_8F25FF8EA49D164EBE5F1B5AD33F3BC90D81801Axmbalnx13ciscoc_-- From d3e3e3@gmail.com Fri Dec 7 13:48:42 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC7D21F8703 for ; Fri, 7 Dec 2012 13:48:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.407 X-Spam-Level: X-Spam-Status: No, score=-103.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTKLMnZhbkaa for ; Fri, 7 Dec 2012 13:48:41 -0800 (PST) Received: from mail-ia0-f176.google.com (mail-ia0-f176.google.com [209.85.210.176]) by ietfa.amsl.com (Postfix) with ESMTP id CFA8321F86E8 for ; Fri, 7 Dec 2012 13:48:41 -0800 (PST) Received: by mail-ia0-f176.google.com with SMTP id k32so1692179iak.21 for ; Fri, 07 Dec 2012 13:48:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=JGr0E56b0kTZNLJCloZHqslO0qzGxXAb0BTHbsMobZY=; b=DxW05lYiGaSnGdnKQbntCzx300wc1+InZKCvTu2p54Cla5DgnS3EKpF7pLbV8wnIl7 I+iNjGyhxl38tq0r07QU43p24ia89SXRbildtR8vhEIWbBX3W6bR67SM4N23mMKLoEvp AOoI220wF/hT2SPOKhviwtp6xm8UPd43dZGSUsFS2ENP4JJN9/PZBFfPkkA2p2mtMuyN rWLha6YKH4n+HIaUorlRbIigLsBAouvo3rtE7N4YKoSyoZgLGg6jpotDYSXRxmszlSYg BIRd9ukJ8Xz06LDjxwI6M3b6GYoode77vgvVVrnGSLjc+nR0D9BmN5WcSHPxSgGsqhwl NKtw== Received: by 10.50.13.138 with SMTP id h10mr397043igc.55.1354916921371; Fri, 07 Dec 2012 13:48:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.28.209 with HTTP; Fri, 7 Dec 2012 13:48:21 -0800 (PST) From: Donald Eastlake Date: Fri, 7 Dec 2012 16:48:21 -0500 Message-ID: To: trill@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [trill] TRILL WG Secretary Appointment X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 21:48:42 -0000 Hi, Jon Hudson (Brocade), who has been taking minutes for the past several TRILL WG meetings, has been appointed Secretary of the TRILL WG. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From windy_1@skyhighway.com Fri Dec 7 22:19:06 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 661D721F8618 for ; Fri, 7 Dec 2012 22:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.361 X-Spam-Level: X-Spam-Status: No, score=0.361 tagged_above=-999 required=5 tests=[AWL=1.502, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwmx7fQ+q9H6 for ; Fri, 7 Dec 2012 22:19:05 -0800 (PST) Received: from skyhighway.com (skyhighway.com [63.249.82.6]) by ietfa.amsl.com (Postfix) with ESMTP id DEA2021F84DF for ; Fri, 7 Dec 2012 22:19:05 -0800 (PST) Received: from Firefly.skyhighway.com (dsl-63-249-88-160.static.cruzio.com [63.249.88.160]) by skyhighway.com with ESMTP id qB86J0J4091620 for ; Fri, 7 Dec 2012 22:19:00 -0800 (PST) Message-Id: <201212080619.qB86J0J4091620@skyhighway.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 07 Dec 2012 22:19:03 -0800 To: trill@ietf.org From: gayle noble In-Reply-To: References: <4552F0907735844E9204A62BBDD325E732132977@SZXEML507-MBS.china.huawei.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Subject: Re: [trill] TRILL Resilient Distribution Trees, who have read it? X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2012 06:19:06 -0000 (in my opinion)  grammatical corrections to document

Page 20
rbridgeBasePortStpWiringCloset OBJECT-TYPE
The value of this object MUST be retained across reinitializations [re-initializations] of the management system."
 
Page 21
rbridgeConfidenceNative OBJECT-TYPE
The value of this object MUST be retained across reinitializations [re-initializations] of the management system."
 
rbridgeConfidenceStatic OBJECT-TYPE
The value of this object MUST be retained across reinitializations [re-initializations] of the management system."
 
page 28
rbridgeVlanDisableLearning OBJECT-TYPE
The value of this object MUST be retained across reinitializations [re-initializations] of the management system."
 
page 30
rbridgeVlanPortAnnouncing OBJECT-TYPE
The value of this object MUST be retained across reinitializations [re-initializations] of the management system."
 
page 31
As another example,frames [example, frames]discarded due to excessive frame size are reported in the port counter MTU Exceeded Discards in the Bridge MIB.
 
page 32
"The number of times a multidestination [multi destination] frame was dropped on this port because the RPF check failed.
 
page 34
 rbridgeEsadiEnable OBJECT-TYPE
The value of this object MUST be retained across reinitializations [re-initializations] of the management system."
 
page 35
rbridgeEsadiDrbPriority OBJECT-TYPE
The value of this object MUST be retained across reinitializations [re-initializations] of the management system."
 
rbridgeEsadiDrbHoldingTime OBJECT-TYPE
The value of this object MUST be retained across reinitializations [re-initializations] of the management system."
 
page 37
 rbridgeSnoopingPortAddrType OBJECT-TYPE
"The IP address type of an IP multicast router detcted [detected]on this port and VLAN. If only IPv4 router(s) are detected, the value returned in [is]'ipv4'.
 
page 39
rbridgeDtreePriority OBJECT-TYPE
The value of this object MUST be retained across reinitializations [re-initializations] of the management system."
 
page 41
rbridgeTrillMinMtuDesired OBJECT-TYPE
The value of this object MUST be retained across reinitializations [re-initializations] of the management system."
 
 
page 42
rbridgeTrillMaxMtuProbes OBJECT-TYPE
The value of this object MUST be retained across reinitializations [re-initializations] of the management system."

thanks
gayle From windy_1@skyhighway.com Fri Dec 7 22:21:31 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58FE321F862A for ; Fri, 7 Dec 2012 22:21:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.14 X-Spam-Level: X-Spam-Status: No, score=-0.14 tagged_above=-999 required=5 tests=[AWL=1.002, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1h5i1APmcOuv for ; Fri, 7 Dec 2012 22:21:30 -0800 (PST) Received: from skyhighway.com (skyhighway.com [63.249.82.6]) by ietfa.amsl.com (Postfix) with ESMTP id B942421F8618 for ; Fri, 7 Dec 2012 22:21:30 -0800 (PST) Received: from Firefly.skyhighway.com (dsl-63-249-88-160.static.cruzio.com [63.249.88.160]) by skyhighway.com with ESMTP id qB86LUdI094658 for ; Fri, 7 Dec 2012 22:21:30 -0800 (PST) Message-Id: <201212080621.qB86LUdI094658@skyhighway.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 07 Dec 2012 22:21:33 -0800 To: trill@ietf.org From: gayle noble Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Subject: [trill] I-D Action: draft-ietf-trill-rbridge-mib-10.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2012 06:21:31 -0000 sorry got wrong header on this in last email - too much Dr. Who tonight
(in my opinion) grammatical corrections to document

Page 20
rbridgeBasePortStpWiringCloset OBJECT-TYPE
The value of this object MUST be retained across reinitializations [re-initializations] of the management system."
 
Page 21
rbridgeConfidenceNative OBJECT-TYPE
The value of this object MUST be retained across reinitializations [re-initializations] of the management system."
 
rbridgeConfidenceStatic OBJECT-TYPE
The value of this object MUST be retained across reinitializations [re-initializations] of the management system."
 
page 28
rbridgeVlanDisableLearning OBJECT-TYPE
The value of this object MUST be retained across reinitializations [re-initializations] of the management system."
 
page 30
rbridgeVlanPortAnnouncing OBJECT-TYPE
The value of this object MUST be retained across reinitializations [re-initializations] of the management system."
 
page 31
As another example,frames [example, frames]discarded due to excessive frame size are reported in the port counter MTU Exceeded Discards in the Bridge MIB.
 
page 32
"The number of times a multidestination [multi destination] frame was dropped on this port because the RPF check failed.
 
page 34
 rbridgeEsadiEnable OBJECT-TYPE
The value of this object MUST be retained across reinitializations [re-initializations] of the management system."
 
page 35
rbridgeEsadiDrbPriority OBJECT-TYPE
The value of this object MUST be retained across reinitializations [re-initializations] of the management system."
 
rbridgeEsadiDrbHoldingTime OBJECT-TYPE
The value of this object MUST be retained across reinitializations [re-initializations] of the management system."
 
page 37
 rbridgeSnoopingPortAddrType OBJECT-TYPE
"The IP address type of an IP multicast router detcted [detected]on this port and VLAN. If only IPv4 router(s) are detected, the value returned in [is]'ipv4'.
 
page 39
rbridgeDtreePriority OBJECT-TYPE
The value of this object MUST be retained across reinitializations [re-initializations] of the management system."
 
page 41
rbridgeTrillMinMtuDesired OBJECT-TYPE
The value of this object MUST be retained across reinitializations [re-initializations] of the management system."
 
 
page 42
rbridgeTrillMaxMtuProbes OBJECT-TYPE
The value of this object MUST be retained across reinitializations [re-initializations] of the management system."

thanks
gayle From d3e3e3@gmail.com Sat Dec 8 14:12:18 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A58E721F84C2 for ; Sat, 8 Dec 2012 14:12:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.42 X-Spam-Level: X-Spam-Status: No, score=-103.42 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gYVuopg0Hbu for ; Sat, 8 Dec 2012 14:12:17 -0800 (PST) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by ietfa.amsl.com (Postfix) with ESMTP id D6E5421F84B6 for ; Sat, 8 Dec 2012 14:12:17 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id qd14so4790699ieb.34 for ; Sat, 08 Dec 2012 14:12:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=GHFO0dKoscNkziBB9zX9XW8Q/zN5Is3/xzS57yQkUn8=; b=tOM/yHLLJcanL0LUEFMqPennw18VOu4P4Eb86rdFTqhWuyf6bBSbZGhs+jlnddoQgq RDCV9vxcDH/tPFFhpK8XNiG1ldr9Gdyboc4jBuEYFX+SXArRHZTSSJLFOdaeeVyoa7pP wEmmBedA5Vv4409Q2+9KlFdeWh2c7MDD5iQXD/Shsz4Gsldisk5ZCzUhHBX/RMuOlKDw 66ZJ9nKeiRMEURE6g3pFUC9OklIgJcAhJnQKrMpSfoDafTVBeXjIhFd/x92goyQAmDel 0SOUsEpaG3iyvXklCGEQQ0rd4/YhXG/NjM62kqz3RdIguWL/5arbvWdK0WT72RNN3rA1 VMOQ== Received: by 10.50.195.168 with SMTP id if8mr2612267igc.71.1355004737344; Sat, 08 Dec 2012 14:12:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.28.209 with HTTP; Sat, 8 Dec 2012 14:11:56 -0800 (PST) In-Reply-To: <201212080621.qB86LUdI094658@skyhighway.com> References: <201212080621.qB86LUdI094658@skyhighway.com> From: Donald Eastlake Date: Sat, 8 Dec 2012 17:11:56 -0500 Message-ID: To: gayle noble Content-Type: text/plain; charset=ISO-8859-1 Cc: trill@ietf.org Subject: Re: [trill] I-D Action: draft-ietf-trill-rbridge-mib-10.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2012 22:12:18 -0000 Hi Gayle, Thanks for these editorial suggestions. This draft is currently in the hands of the RFC Editor to whom I will forward these suggestions. Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Sat, Dec 8, 2012 at 1:21 AM, gayle noble wrote: > sorry got wrong header on this in last email - too much Dr. Who tonight > (in my opinion) grammatical corrections to document > > Page 20 > rbridgeBasePortStpWiringCloset OBJECT-TYPE > The value of this object MUST be retained across reinitializations > [re-initializations] of the management system." > > Page 21 > rbridgeConfidenceNative OBJECT-TYPE > The value of this object MUST be retained across reinitializations > [re-initializations] of the management system." > > rbridgeConfidenceStatic OBJECT-TYPE > The value of this object MUST be retained across reinitializations > [re-initializations] of the management system." > > page 28 > rbridgeVlanDisableLearning OBJECT-TYPE > The value of this object MUST be retained across reinitializations > [re-initializations] of the management system." > > page 30 > rbridgeVlanPortAnnouncing OBJECT-TYPE > The value of this object MUST be retained across reinitializations > [re-initializations] of the management system." > > page 31 > As another example,frames [example, frames]discarded due to excessive frame > size are reported in the port counter MTU Exceeded Discards in the Bridge > MIB. > > page 32 > "The number of times a multidestination [multi destination] frame was > dropped on this port because the RPF check failed. > > page 34 > rbridgeEsadiEnable OBJECT-TYPE > The value of this object MUST be retained across reinitializations > [re-initializations] of the management system." > > page 35 > rbridgeEsadiDrbPriority OBJECT-TYPE > The value of this object MUST be retained across reinitializations > [re-initializations] of the management system." > > rbridgeEsadiDrbHoldingTime OBJECT-TYPE > The value of this object MUST be retained across reinitializations > [re-initializations] of the management system." > > page 37 > rbridgeSnoopingPortAddrType OBJECT-TYPE > "The IP address type of an IP multicast router detcted [detected]on this > port and VLAN. If only IPv4 router(s) are detected, the value returned in > [is]'ipv4'. > > page 39 > rbridgeDtreePriority OBJECT-TYPE > The value of this object MUST be retained across reinitializations > [re-initializations] of the management system." > > page 41 > rbridgeTrillMinMtuDesired OBJECT-TYPE > The value of this object MUST be retained across reinitializations > [re-initializations] of the management system." > > > page 42 > rbridgeTrillMaxMtuProbes OBJECT-TYPE > The value of this object MUST be retained across reinitializations > [re-initializations] of the management system." > > thanks > gayle > > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill > From tsenevir@cisco.com Sat Dec 8 14:31:43 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0A4021F8464 for ; Sat, 8 Dec 2012 14:31:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.497 X-Spam-Level: X-Spam-Status: No, score=-8.497 tagged_above=-999 required=5 tests=[AWL=2.102, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPq-+mkbNl9a for ; Sat, 8 Dec 2012 14:31:43 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 0F22421F8455 for ; Sat, 8 Dec 2012 14:31:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1023; q=dns/txt; s=iport; t=1355005903; x=1356215503; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=KZP0CUbUmdGe4Se57rs4vxpIKYvJITzQZi2xz+yNhI0=; b=PaYsyiBFvbwYs6uIUL7fm/3S7/enJ0TQELZfBMXu3qdynldPg8EeroI1 A4Uzh5iSTzFWaij6FdAi76IaGDGv1xWIujR+iytVKgN+S24TpAAaoeBRG 9eJRbThBQDnBya/3Re81Y26WVkQ8r/CFKC4UtZCxPcZRLJf39K9koDywS A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQFAGa+w1CtJV2Y/2dsb2JhbABBA4VwuHIWc4IeAQEBBAEBATc0FwQCAQgOAwQBAQsUCQchBgsUCQgCBAESCId3Aw8MtU4NiVAEi1ZpgRWCTWEDlDCNDYURgnOCIg X-IronPort-AV: E=McAfee;i="5400,1158,6920"; a="150911854" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 08 Dec 2012 22:31:42 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qB8MVg9v029907 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 8 Dec 2012 22:31:42 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.240]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Sat, 8 Dec 2012 16:31:42 -0600 From: "Tissa Senevirathne (tsenevir)" To: Donald Eastlake , "trill@ietf.org" Thread-Topic: [trill] TRILL WG Secretary Appointment Thread-Index: AQHN1MSkb7VB1K5W/kaq5NYh9Y/AFZgPfSCw Date: Sat, 8 Dec 2012 22:31:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.166.230] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [trill] TRILL WG Secretary Appointment X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2012 22:31:43 -0000 Hi Donald I would like to know the following=20 1. Role and responsibilities of the TRILL WG Secretary ? 2. Any precedence in IETF that WG appointing a secretary ?=20 3. What official protocol/charter allows working groups to formally appoint= secretaries ? Thanks Tissa -----Original Message----- From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of D= onald Eastlake Sent: Friday, December 07, 2012 1:48 PM To: trill@ietf.org Subject: [trill] TRILL WG Secretary Appointment Hi, Jon Hudson (Brocade), who has been taking minutes for the past several TRIL= L WG meetings, has been appointed Secretary of the TRILL WG. 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 _______________= ________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill From rdroms@cisco.com Sat Dec 8 14:57:19 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9472E21F8550 for ; Sat, 8 Dec 2012 14:57:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6iZv3YLRNX9j for ; Sat, 8 Dec 2012 14:57:18 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 54E4821F8513 for ; Sat, 8 Dec 2012 14:57:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1372; q=dns/txt; s=iport; t=1355007438; x=1356217038; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=RVmN6pQBHcMJvRM0/LOBL6EKt7wW/3ymmAFmgiZKv3Y=; b=BlLD6qdXa27ExovQ6p7AMasOXvgGZgb3h8CSa8wAKbsSzUsfU44FvruQ rHEgP7P0oOg7GsnZnyRCvH8CfDV8LmFSEpWoHSiLJ//+9gNbfgiXKOsp5 ZQCxJyXiBegj2CK7VxYbn/MBGLL6EGENpRHMra70LiG/Eub7rWxB6wyOy g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0HAE7Ew1CtJXHB/2dsb2JhbABBA4NIuxoWc4IeAQEBAwEBAQE3NAsFBwQCAQgRBAEBHwkHIQYLFAkIAgQOBYd/AwkGDLVQDYlQBItWaYEVgk1hA5QwgVaLN4URgnM X-IronPort-AV: E=McAfee;i="5400,1158,6920"; a="150870073" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 08 Dec 2012 22:57:14 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id qB8MvEbq022755 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 8 Dec 2012 22:57:14 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.238]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Sat, 8 Dec 2012 16:57:14 -0600 From: "Ralph Droms (rdroms)" To: "Tissa Senevirathne (tsenevir)" Thread-Topic: [trill] TRILL WG Secretary Appointment Thread-Index: AQHN1MSmwuAbf/SVK0eCGPTxLzwAdpgP4qKA//+ijtk= Date: Sat, 8 Dec 2012 22:57:13 +0000 Message-ID: <216E7A53-AC07-4072-818F-F6A1E81A88C6@cisco.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Donald Eastlake , "trill@ietf.org" Subject: Re: [trill] TRILL WG Secretary Appointment X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2012 22:57:19 -0000 On Dec 8, 2012, at 5:31 PM, "Tissa Senevirathne (tsenevir)" wrote: > Hi Donald >=20 > I would like to know the following=20 >=20 > 1. Role and responsibilities of the TRILL WG Secretary ? > 2. Any precedence in IETF that WG appointing a secretary ?=20 > 3. What official protocol/charter allows working groups to formally appoi= nt secretaries ? See RFC 2418, section 6.2. - Ralph >=20 > Thanks > Tissa >=20 > -----Original Message----- > From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of= Donald Eastlake > Sent: Friday, December 07, 2012 1:48 PM > To: trill@ietf.org > Subject: [trill] TRILL WG Secretary Appointment >=20 > Hi, >=20 > Jon Hudson (Brocade), who has been taking minutes for the past several TR= ILL WG meetings, has been appointed Secretary of the TRILL WG. >=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 > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com ______________= _________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill From d3e3e3@gmail.com Sat Dec 8 16:49:31 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BAAA21F86AC for ; Sat, 8 Dec 2012 16:49:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.432 X-Spam-Level: X-Spam-Status: No, score=-103.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPZbPrKetkfc for ; Sat, 8 Dec 2012 16:49:29 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 92C2821F861E for ; Sat, 8 Dec 2012 16:49:28 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id z13so3075617iaz.31 for ; Sat, 08 Dec 2012 16:49:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=KSfYWq9vljTGBImbCvIYfo6kWR54m+mZOvECLvl77PM=; b=wQEk826WCb0C5m33jMG8MM36rmeKpX+nTX8UeaaELOHYiRCw/RQm186pzZm0BW4kHq 4OD8jTcgSelUTDw9lrYD4Xx3779BrJhZ1BQ0CocxkEL64DFYkmxV8IT1Ao8q5IO+6ALu 7EkDZOcd4eA2DXe3QBd+gG8jjGSeQlHlfjzOqhO09EmqXGGlZ76+hxA6YJ69315kI0Or cAzgyJzW59DkgDUEPw+1OoPa7BALjsnwm5+TOfRxfGbJPRvCQwaeurpsBA2aAEcp7hel 8HbSyINE33R8cPlEJh1bMKSep5Vl7vt1Ct0R6wxLxyR1SxboDX/Eu6nHrVI5X0HPxNV0 am3A== Received: by 10.42.179.132 with SMTP id bq4mr7861485icb.8.1355014168127; Sat, 08 Dec 2012 16:49:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.28.209 with HTTP; Sat, 8 Dec 2012 16:49:06 -0800 (PST) In-Reply-To: References: From: Donald Eastlake Date: Sat, 8 Dec 2012 19:49:06 -0500 Message-ID: To: "Tissa Senevirathne (tsenevir)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "trill@ietf.org" Subject: Re: [trill] TRILL WG Secretary Appointment X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2012 00:49:31 -0000 Hi Tissa, On Sat, Dec 8, 2012 at 5:31 PM, Tissa Senevirathne (tsenevir) wrote: > Hi Donald > > I would like to know the following > > 1. Role and responsibilities of the TRILL WG Secretary ? I would expect that Jon will continue to take minutes at meetings. > 2. Any precedence in IETF that WG appointing a secretary ? If you read RFC 2418, the basic WG RFC, you would think that it was normal for most WGs to have a Secretary. In fact, it is not particularly common, but there have been WG Secretaries before. Officially, a WG Secretary is appointed by the AD, not the WG. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > 3. What official protocol/charter allows working groups to formally appoint secretaries ? > > Thanks > Tissa > > -----Original Message----- > From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of Donald Eastlake > Sent: Friday, December 07, 2012 1:48 PM > To: trill@ietf.org > Subject: [trill] TRILL WG Secretary Appointment > > Hi, > > Jon Hudson (Brocade), who has been taking minutes for the past several TRILL WG meetings, has been appointed Secretary of the TRILL WG. > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill From narten@us.ibm.com Mon Dec 10 06:29:16 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE3521F8422 for ; Mon, 10 Dec 2012 06:29:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQh-df6dh4Ve for ; Mon, 10 Dec 2012 06:29:16 -0800 (PST) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by ietfa.amsl.com (Postfix) with ESMTP id 081E121F841E for ; Mon, 10 Dec 2012 06:29:15 -0800 (PST) Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 10 Dec 2012 09:29:13 -0500 Received: from d01dlp03.pok.ibm.com (9.56.250.168) by e9.ny.us.ibm.com (192.168.1.109) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 10 Dec 2012 09:29:10 -0500 Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id AD533C90067 for ; Mon, 10 Dec 2012 09:29:09 -0500 (EST) Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id qBAET8UW197636 for ; Mon, 10 Dec 2012 09:29:08 -0500 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id qBAET4xN014024 for ; Mon, 10 Dec 2012 07:29:04 -0700 Received: from cichlid.raleigh.ibm.com ([9.80.11.210]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id qBAET2ul013793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Dec 2012 07:29:03 -0700 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.5/8.12.5) with ESMTP id qBAET1hT002103; Mon, 10 Dec 2012 09:29:01 -0500 Message-Id: <201212101429.qBAET1hT002103@cichlid.raleigh.ibm.com> To: Donald Eastlake In-reply-to: References: Comments: In-reply-to Donald Eastlake message dated "Sat, 08 Dec 2012 19:49:06 -0500." Date: Mon, 10 Dec 2012 09:29:01 -0500 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12121014-7182-0000-0000-000003A92FEA Cc: "Tissa Senevirathne \(tsenevir\)" , "trill@ietf.org" Subject: Re: [trill] TRILL WG Secretary Appointment X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 14:29:16 -0000 > > 2. Any precedence in IETF that WG appointing a secretary ? > If you read RFC 2418, the basic WG RFC, you would think that it was > normal for most WGs to have a Secretary. In fact, it is not > particularly common, but there have been WG Secretaries before. > Officially, a WG Secretary is appointed by the AD, not the WG. Not sure why you say the WG secretary is an AD appointment. It is clearly a WG function that falls under the responsibily of the chairs. And RFC 2418 describes the WG Secretary role as as subsection of 6.1 (WG Chair) saying: > The Chair has the responsibility and the authority to make decisions, > on behalf of the working group, regarding all matters of working > group process and staffing, in conformance with the rules of the > IETF. The AD has the authority and the responsibility to assist in > making those decisions at the request of the Chair or when > circumstances warrant such an intervention. While it would be fine (as appropriate) to consult with the ADs on such (or any) potential appointment, this seems to be a WG chair responsibility. In any case, congratulations Jon! Thomas From windy_1@skyhighway.com Mon Dec 10 08:48:47 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D052621F850A for ; Mon, 10 Dec 2012 08:48:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.374 X-Spam-Level: X-Spam-Status: No, score=-0.374 tagged_above=-999 required=5 tests=[AWL=0.736, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hr0YS4eNdjv1 for ; Mon, 10 Dec 2012 08:48:47 -0800 (PST) Received: from skyhighway.com (skyhighway.com [63.249.82.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5E63D21F8507 for ; Mon, 10 Dec 2012 08:48:47 -0800 (PST) Received: from Firefly.skyhighway.com (dsl-63-249-88-160.static.cruzio.com [63.249.88.160]) by skyhighway.com with ESMTP id qBAGmk2F082124 for ; Mon, 10 Dec 2012 08:48:47 -0800 (PST) Message-Id: <201212101648.qBAGmk2F082124@skyhighway.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 10 Dec 2012 08:48:50 -0800 To: "trill@ietf.org" From: gayle noble In-Reply-To: <201212101429.qBAET1hT002103@cichlid.raleigh.ibm.com> References: <201212101429.qBAET1hT002103@cichlid.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [trill] TRILL WG Secretary Appointment X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 16:48:47 -0000 >In any case, congratulations Jon! >Thomas Yes! Congratulation Jon! gayle From agmalis@gmail.com Mon Dec 10 10:25:00 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4FE821F8507 for ; Mon, 10 Dec 2012 10:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HpDMjf4k6jR for ; Mon, 10 Dec 2012 10:25:00 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0346721F8506 for ; Mon, 10 Dec 2012 10:24:59 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so10551348ieb.31 for ; Mon, 10 Dec 2012 10:24:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=GWGSPMuP8+o2JqgVK59ud+gnqMmNR7MzcU3NEFpLG94=; b=nUbj+QJyUeBXrg9vKTaNtjAlw3H5lUOTCVVJgmoJ6xODb8X4s9R1rR1xVioblVWB9H HbT3vaJm4IJ9zVZrKKirwFnk+HC9vXiFmTXJ8ssEFBUXWFduCLQ6ySheDBPOPt/jPJvK 61iWkWjVTMAIG+8tD28J8+SHFKlTmjvhwgHfnJb3I9/S3h/5zvV8I0FG8ga+s80cBeHG 8DPKe7E1iwTX4XDeYLQ6EGCS/kZlkRT4B/WkxC1pZXfn8efEIkKkSAIrC8cSKNEQ7atU 3/cmGNaFkEeLsQC6GCydFE7VcJvcUhqsQTW6fpE2VHxBFIv2MMUMPjvFbo3Go8u862nE j5eA== Received: by 10.43.4.70 with SMTP id ob6mr11969116icb.56.1355163899608; Mon, 10 Dec 2012 10:24:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.35.195 with HTTP; Mon, 10 Dec 2012 10:24:38 -0800 (PST) In-Reply-To: References: From: "Andrew G. Malis" Date: Mon, 10 Dec 2012 13:24:38 -0500 Message-ID: To: "Tissa Senevirathne (tsenevir)" Content-Type: multipart/alternative; boundary=bcaec50fe227d9404704d083aee8 Cc: Donald Eastlake , "trill@ietf.org" Subject: Re: [trill] TRILL WG Secretary Appointment X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 18:25:00 -0000 --bcaec50fe227d9404704d083aee8 Content-Type: text/plain; charset=ISO-8859-1 Tissa, To answer your second question, at the very least both the PWE3 and MPLS WGs have WG secretaries. In the PWE3 case, our secretary is responsible for the meeting agenda, presentation collection and uploading, and meeting minutes (and his service is greatly appreciated!). We also have an ongoing volunteer jabber scribe (different person from the secretary). Cheers, Andy (PWE3 co-chair) On Sat, Dec 8, 2012 at 5:31 PM, Tissa Senevirathne (tsenevir) < tsenevir@cisco.com> wrote: > Hi Donald > > I would like to know the following > > 1. Role and responsibilities of the TRILL WG Secretary ? > 2. Any precedence in IETF that WG appointing a secretary ? > 3. What official protocol/charter allows working groups to formally > appoint secretaries ? > > Thanks > Tissa > > -----Original Message----- > From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of > Donald Eastlake > Sent: Friday, December 07, 2012 1:48 PM > To: trill@ietf.org > Subject: [trill] TRILL WG Secretary Appointment > > Hi, > > Jon Hudson (Brocade), who has been taking minutes for the past several > TRILL WG meetings, has been appointed Secretary of the TRILL WG. > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com_______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill > --bcaec50fe227d9404704d083aee8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Tissa,

To answer your second question, at the very least both the PW= E3 and MPLS WGs have WG secretaries. In the PWE3 case, our secretary is res= ponsible for the meeting agenda, presentation collection and uploading, and= meeting minutes (and his service is greatly appreciated!). We also have an= ongoing volunteer jabber scribe (different person from the secretary).

Cheers,
Andy (PWE3 co-chair)


<= div class=3D"gmail_quote">On Sat, Dec 8, 2012 at 5:31 PM, Tissa Senevirathn= e (tsenevir) <tsenevir@cisco.com> wrote:
Hi Donald

I would like to know the following

1. Role and responsibilities of the TRILL WG Secretary ?
2. Any precedence in IETF that WG appointing a secretary ?
3. What official protocol/charter allows working groups to formally appoint= secretaries ?

Thanks
Tissa

-----Original Message-----
From: trill-bounces@ietf.org = [mailto:trill-bounces@ietf.org] On Behalf Of Donald Eastlake
Sent: Friday, December 07, 2012 1:48 PM
To: trill@ietf.org
Subject: [trill] TRILL WG Secretary Appointment

Hi,

Jon Hudson (Brocade), who has been taking minutes for the past several TRIL= L WG meetings, has been appointed Secretary of the TRILL WG.

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 ______________________________________________= _
trill mailing list
trill@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/trill
_______________________________________________
trill mailing list
trill@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/trill

--bcaec50fe227d9404704d083aee8-- From liyizhou@huawei.com Mon Dec 10 16:35:42 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C00BC21F86F9 for ; Mon, 10 Dec 2012 16:35:42 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zs3YB5bTB7SJ for ; Mon, 10 Dec 2012 16:35:42 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8FE21F86F8 for ; Mon, 10 Dec 2012 16:35:41 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANR18175; Tue, 11 Dec 2012 00:35:40 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 11 Dec 2012 00:34:55 +0000 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 11 Dec 2012 00:35:37 +0000 Received: from l63746 (10.138.122.43) by smtpscn.huawei.com (10.82.67.155) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 11 Dec 2012 08:35:30 +0800 From: Yizhou Li To: "'gayle noble'" , References: <201212101429.qBAET1hT002103@cichlid.raleigh.ibm.com> <201212101648.qBAGmk2F082124@skyhighway.com> In-Reply-To: <201212101648.qBAGmk2F082124@skyhighway.com> Date: Tue, 11 Dec 2012 08:35:29 +0800 Message-ID: <07c201cdd737$6c7c48f0$4574dad0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3W9jv3ODe3qwPzQt2OqqpiK/bWgAAQREXQ Content-Language: zh-cn X-Originating-IP: [10.138.122.43] X-CFilter-Loop: Reflected Subject: Re: [trill] TRILL WG Secretary Appointment X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 00:35:42 -0000 Yes. And also thanks for Jon's contribution. Yizhou -----Original Message----- From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of gayle noble Sent: Tuesday, December 11, 2012 12:49 AM To: trill@ietf.org Subject: Re: [trill] TRILL WG Secretary Appointment >In any case, congratulations Jon! >Thomas Yes! Congratulation Jon! gayle _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill From naveen@broadcom.com Mon Dec 10 23:09:45 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4930121F869B for ; Mon, 10 Dec 2012 23:09:45 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Btsy5u97Aol for ; Mon, 10 Dec 2012 23:09:44 -0800 (PST) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDD621F86FE for ; Mon, 10 Dec 2012 23:09:44 -0800 (PST) Received: from [10.16.192.232] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Mon, 10 Dec 2012 23:06:44 -0800 X-Server-Uuid: 4500596E-606A-40F9-852D-14843D8201B2 Received: from SJEXCHCAS04.corp.ad.broadcom.com (10.16.203.11) by SJEXCHHUB02.corp.ad.broadcom.com (10.16.192.232) with Microsoft SMTP Server (TLS) id 8.2.247.2; Mon, 10 Dec 2012 23:09:34 -0800 Received: from SJEXCHMB06.corp.ad.broadcom.com ( [fe80::65ea:1de7:41c4:e948]) by SJEXCHCAS04.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Mon, 10 Dec 2012 23:09:13 -0800 From: "Naveen Nimmu" To: "Thomas Narten" , "Donald Eastlake" Thread-Topic: [trill] TRILL WG Secretary Appointment Thread-Index: AQHN1MSk3vVwAnKc+UGMgH4UWl8JP5gQBCmAgAAmZQCAAndqgIAAkNfg Date: Tue, 11 Dec 2012 07:09:13 +0000 Message-ID: <8FCD488658FD4040A3A2279ABA0AD4831BD1C67B@SJEXCHMB06.corp.ad.broadcom.com> References: <201212101429.qBAET1hT002103@cichlid.raleigh.ibm.com> In-Reply-To: <201212101429.qBAET1hT002103@cichlid.raleigh.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] MIME-Version: 1.0 X-WSS-ID: 7CD8040E3R018114733-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "Tissa Senevirathne \(tsenevir\)" , "trill@ietf.org" Subject: Re: [trill] TRILL WG Secretary Appointment X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 07:09:45 -0000 The more the merrier. Congratulations Jon. naveen -----Original Message----- From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of T= homas Narten Sent: Monday, December 10, 2012 7:59 PM To: Donald Eastlake Cc: Tissa Senevirathne (tsenevir); trill@ietf.org Subject: Re: [trill] TRILL WG Secretary Appointment > > 2. Any precedence in IETF that WG appointing a secretary ? > If you read RFC 2418, the basic WG RFC, you would think that it was > normal for most WGs to have a Secretary. In fact, it is not > particularly common, but there have been WG Secretaries before. > Officially, a WG Secretary is appointed by the AD, not the WG. Not sure why you say the WG secretary is an AD appointment. It is clearly a WG function that falls under the responsibily of the chairs. And RFC 2418 describes the WG Secretary role as as subsection of 6.1 (WG Chair) saying: > The Chair has the responsibility and the authority to make decisions, > on behalf of the working group, regarding all matters of working > group process and staffing, in conformance with the rules of the > IETF. The AD has the authority and the responsibility to assist in > making those decisions at the request of the Chair or when > circumstances warrant such an intervention. While it would be fine (as appropriate) to consult with the ADs on such (or any) potential appointment, this seems to be a WG chair responsibility. In any case, congratulations Jon! Thomas _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill From iesg-secretary@ietf.org Tue Dec 11 06:58:29 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D880B21F8715; Tue, 11 Dec 2012 06:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QW9BhAgQ7YTS; Tue, 11 Dec 2012 06:58:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8D821F8444; Tue, 11 Dec 2012 06:58:29 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121211145829.3754.44253.idtracker@ietfa.amsl.com> Date: Tue, 11 Dec 2012 06:58:29 -0800 Cc: trill@ietf.org Subject: [trill] Last Call: (Requirements for Operations, Administration and Maintenance (OAM) in TRILL (Transparent Interconnection of Lots of Links)) to Informational RFC X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 14:58:30 -0000 The IESG has received a request from the Transparent Interconnection of Lots of Links WG (trill) to consider the following document: - 'Requirements for Operations, Administration and Maintenance (OAM) in TRILL (Transparent Interconnection of Lots of Links)' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-01-03. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract OAM (Operations, Administration and Maintenance) is a general term used to identify functions and toolsets to troubleshoot and monitor networks. This document presents, OAM Requirements applicable to TRILL. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-trill-oam-req/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-trill-oam-req/ballot/ No IPR declarations have been submitted directly on this I-D. From radiaperlman@gmail.com Tue Dec 11 12:53:08 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F7111E8097 for ; Tue, 11 Dec 2012 12:53:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFrdt1gad90K for ; Tue, 11 Dec 2012 12:53:07 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1488421F84D9 for ; Tue, 11 Dec 2012 12:53:06 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so4470288vbb.31 for ; Tue, 11 Dec 2012 12:53:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=95341daxn6WohJ/PSFkELGXz9bOZN6lNQEiAprXHWc0=; b=gW5EWHVHMf42PiISRh114iNc78I94EtQ53NgUHF9/xJUIfsHiIuqcfp5PfBowozxo6 pF/ZIV7uytgFrgr9Lt97YKB8RgbcGIGi0KxWG5uylLzHJEYvTrORQLIKgvTYSdLnU0zu xz+pM0VwKvel0YGDm/HDNS9qaJIDxmJHm5frMOGpWIHRtPlR6Av5CDbPfNxMvSTvECEm ueTElKMAyFLqZlV+NolS3SEkrrClcScXGWxTsW2PXKFGptApDE4s53mUhU0CUkKQr+tX eLymM+5nQanamXndMmhiunOSN9oNgTTLUsCP+tSspDbpIMTfxH6SHAeTPz1pfB2m1Fvt Grug== MIME-Version: 1.0 Received: by 10.52.92.144 with SMTP id cm16mr10563364vdb.36.1355259186515; Tue, 11 Dec 2012 12:53:06 -0800 (PST) Received: by 10.58.207.138 with HTTP; Tue, 11 Dec 2012 12:53:06 -0800 (PST) Date: Tue, 11 Dec 2012 12:53:06 -0800 Message-ID: From: Radia Perlman To: trill@ietf.org Content-Type: multipart/alternative; boundary=20cf307cff96640dc504d099de76 Subject: [trill] Thoughts on active-active edge X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 20:53:08 -0000 --20cf307cff96640dc504d099de76 Content-Type: text/plain; charset=ISO-8859-1 I'm not too happy about any of the proposed solutions to the active-active edge issue, and wondering if there might be a simpler approach. To review the problem: Suppose R1, R2, and R3 are all attached to a set of endnodes (say, through a hypervisor). Let's say "E" is one of the endnodes multihomed through R1, R2, R3. Let's say "R8" is a distant RBridge (one several hops away from R1, R2, and R3). a) If R1, R2, and R3 use their own nickname when encapsulating a frame from E, then R8 will see frequent changes of E's location (between R1, R2, and R3). Furthermore, it would be nice if the path from R8 to E could go via the shortest path (if, for instance, R2 is much closer to R8 than R1). b) If R1, R2, and R3 use a pseudonode nickname (say P) for all the multihomed endnodes, then the RPF check doesn't work when the "wrong" RBridge injects the encapsuated packet into the campus. (the tree will have only one of R1, R2, or R3 attached to the pseudonode, say R2, so when R2 injects using the pseuodnode as ingress nickname, the RPF check will work, but it will not work if R1 or R3 inject). -------------- So...this might have been discussed before, but it might not hurt to look at it with fresh eyes again. ******************* Proposed rule: R1, R2, and R3 should use the pseudonode nickname when encapsulating unicast, but use their own nickname when encapsulating multidestination. *********************** Result: R8 will see endnode changes for E, but not very frequent; R8 will only see changes when traffic from E alternates between multidestination and unicast. Question: Are perceived endnode moves a problem? Why? If endnode changes are, for some reason, a problem, we could have R1, R2, and R3 announce in LSPs, that they are attached to pseudonode P as an active/active group, and therefore, endnode moves between P and anything in the set {R1, R2, R3} should not raise alarms. Better yet, would be to say if endnode E is attached to P, then don't move it to {R1, R2, or R3}. Radia --20cf307cff96640dc504d099de76 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm not too happy about any of the proposed solutions to the active-act= ive edge issue, and wondering if there might be a simpler approach.
To review the problem:

Suppose R1, R2,= and R3 are all attached to a set of endnodes (say, through a hypervisor). = =A0Let's say "E" is one of the endnodes multihomed through R1= , R2, R3. =A0Let's say "R8" is a distant RBridge (one several= hops away from R1, R2, and R3).

a) If R1, R2, and R3 use their own nickname when encaps= ulating a frame from E, then R8 will see frequent changes of E's locati= on (between R1, R2, and R3). =A0Furthermore, it would be nice if the path f= rom R8 to E could go via the shortest path (if, for instance, R2 is much cl= oser to R8 than R1).

b) If R1, R2, and R3 use a pseudonode nickname (say P) = for all the multihomed endnodes, then the RPF check doesn't work when t= he "wrong" RBridge injects the encapsuated packet into the campus= . =A0(the tree will have only one of R1, R2, or R3 attached to the pseudono= de, say R2, so when R2 injects using the pseuodnode as ingress nickname, th= e RPF check will work, but it will not work if R1 or R3 inject).

--------------

So...this might= have been discussed before, but it might not hurt to look at it with fresh= eyes again.



*******= ************
Proposed rule: R1, R2, and R3 should use the pseudonode nickname when = encapsulating unicast, but use their own nickname when encapsulating multid= estination.
***********************

Result: =A0R8 will see endnode changes for E, but not very frequent; =A0R8 = will only see changes when traffic from E alternates between multidestinati= on and unicast. =A0

Question: Are perceived endnod= e moves a problem? =A0Why?

If endnode changes are, for some reason, a problem, we = could have R1, R2, and R3 announce in LSPs, that they are attached to pseud= onode P as an active/active group, and therefore, endnode moves between P a= nd anything in the set {R1, R2, R3} should not raise alarms. =A0Better yet,= would be to say if endnode E is attached to P, then don't move it to {= R1, R2, or R3}.

Radia
--20cf307cff96640dc504d099de76-- From windy_1@skyhighway.com Tue Dec 11 16:43:46 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1053E11E80AE; Tue, 11 Dec 2012 16:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.537 X-Spam-Level: X-Spam-Status: No, score=-0.537 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WyYB26L8Lb1R; Tue, 11 Dec 2012 16:43:45 -0800 (PST) Received: from skyhighway.com (skyhighway.com [63.249.82.6]) by ietfa.amsl.com (Postfix) with ESMTP id A008711E80A3; Tue, 11 Dec 2012 16:43:45 -0800 (PST) Received: from Firefly.skyhighway.com (dsl-63-249-88-160.static.cruzio.com [63.249.88.160]) by skyhighway.com with ESMTP id qBC0hjW7067663; Tue, 11 Dec 2012 16:43:45 -0800 (PST) Message-Id: <201212120043.qBC0hjW7067663@skyhighway.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 11 Dec 2012 16:43:58 -0800 To: ietf@ietf.org, IETF-Announce , trill@ietf.org From: gayle noble In-Reply-To: <20121211145829.3754.44253.idtracker@ietfa.amsl.com> References: <20121211145829.3754.44253.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Subject: Re: [trill] Last Call: (Requirements for Operations, Administration and Maintenance (OAM) in TRILL (Transparent Interconnection of Lots of Links)) to Informational RFC X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 00:43:46 -0000 Very well written!! No spelling errors! No grammatical errors! Only one sentence, in my opinion,  could be rephrased for clarity
4.1. Data Plane
 RBridges MUST have the ability to identify OAM frames destined for them or which require processing by the OAM plane from normal data frames.
[Might be clearer if it was [RBridges MUST have the ability to identify OAM frames from normal data frames when the OAM frames are destined for them or require processing by the OAM plane.]]

gayle From sunny.rajagopalan@us.ibm.com Tue Dec 11 16:44:56 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E02011E80AE for ; Tue, 11 Dec 2012 16:44:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AbaVSOB7gysA for ; Tue, 11 Dec 2012 16:44:55 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by ietfa.amsl.com (Postfix) with ESMTP id 75F7C21E80AF for ; Tue, 11 Dec 2012 16:44:55 -0800 (PST) Received: from /spool/local by e31.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 11 Dec 2012 17:44:54 -0700 Received: from d03dlp01.boulder.ibm.com (9.17.202.177) by e31.co.us.ibm.com (192.168.1.131) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 11 Dec 2012 17:23:46 -0700 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id B62361FF0041 for ; Tue, 11 Dec 2012 17:23:26 -0700 (MST) Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id qBC0NXg1298922 for ; Tue, 11 Dec 2012 17:23:33 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id qBC0NX7D016519 for ; Tue, 11 Dec 2012 17:23:33 -0700 Received: from d03nm127.boulder.ibm.com ([9.16.16.115]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id qBC0NXfY016515 for ; Tue, 11 Dec 2012 17:23:33 -0700 In-Reply-To: References: To: Radia Perlman MIME-Version: 1.0 X-KeepSent: A64C269F:4ABA3691-87257AD2:00001E14; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3FP2 SHF22 July 19, 2012 Message-ID: From: Sunny Rajagopalan Date: Tue, 11 Dec 2012 16:23:30 -0800 X-MIMETrack: Serialize by Router on D03NM127/03/M/IBM(Release 8.5.3FP2 ZX853FP2HF2|October 8, 2012) at 12/11/2012 17:23:32, Serialize complete at 12/11/2012 17:23:32 Content-Type: multipart/alternative; boundary="=_alternative 0002264988257AD2_=" X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12121200-7282-0000-0000-000011F801CC Cc: trill@ietf.org Subject: Re: [trill] Thoughts on active-active edge X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 00:44:56 -0000 This is a multipart message in MIME format. --=_alternative 0002264988257AD2_= Content-Type: text/plain; charset="US-ASCII" Hi, Radia I like this idea a lot better than the other proposals floating around. The +ve is that it can be done with today's ISIS. The -ve is that you'll need a minor hardware change - today's hardware generally doesn't have the ability to use a different source rbridge depending on whether the packet is unicast or multicast. ISIS on an rbridge that is emulating a pseudonode nickname can send out mac reachability information for endnodes attached to it, associating the mac addresses with the pseudonode nickname. Any multicast group with local receivers must also be advertised as belonging to the pseudonode. At the other end, hardware already has the ability to "fix" mac entries so that they don't get rewritten when new information comes in. I do think this is necessary, because I believe we will see mac flips not just in the unicast-multicast interleave case, but also in the pure multicast case (load balancing could be using the layer 4 header, and that could cause different links to be used, even when the smac and dmac stays the same). This means, of course, that if the mac moves to an rbridge that's not part of the pseudonode group then the new rbridge will have to send out an update so that everyone else can fix up their entries and remove the "fixed" property from the entry in hardware. The approaches we've seen so far are complex, require the maintenance of multiple trees, use up the nickname space, and have constraints in the external non-trill topologies that can be used. This approach has none of the problems, and has my vote. -- Sunny From: Radia Perlman To: trill@ietf.org, Date: 12/11/2012 12:54 PM Subject: [trill] Thoughts on active-active edge Sent by: trill-bounces@ietf.org I'm not too happy about any of the proposed solutions to the active-active edge issue, and wondering if there might be a simpler approach. To review the problem: Suppose R1, R2, and R3 are all attached to a set of endnodes (say, through a hypervisor). Let's say "E" is one of the endnodes multihomed through R1, R2, R3. Let's say "R8" is a distant RBridge (one several hops away from R1, R2, and R3). a) If R1, R2, and R3 use their own nickname when encapsulating a frame from E, then R8 will see frequent changes of E's location (between R1, R2, and R3). Furthermore, it would be nice if the path from R8 to E could go via the shortest path (if, for instance, R2 is much closer to R8 than R1). b) If R1, R2, and R3 use a pseudonode nickname (say P) for all the multihomed endnodes, then the RPF check doesn't work when the "wrong" RBridge injects the encapsuated packet into the campus. (the tree will have only one of R1, R2, or R3 attached to the pseudonode, say R2, so when R2 injects using the pseuodnode as ingress nickname, the RPF check will work, but it will not work if R1 or R3 inject). -------------- So...this might have been discussed before, but it might not hurt to look at it with fresh eyes again. ******************* Proposed rule: R1, R2, and R3 should use the pseudonode nickname when encapsulating unicast, but use their own nickname when encapsulating multidestination. *********************** Result: R8 will see endnode changes for E, but not very frequent; R8 will only see changes when traffic from E alternates between multidestination and unicast. Question: Are perceived endnode moves a problem? Why? If endnode changes are, for some reason, a problem, we could have R1, R2, and R3 announce in LSPs, that they are attached to pseudonode P as an active/active group, and therefore, endnode moves between P and anything in the set {R1, R2, R3} should not raise alarms. Better yet, would be to say if endnode E is attached to P, then don't move it to {R1, R2, or R3}. Radia_______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill --=_alternative 0002264988257AD2_= Content-Type: text/html; charset="US-ASCII" Hi, Radia
I like this idea a lot better than the other proposals floating around. The +ve is that it can be done with today's ISIS. The -ve is that you'll need a minor hardware change -  today's hardware generally doesn't have the ability to use a different source rbridge depending on whether the packet is unicast or multicast.

ISIS on  an rbridge that is emulating a pseudonode nickname can send out mac reachability information for endnodes attached to it, associating the mac addresses with the pseudonode nickname. Any multicast group with local receivers must also be advertised as belonging to the pseudonode.

At the other end, hardware already has the ability to "fix" mac entries so that they don't get rewritten when new information comes in. I do think this is necessary, because I believe we will see mac flips not just in the unicast-multicast interleave case, but also in the pure multicast case (load balancing could be using the layer 4 header, and that could cause different links to be used, even when the smac and dmac stays the same).

This means, of course, that if the mac moves to an rbridge that's not part of the pseudonode group then the new rbridge will have to send out an update so that everyone else can fix up their entries and remove the "fixed" property from the entry in hardware.

The approaches we've seen so far are complex, require the maintenance of multiple trees, use up the nickname space, and have constraints in the external non-trill topologies that can be used. This approach has none of the problems, and has my vote.
--
Sunny




From:        Radia Perlman <radiaperlman@gmail.com>
To:        trill@ietf.org,
Date:        12/11/2012 12:54 PM
Subject:        [trill] Thoughts on active-active edge
Sent by:        trill-bounces@ietf.org



I'm not too happy about any of the proposed solutions to the active-active edge issue, and wondering if there might be a simpler approach.

To review the problem:

Suppose R1, R2, and R3 are all attached to a set of endnodes (say, through a hypervisor).  Let's say "E" is one of the endnodes multihomed through R1, R2, R3.  Let's say "R8" is a distant RBridge (one several hops away from R1, R2, and R3).

a) If R1, R2, and R3 use their own nickname when encapsulating a frame from E, then R8 will see frequent changes of E's location (between R1, R2, and R3).  Furthermore, it would be nice if the path from R8 to E could go via the shortest path (if, for instance, R2 is much closer to R8 than R1).

b) If R1, R2, and R3 use a pseudonode nickname (say P) for all the multihomed endnodes, then the RPF check doesn't work when the "wrong" RBridge injects the encapsuated packet into the campus.  (the tree will have only one of R1, R2, or R3 attached to the pseudonode, say R2, so when R2 injects using the pseuodnode as ingress nickname, the RPF check will work, but it will not work if R1 or R3 inject).

--------------

So...this might have been discussed before, but it might not hurt to look at it with fresh eyes again.



*******************
Proposed rule: R1, R2, and R3 should use the pseudonode nickname when encapsulating unicast, but use their own nickname when encapsulating multidestination.
***********************

Result:  R8 will see endnode changes for E, but not very frequent;  R8 will only see changes when traffic from E alternates between multidestination and unicast.  

Question: Are perceived endnode moves a problem?  Why?

If endnode changes are, for some reason, a problem, we could have R1, R2, and R3 announce in LSPs, that they are attached to pseudonode P as an active/active group, and therefore, endnode moves between P and anything in the set {R1, R2, R3} should not raise alarms.  Better yet, would be to say if endnode E is attached to P, then don't move it to {R1, R2, or R3}.

Radia_______________________________________________
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill
--=_alternative 0002264988257AD2_=-- From radiaperlman@gmail.com Tue Dec 11 16:57:09 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6DE21F856E for ; Tue, 11 Dec 2012 16:57:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43WqFUYzF++V for ; Tue, 11 Dec 2012 16:57:08 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC2521F856D for ; Tue, 11 Dec 2012 16:57:08 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so99679vbb.31 for ; Tue, 11 Dec 2012 16:57:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zc250j3w8da7n2fDaGrsDEz3lXPJuzMr+y6VQN001nI=; b=Kk9827Nfs3toR062RsFvMa8vPaak5QFRxe1fvF5gOuitY7jQwVVYalXQP06hEV3z8d zQtnRGUXXJQGm5uzrbj3KCMMlkXV9HPsEiKvLg6pOCnNh2trpU+ueBJRq+ydCsRoTMG1 nNShCti3YyhcTSn0y7Dn9PtSqXCSaXheUG/FuvI2qvoexRsnkIpzK/K8foUWOoAbf0q4 TSVlNnFWMTmEx5JdvD+seXjZlk7g+aK7ca+MoOZBh26A3WfOf/qoDI6k681Dp7ZZqAoO 737mRdkdgdjHD+hqZRq8gknMtXeKgrPm67znfTDTlkQnDQ8kSHXZ1PctyeGVfGgs+94g WF+Q== MIME-Version: 1.0 Received: by 10.58.248.41 with SMTP id yj9mr12799955vec.29.1355273827730; Tue, 11 Dec 2012 16:57:07 -0800 (PST) Received: by 10.58.207.138 with HTTP; Tue, 11 Dec 2012 16:57:07 -0800 (PST) In-Reply-To: References: Date: Tue, 11 Dec 2012 16:57:07 -0800 Message-ID: From: Radia Perlman To: Sunny Rajagopalan Content-Type: multipart/alternative; boundary=047d7bf0d0b213457604d09d47b7 Cc: trill@ietf.org Subject: Re: [trill] Thoughts on active-active edge X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 00:57:09 -0000 --047d7bf0d0b213457604d09d47b7 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Dec 11, 2012 at 4:23 PM, Sunny Rajagopalan < sunny.rajagopalan@us.ibm.com> wrote: > Hi, Radia > I like this idea a lot better than the other proposals floating around. > The +ve is that it can be done with today's ISIS. The -ve is that you'll > need a minor hardware change - today's hardware generally doesn't have the > ability to use a different source rbridge depending on whether the packet > is unicast or multicast. But can R1 use a different ingress nickname depending on the port from which it is received? For instance, if R1 has 4 ports: a) to pseudonode p1 b) to a different shared link, pseudonode p2 c) to a port with just a bunch of endnodes, so there is no pseudonode d) a link towards the rest of the TRILL campus Can R1 use nickname "p1" when ingressing from port a, nickname "p2" when ingressing from port b, nickname "R1" when ingressing from port c? Thanks, Radia --047d7bf0d0b213457604d09d47b7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Dec 11, 2012 at 4:23 PM, Sunny R= ajagopalan <sunny.rajagopalan@us.ibm.com> wrote:<= br>
Hi, Radia
I like this idea a lot better than the other proposals floating around. The +ve is that it can be done with today&= #39;s ISIS. The -ve is that you'll need a minor hardware change - =A0today= 9;s hardware generally doesn't have the ability to use a different source r= bridge depending on whether the packet is unicast or multicast.=A0

But can R1 =A0use a different ingress nickname depe= nding on the port from which it is received? =A0 For instance, if R1 has 4 = ports:
a) to pseudonode p1
b) to a different shared link, pseudonod= e p2
c) to a port with just a bunch of endnodes, so there is no p= seudonode
d) a link towards the rest of the TRILL campus

Can R1 use nickname "p1" when ingressing from= port a, nickname "p2" when ingressing from port b, nickname &quo= t;R1" when ingressing from port c?

Thanks,

Radia
--047d7bf0d0b213457604d09d47b7-- From sunny.rajagopalan@us.ibm.com Tue Dec 11 17:22:49 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91CA121E80B5 for ; Tue, 11 Dec 2012 17:22:49 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Header field occurs more than once: "MIME-Version" occurs 3 times X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXGXianYYojq for ; Tue, 11 Dec 2012 17:22:49 -0800 (PST) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by ietfa.amsl.com (Postfix) with ESMTP id ECBFE21E8096 for ; Tue, 11 Dec 2012 17:22:48 -0800 (PST) Received: from /spool/local by e34.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 11 Dec 2012 18:22:48 -0700 Received: from d03dlp01.boulder.ibm.com (9.17.202.177) by e34.co.us.ibm.com (192.168.1.134) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 11 Dec 2012 18:22:46 -0700 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id 06ADA1FF0044 for ; Tue, 11 Dec 2012 18:22:39 -0700 (MST) Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id qBC1MjXZ368980 for ; Tue, 11 Dec 2012 18:22:45 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id qBC1Mi4D013818 for ; Tue, 11 Dec 2012 18:22:44 -0700 Received: from d03nm127.boulder.ibm.com ([9.16.16.115]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id qBC1MiCh013794 for ; Tue, 11 Dec 2012 18:22:44 -0700 To: "Radia Perlman" In-Reply-To: Message-ID: <61983C8B-1B5E-4AE3-A548-1F170CDF0A05@us.ibm.com> Date: Tue, 11 Dec 2012 18:22:42 -0700 From: Sunny Rajagopalan MIME-Version: 1.0 X-Mailer: Lotus Notes Traveler 8.5.3.100 Upgrade Pack 1 Build 201209141855 X-MIMETrack: Itemize by Notes Server on D03WGW51/03/G/IBM(Release 8.5.3FP2HF25 | July 24, 2012) at 12/11/2012 06:22:42 PM, Serialize by Router on D03NM127/03/M/IBM(Release 8.5.3FP2 ZX853FP2HF2|October 8, 2012) at 12/11/2012 18:22:44 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=Apple-Mail-9CC76E35-7819-49C4-859A-2147F43E5BFB X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12121201-2876-0000-0000-000003053826 Cc: "trill@ietf.org" Subject: Re: [trill] Thoughts on active-active edge X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 01:22:49 -0000 --Apple-Mail-9CC76E35-7819-49C4-859A-2147F43E5BFB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Yes, most hardware can do what you've described below, but cannot pick for= port a, source rbridge p1 for multicast and p2 for unicast.=20 -- Sunny On Dec 11, 2012, at 5:02 PM, "Radia Perlman" wrote: On Tue, Dec 11, 2012 at 4:23 PM, Sunny Rajagopalan wrote: > Hi, Radia=20 > I like this idea a lot better than the other proposals floating around. T= he +ve is that it can be done with today's ISIS. The -ve is that you'll nee= d a minor hardware change - today's hardware generally doesn't have the ab= ility to use a different source rbridge depending on whether the packet is = unicast or multicast.=20 But can R1 use a different ingress nickname depending on the port from whi= ch it is received? For instance, if R1 has 4 ports: a) to pseudonode p1 b) to a different shared link, pseudonode p2 c) to a port with just a bunch of endnodes, so there is no pseudonode d) a link towards the rest of the TRILL campus Can R1 use nickname "p1" when ingressing from port a, nickname "p2" when in= gressing from port b, nickname "R1" when ingressing from port c? Thanks, Radia= = --Apple-Mail-9CC76E35-7819-49C4-859A-2147F43E5BFB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Yes, most hardware can do what you= 've described below, but cannot pick  for port a, source rbridge p1 fo= r multicast and p2 for unicast. 
--
Sunny

O= n Dec 11, 2012, at 5:02 PM, "Radia Perlman" <radiaperlman@gmail.com> wrote:


=
On Tue, Dec 11, 2012 at 4:23 PM, Sunny Raj= agopalan <sunny.rajagopalan@us.ibm.com> wrote:<= br>
Hi, Radia
I like this idea a lot better than the other proposals floating around. The +ve is that it can be done with today's ISIS. The -ve is that you'll need a minor hardware change -  today's hardware generally doesn't have the ability to use a different source rbrid= ge depending on whether the packet is unicast or multicast. 

But can R1  use a different ingress nicknam= e depending on the port from which it is received?   For instance, if = R1 has 4 ports:
a) to pseudonode p1
b) to a different shared link, pseudonod= e p2
c) to a port with just a bunch of endnodes, so there is no p= seudonode
d) a link towards the rest of the TRILL campus

Can R1 use nickname "p1" when ingressing from port a, n= ickname "p2" when ingressing from port b, nickname "R1" when ingressing fro= m port c?

Thanks,

Radia
= = --Apple-Mail-9CC76E35-7819-49C4-859A-2147F43E5BFB-- From d3e3e3@gmail.com Tue Dec 11 18:59:32 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C077111E80C5 for ; Tue, 11 Dec 2012 18:59:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.46 X-Spam-Level: X-Spam-Status: No, score=-103.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0foy3QFYzP7 for ; Tue, 11 Dec 2012 18:59:30 -0800 (PST) Received: from mail-ia0-f173.google.com (mail-ia0-f173.google.com [209.85.210.173]) by ietfa.amsl.com (Postfix) with ESMTP id 5231021F8661 for ; Tue, 11 Dec 2012 18:59:30 -0800 (PST) Received: by mail-ia0-f173.google.com with SMTP id w21so316217iac.32 for ; Tue, 11 Dec 2012 18:59:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=1Tw3wWARYRcv8fI+hVU27HaMhx/3xYPAVi7FZ/5DCag=; b=VfjCsuRM/eh7Pc7LyyqofV7jNdLdgxNOwRa+LKBgKlhllgn6g/j+k29KillXpnTyco tbT/q0bjVS1eWw3dQY2U+GqtHZA8BBXjsceqNzO3Z9A9fqbMKGB7R5pnKfS7FrkHObWn 0p/EVJ1TKZDzM5p6IJJaTjQR3+KombfexBK5puP7sdoQJv+Sw7IyqWtvcU4Pvw4gpvLr IMJRbY2YEUa07K2i2Iz3VoPGg32tUoCrwogzN4uVPgthsrc8+pSfhZbm/VTIx+sNPfLo oDefGzNH+FGvs7xX8HRgE2gQq2SlZZgk+vVbMZeO9pblmNvAvfgSLArXlaWmki4XLTP+ 0WZA== Received: by 10.42.179.132 with SMTP id bq4mr237287icb.8.1355281167857; Tue, 11 Dec 2012 18:59:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.28.209 with HTTP; Tue, 11 Dec 2012 18:59:07 -0800 (PST) From: Donald Eastlake Date: Tue, 11 Dec 2012 21:59:07 -0500 Message-ID: To: trill@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [trill] Draft Minutes from Atlanta meeting uploaded X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 02:59:32 -0000 See https://datatracker.ietf.org/meeting/85/materials.html Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From tsenevir@cisco.com Tue Dec 11 21:27:28 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6765521F895E for ; Tue, 11 Dec 2012 21:27:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.226 X-Spam-Level: X-Spam-Status: No, score=-8.226 tagged_above=-999 required=5 tests=[AWL=2.372, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yogUMclnKHsl for ; Tue, 11 Dec 2012 21:27:23 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 01B3B21F8654 for ; Tue, 11 Dec 2012 21:27:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11863; q=dns/txt; s=iport; t=1355290043; x=1356499643; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=F/QqlTThTLOfKTFvriFMaRjovZEiGohUpYXvMHPcE28=; b=eKRL/c+TrtJM3AZg3PqdAHHLQf495u5Bm7zW2rwsFSonkz/JBOfxgEb5 8ZPMQEBf08MeikLpAgdrpcStRL6NmmlQ254bsL16pJiS85vUtJ9WIbE87 1ko3AgGkYu6kbVquBgInr/21PQ5cuGWoAAdbrWsn72M5AhIEYjunIssZ7 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAAUVyFCtJV2Z/2dsb2JhbABFgkm8NxZzgh4BAQEELUAcAgEIEQQBAQsdBzIUCQgCBAESCBOHdrwajEuDYmEDpk+Cc4Ii X-IronPort-AV: E=Sophos;i="4.84,264,1355097600"; d="scan'208,217";a="151945711" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 12 Dec 2012 05:27:22 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qBC5RM7j002992 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Dec 2012 05:27:22 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.240]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Tue, 11 Dec 2012 23:27:22 -0600 From: "Tissa Senevirathne (tsenevir)" To: Radia Perlman , "trill@ietf.org" Thread-Topic: [trill] Thoughts on active-active edge Thread-Index: AQHN1+GJAcUGAj4DtkSKdF8jmxk4o5gUnyzw Date: Wed, 12 Dec 2012 05:27:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.166.158] Content-Type: multipart/alternative; boundary="_000_FBEA3E19AA24F847BA3AE74E2FE1935628892DF6xmbrcdx08ciscoc_" MIME-Version: 1.0 Subject: Re: [trill] Thoughts on active-active edge X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 05:27:28 -0000 --_000_FBEA3E19AA24F847BA3AE74E2FE1935628892DF6xmbrcdx08ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please see comments in-line From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of R= adia Perlman Sent: Tuesday, December 11, 2012 12:53 PM To: trill@ietf.org Subject: [trill] Thoughts on active-active edge I'm not too happy about any of the proposed solutions to the active-active = edge issue, and wondering if there might be a simpler approach. To review the problem: Suppose R1, R2, and R3 are all attached to a set of endnodes (say, through = a hypervisor). Let's say "E" is one of the endnodes multihomed through R1,= R2, R3. Let's say "R8" is a distant RBridge (one several hops away from R= 1, R2, and R3). a) If R1, R2, and R3 use their own nickname when encapsulating a frame from= E, then R8 will see frequent changes of E's location (between R1, R2, and = R3). Furthermore, it would be nice if the path from R8 to E could go via t= he shortest path (if, for instance, R2 is much closer to R8 than R1). b) If R1, R2, and R3 use a pseudonode nickname (say P) for all the multihom= ed endnodes, then the RPF check doesn't work when the "wrong" RBridge injec= ts the encapsuated packet into the campus. (the tree will have only one of= R1, R2, or R3 attached to the pseudonode, say R2, so when R2 injects using= the pseuodnode as ingress nickname, the RPF check will work, but it will n= ot work if R1 or R3 inject). -------------- So...this might have been discussed before, but it might not hurt to look a= t it with fresh eyes again. ******************* Proposed rule: R1, R2, and R3 should use the pseudonode nickname when encap= sulating unicast, but use their own nickname when encapsulating multidestin= ation. *********************** Result: R8 will see endnode changes for E, but not very frequent; R8 will= only see changes when traffic from E alternates between multidestination a= nd unicast. [Answer] This depends on the traffic Radia. You cannot assume all multicast= hash to Node R1 and all unicast to R2 and R3 and hence multicast unicast a= ddress ping pong is rare. In the contrary, you could have heavy multicast s= tream and a unicast stream both hashing in to the same RBridge RB1. Question: Are perceived endnode moves a problem? Why? [Answer] Yes it is big time. Unlike ancient devices modern devices to hard= ware based learning. When address association start moving, it will constan= tly bombard the CPU with new address or address move notifications. If endnode changes are, for some reason, a problem, we could have R1, R2, a= nd R3 announce in LSPs, that they are attached to pseudonode P as an active= /active group, and therefore, endnode moves between P and anything in the s= et {R1, R2, R3} should not raise alarms. Better yet, would be to say if en= dnode E is attached to P, then don't move it to {R1, R2, or R3}. [Answer] This will complicate hardware learning. Or least need to re-do the= hardware implementations different than today. We discussed this approach many times with you before and the pain points a= re the same. Radia --_000_FBEA3E19AA24F847BA3AE74E2FE1935628892DF6xmbrcdx08ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please see comments in-li= ne

 <= /p>

From: trill-bo= unces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of Radia Perlman
Sent: Tuesday, December 11, 2012 12:53 PM
To: trill@ietf.org
Subject: [trill] Thoughts on active-active edge

 

I'm not too happy about any of the proposed solution= s to the active-active edge issue, and wondering if there might be a simple= r approach.

 

To review the problem:

 

Suppose R1, R2, and R3 are all attached to a set of = endnodes (say, through a hypervisor).  Let's say "E" is one = of the endnodes multihomed through R1, R2, R3.  Let's say "R8&quo= t; is a distant RBridge (one several hops away from R1, R2, and R3).

 

a) If R1, R2, and R3 use their own nickname when enc= apsulating a frame from E, then R8 will see frequent changes of E's locatio= n (between R1, R2, and R3).  Furthermore, it would be nice if the path= from R8 to E could go via the shortest path (if, for instance, R2 is much closer to R8 than R1).

 

b) If R1, R2, and R3 use a pseudonode nickname (say = P) for all the multihomed endnodes, then the RPF check doesn't work when th= e "wrong" RBridge injects the encapsuated packet into the campus.=  (the tree will have only one of R1, R2, or R3 attached to the pseudonode, say R2, so when R2 injects using the pseuod= node as ingress nickname, the RPF check will work, but it will not work if = R1 or R3 inject).

 

--------------

 

So...this might have been discussed before, but it m= ight not hurt to look at it with fresh eyes again.

 

 

 

*******************

Proposed rule: R1, R2, and R3 should use the pseudon= ode nickname when encapsulating unicast, but use their own nickname when en= capsulating multidestination.

***********************

 

Result:  R8 will see endnode changes for E, but= not very frequent;  R8 will only see changes when traffic from E alte= rnates between multidestination and unicast.  

 

[Answer] This depends on = the traffic Radia. You cannot assume all multicast hash to Node R1 and all = unicast to R2 and R3 and hence multicast unicast address ping pong is rare. In the contrary, you could have heavy multicast stream = and a unicast stream both hashing in to the same RBridge RB1.

 <= /p>

Question: Are perceived endnode moves a problem? &nb= sp;Why?

 

[Answer] Yes it is big ti= me.  Unlike ancient devices modern devices to hardware based learning.= When address association start moving, it will constantly bombard the CPU with new address or address move notifications. =

 <= /p>

If endnode changes are, for some reason, a problem, = we could have R1, R2, and R3 announce in LSPs, that they are attached to ps= eudonode P as an active/active group, and therefore, endnode moves between = P and anything in the set {R1, R2, R3} should not raise alarms.  Better yet, would be to say if endnode = E is attached to P, then don't move it to {R1, R2, or R3}.

 <= /p>

[Answer] This will compli= cate hardware learning. Or least need to re-do the hardware implementations= different than today.

 <= /p>

We discussed this approac= h many times with you before and the pain points are the same.

 

Radia

--_000_FBEA3E19AA24F847BA3AE74E2FE1935628892DF6xmbrcdx08ciscoc_-- From radiaperlman@gmail.com Tue Dec 11 21:59:48 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D88A21F84CF for ; Tue, 11 Dec 2012 21:59:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXCbOwosQf1W for ; Tue, 11 Dec 2012 21:59:46 -0800 (PST) Received: from mail-vb0-f45.google.com (mail-vb0-f45.google.com [209.85.212.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD2621F84CA for ; Tue, 11 Dec 2012 21:59:46 -0800 (PST) Received: by mail-vb0-f45.google.com with SMTP id p1so330166vbi.18 for ; Tue, 11 Dec 2012 21:59:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=78aUUtGXcVgeeQiEB8dnTs9vfqMHe2UcS1MT436OoS8=; b=RsdAPDsF1GpbW4WsQCR8XyKVqsZrviuOo10apYO+E2zDIdz0PAcwLcabbAkEF5n43Q F0T95mtJewdZGyS7WDkOX6pghQwkDVolaO+wmMwbCRqSGXlsJXfMZFpdnWNiy9zB5AbG 5rahSvgmYQFmjFUlIRpsWgfbIN5j0nIXBBLDMDyP+NW281iaZpEdLcmgPxKKWYmwchdc NPhT7jxpHcs21GGwrGfJdJEWfOGv46Bb22z/deIul18Rw/dCGpYvco+m2yFqI5d5hIrb FTaIcOuvs9e9DowTjpbpUef3V3dN0RADYiUAhLBLpBdMmIPOH71Zp8WJpKRt6PhlQFm+ XguA== MIME-Version: 1.0 Received: by 10.58.222.40 with SMTP id qj8mr336506vec.36.1355291982532; Tue, 11 Dec 2012 21:59:42 -0800 (PST) Received: by 10.58.207.138 with HTTP; Tue, 11 Dec 2012 21:59:40 -0800 (PST) In-Reply-To: References: Date: Tue, 11 Dec 2012 21:59:40 -0800 Message-ID: From: Radia Perlman To: "Tissa Senevirathne (tsenevir)" Content-Type: multipart/alternative; boundary=047d7bdc8fd02f8e8e04d0a1818a Cc: "trill@ietf.org" Subject: Re: [trill] Thoughts on active-active edge X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 05:59:48 -0000 --047d7bdc8fd02f8e8e04d0a1818a Content-Type: text/plain; charset=ISO-8859-1 Tissa, there are always technical tradeoffs between approaches. Tissa said: >>[Answer] This depends on the traffic Radia. You cannot assume all multicast hash to Node R1 and all unicast to >>R2 and R3 and hence multicast unicast address ping pong is rare. In the contrary, you could have heavy >>multicast stream and a unicast stream both hashing in to the same RBridge RB1. I'm not sure what relevance there is to whether unicast hashes to R1, R2, R3, or alternates between them, since the rule is that they all use the pseudonode nickname when ingressing from E. The only way there will be frequent endnode moves for E is if E frequently alternates sending multicast and unicast. All unicast from E, whether it is sent to R1, R2, or R3, will be perceived by R8 as coming from pseudonode P. Multicast, on the other hand, with the proposed rule, could bounce between R1, R2, and R3. Though as an optimization, if the pseudonode P is attached to R2, then R2 could use P when ingressing either unicast or multicast, so multicast that happens to hash to R2 will not be perceived as an endnode move, whereas multicast hashing to R1 or R3 would. Tissa said about why endnode moves are a problem: >>[Answer] Yes it is big time. Unlike ancient devices modern devices to hardware based learning. When address >>association start moving, it will constantly bombard the CPU with new address or address move notifications. Your description sounds to me like it's only a problem if there are a lot of moves. Since it seems unlikely that E will keep alternating between sending multicast and unicast, or even if there were one node that was doing that for some reason, that there would be lots of nodes acting this way, it seems like the amount of moves seen, relative to the total amount of traffic received by R8, should be really small. So, the disadvantages of this proposal, as Sunny pointed out, are 1) the active-active RBs might need a hardware change in order to selectively use a different ingress nickname depending on whether the packet is multicast or unicast (which implementations is this true for?) 2) distant RBs (say R8), will perceive E moving when E switches from sending unicast to multicast. But as I said, all approaches have pluses and minuses, so the minuses have to be weighed against the pluses. The advantages of this proposed approach relative to the Affinity TLV are: a) you only need one tree for the campus, and you can have arbitrarily many active-active nodes. Or to put it a different way, you can have more active-active RBs than there are trees. b) furthermore, it allows the active-active RBs to do load splitting of multicast (choosing more than one tree), without requiring n*k trees, where n is the number of active-active RBs, and k is the number of trees each might want to use for load splitting. c) you don't need all RBs to change at once in the campus (as you would with the Affinity proposal). If R8 is unmodified, R8 will see E changing when E changes from multicast to unicast, but will not have incorrect behavior. With affinity, absolutely every RB in the campus must be modified or there will be incorrect (not just suboptimal) behavior. Radia --047d7bdc8fd02f8e8e04d0a1818a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Tissa, there are always technical tradeoffs between approaches.

Tissa said:
>>[Answer] This = depends on the traffic Radia. You cannot assume all multicast hash to Node = R1 and all unicast to >>R2 and R3 and hence multicast unicast address= ping pong is rare. In the contrary, you could have heavy >>multicast= stream and a unicast stream both hashing in to the same RBridge RB1.

I'm not sure what relevance there is to whethe= r unicast hashes to R1, R2, R3, or alternates between them, since the rule = is that they all use the pseudonode nickname when ingressing from E. The on= ly way there will be frequent endnode moves for E is if E frequently altern= ates sending multicast and unicast. =A0All unicast from E, whether it is se= nt to R1, R2, or R3, will be perceived by R8 as coming from pseudonode P. = =A0Multicast, on the other hand, with the proposed rule, could bounce betwe= en R1, R2, and R3. =A0Though as an optimization, if the pseudonode P is att= ached to R2, then R2 could use P when ingressing either unicast or multicas= t, so multicast that happens to hash to R2 will not be perceived as an endn= ode move, whereas multicast hashing to R1 or R3 would.

Tissa said about why endnode moves are a problem:
=

>>[Answ= er] Yes it is big time. =A0Unlike ancient devices modern devices to hardwar= e based learning. When address >>association start moving, it will co= nstantly bombard the CPU with new address or address move notifications.

Your description sounds to me like it's only a prob= lem if there are a lot of moves. =A0Since it seems unlikely that E will kee= p alternating between sending multicast and unicast, or even if there were = one node that was doing that for some reason, that there would be lots of n= odes acting this way, it seems like the amount of moves seen, relative to t= he total amount of traffic received by R8, should be really small.

So, the disadvantages of this proposal, as Sunny p= ointed out, are
1) the active-active RBs might need a hardware ch= ange in order to selectively use a different ingress nickname depending on = whether the packet is multicast or unicast =A0(which implementations is thi= s true for?)
2) distant RBs (say R8), will perceive E moving when E switches from s= ending unicast to multicast.

But as I said, = all approaches have pluses and minuses, so the minuses have to be weighed a= gainst the pluses.

The advantages of this proposed approach relative to th= e Affinity TLV are:

a) you only need one tre= e for the campus, and you can have arbitrarily many active-active nodes. = =A0Or to put it a different way, you can have more active-active RBs than t= here are trees.

b) furthermore, it allows the active-active RBs to do l= oad splitting of multicast (choosing more than one tree), without requiring= n*k trees, where n is the number of active-active RBs, and k is the number= of trees each might want to use for load splitting.

c) you don't need all RBs to change at once in the = campus (as you would with the Affinity proposal). =A0If R8 is unmodified, R= 8 will see E changing when E changes from multicast to unicast, but will no= t have incorrect behavior. =A0With affinity, absolutely every RB in the cam= pus must be modified or there will be incorrect (not just suboptimal) behav= ior.


Radia
--047d7bdc8fd02f8e8e04d0a1818a-- From tsenevir@cisco.com Tue Dec 11 22:11:03 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 098E621F887A for ; Tue, 11 Dec 2012 22:11:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.547 X-Spam-Level: X-Spam-Status: No, score=-9.547 tagged_above=-999 required=5 tests=[AWL=1.051, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3dVfpxuPLXqL for ; Tue, 11 Dec 2012 22:10:58 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 218CE21F88A4 for ; Tue, 11 Dec 2012 22:10:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14705; q=dns/txt; s=iport; t=1355292658; x=1356502258; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4q9SNnO7ePBE8a0AmN/2/JnKtIX4MsaSyjw95gj5cBU=; b=bFhgQ6Dp2RnYdUpkJL2S4NvkshhU+/t6ow7ObvyOYtaCifZ4hafFQEtK 9BX5URtZNLktttAupQ7HEJJIlqcNIuPLy6odJ6d9rHaziBqyErs7gqLZb SzsZC47A7NzBIOrj2gj3yvi0kbs9KPDC1G3lIJBG8JZ5ftz8MX98URp28 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFANYeyFCtJXG+/2dsb2JhbABFgkm8PBZzgh4BAQEELUAMEAIBCBEEAQELHQchERQJCAIEDgUIh3cDD7JCDYlUi2Jpg2JhA5JUgV2NDYURgnOBZAIFGQYY X-IronPort-AV: E=Sophos;i="4.84,264,1355097600"; d="scan'208,217";a="151974507" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 12 Dec 2012 06:10:54 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qBC6AsfT000902 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Dec 2012 06:10:54 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.240]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Wed, 12 Dec 2012 00:10:53 -0600 From: "Tissa Senevirathne (tsenevir)" To: Radia Perlman Thread-Topic: [trill] Thoughts on active-active edge Thread-Index: AQHN1+GJAcUGAj4DtkSKdF8jmxk4o5gUnyzwgABxZQD//5vnwA== Date: Wed, 12 Dec 2012 06:10:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.166.158] Content-Type: multipart/alternative; boundary="_000_FBEA3E19AA24F847BA3AE74E2FE1935628892EAExmbrcdx08ciscoc_" MIME-Version: 1.0 Cc: "trill@ietf.org" Subject: Re: [trill] Thoughts on active-active edge X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 06:11:03 -0000 --_000_FBEA3E19AA24F847BA3AE74E2FE1935628892EAExmbrcdx08ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Radia Please see in line From: Radia Perlman [mailto:radiaperlman@gmail.com] Sent: Tuesday, December 11, 2012 10:00 PM To: Tissa Senevirathne (tsenevir) Cc: trill@ietf.org Subject: Re: [trill] Thoughts on active-active edge Tissa, there are always technical tradeoffs between approaches. Tissa said: >>[Answer] This depends on the traffic Radia. You cannot assume all multica= st hash to Node R1 and all unicast to >>R2 and R3 and hence multicast unica= st address ping pong is rare. In the contrary, you could have heavy >>multi= cast stream and a unicast stream both hashing in to the same RBridge RB1. I'm not sure what relevance there is to whether unicast hashes to R1, R2, R= 3, or alternates between them, since the rule is that they all use the pseu= donode nickname when ingressing from E. The only way there will be frequent= endnode moves for E is if E frequently alternates sending multicast and un= icast. All unicast from E, whether it is sent to R1, R2, or R3, will be pe= rceived by R8 as coming from pseudonode P. Multicast, on the other hand, w= ith the proposed rule, could bounce between R1, R2, and R3. Though as an o= ptimization, if the pseudonode P is attached to R2, then R2 could use P whe= n ingressing either unicast or multicast, so multicast that happens to hash= to R2 will not be perceived as an endnode move, whereas multicast hashing = to R1 or R3 would. [Answer-2] Are you saying E will not simultaneously send multicast and unic= ast ? are you also suggesting there is either a single multicast stream or = all multicast streams are hashing to the same RBridge that E is attached to= ? Tissa said about why endnode moves are a problem: >>[Answer] Yes it is big time. Unlike ancient devices modern devices to ha= rdware based learning. When address >>association start moving, it will con= stantly bombard the CPU with new address or address move notifications. Your description sounds to me like it's only a problem if there are a lot o= f moves. Since it seems unlikely that E will keep alternating between send= ing multicast and unicast, or even if there were one node that was doing th= at for some reason, that there would be lots of nodes acting this way, it s= eems like the amount of moves seen, relative to the total amount of traffic= received by R8, should be really small. [Answer-2] It is not lots of switches it is how many ping-pong, with a sing= le address and two stream you can overload learning buffers when traffic is= coming at high rates. So, the disadvantages of this proposal, as Sunny pointed out, are 1) the active-active RBs might need a hardware change in order to selective= ly use a different ingress nickname depending on whether the packet is mult= icast or unicast (which implementations is this true for?) 2) distant RBs (say R8), will perceive E moving when E switches from sendin= g unicast to multicast. [Answer-2] #2 is exactly what I am saying as a big problem. But if you feel= it is not a problem, I am not going to argue any further. You should speak= to few more people and get the validation. ***Address move is a major prob= lem** But as I said, all approaches have pluses and minuses, so the minuses have = to be weighed against the pluses. The advantages of this proposed approach relative to the Affinity TLV are: a) you only need one tree for the campus, and you can have arbitrarily many= active-active nodes. Or to put it a different way, you can have more acti= ve-active RBs than there are trees. b) furthermore, it allows the active-active RBs to do load splitting of mul= ticast (choosing more than one tree), without requiring n*k trees, where n = is the number of active-active RBs, and k is the number of trees each might= want to use for load splitting. c) you don't need all RBs to change at once in the campus (as you would wit= h the Affinity proposal). If R8 is unmodified, R8 will see E changing when= E changes from multicast to unicast, but will not have incorrect behavior.= With affinity, absolutely every RB in the campus must be modified or ther= e will be incorrect (not just suboptimal) behavior. Radia --_000_FBEA3E19AA24F847BA3AE74E2FE1935628892EAExmbrcdx08ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Radia

 <= /p>

Please see in line

 <= /p>

From: Radia Pe= rlman [mailto:radiaperlman@gmail.com]
Sent: Tuesday, December 11, 2012 10:00 PM
To: Tissa Senevirathne (tsenevir)
Cc: trill@ietf.org
Subject: Re: [trill] Thoughts on active-active edge

 

Tissa, there are always technical tradeoffs between = approaches.

 

Tissa said:

>>[Answer] This dep= ends on the traffic Radia. You cannot assume all multicast hash to Node R1 = and all unicast to >>R2 and R3 and hence multicast unicast address ping pong is rare. In the contrary, you could have heavy >>multicast= stream and a unicast stream both hashing in to the same RBridge RB1.

 

I'm not sure what relevance there is to whether unic= ast hashes to R1, R2, R3, or alternates between them, since the rule is tha= t they all use the pseudonode nickname when ingressing from E. The only way= there will be frequent endnode moves for E is if E frequently alternates sending multicast and unicast.  A= ll unicast from E, whether it is sent to R1, R2, or R3, will be perceived b= y R8 as coming from pseudonode P.  Multicast, on the other hand, with = the proposed rule, could bounce between R1, R2, and R3.  Though as an optimization, if the pseudonode P is attach= ed to R2, then R2 could use P when ingressing either unicast or multicast, = so multicast that happens to hash to R2 will not be perceived as an endnode= move, whereas multicast hashing to R1 or R3 would.

 <= /p>

 <= /p>

[Answer-2] Are you saying= E will not simultaneously send multicast and unicast ? are you also sugges= ting there is either a single multicast stream or all multicast streams are hashing to the same RBridge that E is attached to ?=

 

Tissa said about why endnode moves are a problem:

 

>>= [Answer] Yes it is big time.  Unlike ancient devices modern devices to= hardware based learning. When address >>association start moving, it will constantly bombard the CPU with new address or address move notifi= cations.

 

Your description sounds to me like it's only a probl= em if there are a lot of moves.  Since it seems unlikely that E will k= eep alternating between sending multicast and unicast, or even if there wer= e one node that was doing that for some reason, that there would be lots of nodes acting this way, it seems like t= he amount of moves seen, relative to the total amount of traffic received b= y R8, should be really small.

 <= /p>

[Answer-2] It is not lots= of switches it is how many ping-pong, with a single address and two stream= you can overload learning buffers when traffic is coming at high rates.

 

So, the disadvantages of this proposal, as Sunny poi= nted out, are

1) the active-active RBs might need a hardware chang= e in order to selectively use a different ingress nickname depending on whe= ther the packet is multicast or unicast  (which implementations is thi= s true for?)

2) distant RBs (say R8), will perceive E moving when= E switches from sending unicast to multicast.

 

[Answer-2] #2 is exactly = what I am saying as a big problem. But if you feel it is not a problem, I a= m not going to argue any further. You should speak to few more people and get the validation. ***Address move is a major problem** <= o:p>

 <= /p>

But as I said, all approaches have pluses and minuse= s, so the minuses have to be weighed against the pluses.

 

The advantages of this proposed approach relative to= the Affinity TLV are:

 

a) you only need one tree for the campus, and you ca= n have arbitrarily many active-active nodes.  Or to put it a different= way, you can have more active-active RBs than there are trees.<= /p>

 

b) furthermore, it allows the active-active RBs to d= o load splitting of multicast (choosing more than one tree), without requir= ing n*k trees, where n is the number of active-active RBs, and k is the num= ber of trees each might want to use for load splitting.

 

c) you don't need all RBs to change at once in the c= ampus (as you would with the Affinity proposal).  If R8 is unmodified,= R8 will see E changing when E changes from multicast to unicast, but will = not have incorrect behavior.  With affinity, absolutely every RB in the campus must be modified or there will be incorr= ect (not just suboptimal) behavior.

 

 

Radia

--_000_FBEA3E19AA24F847BA3AE74E2FE1935628892EAExmbrcdx08ciscoc_-- From zhangmingui@huawei.com Tue Dec 11 22:49:25 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65CA121F8889 for ; Tue, 11 Dec 2012 22:49:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLE5dnQcG5lN for ; Tue, 11 Dec 2012 22:49:24 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DE0A821F887E for ; Tue, 11 Dec 2012 22:49:23 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMK25106; Wed, 12 Dec 2012 06:49:22 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 12 Dec 2012 06:48:37 +0000 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 12 Dec 2012 14:49:22 +0800 Received: from SZXEML507-MBS.china.huawei.com ([169.254.7.234]) by szxeml405-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Wed, 12 Dec 2012 14:46:55 +0800 From: Mingui Zhang To: "Tissa Senevirathne (tsenevir)" , Radia Perlman Thread-Topic: [trill] Thoughts on active-active edge Thread-Index: AQHN1+GKKCdMCC4LGEWia3k7aW76oZgUHNiAgAAJBwCAAAMhAIAAh2Bg Date: Wed, 12 Dec 2012 06:46:55 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E732138B02@SZXEML507-MBS.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.185] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "trill@ietf.org" Subject: Re: [trill] Thoughts on active-active edge X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 06:49:25 -0000 Hi, I think the MAC move affects the path selection at the remote RBridge 'R8',= which may bring frame disorder at the endnode 'E' connected to the active-= active edge.=20 The new proposal suggests that one group occupies one pseudo-node nickname.= If "use up the nickname space" is really a problem, the new proposal suffe= rs from this problem, right? Having said that, I want to argue that we have= to identify each active-active edge with a pseudo-node nickname in either = proposal AND the consumption of nicknames on active-active edge is not a bi= g problem. Thanks, Mingui=20 >-----Original Message----- >From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of = Tissa >Senevirathne (tsenevir) >Sent: Wednesday, December 12, 2012 2:11 PM >To: Radia Perlman >Cc: trill@ietf.org >Subject: Re: [trill] Thoughts on active-active edge > >Radia > > > >Please see in line > > > >From: Radia Perlman [mailto:radiaperlman@gmail.com] >Sent: Tuesday, December 11, 2012 10:00 PM >To: Tissa Senevirathne (tsenevir) >Cc: trill@ietf.org >Subject: Re: [trill] Thoughts on active-active edge > > > >Tissa, there are always technical tradeoffs between approaches. > > > >Tissa said: > >>>[Answer] This depends on the traffic Radia. You cannot assume all multic= ast >hash to Node R1 and all unicast to >>R2 and R3 and hence multicast unicast >address ping pong is rare. In the contrary, you could have heavy >>multica= st >stream and a unicast stream both hashing in to the same RBridge RB1. > > > >I'm not sure what relevance there is to whether unicast hashes to R1, R2, = R3, or >alternates between them, since the rule is that they all use the pseudonod= e >nickname when ingressing from E. The only way there will be frequent endno= de >moves for E is if E frequently alternates sending multicast and unicast. = All >unicast from E, whether it is sent to R1, R2, or R3, will be perceived by = R8 as >coming from pseudonode P. Multicast, on the other hand, with the proposed >rule, could bounce between R1, R2, and R3. Though as an optimization, if = the >pseudonode P is attached to R2, then R2 could use P when ingressing either >unicast or multicast, so multicast that happens to hash to R2 will not be >perceived as an endnode move, whereas multicast hashing to R1 or R3 would. > > > > > >[Answer-2] Are you saying E will not simultaneously send multicast and uni= cast ? >are you also suggesting there is either a single multicast stream or all m= ulticast >streams are hashing to the same RBridge that E is attached to ? > > > >Tissa said about why endnode moves are a problem: > > > >>>[Answer] Yes it is big time. Unlike ancient devices modern devices to >hardware based learning. When address >>association start moving, it will >constantly bombard the CPU with new address or address move notifications. > > > >Your description sounds to me like it's only a problem if there are a lot = of moves. >Since it seems unlikely that E will keep alternating between sending multi= cast >and unicast, or even if there were one node that was doing that for some r= eason, >that there would be lots of nodes acting this way, it seems like the amoun= t of >moves seen, relative to the total amount of traffic received by R8, should= be >really small. > > > >[Answer-2] It is not lots of switches it is how many ping-pong, with a sin= gle >address and two stream you can overload learning buffers when traffic is c= oming >at high rates. > > > >So, the disadvantages of this proposal, as Sunny pointed out, are > >1) the active-active RBs might need a hardware change in order to selectiv= ely >use a different ingress nickname depending on whether the packet is multic= ast >or unicast (which implementations is this true for?) > >2) distant RBs (say R8), will perceive E moving when E switches from sendi= ng >unicast to multicast. > > > >[Answer-2] #2 is exactly what I am saying as a big problem. But if you fee= l it is >not a problem, I am not going to argue any further. You should speak to fe= w >more people and get the validation. ***Address move is a major problem** > > > >But as I said, all approaches have pluses and minuses, so the minuses have= to be >weighed against the pluses. > > > >The advantages of this proposed approach relative to the Affinity TLV are: > > > >a) you only need one tree for the campus, and you can have arbitrarily man= y >active-active nodes. Or to put it a different way, you can have more >active-active RBs than there are trees. > > > >b) furthermore, it allows the active-active RBs to do load splitting of mu= lticast >(choosing more than one tree), without requiring n*k trees, where n is the >number of active-active RBs, and k is the number of trees each might want = to >use for load splitting. > > > >c) you don't need all RBs to change at once in the campus (as you would wi= th the >Affinity proposal). If R8 is unmodified, R8 will see E changing when E ch= anges >from multicast to unicast, but will not have incorrect behavior. With aff= inity, >absolutely every RB in the campus must be modified or there will be incorr= ect >(not just suboptimal) behavior. > > > > > >Radia From zhai.hongjun@zte.com.cn Wed Dec 12 01:55:36 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B720B21F8975 for ; Wed, 12 Dec 2012 01:55:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.999 X-Spam-Level: X-Spam-Status: No, score=-96.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100, WEIRD_QUOTING=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hXFAcxtQiQyy for ; Wed, 12 Dec 2012 01:55:35 -0800 (PST) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 51F9221F8973 for ; Wed, 12 Dec 2012 01:55:35 -0800 (PST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 7E70F12609A5 for ; Wed, 12 Dec 2012 17:57:24 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id qBC9tGX9020174 for ; Wed, 12 Dec 2012 17:55:16 +0800 (GMT-8) (envelope-from zhai.hongjun@zte.com.cn) To: "trill@ietf.org" MIME-Version: 1.0 X-KeepSent: B82F5FFF:B5A7024B-48257AD2:003032DF; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhai.hongjun@zte.com.cn Date: Wed, 12 Dec 2012 17:55:13 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-12-12 17:55:14, Serialize complete at 2012-12-12 17:55:14 Content-Type: multipart/alternative; boundary="=_alternative 0036BD3348257AD2_=" X-MAIL: mse02.zte.com.cn qBC9tGX9020174 Subject: [trill] Fwd: New Version Notification for draft-hu-trill-pseudonode-nickname-04.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 09:55:36 -0000 This is a multipart message in MIME format. --=_alternative 0036BD3348257AD2_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 QSBuZXcgdmVyc2lvbiBvZiBkcmFmdC1odS10cmlsbC1wc2V1ZG9ub2RlLW5pY2tuYW1lLnR4dCBp cyBwb3N0ZWQuIA0KDQpJbiB0aGlzIHZlcnNpb24sIHRoZSBkcmFmdCBoYXMgNiBtYWluIHNlY3Rp b25zLCBvcmdhbml6ZWQgYXMgZm9sbG93czoNCg0KU2VjdGlvbiAyIGRlc2NyaWJlcyB0aGUgcmVh c29ucyB3aHkgdmlydHVhbCBSQnJpZGdlIGFsb25nIHdpdGggaXRzIA0KcHNldWRvLW5pY2tuYW1l IGlzIGludHJvZHVjZWQuDQoNClNlY3Rpb24gMyBnaXZlcyB0aGUgY29uY2VwdCBvZiBWaXJ0dWFs IFJCcmlkZ2UuIEFuIFJCdiByZXByZXNlbnRzIGEgZ3JvdXAgDQpvZiBkaWZmZXJlbnQgZW5kIHN0 YXRpb24gc2VydmljZSBwb3J0cyBvbiBkaWZmZXJlbnQgZWRnZSBSQnJpZGdlcywgc28gDQp0aGVz ZSBSQnJpZGVzIGNhbiB1c2VzIGEgZGlmZmVyZW50IGluZ3Jlc3Mgbmlja25hbWUgZGVwZW5kaW5n IG9uIHRoZSBwb3J0IA0KZnJvbSB3aGljaCBuYXRpdmUgZnJhbWVzIGlzIHJlY2VpdmVkLg0KDQpT ZWN0aW9uIDQgZGVzY3JpYmVzIEQtdHJlZXMgYWxsb2NhdGlvbiBhY3Jvc3MgbWVtYmVyIFJCcmlk Z2VzIGluIGEgUkJ2LCANCndoZXJlIFNlY3Rpb24gNC4xIGRlc2NyaWJlcyB0aGUgYWxsb2NhdGlv biBvZiB0cmVlcyBmb3IgdGhlIGluZ3Jlc3NlZCANCm11bHRpLWRlc3RpbmF0aW9uIGZyYW1lcyB0 byBwYXNzIHRoZSBSUEYgY2hlY2sgb24gcmVtb3RlIFJCcmlkZ2VzLCB3aGlsZSANClNlY3Rpb24g NC4yIGNvdmVycyB0aGUgYWxsb2NhdGlvbiBvZiB0cmVlcyBmb3IgdGhlIGVncmVzc2luZyBvZiAN Cm11bHRpLWRlc3RpbmF0aW9uIGZyYW1lcyBhcnJpdmluZyBvbiBhbnkgdHJlZXMuDQoNClNlY3Rp b24gNSBjb3ZlcnMgdGhlIHByb2Nlc3Npbmcgb2YgdHJhbnNpdCBmcmFtZXMgaW4gY29uc2lkZXJh dGlvbiBvZiB0aGUgDQpwc2V1ZG8tbmlja25hbWUuIFRoZSBpbmZsdWVuY2Ugb2YgUkJ2IG9uIG1l bWJlciBSQnJpZ2VzIGluZ3Jlc3NpbmcgYW5kIA0KZWdyZXNzaW5nIGZyYW1lcyBhcmUgZGVzY3Jp YmVkIGluIFNlY3Rpb24gNS4xIGFuZCA1LjIsIHJlc3BlY3RpdmVseS4NCg0KU2VjdGlvbiA2IGRp c2N1c3NlcyB0aGUgbGluayBwcm90ZWN0aW9uIGluIHRoZSBjYXNlIG9mIG1lbWJlciBSQnJpZGdl J3MgDQpkb3dubG9hZCBsaW5rIGZhaWx1cmUuDQoNClNlY3Rpb24gNyBnaXZlcyBhbiBFU0FESSBz dWItVExWIHVzZWQgZm9yIEQtdHJlZSBhbGxvY2F0aW9uIGFtb25nIG1lbWJlciANClJicmlkZ2Vz IGdpdmVuIGluIFNlY3Rpb24gNC4yLg0KDQpQbGVhc2UgY2xpY2sgdGhlIGZvbGxvd2luZyBVUkwg YW5kIHJldmlldyB0aGlzIGRyYWZ0LiBZb3VyIHJldmlldyBhbmQgDQpjb21tZW50cyBhcmUgdmVy eSBhcHByZWNpYXRlZC4NCg0KVVJMOiANCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzL2RyYWZ0LWh1LXRyaWxsLXBzZXVkb25vZGUtbmlja25hbWUtMDQudHh0DQoNCg0KDQpCZXN0 IFJlZ2FyZHMsDQpaaGFpIEhvbmdqdW4NCiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIi IiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiINCiBQcm90b2NvbCBEZXZlbG9w bWVudCBEZXB0LlZJLCBDZW50cmFsIFImRCBJbnN0aXR1dGUsIFpURSBDb3Jwb3JhdGlvbg0KIE5v LiA2OCwgWmlqaW5naHVhIFJvYWQsIFl1aHVhdGFpIERpc3RyaWN0LCBOYW5qaW5nLCBQLlIuQ2hp bmEsIDIxMDAxMg0KIA0KIFpoYWkgSG9uZ2p1bg0KIA0KIFRlbDogKzg2LTI1LTUyODc3MzQ1DQog RW1haWw6IHpoYWkuaG9uZ2p1bkB6dGUuY29tLmNuDQoiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIi IiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIg0KDQoNCi0tLS0t INeqt6LIyyC11LrpvvwxMjk1NjcvdXNlci96dGVfbHRkIMqxvOQgMjAxMi0xMi0xMiAxNjo1NCAt LS0tLQ0KDQppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgDQoyMDEyLTEyLTEyIDE2OjQ1DQoNCsrV vP7Iyw0KemhhaS5ob25nanVuQHp0ZS5jb20uY24NCrOty80NCnRzZW5ldmlyQGNpc2NvLmNvbSwg ZDNlM2UzQGdtYWlsLmNvbSwgcmFkaWFAYWx1bS5taXQuZWR1LCANCmh1LmZhbmd3ZWlAenRlLmNv bS5jbiwgemhhbmdtaW5ndWlAaHVhd2VpLmNvbQ0K1vfM4g0KTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1odS10cmlsbC1wc2V1ZG9ub2RlLW5pY2tuYW1lLTA0LnR4dA0KDQoNCg0K DQoNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaHUtdHJpbGwtcHNldWRvbm9kZS1u aWNrbmFtZS0wNC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgSG9uZ2p1 biBaaGFpIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOiAg ICAgICAgICAgICAgICAgZHJhZnQtaHUtdHJpbGwtcHNldWRvbm9kZS1uaWNrbmFtZQ0KUmV2aXNp b246ICAgICAgICAgICAgICAgICAwNA0KVGl0bGU6ICAgICAgICAgICAgICAgICAgICAgICAgICAg IFJCcmlkZ2U6IFBzZXVkby1OaWNrbmFtZQ0KQ3JlYXRpb24gZGF0ZTogICAgICAgICAgICAyMDEy LTEyLTEwDQpXRyBJRDogICAgICAgICAgICAgICAgICAgICAgICAgICAgSW5kaXZpZHVhbCBTdWJt aXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDIxDQpVUkw6ICAgICAgICAgICAgIA0KaHR0cDovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaHUtdHJpbGwtcHNldWRvbm9kZS1uaWNr bmFtZS0wNC50eHQNCg0KU3RhdHVzOiAgICAgICAgICANCmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaHUtdHJpbGwtcHNldWRvbm9kZS1uaWNrbmFtZQ0KSHRtbGl6ZWQ6ICAg ICAgICANCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWh1LXRyaWxsLXBzZXVkb25v ZGUtbmlja25hbWUtMDQNCkRpZmY6ICAgICAgICAgICAgDQpodHRwOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC1odS10cmlsbC1wc2V1ZG9ub2RlLW5pY2tuYW1lLTA0DQoNCkFic3Ry YWN0Og0KICAgUkJyaWRnZXMgcHJvdmlkZSBmcmFtZSBmb3J3YXJkaW5nIHNlcnZpY2UgdG8gbGF5 ZXIyIHN3aXRjaGVzIG9yIGVuZA0KICAgc3RhdGlvbnMgYXQgdGhlIGVkZ2Ugb2YgVFJJTEwgY2Ft cHVzLiAgQXMgZGVmaW5lZCBpbiBbUkZDNjMyNV0sIHdoZW4NCiAgIHRoZXJlIGFyZSBtdWx0aXBs ZSBSQnJpZGdlcyBhdHRhY2hlZCB0byB0aGUgc2FtZSBMQU4gc2VnbWVudCwgb25seQ0KICAgb25l IGVkZ2UgUkJyaWRnZSBpcyBhbGxvd2VkIHRvIGJlIHRoZSBmcmFtZSBmb3J3YXJkZXIgb2YgYSBz cGVjaWZpYw0KICAgVkxBTiBpbiBvcmRlciB0byBhdm9pZCBwb3RlbnRpYWwgZnJhbWUgZHVwbGlj YXRpb24gYW5kIGxvb3BzIGluIHRoZQ0KICAgVFJJTEwgY2FtcHVzLiAgSG93ZXZlciwgaW4gc29t ZSBhcHBsaWNhdGlvbiBzY2VuYXJpb3MsIGZvciBleGFtcGxlIGFuDQogICBlbmQgc3RhdGlvbiBp cyBtdWx0aS1ob21lZCB0byBtdWx0aXBsZSBSQnJpZGdlcyBuZWVkcyB0byBpbXByb3ZlIHRoZQ0K ICAgcmVzaWxpZW5jeSBhbmQgaW5jcmVhc2UgdGhlIGF2YWlsYWJsZSBuZXR3b3JrIGJhbmR3aWR0 aCBvZiB0aGUNCiAgIGNvbm5lY3Rpb24uICBUaGlzIG1lYW5zIGFsbCB0aG9zZSBSQnJpZ2VzIGF0 dGFjaGVkIHRvIHRoZSBlbmQgc3RhdGlvbg0KICAgY2FuIGFjdCBhcyB0aGUgZnJhbWUgZm9yd2Fy ZGVycyBvZiBhIHNwZWNpZmljIFZMQU4uICBUaGlzIGtpbmQgb2YNCiAgIGFjdGl2ZS1hY3RpdmUg Y29ubmVjdGlvbiB2aW9sYXRlcyB0aGUgZGVmaW5pdGlvbiBhYm92ZS4gIEZyYW1lDQogICBkdXBs aWNhdGlvbiBhbmQgZm9yd2FyZGluZyBsb29wcyBtYXkgaGFwcGVuIGFuZCBpdCBtYXkgY2F1c2Ug dGhlDQogICBmbGlwLWZsb3BwaW5nIG9mIHRoZSBlZ3Jlc3MgUkJyaWRnZSBuaWNrbmFtZSBhc3Nv Y2lhdGVkIHRvIHRoZSBNQUMNCiAgIGFkZHJlc3Mgb2Ygc3VjaCBhbiBlbmQgc3RhdGlvbiBpbiBy ZW1vdGUgUkJyaWRnZXMnIGZvcndhcmRpbmcgdGFibGVzLg0KICAgVGhlIFJldmVyc2UgUGF0aCBG b3J3YXJkaW5nIENoZWNrIGRvZXMgbm90IHdvcmsgYXMgd2VsbCwgd2hpY2ggaGFzDQogICBiZWVu IGFkZHJlc3NlZCBpbiBbQ01UXS4gIFRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgdGhlIGNvbmNlcHQg b2YNCiAgIFZpcnR1YWwgUkJyaWRnZSwgYWxvbmcgd2l0aCB0aGUgcHNldWRvLW5pY2tuYW1lIGNv bmZpZ3VyYXRpb24gZm9yDQogICB0aGlzIFZpcnR1YWwgUkJyaWRnZSwgdG8gYWRkcmVzcyB0aGUg YWJvdmUgcHJvYmxlbXMgaW4gYWNjb21wYW55IHdpdGgNCiAgIFtDTVRdLg0KDQogIA0KDQoNClRo ZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0K --=_alternative 0036BD3348257AD2_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkEgbmV3IHZlcnNpb24gb2YgZHJh ZnQtaHUtdHJpbGwtcHNldWRvbm9kZS1uaWNrbmFtZS50eHQNCmlzIHBvc3RlZC4gPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JbiB0aGlzIHZlcnNpb24s IHRoZSBkcmFmdCBoYXMgNiBtYWluDQpzZWN0aW9ucywgb3JnYW5pemVkIGFzIGZvbGxvd3M6PC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5TZWN0aW9uIDIg ZGVzY3JpYmVzIHRoZSByZWFzb25zIHdoeQ0KdmlydHVhbCBSQnJpZGdlIGFsb25nIHdpdGggaXRz IHBzZXVkby1uaWNrbmFtZSBpcyBpbnRyb2R1Y2VkLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+U2VjdGlvbiAzIGdpdmVzIHRoZSBjb25jZXB0IG9mIFZp cnR1YWwNClJCcmlkZ2UuIEFuIFJCdiByZXByZXNlbnRzIGEgZ3JvdXAgb2YgZGlmZmVyZW50IGVu ZCBzdGF0aW9uIHNlcnZpY2UgcG9ydHMNCm9uIGRpZmZlcmVudCBlZGdlIFJCcmlkZ2VzLCBzbyB0 aGVzZSBSQnJpZGVzIGNhbiB1c2VzIGEgZGlmZmVyZW50IGluZ3Jlc3MNCm5pY2tuYW1lIGRlcGVu ZGluZyBvbiB0aGUgcG9ydCBmcm9tIHdoaWNoIG5hdGl2ZSBmcmFtZXMgaXMgcmVjZWl2ZWQuPC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5TZWN0aW9uIDQg ZGVzY3JpYmVzIEQtdHJlZXMgYWxsb2NhdGlvbg0KYWNyb3NzIG1lbWJlciBSQnJpZGdlcyBpbiBh IFJCdiwgd2hlcmUgU2VjdGlvbiA0LjEgZGVzY3JpYmVzIHRoZSBhbGxvY2F0aW9uDQpvZiB0cmVl cyBmb3IgdGhlIGluZ3Jlc3NlZCBtdWx0aS1kZXN0aW5hdGlvbiBmcmFtZXMgdG8gcGFzcyB0aGUg UlBGIGNoZWNrDQpvbiByZW1vdGUgUkJyaWRnZXMsIHdoaWxlIFNlY3Rpb24gNC4yIGNvdmVycyB0 aGUgYWxsb2NhdGlvbiBvZiB0cmVlcyBmb3INCnRoZSBlZ3Jlc3Npbmcgb2YgJm5ic3A7bXVsdGkt ZGVzdGluYXRpb24gZnJhbWVzIGFycml2aW5nIG9uIGFueSB0cmVlcy48L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlNlY3Rpb24gNSBjb3ZlcnMgdGhlIHBy b2Nlc3Npbmcgb2YgdHJhbnNpdA0KZnJhbWVzIGluIGNvbnNpZGVyYXRpb24gb2YgdGhlIHBzZXVk by1uaWNrbmFtZS4gVGhlIGluZmx1ZW5jZSBvZiBSQnYgb24NCm1lbWJlciBSQnJpZ2VzIGluZ3Jl c3NpbmcgYW5kIGVncmVzc2luZyBmcmFtZXMgYXJlIGRlc2NyaWJlZCBpbiBTZWN0aW9uDQo1LjEg YW5kIDUuMiwgcmVzcGVjdGl2ZWx5LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+U2VjdGlvbiA2IGRpc2N1c3NlcyB0aGUgbGluayBwcm90ZWN0aW9uDQpp biB0aGUgY2FzZSBvZiBtZW1iZXIgUkJyaWRnZSdzIGRvd25sb2FkIGxpbmsgZmFpbHVyZS48L2Zv bnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlNlY3Rpb24gNyBn aXZlcyBhbiBFU0FESSBzdWItVExWIHVzZWQNCmZvciBELXRyZWUgYWxsb2NhdGlvbiBhbW9uZyBt ZW1iZXIgUmJyaWRnZXMgZ2l2ZW4gaW4gU2VjdGlvbiA0LjIuPC9mb250Pg0KPGJyPg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5QbGVhc2UgY2xpY2sgdGhlIGZvbGxvd2luZyBV UkwgYW5kIHJldmlldw0KdGhpcyBkcmFmdC4gWW91ciByZXZpZXcgYW5kIGNvbW1lbnRzIGFyZSB2 ZXJ5IGFwcHJlY2lhdGVkLjwvZm9udD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPlVSTDog aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaHUtdHJpbGwtcHNldWRv bm9kZS1uaWNrbmFtZS0wNC50eHQ8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KQmVzdCBSZWdhcmRzLDxicj4NClpoYWkgSG9u Z2p1bjxicj4NCiZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90 OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZx dW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90 OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZx dW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90 OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZx dW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90 OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90Ozxicj4NCiBQcm90b2NvbCBEZXZlbG9wbWVu dCBEZXB0LlZJLCBDZW50cmFsIFImYW1wO0QgSW5zdGl0dXRlLCBaVEUgQ29ycG9yYXRpb248YnI+ DQogTm8uIDY4LCBaaWppbmdodWEgUm9hZCwgWXVodWF0YWkgRGlzdHJpY3QsIE5hbmppbmcsIFAu Ui5DaGluYSwgMjEwMDEyPGJyPg0KIDxicj4NCiBaaGFpIEhvbmdqdW48YnI+DQogPGJyPg0KIFRl bDogKzg2LTI1LTUyODc3MzQ1PGJyPg0KIEVtYWlsOiB6aGFpLmhvbmdqdW5AenRlLmNvbS5jbjxi cj4NCiZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90 OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZx dW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90 OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZx dW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90 OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZx dW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90 OyZxdW90OyZxdW90OyZxdW90OyZxdW90OyZxdW90Ozxicj4NCjxicj4NCjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTEgY29sb3I9IzgwMDA4MCBmYWNlPSJzYW5zLXNlcmlmIj4tLS0tLSDXqreiyMsg tdS66b78MTI5NTY3L3VzZXIvenRlX2x0ZA0KyrG85CAyMDEyLTEyLTEyIDE2OjU0IC0tLS0tPC9m b250Pg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0 aD0yMSU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPmludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZzwvYj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4y MDEyLTEyLTEyIDE2OjQ1PC9mb250Pg0KPHRkIHdpZHRoPTc4JT4NCjx0YWJsZSB3aWR0aD0xMDAl Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPnpoYWkuaG9uZ2p1bkB6dGUuY29tLmNuPC9mb250Pg0KPHRyIHZhbGln bj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij50c2VuZXZpckBjaXNjby5jb20sIGQzZTNlM0BnbWFpbC5jb20sDQpyYWRpYUBhbHVtLm1pdC5l ZHUsIGh1LmZhbmd3ZWlAenRlLmNvbS5jbiwgemhhbmdtaW5ndWlAaHVhd2VpLmNvbTwvZm9udD4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1odS10cmlsbC1w c2V1ZG9ub2RlLW5pY2tuYW1lLTA0LnR4dDwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0K PHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0K PGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRy YWZ0LWh1LXRyaWxsLXBzZXVkb25vZGUtbmlja25hbWUtMDQudHh0PGJyPg0KaGFzIGJlZW4gc3Vj Y2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBIb25nanVuIFpoYWkgYW5kIHBvc3RlZCB0byB0aGU8YnI+ DQpJRVRGIHJlcG9zaXRvcnkuPGJyPg0KPGJyPg0KRmlsZW5hbWU6ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwO2RyYWZ0LWh1LXRy aWxsLXBzZXVkb25vZGUtbmlja25hbWU8YnI+DQpSZXZpc2lvbjogJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7MDQ8YnI+DQpUaXRs ZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw Ow0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsNClJCcmlkZ2U6IFBzZXVkby1OaWNrbmFtZTxicj4NCkNyZWF0aW9uIGRhdGU6ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZu YnNwOzIwMTItMTItMTA8YnI+DQpXRyBJRDogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCkluZGl2aWR1YWwgU3VibWlzc2lvbjxi cj4NCk51bWJlciBvZiBwYWdlczogMjE8YnI+DQpVUkw6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LWh1LXRyaWxsLXBzZXVkb25vZGUtbmlja25hbWUtMDQudHh0PGJyPg0KU3RhdHVzOiAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1odS10cmlsbC1wc2V1ZG9ub2RlLW5pY2tuYW1lPGJyPg0KSHRtbGl6ZWQ6ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2h0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWh1LXRyaWxsLXBzZXVkb25vZGUtbmlja25hbWUtMDQ8YnI+DQpEaWZmOiAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2h0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91 cmwyPWRyYWZ0LWh1LXRyaWxsLXBzZXVkb25vZGUtbmlja25hbWUtMDQ8YnI+DQo8YnI+DQpBYnN0 cmFjdDo8YnI+DQogJm5ic3A7IFJCcmlkZ2VzIHByb3ZpZGUgZnJhbWUgZm9yd2FyZGluZyBzZXJ2 aWNlIHRvIGxheWVyMiBzd2l0Y2hlcyBvcg0KZW5kPGJyPg0KICZuYnNwOyBzdGF0aW9ucyBhdCB0 aGUgZWRnZSBvZiBUUklMTCBjYW1wdXMuICZuYnNwO0FzIGRlZmluZWQgaW4gW1JGQzYzMjVdLA0K d2hlbjxicj4NCiAmbmJzcDsgdGhlcmUgYXJlIG11bHRpcGxlIFJCcmlkZ2VzIGF0dGFjaGVkIHRv IHRoZSBzYW1lIExBTiBzZWdtZW50LCBvbmx5PGJyPg0KICZuYnNwOyBvbmUgZWRnZSBSQnJpZGdl IGlzIGFsbG93ZWQgdG8gYmUgdGhlIGZyYW1lIGZvcndhcmRlciBvZiBhIHNwZWNpZmljPGJyPg0K ICZuYnNwOyBWTEFOIGluIG9yZGVyIHRvIGF2b2lkIHBvdGVudGlhbCBmcmFtZSBkdXBsaWNhdGlv biBhbmQgbG9vcHMgaW4NCnRoZTxicj4NCiAmbmJzcDsgVFJJTEwgY2FtcHVzLiAmbmJzcDtIb3dl dmVyLCBpbiBzb21lIGFwcGxpY2F0aW9uIHNjZW5hcmlvcywgZm9yDQpleGFtcGxlIGFuPGJyPg0K ICZuYnNwOyBlbmQgc3RhdGlvbiBpcyBtdWx0aS1ob21lZCB0byBtdWx0aXBsZSBSQnJpZGdlcyBu ZWVkcyB0byBpbXByb3ZlDQp0aGU8YnI+DQogJm5ic3A7IHJlc2lsaWVuY3kgYW5kIGluY3JlYXNl IHRoZSBhdmFpbGFibGUgbmV0d29yayBiYW5kd2lkdGggb2YgdGhlPGJyPg0KICZuYnNwOyBjb25u ZWN0aW9uLiAmbmJzcDtUaGlzIG1lYW5zIGFsbCB0aG9zZSBSQnJpZ2VzIGF0dGFjaGVkIHRvIHRo ZQ0KZW5kIHN0YXRpb248YnI+DQogJm5ic3A7IGNhbiBhY3QgYXMgdGhlIGZyYW1lIGZvcndhcmRl cnMgb2YgYSBzcGVjaWZpYyBWTEFOLiAmbmJzcDtUaGlzDQpraW5kIG9mPGJyPg0KICZuYnNwOyBh Y3RpdmUtYWN0aXZlIGNvbm5lY3Rpb24gdmlvbGF0ZXMgdGhlIGRlZmluaXRpb24gYWJvdmUuICZu YnNwO0ZyYW1lPGJyPg0KICZuYnNwOyBkdXBsaWNhdGlvbiBhbmQgZm9yd2FyZGluZyBsb29wcyBt YXkgaGFwcGVuIGFuZCBpdCBtYXkgY2F1c2UgdGhlPGJyPg0KICZuYnNwOyBmbGlwLWZsb3BwaW5n IG9mIHRoZSBlZ3Jlc3MgUkJyaWRnZSBuaWNrbmFtZSBhc3NvY2lhdGVkIHRvIHRoZQ0KTUFDPGJy Pg0KICZuYnNwOyBhZGRyZXNzIG9mIHN1Y2ggYW4gZW5kIHN0YXRpb24gaW4gcmVtb3RlIFJCcmlk Z2VzJyBmb3J3YXJkaW5nIHRhYmxlcy48YnI+DQogJm5ic3A7IFRoZSBSZXZlcnNlIFBhdGggRm9y d2FyZGluZyBDaGVjayBkb2VzIG5vdCB3b3JrIGFzIHdlbGwsIHdoaWNoDQpoYXM8YnI+DQogJm5i c3A7IGJlZW4gYWRkcmVzc2VkIGluIFtDTVRdLiAmbmJzcDtUaGlzIGRvY3VtZW50IHByb3Bvc2Vz IHRoZSBjb25jZXB0DQpvZjxicj4NCiAmbmJzcDsgVmlydHVhbCBSQnJpZGdlLCBhbG9uZyB3aXRo IHRoZSBwc2V1ZG8tbmlja25hbWUgY29uZmlndXJhdGlvbiBmb3I8YnI+DQogJm5ic3A7IHRoaXMg VmlydHVhbCBSQnJpZGdlLCB0byBhZGRyZXNzIHRoZSBhYm92ZSBwcm9ibGVtcyBpbiBhY2NvbXBh bnkNCndpdGg8YnI+DQogJm5ic3A7IFtDTVRdLjxicj4NCjxicj4NCiAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGJyPg0KPGJyPg0K PGJyPg0KVGhlIElFVEYgU2VjcmV0YXJpYXQ8YnI+DQo8YnI+DQo8L2ZvbnQ+PC90dD4NCg== --=_alternative 0036BD3348257AD2_=-- From internet-drafts@ietf.org Wed Dec 12 08:26:03 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52ED721E80DF; Wed, 12 Dec 2012 08:26:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0yoLOF103gUr; Wed, 12 Dec 2012 08:26:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C47FD21E80D3; Wed, 12 Dec 2012 08:25:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121212162556.27149.4308.idtracker@ietfa.amsl.com> Date: Wed, 12 Dec 2012 08:25:56 -0800 Cc: trill@ietf.org Subject: [trill] I-D Action: draft-ietf-trill-fine-labeling-03.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 16:26:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transparent Interconnection of Lots of Li= nks Working Group of the IETF. Title : TRILL: Fine-Grained Labeling Author(s) : Donald Eastlake Mingui Zhang Puneet Agarwal Radia Perlman Dinesh G. Dutt Filename : draft-ietf-trill-fine-labeling-03.txt Pages : 27 Date : 2012-12-12 Abstract: The IETF has standardized TRILL (TRansparent Interconnection of Lots of Links), a protocol for least cost transparent frame routing in multi-hop networks with arbitrary topologies and link technologies, using link-state routing with a hop count. The TRILL base protocol standard supports labeling of TRILL data with up to 4K IDs. However, there are applications that require more fine-grained labeling of data. This document updates RFC 6325 and RFC 6327 by specifying optional extensions to the TRILL base protocol to safely accomplish this. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trill-fine-labeling There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-trill-fine-labeling-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-trill-fine-labeling-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From d3e3e3@gmail.com Wed Dec 12 08:29:42 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25CC421E80D3 for ; Wed, 12 Dec 2012 08:29:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.467 X-Spam-Level: X-Spam-Status: No, score=-103.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyj6z7fVPokc for ; Wed, 12 Dec 2012 08:29:41 -0800 (PST) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFC221F87E3 for ; Wed, 12 Dec 2012 08:29:41 -0800 (PST) Received: by mail-ie0-f179.google.com with SMTP id k14so2191943iea.10 for ; Wed, 12 Dec 2012 08:29:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=ANRE+NilLrE9855y1HK0gE6LVJT2UTTO87Wvn3xI5gw=; b=n9HGCSH2o6XNBK0dy248hPX8fA1uGR7Fr2Ky5+I4mM1K9+uWnLABXcOYRv4wmaCDun 10muuXH7rdIdL1HkpG+yv68aM0xRJ5NTe+5xODY7g4tcAnE4sn80Z8fP+vzYvuz5sQ2l yoAK1qTszfad6r9p+Xti9Zykq/fBrLcUQQZYUY7v5Bui5BAsqtxV6CE4iqnG1X+apBUq fZqzRBR98PxN6T04XTYw2ouRHEojas9QAInZbf9/bZJaukXrtP/tpmGzCWbHvjFFiDQi xL7tYyhBUg+ioytOajJw7WXXTkY5zOfbXjU12XR1Q2TjV1ynSdeHuFjdX3gop7UrOwDu KHNQ== Received: by 10.50.194.131 with SMTP id hw3mr13622142igc.71.1355329781168; Wed, 12 Dec 2012 08:29:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.28.209 with HTTP; Wed, 12 Dec 2012 08:29:20 -0800 (PST) In-Reply-To: <20121212162556.27149.4308.idtracker@ietfa.amsl.com> References: <20121212162556.27149.4308.idtracker@ietfa.amsl.com> From: Donald Eastlake Date: Wed, 12 Dec 2012 11:29:20 -0500 Message-ID: To: trill@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [trill] I-D Action: draft-ietf-trill-fine-labeling-03.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 16:29:42 -0000 This version has substantial editorial changes in response to comments on the list. It is not intended to make technical changes. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Wed, Dec 12, 2012 at 11:25 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: Fine-Grained Labeling > Author(s) : Donald Eastlake > Mingui Zhang > Puneet Agarwal > Radia Perlman > Dinesh G. Dutt > Filename : draft-ietf-trill-fine-labeling-03.txt > Pages : 27 > Date : 2012-12-12 > > Abstract: > The IETF has standardized TRILL (TRansparent Interconnection of Lots > of Links), a protocol for least cost transparent frame routing in > multi-hop networks with arbitrary topologies and link technologies, > using link-state routing with a hop count. The TRILL base protocol > standard supports labeling of TRILL data with up to 4K IDs. However, > there are applications that require more fine-grained labeling of > data. This document updates RFC 6325 and RFC 6327 by specifying > optional extensions to the TRILL base protocol to safely accomplish > this. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-trill-fine-labeling > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-trill-fine-labeling-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-trill-fine-labeling-03 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill From narten@us.ibm.com Wed Dec 12 11:57:29 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 984C021E80F4 for ; Wed, 12 Dec 2012 11:57:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxuDNlAtbt3X for ; Wed, 12 Dec 2012 11:57:27 -0800 (PST) Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) by ietfa.amsl.com (Postfix) with ESMTP id A538C21E808D for ; Wed, 12 Dec 2012 11:57:25 -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 ; Wed, 12 Dec 2012 14:57:25 -0500 Received: from d01dlp01.pok.ibm.com (9.56.250.166) by e7.ny.us.ibm.com (192.168.1.107) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 12 Dec 2012 14:57:13 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 8449538C8045 for ; Wed, 12 Dec 2012 14:57:13 -0500 (EST) Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id qBCJvC0w293948 for ; Wed, 12 Dec 2012 14:57:13 -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 qBCJvCca011660 for ; Wed, 12 Dec 2012 14:57:12 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-49-151-5.mts.ibm.com [9.49.151.5]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id qBCJvBof011572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Dec 2012 14:57:12 -0500 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.5/8.12.5) with ESMTP id qBCJvAcP013288; Wed, 12 Dec 2012 14:57:10 -0500 Message-Id: <201212121957.qBCJvAcP013288@cichlid.raleigh.ibm.com> To: "Tissa Senevirathne (tsenevir)" In-reply-to: References: Comments: In-reply-to "Tissa Senevirathne (tsenevir)" message dated "Wed, 12 Dec 2012 05:27:21 +0000." Date: Wed, 12 Dec 2012 14:57:10 -0500 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12121219-5806-0000-0000-00001CE638EC Cc: Radia Perlman , "trill@ietf.org" Subject: Re: [trill] Thoughts on active-active edge X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 19:57:29 -0000 "Tissa Senevirathne (tsenevir)" writes: > > Proposed rule: R1, R2, and R3 should use the pseudonode nickname > > when encapsulating unicast, but use their own nickname when > > encapsulating multidestination. > > > Result: R8 will see endnode changes for E, but not very frequent; R8 > > will only see changes when traffic from E alternates between > > multidestination and unicast. > [Answer] This depends on the traffic Radia. You cannot assume all > multicast hash to Node R1 and all unicast to R2 and R3 and hence > multicast unicast address ping pong is rare. In the contrary, you > could have heavy multicast stream and a unicast stream both hashing > in to the same RBridge RB1. I'm with Tissa on this one. I'm wary about making assumptions about "likely traffic patterns" and then making architectural decisions based on that. We could easily get burned down the road. > > Question: Are perceived endnode moves a problem? Why? > [Answer] Yes it is big time. Unlike ancient devices modern devices > to hardware based learning. When address association start moving, > it will constantly bombard the CPU with new address or address move > notifications. One thing that would help I think would be to actually list the issues associated "MAC flapping" (i.e., where the FDB entries for a given destination Etherent MAC addr keeps flip flopping) in terms of best egress RB. Are the issues exactly the same as for regular bridges? Or are there additional nuances? What breaks or causes pain when entries flap? Possible issues: 1) the paths packets take for a given destination could switch between 2 (or more) paths. This could lead to out-of-order packet delivery. TCP doesn't like this. OAM may not like it either. (It's one thing to have occasional router flaps, its another to have them be a steady-state feature.) 2) Some implementations require software "help" to update FDB entries. I.e., changes are not done 100% by the ASICs. While that may change in the future, this could be an issue today for some implemntations. How common is this problem? Do we have a sense? What else? Thomas From aldrin.ietf@gmail.com Wed Dec 12 12:18:03 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C195621F8818 for ; Wed, 12 Dec 2012 12:18:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7tfTAv7Sn6E for ; Wed, 12 Dec 2012 12:17:57 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5C69421F880A for ; Wed, 12 Dec 2012 12:17:57 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id z20so362509dae.31 for ; Wed, 12 Dec 2012 12:17:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=v/TXA7pnkYociIfiO2PvIdxxq25rVDR3inkhnJ3CSUY=; b=VlTG0z3LGJYHFn6ZB1TTBepif5gHKznBoUKygoXIIlaDgBzFjoLWivBgstCjsMjmfl hiCtK4hSWG3hHBlh2UbIn1hpcw5aSNZoB//JyreHvSKNoMP4cYu6GpLW7O/u5eUZNeKu vFwYiCmL3ksREOiEuW16YrZbi66ASW6pcJIrZLyrPm/aGu0lM9HJqFHT9uCEwpIBAYix vYwltlu154bz5u00ul8LCVi/z9aZfbWQJwo3AS9/uN6c8gMvTvGoKmObvoSYa1qtQ3ez B/wDhFEoG2YQsZKIUUP3SFkx2DB7WJvEjptYri8vwJRbZPHTtRlChiEFGsxO2G3R2Eh5 L6jg== Received: by 10.68.190.38 with SMTP id gn6mr5826301pbc.6.1355343476600; Wed, 12 Dec 2012 12:17:56 -0800 (PST) Received: from [192.168.255.135] (107-1-141-74-ip-static.hfc.comcastbusiness.net. [107.1.141.74]) by mx.google.com with ESMTPS id j9sm16352470paw.2.2012.12.12.12.17.52 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 12 Dec 2012 12:17:53 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Sam Aldrin In-Reply-To: <4552F0907735844E9204A62BBDD325E732138B02@SZXEML507-MBS.china.huawei.com> Date: Wed, 12 Dec 2012 12:17:52 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4552F0907735844E9204A62BBDD325E732138B02@SZXEML507-MBS.china.huawei.com> To: Mingui Zhang X-Mailer: Apple Mail (2.1499) Cc: "Tissa Senevirathne \(tsenevir\)" , Radia Perlman , "trill@ietf.org" Subject: Re: [trill] Thoughts on active-active edge X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 20:18:03 -0000 I agree with Mingui and Tissa on this. Intentionally creating architecture change to have MAC move scenario is = something not at all a good idea. Also, reasoning that only edge or participating RBridges requires = hardware changes is not a good argument for advantage either, because, = that depends on topology and deployment scenario, not architecturally = better. Eventually, that change has to be on all RB's anyway, because of silicon = and other changes. I am more concerned the load balancing of the traffic, which is a = potential issue, and cannot be ignored. One point to consider with any solution is from OAM angle. = Operationally, how this (any solution) could impact the behavior and the = cost associated with this. I believe we have discussed these scenarios (different solution types) = previously.=20 WG should reach consensus and move forward with the agreed solution.=20 Atleast from the IETF WG sessions, I presumed there was a consensus on = the solution.=20 Am I wrong in that assumption? cheers -sam On Dec 11, 2012, at 10:46 PM, Mingui Zhang = wrote: > Hi, >=20 > I think the MAC move affects the path selection at the remote RBridge = 'R8', which may bring frame disorder at the endnode 'E' connected to the = active-active edge.=20 >=20 > The new proposal suggests that one group occupies one pseudo-node = nickname. If "use up the nickname space" is really a problem, the new = proposal suffers from this problem, right? Having said that, I want to = argue that we have to identify each active-active edge with a = pseudo-node nickname in either proposal AND the consumption of nicknames = on active-active edge is not a big problem. >=20 > Thanks, > Mingui=20 >=20 >> -----Original Message----- >> From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On = Behalf Of Tissa >> Senevirathne (tsenevir) >> Sent: Wednesday, December 12, 2012 2:11 PM >> To: Radia Perlman >> Cc: trill@ietf.org >> Subject: Re: [trill] Thoughts on active-active edge >>=20 >> Radia >>=20 >>=20 >>=20 >> Please see in line >>=20 >>=20 >>=20 >> From: Radia Perlman [mailto:radiaperlman@gmail.com] >> Sent: Tuesday, December 11, 2012 10:00 PM >> To: Tissa Senevirathne (tsenevir) >> Cc: trill@ietf.org >> Subject: Re: [trill] Thoughts on active-active edge >>=20 >>=20 >>=20 >> Tissa, there are always technical tradeoffs between approaches. >>=20 >>=20 >>=20 >> Tissa said: >>=20 >>>> [Answer] This depends on the traffic Radia. You cannot assume all = multicast >> hash to Node R1 and all unicast to >>R2 and R3 and hence multicast = unicast >> address ping pong is rare. In the contrary, you could have heavy = >>multicast >> stream and a unicast stream both hashing in to the same RBridge RB1. >>=20 >>=20 >>=20 >> I'm not sure what relevance there is to whether unicast hashes to R1, = R2, R3, or >> alternates between them, since the rule is that they all use the = pseudonode >> nickname when ingressing from E. The only way there will be frequent = endnode >> moves for E is if E frequently alternates sending multicast and = unicast. All >> unicast from E, whether it is sent to R1, R2, or R3, will be = perceived by R8 as >> coming from pseudonode P. Multicast, on the other hand, with the = proposed >> rule, could bounce between R1, R2, and R3. Though as an = optimization, if the >> pseudonode P is attached to R2, then R2 could use P when ingressing = either >> unicast or multicast, so multicast that happens to hash to R2 will = not be >> perceived as an endnode move, whereas multicast hashing to R1 or R3 = would. >>=20 >>=20 >>=20 >>=20 >>=20 >> [Answer-2] Are you saying E will not simultaneously send multicast = and unicast ? >> are you also suggesting there is either a single multicast stream or = all multicast >> streams are hashing to the same RBridge that E is attached to ? >>=20 >>=20 >>=20 >> Tissa said about why endnode moves are a problem: >>=20 >>=20 >>=20 >>>> [Answer] Yes it is big time. Unlike ancient devices modern devices = to >> hardware based learning. When address >>association start moving, it = will >> constantly bombard the CPU with new address or address move = notifications. >>=20 >>=20 >>=20 >> Your description sounds to me like it's only a problem if there are a = lot of moves. >> Since it seems unlikely that E will keep alternating between sending = multicast >> and unicast, or even if there were one node that was doing that for = some reason, >> that there would be lots of nodes acting this way, it seems like the = amount of >> moves seen, relative to the total amount of traffic received by R8, = should be >> really small. >>=20 >>=20 >>=20 >> [Answer-2] It is not lots of switches it is how many ping-pong, with = a single >> address and two stream you can overload learning buffers when traffic = is coming >> at high rates. >>=20 >>=20 >>=20 >> So, the disadvantages of this proposal, as Sunny pointed out, are >>=20 >> 1) the active-active RBs might need a hardware change in order to = selectively >> use a different ingress nickname depending on whether the packet is = multicast >> or unicast (which implementations is this true for?) >>=20 >> 2) distant RBs (say R8), will perceive E moving when E switches from = sending >> unicast to multicast. >>=20 >>=20 >>=20 >> [Answer-2] #2 is exactly what I am saying as a big problem. But if = you feel it is >> not a problem, I am not going to argue any further. You should speak = to few >> more people and get the validation. ***Address move is a major = problem** >>=20 >>=20 >>=20 >> But as I said, all approaches have pluses and minuses, so the minuses = have to be >> weighed against the pluses. >>=20 >>=20 >>=20 >> The advantages of this proposed approach relative to the Affinity TLV = are: >>=20 >>=20 >>=20 >> a) you only need one tree for the campus, and you can have = arbitrarily many >> active-active nodes. Or to put it a different way, you can have more >> active-active RBs than there are trees. >>=20 >>=20 >>=20 >> b) furthermore, it allows the active-active RBs to do load splitting = of multicast >> (choosing more than one tree), without requiring n*k trees, where n = is the >> number of active-active RBs, and k is the number of trees each might = want to >> use for load splitting. >>=20 >>=20 >>=20 >> c) you don't need all RBs to change at once in the campus (as you = would with the >> Affinity proposal). If R8 is unmodified, R8 will see E changing when = E changes >> from multicast to unicast, but will not have incorrect behavior. = With affinity, >> absolutely every RB in the campus must be modified or there will be = incorrect >> (not just suboptimal) behavior. >>=20 >>=20 >>=20 >>=20 >>=20 >> Radia >=20 > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill From narten@us.ibm.com Wed Dec 12 12:26:50 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92BDD1F0CC1 for ; Wed, 12 Dec 2012 12:26:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lT+wYeZNM-P7 for ; Wed, 12 Dec 2012 12:26:45 -0800 (PST) Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) by ietfa.amsl.com (Postfix) with ESMTP id 204A81F0CD6 for ; Wed, 12 Dec 2012 12:26:43 -0800 (PST) Received: from /spool/local by e37.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 12 Dec 2012 13:26:42 -0700 Received: from d03dlp02.boulder.ibm.com (9.17.202.178) by e37.co.us.ibm.com (192.168.1.137) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 12 Dec 2012 13:26:39 -0700 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id D612B3E40060 for ; Wed, 12 Dec 2012 13:26:34 -0700 (MST) Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id qBCKQKsK043400 for ; Wed, 12 Dec 2012 13:26:27 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id qBCKPrZu031207 for ; Wed, 12 Dec 2012 13:25:55 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-49-151-5.mts.ibm.com [9.49.151.5]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id qBCKPo1L030904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Dec 2012 13:25:52 -0700 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.5/8.12.5) with ESMTP id qBCKPmM7013618; Wed, 12 Dec 2012 15:25:48 -0500 Message-Id: <201212122025.qBCKPmM7013618@cichlid.raleigh.ibm.com> To: Sam Aldrin In-reply-to: References: <4552F0907735844E9204A62BBDD325E732138B02@SZXEML507-MBS.china.huawei.com> Comments: In-reply-to Sam Aldrin message dated "Wed, 12 Dec 2012 12:17:52 -0800." Date: Wed, 12 Dec 2012 15:25:48 -0500 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12121220-7408-0000-0000-00000AF9BC62 Cc: "Tissa Senevirathne \(tsenevir\)" , Mingui Zhang , Radia Perlman , "trill@ietf.org" Subject: Re: [trill] Thoughts on active-active edge X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 20:26:50 -0000 > I believe we have discussed these scenarios (different solution > types) previously. WG should reach consensus and move forward with > the agreed solution. Atleast from the IETF WG sessions, I presumed > there was a consensus on the solution. Am I wrong in that > assumption? what "solution" are you referring above as maybe having consensus? Thomas From aldrin.ietf@gmail.com Wed Dec 12 12:41:41 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB3C21F8A5D for ; Wed, 12 Dec 2012 12:41:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.424 X-Spam-Level: X-Spam-Status: No, score=-3.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZuBHFCwrh-W for ; Wed, 12 Dec 2012 12:41:35 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 124CA21F8A5A for ; Wed, 12 Dec 2012 12:41:35 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id z20so369314dae.31 for ; Wed, 12 Dec 2012 12:41:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=ZFMfO/ocVOHS2fqofkyontsYwU4Ex5UqE8lWOyxBj/s=; b=ZQxAcV9xyYE5GCQvugLiK2yKpKx8Z8Qc/eEIb+9BJwoEvuGwReaqhnK74yx4XiEuvJ umayX6hRWWmwyw2hpwBfTphPu2mEVRC7DWKjwAV/mI3jteSeZjp0DryVIJWHPtkqIxof 2aNVe6ko3cXJHOu0cZqxdTQJzXLE3I7KmKLBGpxajp9YZUm/KFOGHvRYpShTurSEv3GX ZFm2nQ9F6LMaZAFL3AklL3XkX4T9UlgSgqScWf2wPpdfodOYL+CC88+YkTvGw5x1z25O CZTbqnFYrnVLN6BEnXF5lOhZVMS8yj3go5pUnOKSdKh2WuTKu2Twipy8MXtztwh8Tqto sMWQ== Received: by 10.66.77.105 with SMTP id r9mr5616222paw.76.1355344894083; Wed, 12 Dec 2012 12:41:34 -0800 (PST) Received: from [192.168.1.9] (c-98-248-237-85.hsd1.ca.comcast.net. [98.248.237.85]) by mx.google.com with ESMTPS id oj1sm16198152pbb.19.2012.12.12.12.41.32 (version=SSLv3 cipher=OTHER); Wed, 12 Dec 2012 12:41:33 -0800 (PST) References: <4552F0907735844E9204A62BBDD325E732138B02@SZXEML507-MBS.china.huawei.com> <201212122025.qBCKPmM7013618@cichlid.raleigh.ibm.com> Mime-Version: 1.0 (1.0) In-Reply-To: <201212122025.qBCKPmM7013618@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <0E430FEE-F2AD-4EA0-9E98-50762B563E9B@gmail.com> X-Mailer: iPhone Mail (10A525) From: Sam Aldrin Date: Wed, 12 Dec 2012 12:41:30 -0800 To: Thomas Narten Cc: "Tissa Senevirathne \(tsenevir\)" , Mingui Zhang , Radia Perlman , "trill@ietf.org" Subject: Re: [trill] Thoughts on active-active edge X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 20:41:41 -0000 Cmt draft Sent from my iPhone On Dec 12, 2012, at 12:25 PM, Thomas Narten wrote: >> I believe we have discussed these scenarios (different solution >> types) previously. WG should reach consensus and move forward with >> the agreed solution. Atleast from the IETF WG sessions, I presumed >> there was a consensus on the solution. Am I wrong in that >> assumption? > > what "solution" are you referring above as maybe having consensus? > > Thomas > From narten@us.ibm.com Wed Dec 12 14:57:49 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3854721F8797 for ; Wed, 12 Dec 2012 14:57:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+c9XrhgaziW for ; Wed, 12 Dec 2012 14:57:48 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by ietfa.amsl.com (Postfix) with ESMTP id 746E521F8675 for ; Wed, 12 Dec 2012 14:57:47 -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 ; Wed, 12 Dec 2012 15:57:47 -0700 Received: from d03dlp01.boulder.ibm.com (9.17.202.177) by e32.co.us.ibm.com (192.168.1.132) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 12 Dec 2012 15:57:45 -0700 Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id CDB5C1FF0043 for ; Wed, 12 Dec 2012 15:57:37 -0700 (MST) Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id qBCMvg9C261754 for ; Wed, 12 Dec 2012 15:57:43 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id qBCMvfI5006022 for ; Wed, 12 Dec 2012 15:57:42 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-49-151-5.mts.ibm.com [9.49.151.5]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id qBCMve70005963; Wed, 12 Dec 2012 15:57:41 -0700 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.5/8.12.5) with ESMTP id qBCMvdeW014734; Wed, 12 Dec 2012 17:57:39 -0500 Message-Id: <201212122257.qBCMvdeW014734@cichlid.raleigh.ibm.com> To: Sam Aldrin In-reply-to: <0E430FEE-F2AD-4EA0-9E98-50762B563E9B@gmail.com> References: <4552F0907735844E9204A62BBDD325E732138B02@SZXEML507-MBS.china.huawei.com> <201212122025.qBCKPmM7013618@cichlid.raleigh.ibm.com> <0E430FEE-F2AD-4EA0-9E98-50762B563E9B@gmail.com> Comments: In-reply-to Sam Aldrin message dated "Wed, 12 Dec 2012 12:41:30 -0800." Date: Wed, 12 Dec 2012 17:57:39 -0500 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12121222-5406-0000-0000-000003160DEB Cc: "Tissa Senevirathne \(tsenevir\)" , Mingui Zhang , Radia Perlman , "trill@ietf.org" Subject: Re: [trill] Thoughts on active-active edge X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 22:57:49 -0000 Sam Aldrin writes: > On Dec 12, 2012, at 12:25 PM, Thomas Narten wrote: > >> I believe we have discussed these scenarios (different solution > >> types) previously. WG should reach consensus and move forward with > >> the agreed solution. Atleast from the IETF WG sessions, I presumed > >> there was a consensus on the solution. Am I wrong in that > >> assumption? > > > > what "solution" are you referring above as maybe having consensus? > Cmt draft If you mean draft-ietf-trill-cmt-01.txt, I at least am not in agreement. I have several issues with the document. For starters, it's incomplete. It needs to be paired with another document to get an actual "standard" you can implement. We don't have such a companion document yet. It's been suggested that draft-hu-trill-pseudonode-nickname-04.txt is one such document. But that document is not a WG document and I'm not sure what its status is. (And it needs work...) As a general rule (not TRILL specific) I don't like WGs doing "partial work" where they standardize one document, that is incomplete by itself, independent of other documents that are needed to produce a complete implementable solution to some real problem. I've raised issues on the list about CMT and its unclarity wrt. LAG/MC-LAG, etc. I did not really get my questions answered. What I'd really like to start with on CMT is a clear problem statement. I.e., exactly what problem/use case it is trying to solve. I have not been able to get that out of the two documents. As for draft-hu-trill-pseudonode-nickname-04.txt, I have other concerns. E.g., it talks about tunneling at one point, but that is completely unspecified. What I don't want to do is spend a lot of time on the *solution* details. I first want a clear problem statement/use case. Without that, it is difficult to assess how well potential solutions address the stated problem. Thomas From tsenevir@cisco.com Wed Dec 12 15:14:21 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B60AB21E8054 for ; Wed, 12 Dec 2012 15:14:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.017 X-Spam-Level: X-Spam-Status: No, score=-9.017 tagged_above=-999 required=5 tests=[AWL=1.582, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id penpgwVxRtYW for ; Wed, 12 Dec 2012 15:14:20 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id D22C41F0CC5 for ; Wed, 12 Dec 2012 15:14:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2781; q=dns/txt; s=iport; t=1355354058; x=1356563658; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=hzuiGoVIkL91VhSEITyoUIC2fmXTveqQa7PJopuZwpM=; b=WNCrLsFmFDvJ/rbTfYlab7dARpxoPmJ7fyi2TNvI50uh80khbNoEZ5Pe Kf3k2eeshctB45D9c8LGGDs1eaQqubfHbLBnCjifNgbfRO3OBGFpNrsv1 sANpM70pMKXeXhNJKaKbaKKK08Q+6zs3VysNz2i+fGZyccyWg6XPjL0TN 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAFIPyVCtJV2d/2dsb2JhbABFvnAWc4IeAQEBAwE6PwUHBAIBCBEEAQELFAkHIREUCQgCBAENBQgTh2QDCQa0LQ2JVYtiaYNiYQOUM40NhRGCc4Ii X-IronPort-AV: E=Sophos;i="4.84,269,1355097600"; d="scan'208";a="152360441" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 12 Dec 2012 23:14:18 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qBCNEIsU010073 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Dec 2012 23:14:18 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.240]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Wed, 12 Dec 2012 17:14:17 -0600 From: "Tissa Senevirathne (tsenevir)" To: Thomas Narten , Sam Aldrin Thread-Topic: [trill] Thoughts on active-active edge Thread-Index: AQHN1+GJAcUGAj4DtkSKdF8jmxk4o5gUnyzwgABxZQD//5vnwIAAcUyAgADilACAAAI4AIAABGIAgAAmC4D//516wA== Date: Wed, 12 Dec 2012 23:14:16 +0000 Message-ID: References: <4552F0907735844E9204A62BBDD325E732138B02@SZXEML507-MBS.china.huawei.com> <201212122025.qBCKPmM7013618@cichlid.raleigh.ibm.com> <0E430FEE-F2AD-4EA0-9E98-50762B563E9B@gmail.com> <201212122257.qBCMvdeW014734@cichlid.raleigh.ibm.com> In-Reply-To: <201212122257.qBCMvdeW014734@cichlid.raleigh.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.155.1.164] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Mingui Zhang , Radia Perlman , "trill@ietf.org" Subject: Re: [trill] Thoughts on active-active edge X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 23:14:21 -0000 I think we should answer the question in hand first. This thread is all about "saying it is ok to have MAC move in TRILL to solv= e active-active edge" I am overwhelmingly against that statement and the argument for it is all b= ased on whole series of assumptions and ignoring the modern networking devi= ces and how they operate. Once that is resolved and behind we can have a separate discussion of CMT, = hu draft and future approach etc. Thanks Tissa -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com]=20 Sent: Wednesday, December 12, 2012 2:58 PM To: Sam Aldrin Cc: Mingui Zhang; Tissa Senevirathne (tsenevir); Radia Perlman; trill@ietf.= org Subject: Re: [trill] Thoughts on active-active edge Sam Aldrin writes: > On Dec 12, 2012, at 12:25 PM, Thomas Narten wrote: > >> I believe we have discussed these scenarios (different solution > >> types) previously. WG should reach consensus and move forward with=20 > >> the agreed solution. Atleast from the IETF WG sessions, I presumed=20 > >> there was a consensus on the solution. Am I wrong in that=20 > >> assumption? > >=20 > > what "solution" are you referring above as maybe having consensus? > Cmt draft If you mean draft-ietf-trill-cmt-01.txt, I at least am not in agreement. I have several issues with the document. For starters, it's incomplete. It needs to be paired with another document = to get an actual "standard" you can implement. We don't have such a compani= on document yet. It's been suggested that draft-hu-trill-pseudonode-nickna= me-04.txt is one such document. But that document is not a WG document and = I'm not sure what its status is. (And it needs work...) As a general rule (not TRILL specific) I don't like WGs doing "partial work= " where they standardize one document, that is incomplete by itself, indepe= ndent of other documents that are needed to produce a complete implementabl= e solution to some real problem. I've raised issues on the list about CMT and its unclarity wrt. LAG/MC-LAG,= etc. I did not really get my questions answered. What I'd really like to start with on CMT is a clear problem statement. I.e= ., exactly what problem/use case it is trying to solve. I have not been abl= e to get that out of the two documents. As for draft-hu-trill-pseudonode-nickname-04.txt, I have other concerns. E.= g., it talks about tunneling at one point, but that is completely unspecifi= ed. What I don't want to do is spend a lot of time on the *solution* details. I= first want a clear problem statement/use case. Without that, it is difficu= lt to assess how well potential solutions address the stated problem. Thomas =20 From aldrin.ietf@gmail.com Wed Dec 12 15:18:06 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 801FF21F842D for ; Wed, 12 Dec 2012 15:18:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0+pu-oJfS2P for ; Wed, 12 Dec 2012 15:18:03 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6E70521F8168 for ; Wed, 12 Dec 2012 15:17:51 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id hz11so974918pad.31 for ; Wed, 12 Dec 2012 15:17:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=1KckAQkdG7L2ASp5HCYY/xnmLHr8uudizcFTaaRYP7Q=; b=LYsdXSrcFRekNoYvNerWBi68bZc6Ckk4gVHLWt3iI7KEsOL+7o9uhV8Knp5cf+7K4I WPEravQ5YgxS6ZMKCkEt43bCv/aEfo7PnRItKxCCFqOOjZ4ZxGGASYWXCqWhhptT1FCD 1hHosBpsBXqXla+ysg6ZP8sY2hIBUZFJHjMz7uumY1vXm8i1cr3tKJB8PXzZrU0uXDdl DKbzTmtSh54eS4DnO3jIWINXHxOuHN0txu1ZYrSWxi0jjDLvO3uX9YKlBVuS9ecqk4Oh U/sCs4QhTLVmesoSZwnv4G6D1f53wvezxook5fnKvF0xPadbV/6LavRz20KzBKvvDLIx 0+yQ== Received: by 10.68.225.101 with SMTP id rj5mr6986423pbc.66.1355354271208; Wed, 12 Dec 2012 15:17:51 -0800 (PST) Received: from [192.168.255.135] (107-1-141-74-ip-static.hfc.comcastbusiness.net. [107.1.141.74]) by mx.google.com with ESMTPS id bh9sm45037pab.12.2012.12.12.15.17.48 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 12 Dec 2012 15:17:50 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Sam Aldrin In-Reply-To: <201212122257.qBCMvdeW014734@cichlid.raleigh.ibm.com> Date: Wed, 12 Dec 2012 15:17:45 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1F0D8677-0843-45D5-8FEE-6F196172554D@gmail.com> References: <4552F0907735844E9204A62BBDD325E732138B02@SZXEML507-MBS.china.huawei.com> <201212122025.qBCKPmM7013618@cichlid.raleigh.ibm.com> <0E430FEE-F2AD-4EA0-9E98-50762B563E9B@gmail.com> <201212122257.qBCMvdeW014734@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1499) Cc: "Tissa Senevirathne \(tsenevir\)" , Mingui Zhang , Radia Perlman , "trill@ietf.org" Subject: Re: [trill] Thoughts on active-active edge X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 23:18:06 -0000 Comments inline. -sam On Dec 12, 2012, at 2:57 PM, Thomas Narten wrote: >=20 > Sam Aldrin writes: >=20 >> On Dec 12, 2012, at 12:25 PM, Thomas Narten = wrote: >=20 >>>> I believe we have discussed these scenarios (different solution >>>> types) previously. WG should reach consensus and move forward with >>>> the agreed solution. Atleast from the IETF WG sessions, I presumed >>>> there was a consensus on the solution. Am I wrong in that >>>> assumption? >>>=20 >>> what "solution" are you referring above as maybe having consensus? >=20 >> Cmt draft >=20 > If you mean draft-ietf-trill-cmt-01.txt, I at least am not in > agreement. %sam- that is the draft. >=20 > I have several issues with the document. %sam - Good time to raise them again and discuss within WG as it is WG = doc. >=20 > For starters, it's incomplete. It needs to be paired with another > document to get an actual "standard" you can implement. We don't have > such a companion document yet. It's been suggested that > draft-hu-trill-pseudonode-nickname-04.txt is one such document. But > that document is not a WG document and I'm not sure what its status > is. (And it needs work...) >=20 > As a general rule (not TRILL specific) I don't like WGs doing "partial > work" where they standardize one document, that is incomplete by > itself, independent of other documents that are needed to produce a > complete implementable solution to some real problem. %sam - In this context, I am not aligned with you. The reason the = document was adopted as WG, is because the problem was identified and = agreed upon. Partial problem or full problem depends on how one sees it. One can also = claim to have one singe 'TRILL' solution document, instead of multiple = drafts targeting subset of TRILL problems. >=20 > I've raised issues on the list about CMT and its unclarity > wrt. LAG/MC-LAG, etc. I did not really get my questions answered. %sam - Authors could clarify. Sorry I am not co-author of any of these = docs :D >=20 > What I'd really like to start with on CMT is a clear problem > statement. I.e., exactly what problem/use case it is trying to > solve. I have not been able to get that out of the two documents. >=20 > As for draft-hu-trill-pseudonode-nickname-04.txt, I have other > concerns. E.g., it talks about tunneling at one point, but that is > completely unspecified. >=20 > What I don't want to do is spend a lot of time on the *solution* > details. I first want a clear problem statement/use case. Without > that, it is difficult to assess how well potential solutions address > the stated problem. %sam - In regards to CMT draft, I understood the problem scope. If = something is not clear, do outline your question and authors have = responsibility to clarify. -sam >=20 > Thomas >=20 >=20 From zhangmingui@huawei.com Wed Dec 12 22:03:31 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98CBC21F88B6 for ; Wed, 12 Dec 2012 22:03:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DesVP9Q4U2ZE for ; Wed, 12 Dec 2012 22:03:30 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 645B221F88B2 for ; Wed, 12 Dec 2012 22:03:29 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANU23284; Thu, 13 Dec 2012 06:03:23 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 13 Dec 2012 06:02:35 +0000 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 13 Dec 2012 06:03:22 +0000 Received: from SZXEML507-MBS.china.huawei.com ([169.254.7.234]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0323.003; Thu, 13 Dec 2012 14:03:18 +0800 From: Mingui Zhang To: Thomas Narten , Sam Aldrin Thread-Topic: [trill] Thoughts on active-active edge Thread-Index: AQHN1+GKKCdMCC4LGEWia3k7aW76oZgUHNiAgAAJBwCAAAMhAIAAh2BggABlRwCAAAI3AIAABGMAgAAmCoCAAPnwUA== Date: Thu, 13 Dec 2012 06:03:18 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E732139D5A@SZXEML507-MBS.china.huawei.com> References: <4552F0907735844E9204A62BBDD325E732138B02@SZXEML507-MBS.china.huawei.com> <201212122025.qBCKPmM7013618@cichlid.raleigh.ibm.com> <0E430FEE-F2AD-4EA0-9E98-50762B563E9B@gmail.com> <201212122257.qBCMvdeW014734@cichlid.raleigh.ibm.com> In-Reply-To: <201212122257.qBCMvdeW014734@cichlid.raleigh.ibm.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.185] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Tissa Senevirathne \(tsenevir\)" , Radia Perlman , "trill@ietf.org" Subject: Re: [trill] Thoughts on active-active edge X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 06:03:31 -0000 Hi Thomas, The whole problem is how to provide end-nodes (end-stations or LAGs) with a= mechanism of active-active access into the TRILL campus. The baseline requ= irement for this mechanism is that traffic duplication or loops MUST be avo= ided. However, as the mechanism is being developed, new problems appear. I'= d like to list those problems as follows.=20 1. RPFC issue.=20 The CMT draft addresses this issue.=20 2. Nickname configuration It is necessary to denote the active-active edge group with a virtual RBrid= ge, say RBv. The member RBridges act as the agents of the nickname allocati= on for RBv and they MUST act in consistence. As defined in RFC6325, pseudonode nickname is actually allocated by the DRB= . DRB is elected through exchanging HELLOs. The LAG or end-station is not a= LAN anymore. As a result, no HELLOs can be exchanged on it. No HELLO no DR= B. So, a new pseudonode nickname allocation method is needed. 3. MAC sharing=20 The MAC addressed learnt by one member RB should be synchronized up with ot= her RBs in the same group. Or else, if a frame destined to such a MAC is vi= a other RBs, it will cause unnecessary unknown unicast. 4. Failure recovery When a member RBridge or link fails, how does the whole active-active edge = group response? A method is needed here to automate that process.=20 I am OK with the idea to compose a problem statement draft. However, IMO, i= t is impossible to provide _one_ solution draft to solve all these problems= . Thanks, Mingui >-----Original Message----- >From: Thomas Narten [mailto:narten@us.ibm.com] >Sent: Thursday, December 13, 2012 6:58 AM >To: Sam Aldrin >Cc: Mingui Zhang; Tissa Senevirathne (tsenevir); Radia Perlman; trill@ietf= .org >Subject: Re: [trill] Thoughts on active-active edge > > >Sam Aldrin writes: > >> On Dec 12, 2012, at 12:25 PM, Thomas Narten wrote: > >> >> I believe we have discussed these scenarios (different solution >> >> types) previously. WG should reach consensus and move forward with >> >> the agreed solution. Atleast from the IETF WG sessions, I presumed >> >> there was a consensus on the solution. Am I wrong in that >> >> assumption? >> > >> > what "solution" are you referring above as maybe having consensus? > >> Cmt draft > >If you mean draft-ietf-trill-cmt-01.txt, I at least am not in >agreement. > >I have several issues with the document. > >For starters, it's incomplete. It needs to be paired with another >document to get an actual "standard" you can implement. We don't have >such a companion document yet. It's been suggested that >draft-hu-trill-pseudonode-nickname-04.txt is one such document. But >that document is not a WG document and I'm not sure what its status >is. (And it needs work...) > >As a general rule (not TRILL specific) I don't like WGs doing "partial >work" where they standardize one document, that is incomplete by >itself, independent of other documents that are needed to produce a >complete implementable solution to some real problem. > >I've raised issues on the list about CMT and its unclarity >wrt. LAG/MC-LAG, etc. I did not really get my questions answered. > >What I'd really like to start with on CMT is a clear problem >statement. I.e., exactly what problem/use case it is trying to >solve. I have not been able to get that out of the two documents. > >As for draft-hu-trill-pseudonode-nickname-04.txt, I have other >concerns. E.g., it talks about tunneling at one point, but that is >completely unspecified. > >What I don't want to do is spend a lot of time on the *solution* >details. I first want a clear problem statement/use case. Without >that, it is difficult to assess how well potential solutions address >the stated problem. > >Thomas > From radiaperlman@gmail.com Wed Dec 12 23:13:23 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4389921F8AA3 for ; Wed, 12 Dec 2012 23:13:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Swgn+2B9BD7o for ; Wed, 12 Dec 2012 23:13:22 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A58FF21F8A88 for ; Wed, 12 Dec 2012 23:13:21 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so1801252vcb.31 for ; Wed, 12 Dec 2012 23:13:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nRGbzWnEO16euG3kY5IiDkXQi48spteYLsw40ysNX5E=; b=uqpinxOgN2BiQPWVj7J7/cc3pmnKXmMKiFRm82lwbc6Id6qe3bkQsKG3T5wGhQlpVI YZSgzlZWH4OcBHkcZErHbiqjiDuvPEljWG/D+El0A3lqsuGUMaPYsaPyjPZc+miB4vck 1K/HZpwTno8BtxVYt/mkkiqD23XcjPknbDlyQA3dxjBwmVmuXwmBPFJnwKd/Cd+LHoqJ 9XsvOcCjMEguRONVV3QPBSaKQX9fzxXrKxFva7QNEnPI0KNtQID+POR4uz/hnH/gM91o 2GAtwyRL2eb38J1DPPvh1ESLHssb69FfsnHMe6a/I+YGL4Gdr2Wxuj07/Vpres+BBrra l0ug== MIME-Version: 1.0 Received: by 10.52.97.104 with SMTP id dz8mr1348972vdb.21.1355382801102; Wed, 12 Dec 2012 23:13:21 -0800 (PST) Received: by 10.58.207.138 with HTTP; Wed, 12 Dec 2012 23:13:20 -0800 (PST) In-Reply-To: <4552F0907735844E9204A62BBDD325E732139D5A@SZXEML507-MBS.china.huawei.com> References: <4552F0907735844E9204A62BBDD325E732138B02@SZXEML507-MBS.china.huawei.com> <201212122025.qBCKPmM7013618@cichlid.raleigh.ibm.com> <0E430FEE-F2AD-4EA0-9E98-50762B563E9B@gmail.com> <201212122257.qBCMvdeW014734@cichlid.raleigh.ibm.com> <4552F0907735844E9204A62BBDD325E732139D5A@SZXEML507-MBS.china.huawei.com> Date: Wed, 12 Dec 2012 23:13:20 -0800 Message-ID: From: Radia Perlman To: Mingui Zhang Content-Type: multipart/alternative; boundary=20cf307f35f464f78e04d0b6a621 Cc: Thomas Narten , Sam Aldrin , "Tissa Senevirathne \(tsenevir\)" , "trill@ietf.org" Subject: Re: [trill] Thoughts on active-active edge X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 07:13:23 -0000 --20cf307f35f464f78e04d0b6a621 Content-Type: text/plain; charset=ISO-8859-1 I think it would be good to have a document that explains the problem...I certainly don't believe I know all the cases that need to be solved. I think I understand the hypervisor case...where the hypervisor decides which uplink to send things to, and never forwards between the up-links. This case is scary because the RBridges on the uplink cannot see Hellos from each other, so if misconfigured, at the very least I could imagine multiple RBridges decapsulating multicast from the campus to the hypervisor. Anyway...how many uplinks do we need to support? Do we care about problems due to misconfiguration? In cases like this, is it common to also have pt-to-pt links between all the RBs attaching to the hypervisor? If so, then it seems like it would be possible for them to coordinate to at least detect misconfiguration, and possibly play games with forwarding messages to each other (e.g., if one of them is not attached to a tree and needs to encapsulate a multidestination frame). How many trees does the campus need? Are there cases where there are lots of hypervisors, where they attach to different subsets of edge RBs? In that case, we might eat up a lot of nicknames, since if one hypervisor is attached to {R1, R2}, and another is attached to {R1, R2, R3}, they cannot use the same pseudonode nickname. Are there cases other than hypervisors? I think there are cases of bridges that have this behavior (a port with a bunch of endnodes, and several up-links, where the bridge does not forward between the up-links. If this has been written down anywhere, can anyone point me to it? If not, it seems really prudent to answer these (and I'm sure other) questions before arguing about specific solutions. Radia --20cf307f35f464f78e04d0b6a621 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think it would be good to have a document that explains the problem...I c= ertainly don't believe I know all the cases that need to be solved. =A0= I think I understand the hypervisor case...where the hypervisor decides whi= ch uplink to send things to, and never forwards between the up-links.

This case is scary because the RBridges on the uplink cannot= see Hellos from each other, so if misconfigured, at the very least I could= imagine multiple RBridges decapsulating multicast from the campus to the h= ypervisor.

Anyway...how many uplinks do we need to support? =A0Do = we care about problems due to misconfiguration?

In= cases like this, is it common to also have pt-to-pt links between all the = RBs attaching to the hypervisor? =A0If so, then it seems like it would be p= ossible for them to coordinate to at least detect misconfiguration, and pos= sibly play games with forwarding messages to each other (e.g., if one of th= em is not attached to a tree and needs to encapsulate a multidestination fr= ame).

How many trees does the campus need?

Are there cases where there are lots of hypervisors, where they atta= ch to different subsets of edge RBs? =A0In that case, we might eat up a lot= of nicknames, since if one hypervisor is attached to {R1, R2}, and another= is attached to {R1, R2, R3}, they cannot use the same pseudonode nickname.=

Are there cases other than hypervisors? =A0I think ther= e are cases of bridges that have this behavior (a port with a bunch of endn= odes, and several up-links, where the bridge does not forward between the u= p-links. =A0

If this has been written down anywhere, can anyone poin= t me to it? =A0If not, it seems really prudent to answer these (and I'm= sure other) questions before arguing about specific solutions.

Radia


--20cf307f35f464f78e04d0b6a621-- From zhai.hongjun@zte.com.cn Thu Dec 13 00:13:43 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3F4D21F8A56; Thu, 13 Dec 2012 00:13:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.999 X-Spam-Level: X-Spam-Status: No, score=-96.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100, WEIRD_QUOTING=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pU0qtGsnSdAl; Thu, 13 Dec 2012 00:13:42 -0800 (PST) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 47FD321F8566; Thu, 13 Dec 2012 00:13:41 -0800 (PST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id A94CE1264889; Thu, 13 Dec 2012 16:15:31 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id qBD8DIXI022311; Thu, 13 Dec 2012 16:13:18 +0800 (GMT-8) (envelope-from zhai.hongjun@zte.com.cn) In-Reply-To: <4552F0907735844E9204A62BBDD325E732139D5A@SZXEML507-MBS.china.huawei.com> To: Mingui Zhang MIME-Version: 1.0 X-KeepSent: F6EE59C9:FD2FC0E6-48257AD3:0021A471; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhai.hongjun@zte.com.cn Date: Thu, 13 Dec 2012 16:13:16 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-12-13 16:13:14, Serialize complete at 2012-12-13 16:13:14 Content-Type: multipart/alternative; boundary="=_alternative 002D679B48257AD3_=" X-MAIL: mse02.zte.com.cn qBD8DIXI022311 Cc: Thomas Narten , trill-bounces@ietf.org, Radia Perlman , Sam Aldrin , "trill@ietf.org" , "Tissa Senevirathne \(tsenevir\)" Subject: Re: [trill] Thoughts on active-active edge X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 08:13:43 -0000 This is a multipart message in MIME format. --=_alternative 002D679B48257AD3_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SSBhbSBPSyB3aXRoIGEgbmV3IGRvY3VtZW50IHRvIHN0YXRlIHRoZSBwcm9ibGVtLg0KDQpBcyBm b3IgdGhlIHByb2JsZW1zIGxpc3RlZCBieSBNaW5ndWksIHBscyBzZWUgaW4gbGluZS4NCg0KDQpC ZXN0IFJlZ2FyZHMsDQpaaGFpIEhvbmdqdW4NCiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIi IiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiINCiBQcm90b2NvbCBEZXZl bG9wbWVudCBEZXB0LlZJLCBDZW50cmFsIFImRCBJbnN0aXR1dGUsIFpURSBDb3Jwb3JhdGlvbg0K IE5vLiA2OCwgWmlqaW5naHVhIFJvYWQsIFl1aHVhdGFpIERpc3RyaWN0LCBOYW5qaW5nLCBQLlIu Q2hpbmEsIDIxMDAxMg0KIA0KIFpoYWkgSG9uZ2p1bg0KIA0KIFRlbDogKzg2LTI1LTUyODc3MzQ1 DQogRW1haWw6IHpoYWkuaG9uZ2p1bkB6dGUuY29tLmNuDQoiIiIiIiIiIiIiIiIiIiIiIiIiIiIi IiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIg0KDQoNCg0K DQoNCk1pbmd1aSBaaGFuZyA8emhhbmdtaW5ndWlAaHVhd2VpLmNvbT4gDQq3orz+yMs6ICB0cmls bC1ib3VuY2VzQGlldGYub3JnDQoyMDEyLTEyLTEzIDE0OjAzDQoNCsrVvP7Iyw0KVGhvbWFzIE5h cnRlbiA8bmFydGVuQHVzLmlibS5jb20+LCBTYW0gQWxkcmluIDxhbGRyaW4uaWV0ZkBnbWFpbC5j b20+DQqzrcvNDQoiVGlzc2EgU2VuZXZpcmF0aG5lIFwodHNlbmV2aXJcKSIgPHRzZW5ldmlyQGNp c2NvLmNvbT4sIFJhZGlhIFBlcmxtYW4gDQo8cmFkaWFwZXJsbWFuQGdtYWlsLmNvbT4sICJ0cmls bEBpZXRmLm9yZyIgPHRyaWxsQGlldGYub3JnPg0K1vfM4g0KUmU6IFt0cmlsbF0gVGhvdWdodHMg b24gYWN0aXZlLWFjdGl2ZSBlZGdlDQoNCg0KDQoNCg0KDQpIaSBUaG9tYXMsDQoNClRoZSB3aG9s ZSBwcm9ibGVtIGlzIGhvdyB0byBwcm92aWRlIGVuZC1ub2RlcyAoZW5kLXN0YXRpb25zIG9yIExB R3MpIHdpdGggDQphIG1lY2hhbmlzbSBvZiBhY3RpdmUtYWN0aXZlIGFjY2VzcyBpbnRvIHRoZSBU UklMTCBjYW1wdXMuIFRoZSBiYXNlbGluZSANCnJlcXVpcmVtZW50IGZvciB0aGlzIG1lY2hhbmlz bSBpcyB0aGF0IHRyYWZmaWMgZHVwbGljYXRpb24gb3IgbG9vcHMgTVVTVCANCmJlIGF2b2lkZWQu IEhvd2V2ZXIsIGFzIHRoZSBtZWNoYW5pc20gaXMgYmVpbmcgZGV2ZWxvcGVkLCBuZXcgcHJvYmxl bXMgDQphcHBlYXIuIEknZCBsaWtlIHRvIGxpc3QgdGhvc2UgcHJvYmxlbXMgYXMgZm9sbG93cy4g DQoNCjEuICAgICAgICAgICAgICAgUlBGQyBpc3N1ZS4gDQpUaGUgQ01UIGRyYWZ0IGFkZHJlc3Nl cyB0aGlzIGlzc3VlLiANCg0KMi4gICAgICAgICAgICAgICBOaWNrbmFtZSBjb25maWd1cmF0aW9u DQpJdCBpcyBuZWNlc3NhcnkgdG8gZGVub3RlIHRoZSBhY3RpdmUtYWN0aXZlIGVkZ2UgZ3JvdXAg d2l0aCBhIHZpcnR1YWwgDQpSQnJpZGdlLCBzYXkgUkJ2LiBUaGUgbWVtYmVyIFJCcmlkZ2VzIGFj dCBhcyB0aGUgYWdlbnRzIG9mIHRoZSBuaWNrbmFtZSANCmFsbG9jYXRpb24gZm9yIFJCdiBhbmQg dGhleSBNVVNUIGFjdCBpbiBjb25zaXN0ZW5jZS4NCg0KQXMgZGVmaW5lZCBpbiBSRkM2MzI1LCBw c2V1ZG9ub2RlIG5pY2tuYW1lIGlzIGFjdHVhbGx5IGFsbG9jYXRlZCBieSB0aGUgDQpEUkIuIERS QiBpcyBlbGVjdGVkIHRocm91Z2ggZXhjaGFuZ2luZyBIRUxMT3MuIFRoZSBMQUcgb3IgZW5kLXN0 YXRpb24gaXMgDQpub3QgYSBMQU4gYW55bW9yZS4gQXMgYSByZXN1bHQsIG5vIEhFTExPcyBjYW4g YmUgZXhjaGFuZ2VkIG9uIGl0LiBObyBIRUxMTyANCm5vIERSQi4gU28sIGEgbmV3IHBzZXVkb25v ZGUgbmlja25hbWUgYWxsb2NhdGlvbiBtZXRob2QgaXMgbmVlZGVkLg0KDQpbSG9uZ2p1biBaaGFp IC0tQmVnaW5dDQpJIGRvbid0IHRoaW5rIHRoZSBuaWNrbmFtZSBhbGxvY2F0aW9uIGZvciBSQnYg aXMgYSBiaWcgaXNzdWUuIFNvIGl0IGlzIG5vdCANCmRpc2N1c3NlZCBpbiBQTiBkcmFmdC4NCg0K SW4gcmVhbCBkZXBsb3ltZW50LCBSQnYgaXMgY29uZmlndXJlZCBvbiBSQnJpZGdlIHBvcnRzIGFu IGlkZW50aWZpZWQgd2l0aCANCmEgbmlja25hbWUuIFdoZW4gdGhlIGZpcnN0IG1lbWJlciBwb3J0 IGlzIGFzc29jaWF0ZWQgd2l0aCBhbiBSQnYsIHdlIGNhbiANCmNob29zZSBvbmUgb2YgdGhlIGF2 YWlhbGJsZSBuaWNrbmFtZXMgc3VnZ2VzdGVkIGJ5IHRoZSBtZW1iZXIgUkJyaWRnZSANCmJhc2Vk IG9uIGl0cyBMU0RCIGFzIHRoZSBwc2V1ZG8tbmlja25hbWUgb2YgdGhlIFJCdi4gVGhlbiB3aGVu IG90aGVyIA0KUkJyaWRnZSBwb3J0cyBuZWVkcyB0byBqb2luIHRoaXMgUkJ2LCB3ZSBjYW4gdXNl IHRoZSBjaG9vc2VuIG5pY2tuYW1lIHRvIA0KaWRlbnRpZnkgdGhpZSBSQnYuDQpbSG9uZ2p1biBa aGFpIC0tRW5kXQ0KDQozLiAgICAgICAgICAgICAgIE1BQyBzaGFyaW5nIA0KVGhlIE1BQyBhZGRy ZXNzZWQgbGVhcm50IGJ5IG9uZSBtZW1iZXIgUkIgc2hvdWxkIGJlIHN5bmNocm9uaXplZCB1cCB3 aXRoIA0Kb3RoZXIgUkJzIGluIHRoZSBzYW1lIGdyb3VwLiBPciBlbHNlLCBpZiBhIGZyYW1lIGRl c3RpbmVkIHRvIHN1Y2ggYSBNQUMgaXMgDQp2aWEgb3RoZXIgUkJzLCBpdCB3aWxsIGNhdXNlIHVu bmVjZXNzYXJ5IHVua25vd24gdW5pY2FzdC4NCg0KW0hvbmdqdW4gWmhhaSAtLUJlZ2luXSANCk1B QyBzaGFyaW5nIGlzIHJlYWxseSBuZWVkZWQgYnV0IG5vdCBkaWZmaWN1bHQuIFdlIGNhbiB1c2Ug RVNBREkgDQpleHRlbnN0aW9uIGZvciB0aGlzIHB1cnBvc2UuIDEpIGFsbG93IHRoZSBWTEFOLXNj b3BlZCBFU0FESSBpbnN0YW5jZSB0byANCmFkdmVydGlzZSBsZWFybmVkIHJlbW90ZSBlbmQgc3Rh dGlvbiBNQUMgYWRkcmVzc2VzIGFzIHdlbGwgYXMgbG9jYWwgZW5kIA0Kc3RhdGlvbiBNQUMgYWRk cmVzc2VzLCBPciAyKSBleHRlbmQgRVNBREkgdG8gc3VwcG9ydCBSQi1Hcm91cCBzY29wZWQgDQpp bnN0YW5jZXMgKHBsZWFzZSByZWZlciBkcmFmdC16aGFpLWV4dGVuc3Rpb24tZm9yLVJCdiBmb3Ig bW9yZSBkZXRhaWxzKS4NCltIb25nanVuIFpoYWkgLS1FbmRdDQoNCg0KNC4gICAgICAgICAgICAg ICBGYWlsdXJlIHJlY292ZXJ5DQpXaGVuIGEgbWVtYmVyIFJCcmlkZ2Ugb3IgbGluayBmYWlscywg aG93IGRvZXMgdGhlIHdob2xlIGFjdGl2ZS1hY3RpdmUgZWRnZSANCmdyb3VwIHJlc3BvbnNlPyBB IG1ldGhvZCBpcyBuZWVkZWQgaGVyZSB0byBhdXRvbWF0ZSB0aGF0IHByb2Nlc3MuDQoNCltIb25n anVuIFpoYWkgIC0tQmVnaW5dDQpJIHRoaW5rIGl0IGlzIHJlYWxseSBhIHByb2JsZW0gc2xvdmUg aW4gUkJ2LiBUaGUgbGluayBmYWlsdXJlIGlzc3VlIGlzIA0KZGlzY3Vzc2VkIGluIFNlY3Rpb24g NiBvZiBQTiBkcmFmdC4gUGxlYXNlIGNsaWNrIHRoZSBmb2xsb3dpbmcgVVJMIGZvciANCm1vcmUg ZGV0YWlscy4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWh1LXRy aWxsLXBzZXVkb25vZGUtbmlja25hbWUtMDQudHh0DQouDQpbSG9uZ2p1biBaaGFpICAtLUVuZF0N Cg0KSSBhbSBPSyB3aXRoIHRoZSBpZGVhIHRvIGNvbXBvc2UgYSBwcm9ibGVtIHN0YXRlbWVudCBk cmFmdC4gSG93ZXZlciwgSU1PLCANCml0IGlzIGltcG9zc2libGUgdG8gcHJvdmlkZSBfb25lXyBz b2x1dGlvbiBkcmFmdCB0byBzb2x2ZSBhbGwgdGhlc2UgDQpwcm9ibGVtcy4NCg0KVGhhbmtzLA0K TWluZ3VpDQoNCg0KDQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBUaG9tYXMg TmFydGVuIFttYWlsdG86bmFydGVuQHVzLmlibS5jb21dDQo+U2VudDogVGh1cnNkYXksIERlY2Vt YmVyIDEzLCAyMDEyIDY6NTggQU0NCj5UbzogU2FtIEFsZHJpbg0KPkNjOiBNaW5ndWkgWmhhbmc7 IFRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpOyBSYWRpYSBQZXJsbWFuOyANCnRyaWxsQGll dGYub3JnDQo+U3ViamVjdDogUmU6IFt0cmlsbF0gVGhvdWdodHMgb24gYWN0aXZlLWFjdGl2ZSBl ZGdlDQo+DQo+DQo+U2FtIEFsZHJpbiA8YWxkcmluLmlldGZAZ21haWwuY29tPiB3cml0ZXM6DQo+ DQo+PiBPbiBEZWMgMTIsIDIwMTIsIGF0IDEyOjI1IFBNLCBUaG9tYXMgTmFydGVuIDxuYXJ0ZW5A dXMuaWJtLmNvbT4gd3JvdGU6DQo+DQo+PiA+PiBJIGJlbGlldmUgd2UgaGF2ZSBkaXNjdXNzZWQg dGhlc2Ugc2NlbmFyaW9zIChkaWZmZXJlbnQgc29sdXRpb24NCj4+ID4+IHR5cGVzKSBwcmV2aW91 c2x5LiAgV0cgc2hvdWxkIHJlYWNoIGNvbnNlbnN1cyBhbmQgbW92ZSBmb3J3YXJkIHdpdGgNCj4+ ID4+IHRoZSBhZ3JlZWQgc29sdXRpb24uICBBdGxlYXN0IGZyb20gdGhlIElFVEYgV0cgc2Vzc2lv bnMsIEkgcHJlc3VtZWQNCj4+ID4+IHRoZXJlIHdhcyBhIGNvbnNlbnN1cyBvbiB0aGUgc29sdXRp b24uICBBbSBJIHdyb25nIGluIHRoYXQNCj4+ID4+IGFzc3VtcHRpb24/DQo+PiA+DQo+PiA+IHdo YXQgInNvbHV0aW9uIiBhcmUgeW91IHJlZmVycmluZyBhYm92ZSBhcyBtYXliZSBoYXZpbmcgY29u c2Vuc3VzPw0KPg0KPj4gQ210IGRyYWZ0DQo+DQo+SWYgeW91IG1lYW4gZHJhZnQtaWV0Zi10cmls bC1jbXQtMDEudHh0LCBJIGF0IGxlYXN0IGFtIG5vdCBpbg0KPmFncmVlbWVudC4NCj4NCj5JIGhh dmUgc2V2ZXJhbCBpc3N1ZXMgd2l0aCB0aGUgZG9jdW1lbnQuDQo+DQo+Rm9yIHN0YXJ0ZXJzLCBp dCdzIGluY29tcGxldGUuIEl0IG5lZWRzIHRvIGJlIHBhaXJlZCB3aXRoIGFub3RoZXINCj5kb2N1 bWVudCB0byBnZXQgYW4gYWN0dWFsICJzdGFuZGFyZCIgeW91IGNhbiBpbXBsZW1lbnQuIFdlIGRv bid0IGhhdmUNCj5zdWNoIGEgY29tcGFuaW9uIGRvY3VtZW50IHlldC4gIEl0J3MgYmVlbiBzdWdn ZXN0ZWQgdGhhdA0KPmRyYWZ0LWh1LXRyaWxsLXBzZXVkb25vZGUtbmlja25hbWUtMDQudHh0IGlz IG9uZSBzdWNoIGRvY3VtZW50LiBCdXQNCj50aGF0IGRvY3VtZW50IGlzIG5vdCBhIFdHIGRvY3Vt ZW50IGFuZCBJJ20gbm90IHN1cmUgd2hhdCBpdHMgc3RhdHVzDQo+aXMuIChBbmQgaXQgbmVlZHMg d29yay4uLikNCj4NCj5BcyBhIGdlbmVyYWwgcnVsZSAobm90IFRSSUxMIHNwZWNpZmljKSBJIGRv bid0IGxpa2UgV0dzIGRvaW5nICJwYXJ0aWFsDQo+d29yayIgd2hlcmUgdGhleSBzdGFuZGFyZGl6 ZSBvbmUgZG9jdW1lbnQsIHRoYXQgaXMgaW5jb21wbGV0ZSBieQ0KPml0c2VsZiwgaW5kZXBlbmRl bnQgb2Ygb3RoZXIgZG9jdW1lbnRzIHRoYXQgYXJlIG5lZWRlZCB0byBwcm9kdWNlIGENCj5jb21w bGV0ZSBpbXBsZW1lbnRhYmxlIHNvbHV0aW9uIHRvIHNvbWUgcmVhbCBwcm9ibGVtLg0KPg0KPkkn dmUgcmFpc2VkIGlzc3VlcyBvbiB0aGUgbGlzdCBhYm91dCBDTVQgYW5kIGl0cyB1bmNsYXJpdHkN Cj53cnQuIExBRy9NQy1MQUcsIGV0Yy4gSSBkaWQgbm90IHJlYWxseSBnZXQgbXkgcXVlc3Rpb25z IGFuc3dlcmVkLg0KPg0KPldoYXQgSSdkIHJlYWxseSBsaWtlIHRvIHN0YXJ0IHdpdGggb24gQ01U IGlzIGEgY2xlYXIgcHJvYmxlbQ0KPnN0YXRlbWVudC4gSS5lLiwgZXhhY3RseSB3aGF0IHByb2Js ZW0vdXNlIGNhc2UgaXQgaXMgdHJ5aW5nIHRvDQo+c29sdmUuIEkgaGF2ZSBub3QgYmVlbiBhYmxl IHRvIGdldCB0aGF0IG91dCBvZiB0aGUgdHdvICBkb2N1bWVudHMuDQo+DQo+QXMgZm9yIGRyYWZ0 LWh1LXRyaWxsLXBzZXVkb25vZGUtbmlja25hbWUtMDQudHh0LCBJIGhhdmUgb3RoZXINCj5jb25j ZXJucy4gRS5nLiwgaXQgdGFsa3MgYWJvdXQgdHVubmVsaW5nIGF0IG9uZSBwb2ludCwgYnV0IHRo YXQgaXMNCj5jb21wbGV0ZWx5IHVuc3BlY2lmaWVkLg0KPg0KPldoYXQgSSBkb24ndCB3YW50IHRv IGRvIGlzIHNwZW5kIGEgbG90IG9mIHRpbWUgb24gdGhlICpzb2x1dGlvbioNCj5kZXRhaWxzLiBJ IGZpcnN0IHdhbnQgYSBjbGVhciBwcm9ibGVtIHN0YXRlbWVudC91c2UgY2FzZS4gV2l0aG91dA0K PnRoYXQsIGl0IGlzIGRpZmZpY3VsdCB0byBhc3Nlc3MgaG93IHdlbGwgcG90ZW50aWFsIHNvbHV0 aW9ucyBhZGRyZXNzDQo+dGhlIHN0YXRlZCBwcm9ibGVtLg0KPg0KPlRob21hcw0KPg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdHJpbGwgbWFpbGlu ZyBsaXN0DQp0cmlsbEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby90cmlsbA0KDQoNCg== --=_alternative 002D679B48257AD3_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgYW0gT0sgPC9mb250Pjx0dD48 Zm9udCBzaXplPTI+d2l0aA0KYSBuZXcgZG9jdW1lbnQgdG8gc3RhdGUgdGhlIHByb2JsZW0uPC9m b250PjwvdHQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkFzIGZv ciB0aGUgcHJvYmxlbXMgbGlzdGVkIGJ5IE1pbmd1aSwNCnBscyBzZWUgaW4gbGluZS48L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjxicj4NCkJlc3QgUmVn YXJkcyw8YnI+DQpaaGFpIEhvbmdqdW48YnI+DQomcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDs8YnI+DQog UHJvdG9jb2wgRGV2ZWxvcG1lbnQgRGVwdC5WSSwgQ2VudHJhbCBSJmFtcDtEIEluc3RpdHV0ZSwg WlRFIENvcnBvcmF0aW9uPGJyPg0KIE5vLiA2OCwgWmlqaW5naHVhIFJvYWQsIFl1aHVhdGFpIERp c3RyaWN0LCBOYW5qaW5nLCBQLlIuQ2hpbmEsIDIxMDAxMjxicj4NCiA8YnI+DQogWmhhaSBIb25n anVuPGJyPg0KIDxicj4NCiBUZWw6ICs4Ni0yNS01Mjg3NzM0NTxicj4NCiBFbWFpbDogemhhaS5o b25nanVuQHp0ZS5jb20uY248YnI+DQomcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDs8YnI+DQo8 YnI+DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2 YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ PGI+TWluZ3VpIFpoYW5nICZsdDt6aGFuZ21pbmd1aUBodWF3ZWkuY29tJmd0OzwvYj4NCjwvZm9u dD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDt0cmls bC1ib3VuY2VzQGlldGYub3JnPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPjIwMTItMTItMTMgMTQ6MDM8L2ZvbnQ+DQo8dGQgd2lkdGg9NjMlPg0KPHRhYmxlIHdpZHRo PTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+VGhvbWFzIE5hcnRlbiAmbHQ7bmFydGVuQHVzLmlibS5jb20m Z3Q7LA0KU2FtIEFsZHJpbiAmbHQ7YWxkcmluLmlldGZAZ21haWwuY29tJmd0OzwvZm9udD4NCjx0 ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+JnF1b3Q7VGlzc2EgU2VuZXZpcmF0aG5lIFwodHNlbmV2aXJcKSZxdW90Ow0KJmx0 O3RzZW5ldmlyQGNpc2NvLmNvbSZndDssIFJhZGlhIFBlcmxtYW4gJmx0O3JhZGlhcGVybG1hbkBn bWFpbC5jb20mZ3Q7LA0KJnF1b3Q7dHJpbGxAaWV0Zi5vcmcmcXVvdDsgJmx0O3RyaWxsQGlldGYu b3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFt0cmlsbF0gVGhvdWdodHMgb24gYWN0aXZl LWFjdGl2ZQ0KZWRnZTwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjx0 dD48Zm9udCBzaXplPTI+SGkgVGhvbWFzLDxicj4NCjxicj4NClRoZSB3aG9sZSBwcm9ibGVtIGlz IGhvdyB0byBwcm92aWRlIGVuZC1ub2RlcyAoZW5kLXN0YXRpb25zIG9yIExBR3MpIHdpdGgNCmEg bWVjaGFuaXNtIG9mIGFjdGl2ZS1hY3RpdmUgYWNjZXNzIGludG8gdGhlIFRSSUxMIGNhbXB1cy4g VGhlIGJhc2VsaW5lDQpyZXF1aXJlbWVudCBmb3IgdGhpcyBtZWNoYW5pc20gaXMgdGhhdCB0cmFm ZmljIGR1cGxpY2F0aW9uIG9yIGxvb3BzIE1VU1QNCmJlIGF2b2lkZWQuIEhvd2V2ZXIsIGFzIHRo ZSBtZWNoYW5pc20gaXMgYmVpbmcgZGV2ZWxvcGVkLCBuZXcgcHJvYmxlbXMNCmFwcGVhci4gSSdk IGxpa2UgdG8gbGlzdCB0aG9zZSBwcm9ibGVtcyBhcyBmb2xsb3dzLiA8YnI+DQo8YnI+DQoxLiAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpS UEZDIGlzc3VlLiA8YnI+DQpUaGUgQ01UIGRyYWZ0IGFkZHJlc3NlcyB0aGlzIGlzc3VlLiA8YnI+ DQo8YnI+DQoyLiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7DQpOaWNrbmFtZSBjb25maWd1cmF0aW9uPGJyPg0KSXQgaXMgbmVjZXNzYXJ5IHRv IGRlbm90ZSB0aGUgYWN0aXZlLWFjdGl2ZSBlZGdlIGdyb3VwIHdpdGggYSB2aXJ0dWFsIFJCcmlk Z2UsDQpzYXkgUkJ2LiBUaGUgbWVtYmVyIFJCcmlkZ2VzIGFjdCBhcyB0aGUgYWdlbnRzIG9mIHRo ZSBuaWNrbmFtZSBhbGxvY2F0aW9uDQpmb3IgUkJ2IGFuZCB0aGV5IE1VU1QgYWN0IGluIGNvbnNp c3RlbmNlLjxicj4NCjxicj4NCkFzIGRlZmluZWQgaW4gUkZDNjMyNSwgcHNldWRvbm9kZSBuaWNr bmFtZSBpcyBhY3R1YWxseSBhbGxvY2F0ZWQgYnkgdGhlDQpEUkIuIERSQiBpcyBlbGVjdGVkIHRo cm91Z2ggZXhjaGFuZ2luZyBIRUxMT3MuIFRoZSBMQUcgb3IgZW5kLXN0YXRpb24gaXMNCm5vdCBh IExBTiBhbnltb3JlLiBBcyBhIHJlc3VsdCwgbm8gSEVMTE9zIGNhbiBiZSBleGNoYW5nZWQgb24g aXQuIE5vIEhFTExPDQpubyBEUkIuIFNvLCBhIG5ldyBwc2V1ZG9ub2RlIG5pY2tuYW1lIGFsbG9j YXRpb24gbWV0aG9kIGlzIG5lZWRlZC48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPltIb25nanVuIFpoYWkgLS1CZWdpbl08L2ZvbnQ+PC90dD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+SSBkb24ndCB0aGluayB0aGUgbmlja25hbWUgYWxsb2NhdGlv bg0KZm9yIFJCdiBpcyBhIGJpZyBpc3N1ZS4gU28gaXQgaXMgbm90IGRpc2N1c3NlZCBpbiBQTiBk cmFmdC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPklu IHJlYWwgZGVwbG95bWVudCwgUkJ2IGlzIGNvbmZpZ3VyZWQNCm9uIFJCcmlkZ2UgcG9ydHMgYW4g aWRlbnRpZmllZCB3aXRoIGEgbmlja25hbWUuIFdoZW4gdGhlIGZpcnN0IG1lbWJlciBwb3J0DQpp cyBhc3NvY2lhdGVkIHdpdGggYW4gUkJ2LCB3ZSBjYW4gY2hvb3NlIG9uZSBvZiB0aGUgYXZhaWFs YmxlIG5pY2tuYW1lcw0Kc3VnZ2VzdGVkIGJ5IHRoZSBtZW1iZXIgUkJyaWRnZSBiYXNlZCBvbiBp dHMgTFNEQiBhcyB0aGUgcHNldWRvLW5pY2tuYW1lDQpvZiB0aGUgUkJ2LiBUaGVuIHdoZW4gb3Ro ZXIgUkJyaWRnZSBwb3J0cyBuZWVkcyB0byBqb2luIHRoaXMgUkJ2LCB3ZSBjYW4NCnVzZSB0aGUg Y2hvb3NlbiBuaWNrbmFtZSB0byBpZGVudGlmeSB0aGllIFJCdi48L2ZvbnQ+PHR0Pjxmb250IHNp emU9Mj48YnI+DQpbSG9uZ2p1biBaaGFpIC0tRW5kXTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+PGJyPg0KMy4gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOw0KTUFDIHNoYXJpbmcgPGJyPg0KVGhlIE1BQyBhZGRyZXNzZWQgbGVh cm50IGJ5IG9uZSBtZW1iZXIgUkIgc2hvdWxkIGJlIHN5bmNocm9uaXplZCB1cCB3aXRoDQpvdGhl ciBSQnMgaW4gdGhlIHNhbWUgZ3JvdXAuIE9yIGVsc2UsIGlmIGEgZnJhbWUgZGVzdGluZWQgdG8g c3VjaCBhIE1BQw0KaXMgdmlhIG90aGVyIFJCcywgaXQgd2lsbCBjYXVzZSB1bm5lY2Vzc2FyeSB1 bmtub3duIHVuaWNhc3QuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5b SG9uZ2p1biBaaGFpIC0tQmVnaW5dIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ TUFDIHNoYXJpbmcgaXMgcmVhbGx5IG5lZWRlZCBidXQgbm90IGRpZmZpY3VsdC4gV2UNCmNhbiB1 c2UgRVNBREkgZXh0ZW5zdGlvbiBmb3IgdGhpcyBwdXJwb3NlLiAxKSBhbGxvdyB0aGUgVkxBTi1z Y29wZWQgRVNBREkNCmluc3RhbmNlIHRvIGFkdmVydGlzZSBsZWFybmVkIHJlbW90ZSBlbmQgc3Rh dGlvbiBNQUMgYWRkcmVzc2VzIGFzIHdlbGwNCmFzIGxvY2FsIGVuZCBzdGF0aW9uIE1BQyBhZGRy ZXNzZXMsIE9yIDIpIGV4dGVuZCBFU0FESSB0byBzdXBwb3J0IFJCLUdyb3VwDQpzY29wZWQgaW5z dGFuY2VzIChwbGVhc2UgcmVmZXIgZHJhZnQtemhhaS1leHRlbnN0aW9uLWZvci1SQnYgZm9yIG1v cmUgZGV0YWlscykuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5bSG9uZ2p1biBa aGFpIC0tRW5kXTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KPGJyPg0K NC4gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw Ow0KRmFpbHVyZSByZWNvdmVyeTxicj4NCldoZW4gYSBtZW1iZXIgUkJyaWRnZSBvciBsaW5rIGZh aWxzLCBob3cgZG9lcyB0aGUgd2hvbGUgYWN0aXZlLWFjdGl2ZSBlZGdlDQpncm91cCByZXNwb25z ZT8gQSBtZXRob2QgaXMgbmVlZGVkIGhlcmUgdG8gYXV0b21hdGUgdGhhdCBwcm9jZXNzLjwvZm9u dD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+W0hvbmdqdW4gWmhhaSAmbmJzcDst LUJlZ2luXTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+SSB0aGluayBpdCBpcyBy ZWFsbHkgYSBwcm9ibGVtIHNsb3ZlIGluIFJCdi4gVGhlIGxpbmsNCmZhaWx1cmUgaXNzdWUgaXMg ZGlzY3Vzc2VkIGluIFNlY3Rpb24gNiBvZiBQTiBkcmFmdC4gUGxlYXNlIGNsaWNrIHRoZSBmb2xs b3dpbmcNClVSTCBmb3IgbW9yZSBkZXRhaWxzLjwvZm9udD48L3R0Pg0KPGJyPjxhIGhyZWY9Imh0 dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWh1LXRyaWxsLXBzZXVkb25v ZGUtbmlja25hbWUtMDQudHh0Ij48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNl cmlmIj48dT5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1odS10cmls bC1wc2V1ZG9ub2RlLW5pY2tuYW1lLTA0LnR4dDwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBm YWNlPSJzYW5zLXNlcmlmIj4uPC9mb250Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+W0hvbmdqdW4g WmhhaSAmbmJzcDstLUVuZF08YnI+DQo8YnI+DQpJIGFtIE9LIHdpdGggdGhlIGlkZWEgdG8gY29t cG9zZSBhIHByb2JsZW0gc3RhdGVtZW50IGRyYWZ0LiBIb3dldmVyLCBJTU8sDQppdCBpcyBpbXBv c3NpYmxlIHRvIHByb3ZpZGUgX29uZV8gc29sdXRpb24gZHJhZnQgdG8gc29sdmUgYWxsIHRoZXNl IHByb2JsZW1zLjxicj4NCjxicj4NClRoYW5rcyw8YnI+DQpNaW5ndWk8YnI+DQo8YnI+DQo8YnI+ DQo8YnI+DQomZ3Q7LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7RnJvbTogVGhv bWFzIE5hcnRlbiBbbWFpbHRvOm5hcnRlbkB1cy5pYm0uY29tXTxicj4NCiZndDtTZW50OiBUaHVy c2RheSwgRGVjZW1iZXIgMTMsIDIwMTIgNjo1OCBBTTxicj4NCiZndDtUbzogU2FtIEFsZHJpbjxi cj4NCiZndDtDYzogTWluZ3VpIFpoYW5nOyBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKTsg UmFkaWEgUGVybG1hbjsgdHJpbGxAaWV0Zi5vcmc8YnI+DQomZ3Q7U3ViamVjdDogUmU6IFt0cmls bF0gVGhvdWdodHMgb24gYWN0aXZlLWFjdGl2ZSBlZGdlPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+ DQomZ3Q7U2FtIEFsZHJpbiAmbHQ7YWxkcmluLmlldGZAZ21haWwuY29tJmd0OyB3cml0ZXM6PGJy Pg0KJmd0Ozxicj4NCiZndDsmZ3Q7IE9uIERlYyAxMiwgMjAxMiwgYXQgMTI6MjUgUE0sIFRob21h cyBOYXJ0ZW4gJmx0O25hcnRlbkB1cy5pYm0uY29tJmd0Ow0Kd3JvdGU6PGJyPg0KJmd0Ozxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7IEkgYmVsaWV2ZSB3ZSBoYXZlIGRpc2N1c3NlZCB0aGVzZSBzY2Vu YXJpb3MgKGRpZmZlcmVudA0Kc29sdXRpb248YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyB0eXBlcykg cHJldmlvdXNseS4gJm5ic3A7V0cgc2hvdWxkIHJlYWNoIGNvbnNlbnN1cyBhbmQNCm1vdmUgZm9y d2FyZCB3aXRoPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgdGhlIGFncmVlZCBzb2x1dGlvbi4gJm5i c3A7QXRsZWFzdCBmcm9tIHRoZSBJRVRGIFdHIHNlc3Npb25zLA0KSSBwcmVzdW1lZDxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7IHRoZXJlIHdhcyBhIGNvbnNlbnN1cyBvbiB0aGUgc29sdXRpb24uICZu YnNwO0FtIEkgd3JvbmcNCmluIHRoYXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBhc3N1bXB0aW9u Pzxicj4NCiZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IHdoYXQgJnF1b3Q7c29sdXRp b24mcXVvdDsgYXJlIHlvdSByZWZlcnJpbmcgYWJvdmUgYXMgbWF5YmUNCmhhdmluZyBjb25zZW5z dXM/PGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7IENtdCBkcmFmdDxicj4NCiZndDs8YnI+DQomZ3Q7 SWYgeW91IG1lYW4gZHJhZnQtaWV0Zi10cmlsbC1jbXQtMDEudHh0LCBJIGF0IGxlYXN0IGFtIG5v dCBpbjxicj4NCiZndDthZ3JlZW1lbnQuPGJyPg0KJmd0Ozxicj4NCiZndDtJIGhhdmUgc2V2ZXJh bCBpc3N1ZXMgd2l0aCB0aGUgZG9jdW1lbnQuPGJyPg0KJmd0Ozxicj4NCiZndDtGb3Igc3RhcnRl cnMsIGl0J3MgaW5jb21wbGV0ZS4gSXQgbmVlZHMgdG8gYmUgcGFpcmVkIHdpdGggYW5vdGhlcjxi cj4NCiZndDtkb2N1bWVudCB0byBnZXQgYW4gYWN0dWFsICZxdW90O3N0YW5kYXJkJnF1b3Q7IHlv dSBjYW4gaW1wbGVtZW50LiBXZQ0KZG9uJ3QgaGF2ZTxicj4NCiZndDtzdWNoIGEgY29tcGFuaW9u IGRvY3VtZW50IHlldC4gJm5ic3A7SXQncyBiZWVuIHN1Z2dlc3RlZCB0aGF0PGJyPg0KJmd0O2Ry YWZ0LWh1LXRyaWxsLXBzZXVkb25vZGUtbmlja25hbWUtMDQudHh0IGlzIG9uZSBzdWNoIGRvY3Vt ZW50LiBCdXQ8YnI+DQomZ3Q7dGhhdCBkb2N1bWVudCBpcyBub3QgYSBXRyBkb2N1bWVudCBhbmQg SSdtIG5vdCBzdXJlIHdoYXQgaXRzIHN0YXR1czxicj4NCiZndDtpcy4gKEFuZCBpdCBuZWVkcyB3 b3JrLi4uKTxicj4NCiZndDs8YnI+DQomZ3Q7QXMgYSBnZW5lcmFsIHJ1bGUgKG5vdCBUUklMTCBz cGVjaWZpYykgSSBkb24ndCBsaWtlIFdHcyBkb2luZyAmcXVvdDtwYXJ0aWFsPGJyPg0KJmd0O3dv cmsmcXVvdDsgd2hlcmUgdGhleSBzdGFuZGFyZGl6ZSBvbmUgZG9jdW1lbnQsIHRoYXQgaXMgaW5j b21wbGV0ZQ0KYnk8YnI+DQomZ3Q7aXRzZWxmLCBpbmRlcGVuZGVudCBvZiBvdGhlciBkb2N1bWVu dHMgdGhhdCBhcmUgbmVlZGVkIHRvIHByb2R1Y2UgYTxicj4NCiZndDtjb21wbGV0ZSBpbXBsZW1l bnRhYmxlIHNvbHV0aW9uIHRvIHNvbWUgcmVhbCBwcm9ibGVtLjxicj4NCiZndDs8YnI+DQomZ3Q7 SSd2ZSByYWlzZWQgaXNzdWVzIG9uIHRoZSBsaXN0IGFib3V0IENNVCBhbmQgaXRzIHVuY2xhcml0 eTxicj4NCiZndDt3cnQuIExBRy9NQy1MQUcsIGV0Yy4gSSBkaWQgbm90IHJlYWxseSBnZXQgbXkg cXVlc3Rpb25zIGFuc3dlcmVkLjxicj4NCiZndDs8YnI+DQomZ3Q7V2hhdCBJJ2QgcmVhbGx5IGxp a2UgdG8gc3RhcnQgd2l0aCBvbiBDTVQgaXMgYSBjbGVhciBwcm9ibGVtPGJyPg0KJmd0O3N0YXRl bWVudC4gSS5lLiwgZXhhY3RseSB3aGF0IHByb2JsZW0vdXNlIGNhc2UgaXQgaXMgdHJ5aW5nIHRv PGJyPg0KJmd0O3NvbHZlLiBJIGhhdmUgbm90IGJlZW4gYWJsZSB0byBnZXQgdGhhdCBvdXQgb2Yg dGhlIHR3byAmbmJzcDtkb2N1bWVudHMuPGJyPg0KJmd0Ozxicj4NCiZndDtBcyBmb3IgZHJhZnQt aHUtdHJpbGwtcHNldWRvbm9kZS1uaWNrbmFtZS0wNC50eHQsIEkgaGF2ZSBvdGhlcjxicj4NCiZn dDtjb25jZXJucy4gRS5nLiwgaXQgdGFsa3MgYWJvdXQgdHVubmVsaW5nIGF0IG9uZSBwb2ludCwg YnV0IHRoYXQgaXM8YnI+DQomZ3Q7Y29tcGxldGVseSB1bnNwZWNpZmllZC48YnI+DQomZ3Q7PGJy Pg0KJmd0O1doYXQgSSBkb24ndCB3YW50IHRvIGRvIGlzIHNwZW5kIGEgbG90IG9mIHRpbWUgb24g dGhlICpzb2x1dGlvbio8YnI+DQomZ3Q7ZGV0YWlscy4gSSBmaXJzdCB3YW50IGEgY2xlYXIgcHJv YmxlbSBzdGF0ZW1lbnQvdXNlIGNhc2UuIFdpdGhvdXQ8YnI+DQomZ3Q7dGhhdCwgaXQgaXMgZGlm ZmljdWx0IHRvIGFzc2VzcyBob3cgd2VsbCBwb3RlbnRpYWwgc29sdXRpb25zIGFkZHJlc3M8YnI+ DQomZ3Q7dGhlIHN0YXRlZCBwcm9ibGVtLjxicj4NCiZndDs8YnI+DQomZ3Q7VGhvbWFzPGJyPg0K Jmd0Ozxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KdHJpbGwgbWFpbGluZyBsaXN0PGJyPg0KdHJpbGxAaWV0Zi5vcmc8YnI+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsPGJyPg0KPC9mb250Pjwv dHQ+DQo8YnI+DQo= --=_alternative 002D679B48257AD3_=-- From zhai.hongjun@zte.com.cn Thu Dec 13 04:03:41 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64BE021F89A7; Thu, 13 Dec 2012 04:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.999 X-Spam-Level: X-Spam-Status: No, score=-96.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100, WEIRD_QUOTING=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CyapiBBmmiio; Thu, 13 Dec 2012 04:03:40 -0800 (PST) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id E293721F8990; Thu, 13 Dec 2012 04:03:39 -0800 (PST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 14C2B1266C8E; Thu, 13 Dec 2012 20:05:30 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id qBDC34Yc049667; Thu, 13 Dec 2012 20:03:04 +0800 (GMT-8) (envelope-from zhai.hongjun@zte.com.cn) In-Reply-To: To: Radia Perlman MIME-Version: 1.0 X-KeepSent: 91CA02ED:06B3BB81-48257AD3:00405487; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhai.hongjun@zte.com.cn Date: Thu, 13 Dec 2012 20:03:01 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-12-13 20:02:58, Serialize complete at 2012-12-13 20:02:58 Content-Type: multipart/alternative; boundary="=_alternative 0042706A48257AD3_=" X-MAIL: mse01.zte.com.cn qBDC34Yc049667 Cc: Thomas Narten , trill-bounces@ietf.org, Sam Aldrin , Mingui Zhang , "trill@ietf.org" , "Tissa Senevirathne \(tsenevir\)" Subject: Re: [trill] Thoughts on active-active edge X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 12:03:41 -0000 This is a multipart message in MIME format. --=_alternative 0042706A48257AD3_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgUmFkaWENCg0KPiBUaGlzIGNhc2UgaXMgc2NhcnkgYmVjYXVzZSB0aGUgUkJyaWRnZXMgb24g dGhlIHVwbGluayBjYW5ub3Qgc2VlIEhlbGxvcyANCmZyb20gZWFjaCBvdGhlciwgDQo+IHNvIGlm IG1pc2NvbmZpZ3VyZWQsIGF0IHRoZSB2ZXJ5IGxlYXN0IEkgY291bGQgaW1hZ2luZSBtdWx0aXBs ZSBSQnJpZGdlcyANCmRlY2Fwc3VsYXRpbmcgDQo+IG11bHRpY2FzdCBmcm9tIHRoZSBjYW1wdXMg dG8gdGhlIGh5cGVydmlzb3IuDQoNCj4gQW55d2F5Li4uaG93IG1hbnkgdXBsaW5rcyBkbyB3ZSBu ZWVkIHRvIHN1cHBvcnQ/ICBEbyB3ZSBjYXJlIGFib3V0IA0KcHJvYmxlbXMgZHVlIHRvIG1pc2Nv bmZpZ3VyYXRpb24/DQoNCkkgZG9uJ3Qga25vdyB3aGF0IHRoZSBtaXNjb25maWd1cmF0aW9uIHJl ZmVycyB0by4gSXMgaXQgdGhlIHNldCBvZiBWTEFOcyANCmZvciB3aGljaCBhbiBSYnJpZGdlIGFj dHMgYXMgQUY/DQoNCg0KPiBBcmUgdGhlcmUgY2FzZXMgd2hlcmUgdGhlcmUgYXJlIGxvdHMgb2Yg aHlwZXJ2aXNvcnMsIHdoZXJlIHRoZXkgYXR0YWNoIA0KdG8gZGlmZmVyZW50IHN1YnNldHMgb2Yg ZWRnZSBSQnM/ICANCj4gSW4gdGhhdCBjYXNlLCB3ZSBtaWdodCBlYXQgdXAgYSBsb3Qgb2Ygbmlj a25hbWVzLCBzaW5jZSBpZiBvbmUgDQpoeXBlcnZpc29yIGlzIGF0dGFjaGVkIHRvIHtSMSwgUjJ9 LCANCj4gYW5kIGFub3RoZXIgaXMgYXR0YWNoZWQgdG8ge1IxLCBSMiwgUjN9LCB0aGV5IGNhbm5v dCB1c2UgdGhlIHNhbWUgDQpwc2V1ZG9ub2RlIG5pY2tuYW1lLg0KDQpJIGRvbid0IGtub3cgd2h5 IHRoZSB0d28gc2V0cyBvZiBSQnJpZGdlcyBjYW4gbm90IHVzZSB0aGUgc2FtZSANCnBzZXVkby1u aWNrbmFtZS4gSWYgdGhlIGxlYXJuZWQgTUFDIGFkZHJlc3NlcyANCmNhbiBiZSBzaGFyZWQgYW1v bmcgbWVtYmVyIFJicmlkZ2VzIG9mIGFuIFJCdiBhbmQgVFJJTEwgZGF0YSBmcmFtZXMgY2FuIGJl IA0KdHVubmVsZWQgdG8gYW5vdGhlciBtZW1iZXIgUmJyaWRnZQ0KdGhhdCBjYW4gZWdyZXNzIHRo ZSBmcmFtZSwgSSB0aGluayB0aGV5IGNhbiB1c2UgdGhlIHNhbWUgcHNldWRvLW5pY2tuYW1lLg0K DQpJZiBJIGFtIHdyb25nLCBwbGVhc2UgY29ycmVjdCBtZS4NCg0KQmVzdCBSZWdhcmRzLA0KWmhh aSBIb25nanVuDQoiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIi IiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiDQogUHJvdG9jb2wgRGV2ZWxvcG1lbnQgRGVwdC5WSSwg Q2VudHJhbCBSJkQgSW5zdGl0dXRlLCBaVEUgQ29ycG9yYXRpb24NCiBOby4gNjgsIFppamluZ2h1 YSBSb2FkLCBZdWh1YXRhaSBEaXN0cmljdCwgTmFuamluZywgUC5SLkNoaW5hLCAyMTAwMTINCiAN CiBaaGFpIEhvbmdqdW4NCiANCiBUZWw6ICs4Ni0yNS01Mjg3NzM0NQ0KIEVtYWlsOiB6aGFpLmhv bmdqdW5AenRlLmNvbS5jbg0KIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIi IiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiINCg0KDQoNCg0KDQpSYWRpYSBQZXJsbWFu IDxyYWRpYXBlcmxtYW5AZ21haWwuY29tPiANCreivP7IyzogIHRyaWxsLWJvdW5jZXNAaWV0Zi5v cmcNCjIwMTItMTItMTMgMTU6MTMNCg0KytW8/sjLDQpNaW5ndWkgWmhhbmcgPHpoYW5nbWluZ3Vp QGh1YXdlaS5jb20+DQqzrcvNDQpUaG9tYXMgTmFydGVuIDxuYXJ0ZW5AdXMuaWJtLmNvbT4sIFNh bSBBbGRyaW4gPGFsZHJpbi5pZXRmQGdtYWlsLmNvbT4sIA0KIlRpc3NhIFNlbmV2aXJhdGhuZSBc KHRzZW5ldmlyXCkiIDx0c2VuZXZpckBjaXNjby5jb20+LCAidHJpbGxAaWV0Zi5vcmciIA0KPHRy aWxsQGlldGYub3JnPg0K1vfM4g0KUmU6IFt0cmlsbF0gVGhvdWdodHMgb24gYWN0aXZlLWFjdGl2 ZSBlZGdlDQoNCg0KDQoNCg0KDQpJIHRoaW5rIGl0IHdvdWxkIGJlIGdvb2QgdG8gaGF2ZSBhIGRv Y3VtZW50IHRoYXQgZXhwbGFpbnMgdGhlIHByb2JsZW0uLi5JIA0KY2VydGFpbmx5IGRvbid0IGJl bGlldmUgSSBrbm93IGFsbCB0aGUgY2FzZXMgdGhhdCBuZWVkIHRvIGJlIHNvbHZlZC4gIEkgDQp0 aGluayBJIHVuZGVyc3RhbmQgdGhlIGh5cGVydmlzb3IgY2FzZS4uLndoZXJlIHRoZSBoeXBlcnZp c29yIGRlY2lkZXMgDQp3aGljaCB1cGxpbmsgdG8gc2VuZCB0aGluZ3MgdG8sIGFuZCBuZXZlciBm b3J3YXJkcyBiZXR3ZWVuIHRoZSB1cC1saW5rcy4NCg0KVGhpcyBjYXNlIGlzIHNjYXJ5IGJlY2F1 c2UgdGhlIFJCcmlkZ2VzIG9uIHRoZSB1cGxpbmsgY2Fubm90IHNlZSBIZWxsb3MgDQpmcm9tIGVh Y2ggb3RoZXIsIHNvIGlmIG1pc2NvbmZpZ3VyZWQsIGF0IHRoZSB2ZXJ5IGxlYXN0IEkgY291bGQg aW1hZ2luZSANCm11bHRpcGxlIFJCcmlkZ2VzIGRlY2Fwc3VsYXRpbmcgbXVsdGljYXN0IGZyb20g dGhlIGNhbXB1cyB0byB0aGUgDQpoeXBlcnZpc29yLg0KDQpBbnl3YXkuLi5ob3cgbWFueSB1cGxp bmtzIGRvIHdlIG5lZWQgdG8gc3VwcG9ydD8gIERvIHdlIGNhcmUgYWJvdXQgDQpwcm9ibGVtcyBk dWUgdG8gbWlzY29uZmlndXJhdGlvbj8NCg0KSW4gY2FzZXMgbGlrZSB0aGlzLCBpcyBpdCBjb21t b24gdG8gYWxzbyBoYXZlIHB0LXRvLXB0IGxpbmtzIGJldHdlZW4gYWxsIA0KdGhlIFJCcyBhdHRh Y2hpbmcgdG8gdGhlIGh5cGVydmlzb3I/ICBJZiBzbywgdGhlbiBpdCBzZWVtcyBsaWtlIGl0IHdv dWxkIA0KYmUgcG9zc2libGUgZm9yIHRoZW0gdG8gY29vcmRpbmF0ZSB0byBhdCBsZWFzdCBkZXRl Y3QgbWlzY29uZmlndXJhdGlvbiwgDQphbmQgcG9zc2libHkgcGxheSBnYW1lcyB3aXRoIGZvcndh cmRpbmcgbWVzc2FnZXMgdG8gZWFjaCBvdGhlciAoZS5nLiwgaWYgDQpvbmUgb2YgdGhlbSBpcyBu b3QgYXR0YWNoZWQgdG8gYSB0cmVlIGFuZCBuZWVkcyB0byBlbmNhcHN1bGF0ZSBhIA0KbXVsdGlk ZXN0aW5hdGlvbiBmcmFtZSkuDQoNCkhvdyBtYW55IHRyZWVzIGRvZXMgdGhlIGNhbXB1cyBuZWVk Pw0KDQpBcmUgdGhlcmUgY2FzZXMgd2hlcmUgdGhlcmUgYXJlIGxvdHMgb2YgaHlwZXJ2aXNvcnMs IHdoZXJlIHRoZXkgYXR0YWNoIHRvIA0KZGlmZmVyZW50IHN1YnNldHMgb2YgZWRnZSBSQnM/ICBJ biB0aGF0IGNhc2UsIHdlIG1pZ2h0IGVhdCB1cCBhIGxvdCBvZiANCm5pY2tuYW1lcywgc2luY2Ug aWYgb25lIGh5cGVydmlzb3IgaXMgYXR0YWNoZWQgdG8ge1IxLCBSMn0sIGFuZCBhbm90aGVyIGlz IA0KYXR0YWNoZWQgdG8ge1IxLCBSMiwgUjN9LCB0aGV5IGNhbm5vdCB1c2UgdGhlIHNhbWUgcHNl dWRvbm9kZSBuaWNrbmFtZS4NCg0KQXJlIHRoZXJlIGNhc2VzIG90aGVyIHRoYW4gaHlwZXJ2aXNv cnM/ICBJIHRoaW5rIHRoZXJlIGFyZSBjYXNlcyBvZiANCmJyaWRnZXMgdGhhdCBoYXZlIHRoaXMg YmVoYXZpb3IgKGEgcG9ydCB3aXRoIGEgYnVuY2ggb2YgZW5kbm9kZXMsIGFuZCANCnNldmVyYWwg dXAtbGlua3MsIHdoZXJlIHRoZSBicmlkZ2UgZG9lcyBub3QgZm9yd2FyZCBiZXR3ZWVuIHRoZSB1 cC1saW5rcy4gDQogDQoNCklmIHRoaXMgaGFzIGJlZW4gd3JpdHRlbiBkb3duIGFueXdoZXJlLCBj YW4gYW55b25lIHBvaW50IG1lIHRvIGl0PyAgSWYgDQpub3QsIGl0IHNlZW1zIHJlYWxseSBwcnVk ZW50IHRvIGFuc3dlciB0aGVzZSAoYW5kIEknbSBzdXJlIG90aGVyKSANCnF1ZXN0aW9ucyBiZWZv cmUgYXJndWluZyBhYm91dCBzcGVjaWZpYyBzb2x1dGlvbnMuDQoNClJhZGlhDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQp0cmlsbCBtYWlsaW5nIGxp c3QNCnRyaWxsQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3RyaWxsDQoNCg0K --=_alternative 0042706A48257AD3_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFJhZGlhPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7IFRoaXMgY2FzZSBpcyBz Y2FyeSBiZWNhdXNlIHRoZQ0KUkJyaWRnZXMgb24gdGhlIHVwbGluayBjYW5ub3Qgc2VlIEhlbGxv cyBmcm9tIGVhY2ggb3RoZXIsIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+Jmd0OyBzbyBpZiBtaXNjb25maWd1cmVkLCBhdCB0aGUgdmVyeQ0KbGVhc3QgSSBjb3Vs ZCBpbWFnaW5lIG11bHRpcGxlIFJCcmlkZ2VzIGRlY2Fwc3VsYXRpbmcgPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7IG11bHRpY2FzdCBmcm9tIHRoZSBjYW1w dXMgdG8gdGhlDQpoeXBlcnZpc29yLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+Jmd0OyBBbnl3YXkuLi5ob3cgbWFueSB1cGxpbmtzIGRvIHdlDQpuZWVk IHRvIHN1cHBvcnQ/ICZuYnNwO0RvIHdlIGNhcmUgYWJvdXQgcHJvYmxlbXMgZHVlIHRvIG1pc2Nv bmZpZ3VyYXRpb24/PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48 YnI+DQpJIGRvbid0IGtub3cgd2hhdCB0aGUgbWlzY29uZmlndXJhdGlvbiByZWZlcnMgdG8uIElz IGl0IHRoZSBzZXQgb2YgVkxBTnMNCmZvciB3aGljaCBhbiBSYnJpZGdlIGFjdHMgYXMgQUY/PC9m b250Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj4mZ3Q7IEFyZSB0aGVyZSBjYXNlcyB3 aGVyZSB0aGVyZSBhcmUgbG90cyBvZiBoeXBlcnZpc29ycywNCndoZXJlIHRoZXkgYXR0YWNoIHRv IGRpZmZlcmVudCBzdWJzZXRzIG9mIGVkZ2UgUkJzPyAmbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yPiZndDsgSW4gdGhhdCBjYXNlLCB3ZSBtaWdodCBlYXQgdXAgYSBsb3Qgb2Ygbmlja25h bWVzLA0Kc2luY2UgaWYgb25lIGh5cGVydmlzb3IgaXMgYXR0YWNoZWQgdG8ge1IxLCBSMn0sIDwv Zm9udD4NCjxicj48Zm9udCBzaXplPTI+Jmd0OyBhbmQgYW5vdGhlciBpcyBhdHRhY2hlZCB0byB7 UjEsIFIyLCBSM30sIHRoZXkgY2Fubm90DQp1c2UgdGhlIHNhbWUgcHNldWRvbm9kZSBuaWNrbmFt ZS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgZG9u J3Qga25vdyB3aHkgdGhlIHR3byBzZXRzIG9mIFJCcmlkZ2VzDQpjYW4gbm90IHVzZSB0aGUgc2Ft ZSBwc2V1ZG8tbmlja25hbWUuIElmIHRoZSBsZWFybmVkIE1BQyBhZGRyZXNzZXMgPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5jYW4gYmUgc2hhcmVkIGFtb25nIG1l bWJlciBSYnJpZGdlcw0Kb2YgYW4gUkJ2IGFuZCBUUklMTCBkYXRhIGZyYW1lcyBjYW4gYmUgdHVu bmVsZWQgdG8gYW5vdGhlciBtZW1iZXIgUmJyaWRnZTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+dGhhdCBjYW4gZWdyZXNzIHRoZSBmcmFtZSwgSSB0aGluayB0aGV5 DQpjYW4gdXNlIHRoZSBzYW1lIHBzZXVkby1uaWNrbmFtZS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPklmIEkgYW0gd3JvbmcsIHBsZWFzZSBjb3JyZWN0 IG1lLjxicj4NCjxicj4NCkJlc3QgUmVnYXJkcyw8YnI+DQpaaGFpIEhvbmdqdW48YnI+DQomcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDs8YnI+DQogUHJvdG9jb2wgRGV2ZWxvcG1lbnQgRGVwdC5WSSwgQ2Vu dHJhbCBSJmFtcDtEIEluc3RpdHV0ZSwgWlRFIENvcnBvcmF0aW9uPGJyPg0KIE5vLiA2OCwgWmlq aW5naHVhIFJvYWQsIFl1aHVhdGFpIERpc3RyaWN0LCBOYW5qaW5nLCBQLlIuQ2hpbmEsIDIxMDAx Mjxicj4NCiA8YnI+DQogWmhhaSBIb25nanVuPGJyPg0KIDxicj4NCiBUZWw6ICs4Ni0yNS01Mjg3 NzM0NTxicj4NCiBFbWFpbDogemhhaS5ob25nanVuQHp0ZS5jb20uY248YnI+DQomcXVvdDsmcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDs8YnI+DQo8YnI+DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8 dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM2JT48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+UmFkaWEgUGVybG1hbiAmbHQ7cmFkaWFwZXJsbWFu QGdtYWlsLmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPreivP7IyzogJm5ic3A7dHJpbGwtYm91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxwPjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEyLTEyLTEzIDE1OjEzPC9mb250Pg0KPHRk IHdpZHRoPTYzJT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8 ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2Zv bnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPk1pbmd1aSBaaGFu ZyAmbHQ7emhhbmdtaW5ndWlAaHVhd2VpLmNvbSZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4N Cjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOt y808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlRob21h cyBOYXJ0ZW4gJmx0O25hcnRlbkB1cy5pYm0uY29tJmd0OywNClNhbSBBbGRyaW4gJmx0O2FsZHJp bi5pZXRmQGdtYWlsLmNvbSZndDssICZxdW90O1Rpc3NhIFNlbmV2aXJhdGhuZSBcKHRzZW5ldmly XCkmcXVvdDsNCiZsdDt0c2VuZXZpckBjaXNjby5jb20mZ3Q7LCAmcXVvdDt0cmlsbEBpZXRmLm9y ZyZxdW90OyAmbHQ7dHJpbGxAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8 dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98zi PC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogW3Ry aWxsXSBUaG91Z2h0cyBvbiBhY3RpdmUtYWN0aXZlDQplZGdlPC9mb250PjwvdGFibGU+DQo8YnI+ DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFi bGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPkkgdGhpbmsgaXQgd291bGQgYmUgZ29v ZCB0byBoYXZlIGEgZG9jdW1lbnQgdGhhdCBleHBsYWlucw0KdGhlIHByb2JsZW0uLi5JIGNlcnRh aW5seSBkb24ndCBiZWxpZXZlIEkga25vdyBhbGwgdGhlIGNhc2VzIHRoYXQgbmVlZA0KdG8gYmUg c29sdmVkLiAmbmJzcDtJIHRoaW5rIEkgdW5kZXJzdGFuZCB0aGUgaHlwZXJ2aXNvciBjYXNlLi4u d2hlcmUgdGhlDQpoeXBlcnZpc29yIGRlY2lkZXMgd2hpY2ggdXBsaW5rIHRvIHNlbmQgdGhpbmdz IHRvLCBhbmQgbmV2ZXIgZm9yd2FyZHMgYmV0d2Vlbg0KdGhlIHVwLWxpbmtzLjwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTM+VGhpcyBjYXNlIGlzIHNjYXJ5IGJlY2F1c2UgdGhlIFJCcmlk Z2VzIG9uIHRoZSB1cGxpbmsNCmNhbm5vdCBzZWUgSGVsbG9zIGZyb20gZWFjaCBvdGhlciwgc28g aWYgbWlzY29uZmlndXJlZCwgYXQgdGhlIHZlcnkgbGVhc3QNCkkgY291bGQgaW1hZ2luZSBtdWx0 aXBsZSBSQnJpZGdlcyBkZWNhcHN1bGF0aW5nIG11bHRpY2FzdCBmcm9tIHRoZSBjYW1wdXMNCnRv IHRoZSBoeXBlcnZpc29yLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+QW55d2F5Li4u aG93IG1hbnkgdXBsaW5rcyBkbyB3ZSBuZWVkIHRvIHN1cHBvcnQ/ICZuYnNwO0RvDQp3ZSBjYXJl IGFib3V0IHByb2JsZW1zIGR1ZSB0byBtaXNjb25maWd1cmF0aW9uPzwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTM+SW4gY2FzZXMgbGlrZSB0aGlzLCBpcyBpdCBjb21tb24gdG8gYWxzbyBo YXZlIHB0LXRvLXB0DQpsaW5rcyBiZXR3ZWVuIGFsbCB0aGUgUkJzIGF0dGFjaGluZyB0byB0aGUg aHlwZXJ2aXNvcj8gJm5ic3A7SWYgc28sIHRoZW4NCml0IHNlZW1zIGxpa2UgaXQgd291bGQgYmUg cG9zc2libGUgZm9yIHRoZW0gdG8gY29vcmRpbmF0ZSB0byBhdCBsZWFzdCBkZXRlY3QNCm1pc2Nv bmZpZ3VyYXRpb24sIGFuZCBwb3NzaWJseSBwbGF5IGdhbWVzIHdpdGggZm9yd2FyZGluZyBtZXNz YWdlcyB0byBlYWNoDQpvdGhlciAoZS5nLiwgaWYgb25lIG9mIHRoZW0gaXMgbm90IGF0dGFjaGVk IHRvIGEgdHJlZSBhbmQgbmVlZHMgdG8gZW5jYXBzdWxhdGUNCmEgbXVsdGlkZXN0aW5hdGlvbiBm cmFtZSkuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mz5Ib3cgbWFueSB0cmVlcyBkb2Vz IHRoZSBjYW1wdXMgbmVlZD88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPkFyZSB0aGVy ZSBjYXNlcyB3aGVyZSB0aGVyZSBhcmUgbG90cyBvZiBoeXBlcnZpc29ycywgd2hlcmUNCnRoZXkg YXR0YWNoIHRvIGRpZmZlcmVudCBzdWJzZXRzIG9mIGVkZ2UgUkJzPyAmbmJzcDtJbiB0aGF0IGNh c2UsIHdlIG1pZ2h0DQplYXQgdXAgYSBsb3Qgb2Ygbmlja25hbWVzLCBzaW5jZSBpZiBvbmUgaHlw ZXJ2aXNvciBpcyBhdHRhY2hlZCB0byB7UjEsDQpSMn0sIGFuZCBhbm90aGVyIGlzIGF0dGFjaGVk IHRvIHtSMSwgUjIsIFIzfSwgdGhleSBjYW5ub3QgdXNlIHRoZSBzYW1lDQpwc2V1ZG9ub2RlIG5p Y2tuYW1lLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+QXJlIHRoZXJlIGNhc2VzIG90 aGVyIHRoYW4gaHlwZXJ2aXNvcnM/ICZuYnNwO0kgdGhpbmsNCnRoZXJlIGFyZSBjYXNlcyBvZiBi cmlkZ2VzIHRoYXQgaGF2ZSB0aGlzIGJlaGF2aW9yIChhIHBvcnQgd2l0aCBhIGJ1bmNoDQpvZiBl bmRub2RlcywgYW5kIHNldmVyYWwgdXAtbGlua3MsIHdoZXJlIHRoZSBicmlkZ2UgZG9lcyBub3Qg Zm9yd2FyZCBiZXR3ZWVuDQp0aGUgdXAtbGlua3MuICZuYnNwOzwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTM+SWYgdGhpcyBoYXMgYmVlbiB3cml0dGVuIGRvd24gYW55d2hlcmUsIGNhbiBh bnlvbmUgcG9pbnQNCm1lIHRvIGl0PyAmbmJzcDtJZiBub3QsIGl0IHNlZW1zIHJlYWxseSBwcnVk ZW50IHRvIGFuc3dlciB0aGVzZSAoYW5kIEknbQ0Kc3VyZSBvdGhlcikgcXVlc3Rpb25zIGJlZm9y ZSBhcmd1aW5nIGFib3V0IHNwZWNpZmljIHNvbHV0aW9ucy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0zPlJhZGlhPC9mb250Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQp0cmlsbCBtYWls aW5nIGxpc3Q8YnI+DQp0cmlsbEBpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdHJpbGw8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCg== --=_alternative 0042706A48257AD3_=-- From windy_1@skyhighway.com Thu Dec 13 08:44:04 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C7921F8B3D for ; Thu, 13 Dec 2012 08:44:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.338 X-Spam-Level: X-Spam-Status: No, score=-1.338 tagged_above=-999 required=5 tests=[AWL=1.203, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opxBM4GG1SAW for ; Thu, 13 Dec 2012 08:44:03 -0800 (PST) Received: from skyhighway.com (skyhighway.com [63.249.82.6]) by ietfa.amsl.com (Postfix) with ESMTP id A74FC21F8B07 for ; Thu, 13 Dec 2012 08:43:57 -0800 (PST) Received: from Firefly.skyhighway.com (dsl-63-249-88-160.static.cruzio.com [63.249.88.160]) by skyhighway.com with ESMTP id qBDGhu3W054804 for ; Thu, 13 Dec 2012 08:43:56 -0800 (PST) Message-Id: <201212131643.qBDGhu3W054804@skyhighway.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 13 Dec 2012 08:44:09 -0800 To: trill@ietf.org From: gayle noble Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [trill] corrections->draft-hu-trill-pseudonode-nickname-04 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:44:04 -0000
(in my opinion grammatical and spelling corrections)
Abstract (page 1)
(if I understand what is trying to be communicated ???)
However, in some application scenarios, for example an end station is multi-homed to multiple RBridges[,] needs [there is a need] to improve the resiliency and increase the available network bandwidth of the connection.
 
(page 4)
This paragraph is repeated twice
In TRILL protocol, RBridges are identified by nicknames (16-bits). At the edge of TRILL network, some RBridges connect to legacy networks on one side and connect to the TRILL network on the other side. These RBridges are called edge RBridges. For the connectivity between the two types of network, edge RBridges provide frame forwarding service to end stations located in legacy networks. When receiving a native frame from such a local end station S, the service edge RBridge RB1 encapsulates the frame in a TRILL header, addressing the packet to RBridge RBx to which the destination end station D is attached. The TRILL header contains an "ingress RBridge nickname" field (filled with RB1's nickname), an "egress RBridge nickname" field (filled with RBx's nickname), and a hop count. On receiving such a frame, RBx removes the TRILL header and forwards it in native form to D. Meanwhile, based on the de-capsulation of that frame, RBx learns the { ingress RBridge nickname, source MAC address, VLAN ID } triplet. Edge RBridges maintain such triplets in their forwarding tables for the future forwarding of native frames.
 
 
(page 5)
In this document, the concept of [a] Virtual RBridge group, together with its Pseudo-nickname, is introduced to address the rest of above issues.
 
(if I understand what this is trying to communicate)
So, in such a RBridge Group, even if there are more than one RBridge providing frame forwarding service for an end station or the service RBridge changes over from one to another member RBridge in same group, the ingress RBridge nickname associated to this end station needs [need] not be unchanged [changed] in remote RBridges' forwarding tables.
 
2.2. Multi-homing and Link Aggregation to TRILL Network (page 6)
 
In order to improve the reliability of connection to [a] TRILL network, multi-homing technique may be employed by a legacy device which can be a switch or end host. Take Figure 1 as an example, switch SW1 multi-homes to [the] TRILL network by connecting to RB1 and RB2 with respective links. Then the end station S1 can continue to get frame forwarding service from [the] TRILL network even if one of its up-links (e.g., SW1-RB1) fails.
 
SW1 may treat the two links as a LAG (Link Aggregation Group) bundle, so that the two links form [an] active-active load sharing model instead of [the] previous active-standby model.
 
(page 6 and 7)
That is to say, in Figure 1, two RBridges (i.e., RB1 and RB2) provides [provide] frame forwarding service to S1 simultaneously in a VLAN.
 
(page 7)(the word that is not needed)
As stated previously, that [----] simultaneous frame forwarding may result in frame duplication, loops and the flip-flopping of the ingress RBridge associated to the MAC of S1 in remote RBridges' (e.g., RBx) forwarding tables.
 
 After joining RBv, such an [a] RBridge port is called a member port of RBv, and such an [a] RBridge becomes a member RBridge of RBv. An [A]RBv is identified by its virtual nickname in TRILL campus, and this nickname is also referred to as pseudo-nickname in this document.
 
After joining an [a] RBv, a member RBridge will announce its connection to RBv by including the information of that RBv, e.g., the pseudo-nickname of RBv, in its self-originated LSP.
 
NOTE: An [A] RBridge port can join at most one RBv at any time, but different ports on the same RBridge can join the same RBv or different RBvs.
 
Furthermore, for a member RBridge, it MUST move out of an [a] RBv and clear the RBv's information from its self-originated LSPs when it loses all of its member ports of the RBv, due to port failure, configuration, etc.
 
To guarantee member RBridges of an [a] RBv group to ingress (i.e., northbound forwarding) and egress (i.e., southbound forwarding) multi-destination frames properly, and to provide protection in case of member link failure as well, this document proposes to allocate the trees among member RBridges in northbound and southbound directions respectively.
 
4.1. Trees for Native Frames Ingressing (page 9)
 
If the frame is received not from that port [not received from that port], it MUST be dropped.
 
(if I am understanding this sentence "frames regardless" is not needed)
However, member RBridges use RBv's pseudo-nickname other than their own nicknames as the ingress nickname when they forward northbound frames regardless [ --- ]unicast or non-unicast frames.
 
That change [is] beyond the scope of this document.
 
4.2. Designated Forwarder for traffic received on Distribution trees (page 9)
 
[The methodology] Methodology explained above addresses the association of distribution trees to RBx on behalf of RBv for native traffic received from the edge.
 
//(who refers to people - as in Dr. Who >*grin*<)
However, remote RBridge RBn who [which] is unaware of the RBv association[,] may choose to forward traffic along any of the available distribution trees.
 
(Step 4: page 11)[note: I am guessing as to the word wanted represented by the letter e]
However, since only one member RBridge of RBv is elected as AF for e [each] set of VLANs on a shared link and responsible to egress multi-=20 destination TRILL data frames to this link, each member RBridge MUST assign itself as the Designated Forwarder for all the distribution trees to guarantee multi-destination frames on any tree will be egressed onto this link by an member RBridge (please refer Section 5.2.2 for more details).
 
5.2.1. Unicast TRILL Data Frames (page 12)
["in" repeated twice]
When receiving a unicast TRILL data frame, RBn checks the egress nickname in the TRILL header of the frame. If the egress nickname is one of RBn's own nicknames, the frame is processed as defined in in [--] [RFC6325].
 
(page 13)
RBn uses RBk's own nickname, instead of RBv's pseudo-nickname as the egress nickname for the re-encapsulation, and remains the ingress nickname [the ingress nickname remains] unchanged.
 
[both a period and a comma are in the text, only the comma is needed]
[NOTE: When receiving that re-encapsulated TRILL frame, as the egress nickname of the frame is RBk's own nickname rather than the RBv's pseudo-nickname, RBk will process it as Section 4.6.2.4 in [RFC6325].[ -- ], and will not re-forward it to another RBridge.]
 
Else, RBn does not know how to reach the destination; it sends the native frame out of all its member ports of RBv on which it is appointed forwarders [forwarder] for the Inner.VLAN.
 
(page 14 & 15) [I corrected "is" and "it" to plural due to the use of the word frames in this and the following sentence]
Then when [the] TRILL data frames to CE1 is [are] delivered to RB1, it [they] can be re-encapsulated (ingress nickname remains unchanged and egress nickname is replaced by RB2's nickname) by RB1 and forwarded based on the above installed MAC entry. The member RBridge who receives the redirected frames will egress them to CE1.
 
(page 16) ["an not need as links is plural]
* 01: Withdrawal (LAG-IDs in this sub-TLV do not have an [--] active      links from the announcing RBridge for RBv and Designated Forwarder election MUST be recalculated).
 
(page 16 & 17)
If it has the membership, receiving such a sub-TLV where the operation code is 00 or 01 will triggers [trigger] it to re-calculate the Designated Forwarder on each tree for the listed LAGs.
 
(page 19)
Thus, the learned MAC addresses of attached end stations on one member RBridge SHOULD be shared with the rest member [rest of the member] RBridges in the same RBv.
 
As a result, RB1 has to treat the traffic from S1 to Sx as traffic with unknown destination and flood it in TRILL, which adds additional forwarding burden on [the] TRILL network.
 
 Therefore, in addition to local attached end station MAC addresses, the learned remote MAC addresses should also be shared among all member RBridges of an [a] RBv.

From windy_1@skyhighway.com Thu Dec 13 08:45:23 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED20C21F8B7F for ; Thu, 13 Dec 2012 08:45:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.895 X-Spam-Level: X-Spam-Status: No, score=0.895 tagged_above=-999 required=5 tests=[AWL=-1.373, BAYES_00=-2.599, HTML_EXTRA_CLOSE=2.809, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2lGnTb47p1U for ; Thu, 13 Dec 2012 08:45:23 -0800 (PST) Received: from skyhighway.com (skyhighway.com [63.249.82.6]) by ietfa.amsl.com (Postfix) with ESMTP id DF17121F8B03 for ; Thu, 13 Dec 2012 08:45:22 -0800 (PST) Received: from Firefly.skyhighway.com (dsl-63-249-88-160.static.cruzio.com [63.249.88.160]) by skyhighway.com with ESMTP id qBDGjFUU059408 for ; Thu, 13 Dec 2012 08:45:15 -0800 (PST) Message-Id: <201212131645.qBDGjFUU059408@skyhighway.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 13 Dec 2012 08:45:28 -0800 To: trill@ietf.org From: gayle noble Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Subject: [trill] corrections ->draft-ietf-trill-fine-labeling-03 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:45:24 -0000
(in my opinion) grammatical and spelling corrections to corrections draft-ietf-trill-fine-labeling-03
-------
1.1 Terminology (page 3)
  Edge TRILL switch - A TRILL switch announcing VLAN or Fien [Fine]Grained Lab el [Label] interest in its LSP.
 
4. Alternate Priority (page 6)
It would be desirable for an ingress TRILL Switch to be able to assign a different priority to an [a] FGL TRILL Data frame for its ingress-to-egress propagation from the priority of the original native frame.
 
2.4 VL, Limited FGL, and Full FGL TRILL Switches (page 8)
It will be simpler to use the same type of label for all TRILL switche [switches] for this purpose.
 
If a campus is being upgraded from VL [to] FGL TRILL switches, it avoids a requirement to immediately reconfigure all ports with FGL configuration.
 
As discussed in Section 4, VL TRILL switches conformant to [RFC6325] should discard an [a] FGL TRILL Data frame as malformed.
 
3. VL versus FGL Label Differences (page 10)
With FGL TRILL switches, many things remain the same because an [a]FGL can appear only as the Inner.Label inside a TRILL Data frame.
 
Thus, for ports configured for FGL, the native frame C-VLAN on one link corresponding to an [a] FGL can be different from the native frame C-VLAN corresponding to that same FGL on a different link elsewhere in the campus or even a different link attached to the same TRILL switch
 
4.2 FGL and VL Mixed Campus Characteristics (page 12)
The [There] are possible future extensions to TRILL that would eliminate the requirement to block TRILL Data traffic between FGL and VL TRILL switches improving backwards compatibility.
 
5.1 Ingress Processing (page 14)
Thus Full FGL TRILL switches MUST support configurable per port mapping from the C-VLAN of a native frame, as reported by the ingress port, to an [a]FGL.

5.2.2 Multi-Destination Transit Processing (page 15)
Multi-destination TRILL Data frames are forwarded on a distribution tree selected by the ingress TRILL switch except that an [a] FGL ingress TRILL switch may TRILL unicast such a frame to all relevant egress TRILL switches as described in Section 5.1.
 
An [A] FGL TRILL switch, say RB1, having an [a] FGL multi-destination frame for label (X.Y) to forward on a distribution tree, SHOULD prune that tree based on whether there are any edge TRILL switches on a tree branch that are advertising connectivity to label (X.Y).
 
5.3 Egress Processing (page 16)
 
A Full FGL TRILL switch MUST be able to configurably [be configured to] convert the FGL in an FGL TRILL Data frame it is egressing to a C-VLAN ID for the resulting native frame on a per port basis.
 
An [A] FGL TRILL switch egresses FGL frames similarly to the egressing of VL frames, as follows:
 
If there are no such ports, it is flooded out all FGL ports that have its FGL except any ports that for which the TRILL switch has knowledge    that the frame's Inner.MacDA cannot be [go] out that port.
 
An [A] FGL TRILL switch, including a Limited FGL TRILL switch that might have limited knowledge of FGL formats, MUST NOT egress an [a] FGL frame with label (X.Y) to any port not configured with that label even if the port is configured to egress VL frames in VLAN X.
 
5.5 Address Learning (page 17)
An [A] FGL TRILL switch learns addresses on ports configured for FGL based on the fine-grained label rather than the native frame's VLAN.
 
(page 22)
As a result, no TRILL data frames can be exchanged between VL and FGL TRILL switches and they will be isolated form [from] each other for data purposes.
From radiaperlman@gmail.com Thu Dec 13 10:10:42 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB2E421F8B56; Thu, 13 Dec 2012 10:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.675 X-Spam-Level: X-Spam-Status: No, score=-1.675 tagged_above=-999 required=5 tests=[AWL=-1.923, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, WEIRD_QUOTING=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ItOkcl7f2Jpa; Thu, 13 Dec 2012 10:10:40 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6A75421F8B55; Thu, 13 Dec 2012 10:10:39 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so2761857vcb.31 for ; Thu, 13 Dec 2012 10:10:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CNUE5iERhQtgwPQTH9Rgap9YP1OggUoXhmOyO0GR9To=; b=z6Xz9fQiNp1PnjpRPKA3doscRdbCJTHFfAolQZrF+GJ/k4G9iW9/HVR6vkjyFmsyzV GDvZcYzs1UCeewFS1W/Fo31wU+VszEddew4bREIIwlYV3iKNtNY58uEiuo3KfBdH585m 5qIokCwSU+6dVpHTu9HmI/GQZqbJfOBEE0Sl01w6ZWcwkUgsDtJH+5nRKNgF8Q8fZM5x /DaQ0QW+W/rTtffn1z7KXBqRVqP3CD1lInjaxjMEO7AVlmSewRkW9CGfBCMRQvuc+bby LMSSp1qJBbUfjWoTaBPWr/EoeJtYSGyenI8+fLh4KHDPmspuH5uH29A4jsPi1KE2fONG qavg== MIME-Version: 1.0 Received: by 10.220.150.84 with SMTP id x20mr4888539vcv.73.1355422238761; Thu, 13 Dec 2012 10:10:38 -0800 (PST) Received: by 10.58.207.138 with HTTP; Thu, 13 Dec 2012 10:10:38 -0800 (PST) In-Reply-To: References: Date: Thu, 13 Dec 2012 10:10:38 -0800 Message-ID: From: Radia Perlman To: zhai.hongjun@zte.com.cn Content-Type: multipart/alternative; boundary=f46d043c7c080fe31504d0bfd504 Cc: Thomas Narten , trill-bounces@ietf.org, Sam Aldrin , Mingui Zhang , "trill@ietf.org" , "Tissa Senevirathne \(tsenevir\)" Subject: Re: [trill] Thoughts on active-active edge X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 18:10:42 -0000 --f46d043c7c080fe31504d0bfd504 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Answering Zhai Hongjun's questions: Why it is necessary to have a different pseuonode nickname if the upllnk is to different sets of RBridges: If hypervisor H1 has uplinks to R1, R2, and R3, and uses pseudonode nickname P1, and hypervisor H2 has uplinks to R1 and R2 (or even had uplinks to R1, R2, and R3, but its link to R3 fails), then if H1 and H2 use the same nickname, say P1, then traffic for H2's MAC addresses might get sent to R3 (since R3 has to claim to be connected to P1 because it is, for H1). But it is no longer attached to H2 because H2's uplink to R3 failed. The safest thing would be for every hypervisor to have a nickname. So, how many hypervisors are there likely to be? How usual would it be for all of them to attach to the same set of uplinks, so that we can use the same pseuodnode nickname? Do we care about the case of one of a hypervisor's uplinks failing, in which case, would the RBridges know? If R3 (the one to which the uplink failed) know? Would R1 and R2 know? Even if R3 knew, how could it alert R1 and R2 to now use a different pseudonode nickname for H2? Would it be obvious to them which of the hypervisors that have uplinks to R1, R2, and R3 they are referring to? All of this must be configured, I assume, and if the configuration is wrong, then who knows what happens..presumably that traffic may or may not get delivered to a hypervisor. And even if configured properly, what happens when uplinks fail? Again, presumably, traffic may or may not get delivered to the hypervisor whose uplink fails. ------------- As for VLANs...that actually is not a problem here, since we're not using AFs. The hypervisor determines which uplink to send something to. And which tree is being used for distribution determines which of R1, R2, or R3 will decapsulate the packet. So the main sort of configuration that I can think of, off the top of my head, is which pseudonodes go with which hypervisors. And I do think configuration is scary, especially if there's no "sanity check" whereby the RBs can compare notes. I don't know how R1 can know that a particular port is to "H1" so that it can inform R2 (via LSPs?) that R1 is attached to H1, and R2 can notice that it, indeed, is also attached to H1. -------- And part of the description of the problem would be answering questions like how many uplinks would need to be supported. Two at most? 30? If a lot, then solutions that require a tree for every uplink would be problematic if implementations don't want to support that many trees. Or is it OK to require lots of trees? So I think there are lots of things that should be written down, as part of describing the problem. Radia On Thu, Dec 13, 2012 at 4:03 AM, wrote: > > Hi Radia > > > This case is scary because the RBridges on the uplink cannot see Hellos > from each other, > > so if misconfigured, at the very least I could imagine multiple RBridge= s > decapsulating > > multicast from the campus to the hypervisor. > > > Anyway...how many uplinks do we need to support? Do we care about > problems due to misconfiguration? > > I don't know what the misconfiguration refers to. Is it the set of VLANs > for which an Rbridge acts as AF? > > > > Are there cases where there are lots of hypervisors, where they attach > to different subsets of edge RBs? > > In that case, we might eat up a lot of nicknames, since if one > hypervisor is attached to {R1, R2}, > > and another is attached to {R1, R2, R3}, they cannot use the same > pseudonode nickname. > > I don't know why the two sets of RBridges can not use the same > pseudo-nickname. If the learned MAC addresses > can be shared among member Rbridges of an RBv and TRILL data frames can b= e > tunneled to another member Rbridge > that can egress the frame, I think they can use the same pseudo-nickname. > > If I am wrong, please correct me. > > > Best Regards, > 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 > """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" > > > > > *Radia Perlman * > =B7=A2=BC=FE=C8=CB: trill-bounces@ietf.org > > 2012-12-13 15:13 > =CA=D5=BC=FE=C8=CB > Mingui Zhang > =B3=AD=CB=CD > Thomas Narten , Sam Aldrin , > "Tissa Senevirathne \(tsenevir\)" , "trill@ietf.org" = < > trill@ietf.org> > =D6=F7=CC=E2 > Re: [trill] Thoughts on active-active edge > > > > > I think it would be good to have a document that explains the problem...I > certainly don't believe I know all the cases that need to be solved. I > think I understand the hypervisor case...where the hypervisor decides whi= ch > uplink to send things to, and never forwards between the up-links. > > This case is scary because the RBridges on the uplink cannot see Hellos > from each other, so if misconfigured, at the very least I could imagine > multiple RBridges decapsulating multicast from the campus to the hypervis= or. > > Anyway...how many uplinks do we need to support? Do we care about > problems due to misconfiguration? > > In cases like this, is it common to also have pt-to-pt links between all > the RBs attaching to the hypervisor? If so, then it seems like it would = be > possible for them to coordinate to at least detect misconfiguration, and > possibly play games with forwarding messages to each other (e.g., if one = of > them is not attached to a tree and needs to encapsulate a multidestinatio= n > frame). > > How many trees does the campus need? > > Are there cases where there are lots of hypervisors, where they attach to > different subsets of edge RBs? In that case, we might eat up a lot of > nicknames, since if one hypervisor is attached to {R1, R2}, and another i= s > attached to {R1, R2, R3}, they cannot use the same pseudonode nickname. > > Are there cases other than hypervisors? I think there are cases of > bridges that have this behavior (a port with a bunch of endnodes, and > several up-links, where the bridge does not forward between the up-links. > > If this has been written down anywhere, can anyone point me to it? If > not, it seems really prudent to answer these (and I'm sure other) questio= ns > before arguing about specific solutions. > > Radia > > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill > > --f46d043c7c080fe31504d0bfd504 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Answering Zhai Hongjun's qu= estions:

Why it is nec= essary to have a different pseuonode nickname if the upllnk is to different= sets of RBridges:

If hypervisor H1 has uplinks to R1, R2, and R3, and uses pse= udonode nickname P1, and hypervisor H2 has uplinks to R1 and R2 (or even ha= d uplinks to R1, R2, and R3, but its link to R3 fails), then if H1 and H2 u= se the same nickname, say P1, then traffic for H2's MAC addresses might= get sent to R3 (since R3 has to claim to be connected to P1 because it is,= for H1).  But it is no longer attached to H2 because H2's uplink = to R3 failed.

The safest thing would be for every hypervisor to have = a nickname.

So, how many hypervisors are there lik= ely to be?  How usual would it be for all of them to attach to the sam= e set of uplinks, so that we can use the same pseuodnode nickname?  Do= we care about the case of one of a hypervisor's uplinks failing, in wh= ich case, would the RBridges know?  If R3 (the one to which the uplink= failed) know?  Would R1 and R2 know?  Even if R3 knew, how could= it alert R1 and R2 to now use a different pseudonode nickname for H2? &nbs= p;Would it be obvious to them which of the hypervisors that have uplinks to= R1, R2, and R3 they are referring to?

All of this must be configured, I assume, and if the co= nfiguration is wrong, then who knows what happens..presumably that traffic = may or may not get delivered to a hypervisor.  And even if configured = properly, what happens when uplinks fail?  Again, presumably, traffic = may or may not get delivered to the hypervisor whose uplink fails.

-------------
As for VLANs...that actually is= not a problem here, since we're not using AFs.  The hypervisor de= termines which uplink to send something to.  And which tree is being u= sed for distribution determines which of R1, R2, or R3 will decapsulate the= packet.

So the main sort of configuration that I can think of, = off the top of my head, is which pseudonodes go with which hypervisors. &nb= sp;And I do think configuration is scary, especially if there's no &quo= t;sanity check" whereby the RBs can compare notes.  I don't k= now how R1 can know that a particular port is to "H1" so that it = can inform R2 (via LSPs?) that R1 is attached to H1, and R2 can notice that= it, indeed, is also attached to H1.

--------
And part of the description of the p= roblem would be answering questions like how many uplinks would need to be = supported.  Two at most?  30?  If a lot, then solutions that= require a tree for every uplink would be problematic if implementations do= n't want to support that many trees.  Or is it OK to require lots = of trees?

So I think there are lots of things that should be writ= ten down, as part of describing the problem.


<= /div>

Radia





On Thu, Dec 13= , 2012 at 4:03 AM, <zhai.hongjun@zte.com.cn> wrote:

Hi Radia

> This case is scary because the RBridges on the uplink cannot see Hellos from each other,
> so if misconfigured, at the very least I could imagine multiple RBridges decapsulating
> multicast from the campus to the hypervisor.

> Anyway...how many uplinks do we need to support?  Do we care about problems due to misconfiguration?

I don't know what the misconfiguration refers to. Is it the set of VLAN= s for which an Rbridge acts as AF?


> Are there cases where there are lots of hypervisors, where they attach to different subsets of edge RBs?  
> In that case, we might eat up a lot of nicknames, since if one hypervisor is attached to {R1, R2},
> and another is attached to {R1, R2, R3}, they cannot use the same pseudonode nickname.

I don't know why the two sets of RB= ridges can not use the same pseudo-nickname. If the learned MAC addresses
can be shared among member Rbridges of an RBv and TRILL data frames can be tunneled to another member Rbridge
that can egress the frame, I think they can use the same pseudo-nickname.

If I am wrong, please correct me.


Best Regards,
Zhai Hongjun
""""""""""""&qu= ot;""""""""""""= """"""""""""&qu= ot;""""""""""""= """"""""""""&qu= ot;"""""""
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.h= ongjun@zte.com.cn
""""""""""""&qu= ot;""""""""""""= """"""""""""&qu= ot;""""""""""""= """"""""""""&qu= ot;""""""""


Radia Perlman <= ;radiaperlman@g= mail.com>
=B7=A2=BC=FE=C8=CB:  trill-bounces@ietf.org=

2012-12-13 15:13

=CA=D5=BC=FE=C8= =CB
Mingui Zhang <zhangmingui@huawei.com&= gt;
=B3=AD=CB=CD
Thomas Narten <narten@us.ibm.com>, Sam Aldrin <a= ldrin.ietf@gmail.com>, "Tissa Senevirathne \(tsenevir\)" <tsenevir@cisco.= com>, "tril= l@ietf.org" <trill@ietf.org>
=D6=F7=CC=E2
Re: [trill] Thoughts on activ= e-active edge





I think it would be good to have a document that expla= ins the problem...I certainly don't believe I know all the cases that need to be solved.  I think I understand the hypervisor case...where the hypervisor decides which uplink to send things to, and never forwards betwe= en the up-links.

This case is scary because the RBridges on the uplink cannot see Hellos from each other, so if misconfigured, at the very least I could imagine multiple RBridges decapsulating multicast from the campus to the hypervisor.

Anyway...how many uplinks do we need to support?  = ;Do we care about problems due to misconfiguration?

In cases like this, is it common to also have pt-to-pt links between all the RBs attaching to the hypervisor?  If so, then it seems like it would be possible for them to coordinate to at least detec= t misconfiguration, and possibly play games with forwarding messages to each other (e.g., if one of them is not attached to a tree and needs to encapsul= ate a multidestination frame).

How many trees does the campus need?

Are there cases where there are lots of hypervisors, w= here they attach to different subsets of edge RBs?  In that case, we might eat up a lot of nicknames, since if one hypervisor is attached to {R1, R2}, and another is attached to {R1, R2, R3}, they cannot use the same pseudonode nickname.

Are there cases other than hypervisors?  I think there are cases of bridges that have this behavior (a port with a bunch of endnodes, and several up-links, where the bridge does not forward betwee= n the up-links.  

If this has been written down anywhere, can anyone poi= nt me to it?  If not, it seems really prudent to answer these (and I'= m sure other) questions before arguing about specific solutions.

Radia

_________= ______________________________________
trill mailing list
trill@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/trill

--f46d043c7c080fe31504d0bfd504-- From hu.fangwei@zte.com.cn Thu Dec 13 18:32:18 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43B8C21F8BD7; Thu, 13 Dec 2012 18:32:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.097 X-Spam-Level: X-Spam-Status: No, score=-97.097 tagged_above=-999 required=5 tests=[AWL=-1.298, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, J_CHICKENPOX_83=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100, WEIRD_QUOTING=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJvBjB1ihNQd; Thu, 13 Dec 2012 18:32:17 -0800 (PST) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA7221F8945; Thu, 13 Dec 2012 18:32:15 -0800 (PST) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id C15971243C00; Fri, 14 Dec 2012 10:34:06 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id D2C2C724D46; Fri, 14 Dec 2012 10:21:16 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id qBE2W01P005773; Fri, 14 Dec 2012 10:32:00 +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: Fri, 14 Dec 2012 10:31:54 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-12-14 10:31:53, Serialize complete at 2012-12-14 10:31:53 Content-Type: multipart/alternative; boundary="=_alternative 000DE9C848257AD4_=" X-MAIL: mse02.zte.com.cn qBE2W01P005773 Cc: Thomas Narten , zhai.hongjun@zte.com.cn, trill-bounces@ietf.org, Sam Aldrin , Mingui Zhang , "trill@ietf.org" , "Tissa Senevirathne \(tsenevir\)" Subject: Re: [trill] Thoughts on active-active edge X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 02:32:18 -0000 This is a multipart message in MIME format. --=_alternative 000DE9C848257AD4_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 VGhlcmUgaXMgb25seSBvbmUgUkJyaWRnZSh0aGF0IGlzIEFGKSB0byBkbyB0aGUgVFJJTEwgZW5j YXB1c2xhdGlvbiBpbiB0aGUgDQpzaGFyZWQgTEFOIGxpbmsgc2NlbmFyaW8uU28gd2UgY2FuIGlu dHJvZHVjZSB0aGUgcHNldWRvbm9kZSBuaWNrbmFtZSB0byANCmlkZW50eSB0aGUgc2hhcmVkIGxp bmssIGFuZCBhdm9pZCB0aGUgcG90ZW50aWFsIGRhdGEgbG9zcyB3aGVuIEFGIGNoYW5nZWQuIA0K V2hpbGUgaXQgaXMgZGlmZmVyZW50IGZvciB0aGUgYWN0aXZlLWFjdGl2ZSBlZGdlIHNjZW5hcmlv OiBhbGwgdGhlIA0KUkJyaWRnZXMgaW4gdGhlIExBRy1ncm91cCBzaG91bGQgZG8gdGhlIFRSSUxM IGVuY2Fwc3VsYXRpb24sIGFuZCB0aGUgDQpSQnJpZGdlIGNhbm5vdCBzZWUgSGVsbG9zIGZyb20g ZWFjaCBvdGhlciwgdGhlcmUgaXMgbm8gQUYgaW4gdGhpcyBjYXNlIA0KYWN0dWFsbHkuIFNvIHBz ZXVkb25vZGUgbmlja25hbWUgaXMgbm90IGZpdCBmb3IgYWN0aXZlLWFjdGl2ZSBlZGdlLg0KDQpX ZSBjb3VsZCB1c2UgdGhlIGNvbnRyb2wgcHJvdG9jb2woZm9yIGV4YW1wbGUsIEVTQURJICl0byBs ZWFybiB0aGUgTUFDIGFuZCANCm5pY2tuYW1lLCBhbmQgYXZvaWQgdGhlIE1BQyBmbGlwIGJ5IGFk ZGluZyBhIG5ldyBJRChsaW5rLUlEKS4gSWYgdGhlIA0KcmVtb3RlIHJlY2VpdmVzIHR3byByZWNv cmRzIHdpdGggdGhlIHNhbWUgTGluay1JRCxpdCBzaG91bGQgdGhpbmsgYm90aCBvZiANCnRoZW0g YXJlIE9rLiANCg0KIFIxIGFuZCBSMiB0ZWxsIFI4IHRoYXQgSDEgaXMgbXVsdGktaG9taW5nIHRv IHRoZSB0cmlsbCBjYW1wdXMsIHRoZXkgdXNlIA0KdGhlIHNhbWUgTGluay1JRCB0byBpZGVudGlm eSB0aGUgTEFHLWdyb3VwLiBXaGVuIFI4IHJlY2VpdmVzIHRoZSANCmluZm9ybWF0aW9uLCBpdCBr ZWVwcyB0d28gcmVjb3JkcyBmb3IgSDEsIG9uZSBpcyBSMSwgYW5kIHRoZSBvdGhlciBpcyBSMi4g DQpUaGUgYmFjayBkYXRhIGZyYW1lIGNvdWxkIGNob2ljZSBlaXRoZXIgUjEgb3IgUjIgYXMgdGhl IGVncmVzcyBuaWNrbmFtZS4NCg0KSWYgdGhlIGxpbmsgYmV0d2VlbiBIMSBhbmQgUjIgZmFpbHMs IHRoZSByZWNvcmQgUjIgaXMgY2xlYXIuDQoNCklmIHRoZXJlIGlzIGFub3RoZXIgbGluayBmb3Ig SDEsIHNheSBSMywgYW5kIFIzIHVzZXMgdGhlIHNhbWUgbGluay1pZCwgc28gDQpSOCBrZWVwcyBh bm90aGVyIHJlY29yZCBmb3IgSDEuDQoNCkJlc3QgcmVnYXJkcy4NCg0KDQoNCg0KUmFkaWEgUGVy bG1hbiA8cmFkaWFwZXJsbWFuQGdtYWlsLmNvbT4gDQq3orz+yMs6ICB0cmlsbC1ib3VuY2VzQGll dGYub3JnDQoyMDEyLTEyLTE0IDAyOjEwDQoNCsrVvP7Iyw0KemhhaS5ob25nanVuQHp0ZS5jb20u Y24NCrOty80NClRob21hcyBOYXJ0ZW4gPG5hcnRlbkB1cy5pYm0uY29tPiwgdHJpbGwtYm91bmNl c0BpZXRmLm9yZywgU2FtIEFsZHJpbiANCjxhbGRyaW4uaWV0ZkBnbWFpbC5jb20+LCBNaW5ndWkg WmhhbmcgPHpoYW5nbWluZ3VpQGh1YXdlaS5jb20+LCANCiJ0cmlsbEBpZXRmLm9yZyIgPHRyaWxs QGlldGYub3JnPiwgIlRpc3NhIFNlbmV2aXJhdGhuZSBcKHRzZW5ldmlyXCkiIA0KPHRzZW5ldmly QGNpc2NvLmNvbT4NCtb3zOINClJlOiBbdHJpbGxdIFRob3VnaHRzIG9uIGFjdGl2ZS1hY3RpdmUg ZWRnZQ0KDQoNCg0KDQoNCg0KQW5zd2VyaW5nIFpoYWkgSG9uZ2p1bidzIHF1ZXN0aW9uczoNCg0K V2h5IGl0IGlzIG5lY2Vzc2FyeSB0byBoYXZlIGEgZGlmZmVyZW50IHBzZXVvbm9kZSBuaWNrbmFt ZSBpZiB0aGUgdXBsbG5rIA0KaXMgdG8gZGlmZmVyZW50IHNldHMgb2YgUkJyaWRnZXM6DQoNCklm IGh5cGVydmlzb3IgSDEgaGFzIHVwbGlua3MgdG8gUjEsIFIyLCBhbmQgUjMsIGFuZCB1c2VzIHBz ZXVkb25vZGUgDQpuaWNrbmFtZSBQMSwgYW5kIGh5cGVydmlzb3IgSDIgaGFzIHVwbGlua3MgdG8g UjEgYW5kIFIyIChvciBldmVuIGhhZCANCnVwbGlua3MgdG8gUjEsIFIyLCBhbmQgUjMsIGJ1dCBp dHMgbGluayB0byBSMyBmYWlscyksIHRoZW4gaWYgSDEgYW5kIEgyIA0KdXNlIHRoZSBzYW1lIG5p Y2tuYW1lLCBzYXkgUDEsIHRoZW4gdHJhZmZpYyBmb3IgSDIncyBNQUMgYWRkcmVzc2VzIG1pZ2h0 IA0KZ2V0IHNlbnQgdG8gUjMgKHNpbmNlIFIzIGhhcyB0byBjbGFpbSB0byBiZSBjb25uZWN0ZWQg dG8gUDEgYmVjYXVzZSBpdCBpcywgDQpmb3IgSDEpLiAgQnV0IGl0IGlzIG5vIGxvbmdlciBhdHRh Y2hlZCB0byBIMiBiZWNhdXNlIEgyJ3MgdXBsaW5rIHRvIFIzIA0KZmFpbGVkLg0KDQpUaGUgc2Fm ZXN0IHRoaW5nIHdvdWxkIGJlIGZvciBldmVyeSBoeXBlcnZpc29yIHRvIGhhdmUgYSBuaWNrbmFt ZS4NCg0KU28sIGhvdyBtYW55IGh5cGVydmlzb3JzIGFyZSB0aGVyZSBsaWtlbHkgdG8gYmU/ICBI b3cgdXN1YWwgd291bGQgaXQgYmUgDQpmb3IgYWxsIG9mIHRoZW0gdG8gYXR0YWNoIHRvIHRoZSBz YW1lIHNldCBvZiB1cGxpbmtzLCBzbyB0aGF0IHdlIGNhbiB1c2UgDQp0aGUgc2FtZSBwc2V1b2Ru b2RlIG5pY2tuYW1lPyAgRG8gd2UgY2FyZSBhYm91dCB0aGUgY2FzZSBvZiBvbmUgb2YgYSANCmh5 cGVydmlzb3IncyB1cGxpbmtzIGZhaWxpbmcsIGluIHdoaWNoIGNhc2UsIHdvdWxkIHRoZSBSQnJp ZGdlcyBrbm93PyAgSWYgDQpSMyAodGhlIG9uZSB0byB3aGljaCB0aGUgdXBsaW5rIGZhaWxlZCkg a25vdz8gIFdvdWxkIFIxIGFuZCBSMiBrbm93PyAgRXZlbiANCmlmIFIzIGtuZXcsIGhvdyBjb3Vs ZCBpdCBhbGVydCBSMSBhbmQgUjIgdG8gbm93IHVzZSBhIGRpZmZlcmVudCBwc2V1ZG9ub2RlIA0K bmlja25hbWUgZm9yIEgyPyAgV291bGQgaXQgYmUgb2J2aW91cyB0byB0aGVtIHdoaWNoIG9mIHRo ZSBoeXBlcnZpc29ycyANCnRoYXQgaGF2ZSB1cGxpbmtzIHRvIFIxLCBSMiwgYW5kIFIzIHRoZXkg YXJlIHJlZmVycmluZyB0bz8NCg0KQWxsIG9mIHRoaXMgbXVzdCBiZSBjb25maWd1cmVkLCBJIGFz c3VtZSwgYW5kIGlmIHRoZSBjb25maWd1cmF0aW9uIGlzIA0Kd3JvbmcsIHRoZW4gd2hvIGtub3dz IHdoYXQgaGFwcGVucy4ucHJlc3VtYWJseSB0aGF0IHRyYWZmaWMgbWF5IG9yIG1heSBub3QgDQpn ZXQgZGVsaXZlcmVkIHRvIGEgaHlwZXJ2aXNvci4gIEFuZCBldmVuIGlmIGNvbmZpZ3VyZWQgcHJv cGVybHksIHdoYXQgDQpoYXBwZW5zIHdoZW4gdXBsaW5rcyBmYWlsPyAgQWdhaW4sIHByZXN1bWFi bHksIHRyYWZmaWMgbWF5IG9yIG1heSBub3QgZ2V0IA0KZGVsaXZlcmVkIHRvIHRoZSBoeXBlcnZp c29yIHdob3NlIHVwbGluayBmYWlscy4NCg0KLS0tLS0tLS0tLS0tLQ0KQXMgZm9yIFZMQU5zLi4u dGhhdCBhY3R1YWxseSBpcyBub3QgYSBwcm9ibGVtIGhlcmUsIHNpbmNlIHdlJ3JlIG5vdCB1c2lu ZyANCkFGcy4gIFRoZSBoeXBlcnZpc29yIGRldGVybWluZXMgd2hpY2ggdXBsaW5rIHRvIHNlbmQg c29tZXRoaW5nIHRvLiAgQW5kIA0Kd2hpY2ggdHJlZSBpcyBiZWluZyB1c2VkIGZvciBkaXN0cmli dXRpb24gZGV0ZXJtaW5lcyB3aGljaCBvZiBSMSwgUjIsIG9yIA0KUjMgd2lsbCBkZWNhcHN1bGF0 ZSB0aGUgcGFja2V0Lg0KDQpTbyB0aGUgbWFpbiBzb3J0IG9mIGNvbmZpZ3VyYXRpb24gdGhhdCBJ IGNhbiB0aGluayBvZiwgb2ZmIHRoZSB0b3Agb2YgbXkgDQpoZWFkLCBpcyB3aGljaCBwc2V1ZG9u b2RlcyBnbyB3aXRoIHdoaWNoIGh5cGVydmlzb3JzLiAgQW5kIEkgZG8gdGhpbmsgDQpjb25maWd1 cmF0aW9uIGlzIHNjYXJ5LCBlc3BlY2lhbGx5IGlmIHRoZXJlJ3Mgbm8gInNhbml0eSBjaGVjayIg d2hlcmVieSANCnRoZSBSQnMgY2FuIGNvbXBhcmUgbm90ZXMuICBJIGRvbid0IGtub3cgaG93IFIx IGNhbiBrbm93IHRoYXQgYSBwYXJ0aWN1bGFyIA0KcG9ydCBpcyB0byAiSDEiIHNvIHRoYXQgaXQg Y2FuIGluZm9ybSBSMiAodmlhIExTUHM/KSB0aGF0IFIxIGlzIGF0dGFjaGVkIA0KdG8gSDEsIGFu ZCBSMiBjYW4gbm90aWNlIHRoYXQgaXQsIGluZGVlZCwgaXMgYWxzbyBhdHRhY2hlZCB0byBIMS4N Cg0KLS0tLS0tLS0NCkFuZCBwYXJ0IG9mIHRoZSBkZXNjcmlwdGlvbiBvZiB0aGUgcHJvYmxlbSB3 b3VsZCBiZSBhbnN3ZXJpbmcgcXVlc3Rpb25zIA0KbGlrZSBob3cgbWFueSB1cGxpbmtzIHdvdWxk IG5lZWQgdG8gYmUgc3VwcG9ydGVkLiAgVHdvIGF0IG1vc3Q/ICAzMD8gIElmIGEgDQpsb3QsIHRo ZW4gc29sdXRpb25zIHRoYXQgcmVxdWlyZSBhIHRyZWUgZm9yIGV2ZXJ5IHVwbGluayB3b3VsZCBi ZSANCnByb2JsZW1hdGljIGlmIGltcGxlbWVudGF0aW9ucyBkb24ndCB3YW50IHRvIHN1cHBvcnQg dGhhdCBtYW55IHRyZWVzLiAgT3IgDQppcyBpdCBPSyB0byByZXF1aXJlIGxvdHMgb2YgdHJlZXM/ DQoNClNvIEkgdGhpbmsgdGhlcmUgYXJlIGxvdHMgb2YgdGhpbmdzIHRoYXQgc2hvdWxkIGJlIHdy aXR0ZW4gZG93biwgYXMgcGFydCANCm9mIGRlc2NyaWJpbmcgdGhlIHByb2JsZW0uDQoNCg0KDQpS YWRpYQ0KDQoNCg0KDQoNCk9uIFRodSwgRGVjIDEzLCAyMDEyIGF0IDQ6MDMgQU0sIDx6aGFpLmhv bmdqdW5AenRlLmNvbS5jbj4gd3JvdGU6DQoNCkhpIFJhZGlhIA0KDQo+IFRoaXMgY2FzZSBpcyBz Y2FyeSBiZWNhdXNlIHRoZSBSQnJpZGdlcyBvbiB0aGUgdXBsaW5rIGNhbm5vdCBzZWUgSGVsbG9z IA0KZnJvbSBlYWNoIG90aGVyLCANCj4gc28gaWYgbWlzY29uZmlndXJlZCwgYXQgdGhlIHZlcnkg bGVhc3QgSSBjb3VsZCBpbWFnaW5lIG11bHRpcGxlIFJCcmlkZ2VzIA0KZGVjYXBzdWxhdGluZyAN Cj4gbXVsdGljYXN0IGZyb20gdGhlIGNhbXB1cyB0byB0aGUgaHlwZXJ2aXNvci4gDQoNCj4gQW55 d2F5Li4uaG93IG1hbnkgdXBsaW5rcyBkbyB3ZSBuZWVkIHRvIHN1cHBvcnQ/ICBEbyB3ZSBjYXJl IGFib3V0IA0KcHJvYmxlbXMgZHVlIHRvIG1pc2NvbmZpZ3VyYXRpb24/IA0KDQpJIGRvbid0IGtu b3cgd2hhdCB0aGUgbWlzY29uZmlndXJhdGlvbiByZWZlcnMgdG8uIElzIGl0IHRoZSBzZXQgb2Yg VkxBTnMgDQpmb3Igd2hpY2ggYW4gUmJyaWRnZSBhY3RzIGFzIEFGPyANCg0KDQo+IEFyZSB0aGVy ZSBjYXNlcyB3aGVyZSB0aGVyZSBhcmUgbG90cyBvZiBoeXBlcnZpc29ycywgd2hlcmUgdGhleSBh dHRhY2ggDQp0byBkaWZmZXJlbnQgc3Vic2V0cyBvZiBlZGdlIFJCcz8gDQo+IEluIHRoYXQgY2Fz ZSwgd2UgbWlnaHQgZWF0IHVwIGEgbG90IG9mIG5pY2tuYW1lcywgc2luY2UgaWYgb25lIA0KaHlw ZXJ2aXNvciBpcyBhdHRhY2hlZCB0byB7UjEsIFIyfSwgDQo+IGFuZCBhbm90aGVyIGlzIGF0dGFj aGVkIHRvIHtSMSwgUjIsIFIzfSwgdGhleSBjYW5ub3QgdXNlIHRoZSBzYW1lIA0KcHNldWRvbm9k ZSBuaWNrbmFtZS4gDQoNCkkgZG9uJ3Qga25vdyB3aHkgdGhlIHR3byBzZXRzIG9mIFJCcmlkZ2Vz IGNhbiBub3QgdXNlIHRoZSBzYW1lIA0KcHNldWRvLW5pY2tuYW1lLiBJZiB0aGUgbGVhcm5lZCBN QUMgYWRkcmVzc2VzIA0KY2FuIGJlIHNoYXJlZCBhbW9uZyBtZW1iZXIgUmJyaWRnZXMgb2YgYW4g UkJ2IGFuZCBUUklMTCBkYXRhIGZyYW1lcyBjYW4gYmUgDQp0dW5uZWxlZCB0byBhbm90aGVyIG1l bWJlciBSYnJpZGdlIA0KdGhhdCBjYW4gZWdyZXNzIHRoZSBmcmFtZSwgSSB0aGluayB0aGV5IGNh biB1c2UgdGhlIHNhbWUgcHNldWRvLW5pY2tuYW1lLiANCg0KSWYgSSBhbSB3cm9uZywgcGxlYXNl IGNvcnJlY3QgbWUuDQoNCg0KQmVzdCBSZWdhcmRzLA0KWmhhaSBIb25nanVuDQoiIiIiIiIiIiIi IiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIi IiIiDQpQcm90b2NvbCBEZXZlbG9wbWVudCBEZXB0LlZJLCBDZW50cmFsIFImRCBJbnN0aXR1dGUs IFpURSBDb3Jwb3JhdGlvbg0KTm8uIDY4LCBaaWppbmdodWEgUm9hZCwgWXVodWF0YWkgRGlzdHJp Y3QsIE5hbmppbmcsIFAuUi5DaGluYSwgMjEwMDEyDQoNClpoYWkgSG9uZ2p1bg0KDQpUZWw6ICs4 Ni0yNS01Mjg3NzM0NQ0KRW1haWw6IHpoYWkuaG9uZ2p1bkB6dGUuY29tLmNuDQoiIiIiIiIiIiIi IiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIi IiIiIg0KDQoNCg0KDQoNClJhZGlhIFBlcmxtYW4gPHJhZGlhcGVybG1hbkBnbWFpbC5jb20+IA0K t6K8/sjLOiAgdHJpbGwtYm91bmNlc0BpZXRmLm9yZyANCjIwMTItMTItMTMgMTU6MTMgDQoNCg0K ytW8/sjLDQpNaW5ndWkgWmhhbmcgPHpoYW5nbWluZ3VpQGh1YXdlaS5jb20+IA0Ks63LzQ0KVGhv bWFzIE5hcnRlbiA8bmFydGVuQHVzLmlibS5jb20+LCBTYW0gQWxkcmluIDxhbGRyaW4uaWV0ZkBn bWFpbC5jb20+LCANCiJUaXNzYSBTZW5ldmlyYXRobmUgXCh0c2VuZXZpclwpIiA8dHNlbmV2aXJA Y2lzY28uY29tPiwgInRyaWxsQGlldGYub3JnIiA8DQp0cmlsbEBpZXRmLm9yZz4gDQrW98ziDQpS ZTogW3RyaWxsXSBUaG91Z2h0cyBvbiBhY3RpdmUtYWN0aXZlIGVkZ2UNCg0KDQoNCg0KDQoNCg0K DQpJIHRoaW5rIGl0IHdvdWxkIGJlIGdvb2QgdG8gaGF2ZSBhIGRvY3VtZW50IHRoYXQgZXhwbGFp bnMgdGhlIHByb2JsZW0uLi5JIA0KY2VydGFpbmx5IGRvbid0IGJlbGlldmUgSSBrbm93IGFsbCB0 aGUgY2FzZXMgdGhhdCBuZWVkIHRvIGJlIHNvbHZlZC4gIEkgDQp0aGluayBJIHVuZGVyc3RhbmQg dGhlIGh5cGVydmlzb3IgY2FzZS4uLndoZXJlIHRoZSBoeXBlcnZpc29yIGRlY2lkZXMgDQp3aGlj aCB1cGxpbmsgdG8gc2VuZCB0aGluZ3MgdG8sIGFuZCBuZXZlciBmb3J3YXJkcyBiZXR3ZWVuIHRo ZSB1cC1saW5rcy4gDQoNClRoaXMgY2FzZSBpcyBzY2FyeSBiZWNhdXNlIHRoZSBSQnJpZGdlcyBv biB0aGUgdXBsaW5rIGNhbm5vdCBzZWUgSGVsbG9zIA0KZnJvbSBlYWNoIG90aGVyLCBzbyBpZiBt aXNjb25maWd1cmVkLCBhdCB0aGUgdmVyeSBsZWFzdCBJIGNvdWxkIGltYWdpbmUgDQptdWx0aXBs ZSBSQnJpZGdlcyBkZWNhcHN1bGF0aW5nIG11bHRpY2FzdCBmcm9tIHRoZSBjYW1wdXMgdG8gdGhl IA0KaHlwZXJ2aXNvci4gDQoNCkFueXdheS4uLmhvdyBtYW55IHVwbGlua3MgZG8gd2UgbmVlZCB0 byBzdXBwb3J0PyAgRG8gd2UgY2FyZSBhYm91dCANCnByb2JsZW1zIGR1ZSB0byBtaXNjb25maWd1 cmF0aW9uPyANCg0KSW4gY2FzZXMgbGlrZSB0aGlzLCBpcyBpdCBjb21tb24gdG8gYWxzbyBoYXZl IHB0LXRvLXB0IGxpbmtzIGJldHdlZW4gYWxsIA0KdGhlIFJCcyBhdHRhY2hpbmcgdG8gdGhlIGh5 cGVydmlzb3I/ICBJZiBzbywgdGhlbiBpdCBzZWVtcyBsaWtlIGl0IHdvdWxkIA0KYmUgcG9zc2li bGUgZm9yIHRoZW0gdG8gY29vcmRpbmF0ZSB0byBhdCBsZWFzdCBkZXRlY3QgbWlzY29uZmlndXJh dGlvbiwgDQphbmQgcG9zc2libHkgcGxheSBnYW1lcyB3aXRoIGZvcndhcmRpbmcgbWVzc2FnZXMg dG8gZWFjaCBvdGhlciAoZS5nLiwgaWYgDQpvbmUgb2YgdGhlbSBpcyBub3QgYXR0YWNoZWQgdG8g YSB0cmVlIGFuZCBuZWVkcyB0byBlbmNhcHN1bGF0ZSBhIA0KbXVsdGlkZXN0aW5hdGlvbiBmcmFt ZSkuIA0KDQpIb3cgbWFueSB0cmVlcyBkb2VzIHRoZSBjYW1wdXMgbmVlZD8gDQoNCkFyZSB0aGVy ZSBjYXNlcyB3aGVyZSB0aGVyZSBhcmUgbG90cyBvZiBoeXBlcnZpc29ycywgd2hlcmUgdGhleSBh dHRhY2ggdG8gDQpkaWZmZXJlbnQgc3Vic2V0cyBvZiBlZGdlIFJCcz8gIEluIHRoYXQgY2FzZSwg d2UgbWlnaHQgZWF0IHVwIGEgbG90IG9mIA0Kbmlja25hbWVzLCBzaW5jZSBpZiBvbmUgaHlwZXJ2 aXNvciBpcyBhdHRhY2hlZCB0byB7UjEsIFIyfSwgYW5kIGFub3RoZXIgaXMgDQphdHRhY2hlZCB0 byB7UjEsIFIyLCBSM30sIHRoZXkgY2Fubm90IHVzZSB0aGUgc2FtZSBwc2V1ZG9ub2RlIG5pY2tu YW1lLiANCg0KQXJlIHRoZXJlIGNhc2VzIG90aGVyIHRoYW4gaHlwZXJ2aXNvcnM/ICBJIHRoaW5r IHRoZXJlIGFyZSBjYXNlcyBvZiANCmJyaWRnZXMgdGhhdCBoYXZlIHRoaXMgYmVoYXZpb3IgKGEg cG9ydCB3aXRoIGEgYnVuY2ggb2YgZW5kbm9kZXMsIGFuZCANCnNldmVyYWwgdXAtbGlua3MsIHdo ZXJlIHRoZSBicmlkZ2UgZG9lcyBub3QgZm9yd2FyZCBiZXR3ZWVuIHRoZSB1cC1saW5rcy4gIA0K DQoNCklmIHRoaXMgaGFzIGJlZW4gd3JpdHRlbiBkb3duIGFueXdoZXJlLCBjYW4gYW55b25lIHBv aW50IG1lIHRvIGl0PyAgSWYgDQpub3QsIGl0IHNlZW1zIHJlYWxseSBwcnVkZW50IHRvIGFuc3dl ciB0aGVzZSAoYW5kIEknbSBzdXJlIG90aGVyKSANCnF1ZXN0aW9ucyBiZWZvcmUgYXJndWluZyBh Ym91dCBzcGVjaWZpYyBzb2x1dGlvbnMuIA0KDQpSYWRpYSANCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnRyaWxsIG1haWxpbmcgbGlzdA0KdHJpbGxA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJpbGwNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnRyaWxsIG1h aWxpbmcgbGlzdA0KdHJpbGxAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdHJpbGwNCg0KDQo= --=_alternative 000DE9C848257AD4_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoZXJlIGlzIG9ubHkgb25lIFJC cmlkZ2UodGhhdCBpcyBBRikNCnRvIGRvIHRoZSBUUklMTCBlbmNhcHVzbGF0aW9uIGluIHRoZSBz aGFyZWQgTEFOIGxpbmsgc2NlbmFyaW8uU28gd2UgY2FuDQppbnRyb2R1Y2UgdGhlIHBzZXVkb25v ZGUgbmlja25hbWUgdG8gaWRlbnR5IHRoZSBzaGFyZWQgbGluaywgYW5kIGF2b2lkDQp0aGUgcG90 ZW50aWFsIGRhdGEgbG9zcyB3aGVuIEFGIGNoYW5nZWQuIFdoaWxlIGl0IGlzIGRpZmZlcmVudCBm b3IgdGhlDQphY3RpdmUtYWN0aXZlIGVkZ2Ugc2NlbmFyaW86IGFsbCB0aGUgUkJyaWRnZXMgaW4g dGhlIExBRy1ncm91cCBzaG91bGQgZG8NCnRoZSBUUklMTCBlbmNhcHN1bGF0aW9uLCBhbmQgdGhl IFJCcmlkZ2UgPC9mb250Pjxmb250IHNpemU9Mj5jYW5ub3Qgc2VlDQpIZWxsb3MgZnJvbSBlYWNo IG90aGVyPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4sIHRoZXJlIGlzDQpu byBBRiBpbiB0aGlzIGNhc2UgYWN0dWFsbHkuIFNvIHBzZXVkb25vZGUgbmlja25hbWUgaXMgbm90 IGZpdCBmb3IgYWN0aXZlLWFjdGl2ZQ0KZWRnZS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPldlIGNvdWxkIHVzZSB0aGUgY29udHJvbCBwcm90b2NvbChm b3INCmV4YW1wbGUsIEVTQURJICl0byBsZWFybiB0aGUgTUFDIGFuZCBuaWNrbmFtZSwgYW5kIGF2 b2lkIHRoZSBNQUMgZmxpcCBieQ0KYWRkaW5nIGEgbmV3IElEKGxpbmstSUQpLiBJZiB0aGUgcmVt b3RlIHJlY2VpdmVzIHR3byByZWNvcmRzIHdpdGggdGhlIHNhbWUNCkxpbmstSUQsaXQgc2hvdWxk IHRoaW5rIGJvdGggb2YgdGhlbSBhcmUgT2suIDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7UjEgYW5kIFIyIHRlbGwgUjggdGhhdCBIMSBpcyBt dWx0aS1ob21pbmcNCnRvIHRoZSB0cmlsbCBjYW1wdXMsIHRoZXkgdXNlIHRoZSBzYW1lIExpbmst SUQgdG8gaWRlbnRpZnkgdGhlIExBRy1ncm91cC4NCldoZW4gUjggcmVjZWl2ZXMgdGhlIGluZm9y bWF0aW9uLCBpdCBrZWVwcyB0d28gcmVjb3JkcyBmb3IgSDEsIG9uZSBpcyBSMSwNCmFuZCB0aGUg b3RoZXIgaXMgUjIuIFRoZSBiYWNrIGRhdGEgZnJhbWUgY291bGQgY2hvaWNlIGVpdGhlciBSMSBv ciBSMiBhcw0KdGhlIGVncmVzcyBuaWNrbmFtZS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPklmIHRoZSBsaW5rIGJldHdlZW4gSDEgYW5kIFIyIGZhaWxz LA0KdGhlIHJlY29yZCBSMiBpcyBjbGVhci48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPklmIHRoZXJlIGlzIGFub3RoZXIgbGluayBmb3IgSDEsIHNheQ0K UjMsIGFuZCBSMyB1c2VzIHRoZSBzYW1lIGxpbmstaWQsIHNvIFI4IGtlZXBzIGFub3RoZXIgcmVj b3JkIGZvciBIMS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPkJlc3QgcmVnYXJkcy48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUg d2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM2JT48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+PGI+UmFkaWEgUGVybG1hbiAmbHQ7cmFkaWFwZXJsbWFuQGdtYWls LmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PreivP7IyzogJm5ic3A7dHJpbGwtYm91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxwPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEyLTEyLTE0IDAyOjEwPC9mb250Pg0KPHRkIHdpZHRo PTYzJT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFs aWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9k aXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPnpoYWkuaG9uZ2p1bkB6dGUu Y29tLmNuPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5UaG9tYXMgTmFydGVuICZsdDtuYXJ0ZW5AdXMuaWJt LmNvbSZndDssDQp0cmlsbC1ib3VuY2VzQGlldGYub3JnLCBTYW0gQWxkcmluICZsdDthbGRyaW4u aWV0ZkBnbWFpbC5jb20mZ3Q7LCBNaW5ndWkNClpoYW5nICZsdDt6aGFuZ21pbmd1aUBodWF3ZWku Y29tJmd0OywgJnF1b3Q7dHJpbGxAaWV0Zi5vcmcmcXVvdDsgJmx0O3RyaWxsQGlldGYub3JnJmd0 OywNCiZxdW90O1Rpc3NhIFNlbmV2aXJhdGhuZSBcKHRzZW5ldmlyXCkmcXVvdDsgJmx0O3RzZW5l dmlyQGNpc2NvLmNvbSZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxp Z249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+ DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBbdHJpbGxdIFRob3VnaHRz IG9uIGFjdGl2ZS1hY3RpdmUNCmVkZ2U8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0 ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxi cj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+QW5zd2VyaW5nIFpoYWkgSG9u Z2p1bidzIHF1ZXN0aW9uczo8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPldoeSBpdCBpcyBuZWNlc3NhcnkgdG8gaGF2ZSBhIGRpZmZlcmVudA0KcHNldW9u b2RlIG5pY2tuYW1lIGlmIHRoZSB1cGxsbmsgaXMgdG8gZGlmZmVyZW50IHNldHMgb2YgUkJyaWRn ZXM6PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5JZiBo eXBlcnZpc29yIEgxIGhhcyB1cGxpbmtzIHRvIFIxLA0KUjIsIGFuZCBSMywgYW5kIHVzZXMgcHNl dWRvbm9kZSBuaWNrbmFtZSBQMSwgYW5kIGh5cGVydmlzb3IgSDIgaGFzIHVwbGlua3MNCnRvIFIx IGFuZCBSMiAob3IgZXZlbiBoYWQgdXBsaW5rcyB0byBSMSwgUjIsIGFuZCBSMywgYnV0IGl0cyBs aW5rIHRvIFIzDQpmYWlscyksIHRoZW4gaWYgSDEgYW5kIEgyIHVzZSB0aGUgc2FtZSBuaWNrbmFt ZSwgc2F5IFAxLCB0aGVuIHRyYWZmaWMgZm9yDQpIMidzIE1BQyBhZGRyZXNzZXMgbWlnaHQgZ2V0 IHNlbnQgdG8gUjMgKHNpbmNlIFIzIGhhcyB0byBjbGFpbSB0byBiZSBjb25uZWN0ZWQNCnRvIFAx IGJlY2F1c2UgaXQgaXMsIGZvciBIMSkuICZuYnNwO0J1dCBpdCBpcyBubyBsb25nZXIgYXR0YWNo ZWQgdG8gSDINCmJlY2F1c2UgSDIncyB1cGxpbmsgdG8gUjMgZmFpbGVkLjwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+VGhlIHNhZmVzdCB0aGluZyB3b3Vs ZCBiZSBmb3IgZXZlcnkNCmh5cGVydmlzb3IgdG8gaGF2ZSBhIG5pY2tuYW1lLjwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+U28sIGhvdyBtYW55IGh5cGVy dmlzb3JzIGFyZSB0aGVyZSBsaWtlbHkNCnRvIGJlPyAmbmJzcDtIb3cgdXN1YWwgd291bGQgaXQg YmUgZm9yIGFsbCBvZiB0aGVtIHRvIGF0dGFjaCB0byB0aGUgc2FtZQ0Kc2V0IG9mIHVwbGlua3Ms IHNvIHRoYXQgd2UgY2FuIHVzZSB0aGUgc2FtZSBwc2V1b2Rub2RlIG5pY2tuYW1lPyAmbmJzcDtE bw0Kd2UgY2FyZSBhYm91dCB0aGUgY2FzZSBvZiBvbmUgb2YgYSBoeXBlcnZpc29yJ3MgdXBsaW5r cyBmYWlsaW5nLCBpbiB3aGljaA0KY2FzZSwgd291bGQgdGhlIFJCcmlkZ2VzIGtub3c/ICZuYnNw O0lmIFIzICh0aGUgb25lIHRvIHdoaWNoIHRoZSB1cGxpbmsNCmZhaWxlZCkga25vdz8gJm5ic3A7 V291bGQgUjEgYW5kIFIyIGtub3c/ICZuYnNwO0V2ZW4gaWYgUjMga25ldywgaG93IGNvdWxkDQpp dCBhbGVydCBSMSBhbmQgUjIgdG8gbm93IHVzZSBhIGRpZmZlcmVudCBwc2V1ZG9ub2RlIG5pY2tu YW1lIGZvciBIMj8gJm5ic3A7V291bGQNCml0IGJlIG9idmlvdXMgdG8gdGhlbSB3aGljaCBvZiB0 aGUgaHlwZXJ2aXNvcnMgdGhhdCBoYXZlIHVwbGlua3MgdG8gUjEsDQpSMiwgYW5kIFIzIHRoZXkg YXJlIHJlZmVycmluZyB0bz88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPkFsbCBvZiB0aGlzIG11c3QgYmUgY29uZmlndXJlZCwgSSBhc3N1bWUsDQphbmQg aWYgdGhlIGNvbmZpZ3VyYXRpb24gaXMgd3JvbmcsIHRoZW4gd2hvIGtub3dzIHdoYXQgaGFwcGVu cy4ucHJlc3VtYWJseQ0KdGhhdCB0cmFmZmljIG1heSBvciBtYXkgbm90IGdldCBkZWxpdmVyZWQg dG8gYSBoeXBlcnZpc29yLiAmbmJzcDtBbmQgZXZlbg0KaWYgY29uZmlndXJlZCBwcm9wZXJseSwg d2hhdCBoYXBwZW5zIHdoZW4gdXBsaW5rcyBmYWlsPyAmbmJzcDtBZ2FpbiwgcHJlc3VtYWJseSwN CnRyYWZmaWMgbWF5IG9yIG1heSBub3QgZ2V0IGRlbGl2ZXJlZCB0byB0aGUgaHlwZXJ2aXNvciB3 aG9zZSB1cGxpbmsgZmFpbHMuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJz YW5zLXNlcmlmIj4tLS0tLS0tLS0tLS0tPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJz YW5zLXNlcmlmIj5BcyBmb3IgVkxBTnMuLi50aGF0IGFjdHVhbGx5IGlzIG5vdA0KYSBwcm9ibGVt IGhlcmUsIHNpbmNlIHdlJ3JlIG5vdCB1c2luZyBBRnMuICZuYnNwO1RoZSBoeXBlcnZpc29yIGRl dGVybWluZXMNCndoaWNoIHVwbGluayB0byBzZW5kIHNvbWV0aGluZyB0by4gJm5ic3A7QW5kIHdo aWNoIHRyZWUgaXMgYmVpbmcgdXNlZCBmb3INCmRpc3RyaWJ1dGlvbiBkZXRlcm1pbmVzIHdoaWNo IG9mIFIxLCBSMiwgb3IgUjMgd2lsbCBkZWNhcHN1bGF0ZSB0aGUgcGFja2V0LjwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+U28gdGhlIG1haW4gc29ydCBv ZiBjb25maWd1cmF0aW9uIHRoYXQNCkkgY2FuIHRoaW5rIG9mLCBvZmYgdGhlIHRvcCBvZiBteSBo ZWFkLCBpcyB3aGljaCBwc2V1ZG9ub2RlcyBnbyB3aXRoIHdoaWNoDQpoeXBlcnZpc29ycy4gJm5i c3A7QW5kIEkgZG8gdGhpbmsgY29uZmlndXJhdGlvbiBpcyBzY2FyeSwgZXNwZWNpYWxseSBpZg0K dGhlcmUncyBubyAmcXVvdDtzYW5pdHkgY2hlY2smcXVvdDsgd2hlcmVieSB0aGUgUkJzIGNhbiBj b21wYXJlIG5vdGVzLg0KJm5ic3A7SSBkb24ndCBrbm93IGhvdyBSMSBjYW4ga25vdyB0aGF0IGEg cGFydGljdWxhciBwb3J0IGlzIHRvICZxdW90O0gxJnF1b3Q7DQpzbyB0aGF0IGl0IGNhbiBpbmZv cm0gUjIgKHZpYSBMU1BzPykgdGhhdCBSMSBpcyBhdHRhY2hlZCB0byBIMSwgYW5kIFIyDQpjYW4g bm90aWNlIHRoYXQgaXQsIGluZGVlZCwgaXMgYWxzbyBhdHRhY2hlZCB0byBIMS48L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPi0tLS0tLS0tPC9mb250Pg0K PGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5BbmQgcGFydCBvZiB0aGUgZGVzY3Jp cHRpb24gb2YgdGhlIHByb2JsZW0NCndvdWxkIGJlIGFuc3dlcmluZyBxdWVzdGlvbnMgbGlrZSBo b3cgbWFueSB1cGxpbmtzIHdvdWxkIG5lZWQgdG8gYmUgc3VwcG9ydGVkLg0KJm5ic3A7VHdvIGF0 IG1vc3Q/ICZuYnNwOzMwPyAmbmJzcDtJZiBhIGxvdCwgdGhlbiBzb2x1dGlvbnMgdGhhdCByZXF1 aXJlDQphIHRyZWUgZm9yIGV2ZXJ5IHVwbGluayB3b3VsZCBiZSBwcm9ibGVtYXRpYyBpZiBpbXBs ZW1lbnRhdGlvbnMgZG9uJ3Qgd2FudA0KdG8gc3VwcG9ydCB0aGF0IG1hbnkgdHJlZXMuICZuYnNw O09yIGlzIGl0IE9LIHRvIHJlcXVpcmUgbG90cyBvZiB0cmVlcz88L2ZvbnQ+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPlNvIEkgdGhpbmsgdGhlcmUgYXJlIGxvdHMg b2YgdGhpbmdzDQp0aGF0IHNob3VsZCBiZSB3cml0dGVuIGRvd24sIGFzIHBhcnQgb2YgZGVzY3Jp YmluZyB0aGUgcHJvYmxlbS48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0zIGZhY2U9InNhbnMtc2VyaWYiPlJhZGlhPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJy Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5PbiBUaHUsIERlYyAx MywgMjAxMiBhdCA0OjAzIEFNLCAmbHQ7PC9mb250PjxhIGhyZWY9bWFpbHRvOnpoYWkuaG9uZ2p1 bkB6dGUuY29tLmNuIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0i c2Fucy1zZXJpZiI+PHU+emhhaS5ob25nanVuQHp0ZS5jb20uY248L3U+PC9mb250PjwvYT48Zm9u dCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0Ow0Kd3JvdGU6PC9mb250Pg0KPGJyPjxmb250 IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpIaSBSYWRpYSA8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCiZndDsgVGhpcyBjYXNlIGlzIHNjYXJ5 IGJlY2F1c2UgdGhlIFJCcmlkZ2VzIG9uIHRoZSB1cGxpbmsgY2Fubm90IHNlZSBIZWxsb3MNCmZy b20gZWFjaCBvdGhlciwgPGJyPg0KJmd0OyBzbyBpZiBtaXNjb25maWd1cmVkLCBhdCB0aGUgdmVy eSBsZWFzdCBJIGNvdWxkIGltYWdpbmUgbXVsdGlwbGUgUkJyaWRnZXMNCmRlY2Fwc3VsYXRpbmcg PGJyPg0KJmd0OyBtdWx0aWNhc3QgZnJvbSB0aGUgY2FtcHVzIHRvIHRoZSBoeXBlcnZpc29yLiA8 YnI+DQo8YnI+DQomZ3Q7IEFueXdheS4uLmhvdyBtYW55IHVwbGlua3MgZG8gd2UgbmVlZCB0byBz dXBwb3J0PyAmbmJzcDtEbyB3ZSBjYXJlDQphYm91dCBwcm9ibGVtcyBkdWUgdG8gbWlzY29uZmln dXJhdGlvbj8gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+ DQpJIGRvbid0IGtub3cgd2hhdCB0aGUgbWlzY29uZmlndXJhdGlvbiByZWZlcnMgdG8uIElzIGl0 IHRoZSBzZXQgb2YgVkxBTnMNCmZvciB3aGljaCBhbiBSYnJpZGdlIGFjdHMgYXMgQUY/IDwvZm9u dD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KJmd0OyBB cmUgdGhlcmUgY2FzZXMgd2hlcmUgdGhlcmUgYXJlIGxvdHMgb2YgaHlwZXJ2aXNvcnMsIHdoZXJl IHRoZXkgYXR0YWNoDQp0byBkaWZmZXJlbnQgc3Vic2V0cyBvZiBlZGdlIFJCcz8gJm5ic3A7IDxi cj4NCiZndDsgSW4gdGhhdCBjYXNlLCB3ZSBtaWdodCBlYXQgdXAgYSBsb3Qgb2Ygbmlja25hbWVz LCBzaW5jZSBpZiBvbmUgaHlwZXJ2aXNvcg0KaXMgYXR0YWNoZWQgdG8ge1IxLCBSMn0sIDxicj4N CiZndDsgYW5kIGFub3RoZXIgaXMgYXR0YWNoZWQgdG8ge1IxLCBSMiwgUjN9LCB0aGV5IGNhbm5v dCB1c2UgdGhlIHNhbWUNCnBzZXVkb25vZGUgbmlja25hbWUuIDxicj4NCjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+SSBkb24ndCBrbm93IHdoeSB0aGUgdHdvIHNl dHMgb2YgUkJyaWRnZXMNCmNhbiBub3QgdXNlIHRoZSBzYW1lIHBzZXVkby1uaWNrbmFtZS4gSWYg dGhlIGxlYXJuZWQgTUFDIGFkZHJlc3NlcyA8YnI+DQpjYW4gYmUgc2hhcmVkIGFtb25nIG1lbWJl ciBSYnJpZGdlcyBvZiBhbiBSQnYgYW5kIFRSSUxMIGRhdGEgZnJhbWVzIGNhbg0KYmUgdHVubmVs ZWQgdG8gYW5vdGhlciBtZW1iZXIgUmJyaWRnZSA8YnI+DQp0aGF0IGNhbiBlZ3Jlc3MgdGhlIGZy YW1lLCBJIHRoaW5rIHRoZXkgY2FuIHVzZSB0aGUgc2FtZSBwc2V1ZG8tbmlja25hbWUuDQo8YnI+ DQo8YnI+DQpJZiBJIGFtIHdyb25nLCBwbGVhc2UgY29ycmVjdCBtZS48L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjxicj4NCkJlc3QgUmVnYXJkcyw8YnI+ DQpaaGFpIEhvbmdqdW48YnI+DQomcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDs8YnI+DQpQcm90b2NvbCBE ZXZlbG9wbWVudCBEZXB0LlZJLCBDZW50cmFsIFImYW1wO0QgSW5zdGl0dXRlLCBaVEUgQ29ycG9y YXRpb248YnI+DQpOby4gNjgsIFppamluZ2h1YSBSb2FkLCBZdWh1YXRhaSBEaXN0cmljdCwgTmFu amluZywgUC5SLkNoaW5hLCAyMTAwMTI8YnI+DQo8YnI+DQpaaGFpIEhvbmdqdW48YnI+DQo8YnI+ DQpUZWw6IDwvZm9udD48YSBocmVmPSJ0ZWw6JTJCODYtMjUtNTI4NzczNDUiIHRhcmdldD1fYmxh bms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+Kzg2LTI1LTUy ODc3MzQ1PC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4N CkVtYWlsOiA8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86emhhaS5ob25nanVuQHp0ZS5jb20uY24gdGFy Z2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT56 aGFpLmhvbmdqdW5AenRlLmNvbS5jbjwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJz YW5zLXNlcmlmIj48YnI+DQomcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDs8YnI+DQo8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjxicj4NCjwvZm9udD4N CjxwPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0yMiU+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPlJhZGlhIFBlcmxtYW4gJmx0OzwvYj48 L2ZvbnQ+PGEgaHJlZj1tYWlsdG86cmFkaWFwZXJsbWFuQGdtYWlsLmNvbSB0YXJnZXQ9X2JsYW5r Pjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjxiPjx1PnJhZGlhcGVy bG1hbkBnbWFpbC5jb208L3U+PC9iPjwvZm9udD48L2E+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPjxiPiZndDs8L2I+DQo8YnI+DQq3orz+yMs6ICZuYnNwOzwvZm9udD48YSBocmVmPSJt YWlsdG86dHJpbGwtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTEg Y29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT50cmlsbC1ib3VuY2VzQGlldGYub3JnPC91 PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPHA+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTItMTItMTMgMTU6MTM8L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPHRkIHdpZHRoPTc3JT4NCjxi cj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MTIlPg0K PGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9m b250PjwvZGl2Pg0KPHRkIHdpZHRoPTg3JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ TWluZ3VpIFpoYW5nICZsdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86emhhbmdtaW5ndWlAaHVhd2Vp LmNvbSB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2Vy aWYiPjx1PnpoYW5nbWluZ3VpQGh1YXdlaS5jb208L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+Jmd0OzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJp ZiI+DQo8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlRob21hcyBOYXJ0ZW4gJmx0OzwvZm9udD48YSBocmVm PW1haWx0bzpuYXJ0ZW5AdXMuaWJtLmNvbSB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MSBjb2xv cj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1Pm5hcnRlbkB1cy5pYm0uY29tPC91PjwvZm9udD48 L2E+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZndDssDQpTYW0gQWxkcmluICZsdDs8 L2ZvbnQ+PGEgaHJlZj1tYWlsdG86YWxkcmluLmlldGZAZ21haWwuY29tIHRhcmdldD1fYmxhbms+ PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+YWxkcmluLmlldGZA Z21haWwuY29tPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZn dDssDQomcXVvdDtUaXNzYSBTZW5ldmlyYXRobmUgXCh0c2VuZXZpclwpJnF1b3Q7ICZsdDs8L2Zv bnQ+PGEgaHJlZj1tYWlsdG86dHNlbmV2aXJAY2lzY28uY29tIHRhcmdldD1fYmxhbms+PGZvbnQg c2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+dHNlbmV2aXJAY2lzY28uY29t PC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZndDssDQomcXVv dDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86dHJpbGxAaWV0Zi5vcmcgdGFyZ2V0PV9ibGFuaz48Zm9u dCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT50cmlsbEBpZXRmLm9yZzwv dT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDsNCiZsdDs8 L2ZvbnQ+PGEgaHJlZj1tYWlsdG86dHJpbGxAaWV0Zi5vcmcgdGFyZ2V0PV9ibGFuaz48Zm9udCBz aXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT50cmlsbEBpZXRmLm9yZzwvdT48 L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7PC9mb250Pjxmb250 IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRk Pg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwv Zm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFt0cmls bF0gVGhvdWdodHMgb24gYWN0aXZlLWFjdGl2ZQ0KZWRnZTwvZm9udD48L3RhYmxlPg0KPGJyPg0K PGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD00OSU+ DQo8dGQgd2lkdGg9NTAlPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJz YW5zLXNlcmlmIj48YnI+DQpJIHRoaW5rIGl0IHdvdWxkIGJlIGdvb2QgdG8gaGF2ZSBhIGRvY3Vt ZW50IHRoYXQgZXhwbGFpbnMgdGhlIHByb2JsZW0uLi5JDQpjZXJ0YWlubHkgZG9uJ3QgYmVsaWV2 ZSBJIGtub3cgYWxsIHRoZSBjYXNlcyB0aGF0IG5lZWQgdG8gYmUgc29sdmVkLiAmbmJzcDtJDQp0 aGluayBJIHVuZGVyc3RhbmQgdGhlIGh5cGVydmlzb3IgY2FzZS4uLndoZXJlIHRoZSBoeXBlcnZp c29yIGRlY2lkZXMgd2hpY2gNCnVwbGluayB0byBzZW5kIHRoaW5ncyB0bywgYW5kIG5ldmVyIGZv cndhcmRzIGJldHdlZW4gdGhlIHVwLWxpbmtzLiA8YnI+DQo8YnI+DQpUaGlzIGNhc2UgaXMgc2Nh cnkgYmVjYXVzZSB0aGUgUkJyaWRnZXMgb24gdGhlIHVwbGluayBjYW5ub3Qgc2VlIEhlbGxvcw0K ZnJvbSBlYWNoIG90aGVyLCBzbyBpZiBtaXNjb25maWd1cmVkLCBhdCB0aGUgdmVyeSBsZWFzdCBJ IGNvdWxkIGltYWdpbmUNCm11bHRpcGxlIFJCcmlkZ2VzIGRlY2Fwc3VsYXRpbmcgbXVsdGljYXN0 IGZyb20gdGhlIGNhbXB1cyB0byB0aGUgaHlwZXJ2aXNvci4NCjxicj4NCjxicj4NCkFueXdheS4u LmhvdyBtYW55IHVwbGlua3MgZG8gd2UgbmVlZCB0byBzdXBwb3J0PyAmbmJzcDtEbyB3ZSBjYXJl IGFib3V0DQpwcm9ibGVtcyBkdWUgdG8gbWlzY29uZmlndXJhdGlvbj8gPGJyPg0KPGJyPg0KSW4g Y2FzZXMgbGlrZSB0aGlzLCBpcyBpdCBjb21tb24gdG8gYWxzbyBoYXZlIHB0LXRvLXB0IGxpbmtz IGJldHdlZW4gYWxsDQp0aGUgUkJzIGF0dGFjaGluZyB0byB0aGUgaHlwZXJ2aXNvcj8gJm5ic3A7 SWYgc28sIHRoZW4gaXQgc2VlbXMgbGlrZSBpdA0Kd291bGQgYmUgcG9zc2libGUgZm9yIHRoZW0g dG8gY29vcmRpbmF0ZSB0byBhdCBsZWFzdCBkZXRlY3QgbWlzY29uZmlndXJhdGlvbiwNCmFuZCBw b3NzaWJseSBwbGF5IGdhbWVzIHdpdGggZm9yd2FyZGluZyBtZXNzYWdlcyB0byBlYWNoIG90aGVy IChlLmcuLCBpZg0Kb25lIG9mIHRoZW0gaXMgbm90IGF0dGFjaGVkIHRvIGEgdHJlZSBhbmQgbmVl ZHMgdG8gZW5jYXBzdWxhdGUgYSBtdWx0aWRlc3RpbmF0aW9uDQpmcmFtZSkuIDxicj4NCjxicj4N CkhvdyBtYW55IHRyZWVzIGRvZXMgdGhlIGNhbXB1cyBuZWVkPyA8YnI+DQo8YnI+DQpBcmUgdGhl cmUgY2FzZXMgd2hlcmUgdGhlcmUgYXJlIGxvdHMgb2YgaHlwZXJ2aXNvcnMsIHdoZXJlIHRoZXkg YXR0YWNoDQp0byBkaWZmZXJlbnQgc3Vic2V0cyBvZiBlZGdlIFJCcz8gJm5ic3A7SW4gdGhhdCBj YXNlLCB3ZSBtaWdodCBlYXQgdXAgYQ0KbG90IG9mIG5pY2tuYW1lcywgc2luY2UgaWYgb25lIGh5 cGVydmlzb3IgaXMgYXR0YWNoZWQgdG8ge1IxLCBSMn0sIGFuZA0KYW5vdGhlciBpcyBhdHRhY2hl ZCB0byB7UjEsIFIyLCBSM30sIHRoZXkgY2Fubm90IHVzZSB0aGUgc2FtZSBwc2V1ZG9ub2RlDQpu aWNrbmFtZS4gPGJyPg0KPGJyPg0KQXJlIHRoZXJlIGNhc2VzIG90aGVyIHRoYW4gaHlwZXJ2aXNv cnM/ICZuYnNwO0kgdGhpbmsgdGhlcmUgYXJlIGNhc2VzIG9mDQpicmlkZ2VzIHRoYXQgaGF2ZSB0 aGlzIGJlaGF2aW9yIChhIHBvcnQgd2l0aCBhIGJ1bmNoIG9mIGVuZG5vZGVzLCBhbmQgc2V2ZXJh bA0KdXAtbGlua3MsIHdoZXJlIHRoZSBicmlkZ2UgZG9lcyBub3QgZm9yd2FyZCBiZXR3ZWVuIHRo ZSB1cC1saW5rcy4gJm5ic3A7DQo8YnI+DQo8YnI+DQpJZiB0aGlzIGhhcyBiZWVuIHdyaXR0ZW4g ZG93biBhbnl3aGVyZSwgY2FuIGFueW9uZSBwb2ludCBtZSB0byBpdD8gJm5ic3A7SWYNCm5vdCwg aXQgc2VlbXMgcmVhbGx5IHBydWRlbnQgdG8gYW5zd2VyIHRoZXNlIChhbmQgSSdtIHN1cmUgb3Ro ZXIpIHF1ZXN0aW9ucw0KYmVmb3JlIGFyZ3VpbmcgYWJvdXQgc3BlY2lmaWMgc29sdXRpb25zLiA8 YnI+DQo8YnI+DQpSYWRpYSA8YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPjx0dD5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnRyaWxsIG1h aWxpbmcgbGlzdDwvdHQ+PC9mb250Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx0dD48dT48YnI+ DQo8L3U+PC90dD48L2ZvbnQ+PGEgaHJlZj1tYWlsdG86dHJpbGxAaWV0Zi5vcmcgdGFyZ2V0PV9i bGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dHQ+PHU+dHJpbGxAaWV0Zi5vcmc8L3U+PC90 dD48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx0dD48dT48YnI+DQo8L3U+PC90 dD48L2ZvbnQ+PGEgaHJlZj1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Ry aWxsIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHR0Pjx1Pmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJpbGw8L3U+PC90dD48L2ZvbnQ+PC9hPjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yPjx0dD5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCnRyaWxsIG1haWxpbmcgbGlzdDxicj4NCnRyaWxsQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmlsbDxicj4NCjwvdHQ+PC9mb250Pg0KPGJy Pg0K --=_alternative 000DE9C848257AD4_=-- From zhai.hongjun@zte.com.cn Thu Dec 13 19:17:35 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C564421F8C51; Thu, 13 Dec 2012 19:17:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.999 X-Spam-Level: X-Spam-Status: No, score=-96.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100, WEIRD_QUOTING=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ku76jBts3RPi; Thu, 13 Dec 2012 19:17:34 -0800 (PST) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9D921F8C55; Thu, 13 Dec 2012 19:17:33 -0800 (PST) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 2BC111244348; Fri, 14 Dec 2012 11:19:24 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 3504E72518D; Fri, 14 Dec 2012 11:06:34 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id qBE3HGM1006133; Fri, 14 Dec 2012 11:17:16 +0800 (GMT-8) (envelope-from zhai.hongjun@zte.com.cn) In-Reply-To: To: Radia Perlman MIME-Version: 1.0 X-KeepSent: A7FD3909:DFC4C7F6-48257AD4:0010B0EE; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhai.hongjun@zte.com.cn Date: Fri, 14 Dec 2012 11:17:13 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-12-14 11:17:08, Serialize complete at 2012-12-14 11:17:08 Content-Type: multipart/alternative; boundary="=_alternative 00124CC648257AD4_=" X-MAIL: mse01.zte.com.cn qBE3HGM1006133 Cc: Thomas Narten , trill-bounces@ietf.org, Sam Aldrin , Mingui Zhang , "trill@ietf.org" , "Tissa Senevirathne \(tsenevir\)" Subject: Re: [trill] Thoughts on active-active edge X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 03:17:35 -0000 This is a multipart message in MIME format. --=_alternative 00124CC648257AD4_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgUmFkaWENCg0KVGhhbmtzIGZvciB5b3VyIGFuc3dlcmluZy4NCg0KDQo+IFdoeSBpdCBpcyBu ZWNlc3NhcnkgdG8gaGF2ZSBhIGRpZmZlcmVudCBwc2V1b25vZGUgbmlja25hbWUgaWYgdGhlIHVw bGxuayANCmlzIHRvIA0KPiBkaWZmZXJlbnQgc2V0cyBvZiBSQnJpZGdlczoNCg0KPiBJZiBoeXBl cnZpc29yIEgxIGhhcyB1cGxpbmtzIHRvIFIxLCBSMiwgYW5kIFIzLCBhbmQgdXNlcyBwc2V1ZG9u b2RlIA0Kbmlja25hbWUgUDEsIA0KPiBhbmQgaHlwZXJ2aXNvciBIMiBoYXMgdXBsaW5rcyB0byBS MSBhbmQgUjIgKG9yIGV2ZW4gaGFkIHVwbGlua3MgdG8gUjEsIA0KUjIsIGFuZCBSMywgDQo+IGJ1 dCBpdHMgbGluayB0byBSMyBmYWlscyksIHRoZW4gaWYgSDEgYW5kIEgyIHVzZSB0aGUgc2FtZSBu aWNrbmFtZSwgc2F5IA0KUDEsIA0KPiB0aGVuIHRyYWZmaWMgZm9yIEgyJ3MgTUFDIGFkZHJlc3Nl cyBtaWdodCBnZXQgc2VudCB0byBSMyAoc2luY2UgUjMgaGFzIA0KdG8gY2xhaW0gdG8gDQo+IGJl IGNvbm5lY3RlZCB0byBQMSBiZWNhdXNlIGl0IGlzLCBmb3IgSDEpLiAgQnV0IGl0IGlzIG5vIGxv bmdlciBhdHRhY2hlZCANCnRvIEgyIA0KPiBiZWNhdXNlIEgyJ3MgdXBsaW5rIHRvIFIzIGZhaWxl ZC4NCg0KSSB0aGluayB5b3UgYXJlIHJpZ2h0IGlmIG1lbWJlciBSQnJpZ2VzIG9mIGFuIFJCdiBk byBub3Qgc2hhcmUgdGhlaXIgDQpsZWFybmVkIGFkZHJlc3NlcyANCihvZiBsb2NhbCBhdHRhdGhl ZCBlbmQgbm9kZXMgYW5kIHJlbW90ZSBub2RlcykgYW1vbmcgdGhlIFJCdi4gSWYgdGhleSANCnNo YXJlIHRoZSBsZWFybmVkIA0KYWRkcmVzc2VzLCBSQjMgd2lsbCBrbm93IGl0IGNhbiByZWFjaCBI MiB2aWEgUkIxIG9yIFJCMi4gU2luY2UgSDIgaGFzIA0KdXBsaW5rcyB0byBSQjEgDQphbmQgUkIy LCB0aGUgdHdvIFJCcmlkZ2VzIGNhbiBsZWFybiBIMidzIE1BQyBhZGRyZXNzIGJ5IG9iZXJ2aW5n IEgyJ3MgDQpuYXRpdmUgZnJhbWVzLiANClRoZW4gUkIxIGFuZCBSQjIgY2FuIHNoYXJlIEgyJ3Mg TUFDIHdpdGhpbiB0aGUgUkJ2LCBzbyBSQjMgd2lsbCBrbm93IChmcm9tIA0KdGhlIHNoYXJlZCAN CmluZm9ybWF0aW9uKSB0aGF0IGl0IGNhbiByZWFjaCBIMiB2aWEgUkIxIG9yIFJCMi4gT24gcmVj ZWlwdCBvZiB0cmFmZmljIA0KZm9yIEgyJ3MgDQpNQUMgYWRkcmVzc2VzLCBSQjMgd2lsbCB0dW5u ZWwgdGhlIHRyYWZmaWMgdG8gUkIxIG9yIFJCMiBhbmQgdGhlIGxhdHRlciBSQiANCmVncmVzcyAN CnRoZSB0cmFmZmljIHRvIEgyLg0KDQpBcyBmb3IgdGhlIHRyYWZmaWMgdHVubmVsaW5nLCBpdCBo YXMgYmVlbiBzcGVjaWZpZWQgaW4gDQpkcmFmdC1pZXRmLXRyaWxsLWNsZWFyLWNvcnJlY3QtMDYu dHh0DQooU2VjdGlvbiAyLjQuMi4xIGluIFBhZ2UgOSBhbmQgU2VjdGlvbiAyLjQuMi4zIGluIFBh ZzIgMTApLiBUaGUgdHVubmVsaW5nIA0KaXMgc2ltcGxlLCANClJCMyByZXBsYWNlcyB0aGUgZWdy ZXNzIG5pY2tuYW1lIGluIHRoZSBUUklMTCBoZWFkZXIgb2YgdGhlIHRyYWZmaWMgd2l0aCANClJC MSBvciBSQjIncyBuaWNrbmFtZSwgDQp0aGVuIHRyYW5zbWl0cyB0aGUgcmUtZW5jYXBzdWx0aW9u IHRyYWZmaWMgdG8gUkIxIG9yIFJCMi4NCg0KVGhlcmVmb3JlLCBBZnRlciB0aGUgTUFDIHNoYXJp bmcgYW1vbmcgbWVtYmVyIFJicmlkZ2VzIG9mIGFuIFJCdiBhbmQgdGhlIA0KdHJhZmZpYyB0dW5u ZWxpbmcgDQphcmUgc3VwcG9ydCwgaXQgaXMgbm90IG5lY2Vzc2FyeSBvbmUgbmlja25hbWUgcGVy IGh5cGVydmlzb3IuDQoNClRoZSBzYWZlc3QgdGhpbmcgd291bGQgYmUgZm9yIGV2ZXJ5IGh5cGVy dmlzb3IgdG8gaGF2ZSBhIG5pY2tuYW1lLg0KDQo+IFNvLCBob3cgbWFueSBoeXBlcnZpc29ycyBh cmUgdGhlcmUgbGlrZWx5IHRvIGJlPyAgSG93IHVzdWFsIHdvdWxkIGl0IGJlIA0KZm9yIGFsbCBv ZiANCj4gdGhlbSB0byBhdHRhY2ggdG8gdGhlIHNhbWUgc2V0IG9mIHVwbGlua3MsIHNvIHRoYXQg d2UgY2FuIHVzZSB0aGUgc2FtZSANCnBzZXVvZG5vZGUgbmlja25hbWU/DQoNCkkgZG8gbm90IGtu b3cgaG93IG1hbnkgaHlwZXJ2aXNvcnMgdGhlcmUgbGlrZWx5IGJlLCBidXQgSSBrbm93IG9uZSBS QnJpZGdlIA0KdXN1YWxseSBoYXMgDQoyNCBvciA0OCBkb3duLWxpbmtzIHRoYXQgY2FuIGFjdHMg YXMgdXBsaW5rcyBmb3Igc2V2ZXJhbCBoeXBlcnZpc29ycy4gU28gDQphYm91dCAxMCBvciAyMCAN Cmh5cGVydmlzb3JzIGNhbiBiZSBkdWFsLWhvbWVkIHRvIHRoZSBzYW1lIHR3byBvZiBzdWNoIFJi cmlkZ2VzLiBJZiB0aG9zZSANCmh5cGVydmlzb3JzIHVzZSANCnNhbWUgYSBwc2V1ZG8tbmlja25h bWUsIGl0IG5vdCBvbmx5IHNhdmVzIG5pY2tuYW1lcyBidXQgYWxzbyBkZWNyZWFzZXMgdGhlIA0K UlBGQyBlbnRyaWVzIA0Kb24gdGhlIFJCcmlnZXMgaW4gdGhlIFRSSUxMIGNhbXB1cyBzY29wZS4N Cg0KPiBEbyB3ZSBjYXJlIGFib3V0IHRoZSBjYXNlIG9mIG9uZSBvZiBhIGh5cGVydmlzb3IncyB1 cGxpbmtzIGZhaWxpbmcsIGluIA0Kd2hpY2ggY2FzZSwgDQo+IHdvdWxkIHRoZSBSQnJpZGdlcyBr bm93PyBJZiBSMyAodGhlIG9uZSB0byB3aGljaCB0aGUgdXBsaW5rIGZhaWxlZCkgDQprbm93PyAg V291bGQgUjEgYW5kIFIyIGtub3c/DQoNCkkgdGhpbmsgdGhlIG1lbWJlciBSQnJpZGdlIFNIT1VM RCBrbm93IHRoZSB1cGxpbmsgZmFpbHVyZSBhbmQgdGVsbCBvdGhlciANCm1lbWJlciBSQnJpZGdl cyANCnRoZSBmYWlsdXJlLCBpZiB0aGF0IFJicmlkZ2UgaXMgZGlyZWN0bHkgY29ubmVjdGVkIHRv IGh5cGVydmlzb3Igd2hpY2ggDQp1cGxpbmsgZmFpbHMuIE90aGVyd2lzZSwgDQp3ZSBjYW4gbWFr ZSBzdXJlIHRoZSBtdWx0aS1kZXN0aW5hdGlvbiB0cmFmZmljIGNhbiBiZSBwcm9wZXJseSBlZ3Jl c3NlZCB0byANCnRoZSBoeXBlcnZpc29yLg0KDQoNCj4gU28gdGhlIG1haW4gc29ydCBvZiBjb25m aWd1cmF0aW9uIHRoYXQgSSBjYW4gdGhpbmsgb2YsIG9mZiB0aGUgdG9wIG9mIG15IA0KaGVhZCwg DQo+IGlzIHdoaWNoIHBzZXVkb25vZGVzIGdvIHdpdGggd2hpY2ggaHlwZXJ2aXNvcnMuIA0KDQpJ ZiBoeXBlcnZpc29ycyBkbyBub3QgbWFrZSBUUklMTC1lbmNhcHN1bGF0aW9uL2RlY2Fwc3VsYXRp b24sIHRoZXkgZG8gbm90IA0KbmVlZCB0byBrbm93IA0Kd2hpY2ggcHNldWRvbm9kZXMgZ28gd2l0 aCB0aGVtLiBCdXQgaWYgdGhleSBkbyB0aGUgDQplbmNhcHN1bGF0aW9uL2RlY2Fwc3VsdGlvbiwg dGhleSByZWFsbHkgbmVlZCB0byBrbm93Lg0KDQo+IEkgZG9uJ3Qga25vdyBob3cgUjEgY2FuIGtu b3cgdGhhdCBhIHBhcnRpY3VsYXIgcG9ydCBpcyB0byAiSDEiIHNvIHRoYXQgDQppdCBjYW4gaW5m b3JtIFIyIA0KPiAodmlhIExTUHM/KSB0aGF0IFIxIGlzIGF0dGFjaGVkIHRvIEgxLCBhbmQgUjIg Y2FuIG5vdGljZSB0aGF0IGl0LCANCmluZGVlZCwgaXMgYWxzbyBhdHRhY2hlZCB0byBIMS4NCg0K SWYgSSBub3QgbWlzdW5kZXJzdG9vZCB5b3VyIG1lYW5pbmcsIEkgdGhpbmsgUjEgY2FuIGxlYXJu IEgxJ3MgTUFDIA0KYWRkcmVzc2VzIGJ5IG9ic2VydmluZyBIMSdzIA0KbmF0aXZlIGZyYW1lcy4g VGhlbiBpdCB3aWxsIGtub3cgd2hpY2ggcGFydGljdWxhciBwb3J0IGlzIHRvIEgxLiBSMiBjYW4g DQphbHNvIGRvIHRoZSBsZWFybmluZy4gDQpJZiBSMiBoYXMgbm90IGxlYXJuZWQgSDEncyBNQUMg YWRkcmVzc2VzLCBSMSBjYW4gc2hhcmUgdGhlIGFkZHJlc3NlZCB3aXRoIA0KaXQgdmlhIEVTQURJ IFBEVS4gDQoNCj4gQW5kIHBhcnQgb2YgdGhlIGRlc2NyaXB0aW9uIG9mIHRoZSBwcm9ibGVtIHdv dWxkIGJlIGFuc3dlcmluZyBxdWVzdGlvbnMgDQpsaWtlIA0KPiBob3cgbWFueSB1cGxpbmtzIHdv dWxkIG5lZWQgdG8gYmUgc3VwcG9ydGVkLiAgVHdvIGF0IG1vc3Q/ICAzMD8gIElmIGEgDQpsb3Qs IA0KPiB0aGVuIHNvbHV0aW9ucyB0aGF0IHJlcXVpcmUgYSB0cmVlIGZvciBldmVyeSB1cGxpbmsg d291bGQgYmUgcHJvYmxlbWF0aWMgDQppZiANCj4gaW1wbGVtZW50YXRpb25zIGRvbid0IHdhbnQg dG8gc3VwcG9ydCB0aGF0IG1hbnkgdHJlZXMuICBPciBpcyBpdCBPSyB0byANCnJlcXVpcmUgDQo+ IGxvdHMgb2YgdHJlZXM/DQoNCkluIG15IG1pbmQsIHNvbWUgdmVuZG9ycyBzYXkgdGhlaXIgcHJv cHJpZXRhcnkgTUMtTEFHIHRlY2hub2xvZ2llcyBjYW4gDQpzdXBwb3J0IGF0IG1vc3QgOCBtZW1i ZXIgDQpkZXZpY2VzIGluIHRoZW9yeS4gQnV0IGluIHByYWN0aWNhbCBkZXBsb3ltZW50LCB0d28g b3IgdGhyZWUgbWVtYmVyIA0KZGV2aWNlcyBpbiBhIE1BQy1MQUcgDQpncm91cCBhcmUgT0suIFNv IEkgdGhpbmsgOCB0cmVlcyBpcyBzdXBwb3J0ZWQgaXMgT0sgYXQgY3VycmVudC4gSXQgY2FuIA0K bWVldCB0aGUgcHJhY3RpY2FsIA0KcmVxdWlyZW1lbnRzIGFuZCBkb2VzIG5vdCBtYWtlIG1hc3Mg UlBGQyBlbnRyaWVzLg0KDQpJZiBJIGFtIHdyb25nLCBwbGVhc2UgY29ycmVjdGUgbWUuDQoNCg0K QmVzdCBSZWdhcmRzLA0KWmhhaSBIb25nanVuDQoiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIi IiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiDQogUHJvdG9jb2wgRGV2 ZWxvcG1lbnQgRGVwdC5WSSwgQ2VudHJhbCBSJkQgSW5zdGl0dXRlLCBaVEUgQ29ycG9yYXRpb24N CiBOby4gNjgsIFppamluZ2h1YSBSb2FkLCBZdWh1YXRhaSBEaXN0cmljdCwgTmFuamluZywgUC5S LkNoaW5hLCAyMTAwMTINCiANCiBaaGFpIEhvbmdqdW4NCiANCiBUZWw6ICs4Ni0yNS01Mjg3NzM0 NQ0KIEVtYWlsOiB6aGFpLmhvbmdqdW5AenRlLmNvbS5jbg0KIiIiIiIiIiIiIiIiIiIiIiIiIiIi IiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiINCg0KDQoN Cg0KDQpSYWRpYSBQZXJsbWFuIDxyYWRpYXBlcmxtYW5AZ21haWwuY29tPiANCreivP7IyzogIHRy aWxsLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMTItMTItMTQgMDI6MTANCg0KytW8/sjLDQp6aGFpLmhv bmdqdW5AenRlLmNvbS5jbg0Ks63LzQ0KVGhvbWFzIE5hcnRlbiA8bmFydGVuQHVzLmlibS5jb20+ LCB0cmlsbC1ib3VuY2VzQGlldGYub3JnLCBTYW0gQWxkcmluIA0KPGFsZHJpbi5pZXRmQGdtYWls LmNvbT4sIE1pbmd1aSBaaGFuZyA8emhhbmdtaW5ndWlAaHVhd2VpLmNvbT4sIA0KInRyaWxsQGll dGYub3JnIiA8dHJpbGxAaWV0Zi5vcmc+LCAiVGlzc2EgU2VuZXZpcmF0aG5lIFwodHNlbmV2aXJc KSIgDQo8dHNlbmV2aXJAY2lzY28uY29tPg0K1vfM4g0KUmU6IFt0cmlsbF0gVGhvdWdodHMgb24g YWN0aXZlLWFjdGl2ZSBlZGdlDQoNCg0KDQoNCg0KDQpBbnN3ZXJpbmcgWmhhaSBIb25nanVuJ3Mg cXVlc3Rpb25zOg0KDQpXaHkgaXQgaXMgbmVjZXNzYXJ5IHRvIGhhdmUgYSBkaWZmZXJlbnQgcHNl dW9ub2RlIG5pY2tuYW1lIGlmIHRoZSB1cGxsbmsgDQppcyB0byBkaWZmZXJlbnQgc2V0cyBvZiBS QnJpZGdlczoNCg0KSWYgaHlwZXJ2aXNvciBIMSBoYXMgdXBsaW5rcyB0byBSMSwgUjIsIGFuZCBS MywgYW5kIHVzZXMgcHNldWRvbm9kZSANCm5pY2tuYW1lIFAxLCBhbmQgaHlwZXJ2aXNvciBIMiBo YXMgdXBsaW5rcyB0byBSMSBhbmQgUjIgKG9yIGV2ZW4gaGFkIA0KdXBsaW5rcyB0byBSMSwgUjIs IGFuZCBSMywgYnV0IGl0cyBsaW5rIHRvIFIzIGZhaWxzKSwgdGhlbiBpZiBIMSBhbmQgSDIgDQp1 c2UgdGhlIHNhbWUgbmlja25hbWUsIHNheSBQMSwgdGhlbiB0cmFmZmljIGZvciBIMidzIE1BQyBh ZGRyZXNzZXMgbWlnaHQgDQpnZXQgc2VudCB0byBSMyAoc2luY2UgUjMgaGFzIHRvIGNsYWltIHRv IGJlIGNvbm5lY3RlZCB0byBQMSBiZWNhdXNlIGl0IGlzLCANCmZvciBIMSkuICBCdXQgaXQgaXMg bm8gbG9uZ2VyIGF0dGFjaGVkIHRvIEgyIGJlY2F1c2UgSDIncyB1cGxpbmsgdG8gUjMgDQpmYWls ZWQuDQoNClRoZSBzYWZlc3QgdGhpbmcgd291bGQgYmUgZm9yIGV2ZXJ5IGh5cGVydmlzb3IgdG8g aGF2ZSBhIG5pY2tuYW1lLg0KDQpTbywgaG93IG1hbnkgaHlwZXJ2aXNvcnMgYXJlIHRoZXJlIGxp a2VseSB0byBiZT8gIEhvdyB1c3VhbCB3b3VsZCBpdCBiZSANCmZvciBhbGwgb2YgdGhlbSB0byBh dHRhY2ggdG8gdGhlIHNhbWUgc2V0IG9mIHVwbGlua3MsIHNvIHRoYXQgd2UgY2FuIHVzZSANCnRo ZSBzYW1lIHBzZXVvZG5vZGUgbmlja25hbWU/ICBEbyB3ZSBjYXJlIGFib3V0IHRoZSBjYXNlIG9m IG9uZSBvZiBhIA0KaHlwZXJ2aXNvcidzIHVwbGlua3MgZmFpbGluZywgaW4gd2hpY2ggY2FzZSwg d291bGQgdGhlIFJCcmlkZ2VzIGtub3c/ICBJZiANClIzICh0aGUgb25lIHRvIHdoaWNoIHRoZSB1 cGxpbmsgZmFpbGVkKSBrbm93PyAgV291bGQgUjEgYW5kIFIyIGtub3c/ICBFdmVuIA0KaWYgUjMg a25ldywgaG93IGNvdWxkIGl0IGFsZXJ0IFIxIGFuZCBSMiB0byBub3cgdXNlIGEgZGlmZmVyZW50 IHBzZXVkb25vZGUgDQpuaWNrbmFtZSBmb3IgSDI/ICBXb3VsZCBpdCBiZSBvYnZpb3VzIHRvIHRo ZW0gd2hpY2ggb2YgdGhlIGh5cGVydmlzb3JzIA0KdGhhdCBoYXZlIHVwbGlua3MgdG8gUjEsIFIy LCBhbmQgUjMgdGhleSBhcmUgcmVmZXJyaW5nIHRvPw0KDQpBbGwgb2YgdGhpcyBtdXN0IGJlIGNv bmZpZ3VyZWQsIEkgYXNzdW1lLCBhbmQgaWYgdGhlIGNvbmZpZ3VyYXRpb24gaXMgDQp3cm9uZywg dGhlbiB3aG8ga25vd3Mgd2hhdCBoYXBwZW5zLi5wcmVzdW1hYmx5IHRoYXQgdHJhZmZpYyBtYXkg b3IgbWF5IG5vdCANCmdldCBkZWxpdmVyZWQgdG8gYSBoeXBlcnZpc29yLiAgQW5kIGV2ZW4gaWYg Y29uZmlndXJlZCBwcm9wZXJseSwgd2hhdCANCmhhcHBlbnMgd2hlbiB1cGxpbmtzIGZhaWw/ICBB Z2FpbiwgcHJlc3VtYWJseSwgdHJhZmZpYyBtYXkgb3IgbWF5IG5vdCBnZXQgDQpkZWxpdmVyZWQg dG8gdGhlIGh5cGVydmlzb3Igd2hvc2UgdXBsaW5rIGZhaWxzLg0KDQotLS0tLS0tLS0tLS0tDQpB cyBmb3IgVkxBTnMuLi50aGF0IGFjdHVhbGx5IGlzIG5vdCBhIHByb2JsZW0gaGVyZSwgc2luY2Ug d2UncmUgbm90IHVzaW5nIA0KQUZzLiAgVGhlIGh5cGVydmlzb3IgZGV0ZXJtaW5lcyB3aGljaCB1 cGxpbmsgdG8gc2VuZCBzb21ldGhpbmcgdG8uICBBbmQgDQp3aGljaCB0cmVlIGlzIGJlaW5nIHVz ZWQgZm9yIGRpc3RyaWJ1dGlvbiBkZXRlcm1pbmVzIHdoaWNoIG9mIFIxLCBSMiwgb3IgDQpSMyB3 aWxsIGRlY2Fwc3VsYXRlIHRoZSBwYWNrZXQuDQoNClNvIHRoZSBtYWluIHNvcnQgb2YgY29uZmln dXJhdGlvbiB0aGF0IEkgY2FuIHRoaW5rIG9mLCBvZmYgdGhlIHRvcCBvZiBteSANCmhlYWQsIGlz IHdoaWNoIHBzZXVkb25vZGVzIGdvIHdpdGggd2hpY2ggaHlwZXJ2aXNvcnMuICBBbmQgSSBkbyB0 aGluayANCmNvbmZpZ3VyYXRpb24gaXMgc2NhcnksIGVzcGVjaWFsbHkgaWYgdGhlcmUncyBubyAi c2FuaXR5IGNoZWNrIiB3aGVyZWJ5IA0KdGhlIFJCcyBjYW4gY29tcGFyZSBub3Rlcy4gIEkgZG9u J3Qga25vdyBob3cgUjEgY2FuIGtub3cgdGhhdCBhIHBhcnRpY3VsYXIgDQpwb3J0IGlzIHRvICJI MSIgc28gdGhhdCBpdCBjYW4gaW5mb3JtIFIyICh2aWEgTFNQcz8pIHRoYXQgUjEgaXMgYXR0YWNo ZWQgDQp0byBIMSwgYW5kIFIyIGNhbiBub3RpY2UgdGhhdCBpdCwgaW5kZWVkLCBpcyBhbHNvIGF0 dGFjaGVkIHRvIEgxLg0KDQotLS0tLS0tLQ0KQW5kIHBhcnQgb2YgdGhlIGRlc2NyaXB0aW9uIG9m IHRoZSBwcm9ibGVtIHdvdWxkIGJlIGFuc3dlcmluZyBxdWVzdGlvbnMgDQpsaWtlIGhvdyBtYW55 IHVwbGlua3Mgd291bGQgbmVlZCB0byBiZSBzdXBwb3J0ZWQuICBUd28gYXQgbW9zdD8gIDMwPyAg SWYgYSANCmxvdCwgdGhlbiBzb2x1dGlvbnMgdGhhdCByZXF1aXJlIGEgdHJlZSBmb3IgZXZlcnkg dXBsaW5rIHdvdWxkIGJlIA0KcHJvYmxlbWF0aWMgaWYgaW1wbGVtZW50YXRpb25zIGRvbid0IHdh bnQgdG8gc3VwcG9ydCB0aGF0IG1hbnkgdHJlZXMuICBPciANCmlzIGl0IE9LIHRvIHJlcXVpcmUg bG90cyBvZiB0cmVlcz8NCg0KU28gSSB0aGluayB0aGVyZSBhcmUgbG90cyBvZiB0aGluZ3MgdGhh dCBzaG91bGQgYmUgd3JpdHRlbiBkb3duLCBhcyBwYXJ0IA0Kb2YgZGVzY3JpYmluZyB0aGUgcHJv YmxlbS4NCg0KDQoNClJhZGlhDQoNCg0KDQoNCg0KT24gVGh1LCBEZWMgMTMsIDIwMTIgYXQgNDow MyBBTSwgPHpoYWkuaG9uZ2p1bkB6dGUuY29tLmNuPiB3cm90ZToNCg0KSGkgUmFkaWEgDQoNCj4g VGhpcyBjYXNlIGlzIHNjYXJ5IGJlY2F1c2UgdGhlIFJCcmlkZ2VzIG9uIHRoZSB1cGxpbmsgY2Fu bm90IHNlZSBIZWxsb3MgDQpmcm9tIGVhY2ggb3RoZXIsIA0KPiBzbyBpZiBtaXNjb25maWd1cmVk LCBhdCB0aGUgdmVyeSBsZWFzdCBJIGNvdWxkIGltYWdpbmUgbXVsdGlwbGUgUkJyaWRnZXMgDQpk ZWNhcHN1bGF0aW5nIA0KPiBtdWx0aWNhc3QgZnJvbSB0aGUgY2FtcHVzIHRvIHRoZSBoeXBlcnZp c29yLiANCg0KPiBBbnl3YXkuLi5ob3cgbWFueSB1cGxpbmtzIGRvIHdlIG5lZWQgdG8gc3VwcG9y dD8gIERvIHdlIGNhcmUgYWJvdXQgDQpwcm9ibGVtcyBkdWUgdG8gbWlzY29uZmlndXJhdGlvbj8g DQoNCkkgZG9uJ3Qga25vdyB3aGF0IHRoZSBtaXNjb25maWd1cmF0aW9uIHJlZmVycyB0by4gSXMg aXQgdGhlIHNldCBvZiBWTEFOcyANCmZvciB3aGljaCBhbiBSYnJpZGdlIGFjdHMgYXMgQUY/IA0K DQoNCj4gQXJlIHRoZXJlIGNhc2VzIHdoZXJlIHRoZXJlIGFyZSBsb3RzIG9mIGh5cGVydmlzb3Jz LCB3aGVyZSB0aGV5IGF0dGFjaCANCnRvIGRpZmZlcmVudCBzdWJzZXRzIG9mIGVkZ2UgUkJzPyAN Cj4gSW4gdGhhdCBjYXNlLCB3ZSBtaWdodCBlYXQgdXAgYSBsb3Qgb2Ygbmlja25hbWVzLCBzaW5j ZSBpZiBvbmUgDQpoeXBlcnZpc29yIGlzIGF0dGFjaGVkIHRvIHtSMSwgUjJ9LCANCj4gYW5kIGFu b3RoZXIgaXMgYXR0YWNoZWQgdG8ge1IxLCBSMiwgUjN9LCB0aGV5IGNhbm5vdCB1c2UgdGhlIHNh bWUgDQpwc2V1ZG9ub2RlIG5pY2tuYW1lLiANCg0KSSBkb24ndCBrbm93IHdoeSB0aGUgdHdvIHNl dHMgb2YgUkJyaWRnZXMgY2FuIG5vdCB1c2UgdGhlIHNhbWUgDQpwc2V1ZG8tbmlja25hbWUuIElm IHRoZSBsZWFybmVkIE1BQyBhZGRyZXNzZXMgDQpjYW4gYmUgc2hhcmVkIGFtb25nIG1lbWJlciBS YnJpZGdlcyBvZiBhbiBSQnYgYW5kIFRSSUxMIGRhdGEgZnJhbWVzIGNhbiBiZSANCnR1bm5lbGVk IHRvIGFub3RoZXIgbWVtYmVyIFJicmlkZ2UgDQp0aGF0IGNhbiBlZ3Jlc3MgdGhlIGZyYW1lLCBJ IHRoaW5rIHRoZXkgY2FuIHVzZSB0aGUgc2FtZSBwc2V1ZG8tbmlja25hbWUuIA0KDQpJZiBJIGFt IHdyb25nLCBwbGVhc2UgY29ycmVjdCBtZS4NCg0KDQpCZXN0IFJlZ2FyZHMsDQpaaGFpIEhvbmdq dW4NCiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIi IiIiIiIiIiIiIiIiIiIiIiINClByb3RvY29sIERldmVsb3BtZW50IERlcHQuVkksIENlbnRyYWwg UiZEIEluc3RpdHV0ZSwgWlRFIENvcnBvcmF0aW9uDQpOby4gNjgsIFppamluZ2h1YSBSb2FkLCBZ dWh1YXRhaSBEaXN0cmljdCwgTmFuamluZywgUC5SLkNoaW5hLCAyMTAwMTINCg0KWmhhaSBIb25n anVuDQoNClRlbDogKzg2LTI1LTUyODc3MzQ1DQpFbWFpbDogemhhaS5ob25nanVuQHp0ZS5jb20u Y24NCiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIi IiIiIiIiIiIiIiIiIiIiIiIiDQoNCg0KDQoNCg0KUmFkaWEgUGVybG1hbiA8cmFkaWFwZXJsbWFu QGdtYWlsLmNvbT4gDQq3orz+yMs6ICB0cmlsbC1ib3VuY2VzQGlldGYub3JnIA0KMjAxMi0xMi0x MyAxNToxMyANCg0KDQrK1bz+yMsNCk1pbmd1aSBaaGFuZyA8emhhbmdtaW5ndWlAaHVhd2VpLmNv bT4gDQqzrcvNDQpUaG9tYXMgTmFydGVuIDxuYXJ0ZW5AdXMuaWJtLmNvbT4sIFNhbSBBbGRyaW4g PGFsZHJpbi5pZXRmQGdtYWlsLmNvbT4sIA0KIlRpc3NhIFNlbmV2aXJhdGhuZSBcKHRzZW5ldmly XCkiIDx0c2VuZXZpckBjaXNjby5jb20+LCAidHJpbGxAaWV0Zi5vcmciIDwNCnRyaWxsQGlldGYu b3JnPiANCtb3zOINClJlOiBbdHJpbGxdIFRob3VnaHRzIG9uIGFjdGl2ZS1hY3RpdmUgZWRnZQ0K DQoNCg0KDQoNCg0KDQoNCkkgdGhpbmsgaXQgd291bGQgYmUgZ29vZCB0byBoYXZlIGEgZG9jdW1l bnQgdGhhdCBleHBsYWlucyB0aGUgcHJvYmxlbS4uLkkgDQpjZXJ0YWlubHkgZG9uJ3QgYmVsaWV2 ZSBJIGtub3cgYWxsIHRoZSBjYXNlcyB0aGF0IG5lZWQgdG8gYmUgc29sdmVkLiAgSSANCnRoaW5r IEkgdW5kZXJzdGFuZCB0aGUgaHlwZXJ2aXNvciBjYXNlLi4ud2hlcmUgdGhlIGh5cGVydmlzb3Ig ZGVjaWRlcyANCndoaWNoIHVwbGluayB0byBzZW5kIHRoaW5ncyB0bywgYW5kIG5ldmVyIGZvcndh cmRzIGJldHdlZW4gdGhlIHVwLWxpbmtzLiANCg0KVGhpcyBjYXNlIGlzIHNjYXJ5IGJlY2F1c2Ug dGhlIFJCcmlkZ2VzIG9uIHRoZSB1cGxpbmsgY2Fubm90IHNlZSBIZWxsb3MgDQpmcm9tIGVhY2gg b3RoZXIsIHNvIGlmIG1pc2NvbmZpZ3VyZWQsIGF0IHRoZSB2ZXJ5IGxlYXN0IEkgY291bGQgaW1h Z2luZSANCm11bHRpcGxlIFJCcmlkZ2VzIGRlY2Fwc3VsYXRpbmcgbXVsdGljYXN0IGZyb20gdGhl IGNhbXB1cyB0byB0aGUgDQpoeXBlcnZpc29yLiANCg0KQW55d2F5Li4uaG93IG1hbnkgdXBsaW5r cyBkbyB3ZSBuZWVkIHRvIHN1cHBvcnQ/ICBEbyB3ZSBjYXJlIGFib3V0IA0KcHJvYmxlbXMgZHVl IHRvIG1pc2NvbmZpZ3VyYXRpb24/IA0KDQpJbiBjYXNlcyBsaWtlIHRoaXMsIGlzIGl0IGNvbW1v biB0byBhbHNvIGhhdmUgcHQtdG8tcHQgbGlua3MgYmV0d2VlbiBhbGwgDQp0aGUgUkJzIGF0dGFj aGluZyB0byB0aGUgaHlwZXJ2aXNvcj8gIElmIHNvLCB0aGVuIGl0IHNlZW1zIGxpa2UgaXQgd291 bGQgDQpiZSBwb3NzaWJsZSBmb3IgdGhlbSB0byBjb29yZGluYXRlIHRvIGF0IGxlYXN0IGRldGVj dCBtaXNjb25maWd1cmF0aW9uLCANCmFuZCBwb3NzaWJseSBwbGF5IGdhbWVzIHdpdGggZm9yd2Fy ZGluZyBtZXNzYWdlcyB0byBlYWNoIG90aGVyIChlLmcuLCBpZiANCm9uZSBvZiB0aGVtIGlzIG5v dCBhdHRhY2hlZCB0byBhIHRyZWUgYW5kIG5lZWRzIHRvIGVuY2Fwc3VsYXRlIGEgDQptdWx0aWRl c3RpbmF0aW9uIGZyYW1lKS4gDQoNCkhvdyBtYW55IHRyZWVzIGRvZXMgdGhlIGNhbXB1cyBuZWVk PyANCg0KQXJlIHRoZXJlIGNhc2VzIHdoZXJlIHRoZXJlIGFyZSBsb3RzIG9mIGh5cGVydmlzb3Jz LCB3aGVyZSB0aGV5IGF0dGFjaCB0byANCmRpZmZlcmVudCBzdWJzZXRzIG9mIGVkZ2UgUkJzPyAg SW4gdGhhdCBjYXNlLCB3ZSBtaWdodCBlYXQgdXAgYSBsb3Qgb2YgDQpuaWNrbmFtZXMsIHNpbmNl IGlmIG9uZSBoeXBlcnZpc29yIGlzIGF0dGFjaGVkIHRvIHtSMSwgUjJ9LCBhbmQgYW5vdGhlciBp cyANCmF0dGFjaGVkIHRvIHtSMSwgUjIsIFIzfSwgdGhleSBjYW5ub3QgdXNlIHRoZSBzYW1lIHBz ZXVkb25vZGUgbmlja25hbWUuIA0KDQpBcmUgdGhlcmUgY2FzZXMgb3RoZXIgdGhhbiBoeXBlcnZp c29ycz8gIEkgdGhpbmsgdGhlcmUgYXJlIGNhc2VzIG9mIA0KYnJpZGdlcyB0aGF0IGhhdmUgdGhp cyBiZWhhdmlvciAoYSBwb3J0IHdpdGggYSBidW5jaCBvZiBlbmRub2RlcywgYW5kIA0Kc2V2ZXJh bCB1cC1saW5rcywgd2hlcmUgdGhlIGJyaWRnZSBkb2VzIG5vdCBmb3J3YXJkIGJldHdlZW4gdGhl IHVwLWxpbmtzLiAgDQoNCg0KSWYgdGhpcyBoYXMgYmVlbiB3cml0dGVuIGRvd24gYW55d2hlcmUs IGNhbiBhbnlvbmUgcG9pbnQgbWUgdG8gaXQ/ICBJZiANCm5vdCwgaXQgc2VlbXMgcmVhbGx5IHBy dWRlbnQgdG8gYW5zd2VyIHRoZXNlIChhbmQgSSdtIHN1cmUgb3RoZXIpIA0KcXVlc3Rpb25zIGJl Zm9yZSBhcmd1aW5nIGFib3V0IHNwZWNpZmljIHNvbHV0aW9ucy4gDQoNClJhZGlhIA0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdHJpbGwgbWFpbGlu ZyBsaXN0DQp0cmlsbEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby90cmlsbA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KdHJpbGwgbWFpbGluZyBsaXN0DQp0cmlsbEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmlsbA0KDQoNCg== --=_alternative 00124CC648257AD4_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8ZGl2Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5IaSBSYWRpYTwvZm9u dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmtzIGZvciB5 b3VyIGFuc3dlcmluZy48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPiZndDsgV2h5IGl0IGlzIG5lY2Vzc2FyeSB0byBoYXZlIGEgZGlmZmVyZW50 DQpwc2V1b25vZGUgbmlja25hbWUgaWYgdGhlIHVwbGxuayBpcyB0byA8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZndDsgZGlmZmVyZW50IHNldHMgb2YgUkJyaWRn ZXM6PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7 IElmIGh5cGVydmlzb3IgSDEgaGFzIHVwbGlua3MgdG8NClIxLCBSMiwgYW5kIFIzLCBhbmQgdXNl cyBwc2V1ZG9ub2RlIG5pY2tuYW1lIFAxLCA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPiZndDsgYW5kIGh5cGVydmlzb3IgSDIgaGFzIHVwbGlua3MgdG8NClIxIGFu ZCBSMiAob3IgZXZlbiBoYWQgdXBsaW5rcyB0byBSMSwgUjIsIGFuZCBSMywgPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7IGJ1dCBpdHMgbGluayB0byBSMyBm YWlscyksIHRoZW4NCmlmIEgxIGFuZCBIMiB1c2UgdGhlIHNhbWUgbmlja25hbWUsIHNheSBQMSwg PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7IHRoZW4gdHJh ZmZpYyBmb3IgSDIncyBNQUMgYWRkcmVzc2VzDQptaWdodCBnZXQgc2VudCB0byBSMyAoc2luY2Ug UjMgaGFzIHRvIGNsYWltIHRvIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+Jmd0OyBiZSBjb25uZWN0ZWQgdG8gUDEgYmVjYXVzZSBpdCBpcywNCmZvciBIMSkuICZu YnNwO0J1dCBpdCBpcyBubyBsb25nZXIgYXR0YWNoZWQgdG8gSDIgPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7IGJlY2F1c2UgSDIncyB1cGxpbmsgdG8gUjMg ZmFpbGVkLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ SSB0aGluayB5b3UgYXJlIHJpZ2h0IGlmIG1lbWJlciBSQnJpZ2VzDQpvZiBhbiBSQnYgZG8gbm90 IHNoYXJlIHRoZWlyIGxlYXJuZWQgYWRkcmVzc2VzIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+KG9mIGxvY2FsIGF0dGF0aGVkIGVuZCBub2RlcyBhbmQgcmVtb3Rl DQpub2RlcykgYW1vbmcgdGhlIFJCdi4gSWYgdGhleSBzaGFyZSB0aGUgbGVhcm5lZCA8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmFkZHJlc3NlcywgUkIzIHdpbGwg a25vdyBpdCBjYW4gcmVhY2gNCkgyIHZpYSBSQjEgb3IgUkIyLiBTaW5jZSBIMiBoYXMgdXBsaW5r cyB0byBSQjEgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5hbmQg UkIyLCB0aGUgdHdvIFJCcmlkZ2VzIGNhbiBsZWFybg0KSDIncyBNQUMgYWRkcmVzcyBieSBvYmVy dmluZyBIMidzIG5hdGl2ZSBmcmFtZXMuIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+VGhlbiBSQjEgYW5kIFJCMiBjYW4gc2hhcmUgSDIncyBNQUMNCndpdGhpbiB0 aGUgUkJ2LCBzbyBSQjMgd2lsbCBrbm93IChmcm9tIHRoZSBzaGFyZWQgPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5pbmZvcm1hdGlvbikgdGhhdCBpdCBjYW4gcmVh Y2ggSDIgdmlhDQpSQjEgb3IgUkIyLiBPbiByZWNlaXB0IG9mIHRyYWZmaWMgZm9yIEgyJ3MgPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5NQUMgYWRkcmVzc2VzLCBS QjMgd2lsbCB0dW5uZWwgdGhlIHRyYWZmaWMNCnRvIFJCMSBvciBSQjIgYW5kIHRoZSBsYXR0ZXIg UkIgZWdyZXNzIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+dGhl IHRyYWZmaWMgdG8gSDIuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj5BcyBmb3IgdGhlIHRyYWZmaWMgdHVubmVsaW5nLCBpdCBoYXMNCmJlZW4gc3BlY2lm aWVkIGluIGRyYWZ0LWlldGYtdHJpbGwtY2xlYXItY29ycmVjdC0wNi50eHQ8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPihTZWN0aW9uIDIuNC4yLjEgaW4gUGFnZSA5 IGFuZCBTZWN0aW9uDQoyLjQuMi4zIGluIFBhZzIgMTApLiBUaGUgdHVubmVsaW5nIGlzIHNpbXBs ZSwgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5SQjMgcmVwbGFj ZXMgdGhlIGVncmVzcyBuaWNrbmFtZSBpbg0KdGhlIFRSSUxMIGhlYWRlciBvZiB0aGUgdHJhZmZp YyB3aXRoIFJCMSBvciBSQjIncyBuaWNrbmFtZSwgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj50aGVuIHRyYW5zbWl0cyB0aGUgcmUtZW5jYXBzdWx0aW9uIHRyYWZm aWMNCnRvIFJCMSBvciBSQjIuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj5UaGVyZWZvcmUsIEFmdGVyIHRoZSBNQUMgc2hhcmluZyBhbW9uZw0KbWVtYmVy IFJicmlkZ2VzIG9mIGFuIFJCdiBhbmQgdGhlIHRyYWZmaWMgdHVubmVsaW5nIDwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+YXJlIHN1cHBvcnQsIGl0IGlzIG5vdCBu ZWNlc3Nhcnkgb25lDQpuaWNrbmFtZSBwZXIgaHlwZXJ2aXNvci48L2ZvbnQ+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoZSBzYWZlc3QgdGhpbmcgd291bGQgYmUg Zm9yIGV2ZXJ5DQpoeXBlcnZpc29yIHRvIGhhdmUgYSBuaWNrbmFtZS48L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZndDsgU28sIGhvdyBtYW55IGh5cGVy dmlzb3JzIGFyZSB0aGVyZQ0KbGlrZWx5IHRvIGJlPyAmbmJzcDtIb3cgdXN1YWwgd291bGQgaXQg YmUgZm9yIGFsbCBvZiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PiZndDsgdGhlbSB0byBhdHRhY2ggdG8gdGhlIHNhbWUgc2V0DQpvZiB1cGxpbmtzLCBzbyB0aGF0 IHdlIGNhbiB1c2UgdGhlIHNhbWUgcHNldW9kbm9kZSBuaWNrbmFtZT88L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgZG8gbm90IGtub3cgaG93IG1hbnkg aHlwZXJ2aXNvcnMgdGhlcmUNCmxpa2VseSBiZSwgYnV0IEkga25vdyBvbmUgUkJyaWRnZSB1c3Vh bGx5IGhhcyA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjI0IG9y IDQ4IGRvd24tbGlua3MgdGhhdCBjYW4gYWN0cyBhcw0KdXBsaW5rcyBmb3Igc2V2ZXJhbCBoeXBl cnZpc29ycy4gU28gYWJvdXQgMTAgb3IgMjAgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj5oeXBlcnZpc29ycyBjYW4gYmUgZHVhbC1ob21lZCB0byB0aGUNCnNhbWUg dHdvIG9mIHN1Y2ggUmJyaWRnZXMuIElmIHRob3NlIGh5cGVydmlzb3JzIHVzZSA8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnNhbWUgYSBwc2V1ZG8tbmlja25hbWUs IGl0IG5vdCBvbmx5DQpzYXZlcyBuaWNrbmFtZXMgYnV0IGFsc28gZGVjcmVhc2VzIHRoZSBSUEZD IGVudHJpZXMgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5vbiB0 aGUgUkJyaWdlcyBpbiB0aGUgVFJJTEwgY2FtcHVzIHNjb3BlLjwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0OyBEbyB3ZSBjYXJlIGFib3V0IHRoZSBj YXNlIG9mIG9uZQ0Kb2YgYSBoeXBlcnZpc29yJ3MgdXBsaW5rcyBmYWlsaW5nLCBpbiB3aGljaCBj YXNlLCA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZndDsgd291 bGQgdGhlIFJCcmlkZ2VzIGtub3c/IElmIFIzDQoodGhlIG9uZSB0byB3aGljaCB0aGUgdXBsaW5r IGZhaWxlZCkga25vdz8gJm5ic3A7V291bGQgUjEgYW5kIFIyIGtub3c/PC9mb250Pg0KPGJyPg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JIHRoaW5rIHRoZSBtZW1iZXIgUkJy aWRnZSBTSE9VTEQga25vdw0KdGhlIHVwbGluayBmYWlsdXJlIGFuZCB0ZWxsIG90aGVyIG1lbWJl ciBSQnJpZGdlcyA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnRo ZSBmYWlsdXJlLCBpZiB0aGF0IFJicmlkZ2UgaXMgZGlyZWN0bHkNCmNvbm5lY3RlZCB0byBoeXBl cnZpc29yIHdoaWNoIHVwbGluayBmYWlscy4gT3RoZXJ3aXNlLCA8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPndlIGNhbiBtYWtlIHN1cmUgdGhlIG11bHRpLWRlc3Rp bmF0aW9uDQp0cmFmZmljIGNhbiBiZSBwcm9wZXJseSBlZ3Jlc3NlZCB0byB0aGUgaHlwZXJ2aXNv ci48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PiZndDsgU28gdGhlIG1haW4gc29ydCBvZiBjb25maWd1cmF0aW9uDQp0aGF0IEkgY2FuIHRoaW5r IG9mLCBvZmYgdGhlIHRvcCBvZiBteSBoZWFkLCA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPiZndDsgaXMgd2hpY2ggcHNldWRvbm9kZXMgZ28gd2l0aCB3aGljaA0K aHlwZXJ2aXNvcnMuICZuYnNwOzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+SWYgaHlwZXJ2aXNvcnMgZG8gbm90IG1ha2UgVFJJTEwtZW5jYXBzdWxhdGlv bi9kZWNhcHN1bGF0aW9uLA0KdGhleSBkbyBub3QgbmVlZCB0byBrbm93IDwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+d2hpY2ggcHNldWRvbm9kZXMgZ28gd2l0aCB0 aGVtLiBCdXQNCmlmIHRoZXkgZG8gdGhlIGVuY2Fwc3VsYXRpb24vZGVjYXBzdWx0aW9uLCB0aGV5 IHJlYWxseSBuZWVkIHRvIGtub3cuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj4mZ3Q7IEkgZG9uJ3Qga25vdyBob3cgUjEgY2FuIGtub3cgdGhhdA0KYSBw YXJ0aWN1bGFyIHBvcnQgaXMgdG8gJnF1b3Q7SDEmcXVvdDsgc28gdGhhdCBpdCBjYW4gaW5mb3Jt IFIyIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0OyAodmlh IExTUHM/KSB0aGF0IFIxIGlzIGF0dGFjaGVkDQp0byBIMSwgYW5kIFIyIGNhbiBub3RpY2UgdGhh dCBpdCwgaW5kZWVkLCBpcyBhbHNvIGF0dGFjaGVkIHRvIEgxLjwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SWYgSSBub3QgbWlzdW5kZXJzdG9vZCB5b3Vy IG1lYW5pbmcsDQpJIHRoaW5rIFIxIGNhbiBsZWFybiBIMSdzIE1BQyBhZGRyZXNzZXMgYnkgb2Jz ZXJ2aW5nIEgxJ3MgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5u YXRpdmUgZnJhbWVzLiBUaGVuIGl0IHdpbGwga25vdyB3aGljaA0KcGFydGljdWxhciBwb3J0IGlz IHRvIEgxLiBSMiBjYW4gYWxzbyBkbyB0aGUgbGVhcm5pbmcuIDwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SWYgUjIgaGFzIG5vdCBsZWFybmVkIEgxJ3MgTUFDIGFk ZHJlc3NlcywNClIxIGNhbiBzaGFyZSB0aGUgYWRkcmVzc2VkIHdpdGggaXQgdmlhIEVTQURJIFBE VS4gPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7 IEFuZCBwYXJ0IG9mIHRoZSBkZXNjcmlwdGlvbiBvZg0KdGhlIHByb2JsZW0gd291bGQgYmUgYW5z d2VyaW5nIHF1ZXN0aW9ucyBsaWtlIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+Jmd0OyBob3cgbWFueSB1cGxpbmtzIHdvdWxkIG5lZWQgdG8NCmJlIHN1cHBvcnRl ZC4gJm5ic3A7VHdvIGF0IG1vc3Q/ICZuYnNwOzMwPyAmbmJzcDtJZiBhIGxvdCwgPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7IHRoZW4gc29sdXRpb25zIHRo YXQgcmVxdWlyZSBhIHRyZWUNCmZvciBldmVyeSB1cGxpbmsgd291bGQgYmUgcHJvYmxlbWF0aWMg aWYgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7IGltcGxl bWVudGF0aW9ucyBkb24ndCB3YW50IHRvIHN1cHBvcnQNCnRoYXQgbWFueSB0cmVlcy4gJm5ic3A7 T3IgaXMgaXQgT0sgdG8gcmVxdWlyZSA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPiZndDsgbG90cyBvZiB0cmVlcz88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkluIG15IG1pbmQsIHNvbWUgdmVuZG9ycyBzYXkgdGhlaXIg cHJvcHJpZXRhcnkNCk1DLUxBRyB0ZWNobm9sb2dpZXMgY2FuIHN1cHBvcnQgYXQgbW9zdCA4IG1l bWJlciA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmRldmljZXMg aW4gdGhlb3J5LiBCdXQgaW4gcHJhY3RpY2FsDQpkZXBsb3ltZW50LCB0d28gb3IgdGhyZWUgbWVt YmVyIGRldmljZXMgaW4gYSBNQUMtTEFHIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+Z3JvdXAgYXJlIE9LLiBTbyBJIHRoaW5rIDggdHJlZXMgaXMNCnN1cHBvcnRl ZCBpcyBPSyBhdCBjdXJyZW50LiBJdCBjYW4gbWVldCB0aGUgcHJhY3RpY2FsIDwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+cmVxdWlyZW1lbnRzIGFuZCBkb2VzIG5v dCBtYWtlIG1hc3MNClJQRkMgZW50cmllcy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPklmIEkgYW0gd3JvbmcsIHBsZWFzZSBjb3JyZWN0ZSBtZS48L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjxicj4NCkJlc3Qg UmVnYXJkcyw8YnI+DQpaaGFpIEhvbmdqdW48YnI+DQomcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDs8YnI+ DQogUHJvdG9jb2wgRGV2ZWxvcG1lbnQgRGVwdC5WSSwgQ2VudHJhbCBSJmFtcDtEIEluc3RpdHV0 ZSwgWlRFIENvcnBvcmF0aW9uPGJyPg0KIE5vLiA2OCwgWmlqaW5naHVhIFJvYWQsIFl1aHVhdGFp IERpc3RyaWN0LCBOYW5qaW5nLCBQLlIuQ2hpbmEsIDIxMDAxMjxicj4NCiA8YnI+DQogWmhhaSBI b25nanVuPGJyPg0KIDxicj4NCiBUZWw6ICs4Ni0yNS01Mjg3NzM0NTxicj4NCiBFbWFpbDogemhh aS5ob25nanVuQHp0ZS5jb20uY248YnI+DQomcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDs8YnI+ DQo8YnI+DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0 ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+PGI+UmFkaWEgUGVybG1hbiAmbHQ7cmFkaWFwZXJsbWFuQGdtYWlsLmNvbSZndDs8L2I+DQo8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7 dHJpbGwtYm91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj4yMDEyLTEyLTE0IDAyOjEwPC9mb250Pg0KPHRkIHdpZHRoPTYzJT4NCjx0YWJsZSB3 aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPnpoYWkuaG9uZ2p1bkB6dGUuY29tLmNuPC9mb250Pg0K PHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj5UaG9tYXMgTmFydGVuICZsdDtuYXJ0ZW5AdXMuaWJtLmNvbSZndDssDQp0cmls bC1ib3VuY2VzQGlldGYub3JnLCBTYW0gQWxkcmluICZsdDthbGRyaW4uaWV0ZkBnbWFpbC5jb20m Z3Q7LCBNaW5ndWkNClpoYW5nICZsdDt6aGFuZ21pbmd1aUBodWF3ZWkuY29tJmd0OywgJnF1b3Q7 dHJpbGxAaWV0Zi5vcmcmcXVvdDsgJmx0O3RyaWxsQGlldGYub3JnJmd0OywNCiZxdW90O1Rpc3Nh IFNlbmV2aXJhdGhuZSBcKHRzZW5ldmlyXCkmcXVvdDsgJmx0O3RzZW5ldmlyQGNpc2NvLmNvbSZn dDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBbdHJpbGxdIFRob3VnaHRzIG9uIGFjdGl2ZS1hY3Rp dmUNCmVkZ2U8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0K PHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+QW5zd2VyaW5nIFpoYWkgSG9uZ2p1bidzIHF1ZXN0aW9u czo8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPldoeSBp dCBpcyBuZWNlc3NhcnkgdG8gaGF2ZSBhIGRpZmZlcmVudA0KcHNldW9ub2RlIG5pY2tuYW1lIGlm IHRoZSB1cGxsbmsgaXMgdG8gZGlmZmVyZW50IHNldHMgb2YgUkJyaWRnZXM6PC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5JZiBoeXBlcnZpc29yIEgxIGhh cyB1cGxpbmtzIHRvIFIxLA0KUjIsIGFuZCBSMywgYW5kIHVzZXMgcHNldWRvbm9kZSBuaWNrbmFt ZSBQMSwgYW5kIGh5cGVydmlzb3IgSDIgaGFzIHVwbGlua3MNCnRvIFIxIGFuZCBSMiAob3IgZXZl biBoYWQgdXBsaW5rcyB0byBSMSwgUjIsIGFuZCBSMywgYnV0IGl0cyBsaW5rIHRvIFIzDQpmYWls cyksIHRoZW4gaWYgSDEgYW5kIEgyIHVzZSB0aGUgc2FtZSBuaWNrbmFtZSwgc2F5IFAxLCB0aGVu IHRyYWZmaWMgZm9yDQpIMidzIE1BQyBhZGRyZXNzZXMgbWlnaHQgZ2V0IHNlbnQgdG8gUjMgKHNp bmNlIFIzIGhhcyB0byBjbGFpbSB0byBiZSBjb25uZWN0ZWQNCnRvIFAxIGJlY2F1c2UgaXQgaXMs IGZvciBIMSkuICZuYnNwO0J1dCBpdCBpcyBubyBsb25nZXIgYXR0YWNoZWQgdG8gSDINCmJlY2F1 c2UgSDIncyB1cGxpbmsgdG8gUjMgZmFpbGVkLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXpl PTMgZmFjZT0ic2Fucy1zZXJpZiI+VGhlIHNhZmVzdCB0aGluZyB3b3VsZCBiZSBmb3IgZXZlcnkN Cmh5cGVydmlzb3IgdG8gaGF2ZSBhIG5pY2tuYW1lLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+U28sIGhvdyBtYW55IGh5cGVydmlzb3JzIGFyZSB0aGVy ZSBsaWtlbHkNCnRvIGJlPyAmbmJzcDtIb3cgdXN1YWwgd291bGQgaXQgYmUgZm9yIGFsbCBvZiB0 aGVtIHRvIGF0dGFjaCB0byB0aGUgc2FtZQ0Kc2V0IG9mIHVwbGlua3MsIHNvIHRoYXQgd2UgY2Fu IHVzZSB0aGUgc2FtZSBwc2V1b2Rub2RlIG5pY2tuYW1lPyAmbmJzcDtEbw0Kd2UgY2FyZSBhYm91 dCB0aGUgY2FzZSBvZiBvbmUgb2YgYSBoeXBlcnZpc29yJ3MgdXBsaW5rcyBmYWlsaW5nLCBpbiB3 aGljaA0KY2FzZSwgd291bGQgdGhlIFJCcmlkZ2VzIGtub3c/ICZuYnNwO0lmIFIzICh0aGUgb25l IHRvIHdoaWNoIHRoZSB1cGxpbmsNCmZhaWxlZCkga25vdz8gJm5ic3A7V291bGQgUjEgYW5kIFIy IGtub3c/ICZuYnNwO0V2ZW4gaWYgUjMga25ldywgaG93IGNvdWxkDQppdCBhbGVydCBSMSBhbmQg UjIgdG8gbm93IHVzZSBhIGRpZmZlcmVudCBwc2V1ZG9ub2RlIG5pY2tuYW1lIGZvciBIMj8gJm5i c3A7V291bGQNCml0IGJlIG9idmlvdXMgdG8gdGhlbSB3aGljaCBvZiB0aGUgaHlwZXJ2aXNvcnMg dGhhdCBoYXZlIHVwbGlua3MgdG8gUjEsDQpSMiwgYW5kIFIzIHRoZXkgYXJlIHJlZmVycmluZyB0 bz88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPkFsbCBv ZiB0aGlzIG11c3QgYmUgY29uZmlndXJlZCwgSSBhc3N1bWUsDQphbmQgaWYgdGhlIGNvbmZpZ3Vy YXRpb24gaXMgd3JvbmcsIHRoZW4gd2hvIGtub3dzIHdoYXQgaGFwcGVucy4ucHJlc3VtYWJseQ0K dGhhdCB0cmFmZmljIG1heSBvciBtYXkgbm90IGdldCBkZWxpdmVyZWQgdG8gYSBoeXBlcnZpc29y LiAmbmJzcDtBbmQgZXZlbg0KaWYgY29uZmlndXJlZCBwcm9wZXJseSwgd2hhdCBoYXBwZW5zIHdo ZW4gdXBsaW5rcyBmYWlsPyAmbmJzcDtBZ2FpbiwgcHJlc3VtYWJseSwNCnRyYWZmaWMgbWF5IG9y IG1heSBub3QgZ2V0IGRlbGl2ZXJlZCB0byB0aGUgaHlwZXJ2aXNvciB3aG9zZSB1cGxpbmsgZmFp bHMuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4tLS0t LS0tLS0tLS0tPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5BcyBm b3IgVkxBTnMuLi50aGF0IGFjdHVhbGx5IGlzIG5vdA0KYSBwcm9ibGVtIGhlcmUsIHNpbmNlIHdl J3JlIG5vdCB1c2luZyBBRnMuICZuYnNwO1RoZSBoeXBlcnZpc29yIGRldGVybWluZXMNCndoaWNo IHVwbGluayB0byBzZW5kIHNvbWV0aGluZyB0by4gJm5ic3A7QW5kIHdoaWNoIHRyZWUgaXMgYmVp bmcgdXNlZCBmb3INCmRpc3RyaWJ1dGlvbiBkZXRlcm1pbmVzIHdoaWNoIG9mIFIxLCBSMiwgb3Ig UjMgd2lsbCBkZWNhcHN1bGF0ZSB0aGUgcGFja2V0LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+U28gdGhlIG1haW4gc29ydCBvZiBjb25maWd1cmF0aW9u IHRoYXQNCkkgY2FuIHRoaW5rIG9mLCBvZmYgdGhlIHRvcCBvZiBteSBoZWFkLCBpcyB3aGljaCBw c2V1ZG9ub2RlcyBnbyB3aXRoIHdoaWNoDQpoeXBlcnZpc29ycy4gJm5ic3A7QW5kIEkgZG8gdGhp bmsgY29uZmlndXJhdGlvbiBpcyBzY2FyeSwgZXNwZWNpYWxseSBpZg0KdGhlcmUncyBubyAmcXVv dDtzYW5pdHkgY2hlY2smcXVvdDsgd2hlcmVieSB0aGUgUkJzIGNhbiBjb21wYXJlIG5vdGVzLg0K Jm5ic3A7SSBkb24ndCBrbm93IGhvdyBSMSBjYW4ga25vdyB0aGF0IGEgcGFydGljdWxhciBwb3J0 IGlzIHRvICZxdW90O0gxJnF1b3Q7DQpzbyB0aGF0IGl0IGNhbiBpbmZvcm0gUjIgKHZpYSBMU1Bz PykgdGhhdCBSMSBpcyBhdHRhY2hlZCB0byBIMSwgYW5kIFIyDQpjYW4gbm90aWNlIHRoYXQgaXQs IGluZGVlZCwgaXMgYWxzbyBhdHRhY2hlZCB0byBIMS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPi0tLS0tLS0tPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MyBmYWNlPSJzYW5zLXNlcmlmIj5BbmQgcGFydCBvZiB0aGUgZGVzY3JpcHRpb24gb2YgdGhlIHBy b2JsZW0NCndvdWxkIGJlIGFuc3dlcmluZyBxdWVzdGlvbnMgbGlrZSBob3cgbWFueSB1cGxpbmtz IHdvdWxkIG5lZWQgdG8gYmUgc3VwcG9ydGVkLg0KJm5ic3A7VHdvIGF0IG1vc3Q/ICZuYnNwOzMw PyAmbmJzcDtJZiBhIGxvdCwgdGhlbiBzb2x1dGlvbnMgdGhhdCByZXF1aXJlDQphIHRyZWUgZm9y IGV2ZXJ5IHVwbGluayB3b3VsZCBiZSBwcm9ibGVtYXRpYyBpZiBpbXBsZW1lbnRhdGlvbnMgZG9u J3Qgd2FudA0KdG8gc3VwcG9ydCB0aGF0IG1hbnkgdHJlZXMuICZuYnNwO09yIGlzIGl0IE9LIHRv IHJlcXVpcmUgbG90cyBvZiB0cmVlcz88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZh Y2U9InNhbnMtc2VyaWYiPlNvIEkgdGhpbmsgdGhlcmUgYXJlIGxvdHMgb2YgdGhpbmdzDQp0aGF0 IHNob3VsZCBiZSB3cml0dGVuIGRvd24sIGFzIHBhcnQgb2YgZGVzY3JpYmluZyB0aGUgcHJvYmxl bS48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMt c2VyaWYiPlJhZGlhPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5PbiBUaHUsIERlYyAxMywgMjAxMiBhdCA0OjAz IEFNLCAmbHQ7PC9mb250PjxhIGhyZWY9bWFpbHRvOnpoYWkuaG9uZ2p1bkB6dGUuY29tLmNuIHRh cmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+ emhhaS5ob25nanVuQHp0ZS5jb20uY248L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0i c2Fucy1zZXJpZiI+Jmd0Ow0Kd3JvdGU6PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJz YW5zLXNlcmlmIj48YnI+DQpIaSBSYWRpYSA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9 InNhbnMtc2VyaWYiPjxicj4NCiZndDsgVGhpcyBjYXNlIGlzIHNjYXJ5IGJlY2F1c2UgdGhlIFJC cmlkZ2VzIG9uIHRoZSB1cGxpbmsgY2Fubm90IHNlZSBIZWxsb3MNCmZyb20gZWFjaCBvdGhlciwg PGJyPg0KJmd0OyBzbyBpZiBtaXNjb25maWd1cmVkLCBhdCB0aGUgdmVyeSBsZWFzdCBJIGNvdWxk IGltYWdpbmUgbXVsdGlwbGUgUkJyaWRnZXMNCmRlY2Fwc3VsYXRpbmcgPGJyPg0KJmd0OyBtdWx0 aWNhc3QgZnJvbSB0aGUgY2FtcHVzIHRvIHRoZSBoeXBlcnZpc29yLiA8YnI+DQo8YnI+DQomZ3Q7 IEFueXdheS4uLmhvdyBtYW55IHVwbGlua3MgZG8gd2UgbmVlZCB0byBzdXBwb3J0PyAmbmJzcDtE byB3ZSBjYXJlDQphYm91dCBwcm9ibGVtcyBkdWUgdG8gbWlzY29uZmlndXJhdGlvbj8gPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpJIGRvbid0IGtub3cg d2hhdCB0aGUgbWlzY29uZmlndXJhdGlvbiByZWZlcnMgdG8uIElzIGl0IHRoZSBzZXQgb2YgVkxB TnMNCmZvciB3aGljaCBhbiBSYnJpZGdlIGFjdHMgYXMgQUY/IDwvZm9udD4NCjxicj48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KJmd0OyBBcmUgdGhlcmUgY2FzZXMg d2hlcmUgdGhlcmUgYXJlIGxvdHMgb2YgaHlwZXJ2aXNvcnMsIHdoZXJlIHRoZXkgYXR0YWNoDQp0 byBkaWZmZXJlbnQgc3Vic2V0cyBvZiBlZGdlIFJCcz8gJm5ic3A7IDxicj4NCiZndDsgSW4gdGhh dCBjYXNlLCB3ZSBtaWdodCBlYXQgdXAgYSBsb3Qgb2Ygbmlja25hbWVzLCBzaW5jZSBpZiBvbmUg aHlwZXJ2aXNvcg0KaXMgYXR0YWNoZWQgdG8ge1IxLCBSMn0sIDxicj4NCiZndDsgYW5kIGFub3Ro ZXIgaXMgYXR0YWNoZWQgdG8ge1IxLCBSMiwgUjN9LCB0aGV5IGNhbm5vdCB1c2UgdGhlIHNhbWUN CnBzZXVkb25vZGUgbmlja25hbWUuIDxicj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+SSBkb24ndCBrbm93IHdoeSB0aGUgdHdvIHNldHMgb2YgUkJyaWRnZXMN CmNhbiBub3QgdXNlIHRoZSBzYW1lIHBzZXVkby1uaWNrbmFtZS4gSWYgdGhlIGxlYXJuZWQgTUFD IGFkZHJlc3NlcyA8YnI+DQpjYW4gYmUgc2hhcmVkIGFtb25nIG1lbWJlciBSYnJpZGdlcyBvZiBh biBSQnYgYW5kIFRSSUxMIGRhdGEgZnJhbWVzIGNhbg0KYmUgdHVubmVsZWQgdG8gYW5vdGhlciBt ZW1iZXIgUmJyaWRnZSA8YnI+DQp0aGF0IGNhbiBlZ3Jlc3MgdGhlIGZyYW1lLCBJIHRoaW5rIHRo ZXkgY2FuIHVzZSB0aGUgc2FtZSBwc2V1ZG8tbmlja25hbWUuDQo8YnI+DQo8YnI+DQpJZiBJIGFt IHdyb25nLCBwbGVhc2UgY29ycmVjdCBtZS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9 InNhbnMtc2VyaWYiPjxicj4NCjxicj4NCkJlc3QgUmVnYXJkcyw8YnI+DQpaaGFpIEhvbmdqdW48 YnI+DQomcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDs8YnI+DQpQcm90b2NvbCBEZXZlbG9wbWVudCBEZXB0 LlZJLCBDZW50cmFsIFImYW1wO0QgSW5zdGl0dXRlLCBaVEUgQ29ycG9yYXRpb248YnI+DQpOby4g NjgsIFppamluZ2h1YSBSb2FkLCBZdWh1YXRhaSBEaXN0cmljdCwgTmFuamluZywgUC5SLkNoaW5h LCAyMTAwMTI8YnI+DQo8YnI+DQpaaGFpIEhvbmdqdW48YnI+DQo8YnI+DQpUZWw6IDwvZm9udD48 YSBocmVmPSJ0ZWw6JTJCODYtMjUtNTI4NzczNDUiIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0z IGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+Kzg2LTI1LTUyODc3MzQ1PC91PjwvZm9u dD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkVtYWlsOiA8L2ZvbnQ+ PGEgaHJlZj1tYWlsdG86emhhaS5ob25nanVuQHp0ZS5jb20uY24gdGFyZ2V0PV9ibGFuaz48Zm9u dCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT56aGFpLmhvbmdqdW5AenRl LmNvbS5jbjwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+ DQomcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDs8YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjxicj4NCjwvZm9udD4NCjxwPg0KPHRhYmxlIHdp ZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0yMyU+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPjxiPlJhZGlhIFBlcmxtYW4gJmx0OzwvYj48L2ZvbnQ+PGEgaHJlZj1t YWlsdG86cmFkaWFwZXJsbWFuQGdtYWlsLmNvbSB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MSBj b2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjxiPjx1PnJhZGlhcGVybG1hbkBnbWFpbC5jb208 L3U+PC9iPjwvZm9udD48L2E+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPiZndDs8 L2I+DQo8YnI+DQq3orz+yMs6ICZuYnNwOzwvZm9udD48YSBocmVmPSJtYWlsdG86dHJpbGwtYm91 bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNl PSJzYW5zLXNlcmlmIj48dT50cmlsbC1ib3VuY2VzQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZv bnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPjIwMTItMTItMTMgMTU6MTM8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPHRkIHdpZHRoPTc2JT4NCjxicj4NCjx0YWJsZSB3aWR0 aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MyU+DQo8ZGl2IGFsaWduPXJpZ2h0 Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQg d2lkdGg9OTYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5NaW5ndWkgWmhhbmcgJmx0 OzwvZm9udD48YSBocmVmPW1haWx0bzp6aGFuZ21pbmd1aUBodWF3ZWkuY29tIHRhcmdldD1fYmxh bms+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+emhhbmdtaW5n dWlAaHVhd2VpLmNvbTwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij4mZ3Q7PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjx0 ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+VGhvbWFzIE5hcnRlbiAmbHQ7PC9mb250PjxhIGhyZWY9bWFpbHRvOm5hcnRlbkB1 cy5pYm0uY29tIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0ic2Fu cy1zZXJpZiI+PHU+bmFydGVuQHVzLmlibS5jb208L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+Jmd0OywNClNhbSBBbGRyaW4gJmx0OzwvZm9udD48YSBocmVmPW1h aWx0bzphbGRyaW4uaWV0ZkBnbWFpbC5jb20gdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTEgY29s b3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5hbGRyaW4uaWV0ZkBnbWFpbC5jb208L3U+PC9m b250PjwvYT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0OywNCiZxdW90O1Rpc3Nh IFNlbmV2aXJhdGhuZSBcKHRzZW5ldmlyXCkmcXVvdDsgJmx0OzwvZm9udD48YSBocmVmPW1haWx0 bzp0c2VuZXZpckBjaXNjby5jb20gdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTEgY29sb3I9Ymx1 ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT50c2VuZXZpckBjaXNjby5jb208L3U+PC9mb250PjwvYT48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0OywNCiZxdW90OzwvZm9udD48YSBocmVm PW1haWx0bzp0cmlsbEBpZXRmLm9yZyB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MSBjb2xvcj1i bHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1PnRyaWxsQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90Ow0KJmx0OzwvZm9udD48YSBocmVmPW1h aWx0bzp0cmlsbEBpZXRmLm9yZyB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MSBjb2xvcj1ibHVl IGZhY2U9InNhbnMtc2VyaWYiPjx1PnRyaWxsQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZndDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPg0KPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJp Z2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRk Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogW3RyaWxsXSBUaG91Z2h0cyBvbiBh Y3RpdmUtYWN0aXZlDQplZGdlPC9mb250PjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lk dGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTUwJT4NCjx0ZCB3aWR0aD01MCU+ PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlm Ij48YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4N CkkgdGhpbmsgaXQgd291bGQgYmUgZ29vZCB0byBoYXZlIGEgZG9jdW1lbnQgdGhhdCBleHBsYWlu cyB0aGUgcHJvYmxlbS4uLkkNCmNlcnRhaW5seSBkb24ndCBiZWxpZXZlIEkga25vdyBhbGwgdGhl IGNhc2VzIHRoYXQgbmVlZCB0byBiZSBzb2x2ZWQuICZuYnNwO0kNCnRoaW5rIEkgdW5kZXJzdGFu ZCB0aGUgaHlwZXJ2aXNvciBjYXNlLi4ud2hlcmUgdGhlIGh5cGVydmlzb3IgZGVjaWRlcyB3aGlj aA0KdXBsaW5rIHRvIHNlbmQgdGhpbmdzIHRvLCBhbmQgbmV2ZXIgZm9yd2FyZHMgYmV0d2VlbiB0 aGUgdXAtbGlua3MuIDxicj4NCjxicj4NClRoaXMgY2FzZSBpcyBzY2FyeSBiZWNhdXNlIHRoZSBS QnJpZGdlcyBvbiB0aGUgdXBsaW5rIGNhbm5vdCBzZWUgSGVsbG9zDQpmcm9tIGVhY2ggb3RoZXIs IHNvIGlmIG1pc2NvbmZpZ3VyZWQsIGF0IHRoZSB2ZXJ5IGxlYXN0IEkgY291bGQgaW1hZ2luZQ0K bXVsdGlwbGUgUkJyaWRnZXMgZGVjYXBzdWxhdGluZyBtdWx0aWNhc3QgZnJvbSB0aGUgY2FtcHVz IHRvIHRoZSBoeXBlcnZpc29yLg0KPGJyPg0KPGJyPg0KQW55d2F5Li4uaG93IG1hbnkgdXBsaW5r cyBkbyB3ZSBuZWVkIHRvIHN1cHBvcnQ/ICZuYnNwO0RvIHdlIGNhcmUgYWJvdXQNCnByb2JsZW1z IGR1ZSB0byBtaXNjb25maWd1cmF0aW9uPyA8YnI+DQo8YnI+DQpJbiBjYXNlcyBsaWtlIHRoaXMs IGlzIGl0IGNvbW1vbiB0byBhbHNvIGhhdmUgcHQtdG8tcHQgbGlua3MgYmV0d2VlbiBhbGwNCnRo ZSBSQnMgYXR0YWNoaW5nIHRvIHRoZSBoeXBlcnZpc29yPyAmbmJzcDtJZiBzbywgdGhlbiBpdCBz ZWVtcyBsaWtlIGl0DQp3b3VsZCBiZSBwb3NzaWJsZSBmb3IgdGhlbSB0byBjb29yZGluYXRlIHRv IGF0IGxlYXN0IGRldGVjdCBtaXNjb25maWd1cmF0aW9uLA0KYW5kIHBvc3NpYmx5IHBsYXkgZ2Ft ZXMgd2l0aCBmb3J3YXJkaW5nIG1lc3NhZ2VzIHRvIGVhY2ggb3RoZXIgKGUuZy4sIGlmDQpvbmUg b2YgdGhlbSBpcyBub3QgYXR0YWNoZWQgdG8gYSB0cmVlIGFuZCBuZWVkcyB0byBlbmNhcHN1bGF0 ZSBhIG11bHRpZGVzdGluYXRpb24NCmZyYW1lKS4gPGJyPg0KPGJyPg0KSG93IG1hbnkgdHJlZXMg ZG9lcyB0aGUgY2FtcHVzIG5lZWQ/IDxicj4NCjxicj4NCkFyZSB0aGVyZSBjYXNlcyB3aGVyZSB0 aGVyZSBhcmUgbG90cyBvZiBoeXBlcnZpc29ycywgd2hlcmUgdGhleSBhdHRhY2gNCnRvIGRpZmZl cmVudCBzdWJzZXRzIG9mIGVkZ2UgUkJzPyAmbmJzcDtJbiB0aGF0IGNhc2UsIHdlIG1pZ2h0IGVh dCB1cCBhDQpsb3Qgb2Ygbmlja25hbWVzLCBzaW5jZSBpZiBvbmUgaHlwZXJ2aXNvciBpcyBhdHRh Y2hlZCB0byB7UjEsIFIyfSwgYW5kDQphbm90aGVyIGlzIGF0dGFjaGVkIHRvIHtSMSwgUjIsIFIz fSwgdGhleSBjYW5ub3QgdXNlIHRoZSBzYW1lIHBzZXVkb25vZGUNCm5pY2tuYW1lLiA8YnI+DQo8 YnI+DQpBcmUgdGhlcmUgY2FzZXMgb3RoZXIgdGhhbiBoeXBlcnZpc29ycz8gJm5ic3A7SSB0aGlu ayB0aGVyZSBhcmUgY2FzZXMgb2YNCmJyaWRnZXMgdGhhdCBoYXZlIHRoaXMgYmVoYXZpb3IgKGEg cG9ydCB3aXRoIGEgYnVuY2ggb2YgZW5kbm9kZXMsIGFuZCBzZXZlcmFsDQp1cC1saW5rcywgd2hl cmUgdGhlIGJyaWRnZSBkb2VzIG5vdCBmb3J3YXJkIGJldHdlZW4gdGhlIHVwLWxpbmtzLiAmbmJz cDsNCjxicj4NCjxicj4NCklmIHRoaXMgaGFzIGJlZW4gd3JpdHRlbiBkb3duIGFueXdoZXJlLCBj YW4gYW55b25lIHBvaW50IG1lIHRvIGl0PyAmbmJzcDtJZg0Kbm90LCBpdCBzZWVtcyByZWFsbHkg cHJ1ZGVudCB0byBhbnN3ZXIgdGhlc2UgKGFuZCBJJ20gc3VyZSBvdGhlcikgcXVlc3Rpb25zDQpi ZWZvcmUgYXJndWluZyBhYm91dCBzcGVjaWZpYyBzb2x1dGlvbnMuIDxicj4NCjxicj4NClJhZGlh IDxicj4NCjwvZm9udD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0zPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KdHJpbGwgbWFpbGluZyBsaXN0PC9mb250 PjwvdHQ+PHR0Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx1Pjxicj4NCjwvdT48L2ZvbnQ+PC90 dD48YSBocmVmPW1haWx0bzp0cmlsbEBpZXRmLm9yZyB0YXJnZXQ9X2JsYW5rPjx0dD48Zm9udCBz aXplPTMgY29sb3I9Ymx1ZT48dT50cmlsbEBpZXRmLm9yZzwvdT48L2ZvbnQ+PC90dD48L2E+PHR0 Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx1Pjxicj4NCjwvdT48L2ZvbnQ+PC90dD48YSBocmVm PWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJpbGwgdGFyZ2V0PV9ibGFu az48dHQ+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby90cmlsbDwvdT48L2ZvbnQ+PC90dD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9 InNhbnMtc2VyaWYiPjxicj4NCjwvZm9udD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KdHJpbGwgbWFpbGlu ZyBsaXN0PGJyPg0KdHJpbGxAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3RyaWxsPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+PC9kaXY+DQo= --=_alternative 00124CC648257AD4_=-- From zhai.hongjun@zte.com.cn Thu Dec 13 19:33:33 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA0C21F8849; Thu, 13 Dec 2012 19:33:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.399 X-Spam-Level: X-Spam-Status: No, score=-96.399 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, J_CHICKENPOX_83=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100, WEIRD_QUOTING=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0N-KvKZkVctk; Thu, 13 Dec 2012 19:33:32 -0800 (PST) Received: from zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 63F7A21F87B3; Thu, 13 Dec 2012 19:33:31 -0800 (PST) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 7F3F613236; Fri, 14 Dec 2012 11:33:20 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id BF84272537F; Fri, 14 Dec 2012 11:22:29 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id qBE3XEAV029443; Fri, 14 Dec 2012 11:33:14 +0800 (GMT-8) (envelope-from zhai.hongjun@zte.com.cn) In-Reply-To: To: hu.fangwei@zte.com.cn MIME-Version: 1.0 X-KeepSent: 9AA48005:287A265A-48257AD4:00127A93; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhai.hongjun@zte.com.cn Date: Fri, 14 Dec 2012 11:33:11 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-12-14 11:33:07, Serialize complete at 2012-12-14 11:33:07 Content-Type: multipart/alternative; boundary="=_alternative 0013C33E48257AD4_=" X-MAIL: mse01.zte.com.cn qBE3XEAV029443 Cc: Thomas Narten , trill-bounces@ietf.org, Radia Perlman , Sam Aldrin , Mingui Zhang , "trill@ietf.org" , "Tissa Senevirathne \(tsenevir\)" Subject: Re: [trill] Thoughts on active-active edge X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 03:33:33 -0000 This is a multipart message in MIME format. --=_alternative 0013C33E48257AD4_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 PiBTbyBwc2V1ZG9ub2RlIG5pY2tuYW1lIGlzIG5vdCBmaXQgZm9yIGFjdGl2ZS1hY3RpdmUgZWRn ZS4NCg0KTWF5YmUgSSBuZWVkIHRvIGNsYXJpZnkgd2hhdCB0aGUgcHNldWRvLW5pY2tuYW1lIGlz IGluIFBOIGRyYWZ0LiANCg0KUHNldWRvLW5pY2tuYW1lIGlzIGEgbmlja25hbWUgdGhhdCBpZGVu dGlmaWVzIGEgZ3JvdXAgb2YgUmJyaWRnZXMoZS5nLCBhIA0KUkJ2KSwgbm90IGEgcHNldWRvbm9k ZS4NCkFuZCB0aGlzIG5pY2tuYW1lIGlzIGFkdmVydGlzZWQgaW4gZWFjaCBtZW1iZXIgUkJyaWRn ZSdzIExTUCwgbm90IGl0J3MgDQpwc2V1ZG9ub2RlIExTUC4NCkZ1cnRob3Jtb3JlLCB0aGVyZSBp cyBubyBtZW1iZXIgUkJyaWRnZSBvcmlnaW5hdGVzIHBzZXVkb25vZGUgTFNQcyBpbiANCmFjdGl2 ZS1hY3RpdmUgZWRnZSwNCnNpbmNlIHRoZXkgY2FuIHNlZSBlYWNoIG90aGVyJ3MgaGVsbG9zLg0K DQpJZiBwc2V1ZG8tbmlja25hbWUgY29uZnVzZXMgc29tZSBvbmUgaW4gdGhpcyBXRywgd2UgY2Fu IGNoYW5nZSBpdCB0byANClJCdi1uaWNrbmFtZS4NCg0KDQpCZXN0IFJlZ2FyZHMsDQpaaGFpIEhv bmdqdW4NCiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIi IiIiIiIiIiIiIiIiIiIiIiIiIiINCiBQcm90b2NvbCBEZXZlbG9wbWVudCBEZXB0LlZJLCBDZW50 cmFsIFImRCBJbnN0aXR1dGUsIFpURSBDb3Jwb3JhdGlvbg0KIE5vLiA2OCwgWmlqaW5naHVhIFJv YWQsIFl1aHVhdGFpIERpc3RyaWN0LCBOYW5qaW5nLCBQLlIuQ2hpbmEsIDIxMDAxMg0KIA0KIFpo YWkgSG9uZ2p1bg0KIA0KIFRlbDogKzg2LTI1LTUyODc3MzQ1DQogRW1haWw6IHpoYWkuaG9uZ2p1 bkB6dGUuY29tLmNuDQoiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIi IiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIg0KDQoNCg0KDQoNCrr6t73OsDE3NTc3Mi91c2Vy L3p0ZV9sdGQNCjIwMTItMTItMTQgMTA6MzENCg0KytW8/sjLDQpSYWRpYSBQZXJsbWFuIDxyYWRp YXBlcmxtYW5AZ21haWwuY29tPg0Ks63LzQ0KU2FtIEFsZHJpbiA8YWxkcmluLmlldGZAZ21haWwu Y29tPiwgVGhvbWFzIE5hcnRlbiA8bmFydGVuQHVzLmlibS5jb20+LCANCiJ0cmlsbEBpZXRmLm9y ZyIgPHRyaWxsQGlldGYub3JnPiwgdHJpbGwtYm91bmNlc0BpZXRmLm9yZywgIlRpc3NhIA0KU2Vu ZXZpcmF0aG5lIFwodHNlbmV2aXJcKSIgPHRzZW5ldmlyQGNpc2NvLmNvbT4sIHpoYWkuaG9uZ2p1 bkB6dGUuY29tLmNuLCANCk1pbmd1aSBaaGFuZyA8emhhbmdtaW5ndWlAaHVhd2VpLmNvbT4NCtb3 zOINClJlOiBSZTogW3RyaWxsXSBUaG91Z2h0cyBvbiBhY3RpdmUtYWN0aXZlIGVkZ2UNCg0KDQoN Cg0KDQoNCg0KVGhlcmUgaXMgb25seSBvbmUgUkJyaWRnZSh0aGF0IGlzIEFGKSB0byBkbyB0aGUg VFJJTEwgZW5jYXB1c2xhdGlvbiBpbiB0aGUgDQpzaGFyZWQgTEFOIGxpbmsgc2NlbmFyaW8uU28g d2UgY2FuIGludHJvZHVjZSB0aGUgcHNldWRvbm9kZSBuaWNrbmFtZSB0byANCmlkZW50eSB0aGUg c2hhcmVkIGxpbmssIGFuZCBhdm9pZCB0aGUgcG90ZW50aWFsIGRhdGEgbG9zcyB3aGVuIEFGIGNo YW5nZWQuIA0KV2hpbGUgaXQgaXMgZGlmZmVyZW50IGZvciB0aGUgYWN0aXZlLWFjdGl2ZSBlZGdl IHNjZW5hcmlvOiBhbGwgdGhlIA0KUkJyaWRnZXMgaW4gdGhlIExBRy1ncm91cCBzaG91bGQgZG8g dGhlIFRSSUxMIGVuY2Fwc3VsYXRpb24sIGFuZCB0aGUgDQpSQnJpZGdlIGNhbm5vdCBzZWUgSGVs bG9zIGZyb20gZWFjaCBvdGhlciwgdGhlcmUgaXMgbm8gQUYgaW4gdGhpcyBjYXNlIA0KYWN0dWFs bHkuIFNvIHBzZXVkb25vZGUgbmlja25hbWUgaXMgbm90IGZpdCBmb3IgYWN0aXZlLWFjdGl2ZSBl ZGdlLiANCg0KV2UgY291bGQgdXNlIHRoZSBjb250cm9sIHByb3RvY29sKGZvciBleGFtcGxlLCBF U0FESSApdG8gbGVhcm4gdGhlIE1BQyBhbmQgDQpuaWNrbmFtZSwgYW5kIGF2b2lkIHRoZSBNQUMg ZmxpcCBieSBhZGRpbmcgYSBuZXcgSUQobGluay1JRCkuIElmIHRoZSANCnJlbW90ZSByZWNlaXZl cyB0d28gcmVjb3JkcyB3aXRoIHRoZSBzYW1lIExpbmstSUQsaXQgc2hvdWxkIHRoaW5rIGJvdGgg b2YgDQp0aGVtIGFyZSBPay4gDQoNCiBSMSBhbmQgUjIgdGVsbCBSOCB0aGF0IEgxIGlzIG11bHRp LWhvbWluZyB0byB0aGUgdHJpbGwgY2FtcHVzLCB0aGV5IHVzZSANCnRoZSBzYW1lIExpbmstSUQg dG8gaWRlbnRpZnkgdGhlIExBRy1ncm91cC4gV2hlbiBSOCByZWNlaXZlcyB0aGUgDQppbmZvcm1h dGlvbiwgaXQga2VlcHMgdHdvIHJlY29yZHMgZm9yIEgxLCBvbmUgaXMgUjEsIGFuZCB0aGUgb3Ro ZXIgaXMgUjIuIA0KVGhlIGJhY2sgZGF0YSBmcmFtZSBjb3VsZCBjaG9pY2UgZWl0aGVyIFIxIG9y IFIyIGFzIHRoZSBlZ3Jlc3Mgbmlja25hbWUuIA0KDQpJZiB0aGUgbGluayBiZXR3ZWVuIEgxIGFu ZCBSMiBmYWlscywgdGhlIHJlY29yZCBSMiBpcyBjbGVhci4gDQoNCklmIHRoZXJlIGlzIGFub3Ro ZXIgbGluayBmb3IgSDEsIHNheSBSMywgYW5kIFIzIHVzZXMgdGhlIHNhbWUgbGluay1pZCwgc28g DQpSOCBrZWVwcyBhbm90aGVyIHJlY29yZCBmb3IgSDEuIA0KDQpCZXN0IHJlZ2FyZHMuIA0KDQoN Cg0KUmFkaWEgUGVybG1hbiA8cmFkaWFwZXJsbWFuQGdtYWlsLmNvbT4gDQq3orz+yMs6ICB0cmls bC1ib3VuY2VzQGlldGYub3JnIA0KMjAxMi0xMi0xNCAwMjoxMCANCg0KDQrK1bz+yMsNCnpoYWku aG9uZ2p1bkB6dGUuY29tLmNuIA0Ks63LzQ0KVGhvbWFzIE5hcnRlbiA8bmFydGVuQHVzLmlibS5j b20+LCB0cmlsbC1ib3VuY2VzQGlldGYub3JnLCBTYW0gQWxkcmluIA0KPGFsZHJpbi5pZXRmQGdt YWlsLmNvbT4sIE1pbmd1aSBaaGFuZyA8emhhbmdtaW5ndWlAaHVhd2VpLmNvbT4sIA0KInRyaWxs QGlldGYub3JnIiA8dHJpbGxAaWV0Zi5vcmc+LCAiVGlzc2EgU2VuZXZpcmF0aG5lIFwodHNlbmV2 aXJcKSIgDQo8dHNlbmV2aXJAY2lzY28uY29tPiANCtb3zOINClJlOiBbdHJpbGxdIFRob3VnaHRz IG9uIGFjdGl2ZS1hY3RpdmUgZWRnZQ0KDQoNCg0KDQoNCg0KDQoNCkFuc3dlcmluZyBaaGFpIEhv bmdqdW4ncyBxdWVzdGlvbnM6IA0KDQpXaHkgaXQgaXMgbmVjZXNzYXJ5IHRvIGhhdmUgYSBkaWZm ZXJlbnQgcHNldW9ub2RlIG5pY2tuYW1lIGlmIHRoZSB1cGxsbmsgDQppcyB0byBkaWZmZXJlbnQg c2V0cyBvZiBSQnJpZGdlczogDQoNCklmIGh5cGVydmlzb3IgSDEgaGFzIHVwbGlua3MgdG8gUjEs IFIyLCBhbmQgUjMsIGFuZCB1c2VzIHBzZXVkb25vZGUgDQpuaWNrbmFtZSBQMSwgYW5kIGh5cGVy dmlzb3IgSDIgaGFzIHVwbGlua3MgdG8gUjEgYW5kIFIyIChvciBldmVuIGhhZCANCnVwbGlua3Mg dG8gUjEsIFIyLCBhbmQgUjMsIGJ1dCBpdHMgbGluayB0byBSMyBmYWlscyksIHRoZW4gaWYgSDEg YW5kIEgyIA0KdXNlIHRoZSBzYW1lIG5pY2tuYW1lLCBzYXkgUDEsIHRoZW4gdHJhZmZpYyBmb3Ig SDIncyBNQUMgYWRkcmVzc2VzIG1pZ2h0IA0KZ2V0IHNlbnQgdG8gUjMgKHNpbmNlIFIzIGhhcyB0 byBjbGFpbSB0byBiZSBjb25uZWN0ZWQgdG8gUDEgYmVjYXVzZSBpdCBpcywgDQpmb3IgSDEpLiAg QnV0IGl0IGlzIG5vIGxvbmdlciBhdHRhY2hlZCB0byBIMiBiZWNhdXNlIEgyJ3MgdXBsaW5rIHRv IFIzIA0KZmFpbGVkLiANCg0KVGhlIHNhZmVzdCB0aGluZyB3b3VsZCBiZSBmb3IgZXZlcnkgaHlw ZXJ2aXNvciB0byBoYXZlIGEgbmlja25hbWUuIA0KDQpTbywgaG93IG1hbnkgaHlwZXJ2aXNvcnMg YXJlIHRoZXJlIGxpa2VseSB0byBiZT8gIEhvdyB1c3VhbCB3b3VsZCBpdCBiZSANCmZvciBhbGwg b2YgdGhlbSB0byBhdHRhY2ggdG8gdGhlIHNhbWUgc2V0IG9mIHVwbGlua3MsIHNvIHRoYXQgd2Ug Y2FuIHVzZSANCnRoZSBzYW1lIHBzZXVvZG5vZGUgbmlja25hbWU/ICBEbyB3ZSBjYXJlIGFib3V0 IHRoZSBjYXNlIG9mIG9uZSBvZiBhIA0KaHlwZXJ2aXNvcidzIHVwbGlua3MgZmFpbGluZywgaW4g d2hpY2ggY2FzZSwgd291bGQgdGhlIFJCcmlkZ2VzIGtub3c/ICBJZiANClIzICh0aGUgb25lIHRv IHdoaWNoIHRoZSB1cGxpbmsgZmFpbGVkKSBrbm93PyAgV291bGQgUjEgYW5kIFIyIGtub3c/ICBF dmVuIA0KaWYgUjMga25ldywgaG93IGNvdWxkIGl0IGFsZXJ0IFIxIGFuZCBSMiB0byBub3cgdXNl IGEgZGlmZmVyZW50IHBzZXVkb25vZGUgDQpuaWNrbmFtZSBmb3IgSDI/ICBXb3VsZCBpdCBiZSBv YnZpb3VzIHRvIHRoZW0gd2hpY2ggb2YgdGhlIGh5cGVydmlzb3JzIA0KdGhhdCBoYXZlIHVwbGlu a3MgdG8gUjEsIFIyLCBhbmQgUjMgdGhleSBhcmUgcmVmZXJyaW5nIHRvPyANCg0KQWxsIG9mIHRo aXMgbXVzdCBiZSBjb25maWd1cmVkLCBJIGFzc3VtZSwgYW5kIGlmIHRoZSBjb25maWd1cmF0aW9u IGlzIA0Kd3JvbmcsIHRoZW4gd2hvIGtub3dzIHdoYXQgaGFwcGVucy4ucHJlc3VtYWJseSB0aGF0 IHRyYWZmaWMgbWF5IG9yIG1heSBub3QgDQpnZXQgZGVsaXZlcmVkIHRvIGEgaHlwZXJ2aXNvci4g IEFuZCBldmVuIGlmIGNvbmZpZ3VyZWQgcHJvcGVybHksIHdoYXQgDQpoYXBwZW5zIHdoZW4gdXBs aW5rcyBmYWlsPyAgQWdhaW4sIHByZXN1bWFibHksIHRyYWZmaWMgbWF5IG9yIG1heSBub3QgZ2V0 IA0KZGVsaXZlcmVkIHRvIHRoZSBoeXBlcnZpc29yIHdob3NlIHVwbGluayBmYWlscy4gDQoNCi0t LS0tLS0tLS0tLS0gDQpBcyBmb3IgVkxBTnMuLi50aGF0IGFjdHVhbGx5IGlzIG5vdCBhIHByb2Js ZW0gaGVyZSwgc2luY2Ugd2UncmUgbm90IHVzaW5nIA0KQUZzLiAgVGhlIGh5cGVydmlzb3IgZGV0 ZXJtaW5lcyB3aGljaCB1cGxpbmsgdG8gc2VuZCBzb21ldGhpbmcgdG8uICBBbmQgDQp3aGljaCB0 cmVlIGlzIGJlaW5nIHVzZWQgZm9yIGRpc3RyaWJ1dGlvbiBkZXRlcm1pbmVzIHdoaWNoIG9mIFIx LCBSMiwgb3IgDQpSMyB3aWxsIGRlY2Fwc3VsYXRlIHRoZSBwYWNrZXQuIA0KDQpTbyB0aGUgbWFp biBzb3J0IG9mIGNvbmZpZ3VyYXRpb24gdGhhdCBJIGNhbiB0aGluayBvZiwgb2ZmIHRoZSB0b3Ag b2YgbXkgDQpoZWFkLCBpcyB3aGljaCBwc2V1ZG9ub2RlcyBnbyB3aXRoIHdoaWNoIGh5cGVydmlz b3JzLiAgQW5kIEkgZG8gdGhpbmsgDQpjb25maWd1cmF0aW9uIGlzIHNjYXJ5LCBlc3BlY2lhbGx5 IGlmIHRoZXJlJ3Mgbm8gInNhbml0eSBjaGVjayIgd2hlcmVieSANCnRoZSBSQnMgY2FuIGNvbXBh cmUgbm90ZXMuICBJIGRvbid0IGtub3cgaG93IFIxIGNhbiBrbm93IHRoYXQgYSBwYXJ0aWN1bGFy IA0KcG9ydCBpcyB0byAiSDEiIHNvIHRoYXQgaXQgY2FuIGluZm9ybSBSMiAodmlhIExTUHM/KSB0 aGF0IFIxIGlzIGF0dGFjaGVkIA0KdG8gSDEsIGFuZCBSMiBjYW4gbm90aWNlIHRoYXQgaXQsIGlu ZGVlZCwgaXMgYWxzbyBhdHRhY2hlZCB0byBIMS4gDQoNCi0tLS0tLS0tIA0KQW5kIHBhcnQgb2Yg dGhlIGRlc2NyaXB0aW9uIG9mIHRoZSBwcm9ibGVtIHdvdWxkIGJlIGFuc3dlcmluZyBxdWVzdGlv bnMgDQpsaWtlIGhvdyBtYW55IHVwbGlua3Mgd291bGQgbmVlZCB0byBiZSBzdXBwb3J0ZWQuICBU d28gYXQgbW9zdD8gIDMwPyAgSWYgYSANCmxvdCwgdGhlbiBzb2x1dGlvbnMgdGhhdCByZXF1aXJl IGEgdHJlZSBmb3IgZXZlcnkgdXBsaW5rIHdvdWxkIGJlIA0KcHJvYmxlbWF0aWMgaWYgaW1wbGVt ZW50YXRpb25zIGRvbid0IHdhbnQgdG8gc3VwcG9ydCB0aGF0IG1hbnkgdHJlZXMuICBPciANCmlz IGl0IE9LIHRvIHJlcXVpcmUgbG90cyBvZiB0cmVlcz8gDQoNClNvIEkgdGhpbmsgdGhlcmUgYXJl IGxvdHMgb2YgdGhpbmdzIHRoYXQgc2hvdWxkIGJlIHdyaXR0ZW4gZG93biwgYXMgcGFydCANCm9m IGRlc2NyaWJpbmcgdGhlIHByb2JsZW0uIA0KDQoNCg0KUmFkaWEgDQoNCg0KDQoNCg0KT24gVGh1 LCBEZWMgMTMsIDIwMTIgYXQgNDowMyBBTSwgPHpoYWkuaG9uZ2p1bkB6dGUuY29tLmNuPiB3cm90 ZTogDQoNCkhpIFJhZGlhIA0KDQo+IFRoaXMgY2FzZSBpcyBzY2FyeSBiZWNhdXNlIHRoZSBSQnJp ZGdlcyBvbiB0aGUgdXBsaW5rIGNhbm5vdCBzZWUgSGVsbG9zIA0KZnJvbSBlYWNoIG90aGVyLCAN Cj4gc28gaWYgbWlzY29uZmlndXJlZCwgYXQgdGhlIHZlcnkgbGVhc3QgSSBjb3VsZCBpbWFnaW5l IG11bHRpcGxlIFJCcmlkZ2VzIA0KZGVjYXBzdWxhdGluZyANCj4gbXVsdGljYXN0IGZyb20gdGhl IGNhbXB1cyB0byB0aGUgaHlwZXJ2aXNvci4gDQoNCj4gQW55d2F5Li4uaG93IG1hbnkgdXBsaW5r cyBkbyB3ZSBuZWVkIHRvIHN1cHBvcnQ/ICBEbyB3ZSBjYXJlIGFib3V0IA0KcHJvYmxlbXMgZHVl IHRvIG1pc2NvbmZpZ3VyYXRpb24/IA0KDQpJIGRvbid0IGtub3cgd2hhdCB0aGUgbWlzY29uZmln dXJhdGlvbiByZWZlcnMgdG8uIElzIGl0IHRoZSBzZXQgb2YgVkxBTnMgDQpmb3Igd2hpY2ggYW4g UmJyaWRnZSBhY3RzIGFzIEFGPyANCg0KDQo+IEFyZSB0aGVyZSBjYXNlcyB3aGVyZSB0aGVyZSBh cmUgbG90cyBvZiBoeXBlcnZpc29ycywgd2hlcmUgdGhleSBhdHRhY2ggDQp0byBkaWZmZXJlbnQg c3Vic2V0cyBvZiBlZGdlIFJCcz8gDQo+IEluIHRoYXQgY2FzZSwgd2UgbWlnaHQgZWF0IHVwIGEg bG90IG9mIG5pY2tuYW1lcywgc2luY2UgaWYgb25lIA0KaHlwZXJ2aXNvciBpcyBhdHRhY2hlZCB0 byB7UjEsIFIyfSwgDQo+IGFuZCBhbm90aGVyIGlzIGF0dGFjaGVkIHRvIHtSMSwgUjIsIFIzfSwg dGhleSBjYW5ub3QgdXNlIHRoZSBzYW1lIA0KcHNldWRvbm9kZSBuaWNrbmFtZS4gDQoNCkkgZG9u J3Qga25vdyB3aHkgdGhlIHR3byBzZXRzIG9mIFJCcmlkZ2VzIGNhbiBub3QgdXNlIHRoZSBzYW1l IA0KcHNldWRvLW5pY2tuYW1lLiBJZiB0aGUgbGVhcm5lZCBNQUMgYWRkcmVzc2VzIA0KY2FuIGJl IHNoYXJlZCBhbW9uZyBtZW1iZXIgUmJyaWRnZXMgb2YgYW4gUkJ2IGFuZCBUUklMTCBkYXRhIGZy YW1lcyBjYW4gYmUgDQp0dW5uZWxlZCB0byBhbm90aGVyIG1lbWJlciBSYnJpZGdlIA0KdGhhdCBj YW4gZWdyZXNzIHRoZSBmcmFtZSwgSSB0aGluayB0aGV5IGNhbiB1c2UgdGhlIHNhbWUgcHNldWRv LW5pY2tuYW1lLiANCg0KSWYgSSBhbSB3cm9uZywgcGxlYXNlIGNvcnJlY3QgbWUuIA0KDQoNCkJl c3QgUmVnYXJkcywNClpoYWkgSG9uZ2p1bg0KIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIi IiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIg0KUHJvdG9jb2wgRGV2ZWxv cG1lbnQgRGVwdC5WSSwgQ2VudHJhbCBSJkQgSW5zdGl0dXRlLCBaVEUgQ29ycG9yYXRpb24NCk5v LiA2OCwgWmlqaW5naHVhIFJvYWQsIFl1aHVhdGFpIERpc3RyaWN0LCBOYW5qaW5nLCBQLlIuQ2hp bmEsIDIxMDAxMg0KDQpaaGFpIEhvbmdqdW4NCg0KVGVsOiArODYtMjUtNTI4NzczNDUNCkVtYWls OiB6aGFpLmhvbmdqdW5AenRlLmNvbS5jbg0KIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIi IiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiINCg0KDQoNCg0KUmFkaWEg UGVybG1hbiA8cmFkaWFwZXJsbWFuQGdtYWlsLmNvbT4gDQq3orz+yMs6ICB0cmlsbC1ib3VuY2Vz QGlldGYub3JnIA0KMjAxMi0xMi0xMyAxNToxMyANCg0KDQrK1bz+yMsNCk1pbmd1aSBaaGFuZyA8 emhhbmdtaW5ndWlAaHVhd2VpLmNvbT4gDQqzrcvNDQpUaG9tYXMgTmFydGVuIDxuYXJ0ZW5AdXMu aWJtLmNvbT4sIFNhbSBBbGRyaW4gPGFsZHJpbi5pZXRmQGdtYWlsLmNvbT4sIA0KIlRpc3NhIFNl bmV2aXJhdGhuZSBcKHRzZW5ldmlyXCkiIDx0c2VuZXZpckBjaXNjby5jb20+LCAidHJpbGxAaWV0 Zi5vcmciIDwNCnRyaWxsQGlldGYub3JnPiANCtb3zOINClJlOiBbdHJpbGxdIFRob3VnaHRzIG9u IGFjdGl2ZS1hY3RpdmUgZWRnZQ0KDQoNCg0KDQoNCg0KDQoNCg0KDQpJIHRoaW5rIGl0IHdvdWxk IGJlIGdvb2QgdG8gaGF2ZSBhIGRvY3VtZW50IHRoYXQgZXhwbGFpbnMgdGhlIHByb2JsZW0uLi5J IA0KY2VydGFpbmx5IGRvbid0IGJlbGlldmUgSSBrbm93IGFsbCB0aGUgY2FzZXMgdGhhdCBuZWVk IHRvIGJlIHNvbHZlZC4gIEkgDQp0aGluayBJIHVuZGVyc3RhbmQgdGhlIGh5cGVydmlzb3IgY2Fz ZS4uLndoZXJlIHRoZSBoeXBlcnZpc29yIGRlY2lkZXMgDQp3aGljaCB1cGxpbmsgdG8gc2VuZCB0 aGluZ3MgdG8sIGFuZCBuZXZlciBmb3J3YXJkcyBiZXR3ZWVuIHRoZSB1cC1saW5rcy4gDQoNClRo aXMgY2FzZSBpcyBzY2FyeSBiZWNhdXNlIHRoZSBSQnJpZGdlcyBvbiB0aGUgdXBsaW5rIGNhbm5v dCBzZWUgSGVsbG9zIA0KZnJvbSBlYWNoIG90aGVyLCBzbyBpZiBtaXNjb25maWd1cmVkLCBhdCB0 aGUgdmVyeSBsZWFzdCBJIGNvdWxkIGltYWdpbmUgDQptdWx0aXBsZSBSQnJpZGdlcyBkZWNhcHN1 bGF0aW5nIG11bHRpY2FzdCBmcm9tIHRoZSBjYW1wdXMgdG8gdGhlIA0KaHlwZXJ2aXNvci4gDQoN CkFueXdheS4uLmhvdyBtYW55IHVwbGlua3MgZG8gd2UgbmVlZCB0byBzdXBwb3J0PyAgRG8gd2Ug Y2FyZSBhYm91dCANCnByb2JsZW1zIGR1ZSB0byBtaXNjb25maWd1cmF0aW9uPyANCg0KSW4gY2Fz ZXMgbGlrZSB0aGlzLCBpcyBpdCBjb21tb24gdG8gYWxzbyBoYXZlIHB0LXRvLXB0IGxpbmtzIGJl dHdlZW4gYWxsIA0KdGhlIFJCcyBhdHRhY2hpbmcgdG8gdGhlIGh5cGVydmlzb3I/ICBJZiBzbywg dGhlbiBpdCBzZWVtcyBsaWtlIGl0IHdvdWxkIA0KYmUgcG9zc2libGUgZm9yIHRoZW0gdG8gY29v cmRpbmF0ZSB0byBhdCBsZWFzdCBkZXRlY3QgbWlzY29uZmlndXJhdGlvbiwgDQphbmQgcG9zc2li bHkgcGxheSBnYW1lcyB3aXRoIGZvcndhcmRpbmcgbWVzc2FnZXMgdG8gZWFjaCBvdGhlciAoZS5n LiwgaWYgDQpvbmUgb2YgdGhlbSBpcyBub3QgYXR0YWNoZWQgdG8gYSB0cmVlIGFuZCBuZWVkcyB0 byBlbmNhcHN1bGF0ZSBhIA0KbXVsdGlkZXN0aW5hdGlvbiBmcmFtZSkuIA0KDQpIb3cgbWFueSB0 cmVlcyBkb2VzIHRoZSBjYW1wdXMgbmVlZD8gDQoNCkFyZSB0aGVyZSBjYXNlcyB3aGVyZSB0aGVy ZSBhcmUgbG90cyBvZiBoeXBlcnZpc29ycywgd2hlcmUgdGhleSBhdHRhY2ggdG8gDQpkaWZmZXJl bnQgc3Vic2V0cyBvZiBlZGdlIFJCcz8gIEluIHRoYXQgY2FzZSwgd2UgbWlnaHQgZWF0IHVwIGEg bG90IG9mIA0Kbmlja25hbWVzLCBzaW5jZSBpZiBvbmUgaHlwZXJ2aXNvciBpcyBhdHRhY2hlZCB0 byB7UjEsIFIyfSwgYW5kIGFub3RoZXIgaXMgDQphdHRhY2hlZCB0byB7UjEsIFIyLCBSM30sIHRo ZXkgY2Fubm90IHVzZSB0aGUgc2FtZSBwc2V1ZG9ub2RlIG5pY2tuYW1lLiANCg0KQXJlIHRoZXJl IGNhc2VzIG90aGVyIHRoYW4gaHlwZXJ2aXNvcnM/ICBJIHRoaW5rIHRoZXJlIGFyZSBjYXNlcyBv ZiANCmJyaWRnZXMgdGhhdCBoYXZlIHRoaXMgYmVoYXZpb3IgKGEgcG9ydCB3aXRoIGEgYnVuY2gg b2YgZW5kbm9kZXMsIGFuZCANCnNldmVyYWwgdXAtbGlua3MsIHdoZXJlIHRoZSBicmlkZ2UgZG9l cyBub3QgZm9yd2FyZCBiZXR3ZWVuIHRoZSB1cC1saW5rcy4gIA0KDQoNCklmIHRoaXMgaGFzIGJl ZW4gd3JpdHRlbiBkb3duIGFueXdoZXJlLCBjYW4gYW55b25lIHBvaW50IG1lIHRvIGl0PyAgSWYg DQpub3QsIGl0IHNlZW1zIHJlYWxseSBwcnVkZW50IHRvIGFuc3dlciB0aGVzZSAoYW5kIEknbSBz dXJlIG90aGVyKSANCnF1ZXN0aW9ucyBiZWZvcmUgYXJndWluZyBhYm91dCBzcGVjaWZpYyBzb2x1 dGlvbnMuIA0KDQpSYWRpYSANCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCnRyaWxsIG1haWxpbmcgbGlzdA0KdHJpbGxAaWV0Zi5vcmcNCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJpbGwNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnRyaWxsIG1haWxpbmcgbGlzdA0KdHJpbGxA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJpbGwNCg0K DQo= --=_alternative 0013C33E48257AD4_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZndDsgU28gcHNldWRvbm9kZSBu aWNrbmFtZSBpcyBub3QgZml0DQpmb3IgYWN0aXZlLWFjdGl2ZSBlZGdlLjwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+TWF5YmUgSSBuZWVkIHRvIGNsYXJp Znkgd2hhdCB0aGUgcHNldWRvLW5pY2tuYW1lDQppcyBpbiBQTiBkcmFmdC4gPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5Qc2V1ZG8tbmlja25hbWUgaXMg YSBuaWNrbmFtZSB0aGF0IGlkZW50aWZpZXMNCmEgZ3JvdXAgb2YgUmJyaWRnZXMoZS5nLCBhIFJC diksIG5vdCBhIHBzZXVkb25vZGUuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj5BbmQgdGhpcyBuaWNrbmFtZSBpcyBhZHZlcnRpc2VkIGluIGVhY2gNCm1lbWJlciBS QnJpZGdlJ3MgTFNQLCBub3QgaXQncyBwc2V1ZG9ub2RlIExTUC48L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkZ1cnRob3Jtb3JlLCB0aGVyZSBpcyBubyBtZW1iZXIg UkJyaWRnZQ0Kb3JpZ2luYXRlcyBwc2V1ZG9ub2RlIExTUHMgaW4gYWN0aXZlLWFjdGl2ZSBlZGdl LDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+c2luY2UgdGhleSBj YW4gc2VlIGVhY2ggb3RoZXIncyBoZWxsb3MuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj5JZiBwc2V1ZG8tbmlja25hbWUgY29uZnVzZXMgc29tZSBvbmUN CmluIHRoaXMgV0csIHdlIGNhbiBjaGFuZ2UgaXQgdG8gUkJ2LW5pY2tuYW1lLjxicj4NCjxicj4N Cjxicj4NCkJlc3QgUmVnYXJkcyw8YnI+DQpaaGFpIEhvbmdqdW48YnI+DQomcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDs8YnI+DQogUHJvdG9jb2wgRGV2ZWxvcG1lbnQgRGVwdC5WSSwgQ2VudHJhbCBSJmFt cDtEIEluc3RpdHV0ZSwgWlRFIENvcnBvcmF0aW9uPGJyPg0KIE5vLiA2OCwgWmlqaW5naHVhIFJv YWQsIFl1aHVhdGFpIERpc3RyaWN0LCBOYW5qaW5nLCBQLlIuQ2hpbmEsIDIxMDAxMjxicj4NCiA8 YnI+DQogWmhhaSBIb25nanVuPGJyPg0KIDxicj4NCiBUZWw6ICs4Ni0yNS01Mjg3NzM0NTxicj4N CiBFbWFpbDogemhhaS5ob25nanVuQHp0ZS5jb20uY248YnI+DQomcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsm cXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVvdDsmcXVv dDsmcXVvdDs8YnI+DQo8YnI+DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lk dGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTQwJT48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+PGI+uvq3vc6wMTc1NzcyL3VzZXIvenRlX2x0ZDwvYj48L2ZvbnQ+DQo8 cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMi0xMi0xNCAxMDozMTwvZm9udD4N Cjx0ZCB3aWR0aD01OSU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRk Pg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjL PC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SYWRpYSBQ ZXJsbWFuICZsdDtyYWRpYXBlcmxtYW5AZ21haWwuY29tJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249 dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ U2FtIEFsZHJpbiAmbHQ7YWxkcmluLmlldGZAZ21haWwuY29tJmd0OywNClRob21hcyBOYXJ0ZW4g Jmx0O25hcnRlbkB1cy5pYm0uY29tJmd0OywgJnF1b3Q7dHJpbGxAaWV0Zi5vcmcmcXVvdDsgJmx0 O3RyaWxsQGlldGYub3JnJmd0OywNCnRyaWxsLWJvdW5jZXNAaWV0Zi5vcmcsICZxdW90O1Rpc3Nh IFNlbmV2aXJhdGhuZSBcKHRzZW5ldmlyXCkmcXVvdDsgJmx0O3RzZW5ldmlyQGNpc2NvLmNvbSZn dDssDQp6aGFpLmhvbmdqdW5AenRlLmNvbS5jbiwgTWluZ3VpIFpoYW5nICZsdDt6aGFuZ21pbmd1 aUBodWF3ZWkuY29tJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGln bj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4N Cjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFJlOiBbdHJpbGxdIFRob3Vn aHRzIG9uIGFjdGl2ZS1hY3RpdmUNCmVkZ2U8L2ZvbnQ+PGEgaHJlZj1Ob3RlczovL05KTUFJTDA3 LzQ4MjU3NUU2MDAyRjQwNTkvRjY0MkYyRDE1MkZCNDVCMjQ4MjU2QzUyMDA0NDc4RDUvNEQ1QUQz MjVCNEU1MjlFRDQ4MjU3QUQzMDA2M0Q2N0I+wbS90zwvYT48L3RhYmxlPg0KPGJyPg0KPHRhYmxl Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJy Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpUaGVyZSBp cyBvbmx5IG9uZSBSQnJpZGdlKHRoYXQgaXMgQUYpIHRvIGRvIHRoZSBUUklMTCBlbmNhcHVzbGF0 aW9uIGluDQp0aGUgc2hhcmVkIExBTiBsaW5rIHNjZW5hcmlvLlNvIHdlIGNhbiBpbnRyb2R1Y2Ug dGhlIHBzZXVkb25vZGUgbmlja25hbWUNCnRvIGlkZW50eSB0aGUgc2hhcmVkIGxpbmssIGFuZCBh dm9pZCB0aGUgcG90ZW50aWFsIGRhdGEgbG9zcyB3aGVuIEFGIGNoYW5nZWQuDQpXaGlsZSBpdCBp cyBkaWZmZXJlbnQgZm9yIHRoZSBhY3RpdmUtYWN0aXZlIGVkZ2Ugc2NlbmFyaW86IGFsbCB0aGUg UkJyaWRnZXMNCmluIHRoZSBMQUctZ3JvdXAgc2hvdWxkIGRvIHRoZSBUUklMTCBlbmNhcHN1bGF0 aW9uLCBhbmQgdGhlIFJCcmlkZ2UgY2Fubm90DQpzZWUgSGVsbG9zIGZyb20gZWFjaCBvdGhlciwg dGhlcmUgaXMgbm8gQUYgaW4gdGhpcyBjYXNlIGFjdHVhbGx5LiBTbyBwc2V1ZG9ub2RlDQpuaWNr bmFtZSBpcyBub3QgZml0IGZvciBhY3RpdmUtYWN0aXZlIGVkZ2UuPC9mb250Pjxmb250IHNpemU9 MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+PGJyPg0KV2UgY291bGQgdXNlIHRoZSBjb250cm9sIHByb3RvY29sKGZvciBleGFt cGxlLCBFU0FESSApdG8gbGVhcm4gdGhlIE1BQw0KYW5kIG5pY2tuYW1lLCBhbmQgYXZvaWQgdGhl IE1BQyBmbGlwIGJ5IGFkZGluZyBhIG5ldyBJRChsaW5rLUlEKS4gSWYgdGhlDQpyZW1vdGUgcmVj ZWl2ZXMgdHdvIHJlY29yZHMgd2l0aCB0aGUgc2FtZSBMaW5rLUlELGl0IHNob3VsZCB0aGluayBi b3RoDQpvZiB0aGVtIGFyZSBPay4gPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlm Ij48YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCiBSMSBh bmQgUjIgdGVsbCBSOCB0aGF0IEgxIGlzIG11bHRpLWhvbWluZyB0byB0aGUgdHJpbGwgY2FtcHVz LCB0aGV5IHVzZQ0KdGhlIHNhbWUgTGluay1JRCB0byBpZGVudGlmeSB0aGUgTEFHLWdyb3VwLiBX aGVuIFI4IHJlY2VpdmVzIHRoZSBpbmZvcm1hdGlvbiwNCml0IGtlZXBzIHR3byByZWNvcmRzIGZv ciBIMSwgb25lIGlzIFIxLCBhbmQgdGhlIG90aGVyIGlzIFIyLiBUaGUgYmFjayBkYXRhDQpmcmFt ZSBjb3VsZCBjaG9pY2UgZWl0aGVyIFIxIG9yIFIyIGFzIHRoZSBlZ3Jlc3Mgbmlja25hbWUuPC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjxicj4NCjwvZm9udD48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KSWYgdGhlIGxpbmsgYmV0d2VlbiBIMSBhbmQg UjIgZmFpbHMsIHRoZSByZWNvcmQgUjIgaXMgY2xlYXIuPC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJzYW5zLXNlcmlmIj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+PGJyPg0KSWYgdGhlcmUgaXMgYW5vdGhlciBsaW5rIGZvciBIMSwgc2F5IFIzLCBhbmQgUjMg dXNlcyB0aGUgc2FtZSBsaW5rLWlkLA0Kc28gUjgga2VlcHMgYW5vdGhlciByZWNvcmQgZm9yIEgx LjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8YnI+DQo8L2ZvbnQ+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkJlc3QgcmVnYXJkcy48L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8YnI+DQo8YnI+DQo8YnI+DQo8L2ZvbnQ+DQo8 dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTE3JT48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+UmFkaWEgUGVybG1hbiAmbHQ7cmFkaWFwZXJsbWFu QGdtYWlsLmNvbSZndDs8L2I+DQo8YnI+DQq3orz+yMs6ICZuYnNwO3RyaWxsLWJvdW5jZXNAaWV0 Zi5vcmc8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPHA+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTItMTItMTQgMDI6MTA8L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPHRkIHdpZHRoPTgyJT4NCjxi cj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MyU+DQo8 ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2Zv bnQ+PC9kaXY+DQo8dGQgd2lkdGg9OTYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj56 aGFpLmhvbmdqdW5AenRlLmNvbS5jbjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJp ZiI+DQo8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlRob21hcyBOYXJ0ZW4gJmx0O25hcnRlbkB1cy5pYm0u Y29tJmd0OywNCnRyaWxsLWJvdW5jZXNAaWV0Zi5vcmcsIFNhbSBBbGRyaW4gJmx0O2FsZHJpbi5p ZXRmQGdtYWlsLmNvbSZndDssIE1pbmd1aQ0KWmhhbmcgJmx0O3poYW5nbWluZ3VpQGh1YXdlaS5j b20mZ3Q7LCAmcXVvdDt0cmlsbEBpZXRmLm9yZyZxdW90OyAmbHQ7dHJpbGxAaWV0Zi5vcmcmZ3Q7 LA0KJnF1b3Q7VGlzc2EgU2VuZXZpcmF0aG5lIFwodHNlbmV2aXJcKSZxdW90OyAmbHQ7dHNlbmV2 aXJAY2lzY28uY29tJmd0OzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8 L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPlJlOiBbdHJpbGxdIFRob3VnaHRzIG9uIGFjdGl2ZS1hY3RpdmUN CmVkZ2U8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRy IHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9NTAlPg0KPHRkIHdpZHRoPTUwJT48L3RhYmxlPg0KPGJy PjwvdGFibGU+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjxicj4N Cjxicj4NCkFuc3dlcmluZyBaaGFpIEhvbmdqdW4ncyBxdWVzdGlvbnM6IDxicj4NCjxicj4NCldo eSBpdCBpcyBuZWNlc3NhcnkgdG8gaGF2ZSBhIGRpZmZlcmVudCBwc2V1b25vZGUgbmlja25hbWUg aWYgdGhlIHVwbGxuaw0KaXMgdG8gZGlmZmVyZW50IHNldHMgb2YgUkJyaWRnZXM6IDxicj4NCjxi cj4NCklmIGh5cGVydmlzb3IgSDEgaGFzIHVwbGlua3MgdG8gUjEsIFIyLCBhbmQgUjMsIGFuZCB1 c2VzIHBzZXVkb25vZGUgbmlja25hbWUNClAxLCBhbmQgaHlwZXJ2aXNvciBIMiBoYXMgdXBsaW5r cyB0byBSMSBhbmQgUjIgKG9yIGV2ZW4gaGFkIHVwbGlua3MgdG8NClIxLCBSMiwgYW5kIFIzLCBi dXQgaXRzIGxpbmsgdG8gUjMgZmFpbHMpLCB0aGVuIGlmIEgxIGFuZCBIMiB1c2UgdGhlIHNhbWUN Cm5pY2tuYW1lLCBzYXkgUDEsIHRoZW4gdHJhZmZpYyBmb3IgSDIncyBNQUMgYWRkcmVzc2VzIG1p Z2h0IGdldCBzZW50IHRvDQpSMyAoc2luY2UgUjMgaGFzIHRvIGNsYWltIHRvIGJlIGNvbm5lY3Rl ZCB0byBQMSBiZWNhdXNlIGl0IGlzLCBmb3IgSDEpLg0KJm5ic3A7QnV0IGl0IGlzIG5vIGxvbmdl ciBhdHRhY2hlZCB0byBIMiBiZWNhdXNlIEgyJ3MgdXBsaW5rIHRvIFIzIGZhaWxlZC4NCjxicj4N Cjxicj4NClRoZSBzYWZlc3QgdGhpbmcgd291bGQgYmUgZm9yIGV2ZXJ5IGh5cGVydmlzb3IgdG8g aGF2ZSBhIG5pY2tuYW1lLiA8YnI+DQo8YnI+DQpTbywgaG93IG1hbnkgaHlwZXJ2aXNvcnMgYXJl IHRoZXJlIGxpa2VseSB0byBiZT8gJm5ic3A7SG93IHVzdWFsIHdvdWxkDQppdCBiZSBmb3IgYWxs IG9mIHRoZW0gdG8gYXR0YWNoIHRvIHRoZSBzYW1lIHNldCBvZiB1cGxpbmtzLCBzbyB0aGF0IHdl DQpjYW4gdXNlIHRoZSBzYW1lIHBzZXVvZG5vZGUgbmlja25hbWU/ICZuYnNwO0RvIHdlIGNhcmUg YWJvdXQgdGhlIGNhc2Ugb2YNCm9uZSBvZiBhIGh5cGVydmlzb3IncyB1cGxpbmtzIGZhaWxpbmcs IGluIHdoaWNoIGNhc2UsIHdvdWxkIHRoZSBSQnJpZGdlcw0Ka25vdz8gJm5ic3A7SWYgUjMgKHRo ZSBvbmUgdG8gd2hpY2ggdGhlIHVwbGluayBmYWlsZWQpIGtub3c/ICZuYnNwO1dvdWxkDQpSMSBh bmQgUjIga25vdz8gJm5ic3A7RXZlbiBpZiBSMyBrbmV3LCBob3cgY291bGQgaXQgYWxlcnQgUjEg YW5kIFIyIHRvDQpub3cgdXNlIGEgZGlmZmVyZW50IHBzZXVkb25vZGUgbmlja25hbWUgZm9yIEgy PyAmbmJzcDtXb3VsZCBpdCBiZSBvYnZpb3VzDQp0byB0aGVtIHdoaWNoIG9mIHRoZSBoeXBlcnZp c29ycyB0aGF0IGhhdmUgdXBsaW5rcyB0byBSMSwgUjIsIGFuZCBSMyB0aGV5DQphcmUgcmVmZXJy aW5nIHRvPyA8YnI+DQo8YnI+DQpBbGwgb2YgdGhpcyBtdXN0IGJlIGNvbmZpZ3VyZWQsIEkgYXNz dW1lLCBhbmQgaWYgdGhlIGNvbmZpZ3VyYXRpb24gaXMgd3JvbmcsDQp0aGVuIHdobyBrbm93cyB3 aGF0IGhhcHBlbnMuLnByZXN1bWFibHkgdGhhdCB0cmFmZmljIG1heSBvciBtYXkgbm90IGdldA0K ZGVsaXZlcmVkIHRvIGEgaHlwZXJ2aXNvci4gJm5ic3A7QW5kIGV2ZW4gaWYgY29uZmlndXJlZCBw cm9wZXJseSwgd2hhdA0KaGFwcGVucyB3aGVuIHVwbGlua3MgZmFpbD8gJm5ic3A7QWdhaW4sIHBy ZXN1bWFibHksIHRyYWZmaWMgbWF5IG9yIG1heQ0Kbm90IGdldCBkZWxpdmVyZWQgdG8gdGhlIGh5 cGVydmlzb3Igd2hvc2UgdXBsaW5rIGZhaWxzLiA8YnI+DQo8YnI+DQotLS0tLS0tLS0tLS0tIDxi cj4NCkFzIGZvciBWTEFOcy4uLnRoYXQgYWN0dWFsbHkgaXMgbm90IGEgcHJvYmxlbSBoZXJlLCBz aW5jZSB3ZSdyZSBub3QgdXNpbmcNCkFGcy4gJm5ic3A7VGhlIGh5cGVydmlzb3IgZGV0ZXJtaW5l cyB3aGljaCB1cGxpbmsgdG8gc2VuZCBzb21ldGhpbmcgdG8uDQombmJzcDtBbmQgd2hpY2ggdHJl ZSBpcyBiZWluZyB1c2VkIGZvciBkaXN0cmlidXRpb24gZGV0ZXJtaW5lcyB3aGljaCBvZg0KUjEs IFIyLCBvciBSMyB3aWxsIGRlY2Fwc3VsYXRlIHRoZSBwYWNrZXQuIDxicj4NCjxicj4NClNvIHRo ZSBtYWluIHNvcnQgb2YgY29uZmlndXJhdGlvbiB0aGF0IEkgY2FuIHRoaW5rIG9mLCBvZmYgdGhl IHRvcCBvZiBteQ0KaGVhZCwgaXMgd2hpY2ggcHNldWRvbm9kZXMgZ28gd2l0aCB3aGljaCBoeXBl cnZpc29ycy4gJm5ic3A7QW5kIEkgZG8gdGhpbmsNCmNvbmZpZ3VyYXRpb24gaXMgc2NhcnksIGVz cGVjaWFsbHkgaWYgdGhlcmUncyBubyAmcXVvdDtzYW5pdHkgY2hlY2smcXVvdDsNCndoZXJlYnkg dGhlIFJCcyBjYW4gY29tcGFyZSBub3Rlcy4gJm5ic3A7SSBkb24ndCBrbm93IGhvdyBSMSBjYW4g a25vdyB0aGF0DQphIHBhcnRpY3VsYXIgcG9ydCBpcyB0byAmcXVvdDtIMSZxdW90OyBzbyB0aGF0 IGl0IGNhbiBpbmZvcm0gUjIgKHZpYSBMU1BzPykNCnRoYXQgUjEgaXMgYXR0YWNoZWQgdG8gSDEs IGFuZCBSMiBjYW4gbm90aWNlIHRoYXQgaXQsIGluZGVlZCwgaXMgYWxzbyBhdHRhY2hlZA0KdG8g SDEuIDxicj4NCjxicj4NCi0tLS0tLS0tIDxicj4NCkFuZCBwYXJ0IG9mIHRoZSBkZXNjcmlwdGlv biBvZiB0aGUgcHJvYmxlbSB3b3VsZCBiZSBhbnN3ZXJpbmcgcXVlc3Rpb25zDQpsaWtlIGhvdyBt YW55IHVwbGlua3Mgd291bGQgbmVlZCB0byBiZSBzdXBwb3J0ZWQuICZuYnNwO1R3byBhdCBtb3N0 PyAmbmJzcDszMD8NCiZuYnNwO0lmIGEgbG90LCB0aGVuIHNvbHV0aW9ucyB0aGF0IHJlcXVpcmUg YSB0cmVlIGZvciBldmVyeSB1cGxpbmsgd291bGQNCmJlIHByb2JsZW1hdGljIGlmIGltcGxlbWVu dGF0aW9ucyBkb24ndCB3YW50IHRvIHN1cHBvcnQgdGhhdCBtYW55IHRyZWVzLg0KJm5ic3A7T3Ig aXMgaXQgT0sgdG8gcmVxdWlyZSBsb3RzIG9mIHRyZWVzPyA8YnI+DQo8YnI+DQpTbyBJIHRoaW5r IHRoZXJlIGFyZSBsb3RzIG9mIHRoaW5ncyB0aGF0IHNob3VsZCBiZSB3cml0dGVuIGRvd24sIGFz IHBhcnQNCm9mIGRlc2NyaWJpbmcgdGhlIHByb2JsZW0uIDxicj4NCjxicj4NCjxicj4NCjxicj4N ClJhZGlhIDxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCk9uIFRodSwgRGVjIDEz LCAyMDEyIGF0IDQ6MDMgQU0sICZsdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86emhhaS5ob25nanVu QHp0ZS5jb20uY24gdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJz YW5zLXNlcmlmIj48dT56aGFpLmhvbmdqdW5AenRlLmNvbS5jbjwvdT48L2ZvbnQ+PC9hPjxmb250 IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7DQp3cm90ZTogPGJyPg0KPGJyPg0KSGkgUmFk aWEgPGJyPg0KPGJyPg0KJmd0OyBUaGlzIGNhc2UgaXMgc2NhcnkgYmVjYXVzZSB0aGUgUkJyaWRn ZXMgb24gdGhlIHVwbGluayBjYW5ub3Qgc2VlIEhlbGxvcw0KZnJvbSBlYWNoIG90aGVyLCA8YnI+ DQomZ3Q7IHNvIGlmIG1pc2NvbmZpZ3VyZWQsIGF0IHRoZSB2ZXJ5IGxlYXN0IEkgY291bGQgaW1h Z2luZSBtdWx0aXBsZSBSQnJpZGdlcw0KZGVjYXBzdWxhdGluZyA8YnI+DQomZ3Q7IG11bHRpY2Fz dCBmcm9tIHRoZSBjYW1wdXMgdG8gdGhlIGh5cGVydmlzb3IuIDxicj4NCjxicj4NCiZndDsgQW55 d2F5Li4uaG93IG1hbnkgdXBsaW5rcyBkbyB3ZSBuZWVkIHRvIHN1cHBvcnQ/ICZuYnNwO0RvIHdl IGNhcmUNCmFib3V0IHByb2JsZW1zIGR1ZSB0byBtaXNjb25maWd1cmF0aW9uPyA8YnI+DQo8YnI+ DQpJIGRvbid0IGtub3cgd2hhdCB0aGUgbWlzY29uZmlndXJhdGlvbiByZWZlcnMgdG8uIElzIGl0 IHRoZSBzZXQgb2YgVkxBTnMNCmZvciB3aGljaCBhbiBSYnJpZGdlIGFjdHMgYXMgQUY/IDxicj4N Cjxicj4NCjxicj4NCiZndDsgQXJlIHRoZXJlIGNhc2VzIHdoZXJlIHRoZXJlIGFyZSBsb3RzIG9m IGh5cGVydmlzb3JzLCB3aGVyZSB0aGV5IGF0dGFjaA0KdG8gZGlmZmVyZW50IHN1YnNldHMgb2Yg ZWRnZSBSQnM/ICZuYnNwOyA8YnI+DQomZ3Q7IEluIHRoYXQgY2FzZSwgd2UgbWlnaHQgZWF0IHVw IGEgbG90IG9mIG5pY2tuYW1lcywgc2luY2UgaWYgb25lIGh5cGVydmlzb3INCmlzIGF0dGFjaGVk IHRvIHtSMSwgUjJ9LCA8YnI+DQomZ3Q7IGFuZCBhbm90aGVyIGlzIGF0dGFjaGVkIHRvIHtSMSwg UjIsIFIzfSwgdGhleSBjYW5ub3QgdXNlIHRoZSBzYW1lDQpwc2V1ZG9ub2RlIG5pY2tuYW1lLiA8 YnI+DQo8YnI+DQpJIGRvbid0IGtub3cgd2h5IHRoZSB0d28gc2V0cyBvZiBSQnJpZGdlcyBjYW4g bm90IHVzZSB0aGUgc2FtZSBwc2V1ZG8tbmlja25hbWUuDQpJZiB0aGUgbGVhcm5lZCBNQUMgYWRk cmVzc2VzIDxicj4NCmNhbiBiZSBzaGFyZWQgYW1vbmcgbWVtYmVyIFJicmlkZ2VzIG9mIGFuIFJC diBhbmQgVFJJTEwgZGF0YSBmcmFtZXMgY2FuDQpiZSB0dW5uZWxlZCB0byBhbm90aGVyIG1lbWJl ciBSYnJpZGdlIDxicj4NCnRoYXQgY2FuIGVncmVzcyB0aGUgZnJhbWUsIEkgdGhpbmsgdGhleSBj YW4gdXNlIHRoZSBzYW1lIHBzZXVkby1uaWNrbmFtZS4NCjxicj4NCjxicj4NCklmIEkgYW0gd3Jv bmcsIHBsZWFzZSBjb3JyZWN0IG1lLiA8YnI+DQo8YnI+DQo8YnI+DQpCZXN0IFJlZ2FyZHMsPGJy Pg0KWmhhaSBIb25nanVuPGJyPg0KJnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7 JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1 b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7 JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1 b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7 JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1 b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7 JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7PGJyPg0KUHJvdG9jb2wg RGV2ZWxvcG1lbnQgRGVwdC5WSSwgQ2VudHJhbCBSJmFtcDtEIEluc3RpdHV0ZSwgWlRFIENvcnBv cmF0aW9uPGJyPg0KTm8uIDY4LCBaaWppbmdodWEgUm9hZCwgWXVodWF0YWkgRGlzdHJpY3QsIE5h bmppbmcsIFAuUi5DaGluYSwgMjEwMDEyPGJyPg0KPGJyPg0KWmhhaSBIb25nanVuPGJyPg0KPGJy Pg0KVGVsOiA8L2ZvbnQ+PGEgaHJlZj0idGVsOiUyQjg2LTI1LTUyODc3MzQ1IiB0YXJnZXQ9X2Js YW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1Pis4Ni0yNS01 Mjg3NzM0NTwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+ DQpFbWFpbDogPC9mb250PjxhIGhyZWY9bWFpbHRvOnpoYWkuaG9uZ2p1bkB6dGUuY29tLmNuIHRh cmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+ emhhaS5ob25nanVuQHp0ZS5jb20uY248L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0i c2Fucy1zZXJpZiI+PGJyPg0KJnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1 b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7 JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1 b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7 JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1 b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7 JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1 b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7JnF1b3Q7PGJyPg0KPGJyPg0K PGJyPg0KPC9mb250Pg0KPHA+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0K PHRkIHdpZHRoPTIzJT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+UmFkaWEgUGVy bG1hbiAmbHQ7PC9iPjwvZm9udD48YSBocmVmPW1haWx0bzpyYWRpYXBlcmxtYW5AZ21haWwuY29t IHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+ PGI+PHU+cmFkaWFwZXJsbWFuQGdtYWlsLmNvbTwvdT48L2I+PC9mb250PjwvYT48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+Jmd0OzwvYj4NCjxicj4NCreivP7IyzogJm5ic3A7PC9m b250PjxhIGhyZWY9Im1haWx0bzp0cmlsbC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9X2JsYW5r Pjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1PnRyaWxsLWJvdW5j ZXNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMi0xMi0xMyAx NToxMzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8dGQg d2lkdGg9NzYlPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0 ZCB3aWR0aD0zJT4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZCB3aWR0aD05NiU+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPk1pbmd1aSBaaGFuZyAmbHQ7PC9mb250PjxhIGhyZWY9bWFpbHRvOnpoYW5n bWluZ3VpQGh1YXdlaS5jb20gdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBm YWNlPSJzYW5zLXNlcmlmIj48dT56aGFuZ21pbmd1aUBodWF3ZWkuY29tPC91PjwvZm9udD48L2E+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZndDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh Y2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFs aWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2 Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5UaG9tYXMgTmFydGVuICZsdDs8 L2ZvbnQ+PGEgaHJlZj1tYWlsdG86bmFydGVuQHVzLmlibS5jb20gdGFyZ2V0PV9ibGFuaz48Zm9u dCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5uYXJ0ZW5AdXMuaWJtLmNv bTwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7LA0KU2Ft IEFsZHJpbiAmbHQ7PC9mb250PjxhIGhyZWY9bWFpbHRvOmFsZHJpbi5pZXRmQGdtYWlsLmNvbSB0 YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1 PmFsZHJpbi5pZXRmQGdtYWlsLmNvbTwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj4mZ3Q7LA0KJnF1b3Q7VGlzc2EgU2VuZXZpcmF0aG5lIFwodHNlbmV2aXJcKSZx dW90OyAmbHQ7PC9mb250PjxhIGhyZWY9bWFpbHRvOnRzZW5ldmlyQGNpc2NvLmNvbSB0YXJnZXQ9 X2JsYW5rPjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1PnRzZW5l dmlyQGNpc2NvLmNvbTwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij4mZ3Q7LA0KJnF1b3Q7PC9mb250PjxhIGhyZWY9bWFpbHRvOnRyaWxsQGlldGYub3JnIHRhcmdl dD1fYmxhbms+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+dHJp bGxAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ JnF1b3Q7DQombHQ7PC9mb250PjxhIGhyZWY9bWFpbHRvOnRyaWxsQGlldGYub3JnIHRhcmdldD1f Ymxhbms+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+dHJpbGxA aWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0 OzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPlJlOiBbdHJpbGxdIFRob3VnaHRzIG9uIGFjdGl2ZS1hY3RpdmUNCmVkZ2U8L2ZvbnQ+PC90 YWJsZT4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPC9mb250Pg0K PGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD01MCU+ DQo8dGQgd2lkdGg9NTAlPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KSSB0aGluayBpdCB3b3Vs ZCBiZSBnb29kIHRvIGhhdmUgYSBkb2N1bWVudCB0aGF0IGV4cGxhaW5zIHRoZSBwcm9ibGVtLi4u SQ0KY2VydGFpbmx5IGRvbid0IGJlbGlldmUgSSBrbm93IGFsbCB0aGUgY2FzZXMgdGhhdCBuZWVk IHRvIGJlIHNvbHZlZC4gJm5ic3A7SQ0KdGhpbmsgSSB1bmRlcnN0YW5kIHRoZSBoeXBlcnZpc29y IGNhc2UuLi53aGVyZSB0aGUgaHlwZXJ2aXNvciBkZWNpZGVzIHdoaWNoDQp1cGxpbmsgdG8gc2Vu ZCB0aGluZ3MgdG8sIGFuZCBuZXZlciBmb3J3YXJkcyBiZXR3ZWVuIHRoZSB1cC1saW5rcy4gPGJy Pg0KPGJyPg0KVGhpcyBjYXNlIGlzIHNjYXJ5IGJlY2F1c2UgdGhlIFJCcmlkZ2VzIG9uIHRoZSB1 cGxpbmsgY2Fubm90IHNlZSBIZWxsb3MNCmZyb20gZWFjaCBvdGhlciwgc28gaWYgbWlzY29uZmln dXJlZCwgYXQgdGhlIHZlcnkgbGVhc3QgSSBjb3VsZCBpbWFnaW5lDQptdWx0aXBsZSBSQnJpZGdl cyBkZWNhcHN1bGF0aW5nIG11bHRpY2FzdCBmcm9tIHRoZSBjYW1wdXMgdG8gdGhlIGh5cGVydmlz b3IuDQo8YnI+DQo8YnI+DQpBbnl3YXkuLi5ob3cgbWFueSB1cGxpbmtzIGRvIHdlIG5lZWQgdG8g c3VwcG9ydD8gJm5ic3A7RG8gd2UgY2FyZSBhYm91dA0KcHJvYmxlbXMgZHVlIHRvIG1pc2NvbmZp Z3VyYXRpb24/IDxicj4NCjxicj4NCkluIGNhc2VzIGxpa2UgdGhpcywgaXMgaXQgY29tbW9uIHRv IGFsc28gaGF2ZSBwdC10by1wdCBsaW5rcyBiZXR3ZWVuIGFsbA0KdGhlIFJCcyBhdHRhY2hpbmcg dG8gdGhlIGh5cGVydmlzb3I/ICZuYnNwO0lmIHNvLCB0aGVuIGl0IHNlZW1zIGxpa2UgaXQNCndv dWxkIGJlIHBvc3NpYmxlIGZvciB0aGVtIHRvIGNvb3JkaW5hdGUgdG8gYXQgbGVhc3QgZGV0ZWN0 IG1pc2NvbmZpZ3VyYXRpb24sDQphbmQgcG9zc2libHkgcGxheSBnYW1lcyB3aXRoIGZvcndhcmRp bmcgbWVzc2FnZXMgdG8gZWFjaCBvdGhlciAoZS5nLiwgaWYNCm9uZSBvZiB0aGVtIGlzIG5vdCBh dHRhY2hlZCB0byBhIHRyZWUgYW5kIG5lZWRzIHRvIGVuY2Fwc3VsYXRlIGEgbXVsdGlkZXN0aW5h dGlvbg0KZnJhbWUpLiA8YnI+DQo8YnI+DQpIb3cgbWFueSB0cmVlcyBkb2VzIHRoZSBjYW1wdXMg bmVlZD8gPGJyPg0KPGJyPg0KQXJlIHRoZXJlIGNhc2VzIHdoZXJlIHRoZXJlIGFyZSBsb3RzIG9m IGh5cGVydmlzb3JzLCB3aGVyZSB0aGV5IGF0dGFjaA0KdG8gZGlmZmVyZW50IHN1YnNldHMgb2Yg ZWRnZSBSQnM/ICZuYnNwO0luIHRoYXQgY2FzZSwgd2UgbWlnaHQgZWF0IHVwIGENCmxvdCBvZiBu aWNrbmFtZXMsIHNpbmNlIGlmIG9uZSBoeXBlcnZpc29yIGlzIGF0dGFjaGVkIHRvIHtSMSwgUjJ9 LCBhbmQNCmFub3RoZXIgaXMgYXR0YWNoZWQgdG8ge1IxLCBSMiwgUjN9LCB0aGV5IGNhbm5vdCB1 c2UgdGhlIHNhbWUgcHNldWRvbm9kZQ0Kbmlja25hbWUuIDxicj4NCjxicj4NCkFyZSB0aGVyZSBj YXNlcyBvdGhlciB0aGFuIGh5cGVydmlzb3JzPyAmbmJzcDtJIHRoaW5rIHRoZXJlIGFyZSBjYXNl cyBvZg0KYnJpZGdlcyB0aGF0IGhhdmUgdGhpcyBiZWhhdmlvciAoYSBwb3J0IHdpdGggYSBidW5j aCBvZiBlbmRub2RlcywgYW5kIHNldmVyYWwNCnVwLWxpbmtzLCB3aGVyZSB0aGUgYnJpZGdlIGRv ZXMgbm90IGZvcndhcmQgYmV0d2VlbiB0aGUgdXAtbGlua3MuICZuYnNwOw0KPGJyPg0KPGJyPg0K SWYgdGhpcyBoYXMgYmVlbiB3cml0dGVuIGRvd24gYW55d2hlcmUsIGNhbiBhbnlvbmUgcG9pbnQg bWUgdG8gaXQ/ICZuYnNwO0lmDQpub3QsIGl0IHNlZW1zIHJlYWxseSBwcnVkZW50IHRvIGFuc3dl ciB0aGVzZSAoYW5kIEknbSBzdXJlIG90aGVyKSBxdWVzdGlvbnMNCmJlZm9yZSBhcmd1aW5nIGFi b3V0IHNwZWNpZmljIHNvbHV0aW9ucy4gPGJyPg0KPGJyPg0KUmFkaWEgPGJyPg0KPC9mb250Pjx0 dD48Zm9udCBzaXplPTM+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQp0cmlsbCBtYWlsaW5nIGxpc3Q8L2ZvbnQ+PC90dD48Zm9udCBzaXpl PTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT48YnI+DQo8L3U+PC9mb250PjxhIGhy ZWY9bWFpbHRvOnRyaWxsQGlldGYub3JnIHRhcmdldD1fYmxhbms+PHR0Pjxmb250IHNpemU9MyBj b2xvcj1ibHVlPjx1PnRyaWxsQGlldGYub3JnPC91PjwvZm9udD48L3R0PjwvYT48Zm9udCBzaXpl PTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT48YnI+DQo8L3U+PC9mb250PjxhIGhy ZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmlsbCB0YXJnZXQ9X2Js YW5rPjx0dD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dT5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3RyaWxsPC91PjwvZm9udD48L3R0PjwvYT48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+PGJyPg0KPC9mb250Pjx0dD48Zm9udCBzaXplPTI+PGJyPg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQp0cmlsbCBtYWls aW5nIGxpc3Q8YnI+DQp0cmlsbEBpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdHJpbGw8L2ZvbnQ+PC90dD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1z ZXJpZiI+PGJyPg0KPC9mb250Pg0KPGJyPg0K --=_alternative 0013C33E48257AD4_=-- From zhangmingui@huawei.com Fri Dec 14 00:12:21 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2BC21F8970 for ; Fri, 14 Dec 2012 00:12:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CyQ0YSrVtGuw for ; Fri, 14 Dec 2012 00:12:19 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 089A221F892A for ; Fri, 14 Dec 2012 00:12:18 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMM20292; Fri, 14 Dec 2012 08:12:14 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 14 Dec 2012 08:11:23 +0000 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 14 Dec 2012 16:12:13 +0800 Received: from SZXEML507-MBS.china.huawei.com ([169.254.7.234]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.01.0323.003; Fri, 14 Dec 2012 16:12:09 +0800 From: Mingui Zhang To: Radia Perlman Thread-Topic: [trill] Thoughts on active-active edge Thread-Index: AQHN1+GKKCdMCC4LGEWia3k7aW76oZgUHNiAgAAJBwCAAAMhAIAAh2BggABlRwCAAAI3AIAABGMAgAAmCoCAAPnwUP//kI4AgAIjPLA= Date: Fri, 14 Dec 2012 08:12:08 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E73213A2AB@SZXEML507-MBS.china.huawei.com> References: <4552F0907735844E9204A62BBDD325E732138B02@SZXEML507-MBS.china.huawei.com> <201212122025.qBCKPmM7013618@cichlid.raleigh.ibm.com> <0E430FEE-F2AD-4EA0-9E98-50762B563E9B@gmail.com> <201212122257.qBCMvdeW014734@cichlid.raleigh.ibm.com> <4552F0907735844E9204A62BBDD325E732139D5A@SZXEML507-MBS.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.185] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Thomas Narten , Sam Aldrin , "Tissa Senevirathne \(tsenevir\)" , "trill@ietf.org" Subject: Re: [trill] Thoughts on active-active edge X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 08:12:21 -0000 Hi Radia, >If this has been written down anywhere, can anyone point me to it? If not= , it >seems really prudent to answer these (and I'm sure other) questions before >arguing about specific solutions. I volunteer to compose that draft. There was a draft we once brought to the= TRILL site. (http://tools.ietf.org/id/draft-zhang-trill-aggregation-02.txt= ). However, it needs a big change. =20 I plan to remove all the staff about specific solutions and include issues = which were discussed on the list. Mingui From narten@us.ibm.com Fri Dec 14 07:17:51 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E86C21F86A9 for ; Fri, 14 Dec 2012 07:17:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFYSDR67QNmO for ; Fri, 14 Dec 2012 07:17:50 -0800 (PST) Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) by ietfa.amsl.com (Postfix) with ESMTP id AED9821F85C9 for ; Fri, 14 Dec 2012 07:17:49 -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 ; Fri, 14 Dec 2012 10:16:41 -0500 Received: from d01dlp02.pok.ibm.com (9.56.250.167) by e7.ny.us.ibm.com (192.168.1.107) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 14 Dec 2012 10:16:35 -0500 Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 1158C6E8201 for ; Fri, 14 Dec 2012 10:15:16 -0500 (EST) Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id qBEFFG1J25755828 for ; Fri, 14 Dec 2012 10:15:16 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id qBEFFF7n007854 for ; Fri, 14 Dec 2012 10:15:16 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-200-54.mts.ibm.com [9.65.200.54]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id qBEFFFXg007736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Dec 2012 10:15:15 -0500 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.5/8.12.5) with ESMTP id qBEFFDSW010845; Fri, 14 Dec 2012 10:15:13 -0500 Message-Id: <201212141515.qBEFFDSW010845@cichlid.raleigh.ibm.com> To: Jon Hudson In-reply-to: References: <201211192208.qAJM87O1007297@cichlid.raleigh.ibm.com> Comments: In-reply-to Jon Hudson message dated "Mon, 19 Nov 2012 22:23:35 -0800." Date: Fri, 14 Dec 2012 10:15:13 -0500 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12121415-5806-0000-0000-00001CFD4E0A Cc: "trill@ietf.org" Subject: Re: [trill] draft-ietf-trill-cmt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 15:17:51 -0000 Getting back to this thread, since it popped up in the active-active thread... Jon Hudson writes: > Just to add to what Donald said... > This is a case where the draft came out of a need that kept > appearing while discussing and trying to solve other challenges ( > like a/a host based connections). > As apposed to a "draft if search of a problem" this is really a case > of a draft providing a building block that by not existing would > prevent other solutions from coming forward. I like building blocks, but I do not like building blocks being defined outside of a clearly scoped and understood problem. I've seen too many so-called "building blocks" defined too early, without a clear understanding of what the real problem being solved is (i.e., what the customer *really* wants, and what the *real* constraints are, and what the *deployment* configuration will be, etc.). > Now as to the terminology. There is much confusion in the market and > with customers as to when something is or is not LAG. > One if of the limitations today of host based LAGs is that they have > to go to the same physical switch unless the target switch is part > if a proprietary MCT pair, and that the MCT group is itself only a > pair. > What many customers want (and is provided today by other proprietary > solutions) is N active links to N top of rack switches where the > initial common two configs would be two links to two TOR switches > from one host, or four active links from a host to four different > TOR switches. Right. And what does this have to do with TRILL? :-) Seriously, we need to separate out what part of the problem is a really a more generic 802.1 problem vs. one that is really a TRILL problem to solve. I don't have a good understanding of that in this case, based on what is written in the document. > This maybe a cause of the confusion caused by the document saying N > switches. And is part of the value since as you stated most MLAG > solutions are only in a pair, and subpar as a result. Seems to me that if the figure shows uplinks from one switch to N upstream switches, and that is not what MLAG actually does in practice today, then the figure is not showing a realistic problem/configuration. Thomas From narten@us.ibm.com Fri Dec 14 07:25:06 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23CCB21F880F for ; Fri, 14 Dec 2012 07:25:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blRVtLv-ElFY for ; Fri, 14 Dec 2012 07:25:04 -0800 (PST) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by ietfa.amsl.com (Postfix) with ESMTP id 0006921F8803 for ; Fri, 14 Dec 2012 07:25:03 -0800 (PST) Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 14 Dec 2012 10:22:57 -0500 Received: from d01dlp03.pok.ibm.com (9.56.250.168) by e9.ny.us.ibm.com (192.168.1.109) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 14 Dec 2012 10:22:50 -0500 Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id 6B5ACC900A8 for ; Fri, 14 Dec 2012 10:21:39 -0500 (EST) Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id qBEFLdcI341706 for ; Fri, 14 Dec 2012 10:21:39 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id qBEFLcNY018970 for ; Fri, 14 Dec 2012 10:21:39 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-200-54.mts.ibm.com [9.65.200.54]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id qBEFLbgw018894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Dec 2012 10:21:38 -0500 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.5/8.12.5) with ESMTP id qBEFHQoF010856; Fri, 14 Dec 2012 10:17:26 -0500 Message-Id: <201212141517.qBEFHQoF010856@cichlid.raleigh.ibm.com> To: "Pat Thaler" In-reply-to: References: <201211192208.qAJM87O1007297@cichlid.raleigh.ibm.com> Comments: In-reply-to "Pat Thaler" message dated "Wed, 21 Nov 2012 01:07:03 +0000." Date: Fri, 14 Dec 2012 10:17:26 -0500 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12121415-7182-0000-0000-000003CBB733 Cc: "trill@ietf.org" Subject: Re: [trill] draft-ietf-trill-cmt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 15:25:06 -0000 +1 to what Pat said. Thomas "Pat Thaler" writes: > Jon and Donald > I'm skeptical about a "building block" to use in future solutions in general and especially for link aggregation or teaming. It's a fairly difficult to generically make a group of bridges pretend to be a single bridge and one should start with an architecture for solution, IMO, rather than starting with pieces that you hope to pull into a future solution. > "A typical deployment scenario, depicted in Figure > 1, which may have either End Stations and/or Legacy bridges attached > to the RBridges. These Legacy devices typically are multi-homed to > several RBridges and treat all of the uplinks as a single Link > Aggregation (LAG) bundle [802.1AX]." > End stations support many forms of teaming so they don't "typically" use any one form. For instance, one is a bridge-independent form of active-active teaming where the end station load balances traffic to various links with different MAC addresses on each link. They generally can't treat links to separate bridges as a single 802.1AX LAG unless the bridges cooperate to support a proprietary multi-chassis LAG. > LAG is defined by 802.1AX and that term shouldn't be used for other mechanisms for using multiple links. It's better to use something else like "teaming" when one wants to include both 802.1AX and non-802.1AX mechanisms. The groupings identified as LAGs in Figure 1 will not be LAGs unless the bridges are presenting them as a single bridge to the end stations which isn't trivial to get right and is currently proprietary. > DRNI (dual resilient network interconnect) - the capability being added in the 802.1AX-Rev project has a focused objective of defining a mechanism for using a LAG between two provider networks (that's why it's called a "network interconnect") where the links end in more than one bridge (probably two or three bridges) on each side of the aggregation. End node attachment to a multi-bridge LAG host isn't an objective. > Pat > -----Original Message----- > From: Jon Hudson [mailto:jon.hudson@gmail.com] > Sent: Monday, November 19, 2012 10:24 PM > To: Donald Eastlake > Cc: Thomas Narten; Tissa Senevirathne (tsenevir); trill@ietf.org > Subject: Re: [trill] draft-ietf-trill-cmt > Just to add to what Donald said... > This is a case where the draft came out of a need that kept appearing while discussing and trying to solve other challenges ( like a/a host based connections). > As apposed to a "draft if search of a problem" this is really a case of a draft providing a building block that by not existing would prevent other solutions from coming forward. > Now as to the terminology. There is much confusion in the market and with customers as to when something is or is not LAG. > One if of the limitations today of host based LAGs is that they have to go to the same physical switch unless the target switch is part if a proprietary MCT pair, and that the MCT group is itself only a pair. > What many customers want (and is provided today by other proprietary solutions) is N active links to N top of rack switches where the initial common two configs would be two links to two TOR switches from one host, or four active links from a host to four different TOR switches. > This maybe a cause of the confusion caused by the document saying N switches. And is part of the value since as you stated most MLAG solutions are only in a pair, and subpar as a result. > J > On Nov 19, 2012, at 8:58 PM, Donald Eastlake wrote: > > Hi Thomas, > > > > Let me describe what I think it going on. > > > > On Mon, Nov 19, 2012 at 5:08 PM, Thomas Narten wrote: > >> Hi. > >> > >> I've got a fairly basic question about this document. > >> > >> What exact customer/deployment scenario is it trying to address? > > > > Scenarios in which customer wants active-active end station connectivity. > > > > TRILL can provide ECMP and multi-pathing and rapid fail-over in the > > links between RBridges. This draft is aimed at specifying a building > > block (the Affinity sub-TLV) and giving an example of use of that > > building block towards getting the same capabilities for end station > > connectivity to the campus.. > > > >> It says: > >> > >>> This document specifies a concept of Affinity sub-TLV to solve > >>> associated RPF issues at the active-active edge. Specific methods in > >>> this document for making use of the Affinity sub-TLV are applicable > >>> where multiple RBridges are connected to an edge device through link > >>> aggregation or to a multiport server or some similar arrangement > >>> where the RBridges cannot see each other's Hellos. > >> > >> I view Link Aggregation Groups (LAGs) as an L2 construct that would be > >> hidden from TRILL. I.e., in Ethernet, LAG is used to "hide" the > >> presence of multiple links between a pair of switches from STP, so STP > >> only sees one link (the LAG) rather than the individual links. Thus, I > >> would expect RBs to want to only know of a single link (i.e., the LAG) > >> and not have any understanding that the link may actually be a LAG. > > > > There are various references in various TRILL documents that agree > > with you that the classic two end-point LAG appears to TRILL as a > > single link with a single port at each end. This draft gives, as > > examples of the use of the Affinity sub-TLV, multi-port servers which > > do not forward frames between those ports, and what is usually called > > multi-chassis LAG (MC-LAG) where you have one device (such as a > > bridge) on one end and multiple devices on the other end that conspire > > to act like one device. (MC-LAG is commonly supported but using > > proprietary methods. There is a project in IEEE 802.1, 802.1AX-REV, > > that is seeking to extend LAG to allow more than one device on each > > side.) > > > > draft-hu-trill-pseudonode-nickname is an example of another use of the > > Affinity sub-TLV not related to LAG. If I recall correctly, at the > > Atlanta meeting I repeatedly paired the trill-pseudonode-nickname > > draft with the trill-cmt draft and suggested people consider them > > together. > > > >> Moreover, Figure 1 is not describing LAG, but multi-chassis LAG > >> (MLAG). MLAG is not standardized (all implementations are proprietary > >> and there is no interoperability between vendors). Moreover, MLAG > >> implementations are pretty restricted -- last I checked, MLAG products > >> were limited to only 2 switches. So the figure in the document showing > >> MLAG involving an arbitrary number of "N" switches seems a stretch. > > > > I'm not sure the number of RBridges in the edge group matters so much > > or that you know about all MC-LAG implementations. In any case, a > > multi-port server could have more than two ports. > > > >> Do I have the right understanding of what is meant by "LAG" in the > >> draft? > > > > I think so -- that is, you correctly understood that in this draft it > > actually means MC-LAG. > > > >> The idea that RBs would be aware of individual links within a LAG > >> kind of defeats the purpose of having LAGs. Is that really what is > >> being proposed? > > > > The draft is intended to specify the Affinity sub-TLV and to provide > > an example where an edge group of RBridges cannot see each other's > > Hellos. For the sub-part of the example using MC-LAG, rather than a > > multi-port server, I would say the MC-LAG is doing exactly what the > > purpose of MC-LAG is. > > > > Thanks, > > Donald > > ============================= > > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > > 155 Beaver Street, Milford, MA 01757 USA > > d3e3e3@gmail.com > > > >> Thomas > > _______________________________________________ > > trill mailing list > > trill@ietf.org > > https://www.ietf.org/mailman/listinfo/trill > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill From narten@us.ibm.com Fri Dec 14 09:00:27 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3904F21F88CF for ; Fri, 14 Dec 2012 09:00:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.449 X-Spam-Level: X-Spam-Status: No, score=-109.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_PREMTR=2.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJM9F5xGCzil for ; Fri, 14 Dec 2012 09:00:26 -0800 (PST) Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) by ietfa.amsl.com (Postfix) with ESMTP id 0DEF821F88F8 for ; Fri, 14 Dec 2012 09:00:13 -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 ; Fri, 14 Dec 2012 12:00:04 -0500 Received: from d01dlp02.pok.ibm.com (9.56.250.167) by e7.ny.us.ibm.com (192.168.1.107) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 14 Dec 2012 12:00:03 -0500 Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 9FB936E803F for ; Fri, 14 Dec 2012 12:00:01 -0500 (EST) Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id qBEH01I0298652 for ; Fri, 14 Dec 2012 12:00:01 -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 qBEH01YS028419 for ; Fri, 14 Dec 2012 12:00:01 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-200-54.mts.ibm.com [9.65.200.54]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id qBEH00fY028309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Dec 2012 12:00:01 -0500 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.5/8.12.5) with ESMTP id qBEGxxqU012075; Fri, 14 Dec 2012 11:59:59 -0500 Message-Id: <201212141659.qBEGxxqU012075@cichlid.raleigh.ibm.com> To: Mingui Zhang In-reply-to: <4552F0907735844E9204A62BBDD325E732132977@SZXEML507-MBS.china.huawei.com> References: <4552F0907735844E9204A62BBDD325E732132977@SZXEML507-MBS.china.huawei.com> Comments: In-reply-to Mingui Zhang message dated "Fri, 30 Nov 2012 08:18:08 +0000." Date: Fri, 14 Dec 2012 11:59:59 -0500 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12121417-5806-0000-0000-00001CFE8A50 Cc: "trill@ietf.org" Subject: Re: [trill] TRILL Resilient Distribution Trees, who have read it? X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 17:00:27 -0000 Hi. Per the Atlanta minutes: > Donald Eastlake (Huawei, co-Chair): OK how many people have read this > draft? That's a pretty small number so I suggest a message to the list > urging people to read this draft. > > Thomas Narten (IBM): I have a high level question. How important is > this document to the core of what we have to do as a WG? Seems like > this assumes you have a distribution tree, which we have now, and the > model is that if something goes wrong you just re-build the > tree. Maybe there is a brief period during which things don't > work. What we are doing here is building up a stand-by path. How > important is this? Do we know that convergence is too slow? It seems > to be to be pre-mature to work on this. > > Donald: I agree that that is the relevant question. How important is > this draft? Perhaps you should post that question to the list. I'm asking this question on the list. Thomas From narten@us.ibm.com Fri Dec 14 09:04:40 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D334321F890E for ; Fri, 14 Dec 2012 09:04:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.257 X-Spam-Level: X-Spam-Status: No, score=-109.257 tagged_above=-999 required=5 tests=[AWL=-0.958, BAYES_00=-2.599, MANGLED_PREMTR=2.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqhv4dDwwiUS for ; Fri, 14 Dec 2012 09:04:40 -0800 (PST) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by ietfa.amsl.com (Postfix) with ESMTP id 28EED21F8907 for ; Fri, 14 Dec 2012 09:04:39 -0800 (PST) Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 14 Dec 2012 12:04:03 -0500 Received: from d01dlp02.pok.ibm.com (9.56.250.167) by e8.ny.us.ibm.com (192.168.1.108) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 14 Dec 2012 12:04:01 -0500 Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 049186E806A for ; Fri, 14 Dec 2012 12:03:59 -0500 (EST) Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id qBEH3vjX279728 for ; Fri, 14 Dec 2012 12:03:57 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id qBEH3sYP022507 for ; Fri, 14 Dec 2012 12:03:54 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-200-54.mts.ibm.com [9.65.200.54]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id qBEH3q2r022407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Dec 2012 12:03:53 -0500 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.5/8.12.5) with ESMTP id qBEH3qJI012132; Fri, 14 Dec 2012 12:03:52 -0500 Message-Id: <201212141703.qBEH3qJI012132@cichlid.raleigh.ibm.com> To: Donald Eastlake In-reply-to: References: Comments: In-reply-to Donald Eastlake message dated "Tue, 11 Dec 2012 21:59:07 -0500." Date: Fri, 14 Dec 2012 12:03:52 -0500 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12121417-9360-0000-0000-00000DF3ACCA Cc: trill@ietf.org Subject: Re: [trill] Draft Minutes from Atlanta meeting uploaded X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 17:04:40 -0000 Wow, what an awesome set of notes. I wish all WGs did this! Thanks again Jon! Some minor/editorial suggestions. For each topic, that has a draft, please insert the actual ID name. This is done for some, but not for all, e.g., "VLAN Mapping". It's helpful for minutes to use the draft names so that one can easily search for draft names in minutes to find where a topic was discussed. Nits: > These is an Area Director s/These/There/ another Area Directory that thought s/Area Directory/ > just because the didn't have s/the/they/ > saying it was "reviewed" is not saying is was "agreed". s/is was agreed/it was agreed/ > to be to be pre-mature to work on this. s/to be to be/to me to be/ Thomas From zhangmingui@huawei.com Sun Dec 16 23:12:52 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E394521F89E9 for ; Sun, 16 Dec 2012 23:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[AWL=-2.931, BAYES_00=-2.599, FB_INCREASE_VOL=3.629, MANGLED_PREMTR=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfSWErLGRA4S for ; Sun, 16 Dec 2012 23:12:52 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6F421F8971 for ; Sun, 16 Dec 2012 23:12:51 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMO19436; Mon, 17 Dec 2012 07:12:50 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 17 Dec 2012 07:12:45 +0000 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 17 Dec 2012 07:12:49 +0000 Received: from SZXEML507-MBS.china.huawei.com ([169.254.7.234]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.003; Mon, 17 Dec 2012 15:12:42 +0800 From: Mingui Zhang To: Thomas Narten Thread-Topic: [trill] TRILL Resilient Distribution Trees, who have read it? Thread-Index: Ac3O0ux4S0JhVhpwS56Ahgx4dyNymwLBniSAAJL4eEA= Date: Mon, 17 Dec 2012 07:12:41 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E73213A467@SZXEML507-MBS.china.huawei.com> References: <4552F0907735844E9204A62BBDD325E732132977@SZXEML507-MBS.china.huawei.com> <201212141659.qBEGxxqU012075@cichlid.raleigh.ibm.com> In-Reply-To: <201212141659.qBEGxxqU012075@cichlid.raleigh.ibm.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.185] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "trill@ietf.org" Subject: Re: [trill] TRILL Resilient Distribution Trees, who have read it? X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 07:12:53 -0000 Hi Thomas, Thanks for posting the question. TRILL provides multicast service using ISIS link state routing. When there = is a failure, RBridges are notified through the propagation of LSPs, which = will trigger a campus-wide convergence on distribution trees. The convergen= ce includes the following major processes: 1) the propagation of LSPs aroun= d the whole campus; 2) the recalculation of trees on affected RBridges; 3) = the update of forwarding information on those RBridges. These processes mak= e the convergence time-consuming. As we know, most multicast traffic is gen= erated by applications which are sensitive to interrupt latency. Therefore,= the convergence will lead to the disruption of multicast service. Due to the propagation delay of LSPs, the distribution trees are calculated= and installed on RBridges at different time, which brings _inconsistence_ = of forwarding states among RBridges. Before the convergence finishes, multi= cast frames may be trapped by forwarding loops and finally dropped. This in= creases the volume of broadcast/multicast traffic.=20 Protection is not a new topic for link state routing. It was proposed to re= duce traffic disruption and resolve inconsistence during convergence using = backup paths pre-installed. TRILL specified to calculate multiple distribut= ion trees in those first days, which offers kind of ability for protection.= The draft "TRILL Resilient Distribution Trees" makes use of this feature t= o provide the multicast protection without significant pay, which is natura= l rather than premature. Thanks, Mingui >-----Original Message----- >From: Thomas Narten [mailto:narten@us.ibm.com] >Sent: Saturday, December 15, 2012 1:00 AM >To: Mingui Zhang >Cc: trill@ietf.org >Subject: Re: [trill] TRILL Resilient Distribution Trees, who have read it? > >Hi. > >Per the Atlanta minutes: > >> Donald Eastlake (Huawei, co-Chair): OK how many people have read this >> draft? That's a pretty small number so I suggest a message to the list >> urging people to read this draft. >> >> Thomas Narten (IBM): I have a high level question. How important is >> this document to the core of what we have to do as a WG? Seems like >> this assumes you have a distribution tree, which we have now, and the >> model is that if something goes wrong you just re-build the >> tree. Maybe there is a brief period during which things don't >> work. What we are doing here is building up a stand-by path. How >> important is this? Do we know that convergence is too slow? It seems >> to be to be pre-mature to work on this. >> >> Donald: I agree that that is the relevant question. How important is >> this draft? Perhaps you should post that question to the list. > >I'm asking this question on the list. > >Thomas From d3e3e3@gmail.com Mon Dec 17 11:37:59 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCF021F87EB for ; Mon, 17 Dec 2012 11:37:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.324 X-Spam-Level: X-Spam-Status: No, score=-102.324 tagged_above=-999 required=5 tests=[AWL=-1.026, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_PREMTR=2.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-bOJf9MKDfk for ; Mon, 17 Dec 2012 11:37:58 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4759221F8503 for ; Mon, 17 Dec 2012 11:37:58 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so9847603ieb.31 for ; Mon, 17 Dec 2012 11:37:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=j2m/1tppniH0w8wqTayEX0tl1VALeYRia853I+lOhGM=; b=OFYm0an0Qk+Y+RkyE9UwxGwwjhRp0xxxJK9mj7SSjQIV/clsycTVbk4NvpB4GIlKiv BvPOvmk6O46pwAKlqBkIDyNDDqRt80RhcLMmiJLFevzybHQ4EDvq3pwFCOop2wmXlM7U vCtcd3O6Sj2J5QbOOltRtHA4UHzrKMHpwheoE/FsDRKSz36uyryxpH9Wg70HP9JSr1DW jTphKPPZUCPeNKv808XSAgOzcfWaX33S7SrLYO7rwjMM8RfMv2mPbiAwlLvn+2bf3LwQ 2KMPjm6IuwX3jW7RToGB4oI8wPEPwYtJxyiABE3B6bFh9cHinrVZYkZgVWOH6ivyLWYx dX0A== Received: by 10.50.219.165 with SMTP id pp5mr10393809igc.55.1355773077895; Mon, 17 Dec 2012 11:37:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.28.209 with HTTP; Mon, 17 Dec 2012 11:37:37 -0800 (PST) In-Reply-To: <201212141703.qBEH3qJI012132@cichlid.raleigh.ibm.com> References: <201212141703.qBEH3qJI012132@cichlid.raleigh.ibm.com> From: Donald Eastlake Date: Mon, 17 Dec 2012 14:37:37 -0500 Message-ID: To: Thomas Narten Content-Type: multipart/alternative; boundary=14dae934112fb43ad904d11184b4 Cc: trill@ietf.org Subject: Re: [trill] Draft Minutes from Atlanta meeting uploaded X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 19:37:59 -0000 --14dae934112fb43ad904d11184b4 Content-Type: text/plain; charset=ISO-8859-1 Thanks for the review of the minutes. A revision with those errors fixed has been uploaded. Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Fri, Dec 14, 2012 at 12:03 PM, Thomas Narten wrote: > Wow, what an awesome set of notes. I wish all WGs did this! Thanks > again Jon! > > Some minor/editorial suggestions. > > For each topic, that has a draft, please insert the actual ID > name. This is done for some, but not for all, e.g., "VLAN > Mapping". It's helpful for minutes to use the draft names so that one > can easily search for draft names in minutes to find where a topic was > discussed. > > Nits: > > > These is an Area Director > > s/These/There/ > > another Area Directory that thought > > s/Area Directory/ > > > just because the didn't have > > s/the/they/ > > > saying it was "reviewed" is not saying is was "agreed". > > s/is was agreed/it was agreed/ > > > to be to be pre-mature to work on this. > > s/to be to be/to me to be/ > > Thomas > > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill > --14dae934112fb43ad904d11184b4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks for the review of the minutes. A revision with those errors fix= ed has been uploaded.

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,=A0Milf= ord, MA 01757 USA
=A0d3e3e3@gmail.com


On Fri, Dec 14, 2012 at 12:03 PM, Thomas= Narten <narten@us.ibm.com> wrote:
Wow, what an awesome set of notes. I wish all WGs did this! Thanks
again Jon!

Some minor/editorial suggestions.

For each topic, that has a draft, please insert the actual ID
name. This is done for some, but not for all, e.g., "VLAN
Mapping". It's helpful for minutes to use the draft names so that = one
can easily search for draft names in minutes to find where a topic was
discussed.

Nits:

> These is an Area Director

s/These/There/

another Area Directory that thought

s/Area Directory/

> just because the didn't have

s/the/they/

> saying it was "reviewed" is not saying is was "agreed&q= uot;.

s/is was agreed/it was agreed/

> to be to be pre-mature to work on this.

s/to be to be/to me to be/

Thomas

_______________________________________________
trill mailing list
trill@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/trill

--14dae934112fb43ad904d11184b4-- From ALim@extremenetworks.com Mon Dec 17 13:50:14 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7C9721F892A for ; Mon, 17 Dec 2012 13:50:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6B6c+BPJ1gK for ; Mon, 17 Dec 2012 13:50:11 -0800 (PST) Received: from ussc-casht-p1.extremenetworks.com (ussc-casht-p1.extremenetworks.com [207.179.9.62]) by ietfa.amsl.com (Postfix) with ESMTP id AD2B621F88A3 for ; Mon, 17 Dec 2012 13:50:11 -0800 (PST) Received: from USEXCHANGE.corp.extremenetworks.com ([10.0.4.74]) by ussc-casht-p2.corp.extremenetworks.com ([10.255.181.88]) with mapi; Mon, 17 Dec 2012 13:50:11 -0800 From: Arnel Lim To: "trill@ietf.org" Date: Mon, 17 Dec 2012 13:50:09 -0800 Thread-Topic: DTree Questions Regarding Router Capability TLV Thread-Index: Ac3coHFIKEK22A7fTPOOok7XxnDDmg== Message-ID: <6738A78F51650A4FAEDCF6844B26C21401C0B3D95B4E@USEXCHANGE.corp.extremenetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6738A78F51650A4FAEDCF6844B26C21401C0B3D95B4EUSEXCHANGEc_" MIME-Version: 1.0 Cc: Wenya Qi , Eric Garver Subject: [trill] DTree Questions Regarding Router Capability TLV X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 21:50:15 -0000 --_000_6738A78F51650A4FAEDCF6844B26C21401C0B3D95B4EUSEXCHANGEc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have some questions about the sending and processing of the TREES-RT-ID a= nd TREES-USE-ID sub-TLV in the Router Capability TLV. I need a little clar= ification with respect to when these sub-TLVs are sent and who sends them. = I've outlined how I interpreted parts of the Distribution Tree section RFC= 632 with respect to these sub-TLVs, but I need a little validation. Note, the quoted items are taken directly from RFC6325. 1) Only the highest priority Rbridge needs to send out TREES-RT-ID sub-TLV,= correct? "The number of trees, k, that are computed for the campus is the number wan= ted by the RBridge RB1, which has the nickname with the highest "tree root"= priority" 2) Rbridges will calculate the highest priority k trees if they don't rece= ive TREES-RT-ID sub-TLV. This implies it's *NOT* mandatory for highest pri= ority Rbridge to send TREES-RT-ID sub-TLV, correct? "If RB1 does not specify the specific distribution tree roots as described = below, then the k highest priority trees are the trees that will be compute= d by all RBridges." 3) ALL Rbridges, RB2, that ingress native traffic MUST send TREES-USE-ID su= b-TLV, correct? This is required for RPF check used by adjacent RBridges. "each RBridge RB2 MUST announce which trees RB2 may choose when RB2 ingress= es a multi-destination packet." 4) Transit-only RBridges do NOT need to send TREES-USE-ID sub-TLV, correct?= Since TREES-USE-ID indicates what trees a RBridge may use for ingressing = native traffic, Transit-only RBridges have nothing to advertise. 5) Ingress RBridges, RB2, can specify, via user config, a set of j trees to= use. If NO trees in the set of j trees intersect with the k highest prio= rity trees advertised by the Rbridge with highest root priority, NONE of t= he j trees are advertised. Ingress RBridges, RB2, will then advertise the= k highest priority trees in the TREES-USE-ID sub-TLV. Correct? OR, does RB2 advertise whatever it wishes, and the RBridge receiving the LS= P examine the intersection of j with k? If no set of j trees is explicitly configured, will RB2 advertise the k hig= hest priority trees in the TREES-USE-ID sub-TLV, or none at all. What's no= t clear is if in the special case of j=3D=3D0, do we still have to include = the sub-TLV in the LSP? I would think the neighboring RBridge can assume i= f the TREES-USE-ID sub-TLV is not present, that means j=3D=3D0 and RB2 will= use the k highest priority trees. Seems explicitily advertisine the k hi= ghest trees may be the "safe" thing to do for interoperability, but is it t= he "right" thing to do? "The information to determine which trees RB2 might choose is included in R= B2's LSP. Similarly to how the highest priority RBridge RB1 specifies the k= trees that will be computed by all RBridges, RB2 specifies a number j, whi= ch is the total number of different trees RB2 might specify, and the specif= ic trees RB2 might specify are a combination of specified trees and trees s= elected from highest priority trees. If RB2 specifies any trees that are no= t in the k trees as specified by RB1, they are ignored. The j potential ingress trees for RB2 are the ones with nicknames that RB2 = has explicitly specified in "specified ingress tree nicknames" (and that ar= e included in the k campus-wide trees selected by highest priority RBridge = RB1), with the remainder (up to the maximum of {j,k}) being the highest pri= ority of the k campus-wide trees." When the RFC refers to RB2's LSP it is referring to the TREES-US-ID sub-TLV= , correct? The j potential ingress trees this section talks about would be manually co= nfigured by the user, correct? If no j trees are specified, does RB2 default to sending out the k trees in= the TREES-USE-ID sub-TLV, an empty TREES-USE-ID sub-TLV, or RB2 does not s= end any TREES-USE-ID sub-TLV at all? If j >=3D k and no tree in j intersects k, all j trees are ignored. Does t= his imply neighbors should not expect dTree traffic from RB2? ________________________________ DISCLAIMER: This e-mail and any attachments to it may contain confidential and propriet= ary material and is solely for the use of the intended recipient. Any revie= w, use, disclosure, distribution or copying of this transmittal is prohibit= ed except by or on behalf of the intended recipient. If you have received t= his transmittal in error, please notify the sender and destroy this e-mail = and any attachments and all copies, whether electronic or printed. --_000_6738A78F51650A4FAEDCF6844B26C21401C0B3D95B4EUSEXCHANGEc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
DISCLAIMER:
This e-mail and any attachments to it may contain confidential and propriet= ary material and is solely for the use of the intended recipient. Any revie= w, use, disclosure, distribution or copying of this transmittal is prohibit= ed except by or on behalf of the intended recipient. If you have received this transmittal in error, please= notify the sender and destroy this e-mail and any attachments and all copi= es, whether electronic or printed.
 --_000_6738A78F51650A4FAEDCF6844B26C21401C0B3D95B4EUSEXCHANGEc_-- From ayabaner@gmail.com Mon Dec 17 14:13:30 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C8621F87D8 for ; Mon, 17 Dec 2012 14:13:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yc0rJIMl0dGS for ; Mon, 17 Dec 2012 14:13:29 -0800 (PST) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id 584A021F8479 for ; Mon, 17 Dec 2012 14:13:29 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id hj13so2324659wib.13 for ; Mon, 17 Dec 2012 14:13:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BXTlsXaNyweH2PQEyydUnrZDcOSa1h3kxMZV9w0aE90=; b=fUuM0I1Mggtdc/5fLI756fHKNWHJOdYnhqfVWVny5q3+T5eaJzu/yWa6dVhosfAG6y 0pZBUOyvwzWK8dfd/7RdCwtMkPn7XF4sIJlSljTCuMybO2AJW8dnrT4KzqKW0aw+mags EM9SdbD+8Hf8S68ktjXgrb3GLN9oJ1j4RGk5Y0OMpX2l8LNguiEGFf5U535HxxzzS+Zw XFKU2n7k0LHpxNECQvfPenndhy78h0t/g4nCsUV6/1A+3Crzo53rSLksLqw3D1SJ1Lna ShHucRXncBIPJw92zgPMQJElJbUJQQKU7dkgwaSJ96QNSlc6jb6vCcMoNJkvPlU0Dt/m covQ== MIME-Version: 1.0 Received: by 10.194.85.168 with SMTP id i8mr20066265wjz.18.1355782408417; Mon, 17 Dec 2012 14:13:28 -0800 (PST) Received: by 10.194.154.129 with HTTP; Mon, 17 Dec 2012 14:13:28 -0800 (PST) In-Reply-To: <6738A78F51650A4FAEDCF6844B26C21401C0B3D95B4E@USEXCHANGE.corp.extremenetworks.com> References: <6738A78F51650A4FAEDCF6844B26C21401C0B3D95B4E@USEXCHANGE.corp.extremenetworks.com> Date: Mon, 17 Dec 2012 14:13:28 -0800 Message-ID: From: Ayan Banerjee To: Arnel Lim Content-Type: multipart/alternative; boundary=089e010d7efcd8b18104d113b08d Cc: Wenya Qi , Eric Garver , "trill@ietf.org" Subject: Re: [trill] DTree Questions Regarding Router Capability TLV X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 22:13:31 -0000 --089e010d7efcd8b18104d113b08d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Please see in-line. Thanks, Ayan On Mon, Dec 17, 2012 at 1:50 PM, Arnel Lim wrote= : > I have some questions about the sending and processing of the > TREES-RT-ID and TREES-USE-ID sub-TLV in the Router Capability TLV. I nee= d > a little clarification with respect to when these sub-TLVs are sent and w= ho > sends them. I=92ve outlined how I interpreted parts of the Distribution = Tree > section RFC632 with respect to these sub-TLVs, but I need a little > validation. **** > > ** ** > > Note, the quoted items are taken directly from RFC6325. ** ** > > ** ** > > ** ** > > 1) Only the highest priority Rbridge needs to send out TREES-RT-ID > sub-TLV, correct? **** > > =93The number of trees, k, that are computed for the campus is the number > wanted by the RBridge RB1, which has the nickname with the highest "tree > root" priority=94**** > > ** ** > > [Ayan] Yes, this is accurate. > > ** > > 2) Rbridges will calculate the highest priority k trees if they don't > receive TREES-RT-ID sub-TLV. This implies it's *NOT* *mandatory* for > highest priority Rbridge to send TREES-RT-ID sub-TLV, correct?**** > > =93If RB1 does not specify the specific distribution tree roots as descri= bed > below, then the k highest priority trees are the trees that will be > computed by all RBridges.=94**** > > ** ** > > [Ayan] Yes, this is accurate. > > 3) ALL Rbridges, RB2, that ingress native traffic *MUST* send > TREES-USE-ID sub-TLV, correct? This is required for RPF check used by > adjacent RBridges.**** > > =93each RBridge RB2 MUST announce which trees RB2 may choose when RB2 > ingresses a multi-destination packet.=94**** > > [Ayan] No, this is not accurate. If ingress nodes use this TLV, it may > help other nodes to be more strict in accepting packets from the relevant > multi-destination trees. If it does not send out this TLV, then it implie= s > that a node may use all multi-destination trees. > > 4) Transit-only RBridges do *NOT* need to send TREES-USE-ID sub-TLV, > correct? Since TREES-USE-ID indicates what trees a RBridge may use for > ingressing native traffic, Transit-only RBridges have nothing to advertis= e. > **** > > [Ayan] See answer to (3) above. > > ** ** > > 5) Ingress RBridges, RB2, can specify, via user config, a set of j trees > to use. If NO trees in the set of j trees intersect with the k highest > priority trees advertised by the Rbridge with highest root priority, NON= E > of the j trees are advertised. Ingress RBridges, RB2, will then adverti= se > the k highest priority trees in the TREES-USE-ID sub-TLV. Correct?**** > > OR, does RB2 advertise whatever it wishes, and the RBridge receiving the > LSP examine the intersection of j with k?**** > > [Ayan] It is the latter - others make use with the TREES-USE-ID TLV. What > a local nodes announces with user configured "j" trees is a local decisio= n. > > If no set of j trees is explicitly configured, will RB2 advertise the k > highest priority trees in the TREES-USE-ID sub-TLV, or none at all. What= =92s > not clear is if in the special case of j=3D=3D0, do we still have to incl= ude > the sub-TLV in the LSP? I would think the neighboring RBridge can assume > if the TREES-USE-ID sub-TLV is not present, that means j=3D=3D0 and RB2 w= ill > use the k highest priority trees. Seems explicitily advertisine the k > highest trees may be the =93safe=94 thing to do for interoperability, but= is it > the =93right=94 thing to do?**** > > [Ayan] Sure a node can announce the "K" trees, but that is also implicit. > Thanks, Ayan > =93The information to determine which trees RB2 might choose is included = in > RB2=92s LSP. Similarly to how the highest priority RBridge RB1 specifies = the > k trees that will be computed by all RBridges, RB2 specifies a number j, > which is the total number of different trees RB2 might specify, and the > specific trees RB2 might specify are a combination of specified trees and > trees selected from highest priority trees. If RB2 specifies any trees th= at > are not in the k trees as specified by RB1, they are ignored.**** > > ** ** > > The j potential ingress trees for RB2 are the ones with nicknames that RB= 2 > has explicitly specified in "specified ingress tree nicknames" (and that > are included in the k campus-wide trees selected by highest priority > RBridge RB1), with the remainder (up to the maximum of {j,k}) being the > highest priority of the k campus-wide trees.=94**** > > ** ** > > When the RFC refers to *RB2=92s LSP* it is referring to the TREES-US-ID > sub-TLV, correct?**** > > The j potential ingress trees this section talks about would be manually > configured by the user, correct?**** > > ** ** > > If no j trees are specified, does RB2 default to sending out the k trees > in the TREES-USE-ID sub-TLV, an empty TREES-USE-ID sub-TLV, or RB2 does n= ot > send any TREES-USE-ID sub-TLV at all?**** > > ** ** > > If j >=3D k and no tree in j intersects k, all j trees are ignored. Does > this imply neighbors should not expect dTree traffic from RB2? **** > > ** ** > > ------------------------------ > DISCLAIMER: > This e-mail and any attachments to it may contain confidential and > proprietary material and is solely for the use of the intended recipient. > Any review, use, disclosure, distribution or copying of this transmittal = is > prohibited except by or on behalf of the intended recipient. If you have > received this transmittal in error, please notify the sender and destroy > this e-mail and any attachments and all copies, whether electronic or > printed. > > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill > > --089e010d7efcd8b18104d113b08d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Please see in-line.

Thanks,
Ayan
<= br>
On Mon, Dec 17, 2012 at 1:50 PM, Arnel Lim <ALim@extremenetworks.com> wrote:

I have some questions about the sending and processing of the= TREES-RT-ID and TREES-USE-ID sub-TLV in the Router Capability TLV.=A0 I ne= ed a little clarification with respect to when these sub-TLVs are sent and = who sends them.=A0 I=92ve outlined how I interpreted parts of the Distribution Tree section RFC632 with respe= ct to these sub-TLVs, but I need a little validation.=A0

=A0

Note, the quoted items are taken directly from RFC6325.

=A0

=A0

1) Only the highest priority Rbridge needs to send out TREES-= RT-ID sub-TLV, correct?

=93The number of trees, k, that are com= puted for the campus is the number wanted by the RBridge RB1, which has the= nickname with the highest "tree root" priority=94

=A0

[Ayan] Yes, this is accurate.

=A0

2) Rbridges will calculate the highest priority k trees if th= ey don't =A0receive TREES-RT-ID sub-TLV.=A0 This implies it's *NOT* mandatory for highest priority Rbridge to send TREES-RT-ID sub-TLV, = correct?

=93If RB1 does not specify the specific= distribution tree roots as described below, then the k highest priority tr= ees are the trees that will be computed by all RBridges.=94

=A0

=A0 [Ayan] Yes, this is accurate.

3) ALL Rbridges, RB2, that ingress native traffic MUST= send TREES-USE-ID sub-TLV, correct?=A0=A0 This is required for RPF check u= sed by adjacent RBridges.

=93each RBridge RB2 MUST announce which trees RB2 may choose when RB2= ingresses a multi-destination packet.=94

[Ayan] No, this is not accurate. If ingress nodes use this T= LV, it may help other nodes to be more strict in accepting packets from the= relevant multi-destination trees. If it does not send out this TLV, then i= t implies that a node may use all multi-destination trees.

4) Transit-only RBridges do NOT need to send TREES-USE= -ID sub-TLV, correct?=A0 Since TREES-USE-ID indicates what trees a RBridge = may use for ingressing native traffic, Transit-only RBridges have nothing t= o advertise.

[Ayan] See answer to (3) above.

=A0

5) Ingress RBridges, RB2, can specify, via user config, a set= of j trees to use.=A0=A0 If NO trees in the set of j trees intersect with = the k highest priority =A0trees advertised by the Rbridge with highest root= priority, NONE of the =A0j trees are advertised.=A0 Ingress RBridges, RB2, will then advertise the k =A0hig= hest priority trees in the TREES-USE-ID sub-TLV. Correct?

OR, does RB2 advertise whatever it wishes, and the RBridge re= ceiving the LSP examine the intersection of j with k?

[Ayan] It is the latter - others make use with the TREES-USE= -ID TLV. What a local nodes announces with user configured "j" tr= ees is a local decision.

If no set of j trees is explicitly configured, will RB2 adver= tise the k highest priority trees in the TREES-USE-ID sub-TLV, or none at a= ll.=A0 What=92s not clear is if in the special case of j=3D=3D0, do we stil= l have to include the sub-TLV in the LSP?=A0 I would think the neighboring RBridge can assume if the TREES-= USE-ID sub-TLV is not present, that means j=3D=3D0 and RB2 will use the k h= ighest priority trees. =A0=A0Seems explicitily advertisine the k highest tr= ees may be the =93safe=94 thing to do for interoperability, but is it the =93right=94 thing to do?

[Ayan] Sure a node can announce the "K" trees, but= that is also implicit.


Thanks,Ayan
=A0

=93The information to determine which trees RB2 might choose is inclu= ded in RB2=92s LSP. Similarly to how the highest priority RBridge RB1 speci= fies the k trees that will be computed by all RBridges, RB2 specifies a number j, which is the total number of di= fferent trees RB2 might specify, and the specific trees RB2 might specify a= re a combination of specified trees and trees selected from highest priorit= y trees. If RB2 specifies any trees that are not in the k trees as specified by RB1, they are ignored.<= u>

=A0

The j potential ingress trees for RB2 are the ones with nicknames tha= t RB2 has explicitly specified in "specified ingress tree nicknames&qu= ot; (and that are included in the k campus-wide trees selected by highest priority RBridge RB1), with the remainder (up to= the maximum of {j,k}) being the highest priority of the k campus-wide tree= s.=94

=A0

When the RFC refers to RB2=92s LSP it is referring to t= he TREES-US-ID sub-TLV, correct?

The j potential ingress trees this section talks about would = be manually configured by the user, correct?

= =A0

If no j trees are specified, does RB2 default to sending out = the k trees in the TREES-USE-ID sub-TLV, an empty TREES-USE-ID sub-TLV, or = RB2 does not send any TREES-USE-ID sub-TLV at all?

=A0

If j >=3D k and no tree in j intersects k, all j trees are= ignored.=A0 Does this imply neighbors should not expect dTree traffic from= RB2?

=A0


DISCLAIMER:
This e-mail and any attachments to it may contain confidential and propriet= ary material and is solely for the use of the intended recipient. Any revie= w, use, disclosure, distribution or copying of this transmittal is prohibit= ed except by or on behalf of the intended recipient. If you have received this transmittal in error, please= notify the sender and destroy this e-mail and any attachments and all copi= es, whether electronic or printed.

_______________________________________________
trill mailing list
trill@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/trill


--089e010d7efcd8b18104d113b08d-- From narten@us.ibm.com Tue Dec 18 07:09:17 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5839E21F8610 for ; Tue, 18 Dec 2012 07:09:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.49 X-Spam-Level: X-Spam-Status: No, score=-109.49 tagged_above=-999 required=5 tests=[AWL=1.109, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqIE809wfmns for ; Tue, 18 Dec 2012 07:09:16 -0800 (PST) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by ietfa.amsl.com (Postfix) with ESMTP id 3B67421F871F for ; Tue, 18 Dec 2012 07:09:16 -0800 (PST) Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 18 Dec 2012 10:09:14 -0500 Received: from d01dlp01.pok.ibm.com (9.56.250.166) by e8.ny.us.ibm.com (192.168.1.108) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 18 Dec 2012 10:09:11 -0500 Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 4755D38C804F for ; Tue, 18 Dec 2012 10:09:11 -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 qBIF9Apj290170 for ; Tue, 18 Dec 2012 10:09:10 -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 qBIF97UE030984 for ; Tue, 18 Dec 2012 13:09:09 -0200 Received: from cichlid.raleigh.ibm.com (sig-9-76-159-220.mts.ibm.com [9.76.159.220]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id qBIF96AR030614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Dec 2012 13:09:07 -0200 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.5/8.12.5) with ESMTP id qBIF91R3012151; Tue, 18 Dec 2012 10:09:01 -0500 Message-Id: <201212181509.qBIF91R3012151@cichlid.raleigh.ibm.com> To: Ayan Banerjee In-reply-to: References: <6738A78F51650A4FAEDCF6844B26C21401C0B3D95B4E@USEXCHANGE.corp.extremenetworks.com> Comments: In-reply-to Ayan Banerjee message dated "Mon, 17 Dec 2012 14:13:28 -0800." Date: Tue, 18 Dec 2012 10:09:01 -0500 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12121815-9360-0000-0000-00000E1ABF34 Cc: Arnel Lim , Wenya Qi , "trill@ietf.org" , Eric Garver Subject: Re: [trill] DTree Questions Regarding Router Capability TLV X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 15:09:17 -0000 Ayan Banerjee writes: > On Mon, Dec 17, 2012 at 1:50 PM, Arnel Lim wrote: > > 3) ALL Rbridges, RB2, that ingress native traffic MUST send > > TREES-USE-ID sub-TLV, correct? This is required for RPF check > > used by adjacent RBridges. > > “each RBridge RB2 MUST announce which trees RB2 may choose when > > RB2 ingresses a multi-destination packet.†> [Ayan] No, this is not accurate. If ingress nodes use this TLV, it > may help other nodes to be more strict in accepting packets from the > relevant multi-destination trees. If it does not send out this TLV, > then it implies that a node may use all multi-destination trees. So, are you saying that if RB doesn't announce the TLV, all other RBs must assume that RB2 can/will ingress multi-destination packets? If so, I understand the reasoning for why the RB should effectively announce a TLV saying "I'm not ingressing anything". But does the spec actually say that transit RBs SHOULD/MUST advertise a TLV with a (presumably) empty list in this case? Thomas From narten@us.ibm.com Tue Dec 18 07:36:01 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD0A21F8A5A for ; Tue, 18 Dec 2012 07:36:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.045 X-Spam-Level: X-Spam-Status: No, score=-108.045 tagged_above=-999 required=5 tests=[AWL=-1.075, BAYES_00=-2.599, FB_INCREASE_VOL=3.629, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eft2FPe5zi7g for ; Tue, 18 Dec 2012 07:36:00 -0800 (PST) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by ietfa.amsl.com (Postfix) with ESMTP id 23EA721F8A0A for ; Tue, 18 Dec 2012 07:36:00 -0800 (PST) Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 18 Dec 2012 10:35:57 -0500 Received: from d01dlp03.pok.ibm.com (9.56.250.168) by e9.ny.us.ibm.com (192.168.1.109) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 18 Dec 2012 10:35:55 -0500 Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id 22C89C90045 for ; Tue, 18 Dec 2012 10:35:55 -0500 (EST) Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id qBIFZsJJ301512 for ; Tue, 18 Dec 2012 10:35:54 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id qBIFZs9t030771 for ; Tue, 18 Dec 2012 13:35:54 -0200 Received: from cichlid.raleigh.ibm.com (sig-9-76-159-220.mts.ibm.com [9.76.159.220]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id qBIFZrYS030694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Dec 2012 13:35:53 -0200 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.5/8.12.5) with ESMTP id qBIFZqAs012411; Tue, 18 Dec 2012 10:35:52 -0500 Message-Id: <201212181535.qBIFZqAs012411@cichlid.raleigh.ibm.com> To: Mingui Zhang In-reply-to: <4552F0907735844E9204A62BBDD325E73213A467@SZXEML507-MBS.china.huawei.com> References: <4552F0907735844E9204A62BBDD325E732132977@SZXEML507-MBS.china.huawei.com> <201212141659.qBEGxxqU012075@cichlid.raleigh.ibm.com> <4552F0907735844E9204A62BBDD325E73213A467@SZXEML507-MBS.china.huawei.com> Comments: In-reply-to Mingui Zhang message dated "Mon, 17 Dec 2012 07:12:41 +0000." Date: Tue, 18 Dec 2012 10:35:51 -0500 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12121815-7182-0000-0000-000003DE3CC1 Cc: "trill@ietf.org" Subject: Re: [trill] TRILL Resilient Distribution Trees, who have read it? X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 15:36:01 -0000 Hi. I understand at a high level what the reational is. What I'm really trying to get at is: does the cost/complexity justify the benefit? For this, some quantifiable metrics would help - not just generalities like "convergence will be faster", etc. Mingui Zhang writes: > Hi Thomas, > TRILL provides multicast service using ISIS link state routing. When > there is a failure, RBridges are notified through the propagation > of LSPs, which will trigger a campus-wide convergence on > distribution trees. The convergence includes the following major > processes: 1) the propagation of LSPs around the whole campus; 2) > the recalculation of trees on affected RBridges; 3) the update of > forwarding information on those RBridges. These processes make the > convergence time-consuming. I take issue with this. The whole point of link-state flooding approaches is that they are fast - much faster than alternatives. And as a data point, back in Paris, Paul Unbehagen gave a presentation in the IS-IS WG on SPB deployment where (according to my notes): They are seeing 34-100ms convergence times and think this can be further reduced by an order of magnitude (recommendation 7) Won't TRILL have similar convergence times? Are we talking about using failover to shave off a few tens of milliseconds? Or is there some sort of expectation that this will shave seconds or more off the recovery time? That is, do we have any evidence (or targets) for TRILL convergence times (after a topology change) that are "too long"? Just "how fast" reconvergence is considered fast enough, and what is considered problematical? > As we know, most multicast traffic is > generated by applications which are sensitive to interrupt > latency. Therefore, the convergence will lead to the disruption of > multicast service. Which applications are those? Are there particular deployment scenarios that are being targetted, or is this just a general argument? > Due to the propagation delay of LSPs, the distribution trees are > calculated and installed on RBridges at different time, which > brings _inconsistence_ of forwarding states among RBridges. Before > the convergence finishes, multicast frames may be trapped by > forwarding loops and finally dropped. This increases the volume of > broadcast/multicast traffic. And just how long does this period of "inconsistency" last? And just how quickly will a node know that a path that it is using has failed and that it needs to fallback to using the precomputed backup path? Won't it also take time for news of a failure to propagate through the network? In other words, won't the network already be reconfiguring itself even before a node realizes that a path has failed and it should switch to a backup? So again, I'm really trying to understand just how much of an improvement the proposed approach is expected to produce. To be clear, I'm not necessarily opposed to this work. But I would like a better understanding of exactly how much benefit we can really expect, so I can understand how to weigh the tradeoffs between increased complexity vs. actual benefit. Thomas From ayabaner@gmail.com Tue Dec 18 09:56:53 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6D621F8AAF for ; Tue, 18 Dec 2012 09:56:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGI6Rzodc569 for ; Tue, 18 Dec 2012 09:56:53 -0800 (PST) Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF1621F8AA4 for ; Tue, 18 Dec 2012 09:56:48 -0800 (PST) Received: by mail-we0-f174.google.com with SMTP id x10so445283wey.5 for ; Tue, 18 Dec 2012 09:56:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BqEu5vql3zOyprPbo9gsKEkdjHJa2h8M5Y3G08ugx9U=; b=laII37wNSIlduyN+k23Q5H+zXxl+xR9TD1pSrxa7KksWO7sGMuCW2H78G2FuSehqR2 NSnbawU5NzkNyK/NSqnKiOBKtecpeT8P63Y0pIiC8GVXxQFTvrCRBVUe2qu89U30muo+ g0QJCl98CyFZN8fpycBhp94Ksu+ciqbLKw5J9hzzfhVsoCTD4+4tDb62nUtq0cl1BhV2 6CZsQJj2CivnqwPmpdCnfQVpHZbCdK+3OHbEv/me9TmnX7mY7l/o76kNf1NGyyLQV3hV nMi1lMmLJY9Ue/ErrHL3WZcLzoTMJEAbJLWtgonZrX8NZkxNX2+sltMxo2w90qZ1v0VW PfEQ== MIME-Version: 1.0 Received: by 10.194.79.34 with SMTP id g2mr6304742wjx.17.1355853407387; Tue, 18 Dec 2012 09:56:47 -0800 (PST) Received: by 10.194.154.129 with HTTP; Tue, 18 Dec 2012 09:56:47 -0800 (PST) In-Reply-To: <201212181509.qBIF91R3012151@cichlid.raleigh.ibm.com> References: <6738A78F51650A4FAEDCF6844B26C21401C0B3D95B4E@USEXCHANGE.corp.extremenetworks.com> <201212181509.qBIF91R3012151@cichlid.raleigh.ibm.com> Date: Tue, 18 Dec 2012 09:56:47 -0800 Message-ID: From: Ayan Banerjee To: Thomas Narten Content-Type: multipart/alternative; boundary=047d7bb03eccb6fecb04d1243884 Cc: Arnel Lim , Wenya Qi , Eric Garver , "trill@ietf.org" Subject: Re: [trill] DTree Questions Regarding Router Capability TLV X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 17:56:53 -0000 --047d7bb03eccb6fecb04d1243884 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Please see in-line. Thanks, Ayan On Tue, Dec 18, 2012 at 7:09 AM, Thomas Narten wrote: > Ayan Banerjee writes: > > > On Mon, Dec 17, 2012 at 1:50 PM, Arnel Lim > wrote: > > > > 3) ALL Rbridges, RB2, that ingress native traffic MUST send > > > TREES-USE-ID sub-TLV, correct? This is required for RPF check > > > used by adjacent RBridges. > > > > =93each RBridge RB2 MUST announce which trees RB2 may choose when > > > RB2 ingresses a multi-destination packet.=94 > > > [Ayan] No, this is not accurate. If ingress nodes use this TLV, it > > may help other nodes to be more strict in accepting packets from the > > relevant multi-destination trees. If it does not send out this TLV, > > then it implies that a node may use all multi-destination trees. > > So, are you saying that if RB doesn't announce the TLV, all other RBs > must assume that RB2 can/will ingress multi-destination packets? > > If so, I understand the reasoning for why the RB should effectively > announce a TLV saying "I'm not ingressing anything". But does the spec > actually say that transit RBs SHOULD/MUST advertise a TLV with a > (presumably) empty list in this case? > > [Ayan] Probably not. However, I would consider the presence of the statement to be an optimization that would be nice to have - so even if it is there, it will probably be a "SHOULD" and not a "MUST". > Thomas > > > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill > > --047d7bb03eccb6fecb04d1243884 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Please see in-line.

Thanks,
Ayan



On Tue, Dec 18, 2012 at 7:09 AM, Thoma= s Narten <narten@us.ibm.com> wrote:
Ayan Banerjee <ayabaner@gmail.com> writes:

> On Mon, Dec 17, 2012 at 1:50 PM, Arnel Lim <ALim@extremenetworks.com> wrote:

> > 3) ALL Rbridges, RB2, that ingress native traffic MUST send
> > =A0 =A0TREES-USE-ID sub-TLV, correct? =A0This is required for RPF= check
> > =A0 =A0used by adjacent RBridges.

> > =93each RBridge RB2 MUST announce which trees RB2 may choose when=
> > =A0 =A0 RB2 ingresses a multi-destination packet.=94

> [Ayan] No, this is not accurate. If ingress nodes use this TLV, it
> may help other nodes to be more strict in accepting packets from the > relevant multi-destination trees. If it does not send out this TLV, > then it implies that a node may use all multi-destination trees.

So, are you saying that if RB doesn't announce the TLV, all other RBs must assume that RB2 can/will ingress multi-destination packets?

If so, I understand the reasoning for why the RB should effectively
announce a TLV saying "I'm not ingressing anything". But does= the spec
actually say that transit RBs SHOULD/MUST advertise a TLV with a
(presumably) empty list in this case?

[Ayan] Probably not. However, I would consider the presence of the = statement to be an optimization that would be nice to have - so even if it = is there, it will probably be a "SHOULD" and not a "MUST&quo= t;.
=A0
Thomas


_______________________________________________
trill mailing list
trill@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/trill


--047d7bb03eccb6fecb04d1243884-- From d3e3e3@gmail.com Tue Dec 18 20:46:31 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F83921F8586 for ; Tue, 18 Dec 2012 20:46:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.425 X-Spam-Level: X-Spam-Status: No, score=-103.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5WG2sxXlNM7 for ; Tue, 18 Dec 2012 20:46:30 -0800 (PST) Received: from mail-ia0-f182.google.com (mail-ia0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id 5C28D21F857D for ; Tue, 18 Dec 2012 20:46:30 -0800 (PST) Received: by mail-ia0-f182.google.com with SMTP id x2so1361949iad.13 for ; Tue, 18 Dec 2012 20:46:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=zBSBChI3X9AMv0Ush/GD2v6z2SdGIkvYxvDcfePg29Q=; b=V1dMCm7UspRqYLDTssDXbMw9rXlTJM/6snPMi4H9ymyp5wrQrep1Ybvh7w2DqWU4bR O1E+EavVPUYZKzNOAtyS7lEsJRoE/cPDLurHFL+GwguSSTyncbJpfmWuJkYdgXWAuFsO JkA4w9QAAV3WzPsmWN5epLd8drpyPUQ0iPGN9WBOfIRORm84H4XayNc4OW30tvFnoPHh xTq9FfGfbgfAiPnL0NoBmCUydyX4Dkcr2ZNm4tsMfHN6k+QTVMSFH0AcQ6Binu7EOTim njcn/Ej0eW59pFTTvpvmX+YS49nmvPCGj8Pg1TQ5rRnaGA4eHxuvbSpw82EGAAVBZaNi idZg== Received: by 10.50.12.138 with SMTP id y10mr5744886igb.58.1355892389815; Tue, 18 Dec 2012 20:46:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.28.209 with HTTP; Tue, 18 Dec 2012 20:46:09 -0800 (PST) In-Reply-To: References: <6738A78F51650A4FAEDCF6844B26C21401C0B3D95B4E@USEXCHANGE.corp.extremenetworks.com> From: Donald Eastlake Date: Tue, 18 Dec 2012 23:46:09 -0500 Message-ID: To: Arnel Lim Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Wenya Qi , "trill@ietf.org" , Eric Garver Subject: Re: [trill] DTree Questions Regarding Router Capability TLV X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 04:46:31 -0000 Hi, You should note that the "TRILL: Clarifications, Corrections, and Updates" draft, particularly Section 3, affects some of the issues you are asking about. That's draft-ietf-trill-clear-correct-06.txt, which is fully approved and in the RFC Editor's queue. On Mon, Dec 17, 2012 at 5:13 PM, Ayan Banerjee wrote: > Please see in-line. > > Thanks, > Ayan > > On Mon, Dec 17, 2012 at 1:50 PM, Arnel Lim wro= te: >> >> I have some questions about the sending and processing of the TREES-RT-I= D >> and TREES-USE-ID sub-TLV in the Router Capability TLV. I need a little >> clarification with respect to when these sub-TLVs are sent and who sends >> them. I=92ve outlined how I interpreted parts of the Distribution Tree >> section RFC632 with respect to these sub-TLVs, but I need a little >> validation. >> >> >> Note, the quoted items are taken directly from RFC6325. >> >> >> >> 1) Only the highest priority Rbridge needs to send out TREES-RT-ID >> sub-TLV, correct? >> >> =93The number of trees, k, that are computed for the campus is the numbe= r >> wanted by the RBridge RB1, which has the nickname with the highest "tree >> root" priority=94 >> >> [Ayan] Yes, this is accurate. While accurate, it may not be wise. What if the RBridge holding the highest priority tree root nickname dies or the network partitions or something? This is typically a pretty small sub-TLV. I would think that, in a well configured campus, if you are using this sub-TLV to specify your tree roots rather than just doing it by priority, then many of the RBridges with higher priority tree root nicknames would advertise this sub-TLV. >> 2) Rbridges will calculate the highest priority k trees if they don't >> receive TREES-RT-ID sub-TLV. This implies it's *NOT* mandatory for high= est >> priority Rbridge to send TREES-RT-ID sub-TLV, correct? >> >> =93If RB1 does not specify the specific distribution tree roots as descr= ibed >> below, then the k highest priority trees are the trees that will be comp= uted >> by all RBridges.=94 >> >> [Ayan] Yes, this is accurate. >> >> 3) ALL Rbridges, RB2, that ingress native traffic MUST send TREES-USE-ID >> sub-TLV, correct? This is required for RPF check used by adjacent >> RBridges. >> >> =93each RBridge RB2 MUST announce which trees RB2 may choose when RB2 >> ingresses a multi-destination packet.=94 >> >> [Ayan] No, this is not accurate. If ingress nodes use this TLV, it may >> help other nodes to be more strict in accepting packets from the relevan= t >> multi-destination trees. If it does not send out this TLV, then it impli= es >> that a node may use all multi-destination trees. Ayan is right. The "MUST" there really means that the RB2 has to announce information from which, along with information from the RBridge holding the highest priority tree root nickname, other RBridges can derive the distribution trees that RB2 might use. As stated in RFC 6325, the primary reason for this is to reduce the amount of RPF state if every RBridge cannot ingress multi-destination to every tree being computed for the campus.. >> 4) Transit-only RBridges do NOT need to send TREES-USE-ID sub-TLV, >> correct? Since TREES-USE-ID indicates what trees a RBridge may use for >> ingressing native traffic, Transit-only RBridges have nothing to adverti= se. >> >> [Ayan] See answer to (3) above. I don't think there is any way an RBridge can indicate it is transit only. Usually switches have an internal virtual end station and at least end up effectively ingressing frames from this virtual end station. If some RBridge will do little or no ingressing of multi-destination frames, it should probably just use one distribution tree. If it is going to use the highest priority tree, I believe all it needs to do is announce the Trees sub-TLV with Number of Trees Used equal to one. If it wants to use some different single tree, then it should also announce the nickname of that tree in a Trees Used Identifiers sub-TLV. >> 5) Ingress RBridges, RB2, can specify, via user config, a set of j trees >> to use. If NO trees in the set of j trees intersect with the k highest >> priority trees advertised by the Rbridge with highest root priority, NO= NE >> of the j trees are advertised. Ingress RBridges, RB2, will then advert= ise >> the k highest priority trees in the TREES-USE-ID sub-TLV. Correct? >> >> OR, does RB2 advertise whatever it wishes, and the RBridge receiving the >> LSP examine the intersection of j with k? >> >> [Ayan] It is the latter - others make use with the TREES-USE-ID TLV. Wha= t >> a local nodes announces with user configured "j" trees is a local decisi= on. >> >> If no set of j trees is explicitly configured, will RB2 advertise the k >> highest priority trees in the TREES-USE-ID sub-TLV, or none at all. Wha= t=92s >> not clear is if in the special case of j=3D=3D0, do we still have to inc= lude the >> sub-TLV in the LSP? I would think the neighboring RBridge can assume if= the >> TREES-USE-ID sub-TLV is not present, that means j=3D=3D0 and RB2 will us= e the k >> highest priority trees. Seems explicitily advertisine the k highest tr= ees >> may be the =93safe=94 thing to do for interoperability, but is it the = =93right=94 >> thing to do? >> >> [Ayan] Sure a node can announce the "K" trees, but that is also implicit= . Right. If no set of j trees is explicitly configured, then it is implicit. (see more below) > Thanks, > Ayan > >> >> =93The information to determine which trees RB2 might choose is included= in >> RB2=92s LSP. Similarly to how the highest priority RBridge RB1 specifies= the k >> trees that will be computed by all RBridges, RB2 specifies a number j, w= hich >> is the total number of different trees RB2 might specify, and the specif= ic >> trees RB2 might specify are a combination of specified trees and trees >> selected from highest priority trees. If RB2 specifies any trees that ar= e >> not in the k trees as specified by RB1, they are ignored. >> >> The j potential ingress trees for RB2 are the ones with nicknames that R= B2 >> has explicitly specified in "specified ingress tree nicknames" (and that= are >> included in the k campus-wide trees selected by highest priority RBridge >> RB1), with the remainder (up to the maximum of {j,k}) being the highest >> priority of the k campus-wide trees.=94 As specified by an Errata filed against RFC 6325 and draft-ietf-trill-clear-correct-06.txt: In [RFC6325], Section 4.5.2, page 56, Point 2, 4th paragraph, the parenthetical "(up to the maximum of {j,k})" is incorrect [Err3052]. It should read "(up to k if j is zero or the minimum of (j, k) if j is non-zero)". >> When the RFC refers to RB2=92s LSP it is referring to the TREES-US-ID >> sub-TLV, correct? The LSP (Link State PDU) for RB2 includes all of the Trees, Tree Identifiers, and Trees Used Identifiers sub-TLVs that RB2 chooses to advertise. (Tree Identifiers will not have any effect unless RB2 holds the nickname that is the highest priority tree root). >> The j potential ingress trees this section talks about would be manually >> configured by the user, correct? Well, there is a default that will happen without configuration but normally the network manager will configure things to get the distribution tree use they want. >> If no j trees are specified, does RB2 default to sending out the k trees >> in the TREES-USE-ID sub-TLV, an empty TREES-USE-ID sub-TLV, or RB2 does = not >> send any TREES-USE-ID sub-TLV at all? Whose j are you talking about, RB2's j or the j of the RBridge holding the nickname that is highest priority to be a tree root? There is no reason for RB2 to waste LSP space by sending out a Trees Used Identifiers sub-TLV if it might use any of the trees being computed for the campus. I also don't see any reason for it to send out an empty Trees Used Identifiers sub-TLV. Neither provides other RBridges with any information. >> If j >=3D k and no tree in j intersects k, all j trees are ignored. Doe= s >> this imply neighbors should not expect dTree traffic from RB2? No. For the campus to work correctly, it is normally necessary for every RBridge to be able to send on a distribution tree. To the extent that the Trees Used Identifiers sub-TLV for an RBridge lists trees not being calculated for a campus, those entries are ignored. If all entries are ignored, it still uses a number of trees determined by the Number of Trees to Use entry in its Trees sub-TLV and the number of trees being computed for the campus. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From d3e3e3@gmail.com Tue Dec 18 21:01:57 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2705021F859D for ; Tue, 18 Dec 2012 21:01:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.433 X-Spam-Level: X-Spam-Status: No, score=-103.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5MJHg3GbnV4 for ; Tue, 18 Dec 2012 21:01:56 -0800 (PST) Received: from mail-ia0-f175.google.com (mail-ia0-f175.google.com [209.85.210.175]) by ietfa.amsl.com (Postfix) with ESMTP id 97E6621F859C for ; Tue, 18 Dec 2012 21:01:55 -0800 (PST) Received: by mail-ia0-f175.google.com with SMTP id z3so1325761iad.20 for ; Tue, 18 Dec 2012 21:01:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=3BlQd1MHPRlCc7YoGfBPwKHMKyrpul+PnGIKtPW8Ryw=; b=SfPBwM6X36MWrNMCl0qyXMLadcT5ppNpBhqSFzGx9mNfqgX8EaVIMNYTDDMh1pKBqV +YkwjovJ1LqpNGpqagHcwqZ1n64UH4qBEuG7oHC8WBnjBn1MdLb2XKKy5zXaghvy3nxY OAq0z5aNaKbD/ncsoYjeofRWy5EndsbqnxSYMNmJjyAi87+cFmqoBH/2apUpb3juATQS RJZcnTw9Zr2GH1MJX/nDGzVWjR68V6ihZLd+zqlACDjjpCTmmbInD57JD3FOK5WzDvth bzTWcssrgKFTiMWYkj2pl23J4tfNX4VhJFsD0V+R4C7RPZRLZIkuvJ5G4HKrmkrYVoJp jtRw== Received: by 10.50.158.201 with SMTP id ww9mr1145042igb.22.1355893315101; Tue, 18 Dec 2012 21:01:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.28.209 with HTTP; Tue, 18 Dec 2012 21:01:34 -0800 (PST) In-Reply-To: <201212181509.qBIF91R3012151@cichlid.raleigh.ibm.com> References: <6738A78F51650A4FAEDCF6844B26C21401C0B3D95B4E@USEXCHANGE.corp.extremenetworks.com> <201212181509.qBIF91R3012151@cichlid.raleigh.ibm.com> From: Donald Eastlake Date: Wed, 19 Dec 2012 00:01:34 -0500 Message-ID: To: Thomas Narten Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Arnel Lim , Wenya Qi , Eric Garver , Ayan Banerjee , "trill@ietf.org" Subject: Re: [trill] DTree Questions Regarding Router Capability TLV X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 05:01:57 -0000 Hi Thomas, On Tue, Dec 18, 2012 at 10:09 AM, Thomas Narten wrote: > Ayan Banerjee writes: > >> On Mon, Dec 17, 2012 at 1:50 PM, Arnel Lim wr= ote: > >> > 3) ALL Rbridges, RB2, that ingress native traffic MUST send >> > TREES-USE-ID sub-TLV, correct? This is required for RPF check >> > used by adjacent RBridges. > >> > =93each RBridge RB2 MUST announce which trees RB2 may choose when >> > RB2 ingresses a multi-destination packet.=94 > >> [Ayan] No, this is not accurate. If ingress nodes use this TLV, it >> may help other nodes to be more strict in accepting packets from the >> relevant multi-destination trees. If it does not send out this TLV, >> then it implies that a node may use all multi-destination trees. > > So, are you saying that if RB doesn't announce the TLV, all other RBs > must assume that RB2 can/will ingress multi-destination packets? Yes, if an RBridge chooses to not list specific trees it might use, then the trees it might use are determined in a default way. > If so, I understand the reasoning for why the RB should effectively > announce a TLV saying "I'm not ingressing anything". But does the spec > actually say that transit RBs SHOULD/MUST advertise a TLV with a > (presumably) empty list in this case? An RBridge "not ingressing anything" can't, for example, have an SNMP stack. While theoretically possible, will such a thing occur in the real world? The Number of Trees to Use field in the Trees sub-TLV says how many trees an RBridge intends to use. And, as per RFC 6325, if that field is zero, it is interpreted as saying that the RBridge can use any of the trees being calculated for the campus. So there is no way for an RBridge to say it is using zero distribution trees. > Thomas 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 From zhangmingui@huawei.com Wed Dec 19 01:30:40 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EBB921F8924 for ; Wed, 19 Dec 2012 01:30:40 -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=-1.488, BAYES_00=-2.599, FB_INCREASE_VOL=3.629, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCkB+L1GP7FI for ; Wed, 19 Dec 2012 01:30:39 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EFFF921F8B0E for ; Wed, 19 Dec 2012 01:30:38 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANZ10834; Wed, 19 Dec 2012 09:30:37 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 19 Dec 2012 09:30:12 +0000 Received: from SZXEML445-HUB.china.huawei.com (10.82.67.183) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 19 Dec 2012 09:30:14 +0000 Received: from SZXEML507-MBS.china.huawei.com ([169.254.7.234]) by szxeml445-hub.china.huawei.com ([10.82.67.183]) with mapi id 14.01.0323.003; Wed, 19 Dec 2012 17:30:08 +0800 From: Mingui Zhang To: Thomas Narten Thread-Topic: [trill] TRILL Resilient Distribution Trees, who have read it? Thread-Index: Ac3O0ux4S0JhVhpwS56Ahgx4dyNymwLBniSAAJL4eEAAM0G8gAAz5+dA Date: Wed, 19 Dec 2012 09:30:07 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E73213A81C@SZXEML507-MBS.china.huawei.com> References: <4552F0907735844E9204A62BBDD325E732132977@SZXEML507-MBS.china.huawei.com> <201212141659.qBEGxxqU012075@cichlid.raleigh.ibm.com> <4552F0907735844E9204A62BBDD325E73213A467@SZXEML507-MBS.china.huawei.com> <201212181535.qBIFZqAs012411@cichlid.raleigh.ibm.com> In-Reply-To: <201212181535.qBIFZqAs012411@cichlid.raleigh.ibm.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.185] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "trill@ietf.org" Subject: Re: [trill] TRILL Resilient Distribution Trees, who have read it? X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 09:30:40 -0000 Hi Thomas, > They are seeing 34-100ms convergence times and think this can be > further reduced by an order of magnitude (recommendation 7) When you say convergence time can be as short as 34 ms, it certainly does n= ot include the failure detection time. Since failures are detected in ISIS = by non-receipt of Hellos within three holding timers, which are "commonly s= et to a value of tens of seconds and, in any case, has a minimum expressibl= e value of one second [rbBFD]". When the presenter mentioned the convergenc= e time, I believe he meant "the time elapsed from a failure event realized = by the control protocol until the forwarding has been recovered [CONVERGE]"= . However, the service disruption does include the failure detection time, = during which the forwarding paths via the failure spot are already cut off.= So, the service disruption time at least includes the following two parts:= 1) Failure detection time; 2) Service resuming time (a.k.a. convergence ti= me). >Won't TRILL have similar convergence times? Are we talking about using >failover to shave off a few tens of milliseconds? Or is there some >sort of expectation that this will shave seconds or more off the >recovery time? We expect that "TRILL Resilient Distribution Trees" reduce the whole recove= ry time. >Which applications are those? Are there particular deployment >scenarios that are being targetted, or is this just a general >argument? Video distribution (e.g., IPTV) is such kind of application [RDT]. >And just how long does this period of "inconsistency" last? And just >how quickly will a node know that a path that it is using has failed >and that it needs to fallback to using the precomputed backup path? >Won't it also take time for news of a failure to propagate through the >network? In other words, won't the network already be reconfiguring >itself even before a node realizes that a path has failed and it >should switch to a backup? The figure on page 4 of [CONVERGE] also tells us that inconsistence introdu= ces a sky-high deal of looping traffic. This period can last seconds. RDT n= ot only reduces the service disruption time but also decreases the looping = traffic. There are three kinds of protection described in the draft. Only the global= 1:1 protection relies on the "news of a failure" to determine to switch to= a backup. We catch the issue in Section 5.4 of the draft. You will find there is no p= roblem that network reconfiguration and the use of backup take place in par= allel. >So again, I'm really trying to understand just how much of an >improvement the proposed approach is expected to produce. Let me quantify the improvement we expected to produce: "Service disruption time should be magnitude shorter than one second [RFC57= 14]".=20 Exactly, we expect [RDT] meets "Realistic availability requirements (sub-se= cond to sub-200msec)... [MOFRR]".=20 References [rbBFD] http://www.ietf.org/id/draft-ietf-trill-rbridge-bfd-07.txt [CONVERGE] http://www.ieee802.org/1/files/public/docs2010/new-farkas-conver= gence-1110.pdf [RDT] http://datatracker.ietf.org/doc/draft-zhang-trill-resilient-trees/?in= clude_text=3D1 [RFC5714] http://tools.ietf.org/html/rfc5714 [MOFRR] http://tools.ietf.org/html/draft-karan-mofrr-02 Thanks, Mingui >-----Original Message----- >From: Thomas Narten [mailto:narten@us.ibm.com] >Sent: Tuesday, December 18, 2012 11:36 PM >To: Mingui Zhang >Cc: trill@ietf.org >Subject: Re: [trill] TRILL Resilient Distribution Trees, who have read it? > >Hi. > >I understand at a high level what the reational is. What I'm really >trying to get at is: does the cost/complexity justify the benefit? For >this, some quantifiable metrics would help - not just generalities >like "convergence will be faster", etc. > >Mingui Zhang writes: > >> Hi Thomas, > >> TRILL provides multicast service using ISIS link state routing. When >> there is a failure, RBridges are notified through the propagation >> of LSPs, which will trigger a campus-wide convergence on >> distribution trees. The convergence includes the following major >> processes: 1) the propagation of LSPs around the whole campus; 2) >> the recalculation of trees on affected RBridges; 3) the update of >> forwarding information on those RBridges. These processes make the >> convergence time-consuming. > >I take issue with this. The whole point of link-state flooding >approaches is that they are fast - much faster than alternatives. > >And as a data point, back in Paris, Paul Unbehagen gave a presentation >in the IS-IS WG on SPB deployment where (according to my notes): > > They are seeing 34-100ms convergence times and think this can be > further reduced by an order of magnitude (recommendation 7) > >Won't TRILL have similar convergence times? Are we talking about using >failover to shave off a few tens of milliseconds? Or is there some >sort of expectation that this will shave seconds or more off the >recovery time? > >That is, do we have any evidence (or targets) for TRILL convergence >times (after a topology change) that are "too long"? Just "how fast" >reconvergence is considered fast enough, and what is considered >problematical? > >> As we know, most multicast traffic is >> generated by applications which are sensitive to interrupt >> latency. Therefore, the convergence will lead to the disruption of >> multicast service. > >Which applications are those? Are there particular deployment >scenarios that are being targetted, or is this just a general >argument? > >> Due to the propagation delay of LSPs, the distribution trees are >> calculated and installed on RBridges at different time, which >> brings _inconsistence_ of forwarding states among RBridges. Before >> the convergence finishes, multicast frames may be trapped by >> forwarding loops and finally dropped. This increases the volume of >> broadcast/multicast traffic. > >And just how long does this period of "inconsistency" last? And just >how quickly will a node know that a path that it is using has failed >and that it needs to fallback to using the precomputed backup path? >Won't it also take time for news of a failure to propagate through the >network? In other words, won't the network already be reconfiguring >itself even before a node realizes that a path has failed and it >should switch to a backup? > >So again, I'm really trying to understand just how much of an >improvement the proposed approach is expected to produce. > >To be clear, I'm not necessarily opposed to this work. But I would >like a better understanding of exactly how much benefit we can really >expect, so I can understand how to weigh the tradeoffs between >increased complexity vs. actual benefit. > >Thomas From d3e3e3@gmail.com Wed Dec 19 07:54:43 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB1621F8598; Wed, 19 Dec 2012 07:54:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.44 X-Spam-Level: X-Spam-Status: No, score=-103.44 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00YYhvGhbUGr; Wed, 19 Dec 2012 07:54:42 -0800 (PST) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) by ietfa.amsl.com (Postfix) with ESMTP id 5DDDB21F857D; Wed, 19 Dec 2012 07:54:42 -0800 (PST) Received: by mail-ie0-f170.google.com with SMTP id k10so3018730iea.15 for ; Wed, 19 Dec 2012 07:54:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=XaZaCyNIZCIjMuhUPFPtT4V3K9BpxqAT/aw4mxq2Yxg=; b=RbL9qvcSYb+e4tddO68c6/MyhRM5M2n5kDiYt9nRO+cm+UlDksz7kChxmgVYxqUBny ksvhsrXBRPJlh/vj6gSNiD/+Nra6VseURThMdyK034ATICzifx3RF1xsUPxWCnMuF4KF zIpvk39Y0mT98BwOSWQkvDx+CKejsSRmSm7u4smSvyNy/O5EWF3cc/vzp2oJm+i8twVN pQCrzF9cZ2oWCawbLkuaqXRWPypjaw4PbSic32oIVemjszp9vdYJ0J/WbXCR2Vr2RQW0 c+aknY7NS9NHPNWQUZ0UoBORd94ZGSZlWm7KTq+93ZyB+f5WHSoC2KOsJ7k+pqTWOxf+ 8kQQ== Received: by 10.43.124.130 with SMTP id go2mr6325918icc.8.1355932481799; Wed, 19 Dec 2012 07:54:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.28.209 with HTTP; Wed, 19 Dec 2012 07:54:21 -0800 (PST) In-Reply-To: <201212120043.qBC0hjW7067663@skyhighway.com> References: <20121211145829.3754.44253.idtracker@ietfa.amsl.com> <201212120043.qBC0hjW7067663@skyhighway.com> From: Donald Eastlake Date: Wed, 19 Dec 2012 10:54:21 -0500 Message-ID: To: gayle noble Content-Type: text/plain; charset=ISO-8859-1 Cc: ietf@ietf.org, trill@ietf.org Subject: Re: [trill] Last Call: (Requirements for Operations, Administration and Maintenance (OAM) in TRILL (Transparent Interconnection of Lots of Links)) to Informational RFC X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 15:54:43 -0000 Hi Gayle, On Tue, Dec 11, 2012 at 7:43 PM, gayle noble wrote: > Very well written!! No spelling errors! No grammatical errors! Only one > sentence, in my opinion, could be rephrased for clarity > 4.1. Data Plane > RBridges MUST have the ability to identify OAM frames destined for them or > which require processing by the OAM plane from normal data frames. > [Might be clearer if it was [RBridges MUST have the ability to identify OAM > frames from normal data frames when the OAM frames are destined for them or > require processing by the OAM plane.]] Thanks for the praise! I think that your suggested wording could be improved by replacing the word "identify" with the word "distinguish". Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > gayle From windy_1@skyhighway.com Wed Dec 19 08:02:18 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22C8921F8A90; Wed, 19 Dec 2012 08:02:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.367 X-Spam-Level: X-Spam-Status: No, score=-1.367 tagged_above=-999 required=5 tests=[AWL=1.232, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Psq23l0lUop9; Wed, 19 Dec 2012 08:02:17 -0800 (PST) Received: from skyhighway.com (skyhighway.com [63.249.82.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7E85521F8A6E; Wed, 19 Dec 2012 08:02:17 -0800 (PST) Received: from Firefly.skyhighway.com (dsl-63-249-88-160.static.cruzio.com [63.249.88.160]) by skyhighway.com with ESMTP id qBJG2H7O034643; Wed, 19 Dec 2012 08:02:17 -0800 (PST) Message-Id: <201212191602.qBJG2H7O034643@skyhighway.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 19 Dec 2012 08:02:10 -0800 To: ietf@ietf.org, trill@ietf.org From: gayle noble In-Reply-To: References: <20121211145829.3754.44253.idtracker@ietfa.amsl.com> <201212120043.qBC0hjW7067663@skyhighway.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [trill] Last Call: (Requirements for Operations, Administration and Maintenance (OAM) in TRILL (Transparent Interconnection of Lots of Links)) to Informational RFC X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 16:02:18 -0000 I totally agree with that tweak >*sparkles*< [RBridges MUST have the ability to distinguish OAM frames from normal data frames when the OAM frames are destined for them or require processing by the OAM plane.] Perfect >*bow*< gayle At 07:54 AM 12/19/2012, Donald Eastlake wrote: >Hi Gayle, > >On Tue, Dec 11, 2012 at 7:43 PM, gayle noble wrote: > > Very well written!! No spelling errors! No grammatical errors! Only one > > sentence, in my opinion, could be rephrased for clarity > > 4.1. Data Plane > > RBridges MUST have the ability to identify OAM frames destined for them or > > which require processing by the OAM plane from normal data frames. > > [Might be clearer if it was [RBridges MUST have the ability to identify OAM > > frames from normal data frames when the OAM frames are destined for them or > > require processing by the OAM plane.]] > >Thanks for the praise! >I think that your suggested wording could be improved by replacing the >word "identify" with the word "distinguish". > >Donald >============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > > > gayle From d3e3e3@gmail.com Wed Dec 19 08:42:05 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 231B921F85DF for ; Wed, 19 Dec 2012 08:42:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.632 X-Spam-Level: X-Spam-Status: No, score=-101.632 tagged_above=-999 required=5 tests=[AWL=-1.662, BAYES_00=-2.599, FB_INCREASE_VOL=3.629, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPzZ1tXzCZe3 for ; Wed, 19 Dec 2012 08:42:04 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6E221F84F6 for ; Wed, 19 Dec 2012 08:42:04 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id z13so1947971iaz.3 for ; Wed, 19 Dec 2012 08:42:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=aQ2TvQSTNJRbA9kriiXV9drJPan2KZgHAxv+GsrFCjs=; b=qKkmKQhhCH0oU1ur0hhHeugqSmjD6E9sIZDThOWWdIfst5b2mSn5xE/QTloaAnOMmw N5TXxHZtHsIVPR6uSVIFE+RQ97sZj9Ie6YOaSofYM3paLUFd1x77CJRTWdQ1UBdIgw0Y fKWZ1segsu9h9EY7Ylv04jF6MtNgWQBMFknkIZwV0nyBhBoS60VeRISmv9Y/APLOtXQY avXBQavxzJIilPiKooehJwqjDKByHeZNBn1/PSad4GWGngZ9kKW9/SmlmZVhvPMc5CXQ a380+IZ/3TZlM4nQR8YGTdXeVC2TG1Z5B40wNb466vYJcuFaKGJuD1jPQUy2pzMCIDMO L6jA== Received: by 10.43.114.135 with SMTP id fa7mr6488315icc.21.1355935323796; Wed, 19 Dec 2012 08:42:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.28.209 with HTTP; Wed, 19 Dec 2012 08:41:43 -0800 (PST) In-Reply-To: <201212181535.qBIFZqAs012411@cichlid.raleigh.ibm.com> References: <4552F0907735844E9204A62BBDD325E732132977@SZXEML507-MBS.china.huawei.com> <201212141659.qBEGxxqU012075@cichlid.raleigh.ibm.com> <4552F0907735844E9204A62BBDD325E73213A467@SZXEML507-MBS.china.huawei.com> <201212181535.qBIFZqAs012411@cichlid.raleigh.ibm.com> From: Donald Eastlake Date: Wed, 19 Dec 2012 11:41:43 -0500 Message-ID: To: Thomas Narten Content-Type: text/plain; charset=ISO-8859-1 Cc: Mingui Zhang , "trill@ietf.org" Subject: Re: [trill] TRILL Resilient Distribution Trees, who have read it? X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 16:42:05 -0000 Hi Thomas, On Tue, Dec 18, 2012 at 10:35 AM, Thomas Narten wrote: > Hi. > > I understand at a high level what the reational is. What I'm really > trying to get at is: does the cost/complexity justify the benefit? For > this, some quantifiable metrics would help - not just generalities > like "convergence will be faster", etc. > > Mingui Zhang writes: > >> Hi Thomas, > >> TRILL provides multicast service using ISIS link state routing. When >> there is a failure, RBridges are notified through the propagation >> of LSPs, which will trigger a campus-wide convergence on >> distribution trees. The convergence includes the following major >> processes: 1) the propagation of LSPs around the whole campus; 2) >> the recalculation of trees on affected RBridges; 3) the update of >> forwarding information on those RBridges. These processes make the >> convergence time-consuming. > > I take issue with this. The whole point of link-state flooding > approaches is that they are fast - much faster than alternatives. They are also more stable than distance-vector methods. > And as a data point, back in Paris, Paul Unbehagen gave a presentation > in the IS-IS WG on SPB deployment where (according to my notes): > > They are seeing 34-100ms convergence times and think this can be > further reduced by an order of magnitude (recommendation 7) > > Won't TRILL have similar convergence times? Are we talking about using > failover to shave off a few tens of milliseconds? Or is there some > sort of expectation that this will shave seconds or more off the > recovery time? Absolute values of convergence time seem meaningless to me without knowing how much horsepower the routing computation CPU has, how many nodes there are, and how much computation you are doing (for example, how many distribution trees you are computing in a TRILL campus). > That is, do we have any evidence (or targets) for TRILL convergence > times (after a topology change) that are "too long"? Just "how fast" > reconvergence is considered fast enough, and what is considered > problematical? Any loss of traffic is bad. A typical acceptable limit for one kind of inherently redundant traffic, voice, is 50 milliseconds. A common rule of thumb is that it is good to test every 10 milliseconds so that, after a few successive test packets fail you can, even allowing for various overhead, bound the switchover time to be less than 50 milliseconds. >> As we know, most multicast traffic is >> generated by applications which are sensitive to interrupt >> latency. Therefore, the convergence will lead to the disruption of >> multicast service. > > Which applications are those? Are there particular deployment > scenarios that are being targetted, or is this just a general > argument? What I hear about most are real time streaming media, like voice and video, and distribution of financial information. >> Due to the propagation delay of LSPs, the distribution trees are >> calculated and installed on RBridges at different time, which >> brings _inconsistence_ of forwarding states among RBridges. Before >> the convergence finishes, multicast frames may be trapped by >> forwarding loops and finally dropped. This increases the volume of >> broadcast/multicast traffic. Unicast frames can loop briefly during a transient unless you use ordered FIBs; however, although there is no technique I am aware of similar to ordered FIBs for multicast distribution, due to the reverse path forwarding check, I think it is much more likely that multicast traffic will be dropped than that they will loop. > And just how long does this period of "inconsistency" last? For failures, conditions that will lose traffic really can extend from the initial failure until the tree forwarding and RPFC information at all RBridges is consistent with the new topology. Inconsistency of that information depends on the fastest and slowest RBridges to adjust. So you could have an RBridge with a particularly powerful processor that gets the LSPs indicting the change in topology early and that only has a few ports connected to an RBridge with a particularly feeble processor that gets the LSPs indicating the change in topology late and has a zillion ports connected... > And just > how quickly will a node know that a path that it is using has failed > and that it needs to fallback to using the precomputed backup path? Sometimes you can tell quickly that an directly connected link has failed due to physical layer or link layer test protocol indications. For a "path", you may have to send test messages at that level and how quickly you find out depends on how frequently you test. > Won't it also take time for news of a failure to propagate through the > network? In other words, won't the network already be reconfiguring > itself even before a node realizes that a path has failed and it > should switch to a backup? Probably. But if you are a source multiple hops away from the failure and have detected the failure due to your path test messages, you might prefer to "instantly" switch to a pre-configured maximally disjoint alternative tree rather than wait for the slowest reconfiguring RBridge along some new path the network is trying to configure itself to before your traffic starts getting through again. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > So again, I'm really trying to understand just how much of an > improvement the proposed approach is expected to produce. > > To be clear, I'm not necessarily opposed to this work. But I would > like a better understanding of exactly how much benefit we can really > expect, so I can understand how to weigh the tradeoffs between > increased complexity vs. actual benefit. > > Thomas > > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill From ostokes@extremenetworks.com Wed Dec 19 10:19:33 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0367421F84D1 for ; Wed, 19 Dec 2012 10:19:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7kA2Efx3S3uN for ; Wed, 19 Dec 2012 10:19:32 -0800 (PST) Received: from ussc-casht-p1.extremenetworks.com (ussc-casht-p1.extremenetworks.com [207.179.9.62]) by ietfa.amsl.com (Postfix) with ESMTP id 1361D21F86C0 for ; Wed, 19 Dec 2012 10:19:32 -0800 (PST) Received: from USEXCHANGE.corp.extremenetworks.com ([10.0.4.74]) by ussc-casht-p2.corp.extremenetworks.com ([10.255.181.88]) with mapi; Wed, 19 Dec 2012 10:19:31 -0800 From: Olen Stokes To: Donald Eastlake , "trill@ietf.org" Date: Wed, 19 Dec 2012 10:19:30 -0800 Thread-Topic: [trill] I-D Action: draft-ietf-trill-fine-labeling-03.txt Thread-Index: Ac3YhecNpK6et6KBS92wwoIty3Au+wFbzZJQ Message-ID: References: <20121212162556.27149.4308.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [trill] I-D Action: draft-ietf-trill-fine-labeling-03.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 18:19:33 -0000 Thanks for the updated draft. I think that the changes have been very wort= hwhile. One thing that the changes made more clear to me is how tightly th= e draft ties fine grained labels (FGLs) to C-VLAN IDs. Going back to RFC 6= 325, it states that: "Use of [802.1ad] S-tags, also known as service tags, and use of stacked ta= gs, are beyond the scope of this document." I take that to mean that the use of S-Tags (or other stacked tags) is not p= rohibited, it is just not covered. The encapsulation used in RFC6325 inclu= ded the C-Tag which told every RBridge that received the TRILL packet that = the encapsulated packet was a C-Tagged packet. If someone wanted to extend= RFC6325 to describe operation with S-Tagged packets, it would be straightf= orward for RBridges to determine that the encapsulated packet was a S-Tagge= d packet by seeing a 0x88A8 instead of a 0x8100. The bottom line is that t= he information necessary to determine the packet type of the encapsulated p= acket was included in the TRILL packet. With FGL, we appear to be losing the ability to determine the packet type o= f the encapsulated packet. The draft in several places describes going bet= ween a FGL and a C-VLAN ID. In other words, the original format of the enc= apsulated packet could appear to be limited to C-Tags. It would seem to be= appropriate to insure that FGL can be extendable to supporting S-Tags. Fo= r example, the following two approaches come to mind: 1) Assume that Ethertype 0x893B indicates only the presence of a FGL and th= at it does not necessarily mean that the encapsulated packet is a native C-= Tagged packet. If pruning is based solely on the FGL and the DMAC of the e= ncapsulated packet, then D-Tree pruning would not require an understanding = of the format of the encapsulated packet. As long as all edge RBridges adv= ertising interest in a FGL agree on the format of the encapsulated packet, = then data forwarding would work correctly. 2) Use a new Ethertype other than 0x893B to indicate that the FGL is for a = S-Tagged (or stacked tag) native packet. Some indication of the approach that the authors have in mind would be very= helpful when trying to understand the draft. This leads to another aspect that became more clear to me in this version o= f the draft. FGLs have global significance but C-VLAN IDs will now have on= ly local significance. It would seem possible that at the edge a DRB and a= non-DRB could both announce VLAN ID 100 in their Hello's but be describing= two different VLANs. RFC 6325 assigned appointed forwarders based on C-VL= AN IDs when C-VLAN IDs had global significance. It would seem appropriate = that FGL RBridges assign AFs based on FGLs since it will be FGLs that have = global significance. =20 Cheers, Olen -----Original Message----- From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of D= onald Eastlake Sent: Wednesday, December 12, 2012 11:29 AM To: trill@ietf.org Subject: Re: [trill] I-D Action: draft-ietf-trill-fine-labeling-03.txt This version has substantial editorial changes in response to comments on t= he list. It is not intended to make technical changes. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Wed, Dec 12, 2012 at 11:25 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. > > Title : TRILL: Fine-Grained Labeling > Author(s) : Donald Eastlake > Mingui Zhang > Puneet Agarwal > Radia Perlman > Dinesh G. Dutt > Filename : draft-ietf-trill-fine-labeling-03.txt > Pages : 27 > Date : 2012-12-12 > > Abstract: > The IETF has standardized TRILL (TRansparent Interconnection of Lots > of Links), a protocol for least cost transparent frame routing in > multi-hop networks with arbitrary topologies and link technologies, > using link-state routing with a hop count. The TRILL base protocol > standard supports labeling of TRILL data with up to 4K IDs. However, > there are applications that require more fine-grained labeling of > data. This document updates RFC 6325 and RFC 6327 by specifying > optional extensions to the TRILL base protocol to safely accomplish > this. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-trill-fine-labeling > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-trill-fine-labeling-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-trill-fine-labeling-03 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill From d3e3e3@gmail.com Sun Dec 23 20:44:47 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD7B321F8B28 for ; Sun, 23 Dec 2012 20:44:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.085 X-Spam-Level: X-Spam-Status: No, score=-103.085 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-7JMGRihRy8 for ; Sun, 23 Dec 2012 20:44:45 -0800 (PST) Received: from mail-ia0-f176.google.com (mail-ia0-f176.google.com [209.85.210.176]) by ietfa.amsl.com (Postfix) with ESMTP id 3150821F8A92 for ; Sun, 23 Dec 2012 20:44:45 -0800 (PST) Received: by mail-ia0-f176.google.com with SMTP id y26so5587082iab.7 for ; Sun, 23 Dec 2012 20:44:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xXaDwWS4bEAL5+NAIi3/uKmAZHJCJldVGOHfqK675Ac=; b=DB4vh0tP/uPSdt7ouU8PvNpwExzG6p/cI6tyActCZMvwMaxAtPu0LfAPlXweLOufCa OtaZ6EyKFLjkJO1DFyc1yCmUto78AKUE3BF/4GiI4plwEh15JZGimz7bRIpPcUybo8nq s0kwwM5Dt2xOSmqV14plyY5zSP7uG/iT/pqrsmtfua+Z401nvgnX2Vn65vTBElw0+mSZ tPOhakJyhN1Zp8iZPdMzRPRfjhlSW+FqMPgRCmOmWXACHSrTj9enJIwPJzioUEO6cUyZ ZqDGPRFZQd97uzaFPutOd7Ijb/IpNRhWlPrXbT4MYfHQ5iC2bzsplcM0N2cr524d6zn/ TqgQ== Received: by 10.50.161.232 with SMTP id xv8mr18741668igb.22.1356324284744; Sun, 23 Dec 2012 20:44:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.28.209 with HTTP; Sun, 23 Dec 2012 20:44:23 -0800 (PST) In-Reply-To: References: <20121212162556.27149.4308.idtracker@ietfa.amsl.com> From: Donald Eastlake Date: Sun, 23 Dec 2012 23:44:23 -0500 Message-ID: To: Olen Stokes Content-Type: text/plain; charset=ISO-8859-1 Cc: "trill@ietf.org" Subject: Re: [trill] I-D Action: draft-ietf-trill-fine-labeling-03.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 04:44:47 -0000 Hi Olen, On Wed, Dec 19, 2012 at 1:19 PM, Olen Stokes wrote: > Thanks for the updated draft. I think that the changes have been > very worthwhile. One thing that the changes made more clear to me > is how tightly the draft ties fine grained labels (FGLs) to C-VLAN > IDs. Going back to RFC 6325, it states that: > > "Use of [802.1ad] S-tags, also known as service tags, and use of > stacked tags, are beyond the scope of this document." Yes, I think think this is inherited, insofar as it is applicable, by the fine grained labeling draft since it updates RFC 6325; a similar statement could be included in that draft. > I take that to mean that the use of S-Tags (or other stacked tags) > is not prohibited, it is just not covered. The encapsulation used > in RFC6325 included the C-Tag which told every RBridge that received > the TRILL packet that the encapsulated packet was a C-Tagged packet. > If someone wanted to extend RFC6325 to describe operation with > S-Tagged packets, it would be straightforward for RBridges to > determine that the encapsulated packet was a S-Tagged packet by > seeing a 0x88A8 instead of a 0x8100. The bottom line is that the > information necessary to determine the packet type of the > encapsulated packet was included in the TRILL packet. > > With FGL, we appear to be losing the ability to determine the packet > type of the encapsulated packet. The draft in several places > describes going between a FGL and a C-VLAN ID. In other words, the > original format of the encapsulated packet could appear to be > limited to C-Tags. It would seem to be appropriate to insure that > FGL can be extendable to supporting S-Tags. For example, the > following two approaches come to mind: > > 1) Assume that Ethertype 0x893B indicates only the presence of a FGL > and that it does not necessarily mean that the encapsulated packet > is a native C-Tagged packet. If pruning is based solely on the FGL > and the DMAC of the encapsulated packet, then D-Tree pruning would > not require an understanding of the format of the encapsulated > packet. As long as all edge RBridges advertising interest in a FGL > agree on the format of the encapsulated packet, then data forwarding > would work correctly. Pruning based on FGL (or VL) and Inner.MacDA of a TRILL Data packet is a reasonable strategy and would have the characteristics you suggest. I believe there are current implementations of TRILL that look deeper into the frames and, if the TRILL Data packet is carrying an IPv4 or IPv6 packet, prune based on the VL and IP destination address. I would assume that such implementations are likely to be extended to work for FGL. > 2) Use a new Ethertype other than 0x893B to indicate that the FGL is > for a S-Tagged (or stacked tag) native packet. Ethertypes are a finite resource so it seems best to avoid using a new one unless necessary. Because the information after the FGL has the usual Ethernet Ethertype/LLC type labeling, if someone has gone outside the bounds of the TRILL documents and put one or more S and/or C tags after an FGL, it seems to me that it can unambiguously parsed. > Some indication of the approach that the authors have in mind would > be very helpful when trying to understand the draft. Well, the draft, sort of by definition, can't say much about what is out of scope... Since the use of VLANs and FGLs is all configured, I would think that a network manager who wanted to encode a bit or two of information about the remainder of the frame could encode that in the FGL. But also, as I said above, I think any known tags pre-fixing the remainder of the frame would be unambiguously pareseable. > This leads to another aspect that became more clear to me in this > version of the draft. FGLs have global significance but C-VLAN IDs > will now have only local significance. That is true if all ports are configured as FGL ports. > It would seem possible that at the edge a DRB and a non-DRB could > both announce VLAN ID 100 in their Hello's but be describing two > different VLANs. RFC 6325 assigned appointed forwarders based on > C-VLAN IDs when C-VLAN IDs had global significance. It would seem > appropriate that FGL RBridges assign AFs based on FGLs since it will > be FGLs that have global significance. Appointed forwarders only have to do with native frames. Within TRILL as specified in the existing RFCs and the FGL draft, native frames can only be either untagged or tagged with a C-VLAN. A native frame with other tagging would, in my opinion, be out of scope. AF has no effect at all on the handling of TRILL Data packets. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > Cheers, > Olen > > -----Original Message----- > From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of Donald Eastlake > Sent: Wednesday, December 12, 2012 11:29 AM > To: trill@ietf.org > Subject: Re: [trill] I-D Action: draft-ietf-trill-fine-labeling-03.txt > > This version has substantial editorial changes in response to comments on the list. It is not intended to make technical changes. > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > > > On Wed, Dec 12, 2012 at 11:25 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: Fine-Grained Labeling >> Author(s) : Donald Eastlake >> Mingui Zhang >> Puneet Agarwal >> Radia Perlman >> Dinesh G. Dutt >> Filename : draft-ietf-trill-fine-labeling-03.txt >> Pages : 27 >> Date : 2012-12-12 >> >> Abstract: >> The IETF has standardized TRILL (TRansparent Interconnection of Lots >> of Links), a protocol for least cost transparent frame routing in >> multi-hop networks with arbitrary topologies and link technologies, >> using link-state routing with a hop count. The TRILL base protocol >> standard supports labeling of TRILL data with up to 4K IDs. However, >> there are applications that require more fine-grained labeling of >> data. This document updates RFC 6325 and RFC 6327 by specifying >> optional extensions to the TRILL base protocol to safely accomplish >> this. >> >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-trill-fine-labeling >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-trill-fine-labeling-03 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-trill-fine-labeling-03 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ From d3e3e3@gmail.com Sun Dec 23 20:57:54 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A66FC21F8C08 for ; Sun, 23 Dec 2012 20:57:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.082 X-Spam-Level: X-Spam-Status: No, score=-103.082 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxUEH1DmM4Uj for ; Sun, 23 Dec 2012 20:57:53 -0800 (PST) Received: from mail-ia0-f178.google.com (mail-ia0-f178.google.com [209.85.210.178]) by ietfa.amsl.com (Postfix) with ESMTP id A139D21F8C03 for ; Sun, 23 Dec 2012 20:57:53 -0800 (PST) Received: by mail-ia0-f178.google.com with SMTP id k25so5605579iah.37 for ; Sun, 23 Dec 2012 20:57:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=h0EhDqf2gLZ05rZxu1oaAQ0G01QUq6LAX0BgI/T4Uss=; b=Tq3LycDvrvFm0T0d1wedqHxzzhXINLo7WpzUmfYOOfe//y+Q3Pc5rolmTFmj4Fpozi Rj1aueB0/D0kN1y04YiSZvgSusLurcEKmRZ3nzRys5at6rvaEAXPxhzkK8O9QrplDEvx kAn1hdUOMnVwJcwdd11D7X+iR8Ww9Aj4Hgb0pGq4Zl7QDxE1y83/W+/pSXBzFt2f7ZYV hQshqVf3DOKT7ocKDsRKKLNVeTasRC0ew+Ml8A5bVQiA791kpQNsSe4aLpT+VFzzLHdD dCYnyrGKa9aK3HtoOyperdJcXdKrzEoyK0E3RxzYy9nBHHSLVM8fOftvWBDGgil5BJqr KhuA== Received: by 10.43.124.130 with SMTP id go2mr16595526icc.8.1356325073236; Sun, 23 Dec 2012 20:57:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.28.209 with HTTP; Sun, 23 Dec 2012 20:57:32 -0800 (PST) In-Reply-To: <201212131645.qBDGjFUU059408@skyhighway.com> References: <201212131645.qBDGjFUU059408@skyhighway.com> From: Donald Eastlake Date: Sun, 23 Dec 2012 23:57:32 -0500 Message-ID: To: gayle noble Content-Type: text/plain; charset=ISO-8859-1 Cc: trill@ietf.org Subject: Re: [trill] corrections ->draft-ietf-trill-fine-labeling-03 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 04:57:54 -0000 Hi Gayle, Thanks for your review. I agree with your corrections except where noted. On Thu, Dec 13, 2012 at 11:45 AM, gayle noble wrote: > (in my opinion) grammatical and spelling corrections to corrections > draft-ietf-trill-fine-labeling-03 > ------- > 1.1 Terminology (page 3) > Edge TRILL switch - A TRILL switch announcing VLAN or Fien [Fine]Grained > Lab el [Label] interest in its LSP. > > 4. Alternate Priority (page 6) > It would be desirable for an ingress TRILL Switch to be able to assign a > different priority to an [a] FGL TRILL Data frame for its ingress-to-egress > propagation from the priority of the original native frame. I suppose it depends on how you pronounce "FGL". I think it is as spelled out like "ef-gee-el", in which case I think "an" is correct. But there could be other pronunciations, such as "figul" for which "a" is correct... This applies to your similar suggestions below. > 2.4 VL, Limited FGL, and Full FGL TRILL Switches (page 8) > It will be simpler to use the same type of label for all TRILL switche > [switches] for this purpose. > > If a campus is being upgraded from VL [to] FGL TRILL switches, it avoids a > requirement to immediately reconfigure all ports with FGL configuration. > > As discussed in Section 4, VL TRILL switches conformant to [RFC6325] should > discard an [a] FGL TRILL Data frame as malformed. > > 3. VL versus FGL Label Differences (page 10) > With FGL TRILL switches, many things remain the same because an [a]FGL can > appear only as the Inner.Label inside a TRILL Data frame. > > Thus, for ports configured for FGL, the native frame C-VLAN on one link > corresponding to an [a] FGL can be different from the native frame C-VLAN > corresponding to that same FGL on a different link elsewhere in the campus > or even a different link attached to the same TRILL switch > > 4.2 FGL and VL Mixed Campus Characteristics (page 12) > The [There] are possible future extensions to TRILL that would eliminate the > requirement to block TRILL Data traffic between FGL and VL TRILL switches > improving backwards compatibility. > > 5.1 Ingress Processing (page 14) > Thus Full FGL TRILL switches MUST support configurable per port mapping from > the C-VLAN of a native frame, as reported by the ingress port, to an [a]FGL. > > 5.2.2 Multi-Destination Transit Processing (page 15) > Multi-destination TRILL Data frames are forwarded on a distribution tree > selected by the ingress TRILL switch except that an [a] FGL ingress TRILL > switch may TRILL unicast such a frame to all relevant egress TRILL switches > as described in Section 5.1. > > An [A] FGL TRILL switch, say RB1, having an [a] FGL multi-destination frame > for label (X.Y) to forward on a distribution tree, SHOULD prune that tree > based on whether there are any edge TRILL switches on a tree branch that are > advertising connectivity to label (X.Y). > > 5.3 Egress Processing (page 16) > > A Full FGL TRILL switch MUST be able to configurably [be configured to] > convert the FGL in an FGL TRILL Data frame it is egressing to a C-VLAN ID > for the resulting native frame on a per port basis. The statement is trying to say not just that it can be configured to covert, but that the exact mapping is configurable. Perhaps "... be able to covert is a configurable fashion between the FGL in an FGL TRILL Data frame it is egressing and a C-VLAN ID..." > An [A] FGL TRILL switch egresses FGL frames similarly to the egressing of VL > frames, as follows: > > If there are no such ports, it is flooded out all FGL ports that have its > FGL except any ports that for which the TRILL switch has knowledge that > the frame's Inner.MacDA cannot be [go] out that port. The idea is that the TRILL switch has some knowledge (perhaps configured by the network manager or due to a layer 2 registration protocol) that some MAC address cannot be present on the link to which a port is connected. Perhaps "...that the frame's Inner.MacDA cannot be present on the link out that port." > An [A] FGL TRILL switch, including a Limited FGL TRILL switch that might > have limited knowledge of FGL formats, MUST NOT egress an [a] FGL frame with > label (X.Y) to any port not configured with that label even if the port is > configured to egress VL frames in VLAN X. > > 5.5 Address Learning (page 17) > An [A] FGL TRILL switch learns addresses on ports configured for FGL based > on the fine-grained label rather than the native frame's VLAN. > > (page 22) > As a result, no TRILL data frames can be exchanged between VL and FGL TRILL > switches and they will be isolated form [from] each other for data purposes. Sorry to the level of typos, Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From windy_1@skyhighway.com Sun Dec 23 21:15:05 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42CDD21F8A0D for ; Sun, 23 Dec 2012 21:15:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[AWL=1.095, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMxXTDwPmTN1 for ; Sun, 23 Dec 2012 21:15:04 -0800 (PST) Received: from skyhighway.com (skyhighway.com [63.249.82.6]) by ietfa.amsl.com (Postfix) with ESMTP id 718C121F85FD for ; Sun, 23 Dec 2012 21:14:58 -0800 (PST) Received: from Firefly.skyhighway.com (dsl-63-249-88-160.static.cruzio.com [63.249.88.160]) by skyhighway.com with ESMTP id qBO5EvBm005857 for ; Sun, 23 Dec 2012 21:14:57 -0800 (PST) Message-Id: <201212240514.qBO5EvBm005857@skyhighway.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 23 Dec 2012 21:14:50 -0800 To: trill@ietf.org From: gayle noble In-Reply-To: References: <201212131645.qBDGjFUU059408@skyhighway.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [trill] corrections ->draft-ietf-trill-fine-labeling-03 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 05:15:05 -0000 Donald, Thanks so much for explaining this stuff to me. I'm fairly good with spelling and grammar, but I'm just learning TRILL. I'm hoping to be useful until I gather enough knowledge to contribute. thanks again gayle From internet-drafts@ietf.org Mon Dec 31 19:56:52 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F13721F8919; Mon, 31 Dec 2012 19:56:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UoKIaJBaPtJr; Mon, 31 Dec 2012 19:56:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEFDE21F8804; Mon, 31 Dec 2012 19:56:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130101035651.28442.1607.idtracker@ietfa.amsl.com> Date: Mon, 31 Dec 2012 19:56:51 -0800 Cc: trill@ietf.org Subject: [trill] I-D Action: draft-ietf-trill-fine-labeling-04.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2013 03:56:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transparent Interconnection of Lots of Li= nks Working Group of the IETF. Title : TRILL: Fine-Grained Labeling Author(s) : Donald Eastlake Mingui Zhang Puneet Agarwal Radia Perlman Dinesh G. Dutt Filename : draft-ietf-trill-fine-labeling-04.txt Pages : 27 Date : 2012-12-31 Abstract: The IETF has standardized TRILL (TRansparent Interconnection of Lots of Links), a protocol for least cost transparent frame routing in multi-hop networks with arbitrary topologies and link technologies, using link-state routing and a hop count. The TRILL base protocol standard supports labeling of TRILL data with up to 4K IDs. However, there are applications that require more fine-grained labeling of data. This document updates RFC 6325 and RFC 6327 by specifying optional extensions to the TRILL base protocol to safely accomplish this. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trill-fine-labeling There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-trill-fine-labeling-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-trill-fine-labeling-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From d3e3e3@gmail.com Mon Dec 31 19:59:18 2012 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A6321F891D for ; Mon, 31 Dec 2012 19:59:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.374 X-Spam-Level: X-Spam-Status: No, score=-103.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2f+yfCzhVyam for ; Mon, 31 Dec 2012 19:59:14 -0800 (PST) Received: from mail-oa0-f47.google.com (mail-oa0-f47.google.com [209.85.219.47]) by ietfa.amsl.com (Postfix) with ESMTP id C73DA21F8919 for ; Mon, 31 Dec 2012 19:59:14 -0800 (PST) Received: by mail-oa0-f47.google.com with SMTP id h1so12350920oag.34 for ; Mon, 31 Dec 2012 19:59:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=M30857eYfFC+qp6PBxucMmaO3o+tQ9Rop29B9JILC4I=; b=FK8aSBi3ipm0h1CKKFd/OiV4cXFencSySD9Cx8vD2bQaAZq1E1fgR/PTsQ5X1sW5Yo 25hhp8MGPkwLjeGrHbuatGoRKPzdgqEN9E+iC5KpuWE/JBjKaV5tgfI4XFl1XgEAPnAS qb/g1yt3RTkdKhWaZ4YhOHVT0vsrjC8YDDDS7Or50rZLn8SNlQEACja5pQuUCQrgnS3o TmURwI7LtTgARYVYUiklGpe2UPZwFkh1QiTdKTAlGt51wE3c9QD1KBsEm69AHoxmk9p2 FHt0nudf8AG4YMCS/ryWnPB4691LPFxHR7lsqs1Uur/Dv/eWC1brneb9LIFdG0c1LjUO fcsg== Received: by 10.182.207.8 with SMTP id ls8mr32379181obc.65.1357012754262; Mon, 31 Dec 2012 19:59:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.144.105 with HTTP; Mon, 31 Dec 2012 19:58:54 -0800 (PST) In-Reply-To: <20130101035651.28442.1607.idtracker@ietfa.amsl.com> References: <20130101035651.28442.1607.idtracker@ietfa.amsl.com> From: Donald Eastlake Date: Mon, 31 Dec 2012 22:58:54 -0500 Message-ID: To: trill@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [trill] I-D Action: draft-ietf-trill-fine-labeling-04.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2013 03:59:19 -0000 There are no technical changes in this version, just a few minor typo fixes and editorial changes. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Mon, Dec 31, 2012 at 10:56 PM, 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: Fine-Grained Labeling > Author(s) : Donald Eastlake > Mingui Zhang > Puneet Agarwal > Radia Perlman > Dinesh G. Dutt > Filename : draft-ietf-trill-fine-labeling-04.txt > Pages : 27 > Date : 2012-12-31 > > Abstract: > The IETF has standardized TRILL (TRansparent Interconnection of Lots > of Links), a protocol for least cost transparent frame routing in > multi-hop networks with arbitrary topologies and link technologies, > using link-state routing and a hop count. The TRILL base protocol > standard supports labeling of TRILL data with up to 4K IDs. However, > there are applications that require more fine-grained labeling of > data. This document updates RFC 6325 and RFC 6327 by specifying > optional extensions to the TRILL base protocol to safely accomplish > this. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-trill-fine-labeling > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-trill-fine-labeling-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-trill-fine-labeling-04 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill

I have some questions about the sending and processi= ng of the TREES-RT-ID and TREES-USE-ID sub-TLV in the Router Capability TLV= .  I need a little clarification with respect to when these sub-TLVs a= re sent and who sends them.  I’ve outlined how I interpreted parts of the Distribution Tree section RFC632 with respe= ct to these sub-TLVs, but I need a little validation. 

 

Note, the quoted items are taken directly from RFC63= 25.

 

 

1) Only the highest priority Rbridge needs to send o= ut TREES-RT-ID sub-TLV, correct?

“The number of trees, = k, that are computed for the campus is the number wanted by the RBridge RB1= , which has the nickname with the highest "tree root" priority”

 

 

2) Rbridges will calculate the highest priority k tr= ees if they don't  receive TREES-RT-ID sub-TLV.  This implies it'= s *NOT* mandatory for highest priority Rbridge to send TREES-RT-ID sub-TLV, = correct?

“If RB1 does not speci= fy the specific distribution tree roots as described below, then the k high= est priority trees are the trees that will be computed by all RBridges.”

 

 

3) ALL Rbridges, RB2, that ingress native traffic MUST send TREES-USE-ID sub-TLV, correct?   This is required = for RPF check used by adjacent RBridges.

“each RBridge RB2 MUST announce which trees RB2 may = choose when RB2 ingresses a multi-destination packet.”

 

4) Transit-only RBridges do NOT need to send = TREES-USE-ID sub-TLV, correct?  Since TREES-USE-ID indicates what tree= s a RBridge may use for ingressing native traffic, Transit-only RBridges ha= ve nothing to advertise.

 

 

5) Ingress RBridges, RB2, can specify, via user conf= ig, a set of j trees to use.   If NO trees in the set of j trees = intersect with the k highest priority  trees advertised by the Rbridge= with highest root priority, NONE of the  j trees are advertised.  Ingress RBridges, RB2, will then advertise the k &nb= sp;highest priority trees in the TREES-USE-ID sub-TLV. Correct?<= /p>

OR, does RB2 advertise whatever it wishes, and the R= Bridge receiving the LSP examine the intersection of j with k?

 

If no set of j trees is explicitly configured, will = RB2 advertise the k highest priority trees in the TREES-USE-ID sub-TLV, or = none at all.  What’s not clear is if in the special case of j=3D= =3D0, do we still have to include the sub-TLV in the LSP?  I would think the neighboring RBridge can assume if the TRE= ES-USE-ID sub-TLV is not present, that means j=3D=3D0 and RB2 will use the = k highest priority trees.   Seems explicitily advertisine the k h= ighest trees may be the “safe” thing to do for interoperability= , but is it the “right” thing to do?

 

“The information to determine which trees RB2 might = choose is included in RB2’s LSP. Similarly to how the highest priorit= y RBridge RB1 specifies the k trees that will be computed by all RBridges, RB2 specifies a number j, which is the total number of di= fferent trees RB2 might specify, and the specific trees RB2 might specify a= re a combination of specified trees and trees selected from highest priorit= y trees. If RB2 specifies any trees that are not in the k trees as specified by RB1, they are ignored.

 

The j potential ingress trees for RB2 are the ones with ni= cknames that RB2 has explicitly specified in "specified ingress tree n= icknames" (and that are included in the k campus-wide trees selected by highest priority RBridge RB1), with the remainder (up to= the maximum of {j,k}) being the highest priority of the k campus-wide tree= s.”

 

When the RFC refers to RB2’s LSP it is= referring to the TREES-US-ID sub-TLV, correct?

The j potential ingress trees this section talks abo= ut would be manually configured by the user, correct?

<= o:p> 

If no j trees are specified, does RB2 default to sen= ding out the k trees in the TREES-USE-ID sub-TLV, an empty TREES-USE-ID sub= -TLV, or RB2 does not send any TREES-USE-ID sub-TLV at all?

 

If j >=3D k and no tree in j intersects k, all j = trees are ignored.  Does this imply neighbors should not expect dTree = traffic from RB2?