From nobody Sun May 1 06:32:13 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 810F212D0BB for ; Sun, 1 May 2016 06:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TigmDGrnbAv4 for ; Sun, 1 May 2016 06:32:10 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1927112D0AD for ; Sun, 1 May 2016 06:32:10 -0700 (PDT) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.11/8.16.0.11) with SMTP id u41DTJiP021962; Sun, 1 May 2016 09:32:01 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049463.ppops.net-00191d01. with ESMTP id 22njqp81mk-14 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 01 May 2016 09:32:01 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u41DMVC8018327; Sun, 1 May 2016 09:22:32 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u41DMPQx018261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 1 May 2016 09:22:27 -0400 Received: from MISOUT7MSGHUBAC.ITServices.sbc.com (MISOUT7MSGHUBAC.itservices.sbc.com [130.9.129.147]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Sun, 1 May 2016 13:22:18 GMT Received: from MISOUT7MSGUSRCD.ITServices.sbc.com ([169.254.4.21]) by MISOUT7MSGHUBAC.ITServices.sbc.com ([130.9.129.147]) with mapi id 14.03.0294.000; Sun, 1 May 2016 09:22:18 -0400 From: "UTTARO, JAMES" To: "'John G. Scudder'" , "'Jakob Heitz (jheitz)'" Thread-Topic: [Idr] BGP persistence Thread-Index: AQHRoiOZxY3tynlL7U+1m/QeYzMTpZ+hSFSAgALMOzA= Date: Sun, 1 May 2016 13:22:16 +0000 Message-ID: References: <1BE5582B-90D5-4C99-8807-EC6202523E4B@juniper.net> In-Reply-To: <1BE5582B-90D5-4C99-8807-EC6202523E4B@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.158.192] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-05-01_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1605010217 Archived-At: Cc: "'idr@ietf.org'" Subject: Re: [Idr] BGP persistence X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 13:32:11 -0000 +1.. We are using this.. -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder Sent: Friday, April 29, 2016 10:38 AM To: Jakob Heitz (jheitz) Cc: idr@ietf.org Subject: Re: [Idr] BGP persistence It's a fair question! The last time the WG discussed adopting the item, as I recall there was no = consensus to do so. It seems as though we should be able to have the conver= sation again at this point. As you say, we now have actual experience with = it, which hopefully will help inform the discussion. Also, the current form= of the document reflects many updates made to address concerns expressed b= y the WG about previous versions, so even though it wasn't a WG document, t= he authors were listening and responding to the WG feedback. With WG chair hat firmly off my head and contributor-to-the-document hat pr= ominently displayed, let me suggest (or rather, second Jakob's indirect sug= gestion) that we adopt and progress the document. Thanks for bringing it up, --John > On Apr 29, 2016, at 10:29 AM, Jakob Heitz (jheitz) wro= te: >=20 > Why is this > https://tools.ietf.org/html/draft-uttaro-idr-bgp-persistence-03 > persistently not an RFC? > We have had an implementation for at least a couple of years and others h= ave also. >=20 > -- > Jakob Heitz. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Sun May 1 15:57:27 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA3812D0DA for ; Sun, 1 May 2016 15:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6-PpT90i7vf for ; Sun, 1 May 2016 15:57:23 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B14912D0AB for ; Sun, 1 May 2016 15:57:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1899; q=dns/txt; s=iport; t=1462143443; x=1463353043; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=7GQyeQalHPMlE+xO98VuSCLnw5kuPCzWpCrjSg96CSk=; b=NtBqQM1BL7DpDfPFnuWUX126eF8R3Ldhx3xWv27fVWcki+3EZ/3/vxQU ppZ/npg78qR0ziSxG6l9rzHhEe7cEUGHL/rI/MXDwqH5LlRmYRbbxXwHw LjyzoopwdAgPa8h3NIj2h4X7iPmj3jA1k5vRConQ95e3PD3gdQWRta+Ch 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AQCdiCZX/5tdJa1cgzhTfQapbpABA?= =?us-ascii?q?Q2BdhcNhWwCgRo4FAEBAQEBAQFlJ4RBAQEBBAEBATc0CwwEAgEIEQQBAR8JByc?= =?us-ascii?q?LFAkIAgQBDQWIKg62PAEBAQEBAQEBAQEBAQEBAQEBAQEBAREEhiGETIoTAQSYF?= =?us-ascii?q?AGFe2+HLYFnjSqPMAEeAQFCg2tsiAh/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,564,1454976000"; d="scan'208";a="97991600" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 May 2016 22:57:22 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u41MvMaQ026813 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 1 May 2016 22:57:22 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 1 May 2016 17:57:20 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1104.009; Sun, 1 May 2016 17:57:21 -0500 From: "Bertrand Duvivier (bduvivie)" To: "'John G. Scudder'" , "Jakob Heitz (jheitz)" Thread-Topic: [Idr] BGP persistence Thread-Index: AQHRoiOZxY3tynlL7U+1m/QeYzMTpZ+hWRiAgAMPaACAAMIxgA== Date: Sun, 1 May 2016 22:57:21 +0000 Message-ID: References: <1BE5582B-90D5-4C99-8807-EC6202523E4B@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.173.58] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "'idr@ietf.org'" Subject: Re: [Idr] BGP persistence X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 22:57:25 -0000 John, BGP persistence is deployed by 10+ customers already, mostly in BGP flowspec use-cases. Thus +1=20 Best Regards Bertrand Duvivier Cisco System. https://www.youtube.com/playlist?list=3DPLcSD8Cbk0fFHTO4bnb3NC8pJka3_ZvoRY > >-----Original Message----- >From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder >Sent: Friday, April 29, 2016 10:38 AM >To: Jakob Heitz (jheitz) >Cc: idr@ietf.org >Subject: Re: [Idr] BGP persistence > >It's a fair question! > >The last time the WG discussed adopting the item, as I recall there was >no consensus to do so. It seems as though we should be able to have the >conversation again at this point. As you say, we now have actual >experience with it, which hopefully will help inform the discussion. >Also, the current form of the document reflects many updates made to >address concerns expressed by the WG about previous versions, so even >though it wasn't a WG document, the authors were listening and responding >to the WG feedback. > >With WG chair hat firmly off my head and contributor-to-the-document hat >prominently displayed, let me suggest (or rather, second Jakob's indirect >suggestion) that we adopt and progress the document. > >Thanks for bringing it up, > >--John > >> On Apr 29, 2016, at 10:29 AM, Jakob Heitz (jheitz) >>wrote: >>=20 >> Why is this >> https://tools.ietf.org/html/draft-uttaro-idr-bgp-persistence-03 >> persistently not an RFC? >> We have had an implementation for at least a couple of years and others >>have also. >>=20 >> -- >> Jakob Heitz. > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From nobody Mon May 2 00:11:01 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2525212B00D; Mon, 2 May 2016 00:11:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160502071100.23772.98345.idtracker@ietfa.amsl.com> Date: Mon, 02 May 2016 00:11:00 -0700 Archived-At: Cc: draft-ietf-idr-add-paths@ietf.org, russ@riw.us, idr@ietf.org, idr-chairs@ietf.org Subject: [Idr] Alexey Melnikov's Discuss on draft-ietf-idr-add-paths-14: (with DISCUSS and COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 07:11:00 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-idr-add-paths-14: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-idr-add-paths/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is a well written document. I have one small issue to discuss before voting "no objection". At the end of section 2: why path identifier "SHOULD be treated as opaque" instead of "MUST be treated as opaque"? What are possible reasons to violate the SHOULD? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- It would be better if section 6 is moved earlier in the document, so that readers can understand why bother with this extension. From nobody Mon May 2 02:29:29 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE0F012D13F for ; Mon, 2 May 2016 02:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.915 X-Spam-Level: X-Spam-Status: No, score=-2.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9iLyleKM1-i for ; Mon, 2 May 2016 02:29:25 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F3EC12D0CD for ; Mon, 2 May 2016 02:29:24 -0700 (PDT) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 0F355C0842; Mon, 2 May 2016 11:29:23 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.58]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id CB1EC1C006F; Mon, 2 May 2016 11:29:22 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0279.002; Mon, 2 May 2016 11:29:22 +0200 From: To: "UTTARO, JAMES" , "'John G. Scudder'" , "'Jakob Heitz (jheitz)'" Thread-Topic: [Idr] BGP persistence Thread-Index: AQHRoiOZxY3tynlL7U+1m/QeYzMTpZ+g47+AgAMPaACAAXCh8A== Date: Mon, 2 May 2016 09:29:22 +0000 Message-ID: <31522_1462181362_57271DF2_31522_142_1_53C29892C857584299CBF5D05346208A0F882DCC@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <1BE5582B-90D5-4C99-8807-EC6202523E4B@juniper.net> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "'idr@ietf.org'" Subject: Re: [Idr] BGP persistence X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 09:29:26 -0000 +1 as a co-author +1 as an IDR contributor: having the discussions on the IDR mailing list, a= llows IDR participants to contribute, improve the document, and increase it= s applicability. (unfortunately, at this point, it seems already a bit late) Thanks -- Bruno > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of UTTARO, JAMES > Sent: Sunday, May 01, 2016 3:22 PM > To: 'John G. Scudder'; 'Jakob Heitz (jheitz)' > Cc: 'idr@ietf.org' > Subject: Re: [Idr] BGP persistence >=20 > +1.. >=20 > We are using this.. >=20 > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder > Sent: Friday, April 29, 2016 10:38 AM > To: Jakob Heitz (jheitz) > Cc: idr@ietf.org > Subject: Re: [Idr] BGP persistence >=20 > It's a fair question! >=20 > The last time the WG discussed adopting the item, as I recall there was no > consensus to do so. It seems as though we should be able to have the > conversation again at this point. As you say, we now have actual experien= ce > with it, which hopefully will help inform the discussion. Also, the curre= nt form > of the document reflects many updates made to address concerns > expressed by the WG about previous versions, so even though it wasn't a > WG document, the authors were listening and responding to the WG > feedback. >=20 > With WG chair hat firmly off my head and contributor-to-the-document hat > prominently displayed, let me suggest (or rather, second Jakob's indirect > suggestion) that we adopt and progress the document. >=20 > Thanks for bringing it up, >=20 > --John >=20 > > On Apr 29, 2016, at 10:29 AM, Jakob Heitz (jheitz) > wrote: > > > > Why is this > > https://tools.ietf.org/html/draft-uttaro-idr-bgp-persistence-03 > > persistently not an RFC? > > We have had an implementation for at least a couple of years and others > have also. > > > > -- > > Jakob Heitz. >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Mon May 2 02:36:01 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B7C6B12B008; Mon, 2 May 2016 02:35:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160502093559.23688.94285.idtracker@ietfa.amsl.com> Date: Mon, 02 May 2016 02:35:59 -0700 Archived-At: Cc: draft-ietf-idr-add-paths@ietf.org, russ@riw.us, idr@ietf.org, idr-chairs@ietf.org Subject: [Idr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-idr-add-paths-14=3A_=28with_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 09:36:00 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-idr-add-paths-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-idr-add-paths/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Two quick comments: 1) Section 6 says: „The applications are detailed in separate documents.“ Does this doc already exists? A reference would be good! 2) One clarification question: When a path with a new identifier is advertised this actually does not mean that these two paths are different, right? Some one could advertise the same path twice with different identifiers, right? Should this be explicitly mention somewhere? From nobody Mon May 2 10:58:03 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1662012D5CE; Mon, 2 May 2016 10:58:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160502175801.15655.80242.idtracker@ietfa.amsl.com> Date: Mon, 02 May 2016 10:58:01 -0700 Archived-At: Cc: draft-ietf-idr-add-paths@ietf.org, russ@riw.us, idr@ietf.org, idr-chairs@ietf.org Subject: [Idr] Kathleen Moriarty's No Objection on draft-ietf-idr-add-paths-14: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 17:58:01 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-idr-add-paths-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-idr-add-paths/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1. I'd like to see the security considerations explicitly state that this could result in a denial of service attack. The resource consumption is stated nicely, but it would be good (following RFC3552) to state the type of attack. "This document defines a BGP extension that allows the advertisement of multiple paths for the same address prefix without the new paths implicitly replacing any previous ones. As a result, multiple paths for a large number of prefixes may be received by a BGP speaker potentially depleting memory resources or even causing network-wide instability." Adding something like: "This could result in a denial of service attack." 2. Change the last sentence of the security considerations section in light of the first paragraph to something like: From: This document introduces no new security concerns in the base operation of BGP [RFC4271]. To: Security concerns in the base operation of BGP [RFC4271] also apply. From nobody Tue May 3 03:36:13 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A4EBD12D729; Tue, 3 May 2016 03:36:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160503103611.7402.3181.idtracker@ietfa.amsl.com> Date: Tue, 03 May 2016 03:36:11 -0700 Archived-At: Cc: draft-ietf-idr-add-paths@ietf.org, russ@riw.us, idr@ietf.org, idr-chairs@ietf.org Subject: [Idr] Stephen Farrell's No Objection on draft-ietf-idr-add-paths-14: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 10:36:11 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-idr-add-paths-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-idr-add-paths/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - section 2: This bit wasn't entirely clear to me: "A BGP speaker that re-advertises a route MUST generate its own Path Identifier to be associated with the re-advertised route." It wasn't clear to me if that means it's disallowed to use the same path identifier or not when re-advertising. If it's not allowed that'd seem to warrant a "MUST NOT" statement, or to say that the path identifier re-advertised MUST be different from that in the received advertisement - "it's own" doesn't quite say the same to me. - section 5: I wasn't clear what happens in the following case. Alice advertises prefix-A with no path identifier, then prefix-A with some path identifier. Next Alice withdraws prefix-A with no associated path identifier. What happens when I get that sequence? (It may well be clear for those readers who know more about BGP.) - What is "bestpath"? If that's defined elsewhere a reference would be good. (A quick duckduckgo only showed me Cisco specific answers for bestpath, but others for "best path.") - Section 5 (last para): what would "special care" here mean? If that'd be clear to relevant readers, that's fine. From nobody Tue May 3 07:13:41 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9232C12D817; Tue, 3 May 2016 07:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bvp3ca2n4up; Tue, 3 May 2016 07:13:36 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0697A12D811; Tue, 3 May 2016 07:13:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1125; q=dns/txt; s=iport; t=1462284814; x=1463494414; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=eMc1Y9sCaD7KCzq95b7LBiHvrFXkzTZwNuCfCjXUHUo=; b=fTwUmuIaZm9W8rRNPjwIjW+oE3qE7Ztln78lSgtWy/Xh6rJy5MwFT722 cqS4d+O4jTj1kyP9Ga4w7a2kyjSd3oC3VIGQ7UHFKaU3wQc5HhvvLASwW maGCCiO9OMvN9mz+XhbYPTKcWCrQg4vjG+NxVa1LRc5zz9AfoLtqPn/F9 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgB+sShX/5xdJa1fgziBUAa3fYIPA?= =?us-ascii?q?Q2BdYYQAoE9OBQBAQEBAQEBZSeEQgEBBDo/EAIBCA4oEDIlAgQBDQWIKrwXAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAReGIIRNihgBBId4iyyEcgGOF48SjzEBHgEBQoI2g?= =?us-ascii?q?TVshz1/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,572,1454976000"; d="scan'208";a="100506901" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 May 2016 14:13:32 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u43EDWit007049 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 May 2016 14:13:32 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 3 May 2016 09:13:32 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Tue, 3 May 2016 09:13:32 -0500 From: "Alvaro Retana (aretana)" To: Alexey Melnikov , The IESG Thread-Topic: Alexey Melnikov's Discuss on draft-ietf-idr-add-paths-14: (with DISCUSS and COMMENT) Thread-Index: AQHRpEHOtLEMAAVoHkW0fuj9GHg0Xp+nVCeA Date: Tue, 3 May 2016 14:13:32 +0000 Message-ID: References: <20160502071100.23772.98345.idtracker@ietfa.amsl.com> In-Reply-To: <20160502071100.23772.98345.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.247.116] Content-Type: text/plain; charset="us-ascii" Content-ID: <40C335109B8C454FBD90A9FAB3E3C02F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-idr-add-paths@ietf.org" , "russ@riw.us" , "idr-chairs@ietf.org" , "idr@ietf.org" Subject: Re: [Idr] Alexey Melnikov's Discuss on draft-ietf-idr-add-paths-14: (with DISCUSS and COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 14:13:39 -0000 On 5/2/16, 3:11 AM, "iesg on behalf of Alexey Melnikov" wrote: [Author hat on.] Alexei: Hi! >Alexey Melnikov has entered the following ballot position for >draft-ietf-idr-add-paths-14: Discuss I think you reviewed version -13. Both your points below have already been addressed in -14. Thanks! Alvaro. >---------------------------------------------------------------------- >DISCUSS: >---------------------------------------------------------------------- > >This is a well written document. I have one small issue to discuss before >voting "no objection". > >At the end of section 2: why path identifier "SHOULD be treated as >opaque" instead of "MUST be treated as opaque"? What are possible reasons >to violate the SHOULD? > > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >It would be better if section 6 is moved earlier in the document, so that >readers can understand why bother with this extension. From nobody Tue May 3 07:29:05 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EAA612D822 for ; Tue, 3 May 2016 07:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=OjMyKXAH; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=PCE7qnzi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LmCRyf1GpH3F for ; Tue, 3 May 2016 07:29:02 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E926F12D824 for ; Tue, 3 May 2016 07:29:01 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 4C3A520CE0 for ; Tue, 3 May 2016 10:29:01 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute1.internal (MEProxy); Tue, 03 May 2016 10:29:01 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=ItNsmjmEJiMR7zP+D6lLL1+Bea0=; b=OjMyKX AHghmbDhol/v6v4l2DQDlaL94oRxsw09boEyOYyGSk8lp0dd/WVHNQJqO3T0a5jk qUh+61dM65PPHX12Hxl2owl2pBzwQYpXc5OuguAhGSFYTmMHLbMssBOwSrTxtx+B mc1o+gpHTeGofauIjfor7CYPKQ9aH5I23e0gk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=ItNsmjmEJiMR7zP +D6lLL1+Bea0=; b=PCE7qnziiyMY1ml+db4UBXAWvIwXuJCHO8x9aB1bqvUhbmr OytKOxdmRg2nUk4nB9ikiIYGpbbDxwNXOEmdsmDHEFfiRmLMJZ/kZ5NenA3cWKpF FrYkYyvrU7funFYtjFjapsibJwrrNL8FuGAft+J0BfIFPxaX1psitFqY8N4c= Received: by web5.nyi.internal (Postfix, from userid 99) id 1BD08A6E4DF; Tue, 3 May 2016 10:29:01 -0400 (EDT) Message-Id: <1462285741.2483521.596787561.4D532DFD@webmail.messagingengine.com> X-Sasl-Enc: sTOxf0p6clpTauUON+e9E3ATnJ94s/CTbT1Um4k1SLvS 1462285741 From: Alexey Melnikov To: Alvaro Retana (aretana), The IESG MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-103fcf22 Date: Tue, 03 May 2016 15:29:01 +0100 In-Reply-To: References: <20160502071100.23772.98345.idtracker@ietfa.amsl.com> Archived-At: Cc: draft-ietf-idr-add-paths@ietf.org, russ@riw.us, idr-chairs@ietf.org, idr@ietf.org Subject: Re: [Idr] Alexey Melnikov's Discuss on draft-ietf-idr-add-paths-14: (with DISCUSS and COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 14:29:04 -0000 Hi Alvaro, Good point well presented :-)! I will clear. On Tue, May 3, 2016, at 03:13 PM, Alvaro Retana (aretana) wrote: > On 5/2/16, 3:11 AM, "iesg on behalf of Alexey Melnikov" > wrote: > > [Author hat on.] > > Alexei: > > Hi! > > >Alexey Melnikov has entered the following ballot position for > >draft-ietf-idr-add-paths-14: Discuss > > I think you reviewed version -13. Both your points below have already > been addressed in -14. > > Thanks! > > Alvaro. > > > >---------------------------------------------------------------------- > >DISCUSS: > >---------------------------------------------------------------------- > > > >This is a well written document. I have one small issue to discuss before > >voting "no objection". > > > >At the end of section 2: why path identifier "SHOULD be treated as > >opaque" instead of "MUST be treated as opaque"? What are possible reasons > >to violate the SHOULD? > > > > > >---------------------------------------------------------------------- > >COMMENT: > >---------------------------------------------------------------------- > > > >It would be better if section 6 is moved earlier in the document, so that > >readers can understand why bother with this extension. > From nobody Tue May 3 07:45:17 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1E212D84B; Tue, 3 May 2016 07:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2tAkkFT6qcKe; Tue, 3 May 2016 07:45:15 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E11E112D84A; Tue, 3 May 2016 07:45:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=775; q=dns/txt; s=iport; t=1462286714; x=1463496314; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=GI4c/Dgxb8p1AWWoUBKU6G/pI/bTPwsdzNatPmn/zfU=; b=JVQim9NfQlmMeYg4ZsteQaTnEFvtixqecvkrrIWMpmiEu4teFMuFKr06 RW/CfSxj83t9jX4Z7rkQLgCZ/fgo7a3vxH9Bu9dry0bKhBP2HjJtLueQu RgjZJVwc3EnM2VVwE/88dtybRruZ0xYS2N2GlBMC0Y4D/p8bechIodMa/ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AqBQBRuChX/4wNJK1fgziBUAa3fYIdg?= =?us-ascii?q?XWGEAKBPToSAQEBAQEBAWUnhEIBAQR5EAIBCA44MiUCBAENBYgqvDkBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEVhiCETYoYAQSOEIUUhHIBjhePEo8xAScCOYI2gTVsh?= =?us-ascii?q?z1/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,572,1454976000"; d="scan'208";a="100366880" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 May 2016 14:45:13 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u43EjD5M001044 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 May 2016 14:45:14 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 3 May 2016 09:45:13 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Tue, 3 May 2016 09:45:13 -0500 From: "Alvaro Retana (aretana)" To: Mirja Kuehlewind , The IESG Thread-Topic: =?iso-8859-1?Q?Mirja_K=FChlewind's_No_Objection_on_draft-ietf-idr-add-pat?= =?iso-8859-1?Q?hs-14:_(with_COMMENT)?= Thread-Index: AQHRpFYKSZlB3k9yyUuAN91bh8HyHp+nXNqA Date: Tue, 3 May 2016 14:45:13 +0000 Message-ID: References: <20160502093559.23688.94285.idtracker@ietfa.amsl.com> In-Reply-To: <20160502093559.23688.94285.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.247.116] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-idr-add-paths@ietf.org" , Russ White , "idr@ietf.org" , "idr-chairs@ietf.org" Subject: Re: [Idr] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_draft-?= =?iso-8859-1?q?ietf-idr-add-paths-14=3A_=28with_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 14:45:16 -0000 On 5/2/16, 5:35 AM, "Mirja Kuehlewind" wrote: [Author hat on.] Mirja: Hi! >2) One clarification question: When a path with a new identifier is >advertised this actually does not mean that these two paths are >different, right? Some one could advertise the same path twice with >different identifiers, right? Should this be explicitly mention >somewhere? Right, the two (or more paths) don't have to be different. I don't think we need to specifically call the general case out as there is no issue related to path selection when that is done. OTOH, we do mention one instance of advertising "the same" path where there might be a need to differentiate -- take a look at the last paragraph in Section 6. Thanks! Alvaro. From nobody Tue May 3 07:55:36 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F22D312B03C; Tue, 3 May 2016 07:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ir9aAsImzgY5; Tue, 3 May 2016 07:55:29 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DEBF12D0E6; Tue, 3 May 2016 07:49:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1446; q=dns/txt; s=iport; t=1462286950; x=1463496550; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=cFq+6mT3QTRZF2Al6qcl8ORByqQUZMiQqhaKDYfM0WI=; b=I4QwTMLyYkysrso2QPK7C+YCmH4J0Z8Z/xZt+1QAuj12D54dhShTMIwB 1PBb+7MKqVjbWusu08FJA/kfPI5ViT3ggpnuktJSJ1DoGtyj1rf+HdvJi Y0KnvSrI7f+/v7yJRPBqn1ZFa8DWG8fJwStzzzWlPOgnsjv8MffYunDiR k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgBBuShX/5JdJa1fgziBUAauKolTg?= =?us-ascii?q?g8BDYF1hhACgT04FAEBAQEBAQFlJ4RCAQEEOj8QAgEIFSEQIRElAgQBDQWIFQM?= =?us-ascii?q?St18NhE4BAQEBAQEBAQEBAQEBAQEBAQEBAQEVhiCETYJDh1UBBId4iyyEQTEBj?= =?us-ascii?q?CCBd48Sh1GHYAEeAQFCgjaBNWwBhzx/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,572,1454976000"; d="scan'208";a="267236253" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 May 2016 14:49:09 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u43En99k031749 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 May 2016 14:49:09 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 3 May 2016 09:49:09 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Tue, 3 May 2016 09:49:09 -0500 From: "Alvaro Retana (aretana)" To: Kathleen Moriarty , The IESG Thread-Topic: Kathleen Moriarty's No Objection on draft-ietf-idr-add-paths-14: (with COMMENT) Thread-Index: AQHRpJwuI/T7aDUVK0GhhGsYh5s3D5+nXWYA Date: Tue, 3 May 2016 14:49:09 +0000 Message-ID: References: <20160502175801.15655.80242.idtracker@ietfa.amsl.com> In-Reply-To: <20160502175801.15655.80242.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.247.116] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-idr-add-paths@ietf.org" , Russ White , "idr-chairs@ietf.org" , "idr@ietf.org" Subject: Re: [Idr] Kathleen Moriarty's No Objection on draft-ietf-idr-add-paths-14: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 14:55:31 -0000 On 5/2/16, 1:58 PM, "iesg on behalf of Kathleen Moriarty" wrote: [Author hat on.] Kathleen: Hi! Yes, we'll take on both suggestions in the next revision. Thanks! Alvaro. >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >1. I'd like to see the security considerations explicitly state that this >could result in a denial of service attack. The resource consumption is >stated nicely, but it would be good (following RFC3552) to state the type >of attack. > > "This document defines a BGP extension that allows the advertisement > of multiple paths for the same address prefix without the new paths > implicitly replacing any previous ones. As a result, multiple paths > for a large number of prefixes may be received by a BGP speaker > potentially depleting memory resources or even causing network-wide > instability." > >Adding something like: "This could result in a denial of service >attack." > >2. Change the last sentence of the security considerations section in >light of the first paragraph to something like: > >From: > This document introduces no new security concerns in the base > operation of BGP [RFC4271]. > >To: > Security concerns in the base operation of BGP [RFC4271] also apply. From nobody Tue May 3 08:26:24 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E918D12D942; Tue, 3 May 2016 08:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-YQfvRet8J8; Tue, 3 May 2016 08:26:16 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6593C12D946; Tue, 3 May 2016 08:25:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2748; q=dns/txt; s=iport; t=1462289122; x=1463498722; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=YgLIOvWBQGCpoZ+3Ag6KRYrqgfSoziRqDCYtvL15nSM=; b=XTcNNa94PTsdApixEcjqfcdY09841TekTIcm8jKIcg+A/pAjxRajOz2O Ab6b4Ji5i1ysmZglc0piT1agZSbvH+nj+7UBozq0VWzwynjRiAbzxLHnN x44d89jRiCy9fMrdKq+qAG39UmGnmaG0Ebp+idQNAAHw7Df9NK9tkV6do U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgBewihX/5NdJa1VCoM4gVAGt32CD?= =?us-ascii?q?wENgXWGEAKBPTgUAQEBAQEBAWUnhEIBAQQ6PxACAQg2EDIlAgQBDQWIKrxUAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBFYYghE2EF4YBAQSHeIsshHIBjheBaIRNiF2GJ?= =?us-ascii?q?IkNAR4BAUKCBRsWgTVshz1/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,573,1454976000"; d="scan'208";a="267251795" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 May 2016 15:25:07 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u43FP7Ho025591 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 May 2016 15:25:07 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 3 May 2016 10:25:06 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Tue, 3 May 2016 10:25:07 -0500 From: "Alvaro Retana (aretana)" To: Stephen Farrell , The IESG Thread-Topic: Stephen Farrell's No Objection on draft-ietf-idr-add-paths-14: (with COMMENT) Thread-Index: AQHRpSed8Pap3QHMyEajC4L8EUASN5+nZlsA Date: Tue, 3 May 2016 15:25:07 +0000 Message-ID: References: <20160503103611.7402.3181.idtracker@ietfa.amsl.com> In-Reply-To: <20160503103611.7402.3181.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.247.116] Content-Type: text/plain; charset="us-ascii" Content-ID: <2BC424A33AB56C49982AF7602BD1BCB6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-idr-add-paths@ietf.org" , Russ White , "idr@ietf.org" , "idr-chairs@ietf.org" Subject: Re: [Idr] Stephen Farrell's No Objection on draft-ietf-idr-add-paths-14: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 15:26:18 -0000 On 5/3/16, 6:36 AM, "Stephen Farrell" wrote: [Author hat on.] Stephen: Hi! Please see my comments below. Thanks! Alvaro. >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > > >- section 2: This bit wasn't entirely clear to me: "A >BGP speaker that re-advertises a route MUST generate its >own Path Identifier to be associated with the >re-advertised route." It wasn't clear to me if that >means it's disallowed to use the same path identifier or >not when re-advertising. If it's not allowed that'd seem >to warrant a "MUST NOT" statement, or to say that the >path identifier re-advertised MUST be different from >that in the received advertisement - "it's own" doesn't >quite say the same to me. How the Path ID is selected is a local matter -- the important piece is that the local router can use it to uniquely identify a specific path. The intent here is to have every BGP speaker create the Path ID and not just take the easy path of simply readvertising because there may be collisions between the Path ID assigned by neighbors and the local ones -- that's the reason for the MUST. The local assignment may result in the same Path ID as the one which was received. That is fine -- as long as the local router did the assignment itself. >- section 5: I wasn't clear what happens in the >following case. Alice advertises prefix-A with no path >identifier, then prefix-A with some path identifier. >Next Alice withdraws prefix-A with no associated path >identifier. What happens when I get that sequence? (It >may well be clear for those readers who know more about >BGP.) That should never happen. Section 5 says that if the capability has been negotiated (Alice is able to send multiple paths and Bob is able to receive multiple paths), then Alice "MUST generate a route update for the based on the combination of the address prefix and the Path Identifier, and use the extended NLRI encodings...". If Alice does advertise prefix-A with no Path ID then Bob will detect an "invalid network field" and reset the session, which is what is specified in the base BGP spec [rfc4271] -- this document doesn't change the processing of UPDATES, just the interpretation of the NLRI. >- What is "bestpath"? If that's defined elsewhere a >reference would be good. (A quick duckduckgo only showed >me Cisco specific answers for bestpath, but others for >"best path.") Good point! I guess we're all just used to the colloquial term where everyone knows it is the best route [rfc4271]. I'll update in the next revision. From nobody Tue May 3 09:19:07 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7257012DA1D for ; Tue, 3 May 2016 09:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7z8LHIXw3tn for ; Tue, 3 May 2016 09:19:04 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42F3212DA1F for ; Tue, 3 May 2016 09:19:03 -0700 (PDT) Received: (qmail 30600 invoked from network); 3 May 2016 18:18:59 +0200 Received: from p5dec2476.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.36.118) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 3 May 2016 18:18:59 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Tue, 3 May 2016 18:19:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160502093559.23688.94285.idtracker@ietfa.amsl.com> To: "Alvaro Retana (aretana)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "draft-ietf-idr-add-paths@ietf.org" , Russ White , "idr@ietf.org" , The IESG , "idr-chairs@ietf.org" Subject: Re: [Idr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-idr-add-paths-14=3A_=28with_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 16:19:06 -0000 Hi Alvaro, okay, that=E2=80=99s fine. I was think about a case, where two paths are = advertised and than maybe someones uses those two paths to do some = complex multipath routing, while at the end this would be unnecessary as = both advertised path are physically the same. Not sure if that would = ever be the case or I=E2=80=99m making things up. If you tell me that = there is no further discussion needed, that=E2=80=99s fine for me as the = doc doesn=E2=80=99t really talk at all about any assumptions that should = be made about the (physical) path that is used. Mirja > Am 03.05.2016 um 16:45 schrieb Alvaro Retana (aretana) = : >=20 > On 5/2/16, 5:35 AM, "Mirja Kuehlewind" wrote: >=20 > [Author hat on.] >=20 > Mirja: >=20 > Hi! >=20 >> 2) One clarification question: When a path with a new identifier is >> advertised this actually does not mean that these two paths are >> different, right? Some one could advertise the same path twice with >> different identifiers, right? Should this be explicitly mention >> somewhere? >=20 > Right, the two (or more paths) don't have to be different. I don't = think > we need to specifically call the general case out as there is no issue > related to path selection when that is done. >=20 > OTOH, we do mention one instance of advertising "the same" path where > there might be a need to differentiate -- take a look at the last > paragraph in Section 6. >=20 > Thanks! >=20 > Alvaro. >=20 From nobody Tue May 3 13:11:55 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF86D12D62E; Tue, 3 May 2016 13:11:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160503201154.8288.39871.idtracker@ietfa.amsl.com> Date: Tue, 03 May 2016 13:11:54 -0700 Archived-At: Cc: draft-ietf-idr-add-paths@ietf.org, russ@riw.us, idr@ietf.org, idr-chairs@ietf.org Subject: [Idr] Alissa Cooper's No Objection on draft-ietf-idr-add-paths-14: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 20:11:55 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-idr-add-paths-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-idr-add-paths/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Was also wondering about "bestpath." From nobody Wed May 4 00:51:16 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E70B12B006; Wed, 4 May 2016 00:51:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160504075109.8272.98072.idtracker@ietfa.amsl.com> Date: Wed, 04 May 2016 00:51:09 -0700 Archived-At: Cc: draft-ietf-idr-route-oscillation-stop@ietf.org, idr@ietf.org, shares@ndzh.com, idr-chairs@ietf.org Subject: [Idr] Stephen Farrell's No Objection on draft-ietf-idr-route-oscillation-stop-03: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 07:51:09 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-idr-route-oscillation-stop-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-idr-route-oscillation-stop/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - abstract: use of so many acronyms here is a pity, be good to expand or not use some of 'em - intro: "MED attribute" is not mentioned in RFC4271, at least not obviously enough to find with a grep;-) I had to search for "multi" to figure out that you meant the MULTI_EXIT_DISC thing, so maybe point at 5.1.4 in 4271 to be nice? - intro: It'd also be nice to provide a reference for the "almost all of the known" claim for readers who aren't familiar with such examples. (And I do mean "nice" and not "necessary":-) From nobody Wed May 4 05:57:47 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D1812D66E; Wed, 4 May 2016 05:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.53 X-Spam-Level: X-Spam-Status: No, score=-4.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQ0ziP4YV53N; Wed, 4 May 2016 05:57:41 -0700 (PDT) Received: from r-mail1.rd.orange.com (r-mail1.rd.orange.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 45E7612D112; Wed, 4 May 2016 05:57:41 -0700 (PDT) Received: from r-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D59ECA44189; Wed, 4 May 2016 14:57:39 +0200 (CEST) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by r-mail1.rd.orange.com (Postfix) with ESMTP id CC7FDA44188; Wed, 4 May 2016 14:57:39 +0200 (CEST) Received: from [10.193.71.12] (10.193.71.12) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.266.1; Wed, 4 May 2016 14:57:39 +0200 To: BESS , IDR , From: Thomas Morin Organization: Orange Message-ID: <5729F1C3.1030605@orange.com> Date: Wed, 4 May 2016 14:57:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 12:57:43 -0000 Hi, There are minor things that could be improved in draft-ietf-bess-evpn-overlay wrt. consistency with draft-ietf-idr-tunnel-encaps : * since draft-ietf-idr-tunnel-encaps will deprecate RFC5512, it would be better that draft-ietf-bess-evpn-overlay refers to draft-ietf-idr-tunnel-encaps and not anymore to RFC5512. * I think it would be better to avoid the explicit list of encap types in section 5.1.3, and rather refer to draft-ietf-idr-tunnel-encaps instead * the following minor modification was proposed, but not yet incorporated: John Drake, 2015-11-13 (to BESS ML): > For the overlay draft, replace this text in section 5.1.3: > > "If the BGP Encapsulation extended community is not present, then the default MPLS encapsulation or a statically configured encapsulation is assumed." > > With the following: > > "Note that the MPLS encapsulation tunnel type is needed in order to distinguish between an advertising node that only supports non-MPLS encapsulations and one that supports MPLS and non-MPLS encapsulations. An advertising node that only supports MPLS encapsulation does not need to advertise any encapsulation tunnel types; i.e., if the BGP Encapsulation extended community is not present, then either MPLS encapsulation or a statically configured encapsulation is assumed." I think this change is useful and should be incorporated, although skipping the last sentence would be wise if the full list of tunnel types is removed. Thanks in advance, -Thomas From nobody Wed May 4 06:23:24 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 189FB12D112; Wed, 4 May 2016 06:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.23 X-Spam-Level: X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.996, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAhTo-wL5cEP; Wed, 4 May 2016 06:23:18 -0700 (PDT) Received: from p-mail2.rd.orange.com (p-mail2.rd.orange.com [161.106.1.3]) by ietfa.amsl.com (Postfix) with ESMTP id 2DBD412B03D; Wed, 4 May 2016 06:23:18 -0700 (PDT) Received: from p-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 60499E30088; Wed, 4 May 2016 15:23:17 +0200 (CEST) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail2.rd.orange.com (Postfix) with ESMTP id 4F812E30085; Wed, 4 May 2016 15:23:17 +0200 (CEST) Received: from [10.193.71.12] (10.193.71.12) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.266.1; Wed, 4 May 2016 15:23:17 +0200 To: BESS , IDR , References: <5729F1C3.1030605@orange.com> From: Thomas Morin Organization: Orange Message-ID: <5729F7C5.6040604@orange.com> Date: Wed, 4 May 2016 15:23:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <5729F1C3.1030605@orange.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 13:23:20 -0000 Hi, There is another point that I missed in this first email. draft-ietf-bess-evpn-overlay (see section 9) relies on the BGP Encapsulation extended to encode the tunnel encap to use for BUM traffic, but contrary to other E-VPN routes, relies on the Ethernet Tag field of the NLRI to encode the VNI/VSID. This is really different than the approach used for other routes (not relying on the generic mechanism in draft-ietf-idr-tunnel-encaps), I think it would be worth highlighting, by adding something like: How the VNI or VSID is encoded in these route is done different from the approach used for other routes, because draft-ietf-idr- tunnel-encaps does not provide procedures describing how to derive a VNI or VSID from a Label in a PMSI Tunnel Attribute. [ An alternative would be to have draft-ietf-idr-tunnel-encaps provide procedures describing how to derive a VNI or VSID from a Label in a PMSI Tunnel Attribute and have draft-ietf-bess-evpn-overlay follow that. I understand that the existence of implementation makes this hard to change. ] -Thomas 2016-05-04, Thomas Morin: > Hi, > > There are minor things that could be improved in > draft-ietf-bess-evpn-overlay wrt. consistency with > draft-ietf-idr-tunnel-encaps : > > * since draft-ietf-idr-tunnel-encaps will deprecate RFC5512, it would be > better that draft-ietf-bess-evpn-overlay refers to > draft-ietf-idr-tunnel-encaps and not anymore to RFC5512. > > * I think it would be better to avoid the explicit list of encap types > in section 5.1.3, and rather refer to draft-ietf-idr-tunnel-encaps instead > * the following minor modification was proposed, but not yet incorporated: > > John Drake, 2015-11-13 (to BESS ML): >> For the overlay draft, replace this text in section 5.1.3: >> >> "If the BGP Encapsulation extended community is not present, then >> the default MPLS encapsulation or a statically configured >> encapsulation is assumed." >> >> With the following: >> >> "Note that the MPLS encapsulation tunnel type is needed in order >> to distinguish between an advertising node that only supports non-MPLS >> encapsulations and one that supports MPLS and non-MPLS >> encapsulations. An advertising node that only supports MPLS >> encapsulation does not need to advertise any encapsulation tunnel >> types; i.e., if the BGP Encapsulation extended community is not >> present, then either MPLS encapsulation or a statically configured >> encapsulation is assumed." > > I think this change is useful and should be incorporated, although > skipping the last sentence would be wise if the full list of tunnel > types is removed. > > Thanks in advance, > > -Thomas > From nobody Wed May 4 06:30:27 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B716C12D112 for ; Wed, 4 May 2016 06:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.229 X-Spam-Level: X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.996, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RX79ypCv02ei for ; Wed, 4 May 2016 06:30:23 -0700 (PDT) Received: from p-mail2.rd.orange.com (p-mail2.rd.orange.com [161.106.1.3]) by ietfa.amsl.com (Postfix) with ESMTP id 1B21512D094 for ; Wed, 4 May 2016 06:30:23 -0700 (PDT) Received: from p-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7E891E30085; Wed, 4 May 2016 15:30:22 +0200 (CEST) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail2.rd.orange.com (Postfix) with ESMTP id 1FB04E30079; Wed, 4 May 2016 15:30:22 +0200 (CEST) Received: from [10.193.71.12] (10.193.71.12) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.266.1; Wed, 4 May 2016 15:30:21 +0200 To: , Eric Rosen References: <20151221171512.15817.2209.idtracker@ietfa.amsl.com> From: Thomas Morin Organization: Orange Message-ID: <5729F96D.4050003@orange.com> Date: Wed, 4 May 2016 15:30:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20151221171512.15817.2209.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------080404030600020408010902" Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-tunnel-encaps-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 13:30:25 -0000 --------------080404030600020408010902 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Hi everyone, The draft has the following piece of text: Note that if none of the TLVs specifies the MPLS tunnel type, a Label Switched Path SHOULD NOT be used unless none of the TLVs specifies a feasible tunnel. I think the following addition would do a nice job of explaining the designers motivation for adding the MPLS tunnel type: Hence, the MPLS encapsulation tunnel type allows to distinguish between an advertising node that only supports non-MPLS encapsulations and one that supports MPLS and non-MPLS encapsulations. (minor reword from text posted by John Drake on 2015-11-13 for draft-ietf-bess-evpn-overlay but that would now belong to draft-ietf-idr-tunnel-encaps) Best, -Thomas > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Inter-Domain Routing Working Group of the IETF. > > Title : The BGP Tunnel Encapsulation Attribute > Authors : Eric C. Rosen > Keyur Patel > Gunter Van de Velde > Filename : draft-ietf-idr-tunnel-encaps-01.txt > Pages : 39 > Date : 2015-12-21 > > Abstract: > RFC 5512 defines a BGP Path Attribute known as the "Tunnel > Encapsulation Attribute". This attribute allows one to specify a set > of tunnels. For each such tunnel, the attribute can provide the > information needed to create the tunnel and the corresponding > encapsulation header. The attribute can also provide information > that aids in choosing whether a particular packet is to be sent > through a particular tunnel. RFC 5512 states that the attribute is > only carried in BGP UPDATEs that have the "Encapsulation Subsequent > Address Family (Encapsulation SAFI)". This document deprecates the > Encapsulation SAFI (which has never been used), and specifies > semantics for the attribute when it is carried in UPDATEs of certain > other SAFIs. This document adds support for additional tunnel types, > and allows a remote tunnel endpoint address to be specified for each > tunnel. This document also provides support for specifying fields of > any inner or outer encapsulations that may be used by a particular > tunnel. > > This document obsoletes RFC 5512. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-tunnel-encaps/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-tunnel-encaps-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --------------080404030600020408010902 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit
Hi everyone,

The draft has the following piece of text:
   Note that if none of the TLVs specifies the MPLS tunnel type, a Label
   Switched Path SHOULD NOT be used unless none of the TLVs specifies a
   feasible tunnel.
I think the following addition would do a nice job of explaining the designers motivation for adding the MPLS tunnel type:
Hence, the MPLS encapsulation tunnel type allows to distinguish between an advertising node that only supports non-MPLS encapsulations and one that supports MPLS and non-MPLS  encapsulations.
(minor reword from text posted by John Drake on 2015-11-13 for draft-ietf-bess-evpn-overlay but that would now belong to draft-ietf-idr-tunnel-encaps)

Best,

-Thomas






A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

        Title           : The BGP Tunnel Encapsulation Attribute
        Authors         : Eric C. Rosen
                          Keyur Patel
                          Gunter Van de Velde
	Filename        : draft-ietf-idr-tunnel-encaps-01.txt
	Pages           : 39
	Date            : 2015-12-21

Abstract:
   RFC 5512 defines a BGP Path Attribute known as the "Tunnel
   Encapsulation Attribute".  This attribute allows one to specify a set
   of tunnels.  For each such tunnel, the attribute can provide the
   information needed to create the tunnel and the corresponding
   encapsulation header.  The attribute can also provide information
   that aids in choosing whether a particular packet is to be sent
   through a particular tunnel.  RFC 5512 states that the attribute is
   only carried in BGP UPDATEs that have the "Encapsulation Subsequent
   Address Family (Encapsulation SAFI)".  This document deprecates the
   Encapsulation SAFI (which has never been used), and specifies
   semantics for the attribute when it is carried in UPDATEs of certain
   other SAFIs.  This document adds support for additional tunnel types,
   and allows a remote tunnel endpoint address to be specified for each
   tunnel.  This document also provides support for specifying fields of
   any inner or outer encapsulations that may be used by a particular
   tunnel.

   This document obsoletes RFC 5512.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-tunnel-encaps/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-tunnel-encaps-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

--------------080404030600020408010902-- From nobody Wed May 4 10:04:22 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42B9312D966; Wed, 4 May 2016 10:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ybK938Wk3V_W; Wed, 4 May 2016 10:04:14 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF24412D73B; Wed, 4 May 2016 10:00:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=913; q=dns/txt; s=iport; t=1462381240; x=1463590840; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=fZZB7ytBSxsMZ6UkyDAFk/m6IU5KgVc1HzbDAP+6G2M=; b=EIcgQEY6PduZj9V0QoBiZKBi/XmDqwD/lUog//vPskZOgDuns+NwBpTH WjhmU3wWkV21jLGsM1G70d+F+6m1KVtOQlcs3n4Th2tM8861XOVnS8Mcq bc5RJLBAyxHofLgELb6lgUbe4JLGccelCSzav8hiKVwxYc0BppvSkI8we 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AdAgASKipX/5hdJa1egziBUAa3VIIPA?= =?us-ascii?q?Q2BdoYQAoE3OBQBAQEBAQEBZSeEQgEBBDo/EAIBCDYQMiUCBAENBYgqvUgBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEVhiCETYoYAQSHeIsshHUBjhePE48zAR4BAUKCN?= =?us-ascii?q?oE1bIc9fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,578,1454976000"; d="scan'208";a="100825301" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 May 2016 17:00:39 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u44H0dqk028804 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 May 2016 17:00:39 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 4 May 2016 12:00:38 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Wed, 4 May 2016 12:00:39 -0500 From: "Alvaro Retana (aretana)" To: Stephen Farrell , The IESG Thread-Topic: Stephen Farrell's No Objection on draft-ietf-idr-route-oscillation-stop-03: (with COMMENT) Thread-Index: AQHRpdm7k+SgxrSVuEylRduasrg5RJ+pEfgA Date: Wed, 4 May 2016 17:00:39 +0000 Message-ID: References: <20160504075109.8272.98072.idtracker@ietfa.amsl.com> In-Reply-To: <20160504075109.8272.98072.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.247.86] Content-Type: text/plain; charset="us-ascii" Content-ID: <0FFBD07E40BFAE47ABEB0A1AC6FE1887@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-idr-route-oscillation-stop@ietf.org" , "idr@ietf.org" , "shares@ndzh.com" , "idr-chairs@ietf.org" Subject: Re: [Idr] Stephen Farrell's No Objection on draft-ietf-idr-route-oscillation-stop-03: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 17:04:15 -0000 On 5/4/16, 3:51 AM, "Stephen Farrell" wrote: [Author hat on.] Stephen: Hi! Thanks for the review. I'll address the comments in the next revision. Alvaro. >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > > >- abstract: use of so many acronyms here is a pity, be good >to expand or not use some of 'em > >- intro: "MED attribute" is not mentioned in RFC4271, at >least not obviously enough to find with a grep;-) I had to >search for "multi" to figure out that you meant the >MULTI_EXIT_DISC thing, so maybe point at 5.1.4 in 4271 to >be nice? > >- intro: It'd also be nice to provide a reference for the >"almost all of the known" claim for readers who aren't >familiar with such examples. (And I do mean "nice" and not >"necessary":-) > > From nobody Wed May 4 11:06:42 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2285D12D147; Wed, 4 May 2016 11:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZSeLpkq0TxX; Wed, 4 May 2016 11:06:35 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92E4212D5BB; Wed, 4 May 2016 11:06:34 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 9A449D44464DD; Wed, 4 May 2016 18:06:28 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u44I6VQj014040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 May 2016 18:06:31 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u44I6Pdw027960 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 May 2016 20:06:31 +0200 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.187]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Wed, 4 May 2016 20:06:12 +0200 From: "Rabadan, Jorge (Nokia - US)" To: EXT Thomas Morin , BESS , IDR , "draft-ietf-bess-evpn-overlay@tools.ietf.org" Thread-Topic: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps Thread-Index: AQHRpi+kmvQEkxjTwkqTS+eCL8sT/g== Date: Wed, 4 May 2016 18:06:12 +0000 Message-ID: <52D35106-ED5E-4C95-9131-6EA4527370D5@alcatel-lucent.com> References: <5729F1C3.1030605@orange.com> <5729F7C5.6040604@orange.com> In-Reply-To: <5729F7C5.6040604@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 18:06:38 -0000 VGhvbWFzLA0KDQpQbGVhc2Ugc2VlIGluLWxpbmUuDQpUaGFuayB5b3UuDQpKb3JnZQ0KDQoNCg0K DQpPbiA1LzQvMTYsIDM6MjMgUE0sICJJZHIgb24gYmVoYWxmIG9mIEVYVCBUaG9tYXMgTW9yaW4i IDxpZHItYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgdGhvbWFzLm1vcmluQG9yYW5nZS5j b20+IHdyb3RlOg0KDQo+SGksDQo+DQo+VGhlcmUgaXMgYW5vdGhlciBwb2ludCB0aGF0IEkgbWlz c2VkIGluIHRoaXMgZmlyc3QgZW1haWwuDQo+DQo+ZHJhZnQtaWV0Zi1iZXNzLWV2cG4tb3Zlcmxh eSAoc2VlIHNlY3Rpb24gOSkgcmVsaWVzIG9uIHRoZSBCR1AgDQo+RW5jYXBzdWxhdGlvbiBleHRl bmRlZCB0byBlbmNvZGUgdGhlIHR1bm5lbCBlbmNhcCB0byB1c2UgZm9yIEJVTSANCj50cmFmZmlj LCBidXQgY29udHJhcnkgdG8gb3RoZXIgRS1WUE4gcm91dGVzLCByZWxpZXMgb24gdGhlIEV0aGVy bmV0IFRhZyANCj5maWVsZCBvZiB0aGUgTkxSSSB0byBlbmNvZGUgdGhlIFZOSS9WU0lELg0KDQpb Sk9SR0VdIFRoaXMgaXMgY2VydGFpbmx5IGEgbGVmdG92ZXIgZnJvbSBhbiBvbGQgdmVyc2lvbiB3 aGVyZSB0aGUgVk5JL1ZTSUQgd2FzIGVuY29kZWQgaW4gdGhlIGV0aGVybmV0IHRhZyBmb3IgYWxs IHRoZSByb3V0ZXMuIFRoZSBWTkkgc2hvdWxkIGJlIGVuY29kZWQgaW4gdGhlIExhYmVsIGZpZWxk IGluIGFsbCB0aGUgcm91dGVzLiBUaGlzIGhhcyB0byBiZSBjb3JyZWN0ZWQuDQoNCkluIGZhY3Qs IHNlY3Rpb24gNS4xLjMgc2F5czoNCg0KNS4xLjMgQ29uc3RydWN0aW5nIEVWUE4gQkdQIFJvdXRl cw0KDQo8c25pcD4NCg0KQWNjb3JkaW5nbHksIGFuZA0KICAgc3BlY2lmaWNhbGx5IHRvIHN1cHBv cnQgdGhlIG9wdGlvbiBvZiBsb2NhbGx5IGFzc2lnbmVkIFZOSXMsIHRoZSBNUExTDQogICBsYWJl bCBmaWVsZCBpbiB0aGUgTUFDIEFkdmVydGlzZW1lbnQsIEV0aGVybmV0IEFEIHBlciBFVkksIGFu ZA0KICAgSW5jbHVzaXZlIE11bHRpY2FzdCBFdGhlcm5ldCBUYWcgcm91dGVzIGlzIHVzZWQgdG8g Y2FycnkgdGhlIFZOSSBvcg0KICAgVlNJRC4gIEZvciB0aGUgYmFsYW5jZSBvZiB0aGlzIG1lbW8s IHRoZSBNUExTIGxhYmVsIGZpZWxkIHdpbGwgYmUNCiAgIHJlZmVycmVkIHRvIGFzIHRoZSBWTkkv VlNJRCBmaWVsZC4gVGhlIFZOSS9WU0lEIGZpZWxkIGlzIHVzZWQgZm9yDQogICBib3RoIGxvY2Fs IGFuZCBnbG9iYWwgVk5Jcy9WU0lEcywgYW5kIGZvciBlaXRoZXIgY2FzZSB0aGUgZW50aXJlIDI0 LQ0KICAgYml0IGZpZWxkIGlzIHVzZWQgdG8gZW5jb2RlIHRoZSBWTkkvVlNJRCB2YWx1ZS4NCg0K PHNuaXA+DQoNCg0KDQoNCg0KPg0KPlRoaXMgaXMgcmVhbGx5IGRpZmZlcmVudCB0aGFuIHRoZSBh cHByb2FjaCB1c2VkIGZvciBvdGhlciByb3V0ZXMgKG5vdCANCj5yZWx5aW5nIG9uIHRoZSBnZW5l cmljIG1lY2hhbmlzbSBpbiBkcmFmdC1pZXRmLWlkci10dW5uZWwtZW5jYXBzKSwgSSANCj50aGlu ayBpdCB3b3VsZCBiZSB3b3J0aCBoaWdobGlnaHRpbmcsIGJ5IGFkZGluZyBzb21ldGhpbmcgbGlr ZToNCj4NCj4gICAgSG93IHRoZSBWTkkgb3IgVlNJRCBpcyBlbmNvZGVkIGluIHRoZXNlIHJvdXRl IGlzIGRvbmUgZGlmZmVyZW50DQo+ICAgIGZyb20gdGhlIGFwcHJvYWNoIHVzZWQgZm9yIG90aGVy IHJvdXRlcywgYmVjYXVzZSBkcmFmdC1pZXRmLWlkci0NCj4gICAgdHVubmVsLWVuY2FwcyBkb2Vz IG5vdCBwcm92aWRlIHByb2NlZHVyZXMgZGVzY3JpYmluZyBob3cgdG8gZGVyaXZlIGENCj4gICAg Vk5JIG9yIFZTSUQgZnJvbSBhIExhYmVsIGluIGEgUE1TSSBUdW5uZWwgQXR0cmlidXRlLg0KPg0K PlsgQW4gYWx0ZXJuYXRpdmUgd291bGQgYmUgdG8gaGF2ZSBkcmFmdC1pZXRmLWlkci10dW5uZWwt ZW5jYXBzIHByb3ZpZGUgDQo+cHJvY2VkdXJlcyBkZXNjcmliaW5nIGhvdyB0byBkZXJpdmUgYSBW Tkkgb3IgVlNJRCBmcm9tIGEgTGFiZWwgaW4gYSBQTVNJIA0KPlR1bm5lbCBBdHRyaWJ1dGUgYW5k IGhhdmUgZHJhZnQtaWV0Zi1iZXNzLWV2cG4tb3ZlcmxheSBmb2xsb3cgdGhhdC4gSSANCj51bmRl cnN0YW5kIHRoYXQgdGhlIGV4aXN0ZW5jZSBvZiBpbXBsZW1lbnRhdGlvbiBtYWtlcyB0aGlzIGhh cmQgdG8gY2hhbmdlLiBdDQo+DQo+LVRob21hcw0KPg0KPg0KPg0KPg0KPg0KPjIwMTYtMDUtMDQs IFRob21hcyBNb3JpbjoNCj4+IEhpLA0KPj4NCj4+IFRoZXJlIGFyZSBtaW5vciB0aGluZ3MgdGhh dCBjb3VsZCBiZSBpbXByb3ZlZCBpbg0KPj4gZHJhZnQtaWV0Zi1iZXNzLWV2cG4tb3ZlcmxheSB3 cnQuIGNvbnNpc3RlbmN5IHdpdGgNCj4+IGRyYWZ0LWlldGYtaWRyLXR1bm5lbC1lbmNhcHMgOg0K Pj4NCj4+ICogc2luY2UgZHJhZnQtaWV0Zi1pZHItdHVubmVsLWVuY2FwcyB3aWxsIGRlcHJlY2F0 ZSBSRkM1NTEyLCBpdCB3b3VsZCBiZQ0KPj4gYmV0dGVyIHRoYXQgZHJhZnQtaWV0Zi1iZXNzLWV2 cG4tb3ZlcmxheSByZWZlcnMgdG8NCj4+IGRyYWZ0LWlldGYtaWRyLXR1bm5lbC1lbmNhcHMgYW5k IG5vdCBhbnltb3JlIHRvIFJGQzU1MTIuDQoNCltKT1JHRV0gSSBhZ3JlZSwgYXMgbG9uZyBhcyBk cmFmdC1pZXRmLWlkci10dW5uZWwtZW5jYXBzIGtlZXBzIHRoZSBlbmNhcHN1bGF0aW9uIGV4dGVu ZGVkIGNvbW11bml0eS4gVGhlcmUgYXJlIGEgZmV3IGltcGxlbWVudGF0aW9ucyB1c2luZyB0aGlz IGNvbW11bml0eSBhbmQgaXQgaXMgZW5vdWdoIHdoZW4gb25seSB0aGUgZW5jYXBzdWxhdGlvbiB0 eXBlIGlzIG5lZWRlZC4NCg0KPj4NCj4+ICogSSB0aGluayBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8g YXZvaWQgdGhlIGV4cGxpY2l0IGxpc3Qgb2YgZW5jYXAgdHlwZXMNCj4+IGluIHNlY3Rpb24gNS4x LjMsIGFuZCByYXRoZXIgcmVmZXIgdG8gZHJhZnQtaWV0Zi1pZHItdHVubmVsLWVuY2FwcyBpbnN0 ZWFkDQoNCltKT1JHRV0gSSBhZ3JlZS4NCg0KPj4gKiB0aGUgZm9sbG93aW5nIG1pbm9yIG1vZGlm aWNhdGlvbiB3YXMgcHJvcG9zZWQsIGJ1dCBub3QgeWV0IGluY29ycG9yYXRlZDoNCj4+DQo+PiAg ICAgSm9obiBEcmFrZSwgMjAxNS0xMS0xMyAodG8gQkVTUyBNTCk6DQo+Pj4gICAgIEZvciB0aGUg b3ZlcmxheSBkcmFmdCwgcmVwbGFjZSB0aGlzIHRleHQgaW4gc2VjdGlvbiA1LjEuMzoNCj4+Pg0K Pj4+ICAgICAiSWYgdGhlIEJHUCBFbmNhcHN1bGF0aW9uIGV4dGVuZGVkIGNvbW11bml0eSBpcyBu b3QgcHJlc2VudCwgdGhlbg0KPj4+IHRoZSBkZWZhdWx0IE1QTFMgZW5jYXBzdWxhdGlvbiBvciBh IHN0YXRpY2FsbHkgY29uZmlndXJlZA0KPj4+IGVuY2Fwc3VsYXRpb24gaXMgYXNzdW1lZC4iDQo+ Pj4NCj4+PiAgICAgV2l0aCB0aGUgZm9sbG93aW5nOg0KPj4+DQo+Pj4gICAgICJOb3RlIHRoYXQg dGhlIE1QTFMgZW5jYXBzdWxhdGlvbiB0dW5uZWwgdHlwZSBpcyBuZWVkZWQgaW4gb3JkZXINCj4+ PiB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuIGFuIGFkdmVydGlzaW5nIG5vZGUgdGhhdCBvbmx5IHN1 cHBvcnRzIG5vbi1NUExTDQo+Pj4gZW5jYXBzdWxhdGlvbnMgYW5kIG9uZSB0aGF0IHN1cHBvcnRz IE1QTFMgYW5kIG5vbi1NUExTDQo+Pj4gZW5jYXBzdWxhdGlvbnMuICBBbiAgYWR2ZXJ0aXNpbmcg bm9kZSB0aGF0IG9ubHkgc3VwcG9ydHMgTVBMUw0KPj4+IGVuY2Fwc3VsYXRpb24gZG9lcyBub3Qg bmVlZCB0byBhZHZlcnRpc2UgYW55IGVuY2Fwc3VsYXRpb24gdHVubmVsDQo+Pj4gdHlwZXM7ICBp LmUuLCAgaWYgdGhlIEJHUCBFbmNhcHN1bGF0aW9uIGV4dGVuZGVkIGNvbW11bml0eSBpcyBub3QN Cj4+PiBwcmVzZW50LCB0aGVuIGVpdGhlciBNUExTIGVuY2Fwc3VsYXRpb24gb3IgYSBzdGF0aWNh bGx5IGNvbmZpZ3VyZWQNCj4+PiBlbmNhcHN1bGF0aW9uIGlzIGFzc3VtZWQuIg0KPj4NCj4+IEkg dGhpbmsgdGhpcyBjaGFuZ2UgaXMgdXNlZnVsIGFuZCBzaG91bGQgYmUgaW5jb3Jwb3JhdGVkLCBh bHRob3VnaA0KPj4gc2tpcHBpbmcgdGhlIGxhc3Qgc2VudGVuY2Ugd291bGQgYmUgd2lzZSBpZiB0 aGUgZnVsbCBsaXN0IG9mIHR1bm5lbA0KPj4gdHlwZXMgaXMgcmVtb3ZlZC4NCj4+DQo+PiBUaGFu a3MgaW4gYWR2YW5jZSwNCj4+DQo+PiAtVGhvbWFzDQo+Pg0KPg0KPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+SWRyIG1haWxpbmcgbGlzdA0KPklkckBp ZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQo= From nobody Wed May 4 11:34:33 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9C0B12D5AC; Wed, 4 May 2016 11:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8lkTmLGhjwC; Wed, 4 May 2016 11:34:29 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0777.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::777]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE4A312D595; Wed, 4 May 2016 11:34:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=DVtI+siANB6dZN3WZ2N2oUGFrM/iKZfrjN7jRzf339w=; b=G6LZCEPzixktMo3/o4bU/gqZtbUZH9MzJVkunWz5FkHl4wo8ZDyZ5jnEmUHmCecVp5Fz1rzYjO2NDMsEGnyUAKiBX+nQvUYqTyCwe3R175RK6S8fg4ye9yq/mzgOrQPsfTXdKLW+yaQAdmmZfX3LiRNjyLr/geVs4ThaIZpyzzc= Received: from BY2PR0501MB1702.namprd05.prod.outlook.com (10.163.154.155) by BY2PR0501MB1701.namprd05.prod.outlook.com (10.163.154.154) with Microsoft SMTP Server (TLS) id 15.1.485.9; Wed, 4 May 2016 18:34:11 +0000 Received: from BY2PR0501MB1702.namprd05.prod.outlook.com ([10.163.154.155]) by BY2PR0501MB1702.namprd05.prod.outlook.com ([10.163.154.155]) with mapi id 15.01.0477.016; Wed, 4 May 2016 18:34:11 +0000 From: John E Drake To: "Rabadan, Jorge (Nokia - US)" , "EXT - thomas.morin@orange.com" , BESS , IDR , "draft-ietf-bess-evpn-overlay@tools.ietf.org" , "Ali Sajassi (sajassi)" Thread-Topic: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps Thread-Index: AQHRpi+6xGM0bynWeUeGN93K6stLXZ+pFtLw Date: Wed, 4 May 2016 18:34:11 +0000 Message-ID: References: <5729F1C3.1030605@orange.com> <5729F7C5.6040604@orange.com> <52D35106-ED5E-4C95-9131-6EA4527370D5@alcatel-lucent.com> In-Reply-To: <52D35106-ED5E-4C95-9131-6EA4527370D5@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nokia.com; dkim=none (message not signed) header.d=none;nokia.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.12] x-ms-office365-filtering-correlation-id: 948c33e5-6601-46fd-790e-08d3744aaf8a x-microsoft-exchange-diagnostics: 1; BY2PR0501MB1701; 5:mtramgV9kgWyOeS6pxoU/4FkDygUvAKKjs27KyqkGAXMQab1ou0bEUxy+gko3Dut5/ozc5DVbQUH8u7aPkTEMgDbL+PdxCnhLp9C5uZwDxT2ECH5G2GfFWqBAZRwXjv2ik7sKfljmTgt9aEAN/ujCQ==; 24:Kf55TftaCFV4IkVxX5vkVtnxs/uwO9RIpRDFptqBnSZIlf0JMlkxXktCzs2TvlU/1dt1h+kRQsqV+ybP0T9MO/UC2s1VHx29E53fqDydL+U=; 7:zbsKZyEKVBLhIyqPahRy+Kg8/SDhJnK4vMarlhKZJneFVqrxt1YOZhEfZDhlQTFINX4xdMu0LuYpcrZuiiEZ/o+h5+fQVqRkFphws+ClzL/9I7cqOoHsXnI2wBRvLt4LpBqtAu2Tl5E7yGZhnJAf83U38IFmYSmkRedzBA/0m1iKfv33DNSPfb17aNHbNX6a x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0501MB1701; x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521098)(9101528026)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:BY2PR0501MB1701; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0501MB1701; x-forefront-prvs: 093290AD39 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377424004)(230783001)(99286002)(87936001)(3846002)(102836003)(6116002)(1220700001)(5008740100001)(76576001)(586003)(106116001)(81166005)(66066001)(54356999)(74316001)(76176999)(86362001)(9686002)(33656002)(2906002)(50986999)(5002640100001)(5001770100001)(189998001)(107886002)(5003600100002)(3660700001)(2501003)(4001150100001)(3280700002)(92566002)(77096005)(5004730100002)(2950100001)(2900100001)(10400500002)(8936002)(122556002)(11100500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0501MB1701; H:BY2PR0501MB1702.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2016 18:34:11.0392 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0501MB1701 Archived-At: Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 18:34:32 -0000 Thomas and Jorge, Snipped, comments inline. Yours Irrespectively, John > > > >draft-ietf-bess-evpn-overlay (see section 9) relies on the BGP > >Encapsulation extended to encode the tunnel encap to use for BUM > >traffic, but contrary to other E-VPN routes, relies on the Ethernet Tag > >field of the NLRI to encode the VNI/VSID. >=20 > [JORGE] This is certainly a leftover from an old version where the VNI/VS= ID was encoded in > the ethernet tag for all the routes. The VNI should be encoded in the Lab= el field in all the > routes. This has to be corrected. >=20 > In fact, section 5.1.3 says: >=20 > 5.1.3 Constructing EVPN BGP Routes >=20 > >=20 > Accordingly, and > specifically to support the option of locally assigned VNIs, the MPLS > label field in the MAC Advertisement, Ethernet AD per EVI, and > Inclusive Multicast Ethernet Tag routes is used to carry the VNI or > VSID. For the balance of this memo, the MPLS label field will be > referred to as the VNI/VSID field. The VNI/VSID field is used for > both local and global VNIs/VSIDs, and for either case the entire 24- > bit field is used to encode the VNI/VSID value. >=20 > [JD] For the IMET route the MPLS label field is carried in the PMSI attrib= ute. I think we need to ask everyone whether they used the Ethernet Tag or the PMSI attribute to carry the VNI =20 > >> > >> There are minor things that could be improved in > >> draft-ietf-bess-evpn-overlay wrt. consistency with > >> draft-ietf-idr-tunnel-encaps : > >> > >> * since draft-ietf-idr-tunnel-encaps will deprecate RFC5512, it would > >> be better that draft-ietf-bess-evpn-overlay refers to > >> draft-ietf-idr-tunnel-encaps and not anymore to RFC5512. >=20 > [JORGE] I agree, as long as draft-ietf-idr-tunnel-encaps keeps the encaps= ulation extended > community. There are a few implementations using this community and it is= enough when > only the encapsulation type is needed. [JD] I agree and the tunnel encaps draft does keep the EC >=20 > >> > >> * I think it would be better to avoid the explicit list of encap > >> types in section 5.1.3, and rather refer to > >> draft-ietf-idr-tunnel-encaps instead >=20 > [JORGE] I agree. [JD] According to IANA, it allocated the five tunnels types to the overlay= draft so I think we need to keep them=20 >=20 > >> * the following minor modification was proposed, but not yet incorpora= ted: > >> > >> John Drake, 2015-11-13 (to BESS ML): > >>> For the overlay draft, replace this text in section 5.1.3: > >>> > >>> "If the BGP Encapsulation extended community is not present, > >>> then the default MPLS encapsulation or a statically configured > >>> encapsulation is assumed." > >>> > >>> With the following: > >>> > >>> "Note that the MPLS encapsulation tunnel type is needed in order > >>> to distinguish between an advertising node that only supports > >>> non-MPLS encapsulations and one that supports MPLS and non-MPLS > >>> encapsulations. An advertising node that only supports MPLS > >>> encapsulation does not need to advertise any encapsulation tunnel > >>> types; i.e., if the BGP Encapsulation extended community is not > >>> present, then either MPLS encapsulation or a statically configured > >>> encapsulation is assumed." > >> > >> I think this change is useful and should be incorporated, although > >> skipping the last sentence would be wise if the full list of tunnel > >> types is removed. [JD] Fine with me either w/ or w/o the last sentence =20 From nobody Wed May 4 12:53:49 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2737812D5EE; Wed, 4 May 2016 12:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-uQ7wzlxZV3; Wed, 4 May 2016 12:53:43 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84D6F12D5F0; Wed, 4 May 2016 12:53:39 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 98757AD7FAA51; Wed, 4 May 2016 19:53:33 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u44JrarO024290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 May 2016 19:53:36 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u44JqTT7007216 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 May 2016 21:53:36 +0200 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.187]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Wed, 4 May 2016 21:52:42 +0200 From: "Rabadan, Jorge (Nokia - US)" To: EXT John E Drake , "EXT - thomas.morin@orange.com" , BESS , IDR , "draft-ietf-bess-evpn-overlay@tools.ietf.org" , "Ali Sajassi (sajassi)" Thread-Topic: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps Thread-Index: AQHRpi+kmvQEkxjTwkqTS+eCL8sT/p+o+TOAgAA3cgA= Date: Wed, 4 May 2016 19:52:41 +0000 Message-ID: <012C176C-A8D6-45AA-BA69-616C0ED7E41E@alcatel-lucent.com> References: <5729F1C3.1030605@orange.com> <5729F7C5.6040604@orange.com> <52D35106-ED5E-4C95-9131-6EA4527370D5@alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="utf-8" Content-ID: <04853C23A910B440B296471AAED46510@exchange.lucent.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 19:53:45 -0000 SGkgSm9obiwNCg0KQWJvdXQgdGhpczoNCg0KW0pEXSBGb3IgdGhlIElNRVQgcm91dGUgdGhlIE1Q TFMgbGFiZWwgZmllbGQgaXMgY2FycmllZCBpbiB0aGUgUE1TSSBhdHRyaWJ1dGUuIEkgdGhpbmsg d2UgbmVlZCB0byBhc2sgZXZlcnlvbmUgd2hldGhlciB0aGV5DQp1c2VkIHRoZSBFdGhlcm5ldCBU YWcgb3IgdGhlIFBNU0kgYXR0cmlidXRlIHRvIGNhcnJ5IHRoZSBWTkkgDQoNCg0KSW4gY2FzZSBp dCBoZWxwcywgSeKAmXZlIHNlZW4gYSBmZXcgaW1wbGVtZW50YXRpb25zIHJ1bm5pbmcgYW5kIHRo ZXkgYWxsIGVuY29kZSB0aGUgVk5JIGluIHRoZSBNUExTIGxhYmVsIGZpZWxkIGluIHRoZSBQVEEu IEFuZCBhIGNvdXBsZSBvZiB0aGVtLCBlbmNvZGUgdGhlIFZOSSBpbiB0aGUgZXRoZXJuZXQtdGFn LCBpbiBhZGRpdGlvbiB0byB0aGUgTVBMUyBsYWJlbCBpbiB0aGUgUFRBLiBJbiBhbnkgY2FzZSwg SSB0aGluayBzZWN0aW9uIDkgY29udHJhZGljdHMgc2VjdGlvbiA1LjEuMyBhbmQgc2hvdWxkIGJl IGNsYXJpZmllZC4NCg0KIjUuMS4zIENvbnN0cnVjdGluZyBFVlBOIEJHUCBSb3V0ZXMNCjxzbmlw Pg0KdGhlIE1QTFMgbGFiZWwgZmllbGQgaW4gdGhlIE1BQyBBZHZlcnRpc2VtZW50LCBFdGhlcm5l dCBBRCBwZXIgRVZJLCBhbmQgKipJbmNsdXNpdmUgTXVsdGljYXN0IEV0aGVybmV0IFRhZyoqIHJv dXRlcyBpcyB1c2VkIHRvIGNhcnJ5IHRoZSBWTkkgb3IgVlNJRC4iIA0KDQpUaGFua3MuDQpKb3Jn ZQ0KDQoNCg0KDQoNCk9uIDUvNC8xNiwgODozNCBQTSwgIkVYVCBKb2huIEUgRHJha2UiIDxqZHJh a2VAanVuaXBlci5uZXQ+IHdyb3RlOg0KDQo+VGhvbWFzIGFuZCBKb3JnZSwNCj4NCj5TbmlwcGVk LCBjb21tZW50cyBpbmxpbmUuDQo+DQo+WW91cnMgSXJyZXNwZWN0aXZlbHksDQo+DQo+Sm9obg0K Pg0KPj4gPg0KPj4gPmRyYWZ0LWlldGYtYmVzcy1ldnBuLW92ZXJsYXkgKHNlZSBzZWN0aW9uIDkp IHJlbGllcyBvbiB0aGUgQkdQDQo+PiA+RW5jYXBzdWxhdGlvbiBleHRlbmRlZCB0byBlbmNvZGUg dGhlIHR1bm5lbCBlbmNhcCB0byB1c2UgZm9yIEJVTQ0KPj4gPnRyYWZmaWMsIGJ1dCBjb250cmFy eSB0byBvdGhlciBFLVZQTiByb3V0ZXMsIHJlbGllcyBvbiB0aGUgRXRoZXJuZXQgVGFnDQo+PiA+ ZmllbGQgb2YgdGhlIE5MUkkgdG8gZW5jb2RlIHRoZSBWTkkvVlNJRC4NCj4+IA0KPj4gW0pPUkdF XSBUaGlzIGlzIGNlcnRhaW5seSBhIGxlZnRvdmVyIGZyb20gYW4gb2xkIHZlcnNpb24gd2hlcmUg dGhlIFZOSS9WU0lEIHdhcyBlbmNvZGVkIGluDQo+PiB0aGUgZXRoZXJuZXQgdGFnIGZvciBhbGwg dGhlIHJvdXRlcy4gVGhlIFZOSSBzaG91bGQgYmUgZW5jb2RlZCBpbiB0aGUgTGFiZWwgZmllbGQg aW4gYWxsIHRoZQ0KPj4gcm91dGVzLiBUaGlzIGhhcyB0byBiZSBjb3JyZWN0ZWQuDQo+PiANCj4+ IEluIGZhY3QsIHNlY3Rpb24gNS4xLjMgc2F5czoNCj4+IA0KPj4gNS4xLjMgQ29uc3RydWN0aW5n IEVWUE4gQkdQIFJvdXRlcw0KPj4gDQo+PiA8c25pcD4NCj4+IA0KPj4gQWNjb3JkaW5nbHksIGFu ZA0KPj4gICAgc3BlY2lmaWNhbGx5IHRvIHN1cHBvcnQgdGhlIG9wdGlvbiBvZiBsb2NhbGx5IGFz c2lnbmVkIFZOSXMsIHRoZSBNUExTDQo+PiAgICBsYWJlbCBmaWVsZCBpbiB0aGUgTUFDIEFkdmVy dGlzZW1lbnQsIEV0aGVybmV0IEFEIHBlciBFVkksIGFuZA0KPj4gICAgSW5jbHVzaXZlIE11bHRp Y2FzdCBFdGhlcm5ldCBUYWcgcm91dGVzIGlzIHVzZWQgdG8gY2FycnkgdGhlIFZOSSBvcg0KPj4g ICAgVlNJRC4gIEZvciB0aGUgYmFsYW5jZSBvZiB0aGlzIG1lbW8sIHRoZSBNUExTIGxhYmVsIGZp ZWxkIHdpbGwgYmUNCj4+ICAgIHJlZmVycmVkIHRvIGFzIHRoZSBWTkkvVlNJRCBmaWVsZC4gVGhl IFZOSS9WU0lEIGZpZWxkIGlzIHVzZWQgZm9yDQo+PiAgICBib3RoIGxvY2FsIGFuZCBnbG9iYWwg Vk5Jcy9WU0lEcywgYW5kIGZvciBlaXRoZXIgY2FzZSB0aGUgZW50aXJlIDI0LQ0KPj4gICAgYml0 IGZpZWxkIGlzIHVzZWQgdG8gZW5jb2RlIHRoZSBWTkkvVlNJRCB2YWx1ZS4NCj4+IA0KPj4gPHNu aXA+DQo+DQo+DQo+W0pEXSAgRm9yIHRoZSBJTUVUIHJvdXRlIHRoZSBNUExTIGxhYmVsIGZpZWxk IGlzIGNhcnJpZWQgaW4gdGhlIFBNU0kgYXR0cmlidXRlLiAgSSB0aGluayB3ZSBuZWVkIHRvIGFz ayBldmVyeW9uZSB3aGV0aGVyIHRoZXkNCj51c2VkIHRoZSBFdGhlcm5ldCBUYWcgb3IgdGhlIFBN U0kgYXR0cmlidXRlIHRvIGNhcnJ5IHRoZSBWTkkgICAgDQo+DQo+DQo+PiA+Pg0KPj4gPj4gVGhl cmUgYXJlIG1pbm9yIHRoaW5ncyB0aGF0IGNvdWxkIGJlIGltcHJvdmVkIGluDQo+PiA+PiBkcmFm dC1pZXRmLWJlc3MtZXZwbi1vdmVybGF5IHdydC4gY29uc2lzdGVuY3kgd2l0aA0KPj4gPj4gZHJh ZnQtaWV0Zi1pZHItdHVubmVsLWVuY2FwcyA6DQo+PiA+Pg0KPj4gPj4gKiBzaW5jZSBkcmFmdC1p ZXRmLWlkci10dW5uZWwtZW5jYXBzIHdpbGwgZGVwcmVjYXRlIFJGQzU1MTIsIGl0IHdvdWxkDQo+ PiA+PiBiZSBiZXR0ZXIgdGhhdCBkcmFmdC1pZXRmLWJlc3MtZXZwbi1vdmVybGF5IHJlZmVycyB0 bw0KPj4gPj4gZHJhZnQtaWV0Zi1pZHItdHVubmVsLWVuY2FwcyBhbmQgbm90IGFueW1vcmUgdG8g UkZDNTUxMi4NCj4+IA0KPj4gW0pPUkdFXSBJIGFncmVlLCBhcyBsb25nIGFzIGRyYWZ0LWlldGYt aWRyLXR1bm5lbC1lbmNhcHMga2VlcHMgdGhlIGVuY2Fwc3VsYXRpb24gZXh0ZW5kZWQNCj4+IGNv bW11bml0eS4gVGhlcmUgYXJlIGEgZmV3IGltcGxlbWVudGF0aW9ucyB1c2luZyB0aGlzIGNvbW11 bml0eSBhbmQgaXQgaXMgZW5vdWdoIHdoZW4NCj4+IG9ubHkgdGhlIGVuY2Fwc3VsYXRpb24gdHlw ZSBpcyBuZWVkZWQuDQo+DQo+DQo+W0pEXSAgIEkgYWdyZWUgYW5kIHRoZSB0dW5uZWwgZW5jYXBz IGRyYWZ0IGRvZXMga2VlcCB0aGUgRUMNCj4NCj4NCj4+IA0KPj4gPj4NCj4+ID4+ICogSSB0aGlu ayBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gYXZvaWQgdGhlIGV4cGxpY2l0IGxpc3Qgb2YgZW5jYXAN Cj4+ID4+IHR5cGVzIGluIHNlY3Rpb24gNS4xLjMsIGFuZCByYXRoZXIgcmVmZXIgdG8NCj4+ID4+ IGRyYWZ0LWlldGYtaWRyLXR1bm5lbC1lbmNhcHMgaW5zdGVhZA0KPj4gDQo+PiBbSk9SR0VdIEkg YWdyZWUuDQo+DQo+DQo+W0pEXSAgQWNjb3JkaW5nIHRvIElBTkEsIGl0IGFsbG9jYXRlZCB0aGUg Zml2ZSB0dW5uZWxzIHR5cGVzIHRvIHRoZSBvdmVybGF5IGRyYWZ0IHNvIEkgdGhpbmsgd2UgbmVl ZCB0byBrZWVwIHRoZW0gDQo+DQo+DQo+PiANCj4+ID4+ICogdGhlIGZvbGxvd2luZyBtaW5vciBt b2RpZmljYXRpb24gd2FzIHByb3Bvc2VkLCBidXQgbm90IHlldCBpbmNvcnBvcmF0ZWQ6DQo+PiA+ Pg0KPj4gPj4gICAgIEpvaG4gRHJha2UsIDIwMTUtMTEtMTMgKHRvIEJFU1MgTUwpOg0KPj4gPj4+ ICAgICBGb3IgdGhlIG92ZXJsYXkgZHJhZnQsIHJlcGxhY2UgdGhpcyB0ZXh0IGluIHNlY3Rpb24g NS4xLjM6DQo+PiA+Pj4NCj4+ID4+PiAgICAgIklmIHRoZSBCR1AgRW5jYXBzdWxhdGlvbiBleHRl bmRlZCBjb21tdW5pdHkgaXMgbm90IHByZXNlbnQsDQo+PiA+Pj4gdGhlbiB0aGUgZGVmYXVsdCBN UExTIGVuY2Fwc3VsYXRpb24gb3IgYSBzdGF0aWNhbGx5IGNvbmZpZ3VyZWQNCj4+ID4+PiBlbmNh cHN1bGF0aW9uIGlzIGFzc3VtZWQuIg0KPj4gPj4+DQo+PiA+Pj4gICAgIFdpdGggdGhlIGZvbGxv d2luZzoNCj4+ID4+Pg0KPj4gPj4+ICAgICAiTm90ZSB0aGF0IHRoZSBNUExTIGVuY2Fwc3VsYXRp b24gdHVubmVsIHR5cGUgaXMgbmVlZGVkIGluIG9yZGVyDQo+PiA+Pj4gdG8gZGlzdGluZ3Vpc2gg YmV0d2VlbiBhbiBhZHZlcnRpc2luZyBub2RlIHRoYXQgb25seSBzdXBwb3J0cw0KPj4gPj4+IG5v bi1NUExTIGVuY2Fwc3VsYXRpb25zIGFuZCBvbmUgdGhhdCBzdXBwb3J0cyBNUExTIGFuZCBub24t TVBMUw0KPj4gPj4+IGVuY2Fwc3VsYXRpb25zLiAgQW4gIGFkdmVydGlzaW5nIG5vZGUgdGhhdCBv bmx5IHN1cHBvcnRzIE1QTFMNCj4+ID4+PiBlbmNhcHN1bGF0aW9uIGRvZXMgbm90IG5lZWQgdG8g YWR2ZXJ0aXNlIGFueSBlbmNhcHN1bGF0aW9uIHR1bm5lbA0KPj4gPj4+IHR5cGVzOyAgaS5lLiwg IGlmIHRoZSBCR1AgRW5jYXBzdWxhdGlvbiBleHRlbmRlZCBjb21tdW5pdHkgaXMgbm90DQo+PiA+ Pj4gcHJlc2VudCwgdGhlbiBlaXRoZXIgTVBMUyBlbmNhcHN1bGF0aW9uIG9yIGEgc3RhdGljYWxs eSBjb25maWd1cmVkDQo+PiA+Pj4gZW5jYXBzdWxhdGlvbiBpcyBhc3N1bWVkLiINCj4+ID4+DQo+ PiA+PiBJIHRoaW5rIHRoaXMgY2hhbmdlIGlzIHVzZWZ1bCBhbmQgc2hvdWxkIGJlIGluY29ycG9y YXRlZCwgYWx0aG91Z2gNCj4+ID4+IHNraXBwaW5nIHRoZSBsYXN0IHNlbnRlbmNlIHdvdWxkIGJl IHdpc2UgaWYgdGhlIGZ1bGwgbGlzdCBvZiB0dW5uZWwNCj4+ID4+IHR5cGVzIGlzIHJlbW92ZWQu DQo+DQo+DQo+W0pEXSAgRmluZSB3aXRoIG1lIGVpdGhlciB3LyBvciB3L28gdGhlIGxhc3Qgc2Vu dGVuY2UgIA0KPg0KPg0K From nobody Wed May 4 12:58:48 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29A4512D5D1; Wed, 4 May 2016 12:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1piS_KIA5yqV; Wed, 4 May 2016 12:58:45 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E25912D52A; Wed, 4 May 2016 12:58:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1363; q=dns/txt; s=iport; t=1462391925; x=1463601525; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=GCNDTjxzSi+mk8yDMG0C6FVXRzl6fdPykcC7T4VgQEM=; b=gNxReHHqOFLh8csKdk9m8hieJZMrKFUWigPqRhxWcN9+SlVQg3Ar/nIm ByhGDSQ6DBH/xrnLKPU+27jJzaDXRoDNiyoo7vX7U+RshSQdwTNShF132 G7GEO4wl9KuSSgC86iJlDCdhoIWOChPP3QaAsPQw+aQygIH6F1nyw2iaO c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AdAgAyUypX/5hdJa1egziBUAa3VYIPA?= =?us-ascii?q?Q2BdoYQAoE6OBQBAQEBAQEBZSeEQgEBBHkQAgEIRjIlAgQOBYgqvWUBAQEBAQE?= =?us-ascii?q?BAwEBAQEBAQEZhiCDSoEDihgBBI4QhRSEdQGOF48TjzMBHgEBQoIFGxaBNWyHP?= =?us-ascii?q?X8BAQE?= X-IronPort-AV: E=Sophos;i="5.24,578,1454976000"; d="scan'208";a="103743557" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 May 2016 19:58:44 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u44JwiPV000711 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 May 2016 19:58:44 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 4 May 2016 14:58:44 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Wed, 4 May 2016 14:58:44 -0500 From: "Alvaro Retana (aretana)" To: "Mirja Kuehlewind (IETF)" Thread-Topic: =?iso-8859-1?Q?Mirja_K=FChlewind's_No_Objection_on_draft-ietf-idr-add-pat?= =?iso-8859-1?Q?hs-14:_(with_COMMENT)?= Thread-Index: AQHRpFYKSZlB3k9yyUuAN91bh8HyHp+nXNqAgABdSwCAAYykAA== Date: Wed, 4 May 2016 19:58:44 +0000 Message-ID: References: <20160502093559.23688.94285.idtracker@ietfa.amsl.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.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.247.86] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <02D979CB577876418F97F158A6B89EE4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-idr-add-paths@ietf.org" , Russ White , "idr@ietf.org" , The IESG , "idr-chairs@ietf.org" Subject: Re: [Idr] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_draft-?= =?iso-8859-1?q?ietf-idr-add-paths-14=3A_=28with_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 19:58:47 -0000 On 5/3/16, 12:19 PM, "Mirja Kuehlewind (IETF)" wrote: Mirja: Hi! >I was think about a case, where two paths are advertised and than maybe >someones uses those two paths to do some complex multipath routing, while >at the end this would be unnecessary as both advertised path are >physically the same. Not sure if that would ever be the case or I=B9m >making things up.=20 Not really. In general, for any type of complex multi-path routing we would probably rely on the IGP information which provides a better picture of the path inside the network. BGP only points at the next-hop, which in this case is the next autonomous system (and not necessarily something directly connected). Having said that, BGP does provide an AS-PATH, but that only shows a high level (logical) view of the path being used. From that point of view it would be easy to determine whether the routes would follow the same path...but not with physical granularity. >If you tell me that there is no further discussion needed, that=B9s fine >for me as the doc doesn=B9t really talk at all about any assumptions that >should be made about the (physical) path that is used. No assumptions should be made -- the document only changes the interpretation of the NLRI, not the selection process of the best route. Thanks! Alvaro. From nobody Wed May 4 13:45:59 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 588A412D1CD; Wed, 4 May 2016 13:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQPX0TmekPyH; Wed, 4 May 2016 13:45:52 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-eopbgr680096.outbound.protection.outlook.com [40.107.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D5DC12D81D; Wed, 4 May 2016 13:45:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=QRd0WfJ7cNnlM74/fFvy/gOPp/1Q9VIZqPiOBvuFaf0=; b=PGpqPQ7/C0AYk85Bt78TanAApnyNBuZOnCcVdYd2lTgYKlxNAhRC1x27onoISlT+ic+Mu3sTLihfEwDP3g7aB2dAuLIOZnJFhPXOPFOE2WFnOzm54rCkilGQ7cPBB0RqNTPRh20Wq1ZBmFef6oD/0bRbBYkGRmmac2+cDRoheO8= Received: from CY1PR05MB2220.namprd05.prod.outlook.com (10.166.192.20) by CY1PR0501MB1705.namprd05.prod.outlook.com (10.163.140.154) with Microsoft SMTP Server (TLS) id 15.1.485.9; Wed, 4 May 2016 20:45:50 +0000 Received: from CY1PR05MB2220.namprd05.prod.outlook.com ([10.166.192.20]) by CY1PR05MB2220.namprd05.prod.outlook.com ([10.166.192.20]) with mapi id 15.01.0485.011; Wed, 4 May 2016 20:45:50 +0000 From: Ravi Shekhar To: "Rabadan, Jorge (Nokia - US)" , John E Drake , "EXT - thomas.morin@orange.com" , BESS , IDR , "draft-ietf-bess-evpn-overlay@tools.ietf.org" , "Ali Sajassi (sajassi)" Thread-Topic: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps Thread-Index: AQHRpi+6Yxu+7jyT7UG9wH5rbs/8yp+pGrqAgAAV74CAAA3WoA== Date: Wed, 4 May 2016 20:45:50 +0000 Message-ID: References: <5729F1C3.1030605@orange.com> <5729F7C5.6040604@orange.com> <52D35106-ED5E-4C95-9131-6EA4527370D5@alcatel-lucent.com> <012C176C-A8D6-45AA-BA69-616C0ED7E41E@alcatel-lucent.com> In-Reply-To: <012C176C-A8D6-45AA-BA69-616C0ED7E41E@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nokia.com; dkim=none (message not signed) header.d=none;nokia.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.239.12] x-ms-office365-filtering-correlation-id: 47d135a1-e36a-4e04-fc62-08d3745d1402 x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1705; 5:3syhuTACRKHeIdqTqUOzBiKq2ugJBtpy1QvL2enaJ8rHWwxohwECGl0vIi/TMWw2jgH5DlBsgSDSOjgostWo1rmTjoET0N/LCAtMuJTlbLNOhYYnBrIT2OYNjl8W9wngjamoKpyYEnVVbBTDj6Jm1Q==; 24:bwbq4LJYT/Ei0yrYAMFTEfCRsBE9duIGmDIL/dbqbj1tcmtAWxMwTsdDcx1I1NOnNh6w6YFB3n1U3y2xYimnh1y0S8c938sZdt1y9onyp1U=; 7:mXGfT1N6NA7fW7zzGNlh/FfPyUGftKOuNL/I+M4PW3YNr1l5kGMfN0yayMtV6J0Fj++8SNs6bIhQwGz7FJ2224C0lZsyVSK01Gf2m39MWaMuRwkTyXLYJgmhXeDxi44BdAt+bLSCUKxUxRBkF1jF7+BwYQtzkWfUpP7YULPR9I8= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1705; x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101528026)(9101521098)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:CY1PR0501MB1705; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1705; x-forefront-prvs: 093290AD39 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377424004)(377454003)(13464003)(24454002)(5008740100001)(87936001)(19580405001)(2906002)(92566002)(86362001)(81166005)(2501003)(107886002)(122556002)(5002640100001)(19580395003)(8936002)(106116001)(189998001)(99286002)(10400500002)(230783001)(77096005)(1220700001)(102836003)(5004730100002)(33656002)(2950100001)(3846002)(76176999)(6116002)(9686002)(586003)(50986999)(3660700001)(76576001)(3280700002)(74316001)(5003600100002)(15975445007)(11100500001)(54356999)(93886004)(5001770100001)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1705; H:CY1PR05MB2220.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2016 20:45:50.4798 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1705 Archived-At: Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 20:45:55 -0000 SGkgSm9yZ2UsDQpUaGUgVk5JIGZpZWxkIGluIEV0aGVybmV0IFRhZyBoYXMgYmVlbiB1c2VkIHRv IGRpZmZlcmVudGlhdGUgdHdvIEJHUCByb3V0ZXMgdGhhdCBoYXZlIHNhbWUgTUFDIGJ1dCBkaWZm ZXJlbnQgVk5JL1ZMQU4tSUQuIElkZWFsbHksIGl0IHNob3VsZCBub3QgYmUgdXNlZCBmb3IgbmV4 dGhvcCBjcmVhdGlvbi4gTWF5IGJlIHdlIGNhbiBhZGQgdGhhdCBjbGFyaWZpY2F0aW9uLg0KVGhh bmtzLg0KLSBSYXZpLg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBCRVNT IFttYWlsdG86YmVzcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUmFiYWRhbiwgSm9y Z2UgKE5va2lhIC0gVVMpDQpTZW50OiBXZWRuZXNkYXksIE1heSAwNCwgMjAxNiAxMjo1MyBQTQ0K VG86IEpvaG4gRSBEcmFrZSA8amRyYWtlQGp1bmlwZXIubmV0PjsgRVhUIC0gdGhvbWFzLm1vcmlu QG9yYW5nZS5jb20gPHRob21hcy5tb3JpbkBvcmFuZ2UuY29tPjsgQkVTUyA8YmVzc0BpZXRmLm9y Zz47IElEUiA8aWRyQGlldGYub3JnPjsgZHJhZnQtaWV0Zi1iZXNzLWV2cG4tb3ZlcmxheUB0b29s cy5pZXRmLm9yZzsgQWxpIFNhamFzc2kgKHNhamFzc2kpIDxzYWphc3NpQGNpc2NvLmNvbT4NClN1 YmplY3Q6IFJlOiBbYmVzc10gW0lkcl0gZHJhZnQtaWV0Zi1iZXNzLWV2cG4tb3ZlcmxheSB2cy4g ZHJhZnQtaWV0Zi1pZHItdHVubmVsLWVuY2Fwcw0KDQpIaSBKb2huLA0KDQpBYm91dCB0aGlzOg0K DQpbSkRdIEZvciB0aGUgSU1FVCByb3V0ZSB0aGUgTVBMUyBsYWJlbCBmaWVsZCBpcyBjYXJyaWVk IGluIHRoZSBQTVNJIGF0dHJpYnV0ZS4gSSB0aGluayB3ZSBuZWVkIHRvIGFzayBldmVyeW9uZSB3 aGV0aGVyIHRoZXkgdXNlZCB0aGUgRXRoZXJuZXQgVGFnIG9yIHRoZSBQTVNJIGF0dHJpYnV0ZSB0 byBjYXJyeSB0aGUgVk5JIA0KDQoNCkluIGNhc2UgaXQgaGVscHMsIEnigJl2ZSBzZWVuIGEgZmV3 IGltcGxlbWVudGF0aW9ucyBydW5uaW5nIGFuZCB0aGV5IGFsbCBlbmNvZGUgdGhlIFZOSSBpbiB0 aGUgTVBMUyBsYWJlbCBmaWVsZCBpbiB0aGUgUFRBLiBBbmQgYSBjb3VwbGUgb2YgdGhlbSwgZW5j b2RlIHRoZSBWTkkgaW4gdGhlIGV0aGVybmV0LXRhZywgaW4gYWRkaXRpb24gdG8gdGhlIE1QTFMg bGFiZWwgaW4gdGhlIFBUQS4gSW4gYW55IGNhc2UsIEkgdGhpbmsgc2VjdGlvbiA5IGNvbnRyYWRp Y3RzIHNlY3Rpb24gNS4xLjMgYW5kIHNob3VsZCBiZSBjbGFyaWZpZWQuDQoNCiI1LjEuMyBDb25z dHJ1Y3RpbmcgRVZQTiBCR1AgUm91dGVzDQo8c25pcD4NCnRoZSBNUExTIGxhYmVsIGZpZWxkIGlu IHRoZSBNQUMgQWR2ZXJ0aXNlbWVudCwgRXRoZXJuZXQgQUQgcGVyIEVWSSwgYW5kICoqSW5jbHVz aXZlIE11bHRpY2FzdCBFdGhlcm5ldCBUYWcqKiByb3V0ZXMgaXMgdXNlZCB0byBjYXJyeSB0aGUg Vk5JIG9yIFZTSUQuIiANCg0KVGhhbmtzLg0KSm9yZ2UNCg0KDQoNCg0KDQpPbiA1LzQvMTYsIDg6 MzQgUE0sICJFWFQgSm9obiBFIERyYWtlIiA8amRyYWtlQGp1bmlwZXIubmV0PiB3cm90ZToNCg0K PlRob21hcyBhbmQgSm9yZ2UsDQo+DQo+U25pcHBlZCwgY29tbWVudHMgaW5saW5lLg0KPg0KPllv dXJzIElycmVzcGVjdGl2ZWx5LA0KPg0KPkpvaG4NCj4NCj4+ID4NCj4+ID5kcmFmdC1pZXRmLWJl c3MtZXZwbi1vdmVybGF5IChzZWUgc2VjdGlvbiA5KSByZWxpZXMgb24gdGhlIEJHUCANCj4+ID5F bmNhcHN1bGF0aW9uIGV4dGVuZGVkIHRvIGVuY29kZSB0aGUgdHVubmVsIGVuY2FwIHRvIHVzZSBm b3IgQlVNIA0KPj4gPnRyYWZmaWMsIGJ1dCBjb250cmFyeSB0byBvdGhlciBFLVZQTiByb3V0ZXMs IHJlbGllcyBvbiB0aGUgRXRoZXJuZXQgDQo+PiA+VGFnIGZpZWxkIG9mIHRoZSBOTFJJIHRvIGVu Y29kZSB0aGUgVk5JL1ZTSUQuDQo+PiANCj4+IFtKT1JHRV0gVGhpcyBpcyBjZXJ0YWlubHkgYSBs ZWZ0b3ZlciBmcm9tIGFuIG9sZCB2ZXJzaW9uIHdoZXJlIHRoZSANCj4+IFZOSS9WU0lEIHdhcyBl bmNvZGVkIGluIHRoZSBldGhlcm5ldCB0YWcgZm9yIGFsbCB0aGUgcm91dGVzLiBUaGUgVk5JIA0K Pj4gc2hvdWxkIGJlIGVuY29kZWQgaW4gdGhlIExhYmVsIGZpZWxkIGluIGFsbCB0aGUgcm91dGVz LiBUaGlzIGhhcyB0byBiZSBjb3JyZWN0ZWQuDQo+PiANCj4+IEluIGZhY3QsIHNlY3Rpb24gNS4x LjMgc2F5czoNCj4+IA0KPj4gNS4xLjMgQ29uc3RydWN0aW5nIEVWUE4gQkdQIFJvdXRlcw0KPj4g DQo+PiA8c25pcD4NCj4+IA0KPj4gQWNjb3JkaW5nbHksIGFuZA0KPj4gICAgc3BlY2lmaWNhbGx5 IHRvIHN1cHBvcnQgdGhlIG9wdGlvbiBvZiBsb2NhbGx5IGFzc2lnbmVkIFZOSXMsIHRoZSBNUExT DQo+PiAgICBsYWJlbCBmaWVsZCBpbiB0aGUgTUFDIEFkdmVydGlzZW1lbnQsIEV0aGVybmV0IEFE IHBlciBFVkksIGFuZA0KPj4gICAgSW5jbHVzaXZlIE11bHRpY2FzdCBFdGhlcm5ldCBUYWcgcm91 dGVzIGlzIHVzZWQgdG8gY2FycnkgdGhlIFZOSSBvcg0KPj4gICAgVlNJRC4gIEZvciB0aGUgYmFs YW5jZSBvZiB0aGlzIG1lbW8sIHRoZSBNUExTIGxhYmVsIGZpZWxkIHdpbGwgYmUNCj4+ICAgIHJl ZmVycmVkIHRvIGFzIHRoZSBWTkkvVlNJRCBmaWVsZC4gVGhlIFZOSS9WU0lEIGZpZWxkIGlzIHVz ZWQgZm9yDQo+PiAgICBib3RoIGxvY2FsIGFuZCBnbG9iYWwgVk5Jcy9WU0lEcywgYW5kIGZvciBl aXRoZXIgY2FzZSB0aGUgZW50aXJlIDI0LQ0KPj4gICAgYml0IGZpZWxkIGlzIHVzZWQgdG8gZW5j b2RlIHRoZSBWTkkvVlNJRCB2YWx1ZS4NCj4+IA0KPj4gPHNuaXA+DQo+DQo+DQo+W0pEXSAgRm9y IHRoZSBJTUVUIHJvdXRlIHRoZSBNUExTIGxhYmVsIGZpZWxkIGlzIGNhcnJpZWQgaW4gdGhlIFBN U0kgYXR0cmlidXRlLiAgSSB0aGluayB3ZSBuZWVkIHRvIGFzayBldmVyeW9uZSB3aGV0aGVyIHRo ZXkNCj51c2VkIHRoZSBFdGhlcm5ldCBUYWcgb3IgdGhlIFBNU0kgYXR0cmlidXRlIHRvIGNhcnJ5 IHRoZSBWTkkgICAgDQo+DQo+DQo+PiA+Pg0KPj4gPj4gVGhlcmUgYXJlIG1pbm9yIHRoaW5ncyB0 aGF0IGNvdWxkIGJlIGltcHJvdmVkIGluIA0KPj4gPj4gZHJhZnQtaWV0Zi1iZXNzLWV2cG4tb3Zl cmxheSB3cnQuIGNvbnNpc3RlbmN5IHdpdGggDQo+PiA+PiBkcmFmdC1pZXRmLWlkci10dW5uZWwt ZW5jYXBzIDoNCj4+ID4+DQo+PiA+PiAqIHNpbmNlIGRyYWZ0LWlldGYtaWRyLXR1bm5lbC1lbmNh cHMgd2lsbCBkZXByZWNhdGUgUkZDNTUxMiwgaXQgDQo+PiA+PiB3b3VsZCBiZSBiZXR0ZXIgdGhh dCBkcmFmdC1pZXRmLWJlc3MtZXZwbi1vdmVybGF5IHJlZmVycyB0byANCj4+ID4+IGRyYWZ0LWll dGYtaWRyLXR1bm5lbC1lbmNhcHMgYW5kIG5vdCBhbnltb3JlIHRvIFJGQzU1MTIuDQo+PiANCj4+ IFtKT1JHRV0gSSBhZ3JlZSwgYXMgbG9uZyBhcyBkcmFmdC1pZXRmLWlkci10dW5uZWwtZW5jYXBz IGtlZXBzIHRoZSANCj4+IGVuY2Fwc3VsYXRpb24gZXh0ZW5kZWQgY29tbXVuaXR5LiBUaGVyZSBh cmUgYSBmZXcgaW1wbGVtZW50YXRpb25zIA0KPj4gdXNpbmcgdGhpcyBjb21tdW5pdHkgYW5kIGl0 IGlzIGVub3VnaCB3aGVuIG9ubHkgdGhlIGVuY2Fwc3VsYXRpb24gdHlwZSBpcyBuZWVkZWQuDQo+ DQo+DQo+W0pEXSAgIEkgYWdyZWUgYW5kIHRoZSB0dW5uZWwgZW5jYXBzIGRyYWZ0IGRvZXMga2Vl cCB0aGUgRUMNCj4NCj4NCj4+IA0KPj4gPj4NCj4+ID4+ICogSSB0aGluayBpdCB3b3VsZCBiZSBi ZXR0ZXIgdG8gYXZvaWQgdGhlIGV4cGxpY2l0IGxpc3Qgb2YgZW5jYXAgDQo+PiA+PiB0eXBlcyBp biBzZWN0aW9uIDUuMS4zLCBhbmQgcmF0aGVyIHJlZmVyIHRvIA0KPj4gPj4gZHJhZnQtaWV0Zi1p ZHItdHVubmVsLWVuY2FwcyBpbnN0ZWFkDQo+PiANCj4+IFtKT1JHRV0gSSBhZ3JlZS4NCj4NCj4N Cj5bSkRdICBBY2NvcmRpbmcgdG8gSUFOQSwgaXQgYWxsb2NhdGVkIHRoZSBmaXZlIHR1bm5lbHMg dHlwZXMgdG8gdGhlIA0KPm92ZXJsYXkgZHJhZnQgc28gSSB0aGluayB3ZSBuZWVkIHRvIGtlZXAg dGhlbQ0KPg0KPg0KPj4gDQo+PiA+PiAqIHRoZSBmb2xsb3dpbmcgbWlub3IgbW9kaWZpY2F0aW9u IHdhcyBwcm9wb3NlZCwgYnV0IG5vdCB5ZXQgaW5jb3Jwb3JhdGVkOg0KPj4gPj4NCj4+ID4+ICAg ICBKb2huIERyYWtlLCAyMDE1LTExLTEzICh0byBCRVNTIE1MKToNCj4+ID4+PiAgICAgRm9yIHRo ZSBvdmVybGF5IGRyYWZ0LCByZXBsYWNlIHRoaXMgdGV4dCBpbiBzZWN0aW9uIDUuMS4zOg0KPj4g Pj4+DQo+PiA+Pj4gICAgICJJZiB0aGUgQkdQIEVuY2Fwc3VsYXRpb24gZXh0ZW5kZWQgY29tbXVu aXR5IGlzIG5vdCBwcmVzZW50LCANCj4+ID4+PiB0aGVuIHRoZSBkZWZhdWx0IE1QTFMgZW5jYXBz dWxhdGlvbiBvciBhIHN0YXRpY2FsbHkgY29uZmlndXJlZCANCj4+ID4+PiBlbmNhcHN1bGF0aW9u IGlzIGFzc3VtZWQuIg0KPj4gPj4+DQo+PiA+Pj4gICAgIFdpdGggdGhlIGZvbGxvd2luZzoNCj4+ ID4+Pg0KPj4gPj4+ICAgICAiTm90ZSB0aGF0IHRoZSBNUExTIGVuY2Fwc3VsYXRpb24gdHVubmVs IHR5cGUgaXMgbmVlZGVkIGluIA0KPj4gPj4+IG9yZGVyIHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4g YW4gYWR2ZXJ0aXNpbmcgbm9kZSB0aGF0IG9ubHkgDQo+PiA+Pj4gc3VwcG9ydHMgbm9uLU1QTFMg ZW5jYXBzdWxhdGlvbnMgYW5kIG9uZSB0aGF0IHN1cHBvcnRzIE1QTFMgYW5kIA0KPj4gPj4+IG5v bi1NUExTIGVuY2Fwc3VsYXRpb25zLiAgQW4gIGFkdmVydGlzaW5nIG5vZGUgdGhhdCBvbmx5IHN1 cHBvcnRzIA0KPj4gPj4+IE1QTFMgZW5jYXBzdWxhdGlvbiBkb2VzIG5vdCBuZWVkIHRvIGFkdmVy dGlzZSBhbnkgZW5jYXBzdWxhdGlvbiANCj4+ID4+PiB0dW5uZWwgdHlwZXM7ICBpLmUuLCAgaWYg dGhlIEJHUCBFbmNhcHN1bGF0aW9uIGV4dGVuZGVkIGNvbW11bml0eSANCj4+ID4+PiBpcyBub3Qg cHJlc2VudCwgdGhlbiBlaXRoZXIgTVBMUyBlbmNhcHN1bGF0aW9uIG9yIGEgc3RhdGljYWxseSAN Cj4+ID4+PiBjb25maWd1cmVkIGVuY2Fwc3VsYXRpb24gaXMgYXNzdW1lZC4iDQo+PiA+Pg0KPj4g Pj4gSSB0aGluayB0aGlzIGNoYW5nZSBpcyB1c2VmdWwgYW5kIHNob3VsZCBiZSBpbmNvcnBvcmF0 ZWQsIGFsdGhvdWdoIA0KPj4gPj4gc2tpcHBpbmcgdGhlIGxhc3Qgc2VudGVuY2Ugd291bGQgYmUg d2lzZSBpZiB0aGUgZnVsbCBsaXN0IG9mIA0KPj4gPj4gdHVubmVsIHR5cGVzIGlzIHJlbW92ZWQu DQo+DQo+DQo+W0pEXSAgRmluZSB3aXRoIG1lIGVpdGhlciB3LyBvciB3L28gdGhlIGxhc3Qgc2Vu dGVuY2UNCj4NCj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpCRVNTIG1haWxpbmcgbGlzdA0KQkVTU0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9iZXNzDQo= From nobody Wed May 4 14:25:28 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29D7F12D97E; Wed, 4 May 2016 14:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rtu644RhceR3; Wed, 4 May 2016 14:25:20 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89F6512D8A8; Wed, 4 May 2016 14:25:19 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 16312739A12DE; Wed, 4 May 2016 21:25:12 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u44LPF6k007067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 May 2016 21:25:15 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u44LPF44006780 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 May 2016 23:25:15 +0200 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.187]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Wed, 4 May 2016 23:25:15 +0200 From: "Rabadan, Jorge (Nokia - US)" To: EXT Ravi Shekhar , John E Drake , "EXT - thomas.morin@orange.com" , BESS , IDR , "draft-ietf-bess-evpn-overlay@tools.ietf.org" , "Ali Sajassi (sajassi)" Thread-Topic: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps Thread-Index: AQHRpi+kmvQEkxjTwkqTS+eCL8sT/p+o+TOAgAA3cgD//+1XAIAALIQA Date: Wed, 4 May 2016 21:25:14 +0000 Message-ID: <2F7BA699-A7F3-43DD-AE94-33ADF6866E8F@alcatel-lucent.com> References: <5729F1C3.1030605@orange.com> <5729F7C5.6040604@orange.com> <52D35106-ED5E-4C95-9131-6EA4527370D5@alcatel-lucent.com> <012C176C-A8D6-45AA-BA69-616C0ED7E41E@alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="utf-8" Content-ID: <10AE155D3E62C14DAA7814BCE8833973@exchange.lucent.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 21:25:23 -0000 SGkgUmF2aSwNCg0KT2YgY291cnNlLCBpbiBjYXNlIG9mIHZsYW4tYXdhcmUgYnVuZGxlIHNlcnZp Y2VzLiBCdXQgc2hvdWxkIGJlIHplcm8gaW4gY2FzZSBvZiBWTEFOLWJhc2VkIG9yIFZMQU4tYnVu ZGxlLg0KVGh4DQpKb3JnZSANCg0KDQoNCg0KT24gNS80LzE2LCAxMDo0NSBQTSwgIkVYVCBSYXZp IFNoZWtoYXIiIDxyc2hla2hhckBqdW5pcGVyLm5ldD4gd3JvdGU6DQoNCj5IaSBKb3JnZSwNCj5U aGUgVk5JIGZpZWxkIGluIEV0aGVybmV0IFRhZyBoYXMgYmVlbiB1c2VkIHRvIGRpZmZlcmVudGlh dGUgdHdvIEJHUCByb3V0ZXMgdGhhdCBoYXZlIHNhbWUgTUFDIGJ1dCBkaWZmZXJlbnQgVk5JL1ZM QU4tSUQuIElkZWFsbHksIGl0IHNob3VsZCBub3QgYmUgdXNlZCBmb3IgbmV4dGhvcCBjcmVhdGlv bi4gTWF5IGJlIHdlIGNhbiBhZGQgdGhhdCBjbGFyaWZpY2F0aW9uLg0KPlRoYW5rcy4NCj4tIFJh dmkuDQo+DQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBCRVNTIFttYWls dG86YmVzcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUmFiYWRhbiwgSm9yZ2UgKE5v a2lhIC0gVVMpDQo+U2VudDogV2VkbmVzZGF5LCBNYXkgMDQsIDIwMTYgMTI6NTMgUE0NCj5Ubzog Sm9obiBFIERyYWtlIDxqZHJha2VAanVuaXBlci5uZXQ+OyBFWFQgLSB0aG9tYXMubW9yaW5Ab3Jh bmdlLmNvbSA8dGhvbWFzLm1vcmluQG9yYW5nZS5jb20+OyBCRVNTIDxiZXNzQGlldGYub3JnPjsg SURSIDxpZHJAaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLWJlc3MtZXZwbi1vdmVybGF5QHRvb2xzLmll dGYub3JnOyBBbGkgU2FqYXNzaSAoc2FqYXNzaSkgPHNhamFzc2lAY2lzY28uY29tPg0KPlN1Ympl Y3Q6IFJlOiBbYmVzc10gW0lkcl0gZHJhZnQtaWV0Zi1iZXNzLWV2cG4tb3ZlcmxheSB2cy4gZHJh ZnQtaWV0Zi1pZHItdHVubmVsLWVuY2Fwcw0KPg0KPkhpIEpvaG4sDQo+DQo+QWJvdXQgdGhpczoN Cj4NCj5bSkRdIEZvciB0aGUgSU1FVCByb3V0ZSB0aGUgTVBMUyBsYWJlbCBmaWVsZCBpcyBjYXJy aWVkIGluIHRoZSBQTVNJIGF0dHJpYnV0ZS4gSSB0aGluayB3ZSBuZWVkIHRvIGFzayBldmVyeW9u ZSB3aGV0aGVyIHRoZXkgdXNlZCB0aGUgRXRoZXJuZXQgVGFnIG9yIHRoZSBQTVNJIGF0dHJpYnV0 ZSB0byBjYXJyeSB0aGUgVk5JIA0KPg0KPg0KPkluIGNhc2UgaXQgaGVscHMsIEnigJl2ZSBzZWVu IGEgZmV3IGltcGxlbWVudGF0aW9ucyBydW5uaW5nIGFuZCB0aGV5IGFsbCBlbmNvZGUgdGhlIFZO SSBpbiB0aGUgTVBMUyBsYWJlbCBmaWVsZCBpbiB0aGUgUFRBLiBBbmQgYSBjb3VwbGUgb2YgdGhl bSwgZW5jb2RlIHRoZSBWTkkgaW4gdGhlIGV0aGVybmV0LXRhZywgaW4gYWRkaXRpb24gdG8gdGhl IE1QTFMgbGFiZWwgaW4gdGhlIFBUQS4gSW4gYW55IGNhc2UsIEkgdGhpbmsgc2VjdGlvbiA5IGNv bnRyYWRpY3RzIHNlY3Rpb24gNS4xLjMgYW5kIHNob3VsZCBiZSBjbGFyaWZpZWQuDQo+DQo+IjUu MS4zIENvbnN0cnVjdGluZyBFVlBOIEJHUCBSb3V0ZXMNCj48c25pcD4NCj50aGUgTVBMUyBsYWJl bCBmaWVsZCBpbiB0aGUgTUFDIEFkdmVydGlzZW1lbnQsIEV0aGVybmV0IEFEIHBlciBFVkksIGFu ZCAqKkluY2x1c2l2ZSBNdWx0aWNhc3QgRXRoZXJuZXQgVGFnKiogcm91dGVzIGlzIHVzZWQgdG8g Y2FycnkgdGhlIFZOSSBvciBWU0lELiIgDQo+DQo+VGhhbmtzLg0KPkpvcmdlDQo+DQo+DQo+DQo+ DQo+DQo+T24gNS80LzE2LCA4OjM0IFBNLCAiRVhUIEpvaG4gRSBEcmFrZSIgPGpkcmFrZUBqdW5p cGVyLm5ldD4gd3JvdGU6DQo+DQo+PlRob21hcyBhbmQgSm9yZ2UsDQo+Pg0KPj5TbmlwcGVkLCBj b21tZW50cyBpbmxpbmUuDQo+Pg0KPj5Zb3VycyBJcnJlc3BlY3RpdmVseSwNCj4+DQo+PkpvaG4N Cj4+DQo+Pj4gPg0KPj4+ID5kcmFmdC1pZXRmLWJlc3MtZXZwbi1vdmVybGF5IChzZWUgc2VjdGlv biA5KSByZWxpZXMgb24gdGhlIEJHUCANCj4+PiA+RW5jYXBzdWxhdGlvbiBleHRlbmRlZCB0byBl bmNvZGUgdGhlIHR1bm5lbCBlbmNhcCB0byB1c2UgZm9yIEJVTSANCj4+PiA+dHJhZmZpYywgYnV0 IGNvbnRyYXJ5IHRvIG90aGVyIEUtVlBOIHJvdXRlcywgcmVsaWVzIG9uIHRoZSBFdGhlcm5ldCAN Cj4+PiA+VGFnIGZpZWxkIG9mIHRoZSBOTFJJIHRvIGVuY29kZSB0aGUgVk5JL1ZTSUQuDQo+Pj4g DQo+Pj4gW0pPUkdFXSBUaGlzIGlzIGNlcnRhaW5seSBhIGxlZnRvdmVyIGZyb20gYW4gb2xkIHZl cnNpb24gd2hlcmUgdGhlIA0KPj4+IFZOSS9WU0lEIHdhcyBlbmNvZGVkIGluIHRoZSBldGhlcm5l dCB0YWcgZm9yIGFsbCB0aGUgcm91dGVzLiBUaGUgVk5JIA0KPj4+IHNob3VsZCBiZSBlbmNvZGVk IGluIHRoZSBMYWJlbCBmaWVsZCBpbiBhbGwgdGhlIHJvdXRlcy4gVGhpcyBoYXMgdG8gYmUgY29y cmVjdGVkLg0KPj4+IA0KPj4+IEluIGZhY3QsIHNlY3Rpb24gNS4xLjMgc2F5czoNCj4+PiANCj4+ PiA1LjEuMyBDb25zdHJ1Y3RpbmcgRVZQTiBCR1AgUm91dGVzDQo+Pj4gDQo+Pj4gPHNuaXA+DQo+ Pj4gDQo+Pj4gQWNjb3JkaW5nbHksIGFuZA0KPj4+ICAgIHNwZWNpZmljYWxseSB0byBzdXBwb3J0 IHRoZSBvcHRpb24gb2YgbG9jYWxseSBhc3NpZ25lZCBWTklzLCB0aGUgTVBMUw0KPj4+ICAgIGxh YmVsIGZpZWxkIGluIHRoZSBNQUMgQWR2ZXJ0aXNlbWVudCwgRXRoZXJuZXQgQUQgcGVyIEVWSSwg YW5kDQo+Pj4gICAgSW5jbHVzaXZlIE11bHRpY2FzdCBFdGhlcm5ldCBUYWcgcm91dGVzIGlzIHVz ZWQgdG8gY2FycnkgdGhlIFZOSSBvcg0KPj4+ICAgIFZTSUQuICBGb3IgdGhlIGJhbGFuY2Ugb2Yg dGhpcyBtZW1vLCB0aGUgTVBMUyBsYWJlbCBmaWVsZCB3aWxsIGJlDQo+Pj4gICAgcmVmZXJyZWQg dG8gYXMgdGhlIFZOSS9WU0lEIGZpZWxkLiBUaGUgVk5JL1ZTSUQgZmllbGQgaXMgdXNlZCBmb3IN Cj4+PiAgICBib3RoIGxvY2FsIGFuZCBnbG9iYWwgVk5Jcy9WU0lEcywgYW5kIGZvciBlaXRoZXIg Y2FzZSB0aGUgZW50aXJlIDI0LQ0KPj4+ICAgIGJpdCBmaWVsZCBpcyB1c2VkIHRvIGVuY29kZSB0 aGUgVk5JL1ZTSUQgdmFsdWUuDQo+Pj4gDQo+Pj4gPHNuaXA+DQo+Pg0KPj4NCj4+W0pEXSAgRm9y IHRoZSBJTUVUIHJvdXRlIHRoZSBNUExTIGxhYmVsIGZpZWxkIGlzIGNhcnJpZWQgaW4gdGhlIFBN U0kgYXR0cmlidXRlLiAgSSB0aGluayB3ZSBuZWVkIHRvIGFzayBldmVyeW9uZSB3aGV0aGVyIHRo ZXkNCj4+dXNlZCB0aGUgRXRoZXJuZXQgVGFnIG9yIHRoZSBQTVNJIGF0dHJpYnV0ZSB0byBjYXJy eSB0aGUgVk5JICAgIA0KPj4NCj4+DQo+Pj4gPj4NCj4+PiA+PiBUaGVyZSBhcmUgbWlub3IgdGhp bmdzIHRoYXQgY291bGQgYmUgaW1wcm92ZWQgaW4gDQo+Pj4gPj4gZHJhZnQtaWV0Zi1iZXNzLWV2 cG4tb3ZlcmxheSB3cnQuIGNvbnNpc3RlbmN5IHdpdGggDQo+Pj4gPj4gZHJhZnQtaWV0Zi1pZHIt dHVubmVsLWVuY2FwcyA6DQo+Pj4gPj4NCj4+PiA+PiAqIHNpbmNlIGRyYWZ0LWlldGYtaWRyLXR1 bm5lbC1lbmNhcHMgd2lsbCBkZXByZWNhdGUgUkZDNTUxMiwgaXQgDQo+Pj4gPj4gd291bGQgYmUg YmV0dGVyIHRoYXQgZHJhZnQtaWV0Zi1iZXNzLWV2cG4tb3ZlcmxheSByZWZlcnMgdG8gDQo+Pj4g Pj4gZHJhZnQtaWV0Zi1pZHItdHVubmVsLWVuY2FwcyBhbmQgbm90IGFueW1vcmUgdG8gUkZDNTUx Mi4NCj4+PiANCj4+PiBbSk9SR0VdIEkgYWdyZWUsIGFzIGxvbmcgYXMgZHJhZnQtaWV0Zi1pZHIt dHVubmVsLWVuY2FwcyBrZWVwcyB0aGUgDQo+Pj4gZW5jYXBzdWxhdGlvbiBleHRlbmRlZCBjb21t dW5pdHkuIFRoZXJlIGFyZSBhIGZldyBpbXBsZW1lbnRhdGlvbnMgDQo+Pj4gdXNpbmcgdGhpcyBj b21tdW5pdHkgYW5kIGl0IGlzIGVub3VnaCB3aGVuIG9ubHkgdGhlIGVuY2Fwc3VsYXRpb24gdHlw ZSBpcyBuZWVkZWQuDQo+Pg0KPj4NCj4+W0pEXSAgIEkgYWdyZWUgYW5kIHRoZSB0dW5uZWwgZW5j YXBzIGRyYWZ0IGRvZXMga2VlcCB0aGUgRUMNCj4+DQo+Pg0KPj4+IA0KPj4+ID4+DQo+Pj4gPj4g KiBJIHRoaW5rIGl0IHdvdWxkIGJlIGJldHRlciB0byBhdm9pZCB0aGUgZXhwbGljaXQgbGlzdCBv ZiBlbmNhcCANCj4+PiA+PiB0eXBlcyBpbiBzZWN0aW9uIDUuMS4zLCBhbmQgcmF0aGVyIHJlZmVy IHRvIA0KPj4+ID4+IGRyYWZ0LWlldGYtaWRyLXR1bm5lbC1lbmNhcHMgaW5zdGVhZA0KPj4+IA0K Pj4+IFtKT1JHRV0gSSBhZ3JlZS4NCj4+DQo+Pg0KPj5bSkRdICBBY2NvcmRpbmcgdG8gSUFOQSwg aXQgYWxsb2NhdGVkIHRoZSBmaXZlIHR1bm5lbHMgdHlwZXMgdG8gdGhlIA0KPj5vdmVybGF5IGRy YWZ0IHNvIEkgdGhpbmsgd2UgbmVlZCB0byBrZWVwIHRoZW0NCj4+DQo+Pg0KPj4+IA0KPj4+ID4+ ICogdGhlIGZvbGxvd2luZyBtaW5vciBtb2RpZmljYXRpb24gd2FzIHByb3Bvc2VkLCBidXQgbm90 IHlldCBpbmNvcnBvcmF0ZWQ6DQo+Pj4gPj4NCj4+PiA+PiAgICAgSm9obiBEcmFrZSwgMjAxNS0x MS0xMyAodG8gQkVTUyBNTCk6DQo+Pj4gPj4+ICAgICBGb3IgdGhlIG92ZXJsYXkgZHJhZnQsIHJl cGxhY2UgdGhpcyB0ZXh0IGluIHNlY3Rpb24gNS4xLjM6DQo+Pj4gPj4+DQo+Pj4gPj4+ICAgICAi SWYgdGhlIEJHUCBFbmNhcHN1bGF0aW9uIGV4dGVuZGVkIGNvbW11bml0eSBpcyBub3QgcHJlc2Vu dCwgDQo+Pj4gPj4+IHRoZW4gdGhlIGRlZmF1bHQgTVBMUyBlbmNhcHN1bGF0aW9uIG9yIGEgc3Rh dGljYWxseSBjb25maWd1cmVkIA0KPj4+ID4+PiBlbmNhcHN1bGF0aW9uIGlzIGFzc3VtZWQuIg0K Pj4+ID4+Pg0KPj4+ID4+PiAgICAgV2l0aCB0aGUgZm9sbG93aW5nOg0KPj4+ID4+Pg0KPj4+ID4+ PiAgICAgIk5vdGUgdGhhdCB0aGUgTVBMUyBlbmNhcHN1bGF0aW9uIHR1bm5lbCB0eXBlIGlzIG5l ZWRlZCBpbiANCj4+PiA+Pj4gb3JkZXIgdG8gZGlzdGluZ3Vpc2ggYmV0d2VlbiBhbiBhZHZlcnRp c2luZyBub2RlIHRoYXQgb25seSANCj4+PiA+Pj4gc3VwcG9ydHMgbm9uLU1QTFMgZW5jYXBzdWxh dGlvbnMgYW5kIG9uZSB0aGF0IHN1cHBvcnRzIE1QTFMgYW5kIA0KPj4+ID4+PiBub24tTVBMUyBl bmNhcHN1bGF0aW9ucy4gIEFuICBhZHZlcnRpc2luZyBub2RlIHRoYXQgb25seSBzdXBwb3J0cyAN Cj4+PiA+Pj4gTVBMUyBlbmNhcHN1bGF0aW9uIGRvZXMgbm90IG5lZWQgdG8gYWR2ZXJ0aXNlIGFu eSBlbmNhcHN1bGF0aW9uIA0KPj4+ID4+PiB0dW5uZWwgdHlwZXM7ICBpLmUuLCAgaWYgdGhlIEJH UCBFbmNhcHN1bGF0aW9uIGV4dGVuZGVkIGNvbW11bml0eSANCj4+PiA+Pj4gaXMgbm90IHByZXNl bnQsIHRoZW4gZWl0aGVyIE1QTFMgZW5jYXBzdWxhdGlvbiBvciBhIHN0YXRpY2FsbHkgDQo+Pj4g Pj4+IGNvbmZpZ3VyZWQgZW5jYXBzdWxhdGlvbiBpcyBhc3N1bWVkLiINCj4+PiA+Pg0KPj4+ID4+ IEkgdGhpbmsgdGhpcyBjaGFuZ2UgaXMgdXNlZnVsIGFuZCBzaG91bGQgYmUgaW5jb3Jwb3JhdGVk LCBhbHRob3VnaCANCj4+PiA+PiBza2lwcGluZyB0aGUgbGFzdCBzZW50ZW5jZSB3b3VsZCBiZSB3 aXNlIGlmIHRoZSBmdWxsIGxpc3Qgb2YgDQo+Pj4gPj4gdHVubmVsIHR5cGVzIGlzIHJlbW92ZWQu DQo+Pg0KPj4NCj4+W0pEXSAgRmluZSB3aXRoIG1lIGVpdGhlciB3LyBvciB3L28gdGhlIGxhc3Qg c2VudGVuY2UNCj4+DQo+Pg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+QkVTUyBtYWlsaW5nIGxpc3QNCj5CRVNTQGlldGYub3JnDQo+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iZXNzDQo= From nobody Wed May 4 14:34:44 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F46212D88C; Wed, 4 May 2016 14:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3PU9rx1T2RY; Wed, 4 May 2016 14:34:40 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0147.outbound.protection.outlook.com [65.55.169.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60C3512D99D; Wed, 4 May 2016 14:34:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=H2kLQkG8qFDQERbvTeG5tyGxoyRWuIRYgm2rdMc5m4c=; b=jbX4o6ZWZY8GwYM2jL6hE6Ff4gcwTcLAdwgCofAuZThymIIZ09KaGh5HlMxJz8hdLJUfuw/DGBVoWqCB14Ah+vq1bEluDDWuIuitrCi0LHEaJn1d3jiq2xCoc8nedspGEEe9JtFKOlMuQxEtNRCRQigVzVCfbumA9bHsR5Ui3ZM= Received: from SN1PR0501MB1709.namprd05.prod.outlook.com (10.163.130.155) by SN1PR0501MB1711.namprd05.prod.outlook.com (10.163.130.157) with Microsoft SMTP Server (TLS) id 15.1.477.8; Wed, 4 May 2016 21:34:38 +0000 Received: from SN1PR0501MB1709.namprd05.prod.outlook.com ([10.163.130.155]) by SN1PR0501MB1709.namprd05.prod.outlook.com ([10.163.130.155]) with mapi id 15.01.0477.016; Wed, 4 May 2016 21:34:38 +0000 From: John E Drake To: "Rabadan, Jorge (Nokia - US)" , "EXT - thomas.morin@orange.com" , BESS , IDR , "draft-ietf-bess-evpn-overlay@tools.ietf.org" , "Ali Sajassi (sajassi)" Thread-Topic: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps Thread-Index: AQHRpi+6xGM0bynWeUeGN93K6stLXZ+pFtLwgAAZ14CAABtMwA== Date: Wed, 4 May 2016 21:34:38 +0000 Message-ID: References: <5729F1C3.1030605@orange.com> <5729F7C5.6040604@orange.com> <52D35106-ED5E-4C95-9131-6EA4527370D5@alcatel-lucent.com> <012C176C-A8D6-45AA-BA69-616C0ED7E41E@alcatel-lucent.com> In-Reply-To: <012C176C-A8D6-45AA-BA69-616C0ED7E41E@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nokia.com; dkim=none (message not signed) header.d=none;nokia.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.12] x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr,ExtAddr x-ms-office365-filtering-correlation-id: fca231bf-9021-4b4d-ffcc-08d37463e53b x-microsoft-exchange-diagnostics: 1; SN1PR0501MB1711; 5:K0CCwq09kKsLUC6mZQ+Qyg83Ew1J3ZhDiDtzQLzXl+uWYnpHjoR6H8E29EtBOh3KjQ0duvbTtf00B3xgU+j3Q2kbwt7jaOoPkoh5Wtgb0g/VCXFfsHbGHicx3iMUsYaJV1901S3kiRvJI1Zm9ELNLA==; 24:QoplP254YUCXSqu+9/Fy/oFghY9hfBVSCTZHMxstBTLdwMAozIhaR4Pe1xSVYDGasr5CpoYMGF25k92pJud+kKwsy2Y2w9VWonUFbLQvTlA=; 7:CtLGxvtFYaT+ZE0Jcoglj2ZoPWcnmcK6YI2yPCXpZZTOE6QRkJcquNO+C+yzB/5SnOfevIDRDfcdE4I2i1STvW1+SiCIiNx50a143R4XHUmSKNwsQbLpEmO+qy/p+uxDcZ/DWCYqQADOLwGMq1PsHEsMLJF6/Khu6ZYmykRGcWdunG90yqvbUHfl0P2AwylK x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB1711; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521098)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:SN1PR0501MB1711; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1711; x-forefront-prvs: 093290AD39 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(377424004)(24454002)(13464003)(11100500001)(5003600100002)(1220700001)(19580405001)(230783001)(19580395003)(10400500002)(5004730100002)(54356999)(9686002)(50986999)(2950100001)(86362001)(76176999)(2900100001)(33656002)(107886002)(8936002)(87936001)(77096005)(15975445007)(92566002)(74316001)(2906002)(81166005)(189998001)(122556002)(5008740100001)(99286002)(586003)(106116001)(3660700001)(93886004)(3846002)(5002640100001)(2501003)(6116002)(102836003)(5001770100001)(76576001)(3280700002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB1711; H:SN1PR0501MB1709.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2016 21:34:38.4620 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB1711 Archived-At: Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 21:34:43 -0000 Sm9yZ2UsDQoNCldlIHB1dCB0aGUgVk5JIHZhbHVlIGluIHRoZSBNUExTIGxhYmVsIGZpZWxkIG9m IHRoZSBQTVNJIGF0dHJpYnV0ZSBmb3IgYWxsIHNlcnZpY2UgdHlwZXMsIGFuZCB3ZSBwdXQgYSB2 YWx1ZSBpbiB0aGUgRXRoZXJuZXQgVGFnIGZpZWxkIGZvbGxvd2luZyB0aGUgcnVsZXMgZm9yIGVh Y2ggc2VydmljZSB0eXBlIGFzIGRlc2NyaWJlZCBpbiA1LjEuMyAoaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtYmVzcy1ldnBuLW92ZXJsYXktMDIjc2VjdGlvbi01LjEuMyku DQoNCllvdSdyZSByaWdodCB0aGF0IHdlIG5lZWQgdG8gY2xlYW4gdXAgc2VjdGlvbiA5Lg0KDQpZ b3VycyBJcnJlc3BlY3RpdmVseSwNCg0KSm9obg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IFJhYmFkYW4sIEpvcmdlIChOb2tpYSAtIFVTKSBbbWFpbHRvOmpvcmdlLnJh YmFkYW5Abm9raWEuY29tXQ0KPiBTZW50OiBXZWRuZXNkYXksIE1heSAwNCwgMjAxNiAzOjUzIFBN DQo+IFRvOiBKb2huIEUgRHJha2U7IEVYVCAtIHRob21hcy5tb3JpbkBvcmFuZ2UuY29tOyBCRVNT OyBJRFI7IGRyYWZ0LWlldGYtYmVzcy1ldnBuLQ0KPiBvdmVybGF5QHRvb2xzLmlldGYub3JnOyBB bGkgU2FqYXNzaSAoc2FqYXNzaSkNCj4gU3ViamVjdDogUmU6IFtJZHJdIGRyYWZ0LWlldGYtYmVz cy1ldnBuLW92ZXJsYXkgdnMuIGRyYWZ0LWlldGYtaWRyLXR1bm5lbC1lbmNhcHMNCj4gDQo+IEhp IEpvaG4sDQo+IA0KPiBBYm91dCB0aGlzOg0KPiANCj4gW0pEXSBGb3IgdGhlIElNRVQgcm91dGUg dGhlIE1QTFMgbGFiZWwgZmllbGQgaXMgY2FycmllZCBpbiB0aGUgUE1TSSBhdHRyaWJ1dGUuIEkg dGhpbmsgd2UgbmVlZA0KPiB0byBhc2sgZXZlcnlvbmUgd2hldGhlciB0aGV5IHVzZWQgdGhlIEV0 aGVybmV0IFRhZyBvciB0aGUgUE1TSSBhdHRyaWJ1dGUgdG8gY2FycnkgdGhlIFZOSQ0KPiANCj4g DQo+IEluIGNhc2UgaXQgaGVscHMsIEnigJl2ZSBzZWVuIGEgZmV3IGltcGxlbWVudGF0aW9ucyBy dW5uaW5nIGFuZCB0aGV5IGFsbCBlbmNvZGUgdGhlIFZOSSBpbiB0aGUNCj4gTVBMUyBsYWJlbCBm aWVsZCBpbiB0aGUgUFRBLiBBbmQgYSBjb3VwbGUgb2YgdGhlbSwgZW5jb2RlIHRoZSBWTkkgaW4g dGhlIGV0aGVybmV0LXRhZywgaW4NCj4gYWRkaXRpb24gdG8gdGhlIE1QTFMgbGFiZWwgaW4gdGhl IFBUQS4gSW4gYW55IGNhc2UsIEkgdGhpbmsgc2VjdGlvbiA5IGNvbnRyYWRpY3RzIHNlY3Rpb24g NS4xLjMNCj4gYW5kIHNob3VsZCBiZSBjbGFyaWZpZWQuDQo+IA0KPiAiNS4xLjMgQ29uc3RydWN0 aW5nIEVWUE4gQkdQIFJvdXRlcw0KPiA8c25pcD4NCj4gdGhlIE1QTFMgbGFiZWwgZmllbGQgaW4g dGhlIE1BQyBBZHZlcnRpc2VtZW50LCBFdGhlcm5ldCBBRCBwZXIgRVZJLCBhbmQgKipJbmNsdXNp dmUNCj4gTXVsdGljYXN0IEV0aGVybmV0IFRhZyoqIHJvdXRlcyBpcyB1c2VkIHRvIGNhcnJ5IHRo ZSBWTkkgb3IgVlNJRC4iDQo+IA0KPiBUaGFua3MuDQo+IEpvcmdlDQo+IA0KPiANCj4gDQo+IA0K PiANCj4gT24gNS80LzE2LCA4OjM0IFBNLCAiRVhUIEpvaG4gRSBEcmFrZSIgPGpkcmFrZUBqdW5p cGVyLm5ldD4gd3JvdGU6DQo+IA0KPiA+VGhvbWFzIGFuZCBKb3JnZSwNCj4gPg0KPiA+U25pcHBl ZCwgY29tbWVudHMgaW5saW5lLg0KPiA+DQo+ID5Zb3VycyBJcnJlc3BlY3RpdmVseSwNCj4gPg0K PiA+Sm9obg0KPiA+DQo+ID4+ID4NCj4gPj4gPmRyYWZ0LWlldGYtYmVzcy1ldnBuLW92ZXJsYXkg KHNlZSBzZWN0aW9uIDkpIHJlbGllcyBvbiB0aGUgQkdQDQo+ID4+ID5FbmNhcHN1bGF0aW9uIGV4 dGVuZGVkIHRvIGVuY29kZSB0aGUgdHVubmVsIGVuY2FwIHRvIHVzZSBmb3IgQlVNDQo+ID4+ID50 cmFmZmljLCBidXQgY29udHJhcnkgdG8gb3RoZXIgRS1WUE4gcm91dGVzLCByZWxpZXMgb24gdGhl IEV0aGVybmV0DQo+ID4+ID5UYWcgZmllbGQgb2YgdGhlIE5MUkkgdG8gZW5jb2RlIHRoZSBWTkkv VlNJRC4NCj4gPj4NCj4gPj4gW0pPUkdFXSBUaGlzIGlzIGNlcnRhaW5seSBhIGxlZnRvdmVyIGZy b20gYW4gb2xkIHZlcnNpb24gd2hlcmUgdGhlDQo+ID4+IFZOSS9WU0lEIHdhcyBlbmNvZGVkIGlu IHRoZSBldGhlcm5ldCB0YWcgZm9yIGFsbCB0aGUgcm91dGVzLiBUaGUgVk5JDQo+ID4+IHNob3Vs ZCBiZSBlbmNvZGVkIGluIHRoZSBMYWJlbCBmaWVsZCBpbiBhbGwgdGhlIHJvdXRlcy4gVGhpcyBo YXMgdG8gYmUgY29ycmVjdGVkLg0KPiA+Pg0KPiA+PiBJbiBmYWN0LCBzZWN0aW9uIDUuMS4zIHNh eXM6DQo+ID4+DQo+ID4+IDUuMS4zIENvbnN0cnVjdGluZyBFVlBOIEJHUCBSb3V0ZXMNCj4gPj4N Cj4gPj4gPHNuaXA+DQo+ID4+DQo+ID4+IEFjY29yZGluZ2x5LCBhbmQNCj4gPj4gICAgc3BlY2lm aWNhbGx5IHRvIHN1cHBvcnQgdGhlIG9wdGlvbiBvZiBsb2NhbGx5IGFzc2lnbmVkIFZOSXMsIHRo ZSBNUExTDQo+ID4+ICAgIGxhYmVsIGZpZWxkIGluIHRoZSBNQUMgQWR2ZXJ0aXNlbWVudCwgRXRo ZXJuZXQgQUQgcGVyIEVWSSwgYW5kDQo+ID4+ICAgIEluY2x1c2l2ZSBNdWx0aWNhc3QgRXRoZXJu ZXQgVGFnIHJvdXRlcyBpcyB1c2VkIHRvIGNhcnJ5IHRoZSBWTkkgb3INCj4gPj4gICAgVlNJRC4g IEZvciB0aGUgYmFsYW5jZSBvZiB0aGlzIG1lbW8sIHRoZSBNUExTIGxhYmVsIGZpZWxkIHdpbGwg YmUNCj4gPj4gICAgcmVmZXJyZWQgdG8gYXMgdGhlIFZOSS9WU0lEIGZpZWxkLiBUaGUgVk5JL1ZT SUQgZmllbGQgaXMgdXNlZCBmb3INCj4gPj4gICAgYm90aCBsb2NhbCBhbmQgZ2xvYmFsIFZOSXMv VlNJRHMsIGFuZCBmb3IgZWl0aGVyIGNhc2UgdGhlIGVudGlyZSAyNC0NCj4gPj4gICAgYml0IGZp ZWxkIGlzIHVzZWQgdG8gZW5jb2RlIHRoZSBWTkkvVlNJRCB2YWx1ZS4NCj4gPj4NCj4gPj4gPHNu aXA+DQo+ID4NCj4gPg0KPiA+W0pEXSAgRm9yIHRoZSBJTUVUIHJvdXRlIHRoZSBNUExTIGxhYmVs IGZpZWxkIGlzIGNhcnJpZWQgaW4gdGhlIFBNU0kgYXR0cmlidXRlLiAgSSB0aGluayB3ZQ0KPiBu ZWVkIHRvIGFzayBldmVyeW9uZSB3aGV0aGVyIHRoZXkNCj4gPnVzZWQgdGhlIEV0aGVybmV0IFRh ZyBvciB0aGUgUE1TSSBhdHRyaWJ1dGUgdG8gY2FycnkgdGhlIFZOSQ0KPiA+DQo+ID4NCj4gPj4g Pj4NCj4gPj4gPj4gVGhlcmUgYXJlIG1pbm9yIHRoaW5ncyB0aGF0IGNvdWxkIGJlIGltcHJvdmVk IGluDQo+ID4+ID4+IGRyYWZ0LWlldGYtYmVzcy1ldnBuLW92ZXJsYXkgd3J0LiBjb25zaXN0ZW5j eSB3aXRoDQo+ID4+ID4+IGRyYWZ0LWlldGYtaWRyLXR1bm5lbC1lbmNhcHMgOg0KPiA+PiA+Pg0K PiA+PiA+PiAqIHNpbmNlIGRyYWZ0LWlldGYtaWRyLXR1bm5lbC1lbmNhcHMgd2lsbCBkZXByZWNh dGUgUkZDNTUxMiwgaXQNCj4gPj4gPj4gd291bGQgYmUgYmV0dGVyIHRoYXQgZHJhZnQtaWV0Zi1i ZXNzLWV2cG4tb3ZlcmxheSByZWZlcnMgdG8NCj4gPj4gPj4gZHJhZnQtaWV0Zi1pZHItdHVubmVs LWVuY2FwcyBhbmQgbm90IGFueW1vcmUgdG8gUkZDNTUxMi4NCj4gPj4NCj4gPj4gW0pPUkdFXSBJ IGFncmVlLCBhcyBsb25nIGFzIGRyYWZ0LWlldGYtaWRyLXR1bm5lbC1lbmNhcHMga2VlcHMgdGhl DQo+ID4+IGVuY2Fwc3VsYXRpb24gZXh0ZW5kZWQgY29tbXVuaXR5LiBUaGVyZSBhcmUgYSBmZXcg aW1wbGVtZW50YXRpb25zDQo+ID4+IHVzaW5nIHRoaXMgY29tbXVuaXR5IGFuZCBpdCBpcyBlbm91 Z2ggd2hlbiBvbmx5IHRoZSBlbmNhcHN1bGF0aW9uIHR5cGUgaXMgbmVlZGVkLg0KPiA+DQo+ID4N Cj4gPltKRF0gICBJIGFncmVlIGFuZCB0aGUgdHVubmVsIGVuY2FwcyBkcmFmdCBkb2VzIGtlZXAg dGhlIEVDDQo+ID4NCj4gPg0KPiA+Pg0KPiA+PiA+Pg0KPiA+PiA+PiAqIEkgdGhpbmsgaXQgd291 bGQgYmUgYmV0dGVyIHRvIGF2b2lkIHRoZSBleHBsaWNpdCBsaXN0IG9mIGVuY2FwDQo+ID4+ID4+ IHR5cGVzIGluIHNlY3Rpb24gNS4xLjMsIGFuZCByYXRoZXIgcmVmZXIgdG8NCj4gPj4gPj4gZHJh ZnQtaWV0Zi1pZHItdHVubmVsLWVuY2FwcyBpbnN0ZWFkDQo+ID4+DQo+ID4+IFtKT1JHRV0gSSBh Z3JlZS4NCj4gPg0KPiA+DQo+ID5bSkRdICBBY2NvcmRpbmcgdG8gSUFOQSwgaXQgYWxsb2NhdGVk IHRoZSBmaXZlIHR1bm5lbHMgdHlwZXMgdG8gdGhlDQo+ID5vdmVybGF5IGRyYWZ0IHNvIEkgdGhp bmsgd2UgbmVlZCB0byBrZWVwIHRoZW0NCj4gPg0KPiA+DQo+ID4+DQo+ID4+ID4+ICogdGhlIGZv bGxvd2luZyBtaW5vciBtb2RpZmljYXRpb24gd2FzIHByb3Bvc2VkLCBidXQgbm90IHlldCBpbmNv cnBvcmF0ZWQ6DQo+ID4+ID4+DQo+ID4+ID4+ICAgICBKb2huIERyYWtlLCAyMDE1LTExLTEzICh0 byBCRVNTIE1MKToNCj4gPj4gPj4+ICAgICBGb3IgdGhlIG92ZXJsYXkgZHJhZnQsIHJlcGxhY2Ug dGhpcyB0ZXh0IGluIHNlY3Rpb24gNS4xLjM6DQo+ID4+ID4+Pg0KPiA+PiA+Pj4gICAgICJJZiB0 aGUgQkdQIEVuY2Fwc3VsYXRpb24gZXh0ZW5kZWQgY29tbXVuaXR5IGlzIG5vdCBwcmVzZW50LA0K PiA+PiA+Pj4gdGhlbiB0aGUgZGVmYXVsdCBNUExTIGVuY2Fwc3VsYXRpb24gb3IgYSBzdGF0aWNh bGx5IGNvbmZpZ3VyZWQNCj4gPj4gPj4+IGVuY2Fwc3VsYXRpb24gaXMgYXNzdW1lZC4iDQo+ID4+ ID4+Pg0KPiA+PiA+Pj4gICAgIFdpdGggdGhlIGZvbGxvd2luZzoNCj4gPj4gPj4+DQo+ID4+ID4+ PiAgICAgIk5vdGUgdGhhdCB0aGUgTVBMUyBlbmNhcHN1bGF0aW9uIHR1bm5lbCB0eXBlIGlzIG5l ZWRlZCBpbg0KPiA+PiA+Pj4gb3JkZXIgdG8gZGlzdGluZ3Vpc2ggYmV0d2VlbiBhbiBhZHZlcnRp c2luZyBub2RlIHRoYXQgb25seQ0KPiA+PiA+Pj4gc3VwcG9ydHMgbm9uLU1QTFMgZW5jYXBzdWxh dGlvbnMgYW5kIG9uZSB0aGF0IHN1cHBvcnRzIE1QTFMgYW5kDQo+ID4+ID4+PiBub24tTVBMUyBl bmNhcHN1bGF0aW9ucy4gIEFuICBhZHZlcnRpc2luZyBub2RlIHRoYXQgb25seSBzdXBwb3J0cw0K PiA+PiA+Pj4gTVBMUyBlbmNhcHN1bGF0aW9uIGRvZXMgbm90IG5lZWQgdG8gYWR2ZXJ0aXNlIGFu eSBlbmNhcHN1bGF0aW9uDQo+ID4+ID4+PiB0dW5uZWwgdHlwZXM7ICBpLmUuLCAgaWYgdGhlIEJH UCBFbmNhcHN1bGF0aW9uIGV4dGVuZGVkIGNvbW11bml0eQ0KPiA+PiA+Pj4gaXMgbm90IHByZXNl bnQsIHRoZW4gZWl0aGVyIE1QTFMgZW5jYXBzdWxhdGlvbiBvciBhIHN0YXRpY2FsbHkNCj4gPj4g Pj4+IGNvbmZpZ3VyZWQgZW5jYXBzdWxhdGlvbiBpcyBhc3N1bWVkLiINCj4gPj4gPj4NCj4gPj4g Pj4gSSB0aGluayB0aGlzIGNoYW5nZSBpcyB1c2VmdWwgYW5kIHNob3VsZCBiZSBpbmNvcnBvcmF0 ZWQsIGFsdGhvdWdoDQo+ID4+ID4+IHNraXBwaW5nIHRoZSBsYXN0IHNlbnRlbmNlIHdvdWxkIGJl IHdpc2UgaWYgdGhlIGZ1bGwgbGlzdCBvZg0KPiA+PiA+PiB0dW5uZWwgdHlwZXMgaXMgcmVtb3Zl ZC4NCj4gPg0KPiA+DQo+ID5bSkRdICBGaW5lIHdpdGggbWUgZWl0aGVyIHcvIG9yIHcvbyB0aGUg bGFzdCBzZW50ZW5jZQ0KPiA+DQo+ID4NCg== From nobody Wed May 4 14:39:21 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D63912D937; Wed, 4 May 2016 14:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88Q8-GQieLnQ; Wed, 4 May 2016 14:39:14 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0133.outbound.protection.outlook.com [65.55.169.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9553212D970; Wed, 4 May 2016 14:39:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Og/sapd4CsnAmHbCWIblXNNIwSpR9YPb8wXc+uiyWlA=; b=Qyb6+vn0MRROwyKmGXySgx0yMHJYkQatVyeqxnyx9PjcL+duhSXk+aN+38B/sksslHkFEdWmpWWSIkW6GT7Zt96SvmeuxPoNxmpkKeO7GbJxW1GV4aoK4SXVot/9dgO939w91kQuq3NnKE01DjEZzC6QQDu/gpnuCS4W/F5i1xk= Received: from CY1PR05MB2220.namprd05.prod.outlook.com (10.166.192.20) by BLUPR0501MB1700.namprd05.prod.outlook.com (10.163.120.158) with Microsoft SMTP Server (TLS) id 15.1.485.9; Wed, 4 May 2016 21:39:09 +0000 Received: from CY1PR05MB2220.namprd05.prod.outlook.com ([10.166.192.20]) by CY1PR05MB2220.namprd05.prod.outlook.com ([10.166.192.20]) with mapi id 15.01.0485.011; Wed, 4 May 2016 21:39:09 +0000 From: Ravi Shekhar To: "Rabadan, Jorge (Nokia - US)" , John E Drake , "EXT - thomas.morin@orange.com" , BESS , IDR , "draft-ietf-bess-evpn-overlay@tools.ietf.org" , "Ali Sajassi (sajassi)" Thread-Topic: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps Thread-Index: AQHRpi+6Yxu+7jyT7UG9wH5rbs/8yp+pGrqAgAAV74CAAA3WoIAADAYAgAAANQA= Date: Wed, 4 May 2016 21:39:09 +0000 Message-ID: References: <5729F1C3.1030605@orange.com> <5729F7C5.6040604@orange.com> <52D35106-ED5E-4C95-9131-6EA4527370D5@alcatel-lucent.com> <012C176C-A8D6-45AA-BA69-616C0ED7E41E@alcatel-lucent.com> <2F7BA699-A7F3-43DD-AE94-33ADF6866E8F@alcatel-lucent.com> In-Reply-To: <2F7BA699-A7F3-43DD-AE94-33ADF6866E8F@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nokia.com; dkim=none (message not signed) header.d=none;nokia.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.239.12] x-ms-office365-filtering-correlation-id: f63b0c10-316e-4605-785c-08d374648686 x-microsoft-exchange-diagnostics: 1; BLUPR0501MB1700; 5:RQp57rZos39b6MNmcwDwLu3Iy9iEn3kDA1lQB5ZGOxTvZCOrQympmGB1zg0BwvImqB2fuj37ysQMuCVuOHhuk/nrr4WXjsMwIeutE1TjB5XjnHuZ99qDgQAyqlVE0MBMMUEUZvDCSaqFdek5bTv5OQ==; 24:eh/sfb/BRhoZ+K87Fjl1PeKV/bGU9sBEGJX12FBb5AlP/agw6mZDQiA2VZ8N4opKNJ7PVaQF3cnVuNlYTdatzqYwx6A9gYCc/DF9RPPqX+Y=; 7:V3v4ZPxcKq/7rG1RhAxaw3F20NcFyYoEXoms7JBQjaPIS/3AFS++yu89SmyyhUKxb6OS4ebS1BQrzgtiivyQtmuxMXvbJb5csBY0piqWU7LlEJoSsIIxIhe8oNowWnNhMEY/T52JVwCfuL3UGFMqgjfIMcK1q/yDAa9OACzR/uM= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB1700; x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521098)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:BLUPR0501MB1700; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB1700; x-forefront-prvs: 093290AD39 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377424004)(13464003)(377454003)(24454002)(87936001)(33656002)(2906002)(189998001)(9686002)(81166005)(5001770100001)(86362001)(107886002)(99286002)(3660700001)(11100500001)(8936002)(122556002)(5002640100001)(106116001)(93886004)(5004730100002)(76576001)(5008740100001)(19580405001)(230783001)(2950100001)(2900100001)(50986999)(2501003)(19580395003)(3846002)(6116002)(77096005)(10400500002)(92566002)(3280700002)(102836003)(1220700001)(15975445007)(5003600100002)(76176999)(54356999)(74316001)(586003); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB1700; H:CY1PR05MB2220.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2016 21:39:09.1414 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB1700 Archived-At: Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 21:39:17 -0000 SGkgSm9yZ2UsIEFzIHBlciB0aGUgY3VycmVudCBzcGVjIHRoYXQgaXMgY29ycmVjdCAtIGl0IGlz IGJlaW5nIHVzZWQgb25seSBmb3Igdmxhbi1hd2FyZSBidW5kbGUgbW9kZWwuDQoNCkZvciB2bGFu LWJhc2VkLCBpZiBhIHN5c3RlbSBzdXBwb3J0cyBtb3JlIHRoYW4gNjRLIHZsYW5zLCBrZWVwaW5n IEV0YWcgemVybyBmb3JjZXMgaW1wbGVtZW50YXRpb24gdG8gY3JlYXRlIG5ldyBSRHMuIFRoZSBj dXJyZW50IElQIGFkZHJlc3MgYmFzZWQgUkQgc3RydWN0dXJlIG9ubHkgaGFzIDE2IGJpdHMgbGVm dCBpbiBSRCBmb3IgaWRlbnRpZnlpbmcgdmxhbnMuIElmIFJEIGhhcyB0byBiZSBhdXRvLWRlcml2 ZWQsIGl0IGFsc28gYWRkcyBleHRyYSBjb21wbGV4aXR5IGluIHRoZSBpbXBsZW1lbnRhdGlvbiB0 aGF0IGl0IGhhcyB0byBub3cgbWFuYWdlIGEgc2VwYXJhdGUgMTYgYml0IG51bWJlciBzcGFjZSAo YWNyb3NzIGdyYWNlZnVsIHJlc3RhcnQsIGFuZCBhY3Jvc3MgY29uZmlndXJlZCBSRHMpLiBJdCB3 b3VsZCBiZSBtdWNoIGVhc2llciBpZiBvbmUgY291bGQgdXNlIGNvbmZpZ3VyZWQgMjQgYml0cyBv ZiB2bmlkL3ZsYW4taWQgdG8gZG8gdGhhdC4gSWRlYWxseSwgd2Ugc2hvdWxkIGdpdmUgaXQgYSBz dHJ1Y3R1cmUgbGlrZSBhdXRvLVJUIDogMSBiaXQgZm9yIGF1dG8vbWFudWFsIGFuZCAyNCBiaXRz IGZvciB2bGFuIGlkZW50aWZpY2F0aW9uLCBhbmQgcHV0IHRob3NlIDMyIGJpdHMgdG8gZ29vZCB1 c2UgZXZlbiBmb3Igdmxhbi1iYXNlZC4NCg0KQWx0ZXJuYXRpdmUgaXMgdG8gZGVmaW5lIGEgbmV3 IHR5cGUgb2YgUkQgdGhhdCBsZWF2ZXMgMyBieXRlcyBvZiBSRCBhdmFpbGFibGUgdG8gZml0IGlu IHZsYW4gaWRlbnRpZmljYXRpb24uIFRoZSBjdXJyZW50IHR5cGVzIG9mIFJEIGFyZSBvbmx5IGEg aGFuZGZ1bCwgYnV0IHRoZSB0eXBlIGZpZWxkIHRha2VzIGEgZnVsbCAyIGJ5dGUgc3BhY2UuIFdl IGNhbiBwb3NzaWJseSBmcmVlIHVwIGEgYnl0ZSBmcm9tIHRoYXQgc3BhY2UuIFNpbmNlIHRoZSBw cm9ibGVtIGlzIHZlcnkgc3BlY2lmaWMgdG8gRVZQTiwgSSBhbSBub3Qgc3VyZSBpZiBpdCBpcyBw cnVkZW50IHRvIGRvIHRoYXQuIFVzaW5nIDMyIGJpdHMgb2YgRXRoZXJuZXQgdGFnIGluIEVWUE4g cm91dGVzIHNvdW5kcyBtb3JlIGFwcHJvcHJpYXRlIGZvciB0aGlzIHB1cnBvc2UuDQoNClRoYW5r cy4NCi0gUmF2aS4NCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBSYWJh ZGFuLCBKb3JnZSAoTm9raWEgLSBVUykgW21haWx0bzpqb3JnZS5yYWJhZGFuQG5va2lhLmNvbV0g DQpTZW50OiBXZWRuZXNkYXksIE1heSAwNCwgMjAxNiAyOjI1IFBNDQpUbzogUmF2aSBTaGVraGFy IDxyc2hla2hhckBqdW5pcGVyLm5ldD47IEpvaG4gRSBEcmFrZSA8amRyYWtlQGp1bmlwZXIubmV0 PjsgRVhUIC0gdGhvbWFzLm1vcmluQG9yYW5nZS5jb20gPHRob21hcy5tb3JpbkBvcmFuZ2UuY29t PjsgQkVTUyA8YmVzc0BpZXRmLm9yZz47IElEUiA8aWRyQGlldGYub3JnPjsgZHJhZnQtaWV0Zi1i ZXNzLWV2cG4tb3ZlcmxheUB0b29scy5pZXRmLm9yZzsgQWxpIFNhamFzc2kgKHNhamFzc2kpIDxz YWphc3NpQGNpc2NvLmNvbT4NClN1YmplY3Q6IFJlOiBbSWRyXSBkcmFmdC1pZXRmLWJlc3MtZXZw bi1vdmVybGF5IHZzLiBkcmFmdC1pZXRmLWlkci10dW5uZWwtZW5jYXBzDQoNCkhpIFJhdmksDQoN Ck9mIGNvdXJzZSwgaW4gY2FzZSBvZiB2bGFuLWF3YXJlIGJ1bmRsZSBzZXJ2aWNlcy4gQnV0IHNo b3VsZCBiZSB6ZXJvIGluIGNhc2Ugb2YgVkxBTi1iYXNlZCBvciBWTEFOLWJ1bmRsZS4NClRoeA0K Sm9yZ2UgDQoNCg0KDQoNCk9uIDUvNC8xNiwgMTA6NDUgUE0sICJFWFQgUmF2aSBTaGVraGFyIiA8 cnNoZWtoYXJAanVuaXBlci5uZXQ+IHdyb3RlOg0KDQo+SGkgSm9yZ2UsDQo+VGhlIFZOSSBmaWVs ZCBpbiBFdGhlcm5ldCBUYWcgaGFzIGJlZW4gdXNlZCB0byBkaWZmZXJlbnRpYXRlIHR3byBCR1Ag cm91dGVzIHRoYXQgaGF2ZSBzYW1lIE1BQyBidXQgZGlmZmVyZW50IFZOSS9WTEFOLUlELiBJZGVh bGx5LCBpdCBzaG91bGQgbm90IGJlIHVzZWQgZm9yIG5leHRob3AgY3JlYXRpb24uIE1heSBiZSB3 ZSBjYW4gYWRkIHRoYXQgY2xhcmlmaWNhdGlvbi4NCj5UaGFua3MuDQo+LSBSYXZpLg0KPg0KPg0K Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogQkVTUyBbbWFpbHRvOmJlc3MtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJhYmFkYW4sIEpvcmdlIA0KPihOb2tpYSAtIFVT KQ0KPlNlbnQ6IFdlZG5lc2RheSwgTWF5IDA0LCAyMDE2IDEyOjUzIFBNDQo+VG86IEpvaG4gRSBE cmFrZSA8amRyYWtlQGp1bmlwZXIubmV0PjsgRVhUIC0gdGhvbWFzLm1vcmluQG9yYW5nZS5jb20g DQo+PHRob21hcy5tb3JpbkBvcmFuZ2UuY29tPjsgQkVTUyA8YmVzc0BpZXRmLm9yZz47IElEUiA8 aWRyQGlldGYub3JnPjsgDQo+ZHJhZnQtaWV0Zi1iZXNzLWV2cG4tb3ZlcmxheUB0b29scy5pZXRm Lm9yZzsgQWxpIFNhamFzc2kgKHNhamFzc2kpIA0KPjxzYWphc3NpQGNpc2NvLmNvbT4NCj5TdWJq ZWN0OiBSZTogW2Jlc3NdIFtJZHJdIGRyYWZ0LWlldGYtYmVzcy1ldnBuLW92ZXJsYXkgdnMuIA0K PmRyYWZ0LWlldGYtaWRyLXR1bm5lbC1lbmNhcHMNCj4NCj5IaSBKb2huLA0KPg0KPkFib3V0IHRo aXM6DQo+DQo+W0pEXSBGb3IgdGhlIElNRVQgcm91dGUgdGhlIE1QTFMgbGFiZWwgZmllbGQgaXMg Y2FycmllZCBpbiB0aGUgUE1TSSANCj5hdHRyaWJ1dGUuIEkgdGhpbmsgd2UgbmVlZCB0byBhc2sg ZXZlcnlvbmUgd2hldGhlciB0aGV5IHVzZWQgdGhlIA0KPkV0aGVybmV0IFRhZyBvciB0aGUgUE1T SSBhdHRyaWJ1dGUgdG8gY2FycnkgdGhlIFZOSQ0KPg0KPg0KPkluIGNhc2UgaXQgaGVscHMsIEni gJl2ZSBzZWVuIGEgZmV3IGltcGxlbWVudGF0aW9ucyBydW5uaW5nIGFuZCB0aGV5IGFsbCBlbmNv ZGUgdGhlIFZOSSBpbiB0aGUgTVBMUyBsYWJlbCBmaWVsZCBpbiB0aGUgUFRBLiBBbmQgYSBjb3Vw bGUgb2YgdGhlbSwgZW5jb2RlIHRoZSBWTkkgaW4gdGhlIGV0aGVybmV0LXRhZywgaW4gYWRkaXRp b24gdG8gdGhlIE1QTFMgbGFiZWwgaW4gdGhlIFBUQS4gSW4gYW55IGNhc2UsIEkgdGhpbmsgc2Vj dGlvbiA5IGNvbnRyYWRpY3RzIHNlY3Rpb24gNS4xLjMgYW5kIHNob3VsZCBiZSBjbGFyaWZpZWQu DQo+DQo+IjUuMS4zIENvbnN0cnVjdGluZyBFVlBOIEJHUCBSb3V0ZXMNCj48c25pcD4NCj50aGUg TVBMUyBsYWJlbCBmaWVsZCBpbiB0aGUgTUFDIEFkdmVydGlzZW1lbnQsIEV0aGVybmV0IEFEIHBl ciBFVkksIGFuZCAqKkluY2x1c2l2ZSBNdWx0aWNhc3QgRXRoZXJuZXQgVGFnKiogcm91dGVzIGlz IHVzZWQgdG8gY2FycnkgdGhlIFZOSSBvciBWU0lELiIgDQo+DQo+VGhhbmtzLg0KPkpvcmdlDQo+ DQo+DQo+DQo+DQo+DQo+T24gNS80LzE2LCA4OjM0IFBNLCAiRVhUIEpvaG4gRSBEcmFrZSIgPGpk cmFrZUBqdW5pcGVyLm5ldD4gd3JvdGU6DQo+DQo+PlRob21hcyBhbmQgSm9yZ2UsDQo+Pg0KPj5T bmlwcGVkLCBjb21tZW50cyBpbmxpbmUuDQo+Pg0KPj5Zb3VycyBJcnJlc3BlY3RpdmVseSwNCj4+ DQo+PkpvaG4NCj4+DQo+Pj4gPg0KPj4+ID5kcmFmdC1pZXRmLWJlc3MtZXZwbi1vdmVybGF5IChz ZWUgc2VjdGlvbiA5KSByZWxpZXMgb24gdGhlIEJHUCANCj4+PiA+RW5jYXBzdWxhdGlvbiBleHRl bmRlZCB0byBlbmNvZGUgdGhlIHR1bm5lbCBlbmNhcCB0byB1c2UgZm9yIEJVTSANCj4+PiA+dHJh ZmZpYywgYnV0IGNvbnRyYXJ5IHRvIG90aGVyIEUtVlBOIHJvdXRlcywgcmVsaWVzIG9uIHRoZSBF dGhlcm5ldCANCj4+PiA+VGFnIGZpZWxkIG9mIHRoZSBOTFJJIHRvIGVuY29kZSB0aGUgVk5JL1ZT SUQuDQo+Pj4gDQo+Pj4gW0pPUkdFXSBUaGlzIGlzIGNlcnRhaW5seSBhIGxlZnRvdmVyIGZyb20g YW4gb2xkIHZlcnNpb24gd2hlcmUgdGhlIA0KPj4+IFZOSS9WU0lEIHdhcyBlbmNvZGVkIGluIHRo ZSBldGhlcm5ldCB0YWcgZm9yIGFsbCB0aGUgcm91dGVzLiBUaGUgVk5JIA0KPj4+IHNob3VsZCBi ZSBlbmNvZGVkIGluIHRoZSBMYWJlbCBmaWVsZCBpbiBhbGwgdGhlIHJvdXRlcy4gVGhpcyBoYXMg dG8gYmUgY29ycmVjdGVkLg0KPj4+IA0KPj4+IEluIGZhY3QsIHNlY3Rpb24gNS4xLjMgc2F5czoN Cj4+PiANCj4+PiA1LjEuMyBDb25zdHJ1Y3RpbmcgRVZQTiBCR1AgUm91dGVzDQo+Pj4gDQo+Pj4g PHNuaXA+DQo+Pj4gDQo+Pj4gQWNjb3JkaW5nbHksIGFuZA0KPj4+ICAgIHNwZWNpZmljYWxseSB0 byBzdXBwb3J0IHRoZSBvcHRpb24gb2YgbG9jYWxseSBhc3NpZ25lZCBWTklzLCB0aGUgTVBMUw0K Pj4+ICAgIGxhYmVsIGZpZWxkIGluIHRoZSBNQUMgQWR2ZXJ0aXNlbWVudCwgRXRoZXJuZXQgQUQg cGVyIEVWSSwgYW5kDQo+Pj4gICAgSW5jbHVzaXZlIE11bHRpY2FzdCBFdGhlcm5ldCBUYWcgcm91 dGVzIGlzIHVzZWQgdG8gY2FycnkgdGhlIFZOSSBvcg0KPj4+ICAgIFZTSUQuICBGb3IgdGhlIGJh bGFuY2Ugb2YgdGhpcyBtZW1vLCB0aGUgTVBMUyBsYWJlbCBmaWVsZCB3aWxsIGJlDQo+Pj4gICAg cmVmZXJyZWQgdG8gYXMgdGhlIFZOSS9WU0lEIGZpZWxkLiBUaGUgVk5JL1ZTSUQgZmllbGQgaXMg dXNlZCBmb3INCj4+PiAgICBib3RoIGxvY2FsIGFuZCBnbG9iYWwgVk5Jcy9WU0lEcywgYW5kIGZv ciBlaXRoZXIgY2FzZSB0aGUgZW50aXJlIDI0LQ0KPj4+ICAgIGJpdCBmaWVsZCBpcyB1c2VkIHRv IGVuY29kZSB0aGUgVk5JL1ZTSUQgdmFsdWUuDQo+Pj4gDQo+Pj4gPHNuaXA+DQo+Pg0KPj4NCj4+ W0pEXSAgRm9yIHRoZSBJTUVUIHJvdXRlIHRoZSBNUExTIGxhYmVsIGZpZWxkIGlzIGNhcnJpZWQg aW4gdGhlIFBNU0kgYXR0cmlidXRlLiAgSSB0aGluayB3ZSBuZWVkIHRvIGFzayBldmVyeW9uZSB3 aGV0aGVyIHRoZXkNCj4+dXNlZCB0aGUgRXRoZXJuZXQgVGFnIG9yIHRoZSBQTVNJIGF0dHJpYnV0 ZSB0byBjYXJyeSB0aGUgVk5JICAgIA0KPj4NCj4+DQo+Pj4gPj4NCj4+PiA+PiBUaGVyZSBhcmUg bWlub3IgdGhpbmdzIHRoYXQgY291bGQgYmUgaW1wcm92ZWQgaW4gDQo+Pj4gPj4gZHJhZnQtaWV0 Zi1iZXNzLWV2cG4tb3ZlcmxheSB3cnQuIGNvbnNpc3RlbmN5IHdpdGggDQo+Pj4gPj4gZHJhZnQt aWV0Zi1pZHItdHVubmVsLWVuY2FwcyA6DQo+Pj4gPj4NCj4+PiA+PiAqIHNpbmNlIGRyYWZ0LWll dGYtaWRyLXR1bm5lbC1lbmNhcHMgd2lsbCBkZXByZWNhdGUgUkZDNTUxMiwgaXQgDQo+Pj4gPj4g d291bGQgYmUgYmV0dGVyIHRoYXQgZHJhZnQtaWV0Zi1iZXNzLWV2cG4tb3ZlcmxheSByZWZlcnMg dG8gDQo+Pj4gPj4gZHJhZnQtaWV0Zi1pZHItdHVubmVsLWVuY2FwcyBhbmQgbm90IGFueW1vcmUg dG8gUkZDNTUxMi4NCj4+PiANCj4+PiBbSk9SR0VdIEkgYWdyZWUsIGFzIGxvbmcgYXMgZHJhZnQt aWV0Zi1pZHItdHVubmVsLWVuY2FwcyBrZWVwcyB0aGUgDQo+Pj4gZW5jYXBzdWxhdGlvbiBleHRl bmRlZCBjb21tdW5pdHkuIFRoZXJlIGFyZSBhIGZldyBpbXBsZW1lbnRhdGlvbnMgDQo+Pj4gdXNp bmcgdGhpcyBjb21tdW5pdHkgYW5kIGl0IGlzIGVub3VnaCB3aGVuIG9ubHkgdGhlIGVuY2Fwc3Vs YXRpb24gdHlwZSBpcyBuZWVkZWQuDQo+Pg0KPj4NCj4+W0pEXSAgIEkgYWdyZWUgYW5kIHRoZSB0 dW5uZWwgZW5jYXBzIGRyYWZ0IGRvZXMga2VlcCB0aGUgRUMNCj4+DQo+Pg0KPj4+IA0KPj4+ID4+ DQo+Pj4gPj4gKiBJIHRoaW5rIGl0IHdvdWxkIGJlIGJldHRlciB0byBhdm9pZCB0aGUgZXhwbGlj aXQgbGlzdCBvZiBlbmNhcCANCj4+PiA+PiB0eXBlcyBpbiBzZWN0aW9uIDUuMS4zLCBhbmQgcmF0 aGVyIHJlZmVyIHRvIA0KPj4+ID4+IGRyYWZ0LWlldGYtaWRyLXR1bm5lbC1lbmNhcHMgaW5zdGVh ZA0KPj4+IA0KPj4+IFtKT1JHRV0gSSBhZ3JlZS4NCj4+DQo+Pg0KPj5bSkRdICBBY2NvcmRpbmcg dG8gSUFOQSwgaXQgYWxsb2NhdGVkIHRoZSBmaXZlIHR1bm5lbHMgdHlwZXMgdG8gdGhlIA0KPj5v dmVybGF5IGRyYWZ0IHNvIEkgdGhpbmsgd2UgbmVlZCB0byBrZWVwIHRoZW0NCj4+DQo+Pg0KPj4+ IA0KPj4+ID4+ICogdGhlIGZvbGxvd2luZyBtaW5vciBtb2RpZmljYXRpb24gd2FzIHByb3Bvc2Vk LCBidXQgbm90IHlldCBpbmNvcnBvcmF0ZWQ6DQo+Pj4gPj4NCj4+PiA+PiAgICAgSm9obiBEcmFr ZSwgMjAxNS0xMS0xMyAodG8gQkVTUyBNTCk6DQo+Pj4gPj4+ICAgICBGb3IgdGhlIG92ZXJsYXkg ZHJhZnQsIHJlcGxhY2UgdGhpcyB0ZXh0IGluIHNlY3Rpb24gNS4xLjM6DQo+Pj4gPj4+DQo+Pj4g Pj4+ICAgICAiSWYgdGhlIEJHUCBFbmNhcHN1bGF0aW9uIGV4dGVuZGVkIGNvbW11bml0eSBpcyBu b3QgcHJlc2VudCwgDQo+Pj4gPj4+IHRoZW4gdGhlIGRlZmF1bHQgTVBMUyBlbmNhcHN1bGF0aW9u IG9yIGEgc3RhdGljYWxseSBjb25maWd1cmVkIA0KPj4+ID4+PiBlbmNhcHN1bGF0aW9uIGlzIGFz c3VtZWQuIg0KPj4+ID4+Pg0KPj4+ID4+PiAgICAgV2l0aCB0aGUgZm9sbG93aW5nOg0KPj4+ID4+ Pg0KPj4+ID4+PiAgICAgIk5vdGUgdGhhdCB0aGUgTVBMUyBlbmNhcHN1bGF0aW9uIHR1bm5lbCB0 eXBlIGlzIG5lZWRlZCBpbiANCj4+PiA+Pj4gb3JkZXIgdG8gZGlzdGluZ3Vpc2ggYmV0d2VlbiBh biBhZHZlcnRpc2luZyBub2RlIHRoYXQgb25seSANCj4+PiA+Pj4gc3VwcG9ydHMgbm9uLU1QTFMg ZW5jYXBzdWxhdGlvbnMgYW5kIG9uZSB0aGF0IHN1cHBvcnRzIE1QTFMgYW5kIA0KPj4+ID4+PiBu b24tTVBMUyBlbmNhcHN1bGF0aW9ucy4gIEFuICBhZHZlcnRpc2luZyBub2RlIHRoYXQgb25seSAN Cj4+PiA+Pj4gc3VwcG9ydHMgTVBMUyBlbmNhcHN1bGF0aW9uIGRvZXMgbm90IG5lZWQgdG8gYWR2 ZXJ0aXNlIGFueSANCj4+PiA+Pj4gZW5jYXBzdWxhdGlvbiB0dW5uZWwgdHlwZXM7ICBpLmUuLCAg aWYgdGhlIEJHUCBFbmNhcHN1bGF0aW9uIA0KPj4+ID4+PiBleHRlbmRlZCBjb21tdW5pdHkgaXMg bm90IHByZXNlbnQsIHRoZW4gZWl0aGVyIE1QTFMgDQo+Pj4gPj4+IGVuY2Fwc3VsYXRpb24gb3Ig YSBzdGF0aWNhbGx5IGNvbmZpZ3VyZWQgZW5jYXBzdWxhdGlvbiBpcyBhc3N1bWVkLiINCj4+PiA+ Pg0KPj4+ID4+IEkgdGhpbmsgdGhpcyBjaGFuZ2UgaXMgdXNlZnVsIGFuZCBzaG91bGQgYmUgaW5j b3Jwb3JhdGVkLCANCj4+PiA+PiBhbHRob3VnaCBza2lwcGluZyB0aGUgbGFzdCBzZW50ZW5jZSB3 b3VsZCBiZSB3aXNlIGlmIHRoZSBmdWxsIA0KPj4+ID4+IGxpc3Qgb2YgdHVubmVsIHR5cGVzIGlz IHJlbW92ZWQuDQo+Pg0KPj4NCj4+W0pEXSAgRmluZSB3aXRoIG1lIGVpdGhlciB3LyBvciB3L28g dGhlIGxhc3Qgc2VudGVuY2UNCj4+DQo+Pg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+QkVTUyBtYWlsaW5nIGxpc3QNCj5CRVNTQGlldGYub3JnDQo+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iZXNzDQo= From nobody Wed May 4 14:50:36 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F96C12D8AF; Wed, 4 May 2016 14:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7mCcEqLYiBb; Wed, 4 May 2016 14:50:31 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEC5B12D8E0; Wed, 4 May 2016 14:41:22 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id ADEBE71DC7D1B; Wed, 4 May 2016 21:41:16 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u44LfK1G028675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 May 2016 21:41:20 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u44LfK8X029133 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 May 2016 23:41:20 +0200 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.187]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Wed, 4 May 2016 23:41:20 +0200 From: "Rabadan, Jorge (Nokia - US)" To: EXT John E Drake , IDR , BESS , "draft-ietf-bess-evpn-overlay@tools.ietf.org" , "Ali Sajassi (sajassi)" , "EXT - thomas.morin@orange.com" Thread-Topic: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps Thread-Index: AQHRpi+kmvQEkxjTwkqTS+eCL8sT/p+o+TOAgAA3cgD///r5AIAAI2bY Date: Wed, 4 May 2016 21:41:19 +0000 Message-ID: <420BA2D8D80A6727.2B2C290F-2299-40BB-B53B-CC36D2B5D826@mail.outlook.com> References: <5729F1C3.1030605@orange.com> <5729F7C5.6040604@orange.com> <52D35106-ED5E-4C95-9131-6EA4527370D5@alcatel-lucent.com> <012C176C-A8D6-45AA-BA69-616C0ED7E41E@alcatel-lucent.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_420BA2D8D80A67272B2C290F229940BBB53BCC36D2B5D826mailout_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 21:50:34 -0000 --_000_420BA2D8D80A67272B2C290F229940BBB53BCC36D2B5D826mailout_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Fully agree John. That's what I meant, sorry if I didn't make myself clear.= Section 9 needs clean up, yes. Thanks, Jorge _____________________________ From: EXT John E Drake > Sent: Wednesday, May 4, 2016 23:34 Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-e= ncaps To: IDR >, Ali Sajassi (sajassi) >, Rabadan, Jorge (Nokia - US) >, BESS <= bess@ietf.org>, >, EXT - thomas.= morin@orange.com > Jorge, We put the VNI value in the MPLS label field of the PMSI attribute for all = service types, and we put a value in the Ethernet Tag field following the r= ules for each service type as described in 5.1.3 (https://tools.ietf.org/ht= ml/draft-ietf-bess-evpn-overlay-02#section-5.1.3). You're right that we need to clean up section 9. Yours Irrespectively, John > -----Original Message----- > From: Rabadan, Jorge (Nokia - US) [mailto:jorge.rabadan@nokia.com] > Sent: Wednesday, May 04, 2016 3:53 PM > To: John E Drake; EXT - thomas.morin@orange.com; BESS; IDR; draft-ietf-bess-evpn- > overlay@tools.ietf.org; Ali Sajassi (sajas= si) > Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel= -encaps > > Hi John, > > About this: > > [JD] For the IMET route the MPLS label field is carried in the PMSI attri= bute. I think we need > to ask everyone whether they used the Ethernet Tag or the PMSI attribute = to carry the VNI > > > In case it helps, I=92ve seen a few implementations running and they all = encode the VNI in the > MPLS label field in the PTA. And a couple of them, encode the VNI in the = ethernet-tag, in > addition to the MPLS label in the PTA. In any case, I think section 9 con= tradicts section 5.1.3 > and should be clarified. > > "5.1.3 Constructing EVPN BGP Routes > > the MPLS label field in the MAC Advertisement, Ethernet AD per EVI, and *= *Inclusive > Multicast Ethernet Tag** routes is used to carry the VNI or VSID." > > Thanks. > Jorge > > > > > > On 5/4/16, 8:34 PM, "EXT John E Drake" > wrote: > > >Thomas and Jorge, > > > >Snipped, comments inline. > > > >Yours Irrespectively, > > > >John > > > >> > > >> >draft-ietf-bess-evpn-overlay (see section 9) relies on the BGP > >> >Encapsulation extended to encode the tunnel encap to use for BUM > >> >traffic, but contrary to other E-VPN routes, relies on the Ethernet > >> >Tag field of the NLRI to encode the VNI/VSID. > >> > >> [JORGE] This is certainly a leftover from an old version where the > >> VNI/VSID was encoded in the ethernet tag for all the routes. The VNI > >> should be encoded in the Label field in all the routes. This has to be= corrected. > >> > >> In fact, section 5.1.3 says: > >> > >> 5.1.3 Constructing EVPN BGP Routes > >> > >> > >> > >> Accordingly, and > >> specifically to support the option of locally assigned VNIs, the MPLS > >> label field in the MAC Advertisement, Ethernet AD per EVI, and > >> Inclusive Multicast Ethernet Tag routes is used to carry the VNI or > >> VSID. For the balance of this memo, the MPLS label field will be > >> referred to as the VNI/VSID field. The VNI/VSID field is used for > >> both local and global VNIs/VSIDs, and for either case the entire 24- > >> bit field is used to encode the VNI/VSID value. > >> > >> > > > > > >[JD] For the IMET route the MPLS label field is carried in the PMSI attr= ibute. I think we > need to ask everyone whether they > >used the Ethernet Tag or the PMSI attribute to carry the VNI > > > > > >> >> > >> >> There are minor things that could be improved in > >> >> draft-ietf-bess-evpn-overlay wrt. consistency with > >> >> draft-ietf-idr-tunnel-encaps : > >> >> > >> >> * since draft-ietf-idr-tunnel-encaps will deprecate RFC5512, it > >> >> would be better that draft-ietf-bess-evpn-overlay refers to > >> >> draft-ietf-idr-tunnel-encaps and not anymore to RFC5512. > >> > >> [JORGE] I agree, as long as draft-ietf-idr-tunnel-encaps keeps the > >> encapsulation extended community. There are a few implementations > >> using this community and it is enough when only the encapsulation type= is needed. > > > > > >[JD] I agree and the tunnel encaps draft does keep the EC > > > > > >> > >> >> > >> >> * I think it would be better to avoid the explicit list of encap > >> >> types in section 5.1.3, and rather refer to > >> >> draft-ietf-idr-tunnel-encaps instead > >> > >> [JORGE] I agree. > > > > > >[JD] According to IANA, it allocated the five tunnels types to the > >overlay draft so I think we need to keep them > > > > > >> > >> >> * the following minor modification was proposed, but not yet incorp= orated: > >> >> > >> >> John Drake, 2015-11-13 (to BESS ML): > >> >>> For the overlay draft, replace this text in section 5.1.3: > >> >>> > >> >>> "If the BGP Encapsulation extended community is not present, > >> >>> then the default MPLS encapsulation or a statically configured > >> >>> encapsulation is assumed." > >> >>> > >> >>> With the following: > >> >>> > >> >>> "Note that the MPLS encapsulation tunnel type is needed in > >> >>> order to distinguish between an advertising node that only > >> >>> supports non-MPLS encapsulations and one that supports MPLS and > >> >>> non-MPLS encapsulations. An advertising node that only supports > >> >>> MPLS encapsulation does not need to advertise any encapsulation > >> >>> tunnel types; i.e., if the BGP Encapsulation extended community > >> >>> is not present, then either MPLS encapsulation or a statically > >> >>> configured encapsulation is assumed." > >> >> > >> >> I think this change is useful and should be incorporated, although > >> >> skipping the last sentence would be wise if the full list of > >> >> tunnel types is removed. > > > > > >[JD] Fine with me either w/ or w/o the last sentence > > > > --_000_420BA2D8D80A67272B2C290F229940BBB53BCC36D2B5D826mailout_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Fully agree John. That's what I meant, sorry if I didn't make myself c= lear. Section 9 needs clean up, yes.

Thanks,
Jorge

_____________________________
From: EXT John E Drake <jdrake@juniper.net>
Sent: Wednesday, May 4, 2016 23:34
Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-e= ncaps
To: IDR <idr@ietf.org>, Ali Sajassi (sajassi) <sajassi@cisc= o.com>, Rabadan, Jorge (Nokia - US) <jorge.rabadan@alcatel-l= ucent.com>, BESS <bess@ietf.org>, <draft-ietf-bess-evpn-overlay@tools.ietf.= org>, EXT - thomas.morin@orange.com <thomas.morin@orange.com>

Jorge,

We put the VNI value in the MPLS label field of the PMSI attribute for all = service types, and we put a value in the Ethernet Tag field following the r= ules for each service type as described in 5.1.3 (https://tools.ietf.org/html/draft-ietf-bess-ev= pn-overlay-02#section-5.1.3).

You're right that we need to clean up section 9.

Yours Irrespectively,

John

> -----Original Message-----
> From: Rabadan, Jorge (Nokia - US) [mailto:jorge.rabadan@nok= ia.com]
> Sent: Wednesday, May 04, 2016 3:53 PM
> To: John E Drake; EXT - thomas.morin@orange.com; BESS; IDR; draft-ietf-bess-evpn-
> overlay@tools.ietf.org; Ali Sajassi (sajassi)
> Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tun= nel-encaps
>
> Hi John,
>
> About this:
>
> [JD] For the IMET route the MPLS label field is carried in the PMSI at= tribute. I think we need
> to ask everyone whether they used the Ethernet Tag or the PMSI attribu= te to carry the VNI
>
>
> In case it helps, I=92ve seen a few implementations running and they a= ll encode the VNI in the
> MPLS label field in the PTA. And a couple of them, encode the VNI in t= he ethernet-tag, in
> addition to the MPLS label in the PTA. In any case, I think section 9 = contradicts section 5.1.3
> and should be clarified.
>
> "5.1.3 Constructing EVPN BGP Routes
> <snip>
> the MPLS label field in the MAC Advertisement, Ethernet AD per EVI, an= d **Inclusive
> Multicast Ethernet Tag** routes is used to carry the VNI or VSID."= ;
>
> Thanks.
> Jorge
>
>
>
>
>
> On 5/4/16, 8:34 PM, "EXT John E Drake" <jdrake@juni= per.net> wrote:
>
> >Thomas and Jorge,
> >
> >Snipped, comments inline.
> >
> >Yours Irrespectively,
> >
> >John
> >
> >> >
> >> >draft-ietf-bess-evpn-overlay (see section 9) relies on th= e BGP
> >> >Encapsulation extended to encode the tunnel encap to use = for BUM
> >> >traffic, but contrary to other E-VPN routes, relies on th= e Ethernet
> >> >Tag field of the NLRI to encode the VNI/VSID.
> >>
> >> [JORGE] This is certainly a leftover from an old version wher= e the
> >> VNI/VSID was encoded in the ethernet tag for all the routes. = The VNI
> >> should be encoded in the Label field in all the routes. This = has to be corrected.
> >>
> >> In fact, section 5.1.3 says:
> >>
> >> 5.1.3 Constructing EVPN BGP Routes
> >>
> >> <snip>
> >>
> >> Accordingly, and
> >> specifically to support the option of locally assigned VNIs, = the MPLS
> >> label field in the MAC Advertisement, Ethernet AD per EVI, an= d
> >> Inclusive Multicast Ethernet Tag routes is used to carry the = VNI or
> >> VSID. For the balance of this memo, the MPLS label field will= be
> >> referred to as the VNI/VSID field. The VNI/VSID field is used= for
> >> both local and global VNIs/VSIDs, and for either case the ent= ire 24-
> >> bit field is used to encode the VNI/VSID value.
> >>
> >> <snip>
> >
> >
> >[JD] For the IMET route the MPLS label field is carried in the PMS= I attribute. I think we
> need to ask everyone whether they
> >used the Ethernet Tag or the PMSI attribute to carry the VNI
> >
> >
> >> >>
> >> >> There are minor things that could be improved in
> >> >> draft-ietf-bess-evpn-overlay wrt. consistency with > >> >> draft-ietf-idr-tunnel-encaps :
> >> >>
> >> >> * since draft-ietf-idr-tunnel-encaps will deprecate = RFC5512, it
> >> >> would be better that draft-ietf-bess-evpn-overlay re= fers to
> >> >> draft-ietf-idr-tunnel-encaps and not anymore to RFC5= 512.
> >>
> >> [JORGE] I agree, as long as draft-ietf-idr-tunnel-encaps keep= s the
> >> encapsulation extended community. There are a few implementat= ions
> >> using this community and it is enough when only the encapsula= tion type is needed.
> >
> >
> >[JD] I agree and the tunnel encaps draft does keep the EC
> >
> >
> >>
> >> >>
> >> >> * I think it would be better to avoid the explicit l= ist of encap
> >> >> types in section 5.1.3, and rather refer to
> >> >> draft-ietf-idr-tunnel-encaps instead
> >>
> >> [JORGE] I agree.
> >
> >
> >[JD] According to IANA, it allocated the five tunnels types to the=
> >overlay draft so I think we need to keep them
> >
> >
> >>
> >> >> * the following minor modification was proposed, but= not yet incorporated:
> >> >>
> >> >> John Drake, 2015-11-13 (to BESS ML):
> >> >>> For the overlay draft, replace this text in sect= ion 5.1.3:
> >> >>>
> >> >>> "If the BGP Encapsulation extended communit= y is not present,
> >> >>> then the default MPLS encapsulation or a statica= lly configured
> >> >>> encapsulation is assumed."
> >> >>>
> >> >>> With the following:
> >> >>>
> >> >>> "Note that the MPLS encapsulation tunnel ty= pe is needed in
> >> >>> order to distinguish between an advertising node= that only
> >> >>> supports non-MPLS encapsulations and one that su= pports MPLS and
> >> >>> non-MPLS encapsulations. An advertising node tha= t only supports
> >> >>> MPLS encapsulation does not need to advertise an= y encapsulation
> >> >>> tunnel types; i.e., if the BGP Encapsulation ext= ended community
> >> >>> is not present, then either MPLS encapsulation o= r a statically
> >> >>> configured encapsulation is assumed."
> >> >>
> >> >> I think this change is useful and should be incorpor= ated, although
> >> >> skipping the last sentence would be wise if the full= list of
> >> >> tunnel types is removed.
> >
> >
> >[JD] Fine with me either w/ or w/o the last sentence
> >
> >


--_000_420BA2D8D80A67272B2C290F229940BBB53BCC36D2B5D826mailout_-- From nobody Thu May 5 02:55:59 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DB42212B00A; Thu, 5 May 2016 02:55:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Jari Arkko" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160505095556.15385.64588.idtracker@ietfa.amsl.com> Date: Thu, 05 May 2016 02:55:56 -0700 Archived-At: Cc: draft-ietf-idr-route-oscillation-stop@ietf.org, idr@ietf.org, pkyzivat@alum.mit.edu, shares@ndzh.com, idr-chairs@ietf.org Subject: [Idr] Jari Arkko's Discuss on draft-ietf-idr-route-oscillation-stop-03: (with DISCUSS and COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 09:55:57 -0000 Jari Arkko has entered the following ballot position for draft-ietf-idr-route-oscillation-stop-03: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-idr-route-oscillation-stop/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for writing this document on this important issue. I want to recommend its approval as an RFC and will do so shortly, but a Gen-ART review from Paul Kyzivat inspired me to read the document, and I have some comments. I'm not necessarily looking for document changes, but I am looking for some responses to Paul's or my comments, to make sure we all agree that we are doing this right. Specifically, > A detailed description of how these oscillations can occur > can be found in [RFC3345]; the description of how a node would > locally detect such condition is outside the scope of this document. I am not an expert on this topic, but I'd like to understand the nature of such detection algorithms. How hard problem is that? What is required? I'm not looking for specifying or even referring to the algorithm here, but it would be beneficial at least for this reader to understand the nature of the class of solutions referred to here. Are solutions algorithmically computable? Heuristic? Dependent on specific configurations? Vendor solutions exist but aren't documented. > When the ADD-PATH Capability is also received from > the IBGP peer with the "Send/Receive" field set to 1 (receive > multiple paths) or 3 (send/receive multiple paths) for the same SAFI>, then the following procedures shall be followed: > > If the peer is a route reflection client, the route reflector SHOULD > advertise to the peer the Group Best Paths (or the Available Paths) > received from its non-client IBGP peers. Depending on the > configuration, the route reflector MAY also advertise to the peer the > Group Best Paths (or the Available Paths) received from its clients. I am picking this text excerpt as an example. Like Paul, some of this language makes me slightly uncomfortable, and it would be good to understand what the aim is. If the intent is to describe a procedure that can be followed and fully specified, the expectations on the text are different from an informative description of the kinds of things an implementation could do. In the above text, there's quite a lot of imprecision. That may be fine, but I wanted to check that this is the case. For instance, why is a "shall" (and in lowercase) followed by a set of "SHOULD"s and "MAY"s? Is there any guidance on when the "SHOULD"s should be followed? There seems to be thinking behind, could that be documented? What kind of configuration issues affect the decisions? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The abstract and introduction should explain terms that are not commonly used (such as MED). BGP is a fine term to use without expansion. From nobody Thu May 5 04:07:48 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79C2C12D115 for ; Thu, 5 May 2016 04:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Sm1da4BRsW7 for ; Thu, 5 May 2016 04:07:45 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B239912B048 for ; Thu, 5 May 2016 04:07:45 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.238; From: "Susan Hares" To: , "'UTTARO, JAMES'" , "'John G. Scudder'" , "'Jakob Heitz \(jheitz\)'" References: <1BE5582B-90D5-4C99-8807-EC6202523E4B@juniper.net> <31522_1462181362_57271DF2_31522_142_1_53C29892C857584299CBF5D05346208A0F882DCC@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <31522_1462181362_57271DF2_31522_142_1_53C29892C857584299CBF5D05346208A0F882DCC@OPEXCLILM21.corporate.adroot.infra.ftgroup> Date: Thu, 5 May 2016 07:07:43 -0400 Message-ID: <07c001d1a6be$5958e490$0c0aadb0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG951+SXZCrL7XkhPM2fqOGSYC/VALzOr+1ASVQiqQDdvf7iZ+VMcNQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] BGP persistence X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 11:07:47 -0000 I will add this to the list of adoption calls. Sue (WG hat on) -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com Sent: Monday, May 02, 2016 5:29 AM To: UTTARO, JAMES; 'John G. Scudder'; 'Jakob Heitz (jheitz)' Cc: 'idr@ietf.org' Subject: Re: [Idr] BGP persistence +1 as a co-author +1 as an IDR contributor: having the discussions on the IDR mailing +list, allows IDR participants to contribute, improve the document, and +increase its applicability. (unfortunately, at this point, it seems +already a bit late) Thanks -- Bruno > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of UTTARO, JAMES > Sent: Sunday, May 01, 2016 3:22 PM > To: 'John G. Scudder'; 'Jakob Heitz (jheitz)' > Cc: 'idr@ietf.org' > Subject: Re: [Idr] BGP persistence > > +1.. > > We are using this.. > > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder > Sent: Friday, April 29, 2016 10:38 AM > To: Jakob Heitz (jheitz) > Cc: idr@ietf.org > Subject: Re: [Idr] BGP persistence > > It's a fair question! > > The last time the WG discussed adopting the item, as I recall there > was no consensus to do so. It seems as though we should be able to > have the conversation again at this point. As you say, we now have > actual experience with it, which hopefully will help inform the > discussion. Also, the current form of the document reflects many > updates made to address concerns expressed by the WG about previous > versions, so even though it wasn't a WG document, the authors were > listening and responding to the WG feedback. > > With WG chair hat firmly off my head and contributor-to-the-document > hat prominently displayed, let me suggest (or rather, second Jakob's > indirect > suggestion) that we adopt and progress the document. > > Thanks for bringing it up, > > --John > > > On Apr 29, 2016, at 10:29 AM, Jakob Heitz (jheitz) > > > wrote: > > > > Why is this > > https://tools.ietf.org/html/draft-uttaro-idr-bgp-persistence-03 > > persistently not an RFC? > > We have had an implementation for at least a couple of years and > > others > have also. > > > > -- > > Jakob Heitz. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr ____________________________________________________________________________ _____________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Thu May 5 05:32:02 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67F5512D51C; Thu, 5 May 2016 05:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7tjUAjiZss5; Thu, 5 May 2016 05:31:57 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 375C912D51F; Thu, 5 May 2016 05:31:56 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 753AC22C884; Thu, 5 May 2016 14:31:54 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.31]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 473FD238056; Thu, 5 May 2016 14:31:54 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1%19]) with mapi id 14.03.0294.000; Thu, 5 May 2016 14:31:53 +0200 From: To: EXT John E Drake , IDR , BESS , "draft-ietf-bess-evpn-overlay@tools.ietf.org" , "Ali Sajassi (sajassi)" , "Rabadan, Jorge (Nokia - US)" , "draft-ietf-idr-tunnel-encap@tools.ietf.org" Thread-Topic: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps Thread-Index: AdGmBJMUJMtmxTFkSDagWg0yGwJv3wAA4tKAAAWwlwAAAPoxgAACvdiAAAOPgQAAADvBgAAjSzCP Date: Thu, 5 May 2016 12:31:53 +0000 Message-ID: <1881_1462451514_572B3D3A_1881_7198_1_0vn90oitr7e881gh2sn8qm5f.1462451509961@email.android.com> References: <5729F1C3.1030605@orange.com> <5729F7C5.6040604@orange.com> <52D35106-ED5E-4C95-9131-6EA4527370D5@alcatel-lucent.com> <012C176C-A8D6-45AA-BA69-616C0ED7E41E@alcatel-lucent.com>, , <420BA2D8D80A6727.2B2C290F-2299-40BB-B53B-CC36D2B5D826@mail.outlook.com> In-Reply-To: <420BA2D8D80A6727.2B2C290F-2299-40BB-B53B-CC36D2B5D826@mail.outlook.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_0vn90oitr7e881gh2sn8qm5f1462451509961emailandroidcom_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.5.5.111218 Archived-At: Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 12:32:00 -0000 --_000_0vn90oitr7e881gh2sn8qm5f1462451509961emailandroidcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks for the clarification on the intent around draft-ietf-bess-evpn-over= lay. Then indeed section 9 needs some tidying up. The issue that I think remain is that it would be much cleaner to explain h= ow to use PMSI with overlay encaps in a spec not specific to E-VPN and in a= way more consistent to what is done for unicast. It seems if course that draft-ietf-idr-tunnel-encap should be the place, bu= t that document currently explicitly makes PMSIs out of scope. Shouldn't this part of draft-ietf-idr-tunnel-encap be revisited ? -Thomas ---- Rabadan, Jorge (Nokia - US) a =E9crit ---- Fully agree John. That's what I meant, sorry if I didn't make myself clear.= Section 9 needs clean up, yes. Thanks, Jorge _____________________________ From: EXT John E Drake > Sent: Wednesday, May 4, 2016 23:34 Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-e= ncaps To: IDR >, Ali Sajassi (sajassi) >, Rabadan, Jorge (Nokia - US) >, BESS <= bess@ietf.org>, >, EXT - thomas.= morin@orange.com > Jorge, We put the VNI value in the MPLS label field of the PMSI attribute for all = service types, and we put a value in the Ethernet Tag field following the r= ules for each service type as described in 5.1.3 (https://tools.ietf.org/ht= ml/draft-ietf-bess-evpn-overlay-02#section-5.1.3). You're right that we need to clean up section 9. Yours Irrespectively, John > -----Original Message----- > From: Rabadan, Jorge (Nokia - US) [mailto:jorge.rabadan@nokia.com] > Sent: Wednesday, May 04, 2016 3:53 PM > To: John E Drake; EXT - thomas.morin@orange.com; BESS; IDR; draft-ietf-bess-evpn- > overlay@tools.ietf.org; Ali Sajassi (sajas= si) > Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel= -encaps > > Hi John, > > About this: > > [JD] For the IMET route the MPLS label field is carried in the PMSI attri= bute. I think we need > to ask everyone whether they used the Ethernet Tag or the PMSI attribute = to carry the VNI > > > In case it helps, I=92ve seen a few implementations running and they all = encode the VNI in the > MPLS label field in the PTA. And a couple of them, encode the VNI in the = ethernet-tag, in > addition to the MPLS label in the PTA. In any case, I think section 9 con= tradicts section 5.1.3 > and should be clarified. > > "5.1.3 Constructing EVPN BGP Routes > > the MPLS label field in the MAC Advertisement, Ethernet AD per EVI, and *= *Inclusive > Multicast Ethernet Tag** routes is used to carry the VNI or VSID." > > Thanks. > Jorge > > > > > > On 5/4/16, 8:34 PM, "EXT John E Drake" > wrote: > > >Thomas and Jorge, > > > >Snipped, comments inline. > > > >Yours Irrespectively, > > > >John > > > >> > > >> >draft-ietf-bess-evpn-overlay (see section 9) relies on the BGP > >> >Encapsulation extended to encode the tunnel encap to use for BUM > >> >traffic, but contrary to other E-VPN routes, relies on the Ethernet > >> >Tag field of the NLRI to encode the VNI/VSID. > >> > >> [JORGE] This is certainly a leftover from an old version where the > >> VNI/VSID was encoded in the ethernet tag for all the routes. The VNI > >> should be encoded in the Label field in all the routes. This has to be= corrected. > >> > >> In fact, section 5.1.3 says: > >> > >> 5.1.3 Constructing EVPN BGP Routes > >> > >> > >> > >> Accordingly, and > >> specifically to support the option of locally assigned VNIs, the MPLS > >> label field in the MAC Advertisement, Ethernet AD per EVI, and > >> Inclusive Multicast Ethernet Tag routes is used to carry the VNI or > >> VSID. For the balance of this memo, the MPLS label field will be > >> referred to as the VNI/VSID field. The VNI/VSID field is used for > >> both local and global VNIs/VSIDs, and for either case the entire 24- > >> bit field is used to encode the VNI/VSID value. > >> > >> > > > > > >[JD] For the IMET route the MPLS label field is carried in the PMSI attr= ibute. I think we > need to ask everyone whether they > >used the Ethernet Tag or the PMSI attribute to carry the VNI > > > > > >> >> > >> >> There are minor things that could be improved in > >> >> draft-ietf-bess-evpn-overlay wrt. consistency with > >> >> draft-ietf-idr-tunnel-encaps : > >> >> > >> >> * since draft-ietf-idr-tunnel-encaps will deprecate RFC5512, it > >> >> would be better that draft-ietf-bess-evpn-overlay refers to > >> >> draft-ietf-idr-tunnel-encaps and not anymore to RFC5512. > >> > >> [JORGE] I agree, as long as draft-ietf-idr-tunnel-encaps keeps the > >> encapsulation extended community. There are a few implementations > >> using this community and it is enough when only the encapsulation type= is needed. > > > > > >[JD] I agree and the tunnel encaps draft does keep the EC > > > > > >> > >> >> > >> >> * I think it would be better to avoid the explicit list of encap > >> >> types in section 5.1.3, and rather refer to > >> >> draft-ietf-idr-tunnel-encaps instead > >> > >> [JORGE] I agree. > > > > > >[JD] According to IANA, it allocated the five tunnels types to the > >overlay draft so I think we need to keep them > > > > > >> > >> >> * the following minor modification was proposed, but not yet incorp= orated: > >> >> > >> >> John Drake, 2015-11-13 (to BESS ML): > >> >>> For the overlay draft, replace this text in section 5.1.3: > >> >>> > >> >>> "If the BGP Encapsulation extended community is not present, > >> >>> then the default MPLS encapsulation or a statically configured > >> >>> encapsulation is assumed." > >> >>> > >> >>> With the following: > >> >>> > >> >>> "Note that the MPLS encapsulation tunnel type is needed in > >> >>> order to distinguish between an advertising node that only > >> >>> supports non-MPLS encapsulations and one that supports MPLS and > >> >>> non-MPLS encapsulations. An advertising node that only supports > >> >>> MPLS encapsulation does not need to advertise any encapsulation > >> >>> tunnel types; i.e., if the BGP Encapsulation extended community > >> >>> is not present, then either MPLS encapsulation or a statically > >> >>> configured encapsulation is assumed." > >> >> > >> >> I think this change is useful and should be incorporated, although > >> >> skipping the last sentence would be wise if the full list of > >> >> tunnel types is removed. > > > > > >[JD] Fine with me either w/ or w/o the last sentence > > > > ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_0vn90oitr7e881gh2sn8qm5f1462451509961emailandroidcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks for the clarification on the intent around draft-ietf-bess-evpn-over= lay. Then indeed section 9 needs some tidying up.

The issue that I think remain is that it would be much cleaner to explain h= ow to use PMSI with overlay encaps in a spec not specific to E-VPN and in a= way more consistent to what is done for unicast.

It seems if course that draft-ietf-idr-tunnel-encap should be the place, bu= t that document currently explicitly makes PMSIs out of scope.

Shouldn't this part of draft-ietf-idr-tunnel-encap be revisited ?

-Thomas


---- Rabadan, Jorge (Nokia - US) a =E9crit ----

Fully agree John. That's what I meant, sorry if I didn't make myself c= lear. Section 9 needs clean up, yes.

Thanks,
Jorge

_____________________________
From: EXT John E Drake <jdrake@juniper.net>
Sent: Wednesday, May 4, 2016 23:34
Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-e= ncaps
To: IDR <idr@ietf.org>= ;, Ali Sajassi (sajassi) <sajassi@cisco.com>, Rabadan, Jorge (Nokia - US) <jorge.rabadan@alcatel-lu= cent.com>, BESS <bess@ietf.org>= ;, <draft-ietf-bess-evpn-overlay@tools.ietf.org>, EXT - thomas.morin@orange.= com <thomas.m= orin@orange.com>


Jorge,

We put the VNI value in the MPLS label field of the PMSI attribute for all = service types, and we put a value in the Ethernet Tag field following the r= ules for each service type as described in 5.1.3 (ht= tps://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-02#section-5.1.3= ).

You're right that we need to clean up section 9.

Yours Irrespectively,

John

> -----Original Message-----
> From: Rabadan, Jorge (Nokia - US) [mailto:jorge.rabadan@nokia.com]
> Sent: Wednesday, May 04, 2016 3:53 PM
> To: John E Drake; EXT - thomas.morin@orange.com; BESS; IDR; draft-ietf-bess-evpn-
> overlay@tools.ie= tf.org; Ali Sajassi (sajassi)
> Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tun= nel-encaps
>
> Hi John,
>
> About this:
>
> [JD] For the IMET route the MPLS label field is carried in the PMSI at= tribute. I think we need
> to ask everyone whether they used the Ethernet Tag or the PMSI attribu= te to carry the VNI
>
>
> In case it helps, I=92ve seen a few implementations running and they a= ll encode the VNI in the
> MPLS label field in the PTA. And a couple of them, encode the VNI in t= he ethernet-tag, in
> addition to the MPLS label in the PTA. In any case, I think section 9 = contradicts section 5.1.3
> and should be clarified.
>
> "5.1.3 Constructing EVPN BGP Routes
> <snip>
> the MPLS label field in the MAC Advertisement, Ethernet AD per EVI, an= d **Inclusive
> Multicast Ethernet Tag** routes is used to carry the VNI or VSID."= ;
>
> Thanks.
> Jorge
>
>
>
>
>
> On 5/4/16, 8:34 PM, "EXT John E Drake" <jdrake@juniper.net> wrote:
>
> >Thomas and Jorge,
> >
> >Snipped, comments inline.
> >
> >Yours Irrespectively,
> >
> >John
> >
> >> >
> >> >draft-ietf-bess-evpn-overlay (see section 9) relies on th= e BGP
> >> >Encapsulation extended to encode the tunnel encap to use = for BUM
> >> >traffic, but contrary to other E-VPN routes, relies on th= e Ethernet
> >> >Tag field of the NLRI to encode the VNI/VSID.
> >>
> >> [JORGE] This is certainly a leftover from an old version wher= e the
> >> VNI/VSID was encoded in the ethernet tag for all the routes. = The VNI
> >> should be encoded in the Label field in all the routes. This = has to be corrected.
> >>
> >> In fact, section 5.1.3 says:
> >>
> >> 5.1.3 Constructing EVPN BGP Routes
> >>
> >> <snip>
> >>
> >> Accordingly, and
> >> specifically to support the option of locally assigned VNIs, = the MPLS
> >> label field in the MAC Advertisement, Ethernet AD per EVI, an= d
> >> Inclusive Multicast Ethernet Tag routes is used to carry the = VNI or
> >> VSID. For the balance of this memo, the MPLS label field will= be
> >> referred to as the VNI/VSID field. The VNI/VSID field is used= for
> >> both local and global VNIs/VSIDs, and for either case the ent= ire 24-
> >> bit field is used to encode the VNI/VSID value.
> >>
> >> <snip>
> >
> >
> >[JD] For the IMET route the MPLS label field is carried in the PMS= I attribute. I think we
> need to ask everyone whether they
> >used the Ethernet Tag or the PMSI attribute to carry the VNI
> >
> >
> >> >>
> >> >> There are minor things that could be improved in
> >> >> draft-ietf-bess-evpn-overlay wrt. consistency with > >> >> draft-ietf-idr-tunnel-encaps :
> >> >>
> >> >> * since draft-ietf-idr-tunnel-encaps will deprecate = RFC5512, it
> >> >> would be better that draft-ietf-bess-evpn-overlay re= fers to
> >> >> draft-ietf-idr-tunnel-encaps and not anymore to RFC5= 512.
> >>
> >> [JORGE] I agree, as long as draft-ietf-idr-tunnel-encaps keep= s the
> >> encapsulation extended community. There are a few implementat= ions
> >> using this community and it is enough when only the encapsula= tion type is needed.
> >
> >
> >[JD] I agree and the tunnel encaps draft does keep the EC
> >
> >
> >>
> >> >>
> >> >> * I think it would be better to avoid the explicit l= ist of encap
> >> >> types in section 5.1.3, and rather refer to
> >> >> draft-ietf-idr-tunnel-encaps instead
> >>
> >> [JORGE] I agree.
> >
> >
> >[JD] According to IANA, it allocated the five tunnels types to the=
> >overlay draft so I think we need to keep them
> >
> >
> >>
> >> >> * the following minor modification was proposed, but= not yet incorporated:
> >> >>
> >> >> John Drake, 2015-11-13 (to BESS ML):
> >> >>> For the overlay draft, replace this text in sect= ion 5.1.3:
> >> >>>
> >> >>> "If the BGP Encapsulation extended communit= y is not present,
> >> >>> then the default MPLS encapsulation or a statica= lly configured
> >> >>> encapsulation is assumed."
> >> >>>
> >> >>> With the following:
> >> >>>
> >> >>> "Note that the MPLS encapsulation tunnel ty= pe is needed in
> >> >>> order to distinguish between an advertising node= that only
> >> >>> supports non-MPLS encapsulations and one that su= pports MPLS and
> >> >>> non-MPLS encapsulations. An advertising node tha= t only supports
> >> >>> MPLS encapsulation does not need to advertise an= y encapsulation
> >> >>> tunnel types; i.e., if the BGP Encapsulation ext= ended community
> >> >>> is not present, then either MPLS encapsulation o= r a statically
> >> >>> configured encapsulation is assumed."
> >> >>
> >> >> I think this change is useful and should be incorpor= ated, although
> >> >> skipping the last sentence would be wise if the full= list of
> >> >> tunnel types is removed.
> >
> >
> >[JD] Fine with me either w/ or w/o the last sentence
> >
> >


______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_0vn90oitr7e881gh2sn8qm5f1462451509961emailandroidcom_-- From nobody Thu May 5 05:57:32 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8FF612D611; Thu, 5 May 2016 05:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2GpZ9IkUaAo; Thu, 5 May 2016 05:57:23 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0762.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:762]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE5C512D610; Thu, 5 May 2016 05:57:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=amCzbLLNBed88/E3yNrM4CdGLYCPZrcGVbdZaMHVvpA=; b=KEEcpBWgd0SSyyvt3x8pkkXJLPoe9bYtvhQ9w/a+yTTiJMU1fbnEPQZpM3rZMJB4Ce4T4kfi3TUGcnmJDKlGbHFEP21aobEYGM7XE1QOfirWCEGpUaKLZ/D1cZBDUsVXwPHkL6v1B2t4aMlL7rD9SzRHXXZo8Z78448gJDkoauQ= Received: from SN1PR0501MB1709.namprd05.prod.outlook.com (10.163.130.155) by SN1PR0501MB1710.namprd05.prod.outlook.com (10.163.130.156) with Microsoft SMTP Server (TLS) id 15.1.477.8; Thu, 5 May 2016 12:57:05 +0000 Received: from SN1PR0501MB1709.namprd05.prod.outlook.com ([10.163.130.155]) by SN1PR0501MB1709.namprd05.prod.outlook.com ([10.163.130.155]) with mapi id 15.01.0477.016; Thu, 5 May 2016 12:57:05 +0000 From: John E Drake To: "EXT - thomas.morin@orange.com" , IDR , BESS , "draft-ietf-bess-evpn-overlay@tools.ietf.org" , "Ali Sajassi (sajassi)" , "Rabadan, Jorge (Nokia - US)" , "draft-ietf-idr-tunnel-encap@tools.ietf.org" Thread-Topic: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps Thread-Index: AQHRpi+6xGM0bynWeUeGN93K6stLXZ+pFtLwgAAZ14CAABtMwIAAAw6AgAD40oCAAALOkA== Date: Thu, 5 May 2016 12:57:05 +0000 Message-ID: References: <5729F1C3.1030605@orange.com> <5729F7C5.6040604@orange.com> <52D35106-ED5E-4C95-9131-6EA4527370D5@alcatel-lucent.com> <012C176C-A8D6-45AA-BA69-616C0ED7E41E@alcatel-lucent.com>, , <420BA2D8D80A6727.2B2C290F-2299-40BB-B53B-CC36D2B5D826@mail.outlook.com> <1881_1462451514_572B3D3A_1881_7198_1_0vn90oitr7e881gh2sn8qm5f.1462451509961@email.android.com> In-Reply-To: <1881_1462451514_572B3D3A_1881_7198_1_0vn90oitr7e881gh2sn8qm5f.1462451509961@email.android.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.12] x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr,ExtAddr x-ms-office365-filtering-correlation-id: 547fedac-6ba5-4a05-b631-08d374e4c2bc x-microsoft-exchange-diagnostics: 1; SN1PR0501MB1710; 5:9EjdA122w1JFQg4S5v4SYtR6FrDM1smwV9ympsGsOeTja5oYSIEUH6h1O+UwXkZ1odj9BmkHqBT+Ze5FAiJrtbRXyv0KpNmS61TJmw5jBBiC78ajcfxxNHNjKu/r1xsfUrFrUGQ2XJPxM8zXtF9t1A==; 24:6jZ+JMamZ1HwC2rr3aN6GHwVa7VQQ5nvVHNw8ezcyCsu2lW2n+45x3DoxQHJrUr0Uoh+aP+hi5kq9ZEdLyB4e9jPUSRWRGUUWrnxNxJTSAE=; 7:Z2gK7wKu7VXdX/14JeTo9/rZm6LXJWdP/IQlm4EbPaULXkTjwYOEuj9LllPPsoL1bTqekQdgRN11gm/qIu4sI+w2tR/Z8ddyJbYvq+Ou2bDOMNTxcAvtHJDhQknTvlFlvxB8nRB2quDikwwfAKXiInpZ74aUuHWu1T+oQ+1kWzkL3YAwdLzidFCUcEEjBKQ+ x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB1710; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521098)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:SN1PR0501MB1710; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1710; x-forefront-prvs: 0933E9FD8D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(377424004)(13464003)(51914003)(24454002)(76576001)(5003600100002)(76176999)(54356999)(50986999)(586003)(86362001)(5004730100002)(87936001)(107886002)(19580395003)(19580405001)(19609705001)(2906002)(16236675004)(5002640100001)(92566002)(10400500002)(106116001)(99286002)(66066001)(5890100001)(122556002)(33656002)(2501003)(74316001)(19300405004)(3660700001)(11100500001)(19617315012)(93886004)(81166005)(9686002)(102836003)(790700001)(3846002)(6116002)(77096005)(8936002)(230783001)(15975445007)(1220700001)(19625215002)(3280700002)(2900100001)(4001150100001)(5008740100001)(5001770100001)(189998001)(2950100001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB1710; H:SN1PR0501MB1709.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0501MB17099CA0122BA8B4C3F99E7EC77C0SN1PR0501MB1709_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 05 May 2016 12:57:05.7415 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB1710 Archived-At: Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 12:57:28 -0000 --_000_SN1PR0501MB17099CA0122BA8B4C3F99E7EC77C0SN1PR0501MB1709_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thomas, The overlay draft preceded the tunnel encaps draft and it was designed to h= andle a very specific problem, marrying the EVPN control plane to the VXLAN= data plane draft and modulo the correction to section 9 it is internally c= onsistent. The tunnel encaps draft solves a more general problem and the WG decided a = long time ago that the overlay draft was not going to be updated to use the= mechanisms it details for unicast, so the overlay draft is already explici= tly not in alignment with it. This, plus the fact that the tunnel encaps draft explicitly puts the PMSI o= ut of scope, leads me to the conclusion that the overlay draft should not b= e tweaked to be in alignment with a future solution for encoding VNIs for m= ulticast. Yours Irrespectively, John From: thomas.morin@orange.com [mailto:thomas.morin@orange.com] Sent: Thursday, May 05, 2016 8:32 AM To: John E Drake; IDR; BESS; draft-ietf-bess-evpn-overlay@tools.ietf.org; A= li Sajassi (sajassi); Rabadan, Jorge (Nokia - US); draft-ietf-idr-tunnel-en= cap@tools.ietf.org Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-e= ncaps Thanks for the clarification on the intent around draft-ietf-bess-evpn-over= lay. Then indeed section 9 needs some tidying up. The issue that I think remain is that it would be much cleaner to explain h= ow to use PMSI with overlay encaps in a spec not specific to E-VPN and in a= way more consistent to what is done for unicast. It seems if course that draft-ietf-idr-tunnel-encap should be the place, bu= t that document currently explicitly makes PMSIs out of scope. Shouldn't this part of draft-ietf-idr-tunnel-encap be revisited ? -Thomas ---- Rabadan, Jorge (Nokia - US) a =E9crit ---- Fully agree John. That's what I meant, sorry if I didn't make myself clear.= Section 9 needs clean up, yes. Thanks, Jorge _____________________________ From: EXT John E Drake > Sent: Wednesday, May 4, 2016 23:34 Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-e= ncaps To: IDR >, Ali Sajassi (sajassi) >, Rabadan, Jorge (Nokia - US) >, BESS <= bess@ietf.org>, >, EXT - thomas.= morin@orange.com > Jorge, We put the VNI value in the MPLS label field of the PMSI attribute for all = service types, and we put a value in the Ethernet Tag field following the r= ules for each service type as described in 5.1.3 (https://tools.ietf.org/ht= ml/draft-ietf-bess-evpn-overlay-02#section-5.1.3). You're right that we need to clean up section 9. Yours Irrespectively, John > -----Original Message----- > From: Rabadan, Jorge (Nokia - US) [mailto:jorge.rabadan@nokia.com] > Sent: Wednesday, May 04, 2016 3:53 PM > To: John E Drake; EXT - thomas.morin@orange.com; BESS; IDR; draft-ietf-bess-evpn- > overlay@tools.ietf.org; Ali Sajassi (sajas= si) > Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel= -encaps > > Hi John, > > About this: > > [JD] For the IMET route the MPLS label field is carried in the PMSI attri= bute. I think we need > to ask everyone whether they used the Ethernet Tag or the PMSI attribute = to carry the VNI > > > In case it helps, I've seen a few implementations running and they all en= code the VNI in the > MPLS label field in the PTA. And a couple of them, encode the VNI in the = ethernet-tag, in > addition to the MPLS label in the PTA. In any case, I think section 9 con= tradicts section 5.1.3 > and should be clarified. > > "5.1.3 Constructing EVPN BGP Routes > > the MPLS label field in the MAC Advertisement, Ethernet AD per EVI, and *= *Inclusive > Multicast Ethernet Tag** routes is used to carry the VNI or VSID." > > Thanks. > Jorge > > > > > > On 5/4/16, 8:34 PM, "EXT John E Drake" > wrote: > > >Thomas and Jorge, > > > >Snipped, comments inline. > > > >Yours Irrespectively, > > > >John > > > >> > > >> >draft-ietf-bess-evpn-overlay (see section 9) relies on the BGP > >> >Encapsulation extended to encode the tunnel encap to use for BUM > >> >traffic, but contrary to other E-VPN routes, relies on the Ethernet > >> >Tag field of the NLRI to encode the VNI/VSID. > >> > >> [JORGE] This is certainly a leftover from an old version where the > >> VNI/VSID was encoded in the ethernet tag for all the routes. The VNI > >> should be encoded in the Label field in all the routes. This has to be= corrected. > >> > >> In fact, section 5.1.3 says: > >> > >> 5.1.3 Constructing EVPN BGP Routes > >> > >> > >> > >> Accordingly, and > >> specifically to support the option of locally assigned VNIs, the MPLS > >> label field in the MAC Advertisement, Ethernet AD per EVI, and > >> Inclusive Multicast Ethernet Tag routes is used to carry the VNI or > >> VSID. For the balance of this memo, the MPLS label field will be > >> referred to as the VNI/VSID field. The VNI/VSID field is used for > >> both local and global VNIs/VSIDs, and for either case the entire 24- > >> bit field is used to encode the VNI/VSID value. > >> > >> > > > > > >[JD] For the IMET route the MPLS label field is carried in the PMSI attr= ibute. I think we > need to ask everyone whether they > >used the Ethernet Tag or the PMSI attribute to carry the VNI > > > > > >> >> > >> >> There are minor things that could be improved in > >> >> draft-ietf-bess-evpn-overlay wrt. consistency with > >> >> draft-ietf-idr-tunnel-encaps : > >> >> > >> >> * since draft-ietf-idr-tunnel-encaps will deprecate RFC5512, it > >> >> would be better that draft-ietf-bess-evpn-overlay refers to > >> >> draft-ietf-idr-tunnel-encaps and not anymore to RFC5512. > >> > >> [JORGE] I agree, as long as draft-ietf-idr-tunnel-encaps keeps the > >> encapsulation extended community. There are a few implementations > >> using this community and it is enough when only the encapsulation type= is needed. > > > > > >[JD] I agree and the tunnel encaps draft does keep the EC > > > > > >> > >> >> > >> >> * I think it would be better to avoid the explicit list of encap > >> >> types in section 5.1.3, and rather refer to > >> >> draft-ietf-idr-tunnel-encaps instead > >> > >> [JORGE] I agree. > > > > > >[JD] According to IANA, it allocated the five tunnels types to the > >overlay draft so I think we need to keep them > > > > > >> > >> >> * the following minor modification was proposed, but not yet incorp= orated: > >> >> > >> >> John Drake, 2015-11-13 (to BESS ML): > >> >>> For the overlay draft, replace this text in section 5.1.3: > >> >>> > >> >>> "If the BGP Encapsulation extended community is not present, > >> >>> then the default MPLS encapsulation or a statically configured > >> >>> encapsulation is assumed." > >> >>> > >> >>> With the following: > >> >>> > >> >>> "Note that the MPLS encapsulation tunnel type is needed in > >> >>> order to distinguish between an advertising node that only > >> >>> supports non-MPLS encapsulations and one that supports MPLS and > >> >>> non-MPLS encapsulations. An advertising node that only supports > >> >>> MPLS encapsulation does not need to advertise any encapsulation > >> >>> tunnel types; i.e., if the BGP Encapsulation extended community > >> >>> is not present, then either MPLS encapsulation or a statically > >> >>> configured encapsulation is assumed." > >> >> > >> >> I think this change is useful and should be incorporated, although > >> >> skipping the last sentence would be wise if the full list of > >> >> tunnel types is removed. > > > > > >[JD] Fine with me either w/ or w/o the last sentence > > > > ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_SN1PR0501MB17099CA0122BA8B4C3F99E7EC77C0SN1PR0501MB1709_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thomas,

 

The overlay draft preceded the tunnel= encaps draft and it was designed to handle a very specific problem, marryi= ng the EVPN control plane to the VXLAN data plane draft and modulo the correction to section 9 it is internally consistent.<= o:p>

 

The tunnel encaps draft solves a more= general problem and the WG decided a long time ago that the overlay draft = was not going to be updated to use the mechanisms it details for unicast, so the overlay draft is already explicitly not in = alignment with it.

 

This, plus the fact that the tunnel e= ncaps draft explicitly puts the PMSI out of scope, leads me to the conclusi= on that the overlay draft should not be tweaked to be in alignment with a future solution for encoding VNIs for multicast.=

 

Yours Irrespectively,

 

John

 

From: thomas.morin@orange.com [mailt= o:thomas.morin@orange.com]
Sent: Thursday, May 05, 2016 8:32 AM
To: John E Drake; IDR; BESS; draft-ietf-bess-evpn-overlay@tools.ietf= .org; Ali Sajassi (sajassi); Rabadan, Jorge (Nokia - US); draft-ietf-idr-tu= nnel-encap@tools.ietf.org
Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-t= unnel-encaps

 

Thanks for the clarif= ication on the intent around draft-ietf-bess-evpn-overlay. Then indeed sect= ion 9 needs some tidying up.

The issue that I think remain is that it would be much cleaner to explain h= ow to use PMSI with overlay encaps in a spec not specific to E-VPN and in a= way more consistent to what is done for unicast.

It seems if course that draft-ietf-idr-tunnel-encap should be the place, bu= t that document currently explicitly makes PMSIs out of scope.

Shouldn't this part of draft-ietf-idr-tunnel-encap be revisited ?

-Thomas


---- Rabadan, Jorge (Nokia - US) a =E9crit ----

Fully agree John. Tha= t's what I meant, sorry if I didn't make myself clear. Section 9 needs clea= n up, yes.

Thanks,
Jorge

 

_____________________= ________
From: EXT John E Drake <jdrake@jun= iper.net>
Sent: Wednesday, May 4, 2016 23:34
Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-e= ncaps
To: IDR <idr@ietf.org>, Ali Sajas= si (sajassi) <sajassi@cisco.com= >, Rabadan, Jorge (Nokia - US) <jorge.rabadan@alcatel-lucent.com>, BESS <bess@ietf.org>, <draft-ietf-bess-e= vpn-overlay@tools.ietf.org>, EXT - thomas.morin@orange.com <= thomas.morin@orange.com><= br>

Jorge,

We put the VNI value in the MPLS label field of the PMSI attribute for all = service types, and we put a value in the Ethernet Tag field following the r= ules for each service type as described in 5.1.3 (https://tools.= ietf.org/html/draft-ietf-bess-evpn-overlay-02#section-5.1.3).

You're right that we need to clean up section 9.

Yours Irrespectively,

John

> -----Original Message-----
> From: Rabadan, Jorge (Nokia - US) [mailto:jorge.rabadan@nokia.com]
> Sent: Wednesday, May 04, 2016 3:53 PM
> To: John E Drake; EXT - tho= mas.morin@orange.com; BESS; IDR; draft-ietf-bess-evpn-
> overlay@tools.ietf.org; = Ali Sajassi (sajassi)
> Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tun= nel-encaps
>
> Hi John,
>
> About this:
>
> [JD] For the IMET route the MPLS label field is carried in the PMSI at= tribute. I think we need
> to ask everyone whether they used the Ethernet Tag or the PMSI attribu= te to carry the VNI
>
>
> In case it helps, I’ve seen a few implementations running and th= ey all encode the VNI in the
> MPLS label field in the PTA. And a couple of them, encode the VNI in t= he ethernet-tag, in
> addition to the MPLS label in the PTA. In any case, I think section 9 = contradicts section 5.1.3
> and should be clarified.
>
> "5.1.3 Constructing EVPN BGP Routes
> <snip>
> the MPLS label field in the MAC Advertisement, Ethernet AD per EVI, an= d **Inclusive
> Multicast Ethernet Tag** routes is used to carry the VNI or VSID."= ;
>
> Thanks.
> Jorge
>
>
>
>
>
> On 5/4/16, 8:34 PM, "EXT John E Drake" <jdrake@juniper.net> wrote:
>
> >Thomas and Jorge,
> >
> >Snipped, comments inline.
> >
> >Yours Irrespectively,
> >
> >John
> >
> >> >
> >> >draft-ietf-bess-evpn-overlay (see section 9) relies on th= e BGP
> >> >Encapsulation extended to encode the tunnel encap to use = for BUM
> >> >traffic, but contrary to other E-VPN routes, relies on th= e Ethernet
> >> >Tag field of the NLRI to encode the VNI/VSID.
> >>
> >> [JORGE] This is certainly a leftover from an old version wher= e the
> >> VNI/VSID was encoded in the ethernet tag for all the routes. = The VNI
> >> should be encoded in the Label field in all the routes. This = has to be corrected.
> >>
> >> In fact, section 5.1.3 says:
> >>
> >> 5.1.3 Constructing EVPN BGP Routes
> >>
> >> <snip>
> >>
> >> Accordingly, and
> >> specifically to support the option of locally assigned VNIs, = the MPLS
> >> label field in the MAC Advertisement, Ethernet AD per EVI, an= d
> >> Inclusive Multicast Ethernet Tag routes is used to carry the = VNI or
> >> VSID. For the balance of this memo, the MPLS label field will= be
> >> referred to as the VNI/VSID field. The VNI/VSID field is used= for
> >> both local and global VNIs/VSIDs, and for either case the ent= ire 24-
> >> bit field is used to encode the VNI/VSID value.
> >>
> >> <snip>
> >
> >
> >[JD] For the IMET route the MPLS label field is carried in the PMS= I attribute. I think we
> need to ask everyone whether they
> >used the Ethernet Tag or the PMSI attribute to carry the VNI
> >
> >
> >> >>
> >> >> There are minor things that could be improved in
> >> >> draft-ietf-bess-evpn-overlay wrt. consistency with > >> >> draft-ietf-idr-tunnel-encaps :
> >> >>
> >> >> * since draft-ietf-idr-tunnel-encaps will deprecate = RFC5512, it
> >> >> would be better that draft-ietf-bess-evpn-overlay re= fers to
> >> >> draft-ietf-idr-tunnel-encaps and not anymore to RFC5= 512.
> >>
> >> [JORGE] I agree, as long as draft-ietf-idr-tunnel-encaps keep= s the
> >> encapsulation extended community. There are a few implementat= ions
> >> using this community and it is enough when only the encapsula= tion type is needed.
> >
> >
> >[JD] I agree and the tunnel encaps draft does keep the EC
> >
> >
> >>
> >> >>
> >> >> * I think it would be better to avoid the explicit l= ist of encap
> >> >> types in section 5.1.3, and rather refer to
> >> >> draft-ietf-idr-tunnel-encaps instead
> >>
> >> [JORGE] I agree.
> >
> >
> >[JD] According to IANA, it allocated the five tunnels types to the=
> >overlay draft so I think we need to keep them
> >
> >
> >>
> >> >> * the following minor modification was proposed, but= not yet incorporated:
> >> >>
> >> >> John Drake, 2015-11-13 (to BESS ML):
> >> >>> For the overlay draft, replace this text in sect= ion 5.1.3:
> >> >>>
> >> >>> "If the BGP Encapsulation extended communit= y is not present,
> >> >>> then the default MPLS encapsulation or a statica= lly configured
> >> >>> encapsulation is assumed."
> >> >>>
> >> >>> With the following:
> >> >>>
> >> >>> "Note that the MPLS encapsulation tunnel ty= pe is needed in
> >> >>> order to distinguish between an advertising node= that only
> >> >>> supports non-MPLS encapsulations and one that su= pports MPLS and
> >> >>> non-MPLS encapsulations. An advertising node tha= t only supports
> >> >>> MPLS encapsulation does not need to advertise an= y encapsulation
> >> >>> tunnel types; i.e., if the BGP Encapsulation ext= ended community
> >> >>> is not present, then either MPLS encapsulation o= r a statically
> >> >>> configured encapsulation is assumed."
> >> >>
> >> >> I think this change is useful and should be incorpor= ated, although
> >> >> skipping the last sentence would be wise if the full= list of
> >> >> tunnel types is removed.
> >
> >
> >[JD] Fine with me either w/ or w/o the last sentence
> >
> >

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
--_000_SN1PR0501MB17099CA0122BA8B4C3F99E7EC77C0SN1PR0501MB1709_-- From nobody Thu May 5 06:45:39 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 904FC12D68F; Thu, 5 May 2016 06:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBeFWP3YIIoS; Thu, 5 May 2016 06:45:33 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 248A812D618; Thu, 5 May 2016 06:45:32 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 4E135782C4FBE; Thu, 5 May 2016 13:45:25 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u45DjSve024158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 May 2016 13:45:28 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u45DjPpM025362 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 May 2016 15:45:27 +0200 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.187]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Thu, 5 May 2016 15:45:27 +0200 From: "Rabadan, Jorge (Nokia - US)" To: EXT John E Drake , "EXT - thomas.morin@orange.com" , IDR , BESS , "draft-ietf-bess-evpn-overlay@tools.ietf.org" , "Ali Sajassi (sajassi)" , "draft-ietf-idr-tunnel-encap@tools.ietf.org" Thread-Topic: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps Thread-Index: AQHRpi+kmvQEkxjTwkqTS+eCL8sT/p+o+TOAgAA3cgD///r5AIAAI2bYgADXSoCAAAcLgIAALwcA Date: Thu, 5 May 2016 13:45:27 +0000 Message-ID: References: <5729F1C3.1030605@orange.com> <5729F7C5.6040604@orange.com> <52D35106-ED5E-4C95-9131-6EA4527370D5@alcatel-lucent.com> <012C176C-A8D6-45AA-BA69-616C0ED7E41E@alcatel-lucent.com> <420BA2D8D80A6727.2B2C290F-2299-40BB-B53B-CC36D2B5D826@mail.outlook.com> <1881_1462451514_572B3D3A_1881_7198_1_0vn90oitr7e881gh2sn8qm5f.1462451509961@email.android.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_C34C65F6323049E3B3AAC488A9154943alcatellucentcom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 13:45:36 -0000 --_000_C34C65F6323049E3B3AAC488A9154943alcatellucentcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIEpvaG4uDQoNClRoYW5rcy4NCkpvcmdlDQoNCk9uIDUvNS8xNiwgMjo1NyBQ TSwgIkVYVCBKb2huIEUgRHJha2UiIDxqZHJha2VAanVuaXBlci5uZXQ8bWFpbHRvOmpkcmFrZUBq dW5pcGVyLm5ldD4+IHdyb3RlOg0KDQpUaG9tYXMsDQoNClRoZSBvdmVybGF5IGRyYWZ0IHByZWNl ZGVkIHRoZSB0dW5uZWwgZW5jYXBzIGRyYWZ0IGFuZCBpdCB3YXMgZGVzaWduZWQgdG8gaGFuZGxl IGEgdmVyeSBzcGVjaWZpYyBwcm9ibGVtLCBtYXJyeWluZyB0aGUgRVZQTiBjb250cm9sIHBsYW5l IHRvIHRoZSBWWExBTiBkYXRhIHBsYW5lIGRyYWZ0IGFuZCBtb2R1bG8gdGhlIGNvcnJlY3Rpb24g dG8gc2VjdGlvbiA5IGl0IGlzIGludGVybmFsbHkgY29uc2lzdGVudC4NCg0KVGhlIHR1bm5lbCBl bmNhcHMgZHJhZnQgc29sdmVzIGEgbW9yZSBnZW5lcmFsIHByb2JsZW0gYW5kIHRoZSBXRyBkZWNp ZGVkIGEgbG9uZyB0aW1lIGFnbyB0aGF0IHRoZSBvdmVybGF5IGRyYWZ0IHdhcyBub3QgZ29pbmcg dG8gYmUgdXBkYXRlZCB0byB1c2UgdGhlIG1lY2hhbmlzbXMgaXQgZGV0YWlscyBmb3IgdW5pY2Fz dCwgc28gdGhlIG92ZXJsYXkgZHJhZnQgaXMgYWxyZWFkeSBleHBsaWNpdGx5IG5vdCBpbiBhbGln bm1lbnQgd2l0aCBpdC4NCg0KVGhpcywgcGx1cyB0aGUgZmFjdCB0aGF0IHRoZSB0dW5uZWwgZW5j YXBzIGRyYWZ0IGV4cGxpY2l0bHkgcHV0cyB0aGUgUE1TSSBvdXQgb2Ygc2NvcGUsIGxlYWRzIG1l IHRvIHRoZSBjb25jbHVzaW9uIHRoYXQgdGhlIG92ZXJsYXkgZHJhZnQgc2hvdWxkIG5vdCBiZSB0 d2Vha2VkIHRvIGJlIGluIGFsaWdubWVudCB3aXRoIGEgZnV0dXJlIHNvbHV0aW9uIGZvciBlbmNv ZGluZyBWTklzIGZvciBtdWx0aWNhc3QuDQoNCllvdXJzIElycmVzcGVjdGl2ZWx5LA0KDQpKb2hu DQoNCkZyb206IHRob21hcy5tb3JpbkBvcmFuZ2UuY29tPG1haWx0bzp0aG9tYXMubW9yaW5Ab3Jh bmdlLmNvbT4gW21haWx0bzp0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbV0NClNlbnQ6IFRodXJzZGF5 LCBNYXkgMDUsIDIwMTYgODozMiBBTQ0KVG86IEpvaG4gRSBEcmFrZTsgSURSOyBCRVNTOyBkcmFm dC1pZXRmLWJlc3MtZXZwbi1vdmVybGF5QHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRm LWJlc3MtZXZwbi1vdmVybGF5QHRvb2xzLmlldGYub3JnPjsgQWxpIFNhamFzc2kgKHNhamFzc2kp OyBSYWJhZGFuLCBKb3JnZSAoTm9raWEgLSBVUyk7IGRyYWZ0LWlldGYtaWRyLXR1bm5lbC1lbmNh cEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1pZHItdHVubmVsLWVuY2FwQHRvb2xz LmlldGYub3JnPg0KU3ViamVjdDogUkU6IFtJZHJdIGRyYWZ0LWlldGYtYmVzcy1ldnBuLW92ZXJs YXkgdnMuIGRyYWZ0LWlldGYtaWRyLXR1bm5lbC1lbmNhcHMNCg0KVGhhbmtzIGZvciB0aGUgY2xh cmlmaWNhdGlvbiBvbiB0aGUgaW50ZW50IGFyb3VuZCBkcmFmdC1pZXRmLWJlc3MtZXZwbi1vdmVy bGF5LiBUaGVuIGluZGVlZCBzZWN0aW9uIDkgbmVlZHMgc29tZSB0aWR5aW5nIHVwLg0KDQpUaGUg aXNzdWUgdGhhdCBJIHRoaW5rIHJlbWFpbiBpcyB0aGF0IGl0IHdvdWxkIGJlIG11Y2ggY2xlYW5l ciB0byBleHBsYWluIGhvdyB0byB1c2UgUE1TSSB3aXRoIG92ZXJsYXkgZW5jYXBzIGluIGEgc3Bl YyBub3Qgc3BlY2lmaWMgdG8gRS1WUE4gYW5kIGluIGEgd2F5IG1vcmUgY29uc2lzdGVudCB0byB3 aGF0IGlzIGRvbmUgZm9yIHVuaWNhc3QuDQoNCkl0IHNlZW1zIGlmIGNvdXJzZSB0aGF0IGRyYWZ0 LWlldGYtaWRyLXR1bm5lbC1lbmNhcCBzaG91bGQgYmUgdGhlIHBsYWNlLCBidXQgdGhhdCBkb2N1 bWVudCBjdXJyZW50bHkgZXhwbGljaXRseSBtYWtlcyBQTVNJcyBvdXQgb2Ygc2NvcGUuDQoNClNo b3VsZG4ndCB0aGlzIHBhcnQgb2YgZHJhZnQtaWV0Zi1pZHItdHVubmVsLWVuY2FwIGJlIHJldmlz aXRlZCA/DQoNCi1UaG9tYXMNCg0KDQotLS0tIFJhYmFkYW4sIEpvcmdlIChOb2tpYSAtIFVTKSBh IMOpY3JpdCAtLS0tDQpGdWxseSBhZ3JlZSBKb2huLiBUaGF0J3Mgd2hhdCBJIG1lYW50LCBzb3Jy eSBpZiBJIGRpZG4ndCBtYWtlIG15c2VsZiBjbGVhci4gU2VjdGlvbiA5IG5lZWRzIGNsZWFuIHVw LCB5ZXMuDQpUaGFua3MsDQpKb3JnZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K RnJvbTogRVhUIEpvaG4gRSBEcmFrZSA8amRyYWtlQGp1bmlwZXIubmV0PG1haWx0bzpqZHJha2VA anVuaXBlci5uZXQ+Pg0KU2VudDogV2VkbmVzZGF5LCBNYXkgNCwgMjAxNiAyMzozNA0KU3ViamVj dDogUkU6IFtJZHJdIGRyYWZ0LWlldGYtYmVzcy1ldnBuLW92ZXJsYXkgdnMuIGRyYWZ0LWlldGYt aWRyLXR1bm5lbC1lbmNhcHMNClRvOiBJRFIgPGlkckBpZXRmLm9yZzxtYWlsdG86aWRyQGlldGYu b3JnPj4sIEFsaSBTYWphc3NpIChzYWphc3NpKSA8c2FqYXNzaUBjaXNjby5jb208bWFpbHRvOnNh amFzc2lAY2lzY28uY29tPj4sIFJhYmFkYW4sIEpvcmdlIChOb2tpYSAtIFVTKSA8am9yZ2UucmFi YWRhbkBhbGNhdGVsLWx1Y2VudC5jb208bWFpbHRvOmpvcmdlLnJhYmFkYW5AYWxjYXRlbC1sdWNl bnQuY29tPj4sIEJFU1MgPGJlc3NAaWV0Zi5vcmc8bWFpbHRvOmJlc3NAaWV0Zi5vcmc+PiwgPGRy YWZ0LWlldGYtYmVzcy1ldnBuLW92ZXJsYXlAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWll dGYtYmVzcy1ldnBuLW92ZXJsYXlAdG9vbHMuaWV0Zi5vcmc+PiwgRVhUIC0gdGhvbWFzLm1vcmlu QG9yYW5nZS5jb208bWFpbHRvOnRob21hcy5tb3JpbkBvcmFuZ2UuY29tPiA8dGhvbWFzLm1vcmlu QG9yYW5nZS5jb208bWFpbHRvOnRob21hcy5tb3JpbkBvcmFuZ2UuY29tPj4NCg0KDQpKb3JnZSwN Cg0KV2UgcHV0IHRoZSBWTkkgdmFsdWUgaW4gdGhlIE1QTFMgbGFiZWwgZmllbGQgb2YgdGhlIFBN U0kgYXR0cmlidXRlIGZvciBhbGwgc2VydmljZSB0eXBlcywgYW5kIHdlIHB1dCBhIHZhbHVlIGlu IHRoZSBFdGhlcm5ldCBUYWcgZmllbGQgZm9sbG93aW5nIHRoZSBydWxlcyBmb3IgZWFjaCBzZXJ2 aWNlIHR5cGUgYXMgZGVzY3JpYmVkIGluIDUuMS4zIChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1iZXNzLWV2cG4tb3ZlcmxheS0wMiNzZWN0aW9uLTUuMS4zKS4NCg0KWW91 J3JlIHJpZ2h0IHRoYXQgd2UgbmVlZCB0byBjbGVhbiB1cCBzZWN0aW9uIDkuDQoNCllvdXJzIEly cmVzcGVjdGl2ZWx5LA0KDQpKb2huDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogUmFiYWRhbiwgSm9yZ2UgKE5va2lhIC0gVVMpIFttYWlsdG86am9yZ2UucmFiYWRhbkBu b2tpYS5jb21dDQo+IFNlbnQ6IFdlZG5lc2RheSwgTWF5IDA0LCAyMDE2IDM6NTMgUE0NCj4gVG86 IEpvaG4gRSBEcmFrZTsgRVhUIC0gdGhvbWFzLm1vcmluQG9yYW5nZS5jb208bWFpbHRvOnRob21h cy5tb3JpbkBvcmFuZ2UuY29tPjsgQkVTUzsgSURSOyBkcmFmdC1pZXRmLWJlc3MtZXZwbi0NCj4g b3ZlcmxheUB0b29scy5pZXRmLm9yZzxtYWlsdG86b3ZlcmxheUB0b29scy5pZXRmLm9yZz47IEFs aSBTYWphc3NpIChzYWphc3NpKQ0KPiBTdWJqZWN0OiBSZTogW0lkcl0gZHJhZnQtaWV0Zi1iZXNz LWV2cG4tb3ZlcmxheSB2cy4gZHJhZnQtaWV0Zi1pZHItdHVubmVsLWVuY2Fwcw0KPg0KPiBIaSBK b2huLA0KPg0KPiBBYm91dCB0aGlzOg0KPg0KPiBbSkRdIEZvciB0aGUgSU1FVCByb3V0ZSB0aGUg TVBMUyBsYWJlbCBmaWVsZCBpcyBjYXJyaWVkIGluIHRoZSBQTVNJIGF0dHJpYnV0ZS4gSSB0aGlu ayB3ZSBuZWVkDQo+IHRvIGFzayBldmVyeW9uZSB3aGV0aGVyIHRoZXkgdXNlZCB0aGUgRXRoZXJu ZXQgVGFnIG9yIHRoZSBQTVNJIGF0dHJpYnV0ZSB0byBjYXJyeSB0aGUgVk5JDQo+DQo+DQo+IElu IGNhc2UgaXQgaGVscHMsIEnigJl2ZSBzZWVuIGEgZmV3IGltcGxlbWVudGF0aW9ucyBydW5uaW5n IGFuZCB0aGV5IGFsbCBlbmNvZGUgdGhlIFZOSSBpbiB0aGUNCj4gTVBMUyBsYWJlbCBmaWVsZCBp biB0aGUgUFRBLiBBbmQgYSBjb3VwbGUgb2YgdGhlbSwgZW5jb2RlIHRoZSBWTkkgaW4gdGhlIGV0 aGVybmV0LXRhZywgaW4NCj4gYWRkaXRpb24gdG8gdGhlIE1QTFMgbGFiZWwgaW4gdGhlIFBUQS4g SW4gYW55IGNhc2UsIEkgdGhpbmsgc2VjdGlvbiA5IGNvbnRyYWRpY3RzIHNlY3Rpb24gNS4xLjMN Cj4gYW5kIHNob3VsZCBiZSBjbGFyaWZpZWQuDQo+DQo+ICI1LjEuMyBDb25zdHJ1Y3RpbmcgRVZQ TiBCR1AgUm91dGVzDQo+IDxzbmlwPg0KPiB0aGUgTVBMUyBsYWJlbCBmaWVsZCBpbiB0aGUgTUFD IEFkdmVydGlzZW1lbnQsIEV0aGVybmV0IEFEIHBlciBFVkksIGFuZCAqKkluY2x1c2l2ZQ0KPiBN dWx0aWNhc3QgRXRoZXJuZXQgVGFnKiogcm91dGVzIGlzIHVzZWQgdG8gY2FycnkgdGhlIFZOSSBv ciBWU0lELiINCj4NCj4gVGhhbmtzLg0KPiBKb3JnZQ0KPg0KPg0KPg0KPg0KPg0KPiBPbiA1LzQv MTYsIDg6MzQgUE0sICJFWFQgSm9obiBFIERyYWtlIiA8amRyYWtlQGp1bmlwZXIubmV0PG1haWx0 bzpqZHJha2VAanVuaXBlci5uZXQ+PiB3cm90ZToNCj4NCj4gPlRob21hcyBhbmQgSm9yZ2UsDQo+ ID4NCj4gPlNuaXBwZWQsIGNvbW1lbnRzIGlubGluZS4NCj4gPg0KPiA+WW91cnMgSXJyZXNwZWN0 aXZlbHksDQo+ID4NCj4gPkpvaG4NCj4gPg0KPiA+PiA+DQo+ID4+ID5kcmFmdC1pZXRmLWJlc3Mt ZXZwbi1vdmVybGF5IChzZWUgc2VjdGlvbiA5KSByZWxpZXMgb24gdGhlIEJHUA0KPiA+PiA+RW5j YXBzdWxhdGlvbiBleHRlbmRlZCB0byBlbmNvZGUgdGhlIHR1bm5lbCBlbmNhcCB0byB1c2UgZm9y IEJVTQ0KPiA+PiA+dHJhZmZpYywgYnV0IGNvbnRyYXJ5IHRvIG90aGVyIEUtVlBOIHJvdXRlcywg cmVsaWVzIG9uIHRoZSBFdGhlcm5ldA0KPiA+PiA+VGFnIGZpZWxkIG9mIHRoZSBOTFJJIHRvIGVu Y29kZSB0aGUgVk5JL1ZTSUQuDQo+ID4+DQo+ID4+IFtKT1JHRV0gVGhpcyBpcyBjZXJ0YWlubHkg YSBsZWZ0b3ZlciBmcm9tIGFuIG9sZCB2ZXJzaW9uIHdoZXJlIHRoZQ0KPiA+PiBWTkkvVlNJRCB3 YXMgZW5jb2RlZCBpbiB0aGUgZXRoZXJuZXQgdGFnIGZvciBhbGwgdGhlIHJvdXRlcy4gVGhlIFZO SQ0KPiA+PiBzaG91bGQgYmUgZW5jb2RlZCBpbiB0aGUgTGFiZWwgZmllbGQgaW4gYWxsIHRoZSBy b3V0ZXMuIFRoaXMgaGFzIHRvIGJlIGNvcnJlY3RlZC4NCj4gPj4NCj4gPj4gSW4gZmFjdCwgc2Vj dGlvbiA1LjEuMyBzYXlzOg0KPiA+Pg0KPiA+PiA1LjEuMyBDb25zdHJ1Y3RpbmcgRVZQTiBCR1Ag Um91dGVzDQo+ID4+DQo+ID4+IDxzbmlwPg0KPiA+Pg0KPiA+PiBBY2NvcmRpbmdseSwgYW5kDQo+ ID4+IHNwZWNpZmljYWxseSB0byBzdXBwb3J0IHRoZSBvcHRpb24gb2YgbG9jYWxseSBhc3NpZ25l ZCBWTklzLCB0aGUgTVBMUw0KPiA+PiBsYWJlbCBmaWVsZCBpbiB0aGUgTUFDIEFkdmVydGlzZW1l bnQsIEV0aGVybmV0IEFEIHBlciBFVkksIGFuZA0KPiA+PiBJbmNsdXNpdmUgTXVsdGljYXN0IEV0 aGVybmV0IFRhZyByb3V0ZXMgaXMgdXNlZCB0byBjYXJyeSB0aGUgVk5JIG9yDQo+ID4+IFZTSUQu IEZvciB0aGUgYmFsYW5jZSBvZiB0aGlzIG1lbW8sIHRoZSBNUExTIGxhYmVsIGZpZWxkIHdpbGwg YmUNCj4gPj4gcmVmZXJyZWQgdG8gYXMgdGhlIFZOSS9WU0lEIGZpZWxkLiBUaGUgVk5JL1ZTSUQg ZmllbGQgaXMgdXNlZCBmb3INCj4gPj4gYm90aCBsb2NhbCBhbmQgZ2xvYmFsIFZOSXMvVlNJRHMs IGFuZCBmb3IgZWl0aGVyIGNhc2UgdGhlIGVudGlyZSAyNC0NCj4gPj4gYml0IGZpZWxkIGlzIHVz ZWQgdG8gZW5jb2RlIHRoZSBWTkkvVlNJRCB2YWx1ZS4NCj4gPj4NCj4gPj4gPHNuaXA+DQo+ID4N Cj4gPg0KPiA+W0pEXSBGb3IgdGhlIElNRVQgcm91dGUgdGhlIE1QTFMgbGFiZWwgZmllbGQgaXMg Y2FycmllZCBpbiB0aGUgUE1TSSBhdHRyaWJ1dGUuIEkgdGhpbmsgd2UNCj4gbmVlZCB0byBhc2sg ZXZlcnlvbmUgd2hldGhlciB0aGV5DQo+ID51c2VkIHRoZSBFdGhlcm5ldCBUYWcgb3IgdGhlIFBN U0kgYXR0cmlidXRlIHRvIGNhcnJ5IHRoZSBWTkkNCj4gPg0KPiA+DQo+ID4+ID4+DQo+ID4+ID4+ IFRoZXJlIGFyZSBtaW5vciB0aGluZ3MgdGhhdCBjb3VsZCBiZSBpbXByb3ZlZCBpbg0KPiA+PiA+ PiBkcmFmdC1pZXRmLWJlc3MtZXZwbi1vdmVybGF5IHdydC4gY29uc2lzdGVuY3kgd2l0aA0KPiA+ PiA+PiBkcmFmdC1pZXRmLWlkci10dW5uZWwtZW5jYXBzIDoNCj4gPj4gPj4NCj4gPj4gPj4gKiBz aW5jZSBkcmFmdC1pZXRmLWlkci10dW5uZWwtZW5jYXBzIHdpbGwgZGVwcmVjYXRlIFJGQzU1MTIs IGl0DQo+ID4+ID4+IHdvdWxkIGJlIGJldHRlciB0aGF0IGRyYWZ0LWlldGYtYmVzcy1ldnBuLW92 ZXJsYXkgcmVmZXJzIHRvDQo+ID4+ID4+IGRyYWZ0LWlldGYtaWRyLXR1bm5lbC1lbmNhcHMgYW5k IG5vdCBhbnltb3JlIHRvIFJGQzU1MTIuDQo+ID4+DQo+ID4+IFtKT1JHRV0gSSBhZ3JlZSwgYXMg bG9uZyBhcyBkcmFmdC1pZXRmLWlkci10dW5uZWwtZW5jYXBzIGtlZXBzIHRoZQ0KPiA+PiBlbmNh cHN1bGF0aW9uIGV4dGVuZGVkIGNvbW11bml0eS4gVGhlcmUgYXJlIGEgZmV3IGltcGxlbWVudGF0 aW9ucw0KPiA+PiB1c2luZyB0aGlzIGNvbW11bml0eSBhbmQgaXQgaXMgZW5vdWdoIHdoZW4gb25s eSB0aGUgZW5jYXBzdWxhdGlvbiB0eXBlIGlzIG5lZWRlZC4NCj4gPg0KPiA+DQo+ID5bSkRdIEkg YWdyZWUgYW5kIHRoZSB0dW5uZWwgZW5jYXBzIGRyYWZ0IGRvZXMga2VlcCB0aGUgRUMNCj4gPg0K PiA+DQo+ID4+DQo+ID4+ID4+DQo+ID4+ID4+ICogSSB0aGluayBpdCB3b3VsZCBiZSBiZXR0ZXIg dG8gYXZvaWQgdGhlIGV4cGxpY2l0IGxpc3Qgb2YgZW5jYXANCj4gPj4gPj4gdHlwZXMgaW4gc2Vj dGlvbiA1LjEuMywgYW5kIHJhdGhlciByZWZlciB0bw0KPiA+PiA+PiBkcmFmdC1pZXRmLWlkci10 dW5uZWwtZW5jYXBzIGluc3RlYWQNCj4gPj4NCj4gPj4gW0pPUkdFXSBJIGFncmVlLg0KPiA+DQo+ ID4NCj4gPltKRF0gQWNjb3JkaW5nIHRvIElBTkEsIGl0IGFsbG9jYXRlZCB0aGUgZml2ZSB0dW5u ZWxzIHR5cGVzIHRvIHRoZQ0KPiA+b3ZlcmxheSBkcmFmdCBzbyBJIHRoaW5rIHdlIG5lZWQgdG8g a2VlcCB0aGVtDQo+ID4NCj4gPg0KPiA+Pg0KPiA+PiA+PiAqIHRoZSBmb2xsb3dpbmcgbWlub3Ig bW9kaWZpY2F0aW9uIHdhcyBwcm9wb3NlZCwgYnV0IG5vdCB5ZXQgaW5jb3Jwb3JhdGVkOg0KPiA+ PiA+Pg0KPiA+PiA+PiBKb2huIERyYWtlLCAyMDE1LTExLTEzICh0byBCRVNTIE1MKToNCj4gPj4g Pj4+IEZvciB0aGUgb3ZlcmxheSBkcmFmdCwgcmVwbGFjZSB0aGlzIHRleHQgaW4gc2VjdGlvbiA1 LjEuMzoNCj4gPj4gPj4+DQo+ID4+ID4+PiAiSWYgdGhlIEJHUCBFbmNhcHN1bGF0aW9uIGV4dGVu ZGVkIGNvbW11bml0eSBpcyBub3QgcHJlc2VudCwNCj4gPj4gPj4+IHRoZW4gdGhlIGRlZmF1bHQg TVBMUyBlbmNhcHN1bGF0aW9uIG9yIGEgc3RhdGljYWxseSBjb25maWd1cmVkDQo+ID4+ID4+PiBl bmNhcHN1bGF0aW9uIGlzIGFzc3VtZWQuIg0KPiA+PiA+Pj4NCj4gPj4gPj4+IFdpdGggdGhlIGZv bGxvd2luZzoNCj4gPj4gPj4+DQo+ID4+ID4+PiAiTm90ZSB0aGF0IHRoZSBNUExTIGVuY2Fwc3Vs YXRpb24gdHVubmVsIHR5cGUgaXMgbmVlZGVkIGluDQo+ID4+ID4+PiBvcmRlciB0byBkaXN0aW5n dWlzaCBiZXR3ZWVuIGFuIGFkdmVydGlzaW5nIG5vZGUgdGhhdCBvbmx5DQo+ID4+ID4+PiBzdXBw b3J0cyBub24tTVBMUyBlbmNhcHN1bGF0aW9ucyBhbmQgb25lIHRoYXQgc3VwcG9ydHMgTVBMUyBh bmQNCj4gPj4gPj4+IG5vbi1NUExTIGVuY2Fwc3VsYXRpb25zLiBBbiBhZHZlcnRpc2luZyBub2Rl IHRoYXQgb25seSBzdXBwb3J0cw0KPiA+PiA+Pj4gTVBMUyBlbmNhcHN1bGF0aW9uIGRvZXMgbm90 IG5lZWQgdG8gYWR2ZXJ0aXNlIGFueSBlbmNhcHN1bGF0aW9uDQo+ID4+ID4+PiB0dW5uZWwgdHlw ZXM7IGkuZS4sIGlmIHRoZSBCR1AgRW5jYXBzdWxhdGlvbiBleHRlbmRlZCBjb21tdW5pdHkNCj4g Pj4gPj4+IGlzIG5vdCBwcmVzZW50LCB0aGVuIGVpdGhlciBNUExTIGVuY2Fwc3VsYXRpb24gb3Ig YSBzdGF0aWNhbGx5DQo+ID4+ID4+PiBjb25maWd1cmVkIGVuY2Fwc3VsYXRpb24gaXMgYXNzdW1l ZC4iDQo+ID4+ID4+DQo+ID4+ID4+IEkgdGhpbmsgdGhpcyBjaGFuZ2UgaXMgdXNlZnVsIGFuZCBz aG91bGQgYmUgaW5jb3Jwb3JhdGVkLCBhbHRob3VnaA0KPiA+PiA+PiBza2lwcGluZyB0aGUgbGFz dCBzZW50ZW5jZSB3b3VsZCBiZSB3aXNlIGlmIHRoZSBmdWxsIGxpc3Qgb2YNCj4gPj4gPj4gdHVu bmVsIHR5cGVzIGlzIHJlbW92ZWQuDQo+ID4NCj4gPg0KPiA+W0pEXSBGaW5lIHdpdGggbWUgZWl0 aGVyIHcvIG9yIHcvbyB0aGUgbGFzdCBzZW50ZW5jZQ0KPiA+DQo+ID4NCg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoN Cg0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRl cyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2 ZW50IGRvbmMNCg0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBh dXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1 aWxsZXogbGUgc2lnbmFsZXINCg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kg cXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQg c3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCg0KT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9u c2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUu IE1lcmNpLg0KDQoNCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRh aW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJv dGVjdGVkIGJ5IGxhdzsNCg0KdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9y IGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQoNCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRo aXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVy ZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2Rp ZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQoNClRoYW5rIHlvdS4NCg== --_000_C34C65F6323049E3B3AAC488A9154943alcatellucentcom_ Content-Type: text/html; charset="utf-8" Content-ID: <410C8EF0AB7FEA41AE25903C61D2767C@exchange.lucent.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx M3B4OyBmb250LWZhbWlseTogJ05va2lhIFB1cmUgVGV4dCcsIHNhbnMtc2VyaWY7Ij4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj5JIGFncmVlIHdpdGggSm9obi48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2PlRoYW5rcy48L2Rpdj4NCjxkaXY+Sm9yZ2U8L2Rpdj4NCjxkaXY+DQo8ZGl2IGlkPSJN QUNfT1VUTE9PS19TSUdOQVRVUkUiPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2Pg0K PGRpdj5PbiA1LzUvMTYsIDI6NTcgUE0sICZxdW90O0VYVCBKb2huIEUgRHJha2UmcXVvdDsgJmx0 OzxhIGhyZWY9Im1haWx0bzpqZHJha2VAanVuaXBlci5uZXQiPmpkcmFrZUBqdW5pcGVyLm5ldDwv YT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+DQo8YmxvY2txdW90ZSBpZD0iTUFD X09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVj NGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXYgeG1s bnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVybjpzY2hlbWFz LW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNv bS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0 bWw0MCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDE1 IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICov DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIg NCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0K CXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFt ZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8ZGl2IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhvbWFzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlIG92ZXJsYXkgZHJhZnQgcHJlY2VkZWQgdGhlIHR1bm5l bCBlbmNhcHMgZHJhZnQgYW5kIGl0IHdhcyBkZXNpZ25lZCB0byBoYW5kbGUgYSB2ZXJ5IHNwZWNp ZmljIHByb2JsZW0sIG1hcnJ5aW5nIHRoZSBFVlBOIGNvbnRyb2wgcGxhbmUgdG8gdGhlIFZYTEFO IGRhdGEgcGxhbmUNCiBkcmFmdCBhbmQgbW9kdWxvIHRoZSBjb3JyZWN0aW9uIHRvIHNlY3Rpb24g OSBpdCBpcyBpbnRlcm5hbGx5IGNvbnNpc3RlbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5UaGUgdHVubmVsIGVuY2FwcyBkcmFmdCBzb2x2ZXMgYSBtb3JlIGdl bmVyYWwgcHJvYmxlbSBhbmQgdGhlIFdHIGRlY2lkZWQgYSBsb25nIHRpbWUgYWdvIHRoYXQgdGhl IG92ZXJsYXkgZHJhZnQgd2FzIG5vdCBnb2luZyB0byBiZSB1cGRhdGVkIHRvIHVzZSB0aGUgbWVj aGFuaXNtcw0KIGl0IGRldGFpbHMgZm9yIHVuaWNhc3QsIHNvIHRoZSBvdmVybGF5IGRyYWZ0IGlz IGFscmVhZHkgZXhwbGljaXRseSBub3QgaW4gYWxpZ25tZW50IHdpdGggaXQuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGlzLCBwbHVzIHRoZSBmYWN0IHRoYXQg dGhlIHR1bm5lbCBlbmNhcHMgZHJhZnQgZXhwbGljaXRseSBwdXRzIHRoZSBQTVNJIG91dCBvZiBz Y29wZSwgbGVhZHMgbWUgdG8gdGhlIGNvbmNsdXNpb24gdGhhdCB0aGUgb3ZlcmxheSBkcmFmdCBz aG91bGQgbm90IGJlIHR3ZWFrZWQNCiB0byBiZSBpbiBhbGlnbm1lbnQgd2l0aCBhIGZ1dHVyZSBz b2x1dGlvbiBmb3IgZW5jb2RpbmcgVk5JcyBmb3IgbXVsdGljYXN0LiA8bzpwPg0KPC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPllvdXJzIElycmVzcGVjdGl2ZWx5 LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Sm9objxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4g MGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4NCjxhIGhyZWY9Im1haWx0bzp0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbSI+dGhv bWFzLm1vcmluQG9yYW5nZS5jb208L2E+IFs8YSBocmVmPSJtYWlsdG86dGhvbWFzLm1vcmluQG9y YW5nZS5jb20iPm1haWx0bzp0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbTwvYT5dDQo8YnI+DQo8Yj5T ZW50OjwvYj4gVGh1cnNkYXksIE1heSAwNSwgMjAxNiA4OjMyIEFNPGJyPg0KPGI+VG86PC9iPiBK b2huIEUgRHJha2U7IElEUjsgQkVTUzsgPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtYmVzcy1l dnBuLW92ZXJsYXlAdG9vbHMuaWV0Zi5vcmciPg0KZHJhZnQtaWV0Zi1iZXNzLWV2cG4tb3Zlcmxh eUB0b29scy5pZXRmLm9yZzwvYT47IEFsaSBTYWphc3NpIChzYWphc3NpKTsgUmFiYWRhbiwgSm9y Z2UgKE5va2lhIC0gVVMpOw0KPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtaWRyLXR1bm5lbC1l bmNhcEB0b29scy5pZXRmLm9yZyI+ZHJhZnQtaWV0Zi1pZHItdHVubmVsLWVuY2FwQHRvb2xzLmll dGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW0lkcl0gZHJhZnQtaWV0Zi1iZXNz LWV2cG4tb3ZlcmxheSB2cy4gZHJhZnQtaWV0Zi1pZHItdHVubmVsLWVuY2FwczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+VGhhbmtzIGZvciB0aGUgY2xhcmlmaWNhdGlvbiBvbiB0aGUgaW50ZW50IGFyb3Vu ZCBkcmFmdC1pZXRmLWJlc3MtZXZwbi1vdmVybGF5LiBUaGVuIGluZGVlZCBzZWN0aW9uIDkgbmVl ZHMgc29tZSB0aWR5aW5nIHVwLg0KPGJyPg0KPGJyPg0KVGhlIGlzc3VlIHRoYXQgSSB0aGluayBy ZW1haW4gaXMgdGhhdCBpdCB3b3VsZCBiZSBtdWNoIGNsZWFuZXIgdG8gZXhwbGFpbiBob3cgdG8g dXNlIFBNU0kgd2l0aCBvdmVybGF5IGVuY2FwcyBpbiBhIHNwZWMgbm90IHNwZWNpZmljIHRvIEUt VlBOIGFuZCBpbiBhIHdheSBtb3JlIGNvbnNpc3RlbnQgdG8gd2hhdCBpcyBkb25lIGZvciB1bmlj YXN0Lg0KPGJyPg0KPGJyPg0KSXQgc2VlbXMgaWYgY291cnNlIHRoYXQgZHJhZnQtaWV0Zi1pZHIt dHVubmVsLWVuY2FwIHNob3VsZCBiZSB0aGUgcGxhY2UsIGJ1dCB0aGF0IGRvY3VtZW50IGN1cnJl bnRseSBleHBsaWNpdGx5IG1ha2VzIFBNU0lzIG91dCBvZiBzY29wZS4NCjxicj4NCjxicj4NClNo b3VsZG4ndCB0aGlzIHBhcnQgb2YgZHJhZnQtaWV0Zi1pZHItdHVubmVsLWVuY2FwIGJlIHJldmlz aXRlZCA/IDxicj4NCjxicj4NCi1UaG9tYXM8YnI+DQo8YnI+DQo8YnI+DQotLS0tIFJhYmFkYW4s IEpvcmdlIChOb2tpYSAtIFVTKSBhIMOpY3JpdCAtLS0tPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdiBpZD0iY29tcG9zZSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij5GdWxseSBhZ3JlZSBKb2huLiBUaGF0J3Mgd2hhdCBJIG1lYW50 LCBzb3JyeSBpZiBJIGRpZG4ndCBtYWtlIG15c2VsZiBjbGVhci4gU2VjdGlvbiA5IG5lZWRzIGNs ZWFuIHVwLCB5ZXMuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhhbmtzLDxicj4NCkpvcmdlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KRnJvbTogRVhUIEpvaG4gRSBEcmFrZSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmpkcmFrZUBqdW5pcGVyLm5ldCI+amRyYWtlQGp1bmlwZXIubmV0PC9hPiZndDs8 YnI+DQpTZW50OiBXZWRuZXNkYXksIE1heSA0LCAyMDE2IDIzOjM0PGJyPg0KU3ViamVjdDogUkU6 IFtJZHJdIGRyYWZ0LWlldGYtYmVzcy1ldnBuLW92ZXJsYXkgdnMuIGRyYWZ0LWlldGYtaWRyLXR1 bm5lbC1lbmNhcHM8YnI+DQpUbzogSURSICZsdDs8YSBocmVmPSJtYWlsdG86aWRyQGlldGYub3Jn Ij5pZHJAaWV0Zi5vcmc8L2E+Jmd0OywgQWxpIFNhamFzc2kgKHNhamFzc2kpICZsdDs8YSBocmVm PSJtYWlsdG86c2FqYXNzaUBjaXNjby5jb20iPnNhamFzc2lAY2lzY28uY29tPC9hPiZndDssIFJh YmFkYW4sIEpvcmdlIChOb2tpYSAtIFVTKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpvcmdlLnJhYmFk YW5AYWxjYXRlbC1sdWNlbnQuY29tIj5qb3JnZS5yYWJhZGFuQGFsY2F0ZWwtbHVjZW50LmNvbTwv YT4mZ3Q7LA0KIEJFU1MgJmx0OzxhIGhyZWY9Im1haWx0bzpiZXNzQGlldGYub3JnIj5iZXNzQGll dGYub3JnPC9hPiZndDssICZsdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1iZXNzLWV2cG4t b3ZlcmxheUB0b29scy5pZXRmLm9yZyI+ZHJhZnQtaWV0Zi1iZXNzLWV2cG4tb3ZlcmxheUB0b29s cy5pZXRmLm9yZzwvYT4mZ3Q7LCBFWFQgLQ0KPGEgaHJlZj0ibWFpbHRvOnRob21hcy5tb3JpbkBv cmFuZ2UuY29tIj50aG9tYXMubW9yaW5Ab3JhbmdlLmNvbTwvYT4gJmx0OzxhIGhyZWY9Im1haWx0 bzp0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbSI+dGhvbWFzLm1vcmluQG9yYW5nZS5jb208L2E+Jmd0 Ozxicj4NCjxicj4NCjxicj4NCkpvcmdlLDxicj4NCjxicj4NCldlIHB1dCB0aGUgVk5JIHZhbHVl IGluIHRoZSBNUExTIGxhYmVsIGZpZWxkIG9mIHRoZSBQTVNJIGF0dHJpYnV0ZSBmb3IgYWxsIHNl cnZpY2UgdHlwZXMsIGFuZCB3ZSBwdXQgYSB2YWx1ZSBpbiB0aGUgRXRoZXJuZXQgVGFnIGZpZWxk IGZvbGxvd2luZyB0aGUgcnVsZXMgZm9yIGVhY2ggc2VydmljZSB0eXBlIGFzIGRlc2NyaWJlZCBp biA1LjEuMyAoPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt YmVzcy1ldnBuLW92ZXJsYXktMDIjc2VjdGlvbi01LjEuMyI+aHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtYmVzcy1ldnBuLW92ZXJsYXktMDIjc2VjdGlvbi01LjEuMzwvYT4p Ljxicj4NCjxicj4NCllvdSdyZSByaWdodCB0aGF0IHdlIG5lZWQgdG8gY2xlYW4gdXAgc2VjdGlv biA5Ljxicj4NCjxicj4NCllvdXJzIElycmVzcGVjdGl2ZWx5LDxicj4NCjxicj4NCkpvaG48YnI+ DQo8YnI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyBGcm9tOiBS YWJhZGFuLCBKb3JnZSAoTm9raWEgLSBVUykgWzxhIGhyZWY9Im1haWx0bzpqb3JnZS5yYWJhZGFu QG5va2lhLmNvbSI+bWFpbHRvOmpvcmdlLnJhYmFkYW5Abm9raWEuY29tPC9hPl08YnI+DQomZ3Q7 IFNlbnQ6IFdlZG5lc2RheSwgTWF5IDA0LCAyMDE2IDM6NTMgUE08YnI+DQomZ3Q7IFRvOiBKb2hu IEUgRHJha2U7IEVYVCAtIDxhIGhyZWY9Im1haWx0bzp0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbSI+ dGhvbWFzLm1vcmluQG9yYW5nZS5jb208L2E+OyBCRVNTOyBJRFI7IGRyYWZ0LWlldGYtYmVzcy1l dnBuLTxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOm92ZXJsYXlAdG9vbHMuaWV0Zi5vcmciPm92 ZXJsYXlAdG9vbHMuaWV0Zi5vcmc8L2E+OyBBbGkgU2FqYXNzaSAoc2FqYXNzaSk8YnI+DQomZ3Q7 IFN1YmplY3Q6IFJlOiBbSWRyXSBkcmFmdC1pZXRmLWJlc3MtZXZwbi1vdmVybGF5IHZzLiBkcmFm dC1pZXRmLWlkci10dW5uZWwtZW5jYXBzPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEhpIEpvaG4sPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IEFib3V0IHRoaXM6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFtKRF0g Rm9yIHRoZSBJTUVUIHJvdXRlIHRoZSBNUExTIGxhYmVsIGZpZWxkIGlzIGNhcnJpZWQgaW4gdGhl IFBNU0kgYXR0cmlidXRlLiBJIHRoaW5rIHdlIG5lZWQ8YnI+DQomZ3Q7IHRvIGFzayBldmVyeW9u ZSB3aGV0aGVyIHRoZXkgdXNlZCB0aGUgRXRoZXJuZXQgVGFnIG9yIHRoZSBQTVNJIGF0dHJpYnV0 ZSB0byBjYXJyeSB0aGUgVk5JPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgSW4gY2Fz ZSBpdCBoZWxwcywgSeKAmXZlIHNlZW4gYSBmZXcgaW1wbGVtZW50YXRpb25zIHJ1bm5pbmcgYW5k IHRoZXkgYWxsIGVuY29kZSB0aGUgVk5JIGluIHRoZTxicj4NCiZndDsgTVBMUyBsYWJlbCBmaWVs ZCBpbiB0aGUgUFRBLiBBbmQgYSBjb3VwbGUgb2YgdGhlbSwgZW5jb2RlIHRoZSBWTkkgaW4gdGhl IGV0aGVybmV0LXRhZywgaW48YnI+DQomZ3Q7IGFkZGl0aW9uIHRvIHRoZSBNUExTIGxhYmVsIGlu IHRoZSBQVEEuIEluIGFueSBjYXNlLCBJIHRoaW5rIHNlY3Rpb24gOSBjb250cmFkaWN0cyBzZWN0 aW9uIDUuMS4zPGJyPg0KJmd0OyBhbmQgc2hvdWxkIGJlIGNsYXJpZmllZC48YnI+DQomZ3Q7IDxi cj4NCiZndDsgJnF1b3Q7NS4xLjMgQ29uc3RydWN0aW5nIEVWUE4gQkdQIFJvdXRlczxicj4NCiZn dDsgJmx0O3NuaXAmZ3Q7PGJyPg0KJmd0OyB0aGUgTVBMUyBsYWJlbCBmaWVsZCBpbiB0aGUgTUFD IEFkdmVydGlzZW1lbnQsIEV0aGVybmV0IEFEIHBlciBFVkksIGFuZCAqKkluY2x1c2l2ZTxicj4N CiZndDsgTXVsdGljYXN0IEV0aGVybmV0IFRhZyoqIHJvdXRlcyBpcyB1c2VkIHRvIGNhcnJ5IHRo ZSBWTkkgb3IgVlNJRC4mcXVvdDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhhbmtzLjxicj4NCiZn dDsgSm9yZ2U8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4N CiZndDsgPGJyPg0KJmd0OyBPbiA1LzQvMTYsIDg6MzQgUE0sICZxdW90O0VYVCBKb2huIEUgRHJh a2UmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpqZHJha2VAanVuaXBlci5uZXQiPmpkcmFrZUBq dW5pcGVyLm5ldDwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7VGhvbWFz IGFuZCBKb3JnZSw8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDtTbmlwcGVkLCBjb21tZW50 cyBpbmxpbmUuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7WW91cnMgSXJyZXNwZWN0aXZl bHksPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Sm9objxicj4NCiZndDsgJmd0Ozxicj4N CiZndDsgJmd0OyZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZndDsgJmd0O2RyYWZ0LWlldGYtYmVz cy1ldnBuLW92ZXJsYXkgKHNlZSBzZWN0aW9uIDkpIHJlbGllcyBvbiB0aGUgQkdQPGJyPg0KJmd0 OyAmZ3Q7Jmd0OyAmZ3Q7RW5jYXBzdWxhdGlvbiBleHRlbmRlZCB0byBlbmNvZGUgdGhlIHR1bm5l bCBlbmNhcCB0byB1c2UgZm9yIEJVTTxicj4NCiZndDsgJmd0OyZndDsgJmd0O3RyYWZmaWMsIGJ1 dCBjb250cmFyeSB0byBvdGhlciBFLVZQTiByb3V0ZXMsIHJlbGllcyBvbiB0aGUgRXRoZXJuZXQ8 YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDtUYWcgZmllbGQgb2YgdGhlIE5MUkkgdG8gZW5jb2RlIHRo ZSBWTkkvVlNJRC48YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBbSk9SR0Vd IFRoaXMgaXMgY2VydGFpbmx5IGEgbGVmdG92ZXIgZnJvbSBhbiBvbGQgdmVyc2lvbiB3aGVyZSB0 aGU8YnI+DQomZ3Q7ICZndDsmZ3Q7IFZOSS9WU0lEIHdhcyBlbmNvZGVkIGluIHRoZSBldGhlcm5l dCB0YWcgZm9yIGFsbCB0aGUgcm91dGVzLiBUaGUgVk5JPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBzaG91 bGQgYmUgZW5jb2RlZCBpbiB0aGUgTGFiZWwgZmllbGQgaW4gYWxsIHRoZSByb3V0ZXMuIFRoaXMg aGFzIHRvIGJlIGNvcnJlY3RlZC48YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0 OyBJbiBmYWN0LCBzZWN0aW9uIDUuMS4zIHNheXM6PGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZn dDsgJmd0OyZndDsgNS4xLjMgQ29uc3RydWN0aW5nIEVWUE4gQkdQIFJvdXRlczxicj4NCiZndDsg Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZsdDtzbmlwJmd0Ozxicj4NCiZndDsgJmd0OyZn dDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IEFjY29yZGluZ2x5LCBhbmQ8YnI+DQomZ3Q7ICZndDsmZ3Q7 IHNwZWNpZmljYWxseSB0byBzdXBwb3J0IHRoZSBvcHRpb24gb2YgbG9jYWxseSBhc3NpZ25lZCBW TklzLCB0aGUgTVBMUzxicj4NCiZndDsgJmd0OyZndDsgbGFiZWwgZmllbGQgaW4gdGhlIE1BQyBB ZHZlcnRpc2VtZW50LCBFdGhlcm5ldCBBRCBwZXIgRVZJLCBhbmQ8YnI+DQomZ3Q7ICZndDsmZ3Q7 IEluY2x1c2l2ZSBNdWx0aWNhc3QgRXRoZXJuZXQgVGFnIHJvdXRlcyBpcyB1c2VkIHRvIGNhcnJ5 IHRoZSBWTkkgb3I8YnI+DQomZ3Q7ICZndDsmZ3Q7IFZTSUQuIEZvciB0aGUgYmFsYW5jZSBvZiB0 aGlzIG1lbW8sIHRoZSBNUExTIGxhYmVsIGZpZWxkIHdpbGwgYmU8YnI+DQomZ3Q7ICZndDsmZ3Q7 IHJlZmVycmVkIHRvIGFzIHRoZSBWTkkvVlNJRCBmaWVsZC4gVGhlIFZOSS9WU0lEIGZpZWxkIGlz IHVzZWQgZm9yPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBib3RoIGxvY2FsIGFuZCBnbG9iYWwgVk5Jcy9W U0lEcywgYW5kIGZvciBlaXRoZXIgY2FzZSB0aGUgZW50aXJlIDI0LTxicj4NCiZndDsgJmd0OyZn dDsgYml0IGZpZWxkIGlzIHVzZWQgdG8gZW5jb2RlIHRoZSBWTkkvVlNJRCB2YWx1ZS48YnI+DQom Z3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmbHQ7c25pcCZndDs8YnI+DQomZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDtbSkRdIEZvciB0aGUgSU1FVCByb3V0ZSB0 aGUgTVBMUyBsYWJlbCBmaWVsZCBpcyBjYXJyaWVkIGluIHRoZSBQTVNJIGF0dHJpYnV0ZS4gSSB0 aGluayB3ZTxicj4NCiZndDsgbmVlZCB0byBhc2sgZXZlcnlvbmUgd2hldGhlciB0aGV5PGJyPg0K Jmd0OyAmZ3Q7dXNlZCB0aGUgRXRoZXJuZXQgVGFnIG9yIHRoZSBQTVNJIGF0dHJpYnV0ZSB0byBj YXJyeSB0aGUgVk5JPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgJmd0OyZndDsgVGhlcmUgYXJlIG1pbm9y IHRoaW5ncyB0aGF0IGNvdWxkIGJlIGltcHJvdmVkIGluPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyBkcmFmdC1pZXRmLWJlc3MtZXZwbi1vdmVybGF5IHdydC4gY29uc2lzdGVuY3kgd2l0aDxi cj4NCiZndDsgJmd0OyZndDsgJmd0OyZndDsgZHJhZnQtaWV0Zi1pZHItdHVubmVsLWVuY2FwcyA6 PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgJmd0OyZndDsg KiBzaW5jZSBkcmFmdC1pZXRmLWlkci10dW5uZWwtZW5jYXBzIHdpbGwgZGVwcmVjYXRlIFJGQzU1 MTIsIGl0PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyB3b3VsZCBiZSBiZXR0ZXIgdGhhdCBk cmFmdC1pZXRmLWJlc3MtZXZwbi1vdmVybGF5IHJlZmVycyB0bzxicj4NCiZndDsgJmd0OyZndDsg Jmd0OyZndDsgZHJhZnQtaWV0Zi1pZHItdHVubmVsLWVuY2FwcyBhbmQgbm90IGFueW1vcmUgdG8g UkZDNTUxMi48YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBbSk9SR0VdIEkg YWdyZWUsIGFzIGxvbmcgYXMgZHJhZnQtaWV0Zi1pZHItdHVubmVsLWVuY2FwcyBrZWVwcyB0aGU8 YnI+DQomZ3Q7ICZndDsmZ3Q7IGVuY2Fwc3VsYXRpb24gZXh0ZW5kZWQgY29tbXVuaXR5LiBUaGVy ZSBhcmUgYSBmZXcgaW1wbGVtZW50YXRpb25zPGJyPg0KJmd0OyAmZ3Q7Jmd0OyB1c2luZyB0aGlz IGNvbW11bml0eSBhbmQgaXQgaXMgZW5vdWdoIHdoZW4gb25seSB0aGUgZW5jYXBzdWxhdGlvbiB0 eXBlIGlzIG5lZWRlZC48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDtbSkRdIEkgYWdyZWUgYW5kIHRoZSB0dW5uZWwgZW5jYXBzIGRyYWZ0IGRvZXMga2VlcCB0aGUg RUM8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgJmd0OyZndDsgKiBJIHRo aW5rIGl0IHdvdWxkIGJlIGJldHRlciB0byBhdm9pZCB0aGUgZXhwbGljaXQgbGlzdCBvZiBlbmNh cDxicj4NCiZndDsgJmd0OyZndDsgJmd0OyZndDsgdHlwZXMgaW4gc2VjdGlvbiA1LjEuMywgYW5k IHJhdGhlciByZWZlciB0bzxicj4NCiZndDsgJmd0OyZndDsgJmd0OyZndDsgZHJhZnQtaWV0Zi1p ZHItdHVubmVsLWVuY2FwcyBpbnN0ZWFkPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0 OyZndDsgW0pPUkdFXSBJIGFncmVlLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4N CiZndDsgJmd0O1tKRF0gQWNjb3JkaW5nIHRvIElBTkEsIGl0IGFsbG9jYXRlZCB0aGUgZml2ZSB0 dW5uZWxzIHR5cGVzIHRvIHRoZTxicj4NCiZndDsgJmd0O292ZXJsYXkgZHJhZnQgc28gSSB0aGlu ayB3ZSBuZWVkIHRvIGtlZXAgdGhlbTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4N CiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7ICogdGhlIGZvbGxvd2lu ZyBtaW5vciBtb2RpZmljYXRpb24gd2FzIHByb3Bvc2VkLCBidXQgbm90IHlldCBpbmNvcnBvcmF0 ZWQ6PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgJmd0OyZn dDsgSm9obiBEcmFrZSwgMjAxNS0xMS0xMyAodG8gQkVTUyBNTCk6PGJyPg0KJmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgRm9yIHRoZSBvdmVybGF5IGRyYWZ0LCByZXBsYWNlIHRoaXMgdGV4dCBp biBzZWN0aW9uIDUuMS4zOjxicj4NCiZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJnF1b3Q7SWYgdGhlIEJHUCBFbmNhcHN1bGF0aW9uIGV4 dGVuZGVkIGNvbW11bml0eSBpcyBub3QgcHJlc2VudCw8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyB0aGVuIHRoZSBkZWZhdWx0IE1QTFMgZW5jYXBzdWxhdGlvbiBvciBhIHN0YXRpY2Fs bHkgY29uZmlndXJlZDxicj4NCiZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IGVuY2Fwc3VsYXRp b24gaXMgYXNzdW1lZC4mcXVvdDs8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IFdpdGggdGhlIGZvbGxvd2luZzo8YnI+DQomZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZx dW90O05vdGUgdGhhdCB0aGUgTVBMUyBlbmNhcHN1bGF0aW9uIHR1bm5lbCB0eXBlIGlzIG5lZWRl ZCBpbjxicj4NCiZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IG9yZGVyIHRvIGRpc3Rpbmd1aXNo IGJldHdlZW4gYW4gYWR2ZXJ0aXNpbmcgbm9kZSB0aGF0IG9ubHk8YnI+DQomZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyBzdXBwb3J0cyBub24tTVBMUyBlbmNhcHN1bGF0aW9ucyBhbmQgb25lIHRo YXQgc3VwcG9ydHMgTVBMUyBhbmQ8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBub24t TVBMUyBlbmNhcHN1bGF0aW9ucy4gQW4gYWR2ZXJ0aXNpbmcgbm9kZSB0aGF0IG9ubHkgc3VwcG9y dHM8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBNUExTIGVuY2Fwc3VsYXRpb24gZG9l cyBub3QgbmVlZCB0byBhZHZlcnRpc2UgYW55IGVuY2Fwc3VsYXRpb248YnI+DQomZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyB0dW5uZWwgdHlwZXM7IGkuZS4sIGlmIHRoZSBCR1AgRW5jYXBzdWxh dGlvbiBleHRlbmRlZCBjb21tdW5pdHk8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBp cyBub3QgcHJlc2VudCwgdGhlbiBlaXRoZXIgTVBMUyBlbmNhcHN1bGF0aW9uIG9yIGEgc3RhdGlj YWxseTxicj4NCiZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IGNvbmZpZ3VyZWQgZW5jYXBzdWxh dGlvbiBpcyBhc3N1bWVkLiZxdW90Ozxicj4NCiZndDsgJmd0OyZndDsgJmd0OyZndDs8YnI+DQom Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IEkgdGhpbmsgdGhpcyBjaGFuZ2UgaXMgdXNlZnVsIGFuZCBz aG91bGQgYmUgaW5jb3Jwb3JhdGVkLCBhbHRob3VnaDxicj4NCiZndDsgJmd0OyZndDsgJmd0OyZn dDsgc2tpcHBpbmcgdGhlIGxhc3Qgc2VudGVuY2Ugd291bGQgYmUgd2lzZSBpZiB0aGUgZnVsbCBs aXN0IG9mPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyB0dW5uZWwgdHlwZXMgaXMgcmVtb3Zl ZC48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDtbSkRdIEZpbmUg d2l0aCBtZSBlaXRoZXIgdy8gb3Igdy9vIHRoZSBsYXN0IHNlbnRlbmNlPGJyPg0KJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48 L3ByZT4NCjxwcmU+Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250 ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQg bmUgZG9pdmVudCBkb25jPG86cD48L286cD48L3ByZT4NCjxwcmU+cGFzIGV0cmUgZGlmZnVzZXMs IGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1 IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXI8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT5hIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBp ZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJs ZXMgZCdhbHRlcmF0aW9uLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk9yYW5nZSBkZWNsaW5lIHRv dXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91 IGZhbHNpZmllLiBNZXJjaS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpw PjwvcHJlPg0KPHByZT5UaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFp biBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90 ZWN0ZWQgYnkgbGF3OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnRoZXkgc2hvdWxkIG5vdCBiZSBk aXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3Is IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRz IGF0dGFjaG1lbnRzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkFzIGVtYWlscyBtYXkgYmUgYWx0 ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1v ZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGFu ayB5b3UuPG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9zcGFuPjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_C34C65F6323049E3B3AAC488A9154943alcatellucentcom_-- From nobody Thu May 5 08:37:10 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7475112D09B; Thu, 5 May 2016 08:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-9jFE-UbNL3; Thu, 5 May 2016 08:37:01 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1D6B12B051; Thu, 5 May 2016 08:37:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3551; q=dns/txt; s=iport; t=1462462620; x=1463672220; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=go7m6lxUtH2PAYgHiC5rn/4hzPyxA/slVotNaEWXDMc=; b=mhWJztAzBNOPsnIQ71iR180T7D/L8w4z+HDQQ+xRZqIOvMfwujYU7TWA InXKNgA295TEaiRuViHzAOdzKgRpgq74uZIIobXsSsrfAlihC271ozP60 t2Ve0yDey+IKYRp8MjW4wXt9ijvLd7cD6IB9n4MqNReHXk0DSDyFsdu6e I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgBtaCtX/5JdJa1dgziBUAa2foIPA?= =?us-ascii?q?Q2BdoYQAoE1OBQBAQEBAQEBZSeEQgEBAwE6MQ4QAgEINhAyJQIEAQ0FG4gHCL8?= =?us-ascii?q?xAQEBAQEBAQEBAQEBAQEBAQEBAReGIIRMihgBBId5iyyEdQGOGIFoh3aFNY8zA?= =?us-ascii?q?R4BAUKCNoE1bIdbfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,582,1454976000"; d="scan'208";a="101361249" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 May 2016 15:36:52 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u45FaqrD015612 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 5 May 2016 15:36:52 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 5 May 2016 10:36:51 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Thu, 5 May 2016 10:36:51 -0500 From: "Alvaro Retana (aretana)" To: Jari Arkko , The IESG Thread-Topic: Jari Arkko's Discuss on draft-ietf-idr-route-oscillation-stop-03: (with DISCUSS and COMMENT) Thread-Index: AQHRprRTmhXdCvFQWUW3H4yt0d2g+J+qizoA Date: Thu, 5 May 2016 15:36:51 +0000 Message-ID: References: <20160505095556.15385.64588.idtracker@ietfa.amsl.com> In-Reply-To: <20160505095556.15385.64588.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.247.86] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-idr-route-oscillation-stop@ietf.org" , "idr@ietf.org" , "pkyzivat@alum.mit.edu" , Susan Hares , "idr-chairs@ietf.org" Subject: Re: [Idr] Jari Arkko's Discuss on draft-ietf-idr-route-oscillation-stop-03: (with DISCUSS and COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 15:37:03 -0000 On 5/5/16, 5:55 AM, "Jari Arkko" wrote: Jari: Hi! >---------------------------------------------------------------------- >DISCUSS: >---------------------------------------------------------------------- > >Thank you for writing this document on this important issue. > >I want to recommend its approval as an RFC and will do so >shortly, but a Gen-ART review from Paul Kyzivat >inspired me to read the document, and I have >some comments. I'm not necessarily looking for >document changes, but I am looking for some responses >to Paul's or my comments, to make sure we all agree >that we are doing this right. > >Specifically, > >> A detailed description of how these oscillations can occur >> can be found in [RFC3345]; the description of how a node would >> locally detect such condition is outside the scope of this document. > >I am not an expert on this topic, but I'd like to understand the nature >of such detection algorithms. How hard problem is that? What is >required? >I'm not looking for specifying or even referring to the algorithm here, >but >it would be beneficial at least for this reader to understand the nature >of the class of solutions referred to here. Are solutions >algorithmically >computable? Heuristic? Dependent on specific configurations? >Vendor solutions exist but aren't documented. As explained in rfc3345, there are specific conditions when the oscillation may happen: multi-tier RR/confederation + receiving MED from more than one peer. The oscillation itself is not hard to detect (simply look for routes that constantly change), the confirmation that it is MED oscillation requires at least realizing that the MED is changing with the routes. > >> When the ADD-PATH Capability is also received from >> the IBGP peer with the "Send/Receive" field set to 1 (receive >> multiple paths) or 3 (send/receive multiple paths) for the same > SAFI>, then the following procedures shall be followed: >>=20 >> If the peer is a route reflection client, the route reflector SHOULD >> advertise to the peer the Group Best Paths (or the Available Paths) >> received from its non-client IBGP peers. Depending on the >> configuration, the route reflector MAY also advertise to the peer the >> Group Best Paths (or the Available Paths) received from its clients. > >I am picking this text excerpt as an example. > >Like Paul, some of this language makes me slightly uncomfortable, >and it would be good to understand what the aim is. If the intent >is to describe a procedure that can be followed and fully specified, >the expectations on the text are different from an informative >description of the kinds of things an implementation could do. > >In the above text, there's quite a lot of imprecision. That may >be fine, but I wanted to check that this is the case. > >For instance, why is a "shall" (and in lowercase) followed by >a set of "SHOULD"s and "MAY"s? Is there any guidance on >when the "SHOULD"s should be followed? There seems to >be thinking behind, could that be documented? What kind >of configuration issues affect the decisions? Yes, I see what you mean. I think that at the time we wrote the text we were probably thinking in terms of "SHOULD" because this is one of the options (Group Best Paths vs All the Paths), but within that option we can be more precise. We will work on clarifying and get back to you -- I'm traveling, so it might take a couple of days. Thanks! Alvaro. From nobody Thu May 5 10:10:37 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E951B12D1AA; Thu, 5 May 2016 10:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhnWISY98Vgv; Thu, 5 May 2016 10:10:27 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2a00:1d50:2::130]) by ietfa.amsl.com (Postfix) with ESMTP id BB1C512D0E6; Thu, 5 May 2016 10:10:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 8EBC72CC6F; Thu, 5 May 2016 20:10:25 +0300 (EEST) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QG866PBvFvf7; Thu, 5 May 2016 20:10:25 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 3440F2CC64; Thu, 5 May 2016 20:10:24 +0300 (EEST) (envelope-from jari.arkko@piuha.net) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_0793917E-BD61-4C86-8F58-2FB4ACD8F9A4"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Jari Arkko In-Reply-To: Date: Thu, 5 May 2016 13:10:23 -0400 Message-Id: <64795885-F58D-4B47-848F-720917544170@piuha.net> References: <20160505095556.15385.64588.idtracker@ietfa.amsl.com> To: "Alvaro Retana (aretana)" X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "draft-ietf-idr-route-oscillation-stop@ietf.org" , "idr@ietf.org" , "idr-chairs@ietf.org" , "pkyzivat@alum.mit.edu" , The IESG , Susan Hares Subject: Re: [Idr] Jari Arkko's Discuss on draft-ietf-idr-route-oscillation-stop-03: (with DISCUSS and COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 17:10:33 -0000 --Apple-Mail=_0793917E-BD61-4C86-8F58-2FB4ACD8F9A4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > We will work on clarifying and get back to you -- I'm traveling, so it > might take a couple of days. Thanks. Jari --Apple-Mail=_0793917E-BD61-4C86-8F58-2FB4ACD8F9A4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXK35/AAoJEM80gCTQU46qiHgQAIAC87tLpNxD2RR4siCqNnBn FllFb3e9HiL5CHdpbrn1sfS7XweECIe6g0B6bG8FTHjaOQMCwn97N2O5RUPl//zh gHMA2+UKWnOoOPGAyhtmNPTSdVV8XMlg3u5t9/18f+/vxEohv+guMeEMQRE2OiqU 4Sky8BuUTmJcYS7IcYWc6OCFiemLbDiA5kdICqVbFlOZtzT1x0HNeuliT23F3Vxb 29fbY9tAv9DTGnDOXlvTNy9Ds0xCHNlLPUPEaBJvQs+ZHLtb2BpJAt0cZOcw9tRG BMnHGGryrBmy2n9hQtJypaLCVOZxr8TQIw5lNMHvkuXa7zoQ8aOyAdwQtI1Vsmfx mXfbBxCOBIM+Uc4tZFpih7mvdZL/7HaWSpBX8v5XsBOap45RlPeSdvsxweGF+bZ5 Bk00LgBwRgrf1BjyDSg7dhrPcFmGiW4VGOktg+43ffpU+RxXECiCyiAUHguhwRxt a3syo5i2fjXBAeJCXg4MFT64quwrXqQPVgatf1GpcAOh03DGykFm4dCB+jqMDaHJ qzxG62jN9Ms5HmO1F3CVm8NsoOTT3D2RuaaAdstOLNGH0eI0BH6/Eu67QuGqY0ZP Txs+wkTv3MBk6QNE2VoWEIi4dqxuPgKeyb/qPnK9H43LBabbifA652XEkxrtMmLp K3+JXA+FTL4t7O49W0B6 =CfdN -----END PGP SIGNATURE----- --Apple-Mail=_0793917E-BD61-4C86-8F58-2FB4ACD8F9A4-- From nobody Thu May 5 11:16:27 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA3C12D0C8; Thu, 5 May 2016 11:16:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160505181624.20478.15108.idtracker@ietfa.amsl.com> Date: Thu, 05 May 2016 11:16:24 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-li-idr-mpls-path-programming-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 18:16:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : BGP Extensions for Service-Oriented MPLS Path Programming (MPP) Authors : Zhenbin Li Shunwan Zhuang Sujian Lu Filename : draft-li-idr-mpls-path-programming-03.txt Pages : 14 Date : 2016-05-05 Abstract: Service-oriented MPLS programming (SoMPP) is to provide customized service process based on flexible label combinations. BGP will play an important role for MPLS path programming to download programmed MPLS path and map the service path to the transport path. This document defines BGP extensions to support service-oriented MPLS path programming. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-li-idr-mpls-path-programming/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-li-idr-mpls-path-programming-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-li-idr-mpls-path-programming-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 5 14:47:23 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09EDB12D690; Thu, 5 May 2016 14:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.914 X-Spam-Level: X-Spam-Status: No, score=-2.914 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxBF-tp2NQ4U; Thu, 5 May 2016 14:47:17 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75E4012D6B3; Thu, 5 May 2016 14:47:17 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id E22A5403B7; Thu, 5 May 2016 23:47:15 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.17]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 91323120055; Thu, 5 May 2016 23:47:15 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM24.corporate.adroot.infra.ftgroup ([fe80::a1e6:3e6a:1f68:5f7e%19]) with mapi id 14.03.0294.000; Thu, 5 May 2016 23:47:15 +0200 From: To: IDR , BESS , "draft-ietf-bess-evpn-overlay@tools.ietf.org" , "Ali Sajassi (sajassi)" , "Rabadan, Jorge (Nokia - US)" , "draft-ietf-idr-tunnel-encap@tools.ietf.org" , John E Drake Thread-Topic: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps Thread-Index: AdGmBJMUJMtmxTFkSDagWg0yGwJv3wAA4tKAAAWwlwAAAPoxgAACvdiAAAOPgQAAADvBgAAjSzCP///lg4CAALWnAA== Date: Thu, 5 May 2016 21:47:14 +0000 Message-ID: <17029_1462484835_572BBF63_17029_2323_1_opi9hqsl9b9tani0t0skkcuq.1462484831251@email.android.com> References: <5729F1C3.1030605@orange.com> <5729F7C5.6040604@orange.com> <52D35106-ED5E-4C95-9131-6EA4527370D5@alcatel-lucent.com> <012C176C-A8D6-45AA-BA69-616C0ED7E41E@alcatel-lucent.com>, , <420BA2D8D80A6727.2B2C290F-2299-40BB-B53B-CC36D2B5D826@mail.outlook.com> <1881_1462451514_572B3D3A_1881_7198_1_0vn90oitr7e881gh2sn8qm5f.1462451509961@email.android.com>, In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_opi9hqsl9b9tani0t0skkcuq1462484831251emailandroidcom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 21:47:21 -0000 --_000_opi9hqsl9b9tani0t0skkcuq1462484831251emailandroidcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi John, I have a hard time reconciliating the fact that yesterday you were fine wit= h having bess-evpn-overlay refer to idr-tunnel-encap instead of RFC5512, wi= th the fact that you consider (belox) the two docs "not aligned" for unicas= t. Can you be more explicit in where the "misalignment" lies? -Thomas ---- John E Drake a =E9crit ---- Thomas, The overlay draft preceded the tunnel encaps draft and it was designed to h= andle a very specific problem, marrying the EVPN control plane to the VXLAN= data plane draft and modulo the correction to section 9 it is internally c= onsistent. The tunnel encaps draft solves a more general problem and the WG decided a = long time ago that the overlay draft was not going to be updated to use the= mechanisms it details for unicast, so the overlay draft is already explici= tly not in alignment with it. This, plus the fact that the tunnel encaps draft explicitly puts the PMSI o= ut of scope, leads me to the conclusion that the overlay draft should not b= e tweaked to be in alignment with a future solution for encoding VNIs for m= ulticast. Yours Irrespectively, John From: thomas.morin@orange.com [mailto:thomas.morin@orange.com] Sent: Thursday, May 05, 2016 8:32 AM To: John E Drake; IDR; BESS; draft-ietf-bess-evpn-overlay@tools.ietf.org; A= li Sajassi (sajassi); Rabadan, Jorge (Nokia - US); draft-ietf-idr-tunnel-en= cap@tools.ietf.org Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-e= ncaps Thanks for the clarification on the intent around draft-ietf-bess-evpn-over= lay. Then indeed section 9 needs some tidying up. The issue that I think remain is that it would be much cleaner to explain h= ow to use PMSI with overlay encaps in a spec not specific to E-VPN and in a= way more consistent to what is done for unicast. It seems if course that draft-ietf-idr-tunnel-encap should be the place, bu= t that document currently explicitly makes PMSIs out of scope. Shouldn't this part of draft-ietf-idr-tunnel-encap be revisited ? -Thomas ---- Rabadan, Jorge (Nokia - US) a =E9crit ---- Fully agree John. That's what I meant, sorry if I didn't make myself clear.= Section 9 needs clean up, yes. Thanks, Jorge _____________________________ From: EXT John E Drake > Sent: Wednesday, May 4, 2016 23:34 Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-e= ncaps To: IDR >, Ali Sajassi (sajassi) >, Rabadan, Jorge (Nokia - US) >, BESS <= bess@ietf.org>, >, EXT - thomas.= morin@orange.com > Jorge, We put the VNI value in the MPLS label field of the PMSI attribute for all = service types, and we put a value in the Ethernet Tag field following the r= ules for each service type as described in 5.1.3 (https://tools.ietf.org/ht= ml/draft-ietf-bess-evpn-overlay-02#section-5.1.3). You're right that we need to clean up section 9. Yours Irrespectively, John > -----Original Message----- > From: Rabadan, Jorge (Nokia - US) [mailto:jorge.rabadan@nokia.com] > Sent: Wednesday, May 04, 2016 3:53 PM > To: John E Drake; EXT - thomas.morin@orange.com; BESS; IDR; draft-ietf-bess-evpn- > overlay@tools.ietf.org; Ali Sajassi (sajas= si) > Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel= -encaps > > Hi John, > > About this: > > [JD] For the IMET route the MPLS label field is carried in the PMSI attri= bute. I think we need > to ask everyone whether they used the Ethernet Tag or the PMSI attribute = to carry the VNI > > > In case it helps, I=92ve seen a few implementations running and they all = encode the VNI in the > MPLS label field in the PTA. And a couple of them, encode the VNI in the = ethernet-tag, in > addition to the MPLS label in the PTA. In any case, I think section 9 con= tradicts section 5.1.3 > and should be clarified. > > "5.1.3 Constructing EVPN BGP Routes > > the MPLS label field in the MAC Advertisement, Ethernet AD per EVI, and *= *Inclusive > Multicast Ethernet Tag** routes is used to carry the VNI or VSID." > > Thanks. > Jorge > > > > > > On 5/4/16, 8:34 PM, "EXT John E Drake" > wrote: > > >Thomas and Jorge, > > > >Snipped, comments inline. > > > >Yours Irrespectively, > > > >John > > > >> > > >> >draft-ietf-bess-evpn-overlay (see section 9) relies on the BGP > >> >Encapsulation extended to encode the tunnel encap to use for BUM > >> >traffic, but contrary to other E-VPN routes, relies on the Ethernet > >> >Tag field of the NLRI to encode the VNI/VSID. > >> > >> [JORGE] This is certainly a leftover from an old version where the > >> VNI/VSID was encoded in the ethernet tag for all the routes. The VNI > >> should be encoded in the Label field in all the routes. This has to be= corrected. > >> > >> In fact, section 5.1.3 says: > >> > >> 5.1.3 Constructing EVPN BGP Routes > >> > >> > >> > >> Accordingly, and > >> specifically to support the option of locally assigned VNIs, the MPLS > >> label field in the MAC Advertisement, Ethernet AD per EVI, and > >> Inclusive Multicast Ethernet Tag routes is used to carry the VNI or > >> VSID. For the balance of this memo, the MPLS label field will be > >> referred to as the VNI/VSID field. The VNI/VSID field is used for > >> both local and global VNIs/VSIDs, and for either case the entire 24- > >> bit field is used to encode the VNI/VSID value. > >> > >> > > > > > >[JD] For the IMET route the MPLS label field is carried in the PMSI attr= ibute. I think we > need to ask everyone whether they > >used the Ethernet Tag or the PMSI attribute to carry the VNI > > > > > >> >> > >> >> There are minor things that could be improved in > >> >> draft-ietf-bess-evpn-overlay wrt. consistency with > >> >> draft-ietf-idr-tunnel-encaps : > >> >> > >> >> * since draft-ietf-idr-tunnel-encaps will deprecate RFC5512, it > >> >> would be better that draft-ietf-bess-evpn-overlay refers to > >> >> draft-ietf-idr-tunnel-encaps and not anymore to RFC5512. > >> > >> [JORGE] I agree, as long as draft-ietf-idr-tunnel-encaps keeps the > >> encapsulation extended community. There are a few implementations > >> using this community and it is enough when only the encapsulation type= is needed. > > > > > >[JD] I agree and the tunnel encaps draft does keep the EC > > > > > >> > >> >> > >> >> * I think it would be better to avoid the explicit list of encap > >> >> types in section 5.1.3, and rather refer to > >> >> draft-ietf-idr-tunnel-encaps instead > >> > >> [JORGE] I agree. > > > > > >[JD] According to IANA, it allocated the five tunnels types to the > >overlay draft so I think we need to keep them > > > > > >> > >> >> * the following minor modification was proposed, but not yet incorp= orated: > >> >> > >> >> John Drake, 2015-11-13 (to BESS ML): > >> >>> For the overlay draft, replace this text in section 5.1.3: > >> >>> > >> >>> "If the BGP Encapsulation extended community is not present, > >> >>> then the default MPLS encapsulation or a statically configured > >> >>> encapsulation is assumed." > >> >>> > >> >>> With the following: > >> >>> > >> >>> "Note that the MPLS encapsulation tunnel type is needed in > >> >>> order to distinguish between an advertising node that only > >> >>> supports non-MPLS encapsulations and one that supports MPLS and > >> >>> non-MPLS encapsulations. An advertising node that only supports > >> >>> MPLS encapsulation does not need to advertise any encapsulation > >> >>> tunnel types; i.e., if the BGP Encapsulation extended community > >> >>> is not present, then either MPLS encapsulation or a statically > >> >>> configured encapsulation is assumed." > >> >> > >> >> I think this change is useful and should be incorporated, although > >> >> skipping the last sentence would be wise if the full list of > >> >> tunnel types is removed. > > > > > >[JD] Fine with me either w/ or w/o the last sentence > > > > ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_opi9hqsl9b9tani0t0skkcuq1462484831251emailandroidcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi John,

I have a hard time reconciliating the fact that yesterday you were fine wit= h having bess-evpn-overlay refer to idr-tunnel-encap instead of RFC5512, wi= th the fact that you consider (belox) the two docs "not aligned" = for unicast.

Can you be more explicit in where the "misalignment" lies?

-Thomas

---- John E Drake a =E9crit ----

Thomas,

 

The overlay draft preceded the tunn= el encaps draft and it was designed to handle a very specific problem, marr= ying the EVPN control plane to the VXLAN data plane draft and modulo the correction to section 9 it is internally consis= tent.

 

The tunnel encaps draft solves a mo= re general problem and the WG decided a long time ago that the overlay draf= t was not going to be updated to use the mechanisms it details for unicast, so the overlay draft is already explicitly not in = alignment with it.

 

This, plus the fact that the tunnel= encaps draft explicitly puts the PMSI out of scope, leads me to the conclu= sion that the overlay draft should not be tweaked to be in alignment with a future solution for encoding VNIs for multicast.=

 

Yours Irrespectively,

 

John

 

From: thomas.morin@orange.com [mai= lto:thomas.morin@orange.com]
Sent: Thursday, May 05, 2016 8:32 AM
To: John E Drake; IDR; BESS; draft-ietf-bess-evpn-overlay@tools.ietf= .org; Ali Sajassi (sajassi); Rabadan, Jorge (Nokia - US); draft-ietf-idr-tu= nnel-encap@tools.ietf.org
Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-t= unnel-encaps

 

Thanks for the clarif= ication on the intent around draft-ietf-bess-evpn-overlay. Then indeed sect= ion 9 needs some tidying up.

The issue that I think remain is that it would be much cleaner to explain h= ow to use PMSI with overlay encaps in a spec not specific to E-VPN and in a= way more consistent to what is done for unicast.

It seems if course that draft-ietf-idr-tunnel-encap should be the place, bu= t that document currently explicitly makes PMSIs out of scope.

Shouldn't this part of draft-ietf-idr-tunnel-encap be revisited ?

-Thomas


---- Rabadan, Jorge (Nokia - US) a =E9crit ----

Fully agree John. Tha= t's what I meant, sorry if I didn't make myself clear. Section 9 needs clea= n up, yes.

Thanks,
Jorge

 

_____________________= ________
From: EXT John E Drake <jdrake@jun= iper.net>
Sent: Wednesday, May 4, 2016 23:34
Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-e= ncaps
To: IDR <idr@ietf.org>, Ali Sajas= si (sajassi) <sajassi@cisco.com= >, Rabadan, Jorge (Nokia - US) <jorge.rabadan@alcatel-lucent.com>, BESS <bess@ietf.org>, <draft-ietf-bess-e= vpn-overlay@tools.ietf.org>, EXT - thomas.morin@orange.com <= thomas.morin@orange.com><= br>

Jorge,

We put the VNI value in the MPLS label field of the PMSI attribute for all = service types, and we put a value in the Ethernet Tag field following the r= ules for each service type as described in 5.1.3 (https://tools.= ietf.org/html/draft-ietf-bess-evpn-overlay-02#section-5.1.3).

You're right that we need to clean up section 9.

Yours Irrespectively,

John

> -----Original Message-----
> From: Rabadan, Jorge (Nokia - US) [mailto:jorge.rabadan@nokia.com]
> Sent: Wednesday, May 04, 2016 3:53 PM
> To: John E Drake; EXT - tho= mas.morin@orange.com; BESS; IDR; draft-ietf-bess-evpn-
> overlay@tools.ietf.org; = Ali Sajassi (sajassi)
> Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tun= nel-encaps
>
> Hi John,
>
> About this:
>
> [JD] For the IMET route the MPLS label field is carried in the PMSI at= tribute. I think we need
> to ask everyone whether they used the Ethernet Tag or the PMSI attribu= te to carry the VNI
>
>
> In case it helps, I=92ve seen a few implementations running and they a= ll encode the VNI in the
> MPLS label field in the PTA. And a couple of them, encode the VNI in t= he ethernet-tag, in
> addition to the MPLS label in the PTA. In any case, I think section 9 = contradicts section 5.1.3
> and should be clarified.
>
> "5.1.3 Constructing EVPN BGP Routes
> <snip>
> the MPLS label field in the MAC Advertisement, Ethernet AD per EVI, an= d **Inclusive
> Multicast Ethernet Tag** routes is used to carry the VNI or VSID."= ;
>
> Thanks.
> Jorge
>
>
>
>
>
> On 5/4/16, 8:34 PM, "EXT John E Drake" <jdrake@juniper.net> wrote:
>
> >Thomas and Jorge,
> >
> >Snipped, comments inline.
> >
> >Yours Irrespectively,
> >
> >John
> >
> >> >
> >> >draft-ietf-bess-evpn-overlay (see section 9) relies on th= e BGP
> >> >Encapsulation extended to encode the tunnel encap to use = for BUM
> >> >traffic, but contrary to other E-VPN routes, relies on th= e Ethernet
> >> >Tag field of the NLRI to encode the VNI/VSID.
> >>
> >> [JORGE] This is certainly a leftover from an old version wher= e the
> >> VNI/VSID was encoded in the ethernet tag for all the routes. = The VNI
> >> should be encoded in the Label field in all the routes. This = has to be corrected.
> >>
> >> In fact, section 5.1.3 says:
> >>
> >> 5.1.3 Constructing EVPN BGP Routes
> >>
> >> <snip>
> >>
> >> Accordingly, and
> >> specifically to support the option of locally assigned VNIs, = the MPLS
> >> label field in the MAC Advertisement, Ethernet AD per EVI, an= d
> >> Inclusive Multicast Ethernet Tag routes is used to carry the = VNI or
> >> VSID. For the balance of this memo, the MPLS label field will= be
> >> referred to as the VNI/VSID field. The VNI/VSID field is used= for
> >> both local and global VNIs/VSIDs, and for either case the ent= ire 24-
> >> bit field is used to encode the VNI/VSID value.
> >>
> >> <snip>
> >
> >
> >[JD] For the IMET route the MPLS label field is carried in the PMS= I attribute. I think we
> need to ask everyone whether they
> >used the Ethernet Tag or the PMSI attribute to carry the VNI
> >
> >
> >> >>
> >> >> There are minor things that could be improved in
> >> >> draft-ietf-bess-evpn-overlay wrt. consistency with > >> >> draft-ietf-idr-tunnel-encaps :
> >> >>
> >> >> * since draft-ietf-idr-tunnel-encaps will deprecate = RFC5512, it
> >> >> would be better that draft-ietf-bess-evpn-overlay re= fers to
> >> >> draft-ietf-idr-tunnel-encaps and not anymore to RFC5= 512.
> >>
> >> [JORGE] I agree, as long as draft-ietf-idr-tunnel-encaps keep= s the
> >> encapsulation extended community. There are a few implementat= ions
> >> using this community and it is enough when only the encapsula= tion type is needed.
> >
> >
> >[JD] I agree and the tunnel encaps draft does keep the EC
> >
> >
> >>
> >> >>
> >> >> * I think it would be better to avoid the explicit l= ist of encap
> >> >> types in section 5.1.3, and rather refer to
> >> >> draft-ietf-idr-tunnel-encaps instead
> >>
> >> [JORGE] I agree.
> >
> >
> >[JD] According to IANA, it allocated the five tunnels types to the=
> >overlay draft so I think we need to keep them
> >
> >
> >>
> >> >> * the following minor modification was proposed, but= not yet incorporated:
> >> >>
> >> >> John Drake, 2015-11-13 (to BESS ML):
> >> >>> For the overlay draft, replace this text in sect= ion 5.1.3:
> >> >>>
> >> >>> "If the BGP Encapsulation extended communit= y is not present,
> >> >>> then the default MPLS encapsulation or a statica= lly configured
> >> >>> encapsulation is assumed."
> >> >>>
> >> >>> With the following:
> >> >>>
> >> >>> "Note that the MPLS encapsulation tunnel ty= pe is needed in
> >> >>> order to distinguish between an advertising node= that only
> >> >>> supports non-MPLS encapsulations and one that su= pports MPLS and
> >> >>> non-MPLS encapsulations. An advertising node tha= t only supports
> >> >>> MPLS encapsulation does not need to advertise an= y encapsulation
> >> >>> tunnel types; i.e., if the BGP Encapsulation ext= ended community
> >> >>> is not present, then either MPLS encapsulation o= r a statically
> >> >>> configured encapsulation is assumed."
> >> >>
> >> >> I think this change is useful and should be incorpor= ated, although
> >> >> skipping the last sentence would be wise if the full= list of
> >> >> tunnel types is removed.
> >
> >
> >[JD] Fine with me either w/ or w/o the last sentence
> >
> >

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
/pre>

If you have received this email in error, please notify the sender and=
 delete this message and its attachments.


As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.


Thank you.


______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_opi9hqsl9b9tani0t0skkcuq1462484831251emailandroidcom_-- From nobody Thu May 5 15:13:12 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD7112D5AA; Thu, 5 May 2016 15:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1o2TMyKMmsL; Thu, 5 May 2016 15:13:07 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2DD612D147; Thu, 5 May 2016 15:13:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32337; q=dns/txt; s=iport; t=1462486386; x=1463695986; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=O89xIodNUoJYbk/kbziO3BSTVtZxskww+Hq60nlPMOY=; b=RrSHnB1v9oaxQEsitRWPDR6Dtieb3zjUqOx2YspV6qNbP65UzyyJagIT HGPHL+Ht34gd4HCRuaYkhd8Eb9dFqR2VcaFzIAtZgA8sbVDHzV6pG+5t9 y2yAwQBioN1dm6EhEuEaTfLc2Y4gvIkvXiXlXcvCMGJ0UxmQpeIF53NPO c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AQCIxCtX/4MNJK1fgmxMU30GuRkBD?= =?us-ascii?q?YF2JIVsAoEzOBQBAQEBAQEBZSeEQQEBAQQODEsCHgQCAQgRAwEBAQEgBwcyFAk?= =?us-ascii?q?IAgQBEhQHiA8OvwkBAQEBAQEBAQEBAQEBAQEBAQEBAQERBIlpgQOEEREBPBaFI?= =?us-ascii?q?wWTJYR1AYV7gneFJoFohE2IXo8zAR4BAUKCBQUWgUtsAQGGdjZ/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,584,1454976000"; d="scan'208,217";a="269351589" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 May 2016 22:13:05 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u45MD5Yv030972 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 5 May 2016 22:13:05 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 5 May 2016 18:13:04 -0400 Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1104.009; Thu, 5 May 2016 18:13:04 -0400 From: "Ali Sajassi (sajassi)" To: "thomas.morin@orange.com" , IDR , BESS , "draft-ietf-bess-evpn-overlay@tools.ietf.org" , "Rabadan, Jorge (Nokia - US)" , "draft-ietf-idr-tunnel-encap@tools.ietf.org" , John E Drake Thread-Topic: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps Thread-Index: AQHRpi++kmVRnOfCCEaLlUJwLCbjV5+pXciAgAAV74CAABx8AIAAAd6AgAD40oCAAAcLgIAAlB8A//+R2gA= Date: Thu, 5 May 2016 22:13:04 +0000 Message-ID: References: <5729F1C3.1030605@orange.com> <5729F7C5.6040604@orange.com> <52D35106-ED5E-4C95-9131-6EA4527370D5@alcatel-lucent.com> <012C176C-A8D6-45AA-BA69-616C0ED7E41E@alcatel-lucent.com> <420BA2D8D80A6727.2B2C290F-2299-40BB-B53B-CC36D2B5D826@mail.outlook.com> <1881_1462451514_572B3D3A_1881_7198_1_0vn90oitr7e881gh2sn8qm5f.1462451509961@email.android.com> <17029_1462484835_572BBF63_17029_2323_1_opi9hqsl9b9tani0t0skkcuq.1462484831251@email.android.com> In-Reply-To: <17029_1462484835_572BBF63_17029_2323_1_opi9hqsl9b9tani0t0skkcuq.1462484831251@email.android.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.76.55] Content-Type: multipart/alternative; boundary="_000_D35112191966F7sajassiciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 22:13:10 -0000 --_000_D35112191966F7sajassiciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Thomas, With respect to tunnel type extended community used in evpn-overlay, we can= refer to idr-tunnel-encap instead of RFC5512. However, besides that I don= =92t see any other point of contention that needs resolving. We agreed that there needs to be some clarification with respect locally-as= signed VNI in MPLS field (in EVPN routes versus PTA) for unicast packets ve= rsus BUM packets. Is there any other things that need to be clarified? BTW, thanks for doing a thorough review of the doc. Cheers, Ali From: "thomas.morin@orange.com" > Date: Thursday, May 5, 2016 at 2:47 PM To: IDR >, BESS >, "draft-ietf-bess-evpn-overlay@tools.ietf.org" >, Cisco Employee= >, "Rabadan, Jorge (Nokia - US= )" >, "draft-ietf-i= dr-tunnel-encap@tools.ietf.org" >, John E Drake > Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-e= ncaps Hi John, I have a hard time reconciliating the fact that yesterday you were fine wit= h having bess-evpn-overlay refer to idr-tunnel-encap instead of RFC5512, wi= th the fact that you consider (belox) the two docs "not aligned" for unicas= t. Can you be more explicit in where the "misalignment" lies? -Thomas ---- John E Drake a =E9crit ---- Thomas, The overlay draft preceded the tunnel encaps draft and it was designed to h= andle a very specific problem, marrying the EVPN control plane to the VXLAN= data plane draft and modulo the correction to section 9 it is internally c= onsistent. The tunnel encaps draft solves a more general problem and the WG decided a = long time ago that the overlay draft was not going to be updated to use the= mechanisms it details for unicast, so the overlay draft is already explici= tly not in alignment with it. This, plus the fact that the tunnel encaps draft explicitly puts the PMSI o= ut of scope, leads me to the conclusion that the overlay draft should not b= e tweaked to be in alignment with a future solution for encoding VNIs for m= ulticast. Yours Irrespectively, John From: thomas.morin@orange.com [mailto:thoma= s.morin@orange.com] Sent: Thursday, May 05, 2016 8:32 AM To: John E Drake; IDR; BESS; draft-ietf-bess-evpn-overlay@tools.ietf.org; Ali Sajassi (sajassi); R= abadan, Jorge (Nokia - US); draft-ietf-idr-tunnel-encap@tools.ietf.org Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-e= ncaps Thanks for the clarification on the intent around draft-ietf-bess-evpn-over= lay. Then indeed section 9 needs some tidying up. The issue that I think remain is that it would be much cleaner to explain h= ow to use PMSI with overlay encaps in a spec not specific to E-VPN and in a= way more consistent to what is done for unicast. It seems if course that draft-ietf-idr-tunnel-encap should be the place, bu= t that document currently explicitly makes PMSIs out of scope. Shouldn't this part of draft-ietf-idr-tunnel-encap be revisited ? -Thomas ---- Rabadan, Jorge (Nokia - US) a =E9crit ---- Fully agree John. That's what I meant, sorry if I didn't make myself clear.= Section 9 needs clean up, yes. Thanks, Jorge _____________________________ From: EXT John E Drake > Sent: Wednesday, May 4, 2016 23:34 Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-e= ncaps To: IDR >, Ali Sajassi (sajassi) >, Rabadan, Jorge (Nokia - US) >, BESS <= bess@ietf.org>, >, EXT - thomas.= morin@orange.com > Jorge, We put the VNI value in the MPLS label field of the PMSI attribute for all = service types, and we put a value in the Ethernet Tag field following the r= ules for each service type as described in 5.1.3 (https://tools.ietf.org/ht= ml/draft-ietf-bess-evpn-overlay-02#section-5.1.3). You're right that we need to clean up section 9. Yours Irrespectively, John > -----Original Message----- > From: Rabadan, Jorge (Nokia - US) [mailto:jorge.rabadan@nokia.com] > Sent: Wednesday, May 04, 2016 3:53 PM > To: John E Drake; EXT - thomas.morin@orange.com; BESS; IDR; draft-ietf-bess-evpn- > overlay@tools.ietf.org; Ali Sajassi (sajas= si) > Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel= -encaps > > Hi John, > > About this: > > [JD] For the IMET route the MPLS label field is carried in the PMSI attri= bute. I think we need > to ask everyone whether they used the Ethernet Tag or the PMSI attribute = to carry the VNI > > > In case it helps, I=92ve seen a few implementations running and they all = encode the VNI in the > MPLS label field in the PTA. And a couple of them, encode the VNI in the = ethernet-tag, in > addition to the MPLS label in the PTA. In any case, I think section 9 con= tradicts section 5.1.3 > and should be clarified. > > "5.1.3 Constructing EVPN BGP Routes > > the MPLS label field in the MAC Advertisement, Ethernet AD per EVI, and *= *Inclusive > Multicast Ethernet Tag** routes is used to carry the VNI or VSID." > > Thanks. > Jorge > > > > > > On 5/4/16, 8:34 PM, "EXT John E Drake" > wrote: > > >Thomas and Jorge, > > > >Snipped, comments inline. > > > >Yours Irrespectively, > > > >John > > > >> > > >> >draft-ietf-bess-evpn-overlay (see section 9) relies on the BGP > >> >Encapsulation extended to encode the tunnel encap to use for BUM > >> >traffic, but contrary to other E-VPN routes, relies on the Ethernet > >> >Tag field of the NLRI to encode the VNI/VSID. > >> > >> [JORGE] This is certainly a leftover from an old version where the > >> VNI/VSID was encoded in the ethernet tag for all the routes. The VNI > >> should be encoded in the Label field in all the routes. This has to be= corrected. > >> > >> In fact, section 5.1.3 says: > >> > >> 5.1.3 Constructing EVPN BGP Routes > >> > >> > >> > >> Accordingly, and > >> specifically to support the option of locally assigned VNIs, the MPLS > >> label field in the MAC Advertisement, Ethernet AD per EVI, and > >> Inclusive Multicast Ethernet Tag routes is used to carry the VNI or > >> VSID. For the balance of this memo, the MPLS label field will be > >> referred to as the VNI/VSID field. The VNI/VSID field is used for > >> both local and global VNIs/VSIDs, and for either case the entire 24- > >> bit field is used to encode the VNI/VSID value. > >> > >> > > > > > >[JD] For the IMET route the MPLS label field is carried in the PMSI attr= ibute. I think we > need to ask everyone whether they > >used the Ethernet Tag or the PMSI attribute to carry the VNI > > > > > >> >> > >> >> There are minor things that could be improved in > >> >> draft-ietf-bess-evpn-overlay wrt. consistency with > >> >> draft-ietf-idr-tunnel-encaps : > >> >> > >> >> * since draft-ietf-idr-tunnel-encaps will deprecate RFC5512, it > >> >> would be better that draft-ietf-bess-evpn-overlay refers to > >> >> draft-ietf-idr-tunnel-encaps and not anymore to RFC5512. > >> > >> [JORGE] I agree, as long as draft-ietf-idr-tunnel-encaps keeps the > >> encapsulation extended community. There are a few implementations > >> using this community and it is enough when only the encapsulation type= is needed. > > > > > >[JD] I agree and the tunnel encaps draft does keep the EC > > > > > >> > >> >> > >> >> * I think it would be better to avoid the explicit list of encap > >> >> types in section 5.1.3, and rather refer to > >> >> draft-ietf-idr-tunnel-encaps instead > >> > >> [JORGE] I agree. > > > > > >[JD] According to IANA, it allocated the five tunnels types to the > >overlay draft so I think we need to keep them > > > > > >> > >> >> * the following minor modification was proposed, but not yet incorp= orated: > >> >> > >> >> John Drake, 2015-11-13 (to BESS ML): > >> >>> For the overlay draft, replace this text in section 5.1.3: > >> >>> > >> >>> "If the BGP Encapsulation extended community is not present, > >> >>> then the default MPLS encapsulation or a statically configured > >> >>> encapsulation is assumed." > >> >>> > >> >>> With the following: > >> >>> > >> >>> "Note that the MPLS encapsulation tunnel type is needed in > >> >>> order to distinguish between an advertising node that only > >> >>> supports non-MPLS encapsulations and one that supports MPLS and > >> >>> non-MPLS encapsulations. An advertising node that only supports > >> >>> MPLS encapsulation does not need to advertise any encapsulation > >> >>> tunnel types; i.e., if the BGP Encapsulation extended community > >> >>> is not present, then either MPLS encapsulation or a statically > >> >>> configured encapsulation is assumed." > >> >> > >> >> I think this change is useful and should be incorporated, although > >> >> skipping the last sentence would be wise if the full list of > >> >> tunnel types is removed. > > > > > >[JD] Fine with me either w/ or w/o the last sentence > > > > ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_D35112191966F7sajassiciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <56840241917E86428B778447FA0006C2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

Hi Thomas,

With respect to tunnel type extended community used in evpn-overlay, w= e can refer to idr-tunnel-encap instead of RFC5512. However, besides that I= don=92t see any other point of contention that needs resolving. 

We agreed that there needs to be some clarification with respect local= ly-assigned VNI in MPLS field (in EVPN routes versus PTA) for unicast packe= ts versus BUM packets.

Is there any other things that need to be clarified? 

BTW, thanks for doing a thorough review of the doc.

Cheers,
Ali



From: "thomas.morin@orange.com" <thomas.morin@orange.com>
Date: Thursday, May 5, 2016 at 2:47= PM
To: IDR <idr@ietf.org>, BESS <be= ss@ietf.org>, "draft-ietf-bess-evpn-overlay@tools.ietf.org" <draft-i= etf-bess-evpn-overlay@tools.ietf.org>, Cisco Employee <sajassi@cisco.com>, "Rabadan, Jorge = (Nokia - US)" <jorge.rab= adan@nokia.com>, "draft-= ietf-idr-tunnel-encap@tools.ietf.org" <draft-ietf-idr-tunnel-encap@tools.iet= f.org>, John E Drake <jdrak= e@juniper.net>
Subject: RE: [Idr] draft-ietf-bess-= evpn-overlay vs. draft-ietf-idr-tunnel-encaps

Hi John,

I have a hard time reconciliating the fact that yesterday you were fine wit= h having bess-evpn-overlay refer to idr-tunnel-encap instead of RFC5512, wi= th the fact that you consider (belox) the two docs "not aligned" = for unicast.

Can you be more explicit in where the "misalignment" lies?

-Thomas

---- John E Drake a =E9crit ----

Thomas,

 

The overlay draft preceded the tunn= el encaps draft and it was designed to handle a very specific problem, marr= ying the EVPN control plane to the VXLAN data plane draft and modulo the correction to section 9 it is internally c= onsistent.

 

The tunnel encaps draft solves a mo= re general problem and the WG decided a long time ago that the overlay draf= t was not going to be updated to use the mechanisms it details for unicast, so the overlay draft is already exp= licitly not in alignment with it.

 

This, plus the fact that the tunnel= encaps draft explicitly puts the PMSI out of scope, leads me to the conclu= sion that the overlay draft should not be tweaked to be in alignment with a future solution for encoding VNIs for= multicast.

 

Yours Irrespectively,

 

John

 

From: thomas.morin@orange.com [mailto:thomas.morin@orange.com]
Sent: Thursday, May 05, 2016 8:32 AM
To: John E Drake; IDR; BESS; draft-ietf-bess-evpn-overlay@tools.ietf.org; Ali Sajassi (sajassi); Rab= adan, Jorge (Nokia - US); draft-ietf-id= r-tunnel-encap@tools.ietf.org
Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-t= unnel-encaps

 

Thanks for the clarif= ication on the intent around draft-ietf-bess-evpn-overlay. Then indeed sect= ion 9 needs some tidying up.

The issue that I think remain is that it would be much cleaner to explain h= ow to use PMSI with overlay encaps in a spec not specific to E-VPN and in a= way more consistent to what is done for unicast.

It seems if course that draft-ietf-idr-tunnel-encap should be the place, bu= t that document currently explicitly makes PMSIs out of scope.

Shouldn't this part of draft-ietf-idr-tunnel-encap be revisited ?

-Thomas


---- Rabadan, Jorge (Nokia - US) a =E9crit ----

Fully agree John. Tha= t's what I meant, sorry if I didn't make myself clear. Section 9 needs clea= n up, yes.

Thanks,
Jorge

 

_____________________= ________
From: EXT John E Drake <jdrake@jun= iper.net>
Sent: Wednesday, May 4, 2016 23:34
Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-e= ncaps
To: IDR <idr@ietf.org>, Ali Sajas= si (sajassi) <sajassi@cisco.com= >, Rabadan, Jorge (Nokia - US) <jorge.rabadan@alcatel-lucent.com>, BESS <bess@ietf.org>, <draft-ietf-bess-e= vpn-overlay@tools.ietf.org>, EXT - thomas.morin@orange.com <= thomas.morin@orange.com><= br>

Jorge,

We put the VNI value in the MPLS label field of the PMSI attribute for all = service types, and we put a value in the Ethernet Tag field following the r= ules for each service type as described in 5.1.3 (https://tools.= ietf.org/html/draft-ietf-bess-evpn-overlay-02#section-5.1.3).

You're right that we need to clean up section 9.

Yours Irrespectively,

John

> -----Original Message-----
> From: Rabadan, Jorge (Nokia - US) [mailto:jorge.rabadan@nokia.com]
> Sent: Wednesday, May 04, 2016 3:53 PM
> To: John E Drake; EXT - tho= mas.morin@orange.com; BESS; IDR; draft-ietf-bess-evpn-
> overlay@tools.ietf.org; = Ali Sajassi (sajassi)
> Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tun= nel-encaps
>
> Hi John,
>
> About this:
>
> [JD] For the IMET route the MPLS label field is carried in the PMSI at= tribute. I think we need
> to ask everyone whether they used the Ethernet Tag or the PMSI attribu= te to carry the VNI
>
>
> In case it helps, I=92ve seen a few implementations running and they a= ll encode the VNI in the
> MPLS label field in the PTA. And a couple of them, encode the VNI in t= he ethernet-tag, in
> addition to the MPLS label in the PTA. In any case, I think section 9 = contradicts section 5.1.3
> and should be clarified.
>
> "5.1.3 Constructing EVPN BGP Routes
> <snip>
> the MPLS label field in the MAC Advertisement, Ethernet AD per EVI, an= d **Inclusive
> Multicast Ethernet Tag** routes is used to carry the VNI or VSID."= ;
>
> Thanks.
> Jorge
>
>
>
>
>
> On 5/4/16, 8:34 PM, "EXT John E Drake" <jdrake@juniper.net> wrote:
>
> >Thomas and Jorge,
> >
> >Snipped, comments inline.
> >
> >Yours Irrespectively,
> >
> >John
> >
> >> >
> >> >draft-ietf-bess-evpn-overlay (see section 9) relies on th= e BGP
> >> >Encapsulation extended to encode the tunnel encap to use = for BUM
> >> >traffic, but contrary to other E-VPN routes, relies on th= e Ethernet
> >> >Tag field of the NLRI to encode the VNI/VSID.
> >>
> >> [JORGE] This is certainly a leftover from an old version wher= e the
> >> VNI/VSID was encoded in the ethernet tag for all the routes. = The VNI
> >> should be encoded in the Label field in all the routes. This = has to be corrected.
> >>
> >> In fact, section 5.1.3 says:
> >>
> >> 5.1.3 Constructing EVPN BGP Routes
> >>
> >> <snip>
> >>
> >> Accordingly, and
> >> specifically to support the option of locally assigned VNIs, = the MPLS
> >> label field in the MAC Advertisement, Ethernet AD per EVI, an= d
> >> Inclusive Multicast Ethernet Tag routes is used to carry the = VNI or
> >> VSID. For the balance of this memo, the MPLS label field will= be
> >> referred to as the VNI/VSID field. The VNI/VSID field is used= for
> >> both local and global VNIs/VSIDs, and for either case the ent= ire 24-
> >> bit field is used to encode the VNI/VSID value.
> >>
> >> <snip>
> >
> >
> >[JD] For the IMET route the MPLS label field is carried in the PMS= I attribute. I think we
> need to ask everyone whether they
> >used the Ethernet Tag or the PMSI attribute to carry the VNI
> >
> >
> >> >>
> >> >> There are minor things that could be improved in
> >> >> draft-ietf-bess-evpn-overlay wrt. consistency with > >> >> draft-ietf-idr-tunnel-encaps :
> >> >>
> >> >> * since draft-ietf-idr-tunnel-encaps will deprecate = RFC5512, it
> >> >> would be better that draft-ietf-bess-evpn-overlay re= fers to
> >> >> draft-ietf-idr-tunnel-encaps and not anymore to RFC5= 512.
> >>
> >> [JORGE] I agree, as long as draft-ietf-idr-tunnel-encaps keep= s the
> >> encapsulation extended community. There are a few implementat= ions
> >> using this community and it is enough when only the encapsula= tion type is needed.
> >
> >
> >[JD] I agree and the tunnel encaps draft does keep the EC
> >
> >
> >>
> >> >>
> >> >> * I think it would be better to avoid the explicit l= ist of encap
> >> >> types in section 5.1.3, and rather refer to
> >> >> draft-ietf-idr-tunnel-encaps instead
> >>
> >> [JORGE] I agree.
> >
> >
> >[JD] According to IANA, it allocated the five tunnels types to the=
> >overlay draft so I think we need to keep them
> >
> >
> >>
> >> >> * the following minor modification was proposed, but= not yet incorporated:
> >> >>
> >> >> John Drake, 2015-11-13 (to BESS ML):
> >> >>> For the overlay draft, replace this text in sect= ion 5.1.3:
> >> >>>
> >> >>> "If the BGP Encapsulation extended communit= y is not present,
> >> >>> then the default MPLS encapsulation or a statica= lly configured
> >> >>> encapsulation is assumed."
> >> >>>
> >> >>> With the following:
> >> >>>
> >> >>> "Note that the MPLS encapsulation tunnel ty= pe is needed in
> >> >>> order to distinguish between an advertising node= that only
> >> >>> supports non-MPLS encapsulations and one that su= pports MPLS and
> >> >>> non-MPLS encapsulations. An advertising node tha= t only supports
> >> >>> MPLS encapsulation does not need to advertise an= y encapsulation
> >> >>> tunnel types; i.e., if the BGP Encapsulation ext= ended community
> >> >>> is not present, then either MPLS encapsulation o= r a statically
> >> >>> configured encapsulation is assumed."
> >> >>
> >> >> I think this change is useful and should be incorpor= ated, although
> >> >> skipping the last sentence would be wise if the full= list of
> >> >> tunnel types is removed.
> >
> >
> >[JD] Fine with me either w/ or w/o the last sentence
> >
> >

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
/pre>

If you have received this email in error, please notify the sender and=
 delete this message and its attachments.


As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.


Thank you.


______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_D35112191966F7sajassiciscocom_-- From nobody Thu May 5 15:22:48 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB1312D70E; Thu, 5 May 2016 15:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J_QyCw7SHvR7; Thu, 5 May 2016 15:22:39 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24A4B12D75E; Thu, 5 May 2016 15:22:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36327; q=dns/txt; s=iport; t=1462486958; x=1463696558; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=QAGseKCpZSFS6m7zXp0NjJLIeS1YRMEtKzhq2+cA3N4=; b=HwYkOIT0A/0wxzpq7kzG07w/yqSneAriYjHlFw4tHPIG4NwvqV6Y66Ef cpZAZlCUUUdOUoB5l2s5AFmW3LkJ3mg6EzAVkFkGt4qE+bqZHBGomVirB u61wv4F1f1oeraVv48m1J4E9y8MsAy7MM0ir7FUAvQBe+WmKiK9Bch1fE w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AQBGxytX/4gNJK1fgmxMU30GuRkBD?= =?us-ascii?q?YF2JIVsAoEzOBQBAQEBAQEBZSeEQQEBAQQODEsCHgQCAQgRAwEBAQEgAQYHMhQ?= =?us-ascii?q?JCAIEARIUB4gPDr8WAQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSJaYEDhBERATwWh?= =?us-ascii?q?SMFkyWEdQGFe4J3hSaBaIRNiF6PMwEeAQFCggUFFoFLbAEBhnY2fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,584,1454976000"; d="scan'208,217";a="269470638" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 May 2016 22:22:36 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u45MMaVv003749 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 5 May 2016 22:22:36 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 5 May 2016 18:22:35 -0400 Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1104.009; Thu, 5 May 2016 18:22:35 -0400 From: "Ali Sajassi (sajassi)" To: "thomas.morin@orange.com" , IDR , BESS , "draft-ietf-bess-evpn-overlay@tools.ietf.org" , "Rabadan, Jorge (Nokia - US)" , "draft-ietf-idr-tunnel-encap@tools.ietf.org" , John E Drake Thread-Topic: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps Thread-Index: AQHRpi++kmVRnOfCCEaLlUJwLCbjV5+pXciAgAAV74CAABx8AIAAAd6AgAD40oCAAAcLgIAAlB8A//+R2gCAAAKqAA== Date: Thu, 5 May 2016 22:22:35 +0000 Message-ID: References: <5729F1C3.1030605@orange.com> <5729F7C5.6040604@orange.com> <52D35106-ED5E-4C95-9131-6EA4527370D5@alcatel-lucent.com> <012C176C-A8D6-45AA-BA69-616C0ED7E41E@alcatel-lucent.com> <420BA2D8D80A6727.2B2C290F-2299-40BB-B53B-CC36D2B5D826@mail.outlook.com> <1881_1462451514_572B3D3A_1881_7198_1_0vn90oitr7e881gh2sn8qm5f.1462451509961@email.android.com> <17029_1462484835_572BBF63_17029_2323_1_opi9hqsl9b9tani0t0skkcuq.1462484831251@email.android.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.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.76.55] Content-Type: multipart/alternative; boundary="_000_D35113FD196727sajassiciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 22:22:44 -0000 --_000_D35113FD196727sajassiciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Thomas, One other thing regarding your earlier question. In EVPN, we decided long t= ime ago that we=92ll use tunnel type extended community but not the attribu= te. So, maybe that=92s the =93mis-alignement=94 that John was talking about= but that should not be considered as mis-alignment since EVPN solution fro= m the beginning never needed and rely such attribute - i.e., EVPN precedes = the tunnel attribute definition. Cheers, Ali From: Cisco Employee > Date: Thursday, May 5, 2016 at 3:13 PM To: "thomas.morin@orange.com" >, IDR >, BESS >, "draft-ietf-bess-ev= pn-overlay@tools.ietf.org" >, "Rabadan, Jorge (Nokia - US)" >, "draft-ietf-idr-tunnel-encap@tool= s.ietf.org" >, John E Drake > Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-e= ncaps Hi Thomas, With respect to tunnel type extended community used in evpn-overlay, we can= refer to idr-tunnel-encap instead of RFC5512. However, besides that I don= =92t see any other point of contention that needs resolving. We agreed that there needs to be some clarification with respect locally-as= signed VNI in MPLS field (in EVPN routes versus PTA) for unicast packets ve= rsus BUM packets. Is there any other things that need to be clarified? BTW, thanks for doing a thorough review of the doc. Cheers, Ali From: "thomas.morin@orange.com" > Date: Thursday, May 5, 2016 at 2:47 PM To: IDR >, BESS >, "draft-ietf-bess-evpn-overlay@tools.ietf.org" >, Cisco Employee= >, "Rabadan, Jorge (Nokia - US= )" >, "draft-ietf-i= dr-tunnel-encap@tools.ietf.org" >, John E Drake > Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-e= ncaps Hi John, I have a hard time reconciliating the fact that yesterday you were fine wit= h having bess-evpn-overlay refer to idr-tunnel-encap instead of RFC5512, wi= th the fact that you consider (belox) the two docs "not aligned" for unicas= t. Can you be more explicit in where the "misalignment" lies? -Thomas ---- John E Drake a =E9crit ---- Thomas, The overlay draft preceded the tunnel encaps draft and it was designed to h= andle a very specific problem, marrying the EVPN control plane to the VXLAN= data plane draft and modulo the correction to section 9 it is internally c= onsistent. The tunnel encaps draft solves a more general problem and the WG decided a = long time ago that the overlay draft was not going to be updated to use the= mechanisms it details for unicast, so the overlay draft is already explici= tly not in alignment with it. This, plus the fact that the tunnel encaps draft explicitly puts the PMSI o= ut of scope, leads me to the conclusion that the overlay draft should not b= e tweaked to be in alignment with a future solution for encoding VNIs for m= ulticast. Yours Irrespectively, John From:thomas.morin@orange.com [mailto:thomas= .morin@orange.com] Sent: Thursday, May 05, 2016 8:32 AM To: John E Drake; IDR; BESS; draft-ietf-bess-evpn-overlay@tools.ietf.org; Ali Sajassi (sajassi); R= abadan, Jorge (Nokia - US); draft-ietf-idr-tunnel-encap@tools.ietf.org Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-e= ncaps Thanks for the clarification on the intent around draft-ietf-bess-evpn-over= lay. Then indeed section 9 needs some tidying up. The issue that I think remain is that it would be much cleaner to explain h= ow to use PMSI with overlay encaps in a spec not specific to E-VPN and in a= way more consistent to what is done for unicast. It seems if course that draft-ietf-idr-tunnel-encap should be the place, bu= t that document currently explicitly makes PMSIs out of scope. Shouldn't this part of draft-ietf-idr-tunnel-encap be revisited ? -Thomas ---- Rabadan, Jorge (Nokia - US) a =E9crit ---- Fully agree John. That's what I meant, sorry if I didn't make myself clear.= Section 9 needs clean up, yes. Thanks, Jorge _____________________________ From: EXT John E Drake > Sent: Wednesday, May 4, 2016 23:34 Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-e= ncaps To: IDR >, Ali Sajassi (sajassi) >, Rabadan, Jorge (Nokia - US) >, BESS <= bess@ietf.org>, >, EXT - thomas.= morin@orange.com > Jorge, We put the VNI value in the MPLS label field of the PMSI attribute for all = service types, and we put a value in the Ethernet Tag field following the r= ules for each service type as described in 5.1.3 (https://tools.ietf.org/ht= ml/draft-ietf-bess-evpn-overlay-02#section-5.1.3). You're right that we need to clean up section 9. Yours Irrespectively, John > -----Original Message----- > From: Rabadan, Jorge (Nokia - US) [mailto:jorge.rabadan@nokia.com] > Sent: Wednesday, May 04, 2016 3:53 PM > To: John E Drake; EXT - thomas.morin@orange.com; BESS; IDR; draft-ietf-bess-evpn- > overlay@tools.ietf.org; Ali Sajassi (sajas= si) > Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel= -encaps > > Hi John, > > About this: > > [JD] For the IMET route the MPLS label field is carried in the PMSI attri= bute. I think we need > to ask everyone whether they used the Ethernet Tag or the PMSI attribute = to carry the VNI > > > In case it helps, I=92ve seen a few implementations running and they all = encode the VNI in the > MPLS label field in the PTA. And a couple of them, encode the VNI in the = ethernet-tag, in > addition to the MPLS label in the PTA. In any case, I think section 9 con= tradicts section 5.1.3 > and should be clarified. > > "5.1.3 Constructing EVPN BGP Routes > > the MPLS label field in the MAC Advertisement, Ethernet AD per EVI, and *= *Inclusive > Multicast Ethernet Tag** routes is used to carry the VNI or VSID." > > Thanks. > Jorge > > > > > > On 5/4/16, 8:34 PM, "EXT John E Drake" > wrote: > > >Thomas and Jorge, > > > >Snipped, comments inline. > > > >Yours Irrespectively, > > > >John > > > >> > > >> >draft-ietf-bess-evpn-overlay (see section 9) relies on the BGP > >> >Encapsulation extended to encode the tunnel encap to use for BUM > >> >traffic, but contrary to other E-VPN routes, relies on the Ethernet > >> >Tag field of the NLRI to encode the VNI/VSID. > >> > >> [JORGE] This is certainly a leftover from an old version where the > >> VNI/VSID was encoded in the ethernet tag for all the routes. The VNI > >> should be encoded in the Label field in all the routes. This has to be= corrected. > >> > >> In fact, section 5.1.3 says: > >> > >> 5.1.3 Constructing EVPN BGP Routes > >> > >> > >> > >> Accordingly, and > >> specifically to support the option of locally assigned VNIs, the MPLS > >> label field in the MAC Advertisement, Ethernet AD per EVI, and > >> Inclusive Multicast Ethernet Tag routes is used to carry the VNI or > >> VSID. For the balance of this memo, the MPLS label field will be > >> referred to as the VNI/VSID field. The VNI/VSID field is used for > >> both local and global VNIs/VSIDs, and for either case the entire 24- > >> bit field is used to encode the VNI/VSID value. > >> > >> > > > > > >[JD] For the IMET route the MPLS label field is carried in the PMSI attr= ibute. I think we > need to ask everyone whether they > >used the Ethernet Tag or the PMSI attribute to carry the VNI > > > > > >> >> > >> >> There are minor things that could be improved in > >> >> draft-ietf-bess-evpn-overlay wrt. consistency with > >> >> draft-ietf-idr-tunnel-encaps : > >> >> > >> >> * since draft-ietf-idr-tunnel-encaps will deprecate RFC5512, it > >> >> would be better that draft-ietf-bess-evpn-overlay refers to > >> >> draft-ietf-idr-tunnel-encaps and not anymore to RFC5512. > >> > >> [JORGE] I agree, as long as draft-ietf-idr-tunnel-encaps keeps the > >> encapsulation extended community. There are a few implementations > >> using this community and it is enough when only the encapsulation type= is needed. > > > > > >[JD] I agree and the tunnel encaps draft does keep the EC > > > > > >> > >> >> > >> >> * I think it would be better to avoid the explicit list of encap > >> >> types in section 5.1.3, and rather refer to > >> >> draft-ietf-idr-tunnel-encaps instead > >> > >> [JORGE] I agree. > > > > > >[JD] According to IANA, it allocated the five tunnels types to the > >overlay draft so I think we need to keep them > > > > > >> > >> >> * the following minor modification was proposed, but not yet incorp= orated: > >> >> > >> >> John Drake, 2015-11-13 (to BESS ML): > >> >>> For the overlay draft, replace this text in section 5.1.3: > >> >>> > >> >>> "If the BGP Encapsulation extended community is not present, > >> >>> then the default MPLS encapsulation or a statically configured > >> >>> encapsulation is assumed." > >> >>> > >> >>> With the following: > >> >>> > >> >>> "Note that the MPLS encapsulation tunnel type is needed in > >> >>> order to distinguish between an advertising node that only > >> >>> supports non-MPLS encapsulations and one that supports MPLS and > >> >>> non-MPLS encapsulations. An advertising node that only supports > >> >>> MPLS encapsulation does not need to advertise any encapsulation > >> >>> tunnel types; i.e., if the BGP Encapsulation extended community > >> >>> is not present, then either MPLS encapsulation or a statically > >> >>> configured encapsulation is assumed." > >> >> > >> >> I think this change is useful and should be incorporated, although > >> >> skipping the last sentence would be wise if the full list of > >> >> tunnel types is removed. > > > > > >[JD] Fine with me either w/ or w/o the last sentence > > > > ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_D35113FD196727sajassiciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <50563F4DFB95C9429E106D59E37D85F9@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

Hi Thomas, 

One other thing regarding your earlier question. In EVPN, we decided l= ong time ago that we=92ll use tunnel type extended community but not the at= tribute. So, maybe that=92s the =93mis-alignement=94 that John was talking = about but that should not be considered as mis-alignment since EVPN solution from the beginning never needed and r= ely such attribute - i.e., EVPN precedes the tunnel attribute definition.

Cheers,
Ali 

From: Cisco Employee <sajassi@cisco.com>
Date: Thursday, May 5, 2016 at 3:13= PM
To: "thomas.morin@orange.com" <thomas.morin@orange.com>, IDR <idr@ietf.org>, BESS <bess@ietf.org>, "draft= -ietf-bess-evpn-overlay@tools.ietf.org" <draft-ietf-bess-evpn-overlay@tools= .ietf.org>, "Rabadan, Jorge (Nokia - US)" <jorge.rabadan@nokia.com>, "draft-= ietf-idr-tunnel-encap@tools.ietf.org" <draft-ietf-idr-tunnel-encap@tools.iet= f.org>, John E Drake <jdrak= e@juniper.net>
Subject: Re: [Idr] draft-ietf-bess-= evpn-overlay vs. draft-ietf-idr-tunnel-encaps


Hi Thomas,

With respect to tunnel type extended community used in evpn-overlay, w= e can refer to idr-tunnel-encap instead of RFC5512. However, besides that I= don=92t see any other point of contention that needs resolving. 

We agreed that there needs to be some clarification with respect local= ly-assigned VNI in MPLS field (in EVPN routes versus PTA) for unicast packe= ts versus BUM packets.

Is there any other things that need to be clarified? 

BTW, thanks for doing a thorough review of the doc.

Cheers,
Ali



From: "thomas.morin@orange.com" <thomas.morin@orange.com>
Date: Thursday, May 5, 2016 at 2:47= PM
To: IDR <idr@ietf.org>, BESS <be= ss@ietf.org>, "draft-ietf-bess-evpn-overlay@tools.ietf.org" <draft-i= etf-bess-evpn-overlay@tools.ietf.org>, Cisco Employee <sajassi@cisco.com>, "Rabadan, Jorge = (Nokia - US)" <jorge.rab= adan@nokia.com>, "draft-= ietf-idr-tunnel-encap@tools.ietf.org" <draft-ietf-idr-tunnel-encap@tools.iet= f.org>, John E Drake <jdrak= e@juniper.net>
Subject: RE: [Idr] draft-ietf-bess-= evpn-overlay vs. draft-ietf-idr-tunnel-encaps

Hi John,

I have a hard time reconciliating the fact that yesterday you were fine wit= h having bess-evpn-overlay refer to idr-tunnel-encap instead of RFC5512, wi= th the fact that you consider (belox) the two docs "not aligned" = for unicast.

Can you be more explicit in where the "misalignment" lies?

-Thomas

---- John E Drake a =E9crit ----

Thomas,

 

The overlay draft preceded the tunn= el encaps draft and it was designed to handle a very specific problem, marr= ying the EVPN control plane to the VXLAN data plane draft and modulo the correction to section 9 it is internally c= onsistent.

 

The tunnel encaps draft solves a mo= re general problem and the WG decided a long time ago that the overlay draf= t was not going to be updated to use the mechanisms it details for unicast, so the overlay draft is already exp= licitly not in alignment with it.

 

This, plus the fact that the tunnel= encaps draft explicitly puts the PMSI out of scope, leads me to the conclu= sion that the overlay draft should not be tweaked to be in alignment with a future solution for encoding VNIs for= multicast.

 

Yours Irrespectively,

 

John

 

From:thomas= .morin@orange.com [mailto:th= omas.morin@orange.com]
Sent: Thursday, May 05, 2016 8:32 AM
To: John E Drake; IDR; BESS; draft-ietf-bess-evpn-overlay@tools.ietf.org; Ali Sajassi (sajassi); Rab= adan, Jorge (Nokia - US); draft-ietf-id= r-tunnel-encap@tools.ietf.org
Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-t= unnel-encaps

 

Thanks for the clarif= ication on the intent around draft-ietf-bess-evpn-overlay. Then indeed sect= ion 9 needs some tidying up.

The issue that I think remain is that it would be much cleaner to explain h= ow to use PMSI with overlay encaps in a spec not specific to E-VPN and in a= way more consistent to what is done for unicast.

It seems if course that draft-ietf-idr-tunnel-encap should be the place, bu= t that document currently explicitly makes PMSIs out of scope.

Shouldn't this part of draft-ietf-idr-tunnel-encap be revisited ?

-Thomas


---- Rabadan, Jorge (Nokia - US) a =E9crit ----

Fully agree John. Tha= t's what I meant, sorry if I didn't make myself clear. Section 9 needs clea= n up, yes.

Thanks,
Jorge

 

_____________________= ________
From: EXT John E Drake <jdrake@jun= iper.net>
Sent: Wednesday, May 4, 2016 23:34
Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-e= ncaps
To: IDR <idr@ietf.org>, Ali Sajas= si (sajassi) <sajassi@cisco.com= >, Rabadan, Jorge (Nokia - US) <jorge.rabadan@alcatel-lucent.com>, BESS <bess@ietf.org>, <draft-ietf-bess-e= vpn-overlay@tools.ietf.org>, EXT - thomas.morin@orange.com <= thomas.morin@orange.com><= br>

Jorge,

We put the VNI value in the MPLS label field of the PMSI attribute for all = service types, and we put a value in the Ethernet Tag field following the r= ules for each service type as described in 5.1.3 (https://tools.= ietf.org/html/draft-ietf-bess-evpn-overlay-02#section-5.1.3).

You're right that we need to clean up section 9.

Yours Irrespectively,

John

> -----Original Message-----
> From: Rabadan, Jorge (Nokia - US) [mailto:jorge.rabadan@nokia.com]
> Sent: Wednesday, May 04, 2016 3:53 PM
> To: John E Drake; EXT - tho= mas.morin@orange.com; BESS; IDR; draft-ietf-bess-evpn-
> overlay@tools.ietf.org; = Ali Sajassi (sajassi)
> Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tun= nel-encaps
>
> Hi John,
>
> About this:
>
> [JD] For the IMET route the MPLS label field is carried in the PMSI at= tribute. I think we need
> to ask everyone whether they used the Ethernet Tag or the PMSI attribu= te to carry the VNI
>
>
> In case it helps, I=92ve seen a few implementations running and they a= ll encode the VNI in the
> MPLS label field in the PTA. And a couple of them, encode the VNI in t= he ethernet-tag, in
> addition to the MPLS label in the PTA. In any case, I think section 9 = contradicts section 5.1.3
> and should be clarified.
>
> "5.1.3 Constructing EVPN BGP Routes
> <snip>
> the MPLS label field in the MAC Advertisement, Ethernet AD per EVI, an= d **Inclusive
> Multicast Ethernet Tag** routes is used to carry the VNI or VSID."= ;
>
> Thanks.
> Jorge
>
>
>
>
>
> On 5/4/16, 8:34 PM, "EXT John E Drake" <jdrake@juniper.net> wrote:
>
> >Thomas and Jorge,
> >
> >Snipped, comments inline.
> >
> >Yours Irrespectively,
> >
> >John
> >
> >> >
> >> >draft-ietf-bess-evpn-overlay (see section 9) relies on th= e BGP
> >> >Encapsulation extended to encode the tunnel encap to use = for BUM
> >> >traffic, but contrary to other E-VPN routes, relies on th= e Ethernet
> >> >Tag field of the NLRI to encode the VNI/VSID.
> >>
> >> [JORGE] This is certainly a leftover from an old version wher= e the
> >> VNI/VSID was encoded in the ethernet tag for all the routes. = The VNI
> >> should be encoded in the Label field in all the routes. This = has to be corrected.
> >>
> >> In fact, section 5.1.3 says:
> >>
> >> 5.1.3 Constructing EVPN BGP Routes
> >>
> >> <snip>
> >>
> >> Accordingly, and
> >> specifically to support the option of locally assigned VNIs, = the MPLS
> >> label field in the MAC Advertisement, Ethernet AD per EVI, an= d
> >> Inclusive Multicast Ethernet Tag routes is used to carry the = VNI or
> >> VSID. For the balance of this memo, the MPLS label field will= be
> >> referred to as the VNI/VSID field. The VNI/VSID field is used= for
> >> both local and global VNIs/VSIDs, and for either case the ent= ire 24-
> >> bit field is used to encode the VNI/VSID value.
> >>
> >> <snip>
> >
> >
> >[JD] For the IMET route the MPLS label field is carried in the PMS= I attribute. I think we
> need to ask everyone whether they
> >used the Ethernet Tag or the PMSI attribute to carry the VNI
> >
> >
> >> >>
> >> >> There are minor things that could be improved in
> >> >> draft-ietf-bess-evpn-overlay wrt. consistency with > >> >> draft-ietf-idr-tunnel-encaps :
> >> >>
> >> >> * since draft-ietf-idr-tunnel-encaps will deprecate = RFC5512, it
> >> >> would be better that draft-ietf-bess-evpn-overlay re= fers to
> >> >> draft-ietf-idr-tunnel-encaps and not anymore to RFC5= 512.
> >>
> >> [JORGE] I agree, as long as draft-ietf-idr-tunnel-encaps keep= s the
> >> encapsulation extended community. There are a few implementat= ions
> >> using this community and it is enough when only the encapsula= tion type is needed.
> >
> >
> >[JD] I agree and the tunnel encaps draft does keep the EC
> >
> >
> >>
> >> >>
> >> >> * I think it would be better to avoid the explicit l= ist of encap
> >> >> types in section 5.1.3, and rather refer to
> >> >> draft-ietf-idr-tunnel-encaps instead
> >>
> >> [JORGE] I agree.
> >
> >
> >[JD] According to IANA, it allocated the five tunnels types to the=
> >overlay draft so I think we need to keep them
> >
> >
> >>
> >> >> * the following minor modification was proposed, but= not yet incorporated:
> >> >>
> >> >> John Drake, 2015-11-13 (to BESS ML):
> >> >>> For the overlay draft, replace this text in sect= ion 5.1.3:
> >> >>>
> >> >>> "If the BGP Encapsulation extended communit= y is not present,
> >> >>> then the default MPLS encapsulation or a statica= lly configured
> >> >>> encapsulation is assumed."
> >> >>>
> >> >>> With the following:
> >> >>>
> >> >>> "Note that the MPLS encapsulation tunnel ty= pe is needed in
> >> >>> order to distinguish between an advertising node= that only
> >> >>> supports non-MPLS encapsulations and one that su= pports MPLS and
> >> >>> non-MPLS encapsulations. An advertising node tha= t only supports
> >> >>> MPLS encapsulation does not need to advertise an= y encapsulation
> >> >>> tunnel types; i.e., if the BGP Encapsulation ext= ended community
> >> >>> is not present, then either MPLS encapsulation o= r a statically
> >> >>> configured encapsulation is assumed."
> >> >>
> >> >> I think this change is useful and should be incorpor= ated, although
> >> >> skipping the last sentence would be wise if the full= list of
> >> >> tunnel types is removed.
> >
> >
> >[JD] Fine with me either w/ or w/o the last sentence
> >
> >

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
/pre>

If you have received this email in error, please notify the sender and=
 delete this message and its attachments.


As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.


Thank you.


______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_D35113FD196727sajassiciscocom_-- From nobody Thu May 5 15:39:54 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6373A12D823; Thu, 5 May 2016 15:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lt78lF2LRUEd; Thu, 5 May 2016 15:39:46 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0137.outbound.protection.outlook.com [65.55.169.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E909A12D76F; Thu, 5 May 2016 15:39:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=dh3ebfZI0g/ogeBG1cSEEWiKDBCRyYLzr/j75nxvGzE=; b=bQdUX1oKYpFuKi7zTHg2pg8Mv+DqKeaU61x3VXUhxZppOz1t1i3bHmJiA+r2vYci0fEfZEhF09GDJxrbbqRUadIRRn/V6JkHYxTRcFyCMWMldYQ+DVh5FO5se5e+VjxnL6n1IZ4RwEoX0xmJmWsrh3C4PKOp1OOXld4dMzmMgCo= Received: from SN1PR0501MB1709.namprd05.prod.outlook.com (10.163.130.155) by SN1PR0501MB1710.namprd05.prod.outlook.com (10.163.130.156) with Microsoft SMTP Server (TLS) id 15.1.477.8; Thu, 5 May 2016 22:38:52 +0000 Received: from SN1PR0501MB1709.namprd05.prod.outlook.com ([10.163.130.155]) by SN1PR0501MB1709.namprd05.prod.outlook.com ([10.163.130.155]) with mapi id 15.01.0477.016; Thu, 5 May 2016 22:38:53 +0000 From: John E Drake To: "EXT - thomas.morin@orange.com" , IDR , BESS , "draft-ietf-bess-evpn-overlay@tools.ietf.org" , "Ali Sajassi (sajassi)" , "Rabadan, Jorge (Nokia - US)" , "draft-ietf-idr-tunnel-encap@tools.ietf.org" Thread-Topic: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps Thread-Index: AQHRpi+6xGM0bynWeUeGN93K6stLXZ+pFtLwgAAZ14CAABtMwIAAAw6AgAD40oCAAALOkIAAmFwAgAAIznA= Date: Thu, 5 May 2016 22:38:52 +0000 Message-ID: References: <5729F1C3.1030605@orange.com> <5729F7C5.6040604@orange.com> <52D35106-ED5E-4C95-9131-6EA4527370D5@alcatel-lucent.com> <012C176C-A8D6-45AA-BA69-616C0ED7E41E@alcatel-lucent.com>, , <420BA2D8D80A6727.2B2C290F-2299-40BB-B53B-CC36D2B5D826@mail.outlook.com> <1881_1462451514_572B3D3A_1881_7198_1_0vn90oitr7e881gh2sn8qm5f.1462451509961@email.android.com>, <17029_1462484835_572BBF63_17029_2323_1_opi9hqsl9b9tani0t0skkcuq.1462484831251@email.android.com> In-Reply-To: <17029_1462484835_572BBF63_17029_2323_1_opi9hqsl9b9tani0t0skkcuq.1462484831251@email.android.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.11] x-ms-office365-filtering-correlation-id: 3fe5b7fd-0bca-4942-eaf7-08d375360914 x-microsoft-exchange-diagnostics: 1; SN1PR0501MB1710; 5:VAseTF38hwEkQZaFlPCk6Vs4j8CHo88zX2RfZWUrYkR74ksFeXWO85/LL2ugjnhV96HKxc25E/bilSLxgnmqYh47Z5KhtxivwfF+NPEa76ZZHFQuNYFeXopvw7oTgBZtTCq5np9U4PXPO2mIWwhU/Q==; 24:ZDKRJ+6ZFZmXPFIQ6g6mDvAmFWPCql0CmawutuCezQfefP5BIvunT2irnUxbPsWD3NeysuepIesHYL/visOwObXkMXfaLG++b/rGuU1KsTY=; 7:84mgyyQIlUTMcKNOpILSSXMi9tnLMe8uB1q8/pqA6Git0LKRVhabUhnrc28Th1+DiA7OgZHK2XGQa6unvSpaL6ST+LYKmb+BbrrIp/CsyZNeImB5nd3+QDVR2zq7geOWAUcASd/z9BUUF0ysMM3AOgF+ww0IRS3x/G/gTNeRBlOdUo2Ima1YnaQaTEHeKSVz x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB1710; x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:SN1PR0501MB1710; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1710; x-forefront-prvs: 0933E9FD8D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(13464003)(24454002)(377424004)(377454003)(93886004)(81166005)(2501003)(19300405004)(33656002)(19617315012)(74316001)(3660700001)(19625215002)(3280700002)(230783001)(77096005)(8936002)(15975445007)(2900100001)(2950100001)(4001150100001)(1220700001)(189998001)(5008740100001)(102836003)(5001770100001)(9686002)(3846002)(790700001)(6116002)(586003)(5004730100002)(87936001)(19580395003)(19580405001)(107886002)(5003600100002)(76576001)(76176999)(54356999)(50986999)(86362001)(66066001)(5890100001)(19609705001)(2906002)(10400500002)(16236675004)(99286002)(5002640100001)(106116001)(122556002)(92566002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB1710; H:SN1PR0501MB1709.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0501MB170976E947BEABC8FD591ED8C77C0SN1PR0501MB1709_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 05 May 2016 22:38:52.8858 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB1710 Archived-At: Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 22:39:51 -0000 --_000_SN1PR0501MB170976E947BEABC8FD591ED8C77C0SN1PR0501MB1709_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thomas, My apologies, I mis-stated the sequence of events. When the tunnel encaps draft was first published it did not carry forward t= he RFC 5512 extended community and it did not propose to obsolete RFC 5512.= There was discussion of using the attribute defined in the tunnel encaps = draft instead of the extended community and we decided to continue to use t= he extended community. So, in that sense we are misaligned with the tunnel= encaps draft. Subsequently, however, the tunnel encaps draft decided to carry forward the= extended community and to obsolete RFC 5512, so we were effectively covere= d by a grandfather clause. However, even though I agreed yesterday to refer to the tunnel encaps draft= instead of RFC 5512 we have an issue with doing this, viz, the overlay dra= ft makes a normative reference to RFC 5512. If we change the normative ref= erence to the tunnel encaps draft we cannot publish the overlay draft until= after the tunnel encaps draft has been published. Given the overlay draft's tardiness, I don't think that's acceptable and wo= uld prefer to continue to refer to RFC 5512. Yours Irrespectively, John From: thomas.morin@orange.com [mailto:thomas.morin@orange.com] Sent: Thursday, May 05, 2016 5:47 PM To: IDR; BESS; draft-ietf-bess-evpn-overlay@tools.ietf.org; Ali Sajassi (sa= jassi); Rabadan, Jorge (Nokia - US); draft-ietf-idr-tunnel-encap@tools.ietf= .org; John E Drake Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-e= ncaps Hi John, I have a hard time reconciliating the fact that yesterday you were fine wit= h having bess-evpn-overlay refer to idr-tunnel-encap instead of RFC5512, wi= th the fact that you consider (belox) the two docs "not aligned" for unicas= t. Can you be more explicit in where the "misalignment" lies? -Thomas ---- John E Drake a =E9crit ---- Thomas, The overlay draft preceded the tunnel encaps draft and it was designed to h= andle a very specific problem, marrying the EVPN control plane to the VXLAN= data plane draft and modulo the correction to section 9 it is internally c= onsistent. The tunnel encaps draft solves a more general problem and the WG decided a = long time ago that the overlay draft was not going to be updated to use the= mechanisms it details for unicast, so the overlay draft is already explici= tly not in alignment with it. This, plus the fact that the tunnel encaps draft explicitly puts the PMSI o= ut of scope, leads me to the conclusion that the overlay draft should not b= e tweaked to be in alignment with a future solution for encoding VNIs for m= ulticast. Yours Irrespectively, John From: thomas.morin@orange.com [mailto:thoma= s.morin@orange.com] Sent: Thursday, May 05, 2016 8:32 AM To: John E Drake; IDR; BESS; draft-ietf-bess-evpn-overlay@tools.ietf.org; Ali Sajassi (sajassi); R= abadan, Jorge (Nokia - US); draft-ietf-idr-tunnel-encap@tools.ietf.org Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-e= ncaps Thanks for the clarification on the intent around draft-ietf-bess-evpn-over= lay. Then indeed section 9 needs some tidying up. The issue that I think remain is that it would be much cleaner to explain h= ow to use PMSI with overlay encaps in a spec not specific to E-VPN and in a= way more consistent to what is done for unicast. It seems if course that draft-ietf-idr-tunnel-encap should be the place, bu= t that document currently explicitly makes PMSIs out of scope. Shouldn't this part of draft-ietf-idr-tunnel-encap be revisited ? -Thomas ---- Rabadan, Jorge (Nokia - US) a =E9crit ---- Fully agree John. That's what I meant, sorry if I didn't make myself clear.= Section 9 needs clean up, yes. Thanks, Jorge _____________________________ From: EXT John E Drake > Sent: Wednesday, May 4, 2016 23:34 Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-e= ncaps To: IDR >, Ali Sajassi (sajassi) >, Rabadan, Jorge (Nokia - US) >, BESS <= bess@ietf.org>, >, EXT - thomas.= morin@orange.com > Jorge, We put the VNI value in the MPLS label field of the PMSI attribute for all = service types, and we put a value in the Ethernet Tag field following the r= ules for each service type as described in 5.1.3 (https://tools.ietf.org/ht= ml/draft-ietf-bess-evpn-overlay-02#section-5.1.3). You're right that we need to clean up section 9. Yours Irrespectively, John > -----Original Message----- > From: Rabadan, Jorge (Nokia - US) [mailto:jorge.rabadan@nokia.com] > Sent: Wednesday, May 04, 2016 3:53 PM > To: John E Drake; EXT - thomas.morin@orange.com; BESS; IDR; draft-ietf-bess-evpn- > overlay@tools.ietf.org; Ali Sajassi (sajas= si) > Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel= -encaps > > Hi John, > > About this: > > [JD] For the IMET route the MPLS label field is carried in the PMSI attri= bute. I think we need > to ask everyone whether they used the Ethernet Tag or the PMSI attribute = to carry the VNI > > > In case it helps, I've seen a few implementations running and they all en= code the VNI in the > MPLS label field in the PTA. And a couple of them, encode the VNI in the = ethernet-tag, in > addition to the MPLS label in the PTA. In any case, I think section 9 con= tradicts section 5.1.3 > and should be clarified. > > "5.1.3 Constructing EVPN BGP Routes > > the MPLS label field in the MAC Advertisement, Ethernet AD per EVI, and *= *Inclusive > Multicast Ethernet Tag** routes is used to carry the VNI or VSID." > > Thanks. > Jorge > > > > > > On 5/4/16, 8:34 PM, "EXT John E Drake" > wrote: > > >Thomas and Jorge, > > > >Snipped, comments inline. > > > >Yours Irrespectively, > > > >John > > > >> > > >> >draft-ietf-bess-evpn-overlay (see section 9) relies on the BGP > >> >Encapsulation extended to encode the tunnel encap to use for BUM > >> >traffic, but contrary to other E-VPN routes, relies on the Ethernet > >> >Tag field of the NLRI to encode the VNI/VSID. > >> > >> [JORGE] This is certainly a leftover from an old version where the > >> VNI/VSID was encoded in the ethernet tag for all the routes. The VNI > >> should be encoded in the Label field in all the routes. This has to be= corrected. > >> > >> In fact, section 5.1.3 says: > >> > >> 5.1.3 Constructing EVPN BGP Routes > >> > >> > >> > >> Accordingly, and > >> specifically to support the option of locally assigned VNIs, the MPLS > >> label field in the MAC Advertisement, Ethernet AD per EVI, and > >> Inclusive Multicast Ethernet Tag routes is used to carry the VNI or > >> VSID. For the balance of this memo, the MPLS label field will be > >> referred to as the VNI/VSID field. The VNI/VSID field is used for > >> both local and global VNIs/VSIDs, and for either case the entire 24- > >> bit field is used to encode the VNI/VSID value. > >> > >> > > > > > >[JD] For the IMET route the MPLS label field is carried in the PMSI attr= ibute. I think we > need to ask everyone whether they > >used the Ethernet Tag or the PMSI attribute to carry the VNI > > > > > >> >> > >> >> There are minor things that could be improved in > >> >> draft-ietf-bess-evpn-overlay wrt. consistency with > >> >> draft-ietf-idr-tunnel-encaps : > >> >> > >> >> * since draft-ietf-idr-tunnel-encaps will deprecate RFC5512, it > >> >> would be better that draft-ietf-bess-evpn-overlay refers to > >> >> draft-ietf-idr-tunnel-encaps and not anymore to RFC5512. > >> > >> [JORGE] I agree, as long as draft-ietf-idr-tunnel-encaps keeps the > >> encapsulation extended community. There are a few implementations > >> using this community and it is enough when only the encapsulation type= is needed. > > > > > >[JD] I agree and the tunnel encaps draft does keep the EC > > > > > >> > >> >> > >> >> * I think it would be better to avoid the explicit list of encap > >> >> types in section 5.1.3, and rather refer to > >> >> draft-ietf-idr-tunnel-encaps instead > >> > >> [JORGE] I agree. > > > > > >[JD] According to IANA, it allocated the five tunnels types to the > >overlay draft so I think we need to keep them > > > > > >> > >> >> * the following minor modification was proposed, but not yet incorp= orated: > >> >> > >> >> John Drake, 2015-11-13 (to BESS ML): > >> >>> For the overlay draft, replace this text in section 5.1.3: > >> >>> > >> >>> "If the BGP Encapsulation extended community is not present, > >> >>> then the default MPLS encapsulation or a statically configured > >> >>> encapsulation is assumed." > >> >>> > >> >>> With the following: > >> >>> > >> >>> "Note that the MPLS encapsulation tunnel type is needed in > >> >>> order to distinguish between an advertising node that only > >> >>> supports non-MPLS encapsulations and one that supports MPLS and > >> >>> non-MPLS encapsulations. An advertising node that only supports > >> >>> MPLS encapsulation does not need to advertise any encapsulation > >> >>> tunnel types; i.e., if the BGP Encapsulation extended community > >> >>> is not present, then either MPLS encapsulation or a statically > >> >>> configured encapsulation is assumed." > >> >> > >> >> I think this change is useful and should be incorporated, although > >> >> skipping the last sentence would be wise if the full list of > >> >> tunnel types is removed. > > > > > >[JD] Fine with me either w/ or w/o the last sentence > > > > ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_SN1PR0501MB170976E947BEABC8FD591ED8C77C0SN1PR0501MB1709_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thomas,

 

My apologies, I mis-stated the sequen= ce of events.

 

When the tunnel encaps draft was firs= t published it did not carry forward the RFC 5512 extended community and it= did not propose to obsolete RFC 5512.  There was discussion of using the attribute defined in the tunnel encaps draft i= nstead of the extended community and we decided to continue to use the exte= nded community.  So, in that sense we are misaligned with the tunnel e= ncaps draft.

 

Subsequently, however, the tunnel enc= aps draft decided to carry forward the extended community and to obsolete R= FC 5512, so we were effectively covered by a grandfather clause.

 

However, even though I agreed yesterd= ay to refer to the tunnel encaps draft instead of RFC 5512 we have an issue= with doing this, viz, the overlay draft makes a normative reference to RFC 5512.  If we change the normative refere= nce to the tunnel encaps draft we cannot publish the overlay draft until af= ter the tunnel encaps draft has been published.

 

Given the overlay draft’s tardi= ness, I don’t think that’s acceptable and would prefer to conti= nue to refer to RFC 5512.

 

Yours Irrespectively,

 

John

 

From: thomas.morin@orange.com [mailt= o:thomas.morin@orange.com]
Sent: Thursday, May 05, 2016 5:47 PM
To: IDR; BESS; draft-ietf-bess-evpn-overlay@tools.ietf.org; Ali Saja= ssi (sajassi); Rabadan, Jorge (Nokia - US); draft-ietf-idr-tunnel-encap@too= ls.ietf.org; John E Drake
Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-t= unnel-encaps

 

Hi John,

I have a hard time reconciliating the fact that yesterday you were fine wit= h having bess-evpn-overlay refer to idr-tunnel-encap instead of RFC5512, wi= th the fact that you consider (belox) the two docs "not aligned" = for unicast.

Can you be more explicit in where the "misalignment" lies?

-Thomas

---- John E Drake a =E9crit ----

Thomas,

 

The overlay draft preceded the tunnel= encaps draft and it was designed to handle a very specific problem, marryi= ng the EVPN control plane to the VXLAN data plane draft and modulo the correction to section 9 it is internally consistent.<= /span>

 

The tunnel encaps draft solves a more= general problem and the WG decided a long time ago that the overlay draft = was not going to be updated to use the mechanisms it details for unicast, so the overlay draft is already explicitly not in = alignment with it.

 

This, plus the fact that the tunnel e= ncaps draft explicitly puts the PMSI out of scope, leads me to the conclusi= on that the overlay draft should not be tweaked to be in alignment with a future solution for encoding VNIs for multicast.=

 

Yours Irrespectively,

 

John

 

From: thomas.morin@orange.com [mailto:thomas.morin@orange.com]
Sent: Thursday, May 05, 2016 8:32 AM
To: John E Drake; IDR; BESS; draft-ietf-bess-evpn-overlay@tools.ietf.org; Ali Sajassi (sajassi); Rab= adan, Jorge (Nokia - US); draft-ietf-id= r-tunnel-encap@tools.ietf.org
Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-t= unnel-encaps

 

Thanks for the clarif= ication on the intent around draft-ietf-bess-evpn-overlay. Then indeed sect= ion 9 needs some tidying up.

The issue that I think remain is that it would be much cleaner to explain h= ow to use PMSI with overlay encaps in a spec not specific to E-VPN and in a= way more consistent to what is done for unicast.

It seems if course that draft-ietf-idr-tunnel-encap should be the place, bu= t that document currently explicitly makes PMSIs out of scope.

Shouldn't this part of draft-ietf-idr-tunnel-encap be revisited ?

-Thomas


---- Rabadan, Jorge (Nokia - US) a =E9crit ----

Fully agree John. Tha= t's what I meant, sorry if I didn't make myself clear. Section 9 needs clea= n up, yes.

Thanks,
Jorge

 

_____________________= ________
From: EXT John E Drake <jdrake@jun= iper.net>
Sent: Wednesday, May 4, 2016 23:34
Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-e= ncaps
To: IDR <idr@ietf.org>, Ali Sajas= si (sajassi) <sajassi@cisco.com= >, Rabadan, Jorge (Nokia - US) <jorge.rabadan@alcatel-lucent.com>, BESS <bess@ietf.org>, <draft-ietf-bess-e= vpn-overlay@tools.ietf.org>, EXT - thomas.morin@orange.com <= thomas.morin@orange.com><= br>

Jorge,

We put the VNI value in the MPLS label field of the PMSI attribute for all = service types, and we put a value in the Ethernet Tag field following the r= ules for each service type as described in 5.1.3 (https://tools.= ietf.org/html/draft-ietf-bess-evpn-overlay-02#section-5.1.3).

You're right that we need to clean up section 9.

Yours Irrespectively,

John

> -----Original Message-----
> From: Rabadan, Jorge (Nokia - US) [mailto:jorge.rabadan@nokia.com]
> Sent: Wednesday, May 04, 2016 3:53 PM
> To: John E Drake; EXT - tho= mas.morin@orange.com; BESS; IDR; draft-ietf-bess-evpn-
> overlay@tools.ietf.org; = Ali Sajassi (sajassi)
> Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tun= nel-encaps
>
> Hi John,
>
> About this:
>
> [JD] For the IMET route the MPLS label field is carried in the PMSI at= tribute. I think we need
> to ask everyone whether they used the Ethernet Tag or the PMSI attribu= te to carry the VNI
>
>
> In case it helps, I’ve seen a few implementations running and th= ey all encode the VNI in the
> MPLS label field in the PTA. And a couple of them, encode the VNI in t= he ethernet-tag, in
> addition to the MPLS label in the PTA. In any case, I think section 9 = contradicts section 5.1.3
> and should be clarified.
>
> "5.1.3 Constructing EVPN BGP Routes
> <snip>
> the MPLS label field in the MAC Advertisement, Ethernet AD per EVI, an= d **Inclusive
> Multicast Ethernet Tag** routes is used to carry the VNI or VSID."= ;
>
> Thanks.
> Jorge
>
>
>
>
>
> On 5/4/16, 8:34 PM, "EXT John E Drake" <jdrake@juniper.net> wrote:
>
> >Thomas and Jorge,
> >
> >Snipped, comments inline.
> >
> >Yours Irrespectively,
> >
> >John
> >
> >> >
> >> >draft-ietf-bess-evpn-overlay (see section 9) relies on th= e BGP
> >> >Encapsulation extended to encode the tunnel encap to use = for BUM
> >> >traffic, but contrary to other E-VPN routes, relies on th= e Ethernet
> >> >Tag field of the NLRI to encode the VNI/VSID.
> >>
> >> [JORGE] This is certainly a leftover from an old version wher= e the
> >> VNI/VSID was encoded in the ethernet tag for all the routes. = The VNI
> >> should be encoded in the Label field in all the routes. This = has to be corrected.
> >>
> >> In fact, section 5.1.3 says:
> >>
> >> 5.1.3 Constructing EVPN BGP Routes
> >>
> >> <snip>
> >>
> >> Accordingly, and
> >> specifically to support the option of locally assigned VNIs, = the MPLS
> >> label field in the MAC Advertisement, Ethernet AD per EVI, an= d
> >> Inclusive Multicast Ethernet Tag routes is used to carry the = VNI or
> >> VSID. For the balance of this memo, the MPLS label field will= be
> >> referred to as the VNI/VSID field. The VNI/VSID field is used= for
> >> both local and global VNIs/VSIDs, and for either case the ent= ire 24-
> >> bit field is used to encode the VNI/VSID value.
> >>
> >> <snip>
> >
> >
> >[JD] For the IMET route the MPLS label field is carried in the PMS= I attribute. I think we
> need to ask everyone whether they
> >used the Ethernet Tag or the PMSI attribute to carry the VNI
> >
> >
> >> >>
> >> >> There are minor things that could be improved in
> >> >> draft-ietf-bess-evpn-overlay wrt. consistency with > >> >> draft-ietf-idr-tunnel-encaps :
> >> >>
> >> >> * since draft-ietf-idr-tunnel-encaps will deprecate = RFC5512, it
> >> >> would be better that draft-ietf-bess-evpn-overlay re= fers to
> >> >> draft-ietf-idr-tunnel-encaps and not anymore to RFC5= 512.
> >>
> >> [JORGE] I agree, as long as draft-ietf-idr-tunnel-encaps keep= s the
> >> encapsulation extended community. There are a few implementat= ions
> >> using this community and it is enough when only the encapsula= tion type is needed.
> >
> >
> >[JD] I agree and the tunnel encaps draft does keep the EC
> >
> >
> >>
> >> >>
> >> >> * I think it would be better to avoid the explicit l= ist of encap
> >> >> types in section 5.1.3, and rather refer to
> >> >> draft-ietf-idr-tunnel-encaps instead
> >>
> >> [JORGE] I agree.
> >
> >
> >[JD] According to IANA, it allocated the five tunnels types to the=
> >overlay draft so I think we need to keep them
> >
> >
> >>
> >> >> * the following minor modification was proposed, but= not yet incorporated:
> >> >>
> >> >> John Drake, 2015-11-13 (to BESS ML):
> >> >>> For the overlay draft, replace this text in sect= ion 5.1.3:
> >> >>>
> >> >>> "If the BGP Encapsulation extended communit= y is not present,
> >> >>> then the default MPLS encapsulation or a statica= lly configured
> >> >>> encapsulation is assumed."
> >> >>>
> >> >>> With the following:
> >> >>>
> >> >>> "Note that the MPLS encapsulation tunnel ty= pe is needed in
> >> >>> order to distinguish between an advertising node= that only
> >> >>> supports non-MPLS encapsulations and one that su= pports MPLS and
> >> >>> non-MPLS encapsulations. An advertising node tha= t only supports
> >> >>> MPLS encapsulation does not need to advertise an= y encapsulation
> >> >>> tunnel types; i.e., if the BGP Encapsulation ext= ended community
> >> >>> is not present, then either MPLS encapsulation o= r a statically
> >> >>> configured encapsulation is assumed."
> >> >>
> >> >> I think this change is useful and should be incorpor= ated, although
> >> >> skipping the last sentence would be wise if the full= list of
> >> >> tunnel types is removed.
> >
> >
> >[JD] Fine with me either w/ or w/o the last sentence
> >
> >

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
--_000_SN1PR0501MB170976E947BEABC8FD591ED8C77C0SN1PR0501MB1709_-- From nobody Thu May 5 16:37:28 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5A912D516 for ; Thu, 5 May 2016 16:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.895 X-Spam-Level: X-Spam-Status: No, score=-2.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CI5BVVS537Fp for ; Thu, 5 May 2016 16:37:24 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 920D712D0AE for ; Thu, 5 May 2016 16:37:23 -0700 (PDT) Received: from [199.87.120.129] (helo=jivecommunications.com) by cappuccino.rob.sh with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1aySpL-0003jL-6Z; Fri, 06 May 2016 00:37:03 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_DF117CF9-0CFC-46B2-BFDE-E228FAF3D683" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Rob Shakir In-Reply-To: Date: Thu, 5 May 2016 17:37:21 -0600 Message-Id: <9D9C2E06-9D20-4D24-B41E-FE0A0D43B65A@rob.sh> References: To: Ajay L X-Mailer: Apple Mail (2.3124) Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] Question about BGP mandatory attribute missing behavior X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 23:37:27 -0000 --Apple-Mail=_DF117CF9-0CFC-46B2-BFDE-E228FAF3D683 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Ajay, > On 29 Apr, 2016, at 2:08 PM, Ajay L wrote: >=20 > The section on NOTIFICATION message says that BGP connection is closed = immediately after sending it. So in my scenario, looks like the expected = behavior is to send NOTIFICATION message with details of the first = detected missing mandatory attribute and close the connection. Please = let me know if this interpretation is not correct An implementation is not expected to send more than one NOTIFICATION = message upon encountering an erroneous UPDATE message. Once an error has = been encountered, and NOTIFICATION has been transmitted; the sending BGP = speaker is expected to close the connection.=20 It is worth noting that the error handling behaviour of when = NOTIFICATION messages are transmitted was modified by RFC7606. Section 3 = of RFC7606 addresses the case of missing well known mandatory fields: d. If any of the well-known mandatory attributes are not present in an UPDATE message, then "treat-as-withdraw" MUST be used. (Note that [RFC4760 ] reclassifies = NEXT_HOP as what is effectively discretionary.) i.e., where a speaker is compliant with RFC7606, then NOTIFICATION = should not be sent in this scenario. Kind regards, r.= --Apple-Mail=_DF117CF9-0CFC-46B2-BFDE-E228FAF3D683 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi Ajay,

On 29 Apr, 2016, at 2:08 PM, = Ajay L <ajayl.bro@gmail.com> wrote:

The section on NOTIFICATION message = says that BGP connection is closed immediately after sending it. So in = my scenario, looks like the expected behavior is to send NOTIFICATION = message with details of the first detected missing mandatory attribute = and close the connection. Please let me know if this interpretation is = not correct

An implementation is not expected to send = more than one NOTIFICATION message upon encountering an erroneous UPDATE = message. Once an error has been encountered, and NOTIFICATION has been = transmitted; the sending BGP speaker is expected to close the = connection. 

It is worth noting = that the error handling behaviour of when NOTIFICATION messages are = transmitted was modified by RFC7606. Section 3 of RFC7606 addresses the = case of missing well known mandatory fields:

   d.  If any of the well-known =
mandatory attributes are not present in
       an UPDATE message, then "treat-as-withdraw" MUST be used.  (Note
       that [RFC4760] reclassifies NEXT_HOP as what is effectively
       discretionary.)

i.e., where a speaker is compliant with RFC7606, then = NOTIFICATION should not be sent in this scenario.
Kind regards,
r.
= --Apple-Mail=_DF117CF9-0CFC-46B2-BFDE-E228FAF3D683-- From nobody Thu May 5 16:44:06 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA6612D0AE for ; Thu, 5 May 2016 16:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwdRE80ZZtFV for ; Thu, 5 May 2016 16:44:03 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E09912D522 for ; Thu, 5 May 2016 16:44:02 -0700 (PDT) Received: from [199.87.120.129] (helo=jivecommunications.com) by cappuccino.rob.sh with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1aySvm-0003km-DX; Fri, 06 May 2016 00:43:42 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Rob Shakir In-Reply-To: Date: Thu, 5 May 2016 17:44:01 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: marco@lamehost.it X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Idr@ietf.org Subject: Re: [Idr] Status of BGP OPERATIONAL Message X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 23:44:05 -0000 Hi Marco, > On 5 Apr, 2016, at 5:58 AM, marco@lamehost.it wrote: >=20 > I have read the threads regarding draft-frs-bgp-operational-message = and i wonder if there are actual plans for deploying the it or not. >=20 > The reason I am asking is that I see value in a mechanism that = advertises the value of MAXPREFIX to the BGP peer which the above can = handle with the ADVISE TLVs. >=20 > My feeling is that BGP OPERATIONAL Message goes behind the scope and = transforms BGP in a general-purpose network messaging queue, but if = there are plans to implement that I would prefer to wait than to suggest = to re-invent the wheel. At the time, there was some interest in implementing this mechanism, and = I believe that it was implemented in Quagga (or at least a patch = exists). Our intention with this draft was to introduce a message type = that allowed for information that related to the state of a session, not = necessarily to a set of NLRI to be advertised across a BGP session. = Robert, David and I have discussed resuscitating this draft, and if you = have a use-case that would fit into it, we could definitely try and = include that. If you were to be advertising the value of a maximum prefix using an = alternate mechanism, how would this be carried? It seems strange to do = it in an OPEN message, since the value may change throughout the = lifetime of the session, and including it in an UPDATE message would = also be somewhat strange because it is not clear that it would be linked = to any particular NLRI. We have rather overloaded the semantics of an = UPDATE message with null NLRI already, so I=E2=80=99m not clear there = would be a neat way that you could transmit this information in a way = that did not end up declaring something that looked like the OPERATIONAL = message and subsequent NLRIs. Best, r.= From nobody Thu May 5 17:04:32 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0059A12B033 for ; Thu, 5 May 2016 17:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6T3cvkGeMub for ; Thu, 5 May 2016 17:04:28 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FF6A12B00F for ; Thu, 5 May 2016 17:04:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CJH13101; Fri, 06 May 2016 00:04:26 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 6 May 2016 01:04:24 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Fri, 6 May 2016 08:04:20 +0800 From: Zhuangshunwan To: Rob Shakir , "marco@lamehost.it" Thread-Topic: [Idr] Status of BGP OPERATIONAL Message Thread-Index: AQHRpygL2xceG5lGFEa8p0WSXOFp7p+rAs1w Date: Fri, 6 May 2016 00:04:20 +0000 Message-ID: <19AB2A007F56DB4E8257F949A2FB9858AA1B4037@NKGEML515-MBX.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.86.254] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.572BDF8A.005F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 2c9f2a748357d8a061afebe7dc8d78f9 Archived-At: Cc: "Idr@ietf.org" Subject: Re: [Idr] Status of BGP OPERATIONAL Message X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 00:04:31 -0000 SGksDQoNCkFib3V0IHRoZSBmb2xsb3dpbmcgcmVxdWlyZW1lbnQ6DQoiPiBUaGUgcmVhc29uIEkg YW0gYXNraW5nIGlzIHRoYXQgSSBzZWUgdmFsdWUgaW4gYSBtZWNoYW5pc20gdGhhdCBhZHZlcnRp c2VzIHRoZSB2YWx1ZSBvZiBNQVhQUkVGSVggdG8gdGhlIEJHUCBwZWVyIHdoaWNoIHRoZSBhYm92 ZSBjYW4gaGFuZGxlIHdpdGggdGhlIEFEVklTRSBUTFZzLiINCg0KSWYgYSBCR1Agc3BlYWtlciB3 YW50cyB0byBhZHZlcnRpc2UgdGhlIHZhbHVlIG9mIE1BWFBSRUZJWCB0byBpdHMgcGVlciwgSSBu b3RpY2UgdGhhdCB0aGVyZSBoYWQgYmVlbiAyIGV4cGlyZWQgZHJhZnRzIHRvIGFkZHJlc3Mgc3Vj aCByZXF1aXJlbWVudDoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtY2hhdmFsaS1i Z3AtcHJlZml4bGltaXQtMDIudHh0DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWtl eXVyLXByZWZpeGxpbWl0LW9yZi0wMC50eHQNCg0KRG8gd2UgcmVhbGx5IG5lZWQgc3VjaCBhIGZl YXR1cmU/DQoNCkJlc3QgUmVnYXJkcywNClNodW53YW4NCg0KLS0tLS3pgq7ku7bljp/ku7YtLS0t LQ0K5Y+R5Lu25Lq6OiBJZHIgW21haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIFJv YiBTaGFraXINCuWPkemAgeaXtumXtDogMjAxNuW5tDXmnIg25pelIDc6NDQNCuaUtuS7tuS6ujog bWFyY29AbGFtZWhvc3QuaXQNCuaKhOmAgTogSWRyQGlldGYub3JnDQrkuLvpopg6IFJlOiBbSWRy XSBTdGF0dXMgb2YgQkdQIE9QRVJBVElPTkFMIE1lc3NhZ2UNCg0KSGkgTWFyY28sDQoNCj4gT24g NSBBcHIsIDIwMTYsIGF0IDU6NTggQU0sIG1hcmNvQGxhbWVob3N0Lml0IHdyb3RlOg0KPiANCj4g SSBoYXZlIHJlYWQgdGhlIHRocmVhZHMgcmVnYXJkaW5nIGRyYWZ0LWZycy1iZ3Atb3BlcmF0aW9u YWwtbWVzc2FnZSBhbmQgaSB3b25kZXIgaWYgdGhlcmUgYXJlIGFjdHVhbCBwbGFucyBmb3IgZGVw bG95aW5nIHRoZSBpdCBvciBub3QuDQo+IA0KPiBUaGUgcmVhc29uIEkgYW0gYXNraW5nIGlzIHRo YXQgSSBzZWUgdmFsdWUgaW4gYSBtZWNoYW5pc20gdGhhdCBhZHZlcnRpc2VzIHRoZSB2YWx1ZSBv ZiBNQVhQUkVGSVggdG8gdGhlIEJHUCBwZWVyIHdoaWNoIHRoZSBhYm92ZSBjYW4gaGFuZGxlIHdp dGggdGhlIEFEVklTRSBUTFZzLg0KPiANCj4gTXkgZmVlbGluZyBpcyB0aGF0IEJHUCBPUEVSQVRJ T05BTCBNZXNzYWdlIGdvZXMgYmVoaW5kIHRoZSBzY29wZSBhbmQgdHJhbnNmb3JtcyBCR1AgaW4g YSBnZW5lcmFsLXB1cnBvc2UgbmV0d29yayBtZXNzYWdpbmcgcXVldWUsIGJ1dCBpZiB0aGVyZSBh cmUgcGxhbnMgdG8gaW1wbGVtZW50IHRoYXQgSSB3b3VsZCBwcmVmZXIgdG8gd2FpdCB0aGFuIHRv IHN1Z2dlc3QgdG8gcmUtaW52ZW50IHRoZSB3aGVlbC4NCg0KQXQgdGhlIHRpbWUsIHRoZXJlIHdh cyBzb21lIGludGVyZXN0IGluIGltcGxlbWVudGluZyB0aGlzIG1lY2hhbmlzbSwgYW5kIEkgYmVs aWV2ZSB0aGF0IGl0IHdhcyBpbXBsZW1lbnRlZCBpbiBRdWFnZ2EgKG9yIGF0IGxlYXN0IGEgcGF0 Y2ggZXhpc3RzKS4gT3VyIGludGVudGlvbiB3aXRoIHRoaXMgZHJhZnQgd2FzIHRvIGludHJvZHVj ZSBhIG1lc3NhZ2UgdHlwZSB0aGF0IGFsbG93ZWQgZm9yIGluZm9ybWF0aW9uIHRoYXQgcmVsYXRl ZCB0byB0aGUgc3RhdGUgb2YgYSBzZXNzaW9uLCBub3QgbmVjZXNzYXJpbHkgdG8gYSBzZXQgb2Yg TkxSSSB0byBiZSBhZHZlcnRpc2VkIGFjcm9zcyBhIEJHUCBzZXNzaW9uLiBSb2JlcnQsIERhdmlk IGFuZCBJIGhhdmUgZGlzY3Vzc2VkIHJlc3VzY2l0YXRpbmcgdGhpcyBkcmFmdCwgYW5kIGlmIHlv dSBoYXZlIGEgdXNlLWNhc2UgdGhhdCB3b3VsZCBmaXQgaW50byBpdCwgd2UgY291bGQgZGVmaW5p dGVseSB0cnkgYW5kIGluY2x1ZGUgdGhhdC4NCg0KSWYgeW91IHdlcmUgdG8gYmUgYWR2ZXJ0aXNp bmcgdGhlIHZhbHVlIG9mIGEgbWF4aW11bSBwcmVmaXggdXNpbmcgYW4gYWx0ZXJuYXRlIG1lY2hh bmlzbSwgaG93IHdvdWxkIHRoaXMgYmUgY2FycmllZD8gSXQgc2VlbXMgc3RyYW5nZSB0byBkbyBp dCBpbiBhbiBPUEVOIG1lc3NhZ2UsIHNpbmNlIHRoZSB2YWx1ZSBtYXkgY2hhbmdlIHRocm91Z2hv dXQgdGhlIGxpZmV0aW1lIG9mIHRoZSBzZXNzaW9uLCBhbmQgaW5jbHVkaW5nIGl0IGluIGFuIFVQ REFURSBtZXNzYWdlIHdvdWxkIGFsc28gYmUgc29tZXdoYXQgc3RyYW5nZSBiZWNhdXNlIGl0IGlz IG5vdCBjbGVhciB0aGF0IGl0IHdvdWxkIGJlIGxpbmtlZCB0byBhbnkgcGFydGljdWxhciBOTFJJ LiBXZSBoYXZlIHJhdGhlciBvdmVybG9hZGVkIHRoZSBzZW1hbnRpY3Mgb2YgYW4gVVBEQVRFIG1l c3NhZ2Ugd2l0aCBudWxsIE5MUkkgYWxyZWFkeSwgc28gSeKAmW0gbm90IGNsZWFyIHRoZXJlIHdv dWxkIGJlIGEgbmVhdCB3YXkgdGhhdCB5b3UgY291bGQgdHJhbnNtaXQgdGhpcyBpbmZvcm1hdGlv biBpbiBhIHdheSB0aGF0IGRpZCBub3QgZW5kIHVwIGRlY2xhcmluZyBzb21ldGhpbmcgdGhhdCBs b29rZWQgbGlrZSB0aGUgT1BFUkFUSU9OQUwgbWVzc2FnZSBhbmQgc3Vic2VxdWVudCBOTFJJcy4N Cg0KQmVzdCwNCnIuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KSWRyIG1haWxpbmcgbGlzdA0KSWRyQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0K From nobody Fri May 6 03:45:23 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8728A12D117 for ; Fri, 6 May 2016 03:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6ESQe-puJq3 for ; Fri, 6 May 2016 03:45:18 -0700 (PDT) Received: from seele.lamehost.it (seele.lamehost.it [80.76.80.23]) by ietfa.amsl.com (Postfix) with ESMTP id A574C12D09E for ; Fri, 6 May 2016 03:45:17 -0700 (PDT) Received: by seele.lamehost.it (Postfix, from userid 33) id 2C42874387; Fri, 6 May 2016 12:45:16 +0200 (CEST) To: Rob Shakir X-PHP-Originating-Script: 0:rcube.php MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 06 May 2016 12:45:16 +0200 From: Marco Marzetti In-Reply-To: References: Message-ID: <5ef210159401a5eed2c4b77c499e1c25@lamehost.it> X-Sender: marco@lamehost.it User-Agent: Roundcube Webmail/1.1.4 Archived-At: Cc: Idr@ietf.org Subject: Re: [Idr] Status of BGP OPERATIONAL Message X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 10:45:21 -0000 On 2016-05-06 01:44, Rob Shakir wrote: > Hi Marco, > >> On 5 Apr, 2016, at 5:58 AM, marco@lamehost.it wrote: >> >> I have read the threads regarding draft-frs-bgp-operational-message >> and i wonder if there are actual plans for deploying the it or not. >> >> The reason I am asking is that I see value in a mechanism that >> advertises the value of MAXPREFIX to the BGP peer which the above can >> handle with the ADVISE TLVs. >> >> My feeling is that BGP OPERATIONAL Message goes behind the scope and >> transforms BGP in a general-purpose network messaging queue, but if >> there are plans to implement that I would prefer to wait than to >> suggest to re-invent the wheel. > > At the time, there was some interest in implementing this mechanism, > and I believe that it was implemented in Quagga (or at least a patch > exists). Our intention with this draft was to introduce a message type > that allowed for information that related to the state of a session, > not necessarily to a set of NLRI to be advertised across a BGP > session. Robert, David and I have discussed resuscitating this draft, > and if you have a use-case that would fit into it, we could definitely > try and include that. > Hello Rob, I have three cases in my mind: 1) Standard peering (not customer) relationship between two ASes. The value of MAXPREFIX is usually exchanged by email (or if it is very urgent by IRC or phone call) between the NOCs or the peering departments. 2) MPLS-VPN: This is a more interesting scenario because of the strict SLAs and the fact that MAXPREFIX (at least in some cases) is a commercial value a) NNI: Same as of #1 b) UNI: Even if triggered by the customer that sends more than allowed, a down is always perceived as a symptom of bad service. 3) Flowspec: My feeling is that the market will adapt to a discrete number of rules per port or per customer. Triggering MAXPREFIX in this case may be catastrophic because it will remove all the active "rules" until the protection is cleared. For all of the above transmitting the value of MAXPREFIX would improve the quality of the service because: 1) The peer could check the values of the sent/allowed prefixes before sending more. 2) The router could raise an alarm for the advertised prefixes as it does for the received > If you were to be advertising the value of a maximum prefix using an > alternate mechanism, how would this be carried? It seems strange to do > it in an OPEN message, since the value may change throughout the > lifetime of the session, and including it in an UPDATE message would > also be somewhat strange because it is not clear that it would be > linked to any particular NLRI. We have rather overloaded the semantics > of an UPDATE message with null NLRI already, so I’m not clear there > would be a neat way that you could transmit this information in a way > that did not end up declaring something that looked like the > OPERATIONAL message and subsequent NLRIs. > > Best, > r. I agree that you can't send MAXPREFIX within OPEN. I like the idea to make of use RFC5291 (Outbound Route Filtering Capability for BGP-4) by defining a new ORF Type as suggested in https://tools.ietf.org/id/draft-keyur-prefixlimit-orf-00.txt , but i'd retain all the behaviors described in RFC5291 except for "Action" that i'd implement as follows: DENY: Prevent the router from advertising more prefixes when the amount of advertised-prefixes is equal to MAXPREFIX PERMIT: Do nothing (the advertised value is purely informational) Regards -- Marco From nobody Mon May 9 06:22:39 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A1A12D1A1; Mon, 9 May 2016 06:22:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160509132235.4859.35247.idtracker@ietfa.amsl.com> Date: Mon, 09 May 2016 06:22:35 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-rtc-no-rt-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 13:22:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : Route Target Constrained Distribution of Routes with no Route Targets Authors : Eric C. Rosen Keyur Patel Jeffrey Haas Robert Raszuk Filename : draft-ietf-idr-rtc-no-rt-05.txt Pages : 7 Date : 2016-05-09 Abstract: There are a variety of BGP-enabled services in which the originator of a BGP route may attach one or more "Route Targets" to the route. By means of a procedure known as "RT Constrained Distribution" (RTC), a given BGP speaker (call it "B") can announce the set of RTs in which it has interest. The implication is that if a particular route (call it "R") carries any RTs at all, BGP speaker B wants to receive route R if and only if B has announced interest in one of the RTs carried by R. However, if route R does not carry any RTs at all, prior specifications do not make it clear whether B's use of RTC implies that it does not want to receive route R. This has caused interoperability problems in the field, as some implementations of RTC do not allow B to receive R, but some services presuppose that B will receive R. This document updates RFC 4684 by clarifying the effect of the RTC mechanism on routes that do not have any RTs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-rtc-no-rt/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-rtc-no-rt-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-rtc-no-rt-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 10 08:00:09 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D2A312D1D9 for ; Tue, 10 May 2016 08:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7Mvfsu6TANN for ; Tue, 10 May 2016 08:00:03 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0799.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:799]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2F2D12D1E1 for ; Tue, 10 May 2016 08:00:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4Ive+mmH3ZP10pRFrPCCzrF4vWHvtvjtdJO2qwbHXF8=; b=TWVmwnYKZ4Rl9BYmTpdVAVaOWJ+MqY8u3uiExFalMcvTVXpubyy05MOhc1NkTI2bnd9g+wvk5CA38CCcpEVa3kwtpACU9ZvKMb/d9Z5p/vew4UT9GPNTN96gL5Dnd2cmfCHRq+cITQoyu83gFGq9//0BGr/xhIEtaYFS1y/A1OY= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; Received: from [172.29.36.38] (66.129.241.10) by BLUPR05MB197.namprd05.prod.outlook.com (10.255.191.21) with Microsoft SMTP Server (TLS) id 15.1.492.11; Tue, 10 May 2016 14:59:46 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_4DE514E2-4A92-45C9-AC32-FBBE915D246B" MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: <000401d186a5$38fac760$aaf05620$@ndzh.com> Date: Tue, 10 May 2016 10:59:42 -0400 Message-ID: <92C4CCDD-6BF2-4F44-B32F-E4ECF57F9F7C@juniper.net> References: <000401d186a5$38fac760$aaf05620$@ndzh.com> To: "idr@ietf. org" X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.10] X-ClientProxiedBy: BLUPR14CA0057.namprd14.prod.outlook.com (10.163.209.153) To BLUPR05MB197.namprd05.prod.outlook.com (10.255.191.21) X-MS-Office365-Filtering-Correlation-Id: a75fd24f-52a1-407f-2ebd-08d378e3ba14 X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB197; 2:bKMjYvDtGTosfiLuvZCJvj1g2eEAzt7xw0wxLTo3ZDwA+6uF+fCSNAqeDVIKH+rTMTOA9djv/P06XPBVq1rQFCKbi2g8iGJWRcOsUNE4b/mpL9s4k+HYopZcrhXGyWCr+Os97jsMFY4RSrdfJQUn6npa5TDUdN6b/W4in0KV1nytV2Ype/qPLCVmpx3l5uwq; 3:RgjoHZ+8VG/Y9X9NFsGJMFIyqahJBLk3Vfjwwk8umhY0+u/bBiSrrpwKjm+xhuJZswsoc+9UP37FfQ54BTZ1DTyx1H8dIDjdqeVfysMDDrBA4EBJP8Vong7a7DdJV9Ef; 25:t+mJQOXrRo8xK36075DjwBcbV+ZOBZszxIrokSMwgDyFSMgZ9x86tg9WJ9xtaiAeFdX6cr3mOiihsD6JMyTFKNVlFuIe8qhtkGjrxCz/GfslalP6cvVdo62mCQFHz2uJA2nwweB1cxRyMj0KcTK2IFGeu4DAtt/GdlVby5YzLIZL7sDWeOaC/TO2WeB2yYAZrmpi90E/qAn6hsjJqNcRsvRYEliAJCnV4l+w+p3k6Krxc2ML6YtJU3u3mDVQMWdiWt9tsfDtOOpW76E9aQl4Wtj2Lj2lb2LFLTESLutQTrszRiiAQu//MIviizFiHyrGQ5Z6dzv4J/HidU++qA2xQrvqO6CFJW6xlALY6UWlglRP0FPKOwBtcWe5ZG5utrsFnL+PCJ9iZVi1ypj8BdAXqhMzrDQyWYBh11Gg8YN1Pj808X11JDpzu0zK96nxta+1G0gv13KthsmHLp7nE4nL5A== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB197; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB197; 20:wkjGIzo+PEDHpufzS2i7tcSI74BcGzn/g2uZLi4jxxDxkpjMWlakClMvjwG5NEBFAgbSVSzYf7n3FSabWo9NWWfomdnA49MwtQdikb6B3fm1Jz0YVVvFqCMR2mU0YriBm9eA+jUGykOPPg4kRnAA5DIi7tIK1kfpE71nONrwdDHAgt8R5CoLouuhkyg4BxPNeRAl1eKssgv4GhSdG1LozyZA6dgONQ2aAJo43sPz9Ddi/mhX4Rsc2T72sMMmsGVkBwN/CHSgdTPXaGcGCjIPVpHgc79MWqLr8w8DIKfWkQxRo3tG/mf+TsdiO/e/GD9FpgXkCZJ1JfLMDeUGIgZuISWOS1GT5XvaBtrga2I2AaWcSQ1viAelV0ApYde7iX7IBiwfUAsbXlC8G3xZ+g0hRdalpU4CfdtNC0iKK1VQ85l+idKp66UeTuHeEz4lxhM3QzYj9QAyrheLZvu2zZJa9i8bI8JiQqSr2/TCQN/t31dVHye8su4diIT0ALR1O3bo; 4:9CYXszSOOlYFpfJWISFBTyxOieHEWxmXwKQ1id9MhOjFpWIKgcXpWzV0+3QihPsHNpfJ9Oan/PALWW1rRiF0Bavp2FAcBWnge/IPKZTjiqIhDvPUjpCeVU9plB2LHyEUcel79GWL7+byfCTsq4tR7pyVI1ICXbsktPicJXaocD3fWWTleHhaodnmf8A28+MSGnabYXSAdKWeZWoHYW2YxJjZ+zU8SpOXMPqfJmJbNDx72bperVz8RsDNBEuvFEwlIQ5cvGp41QwnfSxptHPGo/y1qU5V64hYuxRt+RTsrmxaZoM5qvcJe2CBdnYgaKbh9ui9m/eUO6sXZvDyLK/+O/rQFKwTlXqgS/kTVt76SFW+6ozcuA63ITM9/0Pyr2oj6kqhzLhVar6SH719cM2H2Q== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:BLUPR05MB197; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB197; X-Forefront-PRVS: 0938781D02 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(24454002)(69234005)(5423002)(377454003)(77096005)(5004730100002)(42186005)(2950100001)(50226002)(4326007)(86362001)(15975445007)(2906002)(81166005)(19580395003)(76176999)(19617315012)(19580405001)(92566002)(57306001)(36756003)(189998001)(512874002)(5008740100001)(3846002)(82746002)(84326002)(229853001)(110136002)(33656002)(50986999)(83716003)(66066001)(6116002)(586003)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB197; H:[172.29.36.38]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR05MB197; 23:Nf8RvPm5LDlTSlwZ/37DV1xqe+oS2/ycRr4kh4jHxN?= =?us-ascii?Q?UMbcHrrGOlXhylCllx8IXxnjS976JZH22+VLoAgJ05S0S46K9YYtIHMtdzQ5?= =?us-ascii?Q?Hx0sv0u5YkaHtFA8ibYg18T0SGwHf8AiVtjkyI3kBLYs6seTBpJig+tqCE4o?= =?us-ascii?Q?vMsHJDsbJ97zTujZMAuZw1kzdFPf0X4wkEHT40aPycu88UthYGPfzkGHrD76?= =?us-ascii?Q?NYAg09ezBqHeaB0ZT+PXZxgUZlJh6QhIiWN70KpkomwNqKK3GZgLNLfbcHoc?= =?us-ascii?Q?uNC86d9UhpUSO0AKk473FqoyzAc0jr4cJppO6oFAui5FVZ2qthOCtpbmJg7n?= =?us-ascii?Q?FnkTAR/iJEDSLhkB7jko0cAHJBF8jsabGicIxonNHn6gu3ONxFVxasd3iQdh?= =?us-ascii?Q?wb69hfq2LoqEmmgmWZBVSg25U5jolfkY0DU1M2oHw+TJWU0fSl+V7SaQ8XG+?= =?us-ascii?Q?3VZ+50v3/RhW7VW4IBsOKx6Vl/K1TmGSMlT0+us8kN6ZcgBpuvzwohytW1h1?= =?us-ascii?Q?H9PYbzsA30GA0aCE34KBDIR0Qi1rnoDGwAz93n4Z7+OjuaKmEyjLuSNnl26W?= =?us-ascii?Q?6CPY/H9/pJjlcvt+rHhboaDaoDhbcjXkMj35RAjIZs3oaIABN9b17CoZt8Qh?= =?us-ascii?Q?wF1tTk0S7pXFmwE3sl9n4dHhO3f2sKR+HPN2ib/U1fhW/bTLQjGfUPv+p/H4?= =?us-ascii?Q?I9Z0qVPIptqt8ElQFUF+mQhUThDBEnotMV6Nu3kP53EZJF0SzNUHI9kOevEm?= =?us-ascii?Q?5pG8R6wPT7EXoMShgCI5NQjf30Bwjdc+p/L24RVxKvUNy3CUXulBcU5LIshy?= =?us-ascii?Q?GhNibS0fz66em857t+q+ePWkCVytL879+z1pMr65fE7kZxu0yxEPLG8zurwo?= =?us-ascii?Q?CcxluhRsizdAaH8MsPdebQI1/M/1IsBv8M/uSABT9gzNL32IlcmlxUa9sKMz?= =?us-ascii?Q?w49rxRCDQ3V0IQtj6y++z2ADyaZZXhdNlHSKpeHbGdXPawyC6cLkEfKtDZen?= =?us-ascii?Q?Zdja2ND7hsiqD8kHMwmVhtGvTCiWFwXzTB0KTZ77iKK/RCg4TiTJ2amRhNQK?= =?us-ascii?Q?BqeAo=3D?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB197; 5:+PcqD3+jyoye64cc0izFF5wvdJG0si5HQzxxOmb/+x3kzHamvNMzJB3T2LT+q2uLmGnot11e9EVhB/mwRER4bU7PxQuVDtPAotbCf1iEFxcOppQxFKGmHTVyRnKnnqVPDw92ttYGnIQhbfORQDV/TA==; 24:8ValRKC3Ob5HsyD6qCIqwAjV3KCjv+Zs2sF1p8CR62edmMrVDgrG6ZLIS73qF/P0J7ULclbca0JDxDI6P14+3uuPZGQW57YienlD+K9Ujh8=; 7:qXlSNgZlP5EqCeCor3VChwlFOD+CNEJuGEyNJCcNk0NXaBVVTq6H2RgF44cjJbVYNOboV9oU30poZbT1phZLw1dg8HOw2gIA856lVFrt50k64IM7gQv25dE8z57ACghhuzIN6Sqf0X5ncQDjNJds4POLo1wjLIt3F+RlQ7ErnGr7yNJMEpYW06jbda6IErjq SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 May 2016 14:59:46.0890 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB197 Archived-At: Cc: Susan Hares Subject: [Idr] adoption of five flowspec drafts [was: Re: WG Adoption call for drafts for Flow Specification option 1 (RFC5575 additions (filters/actions) 3/25 to 4/8/2016 ] X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 15:00:08 -0000 --Apple-Mail=_4DE514E2-4A92-45C9-AC32-FBBE915D246B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Dear WG, The following drafts are accepted as WG documents: draft-eddy-idr-flowspec-packet-rate draft-hao-idr-flowspec-nvo3 draft-liang-idr-bgp-flowspec-label draft-litkowski-idr-flowspec-interface-set draft-yong-idr-flowspec-mpls-match The authors should resubmit as draft-ietf-idr-XXX. = (draft-liang-idr-bgp-flowspec-label resubmit as = draft-ietf-idr-flowspec-label, for consistency.) Authors (and the WG) should note that we're also still discussing the = issues of how to best address ordering and action conflict issues. We = think it's likely we'll have a 5575bis coming along, and possibly a v2 = as well, and related documents (all of the above) will probably need to = be updated to fit into whatever framework we end up with. Just FYI for = the moment. Thanks, --John and Sue > On Mar 25, 2016, at 10:47 AM, Susan Hares wrote: >=20 > IDR WG:=20 > =20 > This begins a 2 week WG Call (3/25 to 4/8/2016) for the set of drafts = to be considered in RFC5575 additions. These options are filters, = actions or critical security additions. The flow specification work has = been a part of the interims since IETF 94 > = https://www.ietf.org/proceedings/interim/2016/02/08/idr/proceedings.html = = > = https://www.ietf.org/proceedings/interim/2016/03/07/idr/proceedings.html = = > =20 > There will be a brief flow specification presentation at IETF 95, and = the email list has select to start with option 1 =E2=80=93 extending = RFC5575. We also will be gathering details on the SDN/NFV use case for = option 2 (new NLRI and Wide Communities support).=20 > =20 > This is a group call for the drafts to be considered in the flow = specification work. For each of the drafts you wish to be considered = Option 1, please indicate:=20 > =20 > 1) If this option is valuable for the DDoS deployments or another = critical deployments, =20 > 2) Do you feel this draft is useful, but not ready for adoption,=20= > 3) Do you feel this draft is a good start for this work.=20 > =20 > The drafts to consider are:=20 > https://datatracker.ietf.org/doc/draft-eddy-idr-flowspec-packet-rate/ = > https://datatracker.ietf.org/doc/draft-hao-idr-flowspec-nvo3/ = > = https://datatracker.ietf.org/doc/draft-hao-idr-flowspec-redirect-tunnel/ = = > = https://datatracker.ietf.org/doc/draft-li-idr-flowspec-redirect-generalize= d-sid/ = > https://datatracker.ietf.org/doc/draft-liang-idr-bgp-flowspec-label/ = > = https://datatracker.ietf.org/doc/draft-litkowski-idr-flowspec-interfaceset= / = > = https://datatracker.ietf.org/doc/draft-vandevelde-idr-flowspec-pat= h-redirect/ = > https://datatracker.ietf.org/doc/draft-yong-idr-flowspec-mpls-match/ = > =20 > And for the ordering of these filters and actions drafts =E2=80=93 the = Option 1 section out of this=20 > https://datatracker.ietf.org/doc/draft-hares-idr-flowspec-combo/ = > (A revised draft with just Option 1 will be posted)=20 > =20 > Sue Hares and John Scudder=20 --Apple-Mail=_4DE514E2-4A92-45C9-AC32-FBBE915D246B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" Dear WG,

The following drafts = are accepted as WG documents:

draft-eddy-idr-flowspec-packet-rate
draft-hao-idr-flowspec-nvo3
draft-liang-idr-bgp-flowspec-label
draft-litkowski-idr-flowspec-interface-set
draft-yong-idr-flowspec-mpls-match

The authors should resubmit as draft-ietf-idr-XXX. = (draft-liang-idr-bgp-flowspec-label resubmit as = draft-ietf-idr-flowspec-label, for consistency.)

Authors (and the WG) should note that we're also still = discussing the issues of how to best address ordering and action = conflict issues. We think it's likely we'll have a 5575bis coming along, = and possibly a v2 as well, and related documents (all of the above) will = probably need to be updated to fit into whatever framework we end up = with. Just FYI for the moment.

Thanks,

--John and Sue

On = Mar 25, 2016, at 10:47 AM, Susan Hares <shares@ndzh.com> = wrote:

IDR WG: 
 
This = begins a 2 week WG Call (3/25 to 4/8/2016) for the set of drafts to be = considered in RFC5575 additions. These options are filters, actions or = critical security additions.  The flow specification work has been = a part of the interims since IETF 94
https://www.ietf.org/proceedings/interim/2016/02/08/idr/proceed= ings.html
 
There will be a brief flow specification presentation at IETF = 95, and the email list has select to start with option 1 =E2=80=93 = extending RFC5575.  We also will be gathering details on the = SDN/NFV use case for option 2 (new NLRI and Wide Communities = support). 
 
This is a = group call for the drafts to be considered in the flow specification = work.  For each of the drafts you wish to be considered Option 1, = please indicate: 
 
1)      If this = option is valuable for the DDoS deployments or another critical = deployments,  
2)      Do you feel = this draft is useful, but not ready for adoption, 
3)      Do you feel = this draft is a good start for this work. 
 
The = drafts to consider are: 
https://datatracker.ietf.org/doc/draft-eddy-idr-flowspec-packet= -rate/
https://datatracker.ietf.org/doc/draft-hao-idr-flowspec-redirec= t-tunnel/
 
And for the ordering of these filters and actions drafts =E2=80= =93 the Option 1 section out of this 
https://datatracker.ietf.org/doc/draft-hares-idr-flowspec-combo= /
(A = revised draft with just Option 1 will be posted) 
 
Sue Hares = and John Scudder 

= --Apple-Mail=_4DE514E2-4A92-45C9-AC32-FBBE915D246B-- From nobody Tue May 10 08:11:03 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 047DC12D1D2 for ; Tue, 10 May 2016 08:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtu5NJPP6FxI for ; Tue, 10 May 2016 08:10:58 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0109.outbound.protection.outlook.com [65.55.169.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F095F12D1C2 for ; Tue, 10 May 2016 08:10:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6bI3fr7PWs/R5veyYSU/BDUit66bVOOJEJ/WxkPVd8o=; b=Bo3AT6XLBoUwMoYWcljypGpJKfPyo/kzgL9yqecX1hE+d1uhacLKKdTMv+eV9vFfEwwtfI9peJjrP4+LotqMkXm3lO42YOAlJz6s2UsglTJ2BlFfTYZandfCkEB8oKKDWjDBpz4w+Phxqmx08mzigp6fH7PpwSmtDPiulmCvH44= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; Received: from [172.29.36.38] (66.129.241.10) by BN1PR05MB202.namprd05.prod.outlook.com (10.255.206.18) with Microsoft SMTP Server (TLS) id 15.1.492.11; Tue, 10 May 2016 15:10:56 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_FBDB0706-3AAE-4342-9210-58AC5917B83C" MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: <000401d186a5$38fac760$aaf05620$@ndzh.com> Date: Tue, 10 May 2016 11:10:50 -0400 Message-ID: References: <000401d186a5$38fac760$aaf05620$@ndzh.com> To: "idr@ietf. org" X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.10] X-ClientProxiedBy: BLUPR19CA0006.namprd19.prod.outlook.com (10.162.230.144) To BN1PR05MB202.namprd05.prod.outlook.com (10.255.206.18) X-MS-Office365-Filtering-Correlation-Id: ea4b91cc-3ec5-4f78-2e44-08d378e54982 X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB202; 2:aBsuaGLPkmp1HfZ8kK4bYnTwn0vJyqEs9qmiZJpMvLjSZmdQF9pyu5OwlRFlA5AIwbiL2py6fDG4rMRgWM3nds9T7MtHYrepyx644lO7xuLlZ5JJseU+LGos8684+aGlyALWZbVnSGjfvYvY6UUc1x+UUb2ve/za9xPp3k0whcFH/qv6Cl9M9VMinEaI4jkA; 3:xkRbUq/b/cpNW8nm7hA9T0pQSZxcimZkcd3SnRv546c7GjDRkqZwAyUd3RwO/Cos5YboQw5j/4BlB1rvhEilnXshiI7o/0MGdMmJvsKprALVpgGv8sJdAIBOhkFupDIg; 25:0JxaRVVi6MClsOJUY+AzxyxtDlqUvGyQsCoGQUBBlobhUV6q6IGzVteGsU/FqBkgAe+8R3TmM0vghpBqTBMDv514tt+e3oqDULdwjpGVtQ8XsP2XT04iEXtYgAPNVBEZ1jFkTnR+C8sXq8tLmNMd8gX9k/xQWuhvWhrqAHGa9FKnOl2mvWSWP/HY4RWdMK4oS4ksptR4920rUleW9h0UQUTir29wHjLPz2ecwcM7nhbFzYIA6/eUh00b2fHQUYdRtjzDiadz4+f7WBr2oj2wS0c4KaP6H1qb7M52wHu6PrMKhZoeDk+dcEkjpE2iNY89osM5od9mnR7iVyasX6atOEZH4751m7qoxtxKra+oKTkn/xIxilOj0Na9Oya2x9Ws1bYpXtU07v38G+WIdVVviBn+xXxJ4mJIqpDJQSes1NnEddJrF1iW9Y/9YGSoptjexTomj1qzJX0enQZpV83pRQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB202; X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB202; 20:VXNInYMBMuGr01yW3Auxpixgqbg7iqJ4hWHXsmYFul8zCKAM1W1uGLKvb/TlAZXclqM9n7URxkoCxOionPO4L/sh0Cp+CvY+NVrjEVl1ehObAG0fBS34kx76jGKbtLpw/GyKEmBcUfNYkStzauCG7NbsA3hpoG5QcRT0sGJnmnNyvaWCHRH/fL83Ekn1XmV2BOB7Aq2laMqtTL/tajYKg6nqGQ20qoxwQBfUs9R2FDK7geQDpn6T5ebine19pQBIXZlXyru/wfSMoBlFOuO07mnLCipGpOKoZ8A/O7LZwiSRNP9aQpLE/JI8dbZ9VgPyWcMJZwBbB3bvPLLMHJ7WPWKiar0jXH9abxS7jA+zCwaFrAA+qBqdc5tzx3Lhc4tgFXkcAQS2N+aygRfcaZlc5r3mrYNf99lz5+mdLnb0+pRLLImFoqxqU3VGj15K3Ul4sjcrcYJG26mcWLP2MwnusS/3T4NfLPE511QSuIbflX4g+QS98RYAW5r/EoAxQuuo; 4:5NDEaCPfUfJuUMtWTUvMJ9VwfyLU8IGLuG93iXJ4VStYA2FK5yeNiOj+IqAU6TmYLYmZEsAxpWTG1L1b8U031LQ9DakxnaNL9yviD6J7ejeV5yUxc3NgBcTucYSLbWN9UdQSO2vYS65fcVKuwxPHSDTjypcUhXNjsVyzXZozBvupGig2H2GKKXGi36AFWUBbaKNjP9uv91eRcBF5Oz62sIAUhIVU+7salHHvNkgr/nVEVMZx/k4rm1M0+5XKMAMOdrkpwD3p4KyKhW2Szje0f3XyLy4yg/x5PjmWW37CqKXsqu+ja0bwVdrDfyemqJnduveRUwF3JboF6i8pqOKsf5M27iRBmf4vfY69qGBjzBxZjhfVHz4k7O9tbPL0OwxI/MX+Ct/6mfGFqKdTLVU65w== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:BN1PR05MB202; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB202; X-Forefront-PRVS: 0938781D02 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(377454003)(51874003)(5423002)(24454002)(42186005)(19580405001)(19580395003)(586003)(4326007)(83716003)(66066001)(110136002)(36756003)(84326002)(50986999)(6116002)(3846002)(92566002)(86362001)(76176999)(77096005)(229853001)(50226002)(5004730100002)(82746002)(189998001)(2906002)(2950100001)(19617315012)(33656002)(57306001)(15975445007)(81166005)(512874002)(5008740100001)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB202; H:[172.29.36.38]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1PR05MB202; 23:QxEqFShCkHAXRQ7tuF3gIT0MlgJuiaso4AX9hO653O?= =?us-ascii?Q?0E0Y6yhNkCA5zTo5xTZYwp4G1e2fcaLAe/rCXsGrKKXVaIGL8sXL6VVJAO92?= =?us-ascii?Q?aVcDNFlaVz/VK702sNvmuxXKlC4nYq6LlBikH9pqgdE5HahunUpgZRNNrOeZ?= =?us-ascii?Q?3Nsfu9uX26j4bbSSOk8u7q5GfOW3Ddc8AMrS/cYJO+eUmW7nhKZolYoXkzgs?= =?us-ascii?Q?kv5Y3kQt2hnGz/4eBpP73f9qEC0Y1KTVoaCt/VeDFOlGXUOajC2OASekqdjx?= =?us-ascii?Q?367DTYUYK7SasBb5ZA2EP2elm23lWDmNczAXMe3lp+ti4WRZghj+OT5X1MQv?= =?us-ascii?Q?7AJx89KDnsMT6G3eYrP+BGuOgH0ToBYtDtIHVChsZ89hntIvFgXCz7C8407d?= =?us-ascii?Q?hz0C64j7KUpj4hQ8ZDZCsbgC2MyuF2oWIu7uf6emjiPZdub9Jm8tdETODxDf?= =?us-ascii?Q?XU17TSeM43MK4WbRzwl2veCqSjaa8aIgRy8SJf+pxgNzHHtKaAhHigDBGSpF?= =?us-ascii?Q?b1DZNj+bJAicQxAKXt9OLfqR4bEzt6FWhJmYWZqygVIesLrn5tgNbobY9qKt?= =?us-ascii?Q?p/EPrkFKRB8Qv8GAXONg2kPzYcsDPMH9MAS+KefPPBVSh74uRzD3kRNdtMmX?= =?us-ascii?Q?4e61Ala9xMjAq2S+WPUJw8zgh/woku2pGx0IepFHWJds6AZnAxn0Cemeo3cD?= =?us-ascii?Q?o4WzYMalyG18/TBv2VVvBYoqcmkJDukfrDUtVxO3tdMlRrs/1hVx3/4YNt03?= =?us-ascii?Q?5Z28kbuJBez8kA/LEyfMrWC0B7BI0F4CC8PyAQbM6NNXtqRAxdpOmZ4ZmnRg?= =?us-ascii?Q?VhLxJuxouHkjnUuhww9zRe//04VWQOmXAnls0iriVppcxUApgeq6tQQwwEpx?= =?us-ascii?Q?g2WallUiTN/QMewJvSsi0mN4BF4USoUpgris/iNjQthSRs4Uydjgu/MiySYF?= =?us-ascii?Q?xgKWLhpFGKjnDrxxqqP8Rkl0W7ojkNdQZC62xc5/+lKqWjMVsbaBfgxGmQfr?= =?us-ascii?Q?VUhvJz3HB3phdjZduVHb4PDnJIQP2mqfphCUQjfHBi18/NbFDlLCxXj4OAeA?= =?us-ascii?Q?Psxw8=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB202; 5:WzRAXJd/WVHA2wuKflVVq6wxnnvLxgfELivvzCVOJJvUY6unAWZyd/Ejl5a+rEYwivHy/DMtaAZj2ZfV7Ysr3Wh4zChcxj9FrUYNrFWzesUdOsaeApKNtl4lnj8sB4OVk7/H4pNTBV3dNcWgqdIM4w==; 24:xbgutb7sDKipVSg818VqnMgUW5FyaKdVtd2EwDvGtKDaZ3qAM80rH5O7ybtbnYDDjOiihlglssWqzB2Fwkl6Pe+BYxrgFmA1soIf5d1eY0g=; 7:8EAOwXSZdSIo+qGyN50Xw+pz5IGVncQIit3umYUZNDE7QDfcxCfPXzzplxx3b/W6wfbH+LcM9B70W3nPKmkvw06Fd8PsrWoLXeGJEQ6gwEF/ARNPKhW6VPzvSAZTJnGhMYeR0WxmbdPTa2cdewVMTbAJcJ9rb7mw7KaMmTzdeQVZtYUByp6R2hGEYLmGN9Cz SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 May 2016 15:10:56.2052 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB202 Archived-At: Cc: Susan Hares Subject: [Idr] flowspec tunnel/path/sid drafts next steps [was: Re: WG Adoption call for drafts for Flow Specification option 1 (RFC5575 additions (filters/actions) 3/25 to 4/8/2016 ] X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 15:11:01 -0000 --Apple-Mail=_FBDB0706-3AAE-4342-9210-58AC5917B83C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Dear WG, =20 The WG has demonstrated interest in the subject area addressed by these = drafts: =20 draft-vandevelde-idr-flowspec-path-redirect draft-li-idr-flowspec-redirect-generalized-sid draft-hao-idr-flowspec-redirect-tunnel =20 Furthermore, there's clear consensus that the WG should select only one = approach to proceed forward with.=20 =20 Although during the WG adoption call there was some substantive = discussion of the differences in approach between the three drafts, the = chairs were not convinced that it was sufficient to allow us to = conclude. For this reason, we're asking the respective authors to = prepare short presentations outlining key differences only for = discussion at our upcoming interim on May 16. These will be recorded and = distributed by May 14th, so that the interim time itself can be used for = Q/A/discussion only (and not for presenting slides).=20 =20 Please also use the mailing list for discussion, there is no requirement = to wait until the interim time slot. This will be our only topic for the = May 16 interim. (If we get enough engagement on the mailing list = beforehand, we might even be able to cancel the interim.) We especially encourage review and comment by WG members who haven't = contributed yet. =20 After the interim, the chairs will make a decision about which draft to = move forward with as a good starting point for WG work.=20 =20 Thanks, and thanks in advance for your efforts over the next week or so. =20 Regards, =20 --John and Sue > On Mar 25, 2016, at 10:47 AM, Susan Hares wrote: >=20 > IDR WG:=20 > =20 > This begins a 2 week WG Call (3/25 to 4/8/2016) for the set of drafts = to be considered in RFC5575 additions. These options are filters, = actions or critical security additions. The flow specification work has = been a part of the interims since IETF 94 > = https://www.ietf.org/proceedings/interim/2016/02/08/idr/proceedings.html = = > = https://www.ietf.org/proceedings/interim/2016/03/07/idr/proceedings.html = = > =20 > There will be a brief flow specification presentation at IETF 95, and = the email list has select to start with option 1 =E2=80=93 extending = RFC5575. We also will be gathering details on the SDN/NFV use case for = option 2 (new NLRI and Wide Communities support).=20 > =20 > This is a group call for the drafts to be considered in the flow = specification work. For each of the drafts you wish to be considered = Option 1, please indicate:=20 > =20 > 1) If this option is valuable for the DDoS deployments or another = critical deployments, =20 > 2) Do you feel this draft is useful, but not ready for adoption,=20= > 3) Do you feel this draft is a good start for this work.=20 > =20 > The drafts to consider are:=20 > https://datatracker.ietf.org/doc/draft-eddy-idr-flowspec-packet-rate/ = > https://datatracker.ietf.org/doc/draft-hao-idr-flowspec-nvo3/ = > = https://datatracker.ietf.org/doc/draft-hao-idr-flowspec-redirect-tunnel/ = = > = https://datatracker.ietf.org/doc/draft-li-idr-flowspec-redirect-generalize= d-sid/ = > https://datatracker.ietf.org/doc/draft-liang-idr-bgp-flowspec-label/ = > = https://datatracker.ietf.org/doc/draft-litkowski-idr-flowspec-interfaceset= / = > = https://datatracker.ietf.org/doc/draft-vandevelde-idr-flowspec-pat= h-redirect/ = > https://datatracker.ietf.org/doc/draft-yong-idr-flowspec-mpls-match/ = > =20 > And for the ordering of these filters and actions drafts =E2=80=93 the = Option 1 section out of this=20 > https://datatracker.ietf.org/doc/draft-hares-idr-flowspec-combo/ = > (A revised draft with just Option 1 will be posted)=20 > =20 > Sue Hares and John Scudder=20 --Apple-Mail=_FBDB0706-3AAE-4342-9210-58AC5917B83C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" Dear WG,
 
The WG has = demonstrated interest in the subject area addressed by these drafts:
 
draft-vandevelde-idr-flowspec-path-redirect
draft-li-idr-flowspec-redirect-generalized-sid
draft-hao-idr-flowspec-redirect-tunnel
 
Furthermore, there's clear consensus that the WG should = select only one approach to proceed forward with. 
 
Although during the WG adoption call = there was some substantive discussion of the differences in approach = between the three drafts, the chairs were not convinced that it was = sufficient to allow us to conclude. For this reason, we're asking the = respective authors to prepare short presentations outlining key = differences only for discussion at our upcoming interim on May 16. These = will be recorded and distributed by May 14th, so that the interim = time itself can be used for Q/A/discussion only (and not for presenting = slides). 
 
Please also use the = mailing list for discussion, there is no requirement to wait until the = interim time slot. This will be our only topic for the May 16 = interim. (If we get enough engagement on the mailing list beforehand, we = might even be able to cancel the interim.)

We= especially encourage review and comment by WG members who haven't = contributed yet.
 
After the interim, = the chairs will make a decision about which draft to move forward with = as a good starting point for WG work. 
 
Thanks, and thanks in advance for your efforts over the next = week or so.
 
Regards,
 
--John and Sue

On = Mar 25, 2016, at 10:47 AM, Susan Hares <shares@ndzh.com> = wrote:

IDR WG: 
 
This = begins a 2 week WG Call (3/25 to 4/8/2016) for the set of drafts to be = considered in RFC5575 additions. These options are filters, actions or = critical security additions.  The flow specification work has been = a part of the interims since IETF 94
https://www.ietf.org/proceedings/interim/2016/02/08/idr/proceed= ings.html
 
There will be a brief flow specification presentation at IETF = 95, and the email list has select to start with option 1 =E2=80=93 = extending RFC5575.  We also will be gathering details on the = SDN/NFV use case for option 2 (new NLRI and Wide Communities = support). 
 
This is a = group call for the drafts to be considered in the flow specification = work.  For each of the drafts you wish to be considered Option 1, = please indicate: 
 
1)      If this = option is valuable for the DDoS deployments or another critical = deployments,  
2)      Do you feel = this draft is useful, but not ready for adoption, 
3)      Do you feel = this draft is a good start for this work. 
 
The = drafts to consider are: 
https://datatracker.ietf.org/doc/draft-eddy-idr-flowspec-packet= -rate/
https://datatracker.ietf.org/doc/draft-hao-idr-flowspec-redirec= t-tunnel/
 
And for the ordering of these filters and actions drafts =E2=80= =93 the Option 1 section out of this 
https://datatracker.ietf.org/doc/draft-hares-idr-flowspec-combo= /
(A = revised draft with just Option 1 will be posted) 
 
Sue Hares = and John Scudder 

= --Apple-Mail=_FBDB0706-3AAE-4342-9210-58AC5917B83C-- From nobody Tue May 10 08:30:31 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 57D4812D691; Fri, 6 May 2016 08:43:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Liaison Statement Management Tool To: "Thomas Morin" , "John Scudder" , "Martin Vigoureux" , "Susan Hares" X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160506154352.26329.73696.idtracker@ietfa.amsl.com> Date: Fri, 06 May 2016 08:43:52 -0700 Archived-At: X-Mailman-Approved-At: Tue, 10 May 2016 08:30:22 -0700 Cc: Inter-Domain Routing Discussion List , Kevin Vachon , BGP Enabled ServiceS Discussion List , rraghu@ciena.com, Susan Hares Subject: [Idr] New Liaison Statement, "Liaison from MEF on IP Service Attributes" X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 15:43:52 -0000 Title: Liaison from MEF on IP Service Attributes Submission Date: 2016-05-06 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1473/ From: "MEF Liaison" To: Martin Vigoureux , Thomas Morin ,Susan Hares ,John Scudder Cc: Kevin Vachon ,Lucy Yong ,Alvaro Retana ,Deborah Brungard ,Susan Hares ,BGP Enabled ServiceS Discussion List ,Martin Vigoureux ,Alia Atlas ,Inter-Domain Routing Discussion List ,Thomas Morin ,John Scudder ,Raghu Ranganathan Response Contacts: rraghu@ciena.com Technical Contacts: Purpose: For information Body: Attachments: IP Services Liaison to IETF IDR and BESS WGs https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2016-05-06-mef-idr-bess-liaison-from-mef-on-ip-service-attributes-attachment-1.pdf From nobody Tue May 10 11:06:04 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCA2012D155 for ; Tue, 10 May 2016 11:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2a18OLCtexAi for ; Tue, 10 May 2016 11:06:02 -0700 (PDT) Received: from lxdnp29m.centurylink.com (lxdnp29m.centurylink.com [155.70.32.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06B5612D58D for ; Tue, 10 May 2016 11:05:57 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (emailout.qintra.com [10.1.51.30]) by lxdnp29m.centurylink.com (8.14.8/8.14.8) with ESMTP id u4AI5ujv028788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 May 2016 12:05:56 -0600 Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 7B9B21E0055; Tue, 10 May 2016 12:05:51 -0600 (MDT) Received: from lxdnp32k.corp.intranet (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 62DDC1E0061; Tue, 10 May 2016 12:05:51 -0600 (MDT) Received: from lxdnp32k.corp.intranet (localhost [127.0.0.1]) by lxdnp32k.corp.intranet (8.14.8/8.14.8) with ESMTP id u4AI5pWi060073; Tue, 10 May 2016 12:05:51 -0600 Received: from vddcwhubex502.ctl.intranet (vddcwhubex502.ctl.intranet [151.119.128.29]) by lxdnp32k.corp.intranet (8.14.8/8.14.8) with ESMTP id u4AI5ptN060070 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 May 2016 12:05:51 -0600 Received: from PDDCWMBXEX503.ctl.intranet ([fe80::9033:ef22:df02:32a9]) by vddcwhubex502.ctl.intranet ([151.119.128.29]) with mapi id 14.03.0195.001; Tue, 10 May 2016 12:05:50 -0600 From: "Smith, Donald" To: Rob Shakir , Ajay L Thread-Topic: [Idr] Question about BGP mandatory attribute missing behavior Thread-Index: AQHRokpC9uPp3Fu8kEmS98O4RVWltp+hxcSAgAmoX4CABxlvHA== Date: Tue, 10 May 2016 18:05:50 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D3B51AAC1@PDDCWMBXEX503.ctl.intranet> References: , <9D9C2E06-9D20-4D24-B41E-FE0A0D43B65A@rob.sh> In-Reply-To: <9D9C2E06-9D20-4D24-B41E-FE0A0D43B65A@rob.sh> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] Question about BGP mandatory attribute missing behavior X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 18:06:04 -0000 Where is "well-known" defined? or well-known mandatory attributes? 01100101000010|10011010111101? Hint 7 bit ascii Donald.Smith@centurylink.com From: Idr [idr-bounces@ietf.org] on behalf of Rob Shakir [rjs@rob.sh] Sent: Thursday, May 05, 2016 5:37 PM To: Ajay L Cc: idr@ietf.org Subject: Re: [Idr] Question about BGP mandatory attribute missing behavior Hi Ajay, On 29 Apr, 2016, at 2:08 PM, Ajay L wrote: The section on NOTIFICATION message says that BGP connection is closed imme= diately after sending it. So in my scenario, looks like the expected behavi= or is to send NOTIFICATION message with details of the first detected missi= ng mandatory attribute and close the connection. Please let me know if this= interpretation is not correct An implementation is not expected to send more than one NOTIFICATION messag= e upon encountering an erroneous UPDATE message. Once an error has been enc= ountered, and NOTIFICATION has been transmitted; the sending BGP speaker is= expected to close the connection. It is worth noting that the error handling behaviour of when NOTIFICATION m= essages are transmitted was modified by RFC7606. Section 3 of RFC7606 addre= sses the case of missing well known mandatory fields: d. If any of the well-known mandatory attributes are not present in an UPDATE message, then "treat-as-withdraw" MUST be used. (Note that [RFC4760] reclassifies NEXT_HOP as what is effectively discretionary.) i.e., where a speaker is compliant with RFC7606, then NOTIFICATION should n= ot be sent in this scenario. Kind regards, r. This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly prohibited and may be unlawful. If you have received this communicat= ion in error, please immediately notify the sender by reply e-mail and dest= roy all copies of the communication and any attachments. From nobody Tue May 10 11:11:01 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4161112D57B for ; Tue, 10 May 2016 11:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyjFrKtHb4yL for ; Tue, 10 May 2016 11:10:57 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E63D712D567 for ; Tue, 10 May 2016 11:10:56 -0700 (PDT) Received: from [199.87.120.129] (helo=jivecommunications.com) by cappuccino.rob.sh with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1b0C7A-0003UX-51; Tue, 10 May 2016 19:10:36 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Rob Shakir In-Reply-To: <68EFACB32CF4464298EA2779B058889D3B51AAC1@PDDCWMBXEX503.ctl.intranet> Date: Tue, 10 May 2016 12:10:51 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9D9C2E06-9D20-4D24-B41E-FE0A0D43B65A@rob.sh> <68EFACB32CF4464298EA2779B058889D3B51AAC1@PDDCWMBXEX503.ctl.intranet> To: "Smith, Donald" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] Question about BGP mandatory attribute missing behavior X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 18:11:00 -0000 > On 10 May, 2016, at 12:05 PM, Smith, Donald = wrote: >=20 > Where is "well-known" defined? > or well-known mandatory attributes? I=E2=80=99n not sure whether this is a serious question: =E2=80=9Cwell-kno= wn" is defined based bit 0 of the Attribute Flags field. As per RFC4271. Mandatory is defined in the same document Section 5. Kind regards, r. From nobody Tue May 10 13:54:29 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6866012D5FF for ; Tue, 10 May 2016 13:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGS35CXbclE7 for ; Tue, 10 May 2016 13:54:26 -0700 (PDT) Received: from lxdnp29m.centurylink.com (lxdnp29m.centurylink.com [155.70.32.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBB8612D0B4 for ; Tue, 10 May 2016 13:54:26 -0700 (PDT) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by lxdnp29m.centurylink.com (8.14.8/8.14.8) with ESMTP id u4AKsPA7024488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 May 2016 14:54:25 -0600 Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id CFE991E0204; Tue, 10 May 2016 15:54:19 -0500 (CDT) Received: from lxdnp31k.corp.intranet (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 978E51E00EA; Tue, 10 May 2016 15:54:19 -0500 (CDT) Received: from lxdnp31k.corp.intranet (localhost [127.0.0.1]) by lxdnp31k.corp.intranet (8.14.8/8.14.8) with ESMTP id u4AKsJP6044513; Tue, 10 May 2016 14:54:19 -0600 Received: from vddcwhubex501.ctl.intranet (vddcwhubex501.ctl.intranet [151.119.128.28]) by lxdnp31k.corp.intranet (8.14.8/8.14.8) with ESMTP id u4AKsJXm044510 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 May 2016 14:54:19 -0600 Received: from PDDCWMBXEX503.ctl.intranet ([fe80::9033:ef22:df02:32a9]) by vddcwhubex501.ctl.intranet ([151.119.128.28]) with mapi id 14.03.0195.001; Tue, 10 May 2016 14:54:19 -0600 From: "Smith, Donald" To: Rob Shakir Thread-Topic: [Idr] Question about BGP mandatory attribute missing behavior Thread-Index: AQHRokpC9uPp3Fu8kEmS98O4RVWltp+hxcSAgAmoX4CABxlvHIAAZwCA///IIMA= Date: Tue, 10 May 2016 20:54:18 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D3B51AD4F@PDDCWMBXEX503.ctl.intranet> References: <9D9C2E06-9D20-4D24-B41E-FE0A0D43B65A@rob.sh> <68EFACB32CF4464298EA2779B058889D3B51AAC1@PDDCWMBXEX503.ctl.intranet>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.70.40.131] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] Question about BGP mandatory attribute missing behavior X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 20:54:28 -0000 It was serious. Sorry I googled for it and IETF and couldn't find it. Thank you for the explanation. I don't know BGP bits by heart I usually hav= e to look them up. 01100101000010|10011010111101? Hint 7 bit ascii Donald.Smith@centurylink.com ________________________________________ From: Rob Shakir [rjs@rob.sh] Sent: Tuesday, May 10, 2016 12:10 PM To: Smith, Donald Cc: Ajay L; idr@ietf.org Subject: Re: [Idr] Question about BGP mandatory attribute missing behavior > On 10 May, 2016, at 12:05 PM, Smith, Donald wrote: > > Where is "well-known" defined? > or well-known mandatory attributes? I=92n not sure whether this is a serious question: =93well-known" is define= d based bit 0 of the Attribute Flags field. As per RFC4271. Mandatory is defined in the same document Section 5. Kind regards, r. This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly prohibited and may be unlawful. If you have received this communicat= ion in error, please immediately notify the sender by reply e-mail and dest= roy all copies of the communication and any attachments. From nobody Wed May 11 07:27:17 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C471E12D6C9; Wed, 11 May 2016 07:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LihKVLIgM66u; Wed, 11 May 2016 07:27:09 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBCD12DAF2; Wed, 11 May 2016 07:27:09 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 1B9C91E336; Wed, 11 May 2016 10:32:10 -0400 (EDT) Date: Wed, 11 May 2016 10:32:10 -0400 From: Jeffrey Haas To: Kathleen Moriarty Message-ID: <20160511143210.GC7636@pfrc.org> References: <20160502175801.15655.80242.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160502175801.15655.80242.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: draft-ietf-idr-add-paths@ietf.org, russ@riw.us, The IESG , idr-chairs@ietf.org, idr@ietf.org Subject: Re: [Idr] Kathleen Moriarty's No Objection on draft-ietf-idr-add-paths-14: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 14:27:11 -0000 Kathleen, On Mon, May 02, 2016 at 10:58:01AM -0700, Kathleen Moriarty wrote: > 1. I'd like to see the security considerations explicitly state that this > could result in a denial of service attack. The resource consumption is > stated nicely, but it would be good (following RFC3552) to state the type > of attack. > > "This document defines a BGP extension that allows the advertisement > of multiple paths for the same address prefix without the new paths > implicitly replacing any previous ones. As a result, multiple paths > for a large number of prefixes may be received by a BGP speaker > potentially depleting memory resources or even causing network-wide > instability." > > Adding something like: "This could result in a denial of service > attack." The considerations of a BGP peer's normal protocol interactions with a BGP speaker - with or without add-paths - being considered a Denial of Service seems to be unnecessary scare words. While the add-paths case does permit a much larger number of paths to be propagated, the same issue may apply to simply sending along a much larger amount of some routing table than expected. This could include sending a full Internet routing table to a router scaled for a few thousands of routes. I recommend against this change. > 2. Change the last sentence of the security considerations section in > light of the first paragraph to something like: > > From: > This document introduces no new security concerns in the base > operation of BGP [RFC4271]. > > To: > Security concerns in the base operation of BGP [RFC4271] also apply. I think this covers it nicely. -- jeff From nobody Wed May 11 07:29:27 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 469F612DB12; Wed, 11 May 2016 07:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLnQ8I19Eq7V; Wed, 11 May 2016 07:29:22 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F64C12DAAC; Wed, 11 May 2016 07:29:21 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id o133so59141554vka.0; Wed, 11 May 2016 07:29:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=ROudKI1VUbYbNSHojHAmP+Ip4f0Flk0kyUFBmxagaSI=; b=G+Ayg3LdR6FVVF1DwcPYaIwaDLCM5IjOyjgvkaNIRQW2lI6KBxeWCO/Lhf0zXIMTaq R5VyeSwAt1qSZrgznHC6N1KrIRYsOyoiC9W+O3Dh+5ICsvQoST/Jkhs3xGkZe5aaZ6X3 dNpyuFEc832ABOM94gz76Ti8c4yFTVVgl5fB71NaID28qYNJY5amyX0AxyuwaMhvXPdT vkpm4ApS4TmEvbvnQ0iC9GsYp6KL9V5cWAwytbzgDX0PThXh4UGtf985Igr8CFSmYYGf pXdtQiB3gKPJYx7e9brg+Edd8Wr3utUq6rjIPaS1lwFj1G6dlnTXIUsutOspVbDkPB0m aEtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=ROudKI1VUbYbNSHojHAmP+Ip4f0Flk0kyUFBmxagaSI=; b=XvCg5ZgxnQ2ySJNBzw6QPf4VBbkKsBorznVzE8cf5C904YmRW7UiqkAeLbgsIABciu zZZSUKaSkH/dCSKofRL0ov9MjzkpALj5yKQGa9pP628W5CB250UcNkzWx0+K4tc4KB4j duDZApn6q32Ey+UG5i4BbRi/XWAbbAVq62VC9GZ+Y62RlK3V0UFRqOZG15PlLOJP4kFt +ZSxzLeuuJKgBBYshMxwC/NCyMXRZpxzkkYhxBoEWpekUcPb+ui5rgHsnORyOkuZUK6x 8HjKnwO7RF7XWafkRzgK6HE3Fg7USyFC84ruzcSZsYRuzWy7qKzOu9PVN5V1TtplslzT 9s6g== X-Gm-Message-State: AOPr4FXgMoO6HQ01cuWC7GADcNboJgLOgiAfoz6/6kt/4tvQtGSXEgB9AHMXIMa0dppEHxvjWlnceoKT+nFjuQ== MIME-Version: 1.0 X-Received: by 10.159.35.15 with SMTP id 15mr1842358uae.109.1462976960351; Wed, 11 May 2016 07:29:20 -0700 (PDT) Received: by 10.159.54.231 with HTTP; Wed, 11 May 2016 07:29:20 -0700 (PDT) In-Reply-To: <20160511143210.GC7636@pfrc.org> References: <20160502175801.15655.80242.idtracker@ietfa.amsl.com> <20160511143210.GC7636@pfrc.org> Date: Wed, 11 May 2016 10:29:20 -0400 Message-ID: From: Kathleen Moriarty To: Jeffrey Haas Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-idr-add-paths@ietf.org, russ@riw.us, The IESG , idr-chairs@ietf.org, idr@ietf.org Subject: Re: [Idr] Kathleen Moriarty's No Objection on draft-ietf-idr-add-paths-14: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 14:29:25 -0000 Hi Jeff, Thanks for your response. Inline. On Wed, May 11, 2016 at 10:32 AM, Jeffrey Haas wrote: > Kathleen, > > On Mon, May 02, 2016 at 10:58:01AM -0700, Kathleen Moriarty wrote: >> 1. I'd like to see the security considerations explicitly state that this >> could result in a denial of service attack. The resource consumption is >> stated nicely, but it would be good (following RFC3552) to state the type >> of attack. >> >> "This document defines a BGP extension that allows the advertisement >> of multiple paths for the same address prefix without the new paths >> implicitly replacing any previous ones. As a result, multiple paths >> for a large number of prefixes may be received by a BGP speaker >> potentially depleting memory resources or even causing network-wide >> instability." >> >> Adding something like: "This could result in a denial of service >> attack." > > The considerations of a BGP peer's normal protocol interactions with a BGP > speaker - with or without add-paths - being considered a Denial of Service > seems to be unnecessary scare words. > > While the add-paths case does permit a much larger number of paths to be > propagated, the same issue may apply to simply sending along a much larger > amount of some routing table than expected. This could include sending a > full Internet routing table to a router scaled for a few thousands of > routes. > > I recommend against this change. This is just a comment, so it's up to the shepherd and AD, but adding this would be in line with the guidance from RFC3552. https://tools.ietf.org/html/rfc3552 Thanks, Kathleen > >> 2. Change the last sentence of the security considerations section in >> light of the first paragraph to something like: >> >> From: >> This document introduces no new security concerns in the base >> operation of BGP [RFC4271]. >> >> To: >> Security concerns in the base operation of BGP [RFC4271] also apply. > > I think this covers it nicely. > > -- jeff -- Best regards, Kathleen From nobody Wed May 11 07:33:16 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F06B12DB13 for ; Wed, 11 May 2016 07:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hb-Bgt3AJbCz for ; Wed, 11 May 2016 07:33:12 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id D37D512DB1A for ; Wed, 11 May 2016 07:33:12 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 179291E336; Wed, 11 May 2016 10:38:15 -0400 (EDT) Date: Wed, 11 May 2016 10:38:15 -0400 From: Jeffrey Haas To: "John G. Scudder" Message-ID: <20160511143814.GD7636@pfrc.org> References: <1BE5582B-90D5-4C99-8807-EC6202523E4B@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1BE5582B-90D5-4C99-8807-EC6202523E4B@juniper.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] BGP persistence X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 14:33:14 -0000 On Fri, Apr 29, 2016 at 10:38:21AM -0400, John G. Scudder wrote: > With WG chair hat firmly off my head and contributor-to-the-document hat prominently displayed, let me suggest (or rather, second Jakob's indirect suggestion) that we adopt and progress the document. I'll respond in the appropriate thread when the adoption call comes up, but I clearly support adoption. I'd also like to encourage the authors to refresh the draft meanwhile. In particular, please update your IANA considerations with the assigned values. (And thanks for doing your homework in making sure they got reserved.) -- Jeff From nobody Wed May 11 12:43:51 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EA5C312D7EC; Wed, 11 May 2016 12:43:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160511194350.15300.5726.idtracker@ietfa.amsl.com> Date: Wed, 11 May 2016 12:43:50 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-te-pm-bgp-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 19:43:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : BGP-LS Advertisement of IGP Traffic Engineering Performance Metric Extensions Authors : Stefano Previdi Qin Wu Hannes Gredler Saikat Ray Jeff Tantsura Clarence Filsfils Les Ginsberg Filename : draft-ietf-idr-te-pm-bgp-03.txt Pages : 9 Date : 2016-05-11 Abstract: This document defines new BGP-LS TLVs in order to carry the IGP Traffic Engineering Extensions defined in IS-IS and OSPF protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-te-pm-bgp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-te-pm-bgp-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-te-pm-bgp-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 11 12:47:04 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC5AC12D804 for ; Wed, 11 May 2016 12:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g_GXerIWaY_5 for ; Wed, 11 May 2016 12:47:02 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDD4012D7F6 for ; Wed, 11 May 2016 12:47:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1933; q=dns/txt; s=iport; t=1462996020; x=1464205620; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=2kGfYRIGEMGS+zdhnyjikAU8iT8jwGaxayKP8+j+788=; b=YrZjMNGpawYXZHPriM/jiIfJOxgXptUNlAmHFymqJ86JgJDkxsQwLKSD GFG3aRNEa5FqXyUpJqTAg5mpHr1UB8ezDjV7PTNw6KIs0KG97b6g+KUjV 2wYG5z33jbfH1bZqkVDtQoY9KbM3yNOZTJch0nREd5RL6Wd8Erjok86ZX 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAgCTizNX/5NdJa1egzhVfQa5MgENg?= =?us-ascii?q?XYXC4VyAoE+OBQBAQEBAQEBZSeEQgEBAQMBAQEBNzQQCwIBCBgeECcLJQIEE4g?= =?us-ascii?q?nCA66XwEBAQEBAQEBAQEBAQEBAQEBAQEBARWGIIF2glaEP4Mrgi4FmCcBhX2Ce?= =?us-ascii?q?IUogWlOhAGIYY9AAR4BAUKDa26IC38BAQE?= X-IronPort-AV: E=Sophos;i="5.24,609,1454976000"; d="scan'208";a="272348897" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 May 2016 19:47:00 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u4BJkxMa004840 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 11 May 2016 19:47:00 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 11 May 2016 15:46:58 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1104.009; Wed, 11 May 2016 15:46:58 -0400 From: "Stefano Previdi (sprevidi)" To: idr wg Thread-Topic: [Idr] I-D Action: draft-ietf-idr-te-pm-bgp-03.txt Thread-Index: AQHRq73h0ryTvRCMEUi2WU9lKpPoDw== Date: Wed, 11 May 2016 19:46:58 +0000 Message-ID: References: <20160511194350.15300.5726.idtracker@ietfa.amsl.com> In-Reply-To: <20160511194350.15300.5726.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.161.123] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-te-pm-bgp-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 19:47:04 -0000 Hi, this draft is a merge of: draft-previdi-idr-bgpls-te-metric-extensions-00 draft-ietf-idr-te-pm-bgp-02.txt and consists of advertising the IGP TE metric extensions TLVs (RFC7471 and = RFC7810) into BGP-LS. Thanks. s. > On May 11, 2016, at 9:43 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Inter-Domain Routing of the IETF. >=20 > Title : BGP-LS Advertisement of IGP Traffic Engineering = Performance Metric Extensions > Authors : Stefano Previdi > Qin Wu > Hannes Gredler > Saikat Ray > Jeff Tantsura > Clarence Filsfils > Les Ginsberg > Filename : draft-ietf-idr-te-pm-bgp-03.txt > Pages : 9 > Date : 2016-05-11 >=20 > Abstract: > This document defines new BGP-LS TLVs in order to carry the IGP > Traffic Engineering Extensions defined in IS-IS and OSPF protocols. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-te-pm-bgp/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-idr-te-pm-bgp-03 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-te-pm-bgp-03 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Thu May 12 01:54:33 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 45DAA12B063; Thu, 12 May 2016 01:54:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160512085430.14196.77550.idtracker@ietfa.amsl.com> Date: Thu, 12 May 2016 01:54:30 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgpls-segment-routing-epe-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 08:54:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : Segment Routing BGP Egress Peer Engineering BGP-LS Extensions Authors : Stefano Previdi Clarence Filsfils Saikat Ray Keyur Patel Jie Dong Mach (Guoyi) Chen Filename : draft-ietf-idr-bgpls-segment-routing-epe-04.txt Pages : 19 Date : 2016-05-12 Abstract: Segment Routing (SR) leverages source routing. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service-based. SR allows to enforce a flow through any topological path and service chain while maintaining per-flow state only at the ingress node of the SR domain. The Segment Routing architecture can be directly applied to the MPLS dataplane with no change on the forwarding plane. It requires minor extension to the existing link-state routing protocols. This document outline a BGP-LS extension for exporting BGP peering node topology information (including its peers, interfaces and peering ASs) in a way that is exploitable in order to compute efficient BGP Peering Engineering policies and strategies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgpls-segment-routing-epe-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 12 02:05:46 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2337112D145; Thu, 12 May 2016 02:05:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160512090542.14194.35537.idtracker@ietfa.amsl.com> Date: Thu, 12 May 2016 02:05:42 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgpls-segment-routing-epe-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 09:05:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : Segment Routing BGP Egress Peer Engineering BGP-LS Extensions Authors : Stefano Previdi Clarence Filsfils Saikat Ray Keyur Patel Jie Dong Mach (Guoyi) Chen Filename : draft-ietf-idr-bgpls-segment-routing-epe-05.txt Pages : 19 Date : 2016-05-12 Abstract: Segment Routing (SR) leverages source routing. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service-based. SR allows to enforce a flow through any topological path and service chain while maintaining per-flow state only at the ingress node of the SR domain. The Segment Routing architecture can be directly applied to the MPLS dataplane with no change on the forwarding plane. It requires minor extension to the existing link-state routing protocols. This document outline a BGP-LS extension for exporting BGP peering node topology information (including its peers, interfaces and peering ASs) in a way that is exploitable in order to compute efficient BGP Peering Engineering policies and strategies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgpls-segment-routing-epe-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 12 02:06:50 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82F9F12D139 for ; Thu, 12 May 2016 02:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRnkCbVyMcLP for ; Thu, 12 May 2016 02:06:47 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87C7812D096 for ; Thu, 12 May 2016 02:06:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3992; q=dns/txt; s=iport; t=1463044007; x=1464253607; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=srOzRXFVhK8bn8TOzNDFZtzva+nSto3kNJrRWf+bOjw=; b=AxBLERIWmQXu6BWRIh8uzxQgDCoiMfTwuEzAmpGOGaWhcnYDU2EcjR3A lQ+wFlfbAkDXZbuCch91ZkFEcqDxqhcE60Lk7ta1Yk+oOAVw2GZpQAIrg s/bHmhoCfYifVxWUyA+PRwcmS6DiSqDwyHe/O2Tcw6uyJN+weO2WiTt5/ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D+AQC3RjRX/5BdJa1egzhVfQa5VAENg?= =?us-ascii?q?XYXDYVwAhyBGDgUAQEBAQEBAWUnhEIBAQEDAQEBASAROhALAgEIEgYCAiYCAgI?= =?us-ascii?q?lCxUCDgIEEwmIHggOqkqRBgEBAQEBAQEBAQEBAQEBAQEBAQEBARV8hSSBdoJWh?= =?us-ascii?q?z8rgi4FkzCEdwGFfYJ4hSiBaU6EAYhhhi2BQ4dQAR4BAUKDa24BhzF/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,609,1454976000"; d="scan'208";a="103499229" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 May 2016 09:06:46 +0000 Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u4C96k6w014943 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 12 May 2016 09:06:46 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 12 May 2016 05:06:45 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1104.009; Thu, 12 May 2016 05:06:45 -0400 From: "Stefano Previdi (sprevidi)" To: idr wg Thread-Topic: I-D Action: draft-ietf-idr-bgpls-segment-routing-epe-05.txt Thread-Index: AQHRrC2bMO+F/4EN8kqWhWMRpQjvcA== Date: Thu, 12 May 2016 09:06:45 +0000 Message-ID: References: <20160512090542.14194.35537.idtracker@ietfa.amsl.com> In-Reply-To: <20160512090542.14194.35537.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.198.108] Content-Type: text/plain; charset="utf-8" Content-ID: <5014CCCA53EEC6439A13C23BD7D48FB5@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgpls-segment-routing-epe-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 09:06:49 -0000 SGksDQoNCnRoZSBvbmx5IHVwZGF0ZSBpbiB0aGUgLTA1IHZlcnNpb24gaXMgdGhlIHJldmVydCBi YWNrIHRvIOKAnEVncmVzcyBQZWVyIFRlcm1pbm9sb2d5IChFUEUpIiB0ZXJtaW5vbG9neS4NCg0K VGhlIHByZXZpb3VzIHZlcnNpb24gaGFkIHRoZSDigJxQZWVyIEVuZ2luZWVyaW5nIChQRSnigJ0g dGVybSB3aGljaCBhcHBhcmVudGx5IGNyZWF0ZWQgY29uZnVzaW9uLg0KDQpPYnZpb3VzbHkgdGhl IEVQRSBtZWNoYW5pc21zIGFyZSBzdGlsbCBhcHBsaWNhYmxlIHRvIGJvdGggaUJHUCBhbmQgZUJH UC4NCg0KVGhhbmtzIGFuZCBzb3JyeSBmb3IgdGhlIGNodXJuLg0KDQpzLg0KDQoNCj4gT24gTWF5 IDEyLCAyMDE2LCBhdCAxMTowNSBBTSwgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIHdyb3RlOg0K PiANCj4gDQo+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1s aW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsg aXRlbSBvZiB0aGUgSW50ZXItRG9tYWluIFJvdXRpbmcgb2YgdGhlIElFVEYuDQo+IA0KPiAgICAg ICAgVGl0bGUgICAgICAgICAgIDogU2VnbWVudCBSb3V0aW5nIEJHUCBFZ3Jlc3MgUGVlciBFbmdp bmVlcmluZyBCR1AtTFMgRXh0ZW5zaW9ucw0KPiAgICAgICAgQXV0aG9ycyAgICAgICAgIDogU3Rl ZmFubyBQcmV2aWRpDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICBDbGFyZW5jZSBGaWxzZmls cw0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgU2Fpa2F0IFJheQ0KPiAgICAgICAgICAgICAg ICAgICAgICAgICAgS2V5dXIgUGF0ZWwNCj4gICAgICAgICAgICAgICAgICAgICAgICAgIEppZSBE b25nDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICBNYWNoIChHdW95aSkgQ2hlbg0KPiAJRmls ZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1pZHItYmdwbHMtc2VnbWVudC1yb3V0aW5nLWVwZS0w NS50eHQNCj4gCVBhZ2VzICAgICAgICAgICA6IDE5DQo+IAlEYXRlICAgICAgICAgICAgOiAyMDE2 LTA1LTEyDQo+IA0KPiBBYnN0cmFjdDoNCj4gICBTZWdtZW50IFJvdXRpbmcgKFNSKSBsZXZlcmFn ZXMgc291cmNlIHJvdXRpbmcuICBBIG5vZGUgc3RlZXJzIGENCj4gICBwYWNrZXQgdGhyb3VnaCBh IGNvbnRyb2xsZWQgc2V0IG9mIGluc3RydWN0aW9ucywgY2FsbGVkIHNlZ21lbnRzLCBieQ0KPiAg IHByZXBlbmRpbmcgdGhlIHBhY2tldCB3aXRoIGFuIFNSIGhlYWRlci4gIEEgc2VnbWVudCBjYW4g cmVwcmVzZW50IGFueQ0KPiAgIGluc3RydWN0aW9uLCB0b3BvbG9naWNhbCBvciBzZXJ2aWNlLWJh c2VkLiAgU1IgYWxsb3dzIHRvIGVuZm9yY2UgYQ0KPiAgIGZsb3cgdGhyb3VnaCBhbnkgdG9wb2xv Z2ljYWwgcGF0aCBhbmQgc2VydmljZSBjaGFpbiB3aGlsZSBtYWludGFpbmluZw0KPiAgIHBlci1m bG93IHN0YXRlIG9ubHkgYXQgdGhlIGluZ3Jlc3Mgbm9kZSBvZiB0aGUgU1IgZG9tYWluLg0KPiAN Cj4gICBUaGUgU2VnbWVudCBSb3V0aW5nIGFyY2hpdGVjdHVyZSBjYW4gYmUgZGlyZWN0bHkgYXBw bGllZCB0byB0aGUgTVBMUw0KPiAgIGRhdGFwbGFuZSB3aXRoIG5vIGNoYW5nZSBvbiB0aGUgZm9y d2FyZGluZyBwbGFuZS4gIEl0IHJlcXVpcmVzIG1pbm9yDQo+ICAgZXh0ZW5zaW9uIHRvIHRoZSBl eGlzdGluZyBsaW5rLXN0YXRlIHJvdXRpbmcgcHJvdG9jb2xzLg0KPiANCj4gICBUaGlzIGRvY3Vt ZW50IG91dGxpbmUgYSBCR1AtTFMgZXh0ZW5zaW9uIGZvciBleHBvcnRpbmcgQkdQIHBlZXJpbmcN Cj4gICBub2RlIHRvcG9sb2d5IGluZm9ybWF0aW9uIChpbmNsdWRpbmcgaXRzIHBlZXJzLCBpbnRl cmZhY2VzIGFuZA0KPiAgIHBlZXJpbmcgQVNzKSBpbiBhIHdheSB0aGF0IGlzIGV4cGxvaXRhYmxl IGluIG9yZGVyIHRvIGNvbXB1dGUNCj4gICBlZmZpY2llbnQgQkdQIFBlZXJpbmcgRW5naW5lZXJp bmcgcG9saWNpZXMgYW5kIHN0cmF0ZWdpZXMuDQo+IA0KPiANCj4gDQo+IFRoZSBJRVRGIGRhdGF0 cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPiBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWlkci1iZ3Bscy1zZWdtZW50LXJvdXRpbmctZXBl Lw0KPiANCj4gVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+ IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlkci1iZ3Bscy1zZWdtZW50 LXJvdXRpbmctZXBlLTA1DQo+IA0KPiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBp cyBhdmFpbGFibGUgYXQ6DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm dC1pZXRmLWlkci1iZ3Bscy1zZWdtZW50LXJvdXRpbmctZXBlLTA1DQo+IA0KPiANCj4gUGxlYXNl IG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUg b2Ygc3VibWlzc2lvbg0KPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUg YXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiANCj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBh bHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPiBmdHA6Ly9mdHAuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzLw0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gSS1ELUFubm91bmNlIG1haWxpbmcgbGlzdA0KPiBJLUQtQW5ub3Vu Y2VAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQt YW5ub3VuY2UNCj4gSW50ZXJuZXQtRHJhZnQgZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0Zi5v cmcvc2hhZG93Lmh0bWwNCj4gb3IgZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRl cy50eHQNCg0K From nobody Thu May 12 08:51:11 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7797212D6CC for ; Thu, 12 May 2016 08:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZKSGNdWn0GG for ; Thu, 12 May 2016 08:51:07 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0755.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:755]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD48712D6B2 for ; Thu, 12 May 2016 08:51:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JdPLy5ALlilO1O1cG4Zd+hgtZ7EC8BK2BmuZklkpKx0=; b=MDP2qbiGaKYoFFHVbu/UzmsVE/71/rmC6BVgyo8NSRe2IYSUfddxiEygoXr8/gvIrUUyyrhY8leZqVRxzDHtjSyfv0hknoaBdzbeLAqiQqy1ZLR02vgpae+Ri7R48Mw6B18DWRVN/a6WDjLAZHdaFKX3eImwrhRRYS96RVPprzo= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; Received: from [172.29.39.101] (66.129.241.11) by BY2PR05MB205.namprd05.prod.outlook.com (10.242.41.148) with Microsoft SMTP Server (TLS) id 15.1.477.8; Thu, 12 May 2016 15:50:43 +0000 From: "John G. Scudder" Content-Type: multipart/alternative; boundary="Apple-Mail=_2F47A287-D6DB-4E14-9A17-372E229E287C" Date: Thu, 12 May 2016 11:50:36 -0400 References: <1135213839.1375091463067745545.JavaMail.nobody@rva2rmd002.webex.com> To: Message-ID: <41E94382-3E38-4599-B8AB-86A57E75AE38@juniper.net> MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: BLUPR17CA0062.namprd17.prod.outlook.com (10.162.85.158) To BY2PR05MB205.namprd05.prod.outlook.com (10.242.41.148) X-MS-Office365-Filtering-Correlation-Id: b294227f-d059-4d64-f7a2-08d37a7d2d4c X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB205; 2:UwZYYiyVP+fVWxhpEt7BIRsfkhQcmcfsh9XJBKBRWosvn6cObd598rPSTeCUnEA0HVq//dTofTG3Arntomjxq6IpvBfL9KJZ8exHPjP6JY5gMBPkpwe57w/0i26nzdm3XJjHaq9ElQH0LihTF5jnMSF3zSS5YtjwGTYc+Pl2AConP7Evmk+H0Zo8aUFjy5vx; 3:Jyn86kj1cvEQgTMeSk1iLuGJ3DEZTH8lh3EOiAOq9UvU9nhWGplKnx4DvD8yK4ZqAgSl1h++at3PkHxFjtSvHUdLI8OPL+dti+8vARsZEzeEgHohn9ViNNHAxthTZMwT X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB205; X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB205; 25:0zHYKBI2DKq67ooAVsxJP1UM8bZ1gVvo77tHkXhuwFZ3tARaIxt6lxuJUx7XSCV/jFGozBHAer/pM4xoUlWo6+9+CjLqhQbm9wvYIa1RBoIOXLnUwbe/a/5EoF2wsNqzeTjdy33ni0RtFgnfsb9WJC1jpJHsabvVaVx5eo7YuWlVmg3HAWbObraSxxxgLH4WajtIVKirA2XML50dx+IxP2EOO+f8isszo1+Zg3wzB++QPIrrxyR3kW4bMI3+aoI7n9zcY0uBPNJgepaUjQQPtF7Wp4/C0pJlkwH8izCOSgenvUMQqgEWE6lyPnvA9gA1oN85/OTUsUflZ3DLCxYJOTzNzlhgeyAF+lur5sVJ/uctFzbvW4zv4h0jtmtDp92YWz8TL3czKHJ7ScXGSg3KU94GHX6+Xh6FtNfx1pHsreNoA809zgWEdc6UlEDGi8LWgI/ix5C+97y15305H/3IlpqgY6muLS50SKmqNagE/aLgyOzUMFOGv/P4baW6v6WAvSUBKThP9JMaSp3Fa1NaWmxioS981RmaoFgxxSD0L4z+UJnv19bnAuJ8BIy81zXRBp6DV80KAKsNvqnVHZA9FM0Qr+h5L02+VHmU6QGqBeH0/63iKu/71uTS/yclMnFtwB02/payxTp7jqEwZSECz/cFbg7mLa+kYeR2IiOZiiYsv3gVwS6oNafwTppd5fbYUleu8lDFJ5FAg0mnWd7aPA/ZEu+bYnhE8GgJ+N4xzLxra94iSTJj5Xb3y/uWBntGod5IA2vNErbqWETuBzoggd9QIpgRayQW0AJu66yF3NRTye+iqGNfuCBpZ9X4ZLZlzKn0VcO4kf9jjyjjZSQocNca2LMes5Uyps6SNXztS01+POB1OmoQRSUzzvcP6sxfa73MWrCwvMyd/p+0MWRSyw== X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB205; 20:IMjP8ooksBmj2xFePUxnlPKYjrJTifuxVkk2xRoe+mXSR1P0pd6KEnRDJgcM+lKKQokCaYlByIuuv9Bu3xyzOQxaSX3JM6YHQx2iSptxrPpDBt2U8vMuXM4V4Xbgw8f1jxlRhW90mhXCGCXP0Gfwa3b4Hrd7gvp+EZosrnkj4tDvmDZBCURRSnOchlI48wEUByo48ul+C68PiobofTSrTGA9iFM4ax6d+yZYI4G0HErkzd02F8MyBM/Pln09aRRJDmyvrbJoc5X+BYglG5NJ3sVbH501WsgqwCiJuN+gIayPtTKVhaDvw4v1ajdkDWkfvOeMhq/94IA7161kvaAPp1Cc774tECivEfS92ah5jrkEYXtdsvAPcRdinLpmVpgs9Y+UfMvUKzLx9K2SAx80LNA4Kf1NyGSI86h293BvQEHu+NDy+rsr3ZWe1q04Lkosoi8WYN2kBEtRb0oDY+teiW2XrPld4xEGyEjMuBzXsk401WR0hfY2SNPTiJOv7W75; 4:eODLXzcCaMYuAyymB0I/W2LYkRkryy2EizfLqDpmcGvFegEge5XH90jokky1FkhxbWjToQYAe36IN89s2I+Yf6i/a2ptmj1DUp5HYUiZYz2ZUK9+u7BDI0O6mHiZxPwKLZ6aPEoX8Gno6pq1rAz3e1OrKrl5RAtZgG0ejpQJbnlBiPKyLE1wSbbi5Yr6kYLgz7c0aLEM4iioVF8+ypdzM2NHuC/CUOtbvTUHuLAbiyFDtw+RGJwwX6/lq19s0/NT1HP+qkeLSAwq4ZZ/AWMZ41pDo4DfY+ICo1Kv6yK3KMwpqvsmsQYhHKikToX/im9ebUlehzLWg/kE2wN6idRx11kSF8jvn0nznQBczL4ViycwMGxFniGVRbSPqXkcjJa0UgJdpMlPBAqbtaAC0nkw861h1uS5NX7YCRwNtZ9RHlDru6YefjrxtKJ5HrjWO1CA X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:BY2PR05MB205; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB205; X-Forefront-PRVS: 0940A19703 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(53754006)(17703002)(25584004)(377454003)(82746002)(19580395003)(36756003)(2906002)(76176999)(86362001)(5008740100001)(50226002)(42186005)(450100001)(110136002)(107886002)(83716003)(19580405001)(5004730100002)(50986999)(16799955002)(189998001)(3846002)(586003)(512954002)(84326002)(92566002)(15975445007)(6116002)(33656002)(69556001)(2351001)(230783001)(260700001)(81166006)(19617315012)(66066001)(229853001)(57306001)(77096005)(551544002)(24704002)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB205; H:[172.29.39.101]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2PR05MB205; 23:FB7OzdfiWhxZzobEAfup/zf4Y0VdyXVf6Hwkf0lnDP?= =?us-ascii?Q?B4EXg+5R6lIfnu4IKuifLdZwyTPBZnEmDrjEG+BZkaHyGs5O0PsMVdFXy1LC?= =?us-ascii?Q?CYKwNHhT3wowIUnvPMsB8BqexgmlXnQ1uh15XMM/I5YEipo/dszM0kCmQ5Sw?= =?us-ascii?Q?17hTISji2MnnCNAJ/PppM2moMYQsVQynt4/6MJFKhk8oKwQF+qepgSIt5SoW?= =?us-ascii?Q?xUOMrwzL1wP0cJ6fioHbfHr2iNb4lciutIw44ndqAjv3KTzOIdF0X1sg0u36?= =?us-ascii?Q?HmQxJr96ygqzLuOLwMvC1AENIu/Z+G6EiW50C0/HZhZvYHw0LC11C/6X9o2u?= =?us-ascii?Q?3DwGgPXf8/QgWBHqKGdPSaG57P0zl4VVHyyW5E5mYZ7sfOr5qU5n9fbbq9bk?= =?us-ascii?Q?sV+ONhkQNKC4HbeI3/X8D0weGy4HjhMq6/j/kdLDboAwX03dOsNR65dTII6H?= =?us-ascii?Q?t/GaAkJIwKo9ay1y6X1763MZ2uCgLoPFBfA4gB0Nc+Vsrl1WmAz91lktKv+6?= =?us-ascii?Q?WdvKQAPE2hI2v3e9DL+ndFXr/aVCwCeoXZ9BBXCZ9qbtp/mssogaimdsePke?= =?us-ascii?Q?eAwo7U53PlFlTAttHjvy7djfbl6aSB1p0b2XUIu7ACekobaaTPcZqwRBMEes?= =?us-ascii?Q?g6WYt4yqOvMI0zgq6vCnLXLrn3l8GyXDusrSenjBlSbTb5EH8aA0j88v+0n0?= =?us-ascii?Q?lo1j0jmMF+K5QPml6ao/maqLiZL751taIXBU2DMqS61OvfJFtZV6h1ZYQ+Du?= =?us-ascii?Q?9Y0djFUEKlaU5CsWov8i/NLjSfv4swoQ1vEi2x7ZAE7xDCmGHT/Kar+KGpum?= =?us-ascii?Q?K03G7LFWua79yEsAX2BPTs7nYE4EkABwN9HsQ7QQ7jcfPAyRiI2lGD++s6Dk?= =?us-ascii?Q?xQlZ/b9pbqDazlev+6QlW+aRyOfcNnsBaQRQucjy/YDhdsycktJkUzuA1MLq?= =?us-ascii?Q?WtI3i/pE8oN3FxtiE8s+XOnBFdZc7zjkSKmFiIAsk5GJiv6kjCQHcjz9t04D?= =?us-ascii?Q?4EFE9S/9dmLLecBwDltKRsHUUFxn9JdBxjIUyT7qGHHHL+NIpY2DU3qRlEST?= =?us-ascii?Q?slVeJO+80iGIkyI85NAixJ+dZkxrt9vZjyfOhZbJaoZkToCJ74ARZsBQbkmb?= =?us-ascii?Q?O1v6DJLDGrlrL7fdFeGHOQEpXwDFmt8vZbiT/guKgJ3STNiJwMdL0slmfSZu?= =?us-ascii?Q?1mxna44enT1NsNRbV2fIAg1JP4DgBHH6le?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB205; 5:IiTlXobDkUueTaOaYov3ZcqVTBYNobUe4oSaU5LYaBTl+Xeuo5L1b8k2l0t/aQbVloYxY2IKXHgz0LQeYaD59zkXHsWN0j597Ps+W1p1BKleljhhhJJUUFJ6YCKLJuuYQPqeWLN/r9cHfApkAXgxHQ==; 24:KT224groH8fi6ZUFA0aoTs/StR1cdxpsUYI0hHjDTTbCbwUmo4BZcte7BkLUSDWVvMtfacobLNx1WreVR2yRGXEX0x30aSng5tVP7fMnMIs=; 7:sPBDFl0MR2rfhYlySJU0MqXT7WET3IPwHfYi0JQc1sOESWFZZ/zdBoGKrHbfQHqZ1W0KwiC0hs3usvCDfWhjJ+/lsgPs2se5b1mH+VGUHgfsxCS0CadWJBas/+nobr11gNMtuLgGyXVixZPhxlaQpeEtEw/LvdoOPCOPC++/MIeWcxVR55TLOtIA8V5weJPe SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 May 2016 15:50:43.3743 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB205 Archived-At: Subject: [Idr] Presentation recording for draft-vandevelde-idr-flowspec-path-redirect, for Monday May 16 interim X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 15:51:09 -0000 --Apple-Mail=_2F47A287-D6DB-4E14-9A17-372E229E287C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Hi Everyone, The recording for Gunter's presentation is available, link below. Please = review it before the interim on Monday. I'll send another message when = the slides have been uploaded to the meeting materials site. As a reminder, we are having presenters record their talks instead of = doing them live, as an experiment in dealing with the challenges of = virtual interims across many timezones. This lets us time-shift much of = the work, hopefully accommodating people's time zone requirements = better. We'll be interested in your feedback regarding how well (or = poorly) it worked, after the Monday meeting. And another reminder, if you have questions or comments regarding the = presentation or draft, please consider providing them on the mailing = list. There is no need to wait until the interim, although of course if = you'd rather do it verbally during the meeting that's OK too. Regards, --John > Begin forwarded message: >=20 > From: IDR Working Group > Subject: WebEx recording is available for viewing: = draft-vandevelde-idr-flowspec-path-redirect-20160512 1502-1 > Date: May 12, 2016 at 11:42:25 AM EDT > To: > Reply-To: >=20 > Hello, > IDR Working Group wants to share this WebEx recording with you. > =20 > draft-vandevelde-idr-flowspec-path-redirect-20160512 1502-1 > Thursday, May 12, 2016 > 11:30 am | Eastern Daylight Time (New York, GMT-04:00) > =20 > Play recording = (21 min) > Recording password: (This recording does not require a password.) --Apple-Mail=_2F47A287-D6DB-4E14-9A17-372E229E287C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" Hi Everyone,

The recording for Gunter's presentation is available, link = below. Please review it before the interim on Monday. I'll send another = message when the slides have been uploaded to the meeting materials = site.

As a = reminder, we are having presenters record their talks instead of doing = them live, as an experiment in dealing with the challenges of virtual = interims across many timezones. This lets us time-shift much of the = work, hopefully accommodating people's time zone requirements better. = We'll be interested in your feedback regarding how well (or poorly) it = worked, after the Monday meeting.

And another reminder, if you have = questions or comments regarding the presentation or draft, please = consider providing them on the mailing list. There is no need to wait = until the interim, although of course if you'd rather do it verbally = during the meeting that's OK too.

Regards,

--John

Begin = forwarded message:

From: = IDR Working Group <messenger@webex.com>
Subject: = WebEx recording = is available for viewing: = draft-vandevelde-idr-flowspec-path-redirect-20160512 1502-1
Date: = May 12, 2016 at 11:42:25 AM = EDT
To: = <jgs@juniper.net>
Reply-To: = <idr-chairs@tools.ietf.org>

Hello,
IDR Working Group wants to share this WebEx = recording with you.
 
draft-vandevelde-idr-flowspec-path-redirect-20160512 = 1502-1
Thursday, May 12, 2016
11:30 = am  |  Eastern Daylight Time (New York, = GMT-04:00)
 
Play recording (21 = min)
Recording password: (This recording does not require a = password.)

= --Apple-Mail=_2F47A287-D6DB-4E14-9A17-372E229E287C-- From nobody Thu May 12 09:08:36 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A6412B05B; Thu, 12 May 2016 09:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBPXChc2Tuwt; Thu, 12 May 2016 09:08:32 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0109.outbound.protection.outlook.com [207.46.100.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 250B612D1A9; Thu, 12 May 2016 09:08:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CoUO1wKTFLiWP8XcJKGg9WPU210WiWK6JodccpL5Pj4=; b=Ipnk3AQysvDOvkgj+hPpzitLLByU6cXnKmG99rzAfQSgwkoBkU00iKhxkeOLlJBWr6H+5fDNOczAen/E5DBZpzlQQeISeUTT1GDXWYYaZK3oyo3nwQ4eVJZpfn0vn/pANd5yHJG8RTwnKXsyBbjVxKKGcUufLyHYmwvM1f4UMCc= Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=juniper.net; Received: from [172.29.39.101] (66.129.241.11) by BL2PR05MB194.namprd05.prod.outlook.com (10.242.198.147) with Microsoft SMTP Server (TLS) id 15.1.492.11; Thu, 12 May 2016 16:08:28 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: Date: Thu, 12 May 2016 12:08:22 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20160502175801.15655.80242.idtracker@ietfa.amsl.com> <20160511143210.GC7636@pfrc.org> To: Kathleen Moriarty X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: BY1PR17CA0039.namprd17.prod.outlook.com (10.162.18.177) To BL2PR05MB194.namprd05.prod.outlook.com (10.242.198.147) X-MS-Office365-Filtering-Correlation-Id: 863136ee-d21a-416d-0578-08d37a7fa939 X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB194; 2:HKRfAtjsbCJeynp594GoIuRAEGSDS5SmcXAjSqe95uLYfExJX45Ef9FEECS+fGdqeyxb29osX5ilrQvJeCDJ7sIVbQeBPfyHpj2QZ+VJr/EuIA4D7CSU3SKHRBxP7WRHKxUGFjQ3jv0Sz0hXKkWH2Z6a+vIWFSm0uKggpoyCfBl29l8oZSYmCbUB7zM6zdcC; 3:uXQC4ChHN6dP/aMCBPqPkAFHv9bYActWwsBYW0UD67pjBvT6jdf9KxL/8bfO37EUC0xDTDJDGaln3UXd8NkOq9OsviF232aPFywrmQ35++C/GrsdzVhnO8+XwaaQtL+a; 25:/ZVFn79Hfk9HrHnmZWHyKH4fE+Rewv4QcQtAQp4wOMFwb6vv9hcLcFW0o/2UkyoaNJ0lGViftYLkWgtOcfV+7OVGv9G3O0SWiFKJvhVbrcCUygdm2kNC7xMQt7G9O791m+IEUSnArHGdkzNFN9+/W9yuJPwl7Zyy+vg1RvdCSHvMK7ZetXZtf+fFNlOU92FFRKLvsu3KLjzVgtVrKyjRqqYonFRTAD7Q/NK4ZUn6cgjgFYdIYxUX2W5WpG2Pq9h1pKy8zEJNpPqK1BngpyUa6Vm+JP9u3gWpXudTWgk9wz7zoKjKs+GErO0njnJqU6UxaCuDq2x0FDneXiAKTkMxR7cjY2tXcOFEjGmDrLu9TO09arxOzAhu6+VNIibkLej+Z74imQltbCfjMVvNBDlTzXW5r8aAh7htGfrzFQSsKU4= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR05MB194; X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB194; 20:trZOORjUcLgYKXq7/9JKtIMWXsG+oL3kmSUPzIhbWt2T/DehV92EVScCQLwrY3Tb9ckyEYZP1Th1efjQEdlu3HGSXCecLHwkEFBK0j6aDmw083JDFFWW0OevIW7oX/xYxHzwePuVkLG2FfKQMcbh6BMpaQP0YTy1Jtz7qoTMzozklSA15FwDRRk/lyM4ws4lQx5A7ff8CbDDkPWtiYiWwvYFL/bLhoaiVxhhoJnsYveezIHBxrgtTWSmwDaw1I8nJA4rt50DKvyjTFRODs3PovbwmpqR8t9v7j4ArmNJumIji5OixkXxdpSq7FlftHqdhvxCMsEXlwShOmg3EVFvXrsZRYQ2Lcf5YahASvNUdP9cvARG8tcNllE2zF7BJSa6JCKu63wgWPgd7qPv8Bfko6BeKushKr9MRam3f4MmuOxJ7rvuVteKuCIGk5kcAfJxS4qO77KkOixdJiiUN7k91UmXXeGwI/pP5hf3b5xxs/HZLTcLOSf4VjpAfP67j5KT; 4:mJeITCVT7WS2zI06sXtwKwsxFdtY8Q9MklGwOM41m6/ReE+rJNuE9w01vR1inziTTnuHthPiY43GmVrxlTSnnYFWNgYI7hIgbs/Mvkgb4R4MoDTTpp91oeYufaxPHS/9pWMr3qlSuj0auhfw7JUTCD2nV8m6XeVBgFNn3AhWfRM5JpeOHTkaVf0tPARcwPMlVaXuOdpcksuiu2KgIJB7EHKIC9jIGnD2KCRxxijMv2uRO7bnLo1C4stwVTDAEEovxrlzdMp82rMk9uAsfOsSAnkPpgShypgVRvCCIV/sGBec5n/T6x5OE34tJGEYHtRu8G1qz0b42Zx8i50Es79PJvi03r+5IMxTwiAt89PcArH76gHgZGy/sj9r5gCWQGfdWloK8URWHmk0ow24XwTphA== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:BL2PR05MB194; BCL:0; PCL:0; RULEID:; SRVR:BL2PR05MB194; X-Forefront-PRVS: 0940A19703 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(52314003)(377454003)(24454002)(76176999)(6116002)(3846002)(50986999)(4326007)(50466002)(5004730100002)(23726003)(46406003)(110136002)(19580405001)(82746002)(92566002)(86362001)(19580395003)(83716003)(5008740100001)(586003)(77096005)(50226002)(47776003)(2950100001)(230783001)(42186005)(97756001)(189998001)(15975445007)(8746002)(66066001)(57306001)(2906002)(81166006)(33656002)(36756003)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR05MB194; H:[172.29.39.101]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BL2PR05MB194; 23:j/n/LPSU2LPlan6iTUak/0ekwNvjPVAxAcimAoamJf?= =?us-ascii?Q?jsxgZ2voBbkG73UriMpHP6R/qvwqTSJx1/UW0Wkhpqu/1XSBRgCQz7XnTbz1?= =?us-ascii?Q?WAfGzD3c/ilTG5GA+GjAsLwU8acz0fExuZuZ4tAPmsNx5ZV1vVWhxLFhL7Fi?= =?us-ascii?Q?AxTE5iTcHyeEm+nFq9qOMbenGwjs0INiTorz4UTWVWXgu+mJOQlVKBLRQXSX?= =?us-ascii?Q?YEh5fivtbbd4VwOdskqEgZC01jHhpw40uta3VE1ayHmBfgeH/+dXIMf5MNJi?= =?us-ascii?Q?/9Yv8m69neFh9me0HiXLXn7revNUQCof78wilOwM0y/FPxON82RJY5pVwcGz?= =?us-ascii?Q?x5zB1N85MiQPGgOA2c247OKcIVlBXjBmpgyXKJCy/Ip4purw/2rRNnZ6BRwd?= =?us-ascii?Q?oFdLqwA9f9oJq33sXZUt6dc+95GNZbV7A+EK6Rg8ii9zWqS1L6rmIvAQBs+H?= =?us-ascii?Q?H4heMsSvin63cotuTD8vGrr1HrxhxLaMZQ8hiEZK4DAJ1uIlCpRV6ZSGaLgu?= =?us-ascii?Q?lgR1rq6HkEfRDQrlxpQVByGgJ1Eqt2FolldfOWYpDpUyAb8zUcBQQzIMptrI?= =?us-ascii?Q?AbbYm/rxWG4qzmZMTVEQ8y9e8MN8KGdUBRGa1y7TcJFhxms4yMRgkVRpTNNM?= =?us-ascii?Q?/BZ4zzHREncGYABd0A9Z9nPBn/HOXBljQs/8hm8O8C8f0qs9KeAHj6vcVjT/?= =?us-ascii?Q?6GPhH2HP1M0CRx/+b6DhAh+vtXqD2anbgMJ8wjeH3OYArZoKnLdlvgHwCzip?= =?us-ascii?Q?nULDUpr15yJE0IkdIUNHDLswbiAJQJw2VUodP1Uo5/TMojUlTlN6EFAeTO0d?= =?us-ascii?Q?skUV3phJHYCvc+luZBTd9Nc7lapa3fND+DR34NN8IZSPITKrZirU65L+9SI+?= =?us-ascii?Q?n7C0kL3rL5VQNPetGqNlg+nu44tfPKPHHlAoql326euba5UnGg6xp0W69oGw?= =?us-ascii?Q?j8tiKsYlQXIzZEHLz7qTTN7jG+k9pHS6BSYHKtoMiNXWFLP045anbCpH/Z1m?= =?us-ascii?Q?f2LiZOrGjgR/clsPQPHuxjKSfcw4AfWQV4cDd6p2ToxvMtV9v4INpv/12Cuq?= =?us-ascii?Q?A+N+ZpMeIZJQP8fOzlIJbXA2ntgCpha7ogJTf+HX7KlW66Qw=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB194; 5:fpNkyarPcivc4XdXQ5m1yinefDz5kdt8zMGsg62UP911aqhperzCxRkQcMhxHC463x1OANpeW6hLnJI7Cl7dnLaJGZg96PaIjaskE0gkmG0UFn9+rO3nh61isXdyKoQI11aHOUvA583U/tvwNfJBZg==; 24:vP4cmXw/DSO/mN5oLi8xsyWPe8tuDv+VsVm94By6OaPQBlBQkiMayw/M4RnhqK+63JkIHMTbEN4kmjq5GmNBF6gr9Su2rQi1Q8vCjbbOb60=; 7:BWzznDTQKREiPZYiIVnKfyxwT3r1moBGmo+YBDZUWWwk/dRHG9o2LQbD3LVuYvHuh3p+UFIZqpBOpo6/b0NJAXXYXX42EljjIEeOBw1iL3KCd5GzkdPJoxT4EYFKUtDjuB7W1jV8CxxB+j1i1h/i9/cUOI6UH9UrGJsIyZMgJQRSqrJJtp2gT0z7ldDkkgW1 SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 May 2016 16:08:28.9953 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR05MB194 Archived-At: Cc: idr wg , russ@riw.us, idr-chairs@ietf.org, draft-ietf-idr-add-paths@ietf.org, The IESG Subject: Re: [Idr] Kathleen Moriarty's No Objection on draft-ietf-idr-add-paths-14: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 16:08:34 -0000 Hi Kathleen, On May 11, 2016, at 10:29 AM, Kathleen Moriarty = wrote: > On Wed, May 11, 2016 at 10:32 AM, Jeffrey Haas wrote: >> Kathleen, >>=20 >> On Mon, May 02, 2016 at 10:58:01AM -0700, Kathleen Moriarty wrote: >>> 1. I'd like to see the security considerations explicitly state that = this >>> could result in a denial of service attack. The resource = consumption is >>> stated nicely, but it would be good (following RFC3552) to state the = type >>> of attack. >>>=20 >>> "This document defines a BGP extension that allows the = advertisement >>> of multiple paths for the same address prefix without the new = paths >>> implicitly replacing any previous ones. As a result, multiple = paths >>> for a large number of prefixes may be received by a BGP speaker >>> potentially depleting memory resources or even causing = network-wide >>> instability." >>>=20 >>> Adding something like: "This could result in a denial of service >>> attack." >>=20 >> The considerations of a BGP peer's normal protocol interactions with = a BGP >> speaker - with or without add-paths - being considered a Denial of = Service >> seems to be unnecessary scare words. >>=20 >> While the add-paths case does permit a much larger number of paths to = be >> propagated, the same issue may apply to simply sending along a much = larger >> amount of some routing table than expected. This could include = sending a >> full Internet routing table to a router scaled for a few thousands of >> routes. >>=20 >> I recommend against this change. >=20 > This is just a comment, so it's up to the shepherd and AD, but adding > this would be in line with the guidance from RFC3552. >=20 > https://tools.ietf.org/html/rfc3552 Looking at RFC 3552 S. 2.3.3 ("Denial of Service") it does suggest that = DoS be considered and identified when relevant. I think Jeff's point = (which I agree with) is that add-path doesn't change the fundamentals of = BGP with respect to DoS -- the peer can send me a bazillion routes, = differentiating them by prefix, or by path-id, or both. It just comes = down to which bits in the NLRI are used to make the routes unique. Anyway, point taken that we should think about this more before making = any definite conclusion, and if add-path does create any new DoS = vulnerability we should identify it. Regards, --John= From nobody Thu May 12 09:13:15 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7179412D68C for ; Thu, 12 May 2016 09:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdPt03lzfdkI for ; Thu, 12 May 2016 09:13:10 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0749.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:749]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6C3512D676 for ; Thu, 12 May 2016 09:13:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wZXWIFOB10zHJ4bv6TAkhWBiJqO8OYzy1uqBmQQmp7A=; b=MiaEF3mHasgL4/TjVxJQKeDwXJqccLfmw6kbw+yeZkooHOpotXHChx/y3873RKm61yTB0Sxk2YqVvT8aG5hlLpjXVwDVxbnKiZDTZTVLLoIn3DxYLOYwBWz9BEsKsL8pluNZEeBI6Nd8tsmnxCp+bh3w8Vw9jhlq+NzXXNjXZLg= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; Received: from [172.29.39.101] (66.129.241.11) by BN1PR05MB201.namprd05.prod.outlook.com (10.255.206.23) with Microsoft SMTP Server (TLS) id 15.1.492.11; Thu, 12 May 2016 16:12:50 +0000 From: "John G. Scudder" Content-Type: multipart/alternative; boundary="Apple-Mail=_3609F35A-AF9B-4753-B671-2389BA2250AE" Message-ID: MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Date: Thu, 12 May 2016 12:12:46 -0400 References: <1135213839.1375091463067745545.JavaMail.nobody@rva2rmd002.webex.com> <41E94382-3E38-4599-B8AB-86A57E75AE38@juniper.net> To: In-Reply-To: <41E94382-3E38-4599-B8AB-86A57E75AE38@juniper.net> X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: DM2PR21CA0029.namprd21.prod.outlook.com (10.161.137.167) To BN1PR05MB201.namprd05.prod.outlook.com (10.255.206.23) X-MS-Office365-Filtering-Correlation-Id: 26776a5f-8041-41a5-61fc-08d37a804433 X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB201; 2:rsfs0FPGHU8hAszZwspuwzArxMeX51EWhrvb9puhTLQCj4whW3RdIVs6GhgK8Yo75nrKgWwwnR1ixSOu9sQFCQzDEm0AikhzgQLtq2XA0NfCvH3QyQOaadLldsbRNcy/bcfUwJXC2MNsR7VfY1qsLKdtCLt+7SX4bRdHtVO9clMng4h34f26OST0hJmzjbEy; 3:amlkIsOwidzKZSN3mdW7zumqdYLjle6uzeJQ3J/P7ob986fdvmg1PldMu27Im+o93jpra0m2aS56xW67pL1kCOz78FP1e526IV0c1tKnjf7D3Sc34XxLEnl9KlDwOPGi; 25:hS55khDjfiAfhfy8KVE4W2Q6CZ5H1ni5+joQZb5AvOs5/MBxJE93Tl9HIKaP/xtKOuisZ9Xv4ocLj7HGxh7tub3xSOy8OCWRrW09E+po4EtwFR0sVpk3GajT1FHAogKRvHCd9zQa8fadahdE2bQqAJKAcUscU9mKHY48k2Q6wMrfLvx26MIIbX7At9oNtZl22CC/M8dSgnQF2Lk2Kg++xPng6YKeknHGsovuXKqihEzNB7p5x/7LzDz2d5JZNVOHKLrktBh1O+4ovl7MboWJiKmHlAOOLG7/DL3hMCg5mafMjBfnN0F70lqxUSoGPkHsz8ROVmndKTiSkuZp9c/qEyNy4LB4b/gS5qj2Dix7g1VL9nNPWDWXN2DhqQeoTFkwswENEqQ+44+28TbUrrJKOS08vxw8kGI0xUGhpHbjskY= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB201; X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB201; 20:ZgoExz46/LIp0e68u55/+tBPhjwPFNnBM2iQpj7P2BsgMwCyY7puIXrdkmJDkJq/eaZ0ocL1HIEFFtgA4fuAGBwcUiM7ghfYwyP4IxqWxRbzoZgi/1fT31QC+GooSZtx5jQgWDzRM81TErRM+bKnHVs74kIMKLTSV1+VRJI/0RpmlE+J2J0fWVM/FroobXOR4SYvuUqAwLV7x99UhgUhqNJcs/16ZXej/W7Te3gtSYqp+EV35jjYkjqyiNBmQjmn+XhNNgpLDrd7zcJ+FGSynbfi6V6zEL5QiYx/nUn2D9NiN2gTu+mx/qKIh08drgJFCY3Jpqbc3qldZ3W2qfRqkqjw6roRlTxzjhOrVfr93FBqrt8wdp+L9tEnusfREYCOJSYiO6C8sJbUoGcZKIGsrVFzn+7j7xukhYExD6IGZdWIg2Dgjr4EAOpKI6qFrTBJxSYG130fWxSWX5M1tasJcw8rgak2weQ9HO7fjFTDyIsEKyeBN2uPDyPcA4XAzTnX; 4:nP/Toe0NuziEbW5Ivp8ZOREO6IKyTUBM7PaQeaNSh79YhSOOZbpOp9YTF7S6rk5LY4pONLqjKg/pMoFRdLmKlOw3rRIsUfivvLNCHK/eaz/k5CFfUybYg756TzGNtUxz+NRZlKOmnyUXkq2CTjShhRlCxboN0dC8ZyP+xEYrHFSCnY73ToUO6mX27U1IqLdipuA8iGe5vs8TojJxXYYKCaTwO9yEmNGbkfCAKyU8lu2pafRbXapSvSgRxuHIdxBaTLrb41yCGFcflSV+cNOSb0+/c+OWzJY59J+Wp9R73a3d7SCLPYkcgVGyJOlD84JK86vXmbE9IpjhSdOenkIz2kzulz4zDYjbmSLcT4iI38AEWzYfrK7l+scC6u2nnlOtRYl9/QQTpamKXkjh9ZptVSFXOJpEELbgepuI59CvzuyG2YfL+J9wVerDc8E2Y4qY X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:BN1PR05MB201; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB201; X-Forefront-PRVS: 0940A19703 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(377454003)(17703002)(53754006)(24454002)(25584004)(33656002)(66066001)(19617315012)(50986999)(86362001)(36756003)(57306001)(6116002)(76176999)(50226002)(81166006)(82746002)(586003)(2906002)(3846002)(19580405001)(19580395003)(84326002)(260700001)(5004730100002)(110136002)(15975445007)(16799955002)(83716003)(77096005)(107886002)(92566002)(512954002)(42186005)(69556001)(2351001)(450100001)(2950100001)(551544002)(230783001)(189998001)(5008740100001)(24704002)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB201; H:[172.29.39.101]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1PR05MB201; 23:jjudyeyT7f0QgVyGCrq0ocp4az3pjy9zJTuv+53g41?= =?us-ascii?Q?UrqKqPDETwd/FY3jI8H1AXMrD2QeeWPcxaU7biKtbiZLCnLGMdJKSKzC5Lmg?= =?us-ascii?Q?RUZlIFApTuNR5ojuTkJ8xK94V4SyMH6iY0prUC+BYD3ES9pKHpVq4EdQAnYt?= =?us-ascii?Q?F19rJ3fABxYHTUCtJvAlMGyYh6oM0/jbDx64nvLi2yhL7S6HVkbChfzFYJoY?= =?us-ascii?Q?+S6oEWkDZiX3BoshHtGKd0v9q+Qg9hTTAOKY9qqpCdB7v73nlezv1ny1wezk?= =?us-ascii?Q?iu+dWM+z904PLvBiel36LENR4UKPBM8BRqZU6b5wxd9SyNdXA3WaJqV2MKbU?= =?us-ascii?Q?dACqX3TU8k3hGtWCeGsyAQwgmNcqkk5JPrTjZ/XJpiKR4QiZpCr6fRVv7vXv?= =?us-ascii?Q?wqCiB07hxiUuhmLT4bdqKmIsC2PJ3G3qP4VZdrdS3uRE5KzStzzN4Ipc0Gw7?= =?us-ascii?Q?qOlYoX51jGlGWtN8nKkLdR3fvPrzORTn6OrjKAb0J1iS17CEjADgNqItUMIm?= =?us-ascii?Q?yCOZUZ+fo5e2XahTieJUkqKPgSB6PoAdtypPLoiS7VYN0B3c1uvNHcet+7c5?= =?us-ascii?Q?iIx4foEB3Sa3r6JgzGn3II34ErfMIhCZfVnYEyAu95TZ1hPsUJ7VQDBFpT9E?= =?us-ascii?Q?hiux6NadjnapSDbcvB5IQiHWnI8k8e0VJNokJXvhkGHb2FmF4+Yp0jAUktNK?= =?us-ascii?Q?kdsjXyrazErsomxJcDYE8nQFNOktd63vhXnxlm7S9Fsz3FE7wndEHa8CPxEz?= =?us-ascii?Q?B5h4pI/+vvAxFRKJ1LE04JTRWbvkLYVyL+UHHXk1YPEQZLyDgiRqtFD/+Qb1?= =?us-ascii?Q?FbPbIRhVxdNgQIVGqWDwXddtIrCiV4/5+YJGsZeELBz/vrKDvCxvdyFmsME2?= =?us-ascii?Q?3mZbOMt9hQkrjHGaMsliWkPk81wFRftObI5Jna/mOyXKbnfXBqG5lEpwortn?= =?us-ascii?Q?ijqoUMKHH8Z4p0JlA5vkbr1K65kpfRcm2BfJgw/M3LUDJFLfJHTlnO85xbuT?= =?us-ascii?Q?zCSZkCw7kFKrJY57T45OjbzQdla5Ajcp9tA0OeWVRXfgZQGJ2ssp3WFqeE82?= =?us-ascii?Q?tVzVYlWKPHSu1p6i4xUzc272Mb0G3KxP3eZ+uES4DmJv8pTJGjMxfPeE28FA?= =?us-ascii?Q?9Hi6M4m+mTs6BEBOvPCemK76LesEc9Kxj8uEOOKhYiGS+fa/kymN9pyEFpQ0?= =?us-ascii?Q?InqmHOAe5EOlAsRSzndXh/k0RLIgvluM00Bn1TaQ9Razr9R1Nx70c4Rg=3D?= =?us-ascii?Q?=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB201; 5:WVW0srHfacfRX2aGEdWveNqJTj363dfcM0UCfC9jynB1FGvmapFjlQlXsz1vnfGOPbmF98JU5qcLgshMnSgjrJu2rwBo/jgftyysa4/MFVXemMct7EyVNSM6NoYvRtB4qe3HBNakdm6C/29QorMW2Q==; 24:a6T0zHSXD6k1fnqS+RsWfc94GOpOhxmc56I4yCRvgOXHfAMvnIR/UxWZ0iu5y0tqEXlxB5uc7sgI2THoeTQBsL2kawkHlkHQTDXJpMP0/QY=; 7:6M0bP4D/ek6OCFfiGlQhYwCBpor5Oi2DxaaXuFHTycYCvmV6+fRGjJAOJWEAJVbVdlsDN5GbWEPIEXnR9Hb7Jj8pHDogoJhS7zYLbsgOhnQ0K3sYNib4kym5/xBsFAW2cqLBFuMPNmVGW1J4QFLsOSlU3qYwbpBLRPG8WneNSZgD4W2gU8aSRPOSf9BRZHgW SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 May 2016 16:12:50.1752 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB201 Archived-At: Subject: Re: [Idr] Presentation recording for draft-vandevelde-idr-flowspec-path-redirect, for Monday May 16 interim X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 16:13:12 -0000 --Apple-Mail=_3609F35A-AF9B-4753-B671-2389BA2250AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Slides: = https://www.ietf.org/proceedings/interim/2016/05/16/idr/slides/slides-inte= rim-2016-idr-5-0.pdf --John > On May 12, 2016, at 11:50 AM, John G. Scudder wrote: >=20 > Hi Everyone, >=20 > The recording for Gunter's presentation is available, link below. = Please review it before the interim on Monday. I'll send another message = when the slides have been uploaded to the meeting materials site. >=20 > As a reminder, we are having presenters record their talks instead of = doing them live, as an experiment in dealing with the challenges of = virtual interims across many timezones. This lets us time-shift much of = the work, hopefully accommodating people's time zone requirements = better. We'll be interested in your feedback regarding how well (or = poorly) it worked, after the Monday meeting. >=20 > And another reminder, if you have questions or comments regarding the = presentation or draft, please consider providing them on the mailing = list. There is no need to wait until the interim, although of course if = you'd rather do it verbally during the meeting that's OK too. >=20 > Regards, >=20 > --John >=20 >> Begin forwarded message: >>=20 >> From: IDR Working Group > >> Subject: WebEx recording is available for viewing: = draft-vandevelde-idr-flowspec-path-redirect-20160512 1502-1 >> Date: May 12, 2016 at 11:42:25 AM EDT >> To: > >> Reply-To: > >>=20 >> Hello, >> IDR Working Group wants to share this WebEx recording with you. >> =20 >> draft-vandevelde-idr-flowspec-path-redirect-20160512 1502-1 >> Thursday, May 12, 2016 >> 11:30 am | Eastern Daylight Time (New York, GMT-04:00) >> =20 >> Play recording = (21 min) >> Recording password: (This recording does not require a password.) >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --Apple-Mail=_3609F35A-AF9B-4753-B671-2389BA2250AE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" Slides: https://www.ietf.org/proceedings/interim/2016/05/16/idr/slides/= slides-interim-2016-idr-5-0.pdf

--John

On = May 12, 2016, at 11:50 AM, John G. Scudder <jgs@juniper.net> = wrote:

Hi Everyone,

The recording for Gunter's presentation is available, link = below. Please review it before the interim on Monday. I'll send another = message when the slides have been uploaded to the meeting materials = site.

As a = reminder, we are having presenters record their talks instead of doing = them live, as an experiment in dealing with the challenges of virtual = interims across many timezones. This lets us time-shift much of the = work, hopefully accommodating people's time zone requirements better. = We'll be interested in your feedback regarding how well (or poorly) it = worked, after the Monday meeting.

And another reminder, if you have = questions or comments regarding the presentation or draft, please = consider providing them on the mailing list. There is no need to wait = until the interim, although of course if you'd rather do it verbally = during the meeting that's OK too.

Regards,

--John

Begin = forwarded message:

From: IDR Working Group <messenger@webex.com>
Subject: WebEx recording is available for viewing: = draft-vandevelde-idr-flowspec-path-redirect-20160512 1502-1
Date: May 12, 2016 at 11:42:25 AM EDT
To: <jgs@juniper.net>
Reply-To: <idr-chairs@tools.ietf.org>

Hello,
IDR Working Group wants to share this WebEx = recording with you.
 
draft-vandevelde-idr-flowspec-path-redirect-20160512 = 1502-1
Thursday, May 12, 2016
11:30 = am  |  Eastern Daylight Time (New York, = GMT-04:00)
 
Play recording (21 = min)
Recording password: (This recording does not require a = password.)

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

= --Apple-Mail=_3609F35A-AF9B-4753-B671-2389BA2250AE-- From nobody Thu May 12 09:42:01 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFC3112D1ED; Thu, 12 May 2016 09:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3BpTxvDP39g; Thu, 12 May 2016 09:41:52 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92C7412D6C5; Thu, 12 May 2016 09:41:52 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id f66so105006237vkh.2; Thu, 12 May 2016 09:41:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=9+rLWZkqmdMiKAKALQkizcVeQrL9hitK5mzk6a+fYz8=; b=kV0s4EOmnvbJyIMgUASZnQFADm4ZkiZbICGw38zk3H2kqTMzo/8uRxGPye5rCPQ7GI vCgkkj1fSu37e7ARsG+pZHz5AC3sQe/6d6aXX/WQcQ1WitmhuAiw4Q2ACgU19N4IJjeO 09lazTiR7SFPSdlhB68nizjuBxNp8XheyBtfZYyFXfAcG8mt6L1hMO5wP8TnbGT3DEbf V862KXmbbm3x85VsL4/A+3QxCwf8QFGvxfbKe0hlahcQyyTGeVxawILhTudc8T50MWO9 qFpIxAIVzWjrcTrraXNpCpCEID6hrf5VHk2XUadnnwERU7jGC2cyjNzM/1lYE1rtEy8Y RLtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=9+rLWZkqmdMiKAKALQkizcVeQrL9hitK5mzk6a+fYz8=; b=PcZeAdFqfI1yewJyVfwDc6FZd/hQ0j48Ivk8UVd/yqbe7JhnC+qDWz6FT1FrgeRI9x iTkRL2e1hUGOFdost1FiZtqrErRKLtoDVjTcmRjrUvHL3zq7MDxZsyFAfGFTQfh5TXLm HCDoNCuqvAcB2UVFUacUB0AWg/oLJaA7Zr0ccI2Y3kjM+Di4JfEIzYsGv4zEaM95/W4x ZvWJxraBrluaFylwY6nXaSxRx3KoRO292fXB+PlPjLSdz2CWHS3n7lfjJmxt7ntE4JWK jvUW2T/PiNJHIhUcx+cUMXvNoFD+bOU/0WNRxcSmcKTwa+jOl10uky/ueWifnyIObWC/ riuQ== X-Gm-Message-State: AOPr4FVuAAGH5BIP5sfy1xvnzU49TMAkbLfqRekohtnaWxrymTYG00g6TrjMXhpfyC8sRdkY5N/2fWDT99DHdw== MIME-Version: 1.0 X-Received: by 10.159.35.15 with SMTP id 15mr5215478uae.109.1463071311609; Thu, 12 May 2016 09:41:51 -0700 (PDT) Received: by 10.159.54.231 with HTTP; Thu, 12 May 2016 09:41:51 -0700 (PDT) In-Reply-To: References: <20160502175801.15655.80242.idtracker@ietfa.amsl.com> <20160511143210.GC7636@pfrc.org> Date: Thu, 12 May 2016 12:41:51 -0400 Message-ID: From: Kathleen Moriarty To: "John G. Scudder" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: idr wg , Russ White , idr-chairs@ietf.org, draft-ietf-idr-add-paths@ietf.org, The IESG Subject: Re: [Idr] Kathleen Moriarty's No Objection on draft-ietf-idr-add-paths-14: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 16:41:55 -0000 On Thu, May 12, 2016 at 12:08 PM, John G. Scudder wrote: > Hi Kathleen, > > On May 11, 2016, at 10:29 AM, Kathleen Moriarty wrote: >> On Wed, May 11, 2016 at 10:32 AM, Jeffrey Haas wrote: >>> Kathleen, >>> >>> On Mon, May 02, 2016 at 10:58:01AM -0700, Kathleen Moriarty wrote: >>>> 1. I'd like to see the security considerations explicitly state that t= his >>>> could result in a denial of service attack. The resource consumption = is >>>> stated nicely, but it would be good (following RFC3552) to state the t= ype >>>> of attack. >>>> >>>> "This document defines a BGP extension that allows the advertisement >>>> of multiple paths for the same address prefix without the new paths >>>> implicitly replacing any previous ones. As a result, multiple paths >>>> for a large number of prefixes may be received by a BGP speaker >>>> potentially depleting memory resources or even causing network-wide >>>> instability." >>>> >>>> Adding something like: "This could result in a denial of service >>>> attack." >>> >>> The considerations of a BGP peer's normal protocol interactions with a = BGP >>> speaker - with or without add-paths - being considered a Denial of Serv= ice >>> seems to be unnecessary scare words. >>> >>> While the add-paths case does permit a much larger number of paths to b= e >>> propagated, the same issue may apply to simply sending along a much lar= ger >>> amount of some routing table than expected. This could include sending= a >>> full Internet routing table to a router scaled for a few thousands of >>> routes. >>> >>> I recommend against this change. >> >> This is just a comment, so it's up to the shepherd and AD, but adding >> this would be in line with the guidance from RFC3552. >> >> https://tools.ietf.org/html/rfc3552 > > Looking at RFC 3552 S. 2.3.3 ("Denial of Service") it does suggest that D= oS be considered and identified when relevant. I think Jeff's point (which = I agree with) is that add-path doesn't change the fundamentals of BGP with = respect to DoS -- the peer can send me a bazillion routes, differentiating = them by prefix, or by path-id, or both. It just comes down to which bits in= the NLRI are used to make the routes unique. > > Anyway, point taken that we should think about this more before making an= y definite conclusion, and if add-path does create any new DoS vulnerabilit= y we should identify it. Thanks, John! > > Regards, > > --John --=20 Best regards, Kathleen From nobody Thu May 12 13:27:00 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86A9E12B071 for ; Thu, 12 May 2016 13:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvK9bo7_n3nI for ; Thu, 12 May 2016 13:26:57 -0700 (PDT) Received: from sjmda11.webex.com (sjmda11.webex.com [64.68.124.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B187B12B005 for ; Thu, 12 May 2016 13:26:57 -0700 (PDT) Received: from jva2tc212.webex.com (sjc02-wxp00-lbace03-core-vl120-np10-4.webex.com [64.68.121.248]) by sjmda11.webex.com (Postfix) with ESMTP id 5FDBFC88A2 for ; Thu, 12 May 2016 20:26:57 +0000 (GMT) Received: from jva2tc212.webex.com (localhost [127.0.0.1]) by jva2tc212.webex.com (Postfix) with ESMTP id 25AE868 for ; Thu, 12 May 2016 20:26:57 +0000 (GMT) Date: Thu, 12 May 2016 20:26:57 +0000 (GMT) From: IDR Working Group To: idr@ietf.org Message-ID: <1777113620.18521.1463084817152.JavaMail.nobody@jva2tc212.webex.com> MIME-Version: 1.0 Content-Type: multipart/Mixed; boundary="----=_Part_18519_203910642.1463084817151" X-Priority: 3 Importance: normal Archived-At: Subject: [Idr] WebEx meeting invitation: flowspec tunnel redirection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: idr-chairs@tools.ietf.org List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 20:26:59 -0000 ------=_Part_18519_203910642.1463084817151 Content-Type: multipart/Alternative; boundary="----=_Part_18520_1889743129.1463084817151" ------=_Part_18520_1889743129.1463084817151 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: base64 CkhlbGxvLAoKSURSIFdvcmtpbmcgR3JvdXAgaW52aXRlcyB5b3UgdG8gam9pbiB0aGlzIFdlYkV4 IG1lZXRpbmcuCgoKZmxvd3NwZWMgdHVubmVsIHJlZGlyZWN0aW9uCk1vbmRheSwgTWF5IDE2LCAy MDE2CjEwOjAwIHBtICB8ICBFYXN0ZXJuIERheWxpZ2h0IFRpbWUgKE5ldyBZb3JrLCBHTVQtMDQ6 MDApICB8ICAxIGhyCgoKSk9JTiBXRUJFWCBNRUVUSU5HCmh0dHBzOi8vaWV0Zi53ZWJleC5jb20v aWV0Zi9qLnBocD9NVElEPW05YmU0ODFkMTk5ODhkZDFiNTQ1YmU2NzU5YWVlMjY3YgpNZWV0aW5n IG51bWJlcjogNjQ5IDIzNSA0MTEKTWVldGluZyBwYXNzd29yZDogSmc2NmQycG0KCg0KSk9JTiBC WSBQSE9ORQ0KMS04NzctNjY4LTQ0OTMgQ2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5h ZGEpIAoxLTY1MC00NzktMzIwOCBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpCkFjY2Vz cyBjb2RlOiA2NDkgMjM1IDQxMQoKVG9sbC1mcmVlIGRpYWxpbmcgcmVzdHJpY3Rpb25zOiAKaHR0 cHM6Ly93d3cud2ViZXguY29tL3BkZi90b2xsZnJlZV9yZXN0cmljdGlvbnMucGRmDQoNCgpBZGQg dGhpcyBtZWV0aW5nIHRvIHlvdXIgY2FsZW5kYXIgKENhbm5vdCBhZGQgZnJvbSBtb2JpbGUgZGV2 aWNlcyk6Cmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW1lNjEyNjYyZjYy ZGQ0NzdhZTU5ZWIwN2NmNTg4NmMxYg0KDQoKTmVlZCBoZWxwPyBHbyB0bzoKaHR0cDovL2hlbHAu d2ViZXguY29tCgoKSU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4 IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0 aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBh IGxlZ2FsIG1hdHRlci4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5 IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVp bmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5v dCBqb2luIHRoZSBzZXNzaW9uLgo= ------=_Part_18520_1889743129.1463084817151 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPjxtZXRhIG5hbWU9InZpZXdwb3J0IiBjb250ZW50PSJ3aWR0aD1kZXZpY2Utd2lk dGgsIGluaXRpYWwtc2NhbGU9MSIgLz48Ym9keT48c3R5bGUgdHlwZT0idGV4dC9jc3MiPgpkaXYs cCx0ZCxzcGFuIHt3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7d29yZC1icmVhazogbm9ybWFsO30KCnRh YmxlIHtib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyBib3JkZXI6IDA7Ym9yZGVyLXNwYWNpbmc6 IDA7Ym9yZGVyLWNvbG9yOiB3aGl0ZTsgd2lkdGg6MTAwJSFpbXBvcnRhbnQ7d2lkdGg6NTI1cHg7 IG1heC13aWR0aDo1MjVweCFpbXBvcnRhbnQ7IG1pbi13aWR0aDogMjc5cHghaW1wb3J0YW50O30K dHIge2xpbmUtaGVpZ2h0OiAyMHB4O30KCnRkLGEge2ZvbnQtc2l6ZTogMTVweDtmb250LWZhbWls eTogQXJpYWw7Y29sb3I6ICM2NjY2NjY7cGFkZGluZzowO30KPC9zdHlsZT4KCjx0YWJsZSBzdHls ZT0icGFkZGluZzowOyBtYXJnaW46MCIgd2lkdGg9IjEwMCUiIGFsaWduPSJsZWZ0Ij4KICAgPHRy PgogICAgICA8dGQgc3R5bGU9InBhZGRpbmctdG9wOjVweDsiPgogICAgICAgIDx0YWJsZSBzdHls ZT0id2lkdGg6IDUyNXB4O21hcmdpbi1sZWZ0OjVweCIgYWxpZ249ImxlZnQiPgoJCQk8dHI+CgkJ CQk8dGQgdmFsaWduPSJ0b3AiPgoKPHRhYmxlPgogICAgICAgPHRyPgogICAgICAgICAgPHRkIHN0 eWxlPSJmb250LXNpemU6IDE1cHg7Zm9udC1mYW1pbHk6IEFyaWFsO2NvbG9yOiM0RDRENEQiPgog ICAgICAgICAgICAgSGVsbG8sCiAgICAgICAgICA8L3RkPgogICAgICAgPC90cj4KICAgICAgIDx0 cj4KICAgICAgICAgICA8dGQgc3R5bGU9ImZvbnQtc2l6ZTogMTVweDtmb250LWZhbWlseTogQXJp YWw7Y29sb3I6IzRENEQ0RDtwYWRkaW5nLXRvcDoxMHB4OyI+CiAgICAgICAgICAgICAgICBJRFIg V29ya2luZyBHcm91cCBpbnZpdGVzIHlvdSB0byBqb2luIHRoaXMgV2ViRXggbWVldGluZy4KICAg ICAgICAgICAgICAgIAkgICAgICAgICAgIDwvdGQ+CiAgICAgIDwvdHI+CjwvdGFibGU+CgoKCgo8 dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIw cHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgoJCQkJCQk8dGFibGUgIHdpZHRoPSIxMDAlIj4K CQkJCQkJCTx0cj4KCQkJCQkJCQk8dGQgc3R5bGU9ImZvbnQtc2l6ZToxNnB4OyBjb2xvcjojNEQ0 RDREIj4KCQkJCQkJCQkJPGI+Zmxvd3NwZWMgdHVubmVsIHJlZGlyZWN0aW9uPC9iPgoJCQkJCQkJ CTwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJCQkJPHRyIHN0eWxlPSJtYXJnaW46MHB4Ij4KCQkJCQkJ CQk8dGQ+TW9uZGF5LCBNYXkgMTYsIDIwMTYKCQkJCQkJCQk8L3RkPgoJCQkJCQkJPC90cj4KCQkJ CQkJCTx0ciBzdHlsZT0ibWFyZ2luOjBweCI+CgkJCQkJCQkJPHRkPjEwOjAwIHBtJm5ic3A7Jm5i c3A7fCZuYnNwOyZuYnNwO0Vhc3Rlcm4gRGF5bGlnaHQgVGltZSAoTmV3IFlvcmssIEdNVC0wNDow MCkmbmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7MSBocgoJCQkJCQkJCTwvdGQ+CgkJCQkJCQk8L3Ry PgoJCQkJCQk8L3RhYmxlPgoKPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48 dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KCQkJCQkJPHRh YmxlIHN0eWxlPSJ3aWR0aDphdXRvOyB3aWR0aDphdXRvIWltcG9ydGFudCI+CgkJCQkJCQk8dHI+ CgkJCQkJCQkJPHRkIHN0eWxlPSJjb2xvcjojMDBBRkY5O2ZvbnQtc2l6ZToxNnB4Ij4KCQkJCQkJ CQkJPGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTliZTQ4 MWQxOTk4OGRkMWI1NDViZTY3NTlhZWUyNjdiIgoJCQkJCQkJCQkJc3R5bGU9InRleHQtZGVjb3Jh dGlvbjpub25lO2ZvbnQtc2l6ZToxNnB4O2NvbG9yOiMwMEFGRjkiPgoJCQkJCQkJCQkJPGI+Sm9p biBXZWJFeCBtZWV0aW5nPC9iPgoJCQkJCQkJCQk8L2E+CgkJCQkJCQkJPC90ZD4KCQkJCQkJCTwv dHI+CgkJCQkJCTwvdGFibGU+CgkJCQkJCTx0YWJsZSBzdHlsZT0id2lkdGg6YXV0bzsgd2lkdGg6 YXV0byFpbXBvcnRhbnQiPgoJCQkJCQkJPHRyIHN0eWxlPSJtYXJnaW46MHB4Ij4KCQkJCQkJCQk8 dGQgc3R5bGU9InBhZGRpbmctcmlnaHQ6IDVweDsiPgoJCQkJCQkJCQlNZWV0aW5nIG51bWJlcjoK CQkJCQkJCQk8L3RkPgoJCQkJCQkJCTx0ZD42NDkgMjM1IDQxMQoJCQkJCQkJCTwvdGQ+CgkJCQkJ CQk8L3RyPgoJCQkJCQkJPHRyPgoJCQkJCQkJCTx0ZCBzdHlsZT0icGFkZGluZy1yaWdodDogNXB4 OyI+TWVldGluZyBwYXNzd29yZDo8L3RkPgoJCQkJCQkJCTx0ZD5KZzY2ZDJwbTwvdGQ+CgkJCQkJ CQk8L3RyPgoJCQkJCQk8L3RhYmxlPgoKCgoJCgoJPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWln aHQ6MjBweCI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+ PHRhYmxlPjx0cj48dGQgc3R5bGU9ImZvbnQtc2l6ZToxNnB4Ij48Yj5Kb2luIGJ5IHBob25lPC9i PjwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZD48Yj4xLTg3Ny02NjgtNDQ5Mzwv Yj4mbmJzcDtDYWxsLWluIHRvbGwgZnJlZSBudW1iZXIgKFVTL0NhbmFkYSk8L3RkPjwvdHI+PHRy IHN0eWxlPSJtYXJnaW46MHB4Ij48dGQ+PGI+MS02NTAtNDc5LTMyMDg8L2I+Jm5ic3A7Q2FsbC1p biB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKTwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgi Pjx0ZD5BY2Nlc3MgY29kZTombmJzcDs2NDkgMjM1IDQxMTwvdGQ+PC90cj48dHIgc3R5bGU9Im1h cmdpbjowcHgiPjx0ZD48YSBocmVmPSJodHRwczovL3d3dy53ZWJleC5jb20vcGRmL3RvbGxmcmVl X3Jlc3RyaWN0aW9ucy5wZGYiIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZTtmb250LXNpemU6 MTNweDtjb2xvcjojMDBBRkY5OyI+VG9sbC1mcmVlIGNhbGxpbmcgcmVzdHJpY3Rpb25zPC9hPjwv dGQ+PC90cj48L3RhYmxlPgoKCQkJCQk8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDoyMHB4 Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT48dGFibGU+ PHRyPjx0ZCBzdHlsZT0iZm9udC1zaXplOjEzcHgiPjxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJl eC5jb20vaWV0Zi9qLnBocD9NVElEPW1lNjEyNjYyZjYyZGQ0NzdhZTU5ZWIwN2NmNTg4NmMxYiIg c3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2NvbG9yOiMwMEFGRjk7IGZvbnQtc2l6ZToxM3B4 Ij5BZGQgdGhpcyBtZWV0aW5nPC9hPiB0byB5b3VyIGNhbGVuZGFyLiAoQ2Fubm90IGFkZCBmcm9t IG1vYmlsZSBkZXZpY2VzLik8L3RkPjwvdHI+PC90YWJsZT4KPHRhYmxlPjx0ciBzdHlsZT0ibGlu ZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+ PC90YWJsZT4KPHRhYmxlPgogICAgPHRyPgogICAgICAgPHRkIHN0eWxlPSJmb250LXNpemU6IDEz cHg7Zm9udC1mYW1pbHk6IEFyaWFsO2NvbG9yOiAjNjY2NjY2OyI+CiAgICAgICAgTmVlZCBoZWxw PyBHbyB0byA8YSBocmVmPSJodHRwOi8vaGVscC53ZWJleC5jb20iIHN0eWxlPSJ0ZXh0LWRlY29y YXRpb246bm9uZTtmb250LXNpemU6MTNweDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjojMDBBRkY5 O2ZvbnQtY29sb3I6IzAwQUZGOTsiPmh0dHA6Ly9oZWxwLndlYmV4LmNvbTwvYT4uCgkJPC90ZD4K ICAgIDwvdHI+CjwvdGFibGU+Cjx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAxMHB4OyI+ PHRkIHN0eWxlPSJoZWlnaHQ6MTBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+CgkJCQkJCTx0 YWJsZT4KCQkJCQkJCTx0cj4KCQkJCQkJCQk8dGQgc3R5bGU9ImZvbnQtc2l6ZToxMnB4O2NvbG9y OiAjQTBBMEEwOyI+CgkJCQkJCQkJCUlNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQg dGhpcyBXZWJFeCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2Vu dCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3Zl cmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0 b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25z ZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgaG9z dCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi48L3RkPgoJCQkJCQkJPC90cj4KCQkJCQkJPC90 YWJsZT4KCQkJCTwvdGQ+CgkJCTwvdHI+CgkJPC90YWJsZT4KCTwvdGQ+CiAgIDwvdHI+CjwvdGFi bGU+Cgo8L2JvZHk+ ------=_Part_18520_1889743129.1463084817151-- ------=_Part_18519_203910642.1463084817151 Content-Type: application/octet-stream; name="WebEx_Meeting.ics" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="WebEx_Meeting.ics" QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpFYXN0ZXJuIFRpbWUKQkVHSU46U1RBTkRBUkQKRFRTVEFSVDoyMDE0MTEwMVQwMjAw MDAKUlJVTEU6RlJFUT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0xU1U7QllNT05USD0xMQpUWk9G RlNFVEZST006LTA0MDAKVFpPRkZTRVRUTzotMDUwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDE0MDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0yU1U7QllNT05USD0zClRaT0ZGU0VURlJPTTotMDUw MApUWk9GRlNFVFRPOi0wNDAwClRaTkFNRTpEYXlsaWdodCBTYXZpbmdzIFRpbWUKRU5EOkRBWUxJ R0hUCkVORDpWVElNRVpPTkUKQkVHSU46VkVWRU5UCkFUVEVOREVFO0NOPSIiO1JPTEU9UkVRLVBB UlRJQ0lQQU5UO1JTVlA9VFJVRTpNQUlMVE86aWRyQGlldGYub3JnCk9SR0FOSVpFUjtDTj0iSURS IFdvcmtpbmcgR3JvdXAiOk1BSUxUTzppZHItY2hhaXJzQHRvb2xzLmlldGYub3JnCkRUU1RBUlQ7 VFpJRD0iRWFzdGVybiBUaW1lIjoyMDE2MDUxNlQyMjAwMDAKRFRFTkQ7VFpJRD0iRWFzdGVybiBU aW1lIjoyMDE2MDUxNlQyMzAwMDAKTE9DQVRJT046aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRm ClRSQU5TUDpPUEFRVUUKU0VRVUVOQ0U6MTQ2MzA4NDgxNgpVSUQ6ZDUxNmZmYmUtM2I1YS00YmUx LTkyNzYtODY2NTY1Njg2ODVjCkRUU1RBTVA6MjAxNjA1MTdUMDIwMDAwWgpERVNDUklQVElPTjpc blxuXG5KT0lOIFdFQkVYIE1FRVRJTkdcbmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBo cD9NVElEPW1hOTkxZDI3MjkwOWRmNTc5ODhlNjRkYzgwNzVhMjgzMFxuTWVldGluZyBudW1iZXI6 IDY0OSAyMzUgNDExXG5NZWV0aW5nIHBhc3N3b3JkOiBKZzY2ZDJwbVxuXG5cbkpPSU4gQlkgUEhP TkVcbjEtODc3LTY2OC00NDkzIENhbGwtaW4gdG9sbCBmcmVlIG51bWJlciAoVVMvQ2FuYWRhKSBc bjEtNjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSlcbkFjY2VzcyBj b2RlOiA2NDkgMjM1IDQxMVxuXG5Ub2xsLWZyZWUgZGlhbGluZyByZXN0cmljdGlvbnM6IFxuaHR0 cHM6Ly93d3cud2ViZXguY29tL3BkZi90b2xsZnJlZV9yZXN0cmljdGlvbnMucGRmXG5cblxuXG5D YW4ndCBqb2luIHRoZSBtZWV0aW5nPyBDb250YWN0IHN1cHBvcnQgaGVyZTpcbmh0dHBzOi8vaWV0 Zi53ZWJleC5jb20vaWV0Zi9tY1xuXG5cbklNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRo YXQgdGhpcyBXZWJFeCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24g c2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBkaXNj b3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5b3Ug YXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBj b25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUg aG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi5cbgpYLUFMVC1ERVNDO0ZNVFRZUEU9dGV4 dC9odG1sOgk8Rk9OVCBTSVpFPSIxIiBGQUNFPSJBUklBTCI+Jm5ic3A7PEJSPiA8Rk9OVCBTSVpF PSI0IiBGQUNFPSJBUklBTCI+CQk8YQkJCQkJaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9p ZXRmL2oucGhwP01USUQ9bWE5OTFkMjcyOTA5ZGY1Nzk4OGU2NGRjODA3NWEyODMwIj48Rk9OVCBT SVpFPSIzIiBDT0xPUj0iIzAwQUZGOSIgRkFDRT0iQXJpYWwiPkpvaW4gV2ViRXggbWVldGluZzwv Rk9OVD48L2E+CQkJPHRhYmxlPgkJCQk8dHI+CQkJCQk8dGQ+CQkJCQkJPEZPTlQgU0laRT0iMiIg Q09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5NZWV0aW5nIG51bWJlcjo8L0ZPTlQ+CQkJCQk8 L3RkPgkJCQkJPHRkPgkJCQkJCTxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJh cmlhbCI+NjQ5IDIzNSA0MTE8L0ZPTlQ+CQkJCQk8L3RkPgkJCQk8L3RyPgkJCTwvdGFibGU+CQkJ PHRhYmxlPjx0cj48dGQ+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFs Ij5NZWV0aW5nIHBhc3N3b3JkOjwvRk9OVD48L3RkPjx0ZD48Rk9OVCBTSVpFPSIyIiAgQ09MT1I9 IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5KZzY2ZDJwbTwvRk9OVD48L3RkPjwvdHI+PC90YWJsZT4J CTwvRk9OVD48Rk9OVCBTSVpFPSIxIiBGQUNFPSJBUklBTCI+Jm5ic3A7PEJSPiZuYnNwOzxCUj48 L0ZPTlQ+PEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9IjMiIENPTE9SPSIj NjY2NjY2IiBGQUNFPSJhcmlhbCI+Sm9pbiBieSBwaG9uZTwvRk9OVD4mbmJzcDsgPEJSPjxGT05U IFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+PHN0cm9uZz4xLTg3Ny02Njgt NDQ5Mzwvc3Ryb25nPiZuYnNwO0NhbGwtaW4gdG9sbCBmcmVlIG51bWJlciAoVVMvQ2FuYWRhKTwv Rk9OVD4mbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlh bCI+PHN0cm9uZz4xLTY1MC00NzktMzIwODwvc3Ryb25nPiZuYnNwO0NhbGwtaW4gdG9sbCBudW1i ZXIgKFVTL0NhbmFkYSk8L0ZPTlQ+Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2 NjY2NiIgRkFDRT0iYXJpYWwiPkFjY2VzcyBjb2RlOiA2NDkgMjM1IDQxMTwvRk9OVD4mbmJzcDsg PEJSPjxhIGhyZWY9Imh0dHBzOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rp b25zLnBkZiI+PEZPTlQgU0laRT0iMSIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9ImFyaWFsIj5Ub2xs LWZyZWUgY2FsbGluZyByZXN0cmljdGlvbnM8L0ZPTlQ+PC9hPiAmbmJzcDsgPEJSPjwvRk9OVD48 QlI+PEJSPgkmbmJzcDs8QlI+CTxGT05UIFNJWkU9IjEiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJh cmlhbCI+CQkJCUNhbid0IGpvaW4gdGhlIG1lZXRpbmc/PC9GT05UPgk8YSBocmVmPSJodHRwczov L2lldGYud2ViZXguY29tL2lldGYvbWMiPgk8Rk9OVCBTSVpFPSIxIiBDT0xPUj0iIzAwQUZGOSIg RkFDRT0iQXJpYWwiPkNvbnRhY3Qgc3VwcG9ydC48L0ZPTlQ+PC9hPgkmbmJzcDs8QlI+Jm5ic3A7 PEJSPjxGT05UIENPTE9SPSIjQTBBMEEwIiBzaXplPSIxIiBGQUNFPSJhcmlhbCI+SU1QT1JUQU5U IE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlv IGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNv cmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9p bmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNv cmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3Mg eW91ciBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLjwv Rk9OVD48L0ZPTlQ+ClNVTU1BUlk6Zmxvd3NwZWMgdHVubmVsIHJlZGlyZWN0aW9uClBSSU9SSVRZ OjUKQ0xBU1M6UFVCTElDCkJFR0lOOlZBTEFSTQpUUklHR0VSOi1QVDVNCkFDVElPTjpESVNQTEFZ CkRFU0NSSVBUSU9OOlJlbWluZGVyCkVORDpWQUxBUk0KRU5EOlZFVkVOVApFTkQ6VkNBTEVOREFS Cg== ------=_Part_18519_203910642.1463084817151-- From nobody Thu May 12 13:41:20 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB23F12D16D for ; Thu, 12 May 2016 13:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOlDpw6Ou2W4 for ; Thu, 12 May 2016 13:41:16 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0704.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:704]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EEF812B040 for ; Thu, 12 May 2016 13:41:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bGQB10A/r48yCsJIueMUJROWd6i0GnxKyU0qZcCOzOg=; b=bXR2GwPZXi+WGFMOBaMiM9oPeljiUpTTVufJj65PWGTLv8wm/nYH58RQo0bVsXTkp0iC1E6h6djcjhWrniLD/wvjwOMlQXl3Ln3+XnVja1C8ZlhiQyE1ZkLmMTxcWaLOFqnv5/nAAwVGn1GJ5eZTNLN70Gw1jvL56g0E0OMSO1M= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; Received: from [172.29.39.101] (66.129.241.11) by BN1PR05MB204.namprd05.prod.outlook.com (10.255.206.17) with Microsoft SMTP Server (TLS) id 15.1.492.11; Thu, 12 May 2016 20:40:58 +0000 From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <6D3F4B79-5576-42E6-880B-7A8B4103884A@juniper.net> Date: Thu, 12 May 2016 16:40:52 -0400 To: MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: SN1PR17CA0060.namprd17.prod.outlook.com (10.163.3.156) To BN1PR05MB204.namprd05.prod.outlook.com (10.255.206.17) X-MS-Office365-Filtering-Correlation-Id: 227f4ec6-1453-4c0b-a5d0-08d37aa5b960 X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB204; 2:A+0c3uMSPRBz0Da0gil9Vs+0Bxk2nTHCY8jQ12f1ZE7m1jEEms12ZFaY6XHBYOvHJmzX19Sh+KVv2QRYQpQmtK77cESD5StWTOc3jcIbJCUeszq1KG/0sbdsdA5xJwu8X863AbXT72oIu1GGOo49d2GFTCLaLomBJnqNQgQ/xOBvUIP+mlcDZbxWETMQbBlw; 3:CmBA/RnajCHVvzHBPMU4urdg0dz9EwZ0QN+gYeiataMfVPr5nymSzAmIwSHEHWbyoIADf1sgEh92jB0ZJ1cqnViqnwNOYXZocKgQwwN6NvWfFYjU6E/6kAUmKbAcTWA0 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB204; X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB204; 25:n+xLXWxJTbcYX7/JJ10y1hRjO3WSKEe+uw4r5SG3ROufAmhBW4RTzs6ocC6fVihdsLdrv0zBVVHSO4ZB1o+HueWPo0+kz72aciHOU0H394jOPhG3R8Qv6awI2Xw+5B5CoI2veHoWF95Tc1KaL6HhUL0zXQ7bY4bnp5V8sZgSSLgtyDgj/W07lWrAzDBSj0lhjelDZ3R1/8nHtpzf4gRbyQ20WXcfEFD/g5Va+Nuw1bsRghjrwxrQVdtZDZCVMmfWV8N0yzpaI3LDPxteZLUBZg5CfDwva2dYEpg6sXclRZb8vxlOqXSqbxNAXU1TrLPkWbgJ71+fQsX+TbrQLovdbIph3PJ99mjoVN3toAINvqN3cWu/gci/20qUc9NyXAqK1ZM68bjW6nfsJCFZD+WGG1DtnQ3/wFNxUWgkR7vFDy05srjVUzRDUJe2FghIdlIAaDF/ozLXeEQJsRzpzbIzlqZRm3UohVCqs5QmkxdN3Wy2mKsjcALLBGL15XldHwiM1sDUp8PTEcfGIC/mmJQKfnSD4dsxSIE9sI5cZSMvHQEolU8W11li6KB/if3Q4vbJOAl4dFvqG5hQKWzU3RD7jivTuieFWqyounhR2q9wx4pFwXU8rPDnJ2fnzDtZrJyDmWKLdZXh+Bl/ksrt9LkzTecWi6iGaK4pmBxR1crpW9THKTzSnSFk2jLiUVYEEWcoA5uFw4wwydInN4RcoYcRuHo41FURFYLEpMTq+eGlz7TN7SWZBgr5WxlZdavATAOfh+5UE6szAMBrCBuSsnj+khF6eCg143fdWMR7CzPBU7qmsmiUUWIf6JBp6ziifN+h3zHwf8veVXX2j5RGR+hF7A== X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB204; 20:HRCeocdmn8lbNJ1GJlBV2fnBUI7rMEJVQn7SyXaRRdjz1Bwx0p6h/Ag5Tbs43GsOJYpakiquWkFn9lUo2P60lLscl373cdaRDoFDcp0pEpGmCYYitBVOaqdPa9xExr7fFMcxFlhnEurDonBzTez6/oPYUm59YXIZGakgZtPN4s2YtBp/Jrb/f+nOfQVvOhCwCELwNiJTHch3YXDYtAnoGRnfhjYo2b66i+laldq3uhQTYas0yvCHyu2B9t8KsnhcEwoXxrRPn6h0quKx8MBtKFEudICl8h8+YWH6Ac2a0cpfnh4t1V9ON7eqixVFfPJglgkjCMcGNcM/qHl1dwwse90JWETj9HYD+w+9NJuxD9IzhCV/f94OckOwv+GBuZ0/eOiRlcC4Mbg1R1fWmSYTUounKuq1zUiNc/YR/gzNXhQjCmGW4LN7F2zMgGytR3N9MPvVaTR+nI28mP6d9FsZyH2NHCdVJYSyS1bBXxAsytyk8RhJ1n773oO6ekCvDrlq; 4:V10GpKB+r46thUY4yofjmYl7ZGgzbEoAxmhO1ATK7GdBiDxjmUVA8QQYIc41N2ZROHaF/OXCAqje1JSBf/EYNlTdisnJMO5DF7qOqn+Auo+j8dL8JISM+qZQBTRoMRU4xadmMQ6/Q+unpSLQcv/3P1S447OPN5wgHFh8XrS3jAzOnkA8CU8EoDDASKcK7Qe6r5MIP1K6iDgRYHuvL2fN6Pnnn0XbE8+f3ovPjd73O6YLebEzIH/Ad9g1wv96fyOXxJmZn5n2ybWVDVXVN2hw0djJj632VnAh3znK4VWMqGgYP0AyderYiQe9obzfQEEY71kZye+a3vCdc2jOi4Lpr/14u8upHoBS8UvF+3BTNigZs5u0Lj3Y+Ey0Zg4av4immeI5KvJ8VXQLQi4Wmczpag== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:BN1PR05MB204; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB204; X-Forefront-PRVS: 0940A19703 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(53754006)(107886002)(110136002)(189998001)(57306001)(50226002)(97756001)(66066001)(450100001)(42186005)(47776003)(5004730100002)(33656002)(19580395003)(81166006)(50986999)(2906002)(3846002)(46406003)(36756003)(23726003)(6116002)(229853001)(8746002)(2351001)(15975445007)(50466002)(5008740100001)(86362001)(586003)(77096005)(92566002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB204; H:[172.29.39.101]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1PR05MB204; 23:3BgFur+/Qn7RCZneHFhhDfvoTgkegL382HF/AC3m8C?= =?us-ascii?Q?0jPeFZhvyCdI1UL+eEM81oDLKbYWJ0Ai0diHrcQhLfYmM8C5EuRIwsNkMGQt?= =?us-ascii?Q?wKGraV/Qnn5/vk8YTqdplPrFAaVbH/lWI+OIVYsFLbFwV5zAJo4o2dwzGVLE?= =?us-ascii?Q?UVaWvIFMSaR9vtByLwCcnf1gxgz28pJ4x+33SIH1TTd/EgHkT8jpBFh3uwvY?= =?us-ascii?Q?b5OiDTirPW84B3ZG6ogpFcDwvnFxLgOIlrBmZkJesITXVPDWF905+fEi+m+u?= =?us-ascii?Q?/DeURIpWY7ZS5x7FAsXfBUEZuqe2mR6FfaTtdh6HbsDPIbR+OE7a8uHmKS9F?= =?us-ascii?Q?65L0K5gmRznQ/o8qJj1Mg5wuMFIXx+nzZb9GhCZBucNGE7xxkglZGBliV2RN?= =?us-ascii?Q?eZULY4oSZnL012C7u0wnZu2qQZKRbXJoPQLk7Y5z9Eghh5grOhpdSdZOrjue?= =?us-ascii?Q?OrhhfWTRVNFGUmCYM4RgxreMuWJqPxO/ul1G5nCeeU1Sionh8HaJy/ffDxNM?= =?us-ascii?Q?bHer2Qweod9+YM0CVGTYrjJz6k3mMOCQO6xQ3r2OeBz/+X+tx02YYijEnJc6?= =?us-ascii?Q?VwW7SAAklkxKZWsGXWUVm1OHxfgZa6yyelwYfzSNFotJj1IQRvVbwfZWqbYr?= =?us-ascii?Q?BYM7BQC7VDbN1UavKG/+UA5QTSMu6i+avS5Uy+Ls26HnLcF3GXiepDrW+TU5?= =?us-ascii?Q?mrR6sjC+PfIwml0Q2GCXGl6IoyO2c8ZB/47DR7VkLLGzWfBELPOAw9JlF4zz?= =?us-ascii?Q?L5BqxPtaxOp3AAPpHwLT8r1kwo8Q2b3cvvRCx/nGfQkZh0bETUu8ROYnXk/2?= =?us-ascii?Q?i3eldvep+9WimnBmJuIrZSXpS73wZ4Cjv1NFiZmJ5e/44GZ1YMjqCr1REA7q?= =?us-ascii?Q?AXB9yZOVj40ovN8IV2V06YCIrExDQfhSMuSW9UhWFsQoHiMkbsNVatcTri4i?= =?us-ascii?Q?5DvBb6uz6GaVA5K0cSAlmUKuvocdGPd2KiNWfstg=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB204; 5:zPA2jmynZwKE6ADAeJhG5xsE6pFgBkoWDhURsgSs8zD4eEEEmALDsh5+MdRN38bPagoF7G/2l0mcBGZqLOk+BOoPnew9wUnW9//VDCxH/yHh9ziplVQmk+udJptVT+5uw8lj3IWhrCYcxrLRRMrFew==; 24:O044pDqD4squjvXKoTENbVkD9lemhZxa+nFP+XLI+gUv9nbn1jTL7ObSUvlxyl3RdQnEKJRXfVqpNpl3wnrbD1J6E++p43cjTaWvEY7duKQ=; 7:zHkHEQRSJyoiDjycjIBiAhpYiVI8mgoxqaEnHh8lKnm5a9u4tMjvez0lXukkWfTa6kd5soCsfDuqeNLOlqRg0lbE/h8XI4BORtyoK08lmto/8DwWtytl2Dr/TC/p5auGzmOtemAjnUQOa4afJ3YPYhN3dY1bUBhxQaNK/4tbdxlS1VNUVhe5fPbHAMsHDXli SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 May 2016 20:40:58.4095 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB204 Archived-At: Subject: [Idr] May 16 IDR Interim X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 20:41:19 -0000 Hi All, As (yet another) reminder, we have a virtual interim meeting scheduled = for May 16, 2016 at 22:00 - 23:00 EDT. (Yes, the time of 10 PM EDT is = correct. We apologize to those who are inconvenienced and point out that = other WG members have been putting up with similar suboptimal time zone = scheduling for some time now.) The topic of the interim is flowspec = tunnel redirection. Presentations will be (or have been) prerecorded and = should be reviewed before the meeting, the purpose of the live meeting = is discussion. The agenda has been uploaded:=20 = https://www.ietf.org/proceedings/interim/2016/05/16/idr/agenda/agenda-inte= rim-2016-idr-5 we will update it as presentations are recorded. So far one presentation has been recorded, so far two presentation slide = decks are uploaded. Slides are accessible at the meeting materials site: = https://www.ietf.org/proceedings/interim/2016/05/16/idr/proceedings.html Thanks, --John= From nobody Fri May 13 03:47:12 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F10C12B074 for ; Fri, 13 May 2016 03:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.739 X-Spam-Level: * X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zy2eeZZ4FMMO for ; Fri, 13 May 2016 03:47:05 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2904512B020 for ; Fri, 13 May 2016 03:47:03 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.238; From: "Susan Hares" To: Date: Fri, 13 May 2016 06:46:58 -0400 Message-ID: <008a01d1ad04$c63a77d0$52af6770$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008B_01D1ACE3.3F2A3760" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdGtA5N1fQH6ZeaQT8WhQMAKvH+1Fw== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] IDR interim on May 16th - webex, questions for meeting, and recordings. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 10:47:10 -0000 This is a multipart message in MIME format. ------=_NextPart_000_008B_01D1ACE3.3F2A3760 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The time of the interim is 22:00-23:00 EDT on May 16th. The interim will discuss the following two drafts in order to create a WG solution: . draft-vandevelde-idr-flowspec-path-redirect, and . draft-li-idr-flowspec-redirect-generalized-sid Some of the Questions that will be discuss are included below. Please review the pre-recording presentations prior to the meeting. The Chairs encourage discussion of these questions on the list before, during, and after the meeting. Sue and John ======================== Agenda for IDR Virtual Interim Meeting May 16, 2016 22:00 - 23:00 EDT WebEx: https://ietf.webex.com/ietf/j.php?MTID=m9be481d19988dd1b545be6759aee267b Meeting number: 649 235 411 Meeting password: Jg66d2pm Join by phone 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 649 235 411 Questions for meeting: Submitted by (Eric Wu) 1. Redirect-to-Specific-Tunnel with BGP Path Attribute [TUNNELENCAPS][MPP] and Redirect-to-IID/GSID, Required by different use cases, can we have two docs in IDR In parallel? [Comparison to Redirect-to-IID/GSID , draft-hao will have more little modification to existing mechanisms, No need to do Mapping /Recursive Lookup.] 2. For IID/GSID, one mapping table for all kinds of segments/forwarding-entities vs. one mapping table per segments/forwarding-entities type, should we support both? Chair Questions: 1) Does the WG feel we need the following for RFC5575bis (DDoS) a) Redirection to VRF, b) Redirection to Indirection to IP, and c) Redirection to Service (new)? 2) If the WG desires redirection to Service routing, does the WG desire a) Next-Hop tunnel support? - b) Next-Hop TE Tunnel support? c) Nested Tunnel support? d) Next-Next Hop Tunnel Support? e) Router localized Tunnel recursion? f) Tunnel Encap Recursion: 3) What pieces of the proposed solutions have been implemented and/or deployed? Presentations (prerecorded, please review prior to meeting): - draft-vandevelde-idr-flowspec-path-redirect Gunter Van De Velde 21 minutes https://ietf.webex.com/ietf/ldr.php?RCID=e01d62661085f660f470feddd9bf266f presentation at: https://www.ietf.org/proceedings/interim/2016/05/16/idr/slides/slides-interi m-2016-idr-5-0.pdf draft-li-idr-flowspec-redirect-generalized-sid Eric Wu 20 minutes Streaming recording link: https://ietf.webex.com/ietf/ldr.php?RCID=c8615aa845801a1e4b79cb1708a04484 Download recording link: https://ietf.webex.com/ietf/lsr.php?RCID=4bd504329727d2a811c9cb0c9bc713d8 presentation at: https://www.ietf.org/proceedings/interim/2016/05/16/idr/slides/slides-interi m-2016-idr-5-1.pdf ------=_NextPart_000_008B_01D1ACE3.3F2A3760 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The time = of the interim is 22:00-23:00 EDT on May 16th. =  

 

The interim will discuss the following two drafts in = order to create a WG solution:

 

·         = draft-vandevelde-idr-flowspec-path-redirec= t, and

·         = draft-li-idr-flowspec-redirect-generalized= -sid

 

Some of the Questions that will be discuss are = included below.  Please review the pre-recording presentations = prior to the meeting.   The Chairs encourage discussion of = these questions on the list before, during, and after the meeting. =

 

Sue and John

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

 

Agenda = for IDR Virtual Interim Meeting

 

May 16, = 2016

22:00 - 23:00 = EDT

 

WebEx: = https://ietf.webex.com/ietf/j.php?MTID=3Dm9be481d19988dd1b545be6759aee267= b

Meeting = number:           = 649 235 411

Meeting = password:         = Jg66d2pm

Join by phone

1-877-668-4493 Call-in toll free number = (US/Canada)

1-650-479-3208 Call-in = toll number (US/Canada)

Access code: = 649 235 411

 

Questions for meeting:

 

Submitted by = (Eric Wu)

1. = Redirect-to-Specific-Tunnel with BGP Path Attribute [TUNNELENCAPS][MPP] = and

  Redirect-to-IID/GSID, Required by = different use cases, can we have two docs in IDR In parallel? =

  [Comparison to = Redirect-to-IID/GSID , draft-hao will have more little modification =

  to existing mechanisms, = No need to do Mapping /Recursive Lookup.]

 

2.  For = IID/GSID, one mapping table for

  all kinds of segments/forwarding-entities = vs. one mapping table

  per segments/forwarding-entities type, = should we support both?

 

Chair = Questions:

 

1) Does the = WG feel we need the following for RFC5575bis (DDoS)

  a) Redirection to VRF,

  b) Redirection to Indirection to IP, and =  

  c) Redirection to = Service (new)?

  

2) If = the WG desires redirection to Service routing, does the WG = desire

a) Next-Hop tunnel support? = -

b) Next-Hop TE Tunnel support? =

 c) Nested Tunnel support? =

 d) Next-Next Hop Tunnel = Support?

 e) Router localized = Tunnel recursion?

 f) Tunnel = Encap Recursion:

 

3) What = pieces of the proposed solutions have been implemented

   and/or deployed?   =

 

 

Presentations (prerecorded, please review prior to = meeting):

- = draft-vandevelde-idr-flowspec-path-redirect

  Gunter Van De Velde

  21 minutes

  = https://ietf.webex.com/ietf/ldr.php?RCID=3De01d62661085f660f470feddd9bf26= 6f

 

presentation at:

https://www.ietf.org/proceedings/interim/2016/05/16/idr= /slides/slides-interim-2016-idr-5-0.pdf

 

 

draft-li-idr-flowspec-redirect-generalized-sid

Eric Wu

20 minutes

 

Streaming = recording link:

https://ietf.webex.com/ietf/ldr.php?RCID=3Dc8615aa84580= 1a1e4b79cb1708a04484

Download = recording link:

https://ietf.webex.com/ietf/lsr.php?RCID=3D4bd504329727d2a811= c9cb0c9bc713d8

 

presentation = at:

https://www.ietf.org/proceedings/interim/2= 016/05/16/idr/slides/slides-interim-2016-idr-5-1.pdf

 

------=_NextPart_000_008B_01D1ACE3.3F2A3760-- From nobody Fri May 13 07:56:09 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4763012D543 for ; Fri, 13 May 2016 07:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMDVB-wnfOZu for ; Fri, 13 May 2016 07:56:04 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68066127058 for ; Fri, 13 May 2016 07:56:04 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 67FD546FEEC2 for ; Fri, 13 May 2016 14:55:59 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4DEu2bl002737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 13 May 2016 14:56:02 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u4DEtvh9007741 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 13 May 2016 16:56:00 +0200 Received: from FR711WXCHMBA06.zeu.alcatel-lucent.com ([169.254.2.27]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Fri, 13 May 2016 16:55:58 +0200 From: "Van De Velde, Gunter (Nokia - BE)" To: "idr@ietf.org" Thread-Topic: [Idr] IDR interim on May 16th - webex, questions for meeting, and recordings. Thread-Index: AdGtA5N1fQH6ZeaQT8WhQMAKvH+1FwAI/l2A Date: Fri, 13 May 2016 14:55:57 +0000 Message-ID: <9F087909-60F3-4F5C-8427-C0BD2A4ED9FF@alcatel-lucent.com> References: <008a01d1ad04$c63a77d0$52af6770$@ndzh.com> In-Reply-To: <008a01d1ad04$c63a77d0$52af6770$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_9F08790960F34F5C8427C0BD2A4ED9FFalcatellucentcom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] IDR interim on May 16th - webex, questions for meeting, and recordings. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 14:56:07 -0000 --_000_9F08790960F34F5C8427C0BD2A4ED9FFalcatellucentcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UHJlLWxpbWluYXIgY29tbWVudHPigKYuLg0KDQpCZWZvcmUgZW5nYWdpbmcgd2l0aCBteSBmZWVk YmFjayBhbmQgYWRkcmVzc2luZyB0aGUgZGlzY3Vzc2lvbiBzbGlkZXMsIGkgd291bGQgbGlrZSB0 byB0aGFuayBib3RoIFN1ZSBhbmQgSm9obiBmb3IgZ29pbmcgdGhyb3VnaCB0aGUgZWZmb3J0IGFu ZCB0aW1lIHRvIHRyeSB0byBtYWtlIHRoZSByZWNvcmRpbmdzIGFzIGdvb2QgYXMgcG9zc2libGUg YW5kIGludmVzdGluZyBub24tdHJpdmlhbCBhbW91bnRzIG9mIHRpbWUgdG8gZ2V0IHRoZSBqb2Ig ZG9uZS4NCg0KSSB3b3VsZCBhbHNvIGxpa2UgdG8gdGhhbmtzIEVyaWMgV3UgdG8gZ28gdGhyb3Vn aCB0aGUgZXhlcmNpc2Ugb2YgcmVjb3JkaW5nIGhpcyBwcmVzZW50YXRpb24gb2YgdGhlIHNsaWRl cy4gSSB3ZW50IHRocm91Z2ggdGhlIHNhbWUgZXhlcmNpc2UgYW5kIGV2ZW4gdGhvdWdoIHRoZXJl IHdlcmUgbGVzcyBvcGVyYXRpb25hbCBpc3N1ZXMgdG8gZGVhbCB3aXRoIGR1cmluZyBteSByZWNv cmRpbmcsIGl0IGlzIGEgbm9uLXRyaXZpYWwgdGFzayB0byBzcGVhayB0byBhIHNjcmVlbiBhbmQg bm90IHRvIGFuIGF1ZGllbmNlLg0KDQoNCkNvbW1lbnRzOiBXb3JraW5nIHNsaWRlcyBkaXNjdXNz aW9uIG9mIHRoZSAxNiBNYXkgMjAxNiBJbnRlcmltIElEUiBtZWV0aW5nOg0KLS0tLS0tLS0tLS0t LQ0KDQoNClRpbWVsaW5lIGluZm8NCj09PT09PT09PT0NCg0KZHJhZnQtdmFuZGV2ZWxkZS1pZHIt Zmxvd3NwZWMtcGF0aC1yZWRpcmVjdC0wMCBjcmVhdGVkIG9uIDE0IFNlcHRlbWJlciAyMDE1DQpk cmFmdC12YW5kZXZlbGRlLWlkci1mbG93c3BlYy1wYXRoLXJlZGlyZWN0LTAxIGNyZWF0ZWQgb24g MTIgSmFudWFyeSAyMDE2DQpkcmFmdC12YW5kZXZlbGRlLWlkci1mbG93c3BlYy1wYXRoLXJlZGly ZWN0LTAyIGNyZWF0ZWQgb24gMTcgTWFyY2ggMjAxNg0KDQpkcmFmdC1saS1pZHItZmxvd3NwZWMt cmVkaXJlY3QtZ2VuZXJhbGl6ZWQtc2lkLTAwIGNyZWF0ZWQgb24gMjEgTWFyY2ggMjAxNg0KDQoN CkdlbmVyYWwgc2xpZGUgb2JzZXJ2YXRpb25zIGFib3V0IGRyYWZ0LWxpLWdlbmVyYWxpc2VkLXNp ZC0wMCAocmVmLiBkaXNjdXNzaW9uIHNsaWRlIGZvciAxNiBNYXkgMjAxNikNCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KRHJhZnQt bGkgZG9jdW1lbnRzIGEgZmxvd3NwZWMgYWN0aW9uIHVzaW5nIGEgbmV3IGNvbW11bml0eSAoZ2Vu ZXJhbGl6ZWQtU0lEKS4gVGhlIGV4dGVuZGVkIGNvbW11bml0eSBwcm92aWRlcyBhIGZsb3dzcGVj IGNsaWVudCBpbmZvcm1hdGlvbiB0byBtYWtlIGEgbG9jYWwgZm9yd2FyZGluZyBkZWNpc2lvbiBi eSBtZWFucyBvZiBhIGxvY2FsIG1hcHBpbmcgdGFibGUuIFRoZSB0d28gbWFpbiBjb21wb25lbnRz IHVzZWQgYnkgdGhlIGZsb3dzcGVjIGNsaWVudCBpczogKDEpIGFuIGlkZW50aWZpZXIgYW5kICgy KSBzZW1hbnRpY3MuDQoNCkRyYWZ0LXZhbmRldmVsZGUgZG9jdW1lbnRzIGEgZmxvd3NwZWMgYWN0 aW9uIHVzaW5nIGEgbmV3IGNvbW11bml0eSAoSW5kaXJlY3Rpb24tSUQpLiBUaGUgZXh0ZW5kZWQg Y29tbXVuaXR5IHByb3ZpZGVzIGEgZmxvd3NwZWMgY2xpZW50IGluZm9ybWF0aW9uIHRvIG1ha2Ug YSBsb2NhbCBmb3J3YXJkaW5nIGRlY2lzaW9uIGJ5IG1lYW5zIG9mIGEgbG9jYWwgbWFwcGluZyB0 YWJsZS4gVGhlIHR3byBtYWluIGNvbXBvbmVudHMgdXNlZCBieSB0aGUgZmxvd3NwZWMgY2xpZW50 IGlzOiAoMSkgYW4gaWRlbnRpZmllciBhbmQgKDIpIG9wdGlvbmFsbHkgc2VtYW50aWNzIChUYWJs ZSBzZW1hbnRpY3MgKyBUdW5uZWwtSUQpLg0KDQpkcmFmdC12YW5kZXZlbGRlLWlkci1mbG93c3Bl Yy1wYXRoLXJlZGlyZWN0LTAyIHdhcyBjcmVhdGVkIOKAnGJlZm9yZSIgZHJhZnQtbGktaWRyLWZs b3dzcGVjLXJlZGlyZWN0LWdlbmVyYWxpemVkLXNpZC0wMCBhbmQgYWNoaWV2ZXMgdGhlIHNhbWUg ZnVuY3Rpb25hbGl0eSBhbmQgbW9yZS4gKEZvciBleGFtcGxlIGRyYWZ0LXZhbmRldmVsZGUgaGFz IHRoZSBwb3RlbnRpYWwgdG8gc2lnbmFsIDgxOTIgdHlwZXMgb2Ygc2VtYW50aWMgbWFwcGluZyB0 YWJsZXMgd2hpbGUgZHJhZnQtbGkgaGFzIDI1NSwgYW5vdGhlciBleGFtcGxlIGlzIHRoZSBUSUQg ZmllbGQgd2hpY2ggYWxsb3dzIGR5bmFtaWMgTmV4dC1OZXh0LUhvcCBjb25zdHJ1Y3RzIHVzZSBm b3IgRVBFIEREb1MgcmVkaXJlY3Rpb24pLg0KDQpEdXJpbmcgV0cgYWRkb3B0aW9uLWNhbGwgMy8y NSB0byA0LzggdGhlIGZvbGxvd2luZyBoYXMgYmVlbiBtZW50aW9uZWQgYnkgSWduYXM6IGh0dHA6 Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9pZHIvY3VycmVudC9tc2cxNTUxMi5odG1s DQoNCiJEcmFmdC12YW5kZXZlbGRlIGNhbiBhY2hpZXZlIGFsbCB3aGF0IGRyYWZ0LWhhbyBhbmQg ZHJhZnQtbGkgY2FuLCBhbmQgaW4gYSBtb3JlIGZsZXhpYmxlIHdheS4gSGF2aW5nIHRoZSBhYmls aXR5IHRvIGRlY291cGxlIHJlZGlyZWN0aW9uIHR1bm5lbCB0eXBlIGZyb20gcmVkaXJlY3Rpb24g YWN0aW9uIGlzIGJvdGggcHJhY3RpY2FsIGFuZCBleHRlbnNpYmxlIC0gdGhlIGFjdHVhbCB0dW5u ZWwgdG8gYmUgdXNlZCBpcyBhIGxvY2FsIG9wZXJhdGlvbmFsIGRlY2lzaW9uIGZvciBlYWNoIG5l dHdvcmsgZWxlbWVudCwgaXQgaXMgbm90IG5lY2Vzc2FyeSBzaWduYWxsZWQgYXQgdGhlIHNhbWUg dGltZSBhbmQgYnkgdGhlIHNhbWUgbWVjaGFuaXNtLiBEZWNvdXBsaW5nIHNpZ25hbGxpbmcgYW5k IHJlZGlyZWN0IHBhcnRzIGFsaWducyB3ZWxsIHRvIG9wZXJhdGlvbmFsIHByYWN0aWNlcyBvZiB1 c2luZyBzcGVjaWZpYyB0b29scyBmb3Igc3BlY2lmaWMgdGFza3MuIEp1c3QgdGhhdCBCR1AgY291 bGQgZG8gdGhhdCBkb2VzIG5vdCBuZWNlc2FzcnkgbWVhbiB0aGF0IGl0IHNob3VsZCBiZSB1c2Vk IGFzIGEgYmVzdCBmaXQuIEZyb20gb3BlcmF0aW9uYWwgcGVyc3BlY3RpdmUgdGhlcmUgaXMgbm8g bmVlZCB0byBoYXZlIG11bHRpcGxlIHNvbHV0aW9ucyB0aGF0IHRyeSB0byBhZGRyZXNzIHRoZSBu YXJyb3cgcHJvYmxlbSBzcGFjZSBpbiBzaW1pbGFyIHlldCBpbmNvbXBhdGlibGUgd2F5cy4gVGhl cmUgc2hvdWxkIGJlIG9uZSBkb2N1bWVudCBmb3IgcmVkaXJlY3QsIGFuZCBkcmFmdC12YW5kZXZl bGRlIGlzIGEgZ29vZCBzdGFydGluZyBiYXNlIGZvciB0aGF0LiINCg0KDQpEZXRhaWwgdmlldzog c2xpZGUgb2JzZXJ2YXRpb25zIGRyYWZ0LWxpLWdlbmVyYWxpc2VkLXNpZC0wMCBkaXNjdXNzaW9u DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0NCg0KU2xpZGUgMiAob2YgdGhlIGRyYWZ0LWxpIHByZXNlbnRhdGlvbik6IEhpc3RvcnkNCj09 DQoNClRoZSBzbGlkZSBmb3JnZXRzIHRvIG1lbnRpb24gdGhhdCBkcmFmdC12YW5kZXZlbGRlIHdh cyBlbmhhbmNlZCBhbmQgcHJvZ3Jlc3NlZCBiYXNlZCB1cG9uIGNvbnN0cnVjdGl2ZSBXRyBmZWVk YmFjay4gTXVjaCBmZWVkYmFjayBoYXMgYmVlbiBpbnRlZ3JhdGVkIGJldHdlZW4gZHJhZnQtdmFu ZGV2ZWxkZSAtMDAgdG8g4oCTMDIgQkVGT1JFIGRyYWZ04oCTbGkgZXZlbiBleGlzdGVkLiBGb3Ig ZXhhbXBsZToNCiogVXNlLWNhc2Ugc2NlbmFyaW/igJlzIHdlcmUgYWRkZWQNCiogIlBhdGgtaWQi IGNoYW5nZWQgdG8gIkluZGlyZWN0aW9uLWlkIg0KKiBDb25jZXB0IG9mIEluZGlyZWN0aW9uIHRh YmxlcyBoYXMgYmVlbiBhZGRlZCAoaGVuY2UgYWRkaW5nIHRoZSBjYXBhYmlsaXR5IG9mIGNvbnRl eHQvc2VtYW50aWNzIHNpZ25hbGxpbmcgYWxyZWFkeSBzaW5jZSB2ZXJzaW9uIC0wMSkNCiogRmxv d3NwZWMgdmFsaWRhdGlvbiBpbmZvcm1hdGlvbiBpcyBhZGRlZA0KKiBzaWduYWxsaW5nIG9mIGNv bnRleHQvc2VtYW50aWNzIGlzIGFkZGVkIGJ5IGludHJvZHVjaW5nIEJpbmRpbmctU0lEIGNvbnRl eHQgaWRlbnRpZmllciBhcyBhIGZpcnN0IGV4dGVuc2lvbiBvZiBJbmRpcmVjdGlvbi1pZCBleHRl bmRlZCBjb21tdW5pdHkuDQoNCkl0IGlzIGFuIGluY29ycmVjdCBhc3N1bXB0aW9uIG9mIG5vIGNv bnRleHQgYXdhcmVuZXNzIGluIGRyYWZ0LXZhbmRldmVsZGUuIGRyYWZ0LXZhbmRldmVsZGUtaWRy LWZsb3dzcGVjLXBhdGgtcmVkaXJlY3QgYWRkZWQgY29udGV4dCBzdXBwb3J0IGJlZm9yZSBkcmFm dC1saSBleGlzdGVkLCBhbmQgcmFpc2VzIHF1ZXN0aW9ucyBhYm91dCBuZXcgZWxlbWVudHMgZXhw b3NlZCB3aXRoIGRyYWZ0LWxpIGNvbXBhcmVkIHRvIGRyYWZ0LXZhbmRldmVsZGUuDQoNCihmd2l3 IFRoZSBzZW1hbnRpYyBhd2FyZW5lc3Mgb2YgZHJhZnQtdmFuZGV2ZWxkZSBpcyBtZW50aW9uZWQg YW5kIHRoZSB3ZWJleCByZWNvcmRpbmcgb2YgZHJhZnQtbGkgYmV0d2VlbiByZWNvcmRpbmcgdGlt ZS1zdGFtcHMgMTFtMzBzIHRvIDEzbTMwcykNCg0KDQpTbGlkZSAzIChvZiB0aGUgZHJhZnQtbGkg cHJlc2VudGF0aW9uKQ0KPT0NCg0KTm8gbmV3IGNhcGFiaWxpdHkgaXMgZXhwbGFpbmVkIG9uIHRo aXMgc2xpZGUgaW4gY29tcGFyaXNvbiB3aXRoIHRoZSBkcmFmdC12YW5kZXZlbGRlLg0KSW4gZHJh ZnQtdmFuZGV2ZWxkZSB0aGUgaW5mb3JtYXRpb24gZm91bmQgaW4gdGhlIGluZGlyZWN0aW9uLWlk IGlzIHVzZWQgb24gYSBmbG93c3BlYyBjbGllbnQgaW4gYSBsb2NhbCBtYXBwaW5nLXRhYmxlIChp bmRpcmVjdGlvbi1pZCB0YWJsZSkgdG8gZmluZCBsb2NhbCBmb3J3YXJkaW5nIGluZm9ybWF0aW9u LiBUaGUgbmV3IGZsb3dzcGVjIGV4dGVuZGVkIGNvbW11bml0eSBhcyBkb2N1bWVudGVkIGJ5IGRy YWZ0LXZhbmRldmVsZGUgY2FuIHByb3ZpZGUgYWxyZWFkeSBhIGZsb3dzcGVjIGNsaWVudCB0aGUg cmVxdWlyZWQgc2VtYW50aWMvY29udGV4dCBpbmZvcm1hdGlvbiAoZXhhbXBsZSBpcyB0aGUg4oCY QuKAmSBiaXQpLg0KDQoNClNsaWRlIDQgKG9mIHRoZSBkcmFmdC1saSBwcmVzZW50YXRpb24pDQo9 PQ0KDQpUaGUgZ29hbCBvZiBkcmFmdC1saSBpcyB0byBkZWZpbmUgYSDigJxzZW1hbnRpY3MgZGVw ZW5kZW504oCdIGFjdGlvbi4NCkhvd2V2ZXIsIGRyYWZ0LXZhbmRldmVsZGUgYWxyZWFkeSBhbGxv d3MgdGhhdCBmdW5jdGlvbmFsaXR5IGJlZm9yZSBkcmFmdC1saSBleGlzdGVkDQoNCg0KU2xpZGUg NSAob2YgdGhlIGRyYWZ0LWxpIHByZXNlbnRhdGlvbikNCj09DQoNCkRyYWZ0LXZhbmRldmVsZGUg aGFzIGluZGVlZCB0aGUgcG90ZW50aWFsIHRvIGJlIHVzZWQgaW4gc3VjaCBhIG1hbm5lci4gVGhl IGludGVuZCBvZiB0aGlzIHNsaWRlIGF0IHRoZSB0aW1lIG9mIHVzYWdlIHdhcyB0byBzaG93IGFu IGV4dHJlbWUgZXhhbXBsZSBvZiB0aGUgZmxleGlibGl0eSB0aGUgdGVjaG5vbG9neSBvZmZlcnMu IFdoZW4gZm9yIGV4YW1wbGUgdXNpbmcgcmVkaXJlY3Rpb24gdG8gYmluZGluZy1TSUQgKGFzIGRv Y3VtZW50ZWQgaW4gbGF0ZXN0IGRyYWZ0LXZhbmRldmVsZGUpIHRoZW4gdGhlIGxvY2FsIG1hcHBp bmcgdGFibGUgY2FuIGJlIGJhc2VkIGFyb3VuZCB0aGUgc2lnbmFsbGVkIHNlbWFudGljcy4NCg0K DQpTbGlkZSA2IChvZiB0aGUgZHJhZnQtbGkgcHJlc2VudGF0aW9uKQ0KPT0NCg0KRHJhZnQtdmFu ZGV2ZWxkZSBoYXMgMTMgYml0cyBhdmFpbGFibGUgZm9yIHR5cGVzLCBoZW5jZSB0aGUgcG90ZW50 aWFsIHRvIHN1cHBvcnQvc2lnbmFsIDJeMTMgKD04MTkyKSB0eXBlcyB3aGVuIHVzaW5nIHRoZSBm aWVsZCBhcyBzY2FsYXIgdmFsdWUgKHdoZW4gY29tcGFyaW5nIHdpdGggYSBwb3RlbnRpYWwgZm9y IDI1NSB0eXBlcyB1c2luZyBkcmFmdC1saSkNCg0KVGhlIGNsYWltIG1hZGUgb24gc2xpZGU2IHRo YXQgZHJhZnQtdmFuZGV2ZWxkZSBhbGxvd3Mgb25seSAxMyB0eXBlIG9mIHNlbWFudGljIGluZm9y bWF0aW9uIGlzIHdyb25nIGFzc3VtcHRpb24uDQoNCkF0IHRoZSB0aW1lIG9mIHdyaXRpbmcsIGl0 IHdhcyBmb3VuZCB1c2VmdWwgdG8gc2lnbmFsIGJpbmRpbmcgU0lEIHVzZWZ1bCBzZW1hbnRpYyDi gKYgV2UgZGVjaWRlZCB0byBsZWF2ZSB0aGUgcmVtYWluaW5nIGJpdHMgcmVzZXJ2ZWQvb3BlbiBm b3IgZGlzY3Vzc2lvbiBvbiBob3cgdG8gYmVzdCB1c2UgdGhlIGZpZWxkIGluc3RlYWQuDQpNYXli ZSB0aGUgV0cgZmVlbHMgaXQgaXMgYmVzdCB0byB1c2Ugb25seSBhIGZldyBiaXRzIGZvciBzZW1h bnRpY3MgYW5kIGtlZXAgdGhlIHJlbWFpbmRlciByZXNlcnZlZCBmb3IgZnV0dXJlIHVzZS4NCg0K S2luZCBSZWdhcmRzLA0KRy8NCg0KDQoNCkZyb206IElkciA8aWRyLWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIFN1c2FuIEhhcmVzIDxz aGFyZXNAbmR6aC5jb208bWFpbHRvOnNoYXJlc0BuZHpoLmNvbT4+DQpEYXRlOiBGcmlkYXkgMTMg TWF5IDIwMTYgYXQgMTI6NDYNClRvOiAiaWRyQGlldGYub3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+ IiA8aWRyQGlldGYub3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW0lkcl0gSURS IGludGVyaW0gb24gTWF5IDE2dGggLSB3ZWJleCwgcXVlc3Rpb25zIGZvciBtZWV0aW5nLCBhbmQg cmVjb3JkaW5ncy4NCg0KVGhlIHRpbWUgb2YgdGhlIGludGVyaW0gaXMgMjI6MDAtMjM6MDAgRURU IG9uIE1heSAxNnRoLg0KDQpUaGUgaW50ZXJpbSB3aWxsIGRpc2N1c3MgdGhlIGZvbGxvd2luZyB0 d28gZHJhZnRzIGluIG9yZGVyIHRvIGNyZWF0ZSBhIFdHIHNvbHV0aW9uOg0KDQoNCsK3ICAgICAg ICAgZHJhZnQtdmFuZGV2ZWxkZS1pZHItZmxvd3NwZWMtcGF0aC1yZWRpcmVjdCwgYW5kDQoNCsK3 ICAgICAgICAgZHJhZnQtbGktaWRyLWZsb3dzcGVjLXJlZGlyZWN0LWdlbmVyYWxpemVkLXNpZA0K DQpTb21lIG9mIHRoZSBRdWVzdGlvbnMgdGhhdCB3aWxsIGJlIGRpc2N1c3MgYXJlIGluY2x1ZGVk IGJlbG93LiAgUGxlYXNlIHJldmlldyB0aGUgcHJlLXJlY29yZGluZyBwcmVzZW50YXRpb25zIHBy aW9yIHRvIHRoZSBtZWV0aW5nLiAgIFRoZSBDaGFpcnMgZW5jb3VyYWdlIGRpc2N1c3Npb24gb2Yg dGhlc2UgcXVlc3Rpb25zIG9uIHRoZSBsaXN0IGJlZm9yZSwgZHVyaW5nLCBhbmQgYWZ0ZXIgdGhl IG1lZXRpbmcuDQoNClN1ZSBhbmQgSm9obg0KDQo9PT09PT09PT09PT09PT09PT09PT09PT0NCg0K QWdlbmRhIGZvciBJRFIgVmlydHVhbCBJbnRlcmltIE1lZXRpbmcNCg0KTWF5IDE2LCAyMDE2DQoy MjowMCAtIDIzOjAwIEVEVA0KDQpXZWJFeDogaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2ou cGhwP01USUQ9bTliZTQ4MWQxOTk4OGRkMWI1NDViZTY3NTlhZWUyNjdiDQpNZWV0aW5nIG51bWJl cjogICAgICAgICAgICA2NDkgMjM1IDQxMQ0KTWVldGluZyBwYXNzd29yZDogICAgICAgICBKZzY2 ZDJwbQ0KSm9pbiBieSBwaG9uZQ0KMS04NzctNjY4LTQ0OTMgQ2FsbC1pbiB0b2xsIGZyZWUgbnVt YmVyIChVUy9DYW5hZGEpDQoxLTY1MC00NzktMzIwOCBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9D YW5hZGEpDQpBY2Nlc3MgY29kZTogNjQ5IDIzNSA0MTENCg0KUXVlc3Rpb25zIGZvciBtZWV0aW5n Og0KDQpTdWJtaXR0ZWQgYnkgKEVyaWMgV3UpDQoxLiBSZWRpcmVjdC10by1TcGVjaWZpYy1UdW5u ZWwgd2l0aCBCR1AgUGF0aCBBdHRyaWJ1dGUgW1RVTk5FTEVOQ0FQU11bTVBQXSBhbmQNCiAgUmVk aXJlY3QtdG8tSUlEL0dTSUQsIFJlcXVpcmVkIGJ5IGRpZmZlcmVudCB1c2UgY2FzZXMsIGNhbiB3 ZSBoYXZlIHR3byBkb2NzIGluIElEUiBJbiBwYXJhbGxlbD8NCiAgW0NvbXBhcmlzb24gdG8gUmVk aXJlY3QtdG8tSUlEL0dTSUQgLCBkcmFmdC1oYW8gd2lsbCBoYXZlIG1vcmUgbGl0dGxlIG1vZGlm aWNhdGlvbg0KICB0byBleGlzdGluZyBtZWNoYW5pc21zLCBObyBuZWVkIHRvIGRvIE1hcHBpbmcg L1JlY3Vyc2l2ZSBMb29rdXAuXQ0KDQoyLiAgRm9yIElJRC9HU0lELCBvbmUgbWFwcGluZyB0YWJs ZSBmb3INCiAgYWxsIGtpbmRzIG9mIHNlZ21lbnRzL2ZvcndhcmRpbmctZW50aXRpZXMgdnMuIG9u ZSBtYXBwaW5nIHRhYmxlDQogIHBlciBzZWdtZW50cy9mb3J3YXJkaW5nLWVudGl0aWVzIHR5cGUs IHNob3VsZCB3ZSBzdXBwb3J0IGJvdGg/DQoNCkNoYWlyIFF1ZXN0aW9uczoNCg0KMSkgRG9lcyB0 aGUgV0cgZmVlbCB3ZSBuZWVkIHRoZSBmb2xsb3dpbmcgZm9yIFJGQzU1NzViaXMgKEREb1MpDQog IGEpIFJlZGlyZWN0aW9uIHRvIFZSRiwNCiAgYikgUmVkaXJlY3Rpb24gdG8gSW5kaXJlY3Rpb24g dG8gSVAsIGFuZA0KICBjKSBSZWRpcmVjdGlvbiB0byBTZXJ2aWNlIChuZXcpPw0KDQoyKSBJZiB0 aGUgV0cgZGVzaXJlcyByZWRpcmVjdGlvbiB0byBTZXJ2aWNlIHJvdXRpbmcsIGRvZXMgdGhlIFdH IGRlc2lyZQ0KYSkgTmV4dC1Ib3AgdHVubmVsIHN1cHBvcnQ/IC0NCmIpIE5leHQtSG9wIFRFIFR1 bm5lbCBzdXBwb3J0Pw0KIGMpIE5lc3RlZCBUdW5uZWwgc3VwcG9ydD8NCiBkKSBOZXh0LU5leHQg SG9wIFR1bm5lbCBTdXBwb3J0Pw0KIGUpIFJvdXRlciBsb2NhbGl6ZWQgVHVubmVsIHJlY3Vyc2lv bj8NCiBmKSBUdW5uZWwgRW5jYXAgUmVjdXJzaW9uOg0KDQozKSBXaGF0IHBpZWNlcyBvZiB0aGUg cHJvcG9zZWQgc29sdXRpb25zIGhhdmUgYmVlbiBpbXBsZW1lbnRlZA0KICAgYW5kL29yIGRlcGxv eWVkPw0KDQoNClByZXNlbnRhdGlvbnMgKHByZXJlY29yZGVkLCBwbGVhc2UgcmV2aWV3IHByaW9y IHRvIG1lZXRpbmcpOg0KLSBkcmFmdC12YW5kZXZlbGRlLWlkci1mbG93c3BlYy1wYXRoLXJlZGly ZWN0DQogIEd1bnRlciBWYW4gRGUgVmVsZGUNCiAgMjEgbWludXRlcw0KICBodHRwczovL2lldGYu d2ViZXguY29tL2lldGYvbGRyLnBocD9SQ0lEPWUwMWQ2MjY2MTA4NWY2NjBmNDcwZmVkZGQ5YmYy NjZmDQoNCnByZXNlbnRhdGlvbiBhdDoNCmh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdz L2ludGVyaW0vMjAxNi8wNS8xNi9pZHIvc2xpZGVzL3NsaWRlcy1pbnRlcmltLTIwMTYtaWRyLTUt MC5wZGYNCg0KDQpkcmFmdC1saS1pZHItZmxvd3NwZWMtcmVkaXJlY3QtZ2VuZXJhbGl6ZWQtc2lk DQpFcmljIFd1DQoyMCBtaW51dGVzDQoNClN0cmVhbWluZyByZWNvcmRpbmcgbGluazoNCmh0dHBz Oi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9sZHIucGhwP1JDSUQ9Yzg2MTVhYTg0NTgwMWExZTRiNzlj YjE3MDhhMDQ0ODQNCkRvd25sb2FkIHJlY29yZGluZyBsaW5rOg0KaHR0cHM6Ly9pZXRmLndlYmV4 LmNvbS9pZXRmL2xzci5waHA/UkNJRD00YmQ1MDQzMjk3MjdkMmE4MTFjOWNiMGM5YmM3MTNkOA0K DQpwcmVzZW50YXRpb24gYXQ6DQpodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy9pbnRl cmltLzIwMTYvMDUvMTYvaWRyL3NsaWRlcy9zbGlkZXMtaW50ZXJpbS0yMDE2LWlkci01LTEucGRm DQoNCg== --_000_9F08790960F34F5C8427C0BD2A4ED9FFalcatellucentcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjx0aXRsZT48L3RpdGxlPg0KPC9oZWFkPg0KPGJv ZHkgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNl OyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyBjb2xvcjogcmdiKDAsIDAs IDApOyI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDE0cHg7 IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUnOyI+UHJlLWxpbWluYXIgY29tbWVudHPigKYu LjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogJ0hlbHZl dGljYSBOZXVlJzsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyBm b250LWZhbWlseTogJ0hlbHZldGljYSBOZXVlJzsiPkJlZm9yZSBlbmdhZ2luZyB3aXRoIG15IGZl ZWRiYWNrIGFuZCBhZGRyZXNzaW5nIHRoZSBkaXNjdXNzaW9uIHNsaWRlcywgaSB3b3VsZCBsaWtl IHRvIHRoYW5rIGJvdGggU3VlIGFuZCBKb2huIGZvciBnb2luZyB0aHJvdWdoIHRoZSBlZmZvcnQg YW5kIHRpbWUgdG8gdHJ5IHRvIG1ha2UgdGhlIHJlY29yZGluZ3MgYXMgZ29vZCBhcyBwb3NzaWJs ZQ0KIGFuZCBpbnZlc3Rpbmcgbm9uLXRyaXZpYWwgYW1vdW50cyBvZiB0aW1lIHRvIGdldCB0aGUg am9iIGRvbmUuPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5 OiAnSGVsdmV0aWNhIE5ldWUnOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6 IDE0cHg7IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUnOyI+SSB3b3VsZCBhbHNvIGxpa2Ug dG8gdGhhbmtzIEVyaWMgV3UgdG8gZ28gdGhyb3VnaCB0aGUgZXhlcmNpc2Ugb2YgcmVjb3JkaW5n IGhpcyBwcmVzZW50YXRpb24gb2YgdGhlIHNsaWRlcy4gSSB3ZW50IHRocm91Z2ggdGhlIHNhbWUg ZXhlcmNpc2UgYW5kIGV2ZW4gdGhvdWdoIHRoZXJlIHdlcmUgbGVzcyBvcGVyYXRpb25hbCBpc3N1 ZXMgdG8gZGVhbA0KIHdpdGggZHVyaW5nIG15IHJlY29yZGluZywgaXQgaXMgYSBub24tdHJpdmlh bCB0YXNrIHRvIHNwZWFrIHRvIGEgc2NyZWVuIGFuZCBub3QgdG8gYW4gYXVkaWVuY2UuJm5ic3A7 PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiAnSGVsdmV0 aWNhIE5ldWUnOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDE0cHg7IGZv bnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUnOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJm b250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUnOyI+Q29tbWVudHM6 IFdvcmtpbmcgc2xpZGVzIGRpc2N1c3Npb24gb2YgdGhlIDE2IE1heSAyMDE2IEludGVyaW0gSURS IG1lZXRpbmc6PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5 OiAnSGVsdmV0aWNhIE5ldWUnOyI+LS0tLS0tLS0tLS0tLTwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9u dC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogJ0hlbHZldGljYSBOZXVlJzsiPjxicj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5 OiAnSGVsdmV0aWNhIE5ldWUnOyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpOyI+ PGJyPg0KPC9zcGFuPjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj5UaW1lbGluZSBp bmZvPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj49PT09PT09PT09PC9m b250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj48YnI+DQo8L2ZvbnQ+PC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPmRyYWZ0LXZhbmRldmVs ZGUtaWRyLWZsb3dzcGVjLXBhdGgtcmVkaXJlY3QtMDAgY3JlYXRlZCBvbiAxNCBTZXB0ZW1iZXIg MjAxNTwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+ZHJhZnQtdmFuZGV2 ZWxkZS1pZHItZmxvd3NwZWMtcGF0aC1yZWRpcmVjdC0wMSBjcmVhdGVkIG9uIDEyIEphbnVhcnkg MjAxNjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+ZHJhZnQtdmFuZGV2 ZWxkZS1pZHItZmxvd3NwZWMtcGF0aC1yZWRpcmVjdC0wMiBjcmVhdGVkIG9uIDE3IE1hcmNoIDIw MTY8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPjxicj4NCjwvZm9udD48 L2Rpdj4NCjxkaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPmRyYWZ0LWxpLWlkci1mbG93 c3BlYy1yZWRpcmVjdC1nZW5lcmFsaXplZC1zaWQtMDAgY3JlYXRlZCBvbiAyMSBNYXJjaCAyMDE2 PC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxmb250IGZh Y2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNl PSJDYWxpYnJpIj48YnI+DQo8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmki PkdlbmVyYWwgc2xpZGUgb2JzZXJ2YXRpb25zIGFib3V0IGRyYWZ0LWxpLWdlbmVyYWxpc2VkLXNp ZC0wMCAocmVmLiBkaXNjdXNzaW9uIHNsaWRlIGZvciAxNiBNYXkgMjAxNik8L2ZvbnQ+PC9kaXY+ DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZh Y2U9IkNhbGlicmkiPjxicj4NCjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJy aSI+RHJhZnQtbGkgZG9jdW1lbnRzIGEgZmxvd3NwZWMgYWN0aW9uIHVzaW5nIGEgbmV3IGNvbW11 bml0eSAoZ2VuZXJhbGl6ZWQtU0lEKS4gVGhlIGV4dGVuZGVkIGNvbW11bml0eSBwcm92aWRlcyBh IGZsb3dzcGVjIGNsaWVudCBpbmZvcm1hdGlvbiB0byBtYWtlIGEgbG9jYWwgZm9yd2FyZGluZyBk ZWNpc2lvbiBieSBtZWFucyBvZiBhIGxvY2FsIG1hcHBpbmcgdGFibGUuIFRoZSB0d28gbWFpbiBj b21wb25lbnRzDQogdXNlZCBieSB0aGUgZmxvd3NwZWMgY2xpZW50IGlzOiAoMSkgYW4gaWRlbnRp ZmllciBhbmQgKDIpIHNlbWFudGljcy48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pg0KPGRpdj48Zm9udCBm YWNlPSJDYWxpYnJpIj48YnI+DQo8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+PGZv bnQgZmFjZT0iQ2FsaWJyaSI+RHJhZnQtdmFuZGV2ZWxkZSBkb2N1bWVudHMgYSBmbG93c3BlYyBh Y3Rpb24gdXNpbmcgYSBuZXcgY29tbXVuaXR5IChJbmRpcmVjdGlvbi1JRCkuIFRoZSBleHRlbmRl ZCBjb21tdW5pdHkgcHJvdmlkZXMgYSBmbG93c3BlYyBjbGllbnQgaW5mb3JtYXRpb24gdG8gbWFr ZSBhIGxvY2FsIGZvcndhcmRpbmcgZGVjaXNpb24gYnkgbWVhbnMgb2YgYSBsb2NhbCBtYXBwaW5n IHRhYmxlLiBUaGUgdHdvIG1haW4NCiBjb21wb25lbnRzIHVzZWQgYnkgdGhlIGZsb3dzcGVjIGNs aWVudCBpczogKDEpIGFuIGlkZW50aWZpZXIgYW5kICgyKSBvcHRpb25hbGx5IHNlbWFudGljcyAo VGFibGUgc2VtYW50aWNzICYjNDM7IFR1bm5lbC1JRCkuPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9u dCBmYWNlPSJDYWxpYnJpIj48YnI+DQo8L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 PjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmki PmRyYWZ0LXZhbmRldmVsZGUtaWRyLWZsb3dzcGVjLXBhdGgtcmVkaXJlY3QtMDImbmJzcDt3YXMg Y3JlYXRlZCZuYnNwO+KAnGJlZm9yZSZxdW90OyZuYnNwO2RyYWZ0LWxpLWlkci1mbG93c3BlYy1y ZWRpcmVjdC1nZW5lcmFsaXplZC1zaWQtMDAgYW5kIGFjaGlldmVzIHRoZSBzYW1lIGZ1bmN0aW9u YWxpdHkgYW5kIG1vcmUuIChGb3IgZXhhbXBsZSBkcmFmdC12YW5kZXZlbGRlIGhhcyB0aGUgcG90 ZW50aWFsIHRvIHNpZ25hbCA4MTkyIHR5cGVzDQogb2Ygc2VtYW50aWMgbWFwcGluZyB0YWJsZXMg d2hpbGUgZHJhZnQtbGkgaGFzIDI1NSwgYW5vdGhlciBleGFtcGxlIGlzIHRoZSBUSUQgZmllbGQg d2hpY2ggYWxsb3dzIGR5bmFtaWMgTmV4dC1OZXh0LUhvcCBjb25zdHJ1Y3RzIHVzZSBmb3IgRVBF IEREb1MgcmVkaXJlY3Rpb24pLjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJy aSI+PGJyPg0KPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj5EdXJpbmcg V0cgYWRkb3B0aW9uLWNhbGwgMy8yNSB0byA0LzggdGhlIGZvbGxvd2luZyBoYXMgYmVlbiBtZW50 aW9uZWQgYnkgSWduYXM6DQo8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2 ZS93ZWIvaWRyL2N1cnJlbnQvbXNnMTU1MTIuaHRtbCI+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWls LWFyY2hpdmUvd2ViL2lkci9jdXJyZW50L21zZzE1NTEyLmh0bWw8L2E+PC9mb250PjwvZGl2Pg0K PGRpdiBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogJ0hlbHZldGljYSBOZXVl JzsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaTsiPjxicj4NCjwvc3Bhbj48L2Rp dj4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTRweDsgZm9udC1mYW1pbHk6ICdIZWx2ZXRpY2Eg TmV1ZSc7IG1hcmdpbi1sZWZ0OiA0MHB4OyI+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+JnF1b3Q7PC9m b250PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogbW9ub3NwYWNlOyBmb250LXNpemU6IG1lZGl1 bTsiPkRyYWZ0LXZhbmRldmVsZGUgY2FuIGFjaGlldmUgYWxsIHdoYXQgZHJhZnQtaGFvIGFuZCBk cmFmdC1saSBjYW4sIGFuZCBpbiBhIG1vcmUgZmxleGlibGUgd2F5Lg0KIEhhdmluZyB0aGUgYWJp bGl0eSB0byBkZWNvdXBsZSByZWRpcmVjdGlvbjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6IG1vbm9zcGFjZTsgZm9udC1zaXplOiBtZWRpdW07IGJhY2tncm91bmQtY29sb3I6IHJnYigy NTUsIDI1NSwgMjU1KTsiPiB0dW5uZWwgdHlwZSBmcm9tIHJlZGlyZWN0aW9uIGFjdGlvbiBpcyBi b3RoIHByYWN0aWNhbCBhbmQgZXh0ZW5zaWJsZSAtIHRoZSBhY3R1YWwgdHVubmVsIHRvIGJlIHVz ZWQgaXMgYSBsb2NhbA0KIG9wZXJhdGlvbmFsIGRlY2lzaW9uIGZvciBlYWNoIG5ldHdvcmsgZWxl bWVudCwgaXQgaXMgbm90IG5lY2Vzc2FyeSBzaWduYWxsZWQgYXQgdGhlIHNhbWUgdGltZSBhbmQg YnkgdGhlIHNhbWUgbWVjaGFuaXNtLiBEZWNvdXBsaW5nIHNpZ25hbGxpbmcgYW5kIHJlZGlyZWN0 IHBhcnRzIGFsaWducyB3ZWxsIHRvIG9wZXJhdGlvbmFsIHByYWN0aWNlcyBvZiB1c2luZyBzcGVj aWZpYyB0b29scyBmb3Igc3BlY2lmaWMgdGFza3MuIEp1c3QgdGhhdCBCR1ANCiBjb3VsZCBkbyB0 aGF0IGRvZXMgbm90IG5lY2VzYXNyeSBtZWFuIHRoYXQgaXQgc2hvdWxkIGJlIHVzZWQgYXMgYSBi ZXN0IGZpdC4gRnJvbSBvcGVyYXRpb25hbCBwZXJzcGVjdGl2ZSB0aGVyZSBpcyBubyBuZWVkIHRv IGhhdmUgbXVsdGlwbGUgc29sdXRpb25zIHRoYXQgdHJ5IHRvIGFkZHJlc3MgdGhlIG5hcnJvdyBw cm9ibGVtIHNwYWNlIGluIHNpbWlsYXIgeWV0IGluY29tcGF0aWJsZSB3YXlzLiBUaGVyZSBzaG91 bGQgYmUgb25lIGRvY3VtZW50DQogZm9yIHJlZGlyZWN0LCBhbmQgZHJhZnQtdmFuZGV2ZWxkZSBp cyBhIGdvb2Qgc3RhcnRpbmcgYmFzZSBmb3IgdGhhdC4mcXVvdDs8L3NwYW4+PC9kaXY+DQo8ZGl2 IHN0eWxlPSJmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUnOyI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpOyI+PHNwYW4gc3R5bGU9ImJhY2tncm91 bmQtY29sb3I6IHJnYigyNTUsIDI1MywgMjQ1KTsiPjxicj4NCjwvc3Bhbj48L3NwYW4+PC9kaXY+ DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5l dWUnOyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+PGJy Pg0KPC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDE0cHg7Ij4N CjxkaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPkRldGFpbCB2aWV3OiBzbGlkZSBvYnNl cnZhdGlvbnMgZHJhZnQtbGktZ2VuZXJhbGlzZWQtc2lkLTAwIGRpc2N1c3Npb248L2ZvbnQ+PC9k aXY+DQo8ZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj49PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08L2ZvbnQ+PC9kaXY+DQo8ZGl2 Pjxmb250IGZhY2U9IkNhbGlicmkiPjxicj4NCjwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj5T bGlkZSAyIChvZiB0aGUgZHJhZnQtbGkgcHJlc2VudGF0aW9uKTogSGlzdG9yeSZuYnNwOzwvZm9u dD48L2Rpdj4NCjxkaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPj09PC9mb250PjwvZGl2 Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj48YnI+DQo8L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4N CjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+VGhlIHNsaWRlIGZvcmdldHMgdG8gbWVudGlvbiB0 aGF0IGRyYWZ0LXZhbmRldmVsZGUgd2FzIGVuaGFuY2VkIGFuZCBwcm9ncmVzc2VkIGJhc2VkIHVw b24gY29uc3RydWN0aXZlIFdHIGZlZWRiYWNrLiBNdWNoIGZlZWRiYWNrIGhhcyBiZWVuIGludGVn cmF0ZWQgYmV0d2VlbiBkcmFmdC12YW5kZXZlbGRlIC0wMCB0byDigJMwMiBCRUZPUkUgZHJhZnTi gJNsaSBldmVuIGV4aXN0ZWQuIEZvciBleGFtcGxlOjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQg ZmFjZT0iQ2FsaWJyaSI+KiBVc2UtY2FzZSBzY2VuYXJpb+KAmXMgd2VyZSBhZGRlZDwvZm9udD48 L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+KiAmcXVvdDtQYXRoLWlkJnF1b3Q7IGNo YW5nZWQgdG8gJnF1b3Q7SW5kaXJlY3Rpb24taWQmcXVvdDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxm b250IGZhY2U9IkNhbGlicmkiPiogQ29uY2VwdCBvZiBJbmRpcmVjdGlvbiB0YWJsZXMgaGFzIGJl ZW4gYWRkZWQgKGhlbmNlIGFkZGluZyB0aGUgY2FwYWJpbGl0eSBvZiBjb250ZXh0L3NlbWFudGlj cyBzaWduYWxsaW5nIGFscmVhZHkgc2luY2UgdmVyc2lvbiAtMDEpPC9mb250PjwvZGl2Pg0KPGRp dj48Zm9udCBmYWNlPSJDYWxpYnJpIj4qIEZsb3dzcGVjIHZhbGlkYXRpb24gaW5mb3JtYXRpb24g aXMgYWRkZWQ8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPiogc2lnbmFs bGluZyBvZiBjb250ZXh0L3NlbWFudGljcyBpcyBhZGRlZCBieSBpbnRyb2R1Y2luZyBCaW5kaW5n LVNJRCBjb250ZXh0IGlkZW50aWZpZXIgYXMgYSBmaXJzdCBleHRlbnNpb24gb2YgSW5kaXJlY3Rp b24taWQgZXh0ZW5kZWQgY29tbXVuaXR5LjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0i Q2FsaWJyaSI+PGJyPg0KPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj5J dCBpcyBhbiBpbmNvcnJlY3QgYXNzdW1wdGlvbiBvZiBubyBjb250ZXh0IGF3YXJlbmVzcyBpbiBk cmFmdC12YW5kZXZlbGRlLiBkcmFmdC12YW5kZXZlbGRlLWlkci1mbG93c3BlYy1wYXRoLXJlZGly ZWN0IGFkZGVkIGNvbnRleHQgc3VwcG9ydCBiZWZvcmUgZHJhZnQtbGkgZXhpc3RlZCwgYW5kIHJh aXNlcyBxdWVzdGlvbnMgYWJvdXQgbmV3IGVsZW1lbnRzIGV4cG9zZWQgd2l0aCBkcmFmdC1saSBj b21wYXJlZA0KIHRvIGRyYWZ0LXZhbmRldmVsZGUuPC9mb250PjwvZGl2Pg0KPGRpdj4NCjxkaXY+ PGZvbnQgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KPC9mb250PjwvZGl2Pg0KPGRpdj48c3BhbiBzdHls ZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjUzLCAyNDUpOyI+PGZvbnQgZmFjZT0iQ2Fs aWJyaSI+KGZ3aXcgVGhlIHNlbWFudGljIGF3YXJlbmVzcyBvZiBkcmFmdC12YW5kZXZlbGRlIGlz IG1lbnRpb25lZCBhbmQgdGhlIHdlYmV4IHJlY29yZGluZyBvZiBkcmFmdC1saSBiZXR3ZWVuIHJl Y29yZGluZyB0aW1lLXN0YW1wcyAxMW0zMHMgdG8gMTNtMzBzKTwvZm9udD48L3NwYW4+PC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPjxicj4NCjwvZm9udD48 L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KPC9mb250PjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPlNsaWRlIDMgKG9mIHRoZSBkcmFmdC1saSBw cmVzZW50YXRpb24pPC9mb250PjwvZGl2Pg0KPGRpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJy aSI+PT08L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPjxicj4NCjwvZm9u dD48L2Rpdj4NCjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj5ObyBuZXcgY2FwYWJp bGl0eSBpcyBleHBsYWluZWQgb24gdGhpcyBzbGlkZSBpbiBjb21wYXJpc29uIHdpdGggdGhlIGRy YWZ0LXZhbmRldmVsZGUuPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj5J biBkcmFmdC12YW5kZXZlbGRlIHRoZSBpbmZvcm1hdGlvbiBmb3VuZCBpbiB0aGUgaW5kaXJlY3Rp b24taWQgaXMgdXNlZCBvbiBhIGZsb3dzcGVjIGNsaWVudCBpbiBhIGxvY2FsIG1hcHBpbmctdGFi bGUgKGluZGlyZWN0aW9uLWlkIHRhYmxlKSB0byBmaW5kIGxvY2FsIGZvcndhcmRpbmcgaW5mb3Jt YXRpb24uIFRoZSBuZXcgZmxvd3NwZWMgZXh0ZW5kZWQgY29tbXVuaXR5IGFzIGRvY3VtZW50ZWQg YnkNCiBkcmFmdC12YW5kZXZlbGRlIGNhbiBwcm92aWRlIGFscmVhZHkgYSBmbG93c3BlYyBjbGll bnQgdGhlIHJlcXVpcmVkIHNlbWFudGljL2NvbnRleHQgaW5mb3JtYXRpb24gKGV4YW1wbGUgaXMg dGhlIOKAmELigJkgYml0KS48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmki Pjxicj4NCjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KPC9m b250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj5TbGlkZSA0IChvZiB0aGUgZHJh ZnQtbGkgcHJlc2VudGF0aW9uKTwvZm9udD48L2Rpdj4NCjxkaXY+DQo8ZGl2Pjxmb250IGZhY2U9 IkNhbGlicmkiPj09PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj48YnI+ DQo8L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+VGhlIGdv YWwgb2YgZHJhZnQtbGkgaXMgdG8gZGVmaW5lIGEg4oCcc2VtYW50aWNzIGRlcGVuZGVudOKAnSBh Y3Rpb24uPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj5Ib3dldmVyLCBk cmFmdC12YW5kZXZlbGRlIGFscmVhZHkgYWxsb3dzIHRoYXQgZnVuY3Rpb25hbGl0eSBiZWZvcmUg ZHJhZnQtbGkgZXhpc3RlZDwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+ PGJyPg0KPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj48YnI+DQo8L2Zv bnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPlNsaWRlIDUgKG9mIHRoZSBkcmFm dC1saSBwcmVzZW50YXRpb24pPC9mb250PjwvZGl2Pg0KPGRpdj4NCjxkaXY+PGZvbnQgZmFjZT0i Q2FsaWJyaSI+PT08L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPjxicj4N CjwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj5EcmFmdC12 YW5kZXZlbGRlIGhhcyBpbmRlZWQgdGhlIHBvdGVudGlhbCB0byBiZSB1c2VkIGluIHN1Y2ggYSBt YW5uZXIuIFRoZSBpbnRlbmQgb2YgdGhpcyBzbGlkZSBhdCB0aGUgdGltZSBvZiB1c2FnZSB3YXMg dG8gc2hvdyBhbiBleHRyZW1lIGV4YW1wbGUgb2YgdGhlIGZsZXhpYmxpdHkgdGhlIHRlY2hub2xv Z3kgb2ZmZXJzLiBXaGVuIGZvciBleGFtcGxlIHVzaW5nIHJlZGlyZWN0aW9uIHRvIGJpbmRpbmct U0lEDQogKGFzIGRvY3VtZW50ZWQgaW4gbGF0ZXN0IGRyYWZ0LXZhbmRldmVsZGUpIHRoZW4gdGhl IGxvY2FsIG1hcHBpbmcgdGFibGUgY2FuIGJlIGJhc2VkIGFyb3VuZCB0aGUgc2lnbmFsbGVkIHNl bWFudGljcy48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPjxicj4NCjwv Zm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KPC9mb250PjwvZGl2 Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj5TbGlkZSA2IChvZiB0aGUgZHJhZnQtbGkgcHJl c2VudGF0aW9uKTwvZm9udD48L2Rpdj4NCjxkaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmki Pj09PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj48YnI+DQo8L2ZvbnQ+ PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPkRyYWZ0LXZh bmRldmVsZGUgaGFzIDEzIGJpdHMgYXZhaWxhYmxlIGZvciB0eXBlcywgaGVuY2UgdGhlIHBvdGVu dGlhbCB0byBzdXBwb3J0L3NpZ25hbCAyXjEzICg9ODE5MikgdHlwZXMgd2hlbiB1c2luZyB0aGUg ZmllbGQgYXMgc2NhbGFyIHZhbHVlICh3aGVuIGNvbXBhcmluZyB3aXRoIGEgcG90ZW50aWFsIGZv ciAyNTUgdHlwZXMgdXNpbmcgZHJhZnQtbGkpPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNl PSJDYWxpYnJpIj48YnI+DQo8L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pjxmb250 IGZhY2U9IkNhbGlicmkiPlRoZSBjbGFpbSBtYWRlIG9uIHNsaWRlNiB0aGF0IGRyYWZ0LXZhbmRl dmVsZGUgYWxsb3dzIG9ubHkgMTMgdHlwZSBvZiBzZW1hbnRpYyBpbmZvcm1hdGlvbiBpcyB3cm9u ZyBhc3N1bXB0aW9uLjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+PGJy Pg0KPC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJp Ij5BdCB0aGUgdGltZSBvZiB3cml0aW5nLCBpdCB3YXMgZm91bmQgdXNlZnVsIHRvIHNpZ25hbCBi aW5kaW5nIFNJRCB1c2VmdWwgc2VtYW50aWMg4oCmIFdlIGRlY2lkZWQgdG8gbGVhdmUgdGhlIHJl bWFpbmluZyBiaXRzIHJlc2VydmVkL29wZW4gZm9yIGRpc2N1c3Npb24gb24gaG93IHRvIGJlc3Qg dXNlIHRoZSBmaWVsZCBpbnN0ZWFkLiZuYnNwOzwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRpdj48 Zm9udCBmYWNlPSJDYWxpYnJpIj5NYXliZSB0aGUgV0cgZmVlbHMgaXQgaXMgYmVzdCB0byB1c2Ug b25seSBhIGZldyBiaXRzIGZvciBzZW1hbnRpY3MgYW5kIGtlZXAgdGhlIHJlbWFpbmRlciByZXNl cnZlZCBmb3IgZnV0dXJlIHVzZS4mbmJzcDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9 IkNhbGlicmkiPjxicj4NCjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+ S2luZCBSZWdhcmRzLDwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+Ry88 L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxNHB4 OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPjxicj4NCjwvZGl2Pg0KPGRpdiBz dHlsZT0iZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsi Pjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTRw eDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxkaXYgaWQ9Ik1BQ19PVVRM T09LX1NJR05BVFVSRSI+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1z aXplOiAxNHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPjxicj4NCjwvZGl2 Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIiBzdHlsZT0iZm9udC1zaXplOiAxNHB4 OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdiBzdHlsZT0iZm9udC1m YW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjEycHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6Ymxh Y2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7 IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAw aW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBu b25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5G cm9tOiA8L3NwYW4+SWRyICZsdDs8YSBocmVmPSJtYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmci Pmlkci1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mIFN1c2FuIEhhcmVzICZs dDs8YSBocmVmPSJtYWlsdG86c2hhcmVzQG5kemguY29tIj5zaGFyZXNAbmR6aC5jb208L2E+Jmd0 Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+RnJpZGF5 IDEzIE1heSAyMDE2IGF0IDEyOjQ2PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQi PlRvOiA8L3NwYW4+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmlkckBpZXRmLm9yZyI+aWRyQGlldGYu b3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlkckBpZXRmLm9yZyI+aWRyQGlldGYu b3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDog PC9zcGFuPltJZHJdIElEUiBpbnRlcmltIG9uIE1heSAxNnRoIC0gd2ViZXgsIHF1ZXN0aW9ucyBm b3IgbWVldGluZywgYW5kIHJlY29yZGluZ3MuPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+DQo8ZGl2IHht bG5zOnY9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206dm1sIiB4bWxuczpvPSJ1cm46c2NoZW1h cy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOnc9InVybjpzY2hlbWFzLW1pY3Jv c29mdC1jb206b2ZmaWNlOndvcmQiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAx NCAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAq Lw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAg MCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgi Ow0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxl IERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFs DQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4w cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJh Z3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCglt YXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0K CW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWls U3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0K CXttc28tbGlzdC1pZDoxMjQ5OTk2OTIyOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczotMTcwODM4MDI1OCA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2 NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpA bGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0OlxGMEI3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDozOC4zNXB0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJn aW4tbGVmdDo3NC4zNXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYwQTc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjExMC4zNXB0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpcRjBCNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MTQ2LjM1cHQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1s ZWZ0OjE4Mi4zNXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYwQTc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjIxOC4zNXB0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6 bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDpcRjBCNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjU0LjM1cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0 OjI5MC4zNXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6XEYwQTc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjMyNi4zNXB0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2lu LWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPGRpdiBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHRpbWUgb2YgdGhlIGludGVyaW0gaXMgMjI6 MDAtMjM6MDAgRURUIG9uIE1heSAxNjxzdXA+dGg8L3N1cD4uICZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGUgaW50ZXJpbSB3aWxsIGRpc2N1c3MgdGhlIGZvbGxvd2luZyB0d28gZHJh ZnRzIGluIG9yZGVyIHRvIGNyZWF0ZSBhIFdHIHNvbHV0aW9uOg0KPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzguMzVwdDt0ZXh0LWluZGVudDotLjI1 aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCEtLVtpZiAhc3VwcG9ydExpc3RzXS0tPjxz cGFuIHN0eWxlPSIiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9 ImZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgZm9udC1zaXplOiA3cHQ7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJzsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCEtLVtlbmRpZl0tLT5kcmFm dC12YW5kZXZlbGRlLWlkci1mbG93c3BlYy1wYXRoLXJlZGlyZWN0LCBhbmQ8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzguMzVw dDt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCEtLVtpZiAh c3VwcG9ydExpc3RzXS0tPjxzcGFuIHN0eWxlPSIiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25v cmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgZm9udC1zaXplOiA3cHQ7IGxpbmUtaGVpZ2h0 OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+ PCEtLVtlbmRpZl0tLT5kcmFmdC1saS1pZHItZmxvd3NwZWMtcmVkaXJlY3QtZ2VuZXJhbGl6ZWQt c2lkPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvbWUgb2YgdGhlIFF1ZXN0aW9ucyB0aGF0IHdp bGwgYmUgZGlzY3VzcyBhcmUgaW5jbHVkZWQgYmVsb3cuJm5ic3A7IFBsZWFzZSByZXZpZXcgdGhl IHByZS1yZWNvcmRpbmcgcHJlc2VudGF0aW9ucyBwcmlvciB0byB0aGUgbWVldGluZy4mbmJzcDsm bmJzcDsgVGhlIENoYWlycyBlbmNvdXJhZ2UgZGlzY3Vzc2lvbiBvZiB0aGVzZSBxdWVzdGlvbnMg b24gdGhlIGxpc3QgYmVmb3JlLCBkdXJpbmcsIGFuZCBhZnRlciB0aGUgbWVldGluZy4NCjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5TdWUgYW5kIEpvaG4gPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pj09PT09PT09PT09PT09PT09PT09PT09PTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5BZ2Vu ZGEgZm9yIElEUiBWaXJ0dWFsIEludGVyaW0gTWVldGluZyA8bzpwPjwvbzpwPjwvYj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk1heSAxNiwgMjAxNjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ MjI6MDAgLSAyMzowMCBFRFQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2ViRXg6IDxhIGhyZWY9 Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW05YmU0ODFkMTk5ODhkZDFi NTQ1YmU2NzU5YWVlMjY3YiI+DQpodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJ RD1tOWJlNDgxZDE5OTg4ZGQxYjU0NWJlNjc1OWFlZTI2N2I8L2E+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5NZWV0aW5nIG51bWJlcjombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgNjQ5IDIzNSA0MTE8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1lZXRpbmcgcGFzc3dvcmQ6Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEpnNjZkMnBtPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkpvaW4gYnkgcGhvbmU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjEtODc3LTY2OC00NDkzIENhbGwtaW4gdG9sbCBmcmVlIG51bWJlciAoVVMvQ2Fu YWRhKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MS02NTAtNDc5LTMyMDgg Q2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+QWNjZXNzIGNvZGU6IDY0OSAyMzUgNDExPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPlF1ZXN0aW9ucyBmb3IgbWVldGluZzogPG86cD48L286cD48L2I+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5TdWJtaXR0ZWQgYnkgKEVyaWMgV3UpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4xLiBSZWRpcmVjdC10by1TcGVjaWZpYy1UdW5uZWwgd2l0aCBCR1AgUGF0aCBBdHRyaWJ1 dGUgW1RVTk5FTEVOQ0FQU11bTVBQXSBhbmQNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7Jm5ic3A7UmVkaXJlY3QtdG8tSUlEL0dTSUQsIFJlcXVpcmVkIGJ5IGRp ZmZlcmVudCB1c2UgY2FzZXMsIGNhbiB3ZSBoYXZlIHR3byBkb2NzIGluIElEUiBJbiBwYXJhbGxl bD8NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7W0Nv bXBhcmlzb24gdG8gUmVkaXJlY3QtdG8tSUlEL0dTSUQgLCBkcmFmdC1oYW8gd2lsbCBoYXZlIG1v cmUgbGl0dGxlIG1vZGlmaWNhdGlvbg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsmbmJzcDt0byBleGlzdGluZyBtZWNoYW5pc21zLCBObyBuZWVkIHRvIGRvIE1h cHBpbmcgL1JlY3Vyc2l2ZSBMb29rdXAuXTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yLiZuYnNw OyBGb3IgSUlEL0dTSUQsIG9uZSBtYXBwaW5nIHRhYmxlIGZvciA8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwO2FsbCBraW5kcyBvZiBzZWdtZW50cy9mb3J3 YXJkaW5nLWVudGl0aWVzIHZzLiBvbmUgbWFwcGluZyB0YWJsZQ0KPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDtwZXIgc2VnbWVudHMvZm9yd2FyZGluZy1l bnRpdGllcyB0eXBlLCBzaG91bGQgd2Ugc3VwcG9ydCBib3RoPzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj5DaGFpciBRdWVzdGlvbnM6IDxvOnA+PC9vOnA+PC9iPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MSkg RG9lcyB0aGUgV0cgZmVlbCB3ZSBuZWVkIHRoZSBmb2xsb3dpbmcgZm9yIFJGQzU1NzViaXMgKERE b1MpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgYSkgUmVkaXJl Y3Rpb24gdG8gVlJGLCA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OyZuYnNwO2IpIFJlZGlyZWN0aW9uIHRvIEluZGlyZWN0aW9uIHRvIElQLCBhbmQgJm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDtjKSBSZWRpcmVj dGlvbiB0byBTZXJ2aWNlIChuZXcpPyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Mikg SWYgdGhlIFdHIGRlc2lyZXMgcmVkaXJlY3Rpb24gdG8gU2VydmljZSByb3V0aW5nLCBkb2VzIHRo ZSBXRyBkZXNpcmU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmEpIE5leHQt SG9wIHR1bm5lbCBzdXBwb3J0PyAtPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5iKSBOZXh0LUhvcCBURSBUdW5uZWwgc3VwcG9ydD8gPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDtjKSBOZXN0ZWQgVHVubmVsIHN1cHBvcnQ/IDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ZCkgTmV4dC1OZXh0IEhvcCBUdW5uZWwg U3VwcG9ydD8gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDtlKSBS b3V0ZXIgbG9jYWxpemVkIFR1bm5lbCByZWN1cnNpb24/IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7ZikgVHVubmVsIEVuY2FwIFJlY3Vyc2lvbjogPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjMpIFdoYXQgcGllY2VzIG9mIHRoZSBwcm9wb3NlZCBzb2x1dGlvbnMg aGF2ZSBiZWVuIGltcGxlbWVudGVkPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDsmbmJzcDsgYW5kL29yIGRlcGxveWVkPyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj5QcmVzZW50YXRpb25zIChwcmVyZWNvcmRlZCwgcGxlYXNlIHJldmlldyBwcmlvciB0byBtZWV0 aW5nKTo8bzpwPjwvbzpwPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIGRyYWZ0LXZh bmRldmVsZGUtaWRyLWZsb3dzcGVjLXBhdGgtcmVkaXJlY3Q8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBHdW50ZXIgVmFuIERlIFZlbGRlPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgMjEgbWludXRlczxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5j b20vaWV0Zi9sZHIucGhwP1JDSUQ9ZTAxZDYyNjYxMDg1ZjY2MGY0NzBmZWRkZDliZjI2NmYiPg0K aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2xkci5waHA/UkNJRD1lMDFkNjI2NjEwODVmNjYw ZjQ3MGZlZGRkOWJmMjY2ZjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cHJlc2VudGF0aW9u IGF0OiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzL2ludGVyaW0vMjAxNi8wNS8xNi9pZHIvc2xpZGVz L3NsaWRlcy1pbnRlcmltLTIwMTYtaWRyLTUtMC5wZGYiPmh0dHBzOi8vd3d3LmlldGYub3JnL3By b2NlZWRpbmdzL2ludGVyaW0vMjAxNi8wNS8xNi9pZHIvc2xpZGVzL3NsaWRlcy1pbnRlcmltLTIw MTYtaWRyLTUtMC5wZGY8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZHJhZnQtbGktaWRyLWZsb3dzcGVjLXJlZGly ZWN0LWdlbmVyYWxpemVkLXNpZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ RXJpYyBXdSA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIwIG1pbnV0ZXMg PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN0cmVhbWluZyByZWNvcmRpbmcgbGluazo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJl eC5jb20vaWV0Zi9sZHIucGhwP1JDSUQ9Yzg2MTVhYTg0NTgwMWExZTRiNzljYjE3MDhhMDQ0ODQi Pmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9sZHIucGhwP1JDSUQ9Yzg2MTVhYTg0NTgwMWEx ZTRiNzljYjE3MDhhMDQ0ODQ8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5Eb3dubG9hZCByZWNvcmRpbmcgbGluazo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9sc3IucGhwP1JDSUQ9 NGJkNTA0MzI5NzI3ZDJhODExYzljYjBjOWJjNzEzZDgiPmh0dHBzOi8vaWV0Zi53ZWJleC5jb20v aWV0Zi9sc3IucGhwP1JDSUQ9NGJkNTA0MzI5NzI3ZDJhODExYzljYjBjOWJjNzEzZDg8L2E+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPnByZXNlbnRhdGlvbiBhdDogPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVk aW5ncy9pbnRlcmltLzIwMTYvMDUvMTYvaWRyL3NsaWRlcy9zbGlkZXMtaW50ZXJpbS0yMDE2LWlk ci01LTEucGRmIj5odHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy9pbnRlcmltLzIwMTYv MDUvMTYvaWRyL3NsaWRlcy9zbGlkZXMtaW50ZXJpbS0yMDE2LWlkci01LTEucGRmPC9hPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+PC9zcGFuPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_9F08790960F34F5C8427C0BD2A4ED9FFalcatellucentcom_-- From nobody Fri May 13 08:00:49 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0B912D56E for ; Fri, 13 May 2016 08:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yof88i8N_kRN for ; Fri, 13 May 2016 08:00:43 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 069AB12D568 for ; Fri, 13 May 2016 08:00:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=50681; q=dns/txt; s=iport; t=1463151642; x=1464361242; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=8NpX7xsI29iziS/ZgQRKX7MqFfSpUKPbmr9zR/tM2DY=; b=lTV54LEd5tsIcaf81SJmWHskzgL9+NPM72Rwwih5c3g0fyDy6ZxOxd9g a/BRtTShHvq2oenYtakHcRLloGLoP4xo9AQzIbFfd6yDJvOGo0lyAlDcp u1mU4Qq59qWgWUvtEThqFJOv+j3xmI9yBJbxOsdVuz2zgm6zPXq3zxmPY 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A6AAAO6zVX/5BdJa1EFwOCbEtVfgaCd?= =?us-ascii?q?rZaAQ2BDQVkJIVtAhyBDzgUAQEBAQEBAWUnhEIBAQECAgwXCjkhAgIBBgIRAwE?= =?us-ascii?q?CFQQIAQMDAwICAhkXFAkHAQEBAQMBEgkLB4gUDiySLJ0dhQ2LfAEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBARwFim2BOQGCaAEBDCYJARURB4IyglkFh36QKQGFfYJ4hSi?= =?us-ascii?q?BaYRPh0aBG49AAR4BAUKCBg0OFmpLbgEEhxkHFwcYfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,614,1454976000"; d="scan'208,217";a="271371384" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 May 2016 15:00:41 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u4DF0ffe027981 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 May 2016 15:00:41 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 13 May 2016 11:00:40 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Fri, 13 May 2016 11:00:40 -0400 From: "Acee Lindem (acee)" To: "Van De Velde, Gunter (Nokia - BE)" , "idr@ietf.org" , John Scudder Thread-Topic: [Idr] IDR interim on May 16th - webex, questions for meeting, and recordings. Thread-Index: AdGtA5N1fQH6ZeaQT8WhQMAKvH+1FwAI/l2AAAAqUoA= Date: Fri, 13 May 2016 15:00:40 +0000 Message-ID: References: <008a01d1ad04$c63a77d0$52af6770$@ndzh.com> <9F087909-60F3-4F5C-8427-C0BD2A4ED9FF@alcatel-lucent.com> In-Reply-To: <9F087909-60F3-4F5C-8427-C0BD2A4ED9FF@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: multipart/alternative; boundary="_000_D35B638860D9Eaceeciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] IDR interim on May 16th - webex, questions for meeting, and recordings. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 15:00:47 -0000 --_000_D35B638860D9Eaceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9obiwNCg0KSSB3YXMgYWJsZSB0byBmaW5kIEd1bnRlcuKAmXMgV2ViRXggcmVjb3JkaW5n IHZpYSBhIFVSTCBpbiBvbmUgb2YgdGhlIEUtbWFpbHMgYnV0IG5laXRoZXIgcmVjb3JkaW5nIGxp bmsgaXMgb24gdGhlIG1lZXRpbmcgbWF0ZXJpYWxzIHBhZ2UgYW5kIEnigJlkIGxpa2UgdG8gd2F0 Y2ggRXJpY+KAmXMgYXMgd2VsbC4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3Mv aW50ZXJpbS8yMDE2LzA1LzE2L2lkci9wcm9jZWVkaW5ncy5odG1sDQoNClRoYW5rcywNCkFjZWUN Cg0KRnJvbTogSWRyIDxpZHItYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86aWRyLWJvdW5jZXNAaWV0 Zi5vcmc+PiBvbiBiZWhhbGYgb2YgIlZhbiBEZSBWZWxkZSwgR3VudGVyIChOb2tpYSAtIEJFKSIg PGd1bnRlci52YW5fZGVfdmVsZGVAbm9raWEuY29tPG1haWx0bzpndW50ZXIudmFuX2RlX3ZlbGRl QG5va2lhLmNvbT4+DQpEYXRlOiBGcmlkYXksIE1heSAxMywgMjAxNiBhdCAxMDo1NSBBTQ0KVG86 IElEUiBMaXN0IDxpZHJAaWV0Zi5vcmc8bWFpbHRvOmlkckBpZXRmLm9yZz4+DQpTdWJqZWN0OiBS ZTogW0lkcl0gSURSIGludGVyaW0gb24gTWF5IDE2dGggLSB3ZWJleCwgcXVlc3Rpb25zIGZvciBt ZWV0aW5nLCBhbmQgcmVjb3JkaW5ncy4NCg0KUHJlLWxpbWluYXIgY29tbWVudHPigKYuLg0KDQpC ZWZvcmUgZW5nYWdpbmcgd2l0aCBteSBmZWVkYmFjayBhbmQgYWRkcmVzc2luZyB0aGUgZGlzY3Vz c2lvbiBzbGlkZXMsIGkgd291bGQgbGlrZSB0byB0aGFuayBib3RoIFN1ZSBhbmQgSm9obiBmb3Ig Z29pbmcgdGhyb3VnaCB0aGUgZWZmb3J0IGFuZCB0aW1lIHRvIHRyeSB0byBtYWtlIHRoZSByZWNv cmRpbmdzIGFzIGdvb2QgYXMgcG9zc2libGUgYW5kIGludmVzdGluZyBub24tdHJpdmlhbCBhbW91 bnRzIG9mIHRpbWUgdG8gZ2V0IHRoZSBqb2IgZG9uZS4NCg0KSSB3b3VsZCBhbHNvIGxpa2UgdG8g dGhhbmtzIEVyaWMgV3UgdG8gZ28gdGhyb3VnaCB0aGUgZXhlcmNpc2Ugb2YgcmVjb3JkaW5nIGhp cyBwcmVzZW50YXRpb24gb2YgdGhlIHNsaWRlcy4gSSB3ZW50IHRocm91Z2ggdGhlIHNhbWUgZXhl cmNpc2UgYW5kIGV2ZW4gdGhvdWdoIHRoZXJlIHdlcmUgbGVzcyBvcGVyYXRpb25hbCBpc3N1ZXMg dG8gZGVhbCB3aXRoIGR1cmluZyBteSByZWNvcmRpbmcsIGl0IGlzIGEgbm9uLXRyaXZpYWwgdGFz ayB0byBzcGVhayB0byBhIHNjcmVlbiBhbmQgbm90IHRvIGFuIGF1ZGllbmNlLg0KDQoNCkNvbW1l bnRzOiBXb3JraW5nIHNsaWRlcyBkaXNjdXNzaW9uIG9mIHRoZSAxNiBNYXkgMjAxNiBJbnRlcmlt IElEUiBtZWV0aW5nOg0KLS0tLS0tLS0tLS0tLQ0KDQoNClRpbWVsaW5lIGluZm8NCj09PT09PT09 PT0NCg0KZHJhZnQtdmFuZGV2ZWxkZS1pZHItZmxvd3NwZWMtcGF0aC1yZWRpcmVjdC0wMCBjcmVh dGVkIG9uIDE0IFNlcHRlbWJlciAyMDE1DQpkcmFmdC12YW5kZXZlbGRlLWlkci1mbG93c3BlYy1w YXRoLXJlZGlyZWN0LTAxIGNyZWF0ZWQgb24gMTIgSmFudWFyeSAyMDE2DQpkcmFmdC12YW5kZXZl bGRlLWlkci1mbG93c3BlYy1wYXRoLXJlZGlyZWN0LTAyIGNyZWF0ZWQgb24gMTcgTWFyY2ggMjAx Ng0KDQpkcmFmdC1saS1pZHItZmxvd3NwZWMtcmVkaXJlY3QtZ2VuZXJhbGl6ZWQtc2lkLTAwIGNy ZWF0ZWQgb24gMjEgTWFyY2ggMjAxNg0KDQoNCkdlbmVyYWwgc2xpZGUgb2JzZXJ2YXRpb25zIGFi b3V0IGRyYWZ0LWxpLWdlbmVyYWxpc2VkLXNpZC0wMCAocmVmLiBkaXNjdXNzaW9uIHNsaWRlIGZv ciAxNiBNYXkgMjAxNikNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0NCg0KRHJhZnQtbGkgZG9jdW1lbnRzIGEgZmxvd3NwZWMgYWN0aW9u IHVzaW5nIGEgbmV3IGNvbW11bml0eSAoZ2VuZXJhbGl6ZWQtU0lEKS4gVGhlIGV4dGVuZGVkIGNv bW11bml0eSBwcm92aWRlcyBhIGZsb3dzcGVjIGNsaWVudCBpbmZvcm1hdGlvbiB0byBtYWtlIGEg bG9jYWwgZm9yd2FyZGluZyBkZWNpc2lvbiBieSBtZWFucyBvZiBhIGxvY2FsIG1hcHBpbmcgdGFi bGUuIFRoZSB0d28gbWFpbiBjb21wb25lbnRzIHVzZWQgYnkgdGhlIGZsb3dzcGVjIGNsaWVudCBp czogKDEpIGFuIGlkZW50aWZpZXIgYW5kICgyKSBzZW1hbnRpY3MuDQoNCkRyYWZ0LXZhbmRldmVs ZGUgZG9jdW1lbnRzIGEgZmxvd3NwZWMgYWN0aW9uIHVzaW5nIGEgbmV3IGNvbW11bml0eSAoSW5k aXJlY3Rpb24tSUQpLiBUaGUgZXh0ZW5kZWQgY29tbXVuaXR5IHByb3ZpZGVzIGEgZmxvd3NwZWMg Y2xpZW50IGluZm9ybWF0aW9uIHRvIG1ha2UgYSBsb2NhbCBmb3J3YXJkaW5nIGRlY2lzaW9uIGJ5 IG1lYW5zIG9mIGEgbG9jYWwgbWFwcGluZyB0YWJsZS4gVGhlIHR3byBtYWluIGNvbXBvbmVudHMg dXNlZCBieSB0aGUgZmxvd3NwZWMgY2xpZW50IGlzOiAoMSkgYW4gaWRlbnRpZmllciBhbmQgKDIp IG9wdGlvbmFsbHkgc2VtYW50aWNzIChUYWJsZSBzZW1hbnRpY3MgKyBUdW5uZWwtSUQpLg0KDQpk cmFmdC12YW5kZXZlbGRlLWlkci1mbG93c3BlYy1wYXRoLXJlZGlyZWN0LTAyIHdhcyBjcmVhdGVk IOKAnGJlZm9yZSIgZHJhZnQtbGktaWRyLWZsb3dzcGVjLXJlZGlyZWN0LWdlbmVyYWxpemVkLXNp ZC0wMCBhbmQgYWNoaWV2ZXMgdGhlIHNhbWUgZnVuY3Rpb25hbGl0eSBhbmQgbW9yZS4gKEZvciBl eGFtcGxlIGRyYWZ0LXZhbmRldmVsZGUgaGFzIHRoZSBwb3RlbnRpYWwgdG8gc2lnbmFsIDgxOTIg dHlwZXMgb2Ygc2VtYW50aWMgbWFwcGluZyB0YWJsZXMgd2hpbGUgZHJhZnQtbGkgaGFzIDI1NSwg YW5vdGhlciBleGFtcGxlIGlzIHRoZSBUSUQgZmllbGQgd2hpY2ggYWxsb3dzIGR5bmFtaWMgTmV4 dC1OZXh0LUhvcCBjb25zdHJ1Y3RzIHVzZSBmb3IgRVBFIEREb1MgcmVkaXJlY3Rpb24pLg0KDQpE dXJpbmcgV0cgYWRkb3B0aW9uLWNhbGwgMy8yNSB0byA0LzggdGhlIGZvbGxvd2luZyBoYXMgYmVl biBtZW50aW9uZWQgYnkgSWduYXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dl Yi9pZHIvY3VycmVudC9tc2cxNTUxMi5odG1sDQoNCiJEcmFmdC12YW5kZXZlbGRlIGNhbiBhY2hp ZXZlIGFsbCB3aGF0IGRyYWZ0LWhhbyBhbmQgZHJhZnQtbGkgY2FuLCBhbmQgaW4gYSBtb3JlIGZs ZXhpYmxlIHdheS4gSGF2aW5nIHRoZSBhYmlsaXR5IHRvIGRlY291cGxlIHJlZGlyZWN0aW9uIHR1 bm5lbCB0eXBlIGZyb20gcmVkaXJlY3Rpb24gYWN0aW9uIGlzIGJvdGggcHJhY3RpY2FsIGFuZCBl eHRlbnNpYmxlIC0gdGhlIGFjdHVhbCB0dW5uZWwgdG8gYmUgdXNlZCBpcyBhIGxvY2FsIG9wZXJh dGlvbmFsIGRlY2lzaW9uIGZvciBlYWNoIG5ldHdvcmsgZWxlbWVudCwgaXQgaXMgbm90IG5lY2Vz c2FyeSBzaWduYWxsZWQgYXQgdGhlIHNhbWUgdGltZSBhbmQgYnkgdGhlIHNhbWUgbWVjaGFuaXNt LiBEZWNvdXBsaW5nIHNpZ25hbGxpbmcgYW5kIHJlZGlyZWN0IHBhcnRzIGFsaWducyB3ZWxsIHRv IG9wZXJhdGlvbmFsIHByYWN0aWNlcyBvZiB1c2luZyBzcGVjaWZpYyB0b29scyBmb3Igc3BlY2lm aWMgdGFza3MuIEp1c3QgdGhhdCBCR1AgY291bGQgZG8gdGhhdCBkb2VzIG5vdCBuZWNlc2Fzcnkg bWVhbiB0aGF0IGl0IHNob3VsZCBiZSB1c2VkIGFzIGEgYmVzdCBmaXQuIEZyb20gb3BlcmF0aW9u YWwgcGVyc3BlY3RpdmUgdGhlcmUgaXMgbm8gbmVlZCB0byBoYXZlIG11bHRpcGxlIHNvbHV0aW9u cyB0aGF0IHRyeSB0byBhZGRyZXNzIHRoZSBuYXJyb3cgcHJvYmxlbSBzcGFjZSBpbiBzaW1pbGFy IHlldCBpbmNvbXBhdGlibGUgd2F5cy4gVGhlcmUgc2hvdWxkIGJlIG9uZSBkb2N1bWVudCBmb3Ig cmVkaXJlY3QsIGFuZCBkcmFmdC12YW5kZXZlbGRlIGlzIGEgZ29vZCBzdGFydGluZyBiYXNlIGZv ciB0aGF0LiINCg0KDQpEZXRhaWwgdmlldzogc2xpZGUgb2JzZXJ2YXRpb25zIGRyYWZ0LWxpLWdl bmVyYWxpc2VkLXNpZC0wMCBkaXNjdXNzaW9uDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KU2xpZGUgMiAob2YgdGhlIGRyYWZ0LWxp IHByZXNlbnRhdGlvbik6IEhpc3RvcnkNCj09DQoNClRoZSBzbGlkZSBmb3JnZXRzIHRvIG1lbnRp b24gdGhhdCBkcmFmdC12YW5kZXZlbGRlIHdhcyBlbmhhbmNlZCBhbmQgcHJvZ3Jlc3NlZCBiYXNl ZCB1cG9uIGNvbnN0cnVjdGl2ZSBXRyBmZWVkYmFjay4gTXVjaCBmZWVkYmFjayBoYXMgYmVlbiBp bnRlZ3JhdGVkIGJldHdlZW4gZHJhZnQtdmFuZGV2ZWxkZSAtMDAgdG8g4oCTMDIgQkVGT1JFIGRy YWZ04oCTbGkgZXZlbiBleGlzdGVkLiBGb3IgZXhhbXBsZToNCiogVXNlLWNhc2Ugc2NlbmFyaW/i gJlzIHdlcmUgYWRkZWQNCiogIlBhdGgtaWQiIGNoYW5nZWQgdG8gIkluZGlyZWN0aW9uLWlkIg0K KiBDb25jZXB0IG9mIEluZGlyZWN0aW9uIHRhYmxlcyBoYXMgYmVlbiBhZGRlZCAoaGVuY2UgYWRk aW5nIHRoZSBjYXBhYmlsaXR5IG9mIGNvbnRleHQvc2VtYW50aWNzIHNpZ25hbGxpbmcgYWxyZWFk eSBzaW5jZSB2ZXJzaW9uIC0wMSkNCiogRmxvd3NwZWMgdmFsaWRhdGlvbiBpbmZvcm1hdGlvbiBp cyBhZGRlZA0KKiBzaWduYWxsaW5nIG9mIGNvbnRleHQvc2VtYW50aWNzIGlzIGFkZGVkIGJ5IGlu dHJvZHVjaW5nIEJpbmRpbmctU0lEIGNvbnRleHQgaWRlbnRpZmllciBhcyBhIGZpcnN0IGV4dGVu c2lvbiBvZiBJbmRpcmVjdGlvbi1pZCBleHRlbmRlZCBjb21tdW5pdHkuDQoNCkl0IGlzIGFuIGlu Y29ycmVjdCBhc3N1bXB0aW9uIG9mIG5vIGNvbnRleHQgYXdhcmVuZXNzIGluIGRyYWZ0LXZhbmRl dmVsZGUuIGRyYWZ0LXZhbmRldmVsZGUtaWRyLWZsb3dzcGVjLXBhdGgtcmVkaXJlY3QgYWRkZWQg Y29udGV4dCBzdXBwb3J0IGJlZm9yZSBkcmFmdC1saSBleGlzdGVkLCBhbmQgcmFpc2VzIHF1ZXN0 aW9ucyBhYm91dCBuZXcgZWxlbWVudHMgZXhwb3NlZCB3aXRoIGRyYWZ0LWxpIGNvbXBhcmVkIHRv IGRyYWZ0LXZhbmRldmVsZGUuDQoNCihmd2l3IFRoZSBzZW1hbnRpYyBhd2FyZW5lc3Mgb2YgZHJh ZnQtdmFuZGV2ZWxkZSBpcyBtZW50aW9uZWQgYW5kIHRoZSB3ZWJleCByZWNvcmRpbmcgb2YgZHJh ZnQtbGkgYmV0d2VlbiByZWNvcmRpbmcgdGltZS1zdGFtcHMgMTFtMzBzIHRvIDEzbTMwcykNCg0K DQpTbGlkZSAzIChvZiB0aGUgZHJhZnQtbGkgcHJlc2VudGF0aW9uKQ0KPT0NCg0KTm8gbmV3IGNh cGFiaWxpdHkgaXMgZXhwbGFpbmVkIG9uIHRoaXMgc2xpZGUgaW4gY29tcGFyaXNvbiB3aXRoIHRo ZSBkcmFmdC12YW5kZXZlbGRlLg0KSW4gZHJhZnQtdmFuZGV2ZWxkZSB0aGUgaW5mb3JtYXRpb24g Zm91bmQgaW4gdGhlIGluZGlyZWN0aW9uLWlkIGlzIHVzZWQgb24gYSBmbG93c3BlYyBjbGllbnQg aW4gYSBsb2NhbCBtYXBwaW5nLXRhYmxlIChpbmRpcmVjdGlvbi1pZCB0YWJsZSkgdG8gZmluZCBs b2NhbCBmb3J3YXJkaW5nIGluZm9ybWF0aW9uLiBUaGUgbmV3IGZsb3dzcGVjIGV4dGVuZGVkIGNv bW11bml0eSBhcyBkb2N1bWVudGVkIGJ5IGRyYWZ0LXZhbmRldmVsZGUgY2FuIHByb3ZpZGUgYWxy ZWFkeSBhIGZsb3dzcGVjIGNsaWVudCB0aGUgcmVxdWlyZWQgc2VtYW50aWMvY29udGV4dCBpbmZv cm1hdGlvbiAoZXhhbXBsZSBpcyB0aGUg4oCYQuKAmSBiaXQpLg0KDQoNClNsaWRlIDQgKG9mIHRo ZSBkcmFmdC1saSBwcmVzZW50YXRpb24pDQo9PQ0KDQpUaGUgZ29hbCBvZiBkcmFmdC1saSBpcyB0 byBkZWZpbmUgYSDigJxzZW1hbnRpY3MgZGVwZW5kZW504oCdIGFjdGlvbi4NCkhvd2V2ZXIsIGRy YWZ0LXZhbmRldmVsZGUgYWxyZWFkeSBhbGxvd3MgdGhhdCBmdW5jdGlvbmFsaXR5IGJlZm9yZSBk cmFmdC1saSBleGlzdGVkDQoNCg0KU2xpZGUgNSAob2YgdGhlIGRyYWZ0LWxpIHByZXNlbnRhdGlv bikNCj09DQoNCkRyYWZ0LXZhbmRldmVsZGUgaGFzIGluZGVlZCB0aGUgcG90ZW50aWFsIHRvIGJl IHVzZWQgaW4gc3VjaCBhIG1hbm5lci4gVGhlIGludGVuZCBvZiB0aGlzIHNsaWRlIGF0IHRoZSB0 aW1lIG9mIHVzYWdlIHdhcyB0byBzaG93IGFuIGV4dHJlbWUgZXhhbXBsZSBvZiB0aGUgZmxleGli bGl0eSB0aGUgdGVjaG5vbG9neSBvZmZlcnMuIFdoZW4gZm9yIGV4YW1wbGUgdXNpbmcgcmVkaXJl Y3Rpb24gdG8gYmluZGluZy1TSUQgKGFzIGRvY3VtZW50ZWQgaW4gbGF0ZXN0IGRyYWZ0LXZhbmRl dmVsZGUpIHRoZW4gdGhlIGxvY2FsIG1hcHBpbmcgdGFibGUgY2FuIGJlIGJhc2VkIGFyb3VuZCB0 aGUgc2lnbmFsbGVkIHNlbWFudGljcy4NCg0KDQpTbGlkZSA2IChvZiB0aGUgZHJhZnQtbGkgcHJl c2VudGF0aW9uKQ0KPT0NCg0KRHJhZnQtdmFuZGV2ZWxkZSBoYXMgMTMgYml0cyBhdmFpbGFibGUg Zm9yIHR5cGVzLCBoZW5jZSB0aGUgcG90ZW50aWFsIHRvIHN1cHBvcnQvc2lnbmFsIDJeMTMgKD04 MTkyKSB0eXBlcyB3aGVuIHVzaW5nIHRoZSBmaWVsZCBhcyBzY2FsYXIgdmFsdWUgKHdoZW4gY29t cGFyaW5nIHdpdGggYSBwb3RlbnRpYWwgZm9yIDI1NSB0eXBlcyB1c2luZyBkcmFmdC1saSkNCg0K VGhlIGNsYWltIG1hZGUgb24gc2xpZGU2IHRoYXQgZHJhZnQtdmFuZGV2ZWxkZSBhbGxvd3Mgb25s eSAxMyB0eXBlIG9mIHNlbWFudGljIGluZm9ybWF0aW9uIGlzIHdyb25nIGFzc3VtcHRpb24uDQoN CkF0IHRoZSB0aW1lIG9mIHdyaXRpbmcsIGl0IHdhcyBmb3VuZCB1c2VmdWwgdG8gc2lnbmFsIGJp bmRpbmcgU0lEIHVzZWZ1bCBzZW1hbnRpYyDigKYgV2UgZGVjaWRlZCB0byBsZWF2ZSB0aGUgcmVt YWluaW5nIGJpdHMgcmVzZXJ2ZWQvb3BlbiBmb3IgZGlzY3Vzc2lvbiBvbiBob3cgdG8gYmVzdCB1 c2UgdGhlIGZpZWxkIGluc3RlYWQuDQpNYXliZSB0aGUgV0cgZmVlbHMgaXQgaXMgYmVzdCB0byB1 c2Ugb25seSBhIGZldyBiaXRzIGZvciBzZW1hbnRpY3MgYW5kIGtlZXAgdGhlIHJlbWFpbmRlciBy ZXNlcnZlZCBmb3IgZnV0dXJlIHVzZS4NCg0KS2luZCBSZWdhcmRzLA0KRy8NCg0KDQoNCkZyb206 IElkciA8aWRyLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnPj4g b24gYmVoYWxmIG9mIFN1c2FuIEhhcmVzIDxzaGFyZXNAbmR6aC5jb208bWFpbHRvOnNoYXJlc0Bu ZHpoLmNvbT4+DQpEYXRlOiBGcmlkYXkgMTMgTWF5IDIwMTYgYXQgMTI6NDYNClRvOiAiaWRyQGll dGYub3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+IiA8aWRyQGlldGYub3JnPG1haWx0bzppZHJAaWV0 Zi5vcmc+Pg0KU3ViamVjdDogW0lkcl0gSURSIGludGVyaW0gb24gTWF5IDE2dGggLSB3ZWJleCwg cXVlc3Rpb25zIGZvciBtZWV0aW5nLCBhbmQgcmVjb3JkaW5ncy4NCg0KVGhlIHRpbWUgb2YgdGhl IGludGVyaW0gaXMgMjI6MDAtMjM6MDAgRURUIG9uIE1heSAxNnRoLg0KDQpUaGUgaW50ZXJpbSB3 aWxsIGRpc2N1c3MgdGhlIGZvbGxvd2luZyB0d28gZHJhZnRzIGluIG9yZGVyIHRvIGNyZWF0ZSBh IFdHIHNvbHV0aW9uOg0KDQoNCsK3ICAgICAgICAgZHJhZnQtdmFuZGV2ZWxkZS1pZHItZmxvd3Nw ZWMtcGF0aC1yZWRpcmVjdCwgYW5kDQoNCsK3ICAgICAgICAgZHJhZnQtbGktaWRyLWZsb3dzcGVj LXJlZGlyZWN0LWdlbmVyYWxpemVkLXNpZA0KDQpTb21lIG9mIHRoZSBRdWVzdGlvbnMgdGhhdCB3 aWxsIGJlIGRpc2N1c3MgYXJlIGluY2x1ZGVkIGJlbG93LiAgUGxlYXNlIHJldmlldyB0aGUgcHJl LXJlY29yZGluZyBwcmVzZW50YXRpb25zIHByaW9yIHRvIHRoZSBtZWV0aW5nLiAgIFRoZSBDaGFp cnMgZW5jb3VyYWdlIGRpc2N1c3Npb24gb2YgdGhlc2UgcXVlc3Rpb25zIG9uIHRoZSBsaXN0IGJl Zm9yZSwgZHVyaW5nLCBhbmQgYWZ0ZXIgdGhlIG1lZXRpbmcuDQoNClN1ZSBhbmQgSm9obg0KDQo9 PT09PT09PT09PT09PT09PT09PT09PT0NCg0KQWdlbmRhIGZvciBJRFIgVmlydHVhbCBJbnRlcmlt IE1lZXRpbmcNCg0KTWF5IDE2LCAyMDE2DQoyMjowMCAtIDIzOjAwIEVEVA0KDQpXZWJFeDogaHR0 cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTliZTQ4MWQxOTk4OGRkMWI1NDVi ZTY3NTlhZWUyNjdiDQpNZWV0aW5nIG51bWJlcjogICAgICAgICAgICA2NDkgMjM1IDQxMQ0KTWVl dGluZyBwYXNzd29yZDogICAgICAgICBKZzY2ZDJwbQ0KSm9pbiBieSBwaG9uZQ0KMS04NzctNjY4 LTQ0OTMgQ2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5hZGEpDQoxLTY1MC00NzktMzIw OCBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpDQpBY2Nlc3MgY29kZTogNjQ5IDIzNSA0 MTENCg0KUXVlc3Rpb25zIGZvciBtZWV0aW5nOg0KDQpTdWJtaXR0ZWQgYnkgKEVyaWMgV3UpDQox LiBSZWRpcmVjdC10by1TcGVjaWZpYy1UdW5uZWwgd2l0aCBCR1AgUGF0aCBBdHRyaWJ1dGUgW1RV Tk5FTEVOQ0FQU11bTVBQXSBhbmQNCiAgUmVkaXJlY3QtdG8tSUlEL0dTSUQsIFJlcXVpcmVkIGJ5 IGRpZmZlcmVudCB1c2UgY2FzZXMsIGNhbiB3ZSBoYXZlIHR3byBkb2NzIGluIElEUiBJbiBwYXJh bGxlbD8NCiAgW0NvbXBhcmlzb24gdG8gUmVkaXJlY3QtdG8tSUlEL0dTSUQgLCBkcmFmdC1oYW8g d2lsbCBoYXZlIG1vcmUgbGl0dGxlIG1vZGlmaWNhdGlvbg0KICB0byBleGlzdGluZyBtZWNoYW5p c21zLCBObyBuZWVkIHRvIGRvIE1hcHBpbmcgL1JlY3Vyc2l2ZSBMb29rdXAuXQ0KDQoyLiAgRm9y IElJRC9HU0lELCBvbmUgbWFwcGluZyB0YWJsZSBmb3INCiAgYWxsIGtpbmRzIG9mIHNlZ21lbnRz L2ZvcndhcmRpbmctZW50aXRpZXMgdnMuIG9uZSBtYXBwaW5nIHRhYmxlDQogIHBlciBzZWdtZW50 cy9mb3J3YXJkaW5nLWVudGl0aWVzIHR5cGUsIHNob3VsZCB3ZSBzdXBwb3J0IGJvdGg/DQoNCkNo YWlyIFF1ZXN0aW9uczoNCg0KMSkgRG9lcyB0aGUgV0cgZmVlbCB3ZSBuZWVkIHRoZSBmb2xsb3dp bmcgZm9yIFJGQzU1NzViaXMgKEREb1MpDQogIGEpIFJlZGlyZWN0aW9uIHRvIFZSRiwNCiAgYikg UmVkaXJlY3Rpb24gdG8gSW5kaXJlY3Rpb24gdG8gSVAsIGFuZA0KICBjKSBSZWRpcmVjdGlvbiB0 byBTZXJ2aWNlIChuZXcpPw0KDQoyKSBJZiB0aGUgV0cgZGVzaXJlcyByZWRpcmVjdGlvbiB0byBT ZXJ2aWNlIHJvdXRpbmcsIGRvZXMgdGhlIFdHIGRlc2lyZQ0KYSkgTmV4dC1Ib3AgdHVubmVsIHN1 cHBvcnQ/IC0NCmIpIE5leHQtSG9wIFRFIFR1bm5lbCBzdXBwb3J0Pw0KIGMpIE5lc3RlZCBUdW5u ZWwgc3VwcG9ydD8NCiBkKSBOZXh0LU5leHQgSG9wIFR1bm5lbCBTdXBwb3J0Pw0KIGUpIFJvdXRl ciBsb2NhbGl6ZWQgVHVubmVsIHJlY3Vyc2lvbj8NCiBmKSBUdW5uZWwgRW5jYXAgUmVjdXJzaW9u Og0KDQozKSBXaGF0IHBpZWNlcyBvZiB0aGUgcHJvcG9zZWQgc29sdXRpb25zIGhhdmUgYmVlbiBp bXBsZW1lbnRlZA0KICAgYW5kL29yIGRlcGxveWVkPw0KDQoNClByZXNlbnRhdGlvbnMgKHByZXJl Y29yZGVkLCBwbGVhc2UgcmV2aWV3IHByaW9yIHRvIG1lZXRpbmcpOg0KLSBkcmFmdC12YW5kZXZl bGRlLWlkci1mbG93c3BlYy1wYXRoLXJlZGlyZWN0DQogIEd1bnRlciBWYW4gRGUgVmVsZGUNCiAg MjEgbWludXRlcw0KICBodHRwczovL2lldGYud2ViZXguY29tL2lldGYvbGRyLnBocD9SQ0lEPWUw MWQ2MjY2MTA4NWY2NjBmNDcwZmVkZGQ5YmYyNjZmDQoNCnByZXNlbnRhdGlvbiBhdDoNCmh0dHBz Oi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzL2ludGVyaW0vMjAxNi8wNS8xNi9pZHIvc2xpZGVz L3NsaWRlcy1pbnRlcmltLTIwMTYtaWRyLTUtMC5wZGYNCg0KDQpkcmFmdC1saS1pZHItZmxvd3Nw ZWMtcmVkaXJlY3QtZ2VuZXJhbGl6ZWQtc2lkDQpFcmljIFd1DQoyMCBtaW51dGVzDQoNClN0cmVh bWluZyByZWNvcmRpbmcgbGluazoNCmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9sZHIucGhw P1JDSUQ9Yzg2MTVhYTg0NTgwMWExZTRiNzljYjE3MDhhMDQ0ODQNCkRvd25sb2FkIHJlY29yZGlu ZyBsaW5rOg0KaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2xzci5waHA/UkNJRD00YmQ1MDQz Mjk3MjdkMmE4MTFjOWNiMGM5YmM3MTNkOA0KDQpwcmVzZW50YXRpb24gYXQ6DQpodHRwczovL3d3 dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy9pbnRlcmltLzIwMTYvMDUvMTYvaWRyL3NsaWRlcy9zbGlk ZXMtaW50ZXJpbS0yMDE2LWlkci01LTEucGRmDQoNCg== --_000_D35B638860D9Eaceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <22A152903DE11343841ADFBD555DC648@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0K SGkgSm9obiwmbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxicj4N CjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KSSB3YXMgYWJsZSB0byBmaW5k IEd1bnRlcuKAmXMgV2ViRXggcmVjb3JkaW5nIHZpYSBhIFVSTCBpbiBvbmUgb2YgdGhlIEUtbWFp bHMgYnV0IG5laXRoZXIgcmVjb3JkaW5nIGxpbmsgaXMgb24gdGhlIG1lZXRpbmcgbWF0ZXJpYWxz IHBhZ2UgYW5kIEnigJlkIGxpa2UgdG8gd2F0Y2ggRXJpY+KAmXMgYXMgd2VsbC4mbmJzcDs8L2Rp dj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdj48Zm9u dCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPmh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRp bmdzL2ludGVyaW0vMjAxNi8wNS8xNi9pZHIvcHJvY2VlZGluZ3MuaHRtbDwvZm9udD48L2Rpdj4N CjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+PC9kaXY+ DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+VGhhbmtzLDwvZm9udD48L2Rp dj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj5BY2VlPC9mb250PjwvZGl2 Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0i T0xLX1NSQ19CT0RZX1NFQ1RJT04iIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8ZGl2IHN0eWxl PSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGlnbjpsZWZ0OyBj b2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRp dW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkct UklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDog bWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0 OmJvbGQiPkZyb206IDwvc3Bhbj5JZHIgJmx0OzxhIGhyZWY9Im1haWx0bzppZHItYm91bmNlc0Bp ZXRmLm9yZyI+aWRyLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgJnF1b3Q7 VmFuIERlIFZlbGRlLCBHdW50ZXIgKE5va2lhIC0gQkUpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWls dG86Z3VudGVyLnZhbl9kZV92ZWxkZUBub2tpYS5jb20iPmd1bnRlci52YW5fZGVfdmVsZGVAbm9r aWEuY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTog PC9zcGFuPkZyaWRheSwgTWF5IDEzLCAyMDE2IGF0IDEwOjU1IEFNPGJyPg0KPHNwYW4gc3R5bGU9 ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+SURSIExpc3QgJmx0OzxhIGhyZWY9Im1haWx0 bzppZHJAaWV0Zi5vcmciPmlkckBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZv bnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogW0lkcl0gSURSIGludGVyaW0gb24g TWF5IDE2dGggLSB3ZWJleCwgcXVlc3Rpb25zIGZvciBtZWV0aW5nLCBhbmQgcmVjb3JkaW5ncy48 YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExP T0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUg c29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8dGl0bGU+ PC90aXRsZT4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNw LW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyBjb2xv cjogcmdiKDAsIDAsIDApOyI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJmb250 LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUnOyI+UHJlLWxpbWluYXIg Y29tbWVudHPigKYuLjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyBmb250LWZh bWlseTogJ0hlbHZldGljYSBOZXVlJzsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1z aXplOiAxNHB4OyBmb250LWZhbWlseTogJ0hlbHZldGljYSBOZXVlJzsiPkJlZm9yZSBlbmdhZ2lu ZyB3aXRoIG15IGZlZWRiYWNrIGFuZCBhZGRyZXNzaW5nIHRoZSBkaXNjdXNzaW9uIHNsaWRlcywg aSB3b3VsZCBsaWtlIHRvIHRoYW5rIGJvdGggU3VlIGFuZCBKb2huIGZvciBnb2luZyB0aHJvdWdo IHRoZSBlZmZvcnQgYW5kIHRpbWUgdG8gdHJ5IHRvIG1ha2UgdGhlIHJlY29yZGluZ3MgYXMgZ29v ZCBhcyBwb3NzaWJsZQ0KIGFuZCBpbnZlc3Rpbmcgbm9uLXRyaXZpYWwgYW1vdW50cyBvZiB0aW1l IHRvIGdldCB0aGUgam9iIGRvbmUuPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDE0cHg7 IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUnOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxl PSJmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUnOyI+SSB3b3Vs ZCBhbHNvIGxpa2UgdG8gdGhhbmtzIEVyaWMgV3UgdG8gZ28gdGhyb3VnaCB0aGUgZXhlcmNpc2Ug b2YgcmVjb3JkaW5nIGhpcyBwcmVzZW50YXRpb24gb2YgdGhlIHNsaWRlcy4gSSB3ZW50IHRocm91 Z2ggdGhlIHNhbWUgZXhlcmNpc2UgYW5kIGV2ZW4gdGhvdWdoIHRoZXJlIHdlcmUgbGVzcyBvcGVy YXRpb25hbCBpc3N1ZXMgdG8gZGVhbA0KIHdpdGggZHVyaW5nIG15IHJlY29yZGluZywgaXQgaXMg YSBub24tdHJpdmlhbCB0YXNrIHRvIHNwZWFrIHRvIGEgc2NyZWVuIGFuZCBub3QgdG8gYW4gYXVk aWVuY2UuJm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDE0cHg7IGZvbnQtZmFt aWx5OiAnSGVsdmV0aWNhIE5ldWUnOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNp emU6IDE0cHg7IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUnOyI+PGJyPg0KPC9kaXY+DQo8 ZGl2IHN0eWxlPSJmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUn OyI+Q29tbWVudHM6IFdvcmtpbmcgc2xpZGVzIGRpc2N1c3Npb24gb2YgdGhlIDE2IE1heSAyMDE2 IEludGVyaW0gSURSIG1lZXRpbmc6PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDE0cHg7 IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUnOyI+LS0tLS0tLS0tLS0tLTwvZGl2Pg0KPGRp diBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogJ0hlbHZldGljYSBOZXVlJzsi Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDE0cHg7 IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUnOyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiBDYWxpYnJpOyI+PGJyPg0KPC9zcGFuPjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJp Ij5UaW1lbGluZSBpbmZvPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj49 PT09PT09PT09PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj48YnI+DQo8 L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPmRy YWZ0LXZhbmRldmVsZGUtaWRyLWZsb3dzcGVjLXBhdGgtcmVkaXJlY3QtMDAgY3JlYXRlZCBvbiAx NCBTZXB0ZW1iZXIgMjAxNTwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+ ZHJhZnQtdmFuZGV2ZWxkZS1pZHItZmxvd3NwZWMtcGF0aC1yZWRpcmVjdC0wMSBjcmVhdGVkIG9u IDEyIEphbnVhcnkgMjAxNjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+ ZHJhZnQtdmFuZGV2ZWxkZS1pZHItZmxvd3NwZWMtcGF0aC1yZWRpcmVjdC0wMiBjcmVhdGVkIG9u IDE3IE1hcmNoIDIwMTY8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPjxi cj4NCjwvZm9udD48L2Rpdj4NCjxkaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPmRyYWZ0 LWxpLWlkci1mbG93c3BlYy1yZWRpcmVjdC1nZW5lcmFsaXplZC1zaWQtMDAgY3JlYXRlZCBvbiAy MSBNYXJjaCAyMDE2PC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2PjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRp dj48Zm9udCBmYWNlPSJDYWxpYnJpIj48YnI+DQo8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZh Y2U9IkNhbGlicmkiPkdlbmVyYWwgc2xpZGUgb2JzZXJ2YXRpb25zIGFib3V0IGRyYWZ0LWxpLWdl bmVyYWxpc2VkLXNpZC0wMCAocmVmLiBkaXNjdXNzaW9uIHNsaWRlIGZvciAxNiBNYXkgMjAxNik8 L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08L2ZvbnQ+PC9kaXY+DQo8 ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPjxicj4NCjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQg ZmFjZT0iQ2FsaWJyaSI+RHJhZnQtbGkgZG9jdW1lbnRzIGEgZmxvd3NwZWMgYWN0aW9uIHVzaW5n IGEgbmV3IGNvbW11bml0eSAoZ2VuZXJhbGl6ZWQtU0lEKS4gVGhlIGV4dGVuZGVkIGNvbW11bml0 eSBwcm92aWRlcyBhIGZsb3dzcGVjIGNsaWVudCBpbmZvcm1hdGlvbiB0byBtYWtlIGEgbG9jYWwg Zm9yd2FyZGluZyBkZWNpc2lvbiBieSBtZWFucyBvZiBhIGxvY2FsIG1hcHBpbmcgdGFibGUuIFRo ZSB0d28gbWFpbiBjb21wb25lbnRzDQogdXNlZCBieSB0aGUgZmxvd3NwZWMgY2xpZW50IGlzOiAo MSkgYW4gaWRlbnRpZmllciBhbmQgKDIpIHNlbWFudGljcy48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pg0K PGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj48YnI+DQo8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+RHJhZnQtdmFuZGV2ZWxkZSBkb2N1bWVudHMg YSBmbG93c3BlYyBhY3Rpb24gdXNpbmcgYSBuZXcgY29tbXVuaXR5IChJbmRpcmVjdGlvbi1JRCku IFRoZSBleHRlbmRlZCBjb21tdW5pdHkgcHJvdmlkZXMgYSBmbG93c3BlYyBjbGllbnQgaW5mb3Jt YXRpb24gdG8gbWFrZSBhIGxvY2FsIGZvcndhcmRpbmcgZGVjaXNpb24gYnkgbWVhbnMgb2YgYSBs b2NhbCBtYXBwaW5nIHRhYmxlLiBUaGUgdHdvIG1haW4NCiBjb21wb25lbnRzIHVzZWQgYnkgdGhl IGZsb3dzcGVjIGNsaWVudCBpczogKDEpIGFuIGlkZW50aWZpZXIgYW5kICgyKSBvcHRpb25hbGx5 IHNlbWFudGljcyAoVGFibGUgc2VtYW50aWNzICYjNDM7IFR1bm5lbC1JRCkuPC9mb250PjwvZGl2 Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj48YnI+DQo8L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2PjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pjxmb250IGZh Y2U9IkNhbGlicmkiPmRyYWZ0LXZhbmRldmVsZGUtaWRyLWZsb3dzcGVjLXBhdGgtcmVkaXJlY3Qt MDImbmJzcDt3YXMgY3JlYXRlZCZuYnNwO+KAnGJlZm9yZSZxdW90OyZuYnNwO2RyYWZ0LWxpLWlk ci1mbG93c3BlYy1yZWRpcmVjdC1nZW5lcmFsaXplZC1zaWQtMDAgYW5kIGFjaGlldmVzIHRoZSBz YW1lIGZ1bmN0aW9uYWxpdHkgYW5kIG1vcmUuIChGb3IgZXhhbXBsZSBkcmFmdC12YW5kZXZlbGRl IGhhcyB0aGUgcG90ZW50aWFsIHRvIHNpZ25hbCA4MTkyIHR5cGVzDQogb2Ygc2VtYW50aWMgbWFw cGluZyB0YWJsZXMgd2hpbGUgZHJhZnQtbGkgaGFzIDI1NSwgYW5vdGhlciBleGFtcGxlIGlzIHRo ZSBUSUQgZmllbGQgd2hpY2ggYWxsb3dzIGR5bmFtaWMgTmV4dC1OZXh0LUhvcCBjb25zdHJ1Y3Rz IHVzZSBmb3IgRVBFIEREb1MgcmVkaXJlY3Rpb24pLjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQg ZmFjZT0iQ2FsaWJyaSI+PGJyPg0KPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxp YnJpIj5EdXJpbmcgV0cgYWRkb3B0aW9uLWNhbGwgMy8yNSB0byA0LzggdGhlIGZvbGxvd2luZyBo YXMgYmVlbiBtZW50aW9uZWQgYnkgSWduYXM6DQo8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3Jn L21haWwtYXJjaGl2ZS93ZWIvaWRyL2N1cnJlbnQvbXNnMTU1MTIuaHRtbCI+aHR0cDovL3d3dy5p ZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2lkci9jdXJyZW50L21zZzE1NTEyLmh0bWw8L2E+PC9m b250PjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogJ0hl bHZldGljYSBOZXVlJzsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaTsiPjxicj4N Cjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTRweDsgZm9udC1mYW1pbHk6 ICdIZWx2ZXRpY2EgTmV1ZSc7IG1hcmdpbi1sZWZ0OiA0MHB4OyI+PGZvbnQgZmFjZT0iQ2FsaWJy aSI+JnF1b3Q7PC9mb250PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogbW9ub3NwYWNlOyBmb250 LXNpemU6IG1lZGl1bTsiPkRyYWZ0LXZhbmRldmVsZGUgY2FuIGFjaGlldmUgYWxsIHdoYXQgZHJh ZnQtaGFvIGFuZCBkcmFmdC1saSBjYW4sIGFuZCBpbiBhIG1vcmUgZmxleGlibGUgd2F5Lg0KIEhh dmluZyB0aGUgYWJpbGl0eSB0byBkZWNvdXBsZSByZWRpcmVjdGlvbjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6IG1vbm9zcGFjZTsgZm9udC1zaXplOiBtZWRpdW07IGJhY2tncm91bmQt Y29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPiB0dW5uZWwgdHlwZSBmcm9tIHJlZGlyZWN0aW9u IGFjdGlvbiBpcyBib3RoIHByYWN0aWNhbCBhbmQgZXh0ZW5zaWJsZSAtIHRoZSBhY3R1YWwgdHVu bmVsIHRvIGJlIHVzZWQgaXMgYSBsb2NhbA0KIG9wZXJhdGlvbmFsIGRlY2lzaW9uIGZvciBlYWNo IG5ldHdvcmsgZWxlbWVudCwgaXQgaXMgbm90IG5lY2Vzc2FyeSBzaWduYWxsZWQgYXQgdGhlIHNh bWUgdGltZSBhbmQgYnkgdGhlIHNhbWUgbWVjaGFuaXNtLiBEZWNvdXBsaW5nIHNpZ25hbGxpbmcg YW5kIHJlZGlyZWN0IHBhcnRzIGFsaWducyB3ZWxsIHRvIG9wZXJhdGlvbmFsIHByYWN0aWNlcyBv ZiB1c2luZyBzcGVjaWZpYyB0b29scyBmb3Igc3BlY2lmaWMgdGFza3MuIEp1c3QgdGhhdCBCR1AN CiBjb3VsZCBkbyB0aGF0IGRvZXMgbm90IG5lY2VzYXNyeSBtZWFuIHRoYXQgaXQgc2hvdWxkIGJl IHVzZWQgYXMgYSBiZXN0IGZpdC4gRnJvbSBvcGVyYXRpb25hbCBwZXJzcGVjdGl2ZSB0aGVyZSBp cyBubyBuZWVkIHRvIGhhdmUgbXVsdGlwbGUgc29sdXRpb25zIHRoYXQgdHJ5IHRvIGFkZHJlc3Mg dGhlIG5hcnJvdyBwcm9ibGVtIHNwYWNlIGluIHNpbWlsYXIgeWV0IGluY29tcGF0aWJsZSB3YXlz LiBUaGVyZSBzaG91bGQgYmUgb25lIGRvY3VtZW50DQogZm9yIHJlZGlyZWN0LCBhbmQgZHJhZnQt dmFuZGV2ZWxkZSBpcyBhIGdvb2Qgc3RhcnRpbmcgYmFzZSBmb3IgdGhhdC4mcXVvdDs8L3NwYW4+ PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiAnSGVsdmV0 aWNhIE5ldWUnOyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpOyI+PHNwYW4gc3R5 bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1MywgMjQ1KTsiPjxicj4NCjwvc3Bhbj48 L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiAn SGVsdmV0aWNhIE5ldWUnOyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyI+PGJyPg0KPC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNp emU6IDE0cHg7Ij4NCjxkaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPkRldGFpbCB2aWV3 OiBzbGlkZSBvYnNlcnZhdGlvbnMgZHJhZnQtbGktZ2VuZXJhbGlzZWQtc2lkLTAwIGRpc2N1c3Np b248L2ZvbnQ+PC9kaXY+DQo8ZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj49PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08L2ZvbnQ+ PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPjxicj4NCjwvZm9udD48L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNl PSJDYWxpYnJpIj5TbGlkZSAyIChvZiB0aGUgZHJhZnQtbGkgcHJlc2VudGF0aW9uKTogSGlzdG9y eSZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPj09 PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj48YnI+DQo8L2ZvbnQ+PC9k aXY+DQo8L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+VGhlIHNsaWRlIGZvcmdldHMg dG8gbWVudGlvbiB0aGF0IGRyYWZ0LXZhbmRldmVsZGUgd2FzIGVuaGFuY2VkIGFuZCBwcm9ncmVz c2VkIGJhc2VkIHVwb24gY29uc3RydWN0aXZlIFdHIGZlZWRiYWNrLiBNdWNoIGZlZWRiYWNrIGhh cyBiZWVuIGludGVncmF0ZWQgYmV0d2VlbiBkcmFmdC12YW5kZXZlbGRlIC0wMCB0byDigJMwMiBC RUZPUkUgZHJhZnTigJNsaSBldmVuIGV4aXN0ZWQuIEZvciBleGFtcGxlOjwvZm9udD48L2Rpdj4N CjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+KiBVc2UtY2FzZSBzY2VuYXJpb+KAmXMgd2VyZSBh ZGRlZDwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+KiAmcXVvdDtQYXRo LWlkJnF1b3Q7IGNoYW5nZWQgdG8gJnF1b3Q7SW5kaXJlY3Rpb24taWQmcXVvdDs8L2ZvbnQ+PC9k aXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPiogQ29uY2VwdCBvZiBJbmRpcmVjdGlvbiB0 YWJsZXMgaGFzIGJlZW4gYWRkZWQgKGhlbmNlIGFkZGluZyB0aGUgY2FwYWJpbGl0eSBvZiBjb250 ZXh0L3NlbWFudGljcyBzaWduYWxsaW5nIGFscmVhZHkgc2luY2UgdmVyc2lvbiAtMDEpPC9mb250 PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj4qIEZsb3dzcGVjIHZhbGlkYXRpb24g aW5mb3JtYXRpb24gaXMgYWRkZWQ8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGli cmkiPiogc2lnbmFsbGluZyBvZiBjb250ZXh0L3NlbWFudGljcyBpcyBhZGRlZCBieSBpbnRyb2R1 Y2luZyBCaW5kaW5nLVNJRCBjb250ZXh0IGlkZW50aWZpZXIgYXMgYSBmaXJzdCBleHRlbnNpb24g b2YgSW5kaXJlY3Rpb24taWQgZXh0ZW5kZWQgY29tbXVuaXR5LjwvZm9udD48L2Rpdj4NCjxkaXY+ PGZvbnQgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNl PSJDYWxpYnJpIj5JdCBpcyBhbiBpbmNvcnJlY3QgYXNzdW1wdGlvbiBvZiBubyBjb250ZXh0IGF3 YXJlbmVzcyBpbiBkcmFmdC12YW5kZXZlbGRlLiBkcmFmdC12YW5kZXZlbGRlLWlkci1mbG93c3Bl Yy1wYXRoLXJlZGlyZWN0IGFkZGVkIGNvbnRleHQgc3VwcG9ydCBiZWZvcmUgZHJhZnQtbGkgZXhp c3RlZCwgYW5kIHJhaXNlcyBxdWVzdGlvbnMgYWJvdXQgbmV3IGVsZW1lbnRzIGV4cG9zZWQgd2l0 aCBkcmFmdC1saSBjb21wYXJlZA0KIHRvIGRyYWZ0LXZhbmRldmVsZGUuPC9mb250PjwvZGl2Pg0K PGRpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KPC9mb250PjwvZGl2Pg0KPGRp dj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjUzLCAyNDUpOyI+PGZv bnQgZmFjZT0iQ2FsaWJyaSI+KGZ3aXcgVGhlIHNlbWFudGljIGF3YXJlbmVzcyBvZiBkcmFmdC12 YW5kZXZlbGRlIGlzIG1lbnRpb25lZCBhbmQgdGhlIHdlYmV4IHJlY29yZGluZyBvZiBkcmFmdC1s aSBiZXR3ZWVuIHJlY29yZGluZyB0aW1lLXN0YW1wcyAxMW0zMHMgdG8gMTNtMzBzKTwvZm9udD48 L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPjxi cj4NCjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KPC9mb250 PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPlNsaWRlIDMgKG9mIHRo ZSBkcmFmdC1saSBwcmVzZW50YXRpb24pPC9mb250PjwvZGl2Pg0KPGRpdj4NCjxkaXY+PGZvbnQg ZmFjZT0iQ2FsaWJyaSI+PT08L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmki Pjxicj4NCjwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj5O byBuZXcgY2FwYWJpbGl0eSBpcyBleHBsYWluZWQgb24gdGhpcyBzbGlkZSBpbiBjb21wYXJpc29u IHdpdGggdGhlIGRyYWZ0LXZhbmRldmVsZGUuPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNl PSJDYWxpYnJpIj5JbiBkcmFmdC12YW5kZXZlbGRlIHRoZSBpbmZvcm1hdGlvbiBmb3VuZCBpbiB0 aGUgaW5kaXJlY3Rpb24taWQgaXMgdXNlZCBvbiBhIGZsb3dzcGVjIGNsaWVudCBpbiBhIGxvY2Fs IG1hcHBpbmctdGFibGUgKGluZGlyZWN0aW9uLWlkIHRhYmxlKSB0byBmaW5kIGxvY2FsIGZvcndh cmRpbmcgaW5mb3JtYXRpb24uIFRoZSBuZXcgZmxvd3NwZWMgZXh0ZW5kZWQgY29tbXVuaXR5IGFz IGRvY3VtZW50ZWQgYnkNCiBkcmFmdC12YW5kZXZlbGRlIGNhbiBwcm92aWRlIGFscmVhZHkgYSBm bG93c3BlYyBjbGllbnQgdGhlIHJlcXVpcmVkIHNlbWFudGljL2NvbnRleHQgaW5mb3JtYXRpb24g KGV4YW1wbGUgaXMgdGhlIOKAmELigJkgYml0KS48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZh Y2U9IkNhbGlicmkiPjxicj4NCjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJy aSI+PGJyPg0KPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj5TbGlkZSA0 IChvZiB0aGUgZHJhZnQtbGkgcHJlc2VudGF0aW9uKTwvZm9udD48L2Rpdj4NCjxkaXY+DQo8ZGl2 Pjxmb250IGZhY2U9IkNhbGlicmkiPj09PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJD YWxpYnJpIj48YnI+DQo8L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2Fs aWJyaSI+VGhlIGdvYWwgb2YgZHJhZnQtbGkgaXMgdG8gZGVmaW5lIGEg4oCcc2VtYW50aWNzIGRl cGVuZGVudOKAnSBhY3Rpb24uPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJp Ij5Ib3dldmVyLCBkcmFmdC12YW5kZXZlbGRlIGFscmVhZHkgYWxsb3dzIHRoYXQgZnVuY3Rpb25h bGl0eSBiZWZvcmUgZHJhZnQtbGkgZXhpc3RlZDwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFj ZT0iQ2FsaWJyaSI+PGJyPg0KPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJp Ij48YnI+DQo8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPlNsaWRlIDUg KG9mIHRoZSBkcmFmdC1saSBwcmVzZW50YXRpb24pPC9mb250PjwvZGl2Pg0KPGRpdj4NCjxkaXY+ PGZvbnQgZmFjZT0iQ2FsaWJyaSI+PT08L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNh bGlicmkiPjxicj4NCjwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxp YnJpIj5EcmFmdC12YW5kZXZlbGRlIGhhcyBpbmRlZWQgdGhlIHBvdGVudGlhbCB0byBiZSB1c2Vk IGluIHN1Y2ggYSBtYW5uZXIuIFRoZSBpbnRlbmQgb2YgdGhpcyBzbGlkZSBhdCB0aGUgdGltZSBv ZiB1c2FnZSB3YXMgdG8gc2hvdyBhbiBleHRyZW1lIGV4YW1wbGUgb2YgdGhlIGZsZXhpYmxpdHkg dGhlIHRlY2hub2xvZ3kgb2ZmZXJzLiBXaGVuIGZvciBleGFtcGxlIHVzaW5nIHJlZGlyZWN0aW9u IHRvIGJpbmRpbmctU0lEDQogKGFzIGRvY3VtZW50ZWQgaW4gbGF0ZXN0IGRyYWZ0LXZhbmRldmVs ZGUpIHRoZW4gdGhlIGxvY2FsIG1hcHBpbmcgdGFibGUgY2FuIGJlIGJhc2VkIGFyb3VuZCB0aGUg c2lnbmFsbGVkIHNlbWFudGljcy48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGli cmkiPjxicj4NCjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+PGJyPg0K PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj5TbGlkZSA2IChvZiB0aGUg ZHJhZnQtbGkgcHJlc2VudGF0aW9uKTwvZm9udD48L2Rpdj4NCjxkaXY+DQo8ZGl2Pjxmb250IGZh Y2U9IkNhbGlicmkiPj09PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj48 YnI+DQo8L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGli cmkiPkRyYWZ0LXZhbmRldmVsZGUgaGFzIDEzIGJpdHMgYXZhaWxhYmxlIGZvciB0eXBlcywgaGVu Y2UgdGhlIHBvdGVudGlhbCB0byBzdXBwb3J0L3NpZ25hbCAyXjEzICg9ODE5MikgdHlwZXMgd2hl biB1c2luZyB0aGUgZmllbGQgYXMgc2NhbGFyIHZhbHVlICh3aGVuIGNvbXBhcmluZyB3aXRoIGEg cG90ZW50aWFsIGZvciAyNTUgdHlwZXMgdXNpbmcgZHJhZnQtbGkpPC9mb250PjwvZGl2Pg0KPGRp dj48Zm9udCBmYWNlPSJDYWxpYnJpIj48YnI+DQo8L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiPlRoZSBjbGFpbSBtYWRlIG9uIHNsaWRlNiB0aGF0 IGRyYWZ0LXZhbmRldmVsZGUgYWxsb3dzIG9ubHkgMTMgdHlwZSBvZiBzZW1hbnRpYyBpbmZvcm1h dGlvbiBpcyB3cm9uZyBhc3N1bXB0aW9uLjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0i Q2FsaWJyaSI+PGJyPg0KPC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj48Zm9udCBm YWNlPSJDYWxpYnJpIj5BdCB0aGUgdGltZSBvZiB3cml0aW5nLCBpdCB3YXMgZm91bmQgdXNlZnVs IHRvIHNpZ25hbCBiaW5kaW5nIFNJRCB1c2VmdWwgc2VtYW50aWMg4oCmIFdlIGRlY2lkZWQgdG8g bGVhdmUgdGhlIHJlbWFpbmluZyBiaXRzIHJlc2VydmVkL29wZW4gZm9yIGRpc2N1c3Npb24gb24g aG93IHRvIGJlc3QgdXNlIHRoZSBmaWVsZCBpbnN0ZWFkLiZuYnNwOzwvZm9udD48L2Rpdj4NCjwv ZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIj5NYXliZSB0aGUgV0cgZmVlbHMgaXQgaXMg YmVzdCB0byB1c2Ugb25seSBhIGZldyBiaXRzIGZvciBzZW1hbnRpY3MgYW5kIGtlZXAgdGhlIHJl bWFpbmRlciByZXNlcnZlZCBmb3IgZnV0dXJlIHVzZS4mbmJzcDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2 Pjxmb250IGZhY2U9IkNhbGlicmkiPjxicj4NCjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFj ZT0iQ2FsaWJyaSI+S2luZCBSZWdhcmRzLDwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0i Q2FsaWJyaSI+Ry88L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9u dC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPjxicj4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsiPjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZv bnQtc2l6ZTogMTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxkaXYg aWQ9Ik1BQ19PVVRMT09LX1NJR05BVFVSRSI+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBz dHlsZT0iZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsi Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIiBzdHlsZT0iZm9u dC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdiBz dHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjEycHQ7IHRleHQtYWxpZ246bGVm dDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDog bWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURE SU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklH SFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdl aWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+SWRyICZsdDs8YSBocmVmPSJtYWlsdG86aWRyLWJvdW5j ZXNAaWV0Zi5vcmciPmlkci1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mIFN1 c2FuIEhhcmVzICZsdDs8YSBocmVmPSJtYWlsdG86c2hhcmVzQG5kemguY29tIj5zaGFyZXNAbmR6 aC5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8 L3NwYW4+RnJpZGF5IDEzIE1heSAyMDE2IGF0IDEyOjQ2PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQt d2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmlkckBpZXRmLm9y ZyI+aWRyQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlkckBpZXRmLm9y ZyI+aWRyQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9s ZCI+U3ViamVjdDogPC9zcGFuPltJZHJdIElEUiBpbnRlcmltIG9uIE1heSAxNnRoIC0gd2ViZXgs IHF1ZXN0aW9ucyBmb3IgbWVldGluZywgYW5kIHJlY29yZGluZ3MuPGJyPg0KPC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9k eSI+DQo8ZGl2IHhtbG5zOnY9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206dm1sIiB4bWxuczpv PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOnc9InVybjpz Y2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOndvcmQiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFz Lm1pY3Jvc29mdC5jb20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMu b3JnL1RSL1JFQy1odG1sNDAiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNy b3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBE ZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFu b3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJD YW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0 O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBk aXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxp Lk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlv cml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1i b3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICov DQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMjQ5OTk2OTIyOw0KCW1zby1saXN0LXR5cGU6aHli cmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTcwODM4MDI1OCA2NzY5ODY4OSA2NzY5ODY5 MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2 NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0OlxGMEI3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDozOC4zNXB0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2 ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgltYXJnaW4tbGVmdDo3NC4zNXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYwQTc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1s ZWZ0OjExMC4zNXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpcRjBCNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MTQ2LjM1cHQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCW1hcmdpbi1sZWZ0OjE4Mi4zNXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYwQTc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0 OjIxOC4zNXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpcRjBCNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjU0LjM1cHQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CW1hcmdpbi1sZWZ0OjI5MC4zNXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYwQTc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjMy Ni4zNXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K b2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PGRpdiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHRpbWUgb2YgdGhlIGlu dGVyaW0gaXMgMjI6MDAtMjM6MDAgRURUIG9uIE1heSAxNjxzdXA+dGg8L3N1cD4uICZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgaW50ZXJpbSB3aWxsIGRpc2N1c3MgdGhlIGZvbGxv d2luZyB0d28gZHJhZnRzIGluIG9yZGVyIHRvIGNyZWF0ZSBhIFdHIHNvbHV0aW9uOg0KPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzguMzVwdDt0ZXh0 LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCEtLVtpZiAhc3VwcG9y dExpc3RzXS0tPjxzcGFuIHN0eWxlPSIiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3 PHNwYW4gc3R5bGU9ImZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1h bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgZm9udC1zaXplOiA3cHQ7IGxpbmUtaGVpZ2h0OiBub3Jt YWw7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCEtLVtl bmRpZl0tLT5kcmFmdC12YW5kZXZlbGRlLWlkci1mbG93c3BlYy1wYXRoLXJlZGlyZWN0LCBhbmQ8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzguMzVwdDt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEi Pg0KPCEtLVtpZiAhc3VwcG9ydExpc3RzXS0tPjxzcGFuIHN0eWxlPSIiPjxzcGFuIHN0eWxlPSJt c28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12 YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgZm9udC1zaXplOiA3cHQ7 IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwv c3Bhbj48L3NwYW4+PCEtLVtlbmRpZl0tLT5kcmFmdC1saS1pZHItZmxvd3NwZWMtcmVkaXJlY3Qt Z2VuZXJhbGl6ZWQtc2lkPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvbWUgb2YgdGhlIFF1ZXN0 aW9ucyB0aGF0IHdpbGwgYmUgZGlzY3VzcyBhcmUgaW5jbHVkZWQgYmVsb3cuJm5ic3A7IFBsZWFz ZSByZXZpZXcgdGhlIHByZS1yZWNvcmRpbmcgcHJlc2VudGF0aW9ucyBwcmlvciB0byB0aGUgbWVl dGluZy4mbmJzcDsmbmJzcDsgVGhlIENoYWlycyBlbmNvdXJhZ2UgZGlzY3Vzc2lvbiBvZiB0aGVz ZSBxdWVzdGlvbnMgb24gdGhlIGxpc3QgYmVmb3JlLCBkdXJpbmcsIGFuZCBhZnRlciB0aGUgbWVl dGluZy4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TdWUgYW5kIEpvaG4gPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPj09PT09PT09PT09PT09PT09PT09PT09PTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj5BZ2VuZGEgZm9yIElEUiBWaXJ0dWFsIEludGVyaW0gTWVldGluZyA8bzpwPjwvbzpw PjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk1heSAxNiwgMjAxNjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+MjI6MDAgLSAyMzowMCBFRFQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2Vi RXg6IDxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW05YmU0 ODFkMTk5ODhkZDFiNTQ1YmU2NzU5YWVlMjY3YiI+DQpodHRwczovL2lldGYud2ViZXguY29tL2ll dGYvai5waHA/TVRJRD1tOWJlNDgxZDE5OTg4ZGQxYjU0NWJlNjc1OWFlZTI2N2I8L2E+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NZWV0aW5nIG51bWJlcjombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg NjQ5IDIzNSA0MTE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1lZXRpbmcg cGFzc3dvcmQ6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IEpnNjZkMnBtPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpvaW4gYnkgcGhvbmU8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEtODc3LTY2OC00NDkzIENhbGwtaW4gdG9sbCBmcmVlIG51 bWJlciAoVVMvQ2FuYWRhKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MS02 NTAtNDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKTxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWNjZXNzIGNvZGU6IDY0OSAyMzUgNDExPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPlF1ZXN0aW9ucyBmb3IgbWVldGluZzogPG86cD48L286cD48L2I+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5TdWJtaXR0ZWQgYnkgKEVyaWMgV3UpPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4xLiBSZWRpcmVjdC10by1TcGVjaWZpYy1UdW5uZWwgd2l0aCBCR1Ag UGF0aCBBdHRyaWJ1dGUgW1RVTk5FTEVOQ0FQU11bTVBQXSBhbmQNCjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7UmVkaXJlY3QtdG8tSUlEL0dTSUQsIFJl cXVpcmVkIGJ5IGRpZmZlcmVudCB1c2UgY2FzZXMsIGNhbiB3ZSBoYXZlIHR3byBkb2NzIGluIElE UiBJbiBwYXJhbGxlbD8NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7Jm5ic3A7W0NvbXBhcmlzb24gdG8gUmVkaXJlY3QtdG8tSUlEL0dTSUQgLCBkcmFmdC1oYW8g d2lsbCBoYXZlIG1vcmUgbGl0dGxlIG1vZGlmaWNhdGlvbg0KPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDt0byBleGlzdGluZyBtZWNoYW5pc21zLCBObyBu ZWVkIHRvIGRvIE1hcHBpbmcgL1JlY3Vyc2l2ZSBMb29rdXAuXTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4yLiZuYnNwOyBGb3IgSUlEL0dTSUQsIG9uZSBtYXBwaW5nIHRhYmxlIGZvciA8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwO2FsbCBraW5kcyBvZiBz ZWdtZW50cy9mb3J3YXJkaW5nLWVudGl0aWVzIHZzLiBvbmUgbWFwcGluZyB0YWJsZQ0KPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDtwZXIgc2VnbWVudHMv Zm9yd2FyZGluZy1lbnRpdGllcyB0eXBlLCBzaG91bGQgd2Ugc3VwcG9ydCBib3RoPzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj5DaGFpciBRdWVzdGlvbnM6IDxvOnA+PC9vOnA+PC9iPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+MSkgRG9lcyB0aGUgV0cgZmVlbCB3ZSBuZWVkIHRoZSBmb2xsb3dpbmcgZm9yIFJG QzU1NzViaXMgKEREb1MpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDsgYSkgUmVkaXJlY3Rpb24gdG8gVlJGLCA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyZuYnNwO2IpIFJlZGlyZWN0aW9uIHRvIEluZGlyZWN0aW9uIHRvIElQLCBh bmQgJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJz cDtjKSBSZWRpcmVjdGlvbiB0byBTZXJ2aWNlIChuZXcpPyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+MikgSWYgdGhlIFdHIGRlc2lyZXMgcmVkaXJlY3Rpb24gdG8gU2VydmljZSByb3V0 aW5nLCBkb2VzIHRoZSBXRyBkZXNpcmU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPmEpIE5leHQtSG9wIHR1bm5lbCBzdXBwb3J0PyAtPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5iKSBOZXh0LUhvcCBURSBUdW5uZWwgc3VwcG9ydD8gPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDtjKSBOZXN0ZWQgVHVubmVsIHN1cHBvcnQ/ IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ZCkgTmV4dC1OZXh0 IEhvcCBUdW5uZWwgU3VwcG9ydD8gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDtlKSBSb3V0ZXIgbG9jYWxpemVkIFR1bm5lbCByZWN1cnNpb24/IDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ZikgVHVubmVsIEVuY2FwIFJlY3Vyc2lv bjogPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjMpIFdoYXQgcGllY2VzIG9mIHRoZSBwcm9wb3Nl ZCBzb2x1dGlvbnMgaGF2ZSBiZWVuIGltcGxlbWVudGVkPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgYW5kL29yIGRlcGxveWVkPyZuYnNwOyZuYnNwOyA8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj5QcmVzZW50YXRpb25zIChwcmVyZWNvcmRlZCwgcGxlYXNlIHJldmlldyBw cmlvciB0byBtZWV0aW5nKTo8bzpwPjwvbzpwPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4tIGRyYWZ0LXZhbmRldmVsZGUtaWRyLWZsb3dzcGVjLXBhdGgtcmVkaXJlY3Q8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBHdW50ZXIgVmFuIERlIFZlbGRlPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgMjEgbWludXRlczxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8v aWV0Zi53ZWJleC5jb20vaWV0Zi9sZHIucGhwP1JDSUQ9ZTAxZDYyNjYxMDg1ZjY2MGY0NzBmZWRk ZDliZjI2NmYiPg0KaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2xkci5waHA/UkNJRD1lMDFk NjI2NjEwODVmNjYwZjQ3MGZlZGRkOWJmMjY2ZjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ cHJlc2VudGF0aW9uIGF0OiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzL2ludGVyaW0vMjAxNi8wNS8x Ni9pZHIvc2xpZGVzL3NsaWRlcy1pbnRlcmltLTIwMTYtaWRyLTUtMC5wZGYiPmh0dHBzOi8vd3d3 LmlldGYub3JnL3Byb2NlZWRpbmdzL2ludGVyaW0vMjAxNi8wNS8xNi9pZHIvc2xpZGVzL3NsaWRl cy1pbnRlcmltLTIwMTYtaWRyLTUtMC5wZGY8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZHJhZnQtbGktaWRyLWZs b3dzcGVjLXJlZGlyZWN0LWdlbmVyYWxpemVkLXNpZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+RXJpYyBXdSA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjIwIG1pbnV0ZXMgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN0cmVhbWluZyByZWNvcmRpbmcg bGluazo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBz Oi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9sZHIucGhwP1JDSUQ9Yzg2MTVhYTg0NTgwMWExZTRiNzlj YjE3MDhhMDQ0ODQiPmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9sZHIucGhwP1JDSUQ9Yzg2 MTVhYTg0NTgwMWExZTRiNzljYjE3MDhhMDQ0ODQ8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Eb3dubG9hZCByZWNvcmRpbmcgbGluazo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9s c3IucGhwP1JDSUQ9NGJkNTA0MzI5NzI3ZDJhODExYzljYjBjOWJjNzEzZDgiPmh0dHBzOi8vaWV0 Zi53ZWJleC5jb20vaWV0Zi9sc3IucGhwP1JDSUQ9NGJkNTA0MzI5NzI3ZDJhODExYzljYjBjOWJj NzEzZDg8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnByZXNlbnRhdGlvbiBhdDogPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9wcm9jZWVkaW5ncy9pbnRlcmltLzIwMTYvMDUvMTYvaWRyL3NsaWRlcy9zbGlkZXMtaW50 ZXJpbS0yMDE2LWlkci01LTEucGRmIj5odHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy9p bnRlcmltLzIwMTYvMDUvMTYvaWRyL3NsaWRlcy9zbGlkZXMtaW50ZXJpbS0yMDE2LWlkci01LTEu cGRmPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+PC9zcGFuPjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D35B638860D9Eaceeciscocom_-- From nobody Fri May 13 08:47:06 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E2FFF12B060; Fri, 13 May 2016 08:47:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160513154702.10520.1114.idtracker@ietfa.amsl.com> Date: Fri, 13 May 2016 08:47:02 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-psarkar-idr-bgp-ls-node-admin-tag-extension-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 15:47:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : Advertising Node Admin Tags in BGP Link-State Advertisements Authors : Pushpasis Sarkar Hannes Gredler Stephane Litkowski Filename : draft-psarkar-idr-bgp-ls-node-admin-tag-extension-04.txt Pages : 11 Date : 2016-05-13 Abstract: This document describes the protocol extensions to collect node administrative tags adevertised in IGP Link State advertisements and disseminate the same in BGP Link-State advertisement protocol, to facilitate inter-AS TE applications that may need the same node administrative tags to associate a subset of network devices spanning across more than one AS with a specific functionality. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-psarkar-idr-bgp-ls-node-admin-tag-extension/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-psarkar-idr-bgp-ls-node-admin-tag-extension-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-psarkar-idr-bgp-ls-node-admin-tag-extension-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 13 08:52:01 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11AE312D59D for ; Fri, 13 May 2016 08:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.739 X-Spam-Level: * X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNwE3v38Ge_D for ; Fri, 13 May 2016 08:51:57 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B373B12D187 for ; Fri, 13 May 2016 08:51:56 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.238; From: "Susan Hares" To: "'Acee Lindem \(acee\)'" References: <008a01d1ad04$c63a77d0$52af6770$@ndzh.com> <9F087909-60F3-4F5C-8427-C0BD2A4ED9FF@alcatel-lucent.com> In-Reply-To: Date: Fri, 13 May 2016 11:51:49 -0400 Message-ID: <00b601d1ad2f$5cbbe160$1633a420$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B7_01D1AD0D.D5B31B00" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQL9VAfH3qNrgami4jswlczYdF2oYwJJl/SIAmaezPadOjQ/QA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] IDR interim on May 16th - webex, questions for meeting, and recordings. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 15:52:00 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00B7_01D1AD0D.D5B31B00 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Acee: =20 The link for Eric=E2=80=99s talk is the message you copies (see below) = and I included here:=20 =20 Streaming recording link: https://ietf.webex.com/ietf/ldr.php?RCID=3Dc8615aa845801a1e4b79cb1708a044= 84 Download recording link: https://ietf.webex.com/ietf/lsr.php?RCID=3D4bd504329727d2a811c9cb0c9bc713= d8 =20 The location:=20 https://www.ietf.org/proceedings/interim/2016/05/16/idr/agenda/agenda-int= erim-2016-idr-5 =20 on the Agenda has both links.=20 =20 Sue=20 =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Acee Lindem (acee) Sent: Friday, May 13, 2016 11:01 AM To: Van De Velde, Gunter (Nokia - BE); idr@ietf.org; John Scudder Subject: Re: [Idr] IDR interim on May 16th - webex, questions for = meeting, and recordings. =20 Hi John,=20 =20 I was able to find Gunter=E2=80=99s WebEx recording via a URL in one of = the E-mails but neither recording link is on the meeting materials page = and I=E2=80=99d like to watch Eric=E2=80=99s as well.=20 =20 https://www.ietf.org/proceedings/interim/2016/05/16/idr/proceedings.html =20 Thanks, Acee =20 From: Idr on behalf of "Van De Velde, Gunter = (Nokia - BE)" Date: Friday, May 13, 2016 at 10:55 AM To: IDR List Subject: Re: [Idr] IDR interim on May 16th - webex, questions for = meeting, and recordings. =20 Pre-liminar comments=E2=80=A6.. =20 Before engaging with my feedback and addressing the discussion slides, i = would like to thank both Sue and John for going through the effort and = time to try to make the recordings as good as possible and investing = non-trivial amounts of time to get the job done. =20 I would also like to thanks Eric Wu to go through the exercise of = recording his presentation of the slides. I went through the same = exercise and even though there were less operational issues to deal with = during my recording, it is a non-trivial task to speak to a screen and = not to an audience.=20 =20 =20 Comments: Working slides discussion of the 16 May 2016 Interim IDR = meeting: ------------- =20 =20 Timeline info =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 draft-vandevelde-idr-flowspec-path-redirect-00 created on 14 September = 2015 draft-vandevelde-idr-flowspec-path-redirect-01 created on 12 January = 2016 draft-vandevelde-idr-flowspec-path-redirect-02 created on 17 March 2016 =20 draft-li-idr-flowspec-redirect-generalized-sid-00 created on 21 March = 2016 =20 =20 General slide observations about draft-li-generalised-sid-00 (ref. = discussion slide for 16 May 2016) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D =20 Draft-li documents a flowspec action using a new community = (generalized-SID). The extended community provides a flowspec client = information to make a local forwarding decision by means of a local = mapping table. The two main components used by the flowspec client is: = (1) an identifier and (2) semantics. =20 Draft-vandevelde documents a flowspec action using a new community = (Indirection-ID). The extended community provides a flowspec client = information to make a local forwarding decision by means of a local = mapping table. The two main components used by the flowspec client is: = (1) an identifier and (2) optionally semantics (Table semantics + = Tunnel-ID). =20 draft-vandevelde-idr-flowspec-path-redirect-02 was created = =E2=80=9Cbefore" draft-li-idr-flowspec-redirect-generalized-sid-00 and = achieves the same functionality and more. (For example draft-vandevelde = has the potential to signal 8192 types of semantic mapping tables while = draft-li has 255, another example is the TID field which allows dynamic = Next-Next-Hop constructs use for EPE DDoS redirection). =20 During WG addoption-call 3/25 to 4/8 the following has been mentioned by = Ignas: http://www.ietf.org/mail-archive/web/idr/current/msg15512.html =20 "Draft-vandevelde can achieve all what draft-hao and draft-li can, and = in a more flexible way. Having the ability to decouple redirection = tunnel type from redirection action is both practical and extensible - = the actual tunnel to be used is a local operational decision for each = network element, it is not necessary signalled at the same time and by = the same mechanism. Decoupling signalling and redirect parts aligns well = to operational practices of using specific tools for specific tasks. = Just that BGP could do that does not necesasry mean that it should be = used as a best fit. From operational perspective there is no need to = have multiple solutions that try to address the narrow problem space in = similar yet incompatible ways. There should be one document for = redirect, and draft-vandevelde is a good starting base for that." =20 =20 Detail view: slide observations draft-li-generalised-sid-00 discussion =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D =20 Slide 2 (of the draft-li presentation): History=20 =3D=3D =20 The slide forgets to mention that draft-vandevelde was enhanced and = progressed based upon constructive WG feedback. Much feedback has been = integrated between draft-vandevelde -00 to =E2=80=9302 BEFORE = draft=E2=80=93li even existed. For example: * Use-case scenario=E2=80=99s were added * "Path-id" changed to "Indirection-id" * Concept of Indirection tables has been added (hence adding the = capability of context/semantics signalling already since version -01) * Flowspec validation information is added * signalling of context/semantics is added by introducing Binding-SID = context identifier as a first extension of Indirection-id extended = community. =20 It is an incorrect assumption of no context awareness in = draft-vandevelde. draft-vandevelde-idr-flowspec-path-redirect added = context support before draft-li existed, and raises questions about new = elements exposed with draft-li compared to draft-vandevelde. =20 (fwiw The semantic awareness of draft-vandevelde is mentioned and the = webex recording of draft-li between recording time-stamps 11m30s to = 13m30s) =20 =20 Slide 3 (of the draft-li presentation) =3D=3D =20 No new capability is explained on this slide in comparison with the = draft-vandevelde. In draft-vandevelde the information found in the indirection-id is used = on a flowspec client in a local mapping-table (indirection-id table) to = find local forwarding information. The new flowspec extended community = as documented by draft-vandevelde can provide already a flowspec client = the required semantic/context information (example is the = =E2=80=98B=E2=80=99 bit). =20 =20 Slide 4 (of the draft-li presentation) =3D=3D =20 The goal of draft-li is to define a =E2=80=9Csemantics = dependent=E2=80=9D action. However, draft-vandevelde already allows that functionality before = draft-li existed =20 =20 Slide 5 (of the draft-li presentation) =3D=3D =20 Draft-vandevelde has indeed the potential to be used in such a manner. = The intend of this slide at the time of usage was to show an extreme = example of the flexiblity the technology offers. When for example using = redirection to binding-SID (as documented in latest draft-vandevelde) = then the local mapping table can be based around the signalled = semantics. =20 =20 Slide 6 (of the draft-li presentation) =3D=3D =20 Draft-vandevelde has 13 bits available for types, hence the potential to = support/signal 2^13 (=3D8192) types when using the field as scalar value = (when comparing with a potential for 255 types using draft-li) =20 The claim made on slide6 that draft-vandevelde allows only 13 type of = semantic information is wrong assumption. =20 At the time of writing, it was found useful to signal binding SID useful = semantic =E2=80=A6 We decided to leave the remaining bits reserved/open = for discussion on how to best use the field instead.=20 Maybe the WG feels it is best to use only a few bits for semantics and = keep the remainder reserved for future use.=20 =20 Kind Regards, G/ =20 =20 =20 From: Idr on behalf of Susan Hares = Date: Friday 13 May 2016 at 12:46 To: "idr@ietf.org" Subject: [Idr] IDR interim on May 16th - webex, questions for meeting, = and recordings. =20 The time of the interim is 22:00-23:00 EDT on May 16th. =20 =20 The interim will discuss the following two drafts in order to create a = WG solution:=20 =20 =C2=B7 draft-vandevelde-idr-flowspec-path-redirect, and =C2=B7 draft-li-idr-flowspec-redirect-generalized-sid =20 Some of the Questions that will be discuss are included below. Please = review the pre-recording presentations prior to the meeting. The = Chairs encourage discussion of these questions on the list before, = during, and after the meeting.=20 =20 Sue and John=20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 Agenda for IDR Virtual Interim Meeting=20 =20 May 16, 2016 22:00 - 23:00 EDT =20 WebEx: = https://ietf.webex.com/ietf/j.php?MTID=3Dm9be481d19988dd1b545be6759aee267= b Meeting number: 649 235 411 Meeting password: Jg66d2pm Join by phone 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 649 235 411 =20 Questions for meeting:=20 =20 Submitted by (Eric Wu) 1. Redirect-to-Specific-Tunnel with BGP Path Attribute = [TUNNELENCAPS][MPP] and=20 Redirect-to-IID/GSID, Required by different use cases, can we have two = docs in IDR In parallel?=20 [Comparison to Redirect-to-IID/GSID , draft-hao will have more little = modification=20 to existing mechanisms, No need to do Mapping /Recursive Lookup.] =20 2. For IID/GSID, one mapping table for=20 all kinds of segments/forwarding-entities vs. one mapping table=20 per segments/forwarding-entities type, should we support both? =20 Chair Questions:=20 =20 1) Does the WG feel we need the following for RFC5575bis (DDoS) a) Redirection to VRF,=20 b) Redirection to Indirection to IP, and =20 c) Redirection to Service (new)?=20 =20 2) If the WG desires redirection to Service routing, does the WG desire a) Next-Hop tunnel support? - b) Next-Hop TE Tunnel support?=20 c) Nested Tunnel support?=20 d) Next-Next Hop Tunnel Support?=20 e) Router localized Tunnel recursion?=20 f) Tunnel Encap Recursion:=20 =20 3) What pieces of the proposed solutions have been implemented and/or deployed? =20 =20 =20 Presentations (prerecorded, please review prior to meeting): - draft-vandevelde-idr-flowspec-path-redirect Gunter Van De Velde 21 minutes = https://ietf.webex.com/ietf/ldr.php?RCID=3De01d62661085f660f470feddd9bf26= 6f =20 presentation at:=20 https://www.ietf.org/proceedings/interim/2016/05/16/idr/slides/slides-int= erim-2016-idr-5-0.pdf =20 =20 draft-li-idr-flowspec-redirect-generalized-sid Eric Wu=20 20 minutes=20 =20 Streaming recording link: https://ietf.webex.com/ietf/ldr.php?RCID=3Dc8615aa845801a1e4b79cb1708a044= 84 Download recording link: https://ietf.webex.com/ietf/lsr.php?RCID=3D4bd504329727d2a811c9cb0c9bc713= d8 =20 presentation at:=20 https://www.ietf.org/proceedings/interim/2016/05/16/idr/slides/slides-int= erim-2016-idr-5-1.pdf =20 ------=_NextPart_000_00B7_01D1AD0D.D5B31B00 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Acee:

 

The link for = Eric=E2=80=99s talk is the message you copies (see below) and I included = here:

 

Streaming recording = link:

https://ietf.webex.com/ietf/ldr.php?RCID=3Dc8615aa845801a1e4b= 79cb1708a04484

Download recording link:

https://ietf.webex.com/ietf/lsr.php?RCID=3D4bd504329727d2a811= c9cb0c9bc713d8

 

The location: =

https://www.ietf.org/proceedings/interim/2016/05= /16/idr/agenda/agenda-interim-2016-idr-5

 

on the Agenda has both = links.

 

Sue =

 

From:= = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Acee Lindem = (acee)
Sent: Friday, May 13, 2016 11:01 AM
To: Van = De Velde, Gunter (Nokia - BE); idr@ietf.org; John = Scudder
Subject: Re: [Idr] IDR interim on May 16th - webex, = questions for meeting, and = recordings.

 

Hi = John, 

 

=

I = was able to find Gunter=E2=80=99s WebEx recording via a URL in one of = the E-mails but neither recording link is on the meeting materials page = and I=E2=80=99d like to watch Eric=E2=80=99s as = well. 

 

=

 

Thanks,

Acee

 

=

From: = Idr <idr-bounces@ietf.org> on = behalf of "Van De Velde, Gunter (Nokia - BE)" <gunter.van_de_velde@nokia.c= om>
Date: Friday, May 13, 2016 at 10:55 AM
To: = IDR List <idr@ietf.org>
Subject: Re: = [Idr] IDR interim on May 16th - webex, questions for meeting, and = recordings.

 

=
<= p class=3DMsoNormal>Pre-liminar = comments=E2=80=A6..

 

Before engaging with my feedback and = addressing the discussion slides, i would like to thank both Sue and = John for going through the effort and time to try to make the recordings = as good as possible and investing non-trivial amounts of time to get the = job done.

 

I would also like to thanks Eric Wu to go = through the exercise of recording his presentation of the slides. I went = through the same exercise and even though there were less operational = issues to deal with during my recording, it is a non-trivial task to = speak to a screen and not to an = audience. 

 

 

Comments: Working slides discussion of the 16 = May 2016 Interim IDR meeting:

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

=

 

 

Timeline = info

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

=

draft-vandevelde-idr-flowspec-path= -redirect-00 created on 14 September = 2015

draft-vandevelde-idr-flowspec-path= -redirect-01 created on 12 January = 2016

draft-vandevelde-idr-flowspec-path= -redirect-02 created on 17 March 2016

 

=

draft-li-idr-flowspec-redirect-gen= eralized-sid-00 created on 21 March = 2016

 

=

 

=

General slide observations about = draft-li-generalised-sid-00 (ref. discussion slide for 16 May = 2016)

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

=

Draft-li documents a flowspec = action using a new community (generalized-SID). The extended community = provides a flowspec client information to make a local forwarding = decision by means of a local mapping table. The two main components used = by the flowspec client is: (1) an identifier and (2) = semantics.

 

=

Draft-vandevelde documents a = flowspec action using a new community (Indirection-ID). The extended = community provides a flowspec client information to make a local = forwarding decision by means of a local mapping table. The two main = components used by the flowspec client is: (1) an identifier and (2) = optionally semantics (Table semantics + = Tunnel-ID).

 

=

draft-vandevelde-idr-flowspec-path= -redirect-02 was = created =E2=80=9Cbefore" draft-li-idr-flowspec-redirect-ge= neralized-sid-00 and achieves the same functionality and more. (For = example draft-vandevelde has the potential to signal 8192 types of = semantic mapping tables while draft-li has 255, another example is the = TID field which allows dynamic Next-Next-Hop constructs use for EPE DDoS = redirection).

 

=

During WG addoption-call 3/25 to = 4/8 the following has been mentioned by Ignas: h= ttp://www.ietf.org/mail-archive/web/idr/current/msg15512.html

 

"Draft-vandevelde can achieve all what draft-hao and = draft-li can, and in a more flexible way. Having the ability to decouple = redirection tunnel type from = redirection action is both practical and extensible - the actual tunnel = to be used is a local operational decision for each network element, it = is not necessary signalled at the same time and by the same mechanism. = Decoupling signalling and redirect parts aligns well to operational = practices of using specific tools for specific tasks. Just that BGP = could do that does not necesasry mean that it should be used as a best = fit. From operational perspective there is no need to have multiple = solutions that try to address the narrow problem space in similar yet = incompatible ways. There should be one document for redirect, and = draft-vandevelde is a good starting base for = that."

 

 

<= div>

Detail view: slide observations = draft-li-generalised-sid-00 = discussion

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

=

Slide 2 (of the draft-li = presentation): History 

=3D=3D

=

 

=

The slide forgets to mention that = draft-vandevelde was enhanced and progressed based upon constructive WG = feedback. Much feedback has been integrated between draft-vandevelde -00 = to =E2=80=9302 BEFORE draft=E2=80=93li even existed. For = example:

* Use-case scenario=E2=80=99s = were added

* "Path-id" changed to = "Indirection-id"

* Concept = of Indirection tables has been added (hence adding the capability of = context/semantics signalling already since version = -01)

* Flowspec validation information = is added

* signalling of context/semantics = is added by introducing Binding-SID context identifier as a first = extension of Indirection-id extended = community.

 

=

It is an incorrect assumption of = no context awareness in draft-vandevelde. = draft-vandevelde-idr-flowspec-path-redirect added context support before = draft-li existed, and raises questions about new elements exposed with = draft-li compared to = draft-vandevelde.

 

=

(fwiw The = semantic awareness of draft-vandevelde is mentioned and the webex = recording of draft-li between recording time-stamps 11m30s to = 13m30s)

=

 

=

 

=

Slide 3 (of the draft-li = presentation)

=3D=3D

=

 

=

No new capability is explained on = this slide in comparison with the = draft-vandevelde.

In = draft-vandevelde the information found in the indirection-id is used on = a flowspec client in a local mapping-table (indirection-id table) to = find local forwarding information. The new flowspec extended community = as documented by draft-vandevelde can provide already a flowspec client = the required semantic/context information (example is the = =E2=80=98B=E2=80=99 bit).

 

=

 

=

Slide 4 (of the draft-li = presentation)

=3D=3D

=

 

=

The goal of draft-li is to define = a =E2=80=9Csemantics dependent=E2=80=9D = action.

However, draft-vandevelde already = allows that functionality before draft-li = existed

 

=

 

=

Slide 5 (of the draft-li = presentation)

=3D=3D

=

 

=

Draft-vandevelde has indeed the = potential to be used in such a manner. The intend of this slide at the = time of usage was to show an extreme example of the flexiblity the = technology offers. When for example using redirection to binding-SID (as = documented in latest draft-vandevelde) then the local mapping table can = be based around the signalled = semantics.

 

=

 

=

Slide 6 (of the draft-li = presentation)

=3D=3D

=

 

=

Draft-vandevelde has 13 bits = available for types, hence the potential to support/signal 2^13 = (=3D8192) types when using the field as scalar value (when comparing = with a potential for 255 types using = draft-li)

 

=

The claim made on slide6 that = draft-vandevelde allows only 13 type of semantic information is wrong = assumption.

 

=

At the time of writing, it was = found useful to signal binding SID useful semantic =E2=80=A6 We decided = to leave the remaining bits reserved/open for discussion on how to best = use the field instead. 

Maybe the = WG feels it is best to use only a few bits for semantics and keep the = remainder reserved for future = use. 

 

=

Kind = Regards,

G/

 

=

 

=

 

=

From: = Idr <idr-bounces@ietf.org> on = behalf of Susan Hares <shares@ndzh.com>
Date: = Friday 13 May 2016 at 12:46
To: "idr@ietf.org" <idr@ietf.org>
Subject: = [Idr] IDR interim on May 16th - webex, questions for meeting, and = recordings.

<= p class=3DMsoNormal> 

=

The time of = the interim is 22:00-23:00 EDT on May 16th. =  

 

The interim will discuss = the following two drafts in order to create a WG solution: =

 

=C2=B7         = draft-vandevelde-idr-flowspec-path-redirect, = and

=C2=B7         = draft-li-idr-flowspec-redirect-generalized-sid=

 

Some of the Questions that = will be discuss are included below.  Please review the = pre-recording presentations prior to the meeting.   The Chairs = encourage discussion of these questions on the list before, during, and = after the meeting.

 

Sue and John =

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D

 

Agenda for IDR Virtual = Interim Meeting

 

May 16, = 2016

22:00 - 23:00 EDT

 

WebEx: https://ietf.webex.com/ietf/j.php?MTID=3Dm9be481d19988dd1b545b= e6759aee267b

Meeting = number:           = 649 235 411

Meeting = password:         = Jg66d2pm

Join by phone

1-877-668-4493 Call-in = toll free number (US/Canada)

1-650-479-3208 Call-in = toll number (US/Canada)

Access code: 649 235 411

 

Questions for meeting: =

 

Submitted by (Eric = Wu)

1. Redirect-to-Specific-Tunnel with BGP Path = Attribute [TUNNELENCAPS][MPP] and

  Redirect-to-IID/GSID, Required by = different use cases, can we have two docs in IDR In parallel? =

  [Comparison to Redirect-to-IID/GSID , = draft-hao will have more little modification

  to existing = mechanisms, No need to do Mapping /Recursive = Lookup.]

 

2.  For IID/GSID, one = mapping table for

  all kinds of = segments/forwarding-entities vs. one mapping table =

  per segments/forwarding-entities type, = should we support both?

 

Chair Questions: =

 

1) Does the WG feel we = need the following for RFC5575bis (DDoS)

  a) Redirection to = VRF,

  b) Redirection to Indirection to IP, = and  

  c) Redirection to Service (new)? =

  

2) If the WG desires = redirection to Service routing, does the WG = desire

a) Next-Hop tunnel support? = -

b) Next-Hop TE Tunnel support? =

 c) Nested Tunnel support? =

 d) Next-Next Hop Tunnel Support? =

 e) Router localized Tunnel recursion? =

 f) Tunnel Encap Recursion: =

 

3) What pieces of the = proposed solutions have been implemented

   and/or = deployed?  

 

 

Presentations = (prerecorded, please review prior to meeting):

- = draft-vandevelde-idr-flowspec-path-redirect

  Gunter Van De = Velde

  21 minutes

  https://ietf.webex.com/ietf/ldr.php?RCID=3De01d62661085f660f4= 70feddd9bf266f

 

presentation at: =

https://www.ietf.org/proceedings/interim/2= 016/05/16/idr/slides/slides-interim-2016-idr-5-0.pdf

 

 

draft-li-idr-flowspec-redirect-generalized-sid=

Eric = Wu

20 minutes

 

Streaming recording = link:

https://ietf.webex.com/ietf/ldr.php?RCID=3Dc8615aa845801a1e4b= 79cb1708a04484

Download recording link:

https://ietf.webex.com/ietf/lsr.php?RCID=3D4bd504329727d2a811= c9cb0c9bc713d8

 

presentation at: =

https://www.ietf.org/proceedings/interim/2= 016/05/16/idr/slides/slides-interim-2016-idr-5-1.pdf

 

------=_NextPart_000_00B7_01D1AD0D.D5B31B00-- From nobody Fri May 13 11:37:40 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A13B212B03F for ; Fri, 13 May 2016 11:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFnnTFtnJ92H for ; Fri, 13 May 2016 11:37:35 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B83DF12D0A0 for ; Fri, 13 May 2016 11:37:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=68963; q=dns/txt; s=iport; t=1463164653; x=1464374253; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=hPsJV4Z7M6+t+Sy3GCe4vLhJ9L5bNbE2KWIuKli+9fM=; b=XJBf8XwlWVrN0xorXad/9hLnLy42V/3diQyFnQQx1kiRqIg4cgs8iW7q rVewc516PPbWvy3YeQdpmVAWSaEosYTG+N6nKia/YO3pjrL1W8ahf1B+i VFaUXnDJQRmIa9QUYyXjLXpaV+HJ9hov08ZGdPmNokOkV/b0O1Av2f5ao A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A6AAB1HTZX/4MNJK1EFwOCbEtVfgaCd?= =?us-ascii?q?rZcAQ2BDQVkJIVtAhyBETgUAQEBAQEBAWUnhEIBAQECAgwOCQo5Ew4CAgEGAg4?= =?us-ascii?q?DAwEBARUECAEDAwMCAgIZFxQJBwEBAQEDDgUJCweIFA4sk06dHYUNi30BAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEcBYptgTkBgmgBAQwmCQEVEQeCMoJZBYd+izKEdwG?= =?us-ascii?q?FfYJ4hSiBaYRPh0aBG49AAR4BAUKCBg0OFmpLbgEEhxkHFwcYfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,614,1454976000"; d="scan'208,217";a="271451726" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 May 2016 18:37:32 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u4DIbVjp014997 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 May 2016 18:37:32 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 13 May 2016 14:37:31 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Fri, 13 May 2016 14:37:31 -0400 From: "Acee Lindem (acee)" To: Susan Hares Thread-Topic: [Idr] IDR interim on May 16th - webex, questions for meeting, and recordings. Thread-Index: AdGtA5N1fQH6ZeaQT8WhQMAKvH+1FwAI/l2AAAAqUoAACis7gP//6zcA Date: Fri, 13 May 2016 18:37:30 +0000 Message-ID: References: <008a01d1ad04$c63a77d0$52af6770$@ndzh.com> <9F087909-60F3-4F5C-8427-C0BD2A4ED9FF@alcatel-lucent.com> <00b601d1ad2f$5cbbe160$1633a420$@ndzh.com> In-Reply-To: <00b601d1ad2f$5cbbe160$1633a420$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: multipart/alternative; boundary="_000_D35B96FF60EDEaceeciscocom_" MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] IDR interim on May 16th - webex, questions for meeting, and recordings. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 18:37:39 -0000 --_000_D35B96FF60EDEaceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIFN1ZSAtIEnigJl2ZSB3YXRjaGVkIGl0IGFzIHdlbGwgYW5kIHdvdWxkIGFkdmlzZSBv dGhlcnMgdG8gc2tpcCB0aGUgZmlyc3QgNyBtaW51dGVzIHNpbmNlIGl0IHJlYWxseSBkb2VzbuKA mXQgc3RhcnQgdW50aWwgdGhlbi4NCkFjZWUNCg0KRnJvbTogU3VzYW4gSGFyZXMgPHNoYXJlc0Bu ZHpoLmNvbTxtYWlsdG86c2hhcmVzQG5kemguY29tPj4NCkRhdGU6IEZyaWRheSwgTWF5IDEzLCAy MDE2IGF0IDExOjUxIEFNDQpUbzogQWNlZSBMaW5kZW0gPGFjZWVAY2lzY28uY29tPG1haWx0bzph Y2VlQGNpc2NvLmNvbT4+DQpDYzogSURSIExpc3QgPGlkckBpZXRmLm9yZzxtYWlsdG86aWRyQGll dGYub3JnPj4sIEpvaG4gU2N1ZGRlciA8amdzQGp1bmlwZXIubmV0PG1haWx0bzpqZ3NAanVuaXBl ci5uZXQ+Pg0KU3ViamVjdDogUkU6IFtJZHJdIElEUiBpbnRlcmltIG9uIE1heSAxNnRoIC0gd2Vi ZXgsIHF1ZXN0aW9ucyBmb3IgbWVldGluZywgYW5kIHJlY29yZGluZ3MuDQoNCkFjZWU6DQoNClRo ZSBsaW5rIGZvciBFcmlj4oCZcyB0YWxrIGlzIHRoZSBtZXNzYWdlIHlvdSBjb3BpZXMgKHNlZSBi ZWxvdykgYW5kIEkgaW5jbHVkZWQgaGVyZToNCg0KU3RyZWFtaW5nIHJlY29yZGluZyBsaW5rOg0K aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2xkci5waHA/UkNJRD1jODYxNWFhODQ1ODAxYTFl NGI3OWNiMTcwOGEwNDQ4NA0KRG93bmxvYWQgcmVjb3JkaW5nIGxpbms6DQpodHRwczovL2lldGYu d2ViZXguY29tL2lldGYvbHNyLnBocD9SQ0lEPTRiZDUwNDMyOTcyN2QyYTgxMWM5Y2IwYzliYzcx M2Q4DQoNClRoZSBsb2NhdGlvbjoNCmh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzL2lu dGVyaW0vMjAxNi8wNS8xNi9pZHIvYWdlbmRhL2FnZW5kYS1pbnRlcmltLTIwMTYtaWRyLTUNCg0K b24gdGhlIEFnZW5kYSBoYXMgYm90aCBsaW5rcy4NCg0KU3VlDQoNCkZyb206IElkciBbbWFpbHRv Omlkci1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWNlZSBMaW5kZW0gKGFjZWUpDQpT ZW50OiBGcmlkYXksIE1heSAxMywgMjAxNiAxMTowMSBBTQ0KVG86IFZhbiBEZSBWZWxkZSwgR3Vu dGVyIChOb2tpYSAtIEJFKTsgaWRyQGlldGYub3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+OyBKb2hu IFNjdWRkZXINClN1YmplY3Q6IFJlOiBbSWRyXSBJRFIgaW50ZXJpbSBvbiBNYXkgMTZ0aCAtIHdl YmV4LCBxdWVzdGlvbnMgZm9yIG1lZXRpbmcsIGFuZCByZWNvcmRpbmdzLg0KDQpIaSBKb2huLA0K DQpJIHdhcyBhYmxlIHRvIGZpbmQgR3VudGVy4oCZcyBXZWJFeCByZWNvcmRpbmcgdmlhIGEgVVJM IGluIG9uZSBvZiB0aGUgRS1tYWlscyBidXQgbmVpdGhlciByZWNvcmRpbmcgbGluayBpcyBvbiB0 aGUgbWVldGluZyBtYXRlcmlhbHMgcGFnZSBhbmQgSeKAmWQgbGlrZSB0byB3YXRjaCBFcmlj4oCZ cyBhcyB3ZWxsLg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy9pbnRlcmltLzIw MTYvMDUvMTYvaWRyL3Byb2NlZWRpbmdzLmh0bWwNCg0KVGhhbmtzLA0KQWNlZQ0KDQpGcm9tOiBJ ZHIgPGlkci1ib3VuY2VzQGlldGYub3JnPG1haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZz4+IG9u IGJlaGFsZiBvZiAiVmFuIERlIFZlbGRlLCBHdW50ZXIgKE5va2lhIC0gQkUpIiA8Z3VudGVyLnZh bl9kZV92ZWxkZUBub2tpYS5jb208bWFpbHRvOmd1bnRlci52YW5fZGVfdmVsZGVAbm9raWEuY29t Pj4NCkRhdGU6IEZyaWRheSwgTWF5IDEzLCAyMDE2IGF0IDEwOjU1IEFNDQpUbzogSURSIExpc3Qg PGlkckBpZXRmLm9yZzxtYWlsdG86aWRyQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbSWRyXSBJ RFIgaW50ZXJpbSBvbiBNYXkgMTZ0aCAtIHdlYmV4LCBxdWVzdGlvbnMgZm9yIG1lZXRpbmcsIGFu ZCByZWNvcmRpbmdzLg0KDQpQcmUtbGltaW5hciBjb21tZW50c+KApi4uDQoNCkJlZm9yZSBlbmdh Z2luZyB3aXRoIG15IGZlZWRiYWNrIGFuZCBhZGRyZXNzaW5nIHRoZSBkaXNjdXNzaW9uIHNsaWRl cywgaSB3b3VsZCBsaWtlIHRvIHRoYW5rIGJvdGggU3VlIGFuZCBKb2huIGZvciBnb2luZyB0aHJv dWdoIHRoZSBlZmZvcnQgYW5kIHRpbWUgdG8gdHJ5IHRvIG1ha2UgdGhlIHJlY29yZGluZ3MgYXMg Z29vZCBhcyBwb3NzaWJsZSBhbmQgaW52ZXN0aW5nIG5vbi10cml2aWFsIGFtb3VudHMgb2YgdGlt ZSB0byBnZXQgdGhlIGpvYiBkb25lLg0KDQpJIHdvdWxkIGFsc28gbGlrZSB0byB0aGFua3MgRXJp YyBXdSB0byBnbyB0aHJvdWdoIHRoZSBleGVyY2lzZSBvZiByZWNvcmRpbmcgaGlzIHByZXNlbnRh dGlvbiBvZiB0aGUgc2xpZGVzLiBJIHdlbnQgdGhyb3VnaCB0aGUgc2FtZSBleGVyY2lzZSBhbmQg ZXZlbiB0aG91Z2ggdGhlcmUgd2VyZSBsZXNzIG9wZXJhdGlvbmFsIGlzc3VlcyB0byBkZWFsIHdp dGggZHVyaW5nIG15IHJlY29yZGluZywgaXQgaXMgYSBub24tdHJpdmlhbCB0YXNrIHRvIHNwZWFr IHRvIGEgc2NyZWVuIGFuZCBub3QgdG8gYW4gYXVkaWVuY2UuDQoNCg0KQ29tbWVudHM6IFdvcmtp bmcgc2xpZGVzIGRpc2N1c3Npb24gb2YgdGhlIDE2IE1heSAyMDE2IEludGVyaW0gSURSIG1lZXRp bmc6DQotLS0tLS0tLS0tLS0tDQoNCg0KVGltZWxpbmUgaW5mbw0KPT09PT09PT09PQ0KDQpkcmFm dC12YW5kZXZlbGRlLWlkci1mbG93c3BlYy1wYXRoLXJlZGlyZWN0LTAwIGNyZWF0ZWQgb24gMTQg U2VwdGVtYmVyIDIwMTUNCmRyYWZ0LXZhbmRldmVsZGUtaWRyLWZsb3dzcGVjLXBhdGgtcmVkaXJl Y3QtMDEgY3JlYXRlZCBvbiAxMiBKYW51YXJ5IDIwMTYNCmRyYWZ0LXZhbmRldmVsZGUtaWRyLWZs b3dzcGVjLXBhdGgtcmVkaXJlY3QtMDIgY3JlYXRlZCBvbiAxNyBNYXJjaCAyMDE2DQoNCmRyYWZ0 LWxpLWlkci1mbG93c3BlYy1yZWRpcmVjdC1nZW5lcmFsaXplZC1zaWQtMDAgY3JlYXRlZCBvbiAy MSBNYXJjaCAyMDE2DQoNCg0KR2VuZXJhbCBzbGlkZSBvYnNlcnZhdGlvbnMgYWJvdXQgZHJhZnQt bGktZ2VuZXJhbGlzZWQtc2lkLTAwIChyZWYuIGRpc2N1c3Npb24gc2xpZGUgZm9yIDE2IE1heSAy MDE2KQ0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0KDQpEcmFmdC1saSBkb2N1bWVudHMgYSBmbG93c3BlYyBhY3Rpb24gdXNpbmcgYSBu ZXcgY29tbXVuaXR5IChnZW5lcmFsaXplZC1TSUQpLiBUaGUgZXh0ZW5kZWQgY29tbXVuaXR5IHBy b3ZpZGVzIGEgZmxvd3NwZWMgY2xpZW50IGluZm9ybWF0aW9uIHRvIG1ha2UgYSBsb2NhbCBmb3J3 YXJkaW5nIGRlY2lzaW9uIGJ5IG1lYW5zIG9mIGEgbG9jYWwgbWFwcGluZyB0YWJsZS4gVGhlIHR3 byBtYWluIGNvbXBvbmVudHMgdXNlZCBieSB0aGUgZmxvd3NwZWMgY2xpZW50IGlzOiAoMSkgYW4g aWRlbnRpZmllciBhbmQgKDIpIHNlbWFudGljcy4NCg0KRHJhZnQtdmFuZGV2ZWxkZSBkb2N1bWVu dHMgYSBmbG93c3BlYyBhY3Rpb24gdXNpbmcgYSBuZXcgY29tbXVuaXR5IChJbmRpcmVjdGlvbi1J RCkuIFRoZSBleHRlbmRlZCBjb21tdW5pdHkgcHJvdmlkZXMgYSBmbG93c3BlYyBjbGllbnQgaW5m b3JtYXRpb24gdG8gbWFrZSBhIGxvY2FsIGZvcndhcmRpbmcgZGVjaXNpb24gYnkgbWVhbnMgb2Yg YSBsb2NhbCBtYXBwaW5nIHRhYmxlLiBUaGUgdHdvIG1haW4gY29tcG9uZW50cyB1c2VkIGJ5IHRo ZSBmbG93c3BlYyBjbGllbnQgaXM6ICgxKSBhbiBpZGVudGlmaWVyIGFuZCAoMikgb3B0aW9uYWxs eSBzZW1hbnRpY3MgKFRhYmxlIHNlbWFudGljcyArIFR1bm5lbC1JRCkuDQoNCmRyYWZ0LXZhbmRl dmVsZGUtaWRyLWZsb3dzcGVjLXBhdGgtcmVkaXJlY3QtMDIgd2FzIGNyZWF0ZWQg4oCcYmVmb3Jl IiBkcmFmdC1saS1pZHItZmxvd3NwZWMtcmVkaXJlY3QtZ2VuZXJhbGl6ZWQtc2lkLTAwIGFuZCBh Y2hpZXZlcyB0aGUgc2FtZSBmdW5jdGlvbmFsaXR5IGFuZCBtb3JlLiAoRm9yIGV4YW1wbGUgZHJh ZnQtdmFuZGV2ZWxkZSBoYXMgdGhlIHBvdGVudGlhbCB0byBzaWduYWwgODE5MiB0eXBlcyBvZiBz ZW1hbnRpYyBtYXBwaW5nIHRhYmxlcyB3aGlsZSBkcmFmdC1saSBoYXMgMjU1LCBhbm90aGVyIGV4 YW1wbGUgaXMgdGhlIFRJRCBmaWVsZCB3aGljaCBhbGxvd3MgZHluYW1pYyBOZXh0LU5leHQtSG9w IGNvbnN0cnVjdHMgdXNlIGZvciBFUEUgRERvUyByZWRpcmVjdGlvbikuDQoNCkR1cmluZyBXRyBh ZGRvcHRpb24tY2FsbCAzLzI1IHRvIDQvOCB0aGUgZm9sbG93aW5nIGhhcyBiZWVuIG1lbnRpb25l ZCBieSBJZ25hczogaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2lkci9jdXJy ZW50L21zZzE1NTEyLmh0bWwNCg0KIkRyYWZ0LXZhbmRldmVsZGUgY2FuIGFjaGlldmUgYWxsIHdo YXQgZHJhZnQtaGFvIGFuZCBkcmFmdC1saSBjYW4sIGFuZCBpbiBhIG1vcmUgZmxleGlibGUgd2F5 LiBIYXZpbmcgdGhlIGFiaWxpdHkgdG8gZGVjb3VwbGUgcmVkaXJlY3Rpb24gdHVubmVsIHR5cGUg ZnJvbSByZWRpcmVjdGlvbiBhY3Rpb24gaXMgYm90aCBwcmFjdGljYWwgYW5kIGV4dGVuc2libGUg LSB0aGUgYWN0dWFsIHR1bm5lbCB0byBiZSB1c2VkIGlzIGEgbG9jYWwgb3BlcmF0aW9uYWwgZGVj aXNpb24gZm9yIGVhY2ggbmV0d29yayBlbGVtZW50LCBpdCBpcyBub3QgbmVjZXNzYXJ5IHNpZ25h bGxlZCBhdCB0aGUgc2FtZSB0aW1lIGFuZCBieSB0aGUgc2FtZSBtZWNoYW5pc20uIERlY291cGxp bmcgc2lnbmFsbGluZyBhbmQgcmVkaXJlY3QgcGFydHMgYWxpZ25zIHdlbGwgdG8gb3BlcmF0aW9u YWwgcHJhY3RpY2VzIG9mIHVzaW5nIHNwZWNpZmljIHRvb2xzIGZvciBzcGVjaWZpYyB0YXNrcy4g SnVzdCB0aGF0IEJHUCBjb3VsZCBkbyB0aGF0IGRvZXMgbm90IG5lY2VzYXNyeSBtZWFuIHRoYXQg aXQgc2hvdWxkIGJlIHVzZWQgYXMgYSBiZXN0IGZpdC4gRnJvbSBvcGVyYXRpb25hbCBwZXJzcGVj dGl2ZSB0aGVyZSBpcyBubyBuZWVkIHRvIGhhdmUgbXVsdGlwbGUgc29sdXRpb25zIHRoYXQgdHJ5 IHRvIGFkZHJlc3MgdGhlIG5hcnJvdyBwcm9ibGVtIHNwYWNlIGluIHNpbWlsYXIgeWV0IGluY29t cGF0aWJsZSB3YXlzLiBUaGVyZSBzaG91bGQgYmUgb25lIGRvY3VtZW50IGZvciByZWRpcmVjdCwg YW5kIGRyYWZ0LXZhbmRldmVsZGUgaXMgYSBnb29kIHN0YXJ0aW5nIGJhc2UgZm9yIHRoYXQuIg0K DQoNCkRldGFpbCB2aWV3OiBzbGlkZSBvYnNlcnZhdGlvbnMgZHJhZnQtbGktZ2VuZXJhbGlzZWQt c2lkLTAwIGRpc2N1c3Npb24NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQ0KDQpTbGlkZSAyIChvZiB0aGUgZHJhZnQtbGkgcHJlc2VudGF0 aW9uKTogSGlzdG9yeQ0KPT0NCg0KVGhlIHNsaWRlIGZvcmdldHMgdG8gbWVudGlvbiB0aGF0IGRy YWZ0LXZhbmRldmVsZGUgd2FzIGVuaGFuY2VkIGFuZCBwcm9ncmVzc2VkIGJhc2VkIHVwb24gY29u c3RydWN0aXZlIFdHIGZlZWRiYWNrLiBNdWNoIGZlZWRiYWNrIGhhcyBiZWVuIGludGVncmF0ZWQg YmV0d2VlbiBkcmFmdC12YW5kZXZlbGRlIC0wMCB0byDigJMwMiBCRUZPUkUgZHJhZnTigJNsaSBl dmVuIGV4aXN0ZWQuIEZvciBleGFtcGxlOg0KKiBVc2UtY2FzZSBzY2VuYXJpb+KAmXMgd2VyZSBh ZGRlZA0KKiAiUGF0aC1pZCIgY2hhbmdlZCB0byAiSW5kaXJlY3Rpb24taWQiDQoqIENvbmNlcHQg b2YgSW5kaXJlY3Rpb24gdGFibGVzIGhhcyBiZWVuIGFkZGVkIChoZW5jZSBhZGRpbmcgdGhlIGNh cGFiaWxpdHkgb2YgY29udGV4dC9zZW1hbnRpY3Mgc2lnbmFsbGluZyBhbHJlYWR5IHNpbmNlIHZl cnNpb24gLTAxKQ0KKiBGbG93c3BlYyB2YWxpZGF0aW9uIGluZm9ybWF0aW9uIGlzIGFkZGVkDQoq IHNpZ25hbGxpbmcgb2YgY29udGV4dC9zZW1hbnRpY3MgaXMgYWRkZWQgYnkgaW50cm9kdWNpbmcg QmluZGluZy1TSUQgY29udGV4dCBpZGVudGlmaWVyIGFzIGEgZmlyc3QgZXh0ZW5zaW9uIG9mIElu ZGlyZWN0aW9uLWlkIGV4dGVuZGVkIGNvbW11bml0eS4NCg0KSXQgaXMgYW4gaW5jb3JyZWN0IGFz c3VtcHRpb24gb2Ygbm8gY29udGV4dCBhd2FyZW5lc3MgaW4gZHJhZnQtdmFuZGV2ZWxkZS4gZHJh ZnQtdmFuZGV2ZWxkZS1pZHItZmxvd3NwZWMtcGF0aC1yZWRpcmVjdCBhZGRlZCBjb250ZXh0IHN1 cHBvcnQgYmVmb3JlIGRyYWZ0LWxpIGV4aXN0ZWQsIGFuZCByYWlzZXMgcXVlc3Rpb25zIGFib3V0 IG5ldyBlbGVtZW50cyBleHBvc2VkIHdpdGggZHJhZnQtbGkgY29tcGFyZWQgdG8gZHJhZnQtdmFu ZGV2ZWxkZS4NCg0KKGZ3aXcgVGhlIHNlbWFudGljIGF3YXJlbmVzcyBvZiBkcmFmdC12YW5kZXZl bGRlIGlzIG1lbnRpb25lZCBhbmQgdGhlIHdlYmV4IHJlY29yZGluZyBvZiBkcmFmdC1saSBiZXR3 ZWVuIHJlY29yZGluZyB0aW1lLXN0YW1wcyAxMW0zMHMgdG8gMTNtMzBzKQ0KDQoNClNsaWRlIDMg KG9mIHRoZSBkcmFmdC1saSBwcmVzZW50YXRpb24pDQo9PQ0KDQpObyBuZXcgY2FwYWJpbGl0eSBp cyBleHBsYWluZWQgb24gdGhpcyBzbGlkZSBpbiBjb21wYXJpc29uIHdpdGggdGhlIGRyYWZ0LXZh bmRldmVsZGUuDQpJbiBkcmFmdC12YW5kZXZlbGRlIHRoZSBpbmZvcm1hdGlvbiBmb3VuZCBpbiB0 aGUgaW5kaXJlY3Rpb24taWQgaXMgdXNlZCBvbiBhIGZsb3dzcGVjIGNsaWVudCBpbiBhIGxvY2Fs IG1hcHBpbmctdGFibGUgKGluZGlyZWN0aW9uLWlkIHRhYmxlKSB0byBmaW5kIGxvY2FsIGZvcndh cmRpbmcgaW5mb3JtYXRpb24uIFRoZSBuZXcgZmxvd3NwZWMgZXh0ZW5kZWQgY29tbXVuaXR5IGFz IGRvY3VtZW50ZWQgYnkgZHJhZnQtdmFuZGV2ZWxkZSBjYW4gcHJvdmlkZSBhbHJlYWR5IGEgZmxv d3NwZWMgY2xpZW50IHRoZSByZXF1aXJlZCBzZW1hbnRpYy9jb250ZXh0IGluZm9ybWF0aW9uIChl eGFtcGxlIGlzIHRoZSDigJhC4oCZIGJpdCkuDQoNCg0KU2xpZGUgNCAob2YgdGhlIGRyYWZ0LWxp IHByZXNlbnRhdGlvbikNCj09DQoNClRoZSBnb2FsIG9mIGRyYWZ0LWxpIGlzIHRvIGRlZmluZSBh IOKAnHNlbWFudGljcyBkZXBlbmRlbnTigJ0gYWN0aW9uLg0KSG93ZXZlciwgZHJhZnQtdmFuZGV2 ZWxkZSBhbHJlYWR5IGFsbG93cyB0aGF0IGZ1bmN0aW9uYWxpdHkgYmVmb3JlIGRyYWZ0LWxpIGV4 aXN0ZWQNCg0KDQpTbGlkZSA1IChvZiB0aGUgZHJhZnQtbGkgcHJlc2VudGF0aW9uKQ0KPT0NCg0K RHJhZnQtdmFuZGV2ZWxkZSBoYXMgaW5kZWVkIHRoZSBwb3RlbnRpYWwgdG8gYmUgdXNlZCBpbiBz dWNoIGEgbWFubmVyLiBUaGUgaW50ZW5kIG9mIHRoaXMgc2xpZGUgYXQgdGhlIHRpbWUgb2YgdXNh Z2Ugd2FzIHRvIHNob3cgYW4gZXh0cmVtZSBleGFtcGxlIG9mIHRoZSBmbGV4aWJsaXR5IHRoZSB0 ZWNobm9sb2d5IG9mZmVycy4gV2hlbiBmb3IgZXhhbXBsZSB1c2luZyByZWRpcmVjdGlvbiB0byBi aW5kaW5nLVNJRCAoYXMgZG9jdW1lbnRlZCBpbiBsYXRlc3QgZHJhZnQtdmFuZGV2ZWxkZSkgdGhl biB0aGUgbG9jYWwgbWFwcGluZyB0YWJsZSBjYW4gYmUgYmFzZWQgYXJvdW5kIHRoZSBzaWduYWxs ZWQgc2VtYW50aWNzLg0KDQoNClNsaWRlIDYgKG9mIHRoZSBkcmFmdC1saSBwcmVzZW50YXRpb24p DQo9PQ0KDQpEcmFmdC12YW5kZXZlbGRlIGhhcyAxMyBiaXRzIGF2YWlsYWJsZSBmb3IgdHlwZXMs IGhlbmNlIHRoZSBwb3RlbnRpYWwgdG8gc3VwcG9ydC9zaWduYWwgMl4xMyAoPTgxOTIpIHR5cGVz IHdoZW4gdXNpbmcgdGhlIGZpZWxkIGFzIHNjYWxhciB2YWx1ZSAod2hlbiBjb21wYXJpbmcgd2l0 aCBhIHBvdGVudGlhbCBmb3IgMjU1IHR5cGVzIHVzaW5nIGRyYWZ0LWxpKQ0KDQpUaGUgY2xhaW0g bWFkZSBvbiBzbGlkZTYgdGhhdCBkcmFmdC12YW5kZXZlbGRlIGFsbG93cyBvbmx5IDEzIHR5cGUg b2Ygc2VtYW50aWMgaW5mb3JtYXRpb24gaXMgd3JvbmcgYXNzdW1wdGlvbi4NCg0KQXQgdGhlIHRp bWUgb2Ygd3JpdGluZywgaXQgd2FzIGZvdW5kIHVzZWZ1bCB0byBzaWduYWwgYmluZGluZyBTSUQg dXNlZnVsIHNlbWFudGljIOKApiBXZSBkZWNpZGVkIHRvIGxlYXZlIHRoZSByZW1haW5pbmcgYml0 cyByZXNlcnZlZC9vcGVuIGZvciBkaXNjdXNzaW9uIG9uIGhvdyB0byBiZXN0IHVzZSB0aGUgZmll bGQgaW5zdGVhZC4NCk1heWJlIHRoZSBXRyBmZWVscyBpdCBpcyBiZXN0IHRvIHVzZSBvbmx5IGEg ZmV3IGJpdHMgZm9yIHNlbWFudGljcyBhbmQga2VlcCB0aGUgcmVtYWluZGVyIHJlc2VydmVkIGZv ciBmdXR1cmUgdXNlLg0KDQpLaW5kIFJlZ2FyZHMsDQpHLw0KDQoNCg0KRnJvbTogSWRyIDxpZHIt Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYg b2YgU3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbTxtYWlsdG86c2hhcmVzQG5kemguY29tPj4N CkRhdGU6IEZyaWRheSAxMyBNYXkgMjAxNiBhdCAxMjo0Ng0KVG86ICJpZHJAaWV0Zi5vcmc8bWFp bHRvOmlkckBpZXRmLm9yZz4iIDxpZHJAaWV0Zi5vcmc8bWFpbHRvOmlkckBpZXRmLm9yZz4+DQpT dWJqZWN0OiBbSWRyXSBJRFIgaW50ZXJpbSBvbiBNYXkgMTZ0aCAtIHdlYmV4LCBxdWVzdGlvbnMg Zm9yIG1lZXRpbmcsIGFuZCByZWNvcmRpbmdzLg0KDQpUaGUgdGltZSBvZiB0aGUgaW50ZXJpbSBp cyAyMjowMC0yMzowMCBFRFQgb24gTWF5IDE2dGguDQoNClRoZSBpbnRlcmltIHdpbGwgZGlzY3Vz cyB0aGUgZm9sbG93aW5nIHR3byBkcmFmdHMgaW4gb3JkZXIgdG8gY3JlYXRlIGEgV0cgc29sdXRp b246DQoNCg0KwrcgICAgICAgICBkcmFmdC12YW5kZXZlbGRlLWlkci1mbG93c3BlYy1wYXRoLXJl ZGlyZWN0LCBhbmQNCg0KwrcgICAgICAgICBkcmFmdC1saS1pZHItZmxvd3NwZWMtcmVkaXJlY3Qt Z2VuZXJhbGl6ZWQtc2lkDQoNClNvbWUgb2YgdGhlIFF1ZXN0aW9ucyB0aGF0IHdpbGwgYmUgZGlz Y3VzcyBhcmUgaW5jbHVkZWQgYmVsb3cuICBQbGVhc2UgcmV2aWV3IHRoZSBwcmUtcmVjb3JkaW5n IHByZXNlbnRhdGlvbnMgcHJpb3IgdG8gdGhlIG1lZXRpbmcuICAgVGhlIENoYWlycyBlbmNvdXJh Z2UgZGlzY3Vzc2lvbiBvZiB0aGVzZSBxdWVzdGlvbnMgb24gdGhlIGxpc3QgYmVmb3JlLCBkdXJp bmcsIGFuZCBhZnRlciB0aGUgbWVldGluZy4NCg0KU3VlIGFuZCBKb2huDQoNCj09PT09PT09PT09 PT09PT09PT09PT09PQ0KDQpBZ2VuZGEgZm9yIElEUiBWaXJ0dWFsIEludGVyaW0gTWVldGluZw0K DQpNYXkgMTYsIDIwMTYNCjIyOjAwIC0gMjM6MDAgRURUDQoNCldlYkV4OiBodHRwczovL2lldGYu d2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tOWJlNDgxZDE5OTg4ZGQxYjU0NWJlNjc1OWFlZTI2 N2INCk1lZXRpbmcgbnVtYmVyOiAgICAgICAgICAgIDY0OSAyMzUgNDExDQpNZWV0aW5nIHBhc3N3 b3JkOiAgICAgICAgIEpnNjZkMnBtDQpKb2luIGJ5IHBob25lDQoxLTg3Ny02NjgtNDQ5MyBDYWxs LWluIHRvbGwgZnJlZSBudW1iZXIgKFVTL0NhbmFkYSkNCjEtNjUwLTQ3OS0zMjA4IENhbGwtaW4g dG9sbCBudW1iZXIgKFVTL0NhbmFkYSkNCkFjY2VzcyBjb2RlOiA2NDkgMjM1IDQxMQ0KDQpRdWVz dGlvbnMgZm9yIG1lZXRpbmc6DQoNClN1Ym1pdHRlZCBieSAoRXJpYyBXdSkNCjEuIFJlZGlyZWN0 LXRvLVNwZWNpZmljLVR1bm5lbCB3aXRoIEJHUCBQYXRoIEF0dHJpYnV0ZSBbVFVOTkVMRU5DQVBT XVtNUFBdIGFuZA0KICBSZWRpcmVjdC10by1JSUQvR1NJRCwgUmVxdWlyZWQgYnkgZGlmZmVyZW50 IHVzZSBjYXNlcywgY2FuIHdlIGhhdmUgdHdvIGRvY3MgaW4gSURSIEluIHBhcmFsbGVsPw0KICBb Q29tcGFyaXNvbiB0byBSZWRpcmVjdC10by1JSUQvR1NJRCAsIGRyYWZ0LWhhbyB3aWxsIGhhdmUg bW9yZSBsaXR0bGUgbW9kaWZpY2F0aW9uDQogIHRvIGV4aXN0aW5nIG1lY2hhbmlzbXMsIE5vIG5l ZWQgdG8gZG8gTWFwcGluZyAvUmVjdXJzaXZlIExvb2t1cC5dDQoNCjIuICBGb3IgSUlEL0dTSUQs IG9uZSBtYXBwaW5nIHRhYmxlIGZvcg0KICBhbGwga2luZHMgb2Ygc2VnbWVudHMvZm9yd2FyZGlu Zy1lbnRpdGllcyB2cy4gb25lIG1hcHBpbmcgdGFibGUNCiAgcGVyIHNlZ21lbnRzL2ZvcndhcmRp bmctZW50aXRpZXMgdHlwZSwgc2hvdWxkIHdlIHN1cHBvcnQgYm90aD8NCg0KQ2hhaXIgUXVlc3Rp b25zOg0KDQoxKSBEb2VzIHRoZSBXRyBmZWVsIHdlIG5lZWQgdGhlIGZvbGxvd2luZyBmb3IgUkZD NTU3NWJpcyAoRERvUykNCiAgYSkgUmVkaXJlY3Rpb24gdG8gVlJGLA0KICBiKSBSZWRpcmVjdGlv biB0byBJbmRpcmVjdGlvbiB0byBJUCwgYW5kDQogIGMpIFJlZGlyZWN0aW9uIHRvIFNlcnZpY2Ug KG5ldyk/DQoNCjIpIElmIHRoZSBXRyBkZXNpcmVzIHJlZGlyZWN0aW9uIHRvIFNlcnZpY2Ugcm91 dGluZywgZG9lcyB0aGUgV0cgZGVzaXJlDQphKSBOZXh0LUhvcCB0dW5uZWwgc3VwcG9ydD8gLQ0K YikgTmV4dC1Ib3AgVEUgVHVubmVsIHN1cHBvcnQ/DQogYykgTmVzdGVkIFR1bm5lbCBzdXBwb3J0 Pw0KIGQpIE5leHQtTmV4dCBIb3AgVHVubmVsIFN1cHBvcnQ/DQogZSkgUm91dGVyIGxvY2FsaXpl ZCBUdW5uZWwgcmVjdXJzaW9uPw0KIGYpIFR1bm5lbCBFbmNhcCBSZWN1cnNpb246DQoNCjMpIFdo YXQgcGllY2VzIG9mIHRoZSBwcm9wb3NlZCBzb2x1dGlvbnMgaGF2ZSBiZWVuIGltcGxlbWVudGVk DQogICBhbmQvb3IgZGVwbG95ZWQ/DQoNCg0KUHJlc2VudGF0aW9ucyAocHJlcmVjb3JkZWQsIHBs ZWFzZSByZXZpZXcgcHJpb3IgdG8gbWVldGluZyk6DQotIGRyYWZ0LXZhbmRldmVsZGUtaWRyLWZs b3dzcGVjLXBhdGgtcmVkaXJlY3QNCiAgR3VudGVyIFZhbiBEZSBWZWxkZQ0KICAyMSBtaW51dGVz DQogIGh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9sZHIucGhwP1JDSUQ9ZTAxZDYyNjYxMDg1 ZjY2MGY0NzBmZWRkZDliZjI2NmYNCg0KcHJlc2VudGF0aW9uIGF0Og0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvcHJvY2VlZGluZ3MvaW50ZXJpbS8yMDE2LzA1LzE2L2lkci9zbGlkZXMvc2xpZGVzLWlu dGVyaW0tMjAxNi1pZHItNS0wLnBkZg0KDQoNCmRyYWZ0LWxpLWlkci1mbG93c3BlYy1yZWRpcmVj dC1nZW5lcmFsaXplZC1zaWQNCkVyaWMgV3UNCjIwIG1pbnV0ZXMNCg0KU3RyZWFtaW5nIHJlY29y ZGluZyBsaW5rOg0KaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2xkci5waHA/UkNJRD1jODYx NWFhODQ1ODAxYTFlNGI3OWNiMTcwOGEwNDQ4NA0KRG93bmxvYWQgcmVjb3JkaW5nIGxpbms6DQpo dHRwczovL2lldGYud2ViZXguY29tL2lldGYvbHNyLnBocD9SQ0lEPTRiZDUwNDMyOTcyN2QyYTgx MWM5Y2IwYzliYzcxM2Q4DQoNCnByZXNlbnRhdGlvbiBhdDoNCmh0dHBzOi8vd3d3LmlldGYub3Jn L3Byb2NlZWRpbmdzL2ludGVyaW0vMjAxNi8wNS8xNi9pZHIvc2xpZGVzL3NsaWRlcy1pbnRlcmlt LTIwMTYtaWRyLTUtMS5wZGYNCg0K --_000_D35B96FF60EDEaceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <68749B08025CEC42AD7C83EB7A62870B@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5UaGFua3MgU3Vl IC0gSeKAmXZlIHdhdGNoZWQgaXQgYXMgd2VsbCBhbmQgd291bGQgYWR2aXNlIG90aGVycyB0byBz a2lwIHRoZSBmaXJzdCA3IG1pbnV0ZXMgc2luY2UgaXQgcmVhbGx5IGRvZXNu4oCZdCBzdGFydCB1 bnRpbCB0aGVuLiZuYnNwOzwvZGl2Pg0KPGRpdj5BY2VlPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFt aWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNr OyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQ QURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGlu OyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9u ZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJv bTogPC9zcGFuPlN1c2FuIEhhcmVzICZsdDs8YSBocmVmPSJtYWlsdG86c2hhcmVzQG5kemguY29t Ij5zaGFyZXNAbmR6aC5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpi b2xkIj5EYXRlOiA8L3NwYW4+RnJpZGF5LCBNYXkgMTMsIDIwMTYgYXQgMTE6NTEgQU08YnI+DQo8 c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj5BY2VlIExpbmRlbSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmFjZWVAY2lzY28uY29tIj5hY2VlQGNpc2NvLmNvbTwvYT4mZ3Q7PGJy Pg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+SURSIExpc3QgJmx0 OzxhIGhyZWY9Im1haWx0bzppZHJAaWV0Zi5vcmciPmlkckBpZXRmLm9yZzwvYT4mZ3Q7LCBKb2hu IFNjdWRkZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqZ3NAanVuaXBlci5uZXQiPmpnc0BqdW5pcGVy Lm5ldDwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6 IDwvc3Bhbj5SRTogW0lkcl0gSURSIGludGVyaW0gb24gTWF5IDE2dGggLSB3ZWJleCwgcXVlc3Rp b25zIGZvciBtZWV0aW5nLCBhbmQgcmVjb3JkaW5ncy48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9U RSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsg TUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXYgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNv bTp2bWwiIHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIg eG1sbnM6dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0i aHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3Ii IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48 IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Oldp bmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1 IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFu b3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToi SGVsdmV0aWNhIE5ldWUiOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEx LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2 Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9 DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFy YWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi O30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlz dC1pZDoxMjQ5OTk2OTIyOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBs YXRlLWlkczotMTcwODM4MDI1OCA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2 NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDps ZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MzguMzVwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6NzQu MzVwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MTEwLjM1cHQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJbWFyZ2luLWxlZnQ6MTQ2LjM1cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjE4Mi4zNXB0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0 IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyMTguMzVwdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJn aW4tbGVmdDoyNTQuMzVwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjkwLjM1cHQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjMyNi4zNXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7 bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPGRpdiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkFjZWU6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj5UaGUgbGluayBmb3IgRXJpY+KAmXMgdGFsayBpcyB0aGUgbWVz c2FnZSB5b3UgY29waWVzIChzZWUgYmVsb3cpIGFuZCBJIGluY2x1ZGVkIGhlcmU6DQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5TdHJlYW1pbmcgcmVjb3JkaW5nIGxpbms6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj48YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvbGRyLnBocD9S Q0lEPWM4NjE1YWE4NDU4MDFhMWU0Yjc5Y2IxNzA4YTA0NDg0Ij5odHRwczovL2lldGYud2ViZXgu Y29tL2lldGYvbGRyLnBocD9SQ0lEPWM4NjE1YWE4NDU4MDFhMWU0Yjc5Y2IxNzA4YTA0NDg0PC9h PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+RG93bmxvYWQgcmVjb3JkaW5nIGxpbms6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YSBo cmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvbHNyLnBocD9SQ0lEPTRiZDUwNDMyOTcy N2QyYTgxMWM5Y2IwYzliYzcxM2Q4Ij5odHRwczovL2lldGYud2ViZXguY29tL2lldGYvbHNyLnBo cD9SQ0lEPTRiZDUwNDMyOTcyN2QyYTgxMWM5Y2IwYzliYzcxM2Q4PC9hPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoZSBsb2NhdGlvbjogPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzL2ludGVyaW0vMjAxNi8wNS8xNi9p ZHIvYWdlbmRhL2FnZW5kYS1pbnRlcmltLTIwMTYtaWRyLTUiPmh0dHBzOi8vd3d3LmlldGYub3Jn L3Byb2NlZWRpbmdzL2ludGVyaW0vMjAxNi8wNS8xNi9pZHIvYWdlbmRhL2FnZW5kYS1pbnRlcmlt LTIwMTYtaWRyLTU8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5vbiB0 aGUgQWdlbmRhIGhhcyBib3RoIGxpbmtzLiA8bzpwPg0KPC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+U3VlIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IFRhaG9tYSwgc2Fu cy1zZXJpZjsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBm b250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyI+IElkciBbPGEgaHJlZj0ibWFpbHRvOmlk ci1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+ T24gQmVoYWxmIE9mIDwvYj5BY2VlIExpbmRlbSAoYWNlZSk8YnI+DQo8Yj5TZW50OjwvYj4gRnJp ZGF5LCBNYXkgMTMsIDIwMTYgMTE6MDEgQU08YnI+DQo8Yj5Ubzo8L2I+IFZhbiBEZSBWZWxkZSwg R3VudGVyIChOb2tpYSAtIEJFKTsgPGEgaHJlZj0ibWFpbHRvOmlkckBpZXRmLm9yZyI+aWRyQGll dGYub3JnPC9hPjsgSm9obiBTY3VkZGVyPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbSWRyXSBJ RFIgaW50ZXJpbSBvbiBNYXkgMTZ0aCAtIHdlYmV4LCBxdWVzdGlvbnMgZm9yIG1lZXRpbmcsIGFu ZCByZWNvcmRpbmdzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+SGkg Sm9obiwmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPkkgd2Fz IGFibGUgdG8gZmluZCBHdW50ZXLigJlzIFdlYkV4IHJlY29yZGluZyB2aWEgYSBVUkwgaW4gb25l IG9mIHRoZSBFLW1haWxzIGJ1dCBuZWl0aGVyIHJlY29yZGluZyBsaW5rIGlzIG9uIHRoZSBtZWV0 aW5nIG1hdGVyaWFscyBwYWdlIGFuZCBJ4oCZZCBsaWtlIHRvIHdhdGNoIEVyaWPigJlzIGFzIHdl bGwuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzL2ludGVyaW0v MjAxNi8wNS8xNi9pZHIvcHJvY2VlZGluZ3MuaHRtbCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJv Y2VlZGluZ3MvaW50ZXJpbS8yMDE2LzA1LzE2L2lkci9wcm9jZWVkaW5ncy5odG1sPC9hPjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg c2VyaWY7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkFjZWU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPklkciAmbHQ7PGEg aHJlZj0ibWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnIj5pZHItYm91bmNlc0BpZXRmLm9yZzwv YT4mZ3Q7IG9uIGJlaGFsZiBvZiAmcXVvdDtWYW4gRGUgVmVsZGUsIEd1bnRlciAoTm9raWEgLSBC RSkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpndW50ZXIudmFuX2RlX3ZlbGRlQG5va2lhLmNv bSI+Z3VudGVyLnZhbl9kZV92ZWxkZUBub2tpYS5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwv Yj5GcmlkYXksIE1heSAxMywgMjAxNiBhdCAxMDo1NSBBTTxicj4NCjxiPlRvOiA8L2I+SURSIExp c3QgJmx0OzxhIGhyZWY9Im1haWx0bzppZHJAaWV0Zi5vcmciPmlkckBpZXRmLm9yZzwvYT4mZ3Q7 PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbSWRyXSBJRFIgaW50ZXJpbSBvbiBNYXkgMTZ0aCAt IHdlYmV4LCBxdWVzdGlvbnMgZm9yIG1lZXRpbmcsIGFuZCByZWNvcmRpbmdzLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxl ZnQ6My43NXB0O21hcmdpbi1yaWdodDowaW4iIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9C TE9DS1FVT1RFIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1m YW1pbHk6ICdIZWx2ZXRpY2EgTmV1ZScsIHNlcmlmOyBjb2xvcjogYmxhY2s7Ij5QcmUtbGltaW5h ciBjb21tZW50c+KApi4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZh bWlseTogJ0hlbHZldGljYSBOZXVlJywgc2VyaWY7IGNvbG9yOiBibGFjazsiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6ICdIZWx2ZXRpY2EgTmV1 ZScsIHNlcmlmOyBjb2xvcjogYmxhY2s7Ij5CZWZvcmUgZW5nYWdpbmcgd2l0aCBteSBmZWVkYmFj ayBhbmQgYWRkcmVzc2luZyB0aGUgZGlzY3Vzc2lvbiBzbGlkZXMsIGkgd291bGQgbGlrZSB0byB0 aGFuayBib3RoIFN1ZSBhbmQgSm9obiBmb3IgZ29pbmcgdGhyb3VnaCB0aGUgZWZmb3J0IGFuZCB0 aW1lIHRvDQogdHJ5IHRvIG1ha2UgdGhlIHJlY29yZGluZ3MgYXMgZ29vZCBhcyBwb3NzaWJsZSBh bmQgaW52ZXN0aW5nIG5vbi10cml2aWFsIGFtb3VudHMgb2YgdGltZSB0byBnZXQgdGhlIGpvYiBk b25lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6ICdIZWx2 ZXRpY2EgTmV1ZScsIHNlcmlmOyBjb2xvcjogYmxhY2s7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUnLCBzZXJpZjsg Y29sb3I6IGJsYWNrOyI+SSB3b3VsZCBhbHNvIGxpa2UgdG8gdGhhbmtzIEVyaWMgV3UgdG8gZ28g dGhyb3VnaCB0aGUgZXhlcmNpc2Ugb2YgcmVjb3JkaW5nIGhpcyBwcmVzZW50YXRpb24gb2YgdGhl IHNsaWRlcy4gSSB3ZW50IHRocm91Z2ggdGhlIHNhbWUgZXhlcmNpc2UgYW5kIGV2ZW4gdGhvdWdo DQogdGhlcmUgd2VyZSBsZXNzIG9wZXJhdGlvbmFsIGlzc3VlcyB0byBkZWFsIHdpdGggZHVyaW5n IG15IHJlY29yZGluZywgaXQgaXMgYSBub24tdHJpdmlhbCB0YXNrIHRvIHNwZWFrIHRvIGEgc2Ny ZWVuIGFuZCBub3QgdG8gYW4gYXVkaWVuY2UuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogMTAuNXB0OyBmb250LWZhbWlseTogJ0hlbHZldGljYSBOZXVlJywgc2VyaWY7IGNvbG9yOiBi bGFjazsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1p bHk6ICdIZWx2ZXRpY2EgTmV1ZScsIHNlcmlmOyBjb2xvcjogYmxhY2s7Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUn LCBzZXJpZjsgY29sb3I6IGJsYWNrOyI+Q29tbWVudHM6IFdvcmtpbmcgc2xpZGVzIGRpc2N1c3Np b24gb2YgdGhlIDE2IE1heSAyMDE2IEludGVyaW0gSURSIG1lZXRpbmc6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogJ0hlbHZldGljYSBOZXVlJywgc2VyaWY7 IGNvbG9yOiBibGFjazsiPi0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx MC41cHQ7IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUnLCBzZXJpZjsgY29sb3I6IGJsYWNr OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7 IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUnLCBzZXJpZjsgY29sb3I6IGJsYWNrOyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPlRpbWVsaW5l IGluZm88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PT09PT09 PT09PTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFj ayI+ZHJhZnQtdmFuZGV2ZWxkZS1pZHItZmxvd3NwZWMtcGF0aC1yZWRpcmVjdC0wMCBjcmVhdGVk IG9uIDE0IFNlcHRlbWJlciAyMDE1PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29s b3I6YmxhY2siPmRyYWZ0LXZhbmRldmVsZGUtaWRyLWZsb3dzcGVjLXBhdGgtcmVkaXJlY3QtMDEg Y3JlYXRlZCBvbiAxMiBKYW51YXJ5IDIwMTY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtjb2xvcjpibGFjayI+ZHJhZnQtdmFuZGV2ZWxkZS1pZHItZmxvd3NwZWMtcGF0aC1yZWRpcmVj dC0wMiBjcmVhdGVkIG9uIDE3IE1hcmNoIDIwMTY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2NvbG9yOmJsYWNrIj5kcmFmdC1saS1pZHItZmxvd3NwZWMtcmVkaXJlY3QtZ2VuZXJh bGl6ZWQtc2lkLTAwIGNyZWF0ZWQgb24gMjEgTWFyY2ggMjAxNjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPkdlbmVyYWwgc2xpZGUgb2Jz ZXJ2YXRpb25zIGFib3V0IGRyYWZ0LWxpLWdlbmVyYWxpc2VkLXNpZC0wMCAocmVmLiBkaXNjdXNz aW9uIHNsaWRlIGZvciAxNiBNYXkgMjAxNik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtjb2xvcjpibGFjayI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+ RHJhZnQtbGkgZG9jdW1lbnRzIGEgZmxvd3NwZWMgYWN0aW9uIHVzaW5nIGEgbmV3IGNvbW11bml0 eSAoZ2VuZXJhbGl6ZWQtU0lEKS4gVGhlIGV4dGVuZGVkIGNvbW11bml0eSBwcm92aWRlcyBhIGZs b3dzcGVjIGNsaWVudCBpbmZvcm1hdGlvbiB0byBtYWtlIGEgbG9jYWwgZm9yd2FyZGluZyBkZWNp c2lvbiBieSBtZWFucyBvZiBhIGxvY2FsDQogbWFwcGluZyB0YWJsZS4gVGhlIHR3byBtYWluIGNv bXBvbmVudHMgdXNlZCBieSB0aGUgZmxvd3NwZWMgY2xpZW50IGlzOiAoMSkgYW4gaWRlbnRpZmll ciBhbmQgKDIpIHNlbWFudGljcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPkRyYWZ0LXZhbmRldmVsZGUgZG9jdW1lbnRzIGEgZmxv d3NwZWMgYWN0aW9uIHVzaW5nIGEgbmV3IGNvbW11bml0eSAoSW5kaXJlY3Rpb24tSUQpLiBUaGUg ZXh0ZW5kZWQgY29tbXVuaXR5IHByb3ZpZGVzIGEgZmxvd3NwZWMgY2xpZW50IGluZm9ybWF0aW9u IHRvIG1ha2UgYSBsb2NhbCBmb3J3YXJkaW5nIGRlY2lzaW9uIGJ5IG1lYW5zIG9mDQogYSBsb2Nh bCBtYXBwaW5nIHRhYmxlLiBUaGUgdHdvIG1haW4gY29tcG9uZW50cyB1c2VkIGJ5IHRoZSBmbG93 c3BlYyBjbGllbnQgaXM6ICgxKSBhbiBpZGVudGlmaWVyIGFuZCAoMikgb3B0aW9uYWxseSBzZW1h bnRpY3MgKFRhYmxlIHNlbWFudGljcyAmIzQzOyBUdW5uZWwtSUQpLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5kcmFmdC12YW5k ZXZlbGRlLWlkci1mbG93c3BlYy1wYXRoLXJlZGlyZWN0LTAyJm5ic3A7d2FzIGNyZWF0ZWQmbmJz cDvigJxiZWZvcmUmcXVvdDsmbmJzcDtkcmFmdC1saS1pZHItZmxvd3NwZWMtcmVkaXJlY3QtZ2Vu ZXJhbGl6ZWQtc2lkLTAwIGFuZCBhY2hpZXZlcyB0aGUgc2FtZSBmdW5jdGlvbmFsaXR5IGFuZCBt b3JlLiAoRm9yIGV4YW1wbGUgZHJhZnQtdmFuZGV2ZWxkZQ0KIGhhcyB0aGUgcG90ZW50aWFsIHRv IHNpZ25hbCA4MTkyIHR5cGVzIG9mIHNlbWFudGljIG1hcHBpbmcgdGFibGVzIHdoaWxlIGRyYWZ0 LWxpIGhhcyAyNTUsIGFub3RoZXIgZXhhbXBsZSBpcyB0aGUgVElEIGZpZWxkIHdoaWNoIGFsbG93 cyBkeW5hbWljIE5leHQtTmV4dC1Ib3AgY29uc3RydWN0cyB1c2UgZm9yIEVQRSBERG9TIHJlZGly ZWN0aW9uKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPkR1cmluZyBX RyBhZGRvcHRpb24tY2FsbCAzLzI1IHRvIDQvOCB0aGUgZm9sbG93aW5nIGhhcyBiZWVuIG1lbnRp b25lZCBieSBJZ25hczoNCjxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZl L3dlYi9pZHIvY3VycmVudC9tc2cxNTUxMi5odG1sIj5odHRwOi8vd3d3LmlldGYub3JnL21haWwt YXJjaGl2ZS93ZWIvaWRyL2N1cnJlbnQvbXNnMTU1MTIuaHRtbDwvYT48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUnLCBzZXJpZjsg Y29sb3I6IGJsYWNrOyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW4tbGVmdDozMC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPiZxdW90Ozwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+RHJhZnQtdmFuZGV2ZWxkZSBjYW4gYWNoaWV2ZSBhbGwgd2hhdCBkcmFm dC1oYW8gYW5kIGRyYWZ0LWxpIGNhbiwgYW5kIGluIGEgbW9yZSBmbGV4aWJsZSB3YXkuIEhhdmlu ZyB0aGUgYWJpbGl0eSB0bw0KIGRlY291cGxlIHJlZGlyZWN0aW9uPHNwYW4gc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPiB0dW5uZWwgdHlwZSBmcm9tIHJlZGlyZWN0aW9uIGFjdGlvbiBpcyBib3Ro IHByYWN0aWNhbCBhbmQgZXh0ZW5zaWJsZSAtIHRoZSBhY3R1YWwgdHVubmVsIHRvIGJlIHVzZWQg aXMgYSBsb2NhbCBvcGVyYXRpb25hbCBkZWNpc2lvbiBmb3IgZWFjaCBuZXR3b3JrIGVsZW1lbnQs IGl0IGlzIG5vdCBuZWNlc3Nhcnkgc2lnbmFsbGVkIGF0IHRoZSBzYW1lIHRpbWUNCiBhbmQgYnkg dGhlIHNhbWUgbWVjaGFuaXNtLiBEZWNvdXBsaW5nIHNpZ25hbGxpbmcgYW5kIHJlZGlyZWN0IHBh cnRzIGFsaWducyB3ZWxsIHRvIG9wZXJhdGlvbmFsIHByYWN0aWNlcyBvZiB1c2luZyBzcGVjaWZp YyB0b29scyBmb3Igc3BlY2lmaWMgdGFza3MuIEp1c3QgdGhhdCBCR1AgY291bGQgZG8gdGhhdCBk b2VzIG5vdCBuZWNlc2FzcnkgbWVhbiB0aGF0IGl0IHNob3VsZCBiZSB1c2VkIGFzIGEgYmVzdCBm aXQuIEZyb20gb3BlcmF0aW9uYWwNCiBwZXJzcGVjdGl2ZSB0aGVyZSBpcyBubyBuZWVkIHRvIGhh dmUgbXVsdGlwbGUgc29sdXRpb25zIHRoYXQgdHJ5IHRvIGFkZHJlc3MgdGhlIG5hcnJvdyBwcm9i bGVtIHNwYWNlIGluIHNpbWlsYXIgeWV0IGluY29tcGF0aWJsZSB3YXlzLiBUaGVyZSBzaG91bGQg YmUgb25lIGRvY3VtZW50IGZvciByZWRpcmVjdCwgYW5kIGRyYWZ0LXZhbmRldmVsZGUgaXMgYSBn b29kIHN0YXJ0aW5nIGJhc2UgZm9yIHRoYXQuJnF1b3Q7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUnLCBzZXJp ZjsgY29sb3I6IGJsYWNrOyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250 LWZhbWlseTogJ0hlbHZldGljYSBOZXVlJywgc2VyaWY7IGNvbG9yOiBibGFjazsiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6ICdIZWx2ZXRpY2Eg TmV1ZScsIHNlcmlmOyBjb2xvcjogYmxhY2s7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPkRldGFpbCB2aWV3 OiBzbGlkZSBvYnNlcnZhdGlvbnMgZHJhZnQtbGktZ2VuZXJhbGlzZWQtc2lkLTAwIGRpc2N1c3Np b248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPlNs aWRlIDIgKG9mIHRoZSBkcmFmdC1saSBwcmVzZW50YXRpb24pOiBIaXN0b3J5Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj49PTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5UaGUgc2xpZGUgZm9yZ2V0 cyB0byBtZW50aW9uIHRoYXQgZHJhZnQtdmFuZGV2ZWxkZSB3YXMgZW5oYW5jZWQgYW5kIHByb2dy ZXNzZWQgYmFzZWQgdXBvbiBjb25zdHJ1Y3RpdmUgV0cgZmVlZGJhY2suIE11Y2ggZmVlZGJhY2sg aGFzIGJlZW4gaW50ZWdyYXRlZCBiZXR3ZWVuIGRyYWZ0LXZhbmRldmVsZGUgLTAwIHRvIOKAkzAy IEJFRk9SRQ0KIGRyYWZ04oCTbGkgZXZlbiBleGlzdGVkLiBGb3IgZXhhbXBsZTo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+KiBVc2UtY2FzZSBzY2VuYXJpb+KA mXMgd2VyZSBhZGRlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNr Ij4qICZxdW90O1BhdGgtaWQmcXVvdDsgY2hhbmdlZCB0byAmcXVvdDtJbmRpcmVjdGlvbi1pZCZx dW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj4qIENvbmNl cHQgb2YgSW5kaXJlY3Rpb24gdGFibGVzIGhhcyBiZWVuIGFkZGVkIChoZW5jZSBhZGRpbmcgdGhl IGNhcGFiaWxpdHkgb2YgY29udGV4dC9zZW1hbnRpY3Mgc2lnbmFsbGluZyBhbHJlYWR5IHNpbmNl IHZlcnNpb24gLTAxKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNr Ij4qIEZsb3dzcGVjIHZhbGlkYXRpb24gaW5mb3JtYXRpb24gaXMgYWRkZWQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+KiBzaWduYWxsaW5nIG9mIGNvbnRleHQv c2VtYW50aWNzIGlzIGFkZGVkIGJ5IGludHJvZHVjaW5nIEJpbmRpbmctU0lEIGNvbnRleHQgaWRl bnRpZmllciBhcyBhIGZpcnN0IGV4dGVuc2lvbiBvZiBJbmRpcmVjdGlvbi1pZCBleHRlbmRlZCBj b21tdW5pdHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5JdCBpcyBh biBpbmNvcnJlY3QgYXNzdW1wdGlvbiBvZiBubyBjb250ZXh0IGF3YXJlbmVzcyBpbiBkcmFmdC12 YW5kZXZlbGRlLiBkcmFmdC12YW5kZXZlbGRlLWlkci1mbG93c3BlYy1wYXRoLXJlZGlyZWN0IGFk ZGVkIGNvbnRleHQgc3VwcG9ydCBiZWZvcmUgZHJhZnQtbGkgZXhpc3RlZCwgYW5kIHJhaXNlcyBx dWVzdGlvbnMgYWJvdXQNCiBuZXcgZWxlbWVudHMgZXhwb3NlZCB3aXRoIGRyYWZ0LWxpIGNvbXBh cmVkIHRvIGRyYWZ0LXZhbmRldmVsZGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtjb2xvcjpibGFjaztiYWNrZ3JvdW5kOiNGRkZERjUiPihmd2l3IFRoZSBzZW1hbnRpYyBhd2Fy ZW5lc3Mgb2YgZHJhZnQtdmFuZGV2ZWxkZSBpcyBtZW50aW9uZWQgYW5kIHRoZSB3ZWJleCByZWNv cmRpbmcgb2YgZHJhZnQtbGkgYmV0d2VlbiByZWNvcmRpbmcgdGltZS1zdGFtcHMgMTFtMzBzIHRv IDEzbTMwcyk8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2si PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFj ayI+U2xpZGUgMyAob2YgdGhlIGRyYWZ0LWxpIHByZXNlbnRhdGlvbik8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPj09PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPk5vIG5ldyBjYXBhYmlsaXR5IGlzIGV4cGxh aW5lZCBvbiB0aGlzIHNsaWRlIGluIGNvbXBhcmlzb24gd2l0aCB0aGUgZHJhZnQtdmFuZGV2ZWxk ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+SW4gZHJhZnQt dmFuZGV2ZWxkZSB0aGUgaW5mb3JtYXRpb24gZm91bmQgaW4gdGhlIGluZGlyZWN0aW9uLWlkIGlz IHVzZWQgb24gYSBmbG93c3BlYyBjbGllbnQgaW4gYSBsb2NhbCBtYXBwaW5nLXRhYmxlIChpbmRp cmVjdGlvbi1pZCB0YWJsZSkgdG8gZmluZCBsb2NhbCBmb3J3YXJkaW5nIGluZm9ybWF0aW9uLiBU aGUgbmV3IGZsb3dzcGVjDQogZXh0ZW5kZWQgY29tbXVuaXR5IGFzIGRvY3VtZW50ZWQgYnkgZHJh ZnQtdmFuZGV2ZWxkZSBjYW4gcHJvdmlkZSBhbHJlYWR5IGEgZmxvd3NwZWMgY2xpZW50IHRoZSBy ZXF1aXJlZCBzZW1hbnRpYy9jb250ZXh0IGluZm9ybWF0aW9uIChleGFtcGxlIGlzIHRoZSDigJhC 4oCZIGJpdCkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+U2xpZGUgNCAob2Yg dGhlIGRyYWZ0LWxpIHByZXNlbnRhdGlvbik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Y29sb3I6YmxhY2siPj09PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Y29sb3I6YmxhY2siPlRoZSBnb2FsIG9mIGRyYWZ0LWxpIGlzIHRvIGRlZmluZSBhIOKAnHNl bWFudGljcyBkZXBlbmRlbnTigJ0gYWN0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2NvbG9yOmJsYWNrIj5Ib3dldmVyLCBkcmFmdC12YW5kZXZlbGRlIGFscmVhZHkgYWxsb3dz IHRoYXQgZnVuY3Rpb25hbGl0eSBiZWZvcmUgZHJhZnQtbGkgZXhpc3RlZDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Y29sb3I6YmxhY2siPlNsaWRlIDUgKG9mIHRoZSBkcmFmdC1saSBwcmVzZW50YXRp b24pPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj49 PTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5EcmFmdC12 YW5kZXZlbGRlIGhhcyBpbmRlZWQgdGhlIHBvdGVudGlhbCB0byBiZSB1c2VkIGluIHN1Y2ggYSBt YW5uZXIuIFRoZSBpbnRlbmQgb2YgdGhpcyBzbGlkZSBhdCB0aGUgdGltZSBvZiB1c2FnZSB3YXMg dG8gc2hvdyBhbiBleHRyZW1lIGV4YW1wbGUgb2YgdGhlIGZsZXhpYmxpdHkgdGhlIHRlY2hub2xv Z3kgb2ZmZXJzLiBXaGVuDQogZm9yIGV4YW1wbGUgdXNpbmcgcmVkaXJlY3Rpb24gdG8gYmluZGlu Zy1TSUQgKGFzIGRvY3VtZW50ZWQgaW4gbGF0ZXN0IGRyYWZ0LXZhbmRldmVsZGUpIHRoZW4gdGhl IGxvY2FsIG1hcHBpbmcgdGFibGUgY2FuIGJlIGJhc2VkIGFyb3VuZCB0aGUgc2lnbmFsbGVkIHNl bWFudGljcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5TbGlkZSA2IChvZiB0 aGUgZHJhZnQtbGkgcHJlc2VudGF0aW9uKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtjb2xvcjpibGFjayI+PT08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Y29sb3I6YmxhY2siPkRyYWZ0LXZhbmRldmVsZGUgaGFzIDEzIGJpdHMgYXZhaWxh YmxlIGZvciB0eXBlcywgaGVuY2UgdGhlIHBvdGVudGlhbCB0byBzdXBwb3J0L3NpZ25hbCAyXjEz ICg9ODE5MikgdHlwZXMgd2hlbiB1c2luZyB0aGUgZmllbGQgYXMgc2NhbGFyIHZhbHVlICh3aGVu IGNvbXBhcmluZyB3aXRoIGEgcG90ZW50aWFsIGZvciAyNTUgdHlwZXMgdXNpbmcNCiBkcmFmdC1s aSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2si PlRoZSBjbGFpbSBtYWRlIG9uIHNsaWRlNiB0aGF0IGRyYWZ0LXZhbmRldmVsZGUgYWxsb3dzIG9u bHkgMTMgdHlwZSBvZiBzZW1hbnRpYyBpbmZvcm1hdGlvbiBpcyB3cm9uZyBhc3N1bXB0aW9uLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+QXQg dGhlIHRpbWUgb2Ygd3JpdGluZywgaXQgd2FzIGZvdW5kIHVzZWZ1bCB0byBzaWduYWwgYmluZGlu ZyBTSUQgdXNlZnVsIHNlbWFudGljIOKApiBXZSBkZWNpZGVkIHRvIGxlYXZlIHRoZSByZW1haW5p bmcgYml0cyByZXNlcnZlZC9vcGVuIGZvciBkaXNjdXNzaW9uIG9uIGhvdyB0byBiZXN0IHVzZSB0 aGUgZmllbGQgaW5zdGVhZC4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2NvbG9yOmJsYWNrIj5NYXliZSB0aGUgV0cgZmVlbHMgaXQgaXMgYmVzdCB0byB1c2Ug b25seSBhIGZldyBiaXRzIGZvciBzZW1hbnRpY3MgYW5kIGtlZXAgdGhlIHJlbWFpbmRlciByZXNl cnZlZCBmb3IgZnV0dXJlIHVzZS4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29s b3I6YmxhY2siPktpbmQgUmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtj b2xvcjpibGFjayI+Ry88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj5JZHIgJmx0OzxhIGhyZWY9Im1haWx0bzppZHItYm91bmNlc0Bp ZXRmLm9yZyI+aWRyLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgU3VzYW4g SGFyZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpzaGFyZXNAbmR6aC5jb20iPnNoYXJlc0BuZHpoLmNv bTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPkZyaWRheSAxMyBNYXkgMjAxNiBhdCAxMjo0Njxi cj4NCjxiPlRvOiA8L2I+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmlkckBpZXRmLm9yZyI+aWRyQGll dGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlkckBpZXRmLm9yZyI+aWRyQGll dGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+W0lkcl0gSURSIGludGVyaW0gb24g TWF5IDE2dGggLSB3ZWJleCwgcXVlc3Rpb25zIGZvciBtZWV0aW5nLCBhbmQgcmVjb3JkaW5ncy48 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGUgdGltZSBvZiB0aGUgaW50ZXJpbSBpcyAyMjowMC0y MzowMCBFRFQgb24gTWF5IDE2PHN1cD50aDwvc3VwPi4gJm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPlRoZSBpbnRlcmltIHdpbGwgZGlzY3VzcyB0aGUgZm9sbG93aW5nIHR3 byBkcmFmdHMgaW4gb3JkZXIgdG8gY3JlYXRlIGEgV0cgc29sdXRpb246DQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzguMzVwdDt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6 bDAgbGV2ZWwxIGxmbzIiPg0KPCEtLVtpZiAhc3VwcG9ydExpc3RzXS0tPjxzcGFuIHN0eWxlPSJj b2xvcjogYmxhY2s7Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxl PSJmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2Vp Z2h0OiBub3JtYWw7IGZvbnQtc2l6ZTogN3B0OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbic7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhLS1bZW5kaWZdLS0+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5kcmFmdC12YW5kZXZlbGRlLWlkci1mbG93c3BlYy1wYXRo LXJlZGlyZWN0LCBhbmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM4LjM1cHQ7dGV4dC1pbmRlbnQ6LS4yNWluO21z by1saXN0OmwwIGxldmVsMSBsZm8yIj4NCjwhLS1baWYgIXN1cHBvcnRMaXN0c10tLT48c3BhbiBz dHlsZT0iY29sb3I6IGJsYWNrOyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3Bh biBzdHlsZT0iZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBm b250LXdlaWdodDogbm9ybWFsOyBmb250LXNpemU6IDdwdDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsg Zm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IS0tW2VuZGlm XS0tPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ZHJhZnQtbGktaWRyLWZsb3dzcGVjLXJlZGly ZWN0LWdlbmVyYWxpemVkLXNpZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Tb21l IG9mIHRoZSBRdWVzdGlvbnMgdGhhdCB3aWxsIGJlIGRpc2N1c3MgYXJlIGluY2x1ZGVkIGJlbG93 LiZuYnNwOyBQbGVhc2UgcmV2aWV3IHRoZSBwcmUtcmVjb3JkaW5nIHByZXNlbnRhdGlvbnMgcHJp b3IgdG8gdGhlIG1lZXRpbmcuJm5ic3A7Jm5ic3A7IFRoZSBDaGFpcnMgZW5jb3VyYWdlIGRpc2N1 c3Npb24gb2YgdGhlc2UgcXVlc3Rpb25zIG9uIHRoZSBsaXN0IGJlZm9yZSwgZHVyaW5nLA0KIGFu ZCBhZnRlciB0aGUgbWVldGluZy4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlN1 ZSBhbmQgSm9obiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PT09PT09PT09PT09 PT09PT09PT09PT09PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkFnZW5kYSBm b3IgSURSIFZpcnR1YWwgSW50ZXJpbSBNZWV0aW5nDQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk1heSAxNiwgMjAx NjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+MjI6MDAgLSAyMzowMCBFRFQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+V2ViRXg6IDxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBo cD9NVElEPW05YmU0ODFkMTk5ODhkZDFiNTQ1YmU2NzU5YWVlMjY3YiI+DQpodHRwczovL2lldGYu d2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tOWJlNDgxZDE5OTg4ZGQxYjU0NWJlNjc1OWFlZTI2 N2I8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj5NZWV0aW5nIG51bWJlcjombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgNjQ5IDIzNSA0MTE8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPk1lZXRpbmcgcGFzc3dvcmQ6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEpnNjZkMnBtPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Kb2luIGJ5IHBob25l PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4xLTg3Ny02NjgtNDQ5MyBDYWxsLWluIHRvbGwgZnJlZSBudW1iZXIgKFVT L0NhbmFkYSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjEtNjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIg KFVTL0NhbmFkYSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkFjY2VzcyBjb2RlOiA2NDkgMjM1IDQxMTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5RdWVzdGlvbnMgZm9yIG1lZXRpbmc6IDwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+U3VibWl0dGVkIGJ5IChFcmljIFd1KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+MS4gUmVkaXJlY3Qt dG8tU3BlY2lmaWMtVHVubmVsIHdpdGggQkdQIFBhdGggQXR0cmlidXRlIFtUVU5ORUxFTkNBUFNd W01QUF0gYW5kDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwO1JlZGlyZWN0LXRvLUlJRC9HU0lE LCBSZXF1aXJlZCBieSBkaWZmZXJlbnQgdXNlIGNhc2VzLCBjYW4gd2UgaGF2ZSB0d28gZG9jcyBp biBJRFIgSW4gcGFyYWxsZWw/DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwO1tDb21wYXJpc29u IHRvIFJlZGlyZWN0LXRvLUlJRC9HU0lEICwgZHJhZnQtaGFvIHdpbGwgaGF2ZSBtb3JlIGxpdHRs ZSBtb2RpZmljYXRpb24NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7dG8gZXhpc3RpbmcgbWVj aGFuaXNtcywgTm8gbmVlZCB0byBkbyBNYXBwaW5nIC9SZWN1cnNpdmUgTG9va3VwLl08bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Mi4mbmJzcDsgRm9yIElJRC9HU0lELCBvbmUgbWFw cGluZyB0YWJsZSBmb3INCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7YWxsIGtpbmRzIG9mIHNl Z21lbnRzL2ZvcndhcmRpbmctZW50aXRpZXMgdnMuIG9uZSBtYXBwaW5nIHRhYmxlDQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwO3BlciBzZWdtZW50cy9mb3J3YXJkaW5nLWVudGl0aWVzIHR5cGUs IHNob3VsZCB3ZSBzdXBwb3J0IGJvdGg/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPkNoYWlyIFF1ZXN0aW9uczogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4xKSBEb2VzIHRoZSBXRyBmZWVsIHdl IG5lZWQgdGhlIGZvbGxvd2luZyBmb3IgUkZDNTU3NWJpcyAoRERvUyk8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOyBhKSBSZWRpcmVjdGlvbiB0byBWUkYsIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Yikg UmVkaXJlY3Rpb24gdG8gSW5kaXJlY3Rpb24gdG8gSVAsIGFuZCAmbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOyZuYnNwO2MpIFJlZGlyZWN0aW9uIHRvIFNlcnZpY2UgKG5ldyk/DQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+MikgSWYgdGhlIFdHIGRlc2lyZXMgcmVkaXJl Y3Rpb24gdG8gU2VydmljZSByb3V0aW5nLCBkb2VzIHRoZSBXRyBkZXNpcmU8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PmEpIE5leHQtSG9wIHR1bm5lbCBzdXBwb3J0PyAtPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5iKSBOZXh0LUhvcCBU RSBUdW5uZWwgc3VwcG9ydD8gPG86cD4NCjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwO2MpIE5lc3RlZCBUdW5uZWwg c3VwcG9ydD8gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDtkKSBOZXh0LU5leHQgSG9wIFR1bm5lbCBTdXBw b3J0PyA8bzpwPg0KPC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7ZSkgUm91dGVyIGxvY2FsaXplZCBUdW5uZWwgcmVj dXJzaW9uPw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDtmKSBUdW5uZWwgRW5jYXAgUmVjdXJzaW9uOiA8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+MykgV2hhdCBwaWVjZXMgb2YgdGhlIHBy b3Bvc2VkIHNvbHV0aW9ucyBoYXZlIGJlZW4gaW1wbGVtZW50ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyBhbmQvb3IgZGVwbG95ZWQ/Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlByZXNlbnRhdGlvbnMgKHByZXJl Y29yZGVkLCBwbGVhc2UgcmV2aWV3IHByaW9yIHRvIG1lZXRpbmcpOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPi0gZHJhZnQtdmFuZGV2ZWxkZS1pZHIt Zmxvd3NwZWMtcGF0aC1yZWRpcmVjdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7IEd1bnRlciBWYW4gRGUg VmVsZGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyAyMSBtaW51dGVzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsg PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2xkci5waHA/UkNJRD1lMDFkNjI2 NjEwODVmNjYwZjQ3MGZlZGRkOWJmMjY2ZiI+DQpodHRwczovL2lldGYud2ViZXguY29tL2lldGYv bGRyLnBocD9SQ0lEPWUwMWQ2MjY2MTA4NWY2NjBmNDcwZmVkZGQ5YmYyNjZmPC9hPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5wcmVzZW50YXRpb24gYXQ6IDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvaW50ZXJpbS8yMDE2LzA1 LzE2L2lkci9zbGlkZXMvc2xpZGVzLWludGVyaW0tMjAxNi1pZHItNS0wLnBkZiI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvaW50ZXJpbS8yMDE2LzA1LzE2L2lkci9zbGlkZXMvc2xp ZGVzLWludGVyaW0tMjAxNi1pZHItNS0wLnBkZjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5kcmFmdC1saS1pZHItZmxvd3NwZWMtcmVkaXJl Y3QtZ2VuZXJhbGl6ZWQtc2lkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5FcmljIFd1IDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+MjAg bWludXRlcyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+U3RyZWFtaW5nIHJlY29y ZGluZyBsaW5rOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9p ZXRmL2xkci5waHA/UkNJRD1jODYxNWFhODQ1ODAxYTFlNGI3OWNiMTcwOGEwNDQ4NCI+aHR0cHM6 Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2xkci5waHA/UkNJRD1jODYxNWFhODQ1ODAxYTFlNGI3OWNi MTcwOGEwNDQ4NDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkRvd25sb2FkIHJlY29yZGluZyBsaW5rOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2xzci5waHA/UkNJ RD00YmQ1MDQzMjk3MjdkMmE4MTFjOWNiMGM5YmM3MTNkOCI+aHR0cHM6Ly9pZXRmLndlYmV4LmNv bS9pZXRmL2xzci5waHA/UkNJRD00YmQ1MDQzMjk3MjdkMmE4MTFjOWNiMGM5YmM3MTNkODwvYT48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+cHJlc2VudGF0aW9uIGF0OiA8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzL2ludGVyaW0v MjAxNi8wNS8xNi9pZHIvc2xpZGVzL3NsaWRlcy1pbnRlcmltLTIwMTYtaWRyLTUtMS5wZGYiPmh0 dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzL2ludGVyaW0vMjAxNi8wNS8xNi9pZHIvc2xp ZGVzL3NsaWRlcy1pbnRlcmltLTIwMTYtaWRyLTUtMS5wZGY8L2E+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv c3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D35B96FF60EDEaceeciscocom_-- From nobody Mon May 16 00:21:16 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8190112B00E for ; Mon, 16 May 2016 00:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5l0hDJuANDIO for ; Mon, 16 May 2016 00:21:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D22F12B00C for ; Mon, 16 May 2016 00:21:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id COT51227; Mon, 16 May 2016 07:21:06 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 16 May 2016 08:21:04 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Mon, 16 May 2016 15:21:00 +0800 From: Zhuangshunwan To: "Van De Velde, Gunter (Nokia - BE)" , "idr@ietf.org" Thread-Topic: [Idr] IDR interim on May 16th - webex, questions for meeting, and recordings. Thread-Index: AdGtA5N1fQH6ZeaQT8WhQMAKvH+1FwAI/l2AAIZs/zA= Date: Mon, 16 May 2016 07:20:59 +0000 Message-ID: <19AB2A007F56DB4E8257F949A2FB9858AA1BD619@NKGEML515-MBX.china.huawei.com> References: <008a01d1ad04$c63a77d0$52af6770$@ndzh.com> <9F087909-60F3-4F5C-8427-C0BD2A4ED9FF@alcatel-lucent.com> In-Reply-To: <9F087909-60F3-4F5C-8427-C0BD2A4ED9FF@alcatel-lucent.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.86.254] Content-Type: multipart/alternative; boundary="_000_19AB2A007F56DB4E8257F949A2FB9858AA1BD619NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0203.573974E3.013B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: bd2ba8d06e67a9c15cdac6cfcd8e700e Archived-At: Subject: Re: [Idr] IDR interim on May 16th - webex, questions for meeting, and recordings. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 07:21:14 -0000 --_000_19AB2A007F56DB4E8257F949A2FB9858AA1BD619NKGEML515MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgR3VudGVyLA0KDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudHMsIFBsZWFzZSBzZWUgcmVzcG9u c2VzIGlubGluZS4NCg0KQmVzdCAgUmVnYXJkcywNClNodW53YW4gJiBFcmljLld1DQoNCuWPkeS7 tuS6ujogSWRyIFttYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBWYW4gRGUgVmVs ZGUsIEd1bnRlciAoTm9raWEgLSBCRSkNCuWPkemAgeaXtumXtDogMjAxNuW5tDXmnIgxM+aXpSAy Mjo1Ng0K5pS25Lu25Lq6OiBpZHJAaWV0Zi5vcmcNCuS4u+mimDogUmU6IFtJZHJdIElEUiBpbnRl cmltIG9uIE1heSAxNnRoIC0gd2ViZXgsIHF1ZXN0aW9ucyBmb3IgbWVldGluZywgYW5kIHJlY29y ZGluZ3MuDQoNClByZS1saW1pbmFyIGNvbW1lbnRz4oCmLi4NCg0KQmVmb3JlIGVuZ2FnaW5nIHdp dGggbXkgZmVlZGJhY2sgYW5kIGFkZHJlc3NpbmcgdGhlIGRpc2N1c3Npb24gc2xpZGVzLCBpIHdv dWxkIGxpa2UgdG8gdGhhbmsgYm90aCBTdWUgYW5kIEpvaG4gZm9yIGdvaW5nIHRocm91Z2ggdGhl IGVmZm9ydCBhbmQgdGltZSB0byB0cnkgdG8gbWFrZSB0aGUgcmVjb3JkaW5ncyBhcyBnb29kIGFz IHBvc3NpYmxlIGFuZCBpbnZlc3Rpbmcgbm9uLXRyaXZpYWwgYW1vdW50cyBvZiB0aW1lIHRvIGdl dCB0aGUgam9iIGRvbmUuDQoNCkkgd291bGQgYWxzbyBsaWtlIHRvIHRoYW5rcyBFcmljIFd1IHRv IGdvIHRocm91Z2ggdGhlIGV4ZXJjaXNlIG9mIHJlY29yZGluZyBoaXMgcHJlc2VudGF0aW9uIG9m IHRoZSBzbGlkZXMuIEkgd2VudCB0aHJvdWdoIHRoZSBzYW1lIGV4ZXJjaXNlIGFuZCBldmVuIHRo b3VnaCB0aGVyZSB3ZXJlIGxlc3Mgb3BlcmF0aW9uYWwgaXNzdWVzIHRvIGRlYWwgd2l0aCBkdXJp bmcgbXkgcmVjb3JkaW5nLCBpdCBpcyBhIG5vbi10cml2aWFsIHRhc2sgdG8gc3BlYWsgdG8gYSBz Y3JlZW4gYW5kIG5vdCB0byBhbiBhdWRpZW5jZS4NCg0KDQpDb21tZW50czogV29ya2luZyBzbGlk ZXMgZGlzY3Vzc2lvbiBvZiB0aGUgMTYgTWF5IDIwMTYgSW50ZXJpbSBJRFIgbWVldGluZzoNCi0t LS0tLS0tLS0tLS0NCg0KDQpUaW1lbGluZSBpbmZvDQo9PT09PT09PT09DQoNCmRyYWZ0LXZhbmRl dmVsZGUtaWRyLWZsb3dzcGVjLXBhdGgtcmVkaXJlY3QtMDAgY3JlYXRlZCBvbiAxNCBTZXB0ZW1i ZXIgMjAxNQ0KZHJhZnQtdmFuZGV2ZWxkZS1pZHItZmxvd3NwZWMtcGF0aC1yZWRpcmVjdC0wMSBj cmVhdGVkIG9uIDEyIEphbnVhcnkgMjAxNg0KZHJhZnQtdmFuZGV2ZWxkZS1pZHItZmxvd3NwZWMt cGF0aC1yZWRpcmVjdC0wMiBjcmVhdGVkIG9uIDE3IE1hcmNoIDIwMTYNCg0KZHJhZnQtbGktaWRy LWZsb3dzcGVjLXJlZGlyZWN0LWdlbmVyYWxpemVkLXNpZC0wMCBjcmVhdGVkIG9uIDIxIE1hcmNo IDIwMTYNCg0KDQogW1JlcGx5IDAxXQ0KVGhlIGlkZWEgb2YgZHJhZnQtbGktaWRyLWZsb3dzcGVj LXJlZGlyZWN0LWdlbmVyYWxpemVkLXNpZCBoYWQgaW5pdGlhbGx5IGJlZW4gcHJlc2VudGVkIGlu IHRoZSBJRFIgSW50ZXJpbSBNZWV0aW5nIG9mIDIwMTUtMTAtMjY6DQpodHRwczovL3d3dy5pZXRm Lm9yZy9wcm9jZWVkaW5ncy9pbnRlcmltLzIwMTUvMTAvMjYvaWRyL3NsaWRlcy9zbGlkZXMtaW50 ZXJpbS0yMDE1LWlkci0xMi04LnBkZg0KYW5kIGRpc2N1c3NlZCBpbiBJRFIgbWFpbGluZyBsaXN0 Og0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9ydGd3Zy9jdXJyZW50L21z ZzA1MTk1Lmh0bWwNCg0KQXQgT2N0IDI2LCAyMDE1LCBkcmFmdC12YW5kZXZlbGRlLWlkci1mbG93 c3BlYy1wYXRoLXJlZGlyZWN0LTAwIGRlc2NyaWJlZCB0aGUg4oCcc2VtYW50aWNzIGluZGVwZW5k ZW504oCdIHNvbHV0aW9uLCBidXQgd2UgdGhpbmsgaXQgc2hvdWxkIHNpbXVsdGFuZW91c2x5IGFk ZCDigJxzZW1hbnRpY3MgZGVwZW5kZW504oCdIHNvbHV0aW9uLiBUaGF0IGhhcHBlbmVkIGJlZm9y ZSBkcmFmdC12YW5kZXZlbGRlLWlkci1mbG93c3BlYy1wYXRoLXJlZGlyZWN0LTAxIHdoaWNoIGNy ZWF0ZWQgb24gMTIgSmFudWFyeSAyMDE2LiBBdCB0aGF0IHRpbWUsIHdlIGRvbuKAmXQgdGhpbmsg dGhhdCBhIHNlcGFyYXRlIGRvY3VtZW50IGlzIGltbWVkaWF0ZWx5IG5lZWRlZC4NCg0KQWZ0ZXIg ZHJhZnQtdmFuZGV2ZWxkZS1pZHItZmxvd3NwZWMtcGF0aC1yZWRpcmVjdC0wMSBjcmVhdGVkLCB3 ZSBub3RpY2UgdGhhdCBpdCBkaWQgbm90IGludGVncmF0ZSDigJxzZW1hbnRpY3MgZGVwZW5kZW50 4oCdIHNvbHV0aW9uLCBidXQgYXMgcGVyIG91ciBSZXNlYXJjaCBhbmQgZGV2ZWxvcG1lbnQgdGVh beKAmXMgb3Bpbmlvbiwgd2UgbmVlZCB0aGUg4oCcc2VtYW50aWNzIGRlcGVuZGVudOKAnSBSZWRp cmVjdCBBY3Rpb24gc29sdXRpb24uDQoNClRoZW4g4oCcc2VtYW50aWNzIGRlcGVuZGVudOKAnSBS ZWRpcmVjdCB0byBHZW5lcmFsaXplZCBTZWdtZW50IElEIEFjdGlvbiBkb2N1bWVudGVkIGFzIGRy YWZ0LWxpLWlkci1mbG93c3BlYy1yZWRpcmVjdC1nZW5lcmFsaXplZC1zaWQuIENvaW5jaWRlbnRh bGx5LCBhdCB0aGUgc2FtZSB0aW1lLCBkcmFmdC12YW5kZXZlbGRlIGludHJvZHVjZXMg4oCcQuKA nSBiaXQgdG8gbWFwIHRoZSB2YWx1ZSBlbmNvZGVkIGluIHRoZSBnbG9iYWwgYWRtaW5pc3RyYXRv ciBmaWVsZCB0byBhIEJpbmRpbmcgU2VnbWVudCBJZGVudGlmaWVyIHZhbHVlLg0KDQpHZW5lcmFs IHNsaWRlIG9ic2VydmF0aW9ucyBhYm91dCBkcmFmdC1saS1nZW5lcmFsaXNlZC1zaWQtMDAgKHJl Zi4gZGlzY3Vzc2lvbiBzbGlkZSBmb3IgMTYgTWF5IDIwMTYpDQo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNCkRyYWZ0LWxpIGRvY3Vt ZW50cyBhIGZsb3dzcGVjIGFjdGlvbiB1c2luZyBhIG5ldyBjb21tdW5pdHkgKGdlbmVyYWxpemVk LVNJRCkuIFRoZSBleHRlbmRlZCBjb21tdW5pdHkgcHJvdmlkZXMgYSBmbG93c3BlYyBjbGllbnQg aW5mb3JtYXRpb24gdG8gbWFrZSBhIGxvY2FsIGZvcndhcmRpbmcgZGVjaXNpb24gYnkgbWVhbnMg b2YgYSBsb2NhbCBtYXBwaW5nIHRhYmxlLiBUaGUgdHdvIG1haW4gY29tcG9uZW50cyB1c2VkIGJ5 IHRoZSBmbG93c3BlYyBjbGllbnQgaXM6ICgxKSBhbiBpZGVudGlmaWVyIGFuZCAoMikgc2VtYW50 aWNzLg0KDQpEcmFmdC12YW5kZXZlbGRlIGRvY3VtZW50cyBhIGZsb3dzcGVjIGFjdGlvbiB1c2lu ZyBhIG5ldyBjb21tdW5pdHkgKEluZGlyZWN0aW9uLUlEKS4gVGhlIGV4dGVuZGVkIGNvbW11bml0 eSBwcm92aWRlcyBhIGZsb3dzcGVjIGNsaWVudCBpbmZvcm1hdGlvbiB0byBtYWtlIGEgbG9jYWwg Zm9yd2FyZGluZyBkZWNpc2lvbiBieSBtZWFucyBvZiBhIGxvY2FsIG1hcHBpbmcgdGFibGUuIFRo ZSB0d28gbWFpbiBjb21wb25lbnRzIHVzZWQgYnkgdGhlIGZsb3dzcGVjIGNsaWVudCBpczogKDEp IGFuIGlkZW50aWZpZXIgYW5kICgyKSBvcHRpb25hbGx5IHNlbWFudGljcyAoVGFibGUgc2VtYW50 aWNzICsgVHVubmVsLUlEKS4NCg0KZHJhZnQtdmFuZGV2ZWxkZS1pZHItZmxvd3NwZWMtcGF0aC1y ZWRpcmVjdC0wMiB3YXMgY3JlYXRlZCDigJxiZWZvcmUiIGRyYWZ0LWxpLWlkci1mbG93c3BlYy1y ZWRpcmVjdC1nZW5lcmFsaXplZC1zaWQtMDAgYW5kIGFjaGlldmVzIHRoZSBzYW1lIGZ1bmN0aW9u YWxpdHkgYW5kIG1vcmUuIChGb3IgZXhhbXBsZSBkcmFmdC12YW5kZXZlbGRlIGhhcyB0aGUgcG90 ZW50aWFsIHRvIHNpZ25hbCA4MTkyIHR5cGVzIG9mIHNlbWFudGljIG1hcHBpbmcgdGFibGVzIHdo aWxlIGRyYWZ0LWxpIGhhcyAyNTUsIGFub3RoZXIgZXhhbXBsZSBpcyB0aGUgVElEIGZpZWxkIHdo aWNoIGFsbG93cyBkeW5hbWljIE5leHQtTmV4dC1Ib3AgY29uc3RydWN0cyB1c2UgZm9yIEVQRSBE RG9TIHJlZGlyZWN0aW9uKS4NCltSZXBseSAwMl0NClRoZSBpZGVhIG9mIGRyYWZ0LWxpLWlkci1m bG93c3BlYy1yZWRpcmVjdC1nZW5lcmFsaXplZC1zaWQgaGFkIGluaXRpYWxseSBiZWVuIHByZXNl bnRlZCBpbiB0aGUgSURSIEludGVyaW0gTWVldGluZyBvZiAyMDE1LTEwLTI2Og0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvaW50ZXJpbS8yMDE1LzEwLzI2L2lkci9zbGlkZXMvc2xp ZGVzLWludGVyaW0tMjAxNS1pZHItMTItOC5wZGYNCmFuZCBkaXNjdXNzZWQgaW4gSURSIG1haWxp bmcgbGlzdDoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvcnRnd2cvY3Vy cmVudC9tc2cwNTE5NS5odG1sDQoNCkR1cmluZyBXRyBhZGRvcHRpb24tY2FsbCAzLzI1IHRvIDQv OCB0aGUgZm9sbG93aW5nIGhhcyBiZWVuIG1lbnRpb25lZCBieSBJZ25hczogaHR0cDovL3d3dy5p ZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2lkci9jdXJyZW50L21zZzE1NTEyLmh0bWwNCg0KIkRy YWZ0LXZhbmRldmVsZGUgY2FuIGFjaGlldmUgYWxsIHdoYXQgZHJhZnQtaGFvIGFuZCBkcmFmdC1s aSBjYW4sIGFuZCBpbiBhIG1vcmUgZmxleGlibGUgd2F5LiBIYXZpbmcgdGhlIGFiaWxpdHkgdG8g ZGVjb3VwbGUgcmVkaXJlY3Rpb24gdHVubmVsIHR5cGUgZnJvbSByZWRpcmVjdGlvbiBhY3Rpb24g aXMgYm90aCBwcmFjdGljYWwgYW5kIGV4dGVuc2libGUgLSB0aGUgYWN0dWFsIHR1bm5lbCB0byBi ZSB1c2VkIGlzIGEgbG9jYWwgb3BlcmF0aW9uYWwgZGVjaXNpb24gZm9yIGVhY2ggbmV0d29yayBl bGVtZW50LCBpdCBpcyBub3QgbmVjZXNzYXJ5IHNpZ25hbGxlZCBhdCB0aGUgc2FtZSB0aW1lIGFu ZCBieSB0aGUgc2FtZSBtZWNoYW5pc20uIERlY291cGxpbmcgc2lnbmFsbGluZyBhbmQgcmVkaXJl Y3QgcGFydHMgYWxpZ25zIHdlbGwgdG8gb3BlcmF0aW9uYWwgcHJhY3RpY2VzIG9mIHVzaW5nIHNw ZWNpZmljIHRvb2xzIGZvciBzcGVjaWZpYyB0YXNrcy4gSnVzdCB0aGF0IEJHUCBjb3VsZCBkbyB0 aGF0IGRvZXMgbm90IG5lY2VzYXNyeSBtZWFuIHRoYXQgaXQgc2hvdWxkIGJlIHVzZWQgYXMgYSBi ZXN0IGZpdC4gRnJvbSBvcGVyYXRpb25hbCBwZXJzcGVjdGl2ZSB0aGVyZSBpcyBubyBuZWVkIHRv IGhhdmUgbXVsdGlwbGUgc29sdXRpb25zIHRoYXQgdHJ5IHRvIGFkZHJlc3MgdGhlIG5hcnJvdyBw cm9ibGVtIHNwYWNlIGluIHNpbWlsYXIgeWV0IGluY29tcGF0aWJsZSB3YXlzLiBUaGVyZSBzaG91 bGQgYmUgb25lIGRvY3VtZW50IGZvciByZWRpcmVjdCwgYW5kIGRyYWZ0LXZhbmRldmVsZGUgaXMg YSBnb29kIHN0YXJ0aW5nIGJhc2UgZm9yIHRoYXQuIg0KW1JlcGx5IDAzXQ0KQXMgd2UgdW5kZXJz dGFuZO+8jERyYWZ0LXZhbmRldmVsZGUgY2Fu4oCZdCBhY2hpZXZlIHdoYXQgZHJhZnQtaGFvIGNh bu+8jGRyYWZ0LWhhbyBzcGVjaWZpZXMgdGhlIHNwZWNpZmljIHR1bm5lbCBmcm9tIEZsb3dzcGVj IENvbnRyb2xsZXIgYW5kIHRoZSByZWRpcmVjdCB0dW5uZWwgaW5mb3JtYXRpb24gaXMgZW5jb2Rl ZCBpbiBCR1AgUGF0aCBBdHRyaWJ1dGUgW1RVTk5FTEVOQ0FQU11bTVBQXSB0aGF0IGlzIGNhcnJp ZWQgaW4gdGhlIEJHUCBmbG93LXNwZWMgVVBEQVRFLg0KQ29tcGFyaXNvbiB0byBkcmFmdC12YW5k ZXZlbGRlLCBkcmFmdC1oYW8gd2lsbCBoYXZlIG1vcmUgbGl0dGxlIG1vZGlmaWNhdGlvbiB0byBl eGlzdGluZyBtZWNoYW5pc21zLCBObyBuZWVkIHRvIGRvIE1hcHBpbmcgL1JlY3Vyc2l2ZSBMb29r dXAuDQoNCklmIGRyYWZ0LXZhbmRldmVsZGUgdXNlcyBtb3JlIGJpdHMgdG8gcHJlc2VudCB0aGUg dHlwZSBvZiBzZW1hbnRpYyBpbmZvcm1hdGlvbiBhbmQgdXNlIHRoZW0gYXMgdHlwZSB2YWx1ZSBs aWtlIGRyYWZ0LWxpIGRvZXMsIG5vdCDigJxQZXIgU2VydmljZSBQZXIgQml04oCdIGFzIEJpbmRp bmcgQml0IGRlZmluZXMgaW4gdmVyc2lvbiAtMDIsIGFuZCBzdXBwb3J0IHRvIHNldHVwIHRoZSBt YXBwaW5nIHRhYmxlcyBwZXIgc2VydmljZSB0eXBlLCB3ZSB0aGluayB0aGF0IHRoZSByZXF1aXJl bWVudHMgb2YgZHJhZnQtbGkgY2FuIGJlIGFkZHJlc3NlZC4NCg0KDQpEZXRhaWwgdmlldzogc2xp ZGUgb2JzZXJ2YXRpb25zIGRyYWZ0LWxpLWdlbmVyYWxpc2VkLXNpZC0wMCBkaXNjdXNzaW9uDQo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0N Cg0KU2xpZGUgMiAob2YgdGhlIGRyYWZ0LWxpIHByZXNlbnRhdGlvbik6IEhpc3RvcnkNCj09DQoN ClRoZSBzbGlkZSBmb3JnZXRzIHRvIG1lbnRpb24gdGhhdCBkcmFmdC12YW5kZXZlbGRlIHdhcyBl bmhhbmNlZCBhbmQgcHJvZ3Jlc3NlZCBiYXNlZCB1cG9uIGNvbnN0cnVjdGl2ZSBXRyBmZWVkYmFj ay4gTXVjaCBmZWVkYmFjayBoYXMgYmVlbiBpbnRlZ3JhdGVkIGJldHdlZW4gZHJhZnQtdmFuZGV2 ZWxkZSAtMDAgdG8g4oCTMDIgQkVGT1JFIGRyYWZ04oCTbGkgZXZlbiBleGlzdGVkLiBGb3IgZXhh bXBsZToNCiogVXNlLWNhc2Ugc2NlbmFyaW/igJlzIHdlcmUgYWRkZWQNCiogIlBhdGgtaWQiIGNo YW5nZWQgdG8gIkluZGlyZWN0aW9uLWlkIg0KKiBDb25jZXB0IG9mIEluZGlyZWN0aW9uIHRhYmxl cyBoYXMgYmVlbiBhZGRlZCAoaGVuY2UgYWRkaW5nIHRoZSBjYXBhYmlsaXR5IG9mIGNvbnRleHQv c2VtYW50aWNzIHNpZ25hbGxpbmcgYWxyZWFkeSBzaW5jZSB2ZXJzaW9uIC0wMSkNCltSZXBseSAw NF0NClNvcnJ5LCBhYm91dCDigJxjb250ZXh0L3NlbWFudGljcyBzaWduYWxsaW5nIGFscmVhZHkg c2luY2UgdmVyc2lvbiAtMDHigJ0sIG1heWJlIHdlIG1pc3NlZCB0aGUgcmVsYXRlZCBkZXNjcmlw dGlvbiBvciBkaWQgbm90IHVuZGVyc3RhbmQgaXQgY29ycmVjdGx5LCBjYW4geW91IHNob3cgdXMg dGhlIHRleHQgaW4gdmVyc2lvbiAtMDE/DQoNCiogRmxvd3NwZWMgdmFsaWRhdGlvbiBpbmZvcm1h dGlvbiBpcyBhZGRlZA0KKiBzaWduYWxsaW5nIG9mIGNvbnRleHQvc2VtYW50aWNzIGlzIGFkZGVk IGJ5IGludHJvZHVjaW5nIEJpbmRpbmctU0lEIGNvbnRleHQgaWRlbnRpZmllciBhcyBhIGZpcnN0 IGV4dGVuc2lvbiBvZiBJbmRpcmVjdGlvbi1pZCBleHRlbmRlZCBjb21tdW5pdHkuDQoNCkl0IGlz IGFuIGluY29ycmVjdCBhc3N1bXB0aW9uIG9mIG5vIGNvbnRleHQgYXdhcmVuZXNzIGluIGRyYWZ0 LXZhbmRldmVsZGUuIGRyYWZ0LXZhbmRldmVsZGUtaWRyLWZsb3dzcGVjLXBhdGgtcmVkaXJlY3Qg YWRkZWQgY29udGV4dCBzdXBwb3J0IGJlZm9yZSBkcmFmdC1saSBleGlzdGVkLCBhbmQgcmFpc2Vz IHF1ZXN0aW9ucyBhYm91dCBuZXcgZWxlbWVudHMgZXhwb3NlZCB3aXRoIGRyYWZ0LWxpIGNvbXBh cmVkIHRvIGRyYWZ0LXZhbmRldmVsZGUuDQpbUmVwbHkgMDVdDQpQbGVhc2UgcmVmZXIgdG8gUmVw bHkgMDEuDQoNCihmd2l3IFRoZSBzZW1hbnRpYyBhd2FyZW5lc3Mgb2YgZHJhZnQtdmFuZGV2ZWxk ZSBpcyBtZW50aW9uZWQgYW5kIHRoZSB3ZWJleCByZWNvcmRpbmcgb2YgZHJhZnQtbGkgYmV0d2Vl biByZWNvcmRpbmcgdGltZS1zdGFtcHMgMTFtMzBzIHRvIDEzbTMwcykNCg0KDQpTbGlkZSAzIChv ZiB0aGUgZHJhZnQtbGkgcHJlc2VudGF0aW9uKQ0KPT0NCg0KTm8gbmV3IGNhcGFiaWxpdHkgaXMg ZXhwbGFpbmVkIG9uIHRoaXMgc2xpZGUgaW4gY29tcGFyaXNvbiB3aXRoIHRoZSBkcmFmdC12YW5k ZXZlbGRlLg0KSW4gZHJhZnQtdmFuZGV2ZWxkZSB0aGUgaW5mb3JtYXRpb24gZm91bmQgaW4gdGhl IGluZGlyZWN0aW9uLWlkIGlzIHVzZWQgb24gYSBmbG93c3BlYyBjbGllbnQgaW4gYSBsb2NhbCBt YXBwaW5nLXRhYmxlIChpbmRpcmVjdGlvbi1pZCB0YWJsZSkgdG8gZmluZCBsb2NhbCBmb3J3YXJk aW5nIGluZm9ybWF0aW9uLiBUaGUgbmV3IGZsb3dzcGVjIGV4dGVuZGVkIGNvbW11bml0eSBhcyBk b2N1bWVudGVkIGJ5IGRyYWZ0LXZhbmRldmVsZGUgY2FuIHByb3ZpZGUgYWxyZWFkeSBhIGZsb3dz cGVjIGNsaWVudCB0aGUgcmVxdWlyZWQgc2VtYW50aWMvY29udGV4dCBpbmZvcm1hdGlvbiAoZXhh bXBsZSBpcyB0aGUg4oCYQuKAmSBiaXQpLg0KW1JlcGx5IDA2XQ0KQWxzbywgcGxlYXNlIHJlZmVy IHRvIFJlcGx5IDAxLg0KDQpTbGlkZSA0IChvZiB0aGUgZHJhZnQtbGkgcHJlc2VudGF0aW9uKQ0K PT0NCg0KVGhlIGdvYWwgb2YgZHJhZnQtbGkgaXMgdG8gZGVmaW5lIGEg4oCcc2VtYW50aWNzIGRl cGVuZGVudOKAnSBhY3Rpb24uDQpIb3dldmVyLCBkcmFmdC12YW5kZXZlbGRlIGFscmVhZHkgYWxs b3dzIHRoYXQgZnVuY3Rpb25hbGl0eSBiZWZvcmUgZHJhZnQtbGkgZXhpc3RlZA0KW1JlcGx5IDA3 XQ0KQWxzbywgcGxlYXNlIHJlZmVyIHRvIFJlcGx5IDAxLg0KDQpTbGlkZSA1IChvZiB0aGUgZHJh ZnQtbGkgcHJlc2VudGF0aW9uKQ0KPT0NCg0KRHJhZnQtdmFuZGV2ZWxkZSBoYXMgaW5kZWVkIHRo ZSBwb3RlbnRpYWwgdG8gYmUgdXNlZCBpbiBzdWNoIGEgbWFubmVyLiBUaGUgaW50ZW5kIG9mIHRo aXMgc2xpZGUgYXQgdGhlIHRpbWUgb2YgdXNhZ2Ugd2FzIHRvIHNob3cgYW4gZXh0cmVtZSBleGFt cGxlIG9mIHRoZSBmbGV4aWJsaXR5IHRoZSB0ZWNobm9sb2d5IG9mZmVycy4gV2hlbiBmb3IgZXhh bXBsZSB1c2luZyByZWRpcmVjdGlvbiB0byBiaW5kaW5nLVNJRCAoYXMgZG9jdW1lbnRlZCBpbiBs YXRlc3QgZHJhZnQtdmFuZGV2ZWxkZSkgdGhlbiB0aGUgbG9jYWwgbWFwcGluZyB0YWJsZSBjYW4g YmUgYmFzZWQgYXJvdW5kIHRoZSBzaWduYWxsZWQgc2VtYW50aWNzLg0KW1JlcGx5IDA4XQ0KU28g RHJhZnQtdmFuZGV2ZWxkZSBwbGFubmVkIHRvIHN1cHBvcnQgdHdvIGNhdGVnb3JpZXMgb2YgdGhl IGxvY2FsIG1hcHBpbmcgdGFibGVzPw0KMSkgdGhlIGxvY2FsIG1hcHBpbmcgdGFibGUgcGVyIGRl dmljZTsNCjIpIHRoZSBsb2NhbCBtYXBwaW5nIHRhYmxlIHBlciBzZXJ2aWNlOw0KV2UgdGhpbmsg dGhhdCDigJxzZXR1cCB0aGUgbWFwcGluZyB0YWJsZXMgcGVyIHNlcnZpY2UgdHlwZeKAnSBpcyBl YXNpZXIgdG8gaW1wbGVtZW50Lg0KDQoNClNsaWRlIDYgKG9mIHRoZSBkcmFmdC1saSBwcmVzZW50 YXRpb24pDQo9PQ0KDQpEcmFmdC12YW5kZXZlbGRlIGhhcyAxMyBiaXRzIGF2YWlsYWJsZSBmb3Ig dHlwZXMsIGhlbmNlIHRoZSBwb3RlbnRpYWwgdG8gc3VwcG9ydC9zaWduYWwgMl4xMyAoPTgxOTIp IHR5cGVzIHdoZW4gdXNpbmcgdGhlIGZpZWxkIGFzIHNjYWxhciB2YWx1ZSAod2hlbiBjb21wYXJp bmcgd2l0aCBhIHBvdGVudGlhbCBmb3IgMjU1IHR5cGVzIHVzaW5nIGRyYWZ0LWxpKQ0KDQpUaGUg Y2xhaW0gbWFkZSBvbiBzbGlkZTYgdGhhdCBkcmFmdC12YW5kZXZlbGRlIGFsbG93cyBvbmx5IDEz IHR5cGUgb2Ygc2VtYW50aWMgaW5mb3JtYXRpb24gaXMgd3JvbmcgYXNzdW1wdGlvbi4NCltSZXBs eSAwOV0NClN1cmUsIGlmIGRyYWZ0LXZhbmRldmVsZGUgdXNlcyBtb3JlIGJpdHMgdG8gcHJlc2Vu dCB0aGUgdHlwZSBvZiBzZW1hbnRpYyBpbmZvcm1hdGlvbiBhbmQgdXNlIHRoZW0gYXMgdHlwZSB2 YWx1ZSBsaWtlIGRyYWZ0LWxpIGRvZXMsIG5vdCDigJxQZXIgU2VydmljZSBQZXIgQml04oCdIGFz IEJpbmRpbmcgQml0IGRlZmluZXMgaW4gZHJhZnQtdmFuZGV2ZWxkZSAgdmVyc2lvbiAtMDIuDQoN CkF0IHRoZSB0aW1lIG9mIHdyaXRpbmcsIGl0IHdhcyBmb3VuZCB1c2VmdWwgdG8gc2lnbmFsIGJp bmRpbmcgU0lEIHVzZWZ1bCBzZW1hbnRpYyDigKYgV2UgZGVjaWRlZCB0byBsZWF2ZSB0aGUgcmVt YWluaW5nIGJpdHMgcmVzZXJ2ZWQvb3BlbiBmb3IgZGlzY3Vzc2lvbiBvbiBob3cgdG8gYmVzdCB1 c2UgdGhlIGZpZWxkIGluc3RlYWQuDQpNYXliZSB0aGUgV0cgZmVlbHMgaXQgaXMgYmVzdCB0byB1 c2Ugb25seSBhIGZldyBiaXRzIGZvciBzZW1hbnRpY3MgYW5kIGtlZXAgdGhlIHJlbWFpbmRlciBy ZXNlcnZlZCBmb3IgZnV0dXJlIHVzZS4NCg0KS2luZCBSZWdhcmRzLA0KRy8NCg0KDQoNCkZyb206 IElkciA8aWRyLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnPj4g b24gYmVoYWxmIG9mIFN1c2FuIEhhcmVzIDxzaGFyZXNAbmR6aC5jb208bWFpbHRvOnNoYXJlc0Bu ZHpoLmNvbT4+DQpEYXRlOiBGcmlkYXkgMTMgTWF5IDIwMTYgYXQgMTI6NDYNClRvOiAiaWRyQGll dGYub3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+IiA8aWRyQGlldGYub3JnPG1haWx0bzppZHJAaWV0 Zi5vcmc+Pg0KU3ViamVjdDogW0lkcl0gSURSIGludGVyaW0gb24gTWF5IDE2dGggLSB3ZWJleCwg cXVlc3Rpb25zIGZvciBtZWV0aW5nLCBhbmQgcmVjb3JkaW5ncy4NCg0KVGhlIHRpbWUgb2YgdGhl IGludGVyaW0gaXMgMjI6MDAtMjM6MDAgRURUIG9uIE1heSAxNnRoLg0KDQpUaGUgaW50ZXJpbSB3 aWxsIGRpc2N1c3MgdGhlIGZvbGxvd2luZyB0d28gZHJhZnRzIGluIG9yZGVyIHRvIGNyZWF0ZSBh IFdHIHNvbHV0aW9uOg0KDQoNCsK3ICAgICAgICAgZHJhZnQtdmFuZGV2ZWxkZS1pZHItZmxvd3Nw ZWMtcGF0aC1yZWRpcmVjdCwgYW5kDQoNCsK3ICAgICAgICAgZHJhZnQtbGktaWRyLWZsb3dzcGVj LXJlZGlyZWN0LWdlbmVyYWxpemVkLXNpZA0KDQpTb21lIG9mIHRoZSBRdWVzdGlvbnMgdGhhdCB3 aWxsIGJlIGRpc2N1c3MgYXJlIGluY2x1ZGVkIGJlbG93LiAgUGxlYXNlIHJldmlldyB0aGUgcHJl LXJlY29yZGluZyBwcmVzZW50YXRpb25zIHByaW9yIHRvIHRoZSBtZWV0aW5nLiAgIFRoZSBDaGFp cnMgZW5jb3VyYWdlIGRpc2N1c3Npb24gb2YgdGhlc2UgcXVlc3Rpb25zIG9uIHRoZSBsaXN0IGJl Zm9yZSwgZHVyaW5nLCBhbmQgYWZ0ZXIgdGhlIG1lZXRpbmcuDQoNClN1ZSBhbmQgSm9obg0KDQo9 PT09PT09PT09PT09PT09PT09PT09PT0NCg0KQWdlbmRhIGZvciBJRFIgVmlydHVhbCBJbnRlcmlt IE1lZXRpbmcNCg0KTWF5IDE2LCAyMDE2DQoyMjowMCAtIDIzOjAwIEVEVA0KDQpXZWJFeDogaHR0 cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTliZTQ4MWQxOTk4OGRkMWI1NDVi ZTY3NTlhZWUyNjdiDQpNZWV0aW5nIG51bWJlcjogICAgICAgICAgICA2NDkgMjM1IDQxMQ0KTWVl dGluZyBwYXNzd29yZDogICAgICAgICBKZzY2ZDJwbQ0KSm9pbiBieSBwaG9uZQ0KMS04NzctNjY4 LTQ0OTMgQ2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5hZGEpDQoxLTY1MC00NzktMzIw OCBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpDQpBY2Nlc3MgY29kZTogNjQ5IDIzNSA0 MTENCg0KUXVlc3Rpb25zIGZvciBtZWV0aW5nOg0KDQpTdWJtaXR0ZWQgYnkgKEVyaWMgV3UpDQox LiBSZWRpcmVjdC10by1TcGVjaWZpYy1UdW5uZWwgd2l0aCBCR1AgUGF0aCBBdHRyaWJ1dGUgW1RV Tk5FTEVOQ0FQU11bTVBQXSBhbmQNCiAgUmVkaXJlY3QtdG8tSUlEL0dTSUQsIFJlcXVpcmVkIGJ5 IGRpZmZlcmVudCB1c2UgY2FzZXMsIGNhbiB3ZSBoYXZlIHR3byBkb2NzIGluIElEUiBJbiBwYXJh bGxlbD8NCiAgW0NvbXBhcmlzb24gdG8gUmVkaXJlY3QtdG8tSUlEL0dTSUQgLCBkcmFmdC1oYW8g d2lsbCBoYXZlIG1vcmUgbGl0dGxlIG1vZGlmaWNhdGlvbg0KICB0byBleGlzdGluZyBtZWNoYW5p c21zLCBObyBuZWVkIHRvIGRvIE1hcHBpbmcgL1JlY3Vyc2l2ZSBMb29rdXAuXQ0KDQoyLiAgRm9y IElJRC9HU0lELCBvbmUgbWFwcGluZyB0YWJsZSBmb3INCiAgYWxsIGtpbmRzIG9mIHNlZ21lbnRz L2ZvcndhcmRpbmctZW50aXRpZXMgdnMuIG9uZSBtYXBwaW5nIHRhYmxlDQogIHBlciBzZWdtZW50 cy9mb3J3YXJkaW5nLWVudGl0aWVzIHR5cGUsIHNob3VsZCB3ZSBzdXBwb3J0IGJvdGg/DQoNCkNo YWlyIFF1ZXN0aW9uczoNCg0KMSkgRG9lcyB0aGUgV0cgZmVlbCB3ZSBuZWVkIHRoZSBmb2xsb3dp bmcgZm9yIFJGQzU1NzViaXMgKEREb1MpDQogIGEpIFJlZGlyZWN0aW9uIHRvIFZSRiwNCiAgYikg UmVkaXJlY3Rpb24gdG8gSW5kaXJlY3Rpb24gdG8gSVAsIGFuZA0KICBjKSBSZWRpcmVjdGlvbiB0 byBTZXJ2aWNlIChuZXcpPw0KDQoyKSBJZiB0aGUgV0cgZGVzaXJlcyByZWRpcmVjdGlvbiB0byBT ZXJ2aWNlIHJvdXRpbmcsIGRvZXMgdGhlIFdHIGRlc2lyZQ0KYSkgTmV4dC1Ib3AgdHVubmVsIHN1 cHBvcnQ/IC0NCmIpIE5leHQtSG9wIFRFIFR1bm5lbCBzdXBwb3J0Pw0KIGMpIE5lc3RlZCBUdW5u ZWwgc3VwcG9ydD8NCiBkKSBOZXh0LU5leHQgSG9wIFR1bm5lbCBTdXBwb3J0Pw0KIGUpIFJvdXRl ciBsb2NhbGl6ZWQgVHVubmVsIHJlY3Vyc2lvbj8NCiBmKSBUdW5uZWwgRW5jYXAgUmVjdXJzaW9u Og0KDQozKSBXaGF0IHBpZWNlcyBvZiB0aGUgcHJvcG9zZWQgc29sdXRpb25zIGhhdmUgYmVlbiBp bXBsZW1lbnRlZA0KICAgYW5kL29yIGRlcGxveWVkPw0KDQoNClByZXNlbnRhdGlvbnMgKHByZXJl Y29yZGVkLCBwbGVhc2UgcmV2aWV3IHByaW9yIHRvIG1lZXRpbmcpOg0KLSBkcmFmdC12YW5kZXZl bGRlLWlkci1mbG93c3BlYy1wYXRoLXJlZGlyZWN0DQogIEd1bnRlciBWYW4gRGUgVmVsZGUNCiAg MjEgbWludXRlcw0KICBodHRwczovL2lldGYud2ViZXguY29tL2lldGYvbGRyLnBocD9SQ0lEPWUw MWQ2MjY2MTA4NWY2NjBmNDcwZmVkZGQ5YmYyNjZmDQoNCnByZXNlbnRhdGlvbiBhdDoNCmh0dHBz Oi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzL2ludGVyaW0vMjAxNi8wNS8xNi9pZHIvc2xpZGVz L3NsaWRlcy1pbnRlcmltLTIwMTYtaWRyLTUtMC5wZGYNCg0KDQpkcmFmdC1saS1pZHItZmxvd3Nw ZWMtcmVkaXJlY3QtZ2VuZXJhbGl6ZWQtc2lkDQpFcmljIFd1DQoyMCBtaW51dGVzDQoNClN0cmVh bWluZyByZWNvcmRpbmcgbGluazoNCmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9sZHIucGhw P1JDSUQ9Yzg2MTVhYTg0NTgwMWExZTRiNzljYjE3MDhhMDQ0ODQNCkRvd25sb2FkIHJlY29yZGlu ZyBsaW5rOg0KaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2xzci5waHA/UkNJRD00YmQ1MDQz Mjk3MjdkMmE4MTFjOWNiMGM5YmM3MTNkOA0KDQpwcmVzZW50YXRpb24gYXQ6DQpodHRwczovL3d3 dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy9pbnRlcmltLzIwMTYvMDUvMTYvaWRyL3NsaWRlcy9zbGlk ZXMtaW50ZXJpbS0yMDE2LWlkci01LTEucGRmDQoNCg== --_000_19AB2A007F56DB4E8257F949A2FB9858AA1BD619NKGEML515MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkhlbHZldGljYSBOZXVlIjsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAx IDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9y bWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxp Lk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo5LjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFn cmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1h cmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJ bWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uQ2hhcg0KCXttc28t c3R5bGUtbmFtZToi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazrmibnms6jmoYbmlofmnKw7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMg Ki8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjEyNDk5OTY5MjI7DQoJbXNvLWxpc3QtdHlwZTpo eWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNzA4MzgwMjU4IDY3Njk4Njg5IDY3Njk4 NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4Njkx IDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDozOC4zNXB0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxl dmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJbWFyZ2luLWxlZnQ6NzQuMzVwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1s ZWZ0OjExMC4zNXB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoxNDYuMzVwdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCW1hcmdpbi1sZWZ0OjE4Mi4zNXB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6 MjE4LjM1cHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjI1NC4zNXB0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ bWFyZ2luLWxlZnQ6MjkwLjM1cHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWls eToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDozMjYu MzVwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxNzAzOTQyMjAxOw0KCW1zby1saXN0LXR5cGU6aHlicmlk Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoyMTg1NjExNzYgLTExNDg0MTc5MTQgNjc2OTg2OTEg Njc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2 OTg2OTM7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJn aW4tbGVmdDoxOC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OuWui+S9kzt9DQpv bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPkhpIEd1bnRl ciw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3IgeW91 ciBjb21tZW50cywgUGxlYXNlIHNlZSByZXNwb25zZXMgaW5saW5lLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+QmVzdCAmbmJzcDtSZWdhcmRzLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj5TaHVud2FuICZhbXA7IEVyaWMuV3U8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OuWui+S9kyI+5Y+R5Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L 5L2TIj4gSWRyIFttYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmddDQo8L3NwYW4+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TIj7ku6PooaggPC9zcGFu PjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk65a6L5L2TIj5WYW4gRGUgVmVsZGUsIEd1bnRlciAoTm9raWEgLSBCRSk8YnI+DQo8L3NwYW4+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TIj7lj5Hp gIHml7bpl7Q8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTrlrovkvZMiPiAyMDE2 PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kyI+ 5bm0PHNwYW4gbGFuZz0iRU4tVVMiPjU8L3NwYW4+5pyIPHNwYW4gbGFuZz0iRU4tVVMiPjEzPC9z cGFuPuaXpTxzcGFuIGxhbmc9IkVOLVVTIj4NCiAyMjo1Njxicj4NCjwvc3Bhbj48Yj7mlLbku7bk uro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBpZHJA aWV0Zi5vcmc8YnI+DQo8L3NwYW4+PGI+5Li76aKYPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+ PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gUmU6IFtJZHJdIElEUiBpbnRlcmltIG9uIE1heSAxNnRo IC0gd2ViZXgsIHF1ZXN0aW9ucyBmb3IgbWVldGluZywgYW5kIHJlY29yZGluZ3MuPG86cD48L286 cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Eg TmV1ZSZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+UHJlLWxpbWluYXIgY29t bWVudHPigKYuLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj5CZWZvcmUgZW5nYWdpbmcgd2l0aCBteSBmZWVkYmFjayBhbmQg YWRkcmVzc2luZyB0aGUgZGlzY3Vzc2lvbiBzbGlkZXMsIGkgd291bGQgbGlrZSB0byB0aGFuayBi b3RoIFN1ZSBhbmQgSm9obiBmb3IgZ29pbmcgdGhyb3VnaCB0aGUgZWZmb3J0IGFuZA0KIHRpbWUg dG8gdHJ5IHRvIG1ha2UgdGhlIHJlY29yZGluZ3MgYXMgZ29vZCBhcyBwb3NzaWJsZSBhbmQgaW52 ZXN0aW5nIG5vbi10cml2aWFsIGFtb3VudHMgb2YgdGltZSB0byBnZXQgdGhlIGpvYiBkb25lLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj5JIHdvdWxkIGFsc28gbGlrZSB0byB0aGFua3MgRXJpYyBXdSB0byBnbyB0aHJvdWdo IHRoZSBleGVyY2lzZSBvZiByZWNvcmRpbmcgaGlzIHByZXNlbnRhdGlvbiBvZiB0aGUgc2xpZGVz LiBJIHdlbnQgdGhyb3VnaCB0aGUgc2FtZSBleGVyY2lzZSBhbmQNCiBldmVuIHRob3VnaCB0aGVy ZSB3ZXJlIGxlc3Mgb3BlcmF0aW9uYWwgaXNzdWVzIHRvIGRlYWwgd2l0aCBkdXJpbmcgbXkgcmVj b3JkaW5nLCBpdCBpcyBhIG5vbi10cml2aWFsIHRhc2sgdG8gc3BlYWsgdG8gYSBzY3JlZW4gYW5k IG5vdCB0byBhbiBhdWRpZW5jZS4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZx dW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSBOZXVlJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Db21tZW50czogV29y a2luZyBzbGlkZXMgZGlzY3Vzc2lvbiBvZiB0aGUgMTYgTWF5IDIwMTYgSW50ZXJpbSBJRFIgbWVl dGluZzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPi0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSBOZXVlJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5UaW1lbGluZSBpbmZvPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTrlrovk vZM7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2si Pj09PT09PT09PT08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNr Ij5kcmFmdC12YW5kZXZlbGRlLWlkci1mbG93c3BlYy1wYXRoLXJlZGlyZWN0LTAwIGNyZWF0ZWQg b24gMTQgU2VwdGVtYmVyIDIwMTU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs YWNrIj5kcmFmdC12YW5kZXZlbGRlLWlkci1mbG93c3BlYy1wYXRoLXJlZGlyZWN0LTAxIGNyZWF0 ZWQgb24gMTIgSmFudWFyeSAyMDE2PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpi bGFjayI+ZHJhZnQtdmFuZGV2ZWxkZS1pZHItZmxvd3NwZWMtcGF0aC1yZWRpcmVjdC0wMiBjcmVh dGVkIG9uIDE3IE1hcmNoIDIwMTY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFj ayI+ZHJhZnQtbGktaWRyLWZsb3dzcGVjLXJlZGlyZWN0LWdlbmVyYWxpemVkLXNpZC0wMCBjcmVh dGVkIG9uIDIxIE1hcmNoIDIwMTY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMDBCMEYwIj4mbmJz cDtbUmVwbHkgMDFdIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzAwQjBGMCI+VGhlIGlkZWEgb2YgZHJh ZnQtbGktaWRyLWZsb3dzcGVjLXJlZGlyZWN0LWdlbmVyYWxpemVkLXNpZCBoYWQgaW5pdGlhbGx5 IGJlZW4gcHJlc2VudGVkIGluIHRoZSBJRFIgSW50ZXJpbSBNZWV0aW5nIG9mIDIwMTUtMTAtMjY6 DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMwMEIwRjAiPmh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2Nl ZWRpbmdzL2ludGVyaW0vMjAxNS8xMC8yNi9pZHIvc2xpZGVzL3NsaWRlcy1pbnRlcmltLTIwMTUt aWRyLTEyLTgucGRmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMDBCMEYwIj5hbmQgZGlzY3Vzc2VkIGlu IElEUiBtYWlsaW5nIGxpc3Q6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMDBCMEYwIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3J0Z3dnL2N1cnJlbnQvbXNnMDUxOTUuaHRtbDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6IzAwQjBGMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMDBC MEYwIj5BdCBPY3QgMjYsIDIwMTUsIGRyYWZ0LXZhbmRldmVsZGUtaWRyLWZsb3dzcGVjLXBhdGgt cmVkaXJlY3QtMDAgZGVzY3JpYmVkIHRoZSDigJxzZW1hbnRpY3MgaW5kZXBlbmRlbnTigJ0gc29s dXRpb24sIGJ1dCB3ZSB0aGluayBpdCBzaG91bGQgc2ltdWx0YW5lb3VzbHkgYWRkIOKAnHNlbWFu dGljcyBkZXBlbmRlbnTigJ0gc29sdXRpb24uIFRoYXQgaGFwcGVuZWQNCiBiZWZvcmUgZHJhZnQt dmFuZGV2ZWxkZS1pZHItZmxvd3NwZWMtcGF0aC1yZWRpcmVjdC0wMSB3aGljaCBjcmVhdGVkIG9u IDEyIEphbnVhcnkgMjAxNi4gQXQgdGhhdCB0aW1lLCB3ZSBkb27igJl0IHRoaW5rIHRoYXQgYSBz ZXBhcmF0ZSBkb2N1bWVudCBpcyBpbW1lZGlhdGVseSBuZWVkZWQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv cjojMDBCMEYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMwMEIwRjAiPkFmdGVyIGRyYWZ0 LXZhbmRldmVsZGUtaWRyLWZsb3dzcGVjLXBhdGgtcmVkaXJlY3QtMDEgY3JlYXRlZCwgd2Ugbm90 aWNlIHRoYXQgaXQgZGlkIG5vdCBpbnRlZ3JhdGUg4oCcc2VtYW50aWNzIGRlcGVuZGVudOKAnSBz b2x1dGlvbiwgYnV0IGFzIHBlciBvdXIgUmVzZWFyY2ggYW5kIGRldmVsb3BtZW50IHRlYW3igJlz IG9waW5pb24sIHdlIG5lZWQgdGhlDQog4oCcc2VtYW50aWNzIGRlcGVuZGVudOKAnSBSZWRpcmVj dCBBY3Rpb24gc29sdXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMDBCMEYwIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImNvbG9yOiMwMEIwRjAiPlRoZW4g4oCcc2VtYW50aWNzIGRlcGVuZGVudOKAnSBS ZWRpcmVjdCB0byBHZW5lcmFsaXplZCBTZWdtZW50IElEIEFjdGlvbiBkb2N1bWVudGVkIGFzIGRy YWZ0LWxpLWlkci1mbG93c3BlYy1yZWRpcmVjdC1nZW5lcmFsaXplZC1zaWQuIENvaW5jaWRlbnRh bGx5LCBhdCB0aGUgc2FtZSB0aW1lLCBkcmFmdC12YW5kZXZlbGRlIGludHJvZHVjZXMg4oCcQuKA nQ0KIGJpdCB0byBtYXAgdGhlIHZhbHVlIGVuY29kZWQgaW4gdGhlIGdsb2JhbCBhZG1pbmlzdHJh dG9yIGZpZWxkIHRvIGEgQmluZGluZyBTZWdtZW50IElkZW50aWZpZXIgdmFsdWUuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMwMEIwRjAiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPkdlbmVyYWwgc2xpZGUgb2JzZXJ2YXRp b25zIGFib3V0IGRyYWZ0LWxpLWdlbmVyYWxpc2VkLXNpZC0wMCAocmVmLiBkaXNjdXNzaW9uIHNs aWRlIGZvciAxNiBNYXkgMjAxNik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs YWNrIj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+RHJhZnQtbGkgZG9jdW1lbnRz IGEgZmxvd3NwZWMgYWN0aW9uIHVzaW5nIGEgbmV3IGNvbW11bml0eSAoZ2VuZXJhbGl6ZWQtU0lE KS4gVGhlIGV4dGVuZGVkIGNvbW11bml0eSBwcm92aWRlcyBhIGZsb3dzcGVjIGNsaWVudCBpbmZv cm1hdGlvbiB0byBtYWtlIGEgbG9jYWwgZm9yd2FyZGluZyBkZWNpc2lvbiBieSBtZWFucyBvZiBh IGxvY2FsIG1hcHBpbmcNCiB0YWJsZS4gVGhlIHR3byBtYWluIGNvbXBvbmVudHMgdXNlZCBieSB0 aGUgZmxvd3NwZWMgY2xpZW50IGlzOiAoMSkgYW4gaWRlbnRpZmllciBhbmQgKDIpIHNlbWFudGlj cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5E cmFmdC12YW5kZXZlbGRlIGRvY3VtZW50cyBhIGZsb3dzcGVjIGFjdGlvbiB1c2luZyBhIG5ldyBj b21tdW5pdHkgKEluZGlyZWN0aW9uLUlEKS4gVGhlIGV4dGVuZGVkIGNvbW11bml0eSBwcm92aWRl cyBhIGZsb3dzcGVjIGNsaWVudCBpbmZvcm1hdGlvbiB0byBtYWtlIGEgbG9jYWwgZm9yd2FyZGlu ZyBkZWNpc2lvbiBieSBtZWFucyBvZiBhDQogbG9jYWwgbWFwcGluZyB0YWJsZS4gVGhlIHR3byBt YWluIGNvbXBvbmVudHMgdXNlZCBieSB0aGUgZmxvd3NwZWMgY2xpZW50IGlzOiAoMSkgYW4gaWRl bnRpZmllciBhbmQgKDIpIG9wdGlvbmFsbHkgc2VtYW50aWNzIChUYWJsZSBzZW1hbnRpY3MgJiM0 MzsgVHVubmVsLUlEKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Y29sb3I6YmxhY2siPmRyYWZ0LXZhbmRldmVsZGUtaWRyLWZsb3dzcGVjLXBhdGgtcmVkaXJlY3Qt MDImbmJzcDt3YXMgY3JlYXRlZCZuYnNwO+KAnGJlZm9yZSZxdW90OyZuYnNwO2RyYWZ0LWxpLWlk ci1mbG93c3BlYy1yZWRpcmVjdC1nZW5lcmFsaXplZC1zaWQtMDAgYW5kIGFjaGlldmVzIHRoZSBz YW1lIGZ1bmN0aW9uYWxpdHkgYW5kIG1vcmUuIChGb3IgZXhhbXBsZSBkcmFmdC12YW5kZXZlbGRl IGhhcw0KIHRoZSBwb3RlbnRpYWwgdG8gc2lnbmFsIDgxOTIgdHlwZXMgb2Ygc2VtYW50aWMgbWFw cGluZyB0YWJsZXMgd2hpbGUgZHJhZnQtbGkgaGFzIDI1NSwgYW5vdGhlciBleGFtcGxlIGlzIHRo ZSBUSUQgZmllbGQgd2hpY2ggYWxsb3dzIGR5bmFtaWMgTmV4dC1OZXh0LUhvcCBjb25zdHJ1Y3Rz IHVzZSBmb3IgRVBFIEREb1MgcmVkaXJlY3Rpb24pLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGluZS1oZWlnaHQt YWx0OjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EgTmV1ZSZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMDBCMEYwIj5bUmVwbHkg MDJdDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLWxpbmUtaGVpZ2h0LWFsdDowcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6 IzAwQjBGMCI+VGhlIGlkZWEgb2YNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv bG9yOiMwMEIwRjAiPmRyYWZ0LWxpLWlkci1mbG93c3BlYy1yZWRpcmVjdC1nZW5lcmFsaXplZC1z aWQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EgTmV1ZSZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMDBCMEYwIj4gaGFkIGk8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMDBCMEYwIj5uaXRpYWxseSBi ZWVuIHByZXNlbnRlZA0KIGluIHRoZSBJRFIgSW50ZXJpbSBNZWV0aW5nIG9mIDIwMTUtMTAtMjY6 IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bGluZS1oZWlnaHQtYWx0OjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMDBC MEYwIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy9pbnRlcmltLzIw MTUvMTAvMjYvaWRyL3NsaWRlcy9zbGlkZXMtaW50ZXJpbS0yMDE1LWlkci0xMi04LnBkZiI+PHNw YW4gc3R5bGU9ImNvbG9yOiMwMEIwRjAiPmh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdz L2ludGVyaW0vMjAxNS8xMC8yNi9pZHIvc2xpZGVzL3NsaWRlcy1pbnRlcmltLTIwMTUtaWRyLTEy LTgucGRmPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLWxpbmUtaGVpZ2h0LWFsdDowcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iY29sb3I6IzAwQjBGMCI+YW5kIGRpc2N1c3NlZCBpbiBJRFIgbWFpbGluZyBsaXN0Ojxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGlu ZS1oZWlnaHQtYWx0OjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMDBCMEYw Ij48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3J0Z3dnL2N1 cnJlbnQvbXNnMDUxOTUuaHRtbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwRjAiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvcnRnd2cvY3VycmVudC9tc2cwNTE5NS5odG1s PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5EdXJpbmcgV0cgYWRkb3B0aW9uLWNhbGwgMy8y NSB0byA0LzggdGhlIGZvbGxvd2luZyBoYXMgYmVlbiBtZW50aW9uZWQgYnkgSWduYXM6DQo8YSBo cmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvaWRyL2N1cnJlbnQvbXNn MTU1MTIuaHRtbCI+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2lkci9jdXJy ZW50L21zZzE1NTEyLmh0bWw8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjMwLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2si PiZxdW90Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkRyYWZ0LXZh bmRldmVsZGUgY2FuIGFjaGlldmUgYWxsIHdoYXQgZHJhZnQtaGFvIGFuZCBkcmFmdC1saSBjYW4s IGFuZCBpbiBhIG1vcmUgZmxleGlibGUgd2F5Lg0KIEhhdmluZyB0aGUgYWJpbGl0eSB0byBkZWNv dXBsZSByZWRpcmVjdGlvbjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4gdHVubmVsIHR5 cGUgZnJvbSByZWRpcmVjdGlvbiBhY3Rpb24gaXMgYm90aCBwcmFjdGljYWwgYW5kIGV4dGVuc2li bGUgLSB0aGUgYWN0dWFsIHR1bm5lbCB0byBiZSB1c2VkIGlzIGEgbG9jYWwgb3BlcmF0aW9uYWwg ZGVjaXNpb24gZm9yIGVhY2ggbmV0d29yayBlbGVtZW50LCBpdCBpcyBub3QgbmVjZXNzYXJ5IHNp Z25hbGxlZA0KIGF0IHRoZSBzYW1lIHRpbWUgYW5kIGJ5IHRoZSBzYW1lIG1lY2hhbmlzbS4gRGVj b3VwbGluZyBzaWduYWxsaW5nIGFuZCByZWRpcmVjdCBwYXJ0cyBhbGlnbnMgd2VsbCB0byBvcGVy YXRpb25hbCBwcmFjdGljZXMgb2YgdXNpbmcgc3BlY2lmaWMgdG9vbHMgZm9yIHNwZWNpZmljIHRh c2tzLiBKdXN0IHRoYXQgQkdQIGNvdWxkIGRvIHRoYXQgZG9lcyBub3QgbmVjZXNhc3J5IG1lYW4g dGhhdCBpdCBzaG91bGQgYmUgdXNlZCBhcyBhIGJlc3QgZml0Lg0KIEZyb20gb3BlcmF0aW9uYWwg cGVyc3BlY3RpdmUgdGhlcmUgaXMgbm8gbmVlZCB0byBoYXZlIG11bHRpcGxlIHNvbHV0aW9ucyB0 aGF0IHRyeSB0byBhZGRyZXNzIHRoZSBuYXJyb3cgcHJvYmxlbSBzcGFjZSBpbiBzaW1pbGFyIHll dCBpbmNvbXBhdGlibGUgd2F5cy4gVGhlcmUgc2hvdWxkIGJlIG9uZSBkb2N1bWVudCBmb3IgcmVk aXJlY3QsIGFuZCBkcmFmdC12YW5kZXZlbGRlIGlzIGEgZ29vZCBzdGFydGluZyBiYXNlIGZvciB0 aGF0LiZxdW90Ozwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OiMwMEIwRjAiPltSZXBseSAwM10gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMDBCMEYwIj5BcyB3ZSB1 bmRlcnN0YW5kPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTrlrovkvZM7Y29sb3I6IzAw QjBGMCI+77yMPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzAwQjBGMCI+ RHJhZnQtdmFuZGV2ZWxkZSBjYW7igJl0IGFjaGlldmUgd2hhdCBkcmFmdC1oYW8gY2FuPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTrlrovkvZM7Y29sb3I6IzAwQjBGMCI+77yMPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzAwQjBGMCI+ZHJhZnQtaGFvDQogc3Bl Y2lmaWVzIHRoZSBzcGVjaWZpYyB0dW5uZWwgZnJvbSBGbG93c3BlYyBDb250cm9sbGVyIGFuZCB0 aGUgcmVkaXJlY3QgdHVubmVsIGluZm9ybWF0aW9uIGlzIGVuY29kZWQgaW4gQkdQIFBhdGggQXR0 cmlidXRlIFtUVU5ORUxFTkNBUFNdW01QUF0gdGhhdCBpcyBjYXJyaWVkIGluIHRoZSBCR1AgZmxv dy1zcGVjIFVQREFURS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMwMEIwRjAiPkNvbXBhcmlzb24gdG8g ZHJhZnQtdmFuZGV2ZWxkZSwgZHJhZnQtaGFvIHdpbGwgaGF2ZSBtb3JlIGxpdHRsZSBtb2RpZmlj YXRpb24gdG8gZXhpc3RpbmcgbWVjaGFuaXNtcywgTm8gbmVlZCB0byBkbyBNYXBwaW5nIC9SZWN1 cnNpdmUgTG9va3VwLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbGluZS1oZWlnaHQtYWx0OjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OywmcXVvdDtzZXJpZiZxdW90 Oztjb2xvcjojMDBCMEYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMwMEIwRjAiPklmIGRy YWZ0LXZhbmRldmVsZGUgdXNlcyBtb3JlIGJpdHMgdG8gcHJlc2VudCB0aGUgdHlwZSBvZiBzZW1h bnRpYyBpbmZvcm1hdGlvbiBhbmQgdXNlIHRoZW0gYXMgdHlwZSB2YWx1ZSBsaWtlIGRyYWZ0LWxp IGRvZXMsIG5vdCDigJxQZXIgU2VydmljZSBQZXIgQml04oCdIGFzIEJpbmRpbmcgQml0IGRlZmlu ZXMgaW4gdmVyc2lvbiAtMDIsIGFuZA0KIHN1cHBvcnQgdG8gc2V0dXAgdGhlIG1hcHBpbmcgdGFi bGVzIHBlciBzZXJ2aWNlIHR5cGUsIHdlIHRoaW5rIHRoYXQgdGhlIHJlcXVpcmVtZW50cyBvZiBk cmFmdC1saSBjYW4gYmUgYWRkcmVzc2VkLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 Oztjb2xvcjojMDBCMEYwIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzAw QjBGMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5EZXRhaWwgdmlldzog c2xpZGUgb2JzZXJ2YXRpb25zIGRyYWZ0LWxpLWdlbmVyYWxpc2VkLXNpZC0wMCBkaXNjdXNzaW9u PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTrlrovkvZM7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFj ayI+U2xpZGUgMiAob2YgdGhlIGRyYWZ0LWxpIHByZXNlbnRhdGlvbik6IEhpc3RvcnkmbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9y OmJsYWNrIj49PTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPlRoZSBzbGlkZSBmb3JnZXRzIHRvIG1lbnRpb24g dGhhdCBkcmFmdC12YW5kZXZlbGRlIHdhcyBlbmhhbmNlZCBhbmQgcHJvZ3Jlc3NlZCBiYXNlZCB1 cG9uIGNvbnN0cnVjdGl2ZSBXRyBmZWVkYmFjay4gTXVjaCBmZWVkYmFjayBoYXMgYmVlbiBpbnRl Z3JhdGVkIGJldHdlZW4gZHJhZnQtdmFuZGV2ZWxkZSAtMDAgdG8NCiDigJMwMiBCRUZPUkUgZHJh ZnTigJNsaSBldmVuIGV4aXN0ZWQuIEZvciBleGFtcGxlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+KiBVc2UtY2FzZSBzY2VuYXJpb+KA mXMgd2VyZSBhZGRlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtjb2xvcjpibGFjayI+KiAmcXVvdDtQYXRoLWlkJnF1b3Q7IGNoYW5nZWQgdG8gJnF1b3Q7SW5k aXJlY3Rpb24taWQmcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Y29sb3I6YmxhY2siPiogQ29uY2VwdCBvZiBJbmRpcmVjdGlvbiB0YWJsZXMgaGFzIGJl ZW4gYWRkZWQgKGhlbmNlIGFkZGluZyB0aGUgY2FwYWJpbGl0eSBvZiBjb250ZXh0L3NlbWFudGlj cyBzaWduYWxsaW5nIGFscmVhZHkgc2luY2UgdmVyc2lvbiAtMDEpPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saW5lLWhlaWdodC1hbHQ6MHB0 Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMwMEIwRjAiPltSZXBseSAwNF0NCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGlu ZS1oZWlnaHQtYWx0OjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMDBCMEYw Ij5Tb3JyeSwgYWJvdXQg4oCcY29udGV4dC9zZW1hbnRpY3Mgc2lnbmFsbGluZyBhbHJlYWR5IHNp bmNlIHZlcnNpb24gLTAx4oCdLCBtYXliZSB3ZSBtaXNzZWQgdGhlIHJlbGF0ZWQgZGVzY3JpcHRp b24gb3IgZGlkIG5vdCB1bmRlcnN0YW5kIGl0IGNvcnJlY3RseSwgY2FuIHlvdSBzaG93IHVzDQog dGhlIHRleHQgaW4gdmVyc2lvbiAtMDE/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtjb2xvcjpibGFjayI+KiBGbG93c3BlYyB2YWxpZGF0aW9uIGluZm9ybWF0aW9uIGlz IGFkZGVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9y OmJsYWNrIj4qIHNpZ25hbGxpbmcgb2YgY29udGV4dC9zZW1hbnRpY3MgaXMgYWRkZWQgYnkgaW50 cm9kdWNpbmcgQmluZGluZy1TSUQgY29udGV4dCBpZGVudGlmaWVyIGFzIGEgZmlyc3QgZXh0ZW5z aW9uIG9mIEluZGlyZWN0aW9uLWlkIGV4dGVuZGVkIGNvbW11bml0eS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+SXQgaXMg YW4gaW5jb3JyZWN0IGFzc3VtcHRpb24gb2Ygbm8gY29udGV4dCBhd2FyZW5lc3MgaW4gZHJhZnQt dmFuZGV2ZWxkZS4gZHJhZnQtdmFuZGV2ZWxkZS1pZHItZmxvd3NwZWMtcGF0aC1yZWRpcmVjdCBh ZGRlZCBjb250ZXh0IHN1cHBvcnQgYmVmb3JlIGRyYWZ0LWxpIGV4aXN0ZWQsIGFuZCByYWlzZXMg cXVlc3Rpb25zDQogYWJvdXQgbmV3IGVsZW1lbnRzIGV4cG9zZWQgd2l0aCBkcmFmdC1saSBjb21w YXJlZCB0byBkcmFmdC12YW5kZXZlbGRlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImNvbG9yOiMwMEIwRjA7bGF5b3V0LWdyaWQtbW9kZTpsaW5lIj5bUmVwbHkgMDVdPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJjb2xvcjojMDBCMEYwO2xheW91dC1ncmlkLW1vZGU6bGluZSI+UGxlYXNlIHJlZmVy IHRvIFJlcGx5IDAxLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Y29sb3I6IzAwQjBGMCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Y29sb3I6YmxhY2s7YmFja2dyb3VuZDojRkZGREY1Ij4oZndpdyBUaGUgc2VtYW50aWMgYXdh cmVuZXNzIG9mIGRyYWZ0LXZhbmRldmVsZGUgaXMgbWVudGlvbmVkIGFuZCB0aGUgd2ViZXggcmVj b3JkaW5nIG9mIGRyYWZ0LWxpIGJldHdlZW4gcmVjb3JkaW5nIHRpbWUtc3RhbXBzIDExbTMwcyB0 byAxM20zMHMpPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5T bGlkZSAzIChvZiB0aGUgZHJhZnQtbGkgcHJlc2VudGF0aW9uKTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPj09PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xv cjpibGFjayI+Tm8gbmV3IGNhcGFiaWxpdHkgaXMgZXhwbGFpbmVkIG9uIHRoaXMgc2xpZGUgaW4g Y29tcGFyaXNvbiB3aXRoIHRoZSBkcmFmdC12YW5kZXZlbGRlLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+SW4gZHJhZnQtdmFuZGV2ZWxk ZSB0aGUgaW5mb3JtYXRpb24gZm91bmQgaW4gdGhlIGluZGlyZWN0aW9uLWlkIGlzIHVzZWQgb24g YSBmbG93c3BlYyBjbGllbnQgaW4gYSBsb2NhbCBtYXBwaW5nLXRhYmxlIChpbmRpcmVjdGlvbi1p ZCB0YWJsZSkgdG8gZmluZCBsb2NhbCBmb3J3YXJkaW5nIGluZm9ybWF0aW9uLiBUaGUNCiBuZXcg Zmxvd3NwZWMgZXh0ZW5kZWQgY29tbXVuaXR5IGFzIGRvY3VtZW50ZWQgYnkgZHJhZnQtdmFuZGV2 ZWxkZSBjYW4gcHJvdmlkZSBhbHJlYWR5IGEgZmxvd3NwZWMgY2xpZW50IHRoZSByZXF1aXJlZCBz ZW1hbnRpYy9jb250ZXh0IGluZm9ybWF0aW9uIChleGFtcGxlIGlzIHRoZSDigJhC4oCZIGJpdCku PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMDBCMEYwO2xheW91dC1ncmlkLW1v ZGU6bGluZSI+W1JlcGx5IDA2XTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzAwQjBGMDtsYXlvdXQtZ3Jp ZC1tb2RlOmxpbmUiPkFsc28sIHBsZWFzZSByZWZlciB0byBSZXBseSAwMS48L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMwMEIwRjAiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJs YWNrIj5TbGlkZSA0IChvZiB0aGUgZHJhZnQtbGkgcHJlc2VudGF0aW9uKTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPj09PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtjb2xvcjpibGFjayI+VGhlIGdvYWwgb2YgZHJhZnQtbGkgaXMgdG8gZGVmaW5lIGEg4oCcc2Vt YW50aWNzIGRlcGVuZGVudOKAnSBhY3Rpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5Ib3dldmVyLCBkcmFmdC12YW5kZXZlbGRlIGFs cmVhZHkgYWxsb3dzIHRoYXQgZnVuY3Rpb25hbGl0eSBiZWZvcmUgZHJhZnQtbGkgZXhpc3RlZDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzAwQjBGMDtsYXlvdXQtZ3JpZC1tb2Rl OmxpbmUiPltSZXBseSAwN108bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMwMEIwRjA7bGF5b3V0LWdyaWQt bW9kZTpsaW5lIj5BbHNvLCBwbGVhc2UgcmVmZXIgdG8gUmVwbHkgMDEuPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMDBCMEYwIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFj ayI+U2xpZGUgNSAob2YgdGhlIGRyYWZ0LWxpIHByZXNlbnRhdGlvbik8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj49PTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Y29sb3I6YmxhY2siPkRyYWZ0LXZhbmRldmVsZGUgaGFzIGluZGVlZCB0aGUgcG90ZW50aWFsIHRv IGJlIHVzZWQgaW4gc3VjaCBhIG1hbm5lci4gVGhlIGludGVuZCBvZiB0aGlzIHNsaWRlIGF0IHRo ZSB0aW1lIG9mIHVzYWdlIHdhcyB0byBzaG93IGFuIGV4dHJlbWUgZXhhbXBsZSBvZiB0aGUgZmxl eGlibGl0eSB0aGUgdGVjaG5vbG9neQ0KIG9mZmVycy4gV2hlbiBmb3IgZXhhbXBsZSB1c2luZyBy ZWRpcmVjdGlvbiB0byBiaW5kaW5nLVNJRCAoYXMgZG9jdW1lbnRlZCBpbiBsYXRlc3QgZHJhZnQt dmFuZGV2ZWxkZSkgdGhlbiB0aGUgbG9jYWwgbWFwcGluZyB0YWJsZSBjYW4gYmUgYmFzZWQgYXJv dW5kIHRoZSBzaWduYWxsZWQgc2VtYW50aWNzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGluZS1oZWlnaHQtYWx0 OjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMDBCMEYwIj5bUmVwbHkgMDhd DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LWxpbmUtaGVpZ2h0LWFsdDowcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzAw QjBGMCI+U28gRHJhZnQtdmFuZGV2ZWxkZSBwbGFubmVkIHRvIHN1cHBvcnQgdHdvIGNhdGVnb3Jp ZXMgb2YgdGhlIGxvY2FsIG1hcHBpbmcgdGFibGVzPw0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saW5lLWhlaWdodC1hbHQ6MHB0Ij48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMwMEIwRjAiPjEpIHRoZSBsb2NhbCBtYXBwaW5n IHRhYmxlIHBlciBkZXZpY2U7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLWxpbmUtaGVpZ2h0LWFsdDowcHQiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iY29sb3I6IzAwQjBGMCI+MikgdGhlIGxvY2FsIG1hcHBpbmcgdGFibGUgcGVyIHNl cnZpY2U7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1saW5lLWhlaWdodC1hbHQ6MHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OiMwMEIwRjAiPldlIHRoaW5rIHRoYXQg4oCcc2V0dXAgdGhlIG1hcHBpbmcgdGFibGVzIHBlciBz ZXJ2aWNlIHR5cGXigJ0gaXMgZWFzaWVyIHRvIGltcGxlbWVudC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5TbGlkZSA2IChvZiB0aGUg ZHJhZnQtbGkgcHJlc2VudGF0aW9uKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPj09PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2si PkRyYWZ0LXZhbmRldmVsZGUgaGFzIDEzIGJpdHMgYXZhaWxhYmxlIGZvciB0eXBlcywgaGVuY2Ug dGhlIHBvdGVudGlhbCB0byBzdXBwb3J0L3NpZ25hbCAyXjEzICg9ODE5MikgdHlwZXMgd2hlbiB1 c2luZyB0aGUgZmllbGQgYXMgc2NhbGFyIHZhbHVlICh3aGVuIGNvbXBhcmluZyB3aXRoIGEgcG90 ZW50aWFsIGZvcg0KIDI1NSB0eXBlcyB1c2luZyBkcmFmdC1saSk8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpi bGFjayI+VGhlIGNsYWltIG1hZGUgb24gc2xpZGU2IHRoYXQgZHJhZnQtdmFuZGV2ZWxkZSBhbGxv d3Mgb25seSAxMyB0eXBlIG9mIHNlbWFudGljIGluZm9ybWF0aW9uIGlzIHdyb25nIGFzc3VtcHRp b24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1saW5lLWhlaWdodC1hbHQ6MHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImNvbG9yOiMwMEIwRjAiPltSZXBseSAwOV0NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGluZS1oZWlnaHQtYWx0OjBwdCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMDBCMEYwIj5TdXJlLCBpZiBkcmFmdC12YW5k ZXZlbGRlIHVzZXMgbW9yZSBiaXRzIHRvIHByZXNlbnQgdGhlIHR5cGUgb2Ygc2VtYW50aWMgaW5m b3JtYXRpb24gYW5kIHVzZSB0aGVtIGFzIHR5cGUgdmFsdWUgbGlrZSBkcmFmdC1saSBkb2VzLCBu b3Qg4oCcUGVyIFNlcnZpY2UgUGVyIEJpdOKAnSBhcyBCaW5kaW5nDQogQml0IGRlZmluZXMgaW4g ZHJhZnQtdmFuZGV2ZWxkZSAmbmJzcDt2ZXJzaW9uIC0wMi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Y29sb3I6IzAwQjBGMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5BdCB0aGUgdGlt ZSBvZiB3cml0aW5nLCBpdCB3YXMgZm91bmQgdXNlZnVsIHRvIHNpZ25hbCBiaW5kaW5nIFNJRCB1 c2VmdWwgc2VtYW50aWMg4oCmIFdlIGRlY2lkZWQgdG8gbGVhdmUgdGhlIHJlbWFpbmluZyBiaXRz IHJlc2VydmVkL29wZW4gZm9yIGRpc2N1c3Npb24gb24gaG93IHRvIGJlc3QgdXNlIHRoZSBmaWVs ZA0KIGluc3RlYWQuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPk1heWJlIHRoZSBXRyBmZWVscyBpdCBpcyBiZXN0 IHRvIHVzZSBvbmx5IGEgZmV3IGJpdHMgZm9yIHNlbWFudGljcyBhbmQga2VlcCB0aGUgcmVtYWlu ZGVyIHJlc2VydmVkIGZvciBmdXR1cmUgdXNlLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5LaW5kIFJlZ2FyZHMs PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNr Ij5HLzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBj bSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iY29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJjb2xvcjpibGFjayI+SWRyICZsdDs8YSBocmVmPSJtYWlsdG86aWRyLWJvdW5jZXNAaWV0 Zi5vcmciPmlkci1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mIFN1c2FuIEhh cmVzICZsdDs8YSBocmVmPSJtYWlsdG86c2hhcmVzQG5kemguY29tIj5zaGFyZXNAbmR6aC5jb208 L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5GcmlkYXkgMTMgTWF5IDIwMTYgYXQgMTI6NDY8YnI+ DQo8Yj5UbzogPC9iPiZxdW90OzxhIGhyZWY9Im1haWx0bzppZHJAaWV0Zi5vcmciPmlkckBpZXRm Lm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzppZHJAaWV0Zi5vcmciPmlkckBpZXRm Lm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPltJZHJdIElEUiBpbnRlcmltIG9uIE1h eSAxNnRoIC0gd2ViZXgsIHF1ZXN0aW9ucyBmb3IgbWVldGluZywgYW5kIHJlY29yZGluZ3MuPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFj ayI+VGhlIHRpbWUgb2YgdGhlIGludGVyaW0gaXMgMjI6MDAtMjM6MDAgRURUIG9uIE1heSAxNjxz dXA+dGg8L3N1cD4uICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iY29sb3I6YmxhY2siPlRoZSBpbnRlcmltIHdpbGwgZGlzY3VzcyB0aGUgZm9sbG93 aW5nIHR3byBkcmFmdHMgaW4gb3JkZXIgdG8gY3JlYXRlIGEgV0cgc29sdXRpb246DQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM4LjM1cHQ7dGV4dC1pbmRl bnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3Rz XT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjpibGFj ayI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBw dCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPmRyYWZ0LXZhbmRldmVsZGUtaWRy LWZsb3dzcGVjLXBhdGgtcmVkaXJlY3QsIGFuZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzguMzVwdDt0ZXh0LWlu ZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NCjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOmJs YWNrIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250Ojcu MHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+ZHJhZnQtbGktaWRyLWZsb3dz cGVjLXJlZGlyZWN0LWdlbmVyYWxpemVkLXNpZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPlNvbWUgb2YgdGhlIFF1ZXN0aW9ucyB0aGF0 IHdpbGwgYmUgZGlzY3VzcyBhcmUgaW5jbHVkZWQgYmVsb3cuJm5ic3A7IFBsZWFzZSByZXZpZXcg dGhlIHByZS1yZWNvcmRpbmcgcHJlc2VudGF0aW9ucyBwcmlvciB0byB0aGUgbWVldGluZy4mbmJz cDsmbmJzcDsgVGhlIENoYWlycyBlbmNvdXJhZ2UgZGlzY3Vzc2lvbiBvZiB0aGVzZSBxdWVzdGlv bnMgb24gdGhlIGxpc3QNCiBiZWZvcmUsIGR1cmluZywgYW5kIGFmdGVyIHRoZSBtZWV0aW5nLiA8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNr Ij5TdWUgYW5kIEpvaG4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJjb2xvcjpibGFjayI+PT09PT09PT09PT09PT09PT09PT09PT09PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+QWdlbmRhIGZv ciBJRFIgVmlydHVhbCBJbnRlcmltIE1lZXRpbmcNCjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+TWF5IDE2LCAyMDE2PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv cjpibGFjayI+MjI6MDAgLSAyMzowMCBFRFQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5XZWJFeDogPGEgaHJlZj0iaHR0cHM6Ly9pZXRm LndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTliZTQ4MWQxOTk4OGRkMWI1NDViZTY3NTlhZWUy NjdiIj4NCmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW05YmU0ODFkMTk5 ODhkZDFiNTQ1YmU2NzU5YWVlMjY3YjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5NZWV0 aW5nIG51bWJlcjombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgNjQ5IDIzNSA0MTE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNr Ij5NZWV0aW5nIHBhc3N3b3JkOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBKZzY2ZDJwbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPkpvaW4gYnkgcGhv bmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4xLTg3Ny02NjgtNDQ5MyBDYWxsLWluIHRvbGwg ZnJlZSBudW1iZXIgKFVTL0NhbmFkYSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4xLTY1MC00 NzktMzIwOCBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv cjpibGFjayI+QWNjZXNzIGNvZGU6IDY0OSAyMzUgNDExPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+UXVlc3Rpb25zIGZvciBtZWV0 aW5nOg0KPC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNr Ij5TdWJtaXR0ZWQgYnkgKEVyaWMgV3UpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+MS4gUmVk aXJlY3QtdG8tU3BlY2lmaWMtVHVubmVsIHdpdGggQkdQIFBhdGggQXR0cmlidXRlIFtUVU5ORUxF TkNBUFNdW01QUF0gYW5kDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDtS ZWRpcmVjdC10by1JSUQvR1NJRCwgUmVxdWlyZWQgYnkgZGlmZmVyZW50IHVzZSBjYXNlcywgY2Fu IHdlIGhhdmUgdHdvIGRvY3MgaW4gSURSIEluIHBhcmFsbGVsPw0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7W0NvbXBhcmlzb24gdG8gUmVkaXJlY3QtdG8tSUlEL0dTSUQg LCBkcmFmdC1oYW8gd2lsbCBoYXZlIG1vcmUgbGl0dGxlIG1vZGlmaWNhdGlvbg0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7dG8gZXhpc3RpbmcgbWVjaGFuaXNtcywgTm8g bmVlZCB0byBkbyBNYXBwaW5nIC9SZWN1cnNpdmUgTG9va3VwLl08bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4yLiZuYnNwOyBGb3IgSUlE L0dTSUQsIG9uZSBtYXBwaW5nIHRhYmxlIGZvcg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7YWxsIGtpbmRzIG9mIHNlZ21lbnRzL2ZvcndhcmRpbmctZW50aXRpZXMgdnMu IG9uZSBtYXBwaW5nIHRhYmxlDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDtwZXIgc2VnbWVudHMvZm9yd2FyZGluZy1lbnRpdGllcyB0eXBlLCBzaG91bGQgd2Ugc3VwcG9y dCBib3RoPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Y29sb3I6YmxhY2siPkNoYWlyIFF1ZXN0aW9uczogPC9zcGFuPg0KPC9iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjEpIERvZXMgdGhlIFdHIGZlZWwgd2UgbmVlZCB0 aGUgZm9sbG93aW5nIGZvciBSRkM1NTc1YmlzIChERG9TKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZuYnNwOyBhKSBSZWRpcmVjdGlvbiB0byBWUkYsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDtiKSBSZWRpcmVjdGlvbiB0byBJbmRpcmVjdGlvbiB0byBJUCwgYW5k ICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwO2MpIFJlZGlyZWN0 aW9uIHRvIFNlcnZpY2UgKG5ldyk/DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4yKSBJZiB0aGUgV0cgZGVzaXJlcyByZWRp cmVjdGlvbiB0byBTZXJ2aWNlIHJvdXRpbmcsIGRvZXMgdGhlIFdHIGRlc2lyZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6YmxhY2siPmEpIE5leHQtSG9wIHR1bm5lbCBzdXBwb3J0PyAtPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJjb2xvcjpibGFjayI+YikgTmV4dC1Ib3AgVEUgVHVubmVsIHN1cHBvcnQ/DQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDtjKSBOZXN0ZWQgVHVubmVsIHN1cHBvcnQ/DQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDtkKSBOZXh0LU5leHQgSG9wIFR1bm5lbCBTdXBwb3J0 Pw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7ZSkgUm91dGVyIGxvY2FsaXplZCBU dW5uZWwgcmVjdXJzaW9uPw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7ZikgVHVu bmVsIEVuY2FwIFJlY3Vyc2lvbjoNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjMpIFdoYXQgcGllY2VzIG9mIHRoZSBwcm9wb3NlZCBz b2x1dGlvbnMgaGF2ZSBiZWVuIGltcGxlbWVudGVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7IGFuZC9vciBkZXBsb3llZD8mbmJzcDsmbmJzcDsNCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPlByZXNlbnRhdGlvbnMgKHByZXJlY29yZGVkLCBwbGVh c2UgcmV2aWV3IHByaW9yIHRvIG1lZXRpbmcpOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+LSBkcmFmdC12 YW5kZXZlbGRlLWlkci1mbG93c3BlYy1wYXRoLXJlZGlyZWN0PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7IEd1bnRlciBWYW4gRGUgVmVsZGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDsgMjEgbWludXRlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyA8YSBo cmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvbGRyLnBocD9SQ0lEPWUwMWQ2MjY2MTA4 NWY2NjBmNDcwZmVkZGQ5YmYyNjZmIj4NCmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9sZHIu cGhwP1JDSUQ9ZTAxZDYyNjYxMDg1ZjY2MGY0NzBmZWRkZDliZjI2NmY8L2E+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+cHJlc2VudGF0 aW9uIGF0OiA8bzpwPg0KPC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL3Byb2NlZWRpbmdzL2ludGVyaW0vMjAxNi8wNS8xNi9pZHIvc2xpZGVzL3NsaWRl cy1pbnRlcmltLTIwMTYtaWRyLTUtMC5wZGYiPmh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRp bmdzL2ludGVyaW0vMjAxNi8wNS8xNi9pZHIvc2xpZGVzL3NsaWRlcy1pbnRlcmltLTIwMTYtaWRy LTUtMC5wZGY8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+ZHJhZnQtbGkt aWRyLWZsb3dzcGVjLXJlZGlyZWN0LWdlbmVyYWxpemVkLXNpZDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6 YmxhY2siPkVyaWMgV3UgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+MjAgbWludXRlcyA8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5T dHJlYW1pbmcgcmVjb3JkaW5nIGxpbms6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PGEgaHJl Zj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2xkci5waHA/UkNJRD1jODYxNWFhODQ1ODAx YTFlNGI3OWNiMTcwOGEwNDQ4NCI+aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2xkci5waHA/ UkNJRD1jODYxNWFhODQ1ODAxYTFlNGI3OWNiMTcwOGEwNDQ4NDwvYT48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv bG9yOmJsYWNrIj5Eb3dubG9hZCByZWNvcmRpbmcgbGluazo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs YWNrIj48YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvbHNyLnBocD9SQ0lEPTRi ZDUwNDMyOTcyN2QyYTgxMWM5Y2IwYzliYzcxM2Q4Ij5odHRwczovL2lldGYud2ViZXguY29tL2ll dGYvbHNyLnBocD9SQ0lEPTRiZDUwNDMyOTcyN2QyYTgxMWM5Y2IwYzliYzcxM2Q4PC9hPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPnBy ZXNlbnRhdGlvbiBhdDogPG86cD4NCjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy9pbnRlcmltLzIwMTYvMDUvMTYvaWRyL3NsaWRl cy9zbGlkZXMtaW50ZXJpbS0yMDE2LWlkci01LTEucGRmIj5odHRwczovL3d3dy5pZXRmLm9yZy9w cm9jZWVkaW5ncy9pbnRlcmltLzIwMTYvMDUvMTYvaWRyL3NsaWRlcy9zbGlkZXMtaW50ZXJpbS0y MDE2LWlkci01LTEucGRmPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_19AB2A007F56DB4E8257F949A2FB9858AA1BD619NKGEML515MBXchi_-- From nobody Mon May 16 03:14:30 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A029612D0B0 for ; Mon, 16 May 2016 03:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2sKSWeJGnC0 for ; Mon, 16 May 2016 03:14:23 -0700 (PDT) Received: from st13p11im-asmtp004.me.com (st13p11im-asmtp004.me.com [17.164.40.219]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E664127058 for ; Mon, 16 May 2016 03:14:23 -0700 (PDT) Received: from process-dkim-sign-daemon.st13p11im-asmtp004.me.com by st13p11im-asmtp004.me.com (Oracle Communications Messaging Server 7.0.5.36.0 64bit (built Sep 8 2015)) id <0O7900H00LPUER00@st13p11im-asmtp004.me.com> for idr@ietf.org; Mon, 16 May 2016 10:14:22 +0000 (GMT) Received: from [192.168.2.3] (unknown [31.31.132.240]) by st13p11im-asmtp004.me.com (Oracle Communications Messaging Server 7.0.5.36.0 64bit (built Sep 8 2015)) with ESMTPSA id <0O7900DQ7LRPXL30@st13p11im-asmtp004.me.com>; Mon, 16 May 2016 10:14:22 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-05-16_03:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1015 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1510270003 definitions=main-1605160145 Content-type: multipart/alternative; boundary="Apple-Mail=_6E8B4BF6-78D2-482F-A43D-1F145D588945" MIME-version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Gunter Van De Velde In-reply-to: <19AB2A007F56DB4E8257F949A2FB9858AA1BD619@NKGEML515-MBX.china.huawei.com> Date: Mon, 16 May 2016 12:14:13 +0200 Message-id: <927FBD8E-FCB3-4FF7-9330-A661022124DA@icloud.com> References: <008a01d1ad04$c63a77d0$52af6770$@ndzh.com> <9F087909-60F3-4F5C-8427-C0BD2A4ED9FF@alcatel-lucent.com> <19AB2A007F56DB4E8257F949A2FB9858AA1BD619@NKGEML515-MBX.china.huawei.com> To: Zhuangshunwan X-Mailer: Apple Mail (2.3124) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=4d515a; t=1463393662; bh=pXMy4ALVTHl7PW298nMEpYpLCQc3Z82bjxMhNPZA200=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=oGgiAppURJ1AMMvP62ij+uxEUdaHRUtu23hzsyREsVReC3R9su6igX01ZNFz/OuPg d9j4TKlWmbFjkPTq0w6MPgju/7nKT+YN/lLuaJAKolZg1KLTsCkk3nDfmf2jhnVDcA uclsh1TS+xRTuDbY64zz32CVoH9iHT19QucKRdMfT+WOU+7jMdIMp5kLzASpaZvaoS dRIYKbFq2hE/fb46y8jYcMHz3jmM18LcDsGWt5WqWvT/ogDExw4/aozIAsX6cleDYL lOdYlbTNMD2RqXRT4aTksZiAlQR1sYRxvjBj1QUKURLRiu4X323qX4RIIrlny0unRI 1TacN5j0vIMug== Archived-At: Cc: "idr@ietf.org" , "Van De Velde, Gunter \(Nokia - BE\)" Subject: Re: [Idr] IDR interim on May 16th - webex, questions for meeting, and recordings. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 10:14:29 -0000 --Apple-Mail=_6E8B4BF6-78D2-482F-A43D-1F145D588945 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Shunwan, Eric, All, Inline: GV> > Timeline info > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =20 > draft-vandevelde-idr-flowspec-path-redirect-00 created on 14 September = 2015 > draft-vandevelde-idr-flowspec-path-redirect-01 created on 12 January = 2016 > draft-vandevelde-idr-flowspec-path-redirect-02 created on 17 March = 2016 > =20 > draft-li-idr-flowspec-redirect-generalized-sid-00 created on 21 March = 2016 > =20 > =20 > [Reply 01]=20 > The idea of draft-li-idr-flowspec-redirect-generalized-sid had = initially been presented in the IDR Interim Meeting of 2015-10-26: > = https://www.ietf.org/proceedings/interim/2015/10/26/idr/slides/slides-inte= rim-2015-idr-12-8.pdf = > and discussed in IDR mailing list: > https://www.ietf.org/mail-archive/web/rtgwg/current/msg05195.html = > =20 > =20 GV> The suggested references document justification discussions around = draft-li-idr-mpls-path-programming-02.=20 The reference indicates that draft-vandevelde can use the indirection = extended community to redirect to a tunnel programmed by = draft-li-idr-mpls-path-programming. =20 > At Oct 26, 2015, draft-vandevelde-idr-flowspec-path-redirect-00 = described the =E2=80=9Csemantics independent=E2=80=9D solution, but we = think it should simultaneously add =E2=80=9Csemantics dependent=E2=80=9D = solution. That happened before = draft-vandevelde-idr-flowspec-path-redirect-01 which created on 12 = January 2016. At that time, we don=E2=80=99t think that a separate = document is immediately needed. > =20 > After draft-vandevelde-idr-flowspec-path-redirect-01 created, we = notice that it did not integrate =E2=80=9Csemantics dependent=E2=80=9D = solution, but as per our Research and development team=E2=80=99s = opinion, we need the =E2=80=9Csemantics dependent=E2=80=9D Redirect = Action solution. > =20 > Then =E2=80=9Csemantics dependent=E2=80=9D Redirect to Generalized = Segment ID Action documented as = draft-li-idr-flowspec-redirect-generalized-sid. Coincidentally, at the = same time, draft-vandevelde introduces =E2=80=9CB=E2=80=9D bit to map = the value encoded in the global administrator field to a Binding Segment = Identifier value. GV> The concept of draft-vandevelde to signal a flowspec client using a = redirection identifier is copied in draft-li without even referencing = any version at all of draft-vandevelde-idr-flowspec-path-redirect. = Coincidence? > * Concept of Indirection tables has been added (hence adding the = capability of context/semantics signalling already since version -01) > [Reply 04] > Sorry, about =E2=80=9Ccontext/semantics signalling already since = version -01=E2=80=9D, maybe we missed the related description or did not = understand it correctly, can you show us the text in version -01? > =20 GV> Draft-vandevelde has a discussion around mapping tables, and has the = extended community =E2=80=98 eserved' bits that can be used to signal = semantics or tunnel mapping table, and hence the capability is = available. This capability is used when we actual added redirection to = SR binding SID. > =20 > Draft-vandevelde has indeed the potential to be used in such a manner. = The intend of this slide at the time of usage was to show an extreme = example of the flexiblity the technology offers. When for example using = redirection to binding-SID (as documented in latest draft-vandevelde) = then the local mapping table can be based around the signalled = semantics. > [Reply 08] > So Draft-vandevelde planned to support two categories of the local = mapping tables? > 1) the local mapping table per device; > 2) the local mapping table per service; > We think that =E2=80=9Csetup the mapping tables per service type=E2=80=9D= is easier to implement. GV> This is an interesting discussion.=20 draft-vandevelde has the capability to optionally couple semantics to a = mapping table. This capability is a powerful tool. Because of this capability = currently both (1) and (2) are possible with draft-vandevelde.=20 in addition alternate creative categories could be i.e. : (3) a mapping = table per flowspec controller or (4) a table per tunnel configuration = method/controller. draft-vandevelde can enforce semantic coupling or can permit freedom to = an operational user=E2=80=A6 There are pro's and con=E2=80=99s for each, = and i welcome the WG to=20 provide guidance on the operational implications to complement = draft-vandevelde=E2=80=A6=20 G/ > On 16 May 2016, at 09:20, Zhuangshunwan > wrote: >=20 > Hi Gunter, > =20 > Thanks for your comments, Please see responses inline. > =20 > Best Regards, > Shunwan & Eric.Wu > =20 > =E5=8F=91=E4=BB=B6=E4=BA=BA: Idr [mailto:idr-bounces@ietf.org = ] =E4=BB=A3=E8=A1=A8 Van De Velde, Gunter = (Nokia - BE) > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2016=E5=B9=B45=E6=9C=8813=E6=97=A5= 22:56 > =E6=94=B6=E4=BB=B6=E4=BA=BA: idr@ietf.org > =E4=B8=BB=E9=A2=98: Re: [Idr] IDR interim on May 16th - webex, = questions for meeting, and recordings. > =20 > Pre-liminar comments=E2=80=A6.. > =20 > Before engaging with my feedback and addressing the discussion slides, = i would like to thank both Sue and John for going through the effort and = time to try to make the recordings as good as possible and investing = non-trivial amounts of time to get the job done. > =20 > I would also like to thanks Eric Wu to go through the exercise of = recording his presentation of the slides. I went through the same = exercise and even though there were less operational issues to deal with = during my recording, it is a non-trivial task to speak to a screen and = not to an audience.=20 > =20 > =20 > Comments: Working slides discussion of the 16 May 2016 Interim IDR = meeting: > ------------- > =20 > =20 > Timeline info > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =20 > draft-vandevelde-idr-flowspec-path-redirect-00 created on 14 September = 2015 > draft-vandevelde-idr-flowspec-path-redirect-01 created on 12 January = 2016 > draft-vandevelde-idr-flowspec-path-redirect-02 created on 17 March = 2016 > =20 > draft-li-idr-flowspec-redirect-generalized-sid-00 created on 21 March = 2016 > =20 > =20 > [Reply 01]=20 > The idea of draft-li-idr-flowspec-redirect-generalized-sid had = initially been presented in the IDR Interim Meeting of 2015-10-26: > = https://www.ietf.org/proceedings/interim/2015/10/26/idr/slides/slides-inte= rim-2015-idr-12-8.pdf = > and discussed in IDR mailing list: > https://www.ietf.org/mail-archive/web/rtgwg/current/msg05195.html = > =20 > At Oct 26, 2015, draft-vandevelde-idr-flowspec-path-redirect-00 = described the =E2=80=9Csemantics independent=E2=80=9D solution, but we = think it should simultaneously add =E2=80=9Csemantics dependent=E2=80=9D = solution. That happened before = draft-vandevelde-idr-flowspec-path-redirect-01 which created on 12 = January 2016. At that time, we don=E2=80=99t think that a separate = document is immediately needed. > =20 > After draft-vandevelde-idr-flowspec-path-redirect-01 created, we = notice that it did not integrate =E2=80=9Csemantics dependent=E2=80=9D = solution, but as per our Research and development team=E2=80=99s = opinion, we need the =E2=80=9Csemantics dependent=E2=80=9D Redirect = Action solution. > =20 > Then =E2=80=9Csemantics dependent=E2=80=9D Redirect to Generalized = Segment ID Action documented as = draft-li-idr-flowspec-redirect-generalized-sid. Coincidentally, at the = same time, draft-vandevelde introduces =E2=80=9CB=E2=80=9D bit to map = the value encoded in the global administrator field to a Binding Segment = Identifier value. > =20 > General slide observations about draft-li-generalised-sid-00 (ref. = discussion slide for 16 May 2016) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > =20 > Draft-li documents a flowspec action using a new community = (generalized-SID). The extended community provides a flowspec client = information to make a local forwarding decision by means of a local = mapping table. The two main components used by the flowspec client is: = (1) an identifier and (2) semantics. > =20 > Draft-vandevelde documents a flowspec action using a new community = (Indirection-ID). The extended community provides a flowspec client = information to make a local forwarding decision by means of a local = mapping table. The two main components used by the flowspec client is: = (1) an identifier and (2) optionally semantics (Table semantics + = Tunnel-ID). > =20 > draft-vandevelde-idr-flowspec-path-redirect-02 was created =E2=80=9Cbefo= re" draft-li-idr-flowspec-redirect-generalized-sid-00 and achieves the = same functionality and more. (For example draft-vandevelde has the = potential to signal 8192 types of semantic mapping tables while draft-li = has 255, another example is the TID field which allows dynamic = Next-Next-Hop constructs use for EPE DDoS redirection). > [Reply 02] > The idea of draft-li-idr-flowspec-redirect-generalized-sid had = initially been presented in the IDR Interim Meeting of 2015-10-26:=20 > = https://www.ietf.org/proceedings/interim/2015/10/26/idr/slides/slides-inte= rim-2015-idr-12-8.pdf = > and discussed in IDR mailing list: > https://www.ietf.org/mail-archive/web/rtgwg/current/msg05195.html = > =20 > During WG addoption-call 3/25 to 4/8 the following has been mentioned = by Ignas: http://www.ietf.org/mail-archive/web/idr/current/msg15512.html = > =20 > "Draft-vandevelde can achieve all what draft-hao and draft-li can, and = in a more flexible way. Having the ability to decouple redirection = tunnel type from redirection action is both practical and extensible - = the actual tunnel to be used is a local operational decision for each = network element, it is not necessary signalled at the same time and by = the same mechanism. Decoupling signalling and redirect parts aligns well = to operational practices of using specific tools for specific tasks. = Just that BGP could do that does not necesasry mean that it should be = used as a best fit. =46rom operational perspective there is no need to = have multiple solutions that try to address the narrow problem space in = similar yet incompatible ways. There should be one document for = redirect, and draft-vandevelde is a good starting base for that." > [Reply 03]=20 > As we understand=EF=BC=8CDraft-vandevelde can=E2=80=99t achieve what = draft-hao can=EF=BC=8Cdraft-hao specifies the specific tunnel from = Flowspec Controller and the redirect tunnel information is encoded in = BGP Path Attribute [TUNNELENCAPS][MPP] that is carried in the BGP = flow-spec UPDATE. > Comparison to draft-vandevelde, draft-hao will have more little = modification to existing mechanisms, No need to do Mapping /Recursive = Lookup. > =20 > If draft-vandevelde uses more bits to present the type of semantic = information and use them as type value like draft-li does, not =E2=80=9CPe= r Service Per Bit=E2=80=9D as Binding Bit defines in version -02, and = support to setup the mapping tables per service type, we think that the = requirements of draft-li can be addressed. > =20 > =20 > Detail view: slide observations draft-li-generalised-sid-00 discussion > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > =20 > Slide 2 (of the draft-li presentation): History=20 > =3D=3D > =20 > The slide forgets to mention that draft-vandevelde was enhanced and = progressed based upon constructive WG feedback. Much feedback has been = integrated between draft-vandevelde -00 to =E2=80=9302 BEFORE draft=E2=80=93= li even existed. For example: > * Use-case scenario=E2=80=99s were added > * "Path-id" changed to "Indirection-id" > * Concept of Indirection tables has been added (hence adding the = capability of context/semantics signalling already since version -01) > [Reply 04] > Sorry, about =E2=80=9Ccontext/semantics signalling already since = version -01=E2=80=9D, maybe we missed the related description or did not = understand it correctly, can you show us the text in version -01? > =20 > * Flowspec validation information is added > * signalling of context/semantics is added by introducing Binding-SID = context identifier as a first extension of Indirection-id extended = community. > =20 > It is an incorrect assumption of no context awareness in = draft-vandevelde. draft-vandevelde-idr-flowspec-path-redirect added = context support before draft-li existed, and raises questions about new = elements exposed with draft-li compared to draft-vandevelde. > [Reply 05] > Please refer to Reply 01. > =20 > (fwiw The semantic awareness of draft-vandevelde is mentioned and the = webex recording of draft-li between recording time-stamps 11m30s to = 13m30s) > =20 > =20 > Slide 3 (of the draft-li presentation) > =3D=3D > =20 > No new capability is explained on this slide in comparison with the = draft-vandevelde. > In draft-vandevelde the information found in the indirection-id is = used on a flowspec client in a local mapping-table (indirection-id = table) to find local forwarding information. The new flowspec extended = community as documented by draft-vandevelde can provide already a = flowspec client the required semantic/context information (example is = the =E2=80=98B=E2=80=99 bit). > [Reply 06] > Also, please refer to Reply 01. > =20 > Slide 4 (of the draft-li presentation) > =3D=3D > =20 > The goal of draft-li is to define a =E2=80=9Csemantics dependent=E2=80=9D= action. > However, draft-vandevelde already allows that functionality before = draft-li existed > [Reply 07] > Also, please refer to Reply 01. > =20 > Slide 5 (of the draft-li presentation) > =3D=3D > =20 > Draft-vandevelde has indeed the potential to be used in such a manner. = The intend of this slide at the time of usage was to show an extreme = example of the flexiblity the technology offers. When for example using = redirection to binding-SID (as documented in latest draft-vandevelde) = then the local mapping table can be based around the signalled = semantics. > [Reply 08] > So Draft-vandevelde planned to support two categories of the local = mapping tables? > 1) the local mapping table per device; > 2) the local mapping table per service; > We think that =E2=80=9Csetup the mapping tables per service type=E2=80=9D= is easier to implement. > =20 > =20 > Slide 6 (of the draft-li presentation) > =3D=3D > =20 > Draft-vandevelde has 13 bits available for types, hence the potential = to support/signal 2^13 (=3D8192) types when using the field as scalar = value (when comparing with a potential for 255 types using draft-li) > =20 > The claim made on slide6 that draft-vandevelde allows only 13 type of = semantic information is wrong assumption. > [Reply 09] > Sure, if draft-vandevelde uses more bits to present the type of = semantic information and use them as type value like draft-li does, not = =E2=80=9CPer Service Per Bit=E2=80=9D as Binding Bit defines in = draft-vandevelde version -02. > =20 > At the time of writing, it was found useful to signal binding SID = useful semantic =E2=80=A6 We decided to leave the remaining bits = reserved/open for discussion on how to best use the field instead.=20 > Maybe the WG feels it is best to use only a few bits for semantics and = keep the remainder reserved for future use.=20 > =20 > Kind Regards, > G/ > =20 > =20 > =20 > From: Idr > on = behalf of Susan Hares > > Date: Friday 13 May 2016 at 12:46 > To: "idr@ietf.org " > > Subject: [Idr] IDR interim on May 16th - webex, questions for meeting, = and recordings. > =20 > The time of the interim is 22:00-23:00 EDT on May 16th. =20 > =20 > The interim will discuss the following two drafts in order to create a = WG solution: > =20 > =C2=B7 draft-vandevelde-idr-flowspec-path-redirect, and > =C2=B7 draft-li-idr-flowspec-redirect-generalized-sid > =20 > Some of the Questions that will be discuss are included below. Please = review the pre-recording presentations prior to the meeting. The = Chairs encourage discussion of these questions on the list before, = during, and after the meeting.=20 > =20 > Sue and John=20 > =20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > =20 > Agenda for IDR Virtual Interim Meeting > =20 > May 16, 2016 > 22:00 - 23:00 EDT > =20 > WebEx: = https://ietf.webex.com/ietf/j.php?MTID=3Dm9be481d19988dd1b545be6759aee267b= = > Meeting number: 649 235 411 > Meeting password: Jg66d2pm > Join by phone > 1-877-668-4493 Call-in toll free number (US/Canada) > 1-650-479-3208 Call-in toll number (US/Canada) > Access code: 649 235 411 > =20 > Questions for meeting: > =20 > Submitted by (Eric Wu) > 1. Redirect-to-Specific-Tunnel with BGP Path Attribute = [TUNNELENCAPS][MPP] and > Redirect-to-IID/GSID, Required by different use cases, can we have = two docs in IDR In parallel? > [Comparison to Redirect-to-IID/GSID , draft-hao will have more = little modification > to existing mechanisms, No need to do Mapping /Recursive Lookup.] > =20 > 2. For IID/GSID, one mapping table for > all kinds of segments/forwarding-entities vs. one mapping table > per segments/forwarding-entities type, should we support both? > =20 > Chair Questions:=20 > =20 > 1) Does the WG feel we need the following for RFC5575bis (DDoS) > a) Redirection to VRF, > b) Redirection to Indirection to IP, and =20 > c) Redirection to Service (new)? > =20 > 2) If the WG desires redirection to Service routing, does the WG = desire > a) Next-Hop tunnel support? - > b) Next-Hop TE Tunnel support? > c) Nested Tunnel support? > d) Next-Next Hop Tunnel Support? > e) Router localized Tunnel recursion? > f) Tunnel Encap Recursion: > =20 > 3) What pieces of the proposed solutions have been implemented > and/or deployed? =20 > =20 > =20 > Presentations (prerecorded, please review prior to meeting): > - draft-vandevelde-idr-flowspec-path-redirect > Gunter Van De Velde > 21 minutes > = https://ietf.webex.com/ietf/ldr.php?RCID=3De01d62661085f660f470feddd9bf266= f = > =20 > presentation at:=20 > = https://www.ietf.org/proceedings/interim/2016/05/16/idr/slides/slides-inte= rim-2016-idr-5-0.pdf = > =20 > =20 > draft-li-idr-flowspec-redirect-generalized-sid > Eric Wu=20 > 20 minutes=20 > =20 > Streaming recording link: > = https://ietf.webex.com/ietf/ldr.php?RCID=3Dc8615aa845801a1e4b79cb1708a0448= 4 = > Download recording link: > = https://ietf.webex.com/ietf/lsr.php?RCID=3D4bd504329727d2a811c9cb0c9bc713d= 8 = > =20 > presentation at:=20 > = https://www.ietf.org/proceedings/interim/2016/05/16/idr/slides/slides-inte= rim-2016-idr-5-1.pdf = > =20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr = --Apple-Mail=_6E8B4BF6-78D2-482F-A43D-1F145D588945 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Shunwan, Eric, All,

Inline: GV>

Timeline= = info
=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
 
draft-vandevelde-idr-flowspec-path-redirect-00 created on 14 = September 2015
draft-vandevelde-idr-flowspec-path-redirect-01 created on 12 = January 2016
draft-vandevelde-idr-flowspec-path-redirect-02 created on 17 = March 2016
 
draft-li-idr-flowspec-redirect-generalized-sid-00 created on = 21 March 2016
 
 
 [Reply 01] 
The idea of = draft-li-idr-flowspec-redirect-generalized-sid had initially been = presented in the IDR Interim Meeting of 2015-10-26:
https://www.ietf.org/proceedings/interim/2015/10/26/idr/slides/sl= ides-interim-2015-idr-12-8.pdf
and discussed in IDR mailing = list:
https://www.ietf.org/mail-archive/web/rtgwg/current/msg05195.html=
 
 

GV>
The suggested = references document justification discussions around draft-li-idr-mpls-path-programming-02. 
The reference indicates that draft-vandevelde can use the = indirection extended community to redirect to a tunnel programmed = by draft-li-idr-mpls-path-programming. =  


At Oct 26, = 2015, draft-vandevelde-idr-flowspec-path-redirect-00 described the = =E2=80=9Csemantics independent=E2=80=9D solution, but we think it should = simultaneously add =E2=80=9Csemantics dependent=E2=80=9D solution. That = happened before draft-vandevelde-idr-flowspec-path-redirect-01 which = created on 12 January 2016. At that time, we don=E2=80=99t think that a = separate document is immediately needed.
 
After = draft-vandevelde-idr-flowspec-path-redirect-01 created, we notice that = it did not integrate =E2=80=9Csemantics dependent=E2=80=9D solution, but = as per our Research and development team=E2=80=99s opinion, we need the = =E2=80=9Csemantics dependent=E2=80=9D Redirect Action solution.
 
Then = =E2=80=9Csemantics dependent=E2=80=9D Redirect to Generalized Segment ID = Action documented as draft-li-idr-flowspec-redirect-generalized-sid. = Coincidentally, at the same time, draft-vandevelde introduces =E2=80=9CB=E2= =80=9D bit to map the value encoded in the global administrator field to = a Binding Segment Identifier = value.
=

GV>
The concept of = draft-vandevelde to signal a flowspec client using a redirection = identifier is copied in draft-li without even referencing any version at = all of draft-vandevelde-idr-flowspec-path-redirect. = Coincidence?

* Concept of Indirection tables has been = added (hence adding the capability of context/semantics signalling = already since version -01)
[Reply 04]
Sorry, = about =E2=80=9Ccontext/semantics signalling already since version = -01=E2=80=9D, maybe we missed the related description or did not = understand it correctly, can you show us the text in version -01?
 

GV>
Draft-vandevelde = has a discussion around mapping tables, and has the extended = community =E2=80=98 eserved' bits that can be used to signal = semantics or tunnel mapping table, and hence the capability is = available. This capability is used when we actual added redirection to = SR binding SID.

 
Draft-vandevelde has indeed the potential to be used in such a = manner. The intend of this slide at the time of usage was to show an = extreme example of the flexiblity the technology offers. When for = example using redirection to binding-SID (as documented in latest = draft-vandevelde) then the local mapping table can be based around the = signalled semantics.
[Reply 08]
So = Draft-vandevelde planned to support two categories of the local mapping = tables?
1) the local mapping table per device;
2) the = local mapping table per service;
We think that =E2=80=9Csetup the = mapping tables per service type=E2=80=9D is easier to = implement.


GV>
This is an interesting = discussion. 
draft-vandevelde has the = capability to optionally couple semantics to a mapping = table.
This capability is a powerful = tool.  Because of this capability currently both (1) and = (2) are possible with draft-vandevelde. 

in= addition alternate creative categories could be i.e. : (3) a mapping = table per flowspec controller or (4) a table per tunnel configuration = method/controller.

draft-vandevelde can enforce semantic = coupling or can permit freedom to an operational user=E2=80=A6 There are = pro's and con=E2=80=99s for each, and i welcome the WG = to 
provide guidance on the operational = implications to complement draft-vandevelde=E2=80=A6 

G/



On 16 = May 2016, at 09:20, Zhuangshunwan <zhuangshunwan@huawei.com> wrote:

Hi = Gunter,
 
Thanks for your comments, Please see = responses inline.
 
Best  Regards,
Shunwan & Eric.Wu
 
=E5=8F=91=E4=BB=B6=E4=BA= =BA: Idr [mailto:idr-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Van De Velde, Gunter (Nokia - BE)
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2016=E5=B9=B45=E6=9C=8813=E6=97=A5 22:56
=E6=94=B6=E4=BB=B6=E4=BA=BA: idr@ietf.org
=E4=B8=BB=E9=A2=98: Re: [Idr] IDR interim on = May 16th - webex, questions for meeting, and recordings.
 
Pre-liminar comments=E2=80=A6..
 
Before = engaging with my feedback and addressing the discussion slides, i would = like to thank both Sue and John for going through the effort and time to = try to make the recordings as good as possible and investing non-trivial = amounts of time to get the job done.
 
I would also = like to thanks Eric Wu to go through the exercise of recording his = presentation of the slides. I went through the same exercise and even = though there were less operational issues to deal with during my = recording, it is a non-trivial task to speak to a screen and not to an = audience. 
 
 
Comments: Working slides discussion of the 16 May 2016 = Interim IDR meeting:
-------------
 
 
Timeline info
=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
 
draft-vandevelde-idr-flowspec-path-redirect-00 created on 14 = September 2015
draft-vandevelde-idr-flowspec-path-redirect-01 = created on 12 January 2016
draft-vandevelde-idr-flowspec-path-redirect-02 = created on 17 March 2016
 
draft-li-idr-flowspec-redirect-generalized-sid-00 created on = 21 March 2016
 
 
 [Reply 01] 
The idea of = draft-li-idr-flowspec-redirect-generalized-sid had initially been = presented in the IDR Interim Meeting of 2015-10-26:
https://www.ietf.org/proceedings/interim/2015/10/26/idr/slides/= slides-interim-2015-idr-12-8.pdf
and = discussed in IDR mailing list:
https://www.ietf.org/mail-archive/web/rtgwg/current/msg05195.ht= ml
 
At Oct 26, 2015, = draft-vandevelde-idr-flowspec-path-redirect-00 described the = =E2=80=9Csemantics independent=E2=80=9D solution, but we think it should = simultaneously add =E2=80=9Csemantics dependent=E2=80=9D solution. That = happened before draft-vandevelde-idr-flowspec-path-redirect-01 which = created on 12 January 2016. At that time, we don=E2=80=99t think that a = separate document is immediately needed.
 
After draft-vandevelde-idr-flowspec-path-redirect-01 created, = we notice that it did not integrate =E2=80=9Csemantics dependent=E2=80=9D = solution, but as per our Research and development team=E2=80=99s = opinion, we need the =E2=80=9Csemantics dependent=E2=80=9D Redirect = Action solution.
 
Then =E2=80=9Csemantics dependent=E2=80=9D Redirect to = Generalized Segment ID Action documented as = draft-li-idr-flowspec-redirect-generalized-sid. Coincidentally, at the = same time, draft-vandevelde introduces =E2=80=9CB=E2=80=9D bit to map = the value encoded in the global administrator field to a Binding Segment = Identifier value.
 
General slide observations about draft-li-generalised-sid-00 = (ref. discussion slide for 16 May 2016)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
Draft-li documents a flowspec action using a new community = (generalized-SID). The extended community provides a flowspec client = information to make a local forwarding decision by means of a local = mapping table. The two main components used by the flowspec client is: = (1) an identifier and (2) semantics.
 
Draft-vandevelde = documents a flowspec action using a new community (Indirection-ID). The = extended community provides a flowspec client information to make a = local forwarding decision by means of a local mapping table. The two = main components used by the flowspec client is: (1) an identifier and = (2) optionally semantics (Table semantics + Tunnel-ID).
 
draft-vandevelde-idr-flowspec-path-redirect-02 was = created =E2=80=9Cbefore" draft-li-idr-flowspec-redirect-generali= zed-sid-00 and achieves the same functionality and more. (For example = draft-vandevelde has the potential to signal 8192 types of semantic = mapping tables while draft-li has 255, another example is the TID field = which allows dynamic Next-Next-Hop constructs use for EPE DDoS = redirection).
[Reply 02]
The idea of draft-li-idr-flowspec-redirect-generalized-sid had initially = been presented in the IDR Interim Meeting of 2015-10-26: 
https://www.ietf.org/proceedings/interim/2015/10/26/idr/slides/= slides-interim-2015-idr-12-8.pdf
and = discussed in IDR mailing list:
https://www.ietf.org/mail-archive/web/rtgwg/current/msg05195.ht= ml
 
During WG addoption-call 3/25 to 4/8 the following has been = mentioned by Ignas: http://www.ietf.org/mail-archive/web/idr/current/msg15512.html<= /a>
 
"Draft-vandevelde can achieve all what draft-hao and draft-li = can, and in a more flexible way. Having the ability to decouple = redirection tunnel type from = redirection action is both practical and extensible - the actual tunnel = to be used is a local operational decision for each network element, it = is not necessary signalled at the same time and by the same mechanism. = Decoupling signalling and redirect parts aligns well to operational = practices of using specific tools for specific tasks. Just that BGP = could do that does not necesasry mean that it should be used as a best = fit. =46rom operational perspective there is no need to have multiple = solutions that try to address the narrow problem space in similar yet = incompatible ways. There should be one document for redirect, and = draft-vandevelde is a good starting base for that."
[Reply 03] 
As we = understand=EF=BC=8CDraft-vandevelde can=E2=80=99= t achieve what draft-hao can=EF=BC=8Cdraft-hao = specifies the specific tunnel from Flowspec Controller and the redirect = tunnel information is encoded in BGP Path Attribute [TUNNELENCAPS][MPP] = that is carried in the BGP flow-spec UPDATE.
Comparison = to draft-vandevelde, draft-hao will have more little modification to = existing mechanisms, No need to do Mapping /Recursive Lookup.
 
 
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Slide 2 (of the draft-li = presentation): History 
=3D=3D
The slide forgets to mention = that draft-vandevelde was enhanced and progressed based upon = constructive WG feedback. Much feedback has been integrated between = draft-vandevelde -00 to =E2=80=9302 BEFORE draft=E2=80=93li even = existed. For example:
* Use-case scenario=E2=80=99s = were added
* "Path-id" changed to "Indirection-id"
Sorry, about =E2=80=9Ccontext/semantics = signalling already since version -01=E2=80=9D, maybe we missed the = related description or did not understand it correctly, can you show us = the text in version -01?
 
* Flowspec validation information is added
 
It is an incorrect assumption of = no context awareness in draft-vandevelde. = draft-vandevelde-idr-flowspec-path-redirect added context support before = draft-li existed, and raises questions about new elements exposed with = draft-li compared to draft-vandevelde.
[Reply 05]
Please = refer to Reply 01.
 
(fwiw The = semantic awareness of draft-vandevelde is mentioned and the webex = recording of draft-li between recording time-stamps 11m30s to = 13m30s)
 
 
Slide 3 (of the draft-li presentation)
=3D=3D
 
No new capability is explained on this slide in = comparison with the draft-vandevelde.
[Reply 06]
Also, = please refer to Reply 01.
Slide 4 (of the draft-li = presentation)
=3D=3D
The goal of draft-li is to = define a =E2=80=9Csemantics dependent=E2=80=9D action.
[Reply 07]
Also, = please refer to Reply 01.
Slide 5 (of the draft-li = presentation)
=3D=3D
Draft-vandevelde has indeed the = potential to be used in such a manner. The intend of this slide at the = time of usage was to show an extreme example of the flexiblity the = technology offers. When for example using redirection to binding-SID (as = documented in latest draft-vandevelde) then the local mapping table can = be based around the signalled semantics.
So Draft-vandevelde planned to support two = categories of the local mapping tables?
1) the = local mapping table per device;
2) the local mapping table per = service;
 
 
Slide 6 (of the draft-li = presentation)
=3D=3D
Draft-vandevelde = has 13 bits available for types, hence the potential to support/signal = 2^13 (=3D8192) types when using the field as scalar value (when = comparing with a potential for 255 types using draft-li)
The claim made on = slide6 that draft-vandevelde allows only 13 type of semantic information = is wrong assumption.
[Reply 09]
Sure, if = draft-vandevelde uses more bits to present the type of semantic = information and use them as type value like draft-li does, not =E2=80=9CPe= r Service Per Bit=E2=80=9D as Binding Bit defines in draft-vandevelde =  version -02.
At the time of writing, it was = found useful to signal binding SID useful semantic =E2=80=A6 We decided = to leave the remaining bits reserved/open for discussion on how to best = use the field instead. 
Maybe the WG feels it is best to use only a few bits = for semantics and keep the remainder reserved for future use. 
Kind Regards,
 
 
 
From: Idr <idr-bounces@ietf.org> on = behalf of Susan Hares <shares@ndzh.com>
Date: Friday 13 May 2016 at = 12:46
To: "idr@ietf.org" <idr@ietf.org>
Subject: [Idr] IDR interim on = May 16th - webex, questions for meeting, and recordings.
 
The time of the interim is = 22:00-23:00 EDT on May 16th.  
 
The interim will discuss the = following two drafts in order to create a WG solution:
 
=C2=B7         draft-vandevelde-idr-flowspec-path-redirect, and
=C2=B7         draft-li-idr-flowspec-redirect-generalized-sid
 
Some of the Questions that will be = discuss are included below.  Please review the pre-recording = presentations prior to the meeting.   The Chairs encourage = discussion of these questions on the list before, during, and after the = meeting. 
 
Sue and John 
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
Agenda= for IDR Virtual Interim Meeting
 
May 16, 2016
22:00 - 23:00 EDT
 
WebEx: https://ietf.webex.com/ietf/j.php?MTID=3Dm9be481d19988dd1b545be= 6759aee267b
Meeting = number:            = 649 235 411
Meeting = password:         Jg66d2pm
Join by phone
1-877-668-4493 Call-in toll free = number (US/Canada)
1-650-479-3208 = Call-in toll number (US/Canada)
Access code: 649 235 411
 
Questions for meeting:
 
Submitted by (Eric = Wu)
1. = Redirect-to-Specific-Tunnel with BGP Path Attribute [TUNNELENCAPS][MPP] = and
  Redirect-to-IID/GSID, Required by different use = cases, can we have two docs in IDR In parallel?
  [Comparison to = Redirect-to-IID/GSID , draft-hao will have more little modification
  to existing mechanisms, = No need to do Mapping /Recursive Lookup.]
 
2.  For IID/GSID, one mapping = table for
  all = kinds of segments/forwarding-entities vs. one mapping table
  per = segments/forwarding-entities type, should we support both?
 
Chair = Questions: 
 
1) Does the WG feel we need the = following for RFC5575bis (DDoS)
  a) Redirection to VRF,
  b) Redirection to = Indirection to IP, and  
  c) Redirection to Service (new)?
  
2) If the WG desires redirection to = Service routing, does the WG desire
a) Next-Hop tunnel support? -
b) Next-Hop TE Tunnel support?
 c) Nested Tunnel support?
 d) Next-Next Hop Tunnel = Support?
 e) Router = localized Tunnel recursion?
 f) Tunnel Encap Recursion:
 
3) What pieces of the proposed = solutions have been implemented
   and/or deployed?  
 
 
Presentations = (prerecorded, please review prior to meeting):
- = draft-vandevelde-idr-flowspec-path-redirect
  Gunter Van De Velde
  21 minutes
  https://ietf.webex.com/ietf/ldr.php?RCID=3De01d62661085f660f470= feddd9bf266f
 
presentation at: 
https://www.ietf.org/proceedings/interim/2016/05/16/idr/slides/= slides-interim-2016-idr-5-0.pdf
 
 
draft-li-idr-flowspec-redirect-generalized-sid
Eric Wu 
20 minutes 
 
Streaming recording link:
https://ietf.webex.com/ietf/ldr.php?RCID=3Dc8615aa845801a1e4b79= cb1708a04484
Download recording = link:
 
presentation at: 
https://www.ietf.org/proceedings/interim/2016/05/16/idr/slides/= slides-interim-2016-idr-5-1.pdf
 _______________________________________________
Idr mailing = list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

= --Apple-Mail=_6E8B4BF6-78D2-482F-A43D-1F145D588945-- From nobody Mon May 16 13:16:57 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2044C12DA19 for ; Mon, 16 May 2016 13:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQQ6Oz7anBJ5 for ; Mon, 16 May 2016 13:16:53 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68C9312DA13 for ; Mon, 16 May 2016 13:16:52 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CKA35151; Mon, 16 May 2016 20:16:50 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 16 May 2016 21:16:49 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Mon, 16 May 2016 13:16:44 -0700 From: Lucy yong To: "John G. Scudder" , "idr@ietf.org" , Gunter Van De Velde Thread-Topic: [Idr] Presentation recording for draft-vandevelde-idr-flowspec-path-redirect, for Monday May 16 interim Thread-Index: AQHRrGYmCfZcsaSZg0uJXp7XZ6Ov/5+7whZw Date: Mon, 16 May 2016 20:16:43 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D5728A8D4@dfweml501-mbb> References: <1135213839.1375091463067745545.JavaMail.nobody@rva2rmd002.webex.com> <41E94382-3E38-4599-B8AB-86A57E75AE38@juniper.net> In-Reply-To: <41E94382-3E38-4599-B8AB-86A57E75AE38@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.142] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D5728A8D4dfweml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.573A2AB2.01E5, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 5c642b2b7f4ffc7a9bef9c50e223866f Archived-At: Subject: Re: [Idr] Presentation recording for draft-vandevelde-idr-flowspec-path-redirect, for Monday May 16 interim X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 20:16:56 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D5728A8D4dfweml501mbb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Gunter, Thank you for the presentation. Some comments: 1) Both your draft and li's draft propose logical flow spec redirect with l= ocal mapping method, which, I agree, is a good approach for flow spec redir= ect under centre controller environment. 2) Your draft uses 'bit' to indicate type of tunnel, li's draft uses Code P= oint to indicate type of tunnel. I think that the latter is better semantic= s for this. 3) To support nested tunnel, it is good for protocol to support both a same= type of tunnel segments and different types of tunnel segments. Li's draf= t supports that easily (code point: none). 4) Your solution can support the use cases specified in Section 3.1-3.3 (yo= ur draft), but does not have a way to bind to a particular use case. It rel= ies on local mapping, which is a separate process. Li's draft has explicitl= y binding to type of redirect tunnel. Regards, Lucy From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder Sent: Thursday, May 12, 2016 10:51 AM To: idr@ietf.org Subject: [Idr] Presentation recording for draft-vandevelde-idr-flowspec-pat= h-redirect, for Monday May 16 interim Hi Everyone, The recording for Gunter's presentation is available, link below. Please re= view it before the interim on Monday. I'll send another message when the sl= ides have been uploaded to the meeting materials site. As a reminder, we are having presenters record their talks instead of doing= them live, as an experiment in dealing with the challenges of virtual inte= rims across many timezones. This lets us time-shift much of the work, hopef= ully accommodating people's time zone requirements better. We'll be interes= ted in your feedback regarding how well (or poorly) it worked, after the Mo= nday meeting. And another reminder, if you have questions or comments regarding the prese= ntation or draft, please consider providing them on the mailing list. There= is no need to wait until the interim, although of course if you'd rather d= o it verbally during the meeting that's OK too. Regards, --John Begin forwarded message: From: IDR Working Group > Subject: WebEx recording is available for viewing: draft-vandevelde-idr-flo= wspec-path-redirect-20160512 1502-1 Date: May 12, 2016 at 11:42:25 AM EDT To: > Reply-To: > Hello, IDR Working Group wants to share this WebEx recording with you. draft-vandevelde-idr-flowspec-path-redirect-20160512 1502-1 Thursday, May 12, 2016 11:30 am | Eastern Daylight Time (New York, GMT-04:00) Play recording (21 min) Recording password: (This recording does not require a password.) --_000_2691CE0099834E4A9C5044EEC662BB9D5728A8D4dfweml501mbb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Gunter,

 

Thank you for the pres= entation. Some comments:

 

1) Both your draft and= li’s draft propose logical flow spec redirect with local mapping met= hod, which, I agree, is a good approach for flow spec redirect under centre controller environment.

2) Your draft uses = 216;bit’ to indicate type of tunnel, li’s draft uses Code Point= to indicate type of tunnel. I think that the latter is better semantics fo= r this.

3) To support nested t= unnel, it is good for protocol to support both a same type of tunnel segmen= ts and different types of tunnel segments.  Li’s draft supports that easily (code point: none).

4) Your solution can s= upport the use cases specified in Section 3.1-3.3 (your draft), but does no= t have a way to bind to a particular use case. It relies on local mapping, which is a separate process. Li’s draft has explic= itly binding to type of redirect tunnel.

 

Regards,

Lucy=

 

 

From: Idr [mai= lto:idr-bounces@ietf.org] On Behalf Of John G. Scudder
Sent: Thursday, May 12, 2016 10:51 AM
To: idr@ietf.org
Subject: [Idr] Presentation recording for draft-vandevelde-idr-flows= pec-path-redirect, for Monday May 16 interim

 

Hi Everyone,

 

The recording for Gunter's presentation is available= , link below. Please review it before the interim on Monday. I'll send anot= her message when the slides have been uploaded to the meeting materials sit= e.

 

As a reminder, we are having presenters record their= talks instead of doing them live, as an experiment in dealing with the cha= llenges of virtual interims across many timezones. This lets us time-shift = much of the work, hopefully accommodating people's time zone requirements better. We'll be interested in your feedba= ck regarding how well (or poorly) it worked, after the Monday meeting.=

 

And another reminder, if you have questions or comme= nts regarding the presentation or draft, please consider providing them on = the mailing list. There is no need to wait until the interim, although of c= ourse if you'd rather do it verbally during the meeting that's OK too.

 

Regards,

 

--John



Begin forwarded message:

 

From: IDR Working Group <messenger@w= ebex.com>

Subject: WebEx recording is available for viewing: draft-vandevelde-i= dr-flowspec-path-redirect-20160512 1502-1

Date: May 12, 2016 at 11:42:25 AM EDT

 

Hello,

IDR Working Group wants to share this WebEx record= ing with you.

 

 

 

draft-vandevelde-idr-flowspec-path-redirect-20160512 1502-1

Thursday, May 12, 2016

11:30 am  |  Eastern Daylight = Time (New York, GMT-04:00)

 

 

 

= Play recording<= span style=3D"font-size:11.5pt;font-family:"Arial","sans-ser= if";color:#666666"> (21 min)

Recording password: (This recording does not requi= re a password.)

 

--_000_2691CE0099834E4A9C5044EEC662BB9D5728A8D4dfweml501mbb_-- From nobody Mon May 16 17:02:26 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531E212D555 for ; Mon, 16 May 2016 17:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awFUHaX4V54x for ; Mon, 16 May 2016 17:02:23 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3B412D551 for ; Mon, 16 May 2016 17:02:23 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id A86931E336; Mon, 16 May 2016 20:07:33 -0400 (EDT) Date: Mon, 16 May 2016 20:07:33 -0400 From: Jeffrey Haas To: "John G. Scudder" Message-ID: <20160517000733.GG6332@pfrc.org> References: <1135213839.1375091463067745545.JavaMail.nobody@rva2rmd002.webex.com> <41E94382-3E38-4599-B8AB-86A57E75AE38@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41E94382-3E38-4599-B8AB-86A57E75AE38@juniper.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] Presentation recording for draft-vandevelde-idr-flowspec-path-redirect, for Monday May 16 interim X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 00:02:24 -0000 On Thu, May 12, 2016 at 11:50:36AM -0400, John G. Scudder wrote: > The recording for Gunter's presentation is available, link below. Please review it before the interim on Monday. I'll send another message when the slides have been uploaded to the meeting materials site. Having listened to the pre-recorded presentation, I'd like to support their use for future virtual interims. I think this was very useful. The remainder of my comments are probably most appropriate for the discussion portion of the interim. -- Jeff From nobody Mon May 16 20:28:37 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 855A812B022 for ; Mon, 16 May 2016 20:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.638 X-Spam-Level: *** X-Spam-Status: No, score=3.638 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5kbPRs6JTIS for ; Mon, 16 May 2016 20:28:34 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F186312D593 for ; Mon, 16 May 2016 20:28:33 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.63; From: "Susan Hares" To: Date: Mon, 16 May 2016 23:28:28 -0400 Message-ID: <001601d1afec$2fc83e50$8f58baf0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0017_01D1AFCA.A8B824F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdGv6+j7iP+P9uvZQaWXGTiwop69+g== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: "'John G. Scudder'" Subject: [Idr] IDR Interim on May 16, 2016 - 10-11pm X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 03:28:35 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0017_01D1AFCA.A8B824F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit IDR Wg: Thank you to all the people who attended to the late night tonight. The minute are online at https://www.ietf.org/proceedings/interim/2016/05/16/idr/minutes/minutes-inte rim-2016-idr-5 The discussion was extremely helpful on discussing these two drafts. Thank you to all who participated, Sue and John Recording: Fowspec tunnel redirection-20160517 0209-1 Create time: 5/16/16 11:13 pm File size: 33.06MB Duration: 1 hour 1 minute Security: Description: Streaming recording link: https://ietf.webex.com/ietf/ldr.php?RCID=18809569d575428db56252b203bb1058 Download recording link: https://ietf.webex.com/ietf/lsr.php?RCID=0d29b7628bb39b1b2a3904df09daf369 Play Recorded Meeting Now ------=_NextPart_000_0017_01D1AFCA.A8B824F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IDR Wg: =

 

Thank you to all the people who attended to the late = night tonight.

 

The minute = are online at

https://www.ietf.org/proceedings/interim/2016/= 05/16/idr/minutes/minutes-interim-2016-idr-5

 

The = discussion was extremely helpful on discussing these two drafts.  =

 

Thank you to all who participated,

 

Sue and John =

 

Recording:

 

Fowspec tunnel redirection-20160517 = 0209-1

Create = time:

5/16/16 11:13 pm

File = size:

33.06MB

Duration:

1 hour 1 minute

Security:

Description:

Streaming recording = link:

https://ietf.webex.com/ietf/= ldr.php?RCID=3D18809569d575428db56252b203bb1058

=

Download recording = link:

https://ietf.webex.com/ietf/= lsr.php?RCID=3D0d29b7628bb39b1b2a3904df09daf369

=

Play Recorded Meeting = Now

 

------=_NextPart_000_0017_01D1AFCA.A8B824F0-- From nobody Tue May 17 05:27:10 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 20B7D12D55F; Tue, 17 May 2016 05:27:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160517122706.22265.32273.idtracker@ietfa.amsl.com> Date: Tue, 17 May 2016 05:27:06 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-flowspec-l2vpn-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 12:27:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : Dissemination of Flow Specification Rules for L2 VPN Authors : Weiguo Hao Qiandeng Liang Stephane Litkowski Shunwan Zhuang Filename : draft-ietf-idr-flowspec-l2vpn-04.txt Pages : 13 Date : 2016-05-17 Abstract: This document defines BGP flow-spec extension for Ethernet traffic filtering in L2 VPN network. SAFI=134 in [RFC5575] is redefined for dissemination traffic filtering information in an L2VPN environment. A new subset of component types and extended community also are defined. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-l2vpn/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-flowspec-l2vpn-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-flowspec-l2vpn-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 17 07:11:45 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D68C512D5D5; Tue, 17 May 2016 07:11:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160517141142.22323.67104.idtracker@ietfa.amsl.com> Date: Tue, 17 May 2016 07:11:42 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-flowspec-nvo3-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 14:11:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : Dissemination of Flow Specification Rules for NVO3 Authors : Weiguo Hao Shunwan Zhuang Zhenbin Li Rong Gu Filename : draft-ietf-idr-flowspec-nvo3-00.txt Pages : 9 Date : 2016-05-17 Abstract: This draft proposes a new subset of component types to support the NVO3 flow-spec application. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-nvo3/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-flowspec-nvo3-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 18 03:19:06 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D37F12D1B1; Wed, 18 May 2016 03:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U80fjvFXWXyS; Wed, 18 May 2016 03:19:01 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DDC512D1AD; Wed, 18 May 2016 03:19:01 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 287CF324CC7; Wed, 18 May 2016 12:18:59 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.3]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id E5617238056; Wed, 18 May 2016 12:18:58 +0200 (CEST) Received: from [10.193.71.12] (10.168.234.3) by OPEXCLILM5D.corporate.adroot.infra.ftgroup (10.114.31.3) with Microsoft SMTP Server (TLS) id 14.3.294.0; Wed, 18 May 2016 12:18:56 +0200 To: John E Drake , IDR , BESS , "draft-ietf-bess-evpn-overlay@tools.ietf.org" , "Ali Sajassi (sajassi)" , "Rabadan, Jorge (Nokia - US)" , "draft-ietf-idr-tunnel-encap@tools.ietf.org" References: <5729F1C3.1030605@orange.com> <5729F7C5.6040604@orange.com> <52D35106-ED5E-4C95-9131-6EA4527370D5@alcatel-lucent.com> <012C176C-A8D6-45AA-BA69-616C0ED7E41E@alcatel-lucent.com> <420BA2D8D80A6727.2B2C290F-2299-40BB-B53B-CC36D2B5D826@mail.outlook.com> <1881_1462451514_572B3D3A_1881_7198_1_0vn90oitr7e881gh2sn8qm5f.1462451509961@email.android.com> <17029_1462484835_572BBF63_17029_2323_1_opi9hqsl9b9tani0t0skkcuq.1462484831251@email.android.com> From: Organization: Orange Message-ID: <28175_1463566739_573C4192_28175_2444_1_613f729b-d12e-5c48-29a1-ff000c1184a1@orange.com> Date: Wed, 18 May 2016 12:18:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------2664359F78BA3B94A7874F26" X-Originating-IP: [10.168.234.3] X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.5.18.90316 Archived-At: Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 10:19:05 -0000 --------------2664359F78BA3B94A7874F26 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Hi John, John. > When the tunnel encaps draft was first published it did not carry > forward the RFC 5512 extended community and it did not propose to > obsolete RFC 5512. There was discussion of using the attribute > defined in the tunnel encaps draft instead of the extended community > and we decided to continue to use the extended community. So, in that > sense we are misaligned with the tunnel encaps draft. As you confirm below, the last sentence is only true in the past tense. > Subsequently, however, the tunnel encaps draft decided to carry > forward the extended community and to obsolete RFC 5512, so we were > effectively covered by a grandfather clause. > Yes, precisely: given the content of the two drafts, there is no misalignment anymore. > Given the overlay draft’s tardiness, I don’t think that’s acceptable > and would prefer to continue to refer to RFC 5512. > I do not think that the additional publication delay is a sound rationale for normatively refer to a spec that is known to become obsolete. If it helps, the draft can keep an informative ref to RFC5512 and remind that it does not rely on anything specifically introduced by draft-ietf-idr-tunnel-encaps and not existing already in RFC5512. -Thomas 2016-05-06, John E Drake: > > However, even though I agreed yesterday to refer to the tunnel encaps > draft instead of RFC 5512 we have an issue with doing this, viz, the > overlay draft makes a normative reference to RFC 5512. If we change > the normative reference to the tunnel encaps draft we cannot publish > the overlay draft until after the tunnel encaps draft has been published. > > Given the overlay draft’s tardiness, I don’t think that’s acceptable > and would prefer to continue to refer to RFC 5512. > > Yours Irrespectively, > > John > > *From:*thomas.morin@orange.com [mailto:thomas.morin@orange.com] > *Sent:* Thursday, May 05, 2016 5:47 PM > *To:* IDR; BESS; draft-ietf-bess-evpn-overlay@tools.ietf.org; Ali > Sajassi (sajassi); Rabadan, Jorge (Nokia - US); > draft-ietf-idr-tunnel-encap@tools.ietf.org; John E Drake > *Subject:* RE: [Idr] draft-ietf-bess-evpn-overlay vs. > draft-ietf-idr-tunnel-encaps > > Hi John, > > I have a hard time reconciliating the fact that yesterday you were > fine with having bess-evpn-overlay refer to idr-tunnel-encap instead > of RFC5512, with the fact that you consider (below) the two docs "not > aligned" for unicast. > > Can you be more explicit in where the "misalignment" lies? > > -Thomas > > ---- John E Drake a écrit ---- > > Thomas, > > The overlay draft preceded the tunnel encaps draft and it was designed > to handle a very specific problem, marrying the EVPN control plane to > the VXLAN data plane draft and modulo the correction to section 9 it > is internally consistent. > > The tunnel encaps draft solves a more general problem and the WG > decided a long time ago that the overlay draft was not going to be > updated to use the mechanisms it details for unicast, so the overlay > draft is already explicitly not in alignment with it. > > This, plus the fact that the tunnel encaps draft explicitly puts the > PMSI out of scope, leads me to the conclusion that the overlay draft > should not be tweaked to be in alignment with a future solution for > encoding VNIs for multicast. > > Yours Irrespectively, > > John > > *From:*thomas.morin@orange.com > [mailto:thomas.morin@orange.com] > *Sent:* Thursday, May 05, 2016 8:32 AM > *To:* John E Drake; IDR; BESS; > draft-ietf-bess-evpn-overlay@tools.ietf.org > ; Ali Sajassi > (sajassi); Rabadan, Jorge (Nokia - US); > draft-ietf-idr-tunnel-encap@tools.ietf.org > > *Subject:* RE: [Idr] draft-ietf-bess-evpn-overlay vs. > draft-ietf-idr-tunnel-encaps > > Thanks for the clarification on the intent around > draft-ietf-bess-evpn-overlay. Then indeed section 9 needs some tidying > up. > > The issue that I think remain is that it would be much cleaner to > explain how to use PMSI with overlay encaps in a spec not specific to > E-VPN and in a way more consistent to what is done for unicast. > > It seems if course that draft-ietf-idr-tunnel-encap should be the > place, but that document currently explicitly makes PMSIs out of scope. > > Shouldn't this part of draft-ietf-idr-tunnel-encap be revisited ? > > -Thomas > > > ---- Rabadan, Jorge (Nokia - US) a écrit ---- > > Fully agree John. That's what I meant, sorry if I didn't make myself > clear. Section 9 needs clean up, yes. > > Thanks, > Jorge > > _____________________________ > From: EXT John E Drake > > Sent: Wednesday, May 4, 2016 23:34 > Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. > draft-ietf-idr-tunnel-encaps > To: IDR >, Ali Sajassi (sajassi) > >, Rabadan, Jorge (Nokia > - US) >, BESS >, >, EXT - > thomas.morin@orange.com > > > > > Jorge, > > We put the VNI value in the MPLS label field of the PMSI attribute for > all service types, and we put a value in the Ethernet Tag field > following the rules for each service type as described in 5.1.3 > (https://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-02#section-5.1.3). > > You're right that we need to clean up section 9. > > Yours Irrespectively, > > John > > > -----Original Message----- > > From: Rabadan, Jorge (Nokia - US) [mailto:jorge.rabadan@nokia.com] > > Sent: Wednesday, May 04, 2016 3:53 PM > > To: John E Drake; EXT - thomas.morin@orange.com > ; BESS; IDR; draft-ietf-bess-evpn- > > overlay@tools.ietf.org ; Ali Sajassi > (sajassi) > > Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. > draft-ietf-idr-tunnel-encaps > > > > Hi John, > > > > About this: > > > > [JD] For the IMET route the MPLS label field is carried in the PMSI > attribute. I think we need > > to ask everyone whether they used the Ethernet Tag or the PMSI > attribute to carry the VNI > > > > > > In case it helps, I’ve seen a few implementations running and they > all encode the VNI in the > > MPLS label field in the PTA. And a couple of them, encode the VNI in > the ethernet-tag, in > > addition to the MPLS label in the PTA. In any case, I think section > 9 contradicts section 5.1.3 > > and should be clarified. > > > > "5.1.3 Constructing EVPN BGP Routes > > > > the MPLS label field in the MAC Advertisement, Ethernet AD per EVI, > and **Inclusive > > Multicast Ethernet Tag** routes is used to carry the VNI or VSID." > > > > Thanks. > > Jorge > > > > > > > > > > > > On 5/4/16, 8:34 PM, "EXT John E Drake" > wrote: > > > > >Thomas and Jorge, > > > > > >Snipped, comments inline. > > > > > >Yours Irrespectively, > > > > > >John > > > > > >> > > > >> >draft-ietf-bess-evpn-overlay (see section 9) relies on the BGP > > >> >Encapsulation extended to encode the tunnel encap to use for BUM > > >> >traffic, but contrary to other E-VPN routes, relies on the Ethernet > > >> >Tag field of the NLRI to encode the VNI/VSID. > > >> > > >> [JORGE] This is certainly a leftover from an old version where the > > >> VNI/VSID was encoded in the ethernet tag for all the routes. The VNI > > >> should be encoded in the Label field in all the routes. This has > to be corrected. > > >> > > >> In fact, section 5.1.3 says: > > >> > > >> 5.1.3 Constructing EVPN BGP Routes > > >> > > >> > > >> > > >> Accordingly, and > > >> specifically to support the option of locally assigned VNIs, the MPLS > > >> label field in the MAC Advertisement, Ethernet AD per EVI, and > > >> Inclusive Multicast Ethernet Tag routes is used to carry the VNI or > > >> VSID. For the balance of this memo, the MPLS label field will be > > >> referred to as the VNI/VSID field. The VNI/VSID field is used for > > >> both local and global VNIs/VSIDs, and for either case the entire 24- > > >> bit field is used to encode the VNI/VSID value. > > >> > > >> > > > > > > > > >[JD] For the IMET route the MPLS label field is carried in the PMSI > attribute. I think we > > need to ask everyone whether they > > >used the Ethernet Tag or the PMSI attribute to carry the VNI > > > > > > > > >> >> > > >> >> There are minor things that could be improved in > > >> >> draft-ietf-bess-evpn-overlay wrt. consistency with > > >> >> draft-ietf-idr-tunnel-encaps : > > >> >> > > >> >> * since draft-ietf-idr-tunnel-encaps will deprecate RFC5512, it > > >> >> would be better that draft-ietf-bess-evpn-overlay refers to > > >> >> draft-ietf-idr-tunnel-encaps and not anymore to RFC5512. > > >> > > >> [JORGE] I agree, as long as draft-ietf-idr-tunnel-encaps keeps the > > >> encapsulation extended community. There are a few implementations > > >> using this community and it is enough when only the encapsulation > type is needed. > > > > > > > > >[JD] I agree and the tunnel encaps draft does keep the EC > > > > > > > > >> > > >> >> > > >> >> * I think it would be better to avoid the explicit list of encap > > >> >> types in section 5.1.3, and rather refer to > > >> >> draft-ietf-idr-tunnel-encaps instead > > >> > > >> [JORGE] I agree. > > > > > > > > >[JD] According to IANA, it allocated the five tunnels types to the > > >overlay draft so I think we need to keep them > > > > > > > > >> > > >> >> * the following minor modification was proposed, but not yet > incorporated: > > >> >> > > >> >> John Drake, 2015-11-13 (to BESS ML): > > >> >>> For the overlay draft, replace this text in section 5.1.3: > > >> >>> > > >> >>> "If the BGP Encapsulation extended community is not present, > > >> >>> then the default MPLS encapsulation or a statically configured > > >> >>> encapsulation is assumed." > > >> >>> > > >> >>> With the following: > > >> >>> > > >> >>> "Note that the MPLS encapsulation tunnel type is needed in > > >> >>> order to distinguish between an advertising node that only > > >> >>> supports non-MPLS encapsulations and one that supports MPLS and > > >> >>> non-MPLS encapsulations. An advertising node that only supports > > >> >>> MPLS encapsulation does not need to advertise any encapsulation > > >> >>> tunnel types; i.e., if the BGP Encapsulation extended community > > >> >>> is not present, then either MPLS encapsulation or a statically > > >> >>> configured encapsulation is assumed." > > >> >> > > >> >> I think this change is useful and should be incorporated, although > > >> >> skipping the last sentence would be wise if the full list of > > >> >> tunnel types is removed. > > > > > > > > >[JD] Fine with me either w/ or w/o the last sentence > > > > > > > _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. --------------2664359F78BA3B94A7874F26 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit
Hi John,

John.
When the tunnel encaps draft was first published it did not carry forward the RFC 5512 extended community and it did not propose to obsolete RFC 5512.  There was discussion of using the attribute defined in the tunnel encaps draft instead of the extended community and we decided to continue to use the extended community.  So, in that sense we are misaligned with the tunnel encaps draft.

As you confirm below, the last sentence is only true in the past tense.

Subsequently, however, the tunnel encaps draft decided to carry forward the extended community and to obsolete RFC 5512, so we were effectively covered by a grandfather clause.


Yes, precisely: given the content of the two drafts, there is no misalignment anymore.

Given the overlay draft’s tardiness, I don’t think that’s acceptable and would prefer to continue to refer to RFC 5512.


I do not think that the additional publication delay is a sound rationale for normatively refer to a spec that is known to become obsolete.
If it helps, the draft can keep an informative ref to RFC5512 and remind that it does not rely on anything specifically introduced by draft-ietf-idr-tunnel-encaps and not existing already in RFC5512.

-Thomas


2016-05-06, John E Drake:
 

However, even though I agreed yesterday to refer to the tunnel encaps draft instead of RFC 5512 we have an issue with doing this, viz, the overlay draft makes a normative reference to RFC 5512.  If we change the normative reference to the tunnel encaps draft we cannot publish the overlay draft until after the tunnel encaps draft has been published.

 

Given the overlay draft’s tardiness, I don’t think that’s acceptable and would prefer to continue to refer to RFC 5512.

 

Yours Irrespectively,

 

John

 

From: thomas.morin@orange.com [mailto:thomas.morin@orange.com]
Sent: Thursday, May 05, 2016 5:47 PM
To: IDR; BESS; draft-ietf-bess-evpn-overlay@tools.ietf.org; Ali Sajassi (sajassi); Rabadan, Jorge (Nokia - US); draft-ietf-idr-tunnel-encap@tools.ietf.org; John E Drake
Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps

 

Hi John,

I have a hard time reconciliating the fact that yesterday you were fine with having bess-evpn-overlay refer to idr-tunnel-encap instead of RFC5512, with the fact that you consider (below) the two docs "not aligned" for unicast.

Can you be more explicit in where the "misalignment" lies?

-Thomas

---- John E Drake a écrit ----

Thomas,

 

The overlay draft preceded the tunnel encaps draft and it was designed to handle a very specific problem, marrying the EVPN control plane to the VXLAN data plane draft and modulo the correction to section 9 it is internally consistent.

 

The tunnel encaps draft solves a more general problem and the WG decided a long time ago that the overlay draft was not going to be updated to use the mechanisms it details for unicast, so the overlay draft is already explicitly not in alignment with it.

 

This, plus the fact that the tunnel encaps draft explicitly puts the PMSI out of scope, leads me to the conclusion that the overlay draft should not be tweaked to be in alignment with a future solution for encoding VNIs for multicast.

 

Yours Irrespectively,

 

John

 

From: thomas.morin@orange.com [mailto:thomas.morin@orange.com]
Sent: Thursday, May 05, 2016 8:32 AM
To: John E Drake; IDR; BESS; draft-ietf-bess-evpn-overlay@tools.ietf.org; Ali Sajassi (sajassi); Rabadan, Jorge (Nokia - US); draft-ietf-idr-tunnel-encap@tools.ietf.org
Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps

 

Thanks for the clarification on the intent around draft-ietf-bess-evpn-overlay. Then indeed section 9 needs some tidying up.

The issue that I think remain is that it would be much cleaner to explain how to use PMSI with overlay encaps in a spec not specific to E-VPN and in a way more consistent to what is done for unicast.

It seems if course that draft-ietf-idr-tunnel-encap should be the place, but that document currently explicitly makes PMSIs out of scope.

Shouldn't this part of draft-ietf-idr-tunnel-encap be revisited ?

-Thomas


---- Rabadan, Jorge (Nokia - US) a écrit ----

Fully agree John. That's what I meant, sorry if I didn't make myself clear. Section 9 needs clean up, yes.

Thanks,
Jorge

 

_____________________________
From: EXT John E Drake <jdrake@juniper.net>
Sent: Wednesday, May 4, 2016 23:34
Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps
To: IDR <idr@ietf.org>, Ali Sajassi (sajassi) <sajassi@cisco.com>, Rabadan, Jorge (Nokia - US) <jorge.rabadan@alcatel-lucent.com>, BESS <bess@ietf.org>, <draft-ietf-bess-evpn-overlay@tools.ietf.org>, EXT - thomas.morin@orange.com <thomas.morin@orange.com>


Jorge,

We put the VNI value in the MPLS label field of the PMSI attribute for all service types, and we put a value in the Ethernet Tag field following the rules for each service type as described in 5.1.3 (https://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-02#section-5.1.3).

You're right that we need to clean up section 9.

Yours Irrespectively,

John

> -----Original Message-----
> From: Rabadan, Jorge (Nokia - US) [mailto:jorge.rabadan@nokia.com]
> Sent: Wednesday, May 04, 2016 3:53 PM
> To: John E Drake; EXT - thomas.morin@orange.com; BESS; IDR; draft-ietf-bess-evpn-
> overlay@tools.ietf.org; Ali Sajassi (sajassi)
> Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps
>
> Hi John,
>
> About this:
>
> [JD] For the IMET route the MPLS label field is carried in the PMSI attribute. I think we need
> to ask everyone whether they used the Ethernet Tag or the PMSI attribute to carry the VNI
>
>
> In case it helps, I’ve seen a few implementations running and they all encode the VNI in the
> MPLS label field in the PTA. And a couple of them, encode the VNI in the ethernet-tag, in
> addition to the MPLS label in the PTA. In any case, I think section 9 contradicts section 5.1.3
> and should be clarified.
>
> "5.1.3 Constructing EVPN BGP Routes
> <snip>
> the MPLS label field in the MAC Advertisement, Ethernet AD per EVI, and **Inclusive
> Multicast Ethernet Tag** routes is used to carry the VNI or VSID."
>
> Thanks.
> Jorge
>
>
>
>
>
> On 5/4/16, 8:34 PM, "EXT John E Drake" <jdrake@juniper.net> wrote:
>
> >Thomas and Jorge,
> >
> >Snipped, comments inline.
> >
> >Yours Irrespectively,
> >
> >John
> >
> >> >
> >> >draft-ietf-bess-evpn-overlay (see section 9) relies on the BGP
> >> >Encapsulation extended to encode the tunnel encap to use for BUM
> >> >traffic, but contrary to other E-VPN routes, relies on the Ethernet
> >> >Tag field of the NLRI to encode the VNI/VSID.
> >>
> >> [JORGE] This is certainly a leftover from an old version where the
> >> VNI/VSID was encoded in the ethernet tag for all the routes. The VNI
> >> should be encoded in the Label field in all the routes. This has to be corrected.
> >>
> >> In fact, section 5.1.3 says:
> >>
> >> 5.1.3 Constructing EVPN BGP Routes
> >>
> >> <snip>
> >>
> >> Accordingly, and
> >> specifically to support the option of locally assigned VNIs, the MPLS
> >> label field in the MAC Advertisement, Ethernet AD per EVI, and
> >> Inclusive Multicast Ethernet Tag routes is used to carry the VNI or
> >> VSID. For the balance of this memo, the MPLS label field will be
> >> referred to as the VNI/VSID field. The VNI/VSID field is used for
> >> both local and global VNIs/VSIDs, and for either case the entire 24-
> >> bit field is used to encode the VNI/VSID value.
> >>
> >> <snip>
> >
> >
> >[JD] For the IMET route the MPLS label field is carried in the PMSI attribute. I think we
> need to ask everyone whether they
> >used the Ethernet Tag or the PMSI attribute to carry the VNI
> >
> >
> >> >>
> >> >> There are minor things that could be improved in
> >> >> draft-ietf-bess-evpn-overlay wrt. consistency with
> >> >> draft-ietf-idr-tunnel-encaps :
> >> >>
> >> >> * since draft-ietf-idr-tunnel-encaps will deprecate RFC5512, it
> >> >> would be better that draft-ietf-bess-evpn-overlay refers to
> >> >> draft-ietf-idr-tunnel-encaps and not anymore to RFC5512.
> >>
> >> [JORGE] I agree, as long as draft-ietf-idr-tunnel-encaps keeps the
> >> encapsulation extended community. There are a few implementations
> >> using this community and it is enough when only the encapsulation type is needed.
> >
> >
> >[JD] I agree and the tunnel encaps draft does keep the EC
> >
> >
> >>
> >> >>
> >> >> * I think it would be better to avoid the explicit list of encap
> >> >> types in section 5.1.3, and rather refer to
> >> >> draft-ietf-idr-tunnel-encaps instead
> >>
> >> [JORGE] I agree.
> >
> >
> >[JD] According to IANA, it allocated the five tunnels types to the
> >overlay draft so I think we need to keep them
> >
> >
> >>
> >> >> * the following minor modification was proposed, but not yet incorporated:
> >> >>
> >> >> John Drake, 2015-11-13 (to BESS ML):
> >> >>> For the overlay draft, replace this text in section 5.1.3:
> >> >>>
> >> >>> "If the BGP Encapsulation extended community is not present,
> >> >>> then the default MPLS encapsulation or a statically configured
> >> >>> encapsulation is assumed."
> >> >>>
> >> >>> With the following:
> >> >>>
> >> >>> "Note that the MPLS encapsulation tunnel type is needed in
> >> >>> order to distinguish between an advertising node that only
> >> >>> supports non-MPLS encapsulations and one that supports MPLS and
> >> >>> non-MPLS encapsulations. An advertising node that only supports
> >> >>> MPLS encapsulation does not need to advertise any encapsulation
> >> >>> tunnel types; i.e., if the BGP Encapsulation extended community
> >> >>> is not present, then either MPLS encapsulation or a statically
> >> >>> configured encapsulation is assumed."
> >> >>
> >> >> I think this change is useful and should be incorporated, although
> >> >> skipping the last sentence would be wise if the full list of
> >> >> tunnel types is removed.
> >
> >
> >[JD] Fine with me either w/ or w/o the last sentence
> >
> >


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
--------------2664359F78BA3B94A7874F26-- From nobody Wed May 18 07:16:00 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC90312D1D9; Wed, 18 May 2016 07:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3HV4HtREdG3; Wed, 18 May 2016 07:15:52 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-eopbgr680096.outbound.protection.outlook.com [40.107.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A174C12D103; Wed, 18 May 2016 07:15:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ORrsNnfnZRfRekC4h/BbtFMHCkxkW6u+fwt4wPxp0fc=; b=faQ5lLCIX0PJLCrkEYuw6eq4w7PGdi2nkILtDgsacENX5q7G21BQpzDkjd+9YX/OFjsh2TMDoqtQiZzCWFVF20vZyglOCTdo0oMBL22FK8leFPnPgaS3gp91BNK6E9cpFT/Ke4sg7+bHDau7oPExgo8926ThTTTl8wfUu5IWWjo= Received: from SN1PR0501MB1709.namprd05.prod.outlook.com (10.163.130.155) by SN1PR0501MB1712.namprd05.prod.outlook.com (10.163.130.158) with Microsoft SMTP Server (TLS) id 15.1.501.7; Wed, 18 May 2016 14:15:51 +0000 Received: from SN1PR0501MB1709.namprd05.prod.outlook.com ([10.163.130.155]) by SN1PR0501MB1709.namprd05.prod.outlook.com ([10.163.130.155]) with mapi id 15.01.0492.020; Wed, 18 May 2016 14:15:51 +0000 From: John E Drake To: "EXT - thomas.morin@orange.com" , IDR , BESS , "draft-ietf-bess-evpn-overlay@tools.ietf.org" , "Ali Sajassi (sajassi)" , "Rabadan, Jorge (Nokia - US)" , "draft-ietf-idr-tunnel-encap@tools.ietf.org" Thread-Topic: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps Thread-Index: AQHRpi+6xGM0bynWeUeGN93K6stLXZ+pFtLwgAAZ14CAABtMwIAAAw6AgAD40oCAAALOkIAAmFwAgAAIznCAE6UwgIAAQX5Q Date: Wed, 18 May 2016 14:15:50 +0000 Message-ID: References: <5729F1C3.1030605@orange.com> <5729F7C5.6040604@orange.com> <52D35106-ED5E-4C95-9131-6EA4527370D5@alcatel-lucent.com> <012C176C-A8D6-45AA-BA69-616C0ED7E41E@alcatel-lucent.com> <420BA2D8D80A6727.2B2C290F-2299-40BB-B53B-CC36D2B5D826@mail.outlook.com> <1881_1462451514_572B3D3A_1881_7198_1_0vn90oitr7e881gh2sn8qm5f.1462451509961@email.android.com> <17029_1462484835_572BBF63_17029_2323_1_opi9hqsl9b9tani0t0skkcuq.1462484831251@email.android.com> <28175_1463566739_573C4192_28175_2444_1_613f729b-d12e-5c48-29a1-ff000c1184a1@orange.com> In-Reply-To: <28175_1463566739_573C4192_28175_2444_1_613f729b-d12e-5c48-29a1-ff000c1184a1@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.14] x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr,ExtAddr x-ms-office365-filtering-correlation-id: 5acafea8-e65b-4b83-0341-08d37f26ea90 x-microsoft-exchange-diagnostics: 1; SN1PR0501MB1712; 5:/c5PlWBVWnD7MW8T7To/gqjJJDtpEdohi58NKetAIfMzITCujo+xwQwNyXkfmP7kx9OKGIO3rn3Z4vt1piGdUmd9YoSyS4DglA5AvB/+hcBwreHOJnkfCwZTFpkAQgXH5bn6nNG2gfWIn7G1ELytZA==; 24:y/i7u8D0SetDwOLe5hzcMTfTDZiVrYylMTT7q6yHLYKgtx1qPdO8Cvs1x9RCmU5Gu76lZFjEBZZFWSAs8l66VMDn8cdxs6eWudM8gPr4Xcg=; 7:j398hJ3458CVCa8bSeCWZZ9cKY9/x3EOCd78JsP6/TgOil4Es99E5IC+t6UrNgfswxZXTBCR1SxpQNjRpBVNizMN53sxsV4bXeaZjpMaK+zlYUoXb+6LjNpxLwSh6LGSa/SVeaH7xHGdfu+4JrnYWNGZP8ym2XtGlBOgrFsa6N2c7L9Z7z2j5ogU/iY02y5Q x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB1712; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:SN1PR0501MB1712; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1712; x-forefront-prvs: 0946DC87A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(13464003)(51914003)(24454002)(377454003)(377424004)(3660700001)(76576001)(3280700002)(106116001)(10400500002)(99286002)(790700001)(6116002)(102836003)(586003)(19617315012)(33656002)(92566002)(66066001)(76176999)(54356999)(2950100001)(5002640100001)(2900100001)(50986999)(11100500001)(5004730100002)(19300405004)(4001150100001)(16236675004)(5001770100001)(77096005)(9686002)(189998001)(107886002)(5890100001)(2501003)(2906002)(15975445007)(19625215002)(19580405001)(19580395003)(81166006)(74316001)(8676002)(122556002)(8936002)(93886004)(86362001)(1220700001)(5003600100002)(87936001)(230783001)(5008740100001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB1712; H:SN1PR0501MB1709.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0501MB17090A6F0AC5D3D447E21C28C7490SN1PR0501MB1709_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 18 May 2016 14:15:50.8913 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB1712 Archived-At: Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 14:15:57 -0000 --_000_SN1PR0501MB17090A6F0AC5D3D447E21C28C7490SN1PR0501MB1709_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhvbWFzLA0KDQpJIHNwb2tlIHdpdGggQWxpIGFuZCBoZSB3aWxsIHJlZmVyZW5jZSB0aGUgdHVu bmVsIGVuY2Fwc3VsYXRpb24gZHJhZnQgcmF0aGVyIHRoYW4gUkZDIDU1MTIgYnV0IG1ha2UgaXQg SW5mb3JtYXRpdmUuICBJIHRoaW5rIHRoaXMgaXMgaW4gdGhlIHNwaXJpdCBvZiB3aGF0IHlvdSBw cm9wb3NlZCBpbiB5b3VyIGVtYWlsLCBiZWxvdy4NCg0KWW91cnMgSXJyZXNwZWN0aXZlbHksDQoN CkpvaG4NCg0KRnJvbTogdGhvbWFzLm1vcmluQG9yYW5nZS5jb20gW21haWx0bzp0aG9tYXMubW9y aW5Ab3JhbmdlLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgTWF5IDE4LCAyMDE2IDY6MTkgQU0NClRv OiBKb2huIEUgRHJha2U7IElEUjsgQkVTUzsgZHJhZnQtaWV0Zi1iZXNzLWV2cG4tb3ZlcmxheUB0 b29scy5pZXRmLm9yZzsgQWxpIFNhamFzc2kgKHNhamFzc2kpOyBSYWJhZGFuLCBKb3JnZSAoTm9r aWEgLSBVUyk7IGRyYWZ0LWlldGYtaWRyLXR1bm5lbC1lbmNhcEB0b29scy5pZXRmLm9yZw0KU3Vi amVjdDogUmU6IFtJZHJdIGRyYWZ0LWlldGYtYmVzcy1ldnBuLW92ZXJsYXkgdnMuIGRyYWZ0LWll dGYtaWRyLXR1bm5lbC1lbmNhcHMNCg0KSGkgSm9obiwNCg0KSm9obi4NCg0KV2hlbiB0aGUgdHVu bmVsIGVuY2FwcyBkcmFmdCB3YXMgZmlyc3QgcHVibGlzaGVkIGl0IGRpZCBub3QgY2FycnkgZm9y d2FyZCB0aGUgUkZDIDU1MTIgZXh0ZW5kZWQgY29tbXVuaXR5IGFuZCBpdCBkaWQgbm90IHByb3Bv c2UgdG8gb2Jzb2xldGUgUkZDIDU1MTIuICBUaGVyZSB3YXMgZGlzY3Vzc2lvbiBvZiB1c2luZyB0 aGUgYXR0cmlidXRlIGRlZmluZWQgaW4gdGhlIHR1bm5lbCBlbmNhcHMgZHJhZnQgaW5zdGVhZCBv ZiB0aGUgZXh0ZW5kZWQgY29tbXVuaXR5IGFuZCB3ZSBkZWNpZGVkIHRvIGNvbnRpbnVlIHRvIHVz ZSB0aGUgZXh0ZW5kZWQgY29tbXVuaXR5LiAgU28sIGluIHRoYXQgc2Vuc2Ugd2UgYXJlIG1pc2Fs aWduZWQgd2l0aCB0aGUgdHVubmVsIGVuY2FwcyBkcmFmdC4NCg0KDQpBcyB5b3UgY29uZmlybSBi ZWxvdywgdGhlIGxhc3Qgc2VudGVuY2UgaXMgb25seSB0cnVlIGluIHRoZSBwYXN0IHRlbnNlLg0K DQoNClN1YnNlcXVlbnRseSwgaG93ZXZlciwgdGhlIHR1bm5lbCBlbmNhcHMgZHJhZnQgZGVjaWRl ZCB0byBjYXJyeSBmb3J3YXJkIHRoZSBleHRlbmRlZCBjb21tdW5pdHkgYW5kIHRvIG9ic29sZXRl IFJGQyA1NTEyLCBzbyB3ZSB3ZXJlIGVmZmVjdGl2ZWx5IGNvdmVyZWQgYnkgYSBncmFuZGZhdGhl ciBjbGF1c2UuDQoNClllcywgcHJlY2lzZWx5OiBnaXZlbiB0aGUgY29udGVudCBvZiB0aGUgdHdv IGRyYWZ0cywgdGhlcmUgaXMgbm8gbWlzYWxpZ25tZW50IGFueW1vcmUuDQoNCg0KR2l2ZW4gdGhl IG92ZXJsYXkgZHJhZnTigJlzIHRhcmRpbmVzcywgSSBkb27igJl0IHRoaW5rIHRoYXTigJlzIGFj Y2VwdGFibGUgYW5kIHdvdWxkIHByZWZlciB0byBjb250aW51ZSB0byByZWZlciB0byBSRkMgNTUx Mi4NCg0KSSBkbyBub3QgdGhpbmsgdGhhdCB0aGUgYWRkaXRpb25hbCBwdWJsaWNhdGlvbiBkZWxh eSBpcyBhIHNvdW5kIHJhdGlvbmFsZSBmb3Igbm9ybWF0aXZlbHkgcmVmZXIgdG8gYSBzcGVjIHRo YXQgaXMga25vd24gdG8gYmVjb21lIG9ic29sZXRlLg0KSWYgaXQgaGVscHMsIHRoZSBkcmFmdCBj YW4ga2VlcCBhbiBpbmZvcm1hdGl2ZSByZWYgdG8gUkZDNTUxMiBhbmQgcmVtaW5kIHRoYXQgaXQg ZG9lcyBub3QgcmVseSBvbiBhbnl0aGluZyBzcGVjaWZpY2FsbHkgaW50cm9kdWNlZCBieSBkcmFm dC1pZXRmLWlkci10dW5uZWwtZW5jYXBzIGFuZCBub3QgZXhpc3RpbmcgYWxyZWFkeSBpbiBSRkM1 NTEyLg0KDQotVGhvbWFzDQoNCg0KMjAxNi0wNS0wNiwgSm9obiBFIERyYWtlOg0KDQpIb3dldmVy LCBldmVuIHRob3VnaCBJIGFncmVlZCB5ZXN0ZXJkYXkgdG8gcmVmZXIgdG8gdGhlIHR1bm5lbCBl bmNhcHMgZHJhZnQgaW5zdGVhZCBvZiBSRkMgNTUxMiB3ZSBoYXZlIGFuIGlzc3VlIHdpdGggZG9p bmcgdGhpcywgdml6LCB0aGUgb3ZlcmxheSBkcmFmdCBtYWtlcyBhIG5vcm1hdGl2ZSByZWZlcmVu Y2UgdG8gUkZDIDU1MTIuICBJZiB3ZSBjaGFuZ2UgdGhlIG5vcm1hdGl2ZSByZWZlcmVuY2UgdG8g dGhlIHR1bm5lbCBlbmNhcHMgZHJhZnQgd2UgY2Fubm90IHB1Ymxpc2ggdGhlIG92ZXJsYXkgZHJh ZnQgdW50aWwgYWZ0ZXIgdGhlIHR1bm5lbCBlbmNhcHMgZHJhZnQgaGFzIGJlZW4gcHVibGlzaGVk Lg0KDQpHaXZlbiB0aGUgb3ZlcmxheSBkcmFmdOKAmXMgdGFyZGluZXNzLCBJIGRvbuKAmXQgdGhp bmsgdGhhdOKAmXMgYWNjZXB0YWJsZSBhbmQgd291bGQgcHJlZmVyIHRvIGNvbnRpbnVlIHRvIHJl ZmVyIHRvIFJGQyA1NTEyLg0KDQpZb3VycyBJcnJlc3BlY3RpdmVseSwNCg0KSm9obg0KDQpGcm9t OiB0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbTxtYWlsdG86dGhvbWFzLm1vcmluQG9yYW5nZS5jb20+ IFttYWlsdG86dGhvbWFzLm1vcmluQG9yYW5nZS5jb21dDQpTZW50OiBUaHVyc2RheSwgTWF5IDA1 LCAyMDE2IDU6NDcgUE0NClRvOiBJRFI7IEJFU1M7IGRyYWZ0LWlldGYtYmVzcy1ldnBuLW92ZXJs YXlAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtYmVzcy1ldnBuLW92ZXJsYXlAdG9v bHMuaWV0Zi5vcmc+OyBBbGkgU2FqYXNzaSAoc2FqYXNzaSk7IFJhYmFkYW4sIEpvcmdlIChOb2tp YSAtIFVTKTsgZHJhZnQtaWV0Zi1pZHItdHVubmVsLWVuY2FwQHRvb2xzLmlldGYub3JnPG1haWx0 bzpkcmFmdC1pZXRmLWlkci10dW5uZWwtZW5jYXBAdG9vbHMuaWV0Zi5vcmc+OyBKb2huIEUgRHJh a2UNClN1YmplY3Q6IFJFOiBbSWRyXSBkcmFmdC1pZXRmLWJlc3MtZXZwbi1vdmVybGF5IHZzLiBk cmFmdC1pZXRmLWlkci10dW5uZWwtZW5jYXBzDQoNCkhpIEpvaG4sDQoNCkkgaGF2ZSBhIGhhcmQg dGltZSByZWNvbmNpbGlhdGluZyB0aGUgZmFjdCB0aGF0IHllc3RlcmRheSB5b3Ugd2VyZSBmaW5l IHdpdGggaGF2aW5nIGJlc3MtZXZwbi1vdmVybGF5IHJlZmVyIHRvIGlkci10dW5uZWwtZW5jYXAg aW5zdGVhZCBvZiBSRkM1NTEyLCB3aXRoIHRoZSBmYWN0IHRoYXQgeW91IGNvbnNpZGVyIChiZWxv dykgdGhlIHR3byBkb2NzICJub3QgYWxpZ25lZCIgZm9yIHVuaWNhc3QuDQoNCkNhbiB5b3UgYmUg bW9yZSBleHBsaWNpdCBpbiB3aGVyZSB0aGUgIm1pc2FsaWdubWVudCIgbGllcz8NCg0KLVRob21h cw0KDQotLS0tIEpvaG4gRSBEcmFrZSBhIMOpY3JpdCAtLS0tDQpUaG9tYXMsDQoNClRoZSBvdmVy bGF5IGRyYWZ0IHByZWNlZGVkIHRoZSB0dW5uZWwgZW5jYXBzIGRyYWZ0IGFuZCBpdCB3YXMgZGVz aWduZWQgdG8gaGFuZGxlIGEgdmVyeSBzcGVjaWZpYyBwcm9ibGVtLCBtYXJyeWluZyB0aGUgRVZQ TiBjb250cm9sIHBsYW5lIHRvIHRoZSBWWExBTiBkYXRhIHBsYW5lIGRyYWZ0IGFuZCBtb2R1bG8g dGhlIGNvcnJlY3Rpb24gdG8gc2VjdGlvbiA5IGl0IGlzIGludGVybmFsbHkgY29uc2lzdGVudC4N Cg0KVGhlIHR1bm5lbCBlbmNhcHMgZHJhZnQgc29sdmVzIGEgbW9yZSBnZW5lcmFsIHByb2JsZW0g YW5kIHRoZSBXRyBkZWNpZGVkIGEgbG9uZyB0aW1lIGFnbyB0aGF0IHRoZSBvdmVybGF5IGRyYWZ0 IHdhcyBub3QgZ29pbmcgdG8gYmUgdXBkYXRlZCB0byB1c2UgdGhlIG1lY2hhbmlzbXMgaXQgZGV0 YWlscyBmb3IgdW5pY2FzdCwgc28gdGhlIG92ZXJsYXkgZHJhZnQgaXMgYWxyZWFkeSBleHBsaWNp dGx5IG5vdCBpbiBhbGlnbm1lbnQgd2l0aCBpdC4NCg0KVGhpcywgcGx1cyB0aGUgZmFjdCB0aGF0 IHRoZSB0dW5uZWwgZW5jYXBzIGRyYWZ0IGV4cGxpY2l0bHkgcHV0cyB0aGUgUE1TSSBvdXQgb2Yg c2NvcGUsIGxlYWRzIG1lIHRvIHRoZSBjb25jbHVzaW9uIHRoYXQgdGhlIG92ZXJsYXkgZHJhZnQg c2hvdWxkIG5vdCBiZSB0d2Vha2VkIHRvIGJlIGluIGFsaWdubWVudCB3aXRoIGEgZnV0dXJlIHNv bHV0aW9uIGZvciBlbmNvZGluZyBWTklzIGZvciBtdWx0aWNhc3QuDQoNCllvdXJzIElycmVzcGVj dGl2ZWx5LA0KDQpKb2huDQoNCkZyb206IHRob21hcy5tb3JpbkBvcmFuZ2UuY29tPG1haWx0bzp0 aG9tYXMubW9yaW5Ab3JhbmdlLmNvbT4gW21haWx0bzp0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbV0N ClNlbnQ6IFRodXJzZGF5LCBNYXkgMDUsIDIwMTYgODozMiBBTQ0KVG86IEpvaG4gRSBEcmFrZTsg SURSOyBCRVNTOyBkcmFmdC1pZXRmLWJlc3MtZXZwbi1vdmVybGF5QHRvb2xzLmlldGYub3JnPG1h aWx0bzpkcmFmdC1pZXRmLWJlc3MtZXZwbi1vdmVybGF5QHRvb2xzLmlldGYub3JnPjsgQWxpIFNh amFzc2kgKHNhamFzc2kpOyBSYWJhZGFuLCBKb3JnZSAoTm9raWEgLSBVUyk7IGRyYWZ0LWlldGYt aWRyLXR1bm5lbC1lbmNhcEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1pZHItdHVu bmVsLWVuY2FwQHRvb2xzLmlldGYub3JnPg0KU3ViamVjdDogUkU6IFtJZHJdIGRyYWZ0LWlldGYt YmVzcy1ldnBuLW92ZXJsYXkgdnMuIGRyYWZ0LWlldGYtaWRyLXR1bm5lbC1lbmNhcHMNCg0KVGhh bmtzIGZvciB0aGUgY2xhcmlmaWNhdGlvbiBvbiB0aGUgaW50ZW50IGFyb3VuZCBkcmFmdC1pZXRm LWJlc3MtZXZwbi1vdmVybGF5LiBUaGVuIGluZGVlZCBzZWN0aW9uIDkgbmVlZHMgc29tZSB0aWR5 aW5nIHVwLg0KDQpUaGUgaXNzdWUgdGhhdCBJIHRoaW5rIHJlbWFpbiBpcyB0aGF0IGl0IHdvdWxk IGJlIG11Y2ggY2xlYW5lciB0byBleHBsYWluIGhvdyB0byB1c2UgUE1TSSB3aXRoIG92ZXJsYXkg ZW5jYXBzIGluIGEgc3BlYyBub3Qgc3BlY2lmaWMgdG8gRS1WUE4gYW5kIGluIGEgd2F5IG1vcmUg Y29uc2lzdGVudCB0byB3aGF0IGlzIGRvbmUgZm9yIHVuaWNhc3QuDQoNCkl0IHNlZW1zIGlmIGNv dXJzZSB0aGF0IGRyYWZ0LWlldGYtaWRyLXR1bm5lbC1lbmNhcCBzaG91bGQgYmUgdGhlIHBsYWNl LCBidXQgdGhhdCBkb2N1bWVudCBjdXJyZW50bHkgZXhwbGljaXRseSBtYWtlcyBQTVNJcyBvdXQg b2Ygc2NvcGUuDQoNClNob3VsZG4ndCB0aGlzIHBhcnQgb2YgZHJhZnQtaWV0Zi1pZHItdHVubmVs LWVuY2FwIGJlIHJldmlzaXRlZCA/DQoNCi1UaG9tYXMNCg0KDQotLS0tIFJhYmFkYW4sIEpvcmdl IChOb2tpYSAtIFVTKSBhIMOpY3JpdCAtLS0tDQpGdWxseSBhZ3JlZSBKb2huLiBUaGF0J3Mgd2hh dCBJIG1lYW50LCBzb3JyeSBpZiBJIGRpZG4ndCBtYWtlIG15c2VsZiBjbGVhci4gU2VjdGlvbiA5 IG5lZWRzIGNsZWFuIHVwLCB5ZXMuDQpUaGFua3MsDQpKb3JnZQ0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KRnJvbTogRVhUIEpvaG4gRSBEcmFrZSA8amRyYWtlQGp1bmlwZXIubmV0 PG1haWx0bzpqZHJha2VAanVuaXBlci5uZXQ+Pg0KU2VudDogV2VkbmVzZGF5LCBNYXkgNCwgMjAx NiAyMzozNA0KU3ViamVjdDogUkU6IFtJZHJdIGRyYWZ0LWlldGYtYmVzcy1ldnBuLW92ZXJsYXkg dnMuIGRyYWZ0LWlldGYtaWRyLXR1bm5lbC1lbmNhcHMNClRvOiBJRFIgPGlkckBpZXRmLm9yZzxt YWlsdG86aWRyQGlldGYub3JnPj4sIEFsaSBTYWphc3NpIChzYWphc3NpKSA8c2FqYXNzaUBjaXNj by5jb208bWFpbHRvOnNhamFzc2lAY2lzY28uY29tPj4sIFJhYmFkYW4sIEpvcmdlIChOb2tpYSAt IFVTKSA8am9yZ2UucmFiYWRhbkBhbGNhdGVsLWx1Y2VudC5jb208bWFpbHRvOmpvcmdlLnJhYmFk YW5AYWxjYXRlbC1sdWNlbnQuY29tPj4sIEJFU1MgPGJlc3NAaWV0Zi5vcmc8bWFpbHRvOmJlc3NA aWV0Zi5vcmc+PiwgPGRyYWZ0LWlldGYtYmVzcy1ldnBuLW92ZXJsYXlAdG9vbHMuaWV0Zi5vcmc8 bWFpbHRvOmRyYWZ0LWlldGYtYmVzcy1ldnBuLW92ZXJsYXlAdG9vbHMuaWV0Zi5vcmc+PiwgRVhU IC0gdGhvbWFzLm1vcmluQG9yYW5nZS5jb208bWFpbHRvOnRob21hcy5tb3JpbkBvcmFuZ2UuY29t PiA8dGhvbWFzLm1vcmluQG9yYW5nZS5jb208bWFpbHRvOnRob21hcy5tb3JpbkBvcmFuZ2UuY29t Pj4NCg0KDQpKb3JnZSwNCg0KV2UgcHV0IHRoZSBWTkkgdmFsdWUgaW4gdGhlIE1QTFMgbGFiZWwg ZmllbGQgb2YgdGhlIFBNU0kgYXR0cmlidXRlIGZvciBhbGwgc2VydmljZSB0eXBlcywgYW5kIHdl IHB1dCBhIHZhbHVlIGluIHRoZSBFdGhlcm5ldCBUYWcgZmllbGQgZm9sbG93aW5nIHRoZSBydWxl cyBmb3IgZWFjaCBzZXJ2aWNlIHR5cGUgYXMgZGVzY3JpYmVkIGluIDUuMS4zIChodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1iZXNzLWV2cG4tb3ZlcmxheS0wMiNzZWN0aW9u LTUuMS4zKS4NCg0KWW91J3JlIHJpZ2h0IHRoYXQgd2UgbmVlZCB0byBjbGVhbiB1cCBzZWN0aW9u IDkuDQoNCllvdXJzIElycmVzcGVjdGl2ZWx5LA0KDQpKb2huDQoNCj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gRnJvbTogUmFiYWRhbiwgSm9yZ2UgKE5va2lhIC0gVVMpIFttYWlsdG86 am9yZ2UucmFiYWRhbkBub2tpYS5jb21dDQo+IFNlbnQ6IFdlZG5lc2RheSwgTWF5IDA0LCAyMDE2 IDM6NTMgUE0NCj4gVG86IEpvaG4gRSBEcmFrZTsgRVhUIC0gdGhvbWFzLm1vcmluQG9yYW5nZS5j b208bWFpbHRvOnRob21hcy5tb3JpbkBvcmFuZ2UuY29tPjsgQkVTUzsgSURSOyBkcmFmdC1pZXRm LWJlc3MtZXZwbi0NCj4gb3ZlcmxheUB0b29scy5pZXRmLm9yZzxtYWlsdG86b3ZlcmxheUB0b29s cy5pZXRmLm9yZz47IEFsaSBTYWphc3NpIChzYWphc3NpKQ0KPiBTdWJqZWN0OiBSZTogW0lkcl0g ZHJhZnQtaWV0Zi1iZXNzLWV2cG4tb3ZlcmxheSB2cy4gZHJhZnQtaWV0Zi1pZHItdHVubmVsLWVu Y2Fwcw0KPg0KPiBIaSBKb2huLA0KPg0KPiBBYm91dCB0aGlzOg0KPg0KPiBbSkRdIEZvciB0aGUg SU1FVCByb3V0ZSB0aGUgTVBMUyBsYWJlbCBmaWVsZCBpcyBjYXJyaWVkIGluIHRoZSBQTVNJIGF0 dHJpYnV0ZS4gSSB0aGluayB3ZSBuZWVkDQo+IHRvIGFzayBldmVyeW9uZSB3aGV0aGVyIHRoZXkg dXNlZCB0aGUgRXRoZXJuZXQgVGFnIG9yIHRoZSBQTVNJIGF0dHJpYnV0ZSB0byBjYXJyeSB0aGUg Vk5JDQo+DQo+DQo+IEluIGNhc2UgaXQgaGVscHMsIEnigJl2ZSBzZWVuIGEgZmV3IGltcGxlbWVu dGF0aW9ucyBydW5uaW5nIGFuZCB0aGV5IGFsbCBlbmNvZGUgdGhlIFZOSSBpbiB0aGUNCj4gTVBM UyBsYWJlbCBmaWVsZCBpbiB0aGUgUFRBLiBBbmQgYSBjb3VwbGUgb2YgdGhlbSwgZW5jb2RlIHRo ZSBWTkkgaW4gdGhlIGV0aGVybmV0LXRhZywgaW4NCj4gYWRkaXRpb24gdG8gdGhlIE1QTFMgbGFi ZWwgaW4gdGhlIFBUQS4gSW4gYW55IGNhc2UsIEkgdGhpbmsgc2VjdGlvbiA5IGNvbnRyYWRpY3Rz IHNlY3Rpb24gNS4xLjMNCj4gYW5kIHNob3VsZCBiZSBjbGFyaWZpZWQuDQo+DQo+ICI1LjEuMyBD b25zdHJ1Y3RpbmcgRVZQTiBCR1AgUm91dGVzDQo+IDxzbmlwPg0KPiB0aGUgTVBMUyBsYWJlbCBm aWVsZCBpbiB0aGUgTUFDIEFkdmVydGlzZW1lbnQsIEV0aGVybmV0IEFEIHBlciBFVkksIGFuZCAq KkluY2x1c2l2ZQ0KPiBNdWx0aWNhc3QgRXRoZXJuZXQgVGFnKiogcm91dGVzIGlzIHVzZWQgdG8g Y2FycnkgdGhlIFZOSSBvciBWU0lELiINCj4NCj4gVGhhbmtzLg0KPiBKb3JnZQ0KPg0KPg0KPg0K Pg0KPg0KPiBPbiA1LzQvMTYsIDg6MzQgUE0sICJFWFQgSm9obiBFIERyYWtlIiA8amRyYWtlQGp1 bmlwZXIubmV0PG1haWx0bzpqZHJha2VAanVuaXBlci5uZXQ+PiB3cm90ZToNCj4NCj4gPlRob21h cyBhbmQgSm9yZ2UsDQo+ID4NCj4gPlNuaXBwZWQsIGNvbW1lbnRzIGlubGluZS4NCj4gPg0KPiA+ WW91cnMgSXJyZXNwZWN0aXZlbHksDQo+ID4NCj4gPkpvaG4NCj4gPg0KPiA+PiA+DQo+ID4+ID5k cmFmdC1pZXRmLWJlc3MtZXZwbi1vdmVybGF5IChzZWUgc2VjdGlvbiA5KSByZWxpZXMgb24gdGhl IEJHUA0KPiA+PiA+RW5jYXBzdWxhdGlvbiBleHRlbmRlZCB0byBlbmNvZGUgdGhlIHR1bm5lbCBl bmNhcCB0byB1c2UgZm9yIEJVTQ0KPiA+PiA+dHJhZmZpYywgYnV0IGNvbnRyYXJ5IHRvIG90aGVy IEUtVlBOIHJvdXRlcywgcmVsaWVzIG9uIHRoZSBFdGhlcm5ldA0KPiA+PiA+VGFnIGZpZWxkIG9m IHRoZSBOTFJJIHRvIGVuY29kZSB0aGUgVk5JL1ZTSUQuDQo+ID4+DQo+ID4+IFtKT1JHRV0gVGhp cyBpcyBjZXJ0YWlubHkgYSBsZWZ0b3ZlciBmcm9tIGFuIG9sZCB2ZXJzaW9uIHdoZXJlIHRoZQ0K PiA+PiBWTkkvVlNJRCB3YXMgZW5jb2RlZCBpbiB0aGUgZXRoZXJuZXQgdGFnIGZvciBhbGwgdGhl IHJvdXRlcy4gVGhlIFZOSQ0KPiA+PiBzaG91bGQgYmUgZW5jb2RlZCBpbiB0aGUgTGFiZWwgZmll bGQgaW4gYWxsIHRoZSByb3V0ZXMuIFRoaXMgaGFzIHRvIGJlIGNvcnJlY3RlZC4NCj4gPj4NCj4g Pj4gSW4gZmFjdCwgc2VjdGlvbiA1LjEuMyBzYXlzOg0KPiA+Pg0KPiA+PiA1LjEuMyBDb25zdHJ1 Y3RpbmcgRVZQTiBCR1AgUm91dGVzDQo+ID4+DQo+ID4+IDxzbmlwPg0KPiA+Pg0KPiA+PiBBY2Nv cmRpbmdseSwgYW5kDQo+ID4+IHNwZWNpZmljYWxseSB0byBzdXBwb3J0IHRoZSBvcHRpb24gb2Yg bG9jYWxseSBhc3NpZ25lZCBWTklzLCB0aGUgTVBMUw0KPiA+PiBsYWJlbCBmaWVsZCBpbiB0aGUg TUFDIEFkdmVydGlzZW1lbnQsIEV0aGVybmV0IEFEIHBlciBFVkksIGFuZA0KPiA+PiBJbmNsdXNp dmUgTXVsdGljYXN0IEV0aGVybmV0IFRhZyByb3V0ZXMgaXMgdXNlZCB0byBjYXJyeSB0aGUgVk5J IG9yDQo+ID4+IFZTSUQuIEZvciB0aGUgYmFsYW5jZSBvZiB0aGlzIG1lbW8sIHRoZSBNUExTIGxh YmVsIGZpZWxkIHdpbGwgYmUNCj4gPj4gcmVmZXJyZWQgdG8gYXMgdGhlIFZOSS9WU0lEIGZpZWxk LiBUaGUgVk5JL1ZTSUQgZmllbGQgaXMgdXNlZCBmb3INCj4gPj4gYm90aCBsb2NhbCBhbmQgZ2xv YmFsIFZOSXMvVlNJRHMsIGFuZCBmb3IgZWl0aGVyIGNhc2UgdGhlIGVudGlyZSAyNC0NCj4gPj4g Yml0IGZpZWxkIGlzIHVzZWQgdG8gZW5jb2RlIHRoZSBWTkkvVlNJRCB2YWx1ZS4NCj4gPj4NCj4g Pj4gPHNuaXA+DQo+ID4NCj4gPg0KPiA+W0pEXSBGb3IgdGhlIElNRVQgcm91dGUgdGhlIE1QTFMg bGFiZWwgZmllbGQgaXMgY2FycmllZCBpbiB0aGUgUE1TSSBhdHRyaWJ1dGUuIEkgdGhpbmsgd2UN Cj4gbmVlZCB0byBhc2sgZXZlcnlvbmUgd2hldGhlciB0aGV5DQo+ID51c2VkIHRoZSBFdGhlcm5l dCBUYWcgb3IgdGhlIFBNU0kgYXR0cmlidXRlIHRvIGNhcnJ5IHRoZSBWTkkNCj4gPg0KPiA+DQo+ ID4+ID4+DQo+ID4+ID4+IFRoZXJlIGFyZSBtaW5vciB0aGluZ3MgdGhhdCBjb3VsZCBiZSBpbXBy b3ZlZCBpbg0KPiA+PiA+PiBkcmFmdC1pZXRmLWJlc3MtZXZwbi1vdmVybGF5IHdydC4gY29uc2lz dGVuY3kgd2l0aA0KPiA+PiA+PiBkcmFmdC1pZXRmLWlkci10dW5uZWwtZW5jYXBzIDoNCj4gPj4g Pj4NCj4gPj4gPj4gKiBzaW5jZSBkcmFmdC1pZXRmLWlkci10dW5uZWwtZW5jYXBzIHdpbGwgZGVw cmVjYXRlIFJGQzU1MTIsIGl0DQo+ID4+ID4+IHdvdWxkIGJlIGJldHRlciB0aGF0IGRyYWZ0LWll dGYtYmVzcy1ldnBuLW92ZXJsYXkgcmVmZXJzIHRvDQo+ID4+ID4+IGRyYWZ0LWlldGYtaWRyLXR1 bm5lbC1lbmNhcHMgYW5kIG5vdCBhbnltb3JlIHRvIFJGQzU1MTIuDQo+ID4+DQo+ID4+IFtKT1JH RV0gSSBhZ3JlZSwgYXMgbG9uZyBhcyBkcmFmdC1pZXRmLWlkci10dW5uZWwtZW5jYXBzIGtlZXBz IHRoZQ0KPiA+PiBlbmNhcHN1bGF0aW9uIGV4dGVuZGVkIGNvbW11bml0eS4gVGhlcmUgYXJlIGEg ZmV3IGltcGxlbWVudGF0aW9ucw0KPiA+PiB1c2luZyB0aGlzIGNvbW11bml0eSBhbmQgaXQgaXMg ZW5vdWdoIHdoZW4gb25seSB0aGUgZW5jYXBzdWxhdGlvbiB0eXBlIGlzIG5lZWRlZC4NCj4gPg0K PiA+DQo+ID5bSkRdIEkgYWdyZWUgYW5kIHRoZSB0dW5uZWwgZW5jYXBzIGRyYWZ0IGRvZXMga2Vl cCB0aGUgRUMNCj4gPg0KPiA+DQo+ID4+DQo+ID4+ID4+DQo+ID4+ID4+ICogSSB0aGluayBpdCB3 b3VsZCBiZSBiZXR0ZXIgdG8gYXZvaWQgdGhlIGV4cGxpY2l0IGxpc3Qgb2YgZW5jYXANCj4gPj4g Pj4gdHlwZXMgaW4gc2VjdGlvbiA1LjEuMywgYW5kIHJhdGhlciByZWZlciB0bw0KPiA+PiA+PiBk cmFmdC1pZXRmLWlkci10dW5uZWwtZW5jYXBzIGluc3RlYWQNCj4gPj4NCj4gPj4gW0pPUkdFXSBJ IGFncmVlLg0KPiA+DQo+ID4NCj4gPltKRF0gQWNjb3JkaW5nIHRvIElBTkEsIGl0IGFsbG9jYXRl ZCB0aGUgZml2ZSB0dW5uZWxzIHR5cGVzIHRvIHRoZQ0KPiA+b3ZlcmxheSBkcmFmdCBzbyBJIHRo aW5rIHdlIG5lZWQgdG8ga2VlcCB0aGVtDQo+ID4NCj4gPg0KPiA+Pg0KPiA+PiA+PiAqIHRoZSBm b2xsb3dpbmcgbWlub3IgbW9kaWZpY2F0aW9uIHdhcyBwcm9wb3NlZCwgYnV0IG5vdCB5ZXQgaW5j b3Jwb3JhdGVkOg0KPiA+PiA+Pg0KPiA+PiA+PiBKb2huIERyYWtlLCAyMDE1LTExLTEzICh0byBC RVNTIE1MKToNCj4gPj4gPj4+IEZvciB0aGUgb3ZlcmxheSBkcmFmdCwgcmVwbGFjZSB0aGlzIHRl eHQgaW4gc2VjdGlvbiA1LjEuMzoNCj4gPj4gPj4+DQo+ID4+ID4+PiAiSWYgdGhlIEJHUCBFbmNh cHN1bGF0aW9uIGV4dGVuZGVkIGNvbW11bml0eSBpcyBub3QgcHJlc2VudCwNCj4gPj4gPj4+IHRo ZW4gdGhlIGRlZmF1bHQgTVBMUyBlbmNhcHN1bGF0aW9uIG9yIGEgc3RhdGljYWxseSBjb25maWd1 cmVkDQo+ID4+ID4+PiBlbmNhcHN1bGF0aW9uIGlzIGFzc3VtZWQuIg0KPiA+PiA+Pj4NCj4gPj4g Pj4+IFdpdGggdGhlIGZvbGxvd2luZzoNCj4gPj4gPj4+DQo+ID4+ID4+PiAiTm90ZSB0aGF0IHRo ZSBNUExTIGVuY2Fwc3VsYXRpb24gdHVubmVsIHR5cGUgaXMgbmVlZGVkIGluDQo+ID4+ID4+PiBv cmRlciB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuIGFuIGFkdmVydGlzaW5nIG5vZGUgdGhhdCBvbmx5 DQo+ID4+ID4+PiBzdXBwb3J0cyBub24tTVBMUyBlbmNhcHN1bGF0aW9ucyBhbmQgb25lIHRoYXQg c3VwcG9ydHMgTVBMUyBhbmQNCj4gPj4gPj4+IG5vbi1NUExTIGVuY2Fwc3VsYXRpb25zLiBBbiBh ZHZlcnRpc2luZyBub2RlIHRoYXQgb25seSBzdXBwb3J0cw0KPiA+PiA+Pj4gTVBMUyBlbmNhcHN1 bGF0aW9uIGRvZXMgbm90IG5lZWQgdG8gYWR2ZXJ0aXNlIGFueSBlbmNhcHN1bGF0aW9uDQo+ID4+ ID4+PiB0dW5uZWwgdHlwZXM7IGkuZS4sIGlmIHRoZSBCR1AgRW5jYXBzdWxhdGlvbiBleHRlbmRl ZCBjb21tdW5pdHkNCj4gPj4gPj4+IGlzIG5vdCBwcmVzZW50LCB0aGVuIGVpdGhlciBNUExTIGVu Y2Fwc3VsYXRpb24gb3IgYSBzdGF0aWNhbGx5DQo+ID4+ID4+PiBjb25maWd1cmVkIGVuY2Fwc3Vs YXRpb24gaXMgYXNzdW1lZC4iDQo+ID4+ID4+DQo+ID4+ID4+IEkgdGhpbmsgdGhpcyBjaGFuZ2Ug aXMgdXNlZnVsIGFuZCBzaG91bGQgYmUgaW5jb3Jwb3JhdGVkLCBhbHRob3VnaA0KPiA+PiA+PiBz a2lwcGluZyB0aGUgbGFzdCBzZW50ZW5jZSB3b3VsZCBiZSB3aXNlIGlmIHRoZSBmdWxsIGxpc3Qg b2YNCj4gPj4gPj4gdHVubmVsIHR5cGVzIGlzIHJlbW92ZWQuDQo+ID4NCj4gPg0KPiA+W0pEXSBG aW5lIHdpdGggbWUgZWl0aGVyIHcvIG9yIHcvbyB0aGUgbGFzdCBzZW50ZW5jZQ0KPiA+DQo+ID4N Cg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQoNCg0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2 ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVn aWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCg0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBv dSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2Ug cGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUg ZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0 cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCg0KT3JhbmdlIGRlY2xp bmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9y bWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQoNCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNo bWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24g dGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCg0KdGhleSBzaG91bGQgbm90IGJlIGRpc3Ry aWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQoNCklmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KDQpBcyBlbWFp bHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0 IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQoNClRoYW5rIHlvdS4N Cg== --_000_SN1PR0501MB17090A6F0AC5D3D447E21C28C7490SN1PR0501MB1709_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsN Cgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1u YW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xh czt9DQpwLm1zb2NocGRlZmF1bHQsIGxpLm1zb2NocGRlZmF1bHQsIGRpdi5tc29jaHBkZWZhdWx0 DQoJe21zby1zdHlsZS1uYW1lOm1zb2NocGRlZmF1bHQ7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCglt YXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjsNCgljb2xvcjpibGFjazt9DQpzcGFuLmh0bWxwcmVmb3JtYXR0ZWRj aGFyMA0KCXttc28tc3R5bGUtbmFtZTpodG1scHJlZm9ybWF0dGVkY2hhcjsNCglmb250LWZhbWls eTpDb25zb2xhczt9DQpzcGFuLmVtYWlsc3R5bGUxOQ0KCXttc28tc3R5bGUtbmFtZTplbWFpbHN0 eWxlMTk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1h aWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhvbWFzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBzcG9rZSB3aXRoIEFsaSBhbmQg aGUgd2lsbCByZWZlcmVuY2UgdGhlIHR1bm5lbCBlbmNhcHN1bGF0aW9uIGRyYWZ0IHJhdGhlciB0 aGFuIFJGQyA1NTEyIGJ1dCBtYWtlIGl0IEluZm9ybWF0aXZlLiZuYnNwOyBJIHRoaW5rIHRoaXMg aXMgaW4gdGhlIHNwaXJpdCBvZiB3aGF0IHlvdQ0KIHByb3Bvc2VkIGluIHlvdXIgZW1haWwsIGJl bG93LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPllv dXJzIElycmVzcGVjdGl2ZWx5LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Sm9objxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93 dGV4dCI+IHRob21hcy5tb3JpbkBvcmFuZ2UuY29tIFttYWlsdG86dGhvbWFzLm1vcmluQG9yYW5n ZS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBNYXkgMTgsIDIwMTYgNjoxOSBB TTxicj4NCjxiPlRvOjwvYj4gSm9obiBFIERyYWtlOyBJRFI7IEJFU1M7IGRyYWZ0LWlldGYtYmVz cy1ldnBuLW92ZXJsYXlAdG9vbHMuaWV0Zi5vcmc7IEFsaSBTYWphc3NpIChzYWphc3NpKTsgUmFi YWRhbiwgSm9yZ2UgKE5va2lhIC0gVVMpOyBkcmFmdC1pZXRmLWlkci10dW5uZWwtZW5jYXBAdG9v bHMuaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJZHJdIGRyYWZ0LWlldGYtYmVz cy1ldnBuLW92ZXJsYXkgdnMuIGRyYWZ0LWlldGYtaWRyLXR1bm5lbC1lbmNhcHM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgSm9obiw8YnI+ DQo8YnI+DQpKb2huLjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+V2hlbiB0aGUgdHVubmVsIGVu Y2FwcyBkcmFmdCB3YXMgZmlyc3QgcHVibGlzaGVkIGl0IGRpZCBub3QgY2FycnkgZm9yd2FyZCB0 aGUgUkZDIDU1MTIgZXh0ZW5kZWQgY29tbXVuaXR5IGFuZCBpdCBkaWQgbm90IHByb3Bvc2UgdG8g b2Jzb2xldGUgUkZDIDU1MTIuJm5ic3A7IFRoZXJlDQogd2FzIGRpc2N1c3Npb24gb2YgdXNpbmcg dGhlIGF0dHJpYnV0ZSBkZWZpbmVkIGluIHRoZSB0dW5uZWwgZW5jYXBzIGRyYWZ0IGluc3RlYWQg b2YgdGhlIGV4dGVuZGVkIGNvbW11bml0eSBhbmQgd2UgZGVjaWRlZCB0byBjb250aW51ZSB0byB1 c2UgdGhlIGV4dGVuZGVkIGNvbW11bml0eS4mbmJzcDsgU28sIGluIHRoYXQgc2Vuc2Ugd2UgYXJl IG1pc2FsaWduZWQgd2l0aCB0aGUgdHVubmVsIGVuY2FwcyBkcmFmdC4NCjxicj4NCjxicj4NCjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxicj4NCkFzIHlvdSBjb25maXJtIGJlbG93LCB0aGUgbGFzdCBzZW50ZW5jZSBpcyBvbmx5IHRy dWUgaW4gdGhlIHBhc3QgdGVuc2UuPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlN1 YnNlcXVlbnRseSwgaG93ZXZlciwgdGhlIHR1bm5lbCBlbmNhcHMgZHJhZnQgZGVjaWRlZCB0byBj YXJyeSBmb3J3YXJkIHRoZSBleHRlbmRlZCBjb21tdW5pdHkgYW5kDQogdG8gb2Jzb2xldGUgUkZD IDU1MTIsIHNvIHdlIHdlcmUgZWZmZWN0aXZlbHkgY292ZXJlZCBieSBhIGdyYW5kZmF0aGVyIGNs YXVzZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YnI+DQpZZXMsIHByZWNpc2VseTogZ2l2ZW4gdGhlIGNvbnRlbnQgb2YgdGhlIHR3 byBkcmFmdHMsIHRoZXJlIGlzIG5vIG1pc2FsaWdubWVudCBhbnltb3JlLjxicj4NCjxicj4NCjxi cj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5HaXZlbiB0aGUgb3ZlcmxheSBkcmFmdOKAmXMgdGFyZGluZXNz LCBJIGRvbuKAmXQgdGhpbmsgdGhhdOKAmXMgYWNjZXB0YWJsZSBhbmQgd291bGQgcHJlZmVyIHRv IGNvbnRpbnVlIHRvDQogcmVmZXIgdG8gUkZDIDU1MTIuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KSSBkbyBub3QgdGhpbmsg dGhhdCB0aGUgYWRkaXRpb25hbCBwdWJsaWNhdGlvbiBkZWxheSBpcyBhIHNvdW5kIHJhdGlvbmFs ZSBmb3Igbm9ybWF0aXZlbHkgcmVmZXIgdG8gYSBzcGVjIHRoYXQgaXMga25vd24gdG8gYmVjb21l IG9ic29sZXRlLjxicj4NCklmIGl0IGhlbHBzLCB0aGUgZHJhZnQgY2FuIGtlZXAgYW4gaW5mb3Jt YXRpdmUgcmVmIHRvIFJGQzU1MTIgYW5kIHJlbWluZCB0aGF0IGl0IGRvZXMgbm90IHJlbHkgb24g YW55dGhpbmcgc3BlY2lmaWNhbGx5IGludHJvZHVjZWQgYnkgZHJhZnQtaWV0Zi1pZHItdHVubmVs LWVuY2FwcyBhbmQgbm90IGV4aXN0aW5nIGFscmVhZHkgaW4gUkZDNTUxMi48YnI+DQo8YnI+DQot VGhvbWFzPGJyPg0KPGJyPg0KPGJyPg0KMjAxNi0wNS0wNiwgSm9obiBFIERyYWtlOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Ib3dldmVyLCBldmVuIHRo b3VnaCBJIGFncmVlZCB5ZXN0ZXJkYXkgdG8gcmVmZXIgdG8gdGhlIHR1bm5lbCBlbmNhcHMgZHJh ZnQgaW5zdGVhZCBvZiBSRkMgNTUxMiB3ZSBoYXZlIGFuIGlzc3VlIHdpdGggZG9pbmcgdGhpcywg dml6LCB0aGUgb3ZlcmxheSBkcmFmdCBtYWtlcw0KIGEgbm9ybWF0aXZlIHJlZmVyZW5jZSB0byBS RkMgNTUxMi4mbmJzcDsgSWYgd2UgY2hhbmdlIHRoZSBub3JtYXRpdmUgcmVmZXJlbmNlIHRvIHRo ZSB0dW5uZWwgZW5jYXBzIGRyYWZ0IHdlIGNhbm5vdCBwdWJsaXNoIHRoZSBvdmVybGF5IGRyYWZ0 IHVudGlsIGFmdGVyIHRoZSB0dW5uZWwgZW5jYXBzIGRyYWZ0IGhhcyBiZWVuIHB1Ymxpc2hlZC48 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkdpdmVuIHRoZSBvdmVy bGF5IGRyYWZ04oCZcyB0YXJkaW5lc3MsIEkgZG9u4oCZdCB0aGluayB0aGF04oCZcyBhY2NlcHRh YmxlIGFuZCB3b3VsZCBwcmVmZXIgdG8gY29udGludWUgdG8gcmVmZXIgdG8gUkZDIDU1MTIuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+WW91cnMgSXJy ZXNwZWN0aXZlbHksPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5K b2huPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPg0KPGEgaHJlZj0ibWFpbHRvOnRob21hcy5tb3JpbkBvcmFu Z2UuY29tIj50aG9tYXMubW9yaW5Ab3JhbmdlLmNvbTwvYT4gWzxhIGhyZWY9Im1haWx0bzp0aG9t YXMubW9yaW5Ab3JhbmdlLmNvbSI+bWFpbHRvOnRob21hcy5tb3JpbkBvcmFuZ2UuY29tPC9hPl0N Cjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgTWF5IDA1LCAyMDE2IDU6NDcgUE08YnI+DQo8 Yj5Ubzo8L2I+IElEUjsgQkVTUzsgPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtYmVzcy1ldnBu LW92ZXJsYXlAdG9vbHMuaWV0Zi5vcmciPg0KZHJhZnQtaWV0Zi1iZXNzLWV2cG4tb3ZlcmxheUB0 b29scy5pZXRmLm9yZzwvYT47IEFsaSBTYWphc3NpIChzYWphc3NpKTsgUmFiYWRhbiwgSm9yZ2Ug KE5va2lhIC0gVVMpOw0KPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtaWRyLXR1bm5lbC1lbmNh cEB0b29scy5pZXRmLm9yZyI+ZHJhZnQtaWV0Zi1pZHItdHVubmVsLWVuY2FwQHRvb2xzLmlldGYu b3JnPC9hPjsgSm9obiBFIERyYWtlPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbSWRyXSBkcmFm dC1pZXRmLWJlc3MtZXZwbi1vdmVybGF5IHZzLiBkcmFmdC1pZXRmLWlkci10dW5uZWwtZW5jYXBz PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij5IaSBKb2huLCA8YnI+DQo8YnI+DQpJIGhhdmUgYSBoYXJkIHRp bWUgcmVjb25jaWxpYXRpbmcgdGhlIGZhY3QgdGhhdCB5ZXN0ZXJkYXkgeW91IHdlcmUgZmluZSB3 aXRoIGhhdmluZyBiZXNzLWV2cG4tb3ZlcmxheSByZWZlciB0byBpZHItdHVubmVsLWVuY2FwIGlu c3RlYWQgb2YgUkZDNTUxMiwgd2l0aCB0aGUgZmFjdCB0aGF0IHlvdSBjb25zaWRlciAoYmVsb3cp IHRoZSB0d28gZG9jcyAmcXVvdDtub3QgYWxpZ25lZCZxdW90OyBmb3IgdW5pY2FzdC48YnI+DQo8 YnI+DQpDYW4geW91IGJlIG1vcmUgZXhwbGljaXQgaW4gd2hlcmUgdGhlICZxdW90O21pc2FsaWdu bWVudCZxdW90OyBsaWVzPyA8YnI+DQo8YnI+DQotVGhvbWFzPGJyPg0KPGJyPg0KLS0tLSBKb2hu IEUgRHJha2UgYSDDqWNyaXQgLS0tLTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhvbWFzLDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlIG92ZXJsYXkgZHJh ZnQgcHJlY2VkZWQgdGhlIHR1bm5lbCBlbmNhcHMgZHJhZnQgYW5kIGl0IHdhcyBkZXNpZ25lZCB0 byBoYW5kbGUgYSB2ZXJ5IHNwZWNpZmljIHByb2JsZW0sIG1hcnJ5aW5nIHRoZSBFVlBOIGNvbnRy b2wgcGxhbmUgdG8gdGhlIFZYTEFOIGRhdGEgcGxhbmUNCiBkcmFmdCBhbmQgbW9kdWxvIHRoZSBj b3JyZWN0aW9uIHRvIHNlY3Rpb24gOSBpdCBpcyBpbnRlcm5hbGx5IGNvbnNpc3RlbnQuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgdHVubmVsIGVuY2FwcyBk cmFmdCBzb2x2ZXMgYSBtb3JlIGdlbmVyYWwgcHJvYmxlbSBhbmQgdGhlIFdHIGRlY2lkZWQgYSBs b25nIHRpbWUgYWdvIHRoYXQgdGhlIG92ZXJsYXkgZHJhZnQgd2FzIG5vdCBnb2luZyB0byBiZSB1 cGRhdGVkIHRvIHVzZSB0aGUgbWVjaGFuaXNtcw0KIGl0IGRldGFpbHMgZm9yIHVuaWNhc3QsIHNv IHRoZSBvdmVybGF5IGRyYWZ0IGlzIGFscmVhZHkgZXhwbGljaXRseSBub3QgaW4gYWxpZ25tZW50 IHdpdGggaXQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGlz LCBwbHVzIHRoZSBmYWN0IHRoYXQgdGhlIHR1bm5lbCBlbmNhcHMgZHJhZnQgZXhwbGljaXRseSBw dXRzIHRoZSBQTVNJIG91dCBvZiBzY29wZSwgbGVhZHMgbWUgdG8gdGhlIGNvbmNsdXNpb24gdGhh dCB0aGUgb3ZlcmxheSBkcmFmdCBzaG91bGQgbm90IGJlIHR3ZWFrZWQNCiB0byBiZSBpbiBhbGln bm1lbnQgd2l0aCBhIGZ1dHVyZSBzb2x1dGlvbiBmb3IgZW5jb2RpbmcgVk5JcyBmb3IgbXVsdGlj YXN0LiA8L3NwYW4+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PllvdXJzIElycmVzcGVjdGl2ZWx5LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+Sm9objwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs dWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4NCjxhIGhyZWY9Im1haWx0bzp0aG9tYXMu bW9yaW5Ab3JhbmdlLmNvbSI+dGhvbWFzLm1vcmluQG9yYW5nZS5jb208L2E+IFs8YSBocmVmPSJt YWlsdG86dGhvbWFzLm1vcmluQG9yYW5nZS5jb20iPm1haWx0bzp0aG9tYXMubW9yaW5Ab3Jhbmdl LmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE1heSAwNSwgMjAxNiA4OjMy IEFNPGJyPg0KPGI+VG86PC9iPiBKb2huIEUgRHJha2U7IElEUjsgQkVTUzsgPGEgaHJlZj0ibWFp bHRvOmRyYWZ0LWlldGYtYmVzcy1ldnBuLW92ZXJsYXlAdG9vbHMuaWV0Zi5vcmciPg0KZHJhZnQt aWV0Zi1iZXNzLWV2cG4tb3ZlcmxheUB0b29scy5pZXRmLm9yZzwvYT47IEFsaSBTYWphc3NpIChz YWphc3NpKTsgUmFiYWRhbiwgSm9yZ2UgKE5va2lhIC0gVVMpOw0KPGEgaHJlZj0ibWFpbHRvOmRy YWZ0LWlldGYtaWRyLXR1bm5lbC1lbmNhcEB0b29scy5pZXRmLm9yZyI+ZHJhZnQtaWV0Zi1pZHIt dHVubmVsLWVuY2FwQHRvb2xzLmlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTog W0lkcl0gZHJhZnQtaWV0Zi1iZXNzLWV2cG4tb3ZlcmxheSB2cy4gZHJhZnQtaWV0Zi1pZHItdHVu bmVsLWVuY2Fwczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+VGhhbmtzIGZvciB0aGUgY2xhcmlmaWNhdGlv biBvbiB0aGUgaW50ZW50IGFyb3VuZCBkcmFmdC1pZXRmLWJlc3MtZXZwbi1vdmVybGF5LiBUaGVu IGluZGVlZCBzZWN0aW9uIDkgbmVlZHMgc29tZSB0aWR5aW5nIHVwLg0KPGJyPg0KPGJyPg0KVGhl IGlzc3VlIHRoYXQgSSB0aGluayByZW1haW4gaXMgdGhhdCBpdCB3b3VsZCBiZSBtdWNoIGNsZWFu ZXIgdG8gZXhwbGFpbiBob3cgdG8gdXNlIFBNU0kgd2l0aCBvdmVybGF5IGVuY2FwcyBpbiBhIHNw ZWMgbm90IHNwZWNpZmljIHRvIEUtVlBOIGFuZCBpbiBhIHdheSBtb3JlIGNvbnNpc3RlbnQgdG8g d2hhdCBpcyBkb25lIGZvciB1bmljYXN0Lg0KPGJyPg0KPGJyPg0KSXQgc2VlbXMgaWYgY291cnNl IHRoYXQgZHJhZnQtaWV0Zi1pZHItdHVubmVsLWVuY2FwIHNob3VsZCBiZSB0aGUgcGxhY2UsIGJ1 dCB0aGF0IGRvY3VtZW50IGN1cnJlbnRseSBleHBsaWNpdGx5IG1ha2VzIFBNU0lzIG91dCBvZiBz Y29wZS4NCjxicj4NCjxicj4NClNob3VsZG4ndCB0aGlzIHBhcnQgb2YgZHJhZnQtaWV0Zi1pZHIt dHVubmVsLWVuY2FwIGJlIHJldmlzaXRlZCA/IDxicj4NCjxicj4NCi1UaG9tYXM8YnI+DQo8YnI+ DQo8YnI+DQotLS0tIFJhYmFkYW4sIEpvcmdlIChOb2tpYSAtIFVTKSBhIMOpY3JpdCAtLS0tPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBpZD0iY29tcG9zZSI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5GdWxseSBhZ3JlZSBKb2hu LiBUaGF0J3Mgd2hhdCBJIG1lYW50LCBzb3JyeSBpZiBJIGRpZG4ndCBtYWtlIG15c2VsZiBjbGVh ci4gU2VjdGlvbiA5IG5lZWRzIGNsZWFuIHVwLCB5ZXMuPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLDxicj4NCkpvcmdlPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KRnJvbTogRVhUIEpv aG4gRSBEcmFrZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpkcmFrZUBqdW5pcGVyLm5ldCI+amRyYWtl QGp1bmlwZXIubmV0PC9hPiZndDs8YnI+DQpTZW50OiBXZWRuZXNkYXksIE1heSA0LCAyMDE2IDIz OjM0PGJyPg0KU3ViamVjdDogUkU6IFtJZHJdIGRyYWZ0LWlldGYtYmVzcy1ldnBuLW92ZXJsYXkg dnMuIGRyYWZ0LWlldGYtaWRyLXR1bm5lbC1lbmNhcHM8YnI+DQpUbzogSURSICZsdDs8YSBocmVm PSJtYWlsdG86aWRyQGlldGYub3JnIj5pZHJAaWV0Zi5vcmc8L2E+Jmd0OywgQWxpIFNhamFzc2kg KHNhamFzc2kpICZsdDs8YSBocmVmPSJtYWlsdG86c2FqYXNzaUBjaXNjby5jb20iPnNhamFzc2lA Y2lzY28uY29tPC9hPiZndDssIFJhYmFkYW4sIEpvcmdlIChOb2tpYSAtIFVTKSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmpvcmdlLnJhYmFkYW5AYWxjYXRlbC1sdWNlbnQuY29tIj5qb3JnZS5yYWJhZGFu QGFsY2F0ZWwtbHVjZW50LmNvbTwvYT4mZ3Q7LA0KIEJFU1MgJmx0OzxhIGhyZWY9Im1haWx0bzpi ZXNzQGlldGYub3JnIj5iZXNzQGlldGYub3JnPC9hPiZndDssICZsdDs8YSBocmVmPSJtYWlsdG86 ZHJhZnQtaWV0Zi1iZXNzLWV2cG4tb3ZlcmxheUB0b29scy5pZXRmLm9yZyI+ZHJhZnQtaWV0Zi1i ZXNzLWV2cG4tb3ZlcmxheUB0b29scy5pZXRmLm9yZzwvYT4mZ3Q7LCBFWFQgLQ0KPGEgaHJlZj0i bWFpbHRvOnRob21hcy5tb3JpbkBvcmFuZ2UuY29tIj50aG9tYXMubW9yaW5Ab3JhbmdlLmNvbTwv YT4gJmx0OzxhIGhyZWY9Im1haWx0bzp0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbSI+dGhvbWFzLm1v cmluQG9yYW5nZS5jb208L2E+Jmd0Ozxicj4NCjxicj4NCjxicj4NCkpvcmdlLDxicj4NCjxicj4N CldlIHB1dCB0aGUgVk5JIHZhbHVlIGluIHRoZSBNUExTIGxhYmVsIGZpZWxkIG9mIHRoZSBQTVNJ IGF0dHJpYnV0ZSBmb3IgYWxsIHNlcnZpY2UgdHlwZXMsIGFuZCB3ZSBwdXQgYSB2YWx1ZSBpbiB0 aGUgRXRoZXJuZXQgVGFnIGZpZWxkIGZvbGxvd2luZyB0aGUgcnVsZXMgZm9yIGVhY2ggc2Vydmlj ZSB0eXBlIGFzIGRlc2NyaWJlZCBpbiA1LjEuMyAoPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtYmVzcy1ldnBuLW92ZXJsYXktMDIjc2VjdGlvbi01LjEuMyI+ aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYmVzcy1ldnBuLW92ZXJsYXkt MDIjc2VjdGlvbi01LjEuMzwvYT4pLjxicj4NCjxicj4NCllvdSdyZSByaWdodCB0aGF0IHdlIG5l ZWQgdG8gY2xlYW4gdXAgc2VjdGlvbiA5Ljxicj4NCjxicj4NCllvdXJzIElycmVzcGVjdGl2ZWx5 LDxicj4NCjxicj4NCkpvaG48YnI+DQo8YnI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tPGJyPg0KJmd0OyBGcm9tOiBSYWJhZGFuLCBKb3JnZSAoTm9raWEgLSBVUykgWzxhIGhyZWY9 Im1haWx0bzpqb3JnZS5yYWJhZGFuQG5va2lhLmNvbSI+bWFpbHRvOmpvcmdlLnJhYmFkYW5Abm9r aWEuY29tPC9hPl08YnI+DQomZ3Q7IFNlbnQ6IFdlZG5lc2RheSwgTWF5IDA0LCAyMDE2IDM6NTMg UE08YnI+DQomZ3Q7IFRvOiBKb2huIEUgRHJha2U7IEVYVCAtIDxhIGhyZWY9Im1haWx0bzp0aG9t YXMubW9yaW5Ab3JhbmdlLmNvbSI+dGhvbWFzLm1vcmluQG9yYW5nZS5jb208L2E+OyBCRVNTOyBJ RFI7IGRyYWZ0LWlldGYtYmVzcy1ldnBuLTxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOm92ZXJs YXlAdG9vbHMuaWV0Zi5vcmciPm92ZXJsYXlAdG9vbHMuaWV0Zi5vcmc8L2E+OyBBbGkgU2FqYXNz aSAoc2FqYXNzaSk8YnI+DQomZ3Q7IFN1YmplY3Q6IFJlOiBbSWRyXSBkcmFmdC1pZXRmLWJlc3Mt ZXZwbi1vdmVybGF5IHZzLiBkcmFmdC1pZXRmLWlkci10dW5uZWwtZW5jYXBzPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IEhpIEpvaG4sPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEFib3V0IHRoaXM6PGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IFtKRF0gRm9yIHRoZSBJTUVUIHJvdXRlIHRoZSBNUExTIGxhYmVsIGZp ZWxkIGlzIGNhcnJpZWQgaW4gdGhlIFBNU0kgYXR0cmlidXRlLiBJIHRoaW5rIHdlIG5lZWQ8YnI+ DQomZ3Q7IHRvIGFzayBldmVyeW9uZSB3aGV0aGVyIHRoZXkgdXNlZCB0aGUgRXRoZXJuZXQgVGFn IG9yIHRoZSBQTVNJIGF0dHJpYnV0ZSB0byBjYXJyeSB0aGUgVk5JPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IDxicj4NCiZndDsgSW4gY2FzZSBpdCBoZWxwcywgSeKAmXZlIHNlZW4gYSBmZXcgaW1wbGVt ZW50YXRpb25zIHJ1bm5pbmcgYW5kIHRoZXkgYWxsIGVuY29kZSB0aGUgVk5JIGluIHRoZTxicj4N CiZndDsgTVBMUyBsYWJlbCBmaWVsZCBpbiB0aGUgUFRBLiBBbmQgYSBjb3VwbGUgb2YgdGhlbSwg ZW5jb2RlIHRoZSBWTkkgaW4gdGhlIGV0aGVybmV0LXRhZywgaW48YnI+DQomZ3Q7IGFkZGl0aW9u IHRvIHRoZSBNUExTIGxhYmVsIGluIHRoZSBQVEEuIEluIGFueSBjYXNlLCBJIHRoaW5rIHNlY3Rp b24gOSBjb250cmFkaWN0cyBzZWN0aW9uIDUuMS4zPGJyPg0KJmd0OyBhbmQgc2hvdWxkIGJlIGNs YXJpZmllZC48YnI+DQomZ3Q7IDxicj4NCiZndDsgJnF1b3Q7NS4xLjMgQ29uc3RydWN0aW5nIEVW UE4gQkdQIFJvdXRlczxicj4NCiZndDsgJmx0O3NuaXAmZ3Q7PGJyPg0KJmd0OyB0aGUgTVBMUyBs YWJlbCBmaWVsZCBpbiB0aGUgTUFDIEFkdmVydGlzZW1lbnQsIEV0aGVybmV0IEFEIHBlciBFVkks IGFuZCAqKkluY2x1c2l2ZTxicj4NCiZndDsgTXVsdGljYXN0IEV0aGVybmV0IFRhZyoqIHJvdXRl cyBpcyB1c2VkIHRvIGNhcnJ5IHRoZSBWTkkgb3IgVlNJRC4mcXVvdDs8YnI+DQomZ3Q7IDxicj4N CiZndDsgVGhhbmtzLjxicj4NCiZndDsgSm9yZ2U8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBPbiA1LzQvMTYsIDg6MzQgUE0s ICZxdW90O0VYVCBKb2huIEUgRHJha2UmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpqZHJha2VA anVuaXBlci5uZXQiPmpkcmFrZUBqdW5pcGVyLm5ldDwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsg PGJyPg0KJmd0OyAmZ3Q7VGhvbWFzIGFuZCBKb3JnZSw8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDtTbmlwcGVkLCBjb21tZW50cyBpbmxpbmUuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7WW91cnMgSXJyZXNwZWN0aXZlbHksPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Sm9o bjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZn dDsgJmd0O2RyYWZ0LWlldGYtYmVzcy1ldnBuLW92ZXJsYXkgKHNlZSBzZWN0aW9uIDkpIHJlbGll cyBvbiB0aGUgQkdQPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7RW5jYXBzdWxhdGlvbiBleHRlbmRl ZCB0byBlbmNvZGUgdGhlIHR1bm5lbCBlbmNhcCB0byB1c2UgZm9yIEJVTTxicj4NCiZndDsgJmd0 OyZndDsgJmd0O3RyYWZmaWMsIGJ1dCBjb250cmFyeSB0byBvdGhlciBFLVZQTiByb3V0ZXMsIHJl bGllcyBvbiB0aGUgRXRoZXJuZXQ8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDtUYWcgZmllbGQgb2Yg dGhlIE5MUkkgdG8gZW5jb2RlIHRoZSBWTkkvVlNJRC48YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7Jmd0OyBbSk9SR0VdIFRoaXMgaXMgY2VydGFpbmx5IGEgbGVmdG92ZXIgZnJvbSBh biBvbGQgdmVyc2lvbiB3aGVyZSB0aGU8YnI+DQomZ3Q7ICZndDsmZ3Q7IFZOSS9WU0lEIHdhcyBl bmNvZGVkIGluIHRoZSBldGhlcm5ldCB0YWcgZm9yIGFsbCB0aGUgcm91dGVzLiBUaGUgVk5JPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyBzaG91bGQgYmUgZW5jb2RlZCBpbiB0aGUgTGFiZWwgZmllbGQgaW4g YWxsIHRoZSByb3V0ZXMuIFRoaXMgaGFzIHRvIGJlIGNvcnJlY3RlZC48YnI+DQomZ3Q7ICZndDsm Z3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBJbiBmYWN0LCBzZWN0aW9uIDUuMS4zIHNheXM6PGJyPg0K Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgNS4xLjMgQ29uc3RydWN0aW5nIEVWUE4g QkdQIFJvdXRlczxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZsdDtzbmlw Jmd0Ozxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IEFjY29yZGluZ2x5LCBh bmQ8YnI+DQomZ3Q7ICZndDsmZ3Q7IHNwZWNpZmljYWxseSB0byBzdXBwb3J0IHRoZSBvcHRpb24g b2YgbG9jYWxseSBhc3NpZ25lZCBWTklzLCB0aGUgTVBMUzxicj4NCiZndDsgJmd0OyZndDsgbGFi ZWwgZmllbGQgaW4gdGhlIE1BQyBBZHZlcnRpc2VtZW50LCBFdGhlcm5ldCBBRCBwZXIgRVZJLCBh bmQ8YnI+DQomZ3Q7ICZndDsmZ3Q7IEluY2x1c2l2ZSBNdWx0aWNhc3QgRXRoZXJuZXQgVGFnIHJv dXRlcyBpcyB1c2VkIHRvIGNhcnJ5IHRoZSBWTkkgb3I8YnI+DQomZ3Q7ICZndDsmZ3Q7IFZTSUQu IEZvciB0aGUgYmFsYW5jZSBvZiB0aGlzIG1lbW8sIHRoZSBNUExTIGxhYmVsIGZpZWxkIHdpbGwg YmU8YnI+DQomZ3Q7ICZndDsmZ3Q7IHJlZmVycmVkIHRvIGFzIHRoZSBWTkkvVlNJRCBmaWVsZC4g VGhlIFZOSS9WU0lEIGZpZWxkIGlzIHVzZWQgZm9yPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBib3RoIGxv Y2FsIGFuZCBnbG9iYWwgVk5Jcy9WU0lEcywgYW5kIGZvciBlaXRoZXIgY2FzZSB0aGUgZW50aXJl IDI0LTxicj4NCiZndDsgJmd0OyZndDsgYml0IGZpZWxkIGlzIHVzZWQgdG8gZW5jb2RlIHRoZSBW TkkvVlNJRCB2YWx1ZS48YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmbHQ7 c25pcCZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDtbSkRd IEZvciB0aGUgSU1FVCByb3V0ZSB0aGUgTVBMUyBsYWJlbCBmaWVsZCBpcyBjYXJyaWVkIGluIHRo ZSBQTVNJIGF0dHJpYnV0ZS4gSSB0aGluayB3ZTxicj4NCiZndDsgbmVlZCB0byBhc2sgZXZlcnlv bmUgd2hldGhlciB0aGV5PGJyPg0KJmd0OyAmZ3Q7dXNlZCB0aGUgRXRoZXJuZXQgVGFnIG9yIHRo ZSBQTVNJIGF0dHJpYnV0ZSB0byBjYXJyeSB0aGUgVk5JPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgJmd0 OyZndDsgVGhlcmUgYXJlIG1pbm9yIHRoaW5ncyB0aGF0IGNvdWxkIGJlIGltcHJvdmVkIGluPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBkcmFmdC1pZXRmLWJlc3MtZXZwbi1vdmVybGF5IHdy dC4gY29uc2lzdGVuY3kgd2l0aDxicj4NCiZndDsgJmd0OyZndDsgJmd0OyZndDsgZHJhZnQtaWV0 Zi1pZHItdHVubmVsLWVuY2FwcyA6PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZn dDsgJmd0OyZndDsgJmd0OyZndDsgKiBzaW5jZSBkcmFmdC1pZXRmLWlkci10dW5uZWwtZW5jYXBz IHdpbGwgZGVwcmVjYXRlIFJGQzU1MTIsIGl0PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyB3 b3VsZCBiZSBiZXR0ZXIgdGhhdCBkcmFmdC1pZXRmLWJlc3MtZXZwbi1vdmVybGF5IHJlZmVycyB0 bzxicj4NCiZndDsgJmd0OyZndDsgJmd0OyZndDsgZHJhZnQtaWV0Zi1pZHItdHVubmVsLWVuY2Fw cyBhbmQgbm90IGFueW1vcmUgdG8gUkZDNTUxMi48YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7Jmd0OyBbSk9SR0VdIEkgYWdyZWUsIGFzIGxvbmcgYXMgZHJhZnQtaWV0Zi1pZHItdHVu bmVsLWVuY2FwcyBrZWVwcyB0aGU8YnI+DQomZ3Q7ICZndDsmZ3Q7IGVuY2Fwc3VsYXRpb24gZXh0 ZW5kZWQgY29tbXVuaXR5LiBUaGVyZSBhcmUgYSBmZXcgaW1wbGVtZW50YXRpb25zPGJyPg0KJmd0 OyAmZ3Q7Jmd0OyB1c2luZyB0aGlzIGNvbW11bml0eSBhbmQgaXQgaXMgZW5vdWdoIHdoZW4gb25s eSB0aGUgZW5jYXBzdWxhdGlvbiB0eXBlIGlzIG5lZWRlZC48YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDtbSkRdIEkgYWdyZWUgYW5kIHRoZSB0dW5uZWwgZW5jYXBz IGRyYWZ0IGRvZXMga2VlcCB0aGUgRUM8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+ DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0 OyZndDsgJmd0OyZndDsgKiBJIHRoaW5rIGl0IHdvdWxkIGJlIGJldHRlciB0byBhdm9pZCB0aGUg ZXhwbGljaXQgbGlzdCBvZiBlbmNhcDxicj4NCiZndDsgJmd0OyZndDsgJmd0OyZndDsgdHlwZXMg aW4gc2VjdGlvbiA1LjEuMywgYW5kIHJhdGhlciByZWZlciB0bzxicj4NCiZndDsgJmd0OyZndDsg Jmd0OyZndDsgZHJhZnQtaWV0Zi1pZHItdHVubmVsLWVuY2FwcyBpbnN0ZWFkPGJyPg0KJmd0OyAm Z3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgW0pPUkdFXSBJIGFncmVlLjxicj4NCiZndDsgJmd0 Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0O1tKRF0gQWNjb3JkaW5nIHRvIElBTkEsIGl0 IGFsbG9jYXRlZCB0aGUgZml2ZSB0dW5uZWxzIHR5cGVzIHRvIHRoZTxicj4NCiZndDsgJmd0O292 ZXJsYXkgZHJhZnQgc28gSSB0aGluayB3ZSBuZWVkIHRvIGtlZXAgdGhlbTxicj4NCiZndDsgJmd0 Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7ICogdGhlIGZvbGxvd2luZyBtaW5vciBtb2RpZmljYXRpb24gd2FzIHByb3Bvc2VkLCBi dXQgbm90IHlldCBpbmNvcnBvcmF0ZWQ6PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4N CiZndDsgJmd0OyZndDsgJmd0OyZndDsgSm9obiBEcmFrZSwgMjAxNS0xMS0xMyAodG8gQkVTUyBN TCk6PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgRm9yIHRoZSBvdmVybGF5IGRyYWZ0 LCByZXBsYWNlIHRoaXMgdGV4dCBpbiBzZWN0aW9uIDUuMS4zOjxicj4NCiZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJnF1b3Q7SWYgdGhl IEJHUCBFbmNhcHN1bGF0aW9uIGV4dGVuZGVkIGNvbW11bml0eSBpcyBub3QgcHJlc2VudCw8YnI+ DQomZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyB0aGVuIHRoZSBkZWZhdWx0IE1QTFMgZW5jYXBz dWxhdGlvbiBvciBhIHN0YXRpY2FsbHkgY29uZmlndXJlZDxicj4NCiZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7IGVuY2Fwc3VsYXRpb24gaXMgYXNzdW1lZC4mcXVvdDs8YnI+DQomZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IFdpdGggdGhl IGZvbGxvd2luZzo8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZxdW90O05vdGUgdGhhdCB0aGUgTVBMUyBlbmNhcHN1bGF0aW9u IHR1bm5lbCB0eXBlIGlzIG5lZWRlZCBpbjxicj4NCiZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 IG9yZGVyIHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4gYW4gYWR2ZXJ0aXNpbmcgbm9kZSB0aGF0IG9u bHk8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBzdXBwb3J0cyBub24tTVBMUyBlbmNh cHN1bGF0aW9ucyBhbmQgb25lIHRoYXQgc3VwcG9ydHMgTVBMUyBhbmQ8YnI+DQomZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyBub24tTVBMUyBlbmNhcHN1bGF0aW9ucy4gQW4gYWR2ZXJ0aXNpbmcg bm9kZSB0aGF0IG9ubHkgc3VwcG9ydHM8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBN UExTIGVuY2Fwc3VsYXRpb24gZG9lcyBub3QgbmVlZCB0byBhZHZlcnRpc2UgYW55IGVuY2Fwc3Vs YXRpb248YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyB0dW5uZWwgdHlwZXM7IGkuZS4s IGlmIHRoZSBCR1AgRW5jYXBzdWxhdGlvbiBleHRlbmRlZCBjb21tdW5pdHk8YnI+DQomZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBpcyBub3QgcHJlc2VudCwgdGhlbiBlaXRoZXIgTVBMUyBlbmNh cHN1bGF0aW9uIG9yIGEgc3RhdGljYWxseTxicj4NCiZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 IGNvbmZpZ3VyZWQgZW5jYXBzdWxhdGlvbiBpcyBhc3N1bWVkLiZxdW90Ozxicj4NCiZndDsgJmd0 OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IEkgdGhpbmsgdGhpcyBj aGFuZ2UgaXMgdXNlZnVsIGFuZCBzaG91bGQgYmUgaW5jb3Jwb3JhdGVkLCBhbHRob3VnaDxicj4N CiZndDsgJmd0OyZndDsgJmd0OyZndDsgc2tpcHBpbmcgdGhlIGxhc3Qgc2VudGVuY2Ugd291bGQg YmUgd2lzZSBpZiB0aGUgZnVsbCBsaXN0IG9mPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyB0 dW5uZWwgdHlwZXMgaXMgcmVtb3ZlZC48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+ DQomZ3Q7ICZndDtbSkRdIEZpbmUgd2l0aCBtZSBlaXRoZXIgdy8gb3Igdy9vIHRoZSBsYXN0IHNl bnRlbmNlPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwcmU+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkNl IG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9y bWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9u YzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3Ug Y29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBh ciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyPG86cD48L286cD48L3ByZT4NCjxwcmU+YSBs J2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4g TGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlv biw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5PcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJp bGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVy Y2kuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+ VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFs IG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVz ZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT5JZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5 IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5BcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBp cyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdl ZCBvciBmYWxzaWZpZWQuPG86cD48L286cD48L3ByZT4NCjxwcmU+VGhhbmsgeW91LjxvOnA+PC9v OnA+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_SN1PR0501MB17090A6F0AC5D3D447E21C28C7490SN1PR0501MB1709_-- From nobody Wed May 18 07:23:06 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34CDB12D506; Wed, 18 May 2016 07:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.949 X-Spam-Level: X-Spam-Status: No, score=-4.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_SOFTFAIL=0.665, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5TmoQUDrcGw; Wed, 18 May 2016 07:23:02 -0700 (PDT) Received: from r-mail2.rd.orange.com (r-mail2.rd.orange.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 1B57512D122; Wed, 18 May 2016 07:23:01 -0700 (PDT) Received: from r-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1479C16C00A; Wed, 18 May 2016 16:23:00 +0200 (CEST) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by r-mail2.rd.orange.com (Postfix) with ESMTP id 0609E5D85F9; Wed, 18 May 2016 16:23:00 +0200 (CEST) Received: from [10.193.71.12] (10.193.71.12) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.266.1; Wed, 18 May 2016 16:22:59 +0200 To: John E Drake , IDR , BESS , "draft-ietf-bess-evpn-overlay@tools.ietf.org" , "Ali Sajassi (sajassi)" , "Rabadan, Jorge (Nokia - US)" , "draft-ietf-idr-tunnel-encap@tools.ietf.org" References: <5729F1C3.1030605@orange.com> <5729F7C5.6040604@orange.com> <52D35106-ED5E-4C95-9131-6EA4527370D5@alcatel-lucent.com> <012C176C-A8D6-45AA-BA69-616C0ED7E41E@alcatel-lucent.com> <420BA2D8D80A6727.2B2C290F-2299-40BB-B53B-CC36D2B5D826@mail.outlook.com> <1881_1462451514_572B3D3A_1881_7198_1_0vn90oitr7e881gh2sn8qm5f.1462451509961@email.android.com> <17029_1462484835_572BBF63_17029_2323_1_opi9hqsl9b9tani0t0skkcuq.1462484831251@email.android.com> <28175_1463566739_573C4192_28175_2444_1_613f729b-d12e-5c48-29a1-ff000c1184a1@orange.com> From: Thomas Morin Organization: Orange Message-ID: <9ed4f1b1-1d84-2302-d7bb-5ad7fc42acdb@orange.com> Date: Wed, 18 May 2016 16:22:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------91EE4B3346D8F36A9C2C7D08" Archived-At: Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 14:23:05 -0000 --------------91EE4B3346D8F36A9C2C7D08 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit John, 2016-05-18, John E Drake: > I spoke with Ali and he will reference the tunnel encapsulation draft > rather than RFC 5512 but make it Informative. > I think this is in the spirit of what you proposed in your email, below. Well, only for some definition of "in the spirit"... :-/ What I think we should do is normatively refer to draft-ietf-idr-tunnel-encaps and informatively refer to RFC5512, not the reverse. Or else we end up with an RFC that soon after publication will normatively depend to an obsoleted RFC. -Thomas > *From:*thomas.morin@orange.com [mailto:thomas.morin@orange.com] > *Sent:* Wednesday, May 18, 2016 6:19 AM > *To:* John E Drake; IDR; BESS; > draft-ietf-bess-evpn-overlay@tools.ietf.org; Ali Sajassi (sajassi); > Rabadan, Jorge (Nokia - US); draft-ietf-idr-tunnel-encap@tools.ietf.org > *Subject:* Re: [Idr] draft-ietf-bess-evpn-overlay vs. > draft-ietf-idr-tunnel-encaps > > Hi John, > > John. > > When the tunnel encaps draft was first published it did not carry > forward the RFC 5512 extended community and it did not propose to > obsolete RFC 5512. There was discussion of using the attribute > defined in the tunnel encaps draft instead of the extended > community and we decided to continue to use the extended > community. So, in that sense we are misaligned with the tunnel > encaps draft. > > > As you confirm below, the last sentence is only true in the past tense. > > > Subsequently, however, the tunnel encaps draft decided to carry > forward the extended community and to obsolete RFC 5512, so we > were effectively covered by a grandfather clause. > > > Yes, precisely: given the content of the two drafts, there is no > misalignment anymore. > > > Given the overlay draft’s tardiness, I don’t think that’s > acceptable and would prefer to continue to refer to RFC 5512. > > > I do not think that the additional publication delay is a sound > rationale for normatively refer to a spec that is known to become > obsolete. > If it helps, the draft can keep an informative ref to RFC5512 and > remind that it does not rely on anything specifically introduced by > draft-ietf-idr-tunnel-encaps and not existing already in RFC5512. > > -Thomas > > > 2016-05-06, John E Drake: > > However, even though I agreed yesterday to refer to the tunnel > encaps draft instead of RFC 5512 we have an issue with doing this, > viz, the overlay draft makes a normative reference to RFC 5512. > If we change the normative reference to the tunnel encaps draft we > cannot publish the overlay draft until after the tunnel encaps > draft has been published. > > Given the overlay draft’s tardiness, I don’t think that’s > acceptable and would prefer to continue to refer to RFC 5512. > > Yours Irrespectively, > > John > > *From:*thomas.morin@orange.com > [mailto:thomas.morin@orange.com] > *Sent:* Thursday, May 05, 2016 5:47 PM > *To:* IDR; BESS; draft-ietf-bess-evpn-overlay@tools.ietf.org > ; Ali Sajassi > (sajassi); Rabadan, Jorge (Nokia - US); > draft-ietf-idr-tunnel-encap@tools.ietf.org > ; John E Drake > *Subject:* RE: [Idr] draft-ietf-bess-evpn-overlay vs. > draft-ietf-idr-tunnel-encaps > > Hi John, > > I have a hard time reconciliating the fact that yesterday you were > fine with having bess-evpn-overlay refer to idr-tunnel-encap > instead of RFC5512, with the fact that you consider (below) the > two docs "not aligned" for unicast. > > Can you be more explicit in where the "misalignment" lies? > > -Thomas > > ---- John E Drake a écrit ---- > > Thomas, > > The overlay draft preceded the tunnel encaps draft and it was > designed to handle a very specific problem, marrying the EVPN > control plane to the VXLAN data plane draft and modulo the > correction to section 9 it is internally consistent. > > The tunnel encaps draft solves a more general problem and the WG > decided a long time ago that the overlay draft was not going to be > updated to use the mechanisms it details for unicast, so the > overlay draft is already explicitly not in alignment with it. > > This, plus the fact that the tunnel encaps draft explicitly puts > the PMSI out of scope, leads me to the conclusion that the overlay > draft should not be tweaked to be in alignment with a future > solution for encoding VNIs for multicast. > > Yours Irrespectively, > > John > > *From:*thomas.morin@orange.com > [mailto:thomas.morin@orange.com] > *Sent:* Thursday, May 05, 2016 8:32 AM > *To:* John E Drake; IDR; BESS; > draft-ietf-bess-evpn-overlay@tools.ietf.org > ; Ali Sajassi > (sajassi); Rabadan, Jorge (Nokia - US); > draft-ietf-idr-tunnel-encap@tools.ietf.org > > *Subject:* RE: [Idr] draft-ietf-bess-evpn-overlay vs. > draft-ietf-idr-tunnel-encaps > > Thanks for the clarification on the intent around > draft-ietf-bess-evpn-overlay. Then indeed section 9 needs some > tidying up. > > The issue that I think remain is that it would be much cleaner to > explain how to use PMSI with overlay encaps in a spec not specific > to E-VPN and in a way more consistent to what is done for unicast. > > It seems if course that draft-ietf-idr-tunnel-encap should be the > place, but that document currently explicitly makes PMSIs out of > scope. > > Shouldn't this part of draft-ietf-idr-tunnel-encap be revisited ? > > -Thomas > > > ---- Rabadan, Jorge (Nokia - US) a écrit ---- > > Fully agree John. That's what I meant, sorry if I didn't make > myself clear. Section 9 needs clean up, yes. > > Thanks, > Jorge > > _____________________________ > From: EXT John E Drake > > Sent: Wednesday, May 4, 2016 23:34 > Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. > draft-ietf-idr-tunnel-encaps > To: IDR >, Ali Sajassi > (sajassi) >, Rabadan, > Jorge (Nokia - US) >, BESS >, > >, EXT - > thomas.morin@orange.com > > > > > Jorge, > > We put the VNI value in the MPLS label field of the PMSI attribute > for all service types, and we put a value in the Ethernet Tag > field following the rules for each service type as described in > 5.1.3 > (https://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-02#section-5.1.3). > > You're right that we need to clean up section 9. > > Yours Irrespectively, > > John > > > -----Original Message----- > > From: Rabadan, Jorge (Nokia - US) [mailto:jorge.rabadan@nokia.com] > > Sent: Wednesday, May 04, 2016 3:53 PM > > To: John E Drake; EXT - thomas.morin@orange.com > ; BESS; IDR; draft-ietf-bess-evpn- > > overlay@tools.ietf.org ; Ali > Sajassi (sajassi) > > Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. > draft-ietf-idr-tunnel-encaps > > > > Hi John, > > > > About this: > > > > [JD] For the IMET route the MPLS label field is carried in the > PMSI attribute. I think we need > > to ask everyone whether they used the Ethernet Tag or the PMSI > attribute to carry the VNI > > > > > > In case it helps, I’ve seen a few implementations running and > they all encode the VNI in the > > MPLS label field in the PTA. And a couple of them, encode the > VNI in the ethernet-tag, in > > addition to the MPLS label in the PTA. In any case, I think > section 9 contradicts section 5.1.3 > > and should be clarified. > > > > "5.1.3 Constructing EVPN BGP Routes > > > > the MPLS label field in the MAC Advertisement, Ethernet AD per > EVI, and **Inclusive > > Multicast Ethernet Tag** routes is used to carry the VNI or VSID." > > > > Thanks. > > Jorge > > > > > > > > > > > > On 5/4/16, 8:34 PM, "EXT John E Drake" > wrote: > > > > >Thomas and Jorge, > > > > > >Snipped, comments inline. > > > > > >Yours Irrespectively, > > > > > >John > > > > > >> > > > >> >draft-ietf-bess-evpn-overlay (see section 9) relies on the BGP > > >> >Encapsulation extended to encode the tunnel encap to use for BUM > > >> >traffic, but contrary to other E-VPN routes, relies on the > Ethernet > > >> >Tag field of the NLRI to encode the VNI/VSID. > > >> > > >> [JORGE] This is certainly a leftover from an old version > where the > > >> VNI/VSID was encoded in the ethernet tag for all the routes. > The VNI > > >> should be encoded in the Label field in all the routes. This > has to be corrected. > > >> > > >> In fact, section 5.1.3 says: > > >> > > >> 5.1.3 Constructing EVPN BGP Routes > > >> > > >> > > >> > > >> Accordingly, and > > >> specifically to support the option of locally assigned VNIs, > the MPLS > > >> label field in the MAC Advertisement, Ethernet AD per EVI, and > > >> Inclusive Multicast Ethernet Tag routes is used to carry the > VNI or > > >> VSID. For the balance of this memo, the MPLS label field will be > > >> referred to as the VNI/VSID field. The VNI/VSID field is used for > > >> both local and global VNIs/VSIDs, and for either case the > entire 24- > > >> bit field is used to encode the VNI/VSID value. > > >> > > >> > > > > > > > > >[JD] For the IMET route the MPLS label field is carried in the > PMSI attribute. I think we > > need to ask everyone whether they > > >used the Ethernet Tag or the PMSI attribute to carry the VNI > > > > > > > > >> >> > > >> >> There are minor things that could be improved in > > >> >> draft-ietf-bess-evpn-overlay wrt. consistency with > > >> >> draft-ietf-idr-tunnel-encaps : > > >> >> > > >> >> * since draft-ietf-idr-tunnel-encaps will deprecate > RFC5512, it > > >> >> would be better that draft-ietf-bess-evpn-overlay refers to > > >> >> draft-ietf-idr-tunnel-encaps and not anymore to RFC5512. > > >> > > >> [JORGE] I agree, as long as draft-ietf-idr-tunnel-encaps > keeps the > > >> encapsulation extended community. There are a few implementations > > >> using this community and it is enough when only the > encapsulation type is needed. > > > > > > > > >[JD] I agree and the tunnel encaps draft does keep the EC > > > > > > > > >> > > >> >> > > >> >> * I think it would be better to avoid the explicit list of > encap > > >> >> types in section 5.1.3, and rather refer to > > >> >> draft-ietf-idr-tunnel-encaps instead > > >> > > >> [JORGE] I agree. > > > > > > > > >[JD] According to IANA, it allocated the five tunnels types to the > > >overlay draft so I think we need to keep them > > > > > > > > >> > > >> >> * the following minor modification was proposed, but not > yet incorporated: > > >> >> > > >> >> John Drake, 2015-11-13 (to BESS ML): > > >> >>> For the overlay draft, replace this text in section 5.1.3: > > >> >>> > > >> >>> "If the BGP Encapsulation extended community is not present, > > >> >>> then the default MPLS encapsulation or a statically > configured > > >> >>> encapsulation is assumed." > > >> >>> > > >> >>> With the following: > > >> >>> > > >> >>> "Note that the MPLS encapsulation tunnel type is needed in > > >> >>> order to distinguish between an advertising node that only > > >> >>> supports non-MPLS encapsulations and one that supports > MPLS and > > >> >>> non-MPLS encapsulations. An advertising node that only > supports > > >> >>> MPLS encapsulation does not need to advertise any > encapsulation > > >> >>> tunnel types; i.e., if the BGP Encapsulation extended > community > > >> >>> is not present, then either MPLS encapsulation or a > statically > > >> >>> configured encapsulation is assumed." > > >> >> > > >> >> I think this change is useful and should be incorporated, > although > > >> >> skipping the last sentence would be wise if the full list of > > >> >> tunnel types is removed. > > > > > > > > >[JD] Fine with me either w/ or w/o the last sentence > > > > > > > --------------91EE4B3346D8F36A9C2C7D08 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit
John,

2016-05-18, John E Drake:
I spoke with Ali and he will reference the tunnel encapsulation draft rather than RFC 5512 but make it Informative.
I think this is in the spirit of what you proposed in your email, below.

Well, only for some definition of "in the spirit"... :-/

What I think we should do is normatively refer to draft-ietf-idr-tunnel-encaps and informatively refer to RFC5512, not the reverse.
Or else we end up with an RFC that soon after publication will normatively depend to an obsoleted RFC.

-Thomas


 

From: thomas.morin@orange.com [mailto:thomas.morin@orange.com]
Sent: Wednesday, May 18, 2016 6:19 AM
To: John E Drake; IDR; BESS; draft-ietf-bess-evpn-overlay@tools.ietf.org; Ali Sajassi (sajassi); Rabadan, Jorge (Nokia - US); draft-ietf-idr-tunnel-encap@tools.ietf.org
Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps

 

Hi John,

John.

When the tunnel encaps draft was first published it did not carry forward the RFC 5512 extended community and it did not propose to obsolete RFC 5512.  There was discussion of using the attribute defined in the tunnel encaps draft instead of the extended community and we decided to continue to use the extended community.  So, in that sense we are misaligned with the tunnel encaps draft.


As you confirm below, the last sentence is only true in the past tense.


Subsequently, however, the tunnel encaps draft decided to carry forward the extended community and to obsolete RFC 5512, so we were effectively covered by a grandfather clause.


Yes, precisely: given the content of the two drafts, there is no misalignment anymore.


Given the overlay draft’s tardiness, I don’t think that’s acceptable and would prefer to continue to refer to RFC 5512.


I do not think that the additional publication delay is a sound rationale for normatively refer to a spec that is known to become obsolete.
If it helps, the draft can keep an informative ref to RFC5512 and remind that it does not rely on anything specifically introduced by draft-ietf-idr-tunnel-encaps and not existing already in RFC5512.

-Thomas


2016-05-06, John E Drake:

 

However, even though I agreed yesterday to refer to the tunnel encaps draft instead of RFC 5512 we have an issue with doing this, viz, the overlay draft makes a normative reference to RFC 5512.  If we change the normative reference to the tunnel encaps draft we cannot publish the overlay draft until after the tunnel encaps draft has been published.

 

Given the overlay draft’s tardiness, I don’t think that’s acceptable and would prefer to continue to refer to RFC 5512.

 

Yours Irrespectively,

 

John

 

From: thomas.morin@orange.com [mailto:thomas.morin@orange.com]
Sent: Thursday, May 05, 2016 5:47 PM
To: IDR; BESS; draft-ietf-bess-evpn-overlay@tools.ietf.org; Ali Sajassi (sajassi); Rabadan, Jorge (Nokia - US); draft-ietf-idr-tunnel-encap@tools.ietf.org; John E Drake
Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps

 

Hi John,

I have a hard time reconciliating the fact that yesterday you were fine with having bess-evpn-overlay refer to idr-tunnel-encap instead of RFC5512, with the fact that you consider (below) the two docs "not aligned" for unicast.

Can you be more explicit in where the "misalignment" lies?

-Thomas

---- John E Drake a écrit ----

Thomas,

 

The overlay draft preceded the tunnel encaps draft and it was designed to handle a very specific problem, marrying the EVPN control plane to the VXLAN data plane draft and modulo the correction to section 9 it is internally consistent.

 

The tunnel encaps draft solves a more general problem and the WG decided a long time ago that the overlay draft was not going to be updated to use the mechanisms it details for unicast, so the overlay draft is already explicitly not in alignment with it.

 

This, plus the fact that the tunnel encaps draft explicitly puts the PMSI out of scope, leads me to the conclusion that the overlay draft should not be tweaked to be in alignment with a future solution for encoding VNIs for multicast.

 

Yours Irrespectively,

 

John

 

From: thomas.morin@orange.com [mailto:thomas.morin@orange.com]
Sent: Thursday, May 05, 2016 8:32 AM
To: John E Drake; IDR; BESS; draft-ietf-bess-evpn-overlay@tools.ietf.org; Ali Sajassi (sajassi); Rabadan, Jorge (Nokia - US); draft-ietf-idr-tunnel-encap@tools.ietf.org
Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps

 

Thanks for the clarification on the intent around draft-ietf-bess-evpn-overlay. Then indeed section 9 needs some tidying up.

The issue that I think remain is that it would be much cleaner to explain how to use PMSI with overlay encaps in a spec not specific to E-VPN and in a way more consistent to what is done for unicast.

It seems if course that draft-ietf-idr-tunnel-encap should be the place, but that document currently explicitly makes PMSIs out of scope.

Shouldn't this part of draft-ietf-idr-tunnel-encap be revisited ?

-Thomas


---- Rabadan, Jorge (Nokia - US) a écrit ----

Fully agree John. That's what I meant, sorry if I didn't make myself clear. Section 9 needs clean up, yes.

Thanks,
Jorge

 

_____________________________
From: EXT John E Drake <jdrake@juniper.net>
Sent: Wednesday, May 4, 2016 23:34
Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps
To: IDR <idr@ietf.org>, Ali Sajassi (sajassi) <sajassi@cisco.com>, Rabadan, Jorge (Nokia - US) <jorge.rabadan@alcatel-lucent.com>, BESS <bess@ietf.org>, <draft-ietf-bess-evpn-overlay@tools.ietf.org>, EXT - thomas.morin@orange.com <thomas.morin@orange.com>


Jorge,

We put the VNI value in the MPLS label field of the PMSI attribute for all service types, and we put a value in the Ethernet Tag field following the rules for each service type as described in 5.1.3 (https://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-02#section-5.1.3).

You're right that we need to clean up section 9.

Yours Irrespectively,

John

> -----Original Message-----
> From: Rabadan, Jorge (Nokia - US) [mailto:jorge.rabadan@nokia.com]
> Sent: Wednesday, May 04, 2016 3:53 PM
> To: John E Drake; EXT - thomas.morin@orange.com; BESS; IDR; draft-ietf-bess-evpn-
> overlay@tools.ietf.org; Ali Sajassi (sajassi)
> Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps
>
> Hi John,
>
> About this:
>
> [JD] For the IMET route the MPLS label field is carried in the PMSI attribute. I think we need
> to ask everyone whether they used the Ethernet Tag or the PMSI attribute to carry the VNI
>
>
> In case it helps, I’ve seen a few implementations running and they all encode the VNI in the
> MPLS label field in the PTA. And a couple of them, encode the VNI in the ethernet-tag, in
> addition to the MPLS label in the PTA. In any case, I think section 9 contradicts section 5.1.3
> and should be clarified.
>
> "5.1.3 Constructing EVPN BGP Routes
> <snip>
> the MPLS label field in the MAC Advertisement, Ethernet AD per EVI, and **Inclusive
> Multicast Ethernet Tag** routes is used to carry the VNI or VSID."
>
> Thanks.
> Jorge
>
>
>
>
>
> On 5/4/16, 8:34 PM, "EXT John E Drake" <jdrake@juniper.net> wrote:
>
> >Thomas and Jorge,
> >
> >Snipped, comments inline.
> >
> >Yours Irrespectively,
> >
> >John
> >
> >> >
> >> >draft-ietf-bess-evpn-overlay (see section 9) relies on the BGP
> >> >Encapsulation extended to encode the tunnel encap to use for BUM
> >> >traffic, but contrary to other E-VPN routes, relies on the Ethernet
> >> >Tag field of the NLRI to encode the VNI/VSID.
> >>
> >> [JORGE] This is certainly a leftover from an old version where the
> >> VNI/VSID was encoded in the ethernet tag for all the routes. The VNI
> >> should be encoded in the Label field in all the routes. This has to be corrected.
> >>
> >> In fact, section 5.1.3 says:
> >>
> >> 5.1.3 Constructing EVPN BGP Routes
> >>
> >> <snip>
> >>
> >> Accordingly, and
> >> specifically to support the option of locally assigned VNIs, the MPLS
> >> label field in the MAC Advertisement, Ethernet AD per EVI, and
> >> Inclusive Multicast Ethernet Tag routes is used to carry the VNI or
> >> VSID. For the balance of this memo, the MPLS label field will be
> >> referred to as the VNI/VSID field. The VNI/VSID field is used for
> >> both local and global VNIs/VSIDs, and for either case the entire 24-
> >> bit field is used to encode the VNI/VSID value.
> >>
> >> <snip>
> >
> >
> >[JD] For the IMET route the MPLS label field is carried in the PMSI attribute. I think we
> need to ask everyone whether they
> >used the Ethernet Tag or the PMSI attribute to carry the VNI
> >
> >
> >> >>
> >> >> There are minor things that could be improved in
> >> >> draft-ietf-bess-evpn-overlay wrt. consistency with
> >> >> draft-ietf-idr-tunnel-encaps :
> >> >>
> >> >> * since draft-ietf-idr-tunnel-encaps will deprecate RFC5512, it
> >> >> would be better that draft-ietf-bess-evpn-overlay refers to
> >> >> draft-ietf-idr-tunnel-encaps and not anymore to RFC5512.
> >>
> >> [JORGE] I agree, as long as draft-ietf-idr-tunnel-encaps keeps the
> >> encapsulation extended community. There are a few implementations
> >> using this community and it is enough when only the encapsulation type is needed.
> >
> >
> >[JD] I agree and the tunnel encaps draft does keep the EC
> >
> >
> >>
> >> >>
> >> >> * I think it would be better to avoid the explicit list of encap
> >> >> types in section 5.1.3, and rather refer to
> >> >> draft-ietf-idr-tunnel-encaps instead
> >>
> >> [JORGE] I agree.
> >
> >
> >[JD] According to IANA, it allocated the five tunnels types to the
> >overlay draft so I think we need to keep them
> >
> >
> >>
> >> >> * the following minor modification was proposed, but not yet incorporated:
> >> >>
> >> >> John Drake, 2015-11-13 (to BESS ML):
> >> >>> For the overlay draft, replace this text in section 5.1.3:
> >> >>>
> >> >>> "If the BGP Encapsulation extended community is not present,
> >> >>> then the default MPLS encapsulation or a statically configured
> >> >>> encapsulation is assumed."
> >> >>>
> >> >>> With the following:
> >> >>>
> >> >>> "Note that the MPLS encapsulation tunnel type is needed in
> >> >>> order to distinguish between an advertising node that only
> >> >>> supports non-MPLS encapsulations and one that supports MPLS and
> >> >>> non-MPLS encapsulations. An advertising node that only supports
> >> >>> MPLS encapsulation does not need to advertise any encapsulation
> >> >>> tunnel types; i.e., if the BGP Encapsulation extended community
> >> >>> is not present, then either MPLS encapsulation or a statically
> >> >>> configured encapsulation is assumed."
> >> >>
> >> >> I think this change is useful and should be incorporated, although
> >> >> skipping the last sentence would be wise if the full list of
> >> >> tunnel types is removed.
> >
> >
> >[JD] Fine with me either w/ or w/o the last sentence
> >
> >


--------------91EE4B3346D8F36A9C2C7D08-- From nobody Wed May 18 12:08:43 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 985FD12D64C; Wed, 18 May 2016 11:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IaXptZNUPeIN; Wed, 18 May 2016 11:55:14 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0782.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::782]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A8A312D641; Wed, 18 May 2016 11:55:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JIkdFbi8BtqW38jPJ8cx7/EVXdb+nJ5mQnPH6cbTkKg=; b=jlYQXsi3bzBGm2F2tXTQJ9EyBwWygFaozDShhcgwrUj5cGYK7WtuOwcaSj9o44Ut5kIZ/l/RxfBELGaqRqUPkYvmn72y1yUCoNOZBXLLsUUhbz8oBSqoTejs1fm6jH3q+K4jBuwbYChPp9sEe3BnkgNFeWyPxuWct0STvF4BBdE= Received: from SN1PR0501MB1709.namprd05.prod.outlook.com (10.163.130.155) by SN1PR0501MB2126.namprd05.prod.outlook.com (10.163.228.153) with Microsoft SMTP Server (TLS) id 15.1.497.12; Wed, 18 May 2016 18:54:55 +0000 Received: from SN1PR0501MB1709.namprd05.prod.outlook.com ([10.163.130.155]) by SN1PR0501MB1709.namprd05.prod.outlook.com ([10.163.130.155]) with mapi id 15.01.0492.020; Wed, 18 May 2016 18:54:54 +0000 From: John E Drake To: "EXT - thomas.morin@orange.com" , IDR , BESS , "draft-ietf-bess-evpn-overlay@tools.ietf.org" , "Ali Sajassi (sajassi)" , "Rabadan, Jorge (Nokia - US)" , "draft-ietf-idr-tunnel-encap@tools.ietf.org" Thread-Topic: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps Thread-Index: AQHRpi+6xGM0bynWeUeGN93K6stLXZ+pFtLwgAAZ14CAABtMwIAAAw6AgAD40oCAAALOkIAAmFwAgAAIznCAE6UwgIAAQX5QgAACs4CAAEmJYA== Date: Wed, 18 May 2016 18:54:54 +0000 Message-ID: References: <5729F1C3.1030605@orange.com> <5729F7C5.6040604@orange.com> <52D35106-ED5E-4C95-9131-6EA4527370D5@alcatel-lucent.com> <012C176C-A8D6-45AA-BA69-616C0ED7E41E@alcatel-lucent.com> <420BA2D8D80A6727.2B2C290F-2299-40BB-B53B-CC36D2B5D826@mail.outlook.com> <1881_1462451514_572B3D3A_1881_7198_1_0vn90oitr7e881gh2sn8qm5f.1462451509961@email.android.com> <17029_1462484835_572BBF63_17029_2323_1_opi9hqsl9b9tani0t0skkcuq.1462484831251@email.android.com> <28175_1463566739_573C4192_28175_2444_1_613f729b-d12e-5c48-29a1-ff000c1184a1@orange.com> <9ed4f1b1-1d84-2302-d7bb-5ad7fc42acdb@orange.com> In-Reply-To: <9ed4f1b1-1d84-2302-d7bb-5ad7fc42acdb@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.14] x-ms-office365-filtering-correlation-id: d81d749c-713f-4bbf-4604-08d37f4de697 x-microsoft-exchange-diagnostics: 1; SN1PR0501MB2126; 5:zb7mTEoP/kSj47Gxcn/Tb/GEtU9XS828Uo+LqT4PP/sPGL5tyPVohigykcBL3jxRDlYakXVPC2lSLR7GdFR5cHOjr4MTzTajoRYiCFxqrWuuY6bnMo976d/uCxGQcVkXpSQkHpGra0CBucdToWnW5w==; 24:3ViAE3xjPHjeHq0dOQE3utXi6HSPpbnUwoJcJtq+dfBGpNnPxg6Z6wYbkZMT1EsKKrzE56RYb68WwBfLRSkUUacYLrRlddJOYUZh3/MehoQ=; 7:/rRc0kMVaoM/MnIYULwKIRMPj0iO4ZzSHjQP4I6U3Mxb0jwf5In8nohJp/omdqr1ql/glv783cIl17Lddy+raatlhF1ionIT1GNjuODSWVHvWX4M4mzYb6TTOM12tDfaWH4obV6+dFinv9aNYnKmfEEvKb9CWH8Pnn4GVMK/GVI= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB2126; x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:SN1PR0501MB2126; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB2126; x-forefront-prvs: 0946DC87A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(78124002)(377454003)(377424004)(13464003)(51914003)(99286002)(230783001)(9686002)(189998001)(19580395003)(3280700002)(74316001)(33656002)(92566002)(2501003)(2950100001)(66066001)(5004730100002)(106116001)(16236675004)(8936002)(87936001)(102836003)(6116002)(790700001)(19625215002)(4001150100001)(50986999)(81166006)(86362001)(8676002)(19300405004)(1220700001)(3660700001)(5001770100001)(5008740100001)(5003600100002)(93886004)(586003)(5002640100001)(19580405001)(19617315012)(15975445007)(10400500002)(76576001)(76176999)(77096005)(54356999)(2906002)(4326007)(2900100001)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB2126; H:SN1PR0501MB1709.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_SN1PR0501MB1709067A4289CA9E8FAC6E61C7490SN1PR0501MB1709_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 18 May 2016 18:54:54.6004 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB2126 Archived-At: X-Mailman-Approved-At: Wed, 18 May 2016 12:08:41 -0700 Cc: Adrian Farrel , Alia Atlas Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 18:55:18 -0000 --_000_SN1PR0501MB1709067A4289CA9E8FAC6E61C7490SN1PR0501MB1709_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhvbWFzLA0KDQpJIGRpc2FncmVlLg0KDQpVbmxlc3MgYW5kIHVudGlsIEVyaWPigJlzIGRyYWZ0 IGlzIHB1Ymxpc2hlZCB0aGUgbm9ybWF0aXZlIHJlZmVyZW5jZSBpcyB0byBSRkMgNTUxMiBhbmQg bmVpdGhlciB5b3Ugbm9yIGFueW9uZSBlbHNlIGtub3dzIHdoZW4gb3IgaWYgRXJpY+KAmXMgZHJh ZnQgd2lsbCBiZSBwdWJsaXNoZWQgYXMgYW4gUkZDIGFuZCBJIHRoaW5rIGl0IGlzIGEgc2VyaW91 cyBicmVhY2ggb2YgcHJvY2VkdXJlIHRvIGhvbGQgdXAgdGhlIG92ZXJsYXkgZHJhZnQgYnkgYXNz ZXJ0aW5nIHlvdSBrbm93IHdoYXQgdGhlIGZ1dHVyZSBwb3J0ZW5kcy4NCg0KVGhpcyBpcyBub3Qg dGhlIGZpcnN0IHRpbWUgYW4gUkZDIG1hZGUgYSBub3JtYXRpdmUgcmVmZXJlbmNlIHRvIGFuIFJG QyB0aGF0IHN1YnNlcXVlbnRseSB3YXMgb2Jzb2xldGVkIGFuZCB0aGUgUkZDIHN5c3RlbSBkZWFs cyBxdWl0ZSBuaWNlbHkgd2l0aCB0aGlzIHNpdHVhdGlvbi4NCg0KWW91cnMgSXJyZXNwZWN0aXZl bHksDQoNCkpvaG4NCg0KRnJvbTogVGhvbWFzIE1vcmluIFttYWlsdG86dGhvbWFzLm1vcmluQG9y YW5nZS5jb21dDQpTZW50OiBXZWRuZXNkYXksIE1heSAxOCwgMjAxNiAxMDoyMyBBTQ0KVG86IEpv aG4gRSBEcmFrZTsgSURSOyBCRVNTOyBkcmFmdC1pZXRmLWJlc3MtZXZwbi1vdmVybGF5QHRvb2xz LmlldGYub3JnOyBBbGkgU2FqYXNzaSAoc2FqYXNzaSk7IFJhYmFkYW4sIEpvcmdlIChOb2tpYSAt IFVTKTsgZHJhZnQtaWV0Zi1pZHItdHVubmVsLWVuY2FwQHRvb2xzLmlldGYub3JnDQpTdWJqZWN0 OiBSZTogW0lkcl0gZHJhZnQtaWV0Zi1iZXNzLWV2cG4tb3ZlcmxheSB2cy4gZHJhZnQtaWV0Zi1p ZHItdHVubmVsLWVuY2Fwcw0KDQpKb2huLA0KDQoyMDE2LTA1LTE4LCBKb2huIEUgRHJha2U6DQpJ IHNwb2tlIHdpdGggQWxpIGFuZCBoZSB3aWxsIHJlZmVyZW5jZSB0aGUgdHVubmVsIGVuY2Fwc3Vs YXRpb24gZHJhZnQgcmF0aGVyIHRoYW4gUkZDIDU1MTIgYnV0IG1ha2UgaXQgSW5mb3JtYXRpdmUu DQpJIHRoaW5rIHRoaXMgaXMgaW4gdGhlIHNwaXJpdCBvZiB3aGF0IHlvdSBwcm9wb3NlZCBpbiB5 b3VyIGVtYWlsLCBiZWxvdy4NCg0KV2VsbCwgb25seSBmb3Igc29tZSBkZWZpbml0aW9uIG9mICJp biB0aGUgc3Bpcml0Ii4uLiA6LS8NCg0KV2hhdCBJIHRoaW5rIHdlIHNob3VsZCBkbyBpcyBub3Jt YXRpdmVseSByZWZlciB0byBkcmFmdC1pZXRmLWlkci10dW5uZWwtZW5jYXBzIGFuZCBpbmZvcm1h dGl2ZWx5IHJlZmVyIHRvIFJGQzU1MTIsIG5vdCB0aGUgcmV2ZXJzZS4NCk9yIGVsc2Ugd2UgZW5k IHVwIHdpdGggYW4gUkZDIHRoYXQgc29vbiBhZnRlciBwdWJsaWNhdGlvbiB3aWxsIG5vcm1hdGl2 ZWx5IGRlcGVuZCB0byBhbiBvYnNvbGV0ZWQgUkZDLg0KDQotVGhvbWFzDQoNCg0KDQoNCkZyb206 IHRob21hcy5tb3JpbkBvcmFuZ2UuY29tPG1haWx0bzp0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbT4g W21haWx0bzp0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgTWF5IDE4 LCAyMDE2IDY6MTkgQU0NClRvOiBKb2huIEUgRHJha2U7IElEUjsgQkVTUzsgZHJhZnQtaWV0Zi1i ZXNzLWV2cG4tb3ZlcmxheUB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1iZXNzLWV2 cG4tb3ZlcmxheUB0b29scy5pZXRmLm9yZz47IEFsaSBTYWphc3NpIChzYWphc3NpKTsgUmFiYWRh biwgSm9yZ2UgKE5va2lhIC0gVVMpOyBkcmFmdC1pZXRmLWlkci10dW5uZWwtZW5jYXBAdG9vbHMu aWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtaWRyLXR1bm5lbC1lbmNhcEB0b29scy5pZXRmLm9y Zz4NClN1YmplY3Q6IFJlOiBbSWRyXSBkcmFmdC1pZXRmLWJlc3MtZXZwbi1vdmVybGF5IHZzLiBk cmFmdC1pZXRmLWlkci10dW5uZWwtZW5jYXBzDQoNCkhpIEpvaG4sDQoNCkpvaG4uDQoNCg0KV2hl biB0aGUgdHVubmVsIGVuY2FwcyBkcmFmdCB3YXMgZmlyc3QgcHVibGlzaGVkIGl0IGRpZCBub3Qg Y2FycnkgZm9yd2FyZCB0aGUgUkZDIDU1MTIgZXh0ZW5kZWQgY29tbXVuaXR5IGFuZCBpdCBkaWQg bm90IHByb3Bvc2UgdG8gb2Jzb2xldGUgUkZDIDU1MTIuICBUaGVyZSB3YXMgZGlzY3Vzc2lvbiBv ZiB1c2luZyB0aGUgYXR0cmlidXRlIGRlZmluZWQgaW4gdGhlIHR1bm5lbCBlbmNhcHMgZHJhZnQg aW5zdGVhZCBvZiB0aGUgZXh0ZW5kZWQgY29tbXVuaXR5IGFuZCB3ZSBkZWNpZGVkIHRvIGNvbnRp bnVlIHRvIHVzZSB0aGUgZXh0ZW5kZWQgY29tbXVuaXR5LiAgU28sIGluIHRoYXQgc2Vuc2Ugd2Ug YXJlIG1pc2FsaWduZWQgd2l0aCB0aGUgdHVubmVsIGVuY2FwcyBkcmFmdC4NCg0KDQoNCkFzIHlv dSBjb25maXJtIGJlbG93LCB0aGUgbGFzdCBzZW50ZW5jZSBpcyBvbmx5IHRydWUgaW4gdGhlIHBh c3QgdGVuc2UuDQoNCg0KDQpTdWJzZXF1ZW50bHksIGhvd2V2ZXIsIHRoZSB0dW5uZWwgZW5jYXBz IGRyYWZ0IGRlY2lkZWQgdG8gY2FycnkgZm9yd2FyZCB0aGUgZXh0ZW5kZWQgY29tbXVuaXR5IGFu ZCB0byBvYnNvbGV0ZSBSRkMgNTUxMiwgc28gd2Ugd2VyZSBlZmZlY3RpdmVseSBjb3ZlcmVkIGJ5 IGEgZ3JhbmRmYXRoZXIgY2xhdXNlLg0KDQpZZXMsIHByZWNpc2VseTogZ2l2ZW4gdGhlIGNvbnRl bnQgb2YgdGhlIHR3byBkcmFmdHMsIHRoZXJlIGlzIG5vIG1pc2FsaWdubWVudCBhbnltb3JlLg0K DQoNCg0KR2l2ZW4gdGhlIG92ZXJsYXkgZHJhZnTigJlzIHRhcmRpbmVzcywgSSBkb27igJl0IHRo aW5rIHRoYXTigJlzIGFjY2VwdGFibGUgYW5kIHdvdWxkIHByZWZlciB0byBjb250aW51ZSB0byBy ZWZlciB0byBSRkMgNTUxMi4NCg0KSSBkbyBub3QgdGhpbmsgdGhhdCB0aGUgYWRkaXRpb25hbCBw dWJsaWNhdGlvbiBkZWxheSBpcyBhIHNvdW5kIHJhdGlvbmFsZSBmb3Igbm9ybWF0aXZlbHkgcmVm ZXIgdG8gYSBzcGVjIHRoYXQgaXMga25vd24gdG8gYmVjb21lIG9ic29sZXRlLg0KSWYgaXQgaGVs cHMsIHRoZSBkcmFmdCBjYW4ga2VlcCBhbiBpbmZvcm1hdGl2ZSByZWYgdG8gUkZDNTUxMiBhbmQg cmVtaW5kIHRoYXQgaXQgZG9lcyBub3QgcmVseSBvbiBhbnl0aGluZyBzcGVjaWZpY2FsbHkgaW50 cm9kdWNlZCBieSBkcmFmdC1pZXRmLWlkci10dW5uZWwtZW5jYXBzIGFuZCBub3QgZXhpc3Rpbmcg YWxyZWFkeSBpbiBSRkM1NTEyLg0KDQotVGhvbWFzDQoNCg0KMjAxNi0wNS0wNiwgSm9obiBFIERy YWtlOg0KDQpIb3dldmVyLCBldmVuIHRob3VnaCBJIGFncmVlZCB5ZXN0ZXJkYXkgdG8gcmVmZXIg dG8gdGhlIHR1bm5lbCBlbmNhcHMgZHJhZnQgaW5zdGVhZCBvZiBSRkMgNTUxMiB3ZSBoYXZlIGFu IGlzc3VlIHdpdGggZG9pbmcgdGhpcywgdml6LCB0aGUgb3ZlcmxheSBkcmFmdCBtYWtlcyBhIG5v cm1hdGl2ZSByZWZlcmVuY2UgdG8gUkZDIDU1MTIuICBJZiB3ZSBjaGFuZ2UgdGhlIG5vcm1hdGl2 ZSByZWZlcmVuY2UgdG8gdGhlIHR1bm5lbCBlbmNhcHMgZHJhZnQgd2UgY2Fubm90IHB1Ymxpc2gg dGhlIG92ZXJsYXkgZHJhZnQgdW50aWwgYWZ0ZXIgdGhlIHR1bm5lbCBlbmNhcHMgZHJhZnQgaGFz IGJlZW4gcHVibGlzaGVkLg0KDQpHaXZlbiB0aGUgb3ZlcmxheSBkcmFmdOKAmXMgdGFyZGluZXNz LCBJIGRvbuKAmXQgdGhpbmsgdGhhdOKAmXMgYWNjZXB0YWJsZSBhbmQgd291bGQgcHJlZmVyIHRv IGNvbnRpbnVlIHRvIHJlZmVyIHRvIFJGQyA1NTEyLg0KDQpZb3VycyBJcnJlc3BlY3RpdmVseSwN Cg0KSm9obg0KDQpGcm9tOiB0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbTxtYWlsdG86dGhvbWFzLm1v cmluQG9yYW5nZS5jb20+IFttYWlsdG86dGhvbWFzLm1vcmluQG9yYW5nZS5jb21dDQpTZW50OiBU aHVyc2RheSwgTWF5IDA1LCAyMDE2IDU6NDcgUE0NClRvOiBJRFI7IEJFU1M7IGRyYWZ0LWlldGYt YmVzcy1ldnBuLW92ZXJsYXlAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtYmVzcy1l dnBuLW92ZXJsYXlAdG9vbHMuaWV0Zi5vcmc+OyBBbGkgU2FqYXNzaSAoc2FqYXNzaSk7IFJhYmFk YW4sIEpvcmdlIChOb2tpYSAtIFVTKTsgZHJhZnQtaWV0Zi1pZHItdHVubmVsLWVuY2FwQHRvb2xz LmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWlkci10dW5uZWwtZW5jYXBAdG9vbHMuaWV0Zi5v cmc+OyBKb2huIEUgRHJha2UNClN1YmplY3Q6IFJFOiBbSWRyXSBkcmFmdC1pZXRmLWJlc3MtZXZw bi1vdmVybGF5IHZzLiBkcmFmdC1pZXRmLWlkci10dW5uZWwtZW5jYXBzDQoNCkhpIEpvaG4sDQoN CkkgaGF2ZSBhIGhhcmQgdGltZSByZWNvbmNpbGlhdGluZyB0aGUgZmFjdCB0aGF0IHllc3RlcmRh eSB5b3Ugd2VyZSBmaW5lIHdpdGggaGF2aW5nIGJlc3MtZXZwbi1vdmVybGF5IHJlZmVyIHRvIGlk ci10dW5uZWwtZW5jYXAgaW5zdGVhZCBvZiBSRkM1NTEyLCB3aXRoIHRoZSBmYWN0IHRoYXQgeW91 IGNvbnNpZGVyIChiZWxvdykgdGhlIHR3byBkb2NzICJub3QgYWxpZ25lZCIgZm9yIHVuaWNhc3Qu DQoNCkNhbiB5b3UgYmUgbW9yZSBleHBsaWNpdCBpbiB3aGVyZSB0aGUgIm1pc2FsaWdubWVudCIg bGllcz8NCg0KLVRob21hcw0KDQotLS0tIEpvaG4gRSBEcmFrZSBhIMOpY3JpdCAtLS0tDQpUaG9t YXMsDQoNClRoZSBvdmVybGF5IGRyYWZ0IHByZWNlZGVkIHRoZSB0dW5uZWwgZW5jYXBzIGRyYWZ0 IGFuZCBpdCB3YXMgZGVzaWduZWQgdG8gaGFuZGxlIGEgdmVyeSBzcGVjaWZpYyBwcm9ibGVtLCBt YXJyeWluZyB0aGUgRVZQTiBjb250cm9sIHBsYW5lIHRvIHRoZSBWWExBTiBkYXRhIHBsYW5lIGRy YWZ0IGFuZCBtb2R1bG8gdGhlIGNvcnJlY3Rpb24gdG8gc2VjdGlvbiA5IGl0IGlzIGludGVybmFs bHkgY29uc2lzdGVudC4NCg0KVGhlIHR1bm5lbCBlbmNhcHMgZHJhZnQgc29sdmVzIGEgbW9yZSBn ZW5lcmFsIHByb2JsZW0gYW5kIHRoZSBXRyBkZWNpZGVkIGEgbG9uZyB0aW1lIGFnbyB0aGF0IHRo ZSBvdmVybGF5IGRyYWZ0IHdhcyBub3QgZ29pbmcgdG8gYmUgdXBkYXRlZCB0byB1c2UgdGhlIG1l Y2hhbmlzbXMgaXQgZGV0YWlscyBmb3IgdW5pY2FzdCwgc28gdGhlIG92ZXJsYXkgZHJhZnQgaXMg YWxyZWFkeSBleHBsaWNpdGx5IG5vdCBpbiBhbGlnbm1lbnQgd2l0aCBpdC4NCg0KVGhpcywgcGx1 cyB0aGUgZmFjdCB0aGF0IHRoZSB0dW5uZWwgZW5jYXBzIGRyYWZ0IGV4cGxpY2l0bHkgcHV0cyB0 aGUgUE1TSSBvdXQgb2Ygc2NvcGUsIGxlYWRzIG1lIHRvIHRoZSBjb25jbHVzaW9uIHRoYXQgdGhl IG92ZXJsYXkgZHJhZnQgc2hvdWxkIG5vdCBiZSB0d2Vha2VkIHRvIGJlIGluIGFsaWdubWVudCB3 aXRoIGEgZnV0dXJlIHNvbHV0aW9uIGZvciBlbmNvZGluZyBWTklzIGZvciBtdWx0aWNhc3QuDQoN CllvdXJzIElycmVzcGVjdGl2ZWx5LA0KDQpKb2huDQoNCkZyb206IHRob21hcy5tb3JpbkBvcmFu Z2UuY29tPG1haWx0bzp0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbT4gW21haWx0bzp0aG9tYXMubW9y aW5Ab3JhbmdlLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBNYXkgMDUsIDIwMTYgODozMiBBTQ0KVG86 IEpvaG4gRSBEcmFrZTsgSURSOyBCRVNTOyBkcmFmdC1pZXRmLWJlc3MtZXZwbi1vdmVybGF5QHRv b2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWJlc3MtZXZwbi1vdmVybGF5QHRvb2xzLmll dGYub3JnPjsgQWxpIFNhamFzc2kgKHNhamFzc2kpOyBSYWJhZGFuLCBKb3JnZSAoTm9raWEgLSBV Uyk7IGRyYWZ0LWlldGYtaWRyLXR1bm5lbC1lbmNhcEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJh ZnQtaWV0Zi1pZHItdHVubmVsLWVuY2FwQHRvb2xzLmlldGYub3JnPg0KU3ViamVjdDogUkU6IFtJ ZHJdIGRyYWZ0LWlldGYtYmVzcy1ldnBuLW92ZXJsYXkgdnMuIGRyYWZ0LWlldGYtaWRyLXR1bm5l bC1lbmNhcHMNCg0KVGhhbmtzIGZvciB0aGUgY2xhcmlmaWNhdGlvbiBvbiB0aGUgaW50ZW50IGFy b3VuZCBkcmFmdC1pZXRmLWJlc3MtZXZwbi1vdmVybGF5LiBUaGVuIGluZGVlZCBzZWN0aW9uIDkg bmVlZHMgc29tZSB0aWR5aW5nIHVwLg0KDQpUaGUgaXNzdWUgdGhhdCBJIHRoaW5rIHJlbWFpbiBp cyB0aGF0IGl0IHdvdWxkIGJlIG11Y2ggY2xlYW5lciB0byBleHBsYWluIGhvdyB0byB1c2UgUE1T SSB3aXRoIG92ZXJsYXkgZW5jYXBzIGluIGEgc3BlYyBub3Qgc3BlY2lmaWMgdG8gRS1WUE4gYW5k IGluIGEgd2F5IG1vcmUgY29uc2lzdGVudCB0byB3aGF0IGlzIGRvbmUgZm9yIHVuaWNhc3QuDQoN Ckl0IHNlZW1zIGlmIGNvdXJzZSB0aGF0IGRyYWZ0LWlldGYtaWRyLXR1bm5lbC1lbmNhcCBzaG91 bGQgYmUgdGhlIHBsYWNlLCBidXQgdGhhdCBkb2N1bWVudCBjdXJyZW50bHkgZXhwbGljaXRseSBt YWtlcyBQTVNJcyBvdXQgb2Ygc2NvcGUuDQoNClNob3VsZG4ndCB0aGlzIHBhcnQgb2YgZHJhZnQt aWV0Zi1pZHItdHVubmVsLWVuY2FwIGJlIHJldmlzaXRlZCA/DQoNCi1UaG9tYXMNCg0KDQotLS0t IFJhYmFkYW4sIEpvcmdlIChOb2tpYSAtIFVTKSBhIMOpY3JpdCAtLS0tDQpGdWxseSBhZ3JlZSBK b2huLiBUaGF0J3Mgd2hhdCBJIG1lYW50LCBzb3JyeSBpZiBJIGRpZG4ndCBtYWtlIG15c2VsZiBj bGVhci4gU2VjdGlvbiA5IG5lZWRzIGNsZWFuIHVwLCB5ZXMuDQpUaGFua3MsDQpKb3JnZQ0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogRVhUIEpvaG4gRSBEcmFrZSA8amRy YWtlQGp1bmlwZXIubmV0PG1haWx0bzpqZHJha2VAanVuaXBlci5uZXQ+Pg0KU2VudDogV2VkbmVz ZGF5LCBNYXkgNCwgMjAxNiAyMzozNA0KU3ViamVjdDogUkU6IFtJZHJdIGRyYWZ0LWlldGYtYmVz cy1ldnBuLW92ZXJsYXkgdnMuIGRyYWZ0LWlldGYtaWRyLXR1bm5lbC1lbmNhcHMNClRvOiBJRFIg PGlkckBpZXRmLm9yZzxtYWlsdG86aWRyQGlldGYub3JnPj4sIEFsaSBTYWphc3NpIChzYWphc3Np KSA8c2FqYXNzaUBjaXNjby5jb208bWFpbHRvOnNhamFzc2lAY2lzY28uY29tPj4sIFJhYmFkYW4s IEpvcmdlIChOb2tpYSAtIFVTKSA8am9yZ2UucmFiYWRhbkBhbGNhdGVsLWx1Y2VudC5jb208bWFp bHRvOmpvcmdlLnJhYmFkYW5AYWxjYXRlbC1sdWNlbnQuY29tPj4sIEJFU1MgPGJlc3NAaWV0Zi5v cmc8bWFpbHRvOmJlc3NAaWV0Zi5vcmc+PiwgPGRyYWZ0LWlldGYtYmVzcy1ldnBuLW92ZXJsYXlA dG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtYmVzcy1ldnBuLW92ZXJsYXlAdG9vbHMu aWV0Zi5vcmc+PiwgRVhUIC0gdGhvbWFzLm1vcmluQG9yYW5nZS5jb208bWFpbHRvOnRob21hcy5t b3JpbkBvcmFuZ2UuY29tPiA8dGhvbWFzLm1vcmluQG9yYW5nZS5jb208bWFpbHRvOnRob21hcy5t b3JpbkBvcmFuZ2UuY29tPj4NCg0KDQpKb3JnZSwNCg0KV2UgcHV0IHRoZSBWTkkgdmFsdWUgaW4g dGhlIE1QTFMgbGFiZWwgZmllbGQgb2YgdGhlIFBNU0kgYXR0cmlidXRlIGZvciBhbGwgc2Vydmlj ZSB0eXBlcywgYW5kIHdlIHB1dCBhIHZhbHVlIGluIHRoZSBFdGhlcm5ldCBUYWcgZmllbGQgZm9s bG93aW5nIHRoZSBydWxlcyBmb3IgZWFjaCBzZXJ2aWNlIHR5cGUgYXMgZGVzY3JpYmVkIGluIDUu MS4zIChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1iZXNzLWV2cG4tb3Zl cmxheS0wMiNzZWN0aW9uLTUuMS4zKS4NCg0KWW91J3JlIHJpZ2h0IHRoYXQgd2UgbmVlZCB0byBj bGVhbiB1cCBzZWN0aW9uIDkuDQoNCllvdXJzIElycmVzcGVjdGl2ZWx5LA0KDQpKb2huDQoNCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUmFiYWRhbiwgSm9yZ2UgKE5va2lh IC0gVVMpIFttYWlsdG86am9yZ2UucmFiYWRhbkBub2tpYS5jb21dDQo+IFNlbnQ6IFdlZG5lc2Rh eSwgTWF5IDA0LCAyMDE2IDM6NTMgUE0NCj4gVG86IEpvaG4gRSBEcmFrZTsgRVhUIC0gdGhvbWFz Lm1vcmluQG9yYW5nZS5jb208bWFpbHRvOnRob21hcy5tb3JpbkBvcmFuZ2UuY29tPjsgQkVTUzsg SURSOyBkcmFmdC1pZXRmLWJlc3MtZXZwbi0NCj4gb3ZlcmxheUB0b29scy5pZXRmLm9yZzxtYWls dG86b3ZlcmxheUB0b29scy5pZXRmLm9yZz47IEFsaSBTYWphc3NpIChzYWphc3NpKQ0KPiBTdWJq ZWN0OiBSZTogW0lkcl0gZHJhZnQtaWV0Zi1iZXNzLWV2cG4tb3ZlcmxheSB2cy4gZHJhZnQtaWV0 Zi1pZHItdHVubmVsLWVuY2Fwcw0KPg0KPiBIaSBKb2huLA0KPg0KPiBBYm91dCB0aGlzOg0KPg0K PiBbSkRdIEZvciB0aGUgSU1FVCByb3V0ZSB0aGUgTVBMUyBsYWJlbCBmaWVsZCBpcyBjYXJyaWVk IGluIHRoZSBQTVNJIGF0dHJpYnV0ZS4gSSB0aGluayB3ZSBuZWVkDQo+IHRvIGFzayBldmVyeW9u ZSB3aGV0aGVyIHRoZXkgdXNlZCB0aGUgRXRoZXJuZXQgVGFnIG9yIHRoZSBQTVNJIGF0dHJpYnV0 ZSB0byBjYXJyeSB0aGUgVk5JDQo+DQo+DQo+IEluIGNhc2UgaXQgaGVscHMsIEnigJl2ZSBzZWVu IGEgZmV3IGltcGxlbWVudGF0aW9ucyBydW5uaW5nIGFuZCB0aGV5IGFsbCBlbmNvZGUgdGhlIFZO SSBpbiB0aGUNCj4gTVBMUyBsYWJlbCBmaWVsZCBpbiB0aGUgUFRBLiBBbmQgYSBjb3VwbGUgb2Yg dGhlbSwgZW5jb2RlIHRoZSBWTkkgaW4gdGhlIGV0aGVybmV0LXRhZywgaW4NCj4gYWRkaXRpb24g dG8gdGhlIE1QTFMgbGFiZWwgaW4gdGhlIFBUQS4gSW4gYW55IGNhc2UsIEkgdGhpbmsgc2VjdGlv biA5IGNvbnRyYWRpY3RzIHNlY3Rpb24gNS4xLjMNCj4gYW5kIHNob3VsZCBiZSBjbGFyaWZpZWQu DQo+DQo+ICI1LjEuMyBDb25zdHJ1Y3RpbmcgRVZQTiBCR1AgUm91dGVzDQo+IDxzbmlwPg0KPiB0 aGUgTVBMUyBsYWJlbCBmaWVsZCBpbiB0aGUgTUFDIEFkdmVydGlzZW1lbnQsIEV0aGVybmV0IEFE IHBlciBFVkksIGFuZCAqKkluY2x1c2l2ZQ0KPiBNdWx0aWNhc3QgRXRoZXJuZXQgVGFnKiogcm91 dGVzIGlzIHVzZWQgdG8gY2FycnkgdGhlIFZOSSBvciBWU0lELiINCj4NCj4gVGhhbmtzLg0KPiBK b3JnZQ0KPg0KPg0KPg0KPg0KPg0KPiBPbiA1LzQvMTYsIDg6MzQgUE0sICJFWFQgSm9obiBFIERy YWtlIiA8amRyYWtlQGp1bmlwZXIubmV0PG1haWx0bzpqZHJha2VAanVuaXBlci5uZXQ+PiB3cm90 ZToNCj4NCj4gPlRob21hcyBhbmQgSm9yZ2UsDQo+ID4NCj4gPlNuaXBwZWQsIGNvbW1lbnRzIGlu bGluZS4NCj4gPg0KPiA+WW91cnMgSXJyZXNwZWN0aXZlbHksDQo+ID4NCj4gPkpvaG4NCj4gPg0K PiA+PiA+DQo+ID4+ID5kcmFmdC1pZXRmLWJlc3MtZXZwbi1vdmVybGF5IChzZWUgc2VjdGlvbiA5 KSByZWxpZXMgb24gdGhlIEJHUA0KPiA+PiA+RW5jYXBzdWxhdGlvbiBleHRlbmRlZCB0byBlbmNv ZGUgdGhlIHR1bm5lbCBlbmNhcCB0byB1c2UgZm9yIEJVTQ0KPiA+PiA+dHJhZmZpYywgYnV0IGNv bnRyYXJ5IHRvIG90aGVyIEUtVlBOIHJvdXRlcywgcmVsaWVzIG9uIHRoZSBFdGhlcm5ldA0KPiA+ PiA+VGFnIGZpZWxkIG9mIHRoZSBOTFJJIHRvIGVuY29kZSB0aGUgVk5JL1ZTSUQuDQo+ID4+DQo+ ID4+IFtKT1JHRV0gVGhpcyBpcyBjZXJ0YWlubHkgYSBsZWZ0b3ZlciBmcm9tIGFuIG9sZCB2ZXJz aW9uIHdoZXJlIHRoZQ0KPiA+PiBWTkkvVlNJRCB3YXMgZW5jb2RlZCBpbiB0aGUgZXRoZXJuZXQg dGFnIGZvciBhbGwgdGhlIHJvdXRlcy4gVGhlIFZOSQ0KPiA+PiBzaG91bGQgYmUgZW5jb2RlZCBp biB0aGUgTGFiZWwgZmllbGQgaW4gYWxsIHRoZSByb3V0ZXMuIFRoaXMgaGFzIHRvIGJlIGNvcnJl Y3RlZC4NCj4gPj4NCj4gPj4gSW4gZmFjdCwgc2VjdGlvbiA1LjEuMyBzYXlzOg0KPiA+Pg0KPiA+ PiA1LjEuMyBDb25zdHJ1Y3RpbmcgRVZQTiBCR1AgUm91dGVzDQo+ID4+DQo+ID4+IDxzbmlwPg0K PiA+Pg0KPiA+PiBBY2NvcmRpbmdseSwgYW5kDQo+ID4+IHNwZWNpZmljYWxseSB0byBzdXBwb3J0 IHRoZSBvcHRpb24gb2YgbG9jYWxseSBhc3NpZ25lZCBWTklzLCB0aGUgTVBMUw0KPiA+PiBsYWJl bCBmaWVsZCBpbiB0aGUgTUFDIEFkdmVydGlzZW1lbnQsIEV0aGVybmV0IEFEIHBlciBFVkksIGFu ZA0KPiA+PiBJbmNsdXNpdmUgTXVsdGljYXN0IEV0aGVybmV0IFRhZyByb3V0ZXMgaXMgdXNlZCB0 byBjYXJyeSB0aGUgVk5JIG9yDQo+ID4+IFZTSUQuIEZvciB0aGUgYmFsYW5jZSBvZiB0aGlzIG1l bW8sIHRoZSBNUExTIGxhYmVsIGZpZWxkIHdpbGwgYmUNCj4gPj4gcmVmZXJyZWQgdG8gYXMgdGhl IFZOSS9WU0lEIGZpZWxkLiBUaGUgVk5JL1ZTSUQgZmllbGQgaXMgdXNlZCBmb3INCj4gPj4gYm90 aCBsb2NhbCBhbmQgZ2xvYmFsIFZOSXMvVlNJRHMsIGFuZCBmb3IgZWl0aGVyIGNhc2UgdGhlIGVu dGlyZSAyNC0NCj4gPj4gYml0IGZpZWxkIGlzIHVzZWQgdG8gZW5jb2RlIHRoZSBWTkkvVlNJRCB2 YWx1ZS4NCj4gPj4NCj4gPj4gPHNuaXA+DQo+ID4NCj4gPg0KPiA+W0pEXSBGb3IgdGhlIElNRVQg cm91dGUgdGhlIE1QTFMgbGFiZWwgZmllbGQgaXMgY2FycmllZCBpbiB0aGUgUE1TSSBhdHRyaWJ1 dGUuIEkgdGhpbmsgd2UNCj4gbmVlZCB0byBhc2sgZXZlcnlvbmUgd2hldGhlciB0aGV5DQo+ID51 c2VkIHRoZSBFdGhlcm5ldCBUYWcgb3IgdGhlIFBNU0kgYXR0cmlidXRlIHRvIGNhcnJ5IHRoZSBW TkkNCj4gPg0KPiA+DQo+ID4+ID4+DQo+ID4+ID4+IFRoZXJlIGFyZSBtaW5vciB0aGluZ3MgdGhh dCBjb3VsZCBiZSBpbXByb3ZlZCBpbg0KPiA+PiA+PiBkcmFmdC1pZXRmLWJlc3MtZXZwbi1vdmVy bGF5IHdydC4gY29uc2lzdGVuY3kgd2l0aA0KPiA+PiA+PiBkcmFmdC1pZXRmLWlkci10dW5uZWwt ZW5jYXBzIDoNCj4gPj4gPj4NCj4gPj4gPj4gKiBzaW5jZSBkcmFmdC1pZXRmLWlkci10dW5uZWwt ZW5jYXBzIHdpbGwgZGVwcmVjYXRlIFJGQzU1MTIsIGl0DQo+ID4+ID4+IHdvdWxkIGJlIGJldHRl ciB0aGF0IGRyYWZ0LWlldGYtYmVzcy1ldnBuLW92ZXJsYXkgcmVmZXJzIHRvDQo+ID4+ID4+IGRy YWZ0LWlldGYtaWRyLXR1bm5lbC1lbmNhcHMgYW5kIG5vdCBhbnltb3JlIHRvIFJGQzU1MTIuDQo+ ID4+DQo+ID4+IFtKT1JHRV0gSSBhZ3JlZSwgYXMgbG9uZyBhcyBkcmFmdC1pZXRmLWlkci10dW5u ZWwtZW5jYXBzIGtlZXBzIHRoZQ0KPiA+PiBlbmNhcHN1bGF0aW9uIGV4dGVuZGVkIGNvbW11bml0 eS4gVGhlcmUgYXJlIGEgZmV3IGltcGxlbWVudGF0aW9ucw0KPiA+PiB1c2luZyB0aGlzIGNvbW11 bml0eSBhbmQgaXQgaXMgZW5vdWdoIHdoZW4gb25seSB0aGUgZW5jYXBzdWxhdGlvbiB0eXBlIGlz IG5lZWRlZC4NCj4gPg0KPiA+DQo+ID5bSkRdIEkgYWdyZWUgYW5kIHRoZSB0dW5uZWwgZW5jYXBz IGRyYWZ0IGRvZXMga2VlcCB0aGUgRUMNCj4gPg0KPiA+DQo+ID4+DQo+ID4+ID4+DQo+ID4+ID4+ ICogSSB0aGluayBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gYXZvaWQgdGhlIGV4cGxpY2l0IGxpc3Qg b2YgZW5jYXANCj4gPj4gPj4gdHlwZXMgaW4gc2VjdGlvbiA1LjEuMywgYW5kIHJhdGhlciByZWZl ciB0bw0KPiA+PiA+PiBkcmFmdC1pZXRmLWlkci10dW5uZWwtZW5jYXBzIGluc3RlYWQNCj4gPj4N Cj4gPj4gW0pPUkdFXSBJIGFncmVlLg0KPiA+DQo+ID4NCj4gPltKRF0gQWNjb3JkaW5nIHRvIElB TkEsIGl0IGFsbG9jYXRlZCB0aGUgZml2ZSB0dW5uZWxzIHR5cGVzIHRvIHRoZQ0KPiA+b3Zlcmxh eSBkcmFmdCBzbyBJIHRoaW5rIHdlIG5lZWQgdG8ga2VlcCB0aGVtDQo+ID4NCj4gPg0KPiA+Pg0K PiA+PiA+PiAqIHRoZSBmb2xsb3dpbmcgbWlub3IgbW9kaWZpY2F0aW9uIHdhcyBwcm9wb3NlZCwg YnV0IG5vdCB5ZXQgaW5jb3Jwb3JhdGVkOg0KPiA+PiA+Pg0KPiA+PiA+PiBKb2huIERyYWtlLCAy MDE1LTExLTEzICh0byBCRVNTIE1MKToNCj4gPj4gPj4+IEZvciB0aGUgb3ZlcmxheSBkcmFmdCwg cmVwbGFjZSB0aGlzIHRleHQgaW4gc2VjdGlvbiA1LjEuMzoNCj4gPj4gPj4+DQo+ID4+ID4+PiAi SWYgdGhlIEJHUCBFbmNhcHN1bGF0aW9uIGV4dGVuZGVkIGNvbW11bml0eSBpcyBub3QgcHJlc2Vu dCwNCj4gPj4gPj4+IHRoZW4gdGhlIGRlZmF1bHQgTVBMUyBlbmNhcHN1bGF0aW9uIG9yIGEgc3Rh dGljYWxseSBjb25maWd1cmVkDQo+ID4+ID4+PiBlbmNhcHN1bGF0aW9uIGlzIGFzc3VtZWQuIg0K PiA+PiA+Pj4NCj4gPj4gPj4+IFdpdGggdGhlIGZvbGxvd2luZzoNCj4gPj4gPj4+DQo+ID4+ID4+ PiAiTm90ZSB0aGF0IHRoZSBNUExTIGVuY2Fwc3VsYXRpb24gdHVubmVsIHR5cGUgaXMgbmVlZGVk IGluDQo+ID4+ID4+PiBvcmRlciB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuIGFuIGFkdmVydGlzaW5n IG5vZGUgdGhhdCBvbmx5DQo+ID4+ID4+PiBzdXBwb3J0cyBub24tTVBMUyBlbmNhcHN1bGF0aW9u cyBhbmQgb25lIHRoYXQgc3VwcG9ydHMgTVBMUyBhbmQNCj4gPj4gPj4+IG5vbi1NUExTIGVuY2Fw c3VsYXRpb25zLiBBbiBhZHZlcnRpc2luZyBub2RlIHRoYXQgb25seSBzdXBwb3J0cw0KPiA+PiA+ Pj4gTVBMUyBlbmNhcHN1bGF0aW9uIGRvZXMgbm90IG5lZWQgdG8gYWR2ZXJ0aXNlIGFueSBlbmNh cHN1bGF0aW9uDQo+ID4+ID4+PiB0dW5uZWwgdHlwZXM7IGkuZS4sIGlmIHRoZSBCR1AgRW5jYXBz dWxhdGlvbiBleHRlbmRlZCBjb21tdW5pdHkNCj4gPj4gPj4+IGlzIG5vdCBwcmVzZW50LCB0aGVu IGVpdGhlciBNUExTIGVuY2Fwc3VsYXRpb24gb3IgYSBzdGF0aWNhbGx5DQo+ID4+ID4+PiBjb25m aWd1cmVkIGVuY2Fwc3VsYXRpb24gaXMgYXNzdW1lZC4iDQo+ID4+ID4+DQo+ID4+ID4+IEkgdGhp bmsgdGhpcyBjaGFuZ2UgaXMgdXNlZnVsIGFuZCBzaG91bGQgYmUgaW5jb3Jwb3JhdGVkLCBhbHRo b3VnaA0KPiA+PiA+PiBza2lwcGluZyB0aGUgbGFzdCBzZW50ZW5jZSB3b3VsZCBiZSB3aXNlIGlm IHRoZSBmdWxsIGxpc3Qgb2YNCj4gPj4gPj4gdHVubmVsIHR5cGVzIGlzIHJlbW92ZWQuDQo+ID4N Cj4gPg0KPiA+W0pEXSBGaW5lIHdpdGggbWUgZWl0aGVyIHcvIG9yIHcvbyB0aGUgbGFzdCBzZW50 ZW5jZQ0KPiA+DQo+ID4NCg0K --_000_SN1PR0501MB1709067A4289CA9E8FAC6E61C7490SN1PR0501MB1709_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsN Cgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1u YW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xh czt9DQpwLm1zb2NocGRlZmF1bHQsIGxpLm1zb2NocGRlZmF1bHQsIGRpdi5tc29jaHBkZWZhdWx0 DQoJe21zby1zdHlsZS1uYW1lOm1zb2NocGRlZmF1bHQ7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCglt YXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjsNCgljb2xvcjpibGFjazt9DQpzcGFuLmh0bWxwcmVmb3JtYXR0ZWRj aGFyMA0KCXttc28tc3R5bGUtbmFtZTpodG1scHJlZm9ybWF0dGVkY2hhcjsNCglmb250LWZhbWls eTpDb25zb2xhczt9DQpzcGFuLmVtYWlsc3R5bGUxOQ0KCXttc28tc3R5bGUtbmFtZTplbWFpbHN0 eWxlMTk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1h aWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaG9tYXMsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGRpc2FncmVlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+VW5sZXNzIGFuZCB1bnRpbCBFcmlj4oCZcyBkcmFmdCBpcyBw dWJsaXNoZWQgdGhlIG5vcm1hdGl2ZSByZWZlcmVuY2UgaXMgdG8gUkZDIDU1MTIgYW5kIG5laXRo ZXIgeW91IG5vciBhbnlvbmUgZWxzZSBrbm93cyB3aGVuIG9yIGlmIEVyaWPigJlzIGRyYWZ0IHdp bGwgYmUgcHVibGlzaGVkDQogYXMgYW4gUkZDIGFuZCBJIHRoaW5rIGl0IGlzIGEgc2VyaW91cyBi cmVhY2ggb2YgcHJvY2VkdXJlIHRvIGhvbGQgdXAgdGhlIG92ZXJsYXkgZHJhZnQgYnkgYXNzZXJ0 aW5nIHlvdSBrbm93IHdoYXQgdGhlIGZ1dHVyZSBwb3J0ZW5kcy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoaXMgaXMgbm90IHRoZSBmaXJzdCB0aW1lIGFuIFJG QyBtYWRlIGEgbm9ybWF0aXZlIHJlZmVyZW5jZSB0byBhbiBSRkMgdGhhdCBzdWJzZXF1ZW50bHkg d2FzIG9ic29sZXRlZCBhbmQgdGhlIFJGQyBzeXN0ZW0gZGVhbHMgcXVpdGUgbmljZWx5IHdpdGgg dGhpcyBzaXR1YXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+WW91cnMgSXJyZXNwZWN0aXZlbHksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5Kb2huPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjp3aW5kb3d0ZXh0Ij4gVGhvbWFzIE1vcmluIFttYWlsdG86dGhvbWFzLm1vcmluQG9yYW5n ZS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBNYXkgMTgsIDIwMTYgMTA6MjMg QU08YnI+DQo8Yj5Ubzo8L2I+IEpvaG4gRSBEcmFrZTsgSURSOyBCRVNTOyBkcmFmdC1pZXRmLWJl c3MtZXZwbi1vdmVybGF5QHRvb2xzLmlldGYub3JnOyBBbGkgU2FqYXNzaSAoc2FqYXNzaSk7IFJh YmFkYW4sIEpvcmdlIChOb2tpYSAtIFVTKTsgZHJhZnQtaWV0Zi1pZHItdHVubmVsLWVuY2FwQHRv b2xzLmlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbSWRyXSBkcmFmdC1pZXRmLWJl c3MtZXZwbi1vdmVybGF5IHZzLiBkcmFmdC1pZXRmLWlkci10dW5uZWwtZW5jYXBzPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpvaG4sPGJyPg0K PGJyPg0KMjAxNi0wNS0xOCwgSm9obiBFIERyYWtlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIHNw b2tlIHdpdGggQWxpIGFuZCBoZSB3aWxsIHJlZmVyZW5jZSB0aGUgdHVubmVsIGVuY2Fwc3VsYXRp b24gZHJhZnQgcmF0aGVyIHRoYW4gUkZDIDU1MTIgYnV0IG1ha2UgaXQgSW5mb3JtYXRpdmUuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSB0aGluayB0aGlzIGlzIGluIHRoZSBz cGlyaXQgb2Ygd2hhdCB5b3UgcHJvcG9zZWQgaW4geW91ciBlbWFpbCwgYmVsb3cuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0K V2VsbCwgb25seSBmb3Igc29tZSBkZWZpbml0aW9uIG9mICZxdW90O2luIHRoZSBzcGlyaXQmcXVv dDsuLi4gOi0vPGJyPg0KPGJyPg0KV2hhdCBJIHRoaW5rIHdlIHNob3VsZCBkbyBpcyBub3JtYXRp dmVseSByZWZlciB0byBkcmFmdC1pZXRmLWlkci10dW5uZWwtZW5jYXBzIGFuZCBpbmZvcm1hdGl2 ZWx5IHJlZmVyIHRvIFJGQzU1MTIsIG5vdCB0aGUgcmV2ZXJzZS48YnI+DQpPciBlbHNlIHdlIGVu ZCB1cCB3aXRoIGFuIFJGQyB0aGF0IHNvb24gYWZ0ZXIgcHVibGljYXRpb24gd2lsbCBub3JtYXRp dmVseSBkZXBlbmQgdG8gYW4gb2Jzb2xldGVkIFJGQy48YnI+DQo8YnI+DQotVGhvbWFzPGJyPg0K PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+DQo8bzpwPjwvbzpw PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41 cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndp bmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4 dCI+DQo8YSBocmVmPSJtYWlsdG86dGhvbWFzLm1vcmluQG9yYW5nZS5jb20iPnRob21hcy5tb3Jp bkBvcmFuZ2UuY29tPC9hPiBbPGEgaHJlZj0ibWFpbHRvOnRob21hcy5tb3JpbkBvcmFuZ2UuY29t Ij5tYWlsdG86dGhvbWFzLm1vcmluQG9yYW5nZS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+ IFdlZG5lc2RheSwgTWF5IDE4LCAyMDE2IDY6MTkgQU08YnI+DQo8Yj5Ubzo8L2I+IEpvaG4gRSBE cmFrZTsgSURSOyBCRVNTOyA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1iZXNzLWV2cG4tb3Zl cmxheUB0b29scy5pZXRmLm9yZyI+DQpkcmFmdC1pZXRmLWJlc3MtZXZwbi1vdmVybGF5QHRvb2xz LmlldGYub3JnPC9hPjsgQWxpIFNhamFzc2kgKHNhamFzc2kpOyBSYWJhZGFuLCBKb3JnZSAoTm9r aWEgLSBVUyk7DQo8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1pZHItdHVubmVsLWVuY2FwQHRv b2xzLmlldGYub3JnIj5kcmFmdC1pZXRmLWlkci10dW5uZWwtZW5jYXBAdG9vbHMuaWV0Zi5vcmc8 L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbSWRyXSBkcmFmdC1pZXRmLWJlc3MtZXZwbi1v dmVybGF5IHZzLiBkcmFmdC1pZXRmLWlkci10dW5uZWwtZW5jYXBzPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEpvaG4sPGJyPg0KPGJyPg0K Sm9obi48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPldoZW4gdGhlIHR1bm5lbCBlbmNh cHMgZHJhZnQgd2FzIGZpcnN0IHB1Ymxpc2hlZCBpdCBkaWQgbm90IGNhcnJ5IGZvcndhcmQgdGhl IFJGQyA1NTEyIGV4dGVuZGVkIGNvbW11bml0eSBhbmQgaXQgZGlkIG5vdCBwcm9wb3NlIHRvIG9i c29sZXRlIFJGQyA1NTEyLiZuYnNwOyBUaGVyZQ0KIHdhcyBkaXNjdXNzaW9uIG9mIHVzaW5nIHRo ZSBhdHRyaWJ1dGUgZGVmaW5lZCBpbiB0aGUgdHVubmVsIGVuY2FwcyBkcmFmdCBpbnN0ZWFkIG9m IHRoZSBleHRlbmRlZCBjb21tdW5pdHkgYW5kIHdlIGRlY2lkZWQgdG8gY29udGludWUgdG8gdXNl IHRoZSBleHRlbmRlZCBjb21tdW5pdHkuJm5ic3A7IFNvLCBpbiB0aGF0IHNlbnNlIHdlIGFyZSBt aXNhbGlnbmVkIHdpdGggdGhlIHR1bm5lbCBlbmNhcHMgZHJhZnQuDQo8YnI+DQo8YnI+DQo8YnI+ DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YnI+DQpBcyB5b3UgY29uZmlybSBiZWxvdywgdGhlIGxhc3Qgc2VudGVuY2UgaXMgb25s eSB0cnVlIGluIHRoZSBwYXN0IHRlbnNlLjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9v OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5TdWJzZXF1ZW50bHksIGhvd2V2ZXIsIHRoZSB0dW5uZWwgZW5jYXBzIGRyYWZ0IGRl Y2lkZWQgdG8gY2FycnkgZm9yd2FyZCB0aGUgZXh0ZW5kZWQgY29tbXVuaXR5IGFuZA0KIHRvIG9i c29sZXRlIFJGQyA1NTEyLCBzbyB3ZSB3ZXJlIGVmZmVjdGl2ZWx5IGNvdmVyZWQgYnkgYSBncmFu ZGZhdGhlciBjbGF1c2UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KWWVzLCBwcmVjaXNlbHk6IGdpdmVuIHRoZSBjb250ZW50 IG9mIHRoZSB0d28gZHJhZnRzLCB0aGVyZSBpcyBubyBtaXNhbGlnbm1lbnQgYW55bW9yZS48YnI+ DQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+R2l2ZW4gdGhlIG92ZXJsYXkgZHJh ZnTigJlzIHRhcmRpbmVzcywgSSBkb27igJl0IHRoaW5rIHRoYXTigJlzIGFjY2VwdGFibGUgYW5k IHdvdWxkIHByZWZlciB0byBjb250aW51ZSB0bw0KIHJlZmVyIHRvIFJGQyA1NTEyLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4N CkkgZG8gbm90IHRoaW5rIHRoYXQgdGhlIGFkZGl0aW9uYWwgcHVibGljYXRpb24gZGVsYXkgaXMg YSBzb3VuZCByYXRpb25hbGUgZm9yIG5vcm1hdGl2ZWx5IHJlZmVyIHRvIGEgc3BlYyB0aGF0IGlz IGtub3duIHRvIGJlY29tZSBvYnNvbGV0ZS48YnI+DQpJZiBpdCBoZWxwcywgdGhlIGRyYWZ0IGNh biBrZWVwIGFuIGluZm9ybWF0aXZlIHJlZiB0byBSRkM1NTEyIGFuZCByZW1pbmQgdGhhdCBpdCBk b2VzIG5vdCByZWx5IG9uIGFueXRoaW5nIHNwZWNpZmljYWxseSBpbnRyb2R1Y2VkIGJ5IGRyYWZ0 LWlldGYtaWRyLXR1bm5lbC1lbmNhcHMgYW5kIG5vdCBleGlzdGluZyBhbHJlYWR5IGluIFJGQzU1 MTIuPGJyPg0KPGJyPg0KLVRob21hczxicj4NCjxicj4NCjxicj4NCjIwMTYtMDUtMDYsIEpvaG4g RSBEcmFrZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPg0KPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ SG93ZXZlciwgZXZlbiB0aG91Z2ggSSBhZ3JlZWQgeWVzdGVyZGF5IHRvIHJlZmVyIHRvIHRoZSB0 dW5uZWwgZW5jYXBzIGRyYWZ0IGluc3RlYWQgb2YgUkZDIDU1MTIgd2UgaGF2ZSBhbiBpc3N1ZSB3 aXRoIGRvaW5nIHRoaXMsIHZpeiwgdGhlIG92ZXJsYXkgZHJhZnQgbWFrZXMNCiBhIG5vcm1hdGl2 ZSByZWZlcmVuY2UgdG8gUkZDIDU1MTIuJm5ic3A7IElmIHdlIGNoYW5nZSB0aGUgbm9ybWF0aXZl IHJlZmVyZW5jZSB0byB0aGUgdHVubmVsIGVuY2FwcyBkcmFmdCB3ZSBjYW5ub3QgcHVibGlzaCB0 aGUgb3ZlcmxheSBkcmFmdCB1bnRpbCBhZnRlciB0aGUgdHVubmVsIGVuY2FwcyBkcmFmdCBoYXMg YmVlbiBwdWJsaXNoZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5HaXZlbiB0aGUgb3ZlcmxheSBkcmFmdOKAmXMgdGFyZGluZXNzLCBJIGRvbuKAmXQgdGhpbmsg dGhhdOKAmXMgYWNjZXB0YWJsZSBhbmQgd291bGQgcHJlZmVyIHRvIGNvbnRpbnVlIHRvIHJlZmVy IHRvIFJGQyA1NTEyLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPllvdXJzIElycmVzcGVjdGl2ZWx5LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+Sm9objwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4NCjxhIGhyZWY9Im1haWx0bzp0 aG9tYXMubW9yaW5Ab3JhbmdlLmNvbSI+dGhvbWFzLm1vcmluQG9yYW5nZS5jb208L2E+IFs8YSBo cmVmPSJtYWlsdG86dGhvbWFzLm1vcmluQG9yYW5nZS5jb20iPm1haWx0bzp0aG9tYXMubW9yaW5A b3JhbmdlLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE1heSAwNSwgMjAx NiA1OjQ3IFBNPGJyPg0KPGI+VG86PC9iPiBJRFI7IEJFU1M7IDxhIGhyZWY9Im1haWx0bzpkcmFm dC1pZXRmLWJlc3MtZXZwbi1vdmVybGF5QHRvb2xzLmlldGYub3JnIj4NCmRyYWZ0LWlldGYtYmVz cy1ldnBuLW92ZXJsYXlAdG9vbHMuaWV0Zi5vcmc8L2E+OyBBbGkgU2FqYXNzaSAoc2FqYXNzaSk7 IFJhYmFkYW4sIEpvcmdlIChOb2tpYSAtIFVTKTsNCjxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRm LWlkci10dW5uZWwtZW5jYXBAdG9vbHMuaWV0Zi5vcmciPmRyYWZ0LWlldGYtaWRyLXR1bm5lbC1l bmNhcEB0b29scy5pZXRmLm9yZzwvYT47IEpvaG4gRSBEcmFrZTxicj4NCjxiPlN1YmplY3Q6PC9i PiBSRTogW0lkcl0gZHJhZnQtaWV0Zi1iZXNzLWV2cG4tb3ZlcmxheSB2cy4gZHJhZnQtaWV0Zi1p ZHItdHVubmVsLWVuY2Fwczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SGkgSm9obiwgPGJyPg0KPGJyPg0K SSBoYXZlIGEgaGFyZCB0aW1lIHJlY29uY2lsaWF0aW5nIHRoZSBmYWN0IHRoYXQgeWVzdGVyZGF5 IHlvdSB3ZXJlIGZpbmUgd2l0aCBoYXZpbmcgYmVzcy1ldnBuLW92ZXJsYXkgcmVmZXIgdG8gaWRy LXR1bm5lbC1lbmNhcCBpbnN0ZWFkIG9mIFJGQzU1MTIsIHdpdGggdGhlIGZhY3QgdGhhdCB5b3Ug Y29uc2lkZXIgKGJlbG93KSB0aGUgdHdvIGRvY3MgJnF1b3Q7bm90IGFsaWduZWQmcXVvdDsgZm9y IHVuaWNhc3QuPGJyPg0KPGJyPg0KQ2FuIHlvdSBiZSBtb3JlIGV4cGxpY2l0IGluIHdoZXJlIHRo ZSAmcXVvdDttaXNhbGlnbm1lbnQmcXVvdDsgbGllcz8gPGJyPg0KPGJyPg0KLVRob21hczxicj4N Cjxicj4NCi0tLS0gSm9obiBFIERyYWtlIGEgw6ljcml0IC0tLS08bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPlRob21hcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PlRoZSBvdmVybGF5IGRyYWZ0IHByZWNlZGVkIHRoZSB0dW5uZWwgZW5jYXBzIGRyYWZ0IGFuZCBp dCB3YXMgZGVzaWduZWQgdG8gaGFuZGxlIGEgdmVyeSBzcGVjaWZpYyBwcm9ibGVtLCBtYXJyeWlu ZyB0aGUgRVZQTiBjb250cm9sIHBsYW5lIHRvIHRoZSBWWExBTiBkYXRhIHBsYW5lDQogZHJhZnQg YW5kIG1vZHVsbyB0aGUgY29ycmVjdGlvbiB0byBzZWN0aW9uIDkgaXQgaXMgaW50ZXJuYWxseSBj b25zaXN0ZW50Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhl IHR1bm5lbCBlbmNhcHMgZHJhZnQgc29sdmVzIGEgbW9yZSBnZW5lcmFsIHByb2JsZW0gYW5kIHRo ZSBXRyBkZWNpZGVkIGEgbG9uZyB0aW1lIGFnbyB0aGF0IHRoZSBvdmVybGF5IGRyYWZ0IHdhcyBu b3QgZ29pbmcgdG8gYmUgdXBkYXRlZCB0byB1c2UgdGhlIG1lY2hhbmlzbXMNCiBpdCBkZXRhaWxz IGZvciB1bmljYXN0LCBzbyB0aGUgb3ZlcmxheSBkcmFmdCBpcyBhbHJlYWR5IGV4cGxpY2l0bHkg bm90IGluIGFsaWdubWVudCB3aXRoIGl0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+VGhpcywgcGx1cyB0aGUgZmFjdCB0aGF0IHRoZSB0dW5uZWwgZW5jYXBzIGRy YWZ0IGV4cGxpY2l0bHkgcHV0cyB0aGUgUE1TSSBvdXQgb2Ygc2NvcGUsIGxlYWRzIG1lIHRvIHRo ZSBjb25jbHVzaW9uIHRoYXQgdGhlIG92ZXJsYXkgZHJhZnQgc2hvdWxkIG5vdCBiZSB0d2Vha2Vk DQogdG8gYmUgaW4gYWxpZ25tZW50IHdpdGggYSBmdXR1cmUgc29sdXRpb24gZm9yIGVuY29kaW5n IFZOSXMgZm9yIG11bHRpY2FzdC4gPC9zcGFuPg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5Zb3VycyBJcnJlc3BlY3RpdmVseSw8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkpvaG48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+DQo8YSBocmVm PSJtYWlsdG86dGhvbWFzLm1vcmluQG9yYW5nZS5jb20iPnRob21hcy5tb3JpbkBvcmFuZ2UuY29t PC9hPiBbPGEgaHJlZj0ibWFpbHRvOnRob21hcy5tb3JpbkBvcmFuZ2UuY29tIj5tYWlsdG86dGhv bWFzLm1vcmluQG9yYW5nZS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBN YXkgMDUsIDIwMTYgODozMiBBTTxicj4NCjxiPlRvOjwvYj4gSm9obiBFIERyYWtlOyBJRFI7IEJF U1M7IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLWJlc3MtZXZwbi1vdmVybGF5QHRvb2xzLmll dGYub3JnIj4NCmRyYWZ0LWlldGYtYmVzcy1ldnBuLW92ZXJsYXlAdG9vbHMuaWV0Zi5vcmc8L2E+ OyBBbGkgU2FqYXNzaSAoc2FqYXNzaSk7IFJhYmFkYW4sIEpvcmdlIChOb2tpYSAtIFVTKTsNCjxh IGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLWlkci10dW5uZWwtZW5jYXBAdG9vbHMuaWV0Zi5vcmci PmRyYWZ0LWlldGYtaWRyLXR1bm5lbC1lbmNhcEB0b29scy5pZXRmLm9yZzwvYT48YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUkU6IFtJZHJdIGRyYWZ0LWlldGYtYmVzcy1ldnBuLW92ZXJsYXkgdnMuIGRy YWZ0LWlldGYtaWRyLXR1bm5lbC1lbmNhcHM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlRoYW5rcyBmb3Ig dGhlIGNsYXJpZmljYXRpb24gb24gdGhlIGludGVudCBhcm91bmQgZHJhZnQtaWV0Zi1iZXNzLWV2 cG4tb3ZlcmxheS4gVGhlbiBpbmRlZWQgc2VjdGlvbiA5IG5lZWRzIHNvbWUgdGlkeWluZyB1cC4N Cjxicj4NCjxicj4NClRoZSBpc3N1ZSB0aGF0IEkgdGhpbmsgcmVtYWluIGlzIHRoYXQgaXQgd291 bGQgYmUgbXVjaCBjbGVhbmVyIHRvIGV4cGxhaW4gaG93IHRvIHVzZSBQTVNJIHdpdGggb3Zlcmxh eSBlbmNhcHMgaW4gYSBzcGVjIG5vdCBzcGVjaWZpYyB0byBFLVZQTiBhbmQgaW4gYSB3YXkgbW9y ZSBjb25zaXN0ZW50IHRvIHdoYXQgaXMgZG9uZSBmb3IgdW5pY2FzdC4NCjxicj4NCjxicj4NCkl0 IHNlZW1zIGlmIGNvdXJzZSB0aGF0IGRyYWZ0LWlldGYtaWRyLXR1bm5lbC1lbmNhcCBzaG91bGQg YmUgdGhlIHBsYWNlLCBidXQgdGhhdCBkb2N1bWVudCBjdXJyZW50bHkgZXhwbGljaXRseSBtYWtl cyBQTVNJcyBvdXQgb2Ygc2NvcGUuDQo8YnI+DQo8YnI+DQpTaG91bGRuJ3QgdGhpcyBwYXJ0IG9m IGRyYWZ0LWlldGYtaWRyLXR1bm5lbC1lbmNhcCBiZSByZXZpc2l0ZWQgPyA8YnI+DQo8YnI+DQot VGhvbWFzPGJyPg0KPGJyPg0KPGJyPg0KLS0tLSBSYWJhZGFuLCBKb3JnZSAoTm9raWEgLSBVUykg YSDDqWNyaXQgLS0tLTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgaWQ9ImNvbXBvc2UiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ RnVsbHkgYWdyZWUgSm9obi4gVGhhdCdzIHdoYXQgSSBtZWFudCwgc29ycnkgaWYgSSBkaWRuJ3Qg bWFrZSBteXNlbGYgY2xlYXIuIFNlY3Rpb24gOSBuZWVkcyBjbGVhbiB1cCwgeWVzLjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8YnI+DQpKb3JnZTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCkZyb206IEVYVCBKb2huIEUgRHJha2UgJmx0OzxhIGhyZWY9Im1haWx0bzpqZHJha2VAanVu aXBlci5uZXQiPmpkcmFrZUBqdW5pcGVyLm5ldDwvYT4mZ3Q7PGJyPg0KU2VudDogV2VkbmVzZGF5 LCBNYXkgNCwgMjAxNiAyMzozNDxicj4NClN1YmplY3Q6IFJFOiBbSWRyXSBkcmFmdC1pZXRmLWJl c3MtZXZwbi1vdmVybGF5IHZzLiBkcmFmdC1pZXRmLWlkci10dW5uZWwtZW5jYXBzPGJyPg0KVG86 IElEUiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlkckBpZXRmLm9yZyI+aWRyQGlldGYub3JnPC9hPiZn dDssIEFsaSBTYWphc3NpIChzYWphc3NpKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNhamFzc2lAY2lz Y28uY29tIj5zYWphc3NpQGNpc2NvLmNvbTwvYT4mZ3Q7LCBSYWJhZGFuLCBKb3JnZSAoTm9raWEg LSBVUykgJmx0OzxhIGhyZWY9Im1haWx0bzpqb3JnZS5yYWJhZGFuQGFsY2F0ZWwtbHVjZW50LmNv bSI+am9yZ2UucmFiYWRhbkBhbGNhdGVsLWx1Y2VudC5jb208L2E+Jmd0OywNCiBCRVNTICZsdDs8 YSBocmVmPSJtYWlsdG86YmVzc0BpZXRmLm9yZyI+YmVzc0BpZXRmLm9yZzwvYT4mZ3Q7LCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtYmVzcy1ldnBuLW92ZXJsYXlAdG9vbHMuaWV0Zi5v cmciPmRyYWZ0LWlldGYtYmVzcy1ldnBuLW92ZXJsYXlAdG9vbHMuaWV0Zi5vcmc8L2E+Jmd0Oywg RVhUIC0NCjxhIGhyZWY9Im1haWx0bzp0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbSI+dGhvbWFzLm1v cmluQG9yYW5nZS5jb208L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86dGhvbWFzLm1vcmluQG9yYW5n ZS5jb20iPnRob21hcy5tb3JpbkBvcmFuZ2UuY29tPC9hPiZndDs8YnI+DQo8YnI+DQo8YnI+DQpK b3JnZSw8YnI+DQo8YnI+DQpXZSBwdXQgdGhlIFZOSSB2YWx1ZSBpbiB0aGUgTVBMUyBsYWJlbCBm aWVsZCBvZiB0aGUgUE1TSSBhdHRyaWJ1dGUgZm9yIGFsbCBzZXJ2aWNlIHR5cGVzLCBhbmQgd2Ug cHV0IGEgdmFsdWUgaW4gdGhlIEV0aGVybmV0IFRhZyBmaWVsZCBmb2xsb3dpbmcgdGhlIHJ1bGVz IGZvciBlYWNoIHNlcnZpY2UgdHlwZSBhcyBkZXNjcmliZWQgaW4gNS4xLjMgKDxhIGhyZWY9Imh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWJlc3MtZXZwbi1vdmVybGF5LTAy I3NlY3Rpb24tNS4xLjMiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWJl c3MtZXZwbi1vdmVybGF5LTAyI3NlY3Rpb24tNS4xLjM8L2E+KS48YnI+DQo8YnI+DQpZb3UncmUg cmlnaHQgdGhhdCB3ZSBuZWVkIHRvIGNsZWFuIHVwIHNlY3Rpb24gOS48YnI+DQo8YnI+DQpZb3Vy cyBJcnJlc3BlY3RpdmVseSw8YnI+DQo8YnI+DQpKb2huPGJyPg0KPGJyPg0KJmd0OyAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgRnJvbTogUmFiYWRhbiwgSm9yZ2UgKE5va2lh IC0gVVMpIFs8YSBocmVmPSJtYWlsdG86am9yZ2UucmFiYWRhbkBub2tpYS5jb20iPm1haWx0bzpq b3JnZS5yYWJhZGFuQG5va2lhLmNvbTwvYT5dPGJyPg0KJmd0OyBTZW50OiBXZWRuZXNkYXksIE1h eSAwNCwgMjAxNiAzOjUzIFBNPGJyPg0KJmd0OyBUbzogSm9obiBFIERyYWtlOyBFWFQgLSA8YSBo cmVmPSJtYWlsdG86dGhvbWFzLm1vcmluQG9yYW5nZS5jb20iPnRob21hcy5tb3JpbkBvcmFuZ2Uu Y29tPC9hPjsgQkVTUzsgSURSOyBkcmFmdC1pZXRmLWJlc3MtZXZwbi08YnI+DQomZ3Q7IDxhIGhy ZWY9Im1haWx0bzpvdmVybGF5QHRvb2xzLmlldGYub3JnIj5vdmVybGF5QHRvb2xzLmlldGYub3Jn PC9hPjsgQWxpIFNhamFzc2kgKHNhamFzc2kpPGJyPg0KJmd0OyBTdWJqZWN0OiBSZTogW0lkcl0g ZHJhZnQtaWV0Zi1iZXNzLWV2cG4tb3ZlcmxheSB2cy4gZHJhZnQtaWV0Zi1pZHItdHVubmVsLWVu Y2Fwczxicj4NCiZndDsgPGJyPg0KJmd0OyBIaSBKb2huLDxicj4NCiZndDsgPGJyPg0KJmd0OyBB Ym91dCB0aGlzOjxicj4NCiZndDsgPGJyPg0KJmd0OyBbSkRdIEZvciB0aGUgSU1FVCByb3V0ZSB0 aGUgTVBMUyBsYWJlbCBmaWVsZCBpcyBjYXJyaWVkIGluIHRoZSBQTVNJIGF0dHJpYnV0ZS4gSSB0 aGluayB3ZSBuZWVkPGJyPg0KJmd0OyB0byBhc2sgZXZlcnlvbmUgd2hldGhlciB0aGV5IHVzZWQg dGhlIEV0aGVybmV0IFRhZyBvciB0aGUgUE1TSSBhdHRyaWJ1dGUgdG8gY2FycnkgdGhlIFZOSTxi cj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEluIGNhc2UgaXQgaGVscHMsIEnigJl2ZSBz ZWVuIGEgZmV3IGltcGxlbWVudGF0aW9ucyBydW5uaW5nIGFuZCB0aGV5IGFsbCBlbmNvZGUgdGhl IFZOSSBpbiB0aGU8YnI+DQomZ3Q7IE1QTFMgbGFiZWwgZmllbGQgaW4gdGhlIFBUQS4gQW5kIGEg Y291cGxlIG9mIHRoZW0sIGVuY29kZSB0aGUgVk5JIGluIHRoZSBldGhlcm5ldC10YWcsIGluPGJy Pg0KJmd0OyBhZGRpdGlvbiB0byB0aGUgTVBMUyBsYWJlbCBpbiB0aGUgUFRBLiBJbiBhbnkgY2Fz ZSwgSSB0aGluayBzZWN0aW9uIDkgY29udHJhZGljdHMgc2VjdGlvbiA1LjEuMzxicj4NCiZndDsg YW5kIHNob3VsZCBiZSBjbGFyaWZpZWQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZxdW90OzUuMS4z IENvbnN0cnVjdGluZyBFVlBOIEJHUCBSb3V0ZXM8YnI+DQomZ3Q7ICZsdDtzbmlwJmd0Ozxicj4N CiZndDsgdGhlIE1QTFMgbGFiZWwgZmllbGQgaW4gdGhlIE1BQyBBZHZlcnRpc2VtZW50LCBFdGhl cm5ldCBBRCBwZXIgRVZJLCBhbmQgKipJbmNsdXNpdmU8YnI+DQomZ3Q7IE11bHRpY2FzdCBFdGhl cm5ldCBUYWcqKiByb3V0ZXMgaXMgdXNlZCB0byBjYXJyeSB0aGUgVk5JIG9yIFZTSUQuJnF1b3Q7 PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoYW5rcy48YnI+DQomZ3Q7IEpvcmdlPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgT24g NS80LzE2LCA4OjM0IFBNLCAmcXVvdDtFWFQgSm9obiBFIERyYWtlJnF1b3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86amRyYWtlQGp1bmlwZXIubmV0Ij5qZHJha2VAanVuaXBlci5uZXQ8L2E+Jmd0OyB3 cm90ZTo8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0O1Rob21hcyBhbmQgSm9yZ2UsPGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7U25pcHBlZCwgY29tbWVudHMgaW5saW5lLjxicj4NCiZndDsg Jmd0Ozxicj4NCiZndDsgJmd0O1lvdXJzIElycmVzcGVjdGl2ZWx5LDxicj4NCiZndDsgJmd0Ozxi cj4NCiZndDsgJmd0O0pvaG48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDtkcmFmdC1pZXRmLWJlc3MtZXZwbi1vdmVybGF5IChzZWUg c2VjdGlvbiA5KSByZWxpZXMgb24gdGhlIEJHUDxicj4NCiZndDsgJmd0OyZndDsgJmd0O0VuY2Fw c3VsYXRpb24gZXh0ZW5kZWQgdG8gZW5jb2RlIHRoZSB0dW5uZWwgZW5jYXAgdG8gdXNlIGZvciBC VU08YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDt0cmFmZmljLCBidXQgY29udHJhcnkgdG8gb3RoZXIg RS1WUE4gcm91dGVzLCByZWxpZXMgb24gdGhlIEV0aGVybmV0PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAm Z3Q7VGFnIGZpZWxkIG9mIHRoZSBOTFJJIHRvIGVuY29kZSB0aGUgVk5JL1ZTSUQuPGJyPg0KJmd0 OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgW0pPUkdFXSBUaGlzIGlzIGNlcnRhaW5seSBh IGxlZnRvdmVyIGZyb20gYW4gb2xkIHZlcnNpb24gd2hlcmUgdGhlPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyBWTkkvVlNJRCB3YXMgZW5jb2RlZCBpbiB0aGUgZXRoZXJuZXQgdGFnIGZvciBhbGwgdGhlIHJv dXRlcy4gVGhlIFZOSTxicj4NCiZndDsgJmd0OyZndDsgc2hvdWxkIGJlIGVuY29kZWQgaW4gdGhl IExhYmVsIGZpZWxkIGluIGFsbCB0aGUgcm91dGVzLiBUaGlzIGhhcyB0byBiZSBjb3JyZWN0ZWQu PGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgSW4gZmFjdCwgc2VjdGlvbiA1 LjEuMyBzYXlzOjxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IDUuMS4zIENv bnN0cnVjdGluZyBFVlBOIEJHUCBSb3V0ZXM8YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAm Z3Q7Jmd0OyAmbHQ7c25pcCZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0 OyBBY2NvcmRpbmdseSwgYW5kPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBzcGVjaWZpY2FsbHkgdG8gc3Vw cG9ydCB0aGUgb3B0aW9uIG9mIGxvY2FsbHkgYXNzaWduZWQgVk5JcywgdGhlIE1QTFM8YnI+DQom Z3Q7ICZndDsmZ3Q7IGxhYmVsIGZpZWxkIGluIHRoZSBNQUMgQWR2ZXJ0aXNlbWVudCwgRXRoZXJu ZXQgQUQgcGVyIEVWSSwgYW5kPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBJbmNsdXNpdmUgTXVsdGljYXN0 IEV0aGVybmV0IFRhZyByb3V0ZXMgaXMgdXNlZCB0byBjYXJyeSB0aGUgVk5JIG9yPGJyPg0KJmd0 OyAmZ3Q7Jmd0OyBWU0lELiBGb3IgdGhlIGJhbGFuY2Ugb2YgdGhpcyBtZW1vLCB0aGUgTVBMUyBs YWJlbCBmaWVsZCB3aWxsIGJlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyByZWZlcnJlZCB0byBhcyB0aGUg Vk5JL1ZTSUQgZmllbGQuIFRoZSBWTkkvVlNJRCBmaWVsZCBpcyB1c2VkIGZvcjxicj4NCiZndDsg Jmd0OyZndDsgYm90aCBsb2NhbCBhbmQgZ2xvYmFsIFZOSXMvVlNJRHMsIGFuZCBmb3IgZWl0aGVy IGNhc2UgdGhlIGVudGlyZSAyNC08YnI+DQomZ3Q7ICZndDsmZ3Q7IGJpdCBmaWVsZCBpcyB1c2Vk IHRvIGVuY29kZSB0aGUgVk5JL1ZTSUQgdmFsdWUuPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZn dDsgJmd0OyZndDsgJmx0O3NuaXAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7W0pEXSBGb3IgdGhlIElNRVQgcm91dGUgdGhlIE1QTFMgbGFiZWwgZmllbGQg aXMgY2FycmllZCBpbiB0aGUgUE1TSSBhdHRyaWJ1dGUuIEkgdGhpbmsgd2U8YnI+DQomZ3Q7IG5l ZWQgdG8gYXNrIGV2ZXJ5b25lIHdoZXRoZXIgdGhleTxicj4NCiZndDsgJmd0O3VzZWQgdGhlIEV0 aGVybmV0IFRhZyBvciB0aGUgUE1TSSBhdHRyaWJ1dGUgdG8gY2FycnkgdGhlIFZOSTxicj4NCiZn dDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZndDsgJmd0OyZndDs8YnI+DQom Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IFRoZXJlIGFyZSBtaW5vciB0aGluZ3MgdGhhdCBjb3VsZCBi ZSBpbXByb3ZlZCBpbjxicj4NCiZndDsgJmd0OyZndDsgJmd0OyZndDsgZHJhZnQtaWV0Zi1iZXNz LWV2cG4tb3ZlcmxheSB3cnQuIGNvbnNpc3RlbmN5IHdpdGg8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7IGRyYWZ0LWlldGYtaWRyLXR1bm5lbC1lbmNhcHMgOjxicj4NCiZndDsgJmd0OyZndDsg Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7ICogc2luY2UgZHJhZnQtaWV0Zi1p ZHItdHVubmVsLWVuY2FwcyB3aWxsIGRlcHJlY2F0ZSBSRkM1NTEyLCBpdDxicj4NCiZndDsgJmd0 OyZndDsgJmd0OyZndDsgd291bGQgYmUgYmV0dGVyIHRoYXQgZHJhZnQtaWV0Zi1iZXNzLWV2cG4t b3ZlcmxheSByZWZlcnMgdG88YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IGRyYWZ0LWlldGYt aWRyLXR1bm5lbC1lbmNhcHMgYW5kIG5vdCBhbnltb3JlIHRvIFJGQzU1MTIuPGJyPg0KJmd0OyAm Z3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgW0pPUkdFXSBJIGFncmVlLCBhcyBsb25nIGFzIGRy YWZ0LWlldGYtaWRyLXR1bm5lbC1lbmNhcHMga2VlcHMgdGhlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBl bmNhcHN1bGF0aW9uIGV4dGVuZGVkIGNvbW11bml0eS4gVGhlcmUgYXJlIGEgZmV3IGltcGxlbWVu dGF0aW9uczxicj4NCiZndDsgJmd0OyZndDsgdXNpbmcgdGhpcyBjb21tdW5pdHkgYW5kIGl0IGlz IGVub3VnaCB3aGVuIG9ubHkgdGhlIGVuY2Fwc3VsYXRpb24gdHlwZSBpcyBuZWVkZWQuPGJyPg0K Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7W0pEXSBJIGFncmVlIGFuZCB0 aGUgdHVubmVsIGVuY2FwcyBkcmFmdCBkb2VzIGtlZXAgdGhlIEVDPGJyPg0KJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgJmd0OyZn dDs8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7ICogSSB0aGluayBpdCB3b3VsZCBiZSBiZXR0 ZXIgdG8gYXZvaWQgdGhlIGV4cGxpY2l0IGxpc3Qgb2YgZW5jYXA8YnI+DQomZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7IHR5cGVzIGluIHNlY3Rpb24gNS4xLjMsIGFuZCByYXRoZXIgcmVmZXIgdG88YnI+ DQomZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IGRyYWZ0LWlldGYtaWRyLXR1bm5lbC1lbmNhcHMgaW5z dGVhZDxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IFtKT1JHRV0gSSBhZ3Jl ZS48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDtbSkRdIEFjY29y ZGluZyB0byBJQU5BLCBpdCBhbGxvY2F0ZWQgdGhlIGZpdmUgdHVubmVscyB0eXBlcyB0byB0aGU8 YnI+DQomZ3Q7ICZndDtvdmVybGF5IGRyYWZ0IHNvIEkgdGhpbmsgd2UgbmVlZCB0byBrZWVwIHRo ZW08YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAqIHRoZSBmb2xsb3dpbmcgbWlub3IgbW9kaWZpY2F0aW9u IHdhcyBwcm9wb3NlZCwgYnV0IG5vdCB5ZXQgaW5jb3Jwb3JhdGVkOjxicj4NCiZndDsgJmd0OyZn dDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IEpvaG4gRHJha2UsIDIwMTUt MTEtMTMgKHRvIEJFU1MgTUwpOjxicj4NCiZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IEZvciB0 aGUgb3ZlcmxheSBkcmFmdCwgcmVwbGFjZSB0aGlzIHRleHQgaW4gc2VjdGlvbiA1LjEuMzo8YnI+ DQomZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZxdW90O0lmIHRoZSBCR1AgRW5jYXBzdWxhdGlvbiBleHRlbmRlZCBjb21tdW5pdHkgaXMg bm90IHByZXNlbnQsPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgdGhlbiB0aGUgZGVm YXVsdCBNUExTIGVuY2Fwc3VsYXRpb24gb3IgYSBzdGF0aWNhbGx5IGNvbmZpZ3VyZWQ8YnI+DQom Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBlbmNhcHN1bGF0aW9uIGlzIGFzc3VtZWQuJnF1b3Q7 PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyBXaXRoIHRoZSBmb2xsb3dpbmc6PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmcXVvdDtOb3RlIHRoYXQgdGhlIE1Q TFMgZW5jYXBzdWxhdGlvbiB0dW5uZWwgdHlwZSBpcyBuZWVkZWQgaW48YnI+DQomZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyBvcmRlciB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuIGFuIGFkdmVydGlz aW5nIG5vZGUgdGhhdCBvbmx5PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgc3VwcG9y dHMgbm9uLU1QTFMgZW5jYXBzdWxhdGlvbnMgYW5kIG9uZSB0aGF0IHN1cHBvcnRzIE1QTFMgYW5k PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgbm9uLU1QTFMgZW5jYXBzdWxhdGlvbnMu IEFuIGFkdmVydGlzaW5nIG5vZGUgdGhhdCBvbmx5IHN1cHBvcnRzPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgTVBMUyBlbmNhcHN1bGF0aW9uIGRvZXMgbm90IG5lZWQgdG8gYWR2ZXJ0 aXNlIGFueSBlbmNhcHN1bGF0aW9uPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgdHVu bmVsIHR5cGVzOyBpLmUuLCBpZiB0aGUgQkdQIEVuY2Fwc3VsYXRpb24gZXh0ZW5kZWQgY29tbXVu aXR5PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgaXMgbm90IHByZXNlbnQsIHRoZW4g ZWl0aGVyIE1QTFMgZW5jYXBzdWxhdGlvbiBvciBhIHN0YXRpY2FsbHk8YnI+DQomZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyBjb25maWd1cmVkIGVuY2Fwc3VsYXRpb24gaXMgYXNzdW1lZC4mcXVv dDs8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyBJIHRoaW5rIHRoaXMgY2hhbmdlIGlzIHVzZWZ1bCBhbmQgc2hvdWxkIGJlIGluY29ycG9yYXRl ZCwgYWx0aG91Z2g8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IHNraXBwaW5nIHRoZSBsYXN0 IHNlbnRlbmNlIHdvdWxkIGJlIHdpc2UgaWYgdGhlIGZ1bGwgbGlzdCBvZjxicj4NCiZndDsgJmd0 OyZndDsgJmd0OyZndDsgdHVubmVsIHR5cGVzIGlzIHJlbW92ZWQuPGJyPg0KJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7W0pEXSBGaW5lIHdpdGggbWUgZWl0aGVyIHcvIG9y IHcvbyB0aGUgbGFzdCBzZW50ZW5jZTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_SN1PR0501MB1709067A4289CA9E8FAC6E61C7490SN1PR0501MB1709_-- From nobody Wed May 18 16:55:24 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36A1612D7D2 for ; Wed, 18 May 2016 16:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PpRzTUrbR64y for ; Wed, 18 May 2016 16:55:21 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0122.outbound.protection.outlook.com [65.55.169.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E78D12D7CF for ; Wed, 18 May 2016 16:55:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=aAJKruck2N+28sBg7GLTcgY0sB/b4ky6BNJFIKPdHfw=; b=Udxc8iGBx5pKcMX3ATmjuIzSIU9pN1HfZkiodKiqD+4TvQHRGcluDjgvt6KVJccnsB/kv64OBDAHsEUzjt2KcPaoF1b8dwfWjldjZxQYbODpn1qC6a8sZNIJgi0W4byRdkszrNfGrkETQUAL2ISypkUUE/w6iGmO+gOOthm0Mpg= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; Received: from rgugliemino-sslvpn-nc.jnpr.net (66.129.241.12) by CO2PR05MB2726.namprd05.prod.outlook.com (10.166.200.14) with Microsoft SMTP Server (TLS) id 15.1.497.12; Wed, 18 May 2016 23:55:18 +0000 From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <69BAD0BC-4673-4F52-A7F0-9249EB8EC9E3@juniper.net> Date: Wed, 18 May 2016 19:55:13 -0400 To: MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: BLUPR19CA0042.namprd19.prod.outlook.com (10.162.230.180) To CO2PR05MB2726.namprd05.prod.outlook.com (10.166.200.14) X-MS-Office365-Filtering-Correlation-Id: 971ee4ee-fcec-4d38-769d-08d37f77de0f X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2726; 2:vCL2c0zSbfdhm0GvgTSKUiNIFcL3Y7ZSpFa/o189rsIaoh11FPK7T8n6O1EMRFqXHY0pfH2Zd4Vm9/AMDBu5Uof9dZE9XEk8YEy+d1lx9zLwrmq5EPOcIaWPjFwPEaPes2eGgdXks4wjLp12VcPwvyJw1snD/lYgPB7u6yGVfAplc/UmezvcxZgQIjLeQLNZ; 3:XRlaZyb4ut3wMgXPVY7CNcUayGvk/atQf94AG5NUI1uCbUFAOhu3rLG7ewi7t1WQ2qiFt+LVzds/qakwE46S7fniosLqFg0JCAv1FUSSq2+8AE6JNlN+kEsAjGgkZaSf; 25:EPUtF84UvzDPuksgOqTrjpHFbwwaG7C/lmOv8XmIWdDp2Q2siVE0hmXSmvnGt71Y7Yy8NXeAaeuYD8eMKpTsXtTxrHB54MzXIq7C1q3mW9v12BWOt9xwkRADbiVzXCmvNM3N2TQhLvvJQQrzkMb8J1+N0ZBA89d1DZondyAEjKJQOo4Mc8WNrm9XyQjPXET3HDv54C+tSPyQUGTVaZa2P1O2FppyEJji0rRoCC8oXujSnMidXEoI/usbFu0XQ9CXvKujP0nqcWFdK75xPMzTIgtCFgCLUUQTc2Gzc8sYk1lFEtW/lFM0DXYUWYYsvCvJ1K2f9BT7oTtXdoIwITvxCoqPmJjesjIJUxKcB0pUEh4U8KFD8OBxvLgUiia4S90xaTnenY1ZDpdoSLj0Jqgw6kse/wtkyHzWvdCcNAnj/aU= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR05MB2726; X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2726; 20:19c+RLsadISu2+dfXiQsCgwNx2UtNiX4bEURnsnHPPdOfTLSsDw/mrNhz09LJxsNKeVvOhp8UW0b514hvqevUVZq6GS+BKziFNPx+oO6MEMzDzpXYSIx3KTc2diTOThLNfsX97vx2+0QDERrYkGBRFqXYpd6MKOafPugWJpZTcP50dDstK7VSgCwpGG+GsxvTmGXYw56rNptEhp4hbzON4JjqpTne00u/rRf/Lw6J+57hGLFig2+8rtuMV4AWeHFG19ZNvoyoetTQffCrZQm/dmvSdwWKp9sK/VHVgI7Wg2ehj8Bkk2CFFzU5TKTCojYiOQiA9pFklPo0o/TFOraPJwZoC1DJFFXMvIFfD+cD4q0vuYALPQn7srEMdgYSDOd7G3t+VUQQCOdSQPULD9Voiaek5OCPhPU+/J3Xc8Utp4ynnkrrSK3kdGTn4K9jQ/GfAPe13WF0QwQkFfHe4SdzkoqMn9Bc+I/2NnoVr4A6DRVPz9eSp/vGKpZOraiqWV/; 4:cKmYs0kEh4ZRyRwRw6mKYv5UtLGX42dCUIxshEyy09ocxLHfd7ZiZVm3XGiGDxrHNC83mHB17LNQroghqrEGeN1nxuCpotZR2NPWWmNi+DWlwIpgWFFNomwunELaRdAsdkRgswwbpNKh8pryhVXMOBMuqRS6yUdWutDUreoVRjdq/R51e4ALwTPbynX0x7k6BrlqIXGHUmH06h+kNd+19d1KGm5GfH6L5jF3UMWYdlVQWAuD0K9OMmNTK1ig04WdcFt3DivX/01lZ1VdLbYWJ/sfE9sDV6+Uj0BdroAkM6u7L0ExWOSEgolZQNe3JhQPUK/jydsqHC5HxuWue0/LM7WWWwO4fgCpwyJV8YcDRQbDy98cmfSvjqaReoSH8h6oUy0lxByh2yoX1lMspuFHxQ== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:CO2PR05MB2726; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB2726; X-Forefront-PRVS: 0946DC87A1 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(69224002)(33656002)(46406003)(50466002)(42186005)(2906002)(66066001)(57306001)(189998001)(92566002)(110136002)(47776003)(53416004)(36756003)(86362001)(50226002)(50986999)(77096005)(83716003)(81166006)(586003)(8746002)(82746002)(8676002)(5008740100001)(2351001)(229853001)(107886002)(23726003)(5004730100002)(3846002)(97756001)(3480700004)(6116002)(450100001)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2726; H:rgugliemino-sslvpn-nc.jnpr.net; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO2PR05MB2726; 23:Xl/55YN8tnV61vQpxkqdPXQdafdVaODhqf0go/qPT?= =?us-ascii?Q?yrRWuZesQvbJV+QG9kWuuxJlc7c52kgBryveYwV2a6UJGcW+97qei99L5FoC?= =?us-ascii?Q?+TaYUNsSUUs0HmCOjyHAq2zPMYN561bE3M2ut/CicSt71P0aiOox36AmTBvd?= =?us-ascii?Q?FpowmF/hB3Sj6Lry0vLHLrUJLaX0NvUaGdkngzff290ipxyhz8XtrFRCI8rH?= =?us-ascii?Q?KP016LxbgLejCNfBX+Sy8uaci1dc3E0W0uGc8VD3XGpULNXI3+HH1iy11SYr?= =?us-ascii?Q?QHgPxwtOgOLSiHt1Ufb24m8xrcxnmpwqQwKlveh+JWr0nev3NSq0Wra7NmYO?= =?us-ascii?Q?66S0T8yIkqj/NAWBow2a8Z+tyvLFayCZG6GAi3u7NeDVX/F45zdHPkLkO8LR?= =?us-ascii?Q?1d49zMU/nPFppRyr9j5GEzVxRC3XanOH316LvFphql6TaNm6ocXl3lQQHafO?= =?us-ascii?Q?5xcWffRcxhB9SW8+l6A0LOvFXHhXXYlQEc8Uc+Ja6cDHR8LLH/j7SkL2s/LI?= =?us-ascii?Q?/ZDttUMQYnDbHgh406WycXidYGiy5MFHZimRQh4VwC8Ziog2+uIfvSJjYOft?= =?us-ascii?Q?iygdVnCANU0/T92gKx903ZHXZyJo4Bbfz91hpJyvydXJ/9zarERIBKDT+gvK?= =?us-ascii?Q?jazgk+xK42MMLWOCgvhCglwW8h1htq/mI/LRHvvm6J/DkF7nIMgUP6XzWgtL?= =?us-ascii?Q?kfs7COrGQ0YYXp6AjQbt6eGltugRtjpYSijbHzehivKW+OSBFpDkHBHy7hxA?= =?us-ascii?Q?BefU57uy3+XJ7OXHalBBYlbcceQuU1T9A9VyGHtPpSHENiYNCtW7L1lYiqsR?= =?us-ascii?Q?2JRMRlorA2TE/jOUKfs8n14NH7Uw7cZGZ6zY30UkiRUxemTse1j9D1UbEznF?= =?us-ascii?Q?KIEEyoG90kbeTlrxZNR2tGTVkrAvlr2PGtdi2lBL8PWZZSqWj2Gw4GgIG7A/?= =?us-ascii?Q?8hcKG1NLV8BwgumZMZl1XdsN3AiBuw4AUGsOldNLoRjRntBOreIgO5x0RH1g?= =?us-ascii?Q?6960uaGLCJN9WSjsqDntTyx?= X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2726; 5:V7dNoOee7a2kLlu2womPiCSaBx3jM/8r7kx2TDrxOqQMKy+31TUzqL0dAeO/5mBBGZL2wllhu1LvqBVnMU6cfx6hO/okIRl/njbK5Rg374CxuWKmHjap9wNtIP22YWH9k6wdxjDV8jzRyoD9P5CDzA==; 24:QLt8ACTfrtTDai6wHI8KuD+h6LPjJUVt24r6Nns5RigvwfQERgOq60XAcf/u3zusm2tw/vn3EccYmmgOxoi/N6FmTZpdcYItbtuxeb97jRU=; 7:H/Sdw6VQ3i1af1rRMTvmp1DcpU1MsNWa6335lFTkSYpGxSsgysksC5EG7gD6ki47GAn1n9MRpVxA8dpRglFN3fhdIJNxnTOCzdWNpabCFV/AXyKiaO6jcZrCvl8h6qlpPfHLhHjg2dVKffqa1Sdg86jQf/2mKVnKkxz/siSrrjEm0SDahjauq/O9941AtXgl SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 May 2016 23:55:18.8856 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2726 Archived-At: Subject: [Idr] Adopting redirect draft X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 23:55:23 -0000 Dear WG, Thanks for all your engagement on this topic, most recently at Monday's = meeting. The chairs have determined that we have WG consensus to adopt = the work. There also appeared to be consensus to use the approach of a = type field as in draft-li-idr-flowspec-redirect-generalized-sid rather = than a bit as in draft-vandevelde-idr-flowspec-path-redirect. We have asked the authors to work on a merged draft, and expect to use = that as the basis for an upcoming WG document. Thanks, --John and Sue= From nobody Thu May 19 04:49:36 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7831412D0E3; Thu, 19 May 2016 01:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.949 X-Spam-Level: X-Spam-Status: No, score=-4.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_SOFTFAIL=0.665, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srlOGa4b_Cgj; Thu, 19 May 2016 01:34:19 -0700 (PDT) Received: from r-mail2.rd.orange.com (r-mail2.rd.orange.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 8E71312B03F; Thu, 19 May 2016 01:34:17 -0700 (PDT) Received: from r-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 83E1A16C018; Thu, 19 May 2016 10:34:16 +0200 (CEST) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by r-mail2.rd.orange.com (Postfix) with ESMTP id 718A916C015; Thu, 19 May 2016 10:34:16 +0200 (CEST) Received: from [10.193.71.12] (10.193.71.12) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.266.1; Thu, 19 May 2016 10:34:15 +0200 To: John E Drake , IDR , BESS , "draft-ietf-bess-evpn-overlay@tools.ietf.org" , "Ali Sajassi (sajassi)" , "Rabadan, Jorge (Nokia - US)" , "draft-ietf-idr-tunnel-encap@tools.ietf.org" References: <5729F1C3.1030605@orange.com> <012C176C-A8D6-45AA-BA69-616C0ED7E41E@alcatel-lucent.com> <420BA2D8D80A6727.2B2C290F-2299-40BB-B53B-CC36D2B5D826@mail.outlook.com> <1881_1462451514_572B3D3A_1881_7198_1_0vn90oitr7e881gh2sn8qm5f.1462451509961@email.android.com> <17029_1462484835_572BBF63_17029_2323_1_opi9hqsl9b9tani0t0skkcuq.1462484831251@email.android.com> <28175_1463566739_573C4192_28175_2444_1_613f729b-d12e-5c48-29a1-ff000c1184a1@orange.com> <9ed4f1b1-1d84-2302-d7bb-5ad7fc42acdb@orange.com> From: Thomas Morin Organization: Orange Message-ID: Date: Thu, 19 May 2016 10:34:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9EC6FAAA1C7FA0E7B8D59F17" Archived-At: X-Mailman-Approved-At: Thu, 19 May 2016 04:49:33 -0700 Cc: Adrian Farrel , Alia Atlas Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 08:34:22 -0000 --------------9EC6FAAA1C7FA0E7B8D59F17 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Hi John, [with a question to IDR chairs and draft-ietf-idr-tunnel-encaps authors below] 2016-05-18, John E Drake: > Unless and until Eric’s draft is published the normative reference is to RFC 5512 and neither you nor anyone else knows when or if > Eric’s draft will be published as an RFC and I think it is a serious breach of procedure to hold up the overlay draft by asserting you > know what the future portends. Oh, oh, Big Words :-D (can you hear the faint murmur of lawyers in the background, impatient to enter the procedural battle ?) Talking about "holding up" the draft could give the wrong impression that apart from this question, the draft is ready. From a strict procedural standpoint, if we set aside that it has been 'expired' for 4 weeks, draft-ietf-bess-evpn-overlay is in the same state as draft-ietf-idr-tunnel-encaps, and noone knows its future for sure either. And talking about "holding up" the draft could give the wrong impression on the kind of input I am providing, that merely relate to producing specs not only clear for its authors but to a larger audience. In that respect, if we can avoid a short term future where the draft would point to an obsolete spec, I think it will be better. Hence, having a normative reference to draft-ietf-idr-tunnel-encaps seems better. IDR chairs and draft-ietf-idr-tunnel-encaps authors, do you know when we should expect a WGLC on draft-ietf-idr-tunnel-encaps ? Progressing it quickly will help clarify all that. If too far or too much unknown around the progress of draft-ietf-idr-tunnel-encaps, I can certainly live with draft-ietf-bess-evpn-overlay refer to RFC5512 normatively and to draft-ietf-idr-tunnel-encaps informatively, and have text explicitly state where things stand. But's let's not rush, and remember that implementers care more about spec stability than knowing what the exact RFC number will be. > This is not the first time an RFC made a normative reference to an RFC that subsequently was obsoleted and the RFC system deals > quite nicely with this situation. Of course we can deal with less-than-ideal... it doesn't mean we can't anticipate and do better. -Thomas > *From:*Thomas Morin [mailto:thomas.morin@orange.com] > *Sent:* Wednesday, May 18, 2016 10:23 AM > *To:* John E Drake; IDR; BESS; > draft-ietf-bess-evpn-overlay@tools.ietf.org; Ali Sajassi (sajassi); > Rabadan, Jorge (Nokia - US); draft-ietf-idr-tunnel-encap@tools.ietf.org > *Subject:* Re: [Idr] draft-ietf-bess-evpn-overlay vs. > draft-ietf-idr-tunnel-encaps > > John, > > 2016-05-18, John E Drake: > > I spoke with Ali and he will reference the tunnel encapsulation > draft rather than RFC 5512 but make it Informative. > > I think this is in the spirit of what you proposed in your email, > below. > > > Well, only for some definition of "in the spirit"... :-/ > > What I think we should do is normatively refer to > draft-ietf-idr-tunnel-encaps and informatively refer to RFC5512, not > the reverse. > Or else we end up with an RFC that soon after publication will > normatively depend to an obsoleted RFC. > > -Thomas > > > > *From:*thomas.morin@orange.com > [mailto:thomas.morin@orange.com] > *Sent:* Wednesday, May 18, 2016 6:19 AM > *To:* John E Drake; IDR; BESS; > draft-ietf-bess-evpn-overlay@tools.ietf.org > ; Ali Sajassi > (sajassi); Rabadan, Jorge (Nokia - US); > draft-ietf-idr-tunnel-encap@tools.ietf.org > > *Subject:* Re: [Idr] draft-ietf-bess-evpn-overlay vs. > draft-ietf-idr-tunnel-encaps > > Hi John, > > John. > > > When the tunnel encaps draft was first published it did not > carry forward the RFC 5512 extended community and it did not > propose to obsolete RFC 5512. There was discussion of using > the attribute defined in the tunnel encaps draft instead of > the extended community and we decided to continue to use the > extended community. So, in that sense we are misaligned with > the tunnel encaps draft. > > > > As you confirm below, the last sentence is only true in the past > tense. > > > > Subsequently, however, the tunnel encaps draft decided to > carry forward the extended community and to obsolete RFC 5512, > so we were effectively covered by a grandfather clause. > > > Yes, precisely: given the content of the two drafts, there is no > misalignment anymore. > > > > Given the overlay draft’s tardiness, I don’t think that’s > acceptable and would prefer to continue to refer to RFC 5512. > > > I do not think that the additional publication delay is a sound > rationale for normatively refer to a spec that is known to become > obsolete. > If it helps, the draft can keep an informative ref to RFC5512 and > remind that it does not rely on anything specifically introduced > by draft-ietf-idr-tunnel-encaps and not existing already in RFC5512. > > -Thomas > > > 2016-05-06, John E Drake: > > However, even though I agreed yesterday to refer to the tunnel > encaps draft instead of RFC 5512 we have an issue with doing > this, viz, the overlay draft makes a normative reference to > RFC 5512. If we change the normative reference to the tunnel > encaps draft we cannot publish the overlay draft until after > the tunnel encaps draft has been published. > > Given the overlay draft’s tardiness, I don’t think that’s > acceptable and would prefer to continue to refer to RFC 5512. > > Yours Irrespectively, > > John > > *From:*thomas.morin@orange.com > [mailto:thomas.morin@orange.com] > *Sent:* Thursday, May 05, 2016 5:47 PM > *To:* IDR; BESS; draft-ietf-bess-evpn-overlay@tools.ietf.org > ; Ali > Sajassi (sajassi); Rabadan, Jorge (Nokia - US); > draft-ietf-idr-tunnel-encap@tools.ietf.org > ; John E Drake > *Subject:* RE: [Idr] draft-ietf-bess-evpn-overlay vs. > draft-ietf-idr-tunnel-encaps > > Hi John, > > I have a hard time reconciliating the fact that yesterday you > were fine with having bess-evpn-overlay refer to > idr-tunnel-encap instead of RFC5512, with the fact that you > consider (below) the two docs "not aligned" for unicast. > > Can you be more explicit in where the "misalignment" lies? > > -Thomas > > ---- John E Drake a écrit ---- > > Thomas, > > The overlay draft preceded the tunnel encaps draft and it was > designed to handle a very specific problem, marrying the EVPN > control plane to the VXLAN data plane draft and modulo the > correction to section 9 it is internally consistent. > > The tunnel encaps draft solves a more general problem and the > WG decided a long time ago that the overlay draft was not > going to be updated to use the mechanisms it details for > unicast, so the overlay draft is already explicitly not in > alignment with it. > > This, plus the fact that the tunnel encaps draft explicitly > puts the PMSI out of scope, leads me to the conclusion that > the overlay draft should not be tweaked to be in alignment > with a future solution for encoding VNIs for multicast. > > Yours Irrespectively, > > John > > *From:*thomas.morin@orange.com > [mailto:thomas.morin@orange.com] > *Sent:* Thursday, May 05, 2016 8:32 AM > *To:* John E Drake; IDR; BESS; > draft-ietf-bess-evpn-overlay@tools.ietf.org > ; Ali > Sajassi (sajassi); Rabadan, Jorge (Nokia - US); > draft-ietf-idr-tunnel-encap@tools.ietf.org > > *Subject:* RE: [Idr] draft-ietf-bess-evpn-overlay vs. > draft-ietf-idr-tunnel-encaps > > Thanks for the clarification on the intent around > draft-ietf-bess-evpn-overlay. Then indeed section 9 needs some > tidying up. > > The issue that I think remain is that it would be much cleaner > to explain how to use PMSI with overlay encaps in a spec not > specific to E-VPN and in a way more consistent to what is done > for unicast. > > It seems if course that draft-ietf-idr-tunnel-encap should be > the place, but that document currently explicitly makes PMSIs > out of scope. > > Shouldn't this part of draft-ietf-idr-tunnel-encap be revisited ? > > -Thomas > > > ---- Rabadan, Jorge (Nokia - US) a écrit ---- > > Fully agree John. That's what I meant, sorry if I didn't make > myself clear. Section 9 needs clean up, yes. > > Thanks, > Jorge > > _____________________________ > From: EXT John E Drake > > Sent: Wednesday, May 4, 2016 23:34 > Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. > draft-ietf-idr-tunnel-encaps > To: IDR >, Ali Sajassi > (sajassi) >, > Rabadan, Jorge (Nokia - US) >, BESS > >, > >, EXT - > thomas.morin@orange.com > > > > > Jorge, > > We put the VNI value in the MPLS label field of the PMSI > attribute for all service types, and we put a value in the > Ethernet Tag field following the rules for each service type > as described in 5.1.3 > (https://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-02#section-5.1.3). > > You're right that we need to clean up section 9. > > Yours Irrespectively, > > John > > > -----Original Message----- > > From: Rabadan, Jorge (Nokia - US) > [mailto:jorge.rabadan@nokia.com] > > Sent: Wednesday, May 04, 2016 3:53 PM > > To: John E Drake; EXT - thomas.morin@orange.com > ; BESS; IDR; draft-ietf-bess-evpn- > > overlay@tools.ietf.org ; Ali > Sajassi (sajassi) > > Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. > draft-ietf-idr-tunnel-encaps > > > > Hi John, > > > > About this: > > > > [JD] For the IMET route the MPLS label field is carried in > the PMSI attribute. I think we need > > to ask everyone whether they used the Ethernet Tag or the > PMSI attribute to carry the VNI > > > > > > In case it helps, I’ve seen a few implementations running > and they all encode the VNI in the > > MPLS label field in the PTA. And a couple of them, encode > the VNI in the ethernet-tag, in > > addition to the MPLS label in the PTA. In any case, I think > section 9 contradicts section 5.1.3 > > and should be clarified. > > > > "5.1.3 Constructing EVPN BGP Routes > > > > the MPLS label field in the MAC Advertisement, Ethernet AD > per EVI, and **Inclusive > > Multicast Ethernet Tag** routes is used to carry the VNI or > VSID." > > > > Thanks. > > Jorge > > > > > > > > > > > > On 5/4/16, 8:34 PM, "EXT John E Drake" > wrote: > > > > >Thomas and Jorge, > > > > > >Snipped, comments inline. > > > > > >Yours Irrespectively, > > > > > >John > > > > > >> > > > >> >draft-ietf-bess-evpn-overlay (see section 9) relies on > the BGP > > >> >Encapsulation extended to encode the tunnel encap to use > for BUM > > >> >traffic, but contrary to other E-VPN routes, relies on > the Ethernet > > >> >Tag field of the NLRI to encode the VNI/VSID. > > >> > > >> [JORGE] This is certainly a leftover from an old version > where the > > >> VNI/VSID was encoded in the ethernet tag for all the > routes. The VNI > > >> should be encoded in the Label field in all the routes. > This has to be corrected. > > >> > > >> In fact, section 5.1.3 says: > > >> > > >> 5.1.3 Constructing EVPN BGP Routes > > >> > > >> > > >> > > >> Accordingly, and > > >> specifically to support the option of locally assigned > VNIs, the MPLS > > >> label field in the MAC Advertisement, Ethernet AD per > EVI, and > > >> Inclusive Multicast Ethernet Tag routes is used to carry > the VNI or > > >> VSID. For the balance of this memo, the MPLS label field > will be > > >> referred to as the VNI/VSID field. The VNI/VSID field is > used for > > >> both local and global VNIs/VSIDs, and for either case the > entire 24- > > >> bit field is used to encode the VNI/VSID value. > > >> > > >> > > > > > > > > >[JD] For the IMET route the MPLS label field is carried in > the PMSI attribute. I think we > > need to ask everyone whether they > > >used the Ethernet Tag or the PMSI attribute to carry the VNI > > > > > > > > >> >> > > >> >> There are minor things that could be improved in > > >> >> draft-ietf-bess-evpn-overlay wrt. consistency with > > >> >> draft-ietf-idr-tunnel-encaps : > > >> >> > > >> >> * since draft-ietf-idr-tunnel-encaps will deprecate > RFC5512, it > > >> >> would be better that draft-ietf-bess-evpn-overlay > refers to > > >> >> draft-ietf-idr-tunnel-encaps and not anymore to RFC5512. > > >> > > >> [JORGE] I agree, as long as draft-ietf-idr-tunnel-encaps > keeps the > > >> encapsulation extended community. There are a few > implementations > > >> using this community and it is enough when only the > encapsulation type is needed. > > > > > > > > >[JD] I agree and the tunnel encaps draft does keep the EC > > > > > > > > >> > > >> >> > > >> >> * I think it would be better to avoid the explicit > list of encap > > >> >> types in section 5.1.3, and rather refer to > > >> >> draft-ietf-idr-tunnel-encaps instead > > >> > > >> [JORGE] I agree. > > > > > > > > >[JD] According to IANA, it allocated the five tunnels types > to the > > >overlay draft so I think we need to keep them > > > > > > > > >> > > >> >> * the following minor modification was proposed, but > not yet incorporated: > > >> >> > > >> >> John Drake, 2015-11-13 (to BESS ML): > > >> >>> For the overlay draft, replace this text in section > 5.1.3: > > >> >>> > > >> >>> "If the BGP Encapsulation extended community is not > present, > > >> >>> then the default MPLS encapsulation or a statically > configured > > >> >>> encapsulation is assumed." > > >> >>> > > >> >>> With the following: > > >> >>> > > >> >>> "Note that the MPLS encapsulation tunnel type is > needed in > > >> >>> order to distinguish between an advertising node that > only > > >> >>> supports non-MPLS encapsulations and one that > supports MPLS and > > >> >>> non-MPLS encapsulations. An advertising node that > only supports > > >> >>> MPLS encapsulation does not need to advertise any > encapsulation > > >> >>> tunnel types; i.e., if the BGP Encapsulation extended > community > > >> >>> is not present, then either MPLS encapsulation or a > statically > > >> >>> configured encapsulation is assumed." > > >> >> > > >> >> I think this change is useful and should be > incorporated, although > > >> >> skipping the last sentence would be wise if the full > list of > > >> >> tunnel types is removed. > > > > > > > > >[JD] Fine with me either w/ or w/o the last sentence > > > > > > > --------------9EC6FAAA1C7FA0E7B8D59F17 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit Hi John,

[with a question to IDR chairs and  draft-ietf-idr-tunnel-encaps authors below]

2016-05-18, John E Drake:
> Unless and until Eric’s draft is published the normative reference is to RFC 5512 and neither you nor anyone else knows when or if
> Eric’s draft will be published as an RFC and I think it is a serious breach of procedure to hold up the overlay draft by asserting you
> know what the future portends.

Oh, oh, Big Words  :-D
(can you hear the faint murmur of lawyers in the background, impatient to enter the procedural battle ?)

Talking about "holding up" the draft could give the wrong impression that apart from this question, the draft is ready.
From a strict procedural standpoint, if we set aside that it has been 'expired' for 4 weeks, draft-ietf-bess-evpn-overlay is in the same state as draft-ietf-idr-tunnel-encaps, and noone knows its future for sure either.

And talking about "holding up" the draft could give the wrong impression on the kind of input I am providing, that merely relate to producing specs not only clear for its authors but to a larger audience. In that respect, if we can avoid a short term future where the draft would point to an obsolete spec, I think it will be better. Hence, having a normative reference to draft-ietf-idr-tunnel-encaps seems better.

IDR chairs and draft-ietf-idr-tunnel-encaps authors, do you know when we should expect a WGLC on draft-ietf-idr-tunnel-encaps ?
Progressing it quickly will help clarify all that.

If too far or too much unknown around the progress of draft-ietf-idr-tunnel-encaps, I can certainly live with draft-ietf-bess-evpn-overlay refer to RFC5512 normatively and to draft-ietf-idr-tunnel-encaps informatively, and have text explicitly state where things stand.  But's let's not rush, and remember that implementers care more about spec stability than knowing what the exact RFC number will be.
 
> This is not the first time an RFC made a normative reference to an RFC that subsequently was obsoleted and the RFC system deals
> quite nicely with this situation.

Of course we can deal with less-than-ideal... it doesn't mean we can't anticipate and do better.

-Thomas



From: Thomas Morin [mailto:thomas.morin@orange.com]
Sent: Wednesday, May 18, 2016 10:23 AM
To: John E Drake; IDR; BESS; draft-ietf-bess-evpn-overlay@tools.ietf.org; Ali Sajassi (sajassi); Rabadan, Jorge (Nokia - US); draft-ietf-idr-tunnel-encap@tools.ietf.org
Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps

 

John,

2016-05-18, John E Drake:

I spoke with Ali and he will reference the tunnel encapsulation draft rather than RFC 5512 but make it Informative.

I think this is in the spirit of what you proposed in your email, below.


Well, only for some definition of "in the spirit"... :-/

What I think we should do is normatively refer to draft-ietf-idr-tunnel-encaps and informatively refer to RFC5512, not the reverse.
Or else we end up with an RFC that soon after publication will normatively depend to an obsoleted RFC.

-Thomas



 

From: thomas.morin@orange.com [mailto:thomas.morin@orange.com]
Sent: Wednesday, May 18, 2016 6:19 AM
To: John E Drake; IDR; BESS; draft-ietf-bess-evpn-overlay@tools.ietf.org; Ali Sajassi (sajassi); Rabadan, Jorge (Nokia - US); draft-ietf-idr-tunnel-encap@tools.ietf.org
Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps

 

Hi John,

John.


When the tunnel encaps draft was first published it did not carry forward the RFC 5512 extended community and it did not propose to obsolete RFC 5512.  There was discussion of using the attribute defined in the tunnel encaps draft instead of the extended community and we decided to continue to use the extended community.  So, in that sense we are misaligned with the tunnel encaps draft.



As you confirm below, the last sentence is only true in the past tense.



Subsequently, however, the tunnel encaps draft decided to carry forward the extended community and to obsolete RFC 5512, so we were effectively covered by a grandfather clause.


Yes, precisely: given the content of the two drafts, there is no misalignment anymore.



Given the overlay draft’s tardiness, I don’t think that’s acceptable and would prefer to continue to refer to RFC 5512.


I do not think that the additional publication delay is a sound rationale for normatively refer to a spec that is known to become obsolete.
If it helps, the draft can keep an informative ref to RFC5512 and remind that it does not rely on anything specifically introduced by draft-ietf-idr-tunnel-encaps and not existing already in RFC5512.

-Thomas


2016-05-06, John E Drake:

 

However, even though I agreed yesterday to refer to the tunnel encaps draft instead of RFC 5512 we have an issue with doing this, viz, the overlay draft makes a normative reference to RFC 5512.  If we change the normative reference to the tunnel encaps draft we cannot publish the overlay draft until after the tunnel encaps draft has been published.

 

Given the overlay draft’s tardiness, I don’t think that’s acceptable and would prefer to continue to refer to RFC 5512.

 

Yours Irrespectively,

 

John

 

From: thomas.morin@orange.com [mailto:thomas.morin@orange.com]
Sent: Thursday, May 05, 2016 5:47 PM
To: IDR; BESS; draft-ietf-bess-evpn-overlay@tools.ietf.org; Ali Sajassi (sajassi); Rabadan, Jorge (Nokia - US); draft-ietf-idr-tunnel-encap@tools.ietf.org; John E Drake
Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps

 

Hi John,

I have a hard time reconciliating the fact that yesterday you were fine with having bess-evpn-overlay refer to idr-tunnel-encap instead of RFC5512, with the fact that you consider (below) the two docs "not aligned" for unicast.

Can you be more explicit in where the "misalignment" lies?

-Thomas

---- John E Drake a écrit ----

Thomas,

 

The overlay draft preceded the tunnel encaps draft and it was designed to handle a very specific problem, marrying the EVPN control plane to the VXLAN data plane draft and modulo the correction to section 9 it is internally consistent.

 

The tunnel encaps draft solves a more general problem and the WG decided a long time ago that the overlay draft was not going to be updated to use the mechanisms it details for unicast, so the overlay draft is already explicitly not in alignment with it.

 

This, plus the fact that the tunnel encaps draft explicitly puts the PMSI out of scope, leads me to the conclusion that the overlay draft should not be tweaked to be in alignment with a future solution for encoding VNIs for multicast.

 

Yours Irrespectively,

 

John

 

From: thomas.morin@orange.com [mailto:thomas.morin@orange.com]
Sent: Thursday, May 05, 2016 8:32 AM
To: John E Drake; IDR; BESS; draft-ietf-bess-evpn-overlay@tools.ietf.org; Ali Sajassi (sajassi); Rabadan, Jorge (Nokia - US); draft-ietf-idr-tunnel-encap@tools.ietf.org
Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps

 

Thanks for the clarification on the intent around draft-ietf-bess-evpn-overlay. Then indeed section 9 needs some tidying up.

The issue that I think remain is that it would be much cleaner to explain how to use PMSI with overlay encaps in a spec not specific to E-VPN and in a way more consistent to what is done for unicast.

It seems if course that draft-ietf-idr-tunnel-encap should be the place, but that document currently explicitly makes PMSIs out of scope.

Shouldn't this part of draft-ietf-idr-tunnel-encap be revisited ?

-Thomas


---- Rabadan, Jorge (Nokia - US) a écrit ----

Fully agree John. That's what I meant, sorry if I didn't make myself clear. Section 9 needs clean up, yes.

Thanks,
Jorge

 

_____________________________
From: EXT John E Drake <jdrake@juniper.net>
Sent: Wednesday, May 4, 2016 23:34
Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps
To: IDR <idr@ietf.org>, Ali Sajassi (sajassi) <sajassi@cisco.com>, Rabadan, Jorge (Nokia - US) <jorge.rabadan@alcatel-lucent.com>, BESS <bess@ietf.org>, <draft-ietf-bess-evpn-overlay@tools.ietf.org>, EXT - thomas.morin@orange.com <thomas.morin@orange.com>


Jorge,

We put the VNI value in the MPLS label field of the PMSI attribute for all service types, and we put a value in the Ethernet Tag field following the rules for each service type as described in 5.1.3 (https://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-02#section-5.1.3).

You're right that we need to clean up section 9.

Yours Irrespectively,

John

> -----Original Message-----
> From: Rabadan, Jorge (Nokia - US) [mailto:jorge.rabadan@nokia.com]
> Sent: Wednesday, May 04, 2016 3:53 PM
> To: John E Drake; EXT - thomas.morin@orange.com; BESS; IDR; draft-ietf-bess-evpn-
> overlay@tools.ietf.org; Ali Sajassi (sajassi)
> Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps
>
> Hi John,
>
> About this:
>
> [JD] For the IMET route the MPLS label field is carried in the PMSI attribute. I think we need
> to ask everyone whether they used the Ethernet Tag or the PMSI attribute to carry the VNI
>
>
> In case it helps, I’ve seen a few implementations running and they all encode the VNI in the
> MPLS label field in the PTA. And a couple of them, encode the VNI in the ethernet-tag, in
> addition to the MPLS label in the PTA. In any case, I think section 9 contradicts section 5.1.3
> and should be clarified.
>
> "5.1.3 Constructing EVPN BGP Routes
> <snip>
> the MPLS label field in the MAC Advertisement, Ethernet AD per EVI, and **Inclusive
> Multicast Ethernet Tag** routes is used to carry the VNI or VSID."
>
> Thanks.
> Jorge
>
>
>
>
>
> On 5/4/16, 8:34 PM, "EXT John E Drake" <jdrake@juniper.net> wrote:
>
> >Thomas and Jorge,
> >
> >Snipped, comments inline.
> >
> >Yours Irrespectively,
> >
> >John
> >
> >> >
> >> >draft-ietf-bess-evpn-overlay (see section 9) relies on the BGP
> >> >Encapsulation extended to encode the tunnel encap to use for BUM
> >> >traffic, but contrary to other E-VPN routes, relies on the Ethernet
> >> >Tag field of the NLRI to encode the VNI/VSID.
> >>
> >> [JORGE] This is certainly a leftover from an old version where the
> >> VNI/VSID was encoded in the ethernet tag for all the routes. The VNI
> >> should be encoded in the Label field in all the routes. This has to be corrected.
> >>
> >> In fact, section 5.1.3 says:
> >>
> >> 5.1.3 Constructing EVPN BGP Routes
> >>
> >> <snip>
> >>
> >> Accordingly, and
> >> specifically to support the option of locally assigned VNIs, the MPLS
> >> label field in the MAC Advertisement, Ethernet AD per EVI, and
> >> Inclusive Multicast Ethernet Tag routes is used to carry the VNI or
> >> VSID. For the balance of this memo, the MPLS label field will be
> >> referred to as the VNI/VSID field. The VNI/VSID field is used for
> >> both local and global VNIs/VSIDs, and for either case the entire 24-
> >> bit field is used to encode the VNI/VSID value.
> >>
> >> <snip>
> >
> >
> >[JD] For the IMET route the MPLS label field is carried in the PMSI attribute. I think we
> need to ask everyone whether they
> >used the Ethernet Tag or the PMSI attribute to carry the VNI
> >
> >
> >> >>
> >> >> There are minor things that could be improved in
> >> >> draft-ietf-bess-evpn-overlay wrt. consistency with
> >> >> draft-ietf-idr-tunnel-encaps :
> >> >>
> >> >> * since draft-ietf-idr-tunnel-encaps will deprecate RFC5512, it
> >> >> would be better that draft-ietf-bess-evpn-overlay refers to
> >> >> draft-ietf-idr-tunnel-encaps and not anymore to RFC5512.
> >>
> >> [JORGE] I agree, as long as draft-ietf-idr-tunnel-encaps keeps the
> >> encapsulation extended community. There are a few implementations
> >> using this community and it is enough when only the encapsulation type is needed.
> >
> >
> >[JD] I agree and the tunnel encaps draft does keep the EC
> >
> >
> >>
> >> >>
> >> >> * I think it would be better to avoid the explicit list of encap
> >> >> types in section 5.1.3, and rather refer to
> >> >> draft-ietf-idr-tunnel-encaps instead
> >>
> >> [JORGE] I agree.
> >
> >
> >[JD] According to IANA, it allocated the five tunnels types to the
> >overlay draft so I think we need to keep them
> >
> >
> >>
> >> >> * the following minor modification was proposed, but not yet incorporated:
> >> >>
> >> >> John Drake, 2015-11-13 (to BESS ML):
> >> >>> For the overlay draft, replace this text in section 5.1.3:
> >> >>>
> >> >>> "If the BGP Encapsulation extended community is not present,
> >> >>> then the default MPLS encapsulation or a statically configured
> >> >>> encapsulation is assumed."
> >> >>>
> >> >>> With the following:
> >> >>>
> >> >>> "Note that the MPLS encapsulation tunnel type is needed in
> >> >>> order to distinguish between an advertising node that only
> >> >>> supports non-MPLS encapsulations and one that supports MPLS and
> >> >>> non-MPLS encapsulations. An advertising node that only supports
> >> >>> MPLS encapsulation does not need to advertise any encapsulation
> >> >>> tunnel types; i.e., if the BGP Encapsulation extended community
> >> >>> is not present, then either MPLS encapsulation or a statically
> >> >>> configured encapsulation is assumed."
> >> >>
> >> >> I think this change is useful and should be incorporated, although
> >> >> skipping the last sentence would be wise if the full list of
> >> >> tunnel types is removed.
> >
> >
> >[JD] Fine with me either w/ or w/o the last sentence
> >
> >

 


--------------9EC6FAAA1C7FA0E7B8D59F17-- From nobody Thu May 19 05:57:35 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4706812DA3C; Thu, 19 May 2016 05:57:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160519125734.17424.86359.idtracker@ietfa.amsl.com> Date: Thu, 19 May 2016 05:57:34 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-flowspec-interfaceset-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 12:57:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : Applying BGP flowspec rules on a specific interface set Authors : Stephane Litkowski Adam Simpson Keyur Patel Jeff Haas Filename : draft-ietf-idr-flowspec-interfaceset-00.txt Pages : 13 Date : 2016-05-18 Abstract: BGP Flow-spec is an extension to BGP that allows for the dissemination of traffic flow specification rules. The primary application of this extension is DDoS mitigation where the flowspec rules are applied in most cases to all peering routers of the network. This document will present another use case of BGP Flow-spec where flow specifications are used to maintain some access control lists at network boundary. BGP Flowspec is a very efficient distributing machinery that can help in saving OPEX while deploying/updating ACLs. This new application requires flow specification rules to be applied only on a specific subset of interfaces and in a specific direction. The current specification of BGP Flow-spec does not detail where the flow specification rules need to be applied. This document presents a new interface-set flowspec action that will be used in complement of other actions (marking, rate-limiting ...). The purpose of this extension is to inform remote routers on where to apply the flow specification. This extension can also be used in a DDoS mitigation context where a provider wants to apply the filtering only on specific peers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-interfaceset/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-flowspec-interfaceset-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 20 06:06:10 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AD24412D922; Fri, 20 May 2016 06:06:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160520130606.320.81205.idtracker@ietfa.amsl.com> Date: Fri, 20 May 2016 06:06:06 -0700 Archived-At: Cc: idr-chairs@ietf.org, idr@ietf.org Subject: [Idr] idr - New Meeting Session Request for IETF 96 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 13:06:08 -0000 A new meeting session request has just been submitted by Susan Hares, a Chair of the idr working group. --------------------------------------------------------- Working Group Name: Inter-Domain Routing Area Name: Routing Area Session Requester: Susan Hares Number of Sessions: 2 Length of Session(s): 1.5 Hours, 1 Hour Number of Attendees: 75 Conflicts to Avoid: First Priority: trill i2rs i2nsf netconf bess sidr netmod rtgwg Second Priority: sdnrg nfvrg teas Third Priority: dots rtgarea Special Requests: Please group at beginning of week or end of week. You can also do a 2.5 hr session if that works for the schedule. --------------------------------------------------------- From nobody Sat May 21 03:48:16 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B25012D1D0; Sat, 21 May 2016 03:48:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160521104812.18611.97398.idtracker@ietfa.amsl.com> Date: Sat, 21 May 2016 03:48:12 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-12.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2016 10:48:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : Extended Message support for BGP Authors : Randy Bush Keyur Patel Dave Ward Filename : draft-ietf-idr-bgp-extended-messages-12.txt Pages : 5 Date : 2016-05-21 Abstract: The BGP specification mandates a maximum BGP message size of 4096 octets. As BGP is extended to support newer AFI/SAFIs, there is a need to extend the maximum message size beyond 4096 octets. This document updates the BGP specification in RFC4271 by providing an extension to BGP to extend its current message size from 4096 octets to 65535 octets. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-extended-messages-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat May 21 05:36:52 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC6712D0A2 for ; Sat, 21 May 2016 05:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XlOIivRjC-ft for ; Sat, 21 May 2016 05:36:50 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A81312B053 for ; Sat, 21 May 2016 05:36:50 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1b469A-0006Wr-K3 for idr@ietf.org; Sat, 21 May 2016 12:36:48 +0000 Date: Sat, 21 May 2016 14:36:47 +0200 Message-ID: From: Randy Bush To: idr wg list In-Reply-To: <20160521104812.18611.97398.idtracker@ietfa.amsl.com> References: <20160521104812.18611.97398.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-12.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2016 12:36:51 -0000 the change was to error handling. jgs did the heavy lifting, tyvm. OLD 5. Error Handling A BGP speaker that has the ability to use extended messages but has not advertised the BGP Extended Messages capability, presumably due to configuration, SHOULD NOT accept such a message. However, a BGP speaker that does not advertise the BGP Extended Messages capability might also genuinely not support extended messages. Such a speaker would be expected to follow the error handling procedures of [RFC4221], Section 6.1, and reset the session with a Bad Message Length NOTIFICATION if it receives an extended message. A speaker that treats an improper extended message as a fatal error should do likewise. NEW 5. Error Handling A BGP speaker that has the ability to use extended messages but has not advertised the BGP Extended Messages capability, presumably due to configuration, SHOULD NOT accept an extended message. A speaker MAY implement a more liberal policy and accept extended messages even from a peer that has not advertised the capability. However, a BGP speaker that does not advertise the BGP Extended Messages capability might also genuinely not support extended messages. Such a speaker would be expected to follow the error handling procedures of [RFC4221], Section 6.1, and reset the session with a Bad Message Length NOTIFICATION if it receives an extended message. A speaker that treats an improper extended message as a fatal error, as described in the preceding paragraph, MUST do likewise. randy From nobody Mon May 23 04:49:15 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 95C2312D75C; Mon, 23 May 2016 04:49:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160523114912.10810.98975.idtracker@ietfa.amsl.com> Date: Mon, 23 May 2016 04:49:12 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-route-leak-detection-mitigation-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 11:49:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : Methods for Detection and Mitigation of BGP Route Leaks Authors : Kotikalapudi Sriram Doug Montgomery Brian Dickson Keyur Patel Andrei Robachevsky Filename : draft-ietf-idr-route-leak-detection-mitigation-03.txt Pages : 22 Date : 2016-05-23 Abstract: [I-D.ietf-grow-route-leak-problem-definition] provides a definition of the route leak problem, and also enumerates several types of route leaks. This document first examines which of those route-leak types are detected and mitigated by the existing origin validation (OV) [RFC 6811]. It is recognized that OV offers a limited detection and mitigation capability against route leaks. This document specifies enhancements that significantly extend the route-leak prevention, detection, and mitigation capabilities of BGP. One solution component involves carrying a per-hop route-leak protection (RLP) field in BGP updates. The RLP field is proposed be carried in a new optional transitive attribute, called BGP RLP attribute. The solution is meant to be initially implemented as an enhancement of BGP without requiring BGPsec [I-D.ietf-sidr-bgpsec-protocol]. However, when BGPsec is deployed in the future, the solution can be incorporated in BGPsec, enabling cryptographic protection for the RLP field. That would be one way of implementing the proposed solution in a secure way. The document also includes a stopgap method for detection and mitigation of route leaks for an intermediate phase when OV is deployed but BGP protocol on the wire is unchanged. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-route-leak-detection-mitigation/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigation-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-route-leak-detection-mitigation-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 23 05:32:07 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A584612D7F0 for ; Mon, 23 May 2016 05:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0Ik9Fqvqf0W for ; Mon, 23 May 2016 05:32:02 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0092.outbound.protection.outlook.com [23.103.201.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32AB312D617 for ; Mon, 23 May 2016 05:32:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ID1L1Ye9Q7a1lYKxsSLLwfnRxHdZxGFqEJJYoNL9VUU=; b=0dRLl+b+I1c3hUtu4MfREiX+jQqLSDJwQNu5mYhKZdpdqbYTcinmOEonwvfLYh1XEZHJY5wNjfRKNAzp8PCV910F9iwlMWB1D49NmZk9/1jHVKaxjxj9Xrgn7ydE59Chl4D7s3j3/m7qnrbTxINs1h5H4Ena7vsQVLfTTOzQhDE= Received: from BL2PR09MB1123.namprd09.prod.outlook.com (10.167.102.151) by BL2PR09MB1121.namprd09.prod.outlook.com (10.167.102.149) with Microsoft SMTP Server (TLS) id 15.1.497.12; Mon, 23 May 2016 12:31:59 +0000 Received: from BL2PR09MB1123.namprd09.prod.outlook.com ([10.167.102.151]) by BL2PR09MB1123.namprd09.prod.outlook.com ([10.167.102.151]) with mapi id 15.01.0497.019; Mon, 23 May 2016 12:31:59 +0000 From: "Sriram, Kotikalapudi (Fed)" To: IDR Thread-Topic: New Version Notification for draft-ietf-idr-route-leak-detection-mitigation-03.txt Thread-Index: AQHRtOkgZGSV5fzs80aP7Sr3qJiy25/Gc+0o Date: Mon, 23 May 2016 12:31:59 +0000 Message-ID: References: <20160523114912.10810.33843.idtracker@ietfa.amsl.com> In-Reply-To: <20160523114912.10810.33843.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.218.196] x-ms-office365-filtering-correlation-id: adbc10c4-b49d-4f10-0026-08d383063c5e x-microsoft-exchange-diagnostics: 1; BL2PR09MB1121; 5:aUHZcsuwkMhcD/bEI/Mlo/Bnh4cPyWtEH+4J2OWRWOXrRHuq6R6mkvBxo15BjPvZ8FUGbwLhk6CwdzGKTr3lo2Hg7ep6L7vxhQCTlEqK7VQ62xFueVx0zd/Cx5zt+vd8Gz91MtWRypVW6+6SltnjXA==; 24:0jstuxhtlHg2z3Emu1pK747g+JReTZTEmrltud9uCJtniVDOokDbuil8X3jgFso9tKu3iuGAgdCGuaUgxCr6h8Xy86231PPafOa2gRZLKZE=; 7:mJn0Zkz+lkhoWlNFaAxI4C0jM++iRlxk62HmJM9K8rqkhsNKzQquOPpxcSutGag2AVOnckk2dxrdYFDrLpCn27/g0qysywrW+x2jWrLak6bE+C94wtUbRnvR8DdVCtxiSRQ11YkPxbTDE/9o7ZMgDRxIP+n132UcujDLRNGk9mSb5dwrXlWWlWoymmkK582n x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR09MB1121; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:BL2PR09MB1121; BCL:0; PCL:0; RULEID:; SRVR:BL2PR09MB1121; x-forefront-prvs: 0951AB0A30 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(377424004)(10400500002)(74316001)(230783001)(6116002)(3280700002)(99286002)(2906002)(15975445007)(5004730100002)(5008740100001)(110136002)(50986999)(81166006)(106116001)(8676002)(189998001)(77096005)(54356999)(19580395003)(586003)(122556002)(107886002)(19580405001)(76176999)(86362001)(11100500001)(450100001)(3846002)(5003600100002)(1220700001)(5002640100001)(66066001)(2950100001)(102836003)(33656002)(9686002)(8936002)(76576001)(87936001)(15650500001)(3900700001)(92566002)(2900100001)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR09MB1121; H:BL2PR09MB1123.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 23 May 2016 12:31:59.0520 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR09MB1121 Archived-At: Subject: [Idr] Fw: New Version Notification for draft-ietf-idr-route-leak-detection-mitigation-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 12:32:06 -0000 This new version is a significant improvement both in terms of substance an= d clarity of presentation. It has the following substantive additions: 1. Section 3.1.1 specifies the TLV format for a new BGP RLP attribute. =20 2. It is important that the ingress and egress routers within an AS are coo= rdinated for route leak prevention. The new Section 3.2 =93Intra-AS Messaging for Ro= ute Leak Prevention=94 talks about this, and outlines the common practice amongst large ISPs with = regard to this. 3. Section 5.5 discusses the topic =93Per-Hop RLP Flags or Single RLP Flag = per Update?=94 It is observed that the Per-Hop RLP Flags method is more robust in the pres= ence of=20 partial deployment and/or faulty implementation in some ASes along the path= .=20 A presentation was made at IETF-95 on this topic (slides 5-9): https://www.ietf.org/proceedings/95/slides/slides-95-idr-13.pdf=20 4. Section 3.1.2 talks about how in the future the per-hop RLP encodings wi= ll be carried=20 in existing BGPsec Flags to provide cryptographic protection. =20 We (the authors) thank many who have provided comments so far on this work.= =20 Welcome further comments and suggestions. Sriram ________________________________________ From: internet-drafts@ietf.org Sent: Monday, May 23, 2016 7:49 AM To: Brian Dickson; Montgomery, Douglas (Fed); Keyur Patel; Andrei Robachevs= ky; Sriram, Kotikalapudi (Fed) Subject: New Version Notification for draft-ietf-idr-route-leak-detection-m= itigation-03.txt A new version of I-D, draft-ietf-idr-route-leak-detection-mitigation-03.txt has been successfully submitted by Kotikalapudi Sriram and posted to the IETF repository. Name: draft-ietf-idr-route-leak-detection-mitigation Revision: 03 Title: Methods for Detection and Mitigation of BGP Route Leaks Document date: 2016-05-23 Group: idr Pages: 22 URL: https://www.ietf.org/internet-drafts/draft-ietf-idr-route-l= eak-detection-mitigation-03.txt Status: https://datatracker.ietf.org/doc/draft-ietf-idr-route-leak-= detection-mitigation/ Htmlized: https://tools.ietf.org/html/draft-ietf-idr-route-leak-detec= tion-mitigation-03 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-route-le= ak-detection-mitigation-03 Abstract: [I-D.ietf-grow-route-leak-problem-definition] provides a definition of the route leak problem, and also enumerates several types of route leaks. This document first examines which of those route-leak types are detected and mitigated by the existing origin validation (OV) [RFC 6811]. It is recognized that OV offers a limited detection and mitigation capability against route leaks. This document specifies enhancements that significantly extend the route-leak prevention, detection, and mitigation capabilities of BGP. One solution component involves carrying a per-hop route-leak protection (RLP) field in BGP updates. The RLP field is proposed be carried in a new optional transitive attribute, called BGP RLP attribute. The solution is meant to be initially implemented as an enhancement of BGP without requiring BGPsec [I-D.ietf-sidr-bgpsec-protocol]. However, when BGPsec is deployed in the future, the solution can be incorporated in BGPsec, enabling cryptographic protection for the RLP field. That would be one way of implementing the proposed solution in a secure way. The document also includes a stopgap method for detection and mitigation of route leaks for an intermediate phase when OV is deployed but BGP protocol on the wire is unchanged. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Mon May 23 10:42:42 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01B6812D9EE for ; Mon, 23 May 2016 10:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prz39YgiB4S8 for ; Mon, 23 May 2016 10:42:39 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89E5012D0AA for ; Mon, 23 May 2016 10:42:38 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id u4NHgZUA027599 for ; Mon, 23 May 2016 18:42:35 +0100 Received: from 950129200 (jplon-nat13.juniper.net [193.110.55.13]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id u4NHgX2G027585 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 23 May 2016 18:42:34 +0100 From: "Adrian Farrel" To: Date: Mon, 23 May 2016 18:42:32 +0100 Message-ID: <01ea01d1b51a$7cf31e60$76d95b20$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdG1GnjM0FP4vAcnRKiZoSNePCQ+mQ== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22342.001 X-TM-AS-Result: No--1.259-10.0-31-10 X-imss-scan-details: No--1.259-10.0-31-10 X-TMASE-MatchedRID: UNHYJMizeW6cJAW1zaJMCnBRIrj8R47Fu2rcU2ygxCDPG88r4cu+5DLk 8G2qhCWTeAd/PTpyYH8Uc5C62VlM+XQg3fSSAxs4KWuiyZLRI4CYZJKiXhR6LQzvg1/q1MH2eDg I4iMaw3IhJ/ufappeEpGTpe1iiCJqtD9qpBlNF8rQLWxBF9DMQcRB0bsfrpPIcSqbxBgG0w7OeU hYDpKLDTlm879hveZWNw0xttaZNeBLmHwea/if6Z1t3K32SzMkDV6DA7GniOWFbxXgRQBZyRvQc Ths494OBQb0fpm0/XGl1O/WvQ0mLI9NJFPyrFBRLg4B6mj6omcF5vvBn7Kcsw== Archived-At: Subject: [Idr] New draft for data center gateways X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 17:42:41 -0000 Hi, Just posted https://datatracker.ietf.org/doc/draft-drake-bess-datacenter-gateway/ We think this covers an important hole. The document defines a mechanism using the BGP Tunnel Encapsulation attribute to allow each gateway router to advertise the routes to the prefixes in the data center site to which it provides access, and also to advertise on behalf of each other gateway to the same data center site. We posted this as BESS draft, so discussion there, please until such time that the various chairs tell us to move the discussion somewhere else. Thanks, Adrian From nobody Mon May 23 11:14:47 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11CB312DA5B; Mon, 23 May 2016 11:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cp0J98LVTWpX; Mon, 23 May 2016 11:14:42 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE82612D0DE; Mon, 23 May 2016 11:14:41 -0700 (PDT) Received: by mail-lb0-x233.google.com with SMTP id ww9so58073851lbc.2; Mon, 23 May 2016 11:14:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=fOjztvU2+CFyeUxiW+I6PSvV3Swo6RwMC0qvvMwWS3Y=; b=XKCd4oXiiulLzIm1CYLLvXujAIlhp7YnrrUGvdmQT+wLoHNGi1oUNK5fI/242/02hq kuBT58Seq83auB0r9xusm50DfoWmlnuU2T6+d+wbpT6Rc2AGCnCo2wjZsBYibRGZ7mp+ r7HUBnErjro1x36LsBHi3NVJVniNbRc0wHEnX07Ktmqu9bCLzckrz7Kl+I9c1vu/gqm4 rKAvcYtpaHaEc5/e/8RJUWhGny18iqGoGmMsWGEx4tgza1SnVrgmG+fWrnUlAcHmmAr+ 1JHXQfWg++n0ZJdHl4uRsZoZ2fmr9wh75+jNNa4p8koMkTiUH+s/qZSlfwIU2qDiyfVg ZlXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=fOjztvU2+CFyeUxiW+I6PSvV3Swo6RwMC0qvvMwWS3Y=; b=iY0Qmwzmy3HfDvR54lsPkqnISQusFxa+O4DrGsXJLNmkuVsqnycfu6JCNhx+J9mlMn 0YyBH7Qqy0O02b022QoiEm875AagJxeGGEeLi/h5mgNZpU2c6/ANh0MHAq1crpCXxLR/ AtWnYsWpPUSevl8D6cdtoTvMk/DPhgDa/otAm/By3S8UqjnXmgAWESlfKKhorCjC9BKJ Li8Jwm1TaeAzb4wdDqNnJhDk1VUXD571pdOtsemqMWJk+puS91f5679FkQcJjezOEbyx awXALJLkPJXhvU+lh+lCy3tCoKyXW2nR0iYNxS+l738RJXIyEI60igJNXJVKDhKa4Rvf 5Xjw== X-Gm-Message-State: AOPr4FU7Nrm5oasCvintQSEJm18wodvx21l7yRX/8Gx5yrFZD533q9CD2uMrnIiX/cdr/hwNsnOooCzcBA4agQ== MIME-Version: 1.0 X-Received: by 10.112.171.229 with SMTP id ax5mr6361704lbc.115.1464027279811; Mon, 23 May 2016 11:14:39 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.25.126.210 with HTTP; Mon, 23 May 2016 11:14:39 -0700 (PDT) In-Reply-To: <01ea01d1b51a$7cf31e60$76d95b20$@olddog.co.uk> References: <01ea01d1b51a$7cf31e60$76d95b20$@olddog.co.uk> Date: Mon, 23 May 2016 20:14:39 +0200 X-Google-Sender-Auth: Z9SdVtFWHNYgaik99yYZjvUtN34 Message-ID: From: Robert Raszuk To: Adrian Farrel Content-Type: multipart/alternative; boundary=001a11c36ed6f46cf505338669e7 Archived-At: Cc: idr wg , "spring@ietf.org" Subject: Re: [Idr] New draft for data center gateways X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 18:14:45 -0000 --001a11c36ed6f46cf505338669e7 Content-Type: text/plain; charset=UTF-8 Hi Adrian, Many thx for sharing the document. Just starting to read it one assertion repeated at least twice got my attention: "Segment routing (SR) [I-D.ietf-spring-segment-routing] is a popular protocol mechanism for operating within a DC" By "popular protocol mechanism" when building non blocking L3 CLOS IP fabric are you referring to the below proposal or something else ? https://tools.ietf.org/html/draft-filsfils-spring-large-scale-interconnect-02 Also by "popular" do you mean something which is perhaps deployed in production to any level or author's definition of "popular" refers to something real deployment are yet to see ? Honestly having been involved in building large scale data centers for the last few years I have not see SR being anywhere close to be used there. Especially MPLS flavor of it :) If anything within DCs draft-lapukhov-bgp-sdn-00 is easy to use and provides more then sufficient flexibility within properly constructed intra-dc fabric in terms of traffic engineering. Many thx, Robert. On Mon, May 23, 2016 at 7:42 PM, Adrian Farrel wrote: > Hi, > > Just posted > https://datatracker.ietf.org/doc/draft-drake-bess-datacenter-gateway/ > > We think this covers an important hole. The document defines a mechanism > using > the BGP Tunnel Encapsulation attribute to allow each gateway router to > advertise > the routes to the prefixes in the data center site to which it provides > access, > and also to advertise on behalf of each other gateway to the same data > center > site. > > We posted this as BESS draft, so discussion there, please until such time > that > the various chairs tell us to move the discussion somewhere else. > > Thanks, > Adrian > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --001a11c36ed6f46cf505338669e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Adrian,

=
Many thx for sharing the document. Just starting t= o read it one assertion repeated at least twice got my attention:=C2=A0

"Segment routing (SR= ) [I-D.ietf-spring-segment-routing] is a popular
protocol mechanism= for operating within a DC"

By "popular protocol mechanism" when building non bloc= king L3 CLOS IP fabric are you referring to the below proposal or something= else ?=C2=A0

htt= ps://tools.ietf.org/html/draft-filsfils-spring-large-scale-interconnect-02<= /a>

Also by "popula= r" do you mean something which is perhaps deployed in production to an= y level or author's definition of "popular" refers to somethi= ng real deployment are yet to see ?

<= div class=3D"gmail_default" style=3D"">Honestly having been involved in building large scale data centers = for the last few years I have not see SR being anywhere close to be used th= ere. Especially MPLS flavor of it :)=C2=A0

=
If anything within DCs=C2=A0draft-lapukhov-bgp-sdn-00 is eas= y to use and provides more then sufficient flexibility within properly cons= tructed intra-dc fabric in terms of traffic engineering.=C2=A0
=

Many thx,
Robert.


On Mon, May 23, 2016 at 7= :42 PM, Adrian Farrel <adrian@olddog.co.uk> wrote:
Hi,

Just posted
https://datatracker.ietf.org/do= c/draft-drake-bess-datacenter-gateway/

We think this covers an important hole. The document defines a mechanism us= ing
the BGP Tunnel Encapsulation attribute to allow each gateway router to adve= rtise
the routes to the prefixes in the data center site to which it provides acc= ess,
and also to advertise on behalf of each other gateway to the same data cent= er
site.

We posted this as=C2=A0 BESS draft, so discussion there, please until such = time that
the various chairs tell us to move the discussion somewhere else.

Thanks,
Adrian

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

--001a11c36ed6f46cf505338669e7-- From nobody Mon May 23 12:35:15 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D97E12DAE8; Mon, 23 May 2016 12:35:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160523193512.20868.37891.idtracker@ietfa.amsl.com> Date: Mon, 23 May 2016 12:35:12 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-add-paths-15.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 19:35:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : Advertisement of Multiple Paths in BGP Authors : Daniel Walton Alvaro Retana Enke Chen John Scudder Filename : draft-ietf-idr-add-paths-15.txt Pages : 8 Date : 2016-05-23 Abstract: This document defines a BGP extension that allows the advertisement of multiple paths for the same address prefix without the new paths implicitly replacing any previous ones. The essence of the extension is that each path is identified by a path identifier in addition to the address prefix. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-add-paths/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-add-paths-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-add-paths-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 23 13:14:29 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78BF212DB4B; Mon, 23 May 2016 13:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60k_ee88fKW2; Mon, 23 May 2016 13:14:19 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E308D12DB4E; Mon, 23 May 2016 13:14:18 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id k98so18772483lfi.1; Mon, 23 May 2016 13:14:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=2kDeyHDSc7khB8jmY/f0GyF3Mjuhy7QoH9ycjxxxals=; b=aYNSRIaKcexjiRCvvV2fYVZnCZJHDHnKmv50Bwl69kP6028nKgxadstLeiu7XqquRO JQEkbAWhQQYTwaumbdBi72mHfKO6dNF0C7s0OpJH/bu/bQ9irpQ+mRXW8jFwhUXWcbzz BQW/1oT5378SA7mDT7QD+O+G25PyMR6WILH//u1vv68wliIFxAT5RxswynXMgpE1sJXD YXFJOmteeucEwD3qaYzPtM82UYzHvSR9sD3n/S/SqM5Mu2RwHPGJgvC4/QlJcpvp6/yT kbaiwgPZFsimL5WeE/JuVmG3HyY1N14hlQJkzlm8J4jGPYXNDDejlVM3VRH8SeE6BrbJ PehA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=2kDeyHDSc7khB8jmY/f0GyF3Mjuhy7QoH9ycjxxxals=; b=kOfdm8XtwE24/bbr9MRVXQPuBmim/jSbdm9nIt7fKAMtb7mSa8UIPkOue7bWdh+hSV GO22yrKBEtNYeHQfUPqS5upwLjukMKsBmuQEsTDI6nkT7oqVjr0jfdQGU4LTmQWkJSwI BxtIMBB6wfVJi7IN79UCdGACUU+dQmVyJHYgliS006vT13mYeUYU/oadjFTqG66+du2R o8lNyWS4epsJU5S9hgHD6u0WRHgOnar+io51EnDw/Zm73B5jKwYKlHgeNyKp1xjspIrB Nd+m/b/GLkOzuKMaeDJWJH87mBVEcHofsh4FB1xf9lf5sgSedMgr4KZBiXftuJZiJRl+ U2IA== X-Gm-Message-State: AOPr4FX0OOjw/mDGuF4EX4VGhOVv1VzOTekNAJJ3ACZCW3YBndH0ip/ei0bzka04y3L536kMmWxM6Jj8od6SBw== MIME-Version: 1.0 X-Received: by 10.25.18.26 with SMTP id h26mr5800553lfi.110.1464034456942; Mon, 23 May 2016 13:14:16 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.25.126.210 with HTTP; Mon, 23 May 2016 13:14:16 -0700 (PDT) In-Reply-To: References: <01ea01d1b51a$7cf31e60$76d95b20$@olddog.co.uk> Date: Mon, 23 May 2016 22:14:16 +0200 X-Google-Sender-Auth: _qjQmktN64d7CqR4Y63_zC14EUc Message-ID: From: Robert Raszuk To: Adrian Farrel Content-Type: multipart/alternative; boundary=001a113f8f70bebf6a0533881518 Archived-At: Cc: idr wg , "spring@ietf.org" Subject: Re: [Idr] New draft for data center gateways X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 20:14:25 -0000 --001a113f8f70bebf6a0533881518 Content-Type: text/plain; charset=UTF-8 Dear Authors, Question 1: Assume that prefix X has been advertised with tunnel attribute as described in the draft with both GW1 and GW2 entry points to Egress DC site. So remote GW in Ingress DC site receives at least one such advertisement and as each contains both GW1 and GW2 entries it can engineer flows to those. So far so good ... but what happens when link between PE (on left side) and GW1 goes down ? BGP will after some time remove that path via all ASes, but GW2 will keep advertsing prefix X as still reachable via both GW1 and GW2 within tunnel encapsulation attribute as from his perspective nothing will be wrong. How remote GW in Ingress DC site is now supposed to know that GW1 link to PE in AS2 went down and stop pushing traffic towards it ? - - - Question 2: What happens if all L3 DC CLOS IP Fabrics use eBGP not IGP ? - - - Question 3: Is per prefix tunnel attribute where say /32 routes may be exchanges flat (ref calico approach - https://www.projectcalico.org/) really a scalable solution ? Best, Robert. PS. Just purely as information your inter DC traffic steering problem description is easily solved already today with one level of indirection - Example: LISP. Not sure if we need additional flat protocol extensions here. On Mon, May 23, 2016 at 8:14 PM, Robert Raszuk wrote: > Hi Adrian, > > Many thx for sharing the document. Just starting to read it one assertion > repeated at least twice got my attention: > > "Segment routing (SR) [I-D.ietf-spring-segment-routing] is a popular > protocol mechanism for operating within a DC" > > By "popular protocol mechanism" when building non blocking L3 CLOS IP > fabric are you referring to the below proposal or something else ? > > > https://tools.ietf.org/html/draft-filsfils-spring-large-scale-interconnect-02 > > Also by "popular" do you mean something which is perhaps deployed in > production to any level or author's definition of "popular" refers to > something real deployment are yet to see ? > > Honestly having been involved in building large scale data centers for the > last few years I have not see SR being anywhere close to be used there. > Especially MPLS flavor of it :) > > If anything within DCs draft-lapukhov-bgp-sdn-00 is easy to use and > provides more then sufficient flexibility within properly constructed > intra-dc fabric in terms of traffic engineering. > > Many thx, > Robert. > > > On Mon, May 23, 2016 at 7:42 PM, Adrian Farrel > wrote: > >> Hi, >> >> Just posted >> https://datatracker.ietf.org/doc/draft-drake-bess-datacenter-gateway/ >> >> We think this covers an important hole. The document defines a mechanism >> using >> the BGP Tunnel Encapsulation attribute to allow each gateway router to >> advertise >> the routes to the prefixes in the data center site to which it provides >> access, >> and also to advertise on behalf of each other gateway to the same data >> center >> site. >> >> We posted this as BESS draft, so discussion there, please until such >> time that >> the various chairs tell us to move the discussion somewhere else. >> >> Thanks, >> Adrian >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> > > --001a113f8f70bebf6a0533881518 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Authors,
<= br>
Question 1:

<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small">Assume that prefix X has been advertised with tunnel attr= ibute as described in the draft with both GW1 and GW2 entry points to Egres= s DC site.=C2=A0

So re= mote GW in Ingress DC site receives at least one such advertisement and as = each contains both GW1 and GW2 entries it can engineer flows to those.=C2= =A0

So far so good ...= but what happens when link between PE (on left side) and GW1 goes down ?= =C2=A0

BGP will after = some time remove that path via all ASes, but GW2 will keep advertsing prefi= x X as still reachable via both GW1 and GW2 within tunnel encapsulation att= ribute as from his perspective nothing will be wrong.=C2=A0

How remote GW in Ingress DC site is n= ow supposed to know that GW1 link to PE in AS2 went down and stop pushing t= raffic towards it ?=C2=A0

- - -=C2=A0

Questi= on 2:=C2=A0

What happe= ns if all L3 DC CLOS IP Fabrics use eBGP not IGP ?=C2=A0

- - -=C2=A0

=
Question 3:=C2=A0

Is per prefix tunnel attribute where say /32 routes ma= y be exchanges flat (ref calico approach - https://www.projectcalico.org/) really a scalable solution ?= =C2=A0


Best,
Robert.

PS. Just purely as information your inter DC = traffic steering problem description is easily solved already today with on= e level of indirection - Example: LISP. Not sure if we need additional flat= protocol extensions here.=C2=A0



On Mon, May 23, 2016 at 8:14 PM, Robert Raszuk= <robert@raszuk.net> wrote:
= Hi Adrian,

Many thx for sharing the document. Just starting to read it= one assertion repeated at least twice got my attention:=C2=A0

"S= egment routing (SR) [I-D.ietf-spring-segment-routing] is a popular
protocol mechanism for o= perating within a DC"

By "popular protocol mechanism" w= hen building non blocking L3 CLOS IP fabric are you referring to the below = proposal or something else ?=C2=A0

=

Also by "popular" do you = mean something which is perhaps deployed in production to any level or auth= or's definition of "popular" refers to something real deploym= ent are yet to see ?

Ho= nestly having been involved in building large scale data centers for the la= st few years I have not see SR being anywhere close to be used there. Espec= ially MPLS flavor of it :)=C2=A0

If anything within DCs=C2=A0draft-lapukhov-bgp-sdn-00 is easy to = use and provides more then sufficient flexibility within properly construct= ed intra-dc fabric in terms of traffic engineering.=C2=A0
=
Many thx,
Robert.


On Mon, May 23, 2016 at 7:42 PM, Adrian Farrel <adrian@old= dog.co.uk> wrote:
Hi,

Just posted
https://datatracker.ietf.org/do= c/draft-drake-bess-datacenter-gateway/

We think this covers an important hole. The document defines a mechanism us= ing
the BGP Tunnel Encapsulation attribute to allow each gateway router to adve= rtise
the routes to the prefixes in the data center site to which it provides acc= ess,
and also to advertise on behalf of each other gateway to the same data cent= er
site.

We posted this as=C2=A0 BESS draft, so discussion there, please until such = time that
the various chairs tell us to move the discussion somewhere else.

Thanks,
Adrian

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr


--001a113f8f70bebf6a0533881518-- From nobody Mon May 23 14:55:40 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3775712D57C; Mon, 23 May 2016 14:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYUnW1mbuh5U; Mon, 23 May 2016 14:55:32 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 701F512D57B; Mon, 23 May 2016 14:55:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6218; q=dns/txt; s=iport; t=1464040532; x=1465250132; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=NMqNbEsBvivAUiqzwpPv3RbYTN2RTP//+h0ok2H4Fvw=; b=c3/j/tCLtKqFefXxZYHn4qRN9tLzg6q4n/JSU0VuNqZUXA8KKM8ixsjH H0vX5g9OBsqjRwtJqOADlb0NVoASwpV4lkVqbZx7rwF66z+wThVJ9jtxH cSVo2NH/AbJX5gecsTPFu1+JBiBSoZzIdOYEUwxckup1vasTJGKHAGYwl s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAgBUe0NX/4MNJK1cgzeBUwa3bIIPA?= =?us-ascii?q?Q2Bd4YRAoE2OBQBAQEBAQEBZSeEQwEBBDo/EAIBCDYQMiUCBA4FiC/DbgEBAQE?= =?us-ascii?q?BAQEDAQEBAQEBAQEfhieETYoZAQSTN4UAAY4fgWmET4hkj0sBHgEBQoI4gTVui?= =?us-ascii?q?FJ/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,357,1459814400"; d="scan'208";a="111001907" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 May 2016 21:55:31 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u4NLtVo2030393 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 23 May 2016 21:55:31 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 23 May 2016 16:55:30 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Mon, 23 May 2016 16:55:31 -0500 From: "Alvaro Retana (aretana)" To: Jari Arkko Thread-Topic: Jari Arkko's Discuss on draft-ietf-idr-route-oscillation-stop-03: (with DISCUSS and COMMENT) Thread-Index: AQHRprRTmhXdCvFQWUW3H4yt0d2g+J+qizoAgByzwQA= Date: Mon, 23 May 2016 21:55:31 +0000 Message-ID: References: <20160505095556.15385.64588.idtracker@ietfa.amsl.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.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <25FD23D7EE023548BC3F201FA2D40D20@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-idr-route-oscillation-stop@ietf.org" , "idr@ietf.org" , "idr-chairs@ietf.org" , "pkyzivat@alum.mit.edu" , The IESG , Susan Hares Subject: Re: [Idr] Jari Arkko's Discuss on draft-ietf-idr-route-oscillation-stop-03: (with DISCUSS and COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 21:55:34 -0000 On 5/5/16, 11:36 AM, "Alvaro Retana (aretana)" wrote: Jari: Hi! Took me longer than I thought... Please see below and let me know if you think it is clearer -- I'll then include it in the next version. Thanks! Alvaro. >> >> >> >>>When the ADD-PATH Capability is also received from >>>the IBGP peer with the "Send/Receive" field set to 1 (receive >>>multiple paths) or 3 (send/receive multiple paths) for the same >>SAFI>, then the following procedures shall be followed: >>>If the peer is a route reflection client, the route reflector SHOULD >>>advertise to the peer the Group Best Paths (or the Available Paths) >>>received from its non-client IBGP peers. Depending on the >>>configuration, the route reflector MAY also advertise to the peer the >>>Group Best Paths (or the Available Paths) received from its clients. >> >>I am picking this text excerpt as an example. >> >>Like Paul, some of this language makes me slightly uncomfortable, >>and it would be good to understand what the aim is. If the intent >>is to describe a procedure that can be followed and fully specified, >>the expectations on the text are different from an informative >>description of the kinds of things an implementation could do. >> >>In the above text, there's quite a lot of imprecision. That may >>be fine, but I wanted to check that this is the case. >> >>For instance, why is a "shall" (and in lowercase) followed by >>a set of "SHOULD"s and "MAY"s? Is there any guidance on >>when the "SHOULD"s should be followed? There seems to >>be thinking behind, could that be documented? What kind >>of configuration issues affect the decisions? > >Yes, I see what you mean. I think that at the time we wrote the text we >were probably thinking in terms of "SHOULD" because this is one of the >options (Group Best Paths vs All the Paths), but within that option we can >be more precise. > >We will work on clarifying and get back to you -- I'm traveling, so it >might take a couple of days. OLD> 5.1. Route Reflection Depending on the configuration, for a particular a route reflector SHOULD include the with the "Send/Receive" field set to 2 (send multiple paths) or 3 (send/receive multiple paths) in the ADD-PATH Capability [I-D.ietf-idr-add-paths] advertised to an IBGP peer. When the ADD-PATH Capability is also received from the IBGP peer with the "Send/Receive" field set to 1 (receive multiple paths) or 3 (send/receive multiple paths) for the same , then the following procedures shall be followed: If the peer is a route reflection client, the route reflector SHOULD advertise to the peer the Group Best Paths (or the Available Paths) received from its non-client IBGP peers. Depending on the configuration, the route reflector MAY also advertise to the peer the Group Best Paths (or the Available Paths) received from its clients. If the peer is a non-client, the route reflector SHOULD advertise to the peer the Group Best Paths (or the Available Paths) received from its clients. 5.2. Confederation Depending on the configuration, for a particular a confederation ASBR SHOULD include the with the "Send/ Receive" field set to 2 (send multiple paths) or 3 (send/receive multiple paths) in the ADD-PATH Capability [I-D.ietf-idr-add-paths] advertised to an IBGP peer, and to a confederation external peer. When the ADD-PATH Capability is also received from the IBGP peer or the confederation external peer with the "Send/Receive" field set to 1 (receive multiple paths) or 3 (send/receive multiple paths) for the same , then the following procedures shall be followed: If the peer is internal, the confederation ASBR SHOULD advertise to the peer the Group Best Paths (or the Available Paths) received from its confederation external peers. If the peer is confederation external, the confederation ASBR SHOULD advertise to the peer the Group Best Paths (or the Available Paths) received from its IBGP peers. NEW> 5.1. Route Reflection For a particular a route reflector MUST include the with the "Send/Receive" field set to 2 (send multiple paths) or 3 (send/receive multiple paths) in the ADD-PATH Capability [I-D.ietf-idr-add-paths] advertised to an IBGP peer. When the ADD- PATH Capability is also received from the IBGP peer with the "Send/ Receive" field set to 1 (receive multiple paths) or 3 (send/receive multiple paths) for the same , then the following procedures apply: If the peer is a route reflection client, the route reflector MUST advertise to the peer the Group Best Paths (or the Available Paths) received from its non-client IBGP peers. The route reflector MAY also advertise to the peer the Group Best Paths (or the Available Paths) received from its clients. If the peer is a non-client, the route reflector MUST advertise to the peer the Group Best Paths (or the Available Paths) received from its clients. 5.2. Confederation For a particular a confederation ASBR MUST include the with the "Send/Receive" field set to 2 (send multiple paths) or 3 (send/receive multiple paths) in the ADD-PATH Capability [I-D.ietf-idr-add-paths] advertised to an IBGP peer, and to a confederation external peer. When the ADD-PATH Capability is also received from the IBGP peer or the confederation external peer with the "Send/Receive" field set to 1 (receive multiple paths) or 3 (send/receive multiple paths) for the same , then the following procedures apply: If the peer is internal, the confederation ASBR MUST advertise to the peer the Group Best Paths (or the Available Paths) received from its confederation external peers. If the peer is confederation external, the confederation ASBR MUST advertise to the peer the Group Best Paths (or the Available Paths) received from its IBGP peers. From nobody Tue May 24 00:05:09 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8427D12B05A; Tue, 24 May 2016 00:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvVjk8lWjMEX; Tue, 24 May 2016 00:05:05 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2DE912DC93; Tue, 24 May 2016 00:05:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4163; q=dns/txt; s=iport; t=1464073504; x=1465283104; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=MvFqDCCCrZythjYULMjAVNpua+WgftkCbCUEQp+3gIs=; b=ge0sewN2EZOBkNV2VJ6hl1k6hkYe4QtsYoNOAI68v7KfSV6dMy8jLeVC Pff0JgDHvd13i/cnck1enDi08HPDuL/n28gEbhautN2rUyM5Sr1s8Jkfg 3aJLrOkvvDaFibfg0zuefypEBmUfI5A87tWVNEKlj5+2cwuHZ/UA1zjYe o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BPAgDt/ENX/5hdJa1bgmxLVoEDtH6Ee?= =?us-ascii?q?QENgXYihW8CgTA4FAEBAQEBAQFlJ4RDAQEEgQkCAQgEQjIlAgQBiEEOxCEBAQE?= =?us-ascii?q?BAQEBAQIBAQEBAQEBAQEZBYpzihkFjh2KGgGFf4ggjxyPSwEeAQFCg22JQH8BA?= =?us-ascii?q?QE?= X-IronPort-AV: E=Sophos;i="5.26,359,1459814400"; d="scan'208,217";a="105753673" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 May 2016 07:04:54 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u4O74sqa012658 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 24 May 2016 07:04:54 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 24 May 2016 03:04:54 -0400 Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1104.009; Tue, 24 May 2016 03:04:53 -0400 From: "Ali Sajassi (sajassi)" To: John E Drake , Thomas Morin , IDR , BESS , "draft-ietf-bess-evpn-overlay@tools.ietf.org" , "Rabadan, Jorge (Nokia - US)" , "draft-ietf-idr-tunnel-encap@tools.ietf.org" Thread-Topic: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps Thread-Index: AQHRpi++kmVRnOfCCEaLlUJwLCbjV5+pXciAgAAV74CAABx8AIAAAd6AgAD40oCAAAcLgIAAlB8AgAAObQCAE5+SgIAAQjEAgAiAQYA= Date: Tue, 24 May 2016 07:04:53 +0000 Message-ID: References: <5729F1C3.1030605@orange.com> <5729F7C5.6040604@orange.com> <52D35106-ED5E-4C95-9131-6EA4527370D5@alcatel-lucent.com> <012C176C-A8D6-45AA-BA69-616C0ED7E41E@alcatel-lucent.com> <420BA2D8D80A6727.2B2C290F-2299-40BB-B53B-CC36D2B5D826@mail.outlook.com> <1881_1462451514_572B3D3A_1881_7198_1_0vn90oitr7e881gh2sn8qm5f.1462451509961@email.android.com> <17029_1462484835_572BBF63_17029_2323_1_opi9hqsl9b9tani0t0skkcuq.1462484831251@email.android.com> <28175_1463566739_573C4192_28175_2444_1_613f729b-d12e-5c48-29a1-ff000c1184a1@orange.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.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.116.190] Content-Type: multipart/alternative; boundary="_000_D369475E1A2CD7sajassiciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 07:05:06 -0000 --_000_D369475E1A2CD7sajassiciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Folks, I have updated and published rev03 of even-overlay draft. https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-overlay/ The main changes are: 1. section 10.2 - DCI using ASBR 2. The setting of Ethernet tag and VNI fields - there were some inconsis= tencies in different sections. Section 5.1.3 captures the setting of these = fields for different type of services in pretty good details. All other sec= tions were cleaned up and now refer to section 5.1.3. Thomas, The draft is ready for its long-overdue WG LC considering how long its has = been around and its multi-vendor implementation status. Regards, Ali --_000_D369475E1A2CD7sajassiciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <066D5BAA256E724A8298C8CE6470B952@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

Folks,

I have updated and published rev03 of even-overlay draft. 

The main changes are:
  1. section 10.2 – DCI using ASBR
  2. The setting of Ethernet tag= and VNI fields – there were some inconsistencies in different sectio= ns. Section 5.1.3 captures the setting of these fields for different type o= f services in pretty good details. All other sections were cleaned up and n= ow refer to section 5.1.3.

Thomas,
The draft is ready for its long-overdue WG LC considering how long its= has been around and its multi-vendor implementation status. 

Regards,
Ali
--_000_D369475E1A2CD7sajassiciscocom_-- From nobody Tue May 24 06:50:25 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC5C12D18B; Tue, 24 May 2016 06:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nk2ABI8u65p9; Tue, 24 May 2016 06:41:45 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0132.outbound.protection.outlook.com [207.46.100.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF12212D74A; Tue, 24 May 2016 06:39:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RfroTpudGABMAszI1RDCPIozDcJK2fwLmc6tRj1zVAo=; b=TekDlj8mQufyyBoIoJMKvHpD+n1duv8zUlVBXOglfy8X0m2LMIb3CgprKwWNBRB5BSQEtxsA0Q+g+tMjM4Jl7vf2s1QqHjV5UQSx+8RHggPTUK0ozEyTxHgTwA+YXV1zGc9t47Lnyqc9sHAT/mmORQ+YCcqLvE2IbGW4XZNoH+c= Received: from SN1PR0501MB1709.namprd05.prod.outlook.com (10.163.130.155) by SN1PR0501MB2127.namprd05.prod.outlook.com (10.163.228.154) with Microsoft SMTP Server (TLS) id 15.1.497.12; Tue, 24 May 2016 13:39:27 +0000 Received: from SN1PR0501MB1709.namprd05.prod.outlook.com ([10.163.130.155]) by SN1PR0501MB1709.namprd05.prod.outlook.com ([10.163.130.155]) with mapi id 15.01.0501.013; Tue, 24 May 2016 13:39:26 +0000 From: John E Drake To: "Ali Sajassi (sajassi)" , "EXT - thomas.morin@orange.com" , IDR , BESS , "draft-ietf-bess-evpn-overlay@tools.ietf.org" , "Rabadan, Jorge (Nokia - US)" , "draft-ietf-idr-tunnel-encap@tools.ietf.org" Thread-Topic: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps Thread-Index: AQHRpi+6xGM0bynWeUeGN93K6stLXZ+pFtLwgAAZ14CAABtMwIAAAw6AgAD40oCAAALOkIAAmFwAgAAIznCAE6UwgIAAQX5QgAj2SYCAAGyekA== Date: Tue, 24 May 2016 13:39:26 +0000 Message-ID: References: <5729F1C3.1030605@orange.com> <5729F7C5.6040604@orange.com> <52D35106-ED5E-4C95-9131-6EA4527370D5@alcatel-lucent.com> <012C176C-A8D6-45AA-BA69-616C0ED7E41E@alcatel-lucent.com> <420BA2D8D80A6727.2B2C290F-2299-40BB-B53B-CC36D2B5D826@mail.outlook.com> <1881_1462451514_572B3D3A_1881_7198_1_0vn90oitr7e881gh2sn8qm5f.1462451509961@email.android.com> <17029_1462484835_572BBF63_17029_2323_1_opi9hqsl9b9tani0t0skkcuq.1462484831251@email.android.com> <28175_1463566739_573C4192_28175_2444_1_613f729b-d12e-5c48-29a1-ff000c1184a1@orange.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.11] x-ms-office365-filtering-correlation-id: 1211c865-3246-4c31-b1db-08d383d8d31b x-microsoft-exchange-diagnostics: 1; SN1PR0501MB2127; 5:qnfm27qyD43LRy4GUV2YIRMzqew4rLFyvxr1nzHXRCGIRLuLG7XSeFQlntDboxb9YnTPTxaGUE0kxKbvwKrDt6ZFI3zABZR1XL7s/sCXjJMwa2PCzjoHP2ngRWzPiUcnX/99AbfnwiV0P8QEydFUtg==; 24:UhWvk6RkdIN6RAFO1gCNa7D+YIWFZ1Zr9bO58BQ6VLGKikq2eemxbgQyW0krlS3GNZz0FzOsLp/eINn/nl2mM/eDR9VfCi9YWqeIljdu36Q=; 7:EaEHEiPBDk9zAwJCiNEMvfiNDOsC/j6VNskm6lL86sUZh3oCieGS3n/fqJJ1gO0gX/Ea3DYaqDLJmMja2ef4eqm6qqWDdz+sY2krRIZ567y7wvzMcfXQlQIFaMQoP2jPydm4lCf5q3QlSPopBC4TqRkLddh9AKACoqTBEhPRb7s= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB2127; x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:SN1PR0501MB2127; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB2127; x-forefront-prvs: 09525C61DB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(81166006)(93886004)(86362001)(102836003)(1220700001)(9326002)(9686002)(6116002)(2501003)(3846002)(107886002)(790700001)(50986999)(189998001)(76176999)(54356999)(19625215002)(5003600100002)(19580405001)(19580395003)(106116001)(99286002)(19300405004)(586003)(2900100001)(92566002)(3280700002)(19617315012)(8936002)(5008740100001)(2906002)(5002640100001)(2950100001)(77096005)(5004730100002)(10400500002)(5001770100001)(16236675004)(87936001)(4326007)(3660700001)(76576001)(230783001)(74316001)(19609705001)(122556002)(66066001)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB2127; H:SN1PR0501MB1709.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_SN1PR0501MB1709EA8CE5E1B3C52862015DC74F0SN1PR0501MB1709_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 24 May 2016 13:39:26.5166 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB2127 Archived-At: X-Mailman-Approved-At: Tue, 24 May 2016 06:50:24 -0700 Cc: Adrian Farrel , Alia Atlas Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 13:41:47 -0000 --_000_SN1PR0501MB1709EA8CE5E1B3C52862015DC74F0SN1PR0501MB1709_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Ali and I decided to keep the normative reference to RFC 5512 rather than c= hanging it to Eric's tunnel encapsulation draft because the normative refer= ence pre-dates Eric's draft and because our draft does not use any of the n= ew capabilities introduced in Eric's draft. Ali and I would also like to request that Jorge be the document shepherd fo= r this draft. Yours Irrespectively, John From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Tuesday, May 24, 2016 3:05 AM To: John E Drake; EXT - thomas.morin@orange.com; IDR; BESS; draft-ietf-bess= -evpn-overlay@tools.ietf.org; Rabadan, Jorge (Nokia - US); draft-ietf-idr-t= unnel-encap@tools.ietf.org Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-e= ncaps Folks, I have updated and published rev03 of even-overlay draft. https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-overlay/ The main changes are: 1. section 10.2 - DCI using ASBR 2. The setting of Ethernet tag and VNI fields - there were some inconsis= tencies in different sections. Section 5.1.3 captures the setting of these = fields for different type of services in pretty good details. All other sec= tions were cleaned up and now refer to section 5.1.3. Thomas, The draft is ready for its long-overdue WG LC considering how long its has = been around and its multi-vendor implementation status. Regards, Ali --_000_SN1PR0501MB1709EA8CE5E1B3C52862015DC74F0SN1PR0501MB1709_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Ali and I decided to keep the normati= ve reference to RFC 5512 rather than changing it to Eric’s tunnel enc= apsulation draft because the normative reference pre-dates Eric’s draft and because our draft does not use any of the new capab= ilities introduced in Eric’s draft.

 

Ali and I would also like to request = that Jorge be the document shepherd for this draft.

 

Yours Irrespectively,

 

John

 

From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
Sent: Tuesday, May 24, 2016 3:05 AM
To: John E Drake; EXT - thomas.morin@orange.com; IDR; BESS; draft-ie= tf-bess-evpn-overlay@tools.ietf.org; Rabadan, Jorge (Nokia - US); draft-iet= f-idr-tunnel-encap@tools.ietf.org
Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-t= unnel-encaps

 

 

Folks,

 

I have updated and published rev03 of even-overlay = draft. 

 

The main changes are:

  1. section 10.2 – DCI using ASBR
  2. The setting of Ethernet tag and VNI fields – there were some inconsi= stencies in different sections. Section 5.1.3 captures the setting of these= fields for different type of services in pretty good details. All other sections were cleaned up and now refer to section 5.1.3= .

 

Thomas,

The draft is ready for its long-overdue WG LC consi= dering how long its has been around and its multi-vendor implementation sta= tus. 

 

Regards,

Ali

--_000_SN1PR0501MB1709EA8CE5E1B3C52862015DC74F0SN1PR0501MB1709_-- From nobody Tue May 24 11:00:55 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D264912D141; Tue, 24 May 2016 11:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zG9iyBwTFVRM; Tue, 24 May 2016 11:00:52 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CF7E12D133; Tue, 24 May 2016 11:00:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=732; q=dns/txt; s=iport; t=1464112852; x=1465322452; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=hxDOxqaifpoP3Bl+4rMawE2INQD5kTxDEpuEGYOskCY=; b=mjVt8mG4UUiX6mB6V/ftYbgFG3FtRxjvWtX2t3zqS4v2I7+F9jPN65Qn VebII50ymPSwQXLBSwR0RFRtzCvn0MdWx5t8pFPPa2eYG5b7hcVKwTwYx 5nwRpNa2UCxEJRvtdZu0HLdrzzE1544Jaq3Izf0KsyJoyfc7Y2VrGSP8a c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AhAgCElURX/4kNJK1cgzeBUwa5egENg?= =?us-ascii?q?XaGEQKBMzgUAQEBAQEBAWUnhEMBAQQ6PxACAQg2EDIlAgQOBYgvw3oBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEfhieETIQphXABBJM3hQABjh+BaY0zhjOJGAEeAQFCg21ui?= =?us-ascii?q?Qh/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,360,1459814400"; d="scan'208";a="111445741" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 May 2016 18:00:51 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u4OI0pqM027700 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 24 May 2016 18:00:51 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 24 May 2016 13:00:51 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Tue, 24 May 2016 13:00:51 -0500 From: "Alvaro Retana (aretana)" To: Nick Hilliard Thread-Topic: AD Review of draft-ietf-idr-ix-bgp-route-server-09 Thread-Index: AQHRNFCzHRdSwT+uvUK1lt056oVbCA== Date: Tue, 24 May 2016 18:00:51 +0000 Message-ID: References: <5723E3B4.4090103@foobar.org> In-Reply-To: <5723E3B4.4090103@foobar.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.150.48.37] Content-Type: text/plain; charset="us-ascii" Content-ID: <0D5C2FB62051AD47A48ED9AEC0E36609@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "idr-chairs@ietf.org" , "idr@ietf.org" , "shares@ndzh.com" , "draft-ietf-idr-ix-bgp-route-server@ietf.org" Subject: Re: [Idr] AD Review of draft-ietf-idr-ix-bgp-route-server-09 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 18:00:54 -0000 On 4/29/16, 6:44 PM, "Nick Hilliard" wrote: Nick: Hi! Thanks for the revision! >We deliberately steered clear of dealing with operational issues in this >draft because its focus was on the bgp protocol. Several of the comments >you make below are probably more relevant to >draft-ietf-grow-ix-bgp-route-server-operations. We've marked them as such. Does that mean that you will update draft-ietf-grow-ix-bgp-route-server-operations, or what? Just wondering. It would be nice to have a reference from this document to draft-ietf-grow-ix-bgp-route-server-operations. I'm starting the IETF Last Call and will schedule the IESG review at the next available Telechat. Thanks! Alvaro. From nobody Tue May 24 12:33:56 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5869212D113 for ; Tue, 24 May 2016 12:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.638 X-Spam-Level: *** X-Spam-Status: No, score=3.638 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BwLbZLwpr5E3 for ; Tue, 24 May 2016 12:33:54 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AD3B12D101 for ; Tue, 24 May 2016 12:33:54 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.182.128; From: "Susan Hares" To: Date: Tue, 24 May 2016 15:33:54 -0400 Message-ID: <033301d1b5f3$35443d40$9fccb7c0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0334_01D1B5D1.AE3423E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdG18x/32NUdfqAnSPad+PeK3zUuqg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] draft-ietf-idr-add-paths-guidelines-08.txt - 1 week call to confirm WG LC (5/24 to 5/31) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 19:33:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0334_01D1B5D1.AE3423E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit IDR WG: We're trying to resolve several "pending" requests this month. This is the first of these drafts. draft-ietf-idr-add-paths-guidelines-07.txt reached WG consensus on 4/23/2014. Unfortunately, the RTG-DIR review was not handled. The authors have published draft-ietf-idr-add-paths-guidelines-08.txt. The WG Chairs consider this to resolve the RTG-DIR issues, and plan to forward this to the IESG. However, since this draft has been idle since 2014, we are doing a 1 week call notifying the WG of our plans. If you feel the WG should enter into a 2 week WG LC or if you have issues with this draft, please respond to this email. Otherwise, on 5/31/2016 -this draft will be forwarded to the IESG. Sue Hares and John Scudder ------=_NextPart_000_0334_01D1B5D1.AE3423E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IDR WG:

 

We’re trying to resolve = several “pending” requests this month.  This is the = first of these drafts.

 

draft-ietf-idr-add-paths-guideline= s-07.txt reached WG consensus on 4/23/2014.  Unfortunately, the = RTG-DIR review was not handled.  The authors have published = draft-ietf-idr-add-paths-guidelines-08.txt.

 

The WG Chairs consider this to = resolve the RTG-DIR issues, and plan to forward this to the IESG.  = However, since this draft has been idle since 2014, we are doing a 1 = week call notifying the WG of our plans.  If you feel the WG should = enter into a 2 week WG LC or if you have issues with this draft, please = respond to this email.  Otherwise, on 5/31/2016 –this draft = will be forwarded to the IESG. 

 

Sue Hares and John = Scudder

 

 

 

------=_NextPart_000_0334_01D1B5D1.AE3423E0-- From nobody Tue May 24 13:42:19 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEFB412D1BE for ; Tue, 24 May 2016 13:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.638 X-Spam-Level: *** X-Spam-Status: No, score=3.638 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uU5VuuGQAqK for ; Tue, 24 May 2016 13:42:15 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7415D12D1B1 for ; Tue, 24 May 2016 13:42:15 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.182.128; From: "Susan Hares" To: Date: Tue, 24 May 2016 16:42:11 -0400 Message-ID: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0380_01D1B5DB.38A619D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdG19Q0c4DmlRxlfTIa/f3EYODPjkA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: "'Keyur Patel \(keyupate\)'" , 'David Ward' Subject: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 20:42:17 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0380_01D1B5DB.38A619D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This begins a 2 week WG LC on draft-ietf-idr-bgp-extended-messages (5/24 to 6/7). The draft can be found at: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/ In your comments please provide the following information: 1) Support/"no-support" of this draft being ready for publication, 2) You know of an implementation for this draft, please report the implementation to the IDR Wiki https://trac.tools.ietf.org/wg/idr/trac/wiki/draft-ietf-idr-bgp-extended-imp lementations 3) Do you have any concerns about extending the BGP messages. Sue Hares and John Scudder ------=_NextPart_000_0380_01D1B5DB.38A619D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This = begins a 2 week WG LC on draft-ietf-idr-bgp-extended-messages (5/24 to = 6/7). The draft can be found at:

 

https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messa= ges/

 

In your comments please provide the following = information:

1)      = Support/”no-support” of this draft = being ready for publication,

2)      = You know of an implementation for this draft, = please report the implementation to the IDR Wiki

 

https://trac.tools.ietf.org/wg/idr/trac/wiki/d= raft-ietf-idr-bgp-extended-implementations

 

3)      = Do you have any concerns about extending the BGP = messages.

 

Sue Hares and John Scudder =

------=_NextPart_000_0380_01D1B5DB.38A619D0-- From nobody Tue May 24 13:50:47 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C617512D1D4 for ; Tue, 24 May 2016 13:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3Q2zrxtrApC for ; Tue, 24 May 2016 13:50:44 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EABF312D196 for ; Tue, 24 May 2016 13:50:43 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id a136so93720224wme.0 for ; Tue, 24 May 2016 13:50:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=VPxstJl2+6IpofaIDSqGoZa6gY3Y2+AiZwIL8d2HZWU=; b=gnaGnKSeInOM+2eQkUIlCaVCNhi7ckwrvlEDdNKiBu1bcDdeMXlqI7XgIWuXMBU9gX 9tXEqSJWnDAXk/jFI0ohCAQZrbh9mjbdLl8H4I/MJWXegOPV13lVvOzcg7JbdmELUdGA MqkegKbjAMcycXUx3JQLB9jN16It8nCqRR/Ix72gpKzq2Cqd1f3LFY+xcLQjpbNdVTt0 S0B4+RJ+XE9C6ywM82OFvQnIAGDNvQSfnjANdmNI8Gy4QP9XnaEBiOgAbE+bvLYO0Exa eyEQbfIjovoWcsTR+CurVzQNuWS3WVpRgEIteAW0jn7nXzTtl8HZYEmIP6QRB0hSNHkc nVfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=VPxstJl2+6IpofaIDSqGoZa6gY3Y2+AiZwIL8d2HZWU=; b=GzGKjYSmVp7GCODgkYUz/7DrbIva/d38C4J2gLoP8k2Bh2Jqn9vLENrJ5i1vvqE9dB OjQJVGFNacvhuPoUC12b3lr33isnDhh4IQ2nmJQ0ZscpsH+y/OW6KaT6RJR4YaBO2HZd WmZYH3vI3q/0ivrPPfa4/9E6l+SVWRjJCSQsm1XnPRds2z65ePFhv+3A+HFR0hvisDuC X5A8++pJuc/Ls4Xz9s1XJVk3Dpk4vOk/Q57y5CuR0VPPOwDjAKz58nHmEbUkiVvCEOXa 2JUBVp5KGvQeC8MDLUbrA65FfO5qEkYq6EoXA3eqOJzGVL9nSCIE1FBFh0BoQWehrLx9 uLhA== X-Gm-Message-State: ALyK8tJXeeVJz+It0yuEs3VOp5n5vGpurnQ8GUCy+sq4kJEgP/AOrCT2ctR+/gInMg8Dhg== X-Received: by 10.28.10.196 with SMTP id 187mr714670wmk.76.1464123042187; Tue, 24 May 2016 13:50:42 -0700 (PDT) Received: from localhost ([91.143.127.69]) by smtp.gmail.com with ESMTPSA id m3sm5072735wjc.27.2016.05.24.13.50.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 May 2016 13:50:40 -0700 (PDT) Date: Tue, 24 May 2016 22:50:36 +0200 From: Job Snijders To: Susan Hares Message-ID: <20160524205036.GS81971@Vurt.local> References: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: "'Keyur Patel \(keyupate\)'" , idr@ietf.org, 'David Ward' Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 20:50:46 -0000 On Tue, May 24, 2016 at 04:42:11PM -0400, Susan Hares wrote: > This begins a 2 week WG LC on draft-ietf-idr-bgp-extended-messages (5/24 to > 6/7). The draft can be found at: > > https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/ I support publication. Kind regards, Job From nobody Tue May 24 14:09:03 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C71312D1EA; Tue, 24 May 2016 14:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SG1HbE_uIsIx; Tue, 24 May 2016 14:08:59 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0104.outbound.protection.outlook.com [207.46.100.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3444112D13D; Tue, 24 May 2016 14:08:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6djPsqTyaLl6Iq1NCwN9AwITj8OW9K5fJZ15SOmyXsY=; b=hgLWalueJ94MRp6nMvpnOHudssH1G0oFcGxyT3aOJRm33UaaP05uhxTfHPGjOc6VgS/iqYrTkEfS4fCqJCLKHTBj7gl2p3jcrr2pokQs9GLB2LGQHqnjE//SziG/X0nfjTTsM6LufeCPqADM+6sXpgfwsiOlb+24vot3W2M796E= Received: from SN1PR0501MB1709.namprd05.prod.outlook.com (10.163.130.155) by SN1PR0501MB1711.namprd05.prod.outlook.com (10.163.130.157) with Microsoft SMTP Server (TLS) id 15.1.501.7; Tue, 24 May 2016 21:08:58 +0000 Received: from SN1PR0501MB1709.namprd05.prod.outlook.com ([10.163.130.155]) by SN1PR0501MB1709.namprd05.prod.outlook.com ([10.163.130.155]) with mapi id 15.01.0501.013; Tue, 24 May 2016 21:08:57 +0000 From: John E Drake To: Robert Raszuk , Adrian Farrel Thread-Topic: [spring] [Idr] New draft for data center gateways Thread-Index: AdG1GnjM0FP4vAcnRKiZoSNePCQ+mQABH+CAAAQtdQAAMre9gA== Date: Tue, 24 May 2016 21:08:57 +0000 Message-ID: References: <01ea01d1b51a$7cf31e60$76d95b20$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: raszuk.net; dkim=none (message not signed) header.d=none;raszuk.net; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.10] x-ms-office365-filtering-correlation-id: 5f049879-7ad1-4dac-da47-08d384179f30 x-microsoft-exchange-diagnostics: 1; SN1PR0501MB1711; 5:xVA+hysUdUNqtpzZQCRgqvBtPw6LN2h50L25Y3LlRfVccIeKlX4dJ7ljSxWVnqJnEkWDBz8aHJ4Ni/HgN4pJWNGxPu5oxjPIkMDwxj21O2EBLMAZToSk7TPiWICyEWnsWCR7mcvtEm4gwnq9db8ksA==; 24:QhGdqWehIJx5mITr1BWWeFdqLhNnITpVhBFw3nPCZZCs8rKtl3sPIJTBYzKjzIFKY24Zypo+8UwZjJB7Ei6xppvMsENXwxeo9qBRdlcuSAg=; 7:ztNjjJLMkdYspHIhQY1RNDIeCJcCuudctBvn2hVKwzMxhcRG4ZEbNmq52pZ3/h0Wq0AvjFJ6KJ832Saug1KRzcpowVLk76FAfl6pkg6ZoRbGFQezJ+fMkpnIQgER/PKpNfSOJFpqhyvkMj5oRgEF6A7r2MqKs8Ib6Qu1uVzBOeRH0MFKrS00vi81BYFqC0ce x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB1711; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:SN1PR0501MB1711; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1711; x-forefront-prvs: 09525C61DB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(5008740100001)(16236675004)(66066001)(2950100001)(5001770100001)(2900100001)(86362001)(15975445007)(77096005)(4326007)(19609705001)(3660700001)(2906002)(19580405001)(189998001)(3280700002)(3846002)(76576001)(19625215002)(19580395003)(586003)(92566002)(9686002)(87936001)(1220700001)(790700001)(19300405004)(102836003)(6116002)(122556002)(5004730100002)(5003600100002)(19617315012)(81166006)(5002640100001)(99286002)(10400500002)(50986999)(54356999)(76176999)(8936002)(74316001)(33656002)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB1711; H:SN1PR0501MB1709.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0501MB1709C670BFB005BDB241845DC74F0SN1PR0501MB1709_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 24 May 2016 21:08:57.7233 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB1711 Archived-At: Cc: idr wg , "spring@ietf.org" Subject: Re: [Idr] [spring] New draft for data center gateways X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 21:09:01 -0000 --_000_SN1PR0501MB1709C670BFB005BDB241845DC74F0SN1PR0501MB1709_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Um9iZXJ0LA0KDQpDb21tZW50cyBpbmxpbmUNCg0KWW91cnMgSXJyZXNwZWN0aXZlbHksDQoNCkpv aG4NCg0KRnJvbTogc3ByaW5nIFttYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBSb2JlcnQgUmFzenVrDQpTZW50OiBNb25kYXksIE1heSAyMywgMjAxNiA0OjE0IFBN DQpUbzogQWRyaWFuIEZhcnJlbA0KQ2M6IGlkciB3Zzsgc3ByaW5nQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW3NwcmluZ10gW0lkcl0gTmV3IGRyYWZ0IGZvciBkYXRhIGNlbnRlciBnYXRld2F5cw0K DQpEZWFyIEF1dGhvcnMsDQoNClF1ZXN0aW9uIDE6DQoNCkFzc3VtZSB0aGF0IHByZWZpeCBYIGhh cyBiZWVuIGFkdmVydGlzZWQgd2l0aCB0dW5uZWwgYXR0cmlidXRlIGFzIGRlc2NyaWJlZCBpbiB0 aGUgZHJhZnQgd2l0aCBib3RoIEdXMSBhbmQgR1cyIGVudHJ5IHBvaW50cyB0byBFZ3Jlc3MgREMg c2l0ZS4NCg0KU28gcmVtb3RlIEdXIGluIEluZ3Jlc3MgREMgc2l0ZSByZWNlaXZlcyBhdCBsZWFz dCBvbmUgc3VjaCBhZHZlcnRpc2VtZW50IGFuZCBhcyBlYWNoIGNvbnRhaW5zIGJvdGggR1cxIGFu ZCBHVzIgZW50cmllcyBpdCBjYW4gZW5naW5lZXIgZmxvd3MgdG8gdGhvc2UuDQoNClNvIGZhciBz byBnb29kIC4uLiBidXQgd2hhdCBoYXBwZW5zIHdoZW4gbGluayBiZXR3ZWVuIFBFIChvbiBsZWZ0 IHNpZGUpIGFuZCBHVzEgZ29lcyBkb3duID8NCg0KQkdQIHdpbGwgYWZ0ZXIgc29tZSB0aW1lIHJl bW92ZSB0aGF0IHBhdGggdmlhIGFsbCBBU2VzLCBidXQgR1cyIHdpbGwga2VlcCBhZHZlcnRzaW5n IHByZWZpeCBYIGFzIHN0aWxsIHJlYWNoYWJsZSB2aWEgYm90aCBHVzEgYW5kIEdXMiB3aXRoaW4g dHVubmVsIGVuY2Fwc3VsYXRpb24gYXR0cmlidXRlIGFzIGZyb20gaGlzIHBlcnNwZWN0aXZlIG5v dGhpbmcgd2lsbCBiZSB3cm9uZy4NCg0KSG93IHJlbW90ZSBHVyBpbiBJbmdyZXNzIERDIHNpdGUg aXMgbm93IHN1cHBvc2VkIHRvIGtub3cgdGhhdCBHVzEgbGluayB0byBQRSBpbiBBUzIgd2VudCBk b3duIGFuZCBzdG9wIHB1c2hpbmcgdHJhZmZpYyB0b3dhcmRzIGl0ID8NCg0KDQpbSkRdICBXZSB3 ZXJlIGFzc3VtaW5nIHRoYXQgYSkgR1cvYmFja2JvbmUgbGlua3Mgd291bGQgYmUgYWR2ZXJ0aXNl ZCBpbiBCR1AgTFMgKG9wdGlvbmFsbHkgdy8gRVBFKSBhbmQgYikgYSBHVyB0aGF0IGlzIGRpc2Nv bm5lY3RlZCBmcm9tIHRoZSBiYWNrYm9uZSBkb2VzIG5vdCBhZHZlcnRpc2UgYW4gYXV0by1kaXNj b3Zlcnkgcm91dGUuICBUaGlzIHdpbGwgYmUgbWFkZSBleHBsaWNpdCBpbiB0aGUgbmV4dCByZXZp c2lvbi4NCg0KDQotIC0gLQ0KDQpRdWVzdGlvbiAyOg0KDQpXaGF0IGhhcHBlbnMgaWYgYWxsIEwz IERDIENMT1MgSVAgRmFicmljcyB1c2UgZUJHUCBub3QgSUdQID8NCg0KDQpbSkRdICAgV2UgbWFr ZSBubyBhc3N1bXB0aW9ucyBhYm91dCB3aGF0IGNvbnRyb2wgcGxhbmUgaXMgdXNlZCB3aXRoaW4g YSBEQy4gIEFmdGVyIGFsbCwgdGhlIGRyYWZ0IGlzIGFib3V0IERDIOKAnGludGVyY29ubmVjdOKA nS4gIChCdHcsIGl0IHNob3VsZCBiZSBzcGVsbGVkIOKAmENsb3PigJkgc2luY2UgaXTigJlzIGEg cGVyc29u4oCZcyBsYXN0IG5hbWUuKQ0KDQoNCi0gLSAtDQoNClF1ZXN0aW9uIDM6DQoNCklzIHBl ciBwcmVmaXggdHVubmVsIGF0dHJpYnV0ZSB3aGVyZSBzYXkgLzMyIHJvdXRlcyBtYXkgYmUgZXhj aGFuZ2VzIGZsYXQgKHJlZiBjYWxpY28gYXBwcm9hY2ggLSBodHRwczovL3d3dy5wcm9qZWN0Y2Fs aWNvLm9yZy8pIHJlYWxseSBhIHNjYWxhYmxlIHNvbHV0aW9uID8NCg0KDQpbSkRdICAgQXJlIHlv dSBzaW1wbHkgcmVwZWF0aW5nIHRoZSBvcGluaW9uIHlvdSBleHByZXNzZWQgd2hlbiB0aGUgdHVu bmVsLWVuY2FwcyBkcmFmdCBmaXJzdCBjYW1lIG91dCwgb3IgZG8geW91IGhhdmUgYSBzY2FsYWJp bGl0eSBjb25jZXJuIHRoYXQgaGFzbid0IGFscmVhZHkgYmVlbiBkaXNjdXNzZWQ/DQoNCg0KQmVz dCwNClJvYmVydC4NCg0KUFMuIEp1c3QgcHVyZWx5IGFzIGluZm9ybWF0aW9uIHlvdXIgaW50ZXIg REMgdHJhZmZpYyBzdGVlcmluZyBwcm9ibGVtIGRlc2NyaXB0aW9uIGlzIGVhc2lseSBzb2x2ZWQg YWxyZWFkeSB0b2RheSB3aXRoIG9uZSBsZXZlbCBvZiBpbmRpcmVjdGlvbiAtIEV4YW1wbGU6IExJ U1AuIE5vdCBzdXJlIGlmIHdlIG5lZWQgYWRkaXRpb25hbCBmbGF0IHByb3RvY29sIGV4dGVuc2lv bnMgaGVyZS4NCg0KDQoNCg== --_000_SN1PR0501MB1709C670BFB005BDB241845DC74F0SN1PR0501MB1709_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Um9iZXJ0 LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Q29tbWVudHMgaW5s aW5lPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Zb3VycyBJcnJl c3BlY3RpdmVseSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkpv aG48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBp biAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiBzcHJpbmcgW21haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZ10NCjxi Pk9uIEJlaGFsZiBPZiA8L2I+Um9iZXJ0IFJhc3p1azxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXks IE1heSAyMywgMjAxNiA0OjE0IFBNPGJyPg0KPGI+VG86PC9iPiBBZHJpYW4gRmFycmVsPGJyPg0K PGI+Q2M6PC9iPiBpZHIgd2c7IHNwcmluZ0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW3NwcmluZ10gW0lkcl0gTmV3IGRyYWZ0IGZvciBkYXRhIGNlbnRlciBnYXRld2F5czxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkRl YXIgQXV0aG9ycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWYiPlF1ZXN0aW9uIDE6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5Bc3N1bWUgdGhhdCBwcmVmaXgg WCBoYXMgYmVlbiBhZHZlcnRpc2VkIHdpdGggdHVubmVsIGF0dHJpYnV0ZSBhcyBkZXNjcmliZWQg aW4gdGhlIGRyYWZ0IHdpdGggYm90aCBHVzEgYW5kIEdXMiBlbnRyeSBwb2ludHMgdG8gRWdyZXNz IERDIHNpdGUuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmIj5TbyByZW1vdGUgR1cgaW4gSW5ncmVzcyBEQyBzaXRlIHJl Y2VpdmVzIGF0IGxlYXN0IG9uZSBzdWNoIGFkdmVydGlzZW1lbnQgYW5kIGFzIGVhY2ggY29udGFp bnMgYm90aCBHVzEgYW5kIEdXMiBlbnRyaWVzIGl0IGNhbiBlbmdpbmVlciBmbG93cyB0byB0aG9z ZS4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWYiPlNvIGZhciBzbyBnb29kIC4uLiBidXQgd2hhdCBoYXBwZW5zIHdoZW4g bGluayBiZXR3ZWVuIFBFIChvbiBsZWZ0IHNpZGUpIGFuZCBHVzEgZ29lcyBkb3duID8mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWYiPkJHUCB3aWxsIGFmdGVyIHNvbWUgdGltZSByZW1vdmUgdGhhdCBwYXRoIHZpYSBhbGwg QVNlcywgYnV0IEdXMiB3aWxsIGtlZXAgYWR2ZXJ0c2luZyBwcmVmaXggWCBhcyBzdGlsbCByZWFj aGFibGUgdmlhIGJvdGggR1cxIGFuZCBHVzIgd2l0aGluIHR1bm5lbCBlbmNhcHN1bGF0aW9uIGF0 dHJpYnV0ZSBhcyBmcm9tIGhpcyBwZXJzcGVjdGl2ZQ0KIG5vdGhpbmcgd2lsbCBiZSB3cm9uZy4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWYiPkhvdyByZW1vdGUgR1cgaW4gSW5ncmVzcyBEQyBzaXRlIGlzIG5vdyBzdXBw b3NlZCB0byBrbm93IHRoYXQgR1cxIGxpbmsgdG8gUEUgaW4gQVMyIHdlbnQgZG93biBhbmQgc3Rv cCBwdXNoaW5nIHRyYWZmaWMgdG93YXJkcyBpdCA/Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjUuMjVwdCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjUuMjVwdCI+PGI+PGk+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltKRF0mbmJzcDsgV2Ugd2VyZSBhc3N1bWluZyB0aGF0IGEp IEdXL2JhY2tib25lIGxpbmtzIHdvdWxkIGJlIGFkdmVydGlzZWQgaW4gQkdQIExTIChvcHRpb25h bGx5IHcvIEVQRSkgYW5kIGIpIGEgR1cgdGhhdCBpcyBkaXNjb25uZWN0ZWQNCiBmcm9tIHRoZSBi YWNrYm9uZSBkb2VzIG5vdCBhZHZlcnRpc2UgYW4gYXV0by1kaXNjb3Zlcnkgcm91dGUuJm5ic3A7 IFRoaXMgd2lsbCBiZSBtYWRlIGV4cGxpY2l0IGluIHRoZSBuZXh0IHJldmlzaW9uLiAmbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDo1LjI1cHQiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo1LjI1cHQiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4tIC0gLSZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+UXVlc3Rpb24gMjom bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWYiPldoYXQgaGFwcGVucyBpZiBhbGwgTDMgREMgQ0xPUyBJUCBGYWJyaWNzIHVz ZSBlQkdQIG5vdCBJR1AgPyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+ PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5bSkRdJm5ic3A7Jm5ic3A7IFdlIG1ha2Ugbm8gYXNzdW1wdGlvbnMgYWJvdXQg d2hhdCBjb250cm9sIHBsYW5lIGlzIHVzZWQgd2l0aGluIGEgREMuJm5ic3A7IEFmdGVyIGFsbCwg dGhlIGRyYWZ0IGlzIGFib3V0IERDIOKAnGludGVyY29ubmVjdOKAnS4mbmJzcDsgKEJ0dywgaXQg c2hvdWxkIGJlIHNwZWxsZWQNCiDigJhDbG9z4oCZIHNpbmNlIGl04oCZcyBhIHBlcnNvbuKAmXMg bGFzdCBuYW1lLik8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPi0gLSAt Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmIj5RdWVzdGlvbiAzOiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+SXMgcGVyIHByZWZpeCB0dW5u ZWwgYXR0cmlidXRlIHdoZXJlIHNheSAvMzIgcm91dGVzIG1heSBiZSBleGNoYW5nZXMgZmxhdCAo cmVmIGNhbGljbyBhcHByb2FjaCAtDQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cucHJvamVj dGNhbGljby5vcmcvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZiI+aHR0cHM6Ly93d3cucHJvamVjdGNhbGljby5vcmcvPC9zcGFuPjwvYT48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+KSByZWFs bHkgYSBzY2FsYWJsZSBzb2x1dGlvbiA/Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PltKRF0mbmJzcDsmbmJzcDsgQXJlIHlvdSBzaW1wbHkgcmVwZWF0aW5nIHRoZSBvcGluaW9uIHlv dSBleHByZXNzZWQgd2hlbiB0aGUgdHVubmVsLWVuY2FwcyBkcmFmdCBmaXJzdCBjYW1lIG91dCwg b3IgZG8geW91IGhhdmUgYSBzY2FsYWJpbGl0eSBjb25jZXJuIHRoYXQgaGFzbid0DQogYWxyZWFk eSBiZWVuIGRpc2N1c3NlZD88L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5CZXN0 LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm Ij5Sb2JlcnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmIj5QUy4gSnVzdCBwdXJlbHkgYXMgaW5mb3JtYXRpb24geW91ciBpbnRl ciBEQyB0cmFmZmljIHN0ZWVyaW5nIHByb2JsZW0gZGVzY3JpcHRpb24gaXMgZWFzaWx5IHNvbHZl ZCBhbHJlYWR5IHRvZGF5IHdpdGggb25lIGxldmVsIG9mIGluZGlyZWN0aW9uIC0gRXhhbXBsZTog TElTUC4gTm90IHN1cmUgaWYgd2UgbmVlZCBhZGRpdGlvbmFsDQogZmxhdCBwcm90b2NvbCBleHRl bnNpb25zIGhlcmUuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_SN1PR0501MB1709C670BFB005BDB241845DC74F0SN1PR0501MB1709_-- From nobody Tue May 24 14:27:52 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B21C12D1D3; Tue, 24 May 2016 14:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGSxdJg8-r9r; Tue, 24 May 2016 14:27:47 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF26612B056; Tue, 24 May 2016 14:27:46 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id e130so11057456lfe.3; Tue, 24 May 2016 14:27:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=+wH+dW75cWZOaEtx7iA+VUmuhENNtnwYfRf2hUzJQ2g=; b=rpUBiUycCK4gxoTEQZtUvLiAjGw7kEzsDnPPPKvUsMXF8XiU2zUkTNe/wuKDxUAPq/ uY9wHUVVm2FvNa+N/A8xLoJR4a6u8luMRqD8UEvFzcMnZ13uyQk0xmP5lEsbcSKe8uDM Xp8UbULh2y9KLejFhbbc28y4AtzVcTQd54jBJrJa1HFm5ev+HBBJ74R6fY9zyTTuoXQ+ Pwk8fsfkpUWOJ+HmrCiyda6vvuv+sc7wN5lovEsC/aTwOppVCazQkqIheYnvvg5+VNUr 9FhdZMGfKVhw2nOzKY1K/CcILHaqBQt2kxQeqnfgACEnbf3/v3nIzUUbSijs2JmKzJaq 8CQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=+wH+dW75cWZOaEtx7iA+VUmuhENNtnwYfRf2hUzJQ2g=; b=S6IaMwheKzTzJAgUuX59ip/6/yrBPPNUonR3ldeVI7bzeo+acsS5qfJW5SuyjwdZ7s /paXhsAVn5TAbbEN8xs6oRfSa0BuKGlblVB4HHtatFkhJ6Uj9hAngpMIEY327ZtAv+WM musAYGPakzzUIIF7ni0baGqGo9hC7EM4FYWd8fV2X6vpDeALdXvyQlY8cki2fcwlRDtN k9qQKseUoRsmtB6JVftUWt4wMhAnVb0sBignurQAcK8mEg28k160n6Mb4QgkZMGIIsKw UCUa2vX8KFoe0f+bxWH/M6DpT30sYsnC2c/HTzbtgR3dyf1mBQa4npKzj0ScUlY/Wm8l 2UlA== X-Gm-Message-State: ALyK8tL0kAzJpkERaIV2iE3ApFU1LTd2atufvTyOMK4pjj+4SVPFRwhNvMZvRXo1WqPbAe7ChD3ab+1ufx8kIQ== MIME-Version: 1.0 X-Received: by 10.25.16.219 with SMTP id 88mr59684lfq.21.1464125264904; Tue, 24 May 2016 14:27:44 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.25.134.196 with HTTP; Tue, 24 May 2016 14:27:44 -0700 (PDT) In-Reply-To: References: <01ea01d1b51a$7cf31e60$76d95b20$@olddog.co.uk> Date: Tue, 24 May 2016 23:27:44 +0200 X-Google-Sender-Auth: CSYEoyOCmzv9GZdQ9zY_2GE8CCs Message-ID: From: Robert Raszuk To: John E Drake Content-Type: multipart/alternative; boundary=001a11402d9c524b2305339d3ad3 Archived-At: Cc: "spring@ietf.org" , idr wg Subject: Re: [Idr] [spring] New draft for data center gateways X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 21:27:48 -0000 --001a11402d9c524b2305339d3ad3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi John, *[JD] We were assuming that a) GW/backbone links would be advertised in > BGP LS (optionally w/ EPE) and b) a GW that is disconnected from the > backbone does not advertise an auto-discovery route. This will be made > explicit in the next revision. * > =E2=80=8BAd a) - EPE works fine with next hop self on the ASBRs of the bacb= one. So if your proposal requires external links to be passive in the backbone IGP then the draft needs to state it well. Besides it may not be sufficient if more then one backbone instance is used to interconnect DCs. Ad b) - The current set of procedures described in section 2 for constructing auto discovery routes is not sufficient. GW may be interconnected to more then one backbone each serving different set of prefixes within each DC (you call it X). So much more would need to go into the auto-discovery to make this work in practice. And even if you would go that way it will be slow to re-advertise all prefixes with different tunnel attribute content. *[JD] Are you simply repeating the opinion you expressed when the > tunnel-encaps draft first came out, or do you have a scalability concern > that hasn't already been discussed?* > > =E2=80=8BI am expressing the observation that tunnel-encaps may work well t= o pass static information or information which may change by configiration. Here you are using it to pass remote reachability info embedded into it. I find it far from optimal which as combined with possible DC prefix scale is likely to cause more issues then benefits. That's why I suggest use of indirection layer to solve this overall problem. As mentioned one could be LISP or any other SD-WAN solutions. Thx, R. --001a11402d9c524b2305339d3ad3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi John,

[J= D]=C2=A0 We were assuming that a) GW/backbone links would be advertised in = BGP LS (optionally w/ EPE) and b) a GW that is disconnected from the backbone does not advertise an auto-discovery route.=C2=A0 This w= ill be made explicit in the next revision. =C2=A0

=

=E2=80=8BAd a) - EPE works fine with next hop self on the ASBRs of= the bacbone. So if your proposal requires external links to be passive in = the backbone IGP then the draft needs to state it well. Besides it may not = be sufficient if more then one backbone instance is used to interconnect DC= s.=C2=A0

Ad b) - The c= urrent set of procedures described in section 2 for constructing auto disco= very routes is not sufficient. GW may be interconnected to more then one ba= ckbone each serving different set of prefixes within each DC (you call it X= ). So much more would need to go into the auto-discovery to make this work = in practice. And even if you would go that way it will be slow to re-advert= ise all prefixes with different tunnel attribute content.=C2=A0
=

[JD]=C2=A0=C2=A0 Are you simply= repeating the opinion you expressed when the tunnel-encaps draft first cam= e out, or do you have a scalability concern that hasn't already been discussed?=

<= /blockquote>

=E2=80=8BI am expressing the observation that tunnel-encaps may= work well to pass static information or information which may change by co= nfigiration.=C2=A0

Here you are using it to pass remote reachability info embedd= ed into it. I find it far from optimal which as combined with possible DC p= refix scale is likely to cause more issues then benefits.=C2=A0

That's why I suggest use of i= ndirection layer to solve this overall problem. As mentioned one could be L= ISP or any other SD-WAN solutions.=C2=A0

=
Thx,
R.

--001a11402d9c524b2305339d3ad3-- From nobody Tue May 24 14:59:13 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 157DC12D817; Tue, 24 May 2016 14:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VaBAYkm4IL85; Tue, 24 May 2016 14:59:06 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24FBA12D9D5; Tue, 24 May 2016 14:59:06 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id k98so11305826lfi.1; Tue, 24 May 2016 14:59:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=GKn8aaixS6J6nllQucGsIHvgSMJjxgFU9c5Hxw3BZVo=; b=0KeQL2MRbNL6IcVAP8IxEp8lXFMpsFBarVu7NhK89TVW9fp+PQtNH+Xcw6NRaVHhNB 6/REbpdm2bWWXdqwxa5Rc46rTQJ+EEXeBCDzq1QnKjJJZIk8+7u2wG+VjnV66hYw20sl bYUfaoCm9k1SNhPgyVVc0RBHrgBcWrLbHqUX6cEXM/FwjABRQ73H4jLMLISWNkHmXsTT 1KAKUigZX44MZQIH4Iymk3v4AwaKHMce2QXG3WWnpJxtWCXCP9XPabJ7rB3vfzbl8ACm 2IoBB9f4owSkrawxB56ImdVSEGMfYq3GfoVageDXpTvIsJ/iUxQw4WEi+1pa+0ED93EG jUSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=GKn8aaixS6J6nllQucGsIHvgSMJjxgFU9c5Hxw3BZVo=; b=EJQsL3gnbXeO686y1CY0DKLh6lUnVmMabPns38gxd1ZWJo18Z8+pXBMMtlTh8s4Iol CqN8YuXQDfZIimqAQuunvK4/8qgcwlp/rLlDUh5Xzy6NUlnyZr/8h1kVCH3jz28Gqh1u ZDkQqZUMNy6k1MhyRFNxcoVZnJedDIdynXhwAwWSSjRly9sQbfluJNCSeDgyfVLyoDVR laFGdda6ekZ5s2nFsBozy6bW29ABlXyVlRL684VRzdYSrP1KIdJSMRJT9d67tEP0E8fK k1s/1CbjnIgtZq9VWly5kmwQdVLYlkjP/9kLwTYBzc1dsEuRLuDS+qxsVYljMuiwsF4S oBDw== X-Gm-Message-State: ALyK8tKFaJcnRCXxxBpCtd0yIpYuDldY7qkC7ErNWtVJT4aglf+W0D/Bin3odfWul7XGDKU53FcUllxoeo+xSw== MIME-Version: 1.0 X-Received: by 10.25.33.133 with SMTP id h127mr78927lfh.82.1464127144268; Tue, 24 May 2016 14:59:04 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.25.134.196 with HTTP; Tue, 24 May 2016 14:59:04 -0700 (PDT) In-Reply-To: References: <01ea01d1b51a$7cf31e60$76d95b20$@olddog.co.uk> Date: Tue, 24 May 2016 23:59:04 +0200 X-Google-Sender-Auth: g6oeAjEeJDQmqDS7VcF-hKapOqo Message-ID: From: Robert Raszuk To: John E Drake Content-Type: multipart/alternative; boundary=001a113f1888571bf205339daac7 Archived-At: Cc: "spring@ietf.org" , idr wg Subject: Re: [Idr] [spring] New draft for data center gateways X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 21:59:08 -0000 --001a113f1888571bf205339daac7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable John, Adrian & Eric, Btw .. indirection I am suggesting may not only be realized by choice of a new overlay system. Alternative design would be to only encode a given's DC "COLOR" or "ID" into the tunnel encapsulation attribute which would not change for each X then to establish full mesh EBGP multihop sessions between interesting GWs with each again carrying the tunnel attribute with same set of "IDs" or "COLORS" as would do atomic prefixes. - If such full eBGP mesh would be getting large use of stock BGP Route Server may be used at any DC or in the backbone. - Over such sessions single prefixes would be exchanged - something what you refer to auto discovery routes in current document but those would be only send over EBGP not IBGP. - This would also remove any need to run intra-DC auto discovery. - The connectivity restoration time would be significantly reduced as multihop BFD may be used (directly or to RS). The above described proposal changes your current architecture however I believe it significantly simplifies things, removes the concern of scale and simplifies or even eliminates any new development needed to deploy it today provided that given's vendor policy already allows to match routes with specific attribute payload. Cheers, R. PS. If this game is under same administration (which I think it is based on the requirements) then to mark the routes use of standard or extended community can be used instead of tunnel encapsulation attribute. On Tue, May 24, 2016 at 11:27 PM, Robert Raszuk wrote: > Hi John, > > *[JD] We were assuming that a) GW/backbone links would be advertised in >> BGP LS (optionally w/ EPE) and b) a GW that is disconnected from the >> backbone does not advertise an auto-discovery route. This will be made >> explicit in the next revision. * >> > > =E2=80=8BAd a) - EPE works fine with next hop self on the ASBRs of the ba= cbone. So > if your proposal requires external links to be passive in the backbone IG= P > then the draft needs to state it well. Besides it may not be sufficient i= f > more then one backbone instance is used to interconnect DCs. > > Ad b) - The current set of procedures described in section 2 for > constructing auto discovery routes is not sufficient. GW may be > interconnected to more then one backbone each serving different set of > prefixes within each DC (you call it X). So much more would need to go in= to > the auto-discovery to make this work in practice. And even if you would g= o > that way it will be slow to re-advertise all prefixes with different tunn= el > attribute content. > > *[JD] Are you simply repeating the opinion you expressed when the >> tunnel-encaps draft first came out, or do you have a scalability concern >> that hasn't already been discussed?* >> >> > =E2=80=8BI am expressing the observation that tunnel-encaps may work well= to pass > static information or information which may change by configiration. > > Here you are using it to pass remote reachability info embedded into it. = I > find it far from optimal which as combined with possible DC prefix scale = is > likely to cause more issues then benefits. > > That's why I suggest use of indirection layer to solve this overall > problem. As mentioned one could be LISP or any other SD-WAN solutions. > > Thx, > R. > > --001a113f1888571bf205339daac7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
John, Adrian & Eric,

Btw .. indirection I am suggesting m= ay not only be realized by choice of a new overlay system.=C2=A0

Alternative design would be to o= nly encode a given's DC "COLOR" or "ID" into the tu= nnel encapsulation attribute which would not change for each X then to esta= blish full mesh EBGP multihop sessions between interesting GWs with each ag= ain carrying the tunnel attribute with same set of "IDs" or "= ;COLORS" as would do atomic prefixes.=C2=A0
- If such full eBGP mesh would be getting large = use of stock BGP Route Server may be used at any DC or in the backbone.=C2= =A0

- Over such sessio= ns single prefixes would be exchanged - something what you refer to auto di= scovery routes in current document but those would be only send over EBGP n= ot IBGP.=C2=A0

- This = would also remove any need to run intra-DC auto discovery.=C2=A0

- The connectivity restoration t= ime would be significantly reduced as multihop BFD may be used (directly or= to RS).


The above described proposal changes your current architect= ure however I believe it significantly simplifies things, removes the conce= rn of scale and simplifies or even eliminates any new development needed to= deploy it today provided that given's vendor policy already allows to = match routes with specific attribute payload.
<= br>
Cheers,
R.

PS. If this game is under same= administration (which I think it is based on the requirements) then to mar= k the routes use of standard or extended community can be used instead of t= unnel encapsulation attribute.=C2=A0









On Tue, = May 24, 2016 at 11:27 PM, Robert Raszuk <robert@raszuk.net> = wrote:
Hi John,

[J= D]=C2=A0 We were assuming that a) GW/backbone links would be advertised in = BGP LS (optionally w/ EPE) and b) a GW that is disconnected from the backbone does not advertise an auto-discovery route.=C2=A0 This w= ill be made explicit in the next revision. =C2=A0

=

=E2=80=8BAd a) - EPE works fine with next hop self on the ASB= Rs of the bacbone. So if your proposal requires external links to be passiv= e in the backbone IGP then the draft needs to state it well. Besides it may= not be sufficient if more then one backbone instance is used to interconne= ct DCs.=C2=A0

Ad b) - = The current set of procedures described in section 2 for constructing auto = discovery routes is not sufficient. GW may be interconnected to more then o= ne backbone each serving different set of prefixes within each DC (you call= it X). So much more would need to go into the auto-discovery to make this = work in practice. And even if you would go that way it will be slow to re-a= dvertise all prefixes with different tunnel attribute content.=C2=A0
<= /div>

[JD]=C2=A0=C2=A0 Are you simply= repeating the opinion you expressed when the tunnel-encaps draft first cam= e out, or do you have a scalability concern that hasn't already been discussed?=

<= /blockquote>

=E2=80=8BI am expressing the observation that tunnel-enc= aps may work well to pass static information or information which may chang= e by configiration.=C2=A0

Here you are using it to pass remote reachability info = embedded into it. I find it far from optimal which as combined with possibl= e DC prefix scale is likely to cause more issues then benefits.=C2=A0
=

That's why I suggest us= e of indirection layer to solve this overall problem. As mentioned one coul= d be LISP or any other SD-WAN solutions.=C2=A0

=
Thx,
R.


--001a113f1888571bf205339daac7-- From nobody Tue May 24 15:43:45 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AFCAC12D58F; Tue, 24 May 2016 15:43:41 -0700 (PDT) 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: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160524224341.14017.96672.idtracker@ietfa.amsl.com> Date: Tue, 24 May 2016 15:43:41 -0700 Archived-At: Cc: idr-chairs@ietf.org, draft-ietf-idr-ix-bgp-route-server@ietf.org, shares@ndzh.com, idr@ietf.org Subject: [Idr] Last Call: (Internet Exchange BGP Route Server) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 22:43:42 -0000 The IESG has received a request from the Inter-Domain Routing WG (idr) to consider the following document: - 'Internet Exchange BGP Route Server' as Proposed Standard 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 2016-06-07. 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 This document outlines a specification for multilateral interconnections at Internet exchange points (IXPs). Multilateral interconnection is a method of exchanging routing information between three or more external BGP speakers using a single intermediate broker system, referred to as a route server. Route servers are typically used on shared access media networks, such as Internet exchange points (IXPs), to facilitate simplified interconnection between multiple Internet routers. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-idr-ix-bgp-route-server/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-idr-ix-bgp-route-server/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue May 24 18:20:36 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9359E12D520 for ; Tue, 24 May 2016 18:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JvBsVhEvGOJ7 for ; Tue, 24 May 2016 18:20:24 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0624E12D100 for ; Tue, 24 May 2016 18:20:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11779; q=dns/txt; s=iport; t=1464139223; x=1465348823; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=fFaz7cs3iBSkz9NHR2qSs5mvhaNcYUxPbY1xbVoXCaY=; b=UdsCE3VsLlQ7mpdsyiHkMJ8pSqBIfGWQeEjEa41fLrlPdQ66caDR/LA8 fziK9uHXzqOWIIqAcggSDcIiKdDVJY7pNGQY9NpTxqUDoLtPd1pSKAzCn 8grIIgpyOUCEy8/h8hMMjXYZYEJIoSbLaNEROjTJ55C3RxdEW5CJmlof2 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AdAgDc/ERX/5pdJa1bgmxLVn0GtQeEe?= =?us-ascii?q?QENgXYkhW0CHIEUOBQBAQEBAQEBZSeEQgEBAQQjCkwQAgEIDgMDAQIoAwICAjA?= =?us-ascii?q?UCQgBAQQBDQWILw6yPpFsAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWKc4RfgmGCW?= =?us-ascii?q?QWYNwGFf4gggWmET4MshTiPSwEeAQFCg21uAYkHfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,362,1459814400"; d="scan'208,217";a="111565125" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 May 2016 01:20:22 +0000 Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u4P1KMV3025924 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 25 May 2016 01:20:22 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 24 May 2016 21:20:21 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Tue, 24 May 2016 21:20:21 -0400 From: "Acee Lindem (acee)" To: Susan Hares , "idr@ietf.org" Thread-Topic: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) Thread-Index: AdG19Q0c4DmlRxlfTIa/f3EYODPjkAALotyA Date: Wed, 25 May 2016 01:20:21 +0000 Message-ID: References: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> In-Reply-To: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: multipart/alternative; boundary="_000_D36A75FD624ECaceeciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Keyur Patel \(keyupate\)" , "David Ward \(wardd\)" Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 01:20:33 -0000 --_000_D36A75FD624ECaceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBoYXZlIHJlYWQgdGhlIGRvY3VtZW50IGFuZCBzdXBwb3J0IHB1YmxpY2F0aW9uLg0KVGhhbmtz LA0KQWNlZQ0KDQpGcm9tOiBJZHIgPGlkci1ib3VuY2VzQGlldGYub3JnPG1haWx0bzppZHItYm91 bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBTdXNhbiBIYXJlcyA8c2hhcmVzQG5kemguY29t PG1haWx0bzpzaGFyZXNAbmR6aC5jb20+Pg0KRGF0ZTogVHVlc2RheSwgTWF5IDI0LCAyMDE2IGF0 IDQ6NDIgUE0NClRvOiBJRFIgTGlzdCA8aWRyQGlldGYub3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+ Pg0KQ2M6ICJLZXl1ciBQYXRlbCAoa2V5dXBhdGUpIiA8a2V5dXBhdGVAY2lzY28uY29tPG1haWx0 bzprZXl1cGF0ZUBjaXNjby5jb20+PiwgIkRhdmlkIFdhcmQgKHdhcmRkKSIgPHdhcmRkQGNpc2Nv LmNvbTxtYWlsdG86d2FyZGRAY2lzY28uY29tPj4NClN1YmplY3Q6IFtJZHJdIGRyYWZ0LWlldGYt aWRyLWJncC1leHRlbmRlZC1tZXNzYWdlcy0xMiBXRyBMQyAoNS8yNCB0byA2LzcpDQoNClRoaXMg YmVnaW5zIGEgMiB3ZWVrIFdHIExDIG9uIGRyYWZ0LWlldGYtaWRyLWJncC1leHRlbmRlZC1tZXNz YWdlcyAoNS8yNCB0byA2LzcpLiBUaGUgZHJhZnQgY2FuIGJlIGZvdW5kIGF0Og0KDQpodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWlkci1iZ3AtZXh0ZW5kZWQtbWVz c2FnZXMvDQoNCkluIHlvdXIgY29tbWVudHMgcGxlYXNlIHByb3ZpZGUgdGhlIGZvbGxvd2luZyBp bmZvcm1hdGlvbjoNCg0KMSkgICAgICBTdXBwb3J0L+KAnW5vLXN1cHBvcnTigJ0gb2YgdGhpcyBk cmFmdCBiZWluZyByZWFkeSBmb3IgcHVibGljYXRpb24sDQoNCjIpICAgICAgWW91IGtub3cgb2Yg YW4gaW1wbGVtZW50YXRpb24gZm9yIHRoaXMgZHJhZnQsIHBsZWFzZSByZXBvcnQgdGhlIGltcGxl bWVudGF0aW9uIHRvIHRoZSBJRFIgV2lraQ0KDQpodHRwczovL3RyYWMudG9vbHMuaWV0Zi5vcmcv d2cvaWRyL3RyYWMvd2lraS9kcmFmdC1pZXRmLWlkci1iZ3AtZXh0ZW5kZWQtaW1wbGVtZW50YXRp b25zDQoNCg0KMykgICAgICBEbyB5b3UgaGF2ZSBhbnkgY29uY2VybnMgYWJvdXQgZXh0ZW5kaW5n IHRoZSBCR1AgbWVzc2FnZXMuDQoNClN1ZSBIYXJlcyBhbmQgSm9obiBTY3VkZGVyDQo= --_000_D36A75FD624ECaceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5JIGhhdmUgcmVh ZCB0aGUgZG9jdW1lbnQgYW5kIHN1cHBvcnQgcHVibGljYXRpb24uJm5ic3A7PC9kaXY+DQo8ZGl2 PlRoYW5rcyw8L2Rpdj4NCjxkaXY+QWNlZTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFu IGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxp YnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVS LUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1C T1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVS LVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJ TkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bh bj5JZHIgJmx0OzxhIGhyZWY9Im1haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZyI+aWRyLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgU3VzYW4gSGFyZXMgJmx0OzxhIGhyZWY9 Im1haWx0bzpzaGFyZXNAbmR6aC5jb20iPnNoYXJlc0BuZHpoLmNvbTwvYT4mZ3Q7PGJyPg0KPHNw YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5UdWVzZGF5LCBNYXkgMjQs IDIwMTYgYXQgNDo0MiBQTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Ubzog PC9zcGFuPklEUiBMaXN0ICZsdDs8YSBocmVmPSJtYWlsdG86aWRyQGlldGYub3JnIj5pZHJAaWV0 Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9z cGFuPiZxdW90O0tleXVyIFBhdGVsIChrZXl1cGF0ZSkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0 bzprZXl1cGF0ZUBjaXNjby5jb20iPmtleXVwYXRlQGNpc2NvLmNvbTwvYT4mZ3Q7LCAmcXVvdDtE YXZpZCBXYXJkICh3YXJkZCkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp3YXJkZEBjaXNjby5j b20iPndhcmRkQGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0 OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5bSWRyXSBkcmFmdC1pZXRmLWlkci1iZ3AtZXh0ZW5kZWQt bWVzc2FnZXMtMTIgV0cgTEMgKDUvMjQgdG8gNi83KTxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RF IiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBN QVJHSU46MCAwIDAgNTsiPg0KPGRpdiB4bWxuczp2PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29t OnZtbCIgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIg Y29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwh LS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNh bWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGku TXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9y aXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJv dHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30N CnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyog TGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTgxNjkyNDY7DQoJ bXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMzcxNjA2MjY0 IDY3Njk4NzA1IDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3 Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwt dGV4dDoiJTFcKSI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDIN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9t YW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJ e21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxp c3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7 DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDph bHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50 Oi05LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9t OjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8ZGl2IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGJl Z2lucyBhIDIgd2VlayBXRyBMQyBvbiBkcmFmdC1pZXRmLWlkci1iZ3AtZXh0ZW5kZWQtbWVzc2Fn ZXMgKDUvMjQgdG8gNi83KS4gVGhlIGRyYWZ0IGNhbiBiZSBmb3VuZCBhdDoNCjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLWlkci1iZ3AtZXh0ZW5kZWQtbWVzc2FnZXMvIj5odHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWlkci1iZ3AtZXh0ZW5kZWQtbWVzc2FnZXMvPC9hPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiB5b3VyIGNvbW1lbnRzIHBsZWFzZSBwcm92aWRlIHRo ZSBmb2xsb3dpbmcgaW5mb3JtYXRpb246IDxvOnA+DQo8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZl bDEgbGZvMiI+PCEtLVtpZiAhc3VwcG9ydExpc3RzXS0tPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJ Z25vcmUiPjEpPHNwYW4gc3R5bGU9ImZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNh cHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgZm9udC1zaXplOiA3cHQ7IGxpbmUtaGVp Z2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48IS0tW2VuZGlmXS0tPlN1cHBvcnQv 4oCdbm8tc3VwcG9ydOKAnSBvZiB0aGlzIGRyYWZ0IGJlaW5nIHJlYWR5IGZvciBwdWJsaWNhdGlv biw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4 dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IS0tW2lmICFzdXBwb3J0 TGlzdHNdLS0+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Mik8c3BhbiBzdHlsZT0iZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDog bm9ybWFsOyBmb250LXNpemU6IDdwdDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nOyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+PC9zcGFuPjwhLS1bZW5kaWZdLS0+WW91IGtub3cgb2YgYW4gaW1wbGVtZW50YXRpb24gZm9y IHRoaXMgZHJhZnQsIHBsZWFzZSByZXBvcnQgdGhlIGltcGxlbWVudGF0aW9uIHRvIHRoZSBJRFIg V2lraTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxhIGhyZWY9Imh0dHBzOi8vdHJhYy50b29scy5pZXRmLm9y Zy93Zy9pZHIvdHJhYy93aWtpL2RyYWZ0LWlldGYtaWRyLWJncC1leHRlbmRlZC1pbXBsZW1lbnRh dGlvbnMiPmh0dHBzOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9pZHIvdHJhYy93aWtpL2RyYWZ0 LWlldGYtaWRyLWJncC1leHRlbmRlZC1pbXBsZW1lbnRhdGlvbnM8L2E+DQo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouMjVpbiI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQt aW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCEtLVtpZiAhc3VwcG9ydExp c3RzXS0tPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjMpPHNwYW4gc3R5bGU9ImZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgZm9udC1zaXplOiA3cHQ7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAn VGltZXMgTmV3IFJvbWFuJzsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFu Pjwvc3Bhbj48IS0tW2VuZGlmXS0tPkRvIHlvdSBoYXZlIGFueSBjb25jZXJucyBhYm91dCBleHRl bmRpbmcgdGhlIEJHUCBtZXNzYWdlcy4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TdWUgSGFy ZXMgYW5kIEpvaG4gU2N1ZGRlciA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D36A75FD624ECaceeciscocom_-- From nobody Tue May 24 20:57:16 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A32612D5DD for ; Tue, 24 May 2016 20:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIEfXk-usSmW for ; Tue, 24 May 2016 20:57:13 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8828412D5C0 for ; Tue, 24 May 2016 20:57:13 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id o16so36192537ywd.2 for ; Tue, 24 May 2016 20:57:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=2ugd/W7vQ+hvJPI8BjUjuHc/joJhMo9BG4A7b7f/Bkw=; b=a/LU17FhYag59QMTCWaFgd4XTqh/rgXBqemisI3fEFTT1JsaevPj6Rt0mwafKnbjgQ Fu/H8TzxSlzauIrRtg18FYSy/u+iWujhQum4tKGgGStlYv6/txX1k6EwXcefQFj+Kk6C +In6bTX1HLBck2yMBvlr5umlqULIbKn3FlxesvFjidJl0m9H0A6Ee15n7ZMJbDnRZBIv q1wduCx0BplHJB6HH2oI3oFLmeJ4PGnJbHBanY6vqCrfyfEcyqZKXmyGtYQPKRnrDZ48 LEPh995uRWkaVNNA0pCUfz5+RBz3/eIfoE7yHO3ro6Jrqo1RrgHKMwrvndQu4MjcK2jY VtDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=2ugd/W7vQ+hvJPI8BjUjuHc/joJhMo9BG4A7b7f/Bkw=; b=jScR1rA7jnA9z0aphV7TSG30LsK9TKFQGYIqbLIxAPiM3EmB3cyAyuc3IHs/j0OnIa nzzUDpoTF1C8WRTczkrgrairxCQn/QwabjhCngxoCTnP7SkU3Up5w2S1bNvcbekqg8bb kLlPiykP/twlDOY5k3m5/ghfBdiD1gtIMM+WQpR1RComdJxSp2ueXzVNYZpNhrl7uOqG 5noYKLIf1dnI0tCgYM98udkBP6B2abgD7njgKSJZcdRkNelOqN5KoMMOIEK74oT4RCKR kUUgBbkoK6M4WvqdV1/DZwfwXLx6E3Nzb07gDelsrIMrZeszH2keML/anXhbv+OImHU/ JjoQ== X-Gm-Message-State: ALyK8tIC66d2AHu7FhwVJLYgmjRm+2eWJZQnDEznrAEL0VTngHkX71/H4eVz652E0h7xzClu77bJJ+CHSFfeug== MIME-Version: 1.0 X-Received: by 10.37.108.69 with SMTP id h66mr1033498ybc.102.1464148632631; Tue, 24 May 2016 20:57:12 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.13.209.198 with HTTP; Tue, 24 May 2016 20:57:12 -0700 (PDT) In-Reply-To: References: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> Date: Tue, 24 May 2016 23:57:12 -0400 X-Google-Sender-Auth: uP5cOa7kO5x3_6hndeOzfdVdrJA Message-ID: From: Christopher Morrow To: "Acee Lindem (acee)" Content-Type: multipart/alternative; boundary=001a1148b44025815c0533a2ab56 Archived-At: Cc: "Keyur Patel \(keyupate\)" , "idr@ietf.org" , Susan Hares , "David Ward \(wardd\)" Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 03:57:15 -0000 --001a1148b44025815c0533a2ab56 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, May 24, 2016 at 9:20 PM, Acee Lindem (acee) wrote: > > I have read the document and support publication. > Thanks, > Acee > > From: Idr on behalf of Susan Hares > Date: Tuesday, May 24, 2016 at 4:42 PM > To: IDR List > Cc: "Keyur Patel (keyupate)" , "David Ward (wardd)" < wardd@cisco.com> > Subject: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7= ) > > This begins a 2 week WG LC on draft-ietf-idr-bgp-extended-messages (5/24 to 6/7). The draft can be found at: > > > > https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/ > > =E2=80=8BI too enjoyed reading this document, and support it's publication.= =E2=80=8B > > In your comments please provide the following information: > > 1) Support/=E2=80=9Dno-support=E2=80=9D of this draft being ready fo= r publication, > > 2) You know of an implementation for this draft, please report the implementation to the IDR Wiki > > > > https://trac.tools.ietf.org/wg/idr/trac/wiki/draft-ietf-idr-bgp-extended-im= plementations > > > > 3) Do you have any concerns about extending the BGP messages. > > > > Sue Hares and John Scudder > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --001a1148b44025815c0533a2ab56 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, May 24, 2016 at 9:20 PM, Acee Lindem (acee= ) <acee@cisco.com> wrote:
&g= t;
> I have read the document and support publication.
> Thank= s,
> Acee
>
> From: Idr <idr-bounces@ietf.org> on behalf of Susan Hares <shares@ndzh.com>
> Date: Tuesday,= May 24, 2016 at 4:42 PM
> To: IDR List <idr@ietf.org>
> Cc: "Keyur Patel (keyupate)" = <keyupate@cisco.com>, "= ;David Ward (wardd)" <wardd@cisc= o.com>
> Subject: [Idr] draft-ietf-idr-bgp-extended-messages-1= 2 WG LC (5/24 to 6/7)
>
> This begins a 2 week WG LC on draft-i= etf-idr-bgp-extended-messages (5/24 to 6/7). The draft can be found at:
= >
> =C2=A0
>
> https://datatracker.ietf.org/do= c/draft-ietf-idr-bgp-extended-messages/
>
> =C2=A0

=
=E2=80=8B= I too enjoyed reading this document, and support it's publication.=E2= =80=8B


>
> In your comments please provide= the following information:
>
> 1) =C2=A0 =C2=A0 =C2=A0Support/= =E2=80=9Dno-support=E2=80=9D of this draft being ready for publication,
= >
> 2) =C2=A0 =C2=A0 =C2=A0You know of an implementation for this = draft, please report the implementation to the IDR Wiki
>
> =C2= =A0
>
> https://trac.tools.ietf.org/w= g/idr/trac/wiki/draft-ietf-idr-bgp-extended-implementations
>
= > =C2=A0
>
> 3) =C2=A0 =C2=A0 =C2=A0Do you have any concerns= about extending the BGP messages.
>
> =C2=A0
>
> S= ue Hares and John Scudder
>
>
> _________________________= ______________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
<= /div>
--001a1148b44025815c0533a2ab56-- From nobody Tue May 24 21:06:05 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF88A12D1BD for ; Tue, 24 May 2016 21:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.628 X-Spam-Level: X-Spam-Status: No, score=-5.628 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSwRSjR_9Gyk for ; Tue, 24 May 2016 21:06:03 -0700 (PDT) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 619EB12D5C0 for ; Tue, 24 May 2016 21:06:03 -0700 (PDT) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 9648A87F32; Wed, 25 May 2016 04:06:02 +0000 (UTC) Date: Wed, 25 May 2016 04:06:02 +0000 From: heasley To: Christopher Morrow Message-ID: <20160525040602.GB47244@shrubbery.net> References: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: "Keyur Patel \(keyupate\)" , "idr@ietf.org" , Susan Hares , "David Ward \(wardd\)" Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 04:06:04 -0000 Tue, May 24, 2016 at 11:57:12PM -0400, Christopher Morrow: > > This begins a 2 week WG LC on draft-ietf-idr-bgp-extended-messages (5/24 > to 6/7). The draft can be found at: > > > > > > > > https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/ > > > > > > ​I too enjoyed reading this document, and support it's publication.​ enjoyed? I too support publication. From nobody Tue May 24 22:46:43 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E6D12D164 for ; Tue, 24 May 2016 22:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJ_3NdHhNLou for ; Tue, 24 May 2016 22:46:39 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DD2712B01B for ; Tue, 24 May 2016 22:46:39 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id b124so14828566pfb.0 for ; Tue, 24 May 2016 22:46:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=1EQ3Fgnb4z/963Myj/tv6lN2lxPPTXoufvmhMTJn/aI=; b=ukxDH8jTA5ZY5coNpWOuEN8G6HSohN/jrG9k0/TBwdGii3TFqgiNW+6bxd9c+GxtTJ 5Kk8PtpbhqvHA7kzkDcarrox6ckM8edRZYhUtCndf0sNc+tuJXJTELpbC2vimP/DiUId TZqyN6BC5MY7iL3M2oa12TfOJOz/uFxLmSCwhO83myZRKHaGudKjlvL3Zvgn2DRYfbL0 j7sfexEvvunmGU9LXmYe4hTj802HFOpR7D6X5WgoK2tpzCQdXtyx9VY/Gf3BYNOEzXSC S19ctOg7KEW5ZnGX3rYRf9SjTxB2zNZDUJBe98ub3FC4fm5vXExEApXzTYWPSg2X1F52 ow9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=1EQ3Fgnb4z/963Myj/tv6lN2lxPPTXoufvmhMTJn/aI=; b=YdZsINn4Ow6oaxCMDn5ti2ZMdr2VcnYr+/t/UioYWEhw007pTLXkgrctLoBq+DbeyM tA/9+qZ+Ir2yJyMYhYM7cuEcXdnn5GPWEBUCuFW4/zD9hgoo3Jc2DW0bZzK5x1N2DvAE mMV4aVdh01bk3OFoCV6lK++4Kvq5Vkwq3e+K+vlC0uPQvigx7ghM6Z83I0fDrSYplDkG N0hUBzKZfummGE/ZxQTKky3b+PLb+u3RGOmPi2DGPsvpZUumSLHA7ffMlFE3ZX3DsQLV glt05SCJtTHoDU9lcuHPpe8q+A4KGpGMLBFupjM3DitzzXlM4fyUtMO/Zz78Zy8GrUyz zmfQ== X-Gm-Message-State: ALyK8tLk3l+kvr00tLT32EPOzGKS+0zCzagpojhWP99cWHK3WiA3DhgBXMOsufDfhWL0kw== X-Received: by 10.98.0.84 with SMTP id 81mr3043083pfa.80.1464155199089; Tue, 24 May 2016 22:46:39 -0700 (PDT) Received: from [192.168.1.28] ([76.126.247.72]) by smtp.gmail.com with ESMTPSA id t77sm1079062pfa.71.2016.05.24.22.46.38 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 May 2016 22:46:38 -0700 (PDT) User-Agent: Microsoft-MacOutlook/f.15.1.160411 Date: Tue, 24 May 2016 22:46:36 -0700 From: Jeff Tantsura To: Susan Hares , Message-ID: Thread-Topic: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) References: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> In-Reply-To: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3546974797_2141347453" Archived-At: Cc: "'Keyur Patel \(keyupate\)'" , 'David Ward' Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 05:46:41 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3546974797_2141347453 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Support the publication=20 From: Idr on behalf of Susan Hares Date: Tuesday, May 24, 2016 at 1:42 PM To: Cc: "keyupate@cisco.com" , "David Ward (wardd)" Subject: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) This begins a 2 week WG LC on draft-ietf-idr-bgp-extended-messages (5/24 to= 6/7). The draft can be found at:=20 =20 https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/ =20 In your comments please provide the following information:=20 1) Support/=E2=80=9Dno-support=E2=80=9D of this draft being ready for publication, 2) You know of an implementation for this draft, please report the imp= lementation to the IDR Wiki =20 https://trac.tools.ietf.org/wg/idr/trac/wiki/draft-ietf-idr-bgp-extended-im= plementations=20 =20 3) Do you have any concerns about extending the BGP messages.=20 =20 Sue Hares and John Scudder=20 _______________________________________________ Idr mailing list Idr@ietf.o= rg https://www.ietf.org/mailman/listinfo/idr --B_3546974797_2141347453 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
Support the publica= tion 

From: Idr <idr-bounces@ietf.org> on behalf of Susan = Hares <shares@ndzh.com>
Date: Tuesday, May 24, 2016 at 1:42 PM
<= span style=3D"font-weight:bold">To: <= idr@ietf.org>
Cc: "keyupate@cisco.com" <keyupate@cisco.com>, "David Ward (wardd)" <wardd@cisco.com>
Subject: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC= (5/24 to 6/7)

This begins a 2 week WG L= C on draft-ietf-idr-bgp-extended-messages (5/24 to 6/7). The draft can be fo= und at:

 

https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-= messages/

 

In your comments please provide the following information:

1)&nbs= p;     Support/”no-sup= port” of this draft being ready for publication,

2)    =   You know of an implementation for this dr= aft, please report the implementation to the IDR Wiki

 

https://trac.tools.ietf.= org/wg/idr/trac/wiki/draft-ietf-idr-bgp-extended-implementations

 

=

3)   = ;   Do you have any concerns about ext= ending the BGP messages.

 

Sue Hares and John Scudder

<= /div>
_______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/ma= ilman/listinfo/idr --B_3546974797_2141347453-- From nobody Wed May 25 00:14:00 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 932DC12D986 for ; Wed, 25 May 2016 00:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkkCitUPmxut for ; Wed, 25 May 2016 00:13:57 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5FA512D5F7 for ; Wed, 25 May 2016 00:13:57 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1b5T0u-0006VH-8l; Wed, 25 May 2016 07:13:56 +0000 Date: Wed, 25 May 2016 09:13:55 +0200 Message-ID: From: Randy Bush To: "Susan Hares" In-Reply-To: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> References: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: idr wg list Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 07:13:58 -0000 > This begins a 2 week WG LC on draft-ietf-idr-bgp-extended-messages > (5/24 to 6/7). as the new fasion seems to require [co-]authors to 'vote', as a co-author i support this going to rfc. randy From nobody Wed May 25 00:59:33 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD11312DA65 for ; Wed, 25 May 2016 00:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id geiPss4HGSHq for ; Wed, 25 May 2016 00:59:30 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B993712D639 for ; Wed, 25 May 2016 00:59:29 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id D0516EE76F5D4; Wed, 25 May 2016 07:59:25 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4P7xReg021429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 May 2016 07:59:27 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u4P7xQ5f006848 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 May 2016 09:59:26 +0200 Received: from FR711WXCHMBA06.zeu.alcatel-lucent.com ([169.254.2.27]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Wed, 25 May 2016 09:59:26 +0200 From: "Van De Velde, Gunter (Nokia - BE)" To: Susan Hares , "idr@ietf.org" Thread-Topic: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) Thread-Index: AdG19Q0c4DmlRxlfTIa/f3EYODPjkAAZkxeA Date: Wed, 25 May 2016 07:59:26 +0000 Message-ID: <3F1E4C52-A3EF-48E0-A1F9-E5A3A71658B5@alcatel-lucent.com> References: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> In-Reply-To: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: multipart/alternative; boundary="_000_3F1E4C52A3EF48E0A1F9E5A3A71658B5alcatellucentcom_" MIME-Version: 1.0 Archived-At: Cc: "'Keyur Patel \(keyupate\)'" , 'David Ward' Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 07:59:32 -0000 --_000_3F1E4C52A3EF48E0A1F9E5A3A71658B5alcatellucentcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MSkgICAgICAgU3VwcG9ydCwgd2hpbGUgbWFraW5nIHRoZSBmb2xsb3dpbmcgb2JzZXJ2YXRpb25z Og0KDQpTZWN0aW9uIDQg4oCTIHBhcjE6IGlzIHRoZXJlIGEgcmVhc29uIHdoeSB0aGUgZmlyc3Qg 4oCYc2hvdWxk4oCZIGlzIG5vdCBhIFNIT1VMRD8gU2FtZSBmb3IgdGhlIOKAmG1heeKAmT8NClNl Y3Rpb24gNSDigJMgcGFyMTogV2hlbiB1c2luZyB0aGUgbW9yZSBsaWJlcmFsIHBvbGljeSwgSSBi ZWxpZXZlIGl0IHdvdWxkIG1ha2Ugc2Vuc2UgdG8gaW5kaWNhdGUgYSBtZXNzYWdlIHRoYXQgYW4g ZXh0ZW5kZWQgbWVzc2FnZSB3YXMgcmVjZWl2ZWQgd2hpbGUgaXQgd2FzIG5vdCBleHBlY3RlZCBh dCBhbGwNCiBHLw0KDQoNCkZyb206IElkciA8aWRyLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFs ZiBvZiBTdXNhbiBIYXJlcyA8c2hhcmVzQG5kemguY29tPg0KRGF0ZTogVHVlc2RheSAyNCBNYXkg MjAxNiBhdCAyMjo0Mg0KVG86ICJpZHJAaWV0Zi5vcmciIDxpZHJAaWV0Zi5vcmc+DQpDYzogIidL ZXl1ciBQYXRlbCAoa2V5dXBhdGUpJyIgPGtleXVwYXRlQGNpc2NvLmNvbT4sICdEYXZpZCBXYXJk JyA8d2FyZGRAY2lzY28uY29tPg0KU3ViamVjdDogW0lkcl0gZHJhZnQtaWV0Zi1pZHItYmdwLWV4 dGVuZGVkLW1lc3NhZ2VzLTEyIFdHIExDICg1LzI0IHRvIDYvNykNCg0KVGhpcyBiZWdpbnMgYSAy IHdlZWsgV0cgTEMgb24gZHJhZnQtaWV0Zi1pZHItYmdwLWV4dGVuZGVkLW1lc3NhZ2VzICg1LzI0 IHRvIDYvNykuIFRoZSBkcmFmdCBjYW4gYmUgZm91bmQgYXQ6DQoNCmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaWRyLWJncC1leHRlbmRlZC1tZXNzYWdlcy8NCg0K SW4geW91ciBjb21tZW50cyBwbGVhc2UgcHJvdmlkZSB0aGUgZm9sbG93aW5nIGluZm9ybWF0aW9u Og0KDQoxKSAgICAgICBTdXBwb3J0L+KAnW5vLXN1cHBvcnTigJ0gb2YgdGhpcyBkcmFmdCBiZWlu ZyByZWFkeSBmb3IgcHVibGljYXRpb24sDQoNCjIpICAgICAgIFlvdSBrbm93IG9mIGFuIGltcGxl bWVudGF0aW9uIGZvciB0aGlzIGRyYWZ0LCBwbGVhc2UgcmVwb3J0IHRoZSBpbXBsZW1lbnRhdGlv biB0byB0aGUgSURSIFdpa2kNCg0KaHR0cHM6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2lkci90 cmFjL3dpa2kvZHJhZnQtaWV0Zi1pZHItYmdwLWV4dGVuZGVkLWltcGxlbWVudGF0aW9ucw0KDQoN CjMpICAgICAgIERvIHlvdSBoYXZlIGFueSBjb25jZXJucyBhYm91dCBleHRlbmRpbmcgdGhlIEJH UCBtZXNzYWdlcy4NCg0KU3VlIEhhcmVzIGFuZCBKb2huIFNjdWRkZXINCg== --_000_3F1E4C52A3EF48E0A1F9E5A3A71658B5alcatellucentcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MCAw IDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlz dFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7 bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDow Y207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0K CWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMg Ki8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE4MTY5MjQ2Ow0KCW1zby1saXN0LXR5cGU6aHli cmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTM3MTYwNjI2NCA2NzY5ODcwNSA2NzY5ODcx MyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2 NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRleHQ6IiUxXCkiOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlz dCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsN Cgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDph bHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDYN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVu dDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30N CkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0K QGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTYwNDI2NDc3MzsNCgltc28tbGlzdC10eXBlOmh5YnJp ZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTczMTIwMjAzOCA2NzY5ODcwNSA2NzY5ODcxMyA2 NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5 ODcxNTt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLXRleHQ6IiUxXCkiOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBs MTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0 ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0O30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBo YS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDot OS4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBs aXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0Kb2wN Cgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9z dHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0 OmwxIGxldmVsMSBsZm8zIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxp c3Q6SWdub3JlIj4xKTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9z cGFuPjwhW2VuZGlmXT5TdXBwb3J0LCB3aGlsZSBtYWtpbmcgdGhlIGZvbGxvd2luZyBvYnNlcnZh dGlvbnM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlY3Rpb24gNCDigJMgcGFyMTogaXMgdGhl cmUgYSByZWFzb24gd2h5IHRoZSBmaXJzdCDigJhzaG91bGTigJkgaXMgbm90IGEgU0hPVUxEPyBT YW1lIGZvciB0aGUg4oCYbWF54oCZPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+U2VjdGlvbiA1IOKAkyBwYXIxOiBXaGVuIHVzaW5nIHRoZSBtb3JlIGxpYmVyYWwgcG9saWN5 LCBJIGJlbGlldmUgaXQgd291bGQgbWFrZSBzZW5zZSB0byBpbmRpY2F0ZSBhIG1lc3NhZ2UgdGhh dCBhbiBleHRlbmRlZCBtZXNzYWdlIHdhcyByZWNlaXZlZCB3aGlsZSBpdCB3YXMgbm90IGV4cGVj dGVkIGF0IGFsbDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDtHLzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+RnJvbTogPC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPklkciAmbHQ7aWRyLWJvdW5jZXNAaWV0 Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBTdXNhbiBIYXJlcyAmbHQ7c2hhcmVzQG5kemguY29tJmd0 Ozxicj4NCjxiPkRhdGU6IDwvYj5UdWVzZGF5IDI0IE1heSAyMDE2IGF0IDIyOjQyPGJyPg0KPGI+ VG86IDwvYj4mcXVvdDtpZHJAaWV0Zi5vcmcmcXVvdDsgJmx0O2lkckBpZXRmLm9yZyZndDs8YnI+ DQo8Yj5DYzogPC9iPiZxdW90OydLZXl1ciBQYXRlbCAoa2V5dXBhdGUpJyZxdW90OyAmbHQ7a2V5 dXBhdGVAY2lzY28uY29tJmd0OywgJ0RhdmlkIFdhcmQnICZsdDt3YXJkZEBjaXNjby5jb20mZ3Q7 PGJyPg0KPGI+U3ViamVjdDogPC9iPltJZHJdIGRyYWZ0LWlldGYtaWRyLWJncC1leHRlbmRlZC1t ZXNzYWdlcy0xMiBXRyBMQyAoNS8yNCB0byA2LzcpPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBiZWdpbnMgYSAyIHdl ZWsgV0cgTEMgb24gZHJhZnQtaWV0Zi1pZHItYmdwLWV4dGVuZGVkLW1lc3NhZ2VzICg1LzI0IHRv IDYvNykuIFRoZSBkcmFmdCBjYW4gYmUgZm91bmQgYXQ6DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1p ZHItYmdwLWV4dGVuZGVkLW1lc3NhZ2VzLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1pZHItYmdwLWV4dGVuZGVkLW1lc3NhZ2VzLzwvYT48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SW4geW91ciBjb21tZW50cyBwbGVhc2UgcHJvdmlkZSB0aGUgZm9sbG93aW5n IGluZm9ybWF0aW9uOiA8bzpwPg0KPC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48 IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4xKTxzcGFu IHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5TdXBw b3J0L+KAnW5vLXN1cHBvcnTigJ0gb2YgdGhpcyBkcmFmdCBiZWluZyByZWFkeSBmb3IgcHVibGlj YXRpb24sPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBw b3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjIpPHNwYW4gc3R5bGU9ImZv bnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPllvdSBrbm93IG9mIGFu IGltcGxlbWVudGF0aW9uIGZvciB0aGlzIGRyYWZ0LCBwbGVhc2UgcmVwb3J0IHRoZSBpbXBsZW1l bnRhdGlvbiB0byB0aGUgSURSIFdpa2k8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+aHR0cHM6Ly90cmFj LnRvb2xzLmlldGYub3JnL3dnL2lkci90cmFjL3dpa2kvZHJhZnQtaWV0Zi1pZHItYmdwLWV4dGVu ZGVkLWltcGxlbWVudGF0aW9ucw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlz dDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1s aXN0Oklnbm9yZSI+Myk8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwv c3Bhbj48IVtlbmRpZl0+RG8geW91IGhhdmUgYW55IGNvbmNlcm5zIGFib3V0IGV4dGVuZGluZyB0 aGUgQkdQIG1lc3NhZ2VzLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN1ZSBIYXJlcyBhbmQg Sm9obiBTY3VkZGVyIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_3F1E4C52A3EF48E0A1F9E5A3A71658B5alcatellucentcom_-- From nobody Wed May 25 02:18:53 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59AF412D578 for ; Wed, 25 May 2016 02:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1w74QrzRYon for ; Wed, 25 May 2016 02:18:50 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F12912D573 for ; Wed, 25 May 2016 02:18:50 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1b5Uxk-00077u-GD; Wed, 25 May 2016 09:18:48 +0000 Date: Wed, 25 May 2016 11:18:46 +0200 Message-ID: From: Randy Bush To: Gunter Van De Velde In-Reply-To: <3F1E4C52-A3EF-48E0-A1F9-E5A3A71658B5@alcatel-lucent.com> References: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> <3F1E4C52-A3EF-48E0-A1F9-E5A3A71658B5@alcatel-lucent.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: idr wg list Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 09:18:51 -0000 > Section 4 =E2=80=93 par1: is there a reason why the first =E2=80=98should= =E2=80=99 is not a > SHOULD? Same for the =E2=80=98may=E2=80=99?=20 a matter of style. i don't care; maybe wg will converge on an opinion. > Section 5 =E2=80=93 par1: When using the more liberal policy, I believe it > would make sense to indicate a message that an extended message was > received while it was not expected at all please be specific. by "indicate a message" are you suggesting a new "you sent a surprise" response message? randy From nobody Wed May 25 02:27:56 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BDC212D5B3 for ; Wed, 25 May 2016 02:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ns4TbT9GOL82 for ; Wed, 25 May 2016 02:27:53 -0700 (PDT) Received: from st13p11im-asmtp003.me.com (st13p11im-asmtp003.me.com [17.164.40.218]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA7EC12D567 for ; Wed, 25 May 2016 02:27:53 -0700 (PDT) Received: from process-dkim-sign-daemon.st13p11im-asmtp003.me.com by st13p11im-asmtp003.me.com (Oracle Communications Messaging Server 7.0.5.36.0 64bit (built Sep 8 2015)) id <0O7Q006007ID2200@st13p11im-asmtp003.me.com> for idr@ietf.org; Wed, 25 May 2016 09:27:51 +0000 (GMT) Received: from [192.168.0.142] (d8D8705F8.access.telenet.be [141.135.5.248]) by st13p11im-asmtp003.me.com (Oracle Communications Messaging Server 7.0.5.36.0 64bit (built Sep 8 2015)) with ESMTPSA id <0O7Q0071P7MC8900@st13p11im-asmtp003.me.com>; Wed, 25 May 2016 09:27:50 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-05-25_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1015 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1510270003 definitions=main-1605250121 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Gunter Van De Velde In-reply-to: Date: Wed, 25 May 2016 11:27:57 +0200 Content-transfer-encoding: quoted-printable Message-id: <73AB7C41-FA1D-42AB-9D5E-CE7BB37413BB@icloud.com> References: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> <3F1E4C52-A3EF-48E0-A1F9-E5A3A71658B5@alcatel-lucent.com> To: Randy Bush X-Mailer: Apple Mail (2.3124) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=4d515a; t=1464168471; bh=XydmFfimtWmz+d/+51ddILL7JeFjZgUhIiYBHtGHujA=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=XPEzhNBdxn7TaAkNYx2lhwBLtFmEIKB5Hcw9FLGLahT8QszN8Y2HpPG/FvQMFFPDC 0wzIScmN0/f8AG09wi7ibRu9HeehyGS/Cx9O01QGedQZjGdI5datuWL4VFbNBiwOG3 nye2YOWIg3ysM4P0vmvu+8a1P/41QBMM7LJYtkPm3FDHhHMVVyEy1miUdAkTt0rfvV /1s+i7kHnLLuXrafJSMT84VeWnSfZjT2ixH58pH6FE4IO3JTkQtUEAiCc2dcDMlTyp HmC5unIjLhW0M/W2Hv8iUa/Bs1U9Nwt9ZC/YeK8SEukG0W5/Ek2C86TWdlBWn2nliL xZnsGprv601SQ== Archived-At: Cc: idr wg list , Gunter Van De Velde Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 09:27:55 -0000 inline: GV> > On 25 May 2016, at 11:18, Randy Bush wrote: >=20 >> Section 4 =E2=80=93 par1: is there a reason why the first = =E2=80=98should=E2=80=99 is not a >> SHOULD? Same for the =E2=80=98may=E2=80=99?=20 >=20 > a matter of style. i don't care; maybe wg will converge on an = opinion. >=20 >> Section 5 =E2=80=93 par1: When using the more liberal policy, I = believe it >> would make sense to indicate a message that an extended message was >> received while it was not expected at all >=20 > please be specific. by "indicate a message" are you suggesting a new > "you sent a surprise" response message? >=20 GV> Yes, indeed=E2=80=A6 something in a syslog or so that the peer sent = some unexpected packet to alert the ops team to look into it. G/= From nobody Wed May 25 02:45:43 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA2712D59A for ; Wed, 25 May 2016 02:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehvq4r8AVbqx for ; Wed, 25 May 2016 02:45:41 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5378C12D592 for ; Wed, 25 May 2016 02:45:41 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1b5VNj-0007Fy-AD; Wed, 25 May 2016 09:45:39 +0000 Date: Wed, 25 May 2016 11:45:38 +0200 Message-ID: From: Randy Bush To: Gunter Van De Velde In-Reply-To: <73AB7C41-FA1D-42AB-9D5E-CE7BB37413BB@icloud.com> References: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> <3F1E4C52-A3EF-48E0-A1F9-E5A3A71658B5@alcatel-lucent.com> <73AB7C41-FA1D-42AB-9D5E-CE7BB37413BB@icloud.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: idr wg list Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 09:45:42 -0000 >>> Section 5 =E2=80=93 par1: When using the more liberal policy, I believe= it >>> would make sense to indicate a message that an extended message was >>> received while it was not expected at all >>=20 >> please be specific. by "indicate a message" are you suggesting a new >> "you sent a surprise" response message? >=20 > Yes, indeed=E2=80=A6 something in a syslog or so that the peer sent some > unexpected packet to alert the ops team to look into it. so you do not mean a bgp message, but rather that errors should be logged and maybe an snmp trap raised. so, if we start to add a short sentence or paragraph on this to the end of section 5, how far do you want to go? is there something to which we could point? randy From nobody Wed May 25 03:05:32 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A4B12D60D for ; Wed, 25 May 2016 03:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I_LWexDvLkBU for ; Wed, 25 May 2016 03:05:27 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2544612DA68 for ; Wed, 25 May 2016 03:04:35 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 5D2CBAD36F435; Wed, 25 May 2016 10:04:31 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4PA4XM7008364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 May 2016 10:04:33 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u4PA4UNR032517 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 May 2016 12:04:32 +0200 Received: from FR711WXCHMBA06.zeu.alcatel-lucent.com ([169.254.2.27]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Wed, 25 May 2016 12:04:30 +0200 From: "Van De Velde, Gunter (Nokia - BE)" To: Randy Bush , Gunter Van De Velde Thread-Topic: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) Thread-Index: AQHRtmzTn5LkPObdZkaQFH2DakgGoA== Date: Wed, 25 May 2016 10:04:29 +0000 Message-ID: <7A74147C-9988-40DE-A458-6F6F7609FF7D@alcatel-lucent.com> References: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> <3F1E4C52-A3EF-48E0-A1F9-E5A3A71658B5@alcatel-lucent.com> <73AB7C41-FA1D-42AB-9D5E-CE7BB37413BB@icloud.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: idr wg list Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 10:05:29 -0000 SW5kZWVkLCBub3RoaW5nIG9uIHByb3RvY29sIGxldmVsLiBBcG9sb2dpZXMgZm9yIHRoZSBjb25m dXNpb24uDQoNCkkgd2FzIHRoaW5raW5nIGFib3V0IGFuIG9wZXJhdGlvbmFsIG1lc3NhZ2UgYW5k IHNvbWV0aGluZyBzaW1pbGFyIGFzIGxhc3QgcGFyYWdyYXBoIG9mIGNoYXB0ZXIgNC4xIGZyb20g ZHJhZnQtaWV0Zi1ncm93LW9wcy1yZXFzLWZvci1iZ3AtZXJyb3ItaGFuZGxpbmctMDfigKYgDQoN CuKAnOKAnQ0KU2luY2UgdGhlIE5vbi1Dcml0aWNhbCBlcnJvciBoYW5kbGluZyByZXF1aXJlZCB3 aXRoaW4gdGhpcyBzZWN0aW9uDQogICByZXN1bHRzIGluIG5vIE5PVElGSUNBVElPTiBtZXNzYWdl IGJlaW5nIHRyYW5zbWl0dGVkLCB0aGUgZmFjdCB0aGF0DQogICBhbiBlcnJvciBoYXMgb2NjdXJy ZWQsIGFuZCB0aGVyZSBtYXkgYmUgaW5jb25zaXN0ZW5jeSBiZXR3ZWVuIHRoZQ0KICAgbG9jYWwg YW5kIHJlbW90ZSBCR1Agc3BlYWtlciBNVVNUIGJlIGZsYWdnZWQgdG8gdGhlIG5ldHdvcmsgb3Bl cmF0b3INCiAgIHRocm91Z2ggc3RhbmRhcmQgb3BlcmF0aW9uYWwgaW50ZXJmYWNlcyAoZS5nLiwg U05NUCwgc3lzbG9nKS4gIFRoZQ0KICAgaW5mb3JtYXRpb24gaGlnaGxpZ2h0ZWQgTVVTVCBpbmNs dWRlIHRoZSBOTFJJIGlkZW50aWZpZWQgdG8gYmUNCiAgIGNvbnRhaW5lZCB3aXRoaW4gdGhlIGVy cm9yIG1lc3NhZ2UsIGFuZCBTSE9VTEQgY29udGFpbiBhIGV4YWN0IGNvcHkNCiAgIG9mIHRoZSBy ZWNlaXZlZCBtZXNzYWdlIGZvciBmdXJ0aGVyIGFuYWx5c2lzLg0KDQrigJzigJ0NCg0KRy8NCg0K T24gMjUvMDUvMTYgMTE6NDUsICJJZHIgb24gYmVoYWxmIG9mIFJhbmR5IEJ1c2giIDxpZHItYm91 bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgcmFuZHlAcHNnLmNvbT4gd3JvdGU6DQoNCj4+Pj4g U2VjdGlvbiA1IOKAkyBwYXIxOiBXaGVuIHVzaW5nIHRoZSBtb3JlIGxpYmVyYWwgcG9saWN5LCBJ IGJlbGlldmUgaXQNCj4+Pj4gd291bGQgbWFrZSBzZW5zZSB0byBpbmRpY2F0ZSBhIG1lc3NhZ2Ug dGhhdCBhbiBleHRlbmRlZCBtZXNzYWdlIHdhcw0KPj4+PiByZWNlaXZlZCB3aGlsZSBpdCB3YXMg bm90IGV4cGVjdGVkIGF0IGFsbA0KPj4+IA0KPj4+IHBsZWFzZSBiZSBzcGVjaWZpYy4gIGJ5ICJp bmRpY2F0ZSBhIG1lc3NhZ2UiIGFyZSB5b3Ugc3VnZ2VzdGluZyBhIG5ldw0KPj4+ICJ5b3Ugc2Vu dCBhIHN1cnByaXNlIiByZXNwb25zZSBtZXNzYWdlPw0KPj4gDQo+PiBZZXMsIGluZGVlZOKApiBz b21ldGhpbmcgaW4gYSBzeXNsb2cgb3Igc28gdGhhdCB0aGUgcGVlciBzZW50IHNvbWUNCj4+IHVu ZXhwZWN0ZWQgcGFja2V0IHRvIGFsZXJ0IHRoZSBvcHMgdGVhbSB0byBsb29rIGludG8gaXQuDQo+ DQo+c28geW91IGRvIG5vdCBtZWFuIGEgYmdwIG1lc3NhZ2UsIGJ1dCByYXRoZXIgdGhhdCBlcnJv cnMgc2hvdWxkIGJlDQo+bG9nZ2VkIGFuZCBtYXliZSBhbiBzbm1wIHRyYXAgcmFpc2VkLiAgc28s IGlmIHdlIHN0YXJ0IHRvIGFkZCBhIHNob3J0DQo+c2VudGVuY2Ugb3IgcGFyYWdyYXBoIG9uIHRo aXMgdG8gdGhlIGVuZCBvZiBzZWN0aW9uIDUsIGhvdyBmYXIgZG8geW91DQo+d2FudCB0byBnbz8g IGlzIHRoZXJlIHNvbWV0aGluZyB0byB3aGljaCB3ZSBjb3VsZCBwb2ludD8NCj4NCj5yYW5keQ0K Pg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+SWRy IG1haWxpbmcgbGlzdA0KPklkckBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaWRyDQoNCg== From nobody Wed May 25 03:05:46 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8065B12D9E3 for ; Wed, 25 May 2016 03:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1d4RFvK22HkM for ; Wed, 25 May 2016 03:05:28 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EFF612D9FA for ; Wed, 25 May 2016 03:04:37 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id C7AF73B48B6; Wed, 25 May 2016 12:04:35 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.24]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 9B1214C048; Wed, 25 May 2016 12:04:35 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0294.000; Wed, 25 May 2016 12:04:35 +0200 From: To: Susan Hares , "'Keyur Patel (keyupate)'" Thread-Topic: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) Thread-Index: AdG19Q0c4DmlRxlfTIa/f3EYODPjkAAcJGMw Date: Wed, 25 May 2016 10:04:34 +0000 Message-ID: <13146_1464170675_574578B3_13146_4888_1_53C29892C857584299CBF5D05346208A0F8CD227@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> In-Reply-To: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A0F8CD227OPEXCLILM21corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.5.25.90316 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 10:05:31 -0000 --_000_53C29892C857584299CBF5D05346208A0F8CD227OPEXCLILM21corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, 1) Support. 2) Question, for my own information: why does the capability mean that= the BGP speaker is capable of _both_ receiving _and sending_ extend messa= ge? (vs capable of receiving (only)). IOTW, what is the motivation to adver= tise the capacity to send extended message? 3) Please find below some possible comments: "4. Operation" Suppose that I receive an extended BGP message (e.g. update) that I can't r= elay to some peers because they don't support such extension, while I "shou= ld" have relayed it. Is there an expected behavior? Should it be standardiz= ed? Can this create issues (e.g. inconsistent routing with an AS)? Should t= his be considered in the security considerations? (e.g. I deliberately send= an extended message, and benefit from its/the NLRI not being propagated as= expected. e.g. to influence routing policy) -- "A BGP speaker may send extended messages to its peer only if it has receiv= ed the Extended Message Capability from its peer." May be :s/received/sent and received --- " A BGP speaker that has the ability to use extended messages but has not advertised the BGP Extended Messages capability, presumably due to configuration, SHOULD NOT accept an extended message. A speaker MAY implement a more liberal policy and accept extended messages even from a peer that has not advertised the capability." I would a priori have assumed that both sentences be related. But in fact t= hey are not since the first sentence only refers to the sending of the capa= bility, while the second only refers to the reception of the capability. Sh= ouldn't both sentences be extended to cover both the sending and the receiv= ing? -- "A speaker that treats an improper extended message as a fatal error, as described in the preceding paragraph, MUST do likewise. > I'm sorry but I don't understand this sentence. What does that mean to "tre= at an improper extended message as a fatal error"? e.g. If I receive an ext= ended message with a syntax error requiring to send an NOTIFICATION (e.g. m= ore than one MP_REACH_NLRI) is this considered an improper extended messag= e with a fatal error? If so the text seems wrong as bgp speaker must not do= "likewise" (seems to refer to "reset the session with a Bad Message Leng= th NOTIFICATION") Also "as described in the preceding paragraph, MUST do likewise" seems not = precise enough to me (at least as a non-native English speaker). Which exac= tly is this preceding paragraph describing this "treats an improper extende= d message as a fatal error" --- 7. IANA Considerations "The IANA is requested to register a new BGP Capability Code to be named BG= P Extended Message Capability > I'm not sure about the formulation since IANA has already registered this c= apability as TEMPORARY. "TBD BGP-Extended Message" At least I would expect that the document ask for the _same_ value (6) rath= er than TBD. Thanks, Regards, Bruno From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, May 24, 2016 10:42 PM To: idr@ietf.org Cc: 'Keyur Patel (keyupate)'; 'David Ward' Subject: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) This begins a 2 week WG LC on draft-ietf-idr-bgp-extended-messages (5/24 to= 6/7). The draft can be found at: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/ In your comments please provide the following information: 1) Support/"no-support" of this draft being ready for publication, 2) You know of an implementation for this draft, please report the imp= lementation to the IDR Wiki https://trac.tools.ietf.org/wg/idr/trac/wiki/draft-ietf-idr-bgp-extended-im= plementations 3) Do you have any concerns about extending the BGP messages. Sue Hares and John Scudder ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_53C29892C857584299CBF5D05346208A0F8CD227OPEXCLILM21corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

1)&= nbsp;     Support.<= /o:p>

 

= 2)      Question, for my own information: why does the capability mean that the BG= P speaker is capable of _both_  receiving _and sending_ = extend message? (vs capable of receiving (only)). IOTW, what is the motivation to advertise the capacity to send ex= tended message?

&n= bsp;

= 3)      Please find below some possible comments:

&n= bsp;

“4.  Operation”
Suppose that I receive an extended BGP message (e=
.g. update) that I can’t relay to some peers because they don’t=
 support such extension, while I “should” have relayed it. Is t=
here an expected behavior? Should it be standardized? Can this create issue=
s (e.g. inconsistent routing with an AS)? Should this be considered in the =
security considerations? (e.g. I deliberately send an extended message, and=
 benefit from its/the NLRI not being propagated as expected. e.g. to influe=
nce routing policy)

&n= bsp;

--= 

“A BGP speaker may send extended messages t=
o its peer only if it has received the Extended Message Capability from its=
 peer.”
May be :s/receive=
d/sent and received

---

“   A BGP speaker that has the ab=
ility to use extended messages but has
   not advertised the BGP Extended Mess=
ages capability, presumably due
   to configuration, SHOULD NOT accept =
an extended message.  A speaker
   MAY implement a more liberal policy =
and accept extended messages even
   from a peer that has not advertised =
the capability.”

&n= bsp;

I would= a priori have assumed that both sentences be related. But in fact they are= not since the first sentence only refers to the sending of the capability,= while the second only refers to the reception of the capability. Shouldn’t both sentences be extended to cover bot= h the sending and the receiving?

--=

&n= bsp;

“A speaker that treats an improper extended=
 message as a
   fatal error, as described in the pre=
ceding paragraph, MUST do
   likewise. »

I’= ;m sorry but I don’t understand this sentence. What does that mean to= “treat an improper extended message as a fatal error”? e.g. If= I receive an extended message with a syntax error requiring to send an NOTIFICATION (e.g. more than one MP_REACH_NLRI)  is this cons= idered an improper extended message with a fatal error? If so the text seem= s wrong as bgp speaker must not do “likewise” (seems to refer t= o “reset the session   with a Bad Message Length NOTIFICATION”)

Also “as de=
scribed in the preceding paragraph, MUST do likewise” seems not precise enough to me (at least as a non-native E=
nglish speaker). Which exactly is this preceding paragraph describing this =
“treats an improper extended message as a=
 fatal error”
---
7.  IANA Con=
siderations
“The IANA is requested to register a new BG=
P Capability Code to be named BGP Extended Message Capability »<=
o:p>
I’m not sure about the formulation sinc=
e IANA has already registered this capability as TEMPORARY.
 
“TBD      BGP-Exte=
nded Message”
At least I would expect that the document ask=
 for the _same_ value (6) rather than TBD.
 
 
Thanks,
Regards,
Bruno

&n= bsp;

&n= bsp;

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Tuesday, May 24, 2016 10:42 PM
To: idr@ietf.org
Cc: 'Keyur Patel (keyupate)'; 'David Ward'
Subject: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 t= o 6/7)

 

This begins a 2 week WG LC on d= raft-ietf-idr-bgp-extended-messages (5/24 to 6/7). The draft can be found a= t:

 

https://datatracker.iet= f.org/doc/draft-ietf-idr-bgp-extended-messages/

 

In your comments please provide= the following information:

1) &nbs= p;    Support/”no-suppo= rt” of this draft being ready for publication,

2) &nbs= p;    You know of an implemen= tation for this draft, please report the implementation to the IDR Wiki

 

https://trac.tools.ietf.org/wg/idr/trac/wiki/draft-= ietf-idr-bgp-extended-implementations

 

3) &nbs= p;    Do you have any concern= s about extending the BGP messages.

 

Sue Hares and John Scudder 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_53C29892C857584299CBF5D05346208A0F8CD227OPEXCLILM21corp_-- From nobody Wed May 25 03:08:57 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 261A512D60D for ; Wed, 25 May 2016 03:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBjpxE9RxeB9 for ; Wed, 25 May 2016 03:08:51 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D99512D1EB for ; Wed, 25 May 2016 03:08:51 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1b5VkA-0007Ny-3t; Wed, 25 May 2016 10:08:50 +0000 Date: Wed, 25 May 2016 12:08:48 +0200 Message-ID: From: Randy Bush To: Gunter Van De Velde In-Reply-To: <7A74147C-9988-40DE-A458-6F6F7609FF7D@alcatel-lucent.com> References: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> <3F1E4C52-A3EF-48E0-A1F9-E5A3A71658B5@alcatel-lucent.com> <73AB7C41-FA1D-42AB-9D5E-CE7BB37413BB@icloud.com> <7A74147C-9988-40DE-A458-6F6F7609FF7D@alcatel-lucent.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: idr wg list Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 10:08:56 -0000 > Since the Non-Critical error handling required within this section > results in no NOTIFICATION message being transmitted, the fact that > an error has occurred, and there may be inconsistency between the > local and remote BGP speaker MUST be flagged to the network operator > through standard operational interfaces (e.g., SNMP, syslog). The > information highlighted MUST include the NLRI identified to be > contained within the error message, and SHOULD contain a exact copy > of the received message for further analysis. so, to remove all the flowery language, a third para in sec 5, The inconsistency between the local and remote BGP speakers MUST be reported via syslog and/or SNMP. randy From nobody Wed May 25 03:10:20 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDBF712D645 for ; Wed, 25 May 2016 03:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dx6U-DgPTYn for ; Wed, 25 May 2016 03:10:16 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CA6712D5B5 for ; Wed, 25 May 2016 03:10:16 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 392572A6ABDFC; Wed, 25 May 2016 10:10:12 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4PAAE20020488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 May 2016 10:10:14 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u4PAAAOP023142 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 May 2016 12:10:13 +0200 Received: from FR711WXCHMBA06.zeu.alcatel-lucent.com ([169.254.2.27]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Wed, 25 May 2016 12:10:12 +0200 From: "Van De Velde, Gunter (Nokia - BE)" To: Randy Bush Thread-Topic: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) Thread-Index: AQHRtm2gpjwkqPNhekyAozMylrMtUA== Date: Wed, 25 May 2016 10:10:12 +0000 Message-ID: <6BFAD444-2163-405B-9B18-B126DD853632@alcatel-lucent.com> References: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> <3F1E4C52-A3EF-48E0-A1F9-E5A3A71658B5@alcatel-lucent.com> <73AB7C41-FA1D-42AB-9D5E-CE7BB37413BB@icloud.com> <7A74147C-9988-40DE-A458-6F6F7609FF7D@alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="utf-8" Content-ID: <277DF7C847EA9D4095644087D3549234@exchange.lucent.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: idr wg list Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 10:10:18 -0000 V29ya3MgZm9yIG1lLg0KVGhhbmtzLg0KDQpHLw0KDQpPbiAyNS8wNS8xNiAxMjowOCwgIklkciBv biBiZWhhbGYgb2YgUmFuZHkgQnVzaCIgPGlkci1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBv ZiByYW5keUBwc2cuY29tPiB3cm90ZToNCg0KPj4gICAgU2luY2UgdGhlIE5vbi1Dcml0aWNhbCBl cnJvciBoYW5kbGluZyByZXF1aXJlZCB3aXRoaW4gdGhpcyBzZWN0aW9uDQo+PiAgICByZXN1bHRz IGluIG5vIE5PVElGSUNBVElPTiBtZXNzYWdlIGJlaW5nIHRyYW5zbWl0dGVkLCB0aGUgZmFjdCB0 aGF0DQo+PiAgICBhbiBlcnJvciBoYXMgb2NjdXJyZWQsIGFuZCB0aGVyZSBtYXkgYmUgaW5jb25z aXN0ZW5jeSBiZXR3ZWVuIHRoZQ0KPj4gICAgbG9jYWwgYW5kIHJlbW90ZSBCR1Agc3BlYWtlciBN VVNUIGJlIGZsYWdnZWQgdG8gdGhlIG5ldHdvcmsgb3BlcmF0b3INCj4+ICAgIHRocm91Z2ggc3Rh bmRhcmQgb3BlcmF0aW9uYWwgaW50ZXJmYWNlcyAoZS5nLiwgU05NUCwgc3lzbG9nKS4gIFRoZQ0K Pj4gICAgaW5mb3JtYXRpb24gaGlnaGxpZ2h0ZWQgTVVTVCBpbmNsdWRlIHRoZSBOTFJJIGlkZW50 aWZpZWQgdG8gYmUNCj4+ICAgIGNvbnRhaW5lZCB3aXRoaW4gdGhlIGVycm9yIG1lc3NhZ2UsIGFu ZCBTSE9VTEQgY29udGFpbiBhIGV4YWN0IGNvcHkNCj4+ICAgIG9mIHRoZSByZWNlaXZlZCBtZXNz YWdlIGZvciBmdXJ0aGVyIGFuYWx5c2lzLg0KPg0KPnNvLCB0byByZW1vdmUgYWxsIHRoZSBmbG93 ZXJ5IGxhbmd1YWdlLCBhIHRoaXJkIHBhcmEgaW4gc2VjIDUsDQo+DQo+ICAgICBUaGUgaW5jb25z aXN0ZW5jeSBiZXR3ZWVuIHRoZSBsb2NhbCBhbmQgcmVtb3RlIEJHUCBzcGVha2VycyBNVVNUIGJl DQo+ICAgICByZXBvcnRlZCB2aWEgc3lzbG9nIGFuZC9vciBTTk1QLg0KPg0KPnJhbmR5DQo+DQo+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5JZHIgbWFp bGluZyBsaXN0DQo+SWRyQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9pZHINCg0K From nobody Wed May 25 03:35:04 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6248A12D0E8 for ; Wed, 25 May 2016 03:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id suhVs07TDSo1 for ; Wed, 25 May 2016 03:35:01 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8389A12D0A8 for ; Wed, 25 May 2016 03:34:59 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id w16so4216598lfd.2 for ; Wed, 25 May 2016 03:34:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=VVqJMTDS6DBRUgVJD8azRGmduwEzydDU+v9+Z8JHOV4=; b=yFyi8/c9dh0FeHDQvp90cphkJYUHQRfWtRQwWZvpiRbQl4RHPokNXmsQmSdtCKw/N3 77aZ3mbK3/a40nxGwquhC/3vsTX2XEeIeh7gqhqtqrkVgfgo9b69vRljCHJQz01E2v95 o8nuHrku8oOCFOeESIUhVue4BUieznUP5S4ou61vr9ApolxZpgg/aEk8VgxpCcxDz9Du 8nXbXxWAmW5BQnPKbgSvcVs/X6+R5w5J20274lAEdbcdl/sI4naXFpDg2JQi0WHSj7bc Nw+4WNq3U5Iq56DP+9DrO42OxoLZZXur0+imE+0zKnF5JG7Y68K3RQ088oGTSX/DQhwH bodQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=VVqJMTDS6DBRUgVJD8azRGmduwEzydDU+v9+Z8JHOV4=; b=AUjZJ0oBMDS5wIxVaGGwpXb0uYEwgy8sM/dWPIndYy6SR4gjF3Tbcf4NxjX1vM1vuW tFrkHgRAXQ/ruSbP6uRV5sdlJUK5ccEQ5UVeXEGU75XIdqO1MdPxVPxfW7yi2FOI3b14 o1HFJ07nk4uLggqBK3ct7kx/Sis8ec+kSdvP2E/YEX0O8+VdwS/3+zWuuI/M+eCYZoIV NO40oK5eKsAB7lsfqdqBGcct0u3Ildgf8hxSytCEA8n2BQPd9tBAtN3TUjv4IHKLSMVM 2XPvas0N1CFFuymA/9G5cPsxC6oB40b4sS5HqTferq/coiYFErE7YQiJJp9ZYbVWTivF EIKg== X-Gm-Message-State: ALyK8tKTWfQ6JZlBaVoT5Fe3fl22++5IFbrnWKqSlASmW2yzvKP/3emb59bgV2uS/nRnHHvWfzt03ykrHltmqA== MIME-Version: 1.0 X-Received: by 10.25.33.133 with SMTP id h127mr602238lfh.82.1464172497687; Wed, 25 May 2016 03:34:57 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.25.134.196 with HTTP; Wed, 25 May 2016 03:34:57 -0700 (PDT) In-Reply-To: <13146_1464170675_574578B3_13146_4888_1_53C29892C857584299CBF5D05346208A0F8CD227@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> <13146_1464170675_574578B3_13146_4888_1_53C29892C857584299CBF5D05346208A0F8CD227@OPEXCLILM21.corporate.adroot.infra.ftgroup> Date: Wed, 25 May 2016 12:34:57 +0200 X-Google-Sender-Auth: XXKdIfDDs7CP0-luYTbOdzbLVsc Message-ID: From: Robert Raszuk To: Bruno Decraene Content-Type: multipart/alternative; boundary=001a113f18889d5ac60533a83937 Archived-At: Cc: "Keyur Patel \(keyupate\)" , "idr@ietf.org" , Susan Hares Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 10:35:02 -0000 --001a113f18889d5ac60533a83937 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Bruno, Suppose that I receive an extended BGP message (e.g. update) that I can=E2= =80=99t relay > > to some peers because they don=E2=80=99t support such extension, while I = =E2=80=9Cshould=E2=80=9D have > > relayed it. > > =E2=80=8BBGP does not "relay" messages .. do you have some new BGP draft in= mind which would work as BGP "repeater" ? While I recall we discussed it in the past that work were pretty much abandoned :) BGP generates messages at each BGP speaker so the above seems like non issue to me for this draft. =E2=80=8B =E2=80=8BBest, R. For the draft itself: Support =E2=80=8Bfrom me. --001a113f18889d5ac60533a83937 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Bruno,

<= /div>
Suppose that I receive an extended BGP message (e.g. upd=
ate) that I can=E2=80=99t relay
<= div>
to some peers because they don=E2=80=99t supp=
ort such extension, while I =E2=80=9Cshould=E2=80=9D have 
relayed it.

=E2= =80=8BBGP does not "relay" messages .. do you have some new BGP d= raft in mind which would work as BGP "repeater" ? While I recall = we discussed it in the past that work were pretty much abandoned :)

BGP generates messages at eac= h BGP speaker so the above seems like non issue to me for this draft.=C2=A0=

=E2=80=8B
=E2=80=8BBest,
R.

For the draft itself: Support =E2=80=8Bfrom me.=C2=A0


=C2=A0
--001a113f18889d5ac60533a83937-- From nobody Wed May 25 04:30:57 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B798112DAB7 for ; Wed, 25 May 2016 04:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id It9OJ_B2UhGz for ; Wed, 25 May 2016 04:30:54 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E16712DAD6 for ; Wed, 25 May 2016 04:30:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1824; q=dns/txt; s=iport; t=1464175850; x=1465385450; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=vWcLQA7MjAexrp//5T9jga98Ij2AqZDHl7i/S6pgC3k=; b=XXN+t4fIgiFkQCeyab7F/NuDoSYvBAkWYaVPs1wIaXckjSXLtsR5fEWX nII4W4JRlCE3a7Pv/L4sQqV9cWq2w6yz3WVurr8pQz1pACAuzePVdTDq5 +7aZ/TNgvIvZNqKHcxEEQIJGlDSNA7VYXidPTCbeFEByK304jLSTZJbNm 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D5AQCki0VX/5tdJa1bgzdWfQa5cQENg?= =?us-ascii?q?XYXC4VvAhyBHzgUAQEBAQEBAWUnhEQBAQQBAQEgEToLEAIBCBoCJgICAiULFRA?= =?us-ascii?q?CBAENBYgvDrJokXIBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYEBiXKEP4MBglkFm?= =?us-ascii?q?DcBjh+BaYRPiGSPSwEeAQFCg21uiQh/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,364,1459814400"; d="scan'208";a="277534715" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 May 2016 11:30:49 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u4PBUnMo006550 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 25 May 2016 11:30:49 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 25 May 2016 07:30:48 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Wed, 25 May 2016 07:30:48 -0400 From: "Acee Lindem (acee)" To: Randy Bush , Gunter Van De Velde Thread-Topic: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) Thread-Index: AQHRtnjiLezA7m/5nUql2FPqnNN57w== Date: Wed, 25 May 2016 11:30:48 +0000 Message-ID: References: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> <3F1E4C52-A3EF-48E0-A1F9-E5A3A71658B5@alcatel-lucent.com> <73AB7C41-FA1D-42AB-9D5E-CE7BB37413BB@icloud.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: text/plain; charset="utf-8" Content-ID: <334122A0F8D34847B4AE21B972B443F5@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: idr wg list Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 11:30:56 -0000 DQoNCk9uIDUvMjUvMTYsIDU6NDUgQU0sICJJZHIgb24gYmVoYWxmIG9mIFJhbmR5IEJ1c2giIDxp ZHItYm91bmNlc0BpZXRmLm9yZw0Kb24gYmVoYWxmIG9mIHJhbmR5QHBzZy5jb20+IHdyb3RlOg0K DQo+Pj4+IFNlY3Rpb24gNSDigJMgcGFyMTogV2hlbiB1c2luZyB0aGUgbW9yZSBsaWJlcmFsIHBv bGljeSwgSSBiZWxpZXZlIGl0DQo+Pj4+IHdvdWxkIG1ha2Ugc2Vuc2UgdG8gaW5kaWNhdGUgYSBt ZXNzYWdlIHRoYXQgYW4gZXh0ZW5kZWQgbWVzc2FnZSB3YXMNCj4+Pj4gcmVjZWl2ZWQgd2hpbGUg aXQgd2FzIG5vdCBleHBlY3RlZCBhdCBhbGwNCj4+PiANCj4+PiBwbGVhc2UgYmUgc3BlY2lmaWMu ICBieSAiaW5kaWNhdGUgYSBtZXNzYWdlIiBhcmUgeW91IHN1Z2dlc3RpbmcgYSBuZXcNCj4+PiAi eW91IHNlbnQgYSBzdXJwcmlzZSIgcmVzcG9uc2UgbWVzc2FnZT8NCj4+IA0KPj4gWWVzLCBpbmRl ZWTigKYgc29tZXRoaW5nIGluIGEgc3lzbG9nIG9yIHNvIHRoYXQgdGhlIHBlZXIgc2VudCBzb21l DQo+PiB1bmV4cGVjdGVkIHBhY2tldCB0byBhbGVydCB0aGUgb3BzIHRlYW0gdG8gbG9vayBpbnRv IGl0Lg0KPg0KPnNvIHlvdSBkbyBub3QgbWVhbiBhIGJncCBtZXNzYWdlLCBidXQgcmF0aGVyIHRo YXQgZXJyb3JzIHNob3VsZCBiZQ0KPmxvZ2dlZCBhbmQgbWF5YmUgYW4gc25tcCB0cmFwIHJhaXNl ZC4gIHNvLCBpZiB3ZSBzdGFydCB0byBhZGQgYSBzaG9ydA0KPnNlbnRlbmNlIG9yIHBhcmFncmFw aCBvbiB0aGlzIHRvIHRoZSBlbmQgb2Ygc2VjdGlvbiA1LCBob3cgZmFyIGRvIHlvdQ0KPndhbnQg dG8gZ28/ICBpcyB0aGVyZSBzb21ldGhpbmcgdG8gd2hpY2ggd2UgY291bGQgcG9pbnQ/DQoNCkZX SVcgLSBJbiBSRkMgNzY4NCwgd2UgbWVyZWx5IGFkZGVkIHRoZSBmb2xsb3dpbmcgdGV4dCBmb3Ig dW5leHBlY3RlZA0KT1NQRnYyIGVuY29kaW5nczogDQoNCiAgICBUaGlzIHNpdHVhdGlvbiBTSE9V TEQgYmUgbG9nZ2VkIGFzIGFuIGVycm9yLg0Kb3I6DQogICAgVGhpcyBzaXR1YXRpb24gU0hPVUxE IGJlIGxvb2tlZCBhcyBhIHdhcm5pbmcuDQoNCldlIGludGVudGlvbmFsbHkgbGVmdCBvdXQgdGhl IGRldGFpbHMgb24gdGhlIG1lY2hhbmlzbXMgdXNlZCBmb3IgbG9nZ2luZw0Kb3IgaG93IHRoZSBt ZXNzYWdlcyBzaG91bGQgYmUgdXNlZC4NCg0KVGhhbmtzLA0KQWNlZQ0KDQoNCj4NCj5yYW5keQ0K Pg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+SWRy IG1haWxpbmcgbGlzdA0KPklkckBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaWRyDQoNCg== From nobody Wed May 25 04:42:03 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDA1912DAF4 for ; Wed, 25 May 2016 04:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXbUHZV5ghw8 for ; Wed, 25 May 2016 04:42:01 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E72D12DAF2 for ; Wed, 25 May 2016 04:42:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8347; q=dns/txt; s=iport; t=1464176521; x=1465386121; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+aSN+B7bpTltSNqUe3r0NyahBIEPLrAMaQMSnaU6AgQ=; b=Q1la8XbOXvdmEJDa1ZRlnpHQcQOopOg+7Q/0H4S/1nnJrCFqkrUU8Nl0 2BLRGHZgNS9vJqW52y1unW1WLlsfOHU4LaBJ6ARvOIi1UuV87O6quTpi4 zjHzpUdoQvpJPuPdfI/55pVEOI6CpvdDph/oJhVeullSCZVPBMgXiNU8n U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BRAwCnjkVX/4sNJK0YA0CCbEuBUwa0e?= =?us-ascii?q?IR5AQ2BdoYRAhyBIDgUAQEBAQEBAWUnhEMBAQEEI1YQAgEGAhEDAQIoAwICAjA?= =?us-ascii?q?UCQgCBAENBYgvk1SCAp0dkXMBAQEBAQEBAQEBAQEBAQEBAQEBAQEcinOEX4Jhg?= =?us-ascii?q?lkFkzeFAAGOH4FpjTOGM4kYAR4BAUKDbW6JCH8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,364,1459814400"; d="scan'208,217";a="277773472" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 May 2016 11:42:00 +0000 Received: from XCH-RTP-020.cisco.com (xch-rtp-020.cisco.com [64.101.220.160]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u4PBfxJ0025166 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 25 May 2016 11:42:00 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-020.cisco.com (64.101.220.160) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 25 May 2016 07:41:59 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Wed, 25 May 2016 07:41:59 -0400 From: "Acee Lindem (acee)" To: Robert Raszuk , Bruno Decraene Thread-Topic: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) Thread-Index: AQHRtnpy331Rj2Oog02xXFi+9aCxRQ== Date: Wed, 25 May 2016 11:41:59 +0000 Message-ID: References: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> <13146_1464170675_574578B3_13146_4888_1_53C29892C857584299CBF5D05346208A0F8CD227@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: multipart/alternative; boundary="_000_D36B06A76257Daceeciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Keyur Patel \(keyupate\)" , "idr@ietf.org" , Susan Hares Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 11:42:03 -0000 --_000_D36B06A76257Daceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkZyb206IElkciA8aWRyLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmlkci1ib3VuY2VzQGll dGYub3JnPj4gb24gYmVoYWxmIG9mIFJvYmVydCBSYXN6dWsgPHJvYmVydEByYXN6dWsubmV0PG1h aWx0bzpyb2JlcnRAcmFzenVrLm5ldD4+DQpEYXRlOiBXZWRuZXNkYXksIE1heSAyNSwgMjAxNiBh dCA2OjM0IEFNDQpUbzogQnJ1bm8gRGVjcmFlbmUgPGJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208 bWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20+Pg0KQ2M6ICJLZXl1ciBQYXRlbCAoa2V5 dXBhdGUpIiA8a2V5dXBhdGVAY2lzY28uY29tPG1haWx0bzprZXl1cGF0ZUBjaXNjby5jb20+Piwg SURSIExpc3QgPGlkckBpZXRmLm9yZzxtYWlsdG86aWRyQGlldGYub3JnPj4sIFN1c2FuIEhhcmVz IDxzaGFyZXNAbmR6aC5jb208bWFpbHRvOnNoYXJlc0BuZHpoLmNvbT4+DQpTdWJqZWN0OiBSZTog W0lkcl0gZHJhZnQtaWV0Zi1pZHItYmdwLWV4dGVuZGVkLW1lc3NhZ2VzLTEyIFdHIExDICg1LzI0 IHRvIDYvNykNCg0KSGkgQnJ1bm8sDQoNCg0KU3VwcG9zZSB0aGF0IEkgcmVjZWl2ZSBhbiBleHRl bmRlZCBCR1AgbWVzc2FnZSAoZS5nLiB1cGRhdGUpIHRoYXQgSSBjYW7igJl0IHJlbGF5DQoNCnRv IHNvbWUgcGVlcnMgYmVjYXVzZSB0aGV5IGRvbuKAmXQgc3VwcG9ydCBzdWNoIGV4dGVuc2lvbiwg d2hpbGUgSSDigJxzaG91bGTigJ0gaGF2ZQ0KDQpyZWxheWVkIGl0Lg0KDQrigItCR1AgZG9lcyBu b3QgInJlbGF5IiBtZXNzYWdlcyAuLiBkbyB5b3UgaGF2ZSBzb21lIG5ldyBCR1AgZHJhZnQgaW4g bWluZCB3aGljaCB3b3VsZCB3b3JrIGFzIEJHUCAicmVwZWF0ZXIiID8gV2hpbGUgSSByZWNhbGwg d2UgZGlzY3Vzc2VkIGl0IGluIHRoZSBwYXN0IHRoYXQgd29yayB3ZXJlIHByZXR0eSBtdWNoIGFi YW5kb25lZCA6KQ0KDQpCR1AgZ2VuZXJhdGVzIG1lc3NhZ2VzIGF0IGVhY2ggQkdQIHNwZWFrZXIg c28gdGhlIGFib3ZlIHNlZW1zIGxpa2Ugbm9uIGlzc3VlIHRvIG1lIGZvciB0aGlzIGRyYWZ0Lg0K DQpBIG5vbi1pc3N1ZSB1bmxlc3MgdGhlIHNpemUgb2YgYSBzaW5nbGUgTkxSSSBhbmQgaXRzIGF0 dHJpYnV0ZXMgZXhjZWVkcyA0Sy4NClRoYW5rcywNCkFjZWUNCg0KDQoNCuKAiw0K4oCLQmVzdCwN ClIuDQoNCkZvciB0aGUgZHJhZnQgaXRzZWxmOiBTdXBwb3J0IOKAi2Zyb20gbWUuDQoNCg0KDQo= --_000_D36B06A76257Daceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <4B5660129D818E42A82BCC889F57232B@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0K PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxp Z246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVIt TEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGlu OyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JE RVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJm b250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+SWRyICZsdDs8YSBocmVmPSJtYWlsdG86aWRy LWJvdW5jZXNAaWV0Zi5vcmciPmlkci1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxm IG9mIFJvYmVydCBSYXN6dWsgJmx0OzxhIGhyZWY9Im1haWx0bzpyb2JlcnRAcmFzenVrLm5ldCI+ cm9iZXJ0QHJhc3p1ay5uZXQ8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpi b2xkIj5EYXRlOiA8L3NwYW4+V2VkbmVzZGF5LCBNYXkgMjUsIDIwMTYgYXQgNjozNCBBTTxicj4N CjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPkJydW5vIERlY3JhZW5l ICZsdDs8YSBocmVmPSJtYWlsdG86YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbSI+YnJ1bm8uZGVj cmFlbmVAb3JhbmdlLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJv bGQiPkNjOiA8L3NwYW4+JnF1b3Q7S2V5dXIgUGF0ZWwgKGtleXVwYXRlKSZxdW90OyAmbHQ7PGEg aHJlZj0ibWFpbHRvOmtleXVwYXRlQGNpc2NvLmNvbSI+a2V5dXBhdGVAY2lzY28uY29tPC9hPiZn dDssIElEUiBMaXN0ICZsdDs8YSBocmVmPSJtYWlsdG86aWRyQGlldGYub3JnIj5pZHJAaWV0Zi5v cmc8L2E+Jmd0OywgU3VzYW4gSGFyZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpzaGFyZXNAbmR6aC5j b20iPnNoYXJlc0BuZHpoLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0 OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogW0lkcl0gZHJhZnQtaWV0Zi1pZHItYmdwLWV4dGVu ZGVkLW1lc3NhZ2VzLTEyIFdHIExDICg1LzI0IHRvIDYvNyk8YnI+DQo8L2Rpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tR VU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAg NTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2 IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNh LHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCkhpIEJydW5vLDwvZGl2Pg0KPGRpdiBjbGFz cz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5z LXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWls X2V4dHJhIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxibG9ja3F1b3RlIGNsYXNzPSJn bWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2Nj IHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBsYW5nPSJGUiIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+U3VwcG9zZSB0aGF0 IEkgcmVjZWl2ZSBhbiBleHRlbmRlZCBCR1AgbWVzc2FnZSAoZS5nLiB1cGRhdGUpIHRoYXQgSSBj YW7igJl0IHJlbGF5IDwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhl eDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgbGFu Zz0iRlIiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdj4NCjxwcmU+PHNwYW4gbGFu Zz0iRU4tVVMiPnRvIHNvbWUgcGVlcnMgYmVjYXVzZSB0aGV5IGRvbuKAmXQgc3VwcG9ydCBzdWNo IGV4dGVuc2lvbiwgd2hpbGUgSSDigJxzaG91bGTigJ0gaGF2ZSA8L3NwYW4+PC9wcmU+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3Rl IiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFk ZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGxhbmc9IkZSIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXY+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5yZWxheWVkIGl0LiA8L3NwYW4+PC9w cmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWws aGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCuKAi0JHUCBkb2VzIG5vdCAm cXVvdDtyZWxheSZxdW90OyBtZXNzYWdlcyAuLiBkbyB5b3UgaGF2ZSBzb21lIG5ldyBCR1AgZHJh ZnQgaW4gbWluZCB3aGljaCB3b3VsZCB3b3JrIGFzIEJHUCAmcXVvdDtyZXBlYXRlciZxdW90OyA/ IFdoaWxlIEkgcmVjYWxsIHdlIGRpc2N1c3NlZCBpdCBpbiB0aGUgcGFzdCB0aGF0IHdvcmsgd2Vy ZSBwcmV0dHkgbXVjaCBhYmFuZG9uZWQgOik8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1 bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNp emU6c21hbGwiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHls ZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxs Ij4NCkJHUCBnZW5lcmF0ZXMgbWVzc2FnZXMgYXQgZWFjaCBCR1Agc3BlYWtlciBzbyB0aGUgYWJv dmUgc2VlbXMgbGlrZSBub24gaXNzdWUgdG8gbWUgZm9yIHRoaXMgZHJhZnQuJm5ic3A7PC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L3NwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5BIG5vbi1pc3N1ZSB1bmxl c3MgdGhlIHNpemUgb2YgYSBzaW5nbGUgTkxSSSBhbmQgaXRzIGF0dHJpYnV0ZXMgZXhjZWVkcyA0 Sy4mbmJzcDs8L2Rpdj4NCjxkaXY+VGhhbmtzLDwvZGl2Pg0KPGRpdj5BY2VlJm5ic3A7PC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JD X0JPRFlfU0VDVElPTiI+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05f QkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6 MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+ DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8 ZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFs LGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQo8YnI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRp Y2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0K4oCLPC9kaXY+DQo8ZGl2IGNsYXNzPSJn bWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2Vy aWY7Zm9udC1zaXplOnNtYWxsIj4NCuKAi0Jlc3QsPGJyPg0KUi48L2Rpdj4NCjxkaXYgY2xhc3M9 ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1z ZXJpZjtmb250LXNpemU6c21hbGwiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9k ZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9u dC1zaXplOnNtYWxsIj4NCkZvciB0aGUgZHJhZnQgaXRzZWxmOiBTdXBwb3J0IOKAi2Zyb20gbWUu Jm5ic3A7PGJyPg0KPC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 PiZuYnNwOzwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D36B06A76257Daceeciscocom_-- From nobody Wed May 25 04:46:14 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F5512D95A for ; Wed, 25 May 2016 04:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ygqwT_d0mYv for ; Wed, 25 May 2016 04:46:10 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7478312DB08 for ; Wed, 25 May 2016 04:46:06 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id CEE3C2647B6; Wed, 25 May 2016 13:46:04 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.75]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 9558935C079; Wed, 25 May 2016 13:46:04 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe%19]) with mapi id 14.03.0294.000; Wed, 25 May 2016 13:46:04 +0200 From: To: Robert Raszuk Thread-Topic: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) Thread-Index: AQHRtnEWPZh8nSlbI0GrYMTETHfu5Z/JhpnA Date: Wed, 25 May 2016 11:46:04 +0000 Message-ID: <20520_1464176764_5745907C_20520_692_1_53C29892C857584299CBF5D05346208A0F8CD7B8@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> <13146_1464170675_574578B3_13146_4888_1_53C29892C857584299CBF5D05346208A0F8CD227@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A0F8CD7B8OPEXCLILM21corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.4.25.91516 Archived-At: Cc: "Keyur Patel \(keyupate\)" , "idr@ietf.org" , Susan Hares Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 11:46:13 -0000 --_000_53C29892C857584299CBF5D05346208A0F8CD7B8OPEXCLILM21corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KDQoNCkZyb206IFJvYmVydCBSYXN6dWsNClNlbnQ6IFdlZG5lc2RheSwgTWF5 IDI1LCAyMDE2IDEyOjM1IFBNDQoNCg0KSGkgQnJ1bm8sDQoNCg0KU3VwcG9zZSB0aGF0IEkgcmVj ZWl2ZSBhbiBleHRlbmRlZCBCR1AgbWVzc2FnZSAoZS5nLiB1cGRhdGUpIHRoYXQgSSBjYW7igJl0 IHJlbGF5DQoNCnRvIHNvbWUgcGVlcnMgYmVjYXVzZSB0aGV5IGRvbuKAmXQgc3VwcG9ydCBzdWNo IGV4dGVuc2lvbiwgd2hpbGUgSSDigJxzaG91bGTigJ0gaGF2ZQ0KDQpyZWxheWVkIGl0Lg0KDQri gItCR1AgZG9lcyBub3QgInJlbGF5IiBtZXNzYWdlcyAuLg0KDQpNeSBtaXN0YWtlLiBXb3VsZCDi gJxwcm9wYWdhdGXigJ0gb3Ig4oCccmUtYWR2ZXJ0aXNl4oCdIG9yIOKAnHJlZmxlY3TigJ0gYmUg YSBiZXR0ZXIgdGVybSBmb3IgeW91Pw0KDQpkbyB5b3UgaGF2ZSBzb21lIG5ldyBCR1AgZHJhZnQg aW4gbWluZCB3aGljaCB3b3VsZCB3b3JrIGFzIEJHUCAicmVwZWF0ZXIiID8NCg0KTGV04oCZcyBj b25zaWRlciBSRkMgNDQ1NiAoQkdQIFJvdXRlIFJlZmxlY3Rpb24pLiBJZiBzb21lIGlCR1AgY2xp ZW50cyBkbyBub3QgYWR2ZXJ0aXNlIHRoaXMgYmVoYXZpb3IsIHRoZXkgd2lsbCBub3QgcmVjZWl2 ZSB0aGUgaW50ZXJuYWwgcm91dGVzIGFkdmVydGlzZWQgYnkgdGhlIGlCR1AgY2xpZW50cyBzZW5k aW5nIGV4dGVuZGVkIG1lc3NhZ2VzLiBIZW5jZSwgYWxsIGlCR1Agcm91dGVycyBkbyBub3QgaGF2 ZSBhIGNvbnNpc3RlbnQga25vd2xlZGdlIG9mIHRoZSBpbnRlcm5hbCByb3V0ZXJzLg0KDQotLUJy dW5vDQoNCldoaWxlIEkgcmVjYWxsIHdlIGRpc2N1c3NlZCBpdCBpbiB0aGUgcGFzdCB0aGF0IHdv cmsgd2VyZSBwcmV0dHkgbXVjaCBhYmFuZG9uZWQgOikNCg0KQkdQIGdlbmVyYXRlcyBtZXNzYWdl cyBhdCBlYWNoIEJHUCBzcGVha2VyIHNvIHRoZSBhYm92ZSBzZWVtcyBsaWtlIG5vbiBpc3N1ZSB0 byBtZSBmb3IgdGhpcyBkcmFmdC4NCg0K4oCLDQrigItCZXN0LA0KUi4NCg0KRm9yIHRoZSBkcmFm dCBpdHNlbGY6IFN1cHBvcnQg4oCLZnJvbSBtZS4NCg0KDQoNCgpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdl IGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMg Y29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0 cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZv dXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIK YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRl cy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJh dGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBh IGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFu ZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQg aW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90 IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBl bWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0 aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4K Cg== --_000_53C29892C857584299CBF5D05346208A0F8CD7B8OPEXCLILM21corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0w6kgSFRNTCBD YXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLlByZm9ybWF0SFRNTENh cg0KCXttc28tc3R5bGUtbmFtZToiUHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlByw6lmb3JtYXTDqSBIVE1MIjsNCglmb250 LWZhbWlseTpDb25zb2xhczsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpGUjt9DQpzcGFuLkVtYWls U3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3 MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJGUiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIFJvYmVydCw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUm9iZXJ0IFJhc3p1azxi cj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE1heSAyNSwgMjAxNiAxMjozNSBQTTxicj4NCjxi cj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SGkgQnJ1bm8sPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5T dXBwb3NlIHRoYXQgSSByZWNlaXZlIGFuIGV4dGVuZGVkIEJHUCBtZXNzYWdlIChlLmcuIHVwZGF0 ZSkgdGhhdCBJIGNhbuKAmXQgcmVsYXkgPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHByZT48 c3BhbiBsYW5nPSJFTi1VUyI+dG8gc29tZSBwZWVycyBiZWNhdXNlIHRoZXkgZG9u4oCZdCBzdXBw b3J0IHN1Y2ggZXh0ZW5zaW9uLCB3aGlsZSBJIOKAnHNob3VsZOKAnSBoYXZlIDwvc3Bhbj48bzpw PjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+ DQo8ZGl2Pg0KPGRpdj4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPnJlbGF5ZWQgaXQuIDwvc3Bh bj48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+4oCLQkdQIGRvZXMgbm90 ICZxdW90O3JlbGF5JnF1b3Q7IG1lc3NhZ2VzIC4uPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NeSBtaXN0YWtlLiBXb3VsZCDigJxwcm9w YWdhdGXigJ0gb3Ig4oCccmUtYWR2ZXJ0aXNl4oCdIG9yIOKAnHJlZmxlY3TigJ0gYmUgYSBiZXR0 ZXIgdGVybSBmb3IgeW91PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5kbyB5b3UgaGF2ZSBzb21lIG5ldyBCR1AgZHJhZnQgaW4gbWlu ZCB3aGljaCB3b3VsZCB3b3JrIGFzIEJHUCAmcXVvdDtyZXBlYXRlciZxdW90OyA/PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5MZXTigJlz IGNvbnNpZGVyIFJGQyA0NDU2IChCR1AgUm91dGUgUmVmbGVjdGlvbikuIElmIHNvbWUgaUJHUCBj bGllbnRzIGRvIG5vdCBhZHZlcnRpc2UgdGhpcyBiZWhhdmlvciwgdGhleSB3aWxsIG5vdCByZWNl aXZlIHRoZSBpbnRlcm5hbCByb3V0ZXMNCiBhZHZlcnRpc2VkIGJ5IHRoZSBpQkdQIGNsaWVudHMg c2VuZGluZyBleHRlbmRlZCBtZXNzYWdlcy4gSGVuY2UsIGFsbCBpQkdQIHJvdXRlcnMgZG8gbm90 IGhhdmUgYSBjb25zaXN0ZW50IGtub3dsZWRnZSBvZiB0aGUgaW50ZXJuYWwgcm91dGVycy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LS1CcnVubzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5XaGlsZSBJIHJlY2Fs bCB3ZSBkaXNjdXNzZWQgaXQgaW4gdGhlIHBhc3QgdGhhdCB3b3JrIHdlcmUgcHJldHR5IG11Y2gg YWJhbmRvbmVkIDopPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ QkdQIGdlbmVyYXRlcyBtZXNzYWdlcyBhdCBlYWNoIEJHUCBzcGVha2VyIHNvIHRoZSBhYm92ZSBz ZWVtcyBsaWtlIG5vbiBpc3N1ZSB0byBtZSBmb3IgdGhpcyBkcmFmdC4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPuKAizxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7igItCZXN0LDxicj4NClIuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gb3IgdGhlIGRyYWZ0IGl0c2VsZjogU3VwcG9y dCDigItmcm9tIG1lLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPFBSRT5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdl IGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMg Y29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0 cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZv dXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIK YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRl cy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJh dGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBh IGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFu ZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQg aW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90 IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBl bWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0 aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4K PC9QUkU+PC9ib2R5Pg0KPC9odG1sPg0K --_000_53C29892C857584299CBF5D05346208A0F8CD7B8OPEXCLILM21corp_-- From nobody Wed May 25 04:50:18 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90B9512B009 for ; Wed, 25 May 2016 04:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8aNIem-9E87 for ; Wed, 25 May 2016 04:50:14 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7255E12B020 for ; Wed, 25 May 2016 04:50:13 -0700 (PDT) Received: by mail-lb0-x233.google.com with SMTP id sh2so14565037lbb.1 for ; Wed, 25 May 2016 04:50:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=BqGglZ6VnWrxYtji2mOZ/LK109AxnUnKOxuJlhiDimM=; b=xTUAeVHs2UDlVyO4kvuseI/Sk6WXXSwBKaNCECcN9CpJdvdwI47lXRk6VjPSs33M1x nA9ytwfa2Xlt5ufI/3lcC8+KE9zRd1StytYEkJ553nbjYYLed0jkg6b30OUKgOr4bTvP ZYQI4GgSWFBks4Jha0/1Mhd8kKfXNrcJPSL6bALhdexjWi4BDhVcWTErKrXZLsfo4B3U t1Q+82wRKlxNxcYAIMpB5yx8WX0cf9xctfp7YFgMkKP7WdNf09iv3b5y64uMZAg4l1JV sisWo1X/UzJOMQkNELaxvGIShtToYFPajo9iBcyUxeZl8pKySKvcpIpVsa3K16j/lXMc sQAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=BqGglZ6VnWrxYtji2mOZ/LK109AxnUnKOxuJlhiDimM=; b=Pi/tFz0pP248DgI6EVCcoH3ZVsP0AJhT1wNditmYRSDFqi42X3CJav15vpmWvIPxeN gz/lFRa6y8mLxgi8PjzunGXzart5+gGxMabnzNoJpq7ZxG2vGStl+fl9hVVB8nJh2adU L81Z67t0BGqVgc2O9iKenLFdNpvIc6yRwN7pXB8P71dailYUqhwwFPlQdyyBwiEi4QHo 1Auwrjy2lQqWU0n+oo9Xk2RC8ZLoNlFXx8PBztOFMAA4ysnZnmUgVCjQZNZr0SjT5lCg vqsgNI0b7lThgESTaGrQd/BcF9DuivkBbtRiXz6xerikWPHvrD8hMeiQqmbHipYIrYOH xtEQ== X-Gm-Message-State: ALyK8tLNMVex3URyjZDilFJTc2JXue0ol+66du0oLBB5TZgIUkp++7FtvQMwtChlANr3xlkbaem1IFMtS12iHw== MIME-Version: 1.0 X-Received: by 10.112.12.198 with SMTP id a6mr880462lbc.84.1464177011598; Wed, 25 May 2016 04:50:11 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.25.134.196 with HTTP; Wed, 25 May 2016 04:50:11 -0700 (PDT) In-Reply-To: References: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> <13146_1464170675_574578B3_13146_4888_1_53C29892C857584299CBF5D05346208A0F8CD227@OPEXCLILM21.corporate.adroot.infra.ftgroup> Date: Wed, 25 May 2016 13:50:11 +0200 X-Google-Sender-Auth: U3wk6duT7J3i-1JuYqsukTiHIoo Message-ID: From: Robert Raszuk To: "Acee Lindem (acee)" Content-Type: multipart/alternative; boundary=001a11c3b2b4aa2f750533a946ef Archived-At: Cc: "Keyur Patel \(keyupate\)" , Bruno Decraene , Susan Hares , "idr@ietf.org" Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 11:50:16 -0000 --001a11c3b2b4aa2f750533a946ef Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi AC, Yes indeed - you are right - I was a bit hit with "relay" term :). And since this entire work started with the assumption that packing per NLRI will be broken anyway one could expect this to be always the case. So it does look like a bit of show stopper to me unless we enforce that if there is at least one BGP peer on given BGP speaker not supporting 64K all sessions will get reset to 4K max. Ugly but not sure what other options can address it. Perhaps authors will come up with better one. Thx, R. On Wed, May 25, 2016 at 1:41 PM, Acee Lindem (acee) wrote: > > > From: Idr on behalf of Robert Raszuk < > robert@raszuk.net> > Date: Wednesday, May 25, 2016 at 6:34 AM > To: Bruno Decraene > Cc: "Keyur Patel (keyupate)" , IDR List , > Susan Hares > Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to > 6/7) > > Hi Bruno, > > Suppose that I receive an extended BGP message (e.g. update) that I can= =E2=80=99t relay >> >> to some peers because they don=E2=80=99t support such extension, while I= =E2=80=9Cshould=E2=80=9D have >> >> relayed it. >> >> > =E2=80=8BBGP does not "relay" messages .. do you have some new BGP draft = in mind > which would work as BGP "repeater" ? While I recall we discussed it in th= e > past that work were pretty much abandoned :) > > BGP generates messages at each BGP speaker so the above seems like non > issue to me for this draft. > > > A non-issue unless the size of a single NLRI and its attributes exceeds > 4K. > Thanks, > Acee > > > > =E2=80=8B > =E2=80=8BBest, > R. > > For the draft itself: Support =E2=80=8Bfrom me. > > > > > --001a11c3b2b4aa2f750533a946ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi AC,

Yes indeed - you are right - I was a bit hit with &quo= t;relay" term :).=C2=A0

And since this entire work started with the assumption that packin= g per NLRI will be broken anyway one could expect this to be always the cas= e.=C2=A0

So it does lo= ok like a bit of show stopper to me unless we enforce that if there is at l= east one BGP peer on given BGP speaker not supporting 64K all sessions will= get reset to 4K max. Ugly but not sure what other options can address it. = Perhaps authors will come up with better one.=C2=A0

Thx,
R.



On Wed, May 25, 2016 at 1:41 PM, Ac= ee Lindem (acee) <acee@cisco.com> wrote:


From: Idr <idr-bounces@ietf.org> on behalf= of Robert Raszuk <robert@raszuk.net>
Date: Wednesday, May 25, 2016 at 6:= 34 AM
To: Bruno Decraene <bruno.decraene@orange.co= m>
Cc: "Keyur Patel (keyupate)&qu= ot; <keyupate@ci= sco.com>, IDR List <idr@ietf.org>, Susan Hares <shares@ndzh.com>
Subject: Re: [Idr] draft-ietf-idr-b= gp-extended-messages-12 WG LC (5/24 to 6/7)

Hi Bruno,

Suppose that I receive an extended BGP message (e=
.g. update) that I can=E2=80=99t relay 
to some peers because they don=E2=80=99t support =
such extension, while I =E2=80=9Cshould=E2=80=9D have 
relayed it.

=E2=80=8BBGP does not "relay" messages .. do you have some new BG= P draft in mind which would work as BGP "repeater" ? While I reca= ll we discussed it in the past that work were pretty much abandoned :)

BGP generates messages at each BGP speaker so the above seems like non issu= e to me for this draft.=C2=A0

A non-issue unless the size of a single NLRI and its attributes exceed= s 4K.=C2=A0
Thanks,
Acee=C2=A0



=E2=80=8B
=E2=80=8BBest,
R.

For the draft itself: Support =E2=80=8Bfrom me.=C2=A0


=C2=A0

--001a11c3b2b4aa2f750533a946ef-- From nobody Wed May 25 04:53:59 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49A9912DB00 for ; Wed, 25 May 2016 04:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ob5IOrys-pgR for ; Wed, 25 May 2016 04:53:56 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C1DA12DAF3 for ; Wed, 25 May 2016 04:53:55 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id k98so17140719lfi.1 for ; Wed, 25 May 2016 04:53:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=bbRP/4zLe03gutUnZJCfN9kJUT07z9tEpwBL69tAHuA=; b=PgnCyuMhjWPahh2Rsb9Yk9FyetppskXZMshV1z8Me0PY4URj6DQ1gw6W2CbIzb7+uy pL7ylRDOJ04V5iwyx3CX1I1y6HzJecejykRN2p9Cn16skyh51q+BMVl6jBCG7HNTCtsB La9MpC3ONhKNsPnHNi0jcSSiCj18sPdpFIh5x8P3xLihnzqiFGb3zYw2pEq7FUzNmJ6K ToAd3tGUcBwl0QTfOQFKx7EN7sjt7qaDf55hLfx4/7GSHaEVrLk/SRKXr9u4Uu4snMvu kMplGqD74ui3lvPTtqtg8KOrPe4sfFVEQbHskui1oJlKylp9GOPbW5Qnsy5UxYN+0sTX 9Ehg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=bbRP/4zLe03gutUnZJCfN9kJUT07z9tEpwBL69tAHuA=; b=cqHKQqV26cHyk0L80GK0C5s5MjNXlI/QoANmIv1RdPIG/23SdKObpWGfHSz1Iqjvw3 6Gq888IpV54QioVXmChSqKOlxfDvlBrFIbBuAV1ND2oXZHgK3T+SPKWZI+oKI6q+NGFA M96IQymQhJH/KukkzDc5yQacyoYFC6U4NDHVJPJTze3k+mNZ2/3fhQh/u/pRvrzSfjdj N4kFbRM/TxvlBnq5VL8GoIXp3rO6rndwIZ7CdcSpuqYMUjRLnpE8KdDCpuP15IeALJDr YH6xtnCH+O+qvAJbOxETw/vAQxlWiWkkTS4wxCeXCtaIURZaBYov+OuKtRV30FQgpan3 ZIuQ== X-Gm-Message-State: ALyK8tLnyMGfEqRPCDMfkd9I8WnAs7Vcj3GMyoNuOukZgBbRXIZr1yaCQCks/H7m5W+SNmGt4gMlbhfT/CJf5Q== MIME-Version: 1.0 X-Received: by 10.25.16.219 with SMTP id 88mr744591lfq.21.1464177233687; Wed, 25 May 2016 04:53:53 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.25.134.196 with HTTP; Wed, 25 May 2016 04:53:53 -0700 (PDT) In-Reply-To: <20520_1464176764_5745907C_20520_692_1_53C29892C857584299CBF5D05346208A0F8CD7B8@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> <13146_1464170675_574578B3_13146_4888_1_53C29892C857584299CBF5D05346208A0F8CD227@OPEXCLILM21.corporate.adroot.infra.ftgroup> <20520_1464176764_5745907C_20520_692_1_53C29892C857584299CBF5D05346208A0F8CD7B8@OPEXCLILM21.corporate.adroot.infra.ftgroup> Date: Wed, 25 May 2016 13:53:53 +0200 X-Google-Sender-Auth: Rj_zVCIPyQd6SZFKED_SalgJxV8 Message-ID: From: Robert Raszuk To: Bruno Decraene Content-Type: multipart/alternative; boundary=001a11402d9ce6fd2f0533a95340 Archived-At: Cc: "Keyur Patel \(keyupate\)" , "idr@ietf.org" , Susan Hares Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 11:53:58 -0000 --001a11402d9ce6fd2f0533a95340 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > > =E2=80=8BBGP does not "relay" messages .. > > > > My mistake. Would =E2=80=9Cpropagate=E2=80=9D or =E2=80=9Cre-advertise=E2= =80=9D or =E2=80=9Creflect=E2=80=9D be a better > term for you? > =E2=80=8BYup.=E2=80=8B > > do you have some new BGP draft in mind which would work as BGP "repeater"= ? > > > > Let=E2=80=99s consider RFC 4456 (BGP Route Reflection). If some iBGP clie= nts do > not advertise this behavior, they will not receive the internal routes > advertised by the iBGP clients sending extended messages. Hence, all iBGP > routers do not have a consistent knowledge of the internal routers. > =E2=80=8BWell that would be drastic. Perhaps lighter option would be to dro= p largest optional attributes, but I am not sure if I like such swiss cheese solution. Yes another option would be to have this knobbed for few years and enable only by NOC when all routers support it. =E2=80=8B Automatic incremental deployment =E2=80=8Bis bit hard in network wide enhan= cements :)) Thx, r. --001a11402d9ce6fd2f0533a95340 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=


= =E2=80=8BBGP does not "relay" messages ..

=C2=A0

My = mistake. Would =E2=80=9Cpropagate=E2=80=9D or =E2=80=9Cre-advertise=E2=80= =9D or =E2=80=9Creflect=E2=80=9D be a better term for you?

=

=
=E2=80=8BYup.=E2=80=8B


=C2= =A0

do you have some new BGP draft in mind whic= h would work as BGP "repeater" ?=

=C2=A0

Let= =E2=80=99s consider RFC 4456 (BGP Route Reflection). If some iBGP clients d= o not advertise this behavior, they will not receive the internal routes advertised by the iBGP clients sending extended messages. Hence, all iBGP = routers do not have a consistent knowledge of the internal routers.<= /p>



=E2=80=8BWell that would be dras= tic. Perhaps lighter option would be to drop largest optional attributes, b= ut I am not sure if I like such swiss cheese solution.=C2=A0

Yes another option would be to have = this knobbed for few years and enable only by NOC when all routers support = it. =E2=80=8B

Automatic incremental = deployment =E2=80=8Bis bit hard in network wide enhancements :))

Thx,
r.<= /div>


--001a11402d9ce6fd2f0533a95340-- From nobody Wed May 25 07:23:10 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F22912D70A; Wed, 25 May 2016 07:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id foHQkfFLxUjH; Wed, 25 May 2016 07:22:56 -0700 (PDT) Received: from seele.lamehost.it (seele.lamehost.it [80.76.80.23]) by ietfa.amsl.com (Postfix) with ESMTP id C10B112D67C; Wed, 25 May 2016 07:22:47 -0700 (PDT) Received: by seele.lamehost.it (Postfix, from userid 33) id 5412674401; Wed, 25 May 2016 16:22:44 +0200 (CEST) To: ietf@ietf.org X-PHP-Originating-Script: 0:rcube.php MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 25 May 2016 16:22:44 +0200 From: Marco Marzetti In-Reply-To: <20160524224341.14017.96672.idtracker@ietfa.amsl.com> References: <20160524224341.14017.96672.idtracker@ietfa.amsl.com> Message-ID: <6b69a7e81790d6bae23d39ea44ccb01f@lamehost.it> X-Sender: marco@lamehost.it User-Agent: Roundcube Webmail/1.1.5 Archived-At: Cc: Idr@ietf.org Subject: Re: [Idr] Last Call: (Internet Exchange BGP Route Server) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 14:23:05 -0000 On 2016-05-25 00:43, The IESG wrote: > The IESG has received a request from the Inter-Domain Routing WG (idr) > to > consider the following document: > - 'Internet Exchange BGP Route Server' > as Proposed Standard > > 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 2016-06-07. 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 > > > This document outlines a specification for multilateral > interconnections at Internet exchange points (IXPs). Multilateral > interconnection is a method of exchanging routing information > between > three or more external BGP speakers using a single intermediate > broker system, referred to as a route server. Route servers are > typically used on shared access media networks, such as Internet > exchange points (IXPs), to facilitate simplified interconnection > between multiple Internet routers. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-idr-ix-bgp-route-server/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-idr-ix-bgp-route-server/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr All, Beside i agree on the most part of this draft i would like to underline how bullet 2.2.2 breaks the the nature of BGP itself. The exact part i am referring to is: """ As a route server does not participate in the process of forwarding data between client routers, and because modification of the AS_PATH attribute could affect route server client BGP Decision Process, the route server SHOULD NOT prepend its own AS number to the AS_PATH segment nor modify the AS_PATH segment in any other way. """ I firmly think that it really has to state "MUST NOT" instead of "SHOULD NOT". From a route-server client point of view that breaks the natural BGP best selection process and forces you to purely rely on LOCAL_PREFERENCE which in turns breaks your traffic engineering because it forces you to prefer/not-prefer the prefixes learned over the route server in place of those learned, for instance, over a private session or another IXP. Regards -- Marco From nobody Wed May 25 07:29:29 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1301812D71E for ; Wed, 25 May 2016 07:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljRgXyAH4cRu for ; Wed, 25 May 2016 07:29:22 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C81512D71C for ; Wed, 25 May 2016 07:29:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16341; q=dns/txt; s=iport; t=1464186561; x=1465396161; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=fIrOqL00J2rucEQBx1dWc0eLTBVmKpDwbpZOVI+BgR0=; b=VSaOV/ckv6EDwM1JoQdpF/UawXgGVEnF+tGnRPy09iauG0XpQQZn09l4 Kl+QlrVAWmFa0K9/9EkIG3F8b8yWrFlA9sjRMrZh8NHmiVWDIButtEXdw Iiufd7yLPG5RVWVEy24GbD9j/ribyZGxsTgz/JdftUcrhqVlPREWLGP0m M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BBAgBRtUVX/5RdJa1cgmxLgVMGrgKGd?= =?us-ascii?q?oR5AQ2Bd4YRAhyBIjgUAQEBAQEBAWUnhEMBAQEEI1YQAgEGAhEDAQIoAwICAh8?= =?us-ascii?q?RFAkIAgQOBYgVAxeVL50djT8NhCkBAQEBAQEBAwEBAQEBAQEBAQEdiXCBA4JDg?= =?us-ascii?q?hyCYYJZBZM3hE0zAYwmgXmBaY0zhjOBMYdnAR4BAUKDbW6JCH8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,364,1459814400"; d="scan'208,217";a="276258508" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 May 2016 14:29:20 +0000 Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u4PETJKL021857 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 25 May 2016 14:29:19 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 25 May 2016 10:29:18 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Wed, 25 May 2016 10:29:18 -0400 From: "Acee Lindem (acee)" To: Robert Raszuk Thread-Topic: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) Thread-Index: AQHRtnpy331Rj2Oog02xXFi+9aCxRZ/JzUiA///pZAA= Date: Wed, 25 May 2016 14:29:18 +0000 Message-ID: References: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> <13146_1464170675_574578B3_13146_4888_1_53C29892C857584299CBF5D05346208A0F8CD227@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: multipart/alternative; boundary="_000_D36B2E2D625D3aceeciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Keyur Patel \(keyupate\)" , Bruno Decraene , Susan Hares , "idr@ietf.org" Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 14:29:26 -0000 --_000_D36B2E2D625D3aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KDQpGcm9tOiA8cnJhc3p1a0BnbWFpbC5jb208bWFpbHRvOnJyYXN6dWtAZ21h aWwuY29tPj4gb24gYmVoYWxmIG9mIFJvYmVydCBSYXN6dWsgPHJvYmVydEByYXN6dWsubmV0PG1h aWx0bzpyb2JlcnRAcmFzenVrLm5ldD4+DQpEYXRlOiBXZWRuZXNkYXksIE1heSAyNSwgMjAxNiBh dCA3OjUwIEFNDQpUbzogQWNlZSBMaW5kZW0gPGFjZWVAY2lzY28uY29tPG1haWx0bzphY2VlQGNp c2NvLmNvbT4+DQpDYzogQnJ1bm8gRGVjcmFlbmUgPGJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208 bWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20+PiwgIktleXVyIFBhdGVsIChrZXl1cGF0 ZSkiIDxrZXl1cGF0ZUBjaXNjby5jb208bWFpbHRvOmtleXVwYXRlQGNpc2NvLmNvbT4+LCBJRFIg TGlzdCA8aWRyQGlldGYub3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+PiwgU3VzYW4gSGFyZXMgPHNo YXJlc0BuZHpoLmNvbTxtYWlsdG86c2hhcmVzQG5kemguY29tPj4NClN1YmplY3Q6IFJlOiBbSWRy XSBkcmFmdC1pZXRmLWlkci1iZ3AtZXh0ZW5kZWQtbWVzc2FnZXMtMTIgV0cgTEMgKDUvMjQgdG8g Ni83KQ0KDQpIaSBBQywNCg0KWWVzIGluZGVlZCAtIHlvdSBhcmUgcmlnaHQgLSBJIHdhcyBhIGJp dCBoaXQgd2l0aCAicmVsYXkiIHRlcm0gOikuDQoNCkFuZCBzaW5jZSB0aGlzIGVudGlyZSB3b3Jr IHN0YXJ0ZWQgd2l0aCB0aGUgYXNzdW1wdGlvbiB0aGF0IHBhY2tpbmcgcGVyIE5MUkkgd2lsbCBi ZSBicm9rZW4gYW55d2F5IG9uZSBjb3VsZCBleHBlY3QgdGhpcyB0byBiZSBhbHdheXMgdGhlIGNh c2UuDQoNClNvIGl0IGRvZXMgbG9vayBsaWtlIGEgYml0IG9mIHNob3cgc3RvcHBlciB0byBtZSB1 bmxlc3Mgd2UgZW5mb3JjZSB0aGF0IGlmIHRoZXJlIGlzIGF0IGxlYXN0IG9uZSBCR1AgcGVlciBv biBnaXZlbiBCR1Agc3BlYWtlciBub3Qgc3VwcG9ydGluZyA2NEsgYWxsIHNlc3Npb25zIHdpbGwg Z2V0IHJlc2V0IHRvIDRLIG1heC4gVWdseSBidXQgbm90IHN1cmUgd2hhdCBvdGhlciBvcHRpb25z IGNhbiBhZGRyZXNzIGl0LiBQZXJoYXBzIGF1dGhvcnMgd2lsbCBjb21lIHVwIHdpdGggYmV0dGVy IG9uZS4NCg0KU2luY2UgdGhpcyBpcyBsaWtlbHkgdG8gYmUgYW4gZXh0cmVtZWx5IHJhcmUgb2Nj dXJyZW5jZSwgSeKAmWQgc2ltcGx5IG5vdCBhZHZlcnRpc2UgdGhlIE5MUkkgdG8gYSBwZWVyIG5v dCBzdXBwb3J0aW5nIGV4dGVuZGVkIG1lc3NhZ2VzIGFuZCBsb2cgdGhlIGVycm9yLg0KDQpBZGRp dGlvbmFsbHksIHdlIGNvdWxkIGRpc2NvdXJhZ2UgdGhlIGdlbmVyYXRpb24gb2YgYSBzaW5nbGUg TkxSSSBleGNlZWRpbmcgNEsuDQoNClRoYW5rcywNCkFjZWUNCg0KDQoNClRoeCwNClIuDQoNCg0K DQpPbiBXZWQsIE1heSAyNSwgMjAxNiBhdCAxOjQxIFBNLCBBY2VlIExpbmRlbSAoYWNlZSkgPGFj ZWVAY2lzY28uY29tPG1haWx0bzphY2VlQGNpc2NvLmNvbT4+IHdyb3RlOg0KDQoNCkZyb206IElk ciA8aWRyLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnPj4gb24g YmVoYWxmIG9mIFJvYmVydCBSYXN6dWsgPHJvYmVydEByYXN6dWsubmV0PG1haWx0bzpyb2JlcnRA cmFzenVrLm5ldD4+DQpEYXRlOiBXZWRuZXNkYXksIE1heSAyNSwgMjAxNiBhdCA2OjM0IEFNDQpU bzogQnJ1bm8gRGVjcmFlbmUgPGJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208bWFpbHRvOmJydW5v LmRlY3JhZW5lQG9yYW5nZS5jb20+Pg0KQ2M6ICJLZXl1ciBQYXRlbCAoa2V5dXBhdGUpIiA8a2V5 dXBhdGVAY2lzY28uY29tPG1haWx0bzprZXl1cGF0ZUBjaXNjby5jb20+PiwgSURSIExpc3QgPGlk ckBpZXRmLm9yZzxtYWlsdG86aWRyQGlldGYub3JnPj4sIFN1c2FuIEhhcmVzIDxzaGFyZXNAbmR6 aC5jb208bWFpbHRvOnNoYXJlc0BuZHpoLmNvbT4+DQpTdWJqZWN0OiBSZTogW0lkcl0gZHJhZnQt aWV0Zi1pZHItYmdwLWV4dGVuZGVkLW1lc3NhZ2VzLTEyIFdHIExDICg1LzI0IHRvIDYvNykNCg0K SGkgQnJ1bm8sDQoNCg0KU3VwcG9zZSB0aGF0IEkgcmVjZWl2ZSBhbiBleHRlbmRlZCBCR1AgbWVz c2FnZSAoZS5nLiB1cGRhdGUpIHRoYXQgSSBjYW7igJl0IHJlbGF5DQoNCnRvIHNvbWUgcGVlcnMg YmVjYXVzZSB0aGV5IGRvbuKAmXQgc3VwcG9ydCBzdWNoIGV4dGVuc2lvbiwgd2hpbGUgSSDigJxz aG91bGTigJ0gaGF2ZQ0KDQpyZWxheWVkIGl0Lg0KDQrigItCR1AgZG9lcyBub3QgInJlbGF5IiBt ZXNzYWdlcyAuLiBkbyB5b3UgaGF2ZSBzb21lIG5ldyBCR1AgZHJhZnQgaW4gbWluZCB3aGljaCB3 b3VsZCB3b3JrIGFzIEJHUCAicmVwZWF0ZXIiID8gV2hpbGUgSSByZWNhbGwgd2UgZGlzY3Vzc2Vk IGl0IGluIHRoZSBwYXN0IHRoYXQgd29yayB3ZXJlIHByZXR0eSBtdWNoIGFiYW5kb25lZCA6KQ0K DQpCR1AgZ2VuZXJhdGVzIG1lc3NhZ2VzIGF0IGVhY2ggQkdQIHNwZWFrZXIgc28gdGhlIGFib3Zl IHNlZW1zIGxpa2Ugbm9uIGlzc3VlIHRvIG1lIGZvciB0aGlzIGRyYWZ0Lg0KDQpBIG5vbi1pc3N1 ZSB1bmxlc3MgdGhlIHNpemUgb2YgYSBzaW5nbGUgTkxSSSBhbmQgaXRzIGF0dHJpYnV0ZXMgZXhj ZWVkcyA0Sy4NClRoYW5rcywNCkFjZWUNCg0KDQoNCuKAiw0K4oCLQmVzdCwNClIuDQoNCkZvciB0 aGUgZHJhZnQgaXRzZWxmOiBTdXBwb3J0IOKAi2Zyb20gbWUuDQoNCg0KDQoNCg== --_000_D36B2E2D625D3aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <30AFE8236499124DA5310D27112C5EA7@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSBSb2JlcnQs Jm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9T RUNUSU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0 OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9u ZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5H LUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBz b2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3Bh biBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPiZsdDs8YSBocmVmPSJtYWls dG86cnJhc3p1a0BnbWFpbC5jb20iPnJyYXN6dWtAZ21haWwuY29tPC9hPiZndDsgb24gYmVoYWxm IG9mIFJvYmVydCBSYXN6dWsgJmx0OzxhIGhyZWY9Im1haWx0bzpyb2JlcnRAcmFzenVrLm5ldCI+ cm9iZXJ0QHJhc3p1ay5uZXQ8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpi b2xkIj5EYXRlOiA8L3NwYW4+V2VkbmVzZGF5LCBNYXkgMjUsIDIwMTYgYXQgNzo1MCBBTTxicj4N CjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPkFjZWUgTGluZGVtICZs dDs8YSBocmVmPSJtYWlsdG86YWNlZUBjaXNjby5jb20iPmFjZWVAY2lzY28uY29tPC9hPiZndDs8 YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj5CcnVubyBEZWNy YWVuZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20iPmJydW5v LmRlY3JhZW5lQG9yYW5nZS5jb208L2E+Jmd0OywgJnF1b3Q7S2V5dXIgUGF0ZWwgKGtleXVwYXRl KSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtleXVwYXRlQGNpc2NvLmNvbSI+a2V5dXBhdGVA Y2lzY28uY29tPC9hPiZndDssIElEUiBMaXN0ICZsdDs8YSBocmVmPSJtYWlsdG86aWRyQGlldGYu b3JnIj5pZHJAaWV0Zi5vcmc8L2E+Jmd0OywNCiBTdXNhbiBIYXJlcyAmbHQ7PGEgaHJlZj0ibWFp bHRvOnNoYXJlc0BuZHpoLmNvbSI+c2hhcmVzQG5kemguY29tPC9hPiZndDs8YnI+DQo8c3BhbiBz dHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJlOiBbSWRyXSBkcmFmdC1p ZXRmLWlkci1iZ3AtZXh0ZW5kZWQtbWVzc2FnZXMtMTIgV0cgTEMgKDUvMjQgdG8gNi83KTxicj4N CjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19B VFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xp ZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 IGRpcj0ibHRyIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWls eTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KSGkgQUMsPC9k aXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWws aGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCjxicj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGlj YSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQpZZXMgaW5kZWVkIC0geW91IGFyZSByaWdo dCAtIEkgd2FzIGEgYml0IGhpdCB3aXRoICZxdW90O3JlbGF5JnF1b3Q7IHRlcm0gOikuJm5ic3A7 PC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJp YWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCjxicj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZl dGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQpBbmQgc2luY2UgdGhpcyBlbnRpcmUg d29yayBzdGFydGVkIHdpdGggdGhlIGFzc3VtcHRpb24gdGhhdCBwYWNraW5nIHBlciBOTFJJIHdp bGwgYmUgYnJva2VuIGFueXdheSBvbmUgY291bGQgZXhwZWN0IHRoaXMgdG8gYmUgYWx3YXlzIHRo ZSBjYXNlLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZv bnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQo8 YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWls eTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KU28gaXQgZG9l cyBsb29rIGxpa2UgYSBiaXQgb2Ygc2hvdyBzdG9wcGVyIHRvIG1lIHVubGVzcyB3ZSBlbmZvcmNl IHRoYXQgaWYgdGhlcmUgaXMgYXQgbGVhc3Qgb25lIEJHUCBwZWVyIG9uIGdpdmVuIEJHUCBzcGVh a2VyIG5vdCBzdXBwb3J0aW5nIDY0SyBhbGwgc2Vzc2lvbnMgd2lsbCBnZXQgcmVzZXQgdG8gNEsg bWF4LiBVZ2x5IGJ1dCBub3Qgc3VyZSB3aGF0IG90aGVyIG9wdGlvbnMgY2FuIGFkZHJlc3MgaXQu IFBlcmhhcHMgYXV0aG9ycyB3aWxsDQogY29tZSB1cCB3aXRoIGJldHRlciBvbmUuJm5ic3A7PC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj5TaW5jZSB0aGlzIGlzIGxpa2VseSB0byBiZSBhbiBleHRyZW1l bHkgcmFyZSBvY2N1cnJlbmNlLCBJ4oCZZCBzaW1wbHkgbm90IGFkdmVydGlzZSB0aGUgTkxSSSB0 byBhIHBlZXIgbm90IHN1cHBvcnRpbmcgZXh0ZW5kZWQgbWVzc2FnZXMgYW5kIGxvZyB0aGUgZXJy b3IuICZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QWRkaXRpb25hbGx5LCB3 ZSBjb3VsZCBkaXNjb3VyYWdlIHRoZSBnZW5lcmF0aW9uIG9mIGEgc2luZ2xlIE5MUkkgZXhjZWVk aW5nIDRLLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhhbmtzLDwvZGl2 Pg0KPGRpdj5BY2VlJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8YmxvY2txdW90ZSBpZD0i TUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAj YjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHls ZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxs Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQt ZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQpUaHgs PC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJp YWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NClIuPC9kaXY+DQo8ZGl2 IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNh LHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Z21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNl cmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Z21haWxfZXh0cmEiPjxicj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBXZWQsIE1heSAy NSwgMjAxNiBhdCAxOjQxIFBNLCBBY2VlIExpbmRlbSAoYWNlZSkgPHNwYW4gZGlyPSJsdHIiPg0K Jmx0OzxhIGhyZWY9Im1haWx0bzphY2VlQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFjZWVA Y2lzY28uY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4NCjxibG9ja3F1b3RlIGNsYXNzPSJn bWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2Nj IHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdv cmQ7Y29sb3I6cmdiKDAsMCwwKTtmb250LXNpemU6MTRweDtmb250LWZhbWlseTpDYWxpYnJpLHNh bnMtc2VyaWYiPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3Bhbj4N CjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Zm9udC1zaXplOjExcHQ7dGV4dC1hbGln bjpsZWZ0O2NvbG9yOmJsYWNrO0JPUkRFUi1CT1RUT006bWVkaXVtIG5vbmU7Qk9SREVSLUxFRlQ6 bWVkaXVtIG5vbmU7UEFERElORy1CT1RUT006MGluO1BBRERJTkctTEVGVDowaW47UEFERElORy1S SUdIVDowaW47Qk9SREVSLVRPUDojYjVjNGRmIDFwdCBzb2xpZDtCT1JERVItUklHSFQ6bWVkaXVt IG5vbmU7UEFERElORy1UT1A6M3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5G cm9tOiA8L3NwYW4+SWRyICZsdDs8YSBocmVmPSJtYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5pZHItYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBv ZiBSb2JlcnQgUmFzenVrICZsdDs8YSBocmVmPSJtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQiIHRh cmdldD0iX2JsYW5rIj5yb2JlcnRAcmFzenVrLm5ldDwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9 ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5XZWRuZXNkYXksIE1heSAyNSwgMjAxNiBh dCA2OjM0IEFNPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+ QnJ1bm8gRGVjcmFlbmUgJmx0OzxhIGhyZWY9Im1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2Uu Y29tIiB0YXJnZXQ9Il9ibGFuayI+YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTwvYT4mZ3Q7PGJy Pg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+JnF1b3Q7S2V5dXIg UGF0ZWwgKGtleXVwYXRlKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtleXVwYXRlQGNpc2Nv LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmtleXVwYXRlQGNpc2NvLmNvbTwvYT4mZ3Q7LCBJRFIgTGlz dCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlkckBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlkckBp ZXRmLm9yZzwvYT4mZ3Q7LCBTdXNhbiBIYXJlcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNoYXJlc0Bu ZHpoLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNoYXJlc0BuZHpoLmNvbTwvYT4mZ3Q7PGJyPg0KPHNw YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogW0lkcl0gZHJh ZnQtaWV0Zi1pZHItYmdwLWV4dGVuZGVkLW1lc3NhZ2VzLTEyIFdHIExDICg1LzI0IHRvIDYvNyk8 YnI+DQo8L2Rpdj4NCjxzcGFuIGNsYXNzPSIiPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJCT1JERVItTEVGVDojYjVjNGRmIDUgc29saWQ7UEFERElORzowIDAgMCA1O01B UkdJTjowIDAgMCA1Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGNsYXNz PSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMt c2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCkhpIEJydW5vLDwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21h aWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlm O2ZvbnQtc2l6ZTpzbWFsbCI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJh Ij4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9x dW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlk O3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBsYW5nPSJGUiIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+U3VwcG9zZSB0aGF0IEkgcmVj ZWl2ZSBhbiBleHRlbmRlZCBCR1AgbWVzc2FnZSAoZS5nLiB1cGRhdGUpIHRoYXQgSSBjYW7igJl0 IHJlbGF5IDwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3Jk ZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgbGFuZz0iRlIi IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdj4NCjxwcmU+PHNwYW4gbGFuZz0iRU4t VVMiPnRvIHNvbWUgcGVlcnMgYmVjYXVzZSB0aGV5IGRvbuKAmXQgc3VwcG9ydCBzdWNoIGV4dGVu c2lvbiwgd2hpbGUgSSDigJxzaG91bGTigJ0gaGF2ZSA8L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHls ZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1s ZWZ0OjFleCI+DQo8ZGl2IGxhbmc9IkZSIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXY+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5yZWxheWVkIGl0LiA8L3NwYW4+PC9wcmU+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0 aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCuKAi0JHUCBkb2VzIG5vdCAmcXVvdDty ZWxheSZxdW90OyBtZXNzYWdlcyAuLiBkbyB5b3UgaGF2ZSBzb21lIG5ldyBCR1AgZHJhZnQgaW4g bWluZCB3aGljaCB3b3VsZCB3b3JrIGFzIEJHUCAmcXVvdDtyZXBlYXRlciZxdW90OyA/IFdoaWxl IEkgcmVjYWxsIHdlIGRpc2N1c3NlZCBpdCBpbiB0aGUgcGFzdCB0aGF0IHdvcmsgd2VyZSBwcmV0 dHkgbXVjaCBhYmFuZG9uZWQgOik8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0 eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21h bGwiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9u dC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCkJH UCBnZW5lcmF0ZXMgbWVzc2FnZXMgYXQgZWFjaCBCR1Agc3BlYWtlciBzbyB0aGUgYWJvdmUgc2Vl bXMgbGlrZSBub24gaXNzdWUgdG8gbWUgZm9yIHRoaXMgZHJhZnQuJm5ic3A7PC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L3NwYW4+PC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QSBub24taXNzdWUgdW5s ZXNzIHRoZSBzaXplIG9mIGEgc2luZ2xlIE5MUkkgYW5kIGl0cyBhdHRyaWJ1dGVzIGV4Y2VlZHMg NEsuJm5ic3A7PC9kaXY+DQo8ZGl2PlRoYW5rcyw8L2Rpdj4NCjxkaXY+QWNlZSZuYnNwOzwvZGl2 Pg0KPHNwYW4gY2xhc3M9IiI+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxzcGFuPg0KPGJsb2NrcXVvdGUgc3R5bGU9IkJPUkRFUi1MRUZUOiNiNWM0ZGYgNSBzb2xpZDtQ QURESU5HOjAgMCAwIDU7TUFSR0lOOjAgMCAwIDUiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGRpcj0i bHRyIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3Rl Ij4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6 YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCjxicj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhl bHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQrigIs8L2Rpdj4NCjxkaXYgY2xh c3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fu cy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0K4oCLQmVzdCw8YnI+DQpSLjwvZGl2Pg0KPGRpdiBj bGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxz YW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Imdt YWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJp Zjtmb250LXNpemU6c21hbGwiPg0KRm9yIHRoZSBkcmFmdCBpdHNlbGY6IFN1cHBvcnQg4oCLZnJv bSBtZS4mbmJzcDs8YnI+DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+Jm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPjwvc3Bhbj48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFu Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D36B2E2D625D3aceeciscocom_-- From nobody Wed May 25 08:16:58 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B848812DCAD for ; Wed, 25 May 2016 08:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9eteivFuA_j3 for ; Wed, 25 May 2016 08:16:55 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D19EB12DC03 for ; Wed, 25 May 2016 08:14:44 -0700 (PDT) Received: by mail-lb0-x22a.google.com with SMTP id sh2so16236080lbb.1 for ; Wed, 25 May 2016 08:14:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=syyV/yzcxXFXB2bUmghmMQE1MyrWUk2JBlJ5pJ5X1Pc=; b=mMojCWUcG978QrMAyeejAGPUnCo787bcg+Rwuhcd7GCg0WwjtdyxsfAQemUCS1tD+c mIdjavLnj3WRdAS0gguesGYKnHvxIQYZYu2Nux9hqAa7Sa3oIgLvq45gPMptRJDN7vK3 Y/YQ/DAUYQb05RTmZUEXBPSWTWwpJevCs2Bq/o5MANGTaz1ZBpdednDOEOO3owApv1Px FsOoDDdFE1G+iHHjqU63NIAWCwA3/4BgKqL5mZfPr6Z09a9/I1/k2lWvYgfurT0rKYly hY3XeO/mXRYrTNIR1wQNwDorOVMVTy6mJjlA+hh5mztinJyjMU5LFL1BZ+8bQzpQFQlG yxqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=syyV/yzcxXFXB2bUmghmMQE1MyrWUk2JBlJ5pJ5X1Pc=; b=Hr1j+bLl5QqKAfphgPZGkV/V7clCW0oY+PM0QfrJR97pjRxYcIG53NxvqaZbs4/9Vk T2cmxRaJolMg4w68awAPQu/Lx76ua/vT96XZTChHeLDx0oW76E51IMs2JR9RP7HNC2Gi b1S5Jv2vgbo5vtTh3LEP+zPdHk1iOEG4OOPzxAwwXvkojXoqvETrRcX1Wz61dvSi6vm9 oFD5DTp3xM0ezY8ROXpsrQ2hQFnme+D+oNpZ8MKHlzwlBzZhImkK4L/0qArd76IejUjq GRcDvkdT8h5AAQCj87FSzfXBtuvH1kYOTa7RJCpqz7XxuEObRYtGI4DX3WO5RtoxxDnv J+Qw== X-Gm-Message-State: ALyK8tLAZQ0QO79QpmavuChY4qudiDdG93cw6RU933/m5ktqSuBX+ZFUZ+9jHS9+i5T4sZ5FvQP3OnBf3Dt7cg== MIME-Version: 1.0 X-Received: by 10.112.198.169 with SMTP id jd9mr1207546lbc.94.1464189282968; Wed, 25 May 2016 08:14:42 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.25.134.196 with HTTP; Wed, 25 May 2016 08:14:42 -0700 (PDT) In-Reply-To: References: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> <13146_1464170675_574578B3_13146_4888_1_53C29892C857584299CBF5D05346208A0F8CD227@OPEXCLILM21.corporate.adroot.infra.ftgroup> Date: Wed, 25 May 2016 17:14:42 +0200 X-Google-Sender-Auth: jQvJjhPjdLoW7DYQ4lR0XQemQLs Message-ID: From: Robert Raszuk To: "Acee Lindem (acee)" Content-Type: multipart/alternative; boundary=001a11c341a8186e250533ac223b Archived-At: Cc: "Keyur Patel \(keyupate\)" , Bruno Decraene , Susan Hares , "idr@ietf.org" Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 15:16:58 -0000 --001a11c341a8186e250533ac223b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E2=80=8BIt will result in a permanent control plane loop =E2=80=8Bif such = dropped NLRI on IBGP is a more specific entry. Even if according to your judgement it may be classified as "extremely rare" I do not think IETF spec should take such risk. Best, R. On Wed, May 25, 2016 at 4:29 PM, Acee Lindem (acee) wrote: > Hi Robert, > > From: on behalf of Robert Raszuk > Date: Wednesday, May 25, 2016 at 7:50 AM > To: Acee Lindem > Cc: Bruno Decraene , "Keyur Patel (keyupate)" = < > keyupate@cisco.com>, IDR List , Susan Hares > > Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to > 6/7) > > Hi AC, > > Yes indeed - you are right - I was a bit hit with "relay" term :). > > And since this entire work started with the assumption that packing per > NLRI will be broken anyway one could expect this to be always the case. > > So it does look like a bit of show stopper to me unless we enforce that i= f > there is at least one BGP peer on given BGP speaker not supporting 64K al= l > sessions will get reset to 4K max. Ugly but not sure what other options c= an > address it. Perhaps authors will come up with better one. > > > Since this is likely to be an extremely rare occurrence, I=E2=80=99d simp= ly not > advertise the NLRI to a peer not supporting extended messages and log the > error. > > Additionally, we could discourage the generation of a single NLRI > exceeding 4K. > > Thanks, > Acee > > > > Thx, > R. > > > > On Wed, May 25, 2016 at 1:41 PM, Acee Lindem (acee) > wrote: > >> >> >> From: Idr on behalf of Robert Raszuk < >> robert@raszuk.net> >> Date: Wednesday, May 25, 2016 at 6:34 AM >> To: Bruno Decraene >> Cc: "Keyur Patel (keyupate)" , IDR List , >> Susan Hares >> Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 >> to 6/7) >> >> Hi Bruno, >> >> Suppose that I receive an extended BGP message (e.g. update) that I can= =E2=80=99t relay >>> >>> to some peers because they don=E2=80=99t support such extension, while = I =E2=80=9Cshould=E2=80=9D have >>> >>> relayed it. >>> >>> >> =E2=80=8BBGP does not "relay" messages .. do you have some new BGP draft= in mind >> which would work as BGP "repeater" ? While I recall we discussed it in t= he >> past that work were pretty much abandoned :) >> >> BGP generates messages at each BGP speaker so the above seems like non >> issue to me for this draft. >> >> >> A non-issue unless the size of a single NLRI and its attributes exceeds >> 4K. >> Thanks, >> Acee >> >> >> >> =E2=80=8B >> =E2=80=8BBest, >> R. >> >> For the draft itself: Support =E2=80=8Bfrom me. >> >> >> >> >> > --001a11c341a8186e250533ac223b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=E2=80=8BI= t will result in a permanent control plane loop =E2=80=8Bif such dropped NL= RI on IBGP is a more specific entry.=C2=A0

Even if according to your judgement it may be classifi= ed as "extremely rare" I do not think IETF spec should take such = risk.=C2=A0

Best,
R= .



On Wed, May 25, 2016 = at 4:29 PM, Acee Lindem (acee) <acee@cisco.com> wrote:
Hi Robert,=C2=A0

From: <rraszuk@gmail.com> on behalf of Robert= Raszuk <robert@r= aszuk.net>
Date: Wednesday, May 25, 2016 at 7:= 50 AM
To: Acee Lindem <acee@cisco.com>
Cc: Bruno Decraene <bruno.decraene@orange.co= m>, "Keyur Patel (keyupate)" <keyupate@cisco.com>, IDR List <idr@ietf.org>, Susan Hares <share= s@ndzh.com>
Subject: Re: [Idr] draft-ietf-idr-b= gp-extended-messages-12 WG LC (5/24 to 6/7)

Hi AC,

Yes indeed - you are right - I was a bit hit with "relay" term :)= .=C2=A0

And since this entire work started with the assumption that packing per NLR= I will be broken anyway one could expect this to be always the case.=C2=A0<= /div>

So it does look like a bit of show stopper to me unless we enforce that if = there is at least one BGP peer on given BGP speaker not supporting 64K all = sessions will get reset to 4K max. Ugly but not sure what other options can= address it. Perhaps authors will come up with better one.=C2=A0

Since this is likely to be an extremely rare occurrence, I=E2=80=99d s= imply not advertise the NLRI to a peer not supporting extended messages and= log the error. =C2=A0

Additionally, we could discourage the generation of a single NLRI exce= eding 4K.=C2=A0

Thanks,
Acee=C2=A0



Thx,
R.



On Wed, May 25, 2016 at 1:41 PM, Acee Lindem (ac= ee) <acee@cisco.com&= gt; wrote:


From: Idr <idr-bounces@ietf.org> on behalf= of Robert Raszuk <robert@raszuk.net>
Date: Wednesday, May 25, 2016 at 6:= 34 AM
To: Bruno Decraene <bruno.decraene@orange.co= m>
Cc: "Keyur Patel (keyupate)&qu= ot; <keyupate@ci= sco.com>, IDR List <idr@ietf.org>, Susan Hares <shares@ndzh.com>
Subject: Re: [Idr] draft-ietf-idr-b= gp-extended-messages-12 WG LC (5/24 to 6/7)

Hi Bruno,

Suppose that I receive an extended BGP message (e=
.g. update) that I can=E2=80=99t relay 
to some peers because they don=E2=80=99t support =
such extension, while I =E2=80=9Cshould=E2=80=9D have 
relayed it.

=E2=80=8BBGP does not "relay" messages .. do you have some new BG= P draft in mind which would work as BGP "repeater" ? While I reca= ll we discussed it in the past that work were pretty much abandoned :)

BGP generates messages at each BGP speaker so the above seems like non issu= e to me for this draft.=C2=A0

A non-issue unless the size of a single NLRI and its attributes exceed= s 4K.=C2=A0
Thanks,
Acee=C2=A0



=E2=80=8B
=E2=80=8BBest,
R.

For the draft itself: Support =E2=80=8Bfrom me.=C2=A0


=C2=A0

--001a11c341a8186e250533ac223b-- From nobody Wed May 25 08:32:14 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B921912D1B8 for ; Wed, 25 May 2016 08:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kfln_1Kw7REU for ; Wed, 25 May 2016 08:32:11 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5489F12D77E for ; Wed, 25 May 2016 08:30:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=434; q=dns/txt; s=iport; t=1464190200; x=1465399800; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=AFQOKySdHTPZX4WcC4si6xq4Ez304tFHIJqs/4V0ab0=; b=Zdp1dLgb3M9U16/cokMA4qMMMZfj8qpDSBbU0mA5DFOkBFeGoj43e7wu W4liNsosqhsbHiLPHvSsRFd/pJVxjcbvEAZeV41+LzrTYGvt7dzujGGFO 6r31utqs8A73rEP79RXz54ayhPhobQPgcak8bIW+7/saLOeZ3kx5GFxpe Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AdAgASxEVX/5tdJa1cgzdWfQa5cQENg?= =?us-ascii?q?XcXC4VvAoFAOBQBAQEBAQEBZSeERAEBAwEBAQE3NAsQAgEINhAnCyUCBAENBYg?= =?us-ascii?q?nCA7EJgEBAQEBAQEBAQEBAQEBAQEBAQEBARcFhieETIoZAQSYNwGOH4FTAY1Ij?= =?us-ascii?q?0sBHgEBQoNtbokIfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,364,1459814400"; d="scan'208";a="275928876" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 May 2016 15:29:59 +0000 Received: from XCH-RTP-020.cisco.com (xch-rtp-020.cisco.com [64.101.220.160]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u4PFTxQF001143 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 25 May 2016 15:29:59 GMT Received: from xch-rtp-017.cisco.com (64.101.220.157) by XCH-RTP-020.cisco.com (64.101.220.160) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 25 May 2016 11:29:58 -0400 Received: from xch-rtp-017.cisco.com ([64.101.220.157]) by XCH-RTP-017.cisco.com ([64.101.220.157]) with mapi id 15.00.1104.009; Wed, 25 May 2016 11:29:58 -0400 From: "Keyur Patel (keyupate)" To: Randy Bush , Susan Hares Thread-Topic: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) Thread-Index: AQHRtppLUUD33tF9UkKST93hXB+Dkw== Date: Wed, 25 May 2016 15:29:58 +0000 Message-ID: References: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.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.4.9.150325 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.6.18] Content-Type: text/plain; charset="us-ascii" Content-ID: <7C3C4A6E9A870C42A80249C2532CB80B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 15:32:14 -0000 +1. Support as a co-author. On 5/25/16, 12:13 AM, "Randy Bush" wrote: >> This begins a 2 week WG LC on draft-ietf-idr-bgp-extended-messages >> (5/24 to 6/7). > >as the new fasion seems to require [co-]authors to 'vote', as a >co-author i support this going to rfc. > >randy > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From nobody Wed May 25 08:35:53 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83A2912D6E9 for ; Wed, 25 May 2016 08:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfVBAr982VPX for ; Wed, 25 May 2016 08:35:50 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C16F012D7E3 for ; Wed, 25 May 2016 08:34:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10943; q=dns/txt; s=iport; t=1464190466; x=1465400066; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=xYH1L9nQ80LEt/D+05n2gakTq2rkhg/G6kFqNZUdjGM=; b=WXZo/WIFCMhOWB9mycvaFTppQCHHHZ9rAiFqMPSsmA9rR1hvjAcy4PjF DhlxRoM2a5HkSyFuAPWAyxQCtg9rM0ekBC19FuZFcYA8Y7DXHNmB6+S2R g+Yl5JRGjQYh2mqXWMqBKtwY/PzaO83H5P+fk5rjDkXrZORgyEwOl6MfW s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BAAgC4xEVX/5xdJa1cgmxLgVMGtHiEe?= =?us-ascii?q?QENgXeGEQIcgSQ4FAEBAQEBAQFlJ4RDAQEBBCNWEAIBCBEDAQIoAwICAjAUCQg?= =?us-ascii?q?CBAENBRuIFLJDkWwBAQEBAQEBAQEBAQEBAQEBAQEBAQEchieETIQSTYJhglkFm?= =?us-ascii?q?DcBjh+PHI9LAR4BAUKDbW6ISj5/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,364,1459814400"; d="scan'208,217";a="276288909" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 May 2016 15:34:26 +0000 Received: from XCH-RTP-020.cisco.com (xch-rtp-020.cisco.com [64.101.220.160]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u4PFYPqv002751 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 25 May 2016 15:34:25 GMT Received: from xch-rtp-017.cisco.com (64.101.220.157) by XCH-RTP-020.cisco.com (64.101.220.160) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 25 May 2016 11:34:24 -0400 Received: from xch-rtp-017.cisco.com ([64.101.220.157]) by XCH-RTP-017.cisco.com ([64.101.220.157]) with mapi id 15.00.1104.009; Wed, 25 May 2016 11:34:24 -0400 From: "Keyur Patel (keyupate)" To: Robert Raszuk , Bruno Decraene Thread-Topic: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) Thread-Index: AQHRtprq+lObACwrYUK+SmAOAYLpXA== Date: Wed, 25 May 2016 15:34:24 +0000 Message-ID: References: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> <13146_1464170675_574578B3_13146_4888_1_53C29892C857584299CBF5D05346208A0F8CD227@OPEXCLILM21.corporate.adroot.infra.ftgroup> <20520_1464176764_5745907C_20520_692_1_53C29892C857584299CBF5D05346208A0F8CD7B8@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.6.18] Content-Type: multipart/alternative; boundary="_000_D36B137D40807keyupateciscocom_" MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" , Susan Hares Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 15:35:51 -0000 --_000_D36B137D40807keyupateciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29tbWVudHMgaW5saW5lZCAjS2V5dXIuDQoNCkZyb206IFJvYmVydCBSYXN6dWsgPHJvYmVydEBy YXN6dWsubmV0PG1haWx0bzpyb2JlcnRAcmFzenVrLm5ldD4+DQpEYXRlOiBXZWRuZXNkYXksIE1h eSAyNSwgMjAxNiBhdCA0OjUzIEFNDQpUbzogQnJ1bm8gRGVjcmFlbmUgPGJydW5vLmRlY3JhZW5l QG9yYW5nZS5jb208bWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20+Pg0KQ2M6IFN1c2Fu IEhhcmVzIDxzaGFyZXNAbmR6aC5jb208bWFpbHRvOnNoYXJlc0BuZHpoLmNvbT4+LCBLZXl1ciBQ YXRlbCA8a2V5dXBhdGVAY2lzY28uY29tPG1haWx0bzprZXl1cGF0ZUBjaXNjby5jb20+PiwgImlk ckBpZXRmLm9yZzxtYWlsdG86aWRyQGlldGYub3JnPiIgPGlkckBpZXRmLm9yZzxtYWlsdG86aWRy QGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbSWRyXSBkcmFmdC1pZXRmLWlkci1iZ3AtZXh0ZW5k ZWQtbWVzc2FnZXMtMTIgV0cgTEMgKDUvMjQgdG8gNi83KQ0KDQoNCuKAi0JHUCBkb2VzIG5vdCAi cmVsYXkiIG1lc3NhZ2VzIC4uDQoNCk15IG1pc3Rha2UuIFdvdWxkIOKAnHByb3BhZ2F0ZeKAnSBv ciDigJxyZS1hZHZlcnRpc2XigJ0gb3Ig4oCccmVmbGVjdOKAnSBiZSBhIGJldHRlciB0ZXJtIGZv ciB5b3U/DQoNCg0K4oCLWXVwLuKAiw0KDQoNCg0KZG8geW91IGhhdmUgc29tZSBuZXcgQkdQIGRy YWZ0IGluIG1pbmQgd2hpY2ggd291bGQgd29yayBhcyBCR1AgInJlcGVhdGVyIiA/DQoNCkxldOKA mXMgY29uc2lkZXIgUkZDIDQ0NTYgKEJHUCBSb3V0ZSBSZWZsZWN0aW9uKS4gSWYgc29tZSBpQkdQ IGNsaWVudHMgZG8gbm90IGFkdmVydGlzZSB0aGlzIGJlaGF2aW9yLCB0aGV5IHdpbGwgbm90IHJl Y2VpdmUgdGhlIGludGVybmFsIHJvdXRlcyBhZHZlcnRpc2VkIGJ5IHRoZSBpQkdQIGNsaWVudHMg c2VuZGluZyBleHRlbmRlZCBtZXNzYWdlcy4gSGVuY2UsIGFsbCBpQkdQIHJvdXRlcnMgZG8gbm90 IGhhdmUgYSBjb25zaXN0ZW50IGtub3dsZWRnZSBvZiB0aGUgaW50ZXJuYWwgcm91dGVycy4NCg0K DQrigItXZWxsIHRoYXQgd291bGQgYmUgZHJhc3RpYy4gUGVyaGFwcyBsaWdodGVyIG9wdGlvbiB3 b3VsZCBiZSB0byBkcm9wIGxhcmdlc3Qgb3B0aW9uYWwgYXR0cmlidXRlcywgYnV0IEkgYW0gbm90 IHN1cmUgaWYgSSBsaWtlIHN1Y2ggc3dpc3MgY2hlZXNlIHNvbHV0aW9uLg0KDQpZZXMgYW5vdGhl ciBvcHRpb24gd291bGQgYmUgdG8gaGF2ZSB0aGlzIGtub2JiZWQgZm9yIGZldyB5ZWFycyBhbmQg ZW5hYmxlIG9ubHkgYnkgTk9DIHdoZW4gYWxsIHJvdXRlcnMgc3VwcG9ydCBpdC4g4oCLDQoNCkF1 dG9tYXRpYyBpbmNyZW1lbnRhbCBkZXBsb3ltZW50IOKAi2lzIGJpdCBoYXJkIGluIG5ldHdvcmsg d2lkZSBlbmhhbmNlbWVudHMgOikpDQoNCg0KI0tleXVyOiAgQ2xpZW50cyB3b3VsZCByZWNlaXZl IGludGVybmFsIHJvdXRlcyBhcyBsb25nIGFzIGEgUlIgY2FuIGFubm91bmNlIHByZWZpeGVzIHVz aW5nIGV4aXN0aW5nIG1lc3NhZ2UgbGVuZ3RoIChvZiA0SykuIElmIHRoZSBhdHRyaWJ1dGUgc2l6 ZSBpcyBzdWNoIHRoYXQgdGhlIG1lc3NhZ2UgbGVuZ3RoIGRvZXMgZ2V0IGV4Y2VlZGVkIHRoZW4g dGhlIFByZWZpeCBTSE9VTEQgbm90IGJlIGFubm91bmNlZCBhbmQgYW4gZXJyb3Igc2hvdWxkIGJl IGxvZ2dlZCAoZXhpc3RpbmcgY2FzZSkuDQoNClJlZ2FyZHMsDQpLZXl1cg0KDQoNCg0KVGh4LA0K ci4NCg0KDQoNCg== --_000_D36B137D40807keyupateciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <88A462D2ED8B864993DDDB0B3937E461@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5Db21tZW50cyBp bmxpbmVkICNLZXl1ci48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NS Q19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1z aXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1l ZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47 IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0 ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0 Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+Um9iZXJ0IFJh c3p1ayAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvYmVydEByYXN6dWsubmV0Ij5yb2JlcnRAcmFzenVr Lm5ldDwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwv c3Bhbj5XZWRuZXNkYXksIE1heSAyNSwgMjAxNiBhdCA0OjUzIEFNPGJyPg0KPHNwYW4gc3R5bGU9 ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+QnJ1bm8gRGVjcmFlbmUgJmx0OzxhIGhyZWY9 Im1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tIj5icnVuby5kZWNyYWVuZUBvcmFuZ2Uu Y29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bh bj5TdXNhbiBIYXJlcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNoYXJlc0BuZHpoLmNvbSI+c2hhcmVz QG5kemguY29tPC9hPiZndDssIEtleXVyIFBhdGVsICZsdDs8YSBocmVmPSJtYWlsdG86a2V5dXBh dGVAY2lzY28uY29tIj5rZXl1cGF0ZUBjaXNjby5jb208L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0i bWFpbHRvOmlkckBpZXRmLm9yZyI+aWRyQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmlkckBpZXRmLm9yZyI+aWRyQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHls ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJlOiBbSWRyXSBkcmFmdC1pZXRm LWlkci1iZ3AtZXh0ZW5kZWQtbWVzc2FnZXMtMTIgV0cgTEMgKDUvMjQgdG8gNi83KTxicj4NCjwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8 ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8Ymxv Y2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3Jk ZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgbGFuZz0iRlIi IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBw dCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj48c3BhbiBjbGFzcz0iIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMt c2VyaWY7Ij48YnI+DQrigItCR1AgZG9lcyBub3QgJnF1b3Q7cmVsYXkmcXVvdDsgbWVzc2FnZXMg Li48c3BhbiBzdHlsZT0iY29sb3I6IzFmNDk3ZCI+PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1 KTsiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcD4NCjwvc3Bhbj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5N eSBtaXN0YWtlLiBXb3VsZCDigJxwcm9wYWdhdGXigJ0gb3Ig4oCccmUtYWR2ZXJ0aXNl4oCdIG9y IOKAnHJlZmxlY3TigJ0gYmUgYSBiZXR0ZXIgdGVybSBmb3IgeW91Pzwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFs LGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQrigItZdXAu4oCLPC9kaXY+ DQo8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21h aWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBz b2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgbGFuZz0iRlIiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+ DQo8c3BhbiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsiPmRvIHlvdSBoYXZlIHNvbWUgbmV3IEJHUCBkcmFm dCBpbiBtaW5kIHdoaWNoIHdvdWxkIHdvcmsgYXMgQkdQICZxdW90O3JlcGVhdGVyJnF1b3Q7ID88 c3BhbiBzdHlsZT0iY29sb3I6IzFmNDk3ZCI+PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsi Pjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcD4NCjwvc3Bhbj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5MZXTi gJlzIGNvbnNpZGVyIFJGQyA0NDU2IChCR1AgUm91dGUgUmVmbGVjdGlvbikuIElmIHNvbWUgaUJH UCBjbGllbnRzIGRvIG5vdCBhZHZlcnRpc2UgdGhpcyBiZWhhdmlvciwgdGhleSB3aWxsIG5vdCBy ZWNlaXZlIHRoZSBpbnRlcm5hbA0KIHJvdXRlcyBhZHZlcnRpc2VkIGJ5IHRoZSBpQkdQIGNsaWVu dHMgc2VuZGluZyBleHRlbmRlZCBtZXNzYWdlcy4gSGVuY2UsIGFsbCBpQkdQIHJvdXRlcnMgZG8g bm90IGhhdmUgYSBjb25zaXN0ZW50IGtub3dsZWRnZSBvZiB0aGUgaW50ZXJuYWwgcm91dGVycy48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJm b250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0K 4oCLV2VsbCB0aGF0IHdvdWxkIGJlIGRyYXN0aWMuIFBlcmhhcHMgbGlnaHRlciBvcHRpb24gd291 bGQgYmUgdG8gZHJvcCBsYXJnZXN0IG9wdGlvbmFsIGF0dHJpYnV0ZXMsIGJ1dCBJIGFtIG5vdCBz dXJlIGlmIEkgbGlrZSBzdWNoIHN3aXNzIGNoZWVzZSBzb2x1dGlvbi4mbmJzcDs8L2Rpdj4NCjxk aXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRp Y2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMt c2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NClllcyBhbm90aGVyIG9wdGlvbiB3b3VsZCBiZSB0byBo YXZlIHRoaXMga25vYmJlZCBmb3IgZmV3IHllYXJzIGFuZCBlbmFibGUgb25seSBieSBOT0Mgd2hl biBhbGwgcm91dGVycyBzdXBwb3J0IGl0LiDigIs8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2 ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KQXV0b21hdGljIGluY3JlbWVudGFs IGRlcGxveW1lbnQg4oCLaXMgYml0IGhhcmQgaW4gbmV0d29yayB3aWRlIGVuaGFuY2VtZW50cyA6 KSk8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N Cjwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4jS2V5 dXI6ICZuYnNwO0NsaWVudHMgd291bGQgcmVjZWl2ZSBpbnRlcm5hbCByb3V0ZXMgYXMgbG9uZyBh cyBhIFJSIGNhbiBhbm5vdW5jZSBwcmVmaXhlcyB1c2luZyBleGlzdGluZyBtZXNzYWdlIGxlbmd0 aCAob2YgNEspLiBJZiB0aGUgYXR0cmlidXRlIHNpemUgaXMgc3VjaCB0aGF0IHRoZSBtZXNzYWdl IGxlbmd0aCBkb2VzIGdldCBleGNlZWRlZCB0aGVuIHRoZSBQcmVmaXggU0hPVUxEIG5vdCBiZSBh bm5vdW5jZWQgYW5kIGFuIGVycm9yIHNob3VsZA0KIGJlIGxvZ2dlZCAoZXhpc3RpbmcgY2FzZSku PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5SZWdhcmRzLDwvZGl2Pg0KPGRpdj5LZXl1 cjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0i T0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj4NCjxk aXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXY+ DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVs dmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxz YW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQpUaHgsPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFp bF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7 Zm9udC1zaXplOnNtYWxsIj4NCnIuPC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D36B137D40807keyupateciscocom_-- From nobody Wed May 25 08:36:28 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12BE812D7A1 for ; Wed, 25 May 2016 08:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Jl1PZ90dngV for ; Wed, 25 May 2016 08:36:24 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 954F412D7C3 for ; Wed, 25 May 2016 08:35:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19711; q=dns/txt; s=iport; t=1464190503; x=1465400103; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9tAOCNk/7IDtH9AM1V+wWl7TdRwyj1lbltBWbiJ1NM8=; b=mVDwgrsh9QEZjShwqrAynFNVSW39NpunEh8wfhvIVDLC/gteX31AxUoi KWwz26aynwmt8p2ux643mn01ztMh3tzoUxv3FA+m9kwlSc2jEmqqm5SHP DTDD8WQOdFKtdnfgCby88EnHoF9KBnU1H7sVfqSoyM+mRor5i8sl6pD94 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BBAgARxUVX/4cNJK1cgmxLgVMGrgKGd?= =?us-ascii?q?oR5AQ2Bd4YRAhyBJDgUAQEBAQEBAWUnhEMBAQEEI1YQAgEGAhEDAQIoAwICAh8?= =?us-ascii?q?RFAkIAgQBDQWIFQMXlSadHY02DYQpAQEBAQEBAQEBAQEBAQEBAQEBAQEBHIYng?= =?us-ascii?q?0mBA4JDghyCYYJZBZM3hE0zAYwmgXmBaY0zhjOBMYdnAR4BAUKDbW6JCH8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,364,1459814400"; d="scan'208,217";a="108093430" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 May 2016 15:35:02 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u4PFZ2Hp014983 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 25 May 2016 15:35:02 GMT Received: from xch-rtp-017.cisco.com (64.101.220.157) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 25 May 2016 11:35:00 -0400 Received: from xch-rtp-017.cisco.com ([64.101.220.157]) by XCH-RTP-017.cisco.com ([64.101.220.157]) with mapi id 15.00.1104.009; Wed, 25 May 2016 11:35:01 -0400 From: "Keyur Patel (keyupate)" To: "Acee Lindem (acee)" , Robert Raszuk Thread-Topic: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) Thread-Index: AQHRtpsA+lObACwrYUK+SmAOAYLpXA== Date: Wed, 25 May 2016 15:35:01 +0000 Message-ID: References: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> <13146_1464170675_574578B3_13146_4888_1_53C29892C857584299CBF5D05346208A0F8CD227@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.6.18] Content-Type: multipart/alternative; boundary="_000_D36B14064080Ekeyupateciscocom_" MIME-Version: 1.0 Archived-At: Cc: Bruno Decraene , Susan Hares , "idr@ietf.org" Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 15:36:27 -0000 --_000_D36B14064080Ekeyupateciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29tbWVudHMgaW5saW5lZCAjS2V5dXINCg0KRnJvbTogIkFjZWUgTGluZGVtIChhY2VlKSIgPGFj ZWVAY2lzY28uY29tPG1haWx0bzphY2VlQGNpc2NvLmNvbT4+DQpEYXRlOiBXZWRuZXNkYXksIE1h eSAyNSwgMjAxNiBhdCA3OjI5IEFNDQpUbzogUm9iZXJ0IFJhc3p1ayA8cm9iZXJ0QHJhc3p1ay5u ZXQ8bWFpbHRvOnJvYmVydEByYXN6dWsubmV0Pj4NCkNjOiBCcnVubyBEZWNyYWVuZSA8YnJ1bm8u ZGVjcmFlbmVAb3JhbmdlLmNvbTxtYWlsdG86YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbT4+LCBL ZXl1ciBQYXRlbCA8a2V5dXBhdGVAY2lzY28uY29tPG1haWx0bzprZXl1cGF0ZUBjaXNjby5jb20+ PiwgImlkckBpZXRmLm9yZzxtYWlsdG86aWRyQGlldGYub3JnPiIgPGlkckBpZXRmLm9yZzxtYWls dG86aWRyQGlldGYub3JnPj4sIFN1c2FuIEhhcmVzIDxzaGFyZXNAbmR6aC5jb208bWFpbHRvOnNo YXJlc0BuZHpoLmNvbT4+DQpTdWJqZWN0OiBSZTogW0lkcl0gZHJhZnQtaWV0Zi1pZHItYmdwLWV4 dGVuZGVkLW1lc3NhZ2VzLTEyIFdHIExDICg1LzI0IHRvIDYvNykNCg0KSGkgUm9iZXJ0LA0KDQpG cm9tOiA8cnJhc3p1a0BnbWFpbC5jb208bWFpbHRvOnJyYXN6dWtAZ21haWwuY29tPj4gb24gYmVo YWxmIG9mIFJvYmVydCBSYXN6dWsgPHJvYmVydEByYXN6dWsubmV0PG1haWx0bzpyb2JlcnRAcmFz enVrLm5ldD4+DQpEYXRlOiBXZWRuZXNkYXksIE1heSAyNSwgMjAxNiBhdCA3OjUwIEFNDQpUbzog QWNlZSBMaW5kZW0gPGFjZWVAY2lzY28uY29tPG1haWx0bzphY2VlQGNpc2NvLmNvbT4+DQpDYzog QnJ1bm8gRGVjcmFlbmUgPGJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208bWFpbHRvOmJydW5vLmRl Y3JhZW5lQG9yYW5nZS5jb20+PiwgIktleXVyIFBhdGVsIChrZXl1cGF0ZSkiIDxrZXl1cGF0ZUBj aXNjby5jb208bWFpbHRvOmtleXVwYXRlQGNpc2NvLmNvbT4+LCBJRFIgTGlzdCA8aWRyQGlldGYu b3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+PiwgU3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbTxt YWlsdG86c2hhcmVzQG5kemguY29tPj4NClN1YmplY3Q6IFJlOiBbSWRyXSBkcmFmdC1pZXRmLWlk ci1iZ3AtZXh0ZW5kZWQtbWVzc2FnZXMtMTIgV0cgTEMgKDUvMjQgdG8gNi83KQ0KDQpIaSBBQywN Cg0KWWVzIGluZGVlZCAtIHlvdSBhcmUgcmlnaHQgLSBJIHdhcyBhIGJpdCBoaXQgd2l0aCAicmVs YXkiIHRlcm0gOikuDQoNCkFuZCBzaW5jZSB0aGlzIGVudGlyZSB3b3JrIHN0YXJ0ZWQgd2l0aCB0 aGUgYXNzdW1wdGlvbiB0aGF0IHBhY2tpbmcgcGVyIE5MUkkgd2lsbCBiZSBicm9rZW4gYW55d2F5 IG9uZSBjb3VsZCBleHBlY3QgdGhpcyB0byBiZSBhbHdheXMgdGhlIGNhc2UuDQoNClNvIGl0IGRv ZXMgbG9vayBsaWtlIGEgYml0IG9mIHNob3cgc3RvcHBlciB0byBtZSB1bmxlc3Mgd2UgZW5mb3Jj ZSB0aGF0IGlmIHRoZXJlIGlzIGF0IGxlYXN0IG9uZSBCR1AgcGVlciBvbiBnaXZlbiBCR1Agc3Bl YWtlciBub3Qgc3VwcG9ydGluZyA2NEsgYWxsIHNlc3Npb25zIHdpbGwgZ2V0IHJlc2V0IHRvIDRL IG1heC4gVWdseSBidXQgbm90IHN1cmUgd2hhdCBvdGhlciBvcHRpb25zIGNhbiBhZGRyZXNzIGl0 LiBQZXJoYXBzIGF1dGhvcnMgd2lsbCBjb21lIHVwIHdpdGggYmV0dGVyIG9uZS4NCg0KU2luY2Ug dGhpcyBpcyBsaWtlbHkgdG8gYmUgYW4gZXh0cmVtZWx5IHJhcmUgb2NjdXJyZW5jZSwgSeKAmWQg c2ltcGx5IG5vdCBhZHZlcnRpc2UgdGhlIE5MUkkgdG8gYSBwZWVyIG5vdCBzdXBwb3J0aW5nIGV4 dGVuZGVkIG1lc3NhZ2VzIGFuZCBsb2cgdGhlIGVycm9yLg0KDQpBZGRpdGlvbmFsbHksIHdlIGNv dWxkIGRpc2NvdXJhZ2UgdGhlIGdlbmVyYXRpb24gb2YgYSBzaW5nbGUgTkxSSSBleGNlZWRpbmcg NEsuDQoNCiNLZXl1cjogWWVwLiBJIGFncmVlLiA6KQ0KDQpSZWdhcmRzLA0KS2V5dXINCg0KDQpU aGFua3MsDQpBY2VlDQoNCg0KDQpUaHgsDQpSLg0KDQoNCg0KT24gV2VkLCBNYXkgMjUsIDIwMTYg YXQgMTo0MSBQTSwgQWNlZSBMaW5kZW0gKGFjZWUpIDxhY2VlQGNpc2NvLmNvbTxtYWlsdG86YWNl ZUBjaXNjby5jb20+PiB3cm90ZToNCg0KDQpGcm9tOiBJZHIgPGlkci1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBSb2JlcnQgUmFzenVr IDxyb2JlcnRAcmFzenVrLm5ldDxtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ+Pg0KRGF0ZTogV2Vk bmVzZGF5LCBNYXkgMjUsIDIwMTYgYXQgNjozNCBBTQ0KVG86IEJydW5vIERlY3JhZW5lIDxicnVu by5kZWNyYWVuZUBvcmFuZ2UuY29tPG1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPj4N CkNjOiAiS2V5dXIgUGF0ZWwgKGtleXVwYXRlKSIgPGtleXVwYXRlQGNpc2NvLmNvbTxtYWlsdG86 a2V5dXBhdGVAY2lzY28uY29tPj4sIElEUiBMaXN0IDxpZHJAaWV0Zi5vcmc8bWFpbHRvOmlkckBp ZXRmLm9yZz4+LCBTdXNhbiBIYXJlcyA8c2hhcmVzQG5kemguY29tPG1haWx0bzpzaGFyZXNAbmR6 aC5jb20+Pg0KU3ViamVjdDogUmU6IFtJZHJdIGRyYWZ0LWlldGYtaWRyLWJncC1leHRlbmRlZC1t ZXNzYWdlcy0xMiBXRyBMQyAoNS8yNCB0byA2LzcpDQoNCkhpIEJydW5vLA0KDQoNClN1cHBvc2Ug dGhhdCBJIHJlY2VpdmUgYW4gZXh0ZW5kZWQgQkdQIG1lc3NhZ2UgKGUuZy4gdXBkYXRlKSB0aGF0 IEkgY2Fu4oCZdCByZWxheQ0KDQp0byBzb21lIHBlZXJzIGJlY2F1c2UgdGhleSBkb27igJl0IHN1 cHBvcnQgc3VjaCBleHRlbnNpb24sIHdoaWxlIEkg4oCcc2hvdWxk4oCdIGhhdmUNCg0KcmVsYXll ZCBpdC4NCg0K4oCLQkdQIGRvZXMgbm90ICJyZWxheSIgbWVzc2FnZXMgLi4gZG8geW91IGhhdmUg c29tZSBuZXcgQkdQIGRyYWZ0IGluIG1pbmQgd2hpY2ggd291bGQgd29yayBhcyBCR1AgInJlcGVh dGVyIiA/IFdoaWxlIEkgcmVjYWxsIHdlIGRpc2N1c3NlZCBpdCBpbiB0aGUgcGFzdCB0aGF0IHdv cmsgd2VyZSBwcmV0dHkgbXVjaCBhYmFuZG9uZWQgOikNCg0KQkdQIGdlbmVyYXRlcyBtZXNzYWdl cyBhdCBlYWNoIEJHUCBzcGVha2VyIHNvIHRoZSBhYm92ZSBzZWVtcyBsaWtlIG5vbiBpc3N1ZSB0 byBtZSBmb3IgdGhpcyBkcmFmdC4NCg0KQSBub24taXNzdWUgdW5sZXNzIHRoZSBzaXplIG9mIGEg c2luZ2xlIE5MUkkgYW5kIGl0cyBhdHRyaWJ1dGVzIGV4Y2VlZHMgNEsuDQpUaGFua3MsDQpBY2Vl DQoNCg0KDQrigIsNCuKAi0Jlc3QsDQpSLg0KDQpGb3IgdGhlIGRyYWZ0IGl0c2VsZjogU3VwcG9y dCDigItmcm9tIG1lLg0KDQoNCg0KDQo= --_000_D36B14064080Ekeyupateciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5Db21tZW50cyBp bmxpbmVkICNLZXl1cjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JD X0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNp emU6MTFwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVk aXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsg UEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRk ZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj4mcXVvdDtBY2Vl IExpbmRlbSAoYWNlZSkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzphY2VlQGNpc2NvLmNvbSI+ YWNlZUBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk Ij5EYXRlOiA8L3NwYW4+V2VkbmVzZGF5LCBNYXkgMjUsIDIwMTYgYXQgNzoyOSBBTTxicj4NCjxz cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPlJvYmVydCBSYXN6dWsgJmx0 OzxhIGhyZWY9Im1haWx0bzpyb2JlcnRAcmFzenVrLm5ldCI+cm9iZXJ0QHJhc3p1ay5uZXQ8L2E+ Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPkJydW5v IERlY3JhZW5lICZsdDs8YSBocmVmPSJtYWlsdG86YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbSI+ YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTwvYT4mZ3Q7LCBLZXl1ciBQYXRlbCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmtleXVwYXRlQGNpc2NvLmNvbSI+a2V5dXBhdGVAY2lzY28uY29tPC9hPiZndDss ICZxdW90OzxhIGhyZWY9Im1haWx0bzppZHJAaWV0Zi5vcmciPmlkckBpZXRmLm9yZzwvYT4mcXVv dDsgJmx0OzxhIGhyZWY9Im1haWx0bzppZHJAaWV0Zi5vcmciPmlkckBpZXRmLm9yZzwvYT4mZ3Q7 LA0KIFN1c2FuIEhhcmVzICZsdDs8YSBocmVmPSJtYWlsdG86c2hhcmVzQG5kemguY29tIj5zaGFy ZXNAbmR6aC5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5T dWJqZWN0OiA8L3NwYW4+UmU6IFtJZHJdIGRyYWZ0LWlldGYtaWRyLWJncC1leHRlbmRlZC1tZXNz YWdlcy0xMiBXRyBMQyAoNS8yNCB0byA2LzcpPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNw LW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyBjb2xv cjogcmdiKDAsIDAsIDApOyBmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyI+DQo8ZGl2PkhpIFJvYmVydCwmbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1m YW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6Ymxh Y2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7 IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAw aW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBu b25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5G cm9tOiA8L3NwYW4+Jmx0OzxhIGhyZWY9Im1haWx0bzpycmFzenVrQGdtYWlsLmNvbSI+cnJhc3p1 a0BnbWFpbC5jb208L2E+Jmd0OyBvbiBiZWhhbGYgb2YgUm9iZXJ0IFJhc3p1ayAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnJvYmVydEByYXN6dWsubmV0Ij5yb2JlcnRAcmFzenVrLm5ldDwvYT4mZ3Q7PGJy Pg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5XZWRuZXNkYXks IE1heSAyNSwgMjAxNiBhdCA3OjUwIEFNPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJv bGQiPlRvOiA8L3NwYW4+QWNlZSBMaW5kZW0gJmx0OzxhIGhyZWY9Im1haWx0bzphY2VlQGNpc2Nv LmNvbSI+YWNlZUBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdo dDpib2xkIj5DYzogPC9zcGFuPkJydW5vIERlY3JhZW5lICZsdDs8YSBocmVmPSJtYWlsdG86YnJ1 bm8uZGVjcmFlbmVAb3JhbmdlLmNvbSI+YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTwvYT4mZ3Q7 LCAmcXVvdDtLZXl1ciBQYXRlbCAoa2V5dXBhdGUpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 a2V5dXBhdGVAY2lzY28uY29tIj5rZXl1cGF0ZUBjaXNjby5jb208L2E+Jmd0OywgSURSIExpc3Qg Jmx0OzxhIGhyZWY9Im1haWx0bzppZHJAaWV0Zi5vcmciPmlkckBpZXRmLm9yZzwvYT4mZ3Q7LA0K IFN1c2FuIEhhcmVzICZsdDs8YSBocmVmPSJtYWlsdG86c2hhcmVzQG5kemguY29tIj5zaGFyZXNA bmR6aC5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJq ZWN0OiA8L3NwYW4+UmU6IFtJZHJdIGRyYWZ0LWlldGYtaWRyLWJncC1leHRlbmRlZC1tZXNzYWdl cy0xMiBXRyBMQyAoNS8yNCB0byA2LzcpPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxl PSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjow IDAgMCA1OyI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdiBjbGFzcz0iZ21h aWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlm O2ZvbnQtc2l6ZTpzbWFsbCI+DQpIaSBBQyw8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1 bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNp emU6c21hbGwiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHls ZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxs Ij4NClllcyBpbmRlZWQgLSB5b3UgYXJlIHJpZ2h0IC0gSSB3YXMgYSBiaXQgaGl0IHdpdGggJnF1 b3Q7cmVsYXkmcXVvdDsgdGVybSA6KS4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2Rl ZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250 LXNpemU6c21hbGwiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBz dHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNt YWxsIj4NCkFuZCBzaW5jZSB0aGlzIGVudGlyZSB3b3JrIHN0YXJ0ZWQgd2l0aCB0aGUgYXNzdW1w dGlvbiB0aGF0IHBhY2tpbmcgcGVyIE5MUkkgd2lsbCBiZSBicm9rZW4gYW55d2F5IG9uZSBjb3Vs ZCBleHBlY3QgdGhpcyB0byBiZSBhbHdheXMgdGhlIGNhc2UuJm5ic3A7PC9kaXY+DQo8ZGl2IGNs YXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNh bnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21h aWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlm O2ZvbnQtc2l6ZTpzbWFsbCI+DQpTbyBpdCBkb2VzIGxvb2sgbGlrZSBhIGJpdCBvZiBzaG93IHN0 b3BwZXIgdG8gbWUgdW5sZXNzIHdlIGVuZm9yY2UgdGhhdCBpZiB0aGVyZSBpcyBhdCBsZWFzdCBv bmUgQkdQIHBlZXIgb24gZ2l2ZW4gQkdQIHNwZWFrZXIgbm90IHN1cHBvcnRpbmcgNjRLIGFsbCBz ZXNzaW9ucyB3aWxsIGdldCByZXNldCB0byA0SyBtYXguIFVnbHkgYnV0IG5vdCBzdXJlIHdoYXQg b3RoZXIgb3B0aW9ucyBjYW4gYWRkcmVzcyBpdC4gUGVyaGFwcyBhdXRob3JzIHdpbGwNCiBjb21l IHVwIHdpdGggYmV0dGVyIG9uZS4mbmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlNpbmNlIHRo aXMgaXMgbGlrZWx5IHRvIGJlIGFuIGV4dHJlbWVseSByYXJlIG9jY3VycmVuY2UsIEnigJlkIHNp bXBseSBub3QgYWR2ZXJ0aXNlIHRoZSBOTFJJIHRvIGEgcGVlciBub3Qgc3VwcG9ydGluZyBleHRl bmRlZCBtZXNzYWdlcyBhbmQgbG9nIHRoZSBlcnJvci4gJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj5BZGRpdGlvbmFsbHksIHdlIGNvdWxkIGRpc2NvdXJhZ2UgdGhlIGdlbmVy YXRpb24gb2YgYSBzaW5nbGUgTkxSSSBleGNlZWRpbmcgNEsuJm5ic3A7PC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+I0tleXVyOiBZZXAuIEkg YWdyZWUuIDopPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5SZWdhcmRzLDwvZGl2Pg0K PGRpdj5LZXl1cjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JP RFlfU0VDVElPTiI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAt d2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUt c3BhY2U7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoYW5rcyw8 L2Rpdj4NCjxkaXY+QWNlZSZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGJsb2NrcXVvdGUg aWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVG VDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIg c3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpz bWFsbCI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJm b250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0K VGh4LDwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5 OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQpSLjwvZGl2Pg0K PGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZl dGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fu cy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9ImdtYWlsX2V4dHJhIj48YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gV2VkLCBN YXkgMjUsIDIwMTYgYXQgMTo0MSBQTSwgQWNlZSBMaW5kZW0gKGFjZWUpIDxzcGFuIGRpcj0ibHRy Ij4NCiZsdDs8YSBocmVmPSJtYWlsdG86YWNlZUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5h Y2VlQGNpc2NvLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+DQo8YmxvY2txdW90ZSBjbGFz cz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHgg I2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDpicmVh ay13b3JkO2NvbG9yOnJnYigwLDAsMCk7Zm9udC1zaXplOjE0cHg7Zm9udC1mYW1pbHk6Q2FsaWJy aSxzYW5zLXNlcmlmIj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNw YW4+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2ZvbnQtc2l6ZToxMXB0O3RleHQt YWxpZ246bGVmdDtjb2xvcjpibGFjaztCT1JERVItQk9UVE9NOm1lZGl1bSBub25lO0JPUkRFUi1M RUZUOm1lZGl1bSBub25lO1BBRERJTkctQk9UVE9NOjBpbjtQQURESU5HLUxFRlQ6MGluO1BBRERJ TkctUklHSFQ6MGluO0JPUkRFUi1UT1A6I2I1YzRkZiAxcHQgc29saWQ7Qk9SREVSLVJJR0hUOm1l ZGl1bSBub25lO1BBRERJTkctVE9QOjNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9s ZCI+RnJvbTogPC9zcGFuPklkciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlkci1ib3VuY2VzQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+aWRyLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhh bGYgb2YgUm9iZXJ0IFJhc3p1ayAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvYmVydEByYXN6dWsubmV0 IiB0YXJnZXQ9Il9ibGFuayI+cm9iZXJ0QHJhc3p1ay5uZXQ8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0 eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+V2VkbmVzZGF5LCBNYXkgMjUsIDIw MTYgYXQgNjozNCBBTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9z cGFuPkJydW5vIERlY3JhZW5lICZsdDs8YSBocmVmPSJtYWlsdG86YnJ1bm8uZGVjcmFlbmVAb3Jh bmdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208L2E+Jmd0 Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPiZxdW90O0tl eXVyIFBhdGVsIChrZXl1cGF0ZSkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzprZXl1cGF0ZUBj aXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5rZXl1cGF0ZUBjaXNjby5jb208L2E+Jmd0OywgSURS IExpc3QgJmx0OzxhIGhyZWY9Im1haWx0bzppZHJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5p ZHJAaWV0Zi5vcmc8L2E+Jmd0OywgU3VzYW4gSGFyZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpzaGFy ZXNAbmR6aC5jb20iIHRhcmdldD0iX2JsYW5rIj5zaGFyZXNAbmR6aC5jb208L2E+Jmd0Ozxicj4N CjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFtJZHJd IGRyYWZ0LWlldGYtaWRyLWJncC1leHRlbmRlZC1tZXNzYWdlcy0xMiBXRyBMQyAoNS8yNCB0byA2 LzcpPGJyPg0KPC9kaXY+DQo8c3BhbiBjbGFzcz0iIj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iQk9SREVSLUxFRlQ6I2I1YzRkZiA1IHNvbGlkO1BBRERJTkc6MCAwIDAg NTtNQVJHSU46MCAwIDAgNSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdiBj bGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxz YW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQpIaSBCcnVubyw8L2Rpdj4NCjxkaXYgY2xhc3M9 ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1z ZXJpZjtmb250LXNpemU6c21hbGwiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9l eHRyYSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21h aWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBz b2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgbGFuZz0iRlIiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdj4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPlN1cHBvc2UgdGhhdCBJ IHJlY2VpdmUgYW4gZXh0ZW5kZWQgQkdQIG1lc3NhZ2UgKGUuZy4gdXBkYXRlKSB0aGF0IEkgY2Fu 4oCZdCByZWxheSA8L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7 Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGxhbmc9 IkZSIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXY+DQo8cHJlPjxzcGFuIGxhbmc9 IkVOLVVTIj50byBzb21lIHBlZXJzIGJlY2F1c2UgdGhleSBkb27igJl0IHN1cHBvcnQgc3VjaCBl eHRlbnNpb24sIHdoaWxlIEkg4oCcc2hvdWxk4oCdIGhhdmUgPC9zcGFuPjwvcHJlPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIg c3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRp bmctbGVmdDoxZXgiPg0KPGRpdiBsYW5nPSJGUiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+cmVsYXllZCBpdC4gPC9zcGFuPjwvcHJl Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhl bHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQrigItCR1AgZG9lcyBub3QgJnF1 b3Q7cmVsYXkmcXVvdDsgbWVzc2FnZXMgLi4gZG8geW91IGhhdmUgc29tZSBuZXcgQkdQIGRyYWZ0 IGluIG1pbmQgd2hpY2ggd291bGQgd29yayBhcyBCR1AgJnF1b3Q7cmVwZWF0ZXImcXVvdDsgPyBX aGlsZSBJIHJlY2FsbCB3ZSBkaXNjdXNzZWQgaXQgaW4gdGhlIHBhc3QgdGhhdCB3b3JrIHdlcmUg cHJldHR5IG11Y2ggYWJhbmRvbmVkIDopPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0 IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXpl OnNtYWxsIj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9 ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+ DQpCR1AgZ2VuZXJhdGVzIG1lc3NhZ2VzIGF0IGVhY2ggQkdQIHNwZWFrZXIgc28gdGhlIGFib3Zl IHNlZW1zIGxpa2Ugbm9uIGlzc3VlIHRvIG1lIGZvciB0aGlzIGRyYWZ0LiZuYnNwOzwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9zcGFuPjwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkEgbm9uLWlzc3Vl IHVubGVzcyB0aGUgc2l6ZSBvZiBhIHNpbmdsZSBOTFJJIGFuZCBpdHMgYXR0cmlidXRlcyBleGNl ZWRzIDRLLiZuYnNwOzwvZGl2Pg0KPGRpdj5UaGFua3MsPC9kaXY+DQo8ZGl2PkFjZWUmbmJzcDs8 L2Rpdj4NCjxzcGFuIGNsYXNzPSIiPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8c3Bhbj4NCjxibG9ja3F1b3RlIHN0eWxlPSJCT1JERVItTEVGVDojYjVjNGRmIDUgc29s aWQ7UEFERElORzowIDAgMCA1O01BUkdJTjowIDAgMCA1Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBk aXI9Imx0ciI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9x dW90ZSI+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFt aWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQo8YnI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlh bCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0K4oCLPC9kaXY+DQo8ZGl2 IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNh LHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCuKAi0Jlc3QsPGJyPg0KUi48L2Rpdj4NCjxk aXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRp Y2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMt c2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCkZvciB0aGUgZHJhZnQgaXRzZWxmOiBTdXBwb3J0IOKA i2Zyb20gbWUuJm5ic3A7PGJyPg0KPC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj48L3NwYW4+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv c3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D36B14064080Ekeyupateciscocom_-- From nobody Wed May 25 08:48:20 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA2C912D7A2 for ; Wed, 25 May 2016 08:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHE7E0JCyzDl for ; Wed, 25 May 2016 08:48:16 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85CCF12D7BB for ; Wed, 25 May 2016 08:48:15 -0700 (PDT) Received: by mail-lb0-x22f.google.com with SMTP id h1so16477172lbj.3 for ; Wed, 25 May 2016 08:48:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=3NlwTQ96a6JWn7V3u2CFtpSY9lRyynbtzbZQ/VfVEiU=; b=Cv+ttLZVAt5wIFx1ZKelLv1ywUNm9HLKLYdO74h2U4VUyEQZ3amPXbRaeYJ7msrzpL sehwO/jwH9tg4+Ter9dIlKlBlr4PP2N4b72RIiyV+qYbfHN64M/xaIR4qiOGQAoXNj5P zZLFee0ISgItVUZYtwVJsQ4L+b+c/2vWRMqiT66TWBQOEzStptGVkgssHg4exqpR0Ak3 XvYbCT/xAZEokFzPGKx9H9BJUvuxh5oUDvhXlrka1KCHC4H1FFSgFrgNsrRzT04Nnwww tQUoFjaHnSinGM9KQBox9f8pW6JzqNeuPwWamdjYn9OACsPaBi26cikGnHji1ohXdMyE KnzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=3NlwTQ96a6JWn7V3u2CFtpSY9lRyynbtzbZQ/VfVEiU=; b=AxFKeIRbnnYwjwHcjcY+fEsNuXXxTvk5qOmR0YXlpUDCAFPOjZmElyEbXYpRL6me1X DnWK9alz6CqgNn2veWWEUgTCfweMOLA7bIEzCFQqZn7V7BBCs7BxXVb490GvNfMz6Tdo UJkZ+KItD33yQvtqSHp74XigEmdrDfyrrz6zlkSIzTDax/BxCsH4Emq5+KY5C6bJsFVh Kgsrii049oDBGPVXNd6KenjAWqyy8QVyOJwOOtCO6RqAkRoPVO0FrLMDQRFA86dyPSbJ 1GNDButfrUg2Ze1SMcmSQgTryxCnvlpi9MYIKNSMv/N6Vvvc3n56TCD+eOlzacW4yWpq T6Sg== X-Gm-Message-State: ALyK8tIm6ItfFricU2474S7hrzKvH2fsIqM15PrgDUbiSa2tye0vA1SZs124RZ2D+M1Df2xg2BB4GJBEZD/raw== MIME-Version: 1.0 X-Received: by 10.112.171.229 with SMTP id ax5mr1438444lbc.115.1464191293711; Wed, 25 May 2016 08:48:13 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.25.134.196 with HTTP; Wed, 25 May 2016 08:48:13 -0700 (PDT) In-Reply-To: References: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> <13146_1464170675_574578B3_13146_4888_1_53C29892C857584299CBF5D05346208A0F8CD227@OPEXCLILM21.corporate.adroot.infra.ftgroup> Date: Wed, 25 May 2016 17:48:13 +0200 X-Google-Sender-Auth: NYtxiwggjtTT47gKUPcf3Jy3m7c Message-ID: From: Robert Raszuk To: "Keyur Patel (keyupate)" , "Acee Lindem (acee)" Content-Type: multipart/alternative; boundary=001a11c36ed6f1ef160533ac99c1 Archived-At: Cc: Bruno Decraene , Susan Hares , "idr@ietf.org" Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 15:48:18 -0000 --001a11c36ed6f1ef160533ac99c1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > Additionally, we could discourage the generation of a single NLRI > exceeding 4K. > > #Keyur: Yep. I agree. :) > =E2=80=8BThe entire idea for this draft was triggered by the fear that BGPS= ec may not fit to 4K update msg. The draft explicitly states so as a motivation for this work. Section 1 "As BGP is extended to support newer AFI/SAFIs and newer capabilities (e.g., [I-D.ietf-sidr-bgpsec-overview]), there is a need to extend the maximum message size beyond 4096 octets." =E2=80=8BNow in turn the referenced draft clearly defines that NLRI will on= ly contain single prefix: Section 3.2 "When a BGP speaker originates a BGPsec update message, it creates a BGPsec_Path attribute containing a single signature. The signature protects the Network Layer Reachability Information (NLRI), the AS number of the originating AS, and the AS number of the peer AS to whom the update message is being sent. Note that the NLRI in a BGPsec update message is restricted to contain only a single prefix." Question: =E2=80=8BSo what exactly are we to discourage here because clearly not "gen= eration of single NLRI exceeding 4K" ? Maybe deployment of BGPSec till all BGP routers in the world support this new extended message size ? Thx, R. =E2=80=8B --001a11c36ed6f1ef160533ac99c1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=C2=A0
Additionally, we could discourage the g= eneration of a single NLRI exceeding 4K.=C2=A0

#Keyur: Yep. I agree. :)

=E2=80= =8BThe entire idea for this draft was triggered by the fear that BGPSec may= not fit to 4K update msg.=C2=A0

The draft explicitly states so as a motivation for this work.=C2= =A0

Section 1

= =C2=A0 =C2=A0"As BGP is extended to support newer AFI/SAFIs and newer = capabilities (e.g.,
=C2=A0 =C2=A0[I-D.iet= f-sidr-bgpsec-overview]), there is a need to extend the maximum message=C2= =A0
=C2=A0 =C2=A0size beyond 4096 octets.= "

=E2=80=8B= Now in turn the referenced draft clearly defines that NLRI will only contai= n single prefix:=C2=A0

Section 3.2

=C2=A0 =C2=A0"When a BGP speaker originates a BGPs= ec update message, it creates a
=C2=A0 = =C2=A0BGPsec_Path attribute containing a single signature. The signature
=C2=A0 =C2=A0protects the Network Layer Rea= chability Information (NLRI), the AS
=C2= =A0 =C2=A0number of the originating AS, and the AS number of the peer AS to=
=C2=A0 =C2=A0whom the update message is = being sent. Note that the NLRI in a BGPsec
=C2=A0 =C2=A0update message is restricted to contain only a single prefix= ."

Question:

=E2=80=8BSo what exactly are we to= discourage here because clearly not "generation of single NLRI exceed= ing 4K" ?=C2=A0

M= aybe deployment of BGPSec till all BGP routers in the world support this ne= w extended message size ?=C2=A0

Thx,
R.
=E2=80=8B=
--001a11c36ed6f1ef160533ac99c1-- From nobody Wed May 25 08:51:13 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2214D12D7F7 for ; Wed, 25 May 2016 08:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2cgxv4vbU_Y for ; Wed, 25 May 2016 08:51:10 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0F0612B015 for ; Wed, 25 May 2016 08:51:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11969; q=dns/txt; s=iport; t=1464191463; x=1465401063; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9+eleZYXT4ZNnUEcoawNnvdnSacMsq5jU2nYYyfmMZ4=; b=WEOicrmqWuF+gqDOkDvPq/rhN/86pofVHZYESyjcx122CBn+OsdIvdIW EMdZltiiweQPA5Xd7JfG1gBSEl2620bAHoXqz8YU1zB11NOBJ/2zb1OVC LNLMPYHQC7Rqny3vuqCZP5IhQ48ntZOYX1JW8IdPTJdcXBwlJroJNn9Oi Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BAAgCMyEVX/5pdJa1cgmxLgVMGtHiEe?= =?us-ascii?q?QENgXeGEQIcgSU4FAEBAQEBAQFlJ4RDAQEBBCNWEAIBCBEDAQIoAwICAjAUCQg?= =?us-ascii?q?CBAENBYgvskKRbAEBAQEBAQEBAQEBAQEBAQEBAQEBARyGJ4RMhF+CYYJZBZg3A?= =?us-ascii?q?Y4fgWmNM4YziRgBHgEBQoNtbokIfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,364,1459814400"; d="scan'208,217";a="276960058" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 May 2016 15:51:02 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u4PFp291009183 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 25 May 2016 15:51:02 GMT Received: from xch-rtp-017.cisco.com (64.101.220.157) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 25 May 2016 11:51:01 -0400 Received: from xch-rtp-017.cisco.com ([64.101.220.157]) by XCH-RTP-017.cisco.com ([64.101.220.157]) with mapi id 15.00.1104.009; Wed, 25 May 2016 11:51:01 -0400 From: "Keyur Patel (keyupate)" To: Robert Raszuk , "Acee Lindem (acee)" Thread-Topic: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) Thread-Index: AQHRtp08K/E7XomEXUSbCzMdYMvGjQ== Date: Wed, 25 May 2016 15:51:01 +0000 Message-ID: References: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> <13146_1464170675_574578B3_13146_4888_1_53C29892C857584299CBF5D05346208A0F8CD227@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.6.18] Content-Type: multipart/alternative; boundary="_000_D36B17B740835keyupateciscocom_" MIME-Version: 1.0 Archived-At: Cc: Bruno Decraene , Susan Hares , "idr@ietf.org" Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 15:51:12 -0000 --_000_D36B17B740835keyupateciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KDQpJIHRob3VnaHQgdGhlIGNvbnRleHQgb2YgdGhhdCBsaW5lIOKAnG5vdCBn ZW5lcmF0aW5nIHNpbmdsZSBOTFJJIGlmIGF0dHJpYnV0ZXMgZXhjZWVkIDRL4oCdIHdhcyBmb3Ig cGVlcnMgbm90IHN1cHBvcnRpbmcgZXh0ZW5kZWQgbWVzc2FnZXMuDQoNCk90aGVyd2lzZSBpdHMg YSBtb290IHBvaW50LiA6KQ0KUmVnYXJkcywNCktleXVyDQoNCkZyb206IFJvYmVydCBSYXN6dWsg PHJvYmVydEByYXN6dWsubmV0PG1haWx0bzpyb2JlcnRAcmFzenVrLm5ldD4+DQpEYXRlOiBXZWRu ZXNkYXksIE1heSAyNSwgMjAxNiBhdCA4OjQ4IEFNDQpUbzogS2V5dXIgUGF0ZWwgPGtleXVwYXRl QGNpc2NvLmNvbTxtYWlsdG86a2V5dXBhdGVAY2lzY28uY29tPj4sICJBY2VlIExpbmRlbSAoYWNl ZSkiIDxhY2VlQGNpc2NvLmNvbTxtYWlsdG86YWNlZUBjaXNjby5jb20+Pg0KQ2M6IEJydW5vIERl Y3JhZW5lIDxicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPG1haWx0bzpicnVuby5kZWNyYWVuZUBv cmFuZ2UuY29tPj4sICJpZHJAaWV0Zi5vcmc8bWFpbHRvOmlkckBpZXRmLm9yZz4iIDxpZHJAaWV0 Zi5vcmc8bWFpbHRvOmlkckBpZXRmLm9yZz4+LCBTdXNhbiBIYXJlcyA8c2hhcmVzQG5kemguY29t PG1haWx0bzpzaGFyZXNAbmR6aC5jb20+Pg0KU3ViamVjdDogUmU6IFtJZHJdIGRyYWZ0LWlldGYt aWRyLWJncC1leHRlbmRlZC1tZXNzYWdlcy0xMiBXRyBMQyAoNS8yNCB0byA2LzcpDQoNCg0KQWRk aXRpb25hbGx5LCB3ZSBjb3VsZCBkaXNjb3VyYWdlIHRoZSBnZW5lcmF0aW9uIG9mIGEgc2luZ2xl IE5MUkkgZXhjZWVkaW5nIDRLLg0KDQojS2V5dXI6IFllcC4gSSBhZ3JlZS4gOikNCg0K4oCLVGhl IGVudGlyZSBpZGVhIGZvciB0aGlzIGRyYWZ0IHdhcyB0cmlnZ2VyZWQgYnkgdGhlIGZlYXIgdGhh dCBCR1BTZWMgbWF5IG5vdCBmaXQgdG8gNEsgdXBkYXRlIG1zZy4NCg0KVGhlIGRyYWZ0IGV4cGxp Y2l0bHkgc3RhdGVzIHNvIGFzIGEgbW90aXZhdGlvbiBmb3IgdGhpcyB3b3JrLg0KDQpTZWN0aW9u IDENCg0KICAgIkFzIEJHUCBpcyBleHRlbmRlZCB0byBzdXBwb3J0IG5ld2VyIEFGSS9TQUZJcyBh bmQgbmV3ZXIgY2FwYWJpbGl0aWVzIChlLmcuLA0KICAgW0ktRC5pZXRmLXNpZHItYmdwc2VjLW92 ZXJ2aWV3XSksIHRoZXJlIGlzIGEgbmVlZCB0byBleHRlbmQgdGhlIG1heGltdW0gbWVzc2FnZQ0K ICAgc2l6ZSBiZXlvbmQgNDA5NiBvY3RldHMuIg0KDQrigItOb3cgaW4gdHVybiB0aGUgcmVmZXJl bmNlZCBkcmFmdCBjbGVhcmx5IGRlZmluZXMgdGhhdCBOTFJJIHdpbGwgb25seSBjb250YWluIHNp bmdsZSBwcmVmaXg6DQoNClNlY3Rpb24gMy4yDQoNCiAgICJXaGVuIGEgQkdQIHNwZWFrZXIgb3Jp Z2luYXRlcyBhIEJHUHNlYyB1cGRhdGUgbWVzc2FnZSwgaXQgY3JlYXRlcyBhDQogICBCR1BzZWNf UGF0aCBhdHRyaWJ1dGUgY29udGFpbmluZyBhIHNpbmdsZSBzaWduYXR1cmUuIFRoZSBzaWduYXR1 cmUNCiAgIHByb3RlY3RzIHRoZSBOZXR3b3JrIExheWVyIFJlYWNoYWJpbGl0eSBJbmZvcm1hdGlv biAoTkxSSSksIHRoZSBBUw0KICAgbnVtYmVyIG9mIHRoZSBvcmlnaW5hdGluZyBBUywgYW5kIHRo ZSBBUyBudW1iZXIgb2YgdGhlIHBlZXIgQVMgdG8NCiAgIHdob20gdGhlIHVwZGF0ZSBtZXNzYWdl IGlzIGJlaW5nIHNlbnQuIE5vdGUgdGhhdCB0aGUgTkxSSSBpbiBhIEJHUHNlYw0KICAgdXBkYXRl IG1lc3NhZ2UgaXMgcmVzdHJpY3RlZCB0byBjb250YWluIG9ubHkgYSBzaW5nbGUgcHJlZml4LiIN Cg0KUXVlc3Rpb246DQoNCuKAi1NvIHdoYXQgZXhhY3RseSBhcmUgd2UgdG8gZGlzY291cmFnZSBo ZXJlIGJlY2F1c2UgY2xlYXJseSBub3QgImdlbmVyYXRpb24gb2Ygc2luZ2xlIE5MUkkgZXhjZWVk aW5nIDRLIiA/DQoNCk1heWJlIGRlcGxveW1lbnQgb2YgQkdQU2VjIHRpbGwgYWxsIEJHUCByb3V0 ZXJzIGluIHRoZSB3b3JsZCBzdXBwb3J0IHRoaXMgbmV3IGV4dGVuZGVkIG1lc3NhZ2Ugc2l6ZSA/ DQoNClRoeCwNClIuDQrigIsNCg== --_000_D36B17B740835keyupateciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSBSb2JlcnQs PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JIHRob3VnaHQgdGhlIGNvbnRleHQgb2Yg dGhhdCBsaW5lIOKAnG5vdCBnZW5lcmF0aW5nIHNpbmdsZSBOTFJJIGlmIGF0dHJpYnV0ZXMgZXhj ZWVkIDRL4oCdIHdhcyBmb3IgcGVlcnMgbm90IHN1cHBvcnRpbmcgZXh0ZW5kZWQgbWVzc2FnZXMu PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5PdGhlcndpc2UgaXRzIGEgbW9vdCBwb2lu dC4gOik8L2Rpdj4NCjxkaXY+UmVnYXJkcyw8L2Rpdj4NCjxkaXY+S2V5dXI8L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHls ZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsg Y29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVk aXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5H LVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6 IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdo dDpib2xkIj5Gcm9tOiA8L3NwYW4+Um9iZXJ0IFJhc3p1ayAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJv YmVydEByYXN6dWsubmV0Ij5yb2JlcnRAcmFzenVrLm5ldDwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5 bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5XZWRuZXNkYXksIE1heSAyNSwgMjAx NiBhdCA4OjQ4IEFNPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3Nw YW4+S2V5dXIgUGF0ZWwgJmx0OzxhIGhyZWY9Im1haWx0bzprZXl1cGF0ZUBjaXNjby5jb20iPmtl eXVwYXRlQGNpc2NvLmNvbTwvYT4mZ3Q7LCAmcXVvdDtBY2VlIExpbmRlbSAoYWNlZSkmcXVvdDsg Jmx0OzxhIGhyZWY9Im1haWx0bzphY2VlQGNpc2NvLmNvbSI+YWNlZUBjaXNjby5jb208L2E+Jmd0 Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPkJydW5vIERl Y3JhZW5lICZsdDs8YSBocmVmPSJtYWlsdG86YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbSI+YnJ1 bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86aWRy QGlldGYub3JnIj5pZHJAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86aWRy QGlldGYub3JnIj5pZHJAaWV0Zi5vcmc8L2E+Jmd0OywgU3VzYW4gSGFyZXMgJmx0OzxhIGhyZWY9 Im1haWx0bzpzaGFyZXNAbmR6aC5jb20iPnNoYXJlc0BuZHpoLmNvbTwvYT4mZ3Q7PGJyPg0KPHNw YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogW0lkcl0gZHJh ZnQtaWV0Zi1pZHItYmdwLWV4dGVuZGVkLW1lc3NhZ2VzLTEyIFdHIExDICg1LzI0IHRvIDYvNyk8 YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJs dHIiPg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUi Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5 bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDtib3JkZXItbGVmdC13aWR0aDoxcHg7Ym9yZGVy LWxlZnQtc3R5bGU6c29saWQ7Ym9yZGVyLWxlZnQtY29sb3I6cmdiKDIwNCwyMDQsMjA0KTtwYWRk aW5nLWxlZnQ6MWV4Ij4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkO2NvbG9yOnJn YigwLDAsMCk7Zm9udC1zaXplOjE0cHg7Zm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmIj4N CjxzcGFuPjxzcGFuIGNsYXNzPSIiPg0KPGRpdj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDpicmVh ay13b3JkO2NvbG9yOnJnYigwLDAsMCk7Zm9udC1zaXplOjE0cHg7Zm9udC1mYW1pbHk6Q2FsaWJy aSxzYW5zLXNlcmlmIj4NCjxkaXY+QWRkaXRpb25hbGx5LCB3ZSBjb3VsZCBkaXNjb3VyYWdlIHRo ZSBnZW5lcmF0aW9uIG9mIGEgc2luZ2xlIE5MUkkgZXhjZWVkaW5nIDRLLiZuYnNwOzxicj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj48L3NwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGRpdj4jS2V5dXI6IFllcC4gSSBhZ3JlZS4gOik8L2Rpdj4NCjxkaXY+PC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iZ21h aWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlm O2ZvbnQtc2l6ZTpzbWFsbCI+DQrigItUaGUgZW50aXJlIGlkZWEgZm9yIHRoaXMgZHJhZnQgd2Fz IHRyaWdnZXJlZCBieSB0aGUgZmVhciB0aGF0IEJHUFNlYyBtYXkgbm90IGZpdCB0byA0SyB1cGRh dGUgbXNnLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZv bnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQo8 YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWls eTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KVGhlIGRyYWZ0 IGV4cGxpY2l0bHkgc3RhdGVzIHNvIGFzIGEgbW90aXZhdGlvbiBmb3IgdGhpcyB3b3JrLiZuYnNw OzwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFy aWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQo8YnI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2 ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KU2VjdGlvbiAxPC9kaXY+DQo8ZGl2 IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNh LHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Z21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNl cmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0Ij4mbmJzcDsg Jm5ic3A7JnF1b3Q7QXMgQkdQIGlzIGV4dGVuZGVkIHRvIHN1cHBvcnQgbmV3ZXIgQUZJL1NBRklz IGFuZCBuZXdlciBjYXBhYmlsaXRpZXMgKGUuZy4sPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9k ZWZhdWx0Ij4mbmJzcDsgJm5ic3A7W0ktRC5pZXRmLXNpZHItYmdwc2VjLW92ZXJ2aWV3XSksIHRo ZXJlIGlzIGEgbmVlZCB0byBleHRlbmQgdGhlIG1heGltdW0gbWVzc2FnZSZuYnNwOzwvZGl2Pg0K PGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCI+Jm5ic3A7ICZuYnNwO3NpemUgYmV5b25kIDQwOTYg b2N0ZXRzLiZxdW90OzwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBz dHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNt YWxsIj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZv bnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQri gItOb3cgaW4gdHVybiB0aGUgcmVmZXJlbmNlZCBkcmFmdCBjbGVhcmx5IGRlZmluZXMgdGhhdCBO TFJJIHdpbGwgb25seSBjb250YWluIHNpbmdsZSBwcmVmaXg6Jm5ic3A7PC9kaXY+DQo8ZGl2IGNs YXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNh bnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21h aWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlm O2ZvbnQtc2l6ZTpzbWFsbCI+DQpTZWN0aW9uIDMuMjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxf ZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2Zv bnQtc2l6ZTpzbWFsbCI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQi IHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6 c21hbGwiPg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCI+Jm5ic3A7ICZuYnNwOyZxdW90O1do ZW4gYSBCR1Agc3BlYWtlciBvcmlnaW5hdGVzIGEgQkdQc2VjIHVwZGF0ZSBtZXNzYWdlLCBpdCBj cmVhdGVzIGE8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiPiZuYnNwOyAmbmJzcDtC R1BzZWNfUGF0aCBhdHRyaWJ1dGUgY29udGFpbmluZyBhIHNpbmdsZSBzaWduYXR1cmUuIFRoZSBz aWduYXR1cmU8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiPiZuYnNwOyAmbmJzcDtw cm90ZWN0cyB0aGUgTmV0d29yayBMYXllciBSZWFjaGFiaWxpdHkgSW5mb3JtYXRpb24gKE5MUkkp LCB0aGUgQVM8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiPiZuYnNwOyAmbmJzcDtu dW1iZXIgb2YgdGhlIG9yaWdpbmF0aW5nIEFTLCBhbmQgdGhlIEFTIG51bWJlciBvZiB0aGUgcGVl ciBBUyB0bzwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCI+Jm5ic3A7ICZuYnNwO3do b20gdGhlIHVwZGF0ZSBtZXNzYWdlIGlzIGJlaW5nIHNlbnQuIE5vdGUgdGhhdCB0aGUgTkxSSSBp biBhIEJHUHNlYzwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCI+Jm5ic3A7ICZuYnNw O3VwZGF0ZSBtZXNzYWdlIGlzIHJlc3RyaWN0ZWQgdG8gY29udGFpbiBvbmx5IGEgc2luZ2xlIHBy ZWZpeC4mcXVvdDs8L2Rpdj4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFz cz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5z LXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQpRdWVzdGlvbjo8L2Rpdj4NCjxkaXYgY2xhc3M9Imdt YWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJp Zjtmb250LXNpemU6c21hbGwiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZh dWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1z aXplOnNtYWxsIj4NCuKAi1NvIHdoYXQgZXhhY3RseSBhcmUgd2UgdG8gZGlzY291cmFnZSBoZXJl IGJlY2F1c2UgY2xlYXJseSBub3QgJnF1b3Q7Z2VuZXJhdGlvbiBvZiBzaW5nbGUgTkxSSSBleGNl ZWRpbmcgNEsmcXVvdDsgPyZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIg c3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpz bWFsbCI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJm b250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0K TWF5YmUgZGVwbG95bWVudCBvZiBCR1BTZWMgdGlsbCBhbGwgQkdQIHJvdXRlcnMgaW4gdGhlIHdv cmxkIHN1cHBvcnQgdGhpcyBuZXcgZXh0ZW5kZWQgbWVzc2FnZSBzaXplID8mbmJzcDs8L2Rpdj4N CjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2 ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNh bnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NClRoeCw8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWls X2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtm b250LXNpemU6c21hbGwiPg0KUi48L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0 eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21h bGwiPg0K4oCLPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D36B17B740835keyupateciscocom_-- From nobody Wed May 25 08:54:52 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A64A812D561 for ; Wed, 25 May 2016 08:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jERCe4MgKj48 for ; Wed, 25 May 2016 08:54:48 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2A3712B015 for ; Wed, 25 May 2016 08:54:47 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id e130so20116820lfe.3 for ; Wed, 25 May 2016 08:54:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=9u0t5BTrruukpGc9GKTUEAAKqN+zVa6SHjsDdDS2FUc=; b=PxY5e7OZ0OSjD2e5535wwBP5ERiTBA97c7uFAiVe2JmDLk0BiwwOhlKeylLDt87MWG UrNl+zfvGfc1bIdiViNoNvywoJML9EhnqCPgHp2qv7LCmJdBntMlLtoHnuujsEUJAPyz OvhCO3a/FDH3qMs8XIBwVNVJms0Kl5HTnhEjQnMuoqTVpd4ZxAXkMmg4eNQrMzg7Lepg wSILw6/k4ejWA5AVZlBE6hrEXWLXPBtZjXQ9FCC8riyYshfmAL2HSK6qO9kuI9GO0+/p r+nJLoOt3zshJWOtqUD36BZ9tdBIj4tsZq8qzvpgCCW2XxYdcYRG3iUQxX48PlNTg5f+ 6XCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=9u0t5BTrruukpGc9GKTUEAAKqN+zVa6SHjsDdDS2FUc=; b=msGZZOlkyekJIjzSo+xX/+Kwe+wZRg2y5Pn/0N9ACSIGKwlZrMeSaT/M4/47975CDk zclpfSzixEceTzLddjIL90n/klpnk/G2ZqXjXmgEshRbbJWyaKISeFnUltYdrHNfZHAQ KK7jt4wG1EEyG3liiz4gLoIl2wYQzvg3uHgJldLlalIUyglr2Tx7DCHmx/polLVHobb5 raeTerH0BzY62qVh71Z1IEiBSiWQna+iY8BfNSjEao4i45l2p+kmElRuwVYEc0+1uacU PhKCUUDmdRsa55gcuufwwVECiXWHDSSqAvosdZupKCVvKzaV4B4bzMOBmhc/2WlJbEee kk+A== X-Gm-Message-State: ALyK8tKAwi+St0njlPB2YAilmoAVPWM8oreZ3RB6W+0m4AngmkOD617bHO4rBE8+s288fTwtdvwe+4de9heprw== MIME-Version: 1.0 X-Received: by 10.25.91.140 with SMTP id p134mr1043579lfb.181.1464191685686; Wed, 25 May 2016 08:54:45 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.25.134.196 with HTTP; Wed, 25 May 2016 08:54:45 -0700 (PDT) In-Reply-To: References: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> <13146_1464170675_574578B3_13146_4888_1_53C29892C857584299CBF5D05346208A0F8CD227@OPEXCLILM21.corporate.adroot.infra.ftgroup> Date: Wed, 25 May 2016 17:54:45 +0200 X-Google-Sender-Auth: wxmgcMClgFObHYrbsbmX6ab0XPE Message-ID: From: Robert Raszuk To: "Keyur Patel (keyupate)" Content-Type: multipart/alternative; boundary=001a11400b424efcd90533acb118 Archived-At: Cc: Bruno Decraene , Susan Hares , "idr@ietf.org" Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 15:54:51 -0000 --001a11400b424efcd90533acb118 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E2=80=8BYou missed the scenario I am afraid :) R1 --- RR --- R2 R1 and RR support extended message ... R2 does not. So R1 sends to RR NLRI with attributes exceeding 4K as he has no clue who is behind RR and what they support. How RR is supposed to pass this prefix with bunch of attributes larger then 4K to R2 ? Best, R. =E2=80=8B On Wed, May 25, 2016 at 5:51 PM, Keyur Patel (keyupate) wrote: > Hi Robert, > > I thought the context of that line =E2=80=9Cnot generating single NLRI if > attributes exceed 4K=E2=80=9D was for peers not supporting extended messa= ges. > > Otherwise its a moot point. :) > Regards, > Keyur > > From: Robert Raszuk > Date: Wednesday, May 25, 2016 at 8:48 AM > To: Keyur Patel , "Acee Lindem (acee)" > > Cc: Bruno Decraene , "idr@ietf.org" < > idr@ietf.org>, Susan Hares > Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to > 6/7) > > > >> Additionally, we could discourage the generation of a single NLRI >> exceeding 4K. >> >> #Keyur: Yep. I agree. :) >> > > =E2=80=8BThe entire idea for this draft was triggered by the fear that BG= PSec may > not fit to 4K update msg. > > The draft explicitly states so as a motivation for this work. > > Section 1 > > "As BGP is extended to support newer AFI/SAFIs and newer capabilities > (e.g., > [I-D.ietf-sidr-bgpsec-overview]), there is a need to extend the maximu= m > message > size beyond 4096 octets." > > =E2=80=8BNow in turn the referenced draft clearly defines that NLRI will = only > contain single prefix: > > Section 3.2 > > "When a BGP speaker originates a BGPsec update message, it creates a > BGPsec_Path attribute containing a single signature. The signature > protects the Network Layer Reachability Information (NLRI), the AS > number of the originating AS, and the AS number of the peer AS to > whom the update message is being sent. Note that the NLRI in a BGPsec > update message is restricted to contain only a single prefix." > > Question: > > =E2=80=8BSo what exactly are we to discourage here because clearly not "g= eneration > of single NLRI exceeding 4K" ? > > Maybe deployment of BGPSec till all BGP routers in the world support this > new extended message size ? > > Thx, > R. > =E2=80=8B > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --001a11400b424efcd90533acb118 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=E2=80=8BY= ou missed the scenario I am afraid :)=C2=A0

R1 --- RR --- R2


R1 and RR support extended me= ssage ... R2 does not.=C2=A0

So R1 sends to RR NLRI with attributes exceeding 4K as he has no c= lue who is behind RR and what they support.

How RR is supposed to pass this prefix with bunch of attributes larger th= en 4K to R2 ?

Best,
R.
=E2=80=8B

On Wed, May 25, 2016 a= t 5:51 PM, Keyur Patel (keyupate) <keyupate@cisco.com> wrot= e:
Hi Robert,

I thought the context of that line =E2=80=9Cnot generating single NLRI= if attributes exceed 4K=E2=80=9D was for peers not supporting extended mes= sages.

Otherwise its a moot point. :)
Regards,
Keyur

From: Robert Raszuk <robert@raszuk.net>
Date: Wednesday, May 25, 2016 at 8:= 48 AM
To: Keyur Patel <keyupate@cisco.com>, "= Acee Lindem (acee)" <acee@cisco.com>
Cc: Bruno Decraene <bruno.decraene@orange.co= m>, "idr@ietf= .org" <idr@ie= tf.org>, Susan Hares <shares@ndzh.com>
Subject: Re: [Idr] draft-ietf-idr-b= gp-extended-messages-12 WG LC (5/24 to 6/7)

=C2=A0
Additionally, we could discourage the generation of a single NLRI exce= eding 4K.=C2=A0

#Keyur: Yep. I agree. :)

=E2=80=8BThe entire idea for this draft was triggered by the fear that BGPS= ec may not fit to 4K update msg.=C2=A0

The draft explicitly states so as a motivation for this work.=C2=A0

Section 1

=C2=A0 =C2=A0"As BGP is extended to suppo= rt newer AFI/SAFIs and newer capabilities (e.g.,
=C2=A0 =C2=A0[I-D.ietf-sidr-bgpsec-overview]),= there is a need to extend the maximum message=C2=A0
=C2=A0 =C2=A0size beyond 4096 octets."

=E2=80=8BNow in turn the referenced draft clearly defines that NLRI will on= ly contain single prefix:=C2=A0

Section 3.2

=C2=A0 =C2=A0"When a BGP speaker originat= es a BGPsec update message, it creates a
=C2=A0 =C2=A0BGPsec_Path attribute containing = a single signature. The signature
=C2=A0 =C2=A0protects the Network Layer Reacha= bility Information (NLRI), the AS
=C2=A0 =C2=A0number of the originating AS, and= the AS number of the peer AS to
=C2=A0 =C2=A0whom the update message is being = sent. Note that the NLRI in a BGPsec
=C2=A0 =C2=A0update message is restricted to c= ontain only a single prefix."

Question:

=E2=80=8BSo what exactly are we to discourage here because clearly not &quo= t;generation of single NLRI exceeding 4K" ?=C2=A0

Maybe deployment of BGPSec till all BGP routers in the world support this n= ew extended message size ?=C2=A0

Thx,
R.
=E2=80=8B

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr


--001a11400b424efcd90533acb118-- From nobody Wed May 25 08:57:39 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAAA912D803 for ; Wed, 25 May 2016 08:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEwNQ1j9LHbL for ; Wed, 25 May 2016 08:57:35 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DB3912D7EE for ; Wed, 25 May 2016 08:57:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30506; q=dns/txt; s=iport; t=1464191855; x=1465401455; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=JdIF8bv1c53UKqeGmunL2zcqsSTBZy2ben+MYMdU0SE=; b=J+nQB1Q2TucRxyW44AxRQSJKTuqnFhCqV/ArcFdhjAMQBEuj62eHcCgP lP5reMiFVhlHuBp+wpcGxPiYPSTGKQg+BY0EYbOmvEIzrc3asTj2fMIdw WobQ/4cDu4EaF1Lqd4ufZ/mAQn6faxuh0dS/aD+rnW1t7cbtl7/rwoJcF 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AdAgDnykVX/4wNJK1cgmxLVn0GuXEBD?= =?us-ascii?q?YF3JIVtAoFBOBQBAQEBAQEBZSeEQwEBAQQtTBACAQgRAwEBASEBBgcyFAkIAgQ?= =?us-ascii?q?BDQWILw7EKAEBAQEBAQEBAQEBAQEBAQEBAQEBARcFhieETIQRAQkHATwWhSQBB?= =?us-ascii?q?Jg3AYV/iCCBaYRPiGSGM4kYAR4BAUKDbW4BiEgBCBcEG38BAQE?= X-IronPort-AV: E=Sophos;i="5.26,364,1459814400"; d="scan'208,217";a="276962683" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 May 2016 15:57:34 +0000 Received: from XCH-RTP-020.cisco.com (xch-rtp-020.cisco.com [64.101.220.160]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u4PFvX6O003689 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 25 May 2016 15:57:33 GMT Received: from xch-rtp-017.cisco.com (64.101.220.157) by XCH-RTP-020.cisco.com (64.101.220.160) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 25 May 2016 11:57:32 -0400 Received: from xch-rtp-017.cisco.com ([64.101.220.157]) by XCH-RTP-017.cisco.com ([64.101.220.157]) with mapi id 15.00.1104.009; Wed, 25 May 2016 11:57:32 -0400 From: "Keyur Patel (keyupate)" To: Bruno Decraene , Susan Hares Thread-Topic: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) Thread-Index: AQHRtp4logIJlNjLIEOwkM2fAGkn1w== Date: Wed, 25 May 2016 15:57:32 +0000 Message-ID: References: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> <13146_1464170675_574578B3_13146_4888_1_53C29892C857584299CBF5D05346208A0F8CD227@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <13146_1464170675_574578B3_13146_4888_1_53C29892C857584299CBF5D05346208A0F8CD227@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.6.18] Content-Type: multipart/alternative; boundary="_000_D36B14EC40818keyupateciscocom_" MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 15:57:38 -0000 --_000_D36B14EC40818keyupateciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Bruno, Many thanks for the review. Comments inlined #Keyur From: Bruno Decraene > Date: Wednesday, May 25, 2016 at 3:04 AM To: Susan Hares >, Keyur Patel > Cc: "idr@ietf.org" > Subject: RE: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6= /7) Hi, 1) Support. 2) Question, for my own information: why does the capability mean that= the BGP speaker is capable of _both_ receiving _and sending_ extend messa= ge? (vs capable of receiving (only)). IOTW, what is the motivation to adver= tise the capacity to send extended message? 3) Please find below some possible comments: =934. Operation=94 Suppose that I receive an extended BGP message (e.g. update) that I can=92t= relay to some peers because they don=92t support such extension, while I = =93should=94 have relayed it. Is there an expected behavior? Should it be s= tandardized? Can this create issues (e.g. inconsistent routing with an AS)?= Should this be considered in the security considerations? (e.g. I delibera= tely send an extended message, and benefit from its/the NLRI not being prop= agated as expected. e.g. to influence routing policy) #Keyur: Clients would receive internal routes as long as a RR can announce = prefixes using existing message length (of 4K). It would be using multiple = messages limited to 4K length. Alternatively, if the attribute size is suc= h that the message length does get exceeded then the Prefix SHOULD not be a= nnounced and an error should be logged (existing case). -- =93A BGP speaker may send extended messages to its peer only if it has rece= ived the Extended Message Capability from its peer.=94 May be :s/received/sent and received --- #Keyur: A capability announcement indicates an ability to "receive and pars= e" extended messages. In that context =93receive=94 is good enough? =93 A BGP speaker that has the ability to use extended messages but has not advertised the BGP Extended Messages capability, presumably due to configuration, SHOULD NOT accept an extended message. A speaker MAY implement a more liberal policy and accept extended messages even from a peer that has not advertised the capability.=94 I would a priori have assumed that both sentences be related. But in fact t= hey are not since the first sentence only refers to the sending of the capa= bility, while the second only refers to the reception of the capability. Sh= ouldn=92t both sentences be extended to cover both the sending and the rece= iving? -- #Keyur: We wanted to be explicit in error handling section. :) Again, the c= apability meaning is to be able to =93receive and parse=94. =93A speaker that treats an improper extended message as a fatal error, as described in the preceding paragraph, MUST do likewise. =BB I=92m sorry but I don=92t understand this sentence. What does that mean to = =93treat an improper extended message as a fatal error=94? e.g. If I receiv= e an extended message with a syntax error requiring to send an NOTIFICATION= (e.g. more than one MP_REACH_NLRI) is this considered an improper extende= d message with a fatal error? If so the text seems wrong as bgp speaker mus= t not do =93likewise=94 (seems to refer to =93reset the session with a Ba= d Message Length NOTIFICATION=94) Also =93as described in the preceding paragraph, MUST do likewise=94 seems = not precise enough to me (at least as a non-native English speaker). Which = exactly is this preceding paragraph describing this =93treats an improper e= xtended message as a fatal error=94 --- #Keyur: The text is meant for a BGP speaker that doesn=92t announce extend= ed message capability AND doesn=92t support extended messages implementatio= n (old style peer). Such a peer would consider a receipt of an extended mes= sage as a malformed message. 7. IANA Considerations =93The IANA is requested to register a new BGP Capability Code to be named = BGP Extended Message Capability =BB I=92m not sure about the formulation since IANA has already registered this= capability as TEMPORARY. =93TBD BGP-Extended Message=94 At least I would expect that the document ask for the _same_ value (6) rath= er than TBD. #Keyur: Ack. Regards, Keyur Thanks, Regards, Bruno From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, May 24, 2016 10:42 PM To: idr@ietf.org Cc: 'Keyur Patel (keyupate)'; 'David Ward' Subject: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) This begins a 2 week WG LC on draft-ietf-idr-bgp-extended-messages (5/24 to= 6/7). The draft can be found at: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/ In your comments please provide the following information: 1) Support/=94no-support=94 of this draft being ready for publication, 2) You know of an implementation for this draft, please report the imp= lementation to the IDR Wiki https://trac.tools.ietf.org/wg/idr/trac/wiki/draft-ietf-idr-bgp-extended-im= plementations 3) Do you have any concerns about extending the BGP messages. Sue Hares and John Scudder ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_D36B14EC40818keyupateciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4B40E2C48E3A0C4F94F1C9A5545967AF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Bruno,

Many thanks for the review. Comments inlined #Keyur

From: Bruno Decraene <bruno.decraene@orange.com>
Date: Wednesday, May 25, 2016 at 3:= 04 AM
To: Susan Hares <shares@ndzh.com>, Keyur Patel <keyupate@cisco.com>
Cc: "idr@ietf.org" <idr@ietf.= org>
Subject: RE: [Idr] draft-ietf-idr-b= gp-extended-messages-12 WG LC (5/24 to 6/7)

Hi,<= /p>

 

1)      Support.

 

2)      Question, for my own information: why does the capability mean that th= e BGP speaker is capable of _both_  receiving _and sending_ extend message? (vs capable of receiving (only)). IOTW, what is the motivation to advertise the capacity to send ex= tended message?

&n= bsp;

3)      Please find below some possible comments:

&n= bsp;

=934.  Operation=94
Suppose that I receive an extended BGP message (e=
.g. update) that I can=92t relay to some peers because they don=92t support=
 such extension, while I =93should=94 have relayed it. Is there an expected=
 behavior? Should it be standardized? Can this create issues (e.g. inconsis=
tent routing with an AS)? Should this be considered in the security conside=
rations? (e.g. I deliberately send an extended message, and benefit from it=
s/the NLRI not being propagated as expected. e.g. to influence routing poli=
cy)

&n= bsp;

#Keyur: Clients would receive internal routes as long as a RR can anno= unce prefixes using existing message length (of 4K). It would be using mult= iple messages limited to 4K length.  Alternatively, if the attribute s= ize is such that the message length does get exceeded then the Prefix SHOULD not be announced and an error should b= e logged (existing case).


--= 

=93A BGP speaker may send extended messages to it=
s peer only if it has received the Extended Message Capability from its pee=
r.=94
May be :s/received/sent and=
 received

---
#Keyur: A capability announcement indicates an ability to "receiv= e and parse" extended messages. In that context =93receive=94 is good = enough?


=93   A BGP speaker that has the abilit=
y to use extended messages but has
   not advertised the BGP Extended Mess=
ages capability, presumably due
   to configuration, SHOULD NOT accept =
an extended message.  A speaker
   MAY implement a more liberal policy =
and accept extended messages even
   from a peer that has not advertised =
the capability.=94

&n= bsp;

I would= a priori have assumed that both sentences be related. But in fact they are= not since the first sentence only refers to the sending of the capability,= while the second only refers to the reception of the capability. Shouldn=92t both sentences be extended to cover both th= e sending and the receiving?

--=

#Keyur: We wanted to be explicit in error handling section. :) Again, = the capability meaning is to be able to =93receive and parse=94.

&n= bsp;

=93A speaker that treats an improper extended mes=
sage as a
   fatal error, as described in the pre=
ceding paragraph, MUST do
   likewise. =BB=

I=92m s= orry but I don=92t understand this sentence. What does that mean to =93trea= t an improper extended message as a fatal error=94? e.g. If I receive an ex= tended message with a syntax error requiring to send an NOTIFICATION (e.g. more than one MP_REACH_NLRI)  is this cons= idered an improper extended message with a fatal error? If so the text seem= s wrong as bgp speaker must not do =93likewise=94 (seems to refer to =93res= et the session   with a Bad Message Length NOTIFICATION=94)

Also =93as described in the=
 preceding paragraph, MUST do likewise=94 seems not p=
recise enough to me (at least as a non-native English speaker). Which exact=
ly is this preceding paragraph describing this =93treats an improper extended message as a fatal error---

#Keyur:  The text is meant for a BGP speaker that doesn=92t annou= nce extended message capability AND doesn=92t support extended messages imp= lementation (old style peer). Such a peer would consider a receipt of an ex= tended message as a malformed message. 

7.  IANA Consideration=
s
=93The IANA is requested to register a new BGP Ca=
pability Code to be named BGP Extended Message Capability =BB
I=92m not sure about the formulation since IANA has alr=
eady registered this capability as TEMPORARY.
 
=93TBD      BGP-Extended=
 Message=94
At least I would expect that the document ask for the _=
same_ value (6) rather than TBD.

#Keyur: Ack.

Regards,
Keyur
 

Thanks,
Regards,
Bruno

&n= bsp;

&n= bsp;

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Tuesday, May 24, 2016 10:42 PM
To: idr@ietf.org
Cc: 'Keyur Patel (keyupate)'; 'David Ward'
Subject: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 t= o 6/7)

 

This begins a 2 week WG LC on d= raft-ietf-idr-bgp-extended-messages (5/24 to 6/7). The draft can be found a= t:

 

https://datatracker.iet= f.org/doc/draft-ietf-idr-bgp-extended-messages/

 

In your comments please provide= the following information:

1)      Support/=94no-suppo= rt=94 of this draft being ready for publication,

2)      You know of an impl= ementation for this draft, please report the implementation to the IDR Wiki=

 

https://trac.tools.ietf.org/wg/idr/trac/wiki/draft-= ietf-idr-bgp-extended-implementations

 

3)      Do you have any con= cerns about extending the BGP messages.

 

Sue Hares and John Scudder 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_D36B14EC40818keyupateciscocom_-- From nobody Wed May 25 09:00:50 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5D712D79C for ; Wed, 25 May 2016 09:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJFmhq1JC8rM for ; Wed, 25 May 2016 09:00:46 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7779D12D851 for ; Wed, 25 May 2016 09:00:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20067; q=dns/txt; s=iport; t=1464192038; x=1465401638; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=df4QP4Co8GJbwMjfD85gHRc0rH7oZAgV3W1bLeE76dM=; b=PVFkS/20utM8qktQOwmkWcP/P6vMrTMSgA5zgBxBPVLox4kDUHduL2dI D3Nh9XWe08rcaQSz8jrsUEufyDxi7X/Eb6k84QfwW61QCQ0xJWSq88aKn spKoddTfizJ9bAzfyaJAIyR7zFHCuWcTNCOlsNbAjRzW+zlAZDUXuNMmz 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BCAgDnykVX/5FdJa1cgmxLVn0GtHiEe?= =?us-ascii?q?QENgXcXAQqFbwIcgSU4FAEBAQEBAQFlJ4RDAQEBBAEBASBLCxACAQgRAwECKAM?= =?us-ascii?q?CAgIlCxQJCAIEDgWILw6yOpFuAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGJ4RMh?= =?us-ascii?q?F+CYYJZBZg3AY4fgWmNM4YziRgBHgEBQoNtbokIfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,364,1459814400"; d="scan'208,217";a="276964049" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 May 2016 16:00:37 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u4PG0bDK008884 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 25 May 2016 16:00:37 GMT Received: from xch-rtp-017.cisco.com (64.101.220.157) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 25 May 2016 12:00:37 -0400 Received: from xch-rtp-017.cisco.com ([64.101.220.157]) by XCH-RTP-017.cisco.com ([64.101.220.157]) with mapi id 15.00.1104.009; Wed, 25 May 2016 12:00:36 -0400 From: "Keyur Patel (keyupate)" To: Robert Raszuk Thread-Topic: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) Thread-Index: AQHRtp6TIwM1MpbKPE+Gr6JUNvgKTw== Date: Wed, 25 May 2016 16:00:36 +0000 Message-ID: References: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> <13146_1464170675_574578B3_13146_4888_1_53C29892C857584299CBF5D05346208A0F8CD227@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.6.18] Content-Type: multipart/alternative; boundary="_000_D36B199A40851keyupateciscocom_" MIME-Version: 1.0 Archived-At: Cc: Bruno Decraene , Susan Hares , "idr@ietf.org" Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 16:00:49 -0000 --_000_D36B199A40851keyupateciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KDQpDb21tZW50cyBpbmxpbmVkICNLZXl1cjENCg0KRnJvbTogUm9iZXJ0IFJh c3p1ayA8cm9iZXJ0QHJhc3p1ay5uZXQ8bWFpbHRvOnJvYmVydEByYXN6dWsubmV0Pj4NCkRhdGU6 IFdlZG5lc2RheSwgTWF5IDI1LCAyMDE2IGF0IDg6NTQgQU0NClRvOiBLZXl1ciBQYXRlbCA8a2V5 dXBhdGVAY2lzY28uY29tPG1haWx0bzprZXl1cGF0ZUBjaXNjby5jb20+Pg0KQ2M6ICJBY2VlIExp bmRlbSAoYWNlZSkiIDxhY2VlQGNpc2NvLmNvbTxtYWlsdG86YWNlZUBjaXNjby5jb20+PiwgQnJ1 bm8gRGVjcmFlbmUgPGJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208bWFpbHRvOmJydW5vLmRlY3Jh ZW5lQG9yYW5nZS5jb20+PiwgU3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbTxtYWlsdG86c2hh cmVzQG5kemguY29tPj4sICJpZHJAaWV0Zi5vcmc8bWFpbHRvOmlkckBpZXRmLm9yZz4iIDxpZHJA aWV0Zi5vcmc8bWFpbHRvOmlkckBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW0lkcl0gZHJhZnQt aWV0Zi1pZHItYmdwLWV4dGVuZGVkLW1lc3NhZ2VzLTEyIFdHIExDICg1LzI0IHRvIDYvNykNCg0K DQrigItZb3UgbWlzc2VkIHRoZSBzY2VuYXJpbyBJIGFtIGFmcmFpZCA6KQ0KDQpSMSAtLS0gUlIg LS0tIFIyDQoNCg0KUjEgYW5kIFJSIHN1cHBvcnQgZXh0ZW5kZWQgbWVzc2FnZSAuLi4gUjIgZG9l cyBub3QuDQoNClNvIFIxIHNlbmRzIHRvIFJSIE5MUkkgd2l0aCBhdHRyaWJ1dGVzIGV4Y2VlZGlu ZyA0SyBhcyBoZSBoYXMgbm8gY2x1ZSB3aG8gaXMgYmVoaW5kIFJSIGFuZCB3aGF0IHRoZXkgc3Vw cG9ydC4NCg0KSG93IFJSIGlzIHN1cHBvc2VkIHRvIHBhc3MgdGhpcyBwcmVmaXggd2l0aCBidW5j aCBvZiBhdHRyaWJ1dGVzIGxhcmdlciB0aGVuIDRLIHRvIFIyID8NCg0KI0tleXVyMTogSU1ITywg YnkgZW5hYmxpbmcgZXh0ZW5kZWQgbWVzc2FnZXMgb24gUjIuIDspDQoNCldoYXRzIHRoZSBhbHRl cm5hdGl2ZSB0byDigJxlbmFibGluZyBleHRlbmRlZCBtZXNzYWdlc+KAnSBzbyB0aGF0IHRoZSBw cmVmaXggd2l0aCBhdHRyaWJ1dGUgc2l6ZSBsYXJnZXIgdGhhbiA0SyBpcyBkZWxpdmVyZWQgdG8g UjI/IDopDQoNClJlZ2FyZHMsDQpLZXl1cg0KDQoNCg0KQmVzdCwNClIuDQrigIsNCg0KT24gV2Vk LCBNYXkgMjUsIDIwMTYgYXQgNTo1MSBQTSwgS2V5dXIgUGF0ZWwgKGtleXVwYXRlKSA8a2V5dXBh dGVAY2lzY28uY29tPG1haWx0bzprZXl1cGF0ZUBjaXNjby5jb20+PiB3cm90ZToNCkhpIFJvYmVy dCwNCg0KSSB0aG91Z2h0IHRoZSBjb250ZXh0IG9mIHRoYXQgbGluZSDigJxub3QgZ2VuZXJhdGlu ZyBzaW5nbGUgTkxSSSBpZiBhdHRyaWJ1dGVzIGV4Y2VlZCA0S+KAnSB3YXMgZm9yIHBlZXJzIG5v dCBzdXBwb3J0aW5nIGV4dGVuZGVkIG1lc3NhZ2VzLg0KDQpPdGhlcndpc2UgaXRzIGEgbW9vdCBw b2ludC4gOikNClJlZ2FyZHMsDQpLZXl1cg0KDQpGcm9tOiBSb2JlcnQgUmFzenVrIDxyb2JlcnRA cmFzenVrLm5ldDxtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ+Pg0KRGF0ZTogV2VkbmVzZGF5LCBN YXkgMjUsIDIwMTYgYXQgODo0OCBBTQ0KVG86IEtleXVyIFBhdGVsIDxrZXl1cGF0ZUBjaXNjby5j b208bWFpbHRvOmtleXVwYXRlQGNpc2NvLmNvbT4+LCAiQWNlZSBMaW5kZW0gKGFjZWUpIiA8YWNl ZUBjaXNjby5jb208bWFpbHRvOmFjZWVAY2lzY28uY29tPj4NCkNjOiBCcnVubyBEZWNyYWVuZSA8 YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTxtYWlsdG86YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNv bT4+LCAiaWRyQGlldGYub3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+IiA8aWRyQGlldGYub3JnPG1h aWx0bzppZHJAaWV0Zi5vcmc+PiwgU3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbTxtYWlsdG86 c2hhcmVzQG5kemguY29tPj4NClN1YmplY3Q6IFJlOiBbSWRyXSBkcmFmdC1pZXRmLWlkci1iZ3At ZXh0ZW5kZWQtbWVzc2FnZXMtMTIgV0cgTEMgKDUvMjQgdG8gNi83KQ0KDQoNCkFkZGl0aW9uYWxs eSwgd2UgY291bGQgZGlzY291cmFnZSB0aGUgZ2VuZXJhdGlvbiBvZiBhIHNpbmdsZSBOTFJJIGV4 Y2VlZGluZyA0Sy4NCg0KI0tleXVyOiBZZXAuIEkgYWdyZWUuIDopDQoNCuKAi1RoZSBlbnRpcmUg aWRlYSBmb3IgdGhpcyBkcmFmdCB3YXMgdHJpZ2dlcmVkIGJ5IHRoZSBmZWFyIHRoYXQgQkdQU2Vj IG1heSBub3QgZml0IHRvIDRLIHVwZGF0ZSBtc2cuDQoNClRoZSBkcmFmdCBleHBsaWNpdGx5IHN0 YXRlcyBzbyBhcyBhIG1vdGl2YXRpb24gZm9yIHRoaXMgd29yay4NCg0KU2VjdGlvbiAxDQoNCiAg ICJBcyBCR1AgaXMgZXh0ZW5kZWQgdG8gc3VwcG9ydCBuZXdlciBBRkkvU0FGSXMgYW5kIG5ld2Vy IGNhcGFiaWxpdGllcyAoZS5nLiwNCiAgIFtJLUQuaWV0Zi1zaWRyLWJncHNlYy1vdmVydmlld10p LCB0aGVyZSBpcyBhIG5lZWQgdG8gZXh0ZW5kIHRoZSBtYXhpbXVtIG1lc3NhZ2UNCiAgIHNpemUg YmV5b25kIDQwOTYgb2N0ZXRzLiINCg0K4oCLTm93IGluIHR1cm4gdGhlIHJlZmVyZW5jZWQgZHJh ZnQgY2xlYXJseSBkZWZpbmVzIHRoYXQgTkxSSSB3aWxsIG9ubHkgY29udGFpbiBzaW5nbGUgcHJl Zml4Og0KDQpTZWN0aW9uIDMuMg0KDQogICAiV2hlbiBhIEJHUCBzcGVha2VyIG9yaWdpbmF0ZXMg YSBCR1BzZWMgdXBkYXRlIG1lc3NhZ2UsIGl0IGNyZWF0ZXMgYQ0KICAgQkdQc2VjX1BhdGggYXR0 cmlidXRlIGNvbnRhaW5pbmcgYSBzaW5nbGUgc2lnbmF0dXJlLiBUaGUgc2lnbmF0dXJlDQogICBw cm90ZWN0cyB0aGUgTmV0d29yayBMYXllciBSZWFjaGFiaWxpdHkgSW5mb3JtYXRpb24gKE5MUkkp LCB0aGUgQVMNCiAgIG51bWJlciBvZiB0aGUgb3JpZ2luYXRpbmcgQVMsIGFuZCB0aGUgQVMgbnVt YmVyIG9mIHRoZSBwZWVyIEFTIHRvDQogICB3aG9tIHRoZSB1cGRhdGUgbWVzc2FnZSBpcyBiZWlu ZyBzZW50LiBOb3RlIHRoYXQgdGhlIE5MUkkgaW4gYSBCR1BzZWMNCiAgIHVwZGF0ZSBtZXNzYWdl IGlzIHJlc3RyaWN0ZWQgdG8gY29udGFpbiBvbmx5IGEgc2luZ2xlIHByZWZpeC4iDQoNClF1ZXN0 aW9uOg0KDQrigItTbyB3aGF0IGV4YWN0bHkgYXJlIHdlIHRvIGRpc2NvdXJhZ2UgaGVyZSBiZWNh dXNlIGNsZWFybHkgbm90ICJnZW5lcmF0aW9uIG9mIHNpbmdsZSBOTFJJIGV4Y2VlZGluZyA0SyIg Pw0KDQpNYXliZSBkZXBsb3ltZW50IG9mIEJHUFNlYyB0aWxsIGFsbCBCR1Agcm91dGVycyBpbiB0 aGUgd29ybGQgc3VwcG9ydCB0aGlzIG5ldyBleHRlbmRlZCBtZXNzYWdlIHNpemUgPw0KDQpUaHgs DQpSLg0K4oCLDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpJZHIgbWFpbGluZyBsaXN0DQpJZHJAaWV0Zi5vcmc8bWFpbHRvOklkckBpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQoNCg0K --_000_D36B199A40851keyupateciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSBSb2JlcnQs PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5Db21tZW50cyBpbmxpbmVkICNLZXl1cjE8 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04i Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQt YWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JE RVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDog MGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBC T1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxl PSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+Um9iZXJ0IFJhc3p1ayAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnJvYmVydEByYXN6dWsubmV0Ij5yb2JlcnRAcmFzenVrLm5ldDwvYT4mZ3Q7PGJy Pg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5XZWRuZXNkYXks IE1heSAyNSwgMjAxNiBhdCA4OjU0IEFNPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJv bGQiPlRvOiA8L3NwYW4+S2V5dXIgUGF0ZWwgJmx0OzxhIGhyZWY9Im1haWx0bzprZXl1cGF0ZUBj aXNjby5jb20iPmtleXVwYXRlQGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZv bnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+JnF1b3Q7QWNlZSBMaW5kZW0gKGFjZWUpJnF1b3Q7 ICZsdDs8YSBocmVmPSJtYWlsdG86YWNlZUBjaXNjby5jb20iPmFjZWVAY2lzY28uY29tPC9hPiZn dDssIEJydW5vIERlY3JhZW5lICZsdDs8YSBocmVmPSJtYWlsdG86YnJ1bm8uZGVjcmFlbmVAb3Jh bmdlLmNvbSI+YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTwvYT4mZ3Q7LCBTdXNhbiBIYXJlcyAm bHQ7PGEgaHJlZj0ibWFpbHRvOnNoYXJlc0BuZHpoLmNvbSI+c2hhcmVzQG5kemguY29tPC9hPiZn dDssDQogJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmlkckBpZXRmLm9yZyI+aWRyQGlldGYub3JnPC9h PiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlkckBpZXRmLm9yZyI+aWRyQGlldGYub3JnPC9h PiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFu PlJlOiBbSWRyXSBkcmFmdC1pZXRmLWlkci1iZ3AtZXh0ZW5kZWQtbWVzc2FnZXMtMTIgV0cgTEMg KDUvMjQgdG8gNi83KTxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9u dC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCjxi cj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5 OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQrigItZb3UgbWlz c2VkIHRoZSBzY2VuYXJpbyBJIGFtIGFmcmFpZCA6KSZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0i Z21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNl cmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2Rl ZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250 LXNpemU6c21hbGwiPg0KUjEgLS0tIFJSIC0tLSBSMjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxf ZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2Zv bnQtc2l6ZTpzbWFsbCI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQi IHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6 c21hbGwiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0i Zm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4N ClIxIGFuZCBSUiBzdXBwb3J0IGV4dGVuZGVkIG1lc3NhZ2UgLi4uIFIyIGRvZXMgbm90LiZuYnNw OzwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFy aWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQo8YnI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2 ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KU28gUjEgc2VuZHMgdG8gUlIgTkxS SSB3aXRoIGF0dHJpYnV0ZXMgZXhjZWVkaW5nIDRLIGFzIGhlIGhhcyBubyBjbHVlIHdobyBpcyBi ZWhpbmQgUlIgYW5kIHdoYXQgdGhleSBzdXBwb3J0Lg0KPGJyPg0KPGJyPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNh LHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCkhvdyBSUiBpcyBzdXBwb3NlZCB0byBwYXNz IHRoaXMgcHJlZml4IHdpdGggYnVuY2ggb2YgYXR0cmlidXRlcyBsYXJnZXIgdGhlbiA0SyB0byBS MiA/PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj4jS2V5dXIxOiBJTUhPLCBieSBlbmFibGluZyBleHRlbmRlZCBtZXNzYWdlcyBv biBSMi4gOykmbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PldoYXRzIHRoZSBh bHRlcm5hdGl2ZSB0byDigJxlbmFibGluZyBleHRlbmRlZCBtZXNzYWdlc+KAnSBzbyB0aGF0IHRo ZSBwcmVmaXggd2l0aCBhdHRyaWJ1dGUgc2l6ZSBsYXJnZXIgdGhhbiA0SyBpcyBkZWxpdmVyZWQg dG8gUjI/IDopPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5SZWdhcmRzLDwvZGl2Pg0K PGRpdj5LZXl1cjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGRpcj0i bHRyIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlh bCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KPGJyPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0 aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCkJlc3QsPC9kaXY+DQo8ZGl2IGNsYXNz PSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMt c2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NClIuPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZh dWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1z aXplOnNtYWxsIj4NCuKAizwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+ PGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFdlZCwgTWF5IDI1LCAyMDE2IGF0IDU6 NTEgUE0sIEtleXVyIFBhdGVsIChrZXl1cGF0ZSkgPHNwYW4gZGlyPSJsdHIiPg0KJmx0OzxhIGhy ZWY9Im1haWx0bzprZXl1cGF0ZUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5rZXl1cGF0ZUBj aXNjby5jb208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPg0KPGJsb2NrcXVvdGUgY2xhc3M9Imdt YWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mg c29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29y ZDtjb2xvcjpyZ2IoMCwwLDApO2ZvbnQtc2l6ZToxNHB4O2ZvbnQtZmFtaWx5OkNhbGlicmksc2Fu cy1zZXJpZiI+DQo8ZGl2PkhpIFJvYmVydCw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 PkkgdGhvdWdodCB0aGUgY29udGV4dCBvZiB0aGF0IGxpbmUg4oCcbm90IGdlbmVyYXRpbmcgc2lu Z2xlIE5MUkkgaWYgYXR0cmlidXRlcyBleGNlZWQgNEvigJ0gd2FzIGZvciBwZWVycyBub3Qgc3Vw cG9ydGluZyBleHRlbmRlZCBtZXNzYWdlcy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 Pk90aGVyd2lzZSBpdHMgYSBtb290IHBvaW50LiA6KTwvZGl2Pg0KPGRpdj5SZWdhcmRzLDwvZGl2 Pg0KPGRpdj5LZXl1cjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuPg0KPGRpdiBzdHls ZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtmb250LXNpemU6MTFwdDt0ZXh0LWFsaWduOmxlZnQ7Y29s b3I6YmxhY2s7Qk9SREVSLUJPVFRPTTptZWRpdW0gbm9uZTtCT1JERVItTEVGVDptZWRpdW0gbm9u ZTtQQURESU5HLUJPVFRPTTowaW47UEFERElORy1MRUZUOjBpbjtQQURESU5HLVJJR0hUOjBpbjtC T1JERVItVE9QOiNiNWM0ZGYgMXB0IHNvbGlkO0JPUkRFUi1SSUdIVDptZWRpdW0gbm9uZTtQQURE SU5HLVRPUDozcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bh bj5Sb2JlcnQgUmFzenVrICZsdDs8YSBocmVmPSJtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQiIHRh cmdldD0iX2JsYW5rIj5yb2JlcnRAcmFzenVrLm5ldDwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9 ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5XZWRuZXNkYXksIE1heSAyNSwgMjAxNiBh dCA4OjQ4IEFNPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+ S2V5dXIgUGF0ZWwgJmx0OzxhIGhyZWY9Im1haWx0bzprZXl1cGF0ZUBjaXNjby5jb20iIHRhcmdl dD0iX2JsYW5rIj5rZXl1cGF0ZUBjaXNjby5jb208L2E+Jmd0OywgJnF1b3Q7QWNlZSBMaW5kZW0g KGFjZWUpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YWNlZUBjaXNjby5jb20iIHRhcmdldD0i X2JsYW5rIj5hY2VlQGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2Vp Z2h0OmJvbGQiPkNjOiA8L3NwYW4+QnJ1bm8gRGVjcmFlbmUgJmx0OzxhIGhyZWY9Im1haWx0bzpi cnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+YnJ1bm8uZGVjcmFlbmVA b3JhbmdlLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86aWRyQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+aWRyQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRv OmlkckBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlkckBpZXRmLm9yZzwvYT4mZ3Q7LA0KIFN1 c2FuIEhhcmVzICZsdDs8YSBocmVmPSJtYWlsdG86c2hhcmVzQG5kemguY29tIiB0YXJnZXQ9Il9i bGFuayI+c2hhcmVzQG5kemguY29tPC9hPiZndDs8c3BhbiBjbGFzcz0iIj48YnI+DQo8c3BhbiBz dHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJlOiBbSWRyXSBkcmFmdC1p ZXRmLWlkci1iZ3AtZXh0ZW5kZWQtbWVzc2FnZXMtMTIgV0cgTEMgKDUvMjQgdG8gNi83KTxicj4N Cjwvc3Bhbj48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgZGly PSJsdHIiPg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVv dGUiPg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIg c3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDtib3JkZXItbGVmdC13aWR0aDoxcHg7Ym9y ZGVyLWxlZnQtc3R5bGU6c29saWQ7Ym9yZGVyLWxlZnQtY29sb3I6cmdiKDIwNCwyMDQsMjA0KTtw YWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkO2NvbG9y OnJnYigwLDAsMCk7Zm9udC1zaXplOjE0cHg7Zm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlm Ij4NCjxzcGFuPjxzcGFuPg0KPGRpdj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3Jk O2NvbG9yOnJnYigwLDAsMCk7Zm9udC1zaXplOjE0cHg7Zm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5z LXNlcmlmIj4NCjxkaXY+QWRkaXRpb25hbGx5LCB3ZSBjb3VsZCBkaXNjb3VyYWdlIHRoZSBnZW5l cmF0aW9uIG9mIGEgc2luZ2xlIE5MUkkgZXhjZWVkaW5nIDRLLiZuYnNwOzxicj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj48L3NwYW4+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iaDUiPg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+I0tleXVyOiBZZXAuIEkgYWdyZWUuIDopPC9kaXY+DQo8 ZGl2PjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxkaXYgY2xhc3M9Img1Ij4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0i Z21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNl cmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQrigItUaGUgZW50aXJlIGlkZWEgZm9yIHRoaXMgZHJhZnQg d2FzIHRyaWdnZXJlZCBieSB0aGUgZmVhciB0aGF0IEJHUFNlYyBtYXkgbm90IGZpdCB0byA0SyB1 cGRhdGUgbXNnLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9 ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+ DQo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZh bWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KVGhlIGRy YWZ0IGV4cGxpY2l0bHkgc3RhdGVzIHNvIGFzIGEgbW90aXZhdGlvbiBmb3IgdGhpcyB3b3JrLiZu YnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5 OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQo8YnI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxo ZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KU2VjdGlvbiAxPC9kaXY+DQo8 ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0 aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5z LXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0Ij4mbmJz cDsgJm5ic3A7JnF1b3Q7QXMgQkdQIGlzIGV4dGVuZGVkIHRvIHN1cHBvcnQgbmV3ZXIgQUZJL1NB RklzIGFuZCBuZXdlciBjYXBhYmlsaXRpZXMgKGUuZy4sPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFp bF9kZWZhdWx0Ij4mbmJzcDsgJm5ic3A7W0ktRC5pZXRmLXNpZHItYmdwc2VjLW92ZXJ2aWV3XSks IHRoZXJlIGlzIGEgbmVlZCB0byBleHRlbmQgdGhlIG1heGltdW0gbWVzc2FnZSZuYnNwOzwvZGl2 Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCI+Jm5ic3A7ICZuYnNwO3NpemUgYmV5b25kIDQw OTYgb2N0ZXRzLiZxdW90OzwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0 IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXpl OnNtYWxsIj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9 ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+ DQrigItOb3cgaW4gdHVybiB0aGUgcmVmZXJlbmNlZCBkcmFmdCBjbGVhcmx5IGRlZmluZXMgdGhh dCBOTFJJIHdpbGwgb25seSBjb250YWluIHNpbmdsZSBwcmVmaXg6Jm5ic3A7PC9kaXY+DQo8ZGl2 IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNh LHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Z21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNl cmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQpTZWN0aW9uIDMuMjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21h aWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlm O2ZvbnQtc2l6ZTpzbWFsbCI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1 bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNp emU6c21hbGwiPg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCI+Jm5ic3A7ICZuYnNwOyZxdW90 O1doZW4gYSBCR1Agc3BlYWtlciBvcmlnaW5hdGVzIGEgQkdQc2VjIHVwZGF0ZSBtZXNzYWdlLCBp dCBjcmVhdGVzIGE8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiPiZuYnNwOyAmbmJz cDtCR1BzZWNfUGF0aCBhdHRyaWJ1dGUgY29udGFpbmluZyBhIHNpbmdsZSBzaWduYXR1cmUuIFRo ZSBzaWduYXR1cmU8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiPiZuYnNwOyAmbmJz cDtwcm90ZWN0cyB0aGUgTmV0d29yayBMYXllciBSZWFjaGFiaWxpdHkgSW5mb3JtYXRpb24gKE5M UkkpLCB0aGUgQVM8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiPiZuYnNwOyAmbmJz cDtudW1iZXIgb2YgdGhlIG9yaWdpbmF0aW5nIEFTLCBhbmQgdGhlIEFTIG51bWJlciBvZiB0aGUg cGVlciBBUyB0bzwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCI+Jm5ic3A7ICZuYnNw O3dob20gdGhlIHVwZGF0ZSBtZXNzYWdlIGlzIGJlaW5nIHNlbnQuIE5vdGUgdGhhdCB0aGUgTkxS SSBpbiBhIEJHUHNlYzwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCI+Jm5ic3A7ICZu YnNwO3VwZGF0ZSBtZXNzYWdlIGlzIHJlc3RyaWN0ZWQgdG8gY29udGFpbiBvbmx5IGEgc2luZ2xl IHByZWZpeC4mcXVvdDs8L2Rpdj4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBj bGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxz YW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQpRdWVzdGlvbjo8L2Rpdj4NCjxkaXYgY2xhc3M9 ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1z ZXJpZjtmb250LXNpemU6c21hbGwiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9k ZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9u dC1zaXplOnNtYWxsIj4NCuKAi1NvIHdoYXQgZXhhY3RseSBhcmUgd2UgdG8gZGlzY291cmFnZSBo ZXJlIGJlY2F1c2UgY2xlYXJseSBub3QgJnF1b3Q7Z2VuZXJhdGlvbiBvZiBzaW5nbGUgTkxSSSBl eGNlZWRpbmcgNEsmcXVvdDsgPyZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVs dCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6 ZTpzbWFsbCI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxl PSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwi Pg0KTWF5YmUgZGVwbG95bWVudCBvZiBCR1BTZWMgdGlsbCBhbGwgQkdQIHJvdXRlcnMgaW4gdGhl IHdvcmxkIHN1cHBvcnQgdGhpcyBuZXcgZXh0ZW5kZWQgbWVzc2FnZSBzaXplID8mbmJzcDs8L2Rp dj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxo ZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNh LHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NClRoeCw8L2Rpdj4NCjxkaXYgY2xhc3M9Imdt YWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJp Zjtmb250LXNpemU6c21hbGwiPg0KUi48L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQi IHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6 c21hbGwiPg0K4oCLPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPjwvZGl2Pg0KPGJyPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJZHIgbWFpbGluZyBs aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOklkckBpZXRmLm9yZyI+SWRyQGlldGYub3JnPC9hPjxi cj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyIiBy ZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2lkcjwvYT48YnI+DQo8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxi cj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D36B199A40851keyupateciscocom_-- From nobody Wed May 25 09:04:52 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C83412D822 for ; Wed, 25 May 2016 09:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdiktR_UMvVk for ; Wed, 25 May 2016 09:04:48 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 425F712D79C for ; Wed, 25 May 2016 09:04:48 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id e131so20250269lfb.0 for ; Wed, 25 May 2016 09:04:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=RQPdsM4O0DD2U4k+w6oi1UC46uabflQMOEzWmLNoMUM=; b=XmNcFglcEM/0ba9G/bSdmvbRNpqv8Sd2SA55IVgHjIYQ1QUzDMACbyatCxZbNf3Lic HYPahUisZvZ69AfqgpKdSbKcbmnuwYRGU1L4rqaX8h7eqothBYUpquD3TDW3y0huu8hf pCOGdPovx/fnEM0iz/7fi/cgw2AKbSdabh31HmPxIOal6IXoNSX2RohEqLs2kqA201Ij s1RrYAZCAVzYVzMNIiRPQkcvIzEslYdsHY7wTY5nlWakxQGqLuxo5lhl2OlNkS9bfMS5 j+ZdBzSyCWW01Udd3PzqWKfdVdN1xJTzEZzxwtSZ2C7R7HRZy+QXDTGu8c4hd5OXxaxq n0dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=RQPdsM4O0DD2U4k+w6oi1UC46uabflQMOEzWmLNoMUM=; b=RrXG0YAT0Sl0uxKCCDXWoo9h85LjIfqc9TU2em8Dx6pR4IXR8ouF4Sqgfytkx0Qwtu 6URuTcZV7QNL/WIvTgUgp3GYkaGgf0+Z8QNZ1vwXrfHx/7lmS0gly68aHXgcsnFvtrWt ZpENLIPa3xeCed3XmvWun5YLDWsLU1+dVCxW8lp/Lukhsc7qaV4d4CBLH/AOu9IEhb8F BgDhNFKmKRtkCSSR8lazYWMN/K1e8wRp7sKnyDVk/CAc59/cwXRafysJp4dsIazQ48Ng M4kFkaqtNUB4RTH7IKNJTJsE8449nmjqy1DGxxJIJTQhQXq9pqF8GYtzlXkhfd6qqZPv /oWA== X-Gm-Message-State: ALyK8tLVjjrPGk5ikp7JglIkHol/dVoPNo4kkA6wwy5Lq/Pk8XFDmbDR0oOzxp/rlPVm3Bs8qK8cOuqNMLuDwg== MIME-Version: 1.0 X-Received: by 10.25.16.219 with SMTP id 88mr1166699lfq.21.1464192286252; Wed, 25 May 2016 09:04:46 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.25.134.196 with HTTP; Wed, 25 May 2016 09:04:46 -0700 (PDT) In-Reply-To: References: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> <13146_1464170675_574578B3_13146_4888_1_53C29892C857584299CBF5D05346208A0F8CD227@OPEXCLILM21.corporate.adroot.infra.ftgroup> Date: Wed, 25 May 2016 18:04:46 +0200 X-Google-Sender-Auth: Qhotz_6oPc6cOAPKZeehTcub0GE Message-ID: From: Robert Raszuk To: "Keyur Patel (keyupate)" Content-Type: multipart/alternative; boundary=001a11402d9c1ae59d0533acd593 Archived-At: Cc: Bruno Decraene , Susan Hares , "idr@ietf.org" Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 16:04:51 -0000 --001a11402d9c1ae59d0533acd593 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I listed 4 alternative solutions earlier in this thread already :). Dropping NLRI no matter how rear it would be is not one of them. Your solution is not going to work in practice if extended msg is cap negotiated on by default (after upgrade) as there always be speakers which get upgraded later (if at all). Rgs, r. On Wed, May 25, 2016 at 6:00 PM, Keyur Patel (keyupate) wrote: > Hi Robert, > > Comments inlined #Keyur1 > > From: Robert Raszuk > Date: Wednesday, May 25, 2016 at 8:54 AM > To: Keyur Patel > Cc: "Acee Lindem (acee)" , Bruno Decraene < > bruno.decraene@orange.com>, Susan Hares , "idr@ietf.org" > > Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to > 6/7) > > > =E2=80=8BYou missed the scenario I am afraid :) > > R1 --- RR --- R2 > > > R1 and RR support extended message ... R2 does not. > > So R1 sends to RR NLRI with attributes exceeding 4K as he has no clue who > is behind RR and what they support. > > How RR is supposed to pass this prefix with bunch of attributes larger > then 4K to R2 ? > > #Keyur1: IMHO, by enabling extended messages on R2. ;) > > Whats the alternative to =E2=80=9Cenabling extended messages=E2=80=9D so = that the prefix > with attribute size larger than 4K is delivered to R2? :) > > Regards, > Keyur > > > > Best, > R. > =E2=80=8B > > On Wed, May 25, 2016 at 5:51 PM, Keyur Patel (keyupate) < > keyupate@cisco.com> wrote: > >> Hi Robert, >> >> I thought the context of that line =E2=80=9Cnot generating single NLRI i= f >> attributes exceed 4K=E2=80=9D was for peers not supporting extended mess= ages. >> >> Otherwise its a moot point. :) >> Regards, >> Keyur >> >> From: Robert Raszuk >> Date: Wednesday, May 25, 2016 at 8:48 AM >> To: Keyur Patel , "Acee Lindem (acee)" < >> acee@cisco.com> >> Cc: Bruno Decraene , "idr@ietf.org" < >> idr@ietf.org>, Susan Hares >> Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 >> to 6/7) >> >> >> >>> Additionally, we could discourage the generation of a single NLRI >>> exceeding 4K. >>> >>> #Keyur: Yep. I agree. :) >>> >> >> =E2=80=8BThe entire idea for this draft was triggered by the fear that B= GPSec may >> not fit to 4K update msg. >> >> The draft explicitly states so as a motivation for this work. >> >> Section 1 >> >> "As BGP is extended to support newer AFI/SAFIs and newer capabilities >> (e.g., >> [I-D.ietf-sidr-bgpsec-overview]), there is a need to extend the >> maximum message >> size beyond 4096 octets." >> >> =E2=80=8BNow in turn the referenced draft clearly defines that NLRI will= only >> contain single prefix: >> >> Section 3.2 >> >> "When a BGP speaker originates a BGPsec update message, it creates a >> BGPsec_Path attribute containing a single signature. The signature >> protects the Network Layer Reachability Information (NLRI), the AS >> number of the originating AS, and the AS number of the peer AS to >> whom the update message is being sent. Note that the NLRI in a BGPsec >> update message is restricted to contain only a single prefix." >> >> Question: >> >> =E2=80=8BSo what exactly are we to discourage here because clearly not >> "generation of single NLRI exceeding 4K" ? >> >> Maybe deployment of BGPSec till all BGP routers in the world support thi= s >> new extended message size ? >> >> Thx, >> R. >> =E2=80=8B >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> >> > --001a11402d9c1ae59d0533acd593 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I listed 4= alternative solutions earlier in this thread already :). Dropping NLRI no = matter how rear it would be is not one of them.
Your solution is not going to work in practice if= extended msg is cap negotiated on by default (after upgrade) as there alwa= ys be speakers which get upgraded later (if at all).=C2=A0

Rgs,
r.
=



On Wed, May 25, 2016 at 6:0= 0 PM, Keyur Patel (keyupate) <keyupate@cisco.com> wrote:
Hi Robert,

Comments inlined #Keyur1

From: Robert Raszuk <robert@raszuk.net>
Date: Wednesday, May 25, 2016 at 8:= 54 AM
To: Keyur Patel <keyupate@cisco.com>
Cc: "Acee Lindem (acee)" = <acee@cisco.com&= gt;, Bruno Decraene <bruno.decraene@orange.com>, Susan Hares <shares@ndzh.com>, "idr@ietf.org&q= uot; <idr@ietf.org= >
Subject: Re: [Idr] draft-ietf-idr-b= gp-extended-messages-12 WG LC (5/24 to 6/7)


=E2=80=8BYou missed the scenario I am afraid :)=C2=A0

R1 --- RR --- R2


R1 and RR support extended message ... R2 does not.=C2=A0

So R1 sends to RR NLRI with attributes exceeding 4K as he has no clue who i= s behind RR and what they support.

How RR is supposed to pass this prefix with bunch of attributes larger then= 4K to R2 ?

#Keyur1: IMHO, by enabling extended messages on R2. ;)=C2=A0

Whats the alternative to =E2=80=9Cenabling extended messages=E2=80=9D = so that the prefix with attribute size larger than 4K is delivered to R2? := )

Regards,
Keyur



Best,
R.
=E2=80=8B

On Wed, May 25, 2016 at 5:51 PM, Keyur Patel (ke= yupate) <keyupate@cisco.= com> wrote:
Hi Robert,

I thought the context of that line =E2=80=9Cnot generating single NLRI= if attributes exceed 4K=E2=80=9D was for peers not supporting extended mes= sages.

Otherwise its a moot point. :)
Regards,
Keyur

From: Robert Raszuk <robert@raszuk.net>
Date: Wednesday, May 25, 2016 at 8:= 48 AM
To: Keyur Patel <keyupate@cisco.com>, "= Acee Lindem (acee)" <acee@cisco.com>
Cc: Bruno Decraene <bruno.decraene@orange.co= m>, "idr@ietf= .org" <idr@ie= tf.org>, Susan Hares <share= s@ndzh.com>
Subject: Re: [Idr] draft-ietf-idr-b= gp-extended-messages-12 WG LC (5/24 to 6/7)

=C2=A0
Additionally, we could discourage the generation of a single NLRI exce= eding 4K.=C2=A0

#Keyur: Yep. I agree. :)

=E2=80=8BThe entire idea for this draft was triggered by the fear that BGPS= ec may not fit to 4K update msg.=C2=A0

The draft explicitly states so as a motivation for this work.=C2=A0

Section 1

=C2=A0 =C2=A0"As BGP is extended to suppo= rt newer AFI/SAFIs and newer capabilities (e.g.,
=C2=A0 =C2=A0[I-D.ietf-sidr-bgpsec-overview]),= there is a need to extend the maximum message=C2=A0
=C2=A0 =C2=A0size beyond 4096 octets."

=E2=80=8BNow in turn the referenced draft clearly defines that NLRI will on= ly contain single prefix:=C2=A0

Section 3.2

=C2=A0 =C2=A0"When a BGP speaker originat= es a BGPsec update message, it creates a
=C2=A0 =C2=A0BGPsec_Path attribute containing = a single signature. The signature
=C2=A0 =C2=A0protects the Network Layer Reacha= bility Information (NLRI), the AS
=C2=A0 =C2=A0number of the originating AS, and= the AS number of the peer AS to
=C2=A0 =C2=A0whom the update message is being = sent. Note that the NLRI in a BGPsec
=C2=A0 =C2=A0update message is restricted to c= ontain only a single prefix."

Question:

=E2=80=8BSo what exactly are we to discourage here because clearly not &quo= t;generation of single NLRI exceeding 4K" ?=C2=A0

Maybe deployment of BGPSec till all BGP routers in the world support this n= ew extended message size ?=C2=A0

Thx,
R.
=E2=80=8B

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

--001a11402d9c1ae59d0533acd593-- From nobody Wed May 25 09:24:35 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA6C12D841 for ; Wed, 25 May 2016 09:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bd86IlOUqKr3 for ; Wed, 25 May 2016 09:24:31 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5223212D84C for ; Wed, 25 May 2016 09:24:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27109; q=dns/txt; s=iport; t=1464193471; x=1465403071; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ZEKZnQnRzKkGmCaRu5nKnJxCC9G6ViKzVgeAeeFPWTo=; b=Q0uaaji002owFwTGJQKxRkJ2GSRFYB11J+NuyWvo6snWYqD6SmOmQfPq 9IXDtBIrQOGliDisxQrZbRwToAyr3z7gtOWSeqF/dntWXkAzu917dng2w nKhZRKlESvaz+vd22NyrZjPcLn1JG5P7FabT1tMRbfDlmaQaMots3OvS/ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AfAgB70EVX/5ldJa1cgmxLVn0GuXEBD?= =?us-ascii?q?YF3FwEKhW8CHIElOBQBAQEBAQEBZSeEQwEBAQQBAQEgSwsQAgEIEQMBAigDAgI?= =?us-ascii?q?CJQsUCQgCBA4FG4gUDrI+kW0BAQEBAQEBAwEBAQEBAQEBAQEBFwWGJ4RMhDItg?= =?us-ascii?q?mGCWQWYNwGOH4FpjTOGM4kYAR4BAUKDbW6ISz1/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,364,1459814400"; d="scan'208,217";a="106343189" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 May 2016 16:24:29 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u4PGOTtC031139 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 25 May 2016 16:24:29 GMT Received: from xch-rtp-017.cisco.com (64.101.220.157) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 25 May 2016 12:24:27 -0400 Received: from xch-rtp-017.cisco.com ([64.101.220.157]) by XCH-RTP-017.cisco.com ([64.101.220.157]) with mapi id 15.00.1104.009; Wed, 25 May 2016 12:24:28 -0400 From: "Keyur Patel (keyupate)" To: Robert Raszuk Thread-Topic: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) Thread-Index: AQHRtqHoXuJ+eihBNEmCsBnJQ/gDcw== Date: Wed, 25 May 2016 16:24:28 +0000 Message-ID: References: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> <13146_1464170675_574578B3_13146_4888_1_53C29892C857584299CBF5D05346208A0F8CD227@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.6.18] Content-Type: multipart/alternative; boundary="_000_D36B1BD740862keyupateciscocom_" MIME-Version: 1.0 Archived-At: Cc: Bruno Decraene , Susan Hares , "idr@ietf.org" Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 16:24:34 -0000 --_000_D36B1BD740862keyupateciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KDQpUaGVyZSBhcmUgSW1wbGVtZW50YXRpb25zIHRoYXQgcHJvdmlkZSBhbiBh YmlsaXR5IG9mIHNlbGVjdGl2ZWx5IGRyb3BwaW5nIGF0dHJpYnV0ZXMgYXMgcGFydCBvZiBlcnJv ciBoYW5kbGluZyBzb2x1dGlvbi4gIFdlIGNvdWxkIGFkZCB0ZXh0IHRoYXQgc3VnZ2VzdHMgdGhl IHNhbWUuDQoNCkhvd2V2ZXIsIGRyb3BwaW5nIG9wdGlvbmFsIHRyYW5zaXRpdmUgYXR0cmlidXRl cyAoaW4gYSBzb21ld2hhdCByYW5kb20gZmFzaGlvbiBvciBiYXNlZCBvbiB0aGVpciBzaXplKSB3 aXRob3V0IGEga25vd2xlZGdlIG9mIG5ldHdvcmsgb3BlcmF0b3IgTUFZIHJlc3VsdCBpbiBwYXJ0 aWFsIGRlcGxveW1lbnQgb2Ygc3VjaCBhdHRyaWJ1dGVzIGFuZCBpdHMgZmVhdHVyZXMgYW5kIGNv dWxkIGhhdmUgb3RoZXIgaXNzdWVzIGluIGl0c2VsZiENCg0KUmVnYXJkcywNCktleXVyDQoNCkZy b206IFJvYmVydCBSYXN6dWsgPHJvYmVydEByYXN6dWsubmV0PG1haWx0bzpyb2JlcnRAcmFzenVr Lm5ldD4+DQpEYXRlOiBXZWRuZXNkYXksIE1heSAyNSwgMjAxNiBhdCA5OjA0IEFNDQpUbzogS2V5 dXIgUGF0ZWwgPGtleXVwYXRlQGNpc2NvLmNvbTxtYWlsdG86a2V5dXBhdGVAY2lzY28uY29tPj4N CkNjOiAiQWNlZSBMaW5kZW0gKGFjZWUpIiA8YWNlZUBjaXNjby5jb208bWFpbHRvOmFjZWVAY2lz Y28uY29tPj4sIEJydW5vIERlY3JhZW5lIDxicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPG1haWx0 bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPj4sIFN1c2FuIEhhcmVzIDxzaGFyZXNAbmR6aC5j b208bWFpbHRvOnNoYXJlc0BuZHpoLmNvbT4+LCAiaWRyQGlldGYub3JnPG1haWx0bzppZHJAaWV0 Zi5vcmc+IiA8aWRyQGlldGYub3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6 IFtJZHJdIGRyYWZ0LWlldGYtaWRyLWJncC1leHRlbmRlZC1tZXNzYWdlcy0xMiBXRyBMQyAoNS8y NCB0byA2LzcpDQoNCg0KSSBsaXN0ZWQgNCBhbHRlcm5hdGl2ZSBzb2x1dGlvbnMgZWFybGllciBp biB0aGlzIHRocmVhZCBhbHJlYWR5IDopLiBEcm9wcGluZyBOTFJJIG5vIG1hdHRlciBob3cgcmVh ciBpdCB3b3VsZCBiZSBpcyBub3Qgb25lIG9mIHRoZW0uDQoNCllvdXIgc29sdXRpb24gaXMgbm90 IGdvaW5nIHRvIHdvcmsgaW4gcHJhY3RpY2UgaWYgZXh0ZW5kZWQgbXNnIGlzIGNhcCBuZWdvdGlh dGVkIG9uIGJ5IGRlZmF1bHQgKGFmdGVyIHVwZ3JhZGUpIGFzIHRoZXJlIGFsd2F5cyBiZSBzcGVh a2VycyB3aGljaCBnZXQgdXBncmFkZWQgbGF0ZXIgKGlmIGF0IGFsbCkuDQoNClJncywNCnIuDQoN Cg0KDQpPbiBXZWQsIE1heSAyNSwgMjAxNiBhdCA2OjAwIFBNLCBLZXl1ciBQYXRlbCAoa2V5dXBh dGUpIDxrZXl1cGF0ZUBjaXNjby5jb208bWFpbHRvOmtleXVwYXRlQGNpc2NvLmNvbT4+IHdyb3Rl Og0KSGkgUm9iZXJ0LA0KDQpDb21tZW50cyBpbmxpbmVkICNLZXl1cjENCg0KRnJvbTogUm9iZXJ0 IFJhc3p1ayA8cm9iZXJ0QHJhc3p1ay5uZXQ8bWFpbHRvOnJvYmVydEByYXN6dWsubmV0Pj4NCkRh dGU6IFdlZG5lc2RheSwgTWF5IDI1LCAyMDE2IGF0IDg6NTQgQU0NClRvOiBLZXl1ciBQYXRlbCA8 a2V5dXBhdGVAY2lzY28uY29tPG1haWx0bzprZXl1cGF0ZUBjaXNjby5jb20+Pg0KQ2M6ICJBY2Vl IExpbmRlbSAoYWNlZSkiIDxhY2VlQGNpc2NvLmNvbTxtYWlsdG86YWNlZUBjaXNjby5jb20+Piwg QnJ1bm8gRGVjcmFlbmUgPGJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208bWFpbHRvOmJydW5vLmRl Y3JhZW5lQG9yYW5nZS5jb20+PiwgU3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbTxtYWlsdG86 c2hhcmVzQG5kemguY29tPj4sICJpZHJAaWV0Zi5vcmc8bWFpbHRvOmlkckBpZXRmLm9yZz4iIDxp ZHJAaWV0Zi5vcmc8bWFpbHRvOmlkckBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW0lkcl0gZHJh ZnQtaWV0Zi1pZHItYmdwLWV4dGVuZGVkLW1lc3NhZ2VzLTEyIFdHIExDICg1LzI0IHRvIDYvNykN Cg0KDQrigItZb3UgbWlzc2VkIHRoZSBzY2VuYXJpbyBJIGFtIGFmcmFpZCA6KQ0KDQpSMSAtLS0g UlIgLS0tIFIyDQoNCg0KUjEgYW5kIFJSIHN1cHBvcnQgZXh0ZW5kZWQgbWVzc2FnZSAuLi4gUjIg ZG9lcyBub3QuDQoNClNvIFIxIHNlbmRzIHRvIFJSIE5MUkkgd2l0aCBhdHRyaWJ1dGVzIGV4Y2Vl ZGluZyA0SyBhcyBoZSBoYXMgbm8gY2x1ZSB3aG8gaXMgYmVoaW5kIFJSIGFuZCB3aGF0IHRoZXkg c3VwcG9ydC4NCg0KSG93IFJSIGlzIHN1cHBvc2VkIHRvIHBhc3MgdGhpcyBwcmVmaXggd2l0aCBi dW5jaCBvZiBhdHRyaWJ1dGVzIGxhcmdlciB0aGVuIDRLIHRvIFIyID8NCg0KI0tleXVyMTogSU1I TywgYnkgZW5hYmxpbmcgZXh0ZW5kZWQgbWVzc2FnZXMgb24gUjIuIDspDQoNCldoYXRzIHRoZSBh bHRlcm5hdGl2ZSB0byDigJxlbmFibGluZyBleHRlbmRlZCBtZXNzYWdlc+KAnSBzbyB0aGF0IHRo ZSBwcmVmaXggd2l0aCBhdHRyaWJ1dGUgc2l6ZSBsYXJnZXIgdGhhbiA0SyBpcyBkZWxpdmVyZWQg dG8gUjI/IDopDQoNClJlZ2FyZHMsDQpLZXl1cg0KDQoNCg0KQmVzdCwNClIuDQrigIsNCg0KT24g V2VkLCBNYXkgMjUsIDIwMTYgYXQgNTo1MSBQTSwgS2V5dXIgUGF0ZWwgKGtleXVwYXRlKSA8a2V5 dXBhdGVAY2lzY28uY29tPG1haWx0bzprZXl1cGF0ZUBjaXNjby5jb20+PiB3cm90ZToNCkhpIFJv YmVydCwNCg0KSSB0aG91Z2h0IHRoZSBjb250ZXh0IG9mIHRoYXQgbGluZSDigJxub3QgZ2VuZXJh dGluZyBzaW5nbGUgTkxSSSBpZiBhdHRyaWJ1dGVzIGV4Y2VlZCA0S+KAnSB3YXMgZm9yIHBlZXJz IG5vdCBzdXBwb3J0aW5nIGV4dGVuZGVkIG1lc3NhZ2VzLg0KDQpPdGhlcndpc2UgaXRzIGEgbW9v dCBwb2ludC4gOikNClJlZ2FyZHMsDQpLZXl1cg0KDQpGcm9tOiBSb2JlcnQgUmFzenVrIDxyb2Jl cnRAcmFzenVrLm5ldDxtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ+Pg0KRGF0ZTogV2VkbmVzZGF5 LCBNYXkgMjUsIDIwMTYgYXQgODo0OCBBTQ0KVG86IEtleXVyIFBhdGVsIDxrZXl1cGF0ZUBjaXNj by5jb208bWFpbHRvOmtleXVwYXRlQGNpc2NvLmNvbT4+LCAiQWNlZSBMaW5kZW0gKGFjZWUpIiA8 YWNlZUBjaXNjby5jb208bWFpbHRvOmFjZWVAY2lzY28uY29tPj4NCkNjOiBCcnVubyBEZWNyYWVu ZSA8YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTxtYWlsdG86YnJ1bm8uZGVjcmFlbmVAb3Jhbmdl LmNvbT4+LCAiaWRyQGlldGYub3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+IiA8aWRyQGlldGYub3Jn PG1haWx0bzppZHJAaWV0Zi5vcmc+PiwgU3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbTxtYWls dG86c2hhcmVzQG5kemguY29tPj4NClN1YmplY3Q6IFJlOiBbSWRyXSBkcmFmdC1pZXRmLWlkci1i Z3AtZXh0ZW5kZWQtbWVzc2FnZXMtMTIgV0cgTEMgKDUvMjQgdG8gNi83KQ0KDQoNCkFkZGl0aW9u YWxseSwgd2UgY291bGQgZGlzY291cmFnZSB0aGUgZ2VuZXJhdGlvbiBvZiBhIHNpbmdsZSBOTFJJ IGV4Y2VlZGluZyA0Sy4NCg0KI0tleXVyOiBZZXAuIEkgYWdyZWUuIDopDQoNCuKAi1RoZSBlbnRp cmUgaWRlYSBmb3IgdGhpcyBkcmFmdCB3YXMgdHJpZ2dlcmVkIGJ5IHRoZSBmZWFyIHRoYXQgQkdQ U2VjIG1heSBub3QgZml0IHRvIDRLIHVwZGF0ZSBtc2cuDQoNClRoZSBkcmFmdCBleHBsaWNpdGx5 IHN0YXRlcyBzbyBhcyBhIG1vdGl2YXRpb24gZm9yIHRoaXMgd29yay4NCg0KU2VjdGlvbiAxDQoN CiAgICJBcyBCR1AgaXMgZXh0ZW5kZWQgdG8gc3VwcG9ydCBuZXdlciBBRkkvU0FGSXMgYW5kIG5l d2VyIGNhcGFiaWxpdGllcyAoZS5nLiwNCiAgIFtJLUQuaWV0Zi1zaWRyLWJncHNlYy1vdmVydmll d10pLCB0aGVyZSBpcyBhIG5lZWQgdG8gZXh0ZW5kIHRoZSBtYXhpbXVtIG1lc3NhZ2UNCiAgIHNp emUgYmV5b25kIDQwOTYgb2N0ZXRzLiINCg0K4oCLTm93IGluIHR1cm4gdGhlIHJlZmVyZW5jZWQg ZHJhZnQgY2xlYXJseSBkZWZpbmVzIHRoYXQgTkxSSSB3aWxsIG9ubHkgY29udGFpbiBzaW5nbGUg cHJlZml4Og0KDQpTZWN0aW9uIDMuMg0KDQogICAiV2hlbiBhIEJHUCBzcGVha2VyIG9yaWdpbmF0 ZXMgYSBCR1BzZWMgdXBkYXRlIG1lc3NhZ2UsIGl0IGNyZWF0ZXMgYQ0KICAgQkdQc2VjX1BhdGgg YXR0cmlidXRlIGNvbnRhaW5pbmcgYSBzaW5nbGUgc2lnbmF0dXJlLiBUaGUgc2lnbmF0dXJlDQog ICBwcm90ZWN0cyB0aGUgTmV0d29yayBMYXllciBSZWFjaGFiaWxpdHkgSW5mb3JtYXRpb24gKE5M UkkpLCB0aGUgQVMNCiAgIG51bWJlciBvZiB0aGUgb3JpZ2luYXRpbmcgQVMsIGFuZCB0aGUgQVMg bnVtYmVyIG9mIHRoZSBwZWVyIEFTIHRvDQogICB3aG9tIHRoZSB1cGRhdGUgbWVzc2FnZSBpcyBi ZWluZyBzZW50LiBOb3RlIHRoYXQgdGhlIE5MUkkgaW4gYSBCR1BzZWMNCiAgIHVwZGF0ZSBtZXNz YWdlIGlzIHJlc3RyaWN0ZWQgdG8gY29udGFpbiBvbmx5IGEgc2luZ2xlIHByZWZpeC4iDQoNClF1 ZXN0aW9uOg0KDQrigItTbyB3aGF0IGV4YWN0bHkgYXJlIHdlIHRvIGRpc2NvdXJhZ2UgaGVyZSBi ZWNhdXNlIGNsZWFybHkgbm90ICJnZW5lcmF0aW9uIG9mIHNpbmdsZSBOTFJJIGV4Y2VlZGluZyA0 SyIgPw0KDQpNYXliZSBkZXBsb3ltZW50IG9mIEJHUFNlYyB0aWxsIGFsbCBCR1Agcm91dGVycyBp biB0aGUgd29ybGQgc3VwcG9ydCB0aGlzIG5ldyBleHRlbmRlZCBtZXNzYWdlIHNpemUgPw0KDQpU aHgsDQpSLg0K4oCLDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpJZHIgbWFpbGluZyBsaXN0DQpJZHJAaWV0Zi5vcmc8bWFpbHRvOklkckBpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQoNCg0KDQo= --_000_D36B1BD740862keyupateciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSBSb2JlcnQs PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGVyZSBhcmUgSW1wbGVtZW50YXRpb25z IHRoYXQgcHJvdmlkZSBhbiBhYmlsaXR5IG9mIHNlbGVjdGl2ZWx5IGRyb3BwaW5nIGF0dHJpYnV0 ZXMgYXMgcGFydCBvZiBlcnJvciBoYW5kbGluZyBzb2x1dGlvbi4gJm5ic3A7V2UgY291bGQgYWRk IHRleHQgdGhhdCBzdWdnZXN0cyB0aGUgc2FtZS4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8ZGl2Pkhvd2V2ZXIsIGRyb3BwaW5nIG9wdGlvbmFsIHRyYW5zaXRpdmUgYXR0cmlidXRl cyAoaW4gYSBzb21ld2hhdCByYW5kb20gZmFzaGlvbiBvciBiYXNlZCBvbiB0aGVpciBzaXplKSB3 aXRob3V0IGEga25vd2xlZGdlIG9mIG5ldHdvcmsgb3BlcmF0b3IgTUFZIHJlc3VsdCBpbiBwYXJ0 aWFsIGRlcGxveW1lbnQgb2Ygc3VjaCBhdHRyaWJ1dGVzIGFuZCBpdHMgZmVhdHVyZXMgYW5kIGNv dWxkIGhhdmUgb3RoZXIgaXNzdWVzIGluIGl0c2VsZiEmbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2PlJlZ2FyZHMsPC9kaXY+DQo8ZGl2PktleXVyPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9ImZv bnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9y OmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBu b25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdI VDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRp dW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9s ZCI+RnJvbTogPC9zcGFuPlJvYmVydCBSYXN6dWsgJmx0OzxhIGhyZWY9Im1haWx0bzpyb2JlcnRA cmFzenVrLm5ldCI+cm9iZXJ0QHJhc3p1ay5uZXQ8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJm b250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+V2VkbmVzZGF5LCBNYXkgMjUsIDIwMTYgYXQg OTowNCBBTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPktl eXVyIFBhdGVsICZsdDs8YSBocmVmPSJtYWlsdG86a2V5dXBhdGVAY2lzY28uY29tIj5rZXl1cGF0 ZUBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5D YzogPC9zcGFuPiZxdW90O0FjZWUgTGluZGVtIChhY2VlKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFp bHRvOmFjZWVAY2lzY28uY29tIj5hY2VlQGNpc2NvLmNvbTwvYT4mZ3Q7LCBCcnVubyBEZWNyYWVu ZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20iPmJydW5vLmRl Y3JhZW5lQG9yYW5nZS5jb208L2E+Jmd0OywgU3VzYW4gSGFyZXMgJmx0OzxhIGhyZWY9Im1haWx0 bzpzaGFyZXNAbmR6aC5jb20iPnNoYXJlc0BuZHpoLmNvbTwvYT4mZ3Q7LA0KICZxdW90OzxhIGhy ZWY9Im1haWx0bzppZHJAaWV0Zi5vcmciPmlkckBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhy ZWY9Im1haWx0bzppZHJAaWV0Zi5vcmciPmlkckBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4g c3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogW0lkcl0gZHJhZnQt aWV0Zi1pZHItYmdwLWV4dGVuZGVkLW1lc3NhZ2VzLTEyIFdHIExDICg1LzI0IHRvIDYvNyk8YnI+ DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIi Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhl bHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Es c2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KSSBsaXN0ZWQgNCBhbHRlcm5hdGl2ZSBzb2x1 dGlvbnMgZWFybGllciBpbiB0aGlzIHRocmVhZCBhbHJlYWR5IDopLiBEcm9wcGluZyBOTFJJIG5v IG1hdHRlciBob3cgcmVhciBpdCB3b3VsZCBiZSBpcyBub3Qgb25lIG9mIHRoZW0uPC9kaXY+DQo8 ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0 aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5z LXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQpZb3VyIHNvbHV0aW9uIGlzIG5vdCBnb2luZyB0byB3 b3JrIGluIHByYWN0aWNlIGlmIGV4dGVuZGVkIG1zZyBpcyBjYXAgbmVnb3RpYXRlZCBvbiBieSBk ZWZhdWx0IChhZnRlciB1cGdyYWRlKSBhcyB0aGVyZSBhbHdheXMgYmUgc3BlYWtlcnMgd2hpY2gg Z2V0IHVwZ3JhZGVkIGxhdGVyIChpZiBhdCBhbGwpLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0i Z21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNl cmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2Rl ZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250 LXNpemU6c21hbGwiPg0KUmdzLDwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5 bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFs bCI+DQpyLjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFt aWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQo8YnI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlh bCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KPGJyPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9x dW90ZSI+T24gV2VkLCBNYXkgMjUsIDIwMTYgYXQgNjowMCBQTSwgS2V5dXIgUGF0ZWwgKGtleXVw YXRlKSA8c3BhbiBkaXI9Imx0ciI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOmtleXVwYXRlQGNpc2Nv LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmtleXVwYXRlQGNpc2NvLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3 cm90ZTo8YnI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46 MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4N CjxkaXYgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkO2NvbG9yOnJnYigwLDAsMCk7Zm9udC1z aXplOjE0cHg7Zm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmIj4NCjxkaXY+SGkgUm9iZXJ0 LDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Q29tbWVudHMgaW5saW5lZCAjS2V5dXIx PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWls eTpDYWxpYnJpO2ZvbnQtc2l6ZToxMXB0O3RleHQtYWxpZ246bGVmdDtjb2xvcjpibGFjaztCT1JE RVItQk9UVE9NOm1lZGl1bSBub25lO0JPUkRFUi1MRUZUOm1lZGl1bSBub25lO1BBRERJTkctQk9U VE9NOjBpbjtQQURESU5HLUxFRlQ6MGluO1BBRERJTkctUklHSFQ6MGluO0JPUkRFUi1UT1A6I2I1 YzRkZiAxcHQgc29saWQ7Qk9SREVSLVJJR0hUOm1lZGl1bSBub25lO1BBRERJTkctVE9QOjNwdCI+ DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPlJvYmVydCBSYXN6 dWsgJmx0OzxhIGhyZWY9Im1haWx0bzpyb2JlcnRAcmFzenVrLm5ldCIgdGFyZ2V0PSJfYmxhbmsi PnJvYmVydEByYXN6dWsubmV0PC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6 Ym9sZCI+RGF0ZTogPC9zcGFuPldlZG5lc2RheSwgTWF5IDI1LCAyMDE2IGF0IDg6NTQgQU08YnI+ DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj5LZXl1ciBQYXRlbCAm bHQ7PGEgaHJlZj0ibWFpbHRvOmtleXVwYXRlQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmtl eXVwYXRlQGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJv bGQiPkNjOiA8L3NwYW4+JnF1b3Q7QWNlZSBMaW5kZW0gKGFjZWUpJnF1b3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86YWNlZUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5hY2VlQGNpc2NvLmNvbTwv YT4mZ3Q7LCBCcnVubyBEZWNyYWVuZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJydW5vLmRlY3JhZW5l QG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj5icnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPC9h PiZndDssIFN1c2FuIEhhcmVzICZsdDs8YSBocmVmPSJtYWlsdG86c2hhcmVzQG5kemguY29tIiB0 YXJnZXQ9Il9ibGFuayI+c2hhcmVzQG5kemguY29tPC9hPiZndDssDQogJnF1b3Q7PGEgaHJlZj0i bWFpbHRvOmlkckBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlkckBpZXRmLm9yZzwvYT4mcXVv dDsgJmx0OzxhIGhyZWY9Im1haWx0bzppZHJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pZHJA aWV0Zi5vcmc8L2E+Jmd0OzxzcGFuIGNsYXNzPSIiPjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdl aWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFtJZHJdIGRyYWZ0LWlldGYtaWRyLWJncC1l eHRlbmRlZC1tZXNzYWdlcy0xMiBXRyBMQyAoNS8yNCB0byA2LzcpPGJyPg0KPC9zcGFuPjwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGNsYXNzPSIiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 IGRpcj0ibHRyIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWls eTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KPGJyPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWws aGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCuKAi1lvdSBtaXNzZWQgdGhl IHNjZW5hcmlvIEkgYW0gYWZyYWlkIDopJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9k ZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9u dC1zaXplOnNtYWxsIj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIg c3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpz bWFsbCI+DQpSMSAtLS0gUlIgLS0tIFIyPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0 IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXpl OnNtYWxsIj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9 ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+ DQo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZh bWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KUjEgYW5k IFJSIHN1cHBvcnQgZXh0ZW5kZWQgbWVzc2FnZSAuLi4gUjIgZG9lcyBub3QuJm5ic3A7PC9kaXY+ DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVs dmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxz YW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQpTbyBSMSBzZW5kcyB0byBSUiBOTFJJIHdpdGgg YXR0cmlidXRlcyBleGNlZWRpbmcgNEsgYXMgaGUgaGFzIG5vIGNsdWUgd2hvIGlzIGJlaGluZCBS UiBhbmQgd2hhdCB0aGV5IHN1cHBvcnQuDQo8YnI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1z ZXJpZjtmb250LXNpemU6c21hbGwiPg0KSG93IFJSIGlzIHN1cHBvc2VkIHRvIHBhc3MgdGhpcyBw cmVmaXggd2l0aCBidW5jaCBvZiBhdHRyaWJ1dGVzIGxhcmdlciB0aGVuIDRLIHRvIFIyID88L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj48L3NwYW4+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj4jS2V5dXIxOiBJTUhPLCBieSBlbmFibGluZyBleHRlbmRlZCBtZXNzYWdlcyBv biBSMi4gOykmbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PldoYXRzIHRoZSBh bHRlcm5hdGl2ZSB0byDigJxlbmFibGluZyBleHRlbmRlZCBtZXNzYWdlc+KAnSBzbyB0aGF0IHRo ZSBwcmVmaXggd2l0aCBhdHRyaWJ1dGUgc2l6ZSBsYXJnZXIgdGhhbiA0SyBpcyBkZWxpdmVyZWQg dG8gUjI/IDopPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5SZWdhcmRzLDwvZGl2Pg0K PGRpdj5LZXl1cjwvZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9Img1Ij4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJs dHIiPg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFs LGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQo8YnI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRp Y2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KQmVzdCw8L2Rpdj4NCjxkaXYgY2xhc3M9 ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1z ZXJpZjtmb250LXNpemU6c21hbGwiPg0KUi48L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1 bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNp emU6c21hbGwiPg0K4oCLPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48 YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gV2VkLCBNYXkgMjUsIDIwMTYgYXQgNTo1 MSBQTSwgS2V5dXIgUGF0ZWwgKGtleXVwYXRlKSA8c3BhbiBkaXI9Imx0ciI+DQombHQ7PGEgaHJl Zj0ibWFpbHRvOmtleXVwYXRlQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmtleXVwYXRlQGNp c2NvLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21h aWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBz b2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3Jk O2NvbG9yOnJnYigwLDAsMCk7Zm9udC1zaXplOjE0cHg7Zm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5z LXNlcmlmIj4NCjxkaXY+SGkgUm9iZXJ0LDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ SSB0aG91Z2h0IHRoZSBjb250ZXh0IG9mIHRoYXQgbGluZSDigJxub3QgZ2VuZXJhdGluZyBzaW5n bGUgTkxSSSBpZiBhdHRyaWJ1dGVzIGV4Y2VlZCA0S+KAnSB3YXMgZm9yIHBlZXJzIG5vdCBzdXBw b3J0aW5nIGV4dGVuZGVkIG1lc3NhZ2VzLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ T3RoZXJ3aXNlIGl0cyBhIG1vb3QgcG9pbnQuIDopPC9kaXY+DQo8ZGl2PlJlZ2FyZHMsPC9kaXY+ DQo8ZGl2PktleXVyPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4+DQo8ZGl2IHN0eWxl PSJmb250LWZhbWlseTpDYWxpYnJpO2ZvbnQtc2l6ZToxMXB0O3RleHQtYWxpZ246bGVmdDtjb2xv cjpibGFjaztCT1JERVItQk9UVE9NOm1lZGl1bSBub25lO0JPUkRFUi1MRUZUOm1lZGl1bSBub25l O1BBRERJTkctQk9UVE9NOjBpbjtQQURESU5HLUxFRlQ6MGluO1BBRERJTkctUklHSFQ6MGluO0JP UkRFUi1UT1A6I2I1YzRkZiAxcHQgc29saWQ7Qk9SREVSLVJJR0hUOm1lZGl1bSBub25lO1BBRERJ TkctVE9QOjNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFu PlJvYmVydCBSYXN6dWsgJmx0OzxhIGhyZWY9Im1haWx0bzpyb2JlcnRAcmFzenVrLm5ldCIgdGFy Z2V0PSJfYmxhbmsiPnJvYmVydEByYXN6dWsubmV0PC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0i Zm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPldlZG5lc2RheSwgTWF5IDI1LCAyMDE2IGF0 IDg6NDggQU08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj5L ZXl1ciBQYXRlbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtleXVwYXRlQGNpc2NvLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmtleXVwYXRlQGNpc2NvLmNvbTwvYT4mZ3Q7LCAmcXVvdDtBY2VlIExpbmRlbSAo YWNlZSkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzphY2VlQGNpc2NvLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPmFjZWVAY2lzY28uY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWln aHQ6Ym9sZCI+Q2M6IDwvc3Bhbj5CcnVubyBEZWNyYWVuZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJy dW5vLmRlY3JhZW5lQG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj5icnVuby5kZWNyYWVuZUBv cmFuZ2UuY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzppZHJAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5pZHJAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 aWRyQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWRyQGlldGYub3JnPC9hPiZndDssDQogU3Vz YW4gSGFyZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpzaGFyZXNAbmR6aC5jb20iIHRhcmdldD0iX2Js YW5rIj5zaGFyZXNAbmR6aC5jb208L2E+Jmd0OzxzcGFuPjxicj4NCjxzcGFuIHN0eWxlPSJmb250 LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFtJZHJdIGRyYWZ0LWlldGYtaWRyLWJn cC1leHRlbmRlZC1tZXNzYWdlcy0xMiBXRyBMQyAoNS8yNCB0byA2LzcpPGJyPg0KPC9zcGFuPjwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8 ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8ZGl2 PiZuYnNwOzwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFy Z2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0LXdpZHRoOjFweDtib3JkZXItbGVmdC1z dHlsZTpzb2xpZDtib3JkZXItbGVmdC1jb2xvcjpyZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVm dDoxZXgiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQ7Y29sb3I6cmdiKDAsMCww KTtmb250LXNpemU6MTRweDtmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWYiPg0KPHNwYW4+ PHNwYW4+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQ7Y29sb3I6cmdi KDAsMCwwKTtmb250LXNpemU6MTRweDtmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWYiPg0K PGRpdj5BZGRpdGlvbmFsbHksIHdlIGNvdWxkIGRpc2NvdXJhZ2UgdGhlIGdlbmVyYXRpb24gb2Yg YSBzaW5nbGUgTkxSSSBleGNlZWRpbmcgNEsuJm5ic3A7PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9zcGFuPjwvc3Bhbj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk aXY+I0tleXVyOiBZZXAuIEkgYWdyZWUuIDopPC9kaXY+DQo8ZGl2PjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWls eTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0K4oCLVGhlIGVu dGlyZSBpZGVhIGZvciB0aGlzIGRyYWZ0IHdhcyB0cmlnZ2VyZWQgYnkgdGhlIGZlYXIgdGhhdCBC R1BTZWMgbWF5IG5vdCBmaXQgdG8gNEsgdXBkYXRlIG1zZy4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xh c3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fu cy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFp bF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7 Zm9udC1zaXplOnNtYWxsIj4NClRoZSBkcmFmdCBleHBsaWNpdGx5IHN0YXRlcyBzbyBhcyBhIG1v dGl2YXRpb24gZm9yIHRoaXMgd29yay4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2Rl ZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250 LXNpemU6c21hbGwiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBz dHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNt YWxsIj4NClNlY3Rpb24gMTwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9 ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+ DQo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZh bWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KPGRpdiBj bGFzcz0iZ21haWxfZGVmYXVsdCI+Jm5ic3A7ICZuYnNwOyZxdW90O0FzIEJHUCBpcyBleHRlbmRl ZCB0byBzdXBwb3J0IG5ld2VyIEFGSS9TQUZJcyBhbmQgbmV3ZXIgY2FwYWJpbGl0aWVzIChlLmcu LDwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCI+Jm5ic3A7ICZuYnNwO1tJLUQuaWV0 Zi1zaWRyLWJncHNlYy1vdmVydmlld10pLCB0aGVyZSBpcyBhIG5lZWQgdG8gZXh0ZW5kIHRoZSBt YXhpbXVtIG1lc3NhZ2UmbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiPiZu YnNwOyAmbmJzcDtzaXplIGJleW9uZCA0MDk2IG9jdGV0cy4mcXVvdDs8L2Rpdj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZl dGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fu cy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0K4oCLTm93IGluIHR1cm4gdGhlIHJlZmVyZW5jZWQg ZHJhZnQgY2xlYXJseSBkZWZpbmVzIHRoYXQgTkxSSSB3aWxsIG9ubHkgY29udGFpbiBzaW5nbGUg cHJlZml4OiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZv bnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQo8 YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWls eTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KU2VjdGlvbiAz LjI8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTph cmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KPGJyPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVs dmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2Rl ZmF1bHQiPiZuYnNwOyAmbmJzcDsmcXVvdDtXaGVuIGEgQkdQIHNwZWFrZXIgb3JpZ2luYXRlcyBh IEJHUHNlYyB1cGRhdGUgbWVzc2FnZSwgaXQgY3JlYXRlcyBhPC9kaXY+DQo8ZGl2IGNsYXNzPSJn bWFpbF9kZWZhdWx0Ij4mbmJzcDsgJm5ic3A7QkdQc2VjX1BhdGggYXR0cmlidXRlIGNvbnRhaW5p bmcgYSBzaW5nbGUgc2lnbmF0dXJlLiBUaGUgc2lnbmF0dXJlPC9kaXY+DQo8ZGl2IGNsYXNzPSJn bWFpbF9kZWZhdWx0Ij4mbmJzcDsgJm5ic3A7cHJvdGVjdHMgdGhlIE5ldHdvcmsgTGF5ZXIgUmVh Y2hhYmlsaXR5IEluZm9ybWF0aW9uIChOTFJJKSwgdGhlIEFTPC9kaXY+DQo8ZGl2IGNsYXNzPSJn bWFpbF9kZWZhdWx0Ij4mbmJzcDsgJm5ic3A7bnVtYmVyIG9mIHRoZSBvcmlnaW5hdGluZyBBUywg YW5kIHRoZSBBUyBudW1iZXIgb2YgdGhlIHBlZXIgQVMgdG88L2Rpdj4NCjxkaXYgY2xhc3M9Imdt YWlsX2RlZmF1bHQiPiZuYnNwOyAmbmJzcDt3aG9tIHRoZSB1cGRhdGUgbWVzc2FnZSBpcyBiZWlu ZyBzZW50LiBOb3RlIHRoYXQgdGhlIE5MUkkgaW4gYSBCR1BzZWM8L2Rpdj4NCjxkaXYgY2xhc3M9 ImdtYWlsX2RlZmF1bHQiPiZuYnNwOyAmbmJzcDt1cGRhdGUgbWVzc2FnZSBpcyByZXN0cmljdGVk IHRvIGNvbnRhaW4gb25seSBhIHNpbmdsZSBwcmVmaXguJnF1b3Q7PC9kaXY+DQo8L2Rpdj4NCjxi cj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250 LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KUXVl c3Rpb246PC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1p bHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCjxicj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFs LGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQrigItTbyB3aGF0IGV4YWN0 bHkgYXJlIHdlIHRvIGRpc2NvdXJhZ2UgaGVyZSBiZWNhdXNlIGNsZWFybHkgbm90ICZxdW90O2dl bmVyYXRpb24gb2Ygc2luZ2xlIE5MUkkgZXhjZWVkaW5nIDRLJnF1b3Q7ID8mbmJzcDs8L2Rpdj4N CjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2 ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNh bnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCk1heWJlIGRlcGxveW1lbnQgb2YgQkdQU2VjIHRp bGwgYWxsIEJHUCByb3V0ZXJzIGluIHRoZSB3b3JsZCBzdXBwb3J0IHRoaXMgbmV3IGV4dGVuZGVk IG1lc3NhZ2Ugc2l6ZSA/Jm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBz dHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNt YWxsIj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZv bnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQpU aHgsPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6 YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NClIuPC9kaXY+DQo8 ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0 aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCuKAizwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bh bj48L2Rpdj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KSWRyIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJZHJAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5JZHJAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHIiIHJlbD0ibm9yZWZlcnJlciIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRy PC9hPjxicj4NCjxicj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_D36B1BD740862keyupateciscocom_-- From nobody Wed May 25 12:10:18 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6682D12D918 for ; Wed, 25 May 2016 12:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ef-lYw10nng1 for ; Wed, 25 May 2016 12:10:15 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0107.outbound.protection.outlook.com [23.103.200.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52CC812D90E for ; Wed, 25 May 2016 12:10:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PoBJ6C0jgsewvV6/STM8EF/5RPHMbzwvznEttby3sCc=; b=xAKaKbV678iFV8pYXYhDDBF24/Z34xNaJVsFv6AQMXuuPAUtBejYHWjaPiVK2ct0Q/MEwzgS/TJxKZBiXn+pypniJoZLu1Bmj087wOn6sIkOgrcaPiFvLTB9UhNk7TCvRK+1OaJ8eUtJN3ZYkKwEJNvXPxHaHwfdwGh679/rHvU= Received: from BL2PR09MB1123.namprd09.prod.outlook.com (10.167.102.151) by BL2PR09MB1124.namprd09.prod.outlook.com (10.167.102.152) with Microsoft SMTP Server (TLS) id 15.1.506.9; Wed, 25 May 2016 19:10:07 +0000 Received: from BL2PR09MB1123.namprd09.prod.outlook.com ([10.167.102.151]) by BL2PR09MB1123.namprd09.prod.outlook.com ([10.167.102.151]) with mapi id 15.01.0497.022; Wed, 25 May 2016 19:10:07 +0000 From: "Sriram, Kotikalapudi (Fed)" To: "idr@ietf.org" Thread-Topic: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) Thread-Index: AdG2uAW5RuwAT2hmSMiTTx5/liPUlA== Date: Wed, 25 May 2016 19:10:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.140.122] x-ms-office365-filtering-correlation-id: c26162f2-bb23-4163-fb16-08d384d02fb9 x-microsoft-exchange-diagnostics: 1; BL2PR09MB1124; 5:/c9RWi+soy3C06cCX7ouDSo8SWVEQ7i3dN/ag3rBtKxbZ5Nt1YU8nciEPmn2VaU4DUsyb3gEvKnVhCDQyDQIpVkMl0omeyZ/LCbnlDaX5sX54t9wqdoNoOCYC6qdwgjW1GAOefdmQYlxjm/qnDAk1w==; 24:MJdFjEmbXv17un2Ut8fP0xRo/OGNfojd8Rrezt6UT7P9+53likyD5RL2WWAiS9d0Gk0IR1GpA2YZsKcWIF8lpxbuEvLbK4yyaJ7US/KbXXU=; 7:K0SQxP6+r+W5MbVaJv0sI1zEeBMPqQnClsHKgtv91w12u7Xko1Q1z5xE5cDLmwNd1BhhyQHu8i0EAFjtStSk9rwdxqQdU6YYfvf3+xK++ueEXqS54CO4pg7w1J9uQrNov+gY8gPNZjY3qdMsORDRDLjnvSpwtpP9cUZbDLYMopjUp9jMZzF+UD9RHX4gJEi0 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR09MB1124; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:BL2PR09MB1124; BCL:0; PCL:0; RULEID:; SRVR:BL2PR09MB1124; x-forefront-prvs: 09538D3531 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(5003600100002)(99286002)(5640700001)(10400500002)(74316001)(77096005)(450100001)(122556002)(50986999)(5008740100001)(9686002)(5002640100001)(76576001)(92566002)(2906002)(2351001)(189998001)(66066001)(8936002)(6116002)(102836003)(1220700001)(230783001)(87936001)(5004730100002)(81166006)(3660700001)(586003)(1730700003)(8676002)(3280700002)(107886002)(2501003)(110136002)(2900100001)(54356999)(33656002)(11100500001)(3846002)(558084003)(19618925003); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR09MB1124; H:BL2PR09MB1123.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 25 May 2016 19:10:07.2215 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR09MB1124 Archived-At: Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 19:10:17 -0000 I have read the draft and support publication. Sriram From nobody Wed May 25 13:21:06 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 836EF12DC03 for ; Wed, 25 May 2016 13:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cV9L5wlT9WQB for ; Wed, 25 May 2016 13:21:03 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0091.outbound.protection.outlook.com [23.103.200.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AA7212DCF0 for ; Wed, 25 May 2016 13:21:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=I61/xPtPF/i7PLBqSj1CWgyx2kFMZglyJ9YkZGamIno=; b=RYFUOKJRqrZ5/gMzRNHjCjkLyLK4sQk+vCOvtoh/NAJVxyJcpQ86ZATyV7LZ6C+PigG0q90Ieb8NggLV88KNMYsxUEjQZgscfVhrEwWvWQxSDQNMNxun21qkshFwDsmsb/+gxUeT4B/98MspAVz0XaYxAmfRb/FlhsnndHBMLlY= Received: from SN1PR09MB1134.namprd09.prod.outlook.com (10.166.68.152) by SN1PR09MB1133.namprd09.prod.outlook.com (10.166.68.151) with Microsoft SMTP Server (TLS) id 15.1.497.12; Wed, 25 May 2016 20:21:00 +0000 Received: from SN1PR09MB1134.namprd09.prod.outlook.com ([10.166.68.152]) by SN1PR09MB1134.namprd09.prod.outlook.com ([10.166.68.152]) with mapi id 15.01.0497.022; Wed, 25 May 2016 20:21:00 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Robert Raszuk , Keyur Patel Thread-Topic: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) Thread-Index: AdG2uc9G2atAblYvQ1Cxo6CIqPvd8g== Date: Wed, 25 May 2016 20:21:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: raszuk.net; dkim=none (message not signed) header.d=none;raszuk.net; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.140.122] x-ms-office365-filtering-correlation-id: 166277b1-6562-4b41-fbd7-08d384da168e x-microsoft-exchange-diagnostics: 1; SN1PR09MB1133; 5:Cuu9jGJFKZvF/JxGw0sQeC+9KV+45ZSIAfptMl0JnKY7dZi0eQdmcaTZgLgHDmEMYWiNqBL3SSQ9LVSnjzzlodQoQ1gOM1RP7gh8yrdqCsCA1C4PK8kuSuD/cZq1yWFaD/3kNM6II3fAsSKQcMRJzA==; 24:z5PVyHxIlsi6E2/q4cqoLL7lyv9sFozbAcj58agNvYD+IsM7vJ2s6/5k7XZrDyPz8HLup3seWf6FKv7NGFUYisLz/MS2BGPKkf6G0c1xJNs=; 7:mKogzTD07Hhzw5jvA8VNEnDXi1OLFOp28O3eB0WSdve8peTQvJDyVm4SWB3RvkNsJwtXEABZ+FN4Q+jGpfOPpDzGs99eZk5Y1Spr0CLmcqGPHX0Edv4KF0rc0mRZLULXebUJvBrXR+WFIRUMZ8mjzvNLlVLb3jRh/Snd77BsqKCsI6J+gLhwdpQ+urd3T2Pm x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR09MB1133; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:SN1PR09MB1133; BCL:0; PCL:0; RULEID:; SRVR:SN1PR09MB1133; x-forefront-prvs: 09538D3531 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(15650500001)(9686002)(3660700001)(2420400007)(10400500002)(4326007)(3280700002)(8676002)(5002640100001)(2900100001)(54356999)(10710500007)(74316001)(99286002)(2906002)(230783001)(50986999)(76576001)(81166006)(122556002)(33656002)(8936002)(87936001)(15975445007)(5008740100001)(1220700001)(19580395003)(77096005)(5003600100002)(5001770100001)(3846002)(189998001)(7110500001)(102836003)(586003)(6116002)(92566002)(11100500001)(66066001)(5004730100002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR09MB1133; H:SN1PR09MB1134.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 25 May 2016 20:21:00.2453 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR09MB1133 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 20:21:05 -0000 Robert, >I listed 4 alternative solutions earlier in this thread already :).=20 >Dropping NLRI no matter how rare it would be is not one of them. I don't know what other BGP protocol enhancements would=20 ever need to use extended message; but so far we know that BGPsec "may" need to use it=20 (though very rarely, if ever) -- see note below**. And it seems clear that BGPsec would never need to drop the NLRI=20 (including when the peer has not negotiated extended message capability). This is because it is designed so that a BGPsec speaker can convert a BGPse= c=20 update with path signatures to an unsigned BGP message (for forwarding). BGPsec speaker can/will certainly do this conversion under these=20 two circumstances that matter for this discussion: 1. The BGPsec message (that is being forwarded) has a size larger than 4096= , and the peer has not negotiated extended message capability. 2. The peer has negotiated BGP capability but not BGPsec capability. **Note about BGPsec update size: A BGPsec message size=20 can exceed 4096 octets if there are 40 or more unique ASes=20 in the AS path (given that each AS's signature size is no more than=20 72 octets with the ECDSA P-256 algorithm).=20 The currently seen Maximum AS Path Length (eliminating prepends) is 15=20 http://bgp.potaroo.net/as6447/=20 Sriram From nobody Wed May 25 13:28:19 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D06912DCFE for ; Wed, 25 May 2016 13:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtmSma-ZUUvV for ; Wed, 25 May 2016 13:28:15 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0D6C12DD0A for ; Wed, 25 May 2016 13:28:13 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id e131so23613907lfb.0 for ; Wed, 25 May 2016 13:28:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=rc/IRLElhYRpcIllf6RDum8ytWiUC+aKGEtRnvW+nd4=; b=rJU+AR1X9QlWoPh7wIYtQNlZtwpSqNt9qFIYMkI0W9s7fM/HWrRTbRGTw9JCRTNYnM JSmNCM95FP5HBXBcjSnVxDa8HmVxbExc3672WU1EYc7zSUPGwdHfVxwBa2GKM1e16MMo AGvrj1hwPRBN4owN7aEl90NyJt8fjXQHWCcN44Wt1fpvRt8wLWuh7SHRmyrs9jKZLGmr dogJVkQrgPlN0SawylvPRale21s/VRuOIouCALE5oFPwyRZC9U8sBOBb1ZIiYTW5o73p PZ+RNzHZCvx99klTcsThwXTilXp4WTO81mEP1hGoD5453A5Ik2/kdji3SFSFRgAAJ0Ii Y4og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=rc/IRLElhYRpcIllf6RDum8ytWiUC+aKGEtRnvW+nd4=; b=XtHZ9CmOC6q8YEq005ZjS1ei5JDgqTSUdUT3YodzD702cwGbVW6hptylKPOqNPBbVf 8MkVHiCZWU6N80yinaZCTiGqFhI3QRx8AcjU9ZTEnLCVO6554S+054jNZhzltjp4/QS4 reqgX4GUOu82iSpqkTaI6fmI7xDinbQsJ5WhD7zAYgkrtJcNUWZkCOBR3cKqLjcWMrv9 WIDRdO2P93KQmIAEmmRPi4FOi6A6qIXcZHtw2tt4k16au5LqVCQaeE+6EFgctWWb4CEO A5sq3JQVMEBHfBJhpgTE27JPsy2C/UR13c+kHb5VzzkeXYYUjb8EkUOaQDmc+baDIV9S rHxQ== X-Gm-Message-State: ALyK8tLeWUmJOBTSFbbFVDyOhgeTaduIqPCTRidp72WUiOzxNP4EOVghKN9IIE/PmHhW+f8n/s9zCilS7pfMFw== MIME-Version: 1.0 X-Received: by 10.25.87.65 with SMTP id l62mr1402998lfb.4.1464208090524; Wed, 25 May 2016 13:28:10 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.25.134.196 with HTTP; Wed, 25 May 2016 13:28:10 -0700 (PDT) In-Reply-To: References: Date: Wed, 25 May 2016 22:28:10 +0200 X-Google-Sender-Auth: _B5LNl9gKg2KAfBcFDss05eK-mY Message-ID: From: Robert Raszuk To: "Sriram, Kotikalapudi (Fed)" Content-Type: multipart/alternative; boundary=001a11418d401cf7180533b083aa Archived-At: Cc: Keyur Patel , "idr@ietf.org" Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 20:28:17 -0000 --001a11418d401cf7180533b083aa Content-Type: text/plain; charset=UTF-8 Hi Sriram, Well there are other uses for larger BGP message size. Some claim that very long AS_PATH prepend happens today. Yet some other folks would like to use flow spec with a lot of policy to be pushed around (for example some ACLs can be very very long today). So once we open this road and let large tracks on it we can't have pieces of it to remain narrow (unless those wide roads are under private walls) and gateways out of those private ASes can handle it. Best, R. On Wed, May 25, 2016 at 10:21 PM, Sriram, Kotikalapudi (Fed) < kotikalapudi.sriram@nist.gov> wrote: > Robert, > > >I listed 4 alternative solutions earlier in this thread already :). > >Dropping NLRI no matter how rare it would be is not one of them. > > I don't know what other BGP protocol enhancements would > ever need to use extended message; > but so far we know that BGPsec "may" need to use it > (though very rarely, if ever) -- see note below**. > And it seems clear that BGPsec would never need to drop the NLRI > (including when the peer has not negotiated extended message capability). > This is because it is designed so that a BGPsec speaker can convert a > BGPsec > update with path signatures to an unsigned BGP message (for forwarding). > BGPsec speaker can/will certainly do this conversion under these > two circumstances that matter for this discussion: > 1. The BGPsec message (that is being forwarded) has a size larger than > 4096, > and the peer has not negotiated extended message capability. > 2. The peer has negotiated BGP capability but not BGPsec capability. > > > **Note about BGPsec update size: A BGPsec message size > can exceed 4096 octets if there are 40 or more unique ASes > in the AS path (given that each AS's signature size is no more than > 72 octets with the ECDSA P-256 algorithm). > The currently seen Maximum AS Path Length (eliminating prepends) is 15 > http://bgp.potaroo.net/as6447/ > > Sriram > --001a11418d401cf7180533b083aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Sriram,

=
Well there are other uses for larger BGP message s= ize.=C2=A0

Some claim = that very long AS_PATH prepend happens today.=C2=A0

Yet some other folks would like to use flow s= pec with a lot of policy to be pushed around (for example some ACLs can be = very very long today).=C2=A0

So once we open this road and let large tracks on it we can't = have pieces of it to remain narrow (unless those wide roads are under priva= te walls) and gateways out of those private ASes can handle it.=C2=A0
=

Best,
R.





On Wed, May 25, 2016 at 10:21 PM,= Sriram, Kotikalapudi (Fed) <kotikalapudi.sriram@nist.gov&g= t; wrote:
Robert,

>I listed 4 alternative solutions earlier in this thread already :).
>Dropping NLRI no matter how rare it would be is not one of them.=

I don't know what other BGP protocol enhancements would
ever need to use extended message;
but so far we know that BGPsec "may" need to use it
(though very rarely, if ever) -- see note below**.
And it seems clear that BGPsec would never need to drop the NLRI
(including when the peer has not negotiated extended message capability). This is because it is designed so that a BGPsec speaker can convert a BGPse= c
update with path signatures to an unsigned BGP message (for forwarding). BGPsec speaker can/will certainly do this conversion under these
two circumstances that matter for this discussion:
1. The BGPsec message (that is being forwarded) has a size larger than 4096= ,
and the peer has not negotiated extended message capability.
2.=C2=A0 The peer has negotiated BGP capability but not BGPsec capability.<= br>

**Note about BGPsec update size: A BGPsec message size
can exceed 4096 octets if there are 40 or more unique ASes
in the AS path (given that each AS's signature size is no more than
72 octets with the ECDSA P-256 algorithm).
The currently seen Maximum AS Path Length (eliminating prepends) is 15
http://bgp.potaroo.net/as6447/

Sriram

--001a11418d401cf7180533b083aa-- From nobody Wed May 25 18:23:27 2016 Return-Path: <7riw77@gmail.com> X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3F712B058 for ; Wed, 25 May 2016 18:23:26 -0700 (PDT) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wDISoknOxg0 for ; Wed, 25 May 2016 18:23:24 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA4B912B04A for ; Wed, 25 May 2016 18:23:24 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id c127so63300793ywb.1 for ; Wed, 25 May 2016 18:23:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=zSUPGj6L5g3TR3RVV51GvVKPAFQFDbhcqsz7ztHmTB4=; b=ULCAisrOHL6TeAO4dcHB0RaBpHeocKPoUx2lzFJ5wVwl/rPqZGXpAidZ4dXPwdA1xv mNRU2v/ZNeiT8YqMhyKfdsaQFz1boxqASxpXWQZLFY6Rs6xwEEVQK8/n2rxAKOzPH9kw 1Uckx0yhcVi+VW4ZrxjL8/OGWESOn53dpVHCr68AU1ACd4XP+5lhqYHI6MlRDeny/o3s gSw2DNVRmIbU/pKv/0E86QjIwS2pnv/46Xr2NsMjPrKBf/4Ez1lGzLu7xXzjKd23GRMB GPGdePAMQGxA/KVv75bNE4rRVqOL0Im80M2pw55NN/S2YBZ9vriQSrFz7hD4gaSFOQhf M45A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=zSUPGj6L5g3TR3RVV51GvVKPAFQFDbhcqsz7ztHmTB4=; b=c5+ws2BCoyxxEfqNBwFw24tRUhYb+qUWIpux3nG+5u/+CkvCkSEejcaX/NdlC2039s AC/yDMYn5E5LAtk6THWmCGakQJmGO7M7Sg8tWVxYIzB+zBDnZcjfuGb5Jk1yjS6D5b6D 5WtDvzUliSs4Gxth7+YwWfMqaPk36lYeop6fL0qEmM8W563OxQ1e8M8ntLJLXUL26S6w 1+IgD0ZMigPf0XTP9bOhuXEL5h4jne4VnU7IONQfVnSwPHtVLt6RMOith1+4Uzm2Tk8A KxSoIbRSxDbn01TLw5jK4IS+ogpGJ3wZorbF0vcan3t0vLa5NH1do3zHVEsKzEmOL8o7 F0TQ== X-Gm-Message-State: ALyK8tLfo5VSXVKwZZktKc+wUIXlkrPdQnhz6oWXEvTkyk4SmX3rU6o0qAs5wERGvEFfHg== X-Received: by 10.129.81.87 with SMTP id f84mr4123093ywb.154.1464225803898; Wed, 25 May 2016 18:23:23 -0700 (PDT) Received: from Russ (162-229-180-77.lightspeed.rlghnc.sbcglobal.net. [162.229.180.77]) by smtp.gmail.com with ESMTPSA id n11sm1022912ywb.52.2016.05.25.18.23.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 May 2016 18:23:23 -0700 (PDT) From: "Russ White" <7riw77@gmail.com> To: References: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> <20160524205036.GS81971@Vurt.local> In-Reply-To: <20160524205036.GS81971@Vurt.local> Date: Wed, 25 May 2016 21:23:17 -0400 Message-ID: <01b801d1b6ed$2f1dedd0$8d59c970$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJm67g09Bh8eF9lBor3ExN3YMg19QEcwhDLnpcctVA= Content-Language: en-us Archived-At: Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 01:23:26 -0000 > > This begins a 2 week WG LC on draft-ietf-idr-bgp-extended-messages > > (5/24 to 6/7). The draft can be found at: > > > > https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/ Support. :-) Russ From nobody Wed May 25 20:07:22 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF9A12D54F for ; Wed, 25 May 2016 20:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQtQMXjHTptw for ; Wed, 25 May 2016 20:07:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6927812D50C for ; Wed, 25 May 2016 20:07:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CPP49564; Thu, 26 May 2016 03:07:13 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 26 May 2016 04:07:11 +0100 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.169]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Thu, 26 May 2016 11:07:07 +0800 From: Zhuangshunwan To: Susan Hares , "idr@ietf.org" Thread-Topic: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) Thread-Index: AdG19Q0c4DmlRxlfTIa/f3EYODPjkABANB7A Date: Thu, 26 May 2016 03:07:06 +0000 Message-ID: <19AB2A007F56DB4E8257F949A2FB9858AA1C7007@NKGEML515-MBS.china.huawei.com> References: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> In-Reply-To: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.86.254] Content-Type: multipart/alternative; boundary="_000_19AB2A007F56DB4E8257F949A2FB9858AA1C7007NKGEML515MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.57466862.0047, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.169, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d7b960b652d32236a78aeeeb8ee5d32f Archived-At: Cc: "'Keyur Patel \(keyupate\)'" , 'David Ward' Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 03:07:20 -0000 --_000_19AB2A007F56DB4E8257F949A2FB9858AA1C7007NKGEML515MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 U3VwcG9ydC4NCg0KVGhpcyBleHRlbnNpb24gY2FuIGFkZHJlc3MgdGhlIHJlcXVpcmVtZW50IHRo YXQgb25lIEV0aGVybmV0IEEtRCByb3V0ZSBwZXIgRVNJIGNhbiBiZSBpc3N1ZWQgd2l0aCA0ayBS VHMsDQpObyBuZWVkIHRvIHVzZSBhIHNldCBvZiByb3V0ZXMgdGhhdCBlYWNoIHJvdXRlIHVzZSBh IGRpZmZlcmVudCBSRCB0byBjb252ZXkgdGhlIHRvdGFsIG51bWJlciBvZiBSVHMuDQoNCmh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1iZXNzLWV2cG4tdXNhZ2UtMDIudHh0DQo1 LjIuMS4gU2VydmljZSBzdGFydHVwIHByb2NlZHVyZXMNCg0KICAgQXMgc29vbiBhcyB0aGUgRVZJ cyBhcmUgY3JlYXRlZCBpbiBQRTEsIFBFMiBhbmQgUEUzLCB0aGUgZm9sbG93aW5nDQogICBjb250 cm9sIHBsYW5lIGFjdGlvbnMgYXJlIGNhcnJpZWQgb3V0Og0KDQogICBvIEZsb29kaW5nIHRyZWUg c2V0dXAgcGVyIEVWSSAoNGsgcm91dGVzKTogRWFjaCBQRSB3aWxsIHNlbmQgb25lDQogICAgIElu Y2x1c2l2ZSBNdWx0aWNhc3QgRXRoZXJuZXQgVGFnIHJvdXRlIHBlciBFVkkgKHVwIHRvIDRrIHJv dXRlcyBwZXINCiAgICAgUEUpIHNvIHRoYXQgdGhlIGZsb29kaW5nIHRyZWUgcGVyIEVWSSBjYW4g YmUgc2V0dXAuIE5vdGUgdGhhdA0KICAgICBpbmdyZXNzIHJlcGxpY2F0aW9uIG9yIFAyTVAgTFNQ cyBjYW4gb3B0aW9uYWxseSBiZSBzaWduYWxlZCBpbiB0aGUNCiAgICAgUE1TSSBUdW5uZWwgYXR0 cmlidXRlIGFuZCB0aGUgY29ycmVzcG9uZGluZyB0cmVlIGJlIGNyZWF0ZWQuDQoNCiAgIG8gRXRo ZXJuZXQgQS1EIHJvdXRlcyBwZXIgRVNJIChhIHNldCBvZiByb3V0ZXMgZm9yIEVTSTEyKTogQSBz ZXQgb2YNCiAgICAgQS1EIHJvdXRlcyB3aXRoIGEgbGlzdCBvZiA0ayBSVHMgKG9uZSBwZXIgRVZJ KSBmb3IgRVNJMTIgd2lsbCBiZQ0KICAgICBpc3N1ZWQgZnJvbSBQRTEgYW5kIFBFMiAoaXQgaGFz IHRvIGJlIGEgc2V0IG9mIHJvdXRlcyBzbyB0aGF0IHRoZQ0KICAgICB0b3RhbCBudW1iZXIgb2Yg UlRzIGNhbiBiZSBjb252ZXllZCkuIEFzIHBlciBbUkZDNzQzMl0sIGVhY2gNCiAgICAgRXRoZXJu ZXQgQS1EIHJvdXRlIHBlciBFU0kgaXMgZGlmZmVyZW50aWF0ZWQgZnJvbSB0aGUgb3RoZXIgcm91 dGVzDQogICAgIGluIHRoZSBzZXQgYnkgYSBkaWZmZXJlbnQgUm91dGUgRGlzdGluZ3Vpc2hlciAo RVMgUkQpLiBUaGlzIHNldA0KICAgICB3aWxsIGFsc28gaW5jbHVkZSBFU0kgTGFiZWwgZXh0ZW5k ZWQgY29tbXVuaXRpZXMgd2l0aCB0aGUgYWN0aXZlLQ0KICAgICBzdGFuZGJ5IGZsYWcgc2V0IHRv IHplcm8gKGFsbC1hY3RpdmUgbXVsdGktaG9taW5nIHR5cGUpIGFuZCBhbiBFU0kNCiAgICAgTGFi ZWwgZGlmZmVyZW50IGZyb20gemVybyAodXNlZCBmb3Igc3BsaXQtaG9yaXpvbiBmdW5jdGlvbnMp LiBUaGVzZQ0KICAgICByb3V0ZXMgd2lsbCBiZSBpbXBvcnRlZCBieSB0aGUgdGhyZWUgUEVzLCBz aW5jZSB0aGUgUlRzIG1hdGNoIHRoZQ0KICAgICBFVkkgUlRzIGxvY2FsbHkgY29uZmlndXJlZC4g VGhlIEEtRCByb3V0ZXMgcGVyIEVTSSB3aWxsIGJlIHVzZWQgZm9yDQogICAgIGZhc3QgY29udmVy Z2VuY2UgYW5kIHNwbGl0LWhvcml6b24gZnVuY3Rpb25zLCBhcyBkaXNjdXNzZWQgaW4NCiAgICAg W1JGQzc0MzJdLg0KDQpSZWdhcmRzLA0KU2h1bndhbg0KDQoNCreivP7IyzogSWRyIFttYWlsdG86 aWRyLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gU3VzYW4gSGFyZXMNCreiy83KsbzkOiAyMDE2xOo1 1MIyNcjVIDQ6NDINCsrVvP7IyzogaWRyQGlldGYub3JnDQqzrcvNOiAnS2V5dXIgUGF0ZWwgKGtl eXVwYXRlKSc7ICdEYXZpZCBXYXJkJw0K1vfM4jogW0lkcl0gZHJhZnQtaWV0Zi1pZHItYmdwLWV4 dGVuZGVkLW1lc3NhZ2VzLTEyIFdHIExDICg1LzI0IHRvIDYvNykNCg0KVGhpcyBiZWdpbnMgYSAy IHdlZWsgV0cgTEMgb24gZHJhZnQtaWV0Zi1pZHItYmdwLWV4dGVuZGVkLW1lc3NhZ2VzICg1LzI0 IHRvIDYvNykuIFRoZSBkcmFmdCBjYW4gYmUgZm91bmQgYXQ6DQoNCmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaWRyLWJncC1leHRlbmRlZC1tZXNzYWdlcy8NCg0K SW4geW91ciBjb21tZW50cyBwbGVhc2UgcHJvdmlkZSB0aGUgZm9sbG93aW5nIGluZm9ybWF0aW9u Og0KDQoxKSAgICAgIFN1cHBvcnQvobFuby1zdXBwb3J0obEgb2YgdGhpcyBkcmFmdCBiZWluZyBy ZWFkeSBmb3IgcHVibGljYXRpb24sDQoNCjIpICAgICAgWW91IGtub3cgb2YgYW4gaW1wbGVtZW50 YXRpb24gZm9yIHRoaXMgZHJhZnQsIHBsZWFzZSByZXBvcnQgdGhlIGltcGxlbWVudGF0aW9uIHRv IHRoZSBJRFIgV2lraQ0KDQpodHRwczovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvaWRyL3RyYWMv d2lraS9kcmFmdC1pZXRmLWlkci1iZ3AtZXh0ZW5kZWQtaW1wbGVtZW50YXRpb25zDQoNCg0KMykg ICAgICBEbyB5b3UgaGF2ZSBhbnkgY29uY2VybnMgYWJvdXQgZXh0ZW5kaW5nIHRoZSBCR1AgbWVz c2FnZXMuDQoNClN1ZSBIYXJlcyBhbmQgSm9obiBTY3VkZGVyDQo= --_000_19AB2A007F56DB4E8257F949A2FB9858AA1C7007NKGEML515MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Support.

 

This extension can address the requirement that one Ethernet A-D = route per ESI can be issued with 4k RTs,

No need to use a set of routes that each route use a different RD= to convey the total number of RTs.    

 

https://tools.ietf.org/id/draft-ietf-bess-evpn-usage-02.txt=

5.2.1. Service startup procedures

 

   As soon as the EVIs are created in PE1, P= E2 and PE3, the following

   control plane actions are carried out:

 

   o Flooding tree setup per EVI (4k routes)= : Each PE will send one

     Inclusive Multicast Ethernet = Tag route per EVI (up to 4k routes per

     PE) so that the flooding tree= per EVI can be setup. Note that

     ingress replication or P2MP L= SPs can optionally be signaled in the

     PMSI Tunnel attribute and the= corresponding tree be created.

 

   o Ethernet A-D routes per ESI (a set of routes for = ESI12): A set of

     A-D routes with a l= ist of 4k RTs (one per EVI) for ESI12 will be

     issued from PE1 and= PE2 (it has to be a set of routes so that the

     total number of RTs= can be conveyed). As per [RFC7432], each

     Ethernet A-D route per ESI is= differentiated from the other routes

     in the set by a different Rou= te Distinguisher (ES RD). This set

     will also include ESI Label e= xtended communities with the active-

     standby flag set to zero (all= -active multi-homing type) and an ESI

     Label different from zero (us= ed for split-horizon functions). These

     routes will be imported by th= e three PEs, since the RTs match the

     EVI RTs locally configured. T= he A-D routes per ESI will be used for

     fast convergence and split-ho= rizon functions, as discussed in

     [RFC7432].<= /p>

 

Regards,

Shunwan

 

 

=B7=A2=BC=FE=C8=CB: Idr [ma= ilto:idr-bounces@ietf.org] =B4=FA= =B1=ED Susan Hares
=B7=A2= =CB=CD=CA=B1=BC=E4: 2016=C4=EA5=D4=C225=C8=D5 4:42
=CA=D5=BC=FE=C8=CB: idr@ietf.org
=B3=AD=CB=CD: 'Keyur Patel (keyupate)'; 'David Ward'
=D6=F7=CC=E2: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7)

 

This begins a 2 week WG LC on d= raft-ietf-idr-bgp-extended-messages (5/24 to 6/7). The draft can be found a= t:

 

https://datatracker.iet= f.org/doc/draft-ietf-idr-bgp-extended-messages/

 

In your comments please provide= the following information:

1) &nbs= p;    Support/=A1=B1no-suppor= t=A1=B1 of this draft being ready for publication,

2) &nbs= p;    You know of an implemen= tation for this draft, please report the implementation to the IDR Wiki

 

https://trac.tools.ietf.org/wg/idr/trac/wiki/draft-= ietf-idr-bgp-extended-implementations

 

3) &nbs= p;    Do you have any concern= s about extending the BGP messages.

 

Sue Hares and John Scudder

--_000_19AB2A007F56DB4E8257F949A2FB9858AA1C7007NKGEML515MBSchi_-- From nobody Thu May 26 02:18:54 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79CE612D575 for ; Thu, 26 May 2016 02:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.344 X-Spam-Level: X-Spam-Status: No, score=-3.344 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5WThkNwmtui for ; Thu, 26 May 2016 02:18:50 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF4F112B026 for ; Thu, 26 May 2016 02:18:49 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id BA971205EE; Thu, 26 May 2016 11:18:48 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.32]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 729CB2006A; Thu, 26 May 2016 11:18:48 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0294.000; Thu, 26 May 2016 11:18:48 +0200 From: To: "Keyur Patel (keyupate)" Thread-Topic: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) Thread-Index: AQHRtp4l8Ct7z+m8+kGFNAEsHjbc55/K6Kxg Date: Thu, 26 May 2016 09:18:47 +0000 Message-ID: <15012_1464254328_5746BF78_15012_699_1_53C29892C857584299CBF5D05346208A0F8D0469@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> <13146_1464170675_574578B3_13146_4888_1_53C29892C857584299CBF5D05346208A0F8CD227@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A0F8D0469OPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" , Susan Hares Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 09:18:53 -0000 --_000_53C29892C857584299CBF5D05346208A0F8D0469OPEXCLILM21corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Keyur, Thanks for considering my comments and your prompt answer. Please see inlined #Bruno From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] Sent: Wednesday, May 25, 2016 5:58 PM To: DECRAENE Bruno IMT/OLN; Susan Hares Cc: idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6= /7) Hi Bruno, Many thanks for the review. Comments inlined #Keyur From: Bruno Decraene > Date: Wednesday, May 25, 2016 at 3:04 AM To: Susan Hares >, Keyur Patel > Cc: "idr@ietf.org" > Subject: RE: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6= /7) Hi, 1) Support. 2) Question, for my own information: why does the capability mean that= the BGP speaker is capable of _both_ receiving _and sending_ extend messa= ge? (vs capable of receiving (only)). IOTW, what is the motivation to adver= tise the capacity to send extended message? #Bruno: You may have missed the above question? It's linked to some of the = below comments, so even though it's not a comment, it's useful to me / this= thread. Thanks 3) Please find below some possible comments: "4. Operation" Suppose that I receive an extended BGP message (e.g. update) that I can't r= elay to some peers because they don't support such extension, while I "shou= ld" have relayed it. Is there an expected behavior? Should it be standardiz= ed? Can this create issues (e.g. inconsistent routing with an AS)? Should t= his be considered in the security considerations? (e.g. I deliberately send= an extended message, and benefit from its/the NLRI not being propagated as= expected. e.g. to influence routing policy) #Keyur: Clients would receive internal routes as long as a RR can announce = prefixes using existing message length (of 4K). It would be using multiple = messages limited to 4K length. #Bruno: Agreed. Alternatively, if the attribute size is such that the message length does = get exceeded then the Prefix SHOULD not be announced and an error should be= logged (existing case). #Bruno: That was indeed the issue I had in mind. I'm not seeing this point in the draft. Could this be added? Plus the conse= quences both within an AS and across ASes, in particular to raise this poin= t to network operator (which may deploy this) and protocol designed (which = may want to use it). This is partly similar to the "treat as withdraw" behavior described in RFC= 7606, so you may want to reuse existing text. cf "Operational Consideration= s" https://tools.ietf.org/html/rfc7606#section-6 In particular "we note that if an UPDATE message received on an Internal BGP (IBGP) session is subjected to this treatment, inconsistent routing within the affected Autonomous System may result. The consequences of inconsistent routing can include long-lived forwarding loops and black holes. > [...] < Even if inconsistent routing does not arise, the "treat-as-withdraw" behavior can cause either complete unreachability or suboptimal routing for the destinations whose routes are carried in the affected UPDATE message. > [...] "Because of these potential issues, a BGP speaker must provide debugging facilities to permit issues caused by a malformed attribute to be diagnosed. > An in term of warning to network operator and protocol designer, something = along the following lines "Network operator needing to advertise within its AS a BGP route which siz= e would require a BGP message larger than 4096 octets, SHOULD enabled this = Extended Message capability on all BGP speaker needing to receive this rout= es. Failure to do so may result in inconsistent routing within its AS, as d= escribed above". "A protocol designer or network operator needing to advertise, outside of i= ts AS, a BGP route which size would require a BGP message larger than 4096 = octets should take into account that it has no guarantee that its route wil= l be propagated as expected as a downstream BGP speaker might not be compli= ant or might not has enabled BGP extended messages and hence will not propa= gate the route. This is especially the case if one expect Internet wide pro= pagation of its route, which seems highly improbable until a few years/deca= des". We could add the IPv6 example, to illustrate the time needed to deploy a ne= w feature across the Internet, but I guess this would trigger some negative= reactions. ---- #Bruno This document does not define the default behavior with regards to the adve= rtisement of the capability. IMO, this point may impact the deployability o= f features using extended message and the security consideration. May be it= should be enabled by default on IBGP session and disabled by default on EB= GP sessions. -- "A BGP speaker may send extended messages to its peer only if it has receiv= ed the Extended Message Capability from its peer." May be :s/received/sent and received --- #Keyur: A capability announcement indicates an ability to "receive and pars= e" extended messages. In that context "receive" is good enough? #Bruno: I agree with you in general, but this is not was this document stat= es. "By advertising the BGP Extended Message Capability to a peer, a BGP sp= eaker conveys that it is able to send, receive, and properly handle BGP Ext= ended Messages. > " A BGP speaker that has the ability to use extended messages but has not advertised the BGP Extended Messages capability, presumably due to configuration, SHOULD NOT accept an extended message. A speaker MAY implement a more liberal policy and accept extended messages even from a peer that has not advertised the capability." I would a priori have assumed that both sentences be related. But in fact t= hey are not since the first sentence only refers to the sending of the capa= bility, while the second only refers to the reception of the capability. Sh= ouldn't both sentences be extended to cover both the sending and the receiv= ing? -- #Keyur: We wanted to be explicit in error handling section. :) Again, the c= apability meaning is to be able to "receive and parse". #Bruno: Again same comment. _This_ document has defined the capability to m= ean "send, receive and parse". "A speaker that treats an improper extended message as a fatal error, as described in the preceding paragraph, MUST do likewise. > I'm sorry but I don't understand this sentence. What does that mean to "tre= at an improper extended message as a fatal error"? e.g. If I receive an ext= ended message with a syntax error requiring to send an NOTIFICATION (e.g. m= ore than one MP_REACH_NLRI) is this considered an improper extended messag= e with a fatal error? If so the text seems wrong as bgp speaker must not do= "likewise" (seems to refer to "reset the session with a Bad Message Leng= th NOTIFICATION") Also "as described in the preceding paragraph, MUST do likewise" seems not = precise enough to me (at least as a non-native English speaker). Which exac= tly is this preceding paragraph describing this "treats an improper extende= d message as a fatal error" --- #Keyur: The text is meant for a BGP speaker that doesn't announce extended= message capability AND doesn't support extended messages implementation (o= ld style peer). Such a peer would consider a receipt of an extended message= as a malformed message. #Bruno: ok, thanks for the clarification. I'm not sure to see the value of = the quoted sentence. You are making a distinction/specific sub-case (a BGP = which handled error as fatal error), to say that the behavior is the same. = So it looks like removing the sentence would have the same effect. (no need= for a specific case) 7. IANA Considerations "The IANA is requested to register a new BGP Capability Code to be named BG= P Extended Message Capability > I'm not sure about the formulation since IANA has already registered this c= apability as TEMPORARY. "TBD BGP-Extended Message" At least I would expect that the document ask for the _same_ value (6) rath= er than TBD. #Keyur: Ack. Regards, Keyur Thanks, Regards, Bruno From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, May 24, 2016 10:42 PM To: idr@ietf.org Cc: 'Keyur Patel (keyupate)'; 'David Ward' Subject: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) This begins a 2 week WG LC on draft-ietf-idr-bgp-extended-messages (5/24 to= 6/7). The draft can be found at: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/ In your comments please provide the following information: 1) Support/"no-support" of this draft being ready for publication, 2) You know of an implementation for this draft, please report the imp= lementation to the IDR Wiki https://trac.tools.ietf.org/wg/idr/trac/wiki/draft-ietf-idr-bgp-extended-im= plementations 3) Do you have any concerns about extending the BGP messages. Sue Hares and John Scudder ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_53C29892C857584299CBF5D05346208A0F8D0469OPEXCLILM21corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Keyu= r,

&n= bsp;

Thanks = for considering my comments and your prompt answer.

Please = see inlined #Bruno

&n= bsp;

From: Keyur Pa= tel (keyupate) [mailto:keyupate@cisco.com]
Sent: Wednesday, May 25, 2016 5:58 PM
To: DECRAENE Bruno IMT/OLN; Susan Hares
Cc: idr@ietf.org
Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/= 24 to 6/7)

 

Hi Brun= o,

&n= bsp;

Many th= anks for the review. Comments inlined #Keyur

&n= bsp;

From: Bruno Decraene <bruno.decraene@orange.com>
Date: Wednesday, May 25, 2016 at 3:04 AM
To: Susan Hares <shares@ndzh.c= om>, Keyur Patel <keyupate@= cisco.com>
Cc: "idr@ietf.org" <= ;idr@ietf.org>
Subject: RE: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/= 24 to 6/7)

&n= bsp;

Hi,

 

1)&nb= sp;     Support.

 

2)&nb= sp;     Question, for my own information: why does the capability mean that the BG= P speaker is capable of _both_  receiving _and sending_ = extend message? (vs capable of receiving (only)). IOTW, what is the motivation to advertise the capacity to send ex= tended message?

 

#Bruno:= You may have missed the above question? It’s linked to some of the b= elow comments, so even though it’s not a comment, it’s useful t= o me / this thread. Thanks

 <= /span>

3)      Please find below some possible comments:

 <= /span>

“4.  Operation”
Suppose that I receive an e=
xtended BGP message (e.g. update) that I can’t relay to some peers be=
cause they don’t support such extension, while I “should”=
 have relayed it. Is there an expected behavior? Should it be standardized?=
 Can this create issues (e.g. inconsistent routing with an AS)? Should this=
 be considered in the security considerations? (e.g. I deliberately send an=
 extended message, and benefit from its/the NLRI not being propagated as ex=
pected. e.g. to influence routing policy)

 <= /span>

&n= bsp;

#Keyur:= Clients would receive internal routes as long as a RR can announce prefixe= s using existing message length (of 4K). It would be using multiple message= s limited to 4K length.

#Bruno:= Agreed.

 Alternatively, if the attribute size is such that the message= length does get exceeded then the Prefix SHOULD not be announced and an er= ror should be logged (existing case).

#Bruno:= That was indeed the issue I had in mind.

I’= ;m not seeing this point in the draft. Could this be added? Plus the conseq= uences both within an AS and across ASes, in particular to raise this point= to network operator (which may deploy this) and protocol designed (which may want to use it).

This is partly similar to the “treat as=
 withdraw” behavior described in RFC7606, so you may want to reuse ex=
isting text. cf “Operational Considerations” https://tools.ietf.org/html/rfc7606=
#section-6 In particular
 “we note

   that if an UPDATE message rece= ived on an Internal BGP (IBGP) session

   is subjected to this treatment= , inconsistent routing within the

   affected Autonomous System may= result.  The consequences of

   inconsistent routing can inclu= de long-lived forwarding loops and

   black holes. »

[…]

« Even if inconsistent routing d= oes not arise, the "treat-as-withdraw"

   behavior can cause either comp= lete unreachability or suboptimal

   routing for the destinations w= hose routes are carried in the affected

   UPDATE message. »

[…]

“Because of these potential issues, a= BGP speaker must provide

   debugging facilities to permit= issues caused by a malformed attribute

   to be diagnosed. »&= nbsp;

 

 

An in t= erm of warning to network operator and protocol designer, something along t= he following lines

“= Network operator needing to advertise within its AS  a BGP route which= size would require a BGP message larger than 4096 octets, SHOULD enabled t= his Extended Message capability on all BGP speaker needing to receive this routes. Failure to do so may result in inconsisten= t routing within its AS, as described above”.

“= A protocol designer or network operator needing to advertise, outside of it= s AS, a BGP route which size would require a BGP message larger than 4096 o= ctets should take into account that it has no guarantee that its route will be propagated as expected as a downstream BG= P speaker might not be compliant or might not has enabled BGP extended mess= ages and hence will not propagate the route. This is especially the case if= one expect Internet wide propagation of its route, which seems highly improbable until a few years/decades̶= 1;.

&n= bsp;

We coul= d add the IPv6 example, to illustrate the time needed to deploy a new featu= re across the Internet, but I guess this would trigger some negative reacti= ons.

&n= bsp;

----

&n= bsp;

#Bruno<= o:p>

This do= cument does not define the default behavior with regards to the advertiseme= nt of the capability. IMO, this point may impact the deployability of featu= res using extended message and the security consideration. May be it should be enabled by default on IBGP session and = disabled by default on EBGP sessions.

 

 

--

“A BGP speaker may se=
nd extended messages to its peer only if it has received the Extended Messa=
ge Capability from its peer.”=

May be :s/received/sent and received

---

#Keyur:= A capability announcement indicates an ability to "receive and parse&= quot; extended messages. In that context “receive” is good enou= gh?

#Bruno: I agree with you in general, but this=
 is not was this document states. “By adv=
ertising the BGP Extended Message Capability to a peer, a BGP speaker conve=
ys that it is able to send, rec=
eive, and properly handle BGP Extended Messages. »

&n= bsp;

 

 

“   A BGP s=
peaker that has the ability to use extended messages but has
   not advertised=
 the BGP Extended Messages capability, presumably due
   to configurati=
on, SHOULD NOT accept an extended message.  A speaker
   MAY implement =
a more liberal policy and accept extended messages even
   from a peer th=
at has not advertised the capability.”

 <= /span>

I would= a priori have assumed that both sentences be related. But in fact they are= not since the first sentence only refers to the sending of the capability,= while the second only refers to the reception of the capability. Shouldn’t both sentences be extended to cover bot= h the sending and the receiving?

--

#Keyur:= We wanted to be explicit in error handling section. :) Again, the capabili= ty meaning is to be able to “receive and parse”.

#Bruno:= Again same comment. _This_ document has defined the capability to m= ean “send, receive and parse”.

 

 <= /span>

“A speaker that treat=
s an improper extended message as a=

   fatal error, a=
s described in the preceding paragraph, MUST do
   likewise. =
;»

I’= ;m sorry but I don’t understand this sentence. What does that mean to= “treat an improper extended message as a fatal error”? e.g. If= I receive an extended message with a syntax error requiring to send an NOTIFICATION (e.g. more than one MP_REACH_NLRI)  is this cons= idered an improper extended message with a fatal error? If so the text seem= s wrong as bgp speaker must not do “likewise” (seems to refer t= o “reset the session   with a Bad Message Length NOTIFICATION”)<= /p> 

Also “as described in the preceding paragraph, MUST do likewise&=
#8221; seems not precise enough to me (at l=
east as a non-native English speaker). Which exactly is this preceding para=
graph describing this “treats an improper extended message as a fatal error”=

---

&n= bsp;

#Keyur:=  The text is meant for a BGP speaker that doesn’t announce exte= nded message capability AND doesn’t support extended messages impleme= ntation (old style peer). Such a peer would consider a receipt of an extended message as a malformed message. <= /span>

#Bruno:= ok, thanks for the clarification. I’m not sure to see the value of t= he quoted sentence. You are making a distinction/specific sub-case (a BGP w= hich handled error as fatal error), to say that the behavior is the same. So it looks like removing the sentence would hav= e the same effect. (no need for a specific case)

 

7.  IANA Considerations
“The IANA is requeste=
d to register a new BGP Capability Code to be named BGP Extended Message Ca=
pability »<=
/pre>

I’m not sure about the formulation sinc=
e IANA has already registered this capability as TEMPORARY.


 


“TBD   =
;   BGP-Extended Message”


At least I would expect that the document ask=
 for the _same_ value (6) rather than TBD.

&n= bsp;

#Keyur:= Ack.

&n= bsp;

Regards= ,

Keyur

 
 
Thanks,
Regards,
Bruno=

 <= /span>

 <= /span>

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Tuesday, May 24, 2016 10:42 PM
To: idr@ietf.org
Cc: 'Keyur Patel (keyupate)'; 'David Ward'
Subject: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 t= o 6/7)

 

This begi= ns a 2 week WG LC on draft-ietf-idr-bgp-extended-messages (5/24 to 6/7). Th= e draft can be found at:

 

https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/=

 

In your c= omments please provide the following information:

1)&nb= sp;     S= upport/”no-support” of this draft being ready for publication,<= /span>

2)&nb= sp;     Y= ou know of an implementation for this draft, please report the implementati= on to the IDR Wiki

 

https://trac.tools.ietf.org/w= g/idr/trac/wiki/draft-ietf-idr-bgp-extended-implementations

 

3)&nb= sp;     D= o you have any concerns about extending the BGP messages.

 

Sue Hares= and John Scudder 

__________________________________________=
___________________________________________________________________________=
____
 
Ce message et ses pieces jointes peuvent c=
ontenir des informations confidentielles ou privilegiees et ne doivent donc=

pas etre diffuses, exploites ou copies san=
s autorisation. Si vous avez recu ce message par erreur, veuillez le signal=
er
a l'expediteur et le detruire ainsi que le=
s pieces jointes. Les messages electroniques etant susceptibles d'alteratio=
n,
Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may conta=
in confidential or privileged information that may be protected by law;
they should not be distributed, used or co=
pied without authorisation.
If you have received this email in error, =
please notify the sender and delete this message and its attachments.<=
/o:p>
As emails may be altered, Orange is not li=
able for messages that have been modified, changed or falsified.=

Thank you.
______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_53C29892C857584299CBF5D05346208A0F8D0469OPEXCLILM21corp_-- From nobody Thu May 26 04:20:19 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB5B12DD39 for ; Thu, 26 May 2016 04:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aureuA6jSRxP for ; Thu, 26 May 2016 04:20:17 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88B0F12DA1E for ; Thu, 26 May 2016 04:20:10 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id w16so18897074lfd.2 for ; Thu, 26 May 2016 04:20:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=RW5eT8cayYalb21Szp1L4LaP+K54rLLoBaaBfwhE5eQ=; b=YF2QZXCYChzFcay9EcLt42oYylTCK+P61t4nTlznCG1vFzWt6XaybXdCn1UG3hQv17 eJUseJAmxxiGYHCAfACBsipp0Ro9KX8LAQwMn75tgGzbsJvt/UUVm7FxjNlA2ruX2jLA 38XJEwmxnfGtpdtHbMXsxzAYz4Qf3I2TS7QCPzFhI6Dk8HDASX25lgU5ldQqljLEQlAJ fND7fb0N+l/njwOMNOLrw1JVivS5rqeHwo4mzop0jzeE+Uq9Bz6X3X/tnT0fMY9pYPsW Y4irm20oJtDFyl0b1OZalwwJsvyET5/f+nTG5rO68/Csd8ZhM7+qmHLep+80t3ieV7p1 J6Mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=RW5eT8cayYalb21Szp1L4LaP+K54rLLoBaaBfwhE5eQ=; b=YPaOtYkRxOO1/VGSOC7qDkkXJAApzWE9pbsOqfkgeynOfue3REsQBg9Y7OwlSzTsLz dTtKjsJb2G2Efh1bnrBebjcRV0s3CZJobo/z/EuWzbaX4Ybi328xcmCmxa59XLv3n+Wv FbAJGdxPGTmrtpdggjT7A0whastS76zrrNprtNo4NOzIAOs3XZDJ8XyOFca+LtLiUqdq +VXr1y5VCLmq7OKaXx+R/HTMzr0SWNJ2L+10V2pOGbks9/87h+RgtjnRmxZodjfxFnf/ UzhpNqtwN2NKdubYNw5tHk1OhE1IIoizcRbvVg6ewsdL/+lJf/qRLteTe0LXVPejl1Lx 0W6A== X-Gm-Message-State: ALyK8tKr0SL0PM8LW5nY/X4ZqdUWNvSWCh3jCJysWJ3NXejtUDEvbvEYPgWuYDcxfAFwjgTml4w7REO3raEAiA== MIME-Version: 1.0 X-Received: by 10.25.87.65 with SMTP id l62mr2209372lfb.4.1464261608358; Thu, 26 May 2016 04:20:08 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.25.134.196 with HTTP; Thu, 26 May 2016 04:20:08 -0700 (PDT) In-Reply-To: <15012_1464254328_5746BF78_15012_699_1_53C29892C857584299CBF5D05346208A0F8D0469@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> <13146_1464170675_574578B3_13146_4888_1_53C29892C857584299CBF5D05346208A0F8CD227@OPEXCLILM21.corporate.adroot.infra.ftgroup> <15012_1464254328_5746BF78_15012_699_1_53C29892C857584299CBF5D05346208A0F8D0469@OPEXCLILM21.corporate.adroot.infra.ftgroup> Date: Thu, 26 May 2016 13:20:08 +0200 X-Google-Sender-Auth: bLhSdHDQRFp7ScgW9Jw3kYIa5dg Message-ID: From: Robert Raszuk To: Bruno Decraene Content-Type: multipart/alternative; boundary=001a11418d40064fe60533bcf9a9 Archived-At: Cc: "Keyur Patel \(keyupate\)" , "idr@ietf.org" , Susan Hares Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 11:20:19 -0000 --001a11418d40064fe60533bcf9a9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Bruno/all, =E2=80=9CA protocol designer or network operator needing to advertise, outs= ide of > its AS, a BGP route which size would require a BGP message larger than 40= 96 > octets should take into account that it has no guarantee that its route > will be propagated as expected as a downstream BGP speaker might not be > compliant or might not has enabled BGP extended messages and hence will n= ot > propagate the route. This is especially the case if one expect Internet > wide propagation of its route, which seems highly improbable until a few > years/decades=E2=80=9D. > =E2=80=8BThe above text which very true triggered few more observations: =E2=80=8B- As this is WG last call implementation report (even on the wiki = should be available) Can we get a pointer to it ? I do not see it on the IETF page= : https://www.ietf.org/iesg/implementation-report.html - Did implementation report (if even completed) included the set of test cases say with large AS_PATH or long Extended Community (stuffing a lot of RTs as described in RTC backwards compatibility work) to make sure that most popular BGP implementation can handle such large attributes without crashing ? Otherwise enabling this would be an excellent attack vector in the Internet. - Do we have an agreement that this will not be "ON" by default, but will be enabled only with a knob ? - How do we detect if this is supported across the private AS/public Internet zoo of routers ? Should we have a protocol tool which would allow to detect support of extended messages at each BGP speaker and if not report this as an error to the originator of the large message ? Sending large BGP message if not supported by any remote peer by any BGP speaker along the propagation would trigger reporting it back with new ICMP error could be one approach. I am sure there would be others ... Thx, r. --001a11418d40064fe60533bcf9a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Bruno/all,
<= br>

=E2=80=9CA protocol designer or network op= erator needing to advertise, outside of its AS, a BGP route which size woul= d require a BGP message larger than 4096 octets should take into account th= at it has no guarantee that its route will be propagated as expected as a downstream BG= P speaker might not be compliant or might not has enabled BGP extended mess= ages and hence will not propagate the route. This is especially the case if= one expect Internet wide propagation of its route, which seems highly improbable until a few years/decades=E2= =80=9D.


=
=E2=80=8BThe above text which very true t= riggered few more observations:

=E2=80=8B- As this is WG last call implementation report (even on= the wiki should be available) Can we get a pointer to it ? I do not see it= on the IETF page:
https://www.ietf.org/iesg/implementation-report.htm= l

- Did implementation report (if even completed) included th= e set of test cases say with large AS_PATH or long Extended Community (stuf= fing a lot of RTs as described in RTC backwards compatibility work) to make= sure that most popular BGP implementation can handle such large attributes= without crashing ? Otherwise enabling this would be an excellent attack ve= ctor in the Internet.

= - Do we have an agreement that this will not be "ON" by default, = but will be enabled only with a knob ?=C2=A0

- How do we detect if this is supported across the p= rivate AS/public Internet zoo of routers ? Should we have a protocol tool w= hich would allow to detect support of extended messages at each BGP speaker= and if not report this as an error to the originator of the large message = ? Sending large BGP message if not supported by any remote peer by any BGP = speaker along the propagation would trigger reporting it back with new ICMP= error could be one approach. I am sure there would be others ...

Thx,
r.=

--001a11418d40064fe60533bcf9a9-- From nobody Thu May 26 04:35:15 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C37B612DDDD for ; Thu, 26 May 2016 04:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjQo-7MmSQ49 for ; Thu, 26 May 2016 04:35:12 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F50412DE0E for ; Thu, 26 May 2016 04:34:40 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1b5tYk-0004zF-MF; Thu, 26 May 2016 11:34:38 +0000 Date: Thu, 26 May 2016 13:34:37 +0200 Message-ID: From: Randy Bush To: Robert Raszuk In-Reply-To: References: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> <13146_1464170675_574578B3_13146_4888_1_53C29892C857584299CBF5D05346208A0F8CD227@OPEXCLILM21.corporate.adroot.infra.ftgroup> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: idr wg list Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 11:35:14 -0000 packing is not relevant. receiver unpacks if nlri are packed, and as a sender decides whether and how densly to pack or not. if the outbound link is smaller than the inbound, pack in less nlri. if it is the attributes that over-flow, then you have a more general problem. if we are in the bgpsec space, o will a single nlri with a signed path fit in the extended message? yes. even degenerate prepends don't hurt because of the pCount hack. o if there is an outbound that is not a bgpsec speaker, they will be sent a classic as4_path which darn well should fit in the classic message size. if there is prepend insanity, that would die today. o if the outbound is a bgpsec speaker yet will not use an extended message size, there is one interesting case, the singleton stub. a non-transit router can sign toward its upstream(s) and not care about receiving bgsec as it has no other choice of where to send packets. randy From nobody Thu May 26 04:58:40 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C85312DE50 for ; Thu, 26 May 2016 04:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h_KWgP05vE5m for ; Thu, 26 May 2016 04:58:36 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2691012DE45 for ; Thu, 26 May 2016 04:58:36 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id b73so9013469lfb.3 for ; Thu, 26 May 2016 04:58:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=8zpe+POdaUuwgoUm4wYjEp5KUXc3mc8ev6gV7KEVzX8=; b=Xi7BpxA385zIZqwRXGyl828j0VvyiCyCWdq4mHSUhUdEU+WY6KdQxn7M+jCvEQpVIj BMQVYco8p0BLSng4NNCbg2XqYW/FrfVusg/RdVaQ7KNWWbGO1tNU/TRnHkcIyEW5QcLw FUfUZHBS4LYpusfBpTvCPfhF+ybV4gLPdT3BdA5dNj8rpjltGJv4Pjby8/hcfvtHU/pE cqcJX0OMzMIUIOlgLo7oRjSBXDmtwNjT8KPnyLllNqOVXxU4Nm0ZeCbE61nXqmPCs8Cz JPbzzmaIWke762GLO122kTxX3kJJMoQFaOGAYbV1cazQ9C9kP3Xv72GHLFvBbgh2XXus XYCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=8zpe+POdaUuwgoUm4wYjEp5KUXc3mc8ev6gV7KEVzX8=; b=LeKRKZpQsQAZqX+mDS3ZpzhZ5ldn/NBatYGzJy7PkFSLmS/z9Q9BWHCsqDtZEuNgOp oyphUPEEfNP5NDYLOx+jYov5uR30f10eEHa4+9ArozNTjHkatd+0KWdJVcPYp0LKYv8g 4ILrHranARS3qrnrHmEH3r704xr5He/pSO54aH2BftIxCkf9tfCygdzRkYhPaiEH1tmw y71rbLKuSsrMypRxL2nktpzbw8ELaAanrvd0JBiLLATjBstEfbnd5U0cKyf31gj+H2Gq iri7iAikgl9qvFEY21M/MsPc1hKp8pMuy/1QZgjqctcyBeg/boDFMocatAjR8pqo/eGy uzyQ== X-Gm-Message-State: ALyK8tLHMFw7evXF6azWtoFEiv4pCtDvSdISh+UCX+l9yEHnuxcY+bGQ/P8Yo/Xw2nIXB/RCdM/DHoctuXStEQ== MIME-Version: 1.0 X-Received: by 10.46.5.82 with SMTP id 79mr77592ljf.64.1464263913849; Thu, 26 May 2016 04:58:33 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.25.134.196 with HTTP; Thu, 26 May 2016 04:58:33 -0700 (PDT) In-Reply-To: References: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> <13146_1464170675_574578B3_13146_4888_1_53C29892C857584299CBF5D05346208A0F8CD227@OPEXCLILM21.corporate.adroot.infra.ftgroup> Date: Thu, 26 May 2016 13:58:33 +0200 X-Google-Sender-Auth: H4wzPjGl8gMFdoP-LsWg8BHKlNs Message-ID: From: Robert Raszuk To: Randy Bush Content-Type: multipart/alternative; boundary=001a1148e6f0714e120533bd8227 Archived-At: Cc: idr wg list Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 11:58:39 -0000 --001a1148e6f0714e120533bd8227 Content-Type: text/plain; charset=UTF-8 > if there is prepend insanity, that would die today. The difference is that today it will immediately die at yr peer and it is very easy to detect. Same for other attributes which can take tons of stuff loaded on them today. With extended message it will die few hops away likely in different AS and to detect it will be quite hard without proper tool. Thx, R. On Thu, May 26, 2016 at 1:34 PM, Randy Bush wrote: > packing is not relevant. receiver unpacks if nlri are packed, and as a > sender decides whether and how densly to pack or not. if the outbound > link is smaller than the inbound, pack in less nlri. if it is the > attributes that over-flow, then you have a more general problem. > > if we are in the bgpsec space, > > o will a single nlri with a signed path fit in the extended message? > yes. even degenerate prepends don't hurt because of the pCount > hack. > > o if there is an outbound that is not a bgpsec speaker, they will be > sent a classic as4_path which darn well should fit in the classic > message size. if there is prepend insanity, that would die today. > > o if the outbound is a bgpsec speaker yet will not use an extended > message size, there is one interesting case, the singleton stub. > a non-transit router can sign toward its upstream(s) and not care > about receiving bgsec as it has no other choice of where to send > packets. > > randy > --001a1148e6f0714e120533bd8227 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

> =C2=A0if there is prepe= nd insanity, that would die today.

<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small">The difference is that today it will immediately die at yr peer and it= is very easy to detect. Same for other attributes which can take tons of s= tuff loaded on them today.

With= extended message it will die few hops away likely in different AS and to d= etect it will be quite hard without proper tool.

Thx,
R.





On Thu, May 26, = 2016 at 1:34 PM, Randy Bush <randy@psg.com> wrote:
packing is not relevant.=C2=A0 receiver unpacks if nlr= i are packed, and as a
sender decides whether and how densly to pack or not.=C2=A0 if the outbound=
link is smaller than the inbound, pack in less nlri.=C2=A0 if it is the
attributes that over-flow, then you have a more general problem.

if we are in the bgpsec space,

=C2=A0 o will a single nlri with a signed path fit in the extended message?=
=C2=A0 =C2=A0 yes.=C2=A0 even degenerate prepends don't hurt because of= the pCount
=C2=A0 =C2=A0 hack.

=C2=A0 o if there is an outbound that is not a bgpsec speaker, they will be=
=C2=A0 =C2=A0 sent a classic as4_path which darn well should fit in the cla= ssic
=C2=A0 =C2=A0 message size.=C2=A0 if there is prepend insanity, that would = die today.

=C2=A0 o if the outbound is a bgpsec speaker yet will not use an extended =C2=A0 =C2=A0 message size, there is one interesting case, the singleton st= ub.
=C2=A0 =C2=A0 a non-transit router can sign toward its upstream(s) and not = care
=C2=A0 =C2=A0 about receiving bgsec as it has no other choice of where to s= end
=C2=A0 =C2=A0 packets.

randy

--001a1148e6f0714e120533bd8227-- From nobody Thu May 26 07:21:18 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABF6012D0E8 for ; Thu, 26 May 2016 07:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzhkFhUV1jeY for ; Thu, 26 May 2016 07:21:14 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27E4E12D6E6 for ; Thu, 26 May 2016 07:21:09 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id n129so229646875wmn.1 for ; Thu, 26 May 2016 07:21:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=mPAY1sI1mQJA2xrxJ+eN1qrdZqOjke+z6o4RMBXIjVg=; b=lPqndw8Q2iS4QP67Sr2WGpBx1hlmaBswNibqBupMndvfPfv00t0Z6hnaJBd6bggG74 3TUIyrGFuW//mXaAUetzGgQLFOzw0sqq+8n+ETfJ0auGg2NFS5OaVDju2cwGCB1wqnrI 3UbUjjdwYXJCqZUSd7pX9U/IoeQOmqDOAFnr4Pk8HCJvDNw73G6v+TllxunQqVN5yRzT 1wL555SUmYDh9BumMNUESfbXEYthz+gFMOx63es3XG9f/t8DE50JMfyLkEJAcbt/xhac E+TXQAa+UhjBJZ51QvI/IllVS0lMIPavhW3F0Guqg3GpSuoqNEx4sVNBEh3g3FO48vC9 Z7kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=mPAY1sI1mQJA2xrxJ+eN1qrdZqOjke+z6o4RMBXIjVg=; b=Bl1N1X9Yr0g+aL5c1UVDrF/aZNyPiDquyjT5o0DViLalzSbWQBP0uVCA9axbb/9VuW aMLXKZNJKW28uKqWdcJgrh7kKiEbQdCn1Z5DrKJBP7TdTH1DX9FmENGtSZhbz1JZfGzS +rfP9GaIblQQS+sOZMt317IVno/L2GVGWfujWpa55YYEFnIwhPRTVLv85yYzy0oeXOHc t4wDz9Uiw93Gh26HGTyWUAi+t7/CrvUtJ5rIpKkgFqoqIchxDEpzx5o6+2VKz/vzJjmH 2xXk431G/7CRkl8BjEoesQxLSI3BU8cY2xZt4GNwsg4M7EhPP3gOXO+wk3P1lpOjD1yP hZEQ== X-Gm-Message-State: ALyK8tLYX8lnmenBA54iqvYjrmK4OZJ+feS6UJ6hsNmx9b0GrwwI7rC0QSzbxWV7RAGVKQ== X-Received: by 10.194.141.16 with SMTP id rk16mr9491447wjb.63.1464272467617; Thu, 26 May 2016 07:21:07 -0700 (PDT) Received: from [192.168.191.120] ([80.69.10.100]) by smtp.gmail.com with ESMTPSA id w10sm14621800wjk.18.2016.05.26.07.21.05 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 May 2016 07:21:06 -0700 (PDT) To: idr@ietf.org References: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> From: Ignas Bagdonas Message-ID: <57470650.9020603@gmail.com> Date: Thu, 26 May 2016 15:21:04 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> Content-Type: multipart/alternative; boundary="------------030509080202090404080005" Archived-At: Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 14:21:17 -0000 This is a multi-part message in MIME format. --------------030509080202090404080005 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I have read the draft and support the publication. Some assorted comments: - s/RFC4221/RFC4271, and remove reference of RFC4221. - Section 4, third paragraph talks about the propagation path. How would such a path be known in advance of the propagation? This seems contrary to a normal multipoint flooding mode of BGP operation. - Error handling in the environment with old style and extended messages capable peers. There could be several scenarios advertising received extended messages to an old style peer: -- Single NLRI itself is longer than 4096 (opaque key-value AFI as an example). It is not possible to send it to an old style peer at all, should be dropped and logged. -- Single path attribute is longer than 4096. Removing such attribute would leave no place where to put partial indication. Would see dropping and logging to stay consistent with the NLRI case being a practical approach. -- The sum of path attributes is above 4096, while each path attribute is shorter than 4096. This seems to be the least deterministic case, likely it will be optional attributes that exceed the length, with local node having no knowledge based on what criteria to remove which attribute from propagation. Also this is not specific to extended messages. Behaviour today seems to be left to implementation detail. Should be logged and possibly dropped, leaving to the implementation detail. Ignas On 24/05/2016 21:42, Susan Hares wrote: > > This begins a 2 week WG LC on draft-ietf-idr-bgp-extended-messages > (5/24 to 6/7). The draft can be found at: > > https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/ > > In your comments please provide the following information: > > 1)Support/”no-support” of this draft being ready for publication, > > 2)You know of an implementation for this draft, please report the > implementation to the IDR Wiki > > https://trac.tools.ietf.org/wg/idr/trac/wiki/draft-ietf-idr-bgp-extended-implementations > > > 3)Do you have any concerns about extending the BGP messages. > > Sue Hares and John Scudder > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --------------030509080202090404080005 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit I have read the draft and support the publication.

Some assorted comments:

- s/RFC4221/RFC4271, and remove reference of RFC4221.

- Section 4, third paragraph talks about the propagation path. How would such a path be known in advance of the propagation? This seems contrary to a normal multipoint flooding mode of BGP operation.

- Error handling in the environment with old style and extended messages capable peers. There could be several scenarios advertising received extended messages to an old style peer: 
-- Single NLRI itself is longer than 4096 (opaque key-value AFI as an example). It is not possible to send it to an old style peer at all, should be dropped and logged.
-- Single path attribute is longer than 4096. Removing such attribute would leave no place where to put partial indication. Would see dropping and logging to stay consistent with the NLRI case being a practical approach.
-- The sum of path attributes is above 4096, while each path attribute is shorter than 4096. This seems to be the least deterministic case, likely it will be optional attributes that exceed the length, with local node having no knowledge based on what criteria to remove which attribute from propagation. Also this is not specific to extended messages. Behaviour today seems to be left to implementation detail. Should be logged and possibly dropped, leaving to the implementation detail. 


Ignas



On 24/05/2016 21:42, Susan Hares wrote:

This begins a 2 week WG LC on draft-ietf-idr-bgp-extended-messages (5/24 to 6/7). The draft can be found at:

 

https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/

 

In your comments please provide the following information:

1)      Support/”no-support” of this draft being ready for publication,

2)      You know of an implementation for this draft, please report the implementation to the IDR Wiki

 

https://trac.tools.ietf.org/wg/idr/trac/wiki/draft-ietf-idr-bgp-extended-implementations

 

3)      Do you have any concerns about extending the BGP messages.

 

Sue Hares and John Scudder 



_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

--------------030509080202090404080005-- From nobody Thu May 26 13:13:58 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 043D412D931 for ; Thu, 26 May 2016 13:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjMNbSA3hRcH for ; Thu, 26 May 2016 13:13:56 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id E706712D95D for ; Thu, 26 May 2016 13:13:55 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 266921E335; Thu, 26 May 2016 16:19:21 -0400 (EDT) Date: Thu, 26 May 2016 16:19:21 -0400 From: Jeffrey Haas To: Robert Raszuk Message-ID: <20160526201921.GF10531@pfrc.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: Keyur Patel , "idr@ietf.org" , "Sriram, Kotikalapudi \(Fed\)" Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 20:13:57 -0000 On Wed, May 25, 2016 at 10:28:10PM +0200, Robert Raszuk wrote: > Well there are other uses for larger BGP message size. > > Some claim that very long AS_PATH prepend happens today. For my part, I tend to see this as a DoS on the routing system. I think a few implementations even simply consider the path "bad" once it gets too big. > Yet some other folks would like to use flow spec with a lot of policy to be > pushed around (for example some ACLs can be very very long today). This case would be handy, especially if we get to some of these more "flowspec as SDN" use cases. One place we know we have desired use is large lists of route-target extended communities. While I think cases that are in danger of overflowing RT lists imply some need to engineer the network differently, it does seem to be a common issue. :-) -- Jeff From nobody Tue May 31 00:54:44 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C67F812D11B; Tue, 31 May 2016 00:54:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160531075440.15261.18355.idtracker@ietfa.amsl.com> Date: Tue, 31 May 2016 00:54:40 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-ipv6-rt-constrain-09.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 07:54:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : IPv6 Extensions for Route Target Distribution Authors : Keyur Patel Robert Raszuk Martin Djernaes Jie Dong Mach(Guoyi) Chen Filename : draft-ietf-idr-bgp-ipv6-rt-constrain-09.txt Pages : 6 Date : 2016-05-31 Abstract: The current route target distribution specification as described in [RFC 4684] defines Route Target NLRIs of maximum length of 12 bytes. The IPv6 specific Route Target extended community is defined in [RFC 5701] as length of 20 bytes. Since the current specification only supports prefixes of maximum length of 12 bytes, the lack of an IPv6 specific Route Target reachability information may be a problem when an operator wants to use this application in a pure IPv6 environment. This document defines an extension that allows BGP to exchange longer length IPv6 Route Target prefixes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ipv6-rt-constrain/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-ipv6-rt-constrain-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-ipv6-rt-constrain-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 31 00:57:39 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D72012D14B; Tue, 31 May 2016 00:57:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160531075735.15200.47132.idtracker@ietfa.amsl.com> Date: Tue, 31 May 2016 00:57:35 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-rtc-hierarchical-rr-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 07:57:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : Extensions to RT-Constrain in Hierarchical Route Reflection Scenarios Authors : Jie Dong Mach(Guoyi) Chen Robert Raszuk Filename : draft-ietf-idr-rtc-hierarchical-rr-02.txt Pages : 6 Date : 2016-05-31 Abstract: The Route Target (RT) Constrain mechanism specified in RFC 4684 is used to build a route distribution graph in order to restrict the propagation of Virtual Private Network (VPN) routes. In network scenarios where hierarchical route reflection (RR) is used, the existing RT-Constrain mechanism cannot guarantee a correct route distribution graph. This document describes the problem scenario and proposes a solution to address the RT-Constrain issue in hierarchical RR scenarios. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-rtc-hierarchical-rr/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-rtc-hierarchical-rr-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-rtc-hierarchical-rr-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 31 01:36:57 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5706E12B04F for ; Tue, 31 May 2016 01:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUAma90-83lV for ; Tue, 31 May 2016 01:36:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00A1712B04E for ; Tue, 31 May 2016 01:36:53 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CPW99904; Tue, 31 May 2016 08:36:51 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 31 May 2016 09:36:51 +0100 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.169]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Tue, 31 May 2016 16:36:43 +0800 From: "Dongjie (Jimmy)" To: "idr@ietf.org" Thread-Topic: [Idr] I-D Action: draft-ietf-idr-bgp-ipv6-rt-constrain-09.txt Thread-Index: AQHRuxHTmX3xwR1efk+dJc4jf0Wza5/SuH7g Date: Tue, 31 May 2016 08:36:43 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C92774E83D4C@NKGEML515-MBS.china.huawei.com> References: <20160531075440.15261.18355.idtracker@ietfa.amsl.com> In-Reply-To: <20160531075440.15261.18355.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.151.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.574D4D24.00D1, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.169, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 68b6f450c5386dcb28ad4614187e35a3 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-ipv6-rt-constrain-09.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 08:36:56 -0000 Hi all,=20 This update is just to keep this draft alive.=20 Best regards, Jie > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org > Sent: Tuesday, May 31, 2016 3:55 PM > To: i-d-announce@ietf.org > Cc: idr@ietf.org > Subject: [Idr] I-D Action: draft-ietf-idr-bgp-ipv6-rt-constrain-09.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Inter-Domain Routing of the IETF. >=20 > Title : IPv6 Extensions for Route Target Distribution > Authors : Keyur Patel > Robert Raszuk > Martin Djernaes > Jie Dong > Mach(Guoyi) Chen > Filename : draft-ietf-idr-bgp-ipv6-rt-constrain-09.txt > Pages : 6 > Date : 2016-05-31 >=20 > Abstract: > The current route target distribution specification as described in > [RFC 4684] defines Route Target NLRIs of maximum length of 12 bytes. > The IPv6 specific Route Target extended community is defined in [RFC > 5701] as length of 20 bytes. Since the current specification only > supports prefixes of maximum length of 12 bytes, the lack of an IPv6 > specific Route Target reachability information may be a problem when > an operator wants to use this application in a pure IPv6 environment. > This document defines an extension that allows BGP to exchange longer > length IPv6 Route Target prefixes. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ipv6-rt-constrain/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-idr-bgp-ipv6-rt-constrain-09 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-bgp-ipv6-rt-constrain-= 09 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Tue May 31 01:42:00 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3385812B02C for ; Tue, 31 May 2016 01:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXntw7qDcawU for ; Tue, 31 May 2016 01:41:57 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E42C12B04E for ; Tue, 31 May 2016 01:41:56 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CPX00908; Tue, 31 May 2016 08:41:52 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 31 May 2016 09:41:51 +0100 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.169]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Tue, 31 May 2016 16:41:44 +0800 From: "Dongjie (Jimmy)" To: "idr@ietf.org" Thread-Topic: [Idr] I-D Action: draft-ietf-idr-rtc-hierarchical-rr-02.txt Thread-Index: AQHRuxJIiqDaI2QYG0ik/WC8GBq63J/SuREA Date: Tue, 31 May 2016 08:41:43 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C92774E83D60@NKGEML515-MBS.china.huawei.com> References: <20160531075735.15200.47132.idtracker@ietfa.amsl.com> In-Reply-To: <20160531075735.15200.47132.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.151.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0206.574D4E51.024D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.169, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f5a10e942450913939980a9ce7266e32 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rtc-hierarchical-rr-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 08:41:59 -0000 Hi all,=20 There are some editorial changes in this new revision. And the authors woul= d like to know the WG's opinion on the two potential solutions, so that som= e decision could be made in a future version. Comments and feedbacks are welcome. Best regards, Jie > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org > Sent: Tuesday, May 31, 2016 3:58 PM > To: i-d-announce@ietf.org > Cc: idr@ietf.org > Subject: [Idr] I-D Action: draft-ietf-idr-rtc-hierarchical-rr-02.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Inter-Domain Routing of the IETF. >=20 > Title : Extensions to RT-Constrain in Hierarchical Rout= e > Reflection Scenarios > Authors : Jie Dong > Mach(Guoyi) Chen > Robert Raszuk > Filename : draft-ietf-idr-rtc-hierarchical-rr-02.txt > Pages : 6 > Date : 2016-05-31 >=20 > Abstract: > The Route Target (RT) Constrain mechanism specified in RFC 4684 is > used to build a route distribution graph in order to restrict the > propagation of Virtual Private Network (VPN) routes. In network > scenarios where hierarchical route reflection (RR) is used, the > existing RT-Constrain mechanism cannot guarantee a correct route > distribution graph. This document describes the problem scenario and > proposes a solution to address the RT-Constrain issue in hierarchical > RR scenarios. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-rtc-hierarchical-rr/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-idr-rtc-hierarchical-rr-02 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-rtc-hierarchical-rr-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Tue May 31 05:15:00 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C54D12D5C2; Tue, 31 May 2016 05:14:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160531121459.15306.61547.idtracker@ietfa.amsl.com> Date: Tue, 31 May 2016 05:14:59 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-wide-bgp-communities-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 12:14:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : Wide BGP Communities Attribute Authors : Robert Raszuk Jeffrey Haas Andrew Lange Shane Amante Bruno Decraene Paul Jakma Richard A Steenbergen Filename : draft-ietf-idr-wide-bgp-communities-02.txt Pages : 23 Date : 2016-05-31 Abstract: Route tagging plays an important role in external BGP [RFC4271] relations, in communicating various routing policies between peers. It is also a very common best practice among operators to propagate various additional information about routes intra-domain. The most common tool used today to attach various information about routes is through the use of BGP communities [RFC1997]. Such information is important to allow BGP speakers to perform some mutually agreed actions without the need to maintain a separate offline database for each tuple of prefix and associated set of action entries. This document defines a new encoding which will enhance and simplify what can be accomplished today with the use of BGP communities. The most important addition this specification makes over currently defined BGP communities is the ability to specify, carry as well as use for execution an operator's defined set of parameters. It also provides an extensible platform for any new community encoding needs in the future. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-wide-bgp-communities/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-wide-bgp-communities-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-wide-bgp-communities-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 31 05:16:22 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3804312D529; Tue, 31 May 2016 05:16:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160531121619.15322.90034.idtracker@ietfa.amsl.com> Date: Tue, 31 May 2016 05:16:19 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-registered-wide-bgp-communities-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 12:16:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : Registered Wide BGP Community Values Authors : Robert Raszuk Jeffrey Haas Filename : draft-ietf-idr-registered-wide-bgp-communities-02.txt Pages : 18 Date : 2016-05-31 Abstract: Communicating various routing policies via route tagging plays an important role in external BGP peering relations. The most common tool used today to attach various information about routes is realized with the use of BGP communities. Such information is important for the peering AS to perform some mutually agreed actions without the need to maintain a separate offline database for each pair of prefix and an associated with it requested set of action entries. This document proposes to establish a new IANA maintained registry of most commonly used Wide BGP Communities by network operators. Such public registry will allow for easy refernece and clear interpretation of the actions associated with received community values. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-registered-wide-bgp-communities/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-registered-wide-bgp-communities-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-registered-wide-bgp-communities-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 31 08:40:35 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC05512D1E8; Tue, 31 May 2016 08:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYN6h_AOLsdc; Tue, 31 May 2016 08:40:21 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C0BC12D5D7; Tue, 31 May 2016 08:40:20 -0700 (PDT) X-Envelope-To: Idr@ietf.org Received: from crumpet.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id u4VFeHjD087010 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 May 2016 16:40:17 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be crumpet.local Message-ID: <574DB060.1000801@foobar.org> Date: Tue, 31 May 2016 16:40:16 +0100 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Marco Marzetti References: <20160524224341.14017.96672.idtracker@ietfa.amsl.com> <6b69a7e81790d6bae23d39ea44ccb01f@lamehost.it> In-Reply-To: <6b69a7e81790d6bae23d39ea44ccb01f@lamehost.it> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Idr@ietf.org, ietf@ietf.org Subject: Re: [Idr] Last Call: (Internet Exchange BGP Route Server) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 15:40:29 -0000 Marco Marzetti wrote: > Beside i agree on the most part of this draft i would like to underline > how bullet 2.2.2 breaks the the nature of BGP itself. > > The exact part i am referring to is: > """ > As a route server does not participate in the process of forwarding > data between client routers, and because modification of the AS_PATH > attribute could affect route server client BGP Decision Process, the > route server SHOULD NOT prepend its own AS number to the AS_PATH > segment nor modify the AS_PATH segment in any other way. > """ > > I firmly think that it really has to state "MUST NOT" instead of "SHOULD > NOT". > > From a route-server client point of view that breaks the natural BGP > best selection process and forces you to purely rely on LOCAL_PREFERENCE > which in turns breaks your traffic engineering because it forces you to > prefer/not-prefer the prefixes learned over the route server in place of > those learned, for instance, over a private session or another IXP. It doesn't "break" the decision process mechanism. Localpref might be ugly, but using it doesn't violate the bgp protocol. This statement needs to be "MUST NOT". Technically you can run a route server even if you insert the intermediate ASN into the path. The only absolute "MUST" is that you mustn't change the next-hop; otherwise you end up with a router instead of a route server. RFC2119 is a pain because there is no way of differentiating between "SHOULD NOT", meaning "on balance it would be a better idea not to do X" and "SHOULD NOT", meaning "if you even _think_ about doing X, you need your head examined and the only reason we specified SHOULD NOT instead of MUST NOT in this situation because of some technicality that prevented us from doing so". The text in 2.2.2 veers slightly in the direction of the latter interpretation. Nick From nobody Tue May 31 10:58:02 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5626F12D890; Tue, 31 May 2016 10:58:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160531175801.20255.63736.idtracker@ietfa.amsl.com> Date: Tue, 31 May 2016 10:58:01 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-tunnel-encaps-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 17:58:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : The BGP Tunnel Encapsulation Attribute Authors : Eric C. Rosen Keyur Patel Gunter Van de Velde Filename : draft-ietf-idr-tunnel-encaps-02.txt Pages : 40 Date : 2016-05-31 Abstract: RFC 5512 defines a BGP Path Attribute known as the "Tunnel Encapsulation Attribute". This attribute allows one to specify a set of tunnels. For each such tunnel, the attribute can provide the information needed to create the tunnel and the corresponding encapsulation header. The attribute can also provide information that aids in choosing whether a particular packet is to be sent through a particular tunnel. RFC 5512 states that the attribute is only carried in BGP UPDATEs that have the "Encapsulation Subsequent Address Family (Encapsulation SAFI)". This document deprecates the Encapsulation SAFI (which has never been used), and specifies semantics for the attribute when it is carried in UPDATEs of certain other SAFIs. This document adds support for additional tunnel types, and allows a remote tunnel endpoint address to be specified for each tunnel. This document also provides support for specifying fields of any inner or outer encapsulations that may be used by a particular tunnel. This document obsoletes RFC 5512. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-tunnel-encaps/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-tunnel-encaps-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 31 11:39:00 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 677BF12D562; Tue, 31 May 2016 11:38:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160531183856.20288.57977.idtracker@ietfa.amsl.com> Date: Tue, 31 May 2016 11:38:56 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-flowspec-mpls-match-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 18:38:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : BGP Flow Specification Filter for MPLS Label Authors : Lucy Yong Susan Hares Qiandeng Liang Jianjie You Filename : draft-ietf-idr-flowspec-mpls-match-00.txt Pages : 8 Date : 2016-05-31 Abstract: This draft proposes BGP flow specification rules that are used to filter MPLS labeled packets. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-mpls-match/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-flowspec-mpls-match-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/