From internet-drafts@ietf.org Mon May 6 14:59:03 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E91D921F9354; Mon, 6 May 2013 14:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.301 X-Spam-Level: X-Spam-Status: No, score=-101.301 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKxYRuL2ByCL; Mon, 6 May 2013 14:59:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 662F321F8C7D; Mon, 6 May 2013 14:59:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p6 Message-ID: <20130506215903.23334.10357.idtracker@ietfa.amsl.com> Date: Mon, 06 May 2013 14:59:03 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-general-constraint-encode-11.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 21:59:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : General Network Element Constraint Encoding for GMPLS Co= ntrolled Networks Author(s) : Greg M. Bernstein Young Lee Dan Li Wataru Imajuku Filename : draft-ietf-ccamp-general-constraint-encode-11.txt Pages : 31 Date : 2013-05-06 Abstract: Generalized Multiprotocol Label Switching can be used to control a wide variety of technologies. In some of these technologies network elements and links may impose additional routing constraints such as asymmetric switch connectivity, non-local label assignment, and label range limitations on links. This document provides efficient, protocol-agnostic encodings for general information elements representing connectivity and label constraints as well as label availability. It is intended that protocol-specific documents will reference this memo to describe how information is carried for specific uses. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-general-constraint-encode There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-general-constraint-encode-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-general-constraint-enco= de-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From leeyoung@huawei.com Mon May 6 15:04:07 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0686621F9352 for ; Mon, 6 May 2013 15:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.464 X-Spam-Level: X-Spam-Status: No, score=-6.464 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ct8yQVXr4niA for ; Mon, 6 May 2013 15:04:02 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 93B2521F9348 for ; Mon, 6 May 2013 15:04:01 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARC63689; Mon, 06 May 2013 22:04:00 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 6 May 2013 23:03:56 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 7 May 2013 06:03:58 +0800 Received: from dfweml511-mbs.china.huawei.com ([169.254.15.13]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.007; Mon, 6 May 2013 15:03:54 -0700 From: Leeyoung To: CCAMP Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-general-constraint-encode-11.txt Thread-Index: AQHOSqUIPE4MmCTFl0aTSrA1lQOEiJj4tRoQ Date: Mon, 6 May 2013 22:03:52 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729139D44@dfweml511-mbs.china.huawei.com> References: <20130506215903.23334.10357.idtracker@ietfa.amsl.com> In-Reply-To: <20130506215903.23334.10357.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.108] Content-Type: multipart/mixed; boundary="_002_7AEB3D6833318045B4AE71C2C87E8E1729139D44dfweml511mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-general-constraint-encode-11.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 22:04:07 -0000 --_002_7AEB3D6833318045B4AE71C2C87E8E1729139D44dfweml511mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thus change is to revive the expired draft and to update based on Annapoorn= i's comment which is attached FYI.=20 The nature of changes is basically editorial clarifications.=20 Thanks. Young -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org Sent: Monday, May 06, 2013 4:59 PM To: i-d-announce@ietf.org Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-general-constraint-encode-11.= txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : General Network Element Constraint Encoding for GMPLS Co= ntrolled Networks Author(s) : Greg M. Bernstein Young Lee Dan Li Wataru Imajuku Filename : draft-ietf-ccamp-general-constraint-encode-11.txt Pages : 31 Date : 2013-05-06 Abstract: Generalized Multiprotocol Label Switching can be used to control a wide variety of technologies. In some of these technologies network elements and links may impose additional routing constraints such as asymmetric switch connectivity, non-local label assignment, and label range limitations on links. This document provides efficient, protocol-agnostic encodings for general information elements representing connectivity and label constraints as well as label availability. It is intended that protocol-specific documents will reference this memo to describe how information is carried for specific uses. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-general-constraint-encode There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-general-constraint-encode-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-general-constraint-enco= de-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --_002_7AEB3D6833318045B4AE71C2C87E8E1729139D44dfweml511mbschi_ Content-Type: text/html; name="Mail regarding draft-ietf-ccamp-general-constraint-encode.htm" Content-Description: Mail regarding draft-ietf-ccamp-general-constraint-encode.htm Content-Disposition: attachment; filename="Mail regarding draft-ietf-ccamp-general-constraint-encode.htm"; size=54601; creation-date="Mon, 06 May 2013 22:00:45 GMT"; modification-date="Mon, 06 May 2013 22:00:46 GMT" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiDQp4bWxuczpvPSJ1 cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiDQp4bWxuczp3PSJ1cm46c2No ZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIg0KeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMu bWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIg0KeG1sbnM9Imh0dHA6Ly93d3cudzMu b3JnL1RSL1JFQy1odG1sNDAiPg0KDQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9Q29udGVudC1U eXBlIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD13aW5kb3dzLTEyNTIiPg0KPG1ldGEgbmFt ZT1Qcm9nSWQgY29udGVudD1Xb3JkLkRvY3VtZW50Pg0KPG1ldGEgbmFtZT1HZW5lcmF0b3IgY29u dGVudD0iTWljcm9zb2Z0IFdvcmQgMTIiPg0KPG1ldGEgbmFtZT1PcmlnaW5hdG9yIGNvbnRlbnQ9 Ik1pY3Jvc29mdCBXb3JkIDEyIj4NCjxsaW5rIHJlbD1GaWxlLUxpc3QNCmhyZWY9Ik1haWwlMjBy ZWdhcmRpbmclMjBkcmFmdC1pZXRmLWNjYW1wLWdlbmVyYWwtY29uc3RyYWludC1lbmNvZGVfZmls ZXMvZmlsZWxpc3QueG1sIj4NCjxsaW5rIHJlbD1FZGl0LVRpbWUtRGF0YQ0KaHJlZj0iTWFpbCUy MHJlZ2FyZGluZyUyMGRyYWZ0LWlldGYtY2NhbXAtZ2VuZXJhbC1jb25zdHJhaW50LWVuY29kZV9m aWxlcy9lZGl0ZGF0YS5tc28iPg0KPCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86RG9jdW1l bnRQcm9wZXJ0aWVzPg0KICA8bzpBdXRob3I+bDczNjgyPC9vOkF1dGhvcj4NCiAgPG86VGVtcGxh dGU+Tm9ybWFsRW1haWwuZG90bTwvbzpUZW1wbGF0ZT4NCiAgPG86UmV2aXNpb24+MTwvbzpSZXZp c2lvbj4NCiAgPG86VG90YWxUaW1lPjA8L286VG90YWxUaW1lPg0KICA8bzpDcmVhdGVkPjIwMTMt MDUtMDZUMjI6MDA6MDBaPC9vOkNyZWF0ZWQ+DQogIDxvOlBhZ2VzPjE8L286UGFnZXM+DQogIDxv OldvcmRzPjk4NDwvbzpXb3Jkcz4NCiAgPG86Q2hhcmFjdGVycz41NjE0PC9vOkNoYXJhY3RlcnM+ DQogIDxvOkxpbmVzPjQ2PC9vOkxpbmVzPg0KICA8bzpQYXJhZ3JhcGhzPjEzPC9vOlBhcmFncmFw aHM+DQogIDxvOkNoYXJhY3RlcnNXaXRoU3BhY2VzPjY1ODU8L286Q2hhcmFjdGVyc1dpdGhTcGFj ZXM+DQogIDxvOlZlcnNpb24+MTIuMDA8L286VmVyc2lvbj4NCiA8L286RG9jdW1lbnRQcm9wZXJ0 aWVzPg0KPC94bWw+PCFbZW5kaWZdLS0+DQo8bGluayByZWw9dGhlbWVEYXRhDQpocmVmPSJNYWls JTIwcmVnYXJkaW5nJTIwZHJhZnQtaWV0Zi1jY2FtcC1nZW5lcmFsLWNvbnN0cmFpbnQtZW5jb2Rl X2ZpbGVzL3RoZW1lZGF0YS50aG14Ij4NCjxsaW5rIHJlbD1jb2xvclNjaGVtZU1hcHBpbmcNCmhy ZWY9Ik1haWwlMjByZWdhcmRpbmclMjBkcmFmdC1pZXRmLWNjYW1wLWdlbmVyYWwtY29uc3RyYWlu dC1lbmNvZGVfZmlsZXMvY29sb3JzY2hlbWVtYXBwaW5nLnhtbCI+DQo8IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCiA8dzpXb3JkRG9jdW1lbnQ+DQogIDx3Olpvb20+MDwvdzpab29tPg0KICA8dzpU cmFja01vdmVzLz4NCiAgPHc6VHJhY2tGb3JtYXR0aW5nLz4NCiAgPHc6VmFsaWRhdGVBZ2FpbnN0 U2NoZW1hcy8+DQogIDx3OlNhdmVJZlhNTEludmFsaWQ+ZmFsc2U8L3c6U2F2ZUlmWE1MSW52YWxp ZD4NCiAgPHc6SWdub3JlTWl4ZWRDb250ZW50PmZhbHNlPC93Oklnbm9yZU1peGVkQ29udGVudD4N CiAgPHc6QWx3YXlzU2hvd1BsYWNlaG9sZGVyVGV4dD5mYWxzZTwvdzpBbHdheXNTaG93UGxhY2Vo b2xkZXJUZXh0Pg0KICA8dzpEb05vdFByb21vdGVRRi8+DQogIDx3OkxpZFRoZW1lT3RoZXI+RU4t VVM8L3c6TGlkVGhlbWVPdGhlcj4NCiAgPHc6TGlkVGhlbWVBc2lhbj5YLU5PTkU8L3c6TGlkVGhl bWVBc2lhbj4NCiAgPHc6TGlkVGhlbWVDb21wbGV4U2NyaXB0PlgtTk9ORTwvdzpMaWRUaGVtZUNv bXBsZXhTY3JpcHQ+DQogIDx3OkNvbXBhdGliaWxpdHk+DQogICA8dzpEb05vdEV4cGFuZFNoaWZ0 UmV0dXJuLz4NCiAgIDx3OkJyZWFrV3JhcHBlZFRhYmxlcy8+DQogICA8dzpTcGxpdFBnQnJlYWtB bmRQYXJhTWFyay8+DQogICA8dzpEb250VmVydEFsaWduQ2VsbFdpdGhTcC8+DQogICA8dzpEb250 QnJlYWtDb25zdHJhaW5lZEZvcmNlZFRhYmxlcy8+DQogICA8dzpEb250VmVydEFsaWduSW5UeGJ4 Lz4NCiAgIDx3OldvcmQxMUtlcm5pbmdQYWlycy8+DQogICA8dzpDYWNoZWRDb2xCYWxhbmNlLz4N CiAgPC93OkNvbXBhdGliaWxpdHk+DQogIDx3OkJyb3dzZXJMZXZlbD5NaWNyb3NvZnRJbnRlcm5l dEV4cGxvcmVyNDwvdzpCcm93c2VyTGV2ZWw+DQogIDxtOm1hdGhQcj4NCiAgIDxtOm1hdGhGb250 IG06dmFsPSJDYW1icmlhIE1hdGgiLz4NCiAgIDxtOmJya0JpbiBtOnZhbD0iYmVmb3JlIi8+DQog ICA8bTpicmtCaW5TdWIgbTp2YWw9IiYjNDU7LSIvPg0KICAgPG06c21hbGxGcmFjIG06dmFsPSJv ZmYiLz4NCiAgIDxtOmRpc3BEZWYvPg0KICAgPG06bE1hcmdpbiBtOnZhbD0iMCIvPg0KICAgPG06 ck1hcmdpbiBtOnZhbD0iMCIvPg0KICAgPG06ZGVmSmMgbTp2YWw9ImNlbnRlckdyb3VwIi8+DQog ICA8bTp3cmFwSW5kZW50IG06dmFsPSIxNDQwIi8+DQogICA8bTppbnRMaW0gbTp2YWw9InN1YlN1 cCIvPg0KICAgPG06bmFyeUxpbSBtOnZhbD0idW5kT3ZyIi8+DQogIDwvbTptYXRoUHI+PC93Oldv cmREb2N1bWVudD4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K IDx3OkxhdGVudFN0eWxlcyBEZWZMb2NrZWRTdGF0ZT0iZmFsc2UiIERlZlVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIg0KICBEZWZTZW1pSGlkZGVuPSJ0cnVlIiBEZWZRRm9ybWF0PSJmYWxzZSIgRGVmUHJp b3JpdHk9Ijk5Ig0KICBMYXRlbnRTdHlsZUNvdW50PSIyNjciPg0KICA8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjAiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJOb3JtYWwiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBTZW1pSGlkZGVuPSJmYWxzZSIN CiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyAx Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1h dD0idHJ1ZSIgTmFtZT0iaGVhZGluZyAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyAzIi8+DQogIDx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIg TmFtZT0iaGVhZGluZyA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA1Ii8+DQogIDx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVh ZGluZyA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIg UUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA3Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA4Ii8+ DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0i dHJ1ZSIgTmFtZT0iaGVhZGluZyA5Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyAzIi8+DQogIDx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyA0Ii8+DQogIDx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyA1Ii8+DQog IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyA2 Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9 InRvYyA3Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzki IE5hbWU9InRvYyA4Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iMzkiIE5hbWU9InRvYyA5Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iMzUiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImNhcHRpb24iLz4NCiAgPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxMCIgU2VtaUhpZGRlbj0iZmFsc2UiDQog ICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlRpdGxlIi8+DQog IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMSIgTmFtZT0iRGVmYXVs dCBQYXJhZ3JhcGggRm9udCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjExIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg UUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3VidGl0bGUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSIyMiIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlN0cm9uZyIvPg0KICA8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjIwIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAg IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iRW1waGFzaXMiLz4N CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1OSIgU2VtaUhpZGRl bj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IlRhYmxlIEdyaWQiLz4N CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iUGxhY2Vob2xkZXIgVGV4dCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjEiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJObyBTcGFjaW5nIi8+DQogIDx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBTaGFkaW5nIi8+DQogIDx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0Ii8+DQogIDx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIi8+DQogIDx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIi8+DQogIDx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIFNlbWlIaWRkZW49ImZhbHNl Ig0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIi8+DQog IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIFNlbWlIaWRkZW49 ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAxIi8+ DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNlbWlIaWRk ZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAy Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIFNlbWlI aWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3Jp ZCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIFNl bWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0g R3JpZCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjki IFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRp dW0gR3JpZCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NzAiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJE YXJrIExpc3QiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3 MSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNv bG9yZnVsIFNoYWRpbmciLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI3MiIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9IkNvbG9yZnVsIExpc3QiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IE5hbWU9IkNvbG9yZnVsIEdyaWQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDEiLz4NCiAgPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2UiDQog ICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDEiLz4NCiAg PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgU2VtaUhpZGRlbj0i ZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEg QWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 NCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1l ZGl1bSBTaGFkaW5nIDIgQWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iUmV2aXNpb24iLz4N CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzNCIgU2VtaUhpZGRl bj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9 Ikxpc3QgUGFyYWdyYXBoIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iMjkiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBR Rm9ybWF0PSJ0cnVlIiBOYW1lPSJRdW90ZSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjMwIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iSW50ZW5zZSBRdW90ZSIvPg0KICA8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBTZW1pSGlkZGVuPSJmYWxzZSIN CiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgMSIv Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBTZW1pSGlk ZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQg MSBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjY4IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i TWVkaXVtIEdyaWQgMiBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCAxIi8+DQogIDx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIFNlbWlIaWRkZW49ImZhbHNlIg0K ICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCAx Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIFNlbWlI aWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBM aXN0IEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNzMiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1l PSJDb2xvcmZ1bCBHcmlkIEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjAiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCAyIi8+DQogIDx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIFNlbWlIaWRkZW49ImZhbHNl Ig0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCAyIi8+ DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIFNlbWlIaWRk ZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGlu ZyAxIEFjY2VudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjQiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1l PSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCAyIi8+DQogIDx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCAyIi8+DQog IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIFNlbWlIaWRkZW49 ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFj Y2VudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgi IFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRp dW0gR3JpZCAyIEFjY2VudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjkiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDIiLz4N CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgU2VtaUhpZGRl bj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIExpc3Qg QWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3 MyIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNv bG9yZnVsIEdyaWQgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2UiDQog ICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDMiLz4NCiAg PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgU2VtaUhpZGRlbj0i ZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEg QWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 NCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1l ZGl1bSBTaGFkaW5nIDIgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDMiLz4NCiAgPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgU2VtaUhpZGRlbj0iZmFs c2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50 IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgU2Vt aUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBH cmlkIDIgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgMyIvPg0KICA8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBTZW1pSGlkZGVuPSJm YWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2Nl bnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBT ZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3Jm dWwgR3JpZCBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgNCIvPg0KICA8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBTZW1pSGlkZGVuPSJmYWxz ZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2Nl bnQgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBT ZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVt IFNoYWRpbmcgMiBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjY1IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgNCIvPg0KICA8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBTZW1pSGlkZGVuPSJmYWxzZSIN CiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgNCIv Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBTZW1pSGlk ZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQg MiBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i TWVkaXVtIEdyaWQgMyBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCA0Ii8+DQogIDx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIFNlbWlIaWRkZW49ImZhbHNl Ig0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCA0 Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIFNlbWlI aWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBH cmlkIEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjAiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1l PSJMaWdodCBTaGFkaW5nIEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjEiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIFNlbWlIaWRkZW49ImZhbHNlIg0K ICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCA1 Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIFNlbWlI aWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hh ZGluZyAyIEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIFNlbWlIaWRkZW49ImZhbHNlIg0KICAg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCA1Ii8+DQog IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIFNlbWlIaWRkZW49 ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFj Y2VudCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjki IFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRp dW0gR3JpZCAzIEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNzAiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI3MSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgU2VtaUhpZGRlbj0iZmFsc2UiDQog ICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDUiLz4N CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgU2VtaUhpZGRl bj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIEdyaWQg QWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 MCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ikxp Z2h0IFNoYWRpbmcgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDYiLz4N CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRl bj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5n IDIgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDYiLz4NCiAgPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgU2VtaUhpZGRlbj0iZmFs c2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50 IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgU2Vt aUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBH cmlkIDMgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9IkRhcmsgTGlzdCBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgNiIvPg0KICA8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJm YWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2Nl bnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjE5IiBT ZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1 ZSIgTmFtZT0iU3VidGxlIEVtcGhhc2lzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iMjEiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJJbnRlbnNlIEVtcGhhc2lzIi8+DQogIDx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzEiIFNlbWlIaWRkZW49ImZhbHNl Ig0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJTdWJ0bGUg UmVmZXJlbmNlIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i MzIiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0 PSJ0cnVlIiBOYW1lPSJJbnRlbnNlIFJlZmVyZW5jZSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMzIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iQm9vayBUaXRsZSIvPg0KICA8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM3IiBOYW1lPSJCaWJsaW9ncmFw aHkiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgUUZv cm1hdD0idHJ1ZSIgTmFtZT0iVE9DIEhlYWRpbmciLz4NCiA8L3c6TGF0ZW50U3R5bGVzPg0KPC94 bWw+PCFbZW5kaWZdLS0+DQo8c3R5bGU+DQo8IS0tDQogLyogRm9udCBEZWZpbml0aW9ucyAqLw0K IEBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIg MiA1IDIgNCA0Ow0KCW1zby1mb250LWNoYXJzZXQ6MDsNCgltc28tZ2VuZXJpYy1mb250LWZhbWls eTptb2Rlcm47DQoJbXNvLWZvbnQtZm9ybWF0Om90aGVyOw0KCW1zby1mb250LXBpdGNoOmZpeGVk Ow0KCW1zby1mb250LXNpZ25hdHVyZTozIDAgMCAwIDEgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7DQoJ bXNvLWZvbnQtY2hhcnNldDowOw0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OnJvbWFuOw0KCW1z by1mb250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNpZ25hdHVyZTotNTM2ODcwMTQ1IDEx MDczMDU3MjcgMCAwIDQxNSAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDsNCgltc28tZm9udC1jaGFyc2V0OjA7DQoJ bXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6c3dpc3M7DQoJbXNvLWZvbnQtcGl0Y2g6dmFyaWFibGU7 DQoJbXNvLWZvbnQtc2lnbmF0dXJlOi01MzY4NzAxNDUgMTA3Mzc4NjExMSAxIDAgNDE1IDA7fQ0K IC8qIFN0eWxlIERlZmluaXRpb25zICovDQogcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttc28tc3R5bGUtdW5oaWRlOm5vOw0KCW1zby1zdHlsZS1xZm9ybWF0Onll czsNCgltc28tc3R5bGUtcGFyZW50OiIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtZm9u dC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tZmFyZWFzdC10aGVtZS1mb250Om1pbm9yLWxhdGluOw0K CW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgl0ZXh0LXVu ZGVybGluZTpzaW5nbGU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJ e21zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgl0ZXh0LXVuZGVybGluZTpzaW5n bGU7fQ0KcA0KCXttc28tc3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2Vy aWYiOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWZhcmVhc3QtdGhl bWUtZm9udDptaW5vci1sYXRpbjt9DQpwcmUNCgl7bXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgltc28tcGFnaW5h dGlvbjp3aWRvdy1vcnBoYW47DQoJdGFiLXN0b3BzOjQ1LjhwdCA5MS42cHQgMTM3LjRwdCAxODMu MnB0IDIyOS4wcHQgMjc0LjhwdCAzMjAuNnB0IDM2Ni40cHQgNDEyLjJwdCA0NTguMHB0IDUwMy44 cHQgNTQ5LjZwdCA1OTUuNHB0IDY0MS4ycHQgNjg3LjBwdCA3MzIuOHB0Ow0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tZmFyZWFzdC1mb250LWZh bWlseTpDYWxpYnJpOw0KCW1zby1mYXJlYXN0LXRoZW1lLWZvbnQ6bWlub3ItbGF0aW47fQ0KcC5N c29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFw aA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbXNvLXN0eWxlLXVuaGlkZTpubzsNCgltc28t c3R5bGUtcWZvcm1hdDp5ZXM7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsN CgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1zaXplOjExLjBw dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWZv bnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWZhcmVhc3QtdGhlbWUtZm9udDptaW5vci1sYXRpbjsN Cgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpzcGFuLkhUTUxQcmVm b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN Cgltc28tc3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLXVuaGlkZTpubzsNCgltc28tc3R5bGUtbG9ja2VkOnllczsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWFz Y2lpLWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFu LkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCgltc28tc3R5bGUtbm9z aG93OnllczsNCgltc28tc3R5bGUtdW5oaWRlOm5vOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJbXNvLWFzY2lpLWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWhhbnNp LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tZGVmYXVsdC1wcm9wczp5ZXM7 DQoJZm9udC1zaXplOjEwLjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCW1zby1i aWRpLWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjsNCgltc28taGVhZGVyLW1h cmdpbjouNWluOw0KCW1zby1mb290ZXItbWFyZ2luOi41aW47DQoJbXNvLXBhcGVyLXNvdXJjZTow O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KIC8qIExpc3QgRGVm aW5pdGlvbnMgKi8NCiBAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo4MjM3OTM3MjsNCgltc28tbGlz dC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NjQ5MTE2MjQ2IDEzMzYxOTEx OCA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2 NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRleHQ6IiUx XCkiOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjExLjBw dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2Vy Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30N CkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxl dmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZl bDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9 DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpy aWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0K dWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+DQo8L3N0eWxlPg0KPCEtLVtpZiBndGUgbXNv IDEwXT4NCjxzdHlsZT4NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHRhYmxlLk1zb05vcm1h bFRhYmxlDQoJe21zby1zdHlsZS1uYW1lOiJUYWJsZSBOb3JtYWwiOw0KCW1zby10c3R5bGUtcm93 YmFuZC1zaXplOjA7DQoJbXNvLXRzdHlsZS1jb2xiYW5kLXNpemU6MDsNCgltc28tc3R5bGUtbm9z aG93OnllczsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLXFmb3JtYXQ6eWVz Ow0KCW1zby1zdHlsZS1wYXJlbnQ6IiI7DQoJbXNvLXBhZGRpbmctYWx0OjBpbiA1LjRwdCAwaW4g NS40cHQ7DQoJbXNvLXBhcmEtbWFyZ2luOjBpbjsNCgltc28tcGFyYS1tYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3JwaGFuOw0KCWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQo8L3N0eWxlPg0KPCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQogPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KICA8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIvPg0KIDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCg0KPGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlIHN0 eWxlPSd0YWItaW50ZXJ2YWw6LjVpbic+DQoNCjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjEyMC4wcHQ7dGV4dC1pbmRlbnQ6 LTEyMC4wcHQ7dGFiLXN0b3BzOg0KMTIwLjBwdDttc28tbGF5b3V0LWdyaWQtYWxpZ246bm9uZTt0 ZXh0LWF1dG9zcGFjZTpub25lJz48Yj48c3Bhbg0Kc3R5bGU9J21zby1iaWRpLWZvbnQtZmFtaWx5 OkNhbGlicmk7Y29sb3I6YmxhY2snPkZyb206PHNwYW4gc3R5bGU9J21zby10YWItY291bnQ6DQox Jz6goKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgIDwvc3Bhbj48L3NwYW4+ PC9iPjxzcGFuDQpzdHlsZT0nbXNvLWJpZGktZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFj ayc+QW5uYXBvb3JuaSBOZWVsYW5rYW50YW4NCltBbm5hcG9vcm5pLk5lZWxhbmthbnRhbkBlY2l0 ZWxlLmNvbV08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbWFyZ2luLWxlZnQ6MTIwLjBwdDt0ZXh0LWluZGVudDotMTIwLjBwdDt0YWItc3RvcHM6DQox MjAuMHB0O21zby1sYXlvdXQtZ3JpZC1hbGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUnPjxi PjxzcGFuDQpzdHlsZT0nbXNvLWJpZGktZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayc+ U2VudDo8c3BhbiBzdHlsZT0nbXNvLXRhYi1jb3VudDoNCjEnPqCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoCA8L3NwYW4+PC9zcGFuPjwvYj48c3Bhbg0Kc3R5bGU9J21z by1iaWRpLWZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2snPk1vbmRheSwgTWF5IDA2LCAy MDEzIDY6NDUgQU08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nbWFyZ2luLWxlZnQ6MTIwLjBwdDt0ZXh0LWluZGVudDotMTIwLjBwdDt0YWItc3RvcHM6 DQoxMjAuMHB0O21zby1sYXlvdXQtZ3JpZC1hbGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUn PjxiPjxzcGFuDQpzdHlsZT0nbXNvLWJpZGktZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFj ayc+VG86PHNwYW4gc3R5bGU9J21zby10YWItY291bnQ6DQoxJz6goKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgIDwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuDQpzdHls ZT0nbXNvLWJpZGktZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayc+ZHJhZnQtaWV0Zi1j Y2FtcC1nZW5lcmFsLWNvbnN0cmFpbnQtZW5jb2RlQHRvb2xzLmlldGYub3JnPG86cD48L286cD48 L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjEyMC4w cHQ7dGV4dC1pbmRlbnQ6LTEyMC4wcHQ7dGFiLXN0b3BzOg0KMTIwLjBwdDttc28tbGF5b3V0LWdy aWQtYWxpZ246bm9uZTt0ZXh0LWF1dG9zcGFjZTpub25lJz48Yj48c3Bhbg0Kc3R5bGU9J21zby1i aWRpLWZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2snPlN1YmplY3Q6PHNwYW4NCnN0eWxl PSdtc28tdGFiLWNvdW50OjEnPqCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCA8 L3NwYW4+PC9zcGFuPjwvYj48c3Bhbg0Kc3R5bGU9J21zby1iaWRpLWZvbnQtZmFtaWx5OkNhbGli cmk7Y29sb3I6YmxhY2snPk1haWwgcmVnYXJkaW5nDQpkcmFmdC1pZXRmLWNjYW1wLWdlbmVyYWwt Y29uc3RyYWludC1lbmNvZGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05v cm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdjb2xvcjojMUY0OTdEJz5IZWxsbyBBdXRob3JzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Y29sb3I6IzFGNDk3RCc+SSBoYXZlIGZldyBxdWVzdGlvbnMgcmVnYXJkaW5nDQp0aGUgW2dlbi1l bmNvZGUgZHJhZnRdIC0gk2RyYWZ0LWlldGYtY2NhbXAtZ2VuZXJhbC1jb25zdHJhaW50LWVuY29k ZS0xMC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPlRoZSBtZW50aW9u ZWQgZHJhZnQgaGFzIGV4cGlyZWQNCm9uIDI4IG1hcmNoIDIwMTMuIEJ1dCBhbGwgdGhlIFdTT04g c3BlY2lmaWMgZG9jdW1lbnRzIHJlZmVyIHRvIHRoaXMgZG9jdW1lbnQNCmZvciByZWZlcmVuY2Uu PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5JcyB0aGUNCpNkcmFmdC1pZXRm LWNjYW1wLWdlbmVyYWwtY29uc3RyYWludC1lbmNvZGUtMTAudHh0IHN0aWxsIHZhbGlkPz88bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48dT48c3BhbiBzdHlsZT0n Y29sb3I6IzFGNDk3RCc+PG86cD48c3BhbiBzdHlsZT0ndGV4dC1kZWNvcmF0aW9uOg0KIG5vbmUn PiZuYnNwOzwvc3Bhbj48L286cD48L3NwYW4+PC91PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs Pjx1PjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPjxzcGFuIHN0eWxlPSd0ZXh0LWRl Y29yYXRpb246DQogbm9uZSc+Jm5ic3A7PC9zcGFuPjwvbzpwPjwvc3Bhbj48L3U+PC9wPg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+PHU+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPlF1ZXN0aW9u cyBwZXJ0YWluaW5nIHRvDQqTZHJhZnQtaWV0Zi1jY2FtcC1nZW5lcmFsLWNvbnN0cmFpbnQtZW5j b2RlLTEwLnR4dJQ8bzpwPjwvbzpwPjwvc3Bhbj48L3U+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5 bGU9J3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMic+PCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4NCnN0eWxlPSdtc28tYmlkaS1mb250LXNpemU6MTAuMHB0O21zby1m YXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWJpZGktZm9udC1mYW1pbHk6DQpDYWxpYnJp O2NvbG9yOiMxRjQ5N0QnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPjEpPHNwYW4gc3R5 bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkluIFNlY3Rpb24gPHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpDb3VyaWVyJz4yLjMuQXZhaWxh YmxlIExhYmVscyBTdWItVExWIDwvc3Bhbj5kZWZpbmVzIHByaW9yaXR5IGFzIDgNCmJpdHM8c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVyJz4uIDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWluZGVudDou NWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkNvdXJpZXIn Pkg8L3NwYW4+b3dldmVyIGluIHRoZSBleGFtcGxlPHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7DQpmb250LWZhbWlseTpDb3VyaWVyJz4gPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 Q291cmllcic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7QS41Lg0KUHJpb3Jp dHkgRmxhZ3MgaW4gQXZhaWxhYmxlL1NoYXJlZCBCYWNrdXAgTGFiZWxzIHN1Yi1UTFY8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNClByaW9yaXR5IGlzIGRlZmluZWQgYXMgMyBiaXRzLjwvcD4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWluZGVudDouNWluJz5TaW5jZSB0aGVyZSBpcyBh IG1pc21hdGNoLCA8Yj48c3Bhbg0Kc3R5bGU9J2NvbG9yOnJlZCc+SG93IG1hbnkgYml0cyBzaG91 bGQgYmUgdXNlZCB0byByZXByZXNlbnQgcHJpb3JpdHk/PG86cD48L286cD48L3NwYW4+PC9iPjwv cD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5 bGU9J3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMic+PCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4NCnN0eWxlPSdtc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJp O21zby1iaWRpLWZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6IzFGNDk3RCc+PHNwYW4NCnN0eWxl PSdtc28tbGlzdDpJZ25vcmUnPjIpPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBS b21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3Nw YW4+PCFbZW5kaWZdPkluIHRoZSBzYW1lIGV4YW1wbGUgPHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7DQpmb250LWZhbWlseTpDb3VyaWVyJz5BLjUgUHJpb3JpdHkgRmxhZ3MgaW4gQXZhaWxh YmxlL1NoYXJlZCBCYWNrdXAgTGFiZWxzDQpzdWItVExWPC9zcGFuPiw8L3A+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD4mbmJzcDsmbmJzcDsNCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA3DQptZW50aW9uZWQgYXMg dGhlIGhpZ2hlc3QgcHJpb3JpdHkuIEluIEFTT04vUGFja2V0IHdvcmxkLCCTMJQgaXMgdGhlIGhp Z2hlc3QNCnByaW9yaXR5IGFuZCCTN5QgdGhlIGxvd2VzdC4gPC9wPg0KDQo8cCBjbGFzcz1Nc29O b3JtYWw+PGI+PHNwYW4gc3R5bGU9J2NvbG9yOnJlZCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Q291bGQNCnlvdSBwbGVhc2UgY29tbWVudCBhcyB0byB3aGV0aGVyIDAg b3IgNyBjb25zdGl0dXRlcyBoaWdoZXN0IHByaW9yaXR5ID88bzpwPjwvbzpwPjwvc3Bhbj48L2I+ PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjxwIGNs YXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDps MCBsZXZlbDEgbGZvMic+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4NCnN0eWxlPSdtc28tZmFy ZWFzdC1mb250LWZhbWlseTpDYWxpYnJpO21zby1iaWRpLWZvbnQtZmFtaWx5OkNhbGlicmk7Y29s b3I6IzFGNDk3RCc+PHNwYW4NCnN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPjMpPHNwYW4gc3R5bGU9 J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkluIHNlY3Rpb24gPGEgbmFtZT1z ZWN0aW9uLTIuMz48L2E+PGENCmhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtY2NhbXAtZ2VuZXJhbC1jb25zdHJhaW50LWVuY29kZS0xMCNzZWN0aW9uLTIuMyI+PHNw YW4NCnN0eWxlPSdjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lO3RleHQtdW5k ZXJsaW5lOm5vbmUnPjIuMzwvc3Bhbj48L2E+Lg0KQXZhaWxhYmxlIExhYmVscyBTdWItVExWPC9w Pg0KDQo8cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8 cHJlIHN0eWxlPSdwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMnPjxzcGFuIGxhbmc9RU4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7DQptc28tYW5zaS1sYW5ndWFnZTpFTic+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wcmU+PHByZSBzdHlsZT0ncGFnZS1icmVhay1iZWZvcmU6DQphbHdheXMnPjxz cGFuIGxhbmc9RU4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4n PiZuYnNwOyZuYnNwOyBUaGUgQXZhaWxhYmxlIExhYmVscyBzdWItVExWIGxpbmsgPHNwYW4NCnN0 eWxlPSdiYWNrZ3JvdW5kOnllbGxvdzttc28taGlnaGxpZ2h0OnllbGxvdyc+Y29uc2lzdHMgb2Yg YW4gYXZhaWxhYmlsaXR5IGZsYWcsPC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmUN CnN0eWxlPSdwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMnPjxzcGFuIGxhbmc9RU4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7DQptc28tYW5zaS1sYW5ndWFnZTpFTic+Jm5ic3A7Jm5ic3A7IHByaW9y aXR5IGZsYWdzLCBhbmQgYSBzaW5nbGUgdmFyaWFibGUgbGVuZ3RoIGxhYmVsIHNldCBmaWVsZCBh czxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmUNCnN0eWxlPSdwYWdlLWJyZWFrLWJlZm9yZTph bHdheXMnPjxzcGFuIGxhbmc9RU4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQptc28tYW5zaS1s YW5ndWFnZTpFTic+Jm5ic3A7Jm5ic3A7IGZvbGxvd3M6PG86cD48L286cD48L3NwYW4+PC9wcmU+ PHByZQ0Kc3R5bGU9J3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyc+PHNwYW4gbGFuZz1FTiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDsNCm1zby1hbnNpLWxhbmd1YWdlOkVOJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3ByZT48cHJlIHN0eWxlPSdwYWdlLWJyZWFrLWJlZm9yZToNCmFsd2F5cyc+ PHNwYW4gbGFuZz1FTiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDttc28tYW5zaS1sYW5ndWFnZTpF Tic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlDQpzdHls ZT0ncGFnZS1icmVhay1iZWZvcmU6YWx3YXlzJz48c3BhbiBsYW5nPUVOIHN0eWxlPSdmb250LXNp emU6MTAuMHB0Ow0KbXNvLWFuc2ktbGFuZ3VhZ2U6RU4nPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0 IDUgNiA3IDggOSAwIDE8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlDQpzdHlsZT0ncGFnZS1i cmVhay1iZWZvcmU6YWx3YXlzJz48c3BhbiBsYW5nPUVOIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 Ow0KbXNvLWFuc2ktbGFuZ3VhZ2U6RU4nPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst KzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmUNCnN0eWxlPSdwYWdlLWJyZWFrLWJlZm9yZTph bHdheXMnPjxzcGFuIGxhbmc9RU4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQptc28tYW5zaS1s YW5ndWFnZTpFTic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgUFJJJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgUmVzZXJ2ZWQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmUNCnN0eWxlPSdwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMn PjxzcGFuIGxhbmc9RU4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQptc28tYW5zaS1sYW5ndWFn ZTpFTic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPG86cD48L286cD48L3NwYW4+ PC9wcmU+PHByZQ0Kc3R5bGU9J3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyc+PHNwYW4gbGFuZz1F TiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCm1zby1hbnNpLWxhbmd1YWdlOkVOJz4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBMYWJlbCBTZXQgRmllbGQmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmUN CnN0eWxlPSdwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMnPjxzcGFuIGxhbmc9RU4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7DQptc28tYW5zaS1sYW5ndWFnZTpFTic+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7OjxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPjxwcmUNCnN0eWxlPSdwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMnPjxzcGFuIGxhbmc9 RU4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQptc28tYW5zaS1sYW5ndWFnZTpFTic+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZQ0K c3R5bGU9J3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyc+PHNwYW4gbGFuZz1FTiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDsNCm1zby1hbnNpLWxhbmd1YWdlOkVOJz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3ByZT48cHJlIHN0eWxlPSdwYWdlLWJyZWFrLWJlZm9yZToNCmFsd2F5cyc+PHNwYW4g bGFuZz1FTiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDttc28tYW5zaS1sYW5ndWFnZTpFTic+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+PHByZQ0Kc3R5bGU9J3BhZ2UtYnJlYWstYmVmb3Jl OmFsd2F5cyc+PHNwYW4gbGFuZz1FTiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCm1zby1hbnNp LWxhbmd1YWdlOkVOJz4mbmJzcDsmbmJzcDsgV2hlcmU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48 cHJlDQpzdHlsZT0ncGFnZS1icmVhay1iZWZvcmU6YWx3YXlzJz48c3BhbiBsYW5nPUVOIHN0eWxl PSdmb250LXNpemU6MTAuMHB0Ow0KbXNvLWFuc2ktbGFuZ3VhZ2U6RU4nPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcHJlPjxwcmUgc3R5bGU9J3BhZ2UtYnJlYWstYmVmb3JlOg0KYWx3YXlzJz48 c3BhbiBsYW5nPUVOIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O21zby1hbnNpLWxhbmd1YWdlOkVO Jz4mbmJzcDsmbmJzcDsgUFJJIChQcmlvcml0eSBGbGFncywgOCBiaXRzKTogSW5kaWNhdGVzIHBy aW9yaXR5IGxldmVsIGFwcGxpZWQgdG88bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlDQpzdHls ZT0ncGFnZS1icmVhay1iZWZvcmU6YWx3YXlzJz48c3BhbiBsYW5nPUVOIHN0eWxlPSdmb250LXNp emU6MTAuMHB0Ow0KbXNvLWFuc2ktbGFuZ3VhZ2U6RU4nPiZuYnNwOyZuYnNwOyBMYWJlbCBTZXQg RmllbGQuIDxzcGFuIHN0eWxlPSdiYWNrZ3JvdW5kOg0KeWVsbG93O21zby1oaWdobGlnaHQ6eWVs bG93Jz5CaXQgOCBjb3JyZXNwb25kcyB0byBwcmlvcml0eSBsZXZlbCAwIGFuZCBiaXQgMTU8bzpw PjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wcmU+PHByZQ0Kc3R5bGU9J3BhZ2UtYnJlYWstYmVmb3Jl OmFsd2F5cyc+PHNwYW4gbGFuZz1FTiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmJhY2tncm91 bmQ6eWVsbG93O21zby1oaWdobGlnaHQ6eWVsbG93O21zby1hbnNpLWxhbmd1YWdlOkVOJz4mbmJz cDsmbmJzcDsgY29ycmVzcG9uZHMgdG8gcHJpb3JpdHkgbGV2ZWwgNy48L3NwYW4+PHNwYW4NCmxh bmc9RU4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4nPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmUNCnN0eWxlPSdwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMn PjxzcGFuIGxhbmc9RU4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQptc28tYW5zaS1sYW5ndWFn ZTpFTic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGI+PHNwYW4gc3R5bGU9J2NvbG9yOnJlZCc+YSk8 L3NwYW4+PC9iPjxzcGFuDQpzdHlsZT0nY29sb3I6cmVkJz4gPGI+Jm5ic3A7V2hhdCBpcyB0aGUg dXNlL2RlZmluaXRpb24gb2YgYXZhaWxhYmlsaXR5IGZsYWcgPzwvYj48L3NwYW4+PGI+DQo8bzpw PjwvbzpwPjwvYj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nY29s b3I6cmVkJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtiKQ0KV2hlcmUgc2hvdWxkICZu YnNwO3ByaW9yaXR5IGJlICZuYnNwO2VuY29kZWQsIGluIHRoZSBmaXJzdCBieXRlKDAtN2JpdHMp IG9yDQooOC0xNWJpdHMpPyBEaWFncmFtIHNob3cgdGhlIGZpcnN0IGJ5dGUgd2hlcmVhcyB0aGU8 bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4g c3R5bGU9J2NvbG9yOnJlZCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQombmJzcDtl eHBsYW5hdGlvbiBzYXlzIGl0IGFzIHRoZSBzZWNvbmQgYnl0ZS48bzpwPjwvbzpwPjwvc3Bhbj48 L2I+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3RleHQtaW5kZW50Oi41aW4nPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSd0 ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzInPjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuDQpzdHlsZT0nbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTttc28t YmlkaS1mb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0QnPjxzcGFuDQpzdHlsZT0nbXNv LWxpc3Q6SWdub3JlJz40KTxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4i Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwh W2VuZGlmXT5JbiCTQXZhaWxhYmxlIExhYmVscyBTdWItVExWlCwgYXNzdW1pbmcgUHJpb3JpdHkN CmlzIGRlZmluZWQgYnkgOCBCaXRzIJY8L3A+DQoNCjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGg+ SWYgdHdvIGJpdHMgYXJlIHNldCB0byBpbmRpY2F0ZSB0aGF0IGF2YWlsYWJsZSBsYWJlbHMNCmZv ciAyIHByaW9yaXRpZXMsIHNob3VsZCB0aGUgYXZhaWxhYmxlIGxhYmVscyBhdCBlYWNoIHByaW9y aXR5IGJlIGVuY29kZWQgYXMNCmJlbG93PzwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3BhZ2UtYnJlYWst YmVmb3JlOmFsd2F5cyc+PHNwYW4gbGFuZz1FTg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijttc28tYW5zaS1sYW5ndWFnZTpFTic+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQowJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7DQoxJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQoyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQozPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyc+PHNwYW4gbGFuZz1FTg0Kc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijttc28tYW5zaS1sYW5ndWFn ZTpFTic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQowIDEgMiAzIDQgNSA2IDcgOCA5 IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDE8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ncGFnZS1icmVhay1iZWZvcmU6 YWx3YXlzJz48c3BhbiBsYW5nPUVODQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiQ291cmllciBOZXciO21zby1hbnNpLWxhbmd1YWdlOkVOJz4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyc+PHNwYW4gbGFuZz1FTg0Kc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijttc28tYW5zaS1sYW5n dWFnZTpFTic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQp8IDxzcGFuIHN0eWxlPSdiYWNrZ3Jv dW5kOnllbGxvdzttc28taGlnaGxpZ2h0OnllbGxvdyc+MDEwMDAwMDE8L3NwYW4+Jm5ic3A7DQp8 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQpSZXNlcnZlZCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMnPjxzcGFuIGxhbmc9RU4NCnN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4n PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ncGFnZS1icmVhay1iZWZvcmU6YWx3YXlzJz48 c3BhbiBsYW5nPUVODQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmll ciBOZXciO21zby1hbnNpLWxhbmd1YWdlOkVOJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCnwm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjxzcGFuIHN0eWxlPSdiYWNrZ3JvdW5kOnllbGxvdzttc28taGlnaGxpZ2h0OnllbGxv dyc+TGFiZWwgU2V0IEZpZWxkIGZvcg0KcHJpb3JpdHkgPSAxPC9zcGFuPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3BhZ2UtYnJlYWstYmVmb3JlOmFs d2F5cyc+PHNwYW4gbGFuZz1FTg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijttc28tYW5zaS1sYW5ndWFnZTpFTic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7DQo6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo6PG86cD48L286cD48L3NwYW4+ PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5 cyc+PHNwYW4gbGFuZz1FTg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijttc28tYW5zaS1sYW5ndWFnZTpFTic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMnPjxzcGFuIGxhbmc9RU4NCnN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7bXNvLWFuc2ktbGFuZ3VhZ2U6 RU4nPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPHNwYW4gc3R5bGU9J2JhY2tn cm91bmQ6eWVsbG93O21zby1oaWdobGlnaHQ6eWVsbG93Jz5MYWJlbCBTZXQgRmllbGQgZm9yDQpw cmlvcml0eSA9IDc8L3NwYW4+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0ncGFnZS1icmVhay1iZWZvcmU6YWx3YXlzJz48c3BhbiBsYW5nPUVODQpzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO21zby1hbnNpLWxh bmd1YWdlOkVOJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjombmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0ncGFnZS1icmVhay1iZWZvcmU6YWx3YXlzJz48c3BhbiBsYW5nPUVODQpzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO21zby1hbnNpLWxhbmd1 YWdlOkVOJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCistKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3BhZ2UtYnJlYWstYmVmb3JlOmFs d2F5cyc+PHNwYW4gbGFuZz1FTg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijttc28tYW5zaS1sYW5ndWFnZTpFTic+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjxw IGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlz dDpsMCBsZXZlbDEgbGZvMic+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4NCnN0eWxlPSdtc28t ZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpO21zby1iaWRpLWZvbnQtZmFtaWx5OkNhbGlicmk7 Y29sb3I6IzFGNDk3RCc+PHNwYW4NCnN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPjUpPHNwYW4gc3R5 bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkluIHRoZTxzcGFuIHN0eWxl PSdjb2xvcjojMUY0OTdEJz4gPC9zcGFuPpNMYWJlbA0KU2V0lCBmaWVsZCBvZiBBdmFpbGFibDxz cGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5lPC9zcGFuPiBMYWJlbCBzZXQgVExWLA0KJm5ic3A7 d2hhdCBkb2VzIJNMb3dlc3QgRnJlcXVlbmN5lCBzaWduaWZ5PzwvcD4NCg0KPHAgY2xhc3M9TXNv TGlzdFBhcmFncmFwaD5JcyBpdCB0aGUgbG93ZXN0IGZyZXF1ZW5jeSBzdXBwb3J0ZWQgYnkgdGhl IHBvcnQgZm9yDQphIHBhcnRpY3VsYXIgZ3JpZCBhbmQgY2hhbm5lbCBzcGFjaW5nID88L3A+DQoN CjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGg+T1I8L3A+DQoNCjxwIGNsYXNzPU1zb0xpc3RQYXJh Z3JhcGg+SXMgaXQgdGhlIGxvd2VzdCBhdmFpbGFibGUgZnJlcXVlbmN5IGkuZSB0aGUgbG93ZXN0 DQpmcmVxdWVuY3kgd2hpY2ggaXMgbm90IGluIHVzZSwgYXQgdGhhdCBwb2ludCBpbiB0aW1lPzwv cD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCkluIEV4YW1wbGUgQS4yPHNwYW4gc3R5bGU9J2NvbG9y OiMxRjQ5N0QnPiA8L3NwYW4+aW4gdGhlIGRyYWZ0LDwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KRm9yIHRoZSBmb2xsb3dpbmcgZnJl cXVlbmNpZXMgd2hpY2ggYXJlIGF2YWlsYWJsZSAoYW5kIG5vdCBpbiB1c2UpPC9wPg0KDQo8cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2xpbmUtaGVpZ2h0OjE0LjRwdCc+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgRnJlcXVlbmN5DQooVEh6KSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBuIFZhbHVlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQpiaXQg bWFwIHBvc2l0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J2xpbmUtaGVpZ2h0OjE0LjRwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 DQpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsmbmJzcDsmbmJzcDsNCiZuYnNwOy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286 cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2xpbmUtaGVpZ2h0OjE0 LjRwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseToiQ291cmll ciBOZXciJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPHNwYW4NCnN0eWxlPSdiYWNr Z3JvdW5kOnllbGxvdzttc28taGlnaGxpZ2h0OnllbGxvdyc+MTkyLjAmbmJzcDsmbmJzcDsmbmJz cDsNCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Oy0xMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KMDwvc3Bh bj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbGlu ZS1oZWlnaHQ6MTQuNHB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KMTkyLjUm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCi02Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo1PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J2xpbmUtaGVpZ2h0OjE0LjRwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7DQpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjE5My4xJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQowJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQoxMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdsaW5lLWhlaWdodDoxNC40cHQnPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQoxOTMuOSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KOCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KMTk8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbGluZS1oZWlnaHQ6MTQuNHB0Jz48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIn PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KMTk0LjAmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjIwPG86 cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2xpbmUtaGVp Z2h0OjE0LjRwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseToi Q291cmllciBOZXciJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjE5NS4yJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7DQoyMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOw0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7MzI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bGluZS1oZWlnaHQ6MTQuNHB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KMTk1 LjgmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjI3Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQozODxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdsaW5lLWhlaWdodDoxNC40cHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 Ow0KZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDwvc3Bhbj48c3Bhbg0Kc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPkVuY29kaW5nIGlzOjwvc3Bh bj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyInPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSds aW5lLWhlaWdodDoxNC40cHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAgMSAy IDMgNCA1IDYgNyA4IDkgMA0KMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAw IDE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbGlu ZS1oZWlnaHQ6MTQuNHB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbGluZS1oZWln aHQ6MTQuNHB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IDQmbmJzcDsmbmJz cDsmbmJzcDsNCnwgTnVtIFdhdmVsZW5ndGhzID0gNDAmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNw OyBMZW5ndGggPSAxNg0KYnl0ZXMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdsaW5lLWhlaWdodDoxNC40cHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0Ow0KZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7DQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdsaW5lLWhlaWdodDoxNC40cHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 Ow0KZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHxH cmlkIHwmbmJzcDsgQy5TLg0KfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSZXNlcnZl ZCZuYnNwOyZuYnNwOyA8c3BhbiBzdHlsZT0nYmFja2dyb3VuZDoNCnllbGxvdzttc28taGlnaGxp Z2h0OnllbGxvdyc+fCBuJm5ic3A7IGZvciBsb3dlc3QgZnJlcXVlbmN5ID0gLTExPC9zcGFuPiB8 PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2xpbmUt aGVpZ2h0OjE0LjRwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWls eToiQ291cmllciBOZXciJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCistKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPG86cD48 L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2xpbmUtaGVpZ2h0 OjE0LjRwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseToiQ291 cmllciBOZXciJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDEgMCAwIDAgMCAxIDAgMCAwIDAg MCAxIDANCjAgMCAwIDAgMCAwIDEgMSAwIDAgMCAwIDAgMCAwIDAgMCAwIDB8PG86cD48L286cD48 L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2xpbmUtaGVpZ2h0OjE0LjRw dCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseToiQ291cmllciBO ZXciJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCistKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPG86cD48L286cD48L3NwYW4+ PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2xpbmUtaGVpZ2h0OjE0LjRwdCc+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseToiQ291cmllciBOZXciJz4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDEgMCAwIDAgMCAwIDENCjB8Jm5ic3A7Jm5ic3A7IE5v dCB1c2VkIGluIDQwIENoYW5uZWwgc3lzdGVtIChhbGwgemVyb3MpJm5ic3A7Jm5ic3A7IHw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbGluZS1oZWln aHQ6MTQuNHB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFG NDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KSWYgdGhlIGF2YWlsYWJsZSBmcmVxdWVuY2llcyBhcmU6PG86cD48L286cD48L3NwYW4+ PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2xpbmUtaGVpZ2h0OjE0LjRwdCc+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseToiQ291cmllciBOZXciJz4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRnJlcXVlbmN5DQooVEh6KSZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBuIFZhbHVlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7DQpiaXQgbWFwIHBvc2l0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J2xpbmUtaGVpZ2h0OjE0LjRwdCc+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsmbmJzcDsmbmJz cDsNCiZuYnNwOy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2xp bmUtaGVpZ2h0OjE0LjRwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZh bWlseToiQ291cmllciBOZXciJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjE5My45 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo4Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQoxOTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdsaW5lLWhlaWdodDoxNC40cHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0Ow0KZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7DQoxOTQuMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KOSZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KMjA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbGluZS1oZWlnaHQ6MTQuNHB0Jz48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KMTk1LjImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjIxJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDszMjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdsaW5lLWhlaWdodDoxNC40cHQnPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQoxOTUuOCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K MjcmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjM4PG86cD48L286cD48 L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2xpbmUtaGVpZ2h0OjE0LjRw dCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseToiQ291cmllciBO ZXciJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nbGluZS1oZWlnaHQ6MTQuNHB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsN CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyA8L3NwYW4+PGI+PHNwYW4NCnN0eWxlPSdjb2xvcjojMUY0OTdEJz5XaWxsIHRoZSB2YWx1ZSBv ZiCTbpQgY2hhbmdlIGluIHRoZSBlbmNvZGluZyBjaGFuZ2UgdG8NCpM4lCwgT1Igd2lsbCBpdCBz dGlsbCByZW1haW4gky0xMZQgPzwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7DQpmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOiMxRjQ5N0QnPjxvOnA+PC9v OnA+PC9zcGFuPjwvYj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbGluZS1oZWln aHQ6MTQuNHB0Jz48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDwvc3Bhbj48c3Bhbg0Kc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPldpbGwgdGhlIEVuY29kaW5n IGNoYW5nZSBhcyBiZWxvdzo8L3NwYW4+PC9iPjxiPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOiMxRjQ5N0QnPjxvOnA+PC9vOnA+ PC9zcGFuPjwvYj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbGluZS1oZWlnaHQ6 MTQuNHB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwIDEgMiAzIDQgNSA2IDcg OCA5IDANCjEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxPG86cD48L286 cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2xpbmUtaGVpZ2h0OjE0 LjRwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseToiQ291cmll ciBOZXciJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCistKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2xpbmUtaGVpZ2h0OjE0LjRwdCc+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseToiQ291cmllciBOZXci Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyA0Jm5ic3A7Jm5ic3A7Jm5ic3A7DQp8 IE51bSBXYXZlbGVuZ3RocyA9IDQwJm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsgTGVuZ3RoID0g MTYNCmJ5dGVzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbGluZS1oZWlnaHQ6MTQuNHB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbGlu ZS1oZWlnaHQ6MTQuNHB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8R3JpZCB8Jm5ic3A7 IEMuUy4NCnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVzZXJ2ZWQmbmJzcDsmbmJz cDsgPHNwYW4gc3R5bGU9J2JhY2tncm91bmQ6DQp5ZWxsb3c7bXNvLWhpZ2hsaWdodDp5ZWxsb3cn PnwgbiZuYnNwOyBmb3IgbG93ZXN0IGZyZXF1ZW5jeSA9IDg8L3NwYW4+IHw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbGluZS1oZWlnaHQ6MTQuNHB0 Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbGluZS1oZWlnaHQ6MTQuNHB0Jz48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8MSAwIDAgMCAwIDEgMCAwIDAgMCAwIDEgMA0KMCAwIDAg MCAwIDAgMSAxIDAgMCAwIDAgMCAwIDAgMCAwIDAgMHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoN CjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbGluZS1oZWlnaHQ6MTQuNHB0Jz48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdsaW5lLWhlaWdodDoxNC40cHQnPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHwxIDAgMCAwIDAgMCAxDQowfCZuYnNwOyZuYnNwOyBOb3QgdXNlZCBpbiA0MCBD aGFubmVsIHN5c3RlbSAoYWxsIHplcm9zKSZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3NwYW4+ PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2xpbmUtaGVpZ2h0OjE0LjRwdCc+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseToiQ291cmllciBOZXciJz4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPG86cD48L286cD48L3NwYW4+PC9wPg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdj b2xvcjojMUY0OTdEJz5UaGFua3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+QW5uYXBvb3JuaTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K DQo8cD5UaGlzIGUtbWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIGZvciB0aGUgcmVjaXBpZW50IG9u bHkgYW5kIGNvbnRhaW5zDQppbmZvcm1hdGlvbiB3aGljaCBpcyBDT05GSURFTlRJQUwgYW5kIHdo aWNoIG1heSBiZSBwcm9wcmlldGFyeSB0byBFQ0kgVGVsZWNvbS4NCklmIHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW5mb3JtIHVzIGJ5IGUtbWFp bCwNCnBob25lIG9yIGZheCwgYW5kIHRoZW4gZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYWxsIGNv cGllcyB0aGVyZW9mLiA8L3A+DQoNCjwvZGl2Pg0KDQo8L2JvZHk+DQoNCjwvaHRtbD4NCg== --_002_7AEB3D6833318045B4AE71C2C87E8E1729139D44dfweml511mbschi_-- From lberger@labn.net Tue May 7 06:52:28 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84E5F21F8C69 for ; Tue, 7 May 2013 06:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.591 X-Spam-Level: X-Spam-Status: No, score=-100.591 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OEOv+dEu4etV for ; Tue, 7 May 2013 06:52:21 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id BD8A321F8BE4 for ; Tue, 7 May 2013 06:52:20 -0700 (PDT) Received: (qmail 30890 invoked by uid 0); 7 May 2013 13:51:53 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 7 May 2013 13:51:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=wI1sY7uU8VEmvZXDi2JObNVMondgutubjk3XgBhiiOs=; b=lviHvPUXqhRgf5dbbaBCi/D0PE4y5LZTqjMGLYC9w7ju5Qs/gCPxQWGdQTZsZF2UQoslp6WNbbfv4GrH26Ymowe1ND8hh47Glr2CgfUTWU+SolrkW66Z4HgD0IQE6/YI; Received: from box313.bluehost.com ([69.89.31.113]:55884 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UZiJ7-00055F-Dd; Tue, 07 May 2013 07:51:53 -0600 Message-ID: <518906F8.50507@labn.net> Date: Tue, 07 May 2013 09:51:52 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Leeyoung References: <8DC6547C806B644F998A0566E79E15920F7DFF60@DEMUMBX006.nsn-intra.net> <7AEB3D6833318045B4AE71C2C87E8E172911828D@dfweml511-mbs.china.huawei.com> <8DC6547C806B644F998A0566E79E15920F7E1284@DEMUMBX006.nsn-intra.net> <7AEB3D6833318045B4AE71C2C87E8E172911D7BA@dfweml511-mbs.china.huawei.com> <51471168.3000400@labn.net> <7AEB3D6833318045B4AE71C2C87E8E172911DC5E@dfweml511-mbs.china.huawei.com> <514895C5.7080300@labn.net> <7AEB3D6833318045B4AE71C2C87E8E1729121785@dfweml511-mbs.china.huawei.com> <515DF956.1020305@labn.net> <7AEB3D6833318045B4AE71C2C87E8E172913671A@dfweml511-mbs.china.huawei.com> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E172913671A@dfweml511-mbs.china.huawei.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP , "draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org" Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 13:52:28 -0000 [oops, found this in my outbox -- sorry about the delay] Young, I think this discussion primarily comes down to the intent of mentioning drop ports in several places in Section 6 of the info document. Is the scope of this text aimed at just regen ports or any drop (regen &trib) ports? The text isn't scoped so, as I mentioned/asked in my mail on 4/4, I understood it to refer to the advertisement of information for any drop port. so: > Did I misunderstand the intent of mentioning drop ports in several > places in Section 6 of the info document? If the intended scope is just regen, this needs to be made clear in the documents. Furthermore, as the same (G-PID compatibility identification) issue exists with the egress, why wouldn't the same solution be used for both? Much thanks, Lou On 4/24/2013 12:17 PM, Leeyoung wrote: > Hi Lou, > > I think the main point is if we need to advertise add/drop > (tributary) ports in generic context? You said in the previous > email: > > "I agree that that is how it is normally done, but WSON seems to be changing this in two respects: > 1) By advertising G-PID at all, > 2) By advertising add/drop ports, where prior GMPLS approaches have only advertised the network facing interfaces." > > These elements above are part of regeneration elements that > constitute a WSON lightpath which begins the line side of ingress and > ends the line side of egress. See the diagram below: > > ---- ---- > | |<------------ -------------->| | > ---- | | ---- > -------- > | REG | > -------- > There is a clear use case for this for WSON as REG's are integral > part of a WSON lightpath which can cause an incompatibility/blocking > issue of the path. Drop/Add ports here in REG element may have > wavelength restriction and that is why this is an additional > constraint to look at. > > Advertising tributary ports in general context is a different matter > to me. Not sure if there is a clear use case that can be justified to > support advertising tributary ports in general context. Even if there > is, I don't think that is part of the scope of the generic encoding. > > > Regards, > Young > > > > > > > > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Lou Berger > Sent: Thursday, April 04, 2013 5:06 PM > To: Leeyoung > Cc: CCAMP; draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org > Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19 > > Young, > Please see below. > > On 3/27/2013 1:59 PM, Leeyoung wrote: >> Hi Lou, >> >> Please see my comments in-line. >> >> Thanks. >> Young >> >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Tuesday, March 19, 2013 11:44 AM >> To: Leeyoung >> Cc: CCAMP; Margaria, Cyril (NSN - DE/Munich); >> draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org >> Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19 >> >> >> Young, >> See below. >> On 3/18/2013 1:02 PM, Leeyoung wrote: >>> Hi Lou, >>> >>> The encoding is a part of the Resource Block >> >> Understood, but my comment was more on the definition of >> / encoding. >> >>> (that includes Regenerators and Wavelength converters) which is a WSON specific entity. >> >> So I agree that the need for transit nodes to have detailed encoding >> and adaptation information to support 3R and certain other types of >> switching is (at least to my understanding) specific to WSON. >> > > Y> YOUNG>> RFC 3471 and RFC 4328 discuss G-PID as part of Generalized > Y> Label Request parameters to indicate client/tributary layer of the > Y> LSP at the source/sink. > Y> > Y> I was not clear on what you meant "trib side resources." If you meant > Y> "trib side resources" are LSP encoding type, Switching Type and G-PID > Y> (which are covered by RFC 3471/4328), I believe RFC 3471/4328 are > Y> sufficient; if not could you elaborate? > > trib side = add/drop port at ingress/egress > > resources = attributes related to data that port can transport > >> >> But unless I misunderstand the WSON info draft, this same information >> can be advertised in support of the trib side resources (i.e., at the >> source/destination for add/drop) and this is a generic requirement >> shared with other technologies. >> > > y> YOUNG>> Here you seemed to allude the need for advertizing the > y> Source/Destination tributary resource information using IGP. In > y> general, OSPF does not advertise the trib-side information, does it? > y> I believe signaling check on the tributary resource info on LSP level > y> is good enough per RFC 3471/4328. Please correct me if my > y> understanding is wrong. > > > I agree that that is how it is normally done, but WSON seems to be changing this in two respects: > 1) By advertising G-PID at all, > 2) By advertising add/drop ports, where prior GMPLS approaches have only advertised the network facing interfaces. > > Did I misunderstand the intent of mentioning drop ports in several places in Section 6 of the info document? > >> >> So this lead me to ask about changing the G-PID list encoding to be >> defined in the generic drafts (to facilitate PID advertisement for >> non-WSON technologies.) Perhaps just having a generic encoding for a >> G-PID list won't be of much value, but I suspect that we'll end up >> needing it for other technologies too. >> > > Y> YOUNG>> This point is carried from the above discussion. G-PID has > Y> been specified to cover all GMPLS related technologies. > > Agreed that this is a derivative point and can wait until the above is clarified. > >> -- For what it's worth I am having some trouble understanding how >> G-PID is advertised for add/drop. As far as I can tell, you have a >> per add/drop port, mapped to , to a >> and infer output G-PID from the . >> At least that's how I'm reading the info draft. > > Y> YOUNG>> Actually G-PID is advertised as part of the Node > Y> information: ::= [...] > Y> [] > > Got that. That's what I was referring to when I said " mapped to " >> >> Look at the diagram below from info draft: >> >> I1 +-------------+ +-------------+ E1 >> ----->| | +--------+ | |-----> >> I2 | +------+ Rb #1 +-------+ | E2 >> ----->| | +--------+ | |-----> >> | | | | >> | Resource | +--------+ | Resource | >> | Pool +------+ +-------+ Pool | >> | | + Rb #2 + | | >> | Input +------+ +-------| Output | >> | Connection | +--------+ | Connection | >> | Matrix | . | Matrix | >> | | . | | >> | | . | | >> IN | | +--------+ | | EM >> ----->| +------+ Rb #P +-------+ |-----> >> | | +--------+ | | >> +-------------+ ^ ^ +-------------+ >> | | >> | | >> | | >> | | >> >> Input wavelength Output wavelength >> constraints for constraints for >> each resource each resource >> >> Figure 1 Schematic diagram of resource pool model. >> >> Add/Drop ports to/from Resource Pool (i.e., I1,...IN and E1,..EN) is >> part of link information and advertised as link-TLV; however Resource >> Blocks and its internal connectivity is not modeled as node property >> as they are internal to Resource Pool. >> >> ::= ... >> [...] [...] >> [] >> >> We modeled how RB's are accessible via matrices (input/ouput), if >> there are wavelength limitations and if RB's are available. All of >> these are modeled as the node property. >> >> And within RBinfo, we included Input/Output Constraints where ClientSignalList (GPID) is specified. >> >> ::= ([] >> [] )* >> >> Where >> ::= [] >> [] >> >> >> >> I was delaying asking if a couple of related questions until the above >> was resolved, but perhaps it makes sense to ask them now: >> - Shouldn't also be allowed under ? >> >> YOUNG>> It is implied. is checked in and has obviously the same property. We can add this comment to clarify. >> > > So there is/will never (be) a case where the differ from the ? As you say, this certainly should be made explicit. > >> - Doesn't it make sense to simplify the add/drop G-PID identification >> by adding somewhere under (generic) ? >> > y> YOUNG>> I think you meant doing this at the source/destination. > sure, but aren't add/drop always at source/destination? (I guess you can come up with a case where they aren't, but this isn't the norm...) > > Y> Again > y> I am not sure if we really need to advertise tributary client signal > y> as link TLV. We have signaling mechanism to verify this. > > As you say, this point is covered above. > >> Thanks, >> Lou >> >>> >>> Regards, >>> Young >>> >>> -----Original Message----- >>> From: Lou Berger [mailto:lberger@labn.net] >>> Sent: Monday, March 18, 2013 8:07 AM >>> To: Leeyoung; CCAMP >>> Cc: Margaria, Cyril (NSN - DE/Munich); >>> draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org >>> Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19 >>> >>> Young/All, >>> >>> Some of the discussions last week (on 709 and dimitri's) got me >>> thinking more about the inclusion of G-PID on the wson specific >>> encoding. As G-PID and other client/input information is not >>> technology specific, and it looks like there's a likely a need for a >>> general solution, shouldn't the G-PID (and other 'client/input') >>> information be in draft-ietf-ccamp-general-constraint-encode? >>> >>> Thoughts? >>> >>> Lou >>> >>> On 3/15/2013 5:35 AM, Leeyoung wrote: >>>> Thanks. >>>> >>>> Young >>>> >>>> -----Original Message----- >>>> From: Margaria, Cyril (NSN - DE/Munich) >>>> [mailto:cyril.margaria@nsn.com] >>>> Sent: Thursday, March 14, 2013 5:53 PM >>>> To: Leeyoung; CCAMP; draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org >>>> Subject: RE: Comments on draft-ietf-ccamp-rwa-wson-encode-19 >>>> >>>> >>>> Hi, >>>> >>>> Thanks for the quick feedback. As this introduce a dependency with >>>> the GPID, the text should indicate that the number of bit rate MUST match the number of GPID. >>>> >>>> Other than that I think this is acceptable >>>> >>>> >>>> >>>> Best regards / Mit freundlichen Grüßen Cyril Margaria >>>> >>>> >>>>> -----Original Message----- >>>>> From: ext Leeyoung [mailto:leeyoung@huawei.com] >>>>> Sent: Wednesday, March 13, 2013 9:33 PM >>>>> To: Margaria, Cyril (NSN - DE/Munich); CCAMP; draft-ietf-ccamp-rwa- >>>>> wson-encode@tools.ietf.org >>>>> Subject: RE: Comments on draft-ietf-ccamp-rwa-wson-encode-19 >>>>> >>>>> Hi Cyril, >>>>> >>>>> Thanks for your comment. >>>>> >>>>> This refers to the "Input Bit Rate" of the associated client Signal >>>>> Type in the RB. >>>>> Below is a new section 5.4 that defines Input Bit Rate List Sub-Sub- >>>>> TLV. We removed "range" from this Sub-Sub-TLV. >>>>> >>>>> Let me know if this is acceptable. >>>>> >>>>> Thanks. >>>>> Young >>>>> >>>>> --------------------------------------------------------------------- >>>>> >>>>> 5.4. Input Bit Rate List Sub-Sub-TLV >>>>> >>>>> This sub-sub-TLV contains a list of bit rate of each input client >>>>> signal types specified in the Input Client Signal List Sub-Sub-TLV. >>>>> Type := Input Bit Rate List >>>>> Value := IEEE 32-bit IEEE Floating Point >>>>> >>>>> 0 1 2 3 >>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | Input Bit Rate of GPID #1 | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> : : >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | Input Bit Rate of GPID #N | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf >>>>> Of Margaria, Cyril (NSN - DE/Munich) >>>>> Sent: Wednesday, March 13, 2013 8:54 AM >>>>> To: CCAMP; draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org >>>>> Subject: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19 >>>>> >>>>> Dear Authors, >>>>> >>>>> I have the following comments on draft-ietf-ccamp-rwa-wson-encode-19 >>>>> >>>>> Section 5.1 Resource Block Information Sub-TLV >>>>> >>>>> The sub-TLV format defines the "Input Bit Rate Range List Sub-Sub-TLV >>>>> (opt)" >>>>> No section defines the Input Bit range List Sub-Sub-TLV, while it was >>>>> present in the previous version. >>>>> >>>>> I think the section should be re-added. >>>>> >>>>> >>>>> Mit freundlichen Grüßen / Best Regards >>>>> Cyril Margaria >>>>> >>>>> Nokia Siemens Networks Optical GmbH >>>>> St.Martin-Str. 76 >>>>> D-81541 München >>>>> Germany >>>>> mailto:cyril.margaria@nsn.com >>>>> Phone: +49-89-5159-16934 >>>>> Fax: +49-89-5159-44-16934 >>>>> ---------------------------------------------------------------- >>>>> Nokia Siemens Networks Optical GmbH >>>>> Geschäftsleitung / Board of Directors: Gero Neumeier, Dr. Rolf Nauerz >>>>> Sitz der Gesellschaft: München / Registered office: Munich >>>>> Registergericht: München / Commercial registry: Munich, HRB 197143 >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>> _______________________________________________ >>>> CCAMP mailing list >>>> CCAMP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ccamp >>>> >>>> >>>> >>>> >>> >>> >>> >>> >> >> >> >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > > From leeyoung@huawei.com Tue May 7 12:07:25 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6EE021F940B for ; Tue, 7 May 2013 12:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4R+11mVKwTD4 for ; Tue, 7 May 2013 12:07:21 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 199CD21F93D8 for ; Tue, 7 May 2013 12:07:06 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASN51616; Tue, 07 May 2013 19:07:05 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 7 May 2013 20:06:59 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 7 May 2013 20:07:02 +0100 Received: from dfweml511-mbs.china.huawei.com ([169.254.15.13]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.007; Tue, 7 May 2013 12:06:58 -0700 From: Leeyoung To: Lou Berger Thread-Topic: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19 Thread-Index: AQHOMYCjjSbgAyDhM0mIOPaGuA1CEpjloTRAgBTFMQD//9tXAA== Date: Tue, 7 May 2013 19:06:58 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172913A254@dfweml511-mbs.china.huawei.com> References: <8DC6547C806B644F998A0566E79E15920F7DFF60@DEMUMBX006.nsn-intra.net> <7AEB3D6833318045B4AE71C2C87E8E172911828D@dfweml511-mbs.china.huawei.com> <8DC6547C806B644F998A0566E79E15920F7E1284@DEMUMBX006.nsn-intra.net> <7AEB3D6833318045B4AE71C2C87E8E172911D7BA@dfweml511-mbs.china.huawei.com> <51471168.3000400@labn.net> <7AEB3D6833318045B4AE71C2C87E8E172911DC5E@dfweml511-mbs.china.huawei.com> <514895C5.7080300@labn.net> <7AEB3D6833318045B4AE71C2C87E8E1729121785@dfweml511-mbs.china.huawei.com> <515DF956.1020305@labn.net> <7AEB3D6833318045B4AE71C2C87E8E172913671A@dfweml511-mbs.china.huawei.com> <518906F8.50507@labn.net> In-Reply-To: <518906F8.50507@labn.net> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.108] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: CCAMP , "draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org" Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 19:07:26 -0000 Hi Lou, Yes, the scope of drop ports mentioned in Section 6 of the info document is= aimed at just Regen ports. I will make this point clear in the revision of= the info draft.=20 As we modeled Regen signal compatibility that includes Regen drop port limi= tation, G-PID compatibility identification for Regen (in and out) is includ= ed as part of the "package" per se to advertise all Regen related constrain= ts using IGP.=20 Egress G-PID compatibility check has been built as part of GMPLS Signaling,= which I believe serves the purpose well.=20 If you want Egress (tributary side) G-PID compatibility check using IGP, th= is is a whole different matter. First, I think we need a clear use-case and= requirement why we want to do this in light of the signaling mechanism tha= t does the check. Let me know if this is not the case from your perspective= . Are there some reasons you believe GMPLS Signaling mechanism would not wo= rk to check the tributary egress G-PID check?=20 Regards, Young=20 =20 -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Tuesday, May 07, 2013 8:52 AM To: Leeyoung Cc: CCAMP; draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19 [oops, found this in my outbox -- sorry about the delay] Young, I think this discussion primarily comes down to the intent of mentioning dr= op ports in several places in Section 6 of the info document. Is the scope of this text aimed at just regen ports or any drop (regen &trib) ports? The text isn't scoped so, as I mentioned/asked in my mail on = 4/4, I understood it to refer to the advertisement of information for any d= rop port. so: > Did I misunderstand the intent of mentioning drop ports in several=20 > places in Section 6 of the info document? If the intended scope is just regen, this needs to be made clear in the doc= uments. Furthermore, as the same (G-PID compatibility identification) issue exists with the egress, why wouldn't the same solutio= n be used for both? Much thanks, Lou On 4/24/2013 12:17 PM, Leeyoung wrote: > Hi Lou, >=20 > I think the main point is if we need to advertise add/drop > (tributary) ports in generic context? You said in the previous > email: >=20 > "I agree that that is how it is normally done, but WSON seems to be chang= ing this in two respects: > 1) By advertising G-PID at all, > 2) By advertising add/drop ports, where prior GMPLS approaches have only = advertised the network facing interfaces." >=20 > These elements above are part of regeneration elements that constitute=20 > a WSON lightpath which begins the line side of ingress and ends the=20 > line side of egress. See the diagram below: >=20 > ---- ---- > | |<------------ -------------->| | > ---- | | ---- > -------- > | REG | > -------- > There is a clear use case for this for WSON as REG's are integral part=20 > of a WSON lightpath which can cause an incompatibility/blocking issue=20 > of the path. Drop/Add ports here in REG element may have wavelength=20 > restriction and that is why this is an additional constraint to look=20 > at. >=20 > Advertising tributary ports in general context is a different matter=20 > to me. Not sure if there is a clear use case that can be justified to=20 > support advertising tributary ports in general context. Even if there=20 > is, I don't think that is part of the scope of the generic encoding. >=20 >=20 > Regards, > Young >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf=20 > Of Lou Berger > Sent: Thursday, April 04, 2013 5:06 PM > To: Leeyoung > Cc: CCAMP; draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org > Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19 >=20 > Young, > Please see below. >=20 > On 3/27/2013 1:59 PM, Leeyoung wrote: >> Hi Lou, >> >> Please see my comments in-line.=20 >> >> Thanks. >> Young >> >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Tuesday, March 19, 2013 11:44 AM >> To: Leeyoung >> Cc: CCAMP; Margaria, Cyril (NSN - DE/Munich);=20 >> draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org >> Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19 >> >> >> Young, >> See below. >> On 3/18/2013 1:02 PM, Leeyoung wrote: >>> Hi Lou, >>> >>> The encoding is a part of the Resource Block >> >> Understood, but my comment was more on the definition of=20 >> / encoding. >> >>> (that includes Regenerators and Wavelength converters) which is a WSON = specific entity. >> >> So I agree that the need for transit nodes to have detailed encoding=20 >> and adaptation information to support 3R and certain other types of=20 >> switching is (at least to my understanding) specific to WSON. >> >=20 > Y> YOUNG>> RFC 3471 and RFC 4328 discuss G-PID as part of Generalized > Y> Label Request parameters to indicate client/tributary layer of the=20 > Y> LSP at the source/sink. > Y> > Y> I was not clear on what you meant "trib side resources." If you=20 > Y> meant "trib side resources" are LSP encoding type, Switching Type=20 > Y> and G-PID (which are covered by RFC 3471/4328), I believe RFC=20 > Y> 3471/4328 are sufficient; if not could you elaborate? >=20 > trib side =3D add/drop port at ingress/egress >=20 > resources =3D attributes related to data that port can transport >=20 >> >> But unless I misunderstand the WSON info draft, this same information=20 >> can be advertised in support of the trib side resources (i.e., at the=20 >> source/destination for add/drop) and this is a generic requirement=20 >> shared with other technologies. >> >=20 > y> YOUNG>> Here you seemed to allude the need for advertizing the > y> Source/Destination tributary resource information using IGP. In=20 > y> general, OSPF does not advertise the trib-side information, does it? > y> I believe signaling check on the tributary resource info on LSP=20 > y> level is good enough per RFC 3471/4328. Please correct me if my=20 > y> understanding is wrong. >=20 >=20 > I agree that that is how it is normally done, but WSON seems to be changi= ng this in two respects: > 1) By advertising G-PID at all, > 2) By advertising add/drop ports, where prior GMPLS approaches have only = advertised the network facing interfaces. >=20 > Did I misunderstand the intent of mentioning drop ports in several places= in Section 6 of the info document? >=20 >> >> So this lead me to ask about changing the G-PID list encoding to be=20 >> defined in the generic drafts (to facilitate PID advertisement for=20 >> non-WSON technologies.) Perhaps just having a generic encoding for a=20 >> G-PID list won't be of much value, but I suspect that we'll end up=20 >> needing it for other technologies too. >> >=20 > Y> YOUNG>> This point is carried from the above discussion. G-PID has > Y> been specified to cover all GMPLS related technologies. >=20 > Agreed that this is a derivative point and can wait until the above is cl= arified. >=20 >> -- For what it's worth I am having some trouble understanding how=20 >> G-PID is advertised for add/drop. As far as I can tell, you have a=20 >> per add/drop port, mapped to , to a=20 >> and infer output G-PID from the . >> At least that's how I'm reading the info draft. >=20 > Y> YOUNG>> Actually G-PID is advertised as part of the Node > Y> information: ::=3D [.= ..] > Y> [] >=20 > Got that. That's what I was referring to when I said " mapped to " >> >> Look at the diagram below from info draft: >> >> I1 +-------------+ +-------------+ E1 >> ----->| | +--------+ | |-----> >> I2 | +------+ Rb #1 +-------+ | E2 >> ----->| | +--------+ | |-----> >> | | | | >> | Resource | +--------+ | Resource | >> | Pool +------+ +-------+ Pool | >> | | + Rb #2 + | | >> | Input +------+ +-------| Output | >> | Connection | +--------+ | Connection | >> | Matrix | . | Matrix | >> | | . | | >> | | . | | >> IN | | +--------+ | | EM >> ----->| +------+ Rb #P +-------+ |-----> >> | | +--------+ | | >> +-------------+ ^ ^ +-------------+ >> | | >> | | >> | | >> | | >> >> Input wavelength Output wavelength >> constraints for constraints for >> each resource each resource >> >> Figure 1 Schematic diagram of resource pool model. >> >> Add/Drop ports to/from Resource Pool (i.e., I1,...IN and E1,..EN) is=20 >> part of link information and advertised as link-TLV; however Resource=20 >> Blocks and its internal connectivity is not modeled as node property=20 >> as they are internal to Resource Pool. >> >> ::=3D ... >> [...] [...] >> [] >> >> We modeled how RB's are accessible via matrices (input/ouput), if=20 >> there are wavelength limitations and if RB's are available. All of=20 >> these are modeled as the node property. >> >> And within RBinfo, we included Input/Output Constraints where ClientSign= alList (GPID) is specified.=20 >> >> ::=3D ([] >> [] )* >> >> Where=20 >> ::=3D [] >> [] >> >> >> >> I was delaying asking if a couple of related questions until the=20 >> above was resolved, but perhaps it makes sense to ask them now: >> - Shouldn't also be allowed under = ? >> >> YOUNG>> It is implied. is checked in and has obviously the same property. We can add this = comment to clarify.=20 >> >=20 > So there is/will never (be) a case where the differ f= rom the ? As you say, this certainly should be made expli= cit. >=20 >> - Doesn't it make sense to simplify the add/drop G-PID identification=20 >> by adding somewhere under (generic) ? >> > y> YOUNG>> I think you meant doing this at the source/destination. > sure, but aren't add/drop always at source/destination? (I guess you=20 > can come up with a case where they aren't, but this isn't the norm...) >=20 > Y> Again > y> I am not sure if we really need to advertise tributary client=20 > y> signal as link TLV. We have signaling mechanism to verify this. >=20 > As you say, this point is covered above. >=20 >> Thanks, >> Lou >> >>> >>> Regards, >>> Young >>> >>> -----Original Message----- >>> From: Lou Berger [mailto:lberger@labn.net] >>> Sent: Monday, March 18, 2013 8:07 AM >>> To: Leeyoung; CCAMP >>> Cc: Margaria, Cyril (NSN - DE/Munich);=20 >>> draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org >>> Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19 >>> >>> Young/All, >>> >>> Some of the discussions last week (on 709 and dimitri's) got me=20 >>> thinking more about the inclusion of G-PID on the wson specific=20 >>> encoding. As G-PID and other client/input information is not=20 >>> technology specific, and it looks like there's a likely a need for a=20 >>> general solution, shouldn't the G-PID (and other 'client/input')=20 >>> information be in draft-ietf-ccamp-general-constraint-encode? >>> >>> Thoughts? >>> >>> Lou >>> >>> On 3/15/2013 5:35 AM, Leeyoung wrote: >>>> Thanks.=20 >>>> >>>> Young >>>> >>>> -----Original Message----- >>>> From: Margaria, Cyril (NSN - DE/Munich)=20 >>>> [mailto:cyril.margaria@nsn.com] >>>> Sent: Thursday, March 14, 2013 5:53 PM >>>> To: Leeyoung; CCAMP;=20 >>>> draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org >>>> Subject: RE: Comments on draft-ietf-ccamp-rwa-wson-encode-19 >>>> >>>> >>>> Hi, >>>> >>>> Thanks for the quick feedback. As this introduce a dependency with=20 >>>> the GPID, the text should indicate that the number of bit rate MUST ma= tch the number of GPID. >>>> >>>> Other than that I think this is acceptable >>>> >>>> >>>> >>>> Best regards / Mit freundlichen Gr=FC=DFen Cyril Margaria >>>> >>>> >>>>> -----Original Message----- >>>>> From: ext Leeyoung [mailto:leeyoung@huawei.com] >>>>> Sent: Wednesday, March 13, 2013 9:33 PM >>>>> To: Margaria, Cyril (NSN - DE/Munich); CCAMP;=20 >>>>> draft-ietf-ccamp-rwa- wson-encode@tools.ietf.org >>>>> Subject: RE: Comments on draft-ietf-ccamp-rwa-wson-encode-19 >>>>> >>>>> Hi Cyril, >>>>> >>>>> Thanks for your comment. >>>>> >>>>> This refers to the "Input Bit Rate" of the associated client=20 >>>>> Signal Type in the RB. >>>>> Below is a new section 5.4 that defines Input Bit Rate List=20 >>>>> Sub-Sub- TLV. We removed "range" from this Sub-Sub-TLV. >>>>> >>>>> Let me know if this is acceptable. >>>>> >>>>> Thanks. >>>>> Young >>>>> >>>>> ------------------------------------------------------------------ >>>>> --- >>>>> >>>>> 5.4. Input Bit Rate List Sub-Sub-TLV >>>>> >>>>> This sub-sub-TLV contains a list of bit rate of each input client=20 >>>>> signal types specified in the Input Client Signal List Sub-Sub-TLV. >>>>> Type :=3D Input Bit Rate List >>>>> Value :=3D IEEE 32-bit IEEE Floating Point >>>>> >>>>> 0 1 2 3 >>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | Input Bit Rate of GPID #1 | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> : : >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | Input Bit Rate of GPID #N | >>>>> =20 >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On=20 >>>>> Behalf Of Margaria, Cyril (NSN - DE/Munich) >>>>> Sent: Wednesday, March 13, 2013 8:54 AM >>>>> To: CCAMP; draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org >>>>> Subject: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19 >>>>> >>>>> Dear Authors, >>>>> >>>>> I have the following comments on=20 >>>>> draft-ietf-ccamp-rwa-wson-encode-19 >>>>> >>>>> Section 5.1 Resource Block Information Sub-TLV >>>>> >>>>> The sub-TLV format defines the "Input Bit Rate Range List =20 >>>>> Sub-Sub-TLV (opt)" >>>>> No section defines the Input Bit range List Sub-Sub-TLV, while it=20 >>>>> was present in the previous version. >>>>> >>>>> I think the section should be re-added. >>>>> >>>>> >>>>> Mit freundlichen Gr=FC=DFen / Best Regards Cyril Margaria >>>>> >>>>> Nokia Siemens Networks Optical GmbH St.Martin-Str. 76 >>>>> D-81541 M=FCnchen >>>>> Germany >>>>> mailto:cyril.margaria@nsn.com >>>>> Phone: +49-89-5159-16934 >>>>> Fax: +49-89-5159-44-16934 >>>>> ---------------------------------------------------------------- >>>>> Nokia Siemens Networks Optical GmbH Gesch=E4ftsleitung / Board of=20 >>>>> Directors: Gero Neumeier, Dr. Rolf Nauerz Sitz der Gesellschaft:=20 >>>>> M=FCnchen / Registered office: Munich >>>>> Registergericht: M=FCnchen / Commercial registry: Munich, HRB 197143 >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>> _______________________________________________ >>>> CCAMP mailing list >>>> CCAMP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ccamp >>>> >>>> >>>> >>>> >>> >>> >>> >>> >> >> >> >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp >=20 >=20 >=20 >=20 From lberger@labn.net Wed May 8 08:23:16 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5312521F930C for ; Wed, 8 May 2013 08:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.428 X-Spam-Level: X-Spam-Status: No, score=-101.428 tagged_above=-999 required=5 tests=[AWL=0.837, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJ710AGpsmlY for ; Wed, 8 May 2013 08:23:11 -0700 (PDT) Received: from oproxy13-pub.unifiedlayer.com (oproxy13-pub.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id 99CE221F9026 for ; Wed, 8 May 2013 08:23:11 -0700 (PDT) Received: (qmail 26377 invoked by uid 0); 8 May 2013 15:22:49 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy13.unifiedlayer.com with SMTP; 8 May 2013 15:22:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=P2GGhAu8/E/tSajFBnBlEtE0RBVdCTeJdRdgl/E8AJw=; b=j71lOjEV0jl/N7tQibT17k3m/Ab4F81TPvKyvcDlS5Xpos730Fk4vALxPDaxQPMSlFh/G7S9uMjDly8ErnjoMTD9Xpvh8PPgsUR8nnliDlYVyk/7XkjzOVPHN32CVsO8; Received: from box313.bluehost.com ([69.89.31.113]:43342 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Ua6Cf-0000eL-AE; Wed, 08 May 2013 09:22:49 -0600 Message-ID: <518A6DC7.9060705@labn.net> Date: Wed, 08 May 2013 11:22:47 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Leeyoung References: <8DC6547C806B644F998A0566E79E15920F7DFF60@DEMUMBX006.nsn-intra.net> <7AEB3D6833318045B4AE71C2C87E8E172911828D@dfweml511-mbs.china.huawei.com> <8DC6547C806B644F998A0566E79E15920F7E1284@DEMUMBX006.nsn-intra.net> <7AEB3D6833318045B4AE71C2C87E8E172911D7BA@dfweml511-mbs.china.huawei.com> <51471168.3000400@labn.net> <7AEB3D6833318045B4AE71C2C87E8E172911DC5E@dfweml511-mbs.china.huawei.com> <514895C5.7080300@labn.net> <7AEB3D6833318045B4AE71C2C87E8E1729121785@dfweml511-mbs.china.huawei.com> <515DF956.1020305@labn.net> <7AEB3D6833318045B4AE71C2C87E8E172913671A@dfweml511-mbs.china.huawei.com> <518906F8.50507@labn.net> <7AEB3D6833318045B4AE71C2C87E8E172913A254@dfweml511-mbs.china.huawei.com> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E172913A254@dfweml511-mbs.china.huawei.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP , "draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org" Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 15:23:16 -0000 Young, see below. On 5/7/2013 3:06 PM, Leeyoung wrote: > Hi Lou, > > Yes, the scope of drop ports mentioned in Section 6 of the info > document is aimed at just Regen ports. I will make this point clear > in the revision of the info draft. Great. > As we modeled Regen signal compatibility that includes Regen drop > port limitation, G-PID compatibility identification for Regen (in and > out) is included as part of the "package" per se to advertise all > Regen related constraints using IGP. > > Egress G-PID compatibility check has been built as part of GMPLS > Signaling, which I believe serves the purpose well. > As you know: There's lots of information that shows up in both signaling and routing, where the former provides the requirements of a specific LSP and the latter provides the capabilities/availabilities within the network. Having information in routing doesn't obviate the need for the same information in signaling, and information contained in signaling need not be represented in routing. And, to oversimplify, the more information that's available in routing the more likely that a path computed for a LSP will be established without the use of error/crankback processing, but also more likely the IGP/system will run into scaling issues. So GMPLS' current representation of G-PID in signaling, but not routing, reflects a judgement call at the time GMPLS routing was defined. (and to rely on error/crankback processing when there are g-pid mismatches.) While not an author of RFC4202, I believe part of this tradeoff calculus was the assumption that there is a high probability of there being a switch function at the egress that allows the termination of an LSP coming in (from the network) on any interface for any G-PID (and any other termination/egress constraint) supported on the node. Given that WSON clearly widens the scope to include nodes where this assumption no longer holds, it seemed reasonable (at least to me) for the WSON documents to revisit this decision. > If you want Egress (tributary side) G-PID compatibility check using > IGP, this is a whole different matter. It's not a matter of what I want, it's a matter of what the WSON documents currently state & allow. As I mentioned earlier in this thread, the current text seems to support and even envision advertisement of trib/egress resources, including G-PID. From my perspective, advertisement of egress resources should be generic and this was the main point of my comments. Modifying the WSON documents make it clear that egress/trib resources aren't being advertised resolves this comment. (please don't forget to add the other comments discussed in this thread.) It does raise the question of why the current solution (i.e., crankback) is fine for the egress case, but not for the regen case. As I thought you were covering both case, I haven't thought much on this. Can you explain why you made this tradeoff (G-PID advertisement for regen, but not egress)? > First, I think we need a clear > use-case and requirement why we want to do this in light of the > signaling mechanism that does the check. Let me know if this is not > the case from your perspective. Are there some reasons you believe > GMPLS Signaling mechanism would not work to check the tributary > egress G-PID check? > As discussed above having information in routing doesn't obviate the need for the same information & check to be present in signaling, it just changes the probability of success/crankback. Lou > Regards, > Young > > > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Tuesday, May 07, 2013 8:52 AM > To: Leeyoung > Cc: CCAMP; draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org > Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19 > > [oops, found this in my outbox -- sorry about the delay] > > Young, > > I think this discussion primarily comes down to the intent of mentioning drop ports in several places in Section 6 of the info document. > > Is the scope of this text aimed at just regen ports or any drop (regen > &trib) ports? The text isn't scoped so, as I mentioned/asked in my mail on 4/4, I understood it to refer to the advertisement of information for any drop port. so: >> Did I misunderstand the intent of mentioning drop ports in several >> places in Section 6 of the info document? > > If the intended scope is just regen, this needs to be made clear in the documents. Furthermore, as the same (G-PID compatibility > identification) issue exists with the egress, why wouldn't the same solution be used for both? > > Much thanks, > Lou > > On 4/24/2013 12:17 PM, Leeyoung wrote: >> Hi Lou, >> >> I think the main point is if we need to advertise add/drop >> (tributary) ports in generic context? You said in the previous >> email: >> >> "I agree that that is how it is normally done, but WSON seems to be changing this in two respects: >> 1) By advertising G-PID at all, >> 2) By advertising add/drop ports, where prior GMPLS approaches have only advertised the network facing interfaces." >> >> These elements above are part of regeneration elements that constitute >> a WSON lightpath which begins the line side of ingress and ends the >> line side of egress. See the diagram below: >> >> ---- ---- >> | |<------------ -------------->| | >> ---- | | ---- >> -------- >> | REG | >> -------- >> There is a clear use case for this for WSON as REG's are integral part >> of a WSON lightpath which can cause an incompatibility/blocking issue >> of the path. Drop/Add ports here in REG element may have wavelength >> restriction and that is why this is an additional constraint to look >> at. >> >> Advertising tributary ports in general context is a different matter >> to me. Not sure if there is a clear use case that can be justified to >> support advertising tributary ports in general context. Even if there >> is, I don't think that is part of the scope of the generic encoding. >> >> >> Regards, >> Young >> >> >> >> >> >> >> >> >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf >> Of Lou Berger >> Sent: Thursday, April 04, 2013 5:06 PM >> To: Leeyoung >> Cc: CCAMP; draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org >> Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19 >> >> Young, >> Please see below. >> >> On 3/27/2013 1:59 PM, Leeyoung wrote: >>> Hi Lou, >>> >>> Please see my comments in-line. >>> >>> Thanks. >>> Young >>> >>> -----Original Message----- >>> From: Lou Berger [mailto:lberger@labn.net] >>> Sent: Tuesday, March 19, 2013 11:44 AM >>> To: Leeyoung >>> Cc: CCAMP; Margaria, Cyril (NSN - DE/Munich); >>> draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org >>> Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19 >>> >>> >>> Young, >>> See below. >>> On 3/18/2013 1:02 PM, Leeyoung wrote: >>>> Hi Lou, >>>> >>>> The encoding is a part of the Resource Block >>> >>> Understood, but my comment was more on the definition of >>> / encoding. >>> >>>> (that includes Regenerators and Wavelength converters) which is a WSON specific entity. >>> >>> So I agree that the need for transit nodes to have detailed encoding >>> and adaptation information to support 3R and certain other types of >>> switching is (at least to my understanding) specific to WSON. >>> >> >> Y> YOUNG>> RFC 3471 and RFC 4328 discuss G-PID as part of Generalized >> Y> Label Request parameters to indicate client/tributary layer of the >> Y> LSP at the source/sink. >> Y> >> Y> I was not clear on what you meant "trib side resources." If you >> Y> meant "trib side resources" are LSP encoding type, Switching Type >> Y> and G-PID (which are covered by RFC 3471/4328), I believe RFC >> Y> 3471/4328 are sufficient; if not could you elaborate? >> >> trib side = add/drop port at ingress/egress >> >> resources = attributes related to data that port can transport >> >>> >>> But unless I misunderstand the WSON info draft, this same information >>> can be advertised in support of the trib side resources (i.e., at the >>> source/destination for add/drop) and this is a generic requirement >>> shared with other technologies. >>> >> >> y> YOUNG>> Here you seemed to allude the need for advertizing the >> y> Source/Destination tributary resource information using IGP. In >> y> general, OSPF does not advertise the trib-side information, does it? >> y> I believe signaling check on the tributary resource info on LSP >> y> level is good enough per RFC 3471/4328. Please correct me if my >> y> understanding is wrong. >> >> >> I agree that that is how it is normally done, but WSON seems to be changing this in two respects: >> 1) By advertising G-PID at all, >> 2) By advertising add/drop ports, where prior GMPLS approaches have only advertised the network facing interfaces. >> >> Did I misunderstand the intent of mentioning drop ports in several places in Section 6 of the info document? >> >>> >>> So this lead me to ask about changing the G-PID list encoding to be >>> defined in the generic drafts (to facilitate PID advertisement for >>> non-WSON technologies.) Perhaps just having a generic encoding for a >>> G-PID list won't be of much value, but I suspect that we'll end up >>> needing it for other technologies too. >>> >> >> Y> YOUNG>> This point is carried from the above discussion. G-PID has >> Y> been specified to cover all GMPLS related technologies. >> >> Agreed that this is a derivative point and can wait until the above is clarified. >> >>> -- For what it's worth I am having some trouble understanding how >>> G-PID is advertised for add/drop. As far as I can tell, you have a >>> per add/drop port, mapped to , to a >>> and infer output G-PID from the . >>> At least that's how I'm reading the info draft. >> >> Y> YOUNG>> Actually G-PID is advertised as part of the Node >> Y> information: ::= [...] >> Y> [] >> >> Got that. That's what I was referring to when I said " mapped to " >>> >>> Look at the diagram below from info draft: >>> >>> I1 +-------------+ +-------------+ E1 >>> ----->| | +--------+ | |-----> >>> I2 | +------+ Rb #1 +-------+ | E2 >>> ----->| | +--------+ | |-----> >>> | | | | >>> | Resource | +--------+ | Resource | >>> | Pool +------+ +-------+ Pool | >>> | | + Rb #2 + | | >>> | Input +------+ +-------| Output | >>> | Connection | +--------+ | Connection | >>> | Matrix | . | Matrix | >>> | | . | | >>> | | . | | >>> IN | | +--------+ | | EM >>> ----->| +------+ Rb #P +-------+ |-----> >>> | | +--------+ | | >>> +-------------+ ^ ^ +-------------+ >>> | | >>> | | >>> | | >>> | | >>> >>> Input wavelength Output wavelength >>> constraints for constraints for >>> each resource each resource >>> >>> Figure 1 Schematic diagram of resource pool model. >>> >>> Add/Drop ports to/from Resource Pool (i.e., I1,...IN and E1,..EN) is >>> part of link information and advertised as link-TLV; however Resource >>> Blocks and its internal connectivity is not modeled as node property >>> as they are internal to Resource Pool. >>> >>> ::= ... >>> [...] [...] >>> [] >>> >>> We modeled how RB's are accessible via matrices (input/ouput), if >>> there are wavelength limitations and if RB's are available. All of >>> these are modeled as the node property. >>> >>> And within RBinfo, we included Input/Output Constraints where ClientSignalList (GPID) is specified. >>> >>> ::= ([] >>> [] )* >>> >>> Where >>> ::= [] >>> [] >>> >>> >>> >>> I was delaying asking if a couple of related questions until the >>> above was resolved, but perhaps it makes sense to ask them now: >>> - Shouldn't also be allowed under ? >>> >>> YOUNG>> It is implied. is checked in and has obviously the same property. We can add this comment to clarify. >>> >> >> So there is/will never (be) a case where the differ from the ? As you say, this certainly should be made explicit. >> >>> - Doesn't it make sense to simplify the add/drop G-PID identification >>> by adding somewhere under (generic) ? >>> >> y> YOUNG>> I think you meant doing this at the source/destination. >> sure, but aren't add/drop always at source/destination? (I guess you >> can come up with a case where they aren't, but this isn't the norm...) >> >> Y> Again >> y> I am not sure if we really need to advertise tributary client >> y> signal as link TLV. We have signaling mechanism to verify this. >> >> As you say, this point is covered above. >> >>> Thanks, >>> Lou >>> >>>> >>>> Regards, >>>> Young >>>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: Monday, March 18, 2013 8:07 AM >>>> To: Leeyoung; CCAMP >>>> Cc: Margaria, Cyril (NSN - DE/Munich); >>>> draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org >>>> Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19 >>>> >>>> Young/All, >>>> >>>> Some of the discussions last week (on 709 and dimitri's) got me >>>> thinking more about the inclusion of G-PID on the wson specific >>>> encoding. As G-PID and other client/input information is not >>>> technology specific, and it looks like there's a likely a need for a >>>> general solution, shouldn't the G-PID (and other 'client/input') >>>> information be in draft-ietf-ccamp-general-constraint-encode? >>>> >>>> Thoughts? >>>> >>>> Lou >>>> >>>> On 3/15/2013 5:35 AM, Leeyoung wrote: >>>>> Thanks. >>>>> >>>>> Young >>>>> >>>>> -----Original Message----- >>>>> From: Margaria, Cyril (NSN - DE/Munich) >>>>> [mailto:cyril.margaria@nsn.com] >>>>> Sent: Thursday, March 14, 2013 5:53 PM >>>>> To: Leeyoung; CCAMP; >>>>> draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org >>>>> Subject: RE: Comments on draft-ietf-ccamp-rwa-wson-encode-19 >>>>> >>>>> >>>>> Hi, >>>>> >>>>> Thanks for the quick feedback. As this introduce a dependency with >>>>> the GPID, the text should indicate that the number of bit rate MUST match the number of GPID. >>>>> >>>>> Other than that I think this is acceptable >>>>> >>>>> >>>>> >>>>> Best regards / Mit freundlichen Grüßen Cyril Margaria >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: ext Leeyoung [mailto:leeyoung@huawei.com] >>>>>> Sent: Wednesday, March 13, 2013 9:33 PM >>>>>> To: Margaria, Cyril (NSN - DE/Munich); CCAMP; >>>>>> draft-ietf-ccamp-rwa- wson-encode@tools.ietf.org >>>>>> Subject: RE: Comments on draft-ietf-ccamp-rwa-wson-encode-19 >>>>>> >>>>>> Hi Cyril, >>>>>> >>>>>> Thanks for your comment. >>>>>> >>>>>> This refers to the "Input Bit Rate" of the associated client >>>>>> Signal Type in the RB. >>>>>> Below is a new section 5.4 that defines Input Bit Rate List >>>>>> Sub-Sub- TLV. We removed "range" from this Sub-Sub-TLV. >>>>>> >>>>>> Let me know if this is acceptable. >>>>>> >>>>>> Thanks. >>>>>> Young >>>>>> >>>>>> ------------------------------------------------------------------ >>>>>> --- >>>>>> >>>>>> 5.4. Input Bit Rate List Sub-Sub-TLV >>>>>> >>>>>> This sub-sub-TLV contains a list of bit rate of each input client >>>>>> signal types specified in the Input Client Signal List Sub-Sub-TLV. >>>>>> Type := Input Bit Rate List >>>>>> Value := IEEE 32-bit IEEE Floating Point >>>>>> >>>>>> 0 1 2 3 >>>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> | Input Bit Rate of GPID #1 | >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> : : >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> | Input Bit Rate of GPID #N | >>>>>> >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>>>>> Behalf Of Margaria, Cyril (NSN - DE/Munich) >>>>>> Sent: Wednesday, March 13, 2013 8:54 AM >>>>>> To: CCAMP; draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org >>>>>> Subject: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19 >>>>>> >>>>>> Dear Authors, >>>>>> >>>>>> I have the following comments on >>>>>> draft-ietf-ccamp-rwa-wson-encode-19 >>>>>> >>>>>> Section 5.1 Resource Block Information Sub-TLV >>>>>> >>>>>> The sub-TLV format defines the "Input Bit Rate Range List >>>>>> Sub-Sub-TLV (opt)" >>>>>> No section defines the Input Bit range List Sub-Sub-TLV, while it >>>>>> was present in the previous version. >>>>>> >>>>>> I think the section should be re-added. >>>>>> >>>>>> >>>>>> Mit freundlichen Grüßen / Best Regards Cyril Margaria >>>>>> >>>>>> Nokia Siemens Networks Optical GmbH St.Martin-Str. 76 >>>>>> D-81541 München >>>>>> Germany >>>>>> mailto:cyril.margaria@nsn.com >>>>>> Phone: +49-89-5159-16934 >>>>>> Fax: +49-89-5159-44-16934 >>>>>> ---------------------------------------------------------------- >>>>>> Nokia Siemens Networks Optical GmbH Geschäftsleitung / Board of >>>>>> Directors: Gero Neumeier, Dr. Rolf Nauerz Sitz der Gesellschaft: >>>>>> München / Registered office: Munich >>>>>> Registergericht: München / Commercial registry: Munich, HRB 197143 >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> CCAMP mailing list >>>>>> CCAMP@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> > > > > From lberger@labn.net Wed May 8 09:52:55 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0642B21F9512 for ; Wed, 8 May 2013 09:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.707 X-Spam-Level: X-Spam-Status: No, score=-101.707 tagged_above=-999 required=5 tests=[AWL=0.558, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vGuXKAd8NaSN for ; Wed, 8 May 2013 09:52:49 -0700 (PDT) Received: from oproxy14-pub.unifiedlayer.com (oproxy14-pub.unifiedlayer.com [67.222.51.224]) by ietfa.amsl.com (Postfix) with SMTP id A73A921F94A4 for ; Wed, 8 May 2013 09:52:48 -0700 (PDT) Received: (qmail 15382 invoked by uid 0); 8 May 2013 16:52:43 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy14.unifiedlayer.com with SMTP; 8 May 2013 16:52:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=F+F+ChP2l6Xoj6duBcgqEGY9cB3hzMGIkYMAw7cLFWY=; b=sXOKGQ8IFdVGD8cudn/o9Pe+knVCOdCB5sYhCJh77jfM9V8S78+e2UMn/UBjovKnmzsr2SqYRmtpxRMlvvi6WbNCLpHEKV7tBt3o/wjhVm9ocbxAT0IlylTZH+7IBNXA; Received: from box313.bluehost.com ([69.89.31.113]:57036 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Ua7bf-00028a-7s; Wed, 08 May 2013 10:52:43 -0600 Message-ID: <518A82D9.7080508@labn.net> Date: Wed, 08 May 2013 12:52:41 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" , "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: [CCAMP] Closing G.709 open issues X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 16:52:55 -0000 Authors/WG, I think all would like to wrap up the 709 documents before Berlin. To do this we need to: 1) Ensure all discussed points have been resolved 2) Hold a 2nd LC to ensure consensus on all changes since the 1st LC 3) Capture the resolution of any comments made during 2. In reviewing the close to 200 mail messages on the documents since the 1st LC was issued, I see only one a few points that are still missing, and I'll cover these below. On a side note, as an experiment we'll be tracking these issue via the tools issues page: http://tools.ietf.org/wg/ccamp/trac/report/1 PLEASE reply to this message if you think there are other points/discussions that haven't been addressed in the current set of documents. Once this thread is closed, the 2nd LC will be initiated. The remaining items come from the tread with the final message http://www.ietf.org/mail-archive/web/ccamp/current/msg14701.html The message is from me in response to Daniele's summary of next steps, and has the following unresolved actions: 1) No explicit indication of TSG in the label [SIGNALING] In signaling document section 6: Clarify related text to unambiguous identify the relationship between label length and TSG. Possible target text to change: Note that the Length field in the label format MAY be used to indicate the TS type of the HO ODUk (i.e., TS granularity at 1.25Gbps or 2.5Gbps) since the HO ODUk type can be known from IF_ID RSVP_HOP Object. In some cases when there is no Link Management Protocol (LMP) or routing to make the two end points of the link to know the TSG, the TSG information used by another end can be deduced from the label format. For example, for HO ODU2 link, the value of the length filed will be 4 or 8, which indicates the TS granularity is 2.5Gbps or 1.25Gbps, respectively. 2) Verify that the complete list of G-PIDs are defined [SIGNALING] In signaling document section 4, verify that all payload types defined in G.709 (Summarized in Table 15-8) can be represented. This issue can be resolved via an update or message to the list stating that the verification took place. 3) Identification of hexadecimal representation in G.709 vs decimal in GMPLS [INFO-MODEL] The authors had previously stated the intent to just make this clear in the signaling document. I'd like to make an alternate proposal: let's do the the obvious and have the documents simply use the normal (IETF) convention of using a '0x' prefix anytime a hexadecimal value is represented. I believe this means that only the info-model draft needs to be updated. I believe that's the complete list. Again: PLEASE reply to this message if you think there are other points/discussions that haven't been addressed in the current set of documents. Much thanks, Lou From leeyoung@huawei.com Wed May 8 10:36:43 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0EB421F8E63 for ; Wed, 8 May 2013 10:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.565 X-Spam-Level: X-Spam-Status: No, score=-6.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOK+7q1ox0NH for ; Wed, 8 May 2013 10:36:38 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EF9F321F8E66 for ; Wed, 8 May 2013 10:36:37 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASO39420; Wed, 08 May 2013 17:36:34 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 8 May 2013 18:36:25 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 9 May 2013 01:36:31 +0800 Received: from dfweml511-mbs.china.huawei.com ([169.254.15.13]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.007; Wed, 8 May 2013 10:36:28 -0700 From: Leeyoung To: Lou Berger Thread-Topic: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19 Thread-Index: AQHOMYCjjSbgAyDhM0mIOPaGuA1CEpjloTRAgBTFMQD//9tXAIAB0GWA//+psSs= Date: Wed, 8 May 2013 17:36:28 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172913C520@dfweml511-mbs.china.huawei.com> References: <8DC6547C806B644F998A0566E79E15920F7DFF60@DEMUMBX006.nsn-intra.net> <7AEB3D6833318045B4AE71C2C87E8E172911828D@dfweml511-mbs.china.huawei.com> <8DC6547C806B644F998A0566E79E15920F7E1284@DEMUMBX006.nsn-intra.net> <7AEB3D6833318045B4AE71C2C87E8E172911D7BA@dfweml511-mbs.china.huawei.com> <51471168.3000400@labn.net> <7AEB3D6833318045B4AE71C2C87E8E172911DC5E@dfweml511-mbs.china.huawei.com> <514895C5.7080300@labn.net> <7AEB3D6833318045B4AE71C2C87E8E1729121785@dfweml511-mbs.china.huawei.com> <515DF956.1020305@labn.net> <7AEB3D6833318045B4AE71C2C87E8E172913671A@dfweml511-mbs.china.huawei.com> <518906F8.50507@labn.net> <7AEB3D6833318045B4AE71C2C87E8E172913A254@dfweml511-mbs.china.huawei.com>, <518A6DC7.9060705@labn.net> In-Reply-To: <518A6DC7.9060705@labn.net> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.231] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: CCAMP , "draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org" Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 17:36:43 -0000 Hi Lou, The main issue you raised: "It does raise the question of why the current solution (i.e., crankback) i= s fine for the egress case, but not for the regen case. As I thought you w= ere covering both case, I haven't thought much on this. Can you explain wh= y you made this tradeoff (G-PID advertisement for regen, but not egress)?" Here's my answer: As a WSON optical LSP may involve a set of REGEN's along the LSP, I view th= at IGP dissemination of REGEN related contraints including G-PID would be a= sensible thing as we may have several potential "incompatibility" points. = In such case, depending only on the signaling mechanism would potentially r= esult in a number of crankbacks as there are more permutations in matching = G-PID over multiple REGEN points.=20 Without REGEN elements along the LSP, G-PID check is done at the egress whi= ch is a single point. In such environment, GMPLS signaling mechanism has a = higher likelihood of success in finding the match/compatibility.=20 Thanks. Young ________________________________________ From: Lou Berger [lberger@labn.net] Sent: Wednesday, May 08, 2013 10:22 AM To: Leeyoung Cc: CCAMP; draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19 Young, see below. On 5/7/2013 3:06 PM, Leeyoung wrote: > Hi Lou, > > Yes, the scope of drop ports mentioned in Section 6 of the info > document is aimed at just Regen ports. I will make this point clear > in the revision of the info draft. Great. > As we modeled Regen signal compatibility that includes Regen drop > port limitation, G-PID compatibility identification for Regen (in and > out) is included as part of the "package" per se to advertise all > Regen related constraints using IGP. > > Egress G-PID compatibility check has been built as part of GMPLS > Signaling, which I believe serves the purpose well. > As you know: There's lots of information that shows up in both signaling and routing, where the former provides the requirements of a specific LSP and the latter provides the capabilities/availabilities within the network. Having information in routing doesn't obviate the need for the same information in signaling, and information contained in signaling need not be represented in routing. And, to oversimplify, the more information that's available in routing the more likely that a path computed for a LSP will be established without the use of error/crankback processing, but also more likely the IGP/system will run into scaling issues. So GMPLS' current representation of G-PID in signaling, but not routing, reflects a judgement call at the time GMPLS routing was defined. (and to rely on error/crankback processing when there are g-pid mismatches.) While not an author of RFC4202, I believe part of this tradeoff calculus was the assumption that there is a high probability of there being a switch function at the egress that allows the termination of an LSP coming in (from the network) on any interface for any G-PID (and any other termination/egress constraint) supported on the node. Given that WSON clearly widens the scope to include nodes where this assumption no longer holds, it seemed reasonable (at least to me) for the WSON documents to revisit this decision. > If you want Egress (tributary side) G-PID compatibility check using > IGP, this is a whole different matter. It's not a matter of what I want, it's a matter of what the WSON documents currently state & allow. As I mentioned earlier in this thread, the current text seems to support and even envision advertisement of trib/egress resources, including G-PID. From my perspective, advertisement of egress resources should be generic and this was the main point of my comments. Modifying the WSON documents make it clear that egress/trib resources aren't being advertised resolves this comment. (please don't forget to add the other comments discussed in this thread.) It does raise the question of why the current solution (i.e., crankback) is fine for the egress case, but not for the regen case. As I thought you were covering both case, I haven't thought much on this. Can you explain why you made this tradeoff (G-PID advertisement for regen, but not egress)? > First, I think we need a clear > use-case and requirement why we want to do this in light of the > signaling mechanism that does the check. Let me know if this is not > the case from your perspective. Are there some reasons you believe > GMPLS Signaling mechanism would not work to check the tributary > egress G-PID check? > As discussed above having information in routing doesn't obviate the need for the same information & check to be present in signaling, it just changes the probability of success/crankback. Lou > Regards, > Young > > > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Tuesday, May 07, 2013 8:52 AM > To: Leeyoung > Cc: CCAMP; draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org > Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19 > > [oops, found this in my outbox -- sorry about the delay] > > Young, > > I think this discussion primarily comes down to the intent of mentioning = drop ports in several places in Section 6 of the info document. > > Is the scope of this text aimed at just regen ports or any drop (regen > &trib) ports? The text isn't scoped so, as I mentioned/asked in my mail o= n 4/4, I understood it to refer to the advertisement of information for any= drop port. so: >> Did I misunderstand the intent of mentioning drop ports in several >> places in Section 6 of the info document? > > If the intended scope is just regen, this needs to be made clear in the d= ocuments. Furthermore, as the same (G-PID compatibility > identification) issue exists with the egress, why wouldn't the same solut= ion be used for both? > > Much thanks, > Lou > > On 4/24/2013 12:17 PM, Leeyoung wrote: >> Hi Lou, >> >> I think the main point is if we need to advertise add/drop >> (tributary) ports in generic context? You said in the previous >> email: >> >> "I agree that that is how it is normally done, but WSON seems to be chan= ging this in two respects: >> 1) By advertising G-PID at all, >> 2) By advertising add/drop ports, where prior GMPLS approaches have only= advertised the network facing interfaces." >> >> These elements above are part of regeneration elements that constitute >> a WSON lightpath which begins the line side of ingress and ends the >> line side of egress. See the diagram below: >> >> ---- ---- >> | |<------------ -------------->| | >> ---- | | ---- >> -------- >> | REG | >> -------- >> There is a clear use case for this for WSON as REG's are integral part >> of a WSON lightpath which can cause an incompatibility/blocking issue >> of the path. Drop/Add ports here in REG element may have wavelength >> restriction and that is why this is an additional constraint to look >> at. >> >> Advertising tributary ports in general context is a different matter >> to me. Not sure if there is a clear use case that can be justified to >> support advertising tributary ports in general context. Even if there >> is, I don't think that is part of the scope of the generic encoding. >> >> >> Regards, >> Young >> >> >> >> >> >> >> >> >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf >> Of Lou Berger >> Sent: Thursday, April 04, 2013 5:06 PM >> To: Leeyoung >> Cc: CCAMP; draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org >> Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19 >> >> Young, >> Please see below. >> >> On 3/27/2013 1:59 PM, Leeyoung wrote: >>> Hi Lou, >>> >>> Please see my comments in-line. >>> >>> Thanks. >>> Young >>> >>> -----Original Message----- >>> From: Lou Berger [mailto:lberger@labn.net] >>> Sent: Tuesday, March 19, 2013 11:44 AM >>> To: Leeyoung >>> Cc: CCAMP; Margaria, Cyril (NSN - DE/Munich); >>> draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org >>> Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19 >>> >>> >>> Young, >>> See below. >>> On 3/18/2013 1:02 PM, Leeyoung wrote: >>>> Hi Lou, >>>> >>>> The encoding is a part of the Resource Block >>> >>> Understood, but my comment was more on the definition of >>> / encoding. >>> >>>> (that includes Regenerators and Wavelength converters) which is a WSON= specific entity. >>> >>> So I agree that the need for transit nodes to have detailed encoding >>> and adaptation information to support 3R and certain other types of >>> switching is (at least to my understanding) specific to WSON. >>> >> >> Y> YOUNG>> RFC 3471 and RFC 4328 discuss G-PID as part of Generalized >> Y> Label Request parameters to indicate client/tributary layer of the >> Y> LSP at the source/sink. >> Y> >> Y> I was not clear on what you meant "trib side resources." If you >> Y> meant "trib side resources" are LSP encoding type, Switching Type >> Y> and G-PID (which are covered by RFC 3471/4328), I believe RFC >> Y> 3471/4328 are sufficient; if not could you elaborate? >> >> trib side =3D add/drop port at ingress/egress >> >> resources =3D attributes related to data that port can transport >> >>> >>> But unless I misunderstand the WSON info draft, this same information >>> can be advertised in support of the trib side resources (i.e., at the >>> source/destination for add/drop) and this is a generic requirement >>> shared with other technologies. >>> >> >> y> YOUNG>> Here you seemed to allude the need for advertizing the >> y> Source/Destination tributary resource information using IGP. In >> y> general, OSPF does not advertise the trib-side information, does it? >> y> I believe signaling check on the tributary resource info on LSP >> y> level is good enough per RFC 3471/4328. Please correct me if my >> y> understanding is wrong. >> >> >> I agree that that is how it is normally done, but WSON seems to be chang= ing this in two respects: >> 1) By advertising G-PID at all, >> 2) By advertising add/drop ports, where prior GMPLS approaches have only= advertised the network facing interfaces. >> >> Did I misunderstand the intent of mentioning drop ports in several place= s in Section 6 of the info document? >> >>> >>> So this lead me to ask about changing the G-PID list encoding to be >>> defined in the generic drafts (to facilitate PID advertisement for >>> non-WSON technologies.) Perhaps just having a generic encoding for a >>> G-PID list won't be of much value, but I suspect that we'll end up >>> needing it for other technologies too. >>> >> >> Y> YOUNG>> This point is carried from the above discussion. G-PID has >> Y> been specified to cover all GMPLS related technologies. >> >> Agreed that this is a derivative point and can wait until the above is c= larified. >> >>> -- For what it's worth I am having some trouble understanding how >>> G-PID is advertised for add/drop. As far as I can tell, you have a >>> per add/drop port, mapped to , to a >>> and infer output G-PID from the . >>> At least that's how I'm reading the info draft. >> >> Y> YOUNG>> Actually G-PID is advertised as part of the Node >> Y> information: ::=3D [= ...] >> Y> [] >> >> Got that. That's what I was referring to when I said " mapped to " >>> >>> Look at the diagram below from info draft: >>> >>> I1 +-------------+ +-------------+ E1 >>> ----->| | +--------+ | |-----> >>> I2 | +------+ Rb #1 +-------+ | E2 >>> ----->| | +--------+ | |-----> >>> | | | | >>> | Resource | +--------+ | Resource | >>> | Pool +------+ +-------+ Pool | >>> | | + Rb #2 + | | >>> | Input +------+ +-------| Output | >>> | Connection | +--------+ | Connection | >>> | Matrix | . | Matrix | >>> | | . | | >>> | | . | | >>> IN | | +--------+ | | EM >>> ----->| +------+ Rb #P +-------+ |-----> >>> | | +--------+ | | >>> +-------------+ ^ ^ +-------------+ >>> | | >>> | | >>> | | >>> | | >>> >>> Input wavelength Output wavelength >>> constraints for constraints for >>> each resource each resource >>> >>> Figure 1 Schematic diagram of resource pool model. >>> >>> Add/Drop ports to/from Resource Pool (i.e., I1,...IN and E1,..EN) is >>> part of link information and advertised as link-TLV; however Resource >>> Blocks and its internal connectivity is not modeled as node property >>> as they are internal to Resource Pool. >>> >>> ::=3D ... >>> [...] [...] >>> [] >>> >>> We modeled how RB's are accessible via matrices (input/ouput), if >>> there are wavelength limitations and if RB's are available. All of >>> these are modeled as the node property. >>> >>> And within RBinfo, we included Input/Output Constraints where ClientSig= nalList (GPID) is specified. >>> >>> ::=3D ([] >>> [] )* >>> >>> Where >>> ::=3D [] >>> [] >>> >>> >>> >>> I was delaying asking if a couple of related questions until the >>> above was resolved, but perhaps it makes sense to ask them now: >>> - Shouldn't also be allowed under ? >>> >>> YOUNG>> It is implied. is checked in and has obviously the same property. We can add this= comment to clarify. >>> >> >> So there is/will never (be) a case where the differ = from the ? As you say, this certainly should be made expl= icit. >> >>> - Doesn't it make sense to simplify the add/drop G-PID identification >>> by adding somewhere under (generic) ? >>> >> y> YOUNG>> I think you meant doing this at the source/destination. >> sure, but aren't add/drop always at source/destination? (I guess you >> can come up with a case where they aren't, but this isn't the norm...) >> >> Y> Again >> y> I am not sure if we really need to advertise tributary client >> y> signal as link TLV. We have signaling mechanism to verify this. >> >> As you say, this point is covered above. >> >>> Thanks, >>> Lou >>> >>>> >>>> Regards, >>>> Young >>>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: Monday, March 18, 2013 8:07 AM >>>> To: Leeyoung; CCAMP >>>> Cc: Margaria, Cyril (NSN - DE/Munich); >>>> draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org >>>> Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19 >>>> >>>> Young/All, >>>> >>>> Some of the discussions last week (on 709 and dimitri's) got me >>>> thinking more about the inclusion of G-PID on the wson specific >>>> encoding. As G-PID and other client/input information is not >>>> technology specific, and it looks like there's a likely a need for a >>>> general solution, shouldn't the G-PID (and other 'client/input') >>>> information be in draft-ietf-ccamp-general-constraint-encode? >>>> >>>> Thoughts? >>>> >>>> Lou >>>> >>>> On 3/15/2013 5:35 AM, Leeyoung wrote: >>>>> Thanks. >>>>> >>>>> Young >>>>> >>>>> -----Original Message----- >>>>> From: Margaria, Cyril (NSN - DE/Munich) >>>>> [mailto:cyril.margaria@nsn.com] >>>>> Sent: Thursday, March 14, 2013 5:53 PM >>>>> To: Leeyoung; CCAMP; >>>>> draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org >>>>> Subject: RE: Comments on draft-ietf-ccamp-rwa-wson-encode-19 >>>>> >>>>> >>>>> Hi, >>>>> >>>>> Thanks for the quick feedback. As this introduce a dependency with >>>>> the GPID, the text should indicate that the number of bit rate MUST m= atch the number of GPID. >>>>> >>>>> Other than that I think this is acceptable >>>>> >>>>> >>>>> >>>>> Best regards / Mit freundlichen Gr=FC=DFen Cyril Margaria >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: ext Leeyoung [mailto:leeyoung@huawei.com] >>>>>> Sent: Wednesday, March 13, 2013 9:33 PM >>>>>> To: Margaria, Cyril (NSN - DE/Munich); CCAMP; >>>>>> draft-ietf-ccamp-rwa- wson-encode@tools.ietf.org >>>>>> Subject: RE: Comments on draft-ietf-ccamp-rwa-wson-encode-19 >>>>>> >>>>>> Hi Cyril, >>>>>> >>>>>> Thanks for your comment. >>>>>> >>>>>> This refers to the "Input Bit Rate" of the associated client >>>>>> Signal Type in the RB. >>>>>> Below is a new section 5.4 that defines Input Bit Rate List >>>>>> Sub-Sub- TLV. We removed "range" from this Sub-Sub-TLV. >>>>>> >>>>>> Let me know if this is acceptable. >>>>>> >>>>>> Thanks. >>>>>> Young >>>>>> >>>>>> ------------------------------------------------------------------ >>>>>> --- >>>>>> >>>>>> 5.4. Input Bit Rate List Sub-Sub-TLV >>>>>> >>>>>> This sub-sub-TLV contains a list of bit rate of each input client >>>>>> signal types specified in the Input Client Signal List Sub-Sub-TLV. >>>>>> Type :=3D Input Bit Rate List >>>>>> Value :=3D IEEE 32-bit IEEE Floating Point >>>>>> >>>>>> 0 1 2 3 >>>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> | Input Bit Rate of GPID #1 = | >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> : : >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> | Input Bit Rate of GPID #N = | >>>>>> >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>>>>> Behalf Of Margaria, Cyril (NSN - DE/Munich) >>>>>> Sent: Wednesday, March 13, 2013 8:54 AM >>>>>> To: CCAMP; draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org >>>>>> Subject: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19 >>>>>> >>>>>> Dear Authors, >>>>>> >>>>>> I have the following comments on >>>>>> draft-ietf-ccamp-rwa-wson-encode-19 >>>>>> >>>>>> Section 5.1 Resource Block Information Sub-TLV >>>>>> >>>>>> The sub-TLV format defines the "Input Bit Rate Range List >>>>>> Sub-Sub-TLV (opt)" >>>>>> No section defines the Input Bit range List Sub-Sub-TLV, while it >>>>>> was present in the previous version. >>>>>> >>>>>> I think the section should be re-added. >>>>>> >>>>>> >>>>>> Mit freundlichen Gr=FC=DFen / Best Regards Cyril Margaria >>>>>> >>>>>> Nokia Siemens Networks Optical GmbH St.Martin-Str. 76 >>>>>> D-81541 M=FCnchen >>>>>> Germany >>>>>> mailto:cyril.margaria@nsn.com >>>>>> Phone: +49-89-5159-16934 >>>>>> Fax: +49-89-5159-44-16934 >>>>>> ---------------------------------------------------------------- >>>>>> Nokia Siemens Networks Optical GmbH Gesch=E4ftsleitung / Board of >>>>>> Directors: Gero Neumeier, Dr. Rolf Nauerz Sitz der Gesellschaft: >>>>>> M=FCnchen / Registered office: Munich >>>>>> Registergericht: M=FCnchen / Commercial registry: Munich, HRB 197143 >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> CCAMP mailing list >>>>>> CCAMP@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> > > > >= From lberger@labn.net Wed May 8 11:43:08 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2A821F8A74 for ; Wed, 8 May 2013 11:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.847 X-Spam-Level: X-Spam-Status: No, score=-101.847 tagged_above=-999 required=5 tests=[AWL=0.419, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRXe+gQQMqaJ for ; Wed, 8 May 2013 11:43:04 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 0E45D21F8AD1 for ; Wed, 8 May 2013 11:43:01 -0700 (PDT) Received: (qmail 18127 invoked by uid 0); 8 May 2013 18:42:38 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.bluehost.com with SMTP; 8 May 2013 18:42:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=U8hMAyNV1Ou/1QPcz9WQ7D2GERGnLayGqmqTIyCjLpU=; b=FUNP/ZbhALnW7lsORmS7eE9u44f9p3ubtPcNjDRdPQtPIxvi+GXEgXEuRwWA5dKiwOYAhyUGnmEInPS0ap9eLa4xdhO0wJeMQNKL5cKnFpcpLH56b9CWOWwMzili4AzX; Received: from box313.bluehost.com ([69.89.31.113]:43791 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Ua9K2-0007j6-3o; Wed, 08 May 2013 12:42:38 -0600 Message-ID: <518A9C9C.1020308@labn.net> Date: Wed, 08 May 2013 14:42:36 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Leeyoung References: <8DC6547C806B644F998A0566E79E15920F7DFF60@DEMUMBX006.nsn-intra.net> <7AEB3D6833318045B4AE71C2C87E8E172911828D@dfweml511-mbs.china.huawei.com> <8DC6547C806B644F998A0566E79E15920F7E1284@DEMUMBX006.nsn-intra.net> <7AEB3D6833318045B4AE71C2C87E8E172911D7BA@dfweml511-mbs.china.huawei.com> <51471168.3000400@labn.net> <7AEB3D6833318045B4AE71C2C87E8E172911DC5E@dfweml511-mbs.china.huawei.com> <514895C5.7080300@labn.net> <7AEB3D6833318045B4AE71C2C87E8E1729121785@dfweml511-mbs.china.huawei.com> <515DF956.1020305@labn.net> <7AEB3D6833318045B4AE71C2C87E8E172913671A@dfweml511-mbs.china.huawei.com> <518906F8.50507@labn.net> <7AEB3D6833318045B4AE71C2C87E8E172913A254@dfweml511-mbs.china.huawei.com>, <518A6DC7.9060705@labn.net> <7AEB3D6833318045B4AE71C2C87E8E172913C520@dfweml511-mbs.china.huawei.com> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E172913C520@dfweml511-mbs.china.huawei.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP , "draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org" Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 18:43:08 -0000 Young, Thanks for the quick response. My main issue was really about advertisement of egress trib resources, which you said was not the intent and that the documents will be updated to reflect this point. Once this update is completed and the WG has a chance to provide input on the changes, this point will be closed. WRT regen related advertisement, thank you for providing your rationale. It seems to me that this is very dependent on specific equipment being developed/deployed, and that you've proposed your preferred optimization point. Much thanks, Lou On 5/8/2013 1:36 PM, Leeyoung wrote: > Hi Lou, > > The main issue you raised: > > "It does raise the question of why the current solution (i.e., crankback) is fine for the egress case, but not for the regen case. As I thought you were covering both case, I haven't thought much on this. Can you explain why you made this tradeoff (G-PID advertisement for regen, but not egress)?" > > Here's my answer: > > As a WSON optical LSP may involve a set of REGEN's along the LSP, I view that IGP dissemination of REGEN related contraints including G-PID would be a sensible thing as we may have several potential "incompatibility" points. In such case, depending only on the signaling mechanism would potentially result in a number of crankbacks as there are more permutations in matching G-PID over multiple REGEN points. > > Without REGEN elements along the LSP, G-PID check is done at the egress which is a single point. In such environment, GMPLS signaling mechanism has a higher likelihood of success in finding the match/compatibility. > > Thanks. > Young > > > ________________________________________ > From: Lou Berger [lberger@labn.net] > Sent: Wednesday, May 08, 2013 10:22 AM > To: Leeyoung > Cc: CCAMP; draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org > Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19 > > Young, > > see below. > > On 5/7/2013 3:06 PM, Leeyoung wrote: >> Hi Lou, >> >> Yes, the scope of drop ports mentioned in Section 6 of the info >> document is aimed at just Regen ports. I will make this point clear >> in the revision of the info draft. > > Great. > >> As we modeled Regen signal compatibility that includes Regen drop >> port limitation, G-PID compatibility identification for Regen (in and >> out) is included as part of the "package" per se to advertise all >> Regen related constraints using IGP. >> >> Egress G-PID compatibility check has been built as part of GMPLS >> Signaling, which I believe serves the purpose well. >> > > As you know: There's lots of information that shows up in both > signaling and routing, where the former provides the requirements of > a specific LSP and the latter provides the capabilities/availabilities > within the network. Having information in routing doesn't obviate the > need for the same information in signaling, and information contained > in signaling need not be represented in routing. And, to oversimplify, > the more information that's available in routing the more likely that > a path computed for a LSP will be established without the use of > error/crankback processing, but also more likely the IGP/system will > run into scaling issues. > > So GMPLS' current representation of G-PID in signaling, but not > routing, reflects a judgement call at the time GMPLS routing was > defined. (and to rely on error/crankback processing when there are > g-pid mismatches.) While not an author of RFC4202, I believe part of > this tradeoff calculus was the assumption that there is a high > probability of there being a switch function at the egress that allows > the termination of an LSP coming in (from the network) on any interface > for any G-PID (and any other termination/egress constraint) supported > on the node. Given that WSON clearly widens the scope to include nodes > where this assumption no longer holds, it seemed reasonable (at least > to me) for the WSON documents to revisit this decision. > >> If you want Egress (tributary side) G-PID compatibility check using >> IGP, this is a whole different matter. > > It's not a matter of what I want, it's a matter of what the WSON > documents currently state & allow. As I mentioned earlier in this > thread, the current text seems to support and even envision > advertisement of trib/egress resources, including G-PID. From my > perspective, advertisement of egress resources should be generic and > this was the main point of my comments. > > Modifying the WSON documents make it clear that egress/trib resources > aren't being advertised resolves this comment. (please don't forget to > add the other comments discussed in this thread.) > > It does raise the question of why the current solution (i.e., crankback) > is fine for the egress case, but not for the regen case. As I thought > you were covering both case, I haven't thought much on this. Can you > explain why you made this tradeoff (G-PID advertisement for regen, but > not egress)? > >> First, I think we need a clear >> use-case and requirement why we want to do this in light of the >> signaling mechanism that does the check. Let me know if this is not >> the case from your perspective. Are there some reasons you believe >> GMPLS Signaling mechanism would not work to check the tributary >> egress G-PID check? >> > > As discussed above having information in routing doesn't obviate the > need for the same information & check to be present in signaling, it > just changes the probability of success/crankback. > > Lou > >> Regards, >> Young >> >> >> >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Tuesday, May 07, 2013 8:52 AM >> To: Leeyoung >> Cc: CCAMP; draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org >> Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19 >> >> [oops, found this in my outbox -- sorry about the delay] >> >> Young, >> >> I think this discussion primarily comes down to the intent of mentioning drop ports in several places in Section 6 of the info document. >> >> Is the scope of this text aimed at just regen ports or any drop (regen >> &trib) ports? The text isn't scoped so, as I mentioned/asked in my mail on 4/4, I understood it to refer to the advertisement of information for any drop port. so: >>> Did I misunderstand the intent of mentioning drop ports in several >>> places in Section 6 of the info document? >> >> If the intended scope is just regen, this needs to be made clear in the documents. Furthermore, as the same (G-PID compatibility >> identification) issue exists with the egress, why wouldn't the same solution be used for both? >> >> Much thanks, >> Lou >> >> On 4/24/2013 12:17 PM, Leeyoung wrote: >>> Hi Lou, >>> >>> I think the main point is if we need to advertise add/drop >>> (tributary) ports in generic context? You said in the previous >>> email: >>> >>> "I agree that that is how it is normally done, but WSON seems to be changing this in two respects: >>> 1) By advertising G-PID at all, >>> 2) By advertising add/drop ports, where prior GMPLS approaches have only advertised the network facing interfaces." >>> >>> These elements above are part of regeneration elements that constitute >>> a WSON lightpath which begins the line side of ingress and ends the >>> line side of egress. See the diagram below: >>> >>> ---- ---- >>> | |<------------ -------------->| | >>> ---- | | ---- >>> -------- >>> | REG | >>> -------- >>> There is a clear use case for this for WSON as REG's are integral part >>> of a WSON lightpath which can cause an incompatibility/blocking issue >>> of the path. Drop/Add ports here in REG element may have wavelength >>> restriction and that is why this is an additional constraint to look >>> at. >>> >>> Advertising tributary ports in general context is a different matter >>> to me. Not sure if there is a clear use case that can be justified to >>> support advertising tributary ports in general context. Even if there >>> is, I don't think that is part of the scope of the generic encoding. >>> >>> >>> Regards, >>> Young >>> >>> >>> >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf >>> Of Lou Berger >>> Sent: Thursday, April 04, 2013 5:06 PM >>> To: Leeyoung >>> Cc: CCAMP; draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org >>> Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19 >>> >>> Young, >>> Please see below. >>> >>> On 3/27/2013 1:59 PM, Leeyoung wrote: >>>> Hi Lou, >>>> >>>> Please see my comments in-line. >>>> >>>> Thanks. >>>> Young >>>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: Tuesday, March 19, 2013 11:44 AM >>>> To: Leeyoung >>>> Cc: CCAMP; Margaria, Cyril (NSN - DE/Munich); >>>> draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org >>>> Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19 >>>> >>>> >>>> Young, >>>> See below. >>>> On 3/18/2013 1:02 PM, Leeyoung wrote: >>>>> Hi Lou, >>>>> >>>>> The encoding is a part of the Resource Block >>>> >>>> Understood, but my comment was more on the definition of >>>> / encoding. >>>> >>>>> (that includes Regenerators and Wavelength converters) which is a WSON specific entity. >>>> >>>> So I agree that the need for transit nodes to have detailed encoding >>>> and adaptation information to support 3R and certain other types of >>>> switching is (at least to my understanding) specific to WSON. >>>> >>> >>> Y> YOUNG>> RFC 3471 and RFC 4328 discuss G-PID as part of Generalized >>> Y> Label Request parameters to indicate client/tributary layer of the >>> Y> LSP at the source/sink. >>> Y> >>> Y> I was not clear on what you meant "trib side resources." If you >>> Y> meant "trib side resources" are LSP encoding type, Switching Type >>> Y> and G-PID (which are covered by RFC 3471/4328), I believe RFC >>> Y> 3471/4328 are sufficient; if not could you elaborate? >>> >>> trib side = add/drop port at ingress/egress >>> >>> resources = attributes related to data that port can transport >>> >>>> >>>> But unless I misunderstand the WSON info draft, this same information >>>> can be advertised in support of the trib side resources (i.e., at the >>>> source/destination for add/drop) and this is a generic requirement >>>> shared with other technologies. >>>> >>> >>> y> YOUNG>> Here you seemed to allude the need for advertizing the >>> y> Source/Destination tributary resource information using IGP. In >>> y> general, OSPF does not advertise the trib-side information, does it? >>> y> I believe signaling check on the tributary resource info on LSP >>> y> level is good enough per RFC 3471/4328. Please correct me if my >>> y> understanding is wrong. >>> >>> >>> I agree that that is how it is normally done, but WSON seems to be changing this in two respects: >>> 1) By advertising G-PID at all, >>> 2) By advertising add/drop ports, where prior GMPLS approaches have only advertised the network facing interfaces. >>> >>> Did I misunderstand the intent of mentioning drop ports in several places in Section 6 of the info document? >>> >>>> >>>> So this lead me to ask about changing the G-PID list encoding to be >>>> defined in the generic drafts (to facilitate PID advertisement for >>>> non-WSON technologies.) Perhaps just having a generic encoding for a >>>> G-PID list won't be of much value, but I suspect that we'll end up >>>> needing it for other technologies too. >>>> >>> >>> Y> YOUNG>> This point is carried from the above discussion. G-PID has >>> Y> been specified to cover all GMPLS related technologies. >>> >>> Agreed that this is a derivative point and can wait until the above is clarified. >>> >>>> -- For what it's worth I am having some trouble understanding how >>>> G-PID is advertised for add/drop. As far as I can tell, you have a >>>> per add/drop port, mapped to , to a >>>> and infer output G-PID from the . >>>> At least that's how I'm reading the info draft. >>> >>> Y> YOUNG>> Actually G-PID is advertised as part of the Node >>> Y> information: ::= [...] >>> Y> [] >>> >>> Got that. That's what I was referring to when I said " mapped to " >>>> >>>> Look at the diagram below from info draft: >>>> >>>> I1 +-------------+ +-------------+ E1 >>>> ----->| | +--------+ | |-----> >>>> I2 | +------+ Rb #1 +-------+ | E2 >>>> ----->| | +--------+ | |-----> >>>> | | | | >>>> | Resource | +--------+ | Resource | >>>> | Pool +------+ +-------+ Pool | >>>> | | + Rb #2 + | | >>>> | Input +------+ +-------| Output | >>>> | Connection | +--------+ | Connection | >>>> | Matrix | . | Matrix | >>>> | | . | | >>>> | | . | | >>>> IN | | +--------+ | | EM >>>> ----->| +------+ Rb #P +-------+ |-----> >>>> | | +--------+ | | >>>> +-------------+ ^ ^ +-------------+ >>>> | | >>>> | | >>>> | | >>>> | | >>>> >>>> Input wavelength Output wavelength >>>> constraints for constraints for >>>> each resource each resource >>>> >>>> Figure 1 Schematic diagram of resource pool model. >>>> >>>> Add/Drop ports to/from Resource Pool (i.e., I1,...IN and E1,..EN) is >>>> part of link information and advertised as link-TLV; however Resource >>>> Blocks and its internal connectivity is not modeled as node property >>>> as they are internal to Resource Pool. >>>> >>>> ::= ... >>>> [...] [...] >>>> [] >>>> >>>> We modeled how RB's are accessible via matrices (input/ouput), if >>>> there are wavelength limitations and if RB's are available. All of >>>> these are modeled as the node property. >>>> >>>> And within RBinfo, we included Input/Output Constraints where ClientSignalList (GPID) is specified. >>>> >>>> ::= ([] >>>> [] )* >>>> >>>> Where >>>> ::= [] >>>> [] >>>> >>>> >>>> >>>> I was delaying asking if a couple of related questions until the >>>> above was resolved, but perhaps it makes sense to ask them now: >>>> - Shouldn't also be allowed under ? >>>> >>>> YOUNG>> It is implied. is checked in and has obviously the same property. We can add this comment to clarify. >>>> >>> >>> So there is/will never (be) a case where the differ from the ? As you say, this certainly should be made explicit. >>> >>>> - Doesn't it make sense to simplify the add/drop G-PID identification >>>> by adding somewhere under (generic) ? >>>> >>> y> YOUNG>> I think you meant doing this at the source/destination. >>> sure, but aren't add/drop always at source/destination? (I guess you >>> can come up with a case where they aren't, but this isn't the norm...) >>> >>> Y> Again >>> y> I am not sure if we really need to advertise tributary client >>> y> signal as link TLV. We have signaling mechanism to verify this. >>> >>> As you say, this point is covered above. >>> >>>> Thanks, >>>> Lou >>>> >>>>> >>>>> Regards, >>>>> Young >>>>> >>>>> -----Original Message----- >>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>> Sent: Monday, March 18, 2013 8:07 AM >>>>> To: Leeyoung; CCAMP >>>>> Cc: Margaria, Cyril (NSN - DE/Munich); >>>>> draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org >>>>> Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19 >>>>> >>>>> Young/All, >>>>> >>>>> Some of the discussions last week (on 709 and dimitri's) got me >>>>> thinking more about the inclusion of G-PID on the wson specific >>>>> encoding. As G-PID and other client/input information is not >>>>> technology specific, and it looks like there's a likely a need for a >>>>> general solution, shouldn't the G-PID (and other 'client/input') >>>>> information be in draft-ietf-ccamp-general-constraint-encode? >>>>> >>>>> Thoughts? >>>>> >>>>> Lou >>>>> >>>>> On 3/15/2013 5:35 AM, Leeyoung wrote: >>>>>> Thanks. >>>>>> >>>>>> Young >>>>>> >>>>>> -----Original Message----- >>>>>> From: Margaria, Cyril (NSN - DE/Munich) >>>>>> [mailto:cyril.margaria@nsn.com] >>>>>> Sent: Thursday, March 14, 2013 5:53 PM >>>>>> To: Leeyoung; CCAMP; >>>>>> draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org >>>>>> Subject: RE: Comments on draft-ietf-ccamp-rwa-wson-encode-19 >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> Thanks for the quick feedback. As this introduce a dependency with >>>>>> the GPID, the text should indicate that the number of bit rate MUST match the number of GPID. >>>>>> >>>>>> Other than that I think this is acceptable >>>>>> >>>>>> >>>>>> >>>>>> Best regards / Mit freundlichen Grüßen Cyril Margaria >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: ext Leeyoung [mailto:leeyoung@huawei.com] >>>>>>> Sent: Wednesday, March 13, 2013 9:33 PM >>>>>>> To: Margaria, Cyril (NSN - DE/Munich); CCAMP; >>>>>>> draft-ietf-ccamp-rwa- wson-encode@tools.ietf.org >>>>>>> Subject: RE: Comments on draft-ietf-ccamp-rwa-wson-encode-19 >>>>>>> >>>>>>> Hi Cyril, >>>>>>> >>>>>>> Thanks for your comment. >>>>>>> >>>>>>> This refers to the "Input Bit Rate" of the associated client >>>>>>> Signal Type in the RB. >>>>>>> Below is a new section 5.4 that defines Input Bit Rate List >>>>>>> Sub-Sub- TLV. We removed "range" from this Sub-Sub-TLV. >>>>>>> >>>>>>> Let me know if this is acceptable. >>>>>>> >>>>>>> Thanks. >>>>>>> Young >>>>>>> >>>>>>> ------------------------------------------------------------------ >>>>>>> --- >>>>>>> >>>>>>> 5.4. Input Bit Rate List Sub-Sub-TLV >>>>>>> >>>>>>> This sub-sub-TLV contains a list of bit rate of each input client >>>>>>> signal types specified in the Input Client Signal List Sub-Sub-TLV. >>>>>>> Type := Input Bit Rate List >>>>>>> Value := IEEE 32-bit IEEE Floating Point >>>>>>> >>>>>>> 0 1 2 3 >>>>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>> | Input Bit Rate of GPID #1 | >>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>> : : >>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>> | Input Bit Rate of GPID #N | >>>>>>> >>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>>>>>> Behalf Of Margaria, Cyril (NSN - DE/Munich) >>>>>>> Sent: Wednesday, March 13, 2013 8:54 AM >>>>>>> To: CCAMP; draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org >>>>>>> Subject: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-encode-19 >>>>>>> >>>>>>> Dear Authors, >>>>>>> >>>>>>> I have the following comments on >>>>>>> draft-ietf-ccamp-rwa-wson-encode-19 >>>>>>> >>>>>>> Section 5.1 Resource Block Information Sub-TLV >>>>>>> >>>>>>> The sub-TLV format defines the "Input Bit Rate Range List >>>>>>> Sub-Sub-TLV (opt)" >>>>>>> No section defines the Input Bit range List Sub-Sub-TLV, while it >>>>>>> was present in the previous version. >>>>>>> >>>>>>> I think the section should be re-added. >>>>>>> >>>>>>> >>>>>>> Mit freundlichen Grüßen / Best Regards Cyril Margaria >>>>>>> >>>>>>> Nokia Siemens Networks Optical GmbH St.Martin-Str. 76 >>>>>>> D-81541 München >>>>>>> Germany >>>>>>> mailto:cyril.margaria@nsn.com >>>>>>> Phone: +49-89-5159-16934 >>>>>>> Fax: +49-89-5159-44-16934 >>>>>>> ---------------------------------------------------------------- >>>>>>> Nokia Siemens Networks Optical GmbH Geschäftsleitung / Board of >>>>>>> Directors: Gero Neumeier, Dr. Rolf Nauerz Sitz der Gesellschaft: >>>>>>> München / Registered office: Munich >>>>>>> Registergericht: München / Commercial registry: Munich, HRB 197143 >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> CCAMP mailing list >>>>>>> CCAMP@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>> _______________________________________________ >>>>>> CCAMP mailing list >>>>>> CCAMP@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >>> >>> >>> >>> >> >> >> >> > > > From zhangfatai@huawei.com Thu May 9 00:12:32 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A36021F8E2C for ; Thu, 9 May 2013 00:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pUlYTqUbZsjI for ; Thu, 9 May 2013 00:12:28 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6369D21F8F3C for ; Thu, 9 May 2013 00:12:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASQ19126; Thu, 09 May 2013 07:12:24 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 9 May 2013 08:12:08 +0100 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 9 May 2013 08:12:21 +0100 Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.222]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.007; Thu, 9 May 2013 15:12:18 +0800 From: Fatai Zhang To: Lou Berger , CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" , "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" Thread-Topic: Closing G.709 open issues Thread-Index: AQHOTAyDmhSnK0jr+ESubR/xu8VPgpj8bQiw Date: Thu, 9 May 2013 07:12:18 +0000 Message-ID: References: <518A82D9.7080508@labn.net> In-Reply-To: <518A82D9.7080508@labn.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [CCAMP] Closing G.709 open issues X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 07:12:32 -0000 Hi Lou, For point 1), do you mean that you would like to have "TSG" field (ie., exp= licit indication) in the label format? Or just change the target text that = you quoted?=20 If what you meant is the latter, could you provide some proposed text to re= fine it. For point 2), the GPIDs have been grouped based on Table 15-8 in G.709 (so = it seems that some payload types in Table 15-8 are missed), but I think you= more like the 1:1 mapping between the GPID defined in [SIGNALING] and Tabl= e 15-8. We will check and list all the ungrouped GPIDs.=20 Best Regards Fatai -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Thursday, May 09, 2013 12:53 AM To: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; draft-ie= tf-ccamp-otn-g709-info-model@tools.ietf.org Subject: Closing G.709 open issues Authors/WG, I think all would like to wrap up the 709 documents before Berlin. To do this we need to: 1) Ensure all discussed points have been resolved 2) Hold a 2nd LC to ensure consensus on all changes since the 1st LC 3) Capture the resolution of any comments made during 2. In reviewing the close to 200 mail messages on the documents since the 1st LC was issued, I see only one a few points that are still missing, and I'll cover these below. On a side note, as an experiment we'll be tracking these issue via the tools issues page: http://tools.ietf.org/wg/ccamp/trac/report/1 PLEASE reply to this message if you think there are other points/discussions that haven't been addressed in the current set of documents. Once this thread is closed, the 2nd LC will be initiated. The remaining items come from the tread with the final message http://www.ietf.org/mail-archive/web/ccamp/current/msg14701.html The message is from me in response to Daniele's summary of next steps, and has the following unresolved actions: 1) No explicit indication of TSG in the label [SIGNALING] In signaling document section 6: Clarify related text to unambiguous identify the relationship between label length and TSG. Possible target text to change: Note that the Length field in the label format MAY be used to indicate the TS type of the HO ODUk (i.e., TS granularity at 1.25Gbps or 2.5Gbps) since the HO ODUk type can be known from IF_ID RSVP_HOP Object. In some cases when there is no Link Management Protocol (LMP) or routing to make the two end points of the link to know the TSG, the TSG information used by another end can be deduced from the label format. For example, for HO ODU2 link, the value of the length filed will be 4 or 8, which indicates the TS granularity is 2.5Gbps or 1.25Gbps, respectively. 2) Verify that the complete list of G-PIDs are defined [SIGNALING] In signaling document section 4, verify that all payload types defined in G.709 (Summarized in Table 15-8) can be represented. This issue can be resolved via an update or message to the list stating that the verification took place. 3) Identification of hexadecimal representation in G.709 vs decimal in GMPLS [INFO-MODEL] The authors had previously stated the intent to just make this clear in the signaling document. I'd like to make an alternate proposal: let's do the the obvious and have the documents simply use the normal (IETF) convention of using a '0x' prefix anytime a hexadecimal value is represented. I believe this means that only the info-model draft needs to be updated. I believe that's the complete list. Again: PLEASE reply to this message if you think there are other points/discussions that haven't been addressed in the current set of documents. Much thanks, Lou From lberger@labn.net Thu May 9 06:57:10 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D05421F851C for ; Thu, 9 May 2013 06:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=1.002, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXaWkiD8Ie-y for ; Thu, 9 May 2013 06:57:05 -0700 (PDT) Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id E4C9821F8519 for ; Thu, 9 May 2013 06:57:04 -0700 (PDT) Received: (qmail 27713 invoked by uid 0); 9 May 2013 13:56:40 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy12.bluehost.com with SMTP; 9 May 2013 13:56:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=pn6Y+GaGU+zSGxi3h3r0u3lnbH0lpUd7E7qQsCysWbA=; b=oC5IIQNpV5as2X3lRl6heG1hhiEOUgAZ3JffIjyP3vvBiJwNOiXGQ8L94ajmA8Vd8C9Kx45TLQ2x71JMaAy3EjtwS4AmXUt4o9+OyBDl6NNLvAeXLWEm+fkUyI8AwJPf; Received: from box313.bluehost.com ([69.89.31.113]:42177 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UaRKp-0003iE-Sa; Thu, 09 May 2013 07:56:40 -0600 Message-ID: <518BAB17.9090807@labn.net> Date: Thu, 09 May 2013 09:56:39 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Fatai Zhang References: <518A82D9.7080508@labn.net> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" , "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" Subject: Re: [CCAMP] Closing G.709 open issues X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 13:57:10 -0000 Just to be clear to all: My mail summarized the results of discussions that occurred on the list whose results I believe are not reflected in the current document set. I identified 3 items, and hope I didn't miss anything from the ~200 related messages on the list. I'm not trying to change any conclusions, just ensure that they are documented. Fatai, See below for specific responses. On 5/9/2013 3:12 AM, Fatai Zhang wrote: > Hi Lou, > > For point 1), do you mean that you would like to have "TSG" field > (ie., explicit indication) in the label format? Or just change the > target text that you quoted? > This point was resolved in http://www.ietf.org/mail-archive/web/ccamp/current/msg14701.html to quote: On 3/21/2013 9:51 AM, Lou Berger wrote: > Daniele, ... > On 3/21/2013 9:34 AM, Daniele Ceccarelli wrote: >> Lou, >> >> OK. No changes to signaling re explicit indication of mapping >> and/or TSG in the label. > > I think it would be a good idea to add a comment on this in the > signaling document so that we don't have to revisit it yet again... > > If what you meant is the latter, could you provide some proposed text to refine it. > I suggest that the authors propose some text on the list for the WG to review. Given that the explicit indication issue was raised by one of the co-authors I suspect he can provide text that ensures the issue is covered. There's also some related text already on page 7 of the framework draft. If the authors are unable to come up with a proposal, let me know and I'll propose something to the list. > For point 2), the GPIDs have been grouped based on Table 15-8 in > G.709 (so it seems that some payload types in Table 15-8 are missed), > but I think you more like the 1:1 mapping between the GPID defined in > [SIGNALING] and Table 15-8. The only thing I'm asking for is to verify that it is possible to unambiguously signal the G.709 defined payload types with GMPLS. The authors are free to use any approach, e.g., 1:1 or n:1+other signaled information. > We will check and list all the ungrouped GPIDs. > If you think it's possible to indicate all G.709 defined payload types using the current "grouped" approach, that works for me. You just need to state such on the list. Perhaps it makes sense to just list how each PT in G.709 table 15-8 is represented as a good sanity check. Such a list might also be useful information to add to the draft. Here's a start at such a list. I've flagged the results of a spot check (i.e., I probably have missed something) of PTs for which I don't see an obvious mapping. G.709 Payload Type G-PID ------- ----- 0x01 ??? 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0A 0x0B 0x0C 0x0D 0x0E 0x0F 0x10 0x11 0x12 ??? 0x13 ??? 0x14 ??? 0x15 ??? 0x16 ??? 0x17 ??? 0x18 ??? 0x19 ??? 0x1A 0x1B ??? 0x1C 0x20 0x21 0x55 Unused 0x66 Unused 0x80-0x8F ??? 0xFD ?? (Is this needed?) 0xFE ?? (Is this needed?) 0xFF Unused Thanks, Lou > > > > Best Regards > > Fatai > > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Thursday, May 09, 2013 12:53 AM > To: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org > Subject: Closing G.709 open issues > > Authors/WG, > I think all would like to wrap up the 709 documents before > Berlin. To do this we need to: > 1) Ensure all discussed points have been resolved > 2) Hold a 2nd LC to ensure consensus on all changes since the 1st LC > 3) Capture the resolution of any comments made during 2. > > In reviewing the close to 200 mail messages on the documents since the > 1st LC was issued, I see only one a few points that are still missing, > and I'll cover these below. On a side note, as an experiment we'll be > tracking these issue via the tools issues page: > http://tools.ietf.org/wg/ccamp/trac/report/1 > > PLEASE reply to this message if you think there are other > points/discussions that haven't been addressed in the current set of > documents. Once this thread is closed, the 2nd LC will be initiated. > > The remaining items come from the tread with the final message > http://www.ietf.org/mail-archive/web/ccamp/current/msg14701.html > The message is from me in response to Daniele's summary of next steps, > and has the following unresolved actions: > > 1) No explicit indication of TSG in the label [SIGNALING] > > In signaling document section 6: Clarify related text to unambiguous > identify the relationship between label length and TSG. Possible > target text to change: > Note that the > Length field in the label format MAY be used to indicate the TS > type of the HO ODUk (i.e., TS granularity at 1.25Gbps or 2.5Gbps) > since the HO ODUk type can be known from IF_ID RSVP_HOP Object. In > some cases when there is no Link Management Protocol (LMP) or > routing to make the two end points of the link to know the TSG, > the TSG information used by another end can be deduced from the > label format. For example, for HO ODU2 link, the value of the > length filed will be 4 or 8, which indicates the TS granularity is > 2.5Gbps or 1.25Gbps, respectively. > > 2) Verify that the complete list of G-PIDs are defined [SIGNALING] > > In signaling document section 4, verify that all payload types > defined in G.709 (Summarized in Table 15-8) can be represented. > This issue can be resolved via an update or message to the list > stating that the verification took place. > > 3) Identification of hexadecimal representation in G.709 vs > decimal in GMPLS [INFO-MODEL] > > The authors had previously stated the intent to just make this clear > in the signaling document. I'd like to make an alternate proposal: > let's do the the obvious and have the documents simply use the normal > (IETF) convention of using a '0x' prefix anytime a hexadecimal value > is represented. I believe this means that only the info-model draft > needs to be updated. > > I believe that's the complete list. Again: > PLEASE reply to this message if you think there are other > points/discussions that haven't been addressed in the current set of > documents. > > Much thanks, > Lou > > > > > From daniele.ceccarelli@ericsson.com Thu May 9 09:57:38 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B52B21F8AF4 for ; Thu, 9 May 2013 09:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bW44asS4ctV for ; Thu, 9 May 2013 09:57:33 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5628421F9223 for ; Thu, 9 May 2013 09:57:32 -0700 (PDT) X-AuditID: c1b4fb2d-b7f536d000006e05-44-518bd57ae004 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 7E.34.28165.A75DB815; Thu, 9 May 2013 18:57:31 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.55]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Thu, 9 May 2013 18:57:30 +0200 From: Daniele Ceccarelli To: Lou Berger , Fatai Zhang Thread-Topic: Closing G.709 open issues Thread-Index: AQHOTAyAugJRODS18Eas2l6+kjNWaZj8T3QAgABw+YCAAExsIA== Date: Thu, 9 May 2013 16:57:30 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> References: <518A82D9.7080508@labn.net> <518BAB17.9090807@labn.net> In-Reply-To: <518BAB17.9090807@labn.net> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM+JvrW711e5Ag74aiydzbrBYbJ19n9li yuzvLBYdzW9ZLPqaz7M6sHq0HHnL6rFkyU8mjw+bmtk8vlz+zBbAEsVlk5Kak1mWWqRvl8CV cXLnXOaC304VM9YvZG9gXGHcxcjJISFgIjFlx1Z2CFtM4sK99WxdjFwcQgKHGSVWtM9ngXAW MUp8+HULyOHgYBOwknhyyAekQUTATWL+4tfsIDXMAk1MEoteXmMDSQgLqEnsffuAEaJIXaJ3 6yIo20li4s0OdpA5LAIqEl1dNiBhXgFvicl3P7GC2EICExklbpw1B7E5BTQk/j1bxwRiMwrI SkzYDTGGWUBc4taT+UwQRwtILNlznhnCFpV4+fgfK8h4CQFFieX9chDlehI3pk5hg7C1JZYt fM0MsVZQ4uTMJywTGMVmIZk6C0nLLCQts5C0LGBkWcXInpuYmZNebriJERhRB7f81t3BeOqc yCFGaQ4WJXHeJK7GQCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2M0xnkLV/eOnLVZDrPgn15 x4w2dQefPmbkO8Huq0pOe9Cj+BOPV/WF8O66EP7uxmeOCU5uv1ZoT1p2pJ3fhtHP+NCqN1Pj bm3XNqkxnvVqtvnywO50E7ffNy6vmHKJNXj5DZcsq7PNk5j0yjmdhdtXf6m/0Pl41r/5x68E /HqXGpq6+E9m8OeUi0osxRmJhlrMRcWJAEU4pg52AgAA Cc: CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" , "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" Subject: Re: [CCAMP] Closing G.709 open issues X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 16:57:38 -0000 Hi Lou, Wrt point 1) (TSG) we have 2 options. 1. leave the TSG being inferred by the label length and propose new text (s= ee below). 2. add the TSG to the label. Either solutions work for me, i just want to share some thoughts raised dur= ing discussions with Sergio and Fred. A. From an implementation point of view, in case of multi-stage muxing mult= iple label lookups are needed to infer the TSG B. Future proofness: we all know that TSG=3D10Gbps will be defined shorthly= . This might make the TSG infer from label length not feasible. Again, for me both solutions 1. and 2. work, A. And B. might not be major i= ssues. In case we go for 1. my proposed text is (feel free to amend): "Please note that the TSG of the HO ODUk can be inferred from the length of= the label. In those cases where there is no LMP imposing the TSG to be used between tw= o ends of a link, Such information can be inferred from the signaling. E.g. In a HO ODU link = a label lenght value Of 4 would indicate TSG equal to 2,5Gbps while a value of 8 would correspon= d to a 1.25Gbps TSG". BR Daniele >-----Original Message----- >From: Lou Berger [mailto:lberger@labn.net]=20 >Sent: gioved=EC 9 maggio 2013 15.57 >To: Fatai Zhang >Cc: CCAMP;=20 >draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org;=20 >draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org >Subject: Re: Closing G.709 open issues > > >Just to be clear to all: My mail summarized the results of=20 >discussions that occurred on the list whose results I believe=20 >are not reflected in the current document set. I identified 3=20 >items, and hope I didn't miss anything from the ~200 related=20 >messages on the list. I'm not trying to change any=20 >conclusions, just ensure that they are documented. > >Fatai, > >See below for specific responses. > >On 5/9/2013 3:12 AM, Fatai Zhang wrote: >> Hi Lou, >>=20 >> For point 1), do you mean that you would like to have "TSG" field=20 >> (ie., explicit indication) in the label format? Or just change the=20 >> target text that you quoted? >>=20 > >This point was resolved in >http://www.ietf.org/mail-archive/web/ccamp/current/msg14701.html >to quote: > On 3/21/2013 9:51 AM, Lou Berger wrote: > > Daniele, > ... > > On 3/21/2013 9:34 AM, Daniele Ceccarelli wrote: > >> Lou, > >> > >> OK. No changes to signaling re explicit indication of mapping > >> and/or TSG in the label. > > > > I think it would be a good idea to add a comment on this in the > > signaling document so that we don't have to revisit it yet again... > > > >> If what you meant is the latter, could you provide some=20 >proposed text to refine it. >>=20 > >I suggest that the authors propose some text on the list for=20 >the WG to review. Given that the explicit indication issue=20 >was raised by one of the co-authors I suspect he can provide=20 >text that ensures the issue is covered. There's also some=20 >related text already on page 7 of the framework draft. If the=20 >authors are unable to come up with a proposal, let me know and=20 >I'll propose something to the list. > >> For point 2), the GPIDs have been grouped based on Table 15-8 in >> G.709 (so it seems that some payload types in Table 15-8 are=20 >missed),=20 >> but I think you more like the 1:1 mapping between the GPID=20 >defined in=20 >> [SIGNALING] and Table 15-8. > >The only thing I'm asking for is to verify that it is possible=20 >to unambiguously signal the G.709 defined payload types with=20 >GMPLS. The authors are free to use any approach, e.g., 1:1 or=20 >n:1+other signaled information. > >> We will check and list all the ungrouped GPIDs. >>=20 > >If you think it's possible to indicate all G.709 defined=20 >payload types using the current "grouped" approach, that works=20 >for me. You just need to state such on the list. > >Perhaps it makes sense to just list how each PT in G.709 table=20 >15-8 is represented as a good sanity check. Such a list might=20 >also be useful information to add to the draft. Here's a=20 >start at such a list. I've flagged the results of a spot=20 >check (i.e., I probably have missed >something) of PTs for which I don't see an obvious mapping. > > G.709 > Payload > Type G-PID > ------- ----- > 0x01 ??? > 0x02 > 0x03 > 0x04 > 0x05 > 0x06 > 0x07 > 0x08 > 0x09 > 0x0A > 0x0B > 0x0C > 0x0D > 0x0E > 0x0F > 0x10 > 0x11 > 0x12 ??? > 0x13 ??? > 0x14 ??? > 0x15 ??? > 0x16 ??? > 0x17 ??? > 0x18 ??? > 0x19 ??? > 0x1A > 0x1B ??? > 0x1C > 0x20 > 0x21 > 0x55 Unused > 0x66 Unused > 0x80-0x8F ??? > 0xFD ?? (Is this needed?) > 0xFE ?? (Is this needed?) > 0xFF Unused > > >Thanks, >Lou > >>=20 >>=20 >>=20 >> Best Regards >>=20 >> Fatai >>=20 >>=20 >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Thursday, May 09, 2013 12:53 AM >> To: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org;=20 >> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org >> Subject: Closing G.709 open issues >>=20 >> Authors/WG, >> I think all would like to wrap up the 709 documents=20 >before Berlin. =20 >> To do this we need to: >> 1) Ensure all discussed points have been resolved >> 2) Hold a 2nd LC to ensure consensus on all changes since the 1st LC >> 3) Capture the resolution of any comments made during 2. >>=20 >> In reviewing the close to 200 mail messages on the documents=20 >since the=20 >> 1st LC was issued, I see only one a few points that are=20 >still missing,=20 >> and I'll cover these below. On a side note, as an=20 >experiment we'll be=20 >> tracking these issue via the tools issues page: >> http://tools.ietf.org/wg/ccamp/trac/report/1 >>=20 >> PLEASE reply to this message if you think there are other=20 >> points/discussions that haven't been addressed in the current set of=20 >> documents. Once this thread is closed, the 2nd LC will be initiated. >>=20 >> The remaining items come from the tread with the final message=20 >> http://www.ietf.org/mail-archive/web/ccamp/current/msg14701.html >> The message is from me in response to Daniele's summary of=20 >next steps,=20 >> and has the following unresolved actions: >>=20 >> 1) No explicit indication of TSG in the label [SIGNALING] >>=20 >> In signaling document section 6: Clarify related text to=20 >unambiguous >> identify the relationship between label length and TSG. Possible >> target text to change: >> Note that the >> Length field in the label format MAY be used to indicate the TS >> type of the HO ODUk (i.e., TS granularity at 1.25Gbps or 2.5Gbps) >> since the HO ODUk type can be known from IF_ID RSVP_HOP Object. In >> some cases when there is no Link Management Protocol (LMP) or >> routing to make the two end points of the link to know the TSG, >> the TSG information used by another end can be deduced from the >> label format. For example, for HO ODU2 link, the value of the >> length filed will be 4 or 8, which indicates the TS granularity is >> 2.5Gbps or 1.25Gbps, respectively. >>=20 >> 2) Verify that the complete list of G-PIDs are defined [SIGNALING] >>=20 >> In signaling document section 4, verify that all payload types >> defined in G.709 (Summarized in Table 15-8) can be represented. >> This issue can be resolved via an update or message to the list >> stating that the verification took place. >>=20 >> 3) Identification of hexadecimal representation in G.709 vs >> decimal in GMPLS [INFO-MODEL] >>=20 >> The authors had previously stated the intent to just make=20 >this clear >> in the signaling document. I'd like to make an alternate proposal: >> let's do the the obvious and have the documents simply use=20 >the normal >> (IETF) convention of using a '0x' prefix anytime a=20 >hexadecimal value >> is represented. I believe this means that only the info-model draft >> needs to be updated. >>=20 >> I believe that's the complete list. Again: >> PLEASE reply to this message if you think there are other=20 >> points/discussions that haven't been addressed in the current set of=20 >> documents. >>=20 >> Much thanks, >> Lou >>=20 >>=20 >>=20 >>=20 >>=20 >= From lberger@labn.net Thu May 9 10:21:42 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEAF521F8BC0 for ; Thu, 9 May 2013 10:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.097 X-Spam-Level: X-Spam-Status: No, score=-102.097 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYPPY5F2St6A for ; Thu, 9 May 2013 10:21:38 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id EDE8121F8BBC for ; Thu, 9 May 2013 10:21:37 -0700 (PDT) Received: (qmail 7344 invoked by uid 0); 9 May 2013 17:21:10 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 9 May 2013 17:21:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=0Cxu0b4Qey3qg/kVFYERead3r3Hl8xUNqDhL8TjDCeU=; b=gpxbYm22AwL78rmxPs4Lal9J9mF/5a3Lkb6WddHdtatAuPKh2dY1xarGrV80udmFaqQa/9ux6RV4JRpAR8oRZI1NWlP/6j8OPghBJ5cvd4rC97Ny3s9S3Q+fDjE4c5fD; Received: from box313.bluehost.com ([69.89.31.113]:42608 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UaUWj-00041g-US; Thu, 09 May 2013 11:21:10 -0600 Message-ID: <518BDAFF.40706@labn.net> Date: Thu, 09 May 2013 13:21:03 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Daniele Ceccarelli References: <518A82D9.7080508@labn.net> <518BAB17.9090807@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" , CCAMP , "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" Subject: Re: [CCAMP] Closing G.709 open issues X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 17:21:43 -0000 Daniele, Please see below: On 5/9/2013 12:57 PM, Daniele Ceccarelli wrote: > Hi Lou, > > Wrt point 1) (TSG) we have 2 options. > > 1. leave the TSG being inferred by the label length and propose new text (see below). > 2. add the TSG to the label. > > Either solutions work for me, i just want to share some thoughts raised during discussions with Sergio and Fred. > A. From an implementation point of view, in case of multi-stage muxing multiple label lookups are needed to infer the TSG > B. Future proofness: we all know that TSG=10Gbps will be defined shorthly. This might make the TSG infer from label length not feasible. > Sigh, I keep thinking we're "almost done" on 709 and another discussion pops up... So this is at least the third time we're discussing options 1 and 2. In the prior times, we've always agreed to follow 1. So I'll quote myself, from the last time around: Revising past decisions is fine if there's good cause, such as new information or issues identified/discovered... So let me ask, is there good cause to revisit this decision? > Again, for me both solutions 1. and 2. work, A. And B. might not be major issues. > > In case we go for 1. my proposed text is (feel free to amend): > > "Please note that the TSG of the HO ODUk can be inferred from the length of the label. > In those cases where there is no LMP imposing the TSG to be used between two ends of a link, > Such information can be inferred from the signaling. E.g. In a HO ODU link a label lenght value > Of 4 would indicate TSG equal to 2,5Gbps while a value of 8 would correspond to a 1.25Gbps TSG". Continuing in the case of 1, but how about: Please note that the TS granularity of a HO ODUk can be inferred from the length of the label. The values of 1, 4 and 16 indicate a TS granularity of 2.5Gps, while the values 2, 7, 32 and 80 indicate a TS granularity of 1.25Gps. Note that I added the length value of 1 based on the table on page 7 of the framework draft, but 1 isn't listed as a valid length value. One of these is wrong. (I didn't spend the time to figure out if the 1 needs to be added to valid list or should be dropped from the suggested text. Figured one of the authors would know this.) Thanks, Lou > > BR > Daniele > > > > >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: giovedì 9 maggio 2013 15.57 >> To: Fatai Zhang >> Cc: CCAMP; >> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; >> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org >> Subject: Re: Closing G.709 open issues >> >> >> Just to be clear to all: My mail summarized the results of >> discussions that occurred on the list whose results I believe >> are not reflected in the current document set. I identified 3 >> items, and hope I didn't miss anything from the ~200 related >> messages on the list. I'm not trying to change any >> conclusions, just ensure that they are documented. >> >> Fatai, >> >> See below for specific responses. >> >> On 5/9/2013 3:12 AM, Fatai Zhang wrote: >>> Hi Lou, >>> >>> For point 1), do you mean that you would like to have "TSG" field >>> (ie., explicit indication) in the label format? Or just change the >>> target text that you quoted? >>> >> >> This point was resolved in >> http://www.ietf.org/mail-archive/web/ccamp/current/msg14701.html >> to quote: >> On 3/21/2013 9:51 AM, Lou Berger wrote: >> > Daniele, >> ... >> > On 3/21/2013 9:34 AM, Daniele Ceccarelli wrote: >> >> Lou, >> >> >> >> OK. No changes to signaling re explicit indication of mapping >> >> and/or TSG in the label. >> > >> > I think it would be a good idea to add a comment on this in the >> > signaling document so that we don't have to revisit it yet again... >> > >> >>> If what you meant is the latter, could you provide some >> proposed text to refine it. >>> >> >> I suggest that the authors propose some text on the list for >> the WG to review. Given that the explicit indication issue >> was raised by one of the co-authors I suspect he can provide >> text that ensures the issue is covered. There's also some >> related text already on page 7 of the framework draft. If the >> authors are unable to come up with a proposal, let me know and >> I'll propose something to the list. >> >>> For point 2), the GPIDs have been grouped based on Table 15-8 in >>> G.709 (so it seems that some payload types in Table 15-8 are >> missed), >>> but I think you more like the 1:1 mapping between the GPID >> defined in >>> [SIGNALING] and Table 15-8. >> >> The only thing I'm asking for is to verify that it is possible >> to unambiguously signal the G.709 defined payload types with >> GMPLS. The authors are free to use any approach, e.g., 1:1 or >> n:1+other signaled information. >> >>> We will check and list all the ungrouped GPIDs. >>> >> >> If you think it's possible to indicate all G.709 defined >> payload types using the current "grouped" approach, that works >> for me. You just need to state such on the list. >> >> Perhaps it makes sense to just list how each PT in G.709 table >> 15-8 is represented as a good sanity check. Such a list might >> also be useful information to add to the draft. Here's a >> start at such a list. I've flagged the results of a spot >> check (i.e., I probably have missed >> something) of PTs for which I don't see an obvious mapping. >> >> G.709 >> Payload >> Type G-PID >> ------- ----- >> 0x01 ??? >> 0x02 >> 0x03 >> 0x04 >> 0x05 >> 0x06 >> 0x07 >> 0x08 >> 0x09 >> 0x0A >> 0x0B >> 0x0C >> 0x0D >> 0x0E >> 0x0F >> 0x10 >> 0x11 >> 0x12 ??? >> 0x13 ??? >> 0x14 ??? >> 0x15 ??? >> 0x16 ??? >> 0x17 ??? >> 0x18 ??? >> 0x19 ??? >> 0x1A >> 0x1B ??? >> 0x1C >> 0x20 >> 0x21 >> 0x55 Unused >> 0x66 Unused >> 0x80-0x8F ??? >> 0xFD ?? (Is this needed?) >> 0xFE ?? (Is this needed?) >> 0xFF Unused >> >> >> Thanks, >> Lou >> >>> >>> >>> >>> Best Regards >>> >>> Fatai >>> >>> >>> -----Original Message----- >>> From: Lou Berger [mailto:lberger@labn.net] >>> Sent: Thursday, May 09, 2013 12:53 AM >>> To: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; >>> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org >>> Subject: Closing G.709 open issues >>> >>> Authors/WG, >>> I think all would like to wrap up the 709 documents >> before Berlin. >>> To do this we need to: >>> 1) Ensure all discussed points have been resolved >>> 2) Hold a 2nd LC to ensure consensus on all changes since the 1st LC >>> 3) Capture the resolution of any comments made during 2. >>> >>> In reviewing the close to 200 mail messages on the documents >> since the >>> 1st LC was issued, I see only one a few points that are >> still missing, >>> and I'll cover these below. On a side note, as an >> experiment we'll be >>> tracking these issue via the tools issues page: >>> http://tools.ietf.org/wg/ccamp/trac/report/1 >>> >>> PLEASE reply to this message if you think there are other >>> points/discussions that haven't been addressed in the current set of >>> documents. Once this thread is closed, the 2nd LC will be initiated. >>> >>> The remaining items come from the tread with the final message >>> http://www.ietf.org/mail-archive/web/ccamp/current/msg14701.html >>> The message is from me in response to Daniele's summary of >> next steps, >>> and has the following unresolved actions: >>> >>> 1) No explicit indication of TSG in the label [SIGNALING] >>> >>> In signaling document section 6: Clarify related text to >> unambiguous >>> identify the relationship between label length and TSG. Possible >>> target text to change: >>> Note that the >>> Length field in the label format MAY be used to indicate the TS >>> type of the HO ODUk (i.e., TS granularity at 1.25Gbps or 2.5Gbps) >>> since the HO ODUk type can be known from IF_ID RSVP_HOP Object. In >>> some cases when there is no Link Management Protocol (LMP) or >>> routing to make the two end points of the link to know the TSG, >>> the TSG information used by another end can be deduced from the >>> label format. For example, for HO ODU2 link, the value of the >>> length filed will be 4 or 8, which indicates the TS granularity is >>> 2.5Gbps or 1.25Gbps, respectively. >>> >>> 2) Verify that the complete list of G-PIDs are defined [SIGNALING] >>> >>> In signaling document section 4, verify that all payload types >>> defined in G.709 (Summarized in Table 15-8) can be represented. >>> This issue can be resolved via an update or message to the list >>> stating that the verification took place. >>> >>> 3) Identification of hexadecimal representation in G.709 vs >>> decimal in GMPLS [INFO-MODEL] >>> >>> The authors had previously stated the intent to just make >> this clear >>> in the signaling document. I'd like to make an alternate proposal: >>> let's do the the obvious and have the documents simply use >> the normal >>> (IETF) convention of using a '0x' prefix anytime a >> hexadecimal value >>> is represented. I believe this means that only the info-model draft >>> needs to be updated. >>> >>> I believe that's the complete list. Again: >>> PLEASE reply to this message if you think there are other >>> points/discussions that haven't been addressed in the current set of >>> documents. >>> >>> Much thanks, >>> Lou >>> >>> >>> >>> >>> >> > > > From zhangfatai@huawei.com Thu May 9 18:42:12 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A2221F909A for ; Thu, 9 May 2013 18:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvpxuuGL75Xg for ; Thu, 9 May 2013 18:42:07 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A6E1A21F902D for ; Thu, 9 May 2013 18:42:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARF91939; Fri, 10 May 2013 01:41:59 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 10 May 2013 02:41:41 +0100 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 10 May 2013 02:41:55 +0100 Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.222]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.007; Fri, 10 May 2013 09:41:51 +0800 From: Fatai Zhang To: Lou Berger , Daniele Ceccarelli Thread-Topic: Closing G.709 open issues Thread-Index: AQHOTAyDmhSnK0jr+ESubR/xu8VPgpj8bQiw///u0ICAADKIAIAABpSAgAEN6tA= Date: Fri, 10 May 2013 01:41:51 +0000 Message-ID: References: <518A82D9.7080508@labn.net> <518BAB17.9090807@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> In-Reply-To: <518BDAFF.40706@labn.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" , "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" Subject: Re: [CCAMP] Closing G.709 open issues X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 01:42:12 -0000 Hi Lou, For point 1), "1" should be dropped and "7" should be corrected to "8" in y= our proposed text.=20 I hesitate to make a decision on either approach, I would like to defer to = the WG consensus. For point 2), I compared [G.709-2003] and [G.709-2012], and checked the GPI= Ds defined in [RFC4328], I think the following new GPIDs (values could be 5= 9-79) should be added (besides updating some GPIDs defined in RFC4328, like= 32,47,49-52): Value G-PID Type LSP Encoding Type ----- ---------- ----------------- 59(TBA) G.709 ODU-1.25G G.709 ODUk=20 60(TBA) G.709 ODU-any G.709 ODUk 61(TBA) PCS G.709 ODUk (k=3D0) 62(TBA) FC-1200 G.709 ODUk (k=3D2e) 63(TBA) eOPU2 G.709 ODUk (k=3D2) 64(TBA) STM-1 G.709 ODUk (k=3D0) 65(TBA) STM-4 G.709 ODUk (k=3D0) 66(TBA) FC-100 G.709 ODUk (k=3D0) 67(TBA) FC-200 G.709 ODUk (k=3D1) 68(TBA) FC-400 G.709 ODUflex 69(TBA) FC-800 G.709 ODUflex 70(TBA) IB SDR G.709 ODUflex 71(TBA) IB DDR G.709 ODUflex 72(TBA) IB QDR G.709 ODUflex 73(TBA) SDIa G.709 ODUk (k=3D0) 74(TBA) SDIb G.709 ODUk (k=3D1) 75(TBA) SDIc G.709 ODUk (k=3D1) 76(TBA) SDId G.709 ODUflex 77(TBA) SDIe G.709 ODUflex 78(TBA) SB/ESCON G.709 ODUk (k=3D0) 79(TBA) DVB_ASI G.709 ODUk (k=3D0) Best Regards Fatai -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Friday, May 10, 2013 1:21 AM To: Daniele Ceccarelli Cc: Fatai Zhang; CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.= org; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org Subject: Re: Closing G.709 open issues Daniele, Please see below: On 5/9/2013 12:57 PM, Daniele Ceccarelli wrote: > Hi Lou, >=20 > Wrt point 1) (TSG) we have 2 options. >=20 > 1. leave the TSG being inferred by the label length and propose new text = (see below). > 2. add the TSG to the label. >=20 > Either solutions work for me, i just want to share some thoughts raised d= uring discussions with Sergio and Fred. > A. From an implementation point of view, in case of multi-stage muxing mu= ltiple label lookups are needed to infer the TSG > B. Future proofness: we all know that TSG=3D10Gbps will be defined shorth= ly. This might make the TSG infer from label length not feasible. >=20 Sigh, I keep thinking we're "almost done" on 709 and another discussion pops up... So this is at least the third time we're discussing options 1 and 2. In the prior times, we've always agreed to follow 1. So I'll quote myself, from the last time around: Revising past decisions is fine if there's good cause, such as new information or issues identified/discovered... So let me ask, is there good cause to revisit this decision? > Again, for me both solutions 1. and 2. work, A. And B. might not be major= issues. >=20 > In case we go for 1. my proposed text is (feel free to amend): >=20 > "Please note that the TSG of the HO ODUk can be inferred from the length = of the label. > In those cases where there is no LMP imposing the TSG to be used between = two ends of a link, > Such information can be inferred from the signaling. E.g. In a HO ODU lin= k a label lenght value > Of 4 would indicate TSG equal to 2,5Gbps while a value of 8 would corresp= ond to a 1.25Gbps TSG". Continuing in the case of 1, but how about: Please note that the TS granularity of a HO ODUk can be inferred from the length of the label. The values of 1, 4 and 16 indicate a TS granularity of 2.5Gps, while the values 2, 7, 32 and 80 indicate a TS granularity of 1.25Gps. Note that I added the length value of 1 based on the table on page 7 of the framework draft, but 1 isn't listed as a valid length value. One of these is wrong. (I didn't spend the time to figure out if the 1 needs to be added to valid list or should be dropped from the suggested text. Figured one of the authors would know this.) Thanks, Lou >=20 > BR > Daniele >=20 >=20 >=20 >=20 >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net]=20 >> Sent: gioved=EC 9 maggio 2013 15.57 >> To: Fatai Zhang >> Cc: CCAMP;=20 >> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org;=20 >> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org >> Subject: Re: Closing G.709 open issues >> >> >> Just to be clear to all: My mail summarized the results of=20 >> discussions that occurred on the list whose results I believe=20 >> are not reflected in the current document set. I identified 3=20 >> items, and hope I didn't miss anything from the ~200 related=20 >> messages on the list. I'm not trying to change any=20 >> conclusions, just ensure that they are documented. >> >> Fatai, >> >> See below for specific responses. >> >> On 5/9/2013 3:12 AM, Fatai Zhang wrote: >>> Hi Lou, >>> >>> For point 1), do you mean that you would like to have "TSG" field=20 >>> (ie., explicit indication) in the label format? Or just change the=20 >>> target text that you quoted? >>> >> >> This point was resolved in >> http://www.ietf.org/mail-archive/web/ccamp/current/msg14701.html >> to quote: >> On 3/21/2013 9:51 AM, Lou Berger wrote: >> > Daniele, >> ... >> > On 3/21/2013 9:34 AM, Daniele Ceccarelli wrote: >> >> Lou, >> >> >> >> OK. No changes to signaling re explicit indication of mapping >> >> and/or TSG in the label. >> > >> > I think it would be a good idea to add a comment on this in the >> > signaling document so that we don't have to revisit it yet again... >> > >> >>> If what you meant is the latter, could you provide some=20 >> proposed text to refine it. >>> >> >> I suggest that the authors propose some text on the list for=20 >> the WG to review. Given that the explicit indication issue=20 >> was raised by one of the co-authors I suspect he can provide=20 >> text that ensures the issue is covered. There's also some=20 >> related text already on page 7 of the framework draft. If the=20 >> authors are unable to come up with a proposal, let me know and=20 >> I'll propose something to the list. >> >>> For point 2), the GPIDs have been grouped based on Table 15-8 in >>> G.709 (so it seems that some payload types in Table 15-8 are=20 >> missed),=20 >>> but I think you more like the 1:1 mapping between the GPID=20 >> defined in=20 >>> [SIGNALING] and Table 15-8. >> >> The only thing I'm asking for is to verify that it is possible=20 >> to unambiguously signal the G.709 defined payload types with=20 >> GMPLS. The authors are free to use any approach, e.g., 1:1 or=20 >> n:1+other signaled information. >> >>> We will check and list all the ungrouped GPIDs. >>> >> >> If you think it's possible to indicate all G.709 defined=20 >> payload types using the current "grouped" approach, that works=20 >> for me. You just need to state such on the list. >> >> Perhaps it makes sense to just list how each PT in G.709 table=20 >> 15-8 is represented as a good sanity check. Such a list might=20 >> also be useful information to add to the draft. Here's a=20 >> start at such a list. I've flagged the results of a spot=20 >> check (i.e., I probably have missed >> something) of PTs for which I don't see an obvious mapping. >> >> G.709 >> Payload >> Type G-PID >> ------- ----- >> 0x01 ??? >> 0x02 >> 0x03 >> 0x04 >> 0x05 >> 0x06 >> 0x07 >> 0x08 >> 0x09 >> 0x0A >> 0x0B >> 0x0C >> 0x0D >> 0x0E >> 0x0F >> 0x10 >> 0x11 >> 0x12 ??? >> 0x13 ??? >> 0x14 ??? >> 0x15 ??? >> 0x16 ??? >> 0x17 ??? >> 0x18 ??? >> 0x19 ??? >> 0x1A >> 0x1B ??? >> 0x1C >> 0x20 >> 0x21 >> 0x55 Unused >> 0x66 Unused >> 0x80-0x8F ??? >> 0xFD ?? (Is this needed?) >> 0xFE ?? (Is this needed?) >> 0xFF Unused >> >> >> Thanks, >> Lou >> >>> >>> >>> >>> Best Regards >>> >>> Fatai >>> >>> >>> -----Original Message----- >>> From: Lou Berger [mailto:lberger@labn.net] >>> Sent: Thursday, May 09, 2013 12:53 AM >>> To: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org;=20 >>> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org >>> Subject: Closing G.709 open issues >>> >>> Authors/WG, >>> I think all would like to wrap up the 709 documents=20 >> before Berlin. =20 >>> To do this we need to: >>> 1) Ensure all discussed points have been resolved >>> 2) Hold a 2nd LC to ensure consensus on all changes since the 1st LC >>> 3) Capture the resolution of any comments made during 2. >>> >>> In reviewing the close to 200 mail messages on the documents=20 >> since the=20 >>> 1st LC was issued, I see only one a few points that are=20 >> still missing,=20 >>> and I'll cover these below. On a side note, as an=20 >> experiment we'll be=20 >>> tracking these issue via the tools issues page: >>> http://tools.ietf.org/wg/ccamp/trac/report/1 >>> >>> PLEASE reply to this message if you think there are other=20 >>> points/discussions that haven't been addressed in the current set of=20 >>> documents. Once this thread is closed, the 2nd LC will be initiated. >>> >>> The remaining items come from the tread with the final message=20 >>> http://www.ietf.org/mail-archive/web/ccamp/current/msg14701.html >>> The message is from me in response to Daniele's summary of=20 >> next steps,=20 >>> and has the following unresolved actions: >>> >>> 1) No explicit indication of TSG in the label [SIGNALING] >>> >>> In signaling document section 6: Clarify related text to=20 >> unambiguous >>> identify the relationship between label length and TSG. Possible >>> target text to change: >>> Note that the >>> Length field in the label format MAY be used to indicate the TS >>> type of the HO ODUk (i.e., TS granularity at 1.25Gbps or 2.5Gbps) >>> since the HO ODUk type can be known from IF_ID RSVP_HOP Object. In >>> some cases when there is no Link Management Protocol (LMP) or >>> routing to make the two end points of the link to know the TSG, >>> the TSG information used by another end can be deduced from the >>> label format. For example, for HO ODU2 link, the value of the >>> length filed will be 4 or 8, which indicates the TS granularity is >>> 2.5Gbps or 1.25Gbps, respectively. >>> >>> 2) Verify that the complete list of G-PIDs are defined [SIGNALING] >>> >>> In signaling document section 4, verify that all payload types >>> defined in G.709 (Summarized in Table 15-8) can be represented. >>> This issue can be resolved via an update or message to the list >>> stating that the verification took place. >>> >>> 3) Identification of hexadecimal representation in G.709 vs >>> decimal in GMPLS [INFO-MODEL] >>> >>> The authors had previously stated the intent to just make=20 >> this clear >>> in the signaling document. I'd like to make an alternate proposal: >>> let's do the the obvious and have the documents simply use=20 >> the normal >>> (IETF) convention of using a '0x' prefix anytime a=20 >> hexadecimal value >>> is represented. I believe this means that only the info-model draft >>> needs to be updated. >>> >>> I believe that's the complete list. Again: >>> PLEASE reply to this message if you think there are other=20 >>> points/discussions that haven't been addressed in the current set of=20 >>> documents. >>> >>> Much thanks, >>> Lou >>> >>> >>> >>> >>> >> >=20 >=20 >=20 From daniele.ceccarelli@ericsson.com Thu May 9 23:58:07 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F62E21F8E2C for ; Thu, 9 May 2013 23:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahzKzseU4Tqi for ; Thu, 9 May 2013 23:58:02 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id A476C21F8DCF for ; Thu, 9 May 2013 23:58:01 -0700 (PDT) X-AuditID: c1b4fb2d-b7f536d000006e05-f7-518c9a78fa75 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 38.B7.28165.87A9C815; Fri, 10 May 2013 08:58:00 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.55]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0328.009; Fri, 10 May 2013 08:58:00 +0200 From: Daniele Ceccarelli To: Lou Berger Thread-Topic: Closing G.709 open issues Thread-Index: AQHOTAyAugJRODS18Eas2l6+kjNWaZj8T3QAgABw+YCAAExsIP//7LCAgAEEvuA= Date: Fri, 10 May 2013 06:57:59 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE480C68CE@ESESSMB301.ericsson.se> References: <518A82D9.7080508@labn.net> <518BAB17.9090807@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> In-Reply-To: <518BDAFF.40706@labn.net> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUyM+JvrW7FrJ5Ag/m3ZCyezLnBYrF19n1m iymzv7NYdDS/ZbHoaz7P6sDq0XLkLavHkiU/mTw+bGpm8/hy+TNbAEsUl01Kak5mWWqRvl0C V8aGy1PZCzrCKiZ8aWZsYHzn1MXIwSEhYCKxqLe4i5ETyBSTuHBvPVsXIxeHkMBhRoljE9Yx QziLGSXa/q5mAmlgE7CSeHLIB6RBREBR4uvHRUwgNcwCy5kkDjz6zAiSEBZQk9j79gEjRJG6 RO/WRVC2n8TL429ZQGwWAVWJqxcus4LYvALeEjOfbmKHWPaeUeLBwoVgRZxAgzpOXQArYhSQ lZiwG2IQs4C4xK0n85kgzhaQWLLnPDOELSrx8vE/VghbUeLq9OVMEPV6EjemTmGDsLUlli18 zQyxWFDi5MwnLBMYxWYhGTsLScssJC2zkLQsYGRZxciem5iZk15uuIkRGFcHt/zW3cF46pzI IUZpDhYlcd4krsZAIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYw9n/7eb7j1bKGl1MH9Fd96 v/0WaNun2ef+/lQX97W71xRe7VujwST36r3e+Vr55/PFuB9PnR27yUlAxGGu7v3tta3l5ocL ps81L88TPSWuwrf22iXLrJtiyzmSIjcqTYieNrup+3HY/PWtXknux8+bR9mUSn9ZfUctpIf9 7PKi4AdbH291esahxFKckWioxVxUnAgAiG/WbXkCAAA= Cc: "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" , CCAMP , "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" Subject: Re: [CCAMP] Closing G.709 open issues X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 06:58:08 -0000 Lou, I want to close the OTN work more than anyone else :-) I just expressed loud thinking due to last evolution in OTN data plane, but= i said, no major issue and i'm fine with 1. Let's go with 1. I'm fine with the text you're proposing. Thanks Daniele >-----Original Message----- >From: Lou Berger [mailto:lberger@labn.net]=20 >Sent: gioved=EC 9 maggio 2013 19.21 >To: Daniele Ceccarelli >Cc: Fatai Zhang; CCAMP;=20 >draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org;=20 >draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org >Subject: Re: Closing G.709 open issues > >Daniele, > Please see below: > >On 5/9/2013 12:57 PM, Daniele Ceccarelli wrote: >> Hi Lou, >>=20 >> Wrt point 1) (TSG) we have 2 options. >>=20 >> 1. leave the TSG being inferred by the label length and=20 >propose new text (see below). >> 2. add the TSG to the label. >>=20 >> Either solutions work for me, i just want to share some=20 >thoughts raised during discussions with Sergio and Fred. >> A. From an implementation point of view, in case of=20 >multi-stage muxing=20 >> multiple label lookups are needed to infer the TSG B. Future=20 >proofness: we all know that TSG=3D10Gbps will be defined=20 >shorthly. This might make the TSG infer from label length not feasible. >>=20 > >Sigh, I keep thinking we're "almost done" on 709 and another=20 >discussion pops up... > >So this is at least the third time we're discussing options 1=20 >and 2. In the prior times, we've always agreed to follow 1. =20 >So I'll quote myself, from the last time around: > Revising past decisions is fine if there's good cause, such as new > information or issues identified/discovered... > >So let me ask, is there good cause to revisit this decision? > >> Again, for me both solutions 1. and 2. work, A. And B. might=20 >not be major issues. >>=20 >> In case we go for 1. my proposed text is (feel free to amend): >>=20 >> "Please note that the TSG of the HO ODUk can be inferred=20 >from the length of the label. >> In those cases where there is no LMP imposing the TSG to be used=20 >> between two ends of a link, Such information can be inferred=20 >from the=20 >> signaling. E.g. In a HO ODU link a label lenght value Of 4=20 >would indicate TSG equal to 2,5Gbps while a value of 8 would=20 >correspond to a 1.25Gbps TSG". > >Continuing in the case of 1, but how about: > > Please note that the TS granularity of a HO ODUk can be inferred from > the length of the label. The values of 1, 4 and 16 indicate a TS > granularity of 2.5Gps, while the values 2, 7, 32 and 80 indicate a TS > granularity of 1.25Gps. > >Note that I added the length value of 1 based on the table on=20 >page 7 of the framework draft, but 1 isn't listed as a valid=20 >length value. One of these is wrong. (I didn't spend the time=20 >to figure out if the 1 needs to be added to valid list or=20 >should be dropped from the suggested text. >Figured one of the authors would know this.) > >Thanks, >Lou > >>=20 >> BR >> Daniele >>=20 >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: Lou Berger [mailto:lberger@labn.net] >>> Sent: gioved=EC 9 maggio 2013 15.57 >>> To: Fatai Zhang >>> Cc: CCAMP; >>> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; >>> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org >>> Subject: Re: Closing G.709 open issues >>> >>> >>> Just to be clear to all: My mail summarized the results of=20 >>> discussions that occurred on the list whose results I believe=20 >>> are not reflected in the current document set. I identified 3=20 >>> items, and hope I didn't miss anything from the ~200 related=20 >>> messages on the list. I'm not trying to change any=20 >>> conclusions, just ensure that they are documented. >>> >>> Fatai, >>> >>> See below for specific responses. >>> >>> On 5/9/2013 3:12 AM, Fatai Zhang wrote: >>>> Hi Lou, >>>> >>>> For point 1), do you mean that you would like to have "TSG" field=20 >>>> (ie., explicit indication) in the label format? Or just change the=20 >>>> target text that you quoted? >>>> >>> >>> This point was resolved in >>> http://www.ietf.org/mail-archive/web/ccamp/current/msg14701.html >>> to quote: >>> On 3/21/2013 9:51 AM, Lou Berger wrote: >>> > Daniele, >>> ... >>> > On 3/21/2013 9:34 AM, Daniele Ceccarelli wrote: >>> >> Lou, >>> >> >>> >> OK. No changes to signaling re explicit indication of mapping >>> >> and/or TSG in the label. >>> > >>> > I think it would be a good idea to add a comment on this in the >>> > signaling document so that we don't have to revisit it=20 >yet again... >>> > >>> >>>> If what you meant is the latter, could you provide some=20 >>> proposed text to refine it. >>>> >>> >>> I suggest that the authors propose some text on the list for=20 >>> the WG to review. Given that the explicit indication issue=20 >>> was raised by one of the co-authors I suspect he can provide=20 >>> text that ensures the issue is covered. There's also some=20 >>> related text already on page 7 of the framework draft. If the=20 >>> authors are unable to come up with a proposal, let me know and=20 >>> I'll propose something to the list. >>> >>>> For point 2), the GPIDs have been grouped based on Table 15-8 in >>>> G.709 (so it seems that some payload types in Table 15-8 are=20 >>> missed),=20 >>>> but I think you more like the 1:1 mapping between the GPID=20 >>> defined in=20 >>>> [SIGNALING] and Table 15-8. >>> >>> The only thing I'm asking for is to verify that it is possible=20 >>> to unambiguously signal the G.709 defined payload types with=20 >>> GMPLS. The authors are free to use any approach, e.g., 1:1 or=20 >>> n:1+other signaled information. >>> >>>> We will check and list all the ungrouped GPIDs. >>>> >>> >>> If you think it's possible to indicate all G.709 defined=20 >>> payload types using the current "grouped" approach, that works=20 >>> for me. You just need to state such on the list. >>> >>> Perhaps it makes sense to just list how each PT in G.709 table=20 >>> 15-8 is represented as a good sanity check. Such a list might=20 >>> also be useful information to add to the draft. Here's a=20 >>> start at such a list. I've flagged the results of a spot=20 >>> check (i.e., I probably have missed >>> something) of PTs for which I don't see an obvious mapping. >>> >>> G.709 >>> Payload >>> Type G-PID >>> ------- ----- >>> 0x01 ??? >>> 0x02 >>> 0x03 >>> 0x04 >>> 0x05 >>> 0x06 >>> 0x07 >>> 0x08 >>> 0x09 >>> 0x0A >>> 0x0B >>> 0x0C >>> 0x0D >>> 0x0E >>> 0x0F >>> 0x10 >>> 0x11 >>> 0x12 ??? >>> 0x13 ??? >>> 0x14 ??? >>> 0x15 ??? >>> 0x16 ??? >>> 0x17 ??? >>> 0x18 ??? >>> 0x19 ??? >>> 0x1A >>> 0x1B ??? >>> 0x1C >>> 0x20 >>> 0x21 >>> 0x55 Unused >>> 0x66 Unused >>> 0x80-0x8F ??? >>> 0xFD ?? (Is this needed?) >>> 0xFE ?? (Is this needed?) >>> 0xFF Unused >>> >>> >>> Thanks, >>> Lou >>> >>>> >>>> >>>> >>>> Best Regards >>>> >>>> Fatai >>>> >>>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: Thursday, May 09, 2013 12:53 AM >>>> To: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org;=20 >>>> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org >>>> Subject: Closing G.709 open issues >>>> >>>> Authors/WG, >>>> I think all would like to wrap up the 709 documents=20 >>> before Berlin. =20 >>>> To do this we need to: >>>> 1) Ensure all discussed points have been resolved >>>> 2) Hold a 2nd LC to ensure consensus on all changes since=20 >the 1st LC >>>> 3) Capture the resolution of any comments made during 2. >>>> >>>> In reviewing the close to 200 mail messages on the documents=20 >>> since the=20 >>>> 1st LC was issued, I see only one a few points that are=20 >>> still missing,=20 >>>> and I'll cover these below. On a side note, as an=20 >>> experiment we'll be=20 >>>> tracking these issue via the tools issues page: >>>> http://tools.ietf.org/wg/ccamp/trac/report/1 >>>> >>>> PLEASE reply to this message if you think there are other=20 >>>> points/discussions that haven't been addressed in the=20 >current set of=20 >>>> documents. Once this thread is closed, the 2nd LC will be=20 >initiated. >>>> >>>> The remaining items come from the tread with the final message=20 >>>> http://www.ietf.org/mail-archive/web/ccamp/current/msg14701.html >>>> The message is from me in response to Daniele's summary of=20 >>> next steps,=20 >>>> and has the following unresolved actions: >>>> >>>> 1) No explicit indication of TSG in the label [SIGNALING] >>>> >>>> In signaling document section 6: Clarify related text to=20 >>> unambiguous >>>> identify the relationship between label length and TSG. Possible >>>> target text to change: >>>> Note that the >>>> Length field in the label format MAY be used to indicate the TS >>>> type of the HO ODUk (i.e., TS granularity at 1.25Gbps=20 >or 2.5Gbps) >>>> since the HO ODUk type can be known from IF_ID RSVP_HOP=20 >Object. In >>>> some cases when there is no Link Management Protocol (LMP) or >>>> routing to make the two end points of the link to know the TSG, >>>> the TSG information used by another end can be deduced from the >>>> label format. For example, for HO ODU2 link, the value of the >>>> length filed will be 4 or 8, which indicates the TS=20 >granularity is >>>> 2.5Gbps or 1.25Gbps, respectively. >>>> >>>> 2) Verify that the complete list of G-PIDs are defined [SIGNALING] >>>> >>>> In signaling document section 4, verify that all payload types >>>> defined in G.709 (Summarized in Table 15-8) can be represented. >>>> This issue can be resolved via an update or message to the list >>>> stating that the verification took place. >>>> >>>> 3) Identification of hexadecimal representation in G.709 vs >>>> decimal in GMPLS [INFO-MODEL] >>>> >>>> The authors had previously stated the intent to just make=20 >>> this clear >>>> in the signaling document. I'd like to make an=20 >alternate proposal: >>>> let's do the the obvious and have the documents simply use=20 >>> the normal >>>> (IETF) convention of using a '0x' prefix anytime a=20 >>> hexadecimal value >>>> is represented. I believe this means that only the=20 >info-model draft >>>> needs to be updated. >>>> >>>> I believe that's the complete list. Again: >>>> PLEASE reply to this message if you think there are other=20 >>>> points/discussions that haven't been addressed in the=20 >current set of=20 >>>> documents. >>>> >>>> Much thanks, >>>> Lou >>>> >>>> >>>> >>>> >>>> >>> >>=20 >>=20 >>=20 >= From lberger@labn.net Fri May 10 07:18:31 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD1FB21F8B2B for ; Fri, 10 May 2013 07:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.172 X-Spam-Level: X-Spam-Status: No, score=-102.172 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WSUtc4CTLjDj for ; Fri, 10 May 2013 07:18:27 -0700 (PDT) Received: from oproxy14-pub.unifiedlayer.com (oproxy14-pub.unifiedlayer.com [67.222.51.224]) by ietfa.amsl.com (Postfix) with SMTP id 7D6C621F8B33 for ; Fri, 10 May 2013 07:18:27 -0700 (PDT) Received: (qmail 5630 invoked by uid 0); 10 May 2013 12:50:48 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy14.unifiedlayer.com with SMTP; 10 May 2013 12:50:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=3LTku8f93At3OOMFfkVF/a96OJkrW5Kb7YJF8+cRZsU=; b=1xn14AOx7UAYouTV/EdHBRTZkyNhtcueNO/gaP6oUOMthRMXNnwLQ2C+Z1yk3IxWSnJaKHV/bBfO558ZbUZO6DUo11yOwAOfRnBrbMfRzJPbl/jDVSZ8EvbCHZ7/McAo; Received: from box313.bluehost.com ([69.89.31.113]:50528 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Uamme-0006pt-9l; Fri, 10 May 2013 06:50:48 -0600 Message-ID: <518CED28.30303@labn.net> Date: Fri, 10 May 2013 08:50:48 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Fatai Zhang References: <518A82D9.7080508@labn.net> <518BAB17.9090807@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" , CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" Subject: Re: [CCAMP] Closing G.709 open issues X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 14:18:31 -0000 On 5/9/2013 9:41 PM, Fatai Zhang wrote: > Hi Lou, > > For point 1), "1" should be dropped and "7" should be corrected to "8" in your proposed text. Great. > > I hesitate to make a decision on either approach, I would like to defer to the WG consensus. > I believe we already have a consensus position. The question in my mail was do we need to revisit it. I take your response as a no. (thank you!) > For point 2), I compared [G.709-2003] and [G.709-2012], and checked > the GPIDs defined in [RFC4328], I think the following new GPIDs > (values could be 59-79) should be added (besides updating some GPIDs > defined in RFC4328, like 32,47,49-52): > I suggest going through the full PT list and identifying them in the table (as I started in my last message) so that there is no confusion in implementations. In the list below it looks like you have moved away from the 'grouped G-PID' approach. Is there a reason for this change? Refer to http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parameters.xml in subsequent comments. > Value G-PID Type LSP Encoding Type > ----- ---------- ----------------- > 59(TBA) G.709 ODU-1.25G G.709 ODUk > 60(TBA) G.709 ODU-any G.709 ODUk Do you really need 3 G-PID types for an ODU (I thought TSG was already covered)? > 61(TBA) PCS G.709 ODUk (k=0) > 62(TBA) FC-1200 G.709 ODUk (k=2e) Why not us existing G-PID 58? > 63(TBA) eOPU2 G.709 ODUk (k=2) > 64(TBA) STM-1 G.709 ODUk (k=0) > 65(TBA) STM-4 G.709 ODUk (k=0) Why not us existing G-PID 34? > 66(TBA) FC-100 G.709 ODUk (k=0) > 67(TBA) FC-200 G.709 ODUk (k=1) > 68(TBA) FC-400 G.709 ODUflex > 69(TBA) FC-800 G.709 ODUflex Why not us existing G-PID 58? > 70(TBA) IB SDR G.709 ODUflex > 71(TBA) IB DDR G.709 ODUflex > 72(TBA) IB QDR G.709 ODUflex Can these be one value with rate implying SDR/DDR/QDR? > 73(TBA) SDIa G.709 ODUk (k=0) > 74(TBA) SDIb G.709 ODUk (k=1) > 75(TBA) SDIc G.709 ODUk (k=1) > 76(TBA) SDId G.709 ODUflex > 77(TBA) SDIe G.709 ODUflex Can these be one value with rate implying a-e? > 78(TBA) SB/ESCON G.709 ODUk (k=0) Why not us existing G-PID 56? > 79(TBA) DVB_ASI G.709 ODUk (k=0) > > > > Thanks, Lou > > Best Regards > > Fatai > > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Friday, May 10, 2013 1:21 AM > To: Daniele Ceccarelli > Cc: Fatai Zhang; CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org > Subject: Re: Closing G.709 open issues > > Daniele, > Please see below: > > On 5/9/2013 12:57 PM, Daniele Ceccarelli wrote: >> Hi Lou, >> >> Wrt point 1) (TSG) we have 2 options. >> >> 1. leave the TSG being inferred by the label length and propose new text (see below). >> 2. add the TSG to the label. >> >> Either solutions work for me, i just want to share some thoughts raised during discussions with Sergio and Fred. >> A. From an implementation point of view, in case of multi-stage muxing multiple label lookups are needed to infer the TSG >> B. Future proofness: we all know that TSG=10Gbps will be defined shorthly. This might make the TSG infer from label length not feasible. >> > > Sigh, I keep thinking we're "almost done" on 709 and another discussion > pops up... > > So this is at least the third time we're discussing options 1 and 2. In > the prior times, we've always agreed to follow 1. So I'll quote myself, > from the last time around: > Revising past decisions is fine if there's good cause, such as new > information or issues identified/discovered... > > So let me ask, is there good cause to revisit this decision? > >> Again, for me both solutions 1. and 2. work, A. And B. might not be major issues. >> >> In case we go for 1. my proposed text is (feel free to amend): >> >> "Please note that the TSG of the HO ODUk can be inferred from the length of the label. >> In those cases where there is no LMP imposing the TSG to be used between two ends of a link, >> Such information can be inferred from the signaling. E.g. In a HO ODU link a label lenght value >> Of 4 would indicate TSG equal to 2,5Gbps while a value of 8 would correspond to a 1.25Gbps TSG". > > Continuing in the case of 1, but how about: > > Please note that the TS granularity of a HO ODUk can be inferred from > the length of the label. The values of 1, 4 and 16 indicate a TS > granularity of 2.5Gps, while the values 2, 7, 32 and 80 indicate a TS > granularity of 1.25Gps. > > Note that I added the length value of 1 based on the table on page 7 of > the framework draft, but 1 isn't listed as a valid length value. One of > these is wrong. (I didn't spend the time to figure out if the 1 needs to > be added to valid list or should be dropped from the suggested text. > Figured one of the authors would know this.) > > Thanks, > Lou > >> >> BR >> Daniele >> >> >> >> >>> -----Original Message----- >>> From: Lou Berger [mailto:lberger@labn.net] >>> Sent: giovedì 9 maggio 2013 15.57 >>> To: Fatai Zhang >>> Cc: CCAMP; >>> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; >>> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org >>> Subject: Re: Closing G.709 open issues >>> >>> >>> Just to be clear to all: My mail summarized the results of >>> discussions that occurred on the list whose results I believe >>> are not reflected in the current document set. I identified 3 >>> items, and hope I didn't miss anything from the ~200 related >>> messages on the list. I'm not trying to change any >>> conclusions, just ensure that they are documented. >>> >>> Fatai, >>> >>> See below for specific responses. >>> >>> On 5/9/2013 3:12 AM, Fatai Zhang wrote: >>>> Hi Lou, >>>> >>>> For point 1), do you mean that you would like to have "TSG" field >>>> (ie., explicit indication) in the label format? Or just change the >>>> target text that you quoted? >>>> >>> >>> This point was resolved in >>> http://www.ietf.org/mail-archive/web/ccamp/current/msg14701.html >>> to quote: >>> On 3/21/2013 9:51 AM, Lou Berger wrote: >>> > Daniele, >>> ... >>> > On 3/21/2013 9:34 AM, Daniele Ceccarelli wrote: >>> >> Lou, >>> >> >>> >> OK. No changes to signaling re explicit indication of mapping >>> >> and/or TSG in the label. >>> > >>> > I think it would be a good idea to add a comment on this in the >>> > signaling document so that we don't have to revisit it yet again... >>> > >>> >>>> If what you meant is the latter, could you provide some >>> proposed text to refine it. >>>> >>> >>> I suggest that the authors propose some text on the list for >>> the WG to review. Given that the explicit indication issue >>> was raised by one of the co-authors I suspect he can provide >>> text that ensures the issue is covered. There's also some >>> related text already on page 7 of the framework draft. If the >>> authors are unable to come up with a proposal, let me know and >>> I'll propose something to the list. >>> >>>> For point 2), the GPIDs have been grouped based on Table 15-8 in >>>> G.709 (so it seems that some payload types in Table 15-8 are >>> missed), >>>> but I think you more like the 1:1 mapping between the GPID >>> defined in >>>> [SIGNALING] and Table 15-8. >>> >>> The only thing I'm asking for is to verify that it is possible >>> to unambiguously signal the G.709 defined payload types with >>> GMPLS. The authors are free to use any approach, e.g., 1:1 or >>> n:1+other signaled information. >>> >>>> We will check and list all the ungrouped GPIDs. >>>> >>> >>> If you think it's possible to indicate all G.709 defined >>> payload types using the current "grouped" approach, that works >>> for me. You just need to state such on the list. >>> >>> Perhaps it makes sense to just list how each PT in G.709 table >>> 15-8 is represented as a good sanity check. Such a list might >>> also be useful information to add to the draft. Here's a >>> start at such a list. I've flagged the results of a spot >>> check (i.e., I probably have missed >>> something) of PTs for which I don't see an obvious mapping. >>> >>> G.709 >>> Payload >>> Type G-PID >>> ------- ----- >>> 0x01 ??? >>> 0x02 >>> 0x03 >>> 0x04 >>> 0x05 >>> 0x06 >>> 0x07 >>> 0x08 >>> 0x09 >>> 0x0A >>> 0x0B >>> 0x0C >>> 0x0D >>> 0x0E >>> 0x0F >>> 0x10 >>> 0x11 >>> 0x12 ??? >>> 0x13 ??? >>> 0x14 ??? >>> 0x15 ??? >>> 0x16 ??? >>> 0x17 ??? >>> 0x18 ??? >>> 0x19 ??? >>> 0x1A >>> 0x1B ??? >>> 0x1C >>> 0x20 >>> 0x21 >>> 0x55 Unused >>> 0x66 Unused >>> 0x80-0x8F ??? >>> 0xFD ?? (Is this needed?) >>> 0xFE ?? (Is this needed?) >>> 0xFF Unused >>> >>> >>> Thanks, >>> Lou >>> >>>> >>>> >>>> >>>> Best Regards >>>> >>>> Fatai >>>> >>>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: Thursday, May 09, 2013 12:53 AM >>>> To: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; >>>> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org >>>> Subject: Closing G.709 open issues >>>> >>>> Authors/WG, >>>> I think all would like to wrap up the 709 documents >>> before Berlin. >>>> To do this we need to: >>>> 1) Ensure all discussed points have been resolved >>>> 2) Hold a 2nd LC to ensure consensus on all changes since the 1st LC >>>> 3) Capture the resolution of any comments made during 2. >>>> >>>> In reviewing the close to 200 mail messages on the documents >>> since the >>>> 1st LC was issued, I see only one a few points that are >>> still missing, >>>> and I'll cover these below. On a side note, as an >>> experiment we'll be >>>> tracking these issue via the tools issues page: >>>> http://tools.ietf.org/wg/ccamp/trac/report/1 >>>> >>>> PLEASE reply to this message if you think there are other >>>> points/discussions that haven't been addressed in the current set of >>>> documents. Once this thread is closed, the 2nd LC will be initiated. >>>> >>>> The remaining items come from the tread with the final message >>>> http://www.ietf.org/mail-archive/web/ccamp/current/msg14701.html >>>> The message is from me in response to Daniele's summary of >>> next steps, >>>> and has the following unresolved actions: >>>> >>>> 1) No explicit indication of TSG in the label [SIGNALING] >>>> >>>> In signaling document section 6: Clarify related text to >>> unambiguous >>>> identify the relationship between label length and TSG. Possible >>>> target text to change: >>>> Note that the >>>> Length field in the label format MAY be used to indicate the TS >>>> type of the HO ODUk (i.e., TS granularity at 1.25Gbps or 2.5Gbps) >>>> since the HO ODUk type can be known from IF_ID RSVP_HOP Object. In >>>> some cases when there is no Link Management Protocol (LMP) or >>>> routing to make the two end points of the link to know the TSG, >>>> the TSG information used by another end can be deduced from the >>>> label format. For example, for HO ODU2 link, the value of the >>>> length filed will be 4 or 8, which indicates the TS granularity is >>>> 2.5Gbps or 1.25Gbps, respectively. >>>> >>>> 2) Verify that the complete list of G-PIDs are defined [SIGNALING] >>>> >>>> In signaling document section 4, verify that all payload types >>>> defined in G.709 (Summarized in Table 15-8) can be represented. >>>> This issue can be resolved via an update or message to the list >>>> stating that the verification took place. >>>> >>>> 3) Identification of hexadecimal representation in G.709 vs >>>> decimal in GMPLS [INFO-MODEL] >>>> >>>> The authors had previously stated the intent to just make >>> this clear >>>> in the signaling document. I'd like to make an alternate proposal: >>>> let's do the the obvious and have the documents simply use >>> the normal >>>> (IETF) convention of using a '0x' prefix anytime a >>> hexadecimal value >>>> is represented. I believe this means that only the info-model draft >>>> needs to be updated. >>>> >>>> I believe that's the complete list. Again: >>>> PLEASE reply to this message if you think there are other >>>> points/discussions that haven't been addressed in the current set of >>>> documents. >>>> >>>> Much thanks, >>>> Lou >>>> >>>> >>>> >>>> >>>> >>> >> >> >> > > > > From lberger@labn.net Fri May 10 07:20:29 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18B1321F8CEC for ; Fri, 10 May 2013 07:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.181 X-Spam-Level: X-Spam-Status: No, score=-102.181 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WILT8qWhJttj for ; Fri, 10 May 2013 07:20:21 -0700 (PDT) Received: from oproxy14-pub.unifiedlayer.com (oproxy14-pub.unifiedlayer.com [67.222.51.224]) by ietfa.amsl.com (Postfix) with SMTP id 1A2A921F8CB4 for ; Fri, 10 May 2013 07:20:21 -0700 (PDT) Received: (qmail 15368 invoked by uid 0); 10 May 2013 12:53:32 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy14.unifiedlayer.com with SMTP; 10 May 2013 12:53:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=h16x4gCXaZvIUVJtMFc5la7jvOXm2ByBtezlBIJ/bXU=; b=qQQFDDENJc5QE1DIxJQLnBUF1Zyqx1NziwxQh/7WJzXOoG17D5A30kB1fa6TQrHp89HSyVD3iMYA9hHad3ji8tDWucfFAy1DTkONLTf5yggiRar21o5zZSXCG3pys6+i; Received: from box313.bluehost.com ([69.89.31.113]:50886 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UampI-0008VL-8A; Fri, 10 May 2013 06:53:32 -0600 Message-ID: <518CEDCC.7060904@labn.net> Date: Fri, 10 May 2013 08:53:32 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Daniele Ceccarelli References: <518A82D9.7080508@labn.net> <518BAB17.9090807@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C68CE@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE480C68CE@ESESSMB301.ericsson.se> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" , CCAMP , "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" Subject: Re: [CCAMP] Closing G.709 open issues X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 14:20:31 -0000 Daniele, Most excellent! Once the three open items are addressed (by 2 updated drafts) we'll be ready for the second LC. Lou On 5/10/2013 2:57 AM, Daniele Ceccarelli wrote: > Lou, > > I want to close the OTN work more than anyone else :-) > I just expressed loud thinking due to last evolution in OTN data plane, but i said, no major issue and i'm fine with 1. Let's go with 1. > > I'm fine with the text you're proposing. > > Thanks > Daniele > >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: giovedì 9 maggio 2013 19.21 >> To: Daniele Ceccarelli >> Cc: Fatai Zhang; CCAMP; >> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; >> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org >> Subject: Re: Closing G.709 open issues >> >> Daniele, >> Please see below: >> >> On 5/9/2013 12:57 PM, Daniele Ceccarelli wrote: >>> Hi Lou, >>> >>> Wrt point 1) (TSG) we have 2 options. >>> >>> 1. leave the TSG being inferred by the label length and >> propose new text (see below). >>> 2. add the TSG to the label. >>> >>> Either solutions work for me, i just want to share some >> thoughts raised during discussions with Sergio and Fred. >>> A. From an implementation point of view, in case of >> multi-stage muxing >>> multiple label lookups are needed to infer the TSG B. Future >> proofness: we all know that TSG=10Gbps will be defined >> shorthly. This might make the TSG infer from label length not feasible. >>> >> >> Sigh, I keep thinking we're "almost done" on 709 and another >> discussion pops up... >> >> So this is at least the third time we're discussing options 1 >> and 2. In the prior times, we've always agreed to follow 1. >> So I'll quote myself, from the last time around: >> Revising past decisions is fine if there's good cause, such as new >> information or issues identified/discovered... >> >> So let me ask, is there good cause to revisit this decision? >> >>> Again, for me both solutions 1. and 2. work, A. And B. might >> not be major issues. >>> >>> In case we go for 1. my proposed text is (feel free to amend): >>> >>> "Please note that the TSG of the HO ODUk can be inferred >>from the length of the label. >>> In those cases where there is no LMP imposing the TSG to be used >>> between two ends of a link, Such information can be inferred >>from the >>> signaling. E.g. In a HO ODU link a label lenght value Of 4 >> would indicate TSG equal to 2,5Gbps while a value of 8 would >> correspond to a 1.25Gbps TSG". >> >> Continuing in the case of 1, but how about: >> >> Please note that the TS granularity of a HO ODUk can be inferred from >> the length of the label. The values of 1, 4 and 16 indicate a TS >> granularity of 2.5Gps, while the values 2, 7, 32 and 80 indicate a TS >> granularity of 1.25Gps. >> >> Note that I added the length value of 1 based on the table on >> page 7 of the framework draft, but 1 isn't listed as a valid >> length value. One of these is wrong. (I didn't spend the time >> to figure out if the 1 needs to be added to valid list or >> should be dropped from the suggested text. >> Figured one of the authors would know this.) >> >> Thanks, >> Lou >> >>> >>> BR >>> Daniele >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: giovedì 9 maggio 2013 15.57 >>>> To: Fatai Zhang >>>> Cc: CCAMP; >>>> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; >>>> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org >>>> Subject: Re: Closing G.709 open issues >>>> >>>> >>>> Just to be clear to all: My mail summarized the results of >>>> discussions that occurred on the list whose results I believe >>>> are not reflected in the current document set. I identified 3 >>>> items, and hope I didn't miss anything from the ~200 related >>>> messages on the list. I'm not trying to change any >>>> conclusions, just ensure that they are documented. >>>> >>>> Fatai, >>>> >>>> See below for specific responses. >>>> >>>> On 5/9/2013 3:12 AM, Fatai Zhang wrote: >>>>> Hi Lou, >>>>> >>>>> For point 1), do you mean that you would like to have "TSG" field >>>>> (ie., explicit indication) in the label format? Or just change the >>>>> target text that you quoted? >>>>> >>>> >>>> This point was resolved in >>>> http://www.ietf.org/mail-archive/web/ccamp/current/msg14701.html >>>> to quote: >>>> On 3/21/2013 9:51 AM, Lou Berger wrote: >>>> > Daniele, >>>> ... >>>> > On 3/21/2013 9:34 AM, Daniele Ceccarelli wrote: >>>> >> Lou, >>>> >> >>>> >> OK. No changes to signaling re explicit indication of mapping >>>> >> and/or TSG in the label. >>>> > >>>> > I think it would be a good idea to add a comment on this in the >>>> > signaling document so that we don't have to revisit it >> yet again... >>>> > >>>> >>>>> If what you meant is the latter, could you provide some >>>> proposed text to refine it. >>>>> >>>> >>>> I suggest that the authors propose some text on the list for >>>> the WG to review. Given that the explicit indication issue >>>> was raised by one of the co-authors I suspect he can provide >>>> text that ensures the issue is covered. There's also some >>>> related text already on page 7 of the framework draft. If the >>>> authors are unable to come up with a proposal, let me know and >>>> I'll propose something to the list. >>>> >>>>> For point 2), the GPIDs have been grouped based on Table 15-8 in >>>>> G.709 (so it seems that some payload types in Table 15-8 are >>>> missed), >>>>> but I think you more like the 1:1 mapping between the GPID >>>> defined in >>>>> [SIGNALING] and Table 15-8. >>>> >>>> The only thing I'm asking for is to verify that it is possible >>>> to unambiguously signal the G.709 defined payload types with >>>> GMPLS. The authors are free to use any approach, e.g., 1:1 or >>>> n:1+other signaled information. >>>> >>>>> We will check and list all the ungrouped GPIDs. >>>>> >>>> >>>> If you think it's possible to indicate all G.709 defined >>>> payload types using the current "grouped" approach, that works >>>> for me. You just need to state such on the list. >>>> >>>> Perhaps it makes sense to just list how each PT in G.709 table >>>> 15-8 is represented as a good sanity check. Such a list might >>>> also be useful information to add to the draft. Here's a >>>> start at such a list. I've flagged the results of a spot >>>> check (i.e., I probably have missed >>>> something) of PTs for which I don't see an obvious mapping. >>>> >>>> G.709 >>>> Payload >>>> Type G-PID >>>> ------- ----- >>>> 0x01 ??? >>>> 0x02 >>>> 0x03 >>>> 0x04 >>>> 0x05 >>>> 0x06 >>>> 0x07 >>>> 0x08 >>>> 0x09 >>>> 0x0A >>>> 0x0B >>>> 0x0C >>>> 0x0D >>>> 0x0E >>>> 0x0F >>>> 0x10 >>>> 0x11 >>>> 0x12 ??? >>>> 0x13 ??? >>>> 0x14 ??? >>>> 0x15 ??? >>>> 0x16 ??? >>>> 0x17 ??? >>>> 0x18 ??? >>>> 0x19 ??? >>>> 0x1A >>>> 0x1B ??? >>>> 0x1C >>>> 0x20 >>>> 0x21 >>>> 0x55 Unused >>>> 0x66 Unused >>>> 0x80-0x8F ??? >>>> 0xFD ?? (Is this needed?) >>>> 0xFE ?? (Is this needed?) >>>> 0xFF Unused >>>> >>>> >>>> Thanks, >>>> Lou >>>> >>>>> >>>>> >>>>> >>>>> Best Regards >>>>> >>>>> Fatai >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>> Sent: Thursday, May 09, 2013 12:53 AM >>>>> To: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; >>>>> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org >>>>> Subject: Closing G.709 open issues >>>>> >>>>> Authors/WG, >>>>> I think all would like to wrap up the 709 documents >>>> before Berlin. >>>>> To do this we need to: >>>>> 1) Ensure all discussed points have been resolved >>>>> 2) Hold a 2nd LC to ensure consensus on all changes since >> the 1st LC >>>>> 3) Capture the resolution of any comments made during 2. >>>>> >>>>> In reviewing the close to 200 mail messages on the documents >>>> since the >>>>> 1st LC was issued, I see only one a few points that are >>>> still missing, >>>>> and I'll cover these below. On a side note, as an >>>> experiment we'll be >>>>> tracking these issue via the tools issues page: >>>>> http://tools.ietf.org/wg/ccamp/trac/report/1 >>>>> >>>>> PLEASE reply to this message if you think there are other >>>>> points/discussions that haven't been addressed in the >> current set of >>>>> documents. Once this thread is closed, the 2nd LC will be >> initiated. >>>>> >>>>> The remaining items come from the tread with the final message >>>>> http://www.ietf.org/mail-archive/web/ccamp/current/msg14701.html >>>>> The message is from me in response to Daniele's summary of >>>> next steps, >>>>> and has the following unresolved actions: >>>>> >>>>> 1) No explicit indication of TSG in the label [SIGNALING] >>>>> >>>>> In signaling document section 6: Clarify related text to >>>> unambiguous >>>>> identify the relationship between label length and TSG. Possible >>>>> target text to change: >>>>> Note that the >>>>> Length field in the label format MAY be used to indicate the TS >>>>> type of the HO ODUk (i.e., TS granularity at 1.25Gbps >> or 2.5Gbps) >>>>> since the HO ODUk type can be known from IF_ID RSVP_HOP >> Object. In >>>>> some cases when there is no Link Management Protocol (LMP) or >>>>> routing to make the two end points of the link to know the TSG, >>>>> the TSG information used by another end can be deduced from the >>>>> label format. For example, for HO ODU2 link, the value of the >>>>> length filed will be 4 or 8, which indicates the TS >> granularity is >>>>> 2.5Gbps or 1.25Gbps, respectively. >>>>> >>>>> 2) Verify that the complete list of G-PIDs are defined [SIGNALING] >>>>> >>>>> In signaling document section 4, verify that all payload types >>>>> defined in G.709 (Summarized in Table 15-8) can be represented. >>>>> This issue can be resolved via an update or message to the list >>>>> stating that the verification took place. >>>>> >>>>> 3) Identification of hexadecimal representation in G.709 vs >>>>> decimal in GMPLS [INFO-MODEL] >>>>> >>>>> The authors had previously stated the intent to just make >>>> this clear >>>>> in the signaling document. I'd like to make an >> alternate proposal: >>>>> let's do the the obvious and have the documents simply use >>>> the normal >>>>> (IETF) convention of using a '0x' prefix anytime a >>>> hexadecimal value >>>>> is represented. I believe this means that only the >> info-model draft >>>>> needs to be updated. >>>>> >>>>> I believe that's the complete list. Again: >>>>> PLEASE reply to this message if you think there are other >>>>> points/discussions that haven't been addressed in the >> current set of >>>>> documents. >>>>> >>>>> Much thanks, >>>>> Lou >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >>> >> > > > From jdrake@juniper.net Fri May 10 09:41:29 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C632221F8D00 for ; Fri, 10 May 2013 09:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.467 X-Spam-Level: X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ze+Hed3swiyh for ; Fri, 10 May 2013 09:41:24 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id E767A21F8AA8 for ; Fri, 10 May 2013 09:41:17 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKUY0jLXX8ojlOZ+TmA0r+EuKgvTZOe/f8@postini.com; Fri, 10 May 2013 09:41:17 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 10 May 2013 09:40:10 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Fri, 10 May 2013 09:40:10 -0700 Received: from db9outboundpool.messaging.microsoft.com (213.199.154.252) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 10 May 2013 09:51:07 -0700 Received: from mail89-db9-R.bigfish.com (10.174.16.234) by DB9EHSOBE032.bigfish.com (10.174.14.95) with Microsoft SMTP Server id 14.1.225.23; Fri, 10 May 2013 16:40:08 +0000 Received: from mail89-db9 (localhost [127.0.0.1]) by mail89-db9-R.bigfish.com (Postfix) with ESMTP id EEE444E068A for ; Fri, 10 May 2013 16:40:07 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT005.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -27 X-BigFish: PS-27(zzbb2dI98dI9371Ic89bh1454I542I1432I4015Idb82hzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dhz2dh2a8h668h839h947hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1155h) Received: from mail89-db9 (localhost.localdomain [127.0.0.1]) by mail89-db9 (MessageSwitch) id 1368203962924245_7620; Fri, 10 May 2013 16:39:22 +0000 (UTC) Received: from DB9EHSMHS007.bigfish.com (unknown [10.174.16.254]) by mail89-db9.bigfish.com (Postfix) with ESMTP id DE05C4C005C; Fri, 10 May 2013 16:39:22 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS007.bigfish.com (10.174.14.17) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 10 May 2013 16:39:22 +0000 Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.1.200]) by BL2PRD0510HT005.namprd05.prod.outlook.com ([10.255.100.40]) with mapi id 14.16.0305.001; Fri, 10 May 2013 16:39:20 +0000 From: John E Drake To: Daniele Ceccarelli , Lou Berger Thread-Topic: Closing G.709 open issues Thread-Index: AQHOTUvAUzbt3NZbFkSMH0hHPucez5j+nyqA Date: Fri, 10 May 2013 16:39:19 +0000 Message-ID: <0182DEA5604B3A44A2EE61F3EE3ED69E1D4E97C9@BL2PRD0510MB349.namprd05.prod.outlook.com> References: <518A82D9.7080508@labn.net> <518BAB17.9090807@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C68CE@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE480C68CE@ESESSMB301.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.53] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%ERICSSON.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%LABN.NET$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" , "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" Subject: Re: [CCAMP] Closing G.709 open issues X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 16:41:29 -0000 Can we please just go with 1? Irrespectively Yours, John > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Daniele Ceccarelli > Sent: Thursday, May 09, 2013 11:58 PM > To: Lou Berger > Cc: draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; CCAMP; > draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org > Subject: Re: [CCAMP] Closing G.709 open issues >=20 > Lou, >=20 > I want to close the OTN work more than anyone else :-) I just expressed > loud thinking due to last evolution in OTN data plane, but i said, no > major issue and i'm fine with 1. Let's go with 1. >=20 > I'm fine with the text you're proposing. >=20 > Thanks > Daniele >=20 > >-----Original Message----- > >From: Lou Berger [mailto:lberger@labn.net] > >Sent: gioved=EC 9 maggio 2013 19.21 > >To: Daniele Ceccarelli > >Cc: Fatai Zhang; CCAMP; > >draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; > >draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org > >Subject: Re: Closing G.709 open issues > > > >Daniele, > > Please see below: > > > >On 5/9/2013 12:57 PM, Daniele Ceccarelli wrote: > >> Hi Lou, > >> > >> Wrt point 1) (TSG) we have 2 options. > >> > >> 1. leave the TSG being inferred by the label length and > >propose new text (see below). > >> 2. add the TSG to the label. > >> > >> Either solutions work for me, i just want to share some > >thoughts raised during discussions with Sergio and Fred. > >> A. From an implementation point of view, in case of > >multi-stage muxing > >> multiple label lookups are needed to infer the TSG B. Future > >proofness: we all know that TSG=3D10Gbps will be defined shorthly. This > >might make the TSG infer from label length not feasible. > >> > > > >Sigh, I keep thinking we're "almost done" on 709 and another > discussion > >pops up... > > > >So this is at least the third time we're discussing options 1 and 2. > >In the prior times, we've always agreed to follow 1. > >So I'll quote myself, from the last time around: > > Revising past decisions is fine if there's good cause, such as new > > information or issues identified/discovered... > > > >So let me ask, is there good cause to revisit this decision? > > > >> Again, for me both solutions 1. and 2. work, A. And B. might > >not be major issues. > >> > >> In case we go for 1. my proposed text is (feel free to amend): > >> > >> "Please note that the TSG of the HO ODUk can be inferred > >from the length of the label. > >> In those cases where there is no LMP imposing the TSG to be used > >> between two ends of a link, Such information can be inferred > >from the > >> signaling. E.g. In a HO ODU link a label lenght value Of 4 > >would indicate TSG equal to 2,5Gbps while a value of 8 would > correspond > >to a 1.25Gbps TSG". > > > >Continuing in the case of 1, but how about: > > > > Please note that the TS granularity of a HO ODUk can be inferred > from > > the length of the label. The values of 1, 4 and 16 indicate a TS > > granularity of 2.5Gps, while the values 2, 7, 32 and 80 indicate a TS > > granularity of 1.25Gps. > > > >Note that I added the length value of 1 based on the table on page 7 > of > >the framework draft, but 1 isn't listed as a valid length value. One > >of these is wrong. (I didn't spend the time to figure out if the 1 > >needs to be added to valid list or should be dropped from the > suggested > >text. > >Figured one of the authors would know this.) > > > >Thanks, > >Lou > > > >> > >> BR > >> Daniele > >> > >> > >> > >> > >>> -----Original Message----- > >>> From: Lou Berger [mailto:lberger@labn.net] > >>> Sent: gioved=EC 9 maggio 2013 15.57 > >>> To: Fatai Zhang > >>> Cc: CCAMP; > >>> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; > >>> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org > >>> Subject: Re: Closing G.709 open issues > >>> > >>> > >>> Just to be clear to all: My mail summarized the results of > >>> discussions that occurred on the list whose results I believe are > >>> not reflected in the current document set. I identified 3 items, > >>> and hope I didn't miss anything from the ~200 related messages on > >>> the list. I'm not trying to change any conclusions, just ensure > that > >>> they are documented. > >>> > >>> Fatai, > >>> > >>> See below for specific responses. > >>> > >>> On 5/9/2013 3:12 AM, Fatai Zhang wrote: > >>>> Hi Lou, > >>>> > >>>> For point 1), do you mean that you would like to have "TSG" field > >>>> (ie., explicit indication) in the label format? Or just change the > >>>> target text that you quoted? > >>>> > >>> > >>> This point was resolved in > >>> http://www.ietf.org/mail-archive/web/ccamp/current/msg14701.html > >>> to quote: > >>> On 3/21/2013 9:51 AM, Lou Berger wrote: > >>> > Daniele, > >>> ... > >>> > On 3/21/2013 9:34 AM, Daniele Ceccarelli wrote: > >>> >> Lou, > >>> >> > >>> >> OK. No changes to signaling re explicit indication of mapping > >>> >> and/or TSG in the label. > >>> > > >>> > I think it would be a good idea to add a comment on this in the > >>> > signaling document so that we don't have to revisit it > >yet again... > >>> > > >>> > >>>> If what you meant is the latter, could you provide some > >>> proposed text to refine it. > >>>> > >>> > >>> I suggest that the authors propose some text on the list for the WG > >>> to review. Given that the explicit indication issue was raised by > >>> one of the co-authors I suspect he can provide text that ensures > the > >>> issue is covered. There's also some related text already on page 7 > >>> of the framework draft. If the authors are unable to come up with > a > >>> proposal, let me know and I'll propose something to the list. > >>> > >>>> For point 2), the GPIDs have been grouped based on Table 15-8 in > >>>> G.709 (so it seems that some payload types in Table 15-8 are > >>> missed), > >>>> but I think you more like the 1:1 mapping between the GPID > >>> defined in > >>>> [SIGNALING] and Table 15-8. > >>> > >>> The only thing I'm asking for is to verify that it is possible to > >>> unambiguously signal the G.709 defined payload types with GMPLS. > The > >>> authors are free to use any approach, e.g., 1:1 or n:1+other > >>> signaled information. > >>> > >>>> We will check and list all the ungrouped GPIDs. > >>>> > >>> > >>> If you think it's possible to indicate all G.709 defined payload > >>> types using the current "grouped" approach, that works for me. You > >>> just need to state such on the list. > >>> > >>> Perhaps it makes sense to just list how each PT in G.709 table > >>> 15-8 is represented as a good sanity check. Such a list might also > >>> be useful information to add to the draft. Here's a start at such > a > >>> list. I've flagged the results of a spot check (i.e., I probably > >>> have missed > >>> something) of PTs for which I don't see an obvious mapping. > >>> > >>> G.709 > >>> Payload > >>> Type G-PID > >>> ------- ----- > >>> 0x01 ??? > >>> 0x02 > >>> 0x03 > >>> 0x04 > >>> 0x05 > >>> 0x06 > >>> 0x07 > >>> 0x08 > >>> 0x09 > >>> 0x0A > >>> 0x0B > >>> 0x0C > >>> 0x0D > >>> 0x0E > >>> 0x0F > >>> 0x10 > >>> 0x11 > >>> 0x12 ??? > >>> 0x13 ??? > >>> 0x14 ??? > >>> 0x15 ??? > >>> 0x16 ??? > >>> 0x17 ??? > >>> 0x18 ??? > >>> 0x19 ??? > >>> 0x1A > >>> 0x1B ??? > >>> 0x1C > >>> 0x20 > >>> 0x21 > >>> 0x55 Unused > >>> 0x66 Unused > >>> 0x80-0x8F ??? > >>> 0xFD ?? (Is this needed?) > >>> 0xFE ?? (Is this needed?) > >>> 0xFF Unused > >>> > >>> > >>> Thanks, > >>> Lou > >>> > >>>> > >>>> > >>>> > >>>> Best Regards > >>>> > >>>> Fatai > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: Lou Berger [mailto:lberger@labn.net] > >>>> Sent: Thursday, May 09, 2013 12:53 AM > >>>> To: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; > >>>> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org > >>>> Subject: Closing G.709 open issues > >>>> > >>>> Authors/WG, > >>>> I think all would like to wrap up the 709 documents > >>> before Berlin. > >>>> To do this we need to: > >>>> 1) Ensure all discussed points have been resolved > >>>> 2) Hold a 2nd LC to ensure consensus on all changes since > >the 1st LC > >>>> 3) Capture the resolution of any comments made during 2. > >>>> > >>>> In reviewing the close to 200 mail messages on the documents > >>> since the > >>>> 1st LC was issued, I see only one a few points that are > >>> still missing, > >>>> and I'll cover these below. On a side note, as an > >>> experiment we'll be > >>>> tracking these issue via the tools issues page: > >>>> http://tools.ietf.org/wg/ccamp/trac/report/1 > >>>> > >>>> PLEASE reply to this message if you think there are other > >>>> points/discussions that haven't been addressed in the > >current set of > >>>> documents. Once this thread is closed, the 2nd LC will be > >initiated. > >>>> > >>>> The remaining items come from the tread with the final message > >>>> http://www.ietf.org/mail-archive/web/ccamp/current/msg14701.html > >>>> The message is from me in response to Daniele's summary of > >>> next steps, > >>>> and has the following unresolved actions: > >>>> > >>>> 1) No explicit indication of TSG in the label [SIGNALING] > >>>> > >>>> In signaling document section 6: Clarify related text to > >>> unambiguous > >>>> identify the relationship between label length and TSG. Possible > >>>> target text to change: > >>>> Note that the > >>>> Length field in the label format MAY be used to indicate the TS > >>>> type of the HO ODUk (i.e., TS granularity at 1.25Gbps > >or 2.5Gbps) > >>>> since the HO ODUk type can be known from IF_ID RSVP_HOP > >Object. In > >>>> some cases when there is no Link Management Protocol (LMP) or > >>>> routing to make the two end points of the link to know the TSG, > >>>> the TSG information used by another end can be deduced from the > >>>> label format. For example, for HO ODU2 link, the value of the > >>>> length filed will be 4 or 8, which indicates the TS > >granularity is > >>>> 2.5Gbps or 1.25Gbps, respectively. > >>>> > >>>> 2) Verify that the complete list of G-PIDs are defined [SIGNALING] > >>>> > >>>> In signaling document section 4, verify that all payload types > >>>> defined in G.709 (Summarized in Table 15-8) can be represented. > >>>> This issue can be resolved via an update or message to the list > >>>> stating that the verification took place. > >>>> > >>>> 3) Identification of hexadecimal representation in G.709 vs > >>>> decimal in GMPLS [INFO-MODEL] > >>>> > >>>> The authors had previously stated the intent to just make > >>> this clear > >>>> in the signaling document. I'd like to make an > >alternate proposal: > >>>> let's do the the obvious and have the documents simply use > >>> the normal > >>>> (IETF) convention of using a '0x' prefix anytime a > >>> hexadecimal value > >>>> is represented. I believe this means that only the > >info-model draft > >>>> needs to be updated. > >>>> > >>>> I believe that's the complete list. Again: > >>>> PLEASE reply to this message if you think there are other > >>>> points/discussions that haven't been addressed in the > >current set of > >>>> documents. > >>>> > >>>> Much thanks, > >>>> Lou > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >> > >> > >> > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From zhangfatai@huawei.com Sun May 12 20:33:42 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8AA621F8E3C for ; Sun, 12 May 2013 20:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOImWnv0Vec7 for ; Sun, 12 May 2013 20:33:38 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8630621F8D41 for ; Sun, 12 May 2013 20:33:37 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARH84046; Mon, 13 May 2013 03:33:36 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 13 May 2013 04:33:08 +0100 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 13 May 2013 04:33:32 +0100 Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.222]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.01.0323.007; Mon, 13 May 2013 11:33:05 +0800 From: Fatai Zhang To: Lou Berger Thread-Topic: Closing G.709 open issues Thread-Index: AQHOTAyDmhSnK0jr+ESubR/xu8VPgpj8bQiw///u0ICAADKIAIAABpSAgAEN6tCAADjpAIAEmsGw Date: Mon, 13 May 2013 03:33:04 +0000 Message-ID: References: <518A82D9.7080508@labn.net> <518BAB17.9090807@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> <518CED28.30303@labn.net> In-Reply-To: <518CED28.30303@labn.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: BP+q DC9W GQ3g Hk29 NaWy Vc3C VjKn aJEK eqCO flWY n+VK y0Ek zxr7 2IcG 4N+F 4Rzt; 5; YwBjAGEAbQBwAEAAaQBlAHQAZgAuAG8AcgBnADsAZABhAG4AaQBlAGwAZQAuAGMAZQBjAGMAYQByAGUAbABsAGkAQABlAHIAaQBjAHMAcwBvAG4ALgBjAG8AbQA7AGQAcgBhAGYAdAAtAGkAZQB0AGYALQBjAGMAYQBtAHAALQBnAG0AcABsAHMALQBzAGkAZwBuAGEAbABpAG4AZwAtAGcANwAwADkAdgAzAEAAdABvAG8AbABzAC4AaQBlAHQAZgAuAG8AcgBnADsAZAByAGEAZgB0AC0AaQBlAHQAZgAtAGMAYwBhAG0AcAAtAG8AdABuAC0AZwA3ADAAOQAtAGkAbgBmAG8ALQBtAG8AZABlAGwAQAB0AG8AbwBsAHMALgBpAGUAdABmAC4AbwByAGcAOwBsAGIAZQByAGcAZQByAEAAbABhAGIAbgAuAG4AZQB0AA==; Sosha1_v1; 7; {867613F5-D3F5-47B5-A965-26E91E9590E5}; egBoAGEAbgBnAGYAYQB0AGEAaQBAAGgAdQBhAHcAZQBpAC4AYwBvAG0A; Mon, 13 May 2013 03:32:53 GMT; UgBFADoAIABDAGwAbwBzAGkAbgBnACAARwAuADcAMAA5ACAAbwBwAGUAbgAgAGkAcwBzAHUAZQBzAA== x-cr-puzzleid: {867613F5-D3F5-47B5-A965-26E91E9590E5} x-originating-ip: [10.66.72.159] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" , CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" Subject: Re: [CCAMP] Closing G.709 open issues X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 03:33:42 -0000 Hi Lou, I think you have two major points here.=20 (1) Do you really need 3 G-PID types for an ODU (I thought TSG was already = covered)? I think this has been discussed for quite long time before Vancouver meetin= g, which was famous as "penultimate" issue. Note that this TSG in GPID is d= ifferent from the *implicit* TSG in label format. I don't think we need discuss this anymore. (2) 'Grouped GPID' vs '1:1' mapping (between G.709-2012 and GPIDs defined i= n this draft) We realize that it is safe to use 1:1 mapping approach to avoid some potent= ial issues after investigation. We know this payload types have been define= d by G.709 (data plane), so physically it is better to use 1:1 mapping appr= oach.=20 For the potential issues I mentioned above, for example, we cannot use the = existing 34 to represent 'STM-1' and 'STM-4 ', because it is impossible to = differentiate which one is 'STM-1' or 'STM-4'. In addition, from the concep= t of payload type, we know that e.g, FC-100 is different from FC-800, right= ? So, it is better to assign different GPIDs to these different payload typ= es defined by the data plane. Furthermore, I think it is much cheaper to create new GPIDs in the control = plane than in the data plane (these payload types will be carried in the OH= ).=20 Best Regards Fatai -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Friday, May 10, 2013 8:51 PM To: Fatai Zhang Cc: Daniele Ceccarelli; CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tool= s.ietf.org; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org Subject: Re: Closing G.709 open issues On 5/9/2013 9:41 PM, Fatai Zhang wrote: > Hi Lou, >=20 > For point 1), "1" should be dropped and "7" should be corrected to "8" in= your proposed text.=20 Great. >=20 > I hesitate to make a decision on either approach, I would like to defer t= o the WG consensus. >=20 I believe we already have a consensus position. The question in my mail was do we need to revisit it. I take your response as a no. (thank you!) > For point 2), I compared [G.709-2003] and [G.709-2012], and checked > the GPIDs defined in [RFC4328], I think the following new GPIDs > (values could be 59-79) should be added (besides updating some GPIDs > defined in RFC4328, like 32,47,49-52): >=20 I suggest going through the full PT list and identifying them in the table (as I started in my last message) so that there is no confusion in implementations. In the list below it looks like you have moved away from the 'grouped G-PID' approach. Is there a reason for this change? Refer to http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parameters.x= ml in subsequent comments. > Value G-PID Type LSP Encoding Type > ----- ---------- ----------------- > 59(TBA) G.709 ODU-1.25G G.709 ODUk=20 > 60(TBA) G.709 ODU-any G.709 ODUk Do you really need 3 G-PID types for an ODU (I thought TSG was already covered)? > 61(TBA) PCS G.709 ODUk (k=3D0) > 62(TBA) FC-1200 G.709 ODUk (k=3D2e) Why not us existing G-PID 58? > 63(TBA) eOPU2 G.709 ODUk (k=3D2) > 64(TBA) STM-1 G.709 ODUk (k=3D0) > 65(TBA) STM-4 G.709 ODUk (k=3D0) Why not us existing G-PID 34? > 66(TBA) FC-100 G.709 ODUk (k=3D0) > 67(TBA) FC-200 G.709 ODUk (k=3D1) > 68(TBA) FC-400 G.709 ODUflex > 69(TBA) FC-800 G.709 ODUflex Why not us existing G-PID 58? > 70(TBA) IB SDR G.709 ODUflex > 71(TBA) IB DDR G.709 ODUflex > 72(TBA) IB QDR G.709 ODUflex Can these be one value with rate implying SDR/DDR/QDR? > 73(TBA) SDIa G.709 ODUk (k=3D0) > 74(TBA) SDIb G.709 ODUk (k=3D1) > 75(TBA) SDIc G.709 ODUk (k=3D1) > 76(TBA) SDId G.709 ODUflex > 77(TBA) SDIe G.709 ODUflex Can these be one value with rate implying a-e? > 78(TBA) SB/ESCON G.709 ODUk (k=3D0) Why not us existing G-PID 56? > 79(TBA) DVB_ASI G.709 ODUk (k=3D0) >=20 >=20 >=20 >=20 Thanks, Lou From sergio.belotti@alcatel-lucent.com Mon May 13 00:46:07 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0954A21F8FB3 for ; Mon, 13 May 2013 00:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8 X-Spam-Level: X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7y+Rp6cjWrY for ; Mon, 13 May 2013 00:46:01 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id A9C6821F9164 for ; Mon, 13 May 2013 00:45:57 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r4D7jfjG002193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 May 2013 02:45:42 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id r4D7jcoi029778 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 May 2013 03:45:40 -0400 Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 13 May 2013 03:45:39 -0400 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.233]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Mon, 13 May 2013 09:45:27 +0200 From: "BELOTTI, SERGIO (SERGIO)" To: Fatai Zhang , Lou Berger Thread-Topic: Closing G.709 open issues Thread-Index: AQHOT4qqUl1mFyMbR0uUaEgIgIORFZkCvCzw Date: Mon, 13 May 2013 07:45:27 +0000 Message-ID: References: <518A82D9.7080508@labn.net> <518BAB17.9090807@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> <518CED28.30303@labn.net> In-Reply-To: Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" , CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" Subject: [CCAMP] R: Closing G.709 open issues X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 07:46:07 -0000 Hi Fatai, I agree with you, for both point 1 and 2. Best Regards Sergio Belotti Sergio- System Architect ALCATE-LUCENT Optics Division via Trento 30 Vimercate (MB) - Italy phone +39 (039) 6863033 -----Messaggio originale----- Da: Fatai Zhang [mailto:zhangfatai@huawei.com]=20 Inviato: luned=EC 13 maggio 2013 5.33 A: Lou Berger Cc: Daniele Ceccarelli; CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tool= s.ietf.org; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org Oggetto: RE: Closing G.709 open issues Hi Lou, I think you have two major points here.=20 (1) Do you really need 3 G-PID types for an ODU (I thought TSG was already = covered)? I think this has been discussed for quite long time before Vancouver meetin= g, which was famous as "penultimate" issue. Note that this TSG in GPID is d= ifferent from the *implicit* TSG in label format. I don't think we need discuss this anymore. (2) 'Grouped GPID' vs '1:1' mapping (between G.709-2012 and GPIDs defined i= n this draft) We realize that it is safe to use 1:1 mapping approach to avoid some potent= ial issues after investigation. We know this payload types have been define= d by G.709 (data plane), so physically it is better to use 1:1 mapping appr= oach.=20 For the potential issues I mentioned above, for example, we cannot use the = existing 34 to represent 'STM-1' and 'STM-4 ', because it is impossible to = differentiate which one is 'STM-1' or 'STM-4'. In addition, from the concep= t of payload type, we know that e.g, FC-100 is different from FC-800, right= ? So, it is better to assign different GPIDs to these different payload typ= es defined by the data plane. Furthermore, I think it is much cheaper to create new GPIDs in the control = plane than in the data plane (these payload types will be carried in the OH= ).=20 Best Regards Fatai -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Friday, May 10, 2013 8:51 PM To: Fatai Zhang Cc: Daniele Ceccarelli; CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tool= s.ietf.org; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org Subject: Re: Closing G.709 open issues On 5/9/2013 9:41 PM, Fatai Zhang wrote: > Hi Lou, >=20 > For point 1), "1" should be dropped and "7" should be corrected to "8" in= your proposed text.=20 Great. >=20 > I hesitate to make a decision on either approach, I would like to defer t= o the WG consensus. >=20 I believe we already have a consensus position. The question in my mail was do we need to revisit it. I take your response as a no. (thank you!) > For point 2), I compared [G.709-2003] and [G.709-2012], and checked > the GPIDs defined in [RFC4328], I think the following new GPIDs > (values could be 59-79) should be added (besides updating some GPIDs > defined in RFC4328, like 32,47,49-52): >=20 I suggest going through the full PT list and identifying them in the table (as I started in my last message) so that there is no confusion in implementations. In the list below it looks like you have moved away from the 'grouped G-PID' approach. Is there a reason for this change? Refer to http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parameters.x= ml in subsequent comments. > Value G-PID Type LSP Encoding Type > ----- ---------- ----------------- > 59(TBA) G.709 ODU-1.25G G.709 ODUk=20 > 60(TBA) G.709 ODU-any G.709 ODUk Do you really need 3 G-PID types for an ODU (I thought TSG was already covered)? > 61(TBA) PCS G.709 ODUk (k=3D0) > 62(TBA) FC-1200 G.709 ODUk (k=3D2e) Why not us existing G-PID 58? > 63(TBA) eOPU2 G.709 ODUk (k=3D2) > 64(TBA) STM-1 G.709 ODUk (k=3D0) > 65(TBA) STM-4 G.709 ODUk (k=3D0) Why not us existing G-PID 34? > 66(TBA) FC-100 G.709 ODUk (k=3D0) > 67(TBA) FC-200 G.709 ODUk (k=3D1) > 68(TBA) FC-400 G.709 ODUflex > 69(TBA) FC-800 G.709 ODUflex Why not us existing G-PID 58? > 70(TBA) IB SDR G.709 ODUflex > 71(TBA) IB DDR G.709 ODUflex > 72(TBA) IB QDR G.709 ODUflex Can these be one value with rate implying SDR/DDR/QDR? > 73(TBA) SDIa G.709 ODUk (k=3D0) > 74(TBA) SDIb G.709 ODUk (k=3D1) > 75(TBA) SDIc G.709 ODUk (k=3D1) > 76(TBA) SDId G.709 ODUflex > 77(TBA) SDIe G.709 ODUflex Can these be one value with rate implying a-e? > 78(TBA) SB/ESCON G.709 ODUk (k=3D0) Why not us existing G-PID 56? > 79(TBA) DVB_ASI G.709 ODUk (k=3D0) >=20 >=20 >=20 >=20 Thanks, Lou From daniele.ceccarelli@ericsson.com Mon May 13 01:03:14 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5A6D21F8D84 for ; Mon, 13 May 2013 01:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2iTIzuQuRbbB for ; Mon, 13 May 2013 01:03:09 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4F74121F8FB6 for ; Mon, 13 May 2013 01:03:09 -0700 (PDT) X-AuditID: c1b4fb30-b7f3a6d0000007a4-79-51909e3cfe65 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 62.F0.01956.C3E90915; Mon, 13 May 2013 10:03:08 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.55]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0328.009; Mon, 13 May 2013 10:03:07 +0200 From: Daniele Ceccarelli To: "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" , "lberger@labn.net" Thread-Topic: [CCAMP WG] #50: Identification of hexadecimal representation in G.709 vs decimal in GMPLS Thread-Index: AQHOTBCPGsuJYF0jUUyiGzymCk+foZkCx0Ew Date: Mon, 13 May 2013 08:03:07 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE480C70F8@ESESSMB301.ericsson.se> References: <059.82d98e9dee0226e015a3852ed4c8eece@trac.tools.ietf.org> In-Reply-To: <059.82d98e9dee0226e015a3852ed4c8eece@trac.tools.ietf.org> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUyM+Jvra7NvAmBBtOWCFlMPXqMzeLJnBss FlNmf2ex6Gh+y+LA4rFkyU8mjw+bmtk8vlz+zBbAHMVlk5Kak1mWWqRvl8CVsfb8LcaC44IV t34eZm9g/MfbxcjJISFgIvHoyBJ2CFtM4sK99WxdjFwcQgKHGSW+/3vNBpIQEljMKNF6tqiL kYODTcBK4skhH5AaEYFZjBLPGy4xgtQwC0RKbPv4DmyQsECGxItnm5lBbBGBTIllJ2axQNhG Eos/3gCzWQRUJT6/Xgtm8wp4S+xtvc0MsctNonXBGiYQm1PAXeJK63+wOKOArMSE3YugdolL 3HoynwniaAGJJXvOM0PYohIvH/9jhbAVJa5OX84EUa8ncWPqFDYIW1ti2cLXzBB7BSVOznzC MoFRbBaSsbOQtMxC0jILScsCRpZVjOy5iZk56eXmmxiBEXRwy2+DHYyb7osdYpTmYFES503m agwUEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwNgvvrGJ5aiKWG9jzM6ujyd3m5a3Vn3qMWnd +Elw4i9j5S+8XtFCGkVfTNfMrQvqrZ2q0iDjWt3y3jrj1Tx1v+rilxtWsb0Vcgp/+vZI7Eoe ofOrzaWnbJuyo/SvR8Craka53YL3otn3O7flsVQpLdPe0LHvlIvq+b7AmYZhIYdOTrk1++ax I0osxRmJhlrMRcWJACj9bFVuAgAA Cc: CCAMP , "ccamp-chairs@tools.ietf.org" Subject: Re: [CCAMP] [CCAMP WG] #50: Identification of hexadecimal representation in G.709 vs decimal in GMPLS X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 08:03:14 -0000 Lou, CCAMP, This is the proposed text for the info-model wrt the decimal vs hexadecimal= encoding issue. 13. Identification of hexadecimal representation in G.709 vs decimal in GMPLS considerations Encoding in GMPLS foresses the utilization of hexadecimal values format "0x" while in the data plane documents, like G.709 reccomendation, the format usually used is the decimal one (e.g. G-PID in RSVP-TE vs Payload Type in G.709).=20 BR Daniele & Sergio >-----Original Message----- >From: ccamp issue tracker [mailto:trac+ccamp@trac.tools.ietf.org]=20 >Sent: mercoled=EC 8 maggio 2013 19.22 >To: draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org;=20 >lberger@labn.net >Cc: ccamp-chairs@tools.ietf.org >Subject: [CCAMP WG] #50: Identification of hexadecimal=20 >representation in G.709 vs decimal in GMPLS > >#50: Identification of hexadecimal representation in G.709 vs=20 >decimal in GMPLS > > From: http://www.ietf.org/mail-archive/web/ccamp/current/msg14812.html > > The authors had previously stated the intent to just make this clear > in the signaling document. I'd like to make an alternate proposal: > let's do the the obvious and have the documents simply use=20 >the normal > (IETF) convention of using a '0x' prefix anytime a hexadecimal value > is represented. I believe this means that only the info-model draft > needs to be updated. > >--=20 >-------------------------------------+------------------------- >--------- >-------------------------------------+--- > Reporter: lberger@labn.net | Owner: draft-ietf-ccamp- > Type: task | =20 >otn-g709-info-model@tools.ietf.org > Priority: major | Status: new >Component: otn-g709-info-model | Milestone: Post WG Last Call > Severity: Waiting for Document | Version: > Update | Keywords: >-------------------------------------+------------------------- >--------- >-------------------------------------+--- > >Ticket URL: >CCAMP WG Common Control and=20 >Measurement Plane Working Group >= From zhangfatai@huawei.com Mon May 13 02:43:50 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD1121F90DF for ; Mon, 13 May 2013 02:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3EzLViMlrGR for ; Mon, 13 May 2013 02:43:46 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 38EA721F923C for ; Mon, 13 May 2013 02:43:45 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARI14375; Mon, 13 May 2013 09:43:43 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 13 May 2013 10:43:08 +0100 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 13 May 2013 10:43:26 +0100 Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.222]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0323.007; Mon, 13 May 2013 17:43:15 +0800 From: Fatai Zhang To: Daniele Ceccarelli , "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" , "lberger@labn.net" Thread-Topic: [CCAMP WG] #50: Identification of hexadecimal representation in G.709 vs decimal in GMPLS Thread-Index: AQHOTBCPvUtEBzyTAUGIoOMWCmYBDJkCQl2AgAChYyA= Date: Mon, 13 May 2013 09:43:15 +0000 Message-ID: References: <059.82d98e9dee0226e015a3852ed4c8eece@trac.tools.ietf.org> <4A1562797D64E44993C5CBF38CF1BE480C70F8@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE480C70F8@ESESSMB301.ericsson.se> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: CCAMP , "ccamp-chairs@tools.ietf.org" Subject: Re: [CCAMP] [CCAMP WG] #50: Identification of hexadecimal representation in G.709 vs decimal in GMPLS X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 09:43:50 -0000 Hi Daniele, I think it is better to use the reference format when mentioning some data = plane documents, e.g., [G709-2012]. Best Regards Fatai -----Original Message----- From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]=20 Sent: Monday, May 13, 2013 4:03 PM To: draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; lberger@labn.net Cc: ccamp-chairs@tools.ietf.org; CCAMP Subject: RE: [CCAMP WG] #50: Identification of hexadecimal representation i= n G.709 vs decimal in GMPLS Lou, CCAMP, This is the proposed text for the info-model wrt the decimal vs hexadecimal= encoding issue. 13. Identification of hexadecimal representation in G.709 vs decimal in GMPLS considerations Encoding in GMPLS foresses the utilization of hexadecimal values format "0x" while in the data plane documents, like G.709 reccomendation, the format usually used is the decimal one (e.g. G-PID in RSVP-TE vs Payload Type in G.709).=20 BR Daniele & Sergio >-----Original Message----- >From: ccamp issue tracker [mailto:trac+ccamp@trac.tools.ietf.org]=20 >Sent: mercoled=EC 8 maggio 2013 19.22 >To: draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org;=20 >lberger@labn.net >Cc: ccamp-chairs@tools.ietf.org >Subject: [CCAMP WG] #50: Identification of hexadecimal=20 >representation in G.709 vs decimal in GMPLS > >#50: Identification of hexadecimal representation in G.709 vs=20 >decimal in GMPLS > > From: http://www.ietf.org/mail-archive/web/ccamp/current/msg14812.html > > The authors had previously stated the intent to just make this clear > in the signaling document. I'd like to make an alternate proposal: > let's do the the obvious and have the documents simply use=20 >the normal > (IETF) convention of using a '0x' prefix anytime a hexadecimal value > is represented. I believe this means that only the info-model draft > needs to be updated. > >--=20 >-------------------------------------+------------------------- >--------- >-------------------------------------+--- > Reporter: lberger@labn.net | Owner: draft-ietf-ccamp- > Type: task | =20 >otn-g709-info-model@tools.ietf.org > Priority: major | Status: new >Component: otn-g709-info-model | Milestone: Post WG Last Call > Severity: Waiting for Document | Version: > Update | Keywords: >-------------------------------------+------------------------- >--------- >-------------------------------------+--- > >Ticket URL: >CCAMP WG Common Control and=20 >Measurement Plane Working Group > From daniele.ceccarelli@ericsson.com Mon May 13 02:45:53 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C92421F941D for ; Mon, 13 May 2013 02:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcJXWkRj2gdC for ; Mon, 13 May 2013 02:45:48 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8E721F9397 for ; Mon, 13 May 2013 02:45:47 -0700 (PDT) X-AuditID: c1b4fb30-b7f3a6d0000007a4-5a-5190b64a5906 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id B6.46.01956.A46B0915; Mon, 13 May 2013 11:45:46 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.55]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0328.009; Mon, 13 May 2013 11:45:45 +0200 From: Daniele Ceccarelli To: Fatai Zhang , "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" , "lberger@labn.net" Thread-Topic: [CCAMP WG] #50: Identification of hexadecimal representation in G.709 vs decimal in GMPLS Thread-Index: AQHOTBCPGsuJYF0jUUyiGzymCk+foZkCx0Ew///7q4CAACIZEA== Date: Mon, 13 May 2013 09:45:45 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE480C71A8@ESESSMB301.ericsson.se> References: <059.82d98e9dee0226e015a3852ed4c8eece@trac.tools.ietf.org> <4A1562797D64E44993C5CBF38CF1BE480C70F8@ESESSMB301.ericsson.se> In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyM+Jvra7XtgmBBks+y1lMPXqMzeLJnBss FlNmf2ex6Gh+y2LR13ye1YHVo+XIW1aPJUt+Mnl82NTM5vHl8me2AJYoLpuU1JzMstQifbsE royzU3YxF7yUrNj5ehFzA2OLaBcjJ4eEgInEp+cXGCFsMYkL99azgdhCAocZJbat9uti5AKy FzNKHL54mLmLkYODTcBK4skhH5C4iMBBRomeKe+ZQRqYBSIltn18xw5iCwtkSLx4thksLiKQ KbHsxCwWkF4RASeJ7ysSQcIsAqoSe1unsoLYvALeEq2PfjBB7LrCKNG0pgHsIE6BMIlXL76D FTEKyEpM2L2IEWKXuMStJ/OZII4WkFiy5zwzhC0q8fLxP1YIW1Hi6vTlTBD1ehI3pk5hg7C1 JZYtfM0MsVhQ4uTMJywTGMVmIRk7C0nLLCQts5C0LGBkWcXInpuYmZNebr6JERhVB7f8NtjB uOm+2CFGaQ4WJXHeZK7GQCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2M6dLnk/n/TfpxQ377 8bCNH5ZoT/nezi+rvib/5+VUGc9y3rma3nVHuE7/3rHF4pdFZIpyuCRTdM+tuPC4krkTtR64 FM09Fi72ct+uirg06Ui/uPqsmVLKqvVJ6w5+kVsUtCI9SlL9NotleEHGBfO2tULfk7fuUxaQ +HtmefHLvTM0hPq9lnErsRRnJBpqMRcVJwIA1KfGy3gCAAA= Cc: CCAMP , "ccamp-chairs@tools.ietf.org" Subject: Re: [CCAMP] [CCAMP WG] #50: Identification of hexadecimal representation in G.709 vs decimal in GMPLS X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 09:45:53 -0000 Hi Fatai, Yes, good comment, thanks. Daniele=20 >-----Original Message----- >From: Fatai Zhang [mailto:zhangfatai@huawei.com]=20 >Sent: luned=EC 13 maggio 2013 11.43 >To: Daniele Ceccarelli;=20 >draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; lberger@labn.net >Cc: ccamp-chairs@tools.ietf.org; CCAMP >Subject: RE: [CCAMP WG] #50: Identification of hexadecimal=20 >representation in G.709 vs decimal in GMPLS > >Hi Daniele, > >I think it is better to use the reference format when=20 >mentioning some data plane documents, e.g., [G709-2012]. > > > > > >Best Regards > >Fatai > > >-----Original Message----- >From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] >Sent: Monday, May 13, 2013 4:03 PM >To: draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org;=20 >lberger@labn.net >Cc: ccamp-chairs@tools.ietf.org; CCAMP >Subject: RE: [CCAMP WG] #50: Identification of hexadecimal=20 >representation in G.709 vs decimal in GMPLS > >Lou, CCAMP, > >This is the proposed text for the info-model wrt the decimal=20 >vs hexadecimal encoding issue. > > > >13. Identification of hexadecimal representation in G.709 vs=20 >decimal in > GMPLS considerations > > Encoding in GMPLS foresses the utilization of hexadecimal values > format "0x" while in the data plane documents, like G.709 > reccomendation, the format usually used is the decimal one (e.g. > G-PID in RSVP-TE vs Payload Type in G.709).=20 > >BR >Daniele & Sergio > >>-----Original Message----- >>From: ccamp issue tracker [mailto:trac+ccamp@trac.tools.ietf.org] >>Sent: mercoled=EC 8 maggio 2013 19.22 >>To: draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; >>lberger@labn.net >>Cc: ccamp-chairs@tools.ietf.org >>Subject: [CCAMP WG] #50: Identification of hexadecimal representation=20 >>in G.709 vs decimal in GMPLS >> >>#50: Identification of hexadecimal representation in G.709 vs decimal=20 >>in GMPLS >> >> From:=20 >http://www.ietf.org/mail-archive/web/ccamp/current/msg14812.html >> >> The authors had previously stated the intent to just make=20 >this clear >> in the signaling document. I'd like to make an alternate proposal: >> let's do the the obvious and have the documents simply use the=20 >>normal >> (IETF) convention of using a '0x' prefix anytime a=20 >hexadecimal value >> is represented. I believe this means that only the info-model draft >> needs to be updated. >> >>-- >>-------------------------------------+------------------------- >>--------- >>-------------------------------------+--- >> Reporter: lberger@labn.net | Owner: draft-ietf-ccamp- >> Type: task | =20 >>otn-g709-info-model@tools.ietf.org >> Priority: major | Status: new >>Component: otn-g709-info-model | Milestone: Post WG Last Call >> Severity: Waiting for Document | Version: >> Update | Keywords: >>-------------------------------------+------------------------- >>--------- >>-------------------------------------+--- >> >>Ticket URL: >>CCAMP WG Common Control and=20 >>Measurement Plane Working Group >> >= From lberger@labn.net Mon May 13 03:59:32 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61EB121F8935 for ; Mon, 13 May 2013 03:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93Us1AYpcmWa for ; Mon, 13 May 2013 03:59:28 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 0738F21F85CE for ; Mon, 13 May 2013 03:59:27 -0700 (PDT) Received: (qmail 12746 invoked by uid 0); 13 May 2013 10:59:06 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 13 May 2013 10:59:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=aHQoNlhKCWYV54NSyEB+DzeL7I0Bm3RIQ2MmmZBeODk=; b=j0mFoQXf1jjzWivhqRGIXxnYvvGGe63yTmp+v36mFHyaHnZccQDKQpCgqloz/lO77ahrb98P2v1Si3NtDNKyiMVro8XpiMfu/K+WYDZbYqRcjeXF1eu9LA864IHe9d48; Received: from box313.bluehost.com ([69.89.31.113]:60171 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UbqTC-0002nV-Ay; Mon, 13 May 2013 04:59:06 -0600 Message-ID: <5190C777.2090100@labn.net> Date: Mon, 13 May 2013 06:59:03 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Daniele Ceccarelli References: <059.82d98e9dee0226e015a3852ed4c8eece@trac.tools.ietf.org> <4A1562797D64E44993C5CBF38CF1BE480C70F8@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE480C70F8@ESESSMB301.ericsson.se> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" , "ccamp-chairs@tools.ietf.org" , CCAMP Subject: Re: [CCAMP] [CCAMP WG] #50: Identification of hexadecimal representation in G.709 vs decimal in GMPLS X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 10:59:32 -0000 Daniele, On 5/13/2013 4:03 AM, Daniele Ceccarelli wrote: > Lou, CCAMP, > > This is the proposed text for the info-model wrt the decimal vs > hexadecimal encoding issue. > I think the author's preference of not using the 0x prefix to hexadecimal representation is viable if it is clear in the document (as you mention below) and you can point to precedent of similar usage in existing RFCs. Have you checked / can you check to see if there's such? > > > 13. Identification of hexadecimal representation in G.709 vs decimal in > GMPLS considerations > > Encoding in GMPLS foresses the utilization of hexadecimal values > format "0x" while in the data plane documents, like G.709 > reccomendation, the format usually used is the decimal one (e.g. > G-PID in RSVP-TE vs Payload Type in G.709). > Assuming we go this way: I understand your intent, but I think you're actually stating exactly the opposite. How about, simply: Note that the Payload Types (PT) defined in [G709-2012], and repeated in this document, are provided in hexadecimal representation without the commonly used '0x' prefix. Lou > BR > Daniele & Sergio > >> -----Original Message----- >> From: ccamp issue tracker [mailto:trac+ccamp@trac.tools.ietf.org] >> Sent: mercoledì 8 maggio 2013 19.22 >> To: draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; >> lberger@labn.net >> Cc: ccamp-chairs@tools.ietf.org >> Subject: [CCAMP WG] #50: Identification of hexadecimal >> representation in G.709 vs decimal in GMPLS >> >> #50: Identification of hexadecimal representation in G.709 vs >> decimal in GMPLS >> >> From: http://www.ietf.org/mail-archive/web/ccamp/current/msg14812.html >> >> The authors had previously stated the intent to just make this clear >> in the signaling document. I'd like to make an alternate proposal: >> let's do the the obvious and have the documents simply use >> the normal >> (IETF) convention of using a '0x' prefix anytime a hexadecimal value >> is represented. I believe this means that only the info-model draft >> needs to be updated. >> >> -- >> -------------------------------------+------------------------- >> --------- >> -------------------------------------+--- >> Reporter: lberger@labn.net | Owner: draft-ietf-ccamp- >> Type: task | >> otn-g709-info-model@tools.ietf.org >> Priority: major | Status: new >> Component: otn-g709-info-model | Milestone: Post WG Last Call >> Severity: Waiting for Document | Version: >> Update | Keywords: >> -------------------------------------+------------------------- >> --------- >> -------------------------------------+--- >> >> Ticket URL: >> CCAMP WG Common Control and >> Measurement Plane Working Group >> > > > From acee.lindem@ericsson.com Mon May 13 04:36:19 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A38821F949F for ; Mon, 13 May 2013 04:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bJrwX-v4+T4 for ; Mon, 13 May 2013 04:36:14 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id E7BE721F949D for ; Mon, 13 May 2013 04:36:13 -0700 (PDT) X-AuditID: c6180641-b7f906d000003e3f-80-5190d02cfae7 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id B2.3B.15935.D20D0915; Mon, 13 May 2013 13:36:13 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0328.009; Mon, 13 May 2013 07:36:12 -0400 From: Acee Lindem To: Lou Berger Thread-Topic: [CCAMP] [CCAMP WG] #50: Identification of hexadecimal representation in G.709 vs decimal in GMPLS Thread-Index: AQHOTBCPGsuJYF0jUUyiGzymCk+foZkCx0EwgAB1boCAAApcAA== Date: Mon, 13 May 2013 11:36:11 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4714345F@eusaamb101.ericsson.se> References: <059.82d98e9dee0226e015a3852ed4c8eece@trac.tools.ietf.org> <4A1562797D64E44993C5CBF38CF1BE480C70F8@ESESSMB301.ericsson.se> <5190C777.2090100@labn.net> In-Reply-To: <5190C777.2090100@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <167D45AAA2FD614A98C5CC776C9325BC@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyuXRPlK7uhQmBBg9ei1tMPXqMzeLJnBss FlNmf2ex6Gh+y+LA4rFkyU8mjw+bmtk8vlz+zBbAHMVlk5Kak1mWWqRvl8CVsah1NUvBbpmK t0ueszUwvhHrYuTkkBAwkbh6/RkLhC0mceHeerYuRi4OIYGjjBJ/5z9ngXCWM0osXfeUDaSK TUBH4vmjf8wgtoiAosTXj4uYQIqYBZqYJBY+mMwEkhAWKJDYfnQFkM0BVFQo8eqCH0S9k0T7 snesIDaLgKrEpYV7wGbyCnhL7Lu+FWrZMkaJK8eb2UESnAIaEp86fjCC2IxA530/tQZsPrOA uMStJ/OZIM4WkFiy5zwzhC0q8fLxP1YIW1ni+5xHLBD1ehI3pk5hg7CtJbafuMUMYWtLLFv4 mhniCEGJkzOfsExgFJ+FZMUsJO2zkLTPQtI+C0n7AkbWVYwcpcWpZbnpRoabGIFxd0yCzXEH 44JPlocYpTlYlMR5E7kaA4UE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwTvGJ2J0s0tOVo/PP ov6nt/ZsF0u2k4c4V+0umKu7tO8dl9v+pZnSQkstxDfw/xdIybRcLCs2tz9XizOjz+Pp+tI7 sddrKtbKTWCI+X9rSemXsx93l4uuPdQYnThlAe/JI3q/jcU0e6+Z5yXVsT27++TxtHkH995w jfCpMPN9csT5TJTSrW92SizFGYmGWsxFxYkArZvJ44kCAAA= Cc: "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" , "ccamp-chairs@tools.ietf.org" , CCAMP Subject: Re: [CCAMP] [CCAMP WG] #50: Identification of hexadecimal representation in G.709 vs decimal in GMPLS X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 11:36:19 -0000 On May 13, 2013, at 6:59 AM, Lou Berger wrote: > Daniele, >=20 > On 5/13/2013 4:03 AM, Daniele Ceccarelli wrote: >> Lou, CCAMP, >>=20 >> This is the proposed text for the info-model wrt the decimal vs >> hexadecimal encoding issue. >>=20 >=20 > I think the author's preference of not using the 0x prefix to > hexadecimal representation is viable if it is clear in the document (as > you mention below) and you can point to precedent of similar usage in > existing RFCs. Have you checked / can you check to see if there's such? As a data point, OSPF RFCs and drafts always precede hexadecimal values wit= h 0x. Of course, the OSPF WG has a heritage of the authors also being softw= are developers. Unfortunately, I don't see any guidance here: http://www.rfc-editor.org/st= yleguide.html Thanks, Acee=20 >=20 >>=20 >>=20 >> 13. Identification of hexadecimal representation in G.709 vs decimal in >> GMPLS considerations >>=20 >> Encoding in GMPLS foresses the utilization of hexadecimal values >> format "0x" while in the data plane documents, like G.709 >> reccomendation, the format usually used is the decimal one (e.g. >> G-PID in RSVP-TE vs Payload Type in G.709).=20 >>=20 >=20 > Assuming we go this way: I understand your intent, but I think you're > actually stating exactly the opposite. How about, simply: >=20 > Note that the Payload Types (PT) defined in [G709-2012], and repeated > in this document, are provided in hexadecimal representation without > the commonly used '0x' prefix. >=20 > Lou >=20 >> BR >> Daniele & Sergio >>=20 >>> -----Original Message----- >>> From: ccamp issue tracker [mailto:trac+ccamp@trac.tools.ietf.org]=20 >>> Sent: mercoled=EC 8 maggio 2013 19.22 >>> To: draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org;=20 >>> lberger@labn.net >>> Cc: ccamp-chairs@tools.ietf.org >>> Subject: [CCAMP WG] #50: Identification of hexadecimal=20 >>> representation in G.709 vs decimal in GMPLS >>>=20 >>> #50: Identification of hexadecimal representation in G.709 vs=20 >>> decimal in GMPLS >>>=20 >>> From: http://www.ietf.org/mail-archive/web/ccamp/current/msg14812.html >>>=20 >>> The authors had previously stated the intent to just make this clear >>> in the signaling document. I'd like to make an alternate proposal: >>> let's do the the obvious and have the documents simply use=20 >>> the normal >>> (IETF) convention of using a '0x' prefix anytime a hexadecimal value >>> is represented. I believe this means that only the info-model draft >>> needs to be updated. >>>=20 >>> --=20 >>> -------------------------------------+------------------------- >>> --------- >>> -------------------------------------+--- >>> Reporter: lberger@labn.net | Owner: draft-ietf-ccamp- >>> Type: task | =20 >>> otn-g709-info-model@tools.ietf.org >>> Priority: major | Status: new >>> Component: otn-g709-info-model | Milestone: Post WG Last Call >>> Severity: Waiting for Document | Version: >>> Update | Keywords: >>> -------------------------------------+------------------------- >>> --------- >>> -------------------------------------+--- >>>=20 >>> Ticket URL: >>> CCAMP WG Common Control and=20 >>> Measurement Plane Working Group >>>=20 >>=20 >>=20 >>=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From julien.meuric@orange.com Mon May 13 09:33:22 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1880421F8F07 for ; Mon, 13 May 2013 09:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oB2OaktHVTkn for ; Mon, 13 May 2013 09:33:17 -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 82CFB21F8EFC for ; Mon, 13 May 2013 09:33:17 -0700 (PDT) Received: from r-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2366FA442DD; Mon, 13 May 2013 18:34:59 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.orange.com (Postfix) with ESMTP id 16364A442DC; Mon, 13 May 2013 18:34:59 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 May 2013 18:33:16 +0200 Received: from [10.193.71.218] ([10.193.71.218]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 May 2013 18:33:13 +0200 Message-ID: <519115C1.9080507@orange.com> Date: Mon, 13 May 2013 18:33:05 +0200 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Lou Berger , Daniele Ceccarelli References: <059.82d98e9dee0226e015a3852ed4c8eece@trac.tools.ietf.org> <4A1562797D64E44993C5CBF38CF1BE480C70F8@ESESSMB301.ericsson.se> <5190C777.2090100@labn.net> In-Reply-To: <5190C777.2090100@labn.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 May 2013 16:33:15.0232 (UTC) FILETIME=[9139BE00:01CE4FF7] Cc: "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" , CCAMP Subject: Re: [CCAMP] [CCAMP WG] #50: Identification of hexadecimal representation in G.709 vs decimal in GMPLS X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 16:33:22 -0000 Hi. On my right, a simple prefix that makes values clear and unambiguous at reading time, without the burden of references' context; on my left, 2 confusing statements that will no more be in mind when reading figures... I have often heard comments about RFC readability and the needed IETF background to understand what is not explicit: 2 more characters per figure would be both helpful and harmless. By the way, the IANA registry about GMPLS makes use of the '0x' prefix: http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parameters.xml#gmpls-sig-parameters-8 Regards, Julien On 05/13/2013 12:59, Lou Berger wrote: >> >13. Identification of hexadecimal representation in G.709 vs decimal in >> > GMPLS considerations >> > >> > Encoding in GMPLS foresses the utilization of hexadecimal values >> > format "0x" while in the data plane documents, like G.709 >> > reccomendation, the format usually used is the decimal one (e.g. >> > G-PID in RSVP-TE vs Payload Type in G.709). >> > > Assuming we go this way: I understand your intent, but I think you're > actually stating exactly the opposite. How about, simply: > > Note that the Payload Types (PT) defined in [G709-2012], and repeated > in this document, are provided in hexadecimal representation without > the commonly used '0x' prefix. From lberger@labn.net Mon May 13 10:31:18 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC2421F93DE for ; Mon, 13 May 2013 10:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.159 X-Spam-Level: X-Spam-Status: No, score=-102.159 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrqHyGvSqVEl for ; Mon, 13 May 2013 10:31:13 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 8428C21F93EB for ; Mon, 13 May 2013 10:31:13 -0700 (PDT) Received: (qmail 1548 invoked by uid 0); 13 May 2013 17:29:55 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 13 May 2013 17:29:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=+J7WsLCChodL/GeNOLAIY3vG3QmuKdol4yKtIQekc2g=; b=nBnuZwtrUm7XRdO1dGAw0o8s4tncM7BeFUt30IdyTlUti2B4DqPxvuKFyM1sfacyGHIwvbvXdoAErinuipthvyNs40BB5pEaWaXLh5YQAvpuUGVOdIccxpmVJOqErSLK; Received: from box313.bluehost.com ([69.89.31.113]:54971 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UbwZP-0003WM-FV; Mon, 13 May 2013 11:29:55 -0600 Message-ID: <51912312.9070903@labn.net> Date: Mon, 13 May 2013 13:29:54 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Julien Meuric , CCAMP References: <059.82d98e9dee0226e015a3852ed4c8eece@trac.tools.ietf.org> <4A1562797D64E44993C5CBF38CF1BE480C70F8@ESESSMB301.ericsson.se> <5190C777.2090100@labn.net> <519115C1.9080507@orange.com> In-Reply-To: <519115C1.9080507@orange.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" Subject: Re: [CCAMP] [CCAMP WG] #50: Identification of hexadecimal representation in G.709 vs decimal in GMPLS X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 17:31:18 -0000 Julien, I think you win on this one. Authors, Please add a '0x' prefix to any hexadecimal value in the draft. In other words: s/=2/=0x2 s/ 20/ 0x20 s/ 21/ 0x21 Lou On 5/13/2013 12:33 PM, Julien Meuric wrote: > Hi. > > On my right, a simple prefix that makes values clear and unambiguous at > reading time, without the burden of references' context; on my left, 2 > confusing statements that will no more be in mind when reading figures... > I have often heard comments about RFC readability and the needed IETF > background to understand what is not explicit: 2 more characters per > figure would be both helpful and harmless. > > By the way, the IANA registry about GMPLS makes use of the '0x' prefix: > http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parameters.xml#gmpls-sig-parameters-8 > > Regards, > > Julien > > > On 05/13/2013 12:59, Lou Berger wrote: >>>> 13. Identification of hexadecimal representation in G.709 vs decimal in >>>> GMPLS considerations >>>> >>>> Encoding in GMPLS foresses the utilization of hexadecimal values >>>> format "0x" while in the data plane documents, like G.709 >>>> reccomendation, the format usually used is the decimal one (e.g. >>>> G-PID in RSVP-TE vs Payload Type in G.709). >>>> >> Assuming we go this way: I understand your intent, but I think you're >> actually stating exactly the opposite. How about, simply: >> >> Note that the Payload Types (PT) defined in [G709-2012], and repeated >> in this document, are provided in hexadecimal representation without >> the commonly used '0x' prefix. > > > > > From internet-drafts@ietf.org Mon May 13 11:48:58 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBA921F9408; Mon, 13 May 2013 11:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.33 X-Spam-Level: X-Spam-Status: No, score=-102.33 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBds3AS2uw8V; Mon, 13 May 2013 11:48:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2880821F9362; Mon, 13 May 2013 11:48:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p7 Message-ID: <20130513184857.4752.63578.idtracker@ietfa.amsl.com> Date: Mon, 13 May 2013 11:48:57 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-rwa-info-18.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 18:48:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : Routing and Wavelength Assignment Information Model for = Wavelength Switched Optical Networks Author(s) : Young Lee Greg M. Bernstein Dan Li Wataru Imajuku Filename : draft-ietf-ccamp-rwa-info-18.txt Pages : 28 Date : 2013-05-13 Abstract: This document provides a model of information needed by the routing and wavelength assignment (RWA) process in wavelength switched optical networks (WSONs). The purpose of the information described in this model is to facilitate constrained lightpath computation in WSONs. This model takes into account compatibility constraints between WSON signal attributes and network elements but does not include constraints due to optical impairments. Aspects of this information that may be of use to other technologies utilizing a GMPLS control plane are discussed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-info There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-rwa-info-18 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-rwa-info-18 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From leeyoung@huawei.com Mon May 13 11:56:06 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAA6421F93FF for ; Mon, 13 May 2013 11:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qAaI2G84sudD for ; Mon, 13 May 2013 11:56:02 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB5421F9227 for ; Mon, 13 May 2013 11:56:02 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARI56601; Mon, 13 May 2013 18:56:00 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 13 May 2013 19:55:30 +0100 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 13 May 2013 19:55:56 +0100 Received: from dfweml511-mbs.china.huawei.com ([169.254.15.13]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.007; Mon, 13 May 2013 11:55:50 -0700 From: Leeyoung To: "ccamp@ietf.org" Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-rwa-info-18.txt Thread-Index: AQHOUAqSg8q+O364ykCk4W4DFgXqj5kDdSmQ Date: Mon, 13 May 2013 18:55:49 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172913D047@dfweml511-mbs.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.193] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [CCAMP] FW: I-D Action: draft-ietf-ccamp-rwa-info-18.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 18:56:06 -0000 Hi, This update (v.18) revived the expired draft with the added clarification t= exts thanks to Lou. The major changes are as follows: 1. is added in in Section 5.2 as follows: :=3D [][] 2. Clarified the scope of Section 6 (Link Advertisement) that these additional link characteristics defined in Section 6 only applies to line side ports of WDM system or add/drop ports pertaining to Resource Pool (e.g., Regenerator or Wavelength Converter Pool) and not intended for ingress/egress tributary ports. Let me know if you have any question on this change or any comment on the u= pdated draft.=20 Regards, Young -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org Sent: Monday, May 13, 2013 1:49 PM To: i-d-announce@ietf.org Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-rwa-info-18.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : Routing and Wavelength Assignment Information Model for = Wavelength Switched Optical Networks Author(s) : Young Lee Greg M. Bernstein Dan Li Wataru Imajuku Filename : draft-ietf-ccamp-rwa-info-18.txt Pages : 28 Date : 2013-05-13 Abstract: This document provides a model of information needed by the routing and wavelength assignment (RWA) process in wavelength switched optical networks (WSONs). The purpose of the information described in this model is to facilitate constrained lightpath computation in WSONs. This model takes into account compatibility constraints between WSON signal attributes and network elements but does not include constraints due to optical impairments. Aspects of this information that may be of use to other technologies utilizing a GMPLS control plane are discussed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-info There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-rwa-info-18 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-rwa-info-18 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From db3546@att.com Mon May 13 13:22:23 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C367921F9418 for ; Mon, 13 May 2013 13:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9t7TS3iL1lB for ; Mon, 13 May 2013 13:22:14 -0700 (PDT) Received: from nbfkord-smmo08.seg.att.com (nbfkord-smmo08.seg.att.com [209.65.160.95]) by ietfa.amsl.com (Postfix) with ESMTP id 22ACD21F944F for ; Mon, 13 May 2013 13:22:05 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id c6b41915.0.138084.00-434.374814.nbfkord-smmo08.seg.att.com (envelope-from ); Mon, 13 May 2013 20:22:05 +0000 (UTC) X-MXL-Hash: 51914b6d27f20632-e755016259bb497b5c1b6e4572809651f972657d Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4DKM3lj010786 for ; Mon, 13 May 2013 16:22:04 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4DKLxUe010746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 13 May 2013 16:22:01 -0400 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by mlpi407.sfdc.sbc.com (RSA Interceptor) for ; Mon, 13 May 2013 20:21:42 GMT Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([144.151.223.75]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.02.0342.003; Mon, 13 May 2013 16:21:42 -0400 From: "BRUNGARD, DEBORAH A" To: "ccamp@ietf.org" Thread-Topic: WG Last Call on draft-ietf-ccamp-swcaps-update-01.txt Thread-Index: Ac5CpFGQuVimYnF0R+e2aPHfvQiJcgNcuhWw Date: Mon, 13 May 2013 20:21:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.214] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C82D1CC9MISOUT7MSGUSR9OIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=Mc3bTeDf c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=RWEAq7CW3jcA:10 a=S6dYDceHAyUA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=yDBFPc251] X-AnalysisOut: [QoA:10 a=48vgC7mUAAAA:8 a=H6B-juurdWfqTugIcE0A:9 a=CjuIK1q] X-AnalysisOut: [_8ugA:10 a=lZB815dzVvQA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA] X-AnalysisOut: [:8 a=_R54jnd5ji0U7t9ElTUA:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S] X-AnalysisOut: [4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=XorKDfDefI3mEC] X-AnalysisOut: [d3:21] Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-swcaps-update-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 20:22:23 -0000 --_000_F64C10EAA68C8044B33656FA214632C82D1CC9MISOUT7MSGUSR9OIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This WG Last Call has ended. I will prepare the publication request. Thanks, Deborah From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of B= RUNGARD, DEBORAH A Sent: Friday, April 26, 2013 1:35 PM To: ccamp@ietf.org Subject: [CCAMP] WG Last Call on draft-ietf-ccamp-swcaps-update-01.txt All, This starts a two-week working group last call on draft-ietf-ccamp-swcaps-u= pdate-01.txt. This working group last call ends May 10th, 2013. Please send your comments to the CCAMP mailing list. Deborah (and Lou) --_000_F64C10EAA68C8044B33656FA214632C82D1CC9MISOUT7MSGUSR9OIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This WG Last Call has end= ed.

 <= /p>

I will prepare the public= ation request.

 <= /p>

Thanks,=

Deborah=

 <= /p>

From: ccamp-bo= unces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A
Sent: Friday, April 26, 2013 1:35 PM
To: ccamp@ietf.org
Subject: [CCAMP] WG Last Call on draft-ietf-ccamp-swcaps-update-01.t= xt

 

All,

 

This starts a two-week working group la= st call on draft-ietf-ccamp-swcaps-update-01.txt.

 

This working group last call ends May 1= 0th, 2013.

 

Please send your comments to the CCAMP = mailing list.

 

Deborah (and Lou)

 

 

--_000_F64C10EAA68C8044B33656FA214632C82D1CC9MISOUT7MSGUSR9OIT_-- From zhangfatai@huawei.com Mon May 13 22:53:30 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16C2521F94CC for ; Mon, 13 May 2013 22:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGGewGj2UR8J for ; Mon, 13 May 2013 22:53:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C96B921F8916 for ; Mon, 13 May 2013 22:53:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AST75468; Tue, 14 May 2013 05:53:13 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 14 May 2013 06:52:43 +0100 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 14 May 2013 06:53:10 +0100 Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.222]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.007; Tue, 14 May 2013 13:53:05 +0800 From: Fatai Zhang To: "BELOTTI, SERGIO (SERGIO)" , Lou Berger Thread-Topic: Closing G.709 open issues Thread-Index: AQHOTAyDmhSnK0jr+ESubR/xu8VPgpj8bQiw///u0ICAADKIAIAABpSAgAEN6tCAADjpAIAEmsGw///G7YCAAffecA== Date: Tue, 14 May 2013 05:53:03 +0000 Message-ID: References: <518A82D9.7080508@labn.net> <518BAB17.9090807@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> <518CED28.30303@labn.net> 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.66.72.159] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" , CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" Subject: Re: [CCAMP] Closing G.709 open issues X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 05:53:30 -0000 Hi all, Thanks, Sergio. I would like to double check if everything is OK before we update the signa= ling draft. I would assume the WG is happy with 1:1 mapping approach and the new GPIDs = listed below if there is no more comment until this Wed.=20 Best Regards Fatai -----Original Message----- From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-lucent.com]=20 Sent: Monday, May 13, 2013 3:45 PM To: Fatai Zhang; Lou Berger Cc: Daniele Ceccarelli; CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tool= s.ietf.org; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org Subject: R: Closing G.709 open issues Hi Fatai, I agree with you, for both point 1 and 2. Best Regards Sergio Belotti Sergio- System Architect ALCATE-LUCENT Optics Division via Trento 30 Vimercate (MB) - Italy phone +39 (039) 6863033 -----Messaggio originale----- Da: Fatai Zhang [mailto:zhangfatai@huawei.com]=20 Inviato: luned=EC 13 maggio 2013 5.33 A: Lou Berger Cc: Daniele Ceccarelli; CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tool= s.ietf.org; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org Oggetto: RE: Closing G.709 open issues Hi Lou, I think you have two major points here.=20 (1) Do you really need 3 G-PID types for an ODU (I thought TSG was already = covered)? I think this has been discussed for quite long time before Vancouver meetin= g, which was famous as "penultimate" issue. Note that this TSG in GPID is d= ifferent from the *implicit* TSG in label format. I don't think we need discuss this anymore. (2) 'Grouped GPID' vs '1:1' mapping (between G.709-2012 and GPIDs defined i= n this draft) We realize that it is safe to use 1:1 mapping approach to avoid some potent= ial issues after investigation. We know this payload types have been define= d by G.709 (data plane), so physically it is better to use 1:1 mapping appr= oach.=20 For the potential issues I mentioned above, for example, we cannot use the = existing 34 to represent 'STM-1' and 'STM-4 ', because it is impossible to = differentiate which one is 'STM-1' or 'STM-4'. In addition, from the concep= t of payload type, we know that e.g, FC-100 is different from FC-800, right= ? So, it is better to assign different GPIDs to these different payload typ= es defined by the data plane. Furthermore, I think it is much cheaper to create new GPIDs in the control = plane than in the data plane (these payload types will be carried in the OH= ).=20 Best Regards Fatai -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Friday, May 10, 2013 8:51 PM To: Fatai Zhang Cc: Daniele Ceccarelli; CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tool= s.ietf.org; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org Subject: Re: Closing G.709 open issues On 5/9/2013 9:41 PM, Fatai Zhang wrote: > Hi Lou, >=20 > For point 1), "1" should be dropped and "7" should be corrected to "8" in= your proposed text.=20 Great. >=20 > I hesitate to make a decision on either approach, I would like to defer t= o the WG consensus. >=20 I believe we already have a consensus position. The question in my mail was do we need to revisit it. I take your response as a no. (thank you!) > For point 2), I compared [G.709-2003] and [G.709-2012], and checked > the GPIDs defined in [RFC4328], I think the following new GPIDs > (values could be 59-79) should be added (besides updating some GPIDs > defined in RFC4328, like 32,47,49-52): >=20 I suggest going through the full PT list and identifying them in the table (as I started in my last message) so that there is no confusion in implementations. In the list below it looks like you have moved away from the 'grouped G-PID' approach. Is there a reason for this change? Refer to http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parameters.x= ml in subsequent comments. > Value G-PID Type LSP Encoding Type > ----- ---------- ----------------- > 59(TBA) G.709 ODU-1.25G G.709 ODUk=20 > 60(TBA) G.709 ODU-any G.709 ODUk Do you really need 3 G-PID types for an ODU (I thought TSG was already covered)? > 61(TBA) PCS G.709 ODUk (k=3D0) > 62(TBA) FC-1200 G.709 ODUk (k=3D2e) Why not us existing G-PID 58? > 63(TBA) eOPU2 G.709 ODUk (k=3D2) > 64(TBA) STM-1 G.709 ODUk (k=3D0) > 65(TBA) STM-4 G.709 ODUk (k=3D0) Why not us existing G-PID 34? > 66(TBA) FC-100 G.709 ODUk (k=3D0) > 67(TBA) FC-200 G.709 ODUk (k=3D1) > 68(TBA) FC-400 G.709 ODUflex > 69(TBA) FC-800 G.709 ODUflex Why not us existing G-PID 58? > 70(TBA) IB SDR G.709 ODUflex > 71(TBA) IB DDR G.709 ODUflex > 72(TBA) IB QDR G.709 ODUflex Can these be one value with rate implying SDR/DDR/QDR? > 73(TBA) SDIa G.709 ODUk (k=3D0) > 74(TBA) SDIb G.709 ODUk (k=3D1) > 75(TBA) SDIc G.709 ODUk (k=3D1) > 76(TBA) SDId G.709 ODUflex > 77(TBA) SDIe G.709 ODUflex Can these be one value with rate implying a-e? > 78(TBA) SB/ESCON G.709 ODUk (k=3D0) Why not us existing G-PID 56? > 79(TBA) DVB_ASI G.709 ODUk (k=3D0) >=20 >=20 >=20 >=20 Thanks, Lou From lberger@labn.net Tue May 14 07:01:06 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA1021F8F12 for ; Tue, 14 May 2013 07:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.842 X-Spam-Level: X-Spam-Status: No, score=-102.842 tagged_above=-999 required=5 tests=[AWL=0.757, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1lqnVIv31Hr for ; Tue, 14 May 2013 07:01:01 -0700 (PDT) Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id C745121F8501 for ; Tue, 14 May 2013 07:01:01 -0700 (PDT) Received: (qmail 2155 invoked by uid 0); 14 May 2013 14:00:38 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy12.bluehost.com with SMTP; 14 May 2013 14:00:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=EuS/hd0Xp3nxzXBXCzbz4jYUf9AJOvlBXc/g+RNDfcc=; b=B6874bJGgfJwVwbOf0kNIPhSrqEPyBVW+QZKj9XWYqB16fuQARx2NhD9kbpT1HkNlLwibnTFkJyqeR/jAfozqFh0PO/43dJgX0z1AxlQMmSzfmrGhjGgwefFYLhgJ/EM; Received: from box313.bluehost.com ([69.89.31.113]:50961 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UcFmN-0007Z5-8h; Tue, 14 May 2013 08:00:35 -0600 Message-ID: <51924382.2010904@labn.net> Date: Tue, 14 May 2013 10:00:34 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Fatai Zhang References: <518A82D9.7080508@labn.net> <518BAB17.9090807@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> <518CED28.30303@labn.net> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" , CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" Subject: Re: [CCAMP] Closing G.709 open issues X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 14:01:06 -0000 Fatai, Sergio, I haven't had time to go find the old mail covering the topic you mentioned (which is why I didn't respond yesterday): > I think this has been discussed for quite long time before Vancouver > meeting, which was famous as "penultimate" issue. > > I don't think we need discuss this anymore. My memory is that the consensus at the time was that G.709 would continue to use the current generic approach to edge adaptation & G-PIDs, and that (some of) the G.709 authors would submit a draft that would address adaptation in a generic fashion. Do you think this characterization is mistaken? (If so, time to go searching for the old discussion, if not we can move on.) Assuming no, then it seems to me that you are going against this discussion & consensus by now introducing a 1:1/bandwidth specific mapping approach. Do you disagree? If not, do you think there's justification to reopen this discussion? Independent of the mapping approach and in order to ensure this issue is closed and does not again resurface, I also request (again) that the editors of the draft provide (and include in the document) a full list of Payload Type values (with the 0x value prefix or the values in decimal) and their corresponding G-PID values. Also including Encoding Type as you have below is a good addition -- great idea! Lou On 5/14/2013 1:53 AM, Fatai Zhang wrote: > Hi all, > > Thanks, Sergio. > > I would like to double check if everything is OK before we update the signaling draft. > > I would assume the WG is happy with 1:1 mapping approach and the new GPIDs listed below if there is no more comment until this Wed. > > > > > Best Regards > > Fatai > > > -----Original Message----- > From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-lucent.com] > Sent: Monday, May 13, 2013 3:45 PM > To: Fatai Zhang; Lou Berger > Cc: Daniele Ceccarelli; CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org > Subject: R: Closing G.709 open issues > > Hi Fatai, > > I agree with you, for both point 1 and 2. > > Best Regards > Sergio > > Belotti Sergio- System Architect > ALCATE-LUCENT Optics Division > via Trento 30 Vimercate (MB) - Italy > phone +39 (039) 6863033 > -----Messaggio originale----- > Da: Fatai Zhang [mailto:zhangfatai@huawei.com] > Inviato: lunedì 13 maggio 2013 5.33 > A: Lou Berger > Cc: Daniele Ceccarelli; CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org > Oggetto: RE: Closing G.709 open issues > > Hi Lou, > > I think you have two major points here. > > (1) Do you really need 3 G-PID types for an ODU (I thought TSG was already covered)? > > I think this has been discussed for quite long time before Vancouver meeting, which was famous as "penultimate" issue. Note that this TSG in GPID is different from the *implicit* TSG in label format. > > I don't think we need discuss this anymore. > > (2) 'Grouped GPID' vs '1:1' mapping (between G.709-2012 and GPIDs defined in this draft) > > We realize that it is safe to use 1:1 mapping approach to avoid some potential issues after investigation. We know this payload types have been defined by G.709 (data plane), so physically it is better to use 1:1 mapping approach. > For the potential issues I mentioned above, for example, we cannot use the existing 34 to represent 'STM-1' and 'STM-4 ', because it is impossible to differentiate which one is 'STM-1' or 'STM-4'. In addition, from the concept of payload type, we know that e.g, FC-100 is different from FC-800, right? So, it is better to assign different GPIDs to these different payload types defined by the data plane. > > Furthermore, I think it is much cheaper to create new GPIDs in the control plane than in the data plane (these payload types will be carried in the OH). > > > > > Best Regards > > Fatai > > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Friday, May 10, 2013 8:51 PM > To: Fatai Zhang > Cc: Daniele Ceccarelli; CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org > Subject: Re: Closing G.709 open issues > > > > On 5/9/2013 9:41 PM, Fatai Zhang wrote: >> Hi Lou, >> >> For point 1), "1" should be dropped and "7" should be corrected to "8" in your proposed text. > > Great. > >> >> I hesitate to make a decision on either approach, I would like to defer to the WG consensus. >> > > I believe we already have a consensus position. The question in my mail > was do we need to revisit it. I take your response as a no. (thank you!) > >> For point 2), I compared [G.709-2003] and [G.709-2012], and checked >> the GPIDs defined in [RFC4328], I think the following new GPIDs >> (values could be 59-79) should be added (besides updating some GPIDs >> defined in RFC4328, like 32,47,49-52): >> > > I suggest going through the full PT list and identifying them in the > table (as I started in my last message) so that there is no confusion in > implementations. > > In the list below it looks like you have moved away from the 'grouped > G-PID' approach. Is there a reason for this change? > > Refer to > http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parameters.xml > in subsequent comments. > >> Value G-PID Type LSP Encoding Type >> ----- ---------- ----------------- >> 59(TBA) G.709 ODU-1.25G G.709 ODUk >> 60(TBA) G.709 ODU-any G.709 ODUk > > Do you really need 3 G-PID types for an ODU (I thought TSG was already > covered)? > >> 61(TBA) PCS G.709 ODUk (k=0) >> 62(TBA) FC-1200 G.709 ODUk (k=2e) > Why not us existing G-PID 58? > >> 63(TBA) eOPU2 G.709 ODUk (k=2) > >> 64(TBA) STM-1 G.709 ODUk (k=0) >> 65(TBA) STM-4 G.709 ODUk (k=0) > Why not us existing G-PID 34? > >> 66(TBA) FC-100 G.709 ODUk (k=0) >> 67(TBA) FC-200 G.709 ODUk (k=1) >> 68(TBA) FC-400 G.709 ODUflex >> 69(TBA) FC-800 G.709 ODUflex > Why not us existing G-PID 58? > >> 70(TBA) IB SDR G.709 ODUflex >> 71(TBA) IB DDR G.709 ODUflex >> 72(TBA) IB QDR G.709 ODUflex > Can these be one value with rate implying SDR/DDR/QDR? > >> 73(TBA) SDIa G.709 ODUk (k=0) >> 74(TBA) SDIb G.709 ODUk (k=1) >> 75(TBA) SDIc G.709 ODUk (k=1) >> 76(TBA) SDId G.709 ODUflex >> 77(TBA) SDIe G.709 ODUflex > > Can these be one value with rate implying a-e? > >> 78(TBA) SB/ESCON G.709 ODUk (k=0) > Why not us existing G-PID 56? > >> 79(TBA) DVB_ASI G.709 ODUk (k=0) >> >> >> >> > > Thanks, > Lou > > > > > > From lberger@labn.net Tue May 14 09:18:21 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F97E21F8506 for ; Tue, 14 May 2013 09:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.936 X-Spam-Level: X-Spam-Status: No, score=-102.936 tagged_above=-999 required=5 tests=[AWL=0.663, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oemw7qJ5rCIg for ; Tue, 14 May 2013 09:18:10 -0700 (PDT) Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id 7CB7D21F8721 for ; Tue, 14 May 2013 09:18:00 -0700 (PDT) Received: (qmail 3769 invoked by uid 0); 14 May 2013 16:17:31 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy12.bluehost.com with SMTP; 14 May 2013 16:17:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=zScy72Aa8fID77Xlan9iqLUwFusfxqto3ptmWACo9eA=; b=tm/3IQEqTK0BGPbFy+3zAjD0vC7bUDMFu9P3ExHPdS6Y47teH18wD+122Wobyvh0fijAmxL/687hjbnexwkdQPxiFrTNdBlgL1TMJ3v6J5DzYPRBzgZlCo/GICaztE4U; Received: from box313.bluehost.com ([69.89.31.113]:43244 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UcHus-0001sR-CN; Tue, 14 May 2013 10:17:30 -0600 Message-ID: <5192639A.7090203@labn.net> Date: Tue, 14 May 2013 12:17:30 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Leeyoung References: <7AEB3D6833318045B4AE71C2C87E8E172913D047@dfweml511-mbs.china.huawei.com> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E172913D047@dfweml511-mbs.china.huawei.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-rwa-info-18.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 16:18:56 -0000 Young/WSON authors, Can you confirm that there are no other outstanding actions on the WSON documents other than an update to the signaling document (based on prior discussions)? Much thanks, Lou On 5/13/2013 2:55 PM, Leeyoung wrote: > Hi, > > This update (v.18) revived the expired draft with the added clarification texts thanks to Lou. > > The major changes are as follows: > > 1. is added in in Section 5.2 as > follows: := > [][] > > 2. Clarified the scope of Section 6 (Link Advertisement) that these > additional link characteristics defined in Section 6 only applies to > line side ports of WDM system or add/drop ports pertaining to > Resource Pool (e.g., Regenerator or Wavelength Converter Pool) and > not intended for ingress/egress tributary ports. > > Let me know if you have any question on this change or any comment on the updated draft. > > Regards, > Young > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Monday, May 13, 2013 1:49 PM > To: i-d-announce@ietf.org > Cc: ccamp@ietf.org > Subject: [CCAMP] I-D Action: draft-ietf-ccamp-rwa-info-18.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. > > Title : Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks > Author(s) : Young Lee > Greg M. Bernstein > Dan Li > Wataru Imajuku > Filename : draft-ietf-ccamp-rwa-info-18.txt > Pages : 28 > Date : 2013-05-13 > > Abstract: > This document provides a model of information needed by the routing > and wavelength assignment (RWA) process in wavelength switched > optical networks (WSONs). The purpose of the information described > in this model is to facilitate constrained lightpath computation in > WSONs. This model takes into account compatibility constraints > between WSON signal attributes and network elements but does not > include constraints due to optical impairments. Aspects of this > information that may be of use to other technologies utilizing a > GMPLS control plane are discussed. > > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-info > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ccamp-rwa-info-18 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-rwa-info-18 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > > From leeyoung@huawei.com Tue May 14 10:04:26 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55EFC21F901A for ; Tue, 14 May 2013 10:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbv+OhaC-B-H for ; Tue, 14 May 2013 10:04:15 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 54ECD11E8106 for ; Tue, 14 May 2013 10:03:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASU33763; Tue, 14 May 2013 17:03:52 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 14 May 2013 18:03:22 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 14 May 2013 18:03:51 +0100 Received: from dfweml511-mbs.china.huawei.com ([169.254.15.13]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.007; Tue, 14 May 2013 10:03:47 -0700 From: Leeyoung To: Lou Berger Thread-Topic: [CCAMP] FW: I-D Action: draft-ietf-ccamp-rwa-info-18.txt Thread-Index: AQHOUL6bG9QwrBEd8UGt6sEwiqWTaZkE5/mA Date: Tue, 14 May 2013 17:03:46 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172913DFF0@dfweml511-mbs.china.huawei.com> References: <7AEB3D6833318045B4AE71C2C87E8E172913D047@dfweml511-mbs.china.huawei.com> <5192639A.7090203@labn.net> In-Reply-To: <5192639A.7090203@labn.net> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.156.164] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-rwa-info-18.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 17:04:28 -0000 Hi Lou, There are no outstanding actions on the WSON documents. We only need to upd= ate signaling draft based on the last IETF meeting discussion, which will b= e shortly updated.=20 Thanks. Young -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Tuesday, May 14, 2013 11:18 AM To: Leeyoung Cc: ccamp@ietf.org Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-rwa-info-18.txt Young/WSON authors, Can you confirm that there are no other outstanding actions on the WSON do= cuments other than an update to the signaling document (based on prior disc= ussions)? Much thanks, Lou On 5/13/2013 2:55 PM, Leeyoung wrote: > Hi, >=20 > This update (v.18) revived the expired draft with the added clarification= texts thanks to Lou. >=20 > The major changes are as follows: >=20 > 1. is added in in Section 5.2 as > follows: :=3D > [][] >=20 > 2. Clarified the scope of Section 6 (Link Advertisement) that these > additional link characteristics defined in Section 6 only applies to > line side ports of WDM system or add/drop ports pertaining to > Resource Pool (e.g., Regenerator or Wavelength Converter Pool) and > not intended for ingress/egress tributary ports. >=20 > Let me know if you have any question on this change or any comment on the= updated draft.=20 >=20 > Regards, > Young >=20 > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf=20 > Of internet-drafts@ietf.org > Sent: Monday, May 13, 2013 1:49 PM > To: i-d-announce@ietf.org > Cc: ccamp@ietf.org > Subject: [CCAMP] I-D Action: draft-ietf-ccamp-rwa-info-18.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 Common Control and Measurement Plane Wo= rking Group of the IETF. >=20 > Title : Routing and Wavelength Assignment Information Model fo= r Wavelength Switched Optical Networks > Author(s) : Young Lee > Greg M. Bernstein > Dan Li > Wataru Imajuku > Filename : draft-ietf-ccamp-rwa-info-18.txt > Pages : 28 > Date : 2013-05-13 >=20 > Abstract: > This document provides a model of information needed by the routing > and wavelength assignment (RWA) process in wavelength switched > optical networks (WSONs). The purpose of the information described > in this model is to facilitate constrained lightpath computation in > WSONs. This model takes into account compatibility constraints > between WSON signal attributes and network elements but does not > include constraints due to optical impairments. Aspects of this > information that may be of use to other technologies utilizing a > GMPLS control plane are discussed. >=20 >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-info >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ccamp-rwa-info-18 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-rwa-info-18 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp >=20 >=20 >=20 >=20 From lberger@labn.net Tue May 14 10:15:20 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7A2021F89E2 for ; Tue, 14 May 2013 10:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.343 X-Spam-Level: X-Spam-Status: No, score=-102.343 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zvM2Kj2ryww for ; Tue, 14 May 2013 10:15:16 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 530DD21F8696 for ; Tue, 14 May 2013 10:15:16 -0700 (PDT) Received: (qmail 6922 invoked by uid 0); 14 May 2013 17:14:54 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.bluehost.com with SMTP; 14 May 2013 17:14:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=7BwSC6uMQcskAH9pMRjZfP1BjIiQcHl1W/UCrcxDvDU=; b=TxGPGymcHKZqqTodNhfPOANNG2TXRcGHvJ0Wd3gFlF4ifMEr9jww3hEiQ1LOsWtw79rRBAbzlT/sudOuJVJOqcPXrMtRGSQ91d9DhYf5ymL4VV1r2AIOvbHxdPdy+nAb; Received: from box313.bluehost.com ([69.89.31.113]:51015 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UcIoQ-00089s-BD; Tue, 14 May 2013 11:14:54 -0600 Message-ID: <5192710E.7010905@labn.net> Date: Tue, 14 May 2013 13:14:54 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Leeyoung References: <7AEB3D6833318045B4AE71C2C87E8E172913D047@dfweml511-mbs.china.huawei.com> <5192639A.7090203@labn.net> <7AEB3D6833318045B4AE71C2C87E8E172913DFF0@dfweml511-mbs.china.huawei.com> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E172913DFF0@dfweml511-mbs.china.huawei.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-rwa-info-18.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 17:15:21 -0000 Young, Great. Sounds like we're in sync on future/planned/outstanding next steps. Lou On 5/14/2013 1:03 PM, Leeyoung wrote: > Hi Lou, > > There are no outstanding actions on the WSON documents. We only need to update signaling draft based on the last IETF meeting discussion, which will be shortly updated. > > Thanks. > Young > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Tuesday, May 14, 2013 11:18 AM > To: Leeyoung > Cc: ccamp@ietf.org > Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-rwa-info-18.txt > > Young/WSON authors, > Can you confirm that there are no other outstanding actions on the WSON documents other than an update to the signaling document (based on prior discussions)? > > Much thanks, > Lou > > On 5/13/2013 2:55 PM, Leeyoung wrote: >> Hi, >> >> This update (v.18) revived the expired draft with the added clarification texts thanks to Lou. >> >> The major changes are as follows: >> >> 1. is added in in Section 5.2 as >> follows: := >> [][] >> >> 2. Clarified the scope of Section 6 (Link Advertisement) that these >> additional link characteristics defined in Section 6 only applies to >> line side ports of WDM system or add/drop ports pertaining to >> Resource Pool (e.g., Regenerator or Wavelength Converter Pool) and >> not intended for ingress/egress tributary ports. >> >> Let me know if you have any question on this change or any comment on the updated draft. >> >> Regards, >> Young >> >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf >> Of internet-drafts@ietf.org >> Sent: Monday, May 13, 2013 1:49 PM >> To: i-d-announce@ietf.org >> Cc: ccamp@ietf.org >> Subject: [CCAMP] I-D Action: draft-ietf-ccamp-rwa-info-18.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. >> >> Title : Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks >> Author(s) : Young Lee >> Greg M. Bernstein >> Dan Li >> Wataru Imajuku >> Filename : draft-ietf-ccamp-rwa-info-18.txt >> Pages : 28 >> Date : 2013-05-13 >> >> Abstract: >> This document provides a model of information needed by the routing >> and wavelength assignment (RWA) process in wavelength switched >> optical networks (WSONs). The purpose of the information described >> in this model is to facilitate constrained lightpath computation in >> WSONs. This model takes into account compatibility constraints >> between WSON signal attributes and network elements but does not >> include constraints due to optical impairments. Aspects of this >> information that may be of use to other technologies utilizing a >> GMPLS control plane are discussed. >> >> >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-info >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-info-18 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-rwa-info-18 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> > > > > From daniele.ceccarelli@ericsson.com Wed May 15 01:20:41 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 773FB21F85C9 for ; Wed, 15 May 2013 01:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpldRXzQ0aI2 for ; Wed, 15 May 2013 01:20:32 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id C50B221F85DC for ; Wed, 15 May 2013 01:20:31 -0700 (PDT) X-AuditID: c1b4fb30-b7f3a6d0000007a4-0c-519345492f51 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id BC.CC.01956.94543915; Wed, 15 May 2013 10:20:26 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.55]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0328.009; Wed, 15 May 2013 10:20:25 +0200 From: Daniele Ceccarelli To: Lou Berger , Fatai Zhang Thread-Topic: Closing G.709 open issues Thread-Index: AQHOTAyAugJRODS18Eas2l6+kjNWaZj8T3QAgABw+YCAAExsIP//7LCAgACL7ICAALrnAIAEGysAgABGg4CAAXLugIAAiDYAgAFJbzA= Date: Wed, 15 May 2013 08:20:25 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE480C90D5@ESESSMB301.ericsson.se> References: <518A82D9.7080508@labn.net> <518BAB17.9090807@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> <518CED28.30303@labn.net> <51924382.2010904@labn.net> In-Reply-To: <51924382.2010904@labn.net> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM+Jvra6X6+RAg6W/eCyezLnBYrF19n1m iymzv7NYdDS/ZbFYtvk3u0Vf83lWBzaP1md7WT1ajrxl9Viy5CeTx4dNzWweXy5/ZgtgjeKy SUnNySxLLdK3S+DK+HHsH1PBRPeKVSt/MTUwbjfrYuTkkBAwkTj8aTsjhC0mceHeerYuRi4O IYHDjBLfzr5hhnAWM0qcuLIGyOHgYBOwknhyyAekQUTATWL+4tfsIDXMAoeYJFr+vGMDSQgL qEnsffuAEaJIXaJ36yJGkF4RgTKJnb1uIGEWAVWJo1d3soDYvALeEs/bl7FD7LrHIjHrWhNY L6eAhsS184uZQGxGAVmJCbsXgcWZBcQlbj2ZzwRxtYDEkj3nmSFsUYmXj/+xguySEFCUWN4v B1GuJ3Fj6hQ2CFtbYtnC18wQewUlTs58wjKBUWwWkqmzkLTMQtIyC0nLAkaWVYzsuYmZOenl 5psYgZF2cMtvgx2Mm+6LHWKU5mBREudN5moMFBJITyxJzU5NLUgtii8qzUktPsTIxMEp1cCo uazVQGapVrixvURdsNPNPgme+GeTXZIWL7xk/N7+Y//PFNl55TtzF5ueY1AoyV20tcXyzbpz h8IuxfSwbOp2yNZb+qloxeIQqxkOJ62/zmCfcfRd05H41O/RUz6++b7USn6ZPGewnI/7eiuJ 2dOi/C4Kmn0PezuL+/I5/pi/NSs27RQ4tahXiaU4I9FQi7moOBEAbgLo7YICAAA= Cc: CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" , "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" Subject: Re: [CCAMP] Closing G.709 open issues X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 08:20:41 -0000 Hi Lou, Just a bit.=20 >My memory is that the consensus at the time was that G.709=20 >would continue to use the current generic approach to edge=20 >adaptation & G-PIDs, and that (some of) the G.709 authors=20 >would submit a draft that would address adaptation in a=20 >generic fashion. > If i correctly remember we agreed to solve the routing issu in a generic ap= proach, not the signaling one. It is possible to assume that the adaptation is a known info to the operato= r and hence that the advertisement can be postponed and addressed in a gene= ric way but it needs to be signaled. This is an hortogonal issue with respect to the mapping of G-PID, which has= always been assumed to be 1:1 with G.709 values. The 1:1 *mapping* approach used by Fatai is different from the *mapping" pr= otocol like GFP, AMP that we discussed before. BR Daniele, Sergio, Fatai >-----Original Message----- >From: Lou Berger [mailto:lberger@labn.net]=20 >Sent: marted=EC 14 maggio 2013 16.01 >To: Fatai Zhang >Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP;=20 >draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org;=20 >draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org >Subject: Re: Closing G.709 open issues > >Fatai, Sergio, > I haven't had time to go find the old mail covering the=20 >topic you mentioned (which is why I didn't respond yesterday): >> I think this has been discussed for quite long time before Vancouver=20 >> meeting, which was famous as "penultimate" issue. >> >> I don't think we need discuss this anymore. > >My memory is that the consensus at the time was that G.709=20 >would continue to use the current generic approach to edge=20 >adaptation & G-PIDs, and that (some of) the G.709 authors=20 >would submit a draft that would address adaptation in a=20 >generic fashion. > >Do you think this characterization is mistaken? (If so, time=20 >to go searching for the old discussion, if not we can move on.) > >Assuming no, then it seems to me that you are going against=20 >this discussion & consensus by now introducing a 1:1/bandwidth=20 >specific mapping approach. Do you disagree? If not, do you=20 >think there's justification to reopen this discussion? > >Independent of the mapping approach and in order to ensure=20 >this issue is closed and does not again resurface, I also=20 >request (again) that the editors of the draft provide (and=20 >include in the document) a full list of Payload Type values=20 >(with the 0x value prefix or the values in >decimal) and their corresponding G-PID values. Also including=20 >Encoding Type as you have below is a good addition -- great idea! > >Lou > >On 5/14/2013 1:53 AM, Fatai Zhang wrote: >> Hi all, >>=20 >> Thanks, Sergio. >>=20 >> I would like to double check if everything is OK before we=20 >update the signaling draft. >>=20 >> I would assume the WG is happy with 1:1 mapping approach and=20 >the new GPIDs listed below if there is no more comment until this Wed.=20 >>=20 >>=20 >>=20 >>=20 >> Best Regards >>=20 >> Fatai >>=20 >>=20 >> -----Original Message----- >> From: BELOTTI, SERGIO (SERGIO)=20 >> [mailto:sergio.belotti@alcatel-lucent.com] >> Sent: Monday, May 13, 2013 3:45 PM >> To: Fatai Zhang; Lou Berger >> Cc: Daniele Ceccarelli; CCAMP;=20 >> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org;=20 >> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org >> Subject: R: Closing G.709 open issues >>=20 >> Hi Fatai, >>=20 >> I agree with you, for both point 1 and 2. >>=20 >> Best Regards >> Sergio >>=20 >> Belotti Sergio- System Architect >> ALCATE-LUCENT Optics Division >> via Trento 30 Vimercate (MB) - Italy >> phone +39 (039) 6863033 >> -----Messaggio originale----- >> Da: Fatai Zhang [mailto:zhangfatai@huawei.com] >> Inviato: luned=EC 13 maggio 2013 5.33 >> A: Lou Berger >> Cc: Daniele Ceccarelli; CCAMP;=20 >> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org;=20 >> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org >> Oggetto: RE: Closing G.709 open issues >>=20 >> Hi Lou, >>=20 >> I think you have two major points here.=20 >>=20 >> (1) Do you really need 3 G-PID types for an ODU (I thought=20 >TSG was already covered)? >>=20 >> I think this has been discussed for quite long time before=20 >Vancouver meeting, which was famous as "penultimate" issue.=20 >Note that this TSG in GPID is different from the *implicit*=20 >TSG in label format. >>=20 >> I don't think we need discuss this anymore. >>=20 >> (2) 'Grouped GPID' vs '1:1' mapping (between G.709-2012 and GPIDs=20 >> defined in this draft) >>=20 >> We realize that it is safe to use 1:1 mapping approach to=20 >avoid some potential issues after investigation. We know this=20 >payload types have been defined by G.709 (data plane), so=20 >physically it is better to use 1:1 mapping approach.=20 >> For the potential issues I mentioned above, for example, we=20 >cannot use the existing 34 to represent 'STM-1' and 'STM-4 ',=20 >because it is impossible to differentiate which one is 'STM-1'=20 >or 'STM-4'. In addition, from the concept of payload type, we=20 >know that e.g, FC-100 is different from FC-800, right? So, it=20 >is better to assign different GPIDs to these different payload=20 >types defined by the data plane. >>=20 >> Furthermore, I think it is much cheaper to create new GPIDs=20 >in the control plane than in the data plane (these payload=20 >types will be carried in the OH).=20 >>=20 >>=20 >>=20 >>=20 >> Best Regards >>=20 >> Fatai >>=20 >>=20 >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Friday, May 10, 2013 8:51 PM >> To: Fatai Zhang >> Cc: Daniele Ceccarelli; CCAMP;=20 >> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org;=20 >> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org >> Subject: Re: Closing G.709 open issues >>=20 >>=20 >>=20 >> On 5/9/2013 9:41 PM, Fatai Zhang wrote: >>> Hi Lou, >>> >>> For point 1), "1" should be dropped and "7" should be=20 >corrected to "8" in your proposed text.=20 >>=20 >> Great. >>=20 >>> >>> I hesitate to make a decision on either approach, I would=20 >like to defer to the WG consensus. >>> >>=20 >> I believe we already have a consensus position. The question in my=20 >> mail was do we need to revisit it. I take your response as a no.=20 >> (thank you!) >>=20 >>> For point 2), I compared [G.709-2003] and [G.709-2012], and checked=20 >>> the GPIDs defined in [RFC4328], I think the following new GPIDs=20 >>> (values could be 59-79) should be added (besides updating=20 >some GPIDs=20 >>> defined in RFC4328, like 32,47,49-52): >>> >>=20 >> I suggest going through the full PT list and identifying them in the=20 >> table (as I started in my last message) so that there is no=20 >confusion=20 >> in implementations. >>=20 >> In the list below it looks like you have moved away from the=20 >'grouped=20 >> G-PID' approach. Is there a reason for this change? >>=20 >> Refer to >>=20 >http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-paramet >> ers.xml >> in subsequent comments. >>=20 >>> Value G-PID Type LSP Encoding Type >>> ----- ---------- ----------------- >>> 59(TBA) G.709 ODU-1.25G G.709 ODUk=20 >>> 60(TBA) G.709 ODU-any G.709 ODUk >>=20 >> Do you really need 3 G-PID types for an ODU (I thought TSG=20 >was already=20 >> covered)? >>=20 >>> 61(TBA) PCS G.709 ODUk (k=3D0) >>> 62(TBA) FC-1200 G.709 ODUk (k=3D2e) >> Why not us existing G-PID 58? >>=20 >>> 63(TBA) eOPU2 G.709 ODUk (k=3D2) >>=20 >>> 64(TBA) STM-1 G.709 ODUk (k=3D0) >>> 65(TBA) STM-4 G.709 ODUk (k=3D0) >> Why not us existing G-PID 34? >>=20 >>> 66(TBA) FC-100 G.709 ODUk (k=3D0) >>> 67(TBA) FC-200 G.709 ODUk (k=3D1) >>> 68(TBA) FC-400 G.709 ODUflex >>> 69(TBA) FC-800 G.709 ODUflex >> Why not us existing G-PID 58? >>=20 >>> 70(TBA) IB SDR G.709 ODUflex >>> 71(TBA) IB DDR G.709 ODUflex >>> 72(TBA) IB QDR G.709 ODUflex >> Can these be one value with rate implying SDR/DDR/QDR? >>=20 >>> 73(TBA) SDIa G.709 ODUk (k=3D0) >>> 74(TBA) SDIb G.709 ODUk (k=3D1) >>> 75(TBA) SDIc G.709 ODUk (k=3D1) >>> 76(TBA) SDId G.709 ODUflex >>> 77(TBA) SDIe G.709 ODUflex >>=20 >> Can these be one value with rate implying a-e? >>=20 >>> 78(TBA) SB/ESCON G.709 ODUk (k=3D0) >> Why not us existing G-PID 56? >>=20 >>> 79(TBA) DVB_ASI G.709 ODUk (k=3D0) >>> >>> >>> >>> >>=20 >> Thanks, >> Lou >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >= From lberger@labn.net Wed May 15 04:22:52 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3A8B21F8EC1 for ; Wed, 15 May 2013 04:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.002 X-Spam-Level: X-Spam-Status: No, score=-103.002 tagged_above=-999 required=5 tests=[AWL=0.597, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RwcqxYqShYyg for ; Wed, 15 May 2013 04:22:48 -0700 (PDT) Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id 0FD9A21F8EB9 for ; Wed, 15 May 2013 04:22:48 -0700 (PDT) Received: (qmail 23253 invoked by uid 0); 15 May 2013 11:22:26 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy12.bluehost.com with SMTP; 15 May 2013 11:22:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:CC:To:From; bh=v7TE0mxRnWKk5mE3EZwRy10KcXOtdtA9OcD5ODuYtZA=; b=GeC6gpsrpnydNGUL2C3eSb8ju3ZxiKWc9IrUMOfDL0DhSG2IuYqjZKJK+ENIRr3TRlTUGjl6WTswFfIP2T+pDq3lIdjSW32fBctF7mdGU3/1XgqX3JBf6Jx0Ts7OveXF; Received: from box313.bluehost.com ([69.89.31.113]:47755 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UcZms-00077z-Cx; Wed, 15 May 2013 05:22:26 -0600 From: Lou Berger To: Daniele Ceccarelli , Fatai Zhang Date: Wed, 15 May 2013 07:22:23 -0400 Message-ID: <13ea7ed3bdd.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE480C90D5@ESESSMB301.ericsson.se> References: <518A82D9.7080508@labn.net> <518BAB17.9090807@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> <518CED28.30303@labn.net> <51924382.2010904@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C90D5@ESESSMB301.ericsson.se> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 AquaMail/1.2.4.0 (build: 2100294) MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" , "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" Subject: Re: [CCAMP] Closing G.709 open issues X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 11:22:53 -0000 Daniele, On May 15, 2013 4:20:25 AM Daniele Ceccarelli wrote: > Hi Lou, > > Just a bit. > >My memory is that the consensus at the time was that G.709 would continue > to use the current generic approach to edge adaptation & G-PIDs, and that > (some of) the G.709 authors would submit a draft that would address > adaptation in a generic fashion. > > > > If i correctly remember we agreed to solve the routing issu in a generic > approach, not the signaling one. We must be thinking of different threads. The one I'm thinking of started with the comment along the lines of "why only some G-PIDs represented in the ADAPTATION object" and concluded with the agreement to drop the object and follow the current generic approach as well as look into a non-OTN specific solution in a new draft. At least that's how I remember it.... > It is possible to assume that the adaptation is a known info to the > operator and hence that the advertisement can be postponed and addressed in > a generic way but it needs to be signaled. > > This is an hortogonal issue with respect to the mapping of G-PID, which has > always been assumed to be 1:1 with G.709 values. humm, this seems inconsistent with Fatai recently suggesting that i was asking for a "non-grouped" approach. At the time, I was really just thinking about the values missing in the list I sent out. I don't recall any other discussion on moving away from the past 709 G-PID assignment approach. > The 1:1 *mapping* approach used by Fatai is different from the *mapping" > protocol like GFP, AMP that we discussed before. > It looks like we both/all should take a look at the archives to refresh our memories.... Thanks, Lou > BR > Daniele, Sergio, Fatai > > > >-----Original Message----- > >From: Lou Berger [mailto:lberger@labn.net] Sent: martedì 14 maggio 2013 16.01 > >To: Fatai Zhang > >Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; > draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; > draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org > >Subject: Re: Closing G.709 open issues > > > >Fatai, Sergio, > > I haven't had time to go find the old mail covering the topic you > mentioned (which is why I didn't respond yesterday): > >> I think this has been discussed for quite long time before Vancouver > meeting, which was famous as "penultimate" issue. > >> > >> I don't think we need discuss this anymore. > > > >My memory is that the consensus at the time was that G.709 would continue > to use the current generic approach to edge adaptation & G-PIDs, and that > (some of) the G.709 authors would submit a draft that would address > adaptation in a generic fashion. > > > >Do you think this characterization is mistaken? (If so, time to go > searching for the old discussion, if not we can move on.) > > > >Assuming no, then it seems to me that you are going against this > discussion & consensus by now introducing a 1:1/bandwidth specific mapping > approach. Do you disagree? If not, do you think there's justification to > reopen this discussion? > > > >Independent of the mapping approach and in order to ensure this issue is > closed and does not again resurface, I also request (again) that the > editors of the draft provide (and include in the document) a full list of > Payload Type values (with the 0x value prefix or the values in > >decimal) and their corresponding G-PID values. Also including Encoding > Type as you have below is a good addition -- great idea! > > > >Lou > > > >On 5/14/2013 1:53 AM, Fatai Zhang wrote: > >> Hi all, > >> Thanks, Sergio. > >> I would like to double check if everything is OK before we >update the > signaling draft. > >> I would assume the WG is happy with 1:1 mapping approach and >the new > GPIDs listed below if there is no more comment until this Wed. > >> > >> Best Regards > >> Fatai > >> > >> -----Original Message----- > >> From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-lucent.com] > >> Sent: Monday, May 13, 2013 3:45 PM > >> To: Fatai Zhang; Lou Berger > >> Cc: Daniele Ceccarelli; CCAMP; > draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; > draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org > >> Subject: R: Closing G.709 open issues > >> Hi Fatai, > >> I agree with you, for both point 1 and 2. > >> Best Regards > >> Sergio > >> Belotti Sergio- System Architect > >> ALCATE-LUCENT Optics Division > >> via Trento 30 Vimercate (MB) - Italy > >> phone +39 (039) 6863033 > >> -----Messaggio originale----- > >> Da: Fatai Zhang [mailto:zhangfatai@huawei.com] > >> Inviato: lunedì 13 maggio 2013 5.33 > >> A: Lou Berger > >> Cc: Daniele Ceccarelli; CCAMP; > draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; > draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org > >> Oggetto: RE: Closing G.709 open issues > >> Hi Lou, > >> I think you have two major points here. > >> (1) Do you really need 3 G-PID types for an ODU (I thought >TSG was > already covered)? > >> I think this has been discussed for quite long time before >Vancouver > meeting, which was famous as "penultimate" issue. >Note that this TSG in > GPID is different from the *implicit* >TSG in label format. > >> I don't think we need discuss this anymore. > >> (2) 'Grouped GPID' vs '1:1' mapping (between G.709-2012 and GPIDs > defined in this draft) > >> We realize that it is safe to use 1:1 mapping approach to >avoid some > potential issues after investigation. We know this >payload types have been > defined by G.709 (data plane), so >physically it is better to use 1:1 > mapping approach. For the potential issues I mentioned above, for example, > we >cannot use the existing 34 to represent 'STM-1' and 'STM-4 ', >because > it is impossible to differentiate which one is 'STM-1' >or 'STM-4'. In > addition, from the concept of payload type, we >know that e.g, FC-100 is > different from FC-800, right? So, it >is better to assign different GPIDs > to these different payload >types defined by the data plane. > >> Furthermore, I think it is much cheaper to create new GPIDs >in the > control plane than in the data plane (these payload >types will be carried > in the OH). > >> > >> Best Regards > >> Fatai > >> > >> -----Original Message----- > >> From: Lou Berger [mailto:lberger@labn.net] > >> Sent: Friday, May 10, 2013 8:51 PM > >> To: Fatai Zhang > >> Cc: Daniele Ceccarelli; CCAMP; > draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; > draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org > >> Subject: Re: Closing G.709 open issues > >> > >> On 5/9/2013 9:41 PM, Fatai Zhang wrote: > >>> Hi Lou, > >>> > >>> For point 1), "1" should be dropped and "7" should be >corrected to "8" > in your proposed text. >> >> Great. > >> >>> > >>> I hesitate to make a decision on either approach, I would >like to > defer to the WG consensus. > >>> > >> I believe we already have a consensus position. The question in my mail > was do we need to revisit it. I take your response as a no. (thank you!) > >> >>> For point 2), I compared [G.709-2003] and [G.709-2012], and checked > >>> the GPIDs defined in [RFC4328], I think the following new GPIDs >>> > (values could be 59-79) should be added (besides updating >some GPIDs >>> > defined in RFC4328, like 32,47,49-52): > >>> > >> I suggest going through the full PT list and identifying them in the > table (as I started in my last message) so that there is no >confusion in > implementations. > >> In the list below it looks like you have moved away from the >'grouped > G-PID' approach. Is there a reason for this change? > >> Refer to > >> >http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-paramet > >> ers.xml > >> in subsequent comments. > >> >>> Value G-PID Type LSP Encoding Type > >>> ----- ---------- ----------------- > >>> 59(TBA) G.709 ODU-1.25G G.709 ODUk 60(TBA) G.709 > ODU-any G.709 ODUk > >> Do you really need 3 G-PID types for an ODU (I thought TSG >was already > covered)? > >> >>> 61(TBA) PCS G.709 ODUk (k=0) > >>> 62(TBA) FC-1200 G.709 ODUk (k=2e) > >> Why not us existing G-PID 58? > >> >>> 63(TBA) eOPU2 G.709 ODUk (k=2) > >> >>> 64(TBA) STM-1 G.709 ODUk (k=0) > >>> 65(TBA) STM-4 G.709 ODUk (k=0) > >> Why not us existing G-PID 34? > >> >>> 66(TBA) FC-100 G.709 ODUk (k=0) > >>> 67(TBA) FC-200 G.709 ODUk (k=1) > >>> 68(TBA) FC-400 G.709 ODUflex > >>> 69(TBA) FC-800 G.709 ODUflex > >> Why not us existing G-PID 58? > >> >>> 70(TBA) IB SDR G.709 ODUflex > >>> 71(TBA) IB DDR G.709 ODUflex > >>> 72(TBA) IB QDR G.709 ODUflex > >> Can these be one value with rate implying SDR/DDR/QDR? > >> >>> 73(TBA) SDIa G.709 ODUk (k=0) > >>> 74(TBA) SDIb G.709 ODUk (k=1) > >>> 75(TBA) SDIc G.709 ODUk (k=1) > >>> 76(TBA) SDId G.709 ODUflex > >>> 77(TBA) SDIe G.709 ODUflex > >> Can these be one value with rate implying a-e? > >> >>> 78(TBA) SB/ESCON G.709 ODUk (k=0) > >> Why not us existing G-PID 56? > >> >>> 79(TBA) DVB_ASI G.709 ODUk (k=0) > >>> > >>> > >>> > >>> > >> Thanks, > >> Lou > >> > >> > >> > > From sergio.belotti@alcatel-lucent.com Wed May 15 04:55:36 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84B1A21F899E for ; Wed, 15 May 2013 04:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.3 X-Spam-Level: X-Spam-Status: No, score=-9.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-IesNQ9HLgR for ; Wed, 15 May 2013 04:55:30 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id EB54B21F882A for ; Wed, 15 May 2013 04:55:29 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r4FBtLri009817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 15 May 2013 06:55:21 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id r4FBtKlR026685 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 May 2013 07:55:20 -0400 Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 15 May 2013 07:55:20 -0400 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.233]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Wed, 15 May 2013 13:54:57 +0200 From: "BELOTTI, SERGIO (SERGIO)" To: Lou Berger , Daniele Ceccarelli , Fatai Zhang Thread-Topic: Closing G.709 open issues Thread-Index: AQHOT4qqUl1mFyMbR0uUaEgIgIORFZkCvCzwgAFRz4CAAIg2AIABM0yAgAAy14CAAChN0A== Date: Wed, 15 May 2013 11:54:57 +0000 Message-ID: References: <518A82D9.7080508@labn.net> <518BAB17.9090807@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> <518CED28.30303@labn.net> <51924382.2010904@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C90D5@ESESSMB301.ericsson.se> <13ea7ed3bdd.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <13ea7ed3bdd.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" , "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" Subject: [CCAMP] R: Closing G.709 open issues X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 11:55:36 -0000 We (as authors" were asked to cope with the remaining issues to start secon= d LC. One these "remaining issues" was as fro Lou's mil of May 9th 2) Verify that the complete list of G-PIDs are defined [SIGNALING] In signaling document section 4, verify that all payload types defined in G.709 (Summarized in Table 15-8) can be represented. This issue can be resolved via an update or message to the list stating that the verification took place. This is concluded by Fatai answer regarding G-PID check and 1:1 mapping. FATAI> For point 2), I compared [G.709-2003] and [G.709-2012], and checked = the GPIDs defined in [RFC4328], I think the following new GPIDs (values cou= ld be 59-79) should be added (besides updating some GPIDs defined in RFC432= 8, like 32,47,49-52): Value G-PID Type LSP Encoding Type ----- ---------- ----------------- 59(TBA) G.709 ODU-1.25G G.709 ODUk=20 60(TBA) G.709 ODU-any G.709 ODUk 61(TBA) PCS G.709 ODUk (k=3D0) 62(TBA) FC-1200 G.709 ODUk (k=3D2e) 63(TBA) eOPU2 G.709 ODUk (k=3D2) 64(TBA) STM-1 G.709 ODUk (k=3D0) 65(TBA) STM-4 G.709 ODUk (k=3D0) 66(TBA) FC-100 G.709 ODUk (k=3D0) 67(TBA) FC-200 G.709 ODUk (k=3D1) 68(TBA) FC-400 G.709 ODUflex 69(TBA) FC-800 G.709 ODUflex 70(TBA) IB SDR G.709 ODUflex 71(TBA) IB DDR G.709 ODUflex 72(TBA) IB QDR G.709 ODUflex 73(TBA) SDIa G.709 ODUk (k=3D0) 74(TBA) SDIb G.709 ODUk (k=3D1) 75(TBA) SDIc G.709 ODUk (k=3D1) 76(TBA) SDId G.709 ODUflex 77(TBA) SDIe G.709 ODUflex 78(TBA) SB/ESCON G.709 ODUk (k=3D0) 79(TBA) DVB_ASI G.709 ODUk (k=3D0) All this has nothing to do with specifc ADAPTATION object , for which I wa= s always in favour but it seems as though it is linked to MRN discussion an= d out of specifc OTN.=20 Hope this can help. Best Regards Sergio Belotti Sergio- System Architect ALCATE-LUCENT Optics Division via Trento 30 Vimercate (MB) - Italy phone +39 (039) 6863033 -----Messaggio originale----- Da: Lou Berger [mailto:lberger@labn.net]=20 Inviato: mercoled=EC 15 maggio 2013 13.22 A: Daniele Ceccarelli; Fatai Zhang Cc: BELOTTI, SERGIO (SERGIO); CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v= 3@tools.ietf.org; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org Oggetto: RE: Closing G.709 open issues Daniele, On May 15, 2013 4:20:25 AM Daniele Ceccarelli=20 wrote: > Hi Lou, > > Just a bit. > >My memory is that the consensus at the time was that G.709 would continu= e=20 > to use the current generic approach to edge adaptation & G-PIDs, and that= =20 > (some of) the G.709 authors would submit a draft that would address=20 > adaptation in a generic fashion. > > > > If i correctly remember we agreed to solve the routing issu in a generic= =20 > approach, not the signaling one. We must be thinking of different threads. The one I'm thinking of started=20 with the comment along the lines of "why only some G-PIDs represented in=20 the ADAPTATION object" and concluded with the agreement to drop the object= =20 and follow the current generic approach as well as look into a non-OTN=20 specific solution in a new draft. At least that's how I remember it.... > It is possible to assume that the adaptation is a known info to the=20 > operator and hence that the advertisement can be postponed and addressed = in=20 > a generic way but it needs to be signaled. > > This is an hortogonal issue with respect to the mapping of G-PID, which h= as=20 > always been assumed to be 1:1 with G.709 values. humm, this seems inconsistent with Fatai recently suggesting that i was=20 asking for a "non-grouped" approach. At the time, I was really just=20 thinking about the values missing in the list I sent out. I don't recall=20 any other discussion on moving away from the past 709 G-PID assignment=20 approach. > The 1:1 *mapping* approach used by Fatai is different from the *mapping"= =20 > protocol like GFP, AMP that we discussed before. > It looks like we both/all should take a look at the archives to refresh our= =20 memories.... Thanks, Lou > BR > Daniele, Sergio, Fatai > > > >-----Original Message----- > >From: Lou Berger [mailto:lberger@labn.net] Sent: marted=EC 14 maggio 201= 3 16.01 > >To: Fatai Zhang > >Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP;=20 > draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org;=20 > draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org > >Subject: Re: Closing G.709 open issues > > > >Fatai, Sergio, > > I haven't had time to go find the old mail covering the topic you=20 > mentioned (which is why I didn't respond yesterday): > >> I think this has been discussed for quite long time before Vancouver=20 > meeting, which was famous as "penultimate" issue. > >> > >> I don't think we need discuss this anymore. > > > >My memory is that the consensus at the time was that G.709 would continu= e=20 > to use the current generic approach to edge adaptation & G-PIDs, and that= =20 > (some of) the G.709 authors would submit a draft that would address=20 > adaptation in a generic fashion. > > > >Do you think this characterization is mistaken? (If so, time to go=20 > searching for the old discussion, if not we can move on.) > > > >Assuming no, then it seems to me that you are going against this=20 > discussion & consensus by now introducing a 1:1/bandwidth specific mappin= g=20 > approach. Do you disagree? If not, do you think there's justification to= =20 > reopen this discussion? > > > >Independent of the mapping approach and in order to ensure this issue is= =20 > closed and does not again resurface, I also request (again) that the=20 > editors of the draft provide (and include in the document) a full list of= =20 > Payload Type values (with the 0x value prefix or the values in > >decimal) and their corresponding G-PID values. Also including Encoding= =20 > Type as you have below is a good addition -- great idea! > > > >Lou > > > >On 5/14/2013 1:53 AM, Fatai Zhang wrote: > >> Hi all, > >> Thanks, Sergio. > >> I would like to double check if everything is OK before we >update the= =20 > signaling draft. > >> I would assume the WG is happy with 1:1 mapping approach and >the new= =20 > GPIDs listed below if there is no more comment until this Wed. > >> > >> Best Regards > >> Fatai > >> > >> -----Original Message----- > >> From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-lucent.c= om] > >> Sent: Monday, May 13, 2013 3:45 PM > >> To: Fatai Zhang; Lou Berger > >> Cc: Daniele Ceccarelli; CCAMP;=20 > draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org;=20 > draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org > >> Subject: R: Closing G.709 open issues > >> Hi Fatai, > >> I agree with you, for both point 1 and 2. > >> Best Regards > >> Sergio > >> Belotti Sergio- System Architect > >> ALCATE-LUCENT Optics Division > >> via Trento 30 Vimercate (MB) - Italy > >> phone +39 (039) 6863033 > >> -----Messaggio originale----- > >> Da: Fatai Zhang [mailto:zhangfatai@huawei.com] > >> Inviato: luned=EC 13 maggio 2013 5.33 > >> A: Lou Berger > >> Cc: Daniele Ceccarelli; CCAMP;=20 > draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org;=20 > draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org > >> Oggetto: RE: Closing G.709 open issues > >> Hi Lou, > >> I think you have two major points here. > >> (1) Do you really need 3 G-PID types for an ODU (I thought >TSG was=20 > already covered)? > >> I think this has been discussed for quite long time before >Vancouver= =20 > meeting, which was famous as "penultimate" issue. >Note that this TSG in= =20 > GPID is different from the *implicit* >TSG in label format. > >> I don't think we need discuss this anymore. > >> (2) 'Grouped GPID' vs '1:1' mapping (between G.709-2012 and GPIDs=20 > defined in this draft) > >> We realize that it is safe to use 1:1 mapping approach to >avoid some= =20 > potential issues after investigation. We know this >payload types have be= en=20 > defined by G.709 (data plane), so >physically it is better to use 1:1=20 > mapping approach. For the potential issues I mentioned above, for example= ,=20 > we >cannot use the existing 34 to represent 'STM-1' and 'STM-4 ', >becaus= e=20 > it is impossible to differentiate which one is 'STM-1' >or 'STM-4'. In=20 > addition, from the concept of payload type, we >know that e.g, FC-100 is= =20 > different from FC-800, right? So, it >is better to assign different GPIDs= =20 > to these different payload >types defined by the data plane. > >> Furthermore, I think it is much cheaper to create new GPIDs >in the=20 > control plane than in the data plane (these payload >types will be carrie= d=20 > in the OH). > >> > >> Best Regards > >> Fatai > >> > >> -----Original Message----- > >> From: Lou Berger [mailto:lberger@labn.net] > >> Sent: Friday, May 10, 2013 8:51 PM > >> To: Fatai Zhang > >> Cc: Daniele Ceccarelli; CCAMP;=20 > draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org;=20 > draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org > >> Subject: Re: Closing G.709 open issues > >> > >> On 5/9/2013 9:41 PM, Fatai Zhang wrote: > >>> Hi Lou, > >>> > >>> For point 1), "1" should be dropped and "7" should be >corrected to "= 8"=20 > in your proposed text. >> >> Great. > >> >>> > >>> I hesitate to make a decision on either approach, I would >like to=20 > defer to the WG consensus. > >>> > >> I believe we already have a consensus position. The question in my ma= il=20 > was do we need to revisit it. I take your response as a no. (thank you!) > >> >>> For point 2), I compared [G.709-2003] and [G.709-2012], and checke= d=20 > >>> the GPIDs defined in [RFC4328], I think the following new GPIDs >>>=20 > (values could be 59-79) should be added (besides updating >some GPIDs >>>= =20 > defined in RFC4328, like 32,47,49-52): > >>> > >> I suggest going through the full PT list and identifying them in the=20 > table (as I started in my last message) so that there is no >confusion in= =20 > implementations. > >> In the list below it looks like you have moved away from the >'grouped= =20 > G-PID' approach. Is there a reason for this change? > >> Refer to > >> >http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parame= t > >> ers.xml > >> in subsequent comments. > >> >>> Value G-PID Type LSP Encoding Type > >>> ----- ---------- ----------------- > >>> 59(TBA) G.709 ODU-1.25G G.709 ODUk 60(TBA) G.709=20 > ODU-any G.709 ODUk > >> Do you really need 3 G-PID types for an ODU (I thought TSG >was alread= y=20 > covered)? > >> >>> 61(TBA) PCS G.709 ODUk (k=3D0) > >>> 62(TBA) FC-1200 G.709 ODUk (k=3D2e) > >> Why not us existing G-PID 58? > >> >>> 63(TBA) eOPU2 G.709 ODUk (k=3D2) > >> >>> 64(TBA) STM-1 G.709 ODUk (k=3D0) > >>> 65(TBA) STM-4 G.709 ODUk (k=3D0) > >> Why not us existing G-PID 34? > >> >>> 66(TBA) FC-100 G.709 ODUk (k=3D0) > >>> 67(TBA) FC-200 G.709 ODUk (k=3D1) > >>> 68(TBA) FC-400 G.709 ODUflex > >>> 69(TBA) FC-800 G.709 ODUflex > >> Why not us existing G-PID 58? > >> >>> 70(TBA) IB SDR G.709 ODUflex > >>> 71(TBA) IB DDR G.709 ODUflex > >>> 72(TBA) IB QDR G.709 ODUflex > >> Can these be one value with rate implying SDR/DDR/QDR? > >> >>> 73(TBA) SDIa G.709 ODUk (k=3D0) > >>> 74(TBA) SDIb G.709 ODUk (k=3D1) > >>> 75(TBA) SDIc G.709 ODUk (k=3D1) > >>> 76(TBA) SDId G.709 ODUflex > >>> 77(TBA) SDIe G.709 ODUflex > >> Can these be one value with rate implying a-e? > >> >>> 78(TBA) SB/ESCON G.709 ODUk (k=3D0) > >> Why not us existing G-PID 56? > >> >>> 79(TBA) DVB_ASI G.709 ODUk (k=3D0) > >>> > >>> > >>> > >>> > >> Thanks, > >> Lou > >> > >> > >> > > From lberger@labn.net Wed May 15 07:58:29 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B8621F8A53 for ; Wed, 15 May 2013 07:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.056 X-Spam-Level: X-Spam-Status: No, score=-103.056 tagged_above=-999 required=5 tests=[AWL=0.543, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 268fLb7QHoEy for ; Wed, 15 May 2013 07:58:24 -0700 (PDT) Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id 6532921F87E0 for ; Wed, 15 May 2013 07:58:08 -0700 (PDT) Received: (qmail 32117 invoked by uid 0); 15 May 2013 14:57:46 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy12.bluehost.com with SMTP; 15 May 2013 14:57:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=2CiyWPMUwiDczedDwzklcRP63nFcYmJs9d8opyB6lJY=; b=KzgufqtZ+XKin0EKJnYHJG+PQwQZxUBoOYuygWWmVPLRxjHNqaNbPqj3yqSHd18GWmuBBSSTbtXMw5M655aMlH3KA3Drk8vVAt4OfAaDY+iPHGOLTmvwdoBTQr3sE6dY; Received: from box313.bluehost.com ([69.89.31.113]:44977 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Ucd9F-0007iR-M1; Wed, 15 May 2013 08:57:46 -0600 Message-ID: <5193A26A.1090005@labn.net> Date: Wed, 15 May 2013 10:57:46 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "BELOTTI, SERGIO (SERGIO)" , Fatai Zhang References: <518A82D9.7080508@labn.net> <518BAB17.9090807@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> <518CED28.30303@labn.net> <51924382.2010904@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C90D5@ESESSMB301.ericsson.se> <13ea7ed3bdd.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" Subject: Re: [CCAMP] R: Closing G.709 open issues X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 14:58:29 -0000 Sergio/Fatai, On 5/15/2013 7:54 AM, BELOTTI, SERGIO (SERGIO) wrote: > We (as authors" were asked to cope with the remaining issues to start second LC. > One these "remaining issues" was as fro Lou's mil of May 9th > > 2) Verify that the complete list of G-PIDs are defined [SIGNALING] > > In signaling document section 4, verify that all payload types > defined in G.709 (Summarized in Table 15-8) can be represented. > This issue can be resolved via an update or message to the list > stating that the verification took place. > > This is concluded by Fatai answer regarding G-PID check and 1:1 mapping. And, based on the discussion, I (to be clear, as WG chair) have revised the request by asking: "that the editors of the draft provide (and include in the document) a full list of Payload Type values (with the 0x value prefix or the values in decimal) and their corresponding G-PID values. Also including Encoding Type as you [Fatai] have below is a good addition -- great idea!" Given the level of discussion of this thread, I think this is a completely reasonable way to avoid future confusion, particularly in implementations. Do the Authors/Editor need help in generating this complete list? Do the Authors/Editor want (me) to issue a call for input on this list? I suspect some in WG will be happy to jump in as it's an easy way to get added as a contributor to the signaling draft. > > FATAI> For point 2), I compared [G.709-2003] and [G.709-2012], and checked the GPIDs defined in [RFC4328], I think the following new GPIDs (values could be 59-79) should be added (besides updating some GPIDs defined in RFC4328, like 32,47,49-52): > > Value G-PID Type LSP Encoding Type > ----- ---------- ----------------- > 59(TBA) G.709 ODU-1.25G G.709 ODUk > 60(TBA) G.709 ODU-any G.709 ODUk > 61(TBA) PCS G.709 ODUk (k=0) > 62(TBA) FC-1200 G.709 ODUk (k=2e) > 63(TBA) eOPU2 G.709 ODUk (k=2) > 64(TBA) STM-1 G.709 ODUk (k=0) > 65(TBA) STM-4 G.709 ODUk (k=0) > 66(TBA) FC-100 G.709 ODUk (k=0) > 67(TBA) FC-200 G.709 ODUk (k=1) > 68(TBA) FC-400 G.709 ODUflex > 69(TBA) FC-800 G.709 ODUflex > 70(TBA) IB SDR G.709 ODUflex > 71(TBA) IB DDR G.709 ODUflex > 72(TBA) IB QDR G.709 ODUflex > 73(TBA) SDIa G.709 ODUk (k=0) > 74(TBA) SDIb G.709 ODUk (k=1) > 75(TBA) SDIc G.709 ODUk (k=1) > 76(TBA) SDId G.709 ODUflex > 77(TBA) SDIe G.709 ODUflex > 78(TBA) SB/ESCON G.709 ODUk (k=0) > 79(TBA) DVB_ASI G.709 ODUk (k=0) > > All this has nothing to do with specifc ADAPTATION object , for which I was always in favour but it seems as though it is linked to MRN discussion and out of specifc OTN. > So I went looking for past discussions on this, and this is what I find: - From http://www.ietf.org/mail-archive/web/ccamp/current/msg13598.html On 7/19/2012 11:45 AM, Lou Berger wrote: > (As participant in thread) I read that the conclusion is to not optimize > for a very special corner case and: > 1) basically treat the intra-OTN case the same as any other MRN/MLN case > (leveraging GPID, and no new hierarchy object) > 2) Use Daniele's new draft on MRN/MLN as the starting point in the > discussion of how to address the limitations in MRN/MLN identified in > this discussion. >From http://tools.ietf.org/agenda/84/slides/slides-84-ccamp-7.pdf > G-PID Value Extension > o Extended G-PID for G.709 ODU client signals: > Value G-PID Type TSG (LO ODU into requested LSP) > ----- ---------- ---------------- > 47 G.709 ODU 2.5Gbps [RFC4328] > 59(TBA) G.709 ODU-1.25G 1.25Gbps (new) > 60(TBA) G.709 ODU-any either 1.25 or 2.5Gbps(new) > > o Added other new G-PID values for new client signals supported by G.709V3 > Value G-PID Type > ----- ---------- > 61(TBA) CBRc (via GMP) > 62(TBA) 1000BASE-X > 63(TBA) FC-1200 > > o Updated some existing G-PID description to support new 1.25G, 100G, > supra-2.488G client signals, such as 32 for ATM, 49 for asynchronous > CBR , 50 for synchronous CBR , 51 for BSOT, 52 for BSNT. I have not interest/need to revist past consensus on G-PIDs & TSGs, so will limit my comments to the newly defined G-PIDs. My questions on the new G-PIDs come down to: - Why are rate specific G-PIDs being proposed (rather than continuing to use the previous approach documented in the draft and in Section 3.1.3 of rfc4328)? - Why are new values being defined rather than using existing values, e.g., G-PID 56? That's it. Lou > Hope this can help. > > Best Regards > Sergio > > Belotti Sergio- System Architect > ALCATE-LUCENT Optics Division > via Trento 30 Vimercate (MB) - Italy > phone +39 (039) 6863033 > > -----Messaggio originale----- > Da: Lou Berger [mailto:lberger@labn.net] > Inviato: mercoledì 15 maggio 2013 13.22 > A: Daniele Ceccarelli; Fatai Zhang > Cc: BELOTTI, SERGIO (SERGIO); CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org > Oggetto: RE: Closing G.709 open issues > > Daniele, > > On May 15, 2013 4:20:25 AM Daniele Ceccarelli > wrote: >> Hi Lou, >> >> Just a bit. >>> My memory is that the consensus at the time was that G.709 would continue >> to use the current generic approach to edge adaptation & G-PIDs, and that >> (some of) the G.709 authors would submit a draft that would address >> adaptation in a generic fashion. >>> >> >> If i correctly remember we agreed to solve the routing issu in a generic >> approach, not the signaling one. > > We must be thinking of different threads. The one I'm thinking of started > with the comment along the lines of "why only some G-PIDs represented in > the ADAPTATION object" and concluded with the agreement to drop the object > and follow the current generic approach as well as look into a non-OTN > specific solution in a new draft. At least that's how I remember it.... > >> It is possible to assume that the adaptation is a known info to the >> operator and hence that the advertisement can be postponed and addressed in >> a generic way but it needs to be signaled. >> >> This is an hortogonal issue with respect to the mapping of G-PID, which has >> always been assumed to be 1:1 with G.709 values. > > humm, this seems inconsistent with Fatai recently suggesting that i was > asking for a "non-grouped" approach. At the time, I was really just > thinking about the values missing in the list I sent out. I don't recall > any other discussion on moving away from the past 709 G-PID assignment > approach. > >> The 1:1 *mapping* approach used by Fatai is different from the *mapping" >> protocol like GFP, AMP that we discussed before. >> > > It looks like we both/all should take a look at the archives to refresh our > memories.... > > Thanks, > Lou > >> BR >> Daniele, Sergio, Fatai >> >> >>> -----Original Message----- >>> From: Lou Berger [mailto:lberger@labn.net] Sent: martedì 14 maggio 2013 16.01 >>> To: Fatai Zhang >>> Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; >> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; >> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org >>> Subject: Re: Closing G.709 open issues >>> >>> Fatai, Sergio, >>> I haven't had time to go find the old mail covering the topic you >> mentioned (which is why I didn't respond yesterday): >>>> I think this has been discussed for quite long time before Vancouver >> meeting, which was famous as "penultimate" issue. >>>> >>>> I don't think we need discuss this anymore. >>> >>> My memory is that the consensus at the time was that G.709 would continue >> to use the current generic approach to edge adaptation & G-PIDs, and that >> (some of) the G.709 authors would submit a draft that would address >> adaptation in a generic fashion. >>> >>> Do you think this characterization is mistaken? (If so, time to go >> searching for the old discussion, if not we can move on.) >>> >>> Assuming no, then it seems to me that you are going against this >> discussion & consensus by now introducing a 1:1/bandwidth specific mapping >> approach. Do you disagree? If not, do you think there's justification to >> reopen this discussion? >>> >>> Independent of the mapping approach and in order to ensure this issue is >> closed and does not again resurface, I also request (again) that the >> editors of the draft provide (and include in the document) a full list of >> Payload Type values (with the 0x value prefix or the values in >>> decimal) and their corresponding G-PID values. Also including Encoding >> Type as you have below is a good addition -- great idea! >>> >>> Lou >>> >>> On 5/14/2013 1:53 AM, Fatai Zhang wrote: >>>> Hi all, >>>> Thanks, Sergio. >>>> I would like to double check if everything is OK before we >update the >> signaling draft. >>>> I would assume the WG is happy with 1:1 mapping approach and >the new >> GPIDs listed below if there is no more comment until this Wed. >>>> >>>> Best Regards >>>> Fatai >>>> >>>> -----Original Message----- >>>> From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-lucent.com] >>>> Sent: Monday, May 13, 2013 3:45 PM >>>> To: Fatai Zhang; Lou Berger >>>> Cc: Daniele Ceccarelli; CCAMP; >> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; >> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org >>>> Subject: R: Closing G.709 open issues >>>> Hi Fatai, >>>> I agree with you, for both point 1 and 2. >>>> Best Regards >>>> Sergio >>>> Belotti Sergio- System Architect >>>> ALCATE-LUCENT Optics Division >>>> via Trento 30 Vimercate (MB) - Italy >>>> phone +39 (039) 6863033 >>>> -----Messaggio originale----- >>>> Da: Fatai Zhang [mailto:zhangfatai@huawei.com] >>>> Inviato: lunedì 13 maggio 2013 5.33 >>>> A: Lou Berger >>>> Cc: Daniele Ceccarelli; CCAMP; >> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; >> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org >>>> Oggetto: RE: Closing G.709 open issues >>>> Hi Lou, >>>> I think you have two major points here. >>>> (1) Do you really need 3 G-PID types for an ODU (I thought >TSG was >> already covered)? >>>> I think this has been discussed for quite long time before >Vancouver >> meeting, which was famous as "penultimate" issue. >Note that this TSG in >> GPID is different from the *implicit* >TSG in label format. >>>> I don't think we need discuss this anymore. >>>> (2) 'Grouped GPID' vs '1:1' mapping (between G.709-2012 and GPIDs >> defined in this draft) >>>> We realize that it is safe to use 1:1 mapping approach to >avoid some >> potential issues after investigation. We know this >payload types have been >> defined by G.709 (data plane), so >physically it is better to use 1:1 >> mapping approach. For the potential issues I mentioned above, for example, >> we >cannot use the existing 34 to represent 'STM-1' and 'STM-4 ', >because >> it is impossible to differentiate which one is 'STM-1' >or 'STM-4'. In >> addition, from the concept of payload type, we >know that e.g, FC-100 is >> different from FC-800, right? So, it >is better to assign different GPIDs >> to these different payload >types defined by the data plane. >>>> Furthermore, I think it is much cheaper to create new GPIDs >in the >> control plane than in the data plane (these payload >types will be carried >> in the OH). >>>> >>>> Best Regards >>>> Fatai >>>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: Friday, May 10, 2013 8:51 PM >>>> To: Fatai Zhang >>>> Cc: Daniele Ceccarelli; CCAMP; >> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; >> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org >>>> Subject: Re: Closing G.709 open issues >>>> >>>> On 5/9/2013 9:41 PM, Fatai Zhang wrote: >>>>> Hi Lou, >>>>> >>>>> For point 1), "1" should be dropped and "7" should be >corrected to "8" >> in your proposed text. >> >> Great. >>>>>>> >>>>> I hesitate to make a decision on either approach, I would >like to >> defer to the WG consensus. >>>>> >>>> I believe we already have a consensus position. The question in my mail >> was do we need to revisit it. I take your response as a no. (thank you!) >>>>>>> For point 2), I compared [G.709-2003] and [G.709-2012], and checked >>>>> the GPIDs defined in [RFC4328], I think the following new GPIDs >>> >> (values could be 59-79) should be added (besides updating >some GPIDs >>> >> defined in RFC4328, like 32,47,49-52): >>>>> >>>> I suggest going through the full PT list and identifying them in the >> table (as I started in my last message) so that there is no >confusion in >> implementations. >>>> In the list below it looks like you have moved away from the >'grouped >> G-PID' approach. Is there a reason for this change? >>>> Refer to >>>>> http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-paramet >>>> ers.xml >>>> in subsequent comments. >>>>>>> Value G-PID Type LSP Encoding Type >>>>> ----- ---------- ----------------- >>>>> 59(TBA) G.709 ODU-1.25G G.709 ODUk 60(TBA) G.709 >> ODU-any G.709 ODUk >>>> Do you really need 3 G-PID types for an ODU (I thought TSG >was already >> covered)? >>>>>>> 61(TBA) PCS G.709 ODUk (k=0) >>>>> 62(TBA) FC-1200 G.709 ODUk (k=2e) >>>> Why not us existing G-PID 58? >>>>>>> 63(TBA) eOPU2 G.709 ODUk (k=2) >>>>>>> 64(TBA) STM-1 G.709 ODUk (k=0) >>>>> 65(TBA) STM-4 G.709 ODUk (k=0) >>>> Why not us existing G-PID 34? >>>>>>> 66(TBA) FC-100 G.709 ODUk (k=0) >>>>> 67(TBA) FC-200 G.709 ODUk (k=1) >>>>> 68(TBA) FC-400 G.709 ODUflex >>>>> 69(TBA) FC-800 G.709 ODUflex >>>> Why not us existing G-PID 58? >>>>>>> 70(TBA) IB SDR G.709 ODUflex >>>>> 71(TBA) IB DDR G.709 ODUflex >>>>> 72(TBA) IB QDR G.709 ODUflex >>>> Can these be one value with rate implying SDR/DDR/QDR? >>>>>>> 73(TBA) SDIa G.709 ODUk (k=0) >>>>> 74(TBA) SDIb G.709 ODUk (k=1) >>>>> 75(TBA) SDIc G.709 ODUk (k=1) >>>>> 76(TBA) SDId G.709 ODUflex >>>>> 77(TBA) SDIe G.709 ODUflex >>>> Can these be one value with rate implying a-e? >>>>>>> 78(TBA) SB/ESCON G.709 ODUk (k=0) >>>> Why not us existing G-PID 56? >>>>>>> 79(TBA) DVB_ASI G.709 ODUk (k=0) >>>>> >>>>> >>>>> >>>>> >>>> Thanks, >>>> Lou >>>> >>>> >>>> >>> > > > > > > From zhangfatai@huawei.com Fri May 17 00:58:37 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E67A821F8E4C for ; Fri, 17 May 2013 00:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YG2pdOOFdY5t for ; Fri, 17 May 2013 00:58:33 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9A121F8E46 for ; Fri, 17 May 2013 00:58:30 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARL76991; Fri, 17 May 2013 07:58:29 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 17 May 2013 08:57:49 +0100 Received: from SZXEML455-HUB.china.huawei.com (10.82.67.198) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 17 May 2013 15:58:23 +0800 Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.222]) by SZXEML455-HUB.china.huawei.com ([10.82.67.198]) with mapi id 14.01.0323.007; Fri, 17 May 2013 15:58:18 +0800 From: Fatai Zhang To: Lou Berger , "BELOTTI, SERGIO (SERGIO)" Thread-Topic: R: Closing G.709 open issues Thread-Index: AQHOTAyDmhSnK0jr+ESubR/xu8VPgpj8bQiw///u0ICAADKIAIAABpSAgAEN6tCAADjpAIAEmsGw///G7YCAAffecIAAA0UAgAEzTICAADLXgIAACRmAgAAzFQCAAzHYYA== Date: Fri, 17 May 2013 07:58:17 +0000 Message-ID: References: <518A82D9.7080508@labn.net> <518BAB17.9090807@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> <518CED28.30303@labn.net> <51924382.2010904@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C90D5@ESESSMB301.ericsson.se> <13ea7ed3bdd.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <5193A26A.1090005@labn.net> In-Reply-To: <5193A26A.1090005@labn.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-cr-hashedpuzzle: BVHx GHge LjXI OmzX O7Dj PpkM QPTC UHyJ UvDU WAP1 Wnfu aZvl h3Qa uyac wDME wmLo; 5; YwBjAGEAbQBwAEAAaQBlAHQAZgAuAG8AcgBnADsAZABhAG4AaQBlAGwAZQAuAGMAZQBjAGMAYQByAGUAbABsAGkAQABlAHIAaQBjAHMAcwBvAG4ALgBjAG8AbQA7AGQAcgBhAGYAdAAtAGkAZQB0AGYALQBjAGMAYQBtAHAALQBnAG0AcABsAHMALQBzAGkAZwBuAGEAbABpAG4AZwAtAGcANwAwADkAdgAzAEAAdABvAG8AbABzAC4AaQBlAHQAZgAuAG8AcgBnADsAbABiAGUAcgBnAGUAcgBAAGwAYQBiAG4ALgBuAGUAdAA7AHMAZQByAGcAaQBvAC4AYgBlAGwAbwB0AHQAaQBAAGEAbABjAGEAdABlAGwALQBsAHUAYwBlAG4AdAAuAGMAbwBtAA==; Sosha1_v1; 7; {A4398744-541C-4856-B412-0B7BC7C898EC}; egBoAGEAbgBnAGYAYQB0AGEAaQBAAGgAdQBhAHcAZQBpAC4AYwBvAG0A; Fri, 17 May 2013 07:58:08 GMT; UgBFADoAIABSADoAIABDAGwAbwBzAGkAbgBnACAARwAuADcAMAA5ACAAbwBwAGUAbgAgAGkAcwBzAHUAZQBzAA== x-cr-puzzleid: {A4398744-541C-4856-B412-0B7BC7C898EC} x-originating-ip: [10.66.72.159] Content-Type: multipart/mixed; boundary="_004_F82A4B6D50F9464B8EBA55651F541CF84317D2BASZXEML552MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" Subject: Re: [CCAMP] R: Closing G.709 open issues X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 07:58:38 -0000 --_004_F82A4B6D50F9464B8EBA55651F541CF84317D2BASZXEML552MBXchi_ Content-Type: multipart/alternative; boundary="_000_F82A4B6D50F9464B8EBA55651F541CF84317D2BASZXEML552MBXchi_" --_000_F82A4B6D50F9464B8EBA55651F541CF84317D2BASZXEML552MBXchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Lou, I thought it should be sufficient for me to identify the *updated* and *new= * G-PIDs in this draft (I compared [G.709-2003] and [G.709-2012], and check= ed RFC4328), but I would be happy to provide a full list for your request. Please see the list below, and the new payload types introduced by [G.709-2= 012] (and the corresponding new G-PIDs defined in this draft) are in the li= ght blue cells. Please check if there is anything missed or wrong. Note that GPIDs like 32,= 47,49-52 have been updated in this draft. Note that we as authors welcome any contributors for their contribution. For you convenience, I also attached the word document. G-PIDs vs Payload types defined in Table 15-8 of G.709 G-PID LSP Encoding Payload Type in Hex code defined in G.709 Note Interpretation from G.709 None 0x01 Not needed Experimental mapping (Note 3) 49 G.709 ODUk, G.709 OCh 0x02 1)G-PID defined in RFC4328; 2) Updated in this draft. Asynchronous CBR mapping, see clause 17.2 50 G.709 ODUk 0x03 ditto Bit synchronous CBR mapping, see clause 17.2 32 SDH, G.709 ODUk 0x04 ditto ATM mapping, see clause 17.3 54 G.709 ODUk (and SDH) 0x05 G-PIDs defined in RFC4328 with two kinds of GFPs (Ethernet MAC (framed GFP) GFP mapping, see clause 17.4 None 0x06 Not needed and Not defined in RFC4328 Virtual Concatenated signal, see clause 18 (Note 5) 61(TBA) G.709 ODUk (k=3D0,3,4) 0x07 Is being defined in this draft (new payload type defined in [G.709-2012]) PCS codeword transparent Ethernet mapping: =B7 1000BASE-X into OPU0, see clauses 17.7.1 and 17.7.1.1 =B7 40GBASE-R into OPU3, see clauses 17.7.4 and 17.7.4.1 =B7 100GBASE-R into OPU4, see clauses 17.7.5 and 17.7.5.1 62(TBA) G.709 ODUk (k=3D2e) 0x08 ditto FC-1200 into OPU2e mapping, see clause 17.8.2 63(TBA) G.709 ODUk (k=3D2) 0x09 ditto GFP mapping into Extended OPU2 payload, see clause 17.4.1 (Note 6) 64(TBA) G.709 ODUk (k=3D0) 0x0A ditto STM-1 mapping into OPU0, see clause 17.7.1 65(TBA) G.709 ODUk (k=3D0) 0x0B ditto STM-4 mapping into OPU0, see clause 17.7.1 66(TBA) G.709 ODUk (k=3D0) 0x0C ditto FC-100 mapping into OPU0, see clause 17.7.1 67(TBA) G.709 ODUk (k=3D1) 0x0D ditto FC-200 mapping into OPU1, see clause 17.7.2 68(TBA) G.709 ODUflex 0x0E ditto FC-400 mapping into OPUflex, see clause 17.9 69(TBA) G.709 ODUflex 0x0F ditto FC-800 mapping into OPUflex, see clause 17.9 51 G.709 ODUk 0x10 1)G-PID defined in RFC4328; 2) Updated in this draft. Bit stream with octet timing mapping, see clause 17.6.1 52 G.709 ODUk 0x11 ditto Bit stream without octet timing mapping, see clause 17.6.2 70(TBA) G.709 ODUflex 0x12 Is being defined in this draft (new payload type defined in [G.709-2012]) IB SDR mapping into OPUflex, see 17.9 71(TBA) G.709 ODUflex 0x13 ditto IB DDR mapping into OPUflex, see 17.9 72(TBA) G.709 ODUflex 0x14 ditto IB QDR mapping into OPUflex, see 17.9 73(TBA) G.709 ODUk (k=3D0) 0x15 ditto SDI mapping into OPU0, see 17.7.1 74(TBA) G.709 ODUk (k=3D1) 0x16 ditto (1.485/1.001) Gbit/s SDI mapping into OPU1, see 17.7.2 75(TBA) G.709 ODUk (k=3D1) 0x17 ditto 1.485 Gbit/s SDI mapping into OPU1, see 17.7.2 76(TBA) G.709 ODUflex 0x18 ditto (2.970/1.001) Gbit/s SDI mapping into OPUflex, see 17.9 77(TBA) G.709 ODUflex 0x19 ditto 2.970 Gbit/s SDI mapping into OPUflex, see 17.9 78(TBA) G.709 ODUk (k=3D0) 0x1A ditto SBCON/ESCON mapping into OPU0, see 17.7.1 79(TBA) G.709 ODUk (k=3D0) 0x1B ditto DVB_ASI mapping into OPU0, see 17.7.1 47 G.709 ODUk 0x20 1) G-PIDs defined in RFC4328. 2) Updated in this draft. ODU multiplex structure supporting ODTUjk only, see clause 19 (AMP only) 59/60 G.709 ODUk 0x21 1)Are being defined in this draft (new payload type defined in [G.709-2012]= ); 2) 59 for G.709 ODU-1.25G; 60 for G.709 ODU-any ODU multiplex structure supporting ODTUk.ts or ODTUk.ts and ODTUjk, see cla= use 19 (GMP capable) (Note 7) None 55 Not needed Not available (Note 2) None 66 Not needed Not available (Note 2) None 80-8F Not needed Reserved codes for proprietary use (Note 4) None FD Not needed NULL test signal mapping, see clause 17.5.1 None FE Not needed PRBS test signal mapping, see clause 17.5.2 None FF Not needed Not available (Note 2) Best Regards Fatai -----Original Message----- From: Lou Berger [mailto:lberger@labn.net] Sent: Wednesday, May 15, 2013 10:58 PM To: BELOTTI, SERGIO (SERGIO); Fatai Zhang Cc: Daniele Ceccarelli; CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tool= s.ietf.org Subject: Re: R: Closing G.709 open issues Sergio/Fatai, On 5/15/2013 7:54 AM, BELOTTI, SERGIO (SERGIO) wrote: > We (as authors" were asked to cope with the remaining issues to start sec= ond LC. > One these "remaining issues" was as fro Lou's mil of May 9th > > 2) Verify that the complete list of G-PIDs are defined [SIGNALING] > > In signaling document section 4, verify that all payload types > defined in G.709 (Summarized in Table 15-8) can be represented. > This issue can be resolved via an update or message to the list > stating that the verification took place. > > This is concluded by Fatai answer regarding G-PID check and 1:1 mapping. And, based on the discussion, I (to be clear, as WG chair) have revised the request by asking: "that the editors of the draft provide (and include in the document) a full list of Payload Type values (with the 0x value prefix or the values in decimal) and their corresponding G-PID values. Also including Encoding Type as you [Fatai] have below is a good addition -- great idea!" Given the level of discussion of this thread, I think this is a completely reasonable way to avoid future confusion, particularly in implementations. Do the Authors/Editor need help in generating this complete list? Do the Authors/Editor want (me) to issue a call for input on this list? I suspect some in WG will be happy to jump in as it's an easy way to get added as a contributor to the signaling draft. > > FATAI> For point 2), I compared [G.709-2003] and [G.709-2012], and checke= d the GPIDs defined in [RFC4328], I think the following new GPIDs (values c= ould be 59-79) should be added (besides updating some GPIDs defined in RFC4= 328, like 32,47,49-52): > > Value G-PID Type LSP Encoding Type > ----- ---------- ----------------- > 59(TBA) G.709 ODU-1.25G G.709 ODUk > 60(TBA) G.709 ODU-any G.709 ODUk > 61(TBA) PCS G.709 ODUk (k=3D0) > 62(TBA) FC-1200 G.709 ODUk (k=3D2e) > 63(TBA) eOPU2 G.709 ODUk (k=3D2) > 64(TBA) STM-1 G.709 ODUk (k=3D0) > 65(TBA) STM-4 G.709 ODUk (k=3D0) > 66(TBA) FC-100 G.709 ODUk (k=3D0) > 67(TBA) FC-200 G.709 ODUk (k=3D1) > 68(TBA) FC-400 G.709 ODUflex > 69(TBA) FC-800 G.709 ODUflex > 70(TBA) IB SDR G.709 ODUflex > 71(TBA) IB DDR G.709 ODUflex > 72(TBA) IB QDR G.709 ODUflex > 73(TBA) SDIa G.709 ODUk (k=3D0) > 74(TBA) SDIb G.709 ODUk (k=3D1) > 75(TBA) SDIc G.709 ODUk (k=3D1) > 76(TBA) SDId G.709 ODUflex > 77(TBA) SDIe G.709 ODUflex > 78(TBA) SB/ESCON G.709 ODUk (k=3D0) > 79(TBA) DVB_ASI G.709 ODUk (k=3D0) > > All this has nothing to do with specifc ADAPTATION object , for which I = was always in favour but it seems as though it is linked to MRN discussion = and out of specifc OTN. > So I went looking for past discussions on this, and this is what I find: - From http://www.ietf.org/mail-archive/web/ccamp/current/msg13598.html On 7/19/2012 11:45 AM, Lou Berger wrote: > (As participant in thread) I read that the conclusion is to not optimize > for a very special corner case and: > 1) basically treat the intra-OTN case the same as any other MRN/MLN case > (leveraging GPID, and no new hierarchy object) > 2) Use Daniele's new draft on MRN/MLN as the starting point in the > discussion of how to address the limitations in MRN/MLN identified in > this discussion. >From http://tools.ietf.org/agenda/84/slides/slides-84-ccamp-7.pdf > G-PID Value Extension > o Extended G-PID for G.709 ODU client signals: > Value G-PID Type TSG (LO ODU into requested LSP) > ----- ---------- ---------------- > 47 G.709 ODU 2.5Gbps [RFC4328] > 59(TBA) G.709 ODU-1.25G 1.25Gbps (new) > 60(TBA) G.709 ODU-any either 1.25 or 2.5Gbps(new) > > o Added other new G-PID values for new client signals supported by G.709V= 3 > Value G-PID Type > ----- ---------- > 61(TBA) CBRc (via GMP) > 62(TBA) 1000BASE-X > 63(TBA) FC-1200 > > o Updated some existing G-PID description to support new 1.25G, 100G, > supra-2.488G client signals, such as 32 for ATM, 49 for asynchronous > CBR , 50 for synchronous CBR , 51 for BSOT, 52 for BSNT. I have not interest/need to revist past consensus on G-PIDs & TSGs, so will limit my comments to the newly defined G-PIDs. My questions on the new G-PIDs come down to: - Why are rate specific G-PIDs being proposed (rather than continuing to use the previous approach documented in the draft and in Section 3.1.3 of rfc4328)? - Why are new values being defined rather than using existing values, e.g., G-PID 56? That's it. Lou > Hope this can help. > > Best Regards > Sergio > > Belotti Sergio- System Architect > ALCATE-LUCENT Optics Division > via Trento 30 Vimercate (MB) - Italy > phone +39 (039) 6863033 > > -----Messaggio originale----- > Da: Lou Berger [mailto:lberger@labn.net] > Inviato: mercoled=EC 15 maggio 2013 13.22 > A: Daniele Ceccarelli; Fatai Zhang > Cc: BELOTTI, SERGIO (SERGIO); CCAMP; draft-ietf-ccamp-gmpls-signaling-g70= 9v3@tools.ietf.org; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org > Oggetto: RE: Closing G.709 open issues > > Daniele, > > On May 15, 2013 4:20:25 AM Daniele Ceccarelli > wrote: >> Hi Lou, >> >> Just a bit. >>> My memory is that the consensus at the time was that G.709 would contin= ue >> to use the current generic approach to edge adaptation & G-PIDs, and tha= t >> (some of) the G.709 authors would submit a draft that would address >> adaptation in a generic fashion. >>> >> >> If i correctly remember we agreed to solve the routing issu in a generic >> approach, not the signaling one. > > We must be thinking of different threads. The one I'm thinking of started > with the comment along the lines of "why only some G-PIDs represented in > the ADAPTATION object" and concluded with the agreement to drop the objec= t > and follow the current generic approach as well as look into a non-OTN > specific solution in a new draft. At least that's how I remember it.... > >> It is possible to assume that the adaptation is a known info to the >> operator and hence that the advertisement can be postponed and addressed= in >> a generic way but it needs to be signaled. >> >> This is an hortogonal issue with respect to the mapping of G-PID, which = has >> always been assumed to be 1:1 with G.709 values. > > humm, this seems inconsistent with Fatai recently suggesting that i was > asking for a "non-grouped" approach. At the time, I was really just > thinking about the values missing in the list I sent out. I don't recall > any other discussion on moving away from the past 709 G-PID assignment > approach. > >> The 1:1 *mapping* approach used by Fatai is different from the *mapping" >> protocol like GFP, AMP that we discussed before. >> > > It looks like we both/all should take a look at the archives to refresh o= ur > memories.... > > Thanks, > Lou > >> BR >> Daniele, Sergio, Fatai >> >> >>> -----Original Message----- >>> From: Lou Berger [mailto:lberger@labn.net] Sent: marted=EC 14 maggio 20= 13 16.01 >>> To: Fatai Zhang >>> Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; >> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; >> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org >>> Subject: Re: Closing G.709 open issues >>> >>> Fatai, Sergio, >>> I haven't had time to go find the old mail covering the topic = you >> mentioned (which is why I didn't respond yesterday): >>>> I think this has been discussed for quite long time before Vancouver >> meeting, which was famous as "penultimate" issue. >>>> >>>> I don't think we need discuss this anymore. >>> >>> My memory is that the consensus at the time was that G.709 would contin= ue >> to use the current generic approach to edge adaptation & G-PIDs, and tha= t >> (some of) the G.709 authors would submit a draft that would address >> adaptation in a generic fashion. >>> >>> Do you think this characterization is mistaken? (If so, time to go >> searching for the old discussion, if not we can move on.) >>> >>> Assuming no, then it seems to me that you are going against this >> discussion & consensus by now introducing a 1:1/bandwidth specific mappi= ng >> approach. Do you disagree? If not, do you think there's justification t= o >> reopen this discussion? >>> >>> Independent of the mapping approach and in order to ensure this issue i= s >> closed and does not again resurface, I also request (again) that the >> editors of the draft provide (and include in the document) a full list o= f >> Payload Type values (with the 0x value prefix or the values in >>> decimal) and their corresponding G-PID values. Also including Encoding >> Type as you have below is a good addition -- great idea! >>> >>> Lou >>> >>> On 5/14/2013 1:53 AM, Fatai Zhang wrote: >>>> Hi all, >>>> Thanks, Sergio. >>>> I would like to double check if everything is OK before we >update the >> signaling draft. >>>> I would assume the WG is happy with 1:1 mapping approach and >the new >> GPIDs listed below if there is no more comment until this Wed. >>>> >>>> Best Regards >>>> Fatai >>>> >>>> -----Original Message----- >>>> From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-lucent.c= om] >>>> Sent: Monday, May 13, 2013 3:45 PM >>>> To: Fatai Zhang; Lou Berger >>>> Cc: Daniele Ceccarelli; CCAMP; >> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; >> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org >>>> Subject: R: Closing G.709 open issues >>>> Hi Fatai, >>>> I agree with you, for both point 1 and 2. >>>> Best Regards >>>> Sergio >>>> Belotti Sergio- System Architect >>>> ALCATE-LUCENT Optics Division >>>> via Trento 30 Vimercate (MB) - Italy >>>> phone +39 (039) 6863033 >>>> -----Messaggio originale----- >>>> Da: Fatai Zhang [mailto:zhangfatai@huawei.com] >>>> Inviato: luned=EC 13 maggio 2013 5.33 >>>> A: Lou Berger >>>> Cc: Daniele Ceccarelli; CCAMP; >> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; >> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org >>>> Oggetto: RE: Closing G.709 open issues >>>> Hi Lou, >>>> I think you have two major points here. >>>> (1) Do you really need 3 G-PID types for an ODU (I thought >TSG was >> already covered)? >>>> I think this has been discussed for quite long time before >Vancouver >> meeting, which was famous as "penultimate" issue. >Note that this TSG in >> GPID is different from the *implicit* >TSG in label format. >>>> I don't think we need discuss this anymore. >>>> (2) 'Grouped GPID' vs '1:1' mapping (between G.709-2012 and GPIDs >> defined in this draft) >>>> We realize that it is safe to use 1:1 mapping approach to >avoid some >> potential issues after investigation. We know this >payload types have b= een >> defined by G.709 (data plane), so >physically it is better to use 1:1 >> mapping approach. For the potential issues I mentioned above, for exampl= e, >> we >cannot use the existing 34 to represent 'STM-1' and 'STM-4 ', >becau= se >> it is impossible to differentiate which one is 'STM-1' >or 'STM-4'. In >> addition, from the concept of payload type, we >know that e.g, FC-100 is >> different from FC-800, right? So, it >is better to assign different GPID= s >> to these different payload >types defined by the data plane. >>>> Furthermore, I think it is much cheaper to create new GPIDs >in the >> control plane than in the data plane (these payload >types will be carri= ed >> in the OH). >>>> >>>> Best Regards >>>> Fatai >>>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: Friday, May 10, 2013 8:51 PM >>>> To: Fatai Zhang >>>> Cc: Daniele Ceccarelli; CCAMP; >> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; >> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org >>>> Subject: Re: Closing G.709 open issues >>>> >>>> On 5/9/2013 9:41 PM, Fatai Zhang wrote: >>>>> Hi Lou, >>>>> >>>>> For point 1), "1" should be dropped and "7" should be >corrected to "= 8" >> in your proposed text. >> >> Great. >>>>>>> >>>>> I hesitate to make a decision on either approach, I would >like to >> defer to the WG consensus. >>>>> >>>> I believe we already have a consensus position. The question in my ma= il >> was do we need to revisit it. I take your response as a no. (thank you!= ) >>>>>>> For point 2), I compared [G.709-2003] and [G.709-2012], and checked >>>>> the GPIDs defined in [RFC4328], I think the following new GPIDs >>> >> (values could be 59-79) should be added (besides updating >some GPIDs >>= > >> defined in RFC4328, like 32,47,49-52): >>>>> >>>> I suggest going through the full PT list and identifying them in the >> table (as I started in my last message) so that there is no >confusion i= n >> implementations. >>>> In the list below it looks like you have moved away from the >'grouped >> G-PID' approach. Is there a reason for this change? >>>> Refer to >>>>> http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parame= t >>>> ers.xml >>>> in subsequent comments. >>>>>>> Value G-PID Type LSP Encoding Type >>>>> ----- ---------- ----------------- >>>>> 59(TBA) G.709 ODU-1.25G G.709 ODUk 60(TBA) G.709 >> ODU-any G.709 ODUk >>>> Do you really need 3 G-PID types for an ODU (I thought TSG >was alread= y >> covered)? >>>>>>> 61(TBA) PCS G.709 ODUk (k=3D0) >>>>> 62(TBA) FC-1200 G.709 ODUk (k=3D2e) >>>> Why not us existing G-PID 58? >>>>>>> 63(TBA) eOPU2 G.709 ODUk (k=3D2) >>>>>>> 64(TBA) STM-1 G.709 ODUk (k=3D0) >>>>> 65(TBA) STM-4 G.709 ODUk (k=3D0) >>>> Why not us existing G-PID 34? >>>>>>> 66(TBA) FC-100 G.709 ODUk (k=3D0) >>>>> 67(TBA) FC-200 G.709 ODUk (k=3D1) >>>>> 68(TBA) FC-400 G.709 ODUflex >>>>> 69(TBA) FC-800 G.709 ODUflex >>>> Why not us existing G-PID 58? >>>>>>> 70(TBA) IB SDR G.709 ODUflex >>>>> 71(TBA) IB DDR G.709 ODUflex >>>>> 72(TBA) IB QDR G.709 ODUflex >>>> Can these be one value with rate implying SDR/DDR/QDR? >>>>>>> 73(TBA) SDIa G.709 ODUk (k=3D0) >>>>> 74(TBA) SDIb G.709 ODUk (k=3D1) >>>>> 75(TBA) SDIc G.709 ODUk (k=3D1) >>>>> 76(TBA) SDId G.709 ODUflex >>>>> 77(TBA) SDIe G.709 ODUflex >>>> Can these be one value with rate implying a-e? >>>>>>> 78(TBA) SB/ESCON G.709 ODUk (k=3D0) >>>> Why not us existing G-PID 56? >>>>>>> 79(TBA) DVB_ASI G.709 ODUk (k=3D0) >>>>> >>>>> >>>>> >>>>> >>>> Thanks, >>>> Lou >>>> >>>> >>>> >>> > > > > > > --_000_F82A4B6D50F9464B8EBA55651F541CF84317D2BASZXEML552MBXchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi L= ou,

 

I th= ought it should be sufficient for me to identify the *updated* and *= new* G-PIDs in this draft (I compared [G.709-2003] and [G.709-2012],= and checked RFC4328), but I would be happy to provide a full list for your request.

 

Plea= se see the list below, and the new payload types introduced by [G.709-2012]= (and the corresponding new G-PIDs defined in this draft) are in the light = blue cells.

 

Plea= se check if there is anything missed or wrong. Note that GPIDs like 32,47,4= 9-52 have been updated in this draft.

 

Note= that we as authors welcome any contributors for their contribution.

 

For = you convenience, I also attached the word document.

 

 

G-PIDs vs Payload types defined in Table 15-8 = of G.709

 

G-= PID

LS= P Encoding

Pa= yload Type in Hex code defined in G.709=

No= te

In= terpretation from = G.709

None

 

0x01

Not needed

Experimental mapping (Note 3)

49

G.709 ODUk, G.709 OCh

0x02

1)G-PID defined in RFC4328;

2) Updated in this draft.

Asynchronous CBR mapping, see clause 17.2

50

G.709 ODUk

0x03

ditto

Bit synchronous CBR mapping, see clause 17.2

32

SDH, G.709 ODUk

0x04

ditto

ATM mapping, see clause 17.3

54

G.709 ODUk (and SDH)=

 

0x05

G-PIDs defined in RFC4328 with two kinds of GFPs (Ethernet MAC (framed GF= P)

 

GFP mapping, see clause 17.4

None

 

0x06

Not needed and Not defined in R= FC4328

Virtual Concatenated signal, se= e clause 18 (Note 5)

61(TBA)

G.709 ODUk (k=3D0,3,4)

0x07

Is being defined in this draft = (new payload type defined in [G.709-2012])

PCS codeword transparent Ethern= et mapping:

=B7      1000BASE-X into OPU0, s= ee clauses 17.7.1 and 17.7.1.1

=B7      40GBASE-R into OPU3, se= e clauses 17.7.4 and 17.7.4.1

=B7      100GBASE-R into OPU4, s= ee clauses 17.7.5 and 17.7.5.1

62(TBA)

G.709 ODUk (k=3D2e)

0x08

ditto

FC-1200 into OPU2e mapping, see= clause 17.8.2

63(TBA)

G.709 ODUk (k=3D2)

0x09

ditto

GFP mapping into Extended OPU2 = payload, see clause 17.4.1 (Note 6)

64(TBA)

G.709 ODUk (k=3D0)

0x0A

ditto

STM-1 mapping into OPU0, see cl= ause 17.7.1

65(TBA)

G.709 ODUk (k=3D0)

0x0B

ditto

STM-4 mapping into OPU0, see cl= ause 17.7.1

66(TBA)

G.709 ODUk (k=3D0)

0x0C

ditto

FC-100 mapping into OPU0, see c= lause 17.7.1

67(TBA)

G.709 ODUk (k=3D1)

0x0D

ditto

FC-200 mapping into OPU1, see c= lause 17.7.2

68(TBA)

G.709 ODUflex

0x0E

ditto

FC-400 mapping into OPUflex, se= e clause 17.9

69(TBA)

G.709 ODUflex

0x0F

ditto

FC-800 mapping into OPUflex, se= e clause 17.9

51

G.709 ODUk

0x10

1)G-PID defined in RFC4328;

2) Updated in this draft.

Bit stream with octet timing ma= pping, see clause 17.6.1

52

G.709 ODUk

0x11

ditto

Bit stream without octet timing= mapping, see clause 17.6.2

70(TBA)

G.709 ODUflex

0x12

Is being defined in this draft = (new payload type defined in [G.709-2012])=

IB SDR  mapping into OPUfl= ex, see 17.9

71(TBA)

G.709 ODUflex

0x13

ditto

IB DDR mapping into OPUflex, se= e 17.9

72(TBA)

G.709 ODUflex

0x14

ditto

IB QDR mapping into OPUflex, se= e 17.9

73(TBA)

G.709 ODUk (k=3D0)

0x15

ditto

SDI  mapping into OPU0, se= e 17.7.1

74(TBA)

G.709 ODUk (k=3D1)

0x16

ditto

(1.485/1.001) Gbit/s SDI mappin= g into OPU1, see 17.7.2

75(TBA)

G.709 ODUk (k=3D1)

0x17

ditto

1.485 Gbit/s SDI mapping into O= PU1, see 17.7.2

76(TBA)

G.709 ODUflex

0x18

ditto

(2.970/1.001) Gbit/s SDI mappin= g into OPUflex, see 17.9

77(TBA)

G.709 ODUflex

0x19

ditto

2.970 Gbit/s SDI mapping into O= PUflex, see 17.9

78(TBA)

G.709 ODUk (k=3D0)

0x1A

ditto

SBCON/ESCON mapping into OPU0, = see 17.7.1

79(TBA)

G.709 ODUk (k=3D0)

0x1B

ditto

DVB_ASI mappin= g into OPU0, see 17.7.1

47

G.709 ODUk

0x20

1) G-PIDs defined in RFC4328. <= o:p>

2) Updated in this draft.<= /o:p>

ODU multiplex structure support= ing ODTUjk only, see clause 19 (AMP only)

59/60

G.709 ODUk

0x21

1)Are being de= fined in this draft (new payload type defined in [G.709-2012]);<= /span>

2) 59 for G.709 ODU-1.25G; 60 f= or G.709 ODU-any

ODU multiplex = structure supporting ODTUk.ts or ODTUk.ts and ODTUjk, see clause 19 (GMP ca= pable) (Note 7)

None

 

55

Not needed

Not available (Note 2)

None

 

66

Not needed

Not available (Note 2)

None

 

80-8F

Not needed

Reserved codes for proprietary = use (Note 4)

None

 

FD

Not needed

NULL test signal mapping, see c= lause 17.5.1

None

 

FE

Not needed

PRBS test signal mapping, see c= lause 17.5.2

None

 

FF

Not needed

Not available (Note 2)

 

 

 

 

 

 

 

 

 

 

Best Regards

 

Fatai

 

 

-----Original Message----- From: Lou Berger [mailto:lberger@labn.net]
Sent: Wednesday, May 15, 2013 10:58 PM
To: BELOTTI, SERGIO (SERGIO); Fatai Zhang
Cc: Daniele Ceccarelli; CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tool= s.ietf.org
Subject: Re: R: Closing G.709 open issues

 

Sergio/Fatai,

 

On 5/15/2013 7:54 AM, BELOTT= I, SERGIO (SERGIO) wrote:

> We (as authors" we= re asked to cope with the remaining issues to start second LC.

> One these "remaini= ng issues" was as fro Lou's mil of May 9th

>

> 2) Verify that the comp= lete list of G-PIDs are defined [SIGNALING]

>

>   In signalin= g document section 4, verify that all payload types

>   defined in = G.709 (Summarized in Table 15-8) can be represented.

>   This issue = can be resolved via an update or message to the list

>   stating tha= t the verification took place.

>

> This is concluded by Fa= tai answer regarding G-PID check and 1:1 mapping.

 

And, based on the discussion= , I (to be clear, as WG chair) have revised

the request by asking:<= /o:p>

  "that the editor= s of the draft provide (and include in the document)

   a full list of = Payload Type values (with the 0x value prefix or the

   values in decim= al) and their corresponding G-PID values.  Also

   including Encod= ing Type as you [Fatai] have below is a good addition

   -- great idea!&= quot;

 

Given the level of discussio= n of this thread, I think this is a

completely reasonable way to= avoid future confusion, particularly in

implementations.<= /span>

 

Do the Authors/Editor need h= elp in generating this complete list?

 

Do the Authors/Editor want (= me) to issue a call for input on this list?

I suspect some in WG will be= happy to jump in as it's an easy way to

get added as a contributor t= o the signaling draft.

 

>

> FATAI> For point 2),= I compared [G.709-2003] and [G.709-2012], and checked the GPIDs defined in= [RFC4328], I think the following new GPIDs (values could be 59-79) should = be added (besides updating some GPIDs defined in RFC4328, like 32,47,49-52):

>

>    = Value       G-PID Type   &nbs= p;         LSP Encoding Type

>     = ; -----       ----------  &nbs= p;          -----------------<= o:p>

>    59(TB= A)     G.709 ODU-1.25G     &nb= sp;  G.709 ODUk

>    60(TB= A)     G.709 ODU-any      = ;    G.709 ODUk

>    61(TB= A)     PCS       &nb= sp;            G.709= ODUk (k=3D0)

>    62(TB= A)     FC-1200       = ;         G.709 ODUk (k=3D2e)<= /o:p>

>    63(TB= A)     eOPU2       &= nbsp;         G.709 ODUk (k=3D2)

>    64(TB= A)     STM-1       &= nbsp;          G.709 ODUk (k= =3D0)

>    65(TB= A)     STM-4       &= nbsp;          G.709 ODUk (k= =3D0)

>    66(TB= A)     FC-100       =           G.709 ODUk (k=3D0)

>    67(TB= A)     FC-200       =           G.709 ODUk (k=3D1)

>    68(TB= A)     FC-400       =           G.709 ODUflex

>    69(TB= A)     FC-800       =           G.709 ODUflex

>    70(TB= A)     IB SDR       =           G.709 ODUflex

>    71(TB= A)     IB DDR       =           G.709 ODUflex

>    72(TB= A)     IB QDR       =           G.709 ODUflex

>    73(TB= A)     SDIa       &n= bsp;           G.709 ODUk= (k=3D0)

>    74(TB= A)     SDIb       &n= bsp;           G.709 ODUk= (k=3D1)

>    75(TB= A)     SDIc       &n= bsp;           G.709 ODUk= (k=3D1)

>    76(TB= A)     SDId       &n= bsp;           G.709 ODUf= lex

>    77(TB= A)     SDIe       &n= bsp;           G.709 ODUf= lex

>    78(TB= A)     SB/ESCON      &nbs= p;       G.709 ODUk (k=3D0)=

>    79(TB= A)     DVB_ASI       = ;         G.709 ODUk (k=3D0)

>

 

> All this has nothing to= do with specifc ADAPTATION object , for which  I was always in favour= but it seems as though it is linked to MRN discussion and out of specifc O= TN.

>

 

So I went looking for past d= iscussions on this, and this is what I find:

 

- From http://www.ietf.org/m= ail-archive/web/ccamp/current/msg13598.html

On 7/19/2012 11:45 AM, Lou B= erger wrote:

> (As participant in thre= ad) I read that the conclusion is to not optimize

> for a very special corn= er case and:

> 1) basically treat the = intra-OTN case the same as any other MRN/MLN case

>    (leve= raging GPID, and no new hierarchy object)

> 2) Use Daniele's new dr= aft on MRN/MLN as the starting point in the

> discussion of how to ad= dress the limitations in MRN/MLN identified in

> this discussion.

 

From http://tools.ietf.org/a= genda/84/slides/slides-84-ccamp-7.pdf

> G-PID Value Extension

> o Extended G-PID for G.= 709 ODU client signals:

>   Value G-PID= Type TSG (LO ODU into requested LSP)

>   ----- -----= ----- ----------------

>   47 G.709 OD= U 2.5Gbps [RFC4328]

>   59(TBA) G.7= 09 ODU-1.25G 1.25Gbps (new)

>   60(TBA) G.7= 09 ODU-any either 1.25 or 2.5Gbps(new)

>

> o Added other new G-PID= values for new client signals supported by G.709V3

>   Value G-PID= Type

>   ----- -----= -----

>   61(TBA) CBR= c (via GMP)

>   62(TBA) 100= 0BASE-X

>   63(TBA) FC-= 1200

>

> o Updated some existing= G-PID description to support new 1.25G, 100G,

>   supra-2.488= G client signals, such as 32 for ATM, 49 for asynchronous

>   CBR , 50 fo= r synchronous CBR , 51 for BSOT, 52 for BSNT.

 

I have not interest/need to = revist past consensus on G-PIDs & TSGs, so

will limit my comments to th= e newly defined G-PIDs.

 

My questions on the new G-PI= Ds come down to:

- Why are rate specific G-PI= Ds being proposed (rather than

  continuing to use the= previous approach documented in the draft

  and in Section 3.1.3 = of rfc4328)?

 

- Why are new values being d= efined rather than using existing

  values, e.g., G-PID 5= 6?

 

That's it.=

 

Lou

 

> Hope this can help.

>

> Best Regards=

> Sergio

>

> Belotti Sergio-  S= ystem Architect

> ALCATE-LUCENT  Opt= ics Division

> via Trento 30 Vimercate= (MB) - Italy

> phone +39 (039) 686= 3033

>

> -----Messaggio original= e-----

> Da: Lou Berger [mailto:= lberger@labn.net]

> Inviato: mercoled=EC 15 maggio 2013 13.22

> A: Daniele Ceccarelli; = Fatai Zhang

> Cc: BELOTTI, SERGIO (SE= RGIO); CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; draft= -ietf-ccamp-otn-g709-info-model@tools.ietf.org

> Oggetto: RE: Closing G.= 709 open issues

>

> Daniele,

>

> On May 15, 2013 4:20:25= AM Daniele Ceccarelli

> <daniele.ceccarelli@= ericsson.com> wrote:

>> Hi Lou,<= /span>

>> 

>> Just a bit.

>>> My memory is th= at the consensus at the time was that G.709 would continue

>> to use the current = generic approach to edge adaptation & G-PIDs, and that

>> (some of) the G.709= authors would submit a draft that would address

>> adaptation in a gen= eric fashion.

>>> 

>> 

>> If i correctly reme= mber we agreed to solve the routing issu in a generic

>> approach, not the s= ignaling one.

>

> We must be thinking of = different threads. The one I'm thinking of started

> with the comment along = the lines of "why only some G-PIDs represented in

> the ADAPTATION object&q= uot; and concluded with the agreement to drop the object

> and follow the current = generic approach as well as look into a non-OTN

> specific solution in a = new draft.  At least that's how I remember it....

>

>> It is possible to a= ssume that the adaptation is a known info to the

>> operator and hence = that the advertisement can be postponed and addressed in

>> a generic way but i= t needs to be signaled.

>> 

>> This is an hortogon= al issue with respect to the mapping of G-PID, which has

>> always been assumed= to be 1:1 with G.709 values.

>

> humm, this seems incons= istent with Fatai  recently suggesting that i was

> asking for a "non-= grouped" approach.  At the time, I was really just

> thinking about the valu= es missing in the list I sent out. I don't recall

> any other discussion on= moving away from the past 709 G-PID assignment

> approach.

>

>> The 1:1 *mapping* a= pproach used by Fatai is different from the *mapping"

>> protocol like GFP, = AMP that we discussed before.

>> 

>

> It looks like we both/a= ll should take a look at the archives to refresh our

> memories....=

>

> Thanks,

>  Lou

>

>> BR

>> Daniele, Sergio, Fa= tai

>> 

>> 

>>> -----Original M= essage-----

>>> From: Lou Berge= r [mailto:lberger@labn.net] Sent: marted=EC 14= maggio 2013 16.01

>>> To: Fatai Zhang=

>>> Cc: BELOTTI, SE= RGIO (SERGIO); Daniele Ceccarelli; CCAMP;

>> draft-ietf-ccamp-gm= pls-signaling-g709v3@tools.ietf.org;

>> draft-ietf-ccamp-ot= n-g709-info-model@tools.ietf.org

>>> Subject: Re: Cl= osing G.709 open issues

>>> 

>>> Fatai, Sergio,<= o:p>

>>>   &nb= sp;      I haven't had time to go find the old mai= l covering the topic you

>> mentioned (which is= why I didn't respond yesterday):

>>>> I think thi= s has been discussed for quite long time before Vancouver

>> meeting, which was = famous as "penultimate" issue.

>>>> <= /o:p>

>>>> I don't thi= nk we need discuss this anymore.

>>> 

>>> My memory is th= at the consensus at the time was that G.709 would continue

>> to use the current = generic approach to edge adaptation & G-PIDs, and that

>> (some of) the G.709= authors would submit a draft that would address

>> adaptation in a gen= eric fashion.

>>> 

>>> Do you think th= is characterization is mistaken?  (If so, time to go

>> searching for the o= ld discussion, if not we can move on.)

>>> 

>>> Assuming no, th= en it seems to me that you are going against this

>> discussion & co= nsensus by now introducing a 1:1/bandwidth specific mapping

>> approach. Do you di= sagree?  If not, do you think there's justification to

>> reopen this discuss= ion?

>>> 

>>> Independent of = the mapping approach and in order to ensure this issue is

>> closed and does not= again resurface, I also request (again) that the

>> editors of the draf= t provide (and include in the document) a full list of

>> Payload Type values= (with the 0x value prefix or the values in

>>> decimal) and th= eir corresponding G-PID values.  Also including Encoding

>> Type as you have be= low is a good addition -- great idea!

>>> 

>>> Lou<= /span>

>>> 

>>> On 5/14/2013 1:= 53 AM, Fatai Zhang wrote:

>>>> Hi all,

>>>> Thanks, Ser= gio.

>>>> I would lik= e to double check if everything is OK before we >update the

>> signaling draft.

>>>> I would ass= ume the WG is happy with 1:1 mapping approach and >the new

>> GPIDs listed below = if there is no more comment until this Wed.

>>>> <= /o:p>

>>>> Best Regard= s

>>>> Fatai<= /o:p>

>>>> <= /o:p>

>>>> -----Origin= al Message-----

>>>> From: BELOT= TI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-lucent.com]

>>>> Sent: Monda= y, May 13, 2013 3:45 PM

>>>> To: Fatai Z= hang; Lou Berger

>>>> Cc: Daniele= Ceccarelli; CCAMP;

>> draft-ietf-ccamp-gm= pls-signaling-g709v3@tools.ietf.org;

>> draft-ietf-ccamp-ot= n-g709-info-model@tools.ietf.org

>>>> Subject: R:= Closing G.709 open issues

>>>> Hi Fatai,

>>>> I agree wit= h you, for both point 1 and 2.

>>>> Best Regard= s

>>>> Sergio=

>>>> Belotti Ser= gio-  System Architect

>>>> ALCATE-LUCE= NT  Optics Division

>>>> via Trento = 30 Vimercate (MB) - Italy

>>>> phone += 39 (039) 6863033

>>>> -----Messag= gio originale-----

>>>> Da: Fatai Z= hang [mailto:zhangfatai@huawei.com]

>>>> Inviato: lu= ned 13 maggio 2013 5.33

>>>> A: Lou Berg= er

>>>> Cc: Daniele= Ceccarelli; CCAMP;

>> draft-ietf-ccamp-gm= pls-signaling-g709v3@tools.ietf.org;

>> draft-ietf-ccamp-ot= n-g709-info-model@tools.ietf.org

>>>> Oggetto: RE= : Closing G.709 open issues

>>>> Hi Lou,

>>>> I think you= have two major points here.

>>>> (1) Do you = really need 3 G-PID types for an ODU (I thought >TSG was

>> already covered)?

>>>> I think thi= s has been discussed for quite long time before >Vancouver

>> meeting, which was = famous as "penultimate" issue. >Note that this TSG in

>> GPID is different f= rom the *implicit* >TSG in label format.

>>>> I don't thi= nk we need discuss this anymore.

>>>> (2) 'Groupe= d GPID' vs '1:1' mapping (between G.709-2012 and GPIDs

>> defined in this dra= ft)

>>>> We realize = that it is safe to use 1:1 mapping approach to >avoid some

>> potential issues af= ter investigation. We know this >payload types have been

>> defined by G.709 (d= ata plane), so >physically it is better to use 1:1

>> mapping approach. F= or the potential issues I mentioned above, for example,

>> we >cannot use t= he existing 34 to represent 'STM-1' and 'STM-4 ', >because

>> it is impossible to= differentiate which one is 'STM-1' >or 'STM-4'. In

>> addition, from the = concept of payload type, we >know that e.g, FC-100 is

>> different from FC-8= 00, right? So, it >is better to assign different GPIDs

>> to these different = payload >types defined by the data plane.

>>>> Furthermore= , I think it is much cheaper to create new GPIDs >in the

>> control plane than = in the data plane (these payload >types will be carried

>> in the OH).

>>>> <= /o:p>

>>>> Best Regard= s

>>>> Fatai<= /o:p>

>>>> <= /o:p>

>>>> -----Origin= al Message-----

>>>> From: Lou B= erger [mailto:lberger@labn.net]

>>>> Sent: Frida= y, May 10, 2013 8:51 PM

>>>> To: Fatai Z= hang

>>>> Cc: Daniele= Ceccarelli; CCAMP;

>> draft-ietf-ccamp-gm= pls-signaling-g709v3@tools.ietf.org;

>> draft-ietf-ccamp-ot= n-g709-info-model@tools.ietf.org

>>>> Subject: Re= : Closing G.709 open issues

>>>> <= /o:p>

>>>> On 5/9/2013= 9:41 PM, Fatai Zhang wrote:

>>>>> Hi Lou,=

>>>>>&nb= sp;

>>>>> For poi= nt 1), "1" should be dropped and "7" should be >corr= ected to "8"

>> in your proposed te= xt. >> >> Great.

>>>>>>>=  

>>>>> I hesit= ate to make a decision on either approach, I would >like to

>> defer to the WG con= sensus.

>>>>>&nb= sp;

>>>> I believe w= e already have a consensus position.  The question in my mail

>> was do we need to r= evisit it.  I take your response as a no. (thank you!)

>>>>>>>= For point 2), I compared [G.709-2003] and [G.709-2012], and checked

>>>>> the GPI= Ds defined in [RFC4328], I think the following new GPIDs >>>

>> (values could be 59= -79) should be added (besides updating >some GPIDs >>>

>> defined in RFC4328,= like 32,47,49-52):

>>>>>&nb= sp;

>>>> I suggest g= oing through the full PT list and identifying them in the

>> table (as I started= in my last message) so that there is no >confusion in

>> implementations.

>>>> In the list= below it looks like you have moved away from the >'grouped

>> G-PID' approach.&nb= sp; Is there a reason for this change?

>>>> Refer to

>>>>> http://= www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-paramet<= /span>

>>>> ers.xml

>>>> in subseque= nt comments.

>>>>>>>=      Value       G-PID Ty= pe             = LSP Encoding Type

>>>>> &n= bsp;    -----       ----------=              --= ---------------

>>>>> &n= bsp;  59(TBA)     G.709 ODU-1.25G   = ;     G.709 ODUk 60(TBA)     G.709

>> ODU-any  =         G.709 ODUk

>>>> Do you real= ly need 3 G-PID types for an ODU (I thought TSG >was already

>> covered)?

>>>>>>>=     61(TBA)     PCS   &nb= sp;            =     G.709 ODUk (k=3D0)

>>>>> &n= bsp;  62(TBA)     FC-1200    &= nbsp;           G.709 ODU= k (k=3D2e)

>>>> Why not us = existing G-PID 58?

>>>>>>>=     63(TBA)     eOPU2   &= nbsp;           &nbs= p; G.709 ODUk (k=3D2)

>>>>>>>=     64(TBA)     STM-1   &= nbsp;           &nbs= p;  G.709 ODUk (k=3D0)

>>>>> &n= bsp;  65(TBA)     STM-4    &nb= sp;             = ;G.709 ODUk (k=3D0)

>>>> Why not us = existing G-PID 34?

>>>>>>>=     66(TBA)     FC-100   =             &nb= sp; G.709 ODUk (k=3D0)

>>>>> &n= bsp;  67(TBA)     FC-200    &n= bsp;            G.70= 9 ODUk (k=3D1)

>>>>> &n= bsp;  68(TBA)     FC-400    &n= bsp;            G.70= 9 ODUflex

>>>>> &n= bsp;  69(TBA)     FC-800    &n= bsp;            G.70= 9 ODUflex

>>>> Why not us = existing G-PID 58?

>>>>>>>=     70(TBA)     IB SDR   =             &nb= sp; G.709 ODUflex

>>>>> &n= bsp;  71(TBA)     IB DDR    &n= bsp;            G.70= 9 ODUflex

>>>>> &n= bsp;  72(TBA)     IB QDR    &n= bsp;            G.70= 9 ODUflex

>>>> Can these b= e one value with rate implying SDR/DDR/QDR?

>>>>>>>=     73(TBA)     SDIa   &n= bsp;            = ;   G.709 ODUk (k=3D0)

>>>>> &n= bsp;  74(TBA)     SDIb    &nbs= p;            &= nbsp; G.709 ODUk (k=3D1)

>>>>> &n= bsp;  75(TBA)     SDIc    &nbs= p;            &= nbsp; G.709 ODUk (k=3D1)

>>>>> &n= bsp;  76(TBA)     SDId    &nbs= p;            &= nbsp; G.709 ODUflex

>>>>> &n= bsp;  77(TBA)     SDIe    &nbs= p;            &= nbsp; G.709 ODUflex

>>>> Can these b= e one value with rate implying a-e?

>>>>>>>=     78(TBA)     SB/ESCON  &nbs= p;           G.709 ODUk (= k=3D0)

>>>> Why not us = existing G-PID 56?

>>>>>>>=     79(TBA)     DVB_ASI   = ;             G= .709 ODUk (k=3D0)

>>>>>&nb= sp;

>>>>>&nb= sp;

>>>>>&nb= sp;

>>>>>&nb= sp;

>>>> Thanks,

>>>> Lou

>>>> <= /o:p>

>>>> <= /o:p>

>>>> <= /o:p>

>>> 

>

>

>

>

>

>

--_000_F82A4B6D50F9464B8EBA55651F541CF84317D2BASZXEML552MBXchi_-- --_004_F82A4B6D50F9464B8EBA55651F541CF84317D2BASZXEML552MBXchi_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="GPIDs for OTN signaling draft.docx" Content-Description: GPIDs for OTN signaling draft.docx Content-Disposition: attachment; filename="GPIDs for OTN signaling draft.docx"; size=67756; creation-date="Fri, 17 May 2013 03:10:11 GMT"; modification-date="Fri, 17 May 2013 07:43:48 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQCMimiR9gEAAOIKAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADE Vstu2zAQvBfoPwi8FhadFCiKwnIOfRzbAHWBXmlyZTMRHyDXSfz3XUmRGtiO5JoQehEgCDs7nJld cXHzZKrsAULUzhbsKp+zDKx0SttNwX6tvs0+siyisEpUzkLB9hDZzfLtm8Vq7yFmVG1jwbaI/hPn UW7BiJg7D5a+lC4YgfQaNtwLeS82wK/n8w9cOotgcYY1BlsufhCBoBVktyLgd2GoD390QfHSObQO IeYEx7LPbV3dumDC+0pLgUScP1h10HTmylJLUE7uDLXKazgfnIQY6WimynvodzU0P01C7iI689tU XCOY2+B8vEqm0oPWeBBQQ+w4fIFS7CrMvj6RPq0ldx42ByfXplay+UC8T9QEqOJBzYhaz/bkVNko GrfaD7EatmNA0cbW3pVhmAtc7ZGN0LZT9dV42Z1ZQ6A8JHt6FK8eepRExH01RcBb3NH2YNVEE9Yh D1Egv5qp4pTPZBOgnhoFakaDfjBYr0YgAiIFYIIF0yEPHb9fchCuk49/lMF6xUE4s//7/9G/t7/d ickUWph/8b/VKH2pXyo+0h8TePNMJ9HAjPq9BaEmyVsLfGb/CfJ2Zv+SbhErsa4gOW4nTH+GHhXh EdY/J1s9L8BHibSipWfvSItxN/5OvwsXmNHdWSRVnxh53txQl38AAAD//wMAUEsDBBQABgAIAAAA IQCZVX4FBAEAAOECAAALAAgCX3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArJLPSsNAEMbvgu+wzL2ZtIqINOlF hN5E4gMMu9MkmP3D7lTbt3ctiAZq0oPHnfnmm9987HpzsIN655h67ypYFiUodtqb3rUVvDZPi3tQ ScgZGrzjCo6cYFNfX61feCDJQ6nrQ1LZxaUKOpHwgJh0x5ZS4QO73Nn5aEnyM7YYSL9Ry7gqyzuM vz2gHnmqrakgbs0NqOYY8uZ5b7/b9Zofvd5bdnJmBfJB2Bk2ixAzW5Q+X6Maii1LBcbr51xOSCEU GRvwPNHqcqK/r0XLQoaEUPvI0zxfiimg5eVA8xGNFT/pfPhoMEd0ynaK5vY/afQ+ibcz8Zw030g4 +pj1JwAAAP//AwBQSwMEFAAGAAgAAAAhAG8BpR95AQAAUggAABwACAF3b3JkL19yZWxzL2RvY3Vt ZW50LnhtbC5yZWxzIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArFbLTsMwELwj 8Q+R78R1C+Whpr0gpF6hSFzdZPMQiR3ZW6B/z9KqadpG5rKXSDtRdiazs05mi5+mjr7A+cqaRKh4 JCIwqc0qUyTiffVy8yAij9pkurYGErEFLxbz66vZK9Qa6SFfVq2PqIvxiSgR2ycpfVpCo31sWzB0 J7eu0UilK2Sr009dgByPRlPp+j3E/KRntMwS4ZYZ8a+2LTH/39vmeZXCs003DRgcoJAl6AwcddSu AKSeu1rFJFLIYX414RSQW4t9Aft6EhLAyu9xW9MEOwP2dYj+nvP1wWSGDOgJOCAhCWrMqWE4A8ER sPKbTbMGR/t1nEIHBV3gNCHdeLTNB8W+i0Icyw6VFUITXIspp5q/LTjLRQcFLVHcKi53cxwScMfJ /w3rN0CkZPT2oweGhChWJUjHNxyTsSvl7hrMhKKPB99ZPXxUBgXccvL7i1kckNAgHjklDB9VwUQq Vg9ya3Cl13UvDB10cEGe/AnMfwEAAP//AwBQSwMEFAAGAAgAAAAhAAWyrciCHwAAKMIBABEAAAB3 b3JkL2RvY3VtZW50LnhtbOxd6W7jyHb+HyDvQOiXGxjbJLV7rnWhtbuBnm7Hdk8CXFxc0BLd1jRN CiS9zSvkZ14gT5A3yJ88S/IeOVUsSnWkIlmkqM2qGWA01kIWT53lO2v95a+vj472bPvB1HMvK8aZ XtFsd+xNpu6Py8r329Fpq6IFoeVOLMdz7cvKmx1U/tr553/6y8vFxBs/PdpuqMEl3ODiGT59CMPZ xfl5MH6wH63gzJvZLnx47/mPVgh/+j/OHy3/59PsdOw9zqxwejd1puHbuanrjQq7jHdZefLdC3aJ 08fp2PcC7z4kP7nw7u+nY5u9xL/wZe4b/XLAlkzveO7bDqzBc4OH6SyIr/ZY9GrwiA/xRZ7THuL5 0Ym/9zKTudvEt15gPx6daNkvnj+Z+d7YDgJ4dxB9OL+ioafdmxGQXGL+C5kl4HvGK3m0pu78MoQ7 lvZ/vnlnsHnn0b3PyaUWDwK06AAv3XmTN/I6014ugBcn15cVXW+39VbVrMRvXcFGr7w5sO+tJydc /eSKe4te+conL3+M4XLPlnNZGQPr2n7lnLzrRx/6I88NA/jCw9SFS9pWEHaDqRV9545+07HcH/CF +KPLyp8Pp/2v5Bvn7DLwOosud+d5Pwm/34SWH8KPphNYE3kc13oEYv3j2r6vtdoG/KvrbB3wIX18 9KyFVkif8d4/7X8id0xZ78sFleCLYGaNYVUz3w5s/9mudD6eXn0eBBp5sDB6PLqQeImEvv12tWm0 6A7mJmGeBXaeg6Rl7AOllmkUb/zQnQC1om2P+CwmXtKqEZNxFOL4i+zGlfXmeNZEC99m9jJhNs4t nf3ei4l9P3XtiTZ1tVvrzrE1o37a2jqRiDVbFSnNu9c+njX1NloP0Rhk17KV32jU6BmDuUZcVX70 MkyZSeg0eW0WrzG8c8g94CW6PPzPvwJTvwB20OutOlkaYcrLyuSV6U2xxoXf9cAQAPCgl/PIs1N+ JzbNscl1gj8vKzX6P5Fmoqpz7Dke2AHrKfQilenY90S3FvrtnReG3mPRX/vTHw+Fbz11wcrZn4re O/r578V+ThQ6Jv+d88V6857I00S7dz99tScRgeGrX8CQxbfS4R/yQXSRORN89KcTspM/4LXvOfBt whJGjRk2/LbZbETXxm/X623B22ajXRO8XW0b9CLROuLbhz7ceQ4gukOjVTUIC3FGtWU2q1XKV+TN Wwoqqn192DOpHQuZIRtbbngzA3hKFXfof7L57W7pRrQmEXeTJbGrhGPK3mNGp3EsK4QwsCwkKuRn 7ItIE0g8xTWnCfDXKQxqtM0+0JYshUGT2U34BqqRyQ3Vkw+2xXb8p23PvoAODSKbFa39Lv4y29G7 PvkY1kyfFF7ZlSnKkgIDwgu+XGTrJKBTBE6QFoWVwBVXN5o8NVtP+jMACvXZI9EHA51MtyTaQfE+ Ek6Gu25pH+v1emtkbGIfZci+9T3+cnOlDZkziraarERic4g+2d7mbE7I9nFzxPgmxqW3AAEIAEO7 VoKAhp1P9qsG4YkV1BuLPvFKqoZuVntUTDauiMR00DgQmoT3snQLtXvbY98j0y1fvRDzkJxOoahj eVPAinad6Q8X3qcwdBFZoHsc2c+STfrebFcseJFHy8BVDpsbdj6TOAyEHUIajEtSGUSwW71aQ+/v VLDvfXAYMkSa7DqFQRJotN6rNUfUTK2BRs0mA867QqP4KXg0OmyaRrdKzDB5Pnk0GtqvYYSwCRr9 Cn9RMIqhqehx52AvG0cSkY+Ek+6WjK3IvigBp18hVI74WE65GGujyeR9EHgFUipkm/sgSaW1YV0K lbp6I/LMjohb9VfEqxxMIzoXM851pOYZBTk1LycYuoFuJbfh6wOh5A0XqKfyxIIplGzSiBVR9u+o rkEUhc3jNiU1nyF3eS/UXNue2BN0G7mNE4Il+Kl8lCN54zBbUruy243DOKiogAxfZ7Y/JVlVy9Ee rdkMoqHaCQGrWvVD8hYQom4XcbSau41/JXNGc9Bs1IZ7jzgwv9R0vanXK5zsyolnTZRJoCJGLpUU fdwgzhBQn3u25OijFM4oolDLoTNF/Nq3wfefv0ToX/vWf0iWx2TSK/DC8XgJ9mmb4MUssOHrgBcu qN/o19q1JlJquxWrcnfRwLZtCYIynVLuLWl1Ax+nux71a1WzcKZYSl+Lo4W/4jhpBK7AN41VF4Hh mAEwDI+/dzz8Yn7Qvs8mVhil+cOHaaBBkdR9eFZAQreMUncrtjGrrOXGibm4G7y54wffc72nQOv3 rmP4+osW2DbmcOylrCE5Y8d6ClYvXspTdowmZqcCq+6kmIztY/b9jRIavapZh0pTIPE+RwkxX3GS LA1MARh26noBLbXJ2KCA+tyzvQPMXoTeCqiXi7e2CdSrBTZ8HaCOrGmsJI4HjU2mUEZXgOQKeXEi tgYK6k1DTYEvXIVPDO1ega/9DZgyW38c4KuawhTJUbsNBkwF1H8P4Otm8GkeKYWoaQHrYGwQgTWM hmnOC4OPpCphmwisVmDDN4nARi1zYHaRg7lbKeMsfwlRcIXAaKNeajeeHwNzhNa5fVgDgXVvf1Ph LkBcKY6XCnctOlUFNl8f6aNBjSaA1wy47GtRXL2ITcgV9sJkZTmSpTc5rxx/QkEAe4soBbYLKdWH L9OJ99KHjmGf9jvR0l/WHBNad1Ffm3UHWicqCnZsyycGaOYFl5Vm3NME3xR/w4C+4KjEIvkr9VYr 6ytt6MmLmlriNXnQ7X/veC9XT+44Kqoknb+kzgQaYGzo1YfmPfYYC1YiXXbsVlCKSaudaes/e7hF Ox6LhAZ/xk9lmtHvsrUryXuxckz4MQkE4y3kVHWRyxOPcJHG105gpoEGKBVnHoW5N1xrxBaVXICC v57AV4IGrM2UQERPRLQva0UjZIwrsMJ5Q9oGwXazrzca+1+Qw7FXCYhsm2C7vmmwzYyTUCrjN9MV a3nmjSmYXOqk3K1lcxEmiz5zVjqgvUzDBy188bSfU3cS0Gbv0VWgnaD9AdUW0yxCopzRkX44osyG 4YPtu3ao/dbtayf3PgyVmGgfR1dYo0ncbn12F2eEcdJXXrViw8x3ExyialVRbk78ssUWOFvMTcDZ yscCsU+B0cTKS5cB69XesE8AKUFaURu8Xm30G03qhMQN7Olt8OYGotoEnXCjIdaZ0UBRz/xa9C/p ZrxqXV8U3PE6qN/Wm0NciifV+ruAdwtYvegUhG2IlpYtIUSRCnFyK1ozJ27ra/ZSe5n2fWsF5iVn U4Foa+P9Iq8Fu9b3nXDrQ/w0wq1AmFyMDmRnohV2CqBy7l7w+waCcnI7Koxr7/uOVnswa6IXmwfq xLK3iHqRCVHtpz4TYwtosGFtThoJC6BN5riPFOIaPaPfpMNbuAgFxyTssUvRvGFWfbIcAwoR6L4z 4Lq6mJAmy0qGnd+nfvgErVYQxhtDObFLS4oD6OW3nKhulVWYGi3WhVXH3hXaAPhju/DL0Gs0uice a0iXE5Egjv3Ef6WNIYLBWw9kbB2OWvJzt+DD+6kDIxT7jUEb5tHA3+CKPtoj+ibBOXRo4/y9WzpN sVqNA5HSQ44YHmUYlQdh9WajXpsPQiuSwBUZnLmlWAOEcRi6PFXQwH2zyyqpqnfNOTGuo6jCRtZx ctvrpggA0SnEPKyGF0UFFAfBaM1hrb6E9kuEhNxGFtg1EHDGYkkuMxk1uGzNYHSsdz/0SRAqGlsV zGzHoTNKo0g9+YSzbbkYiVtSh3TLLVlS8b1hTGapdxbbeO3k5yWuvOaoTyx7a1ivD+dF6JsUo1+q v2AvnlvJenzQKSSdouD/YUjn2qkFkRkAJhZDh8KiUMDv4O4FfkcTCRJZYLYnmeB3HIB1b+jVFowV ZnqIWvecSpfpxVLtePbFQKN2PqOdWk+wZQa/kXsG2p1NErhcSmLRE6eduPaLNuMmBvPf+xtNiZ6a umH+vYjuSPAtDoDJNuZgIMm96t/QeXVk6rkW+pYLyXafDM2fZ2/YlIcLxDeRhIOYx7aYGCi8Ymyg 4u9xaTj8dSpFBgyb6nalq0zcp8fIY5g6z2SkK1/iAJ99nrsJ1XgUK/uFjAYNOwaMku11b4an/waz AkNP+3b1Xee9rkCDFrzmmUF98uh/zzAQPgoy1fSPlErXcypVBVSqLahUO0YqATMtk6kmIFN9Qaa6 kEzAUsSJIS+yqZSRXh00liYK80qAGaNdpFIOQA8fmyuPGxA4gECji8qVj+JIG4gZ7c6V35J7Hpbq cicsGtxohFQ4Bl7Tdb008dDEtCuHytEtIeksA9OY8UrJZ8BV2JcKJdh4S9nR8fwVskDl6K7O6o9r CWQ2MOyU2h1yEHEhgeuTK4AgR9dR/9QwdX0Oy00bFyjFuaPmWesMW33E1/CHNNSsl1K1s4FBIAfB FscGNXE7DmdPFdQEmYtTlu8KauYy1+JESdQksQTyxJmb48gamUUCo8L25YPQklsu5uLwXy7mLVLM xd0LsGob8TiyyVEQiPx3qWTieJMqcphIYU0I1G8Aa3LV7xHeHL5CuRLM5SZRczNO7/ABz//5TwiZ QyiYFS41UpTY9hHoRurGVbAzO0UpI8XZalguMenA+bnXhEl9e3Jl/bB7vm39pMd4hJ1GYgGEwqYK mwIFFDYFUY3jamJi0IqmFLWeCGIUNsUHgJejFLn9Wh+bdhU2lTjrUsVBibVkXo1cCcgGsOnN7W+n Rhz6nEdDUSkHq+RIZmoQHhUEVaXzcftpWRAUgCaejqCCoKRxYyuMtrt8ezb3cLZajK1UELQCR3IG tv9sVzoKaBIz+z4T7r1km5zoP6ggKGdGVqpeVMI9f8W+jAcWdgjQrB0c0FSxTtJNVlaPpgynZNt/ uQAmoEfc8M+JvQpTgnlQKXSFHjOhtEKP7xc99hV6VGFK2idTcqfaBsKUpFwTqjXjU5WFLWcqTlmh s3whlqxGfJTSBi6NNHGLt0KaKk4Zze1OzwGrOOVSnHLpKGHiLmZ3kKiE+N4nxAcKaSqkeThIk/QF LSNNgy/PjJDmXrUFqUBlmYFKQHBR7fh+FWVCTBP3WCqkqZDmQSDNe8d+RSAAoJ1wlh2bJ6egH5nU m9w8nDg1dN+Gnw3Rrsttq0pRc3pdpaihfGMrPeHidBBEHuFME4wHEU8naTKp/koY+3H1Pa9yTOeO ZaCa0ikH4qgKN7dST3ds3euY6TiGVal3lXoHCoh17c4Donk1sRyeURHKvY9QjpBJl9tWBVM5va5g 6s5hakvBVGjfFwxZqvb1Yc+kk3N3dzQawdrSh2fgp+APzxgOqka/gcZrl1DbDoJcIN5Z7mFlddF4 YEq16FgK+cMpcpEaEzSD1LkqW8Qxmjmp51P5bGi17wZT67Lyf//17//73/+x9pnL7JFE21P0XsC8 3AHMBYylEAPl2qhkmdjy0Bt2OxF5H+hpOTGR2Zk5cRFAkcZi9tCU92HmdgHCC1FKEuEbpmka8+Oe eWHAn0QF4dGXydpkzhRLOY1958pH7I4YH+hxwfzIfXZa8K/4YBYgJxQqwH/iNl7i5eKY1XUEkJKZ eF0CkzVEOpwmWhlJ50pmlTNli5vMD9r32YQerjV1tcXZBGcFmFF44kASM+YkIP56iW0sSAZ701AL QhiG8hidGO2NQzjFOZw+kjMcWNJ4OQLXKGtYOeaeoue+bmSCpPS5rxS7wEEKYxuEhOAY/nSyKJfF Xask3sBGvqx2lrkpz5UllrMbstJZT6lCIIiTWo7lQWiG+Egvju4vF2ln925wD/FO8RYIf5JfvhUc I/wQnx4oPjZqHzgAKzmeA44G5xXxhIQ4j+z4/Aztncl08o4KQE8uF2tjoKfkUYj7vQs7QU7eU6hl gSc6BrGxrfnbd86VP3ylBvPO4aQm9Aiup+cnuZ5rE8wS/MnASwqQAQtu34fFfomNb767+tMfDwVv O3Wh2df+VGzN0Y9/L/JjgvI4kkd/zjeDuTK7OIIHyS3HBwGgfWfOCVlwCHNC3t9iXsj7a8QN+X5M sTcnB2pEZy6cD4JQ9CRWWfDfxAEhuGF804NOsyupOyypU8OiuNnk2YE30KvsS/TQp63WHCjROjDR OpJDko0iYSwZl1eBtvlBr2PHtvzliCsAhl03i697YjTo0zjzEcOflWoUpnCzARx4IuoY6GjOOx85 UmK092K0sSgOB24S6jY/97SbwbUW57+iMcIoPQgiKmz32W2RPByygQuViSqZd5wT/5fmUkPkVmE6 X4vyuquZORVbUrGl8G0GOc/JqxUV+CgoflhQ/MhaOJo4CaViS55/Gc1XouiIj+3nC6uul4aDfeDj +/luTSwaj+oOIKKrYksc/FKxJXDwUlNuKlliEA9/NfEQvzmw760nJyT5gS2XUxTmY315ckA2HOfu FXYMfJQuwvhEIQpLpFRsCTgmtTTvIM5D3UZsqfSZ8chGq8iLirxAaXly5GUAkRc0rUoFXqqN+Cwi KCuZ15FwFSZAT1XUI1PCpIp6kurUVVHPts6iOrbAC06FqsCLCrwQl25+Xoc6AY4AnLiCRty5d1yD RJS/cFiZhKMJvOBz4lXgZVGX/+7j9irwwlpG8u20Sg61qvIRbFyKkb8llGgk1jMfx8dXKseSAy// ogIv/TjZoCpeloPlLxeq4kVVvCxKBkDXIJx+ALn3Ywu84DyhCryowIsKvFxWEqZZ7Wng5adU9oud MsCJ+Aruy1VrIyZG2YenIvvBJbDyuhiqdq2ylaHfRxPnqSOhU3EeFecZGXTcavZcQCkXvLPJcSxK kaoCG1Jg07kZfF5qYYKzOfRomB90CjW3NcVPlayoyImKnKjICUsgjG03tP2oZ4w5JdltzDJmNdvD kZ5DgxN9nFul5tCAaVH+1pb8rWGtPmzGKYn86SDxhNByRAmusuclK/sWOSnzMHAVOVEVMrSvPzPd m20UOUkuMtEftyY1VOTEego9hm6OqrNVVcioChkTJZhu6ekh1So7N0T+uCCmU+IaFq7Hc4cVMifG Wa1VPzfOdN34gM/LWHMazMe7aYj0ZtL1JNI8Yec8gOE1n3ELFQR+DC7wgyvyCSBUQ2KS+2LQgIJ8 s4tV4EcFflTg54ACPzjzpwI/qmQGIRrVq0Rwigr8kOMNGapNJwYpmVGBn4UJBOY5Kqf4aEpmmsiB QS4FKRRWM2nAmSWnrGSdrQGUQ8HdAyirVoEfFfh5z4EfGvdRAR+YsIYPPlM9UqpHCoxVfAKjUaPH n6qAzwLtHqAxP6oeKQdOqr+23Ynt25Mr64fdg3OQf0aHBXSaOJWpQkEqFKRCQYfWPaXOosp1rKOK zbTNfr0t2eqxpfK69YtyWio2o4pyyAjt/CWkJJCXOVFEtTN5DkZHx6VId1mUY561m/reF+WI+6lF lTpIVSfVAalTptQJ5hUabUk9PEINO04u6lI9LNvpYTmqeFLYaeI8qIoaYVykpG47UqdOmeLaUvK1 wHwbfFdRIxU1io7cEHQgHE1FT8pJsqqiJ4eAHGASUFX0qIqe91zRQ4NG+1vRo6JFOKJ4LXcmOcN5 Y8sNb2bONIwS+f4nm684NlvNqDn3jzEY92cLDv1ZDCQhqjqu5xaXrBriKpcDqNI8Nke8dXLb635A 4VSSzJg3OiZiGMNs0iLdpUKmA9hi5fWt4/Xt27wQvRDz1iF9DYrtAJm3rzcaQ7L2eaay8S6z8d0C Oinh9N4D0EkH6UocAF0xQtpQYl8MRG96/W9fz4c38N+VKQNovCRG2Mj6UqRFm4L8OMZCRqvhpyoT 91WhOpkCQoX7dCm9+mBbk4hiP2179tV+DWO8zAjJgPLd0tvbm+WX/85gFzvNtgKGIGmtVr02GuxX pZtY3ez87EMFDMFJ7jcGbRiCDcK+9YM7CwLDYgoMDBNVbMRaZRW+MQ3ojzw3DIAyD3TeEX++BBx/ htRjfHWiiPRXBASXUsVCS7jq3iRf3uihy5PnyfZ9Dxdn6v1ad9Qj/Dl3H+r1eitzbnsmlyzwAkle RxZRaPrivc3BOcm7V/KA+HcMaPdzA8WmbPB77x/dm9XZXBtBzb1ac0RjAUQgVns1GQ/vIlqKGtzv vDD0HmMtiY9+qRF5TilxA1HjrkX/inQ2KQ8kj32d7FQg8lxzI+aqvXq3Pj+zkXpWQx3+qUuDJUba NZDwaNg02i16Q+mLEZtSw+VHRBVlK/2EgCdH2fRTPDe4S4wO8W7yu9QF+EpzVHN9X+1WeyM9Y5fK Uxcyw8QTbcHqBmNbIHNx2HCxmikFMZe0wg7U06wHoEtaiJhUKSEKoluEY0sMcYx1H+SlnqjVBGUr 7C3yjNnn2oibnRhYluHWRFHglsF0XSqgztaqRBEWANeMdoQcuXSuqZcHtLfMQ4Ou2TWrMWjmjSD+ hBpBTg5l2EWahhxjcLRfnwfEAr86utWPrQvBCsz4l7qQzsfTq88DxCTAYvxdzX6z3x3y5n79x+8E aXfcxHOKCa5N7Pupa0+0qatdj/q1qonbEYEUpVJbvIozkaIHvcfvgtDlTtao70BEOuYH7ftsYoXR 9oQP00Cb+NZ9eIZ4Rw5GVtuGKG++ZZWWcxPx17el52KuY3UtkdHmpEDKxokZHeCW9vjkhNOZY79q Qeg/jcMn39aCp9nM88Op+wNLAsiA73n3Q58opChrHMxsx0luMStqJ78Nbr//sR4ULHhrMaU0z3Xe oqHYY8d6CmzNaGsn3d+u6AcpyXcQh5DqrBApccxK12hv2YYX9MLrjcZx5q765Pwb6l7OnTz2FhGW ZBSyJ07earg21azfAZfQgjSWYJPSAp06rtNeQha1VrVmzsOijCm3sq7zRhFcnBCLOID45bvj1ULs KFa1pQQkVrm20ApJQAKhG05iChyavZzhkXGFiYOayxDKAbCEuMQByI4gODGsVtvt0brBPOaE5mcU zinFYG2VC3PodLgqW1GhCMXqvfM/GOE900ACIMddh5sahEqHZn/LKCIHU8hojM2wo8ydCb8sDTDn FCYJmdS6TV2fR+K3CTG6vo0YeWlh2CJvcWFiI6jd2cT74sIhC39bO3HtF21mvTmeNdGIG8Z/72/U fp6aumH+Hfsl3BNv0Xb9iqgeqY+lWAqWOUz7WKFy2Rz8deqGs7fSgX4IZWkoJZ+NmcsSpew7geiI OQGiLvW2du/5y664H5MmaTOlbtqJ4FbZOEfu3qfGmVn/iBhkXSaVurGY0r9qDX3ThN6XZ9Vgw08t 9w2tR862J4TuDgA54qALVRyHHSEohOjEzL/5UGBZgJSEBn+ehcsZC3FkUuIQPAayS6SltqqsxatL jpseEbEsd7Js2nZJrTWjzmVt3Eqs+SPEmsfWzLpz7A/ayVcvtLUmxndIfcMfa8Wdq3192DOpSx13 uWZUfzXbpcedyUOMSyjSqpktEx+NLtXVsACMi7rORf8vIJVoadmQg+wMqw/mEjepbl/2RYmz9dVz sVeDeIBQj9wvpuFi/L6oa7UkYguMrFRtbTqxYwpKPp+o6GZzz1cCM8XPtwJ/uSxW2KnjEwfliCGM xZREDMgXLEtWrs3mHpsTDEneR9gVCMddoQTR8kLNte2JPUG3kSO5ECKXRPJ15YsjOXYgEaeBfdGs Z2vqEHvDzI25V+ZmA6MZStohgVCUoCGUuZnXp/O1Z+uKg7hUMRYS8ipRE/1OzU0Dn2oiRwxlbiq4 qUvOmilzs9/m5ti8m1gDlo6rlMsidsneqQ1p6aetUQEIrcyIMiPgesRRAU4dpXgt13Zg+89Qnzz2 JnZAczkQSpz5Uzu0/DeNlG1GkbOacmVox6Oo7pRH15txZbjNLNdnV7blqGzLCPfJKP8EIsLE1EaR sHJF66j9E3HK9Ov3L1+00A5CLZj+cC0nnm8VpW4Q5mF7klDiwToKln+RYuiMJm66ia/fwQFieDvl ImcplX3ARSp9BJ0xtM1vNchdQjxPGcHseSsx+lNBOpBkMqEC4TVq6zujIdIbyggqI0iUVtE0XLK9 EBvBq+vezUEbQTNZfLZvBNvl9+6Rh9jbGgplBJURlDPy6VB2pEKMcTUSFAUhjcZcA1arpAojwjco aGC9s7ekuiHmP04XJRtBqLgqpTBC2GrLKjDY3Un/9/8LAAAA///MVVtv0zAU/iuT39Hs3F2RSaQw 4AEUrUg8u46TBnlJ5Jyu6349x3aqdWpXaAGJpzjnfj4ff4fScE4/FAG5ebuZgSmN/UrRwWLQLVx7 6SfVNiu42swehM5JwBPiFD/kTiRVB8pY6fVzFJDOW/qYIL+j9SYnjEWU4BG2g8pJ9Sh2bpPhgDoz ttVdTiiNsjAKCmvuRO9VLdYaDjWlFSU8mMfcdTL4pMMCtlqhtyv8m1hqBeoRXi8f83hPLboG/ZQY 4d3Yipw8rd7Mv06lOhvs1GWxX9/31O/xroM0ubTr0tju4iJKb/lvQhHHcXbL/giKM/uLEXkE7JJb vaC/v3DV5/UXJDy6tL/TU3vmVf2j+Qw5+2/n8+hNoRCQrOxnqe2Te8EbRcGy47wxaRyBjUpCaXbk Yh/ZS78F6q2Uhsk8Sd1rWilRKXOnamVUJy21+IlXD6ojV2bWVjkxn6vMU8xr1pXnsT0H7h3qvkci /WV4Rk+bH8Zn7HRFdWtG2KuHBaczHNiH3n5oFk8IiuN5Tt1IrZDzkyycIBmaL8JCDv2A8hDzWPzt fsHfjLrVsOwB+nv8j/yq0Kre03pQc5KmjnE8ZDnh3IVq1oAI4q35emSvR0wwDkLitomC2IurXn40 bWXrcGtIt50abSX2ULYgsWhbm99ofk7csC37ausOGGF9j2vv5icAAAD//wMAUEsDBBQABgAIAAAA IQDPiRwqUwEAAP8CAAAQAAAAd29yZC9mb290ZXIzLnhtbJxSy27DIBC8V+o/WNwTSCpFkVUnUhT1 1EPVxwdQG2JUYBFgu/n7Ln71cYiiXlixw8zssnu//zQ6a4UPCmxBVktGMmFLqJQ9FeTt9WGxJVmI 3FZcgxUFOYtA9rvbm/sul9FnyLYhbxGoY3Q5paGsheFhCU5YBCV4wyNe/Yka7j8atyjBOB7Vu9Iq numasQ0ZZaAgjbf5KLEwqvQQQMZEyUFKVYoxTAx/je/APELZGGFj70i90FgD2FArFyY18181bLGe RNpLTbRGT+86d41b5XmHozB6KLsDXzkPpQgBs8cBnBVX7JL3+IFJYmZcU8Jvz6kSw5WdZdJi/Jn/ PLwlDo8O3jRJfTeCf7HDNXJZl+P6Vc8FYexwWG3XBzKljkLyRscfSM948n14iWct8GnLdUE4JzRl la0wJZUP8VGlwu42LCEUnRIvxf7E9d19AQAA//8DAFBLAwQUAAYACAAAACEA8axpGm4DAADxCQAA EAAAAHdvcmQvZm9vdGVyMi54bWy8Vs9P1EAUvpv4PzQ9eDAu/bEsC5VdXWQhJqwSfsQLl9JO2dG2 U2dmt643YjR6EE/e5IAmJhoM8WBi9MA/g0v8L3wz0xaKiItGOTCd6Xvf99733pvu9LUHUaj1EWWY xA3dGjN1DcUe8XG80dBXV+Yqk7rGuBv7bkhi1NAHiOnXmhcvTKdOwKkG3jFz+vCiy3niGAbzuihy 2RhJUAwvA0Ijl8OWbhiRS+/1kopHosTleB2HmA8M2zQn9AyGNPQejZ0MohJhjxJGAi5cHBIE2EPZ knvQUXiV5yzxehGKuWQ0KAohBhKzLk5Yjhb9KRqk2M1B+mcl0Y/C3C5NRmHzqZtCKaJQhZ0S6ieU eIgxOJ1VLwtEyzyLOxNQQBQeo4RQ5swjiVwcFzCiMU7UvyjeGBTPUNyGgDpKBLRoQhvx9TBbFmn2 cEdLnbSh10wT2hEsBgkQJB7XjcxgBoCgZ+WOJGDSd8OGLjQJkfBgDxv6uHxIXA98JYxHQgIN4/Y4 EUCGpD6OtB4uEHIvRzOttnlkV8Q2T7EveDdgvUFCsIZIqyJSGVzp2J6yrdOOJ0x5rCLIAWGaUgfm 0F+CeM2ZGWvSnlECeTJPLwvBy9Sx6hM/qyMgM0Mhy0m4/GgWBW4v5IKo2ho37SlJlCiGZJkPQgSm UlTXVRng2IejAFPGF7AoeBXolYyZXxD6yzhKpCuOGQettZWbnba2dl27dL9H+NUB/FU6FV/tNEla yrpmj9fqc+pcBROTRUpIoIhoJkHTNq1qpVax6rKKspZU/i9ikLtEVTnT7xcqWrJRSj12fhVvWKY1 Zf9ORcDNtIJooToqHTpHYs5A3C6OoSTIZbzFsJQdHIqcvz3fOvj85WB/+9vek4P9neHmXil5sDw/ 5pW/hxi+en/49cVw6+lw+9Hh283hh9fDZ++GL9+UkEXiI9SiZtfF0P6XWqTOrzo6de56efdTvNGV 185fle5wd7ckB8zRz7Oy2JpvywYqTcRktWaO19X5WRNhlQgg2oJBdsX5W+P7zqcSZNZfXHyrHaau 1YQihmgf6c0r2mnG52zwxx9PgBQ5QDnyG+XWakcotaxpa5e1FnXXsScfO+2l+fbc7aVOa+WUi2VU GaulCP6BjKVJgA2HqRWL+giOeGcf+ziccWcLKtEyBSX8YGv+AAAA//8DAFBLAwQUAAYACAAAACEA bHsjCCQFAAC/EQAAEAAAAHdvcmQvaGVhZGVyMi54bWzsWM1uGzcQvhfoOyz2bktybEdeRA5sOXYC 2Klhx83RoLiUlgiXXJDUj/MACXoo0FMvPRU95Niee+jbpH6NzvBnJVmurFi5tQdrZ0nOzDf/XD97 PilFMmLacCU7aWuzmSZMUpVzOeikV2+ON9ppYiyRORFKsk56w0z6fP/bb56NsyLXCXBLk41go7C2 yhoNQwtWErOpKiZhs690SSy86kGjJPrdsNqgqqyI5T0uuL1pbDWbu2kQozrpUMssiNgoOdXKqL5F lkz1+5yy8IgcehW9nvNI0WHJpHUaG5oJwKCkKXhlorTysdLAxCIKGS0zYlSKeG5craIt12QMoSiF hz1WOq+0oswYWD3ym7XEVnOZ7uBAFFFzrAJhXmdEUhIuazGYGHfiXwdvE4LX8LobKGpqCPhiH9LI 9kR4nOtAvE3G2biT7jSbkI5w4qYCBRW1aSMcOARBkLP41lPWqhJOjYjopOgWwZDJvO+k246oCAV2 J4kqoSBnyNAqlNVw2meEAZYuE+KMOCSC9W1A8nSKI58Qj0PzQfHv+172jDSQfarUu4gUbGtOMdSm n2ieo1kDeHaV8Orb21te5dzqTntv+57l1m7bLXsAUZ7VIAqqPL8AVzQPD1vtrUPvfu11UyLtZQU1 6X2sX7JgXnExFOA/NiEQgIj+adshQh2B31IXGxosodMYTl0XQohc4Vx1D6q4dMT6ZCgs4u22mq29 LYe38gqqS3sjWIRD2iEkflMfK2kNbBJDOe+kR8oOS4TBiLEHhpOZpeJAmvqIzwlnEYAMqlwuBCvX kTzOpDrXSvWdhwWRgwifyY2ry3l874uN7uuQH0F36AXg5irjUnDJkpwb+8blNlKHNXVaUxhu9FuV sYmF9pfQCdRFa6+FpUVvahoxwZl+n1H7wp+EcmrtNXfgHMYgTaBw4LeHv/50riCKCc/hXJpIUkKW fP7lr9sfPibwnjNDgePl2+vz7y6vL04Or79n2nJKROCmr0cnmlQFp8caeDFyBNJ+unKq6DsTRgNE 7E6DuWfA3GmWvkVJ1S3A1ezAVGAaQnVBrrJl+tfVOmPKEbEkGWpIsS82oOLUDjWD8AGVwV+ABdTa 0uTonLsaRNHgihBICLAPJOyi7ocjGfm9NIIwfeAWHZ/US1qrccFIbmI85qU08HUOYU/w6pgLmBQk QzrRGSt7DFJPv8pdSElmNL2AEEN4gbaaWVog2Qe2sN6Y2XA6pmJRo4GCT3rjM5VDJrsZgfyTvi7x CTMsgdoBD0HVuBIgWFNLCgrUReZKG3vCYE4hAaABJ4SVZGR0ahAxHI1HcFkqNNZZImQCo3BvZ2vH MczslNwynQgO15Y2TpOACf36QuaO2RIuPA0KhAQ90c5AwqtTHuoOk3X2Hei62SCd1T0IaChYbJLY 9lds4zNjJ/bWr9+wPSb4jRMJAcZ5Y+NcegKXi4XBBJeIA8EH4HF/m/B3i9CFo4gVbX1wZPVcH4RO noO6Poe8OIWW3kmf7Pr+mn2FkYNRQg+jT4Kn0RvrSgbABZeQx3GeBhcFuXb/758/ok7rNIN+lyxf ovfsMrl6lZwoC+MBwxSm9MLychS//rYeivreMHdJeND6zz/9uJ7eBTP9HWVhean1t5/+mEOBOeDi sbQu4F7wf1089vr4YGb8x+vi9w9zGbliV3hU7d/++WlO11z2Y2vyXTF8fK7Y0xfn153PkNDTl/XX buE+T2PnDF8iYXW2z+AS3gxC20QDYit3q/Dvl/1/AAAA//8DAFBLAwQUAAYACAAAACEAvejRAVMB AAD/AgAAEAAAAHdvcmQvaGVhZGVyMS54bWycUslqwzAQvRf6D0b3REoKIZg4gRB66qF0+QBFkmNR bUiy3fx9R966HILpRYPm6b03o5nd4VOrrBE+SGsKtFoSlAnDLJfmUqD3t8fFFmUhUsOpskYU6CoC Ouzv73ZtXnGfAduEvAGgitHlGAdWCU3D0jphACyt1zTC1V+wpv6jdgtmtaNRnqWS8YrXhGzQIGML VHuTDxILLZm3wZYxUXJblpKJIYwMP8e3Z54sq7UwsXPEXiiowZpQSRdGNf1fNWixGkWaW000Wo3v WjfHjXvawii06sturefOWyZCgOypByfFFbnlPXxgkpgYc0r47TlWoqk0k0xajD/zn4a3hOHh3hsn qe9G4C/2sEYua3NYP/5SIEKOx9V2fURj6iRKWqv4A+kYz74Lr/GqBDxtqCoQPSOcstJwSJXSh/gk U2EPG5IQDE6Jl2J3wvruvwAAAP//AwBQSwMEFAAGAAgAAAAhAJUqyOFpAQAAswMAABEAAAB3b3Jk L2VuZG5vdGVzLnhtbKST227DIAyG7yftHSLuU+gutilqUmmK+gA7PAAjpEELGAFJ1refc+xWVVXV 3ZBg48+/sdlsv3UdtdJ5BSYl6xUjkTQCCmX2Kfl438XPJPKBm4LXYGRKDtKTbXZ/t+kSaQoDQfoI EcYnLXqrEGxCqReV1NyvwEqDzhKc5gG3bk81d1+NjQVoy4P6VLUKB/rA2COZMJCSxplkQsRaCQce ytCHJFCWSsjpM0e4a/KOkTmIRksThozUyRo1gPGVsn6m6VtpWGI1Q9pLRbS6ns919ppsheMd9kPX o+wOXGEdCOk9WvPRuRDX7FLu6QJ7xBJxjYS/OWclmiuzYPrpOOn/0rwVNo+OuWmPOhaCd5EdZynq knCwCPLScscDOIImVaQkXg/nLG5xVovXlDDGnli+e+lPDKZclrypwy9PT3b9suBotqGDDVc7/E9T fE6EABOUaYYZeTsVxP6j5yz5gjZUO7+27AcAAP//AwBQSwMEFAAGAAgAAAAhALRY3uZpAQAAuQMA ABIAAAB3b3JkL2Zvb3Rub3Rlcy54bWykkktuwyAQhveVegeLvQPpoq2s2JEqKwfo4wAU4xjVMAiw 3dy+42fTKIqidIPNPL75h5nN9lvXUSudV2BSsl4xEkkjoFBmn5KP9138TCIfuCl4DUam5CA92Wb3 d5suKQGCgSB9hAzjkxbdVQg2odSLSmruV2ClQWcJTvOAV7enmruvxsYCtOVBfapahQN9YOyRTBhI SeNMMiFirYQDD2XoUxIoSyXk9Jkz3DV1x8wcRKOlCUNF6mSNGsD4Slk/0/StNGyxmiHtpSZaXc9x nb2mWuF4hwPR9Si7A1dYB0J6j9Z8dC7ENbtUe3rAHrFkXCPhb81ZiebKLJh+PU7mvwxvhcOjY23a o34bwbfIjpYp6pJwsEjy0nLHAziCJlWkJF4PgRavuK3Fa0oYY08s3730EYMplyVv6nDk6dGuPxYc zTZ0sOFph/95j8/KEGCCMs2wJm+nkth/FJ0lX1KHgmepPvsBAAD//wMAUEsDBBQABgAIAAAAIQBY YLMbugAAACIBAAAbAAAAd29yZC9fcmVscy9oZWFkZXIyLnhtbC5yZWxzhI/LCsIwEEX3gv8QZm/T uhCRpm5EcCv1A4ZkmkabB0kU+/cG3CgILude7jlMu3/aiT0oJuOdgKaqgZGTXhmnBVz642oLLGV0 CifvSMBMCfbdctGeacJcRmk0IbFCcUnAmHPYcZ7kSBZT5QO50gw+WszljJoHlDfUxNd1veHxkwHd F5OdlIB4Ug2wfg7F/J/th8FIOnh5t+TyDwU3trgLEKOmLMCSMvgOm+oaSAPvWv71WfcCAAD//wMA UEsDBBQABgAIAAAAIQC96NEBUwEAAP8CAAAQAAAAd29yZC9oZWFkZXIzLnhtbJxSyWrDMBC9F/oP RvdESgohmDiBEHrqoXT5AEWSY1FtSLLd/H1H3rocgulFg+bpvTejmd3hU6usET5Iawq0WhKUCcMs l+ZSoPe3x8UWZSFSw6myRhToKgI67O/vdm1ecZ8B24S8AaCK0eUYB1YJTcPSOmEALK3XNMLVX7Cm /qN2C2a1o1GepZLxiteEbNAgYwtUe5MPEgstmbfBljFRcluWkokhjAw/x7dnniyrtTCxc8ReKKjB mlBJF0Y1/V81aLEaRZpbTTRaje9aN8eNe9rCKLTqy26t585bJkKA7KkHJ8UVueU9fGCSmBhzSvjt OVaiqTSTTFqMP/OfhreE4eHeGyep70bgL/awRi5rc1g//lIgQo7H1XZ9RGPqJEpaq/gD6RjPvguv 8aoEPG2oKhA9I5yy0nBIldKH+CRTYQ8bkhAMTomXYnfC+u6/AAAA//8DAFBLAwQUAAYACAAAACEA z4kcKlMBAAD/AgAAEAAAAHdvcmQvZm9vdGVyMS54bWycUstuwyAQvFfqP1jcE0gqRZFVJ1IU9dRD 1ccHUBtiVGARYLv5+y5+9XGIol5YscPM7LJ7v/80OmuFDwpsQVZLRjJhS6iUPRXk7fVhsSVZiNxW XIMVBTmLQPa725v7LpfRZ8i2IW8RqGN0OaWhrIXhYQlOWAQleMMjXv2JGu4/GrcowTge1bvSKp7p mrENGWWgII23+SixMKr0EEDGRMlBSlWKMUwMf43vwDxC2RhhY+9IvdBYA9hQKxcmNfNfNWyxnkTa S020Rk/vOneNW+V5h6Mweii7A185D6UIAbPHAZwVV+yS9/iBSWJmXFPCb8+pEsOVnWXSYvyZ/zy8 JQ6PDt40SX03gn+xwzVyWZfj+lXPBWHscFht1wcypY5C8kbHH0jPePJ9eIlnLfBpy3VBOCc0ZZWt MCWVD/FRpcLuNiwhFJ0SL8X+xPXdfQEAAP//AwBQSwMEFAAGAAgAAAAhAMccbRScBgAAURsAABUA AAB3b3JkL3RoZW1lL3RoZW1lMS54bWzsWU1vG0UYviPxH0Z7b2MndhpHdarYsRto00axW9TjeD3e nXp2ZzUzTuobao9ISIiCeqAS4sIBAZVaCSTKr0kpKkXqX+Cdmd31TrwmSRtBBfUh8c4+7/fHvDO+ eOlOxNA+EZLyuOlVz1c8RGKfD2kcNL0b/e65NQ9JheMhZjwmTW9KpHdp4/33LuJ1FZKIIKCP5Tpu eqFSyfrSkvRhGcvzPCExvBtxEWEFjyJYGgp8AHwjtrRcqawuRZjGHopxBGyvj0bUJ+jZz7+8+OaB t5Fx7zAQESupF3wmepo3cUgMdjiuaoScyjYTaB+zpgeChvygT+4oDzEsFbxoehXz8ZY2Li7h9ZSI qQW0Bbqu+aR0KcFwvGxkimCQC612a40LWzl/A2BqHtfpdNqdas7PALDvg6VWlyLPWnet2sp4FkD2 6zzvdqVeqbn4Av+VOZ0brVar3kh1sUwNyH6tzeHXKqu1zWUHb0AWX5/D11qb7faqgzcgi1+dw3cv NFZrLt6AQkbj8RxaB7TbTbnnkBFn26XwNYCvVVL4DAXZkGeXFjHisVqUaxG+zUUXABrIsKIxUtOE jLAPadzG0UBQrAXgdYILb+ySL+eWtCwkfUET1fQ+TDCUxIzfq6ffv3r6GB3efXJ496fDe/cO7/5o GTlU2zgOilQvv/3sz4cfoz8ef/3y/hfleFnE//bDJ89+/bwcCOUzU+f5l49+f/Lo+YNPX3x3vwS+ KfCgCO/TiEh0jRygPR6BYcYrruZkIE5H0Q8xLVJsxoHEMdZSSvh3VOigr00xS6Pj6NEirgdvCmgf ZcDLk9uOwr1QTBQtkXwljBzgDuesxUWpF65oWQU39ydxUC5cTIq4PYz3y2S3cezEtzNJoG9maekY 3g6Jo+Yuw7HCAYmJQvodHxNSYt0tSh2/7lBfcMlHCt2iqIVpqUv6dOBk04xom0YQl2mZzRBvxzc7 N1GLszKrt8i+i4SqwKxE+T5hjhsv44nCURnLPo5Y0eFXsQrLlOxNhV/EdaSCSAeEcdQZEinLaK4L sLcQ9CsYOlZp2HfYNHKRQtFxGc+rmPMicouP2yGOkjJsj8ZhEfuBHEOKYrTLVRl8h7sVop8hDjhe GO6blDjhPr4b3KCBo9IsQfSbidCxhFbtdOCIxn/XjhmFfmxz4OzaMTTA5189LMmst7URb8KeVFYJ 20fa7yLc0abb5mJI3/6eu4Un8S6BNJ/feN613Hct1/vPt9xF9XzSRjvrrdB29dxgh2IzIkcLJ+QR ZaynpoxclWZIlrBPDLuwqOnM8ZDkJ6YkhK9pX3dwgcCGBgmuPqIq7IU4gQG76mkmgUxZBxIlXMLB ziyX8tZ4GNKVPRbW9YHB9gOJ1Q4f2uUVvZydC3I2ZrcJzOEzE7SiGZxU2MqFlCmY/TrCqlqpE0ur GtVMq3Ok5SZDDOdNg8XcmzCAIBhbwMurcEDXouFgghkZar/bvTcLi4nCWYZIhnhI0hhpu+djVDVB ynLF3ARA7pTESB/yjvFaQVpDs30DaScJUlFcbYG4LHpvEqUsg2dR0nV7pBxZXCxOFqODpteoL9c9 5OOk6Y3gTAtfowSiLvXMh1kAN0O+Ejbtjy1mU+WzaDYyw9wiqMI1hfX7nMFOH0iEVFtYhjY1zKs0 BVisJVn9l+vg1rMywGb6a2ixsgbJ8K9pAX50Q0tGI+KrYrALK9p39jFtpXyiiOiFwwM0YBOxhyH8 OlXBniGVcDVhOoJ+gHs07W3zym3OadEVb68Mzq5jloQ4bbe6RLNKtnBTx7kO5qmgHthWqrsx7vSm mJI/I1OKafw/M0XvJ3BTsDLUEfDhHldgpOu16XGhQg5dKAmp3xUwOJjeAdkCd7HwGpIKbpPNf0H2 9X9bc5aHKWs48Kk9GiBBYT9SoSBkF9qSyb5jmFXTvcuyZCkjk1EFdWVi1R6QfcL6ugeu6r3dQyGk uukmaRswuKP55z6nFTQI9JBTrDenh+R7r62Bf3ryscUMRrl92Aw0mf9zFUt2VUtvyLO9t2iIfjEb s2pZVYCwwlbQSMv+NVU45VZrO9acxcv1TDmI4rzFsJgPRAnc9yD9B/Y/KnxGTBrrDbXP96C3Ivih QTODtIGsPmcHD6QbpF0cwOBkF20yaVbWtenopL2WbdZnPOnmco84W2t2knif0tn5cOaKc2rxLJ2d etjxtV1b6GqI7NEShaVRdpAxgTG/aRV/deKD2xDoLbjfnzAlTTLBb0oCw+jZM3UAxW8lGtKNvwAA AP//AwBQSwMECgAAAAAAAAAhAMcZ/uonjQAAJ40AABYAAAB3b3JkL21lZGlhL2ltYWdlMS5qcGVn /9j/4AAQSkZJRgABAgEBLAEsAAD/4RpKRXhpZgAATU0AKgAAAAgABwESAAMAAAABAAEAAAEaAAUA AAABAAAAYgEbAAUAAAABAAAAagEoAAMAAAABAAIAAAExAAIAAAAUAAAAcgEyAAIAAAAUAAAAhodp AAQAAAABAAAAnAAAAMgAAAEsAAAAAQAAASwAAAABQWRvYmUgUGhvdG9zaG9wIDcuMAAyMDA2OjA0 OjI4IDEzOjUxOjAxAAAAAAOgAQADAAAAAf//AACgAgAEAAAAAQAAASygAwAEAAAAAQAAASwAAAAA AAAABgEDAAMAAAABAAYAAAEaAAUAAAABAAABFgEbAAUAAAABAAABHgEoAAMAAAABAAIAAAIBAAQA AAABAAABJgICAAQAAAABAAAZHAAAAAAAAABIAAAAAQAAAEgAAAAB/9j/4AAQSkZJRgABAgEASABI AAD/7QAMQWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwP FRgTExUTExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQO Dg4UFA4ODg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEI AIAAgAMBIgACEQEDEQH/3QAEAAj/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEF AQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMi cYEyBhSRobFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj 80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcG BTUBAAIRAyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kST VKMXZEVVNnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/ 2gAMAwEAAhEDEQA/APVUkkklKSSSSUxssrqrdba4MrYC573GAGgS5znH6LWrges/4wcq699HR4px 2naMl7ZsfH59bH+ypn/GM9T/AIv6Ctf4yeruqop6RUYN/wCmv/qNMUs/tWtc/wD6yuDo5VLmeYkJ cEDVfMXpvgnwjFLCOa5iInx37WOXyCI/TlH9LidgZ/Usixtt2XdZYxwfWX2OcGuB3tc2ufT9rh+4 vT+k546j06jMA2m1vvb2D2nZa0f1bGuXleP2Xd/UnJ34V+IeaLN7f6tgn/z4y1N5SZ9wgn5h+IV8 dwROATjER9qXQcP6ufpl/wA/gd/KyGY2PZe/6NbSY8T2b/acuWpflb3Wi17LLHF79jiAXE7ne36K 2vrDcGYjKe91gEeTf0h/6TWrKo2907mpnjEQflH/ADi5fJQ4cMpkXxn/AJsW7jdYyqXBuV+lq4Lg IeP5Xt9r1tV2MtrbZW4OY8S1w4IK5y7bGitdBynC2zDOrINtflqBY3+1u3/56PL5pcQhI2DsT3W8 xy8TA5IR4THWQGxi7aSSSuOepJJJJT//0PVUPIyKcWizIvcGU0tL7Hns1olx0RFwn+MnrL2+j0el 8NePWygO4n9BW7+011mz/iUzLkGOBl9nm2uQ5SXN8xDCDQkbnL93HH5i18b/ABg3n6wG64FvSrYq FR5Yyfbknbu/S/nWt/63+ZWvQWPZYxtlbg9jwHNc0yCDq1zXBeErvP8AF99Y+OiZbhpJw3H/AD7K C7/wSr/M/wBEqnLcwTLhmb4jof63Z3vjXwbHHAM/LQ4fZiI5ID9LFH/Kf34fpuf/AIyp/b1M/wDc Vkf59y5ikwfmu6/xmdOLqsTqbG/QJotOsw79JT/Za4Xf9uLgmGD8VDzIIyyvrq6nwbJHJ8Ow8P6M TCX96EnUx3cLrPqTaR1OyudLKCSPNj2bf/Pj1xlFi6b6nXR12hv+kZY3/o+p/wCi0MBrJDzH4sHx TFfLZvCEpf4nrd/6zX/r1FPZlZf/AJ7tv/opUa74Cb603x1ot/dprH3mxyz236J2Y3ln5/k5nLYP 6Ni03jf+N6nSffI5VnoL93VhHap5P3sWK7I05W39UaXWX5GYfoMaKWHxJi2z/Nb6KOEXlj539i3m sYx8tlkf3eH/AB/S9MSAJPC4fqf10yWdXZbha4OMXVurJEXgmLLJ/M+j+qO/75d6SvfXTrnpsPSM ckPsaDlPB4rd/gNPzrv8J/wH/HLhb7FLzPMES4IGuE+o+PZPwb4XGcDmzwEvcBjjhL9yX+U/wv0H 17CzMfOxKsvGdvpuaHsPx/Nd/Lb9F6OvP/8AF51kszLukWvOy+bcdp7PaJuaP+MrHqf9aXoCs4cn uQEvofNyfiPJy5TmZ4TrH5scv3scvl/7x//R9VXjn1rufd9ZOoPs+kLiwf1awKmf9Bi9jXmP+MTp L8TrA6g0TRnAEmNG2MDa3s/tt2Wf9uKtzkScYI6HV2/+LmWEOclGWksmMxh5gifC8qpMe+t7bGEt e0hzXAwQRqHNKinWc9kNQ+oYeZV9cvqvfjuLasst2WtB0ba2LKbfzneha9jf/Bal5jbW+qx9Vg22 VuLXtPIIO1wWn9WeuP6J1SvJO52M/wBmTW08sP539ap36Rv/AG3+etT6+dIqx82vq2J78TqQ9Tcz VgsgO3Bzfb+sNPrfy/0ysZD7uMT/AE4emf8Ad/Rk5HJ4/uPOT5bbl+avNy3aGWP87h/xHm6rIXQf VG7/ALIsCO73j76rQuZW59Tnk/WXAH8t3/UPUWL+ch/ej+bd5+APK8wf9Vk/9Jydj613R9Yslv7r ah/0N3/flnNyET65W7frRmjyq/8APTFkjI80cp/WT/vS/Np8pgvlOXPfFjP/AI3F0nZGncnsByT4 BdqcgfVf6tVuuAdlHRrOQ6+3dbslv+Dq93v/ANFUuW+p/T29R6n9pucG4vT9t9hJ0L9TQ0mRta3Z 6z/+LVL6z9f/AGt1N9tbicWma8Uagbfz7tp/Ovd/4F6akxy9uByfpS9MP+6k1eY5b71zMOVH81hr NzP94/zOH/C/6DSvyHvc59ji+x5LrHnlznGXvd/WVK22VGy6UIknlV7dzHiEXQ+rz3s6/wBOc0wT lVAkeDnta4f2muXs68r+ofSHdQ62zIcP0GBFzz/L/wC07P8APHq/9ZXqi0OSBECT1Ojyv/GbJCXN Y4R1ljh6/DjPFGL/AP/Su4H+M++nOyWZ9P2nCde80Pr2ttrrLnbK49teRtZs/wBE/wD4R67Jz+hf Wrpj6WWsyqHgE7SPUqcdwY/a730XN92zez/wNeJ5dDsPOyMN/wBLGtfU7vqxzq/++qxgZ2Vg5DMr DtdTfWZa9p/A/muY789jvYqXvyjYmOKL00vhWHKI5OXl7GWIEoyj8hI+U/1f8B2Ov/VrqHQr9t49 TGeYpymiGu/ku59O3/g1kyu36T/jBxcvFdgfWSkWMsAY69jZa5p5dfS36O36e/H/AO2kHrf1FD6z 1D6uWNy8RwLvQa7c4R/3Hsl3r/nezd6v/GqKeESuWI8Q6x/Ti6HLfEcmIxw8/H2sh9MM/wD4Hzf4 f+Tm8cu1+q2VV17o2T9Ws94NzG7+nvfqRA9oZp/2mf8Ay9/oWWVfzNa4tzXNcWPBa4aEHQg+aP0/ Nv6fm05tH87Q8PaDMGPpMdH5j2+x6ixz4Ja/KfTId4lvc7y/3jCYxPDlgRkwZP3M0PVCX/cyR5GP djX2Y97dl1LiyxuhhzTtcNFs/Uhu760YI87D91VpWx9demUZ+FR9aOnNJrvY37UJ1AIayqwtbubv r/mL/wBJ/o/+EWZ9Qai/6zY7v9Eyxx+bHV/+jE8YzDPGO44omJ7xa0+bjzHwzPlrhmMWWGWH+bzR hKM4f4yvr60t+s2SeN7Kj/0Gt/76sGpt1tjKqmmyywhrGNEkuJ2ta0D95dL/AIxmbfrCD+/Qw/i9 v/fVY+o3SKaq7/rH1BpGNhtc7HkcloJtua38/wBL6Ff/AAv/AAlSMsZnnlEfvEk9oowc3Hl/hWDN IcRGKEIQ65MtcEIBP9YLv+bX1cx+gY5b9szWl+bY06wYFv7vttd+r1v/ANBS9cQSSrXVuo29T6lk Z9ujr3lwbztaPbVXIDf5usNYqoBcQ1oknQAckqPLPilp8o9MR/VDZ5Hljgw+s3myE5c8/wB7Lk+b /Bh8kVlqdB+r2d1zKFOO0spaf02S4exg/wC/2/uVf+i/0i2+ifUS1zG5/XnjCwmje6pztjyO3rOd 7cdn73+G/wCKVzqP16wOn4jenfVugNZUCxtz2wxo/fqYffc930/Uv/P+n629PhhAHFlPDHpH9ObW 5j4jPJI4Ph8ffy/LLN/4G5f+9k/Tn/Uenx2dF+q/TGUvtrxqWAlz3mH2vA/SWbf5y6137rP6i5Tq f+Me+66uvplJopD2l9tkF7mgt3MFfuZV+d+db/1tchm52Zn5DsnMtdfc/lzj252tH0WM/kMQ6Kzd fXS3V1j2sA83Hanz5qRqOMcEdh+8wct8CwwMs3Ny+85pXKRl/NiX6R4f0/8Aqj//03/xndAtxepj rNLP1XM2tucPzbwNurY9rbqmMd/xvqrjWPXv+bhYufi2YeZU27HubtsrdwR/31zXe5j2/QXln1i/ xcdV6bYbulB/UcMydrQPWZr7WOrH9I9v+Epb/wBZrVXNhNmQF27vwz4jERjiyS4ZR0iTtKP/AHzz TXLS6P1zqXR7/XwbSwuj1Kzqx4H5tjPzv+rWVYy7HtdTkVuptYYdXY0scD/KY+HKTXjxVQgxNjQh 6GM8eWBjMRnCQ1jL1Rk+hVdX+rH1tZXT1pgwOpABrchh2h350NueHM26e2rJ/wCs2eosXrf1K6x0 kPua37XiMlxvq5a0T7rafp1+0bn/AM5Uz/Srmw4Lo/q/9dup9HimwnMwxA9Gxx3MAG0Ciz3em3/g /wCbT+OE9Moo/wCcj/3cWv8Ad+Y5X1clPjx9eUzH0f8Apvl/yX912P8AF71Oq6vJ6BmHfVe1zqK3 cEEFuVSNfzmfpNjf+GVn6t9As6N9cr8Y7nUDGfbjWuiXML6me7b+fXu9N/8AnrQxMH6tdfto6v0h 4xc3Hey1/ogMeDO51eXjj6XqfpGep/hP9LbWun2t3B0DcAQD3g8/kVnHiuMLIPtm4TH6Uezh878Q 4cnMe3CWP73Dg5nl8g4Tizx/ysf7zw31t6Lf1n63YeJX7WOxWuus/drZZb6j+/7zWV/8Io/X/qFe BgYn1ewztq2Ndc3UkV1w3GZuP7z2b3/n/omLu9rd26BuiJ7wuaz+nfVzpGTkda61YMrKyHOfU26H GG6Mpxcb891TPRr9R/0P+BSyYqEyCB7h9Uz+jBHJfEBLJy0ckJZI8pGsGDGOOWfmTtk/q8DxXRPq d1jq+y1rPs+I4ici3QFv71Vf07vb9D/Bf8Kt5+d9VvqiLK+nN/aHV2yx1jzIYfzt1jR6bGt/Oro/ S/4K16yfrB9eOo9VmjF3YWHqCxjjveD7f01jY9u3/BM/656q5qVV44Y9MY4pf5yX/cRegHK8zzfq 52XtYj/4Ewn5v/OnN/lP7kHR6x17qfWbhbm2y1v83S321t/qV/vfy3fpFnppUqqrbrG1UsdbY4w1 jAXOJ/ktaoSTI2TZLowjjxQEIRjjhEaRj6YxYrqPqD0R+f1VufbWTiYR3h/DTcINVf8AK9P+e9v/ AAe/+cTdC+ofVeoWCzPa7AxQRu3iLXfvNrqd9D/jLf8AwVek4ODi4GLXiYlYqoqENaPxc4/nOcrX L8vIyE5CojUA/pOF8Z+M44Yp8vgkJ5ZjhnKJ9OKJ+b1fvv8A/9T1VYn1o+sV31exa8wYL8zGcS26 xjw0VE7fS9T2v9lsub6n7/8Axta20HLxcfMxrcTJYLKL2Gu1hkS1w2uEthzf7KButDRXYzETBnHi jfqjto8Bb/jZxrBDukGweD7m/wDpFyEP8aWIf+8Ov/t5v/vKsb60/UTqfRLbMjGY7L6aXHZYwF1l bY3bcpjR7dv0fXb+i/4n1PSXLSPFVZZMoNE19A72DlORyREoR4on+vP/AL59DP8AjOod9Do1Tfja D/7rtSZ/jEzMixtOJ0ih9zzDGAOscT4NZW1rnLC+r31G671nbcWfY8MmDkXggkaSaaPbZbz/AMHT /wAKvT+g/VjpPQqz9jrm97Q23JeZe4DX+rWzd+ZUjGOaW8uEeQWcxl+G4BUcXu5f3ePJwj+/LjTd Fb1X7ObeqVY+PdZBbTjtMtH7t1jnvbY//i/+mtFJJWQKFOJknxyMqEb/AEY/KPJSo9Xb1E4vqdNq ouya5IqyAYcI1rre1zPTsd/L/Rq8kkRYpUJ8EhKhKjtL5T5vndn+MDOxbXUZnSaWXVmH1ncxw7/R e1ydv+Muv87pFZ+FoH/ohy7HrP1e6X1qoMzqpewEV3MO2xk/uu/75ZvrXm/XfqP1npINtbftuIP8 LSDuaPG6j3PZ/WZ6taqZBzENRLij5C3oeSyfCeZAjkwjDl/dOTJGEv8AZz4/+a7P/jmY/wD5Ts/7 eH/vOiM/xoYzNB0wtnnbaP8A0k1eel4W/wDVv6n9S63ay17HY/TwQbL3jaXNn3DG3NPqP/l/zSjh lzyNA39ItvmPh/wvFAzyQ4Yjvky/9++i/Vr6xu6/Vde3DfjUVENbY524PcZ3tZDW/wA3+d/XW2gY WHjYGLVh4rBVRS3axg8P+/Od9J7kdX4ggDiNnqXlc8scskjih7eO/RC+Ko+Jk//V9VSXC/UX/GLl /WnrF3TrsKvGbTjuv3seXElr6qtvua3/AEy7DqeW7C6bl5jGh7saiy5rCYDjW11gaXa/S2pKbSh6 NPqersb6sRvgbo8N30lyP1C+vWT9ax1A3YjMb7C2ot2OLtxs9bncP+BVb6if4xMv61dVuwLsKvGb Tjm/ex7nEkPrq27XN/4VJT3SSzfrH1Wzo3Q8zqlVYufi1+o2txIB1A1cFj/UL65ZH1sxcu+/GZi/ ZrGsaGOLp3N3a7g1JT1SS5b6+fXUfVPDxbK6BlZOXYW11OcWtDGAG6zc0O+i59TNv/CKH1D+vdX1 sqyWW1Nxc3GcCaGu3B1Tvo3M3bX+2z2W/ufov9Kkp6xJcL1b/GLl9G+uFfQeoYVbMO2ysNzN5b+i uhrLyHjZtpsP6b/irV1/Vs9vTOl5nUXN3jDosv2TG702us2bv5e3YkptpLzf6q/42retddxel5mF Vi15RcxtzbCYs2l1Tdr2/wCFe30f69i7X6y9br6D0PL6rY3f9mZLK+N1jiK6Wf2rXs3JKb5ooNou NbDaNBZtG6P6/wBJEXJfVP67nq/Qczr/AFdlPTcHFsNYfucZ2tY57zub7t77q6qWV/pLLf0awP8A x3eo5+VbT0DoF2cyrXcC97yzhtj6Mamz0f8At2xJVl9MSXn2B9ffrpk5+Nj3/VbIoputrrtudXeA xjnNbZa4upDfYw7lZ+vn+MPL+qvU8fCpw68ll9AuL3vc0g7317drWn9xJT//1uQ+of1gy+gdbvzM Tp1nVLLMd9JoqLmua02U2et7Ksj2t9LZ9D/CLtOp/wCMzreX03LxX/VbKpZfRZW60vsIYHMc11jv 1Nv8233/AElj/wCJhrm/WzL3NLZwbYkR/hsVesfWGf2B1KOfsl8R/wAW9JT5v/iQ465/Vxv/AHaW f/iT/wDFLmf+Enf+fcdaX+I5pDutBwiRi8+B+1LG6KOqf4tfrRbd1TCtyMKyt2Ocipp2vrc6u1t2 O922p9jfSb+hfYkp9P8Ar/8A+I3q3/hc/lauU/xIf8mdT/4+v/qCqX1s/wAZ2F9YeiX9G6Hg5bsn N2sc6xjNGBzXv2MofkutdZs9L/BqGFVm/Uf/ABdZhzWmnq3XLCzFoaSLWMfWGb7Gj31W01evd7f5 p78euz07UlNd3UKvrZ/jObkX5VVPSekWB1Vj7Gema8Z42em922u37dl/pP8AwvZ/wKBk9QxPqd/j LOfhWMs6VmnfZ6L2Ob6OQf1hv6Lc1n2bLY66uj/gKld+pf8Aip6d1joFPU+r3ZNN2UXPprocxoFP 0anWNuot99m19vtf/MvqS+uv+Krp3RugXdT6RblX3Yrmvurucx49H6Nr2Npoqdurc5ljvds9H1Ul N7/HV0L1cXD69U2XY5+y5MST6bybMd/7rWV2+qz/ANCGKX1v+tjcj/Ffg2ssL8nq7a8e1xMP3Vf0 98fnM9bH9F3/AIYVv6q3H66f4u8noeW/9ex2fZS55gyzbd03Is2Df6e5ldb/APTfZ7l5d07G6h1L N6d9XL97KRmmsAt91br3U05f/bbcbds/4xJTtde6L/zb6b9U+u4o/T21Nvt9sD1Wvb1Ch1jx9Kz0 8n0P+LxV1P8Aje+sGNlfV/pOLiOLx1Nzc1pBAPotZ+iFlf0v0z8n2f8Ahd66X/GT0NnU/qdlVUsA s6eBlY7QYAFIPqtgfS/VHXtYz9/YvK/qV0/L+sn1m6ThZkvxenMkyIiil78oVO/fa/Iv9H+pakp6 769dOf8AVv8AxY9P6PXAc++qvMIMhz3Nuzb/AHfnN+01ez+Qsj6j/XHM+r/RRj4P1bvzjdY59udW 54FhB2tb7cW/+Zb+j2+r/wCfF6R9efq5Z9Y/q7f0+gtGUHMuxnPMND2HuRP06nW1f21539Vvrt1j 6lUWdB650u99NNjjTHsfXuO61jdw9LIofZ+lqsY/8/8AwtdlfppT0uB/jM61lZ2Ni2fVfJoZkWsq dc59hDA9zWGx04bPobt30lzH+O3/AMUGD/4TH/ny1dPg/wCN7p2bnY2G3puSx2VdXS17iyAbHNqD j/nLmv8AHWx7vrBg7Wk/qY4E/wCEtSU//9n/7R74UGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAA AAAAAAAAAAAAAAAAAAAAOEJJTQPtAAAAAAAQASwAAAABAAIBLAAAAAEAAjhCSU0EJgAAAAAADgAA AAAAAAAAAAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkA AAAAAAAAAAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABI AC9mZgABAGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUA AAABAC0AAAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA /////////////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD/ ////////////////////////////A+gAADhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklN BB4AAAAAAAQAAAAAOEJJTQQaAAAAAANbAAAABgAAAAAAAAAAAAABLAAAASwAAAATAEgAVwBfAFAA TwBTAF8AUgBHAEIAXwBWAGUAcgB0AGkAYwBhAGwAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAASwAAAEsAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAA AABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAAAFJjdDEAAAAEAAAAAFRvcCBsb25nAAAA AAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAEsAAAAAFJnaHRsb25nAAABLAAAAAZzbGlj ZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAASAAAAB3NsaWNlSURsb25nAAAAAAAAAAdn cm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxFU2xpY2VPcmlnaW4AAAANYXV0b0dlbmVy YXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAAAEltZyAAAAAGYm91bmRzT2JqYwAAAAEA AAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAATGVmdGxvbmcAAAAAAAAAAEJ0b21sb25n AAABLAAAAABSZ2h0bG9uZwAAASwAAAADdXJsVEVYVAAAAAEAAAAAAABudWxsVEVYVAAAAAEAAAAA AABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAAAQAAAAAADmNlbGxUZXh0SXNIVE1MYm9v bAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpBbGlnbmVudW0AAAAPRVNsaWNlSG9yekFs aWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAAAA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVm YXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNlQkdDb2xvclR5cGUAAAAATm9uZQAAAAl0 b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9uZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9u ZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAA AAE4QklNBAwAAAAAGTgAAAABAAAAgAAAAIAAAAGAAADAAAAAGRwAGAAB/9j/4AAQSkZJRgABAgEA SABIAAD/7QAMQWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUP DAwPFRgTExUTExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4O EBQODg4UFA4ODg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/A ABEIAIAAgAMBIgACEQEDEQH/3QAEAAj/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsB AAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFR YRMicYEyBhSRobFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD 03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUG BwcGBTUBAAIRAyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC 0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5en t8f/2gAMAwEAAhEDEQA/APVUkkklKSSSSUxssrqrdba4MrYC573GAGgS5znH6LWrges/4wcq699H R4px2naMl7ZsfH59bH+ypn/GM9T/AIv6Ctf4yeruqop6RUYN/wCmv/qNMUs/tWtc/wD6yuDo5VLm eYkJcEDVfMXpvgnwjFLCOa5iInx37WOXyCI/TlH9LidgZ/Usixtt2XdZYxwfWX2OcGuB3tc2ufT9 rh+4vT+k546j06jMA2m1vvb2D2nZa0f1bGuXleP2Xd/UnJ34V+IeaLN7f6tgn/z4y1N5SZ9wgn5h +IV8dwROATjER9qXQcP6ufpl/wA/gd/KyGY2PZe/6NbSY8T2b/acuWpflb3Wi17LLHF79jiAXE7n e36K2vrDcGYjKe91gEeTf0h/6TWrKo2907mpnjEQflH/ADi5fJQ4cMpkXxn/AJsW7jdYyqXBuV+l q4LgIeP5Xt9r1tV2MtrbZW4OY8S1w4IK5y7bGitdBynC2zDOrINtflqBY3+1u3/56PL5pcQhI2Ds T3W8xy8TA5IR4THWQGxi7aSSSuOepJJJJT//0PVUPIyKcWizIvcGU0tL7Hns1olx0RFwn+MnrL2+ j0el8NePWygO4n9BW7+011mz/iUzLkGOBl9nm2uQ5SXN8xDCDQkbnL93HH5i18b/ABg3n6wG64Fv SrYqFR5Yyfbknbu/S/nWt/63+ZWvQWPZYxtlbg9jwHNc0yCDq1zXBeErvP8AF99Y+OiZbhpJw3H/ AD7KC7/wSr/M/wBEqnLcwTLhmb4jof63Z3vjXwbHHAM/LQ4fZiI5ID9LFH/Kf34fpuf/AIyp/b1M /wDcVkf59y5ikwfmu6/xmdOLqsTqbG/QJotOsw79JT/Za4Xf9uLgmGD8VDzIIyyvrq6nwbJHJ8Ow 8P6MTCX96EnUx3cLrPqTaR1OyudLKCSPNj2bf/Pj1xlFi6b6nXR12hv+kZY3/o+p/wCi0MBrJDzH 4sHxTFfLZvCEpf4nrd/6zX/r1FPZlZf/AJ7tv/opUa74Cb603x1ot/dprH3mxyz236J2Y3ln5/k5 nLYP6Ni03jf+N6nSffI5VnoL93VhHap5P3sWK7I05W39UaXWX5GYfoMaKWHxJi2z/Nb6KOEXlj53 9i3msYx8tlkf3eH/AB/S9MSAJPC4fqf10yWdXZbha4OMXVurJEXgmLLJ/M+j+qO/75d6SvfXTrnp sPSMckPsaDlPB4rd/gNPzrv8J/wH/HLhb7FLzPMES4IGuE+o+PZPwb4XGcDmzwEvcBjjhL9yX+U/ wv0H17CzMfOxKsvGdvpuaHsPx/Nd/Lb9F6OvP/8AF51kszLukWvOy+bcdp7PaJuaP+MrHqf9aXoC s4cnuQEvofNyfiPJy5TmZ4TrH5scv3scvl/7x//R9VXjn1rufd9ZOoPs+kLiwf1awKmf9Bi9jXmP +MTpL8TrA6g0TRnAEmNG2MDa3s/tt2Wf9uKtzkScYI6HV2/+LmWEOclGWksmMxh5gifC8qpMe+t7 bGEte0hzXAwQRqHNKinWc9kNQ+oYeZV9cvqvfjuLasst2WtB0ba2LKbfzneha9jf/Bal5jbW+qx9 Vg22VuLXtPIIO1wWn9WeuP6J1SvJO52M/wBmTW08sP539ap36Rv/AG3+etT6+dIqx82vq2J78TqQ 9TczVgsgO3Bzfb+sNPrfy/0ysZD7uMT/AE4emf8Ad/Rk5HJ4/uPOT5bbl+avNy3aGWP87h/xHm6r IXQfVG7/ALIsCO73j76rQuZW59Tnk/WXAH8t3/UPUWL+ch/ej+bd5+APK8wf9Vk/9Jydj613R9Ys lv7rah/0N3/flnNyET65W7frRmjyq/8APTFkjI80cp/WT/vS/Np8pgvlOXPfFjP/AI3F0nZGncns ByT4BdqcgfVf6tVuuAdlHRrOQ6+3dbslv+Dq93v/ANFUuW+p/T29R6n9pucG4vT9t9hJ0L9TQ0mR ta3Z6z/+LVL6z9f/AGt1N9tbicWma8Uagbfz7tp/Ovd/4F6akxy9uByfpS9MP+6k1eY5b71zMOVH 81hrNzP94/zOH/C/6DSvyHvc59ji+x5LrHnlznGXvd/WVK22VGy6UIknlV7dzHiEXQ+rz3s6/wBO c0wTlVAkeDnta4f2muXs68r+ofSHdQ62zIcP0GBFzz/L/wC07P8APHq/9ZXqi0OSBECT1Ojyv/Gb JCXNY4R1ljh6/DjPFGL/AP/Su4H+M++nOyWZ9P2nCde80Pr2ttrrLnbK49teRtZs/wBE/wD4R67J z+hfWrpj6WWsyqHgE7SPUqcdwY/a730XN92zez/wNeJ5dDsPOyMN/wBLGtfU7vqxzq/++qxgZ2Vg 5DMrDtdTfWZa9p/A/muY789jvYqXvyjYmOKL00vhWHKI5OXl7GWIEoyj8hI+U/1f8B2Ov/VrqHQr 9t49TGeYpymiGu/ku59O3/g1kyu36T/jBxcvFdgfWSkWMsAY69jZa5p5dfS36O36e/H/AO2kHrf1 FD6z1D6uWNy8RwLvQa7c4R/3Hsl3r/nezd6v/GqKeESuWI8Q6x/Ti6HLfEcmIxw8/H2sh9MM/wD4 Hzf4f+Tm8cu1+q2VV17o2T9Ws94NzG7+nvfqRA9oZp/2mf8Ay9/oWWVfzNa4tzXNcWPBa4aEHQg+ aP0/Nv6fm05tH87Q8PaDMGPpMdH5j2+x6ixz4Ja/KfTId4lvc7y/3jCYxPDlgRkwZP3M0PVCX/cy R5GPdjX2Y97dl1LiyxuhhzTtcNFs/Uhu760YI87D91VpWx9demUZ+FR9aOnNJrvY37UJ1AIayqwt bubvr/mL/wBJ/o/+EWZ9Qai/6zY7v9Eyxx+bHV/+jE8YzDPGO44omJ7xa0+bjzHwzPlrhmMWWGWH +bzRhKM4f4yvr60t+s2SeN7Kj/0Gt/76sGpt1tjKqmmyywhrGNEkuJ2ta0D95dL/AIxmbfrCD+/Q w/i9v/fVY+o3SKaq7/rH1BpGNhtc7HkcloJtua38/wBL6Ff/AAv/AAlSMsZnnlEfvEk9oowc3Hl/ hWDNIcRGKEIQ65MtcEIBP9YLv+bX1cx+gY5b9szWl+bY06wYFv7vttd+r1v/ANBS9cQSSrXVuo29 T6lkZ9ujr3lwbztaPbVXIDf5usNYqoBcQ1oknQAckqPLPilp8o9MR/VDZ5Hljgw+s3myE5c8/wB7 Lk+b/Bh8kVlqdB+r2d1zKFOO0spaf02S4exg/wC/2/uVf+i/0i2+ifUS1zG5/XnjCwmje6pztjyO 3rOd7cdn73+G/wCKVzqP16wOn4jenfVugNZUCxtz2wxo/fqYffc930/Uv/P+n629PhhAHFlPDHpH 9ObW5j4jPJI4Ph8ffy/LLN/4G5f+9k/Tn/Uenx2dF+q/TGUvtrxqWAlz3mH2vA/SWbf5y6137rP6 i5Tqf+Me+66uvplJopD2l9tkF7mgt3MFfuZV+d+db/1tchm52Zn5DsnMtdfc/lzj252tH0WM/kMQ 6KzdfXS3V1j2sA83Hanz5qRqOMcEdh+8wct8CwwMs3Ny+85pXKRl/NiX6R4f0/8Aqj//03/xndAt xepjrNLP1XM2tucPzbwNurY9rbqmMd/xvqrjWPXv+bhYufi2YeZU27HubtsrdwR/31zXe5j2/QXl n1i/xcdV6bYbulB/UcMydrQPWZr7WOrH9I9v+Epb/wBZrVXNhNmQF27vwz4jERjiyS4ZR0iTtKP/ AHzzTXLS6P1zqXR7/XwbSwuj1Kzqx4H5tjPzv+rWVYy7HtdTkVuptYYdXY0scD/KY+HKTXjxVQgx NjQh6GM8eWBjMRnCQ1jL1Rk+hVdX+rH1tZXT1pgwOpABrchh2h350NueHM26e2rJ/wCs2eosXrf1 K6x0kPua37XiMlxvq5a0T7rafp1+0bn/AM5Uz/Srmw4Lo/q/9dup9HimwnMwxA9Gxx3MAG0Ciz3e m3/g/wCbT+OE9Moo/wCcj/3cWv8Ad+Y5X1clPjx9eUzH0f8Apvl/yX912P8AF71Oq6vJ6BmHfVe1 zqK3cEEFuVSNfzmfpNjf+GVn6t9As6N9cr8Y7nUDGfbjWuiXML6me7b+fXu9N/8AnrQxMH6tdfto 6v0h4xc3Hey1/ogMeDO51eXjj6XqfpGep/hP9LbWun2t3B0DcAQD3g8/kVnHiuMLIPtm4TH6Uezh 878Q4cnMe3CWP73Dg5nl8g4Tizx/ysf7zw31t6Lf1n63YeJX7WOxWuus/drZZb6j+/7zWV/8Io/X /qFeBgYn1ewztq2Ndc3UkV1w3GZuP7z2b3/n/omLu9rd26BuiJ7wuaz+nfVzpGTkda61YMrKyHOf U26HGG6Mpxcb891TPRr9R/0P+BSyYqEyCB7h9Uz+jBHJfEBLJy0ckJZI8pGsGDGOOWfmTtk/q8Dx XRPqd1jq+y1rPs+I4ici3QFv71Vf07vb9D/Bf8Kt5+d9VvqiLK+nN/aHV2yx1jzIYfzt1jR6bGt/ Oro/S/4K16yfrB9eOo9VmjF3YWHqCxjjveD7f01jY9u3/BM/656q5qVV44Y9MY4pf5yX/cRegHK8 zzfq52XtYj/4Ewn5v/OnN/lP7kHR6x17qfWbhbm2y1v83S321t/qV/vfy3fpFnppUqqrbrG1Usdb Y4w1jAXOJ/ktaoSTI2TZLowjjxQEIRjjhEaRj6YxYrqPqD0R+f1VufbWTiYR3h/DTcINVf8AK9P+ e9v/AAe/+cTdC+ofVeoWCzPa7AxQRu3iLXfvNrqd9D/jLf8AwVek4ODi4GLXiYlYqoqENaPxc4/n OcrXL8vIyE5CojUA/pOF8Z+M44Yp8vgkJ5ZjhnKJ9OKJ+b1fvv8A/9T1VYn1o+sV31exa8wYL8zG cS26xjw0VE7fS9T2v9lsub6n7/8Axta20HLxcfMxrcTJYLKL2Gu1hkS1w2uEthzf7KButDRXYzET BnHijfqjto8Bb/jZxrBDukGweD7m/wDpFyEP8aWIf+8Ov/t5v/vKsb60/UTqfRLbMjGY7L6aXHZY wF1lbY3bcpjR7dv0fXb+i/4n1PSXLSPFVZZMoNE19A72DlORyREoR4on+vP/AL59DP8AjOod9Do1 TfjaD/7rtSZ/jEzMixtOJ0ih9zzDGAOscT4NZW1rnLC+r31G671nbcWfY8MmDkXggkaSaaPbZbz/ AMHT/wAKvT+g/VjpPQqz9jrm97Q23JeZe4DX+rWzd+ZUjGOaW8uEeQWcxl+G4BUcXu5f3ePJwj+/ LjTdFb1X7ObeqVY+PdZBbTjtMtH7t1jnvbY//i/+mtFJJWQKFOJknxyMqEb/AEY/KPJSo9Xb1E4v qdNqouya5IqyAYcI1rre1zPTsd/L/Rq8kkRYpUJ8EhKhKjtL5T5vndn+MDOxbXUZnSaWXVmH1ncx w7/Re1ydv+Muv87pFZ+FoH/ohy7HrP1e6X1qoMzqpewEV3MO2xk/uu/75ZvrXm/XfqP1npINtbft uIP8LSDuaPG6j3PZ/WZ6taqZBzENRLij5C3oeSyfCeZAjkwjDl/dOTJGEv8AZz4/+a7P/jmY/wD5 Ts/7eH/vOiM/xoYzNB0wtnnbaP8A0k1eel4W/wDVv6n9S63ay17HY/TwQbL3jaXNn3DG3NPqP/l/ zSjhlzyNA39ItvmPh/wvFAzyQ4Yjvky/9++i/Vr6xu6/Vde3DfjUVENbY524PcZ3tZDW/wA3+d/X W2gYWHjYGLVh4rBVRS3axg8P+/Od9J7kdX4ggDiNnqXlc8scskjih7eO/RC+Ko+Jk//V9VSXC/UX /GLl/WnrF3TrsKvGbTjuv3seXElr6qtvua3/AEy7DqeW7C6bl5jGh7saiy5rCYDjW11gaXa/S2pK bSh6NPqersb6sRvgbo8N30lyP1C+vWT9ax1A3YjMb7C2ot2OLtxs9bncP+BVb6if4xMv61dVuwLs KvGbTjm/ex7nEkPrq27XN/4VJT3SSzfrH1Wzo3Q8zqlVYufi1+o2txIB1A1cFj/UL65ZH1sxcu+/ GZi/ZrGsaGOLp3N3a7g1JT1SS5b6+fXUfVPDxbK6BlZOXYW11OcWtDGAG6zc0O+i59TNv/CKH1D+ vdX1sqyWW1Nxc3GcCaGu3B1Tvo3M3bX+2z2W/ufov9Kkp6xJcL1b/GLl9G+uFfQeoYVbMO2ysNzN 5b+iuhrLyHjZtpsP6b/irV1/Vs9vTOl5nUXN3jDosv2TG702us2bv5e3YkptpLzf6q/42retddxe l5mFVi15RcxtzbCYs2l1Tdr2/wCFe30f69i7X6y9br6D0PL6rY3f9mZLK+N1jiK6Wf2rXs3JKb5o oNouNbDaNBZtG6P6/wBJEXJfVP67nq/Qczr/AFdlPTcHFsNYfucZ2tY57zub7t77q6qWV/pLLf0a wP8Ax3eo5+VbT0DoF2cyrXcC97yzhtj6Mamz0f8At2xJVl9MSXn2B9ffrpk5+Nj3/VbIoputrrtu dXeAxjnNbZa4upDfYw7lZ+vn+MPL+qvU8fCpw68ll9AuL3vc0g7317drWn9xJT//1uQ+of1gy+gd bvzMTp1nVLLMd9JoqLmua02U2et7Ksj2t9LZ9D/CLtOp/wCMzreX03LxX/VbKpZfRZW60vsIYHMc 11jv1Nv8233/AElj/wCJhrm/WzL3NLZwbYkR/hsVesfWGf2B1KOfsl8R/wAW9JT5v/iQ465/Vxv/ AHaWf/iT/wDFLmf+Enf+fcdaX+I5pDutBwiRi8+B+1LG6KOqf4tfrRbd1TCtyMKyt2Ocipp2vrc6 u1t2O922p9jfSb+hfYkp9P8Ar/8A+I3q3/hc/lauU/xIf8mdT/4+v/qCqX1s/wAZ2F9YeiX9G6Hg 5bsnN2sc6xjNGBzXv2MofkutdZs9L/BqGFVm/Uf/ABdZhzWmnq3XLCzFoaSLWMfWGb7Gj31W01ev d7f5p78euz07UlNd3UKvrZ/jObkX5VVPSekWB1Vj7Gema8Z42em922u37dl/pP8AwvZ/wKBk9QxP qd/jLOfhWMs6VmnfZ6L2Ob6OQf1hv6Lc1n2bLY66uj/gKld+pf8Aip6d1joFPU+r3ZNN2UXPproc xoFP0anWNuot99m19vtf/MvqS+uv+Krp3RugXdT6RblX3Yrmvurucx49H6Nr2Npoqdurc5ljvds9 H1UlN7/HV0L1cXD69U2XY5+y5MST6bybMd/7rWV2+qz/ANCGKX1v+tjcj/Ffg2ssL8nq7a8e1xMP 3Vf098fnM9bH9F3/AIYVv6q3H66f4u8noeW/9ex2fZS55gyzbd03Is2Df6e5ldb/APTfZ7l5d07G 6h1LN6d9XL97KRmmsAt91br3U05f/bbcbds/4xJTtde6L/zb6b9U+u4o/T21Nvt9sD1Wvb1Ch1jx 9Kz08n0P+LxV1P8Aje+sGNlfV/pOLiOLx1Nzc1pBAPotZ+iFlf0v0z8n2f8Ahd66X/GT0NnU/qdl VUsAs6eBlY7QYAFIPqtgfS/VHXtYz9/YvK/qV0/L+sn1m6ThZkvxenMkyIiil78oVO/fa/Iv9H+p akp6769dOf8AVv8AxY9P6PXAc++qvMIMhz3Nuzb/AHfnN+01ez+Qsj6j/XHM+r/RRj4P1bvzjdY5 9udW54FhB2tb7cW/+Zb+j2+r/wCfF6R9efq5Z9Y/q7f0+gtGUHMuxnPMND2HuRP06nW1f21539Vv rt1j6lUWdB650u99NNjjTHsfXuO61jdw9LIofZ+lqsY/8/8AwtdlfppT0uB/jM61lZ2Ni2fVfJoZ kWsqdc59hDA9zWGx04bPobt30lzH+O3/AMUGD/4TH/ny1dPg/wCN7p2bnY2G3puSx2VdXS17iyAb HNqDj/nLmv8AHWx7vrBg7Wk/qY4E/wCEtSU//9k4QklNBCEAAAAAAFUAAAABAQAAAA8AQQBkAG8A YgBlACAAUABoAG8AdABvAHMAaABvAHAAAAATAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBw ACAANwAuADAAAAABADhCSU0EBgAAAAAABwABAAAAAQEA/+ESSGh0dHA6Ly9ucy5hZG9iZS5jb20v eGFwLzEuMC8APD94cGFja2V0IGJlZ2luPSfvu78nIGlkPSdXNU0wTXBDZWhpSHpyZVN6TlRjemtj OWQnPz4KPD9hZG9iZS14YXAtZmlsdGVycyBlc2M9IkNSIj8+Cjx4OnhhcG1ldGEgeG1sbnM6eD0n YWRvYmU6bnM6bWV0YS8nIHg6eGFwdGs9J1hNUCB0b29sa2l0IDIuOC4yLTMzLCBmcmFtZXdvcmsg MS41Jz4KPHJkZjpSREYgeG1sbnM6cmRmPSdodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJk Zi1zeW50YXgtbnMjJyB4bWxuczppWD0naHR0cDovL25zLmFkb2JlLmNvbS9pWC8xLjAvJz4KCiA8 cmRmOkRlc2NyaXB0aW9uIGFib3V0PSd1dWlkOmU2NTBlYTY0LWQ2N2EtMTFkYS1iYjVhLWUyZmVh OGI3NjFlMycKICB4bWxuczp4YXBNTT0naHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21tLyc+ CiAgPHhhcE1NOkRvY3VtZW50SUQ+YWRvYmU6ZG9jaWQ6cGhvdG9zaG9wOmU2NTBlYTYyLWQ2N2Et MTFkYS1iYjVhLWUyZmVhOGI3NjFlMzwveGFwTU06RG9jdW1lbnRJRD4KIDwvcmRmOkRlc2NyaXB0 aW9uPgoKPC9yZGY6UkRGPgo8L3g6eGFwbWV0YT4KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgCjw/eHBhY2tldCBlbmQ9J3cnPz7/7gAOQWRvYmUAZIAAAAAB /9sAhAAMCAgICQgMCQkMEQsKCxEVDwwMDxUYExMVExMYEQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwM DAwMDAwMDAwMDAwMAQ0LCw0ODRAODhAUDg4OFBQODg4OFBEMDAwMDBERDAwMDAwMEQwMDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAz/wAARCAEsASwDASIAAhEBAxEB/90ABAAT/8QBPwAAAQUBAQEB AQEAAAAAAAAAAwABAgQFBgcICQoLAQABBQEBAQEBAQAAAAAAAAABAAIDBAUGBwgJCgsQAAEEAQMC BAIFBwYIBQMMMwEAAhEDBCESMQVBUWETInGBMgYUkaGxQiMkFVLBYjM0coLRQwclklPw4fFjczUW orKDJkSTVGRFwqN0NhfSVeJl8rOEw9N14/NGJ5SkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2N0dX Z3eHl6e3x9fn9xEAAgIBAgQEAwQFBgcHBgU1AQACEQMhMRIEQVFhcSITBTKBkRShsUIjwVLR8DMk YuFygpJDUxVjczTxJQYWorKDByY1wtJEk1SjF2RFVTZ0ZeLys4TD03Xj80aUpIW0lcTU5PSltcXV 5fVWZnaGlqa2xtbm9ic3R1dnd4eXp7fH/9oADAMBAAIRAxEAPwD1VJJJJSkkkklKSSSSUpJJJJSk kkklKSSWb13ruH0TDOTknc92lNI+k93gP5P770CREEk0AvxYp5Zxx44mc5moxHVu5GTj4tLr8mxt NTBLnvIAH3rleo/4xMKpxr6bS7JI09V/sZ/Zb/OP/wCguK6v17qHWsg3Zb/YD+ioboxg/kt/e/lq qwKjl5yRNY/SO/6T1HJ/8XcWOIlzR9yf+bieHHH/AAvmm9HkfXTr+TIbc3Hae1TQCP7b97lRtz8/ KJORk22zyHPJH+bO1UmBHYFXlknL5pE/V0I8tgxfzeKEP7sQD/jPof1S6o7O6aKrXTfiwxxPJb/g n/8AfFuLz36q5pw+rVAmK8j9E/5/zZ/z16EtHlsnHjF7x9JeT+K8uMPMy4RUMn6yP1+aP+MpJJJT NBS5PqWbZlZrrGOLWM9lcGNB+dp+8t/rGScfBeWmH2exvz5/6K5hjFU5ue0B/eP7HS+HYgBLKR/U j/3TYp6h1CqNt7iB2d7h/wBJXqOv5LdLq22Dxb7T/Fqz2sUtirxy5I7SLZyYsM/mhH6DhP8AzXos XqWLlaMdtf8AuO0P/mStLkiwjUaEcFanTuruBFGUZB0ZafyP/wDJK1i5kE1PQ9+jRz8lQMsR4h1i fm+jspJJKy0lJJJJKUkkkkpSSSSSlJJJJKUkkkkp/9D1VJJJJSkkkklKSSSSUpJJJJSkkkklIcvK ow8a3KyHbKaWl73eQXj3Xes5PWeoPy7iQz6NNfZjPzWf+TXYf4yuqurox+l1uj1v0twH7rTFTf7T 9zv+trz5Z/OZSZcA2jv/AHnrv+LnIxhh+9TH6zLYx/1MQ/79IxHYgMR2Kq7k2wxWGKuxWGItWbYr JaQ5ujmmQfML07CyRlYdOQP8KxrvmR7l5ixdz9Ucj1el+kTrQ8tjyP6Rv/VK1ycqmY/vD/ouD8cx cWGGTrjlX+DN3EkklfedcD6w3bsiqgcVt3H4u/8AOVnsClnXetnXWTI3Fo+DfaPyJMWZllxTkfF2 8UODDCPYa+cvUUrGogYmYjCITVkpG2u5qC9qtPhV3oL4F1ui55tacW0y9glhPdvh/ZWquQrudRcy 5n0mGf7wutre2xjbG6teA4fAq9y2TijwneP5OfzuEQmJx+Wf/S6skkklYaikkkklKSSSSUpJJJJS kkkklP8A/9H1VJJJJSkkkklKSULba6a3W2uDK2Aue92gAGpcV5f9Zfrjl9Rz2HBsdRiYjw6iNC57 f8O//vjFFlzRxizqTsG98P8AhubnchjD0xiLnkl8sf3Y/wB6T6mksf6s/WCnrmALdGZNUNyKvB37 7f8Ag7FsKSMhICQNgtXNhnhySxZBwzgeGQUkkkixvkv13yjk/WTK19tO2pv9lo3f9PesFaf1lJP1 g6hP/ciz/qlmLHyG5yP9Yvo3JREOVwRGwxwH/MSMR2KuxHYU1km2WKwxVmFHYUWrMNli6n6l3kZG RR2exrx8Wnb/AN/XKsK3Pqrd6fWKhMCxrmH7tw/6lS4DWSJ8a/xnM+I4+Plso/qmX+J6/wDuXu0O +z0qLLf3Gl33CURUOt2+n0u8zBcA0f2iGrSmajI9gS8rijx5IR/ekI/a8ux06nk6lWGFVGORmuWW 9BOLba5E3qq16nvSYDBK56C9yYvQ3PSXRgxeV0nQ7TZ02ueWEs+4rl3uXR/Vsz08/wDGO/76p+VP 6z6Fh+IR/o4PaQdVJJJX3HUkm41K4P6z/WO3Lym04VhZj4ztzbGmC6xv+E/qM/MUeXLHHGzr2Da5 LksnNZOCHpAFymflj2e9SWH9WfrEzq1Ho3ENzqh+kbwHj/Ss/wC/rcToTE4iUTYLFnwZMGSWLIOG Uf5cUVJJJJzEpJJJJT//0vVUkkklKSSWH9buu/sbpTn1mMrImvHHgY91v/WmoSkIxMjsGTBhnmyw xYxc8h4Q8x9fvrMb7XdGw3/oaj+tPH5zx/gf6lf5/wDwi4pIuLiXOJLiZJPJJSWTkyHJIyL6DyXK Y+VwRw4/0fml1nP9KZdDonWcno3UGZlBkDS2vs9h+kw/99XsGBnY3UMSrMxXb6bm7mnuPFrv5TV4 eun+pP1l/ZWZ9jynxg5J1J4rsOjbP6jvo2Kblc/AeGXyy/5pc3478M+84/fxD9fiGoH+Vx/u/wB+ P6D6ikmTrReMfH/rfS6n6yZ7T+dZvHweBZ/35Y667/GTh+l1enLA9uTUAT/KrO0/9B1a5FZGaPDk mPE/i+h/Dcoy8ly8x/m4xP8Aeh6Jf86K7eUdhQEVhTGzIaNlhVhhVVhR2FFrTDaYVo9IuFXUsWw8 C1k/Anb/ABWWxysUWbLGP/dcD9xlGJog9i1M0OKEo/vAx+19VWL9abduBWzu+0fgHFbIIIBHB1C5 z64WADFrnWXuj/NC0+YNYpeX5vI8hHi5rGPEn/FjxOI1yK16qNeites16CUG0HqXqKsHp96TGYJy 9Dc9DL1EvSSIMnOXVfV1hb0utx/Pc534x/31cc567zp9H2fBopiCxjQfjHu/6Ss8mLmT2H5tL4qe HDCP70r/AMUf+hNhJJZvXusV9KwjYIORZLaGHu798/yGK7KQiDI7ByMWOeWcccBcpGgHJ+t/XTQw 9NxXRbYP1h4/Naf8H/Ws/wCoXEPKLfa+2x1lji97yXOceSTyVXeVl5chySMj9B2D2XI8pHlsQxx1 O85fvzXx8zIwsmvKxnbLqjua78rXfyXfnL1LonV6Or9PZl1e130ba+7Hj6TP/IryV5Wr9U+unpHV Wix0YmURXeOwP+Du/sO/6Cfy2bglR+WW/wDFj+LfDvvOAzgP1+IXH+vD9LH/AN4+qJJJLSeOUkkk kp//0/VUkkklKXkv116uep9ctax04+JNNQ7e0/pX/wBqxem9azfsHScvM701OLf60bWf9NeJkkmS ZJ5Kp87PSMO+pej/AOLPLAzy8wR8n6uH96XzqTpk6ovVBSSSSSX0n6hfWT7bjDpWU6cnHb+hcTq+ sfm/16v/AD2uvXhuJlX4eTVlY7tl1Lg5jvML2HoXWKOs9OrzKva4+22v9x4+mz/yK0OVzcUeCXzR 28YvHfH/AIb7GX7xiH6rKfUB/k8v/e5HG/xidPOT0RuU0S/DsDj/AFH/AKN//S9NeYr3LMxa8zEu xbRNd7HVu+DhtXieZi2YmVdi2iLKHurd8WnaoedhUhP94V9Q6P8AxZ5njwZOXJ9WKXHH/Z5P/Q0K mwqCcaKq9A2GOR2OVRjkdjkmGcW2xyKHaFVWuRWuRa8ovrWE7fh0P/erYfvaFzH1zs/XcdvhUT97 v/MV0PRLPU6Rhv8AGln/AFIXKfXO3/K7G/u0t/EvK0OYP6gePC8n8Nx/0+Q/c9z/AL1zGvUw9VWv Uw9UHflBtB6feqwen3pLOBOXqJeg70xekkQb/S6DmdRoo5aXhz/6rfe78i79ct9TMTcb85w/4Kv/ AKuw/wDULqVocrCsd/vG/o8/8Wy8XMcA2xDh/wAOXqkjyL6sah99ztldYLnOPgF5t1nqtvU81+S/ Rv0amfusHA/8mtb64dc+0Xfs7Hd+hpP6Zw/OePzP6tX/AFa5dzlBzWbiPAPljv4ydX4NyHtQ9/IP 1mQekfuY/wDvprPcgvcne5Be5VXdhFi9yA8qb3ILjJQbEA+sfUrqx6n0Sv1Hbr8X9Db4naP0b/7V a315v/i2zTV1W/DJ9uTVuA/lVmf+oc9ekLU5efHiiTuPSfo8L8Z5YcvzuWMRUJ/rYeWT/wBD4lJJ JKZzn//U9VSSSSU85/jAscz6s3gGN762n4bg7/vq8oC9Z+vtLrfqxk7RJrNbz8A9s/lXkwWfzn84 P7r1/wDxbI+5yrf3ZX/iwXTpklVd0LpJJJLlLd+qP1gd0XqQ9Qn7HkQzIb4fu3f9b/6hYSSMJGMh Ibhiz4IZ8U8WQXCY4T/H/Bfd2ua5oc0gtcJBHBBXnH+MbpP2fqFfUqxFeWNtkdrGD/v9f/ULV/xf fWH7TjnpGS6bqBOMTy6sc1/9a/8APf8AUXQfWPpI6v0i/DA/Skb6T4WN9zP876C0Z1nw2N9x/eHR 43ljP4X8SEch9F8E5dJ4Mny5P+7fGkk7muY4scC1zTDgeQQmWa9uyaYRWuQFJroSQRbaa5Ga5VGu RWvSYZQfWfqy7d0DBP8AwQ/Bcl9cn/5dePCqv8hXU/VMz9XcE/8AB/8AfnLj/ro+PrDcPBlf/Uq/ zH+54f4P/ReV+GR/4U5gdvd/9KuaHqQeqoeph6ou+YNkPT71W3p96S322xvTNLnvaxg3PeQ1o8Sd AEDet/6mdOOX1E5bxNOJqPA2H6H+Z9NPhEzkIjqWLmJxwYZ5ZbQF+cv0Y/4T2fS8JuBgU4o5rb7z 4uPue7/OWf8AWjrY6XhbKj+t5Etq/kj8+3+z+b/LWrlZNOJj2ZN7tlVTS57vILyzq3Vbup51mXbp uMVs/dYPoMV7mMoxwEY7kUP6sXn/AIXycub5iWbLrjgeOd/5TJL1cH/ftdz55Mk8lCc9Rc9Dc9Zz 10YLucguck5yE5yDNGKnOUEkkmV2/qZY6v6y4JaY3Pc0/BzHheuryT6k0ut+s2HtGjC57vg1jl62 tDkv5s/3nj/+M9fe8ff2hf8AjzUkkkrTgv8A/9X1VJJJJTW6jhszsDIw38X1ur+bhAK8QtqsotfT aNtlbix7T2LTtcF7wvNv8YnQTi5o6vQ39BlHbfH5toH0v+ut/wCmqvN47iJj9Hfyd7/i7zYx5p8v I0M2sP8AaQ/R/wAOLxydME6oPWhdJMnQXKSSSSSmw8u/CyqsvHdsupcHsPmF7J0bqtHV+nVZ1Onq CLGfuvH85Wf6q8VXTfUbr/7M6l9kvdGJmENdPDbOK7P++PVjlc3BPhPyy/Nx/jvw/wC88v7sB+uw AyH9fH+nD/uoM/r/ANF+w9V+21NjHzZdpwLB/Ot/t/zi5Zey/WLpDOsdKuxDHqxvod4WN+h/nfQX jljH1vdXYC17CWuaeQRoQhzWLgnY+WWv16p+A89945UQkf1uCoS/rQ/yc/8AuWKSSSgddkHQiNeg pwYSQRb6/wDVDX6tYH/Fn/qnLivru6PrJeP5FX/UrtPqh/4msD/iz/1Tlw/17MfWW/zrq/6lXuY/ 3PD/AAf+i8p8JF/F+aH+2/8AS0XID1IPVYPUg9UXpDBs70t6r70t6K3gbAc5xDWgucTDQOSTwF6l 0Dpg6X0urGI/Skb7j4vd9L/N+guL+ovSft3UTnWtmjCgt8Dafof9tt/Sf5i6/wCs/W29G6Y+9pH2 m39HjtPd5/P/AKtf01c5WIhGWWX08nnfjWWWbPj5HD6pWDP/AGkvkj/gQ9cnmvr1131rx0rHd+ip IdkEd7Pza/8ArX/VrkS9Dfa57i97i5ziS5x1JJ1JKgXqrkyGcjI9Xe5Pk4cthhij+iPVL9+f6Ukj nobnqBeoEkpjbEGTnKCSSS9SSSLjY92VkV41DS+21wYxo7kpIJABJNAakl7L/Fp04uycnqTm+2to prP8p3vs/wA1rW/569BVDofSqukdMpwa9SwTY/8AeedbHq+tbBj4MYj13Pm+f/E+b+9c3kyj5L4c f+zh6Y/43zqSSSUjSf/W7i/65dFxus29IyrPQtq2/pnfzZc4b9hf/g3N3fnrca5r2h7CHNcJDgZB B8F4R1zLdmdazslxn1L7CPhuLW/9FXehfWvrHRXAY1u/H/OxrJdWf6o/wf8A1tVhzNSIkNL0Idyf wTixQlhlWThHFCfyylXq4ZfovtaBm4ePnYtmJksFlNzdr2n/AF+k1YXQfr10fq22m132PLOnpWn2 uP8AwVv0Xf2l0inEozGhBDkZMWbl8gE4yxzibH0/SjJ8c+sn1by+g5ZY8GzFsJ+z3xo4fuP/AHbW rIXuWdgYnUMV+Jl1i2mwQWn/AKpp/Ne1eW/Wf6o5nQ7DdXN+A4+y4ctn8y+Po/11Rz8uYeqOsf8A ovV/CfjMeYAw5iI5xoDtHN5f6z+q4CdRTqq7gXSSSSXKSSSSU+q/Unr37V6WKbnTl4kMsnlzf8Fb /wB9eub/AMYfQ/suY3qtDYpyjtuA4FoH0v8ArrVgfV/rFvRuqVZjZNc7b2D86s/TH/f2r1nPw8Tr XS347iH0ZVYLLBrE+6q1v9X6SvQPv4TA/PH+UXleZifhXxKPMQH9Gz3xRHQS/nYf4H85jfFEkfOw r8DLtw8hu22lxa4fD84fyXfSQFRIo0XqYyEgJRNxkLBHUFSSSSSX2H6piPq5gf8AFA/eSuD/AMYO n1ksPjVWfwXoH1Zbt+r3Tx/wDD94lcF/jFbH1hn96is/i8fwV/mP9zx/wfyeS+DH/hfP4+9/6UeZ DinD1BJUHraSb0Siu3IuropaX22uDGNHdzjDVXXc/wCLroO97utZDfaya8UHx4tt/s/zbf7afixn JMRH18mpz/NQ5Tl55pfoioR/fyH5IvYdG6ZT0fpdWI0j9G3dbZxuefdbYV5l9auvHrHVX2MdOLTN eOP5IPus/wCuuXX/AOMDrv2LAHTaHRkZg/SEctq/O/7d+h/24vNFY5vIBWKO0d/2ByPgHJylx8/m 9WTMZe3fY/zmT/D+VkXppKZJVHolJJJJKUkki42NflXsx8et1t1hhjGiSSkgkAEk0BqSUbWue4MY C5zjDWjUknsF6Z9S/qmel1/tDOb+vWiGMP8Agmn/ANGv/PU/qp9TKekhuZm7bc8j2jltU/ufvWf8 IuoV/luW4anP5ug/deT+M/GveEuW5Y/qtsmX/O/1If6v/pqSVXqHU8DptBvzbm0s7buSfBjB7n/2 VwnXP8YmVkbqOkMOPUdDkPg2H+o36FSnyZoY/mOv7o+Zy+S+G8zzZ/VQ9HXLL044/wCF+l/gPadW 6/0vo9e7NuDXkS2lvusd/Vr/AO/OVb/nRh/83v27sPpf6GRu3b/S9Of3l5JbdbfY6257rLHmXPcS ST5uK1v2i/8A5p/s+dPtm6P5OzdH/biqjnTxE8PpA26793cl/wAWcYxQiMpOaUvVkI9AjwT9Mcf9 /gf/1+M3lzi52pcZPxKm0qfUaTjdRysciPSusZH9VzmoTSs6Qe0xTsA90oK6XoP146v0nbVY77Zi DT0bTq0f8Fb9Jv8A1C5gFTBTBKUTcTTPPFizw4MsBOJ6H/uf3X2non1p6R1poGNbsyIl2PZ7Xj+r /pP7C1rK67a3V2ND2PEOa4SCD2IK8EY97HB7HFrmmWuBgg+RXYdB/wAYmfh7aOqA5mONPVGlrR8f o3f2/wDPVrHzQOmQV49HD5z4BON5OVlxga+3I/rB/cn+k3frN/i/cwuzOiNLmcvw51H/ABBP0v8A i1w7muY4seC1zTDmkQQR2IXtfTOsdO6rR62De21v5zRo5vlZWfcxZ/1g+qPTettNhH2fMj25DBz/ AMcz/Cf9Wm5eVEhxY616fon+6ych8dyYJexzolUfT7hH62H+1j+n/wBN8jTrR6z9X+p9Fu9PMr/R kxXe3Wt3wd+9/Ics1UpRMTRFF6fFlhlgJ45CcJbSibC6SSSDIpeh/wCLrrnrY7+kXu/SUDfjzyWH 6df/AFty88Vnp2ff07OpzccxZQ4OHgR+cw/yXt9qkw5DjmJdNpeTT+JcmOb5aeL9P5sZ/dyR+X/v Xu/8YfQfXx29Yx2zbQNuSB3r/Ns/61/1H9Redr2/EycXqfT68iuLMfKrnaddHCHsd/1D15P9Z+hv 6L1R+OAfs9nvxnnuw/mz+9X9BT83i1GSO0t/4uV/xe54mMuSzaZMN+3xb8A+fH/exuQkkkqj0L7Z 0ZmzpGE3wx6h/wBBq4L/ABlsjrGO/wDexx+D3r0PCZsw6Gcba2D7mhcF/jOZGdgv8anj7nf+ZLR5 kfqPLheL+Bzv4oD+/wC7+Rk8Ukkks57RvdG6Vf1bqNODTp6hl7/3WD+cs/stXr4GF0jpukVYmHX9 zWj/AKpyw/qN0D9mdO+13tjMzAHOB5ZXzXX/AGvpvWX/AIx+twK+jUO5i3Kjw/wVX/oz/ttXsURg wnJL5pfyjF5TnssvinxCHKYj+oxE8Uh/V/nsv/qPG8f1fqd3Veo3Z130rXe1v7rRpXWP6rVSSSVE kkkncvUwhGEYwgOGMAIxA6RipJJJJcpJSYx9jwxjS97jDWtEknyAXZ/V7/F9dftyuszTVy3FGjz/ AMa7/B/1f5z+on48cshqIv8AJrc3zuDlYceaYj+7Hec/7kXneifV7qXWrvTxGRU0xZe7Rjf7X5zv 5DV6d0H6tdP6HTFDfUyHCLch30j/ACW/6Ov+QtLHx8bDobTQxtNFY0a0Q0ALmuu/X7p2BuowIzck aSD+iaf5Vg/nP+tq9DFjwDimRxd/+9Dy3M89zvxXJ7PLwlHD+5H/AKWfI9NkZFGNS6/IsbVUwS57 yAB8yuL67/jFrZuo6Mz1HcHJsHtH/FV/nf8AXFx3VeudT6vb6mdcXgfRrGjG/wBSsKgoMvOSOkPS O/6Tp8h/xcxY6nzR96f+bH8zHz/zifMzszOvN+Zc6+0/nPM/Jv7qAkkqpJOpd6MYxAjECMRoANAF Iu532Xb+b6k/OEJaH2R37A+2R7ftfpT/ANb3ogbolIAxHc0P8WRf/9DN/wAYfT3YX1oyXR+jyw3I Yf6w22f+CseucaV6t/jO6G7O6SzqVLZu6eSXxyanfzn/AG273/8Abi8nVLNGpnx1el+H5/c5eBv1 QHBL/BTNKmCgtKICoSHUxzSgqQKGCpAphDZjJtYmZlYd7cjFtdTa3h7DBXddB/xkNdtx+tM2ngZV Y0/67UP+qr/7bXnoKkCnQyzxn0n6dGLmuR5fm41lhZ/RnH05I+Un3ScHqWJp6eVi3DyexwXFdf8A 8XRG7J6K6RycR5/882u/6iz/ALcXIdJ671Po93q4NxYD9Oo6sd/XrXonQfr70zqW2jMjCyjoA4/o 3H+RYfo/1bFZGTFmHDMcMv5fLJw5cl8Q+GSOXlZHNh3lGr0/1uH/ANSY3zK+i/GtdTkVuqtYYcx4 IIPwKgvaOrdC6X1mn082oPIHstbo9v8AUsXnvXfqH1Ppu6/EnNxRrLB+kaP5dX53/W1Bl5WcNR6o +G7qch8d5fmKhk/UZf3ZH9XL+5P/AL55lJLUGDoQkq7sPdf4uOtbX2dHudo6bcafH/C1j/z5/wBu LpfrV0JvWulvqaB9qpl+M7+UP8H/AFbforybDy7sPKqyqDttpeHsPmCvaOmZ9PUsCjOp+hewOjwP D2f2H+1X+WkMmM4pa1/0f/QXlPjmCfKc3j57D6eM2f6ueP8A6th/6kfE3sfW9zHgte0lrmnQgjkF Sx2b8ipn7z2j7yuy/wAYX1e9K39s4rf0dpDcpo7P4bd/1z6L/wCWuW6LV63WMKr9++sH/Oaqk8Zh k4D30eg5bnYcxyn3iGnpJnH9ycB64vtQECPBcP8A4z6/0XT7PB1rfvFZ/gu5XH/4zKt3Sca39y+P 85rv/ILQ5kXhn5PHfBZcPxHAe8pR/wAaEovm66X6j/V/9qdR+1XtnDxCHOnh7+a6v+/2LCwMHI6h mVYeM3dbc4NaOw8XO/ktb7l7H0jpdHSun1YNA9tY9zu7nn6djv6zlT5XDxy4j8sfxL0nx34j92we 1jP67MKHfHj/AEp/9zBJ1LPp6dg3Zt383QwuI8T+awf13e1eL5uZdnZd2Xed1t7i9x+PYf1V2P8A jH61vtq6PS721xbkR3cR+iZ/Zb71w6PN5eKfANo/9JZ/xe5L2eXOeY/WZ9R/Vwj5f8f51JJK503p PUOqX+hg0utd+cRo1o8XvPtYqwBJoCy7U5xhEynIRjHUykeGI+rTWz0P6q9U604OpZ6WNPuybBDf 7H+ld/VXYdC/xfYWHtv6oRl3jUVD+aafP863+17F0XUOqdN6RjC3LtbRWBDGDkx+bVW36St4+U04 sp4R2/iXA5z/AIwXL2eRgc2SXpGSrjf+rx/ptPoX1V6X0VodSz1sqIdk2CXf9b/0Tf6qbrn1r6V0 YFlr/Wyu2PXq7/rh+jV/aXHde/xgZ+duo6aDh450Nk/pXD+sP5r+x/nrkyS4lzjJOpJ5JTp81GA4 cIHn0YuW+BZ+Yn7/AMQySJlr7d3P/Dn/AJOP9TG7XXPrb1XrJNb3+hinjHrJAI/4V30rViJJKnKU pG5Gy9FhwYsMBjxQGOA/RipJJJBkUkkmSQpeg/sN/wD43fp7T6237bEa87//AG3XH/V/pNnV+rUY TR7HHdc7wrbrYf8Avq9l9Kv0vS2j09uzZ22xt2qaEP1WSflEf40XN5nmh9/5PlgdScmWfkMOWMP+ 7f/R9TexljHV2NDmPBa5p1BB0c0rxT64/Vm3oHVHMY0nByCX4tnOnelx/fqXtqoda6NhdawLMHNb Nb9WvH0mOH0bKz+81MyY+MeI2bXJc2eXyWdYS0mP+6fAwVNpWl9Yvq31DoGYcfKbuqcT6GQ0ex48 v3X/AL9aygYVKUSDRelxZYyAlE8UTsQmBUwUFpRAUwhtwmlBTgoYKkCmENiMkgKdQBUgU2mUSei6 B9dOq9ILanu+1YY09Gw6tH/A2fSZ/wBQvRui/WTpfWq5xLYuAl+O/Sxv9n89v8ti8YlTputpsbbS 91djDLXtJBB8nBTYuZnDQ+qPY/sc3nvg3L81c4j2cx/TiPTL/aQfW+t/U/pHWN1jmfZ8o/8AaioA En/hGfRsXn/W/qh1jo82Pr9fGH+HqkgD/hG/SrW59X/8Ytle3G60PUZwMpg9w/46sfT/AK7F3eNk 42ZQ2/GsbdS8aPYQQVYMMOcXH0y/H/Ci5Eea+JfCpDHmHu4No8Xqxkf6rL+h/c/5j4au4/xb9Z22 W9Hud7Xzbjz+8P51n9pvvW31v6i9I6lutxx9iyTrvrHsJ/l0/R/zNi4nK6F176s51Waai9mO8PZk V+6swfz/AM6vd/wigGPJgmJ1cRuY/uupLneT+KctPlxL280hcIZPTL3Y/JwS/TfVsjHpyqLMe9of Va0se08EFebYPQL+lfXbEwny6sW+rRYfzq2h1jT/AFm7Nr16Pg5dWdh05lP83ewPb8xwiOppfYy1 zGusrn03kAubu+lsd+buVzJijk4ZfukSB/qvOcnz2XkxnxEExywnjlA/oZa4Iz/wf0ma5r/GFUbP q493+itrefv9P/0YulULqab6zVcxtlbvpMeA4GNfouT5x4oSj3FNflc/scxizVxe3OM6/eEejyv1 D+rn2DE/aWUyMrKb+jaRqyo6/wCfb9JdJ1LPp6dg35tx9lDC6PE/ms/tu9qsriP8YOdk5NuP0LCY +2x8XXMYC4n82pvt/tPUcqw4vT00H9aRbeL3PiXPg5TQmeLJr6cWDHvH/F9LwmZlXZmVblXndbc8 vefMlLEw8rMuFGLU6613DGCSuv6L/i5yLdt3V7PQZz9nrILz/Xs+hX/Z3ruOn9L6f0yn0cGhtLO8 D3Hze8+96qY+UnPWfpB/xnoOc+P8ry49vlwM04jhHDpghX9f9L/AeO6J/i4Ptv6zZ5jGqP8A59t/ 9J/9uLtKaMHpuLspZXi41QkxDWgfvOd/5JZfXvrd0vozTW532jL7Y9ZEg/8ACu/wX/Vrzjrf1l6p 1p/61ZtoBlmOzRg+X57v5T1MZ4cAqA4p/wAvmk5uPlfiPxWQyZ5nFy+4scMP+o4f0v8AaTet69/j Epp3Y/Rmi6zg5Lx7B/xbP8J/a9i4TMzcvOvORl2uutdy55n5D91ASVTJmnkPqOnbo9FyXw7luUjW KHqPzZJerJL/AAlJJJKNuKSSSSQpJMkkq1JAEkACSdAAkASQAJJ0AC9B+pf1MdjuZ1TqjIuHux8d 35n/AAto/wBJ+4z8xSYsUskqH1PZp89z2LlMRyZDr+hD9LJLsHU+pP1cPR8A35LYzsoA2A8sZ+ZT /wB+sXSJJLS9qPt+3+jVPE/f8/3v73f63i4v6tfL7f8Ac4PQ/wD/0vVUkkklNbqHTsLqWK/Ezqm3 0P5Y7x/eafzHt/eavNPrF/iyz8RzsjoxOZj8+g6Bc0fyeG3f+fF6okmTxxlv9rY5fm8uA+g+nrA/ KX53tqux7DVex1VjdHMeC1w+LXJBy99z+k9M6kz08/GryG9t7QSP6r/ptXOZn+LH6t3kuo9bEceB W/c0f2bhZ/1Sgly8uhBdbD8Zxf5SMoHw9cXygFTBXojv8U2HPs6jYB51tP8A35qQ/wAU+P8A+WT/ APtof+lFGeXydvxbsfjPJ9ch/wAWf/evnoKkCvQf/Gpo/wDLJ/8A20P/AEqn/wDGqx//ACxf/wBt D/0om/dsv7v4hlHxvkf86f8AEyf96+fAp5XoP/jV4/8A5Yv/AO2h/wClE4/xWY//AJYv/wC2h/6U Q+65f3fxDIPjvIf50/4mT/vXz6Vo9H691Lo1/q4VpaD9Op2rHf12f9+XYf8AjW43/lg//tsf+TT/ APjXYv8A5YWf9tj/AMmkOWzA2BR80T+NfDMkTDJPjhLQxljmR/0XY+r31z6b1kNpsIxc0/4F50cf +Bf+d/U+mugIDgQRIOhBXED/ABX4oMjqFkjgisf+TXXdNw7MLBqxbb35T6hHrWfScJ03f1foq5iO WqyR/wAJ5vn4ciJcfJ5SQTrilGY4PGM5/othrGsaGMAa1ugaBAAUkklK0FJJJJKUo7Gb9+0byI3R rHhKkkkpBmZuJg0Oycu1tNLOXOMfIfvOXn31h/xg5WXuxukzjY50N5/nXf1P9C3/AMEXR9e+po63 mnJvz7WMAAro2hzGQIds1b9JZv8A42GJ/wBz7P8Attv/AJJVs3vyuMBwx736pO38NPwnCI5eZyHL m34Djn7WI/4v6yT585xcS5xJJ1JPJKS9B/8AGwxP+59n/bbf/JJf+Nhif9z7P+22/wDklV+65v3f xDu/6f8Ah3+dP/heT/vXz5Jeg/8AjYYn/c+z/Mb/AOSS/wDGvxP+59n/AG23/wAkl91zfu/iFf6f +Hf50/4mT/vXz1Jehf8AjX4n/c+z/ttv/kkv/GvxP+59n+Y3/wAkl91zfu/iFf6f+H/50/4mT/vX z1Jehf8AjX4f/c63/Mb/AHo1P+LLpLHTdk32j90bW/8AfXI/dMvYfatP/GD4eBpkkfAQm+bLT6T9 XOsdXeBiY7vTPN7/AG1j+276X9henYH1Q+r2AQ6rDY94/Ptmw/8Agkt/6K2AABAEAcAKWHJfvy+k f4ufzP8AxmFEcviN/v5f/VcP+/ec+rv1J6f0ctyLiMrNGoscPaw/8Cz/ANGOXSJJK3GEYCoig89n 5jLzEzkzTM5HqfyiP0VJJJJzE//T9VSSSSUpZHXfrR0zoBqHUPVaLwfTcxhc0lv0m7v3tVrrL+sn Qsfr3SrcG2GvPuot/csH0H/99f8AyEJXRrdkxe37kfcvgv1cO7iO/wAaP1YHAyHfCsfxehu/xq/V 0cU5Lv7DP/Sq8tzcLJwMu3DymGu+hxZY0+I/76781AVU55+Dtj4XypAI4iD/AFn1R3+Nnog+jiZL viGD/wBGIR/xtdP/ADen3H4vaP8AyS8wSS9+ff8ABePhfKjeJP8AhSfTD/jax/zemvPxtA/9FqB/ xsH83pv32/8AqJecBymHJpzZP3vwDND4ZyX+av8Awp/989+7/GtmH6GBUPjY4/8AfWqJ/wAafUzx h0D4l5/78uEDlIFMObL+82I/DOR/zI+2f/fPbO/xodaP0cbGHyef/RiC7/GV9YXfRbjs+DCf+qsK 5EEkwNSeAuy+rX+L7MztmV1Xdi4pgtp4tePP/Qs/rfpEozzTNRkUZuX+GctDjy4scR0BHFKXhGLZ 6R9aPrt1vI9DBFUD+ctNYDGD+W87v81eiViwVtFhDrABvIEAuj3FoQsLBxMDHbjYdTaaWcMaI+Z/ ecjq5jhKI9UjInu83zvM4s0x7OGGDHH5REeuXjkkpJJJSNRSSSSSlJJJJKcH60X/AFmxam5PRRXZ VW0+vUW7rP67B+c3+S1cYP8AGL9YmmHCgkcg1n+DwvUVzf1j+pXT+sB2RRGLnHX1Wj2vP/DMH/nz 6agzY8h9WOZH9W/+i63w3nOSiBi5vl4Sj0z8NzH+1/e/vPMN/wAZnWh9KjGd/ZeP/RimP8Z3VO+J QfhvH/flzPVekdR6TkehnUmt35ruWOH71b/ouVKVTObMDRkQfF6OPwz4bkiJxw45RlqJRJ4T/iye 3H+NDO/Owaj8HuH96K3/ABo2fn9PHytP/pNcHKUpfeM3734BB+DfDj/kB9JZP+/fQG/40qvzunO+ Vo/9JqY/xo4f52BYPg9p/wC+hedylKP3nN+9+AWH4H8P/wA0R/h5P++fSW/4z+lH6eJePhsP/f2o jf8AGZ0I805A/ss/9KLzGUpTvvWXuPsYz8C5DpGQ/wAMvqQ/xk/V48tyB/YH/k0Rn+MX6tuIAddJ 0A9Mkk/2SV5RK7P/ABe/Vk5eQOsZbP1bHd+rtP59g/P/AKlP/nxPx58s5CIr7Gpzfwn4fy+GWWZy AR2HH88v0Yj0vpLHbmh0Fu4AwdCJ8VJJJXXmVJJJJKf/1PVUkkklKSSSSU8r9d/qbX13H+14gDOp 0thp4FrR/gbD+9/onryG+i7HufRex1V1ZLX1uEOBHZwX0Que+tH1M6b9YGeq79XzmiGZLRzH0WXN /wAIz/pqHLi4tY7/AJulyPxD2qx5dcf6MusP/QXxRJbHW/qn1vojz9roLqAfbk1y6sj+t/g/+uLH VYgg0RTtwnGcRKEhIHqFJwUyudN6R1Pql3o9Pxn5D+5aPaP69h9jP7SFWuMhEWSIgdS1g5avRPq/ 1Xrd3p4NJcwGH3u0rZ/Xs/7433rs/q//AIraai3I65Z6zxr9lqJDP+u26Of/ANbXeY+Nj4tLaMat tNNYhlbAGtA+AU0OXJ1loO3Vz+Y+MxgDHCOOX75+Qf8AfPP/AFc+o3TOiht9oGXnDX1nj2tP/A1/ m/1/prpUklZjERFAU4mbNkzTM8kjOR7/ALFJJJIsakkkklKSSSSUpJJJJSkkkklNfO6fh9Qx3Y2Z U26p3LXDg/vNP0mO/qrzz6w/4vMzE3ZPSS7Kx+TQf51o/k/6b/z4vS0lHkwwyDUa9+rc5P4hzHKS vHK4H5sctccv+9fA3BzHFrgWuaYIOhBTSvY+u/VLpHWwX31+lkxpk1QH/wBv823+2vPOt/UXrfSy 6ytn23GH+FpBLgP+Ep+m3/pqlk5acNR6h3D03J/GeX5gCMj7WT9yZ0/wJvPSlKiTBg6EchNKip0D NlKaU9NV2RYKqK3W2O0axgLnH+y1dr9Xf8W+Ve5uT1sminkYzT+kd/xjh/NN/wDBP6ifDFKZoBrc zzuHl48WWYHaP6cv7sXJ+qf1UyevZIssDq+nVH9Ndxuj/A1fy/8Az2vXMfHpxaGY+OwV01NDWMbo AAmxsajFoZj41baqaxtZW0QAEVX8WIYx3J3LyfP8/k5vJZ9OOPyQ/wC6l/XUkkkpGkpJJJJT/9X1 VJJJJSkkkklKSSSSUsQCCCJB5BWVl/VT6uZji/I6dQ57uXNbsJ/tVbFrJIEA7i10ZyibjIx/unhc Oj6k/VWgyzp1Tj/L3P8Awsc9bFNFNFYrorbVWOGMAaB/ZaiJJAAbABM8k5/PKUv7x4lJJJIrFJJJ JKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpz876v9F6i7dmYdVr/3y2Hf9uM2vVGv6jfV at24YDXHwc57h/muet5JNMInUxH2MseZzxHDHLOMewnIBrYfTsDBZsw8evHb4VtDfv2qykknVTGZ GRskknqVJJJJIUkkkkpSSSSSn//W9VSXjjv8dvXA4j9n4uhjmz/ya7v6gfWvL+tPS783LprofTea mtq3QQGsfuO8u/fSU9QkkkkpSS4j/GD9fM/6qZWHTiY1OQ3KY97jbukFpa327HN/eWH9Xf8AG31f q3XMLptuFj115dzanvaX7gHd27nJKfU0kLKtNONbc0Sa2OeAeCWguXkP/j3dc/8AK/F++z/yaSn2 NJc99RvrJk/WXoY6nlVMosNr69lc7YZt195d+8uhSUpJJeafW/8AxpdV6B9YcrpWPh49tWPs22PL 9x31stO7a4N/PSU+lpLz/wCon+MfqX1n6y/p2Vi0UVtodbvrL90tcxu33ud++vQElKSSXIf4wPr0 76qVYteLVXkZmUS707CYbU3QvOyPpP8Aaz+2kp69JeOf+Pd1z/yvxfvs/wDJr0n6o/WKv6ydCo6m 1oZa6WZFTdQyxv026/8AbjP5D0lO0kkvKuvf42PrD0brGX0y3AxS7FscwO/SDc3mqz6f59e16Sn1 VJcD9Qv8ZOT9Zuq29NzserGeKjbQai73FpHqMPqOd+a7eu+SUpJJeZfWv/Gzn9G6/l9MwcSi+nFc GepYX7i/a02j2Oa32POxJT6akvHWf47us727+n42yRug2TH5233r17HvryKK8io7q7mNsYfFrhua kpIkksL66fWQ/VroNvUmMbbfvZXRU8kNc5x77fd7aw96SndSXjn/AI93XP8Ayvxfvs/8mvV+j5GZ ldKxMrOrbTlX1NstqZO1pcN+z3S72ykpuJLO611/pHQsb7T1TJbjsM7GnV7yPzaqm++z+yuB6l/j uxGOczpnTn3AH22XvFYP/Wqxb/58SU+npLxw/wCO7rU+3p2MB5mw/wDfkv8Ax7uuf+V+L99n/k0l PsaS8p6J/jf6x1LrGF0+zBxmV5d9dL3tL5Ae4MLmy7zXqySlJLyPP/xzdaxc7Jxm4GM5tFr62uJs khjiyT7/ACQP/Hu65/5X4v32f+TSU//X8rf9N3xK9m/xKf8AidzP/DZ/891Lxl/03fEr1b/FJ1/o nTOhZVPUM6jFtflFzWWvDSW7Kxuh3wSU+ppLF/55/VP/AMt8T/t1v96X/PP6p/8Alvif9ut/vSU+ d/48P+UOlf8AE2/9Uxch9Rf/ABYdI/8ADLPyrpP8cHV+l9Uzumv6dlVZba6rBYaXB4aS5sbtq5v6 i/8Aiw6R/wCGWflSU/QvUP8Ak/J/4mz/AKly+XV9RdQ/5Pyf+Js/6ly+XUlPuf8Aie/8Rzf/AAzb /wB8XbriP8T3/iOb/wCGbf8Avi7dJSl8/wD+NH/xcdR/6z/55qX0Avn/APxo/wDi46j/ANZ/881J KdL/ABM/+Ku3/wAKWf8AV1L25eI/4mf/ABV2/wDhSz/q6l7ckpZzmtaXOIDWiSTwAF85fXXr5+sH 1jys9pJxw70sUeFTPaz/ALc/nf8Ari9b/wAan1h/ZH1afjUu25XUyaK4Oorj9Zs/zP0X/XV4n0np t/Vep4vTsf8AncqxtbT4bj7n/wBhvvSUtldMzMTFxMu+vZTnsdZju/eaxxqf/wBJq7b/ABPfWH7B 1qzo97ox+pD9FPAvYJZ/27XvZ/20ux/xi/VOjI+pbKsKuH9EYH44A19Jjdl7P+2m+r/1peJY2Rdi 5FWTQ4supe2yt45Dmnc13+ckp+pl4/8A46ei+j1LE61WPZls9C4/8JXrWf7dTv8AwJem/VvrNXXe iYnVKoH2hgNjR+bYPZcz+zY1yz/8YHRf2z9Vc3Ha3ddS37RR476vfA/4yv1K/wC2kp8N+q3Vj0b6 w4PUZhlNrfV863fo7h/209y+lAQ4BzTIOoI4IXysvof/ABfdX/a/1Twb3GbaWfZrv61X6P8A6dfp 2JKd3Lya8TEuyrdK8et1r/6rAXu/6lfMOdl2ZubfmWmbMix9rz5vJefyr3f/ABo9U/Z/1PymtMWZ pbis+Dzut/8AAWWLwrpuFZn9QxsGoTZk2sqb8XuDP4pKa697/wAVvVx1L6o41bjNuATivHeGe6n/ AMBexeY/4z+h19H+tDxQz08XKqZdS0CAIHo2NH/XKt39tbH+Jbq/2frOV0l7oZm1epWCdPUq8P61 T3/9tpKfZV5L/jt6sH5OB0dh0qa7JtHm79FT/wBFtq9aXzj9durftj60dQzQ7dV6prpPI9Or9DXH 9bZvSUw+p3Rz1r6y4GARuqfaH3d/0df6W2f6zWbF9CdY6pjdH6Xk9SydKcWsvLRoSR9Ctv8AKsf7 GrzP/En0fdbndasbowDFoPmYtv8A+j6K1v8AHT1B1H1fxcFhj7ZkS/zZU3ft/wC3H1JKfKev9e6h 1/qVvUc95dZYfYz82tn5lVTfzWNV/wCqn1H6z9aLHHDDacWo7bcq2QwH9xm33W2fyVz698+qvW/q l0j6u4GA3qmIx1dLTaDawH1Hj1Li7X6XqOckp5qv/EbVtHq9Xdu77aBH/SuUv/GNxv8Ay3f/ANsD /wBLLuf+eH1V/wDLbE/7eZ/5JL/nh9Vf/LbE/wC3mf8AkklPI9J/xO4/TOqYnUW9UfYcS5lwrNIG 7Y4P2bvVdt3QvRllUfWr6t5FzKKOp4tl1rgyuttrS5zjo1rWg/nLVSU/MPWv+Wc//wAM3f8AVuVN XOtf8s5//hm7/q3Kmkp//9Dyt/03fEo2P0/PymF+NjW3sBgurY54B8JYCgv+m74lezf4lP8AxO5n /hs/+e6klPkn7F6x/wBwMn/tl/8A5FL9i9Y/7gZP/bL/APyK+nkklPy1kYeXiloyaLKC7VosY5kg fu7w1bH1F/8AFh0j/wAMs/Kuv/x4f8odK/4m3/qmLkPqL/4sOkf+GWflSU/QvUP+T8n/AImz/qXL 5dX1Jl1mzEurHL63N+8EL5bcC0lp0IMFJT7n/ie/8Rzf/DNv/fF264D/ABMZdVv1YvxQR6uPkuL2 9w2xrHMd/a2vXfpKUvn/APxo/wDi46j/ANZ/881L6AXzv/jDy68z659UtqO5jbRVI8amMof/ANOt JTtf4mf/ABV2/wDhSz/q6l7cvFv8StDn/WTKu/NqxHA/Fz6o/wCpXon+MH6xfsD6tZF9btuXkfq+ L473j3WD/ia99iSnyP8AxkfWL9u/WW41O3YeF+r40cHaf0to/wCNt/8AA/TWz/ifwMEdTyOs511V QxG+ljC17Wk2WD9JY0PP5lXt/wCurz1LafApKfp1/VujPaWPzcZzXAhwNrIIPI+kvnb60dKq6R13 LwaLG247Hl2PYxwcDW/31e5n5zWu2PWXtPgUoPgkp9N/xMfWI1ZWR9X73ezIm/Fns9o/TsH9esb/ APrS9cIBEHhfL/TOoZHTOoY/UMY7bsWxtjPPafon+S/6K+luldRx+q9Nxuo4xmnKrbYzykasP8pj vY5JT89/XTop6J9Zc7ADdtIsNmP/AMVZ+kq/zN3prtP8SfWNmVndFsdpc0ZNIP7zP0d0f1mOr/7b Vn/HZ0XdVg9brbqwnFyHDwM245P9r1lwH1O6uejfWXAz521stDLv+Ls/RW/9B6SntP8AHb1Tfm9P 6Sw6UsdkWj+VYfTrn+xW/wDz1i/4pul/b/rdVe5s14Fb8h08bv5qr/p27/7Cy/r71QdV+tnUclrg +ptvo1OHBZV+haW/1tm9ehf4k+mel0rO6m4e7JuFLD/IqG4x/wBcu/6CSmf+OnpPr9FxeqMbL8K3 07Hd/Tt0/wDPzK/89eWfVzqruj9dwepDjGua5/mwnZcP+2nPX0P9Y+lt6v0LO6aRJyKXNZ5PA3VH /t1rF80PY5jix42uaSHA8ghJT9IfWzrDOlfVjO6kxw3NpPoHxfZ+jo/6b2r5uXc/Wb62/tD6gdD6 aLJyC5zcsTrGL+ho3/8AGtsZZ/YWB9TejnrX1lwMAjdU60Pu/wCLr/S2/wCc1mxJT7j9ROj/ALG+ q2BiOEWvr9a/+vb+ld/mbvTXF/48Z9PpH7s3/fFK9SAAEDhef/45+mvyPq9jZzBJwb/f5MtHpl3/ AG62lJT4srjei9YcA5uDklpEgil5BB/sqmvpH6n9Vo6t9Wun5dLg79Cyu0TJbZWBXax39pqSn57/ AGJ1n/uBk/8AbNn/AJBL9idZ/wC4GT/2zZ/5BfTqSSn53+qnSOrVfWfpVlmFkMYzLpLnOqeAAHt9 znFq+iEkklPzD1r/AJZz/wDwzd/1blTVzrX/ACzn/wDhm7/q3Kmkp//R8rf9N3xK9m/xKf8AidzP /DZ/891Lyp3/ADe3Gftkyf8ARL1v/E99i/YOX9j9X0/tRn1tsz6dX0fT/NSU96kkkkp8h/x4f8od K/4m3/qmLkPqL/4sOkf+GWflXc/45f2b9v6b9t9efSs2ejsiNzfpeouU+pf7E/519K9D7V6v2lmz f6e2Z/O2+5JT7+vn76//AFRzPq91m60Vl3Tcqx1mLeBLRuO80PP5tlX/AE2L6BVTqv7L/Z937X9H 7Bt/T/aNvpx/K9T2pKfnb6t/Wfqv1azvtnTnj3jbdS8TXY392xoLf7L2r0Cj/HizYPtHSDv7mu7T 7n1LmPrR/wCNt67/ANi/bd8mfSj0P7H2r9OuSs9PefS3bO26J/BJT6J1r/HP1XLx30dLxGYBeC03 uf6tgB/0XtrYx/8AK968699j+77Hn4kk/wDVOcrWD+yd4/aH2jZ39DZP/gq9Y/xff+Np69f7Kn9q 6bPt/wDPT/wH/afd/wAR+kSU3v8AFV9U8noXS7s7PYas3qBafSd9JlTZ9Nr/AN2x7n73tXDf42vr F+1PrD+z6XTi9LBq04NzoOQ7+zDaf+tr23K9b7Nd6H89sd6XH0oOz6Xt+kvm7I/Ynr2faPtvr73e ru9Pdvn37v5W5JTsf4sugjrP1poNrd2Ngj7VcDqCWEeiz+1cWf2F719no/0bP80Lz7/E3+xfsHUf sHqfafVZ6/rbd2zafQ2+n+Zu9ZeipKR/Z6P9Gz/NCqdV6PhdU6bk9PuraK8mt1ZcAJBI9r2/ymO9 6vpJKflzOw78DNvwshu27GsdVYP5TTtK9T/xMfWL1MfI+r97vdTORiz3Y4/p6x/Us/Sf9cXP/wCM z/m5/wA7sqfX9fbX9p9HZs9TaP3/AM70/T3qn9RvsP8Azr6d+yvtf2r1R9L09vpwftHqR/g/Q9RJ T7N9aujt639X83ppEvuqJp8rG/pKT/241q+bHNcxxY4FrmmHA6EEL6pXz39a/wDmz/zk6l6X2rb9 psn0/T2bt36X093u2erv2pKeZX0f9Sul/sr6rdOwy3bYKRZaO++39PZ/0rF4Pg/82ftuP632v0vV Z6m70427hu3R+btX0k3btG36MaR4JKXXzz/jD6T+yvrdn0taG1Xv+01Acbbf0hj+rZ6jF9DLyj/H J+xP2n0/7X632r0Hz6Oz+b3fo9/qfy/VSU+WL1L/ABJ9HmzP61Y3RoGLQSO5i2+P/AV59/2Pf93P /Al7f/iy/Zv/ADQxP2du9PdZ6vqRv9Te7f6mz2/R2f8AW0lPVKt1Lp+N1PAv6flt34+Sw12DvDhy 3+U36TVZSSU/OH1q+qnUvqz1B2NlsLsdxJxsoD2WN+P5tn+krQ/q/wDWvrn1ctc/peQa2Wa2UuG+ txHd1bvzv5bPevoTrf7F/Ztv7c9H7BH6T7RGzy+l+f8AubPevFPrD/42Pru/ZX7QmTPo7fR/sfa/ 06SnRZ/jq+srWgPxcN5/e22D/wBHJ/8Ax6/rH/3Dw/8ANs/9LLjj/wA3Z0+2R/1pL/se/wC7n/gS Snv+hf43evdS6zg9PuxMVtWVfXS9zRZuDXuDHFs2u92q9aXz19Vf2H/zm6V6P2v1ftdOzd6e2d7Y 3R+avoVJT8w9a/5Zz/8Awzd/1blTW51f9gftbN3/AGvf9ot3R6cTvdMKp/2Pf93P/AklP//ZUEsD BBQABgAIAAAAIQAf+x7m/QUAAA8RAAARAAAAd29yZC9zZXR0aW5ncy54bWycWFlz2zYQfu9M/4OG z1UE8CYncoZn7Y6TeqKkfYZISGJNEhwQsqz8+i54RJGzzmTiF4N7fNgT3vXbd89NvXjisq9Euzbo G2IseFuIsmr3a+Pzp3zpG4tesbZktWj52jjz3nh38/tvb09hz5UCsX4BEG0firVxlG3YFwfesH7Z VIUUvdipZSGaUOx2VcGnX8akIdfGQakuXK0mpTei4y2g7YRsmOrfCLlfjZqpKI4Nb9XKJMRdSV4z BQb3h6rrZ7TmV9HgqsMM8vQjJ56aepY7UfIjycndk5DlV42fMU8rdFIUvO8hsk09utuwqp1h+vpn cMZ43ldbyeT5G5AbSNsXIZrFKey4LCCgkHNCjJVmlOKDUGnVdzU7P7A9j8UR0i4r3g/sLdgGdZJq qc1RSs295Qxor7JzIdTEBq/EbqOY4nB33/G6HiqsqDkD307hXrKmYVARI2WA7NW55g+s5flQD3lV AxrIPjEIgpUTOtnNd+xYq09su1Gim/m2Obsl2Qnu+lNW5T9cqqpg9aZjBZBmUeq4E9Lo/K2Q1RfR KlanF90MmuQ8a8zQo/wM+5q0OaIXByZZAS5M1ydwhRT1jAlt0klI/MOxLdRxqO9R71DKzYF1PB39 7G/eirDXhHIiLJ5C/gyZ5GWloFu7qmzY89rwaWBrhNUp/B7iFO4gOS3k50Hq5M9fYE1Vro3lFNsX 5MFvwJvJoy5vywvQ9PEC55o6w1wpav+Z0rb0kB6d88/3Y2WxmrUF30DGah6fFU/FcTue/q1KdRiE huK95+yJx6x47GvWHyL9Yg3MY/1JsmpI+0gYpLPnDt61zaHaqY9cwds1yLLyv2Ov7quW3/Jqf1B3 LRRWPeH0PM/u2VkcFchCHC42wwNaQmZOoT58hNDOaSXE9x1CsjGXmnvhEMtNXA/leCTNY5QTu5Y7 ZecFWmJHr+jkJE+HWhjtu1hALRKZKXYPtb08ilBOTBNv6oBrC2hsmY6P6iSmm0198EIn8Zw0wHRM y/TNqTOvdUzXJSnOSbwkQmNtUWJaaEQtG+5Bs2BFVpyjnlqRTUzUauDkKeqpFTuOj1sQO5GD5tRK SBbjaLkTmw4WN5sQj+Ac30xzNKe2D1FAbbMDM7NQT+3IIwS1DeqdxmjcHNN2vByz2vFcx0Yr0SWW T9GqcqlrmmjcgG5StA7cwEwc1B83sQMbrQMvpmaOcxLiuug9Xuq5Ns7JbCdD0XxqU4pmzjdtEqEx 8C2H4Fb7ju0laNe//iIBB8oXy48f2y5JUE7mOBluW04838J0goD4Flo7QezC84LpQMtFLqoTRcS1 0XqLMupbaIXEnhv4aB3EgWPh9RbH1Me7JIaaomj/JJTQALU60WWA5icJiIdXSBJYHm5bEkHXo/lJ Mjem6GuZ5PAHCM1cSu3oFU5kRiaa04zAD1q9mWUFAdr1GRQVXjuZZ9IIvye1aIL6k2WUWGgMcnh1 PBQthzfRRN/EPPFMC70nzzwaoHHLc4j10D8wHeg/WjATNKHeMPSoNJ5ymPsWzTjFJqzZyoot3usd BGaKJtzKx7hqZ/6Wwy7Ev+VsjtuZuVyOjL5hdZ3DbDkzYP0YOSUMqDA2DsD1eyb3F+ShXZpQolSY LP/6iqbXBC7/hIG/G1FPknV3bQnk+UJqj+3XhFULs1Mz0/vjdjNrtbCKfMM6tuXfT1IDri4BOoUK tkeY/QCFXQZ03i4/b/SWwFmvor5ia+PLYZl80NowhNVyo5dO/p513TjWb/d0bdR6fKNaTcEXbDKP w8d2b048c+DBl+YNH6zQzoL0dNAC4xGkpsOFZs0060KzZ5p9oTkzzbnQ3JnmatrhDOsYbESPsNzN R03fiboWJ17ezsS18R1pDMIw0d61RX0sOZRIKYr+rtX71ri8DfvCry4Q07oBayEMvlfLhl5F9LbR XVEXJVOQouHRE6Hke106Sk/RV2JaGaINW1XLT7CHGgtRw+oxFObqWg+K5MqIYfh+4RMssLyooBU2 52Z7WavejPGpq15teAcbmBISIjvskH8M5Xf5T8bN/wAAAP//AwBQSwMEFAAGAAgAAAAhACGCrkxT DgAAd1YAAA8AAAB3b3JkL3N0eWxlcy54bWzsXF+P3LYRfy/Q77DYd+f2z/01cg7uznZiwLk4vnP7 GGi13FvFWmkraX22n/qUNGiKoC3gtkgf4iYtXKDxSwokTdz2y/guzlO+QodDUqI0IiWu102LJA85 S0v+SM7Mb2ZIzu7Lr9ydhZ07LEmDONrt9l/qdTss8uNxEJ3sdm8dX72w3e2kmReNvTCO2G73Hku7 r1z68Y9ePr2YZvdClnYAIEovJrvdaZbNL66tpf6Uzbz0pXjOIvhsEiczL4PH5GQtnkwCn12O/cWM RdnaoNfbXEtY6GUweDoN5mlXop22QTuNk/E8iX2WpjDbWSjwZl4QdS/B9Maxf5lNvEWYpfwxuZHI R/mEf67GUZZ2Ti96qR8Eu93jYAYrOmSnnZvxzIu68Anz0mwvDbzd7tnjXz7952/5u+lelNa39lMK ssZHCr3oBHre8cLdLosu3DoqY9+fXjg45K9GwRiQveTC0V4XOq7hxNVfbQHzfDmiVWW1IFOQ8JHQ EMiCTa7H/m02Psrgg90uaBlf3rp2IwniJMjuFe+O2Cx4LRiPGdhD3i6aBmP20ymLbqVsXLx/8ypq V77w40WU7XYHm1uogDAdX7nrsznXLgwXeTMY+ZB3CPnwP1N9+3yhIKG65lPmcVPs9J17DJx7DJ17 rPMeqSYvnOaiIiz3uW+8INzNF4S79YJwwfe8EPnurBjX99DIV4x6HGQh45itmHK0GGVuHbIkjk5a 41+ZzadeGoCLbjmhG6Hns2kcjlnSOWZ3s3rpBIUD2tmxOILDuHM093zwBRxnoXVrT6/rwck06xxN 0aVUYTZ7ltFFz+tBiqvQR9+0eS/R7dUkGJPRBpbRXmfjYDFTExW+rzTmsH1ndIOlzuvNnflCa4bd aNmTjrnZ3JNLqWbMrZY96ZjbLXui2y9JyGaHl73kdqfOELZs9nMQh3EyWYRKp1Vz2LJZUd65dlib IeU960xwy2ZFJap09nwfsoka7djWXHDG3N+27II85v62xVdZZEaxCaKCMjCjtOaVGcJGsJvsTsCT dG46NOXQ/KHVjSKzb3iJd5J482nVDIeY0LQKN28u4gyDk86cAQbWVv2vRZCgpqxTizPEvLMVjtQP rsuinNYOyKyc1p7IDNHaJZkhWvkmY3cnJ2VGsdE29zmoEpPn2LIxN4fAmGCEsNG21n/RGOHmv2h/ myCo/6L9bVKoeJ6+UgdFsQmigpJThKI4+y8KYfNftUSlEM5EpRDORKUQzkSlEE5EJd2XIipFsdln zjKdqBTCZqI5hE5UCmGzz1qi0pTMjai0v00QlKi0v00KFYrlRKUoNkFUUHKiUhRnolIIZ6JSCGei UghnolIIZ6JSCCeiku5LEZWi2OwzZ5lOVAphM9EcQicqhbDZZy1RMV/UM8CWu2gVy2h/myAoUWl/ mxQqFMuJSlFsgqig5ESlKM5EpRDORKUQzkSlEM5EpRDORKUQTkQl3ZciKkWx2WfOMp2oFMJmojmE TlQKYbPPWqLiifJzEJX2twmCEpX2t0mhQrGcqBTFJogKSk5UiuJMVArhTFQK4UxUCuFMVArhTFQK 4URU0n0polIUm33mLNOJSiFsJppD6ESlEDb7rCUqXtE8B1Fpf5sgKFFpf5sUKhTLiUpRbIKooORE pSjORKUQzkSlEM5EpRDORKUQzkSlEE5EJd2XIipFsdlnzjKdqBTCZqI5hE5UCmGzT361FrKOfgOm M7Tvfuppghq0v8ySk7rJJiyBig1GznLbQ6mzWDMW7ulbncfux/HtTn5zqYtpiPuNdiDBKAxiPKK+ 13jePcTbZ3rpbi4qOH7joPOaKCxoRkflUnRyCwqVGnrRBa9owAIZaJjdm0Plw1w/dYeCDF6ZAhU3 OANep3EN6iq8PlZO8FIJ6IfFIrJgAlcjhYf/hoqdsWrT6/XXt67u7YkbLygN4aNn3ggLX+Cvahey ScbHm8dQprK1I72pqUG/vyO5aWyxsS29kLHFzjY6XJAONMH5xFBtNAnj0xuLyM/UzOT5jrfIYn7N yy5fMX5yWP1k/PYizW7yu91rUSESIYtU3BlDlxGDSiRQQ38gx3rbV0CjOJuK5hncU++FwUnE65Py j72UhUHEeBNYhxQv1BNxKSeqgkjVCR1D9RMMMwuiOLkia4fkXO4rxIGKY+WioFf3uXIUkKoTEqPi cDA62lSDcWEbbk7Umop6GjSiCNabT0rM0mxj+/v97cG+aCWFcJux+SFgCLDFTMgkWsyu5YoYKv3D W/Ex1clgHS98vEnGoI6MPyFgnYbiRcZ1cf1OqOaNjc16kZVde0kgyo4K8X7z1a/L9VyiDQ49wv+n ucaGMsSk9w94uRgyU7yDkZfSzYAwXelGDqXrBvwCTmgFygnCQnQS9b+rLxx01foqNKW4pWtKvFtW U0OjpmTSMAIHMX6D17ihXShlrVaBnGrXwfJTNIScTLo6leHY6af5WIQqng/Fc8mf4qsaxsJBH6xX MVY8cWLudtf7mF3xh5uLEF7wAYT5UvLilM3GQMiK0xkdCCHcZkku9Ofgpz+FyOyD6+ErMgVmSldZ jNnJb9M7PBSIhRZ5jzIKSbXi5h5XUs4r4BWIwuDhIXyKajDTDKmZitShc4w9xXh5nYCal6oWaJpY XvSFONkolEnGKBRBFyp20SJErjO+6wlBQMMDFoaveyIliecwrqEpT07Ep/0eFv5VoCBKZ/HM3D/B 6i6ErwMAyeqTEY98EWaRA8lGLJElZyaxrxPvAKVqfLtisoS2EjfPq5RJ+pD8xLMjnkGSbLJH5vbs 4aPzj55886ffn3/2SEywzkuVc0tD3G9wRjIxLMWWxlQAMWEZPZkBBJjQccvgL7cxF59C0gQ62e0O N+X+tcgTeJkS8FgQyZCoVRMCWcytBf8imPTlKvRgIt6BdlzCvk1LGwYtnT949/yPfxNaatSIyq7h r6L2mPmBrLXGhF8lSqIpLGBpAUXxjSSOJ+gKCmHB5lW+KXIk8W6FwtqsE9bZJ393EtaqDWa0QkmA doSft5mMKLDXt4lI7M/PnnwgdFBNSWSm0mhGhWTUpojYSaHwZnagz20dKfbhCx3wTRTcvGKkwHSK f7lDSCS9D9kFD9I8HwFvhwHH56WVepIh48hSffMYs1RvFYGW6hzAV0rG7DVFXtdVi+4/Wa476Bhi oy7+//2wDVP25X5ymm82/ZB5mMbpVgEymQQhfO+mSETv4CZfCasUNQQqSMSQh7UOvsRRnX/wm7MP //Xcsbc29ZfnyW2jLebt38tgu03UAjo5/8jsOWVQa/ScpaMQumHa1vdL8IARo/C2JRPEuLwCC9wh a+VR8uHH5x+9C1ZYHyjaLrcm3yidLpaTDeGywZED5dRB3BCSPHiUW0j+1CgTmXNpp27VZI5sGGEE W4I3lHc5eoIn3oH8XRK8/MzN84jUJzHUSmNWCpilY9ua1LpGsNI4YCmYx61v9KWsoC28xHCDsYfL E5vs9MQpJ3fseOwK/1g623MJ+C2ttpDWiEiLH4OtUlr9DZn8GKW1PeyhGeTSAnONvPlxjFdGUsDE PI0JUn4kXDVOmyE251ItRWtLG30i7PNPPwaf8O2TX3zzlwfPHr7/9Itfff3kr8/+/eG3T95byj+s YJJjOsnPHn39yZeQ5C81pdzy5/vjpHVuifcyMovo4X98cFieQOH/ENkHOokVeqSVby+ZQZ76jqm6 XWgbBZRI2+bNDVI9vSg2/JMgSTOenvBNvookzvI+//PncL7/1qv7g2EfLzC/c/5NiCq+fvLg7J0/ nH315bPHj5/Puonk1vMQ0FJyJfFAJOHfZddORQIMz0gJFXQ4L65elcRoiJbgfeUuLr/snNDzqWPe qsP9br002u5jT4NxfHoA57FJXL4ogoTjxd0xhrnJgoT4Q/kAvHAaLuen+rbsh12x21nA925XbI6/ pVsOW5IwobfGYn/09Iuf15NS3r2YU1tDjCQ/qCFfoKMZif/Lqx7idtR2oUhO26bt7QVB73ykIL58 v14QIDqctUkSZu2UThWK7HhCL3X2vTCM4Qc18Cv1Qkb114/gf24rR30AV1z2qcndDmS++Z3386Sk bYWME+NJmX6Wef7eP+B64vzhOyJF6RSzr+Yp0vL0pXogM6sSipWacvwXIAJNpfTCyIuiGH6Xhf9M SpKXc9WqtpZpeu1PlWnG36PR1lizBYYrXBgfzLUhqJfM1uJUMKzzjR1JgPCTt/Cj2hVLRum3VNiF V+rU6VkXhsx7SiczGa2Kyg8NjWVR5Ra1dVGVJo2FUYPtdTF9mJBiaekAZQN+RQclYmqwvSFlY2rQ 78P3ua0Q/XXFcSPGVq9hlMFgU16SmTAGGxvSbo0ttkWVEJ5W1EpjCEK3r2W43msYZbi5LU3dNI/h jrhSBMOHJngRsYKTvNzhjFAZBfMGOGFHlmmehF4cap6kIEjVaUqF6k6Te1h5wFGOXTV0UpLRhFg2 /rrCwnKLZRlUQWmoLURpa9l+5dmh2oWc/SBTBbXqKgbVRQOotrz30nQvMenvggFss0m4xFe6y5IB 9sG7Z5/+zjW64h0+mHTpHFM3k2oIUkey5sJIKQPVcPnCx6YIhJyoZhvHfMv5ViNdzAuWKv4OeVEK HD9EFq3IefD/FFlKVbC0CFY5HZtXWSaiNLHmMBb1/PXEUZ+iNzSEGpK9FfleI61K2Vu5CJLGZn5a CPmDvFOqKfWm92yl6NzseEsZrxaLaV2KFovTxeht5st8tSqjifSoupA89bIapGXsLkvtypV+b3gg 0iOzMyo5iboYXWpQG6LLLRpz3H5DgFaZngyFWqg2frKq4n/u7t0K/UXypkpPtUAuc+xKIIda/pUH 8pqDGdwpP/3iK7jPNQdyLbvT7cmbyHTYbE0ylq9o7cAuZEx66T8AAAD//wMAUEsDBBQABgAIAAAA IQAbVN9U4QAAAFUBAAAYACgAY3VzdG9tWG1sL2l0ZW1Qcm9wczEueG1sIKIkACigIAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJyQTWvDMAyG74P9h6C768Tx+kWcQhMKvY4NdnUdJzHE VrCdsTH23+ewU3fcSTwS0vOi6vRhp+xd+2DQCSg2OWTaKeyMGwS8vlzIHrIQpevkhE4LcAin+vGh 6sKxk1GGiF5fo7ZZaphUr62Ar5a1nF92T6TgBSN8v2vI+cAasj3nh6IsG15y9g1ZUrt0JggYY5yP lAY1aivDBmft0rBHb2VM6AeKfW+UblEtVrtIWZ5vqVqS3r7ZCeo1z+/2s+7DPa7RFm/+a7mZ22Rw 8HIeP4HWFf2jWvnuFfUPAAAA//8DAFBLAwQUAAYACAAAACEAg6VkzfELAAA9jgAAEgAAAHdvcmQv bnVtYmVyaW5nLnhtbOxdzW7rxhXeF+g7GAK06OLK/JdkxDeQLQlIcJsGyS26piX6mqhECiRlx1kG 3XRZFF0UXXWVvkEXSfo0DdCs7iv0zAyHnJHJI/6MbNnm5vqK80PON2fOfHPmzJlPPv1mvTq59aLY D4Pznj7QeidesAiXfvDhvPf79/M3o95JnLjB0l2FgXfeu/fi3qdvf/2rT+7Ogu36yosg4wnUEcRn t5B8kySbs9PTeHHjrd14EG68ABKvw2jtJvAz+nC6dqM/bjdvFuF64yb+lb/yk/tTQ9OcXlpNeN7b RsFZWsWbtb+Iwji8TkiRs/D62l946R9eIqryXlZyGi62ay9I6BtPI28F3xAG8Y2/iXlt66a1QRNv eCW3WCNu1yue725T5W3LyL0DnNcr9tl3YbTcROHCi2N4OmWJWY26hr07BZBUkZWo8gnyO/mXrF0/ yKoh4rHT/1nnDaDzTtm7T0lVeUMAi7cgTO5VnETuIvliuz6Rfn22PO9pNEsQ+0tIu3VX8GRiTodD w+ydksLr7Srx33m33ur9/cbjeejTFXnKciXrzYqnXZhT7dIaOixldUsSfPjD3wUiHyU8s85ygbzP 19nDpbfw125aNZR8732TpfXTEvD48wWvZeVdJ6yizZcR+eoE2pz+5XngFT34/yaMz3uWaZDsp3lG PyDtJ/WwVPhx4wYf6FDNc6e1R+wl0TwMkpjk9AMo5rlxMol9N62ZZoI3wIeSL4E/kJPhoFPM2+Iw 6NNG0KqbQ2GzjiqBgqSKUOS5FUFhqIJi0E8FtpVgDA0NEQySKqKR51aEhqkCDWvAhkIrIGxniAAx NmWxcEYcNkVAWCqAsD/++OfnD4VdEYpVeOdF77wk8aKs0ZLidF4EHE4dOL4K125QjAYV77a68xCD ZOlduzDnpqMPmUWGFZHAZ1OYRUB1DvrWoG8P+s6gPxz0RxlkzecV3bK4TuCTsTjH0mRRlwr5FemQ 0eHwGfTHKiCyR1bazYUQkWQJojx/Y4hgnhfoICEmwk94mfCLsEPGVCR2eOFc2tqc9m0Tdqhb48l0 YufUBV5ajx1uNxtU0f3y9z/9/NPflPBE3RhRVlHCjmiy2EMvminqloFxAposgvHSuaJuD+lapEw4 SLKIxwtmi7ql0zmjDIrhaChB8aL54pODcWyM8ckBOSbOeCAwXghrNIwxplNpsqhTXyFrNCzTRlgj TZYgenzWyIw6Ims0NMs2Z81Z41w3HM0xLjPWDS08WtaYs8AiWk9Sxf7Jczcm9Z11kZhyCwytnXVR NDt31sVUZ3TWxUx9HhtXfGK78zExxYNA8UJ4osD7iubYzroIpruc9xVCdATWRTYhiTzR1C5Hhj6Z MJ5Xf+/Z1owJbF53e88R3d0uoETd3nM293XssGOHBSOkY4fZCOnYoeS307FDbnXp9p7B4IDszXd7 z8y9ToIIIBO2l/fuPTM9LLFD4stqM7+CJnvPl3NDG84uW+w9474UmXWyudtEbg0sIu0KbId3Z1eg 3pmjJ/tef+d3/C1/AF5e1Ac0/vaSuDnSQuwZLv2vimPWAjR1m5AA5W4y0liRTbqvjanWwdSgPjR3 ZyKm7BkupK/IGloLTrr/tgMn35NDRPRVsebHAPTVce/HAPU1MfjHwLNbB9RBmTlJybo1c5xCdGu3 mqA0tDpxrQ50zTUJU8rSmmRkXAzH+qypxVqztLGm6dNs7QBEu55nw+HXJAbmcGJBKnxzfloqy039 GQDgAhvbMa0QdN3C2jcey/4a+bYc0r4jI+z62OQUrmhZSX3SxD6s1EYlBFrPzh9kA6D54tkY6nTF CjJX2MzxjkP9UONeq0hXKiG2eTPhmIWClpq2hnWoYduy7/HI5qtMpKVVGSeucLIOZQdKFDTWMkZY t5rgGiZpIF03+bkKpLVVqWCt1sLxGQUNtjXUs9wcgSO+OFx1IzvEiTT4uLmaPbKxTrbM8c5hmNzl HGnz0TMnx7GoObJEZdm6Js8++lArHMk1eQwTfpHHWMZ8Zg+1CRPf+jvvuj6fXcymqcVQ3FhkJ8xr nnaOt9fXIOLU5BiECZyw/pANLOlUo35ykiUgM4d49oxqi2s/ipN3PjlYLwGamvXhDz/d7cYL3z/v TSIfjqTDN/Fz3ue9X374y39/+isdihPAUsjDToQLzjZ1lgmPanatDjQo9kfH+kYprrSj5eWXyTsf WX41InO1cIUTmM8b2kc1wtaFFg63PnN0KdeTBdfg/A8RXCXU1VYRTkCgZIXMnDA2kdGYOp8V6eS+ XykrVRQM2/p4KyHQzm+qzGccRfibTZNCgJPXgXdVCr83NMKwk3ES+aeKTmm6ivjKkxhgOhVvvk7u V1lUIZdJvqjf44278LIBITK/n//xn8JABQsIQcVDYKTK4zmRv+qmS3mLuOlKp1K/cOIkkPLyjvnf P/9VGB7h1XRMzbUYG1HiWsw2LN22p2kYjvprscnEmcBxuzyMB0wR9WzKAQSkKxx1LLjC5CRLRNZc e+YoYjhGgnDhZuWHjOApgnBNYE2kAAliYi5HYo8Buj0SjdY3sMIXtXE/tXAqQGPfCWli+BG54o6x uj0ex2fY1onlulxCaLIIyY5huz0kSlYSqo3g1Mpdjso+I3h7VJTwfQkViMCkYARRi3g5MHsN5u2R qcrMn8C4Tq3nCDj7jOvtwWlKoYv0rfrAXdTSXo7PXkN8e3yaUtkK+KgJ3EWt8uUQ7TXaN4GoJqlk GIqk0jFtCzYb0sBl9UnlfGY5tjnJ+U5tUikNdnnllxq4HpAKBcrw4B7V0DOIDa6Rp4MMTg75AwlX gE8epovzdXG5fJwBYGV88sCvD/DposKme2gQ31GFrBwi4CXfTyPfh48lJSy0iworjZIuKqwYXFyJ 98YhBomwlYyPkeMml13chtw1rWzr5vjjNoxpZF2JXE5Hc+vicsLmmGJyeXN/FfnL35L7BEpuDhjN rIntWLNsphIoJvw32awW4K1BHWbB/Y0cIJT2FFISKd8lcLVdrbwkq1HUfR+/+3f2vLkZ0wTvs/K1 AEkVLTN5bnxj8+v79VVI3U3SnU3hAb1toLJCoI6AEnQm+aIEtknggg5ysYgCKEMFQOpaFkW+iInS 5CZQXobbyPeiky+8O9oVzKVk5+kCboXYefTAhwdXvNRPS8KZ+kWrxfnjd9+rQHqUOZEVIk2SmyD9 B/DSIrfbwH0v4BDOcJaf1RNdJqjyqFcuumq0gGGjN0fQ5CaQCsOe4Sk8qAcmdbCQ5PNI9YBpoJHj aXITKHeH94H0ABv1otAerR4wx/jcRZKbIC2P+fZ6gF42Iokum9SUTmFq9ICVh7YuUq00uQmkwrBv qQeo67gE5pHqAQj0gDErmtwEykfSA3STUsL5aPWAo6OTF01ugnR7PQCUq07IEP3hbWZwkZk1nDno yoSuV0rWJNOxDZeZMUmUPW6q+rU/4n0Vz9HW/cDmr8an4jmatYug6CzYnQV7x9Wms2CLVpx+Z8Hu LNjkjLkkFLteNd29ZlXwUeMe8QwiD+vM5imasIczbWZeaKnxudiEjRHFmWPM5qN5vlkPjLlzuj3A zbcTNQTxRTjdEizUMMTO65adNRYPUXVet/wEtoBK53VbsnHbed2SHdkycIhbLbJN2nndQnyLcnw6 r9vz3nF43YJ3ARA7+De/HlewUH62hEQ6kYApknUnZCXjQirHTtzUL8dOptQvxxznCsvxoCtFn8nO N5QXo/bQ3916Efh1kEOcD+iukMZASTGB1RpPItgIP7NaBKcEnjWDtnotwtGmFrUIB4Ja1CJ4L7ao RThz0qIW4XxGi1oEX7MWtQju/pVqgT2BImFlTSoUVnQsskbUL8c+u3455jxVv1y6t1FYkB8fLMIl XerWL4coKfR9iJLiU1zhdyJKih8ULSyHaClMB0OoOKJ7CnHhl34Xvg8RGE5xCsshAoOWQwQGKwdb eqXtA5lAJiemeguBwQsiEoMXREQGL4jIDIoNIjNoOURm8A9FhAYviEgNXhARG6z3ISBSqdhg0ECA yWblmgqNiQgND+tYNA4h0kzph6LlEJlByyEyQw9j8fmM/b3yIvCge/t/AAAA//8DAFBLAwQUAAYA CAAAACEAdD85esIAAAAoAQAAHgAIAWN1c3RvbVhtbC9fcmVscy9pdGVtMS54bWwucmVscyCiBAEo oAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAITPwYoCMQwG4LvgO5Tcnc54EJHpeFkWvIm4 4LV0MjPFaVOaKPr2Fk8rLOwxCfn+pN0/wqzumNlTNNBUNSiMjnofRwM/5+/VFhSLjb2dKaKBJzLs u+WiPeFspSzx5BOrokQ2MImkndbsJgyWK0oYy2SgHKyUMo86WXe1I+p1XW90/m1A92GqQ28gH/oG 1PmZSvL/Ng2Dd/hF7hYwyh8R2t1YKFzCfMyUuMg2jygGvGB4t5qq3Au6a/XHf90LAAD//wMAUEsD BBQABgAIAAAAIQCpyFyqjAAAANoAAAATACgAY3VzdG9tWG1sL2l0ZW0xLnhtbCCiJAAooCAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACySbIKzi8tSk4tVghOzUlNLklNCS6pzEm1VYpx DHDUiwj2UVIAC/gl5gIFgWJKChW5OXnFVkm2ShklJQVW+vrFyRmpuYnFevkFqXlAubT8otzEEiC3 KF0/Py0tMznVJT+5NDc1r0TfyMDATD8pMyknMz+9KLEgoxJqGFWMsrPRh3vGjpcLAAAA//8DAFBL AwQUAAYACAAAACEAiVDx9pkBAADsAgAAEAAIAWRvY1Byb3BzL2FwcC54bWwgogQBKKAAAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAACckkFP3DAQhe+V+h+inEscUkAsmjVCiyoOtEXaAGfLniQW jm3ZXsr++44Jmw3qrTnNvHGenz8brt9GU7xiiNrZdXla1WWBVjqlbb8uH9sfJ5dlEZOwShhncV3u MZbX/OsXeAjOY0gaY0EWNq7LISV/xViUA44iVjS2NOlcGEWiNvTMdZ2WeOvkbkSbWFPXFwzfElqF 6sTPhuXkePWa/tdUOZnzxad27ykwhxZHb0RC/ivHMZVyaQQ2q9C6JEyrR+TN+YoGcwsPosfIvwOb Cnh2QUV+3jTAphI2gwhCJmLIm9VlDWwhwI33RkuRCC//qWVw0XWp+P0OosgGwJZLgOBsUe6CTntO VssW7rWlKM0ZsKmibEH0Qfgh8osccO5gK4XBDSHgnTARgR0F2LjRC7vndzvxB3XRohysM67PV7lx 1bf7pCo6xMeqvOtLfPStu838Puw+iwsEzzoNWy9kZna2olRHGIsRbIkZKjrdwfAowB3dWTB5V/rX 9qgOa/4dZLxP0+Plp01V0/fO86ARlPlV8b8AAAD//wMAUEsDBBQABgAIAAAAIQBkfaZzSwEAAHgC AAARAAgBZG9jUHJvcHMvY29yZS54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AACMkl1PwyAYhe9N/A8N9y10VbeQtkvU7MolJs5ovCPwbiMWSgDX7d9LP1a76IWXcA4P57yQL4+q ig5gnax1gdKEoAg0r4XUuwK9blbxAkXOMy1YVWso0AkcWpbXVzk3lNcWnm1twHoJLgok7Sg3Bdp7 byjGju9BMZcEhw7itraK+bC0O2wY/2Q7wDNC7rACzwTzDLfA2IxENCAFH5Hmy1YdQHAMFSjQ3uE0 SfGP14NV7s8DnTJxKulPJnQa4k7Zgvfi6D46ORqbpkmarIsR8qf4ff300lWNpW5nxQGVueCUW2C+ tuUqdJM5nuy006uY8+sw6K0EcX86m34LrdfCQbYvVC5IjqfrcE3Xqr8LRBRy0r7VWXnLHh43K1TO SJrF5DZO5xuSUTKnhHy0oS7Ot7n7DTVE+ydxTm8CdEo8A8ou8eVfKb8BAAD//wMAUEsDBBQABgAI AAAAIQCfcHe9XQMAAJQOAAASAAAAd29yZC9mb250VGFibGUueG1sxFdBb9MwFL4j8R+i3FmdNGvS atnUpsvgwA50E0fkpu5qKY6rOF23G/cdJsSRM1euHBD/BpAQ/Aie7aTr2oQ2RRutojYv9ovz+fu+ 93JwdMVi45KkgvLEN609ZBokifiIJhe+eX4WPvNMQ2Q4GeGYJ8Q3r4kwjw6fPjmYd8Y8yYQB8xPR SX1zkmXTTqMhoglhWOzxKUng2pinDGdwml40+HhMI9Ln0YyRJGvYCLUaKYlxBvcWEzoVZp5tvk22 OU9H05RHRAhYLIt1PoZpYh7mqzPmnQQzWPUZZUQYp2RuvOIM6wFTnHBBLBhziWPfRDZ8W6iJ9pED hw3/HLMhM0UTnAqSLQYiHR5jRuPrIpqqvGr8lGbRpIhf4pTiYUz0HEEv4MJMDJFvHiOE7G4Ymjpi +WYAEddzrDxiw6L0p51HmosIbBMsTOVRQyydByKQJ5+l1tnQ+7SGSBeWFSug1nHoAQ6OwkNiYtfC QcypEPph/xWH5mPg8PPLu29f3ysgcJydAluKnRtQ9pzQ/FHWuGIBRm04rOKrB65wxWvp8H2uMD4i aVIC0phekZGOLzPFkxtq95aY0vSC0A3C7ipCVmsDUxzIpPi1PVMG12zIy6myD0KxgCAWcgEKG87c UhiQXQZDfcksiL2QjJWHVoFASiAgtFLJKEBhppy1PRABn6WUpNJGKoTjgmm0lWSkgTi1hFOXFJX2 8SiyeQ2WK2uEKEViv9iou98avMCzjOvhWzpIcZecBOCAj0mL759uqh1kMCt0XuogCAizi4PsClHB DYDI9rxQAreqnIewkB8fPwNEb056dtOyFWMexCdzHhT1U1ZCD0mdrD9kESm1B5ggfbKmPfR5NmNl heTX7c3vD29zRq/RQBZb+dlAA6vMQesX2568FXQdd1JptfsulJLeKg+amyACE22rPNs76MuBcf7C OOHZhEalxmEjDYerioknTbTUOLzSHqw+HIoc9nIP1uoGbthfhwN4q4tOFWOgm60Lh2JMMCF/gaK9 IzPqVpP/y4sAsyH0oxU4yHZct+WyPa+iBMhVdd/3W636PUZXKeR4SSHKC5CzppCFrVRRAkRdlxIB jilAUYFEqF5MVEteG4kdxCGr6D1xSCS6wUIutV5QNiKRv6mIwz8AAAD//wMAUEsDBBQABgAIAAAA IQBK2IqSuwAAAAQBAAAUAAAAd29yZC93ZWJTZXR0aW5ncy54bWyMzsFqwzAMxvF7Ye8QdF+d9TBK SFIooy/Q9QFcR2kMsWQkbd729DVsl916FJ/48e8PX2ltPlE0Mg3wsm2hQQo8RboNcHk/Pe+hUfM0 +ZUJB/hGhcP4tOlLV/B6RrP6qU1VSDsZYDHLnXMaFkxet5yR6jazJG/1lJvjeY4B3zh8JCRzu7Z9 dYKrt1qgS8wKf1p5RCssUxYOqFpD0vrrJR8JxtrI2WKKP3hiOQoXRXFj7/61j3cAAAD//wMAUEsD BBQABgAIAAAAIQAEPdjV9gAAAGwBAAATAAgBZG9jUHJvcHMvY3VzdG9tLnhtbCCiBAEooAABAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJyQy26DMBBF95X6D5b3jo0R4SFD1ECy7iLt3jKGIOGH bIcWVf33GqWPfZczd3TmzLDDu5rBIp2fjK5hsiMQSC1MP+mxhi+XMyog8IHrns9Gyxqu0sND8/jA np2x0oVJehAR2tfwGoKtMPbiKhX3uxjrmAzGKR5i6UZshmESsjPipqQOmBKyx+Lmg1HI/uLgnVct 4b/I3ojNzr9eVht1G/YNX8GgwtTX8KPL2q7LSIboqWxRQpIjKtMyR6QghB5pey6fTp8Q2G2YQqC5 iqf7YeZjpC2hmu2bD65J0n2R5LTMU4b/ugz/7GsY3kTub2q+AAAA//8DAFBLAQItABQABgAIAAAA IQCMimiR9gEAAOIKAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0A FAAGAAgAAAAhAJlVfgUEAQAA4QIAAAsAAAAAAAAAAAAAAAAALwQAAF9yZWxzLy5yZWxzUEsBAi0A FAAGAAgAAAAhAG8BpR95AQAAUggAABwAAAAAAAAAAAAAAAAAZAcAAHdvcmQvX3JlbHMvZG9jdW1l bnQueG1sLnJlbHNQSwECLQAUAAYACAAAACEABbKtyIIfAAAowgEAEQAAAAAAAAAAAAAAAAAfCgAA d29yZC9kb2N1bWVudC54bWxQSwECLQAUAAYACAAAACEAz4kcKlMBAAD/AgAAEAAAAAAAAAAAAAAA AADQKQAAd29yZC9mb290ZXIzLnhtbFBLAQItABQABgAIAAAAIQDxrGkabgMAAPEJAAAQAAAAAAAA AAAAAAAAAFErAAB3b3JkL2Zvb3RlcjIueG1sUEsBAi0AFAAGAAgAAAAhAGx7IwgkBQAAvxEAABAA AAAAAAAAAAAAAAAA7S4AAHdvcmQvaGVhZGVyMi54bWxQSwECLQAUAAYACAAAACEAvejRAVMBAAD/ AgAAEAAAAAAAAAAAAAAAAAA/NAAAd29yZC9oZWFkZXIxLnhtbFBLAQItABQABgAIAAAAIQCVKsjh aQEAALMDAAARAAAAAAAAAAAAAAAAAMA1AAB3b3JkL2VuZG5vdGVzLnhtbFBLAQItABQABgAIAAAA IQC0WN7maQEAALkDAAASAAAAAAAAAAAAAAAAAFg3AAB3b3JkL2Zvb3Rub3Rlcy54bWxQSwECLQAU AAYACAAAACEAWGCzG7oAAAAiAQAAGwAAAAAAAAAAAAAAAADxOAAAd29yZC9fcmVscy9oZWFkZXIy LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAL3o0QFTAQAA/wIAABAAAAAAAAAAAAAAAAAA5DkAAHdv cmQvaGVhZGVyMy54bWxQSwECLQAUAAYACAAAACEAz4kcKlMBAAD/AgAAEAAAAAAAAAAAAAAAAABl OwAAd29yZC9mb290ZXIxLnhtbFBLAQItABQABgAIAAAAIQDHHG0UnAYAAFEbAAAVAAAAAAAAAAAA AAAAAOY8AAB3b3JkL3RoZW1lL3RoZW1lMS54bWxQSwECLQAKAAAAAAAAACEAxxn+6ieNAAAnjQAA FgAAAAAAAAAAAAAAAAC1QwAAd29yZC9tZWRpYS9pbWFnZTEuanBlZ1BLAQItABQABgAIAAAAIQAf +x7m/QUAAA8RAAARAAAAAAAAAAAAAAAAABDRAAB3b3JkL3NldHRpbmdzLnhtbFBLAQItABQABgAI AAAAIQAhgq5MUw4AAHdWAAAPAAAAAAAAAAAAAAAAADzXAAB3b3JkL3N0eWxlcy54bWxQSwECLQAU AAYACAAAACEAG1TfVOEAAABVAQAAGAAAAAAAAAAAAAAAAAC85QAAY3VzdG9tWG1sL2l0ZW1Qcm9w czEueG1sUEsBAi0AFAAGAAgAAAAhAIOlZM3xCwAAPY4AABIAAAAAAAAAAAAAAAAA++YAAHdvcmQv bnVtYmVyaW5nLnhtbFBLAQItABQABgAIAAAAIQB0Pzl6wgAAACgBAAAeAAAAAAAAAAAAAAAAABzz AABjdXN0b21YbWwvX3JlbHMvaXRlbTEueG1sLnJlbHNQSwECLQAUAAYACAAAACEAqchcqowAAADa AAAAEwAAAAAAAAAAAAAAAAAi9QAAY3VzdG9tWG1sL2l0ZW0xLnhtbFBLAQItABQABgAIAAAAIQCJ UPH2mQEAAOwCAAAQAAAAAAAAAAAAAAAAAAf2AABkb2NQcm9wcy9hcHAueG1sUEsBAi0AFAAGAAgA AAAhAGR9pnNLAQAAeAIAABEAAAAAAAAAAAAAAAAA1vgAAGRvY1Byb3BzL2NvcmUueG1sUEsBAi0A FAAGAAgAAAAhAJ9wd71dAwAAlA4AABIAAAAAAAAAAAAAAAAAWPsAAHdvcmQvZm9udFRhYmxlLnht bFBLAQItABQABgAIAAAAIQBK2IqSuwAAAAQBAAAUAAAAAAAAAAAAAAAAAOX+AAB3b3JkL3dlYlNl dHRpbmdzLnhtbFBLAQItABQABgAIAAAAIQAEPdjV9gAAAGwBAAATAAAAAAAAAAAAAAAAANL/AABk b2NQcm9wcy9jdXN0b20ueG1sUEsFBgAAAAAaABoAlQYAAAECAQAAAA== --_004_F82A4B6D50F9464B8EBA55651F541CF84317D2BASZXEML552MBXchi_-- From lberger@labn.net Fri May 17 08:16:36 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF2A21F9696 for ; Fri, 17 May 2013 08:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.135 X-Spam-Level: X-Spam-Status: No, score=-102.135 tagged_above=-999 required=5 tests=[AWL=-0.470, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_52=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IqGqDwXDpj-b for ; Fri, 17 May 2013 08:16:32 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 9314D21F9686 for ; Fri, 17 May 2013 08:16:32 -0700 (PDT) Received: (qmail 23804 invoked by uid 0); 17 May 2013 15:16:11 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.bluehost.com with SMTP; 17 May 2013 15:16:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=4SRjbsn7QUInuFmFlcYBuWWJirRH0uv2vDziJbWBhUs=; b=gdDvWpL+jRJ4ftK1wWFj5phWNFd2q1NdfhMvrrbd2v667VwUphgNs4IHTih/WOgtb//5K649/8dDbqyqYsvcyPIBsSx56pZ67U0isOQSANYHLEGb/z4ATwNgV62HJ2Fb; Received: from box313.bluehost.com ([69.89.31.113]:34214 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UdMOA-0007Aw-Jf; Fri, 17 May 2013 09:16:10 -0600 Message-ID: <519649B4.5060408@labn.net> Date: Fri, 17 May 2013 11:16:04 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Fatai Zhang References: <518A82D9.7080508@labn.net> <518BAB17.9090807@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> <518CED28.30303@labn.net> <51924382.2010904@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C90D5@ESESSMB301.ericsson.se> <13ea7ed3bdd.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <5193A26A.1090005@labn.net> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" Subject: Re: [CCAMP] R: Closing G.709 open issues X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 15:16:37 -0000 Fatai, That's a great start for the WG. Thank you. To answer your implied question as to why my request for the full list. My feeling is that there have been too many "surprises" on the 709 documents in areas that I thought were either obvious (but from the IETF & GMPLS context, not ITU-T or G.709 perspectives) or resolved by past discussions. At this point, as co-chair and Document shepherd, I want to ensure that any open point on the documents are unambiguously closed and that past discussions (i.e., points of consensus) are 100% captured, so that we can smoothly move through the planned second LC and publication request. To that end, in my previous message I asked two questions about points where it seems you are proposing moving away from what has been previously been discussed & agreed to by the WG. Can you answer the following: >> My questions on the new G-PIDs come down to: >> - Why are rate specific G-PIDs being proposed (rather than >> continuing to use the previous approach documented in the draft >> and in Section 3.1.3 of rfc4328)? >> - Why are new values being defined rather than using existing >> values, e.g., G-PID 56? >> Much thanks, Lou On 5/17/2013 3:58 AM, Fatai Zhang wrote:> Hi Lou, > > I thought it should be sufficient for me to identify the **updated** and > **new** G-PIDs in this draft (I compared [G.709-2003] and [G.709-2012], > and checked RFC4328), but I would be happy to provide a full list for > your request. > > Please see the list below, and the new payload types introduced by > [G.709-2012] (and the corresponding new G-PIDs defined in this draft) > are in the light blue cells. > > Please check if there is anything missed or wrong. Note that GPIDs like > 32,47,49-52 have been updated in this draft. > > Note that we as authors welcome any contributors for their contribution. > > For you convenience, I also attached the word document. > > > *G-PIDs vs **Payload types defined in Table 15-8 of G.709* > > G-PID > > LSP Encoding > > Payload Type in Hex codedefined in G.709 > > Note > > Interpretationfrom G.709 > None > > > > 0x01 > > Not needed > > Experimental mapping (Note 3) > 49 > > G.709 ODUk, G.709 OCh > > 0x02 > > 1)G-PID defined in RFC4328; > 2) Updated in this draft. > > Asynchronous CBR mapping, see clause 17.2 > 50 > > G.709 ODUk > > 0x03 > > ditto > > Bit synchronous CBR mapping, see clause 17.2 > 32 > > SDH, G.709 ODUk > > 0x04 > > ditto > > ATM mapping, see clause 17.3 > 54 > > G.709 ODUk (and SDH) > > > 0x05 > > G-PIDs defined in RFC4328 with two kinds of GFPs (Ethernet MAC (framed GFP) > > > GFP mapping, see clause 17.4 > None > > > > 0x06 > > Not needed and Not defined in RFC4328 > > Virtual Concatenated signal, see clause 18 (Note 5) > 61(TBA) > > G.709 ODUk (k=0,3,4) > > 0x07 > > Is being defined in this draft (new payload type defined in [G.709-2012]) > > PCS codeword transparent Ethernet mapping: > · 1000BASE-X into OPU0, see clauses 17.7.1 and 17.7.1.1 > · 40GBASE-R into OPU3, see clauses 17.7.4 and 17.7.4.1 > · 100GBASE-R into OPU4, see clauses 17.7.5 and 17.7.5.1 > 62(TBA) > > G.709 ODUk (k=2e) > > 0x08 > > ditto > > FC-1200 into OPU2e mapping, see clause 17.8.2 > 63(TBA) > > G.709 ODUk (k=2) > > 0x09 > > ditto > > GFP mapping into Extended OPU2 payload, see clause 17.4.1 (Note 6) > 64(TBA) > > G.709 ODUk (k=0) > > 0x0A > > ditto > > STM-1 mapping into OPU0, see clause 17.7.1 > 65(TBA) > > G.709 ODUk (k=0) > > 0x0B > > ditto > > STM-4 mapping into OPU0, see clause 17.7.1 > 66(TBA) > > G.709 ODUk (k=0) > > 0x0C > > ditto > > FC-100 mapping into OPU0, see clause 17.7.1 > 67(TBA) > > G.709 ODUk (k=1) > > 0x0D > > ditto > > FC-200 mapping into OPU1, see clause 17.7.2 > 68(TBA) > > G.709 ODUflex > > 0x0E > > ditto > > FC-400 mapping into OPUflex, see clause 17.9 > 69(TBA) > > G.709 ODUflex > > 0x0F > > ditto > > FC-800 mapping into OPUflex, see clause 17.9 > 51 > > G.709 ODUk > > 0x10 > > 1)G-PID defined in RFC4328; > 2) Updated in this draft. > > Bit stream with octet timing mapping, see clause 17.6.1 > 52 > > G.709 ODUk > > 0x11 > > ditto > > Bit stream without octet timing mapping, see clause 17.6.2 > 70(TBA) > > G.709 ODUflex > > 0x12 > > Is being defined in this draft (new payload type defined in [G.709-2012]) > > IB SDR mapping into OPUflex, see 17.9 > 71(TBA) > > G.709 ODUflex > > 0x13 > > ditto > > IB DDR mapping into OPUflex, see 17.9 > 72(TBA) > > G.709 ODUflex > > 0x14 > > ditto > > IB QDR mapping into OPUflex, see 17.9 > 73(TBA) > > G.709 ODUk (k=0) > > 0x15 > > ditto > > SDI mapping into OPU0, see 17.7.1 > 74(TBA) > > G.709 ODUk (k=1) > > 0x16 > > ditto > > (1.485/1.001) Gbit/s SDI mapping into OPU1, see 17.7.2 > 75(TBA) > > G.709 ODUk (k=1) > > 0x17 > > ditto > > 1.485 Gbit/s SDI mapping into OPU1, see 17.7.2 > 76(TBA) > > G.709 ODUflex > > 0x18 > > ditto > > (2.970/1.001) Gbit/s SDI mapping into OPUflex, see 17.9 > 77(TBA) > > G.709 ODUflex > > 0x19 > > ditto > > 2.970 Gbit/s SDI mapping into OPUflex, see 17.9 > 78(TBA) > > G.709 ODUk (k=0) > > 0x1A > > ditto > > SBCON/ESCON mapping into OPU0, see 17.7.1 > 79(TBA) > > G.709 ODUk (k=0) > > 0x1B > > ditto > > DVB_ASI mapping into OPU0, see 17.7.1 > 47 > > G.709 ODUk > > 0x20 > > 1) G-PIDs defined in RFC4328. > 2) Updated in this draft. > > ODU multiplex structure supporting ODTUjk only, see clause 19 (AMP only) > 59/60 > > G.709 ODUk > > 0x21 > > 1)Are being defined in this draft (new payload type defined in > [G.709-2012]); > 2) 59 for G.709 ODU-1.25G; 60 for G.709 ODU-any > > ODU multiplex structure supporting ODTUk.ts or ODTUk.ts and ODTUjk, see > clause 19 (GMP capable) (Note 7) > None > > > > 55 > > Not needed > > Not available (Note 2) > None > > > > 66 > > Not needed > > Not available (Note 2) > None > > > > 80-8F > > Not needed > > Reserved codes for proprietary use (Note 4) > None > > > > FD > > Not needed > > NULL test signal mapping, see clause 17.5.1 > None > > > > FE > > Not needed > > PRBS test signal mapping, see clause 17.5.2 > None > > > > FF > > Not needed > > Not available (Note 2) > > > > > > > > > > > > > > > Best Regards > > Fatai > > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Wednesday, May 15, 2013 10:58 PM > To: BELOTTI, SERGIO (SERGIO); Fatai Zhang > Cc: Daniele Ceccarelli; CCAMP; > draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org > Subject: Re: R: Closing G.709 open issues > > Sergio/Fatai, > > On 5/15/2013 7:54 AM, BELOTTI, SERGIO (SERGIO) wrote: >> We (as authors" were asked to cope with the remaining issues to start second LC. >> One these "remaining issues" was as fro Lou's mil of May 9th >> >> 2) Verify that the complete list of G-PIDs are defined [SIGNALING] >> >> In signaling document section 4, verify that all payload types >> defined in G.709 (Summarized in Table 15-8) can be represented. >> This issue can be resolved via an update or message to the list >> stating that the verification took place. >> >> This is concluded by Fatai answer regarding G-PID check and 1:1 mapping. > > And, based on the discussion, I (to be clear, as WG chair) have revised > the request by asking: > "that the editors of the draft provide (and include in the document) > a full list of Payload Type values (with the 0x value prefix or the > values in decimal) and their corresponding G-PID values. Also > including Encoding Type as you [Fatai] have below is a good addition > -- great idea!" > > Given the level of discussion of this thread, I think this is a > completely reasonable way to avoid future confusion, particularly in > implementations. > > Do the Authors/Editor need help in generating this complete list? > > Do the Authors/Editor want (me) to issue a call for input on this list? > I suspect some in WG will be happy to jump in as it's an easy way to > get added as a contributor to the signaling draft. > >> >> FATAI> For point 2), I compared [G.709-2003] and [G.709-2012], and checked the GPIDs defined in [RFC4328], I think the following new GPIDs (values could be 59-79) should be added (besides updating some GPIDs defined in RFC4328, like 32,47,49-52): >> >> Value G-PID Type LSP Encoding Type >> ----- ---------- ----------------- >> 59(TBA) G.709 ODU-1.25G G.709 ODUk >> 60(TBA) G.709 ODU-any G.709 ODUk >> 61(TBA) PCS G.709 ODUk (k=0) >> 62(TBA) FC-1200 G.709 ODUk (k=2e) >> 63(TBA) eOPU2 G.709 ODUk (k=2) >> 64(TBA) STM-1 G.709 ODUk (k=0) >> 65(TBA) STM-4 G.709 ODUk (k=0) >> 66(TBA) FC-100 G.709 ODUk (k=0) >> 67(TBA) FC-200 G.709 ODUk (k=1) >> 68(TBA) FC-400 G.709 ODUflex >> 69(TBA) FC-800 G.709 ODUflex >> 70(TBA) IB SDR G.709 ODUflex >> 71(TBA) IB DDR G.709 ODUflex >> 72(TBA) IB QDR G.709 ODUflex >> 73(TBA) SDIa G.709 ODUk (k=0) >> 74(TBA) SDIb G.709 ODUk (k=1) >> 75(TBA) SDIc G.709 ODUk (k=1) >> 76(TBA) SDId G.709 ODUflex >> 77(TBA) SDIe G.709 ODUflex >> 78(TBA) SB/ESCON G.709 ODUk (k=0) >> 79(TBA) DVB_ASI G.709 ODUk (k=0) >> > >> All this has nothing to do with specifc ADAPTATION object , for which I was always in favour but it seems as though it is linked to MRN discussion and out of specifc OTN. >> > > So I went looking for past discussions on this, and this is what I find: > > - From http://www.ietf.org/mail-archive/web/ccamp/current/msg13598.html > On 7/19/2012 11:45 AM, Lou Berger wrote: >> (As participant in thread) I read that the conclusion is to not optimize >> for a very special corner case and: >> 1) basically treat the intra-OTN case the same as any other MRN/MLN case >> (leveraging GPID, and no new hierarchy object) >> 2) Use Daniele's new draft on MRN/MLN as the starting point in the >> discussion of how to address the limitations in MRN/MLN identified in >> this discussion. > > From http://tools.ietf.org/agenda/84/slides/slides-84-ccamp-7.pdf >> G-PID Value Extension >> o Extended G-PID for G.709 ODU client signals: >> Value G-PID Type TSG (LO ODU into requested LSP) >> ----- ---------- ---------------- >> 47 G.709 ODU 2.5Gbps [RFC4328] >> 59(TBA) G.709 ODU-1.25G 1.25Gbps (new) >> 60(TBA) G.709 ODU-any either 1.25 or 2.5Gbps(new) >> >> o Added other new G-PID values for new client signals supported by G.709V3 >> Value G-PID Type >> ----- ---------- >> 61(TBA) CBRc (via GMP) >> 62(TBA) 1000BASE-X >> 63(TBA) FC-1200 >> >> o Updated some existing G-PID description to support new 1.25G, 100G, >> supra-2.488G client signals, such as 32 for ATM, 49 for asynchronous >> CBR , 50 for synchronous CBR , 51 for BSOT, 52 for BSNT. > > I have not interest/need to revist past consensus on G-PIDs & TSGs, so > will limit my comments to the newly defined G-PIDs. > > My questions on the new G-PIDs come down to: > - Why are rate specific G-PIDs being proposed (rather than > continuing to use the previous approach documented in the draft > and in Section 3.1.3 of rfc4328)? > > - Why are new values being defined rather than using existing > values, e.g., G-PID 56? > > That's it. > > Lou > >> Hope this can help. >> >> Best Regards >> Sergio >> >> Belotti Sergio- System Architect >> ALCATE-LUCENT Optics Division >> via Trento 30 Vimercate (MB) - Italy >> phone +39 (039) 6863033 >> >> -----Messaggio originale----- >> Da: Lou Berger [mailto:lberger@labn.net] >> Inviato: mercoledì15 maggio 2013 13.22 >> A: Daniele Ceccarelli; Fatai Zhang >> Cc: BELOTTI, SERGIO (SERGIO); CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org >> Oggetto: RE: Closing G.709 open issues >> >> Daniele, >> >> On May 15, 2013 4:20:25 AM Daniele Ceccarelli >> wrote: >>> Hi Lou, >>> >>> Just a bit. >>>> My memory is that the consensus at the time was that G.709 would continue >>> to use the current generic approach to edge adaptation & G-PIDs, and that >>> (some of) the G.709 authors would submit a draft that would address >>> adaptation in a generic fashion. >>>> >>> >>> If i correctly remember we agreed to solve the routing issu in a generic >>> approach, not the signaling one. >> >> We must be thinking of different threads. The one I'm thinking of started >> with the comment along the lines of "why only some G-PIDs represented in >> the ADAPTATION object" and concluded with the agreement to drop the object >> and follow the current generic approach as well as look into a non-OTN >> specific solution in a new draft. At least that's how I remember it.... >> >>> It is possible to assume that the adaptation is a known info to the >>> operator and hence that the advertisement can be postponed and addressed in >>> a generic way but it needs to be signaled. >>> >>> This is an hortogonal issue with respect to the mapping of G-PID, which has >>> always been assumed to be 1:1 with G.709 values. >> >> humm, this seems inconsistent with Fatai recently suggesting that i was >> asking for a "non-grouped" approach. At the time, I was really just >> thinking about the values missing in the list I sent out. I don't recall >> any other discussion on moving away from the past 709 G-PID assignment >> approach. >> >>> The 1:1 *mapping* approach used by Fatai is different from the *mapping" >>> protocol like GFP, AMP that we discussed before. >>> >> >> It looks like we both/all should take a look at the archives to refresh our >> memories.... >> >> Thanks, >> Lou >> >>> BR >>> Daniele, Sergio, Fatai >>> >>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] Sent: martedì14 maggio 2013 16.01 >>>> To: Fatai Zhang >>>> Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; >>> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; >>> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org >>>> Subject: Re: Closing G.709 open issues >>>> >>>> Fatai, Sergio, >>>> I haven't had time to go find the old mail covering the topic you >>> mentioned (which is why I didn't respond yesterday): >>>>> I think this has been discussed for quite long time before Vancouver >>> meeting, which was famous as "penultimate" issue. >>>>> >>>>> I don't think we need discuss this anymore. >>>> >>>> My memory is that the consensus at the time was that G.709 would continue >>> to use the current generic approach to edge adaptation & G-PIDs, and that >>> (some of) the G.709 authors would submit a draft that would address >>> adaptation in a generic fashion. >>>> >>>> Do you think this characterization is mistaken? (If so, time to go >>> searching for the old discussion, if not we can move on.) >>>> >>>> Assuming no, then it seems to me that you are going against this >>> discussion & consensus by now introducing a 1:1/bandwidth specific mapping >>> approach. Do you disagree? If not, do you think there's justification to >>> reopen this discussion? >>>> >>>> Independent of the mapping approach and in order to ensure this issue is >>> closed and does not again resurface, I also request (again) that the >>> editors of the draft provide (and include in the document) a full list of >>> Payload Type values (with the 0x value prefix or the values in >>>> decimal) and their corresponding G-PID values. Also including Encoding >>> Type as you have below is a good addition -- great idea! >>>> >>>> Lou >>>> >>>> On 5/14/2013 1:53 AM, Fatai Zhang wrote: >>>>> Hi all, >>>>> Thanks, Sergio. >>>>> I would like to double check if everything is OK before we >update the >>> signaling draft. >>>>> I would assume the WG is happy with 1:1 mapping approach and >the new >>> GPIDs listed below if there is no more comment until this Wed. >>>>> >>>>> Best Regards >>>>> Fatai >>>>> >>>>> -----Original Message----- >>>>> From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-lucent.com] >>>>> Sent: Monday, May 13, 2013 3:45 PM >>>>> To: Fatai Zhang; Lou Berger >>>>> Cc: Daniele Ceccarelli; CCAMP; >>> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; >>> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org >>>>> Subject: R: Closing G.709 open issues >>>>> Hi Fatai, >>>>> I agree with you, for both point 1 and 2. >>>>> Best Regards >>>>> Sergio >>>>> Belotti Sergio- System Architect >>>>> ALCATE-LUCENT Optics Division >>>>> via Trento 30 Vimercate (MB) - Italy >>>>> phone +39 (039) 6863033 >>>>> -----Messaggio originale----- >>>>> Da: Fatai Zhang [mailto:zhangfatai@huawei.com] >>>>> Inviato: lunedì13 maggio 2013 5.33 >>>>> A: Lou Berger >>>>> Cc: Daniele Ceccarelli; CCAMP; >>> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; >>> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org >>>>> Oggetto: RE: Closing G.709 open issues >>>>> Hi Lou, >>>>> I think you have two major points here. >>>>> (1) Do you really need 3 G-PID types for an ODU (I thought >TSG was >>> already covered)? >>>>> I think this has been discussed for quite long time before >Vancouver >>> meeting, which was famous as "penultimate" issue. >Note that this TSG in >>> GPID is different from the *implicit* >TSG in label format. >>>>> I don't think we need discuss this anymore. >>>>> (2) 'Grouped GPID' vs '1:1' mapping (between G.709-2012 and GPIDs >>> defined in this draft) >>>>> We realize that it is safe to use 1:1 mapping approach to >avoid some >>> potential issues after investigation. We know this >payload types have been >>> defined by G.709 (data plane), so >physically it is better to use 1:1 >>> mapping approach. For the potential issues I mentioned above, for example, >>> we >cannot use the existing 34 to represent 'STM-1' and 'STM-4 ', >because >>> it is impossible to differentiate which one is 'STM-1' >or 'STM-4'. In >>> addition, from the concept of payload type, we >know that e.g, FC-100 is >>> different from FC-800, right? So, it >is better to assign different GPIDs >>> to these different payload >types defined by the data plane. >>>>> Furthermore, I think it is much cheaper to create new GPIDs >in the >>> control plane than in the data plane (these payload >types will be carried >>> in the OH). >>>>> >>>>> Best Regards >>>>> Fatai >>>>> >>>>> -----Original Message----- >>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>> Sent: Friday, May 10, 2013 8:51 PM >>>>> To: Fatai Zhang >>>>> Cc: Daniele Ceccarelli; CCAMP; >>> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; >>> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org >>>>> Subject: Re: Closing G.709 open issues >>>>> >>>>> On 5/9/2013 9:41 PM, Fatai Zhang wrote: >>>>>> Hi Lou, >>>>>> >>>>>> For point 1), "1" should be dropped and "7" should be >corrected to "8" >>> in your proposed text. >> >> Great. >>>>>>>> >>>>>> I hesitate to make a decision on either approach, I would >like to >>> defer to the WG consensus. >>>>>> >>>>> I believe we already have a consensus position. The question in my mail >>> was do we need to revisit it. I take your response as a no. (thank you!) >>>>>>>> For point 2), I compared [G.709-2003] and [G.709-2012], and checked >>>>>> the GPIDs defined in [RFC4328], I think the following new GPIDs >>> >>> (values could be 59-79) should be added (besides updating >some GPIDs >>> >>> defined in RFC4328, like 32,47,49-52): >>>>>> >>>>> I suggest going through the full PT list and identifying them in the >>> table (as I started in my last message) so that there is no >confusion in >>> implementations. >>>>> In the list below it looks like you have moved away from the >'grouped >>> G-PID' approach. Is there a reason for this change? >>>>> Refer to >>>>>> http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-paramet >>>>> ers.xml >>>>> in subsequent comments. >>>>>>>> Value G-PID Type LSP Encoding Type >>>>>> ----- ---------- ----------------- >>>>>> 59(TBA) G.709 ODU-1.25G G.709 ODUk 60(TBA) G.709 >>> ODU-any G.709 ODUk >>>>> Do you really need 3 G-PID types for an ODU (I thought TSG >was already >>> covered)? >>>>>>>> 61(TBA) PCS G.709 ODUk (k=0) >>>>>> 62(TBA) FC-1200 G.709 ODUk (k=2e) >>>>> Why not us existing G-PID 58? >>>>>>>> 63(TBA) eOPU2 G.709 ODUk (k=2) >>>>>>>> 64(TBA) STM-1 G.709 ODUk (k=0) >>>>>> 65(TBA) STM-4 G.709 ODUk (k=0) >>>>> Why not us existing G-PID 34? >>>>>>>> 66(TBA) FC-100 G.709 ODUk (k=0) >>>>>> 67(TBA) FC-200 G.709 ODUk (k=1) >>>>>> 68(TBA) FC-400 G.709 ODUflex >>>>>> 69(TBA) FC-800 G.709 ODUflex >>>>> Why not us existing G-PID 58? >>>>>>>> 70(TBA) IB SDR G.709 ODUflex >>>>>> 71(TBA) IB DDR G.709 ODUflex >>>>>> 72(TBA) IB QDR G.709 ODUflex >>>>> Can these be one value with rate implying SDR/DDR/QDR? >>>>>>>> 73(TBA) SDIa G.709 ODUk (k=0) >>>>>> 74(TBA) SDIb G.709 ODUk (k=1) >>>>>> 75(TBA) SDIc G.709 ODUk (k=1) >>>>>> 76(TBA) SDId G.709 ODUflex >>>>>> 77(TBA) SDIe G.709 ODUflex >>>>> Can these be one value with rate implying a-e? >>>>>>>> 78(TBA) SB/ESCON G.709 ODUk (k=0) >>>>> Why not us existing G-PID 56? >>>>>>>> 79(TBA) DVB_ASI G.709 ODUk (k=0) >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Thanks, >>>>> Lou >>>>> >>>>> >>>>> >>>> >> >> >> >> >> >> > From lberger@labn.net Fri May 17 09:17:34 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B41C21F97D0 for ; Fri, 17 May 2013 09:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.065 X-Spam-Level: X-Spam-Status: No, score=-103.065 tagged_above=-999 required=5 tests=[AWL=0.534, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-inJUeGAPk3 for ; Fri, 17 May 2013 09:17:30 -0700 (PDT) Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id EAE9021F97BC for ; Fri, 17 May 2013 09:17:29 -0700 (PDT) Received: (qmail 1479 invoked by uid 0); 17 May 2013 16:17:08 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy12.bluehost.com with SMTP; 17 May 2013 16:17:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=8/BlHGysdR7YMJdDVCNafNp6cZ83xyO07cGfVApH2cQ=; b=Q+w0mp0P9NWQiF6HYNPi+aXbgL6muppNshFUh2kM2HJSmel97+fJXqaeEygs2lW5RNkvsJpvP+j2iIOZ1DfrPF8kYppQH6ri01ibhQqTxQxQFpLrH2MfwnRg4x3aSj8M; Received: from box313.bluehost.com ([69.89.31.113]:41934 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UdNLA-0007bj-Bo; Fri, 17 May 2013 10:17:08 -0600 Message-ID: <519657FE.5030602@labn.net> Date: Fri, 17 May 2013 12:17:02 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Fatai Zhang References: <518A82D9.7080508@labn.net> <518BAB17.9090807@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" , CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" Subject: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 open issues) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 16:17:34 -0000 Authors/WG, From the mail on the list it seems to me that we've reached closure on Issue #48: "Document no explicit indication of TSG in the label" (http://trac.tools.ietf.org/wg/ccamp/trac/ticket/48). I'd like to confirm my reading. As I read the list, this issue will be resolved by making the following change to draft-ietf-ccamp-gmpls-signaling-g709v3. OLD Note that the Length field in the label format MAY be used to indicate the TS type of the HO ODUk (i.e., TS granularity at 1.25Gbps or 2.5Gbps) since the HO ODUk type can be known from IF_ID RSVP_HOP Object. In some cases when there is no Link Management Protocol (LMP) or routing to make the two end points of the link to know the TSG, the TSG information used by another end can be deduced from the label format. For example, for HO ODU2 link, the value of the length filed will be 4 or 8, which indicates the TS granularity is 2.5Gbps or 1.25Gbps, respectively. NEW Please note that the TS granularity of an HO ODUk can be inferred from the length of the label. The values of 4 and 16 indicate a TS granularity of 2.5Gps, while the values 2, 8, 32 and 80 indicate a TS granularity of 1.25Gps. Please speak up if you disagree with this resolution. Thanks, Lou On 5/9/2013 9:41 PM, Fatai Zhang wrote: > For point 1), "1" should be dropped and "7" should be corrected to "8" in your proposed text. > From jdrake@juniper.net Fri May 17 10:21:13 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B353121F9717 for ; Fri, 17 May 2013 10:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.467 X-Spam-Level: X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNmAioW4KcTp for ; Fri, 17 May 2013 10:21:07 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB7921F97B0 for ; Fri, 17 May 2013 10:20:43 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUZZm6nZNJ7+9A1d5i3jz+1ox7r7ubVWI@postini.com; Fri, 17 May 2013 10:20:43 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 17 May 2013 10:15:59 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Fri, 17 May 2013 10:15:59 -0700 Received: from am1outboundpool.messaging.microsoft.com (213.199.154.207) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 17 May 2013 10:26:50 -0700 Received: from mail101-am1-R.bigfish.com (10.3.201.236) by AM1EHSOBE010.bigfish.com (10.3.204.30) with Microsoft SMTP Server id 14.1.225.23; Fri, 17 May 2013 17:15:56 +0000 Received: from mail101-am1 (localhost [127.0.0.1]) by mail101-am1-R.bigfish.com (Postfix) with ESMTP id 593A5C0E78 for ; Fri, 17 May 2013 17:15:56 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT003.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -46 X-BigFish: PS-46(z21aILzbb2dI98dI9371I542I1432I4015Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1155h) Received: from mail101-am1 (localhost.localdomain [127.0.0.1]) by mail101-am1 (MessageSwitch) id 136881093133400_3197; Fri, 17 May 2013 17:15:31 +0000 (UTC) Received: from AM1EHSMHS016.bigfish.com (unknown [10.3.201.249]) by mail101-am1.bigfish.com (Postfix) with ESMTP id 05A083E02DC; Fri, 17 May 2013 17:15:31 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS016.bigfish.com (10.3.207.154) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 17 May 2013 17:15:25 +0000 Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.1.63]) by BL2PRD0510HT003.namprd05.prod.outlook.com ([10.255.100.38]) with mapi id 14.16.0311.000; Fri, 17 May 2013 17:15:24 +0000 From: John E Drake To: Lou Berger , Fatai Zhang Thread-Topic: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 open issues) Thread-Index: AQHOUxolXg1utrqdnEm+hHhHNvjEopkJnSEg Date: Fri, 17 May 2013 17:15:23 +0000 Message-ID: <0182DEA5604B3A44A2EE61F3EE3ED69E1D5009B0@BL2PRD0510MB349.namprd05.prod.outlook.com> References: <518A82D9.7080508@labn.net> <518BAB17.9090807@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> <519657FE.5030602@labn.net> In-Reply-To: <519657FE.5030602@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.53] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%LABN.NET$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%HUAWEI.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" , CCAMP Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 open issues) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 17:21:13 -0000 Lou, I think the original text is fine and your attempted re-write completely ma= ngled its meaning. The label is a bit vector whose length is equal to the = ODUk rate / TSG.=20 Irrespectively Yours, John > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Lou Berger > Sent: Friday, May 17, 2013 9:17 AM > To: Fatai Zhang > Cc: draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; CCAMP; draft- > ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org > Subject: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 > open issues) >=20 > Authors/WG, > From the mail on the list it seems to me that we've reached > closure on Issue #48: "Document no explicit indication of TSG in the > label" > (http://trac.tools.ietf.org/wg/ccamp/trac/ticket/48). I'd like to > confirm my reading. >=20 > As I read the list, this issue will be resolved by making the following > change to draft-ietf-ccamp-gmpls-signaling-g709v3. >=20 > OLD > Note that the > Length field in the label format MAY be used to indicate the TS > type of the HO ODUk (i.e., TS granularity at 1.25Gbps or 2.5Gbps) > since the HO ODUk type can be known from IF_ID RSVP_HOP Object. In > some cases when there is no Link Management Protocol (LMP) or > routing to make the two end points of the link to know the TSG, > the TSG information used by another end can be deduced from the > label format. For example, for HO ODU2 link, the value of the > length filed will be 4 or 8, which indicates the TS granularity is > 2.5Gbps or 1.25Gbps, respectively. >=20 > NEW > Please note that the TS granularity of an HO ODUk can be inferred > from > the length of the label. The values of 4 and 16 indicate a TS > granularity of 2.5Gps, while the values 2, 8, 32 and 80 indicate a TS > granularity of 1.25Gps. >=20 > Please speak up if you disagree with this resolution. >=20 > Thanks, > Lou >=20 > On 5/9/2013 9:41 PM, Fatai Zhang wrote: > > For point 1), "1" should be dropped and "7" should be corrected to > "8" in your proposed text. > > >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From lberger@labn.net Fri May 17 13:33:01 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6990921F9626 for ; Fri, 17 May 2013 13:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.437 X-Spam-Level: X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[AWL=-0.172, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4rCVezqToLR for ; Fri, 17 May 2013 13:32:57 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 686B221F9664 for ; Fri, 17 May 2013 13:32:53 -0700 (PDT) Received: (qmail 21572 invoked by uid 0); 17 May 2013 20:32:31 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.bluehost.com with SMTP; 17 May 2013 20:32:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=/KBfCjgtyiRnC+J+ud6FdKz9QWgjlfiUoretjyemXS8=; b=eni6haVl/diZnEmG363SbqPXBR6sVYNAuVex+fQxh4B9yqdXz6yTYJe2jgvDNRKWIqjQXaV4hhFlzeBZd013A8KpXSpvWdHUJxa65A9WRQGWJScahMgcsNaBjGeDRCX1; Received: from box313.bluehost.com ([69.89.31.113]:46068 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UdRKJ-0003sF-Da; Fri, 17 May 2013 14:32:31 -0600 Message-ID: <519693DF.6000003@labn.net> Date: Fri, 17 May 2013 16:32:31 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: John E Drake References: <518A82D9.7080508@labn.net> <518BAB17.9090807@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> <519657FE.5030602@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D5009B0@BL2PRD0510MB349.namprd05.prod.outlook.com> In-Reply-To: <0182DEA5604B3A44A2EE61F3EE3ED69E1D5009B0@BL2PRD0510MB349.namprd05.prod.outlook.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" , "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" , CCAMP Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 open issues) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 20:33:01 -0000 John, I guess you haven't been paying attention! The rewrite originated from Daniele, was tweaked by me and then fixed by Fatai. Do you have an alternate proposal to address issue#48? Issue #48="In signaling document section 6: Clarify related text [i.e., the OLD text] to unambiguously identify the relationship between label length and TSG." Thanks, Lou On 5/17/2013 1:15 PM, John E Drake wrote: > Lou, > > I think the original text is fine and your attempted re-write completely mangled its meaning. The label is a bit vector whose length is equal to the ODUk rate / TSG. > > Irrespectively Yours, > > John > > >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf >> Of Lou Berger >> Sent: Friday, May 17, 2013 9:17 AM >> To: Fatai Zhang >> Cc: draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; CCAMP; draft- >> ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >> Subject: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 >> open issues) >> >> Authors/WG, >> From the mail on the list it seems to me that we've reached >> closure on Issue #48: "Document no explicit indication of TSG in the >> label" >> (http://trac.tools.ietf.org/wg/ccamp/trac/ticket/48). I'd like to >> confirm my reading. >> >> As I read the list, this issue will be resolved by making the following >> change to draft-ietf-ccamp-gmpls-signaling-g709v3. >> >> OLD >> Note that the >> Length field in the label format MAY be used to indicate the TS >> type of the HO ODUk (i.e., TS granularity at 1.25Gbps or 2.5Gbps) >> since the HO ODUk type can be known from IF_ID RSVP_HOP Object. In >> some cases when there is no Link Management Protocol (LMP) or >> routing to make the two end points of the link to know the TSG, >> the TSG information used by another end can be deduced from the >> label format. For example, for HO ODU2 link, the value of the >> length filed will be 4 or 8, which indicates the TS granularity is >> 2.5Gbps or 1.25Gbps, respectively. >> >> NEW >> Please note that the TS granularity of an HO ODUk can be inferred >> from >> the length of the label. The values of 4 and 16 indicate a TS >> granularity of 2.5Gps, while the values 2, 8, 32 and 80 indicate a TS >> granularity of 1.25Gps. >> >> Please speak up if you disagree with this resolution. >> >> Thanks, >> Lou >> >> On 5/9/2013 9:41 PM, Fatai Zhang wrote: >>> For point 1), "1" should be dropped and "7" should be corrected to >> "8" in your proposed text. >>> >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > > From kpithewan@infinera.com Sun May 19 05:27:00 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4874221F84AD for ; Sun, 19 May 2013 05:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzcIkt5TbvW8 for ; Sun, 19 May 2013 05:26:56 -0700 (PDT) Received: from sv-casht-prod1.infinera.com (sv-casht-prod1.infinera.com [8.4.225.24]) by ietfa.amsl.com (Postfix) with ESMTP id A1AA821F847F for ; Sun, 19 May 2013 05:26:54 -0700 (PDT) Received: from SV-EXDB-PROD2.infinera.com ([fe80::1d05:1822:aaea:ff52]) by sv-casht-prod1.infinera.com ([10.100.97.218]) with mapi id 14.03.0123.003; Sun, 19 May 2013 05:26:53 -0700 From: Khuzema Pithewan To: Fatai Zhang , Lou Berger , "BELOTTI, SERGIO (SERGIO)" Thread-Topic: R: Closing G.709 open issues Thread-Index: AQHOUtRa2DP443BrzUqEe/rBVrfkQZkMcJkw Date: Sun, 19 May 2013 12:26:52 +0000 Message-ID: References: <518A82D9.7080508@labn.net> <518BAB17.9090807@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> <518CED28.30303@labn.net> <51924382.2010904@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C90D5@ESESSMB301.ericsson.se> <13ea7ed3bdd.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <5193A26A.1090005@labn.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.156.118] Content-Type: multipart/alternative; boundary="_000_D8D01B39D6B38C45AA37C06ECC1D65D53FD6C47ESVEXDBPROD2infi_" MIME-Version: 1.0 Cc: CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" Subject: Re: [CCAMP] R: Closing G.709 open issues X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 May 2013 12:27:00 -0000 --_000_D8D01B39D6B38C45AA37C06ECC1D65D53FD6C47ESVEXDBPROD2infi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Fatai, I think we should (continue to) keep GPid as technology indicator and use = rate in signal Type to make sense of payload. For example, FC-100, GPid =3D 43 (FiberChannel) and SignalType=3DODU0 (10),= will give you payload FC-100. Do you see any case, where it can be ambiguous? Thanks Khuzema From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of F= atai Zhang Sent: Friday, May 17, 2013 1:28 PM To: Lou Berger; BELOTTI, SERGIO (SERGIO) Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org Subject: Re: [CCAMP] R: Closing G.709 open issues Hi Lou, I thought it should be sufficient for me to identify the *updated* and *new= * G-PIDs in this draft (I compared [G.709-2003] and [G.709-2012], and check= ed RFC4328), but I would be happy to provide a full list for your request. Please see the list below, and the new payload types introduced by [G.709-2= 012] (and the corresponding new G-PIDs defined in this draft) are in the li= ght blue cells. Please check if there is anything missed or wrong. Note that GPIDs like 32,= 47,49-52 have been updated in this draft. Note that we as authors welcome any contributors for their contribution. For you convenience, I also attached the word document. G-PIDs vs Payload types defined in Table 15-8 of G.709 G-PID LSP Encoding Payload Type in Hex code defined in G.709 Note Interpretation from G.709 None 0x01 Not needed Experimental mapping (Note 3) 49 G.709 ODUk, G.709 OCh 0x02 1)G-PID defined in RFC4328; 2) Updated in this draft. Asynchronous CBR mapping, see clause 17.2 50 G.709 ODUk 0x03 ditto Bit synchronous CBR mapping, see clause 17.2 32 SDH, G.709 ODUk 0x04 ditto ATM mapping, see clause 17.3 54 G.709 ODUk (and SDH) 0x05 G-PIDs defined in RFC4328 with two kinds of GFPs (Ethernet MAC (framed GFP) GFP mapping, see clause 17.4 None 0x06 Not needed and Not defined in RFC4328 Virtual Concatenated signal, see clause 18 (Note 5) 61(TBA) G.709 ODUk (k=3D0,3,4) 0x07 Is being defined in this draft (new payload type defined in [G.709-2012]) PCS codeword transparent Ethernet mapping: =B7 1000BASE-X into OPU0, see clauses 17.7.1 and 17.7.1.1 =B7 40GBASE-R into OPU3, see clauses 17.7.4 and 17.7.4.1 =B7 100GBASE-R into OPU4, see clauses 17.7.5 and 17.7.5.1 62(TBA) G.709 ODUk (k=3D2e) 0x08 ditto FC-1200 into OPU2e mapping, see clause 17.8.2 63(TBA) G.709 ODUk (k=3D2) 0x09 ditto GFP mapping into Extended OPU2 payload, see clause 17.4.1 (Note 6) 64(TBA) G.709 ODUk (k=3D0) 0x0A ditto STM-1 mapping into OPU0, see clause 17.7.1 65(TBA) G.709 ODUk (k=3D0) 0x0B ditto STM-4 mapping into OPU0, see clause 17.7.1 66(TBA) G.709 ODUk (k=3D0) 0x0C ditto FC-100 mapping into OPU0, see clause 17.7.1 67(TBA) G.709 ODUk (k=3D1) 0x0D ditto FC-200 mapping into OPU1, see clause 17.7.2 68(TBA) G.709 ODUflex 0x0E ditto FC-400 mapping into OPUflex, see clause 17.9 69(TBA) G.709 ODUflex 0x0F ditto FC-800 mapping into OPUflex, see clause 17.9 51 G.709 ODUk 0x10 1)G-PID defined in RFC4328; 2) Updated in this draft. Bit stream with octet timing mapping, see clause 17.6.1 52 G.709 ODUk 0x11 ditto Bit stream without octet timing mapping, see clause 17.6.2 70(TBA) G.709 ODUflex 0x12 Is being defined in this draft (new payload type defined in [G.709-2012]) IB SDR mapping into OPUflex, see 17.9 71(TBA) G.709 ODUflex 0x13 ditto IB DDR mapping into OPUflex, see 17.9 72(TBA) G.709 ODUflex 0x14 ditto IB QDR mapping into OPUflex, see 17.9 73(TBA) G.709 ODUk (k=3D0) 0x15 ditto SDI mapping into OPU0, see 17.7.1 74(TBA) G.709 ODUk (k=3D1) 0x16 ditto (1.485/1.001) Gbit/s SDI mapping into OPU1, see 17.7.2 75(TBA) G.709 ODUk (k=3D1) 0x17 ditto 1.485 Gbit/s SDI mapping into OPU1, see 17.7.2 76(TBA) G.709 ODUflex 0x18 ditto (2.970/1.001) Gbit/s SDI mapping into OPUflex, see 17.9 77(TBA) G.709 ODUflex 0x19 ditto 2.970 Gbit/s SDI mapping into OPUflex, see 17.9 78(TBA) G.709 ODUk (k=3D0) 0x1A ditto SBCON/ESCON mapping into OPU0, see 17.7.1 79(TBA) G.709 ODUk (k=3D0) 0x1B ditto DVB_ASI mapping into OPU0, see 17.7.1 47 G.709 ODUk 0x20 1) G-PIDs defined in RFC4328. 2) Updated in this draft. ODU multiplex structure supporting ODTUjk only, see clause 19 (AMP only) 59/60 G.709 ODUk 0x21 1)Are being defined in this draft (new payload type defined in [G.709-2012]= ); 2) 59 for G.709 ODU-1.25G; 60 for G.709 ODU-any ODU multiplex structure supporting ODTUk.ts or ODTUk.ts and ODTUjk, see cla= use 19 (GMP capable) (Note 7) None 55 Not needed Not available (Note 2) None 66 Not needed Not available (Note 2) None 80-8F Not needed Reserved codes for proprietary use (Note 4) None FD Not needed NULL test signal mapping, see clause 17.5.1 None FE Not needed PRBS test signal mapping, see clause 17.5.2 None FF Not needed Not available (Note 2) Best Regards Fatai -----Original Message----- From: Lou Berger [mailto:lberger@labn.net] Sent: Wednesday, May 15, 2013 10:58 PM To: BELOTTI, SERGIO (SERGIO); Fatai Zhang Cc: Daniele Ceccarelli; CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tool= s.ietf.org Subject: Re: R: Closing G.709 open issues Sergio/Fatai, On 5/15/2013 7:54 AM, BELOTTI, SERGIO (SERGIO) wrote: > We (as authors" were asked to cope with the remaining issues to start sec= ond LC. > One these "remaining issues" was as fro Lou's mil of May 9th > > 2) Verify that the complete list of G-PIDs are defined [SIGNALING] > > In signaling document section 4, verify that all payload types > defined in G.709 (Summarized in Table 15-8) can be represented. > This issue can be resolved via an update or message to the list > stating that the verification took place. > > This is concluded by Fatai answer regarding G-PID check and 1:1 mapping. And, based on the discussion, I (to be clear, as WG chair) have revised the request by asking: "that the editors of the draft provide (and include in the document) a full list of Payload Type values (with the 0x value prefix or the values in decimal) and their corresponding G-PID values. Also including Encoding Type as you [Fatai] have below is a good addition -- great idea!" Given the level of discussion of this thread, I think this is a completely reasonable way to avoid future confusion, particularly in implementations. Do the Authors/Editor need help in generating this complete list? Do the Authors/Editor want (me) to issue a call for input on this list? I suspect some in WG will be happy to jump in as it's an easy way to get added as a contributor to the signaling draft. > > FATAI> For point 2), I compared [G.709-2003] and [G.709-2012], and checke= d the GPIDs defined in [RFC4328], I think the following new GPIDs (values c= ould be 59-79) should be added (besides updating some GPIDs defined in RFC4= 328, like 32,47,49-52): > > Value G-PID Type LSP Encoding Type > ----- ---------- ----------------- > 59(TBA) G.709 ODU-1.25G G.709 ODUk > 60(TBA) G.709 ODU-any G.709 ODUk > 61(TBA) PCS G.709 ODUk (k=3D0) > 62(TBA) FC-1200 G.709 ODUk (k=3D2e) > 63(TBA) eOPU2 G.709 ODUk (k=3D2) > 64(TBA) STM-1 G.709 ODUk (k=3D0) > 65(TBA) STM-4 G.709 ODUk (k=3D0) > 66(TBA) FC-100 G.709 ODUk (k=3D0) > 67(TBA) FC-200 G.709 ODUk (k=3D1) > 68(TBA) FC-400 G.709 ODUflex > 69(TBA) FC-800 G.709 ODUflex > 70(TBA) IB SDR G.709 ODUflex > 71(TBA) IB DDR G.709 ODUflex > 72(TBA) IB QDR G.709 ODUflex > 73(TBA) SDIa G.709 ODUk (k=3D0) > 74(TBA) SDIb G.709 ODUk (k=3D1) > 75(TBA) SDIc G.709 ODUk (k=3D1) > 76(TBA) SDId G.709 ODUflex > 77(TBA) SDIe G.709 ODUflex > 78(TBA) SB/ESCON G.709 ODUk (k=3D0) > 79(TBA) DVB_ASI G.709 ODUk (k=3D0) > > All this has nothing to do with specifc ADAPTATION object , for which I = was always in favour but it seems as though it is linked to MRN discussion = and out of specifc OTN. > So I went looking for past discussions on this, and this is what I find: - From http://www.ietf.org/mail-archive/web/ccamp/current/msg13598.html On 7/19/2012 11:45 AM, Lou Berger wrote: > (As participant in thread) I read that the conclusion is to not optimize > for a very special corner case and: > 1) basically treat the intra-OTN case the same as any other MRN/MLN case > (leveraging GPID, and no new hierarchy object) > 2) Use Daniele's new draft on MRN/MLN as the starting point in the > discussion of how to address the limitations in MRN/MLN identified in > this discussion. >From http://tools.ietf.org/agenda/84/slides/slides-84-ccamp-7.pdf > G-PID Value Extension > o Extended G-PID for G.709 ODU client signals: > Value G-PID Type TSG (LO ODU into requested LSP) > ----- ---------- ---------------- > 47 G.709 ODU 2.5Gbps [RFC4328] > 59(TBA) G.709 ODU-1.25G 1.25Gbps (new) > 60(TBA) G.709 ODU-any either 1.25 or 2.5Gbps(new) > > o Added other new G-PID values for new client signals supported by G.709V= 3 > Value G-PID Type > ----- ---------- > 61(TBA) CBRc (via GMP) > 62(TBA) 1000BASE-X > 63(TBA) FC-1200 > > o Updated some existing G-PID description to support new 1.25G, 100G, > supra-2.488G client signals, such as 32 for ATM, 49 for asynchronous > CBR , 50 for synchronous CBR , 51 for BSOT, 52 for BSNT. I have not interest/need to revist past consensus on G-PIDs & TSGs, so will limit my comments to the newly defined G-PIDs. My questions on the new G-PIDs come down to: - Why are rate specific G-PIDs being proposed (rather than continuing to use the previous approach documented in the draft and in Section 3.1.3 of rfc4328)? - Why are new values being defined rather than using existing values, e.g., G-PID 56? That's it. Lou > Hope this can help. > > Best Regards > Sergio > > Belotti Sergio- System Architect > ALCATE-LUCENT Optics Division > via Trento 30 Vimercate (MB) - Italy > phone +39 (039) 6863033 > > -----Messaggio originale----- > Da: Lou Berger [mailto:lberger@labn.net] > Inviato: mercoled=EC 15 maggio 2013 13.22 > A: Daniele Ceccarelli; Fatai Zhang > Cc: BELOTTI, SERGIO (SERGIO); CCAMP; draft-ietf-ccamp-gmpls-signaling-g70= 9v3@tools.ietf.org; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org > Oggetto: RE: Closing G.709 open issues > > Daniele, > > On May 15, 2013 4:20:25 AM Daniele Ceccarelli > >= wrote: >> Hi Lou, >> >> Just a bit. >>> My memory is that the consensus at the time was that G.709 would contin= ue >> to use the current generic approach to edge adaptation & G-PIDs, and tha= t >> (some of) the G.709 authors would submit a draft that would address >> adaptation in a generic fashion. >>> >> >> If i correctly remember we agreed to solve the routing issu in a generic >> approach, not the signaling one. > > We must be thinking of different threads. The one I'm thinking of started > with the comment along the lines of "why only some G-PIDs represented in > the ADAPTATION object" and concluded with the agreement to drop the objec= t > and follow the current generic approach as well as look into a non-OTN > specific solution in a new draft. At least that's how I remember it.... > >> It is possible to assume that the adaptation is a known info to the >> operator and hence that the advertisement can be postponed and addressed= in >> a generic way but it needs to be signaled. >> >> This is an hortogonal issue with respect to the mapping of G-PID, which = has >> always been assumed to be 1:1 with G.709 values. > > humm, this seems inconsistent with Fatai recently suggesting that i was > asking for a "non-grouped" approach. At the time, I was really just > thinking about the values missing in the list I sent out. I don't recall > any other discussion on moving away from the past 709 G-PID assignment > approach. > >> The 1:1 *mapping* approach used by Fatai is different from the *mapping" >> protocol like GFP, AMP that we discussed before. >> > > It looks like we both/all should take a look at the archives to refresh o= ur > memories.... > > Thanks, > Lou > >> BR >> Daniele, Sergio, Fatai >> >> >>> -----Original Message----- >>> From: Lou Berger [mailto:lberger@labn.net] Sent: marted=EC 14 maggio 20= 13 16.01 >>> To: Fatai Zhang >>> Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; >> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; >> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org >>> Subject: Re: Closing G.709 open issues >>> >>> Fatai, Sergio, >>> I haven't had time to go find the old mail covering the topic = you >> mentioned (which is why I didn't respond yesterday): >>>> I think this has been discussed for quite long time before Vancouver >> meeting, which was famous as "penultimate" issue. >>>> >>>> I don't think we need discuss this anymore. >>> >>> My memory is that the consensus at the time was that G.709 would contin= ue >> to use the current generic approach to edge adaptation & G-PIDs, and tha= t >> (some of) the G.709 authors would submit a draft that would address >> adaptation in a generic fashion. >>> >>> Do you think this characterization is mistaken? (If so, time to go >> searching for the old discussion, if not we can move on.) >>> >>> Assuming no, then it seems to me that you are going against this >> discussion & consensus by now introducing a 1:1/bandwidth specific mappi= ng >> approach. Do you disagree? If not, do you think there's justification t= o >> reopen this discussion? >>> >>> Independent of the mapping approach and in order to ensure this issue i= s >> closed and does not again resurface, I also request (again) that the >> editors of the draft provide (and include in the document) a full list o= f >> Payload Type values (with the 0x value prefix or the values in >>> decimal) and their corresponding G-PID values. Also including Encoding >> Type as you have below is a good addition -- great idea! >>> >>> Lou >>> >>> On 5/14/2013 1:53 AM, Fatai Zhang wrote: >>>> Hi all, >>>> Thanks, Sergio. >>>> I would like to double check if everything is OK before we >update the >> signaling draft. >>>> I would assume the WG is happy with 1:1 mapping approach and >the new >> GPIDs listed below if there is no more comment until this Wed. >>>> >>>> Best Regards >>>> Fatai >>>> >>>> -----Original Message----- >>>> From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-lucent.c= om] >>>> Sent: Monday, May 13, 2013 3:45 PM >>>> To: Fatai Zhang; Lou Berger >>>> Cc: Daniele Ceccarelli; CCAMP; >> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; >> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org >>>> Subject: R: Closing G.709 open issues >>>> Hi Fatai, >>>> I agree with you, for both point 1 and 2. >>>> Best Regards >>>> Sergio >>>> Belotti Sergio- System Architect >>>> ALCATE-LUCENT Optics Division >>>> via Trento 30 Vimercate (MB) - Italy >>>> phone +39 (039) 6863033 >>>> -----Messaggio originale----- >>>> Da: Fatai Zhang [mailto:zhangfatai@huawei.com] >>>> Inviato: luned=EC 13 maggio 2013 5.33 >>>> A: Lou Berger >>>> Cc: Daniele Ceccarelli; CCAMP; >> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; >> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org >>>> Oggetto: RE: Closing G.709 open issues >>>> Hi Lou, >>>> I think you have two major points here. >>>> (1) Do you really need 3 G-PID types for an ODU (I thought >TSG was >> already covered)? >>>> I think this has been discussed for quite long time before >Vancouver >> meeting, which was famous as "penultimate" issue. >Note that this TSG in >> GPID is different from the *implicit* >TSG in label format. >>>> I don't think we need discuss this anymore. >>>> (2) 'Grouped GPID' vs '1:1' mapping (between G.709-2012 and GPIDs >> defined in this draft) >>>> We realize that it is safe to use 1:1 mapping approach to >avoid some >> potential issues after investigation. We know this >payload types have b= een >> defined by G.709 (data plane), so >physically it is better to use 1:1 >> mapping approach. For the potential issues I mentioned above, for exampl= e, >> we >cannot use the existing 34 to represent 'STM-1' and 'STM-4 ', >becau= se >> it is impossible to differentiate which one is 'STM-1' >or 'STM-4'. In >> addition, from the concept of payload type, we >know that e.g, FC-100 is >> different from FC-800, right? So, it >is better to assign different GPID= s >> to these different payload >types defined by the data plane. >>>> Furthermore, I think it is much cheaper to create new GPIDs >in the >> control plane than in the data plane (these payload >types will be carri= ed >> in the OH). >>>> >>>> Best Regards >>>> Fatai >>>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: Friday, May 10, 2013 8:51 PM >>>> To: Fatai Zhang >>>> Cc: Daniele Ceccarelli; CCAMP; >> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; >> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org >>>> Subject: Re: Closing G.709 open issues >>>> >>>> On 5/9/2013 9:41 PM, Fatai Zhang wrote: >>>>> Hi Lou, >>>>> >>>>> For point 1), "1" should be dropped and "7" should be >corrected to "= 8" >> in your proposed text. >> >> Great. >>>>>>> >>>>> I hesitate to make a decision on either approach, I would >like to >> defer to the WG consensus. >>>>> >>>> I believe we already have a consensus position. The question in my ma= il >> was do we need to revisit it. I take your response as a no. (thank you!= ) >>>>>>> For point 2), I compared [G.709-2003] and [G.709-2012], and checked >>>>> the GPIDs defined in [RFC4328], I think the following new GPIDs >>> >> (values could be 59-79) should be added (besides updating >some GPIDs >>= > >> defined in RFC4328, like 32,47,49-52): >>>>> >>>> I suggest going through the full PT list and identifying them in the >> table (as I started in my last message) so that there is no >confusion i= n >> implementations. >>>> In the list below it looks like you have moved away from the >'grouped >> G-PID' approach. Is there a reason for this change? >>>> Refer to >>>>> http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parame= t >>>> ers.xml >>>> in subsequent comments. >>>>>>> Value G-PID Type LSP Encoding Type >>>>> ----- ---------- ----------------- >>>>> 59(TBA) G.709 ODU-1.25G G.709 ODUk 60(TBA) G.709 >> ODU-any G.709 ODUk >>>> Do you really need 3 G-PID types for an ODU (I thought TSG >was alread= y >> covered)? >>>>>>> 61(TBA) PCS G.709 ODUk (k=3D0) >>>>> 62(TBA) FC-1200 G.709 ODUk (k=3D2e) >>>> Why not us existing G-PID 58? >>>>>>> 63(TBA) eOPU2 G.709 ODUk (k=3D2) >>>>>>> 64(TBA) STM-1 G.709 ODUk (k=3D0) >>>>> 65(TBA) STM-4 G.709 ODUk (k=3D0) >>>> Why not us existing G-PID 34? >>>>>>> 66(TBA) FC-100 G.709 ODUk (k=3D0) >>>>> 67(TBA) FC-200 G.709 ODUk (k=3D1) >>>>> 68(TBA) FC-400 G.709 ODUflex >>>>> 69(TBA) FC-800 G.709 ODUflex >>>> Why not us existing G-PID 58? >>>>>>> 70(TBA) IB SDR G.709 ODUflex >>>>> 71(TBA) IB DDR G.709 ODUflex >>>>> 72(TBA) IB QDR G.709 ODUflex >>>> Can these be one value with rate implying SDR/DDR/QDR? >>>>>>> 73(TBA) SDIa G.709 ODUk (k=3D0) >>>>> 74(TBA) SDIb G.709 ODUk (k=3D1) >>>>> 75(TBA) SDIc G.709 ODUk (k=3D1) >>>>> 76(TBA) SDId G.709 ODUflex >>>>> 77(TBA) SDIe G.709 ODUflex >>>> Can these be one value with rate implying a-e? >>>>>>> 78(TBA) SB/ESCON G.709 ODUk (k=3D0) >>>> Why not us existing G-PID 56? >>>>>>> 79(TBA) DVB_ASI G.709 ODUk (k=3D0) >>>>> >>>>> >>>>> >>>>> >>>> Thanks, >>>> Lou >>>> >>>> >>>> >>> > > > > > > --_000_D8D01B39D6B38C45AA37C06ECC1D65D53FD6C47ESVEXDBPROD2infi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Fa= tai,

=  

I thi= nk we should (continue to)  keep GPid as technology indicator and use = rate in signal Type to make sense of payload.

=  

For e= xample, FC-100, GPid =3D 43 (FiberChannel) and SignalType=3DODU0 (10), will= give you payload FC-100.

=  

Do yo= u see any case, where it can be ambiguous?

=  

Thank= s

Khuze= ma

=  

From: ccamp-bounces@ietf.org [mailto:ccamp-bounc= es@ietf.org] On Behalf Of Fatai Zhang
Sent: Friday, May 17, 2013 1:28 PM
To: Lou Berger; BELOTTI, SERGIO (SERGIO)
Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org Subject: Re: [CCAMP] R: Closing G.709 open issues<= /p>

 =

Hi Lou,

 

I thought it should be sufficient for me to identify the *update= d* and *new* G-PIDs in this draft (I compared [G.709-2003] and [= G.709-2012], and checked RFC4328), but I would be happy to provide a full list for your request.

&= nbsp;

Please see the list below, and the new payload types introduced by = [G.709-2012] (and the corresponding new G-PIDs defined in this draft) are i= n the light blue cells.

 

Please check if there is anything missed or wrong. Note that GPIDs = like 32,47,49-52 have been updated in this draft.

 

Note that we as authors welcome any contributors for their contribu= tion.

&= nbsp;

For you convenience, I also attached the word document.<= /span>

 

&= nbsp;

G-PIDs vs Payload types defined in Table 15-8 of G.709

&nbs= p;

G-PID

LS= P Encoding

Pa= yload Type in Hex code defined in G.709

No= te

In= terpretation from G.709

None

 

0x01

Not needed

Experimental mapping (Note 3)

49

G.709 ODUk, G.709 OCh

0x02

1)G-PID defined in RFC4328;

2) Updated in this draft.

Asynchronous CBR mapping, see clause 17.2

50

G.709 ODUk

0x03

ditto

Bit synchronous CBR mapping, see clause 17.2

32

SDH, G.709 ODUk

0x04

ditto

ATM mapping, see clause 17.3

54

G.709 ODUk (and SDH)

 

0x05

G-PIDs defined in RFC4328 with two kinds of GFPs (Ethernet MAC (framed GF= P)

 

GFP mapping, see clause 17.4

None

 

0x06

Not needed and Not defined in R= FC4328

Virtual Concatenated signal, se= e clause 18 (Note 5)

61(TBA)

G.709 ODUk (k=3D0,3,4)

0x07

Is being defined in this draft = (new payload type defined in [G.709-2012])

PCS codeword transparent Ethern= et mapping:

=B7         1000BASE-X into OPU0, s= ee clauses 17.7.1 and 17.7.1.1

=B7         40GBASE-R into OPU3, se= e clauses 17.7.4 and 17.7.4.1

=B7         100GBASE-R into OPU4, s= ee clauses 17.7.5 and 17.7.5.1

62(TBA)

G.709 ODUk (k=3D2e)

0x08

ditto

FC-1200 into OPU2e mapping, see= clause 17.8.2

63(TBA)

G.709 ODUk (k=3D2)

0x09

ditto

GFP mapping into Extended OPU2 = payload, see clause 17.4.1 (Note 6)

64(TBA)

G.709 ODUk (k=3D0)

0x0A

ditto

STM-1 mapping into OPU0, see cl= ause 17.7.1

65(TBA)

G.709 ODUk (k=3D0)

0x0B

ditto

STM-4 mapping into OPU0, see cl= ause 17.7.1

66(TBA)

G.709 ODUk (k=3D0)

0x0C

ditto

FC-100 mapping into OPU0, see c= lause 17.7.1

67(TBA)

G.709 ODUk (k=3D1)

0x0D

ditto

FC-200 mapping into OPU1, see c= lause 17.7.2

68(TBA)

G.709 ODUflex

0x0E

ditto

FC-400 mapping into OPUflex, se= e clause 17.9

69(TBA)

G.709 ODUflex

0x0F

ditto

FC-800 mapping into OPUflex, se= e clause 17.9

51

G.709 ODUk

0x10

1)G-PID defined in RFC4328;

2) Updated in this draft.<= /o:p>

Bit stream with octet timing ma= pping, see clause 17.6.1

52

G.709 ODUk

0x11

ditto

Bit stream without octet timing= mapping, see clause 17.6.2

70(TBA)

G.709 ODUflex

0x12

Is being defined in this draft = (new payload type defined in [G.709-2012])

IB SDR  mapping into OPUfl= ex, see 17.9

71(TBA)

G.709 ODUflex

0x13

ditto

IB DDR mapping into OPUflex, se= e 17.9

72(TBA)

G.709 ODUflex

0x14

ditto

IB QDR mapping into OPUflex, se= e 17.9

73(TBA)

G.709 ODUk (k=3D0)

0x15

ditto

SDI  mapping into OPU0, se= e 17.7.1

74(TBA)

G.709 ODUk (k=3D1)

0x16

ditto

(1.485/1.001) Gbit/s SDI mappin= g into OPU1, see 17.7.2

75(TBA)

G.709 ODUk (k=3D1)

0x17

ditto

1.485 Gbit/s SDI mapping into O= PU1, see 17.7.2

76(TBA)

G.709 ODUflex

0x18

ditto

(2.970/1.001) Gbit/s SDI mappin= g into OPUflex, see 17.9

77(TBA)

G.709 ODUflex

0x19

ditto

2.970 Gbit/s SDI mapping into O= PUflex, see 17.9

78(TBA)

G.709 ODUk (k=3D0)

0x1A

ditto

SBCON/ESCON mapping into OPU0, = see 17.7.1

79(TBA)

G.709 ODUk (k=3D0)

0x1B

ditto

DVB_ASI mappin= g into OPU0, see 17.7.1

47

G.709 ODUk

0x20

1) G-PIDs defined in RFC4328. <= o:p>

2) Updated in this draft.<= /o:p>

ODU multiplex structure support= ing ODTUjk only, see clause 19 (AMP only)

59/60

G.709 ODUk

0x21

1)Are being de= fined in this draft (new payload type defined in [G.709-2012]);<= /span>

2) 59 for G.709 ODU-1.25G; 60 f= or G.709 ODU-any

ODU multiplex = structure supporting ODTUk.ts or ODTUk.ts and ODTUjk, see clause 19 (GMP ca= pable) (Note 7)

None

 

55

Not needed

Not available (Note 2)

None

 

66

Not needed

Not available (Note 2)

None

 

80-8F

Not needed

Reserved codes for proprietary = use (Note 4)

None

 

FD

Not needed

NULL test signal mapping, see c= lause 17.5.1

None

 

FE

Not needed

PRBS test signal mapping, see c= lause 17.5.2

None

 

FF

Not needed

Not available (Note 2)

 

 

 

 

 

 =

&= nbsp;

&= nbsp;

&= nbsp;

&= nbsp;

Best R= egards

&= nbsp;

Fatai<= o:p>

&= nbsp;

&= nbsp;

-----O= riginal Message-----
From: Lou Berger [mailto:lberger@labn.net]
Sent: Wednesday, May 15, 2013 10:58 PM
To: BELOTTI, SERGIO (SERGIO); Fatai Zhang
Cc: Daniele Ceccarelli; CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tool= s.ietf.org
Subject: Re: R: Closing G.709 open issues

&= nbsp;

Sergio= /Fatai,

&= nbsp;

On 5/1= 5/2013 7:54 AM, BELOTTI, SERGIO (SERGIO) wrote:

> W= e (as authors" were asked to cope with the remaining issues to start s= econd LC.

> O= ne these "remaining issues" was as fro Lou's mil of May 9th<= /o:p>

> <= o:p>

> 2= ) Verify that the complete list of G-PIDs are defined [SIGNALING]

> <= o:p>

>&n= bsp;  In signaling document section 4, verify that all payload types

>&n= bsp;  defined in G.709 (Summarized in Table 15-8) can be represented.<= o:p>

>&n= bsp;  This issue can be resolved via an update or message to the list<= o:p>

>&n= bsp;  stating that the verification took place.

> <= o:p>

> T= his is concluded by Fatai answer regarding G-PID check and 1:1 mapping.

&= nbsp;

And, b= ased on the discussion, I (to be clear, as WG chair) have revised

the re= quest by asking:

 = "that the editors of the draft provide (and include in the document)<= o:p>

 =   a full list of Payload Type values (with the 0x value prefix or the<= o:p>

 =   values in decimal) and their corresponding G-PID values.  Also<= o:p>

 =   including Encoding Type as you [Fatai] have below is a good addition=

 =   -- great idea!"

&= nbsp;

Given = the level of discussion of this thread, I think this is a=

comple= tely reasonable way to avoid future confusion, particularly in

implem= entations.

&= nbsp;

Do the= Authors/Editor need help in generating this complete list?

&= nbsp;

Do the= Authors/Editor want (me) to issue a call for input on this list?

I susp= ect some in WG will be happy to jump in as it's an easy way to

get ad= ded as a contributor to the signaling draft.

&= nbsp;

> <= o:p>

> F= ATAI> For point 2), I compared [G.709-2003] and [G.709-2012], and checke= d the GPIDs defined in [RFC4328], I think the following new GPIDs (values c= ould be 59-79) should be added (besides updating some GPIDs defined in RFC4328, like 32,47,49-52):

> <= o:p>

>&n= bsp;    Value       G-PID Type=              LS= P Encoding Type

>&n= bsp;     -----       ----= ------           &nb= sp; -----------------

>&n= bsp;   59(TBA)     G.709 ODU-1.25G  = ;      G.709 ODUk

>&n= bsp;   60(TBA)     G.709 ODU-any  &= nbsp;       G.709 ODUk

>&n= bsp;   61(TBA)     PCS    = ;            &n= bsp;   G.709 ODUk (k=3D0)

>&n= bsp;   62(TBA)     FC-1200   &= nbsp;            G.7= 09 ODUk (k=3D2e)

>&n= bsp;   63(TBA)     eOPU2   &nb= sp;            = G.709 ODUk (k=3D2)

>&n= bsp;   64(TBA)     STM-1   &nb= sp;            =   G.709 ODUk (k=3D0)

>&n= bsp;   65(TBA)     STM-4   &nb= sp;            =   G.709 ODUk (k=3D0)

>&n= bsp;   66(TBA)     FC-100   &n= bsp;            = ; G.709 ODUk (k=3D0)

>&n= bsp;   67(TBA)     FC-200   &n= bsp;            = ; G.709 ODUk (k=3D1)

>&n= bsp;   68(TBA)     FC-400   &n= bsp;            = ; G.709 ODUflex

>&n= bsp;   69(TBA)     FC-800   &n= bsp;            = ; G.709 ODUflex

>&n= bsp;   70(TBA)     IB SDR   &n= bsp;            = ; G.709 ODUflex

>&n= bsp;   71(TBA)     IB DDR   &n= bsp;            = ; G.709 ODUflex

>&n= bsp;   72(TBA)     IB QDR   &n= bsp;            = ; G.709 ODUflex

>&n= bsp;   73(TBA)     SDIa   &nbs= p;            &= nbsp;  G.709 ODUk (k=3D0)

>&n= bsp;   74(TBA)     SDIb   &nbs= p;            &= nbsp;  G.709 ODUk (k=3D1)

>&n= bsp;   75(TBA)     SDIc   &nbs= p;            &= nbsp;  G.709 ODUk (k=3D1)

>&n= bsp;   76(TBA)     SDId   &nbs= p;            &= nbsp;  G.709 ODUflex

>&n= bsp;   77(TBA)     SDIe   &nbs= p;            &= nbsp;  G.709 ODUflex

>&n= bsp;   78(TBA)     SB/ESCON   =            G.709 ODUk (k= =3D0)

>&n= bsp;   79(TBA)     DVB_ASI   &= nbsp;            G.7= 09 ODUk (k=3D0)

> <= o:p>

&= nbsp;

> A= ll this has nothing to do with specifc ADAPTATION object , for which  = I was always in favour but it seems as though it is linked to MRN discussio= n and out of specifc OTN.

> <= o:p>

&= nbsp;

So I w= ent looking for past discussions on this, and this is what I find:

&= nbsp;

- From= http://www.ietf.org/mail-archive/web/ccamp/current/msg13598.html

On 7/1= 9/2012 11:45 AM, Lou Berger wrote:

> (= As participant in thread) I read that the conclusion is to not optimize

> f= or a very special corner case and:

> 1= ) basically treat the intra-OTN case the same as any other MRN/MLN case

>&n= bsp;   (leveraging GPID, and no new hierarchy object)<= /span>

> 2= ) Use Daniele's new draft on MRN/MLN as the starting point in the

> d= iscussion of how to address the limitations in MRN/MLN identified in

> t= his discussion.

&= nbsp;

From <= a href=3D"http://tools.ietf.org/agenda/84/slides/slides-84-ccamp-7.pdf"> http://tools.ietf.org/agenda/84/slides/slides-84-ccamp-7.pdf=

> G= -PID Value Extension

> o= Extended G-PID for G.709 ODU client signals:

>&n= bsp;  Value G-PID Type TSG (LO ODU into requested LSP)

>&n= bsp;  ----- ---------- ----------------

>&n= bsp;  47 G.709 ODU 2.5Gbps [RFC4328]

>&n= bsp;  59(TBA) G.709 ODU-1.25G 1.25Gbps (new)

>&n= bsp;  60(TBA) G.709 ODU-any either 1.25 or 2.5Gbps(new)

> <= o:p>

> o= Added other new G-PID values for new client signals supported by G.709V3

>&n= bsp;  Value G-PID Type

>&n= bsp;  ----- ----------

>&n= bsp;  61(TBA) CBRc (via GMP)

>&n= bsp;  62(TBA) 1000BASE-X

>&n= bsp;  63(TBA) FC-1200

> <= o:p>

> o= Updated some existing G-PID description to support new 1.25G, 100G,

>&n= bsp;  supra-2.488G client signals, such as 32 for ATM, 49 for asynchro= nous

>&n= bsp;  CBR , 50 for synchronous CBR , 51 for BSOT, 52 for BSNT.

&= nbsp;

I have= not interest/need to revist past consensus on G-PIDs & TSGs, so

will l= imit my comments to the newly defined G-PIDs.

&= nbsp;

My que= stions on the new G-PIDs come down to:

- Why = are rate specific G-PIDs being proposed (rather than

 = continuing to use the previous approach documented in the draft=

 = and in Section 3.1.3 of rfc4328)?

&= nbsp;

- Why = are new values being defined rather than using existing

 = values, e.g., G-PID 56?

&= nbsp;

That's= it.

&= nbsp;

Lou

&= nbsp;

> H= ope this can help.

> <= o:p>

> B= est Regards

> S= ergio

> <= o:p>

> B= elotti Sergio-  System Architect

> A= LCATE-LUCENT  Optics Division

> v= ia Trento 30 Vimercate (MB) - Italy

> p= hone +39 (039) 6863033

> <= o:p>

> -= ----Messaggio originale-----

> D= a: Lou Berger [mailto:lberger@labn.net]

> I= nviato: mercoled=EC 15 maggio 2013 13.22

> A= : Daniele Ceccarelli; Fatai Zhang

> C= c: BELOTTI, SERGIO (SERGIO); CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3= @tools.ietf.org; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org

> O= ggetto: RE: Closing G.709 open issues

> <= o:p>

> D= aniele,

> <= o:p>

> O= n May 15, 2013 4:20:25 AM Daniele Ceccarelli

> &= lt;daniele.ceccarelli@er= icsson.com> wrote:

>&g= t; Hi Lou,

>&g= t; 

>&g= t; Just a bit.

>&g= t;> My memory is that the consensus at the time was that G.709 would con= tinue

>&g= t; to use the current generic approach to edge adaptation & G-PIDs, and= that

>&g= t; (some of) the G.709 authors would submit a draft that would address

>&g= t; adaptation in a generic fashion.

>&g= t;> 

>&g= t; 

>&g= t; If i correctly remember we agreed to solve the routing issu in a generic

>&g= t; approach, not the signaling one.

> <= o:p>

> W= e must be thinking of different threads. The one I'm thinking of started

> w= ith the comment along the lines of "why only some G-PIDs represented i= n

> t= he ADAPTATION object" and concluded with the agreement to drop the obj= ect

> a= nd follow the current generic approach as well as look into a non-OTN

> s= pecific solution in a new draft.  At least that's how I remember it...= .

> <= o:p>

>&g= t; It is possible to assume that the adaptation is a known info to the

>&g= t; operator and hence that the advertisement can be postponed and addressed= in

>&g= t; a generic way but it needs to be signaled.

>&g= t; 

>&g= t; This is an hortogonal issue with respect to the mapping of G-PID, which = has

>&g= t; always been assumed to be 1:1 with G.709 values.

> <= o:p>

> h= umm, this seems inconsistent with Fatai  recently suggesting that i wa= s

> a= sking for a "non-grouped" approach.  At the time, I was real= ly just

> t= hinking about the values missing in the list I sent out. I don't recall

> a= ny other discussion on moving away from the past 709 G-PID assignment

> a= pproach.

> <= o:p>

>&g= t; The 1:1 *mapping* approach used by Fatai is different from the *mapping&= quot;

>&g= t; protocol like GFP, AMP that we discussed before.

>&g= t; 

> <= o:p>

> I= t looks like we both/all should take a look at the archives to refresh our

> m= emories....

> <= o:p>

> T= hanks,

>&n= bsp; Lou

> <= o:p>

>&g= t; BR

>&g= t; Daniele, Sergio, Fatai

>&g= t; 

>&g= t; 

>&g= t;> -----Original Message-----

>&g= t;> From: Lou Berger [mailto:lberger@labn.net] Sent: marted= =EC 14 maggio 2013 16.01

>&g= t;> To: Fatai Zhang

>&g= t;> Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP;

>&g= t; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org;

>&g= t; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org

>&g= t;> Subject: Re: Closing G.709 open issues

>&g= t;> 

>&g= t;> Fatai, Sergio,

>&g= t;>          I haven't had time = to go find the old mail covering the topic you

>&g= t; mentioned (which is why I didn't respond yesterday):

>&g= t;>> I think this has been discussed for quite long time before Vanco= uver

>&g= t; meeting, which was famous as "penultimate" issue.

>&g= t;>> 

>&g= t;>> I don't think we need discuss this anymore.

>&g= t;> 

>&g= t;> My memory is that the consensus at the time was that G.709 would con= tinue

>&g= t; to use the current generic approach to edge adaptation & G-PIDs, and= that

>&g= t; (some of) the G.709 authors would submit a draft that would address

>&g= t; adaptation in a generic fashion.

>&g= t;> 

>&g= t;> Do you think this characterization is mistaken?  (If so, time t= o go

>&g= t; searching for the old discussion, if not we can move on.)

>&g= t;> 

>&g= t;> Assuming no, then it seems to me that you are going against this

>&g= t; discussion & consensus by now introducing a 1:1/bandwidth specific m= apping

>&g= t; approach. Do you disagree?  If not, do you think there's justificat= ion to

>&g= t; reopen this discussion?

>&g= t;> 

>&g= t;> Independent of the mapping approach and in order to ensure this issu= e is

>&g= t; closed and does not again resurface, I also request (again) that the

>&g= t; editors of the draft provide (and include in the document) a full list o= f

>&g= t; Payload Type values (with the 0x value prefix or the values in

>&g= t;> decimal) and their corresponding G-PID values.  Also including = Encoding

>&g= t; Type as you have below is a good addition -- great idea!

>&g= t;> 

>&g= t;> Lou

>&g= t;> 

>&g= t;> On 5/14/2013 1:53 AM, Fatai Zhang wrote:

>&g= t;>> Hi all,

>&g= t;>> Thanks, Sergio.

>&g= t;>> I would like to double check if everything is OK before we >u= pdate the

>&g= t; signaling draft.

>&g= t;>> I would assume the WG is happy with 1:1 mapping approach and >= ;the new

>&g= t; GPIDs listed below if there is no more comment until this Wed.

>&g= t;>> 

>&g= t;>> Best Regards

>&g= t;>> Fatai

>&g= t;>> 

>&g= t;>> -----Original Message-----

>&g= t;>> From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-lu= cent.com]

>&g= t;>> Sent: Monday, May 13, 2013 3:45 PM

>&g= t;>> To: Fatai Zhang; Lou Berger

>&g= t;>> Cc: Daniele Ceccarelli; CCAMP;

>&g= t; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org;

>&g= t; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org

>&g= t;>> Subject: R: Closing G.709 open issues

>&g= t;>> Hi Fatai,

>&g= t;>> I agree with you, for both point 1 and 2.

>&g= t;>> Best Regards

>&g= t;>> Sergio

>&g= t;>> Belotti Sergio-  System Architect

>&g= t;>> ALCATE-LUCENT  Optics Division

>&g= t;>> via Trento 30 Vimercate (MB) - Italy

>&g= t;>> phone +39 (039) 6863033

>&g= t;>> -----Messaggio originale-----

>&g= t;>> Da: Fatai Zhang [mailto:zhangfatai@huawei.com]=

>&g= t;>> Inviato: luned=EC 13 maggio 2013 5.33

>&g= t;>> A: Lou Berger

>&g= t;>> Cc: Daniele Ceccarelli; CCAMP;

>&g= t; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org;

>&g= t; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org

>&g= t;>> Oggetto: RE: Closing G.709 open issues

>&g= t;>> Hi Lou,

>&g= t;>> I think you have two major points here.

>&g= t;>> (1) Do you really need 3 G-PID types for an ODU (I thought >T= SG was

>&g= t; already covered)?

>&g= t;>> I think this has been discussed for quite long time before >V= ancouver

>&g= t; meeting, which was famous as "penultimate" issue. >Note tha= t this TSG in

>&g= t; GPID is different from the *implicit* >TSG in label format.

>&g= t;>> I don't think we need discuss this anymore.

>&g= t;>> (2) 'Grouped GPID' vs '1:1' mapping (between G.709-2012 and GPID= s

>&g= t; defined in this draft)

>&g= t;>> We realize that it is safe to use 1:1 mapping approach to >av= oid some

>&g= t; potential issues after investigation. We know this >payload types hav= e been

>&g= t; defined by G.709 (data plane), so >physically it is better to use 1:1

>&g= t; mapping approach. For the potential issues I mentioned above, for exampl= e,

>&g= t; we >cannot use the existing 34 to represent 'STM-1' and 'STM-4 ', >= ;because

>&g= t; it is impossible to differentiate which one is 'STM-1' >or 'STM-4'. I= n

>&g= t; addition, from the concept of payload type, we >know that e.g, FC-100= is

>&g= t; different from FC-800, right? So, it >is better to assign different G= PIDs

>&g= t; to these different payload >types defined by the data plane.

>&g= t;>> Furthermore, I think it is much cheaper to create new GPIDs >= in the

>&g= t; control plane than in the data plane (these payload >types will be ca= rried

>&g= t; in the OH).

>&g= t;>> 

>&g= t;>> Best Regards

>&g= t;>> Fatai

>&g= t;>> 

>&g= t;>> -----Original Message-----

>&g= t;>> From: Lou Berger [mailto:lberger@labn.net]

>&g= t;>> Sent: Friday, May 10, 2013 8:51 PM

>&g= t;>> To: Fatai Zhang

>&g= t;>> Cc: Daniele Ceccarelli; CCAMP;

>&g= t; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org;

>&g= t; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org

>&g= t;>> Subject: Re: Closing G.709 open issues

>&g= t;>> 

>&g= t;>> On 5/9/2013 9:41 PM, Fatai Zhang wrote:

>&g= t;>>> Hi Lou,

>&g= t;>>> 

>&g= t;>>> For point 1), "1" should be dropped and "7&qu= ot; should be >corrected to "8"

>&g= t; in your proposed text. >> >> Great.

>&g= t;>>>>> 

>&g= t;>>> I hesitate to make a decision on either approach, I would &g= t;like to

>&g= t; defer to the WG consensus.

>&g= t;>>> 

>&g= t;>> I believe we already have a consensus position.  The questi= on in my mail

>&g= t; was do we need to revisit it.  I take your response as a no. (thank= you!)

>&g= t;>>>>> For point 2), I compared [G.709-2003] and [G.709-201= 2], and checked

>&g= t;>>> the GPIDs defined in [RFC4328], I think the following new GP= IDs >>>

>&g= t; (values could be 59-79) should be added (besides updating >some GPIDs= >>>

>&g= t; defined in RFC4328, like 32,47,49-52):

>&g= t;>>> 

>&g= t;>> I suggest going through the full PT list and identifying them in= the

>&g= t; table (as I started in my last message) so that there is no >confusio= n in

>&g= t; implementations.

>&g= t;>> In the list below it looks like you have moved away from the >= ;'grouped

>&g= t; G-PID' approach.  Is there a reason for this change?

>&g= t;>> Refer to

>&g= t;>>> http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-paramet<= o:p>

>&g= t;>> ers.xml

>&g= t;>> in subsequent comments.

>&g= t;>>>>>     Value    = ;   G-PID Type        &nb= sp;    LSP Encoding Type

>&g= t;>>>      -----    &= nbsp;  ----------         = ;    -----------------

>&g= t;>>>    59(TBA)     G.709 ODU-= 1.25G        G.709 ODUk 60(TBA) &nb= sp;   G.709

>&g= t; ODU-any          G.709 ODUk=

>&g= t;>> Do you really need 3 G-PID types for an ODU (I thought TSG >w= as already

>&g= t; covered)?

>&g= t;>>>>>    61(TBA)     PC= S            &n= bsp;       G.709 ODUk (k=3D0)

>&g= t;>>>    62(TBA)     FC-1200&nb= sp;            =    G.709 ODUk (k=3D2e)

>&g= t;>> Why not us existing G-PID 58?

>&g= t;>>>>>    63(TBA)     eO= PU2            =      G.709 ODUk (k=3D2)

>&g= t;>>>>>    64(TBA)     ST= M-1            =       G.709 ODUk (k=3D0)

>&g= t;>>>    65(TBA)     STM-4 = ;             &= nbsp;   G.709 ODUk (k=3D0)

>&g= t;>> Why not us existing G-PID 34?

>&g= t;>>>>>    66(TBA)     FC= -100            = ;     G.709 ODUk (k=3D0)

>&g= t;>>>    67(TBA)     FC-200&nbs= p;            &= nbsp;   G.709 ODUk (k=3D1)

>&g= t;>>>    68(TBA)     FC-400&nbs= p;            &= nbsp;   G.709 ODUflex

>&g= t;>>>    69(TBA)     FC-800&nbs= p;            &= nbsp;   G.709 ODUflex

>&g= t;>> Why not us existing G-PID 58?

>&g= t;>>>>>    70(TBA)     IB= SDR            = ;     G.709 ODUflex

>&g= t;>>>    71(TBA)     IB DDR&nbs= p;            &= nbsp;   G.709 ODUflex

>&g= t;>>>    72(TBA)     IB QDR&nbs= p;            &= nbsp;   G.709 ODUflex

>&g= t;>> Can these be one value with rate implying SDR/DDR/QDR?

>&g= t;>>>>>    73(TBA)     SD= Ia            &= nbsp;      G.709 ODUk (k=3D0)

>&g= t;>>>    74(TBA)     SDIb =             &nb= sp;     G.709 ODUk (k=3D1)

>&g= t;>>>    75(TBA)     SDIc =             &nb= sp;     G.709 ODUk (k=3D1)

>&g= t;>>>    76(TBA)     SDId =             &nb= sp;     G.709 ODUflex

>&g= t;>>>    77(TBA)     SDIe =             &nb= sp;     G.709 ODUflex

>&g= t;>> Can these be one value with rate implying a-e?=

>&g= t;>>>>>    78(TBA)     SB= /ESCON           &nb= sp;  G.709 ODUk (k=3D0)

>&g= t;>> Why not us existing G-PID 56?

>&g= t;>>>>>    79(TBA)     DV= B_ASI           &nbs= p;    G.709 ODUk (k=3D0)

>&g= t;>>> 

>&g= t;>>> 

>&g= t;>>> 

>&g= t;>>> 

>&g= t;>> Thanks,

>&g= t;>> Lou

>&g= t;>> 

>&g= t;>> 

>&g= t;>> 

>&g= t;> 

> <= o:p>

> <= o:p>

> <= o:p>

> <= o:p>

> <= o:p>

> <= o:p>

--_000_D8D01B39D6B38C45AA37C06ECC1D65D53FD6C47ESVEXDBPROD2infi_-- From zhangfatai@huawei.com Mon May 20 02:09:36 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0069721F8233 for ; Mon, 20 May 2013 02:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.498 X-Spam-Level: X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRwSmIuUFYyE for ; Mon, 20 May 2013 02:09:30 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 574A321F84AF for ; Mon, 20 May 2013 02:09:18 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASY67349; Mon, 20 May 2013 09:09:09 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 20 May 2013 10:09:02 +0100 Received: from SZXEML451-HUB.china.huawei.com (10.82.67.194) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 20 May 2013 10:09:05 +0100 Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.235]) by szxeml451-hub.china.huawei.com ([10.82.67.194]) with mapi id 14.01.0323.007; Mon, 20 May 2013 17:09:03 +0800 From: Fatai Zhang To: Lou Berger Thread-Topic: R: Closing G.709 open issues Thread-Index: AQHOTAyDmhSnK0jr+ESubR/xu8VPgpj8bQiw///u0ICAADKIAIAABpSAgAEN6tCAADjpAIAEmsGw///G7YCAAffecIAAA0UAgAEzTICAADLXgIAACRmAgAAzFQCAAzHYYP//9+4AAJok6dA= Date: Mon, 20 May 2013 09:09:01 +0000 Message-ID: References: <518A82D9.7080508@labn.net> <518BAB17.9090807@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> <518CED28.30303@labn.net> <51924382.2010904@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C90D5@ESESSMB301.ericsson.se> <13ea7ed3bdd.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <5193A26A.1090005@labn.net> <519649B4.5060408@labn.net> In-Reply-To: <519649B4.5060408@labn.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: multipart/alternative; boundary="_000_F82A4B6D50F9464B8EBA55651F541CF84319607DSZXEML552MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" Subject: Re: [CCAMP] R: Closing G.709 open issues X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 09:09:36 -0000 --_000_F82A4B6D50F9464B8EBA55651F541CF84319607DSZXEML552MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Lou, I think my mail on March 13rd may have answered your following comments. My= response quoted as follows. In addition, if people look at the full list that I provided, I think peopl= e can realize that RFC4328 (section 3.1.3) used the same approach as the cu= rrent approach of this draft (ie., 1:1 mapping between GPIDs and payload ty= pes defined by G.709), ie., we are following what RFC4328 did. BTW, I am not sure if we need spend so much on discussing this point (becau= se there is no issue to stick to the data plane by using the current approa= ch of this draft). =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D (2) 'Grouped GPID' vs '1:1' mapping (between G.709-2012 and GPIDs defined i= n this draft) We realize that it is safe to use 1:1 mapping approach to avoid some potent= ial issues after investigation. We know this payload types have been define= d by G.709 (data plane), so physically it is better to use 1:1 mapping appr= oach. For the potential issues I mentioned above, for example, we cannot use the = existing 34 to represent 'STM-1' and 'STM-4 ', because it is impossible to = differentiate which one is 'STM-1' or 'STM-4'. In addition, from the concep= t of payload type, we know that e.g, FC-100 is different from FC-800, right= ? So, it is better to assign different GPIDs to these different payload typ= es defined by the data plane. Furthermore, I think it is much cheaper to create new GPIDs in the control = plane than in the data plane (these payload types will be carried in the OH= ). Best Regards Fatai -----Original Message----- From: Lou Berger [mailto:lberger@labn.net] Sent: Friday, May 17, 2013 11:16 PM To: Fatai Zhang Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; draft-ietf-ccamp-g= mpls-signaling-g709v3@tools.ietf.org Subject: Re: R: Closing G.709 open issues Fatai, That's a great start for the WG. Thank you. To answer your implied question as to why my request for the full list. My feeling is that there have been too many "surprises" on the 709 documents in areas that I thought were either obvious (but from the IETF & GMPLS context, not ITU-T or G.709 perspectives) or resolved by past discussions. At this point, as co-chair and Document shepherd, I want to ensure that any open point on the documents are unambiguously closed and that past discussions (i.e., points of consensus) are 100% captured, so that we can smoothly move through the planned second LC and publication request. To that end, in my previous message I asked two questions about points where it seems you are proposing moving away from what has been previously been discussed & agreed to by the WG. Can you answer the following: >> My questions on the new G-PIDs come down to: >> - Why are rate specific G-PIDs being proposed (rather than >> continuing to use the previous approach documented in the draft >> and in Section 3.1.3 of rfc4328)? >> - Why are new values being defined rather than using existing >> values, e.g., G-PID 56? >> Much thanks, Lou --_000_F82A4B6D50F9464B8EBA55651F541CF84319607DSZXEML552MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi L= ou,

 

I th= ink my mail on March 13rd may have answered your following comments. My res= ponse quoted as follows.

 

In a= ddition, if people look at the full list that I provided, I think people ca= n realize that RFC4328 (section 3.1.3) used the same approach as the curren= t approach of this draft (ie., 1:1 mapping between GPIDs and payload types defined by G.709), ie., we are following w= hat RFC4328 did.

 

BTW,= I am not sure if we need spend so much on discussing this point (because t= here is no issue to stick to the data plane by using the current approach o= f this draft).

 

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

(2) 'Grouped GPID' vs '1:1' = mapping (between G.709-2012 and GPIDs defined in this draft)

 

We realize that it is safe t= o use 1:1 mapping approach to avoid some potential issues after investigati= on. We know this payload types have been defined by G.709 (data plane), so = physically it is better to use 1:1 mapping approach.

For the potential issues I m= entioned above, for example, we cannot use the existing 34 to represent 'ST= M-1' and 'STM-4 ', because it is impossible to differentiate which one is '= STM-1' or 'STM-4'. In addition, from the concept of payload type, we know that e.g, FC-100 is different from FC= -800, right? So, it is better to assign different GPIDs to these different = payload types defined by the data plane.

 

Furthermore, I think it is m= uch cheaper to create new GPIDs in the control plane than in the data plane= (these payload types will be carried in the OH).

 

 

 

 

Best= Regards

 

Fata= i

 

-----Original Message----- From: Lou Berger [mailto:lberger@labn.net]
Sent: Friday, May 17, 2013 11:16 PM
To: Fatai Zhang
Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; draft-ietf-ccamp-g= mpls-signaling-g709v3@tools.ietf.org
Subject: Re: R: Closing G.709 open issues

 

Fatai,

    &nbs= p;   

That's a great start for the= WG.  Thank you.

 

To answer your implied quest= ion as to why my request for the full list.

My feeling is that there hav= e been too many "surprises" on the 709

documents in areas that I th= ought were either obvious (but from the IETF

& GMPLS context, not ITU= -T or G.709 perspectives) or resolved by past

discussions.  At this p= oint, as co-chair and Document shepherd, I want

to ensure that any open poin= t on the documents are unambiguously closed

and that past discussions (i= .e., points of consensus) are 100% captured,

so that we can smoothly move= through the planned second LC and

publication request.

 

To that end, in my previous = message I asked two questions about points

where it seems you are propo= sing moving away from what has been

previously been discussed &a= mp; agreed to by the WG.  Can you answer the

following:=

 

>> My questions on the= new G-PIDs come down to:

>> - Why are rate spec= ific G-PIDs being proposed (rather than

>>   continu= ing to use the previous approach documented in the draft<= /p>

>>   and in = Section 3.1.3 of rfc4328)?

 

>> - Why are new value= s being defined rather than using existing

>>   values,= e.g., G-PID 56?

>> 

 

Much thanks,

Lou

 

&= nbsp;

--_000_F82A4B6D50F9464B8EBA55651F541CF84319607DSZXEML552MBXchi_-- From zhangfatai@huawei.com Mon May 20 02:16:50 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 678B321F86C0 for ; Mon, 20 May 2013 02:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.523 X-Spam-Level: X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YS52XFgTbVDY for ; Mon, 20 May 2013 02:16:35 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 338F321F84FD for ; Mon, 20 May 2013 02:16:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASY67935; Mon, 20 May 2013 09:16:13 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 20 May 2013 10:16:01 +0100 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 20 May 2013 10:16:05 +0100 Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.235]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0323.007; Mon, 20 May 2013 17:15:55 +0800 From: Fatai Zhang To: Fatai Zhang , Lou Berger Thread-Topic: R: Closing G.709 open issues Thread-Index: AQHOTAyDmhSnK0jr+ESubR/xu8VPgpj8bQiw///u0ICAADKIAIAABpSAgAEN6tCAADjpAIAEmsGw///G7YCAAffecIAAA0UAgAEzTICAADLXgIAACRmAgAAzFQCAAzHYYP//9+4AAJok6dAAANMWAA== Date: Mon, 20 May 2013 09:15:54 +0000 Message-ID: References: <518A82D9.7080508@labn.net> <518BAB17.9090807@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> <518CED28.30303@labn.net> <51924382.2010904@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C90D5@ESESSMB301.ericsson.se> <13ea7ed3bdd.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <5193A26A.1090005@labn.net> <519649B4.5060408@labn.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: multipart/alternative; boundary="_000_F82A4B6D50F9464B8EBA55651F541CF843196095SZXEML552MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" Subject: Re: [CCAMP] R: Closing G.709 open issues X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 09:16:50 -0000 --_000_F82A4B6D50F9464B8EBA55651F541CF843196095SZXEML552MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Lou, To be precise, I should use "the proposed approach" to replace "the current= approach". Best Regards Fatai From: Fatai Zhang Sent: Monday, May 20, 2013 5:09 PM To: 'Lou Berger' Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; draft-ietf-ccamp-g= mpls-signaling-g709v3@tools.ietf.org Subject: RE: R: Closing G.709 open issues Hi Lou, I think my mail on March 13rd may have answered your following comments. My= response quoted as follows. In addition, if people look at the full list that I provided, I think peopl= e can realize that RFC4328 (section 3.1.3) used the same approach as the cu= rrent approach of this draft (ie., 1:1 mapping between GPIDs and payload ty= pes defined by G.709), ie., we are following what RFC4328 did. BTW, I am not sure if we need spend so much on discussing this point (becau= se there is no issue to stick to the data plane by using the current approa= ch of this draft). =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D (2) 'Grouped GPID' vs '1:1' mapping (between G.709-2012 and GPIDs defined i= n this draft) We realize that it is safe to use 1:1 mapping approach to avoid some potent= ial issues after investigation. We know this payload types have been define= d by G.709 (data plane), so physically it is better to use 1:1 mapping appr= oach. For the potential issues I mentioned above, for example, we cannot use the = existing 34 to represent 'STM-1' and 'STM-4 ', because it is impossible to = differentiate which one is 'STM-1' or 'STM-4'. In addition, from the concep= t of payload type, we know that e.g, FC-100 is different from FC-800, right= ? So, it is better to assign different GPIDs to these different payload typ= es defined by the data plane. Furthermore, I think it is much cheaper to create new GPIDs in the control = plane than in the data plane (these payload types will be carried in the OH= ). Best Regards Fatai -----Original Message----- From: Lou Berger [mailto:lberger@labn.net] Sent: Friday, May 17, 2013 11:16 PM To: Fatai Zhang Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; draft-ietf-ccamp-g= mpls-signaling-g709v3@tools.ietf.org Subject: Re: R: Closing G.709 open issues Fatai, That's a great start for the WG. Thank you. To answer your implied question as to why my request for the full list. My feeling is that there have been too many "surprises" on the 709 documents in areas that I thought were either obvious (but from the IETF & GMPLS context, not ITU-T or G.709 perspectives) or resolved by past discussions. At this point, as co-chair and Document shepherd, I want to ensure that any open point on the documents are unambiguously closed and that past discussions (i.e., points of consensus) are 100% captured, so that we can smoothly move through the planned second LC and publication request. To that end, in my previous message I asked two questions about points where it seems you are proposing moving away from what has been previously been discussed & agreed to by the WG. Can you answer the following: >> My questions on the new G-PIDs come down to: >> - Why are rate specific G-PIDs being proposed (rather than >> continuing to use the previous approach documented in the draft >> and in Section 3.1.3 of rfc4328)? >> - Why are new values being defined rather than using existing >> values, e.g., G-PID 56? >> Much thanks, Lou --_000_F82A4B6D50F9464B8EBA55651F541CF843196095SZXEML552MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Lou,=

&n= bsp;

To be p= recise, I should use “the proposed approach” to replace “= the current approach”.

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

Best Re= gards

&n= bsp;

Fatai

&n= bsp;

From: Fatai Zhang
Sent: Monday, May 20, 2013 5:09 PM
To: 'Lou Berger'
Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; draft-ietf-= ccamp-gmpls-signaling-g709v3@tools.ietf.org
Subject: RE: R: Closing G.709 open issues

 

Hi L= ou,

 

I th= ink my mail on March 13rd may have answered your following comments. My res= ponse quoted as follows.

 

In a= ddition, if people look at the full list that I provided, I think people ca= n realize that RFC4328 (section 3.1.3) used the same approach as the curren= t approach of this draft (ie., 1:1 mapping between GPIDs and payload types defined by G.709), ie., we are following w= hat RFC4328 did.

 

BTW,= I am not sure if we need spend so much on discussing this point (because t= here is no issue to stick to the data plane by using the current approach o= f this draft).

 

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

(2) 'Grouped GPID' vs '1:1' = mapping (between G.709-2012 and GPIDs defined in this draft)

 

We realize that it is safe t= o use 1:1 mapping approach to avoid some potential issues after investigati= on. We know this payload types have been defined by G.709 (data plane), so = physically it is better to use 1:1 mapping approach.

For the potential issues I m= entioned above, for example, we cannot use the existing 34 to represent 'ST= M-1' and 'STM-4 ', because it is impossible to differentiate which one is '= STM-1' or 'STM-4'. In addition, from the concept of payload type, we know that e.g, FC-100 is different from FC= -800, right? So, it is better to assign different GPIDs to these different = payload types defined by the data plane.

 

Furthermore, I think it is m= uch cheaper to create new GPIDs in the control plane than in the data plane= (these payload types will be carried in the OH).

 

 

 

 

Best= Regards

 

Fata= i

 

-----Original Message----- From: Lou Berger [mailto:lberger@labn.net]
Sent: Friday, May 17, 2013 11:16 PM
To: Fatai Zhang
Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; draft-ietf-ccamp-g= mpls-signaling-g709v3@tools.ietf.org
Subject: Re: R: Closing G.709 open issues

 

Fatai,

    &nbs= p;   

That's a great start for the= WG.  Thank you.

 

To answer your implied quest= ion as to why my request for the full list.

My feeling is that there hav= e been too many "surprises" on the 709

documents in areas that I th= ought were either obvious (but from the IETF

& GMPLS context, not ITU= -T or G.709 perspectives) or resolved by past

discussions.  At this p= oint, as co-chair and Document shepherd, I want

to ensure that any open poin= t on the documents are unambiguously closed

and that past discussions (i= .e., points of consensus) are 100% captured,

so that we can smoothly move= through the planned second LC and

publication request.

 

To that end, in my previous = message I asked two questions about points

where it seems you are propo= sing moving away from what has been

previously been discussed &a= mp; agreed to by the WG.  Can you answer the

following:=

 

>> My questions on the= new G-PIDs come down to:

>> - Why are rate spec= ific G-PIDs being proposed (rather than

>>   continu= ing to use the previous approach documented in the draft<= /p>

>>   and in = Section 3.1.3 of rfc4328)?

 

>> - Why are new value= s being defined rather than using existing

>>   values,= e.g., G-PID 56?

>> 

 

Much thanks,

Lou

 

&= nbsp;

--_000_F82A4B6D50F9464B8EBA55651F541CF843196095SZXEML552MBXchi_-- From kpithewan@infinera.com Mon May 20 04:57:49 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5DA21F9121 for ; Mon, 20 May 2013 04:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYOhSmWLw8e0 for ; Mon, 20 May 2013 04:57:39 -0700 (PDT) Received: from sv-casht-prod2.infinera.com (sv-casht-prod2.infinera.com [8.4.225.25]) by ietfa.amsl.com (Postfix) with ESMTP id 01C8221F90D2 for ; Mon, 20 May 2013 04:57:39 -0700 (PDT) Received: from SV-EXDB-PROD2.infinera.com ([fe80::1d05:1822:aaea:ff52]) by sv-casht-prod2.infinera.com ([::1]) with mapi id 14.03.0123.003; Mon, 20 May 2013 04:57:38 -0700 From: Khuzema Pithewan To: Khuzema Pithewan , Fatai Zhang , Lou Berger , "BELOTTI, SERGIO (SERGIO)" Thread-Topic: R: Closing G.709 open issues Thread-Index: AQHOUtRa2DP443BrzUqEe/rBVrfkQZkMcJkwgAGJxUA= Date: Mon, 20 May 2013 11:57:37 +0000 Message-ID: References: <518A82D9.7080508@labn.net> <518BAB17.9090807@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> <518CED28.30303@labn.net> <51924382.2010904@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C90D5@ESESSMB301.ericsson.se> <13ea7ed3bdd.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <5193A26A.1090005@labn.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.96.93] Content-Type: multipart/alternative; boundary="_000_D8D01B39D6B38C45AA37C06ECC1D65D53FD6D110SVEXDBPROD2infi_" MIME-Version: 1.0 Cc: CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" Subject: Re: [CCAMP] R: Closing G.709 open issues X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 11:57:49 -0000 --_000_D8D01B39D6B38C45AA37C06ECC1D65D53FD6D110SVEXDBPROD2infi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, After offline discussion, agreed that G.709' Payload code is required to ha= ve 1:1 mapping with GPid, to resolve STM-1 and STM-4 ambiguity and to achie= ve, in general coherency between spec of Data plane and Control plane for i= nterpretation of payload Identifier. However, there is another question that has popped up. Need WG opinion on t= his. G.709-2012 Table 15-8 defines some reserved code point to be used for prop= rietary payloads and also says that these payloads code will not be subject= to standardization. Question is, Should we also reserve equivalent number of GPIds in signaling= that can be used along with those reserved dataplane code points? For refe= rence, pls look at the bottom few lines in the table that Fatai sent out. Best Regards Khuzema From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of K= huzema Pithewan Sent: Sunday, May 19, 2013 5:57 PM To: Fatai Zhang; Lou Berger; BELOTTI, SERGIO (SERGIO) Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org Subject: Re: [CCAMP] R: Closing G.709 open issues Hi Fatai, I think we should (continue to) keep GPid as technology indicator and use = rate in signal Type to make sense of payload. For example, FC-100, GPid =3D 43 (FiberChannel) and SignalType=3DODU0 (10),= will give you payload FC-100. Do you see any case, where it can be ambiguous? Thanks Khuzema From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of F= atai Zhang Sent: Friday, May 17, 2013 1:28 PM To: Lou Berger; BELOTTI, SERGIO (SERGIO) Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org Subject: Re: [CCAMP] R: Closing G.709 open issues Hi Lou, I thought it should be sufficient for me to identify the *updated* and *new= * G-PIDs in this draft (I compared [G.709-2003] and [G.709-2012], and check= ed RFC4328), but I would be happy to provide a full list for your request. Please see the list below, and the new payload types introduced by [G.709-2= 012] (and the corresponding new G-PIDs defined in this draft) are in the li= ght blue cells. Please check if there is anything missed or wrong. Note that GPIDs like 32,= 47,49-52 have been updated in this draft. Note that we as authors welcome any contributors for their contribution. For you convenience, I also attached the word document. G-PIDs vs Payload types defined in Table 15-8 of G.709 G-PID LSP Encoding Payload Type in Hex code defined in G.709 Note Interpretation from G.709 None 0x01 Not needed Experimental mapping (Note 3) 49 G.709 ODUk, G.709 OCh 0x02 1)G-PID defined in RFC4328; 2) Updated in this draft. Asynchronous CBR mapping, see clause 17.2 50 G.709 ODUk 0x03 ditto Bit synchronous CBR mapping, see clause 17.2 32 SDH, G.709 ODUk 0x04 ditto ATM mapping, see clause 17.3 54 G.709 ODUk (and SDH) 0x05 G-PIDs defined in RFC4328 with two kinds of GFPs (Ethernet MAC (framed GFP) GFP mapping, see clause 17.4 None 0x06 Not needed and Not defined in RFC4328 Virtual Concatenated signal, see clause 18 (Note 5) 61(TBA) G.709 ODUk (k=3D0,3,4) 0x07 Is being defined in this draft (new payload type defined in [G.709-2012]) PCS codeword transparent Ethernet mapping: =B7 1000BASE-X into OPU0, see clauses 17.7.1 and 17.7.1.1 =B7 40GBASE-R into OPU3, see clauses 17.7.4 and 17.7.4.1 =B7 100GBASE-R into OPU4, see clauses 17.7.5 and 17.7.5.1 62(TBA) G.709 ODUk (k=3D2e) 0x08 ditto FC-1200 into OPU2e mapping, see clause 17.8.2 63(TBA) G.709 ODUk (k=3D2) 0x09 ditto GFP mapping into Extended OPU2 payload, see clause 17.4.1 (Note 6) 64(TBA) G.709 ODUk (k=3D0) 0x0A ditto STM-1 mapping into OPU0, see clause 17.7.1 65(TBA) G.709 ODUk (k=3D0) 0x0B ditto STM-4 mapping into OPU0, see clause 17.7.1 66(TBA) G.709 ODUk (k=3D0) 0x0C ditto FC-100 mapping into OPU0, see clause 17.7.1 67(TBA) G.709 ODUk (k=3D1) 0x0D ditto FC-200 mapping into OPU1, see clause 17.7.2 68(TBA) G.709 ODUflex 0x0E ditto FC-400 mapping into OPUflex, see clause 17.9 69(TBA) G.709 ODUflex 0x0F ditto FC-800 mapping into OPUflex, see clause 17.9 51 G.709 ODUk 0x10 1)G-PID defined in RFC4328; 2) Updated in this draft. Bit stream with octet timing mapping, see clause 17.6.1 52 G.709 ODUk 0x11 ditto Bit stream without octet timing mapping, see clause 17.6.2 70(TBA) G.709 ODUflex 0x12 Is being defined in this draft (new payload type defined in [G.709-2012]) IB SDR mapping into OPUflex, see 17.9 71(TBA) G.709 ODUflex 0x13 ditto IB DDR mapping into OPUflex, see 17.9 72(TBA) G.709 ODUflex 0x14 ditto IB QDR mapping into OPUflex, see 17.9 73(TBA) G.709 ODUk (k=3D0) 0x15 ditto SDI mapping into OPU0, see 17.7.1 74(TBA) G.709 ODUk (k=3D1) 0x16 ditto (1.485/1.001) Gbit/s SDI mapping into OPU1, see 17.7.2 75(TBA) G.709 ODUk (k=3D1) 0x17 ditto 1.485 Gbit/s SDI mapping into OPU1, see 17.7.2 76(TBA) G.709 ODUflex 0x18 ditto (2.970/1.001) Gbit/s SDI mapping into OPUflex, see 17.9 77(TBA) G.709 ODUflex 0x19 ditto 2.970 Gbit/s SDI mapping into OPUflex, see 17.9 78(TBA) G.709 ODUk (k=3D0) 0x1A ditto SBCON/ESCON mapping into OPU0, see 17.7.1 79(TBA) G.709 ODUk (k=3D0) 0x1B ditto DVB_ASI mapping into OPU0, see 17.7.1 47 G.709 ODUk 0x20 1) G-PIDs defined in RFC4328. 2) Updated in this draft. ODU multiplex structure supporting ODTUjk only, see clause 19 (AMP only) 59/60 G.709 ODUk 0x21 1)Are being defined in this draft (new payload type defined in [G.709-2012]= ); 2) 59 for G.709 ODU-1.25G; 60 for G.709 ODU-any ODU multiplex structure supporting ODTUk.ts or ODTUk.ts and ODTUjk, see cla= use 19 (GMP capable) (Note 7) None 55 Not needed Not available (Note 2) None 66 Not needed Not available (Note 2) None 80-8F Not needed Reserved codes for proprietary use (Note 4) None FD Not needed NULL test signal mapping, see clause 17.5.1 None FE Not needed PRBS test signal mapping, see clause 17.5.2 None FF Not needed Not available (Note 2) Best Regards Fatai -----Original Message----- From: Lou Berger [mailto:lberger@labn.net] Sent: Wednesday, May 15, 2013 10:58 PM To: BELOTTI, SERGIO (SERGIO); Fatai Zhang Cc: Daniele Ceccarelli; CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tool= s.ietf.org Subject: Re: R: Closing G.709 open issues Sergio/Fatai, On 5/15/2013 7:54 AM, BELOTTI, SERGIO (SERGIO) wrote: > We (as authors" were asked to cope with the remaining issues to start sec= ond LC. > One these "remaining issues" was as fro Lou's mil of May 9th > > 2) Verify that the complete list of G-PIDs are defined [SIGNALING] > > In signaling document section 4, verify that all payload types > defined in G.709 (Summarized in Table 15-8) can be represented. > This issue can be resolved via an update or message to the list > stating that the verification took place. > > This is concluded by Fatai answer regarding G-PID check and 1:1 mapping. And, based on the discussion, I (to be clear, as WG chair) have revised the request by asking: "that the editors of the draft provide (and include in the document) a full list of Payload Type values (with the 0x value prefix or the values in decimal) and their corresponding G-PID values. Also including Encoding Type as you [Fatai] have below is a good addition -- great idea!" Given the level of discussion of this thread, I think this is a completely reasonable way to avoid future confusion, particularly in implementations. Do the Authors/Editor need help in generating this complete list? Do the Authors/Editor want (me) to issue a call for input on this list? I suspect some in WG will be happy to jump in as it's an easy way to get added as a contributor to the signaling draft. > > FATAI> For point 2), I compared [G.709-2003] and [G.709-2012], and checke= d the GPIDs defined in [RFC4328], I think the following new GPIDs (values c= ould be 59-79) should be added (besides updating some GPIDs defined in RFC4= 328, like 32,47,49-52): > > Value G-PID Type LSP Encoding Type > ----- ---------- ----------------- > 59(TBA) G.709 ODU-1.25G G.709 ODUk > 60(TBA) G.709 ODU-any G.709 ODUk > 61(TBA) PCS G.709 ODUk (k=3D0) > 62(TBA) FC-1200 G.709 ODUk (k=3D2e) > 63(TBA) eOPU2 G.709 ODUk (k=3D2) > 64(TBA) STM-1 G.709 ODUk (k=3D0) > 65(TBA) STM-4 G.709 ODUk (k=3D0) > 66(TBA) FC-100 G.709 ODUk (k=3D0) > 67(TBA) FC-200 G.709 ODUk (k=3D1) > 68(TBA) FC-400 G.709 ODUflex > 69(TBA) FC-800 G.709 ODUflex > 70(TBA) IB SDR G.709 ODUflex > 71(TBA) IB DDR G.709 ODUflex > 72(TBA) IB QDR G.709 ODUflex > 73(TBA) SDIa G.709 ODUk (k=3D0) > 74(TBA) SDIb G.709 ODUk (k=3D1) > 75(TBA) SDIc G.709 ODUk (k=3D1) > 76(TBA) SDId G.709 ODUflex > 77(TBA) SDIe G.709 ODUflex > 78(TBA) SB/ESCON G.709 ODUk (k=3D0) > 79(TBA) DVB_ASI G.709 ODUk (k=3D0) > > All this has nothing to do with specifc ADAPTATION object , for which I = was always in favour but it seems as though it is linked to MRN discussion = and out of specifc OTN. > So I went looking for past discussions on this, and this is what I find: - From http://www.ietf.org/mail-archive/web/ccamp/current/msg13598.html On 7/19/2012 11:45 AM, Lou Berger wrote: > (As participant in thread) I read that the conclusion is to not optimize > for a very special corner case and: > 1) basically treat the intra-OTN case the same as any other MRN/MLN case > (leveraging GPID, and no new hierarchy object) > 2) Use Daniele's new draft on MRN/MLN as the starting point in the > discussion of how to address the limitations in MRN/MLN identified in > this discussion. >From http://tools.ietf.org/agenda/84/slides/slides-84-ccamp-7.pdf > G-PID Value Extension > o Extended G-PID for G.709 ODU client signals: > Value G-PID Type TSG (LO ODU into requested LSP) > ----- ---------- ---------------- > 47 G.709 ODU 2.5Gbps [RFC4328] > 59(TBA) G.709 ODU-1.25G 1.25Gbps (new) > 60(TBA) G.709 ODU-any either 1.25 or 2.5Gbps(new) > > o Added other new G-PID values for new client signals supported by G.709V= 3 > Value G-PID Type > ----- ---------- > 61(TBA) CBRc (via GMP) > 62(TBA) 1000BASE-X > 63(TBA) FC-1200 > > o Updated some existing G-PID description to support new 1.25G, 100G, > supra-2.488G client signals, such as 32 for ATM, 49 for asynchronous > CBR , 50 for synchronous CBR , 51 for BSOT, 52 for BSNT. I have not interest/need to revist past consensus on G-PIDs & TSGs, so will limit my comments to the newly defined G-PIDs. My questions on the new G-PIDs come down to: - Why are rate specific G-PIDs being proposed (rather than continuing to use the previous approach documented in the draft and in Section 3.1.3 of rfc4328)? - Why are new values being defined rather than using existing values, e.g., G-PID 56? That's it. Lou > Hope this can help. > > Best Regards > Sergio > > Belotti Sergio- System Architect > ALCATE-LUCENT Optics Division > via Trento 30 Vimercate (MB) - Italy > phone +39 (039) 6863033 > > -----Messaggio originale----- > Da: Lou Berger [mailto:lberger@labn.net] > Inviato: mercoled=EC 15 maggio 2013 13.22 > A: Daniele Ceccarelli; Fatai Zhang > Cc: BELOTTI, SERGIO (SERGIO); CCAMP; draft-ietf-ccamp-gmpls-signaling-g70= 9v3@tools.ietf.org; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org > Oggetto: RE: Closing G.709 open issues > > Daniele, > > On May 15, 2013 4:20:25 AM Daniele Ceccarelli > >= wrote: >> Hi Lou, >> >> Just a bit. >>> My memory is that the consensus at the time was that G.709 would contin= ue >> to use the current generic approach to edge adaptation & G-PIDs, and tha= t >> (some of) the G.709 authors would submit a draft that would address >> adaptation in a generic fashion. >>> >> >> If i correctly remember we agreed to solve the routing issu in a generic >> approach, not the signaling one. > > We must be thinking of different threads. The one I'm thinking of started > with the comment along the lines of "why only some G-PIDs represented in > the ADAPTATION object" and concluded with the agreement to drop the objec= t > and follow the current generic approach as well as look into a non-OTN > specific solution in a new draft. At least that's how I remember it.... > >> It is possible to assume that the adaptation is a known info to the >> operator and hence that the advertisement can be postponed and addressed= in >> a generic way but it needs to be signaled. >> >> This is an hortogonal issue with respect to the mapping of G-PID, which = has >> always been assumed to be 1:1 with G.709 values. > > humm, this seems inconsistent with Fatai recently suggesting that i was > asking for a "non-grouped" approach. At the time, I was really just > thinking about the values missing in the list I sent out. I don't recall > any other discussion on moving away from the past 709 G-PID assignment > approach. > >> The 1:1 *mapping* approach used by Fatai is different from the *mapping" >> protocol like GFP, AMP that we discussed before. >> > > It looks like we both/all should take a look at the archives to refresh o= ur > memories.... > > Thanks, > Lou > >> BR >> Daniele, Sergio, Fatai >> >> >>> -----Original Message----- >>> From: Lou Berger [mailto:lberger@labn.net] Sent: marted=EC 14 maggio 20= 13 16.01 >>> To: Fatai Zhang >>> Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; >> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; >> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org >>> Subject: Re: Closing G.709 open issues >>> >>> Fatai, Sergio, >>> I haven't had time to go find the old mail covering the topic = you >> mentioned (which is why I didn't respond yesterday): >>>> I think this has been discussed for quite long time before Vancouver >> meeting, which was famous as "penultimate" issue. >>>> >>>> I don't think we need discuss this anymore. >>> >>> My memory is that the consensus at the time was that G.709 would contin= ue >> to use the current generic approach to edge adaptation & G-PIDs, and tha= t >> (some of) the G.709 authors would submit a draft that would address >> adaptation in a generic fashion. >>> >>> Do you think this characterization is mistaken? (If so, time to go >> searching for the old discussion, if not we can move on.) >>> >>> Assuming no, then it seems to me that you are going against this >> discussion & consensus by now introducing a 1:1/bandwidth specific mappi= ng >> approach. Do you disagree? If not, do you think there's justification t= o >> reopen this discussion? >>> >>> Independent of the mapping approach and in order to ensure this issue i= s >> closed and does not again resurface, I also request (again) that the >> editors of the draft provide (and include in the document) a full list o= f >> Payload Type values (with the 0x value prefix or the values in >>> decimal) and their corresponding G-PID values. Also including Encoding >> Type as you have below is a good addition -- great idea! >>> >>> Lou >>> >>> On 5/14/2013 1:53 AM, Fatai Zhang wrote: >>>> Hi all, >>>> Thanks, Sergio. >>>> I would like to double check if everything is OK before we >update the >> signaling draft. >>>> I would assume the WG is happy with 1:1 mapping approach and >the new >> GPIDs listed below if there is no more comment until this Wed. >>>> >>>> Best Regards >>>> Fatai >>>> >>>> -----Original Message----- >>>> From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-lucent.c= om] >>>> Sent: Monday, May 13, 2013 3:45 PM >>>> To: Fatai Zhang; Lou Berger >>>> Cc: Daniele Ceccarelli; CCAMP; >> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; >> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org >>>> Subject: R: Closing G.709 open issues >>>> Hi Fatai, >>>> I agree with you, for both point 1 and 2. >>>> Best Regards >>>> Sergio >>>> Belotti Sergio- System Architect >>>> ALCATE-LUCENT Optics Division >>>> via Trento 30 Vimercate (MB) - Italy >>>> phone +39 (039) 6863033 >>>> -----Messaggio originale----- >>>> Da: Fatai Zhang [mailto:zhangfatai@huawei.com] >>>> Inviato: luned=EC 13 maggio 2013 5.33 >>>> A: Lou Berger >>>> Cc: Daniele Ceccarelli; CCAMP; >> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; >> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org >>>> Oggetto: RE: Closing G.709 open issues >>>> Hi Lou, >>>> I think you have two major points here. >>>> (1) Do you really need 3 G-PID types for an ODU (I thought >TSG was >> already covered)? >>>> I think this has been discussed for quite long time before >Vancouver >> meeting, which was famous as "penultimate" issue. >Note that this TSG in >> GPID is different from the *implicit* >TSG in label format. >>>> I don't think we need discuss this anymore. >>>> (2) 'Grouped GPID' vs '1:1' mapping (between G.709-2012 and GPIDs >> defined in this draft) >>>> We realize that it is safe to use 1:1 mapping approach to >avoid some >> potential issues after investigation. We know this >payload types have b= een >> defined by G.709 (data plane), so >physically it is better to use 1:1 >> mapping approach. For the potential issues I mentioned above, for exampl= e, >> we >cannot use the existing 34 to represent 'STM-1' and 'STM-4 ', >becau= se >> it is impossible to differentiate which one is 'STM-1' >or 'STM-4'. In >> addition, from the concept of payload type, we >know that e.g, FC-100 is >> different from FC-800, right? So, it >is better to assign different GPID= s >> to these different payload >types defined by the data plane. >>>> Furthermore, I think it is much cheaper to create new GPIDs >in the >> control plane than in the data plane (these payload >types will be carri= ed >> in the OH). >>>> >>>> Best Regards >>>> Fatai >>>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: Friday, May 10, 2013 8:51 PM >>>> To: Fatai Zhang >>>> Cc: Daniele Ceccarelli; CCAMP; >> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; >> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org >>>> Subject: Re: Closing G.709 open issues >>>> >>>> On 5/9/2013 9:41 PM, Fatai Zhang wrote: >>>>> Hi Lou, >>>>> >>>>> For point 1), "1" should be dropped and "7" should be >corrected to "= 8" >> in your proposed text. >> >> Great. >>>>>>> >>>>> I hesitate to make a decision on either approach, I would >like to >> defer to the WG consensus. >>>>> >>>> I believe we already have a consensus position. The question in my ma= il >> was do we need to revisit it. I take your response as a no. (thank you!= ) >>>>>>> For point 2), I compared [G.709-2003] and [G.709-2012], and checked >>>>> the GPIDs defined in [RFC4328], I think the following new GPIDs >>> >> (values could be 59-79) should be added (besides updating >some GPIDs >>= > >> defined in RFC4328, like 32,47,49-52): >>>>> >>>> I suggest going through the full PT list and identifying them in the >> table (as I started in my last message) so that there is no >confusion i= n >> implementations. >>>> In the list below it looks like you have moved away from the >'grouped >> G-PID' approach. Is there a reason for this change? >>>> Refer to >>>>> http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parame= t >>>> ers.xml >>>> in subsequent comments. >>>>>>> Value G-PID Type LSP Encoding Type >>>>> ----- ---------- ----------------- >>>>> 59(TBA) G.709 ODU-1.25G G.709 ODUk 60(TBA) G.709 >> ODU-any G.709 ODUk >>>> Do you really need 3 G-PID types for an ODU (I thought TSG >was alread= y >> covered)? >>>>>>> 61(TBA) PCS G.709 ODUk (k=3D0) >>>>> 62(TBA) FC-1200 G.709 ODUk (k=3D2e) >>>> Why not us existing G-PID 58? >>>>>>> 63(TBA) eOPU2 G.709 ODUk (k=3D2) >>>>>>> 64(TBA) STM-1 G.709 ODUk (k=3D0) >>>>> 65(TBA) STM-4 G.709 ODUk (k=3D0) >>>> Why not us existing G-PID 34? >>>>>>> 66(TBA) FC-100 G.709 ODUk (k=3D0) >>>>> 67(TBA) FC-200 G.709 ODUk (k=3D1) >>>>> 68(TBA) FC-400 G.709 ODUflex >>>>> 69(TBA) FC-800 G.709 ODUflex >>>> Why not us existing G-PID 58? >>>>>>> 70(TBA) IB SDR G.709 ODUflex >>>>> 71(TBA) IB DDR G.709 ODUflex >>>>> 72(TBA) IB QDR G.709 ODUflex >>>> Can these be one value with rate implying SDR/DDR/QDR? >>>>>>> 73(TBA) SDIa G.709 ODUk (k=3D0) >>>>> 74(TBA) SDIb G.709 ODUk (k=3D1) >>>>> 75(TBA) SDIc G.709 ODUk (k=3D1) >>>>> 76(TBA) SDId G.709 ODUflex >>>>> 77(TBA) SDIe G.709 ODUflex >>>> Can these be one value with rate implying a-e? >>>>>>> 78(TBA) SB/ESCON G.709 ODUk (k=3D0) >>>> Why not us existing G-PID 56? >>>>>>> 79(TBA) DVB_ASI G.709 ODUk (k=3D0) >>>>> >>>>> >>>>> >>>>> >>>> Thanks, >>>> Lou >>>> >>>> >>>> >>> > > > > > > --_000_D8D01B39D6B38C45AA37C06ECC1D65D53FD6D110SVEXDBPROD2infi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

=  

After= offline discussion, agreed that G.709’ Payload code is required to h= ave 1:1 mapping with GPid, to resolve STM-1 and STM-4 ambiguity and to achi= eve, in general coherency between spec of Data plane and Control plane for interpretation of payload Identifier.

=  

Howev= er, there is another question that has popped up. Need WG opinion on this.<= o:p>

=  

G.709= -2012 Table 15-8 defines some reserved code point  to be used for prop= rietary payloads and also says that these payloads code will not be subject= to standardization.

=  

Quest= ion is, Should we also reserve equivalent number of GPIds in signaling that= can be used along with those reserved dataplane code points? For reference= , pls look at the bottom few lines in the table that Fatai sent out.

=  

Best = Regards

Khuze= ma

=  

=  

=  

=  

From: ccamp-bounces@ietf.org [mailto:ccamp-bounc= es@ietf.org] On Behalf Of Khuzema Pithewan
Sent: Sunday, May 19, 2013 5:57 PM
To: Fatai Zhang; Lou Berger; BELOTTI, SERGIO (SERGIO)
Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org Subject: Re: [CCAMP] R: Closing G.709 open issues<= /p>

 =

Hi Fa= tai,

=  

I thi= nk we should (continue to)  keep GPid as technology indicator and use = rate in signal Type to make sense of payload.

=  

For e= xample, FC-100, GPid =3D 43 (FiberChannel) and SignalType=3DODU0 (10), will= give you payload FC-100.

=  

Do yo= u see any case, where it can be ambiguous?

=  

Thank= s

Khuze= ma

=  

From: ccamp-bounces@ietf.org [mailto:ccamp-bounc= es@ietf.org] On Behalf Of Fatai Zhang
Sent: Friday, May 17, 2013 1:28 PM
To: Lou Berger; BELOTTI, SERGIO (SERGIO)
Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org Subject: Re: [CCAMP] R: Closing G.709 open issues<= /p>

 =

Hi Lou,

 

I thought it should be sufficient for me to identify the *update= d* and *new* G-PIDs in this draft (I compared [G.709-2003] and [= G.709-2012], and checked RFC4328), but I would be happy to provide a full list for your request.

&= nbsp;

Please see the list below, and the new payload types introduced by = [G.709-2012] (and the corresponding new G-PIDs defined in this draft) are i= n the light blue cells.

 

Please check if there is anything missed or wrong. Note that GPIDs = like 32,47,49-52 have been updated in this draft.

 

Note that we as authors welcome any contributors for their contribu= tion.

&= nbsp;

For you convenience, I also attached the word document.<= /span>

 

&= nbsp;

G-PIDs vs Payload types defined in Table 15-8 of G.709

&nbs= p;

G-PID

LS= P Encoding

Pa= yload Type in Hex code defined in G.709

No= te

In= terpretation from G.709

None

 

0x01

Not needed

Experimental mapping (Note 3)

49

G.709 ODUk, G.709 OCh

0x02

1)G-PID defined in RFC4328;

2) Updated in this draft.

Asynchronous CBR mapping, see clause 17.2

50

G.709 ODUk

0x03

ditto

Bit synchronous CBR mapping, see clause 17.2

32

SDH, G.709 ODUk

0x04

ditto

ATM mapping, see clause 17.3

54

G.709 ODUk (and SDH)

 

0x05

G-PIDs defined in RFC4328 with two kinds of GFPs (Ethernet MAC (framed GF= P)

 

GFP mapping, see clause 17.4

None

 

0x06

Not needed and Not defined in R= FC4328

Virtual Concatenated signal, se= e clause 18 (Note 5)

61(TBA)

G.709 ODUk (k=3D0,3,4)

0x07

Is being defined in this draft = (new payload type defined in [G.709-2012])

PCS codeword transparent Ethern= et mapping:

=B7         1000BASE-X into OPU0, s= ee clauses 17.7.1 and 17.7.1.1

=B7         40GBASE-R into OPU3, se= e clauses 17.7.4 and 17.7.4.1

=B7         100GBASE-R into OPU4, s= ee clauses 17.7.5 and 17.7.5.1

62(TBA)

G.709 ODUk (k=3D2e)

0x08

ditto

FC-1200 into OPU2e mapping, see= clause 17.8.2

63(TBA)

G.709 ODUk (k=3D2)

0x09

ditto

GFP mapping into Extended OPU2 = payload, see clause 17.4.1 (Note 6)

64(TBA)

G.709 ODUk (k=3D0)

0x0A

ditto

STM-1 mapping into OPU0, see cl= ause 17.7.1

65(TBA)

G.709 ODUk (k=3D0)

0x0B

ditto

STM-4 mapping into OPU0, see cl= ause 17.7.1

66(TBA)

G.709 ODUk (k=3D0)

0x0C

ditto

FC-100 mapping into OPU0, see c= lause 17.7.1

67(TBA)

G.709 ODUk (k=3D1)

0x0D

ditto

FC-200 mapping into OPU1, see c= lause 17.7.2

68(TBA)

G.709 ODUflex

0x0E

ditto

FC-400 mapping into OPUflex, se= e clause 17.9

69(TBA)

G.709 ODUflex

0x0F

ditto

FC-800 mapping into OPUflex, se= e clause 17.9

51

G.709 ODUk

0x10

1)G-PID defined in RFC4328;

2) Updated in this draft.<= /o:p>

Bit stream with octet timing ma= pping, see clause 17.6.1

52

G.709 ODUk

0x11

ditto

Bit stream without octet timing= mapping, see clause 17.6.2

70(TBA)

G.709 ODUflex

0x12

Is being defined in this draft = (new payload type defined in [G.709-2012])

IB SDR  mapping into OPUfl= ex, see 17.9

71(TBA)

G.709 ODUflex

0x13

ditto

IB DDR mapping into OPUflex, se= e 17.9

72(TBA)

G.709 ODUflex

0x14

ditto

IB QDR mapping into OPUflex, se= e 17.9

73(TBA)

G.709 ODUk (k=3D0)

0x15

ditto

SDI  mapping into OPU0, se= e 17.7.1

74(TBA)

G.709 ODUk (k=3D1)

0x16

ditto

(1.485/1.001) Gbit/s SDI mappin= g into OPU1, see 17.7.2

75(TBA)

G.709 ODUk (k=3D1)

0x17

ditto

1.485 Gbit/s SDI mapping into O= PU1, see 17.7.2

76(TBA)

G.709 ODUflex

0x18

ditto

(2.970/1.001) Gbit/s SDI mappin= g into OPUflex, see 17.9

77(TBA)

G.709 ODUflex

0x19

ditto

2.970 Gbit/s SDI mapping into O= PUflex, see 17.9

78(TBA)

G.709 ODUk (k=3D0)

0x1A

ditto

SBCON/ESCON mapping into OPU0, = see 17.7.1

79(TBA)

G.709 ODUk (k=3D0)

0x1B

ditto

DVB_ASI mappin= g into OPU0, see 17.7.1

47

G.709 ODUk

0x20

1) G-PIDs defined in RFC4328. <= o:p>

2) Updated in this draft.<= /o:p>

ODU multiplex structure support= ing ODTUjk only, see clause 19 (AMP only)

59/60

G.709 ODUk

0x21

1)Are being de= fined in this draft (new payload type defined in [G.709-2012]);<= /span>

2) 59 for G.709 ODU-1.25G; 60 f= or G.709 ODU-any

ODU multiplex = structure supporting ODTUk.ts or ODTUk.ts and ODTUjk, see clause 19 (GMP ca= pable) (Note 7)

None

 

55

Not needed

Not available (Note 2)

None

 

66

Not needed

Not available (Note 2)

None

 

80-8F

Not needed

Reserved codes for proprietary = use (Note 4)

None

 

FD

Not needed

NULL test signal mapping, see c= lause 17.5.1

None

 

FE

Not needed

PRBS test signal mapping, see c= lause 17.5.2

None

 

FF

Not needed

Not available (Note 2)

 

 

 

 

 

 =

&= nbsp;

&= nbsp;

&= nbsp;

&= nbsp;

Best R= egards

&= nbsp;

Fatai<= o:p>

&= nbsp;

&= nbsp;

-----O= riginal Message-----
From: Lou Berger [mailto:lberger@labn.net]
Sent: Wednesday, May 15, 2013 10:58 PM
To: BELOTTI, SERGIO (SERGIO); Fatai Zhang
Cc: Daniele Ceccarelli; CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tool= s.ietf.org
Subject: Re: R: Closing G.709 open issues

&= nbsp;

Sergio= /Fatai,

&= nbsp;

On 5/1= 5/2013 7:54 AM, BELOTTI, SERGIO (SERGIO) wrote:

> W= e (as authors" were asked to cope with the remaining issues to start s= econd LC.

> O= ne these "remaining issues" was as fro Lou's mil of May 9th<= /o:p>

> <= o:p>

> 2= ) Verify that the complete list of G-PIDs are defined [SIGNALING]

> <= o:p>

>&n= bsp;  In signaling document section 4, verify that all payload types

>&n= bsp;  defined in G.709 (Summarized in Table 15-8) can be represented.<= o:p>

>&n= bsp;  This issue can be resolved via an update or message to the list<= o:p>

>&n= bsp;  stating that the verification took place.

> <= o:p>

> T= his is concluded by Fatai answer regarding G-PID check and 1:1 mapping.

&= nbsp;

And, b= ased on the discussion, I (to be clear, as WG chair) have revised

the re= quest by asking:

 = "that the editors of the draft provide (and include in the document)<= o:p>

 =   a full list of Payload Type values (with the 0x value prefix or the<= o:p>

 =   values in decimal) and their corresponding G-PID values.  Also<= o:p>

 =   including Encoding Type as you [Fatai] have below is a good addition=

 =   -- great idea!"

&= nbsp;

Given = the level of discussion of this thread, I think this is a=

comple= tely reasonable way to avoid future confusion, particularly in

implem= entations.

&= nbsp;

Do the= Authors/Editor need help in generating this complete list?

&= nbsp;

Do the= Authors/Editor want (me) to issue a call for input on this list?

I susp= ect some in WG will be happy to jump in as it's an easy way to

get ad= ded as a contributor to the signaling draft.

&= nbsp;

> <= o:p>

> F= ATAI> For point 2), I compared [G.709-2003] and [G.709-2012], and checke= d the GPIDs defined in [RFC4328], I think the following new GPIDs (values c= ould be 59-79) should be added (besides updating some GPIDs defined in RFC4328, like 32,47,49-52):

> <= o:p>

>&n= bsp;    Value       G-PID Type=              LS= P Encoding Type

>&n= bsp;     -----       ----= ------           &nb= sp; -----------------

>&n= bsp;   59(TBA)     G.709 ODU-1.25G  = ;      G.709 ODUk

>&n= bsp;   60(TBA)     G.709 ODU-any  &= nbsp;       G.709 ODUk

>&n= bsp;   61(TBA)     PCS    = ;            &n= bsp;   G.709 ODUk (k=3D0)

>&n= bsp;   62(TBA)     FC-1200   &= nbsp;            G.7= 09 ODUk (k=3D2e)

>&n= bsp;   63(TBA)     eOPU2   &nb= sp;            = G.709 ODUk (k=3D2)

>&n= bsp;   64(TBA)     STM-1   &nb= sp;            =   G.709 ODUk (k=3D0)

>&n= bsp;   65(TBA)     STM-4   &nb= sp;            =   G.709 ODUk (k=3D0)

>&n= bsp;   66(TBA)     FC-100   &n= bsp;            = ; G.709 ODUk (k=3D0)

>&n= bsp;   67(TBA)     FC-200   &n= bsp;            = ; G.709 ODUk (k=3D1)

>&n= bsp;   68(TBA)     FC-400   &n= bsp;            = ; G.709 ODUflex

>&n= bsp;   69(TBA)     FC-800   &n= bsp;            = ; G.709 ODUflex

>&n= bsp;   70(TBA)     IB SDR   &n= bsp;            = ; G.709 ODUflex

>&n= bsp;   71(TBA)     IB DDR   &n= bsp;            = ; G.709 ODUflex

>&n= bsp;   72(TBA)     IB QDR   &n= bsp;            = ; G.709 ODUflex

>&n= bsp;   73(TBA)     SDIa   &nbs= p;            &= nbsp;  G.709 ODUk (k=3D0)

>&n= bsp;   74(TBA)     SDIb   &nbs= p;            &= nbsp;  G.709 ODUk (k=3D1)

>&n= bsp;   75(TBA)     SDIc   &nbs= p;            &= nbsp;  G.709 ODUk (k=3D1)

>&n= bsp;   76(TBA)     SDId   &nbs= p;            &= nbsp;  G.709 ODUflex

>&n= bsp;   77(TBA)     SDIe   &nbs= p;            &= nbsp;  G.709 ODUflex

>&n= bsp;   78(TBA)     SB/ESCON   =            G.709 ODUk (k= =3D0)

>&n= bsp;   79(TBA)     DVB_ASI   &= nbsp;            G.7= 09 ODUk (k=3D0)

> <= o:p>

&= nbsp;

> A= ll this has nothing to do with specifc ADAPTATION object , for which  = I was always in favour but it seems as though it is linked to MRN discussio= n and out of specifc OTN.

> <= o:p>

&= nbsp;

So I w= ent looking for past discussions on this, and this is what I find:

&= nbsp;

- From= http://www.ietf.org/mail-archive/web/ccamp/current/msg13598.html

On 7/1= 9/2012 11:45 AM, Lou Berger wrote:

> (= As participant in thread) I read that the conclusion is to not optimize

> f= or a very special corner case and:

> 1= ) basically treat the intra-OTN case the same as any other MRN/MLN case

>&n= bsp;   (leveraging GPID, and no new hierarchy object)<= /span>

> 2= ) Use Daniele's new draft on MRN/MLN as the starting point in the

> d= iscussion of how to address the limitations in MRN/MLN identified in

> t= his discussion.

&= nbsp;

From <= a href=3D"http://tools.ietf.org/agenda/84/slides/slides-84-ccamp-7.pdf"> http://tools.ietf.org/agenda/84/slides/slides-84-ccamp-7.pdf=

> G= -PID Value Extension

> o= Extended G-PID for G.709 ODU client signals:

>&n= bsp;  Value G-PID Type TSG (LO ODU into requested LSP)

>&n= bsp;  ----- ---------- ----------------

>&n= bsp;  47 G.709 ODU 2.5Gbps [RFC4328]

>&n= bsp;  59(TBA) G.709 ODU-1.25G 1.25Gbps (new)

>&n= bsp;  60(TBA) G.709 ODU-any either 1.25 or 2.5Gbps(new)

> <= o:p>

> o= Added other new G-PID values for new client signals supported by G.709V3

>&n= bsp;  Value G-PID Type

>&n= bsp;  ----- ----------

>&n= bsp;  61(TBA) CBRc (via GMP)

>&n= bsp;  62(TBA) 1000BASE-X

>&n= bsp;  63(TBA) FC-1200

> <= o:p>

> o= Updated some existing G-PID description to support new 1.25G, 100G,

>&n= bsp;  supra-2.488G client signals, such as 32 for ATM, 49 for asynchro= nous

>&n= bsp;  CBR , 50 for synchronous CBR , 51 for BSOT, 52 for BSNT.

&= nbsp;

I have= not interest/need to revist past consensus on G-PIDs & TSGs, so

will l= imit my comments to the newly defined G-PIDs.

&= nbsp;

My que= stions on the new G-PIDs come down to:

- Why = are rate specific G-PIDs being proposed (rather than

 = continuing to use the previous approach documented in the draft=

 = and in Section 3.1.3 of rfc4328)?

&= nbsp;

- Why = are new values being defined rather than using existing

 = values, e.g., G-PID 56?

&= nbsp;

That's= it.

&= nbsp;

Lou

&= nbsp;

> H= ope this can help.

> <= o:p>

> B= est Regards

> S= ergio

> <= o:p>

> B= elotti Sergio-  System Architect

> A= LCATE-LUCENT  Optics Division

> v= ia Trento 30 Vimercate (MB) - Italy

> p= hone +39 (039) 6863033

> <= o:p>

> -= ----Messaggio originale-----

> D= a: Lou Berger [mailto:lberger@labn.net]

> I= nviato: mercoled=EC 15 maggio 2013 13.22

> A= : Daniele Ceccarelli; Fatai Zhang

> C= c: BELOTTI, SERGIO (SERGIO); CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3= @tools.ietf.org; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org

> O= ggetto: RE: Closing G.709 open issues

> <= o:p>

> D= aniele,

> <= o:p>

> O= n May 15, 2013 4:20:25 AM Daniele Ceccarelli

> &= lt;daniele.ceccarelli@er= icsson.com> wrote:

>&g= t; Hi Lou,

>&g= t; 

>&g= t; Just a bit.

>&g= t;> My memory is that the consensus at the time was that G.709 would con= tinue

>&g= t; to use the current generic approach to edge adaptation & G-PIDs, and= that

>&g= t; (some of) the G.709 authors would submit a draft that would address

>&g= t; adaptation in a generic fashion.

>&g= t;> 

>&g= t; 

>&g= t; If i correctly remember we agreed to solve the routing issu in a generic

>&g= t; approach, not the signaling one.

> <= o:p>

> W= e must be thinking of different threads. The one I'm thinking of started

> w= ith the comment along the lines of "why only some G-PIDs represented i= n

> t= he ADAPTATION object" and concluded with the agreement to drop the obj= ect

> a= nd follow the current generic approach as well as look into a non-OTN

> s= pecific solution in a new draft.  At least that's how I remember it...= .

> <= o:p>

>&g= t; It is possible to assume that the adaptation is a known info to the

>&g= t; operator and hence that the advertisement can be postponed and addressed= in

>&g= t; a generic way but it needs to be signaled.

>&g= t; 

>&g= t; This is an hortogonal issue with respect to the mapping of G-PID, which = has

>&g= t; always been assumed to be 1:1 with G.709 values.

> <= o:p>

> h= umm, this seems inconsistent with Fatai  recently suggesting that i wa= s

> a= sking for a "non-grouped" approach.  At the time, I was real= ly just

> t= hinking about the values missing in the list I sent out. I don't recall

> a= ny other discussion on moving away from the past 709 G-PID assignment

> a= pproach.

> <= o:p>

>&g= t; The 1:1 *mapping* approach used by Fatai is different from the *mapping&= quot;

>&g= t; protocol like GFP, AMP that we discussed before.

>&g= t; 

> <= o:p>

> I= t looks like we both/all should take a look at the archives to refresh our

> m= emories....

> <= o:p>

> T= hanks,

>&n= bsp; Lou

> <= o:p>

>&g= t; BR

>&g= t; Daniele, Sergio, Fatai

>&g= t; 

>&g= t; 

>&g= t;> -----Original Message-----

>&g= t;> From: Lou Berger [mailto:lberger@labn.net] Sent: marted= =EC 14 maggio 2013 16.01

>&g= t;> To: Fatai Zhang

>&g= t;> Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP;

>&g= t; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org;

>&g= t; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org

>&g= t;> Subject: Re: Closing G.709 open issues

>&g= t;> 

>&g= t;> Fatai, Sergio,

>&g= t;>          I haven't had time = to go find the old mail covering the topic you

>&g= t; mentioned (which is why I didn't respond yesterday):

>&g= t;>> I think this has been discussed for quite long time before Vanco= uver

>&g= t; meeting, which was famous as "penultimate" issue.

>&g= t;>> 

>&g= t;>> I don't think we need discuss this anymore.

>&g= t;> 

>&g= t;> My memory is that the consensus at the time was that G.709 would con= tinue

>&g= t; to use the current generic approach to edge adaptation & G-PIDs, and= that

>&g= t; (some of) the G.709 authors would submit a draft that would address

>&g= t; adaptation in a generic fashion.

>&g= t;> 

>&g= t;> Do you think this characterization is mistaken?  (If so, time t= o go

>&g= t; searching for the old discussion, if not we can move on.)

>&g= t;> 

>&g= t;> Assuming no, then it seems to me that you are going against this

>&g= t; discussion & consensus by now introducing a 1:1/bandwidth specific m= apping

>&g= t; approach. Do you disagree?  If not, do you think there's justificat= ion to

>&g= t; reopen this discussion?

>&g= t;> 

>&g= t;> Independent of the mapping approach and in order to ensure this issu= e is

>&g= t; closed and does not again resurface, I also request (again) that the

>&g= t; editors of the draft provide (and include in the document) a full list o= f

>&g= t; Payload Type values (with the 0x value prefix or the values in

>&g= t;> decimal) and their corresponding G-PID values.  Also including = Encoding

>&g= t; Type as you have below is a good addition -- great idea!

>&g= t;> 

>&g= t;> Lou

>&g= t;> 

>&g= t;> On 5/14/2013 1:53 AM, Fatai Zhang wrote:

>&g= t;>> Hi all,

>&g= t;>> Thanks, Sergio.

>&g= t;>> I would like to double check if everything is OK before we >u= pdate the

>&g= t; signaling draft.

>&g= t;>> I would assume the WG is happy with 1:1 mapping approach and >= ;the new

>&g= t; GPIDs listed below if there is no more comment until this Wed.

>&g= t;>> 

>&g= t;>> Best Regards

>&g= t;>> Fatai

>&g= t;>> 

>&g= t;>> -----Original Message-----

>&g= t;>> From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-lu= cent.com]

>&g= t;>> Sent: Monday, May 13, 2013 3:45 PM

>&g= t;>> To: Fatai Zhang; Lou Berger

>&g= t;>> Cc: Daniele Ceccarelli; CCAMP;

>&g= t; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org;

>&g= t; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org

>&g= t;>> Subject: R: Closing G.709 open issues

>&g= t;>> Hi Fatai,

>&g= t;>> I agree with you, for both point 1 and 2.

>&g= t;>> Best Regards

>&g= t;>> Sergio

>&g= t;>> Belotti Sergio-  System Architect

>&g= t;>> ALCATE-LUCENT  Optics Division

>&g= t;>> via Trento 30 Vimercate (MB) - Italy

>&g= t;>> phone +39 (039) 6863033

>&g= t;>> -----Messaggio originale-----

>&g= t;>> Da: Fatai Zhang [mailto:zhangfatai@huawei.com]=

>&g= t;>> Inviato: luned=EC 13 maggio 2013 5.33

>&g= t;>> A: Lou Berger

>&g= t;>> Cc: Daniele Ceccarelli; CCAMP;

>&g= t; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org;

>&g= t; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org

>&g= t;>> Oggetto: RE: Closing G.709 open issues

>&g= t;>> Hi Lou,

>&g= t;>> I think you have two major points here.

>&g= t;>> (1) Do you really need 3 G-PID types for an ODU (I thought >T= SG was

>&g= t; already covered)?

>&g= t;>> I think this has been discussed for quite long time before >V= ancouver

>&g= t; meeting, which was famous as "penultimate" issue. >Note tha= t this TSG in

>&g= t; GPID is different from the *implicit* >TSG in label format.

>&g= t;>> I don't think we need discuss this anymore.

>&g= t;>> (2) 'Grouped GPID' vs '1:1' mapping (between G.709-2012 and GPID= s

>&g= t; defined in this draft)

>&g= t;>> We realize that it is safe to use 1:1 mapping approach to >av= oid some

>&g= t; potential issues after investigation. We know this >payload types hav= e been

>&g= t; defined by G.709 (data plane), so >physically it is better to use 1:1

>&g= t; mapping approach. For the potential issues I mentioned above, for exampl= e,

>&g= t; we >cannot use the existing 34 to represent 'STM-1' and 'STM-4 ', >= ;because

>&g= t; it is impossible to differentiate which one is 'STM-1' >or 'STM-4'. I= n

>&g= t; addition, from the concept of payload type, we >know that e.g, FC-100= is

>&g= t; different from FC-800, right? So, it >is better to assign different G= PIDs

>&g= t; to these different payload >types defined by the data plane.

>&g= t;>> Furthermore, I think it is much cheaper to create new GPIDs >= in the

>&g= t; control plane than in the data plane (these payload >types will be ca= rried

>&g= t; in the OH).

>&g= t;>> 

>&g= t;>> Best Regards

>&g= t;>> Fatai

>&g= t;>> 

>&g= t;>> -----Original Message-----

>&g= t;>> From: Lou Berger [mailto:lberger@labn.net]

>&g= t;>> Sent: Friday, May 10, 2013 8:51 PM

>&g= t;>> To: Fatai Zhang

>&g= t;>> Cc: Daniele Ceccarelli; CCAMP;

>&g= t; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org;

>&g= t; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org

>&g= t;>> Subject: Re: Closing G.709 open issues

>&g= t;>> 

>&g= t;>> On 5/9/2013 9:41 PM, Fatai Zhang wrote:

>&g= t;>>> Hi Lou,

>&g= t;>>> 

>&g= t;>>> For point 1), "1" should be dropped and "7&qu= ot; should be >corrected to "8"

>&g= t; in your proposed text. >> >> Great.

>&g= t;>>>>> 

>&g= t;>>> I hesitate to make a decision on either approach, I would &g= t;like to

>&g= t; defer to the WG consensus.

>&g= t;>>> 

>&g= t;>> I believe we already have a consensus position.  The questi= on in my mail

>&g= t; was do we need to revisit it.  I take your response as a no. (thank= you!)

>&g= t;>>>>> For point 2), I compared [G.709-2003] and [G.709-201= 2], and checked

>&g= t;>>> the GPIDs defined in [RFC4328], I think the following new GP= IDs >>>

>&g= t; (values could be 59-79) should be added (besides updating >some GPIDs= >>>

>&g= t; defined in RFC4328, like 32,47,49-52):

>&g= t;>>> 

>&g= t;>> I suggest going through the full PT list and identifying them in= the

>&g= t; table (as I started in my last message) so that there is no >confusio= n in

>&g= t; implementations.

>&g= t;>> In the list below it looks like you have moved away from the >= ;'grouped

>&g= t; G-PID' approach.  Is there a reason for this change?

>&g= t;>> Refer to

>&g= t;>>> http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-paramet<= o:p>

>&g= t;>> ers.xml

>&g= t;>> in subsequent comments.

>&g= t;>>>>>     Value    = ;   G-PID Type        &nb= sp;    LSP Encoding Type

>&g= t;>>>      -----    &= nbsp;  ----------         = ;    -----------------

>&g= t;>>>    59(TBA)     G.709 ODU-= 1.25G        G.709 ODUk 60(TBA) &nb= sp;   G.709

>&g= t; ODU-any          G.709 ODUk=

>&g= t;>> Do you really need 3 G-PID types for an ODU (I thought TSG >w= as already

>&g= t; covered)?

>&g= t;>>>>>    61(TBA)     PC= S            &n= bsp;       G.709 ODUk (k=3D0)

>&g= t;>>>    62(TBA)     FC-1200&nb= sp;            =    G.709 ODUk (k=3D2e)

>&g= t;>> Why not us existing G-PID 58?

>&g= t;>>>>>    63(TBA)     eO= PU2            =      G.709 ODUk (k=3D2)

>&g= t;>>>>>    64(TBA)     ST= M-1            =       G.709 ODUk (k=3D0)

>&g= t;>>>    65(TBA)     STM-4 = ;             &= nbsp;   G.709 ODUk (k=3D0)

>&g= t;>> Why not us existing G-PID 34?

>&g= t;>>>>>    66(TBA)     FC= -100            = ;     G.709 ODUk (k=3D0)

>&g= t;>>>    67(TBA)     FC-200&nbs= p;            &= nbsp;   G.709 ODUk (k=3D1)

>&g= t;>>>    68(TBA)     FC-400&nbs= p;            &= nbsp;   G.709 ODUflex

>&g= t;>>>    69(TBA)     FC-800&nbs= p;            &= nbsp;   G.709 ODUflex

>&g= t;>> Why not us existing G-PID 58?

>&g= t;>>>>>    70(TBA)     IB= SDR            = ;     G.709 ODUflex

>&g= t;>>>    71(TBA)     IB DDR&nbs= p;            &= nbsp;   G.709 ODUflex

>&g= t;>>>    72(TBA)     IB QDR&nbs= p;            &= nbsp;   G.709 ODUflex

>&g= t;>> Can these be one value with rate implying SDR/DDR/QDR?

>&g= t;>>>>>    73(TBA)     SD= Ia            &= nbsp;      G.709 ODUk (k=3D0)

>&g= t;>>>    74(TBA)     SDIb =             &nb= sp;     G.709 ODUk (k=3D1)

>&g= t;>>>    75(TBA)     SDIc =             &nb= sp;     G.709 ODUk (k=3D1)

>&g= t;>>>    76(TBA)     SDId =             &nb= sp;     G.709 ODUflex

>&g= t;>>>    77(TBA)     SDIe =             &nb= sp;     G.709 ODUflex

>&g= t;>> Can these be one value with rate implying a-e?=

>&g= t;>>>>>    78(TBA)     SB= /ESCON           &nb= sp;  G.709 ODUk (k=3D0)

>&g= t;>> Why not us existing G-PID 56?

>&g= t;>>>>>    79(TBA)     DV= B_ASI           &nbs= p;    G.709 ODUk (k=3D0)

>&g= t;>>> 

>&g= t;>>> 

>&g= t;>>> 

>&g= t;>>> 

>&g= t;>> Thanks,

>&g= t;>> Lou

>&g= t;>> 

>&g= t;>> 

>&g= t;>> 

>&g= t;> 

> <= o:p>

> <= o:p>

> <= o:p>

> <= o:p>

> <= o:p>

> <= o:p>

--_000_D8D01B39D6B38C45AA37C06ECC1D65D53FD6D110SVEXDBPROD2infi_-- From jdrake@juniper.net Mon May 20 06:23:32 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8900C21F937A for ; Mon, 20 May 2013 06:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.467 X-Spam-Level: X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2ePlLjelSPF for ; Mon, 20 May 2013 06:22:46 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 5217F21F936E for ; Mon, 20 May 2013 06:22:26 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKUZojj+NzwwzekLMNhnZk+INE9Z8HQJTr@postini.com; Mon, 20 May 2013 06:22:27 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 20 May 2013 06:15:54 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Mon, 20 May 2013 06:15:54 -0700 Received: from CO9EHSOBE034.bigfish.com (207.46.163.26) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 20 May 2013 06:18:38 -0700 Received: from mail15-co9-R.bigfish.com (10.236.132.234) by CO9EHSOBE034.bigfish.com (10.236.130.97) with Microsoft SMTP Server id 14.1.225.23; Mon, 20 May 2013 13:15:53 +0000 Received: from mail15-co9 (localhost [127.0.0.1]) by mail15-co9-R.bigfish.com (Postfix) with ESMTP id A637D2A0A06 for ; Mon, 20 May 2013 13:15:53 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT005.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -46 X-BigFish: PS-46(z21aILzbb2dI98dI9371I542I1432I4015Idb82hzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1155h) Received: from mail15-co9 (localhost.localdomain [127.0.0.1]) by mail15-co9 (MessageSwitch) id 1369055705892826_22004; Mon, 20 May 2013 13:15:05 +0000 (UTC) Received: from CO9EHSMHS023.bigfish.com (unknown [10.236.132.251]) by mail15-co9.bigfish.com (Postfix) with ESMTP id CD14E20260; Mon, 20 May 2013 13:15:05 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS023.bigfish.com (10.236.130.33) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 20 May 2013 13:15:04 +0000 Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.1.63]) by BL2PRD0510HT005.namprd05.prod.outlook.com ([10.255.100.40]) with mapi id 14.16.0311.000; Mon, 20 May 2013 13:15:01 +0000 From: John E Drake To: Lou Berger Thread-Topic: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 open issues) Thread-Index: AQHOUz2x/LI/EygSNE2StyemUF3KopkOC57A Date: Mon, 20 May 2013 13:15:00 +0000 Message-ID: <0182DEA5604B3A44A2EE61F3EE3ED69E1D504EAD@BL2PRD0510MB349.namprd05.prod.outlook.com> References: <518A82D9.7080508@labn.net> <518BAB17.9090807@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> <519657FE.5030602@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D5009B0@BL2PRD0510MB349.namprd05.prod.outlook.com> <519693DF.6000003@labn.net> In-Reply-To: <519693DF.6000003@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.52] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%LABN.NET$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%HUAWEI.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" , "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" , CCAMP Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 open issues) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 13:23:39 -0000 Length (12 bits): indicates the number of bits of the Bit Map field, i.e., = the number of TS in the HO ODUk link. The TS granularity, 1.25Gbps or 2.5G= bps, may be derived by dividing the HO ODUk link's rate by the value of the= Length field. For example, for an HO ODU2 link, whose link rate is 10Gbps= , the value of the Length field will be either 4 or 8 and the TS granularit= y will be either 2.5Gbps or 1.25Gbps, respectively. =20 Irrespectively Yours, John > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Friday, May 17, 2013 1:33 PM > To: John E Drake > Cc: Fatai Zhang; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; > CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org > Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 > open issues) >=20 > John, > I guess you haven't been paying attention! The rewrite > originated from Daniele, was tweaked by me and then fixed by Fatai. >=20 > Do you have an alternate proposal to address issue#48? > Issue #48=3D"In signaling document section 6: Clarify related text [i.e., > the OLD text] to unambiguously identify the relationship between label > length and TSG." >=20 > Thanks, > Lou >=20 > On 5/17/2013 1:15 PM, John E Drake wrote: > > Lou, > > > > I think the original text is fine and your attempted re-write > completely mangled its meaning. The label is a bit vector whose length > is equal to the ODUk rate / TSG. > > > > Irrespectively Yours, > > > > John > > > > > >> -----Original Message----- > >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > >> Behalf Of Lou Berger > >> Sent: Friday, May 17, 2013 9:17 AM > >> To: Fatai Zhang > >> Cc: draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; CCAMP; > >> draft- ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org > >> Subject: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 > >> open issues) > >> > >> Authors/WG, > >> From the mail on the list it seems to me that we've reached > closure > >> on Issue #48: "Document no explicit indication of TSG in the label" > >> (http://trac.tools.ietf.org/wg/ccamp/trac/ticket/48). I'd like to > >> confirm my reading. > >> > >> As I read the list, this issue will be resolved by making the > >> following change to draft-ietf-ccamp-gmpls-signaling-g709v3. > >> > >> OLD > >> Note that the > >> Length field in the label format MAY be used to indicate the TS > >> type of the HO ODUk (i.e., TS granularity at 1.25Gbps or 2.5Gbps) > >> since the HO ODUk type can be known from IF_ID RSVP_HOP Object. In > >> some cases when there is no Link Management Protocol (LMP) or > >> routing to make the two end points of the link to know the TSG, > >> the TSG information used by another end can be deduced from the > >> label format. For example, for HO ODU2 link, the value of the > >> length filed will be 4 or 8, which indicates the TS granularity is > >> 2.5Gbps or 1.25Gbps, respectively. > >> > >> NEW > >> Please note that the TS granularity of an HO ODUk can be inferred > >> from > >> the length of the label. The values of 4 and 16 indicate a TS > >> granularity of 2.5Gps, while the values 2, 8, 32 and 80 indicate a > TS > >> granularity of 1.25Gps. > >> > >> Please speak up if you disagree with this resolution. > >> > >> Thanks, > >> Lou > >> > >> On 5/9/2013 9:41 PM, Fatai Zhang wrote: > >>> For point 1), "1" should be dropped and "7" should be corrected to > >> "8" in your proposed text. > >>> > >> > >> _______________________________________________ > >> CCAMP mailing list > >> CCAMP@ietf.org > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > > > > > From lberger@labn.net Mon May 20 11:43:40 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9600E21F8EEA for ; Mon, 20 May 2013 11:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.092 X-Spam-Level: X-Spam-Status: No, score=-103.092 tagged_above=-999 required=5 tests=[AWL=0.507, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfM7WaoJ3jj0 for ; Mon, 20 May 2013 11:43:36 -0700 (PDT) Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id 1F7EE21F8721 for ; Mon, 20 May 2013 11:43:35 -0700 (PDT) Received: (qmail 29101 invoked by uid 0); 20 May 2013 18:43:13 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy12.bluehost.com with SMTP; 20 May 2013 18:43:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=JfMzFvqB6xhYn+825s3CEbqbXxLfXOu8kQpapT/oenc=; b=fmg1wyFdbuijmQF5I8GuLBl+zydkwESbi/rfSEu9ERKUTrkI6QmbuINhAM//WfLLhxypS0KlP0NelrZjlOLFDKeS8+hsS5Iin38OsICypO/AltBipMYB1fUCBzmd44CO; Received: from box313.bluehost.com ([69.89.31.113]:36019 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UeV3A-0008FI-OM; Mon, 20 May 2013 12:43:12 -0600 Message-ID: <519A6EC1.4080205@labn.net> Date: Mon, 20 May 2013 14:43:13 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: John E Drake References: <518A82D9.7080508@labn.net> <518BAB17.9090807@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> <519657FE.5030602@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D5009B0@BL2PRD0510MB349.namprd05.prod.outlook.com> <519693DF.6000003@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D504EAD@BL2PRD0510MB349.namprd05.prod.outlook.com> In-Reply-To: <0182DEA5604B3A44A2EE61F3EE3ED69E1D504EAD@BL2PRD0510MB349.namprd05.prod.outlook.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" , "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" , CCAMP Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 open issues) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 18:43:40 -0000 John, There's still some ambiguity here. How about: On 5/20/2013 9:15 AM, John E Drake wrote: > Length (12 bits): indicates the number of bits of the Bit Map field, > i.e., the number of TS in the HO ODUk link. The TS granularity, > 1.25Gbps or 2.5Gbps, may be derived by dividing the HO ODUk link's > rate by the value of the Length field. Replace: > For example, for an HO ODU2 > link, whose link rate is 10Gbps, the value of the Length field will > be either 4 or 8 and the TS granularity will be either 2.5Gbps or > 1.25Gbps, respectively. > With: The values of 4 and 16 indicate a TS granularity of 2.5Gps, while the values 2, 8, 32 and 80 indicate a TS granularity of 1.25Gps. Lou > Irrespectively Yours, > > John > > >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Friday, May 17, 2013 1:33 PM >> To: John E Drake >> Cc: Fatai Zhang; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; >> CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >> Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 >> open issues) >> >> John, >> I guess you haven't been paying attention! The rewrite >> originated from Daniele, was tweaked by me and then fixed by Fatai. >> >> Do you have an alternate proposal to address issue#48? >> Issue #48="In signaling document section 6: Clarify related text [i.e., >> the OLD text] to unambiguously identify the relationship between label >> length and TSG." >> >> Thanks, >> Lou >> >> On 5/17/2013 1:15 PM, John E Drake wrote: >>> Lou, >>> >>> I think the original text is fine and your attempted re-write >> completely mangled its meaning. The label is a bit vector whose length >> is equal to the ODUk rate / TSG. >>> >>> Irrespectively Yours, >>> >>> John >>> >>> >>>> -----Original Message----- >>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>>> Behalf Of Lou Berger >>>> Sent: Friday, May 17, 2013 9:17 AM >>>> To: Fatai Zhang >>>> Cc: draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; CCAMP; >>>> draft- ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>> Subject: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 >>>> open issues) >>>> >>>> Authors/WG, >>>> From the mail on the list it seems to me that we've reached >> closure >>>> on Issue #48: "Document no explicit indication of TSG in the label" >>>> (http://trac.tools.ietf.org/wg/ccamp/trac/ticket/48). I'd like to >>>> confirm my reading. >>>> >>>> As I read the list, this issue will be resolved by making the >>>> following change to draft-ietf-ccamp-gmpls-signaling-g709v3. >>>> >>>> OLD >>>> Note that the >>>> Length field in the label format MAY be used to indicate the TS >>>> type of the HO ODUk (i.e., TS granularity at 1.25Gbps or 2.5Gbps) >>>> since the HO ODUk type can be known from IF_ID RSVP_HOP Object. In >>>> some cases when there is no Link Management Protocol (LMP) or >>>> routing to make the two end points of the link to know the TSG, >>>> the TSG information used by another end can be deduced from the >>>> label format. For example, for HO ODU2 link, the value of the >>>> length filed will be 4 or 8, which indicates the TS granularity is >>>> 2.5Gbps or 1.25Gbps, respectively. >>>> >>>> NEW >>>> Please note that the TS granularity of an HO ODUk can be inferred >>>> from >>>> the length of the label. The values of 4 and 16 indicate a TS >>>> granularity of 2.5Gps, while the values 2, 8, 32 and 80 indicate a >> TS >>>> granularity of 1.25Gps. >>>> >>>> Please speak up if you disagree with this resolution. >>>> >>>> Thanks, >>>> Lou >>>> >>>> On 5/9/2013 9:41 PM, Fatai Zhang wrote: >>>>> For point 1), "1" should be dropped and "7" should be corrected to >>>> "8" in your proposed text. >>>>> >>>> >>>> _______________________________________________ >>>> CCAMP mailing list >>>> CCAMP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ccamp >>> >>> >>> >>> >>> >>> > > > > > > From jdrake@juniper.net Mon May 20 12:26:19 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 550F921F96AB for ; Mon, 20 May 2013 12:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.467 X-Spam-Level: X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agzzv8znxt+z for ; Mon, 20 May 2013 12:26:05 -0700 (PDT) Received: from exprod7og128.obsmtp.com (exprod7og128.obsmtp.com [64.18.2.121]) by ietfa.amsl.com (Postfix) with ESMTP id 4A47621F9681 for ; Mon, 20 May 2013 12:26:01 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob128.postini.com ([64.18.6.12]) with SMTP ID DSNKUZp4yIIqokiEscef79I7UeAqf62kZ58+@postini.com; Mon, 20 May 2013 12:26:02 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 20 May 2013 12:18:50 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Mon, 20 May 2013 12:18:50 -0700 Received: from va3outboundpool.messaging.microsoft.com (216.32.180.30) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 20 May 2013 12:29:39 -0700 Received: from mail90-va3-R.bigfish.com (10.7.14.247) by VA3EHSOBE011.bigfish.com (10.7.40.61) with Microsoft SMTP Server id 14.1.225.23; Mon, 20 May 2013 19:18:49 +0000 Received: from mail90-va3 (localhost [127.0.0.1]) by mail90-va3-R.bigfish.com (Postfix) with ESMTP id A3A853600E1 for ; Mon, 20 May 2013 19:18:49 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT005.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -47 X-BigFish: PS-47(z21aILzbb2dI98dI9371I542I1432I1418I4015Idb82hzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dh8275chz2dh2a8h668h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1155h) Received: from mail90-va3 (localhost.localdomain [127.0.0.1]) by mail90-va3 (MessageSwitch) id 1369077527953476_10083; Mon, 20 May 2013 19:18:47 +0000 (UTC) Received: from VA3EHSMHS006.bigfish.com (unknown [10.7.14.235]) by mail90-va3.bigfish.com (Postfix) with ESMTP id DAA243400D1; Mon, 20 May 2013 19:18:47 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS006.bigfish.com (10.7.99.16) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 20 May 2013 19:18:47 +0000 Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.1.63]) by BL2PRD0510HT005.namprd05.prod.outlook.com ([10.255.100.40]) with mapi id 14.16.0311.000; Mon, 20 May 2013 19:18:46 +0000 From: John E Drake To: Lou Berger Thread-Topic: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 open issues) Thread-Index: AQHOUz2x/LI/EygSNE2StyemUF3KopkOC57AgABhqoCAAAntLQ== Date: Mon, 20 May 2013 19:18:45 +0000 Message-ID: <9574E62A-6A68-4290-A103-8A0A750E2004@juniper.net> References: <518A82D9.7080508@labn.net> <518BAB17.9090807@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> <519657FE.5030602@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D5009B0@BL2PRD0510MB349.namprd05.prod.outlook.com> <519693DF.6000003@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D504EAD@BL2PRD0510MB349.namprd05.prod.outlook.com>, <519A6EC1.4080205@labn.net> In-Reply-To: <519A6EC1.4080205@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.147.96.91] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%LABN.NET$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%HUAWEI.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" , "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" , CCAMP Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 open issues) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 19:26:20 -0000 I think that's a big mistake(tm). If a new rate or TSG is introduced the R= FC would need to be updated even though the encoding does not require it. Sent from my iPhone On May 20, 2013, at 2:43 PM, "Lou Berger" wrote: > John, > There's still some ambiguity here. How about: > On 5/20/2013 9:15 AM, John E Drake wrote: >> Length (12 bits): indicates the number of bits of the Bit Map field, >> i.e., the number of TS in the HO ODUk link. The TS granularity, >> 1.25Gbps or 2.5Gbps, may be derived by dividing the HO ODUk link's >> rate by the value of the Length field. =20 >=20 >=20 > Replace: >> For example, for an HO ODU2 >> link, whose link rate is 10Gbps, the value of the Length field will >> be either 4 or 8 and the TS granularity will be either 2.5Gbps or >> 1.25Gbps, respectively. > With: >=20 > The values of 4 and 16 indicate a TS granularity of 2.5Gps, while > the values 2, 8, 32 and 80 indicate a TS granularity of 1.25Gps. >=20 > Lou >=20 >=20 >> Irrespectively Yours, >>=20 >> John >>=20 >>=20 >>> -----Original Message----- >>> From: Lou Berger [mailto:lberger@labn.net] >>> Sent: Friday, May 17, 2013 1:33 PM >>> To: John E Drake >>> Cc: Fatai Zhang; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; >>> CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>> Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 >>> open issues) >>>=20 >>> John, >>> I guess you haven't been paying attention! The rewrite >>> originated from Daniele, was tweaked by me and then fixed by Fatai. >>>=20 >>> Do you have an alternate proposal to address issue#48? >>> Issue #48=3D"In signaling document section 6: Clarify related text [i.e= ., >>> the OLD text] to unambiguously identify the relationship between label >>> length and TSG." >>>=20 >>> Thanks, >>> Lou >>>=20 >>> On 5/17/2013 1:15 PM, John E Drake wrote: >>>> Lou, >>>>=20 >>>> I think the original text is fine and your attempted re-write >>> completely mangled its meaning. The label is a bit vector whose length >>> is equal to the ODUk rate / TSG. >>>>=20 >>>> Irrespectively Yours, >>>>=20 >>>> John >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>>>> Behalf Of Lou Berger >>>>> Sent: Friday, May 17, 2013 9:17 AM >>>>> To: Fatai Zhang >>>>> Cc: draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; CCAMP; >>>>> draft- ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>>> Subject: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 >>>>> open issues) >>>>>=20 >>>>> Authors/WG, >>>>> From the mail on the list it seems to me that we've reached >>> closure >>>>> on Issue #48: "Document no explicit indication of TSG in the label" >>>>> (http://trac.tools.ietf.org/wg/ccamp/trac/ticket/48). I'd like to >>>>> confirm my reading. >>>>>=20 >>>>> As I read the list, this issue will be resolved by making the >>>>> following change to draft-ietf-ccamp-gmpls-signaling-g709v3. >>>>>=20 >>>>> OLD >>>>> Note that the >>>>> Length field in the label format MAY be used to indicate the TS >>>>> type of the HO ODUk (i.e., TS granularity at 1.25Gbps or 2.5Gbps) >>>>> since the HO ODUk type can be known from IF_ID RSVP_HOP Object. In >>>>> some cases when there is no Link Management Protocol (LMP) or >>>>> routing to make the two end points of the link to know the TSG, >>>>> the TSG information used by another end can be deduced from the >>>>> label format. For example, for HO ODU2 link, the value of the >>>>> length filed will be 4 or 8, which indicates the TS granularity is >>>>> 2.5Gbps or 1.25Gbps, respectively. >>>>>=20 >>>>> NEW >>>>> Please note that the TS granularity of an HO ODUk can be inferred >>>>> from >>>>> the length of the label. The values of 4 and 16 indicate a TS >>>>> granularity of 2.5Gps, while the values 2, 8, 32 and 80 indicate a >>> TS >>>>> granularity of 1.25Gps. >>>>>=20 >>>>> Please speak up if you disagree with this resolution. >>>>>=20 >>>>> Thanks, >>>>> Lou >>>>>=20 >>>>> On 5/9/2013 9:41 PM, Fatai Zhang wrote: >>>>>> For point 1), "1" should be dropped and "7" should be corrected to >>>>> "8" in your proposed text. >>>>>=20 >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >=20 From jdrake@juniper.net Mon May 20 12:35:34 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01FB121F96D6 for ; Mon, 20 May 2013 12:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.467 X-Spam-Level: X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+1eam4reZrs for ; Mon, 20 May 2013 12:35:28 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5CE21F96C4 for ; Mon, 20 May 2013 12:35:28 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKUZp6/+QEpt1cEiDsyCqZnwhyrqsvUJMN@postini.com; Mon, 20 May 2013 12:35:28 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 20 May 2013 12:28:46 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Mon, 20 May 2013 12:28:45 -0700 Received: from db9outboundpool.messaging.microsoft.com (213.199.154.251) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 20 May 2013 12:31:29 -0700 Received: from mail47-db9-R.bigfish.com (10.174.16.240) by DB9EHSOBE002.bigfish.com (10.174.14.65) with Microsoft SMTP Server id 14.1.225.23; Mon, 20 May 2013 19:28:43 +0000 Received: from mail47-db9 (localhost [127.0.0.1]) by mail47-db9-R.bigfish.com (Postfix) with ESMTP id 9205340089 for ; Mon, 20 May 2013 19:28:43 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT003.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -46 X-BigFish: PS-46(z21aILzbb2dI98dI9371I542I1432I4015Idb82hzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dh8275chz2dh2a8h668h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1155h) Received: from mail47-db9 (localhost.localdomain [127.0.0.1]) by mail47-db9 (MessageSwitch) id 1369078121964468_24234; Mon, 20 May 2013 19:28:41 +0000 (UTC) Received: from DB9EHSMHS018.bigfish.com (unknown [10.174.16.237]) by mail47-db9.bigfish.com (Postfix) with ESMTP id DCF884A00BC; Mon, 20 May 2013 19:28:41 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS018.bigfish.com (10.174.14.28) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 20 May 2013 19:28:38 +0000 Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.1.63]) by BL2PRD0510HT003.namprd05.prod.outlook.com ([10.255.100.38]) with mapi id 14.16.0311.000; Mon, 20 May 2013 19:28:36 +0000 From: John E Drake To: Lou Berger Thread-Topic: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 open issues) Thread-Index: AQHOUz2x/LI/EygSNE2StyemUF3KopkOC57AgABhqoCAAAytTQ== Date: Mon, 20 May 2013 19:28:35 +0000 Message-ID: <0AD459F3-28DB-4AD7-8204-CE7BECAC243E@juniper.net> References: <518A82D9.7080508@labn.net> <518BAB17.9090807@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> <519657FE.5030602@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D5009B0@BL2PRD0510MB349.namprd05.prod.outlook.com> <519693DF.6000003@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D504EAD@BL2PRD0510MB349.namprd05.prod.outlook.com>, <519A6EC1.4080205@labn.net> In-Reply-To: <519A6EC1.4080205@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.147.96.91] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%LABN.NET$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%HUAWEI.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" , "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" , CCAMP Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 open issues) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 19:35:34 -0000 Btw, what is the alleged ambiguity to which you refer? Sent from my iPhone On May 20, 2013, at 2:43 PM, "Lou Berger" wrote: > John, > There's still some ambiguity here. How about: > On 5/20/2013 9:15 AM, John E Drake wrote: >> Length (12 bits): indicates the number of bits of the Bit Map field, >> i.e., the number of TS in the HO ODUk link. The TS granularity, >> 1.25Gbps or 2.5Gbps, may be derived by dividing the HO ODUk link's >> rate by the value of the Length field. =20 >=20 >=20 > Replace: >> For example, for an HO ODU2 >> link, whose link rate is 10Gbps, the value of the Length field will >> be either 4 or 8 and the TS granularity will be either 2.5Gbps or >> 1.25Gbps, respectively. > With: >=20 > The values of 4 and 16 indicate a TS granularity of 2.5Gps, while > the values 2, 8, 32 and 80 indicate a TS granularity of 1.25Gps. >=20 > Lou >=20 >=20 >> Irrespectively Yours, >>=20 >> John >>=20 >>=20 >>> -----Original Message----- >>> From: Lou Berger [mailto:lberger@labn.net] >>> Sent: Friday, May 17, 2013 1:33 PM >>> To: John E Drake >>> Cc: Fatai Zhang; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; >>> CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>> Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 >>> open issues) >>>=20 >>> John, >>> I guess you haven't been paying attention! The rewrite >>> originated from Daniele, was tweaked by me and then fixed by Fatai. >>>=20 >>> Do you have an alternate proposal to address issue#48? >>> Issue #48=3D"In signaling document section 6: Clarify related text [i.e= ., >>> the OLD text] to unambiguously identify the relationship between label >>> length and TSG." >>>=20 >>> Thanks, >>> Lou >>>=20 >>> On 5/17/2013 1:15 PM, John E Drake wrote: >>>> Lou, >>>>=20 >>>> I think the original text is fine and your attempted re-write >>> completely mangled its meaning. The label is a bit vector whose length >>> is equal to the ODUk rate / TSG. >>>>=20 >>>> Irrespectively Yours, >>>>=20 >>>> John >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>>>> Behalf Of Lou Berger >>>>> Sent: Friday, May 17, 2013 9:17 AM >>>>> To: Fatai Zhang >>>>> Cc: draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; CCAMP; >>>>> draft- ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>>> Subject: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 >>>>> open issues) >>>>>=20 >>>>> Authors/WG, >>>>> From the mail on the list it seems to me that we've reached >>> closure >>>>> on Issue #48: "Document no explicit indication of TSG in the label" >>>>> (http://trac.tools.ietf.org/wg/ccamp/trac/ticket/48). I'd like to >>>>> confirm my reading. >>>>>=20 >>>>> As I read the list, this issue will be resolved by making the >>>>> following change to draft-ietf-ccamp-gmpls-signaling-g709v3. >>>>>=20 >>>>> OLD >>>>> Note that the >>>>> Length field in the label format MAY be used to indicate the TS >>>>> type of the HO ODUk (i.e., TS granularity at 1.25Gbps or 2.5Gbps) >>>>> since the HO ODUk type can be known from IF_ID RSVP_HOP Object. In >>>>> some cases when there is no Link Management Protocol (LMP) or >>>>> routing to make the two end points of the link to know the TSG, >>>>> the TSG information used by another end can be deduced from the >>>>> label format. For example, for HO ODU2 link, the value of the >>>>> length filed will be 4 or 8, which indicates the TS granularity is >>>>> 2.5Gbps or 1.25Gbps, respectively. >>>>>=20 >>>>> NEW >>>>> Please note that the TS granularity of an HO ODUk can be inferred >>>>> from >>>>> the length of the label. The values of 4 and 16 indicate a TS >>>>> granularity of 2.5Gps, while the values 2, 8, 32 and 80 indicate a >>> TS >>>>> granularity of 1.25Gps. >>>>>=20 >>>>> Please speak up if you disagree with this resolution. >>>>>=20 >>>>> Thanks, >>>>> Lou >>>>>=20 >>>>> On 5/9/2013 9:41 PM, Fatai Zhang wrote: >>>>>> For point 1), "1" should be dropped and "7" should be corrected to >>>>> "8" in your proposed text. >>>>>=20 >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >=20 From lberger@labn.net Mon May 20 13:42:01 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC96B21F9680 for ; Mon, 20 May 2013 13:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.457 X-Spam-Level: X-Spam-Status: No, score=-102.457 tagged_above=-999 required=5 tests=[AWL=-0.192, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQlK+FixJqAE for ; Mon, 20 May 2013 13:41:57 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 570E821F9676 for ; Mon, 20 May 2013 13:41:57 -0700 (PDT) Received: (qmail 21159 invoked by uid 0); 20 May 2013 20:41:34 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.bluehost.com with SMTP; 20 May 2013 20:41:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=xslIOGgELaQR6kFEN1qk0DfTVAE1Y/r2KZT90pQqSYE=; b=ckIrMu8HotfsQXZt0UR44JCmIKWXbOKUqbccza4zyp+TrZ1U+V8BHMKq0hD+N47J9Pole5/n3C38lD1kp1blgDgpNYluRsM2E0OnI5MdjQUh8mNxol83kp4V0Om1atgk; Received: from box313.bluehost.com ([69.89.31.113]:51190 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UeWti-0002iE-0L; Mon, 20 May 2013 14:41:34 -0600 Message-ID: <519A8A7D.5020002@labn.net> Date: Mon, 20 May 2013 16:41:33 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: John E Drake References: <518A82D9.7080508@labn.net> <518BAB17.9090807@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> <519657FE.5030602@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D5009B0@BL2PRD0510MB349.namprd05.prod.outlook.com> <519693DF.6000003@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D504EAD@BL2PRD0510MB349.namprd05.prod.outlook.com>, <519A6EC1.4080205@labn.net> <9574E62A-6A68-4290-A103-8A0A750E2004@juniper.net> In-Reply-To: <9574E62A-6A68-4290-A103-8A0A750E2004@juniper.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" , "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" , CCAMP Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 open issues) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 20:42:02 -0000 On 5/20/2013 3:18 PM, John E Drake wrote: > I think that's a big mistake(tm). If a new rate or TSG is introduced > the RFC would need to be updated even though the encoding does not > require it. > Well that's easily addressed, via something like: Length (12 bits): indicates the number of bits of the Bit Map field, i.e., the number of TS in the HO ODUk link. The TS granularity, 1.25Gbps or 2.5Gbps, may be derived by dividing the HO ODUk link's rate by the value of the Length field. In the context of [G709-2012], the values of 4 and 16 indicate a TS granularity of 2.5Gps, and the values 2, 8, 32 and 80 indicate a TS granularity of 1.25Gps. Lou > Sent from my iPhone > > On May 20, 2013, at 2:43 PM, "Lou Berger" wrote: > >> John, >> There's still some ambiguity here. How about: >> On 5/20/2013 9:15 AM, John E Drake wrote: >>> Length (12 bits): indicates the number of bits of the Bit Map field, >>> i.e., the number of TS in the HO ODUk link. The TS granularity, >>> 1.25Gbps or 2.5Gbps, may be derived by dividing the HO ODUk link's >>> rate by the value of the Length field. >> >> >> Replace: >>> For example, for an HO ODU2 >>> link, whose link rate is 10Gbps, the value of the Length field will >>> be either 4 or 8 and the TS granularity will be either 2.5Gbps or >>> 1.25Gbps, respectively. >> With: >> >> The values of 4 and 16 indicate a TS granularity of 2.5Gps, while >> the values 2, 8, 32 and 80 indicate a TS granularity of 1.25Gps. >> >> Lou >> >> >>> Irrespectively Yours, >>> >>> John >>> >>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: Friday, May 17, 2013 1:33 PM >>>> To: John E Drake >>>> Cc: Fatai Zhang; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; >>>> CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>> Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 >>>> open issues) >>>> >>>> John, >>>> I guess you haven't been paying attention! The rewrite >>>> originated from Daniele, was tweaked by me and then fixed by Fatai. >>>> >>>> Do you have an alternate proposal to address issue#48? >>>> Issue #48="In signaling document section 6: Clarify related text [i.e., >>>> the OLD text] to unambiguously identify the relationship between label >>>> length and TSG." >>>> >>>> Thanks, >>>> Lou >>>> >>>> On 5/17/2013 1:15 PM, John E Drake wrote: >>>>> Lou, >>>>> >>>>> I think the original text is fine and your attempted re-write >>>> completely mangled its meaning. The label is a bit vector whose length >>>> is equal to the ODUk rate / TSG. >>>>> >>>>> Irrespectively Yours, >>>>> >>>>> John >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>>>>> Behalf Of Lou Berger >>>>>> Sent: Friday, May 17, 2013 9:17 AM >>>>>> To: Fatai Zhang >>>>>> Cc: draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; CCAMP; >>>>>> draft- ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>>>> Subject: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 >>>>>> open issues) >>>>>> >>>>>> Authors/WG, >>>>>> From the mail on the list it seems to me that we've reached >>>> closure >>>>>> on Issue #48: "Document no explicit indication of TSG in the label" >>>>>> (http://trac.tools.ietf.org/wg/ccamp/trac/ticket/48). I'd like to >>>>>> confirm my reading. >>>>>> >>>>>> As I read the list, this issue will be resolved by making the >>>>>> following change to draft-ietf-ccamp-gmpls-signaling-g709v3. >>>>>> >>>>>> OLD >>>>>> Note that the >>>>>> Length field in the label format MAY be used to indicate the TS >>>>>> type of the HO ODUk (i.e., TS granularity at 1.25Gbps or 2.5Gbps) >>>>>> since the HO ODUk type can be known from IF_ID RSVP_HOP Object. In >>>>>> some cases when there is no Link Management Protocol (LMP) or >>>>>> routing to make the two end points of the link to know the TSG, >>>>>> the TSG information used by another end can be deduced from the >>>>>> label format. For example, for HO ODU2 link, the value of the >>>>>> length filed will be 4 or 8, which indicates the TS granularity is >>>>>> 2.5Gbps or 1.25Gbps, respectively. >>>>>> >>>>>> NEW >>>>>> Please note that the TS granularity of an HO ODUk can be inferred >>>>>> from >>>>>> the length of the label. The values of 4 and 16 indicate a TS >>>>>> granularity of 2.5Gps, while the values 2, 8, 32 and 80 indicate a >>>> TS >>>>>> granularity of 1.25Gps. >>>>>> >>>>>> Please speak up if you disagree with this resolution. >>>>>> >>>>>> Thanks, >>>>>> Lou >>>>>> >>>>>> On 5/9/2013 9:41 PM, Fatai Zhang wrote: >>>>>>> For point 1), "1" should be dropped and "7" should be corrected to >>>>>> "8" in your proposed text. >>>>>> >>>>>> _______________________________________________ >>>>>> CCAMP mailing list >>>>>> CCAMP@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ccamp >> > > > > > From jdrake@juniper.net Mon May 20 19:32:55 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D11F121F9738 for ; Mon, 20 May 2013 19:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.467 X-Spam-Level: X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXFbMu4EVkT7 for ; Mon, 20 May 2013 19:32:50 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 0034021F9732 for ; Mon, 20 May 2013 19:32:49 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKUZrc0QJGXYWy8iu/vGI97CyhfyPI/JHE@postini.com; Mon, 20 May 2013 19:32:50 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 20 May 2013 19:31:11 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Mon, 20 May 2013 19:31:10 -0700 Received: from CO9EHSOBE018.bigfish.com (207.46.163.26) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 20 May 2013 19:41:59 -0700 Received: from mail1-co9-R.bigfish.com (10.236.132.250) by CO9EHSOBE018.bigfish.com (10.236.130.81) with Microsoft SMTP Server id 14.1.225.23; Tue, 21 May 2013 02:31:10 +0000 Received: from mail1-co9 (localhost [127.0.0.1]) by mail1-co9-R.bigfish.com (Postfix) with ESMTP id 3E7D54208C5 for ; Tue, 21 May 2013 02:31:10 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT005.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -47 X-BigFish: PS-47(z21aILzbb2dI98dI9371I542I1432I1418I4015Idb82hzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dh8275chz2dh2a8h668h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1155h) Received: from mail1-co9 (localhost.localdomain [127.0.0.1]) by mail1-co9 (MessageSwitch) id 1369103445163171_13888; Tue, 21 May 2013 02:30:45 +0000 (UTC) Received: from CO9EHSMHS025.bigfish.com (unknown [10.236.132.228]) by mail1-co9.bigfish.com (Postfix) with ESMTP id 253A8440710; Tue, 21 May 2013 02:30:45 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS025.bigfish.com (10.236.130.35) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 21 May 2013 02:30:45 +0000 Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.1.63]) by BL2PRD0510HT005.namprd05.prod.outlook.com ([10.255.100.40]) with mapi id 14.16.0311.000; Tue, 21 May 2013 02:30:31 +0000 From: John E Drake To: Lou Berger Thread-Topic: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 open issues) Thread-Index: AQHOUz2x/LI/EygSNE2StyemUF3KopkOC57AgABhqoCAAAntLYAAFyOAgABhf08= Date: Tue, 21 May 2013 02:30:30 +0000 Message-ID: References: <518A82D9.7080508@labn.net> <518BAB17.9090807@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> <519657FE.5030602@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D5009B0@BL2PRD0510MB349.namprd05.prod.outlook.com> <519693DF.6000003@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D504EAD@BL2PRD0510MB349.namprd05.prod.outlook.com>, <519A6EC1.4080205@labn.net> <9574E62A-6A68-4290-A103-8A0A750E2004@juniper.net>, <519A8A7D.5020002@labn.net> In-Reply-To: <519A8A7D.5020002@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [198.228.212.29] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%LABN.NET$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%HUAWEI.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" , "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" , CCAMP Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 open issues) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 02:32:55 -0000 What is behind your preoccupation with enumerating all possible combination= s of length & TSG? Do you have trouble with arithmetic? Sent from my iPhone On May 20, 2013, at 1:42 PM, "Lou Berger" wrote: >=20 >=20 > On 5/20/2013 3:18 PM, John E Drake wrote: >> I think that's a big mistake(tm). If a new rate or TSG is introduced >> the RFC would need to be updated even though the encoding does not >> require it. >=20 > Well that's easily addressed, via something like: >=20 > Length (12 bits): indicates the number of bits of the Bit Map field, > i.e., the number of TS in the HO ODUk link. The TS granularity, > 1.25Gbps or 2.5Gbps, may be derived by dividing the HO ODUk link's rate > by the value of the Length field. In the context of [G709-2012], the > values of 4 and 16 indicate a TS granularity of 2.5Gps, and the values > 2, 8, 32 and 80 indicate a TS granularity of 1.25Gps. >=20 > Lou >=20 >> Sent from my iPhone >>=20 >> On May 20, 2013, at 2:43 PM, "Lou Berger" wrote: >>=20 >>> John, >>> There's still some ambiguity here. How about: >>> On 5/20/2013 9:15 AM, John E Drake wrote: >>>> Length (12 bits): indicates the number of bits of the Bit Map field, >>>> i.e., the number of TS in the HO ODUk link. The TS granularity, >>>> 1.25Gbps or 2.5Gbps, may be derived by dividing the HO ODUk link's >>>> rate by the value of the Length field. =20 >>>=20 >>>=20 >>> Replace: >>>> For example, for an HO ODU2 >>>> link, whose link rate is 10Gbps, the value of the Length field will >>>> be either 4 or 8 and the TS granularity will be either 2.5Gbps or >>>> 1.25Gbps, respectively. >>> With: >>>=20 >>> The values of 4 and 16 indicate a TS granularity of 2.5Gps, while >>> the values 2, 8, 32 and 80 indicate a TS granularity of 1.25Gps. >>>=20 >>> Lou >>>=20 >>>=20 >>>> Irrespectively Yours, >>>>=20 >>>> John >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>> Sent: Friday, May 17, 2013 1:33 PM >>>>> To: John E Drake >>>>> Cc: Fatai Zhang; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; >>>>> CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>>> Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.7= 09 >>>>> open issues) >>>>>=20 >>>>> John, >>>>> I guess you haven't been paying attention! The rewrite >>>>> originated from Daniele, was tweaked by me and then fixed by Fatai. >>>>>=20 >>>>> Do you have an alternate proposal to address issue#48? >>>>> Issue #48=3D"In signaling document section 6: Clarify related text [i= .e., >>>>> the OLD text] to unambiguously identify the relationship between labe= l >>>>> length and TSG." >>>>>=20 >>>>> Thanks, >>>>> Lou >>>>>=20 >>>>> On 5/17/2013 1:15 PM, John E Drake wrote: >>>>>> Lou, >>>>>>=20 >>>>>> I think the original text is fine and your attempted re-write >>>>> completely mangled its meaning. The label is a bit vector whose leng= th >>>>> is equal to the ODUk rate / TSG. >>>>>>=20 >>>>>> Irrespectively Yours, >>>>>>=20 >>>>>> John >>>>>>=20 >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>>>>>> Behalf Of Lou Berger >>>>>>> Sent: Friday, May 17, 2013 9:17 AM >>>>>>> To: Fatai Zhang >>>>>>> Cc: draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; CCAMP; >>>>>>> draft- ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>>>>> Subject: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 >>>>>>> open issues) >>>>>>>=20 >>>>>>> Authors/WG, >>>>>>> From the mail on the list it seems to me that we've reached >>>>> closure >>>>>>> on Issue #48: "Document no explicit indication of TSG in the label" >>>>>>> (http://trac.tools.ietf.org/wg/ccamp/trac/ticket/48). I'd like to >>>>>>> confirm my reading. >>>>>>>=20 >>>>>>> As I read the list, this issue will be resolved by making the >>>>>>> following change to draft-ietf-ccamp-gmpls-signaling-g709v3. >>>>>>>=20 >>>>>>> OLD >>>>>>> Note that the >>>>>>> Length field in the label format MAY be used to indicate the TS >>>>>>> type of the HO ODUk (i.e., TS granularity at 1.25Gbps or 2.5Gbps) >>>>>>> since the HO ODUk type can be known from IF_ID RSVP_HOP Object. In >>>>>>> some cases when there is no Link Management Protocol (LMP) or >>>>>>> routing to make the two end points of the link to know the TSG, >>>>>>> the TSG information used by another end can be deduced from the >>>>>>> label format. For example, for HO ODU2 link, the value of the >>>>>>> length filed will be 4 or 8, which indicates the TS granularity is >>>>>>> 2.5Gbps or 1.25Gbps, respectively. >>>>>>>=20 >>>>>>> NEW >>>>>>> Please note that the TS granularity of an HO ODUk can be inferred >>>>>>> from >>>>>>> the length of the label. The values of 4 and 16 indicate a TS >>>>>>> granularity of 2.5Gps, while the values 2, 8, 32 and 80 indicate a >>>>> TS >>>>>>> granularity of 1.25Gps. >>>>>>>=20 >>>>>>> Please speak up if you disagree with this resolution. >>>>>>>=20 >>>>>>> Thanks, >>>>>>> Lou >>>>>>>=20 >>>>>>> On 5/9/2013 9:41 PM, Fatai Zhang wrote: >>>>>>>> For point 1), "1" should be dropped and "7" should be corrected to >>>>>>> "8" in your proposed text. >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> CCAMP mailing list >>>>>>> CCAMP@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >=20 From lberger@labn.net Tue May 21 05:37:42 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D33EA21F970A for ; Tue, 21 May 2013 05:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.113 X-Spam-Level: X-Spam-Status: No, score=-103.113 tagged_above=-999 required=5 tests=[AWL=0.486, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pa1oIwxpMVEy for ; Tue, 21 May 2013 05:37:37 -0700 (PDT) Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id DB94C21F971C for ; Tue, 21 May 2013 05:37:36 -0700 (PDT) Received: (qmail 19031 invoked by uid 0); 21 May 2013 12:37:11 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy12.bluehost.com with SMTP; 21 May 2013 12:37:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=4f9aRs7pwUq1vRkCk4Hw3CJuTmjFfjQ8ueoMQE9DbAo=; b=KVOYtvm4YxyUNEcdsWywrc9ObnOLCxyTejBm5/Ggm1E+Ek4h+uFt51lhfpnccltNqrMLT92Hta/mFoWIDjBXxwQZc2Km+5g6aT23sn2fQrIC5Jfgu37pwqZtX5xkDfNl; Received: from box313.bluehost.com ([69.89.31.113]:56941 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UeloV-0000jR-IA; Tue, 21 May 2013 06:37:11 -0600 Message-ID: <519B6A75.5040803@labn.net> Date: Tue, 21 May 2013 08:37:09 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: John E Drake References: <518A82D9.7080508@labn.net> <518BAB17.9090807@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> <519657FE.5030602@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D5009B0@BL2PRD0510MB349.namprd05.prod.outlook.com> <519693DF.6000003@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D504EAD@BL2PRD0510MB349.namprd05.prod.outlook.com>, <519A6EC1.4080205@labn.net> <9574E62A-6A68-4290-A103-8A0A750E2004@juniper.net>, <519A8A7D.5020002@labn.net> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" , "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" , CCAMP Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 open issues) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 12:37:42 -0000 John, Really? You're joking right? As I said to Fatai: My feeling is that there have been too many "surprises" on the 709 documents in areas that I thought were ... resolved by past discussions. At this point, as co-chair and Document shepherd, I want to ensure that any open point on the documents are unambiguously closed and that past discussions (i.e., points of consensus) are 100% captured, so that we can smoothly move through the planned second LC and publication request. The particular point of the ambiguity/implicit nature of determining TSG from length has been brought up at least three times. (Note, by others in the WG -- this is not my concern.) Each time the consensus from the discussion is to leave as is, but no or only minimal changes were made to the document. I opened the trac ticket to ensure that the consensus was documented in the draft and that we don't have to yet again revisit this topic -- which *is* my concern. So, the revised text addresses your concern of not needing to redefine the field for new 709 rate or TSGs, and it is sufficiently precise so that non should misinterpret the current "implicit" specification of TSG. Can we/you accept the revised "overly precise" text and move forward? Lou On 5/20/2013 10:30 PM, John E Drake wrote: > What is behind your preoccupation with enumerating all possible combinations of length & TSG? Do you have trouble with arithmetic? > > Sent from my iPhone > > On May 20, 2013, at 1:42 PM, "Lou Berger" wrote: > >> >> >> On 5/20/2013 3:18 PM, John E Drake wrote: >>> I think that's a big mistake(tm). If a new rate or TSG is introduced >>> the RFC would need to be updated even though the encoding does not >>> require it. >> >> Well that's easily addressed, via something like: >> >> Length (12 bits): indicates the number of bits of the Bit Map field, >> i.e., the number of TS in the HO ODUk link. The TS granularity, >> 1.25Gbps or 2.5Gbps, may be derived by dividing the HO ODUk link's rate >> by the value of the Length field. In the context of [G709-2012], the >> values of 4 and 16 indicate a TS granularity of 2.5Gps, and the values >> 2, 8, 32 and 80 indicate a TS granularity of 1.25Gps. >> >> Lou >> >>> Sent from my iPhone >>> >>> On May 20, 2013, at 2:43 PM, "Lou Berger" wrote: >>> >>>> John, >>>> There's still some ambiguity here. How about: >>>> On 5/20/2013 9:15 AM, John E Drake wrote: >>>>> Length (12 bits): indicates the number of bits of the Bit Map field, >>>>> i.e., the number of TS in the HO ODUk link. The TS granularity, >>>>> 1.25Gbps or 2.5Gbps, may be derived by dividing the HO ODUk link's >>>>> rate by the value of the Length field. >>>> >>>> >>>> Replace: >>>>> For example, for an HO ODU2 >>>>> link, whose link rate is 10Gbps, the value of the Length field will >>>>> be either 4 or 8 and the TS granularity will be either 2.5Gbps or >>>>> 1.25Gbps, respectively. >>>> With: >>>> >>>> The values of 4 and 16 indicate a TS granularity of 2.5Gps, while >>>> the values 2, 8, 32 and 80 indicate a TS granularity of 1.25Gps. >>>> >>>> Lou >>>> >>>> >>>>> Irrespectively Yours, >>>>> >>>>> John >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>>> Sent: Friday, May 17, 2013 1:33 PM >>>>>> To: John E Drake >>>>>> Cc: Fatai Zhang; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; >>>>>> CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>>>> Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 >>>>>> open issues) >>>>>> >>>>>> John, >>>>>> I guess you haven't been paying attention! The rewrite >>>>>> originated from Daniele, was tweaked by me and then fixed by Fatai. >>>>>> >>>>>> Do you have an alternate proposal to address issue#48? >>>>>> Issue #48="In signaling document section 6: Clarify related text [i.e., >>>>>> the OLD text] to unambiguously identify the relationship between label >>>>>> length and TSG." >>>>>> >>>>>> Thanks, >>>>>> Lou >>>>>> >>>>>> On 5/17/2013 1:15 PM, John E Drake wrote: >>>>>>> Lou, >>>>>>> >>>>>>> I think the original text is fine and your attempted re-write >>>>>> completely mangled its meaning. The label is a bit vector whose length >>>>>> is equal to the ODUk rate / TSG. >>>>>>> >>>>>>> Irrespectively Yours, >>>>>>> >>>>>>> John >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>>>>>>> Behalf Of Lou Berger >>>>>>>> Sent: Friday, May 17, 2013 9:17 AM >>>>>>>> To: Fatai Zhang >>>>>>>> Cc: draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; CCAMP; >>>>>>>> draft- ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>>>>>> Subject: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 >>>>>>>> open issues) >>>>>>>> >>>>>>>> Authors/WG, >>>>>>>> From the mail on the list it seems to me that we've reached >>>>>> closure >>>>>>>> on Issue #48: "Document no explicit indication of TSG in the label" >>>>>>>> (http://trac.tools.ietf.org/wg/ccamp/trac/ticket/48). I'd like to >>>>>>>> confirm my reading. >>>>>>>> >>>>>>>> As I read the list, this issue will be resolved by making the >>>>>>>> following change to draft-ietf-ccamp-gmpls-signaling-g709v3. >>>>>>>> >>>>>>>> OLD >>>>>>>> Note that the >>>>>>>> Length field in the label format MAY be used to indicate the TS >>>>>>>> type of the HO ODUk (i.e., TS granularity at 1.25Gbps or 2.5Gbps) >>>>>>>> since the HO ODUk type can be known from IF_ID RSVP_HOP Object. In >>>>>>>> some cases when there is no Link Management Protocol (LMP) or >>>>>>>> routing to make the two end points of the link to know the TSG, >>>>>>>> the TSG information used by another end can be deduced from the >>>>>>>> label format. For example, for HO ODU2 link, the value of the >>>>>>>> length filed will be 4 or 8, which indicates the TS granularity is >>>>>>>> 2.5Gbps or 1.25Gbps, respectively. >>>>>>>> >>>>>>>> NEW >>>>>>>> Please note that the TS granularity of an HO ODUk can be inferred >>>>>>>> from >>>>>>>> the length of the label. The values of 4 and 16 indicate a TS >>>>>>>> granularity of 2.5Gps, while the values 2, 8, 32 and 80 indicate a >>>>>> TS >>>>>>>> granularity of 1.25Gps. >>>>>>>> >>>>>>>> Please speak up if you disagree with this resolution. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Lou >>>>>>>> >>>>>>>> On 5/9/2013 9:41 PM, Fatai Zhang wrote: >>>>>>>>> For point 1), "1" should be dropped and "7" should be corrected to >>>>>>>> "8" in your proposed text. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> CCAMP mailing list >>>>>>>> CCAMP@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >> > > > > > From lberger@labn.net Tue May 21 06:17:29 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D92621F977E for ; Tue, 21 May 2013 06:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.473 X-Spam-Level: X-Spam-Status: No, score=-102.473 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVLUhdAM6AGc for ; Tue, 21 May 2013 06:17:21 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 5981821F96BC for ; Tue, 21 May 2013 06:17:21 -0700 (PDT) Received: (qmail 7271 invoked by uid 0); 21 May 2013 13:16:57 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 21 May 2013 13:16:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=/V9jds5dsd785MJf2SH1aG8Kp/ofiV4ikAc2biUuFE0=; b=QqOxEonT5I/VeoOEUTDFkgOcll1qJ3hkfdJp8klami1q+BGdC6pCA0BxQ/c3xEXl2+KYdKBtlJbB9yBbUZOR22iH7wzfD/4DEEXZZq18YzhFJdTURDdB38u76brrRPuv; Received: from box313.bluehost.com ([69.89.31.113]:33167 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UemQz-00045I-6z; Tue, 21 May 2013 07:16:57 -0600 Message-ID: <519B73C9.2030308@labn.net> Date: Tue, 21 May 2013 09:16:57 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: CCAMP References: <518A82D9.7080508@labn.net> <518BAB17.9090807@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> <518CED28.30303@labn.net> <51924382.2010904@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C90D5@ESESSMB301.ericsson.se> <13ea7ed3bdd.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <5193A26A.1090005@labn.net> <519649B4.5060408@labn.net> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" Subject: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 13:17:29 -0000 All, In the interest of moving this discussion quickly to closure, I spent some time trying to come up with the full list of G.709 PT to G-PID mappings. In coming up with this list I tried to be consistent with the last consensus point that I can identify on this topic (the previously referenced July 2012 thread & presentation), which included: A) Defining new G-PIDs for client types not identified by an assigned G-PID (per http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parameters.xml) B) Reusing G-PID wherever {G-PID, ODU rate} unambiguously identify a G.709 payload type, and define new G-PIDs when reuse not possible. C) No G-PID value for unused, reserved, or proprietary 709 Payload Type. Here's what I've come up with: G.709 Payload Type G-PID Type/Comment LSP Encoding ==== ===== ============== =================== 0x01 No standard value 0x02 49 CBRa G.709 ODUk 0x03 50 CBRb G.709 ODUk 0x04 32 ATM G.709 ODUk 0x05 TBA1 Framed GFP G.709 ODUk 0x06 ??? Is any valued needed? 0x07 55 Ethernet PHY G.709 ODUk (k=0) (transparent G.709 ODUk (k=3) GFP) G.709 ODUk (k=4) 0x08 58 Fiber Channel G.709 ODUk (k=2e) 0x09 TBA1 Framed GFP G.709 ODUk (k=2e) 0x0A TBA2 STM-1 G.709 ODUk (k=0) 0x0B TBA3 STM-4 G.709 ODUk (k=0) 0x0C 58 Fiber Channel G.709 ODUk (k=0) 0x0D 58 Fiber Channel G.709 ODUk (k=1) 0x0E 58 Fiber Channel G.709 ODUflex 0x0F 58 Fiber Channel G.709 ODUflex 0x10 51 BSOT G.709 ODUk 0x11 52 BSNT G.709 ODUk 0x12 TBA4 InfiniBand G.709 ODUflex 0x13 TBA4 InfiniBand G.709 ODUflex 0x14 TBA4 InfiniBand G.709 ODUflex 0x15 TBA5 Serial Digital G.709 ODUk (k=0) Interface 0x16 TBA6 Serial Digital G.709 ODUk (k=1) Interface/1.001 0x17 TBA5 Serial Digital G.709 ODUk (k=1) Interface 0x18 TBA6 Serial Digital G.709 ODUflex Interface/1.001 0x19 TBA5 Serial Digital G.709 ODUflex Interface 0x1A 56 SBCON/ESCON G.709 ODUk (k=0) (IANA to update Type field) 0x1B TBA7 DVB_ASI G.709 ODUk (k=0) 0x1C 58 Fiber Channel G.709 ODUk 0x20 47 G.709 ODU-2.5G G.709 ODUk (k=2,3) (IANA to update Type field) TBA8 G.709 ODU-1.25G G.709 ODUk (k=1,2,3) 0x21 TBA8 G.709 ODU-1.25G G.709 ODUk (k=2,3,4) TBA9 G.709 ODU-Any G.709 ODUk (k=2,3) 0x55 No standard value 0x66 No standard value 0x80-0x8F No standard value 0xFD TBA10 Null Test G.709 ODUk 0xFE TBA11 Random Test G.709 ODUk 0xFF No standard value Note that there are a few differences with Fatai's list, which doesn't format well in e-mail, but is available in the archive http://www.ietf.org/mail-archive/web/ccamp/current/msg14845.html Please speak up if you think the above is not aligned with prior consensus or if you have an issue with any of the above. Much thanks, Lou On 5/20/2013 5:09 AM, Fatai Zhang wrote: > Hi Lou, > > > > I think my mail on March 13rd may have answered your following comments. > My response quoted as follows. > > > > In addition, if people look at the full list that I provided, I think > people can realize that RFC4328 (section 3.1.3) used the same approach > as the current approach of this draft (ie., 1:1 mapping between GPIDs > and payload types defined by G.709), ie., we are following what RFC4328 > did. > > > > BTW, I am not sure if we need spend so much on discussing this point > (because there is no issue to stick to the data plane by using the > current approach of this draft). > > > > ====================================================================================================================== > > (2) 'Grouped GPID' vs '1:1' mapping (between G.709-2012 and GPIDs > defined in this draft) > > > > We realize that it is safe to use 1:1 mapping approach to avoid some > potential issues after investigation. We know this payload types have > been defined by G.709 (data plane), so physically it is better to use > 1:1 mapping approach. > > For the potential issues I mentioned above, for example, we cannot use > the existing 34 to represent 'STM-1' and 'STM-4 ', because it is > impossible to differentiate which one is 'STM-1' or 'STM-4'. In > addition, from the concept of payload type, we know that e.g, FC-100 is > different from FC-800, right? So, it is better to assign different GPIDs > to these different payload types defined by the data plane. > > > > Furthermore, I think it is much cheaper to create new GPIDs in the > control plane than in the data plane (these payload types will be > carried in the OH). > > > > > > > > > > Best Regards > > > > Fatai > > > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Friday, May 17, 2013 11:16 PM > To: Fatai Zhang > Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; > draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org > Subject: Re: R: Closing G.709 open issues > > > > Fatai, > > > > That's a great start for the WG. Thank you. > > > > To answer your implied question as to why my request for the full list. > > My feeling is that there have been too many "surprises" on the 709 > > documents in areas that I thought were either obvious (but from the IETF > > & GMPLS context, not ITU-T or G.709 perspectives) or resolved by past > > discussions. At this point, as co-chair and Document shepherd, I want > > to ensure that any open point on the documents are unambiguously closed > > and that past discussions (i.e., points of consensus) are 100% captured, > > so that we can smoothly move through the planned second LC and > > publication request. > > > > To that end, in my previous message I asked two questions about points > > where it seems you are proposing moving away from what has been > > previously been discussed & agreed to by the WG. Can you answer the > > following: > > > >>> My questions on the new G-PIDs come down to: > >>> - Why are rate specific G-PIDs being proposed (rather than > >>> continuing to use the previous approach documented in the draft > >>> and in Section 3.1.3 of rfc4328)? > > > >>> - Why are new values being defined rather than using existing > >>> values, e.g., G-PID 56? > >>> > > > > Much thanks, > > Lou > > > > > From jdrake@juniper.net Tue May 21 13:25:58 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5B211E80DE for ; Tue, 21 May 2013 13:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.467 X-Spam-Level: X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kTyNGkb4-jJ for ; Tue, 21 May 2013 13:25:52 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id B195811E80D2 for ; Tue, 21 May 2013 13:25:52 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUZvYUMsH8nyGSheQ+ASGsmjZyCPcv27A@postini.com; Tue, 21 May 2013 13:25:52 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 21 May 2013 13:23:41 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Tue, 21 May 2013 13:23:41 -0700 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.183) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 21 May 2013 13:27:23 -0700 Received: from mail205-ch1-R.bigfish.com (10.43.68.242) by CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id 14.1.225.23; Tue, 21 May 2013 20:23:40 +0000 Received: from mail205-ch1 (localhost [127.0.0.1]) by mail205-ch1-R.bigfish.com (Postfix) with ESMTP id 7747E60142 for ; Tue, 21 May 2013 20:23:40 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -47 X-BigFish: PS-47(z21aILzbb2dI98dI9371I542I1432I1418I4015Idb82hzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dh8275chz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1155h) Received: from mail205-ch1 (localhost.localdomain [127.0.0.1]) by mail205-ch1 (MessageSwitch) id 136916781930086_14447; Tue, 21 May 2013 20:23:39 +0000 (UTC) Received: from CH1EHSMHS039.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.230]) by mail205-ch1.bigfish.com (Postfix) with ESMTP id 03EE8480098; Tue, 21 May 2013 20:23:39 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS039.bigfish.com (10.43.69.248) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 21 May 2013 20:23:38 +0000 Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.1.63]) by BL2PRD0510HT001.namprd05.prod.outlook.com ([10.255.100.36]) with mapi id 14.16.0311.000; Tue, 21 May 2013 20:23:38 +0000 From: John E Drake To: Lou Berger Thread-Topic: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 open issues) Thread-Index: AQHOUz2x/LI/EygSNE2StyemUF3KopkOC57AgABhqoCAAAntLYAAFyOAgABhf0+AAKl/gIAAgNDw Date: Tue, 21 May 2013 20:23:37 +0000 Message-ID: <0182DEA5604B3A44A2EE61F3EE3ED69E1D508BCA@BL2PRD0510MB349.namprd05.prod.outlook.com> References: <518A82D9.7080508@labn.net> <518BAB17.9090807@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> <519657FE.5030602@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D5009B0@BL2PRD0510MB349.namprd05.prod.outlook.com> <519693DF.6000003@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D504EAD@BL2PRD0510MB349.namprd05.prod.outlook.com>, <519A6EC1.4080205@labn.net> <9574E62A-6A68-4290-A103-8A0A750E2004@juniper.net>, <519A8A7D.5020002@labn.net> <519B6A75.5040803@labn.net> In-Reply-To: <519B6A75.5040803@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.52] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%LABN.NET$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%HUAWEI.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" , "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" , CCAMP Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 open issues) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 20:25:58 -0000 Lou, The question that has always been is whether signaling needed to include an= explicit TSG filed and the answer has always been no because it can be der= ived from other fields. The text I proposed makes that derivation explicit= and unambiguous. The additional text you are proposing adds neither clari= ty nor information. Yours Irrespectively, John > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Tuesday, May 21, 2013 5:37 AM > To: John E Drake > Cc: Fatai Zhang; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; > CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org > Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 > open issues) >=20 > John, >=20 > Really? You're joking right? >=20 > As I said to Fatai: > My feeling is that there have been too many "surprises" on the 709 > documents in areas that I thought were ... resolved by past > discussions. At this point, as co-chair and Document shepherd, I > want to ensure that any open point on the documents are > unambiguously closed and that past discussions (i.e., points of > consensus) are 100% captured, so that we can smoothly move through > the planned second LC and publication request. >=20 > The particular point of the ambiguity/implicit nature of determining > TSG from length has been brought up at least three times. (Note, by > others in the WG -- this is not my concern.) Each time the consensus > from the discussion is to leave as is, but no or only minimal changes > were made to the document. I opened the trac ticket to ensure that the > consensus was documented in the draft and that we don't have to yet > again revisit this topic -- which *is* my concern. >=20 > So, the revised text addresses your concern of not needing to redefine > the field for new 709 rate or TSGs, and it is sufficiently precise so > that non should misinterpret the current "implicit" specification of > TSG. >=20 > Can we/you accept the revised "overly precise" text and move forward? >=20 > Lou >=20 > On 5/20/2013 10:30 PM, John E Drake wrote: > > What is behind your preoccupation with enumerating all possible > combinations of length & TSG? Do you have trouble with arithmetic? > > > > Sent from my iPhone > > > > On May 20, 2013, at 1:42 PM, "Lou Berger" wrote: > > > >> > >> > >> On 5/20/2013 3:18 PM, John E Drake wrote: > >>> I think that's a big mistake(tm). If a new rate or TSG is > >>> introduced the RFC would need to be updated even though the > encoding > >>> does not require it. > >> > >> Well that's easily addressed, via something like: > >> > >> Length (12 bits): indicates the number of bits of the Bit Map field, > >> i.e., the number of TS in the HO ODUk link. The TS granularity, > >> 1.25Gbps or 2.5Gbps, may be derived by dividing the HO ODUk link's > >> rate by the value of the Length field. In the context of > >> [G709-2012], the values of 4 and 16 indicate a TS granularity of > >> 2.5Gps, and the values 2, 8, 32 and 80 indicate a TS granularity of > 1.25Gps. > >> > >> Lou > >> > >>> Sent from my iPhone > >>> > >>> On May 20, 2013, at 2:43 PM, "Lou Berger" wrote: > >>> > >>>> John, > >>>> There's still some ambiguity here. How about: > >>>> On 5/20/2013 9:15 AM, John E Drake wrote: > >>>>> Length (12 bits): indicates the number of bits of the Bit Map > >>>>> field, i.e., the number of TS in the HO ODUk link. The TS > >>>>> granularity, 1.25Gbps or 2.5Gbps, may be derived by dividing the > >>>>> HO ODUk link's rate by the value of the Length field. > >>>> > >>>> > >>>> Replace: > >>>>> For example, for an HO ODU2 > >>>>> link, whose link rate is 10Gbps, the value of the Length field > >>>>> will be either 4 or 8 and the TS granularity will be either > >>>>> 2.5Gbps or 1.25Gbps, respectively. > >>>> With: > >>>> > >>>> The values of 4 and 16 indicate a TS granularity of 2.5Gps, while > >>>> the values 2, 8, 32 and 80 indicate a TS granularity of 1.25Gps. > >>>> > >>>> Lou > >>>> > >>>> > >>>>> Irrespectively Yours, > >>>>> > >>>>> John > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Lou Berger [mailto:lberger@labn.net] > >>>>>> Sent: Friday, May 17, 2013 1:33 PM > >>>>>> To: John E Drake > >>>>>> Cc: Fatai Zhang; > >>>>>> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; > >>>>>> CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org > >>>>>> Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: > Closing > >>>>>> G.709 open issues) > >>>>>> > >>>>>> John, > >>>>>> I guess you haven't been paying attention! The rewrite > >>>>>> originated from Daniele, was tweaked by me and then fixed by > Fatai. > >>>>>> > >>>>>> Do you have an alternate proposal to address issue#48? > >>>>>> Issue #48=3D"In signaling document section 6: Clarify related text > >>>>>> [i.e., the OLD text] to unambiguously identify the relationship > >>>>>> between label length and TSG." > >>>>>> > >>>>>> Thanks, > >>>>>> Lou > >>>>>> > >>>>>> On 5/17/2013 1:15 PM, John E Drake wrote: > >>>>>>> Lou, > >>>>>>> > >>>>>>> I think the original text is fine and your attempted re-write > >>>>>> completely mangled its meaning. The label is a bit vector whose > >>>>>> length is equal to the ODUk rate / TSG. > >>>>>>> > >>>>>>> Irrespectively Yours, > >>>>>>> > >>>>>>> John > >>>>>>> > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] > On > >>>>>>>> Behalf Of Lou Berger > >>>>>>>> Sent: Friday, May 17, 2013 9:17 AM > >>>>>>>> To: Fatai Zhang > >>>>>>>> Cc: draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; > CCAMP; > >>>>>>>> draft- ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org > >>>>>>>> Subject: [CCAMP] Confirming plan for Issue #48: (Was: Closing > >>>>>>>> G.709 open issues) > >>>>>>>> > >>>>>>>> Authors/WG, > >>>>>>>> From the mail on the list it seems to me that we've reached > >>>>>> closure > >>>>>>>> on Issue #48: "Document no explicit indication of TSG in the > label" > >>>>>>>> (http://trac.tools.ietf.org/wg/ccamp/trac/ticket/48). I'd > like > >>>>>>>> to confirm my reading. > >>>>>>>> > >>>>>>>> As I read the list, this issue will be resolved by making the > >>>>>>>> following change to draft-ietf-ccamp-gmpls-signaling-g709v3. > >>>>>>>> > >>>>>>>> OLD > >>>>>>>> Note that the > >>>>>>>> Length field in the label format MAY be used to indicate the > TS > >>>>>>>> type of the HO ODUk (i.e., TS granularity at 1.25Gbps or > >>>>>>>> 2.5Gbps) since the HO ODUk type can be known from IF_ID > >>>>>>>> RSVP_HOP Object. In some cases when there is no Link > Management > >>>>>>>> Protocol (LMP) or routing to make the two end points of the > >>>>>>>> link to know the TSG, the TSG information used by another end > >>>>>>>> can be deduced from the label format. For example, for HO ODU2 > >>>>>>>> link, the value of the length filed will be 4 or 8, which > >>>>>>>> indicates the TS granularity is 2.5Gbps or 1.25Gbps, > respectively. > >>>>>>>> > >>>>>>>> NEW > >>>>>>>> Please note that the TS granularity of an HO ODUk can be > >>>>>>>> inferred from the length of the label. The values of 4 and 16 > >>>>>>>> indicate a TS granularity of 2.5Gps, while the values 2, 8, 32 > >>>>>>>> and 80 indicate a > >>>>>> TS > >>>>>>>> granularity of 1.25Gps. > >>>>>>>> > >>>>>>>> Please speak up if you disagree with this resolution. > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> Lou > >>>>>>>> > >>>>>>>> On 5/9/2013 9:41 PM, Fatai Zhang wrote: > >>>>>>>>> For point 1), "1" should be dropped and "7" should be > >>>>>>>>> corrected to > >>>>>>>> "8" in your proposed text. > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> CCAMP mailing list > >>>>>>>> CCAMP@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp > >> > > > > > > > > > > From lberger@labn.net Tue May 21 17:38:47 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ABDB21F93B1 for ; Tue, 21 May 2013 17:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.462 X-Spam-Level: X-Spam-Status: No, score=-102.462 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKRmj282-4el for ; Tue, 21 May 2013 17:38:43 -0700 (PDT) Received: from oproxy13-pub.unifiedlayer.com (oproxy13-pub.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id 0FBCC21F9371 for ; Tue, 21 May 2013 17:38:43 -0700 (PDT) Received: (qmail 21513 invoked by uid 0); 22 May 2013 00:38:20 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy13.unifiedlayer.com with SMTP; 22 May 2013 00:38:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:CC:To:From; bh=vW6ThWbifN7Pt6pudK/AH9fxjPslRUDHUZsP38cWVYQ=; b=Zol/NeKxvhBZiBaFvRS7caWwqlZCrdrbXcNlMb8Ip4bnihm2WVv0WuqKnGrSnWf8CM3hPh3MmkqwiWCcb23Qptx+3uKHxj5jVFg+ta+HWYnCGnGV+GI/pJngeoZ8gTvv; Received: from box313.bluehost.com ([69.89.31.113]:45048 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Uex4O-0005sy-7T; Tue, 21 May 2013 18:38:20 -0600 From: Lou Berger To: John E Drake Date: Tue, 21 May 2013 20:38:16 -0400 Message-ID: <13ec9ac042d.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <0182DEA5604B3A44A2EE61F3EE3ED69E1D508BCA@BL2PRD0510MB349.namprd05.prod.outlook.com> References: <518A82D9.7080508@labn.net> <518BAB17.9090807@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> <519657FE.5030602@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D5009B0@BL2PRD0510MB349.namprd05.prod.outlook.com> <519693DF.6000003@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D504EAD@BL2PRD0510MB349.namprd05.prod.outlook.com>, <519A6EC1.4080205@labn.net> <9574E62A-6A68-4290-A103-8A0A750E2004@juniper.net>, <519A8A7D.5020002@labn.net> <519B6A75.5040803@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D508BCA@BL2PRD0510MB349.namprd05.prod.outlook.com> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 AquaMail/1.2.4.0 (build: 2100294) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" , "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" , CCAMP Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 open issues) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 00:38:47 -0000 John, Great. It seems we agree that it shouldn't have been necessary to discuss this point so many times, and that the additional text doesn't change the field definition. It is informative narrative after all. Now that said, can you live with the revised "overly precise" text so that we can move forward (and ensure we're not back here again)? Lou On May 21, 2013 4:23:37 PM John E Drake wrote: > Lou, > > The question that has always been is whether signaling needed to include an > explicit TSG filed and the answer has always been no because it can be > derived from other fields. The text I proposed makes that derivation > explicit and unambiguous. The additional text you are proposing adds > neither clarity nor information. > > Yours Irrespectively, > > John > > > -----Original Message----- > > From: Lou Berger [mailto:lberger@labn.net] > > Sent: Tuesday, May 21, 2013 5:37 AM > > To: John E Drake > > Cc: Fatai Zhang; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; > > CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org > > Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 > > open issues) > > John, > > Really? You're joking right? > > As I said to Fatai: > > My feeling is that there have been too many "surprises" on the 709 > > documents in areas that I thought were ... resolved by past > > discussions. At this point, as co-chair and Document shepherd, I > > want to ensure that any open point on the documents are > > unambiguously closed and that past discussions (i.e., points of > > consensus) are 100% captured, so that we can smoothly move through > > the planned second LC and publication request. > > The particular point of the ambiguity/implicit nature of determining > > TSG from length has been brought up at least three times. (Note, by > > others in the WG -- this is not my concern.) Each time the consensus > > from the discussion is to leave as is, but no or only minimal changes > > were made to the document. I opened the trac ticket to ensure that the > > consensus was documented in the draft and that we don't have to yet > > again revisit this topic -- which *is* my concern. > > So, the revised text addresses your concern of not needing to redefine > > the field for new 709 rate or TSGs, and it is sufficiently precise so > > that non should misinterpret the current "implicit" specification of > > TSG. > > Can we/you accept the revised "overly precise" text and move forward? > > Lou > > On 5/20/2013 10:30 PM, John E Drake wrote: > > > What is behind your preoccupation with enumerating all possible > > combinations of length & TSG? Do you have trouble with arithmetic? > > > > > > Sent from my iPhone > > > > > > On May 20, 2013, at 1:42 PM, "Lou Berger" wrote: > > > > > >> > > >> > > >> On 5/20/2013 3:18 PM, John E Drake wrote: > > >>> I think that's a big mistake(tm). If a new rate or TSG is > > >>> introduced the RFC would need to be updated even though the > > encoding > > >>> does not require it. > > >> > > >> Well that's easily addressed, via something like: > > >> > > >> Length (12 bits): indicates the number of bits of the Bit Map field, > > >> i.e., the number of TS in the HO ODUk link. The TS granularity, > > >> 1.25Gbps or 2.5Gbps, may be derived by dividing the HO ODUk link's > > >> rate by the value of the Length field. In the context of > > >> [G709-2012], the values of 4 and 16 indicate a TS granularity of > > >> 2.5Gps, and the values 2, 8, 32 and 80 indicate a TS granularity of > > 1.25Gps. > > >> > > >> Lou > > >> > > >>> Sent from my iPhone > > >>> > > >>> On May 20, 2013, at 2:43 PM, "Lou Berger" wrote: > > >>> > > >>>> John, > > >>>> There's still some ambiguity here. How about: > > >>>> On 5/20/2013 9:15 AM, John E Drake wrote: > > >>>>> Length (12 bits): indicates the number of bits of the Bit Map > > >>>>> field, i.e., the number of TS in the HO ODUk link. The TS > > >>>>> granularity, 1.25Gbps or 2.5Gbps, may be derived by dividing the > > >>>>> HO ODUk link's rate by the value of the Length field. > > >>>> > > >>>> > > >>>> Replace: > > >>>>> For example, for an HO ODU2 > > >>>>> link, whose link rate is 10Gbps, the value of the Length field > > >>>>> will be either 4 or 8 and the TS granularity will be either > > >>>>> 2.5Gbps or 1.25Gbps, respectively. > > >>>> With: > > >>>> > > >>>> The values of 4 and 16 indicate a TS granularity of 2.5Gps, while > > >>>> the values 2, 8, 32 and 80 indicate a TS granularity of 1.25Gps. > > >>>> > > >>>> Lou > > >>>> > > >>>> > > >>>>> Irrespectively Yours, > > >>>>> > > >>>>> John > > >>>>> > > >>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: Lou Berger [mailto:lberger@labn.net] > > >>>>>> Sent: Friday, May 17, 2013 1:33 PM > > >>>>>> To: John E Drake > > >>>>>> Cc: Fatai Zhang; > > >>>>>> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; > > >>>>>> CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org > > >>>>>> Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: > > Closing > > >>>>>> G.709 open issues) > > >>>>>> > > >>>>>> John, > > >>>>>> I guess you haven't been paying attention! The rewrite > > >>>>>> originated from Daniele, was tweaked by me and then fixed by > > Fatai. > > >>>>>> > > >>>>>> Do you have an alternate proposal to address issue#48? > > >>>>>> Issue #48="In signaling document section 6: Clarify related text > > >>>>>> [i.e., the OLD text] to unambiguously identify the relationship > > >>>>>> between label length and TSG." > > >>>>>> > > >>>>>> Thanks, > > >>>>>> Lou > > >>>>>> > > >>>>>> On 5/17/2013 1:15 PM, John E Drake wrote: > > >>>>>>> Lou, > > >>>>>>> > > >>>>>>> I think the original text is fine and your attempted re-write > > >>>>>> completely mangled its meaning. The label is a bit vector whose > > >>>>>> length is equal to the ODUk rate / TSG. > > >>>>>>> > > >>>>>>> Irrespectively Yours, > > >>>>>>> > > >>>>>>> John > > >>>>>>> > > >>>>>>> > > >>>>>>>> -----Original Message----- > > >>>>>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] > > On > > >>>>>>>> Behalf Of Lou Berger > > >>>>>>>> Sent: Friday, May 17, 2013 9:17 AM > > >>>>>>>> To: Fatai Zhang > > >>>>>>>> Cc: draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; > > CCAMP; > > >>>>>>>> draft- ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org > > >>>>>>>> Subject: [CCAMP] Confirming plan for Issue #48: (Was: Closing > > >>>>>>>> G.709 open issues) > > >>>>>>>> > > >>>>>>>> Authors/WG, > > >>>>>>>> From the mail on the list it seems to me that we've reached > > >>>>>> closure > > >>>>>>>> on Issue #48: "Document no explicit indication of TSG in the > > label" > > >>>>>>>> (http://trac.tools.ietf.org/wg/ccamp/trac/ticket/48). I'd > > like > > >>>>>>>> to confirm my reading. > > >>>>>>>> > > >>>>>>>> As I read the list, this issue will be resolved by making the > > >>>>>>>> following change to draft-ietf-ccamp-gmpls-signaling-g709v3. > > >>>>>>>> > > >>>>>>>> OLD > > >>>>>>>> Note that the > > >>>>>>>> Length field in the label format MAY be used to indicate the > > TS > > >>>>>>>> type of the HO ODUk (i.e., TS granularity at 1.25Gbps or > > >>>>>>>> 2.5Gbps) since the HO ODUk type can be known from IF_ID > > >>>>>>>> RSVP_HOP Object. In some cases when there is no Link > > Management > > >>>>>>>> Protocol (LMP) or routing to make the two end points of the > > >>>>>>>> link to know the TSG, the TSG information used by another end > > >>>>>>>> can be deduced from the label format. For example, for HO ODU2 > > >>>>>>>> link, the value of the length filed will be 4 or 8, which > > >>>>>>>> indicates the TS granularity is 2.5Gbps or 1.25Gbps, > > respectively. > > >>>>>>>> > > >>>>>>>> NEW > > >>>>>>>> Please note that the TS granularity of an HO ODUk can be > > >>>>>>>> inferred from the length of the label. The values of 4 and 16 > > >>>>>>>> indicate a TS granularity of 2.5Gps, while the values 2, 8, 32 > > >>>>>>>> and 80 indicate a > > >>>>>> TS > > >>>>>>>> granularity of 1.25Gps. > > >>>>>>>> > > >>>>>>>> Please speak up if you disagree with this resolution. > > >>>>>>>> > > >>>>>>>> Thanks, > > >>>>>>>> Lou > > >>>>>>>> > > >>>>>>>> On 5/9/2013 9:41 PM, Fatai Zhang wrote: > > >>>>>>>>> For point 1), "1" should be dropped and "7" should be > > >>>>>>>>> corrected to > > >>>>>>>> "8" in your proposed text. > > >>>>>>>> > > >>>>>>>> _______________________________________________ > > >>>>>>>> CCAMP mailing list > > >>>>>>>> CCAMP@ietf.org > > >>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp > > >> > > > > > > > > > > > > > > > > > > From jdrake@juniper.net Tue May 21 17:48:32 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5490321F905F for ; Tue, 21 May 2013 17:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.467 X-Spam-Level: X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dC-KjnPs2qLL for ; Tue, 21 May 2013 17:48:26 -0700 (PDT) Received: from exprod7og128.obsmtp.com (exprod7og128.obsmtp.com [64.18.2.121]) by ietfa.amsl.com (Postfix) with ESMTP id 67AF521F92E7 for ; Tue, 21 May 2013 17:48:26 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob128.postini.com ([64.18.6.12]) with SMTP ID DSNKUZwV2XoQPPmCsZtjvRAU5lLGmQsCRKPQ@postini.com; Tue, 21 May 2013 17:48:26 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 21 May 2013 17:45:17 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Tue, 21 May 2013 17:45:17 -0700 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.183) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 21 May 2013 17:48:58 -0700 Received: from mail69-ch1-R.bigfish.com (10.43.68.252) by CH1EHSOBE004.bigfish.com (10.43.70.54) with Microsoft SMTP Server id 14.1.225.23; Wed, 22 May 2013 00:45:16 +0000 Received: from mail69-ch1 (localhost [127.0.0.1]) by mail69-ch1-R.bigfish.com (Postfix) with ESMTP id 5C3C81C024A for ; Wed, 22 May 2013 00:45:16 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -47 X-BigFish: PS-47(z21aILzbb2dI98dI9371I542I1432I1418I4015Idb82hzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dh8275chz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1155h) Received: from mail69-ch1 (localhost.localdomain [127.0.0.1]) by mail69-ch1 (MessageSwitch) id 1369183513875821_30694; Wed, 22 May 2013 00:45:13 +0000 (UTC) Received: from CH1EHSMHS022.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.252]) by mail69-ch1.bigfish.com (Postfix) with ESMTP id D2F3F2E0085; Wed, 22 May 2013 00:45:13 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS022.bigfish.com (10.43.70.22) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 22 May 2013 00:45:13 +0000 Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.1.63]) by BL2PRD0510HT001.namprd05.prod.outlook.com ([10.255.100.36]) with mapi id 14.16.0311.000; Wed, 22 May 2013 00:45:12 +0000 From: John E Drake To: Lou Berger Thread-Topic: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 open issues) Thread-Index: AQHOUz2x/LI/EygSNE2StyemUF3KopkOC57AgABhqoCAAAntLYAAFyOAgABhf0+AAKl/gIAAgNDwgABIqgCAAAF6MA== Date: Wed, 22 May 2013 00:45:12 +0000 Message-ID: <0182DEA5604B3A44A2EE61F3EE3ED69E1D50937C@BL2PRD0510MB349.namprd05.prod.outlook.com> References: <518A82D9.7080508@labn.net> <518BAB17.9090807@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> <519657FE.5030602@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D5009B0@BL2PRD0510MB349.namprd05.prod.outlook.com> <519693DF.6000003@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D504EAD@BL2PRD0510MB349.namprd05.prod.outlook.com>, <519A6EC1.4080205@labn.net> <9574E62A-6A68-4290-A103-8A0A750E2004@juniper.net>, <519A8A7D.5020002@labn.net> <519B6A75.5040803@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D508BCA@BL2PRD0510MB349.namprd05.prod.outlook.com> <13ec9ac042d.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <13ec9ac042d.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.50] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%LABN.NET$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%HUAWEI.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" , "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" , CCAMP Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 open issues) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 00:48:32 -0000 It should be blindingly obvious to the informed reader that in the context = of [G709-2012], the values of 4 and 16 indicate a TS granularity of 2.5Gps,= and the values 2, 8, 32 and 80 indicate a TS granularity of 1.25Gps. Yours Irrespectively, John > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Tuesday, May 21, 2013 5:38 PM > To: John E Drake > Cc: Fatai Zhang; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; > CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org > Subject: RE: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 > open issues) >=20 > John, >=20 > Great. It seems we agree that it shouldn't have been necessary to > discuss this point so many times, and that the additional text doesn't > change the field definition. It is informative narrative after all. >=20 > Now that said, can you live with the revised "overly precise" text so > that we can move forward (and ensure we're not back here again)? >=20 > Lou >=20 > On May 21, 2013 4:23:37 PM John E Drake wrote: > > Lou, > > > > The question that has always been is whether signaling needed to > > include an explicit TSG filed and the answer has always been no > > because it can be derived from other fields. The text I proposed > > makes that derivation explicit and unambiguous. The additional text > > you are proposing adds neither clarity nor information. > > > > Yours Irrespectively, > > > > John > > > > > -----Original Message----- > > > From: Lou Berger [mailto:lberger@labn.net] > > > Sent: Tuesday, May 21, 2013 5:37 AM > > > To: John E Drake > > > Cc: Fatai Zhang; > > > draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; > > > CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org > > > Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing > > > G.709 open issues) John, Really? You're joking right? > > > As I said to Fatai: > > > My feeling is that there have been too many "surprises" on the > 709 > > > documents in areas that I thought were ... resolved by past > > > discussions. At this point, as co-chair and Document shepherd, > I > > > want to ensure that any open point on the documents are > > > unambiguously closed and that past discussions (i.e., points of > > > consensus) are 100% captured, so that we can smoothly move > through > > > the planned second LC and publication request. > > > The particular point of the ambiguity/implicit nature of > determining > > > TSG from length has been brought up at least three times. (Note, > by > > > others in the WG -- this is not my concern.) Each time the > consensus > > > from the discussion is to leave as is, but no or only minimal > > > changes were made to the document. I opened the trac ticket to > > > ensure that the consensus was documented in the draft and that we > > > don't have to yet again revisit this topic -- which *is* my > concern. > > > So, the revised text addresses your concern of not needing to > > > redefine the field for new 709 rate or TSGs, and it is sufficiently > > > precise so that non should misinterpret the current "implicit" > > > specification of TSG. > > > Can we/you accept the revised "overly precise" text and move > forward? > > > Lou > > > On 5/20/2013 10:30 PM, John E Drake wrote: > > > > What is behind your preoccupation with enumerating all possible > > > combinations of length & TSG? Do you have trouble with arithmetic? > > > > > > > > Sent from my iPhone > > > > > > > > On May 20, 2013, at 1:42 PM, "Lou Berger" > wrote: > > > > > > > >> > > > >> > > > >> On 5/20/2013 3:18 PM, John E Drake wrote: > > > >>> I think that's a big mistake(tm). If a new rate or TSG is > > > >>> introduced the RFC would need to be updated even though the > > > encoding > > > >>> does not require it. > > > >> > > > >> Well that's easily addressed, via something like: > > > >> > > > >> Length (12 bits): indicates the number of bits of the Bit Map > > > >> field, i.e., the number of TS in the HO ODUk link. The TS > > > >> granularity, 1.25Gbps or 2.5Gbps, may be derived by dividing the > > > >> HO ODUk link's rate by the value of the Length field. In the > > > >> context of [G709-2012], the values of 4 and 16 indicate a TS > > > >> granularity of 2.5Gps, and the values 2, 8, 32 and 80 indicate a > > > >> TS granularity of > > > 1.25Gps. > > > >> > > > >> Lou > > > >> > > > >>> Sent from my iPhone > > > >>> > > > >>> On May 20, 2013, at 2:43 PM, "Lou Berger" > wrote: > > > >>> > > > >>>> John, > > > >>>> There's still some ambiguity here. How about: > > > >>>> On 5/20/2013 9:15 AM, John E Drake wrote: > > > >>>>> Length (12 bits): indicates the number of bits of the Bit Map > > > >>>>> field, i.e., the number of TS in the HO ODUk link. The TS > > > >>>>> granularity, 1.25Gbps or 2.5Gbps, may be derived by dividing > > > >>>>> the HO ODUk link's rate by the value of the Length field. > > > >>>> > > > >>>> > > > >>>> Replace: > > > >>>>> For example, for an HO ODU2 > > > >>>>> link, whose link rate is 10Gbps, the value of the Length > field > > > >>>>> will be either 4 or 8 and the TS granularity will be either > > > >>>>> 2.5Gbps or 1.25Gbps, respectively. > > > >>>> With: > > > >>>> > > > >>>> The values of 4 and 16 indicate a TS granularity of 2.5Gps, > > > >>>> while the values 2, 8, 32 and 80 indicate a TS granularity of > 1.25Gps. > > > >>>> > > > >>>> Lou > > > >>>> > > > >>>> > > > >>>>> Irrespectively Yours, > > > >>>>> > > > >>>>> John > > > >>>>> > > > >>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: Lou Berger [mailto:lberger@labn.net] > > > >>>>>> Sent: Friday, May 17, 2013 1:33 PM > > > >>>>>> To: John E Drake > > > >>>>>> Cc: Fatai Zhang; > > > >>>>>> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; > > > >>>>>> CCAMP; draft-ietf-ccamp-gmpls-signaling- > g709v3@tools.ietf.org > > > >>>>>> Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: > > > Closing > > > >>>>>> G.709 open issues) > > > >>>>>> > > > >>>>>> John, > > > >>>>>> I guess you haven't been paying attention! The rewrite > > > >>>>>> originated from Daniele, was tweaked by me and then fixed by > > > Fatai. > > > >>>>>> > > > >>>>>> Do you have an alternate proposal to address issue#48? > > > >>>>>> Issue #48=3D"In signaling document section 6: Clarify related > > > >>>>>> text [i.e., the OLD text] to unambiguously identify the > > > >>>>>> relationship between label length and TSG." > > > >>>>>> > > > >>>>>> Thanks, > > > >>>>>> Lou > > > >>>>>> > > > >>>>>> On 5/17/2013 1:15 PM, John E Drake wrote: > > > >>>>>>> Lou, > > > >>>>>>> > > > >>>>>>> I think the original text is fine and your attempted > > > >>>>>>> re-write > > > >>>>>> completely mangled its meaning. The label is a bit vector > > > >>>>>> whose length is equal to the ODUk rate / TSG. > > > >>>>>>> > > > >>>>>>> Irrespectively Yours, > > > >>>>>>> > > > >>>>>>> John > > > >>>>>>> > > > >>>>>>> > > > >>>>>>>> -----Original Message----- > > > >>>>>>>> From: ccamp-bounces@ietf.org > > > >>>>>>>> [mailto:ccamp-bounces@ietf.org] > > > On > > > >>>>>>>> Behalf Of Lou Berger > > > >>>>>>>> Sent: Friday, May 17, 2013 9:17 AM > > > >>>>>>>> To: Fatai Zhang > > > >>>>>>>> Cc: draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; > > > CCAMP; > > > >>>>>>>> draft- ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org > > > >>>>>>>> Subject: [CCAMP] Confirming plan for Issue #48: (Was: > > > >>>>>>>> Closing > > > >>>>>>>> G.709 open issues) > > > >>>>>>>> > > > >>>>>>>> Authors/WG, > > > >>>>>>>> From the mail on the list it seems to me that we've > > > >>>>>>>> reached > > > >>>>>> closure > > > >>>>>>>> on Issue #48: "Document no explicit indication of TSG in > > > >>>>>>>> the > > > label" > > > >>>>>>>> (http://trac.tools.ietf.org/wg/ccamp/trac/ticket/48). I'd > > > like > > > >>>>>>>> to confirm my reading. > > > >>>>>>>> > > > >>>>>>>> As I read the list, this issue will be resolved by making > > > >>>>>>>> the following change to draft-ietf-ccamp-gmpls-signaling- > g709v3. > > > >>>>>>>> > > > >>>>>>>> OLD > > > >>>>>>>> Note that the > > > >>>>>>>> Length field in the label format MAY be used to indicate > > > >>>>>>>> the > > > TS > > > >>>>>>>> type of the HO ODUk (i.e., TS granularity at 1.25Gbps or > > > >>>>>>>> 2.5Gbps) since the HO ODUk type can be known from IF_ID > > > >>>>>>>> RSVP_HOP Object. In some cases when there is no Link > > > Management > > > >>>>>>>> Protocol (LMP) or routing to make the two end points of > the > > > >>>>>>>> link to know the TSG, the TSG information used by another > > > >>>>>>>> end can be deduced from the label format. For example, for > > > >>>>>>>> HO ODU2 link, the value of the length filed will be 4 or > 8, > > > >>>>>>>> which indicates the TS granularity is 2.5Gbps or 1.25Gbps, > > > respectively. > > > >>>>>>>> > > > >>>>>>>> NEW > > > >>>>>>>> Please note that the TS granularity of an HO ODUk can be > > > >>>>>>>> inferred from the length of the label. The values of 4 and > > > >>>>>>>> 16 indicate a TS granularity of 2.5Gps, while the values > 2, > > > >>>>>>>> 8, 32 and 80 indicate a > > > >>>>>> TS > > > >>>>>>>> granularity of 1.25Gps. > > > >>>>>>>> > > > >>>>>>>> Please speak up if you disagree with this resolution. > > > >>>>>>>> > > > >>>>>>>> Thanks, > > > >>>>>>>> Lou > > > >>>>>>>> > > > >>>>>>>> On 5/9/2013 9:41 PM, Fatai Zhang wrote: > > > >>>>>>>>> For point 1), "1" should be dropped and "7" should be > > > >>>>>>>>> corrected to > > > >>>>>>>> "8" in your proposed text. > > > >>>>>>>> > > > >>>>>>>> _______________________________________________ > > > >>>>>>>> CCAMP mailing list > > > >>>>>>>> CCAMP@ietf.org > > > >>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > >=20 >=20 From lberger@labn.net Wed May 22 10:45:23 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E7811E8109 for ; Wed, 22 May 2013 10:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.452 X-Spam-Level: X-Spam-Status: No, score=-102.452 tagged_above=-999 required=5 tests=[AWL=-0.187, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnKrZJhgCOXg for ; Wed, 22 May 2013 10:45:19 -0700 (PDT) Received: from oproxy14-pub.unifiedlayer.com (oproxy14-pub.unifiedlayer.com [67.222.51.224]) by ietfa.amsl.com (Postfix) with SMTP id 6E9A121F905B for ; Wed, 22 May 2013 10:45:18 -0700 (PDT) Received: (qmail 20092 invoked by uid 0); 22 May 2013 17:28:41 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy14.unifiedlayer.com with SMTP; 22 May 2013 17:28:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=hDlk7eqQ1QpAzO6C2cyJxchZnmk8iT2Nn5utcR+9uOw=; b=AZkpPeTj/h4lFknpsPdlbodUm1iie42Z9xwheubaBdJ/B+HHR/p1kqtJ+qBjiM9YlaHyI+iM50XGApVsPnkcQVkkFseEuQeZecZfJSUwIghzO4B5AcSgnJyOadN+Gyd5; Received: from box313.bluehost.com ([69.89.31.113]:33879 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UfCq9-00069I-8j; Wed, 22 May 2013 11:28:41 -0600 Message-ID: <519D0049.80709@labn.net> Date: Wed, 22 May 2013 13:28:41 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: John E Drake References: <518A82D9.7080508@labn.net> <518BAB17.9090807@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> <519657FE.5030602@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D5009B0@BL2PRD0510MB349.namprd05.prod.outlook.com> <519693DF.6000003@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D504EAD@BL2PRD0510MB349.namprd05.prod.outlook.com>, <519A6EC1.4080205@labn.net> <9574E62A-6A68-4290-A103-8A0A750E2004@juniper.net>, <519A8A7D.5020002@labn.net> <519B6A75.5040803@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D508BCA@BL2PRD0510MB349.namprd05.prod.outlook.com> <13ec9ac042d.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D50937C@BL2PRD0510MB349.namprd05.prod.outlook.com> In-Reply-To: <0182DEA5604B3A44A2EE61F3EE3ED69E1D50937C@BL2PRD0510MB349.namprd05.prod.outlook.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 open issues) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 17:45:23 -0000 I'm empathetic with the addition, but suspect it's best not to put the first 10 words in the draft... Lou On 5/21/2013 8:45 PM, John E Drake wrote: > It should be blindingly obvious to the informed reader that in the context of [G709-2012], the values of 4 and 16 indicate a TS granularity of 2.5Gps, and the values 2, 8, 32 and 80 indicate a TS granularity of 1.25Gps. > > Yours Irrespectively, > > John > >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Tuesday, May 21, 2013 5:38 PM >> To: John E Drake >> Cc: Fatai Zhang; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; >> CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >> Subject: RE: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 >> open issues) >> >> John, >> >> Great. It seems we agree that it shouldn't have been necessary to >> discuss this point so many times, and that the additional text doesn't >> change the field definition. It is informative narrative after all. >> >> Now that said, can you live with the revised "overly precise" text so >> that we can move forward (and ensure we're not back here again)? >> >> Lou >> >> On May 21, 2013 4:23:37 PM John E Drake wrote: >>> Lou, >>> >>> The question that has always been is whether signaling needed to >>> include an explicit TSG filed and the answer has always been no >>> because it can be derived from other fields. The text I proposed >>> makes that derivation explicit and unambiguous. The additional text >>> you are proposing adds neither clarity nor information. >>> >>> Yours Irrespectively, >>> >>> John >>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: Tuesday, May 21, 2013 5:37 AM >>>> To: John E Drake >>>> Cc: Fatai Zhang; >>>> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; >>>> CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>> Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing >>>> G.709 open issues) John, Really? You're joking right? >>>> As I said to Fatai: >>>> My feeling is that there have been too many "surprises" on the >> 709 >>>> documents in areas that I thought were ... resolved by past >>>> discussions. At this point, as co-chair and Document shepherd, >> I >>>> want to ensure that any open point on the documents are >>>> unambiguously closed and that past discussions (i.e., points of >>>> consensus) are 100% captured, so that we can smoothly move >> through >>>> the planned second LC and publication request. >>>> The particular point of the ambiguity/implicit nature of >> determining >>>> TSG from length has been brought up at least three times. (Note, >> by >>>> others in the WG -- this is not my concern.) Each time the >> consensus >>>> from the discussion is to leave as is, but no or only minimal >>>> changes were made to the document. I opened the trac ticket to >>>> ensure that the consensus was documented in the draft and that we >>>> don't have to yet again revisit this topic -- which *is* my >> concern. >>>> So, the revised text addresses your concern of not needing to >>>> redefine the field for new 709 rate or TSGs, and it is sufficiently >>>> precise so that non should misinterpret the current "implicit" >>>> specification of TSG. >>>> Can we/you accept the revised "overly precise" text and move >> forward? >>>> Lou >>>> On 5/20/2013 10:30 PM, John E Drake wrote: >>>>> What is behind your preoccupation with enumerating all possible >>>> combinations of length & TSG? Do you have trouble with arithmetic? >>>>> >>>>> Sent from my iPhone >>>>> >>>>> On May 20, 2013, at 1:42 PM, "Lou Berger" >> wrote: >>>>> >>>>>> >>>>>> >>>>>> On 5/20/2013 3:18 PM, John E Drake wrote: >>>>>>> I think that's a big mistake(tm). If a new rate or TSG is >>>>>>> introduced the RFC would need to be updated even though the >>>> encoding >>>>>>> does not require it. >>>>>> >>>>>> Well that's easily addressed, via something like: >>>>>> >>>>>> Length (12 bits): indicates the number of bits of the Bit Map >>>>>> field, i.e., the number of TS in the HO ODUk link. The TS >>>>>> granularity, 1.25Gbps or 2.5Gbps, may be derived by dividing the >>>>>> HO ODUk link's rate by the value of the Length field. In the >>>>>> context of [G709-2012], the values of 4 and 16 indicate a TS >>>>>> granularity of 2.5Gps, and the values 2, 8, 32 and 80 indicate a >>>>>> TS granularity of >>>> 1.25Gps. >>>>>> >>>>>> Lou >>>>>> >>>>>>> Sent from my iPhone >>>>>>> >>>>>>> On May 20, 2013, at 2:43 PM, "Lou Berger" >> wrote: >>>>>>> >>>>>>>> John, >>>>>>>> There's still some ambiguity here. How about: >>>>>>>> On 5/20/2013 9:15 AM, John E Drake wrote: >>>>>>>>> Length (12 bits): indicates the number of bits of the Bit Map >>>>>>>>> field, i.e., the number of TS in the HO ODUk link. The TS >>>>>>>>> granularity, 1.25Gbps or 2.5Gbps, may be derived by dividing >>>>>>>>> the HO ODUk link's rate by the value of the Length field. >>>>>>>> >>>>>>>> >>>>>>>> Replace: >>>>>>>>> For example, for an HO ODU2 >>>>>>>>> link, whose link rate is 10Gbps, the value of the Length >> field >>>>>>>>> will be either 4 or 8 and the TS granularity will be either >>>>>>>>> 2.5Gbps or 1.25Gbps, respectively. >>>>>>>> With: >>>>>>>> >>>>>>>> The values of 4 and 16 indicate a TS granularity of 2.5Gps, >>>>>>>> while the values 2, 8, 32 and 80 indicate a TS granularity of >> 1.25Gps. >>>>>>>> >>>>>>>> Lou >>>>>>>> >>>>>>>> >>>>>>>>> Irrespectively Yours, >>>>>>>>> >>>>>>>>> John >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>>>>>>> Sent: Friday, May 17, 2013 1:33 PM >>>>>>>>>> To: John E Drake >>>>>>>>>> Cc: Fatai Zhang; >>>>>>>>>> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; >>>>>>>>>> CCAMP; draft-ietf-ccamp-gmpls-signaling- >> g709v3@tools.ietf.org >>>>>>>>>> Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: >>>> Closing >>>>>>>>>> G.709 open issues) >>>>>>>>>> >>>>>>>>>> John, >>>>>>>>>> I guess you haven't been paying attention! The rewrite >>>>>>>>>> originated from Daniele, was tweaked by me and then fixed by >>>> Fatai. >>>>>>>>>> >>>>>>>>>> Do you have an alternate proposal to address issue#48? >>>>>>>>>> Issue #48="In signaling document section 6: Clarify related >>>>>>>>>> text [i.e., the OLD text] to unambiguously identify the >>>>>>>>>> relationship between label length and TSG." >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Lou >>>>>>>>>> >>>>>>>>>> On 5/17/2013 1:15 PM, John E Drake wrote: >>>>>>>>>>> Lou, >>>>>>>>>>> >>>>>>>>>>> I think the original text is fine and your attempted >>>>>>>>>>> re-write >>>>>>>>>> completely mangled its meaning. The label is a bit vector >>>>>>>>>> whose length is equal to the ODUk rate / TSG. >>>>>>>>>>> >>>>>>>>>>> Irrespectively Yours, >>>>>>>>>>> >>>>>>>>>>> John >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: ccamp-bounces@ietf.org >>>>>>>>>>>> [mailto:ccamp-bounces@ietf.org] >>>> On >>>>>>>>>>>> Behalf Of Lou Berger >>>>>>>>>>>> Sent: Friday, May 17, 2013 9:17 AM >>>>>>>>>>>> To: Fatai Zhang >>>>>>>>>>>> Cc: draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; >>>> CCAMP; >>>>>>>>>>>> draft- ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>>>>>>>>>> Subject: [CCAMP] Confirming plan for Issue #48: (Was: >>>>>>>>>>>> Closing >>>>>>>>>>>> G.709 open issues) >>>>>>>>>>>> >>>>>>>>>>>> Authors/WG, >>>>>>>>>>>> From the mail on the list it seems to me that we've >>>>>>>>>>>> reached >>>>>>>>>> closure >>>>>>>>>>>> on Issue #48: "Document no explicit indication of TSG in >>>>>>>>>>>> the >>>> label" >>>>>>>>>>>> (http://trac.tools.ietf.org/wg/ccamp/trac/ticket/48). I'd >>>> like >>>>>>>>>>>> to confirm my reading. >>>>>>>>>>>> >>>>>>>>>>>> As I read the list, this issue will be resolved by making >>>>>>>>>>>> the following change to draft-ietf-ccamp-gmpls-signaling- >> g709v3. >>>>>>>>>>>> >>>>>>>>>>>> OLD >>>>>>>>>>>> Note that the >>>>>>>>>>>> Length field in the label format MAY be used to indicate >>>>>>>>>>>> the >>>> TS >>>>>>>>>>>> type of the HO ODUk (i.e., TS granularity at 1.25Gbps or >>>>>>>>>>>> 2.5Gbps) since the HO ODUk type can be known from IF_ID >>>>>>>>>>>> RSVP_HOP Object. In some cases when there is no Link >>>> Management >>>>>>>>>>>> Protocol (LMP) or routing to make the two end points of >> the >>>>>>>>>>>> link to know the TSG, the TSG information used by another >>>>>>>>>>>> end can be deduced from the label format. For example, for >>>>>>>>>>>> HO ODU2 link, the value of the length filed will be 4 or >> 8, >>>>>>>>>>>> which indicates the TS granularity is 2.5Gbps or 1.25Gbps, >>>> respectively. >>>>>>>>>>>> >>>>>>>>>>>> NEW >>>>>>>>>>>> Please note that the TS granularity of an HO ODUk can be >>>>>>>>>>>> inferred from the length of the label. The values of 4 and >>>>>>>>>>>> 16 indicate a TS granularity of 2.5Gps, while the values >> 2, >>>>>>>>>>>> 8, 32 and 80 indicate a >>>>>>>>>> TS >>>>>>>>>>>> granularity of 1.25Gps. >>>>>>>>>>>> >>>>>>>>>>>> Please speak up if you disagree with this resolution. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Lou >>>>>>>>>>>> >>>>>>>>>>>> On 5/9/2013 9:41 PM, Fatai Zhang wrote: >>>>>>>>>>>>> For point 1), "1" should be dropped and "7" should be >>>>>>>>>>>>> corrected to >>>>>>>>>>>> "8" in your proposed text. >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> CCAMP mailing list >>>>>>>>>>>> CCAMP@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>> >>> >>> >> >> > > > > > > From jdrake@juniper.net Wed May 22 11:10:24 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 108D311E810C for ; Wed, 22 May 2013 11:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rd8f2nsGjnaX for ; Wed, 22 May 2013 11:10:18 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id E1B2111E8106 for ; Wed, 22 May 2013 11:10:17 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKUZ0KCTZoBzSuhEujU7iBblKnltfVtLVX@postini.com; Wed, 22 May 2013 11:10:17 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 22 May 2013 11:02:15 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Wed, 22 May 2013 11:02:14 -0700 Received: from tx2outboundpool.messaging.microsoft.com (65.55.88.12) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 22 May 2013 11:13:02 -0700 Received: from mail33-tx2-R.bigfish.com (10.9.14.228) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.23; Wed, 22 May 2013 18:02:13 +0000 Received: from mail33-tx2 (localhost [127.0.0.1]) by mail33-tx2-R.bigfish.com (Postfix) with ESMTP id C68054A009F for ; Wed, 22 May 2013 18:02:13 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT003.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -47 X-BigFish: PS-47(z21aILzbb2dI98dI9371I542I1432I1418I4015Idb82hzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dh8275chz2dh2a8h668h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1155h) Received: from mail33-tx2 (localhost.localdomain [127.0.0.1]) by mail33-tx2 (MessageSwitch) id 1369245666727137_25290; Wed, 22 May 2013 18:01:06 +0000 (UTC) Received: from TX2EHSMHS020.bigfish.com (unknown [10.9.14.248]) by mail33-tx2.bigfish.com (Postfix) with ESMTP id 4B19A2E0296; Wed, 22 May 2013 18:00:52 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS020.bigfish.com (10.9.99.120) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 22 May 2013 18:00:51 +0000 Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.1.63]) by BL2PRD0510HT003.namprd05.prod.outlook.com ([10.255.100.38]) with mapi id 14.16.0311.000; Wed, 22 May 2013 18:00:50 +0000 From: John E Drake To: Lou Berger Thread-Topic: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 open issues) Thread-Index: AQHOUz2x/LI/EygSNE2StyemUF3KopkOC57AgABhqoCAAAntLYAAFyOAgABhf0+AAKl/gIAAgNDwgABIqgCAAAF6MIABGNWAgAAI+80= Date: Wed, 22 May 2013 18:00:49 +0000 Message-ID: <2F3E6A05-D111-4CB2-B2AD-59AE980A2043@juniper.net> References: <518A82D9.7080508@labn.net> <518BAB17.9090807@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> <519657FE.5030602@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D5009B0@BL2PRD0510MB349.namprd05.prod.outlook.com> <519693DF.6000003@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D504EAD@BL2PRD0510MB349.namprd05.prod.outlook.com>, <519A6EC1.4080205@labn.net> <9574E62A-6A68-4290-A103-8A0A750E2004@juniper.net>, <519A8A7D.5020002@labn.net> <519B6A75.5040803@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D508BCA@BL2PRD0510MB349.namprd05.prod.outlook.com> <13ec9ac042d.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D50937C@BL2PRD0510MB349.namprd05.prod.outlook.com>, <519D0049.80709@labn.net> In-Reply-To: <519D0049.80709@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.147.108.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%LABN.NET$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%HUAWEI.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: CCAMP Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 open issues) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 18:10:24 -0000 Bummer Sent from my iPhone On May 22, 2013, at 10:45 AM, "Lou Berger" wrote: > I'm empathetic with the addition, but suspect it's best not to put the > first 10 words in the draft... >=20 > Lou >=20 > On 5/21/2013 8:45 PM, John E Drake wrote: >> It should be blindingly obvious to the informed reader that in the conte= xt of [G709-2012], the values of 4 and 16 indicate a TS granularity of 2.5G= ps, and the values 2, 8, 32 and 80 indicate a TS granularity of 1.25Gps. >>=20 >> Yours Irrespectively, >>=20 >> John >>=20 >>> -----Original Message----- >>> From: Lou Berger [mailto:lberger@labn.net] >>> Sent: Tuesday, May 21, 2013 5:38 PM >>> To: John E Drake >>> Cc: Fatai Zhang; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; >>> CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>> Subject: RE: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 >>> open issues) >>>=20 >>> John, >>>=20 >>> Great. It seems we agree that it shouldn't have been necessary to >>> discuss this point so many times, and that the additional text doesn't >>> change the field definition. It is informative narrative after all. >>>=20 >>> Now that said, can you live with the revised "overly precise" text so >>> that we can move forward (and ensure we're not back here again)? >>>=20 >>> Lou >>>=20 >>> On May 21, 2013 4:23:37 PM John E Drake wrote: >>>> Lou, >>>>=20 >>>> The question that has always been is whether signaling needed to >>>> include an explicit TSG filed and the answer has always been no >>>> because it can be derived from other fields. The text I proposed >>>> makes that derivation explicit and unambiguous. The additional text >>>> you are proposing adds neither clarity nor information. >>>>=20 >>>> Yours Irrespectively, >>>>=20 >>>> John >>>>=20 >>>>> -----Original Message----- >>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>> Sent: Tuesday, May 21, 2013 5:37 AM >>>>> To: John E Drake >>>>> Cc: Fatai Zhang; >>>>> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; >>>>> CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>>> Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing >>>>> G.709 open issues) John, Really? You're joking right? >>>>> As I said to Fatai: >>>>> My feeling is that there have been too many "surprises" on the >>> 709 >>>>> documents in areas that I thought were ... resolved by past >>>>> discussions. At this point, as co-chair and Document shepherd, >>> I >>>>> want to ensure that any open point on the documents are >>>>> unambiguously closed and that past discussions (i.e., points of >>>>> consensus) are 100% captured, so that we can smoothly move >>> through >>>>> the planned second LC and publication request. >>>>> The particular point of the ambiguity/implicit nature of >>> determining >>>>> TSG from length has been brought up at least three times. (Note, >>> by >>>>> others in the WG -- this is not my concern.) Each time the >>> consensus >>>>> from the discussion is to leave as is, but no or only minimal >>>>> changes were made to the document. I opened the trac ticket to >>>>> ensure that the consensus was documented in the draft and that we >>>>> don't have to yet again revisit this topic -- which *is* my >>> concern. >>>>> So, the revised text addresses your concern of not needing to >>>>> redefine the field for new 709 rate or TSGs, and it is sufficiently >>>>> precise so that non should misinterpret the current "implicit" >>>>> specification of TSG. >>>>> Can we/you accept the revised "overly precise" text and move >>> forward? >>>>> Lou >>>>> On 5/20/2013 10:30 PM, John E Drake wrote: >>>>>> What is behind your preoccupation with enumerating all possible >>>>> combinations of length & TSG? Do you have trouble with arithmetic? >>>>>>=20 >>>>>> Sent from my iPhone >>>>>>=20 >>>>>> On May 20, 2013, at 1:42 PM, "Lou Berger" >>> wrote: >>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On 5/20/2013 3:18 PM, John E Drake wrote: >>>>>>>> I think that's a big mistake(tm). If a new rate or TSG is >>>>>>>> introduced the RFC would need to be updated even though the >>>>> encoding >>>>>>>> does not require it. >>>>>>>=20 >>>>>>> Well that's easily addressed, via something like: >>>>>>>=20 >>>>>>> Length (12 bits): indicates the number of bits of the Bit Map >>>>>>> field, i.e., the number of TS in the HO ODUk link. The TS >>>>>>> granularity, 1.25Gbps or 2.5Gbps, may be derived by dividing the >>>>>>> HO ODUk link's rate by the value of the Length field. In the >>>>>>> context of [G709-2012], the values of 4 and 16 indicate a TS >>>>>>> granularity of 2.5Gps, and the values 2, 8, 32 and 80 indicate a >>>>>>> TS granularity of >>>>> 1.25Gps. >>>>>>>=20 >>>>>>> Lou >>>>>>>=20 >>>>>>>> Sent from my iPhone >>>>>>>>=20 >>>>>>>> On May 20, 2013, at 2:43 PM, "Lou Berger" >>> wrote: >>>>>>>>=20 >>>>>>>>> John, >>>>>>>>> There's still some ambiguity here. How about: >>>>>>>>> On 5/20/2013 9:15 AM, John E Drake wrote: >>>>>>>>>> Length (12 bits): indicates the number of bits of the Bit Map >>>>>>>>>> field, i.e., the number of TS in the HO ODUk link. The TS >>>>>>>>>> granularity, 1.25Gbps or 2.5Gbps, may be derived by dividing >>>>>>>>>> the HO ODUk link's rate by the value of the Length field. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Replace: >>>>>>>>>> For example, for an HO ODU2 >>>>>>>>>> link, whose link rate is 10Gbps, the value of the Length >>> field >>>>>>>>>> will be either 4 or 8 and the TS granularity will be either >>>>>>>>>> 2.5Gbps or 1.25Gbps, respectively. >>>>>>>>> With: >>>>>>>>>=20 >>>>>>>>> The values of 4 and 16 indicate a TS granularity of 2.5Gps, >>>>>>>>> while the values 2, 8, 32 and 80 indicate a TS granularity of >>> 1.25Gps. >>>>>>>>>=20 >>>>>>>>> Lou >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> Irrespectively Yours, >>>>>>>>>>=20 >>>>>>>>>> John >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>>>>>>>> Sent: Friday, May 17, 2013 1:33 PM >>>>>>>>>>> To: John E Drake >>>>>>>>>>> Cc: Fatai Zhang; >>>>>>>>>>> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; >>>>>>>>>>> CCAMP; draft-ietf-ccamp-gmpls-signaling- >>> g709v3@tools.ietf.org >>>>>>>>>>> Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: >>>>> Closing >>>>>>>>>>> G.709 open issues) >>>>>>>>>>>=20 >>>>>>>>>>> John, >>>>>>>>>>> I guess you haven't been paying attention! The rewrite >>>>>>>>>>> originated from Daniele, was tweaked by me and then fixed by >>>>> Fatai. >>>>>>>>>>>=20 >>>>>>>>>>> Do you have an alternate proposal to address issue#48? >>>>>>>>>>> Issue #48=3D"In signaling document section 6: Clarify related >>>>>>>>>>> text [i.e., the OLD text] to unambiguously identify the >>>>>>>>>>> relationship between label length and TSG." >>>>>>>>>>>=20 >>>>>>>>>>> Thanks, >>>>>>>>>>> Lou >>>>>>>>>>>=20 >>>>>>>>>>> On 5/17/2013 1:15 PM, John E Drake wrote: >>>>>>>>>>>> Lou, >>>>>>>>>>>>=20 >>>>>>>>>>>> I think the original text is fine and your attempted >>>>>>>>>>>> re-write >>>>>>>>>>> completely mangled its meaning. The label is a bit vector >>>>>>>>>>> whose length is equal to the ODUk rate / TSG. >>>>>>>>>>>>=20 >>>>>>>>>>>> Irrespectively Yours, >>>>>>>>>>>>=20 >>>>>>>>>>>> John >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: ccamp-bounces@ietf.org >>>>>>>>>>>>> [mailto:ccamp-bounces@ietf.org] >>>>> On >>>>>>>>>>>>> Behalf Of Lou Berger >>>>>>>>>>>>> Sent: Friday, May 17, 2013 9:17 AM >>>>>>>>>>>>> To: Fatai Zhang >>>>>>>>>>>>> Cc: draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; >>>>> CCAMP; >>>>>>>>>>>>> draft- ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>>>>>>>>>>> Subject: [CCAMP] Confirming plan for Issue #48: (Was: >>>>>>>>>>>>> Closing >>>>>>>>>>>>> G.709 open issues) >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Authors/WG, >>>>>>>>>>>>> From the mail on the list it seems to me that we've >>>>>>>>>>>>> reached >>>>>>>>>>> closure >>>>>>>>>>>>> on Issue #48: "Document no explicit indication of TSG in >>>>>>>>>>>>> the >>>>> label" >>>>>>>>>>>>> (http://trac.tools.ietf.org/wg/ccamp/trac/ticket/48). I'd >>>>> like >>>>>>>>>>>>> to confirm my reading. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> As I read the list, this issue will be resolved by making >>>>>>>>>>>>> the following change to draft-ietf-ccamp-gmpls-signaling- >>> g709v3. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> OLD >>>>>>>>>>>>> Note that the >>>>>>>>>>>>> Length field in the label format MAY be used to indicate >>>>>>>>>>>>> the >>>>> TS >>>>>>>>>>>>> type of the HO ODUk (i.e., TS granularity at 1.25Gbps or >>>>>>>>>>>>> 2.5Gbps) since the HO ODUk type can be known from IF_ID >>>>>>>>>>>>> RSVP_HOP Object. In some cases when there is no Link >>>>> Management >>>>>>>>>>>>> Protocol (LMP) or routing to make the two end points of >>> the >>>>>>>>>>>>> link to know the TSG, the TSG information used by another >>>>>>>>>>>>> end can be deduced from the label format. For example, for >>>>>>>>>>>>> HO ODU2 link, the value of the length filed will be 4 or >>> 8, >>>>>>>>>>>>> which indicates the TS granularity is 2.5Gbps or 1.25Gbps, >>>>> respectively. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> NEW >>>>>>>>>>>>> Please note that the TS granularity of an HO ODUk can be >>>>>>>>>>>>> inferred from the length of the label. The values of 4 and >>>>>>>>>>>>> 16 indicate a TS granularity of 2.5Gps, while the values >>> 2, >>>>>>>>>>>>> 8, 32 and 80 indicate a >>>>>>>>>>> TS >>>>>>>>>>>>> granularity of 1.25Gps. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Please speak up if you disagree with this resolution. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Lou >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On 5/9/2013 9:41 PM, Fatai Zhang wrote: >>>>>>>>>>>>>> For point 1), "1" should be dropped and "7" should be >>>>>>>>>>>>>> corrected to >>>>>>>>>>>>> "8" in your proposed text. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> CCAMP mailing list >>>>>>>>>>>>> CCAMP@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >=20 From zhangfatai@huawei.com Wed May 22 17:55:23 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE7E11E817A for ; Wed, 22 May 2013 17:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 549BwiaU8cJ8 for ; Wed, 22 May 2013 17:55:18 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 815D511E815B for ; Wed, 22 May 2013 17:55:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARQ36324; Thu, 23 May 2013 00:55:15 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 23 May 2013 01:54:59 +0100 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 23 May 2013 08:55:10 +0800 Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.235]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.007; Thu, 23 May 2013 08:55:04 +0800 From: Fatai Zhang To: John E Drake , Lou Berger Thread-Topic: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 open issues) Thread-Index: AQHOUz2wRZxL9IlXX0COWaVQpGYsjZkNi3gAgABbtICAAAntgIAAFyOAgABhfgCAAKl/gIAAglWAgABHJgCAAAHwAIABGF6AgAAI+4CAAPgZMA== Date: Thu, 23 May 2013 00:55:04 +0000 Message-ID: References: <518A82D9.7080508@labn.net> <518BAB17.9090807@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> <519657FE.5030602@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D5009B0@BL2PRD0510MB349.namprd05.prod.outlook.com> <519693DF.6000003@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D504EAD@BL2PRD0510MB349.namprd05.prod.outlook.com>, <519A6EC1.4080205@labn.net> <9574E62A-6A68-4290-A103-8A0A750E2004@juniper.net>, <519A8A7D.5020002@labn.net> <519B6A75.5040803@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D508BCA@BL2PRD0510MB349.namprd05.prod.outlook.com> <13ec9ac042d.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D50937C@BL2PRD0510MB349.namprd05.prod.outlook.com>, <519D0049.80709@labn.net> <2F3E6A05-D111-4CB2-B2AD-59AE980A2043@juniper.net> In-Reply-To: <2F3E6A05-D111-4CB2-B2AD-59AE980A2043@juniper.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: CCAMP Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 open issues) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 00:55:23 -0000 Hi Lou and John, Thanks for your discussion on providing the proposed text. However, I am lost by the discussion.=20 What is the final proposed text? I hope someone can finalize it. I think it is time to conclude the discussion on this point (the original p= oint 1).=20 Best Regards Fatai -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net]=20 Sent: Thursday, May 23, 2013 2:01 AM To: Lou Berger Cc: Fatai Zhang; CCAMP Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 ope= n issues) Bummer Sent from my iPhone On May 22, 2013, at 10:45 AM, "Lou Berger" wrote: > I'm empathetic with the addition, but suspect it's best not to put the > first 10 words in the draft... >=20 > Lou >=20 > On 5/21/2013 8:45 PM, John E Drake wrote: >> It should be blindingly obvious to the informed reader that in the conte= xt of [G709-2012], the values of 4 and 16 indicate a TS granularity of 2.5G= ps, and the values 2, 8, 32 and 80 indicate a TS granularity of 1.25Gps. >>=20 >> Yours Irrespectively, >>=20 >> John >>=20 >>> -----Original Message----- >>> From: Lou Berger [mailto:lberger@labn.net] >>> Sent: Tuesday, May 21, 2013 5:38 PM >>> To: John E Drake >>> Cc: Fatai Zhang; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; >>> CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>> Subject: RE: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 >>> open issues) >>>=20 >>> John, >>>=20 >>> Great. It seems we agree that it shouldn't have been necessary to >>> discuss this point so many times, and that the additional text doesn't >>> change the field definition. It is informative narrative after all. >>>=20 >>> Now that said, can you live with the revised "overly precise" text so >>> that we can move forward (and ensure we're not back here again)? >>>=20 >>> Lou >>>=20 >>> On May 21, 2013 4:23:37 PM John E Drake wrote: >>>> Lou, >>>>=20 >>>> The question that has always been is whether signaling needed to >>>> include an explicit TSG filed and the answer has always been no >>>> because it can be derived from other fields. The text I proposed >>>> makes that derivation explicit and unambiguous. The additional text >>>> you are proposing adds neither clarity nor information. >>>>=20 >>>> Yours Irrespectively, >>>>=20 >>>> John >>>>=20 >>>>> -----Original Message----- >>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>> Sent: Tuesday, May 21, 2013 5:37 AM >>>>> To: John E Drake >>>>> Cc: Fatai Zhang; >>>>> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; >>>>> CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>>> Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing >>>>> G.709 open issues) John, Really? You're joking right? >>>>> As I said to Fatai: >>>>> My feeling is that there have been too many "surprises" on the >>> 709 >>>>> documents in areas that I thought were ... resolved by past >>>>> discussions. At this point, as co-chair and Document shepherd, >>> I >>>>> want to ensure that any open point on the documents are >>>>> unambiguously closed and that past discussions (i.e., points of >>>>> consensus) are 100% captured, so that we can smoothly move >>> through >>>>> the planned second LC and publication request. >>>>> The particular point of the ambiguity/implicit nature of >>> determining >>>>> TSG from length has been brought up at least three times. (Note, >>> by >>>>> others in the WG -- this is not my concern.) Each time the >>> consensus >>>>> from the discussion is to leave as is, but no or only minimal >>>>> changes were made to the document. I opened the trac ticket to >>>>> ensure that the consensus was documented in the draft and that we >>>>> don't have to yet again revisit this topic -- which *is* my >>> concern. >>>>> So, the revised text addresses your concern of not needing to >>>>> redefine the field for new 709 rate or TSGs, and it is sufficiently >>>>> precise so that non should misinterpret the current "implicit" >>>>> specification of TSG. >>>>> Can we/you accept the revised "overly precise" text and move >>> forward? >>>>> Lou >>>>> On 5/20/2013 10:30 PM, John E Drake wrote: >>>>>> What is behind your preoccupation with enumerating all possible >>>>> combinations of length & TSG? Do you have trouble with arithmetic? >>>>>>=20 >>>>>> Sent from my iPhone >>>>>>=20 >>>>>> On May 20, 2013, at 1:42 PM, "Lou Berger" >>> wrote: >>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On 5/20/2013 3:18 PM, John E Drake wrote: >>>>>>>> I think that's a big mistake(tm). If a new rate or TSG is >>>>>>>> introduced the RFC would need to be updated even though the >>>>> encoding >>>>>>>> does not require it. >>>>>>>=20 >>>>>>> Well that's easily addressed, via something like: >>>>>>>=20 >>>>>>> Length (12 bits): indicates the number of bits of the Bit Map >>>>>>> field, i.e., the number of TS in the HO ODUk link. The TS >>>>>>> granularity, 1.25Gbps or 2.5Gbps, may be derived by dividing the >>>>>>> HO ODUk link's rate by the value of the Length field. In the >>>>>>> context of [G709-2012], the values of 4 and 16 indicate a TS >>>>>>> granularity of 2.5Gps, and the values 2, 8, 32 and 80 indicate a >>>>>>> TS granularity of >>>>> 1.25Gps. >>>>>>>=20 >>>>>>> Lou >>>>>>>=20 >>>>>>>> Sent from my iPhone >>>>>>>>=20 >>>>>>>> On May 20, 2013, at 2:43 PM, "Lou Berger" >>> wrote: >>>>>>>>=20 >>>>>>>>> John, >>>>>>>>> There's still some ambiguity here. How about: >>>>>>>>> On 5/20/2013 9:15 AM, John E Drake wrote: >>>>>>>>>> Length (12 bits): indicates the number of bits of the Bit Map >>>>>>>>>> field, i.e., the number of TS in the HO ODUk link. The TS >>>>>>>>>> granularity, 1.25Gbps or 2.5Gbps, may be derived by dividing >>>>>>>>>> the HO ODUk link's rate by the value of the Length field. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Replace: >>>>>>>>>> For example, for an HO ODU2 >>>>>>>>>> link, whose link rate is 10Gbps, the value of the Length >>> field >>>>>>>>>> will be either 4 or 8 and the TS granularity will be either >>>>>>>>>> 2.5Gbps or 1.25Gbps, respectively. >>>>>>>>> With: >>>>>>>>>=20 >>>>>>>>> The values of 4 and 16 indicate a TS granularity of 2.5Gps, >>>>>>>>> while the values 2, 8, 32 and 80 indicate a TS granularity of >>> 1.25Gps. >>>>>>>>>=20 >>>>>>>>> Lou >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> Irrespectively Yours, >>>>>>>>>>=20 >>>>>>>>>> John >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>>>>>>>> Sent: Friday, May 17, 2013 1:33 PM >>>>>>>>>>> To: John E Drake >>>>>>>>>>> Cc: Fatai Zhang; >>>>>>>>>>> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; >>>>>>>>>>> CCAMP; draft-ietf-ccamp-gmpls-signaling- >>> g709v3@tools.ietf.org >>>>>>>>>>> Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: >>>>> Closing >>>>>>>>>>> G.709 open issues) >>>>>>>>>>>=20 >>>>>>>>>>> John, >>>>>>>>>>> I guess you haven't been paying attention! The rewrite >>>>>>>>>>> originated from Daniele, was tweaked by me and then fixed by >>>>> Fatai. >>>>>>>>>>>=20 >>>>>>>>>>> Do you have an alternate proposal to address issue#48? >>>>>>>>>>> Issue #48=3D"In signaling document section 6: Clarify related >>>>>>>>>>> text [i.e., the OLD text] to unambiguously identify the >>>>>>>>>>> relationship between label length and TSG." >>>>>>>>>>>=20 >>>>>>>>>>> Thanks, >>>>>>>>>>> Lou >>>>>>>>>>>=20 >>>>>>>>>>> On 5/17/2013 1:15 PM, John E Drake wrote: >>>>>>>>>>>> Lou, >>>>>>>>>>>>=20 >>>>>>>>>>>> I think the original text is fine and your attempted >>>>>>>>>>>> re-write >>>>>>>>>>> completely mangled its meaning. The label is a bit vector >>>>>>>>>>> whose length is equal to the ODUk rate / TSG. >>>>>>>>>>>>=20 >>>>>>>>>>>> Irrespectively Yours, >>>>>>>>>>>>=20 >>>>>>>>>>>> John >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: ccamp-bounces@ietf.org >>>>>>>>>>>>> [mailto:ccamp-bounces@ietf.org] >>>>> On >>>>>>>>>>>>> Behalf Of Lou Berger >>>>>>>>>>>>> Sent: Friday, May 17, 2013 9:17 AM >>>>>>>>>>>>> To: Fatai Zhang >>>>>>>>>>>>> Cc: draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; >>>>> CCAMP; >>>>>>>>>>>>> draft- ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>>>>>>>>>>> Subject: [CCAMP] Confirming plan for Issue #48: (Was: >>>>>>>>>>>>> Closing >>>>>>>>>>>>> G.709 open issues) >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Authors/WG, >>>>>>>>>>>>> From the mail on the list it seems to me that we've >>>>>>>>>>>>> reached >>>>>>>>>>> closure >>>>>>>>>>>>> on Issue #48: "Document no explicit indication of TSG in >>>>>>>>>>>>> the >>>>> label" >>>>>>>>>>>>> (http://trac.tools.ietf.org/wg/ccamp/trac/ticket/48). I'd >>>>> like >>>>>>>>>>>>> to confirm my reading. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> As I read the list, this issue will be resolved by making >>>>>>>>>>>>> the following change to draft-ietf-ccamp-gmpls-signaling- >>> g709v3. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> OLD >>>>>>>>>>>>> Note that the >>>>>>>>>>>>> Length field in the label format MAY be used to indicate >>>>>>>>>>>>> the >>>>> TS >>>>>>>>>>>>> type of the HO ODUk (i.e., TS granularity at 1.25Gbps or >>>>>>>>>>>>> 2.5Gbps) since the HO ODUk type can be known from IF_ID >>>>>>>>>>>>> RSVP_HOP Object. In some cases when there is no Link >>>>> Management >>>>>>>>>>>>> Protocol (LMP) or routing to make the two end points of >>> the >>>>>>>>>>>>> link to know the TSG, the TSG information used by another >>>>>>>>>>>>> end can be deduced from the label format. For example, for >>>>>>>>>>>>> HO ODU2 link, the value of the length filed will be 4 or >>> 8, >>>>>>>>>>>>> which indicates the TS granularity is 2.5Gbps or 1.25Gbps, >>>>> respectively. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> NEW >>>>>>>>>>>>> Please note that the TS granularity of an HO ODUk can be >>>>>>>>>>>>> inferred from the length of the label. The values of 4 and >>>>>>>>>>>>> 16 indicate a TS granularity of 2.5Gps, while the values >>> 2, >>>>>>>>>>>>> 8, 32 and 80 indicate a >>>>>>>>>>> TS >>>>>>>>>>>>> granularity of 1.25Gps. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Please speak up if you disagree with this resolution. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Lou >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On 5/9/2013 9:41 PM, Fatai Zhang wrote: >>>>>>>>>>>>>> For point 1), "1" should be dropped and "7" should be >>>>>>>>>>>>>> corrected to >>>>>>>>>>>>> "8" in your proposed text. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> CCAMP mailing list >>>>>>>>>>>>> CCAMP@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >=20 From zhangfatai@huawei.com Wed May 22 18:14:14 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB8DA11E817A for ; Wed, 22 May 2013 18:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.548 X-Spam-Level: X-Spam-Status: No, score=-6.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnA9ow3CN-Ih for ; Wed, 22 May 2013 18:14:09 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 36AAE11E815B for ; Wed, 22 May 2013 18:14:08 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARQ37132; Thu, 23 May 2013 01:14:07 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 23 May 2013 02:13:55 +0100 Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 23 May 2013 09:14:06 +0800 Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.235]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.01.0323.007; Thu, 23 May 2013 09:13:41 +0800 From: Fatai Zhang To: Fatai Zhang , Lou Berger Thread-Topic: R: Closing G.709 open issues Thread-Index: AQHOTAyDmhSnK0jr+ESubR/xu8VPgpj8bQiw///u0ICAADKIAIAABpSAgAEN6tCAADjpAIAEmsGw///G7YCAAffecIAAA0UAgAEzTICAADLXgIAACRmAgAAzFQCAAzHYYP//9+4AAJok6dAAhqlDUA== Date: Thu, 23 May 2013 01:13:40 +0000 Message-ID: References: <518A82D9.7080508@labn.net> <518BAB17.9090807@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> <518CED28.30303@labn.net> <51924382.2010904@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C90D5@ESESSMB301.ericsson.se> <13ea7ed3bdd.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <5193A26A.1090005@labn.net> <519649B4.5060408@labn.net> 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.66.72.159] Content-Type: multipart/alternative; boundary="_000_F82A4B6D50F9464B8EBA55651F541CF84319B76ESZXEML552MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" Subject: Re: [CCAMP] R: Closing G.709 open issues X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 01:14:14 -0000 --_000_F82A4B6D50F9464B8EBA55651F541CF84319B76ESZXEML552MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Lou and all, I would like to double check again on the original point 2. I would assume the WG is happy with the proposed approach and then conclude= the discussion on point 2 if there is no more comment until this Friday. Note that I think more people have shown their support on the proposed appr= oach. Best Regards Fatai From: Fatai Zhang [mailto:zhangfatai@huawei.com] Sent: Monday, May 20, 2013 5:09 PM To: Lou Berger Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; draft-ietf-ccamp-g= mpls-signaling-g709v3@tools.ietf.org Subject: RE: R: Closing G.709 open issues Hi Lou, I think my mail on May 13rd may have answered your following comments. My r= esponse quoted as follows. In addition, if people look at the full list that I provided, I think peopl= e can realize that RFC4328 (section 3.1.3) used the same approach as the pr= oposed approach (ie., 1:1 mapping between GPIDs and payload types defined b= y G.709), ie., we are following what RFC4328 did. BTW, I am not sure if we need spend so much time on discussing this point (= because there is no issue to stick to the data plane by using the proposed = approach). =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D (2) 'Grouped GPID' vs '1:1' mapping (between G.709-2012 and GPIDs defined i= n this draft) We realize that it is safe to use 1:1 mapping approach to avoid some potent= ial issues after investigation. We know this payload types have been define= d by G.709 (data plane), so physically it is better to use 1:1 mapping appr= oach. For the potential issues I mentioned above, for example, we cannot use the = existing 34 to represent 'STM-1' and 'STM-4 ', because it is impossible to = differentiate which one is 'STM-1' or 'STM-4'. In addition, from the concep= t of payload type, we know that e.g, FC-100 is different from FC-800, right= ? So, it is better to assign different GPIDs to these different payload typ= es defined by the data plane. Furthermore, I think it is much cheaper to create new GPIDs in the control = plane than in the data plane (these payload types will be carried in the OH= ). Best Regards Fatai -----Original Message----- From: Lou Berger [mailto:lberger@labn.net] Sent: Friday, May 17, 2013 11:16 PM To: Fatai Zhang Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; draft-ietf-ccamp-g= mpls-signaling-g709v3@tools.ietf.org Subject: Re: R: Closing G.709 open issues Fatai, That's a great start for the WG. Thank you. To answer your implied question as to why my request for the full list. My feeling is that there have been too many "surprises" on the 709 documents in areas that I thought were either obvious (but from the IETF & GMPLS context, not ITU-T or G.709 perspectives) or resolved by past discussions. At this point, as co-chair and Document shepherd, I want to ensure that any open point on the documents are unambiguously closed and that past discussions (i.e., points of consensus) are 100% captured, so that we can smoothly move through the planned second LC and publication request. To that end, in my previous message I asked two questions about points where it seems you are proposing moving away from what has been previously been discussed & agreed to by the WG. Can you answer the following: >> My questions on the new G-PIDs come down to: >> - Why are rate specific G-PIDs being proposed (rather than >> continuing to use the previous approach documented in the draft >> and in Section 3.1.3 of rfc4328)? >> - Why are new values being defined rather than using existing >> values, e.g., G-PID 56? >> Much thanks, Lou --_000_F82A4B6D50F9464B8EBA55651F541CF84319B76ESZXEML552MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Lou = and all,

&n= bsp;

I would= like to double check again on the original point 2.

&n= bsp;

I wo= uld assume the WG is happy with the proposed approach and then conclude the= discussion on point 2 if there is no more comment until this Friday.

&n= bsp;

Note th= at I think more people have shown their support on the proposed approach.

&n= bsp;

&n= bsp;

Best Re= gards

&n= bsp;

Fatai

&n= bsp;

From: Fatai Zhang = [mailto:zhangfatai@huawei.com]
Sent: Monday, May 20, 2013 5:09 PM
To: Lou Berger
Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; draft-ietf-= ccamp-gmpls-signaling-g709v3@tools.ietf.org
Subject: RE: R: Closing G.709 open issues

 

Hi L= ou,

 

I th= ink my mail on May 13rd may have answered your= following comments. My response quoted as follows.

 

In a= ddition, if people look at the full list that I provided, I think people ca= n realize that RFC4328 (section 3.1.3) used the same approach as the proposed approach (ie., 1:1 mapping between GP= IDs and payload types defined by G.709), ie., we are following what RFC4328= did.

 

BTW,= I am not sure if we need spend so much time on discussing this point (because there = is no issue to stick to the data plane by using the proposed approach).

 

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

(2) 'Grouped GPID' vs '1:1' = mapping (between G.709-2012 and GPIDs defined in this draft)

 

We realize that it is safe t= o use 1:1 mapping approach to avoid some potential issues after investigati= on. We know this payload types have been defined by G.709 (data plane), so = physically it is better to use 1:1 mapping approach.

For the potential issues I m= entioned above, for example, we cannot use the existing 34 to represent 'ST= M-1' and 'STM-4 ', because it is impossible to differentiate which one is '= STM-1' or 'STM-4'. In addition, from the concept of payload type, we know that e.g, FC-100 is different from FC= -800, right? So, it is better to assign different GPIDs to these different = payload types defined by the data plane.

 

Furthermore, I think it is m= uch cheaper to create new GPIDs in the control plane than in the data plane= (these payload types will be carried in the OH).

 

 

 

 

Best= Regards

 

Fata= i

 

-----Original Message----- From: Lou Berger [mailto:lberger@labn.net]
Sent: Friday, May 17, 2013 11:16 PM
To: Fatai Zhang
Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; draft-ietf-ccamp-g= mpls-signaling-g709v3@tools.ietf.org
Subject: Re: R: Closing G.709 open issues

 

Fatai,

    &nbs= p;   

That's a great start for the= WG.  Thank you.

 

To answer your implied quest= ion as to why my request for the full list.

My feeling is that there hav= e been too many "surprises" on the 709

documents in areas that I th= ought were either obvious (but from the IETF

& GMPLS context, not ITU= -T or G.709 perspectives) or resolved by past

discussions.  At this p= oint, as co-chair and Document shepherd, I want

to ensure that any open poin= t on the documents are unambiguously closed

and that past discussions (i= .e., points of consensus) are 100% captured,

so that we can smoothly move= through the planned second LC and

publication request.

 

To that end, in my previous = message I asked two questions about points

where it seems you are propo= sing moving away from what has been

previously been discussed &a= mp; agreed to by the WG.  Can you answer the

following:=

 

>> My questions on the= new G-PIDs come down to:

>> - Why are rate spec= ific G-PIDs being proposed (rather than

>>   continu= ing to use the previous approach documented in the draft<= /p>

>>   and in = Section 3.1.3 of rfc4328)?

 

>> - Why are new value= s being defined rather than using existing

>>   values,= e.g., G-PID 56?

>> 

 

Much thanks,

Lou

 

&= nbsp;

--_000_F82A4B6D50F9464B8EBA55651F541CF84319B76ESZXEML552MBXchi_-- From lberger@labn.net Wed May 22 18:28:02 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8BF611E8182 for ; Wed, 22 May 2013 18:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.443 X-Spam-Level: X-Spam-Status: No, score=-102.443 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKcr-UUIermQ for ; Wed, 22 May 2013 18:27:58 -0700 (PDT) Received: from oproxy14-pub.unifiedlayer.com (oproxy14-pub.unifiedlayer.com [67.222.51.224]) by ietfa.amsl.com (Postfix) with SMTP id 55B7A11E8181 for ; Wed, 22 May 2013 18:27:58 -0700 (PDT) Received: (qmail 389 invoked by uid 0); 23 May 2013 01:27:55 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy14.unifiedlayer.com with SMTP; 23 May 2013 01:27:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=OjwO5ssjQ+faWgkwcOOfD690vy6blFOIIQaCDjRSr94=; b=Bi1U15ae9Asse4CAJicxDij4pbOIgDv4rRxSNDqlL0IMf3knAt+s9TuD+LpbA/QzF8I4vMn0nOXH8ZiVTeZOKJrr9vMrukepL5efyWUTZtYVkH8CQXOLRAPjRTqSvbl7; Received: from box313.bluehost.com ([69.89.31.113]:50484 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UfKJu-0002JR-LG; Wed, 22 May 2013 19:27:54 -0600 Message-ID: <519D709A.5020609@labn.net> Date: Wed, 22 May 2013 21:27:54 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Fatai Zhang References: <518A82D9.7080508@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> <519657FE.5030602@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D5009B0@BL2PRD0510MB349.namprd05.prod.outlook.com> <519693DF.6000003@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D504EAD@BL2PRD0510MB349.namprd05.prod.outlook.com>, <519A6EC1.4080205@labn.net> <9574E62A-6A68-4290-A103-8A0A750E2004@juniper.net>, <519A8A7D.5020002@labn.net> <519B6A75.5040803@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D508BCA@BL2PRD0510MB349.namprd05.prod.outlook.com> <13ec9ac042d.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D50937C@BL2PRD0510MB349.namprd05.prod.outlook.com>, <519D0049.80709@labn.net> <2F3E6A05-D111-4CB2-B2AD-59AE980A2043@juniper.net> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 open issues) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 01:28:03 -0000 drop the OLD text (identified in the trac issue) & replace Length field definition with: >> Length (12 bits): indicates the number of bits of the Bit Map >> field, i.e., the number of TS in the HO ODUk link. The TS >> granularity, 1.25Gbps or 2.5Gbps, may be derived by dividing the >> HO ODUk link's rate by the value of the Length field. In the >> context of [G709-2012], the values of 4 and 16 indicate a TS >> granularity of 2.5Gps, and the values 2, 8, 32 and 80 indicate a >> TS granularity of 1.25Gps. Lou On 5/22/2013 8:55 PM, Fatai Zhang wrote: > Hi Lou and John, > > Thanks for your discussion on providing the proposed text. > > However, I am lost by the discussion. > > What is the final proposed text? I hope someone can finalize it. > > I think it is time to conclude the discussion on this point (the original point 1). > > > > Best Regards > > Fatai > > > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Thursday, May 23, 2013 2:01 AM > To: Lou Berger > Cc: Fatai Zhang; CCAMP > Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 open issues) > > Bummer > > Sent from my iPhone > > On May 22, 2013, at 10:45 AM, "Lou Berger" wrote: > >> I'm empathetic with the addition, but suspect it's best not to put the >> first 10 words in the draft... >> >> Lou >> >> On 5/21/2013 8:45 PM, John E Drake wrote: >>> It should be blindingly obvious to the informed reader that in the context of [G709-2012], the values of 4 and 16 indicate a TS granularity of 2.5Gps, and the values 2, 8, 32 and 80 indicate a TS granularity of 1.25Gps. >>> >>> Yours Irrespectively, >>> >>> John >>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: Tuesday, May 21, 2013 5:38 PM >>>> To: John E Drake >>>> Cc: Fatai Zhang; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; >>>> CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>> Subject: RE: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 >>>> open issues) >>>> >>>> John, >>>> >>>> Great. It seems we agree that it shouldn't have been necessary to >>>> discuss this point so many times, and that the additional text doesn't >>>> change the field definition. It is informative narrative after all. >>>> >>>> Now that said, can you live with the revised "overly precise" text so >>>> that we can move forward (and ensure we're not back here again)? >>>> >>>> Lou >>>> >>>> On May 21, 2013 4:23:37 PM John E Drake wrote: >>>>> Lou, >>>>> >>>>> The question that has always been is whether signaling needed to >>>>> include an explicit TSG filed and the answer has always been no >>>>> because it can be derived from other fields. The text I proposed >>>>> makes that derivation explicit and unambiguous. The additional text >>>>> you are proposing adds neither clarity nor information. >>>>> >>>>> Yours Irrespectively, >>>>> >>>>> John >>>>> >>>>>> -----Original Message----- >>>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>>> Sent: Tuesday, May 21, 2013 5:37 AM >>>>>> To: John E Drake >>>>>> Cc: Fatai Zhang; >>>>>> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; >>>>>> CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>>>> Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing >>>>>> G.709 open issues) John, Really? You're joking right? >>>>>> As I said to Fatai: >>>>>> My feeling is that there have been too many "surprises" on the >>>> 709 >>>>>> documents in areas that I thought were ... resolved by past >>>>>> discussions. At this point, as co-chair and Document shepherd, >>>> I >>>>>> want to ensure that any open point on the documents are >>>>>> unambiguously closed and that past discussions (i.e., points of >>>>>> consensus) are 100% captured, so that we can smoothly move >>>> through >>>>>> the planned second LC and publication request. >>>>>> The particular point of the ambiguity/implicit nature of >>>> determining >>>>>> TSG from length has been brought up at least three times. (Note, >>>> by >>>>>> others in the WG -- this is not my concern.) Each time the >>>> consensus >>>>>> from the discussion is to leave as is, but no or only minimal >>>>>> changes were made to the document. I opened the trac ticket to >>>>>> ensure that the consensus was documented in the draft and that we >>>>>> don't have to yet again revisit this topic -- which *is* my >>>> concern. >>>>>> So, the revised text addresses your concern of not needing to >>>>>> redefine the field for new 709 rate or TSGs, and it is sufficiently >>>>>> precise so that non should misinterpret the current "implicit" >>>>>> specification of TSG. >>>>>> Can we/you accept the revised "overly precise" text and move >>>> forward? >>>>>> Lou >>>>>> On 5/20/2013 10:30 PM, John E Drake wrote: >>>>>>> What is behind your preoccupation with enumerating all possible >>>>>> combinations of length & TSG? Do you have trouble with arithmetic? >>>>>>> >>>>>>> Sent from my iPhone >>>>>>> >>>>>>> On May 20, 2013, at 1:42 PM, "Lou Berger" >>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 5/20/2013 3:18 PM, John E Drake wrote: >>>>>>>>> I think that's a big mistake(tm). If a new rate or TSG is >>>>>>>>> introduced the RFC would need to be updated even though the >>>>>> encoding >>>>>>>>> does not require it. >>>>>>>> >>>>>>>> Well that's easily addressed, via something like: >>>>>>>> >>>>>>>> Length (12 bits): indicates the number of bits of the Bit Map >>>>>>>> field, i.e., the number of TS in the HO ODUk link. The TS >>>>>>>> granularity, 1.25Gbps or 2.5Gbps, may be derived by dividing the >>>>>>>> HO ODUk link's rate by the value of the Length field. In the >>>>>>>> context of [G709-2012], the values of 4 and 16 indicate a TS >>>>>>>> granularity of 2.5Gps, and the values 2, 8, 32 and 80 indicate a >>>>>>>> TS granularity of >>>>>> 1.25Gps. >>>>>>>> >>>>>>>> Lou >>>>>>>> >>>>>>>>> Sent from my iPhone >>>>>>>>> >>>>>>>>> On May 20, 2013, at 2:43 PM, "Lou Berger" >>>> wrote: >>>>>>>>> >>>>>>>>>> John, >>>>>>>>>> There's still some ambiguity here. How about: >>>>>>>>>> On 5/20/2013 9:15 AM, John E Drake wrote: >>>>>>>>>>> Length (12 bits): indicates the number of bits of the Bit Map >>>>>>>>>>> field, i.e., the number of TS in the HO ODUk link. The TS >>>>>>>>>>> granularity, 1.25Gbps or 2.5Gbps, may be derived by dividing >>>>>>>>>>> the HO ODUk link's rate by the value of the Length field. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Replace: >>>>>>>>>>> For example, for an HO ODU2 >>>>>>>>>>> link, whose link rate is 10Gbps, the value of the Length >>>> field >>>>>>>>>>> will be either 4 or 8 and the TS granularity will be either >>>>>>>>>>> 2.5Gbps or 1.25Gbps, respectively. >>>>>>>>>> With: >>>>>>>>>> >>>>>>>>>> The values of 4 and 16 indicate a TS granularity of 2.5Gps, >>>>>>>>>> while the values 2, 8, 32 and 80 indicate a TS granularity of >>>> 1.25Gps. >>>>>>>>>> >>>>>>>>>> Lou >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Irrespectively Yours, >>>>>>>>>>> >>>>>>>>>>> John >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>>>>>>>>> Sent: Friday, May 17, 2013 1:33 PM >>>>>>>>>>>> To: John E Drake >>>>>>>>>>>> Cc: Fatai Zhang; >>>>>>>>>>>> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; >>>>>>>>>>>> CCAMP; draft-ietf-ccamp-gmpls-signaling- >>>> g709v3@tools.ietf.org >>>>>>>>>>>> Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: >>>>>> Closing >>>>>>>>>>>> G.709 open issues) >>>>>>>>>>>> >>>>>>>>>>>> John, >>>>>>>>>>>> I guess you haven't been paying attention! The rewrite >>>>>>>>>>>> originated from Daniele, was tweaked by me and then fixed by >>>>>> Fatai. >>>>>>>>>>>> >>>>>>>>>>>> Do you have an alternate proposal to address issue#48? >>>>>>>>>>>> Issue #48="In signaling document section 6: Clarify related >>>>>>>>>>>> text [i.e., the OLD text] to unambiguously identify the >>>>>>>>>>>> relationship between label length and TSG." >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Lou >>>>>>>>>>>> >>>>>>>>>>>> On 5/17/2013 1:15 PM, John E Drake wrote: >>>>>>>>>>>>> Lou, >>>>>>>>>>>>> >>>>>>>>>>>>> I think the original text is fine and your attempted >>>>>>>>>>>>> re-write >>>>>>>>>>>> completely mangled its meaning. The label is a bit vector >>>>>>>>>>>> whose length is equal to the ODUk rate / TSG. >>>>>>>>>>>>> >>>>>>>>>>>>> Irrespectively Yours, >>>>>>>>>>>>> >>>>>>>>>>>>> John >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: ccamp-bounces@ietf.org >>>>>>>>>>>>>> [mailto:ccamp-bounces@ietf.org] >>>>>> On >>>>>>>>>>>>>> Behalf Of Lou Berger >>>>>>>>>>>>>> Sent: Friday, May 17, 2013 9:17 AM >>>>>>>>>>>>>> To: Fatai Zhang >>>>>>>>>>>>>> Cc: draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; >>>>>> CCAMP; >>>>>>>>>>>>>> draft- ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>>>>>>>>>>>> Subject: [CCAMP] Confirming plan for Issue #48: (Was: >>>>>>>>>>>>>> Closing >>>>>>>>>>>>>> G.709 open issues) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Authors/WG, >>>>>>>>>>>>>> From the mail on the list it seems to me that we've >>>>>>>>>>>>>> reached >>>>>>>>>>>> closure >>>>>>>>>>>>>> on Issue #48: "Document no explicit indication of TSG in >>>>>>>>>>>>>> the >>>>>> label" >>>>>>>>>>>>>> (http://trac.tools.ietf.org/wg/ccamp/trac/ticket/48). I'd >>>>>> like >>>>>>>>>>>>>> to confirm my reading. >>>>>>>>>>>>>> >>>>>>>>>>>>>> As I read the list, this issue will be resolved by making >>>>>>>>>>>>>> the following change to draft-ietf-ccamp-gmpls-signaling- >>>> g709v3. >>>>>>>>>>>>>> >>>>>>>>>>>>>> OLD >>>>>>>>>>>>>> Note that the >>>>>>>>>>>>>> Length field in the label format MAY be used to indicate >>>>>>>>>>>>>> the >>>>>> TS >>>>>>>>>>>>>> type of the HO ODUk (i.e., TS granularity at 1.25Gbps or >>>>>>>>>>>>>> 2.5Gbps) since the HO ODUk type can be known from IF_ID >>>>>>>>>>>>>> RSVP_HOP Object. In some cases when there is no Link >>>>>> Management >>>>>>>>>>>>>> Protocol (LMP) or routing to make the two end points of >>>> the >>>>>>>>>>>>>> link to know the TSG, the TSG information used by another >>>>>>>>>>>>>> end can be deduced from the label format. For example, for >>>>>>>>>>>>>> HO ODU2 link, the value of the length filed will be 4 or >>>> 8, >>>>>>>>>>>>>> which indicates the TS granularity is 2.5Gbps or 1.25Gbps, >>>>>> respectively. >>>>>>>>>>>>>> >>>>>>>>>>>>>> NEW >>>>>>>>>>>>>> Please note that the TS granularity of an HO ODUk can be >>>>>>>>>>>>>> inferred from the length of the label. The values of 4 and >>>>>>>>>>>>>> 16 indicate a TS granularity of 2.5Gps, while the values >>>> 2, >>>>>>>>>>>>>> 8, 32 and 80 indicate a >>>>>>>>>>>> TS >>>>>>>>>>>>>> granularity of 1.25Gps. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please speak up if you disagree with this resolution. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Lou >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 5/9/2013 9:41 PM, Fatai Zhang wrote: >>>>>>>>>>>>>>> For point 1), "1" should be dropped and "7" should be >>>>>>>>>>>>>>> corrected to >>>>>>>>>>>>>> "8" in your proposed text. >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> CCAMP mailing list >>>>>>>>>>>>>> CCAMP@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >> > > > > > From lberger@labn.net Wed May 22 18:41:52 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8DEF1F0D27 for ; Wed, 22 May 2013 18:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.435 X-Spam-Level: X-Spam-Status: No, score=-102.435 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rXStfeb8QWN4 for ; Wed, 22 May 2013 18:41:48 -0700 (PDT) Received: from oproxy13-pub.unifiedlayer.com (oproxy13-pub.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id 82E331F0D2E for ; Wed, 22 May 2013 18:41:44 -0700 (PDT) Received: (qmail 9492 invoked by uid 0); 23 May 2013 01:41:21 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy13.unifiedlayer.com with SMTP; 23 May 2013 01:41:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=/hf1thUqxWOU/Ql1vuCTbzDnP63HwdiQ15yE3VEkH7E=; b=jL0Sikv7JsqhJ/ZRQdxpbHrOHYcrMs6HyXutltWeUzinb3JYxQMxz13VUojPLFefnGCLvEUqqJ75Z7Zs8hBNoksm4jwy5XH4sux23c4Zqpu3GFYn1YrRyre7Y8HjmNG7; Received: from box313.bluehost.com ([69.89.31.113]:52667 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UfKWv-0000ZD-Dn; Wed, 22 May 2013 19:41:21 -0600 Message-ID: <519D73C0.6020901@labn.net> Date: Wed, 22 May 2013 21:41:20 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Fatai Zhang References: <518A82D9.7080508@labn.net> <518BAB17.9090807@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> <518CED28.30303@labn.net> <51924382.2010904@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C90D5@ESESSMB301.ericsson.se> <13ea7ed3bdd.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <5193A26A.1090005@labn.net> <519649B4.5060408@labn.net> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" Subject: Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 01:41:52 -0000 Fatai, I think you missed the following: http://www.ietf.org/mail-archive/web/ccamp/current/msg14861.html As stated in that message: > Please speak up if you think the above is not aligned with prior > consensus or if you have an issue with any of the above. (probably best to respond to that message if you have a comment on it.) Lou On 5/22/2013 9:13 PM, Fatai Zhang wrote: > Hi Lou and all, > > > > I would like to double check again on the original point 2. > > > > I would assume the WG is happy with the proposed approach and then > conclude the discussion on point 2 if there is no more comment until > this Friday. > > > > Note that I think more people have shown their support on the proposed > approach. > > > > > > Best Regards > > > > Fatai > > > > *From:*Fatai Zhang [mailto:zhangfatai@huawei.com] > *Sent:* Monday, May 20, 2013 5:09 PM > *To:* Lou Berger > *Cc:* BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; > draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org > *Subject:* RE: R: Closing G.709 open issues > > > > Hi Lou, > > > > I think my mail on May13rd may have answered your following comments. My > response quoted as follows. > > > > In addition, if people look at the full list that I provided, I think > people can realize that RFC4328 (section 3.1.3) used the same approach > as the proposedapproach (ie., 1:1 mapping between GPIDs and payload > types defined by G.709), ie., we are following what RFC4328 did. > > > > BTW, I am not sure if we need spend so much time on discussing this > point (because there is no issue to stick to the data plane by using the > proposedapproach). > > > > ====================================================================================================================== > > (2) 'Grouped GPID' vs '1:1' mapping (between G.709-2012 and GPIDs > defined in this draft) > > > > We realize that it is safe to use 1:1 mapping approach to avoid some > potential issues after investigation. We know this payload types have > been defined by G.709 (data plane), so physically it is better to use > 1:1 mapping approach. > > For the potential issues I mentioned above, for example, we cannot use > the existing 34 to represent 'STM-1' and 'STM-4 ', because it is > impossible to differentiate which one is 'STM-1' or 'STM-4'. In > addition, from the concept of payload type, we know that e.g, FC-100 is > different from FC-800, right? So, it is better to assign different GPIDs > to these different payload types defined by the data plane. > > > > Furthermore, I think it is much cheaper to create new GPIDs in the > control plane than in the data plane (these payload types will be > carried in the OH). > > > > > > > > > > Best Regards > > > > Fatai > > > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Friday, May 17, 2013 11:16 PM > To: Fatai Zhang > Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; > draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org > Subject: Re: R: Closing G.709 open issues > > > > Fatai, > > > > That's a great start for the WG. Thank you. > > > > To answer your implied question as to why my request for the full list. > > My feeling is that there have been too many "surprises" on the 709 > > documents in areas that I thought were either obvious (but from the IETF > > & GMPLS context, not ITU-T or G.709 perspectives) or resolved by past > > discussions. At this point, as co-chair and Document shepherd, I want > > to ensure that any open point on the documents are unambiguously closed > > and that past discussions (i.e., points of consensus) are 100% captured, > > so that we can smoothly move through the planned second LC and > > publication request. > > > > To that end, in my previous message I asked two questions about points > > where it seems you are proposing moving away from what has been > > previously been discussed & agreed to by the WG. Can you answer the > > following: > > > >>> My questions on the new G-PIDs come down to: > >>> - Why are rate specific G-PIDs being proposed (rather than > >>> continuing to use the previous approach documented in the draft > >>> and in Section 3.1.3 of rfc4328)? > > > >>> - Why are new values being defined rather than using existing > >>> values, e.g., G-PID 56? > >>> > > > > Much thanks, > > Lou > > > > > From zhangfatai@huawei.com Wed May 22 19:06:07 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5849911E812A for ; Wed, 22 May 2013 19:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DR7yc99dvuGS for ; Wed, 22 May 2013 19:06:03 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E88F811E812C for ; Wed, 22 May 2013 19:06:01 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATB30190; Thu, 23 May 2013 02:06:00 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 23 May 2013 03:05:48 +0100 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 23 May 2013 03:05:59 +0100 Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.235]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.01.0323.007; Thu, 23 May 2013 10:05:55 +0800 From: Fatai Zhang To: Lou Berger Thread-Topic: Closing Issue #49 (Was: Re: R: Closing G.709 open issues) Thread-Index: AQHOV1amLRBxUXHtPkyBWPTV+jF4r5kSBU4g Date: Thu, 23 May 2013 02:05:54 +0000 Message-ID: References: <518A82D9.7080508@labn.net> <518BAB17.9090807@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> <518CED28.30303@labn.net> <51924382.2010904@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C90D5@ESESSMB301.ericsson.se> <13ea7ed3bdd.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <5193A26A.1090005@labn.net> <519649B4.5060408@labn.net> <519D73C0.6020901@labn.net> In-Reply-To: <519D73C0.6020901@labn.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" Subject: Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 02:06:07 -0000 Hi Lou, I really missed this mail. I will respond there. Best Regards Fatai -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Thursday, May 23, 2013 9:41 AM To: Fatai Zhang Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; draft-ietf-ccamp-g= mpls-signaling-g709v3@tools.ietf.org Subject: Re: Closing Issue #49 (Was: Re: R: Closing G.709 open issues) Fatai, I think you missed the following: http://www.ietf.org/mail-archive/web/ccamp/current/msg14861.html As stated in that message: > Please speak up if you think the above is not aligned with prior > consensus or if you have an issue with any of the above. (probably best to respond to that message if you have a comment on it.) Lou On 5/22/2013 9:13 PM, Fatai Zhang wrote: > Hi Lou and all, >=20 > =20 >=20 > I would like to double check again on the original point 2. >=20 > =20 >=20 > I would assume the WG is happy with the proposed approach and then > conclude the discussion on point 2 if there is no more comment until > this Friday. >=20 > =20 >=20 > Note that I think more people have shown their support on the proposed > approach. >=20 > =20 >=20 > =20 >=20 > Best Regards >=20 > =20 >=20 > Fatai >=20 > =20 >=20 > *From:*Fatai Zhang [mailto:zhangfatai@huawei.com] > *Sent:* Monday, May 20, 2013 5:09 PM > *To:* Lou Berger > *Cc:* BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; > draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org > *Subject:* RE: R: Closing G.709 open issues >=20 > =20 >=20 > Hi Lou, >=20 > =20 >=20 > I think my mail on May13rd may have answered your following comments. My > response quoted as follows. >=20 > =20 >=20 > In addition, if people look at the full list that I provided, I think > people can realize that RFC4328 (section 3.1.3) used the same approach > as the proposedapproach (ie., 1:1 mapping between GPIDs and payload > types defined by G.709), ie., we are following what RFC4328 did. >=20 > =20 >=20 > BTW, I am not sure if we need spend so much time on discussing this > point (because there is no issue to stick to the data plane by using the > proposedapproach). >=20 > =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= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 > (2) 'Grouped GPID' vs '1:1' mapping (between G.709-2012 and GPIDs > defined in this draft) >=20 > =20 >=20 > We realize that it is safe to use 1:1 mapping approach to avoid some > potential issues after investigation. We know this payload types have > been defined by G.709 (data plane), so physically it is better to use > 1:1 mapping approach. >=20 > For the potential issues I mentioned above, for example, we cannot use > the existing 34 to represent 'STM-1' and 'STM-4 ', because it is > impossible to differentiate which one is 'STM-1' or 'STM-4'. In > addition, from the concept of payload type, we know that e.g, FC-100 is > different from FC-800, right? So, it is better to assign different GPIDs > to these different payload types defined by the data plane. >=20 > =20 >=20 > Furthermore, I think it is much cheaper to create new GPIDs in the > control plane than in the data plane (these payload types will be > carried in the OH). >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > Best Regards >=20 > =20 >=20 > Fatai >=20 > =20 >=20 > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Friday, May 17, 2013 11:16 PM > To: Fatai Zhang > Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; > draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org > Subject: Re: R: Closing G.709 open issues >=20 > =20 >=20 > Fatai, >=20 > =20 >=20 > That's a great start for the WG. Thank you. >=20 > =20 >=20 > To answer your implied question as to why my request for the full list. >=20 > My feeling is that there have been too many "surprises" on the 709 >=20 > documents in areas that I thought were either obvious (but from the IETF >=20 > & GMPLS context, not ITU-T or G.709 perspectives) or resolved by past >=20 > discussions. At this point, as co-chair and Document shepherd, I want >=20 > to ensure that any open point on the documents are unambiguously closed >=20 > and that past discussions (i.e., points of consensus) are 100% captured, >=20 > so that we can smoothly move through the planned second LC and >=20 > publication request. >=20 > =20 >=20 > To that end, in my previous message I asked two questions about points >=20 > where it seems you are proposing moving away from what has been >=20 > previously been discussed & agreed to by the WG. Can you answer the >=20 > following: >=20 > =20 >=20 >>> My questions on the new G-PIDs come down to: >=20 >>> - Why are rate specific G-PIDs being proposed (rather than >=20 >>> continuing to use the previous approach documented in the draft >=20 >>> and in Section 3.1.3 of rfc4328)? >=20 > =20 >=20 >>> - Why are new values being defined rather than using existing >=20 >>> values, e.g., G-PID 56? >=20 >>>=20 >=20 > =20 >=20 > Much thanks, >=20 > Lou >=20 > =20 >=20 > =20 >=20 From jdrake@juniper.net Wed May 22 19:14:44 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F0721F9023 for ; Wed, 22 May 2013 19:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fSgCNSg3i4r for ; Wed, 22 May 2013 19:14:36 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 2B14711E812C for ; Wed, 22 May 2013 19:14:35 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKUZ17i2LXMy0z9Q5fIj9M3tQjp71ynmXG@postini.com; Wed, 22 May 2013 19:14:36 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 22 May 2013 19:10:21 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Wed, 22 May 2013 19:10:20 -0700 Received: from va3outboundpool.messaging.microsoft.com (216.32.180.16) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 22 May 2013 19:21:08 -0700 Received: from mail42-va3-R.bigfish.com (10.7.14.248) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.23; Thu, 23 May 2013 02:10:19 +0000 Received: from mail42-va3 (localhost [127.0.0.1]) by mail42-va3-R.bigfish.com (Postfix) with ESMTP id B574F42013C for ; Thu, 23 May 2013 02:10:19 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -47 X-BigFish: PS-47(z21aILzbb2dI98dI9371I542I1432I1418I4015Idb82hzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dh8275chz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1155h) Received: from mail42-va3 (localhost.localdomain [127.0.0.1]) by mail42-va3 (MessageSwitch) id 1369275016996600_23053; Thu, 23 May 2013 02:10:16 +0000 (UTC) Received: from VA3EHSMHS040.bigfish.com (unknown [10.7.14.246]) by mail42-va3.bigfish.com (Postfix) with ESMTP id EE9A940064; Thu, 23 May 2013 02:10:16 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS040.bigfish.com (10.7.99.50) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 23 May 2013 02:10:12 +0000 Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.1.63]) by BL2PRD0510HT001.namprd05.prod.outlook.com ([10.255.100.36]) with mapi id 14.16.0311.000; Thu, 23 May 2013 02:10:11 +0000 From: John E Drake To: Fatai Zhang , Lou Berger Thread-Topic: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 open issues) Thread-Index: AQHOUz2x/LI/EygSNE2StyemUF3KopkOC57AgABhqoCAAAntLYAAFyOAgABhf0+AAKl/gIAAgNDwgABIqgCAAAF6MIABGNWAgAAI+82AAHO8AIAAFGdA Date: Thu, 23 May 2013 02:10:09 +0000 Message-ID: <0182DEA5604B3A44A2EE61F3EE3ED69E1D50A4D9@BL2PRD0510MB349.namprd05.prod.outlook.com> References: <518A82D9.7080508@labn.net> <518BAB17.9090807@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> <519657FE.5030602@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D5009B0@BL2PRD0510MB349.namprd05.prod.outlook.com> <519693DF.6000003@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D504EAD@BL2PRD0510MB349.namprd05.prod.outlook.com>, <519A6EC1.4080205@labn.net> <9574E62A-6A68-4290-A103-8A0A750E2004@juniper.net>, <519A8A7D.5020002@labn.net> <519B6A75.5040803@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D508BCA@BL2PRD0510MB349.namprd05.prod.outlook.com> <13ec9ac042d.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D50937C@BL2PRD0510MB349.namprd05.prod.outlook.com>, <519D0049.80709@labn.net> <2F3E6A05-D111-4CB2-B2AD-59AE980A2043@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.54] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%HUAWEI.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%LABN.NET$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: CCAMP Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 open issues) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 02:14:44 -0000 Fatai, Length (12 bits): indicates the number of bits of the Bit Map field, i.e., = the number of TS in the HO ODUk link. The TS granularity, 1.25Gbps or 2.5G= bps, may be derived by dividing the HO ODUk link's rate by the value of the= Length field. In the context of [G709-2012], the values of 4 and 16 indic= ate a TS granularity of 2.5Gps, and the values 2, 8, 32 and 80 indicate a T= S granularity of 1.25Gps. Yours Irrespectively, John > -----Original Message----- > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > Sent: Wednesday, May 22, 2013 5:55 PM > To: John E Drake; Lou Berger > Cc: CCAMP > Subject: RE: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 > open issues) >=20 > Hi Lou and John, >=20 > Thanks for your discussion on providing the proposed text. >=20 > However, I am lost by the discussion. >=20 > What is the final proposed text? I hope someone can finalize it. >=20 > I think it is time to conclude the discussion on this point (the > original point 1). >=20 >=20 >=20 > Best Regards >=20 > Fatai >=20 >=20 > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Thursday, May 23, 2013 2:01 AM > To: Lou Berger > Cc: Fatai Zhang; CCAMP > Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 > open issues) >=20 > Bummer >=20 > Sent from my iPhone >=20 > On May 22, 2013, at 10:45 AM, "Lou Berger" wrote: >=20 > > I'm empathetic with the addition, but suspect it's best not to put > the > > first 10 words in the draft... > > > > Lou > > > > On 5/21/2013 8:45 PM, John E Drake wrote: > >> It should be blindingly obvious to the informed reader that in the > context of [G709-2012], the values of 4 and 16 indicate a TS > granularity of 2.5Gps, and the values 2, 8, 32 and 80 indicate a TS > granularity of 1.25Gps. > >> > >> Yours Irrespectively, > >> > >> John > >> > >>> -----Original Message----- > >>> From: Lou Berger [mailto:lberger@labn.net] > >>> Sent: Tuesday, May 21, 2013 5:38 PM > >>> To: John E Drake > >>> Cc: Fatai Zhang; > >>> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; > >>> CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org > >>> Subject: RE: [CCAMP] Confirming plan for Issue #48: (Was: Closing > >>> G.709 open issues) > >>> > >>> John, > >>> > >>> Great. It seems we agree that it shouldn't have been necessary to > >>> discuss this point so many times, and that the additional text > >>> doesn't change the field definition. It is informative narrative > after all. > >>> > >>> Now that said, can you live with the revised "overly precise" text > >>> so that we can move forward (and ensure we're not back here again)? > >>> > >>> Lou > >>> > >>> On May 21, 2013 4:23:37 PM John E Drake wrote: > >>>> Lou, > >>>> > >>>> The question that has always been is whether signaling needed to > >>>> include an explicit TSG filed and the answer has always been no > >>>> because it can be derived from other fields. The text I proposed > >>>> makes that derivation explicit and unambiguous. The additional > >>>> text you are proposing adds neither clarity nor information. > >>>> > >>>> Yours Irrespectively, > >>>> > >>>> John > >>>> > >>>>> -----Original Message----- > >>>>> From: Lou Berger [mailto:lberger@labn.net] > >>>>> Sent: Tuesday, May 21, 2013 5:37 AM > >>>>> To: John E Drake > >>>>> Cc: Fatai Zhang; > >>>>> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; > >>>>> CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org > >>>>> Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing > >>>>> G.709 open issues) John, Really? You're joking right? > >>>>> As I said to Fatai: > >>>>> My feeling is that there have been too many "surprises" on the > >>> 709 > >>>>> documents in areas that I thought were ... resolved by past > >>>>> discussions. At this point, as co-chair and Document shepherd, > >>> I > >>>>> want to ensure that any open point on the documents are > >>>>> unambiguously closed and that past discussions (i.e., points of > >>>>> consensus) are 100% captured, so that we can smoothly move > >>> through > >>>>> the planned second LC and publication request. > >>>>> The particular point of the ambiguity/implicit nature of > >>> determining > >>>>> TSG from length has been brought up at least three times. (Note, > >>> by > >>>>> others in the WG -- this is not my concern.) Each time the > >>> consensus > >>>>> from the discussion is to leave as is, but no or only minimal > >>>>> changes were made to the document. I opened the trac ticket to > >>>>> ensure that the consensus was documented in the draft and that we > >>>>> don't have to yet again revisit this topic -- which *is* my > >>> concern. > >>>>> So, the revised text addresses your concern of not needing to > >>>>> redefine the field for new 709 rate or TSGs, and it is > >>>>> sufficiently precise so that non should misinterpret the current > "implicit" > >>>>> specification of TSG. > >>>>> Can we/you accept the revised "overly precise" text and move > >>> forward? > >>>>> Lou > >>>>> On 5/20/2013 10:30 PM, John E Drake wrote: > >>>>>> What is behind your preoccupation with enumerating all possible > >>>>> combinations of length & TSG? Do you have trouble with > arithmetic? > >>>>>> > >>>>>> Sent from my iPhone > >>>>>> > >>>>>> On May 20, 2013, at 1:42 PM, "Lou Berger" > >>> wrote: > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On 5/20/2013 3:18 PM, John E Drake wrote: > >>>>>>>> I think that's a big mistake(tm). If a new rate or TSG is > >>>>>>>> introduced the RFC would need to be updated even though the > >>>>> encoding > >>>>>>>> does not require it. > >>>>>>> > >>>>>>> Well that's easily addressed, via something like: > >>>>>>> > >>>>>>> Length (12 bits): indicates the number of bits of the Bit Map > >>>>>>> field, i.e., the number of TS in the HO ODUk link. The TS > >>>>>>> granularity, 1.25Gbps or 2.5Gbps, may be derived by dividing > the > >>>>>>> HO ODUk link's rate by the value of the Length field. In the > >>>>>>> context of [G709-2012], the values of 4 and 16 indicate a TS > >>>>>>> granularity of 2.5Gps, and the values 2, 8, 32 and 80 indicate > a > >>>>>>> TS granularity of > >>>>> 1.25Gps. > >>>>>>> > >>>>>>> Lou > >>>>>>> > >>>>>>>> Sent from my iPhone > >>>>>>>> > >>>>>>>> On May 20, 2013, at 2:43 PM, "Lou Berger" > >>> wrote: > >>>>>>>> > >>>>>>>>> John, > >>>>>>>>> There's still some ambiguity here. How about: > >>>>>>>>> On 5/20/2013 9:15 AM, John E Drake wrote: > >>>>>>>>>> Length (12 bits): indicates the number of bits of the Bit > Map > >>>>>>>>>> field, i.e., the number of TS in the HO ODUk link. The TS > >>>>>>>>>> granularity, 1.25Gbps or 2.5Gbps, may be derived by dividing > >>>>>>>>>> the HO ODUk link's rate by the value of the Length field. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Replace: > >>>>>>>>>> For example, for an HO ODU2 > >>>>>>>>>> link, whose link rate is 10Gbps, the value of the Length > >>> field > >>>>>>>>>> will be either 4 or 8 and the TS granularity will be either > >>>>>>>>>> 2.5Gbps or 1.25Gbps, respectively. > >>>>>>>>> With: > >>>>>>>>> > >>>>>>>>> The values of 4 and 16 indicate a TS granularity of 2.5Gps, > >>>>>>>>> while the values 2, 8, 32 and 80 indicate a TS granularity of > >>> 1.25Gps. > >>>>>>>>> > >>>>>>>>> Lou > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> Irrespectively Yours, > >>>>>>>>>> > >>>>>>>>>> John > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> -----Original Message----- > >>>>>>>>>>> From: Lou Berger [mailto:lberger@labn.net] > >>>>>>>>>>> Sent: Friday, May 17, 2013 1:33 PM > >>>>>>>>>>> To: John E Drake > >>>>>>>>>>> Cc: Fatai Zhang; > >>>>>>>>>>> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; > >>>>>>>>>>> CCAMP; draft-ietf-ccamp-gmpls-signaling- > >>> g709v3@tools.ietf.org > >>>>>>>>>>> Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: > >>>>> Closing > >>>>>>>>>>> G.709 open issues) > >>>>>>>>>>> > >>>>>>>>>>> John, > >>>>>>>>>>> I guess you haven't been paying attention! The rewrite > >>>>>>>>>>> originated from Daniele, was tweaked by me and then fixed > by > >>>>> Fatai. > >>>>>>>>>>> > >>>>>>>>>>> Do you have an alternate proposal to address issue#48? > >>>>>>>>>>> Issue #48=3D"In signaling document section 6: Clarify related > >>>>>>>>>>> text [i.e., the OLD text] to unambiguously identify the > >>>>>>>>>>> relationship between label length and TSG." > >>>>>>>>>>> > >>>>>>>>>>> Thanks, > >>>>>>>>>>> Lou > >>>>>>>>>>> > >>>>>>>>>>> On 5/17/2013 1:15 PM, John E Drake wrote: > >>>>>>>>>>>> Lou, > >>>>>>>>>>>> > >>>>>>>>>>>> I think the original text is fine and your attempted > >>>>>>>>>>>> re-write > >>>>>>>>>>> completely mangled its meaning. The label is a bit vector > >>>>>>>>>>> whose length is equal to the ODUk rate / TSG. > >>>>>>>>>>>> > >>>>>>>>>>>> Irrespectively Yours, > >>>>>>>>>>>> > >>>>>>>>>>>> John > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>> From: ccamp-bounces@ietf.org > >>>>>>>>>>>>> [mailto:ccamp-bounces@ietf.org] > >>>>> On > >>>>>>>>>>>>> Behalf Of Lou Berger > >>>>>>>>>>>>> Sent: Friday, May 17, 2013 9:17 AM > >>>>>>>>>>>>> To: Fatai Zhang > >>>>>>>>>>>>> Cc: draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; > >>>>> CCAMP; > >>>>>>>>>>>>> draft- ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org > >>>>>>>>>>>>> Subject: [CCAMP] Confirming plan for Issue #48: (Was: > >>>>>>>>>>>>> Closing > >>>>>>>>>>>>> G.709 open issues) > >>>>>>>>>>>>> > >>>>>>>>>>>>> Authors/WG, > >>>>>>>>>>>>> From the mail on the list it seems to me that we've > >>>>>>>>>>>>> reached > >>>>>>>>>>> closure > >>>>>>>>>>>>> on Issue #48: "Document no explicit indication of TSG in > >>>>>>>>>>>>> the > >>>>> label" > >>>>>>>>>>>>> (http://trac.tools.ietf.org/wg/ccamp/trac/ticket/48). > I'd > >>>>> like > >>>>>>>>>>>>> to confirm my reading. > >>>>>>>>>>>>> > >>>>>>>>>>>>> As I read the list, this issue will be resolved by making > >>>>>>>>>>>>> the following change to draft-ietf-ccamp-gmpls-signaling- > >>> g709v3. > >>>>>>>>>>>>> > >>>>>>>>>>>>> OLD > >>>>>>>>>>>>> Note that the > >>>>>>>>>>>>> Length field in the label format MAY be used to indicate > >>>>>>>>>>>>> the > >>>>> TS > >>>>>>>>>>>>> type of the HO ODUk (i.e., TS granularity at 1.25Gbps or > >>>>>>>>>>>>> 2.5Gbps) since the HO ODUk type can be known from IF_ID > >>>>>>>>>>>>> RSVP_HOP Object. In some cases when there is no Link > >>>>> Management > >>>>>>>>>>>>> Protocol (LMP) or routing to make the two end points of > >>> the > >>>>>>>>>>>>> link to know the TSG, the TSG information used by another > >>>>>>>>>>>>> end can be deduced from the label format. For example, > for > >>>>>>>>>>>>> HO ODU2 link, the value of the length filed will be 4 or > >>> 8, > >>>>>>>>>>>>> which indicates the TS granularity is 2.5Gbps or > 1.25Gbps, > >>>>> respectively. > >>>>>>>>>>>>> > >>>>>>>>>>>>> NEW > >>>>>>>>>>>>> Please note that the TS granularity of an HO ODUk can be > >>>>>>>>>>>>> inferred from the length of the label. The values of 4 > and > >>>>>>>>>>>>> 16 indicate a TS granularity of 2.5Gps, while the values > >>> 2, > >>>>>>>>>>>>> 8, 32 and 80 indicate a > >>>>>>>>>>> TS > >>>>>>>>>>>>> granularity of 1.25Gps. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Please speak up if you disagree with this resolution. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>> Lou > >>>>>>>>>>>>> > >>>>>>>>>>>>> On 5/9/2013 9:41 PM, Fatai Zhang wrote: > >>>>>>>>>>>>>> For point 1), "1" should be dropped and "7" should be > >>>>>>>>>>>>>> corrected to > >>>>>>>>>>>>> "8" in your proposed text. > >>>>>>>>>>>>> > >>>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>>> CCAMP mailing list > >>>>>>>>>>>>> CCAMP@ietf.org > >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp > > >=20 From zhangfatai@huawei.com Wed May 22 19:35:47 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F06B111E8164 for ; Wed, 22 May 2013 19:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.961 X-Spam-Level: X-Spam-Status: No, score=-5.961 tagged_above=-999 required=5 tests=[AWL=-0.563, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1OlweGlH2CX for ; Wed, 22 May 2013 19:35:41 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2B20511E8163 for ; Wed, 22 May 2013 19:35:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATB31990; Thu, 23 May 2013 02:35:26 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 23 May 2013 03:35:10 +0100 Received: from SZXEML424-HUB.china.huawei.com (10.82.67.163) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 23 May 2013 03:35:20 +0100 Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.235]) by szxeml424-hub.china.huawei.com ([10.82.67.163]) with mapi id 14.01.0323.007; Thu, 23 May 2013 10:35:15 +0800 From: Fatai Zhang To: Lou Berger , CCAMP Thread-Topic: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues) Thread-Index: AQHOViWQY0rdNLd8TU6gdPkEdNxSL5kSC4Bg Date: Thu, 23 May 2013 02:35:14 +0000 Message-ID: References: <518A82D9.7080508@labn.net> <518BAB17.9090807@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> <518CED28.30303@labn.net> <51924382.2010904@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C90D5@ESESSMB301.ericsson.se> <13ea7ed3bdd.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <5193A26A.1090005@labn.net> <519649B4.5060408@labn.net> <519B73C9.2030308@labn.net> In-Reply-To: <519B73C9.2030308@labn.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: multipart/mixed; boundary="_004_F82A4B6D50F9464B8EBA55651F541CF84319B82ESZXEML552MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" Subject: Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 02:35:47 -0000 --_004_F82A4B6D50F9464B8EBA55651F541CF84319B82ESZXEML552MBXchi_ Content-Type: multipart/alternative; boundary="_000_F82A4B6D50F9464B8EBA55651F541CF84319B82ESZXEML552MBXchi_" --_000_F82A4B6D50F9464B8EBA55651F541CF84319B82ESZXEML552MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Lou, I incorporated your proposal into my table to facilitate the readers. I think you still insist on reusing some existing G-PIDs like 58, 56. For = 0x04, why you think that RFC4328 does not cover it (ie., G-PID=3D54)? Technically, I am not convince by your proposal, but I would like to reserv= e my opinion for your same motivation (ie., to conclude the discussion as s= oon as possible). Any opinions on Lou's proposal from the WG? I will update the signaling dra= ft based on Lou's proposal if there is no comment on Lou's proposal. Note that all the new G-PID values will be re-ordered with TBA. G-PIDs vs Payload types defined in Table 15-8 of G.709 Payload Type in Hex code defined in G.709 G-PID LSP Encoding Note Interpretation from G.709 0x01 None Not needed Experimental mapping (Note 3) 0x02 49 G.709 ODUk, G.709 OCh 1)G-PID defined in RFC4328; 2) Updated in this draft. Asynchronous CBR mapping, see clause 17.2 0x03 50 G.709 ODUk ditto Bit synchronous CBR mapping, see clause 17.2 0x04 32 SDH, G.709 ODUk ditto ATM mapping, see clause 17.3 0x05 54 or TBA (Suggested by Lou) G.709 ODUk (and SDH) G-PIDs defined in RFC4328 for framed GFP GFP mapping, see clause 17.4 0x06 None Not needed and Not defined in RFC4328 Virtual Concatenated signal, see clause 18 (Note 5) 0x07 61(TBA) Or 55(Suggested by Lou) G.709 ODUk (k=3D0,3,4) Is being defined in this draft (new payload type defined in [G.709-2012]) PCS codeword transparent Ethernet mapping: * 1000BASE-X into OPU0, see clauses 17.7.1 and 17.7.1.1 * 40GBASE-R into OPU3, see clauses 17.7.4 and 17.7.4.1 * 100GBASE-R into OPU4, see clauses 17.7.5 and 17.7.5.1 0x08 62(TBA) Or 58(Suggested by Lou) G.709 ODUk (k=3D2e) ditto FC-1200 into OPU2e mapping, see clause 17.8.2 0x09 63(TBA) G.709 ODUk (k=3D2) ditto GFP mapping into Extended OPU2 payload, see clause 17.4.1 (Note 6) 0x0A 64(TBA) G.709 ODUk (k=3D0) ditto STM-1 mapping into OPU0, see clause 17.7.1 0x0B 65(TBA) G.709 ODUk (k=3D0) ditto STM-4 mapping into OPU0, see clause 17.7.1 0x0C 66(TBA) Or 58(Suggested by Lou) G.709 ODUk (k=3D0) ditto FC-100 mapping into OPU0, see clause 17.7.1 0x0D 67(TBA) Or 58(Suggested by Lou) G.709 ODUk (k=3D1) ditto FC-200 mapping into OPU1, see clause 17.7.2 0x0E 68(TBA) Or 58(Suggested by Lou) G.709 ODUflex ditto FC-400 mapping into OPUflex, see clause 17.9 0x0F 69(TBA) Or 58(Suggested by Lou) G.709 ODUflex ditto FC-800 mapping into OPUflex, see clause 17.9 0x10 51 G.709 ODUk 1)G-PID defined in RFC4328; 2) Updated in this draft. Bit stream with octet timing mapping, see clause 17.6.1 0x11 52 G.709 ODUk ditto Bit stream without octet timing mapping, see clause 17.6.2 0x12 70(TBA) G.709 ODUflex Is being defined in this draft (new payload type defined in [G.709-2012]) IB SDR mapping into OPUflex, see 17.9 0x13 71(TBA) G.709 ODUflex ditto IB DDR mapping into OPUflex, see 17.9 0x14 72(TBA) G.709 ODUflex ditto IB QDR mapping into OPUflex, see 17.9 0x15 73(TBA) G.709 ODUk (k=3D0) ditto SDI mapping into OPU0, see 17.7.1 0x16 74(TBA) G.709 ODUk (k=3D1) ditto (1.485/1.001) Gbit/s SDI mapping into OPU1, see 17.7.2 0x17 75(TBA) G.709 ODUk (k=3D1) ditto 1.485 Gbit/s SDI mapping into OPU1, see 17.7.2 0x18 76(TBA) G.709 ODUflex ditto (2.970/1.001) Gbit/s SDI mapping into OPUflex, see 17.9 0x19 77(TBA) G.709 ODUflex ditto 2.970 Gbit/s SDI mapping into OPUflex, see 17.9 0x1A 78(TBA) Or 56(Suggested by Lou) G.709 ODUk (k=3D0) ditto SBCON/ESCON mapping into OPU0, see 17.7.1 0x1B 79(TBA) G.709 ODUk (k=3D0) ditto DVB_ASI mapping into OPU0, see 17.7.1 0x20 47 G.709 ODUk 1) G-PIDs defined in RFC4328. 2) Updated in this draft. ODU multiplex structure supporting ODTUjk only, see clause 19 (AMP only) 0x21 59/60(TBA) G.709 ODUk 1)Are being defined in this draft (new payload type defined in [G.709-2012]= ); 2) 59 for G.709 ODU-1.25G; 60 for G.709 ODU-any ODU multiplex structure supporting ODTUk.ts or ODTUk.ts and ODTUjk, see cla= use 19 (GMP capable) (Note 7) 55 None Not needed Not available (Note 2) 66 None Not needed Not available (Note 2) 80-8F None Not needed Reserved codes for proprietary use (Note 4) FD None Or TBA(Suggested by Lou) Not needed NULL test signal mapping, see clause 17.5.1 FE None Or TBA(Suggested by Lou) Not needed PRBS test signal mapping, see clause 17.5.2 FF None Not needed Not available (Note 2) Best Regards Fatai -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of L= ou Berger Sent: Tuesday, May 21, 2013 9:17 PM To: CCAMP Cc: draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org Subject: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues) All, In the interest of moving this discussion quickly to closure, I spent some time trying to come up with the full list of G.709 PT to G-PID mappings. In coming up with this list I tried to be consistent with the last consensus point that I can identify on this topic (the previously referenced July 2012 thread & presentation), which included: A) Defining new G-PIDs for client types not identified by an assigned G-PID (per http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parameters.x= ml) B) Reusing G-PID wherever {G-PID, ODU rate} unambiguously identify a G.709 payload type, and define new G-PIDs when reuse not possible. C) No G-PID value for unused, reserved, or proprietary 709 Payload Type. Here's what I've come up with: G.709 Payload Type G-PID Type/Comment LSP Encoding =3D=3D=3D=3D =3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 0x01 No standard value 0x02 49 CBRa G.709 ODUk 0x03 50 CBRb G.709 ODUk 0x04 32 ATM G.709 ODUk 0x05 TBA1 Framed GFP G.709 ODUk 0x06 ??? Is any valued needed? 0x07 55 Ethernet PHY G.709 ODUk (k=3D0) (transparent G.709 ODUk (k=3D3) GFP) G.709 ODUk (k=3D4) 0x08 58 Fiber Channel G.709 ODUk (k=3D2e) 0x09 TBA1 Framed GFP G.709 ODUk (k=3D2e) 0x0A TBA2 STM-1 G.709 ODUk (k=3D0) 0x0B TBA3 STM-4 G.709 ODUk (k=3D0) 0x0C 58 Fiber Channel G.709 ODUk (k=3D0) 0x0D 58 Fiber Channel G.709 ODUk (k=3D1) 0x0E 58 Fiber Channel G.709 ODUflex 0x0F 58 Fiber Channel G.709 ODUflex 0x10 51 BSOT G.709 ODUk 0x11 52 BSNT G.709 ODUk 0x12 TBA4 InfiniBand G.709 ODUflex 0x13 TBA4 InfiniBand G.709 ODUflex 0x14 TBA4 InfiniBand G.709 ODUflex 0x15 TBA5 Serial Digital G.709 ODUk (k=3D0) Interface 0x16 TBA6 Serial Digital G.709 ODUk (k=3D1) Interface/1.001 0x17 TBA5 Serial Digital G.709 ODUk (k=3D1) Interface 0x18 TBA6 Serial Digital G.709 ODUflex Interface/1.001 0x19 TBA5 Serial Digital G.709 ODUflex Interface 0x1A 56 SBCON/ESCON G.709 ODUk (k=3D0) (IANA to update Type field) 0x1B TBA7 DVB_ASI G.709 ODUk (k=3D0) 0x1C 58 Fiber Channel G.709 ODUk 0x20 47 G.709 ODU-2.5G G.709 ODUk (k=3D2,3) (IANA to update Type field) TBA8 G.709 ODU-1.25G G.709 ODUk (k=3D1,2,3) 0x21 TBA8 G.709 ODU-1.25G G.709 ODUk (k=3D2,3,4) TBA9 G.709 ODU-Any G.709 ODUk (k=3D2,3) 0x55 No standard value 0x66 No standard value 0x80-0x8F No standard value 0xFD TBA10 Null Test G.709 ODUk 0xFE TBA11 Random Test G.709 ODUk 0xFF No standard value Note that there are a few differences with Fatai's list, which doesn't format well in e-mail, but is available in the archive http://www.ietf.org/mail-archive/web/ccamp/current/msg14845.html Please speak up if you think the above is not aligned with prior consensus or if you have an issue with any of the above. Much thanks, Lou On 5/20/2013 5:09 AM, Fatai Zhang wrote: > Hi Lou, > > > > I think my mail on March 13rd may have answered your following comments. > My response quoted as follows. > > > > In addition, if people look at the full list that I provided, I think > people can realize that RFC4328 (section 3.1.3) used the same approach > as the current approach of this draft (ie., 1:1 mapping between GPIDs > and payload types defined by G.709), ie., we are following what RFC4328 > did. > > > > BTW, I am not sure if we need spend so much on discussing this point > (because there is no issue to stick to the data plane by using the > current approach of this draft). > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > (2) 'Grouped GPID' vs '1:1' mapping (between G.709-2012 and GPIDs > defined in this draft) > > > > We realize that it is safe to use 1:1 mapping approach to avoid some > potential issues after investigation. We know this payload types have > been defined by G.709 (data plane), so physically it is better to use > 1:1 mapping approach. > > For the potential issues I mentioned above, for example, we cannot use > the existing 34 to represent 'STM-1' and 'STM-4 ', because it is > impossible to differentiate which one is 'STM-1' or 'STM-4'. In > addition, from the concept of payload type, we know that e.g, FC-100 is > different from FC-800, right? So, it is better to assign different GPIDs > to these different payload types defined by the data plane. > > > > Furthermore, I think it is much cheaper to create new GPIDs in the > control plane than in the data plane (these payload types will be > carried in the OH). > > > > > > > > > > Best Regards > > > > Fatai > > > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Friday, May 17, 2013 11:16 PM > To: Fatai Zhang > Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; > draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org > Subject: Re: R: Closing G.709 open issues > > > > Fatai, > > > > That's a great start for the WG. Thank you. > > > > To answer your implied question as to why my request for the full list. > > My feeling is that there have been too many "surprises" on the 709 > > documents in areas that I thought were either obvious (but from the IETF > > & GMPLS context, not ITU-T or G.709 perspectives) or resolved by past > > discussions. At this point, as co-chair and Document shepherd, I want > > to ensure that any open point on the documents are unambiguously closed > > and that past discussions (i.e., points of consensus) are 100% captured, > > so that we can smoothly move through the planned second LC and > > publication request. > > > > To that end, in my previous message I asked two questions about points > > where it seems you are proposing moving away from what has been > > previously been discussed & agreed to by the WG. Can you answer the > > following: > > > >>> My questions on the new G-PIDs come down to: > >>> - Why are rate specific G-PIDs being proposed (rather than > >>> continuing to use the previous approach documented in the draft > >>> and in Section 3.1.3 of rfc4328)? > > > >>> - Why are new values being defined rather than using existing > >>> values, e.g., G-PID 56? > >>> > > > > Much thanks, > > Lou > > > > > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --_000_F82A4B6D50F9464B8EBA55651F541CF84319B82ESZXEML552MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi L= ou,

 

I in= corporated your proposal into my table to facilitate the readers.

 

I th= ink you still insist on reusing some existing G-PIDs like 58, 56.  For= 0x04, why you think that RFC4328 does not cover it (ie., G-PID=3D54)?

 

Tech= nically, I am not convince by your proposal, but I would like to reserve my= opinion for your same motivation (ie., to conclude the discussion as soon = as possible).

 

Any = opinions on Lou’s proposal from the WG? I will update the signaling d= raft based on Lou’s proposal if there is no comment on Lou’s pr= oposal.

 

Note= that all the new G-PID values will be re-ordered with TBA.

 

G-PIDs vs Payload types defined in Table 15-8 = of G.709

 

Pa= yload Type in Hex code defined in G.709=

G-= PID

LS= P Encoding

No= te

In= terpretation from = G.709

0x01

None

 

Not needed

Experimental mapping (Note 3)

0x02

49

G.709 ODUk, G.709 OCh

1)G-PID defined in RFC4328;

2) Updated in this draft.

Asynchronous CBR mapping, see clause 17.2

0x03

50

G.709 ODUk

ditto

Bit synchronous CBR mapping, see clause 17.2

0x04

32

SDH, G.709 ODUk

ditto

ATM mapping, see clause 17.3

0x05

54

or

TBA (= Suggested by Lou)

G.709 ODUk (and SDH)=

 

G-PIDs defined in RFC4328 for framed GFP

 

GFP mapping, see clause 17.4

0x06

None

 

Not needed and Not defined in R= FC4328

Virtual Concatenated signal, se= e clause 18 (Note 5)

0x07

61(TBA)

Or 55(Suggested by Lou)=

G.709 ODUk (k=3D0,3,4)

Is being defined in this draft = (new payload type defined in [G.709-2012])

PCS codeword transparent Ethern= et mapping:

·      1000BASE-X into OPU0, s= ee clauses 17.7.1 and 17.7.1.1

·      40GBASE-R into OPU3, se= e clauses 17.7.4 and 17.7.4.1

·      100GBASE-R into OPU4, s= ee clauses 17.7.5 and 17.7.5.1

0x08

62(TBA)

Or 58(Suggested by Lou)=

G.709 ODUk (k=3D2e)

ditto

FC-1200 into OPU2e mapping, see= clause 17.8.2

0x09

63(TBA)

G.709 ODUk (k=3D2)

ditto

GFP mapping into Extended OPU2 = payload, see clause 17.4.1 (Note 6)

0x0A

64(TBA)

G.709 ODUk (k=3D0)

ditto

STM-1 mapping into OPU0, see cl= ause 17.7.1

0x0B

65(TBA)

G.709 ODUk (k=3D0)

ditto

STM-4 mapping into OPU0, see cl= ause 17.7.1

0x0C

66(TBA)

Or 58(Suggested by Lou)=

G.709 ODUk (k=3D0)

ditto

FC-100 mapping into OPU0, see c= lause 17.7.1

0x0D

67(TBA)

Or 58(Suggested by Lou)=

G.709 ODUk (k=3D1)

ditto

FC-200 mapping into OPU1, see c= lause 17.7.2

0x0E

68(TBA)

Or 58(Suggested by Lou)=

G.709 ODUflex

ditto

FC-400 mapping into OPUflex, se= e clause 17.9

0x0F

69(TBA)

Or 58(Suggested by Lou)=

G.709 ODUflex

ditto

FC-800 mapping into OPUflex, se= e clause 17.9

0x10

51

G.709 ODUk

1)G-PID defined in RFC4328;

2) Updated in this draft.

Bit stream with octet timing ma= pping, see clause 17.6.1

0x11

52

G.709 ODUk

ditto

Bit stream without octet timing= mapping, see clause 17.6.2

0x12

70(TBA)

G.709 ODUflex

Is being defined in this draft = (new payload type defined in [G.709-2012])=

IB SDR  mapping into OPUfl= ex, see 17.9

0x13

71(TBA)

G.709 ODUflex

ditto

IB DDR mapping into OPUflex, se= e 17.9

0x14

72(TBA)

G.709 ODUflex

ditto

IB QDR mapping into OPUflex, se= e 17.9

0x15

73(TBA)

G.709 ODUk (k=3D0)

ditto

SDI  mapping into OPU0, se= e 17.7.1

0x16

74(TBA)

G.709 ODUk (k=3D1)

ditto

(1.485/1.001) Gbit/s SDI mappin= g into OPU1, see 17.7.2

0x17

75(TBA)

G.709 ODUk (k=3D1)

ditto

1.485 Gbit/s SDI mapping into O= PU1, see 17.7.2

0x18

76(TBA)

G.709 ODUflex

ditto

(2.970/1.001) Gbit/s SDI mappin= g into OPUflex, see 17.9

0x19

77(TBA)

G.709 ODUflex

ditto

2.970 Gbit/s SDI mapping into O= PUflex, see 17.9

0x1A

78(TBA)

Or 56(Suggested by Lou)=

G.709 ODUk (k=3D0)

ditto

SBCON/ESCON mapping into OPU0, = see 17.7.1

0x1B

79(TBA)

G.709 ODUk (k=3D0)

ditto

DVB_ASI mappin= g into OPU0, see 17.7.1

0x20

47

G.709 ODUk

1) G-PIDs defined in RFC4328. <= o:p>

2) Updated in this draft.<= /o:p>

ODU multiplex structure support= ing ODTUjk only, see clause 19 (AMP only)

0x21

59/60(TBA)

G.709 ODUk

1)Are being de= fined in this draft (new payload type defined in [G.709-2012]);<= /span>

2) 59 for G.709 ODU-1.25G; 60 f= or G.709 ODU-any

ODU multiplex = structure supporting ODTUk.ts or ODTUk.ts and ODTUjk, see clause 19 (GMP ca= pable) (Note 7)

55

None

 

Not needed

Not available (Note 2)

66

None

 

Not needed

Not available (Note 2)

80-8F

None

 

Not needed

Reserved codes for proprietary = use (Note 4)

FD

None

Or TBA(Suggested by Lou= )

 

Not needed

NULL test signal mapping, see c= lause 17.5.1

FE

None

Or TBA(Suggested by Lou= )

 

Not needed

PRBS test signal mapping, see c= lause 17.5.2

FF

None

 

Not needed

Not available (Note 2)

 

 

 

 

 

 

 

 

 

Best= Regards

 

Fata= i

 

 

-----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of L= ou Berger
Sent: Tuesday, May 21, 2013 9:17 PM
To: CCAMP
Cc: draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org
Subject: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues)<= o:p>

 

All,

 

In the interest of moving th= is discussion quickly to closure, I spent

some time trying to come up = with the full list of G.709 PT to G-PID

mappings.  In coming up= with this list I tried to be consistent with

the last consensus point tha= t I can identify on this topic (the

previously referenced July 2= 012 thread & presentation), which included:

 

A) Defining new G-PIDs for c= lient types not identified by an assigned

G-PID (per=

http://www.iana.org/assignme= nts/gmpls-sig-parameters/gmpls-sig-parameters.xml)

 

B) Reusing G-PID wherever {G= -PID, ODU rate} unambiguously identify a

G.709 payload type, and defi= ne new G-PIDs when reuse not possible.

 

C) No G-PID value for unused= , reserved, or proprietary 709 Payload Type.

 

Here's what I've come up wit= h:

 

    G.709

   Payload

    Type = ;  G-PID   Type/Comment    LSP Encoding<= /o:p>

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

    0x01 = ;          No standard value

    0x02 = ;   49     CBRa     =        G.709 ODUk

    0x03 = ;   50     CBRb     =        G.709 ODUk

    0x04 = ;   32     ATM      =        G.709 ODUk

    0x05 = ;   TBA1   Framed GFP      G.7= 09 ODUk

    0x06 = ;   ???    Is any valued needed?=

    0x07 = ;   55     Ethernet PHY    G.7= 09 ODUk (k=3D0)

    &nbs= p;            &= nbsp; (transparent    G.709 ODUk (k=3D3)

    &nbs= p;            &= nbsp; GFP)           = ; G.709 ODUk (k=3D4)

    0x08 = ;   58     Fiber Channel   G.709 OD= Uk (k=3D2e)

    0x09 = ;   TBA1   Framed GFP      G.7= 09 ODUk (k=3D2e)

    0x0A = ;   TBA2   STM-1      &nb= sp;    G.709 ODUk (k=3D0)

    0x0B = ;   TBA3   STM-4      &nb= sp;    G.709 ODUk (k=3D0)

    0x0C = ;   58     Fiber Channel   G.709 OD= Uk (k=3D0)

    0x0D = ;   58     Fiber Channel   G.709 OD= Uk (k=3D1)

    0x0E = ;   58     Fiber Channel   G.709 OD= Uflex

    0x0F = ;   58     Fiber Channel   G.709 OD= Uflex

    0x10 = ;   51     BSOT     =        G.709 ODUk

    0x11 = ;   52     BSNT     =        G.709 ODUk

    0x12 = ;   TBA4   InfiniBand      G.7= 09 ODUflex

    0x13 = ;   TBA4   InfiniBand      G.7= 09 ODUflex

    0x14 = ;   TBA4   InfiniBand      G.7= 09 ODUflex

    0x15 = ;   TBA5   Serial Digital  G.709 ODUk (k=3D0)=

    &nbs= p;            &= nbsp; Interface

    0x16 = ;   TBA6   Serial Digital  G.709 ODUk (k=3D1)=

    &nbs= p;            &= nbsp; Interface/1.001

    0x17 = ;   TBA5   Serial Digital  G.709 ODUk (k=3D1)=

    &nbs= p;            &= nbsp; Interface

    0x18 = ;   TBA6   Serial Digital  G.709 ODUflex

    &nbs= p;            &= nbsp; Interface/1.001

    0x19 = ;   TBA5   Serial Digital  G.709 ODUflex

    &nbs= p;            &= nbsp; Interface

    0x1A = ;   56     SBCON/ESCON    = ; G.709 ODUk (k=3D0)

    &nbs= p;            &= nbsp; (IANA to update Type field)

    0x1B = ;   TBA7   DVB_ASI      &= nbsp;  G.709 ODUk (k=3D0)

    0x1C = ;   58     Fiber Channel   G.709 OD= Uk

    0x20 = ;   47     G.709 ODU-2.5G  G.709 ODUk

    &nbs= p;            &= nbsp;           &nbs= p;       (k=3D2,3)

    &nbs= p;            &= nbsp; (IANA to update Type field)

    &nbs= p;       TBA8   G.709 ODU-1.25G G.7= 09 ODUk

    &nbs= p;            &= nbsp;           &nbs= p;       (k=3D1,2,3)

    0x21 = ;   TBA8   G.709 ODU-1.25G G.709 ODUk=

    &nbs= p;            &= nbsp;           &nbs= p;       (k=3D2,3,4)

    &nbs= p;       TBA9   G.709 ODU-Any =   G.709 ODUk

    &nbs= p;            &= nbsp;           &nbs= p;     (k=3D2,3)

    0x55 = ;          No standard value

    0x66 = ;          No standard value

    0x80-0x8F=       No standard value

    0xFD = ;   TBA10  Null Test       G.7= 09 ODUk

    0xFE = ;   TBA11  Random Test     G.709 ODUk

    0xFF = ;          No standard value

 

Note that there are a few di= fferences with Fatai's list, which doesn't

format well in e-mail, but i= s available in the archive

http://www.ietf.org/mail-arc= hive/web/ccamp/current/msg14845.html

 

Please speak up if you think= the above is not aligned with prior

consensus or if you have an = issue with any of the above.

 

Much thanks,

Lou

 

 

On 5/20/2013 5:09 AM, Fatai = Zhang wrote:

> Hi Lou,

>

> 

>

> I think my mail on Marc= h 13rd may have answered your following comments.

> My response quoted as f= ollows.

>

> 

>

> In addition, if people = look at the full list that I provided, I think

> people can realize that= RFC4328 (section 3.1.3) used the same approach

> as the current approach= of this draft (ie., 1:1 mapping between GPIDs

> and payload types defin= ed by G.709), ie., we are following what RFC4328

> did.<= /p>

>

> 

>

> BTW, I am not sure if w= e need spend so much on discussing this point

> (because there is no is= sue to stick to the data plane by using the

> current approach of thi= s draft).

>

> 

>

> =3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

>

> (2) 'Grouped GPID' vs '= 1:1' mapping (between G.709-2012 and GPIDs

> defined in this draft)<= o:p>

>

> 

>

> We realize that it is s= afe to use 1:1 mapping approach to avoid some

> potential issues after = investigation. We know this payload types have

> been defined by G.709 (= data plane), so physically it is better to use

> 1:1 mapping approach.

>

> For the potential issue= s I mentioned above, for example, we cannot use

> the existing 34 to repr= esent 'STM-1' and 'STM-4 ', because it is

> impossible to different= iate which one is 'STM-1' or 'STM-4'. In

> addition, from the conc= ept of payload type, we know that e.g, FC-100 is

> different from FC-800, = right? So, it is better to assign different GPIDs

> to these different payl= oad types defined by the data plane.

>

> 

>

> Furthermore, I think it= is much cheaper to create new GPIDs in the

> control plane than in t= he data plane (these payload types will be

> carried in the OH).

>

> 

>

> 

>

> 

>

> 

>

> Best Regards=

>

> 

>

> Fatai=

>

> 

>

> -----Original Message--= ---

> From: Lou Berger [mailt= o:lberger@labn.net]

> Sent: Friday, May 17, 2= 013 11:16 PM

> To: Fatai Zhang

> Cc: BELOTTI, SERGIO (SE= RGIO); Daniele Ceccarelli; CCAMP;

> draft-ietf-ccamp-gmpls-= signaling-g709v3@tools.ietf.org

> Subject: Re: R: Closing= G.709 open issues

>

> 

>

> Fatai,

>

>    =     

>

> That's a great start fo= r the WG.  Thank you.

>

> 

>

> To answer your implied = question as to why my request for the full list.

>

> My feeling is that ther= e have been too many "surprises" on the 709

>

> documents in areas that= I thought were either obvious (but from the IETF

>

> & GMPLS context, no= t ITU-T or G.709 perspectives) or resolved by past

>

> discussions.  At t= his point, as co-chair and Document shepherd, I want

>

> to ensure that any open= point on the documents are unambiguously closed

>

> and that past discussio= ns (i.e., points of consensus) are 100% captured,

>

> so that we can smoothly= move through the planned second LC and

>

> publication request.

>

> 

>

> To that end, in my prev= ious message I asked two questions about points

>

> where it seems you are = proposing moving away from what has been

>

> previously been discuss= ed & agreed to by the WG.  Can you answer the

>

> following:

>

> 

>

>>> My questions on= the new G-PIDs come down to:

>

>>> - Why are rate = specific G-PIDs being proposed (rather than

>

>>>   con= tinuing to use the previous approach documented in the draft

>

>>>   and= in Section 3.1.3 of rfc4328)?

>

> 

>

>>> - Why are new v= alues being defined rather than using existing

>

>>>   val= ues, e.g., G-PID 56?

>

>>>

>

> 

>

> Much thanks,=

>

> Lou

>

> 

>

> 

>

____________________________= ___________________

CCAMP mailing list

CCAMP@ietf.org

https://www.ietf.org/mailman= /listinfo/ccamp

--_000_F82A4B6D50F9464B8EBA55651F541CF84319B82ESZXEML552MBXchi_-- --_004_F82A4B6D50F9464B8EBA55651F541CF84319B82ESZXEML552MBXchi_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="GPIDs for OTN signaling draft with Lou's proposal.docx" Content-Description: GPIDs for OTN signaling draft with Lou's proposal.docx Content-Disposition: attachment; filename="GPIDs for OTN signaling draft with Lou's proposal.docx"; size=68302; creation-date="Fri, 17 May 2013 03:10:11 GMT"; modification-date="Thu, 23 May 2013 02:15:43 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQCMimiR9gEAAOIKAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADE Vstu2zAQvBfoPwi8FhadFCiKwnIOfRzbAHWBXmlyZTMRHyDXSfz3XUmRGtiO5JoQehEgCDs7nJld cXHzZKrsAULUzhbsKp+zDKx0SttNwX6tvs0+siyisEpUzkLB9hDZzfLtm8Vq7yFmVG1jwbaI/hPn UW7BiJg7D5a+lC4YgfQaNtwLeS82wK/n8w9cOotgcYY1BlsufhCBoBVktyLgd2GoD390QfHSObQO IeYEx7LPbV3dumDC+0pLgUScP1h10HTmylJLUE7uDLXKazgfnIQY6WimynvodzU0P01C7iI689tU XCOY2+B8vEqm0oPWeBBQQ+w4fIFS7CrMvj6RPq0ldx42ByfXplay+UC8T9QEqOJBzYhaz/bkVNko GrfaD7EatmNA0cbW3pVhmAtc7ZGN0LZT9dV42Z1ZQ6A8JHt6FK8eepRExH01RcBb3NH2YNVEE9Yh D1Egv5qp4pTPZBOgnhoFakaDfjBYr0YgAiIFYIIF0yEPHb9fchCuk49/lMF6xUE4s//7/9G/t7/d ickUWph/8b/VKH2pXyo+0h8TePNMJ9HAjPq9BaEmyVsLfGb/CfJ2Zv+SbhErsa4gOW4nTH+GHhXh EdY/J1s9L8BHibSipWfvSItxN/5OvwsXmNHdWSRVnxh53txQl38AAAD//wMAUEsDBBQABgAIAAAA IQCZVX4FBAEAAOECAAALAAgCX3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArJLPSsNAEMbvgu+wzL2ZtIqINOlF hN5E4gMMu9MkmP3D7lTbt3ctiAZq0oPHnfnmm9987HpzsIN655h67ypYFiUodtqb3rUVvDZPi3tQ ScgZGrzjCo6cYFNfX61feCDJQ6nrQ1LZxaUKOpHwgJh0x5ZS4QO73Nn5aEnyM7YYSL9Ry7gqyzuM vz2gHnmqrakgbs0NqOYY8uZ5b7/b9Zofvd5bdnJmBfJB2Bk2ixAzW5Q+X6Maii1LBcbr51xOSCEU GRvwPNHqcqK/r0XLQoaEUPvI0zxfiimg5eVA8xGNFT/pfPhoMEd0ynaK5vY/afQ+ibcz8Zw030g4 +pj1JwAAAP//AwBQSwMEFAAGAAgAAAAhAG8BpR95AQAAUggAABwACAF3b3JkL19yZWxzL2RvY3Vt ZW50LnhtbC5yZWxzIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArFbLTsMwELwj 8Q+R78R1C+Whpr0gpF6hSFzdZPMQiR3ZW6B/z9KqadpG5rKXSDtRdiazs05mi5+mjr7A+cqaRKh4 JCIwqc0qUyTiffVy8yAij9pkurYGErEFLxbz66vZK9Qa6SFfVq2PqIvxiSgR2ycpfVpCo31sWzB0 J7eu0UilK2Sr009dgByPRlPp+j3E/KRntMwS4ZYZ8a+2LTH/39vmeZXCs003DRgcoJAl6AwcddSu AKSeu1rFJFLIYX414RSQW4t9Aft6EhLAyu9xW9MEOwP2dYj+nvP1wWSGDOgJOCAhCWrMqWE4A8ER sPKbTbMGR/t1nEIHBV3gNCHdeLTNB8W+i0Icyw6VFUITXIspp5q/LTjLRQcFLVHcKi53cxwScMfJ /w3rN0CkZPT2oweGhChWJUjHNxyTsSvl7hrMhKKPB99ZPXxUBgXccvL7i1kckNAgHjklDB9VwUQq Vg9ya3Cl13UvDB10cEGe/AnMfwEAAP//AwBQSwMEFAAGAAgAAAAhAMUfr4JnIQAAINIBABEAAAB3 b3JkL2RvY3VtZW50LnhtbOxdXW7jSJJ+X2DvQOjJBbRtkvp3jzWwJMtVQLXLa7t6Fmg0BpSUsjmm SYGky3ZdYR73AnuCvcG+7Fl277GRmaSUKSXJJEXKkp0zQLltUWQyMjLiiy8jIv/y15dHR/uB/MD2 3NOacaTXNOROvKnt3p3Wvt+ODjs1LQgtd2o5notOa68oqP2196//8pfnk6k3eXpEbqjBLdzg5Ad8 eh+G85Pj42Byjx6t4MibIxc+nHn+oxXCr/7d8aPlPzzNDyfe49wK7bHt2OHrsanrrVp0G++09uS7 J9EtDh/tie8F3izEXznxZjN7gqIf8Td8mefSbw6jIZMnHvvIgTF4bnBvz4P4bo9F7waveB/f5Efa S/x4dOLrnucyT5v61jPMx6NDh/3s+dO5701QEMBfh/TDxR0NPe3ZkQDxLRbfkBkC/8x4JI+W7S5u g7VjZf4Xk3cEk3dMn32Mb7V8EZBFD3Rp7E1f8c+59nwCuji9Pq3pererd+pmLf7TFUz02h+HaGY9 OeH6J1fMn8idr3z84x8TuN0PyzmtTUB1kV87xn/16Ydj8otjuXdwEbKC8CywrdPaz/vDwSW+8Di6 En7Oo2943gNW6ZvQ8kP4kj2Fx+IRu9YjyOPv12jW6HQN+L+uR4+CD8kbcq/DDMIfeW4YwFX3tgvv FQ+DfpsbIXmNmX84+IyfGF8oGO/zCVmkJ8HcmsCo5j4KkP8D1XoXh1dfhoGGXyykr0cGEg8Ri3DQ rbeNDpmkSErVDLD3I0gaxi5IalVG42jiz90pSItOO1WlWHhJo06aQka/8GxcWa+OZ0218HWOVgVT ubb0dnsupmhmu2iq2a52a40dpBnNw87WhYQd1vqS0ryZdnHU1rvceLDFwLOWbd9Go1bfGC6M3rp9 I7eh1idakPIGKx5GOHbwbeAHvRH8x99Ab58BAehGC3wxfAZ6d1qbvljU8IjtJnyvD+Yc4AO5nYdf j1gl7JkchO8T/DytNch/UONDrOPEczyw5tZT6NHbO2iGzWeh7469MPQei37bt+/uCz/adsFXoc9F n02//nuxr2ObzYt/7Hy1Xr0n/DZ09mb2C5pSAcOlX8FkxY/S4X/4A3qThRJc+PYUz+Qd/Bx4DlyN VaJV79Kb8H822y3RnzuNuuDPpmGKrq6bHXM5jvjxoQ9PXsCAZr3RMg2sQozf7Jjtep3oFf7jLYEG g2FrWB8QVxVGS2NiueHNHEAmsc2h/xmx093RDTpUkXZj0UR3CSdEvSeRnCbxWsGCgWFxSwV/LbqQ W+wSb3HNLHb+cgJmACT3zT55vQh9zG/CV7B+0bohpvAeWdGMPyA0/wpmMqBuiY59HF8coZHxgH4s b0JgFrAwpLBA4YeBDMXWNfaKt2CdsPnnjCyMCp64riTMeMXvD3MWz3TvM3rRIP4p7nPLf2mN8XdJ roWoHdVSsa7i1QpD25KutrrmoNmtQlfjuYKf0SrYjj5SrFy2vo39CPYRUwwQIXMesXnd3jw2m83O yKhiHp9Pds/m9L7eXGnnEf3BTTXWtuzJIU5OTU5y9LqJbexdeiFvleUmhUCM1UkBl3nm2HduPKAl GUAWIHWWJfvvnVlL8NIbOskvmDoBGiEk/Bm3UuDejL9N5wpi6ecGI4n4QJv5EApkOEk8xWSQEjiz 2W+0RwTlbYAzG+03xpn8W5SBM0P0ElLsjHHmJfxGYCYPOkWwegG1KjH/2TeFue/pL6sqyy+JSFyM Hkve1+DuK2efjI2RWa7ZlUJmez27l7BRUWQeNkZWueZByhtscx7ktHVziPNGUooCvOyFjOVA/T/r yLK/hw3LJad3OVyh3O29UHMRmqIp9xi5iRPCIPiqPFmxRxNXjjk/f5kj38ZbnJajPVrzOZCa2gGG oVr9U/IUYKFuFV6Ynfbb0li5NEOKxtqm4St9mVYGL8xkpcMLuSLiJ9fs7iK84K1BQ9fberOWG9w1 RDs6xIBSuYulv11QwbxbMkUstbaKuMty5EyCN+3b8PvDLzSQ074N7gso/iZIJZ2If1spM4qbGl1L QQoxy258IokBLO98PRo0AEL8yjPuFHqsbGvyWxfXdB88lxF5RwLumZ+07/OpFdLt6vDeDjTI55mF RwVUessY7m2ngbcmkf4wyr+Bfp8Fr+7k3vdc7ynQBv3rGNz9ogUI8RrOg4MNnjlxrKdg/ealvGXP aPPqVGDUvRRwsX1E2452nEUMEhlNvBUr9robb8zmMlcK0RZcnT29XsAKKsJsZZubsdPSsA2zFU29 iPQVol2mP0j5g94S0RaQ9yYw9oNDr6kNiWEFRK5gVjkwq2+HmkJafOo4trs7hbQUd7heB5Bt1nHg u75JsHk8Xt3WZKOAIVRIqySkVU9Z8snMrUJaeZHWzfDzgjQEArGAyiu4Jag6yraH2K0puJVdL7Zi TwrGzWLW9uz2N0VkgR6mcAofkMjqtLu0oIek/KVvbOwikbVCkNLXYeKTbWCutYfKGUS9WcABlYC5 ck35SB8NG2Q3dMMdQxFVCzx0hJLTilqzpcnA7S3oQ1OElVc2uRodo2mSTHwmlbaZKHn+clrOs9+S Z4qtZOb4HuquIOF6WWr3ihzHe6Z5K9kKgPGF5wuW075OS/Yrl6XzJUj+tn+mHdw83d2hAO9jjl+1 r95TSgZUlSFN4hLjt53JEmOI8ci4pSQrP9tT73kAtfc+KXwkpahRYnpojWmBqzUG80M+mTjI8mvw 29wLTmvtboNqMlwpvsKAHgBZlzQ7naxLup0mvgTjmGhMHjTvmMFKunpyJzQHG1f540w16KqAoPUG VPFGr7G00LjcNnoUZG6TSgjSySN6uWVdbrS0g5/xW5mkXDNn8Q58ed1KMj68yO2xRVgS69oBtCjR IPwTaeWKjeAV5ToiyTfTK0ElZjVpNtgq0PmP0r2EG6AlRLF55KGX5soifduedcx+EiiaON6Kmmcw xZlRksxaBkGs/7ifRrPRaNfPseVIXRKbw1rxoMEglDE8KbH1Zj50QZlqF6OrbM/9AVZlCftKeVbl uvfbmpUC5c5ScDkNAtXhOY0ojQYSXkQgHftFsIv4h3QGtl7vnw/i9ViwkUAVGdj4VZjmGpt0uSBi WdyL/EbDMokKx3pTb7Rj8ZRbObbEI1z5ZbyxwmtQhw6EQQ0pJhJeMfIk2cVezI3h4pbAUhGBUT8r 9LbCkH0Ppy9n7rZo+hZyz17eINUSZloGicJUQPFweUVhezi1OavNRFMbzxf+WRCB7qHg6n3ogJDV dGUJ9TfHr4w5im6WYufktT+uHNNwnAQlTILc7gKWT4ho9nCWcy2PeCGsgRxm6sLe77YfPkHdGDAK E8j+dkkGeAAtByyHphnHSKYTlZQ1RaErPOtNAI2hNwjRIG6YiEcV+9eEqiNRBi40A7vH3fJ4AoXt BQYfzmwHmjMOWsMu9B2B30NoJYpG5I94mZF2kIu/3ZLNyjppOEVEJQtr9Hpr0NoFWBMNpHxYw9wY YE27wOJOgDU7MIfpu1hlwpgNbW+iqWBmpzwr3zIOgKkVmZFVBowPIykDlrIkuMsJs1qmjDeAiuub ECWw3d+4tbJm5defmaokJQyI3/eAAclZC0lwIOaJEkkiji6VHUgJQmjym6k5pFDCw6vb/NhXn5gL MSWiCHEAmMs4gomNoYhYk+kmwcqahv7Z3uzcxywV7YgXzGE/knRxpvsi+BOGoC06pB6uY5V6NjQS LvXJYmFoBw+n+sp4NnlVSRvT+6X+C8/XgXRLkrDI3xEsSLka+i/FhWHcuVO4P/JBlmK0WjbwuuuL IftmsM56X95A8QJtjPBmKLNLs6zB1Q5c9KzNmU7b7HV/EMtxaOqG+WcRJUsIjncAP2cCPq7jLgF8 uey9DOyFDueDG9JpFR8IoIW+5cLGtY/PkziH+M53URgz/yec3uCb40WdzV2nINr1FzSgz9vZmXQi lPv0SG2K7fzAfZLZdAH47Msizq2Ttscw6OgbcrIxoD9z/+zm/PDfoctt6Gnfrr7rLG0QaLAD0j4y CJ1D//NI1HzsnYupoV8QKV0vpFQXSKmxlFLjI0oJlGlVTA2BmJpLMTWFYgLVzUtGjfT6sLVpm+5q dtf20w7nTNFNI/LLg2BZDY8YwABcFH9SAzXnkWpRBcP/rgA2xUXBbFWUQ8vMTolclCnJRUV0ijAY iP/I8H385QSaMIRMFE+m5jmIlgQIlypcNpBN9N/MMKKblUA8KC4KTinaPS6KA6SgPFvkwTqKi2JO A8kfmxTnopLSAPFhP6squgG/FJbKGSUMGnigVR2OjS0XHMopNtjEyOSFvVOTb74LHyXeOewVias/ LnmT6HsYF15yHeaHIMXk5DoaHBqmri9CTRPFBAUbTOHAvHOUUu8ND9tycmIFzbT2VS3eQfjU5Qw3 Vt3sbKzdDZ84bxM7Cgbv82nhu7T3zNjcEsOmelLYhM1GWsmHIeoWsa/LNBfbXBzRZc8bSD1GNuIN NbW7WFseJ4t3F00F6WTOzIpTRrH9ptRDGkwutbXGhzAKcnJlyksorDt/gVRNOGABb7iY8c4gC+/+ 5z9x6QlsvNBzAFop2o4t9juoQlE8eUoEm8eDOFYQXmPt8tH0yrpDfR9ZD+TUpOwiFQZswMVnCgJK HC8Zm1gxPlg49g0oX2ZWshVBNlWm1VAQENfJ5vGi4imW8QHZ8wZ3URDwLLDJQeCZwiAJZilOcRnF rOzwKVYvnSlVEDCvUZBZ/mHv5va3QyMm8hbcHpdsE+XaJDtdeNKWkZ6i9HByLqGD3gGl109WrUR7 qSg9C+rEloXjCy+9c3iuqfBcXtOt8BykS2OjQPgD8WbyFgsGFJ7LE4zI4Q6F5/IaBTm5YjzX2Ds8 V0EX/n2led8Bnhu8Kzy3vd3Y/cpwbSXhupWiCz5l9Tprx5u/vKwd70TjqdJWN9Q6iNDEW8OrOYEr G3xRs2C5DLvnkxKSid+yglqlrTbeKG1VMdy5tmlw0BVR0wnLGpdQq4hIRURUS0ouQ8217ZXo1BmN D3s4bxXSVh+t+RxXQgvrSRXFXSNNryEDUTWgSq4zY4xj5kllnA7qQxUSIVAuUiZ+a40dJJmdsCE4 lbEQ2QBBOnWhvU8h0cLRb7BjoKKnDRVURU/kpAYEuWE4x+K09vP+cP3EUBU9qeiJNKyUYwtYN72D DagMFT2p6GmPoidTED0ZbFI4jZ52quZPbSi9pwShcxU9fYDoqaOipxJ2OVTLFNUyheZORTR+T0VP KnoqHj3NHPTCuV/Y3hd2D44S8jDlll2Rr8odgH6L6/25lAgc4qomJvkbG8lQvQmZCrBDBIfF8TtE Uiov1TAbGhpdfc+7itK1YzX46nKj5VYg/KJqM9TJKQuyP2+t7ShZtUCzEk6/MdutGhg32lp++kJK 53YiH1Pl8gn59VZXhV4q9CI7MPQQhuwtQVjdCflBnMFY82Mq7Q975Li4hXPVyfZU9Tbiat2w1Ghw mwyhs3f14S7pmW5v3tsoL2iU0yYVeq0ZJS5XR1UmVVKZJPYWEHp1VOgF7T529RhusClxN/rsVE/+ Ld7wtOz2QG+1zslpJrkcQWZWX/SGlKQx+KOk5MyvsHC9Oim/2UmFcqkasql1TdHpLkRqZCoS4lAR bsol6vNh3RiQWJYchpYePubKXRaXeC8gySKtbJkZ9X//9c///e//kMXnWBmFGCl6JdH0FH0WBrQU LK1l2+BhFGSDJScqfU5apmka1BDIHI7wgND8Eo7ZJW3J8C9fbRcF5LfIjmRHRozkRUK+J2f2xqKW nU4QsdiBGp8uDq++DNmDu65HgwYcvvUrX4BFZwKmI2adT7Gb5w6CuqZEdC4rnkvAVYmmZ37Svs+n 5Ixp29WWJ5wdccEoFQH8G/NW1HZE+2Tx4XjCc8vIl+iFJQswl9VgBBhPIzdn5IV6fTvUghDa6z1q z3Z4r3mTEE4TC+1HXP8Q1UGsUsitso484rXn1sdqxqQJxwdnTyw3vJk7Nl1qof8Z2Xf3IbwUSRE3 K2nwE076cNYa8gMsprEXhh4IiD4wANE4CJOWwc/TGrH4cBzbBMHo8R/ZQ7rBGhBtWNyrOt2oshZ8 SxCpkN8W88d7N33vBXulZPYtbemKFU3ox70Lc6hAnSzqLh/UYX1ZGM79MMJFHXSp4K9XMiv1YWYB nDdzjjUXvq/AJO8pzERKpP11a1vHm4ydK//8hWC6scOsmtDDGJQAJddzF6iFIJUU1AKrHs0WECvf N3m0lO+7Povs8n3VdqHNIfpc7G3pl38v8mUM6RiR018XkxGFghkQtpIUdG7dMnqQD7/ympD3u7wu 5P02pw35vszD7p1IKOBSt2Jbk05JVAnqmY2McnlP5sZhzygECCVAvVLoxbnZEwdZ/mroCQq2g+X5 bxbmxOuNW4Tlwq62npQZQ4wR8c05yOcV+Kv0fR/1PVdAIOb5QXnE7DxjZ3MZcDE5/LEyGBQ2YmKE /Ty2JtfSyrGIsndtwDL3vnC7BWlZItlrU5ZiCbQxwrT8FM1gq2kK7YmY7QvtwEXP8TFMGk6nZa/7 gyzvQ1M3zD+LlJQLNzqUh+LMiFpGJIkiYfPxS1+7GV5r8Z4S7a21sojExUJvWzkBZ5htqWRCUTiK wlkpg+Dsi4oA9jECeAcUTp0z0xhKZafpCFPXFGDgFvR+AoZ3TeEYisJxPMjDIR0+aS4buyPzETn4 XHGmonA4XwGuorL6f86UKmy0j9go19KSoXBKb4aglEzxhCQtlSHbkwmOIRAcXO9wKWOo+A2VokJT h1MTclSKSlKKtUpRgZJn1bdkURCVs2+J0eDMtOI3lrUVHzHee9f8hqn4DcVvGDhXbNHzN1cQpvgN zlcofiO58A1UTFGHzc7IILvi2RXFit8gVQr5IIdSMj2X/ZZSMnGCICRw/JviNwax71yvVlb5Gyp/ Q+VvLPcOwdZw9Pl+bne/g/wN/jBjxW8ofqPZlQSl4nhvwbRl50rLAI7yMqTbdcVvKH5D8RvtAu3s 1vpxZZAbYAQ2KKoDuxAt+4TtVK3ks8M5KKLSRVS6SBVnZyglU+kia+kivZvhl5W6FzjlQ6dd1aC8 pL2tdmqKoFAEhSIoFEER9QOaIDdEPu4qWk6QxkC6zN7IbDpdz2hxm2p4NKrAZPNek/va9OZdJ2A0 FEGhCApFULwTgsIo0ksh4VAVFTuq2HE9dqyyl6diwRQLhlkwcb7HgXHU6DSPjSNdNz7x5wMkMcOS lSwXYzvkEH/S/aJjgtOY5rB3HEBjkS983Q3wKwbDr6T0IIRgo7QzTxW/ovgVxa8ofqVyfsWxgvAa uXA8BZpeWXeoD+d3PJBq/bylL23ODivmRaWGvNvUkKZiXhTzopgXxbwA4ofumKe1xWHzinlRzIti XnBhQ2oDAlXO1Sy7nEvMvBDiRTEu+MzJjKOOFeOiGBflzBXjUjnjkpdX6SheRbWQXLRYeNcZLS3F qyheRfEqBXmVmYNeOF+RsRcqR9GrFBMIZlMP4t7X5Mjyuz1UelysSjFRKSYpKSbmUbet73yKiZil EeWdSFlyySwZyGHJ6xzSE2UWCTHqPJs8ByFztKc6kjiqFwnj6t2EEy1b9S4mlBU5o8iZnSNnUuwf aGyCQqsjid8pon7X5ExbkTOKnFHkjCJngp+ntVbmFv/YC0PvEXCbasV5zZ0UDyLBbP71EM2sJyc8 xXvT9UbL3GBpYSbvyidH0Md35x5JzotX5Iyn7HfVSibmNwg3s7tZKOJBK1ImI2MmCtsnlhvezB07 pFUD/mfE9uo2O20c5oub/5GKKWq4kmIlcfCv+n+W1TEtZ3uNM46WlNtBSji/dQfmMN0FlxnN+SPP DQNwzve2Cy4fQdXNWWBbdGnsXOvLTlKoBzgjBhgYtwyGrWF90cY6E+bwl18xd8AGIrutvdiILLr/ bSDGaGQEQVF7dA9GzGEN2StyHO9ZdsKA/Ol949bKGqG+/sxUJSlhQP7qgJj3TX12tmThfcVedNXr rzR6bHba3VZLssUkXj0bzwrfwRhmRVYIJTy7dXDzdHeHghBNtfGr9tV7KtL0weg06gJCfAfsKRd0 xIYi3cjm2oQWGwCZ6CfCKilaDneJLkrQ5Iujtt5dVWfxmbRS23K5htR75y1VP4Dyyqhp6YfOKrkS 35KwpG/6g2+Xx+c38O9a0weuqSa/7DnYC7+U1vUhMgnpEVW9oauIyp4S+Ch1osI9sqZUYg8IzS/R SwiuibCSkSAjsY+5P8f+QGbZZpvy5xPx3TFO1Fez9lYwEtPgMHWk+F5Gn8N4nKbC57k2JPfTdkhF bcVUAg6Htdw70JI4fDut/bw/HFxi5apWXWSejKe/3U2K3GB88exjwBtOYtrlb/A+z6e1dwUqO51m YzQklr9oVFnOso+1AgQuDo8UqKzNfRQg/weq9cru07+fBkwqIso0YP+YxN7MQbOQur9U75FD4ZNd Wckt5tQEWnAc9xYnUGykhr/3/352s94XrRKI3G+0RyTfD2+Srp+MF+lwOkSuZtOB6+2Qtr3dqMHa S6l/J7540SeB/Ea9MUeu8pvC15RbaXLiydhDlkLH+LD35HhiQYpsgHzaA73VOpfm+LKfhJFOFmiO BMWQe3L3NfXyAPTeKcy5Dv9rSuOmaC1mCzbRt4zO20a3w6pG9s3w7DcKNRsT86a7MEuRHMBsSKSG 1M/q/ZGeMUvlAQSZ2CPHBPPgQebm1YLndRUsNMLNCdqSBiJ24SkEFohXTAvIVP5t3Q2m7yYwMpQJ /IoYMMajpOwmbKTX0CP34vDqyzDQpmhmu7BZZLva9WjQqJudI9FMrmzLbo4c9k2OPfOT9n0+tfDG GsgqvLdBdr41C48KeHOQsokRXFrBydb1vgD828Ikxg6LGx2zQqS8udhiwYaX9gj5kfYcypq1IPSf JuGTj7TgaT73/NAGIo6bW1gDvufNzn1/MXXBHPbsk/fiikLEb8Pb7/94kHp4Utfpgo8WS0rzXOeV VuRNHOspQJrR1Q7OfrsiH6TsMOPIwydsIJYZQR7r2ajCwKNgXNaErX6VDFb51oWM80lEbOu7Dalu jgdLcNfIp2ZHaOsP4u8l8xagwD3T4JYifrHCRz7tJ+E0aDTP2439CAjWZz2HesmqRLN73NLVTgjO 0Ntr1ShkEMROsqKNlkIjxLEiZ7PAasYOmEuhYpBUBaskF4SRM6sJIaMyqxI8voxxq8ZryzwZe1rj 0xkA8DHC2JuJTJfRlnbgomdtbr06njXVcPzEXvcHWYOHpm6Yf376lVsAVLtkwtjIf8TLJZ0OgG3g 9iDLMS4J8CJ0QDyQQut2g/AIAt5mV5t5/moUlGlJpB7ao/aybEMl9WyxAT80jszmxa9aS6/6rTnN 3NQ0b/DGGkj/0HJfufHI2eEECkPZ4e3b4UIIQbwEqqdE1tF5oeEDwLn9/nAUBpzqJjE0SSRJSYMR y1Jbt5x5+aOSxrcPwrLc6aqfeUtpbci+lTVxa5zbBXBuE2tujR30STu49EKktXeJfzPb3dL5N3BI cTLh7qUvJOJlhoANe02+JkjOxQqrGqsThlRa6xLKLtO/lkezL7i5bEzCyE02Bs2+KQ4hLj0XcU5B UtiirfvqhC2Vgpcu7FiCcu8njJt35P3iNwH1YXRBcrq5uebvkMpoyN3eCzUXoSmaco+RE7kQIu+e yPn4kjNb4F8064dlO9jfRO7G3Cl3U0Htf3UzVEK2HLNUUuat1SqgrsrdxEUXFMHIGQjlbsj27mqx h3I3uTswYPCi3M1uuxsV3fDJGmTt9zr6YWf0ITwO434ZpFoCzlRuRLmRaHOoBG362G7kmlb7TbWJ N0UB2csBKnHu2yi0/FcNp69R5qyhQhmSksflVsZhRfq+59ZCmdGwasfC94zKKHhiWirJpH+nkmSp C33DXkDbc1TM9iXTbivWIqpajNSkd8ABDifsqwgUQmZfP2I24pEx+s1rQFldw5gpiJ+ZJI0NJxtH DqoVGC7v5lQjBxlYwgTc9s+q670FulTRFogiooHajIl2Zsky8F6SCCqqe3K3/9CQTuwILr9//aqF 0OtOC+w713LiBkt001Q0HQkeJappWP0Gb7U5Ytxo82U/kamBjb4cNzlKSSvHC36rhRPveuP2/wUA AAD//+xYX2/aMBD/KlGeOmlrSQLhj0qkQsc2aWOoVNpzSEzIZJLIMVD66Xe2k80uJLgFpk3ioTS2 z3fnu5/vzvczMDa9tY/7ZoASioh5493ebHrZhHi3mx6BRZLH4cOE9M1GozVotkddk61Qb/SREVJO DsRsE/+lAV8vfgUfGvwATpu+adlt14RPus1Q3wyf/EIeDQRhVgpk4ob37r0zZORch3s091eYckWc pmtb5cqETblde9gSuhXKZ1O6xQh28+M9+jOMKHqiTOKmt+/cIKc49ihNaA47F3EC8pCf07s85rqy uWiB4Y+WnLcI43Qj2GI/iWC+3NE3nxcfhuPikJy7ZFxuYQ2Jh5kyP4zTBCkekdy3x5rCo4WJJU2O PB5oYjwtcS/P/AA8nBGUI7JGpmcougm0AGTAWNy5u15VMVfSSSBQ4XEqEEj+KWWez1Ted8Uqkseq ZJIzQpOhiLxUSIJGrWwtkOpAA4ygK/N4rHqPg7ur6SqKUE5RaMy2xtd09U6xgWZg6zQd7cDWUsLX QaCr5BzorVarM7J4JH5rtCuBrnc+27L1A7eq8NnPV55ERY4WIL2x4muVw/F491JqJAiFKFTE6Jnc sTv2vwopyeRqlJRLhP23ffIwmBoU7puRx1HiY2PpZ1mcRO+NHCE1SxTuqMgoAfZX+e6Oan08q32t +KHk77VeTtcwubYVYsWXMKA8elFSctBMbI+8wJLSMeXVwqYX+AmdZjimvGyh5DOSaw+761bXM1yb sgBjMbWssv6UY67T/YsQgyptYA9OErXAdaWF99Wmo2ofMTPsN8ZratPjQ9wJClbpFuqmTM2o+LKW VFBebcFLEnxzNasC6vVJfj8WNN2t3JZLEtSMUJLJa2LRGGoAf+3HmD1AjSsYIsOuKTGB6yWHVL/z T5hDNIPaEWlBeq3uud8nyABwV0WCP3zRS7RqnvoSyitDeb1XX/k0O5P//ofHg4JEGLCwx/7NMKtm lNbQYGB1oHIsw6zkgWKFV8c5Cujkd13IKm913xTW2WzDcYdum0f5BfJDRB7QHBGUBKxbKFqTaI0S 0yC9OOyb5EvYEVV2FXUoWpPShq7YME8h3B9mbzXqyXf5W1a9RvOY5FTSx7LrJezQO4I+i6bPYBTW urW6Dd4CWMC323EKk2TRN5+ZnKYZzDsghzmJvVFg2Gk02HCWUpouYdxs8jFGc2lVGLVvttv8LSJM 1je7Xc4qWlGwIHhN6BOkmDVmi/Zi026J6TANPpE4ZHrwzjKOE5Qz0exjEtMAlGa6ie62wAkH2ywN t/wDOKyW0AL3fgEAAP//AwBQSwMEFAAGAAgAAAAhAM+JHCpTAQAA/wIAABAAAAB3b3JkL2Zvb3Rl cjMueG1snFLLbsMgELxX6j9Y3BNIKkWRVSdSFPXUQ9XHB1AbYlRgEWC7+fsufvVxiKJeWLHDzOyy e7//NDprhQ8KbEFWS0YyYUuolD0V5O31YbElWYjcVlyDFQU5i0D2u9ub+y6X0WfItiFvEahjdDml oayF4WEJTlgEJXjDI179iRruPxq3KME4HtW70iqe6ZqxDRlloCCNt/kosTCq9BBAxkTJQUpVijFM DH+N78A8QtkYYWPvSL3QWAPYUCsXJjXzXzVssZ5E2ktNtEZP7zp3jVvleYejMHoouwNfOQ+lCAGz xwGcFVfskvf4gUliZlxTwm/PqRLDlZ1l0mL8mf88vCUOjw7eNEl9N4J/scM1clmX4/pVzwVh7HBY bdcHMqWOQvJGxx9Iz3jyfXiJZy3wact1QTgnNGWVrTAllQ/xUaXC7jYsIRSdEi/F/sT13X0BAAD/ /wMAUEsDBBQABgAIAAAAIQAukAR+awMAAPEJAAAQAAAAd29yZC9mb290ZXIyLnhtbMxWS08UQRC+ m/gfJnPwYFjmsbDAyC6y7EJMWCU84oXLMNPDtsxMj929O643YjR6EE/e5IAmJhoM8WBi9MCfgSX+ C6t7HjC8XCQxcqCne6q+r+qrqp6dnHoS+EoXUYZJWFWNYV1VUOgQF4frVXVlebY0riqM26Fr+yRE VbWHmDpVu3ljMrY8ThXwDpnVhRdtziNL05jTRoHNhkmEQnjpERrYHLZ0XQtsutGJSg4JIpvjNexj 3tNMXa+oKQypqh0aWilEKcAOJYx4XLhYxPOwg9Il86CD8CaeDeJ0AhRyyahR5EMMJGRtHLEMLfhb NEixnYF0L0uiG/iZXRwNwuZSO4ZSBH4SdkyoG1HiIMbgtJG8zBEN/TLuVEABkXsMEkKRM4sksHGY w4jGOFX/vHjDUDwt4dYE1HEioEUN2oiv+emyQNOHh0psxVV1VNehHcGiFwFB5HBVSw3qAAQ9K3ck ApOu7VdVoYmPhAd7WlVH5ENkO+ArYRziE2gYu8OJANIk9UmkNX+ekI0MTTea+rFdHtscxa7gXYd1 hvhgDZGWRaQyuMKxOWEa5x1XdHmcRJABwjTFFsyhuwjx6vW6MW7WE4EcmaeThuCk6hhjlbPqCMjU UMhyGi47aiDP7vhcEI2MmfX6hCSKEoZoifd8BKZSVNtOMsChC0cepozPY1HwMtAnMqZ+nu8u4SCS rjhkHLRWlu+1msrqXeXW4w7hd3rwV2qV3GSnSNJC1qPlkQpIJvKlSTAhWaCEeAlResZrpm6US6Ml syyrKGtJ5f88BrmLkiqn+l2goiEbpdBjV1dxxtCNCfNPKgJuqhVEm6dIZ0nIGYjbxiGUBNmMTzMs ZQeHPOfD11sH338c7G8f7r042N/pb+4VkgfLq2MOXR+i/+7z0c83/a2X/e1nRx83+1/e91996r/9 UEAWiQ9Qi1FzTAztP6lFbF3U0bH1yMm6n+L1trx2rlW6o93dghwwR2dnZWF6rikbqDARM41KozyT nF82ESMFAog2Z5BdcfXW+LXzrQCZ9hcX32qLJddqRBFDtIvU2pBynnHau4M2+POvp0DyHKAc2Y1y f6UllFpSlNXbyjS117AjH1vNxbnm7IPF1vTyORfLfyNjYRJgw2FqxZJ8BAe8s098HC65swWVaJmc En6w1X4DAAD//wMAUEsDBBQABgAIAAAAIQBseyMIJAUAAL8RAAAQAAAAd29yZC9oZWFkZXIyLnht bOxYzW4bNxC+F+g7LPZuS3JsR15EDmw5dgLYqWHHzdGguJSWCJdckNSP8wAJeijQUy89FT3k2J57 6Nukfo3O8GclWa6sWLm1B2tnSc7MN/9cP3s+KUUyYtpwJTtpa7OZJkxSlXM56KRXb4432mliLJE5 EUqyTnrDTPp8/9tvno2zItcJcEuTjWCjsLbKGg1DC1YSs6kqJmGzr3RJLLzqQaMk+t2w2qCqrIjl PS64vWlsNZu7aRCjOulQyyyI2Cg51cqovkWWTPX7nLLwiBx6Fb2e80jRYcmkdRobmgnAoKQpeGWi tPKx0sDEIgoZLTNiVIp4blytoi3XZAyhKIWHPVY6r7SizBhYPfKbtcRWc5nu4EAUUXOsAmFeZ0RS Ei5rMZgYd+JfB28TgtfwuhsoamoI+GIf0sj2RHic60C8TcbZuJPuNJuQjnDipgIFFbVpIxw4BEGQ s/jWU9aqEk6NiOik6BbBkMm876TbjqgIBXYniSqhIGfI0CqU1XDaZ4QBli4T4ow4JIL1bUDydIoj nxCPQ/NB8e/7XvaMNJB9qtS7iBRsa04x1KafaJ6jWQN4dpXw6tvbW17l3OpOe2/7nuXWbtstewBR ntUgCqo8vwBXNA8PW+2tQ+9+7XVTIu1lBTXpfaxfsmBecTEU4D82IRCAiP5p2yFCHYHfUhcbGiyh 0xhOXRdCiFzhXHUPqrh0xPpkKCzi7baarb0th7fyCqpLeyNYhEPaISR+Ux8raQ1sEkM576RHyg5L hMGIsQeGk5ml4kCa+ojPCWcRgAyqXC4EK9eRPM6kOtdK9Z2HBZGDCJ/JjavLeXzvi43u65AfQXfo BeDmKuNScMmSnBv7xuU2Uoc1dVpTGG70W5WxiYX2l9AJ1EVrr4WlRW9qGjHBmX6fUfvCn4Ryau01 d+AcxiBNoHDgt4e//nSuIIoJz+FcmkhSQpZ8/uWv2x8+JvCeM0OB4+Xb6/PvLq8vTg6vv2fackpE 4KavRyeaVAWnxxp4MXIE0n66cqroOxNGA0TsToO5Z8DcaZa+RUnVLcDV7MBUYBpCdUGusmX619U6 Y8oRsSQZakixLzag4tQONYPwAZXBX4AF1NrS5OicuxpE0eCKEEgIsA8k7KLuhyMZ+b00gjB94BYd n9RLWqtxwUhuYjzmpTTwdQ5hT/DqmAuYFCRDOtEZK3sMUk+/yl1ISWY0vYAQQ3iBtppZWiDZB7aw 3pjZcDqmYlGjgYJPeuMzlUMmuxmB/JO+LvEJMyyB2gEPQdW4EiBYU0sKCtRF5kobe8JgTiEBoAEn hJVkZHRqEDEcjUdwWSo01lkiZAKjcG9na8cxzOyU3DKdCA7XljZOk4AJ/fpC5o7ZEi48DQqEBD3R zkDCq1Me6g6TdfYd6LrZIJ3VPQhoKFhsktj2V2zjM2Mn9tav37A9JviNEwkBxnlj41x6ApeLhcEE l4gDwQfgcX+b8HeL0IWjiBVtfXBk9VwfhE6eg7o+h7w4hZbeSZ/s+v6afYWRg1FCD6NPgqfRG+tK BsAFl5DHcZ4GFwW5dv/vnz+iTus0g36XLF+i9+wyuXqVnCgL4wHDFKb0wvJyFL/+th6K+t4wd0l4 0PrPP/24nt4FM/0dZWF5qfW3n/6YQ4E54OKxtC7gXvB/XTz2+vhgZvzH6+L3D3MZuWJXeFTt3/75 aU7XXPZja/JdMXx8rtjTF+fXnc+Q0NOX9ddu4T5PY+cMXyJhdbbP4BLeDELbRANiK3er8O+X/X8A AAD//wMAUEsDBBQABgAIAAAAIQC96NEBUwEAAP8CAAAQAAAAd29yZC9oZWFkZXIxLnhtbJxSyWrD MBC9F/oPRvdESgohmDiBEHrqoXT5AEWSY1FtSLLd/H1H3rocgulFg+bpvTejmd3hU6usET5Iawq0 WhKUCcMsl+ZSoPe3x8UWZSFSw6myRhToKgI67O/vdm1ecZ8B24S8AaCK0eUYB1YJTcPSOmEALK3X NMLVX7Cm/qN2C2a1o1GepZLxiteEbNAgYwtUe5MPEgstmbfBljFRcluWkokhjAw/x7dnniyrtTCx c8ReKKjBmlBJF0Y1/V81aLEaRZpbTTRaje9aN8eNe9rCKLTqy26t585bJkKA7KkHJ8UVueU9fGCS mBhzSvjtOVaiqTSTTFqMP/OfhreE4eHeGyep70bgL/awRi5rc1g//lIgQo7H1XZ9RGPqJEpaq/gD 6RjPvguv8aoEPG2oKhA9I5yy0nBIldKH+CRTYQ8bkhAMTomXYnfC+u6/AAAA//8DAFBLAwQUAAYA CAAAACEA3ypgoGoBAACzAwAAEQAAAHdvcmQvZW5kbm90ZXMueG1spJNdboMwDMffJ+0OKO80tA/T igrVpKoH2McBshBGNGJHSYD19jMU6FZVVbW9BGLHP/8dO5vtl6mjVjmvETK2XCQsUiCx0PCRsbfX ffzIIh8EFKJGUBk7KM+2+f3dpksVFIBB+YgQ4NOWvFUINuXcy0oZ4RdoFZCzRGdEoK374Ea4z8bG Eo0VQb/rWocDXyXJAxsxmLHGQToiYqOlQ49l6ENSLEst1fiZItwteY+RO5SNURCGjNypmjQg+Epb P9HMX2lUYjVB2mtFtKaeznX2lmyFEx31w9RH2R26wjqUynuy7o7OmbhMruUeL7BHzBG3SPidc1Ji hIYZ00/HWf/n5i2oefyYm/eoUyF0F/lplqIuDQdLIK+scCKgY2TSRcbi5XDO0pZmtXjOWJKs96v1 E83naNqpUjR1+OHpya5fZhzPN3yw0WqH/3GKL4mQCEFDM8zIy7mg5D96LpKvaCO102vLvwEAAP// AwBQSwMEFAAGAAgAAAAhAD9l+w1qAQAAuQMAABIAAAB3b3JkL2Zvb3Rub3Rlcy54bWykkktuwyAQ hveVegeLvQPJomqs2FGlKAfo4wAU4xjVMAiw3dy+42fTKIqidIPNDPPND/Nvtt+6ihrpvAKTkuWC kUgaAbkyh5R8vO/jZxL5wE3OKzAyJUfpyTZ7fNi0SQEQDATpI2QYnzSYLkOwCaVelFJzvwArDSYL cJoH3LoD1dx91TYWoC0P6lNVKhzpirEnMmIgJbUzyYiItRIOPBShK0mgKJSQ42eqcLf0HSp3IGot Teg7Uicr1ADGl8r6iabvpeEVywnSXLtEo6vpXGtv6ZY73uJAdDXIbsHl1oGQ3mN0NyRn4pJd6z0+ YIeYK26R8LfnpERzZWZMZ4+z+c/DW+Dw6NCbdqjfi+BbZCdmitokHC2SvLTc8QCOYEjlKYmX/UGL W3Rr/poSxtb71foFHTqGdrLgdRVOMh3adcuMo9mG9jFcbf8/+fiiDAEmKFP3Nnk7l8T+o+gi+Zo6 FDxJ9dkPAAAA//8DAFBLAwQUAAYACAAAACEAWGCzG7oAAAAiAQAAGwAAAHdvcmQvX3JlbHMvaGVh ZGVyMi54bWwucmVsc4SPywrCMBBF94L/EGZv07oQkaZuRHAr9QOGZJpGmwdJFPv3BtwoCC7nXu45 TLt/2ok9KCbjnYCmqoGRk14ZpwVc+uNqCyxldAon70jATAn23XLRnmnCXEZpNCGxQnFJwJhz2HGe 5EgWU+UDudIMPlrM5YyaB5Q31MTXdb3h8ZMB3ReTnZSAeFINsH4Oxfyf7YfBSDp4ebfk8g8FN7a4 CxCjpizAkjL4DpvqGkgD71r+9Vn3AgAA//8DAFBLAwQUAAYACAAAACEAvejRAVMBAAD/AgAAEAAA AHdvcmQvaGVhZGVyMy54bWycUslqwzAQvRf6D0b3REoKIZg4gRB66qF0+QBFkmNRbUiy3fx9R966 HILpRYPm6b03o5nd4VOrrBE+SGsKtFoSlAnDLJfmUqD3t8fFFmUhUsOpskYU6CoCOuzv73ZtXnGf AduEvAGgitHlGAdWCU3D0jphACyt1zTC1V+wpv6jdgtmtaNRnqWS8YrXhGzQIGMLVHuTDxILLZm3 wZYxUXJblpKJIYwMP8e3Z54sq7UwsXPEXiiowZpQSRdGNf1fNWixGkWaW000Wo3vWjfHjXvawii0 6sturefOWyZCgOypByfFFbnlPXxgkpgYc0r47TlWoqk0k0xajD/zn4a3hOHh3hsnqe9G4C/2sEYu a3NYP/5SIEKOx9V2fURj6iRKWqv4A+kYz74Lr/GqBDxtqCoQPSOcstJwSJXSh/gkU2EPG5IQDE6J l2J3wvruvwAAAP//AwBQSwMEFAAGAAgAAAAhAM+JHCpTAQAA/wIAABAAAAB3b3JkL2Zvb3RlcjEu eG1snFLLbsMgELxX6j9Y3BNIKkWRVSdSFPXUQ9XHB1AbYlRgEWC7+fsufvVxiKJeWLHDzOyye7// NDprhQ8KbEFWS0YyYUuolD0V5O31YbElWYjcVlyDFQU5i0D2u9ub+y6X0WfItiFvEahjdDmloayF 4WEJTlgEJXjDI179iRruPxq3KME4HtW70iqe6ZqxDRlloCCNt/kosTCq9BBAxkTJQUpVijFMDH+N 78A8QtkYYWPvSL3QWAPYUCsXJjXzXzVssZ5E2ktNtEZP7zp3jVvleYejMHoouwNfOQ+lCAGzxwGc FVfskvf4gUliZlxTwm/PqRLDlZ1l0mL8mf88vCUOjw7eNEl9N4J/scM1clmX4/pVzwVh7HBYbdcH MqWOQvJGxx9Iz3jyfXiJZy3wact1QTgnNGWVrTAllQ/xUaXC7jYsIRSdEi/F/sT13X0BAAD//wMA UEsDBBQABgAIAAAAIQDHHG0UnAYAAFEbAAAVAAAAd29yZC90aGVtZS90aGVtZTEueG1s7FlNbxtF GL4j8R9Ge29jJ3YaR3Wq2LEbaNNGsVvU43g93p16dmc1M07qG2qPSEiIgnqgEuLCAQGVWgkkyq9J KSpF6l/gnZnd9U68JkkbQQX1IfHOPu/3x7wzvnjpTsTQPhGS8rjpVc9XPERinw9pHDS9G/3uuTUP SYXjIWY8Jk1vSqR3aeP99y7idRWSiCCgj+U6bnqhUsn60pL0YRnL8zwhMbwbcRFhBY8iWBoKfAB8 I7a0XKmsLkWYxh6KcQRsr49G1Cfo2c+/vPjmgbeRce8wEBErqRd8JnqaN3FIDHY4rmqEnMo2E2gf s6YHgob8oE/uKA8xLBW8aHoV8/GWNi4u4fWUiKkFtAW6rvmkdCnBcLxsZIpgkAutdmuNC1s5fwNg ah7X6XTanWrOzwCw74OlVpciz1p3rdrKeBZA9us873alXqm5+AL/lTmdG61Wq95IdbFMDch+rc3h 1yqrtc1lB29AFl+fw9dam+32qoM3IItfncN3LzRWay7egEJG4/EcWge0202555ARZ9ul8DWAr1VS +AwF2ZBnlxYx4rFalGsRvs1FFwAayLCiMVLThIywD2ncxtFAUKwF4HWCC2/ski/nlrQsJH1BE9X0 PkwwlMSM36un3796+hgd3n1yePenw3v3Du/+aBk5VNs4DopUL7/97M+HH6M/Hn/98v4X5XhZxP/2 wyfPfv28HAjlM1Pn+ZePfn/y6PmDT198d78EvinwoAjv04hIdI0coD0egWHGK67mZCBOR9EPMS1S bMaBxDHWUkr4d1TooK9NMUuj4+jRIq4HbwpoH2XAy5PbjsK9UEwULZF8JYwc4A7nrMVFqReuaFkF N/cncVAuXEyKuD2M98tkt3HsxLczSaBvZmnpGN4OiaPmLsOxwgGJiUL6HR8TUmLdLUodv+5QX3DJ RwrdoqiFaalL+nTgZNOMaJtGEJdpmc0Qb8c3OzdRi7Myq7fIvouEqsCsRPk+YY4bL+OJwlEZyz6O WNHhV7EKy5TsTYVfxHWkgkgHhHHUGRIpy2iuC7C3EPQrGDpWadh32DRykULRcRnPq5jzInKLj9sh jpIybI/GYRH7gRxDimK0y1UZfIe7FaKfIQ44Xhjum5Q44T6+G9yggaPSLEH0m4nQsYRW7XTgiMZ/ 144ZhX5sc+Ds2jE0wOdfPSzJrLe1EW/CnlRWCdtH2u8i3NGm2+ZiSN/+nruFJ/EugTSf33jetdx3 Ldf7z7fcRfV80kY7663QdvXcYIdiMyJHCyfkEWWsp6aMXJVmSJawTwy7sKjpzPGQ5CemJISvaV93 cIHAhgYJrj6iKuyFOIEBu+ppJoFMWQcSJVzCwc4sl/LWeBjSlT0W1vWBwfYDidUOH9rlFb2cnQty Nma3CczhMxO0ohmcVNjKhZQpmP06wqpaqRNLqxrVTKtzpOUmQwznTYPF3JswgCAYW8DLq3BA16Lh YIIZGWq/2703C4uJwlmGSIZ4SNIYabvnY1Q1QcpyxdwEQO6UxEgf8o7xWkFaQ7N9A2knCVJRXG2B uCx6bxKlLINnUdJ1e6QcWVwsThajg6bXqC/XPeTjpOmN4EwLX6MEoi71zIdZADdDvhI27Y8tZlPl s2g2MsPcIqjCNYX1+5zBTh9IhFRbWIY2NcyrNAVYrCVZ/Zfr4NazMsBm+mtosbIGyfCvaQF+dENL RiPiq2KwCyvad/YxbaV8oojohcMDNGATsYch/DpVwZ4hlXA1YTqCfoB7NO1t88ptzmnRFW+vDM6u Y5aEOG23ukSzSrZwU8e5DuapoB7YVqq7Me70ppiSPyNTimn8PzNF7ydwU7Ay1BHw4R5XYKTrtelx oUIOXSgJqd8VMDiY3gHZAnex8BqSCm6TzX9B9vV/W3OWhylrOPCpPRogQWE/UqEgZBfaksm+Y5hV 073LsmQpI5NRBXVlYtUekH3C+roHruq93UMhpLrpJmkbMLij+ec+pxU0CPSQU6w3p4fke6+tgX96 8rHFDEa5fdgMNJn/cxVLdlVLb8izvbdoiH4xG7NqWVWAsMJW0EjL/jVVOOVWazvWnMXL9Uw5iOK8 xbCYD0QJ3Pcg/Qf2Pyp8Rkwa6w21z/egtyL4oUEzg7SBrD5nBw+kG6RdHMDgZBdtMmlW1rXp6KS9 lm3WZzzp5nKPOFtrdpJ4n9LZ+XDminNq8SydnXrY8bVdW+hqiOzREoWlUXaQMYExv2kVf3Xig9sQ 6C24358wJU0ywW9KAsPo2TN1AMVvJRrSjb8AAAD//wMAUEsDBAoAAAAAAAAAIQDHGf7qJ40AACeN AAAWAAAAd29yZC9tZWRpYS9pbWFnZTEuanBlZ//Y/+AAEEpGSUYAAQIBASwBLAAA/+EaSkV4aWYA AE1NACoAAAAIAAcBEgADAAAAAQABAAABGgAFAAAAAQAAAGIBGwAFAAAAAQAAAGoBKAADAAAAAQAC AAABMQACAAAAFAAAAHIBMgACAAAAFAAAAIaHaQAEAAAAAQAAAJwAAADIAAABLAAAAAEAAAEsAAAA AUFkb2JlIFBob3Rvc2hvcCA3LjAAMjAwNjowNDoyOCAxMzo1MTowMQAAAAADoAEAAwAAAAH//wAA oAIABAAAAAEAAAEsoAMABAAAAAEAAAEsAAAAAAAAAAYBAwADAAAAAQAGAAABGgAFAAAAAQAAARYB GwAFAAAAAQAAAR4BKAADAAAAAQACAAACAQAEAAAAAQAAASYCAgAEAAAAAQAAGRwAAAAAAAAASAAA AAEAAABIAAAAAf/Y/+AAEEpGSUYAAQIBAEgASAAA/+0ADEFkb2JlX0NNAAL/7gAOQWRvYmUAZIAA AAAB/9sAhAAMCAgICQgMCQkMEQsKCxEVDwwMDxUYExMVExMYEQwMDAwMDBEMDAwMDAwMDAwMDAwM DAwMDAwMDAwMDAwMDAwMAQ0LCw0ODRAODhAUDg4OFBQODg4OFBEMDAwMDBERDAwMDAwMEQwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAARCACAAIADASIAAhEBAxEB/90ABAAI/8QBPwAAAQUB AQEBAQEAAAAAAAAAAwABAgQFBgcICQoLAQABBQEBAQEBAQAAAAAAAAABAAIDBAUGBwgJCgsQAAEE AQMCBAIFBwYIBQMMMwEAAhEDBCESMQVBUWETInGBMgYUkaGxQiMkFVLBYjM0coLRQwclklPw4fFj czUWorKDJkSTVGRFwqN0NhfSVeJl8rOEw9N14/NGJ5SkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2 N0dXZ3eHl6e3x9fn9xEAAgIBAgQEAwQFBgcHBgU1AQACEQMhMRIEQVFhcSITBTKBkRShsUIjwVLR 8DMkYuFygpJDUxVjczTxJQYWorKDByY1wtJEk1SjF2RFVTZ0ZeLys4TD03Xj80aUpIW0lcTU5PSl tcXV5fVWZnaGlqa2xtbm9ic3R1dnd4eXp7fH/9oADAMBAAIRAxEAPwD1VJJJJSkkkklMbLK6q3W2 uDK2Aue9xgBoEuc5x+i1q4HrP+MHKuvfR0eKcdp2jJe2bHx+fWx/sqZ/xjPU/wCL+grX+Mnq7qqK ekVGDf8Apr/6jTFLP7VrXP8A+srg6OVS5nmJCXBA1XzF6b4J8IxSwjmuYiJ8d+1jl8giP05R/S4n YGf1LIsbbdl3WWMcH1l9jnBrgd7XNrn0/a4fuL0/pOeOo9OozANptb729g9p2WtH9Wxrl5Xj9l3f 1Jyd+FfiHmize3+rYJ/8+MtTeUmfcIJ+YfiFfHcETgE4xEfal0HD+rn6Zf8AP4HfyshmNj2Xv+jW 0mPE9m/2nLlqX5W91oteyyxxe/Y4gFxO53t+itr6w3BmIynvdYBHk39If+k1qyqNvdO5qZ4xEH5R /wA4uXyUOHDKZF8Z/wCbFu43WMqlwblfpauC4CHj+V7fa9bVdjLa22VuDmPEtcOCCucu2xorXQcp wtswzqyDbX5agWN/tbt/+ejy+aXEISNg7E91vMcvEwOSEeEx1kBsYu2kkkrjnqSSSSU//9D1VDyM inFosyL3BlNLS+x57NaJcdERcJ/jJ6y9vo9HpfDXj1soDuJ/QVu/tNdZs/4lMy5BjgZfZ5trkOUl zfMQwg0JG5y/dxx+YtfG/wAYN5+sBuuBb0q2KhUeWMn25J27v0v51rf+t/mVr0Fj2WMbZW4PY8Bz XNMgg6tc1wXhK7z/ABffWPjomW4aScNx/wA+ygu/8Eq/zP8ARKpy3MEy4Zm+I6H+t2d7418GxxwD Py0OH2YiOSA/SxR/yn9+H6bn/wCMqf29TP8A3FZH+fcuYpMH5ruv8ZnTi6rE6mxv0CaLTrMO/SU/ 2WuF3/bi4Jhg/FQ8yCMsr66up8GyRyfDsPD+jEwl/ehJ1Md3C6z6k2kdTsrnSygkjzY9m3/z49cZ RYum+p10ddob/pGWN/6Pqf8AotDAayQ8x+LB8UxXy2bwhKX+J63f+s1/69RT2ZWX/wCe7b/6KVGu +Am+tN8daLf3aax95scs9t+idmN5Z+f5OZy2D+jYtN43/jep0n3yOVZ6C/d1YR2qeT97FiuyNOVt /VGl1l+RmH6DGilh8SYts/zW+ijhF5Y+d/Yt5rGMfLZZH93h/wAf0vTEgCTwuH6n9dMlnV2W4WuD jF1bqyRF4JiyyfzPo/qjv++Xekr310656bD0jHJD7Gg5TweK3f4DT867/Cf8B/xy4W+xS8zzBEuC BrhPqPj2T8G+FxnA5s8BL3AY44S/cl/lP8L9B9ewszHzsSrLxnb6bmh7D8fzXfy2/Rejrz//ABed ZLMy7pFrzsvm3Haez2ibmj/jKx6n/Wl6ArOHJ7kBL6Hzcn4jycuU5meE6x+bHL97HL5f+8f/0fVV 459a7n3fWTqD7PpC4sH9WsCpn/QYvY15j/jE6S/E6wOoNE0ZwBJjRtjA2t7P7bdln/birc5EnGCO h1dv/i5lhDnJRlpLJjMYeYInwvKqTHvre2xhLXtIc1wMEEahzSop1nPZDUPqGHmVfXL6r347i2rL LdlrQdG2tiym3853oWvY3/wWpeY21vqsfVYNtlbi17TyCDtcFp/Vnrj+idUryTudjP8AZk1tPLD+ d/Wqd+kb/wBt/nrU+vnSKsfNr6tie/E6kPU3M1YLIDtwc32/rDT638v9MrGQ+7jE/wBOHpn/AHf0 ZORyeP7jzk+W25fmrzct2hlj/O4f8R5uqyF0H1Ru/wCyLAju94++q0LmVufU55P1lwB/Ld/1D1Fi /nIf3o/m3efgDyvMH/VZP/ScnY+td0fWLJb+62of9Dd/35ZzchE+uVu360Zo8qv/AD0xZIyPNHKf 1k/70vzafKYL5Tlz3xYz/wCNxdJ2Rp3J7Ack+AXanIH1X+rVbrgHZR0azkOvt3W7Jb/g6vd7/wDR VLlvqf09vUep/abnBuL0/bfYSdC/U0NJkbWt2es//i1S+s/X/wBrdTfbW4nFpmvFGoG38+7afzr3 f+BempMcvbgcn6UvTD/upNXmOW+9czDlR/NYazcz/eP8zh/wv+g0r8h73OfY4vseS6x55c5xl73f 1lSttlRsulCJJ5Ve3cx4hF0Pq897Ov8ATnNME5VQJHg57WuH9prl7OvK/qH0h3UOtsyHD9BgRc8/ y/8AtOz/ADx6v/WV6otDkgRAk9To8r/xmyQlzWOEdZY4evw4zxRi/wD/0ruB/jPvpzslmfT9pwnX vND69rba6y52yuPbXkbWbP8ARP8A+Eeuyc/oX1q6Y+llrMqh4BO0j1KnHcGP2u99Fzfds3s/8DXi eXQ7DzsjDf8ASxrX1O76sc6v/vqsYGdlYOQzKw7XU31mWvafwP5rmO/PY72Kl78o2Jjii9NL4Vhy iOTl5exliBKMo/ISPlP9X/Adjr/1a6h0K/bePUxnmKcpohrv5LufTt/4NZMrt+k/4wcXLxXYH1kp FjLAGOvY2WuaeXX0t+jt+nvx/wDtpB639RQ+s9Q+rljcvEcC70Gu3OEf9x7Jd6/53s3er/xqinhE rliPEOsf04uhy3xHJiMcPPx9rIfTDP8A+B83+H/k5vHLtfqtlVde6Nk/VrPeDcxu/p736kQPaGaf 9pn/AMvf6FllX8zWuLc1zXFjwWuGhB0IPmj9Pzb+n5tObR/O0PD2gzBj6THR+Y9vseosc+CWvyn0 yHeJb3O8v94wmMTw5YEZMGT9zND1Ql/3MkeRj3Y19mPe3ZdS4ssboYc07XDRbP1Ibu+tGCPOw/dV aVsfXXplGfhUfWjpzSa72N+1CdQCGsqsLW7m76/5i/8ASf6P/hFmfUGov+s2O7/RMscfmx1f/oxP GMwzxjuOKJie8WtPm48x8Mz5a4ZjFlhlh/m80YSjOH+Mr6+tLfrNknjeyo/9Brf++rBqbdbYyqpp sssIaxjRJLidrWtA/eXS/wCMZm36wg/v0MP4vb/31WPqN0imqu/6x9QaRjYbXOx5HJaCbbmt/P8A S+hX/wAL/wAJUjLGZ55RH7xJPaKMHNx5f4VgzSHERihCEOuTLXBCAT/WC7/m19XMfoGOW/bM1pfm 2NOsGBb+77bXfq9b/wDQUvXEEkq11bqNvU+pZGfbo695cG87Wj21VyA3+brDWKqAXENaJJ0AHJKj yz4pafKPTEf1Q2eR5Y4MPrN5shOXPP8Aey5Pm/wYfJFZanQfq9ndcyhTjtLKWn9NkuHsYP8Av9v7 lX/ov9Itvon1Etcxuf154wsJo3uqc7Y8jt6zne3HZ+9/hv8Ailc6j9esDp+I3p31boDWVAsbc9sM aP36mH33Pd9P1L/z/p+tvT4YQBxZTwx6R/Tm1uY+IzySOD4fH38vyyzf+BuX/vZP05/1Hp8dnRfq v0xlL7a8algJc95h9rwP0lm3+cutd+6z+ouU6n/jHvuurr6ZSaKQ9pfbZBe5oLdzBX7mVfnfnW/9 bXIZudmZ+Q7JzLXX3P5c49udrR9FjP5DEOis3X10t1dY9rAPNx2p8+akajjHBHYfvMHLfAsMDLNz cvvOaVykZfzYl+keH9P/AKo//9N/8Z3QLcXqY6zSz9VzNrbnD828Dbq2Pa26pjHf8b6q41j17/m4 WLn4tmHmVNux7m7bK3cEf99c13uY9v0F5Z9Yv8XHVem2G7pQf1HDMna0D1ma+1jqx/SPb/hKW/8A Wa1VzYTZkBdu78M+IxEY4skuGUdIk7Sj/wB8801y0uj9c6l0e/18G0sLo9Ss6seB+bYz87/q1lWM ux7XU5FbqbWGHV2NLHA/ymPhyk148VUIMTY0IehjPHlgYzEZwkNYy9UZPoVXV/qx9bWV09aYMDqQ Aa3IYdod+dDbnhzNuntqyf8ArNnqLF639SusdJD7mt+14jJcb6uWtE+62n6dftG5/wDOVM/0q5sO C6P6v/XbqfR4psJzMMQPRscdzABtAos93pt/4P8Am0/jhPTKKP8AnI/93Fr/AHfmOV9XJT48fXlM x9H/AKb5f8l/ddj/ABe9TquryegZh31Xtc6it3BBBblUjX85n6TY3/hlZ+rfQLOjfXK/GO51Axn2 41rolzC+pnu2/n17vTf/AJ60MTB+rXX7aOr9IeMXNx3stf6IDHgzudXl44+l6n6Rnqf4T/S21rp9 rdwdA3AEA94PP5FZx4rjCyD7ZuEx+lHs4fO/EOHJzHtwlj+9w4OZ5fIOE4s8f8rH+88N9bei39Z+ t2HiV+1jsVrrrP3a2WW+o/v+81lf/CKP1/6hXgYGJ9XsM7atjXXN1JFdcNxmbj+89m9/5/6Ji7va 3dugboie8Lms/p31c6Rk5HWutWDKyshzn1NuhxhujKcXG/PdUz0a/Uf9D/gUsmKhMgge4fVM/owR yXxASyctHJCWSPKRrBgxjjln5k7ZP6vA8V0T6ndY6vstaz7PiOInIt0Bb+9VX9O72/Q/wX/Crefn fVb6oiyvpzf2h1dssdY8yGH87dY0emxrfzq6P0v+Ctesn6wfXjqPVZoxd2Fh6gsY473g+39NY2Pb t/wTP+uequalVeOGPTGOKX+cl/3EXoByvM836udl7WI/+BMJ+b/zpzf5T+5B0esde6n1m4W5tstb /N0t9tbf6lf738t36RZ6aVKqq26xtVLHW2OMNYwFzif5LWqEkyNk2S6MI48UBCEY44RGkY+mMWK6 j6g9Efn9Vbn21k4mEd4fw03CDVX/ACvT/nvb/wAHv/nE3QvqH1XqFgsz2uwMUEbt4i137za6nfQ/ 4y3/AMFXpODg4uBi14mJWKqKhDWj8XOP5znK1y/LyMhOQqI1AP6ThfGfjOOGKfL4JCeWY4ZyifTi ifm9X77/AP/U9VWJ9aPrFd9XsWvMGC/MxnEtusY8NFRO30vU9r/ZbLm+p+//AMbWttBy8XHzMa3E yWCyi9hrtYZEtcNrhLYc3+ygbrQ0V2MxEwZx4o36o7aPAW/42cawQ7pBsHg+5v8A6RchD/GliH/v Dr/7eb/7yrG+tP1E6n0S2zIxmOy+mlx2WMBdZW2N23KY0e3b9H12/ov+J9T0ly0jxVWWTKDRNfQO 9g5TkckRKEeKJ/rz/wC+fQz/AIzqHfQ6NU342g/+67Umf4xMzIsbTidIofc8wxgDrHE+DWVta5yw vq99Ruu9Z23Fn2PDJg5F4IJGkmmj22W8/wDB0/8ACr0/oP1Y6T0Ks/Y65ve0NtyXmXuA1/q1s3fm VIxjmlvLhHkFnMZfhuAVHF7uX93jycI/vy403RW9V+zm3qlWPj3WQW047TLR+7dY5722P/4v/prR SSVkChTiZJ8cjKhG/wBGPyjyUqPV29ROL6nTaqLsmuSKsgGHCNa63tcz07Hfy/0avJJEWKVCfBIS oSo7S+U+b53Z/jAzsW11GZ0mll1Zh9Z3McO/0Xtcnb/jLr/O6RWfhaB/6Icux6z9Xul9aqDM6qXs BFdzDtsZP7rv++Wb615v136j9Z6SDbW37biD/C0g7mjxuo9z2f1merWqmQcxDUS4o+Qt6Hksnwnm QI5MIw5f3TkyRhL/AGc+P/muz/45mP8A+U7P+3h/7zojP8aGMzQdMLZ522j/ANJNXnpeFv8A1b+p /Uut2stex2P08EGy942lzZ9wxtzT6j/5f80o4Zc8jQN/SLb5j4f8LxQM8kOGI75Mv/fvov1a+sbu v1XXtw341FRDW2OduD3Gd7WQ1v8AN/nf11toGFh42Bi1YeKwVUUt2sYPD/vznfSe5HV+IIA4jZ6l 5XPLHLJI4oe3jv0QviqPiZP/1fVUlwv1F/xi5f1p6xd067Crxm047r97HlxJa+qrb7mt/wBMuw6n luwum5eYxoe7GosuawmA41tdYGl2v0tqSm0oejT6nq7G+rEb4G6PDd9Jcj9Qvr1k/WsdQN2IzG+w tqLdji7cbPW53D/gVW+on+MTL+tXVbsC7Crxm045v3se5xJD66tu1zf+FSU90ks36x9Vs6N0PM6p VWLn4tfqNrcSAdQNXBY/1C+uWR9bMXLvvxmYv2axrGhji6dzd2u4NSU9UkuW+vn11H1Tw8WyugZW Tl2FtdTnFrQxgBus3NDvoufUzb/wih9Q/r3V9bKslltTcXNxnAmhrtwdU76NzN21/ts9lv7n6L/S pKesSXC9W/xi5fRvrhX0HqGFWzDtsrDczeW/oroay8h42babD+m/4q1df1bPb0zpeZ1Fzd4w6LL9 kxu9NrrNm7+Xt2JKbaS83+qv+Nq3rXXcXpeZhVYteUXMbc2wmLNpdU3a9v8AhXt9H+vYu1+svW6+ g9Dy+q2N3/ZmSyvjdY4iuln9q17NySm+aKDaLjWw2jQWbRuj+v8ASRFyX1T+u56v0HM6/wBXZT03 BxbDWH7nGdrWOe87m+7e+6uqllf6Sy39GsD/AMd3qOflW09A6BdnMq13Ave8s4bY+jGps9H/ALds SVZfTEl59gfX366ZOfjY9/1WyKKbra67bnV3gMY5zW2WuLqQ32MO5Wfr5/jDy/qr1PHwqcOvJZfQ Li973NIO99e3a1p/cSU//9bkPqH9YMvoHW78zE6dZ1SyzHfSaKi5rmtNlNnreyrI9rfS2fQ/wi7T qf8AjM63l9Ny8V/1WyqWX0WVutL7CGBzHNdY79Tb/Nt9/wBJY/8AiYa5v1sy9zS2cG2JEf4bFXrH 1hn9gdSjn7JfEf8AFvSU+b/4kOOuf1cb/wB2ln/4k/8AxS5n/hJ3/n3HWl/iOaQ7rQcIkYvPgftS xuijqn+LX60W3dUwrcjCsrdjnIqadr63OrtbdjvdtqfY30m/oX2JKfT/AK//APiN6t/4XP5WrlP8 SH/JnU/+Pr/6gql9bP8AGdhfWHol/Ruh4OW7JzdrHOsYzRgc179jKH5LrXWbPS/wahhVZv1H/wAX WYc1pp6t1ywsxaGki1jH1hm+xo99VtNXr3e3+ae/Hrs9O1JTXd1Cr62f4zm5F+VVT0npFgdVY+xn pmvGeNnpvdtrt+3Zf6T/AML2f8CgZPUMT6nf4yzn4VjLOlZp32ei9jm+jkH9Yb+i3NZ9my2Ouro/ 4CpXfqX/AIqendY6BT1Pq92TTdlFz6a6HMaBT9Gp1jbqLffZtfb7X/zL6kvrr/iq6d0boF3U+kW5 V92K5r7q7nMePR+ja9jaaKnbq3OZY73bPR9VJTe/x1dC9XFw+vVNl2OfsuTEk+m8mzHf+61ldvqs /wDQhil9b/rY3I/xX4NrLC/J6u2vHtcTD91X9PfH5zPWx/Rd/wCGFb+qtx+un+LvJ6Hlv/Xsdn2U ueYMs23dNyLNg3+nuZXW/wD032e5eXdOxuodSzenfVy/eykZprALfdW691NOX/223G3bP+MSU7XX ui/82+m/VPruKP09tTb7fbA9Vr29QodY8fSs9PJ9D/i8VdT/AI3vrBjZX1f6Ti4ji8dTc3NaQQD6 LWfohZX9L9M/J9n/AIXeul/xk9DZ1P6nZVVLALOngZWO0GABSD6rYH0v1R17WM/f2Lyv6ldPy/rJ 9Zuk4WZL8XpzJMiIope/KFTv32vyL/R/qWpKeu+vXTn/AFb/AMWPT+j1wHPvqrzCDIc9zbs2/wB3 5zftNXs/kLI+o/1xzPq/0UY+D9W7843WOfbnVueBYQdrW+3Fv/mW/o9vq/8AnxekfXn6uWfWP6u3 9PoLRlBzLsZzzDQ9h7kT9Op1tX9ted/Vb67dY+pVFnQeudLvfTTY40x7H17jutY3cPSyKH2fparG P/P/AMLXZX6aU9Lgf4zOtZWdjYtn1XyaGZFrKnXOfYQwPc1hsdOGz6G7d9Jcx/jt/wDFBg/+Ex/5 8tXT4P8Aje6dm52Nht6bksdlXV0te4sgGxzag4/5y5r/AB1se76wYO1pP6mOBP8AhLUlP//Z/+0e +FBob3Rvc2hvcCAzLjAAOEJJTQQlAAAAAAAQAAAAAAAAAAAAAAAAAAAAADhCSU0D7QAAAAAAEAEs AAAAAQACASwAAAABAAI4QklNBCYAAAAAAA4AAAAAAAAAAAAAP4AAADhCSU0EDQAAAAAABAAAAB44 QklNBBkAAAAAAAQAAAAeOEJJTQPzAAAAAAAJAAAAAAAAAAABADhCSU0ECgAAAAAAAQAAOEJJTScQ AAAAAAAKAAEAAAAAAAAAAjhCSU0D9QAAAAAASAAvZmYAAQBsZmYABgAAAAAAAQAvZmYAAQChmZoA BgAAAAAAAQAyAAAAAQBaAAAABgAAAAAAAQA1AAAAAQAtAAAABgAAAAAAAThCSU0D+AAAAAAAcAAA /////////////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD/ ////////////////////////////A+gAAAAA/////////////////////////////wPoAAA4QklN BAgAAAAAABAAAAABAAACQAAAAkAAAAAAOEJJTQQeAAAAAAAEAAAAADhCSU0EGgAAAAADWwAAAAYA AAAAAAAAAAAAASwAAAEsAAAAEwBIAFcAXwBQAE8AUwBfAFIARwBCAF8AVgBlAHIAdABpAGMAYQBs AAAAAQAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAEsAAABLAAAAAAAAAAAAAAAAAAAAAAB AAAAAAAAAAAAAAAAAAAAAAAAABAAAAABAAAAAAAAbnVsbAAAAAIAAAAGYm91bmRzT2JqYwAAAAEA AAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAATGVmdGxvbmcAAAAAAAAAAEJ0b21sb25n AAABLAAAAABSZ2h0bG9uZwAAASwAAAAGc2xpY2VzVmxMcwAAAAFPYmpjAAAAAQAAAAAABXNsaWNl AAAAEgAAAAdzbGljZUlEbG9uZwAAAAAAAAAHZ3JvdXBJRGxvbmcAAAAAAAAABm9yaWdpbmVudW0A AAAMRVNsaWNlT3JpZ2luAAAADWF1dG9HZW5lcmF0ZWQAAAAAVHlwZWVudW0AAAAKRVNsaWNlVHlw ZQAAAABJbWcgAAAABmJvdW5kc09iamMAAAABAAAAAAAAUmN0MQAAAAQAAAAAVG9wIGxvbmcAAAAA AAAAAExlZnRsb25nAAAAAAAAAABCdG9tbG9uZwAAASwAAAAAUmdodGxvbmcAAAEsAAAAA3VybFRF WFQAAAABAAAAAAAAbnVsbFRFWFQAAAABAAAAAAAATXNnZVRFWFQAAAABAAAAAAAGYWx0VGFnVEVY VAAAAAEAAAAAAA5jZWxsVGV4dElzSFRNTGJvb2wBAAAACGNlbGxUZXh0VEVYVAAAAAEAAAAAAAlo b3J6QWxpZ25lbnVtAAAAD0VTbGljZUhvcnpBbGlnbgAAAAdkZWZhdWx0AAAACXZlcnRBbGlnbmVu dW0AAAAPRVNsaWNlVmVydEFsaWduAAAAB2RlZmF1bHQAAAALYmdDb2xvclR5cGVlbnVtAAAAEUVT bGljZUJHQ29sb3JUeXBlAAAAAE5vbmUAAAAJdG9wT3V0c2V0bG9uZwAAAAAAAAAKbGVmdE91dHNl dGxvbmcAAAAAAAAADGJvdHRvbU91dHNldGxvbmcAAAAAAAAAC3JpZ2h0T3V0c2V0bG9uZwAAAAAA OEJJTQQRAAAAAAABAQA4QklNBBQAAAAAAAQAAAABOEJJTQQMAAAAABk4AAAAAQAAAIAAAACAAAAB gAAAwAAAABkcABgAAf/Y/+AAEEpGSUYAAQIBAEgASAAA/+0ADEFkb2JlX0NNAAL/7gAOQWRvYmUA ZIAAAAAB/9sAhAAMCAgICQgMCQkMEQsKCxEVDwwMDxUYExMVExMYEQwMDAwMDBEMDAwMDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMAQ0LCw0ODRAODhAUDg4OFBQODg4OFBEMDAwMDBERDAwMDAwMEQwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAARCACAAIADASIAAhEBAxEB/90ABAAI/8QBPwAA AQUBAQEBAQEAAAAAAAAAAwABAgQFBgcICQoLAQABBQEBAQEBAQAAAAAAAAABAAIDBAUGBwgJCgsQ AAEEAQMCBAIFBwYIBQMMMwEAAhEDBCESMQVBUWETInGBMgYUkaGxQiMkFVLBYjM0coLRQwclklPw 4fFjczUWorKDJkSTVGRFwqN0NhfSVeJl8rOEw9N14/NGJ5SkhbSVxNTk9KW1xdXl9VZmdoaWprbG 1ub2N0dXZ3eHl6e3x9fn9xEAAgIBAgQEAwQFBgcHBgU1AQACEQMhMRIEQVFhcSITBTKBkRShsUIj wVLR8DMkYuFygpJDUxVjczTxJQYWorKDByY1wtJEk1SjF2RFVTZ0ZeLys4TD03Xj80aUpIW0lcTU 5PSltcXV5fVWZnaGlqa2xtbm9ic3R1dnd4eXp7fH/9oADAMBAAIRAxEAPwD1VJJJJSkkkklMbLK6 q3W2uDK2Aue9xgBoEuc5x+i1q4HrP+MHKuvfR0eKcdp2jJe2bHx+fWx/sqZ/xjPU/wCL+grX+Mnq 7qqKekVGDf8Apr/6jTFLP7VrXP8A+srg6OVS5nmJCXBA1XzF6b4J8IxSwjmuYiJ8d+1jl8giP05R /S4nYGf1LIsbbdl3WWMcH1l9jnBrgd7XNrn0/a4fuL0/pOeOo9OozANptb729g9p2WtH9Wxrl5Xj 9l3f1Jyd+FfiHmize3+rYJ/8+MtTeUmfcIJ+YfiFfHcETgE4xEfal0HD+rn6Zf8AP4HfyshmNj2X v+jW0mPE9m/2nLlqX5W91oteyyxxe/Y4gFxO53t+itr6w3BmIynvdYBHk39If+k1qyqNvdO5qZ4x EH5R/wA4uXyUOHDKZF8Z/wCbFu43WMqlwblfpauC4CHj+V7fa9bVdjLa22VuDmPEtcOCCucu2xor XQcpwtswzqyDbX5agWN/tbt/+ejy+aXEISNg7E91vMcvEwOSEeEx1kBsYu2kkkrjnqSSSSU//9D1 VDyMinFosyL3BlNLS+x57NaJcdERcJ/jJ6y9vo9HpfDXj1soDuJ/QVu/tNdZs/4lMy5BjgZfZ5tr kOUlzfMQwg0JG5y/dxx+YtfG/wAYN5+sBuuBb0q2KhUeWMn25J27v0v51rf+t/mVr0Fj2WMbZW4P Y8BzXNMgg6tc1wXhK7z/ABffWPjomW4aScNx/wA+ygu/8Eq/zP8ARKpy3MEy4Zm+I6H+t2d7418G xxwDPy0OH2YiOSA/SxR/yn9+H6bn/wCMqf29TP8A3FZH+fcuYpMH5ruv8ZnTi6rE6mxv0CaLTrMO /SU/2WuF3/bi4Jhg/FQ8yCMsr66up8GyRyfDsPD+jEwl/ehJ1Md3C6z6k2kdTsrnSygkjzY9m3/z 49cZRYum+p10ddob/pGWN/6Pqf8AotDAayQ8x+LB8UxXy2bwhKX+J63f+s1/69RT2ZWX/wCe7b/6 KVGu+Am+tN8daLf3aax95scs9t+idmN5Z+f5OZy2D+jYtN43/jep0n3yOVZ6C/d1YR2qeT97Fiuy NOVt/VGl1l+RmH6DGilh8SYts/zW+ijhF5Y+d/Yt5rGMfLZZH93h/wAf0vTEgCTwuH6n9dMlnV2W 4WuDjF1bqyRF4JiyyfzPo/qjv++Xekr310656bD0jHJD7Gg5TweK3f4DT867/Cf8B/xy4W+xS8zz BEuCBrhPqPj2T8G+FxnA5s8BL3AY44S/cl/lP8L9B9ewszHzsSrLxnb6bmh7D8fzXfy2/Rejrz// ABedZLMy7pFrzsvm3Haez2ibmj/jKx6n/Wl6ArOHJ7kBL6Hzcn4jycuU5meE6x+bHL97HL5f+8f/ 0fVV459a7n3fWTqD7PpC4sH9WsCpn/QYvY15j/jE6S/E6wOoNE0ZwBJjRtjA2t7P7bdln/birc5E nGCOh1dv/i5lhDnJRlpLJjMYeYInwvKqTHvre2xhLXtIc1wMEEahzSop1nPZDUPqGHmVfXL6r347 i2rLLdlrQdG2tiym3853oWvY3/wWpeY21vqsfVYNtlbi17TyCDtcFp/Vnrj+idUryTudjP8AZk1t PLD+d/Wqd+kb/wBt/nrU+vnSKsfNr6tie/E6kPU3M1YLIDtwc32/rDT638v9MrGQ+7jE/wBOHpn/ AHf0ZORyeP7jzk+W25fmrzct2hlj/O4f8R5uqyF0H1Ru/wCyLAju94++q0LmVufU55P1lwB/Ld/1 D1Fi/nIf3o/m3efgDyvMH/VZP/ScnY+td0fWLJb+62of9Dd/35ZzchE+uVu360Zo8qv/AD0xZIyP NHKf1k/70vzafKYL5Tlz3xYz/wCNxdJ2Rp3J7Ack+AXanIH1X+rVbrgHZR0azkOvt3W7Jb/g6vd7 /wDRVLlvqf09vUep/abnBuL0/bfYSdC/U0NJkbWt2es//i1S+s/X/wBrdTfbW4nFpmvFGoG38+7a fzr3f+BempMcvbgcn6UvTD/upNXmOW+9czDlR/NYazcz/eP8zh/wv+g0r8h73OfY4vseS6x55c5x l73f1lSttlRsulCJJ5Ve3cx4hF0Pq897Ov8ATnNME5VQJHg57WuH9prl7OvK/qH0h3UOtsyHD9Bg Rc8/y/8AtOz/ADx6v/WV6otDkgRAk9To8r/xmyQlzWOEdZY4evw4zxRi/wD/0ruB/jPvpzslmfT9 pwnXvND69rba6y52yuPbXkbWbP8ARP8A+Eeuyc/oX1q6Y+llrMqh4BO0j1KnHcGP2u99Fzfds3s/ 8DXieXQ7DzsjDf8ASxrX1O76sc6v/vqsYGdlYOQzKw7XU31mWvafwP5rmO/PY72Kl78o2Jjii9NL 4VhyiOTl5exliBKMo/ISPlP9X/Adjr/1a6h0K/bePUxnmKcpohrv5LufTt/4NZMrt+k/4wcXLxXY H1kpFjLAGOvY2WuaeXX0t+jt+nvx/wDtpB639RQ+s9Q+rljcvEcC70Gu3OEf9x7Jd6/53s3er/xq inhErliPEOsf04uhy3xHJiMcPPx9rIfTDP8A+B83+H/k5vHLtfqtlVde6Nk/VrPeDcxu/p736kQP aGaf9pn/AMvf6FllX8zWuLc1zXFjwWuGhB0IPmj9Pzb+n5tObR/O0PD2gzBj6THR+Y9vseosc+CW vyn0yHeJb3O8v94wmMTw5YEZMGT9zND1Ql/3MkeRj3Y19mPe3ZdS4ssboYc07XDRbP1Ibu+tGCPO w/dVaVsfXXplGfhUfWjpzSa72N+1CdQCGsqsLW7m76/5i/8ASf6P/hFmfUGov+s2O7/RMscfmx1f /oxPGMwzxjuOKJie8WtPm48x8Mz5a4ZjFlhlh/m80YSjOH+Mr6+tLfrNknjeyo/9Brf++rBqbdbY yqppsssIaxjRJLidrWtA/eXS/wCMZm36wg/v0MP4vb/31WPqN0imqu/6x9QaRjYbXOx5HJaCbbmt /P8AS+hX/wAL/wAJUjLGZ55RH7xJPaKMHNx5f4VgzSHERihCEOuTLXBCAT/WC7/m19XMfoGOW/bM 1pfm2NOsGBb+77bXfq9b/wDQUvXEEkq11bqNvU+pZGfbo695cG87Wj21VyA3+brDWKqAXENaJJ0A HJKjyz4pafKPTEf1Q2eR5Y4MPrN5shOXPP8Aey5Pm/wYfJFZanQfq9ndcyhTjtLKWn9NkuHsYP8A v9v7lX/ov9Itvon1Etcxuf154wsJo3uqc7Y8jt6zne3HZ+9/hv8Ailc6j9esDp+I3p31boDWVAsb c9sMaP36mH33Pd9P1L/z/p+tvT4YQBxZTwx6R/Tm1uY+IzySOD4fH38vyyzf+BuX/vZP05/1Hp8d nRfqv0xlL7a8algJc95h9rwP0lm3+cutd+6z+ouU6n/jHvuurr6ZSaKQ9pfbZBe5oLdzBX7mVfnf nW/9bXIZudmZ+Q7JzLXX3P5c49udrR9FjP5DEOis3X10t1dY9rAPNx2p8+akajjHBHYfvMHLfAsM DLNzcvvOaVykZfzYl+keH9P/AKo//9N/8Z3QLcXqY6zSz9VzNrbnD828Dbq2Pa26pjHf8b6q41j1 7/m4WLn4tmHmVNux7m7bK3cEf99c13uY9v0F5Z9Yv8XHVem2G7pQf1HDMna0D1ma+1jqx/SPb/hK W/8AWa1VzYTZkBdu78M+IxEY4skuGUdIk7Sj/wB8801y0uj9c6l0e/18G0sLo9Ss6seB+bYz87/q 1lWMux7XU5FbqbWGHV2NLHA/ymPhyk148VUIMTY0IehjPHlgYzEZwkNYy9UZPoVXV/qx9bWV09aY MDqQAa3IYdod+dDbnhzNuntqyf8ArNnqLF639SusdJD7mt+14jJcb6uWtE+62n6dftG5/wDOVM/0 q5sOC6P6v/XbqfR4psJzMMQPRscdzABtAos93pt/4P8Am0/jhPTKKP8AnI/93Fr/AHfmOV9XJT48 fXlMx9H/AKb5f8l/ddj/ABe9TquryegZh31Xtc6it3BBBblUjX85n6TY3/hlZ+rfQLOjfXK/GO51 Axn241rolzC+pnu2/n17vTf/AJ60MTB+rXX7aOr9IeMXNx3stf6IDHgzudXl44+l6n6Rnqf4T/S2 1rp9rdwdA3AEA94PP5FZx4rjCyD7ZuEx+lHs4fO/EOHJzHtwlj+9w4OZ5fIOE4s8f8rH+88N9bei 39Z+t2HiV+1jsVrrrP3a2WW+o/v+81lf/CKP1/6hXgYGJ9XsM7atjXXN1JFdcNxmbj+89m9/5/6J i7va3dugboie8Lms/p31c6Rk5HWutWDKyshzn1NuhxhujKcXG/PdUz0a/Uf9D/gUsmKhMgge4fVM /owRyXxASyctHJCWSPKRrBgxjjln5k7ZP6vA8V0T6ndY6vstaz7PiOInIt0Bb+9VX9O72/Q/wX/C refnfVb6oiyvpzf2h1dssdY8yGH87dY0emxrfzq6P0v+Ctesn6wfXjqPVZoxd2Fh6gsY473g+39N Y2Pbt/wTP+uequalVeOGPTGOKX+cl/3EXoByvM836udl7WI/+BMJ+b/zpzf5T+5B0esde6n1m4W5 tstb/N0t9tbf6lf738t36RZ6aVKqq26xtVLHW2OMNYwFzif5LWqEkyNk2S6MI48UBCEY44RGkY+m MWK6j6g9Efn9Vbn21k4mEd4fw03CDVX/ACvT/nvb/wAHv/nE3QvqH1XqFgsz2uwMUEbt4i137za6 nfQ/4y3/AMFXpODg4uBi14mJWKqKhDWj8XOP5znK1y/LyMhOQqI1AP6ThfGfjOOGKfL4JCeWY4Zy ifTiifm9X77/AP/U9VWJ9aPrFd9XsWvMGC/MxnEtusY8NFRO30vU9r/ZbLm+p+//AMbWttBy8XHz Ma3EyWCyi9hrtYZEtcNrhLYc3+ygbrQ0V2MxEwZx4o36o7aPAW/42cawQ7pBsHg+5v8A6RchD/Gl iH/vDr/7eb/7yrG+tP1E6n0S2zIxmOy+mlx2WMBdZW2N23KY0e3b9H12/ov+J9T0ly0jxVWWTKDR NfQO9g5TkckRKEeKJ/rz/wC+fQz/AIzqHfQ6NU342g/+67Umf4xMzIsbTidIofc8wxgDrHE+DWVt a5ywvq99Ruu9Z23Fn2PDJg5F4IJGkmmj22W8/wDB0/8ACr0/oP1Y6T0Ks/Y65ve0NtyXmXuA1/q1 s3fmVIxjmlvLhHkFnMZfhuAVHF7uX93jycI/vy403RW9V+zm3qlWPj3WQW047TLR+7dY5722P/4v /prRSSVkChTiZJ8cjKhG/wBGPyjyUqPV29ROL6nTaqLsmuSKsgGHCNa63tcz07Hfy/0avJJEWKVC fBISoSo7S+U+b53Z/jAzsW11GZ0mll1Zh9Z3McO/0Xtcnb/jLr/O6RWfhaB/6Icux6z9Xul9aqDM 6qXsBFdzDtsZP7rv++Wb615v136j9Z6SDbW37biD/C0g7mjxuo9z2f1merWqmQcxDUS4o+Qt6Hks nwnmQI5MIw5f3TkyRhL/AGc+P/muz/45mP8A+U7P+3h/7zojP8aGMzQdMLZ522j/ANJNXnpeFv8A 1b+p/Uut2stex2P08EGy942lzZ9wxtzT6j/5f80o4Zc8jQN/SLb5j4f8LxQM8kOGI75Mv/fvov1a +sbuv1XXtw341FRDW2OduD3Gd7WQ1v8AN/nf11toGFh42Bi1YeKwVUUt2sYPD/vznfSe5HV+IIA4 jZ6l5XPLHLJI4oe3jv0QviqPiZP/1fVUlwv1F/xi5f1p6xd067Crxm047r97HlxJa+qrb7mt/wBM uw6nluwum5eYxoe7GosuawmA41tdYGl2v0tqSm0oejT6nq7G+rEb4G6PDd9Jcj9Qvr1k/WsdQN2I zG+wtqLdji7cbPW53D/gVW+on+MTL+tXVbsC7Crxm045v3se5xJD66tu1zf+FSU90ks36x9Vs6N0 PM6pVWLn4tfqNrcSAdQNXBY/1C+uWR9bMXLvvxmYv2axrGhji6dzd2u4NSU9UkuW+vn11H1Tw8Wy ugZWTl2FtdTnFrQxgBus3NDvoufUzb/wih9Q/r3V9bKslltTcXNxnAmhrtwdU76NzN21/ts9lv7n 6L/SpKesSXC9W/xi5fRvrhX0HqGFWzDtsrDczeW/oroay8h42babD+m/4q1df1bPb0zpeZ1Fzd4w 6LL9kxu9NrrNm7+Xt2JKbaS83+qv+Nq3rXXcXpeZhVYteUXMbc2wmLNpdU3a9v8AhXt9H+vYu1+s vW6+g9Dy+q2N3/ZmSyvjdY4iuln9q17NySm+aKDaLjWw2jQWbRuj+v8ASRFyX1T+u56v0HM6/wBX ZT03BxbDWH7nGdrWOe87m+7e+6uqllf6Sy39GsD/AMd3qOflW09A6BdnMq13Ave8s4bY+jGps9H/ ALdsSVZfTEl59gfX366ZOfjY9/1WyKKbra67bnV3gMY5zW2WuLqQ32MO5Wfr5/jDy/qr1PHwqcOv JZfQLi973NIO99e3a1p/cSU//9bkPqH9YMvoHW78zE6dZ1SyzHfSaKi5rmtNlNnreyrI9rfS2fQ/ wi7Tqf8AjM63l9Ny8V/1WyqWX0WVutL7CGBzHNdY79Tb/Nt9/wBJY/8AiYa5v1sy9zS2cG2JEf4b FXrH1hn9gdSjn7JfEf8AFvSU+b/4kOOuf1cb/wB2ln/4k/8AxS5n/hJ3/n3HWl/iOaQ7rQcIkYvP gftSxuijqn+LX60W3dUwrcjCsrdjnIqadr63OrtbdjvdtqfY30m/oX2JKfT/AK//APiN6t/4XP5W rlP8SH/JnU/+Pr/6gql9bP8AGdhfWHol/Ruh4OW7JzdrHOsYzRgc179jKH5LrXWbPS/wahhVZv1H /wAXWYc1pp6t1ywsxaGki1jH1hm+xo99VtNXr3e3+ae/Hrs9O1JTXd1Cr62f4zm5F+VVT0npFgdV Y+xnpmvGeNnpvdtrt+3Zf6T/AML2f8CgZPUMT6nf4yzn4VjLOlZp32ei9jm+jkH9Yb+i3NZ9my2O uro/4CpXfqX/AIqendY6BT1Pq92TTdlFz6a6HMaBT9Gp1jbqLffZtfb7X/zL6kvrr/iq6d0boF3U +kW5V92K5r7q7nMePR+ja9jaaKnbq3OZY73bPR9VJTe/x1dC9XFw+vVNl2OfsuTEk+m8mzHf+61l dvqs/wDQhil9b/rY3I/xX4NrLC/J6u2vHtcTD91X9PfH5zPWx/Rd/wCGFb+qtx+un+LvJ6Hlv/Xs dn2UueYMs23dNyLNg3+nuZXW/wD032e5eXdOxuodSzenfVy/eykZprALfdW691NOX/223G3bP+MS U7XXui/82+m/VPruKP09tTb7fbA9Vr29QodY8fSs9PJ9D/i8VdT/AI3vrBjZX1f6Ti4ji8dTc3Na QQD6LWfohZX9L9M/J9n/AIXeul/xk9DZ1P6nZVVLALOngZWO0GABSD6rYH0v1R17WM/f2Lyv6ldP y/rJ9Zuk4WZL8XpzJMiIope/KFTv32vyL/R/qWpKeu+vXTn/AFb/AMWPT+j1wHPvqrzCDIc9zbs2 /wB35zftNXs/kLI+o/1xzPq/0UY+D9W7843WOfbnVueBYQdrW+3Fv/mW/o9vq/8AnxekfXn6uWfW P6u39PoLRlBzLsZzzDQ9h7kT9Op1tX9ted/Vb67dY+pVFnQeudLvfTTY40x7H17jutY3cPSyKH2f parGP/P/AMLXZX6aU9Lgf4zOtZWdjYtn1XyaGZFrKnXOfYQwPc1hsdOGz6G7d9Jcx/jt/wDFBg/+ Ex/58tXT4P8Aje6dm52Nht6bksdlXV0te4sgGxzag4/5y5r/AB1se76wYO1pP6mOBP8AhLUlP//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgADcALgAwAAAAAQA4QklNBAYAAAAAAAcAAQAA AAEBAP/hEkhodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvADw/eHBhY2tldCBiZWdpbj0n77u/ JyBpZD0nVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkJz8+Cjw/YWRvYmUteGFwLWZpbHRlcnMgZXNj PSJDUiI/Pgo8eDp4YXBtZXRhIHhtbG5zOng9J2Fkb2JlOm5zOm1ldGEvJyB4OnhhcHRrPSdYTVAg dG9vbGtpdCAyLjguMi0zMywgZnJhbWV3b3JrIDEuNSc+CjxyZGY6UkRGIHhtbG5zOnJkZj0naHR0 cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIycgeG1sbnM6aVg9J2h0dHA6 Ly9ucy5hZG9iZS5jb20vaVgvMS4wLyc+CgogPHJkZjpEZXNjcmlwdGlvbiBhYm91dD0ndXVpZDpl NjUwZWE2NC1kNjdhLTExZGEtYmI1YS1lMmZlYThiNzYxZTMnCiAgeG1sbnM6eGFwTU09J2h0dHA6 Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9tbS8nPgogIDx4YXBNTTpEb2N1bWVudElEPmFkb2JlOmRv Y2lkOnBob3Rvc2hvcDplNjUwZWE2Mi1kNjdhLTExZGEtYmI1YS1lMmZlYThiNzYxZTM8L3hhcE1N OkRvY3VtZW50SUQ+CiA8L3JkZjpEZXNjcmlwdGlvbj4KCjwvcmRmOlJERj4KPC94OnhhcG1ldGE+ CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAo8P3hwYWNr ZXQgZW5kPSd3Jz8+/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8VGBMT FRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsNDg0QDg4QFA4ODhQU Dg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgBLAEs AwEiAAIRAQMRAf/dAAQAE//EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUBAQEB AQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJxgTIG FJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePzRieU pIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYFNQEA AhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNUoxdk RVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//aAAwD AQACEQMRAD8A9VSSSSUpJJJJSkkkklKSSSSUpJJJJSkklm9d67h9Ewzk5J3PdpTSPpPd4D+T++9A kRBJNAL8WKeWcceOJnOZqMR1buRk4+LS6/JsbTUwS57yAB965XqP+MTCqca+m0uySNPVf7Gf2W/z j/8AoLiur9e6h1rIN2W/2A/oqG6MYP5Lf3v5aqsCo5eckTWP0jv+k9Ryf/F3FjiJc0fcn/m4nhxx /wAL5pvR5H106/kyG3Nx2ntU0Aj+2/e5Ubc/PyiTkZNts8hzyR/mztVJgR2BV5ZJy+aRP1dCPLYM X83ihD+7EA/4z6H9UuqOzumiq1034sMcTyW/4J//AHxbi89+quacPq1QJivI/RP+f82f89ehLR5b Jx4xe8fSXk/ivLjDzMuEVDJ+sj9fmj/jKSSSUzQUuT6lm2ZWa6xji1jPZXBjQfnafvLf6xknHwXl ph9nsb8+f+iuYYxVObntAf3j+x0vh2IASykf1I/902KeodQqjbe4gdne4f8ASV6jr+S3S6ttg8W+ 0/xas9rFLYq8cuSO0i2cmLDP5oR+g4T/AM16LF6li5WjHbX/ALjtD/5krS5IsI1GhHBWp07q7gRR lGQdGWn8j/8AyStYuZBNT0Pfo0c/JUDLEeIdYn5vo7KSSSstJSSSSSlJJJJKUkkkkpSSSSSlJJJJ Kf/Q9VSSSSUpJJJJSkkkklKSSSSUpJJJJSHLyqMPGtysh2ymlpe93kF4913rOT1nqD8u4kM+jTX2 Yz81n/k12H+Mrqrq6Mfpdbo9b9LcB+60xU3+0/c7/ra8+WfzmUmXANo7/wB567/i5yMYYfvUx+sy 2Mf9TEP+/SMR2IDEdiqu5NsMVhirsVhiLVm2KyWkObo5pkHzC9OwskZWHTkD/Csa75ke5eYsXc/V HI9XpfpE60PLY8j+kb/1StcnKpmP7w/6Lg/HMXFhhk645V/gzdxJJJX3nXA+sN27IqoHFbdx+Lv/ ADlZ7ApZ13rZ11kyNxaPg32j8iTFmZZcU5HxdvFDgwwj2GvnL1FKxqIGJmIwiE1ZKRtruagvarT4 Vd6C+BdbouebWnFtMvYJYT3b4f2VqrkK7nUXMuZ9Jhn+8Lra3tsY2xurXgOHwKvctk4o8J3j+Tn8 7hEJicfln/0urJJJJWGopJJJJSkkkklKSSSSUpJJJJT/AP/R9VSSSSUpJJJJSklC22umt1trgytg LnvdoABqXFeX/WX645fUc9hwbHUYmI8OojQue3/Dv/74xRZc0cYs6k7BvfD/AIbm53IYw9MYi55J fLH92P8Aek+ppLH+rP1gp65gC3RmTVDcirwd++3/AIOxbCkjISAkDYLVzYZ4cksWQcM4HhkFJJJI sb5L9d8o5P1kytfbTtqb/ZaN3/T3rBWn9ZST9YOoT/3Is/6pZix8hucj/WL6NyURDlcERsMcB/zE jEdirsR2FNZJtlisMVZhR2FFqzDZYup+pd5GRkUdnsa8fFp2/wDf1yrCtz6q3en1ioTAsa5h+7cP +pUuA1kifGv8ZzPiOPj5bKP6pl/iev8A7l7tDvs9Kiy39xpd9wlEVDrdvp9LvMwXANH9ohq0pmoy PYEvK4o8eSEf3pCP2vLsdOp5OpVhhVRjkZrllvQTi22uRN6qtep70mAwSuegvcmL0Nz0l0YMXldJ 0O02dNrnlhLPuK5d7l0f1bM9PP8Axjv++qflT+s+hYfiEf6OD2kHVSSSV9x1JJuNSuD+s/1jty8p tOFYWY+M7c2xpgusb/hP6jPzFHlyxxxs69g2uS5LJzWTgh6QBcpn5Y9nvUlh/Vn6xM6tR6NxDc6o fpG8B4/0rP8Av63E6ExOIlE2CxZ8GTBkliyDhlH+XFFSSSScxKSSSSU//9L1VJJJJSkklh/W7rv7 G6U59ZjKyJrxx4GPdb/1pqEpCMTI7BkwYZ5ssMWMXPIeEPMfX76zG+13RsN/6Go/rTx+c8f4H+pX +f8A8IuKSLi4lziS4mSTySUlk5MhySMi+g8lymPlcEcOP9H5pdZz/SmXQ6J1nJ6N1BmZQZA0tr7P YfpMP/fV7BgZ2N1DEqzMV2+m5u5p7jxa7+U1eHrp/qT9Zf2VmfY8p8YOSdSeK7Do2z+o76Nim5XP wHhl8sv+aXN+O/DPvOP38Q/X4hqB/lcf7v8Afj+g+opJk60XjHx/630up+sme0/nWbx8HgWf9+WO uu/xk4fpdXpywPbk1AE/yqztP/QdWuRWRmjw5JjxP4vofw3KMvJcvMf5uMT/AHoeiX/Oiu3lHYUB FYUxsyGjZYVYYVVYUdhRa0w2mFaPSLhV1LFsPAtZPwJ2/wAVlscrFFmyxj/3XA/cZRiaIPYtTNDi hKP7wMftfVVi/Wm3bgVs7vtH4BxWyCCARwdQuc+uFgAxa51l7o/zQtPmDWKXl+byPIR4uaxjxJ/x Y8TiNciteqjXorXrNeglBtB6l6irB6fekxmCcvQ3PQy9RL0kiDJzl1X1dYW9Lrcfz3Od+Mf99XHO eu86fR9nwaKYgsY0H4x7v+krPJi5k9h+bS+Knhwwj+9K/wDFH/oTYSSWb17rFfSsI2CDkWS2hh7u /fP8hiuykIgyOwcjFjnlnHHAXKRoByfrf100MPTcV0W2D9YePzWn/B/1rP8AqFxDyi32vtsdZY4v e8lznHkk8lV3lZeXIckjI/Qdg9lyPKR5bEMcdTvOX7818fMyMLJrysZ2y6o7mu/K138l35y9S6J1 ejq/T2ZdXtd9G2vux4+kz/yK8leVq/VPrp6R1VosdGJlEV3jsD/g7v7Dv+gn8tm4JUfllv8AxY/i 3w77zgM4D9fiFx/rw/Sx/wDePqiSSS0njlJJJJKf/9P1VJJJJSl5L9dernqfXLWsdOPiTTUO3tP6 V/8AasXpvWs37B0nLzO9NTi3+tG1n/TXiZJJkmSeSqfOz0jDvqXo/wDizywM8vMEfJ+rh/el86k6 ZOqL1QUkkkkl9J+oX1k+24w6VlOnJx2/oXE6vrH5v9er/wA9rr14biZV+Hk1ZWO7ZdS4OY7zC9h6 F1ijrPTq8yr2uPttr/cePps/8itDlc3FHgl80dvGLx3x/wCG+xl+8Yh+qyn1Af5PL/3uRxv8YnTz k9EblNEvw7A4/wBR/wCjf/0vTXmK9yzMWvMxLsW0TXex1bvg4bV4nmYtmJlXYtoiyh7q3fFp2qHn YVIT/eFfUOj/AMWeZ48GTlyfVilxx/2eT/0NCpsKgnGiqvQNhjkdjlUY5HY5JhnFtscih2hVVrkV rkWvKL61hO34dD/3q2H72hcx9c7P13Hb4VE/e7/zFdD0Sz1OkYb/ABpZ/wBSFyn1zt/yuxv7tLfx LytDmD+oHjwvJ/Dcf9PkP3Pc/wC9cxr1MPVVr1MPVB35QbQen3qsHp96SzgTl6iXoO9MXpJEG/0u g5nUaKOWl4c/+q33u/Iu/XLfUzE3G/OcP+Cr/wCrsP8A1C6laHKwrHf7xv6PP/FsvFzHANsQ4f8A Dl6pI8i+rGoffc7ZXWC5zj4BebdZ6rb1PNfkv0b9Gpn7rBwP/JrW+uHXPtF37Ox3foaT+mcPznj8 z+rV/wBWuXc5Qc1m4jwD5Y7+MnV+Dch7UPfyD9ZkHpH7mP8A76az3IL3J3uQXuVV3YRYvcgPKm9y C4yUGxAPrH1K6sep9Er9R26/F/Q2+J2j9G/+1Wt9eb/4ts01dVvwyfbk1bgP5VZn/qHPXpC1OXnx 4ok7j0n6PC/GeWHL87ljEVCf62Hlk/8AQ+JSSSSmc5//1PVUkkklPOf4wLHM+rN4Bje+tp+G4O/7 6vKAvWfr7S636sZO0SazW8/APbP5V5MFn85/OD+69f8A8WyPucq392V/4sF06ZJVXdC6SSSS5S3f qj9YHdF6kPUJ+x5EMyG+H7t3/W/+oWEkjCRjISG4Ys+CGfFPFkFwmOE/x/wX3drmuaHNILXCQRwQ V5x/jG6T9n6hX1KsRXljbZHaxg/7/X/1C1f8X31h+0456Rkum6gTjE8urHNf/Wv/AD3/AFF0H1j6 SOr9IvwwP0pG+k+Fjfcz/O+gtGdZ8Njfcf3h0eN5Yz+F/EhHIfRfBOXSeDJ8uT/u3xpJO5rmOLHA tc0w4HkEJlmvbsmmEVrkBSa6EkEW2muRmuVRrkVr0mGUH1n6su3dAwT/AMEPwXJfXJ/+XXjwqr/I V1P1TM/V3BP/AAf/AH5y4/66Pj6w3DwZX/1Kv8x/ueH+D/0Xlfhkf+FOYHb3f/Srmh6kHqqHqYeq LvmDZD0+9Vt6fekt9tsb0zS572sYNz3kNaPEnQBA3rf+pnTjl9ROW8TTiajwNh+h/mfTT4RM5CI6 li5iccGGeWW0BfnL9GP+E9n0vCbgYFOKOa2+8+Lj7nu/zln/AFo62Ol4Wyo/reRLav5I/Pt/s/m/ y1q5WTTiY9mTe7ZVU0ue7yC8s6t1W7qedZl26bjFbP3WD6DFe5jKMcBGO5FD+rF5/wCF8nLm+Ylm y644Hjnf+UyS9XB/37Xc+eTJPJQnPUXPQ3PWc9dGC7nILnJOchOcgzRipzlBJJJldv6mWOr+suCW mNz3NPwcx4Xrq8k+pNLrfrNh7Rowue74NY5etrQ5L+bP954//jPX3vH39oX/AI81JJJK04L/AP/V 9VSSSSU1uo4bM7AyMN/F9bq/m4QCvELarKLX02jbZW4se09i07XBe8Lzb/GJ0E4uaOr0N/QZR23x +baB9L/rrf8ApqrzeO4iY/R38ne/4u82MeafLyNDNrD/AGkP0f8ADi8cnTBOqD1oXSTJ0Fykkkkk psPLvwsqrLx3bLqXB7D5heydG6rR1fp1WdTp6gixn7rx/OVn+qvFV031G6/+zOpfZL3RiZhDXTw2 ziuz/vj1Y5XNwT4T8svzcf478P8AvPL+7AfrsAMh/Xx/pw/7qDP6/wDRfsPVfttTYx82XacCwfzr f7f84uWXsv1i6QzrHSrsQx6sb6HeFjfof530F45Yx9b3V2AtewlrmnkEaEIc1i4J2Pllr9eqfgPP feOVEJH9bgqEv60P8nP/ALlikkkoHXZB0IjXoKcGEkEW+v8A1Q1+rWB/xZ/6py4r67uj6yXj+RV/ 1K7T6of+JrA/4s/9U5cP9ezH1lv866v+pV7mP9zw/wAH/ovKfCRfxfmh/tv/AEtFyA9SD1WD1IPV F6QwbO9Leq+9Leit4GwHOcQ1oLnEw0Dkk8BepdA6YOl9LqxiP0pG+4+L3fS/zfoLi/qL0n7d1E51 rZowoLfA2n6H/bbf0n+Yuv8ArP1tvRumPvaR9pt/R47T3efz/wCrX9NXOViIRlll9PJ5341llmz4 +Rw+qVgz/wBpL5I/4EPXJ5r69dd9a8dKx3foqSHZBHez82v/AK1/1a5EvQ32ue4ve4uc4kucdSSd SSoF6q5MhnIyPV3uT5OHLYYYo/oj1S/fn+lJI56G56gXqBJKY2xBk5ygkkkvUkki42PdlZFeNQ0v ttcGMaO5KSCQASTQGpJey/xadOLsnJ6k5vtraKaz/Kd77P8ANa1v+evQVQ6H0qrpHTKcGvUsE2P/ AHnnWx6vrWwY+DGI9dz5vn/xPm/vXN5Mo+S+HH/s4emP+N86kkklI0n/1u4v+uXRcbrNvSMqz0La tv6Z382XOG/YX/4Nzd3563Gua9oewhzXCQ4GQQfBeEdcy3ZnWs7JcZ9S+wj4bi1v/RV3oX1r6x0V wGNbvx/zsayXVn+qP8H/ANbVYczUiJDS9CHcn8E4sUJYZVk4RxQn8spV6uGX6L7WgZuHj52LZiZL BZTc3a9p/wBfpNWF0H69dH6ttptd9jyzp6Vp9rj/AMFb9F39pdIpxKMxoQQ5GTFm5fIBOMsc4mx9 P0oyfHPrJ9W8voOWWPBsxbCfs98aOH7j/wB21qyF7lnYGJ1DFfiZdYtpsEFp/wCqafzXtXlv1n+q OZ0Ow3VzfgOPsuHLZ/Mvj6P9dUc/LmHqjrH/AKL1fwn4zHmAMOYiOcaA7RzeX+s/quAnUU6qu4F0 kkklykkkklPqv1J69+1elim505eJDLJ5c3/BW/8AfXrm/wDGH0P7LmN6rQ2Kco7bgOBaB9L/AK61 YH1f6xb0bqlWY2TXO29g/OrP0x/39q9Zz8PE610t+O4h9GVWCywaxPuqtb/V+kr0D7+EwPzx/lF5 XmYn4V8SjzEB/Rs98UR0Ev52H+B/OY3xRJHzsK/Ay7cPIbttpcWuHw/OH8l30kBUSKNF6mMhICUT cZCwR1BUkkkkl9h+qYj6uYH/ABQP3krg/wDGDp9ZLD41Vn8F6B9WW7fq908f8Aw/eJXBf4xWx9YZ /eorP4vH8Ff5j/c8f8H8nkvgx/4Xz+Pvf+lHmQ4pw9QSVB62km9EortyLq6KWl9trgxjR3c4w1V1 3P8Ai66Dve7rWQ32smvFB8eLbf7P823+2n4sZyTER9fJqc/zUOU5eeaX6IqEf38h+SL2HRumU9H6 XViNI/Rt3W2cbnn3W2FeZfWrrx6x1V9jHTi0zXjj+SD7rP8Arrl1/wDjA679iwB02h0ZGYP0hHLa vzv+3fof9uLzRWObyAVijtHf9gcj4BycpcfP5vVkzGXt32P85k/w/lZF6aSmSVR6JSSSSSlJJIuN jX5V7MfHrdbdYYYxokkpIJABJNAaklG1rnuDGAuc4w1o1JJ7BemfUv6pnpdf7Qzm/r1ohjD/AIJp /wDRr/z1P6qfUynpIbmZu23PI9o5bVP7n71n/CLqFf5bluGpz+boP3Xk/jPxr3hLluWP6rbJl/zv 9SH+r/6aklV6h1PA6bQb825tLO27knwYwe5/9lcJ1z/GJlZG6jpDDj1HQ5D4Nh/qN+hUp8maGP5j r+6PmcvkvhvM82f1UPR1yy9OOP8Ahfpf4D2nVuv9L6PXuzbg15Etpb7rHf1a/wDvzlW/50Yf/N79 u7D6X+hkbt2/0vTn95eSW3W32Otue6yx5lz3Ekk+bitb9ov/AOaf7PnT7Zuj+Ts3R/24qo508RPD 6QNuu/d3Jf8AFnGMUIjKTmlL1ZCPQI8E/THH/f4H/9fjN5c4udqXGT8SptKn1Gk43UcrHIj0rrGR /Vc5qE0rOkHtMU7APdKCul6D9eOr9J21WO+2Yg09G06tH/BW/Sb/ANQuYBUwUwSlE3E0zzxYs8OD LATieh/7n919p6J9aekdaaBjW7MiJdj2e14/q/6T+wtayuu2t1djQ9jxDmuEgg9iCvBGPexwexxa 5plrgYIPkV2HQf8AGJn4e2jqgOZjjT1Rpa0fH6N39v8Az1ax80DpkFePRw+c+ATjeTlZcYGvtyP6 wf3J/pN36zf4v3MLszojS5nL8OdR/wAQT9L/AItcO5rmOLHgtc0w5pEEEdiF7X0zrHTuq0etg3tt b+c0aOb5WVn3MWf9YPqj03rbTYR9nzI9uQwc/wDHM/wn/VpuXlRIcWOten6J/usnIfHcmCXsc6JV H0+4R+th/tY/p/8ATfI060es/V/qfRbvTzK/0ZMV3t1rd8HfvfyHLNVKUTE0RRenxZYZYCeOQnCW 0omwukkkgyKXof8Ai66562O/pF7v0lA3488lh+nX/wBbcvPFZ6dn39Ozqc3HMWUODh4EfnMP8l7f apMOQ45iXTaXk0/iXJjm+Wni/T+bGf3ckfl/717v/GH0H18dvWMds20Dbkgd6/zbP+tf9R/UXna9 vxMnF6n0+vIrizHyq52nXRwh7Hf9Q9eT/Wfob+i9UfjgH7PZ78Z57sP5s/vV/QU/N4tRkjtLf+Ll f8XueJjLks2mTDft8W/APnx/3sbkJJJKo9C+2dGZs6RhN8Meof8AQauC/wAZbI6xjv8A3scfg969 DwmbMOhnG2tg+5oXBf4zmRnYL/Gp4+53/mS0eZH6jy4Xi/gc7+KA/v8Au/kZPFJJJLOe0b3RulX9 W6jTg06eoZe/91g/nLP7LV6+BhdI6bpFWJh1/c1o/wCqcsP6jdA/ZnTvtd7YzMwBzgeWV811/wBr 6b1l/wCMfrcCvo1DuYtyo8P8FV/6M/7bV7FEYMJyS+aX8oxeU57LL4p8QhymI/qMRPFIf1f57L/6 jxvH9X6nd1XqN2dd9K13tb+60aV1j+q1UkklRJJJJ3L1MIRhGMIDhjACMQOkYqSSSSXKSUmMfY8M Y0ve4w1rRJJ8gF2f1e/xfXX7crrM01ctxRo8/wDGu/wf9X+c/qJ+PHLIaiL/ACa3N87g5WHHmmI/ ux3nP+5F53on1e6l1q708RkVNMWXu0Y3+1+c7+Q1endB+rXT+h0xQ31Mhwi3Id9I/wAlv+jr/kLS x8fGw6G00MbTRWNGtENAC5rrv1+6dgbqMCM3JGkg/omn+VYP5z/ravQxY8A4pkcXf/vQ8tzPPc78 Vyezy8JRw/uR/wClnyPTZGRRjUuvyLG1VMEue8gAfMri+u/4xa2bqOjM9R3BybB7R/xVf53/AFxc d1XrnU+r2+pnXF4H0axoxv8AUrCoKDLzkjpD0jv+k6fIf8XMWOp80fen/mx/Mx8/84nzM7Mzrzfm XOvtP5zzPyb+6gJJKqSTqXejGMQIxAjEaADQBSLud9l2/m+pPzhCWh9kd+wPtke37X6U/wDW96IG 6JSAMR3ND/FkX//Qzf8AGH092F9aMl0fo8sNyGH+sNtn/grHrnGlerf4zuhuzuks6lS2bunkl8cm p385/wBtu9//AG4vJ1SzRqZ8dXpfh+f3OXgb9UBwS/wUzSpgoLSiAqEh1Mc0oKkChgqQKYQ2YybW JmZWHe3IxbXU2t4ewwV3XQf8ZDXbcfrTNp4GVWNP+u1D/qq/+2156CpAp0Ms8Z9J+nRi5rkeX5uN ZYWf0Zx9OSPlJ90nB6liaenlYtw8nscFxXX/APF0RuyeiukcnEef/PNrv+os/wC3FyHSeu9T6Pd6 uDcWA/TqOrHf1616J0H6+9M6ltozIwso6AOP6Nx/kWH6P9WxWRkxZhwzHDL+XyycOXJfEPhkjl5W RzYd5Rq9P9bh/wDUmN8yvovxrXU5FbqrWGHMeCCD8CoL2jq3Qul9Zp9PNqDyB7LW6Pb/AFLF5713 6h9T6buvxJzcUaywfpGj+XV+d/1tQZeVnDUeqPhu6nIfHeX5ioZP1GX92R/Vy/uT/wC+eZSS1Bg6 EJKu7D3X+LjrW19nR7naOm3Gnx/wtY/8+f8Abi6X61dCb1rpb6mgfaqZfjO/lD/B/wBW36K8mw8u 7Dyqsqg7baXh7D5gr2jpmfT1LAozqfoXsDo8Dw9n9h/tV/lpDJjOKWtf9H/0F5T45gnynN4+ew+n jNn+rnj/AOrYf+pHxN7H1vcx4LXtJa5p0II5BUsdm/IqZ+89o+8rsv8AGF9XvSt/bOK39HaQ3KaO z+G3f9c+i/8Alrlui1et1jCq/fvrB/zmqpPGYZOA99HoOW52HMcp94hp6SZx/cnAeuL7UBAjwXD/ AOM+v9F0+zwda37xWf4LuVx/+Myrd0nGt/cvj/Oa7/yC0OZF4Z+Tx3wWXD8RwHvKUf8AGhKL5uul +o/1f/anUftV7Zw8Qhzp4e/mur/v9iwsDByOoZlWHjN3W3ODWjsPFzv5LW+5ex9I6XR0rp9WDQPb WPc7u55+nY7+s5U+Vw8cuI/LH8S9J8d+I/dsHtYz+uzCh3x4/wBKf/cwSdSz6enYN2bd/N0MLiPE /msH9d3tXi+bmXZ2Xdl3ndbe4vcfj2H9Vdj/AIx+tb7auj0u9tcW5Ed3Efomf2W+9cOjzeXinwDa P/SWf8XuS9nlznmP1mfUf1cI+X/H+dSSSudN6T1Dql/oYNLrXfnEaNaPF7z7WKsASaAsu1OcYRMp yEYx1MpHhiPq01s9D+qvVOtODqWeljT7smwQ3+x/pXf1V2HQv8X2Fh7b+qEZd41FQ/mmnz/Ot/te xdF1DqnTekYwty7W0VgQxg5Mfm1Vt+krePlNOLKeEdv4lwOc/wCMFy9nkYHNkl6Rkq43/q8f6bT6 F9Vel9FaHUs9bKiHZNgl3/W/9E3+qm659a+ldGBZa/1srtj16u/64fo1f2lx3Xv8YGfnbqOmg4eO dDZP6Vw/rD+a/sf565MkuJc4yTqSeSU6fNRgOHCB59GLlvgWfmJ+/wDEMkiZa+3dz/w5/wCTj/Ux u11z629V6yTW9/oYp4x6yQCP+Fd9K1YiSSpylKRuRsvRYcGLDAY8UBjgP0YqSSSQZFJJJkkKXoP7 Df8A+N36e0+tt+2xGvO//wBt1x/1f6TZ1fq1GE0exx3XO8K262H/AL6vZfSr9L0to9Pbs2dtsbdq mhD9Vkn5RH+NFzeZ5off+T5YHUnJln5DDljD/u3/0fU3sZYx1djQ5jwWuadQQdHNK8U+uP1Zt6B1 RzGNJwcgl+LZzp3pcf36l7aqHWujYXWsCzBzWzW/Vrx9Jjh9Gys/vNTMmPjHiNm1yXNnl8lnWEtJ j/unwMFTaVpfWL6t9Q6BmHHym7qnE+hkNHsePL91/wC/WsoGFSlEg0XpcWWMgJRPFE7EJgVMFBaU QFMIbcJpQU4KGCpAphDYjJICnUAVIFNplEnougfXTqvSC2p7vtWGNPRsOrR/wNn0mf8AUL0bov1k 6X1qucS2LgJfjv0sb/Z/Pb/LYvGJU6brabG20vdXYwy17SQQfJwU2LmZw0Pqj2P7HN574Ny/NXOI 9nMf04j0y/2kH1vrf1P6R1jdY5n2fKP/AGoqABJ/4Rn0bF5/1v6odY6PNj6/Xxh/h6pIA/4Rv0q1 ufV//GLZXtxutD1GcDKYPcP+OrH0/wCuxd3jZONmUNvxrG3UvGj2EEFWDDDnFx9Mvx/wouRHmviX wqQx5h7uDaPF6sZH+qy/of3P+Y+GruP8W/WdtlvR7ne18248/vD+dZ/ab71t9b+ovSOpbrccfYsk 676x7Cf5dP0f8zYuJyuhde+rOdVmmovZjvD2ZFfurMH8/wDOr3f8IoBjyYJidXEbmP7rqS53k/in LT5cS9vNIXCGT0y92PycEv031bIx6cqizHvaH1WtLHtPBBXm2D0C/pX12xMJ8urFvq0WH86todY0 /wBZuza9ej4OXVnYdOZT/N3sD2/McIjqaX2MtcxrrK59N5ALm7vpbHfm7lcyYo5OGX7pEgf6rznJ 89l5MZ8RBMcsJ45QP6GWuCM/8H9Jmua/xhVGz6uPd/ora3n7/T/9GLpVC6mm+s1XMbZW76THgOBj X6Lk+ceKEo9xTX5XP7HMYs1cXtzjOv3hHo8r9Q/q59gxP2llMjKym/o2kasqOv8An2/SXSdSz6en YN+bcfZQwujxP5rP7bvarK4j/GDnZOTbj9CwmPtsfF1zGAuJ/Nqb7f7T1HKsOL09NB/WkW3i9z4l z4OU0Jniya+nFgx7x/xfS8JmZV2ZlW5V53W3PL3nzJSxMPKzLhRi1Outdwxgkrr+i/4uci3bd1ez 0Gc/Z6yC8/17PoV/2d67jp/S+n9Mp9HBobSzvA9x83vPveqmPlJz1n6Qf8Z6DnPj/K8uPb5cDNOI 4Rw6YIV/X/S/wHjuif4uD7b+s2eYxqj/AOfbf/Sf/bi7SmjB6bi7KWV4uNUJMQ1oH7znf+SWX176 3dL6M01ud9oy+2PWRIP/AArv8F/1a84639Zeqdaf+tWbaAZZjs0YPl+e7+U9TGeHAKgOKf8AL5pO bj5X4j8VkMmeZxcvuLHDD/qOH9L/AGk3revf4xKad2P0Zous4OS8ewf8Wz/Cf2vYuEzM3LzrzkZd rrrXcueZ+Q/dQElUyZp5D6jp26PRcl8O5blI1ih6j82SXqyS/wAJSSSSjbikkkkkKSTJJKtSQBJA AknQAJAEkACSdAAvQfqX9THY7mdU6oyLh7sfHd+Z/wALaP8ASfuM/MUmLFLJKh9T2afPc9i5TEcm Q6/oQ/SyS7B1PqT9XD0fAN+S2M7KANgPLGfmU/8AfrF0iSS0vaj7ft/o1TxP3/P97+93+t4uL+rX y+3/AHOD0P8A/9L1VJJJJTW6h07C6livxM6pt9D+WO8f3mn8x7f3mrzT6xf4ss/Ec7I6MTmY/PoO gXNH8nht3/nxeqJJk8cZb/a2OX5vLgPoPp6wPyl+d7arsew1XsdVY3RzHgtcPi1yQcvfc/pPTOpM 9PPxq8hvbe0Ej+q/6bVzmZ/ix+rd5LqPWxHHgVv3NH9m4Wf9UoJcvLoQXWw/GcX+UjKB8PXF8oBU wV6I7/FNhz7Oo2AedbT/AN+akP8AFPj/APlk/wD7aH/pRRnl8nb8W7H4zyfXIf8AFn/3r56CpAr0 H/xqaP8Ayyf/ANtD/wBKp/8Axqsf/wAsX/8AbQ/9KJv3bL+7+IZR8b5H/On/ABMn/evnwKeV6D/4 1eP/AOWL/wDtof8ApROP8VmP/wCWL/8Atof+lEPuuX938QyD47yH+dP+Jk/718+laPR+vdS6Nf6u FaWg/Tqdqx39dn/fl2H/AI1uN/5YP/7bH/k0/wD412L/AOWFn/bY/wDJpDlswNgUfNE/jXwzJEwy T44S0MZY5kf9F2Pq99c+m9ZDabCMXNP+BedHH/gX/nf1PproCA4EESDoQVxA/wAV+KDI6hZI4IrH /k113TcOzCwasW29+U+oR61n0nCdN39X6KuYjlqskf8ACeb5+HIiXHyeUkE64pRmODxjOf6LYaxr GhjAGtboGgQAFJJJStBSSSSSlKOxm/ftG8iN0ax4SpJJKQZmbiYNDsnLtbTSzlzjHyH7zl599Yf8 YOVl7sbpM42OdDef5139T/Qt/wDBF0fXvqaOt5pyb8+1jAAK6NocxkCHbNW/SWb/AONhif8Ac+z/ ALbb/wCSVbN78rjAcMe9+qTt/DT8JwiOXmchy5t+A45+1iP+L+sk+fOcXEucSSdSTySkvQf/ABsM T/ufZ/223/ySX/jYYn/c+z/ttv8A5JVfuub938Q7v+n/AId/nT/4Xk/718+SXoP/AI2GJ/3Ps/zG /wDkkv8Axr8T/ufZ/wBtt/8AJJfdc37v4hX+n/h3+dP+Jk/7189SXoX/AI1+J/3Ps/7bb/5JL/xr 8T/ufZ/mN/8AJJfdc37v4hX+n/h/+dP+Jk/7189SXoX/AI1+H/3Ot/zG/wB6NT/iy6Sx03ZN9o/d G1v/AH1yP3TL2H2rT/xg+HgaZJHwEJvmy0+k/VzrHV3gYmO70zze/wBtY/tu+l/YXp2B9UPq9gEO qw2PePz7ZsP/AIJLf+itgAAQBAHAClhyX78vpH+Ln8z/AMZhRHL4jf7+X/1XD/v3nPq79Sen9HLc i4jKzRqLHD2sP/As/wDRjl0iSStxhGAqIoPPZ+Yy8xM5M0zOR6n8oj9FSSSScxP/0/VUkkklKWR1 360dM6Aah1D1Wi8H03MYXNJb9Ju797Va6y/rJ0LH690q3Bthrz7qLf3LB9B//fX/AMhCV0a3ZMXt +5H3L4L9XDu4jv8AGj9WBwMh3wrH8Xobv8av1dHFOS7+wz/0qvLc3CycDLtw8phrvocWWNPiP++u /NQFVOefg7Y+F8qQCOIg/wBZ9Ud/jZ6IPo4mS74hg/8ARiEf8bXT/wA3p9x+L2j/AMkvMEkvfn3/ AAXj4Xyo3iT/AIUn0w/42sf83prz8bQP/Ragf8bB/N6b99v/AKiXnAcphyac2T978AzQ+Gcl/mr/ AMKf/fPfu/xrZh+hgVD42OP/AH1qif8AGn1M8YdA+Jef+/LhA5SBTDmy/vNiPwzkf8yPtn/3z2zv 8aHWj9HGxh8nn/0Ygu/xlfWF30W47Pgwn/qrCuRBJMDUngLsvq1/i+zM7ZldV3YuKYLaeLXjz/0L P636RKM80zUZFGbl/hnLQ48uLHEdARxSl4Ri2ekfWj67dbyPQwRVA/nLTWAxg/lvO7/NXolYsFbR YQ6wAbyBALo9xaELCwcTAx242HU2mlnDGiPmf3nI6uY4SiPVIyJ7vN87zOLNMezhhgxx+URHrl45 JKSSSUjUUkkkkpSSSSSnB+tF/wBZsWpuT0UV2VVtPr1Fu6z+uwfnN/ktXGD/ABi/WJphwoJHINZ/ g8L1Fc39Y/qV0/rAdkURi5x19Vo9rz/wzB/58+moM2PIfVjmR/Vv/out8N5zkogYub5eEo9M/Dcx /tf3v7zzDf8AGZ1ofSoxnf2Xj/0Ypj/Gd1TviUH4bx/35cz1XpHUek5HoZ1Jrd+a7ljh+9W/6LlS lUzmzA0ZEHxejj8M+G5IiccOOUZaiUSeE/4sntx/jQzvzsGo/B7h/eit/wAaNn5/Tx8rT/6TXByl KX3jN+9+AQfg3w4/5AfSWT/v30Bv+NKr87pzvlaP/SamP8aOH+dgWD4Paf8AvoXncpSj95zfvfgF h+B/D/8ANEf4eT/vn0lv+M/pR+niXj4bD/39qI3/ABmdCPNOQP7LP/Si8xlKU771l7j7GM/AuQ6R kP8ADL6kP8ZP1ePLcgf2B/5NEZ/jF+rbiAHXSdAPTJJP9kleUSuz/wAXv1ZOXkDrGWz9Wx3fq7T+ fYPz/wCpT/58T8efLOQiK+xqc38J+H8vhllmcgEdhx/PL9GI9L6Sx25odBbuAMHQifFSSSV15lSS SSSn/9T1VJJJJSkkkklPK/Xf6m19dx/teIAzqdLYaeBa0f4Gw/vf6J68hvoux7n0XsdVdWS19bhD gR2cF9ELnvrR9TOm/WBnqu/V85ohmS0cx9Flzf8ACM/6ahy4uLWO/wCbpcj8Q9qseXXH+jLrD/0F 8USWx1v6p9b6I8/a6C6gH25NcurI/rf4P/rix1WIINEU7cJxnEShISB6hScFMrnTekdT6pd6PT8Z +Q/uWj2j+vYfYz+0hVrjIRFkiIHUtYOWr0T6v9V63d6eDSXMBh97tK2f17P++N967P6v/wCK2mot yOuWes8a/ZaiQz/rtujn/wDW13mPjY+LS2jGrbTTWIZWwBrQPgFNDlydZaDt1c/mPjMYAxwjjl++ fkH/AHzz/wBXPqN0zoobfaBl5w19Z49rT/wNf5v9f6a6VJJWYxERQFOJmzZM0zPJIzke/wCxSSSS LGpJJJJSkkkklKSSSSUpJJJJTXzun4fUMd2NmVNuqdy1w4P7zT9Jjv6q88+sP+LzMxN2T0kuysfk 0H+daP5P+m/8+L0tJR5MMMg1Gvfq3OT+IcxykrxyuB+bHLXHL/vXwNwcxxa4FrmmCDoQU0r2Prv1 S6R1sF99fpZMaZNUB/8Ab/Nt/trzzrf1F630susrZ9txh/haQS4D/hKfpt/6apZOWnDUeodw9Nyf xnl+YAjI+1k/cmdP8Cbz0pSokwYOhHITSoqdAzZSmlPTVdkWCqit1tjtGsYC5x/stXa/V3/FvlXu bk9bJop5GM0/pHf8Y4fzTf8AwT+onwxSmaAa3M87h5ePFlmB2j+nL+7Fyfqn9VMnr2SLLA6vp1R/ TXcbo/wNX8v/AM9r1zHx6cWhmPjsFdNTQ1jG6AAJsbGoxaGY+NW2qmsbWVtEABFV/FiGMdydy8nz /P5ObyWfTjj8kP8Aupf11JJJKRpKSSSSU//V9VSSSSUpJJJJSkkkklLEAggiQeQVlZf1U+rmY4vy OnUOe7lzW7Cf7VWxaySBAO4tdGcom4yMf7p4XDo+pP1VoMs6dU4/y9z/AMLHPWxTRTRWK6K21Vjh jAGgf2WoiSQAGwATPJOfzylL+8eJSSSSKxSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJ JJKc/O+r/Reou3ZmHVa/98th3/bjNr1Rr+o31WrduGA1x8HOe4f5rnreSTTCJ1MR9jLHmc8Rwxyz jHsJyAa2H07AwWbMPHrx2+FbQ379qspJJ1UxmRkbJJJ6lSSSSSFJJJJKUkkkkp//1vVUl447/Hb1 wOI/Z+LoY5s/8mu7+oH1ry/rT0u/Ny6a6H03mprat0EBrH7jvLv30lPUJJJJKUkuI/xg/XzP+qmV h04mNTkNymPe427pBaWt9uxzf3lh/V3/ABt9X6t1zC6bbhY9deXc2p72l+4B3du5ySn1NJCyrTTj W3NEmtjngHgloLl5D/493XP/ACvxfvs/8mkp9jSXPfUb6yZP1l6GOp5VTKLDa+vZXO2GbdfeXfvL oUlKSSXmn1v/AMaXVegfWHK6Vj4ePbVj7Ntjy/cd9bLTu2uDfz0lPpaS8/8AqJ/jH6l9Z+sv6dlY tFFbaHW76y/dLXMbt97nfvr0BJSkklyH+MD69O+qlWLXi1V5GZlEu9OwmG1N0Lzsj6T/AGs/tpKe vSXjn/j3dc/8r8X77P8Aya9J+qP1ir+snQqOptaGWulmRU3UMsb9Nuv/AG4z+Q9JTtJJLyrr3+Nj 6w9G6xl9MtwMUuxbHMDv0g3N5qs+n+fXtekp9VSXA/UL/GTk/WbqtvTc7Hqxnio20Gou9xaR6jD6 jnfmu3rvklKSSXmX1r/xs5/Ruv5fTMHEovpxXBnqWF+4v2tNo9jmt9jzsSU+mpLx1n+O7rO9u/p+ NskboNkx+dt969ex768iivIqO6u5jbGHxa4bmpKSJJLC+un1kP1a6Db1JjG2372V0VPJDXOce+33 e2sPekp3Ul45/wCPd1z/AMr8X77P/Jr1fo+RmZXSsTKzq205V9TbLamTtaXDfs90u9spKbiSzutd f6R0LG+09UyW47DOxp1e8j82qpvvs/srgepf47sRjnM6Z059wB9tl7xWD/1qsW/+fElPp6S8cP8A ju61Pt6djAeZsP8A35L/AMe7rn/lfi/fZ/5NJT7GkvKeif43+sdS6xhdPswcZleXfXS97S+QHuDC 5su816skpSS8jz/8c3WsXOycZuBjObRa+tribJIY4sk+/wAkD/x7uuf+V+L99n/k0lP/1/K3/Td8 SvZv8Sn/AIncz/w2f/PdS8Zf9N3xK9W/xSdf6J0zoWVT1DOoxbX5Rc1lrw0luysbod8ElPqaSxf+ ef1T/wDLfE/7db/el/zz+qf/AJb4n/brf70lPnf+PD/lDpX/ABNv/VMXIfUX/wAWHSP/AAyz8q6T /HB1fpfVM7pr+nZVWW2uqwWGlweGkubG7aub+ov/AIsOkf8Ahln5UlP0L1D/AJPyf+Js/wCpcvl1 fUXUP+T8n/ibP+pcvl1JT7n/AInv/Ec3/wAM2/8AfF264j/E9/4jm/8Ahm3/AL4u3SUpfP8A/jR/ 8XHUf+s/+eal9AL5/wD8aP8A4uOo/wDWf/PNSSnS/wATP/irt/8ACln/AFdS9uXiP+Jn/wAVdv8A 4Us/6upe3JKWc5rWlziA1okk8ABfOX116+frB9Y8rPaSccO9LFHhUz2s/wC3P53/AK4vW/8AGp9Y f2R9Wn41LtuV1MmiuDqK4/WbP8z9F/11eJ9J6bf1XqeL07H/AJ3KsbW0+G4+5/8AYb70lLZXTMzE xcTLvr2U57HWY7v3mscan/8ASau2/wAT31h+wdas6Pe6MfqQ/RTwL2CWf9u172f9tLsf8Yv1ToyP qWyrCrh/RGB+OANfSY3Zez/tpvq/9aXiWNkXYuRVk0OLLqXtsreOQ5p3Nd/nJKfqZeP/AOOnovo9 SxOtVj2ZbPQuP/CV61n+3U7/AMCXpv1b6zV13omJ1SqB9oYDY0fm2D2XM/s2Ncs//GB0X9s/VXNx 2t3XUt+0UeO+r3wP+Mr9Sv8AtpKfDfqt1Y9G+sOD1GYZTa31fOt36O4f9tPcvpQEOAc0yDqCOCF8 rL6H/wAX3V/2v9U8G9xm2ln2a7+tV+j/AOnX6diSndy8mvExLsq3SvHrda/+qwF7v+pXzDnZdmbm 35lpmzIsfa8+byXn8q93/wAaPVP2f9T8prTFmaW4rPg87rf/AAFli8K6bhWZ/UMbBqE2ZNrKm/F7 gz+KSmuve/8AFb1cdS+qONW4zbgE4rx3hnup/wDAXsXmP+M/odfR/rQ8UM9PFyqmXUtAgCB6NjR/ 1yrd/bWx/iW6v9n6zldJe6GZtXqVgnT1KvD+tU9//baSn2VeS/47erB+TgdHYdKmuybR5u/RU/8A RbavWl84/Xbq37Y+tHUM0O3Veqa6TyPTq/Q1x/W2b0lMPqd0c9a+suBgEbqn2h93f9HX+ltn+s1m xfQnWOqY3R+l5PUsnSnFrLy0aEkfQrb/ACrH+xq8z/xJ9H3W53WrG6MAxaD5mLb/APo+itb/AB09 QdR9X8XBYY+2ZEv82VN37f8Atx9SSnynr/Xuodf6lb1HPeXWWH2M/NrZ+ZVU381jVf8Aqp9R+s/W ixxww2nFqO23KtkMB/cZt91tn8lc+vfPqr1v6pdI+ruBgN6piMdXS02g2sB9R49S4u1+l6jnJKea r/xG1bR6vV3bu+2gR/0rlL/xjcb/AMt3/wDbA/8ASy7n/nh9Vf8Ay2xP+3mf+SS/54fVX/y2xP8A t5n/AJJJTyPSf8TuP0zqmJ1FvVH2HEuZcKzSBu2OD9m71Xbd0L0ZZVH1q+reRcyijqeLZda4Mrrb a0uc46Na1oP5y1UlPzD1r/lnP/8ADN3/AFblTVzrX/LOf/4Zu/6typpKf//Q8rf9N3xKNj9Pz8ph fjY1t7AYLq2OeAfCWAoL/pu+JXs3+JT/AMTuZ/4bP/nupJT5J+xesf8AcDJ/7Zf/AORS/YvWP+4G T/2y/wD8ivp5JJT8tZGHl4paMmiygu1aLGOZIH7u8NWx9Rf/ABYdI/8ADLPyrr/8eH/KHSv+Jt/6 pi5D6i/+LDpH/hln5UlP0L1D/k/J/wCJs/6ly+XV9SZdZsxLqxy+tzfvBC+W3AtJadCDBSU+5/4n v/Ec3/wzb/3xduuA/wATGXVb9WL8UEerj5Li9vcNsaxzHf2tr136SlL5/wD8aP8A4uOo/wDWf/PN S+gF87/4w8uvM+ufVLajuY20VSPGpjKH/wDTrSU7X+Jn/wAVdv8A4Us/6upe3Lxb/ErQ5/1kyrvz asRwPxc+qP8AqV6J/jB+sX7A+rWRfW7bl5H6vi+O9491g/4mvfYkp8j/AMZH1i/bv1luNTt2Hhfq +NHB2n9LaP8Ajbf/AAP01s/4n8DBHU8jrOddVUMRvpYwte1pNlg/SWNDz+ZV7f8Arq89S2nwKSn6 df1boz2lj83Gc1wIcDayCDyPpL52+tHSqukddy8GixtuOx5dj2McHA1v99XuZ+c1rtj1l7T4FKD4 JKfTf8TH1iNWVkfV+93syJvxZ7PaP07B/XrG/wD60vXCARB4Xy/0zqGR0zqGP1DGO27FsbYzz2n6 J/kv+ivpbpXUcfqvTcbqOMZpyq22M8pGrD/KY72OSU/Pf106KeifWXOwA3bSLDZj/wDFWfpKv8zd 6a7T/En1jZlZ3RbHaXNGTSD+8z9HdH9Zjq/+21Z/x2dF3VYPW626sJxchw8DNuOT/a9ZcB9Turno 31lwM+dtbLQy7/i7P0Vv/Qekp7T/AB29U35vT+ksOlLHZFo/lWH065/sVv8A89Yv+Kbpf2/63VXu bNeBW/IdPG7+aq/6du/+wsv6+9UHVfrZ1HJa4Pqbb6NThwWVfoWlv9bZvXoX+JPpnpdKzupuHuyb hSw/yKhuMf8AXLv+gkpn/jp6T6/RcXqjGy/Ct9Ox3f07dP8Az8yv/PXln1c6q7o/XcHqQ4xrmuf5 sJ2XD/tpz19D/WPpber9CzumkScilzWeTwN1R/7daxfND2OY4seNrmkhwPIISU/SH1s6wzpX1Yzu pMcNzaT6B8X2fo6P+m9q+bl3P1m+tv7Q+oHQ+miycguc3LE6xi/oaN//ABrbGWf2FgfU3o5619Zc DAI3VOtD7v8Ai6/0tv8AnNZsSU+4/UTo/wCxvqtgYjhFr6/Wv/r2/pXf5m701xf+PGfT6R+7N/3x SvUgABA4Xn/+Ofpr8j6vY2cwScG/3+TLR6Zd/wButpSU+LK43ovWHAObg5JaRIIpeQQf7Kpr6R+p /VaOrfVrp+XS4O/QsrtEyW2VgV2sd/aakp+e/wBidZ/7gZP/AGzZ/wCQS/YnWf8AuBk/9s2f+QX0 6kkp+d/qp0jq1X1n6VZZhZDGMy6S5zqngAB7fc5xavohJJJT8w9a/wCWc/8A8M3f9W5U1c61/wAs 5/8A4Zu/6typpKf/0fK3/Td8SvZv8Sn/AIncz/w2f/PdS8qd/wA3txn7ZMn/AES9b/xPfYv2Dl/Y /V9P7UZ9bbM+nV9H0/zUlPepJJJKfIf8eH/KHSv+Jt/6pi5D6i/+LDpH/hln5V3P+OX9m/b+m/bf Xn0rNno7Ijc36XqLlPqX+xP+dfSvQ+1er9pZs3+ntmfztvuSU+/r5++v/wBUcz6vdZutFZd03Ksd Zi3gS0bjvNDz+bZV/wBNi+gVU6r+y/2fd+1/R+wbf0/2jb6cfyvU9qSn52+rf1n6r9Ws77Z05494 23UvE12N/dsaC3+y9q9Ao/x4s2D7R0g7+5ru0+59S5j60f8Ajbeu/wDYv23fJn0o9D+x9q/TrkrP T3n0t2ztuifwSU+ida/xz9Vy8d9HS8RmAXgtN7n+rYAf9F7a2Mf/ACvevOvfY/u+x5+JJP8A1TnK 1g/sneP2h9o2d/Q2T/4KvWP8X3/jaevX+yp/aumz7f8Az0/8B/2n3f8AEfpElN7/ABVfVPJ6F0u7 Oz2GrN6gWn0nfSZU2fTa/wDdse5+97Vw3+Nr6xftT6w/s+l04vSwatODc6DkO/sw2n/ra9tyvW+z Xeh/PbHelx9KDs+l7fpL5uyP2J69n2j7b6+93q7vT3b59+7+VuSU7H+LLoI6z9aaDa3djYI+1XA6 glhHos/tXFn9he9fZ6P9Gz/NC8+/xN/sX7B1H7B6n2n1Wev623ds2n0Nvp/mbvWXoqSkf2ej/Rs/ zQqnVej4XVOm5PT7q2ivJrdWXACQSPa9v8pjver6SSn5czsO/Azb8LIbtuxrHVWD+U07SvU/8TH1 i9THyPq/e73UzkYs92OP6esf1LP0n/XFz/8AjM/5uf8AO7Kn1/X21/afR2bPU2j9/wDO9P096p/U b7D/AM6+nfsr7X9q9UfS9Pb6cH7R6kf4P0PUSU+zfWro7et/V/N6aRL7qiafKxv6Sk/9uNavmxzX McWOBa5phwOhBC+qV89/Wv8A5s/85Opel9q2/abJ9P09m7d+l9Pd7tnq79qSnmV9H/Urpf7K+q3T sMt22CkWWjvvt/T2f9KxeD4P/Nn7bj+t9r9L1Wepu9ONu4bt0fm7V9JN27Rt+jGkeCSl188/4w+k /sr63Z9LWhtV7/tNQHG239IY/q2eoxfQy8o/xyfsT9p9P+1+t9q9B8+js/m936Pf6n8v1UlPli9S /wASfR5sz+tWN0aBi0EjuYtvj/wFeff9j3/dz/wJe3/4sv2b/wA0MT9nbvT3Wer6kb/U3u3+ps9v 0dn/AFtJT1SrdS6fjdTwL+n5bd+PksNdg7w4ct/lN+k1WUklPzh9avqp1L6s9QdjZbC7HcScbKA9 ljfj+bZ/pK0P6v8A1r659XLXP6XkGtlmtlLhvrcR3dW787+Wz3r6E63+xf2bb+3PR+wR+k+0Rs8v pfn/ALmz3rxT6w/+Nj67v2V+0Jkz6O30f7H2v9Okp0Wf46vrK1oD8XDef3ttg/8ARyf/AMev6x/9 w8P/ADbP/Sy44/8AN2dPtkf9aS/7Hv8Au5/4Ekp7/oX+N3r3Uus4PT7sTFbVlX10vc0Wbg17gxxb NrvdqvWl89fVX9h/85ulej9r9X7XTs3entne2N0fmr6FSU/MPWv+Wc//AMM3f9W5U1udX/YH7Wzd /wBr3/aLd0enE73TCqf9j3/dz/wJJT//2VBLAwQUAAYACAAAACEA3UOwkTcGAABJEgAAEQAAAHdv cmQvc2V0dGluZ3MueG1snFjbcts2EH3vTP9Bo+c6AsA7J3KG1zodJ/VESfsMkZDEmiQ4IGRF+fou eIkiZ53JxC8Gd7EHi70Zx6/ffG7qxZNQfSXb9ZK+IsuFaAtZVu1+vfz0Mb/xl4te87bktWzFenkW /fLN7e+/vT6FvdAatvULgGj7UK6XR9WGfXEQDe9vmqpQspc7fVPIJpS7XVWI6ddyslDr5UHrLlyt JqNXshMtoO2karjuX0m1X42WqSyOjWj1ihHirpSouQaH+0PV9TNa86tocNRhBnn60SWemnred6Lk Rzun656kKr9a/Ix7xqBTshB9D5Ft6vG6Da/aGaavfwZnjOd9tVVcnb8BuYW0fZGyWZzCTqgCAgo5 J2S5MopSvpc6rfqu5ucHvhexPELaVSX6Qb0F36BOUrNrc1TKaO8EB9mL6lxKPanhVnK30VwLOLvv RF0PFVbUgsPdTuFe8abhUBGjZIDs9bkWD7wV+VAPeVUDGux94hAEKyd08lvs+LHWH/l2o2U36202 X0vxE5z1p6rKf4TSVcHrTccLEM1bqeNOSOPl76SqvshW8zq92GbQJOfZYoYe98+wL+1mI3px4IoX cIXp+ASOULKeMaFNOgWJfzi2hT4O9T3aHUq1OfBOpOM9+9vXMuyNoJwEi6dQfIZMirLS0K1dVTb8 MySWsWBwdHUKv8c4hTvITgsJelAm+/MXuFOV6+XNFNxn4hlvFo+2oi0vQNPHM5xr6QxzZWgCwLXx pYf8mKR/uh9Li9e8LcQGUlaL+KxFKo/bcfVvVerDsGmo3nvBn0TMi8e+5v0hMiNrUB7rj4pXQ95H wbA7+9zBYNscqp3+IDQMr2EvL/879vq+asWdqPYH/baFyqonnF7k2T0/y6OGvRDXi88wQUtIzSk0 iw8Q2jmvhPi+Q0g2JtNoLxpiuYnroRqPpHmMamLXcqfsPENL7OgFm5zkqY2hUYtELEU1tpdHEaqJ aeJNLXDtAY0t5vioTcLcbGqEZzaJ56QBZsMs5rOpNa9tmOuSFNf4bhyjsWaJl0SoxqKEWWisLRs8 QPNjRVacozGwIpsw9D6gyVM0BlbsOD7uQexEDpptKyFZjKPlTswcLKI2IR7BNR6LY9Rr26cOs1A0 n6U5WiG2D5FD72MHLLPwcwIv9hL0nMgjBL0p9BWN0Sw4zHa8HENzLNtlaEQd2/YstEIcz3VstEsc 3wtctBJdYvkU7QWXugz3AOSMoh64AUscNG5uYgc2WqNeTFmOaxLiuug5Xuq5Nq7JbCdD0XxqU+pg sfaZTSI0Br7lENxr37G9BJ1VL89R0EBroR7EtkvQqvIzx8lw33Li+WjFBwHxLbQSg9iFoYh5EOQs wGMAgyJyUbQoIq6N1nWUUd9Cqzf23MBHKyQOHAuvxDimPt6nMVQbRTs4ITSP0egklNAAvU9iSgfN aRIQD6+qJLA83OskgimG5jRJ3dTCNZkbU7RPkxz+CKN1kFI7ekHjUZgIWLbTiEX4tMwI/KA2GYVZ gfqWWVYQoFMsg7LGqzfzGI3Q/GSpRRP8nIwSPG45TFEPRcth+jN0+ueJx/D75JlHAzTWeQ75GToY XlXmjz28pZrQUDPzxBxXOTyYF834/E94s1UVX7wz5A3eYk24VY9x1c76rQASKb7VbI7bWXlzMyr6 htd1Do/yWQG8bdSU8LKH9/YAXL/jan9BHtqyCRUqhSf5X1/RDL8S6k9gSt2IelK8e9uWIJ4PpPbY 5k1YtfDmbGZ5f9xuZqsWONw3qmNb/v2kDODqEqBTqIF2w5sZUPiF2Yj25tPG0CvBex31FV8vvxxu kvfGGh6vtdoYti7e8a4b+dB2T9fL2jx7qTHT8AUU8HH42O7ZpGODDr6Mbvjghbks7J4WZsO4hF3T 4iKzZpl1kdmzzL7InFnmXGTuLHON7HAGHgtU8hFY8bw08p2sa3kS5d0sXC+/E41BGJjA27aoj6WA Eill0b9tDVEdWe9AtH6ZeU1EDQg1MIYrmmZInOFp3ZV0UXINORpmqAyV2Jva0YZ+XG0zxhBu4KOt OAHRWy5kDZxtqMzVtR1UyZUTA2t5dimg/qKooBc252Z7IaSvxgDVVa83ogPuqqWC0A7s+4+h/i7/ A7r9HwAA//8DAFBLAwQUAAYACAAAACEAIYKuTFMOAAB3VgAADwAAAHdvcmQvc3R5bGVzLnhtbOxc X4/cthF/L9DvsNh35/bP/TVyDu7OdmLAuTi+c/sYaLXcW8VaaStpfbaf+pQ0aIqgLeC2SB/iJi1c oPFLCiRN3PbL+C7OU75Ch0NSojQiJa7XTYskDzlLS/5IzsxvZkjO7suv3J2FnTssSYM42u32X+p1 Oyzy43EQnex2bx1fvbDd7aSZF429MI7YbvceS7uvXPrxj14+vZhm90KWdgAgSi8mu91pls0vrq2l /pTNvPSleM4i+GwSJzMvg8fkZC2eTAKfXY79xYxF2dqg19tcS1joZTB4Og3maVeinbZBO42T8TyJ fZamMNtZKPBmXhB1L8H0xrF/mU28RZil/DG5kchH+YR/rsZRlnZOL3qpHwS73eNgBis6ZKedm/HM i7rwCfPSbC8NvN3u2eNfPv3nb/m76V6U1rf2UwqyxkcKvegEet7xwt0uiy7cOipj359eODjkr0bB GJC95MLRXhc6ruHE1V9tAfN8OaJVZbUgU5DwkdAQyIJNrsf+bTY+yuCD3S5oGV/eunYjCeIkyO4V 747YLHgtGI8Z2EPeLpoGY/bTKYtupWxcvH/zKmpXvvDjRZTtdgebW6iAMB1fueuzOdcuDBd5Mxj5 kHcI+fA/U337fKEgobrmU+ZxU+z0nXsMnHsMnXus8x6pJi+c5qIiLPe5b7wg3M0XhLv1gnDB97wQ +e6sGNf30MhXjHocZCHjmK2YcrQYZW4dsiSOTlrjX5nNp14agItuOaEboeezaRyOWdI5ZnezeukE hQPa2bE4gsO4czT3fPAFHGehdWtPr+vByTTrHE3RpVRhNnuW0UXP60GKq9BH37R5L9Ht1SQYk9EG ltFeZ+NgMVMTFb6vNOawfWd0g6XO682d+UJrht1o2ZOOudnck0upZsytlj3pmNste6LbL0nIZoeX veR2p84Qtmz2cxCHcTJZhEqnVXPYsllR3rl2WJsh5T3rTHDLZkUlqnT2fB+yiRrt2NZccMbc37bs gjzm/rbFV1lkRrEJooIyMKO05pUZwkawm+xOwJN0bjo05dD8odWNIrNveIl3knjzadUMh5jQtAo3 by7iDIOTzpwBBtZW/a9FkKCmrFOLM8S8sxWO1A+uy6Kc1g7IrJzWnsgM0dolmSFa+SZjdycnZUax 0Tb3OagSk+fYsjE3h8CYYISw0bbWf9EY4ea/aH+bIKj/ov1tUqh4nr5SB0WxCaKCklOEojj7Lwph 81+1RKUQzkSlEM5EpRDORKUQTkQl3ZciKkWx2WfOMp2oFMJmojmETlQKYbPPWqLSlMyNqLS/TRCU qLS/TQoViuVEpSg2QVRQcqJSFGeiUghnolIIZ6JSCGeiUghnolIIJ6KS7ksRlaLY7DNnmU5UCmEz 0RxCJyqFsNlnLVExX9QzwJa7aBXLaH+bIChRaX+bFCoUy4lKUWyCqKDkRKUozkSlEM5EpRDORKUQ zkSlEM5EpRBORCXdlyIqRbHZZ84ynagUwmaiOYROVAphs89aouKJ8nMQlfa3CYISlfa3SaFCsZyo FMUmiApKTlSK4kxUCuFMVArhTFQK4UxUCuFMVArhRFTSfSmiUhSbfeYs04lKIWwmmkPoRKUQNvus JSpe0TwHUWl/myAoUWl/mxQqFMuJSlFsgqig5ESlKM5EpRDORKUQzkSlEM5EpRDORKUQTkQl3Zci KkWx2WfOMp2oFMJmojmETlQKYbNPfrUWso5+A6YztO9+6mmCGrS/zJKTuskmLIGKDUbOcttDqbNY Mxbu6Vudx+7H8e1OfnOpi2mI+412IMEoDGI8or7XeN49xNtneuluLio4fuOg85ooLGhGR+VSdHIL CpUaetEFr2jAAhlomN2bQ+XDXD91h4IMXpkCFTc4A16ncQ3qKrw+Vk7wUgnoh8UismACVyOFh/+G ip2xatPr9de3ru7tiRsvKA3ho2feCAtf4K9qF7JJxsebx1CmsrUjvampQb+/I7lpbLGxLb2QscXO NjpckA40wfnEUG00CePTG4vIz9TM5PmOt8hifs3LLl8xfnJY/WT89iLNbvK73WtRIRIhi1TcGUOX EYNKJFBDfyDHettXQKM4m4rmGdxT74XBScTrk/KPvZSFQcR4E1iHFC/UE3EpJ6qCSNUJHUP1Ewwz C6I4uSJrh+Rc7ivEgYpj5aKgV/e5chSQqhMSo+JwMDraVINxYRtuTtSainoaNKII1ptPSszSbGP7 +/3twb5oJYVwm7H5IWAIsMVMyCRazK7lihgq/cNb8THVyWAdL3y8Scagjow/IWCdhuJFxnVx/U6o 5o2NzXqRlV17SSDKjgrxfvPVr8v1XKINDj3C/6e5xoYyxKT3D3i5GDJTvIORl9LNgDBd6UYOpesG /AJOaAXKCcJCdBL1v6svHHTV+io0pbila0q8W1ZTQ6OmZNIwAgcxfoPXuKFdKGWtVoGcatfB8lM0 hJxMujqV4djpp/lYhCqeD8VzyZ/iqxrGwkEfrFcxVjxxYu521/uYXfGHm4sQXvABhPlS8uKUzcZA yIrTGR0IIdxmSS705+CnP4XI7IPr4SsyBWZKV1mM2clv0zs8FIiFFnmPMgpJteLmHldSzivgFYjC 4OEhfIpqMNMMqZmK1KFzjD3FeHmdgJqXqhZomlhe9IU42SiUScYoFEEXKnbRIkSuM77rCUFAwwMW hq97IiWJ5zCuoSlPTsSn/R4W/lWgIEpn8czcP8HqLoSvAwDJ6pMRj3wRZpEDyUYskSVnJrGvE+8A pWp8u2KyhLYSN8+rlEn6kPzEsyOeQZJsskfm9uzho/OPnnzzp9+ff/ZITLDOS5VzS0Pcb3BGMjEs xZbGVAAxYRk9mQEEmNBxy+AvtzEXn0LSBDrZ7Q435f61yBN4mRLwWBDJkKhVEwJZzK0F/yKY9OUq 9GAi3oF2XMK+TUsbBi2dP3j3/I9/E1pq1IjKruGvovaY+YGstcaEXyVKoiksYGkBRfGNJI4n6AoK YcHmVb4pciTxboXC2qwT1tknf3cS1qoNZrRCSYB2hJ+3mYwosNe3iUjsz8+efCB0UE1JZKbSaEaF ZNSmiNhJofBmdqDPbR0p9uELHfBNFNy8YqTAdIp/uUNIJL0P2QUP0jwfAW+HAcfnpZV6kiHjyFJ9 8xizVG8VgZbqHMBXSsbsNUVe11WL7j9ZrjvoGGKjLv7//bANU/blfnKabzb9kHmYxulWATKZBCF8 76ZIRO/gJl8JqxQ1BCpIxJCHtQ6+xFGdf/Cbsw//9dyxtzb1l+fJbaMt5u3fy2C7TdQCOjn/yOw5 ZVBr9JyloxC6YdrW90vwgBGj8LYlE8S4vAIL3CFr5VHy4cfnH70LVlgfKNoutybfKJ0ulpMN4bLB kQPl1EHcEJI8eJRbSP7UKBOZc2mnbtVkjmwYYQRbgjeUdzl6gifegfxdErz8zM3ziNQnMdRKY1YK mKVj25rUukaw0jhgKZjHrW/0paygLbzEcIOxh8sTm+z0xCknd+x47Ar/WDrbcwn4La22kNaISIsf g61SWv0NmfwYpbU97KEZ5NICc428+XGMV0ZSwMQ8jQlSfiRcNU6bITbnUi1Fa0sbfSLs808/Bp/w 7ZNffPOXB88evv/0i199/eSvz/794bdP3lvKP6xgkmM6yc8eff3Jl5DkLzWl3PLn++OkdW6J9zIy i+jhf3xwWJ5A4f8Q2Qc6iRV6pJVvL5lBnvqOqbpdaBsFlEjb5s0NUj29KDb8kyBJM56e8E2+iiTO 8j7/8+dwvv/Wq/uDYR8vML9z/k2IKr5+8uDsnT+cffXls8ePn8+6ieTW8xDQUnIl8UAk4d9l105F AgzPSAkVdDgvrl6VxGiIluB95S4uv+yc0POpY96qw/1uvTTa7mNPg3F8egDnsUlcviiChOPF3TGG ucmChPhD+QC8cBou56f6tuyHXbHbWcD3bldsjr+lWw5bkjCht8Zif/T0i5/Xk1LevZhTW0OMJD+o IV+goxmJ/8urHuJ21HahSE7bpu3tBUHvfKQgvny/XhAgOpy1SRJm7ZROFYrseEIvdfa9MIzhBzXw K/VCRvXXj+B/bitHfQBXXPapyd0OZL75nffzpKRthYwT40mZfpZ5/t4/4Hri/OE7IkXpFLOv5inS 8vSleiAzqxKKlZpy/BcgAk2l9MLIi6IYfpeF/0xKkpdz1aq2lml67U+Vacbfo9HWWLMFhitcGB/M tSGol8zW4lQwrPONHUmA8JO38KPaFUtG6bdU2IVX6tTpWReGzHtKJzMZrYrKDw2NZVHlFrV1UZUm jYVRg+11MX2YkGJp6QBlA35FByViarC9IWVjatDvw/e5rRD9dcVxI8ZWr2GUwWBTXpKZMAYbG9Ju jS22RZUQnlbUSmMIQrevZbjeaxhluLktTd00j+GOuFIEw4cmeBGxgpO83OGMUBkF8wY4YUeWaZ6E XhxqnqQgSNVpSoXqTpN7WHnAUY5dNXRSktGEWDb+usLCcotlGVRBaagtRGlr2X7l2aHahZz9IFMF teoqBtVFA6i2vPfSdC8x6e+CAWyzSbjEV7rLkgH2wbtnn/7ONbriHT6YdOkcUzeTaghSR7Lmwkgp A9Vw+cLHpgiEnKhmG8d8y/lWI13MC5Yq/g55UQocP0QWrch58P8UWUpVsLQIVjkdm1dZJqI0seYw FvX89cRRn6I3NIQakr0V+V4jrUrZW7kIksZmfloI+YO8U6op9ab3bKXo3Ox4SxmvFotpXYoWi9PF 6G3my3y1KqOJ9Ki6kDz1shqkZewuS+3KlX5veCDSI7MzKjmJuhhdalAbosstGnPcfkOAVpmeDIVa qDZ+sqrif+7u3Qr9RfKmSk+1QC5z7Eogh1r+lQfymoMZ3Ck//eIruM81B3Itu9PtyZvIdNhsTTKW r2jtwC5kTHrpPwAAAP//AwBQSwMEFAAGAAgAAAAhADOAIU3hAAAAVQEAABgAKABjdXN0b21YbWwv aXRlbVByb3BzMS54bWwgoiQAKKAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnJBB a8MwDIXvg/4Ho3tqL6RZWuKUtV6h17FBr66jJIbYDrZTNsb++xx26o47Se8J6Xuo3n+YkdzQB+0s h8c1A4JWuVbbnsP72ymrgIQobStHZ5GDdbBvVg91G3atjDJE5/Ec0ZBk6FTPgsNXnrPDExNVttlU z1lxKPNsW76cUleU1VEcxbYqvoEktE1nAochxmlHaVADGhnWbkKbhp3zRsYkfU9d12mFwqnZoI00 Z6ykak54czEjNEue3+1X7MK9XKLNXv+XctXXUbvey2n4BNrU9A9q0XevaH4AAAD//wMAUEsDBBQA BgAIAAAAIQCDpWTN8QsAAD2OAAASAAAAd29yZC9udW1iZXJpbmcueG1s7F3NbuvGFd4X6DsYArTo 4sr8l2TEN5AtCUhwmwbJLbqmJfqaqEQKJGXHWQbddFkUXRRddZW+QRdJ+jQN0KzuK/TMDIeckckj /oxs2ebm+orzQ843Z858c+bMmU8+/Wa9Orn1otgPg/OePtB6J16wCJd+8OG89/v38zej3kmcuMHS XYWBd9679+Lep29//atP7s6C7frKiyDjCdQRxGe3kHyTJJuz09N4ceOt3XgQbrwAEq/DaO0m8DP6 cLp2oz9uN28W4XrjJv6Vv/KT+1ND05xeWk143ttGwVlaxZu1v4jCOLxOSJGz8PraX3jpH14iqvJe VnIaLrZrL0joG08jbwXfEAbxjb+JeW3rprVBE294JbdYI27XK57vblPlbcvIvQOc1yv22XdhtNxE 4cKLY3g6ZYlZjbqGvTsFkFSRlajyCfI7+ZesXT/IqiHisdP/WecNoPNO2btPSVV5QwCLtyBM7lWc RO4i+WK7PpF+fbY872k0SxD7S0i7dVfwZGJOh0PD7J2SwuvtKvHfebfe6v39xuN56NMVecpyJevN iqddmFPt0ho6LGV1SxJ8+MPfBSIfJTyzznKBvM/X2cOlt/DXblo1lHzvfZOl9dMS8PjzBa9l5V0n rKLNlxH56gTanP7leeAVPfj/JozPe5ZpkOyneUY/IO0n9bBU+HHjBh/oUM1zp7VH7CXRPAySmOT0 AyjmuXEyiX03rZlmgjfAh5IvgT+Qk+GgU8zb4jDo00bQqptDYbOOKoGCpIpQ5LkVQWGogmLQTwW2 lWAMDQ0RDJIqopHnVoSGqQINa8CGQisgbGeIADE2ZbFwRhw2RUBYKoCwP/745+cPhV0RilV450Xv vCTxoqzRkuJ0XgQcTh04vgrXblCMBhXvtrrzEINk6V27MOemow+ZRYYVkcBnU5hFQHUO+tagbw/6 zqA/HPRHGWTN5xXdsrhO4JOxOMfSZFGXCvkV6ZDR4fAZ9McqILJHVtrNhRCRZAmiPH9jiGCeF+gg ISbCT3iZ8IuwQ8ZUJHZ44Vza2pz2bRN2qFvjyXRi59QFXlqPHW43G1TR/fL3P/3809+U8ETdGFFW UcKOaLLYQy+aKeqWgXECmiyC8dK5om4P6VqkTDhIsojHC2aLuqXTOaMMiuFoKEHxovnik4NxbIzx yQE5Js54IDBeCGs0jDGmU2myqFNfIWs0LNNGWCNNliB6fNbIjDoiazQ0yzZnzVnjXDcczTEuM9YN LTxa1pizwCJaT1LF/slzNyb1nXWRmHILDK2ddVE0O3fWxVRndNbFTH0eG1d8YrvzMTHFg0DxQnii wPuK5tjOugimu5z3FUJ0BNZFNiGJPNHULkeGPpkwnld/79nWjAlsXnd7zxHd3S6gRN3eczb3deyw Y4cFI6Rjh9kI6dih5LfTsUNuden2nsHggOzNd3vPzL1OggggE7aX9+49Mz0ssUPiy2ozv4Ime8+X c0Mbzi5b7D3jvhSZdbK520RuDSwi7Qpsh3dnV6DemaMn+15/53f8LX8AXl7UBzT+9pK4OdJC7Bku /a+KY9YCNHWbkADlbjLSWJFNuq+NqdbB1KA+NHdnIqbsGS6kr8gaWgtOuv+2Ayffk0NE9FWx5scA 9NVx78cA9TUx+MfAs1sH1EGZOUnJujVznEJ0a7eaoDS0OnGtDnTNNQlTytKaZGRcDMf6rKnFWrO0 sabp02ztAES7nmfD4dckBuZwYkEqfHN+WirLTf0ZAOACG9sxrRB03cLaNx7L/hr5thzSviMj7PrY 5BSuaFlJfdLEPqzURiUEWs/OH2QDoPni2RjqdMUKMlfYzPGOQ/1Q416rSFcqIbZ5M+GYhYKWmraG dahh27Lv8cjmq0ykpVUZJ65wsg5lB0oUNNYyRli3muAaJmkgXTf5uQqktVWpYK3WwvEZBQ22NdSz 3ByBI744XHUjO8SJNPi4uZo9srFOtszxzmGY3OUcafPRMyfHsag5skRl2bomzz76UCscyTV5DBN+ kcdYxnxmD7UJE9/6O++6Pp9dzKapxVDcWGQnzGuedo6319cg4tTkGIQJnLD+kA0s6VSjfnKSJSAz h3j2jGqLaz+Kk3c+OVgvAZqa9eEPP93txgvfP+9NIh+OpMM38XPe571ffvjLf3/6Kx2KE8BSyMNO hAvONnWWCY9qdq0ONCj2R8f6RimutKPl5ZfJOx9ZfjUic7VwhROYzxvaRzXC1oUWDrc+c3Qp15MF 1+D8DxFcJdTVVhFOQKBkhcycMDaR0Zg6nxXp5L5fKStVFAzb+ngrIdDOb6rMZxxF+JtNk0KAk9eB d1UKvzc0wrCTcRL5p4pOabqK+MqTGGA6FW++Tu5XWVQhl0m+qN/jjbvwsgEhMr+f//GfwkAFCwhB xUNgpMrjOZG/6qZLeYu46UqnUr9w4iSQ8vKO+d8//1UYHuHVdEzNtRgbUeJazDYs3banaRiO+mux ycSZwHG7PIwHTBH1bMoBBKQrHHUsuMLkJEtE1lx75ihiOEaCcOFm5YeM4CmCcE1gTaQACWJiLkdi jwG6PRKN1jewwhe1cT+1cCpAY98JaWL4EbnijrG6PR7HZ9jWieW6XEJosgjJjmG7PSRKVhKqjeDU yl2Oyj4jeHtUlPB9CRWIwKRgBFGLeDkwew3m7ZGpysyfwLhOrecIOPuM6+3BaUqhi/St+sBd1NJe js9eQ3x7fJpS2Qr4qAncRa3y5RDtNdo3gagmqWQYiqTSMW0LNhvSwGX1SeV8Zjm2Ocn5Tm1SKQ12 eeWXGrgekAoFyvDgHtXQM4gNrpGngwxODvkDCVeATx6mi/N1cbl8nAFgZXzywK8P8OmiwqZ7aBDf UYWsHCLgJd9PI9+HjyUlLLSLCiuNki4qrBhcXIn3xiEGibCVjI+R4yaXXdyG3DWtbOvm+OM2jGlk XYlcTkdz6+JywuaYYnJ5c38V+cvfkvsESm4OGM2sie1Ys2ymEigm/DfZrBbgrUEdZsH9jRwglPYU UhIp3yVwtV2tvCSrUdR9H7/7d/a8uRnTBO+z8rUASRUtM3lufGPz6/v1VUjdTdKdTeEBvW2gskKg joASdCb5ogS2SeCCDnKxiAIoQwVA6loWRb6IidLkJlBehtvI96KTL7w72hXMpWTn6QJuhdh59MCH B1e81E9Lwpn6RavF+eN336tAepQ5kRUiTZKbIP0H8NIit9vAfS/gEM5wlp/VE10mqPKoVy66arSA YaM3R9DkJpAKw57hKTyoByZ1sJDk80j1gGmgkeNpchMod4f3gfQAG/Wi0B6tHjDH+NxFkpsgLY/5 9nqAXjYiiS6b1JROYWr0gJWHti5SrTS5CaTCsG+pB6jruATmkeoBCPSAMSua3ATKR9IDdJNSwvlo 9YCjo5MXTW6CdHs9AJSrTsgQ/eFtZnCRmTWcOejKhK5XStYk07ENl5kxSZQ9bqr6tT/ifRXP0db9 wOavxqfiOZq1i6DoLNidBXvH1aazYItWnH5nwe4s2OSMuSQUu1413b1mVfBR4x7xDCIP68zmKZqw hzNtZl5oqfG52ISNEcWZY8zmo3m+WQ+MuXO6PcDNtxM1BPFFON0SLNQwxM7rlp01Fg9RdV63/AS2 gErndVuycdt53ZId2TJwiFstsk3aed1CfItyfDqv2/PecXjdgncBEDv4N78eV7BQfraERDqRgCmS dSdkJeNCKsdO3NQvx06m1C/HHOcKy/GgK0Wfyc43lBej9tDf3XoR+HWQQ5wP6K6QxkBJMYHVGk8i 2Ag/s1oEpwSeNYO2ei3C0aYWtQgHglrUIngvtqhFOHPSohbhfEaLWgRfsxa1CO7+lWqBPYEiYWVN KhRWdCyyRtQvxz67fjnmPFW/XLq3UViQHx8swiVd6tYvhygp9H2IkuJTXOF3IkqKHxQtLIdoKUwH Q6g4onsKceGXfhe+DxEYTnEKyyECg5ZDBAYrB1t6pe0DmUAmJ6Z6C4HBCyISgxdERAYviMgMig0i M2g5RGbwD0WEBi+ISA1eEBEbrPchIFKp2GDQQIDJZuWaCo2JCA0P61g0DiHSTOmHouUQmUHLITJD D2Px+Yz9vfIi8KB7+38AAAD//wMAUEsDBBQABgAIAAAAIQB0Pzl6wgAAACgBAAAeAAgBY3VzdG9t WG1sL19yZWxzL2l0ZW0xLnhtbC5yZWxzIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAhM/BigIxDAbgu+A7lNydzngQkel4WRa8ibjgtXQyM8VpU5oo+vYWTyss7DEJ+f6k3T/CrO6Y 2VM00FQ1KIyOeh9HAz/n79UWFIuNvZ0pooEnMuy75aI94WylLPHkE6uiRDYwiaSd1uwmDJYrShjL ZKAcrJQyjzpZd7Uj6nVdb3T+bUD3YapDbyAf+gbU+ZlK8v82DYN3+EXuFjDKHxHa3VgoXMJ8zJS4 yDaPKAa8YHi3mqrcC7pr9cd/3QsAAP//AwBQSwMEFAAGAAgAAAAhAKnIXKqMAAAA2gAAABMAKABj dXN0b21YbWwvaXRlbTEueG1sIKIkACigIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ALJJsgrOLy1KTi1WCE7NSU0uSU0JLqnMSbVVinEMcNSLCPZRUgAL+CXmAgWBYkoKFbk5ecVWSbZK GSUlBVb6+sXJGam5icV6+QWpeUC5tPyi3MQSILcoXT8/LS0zOdUlP7k0NzWvRN/IwMBMPykzKScz P70osSCjEmoYVYyys9GHe8aOlwsAAAD//wMAUEsDBBQABgAIAAAAIQBlux6NmwEAAOwCAAAQAAgB ZG9jUHJvcHMvYXBwLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJySQW/c IBCF75X6HyyfG+PdbTaraJao2qjKIW0jrZOcEYxtVAwI2DT77zvEWa+j3urTzBv8eHwAN6+DKV4w RO3stlxUdVmglU5p223Lx+b7xaYsYhJWCeMsbssjxvKGf/4ED8F5DEljLMjCxm3Zp+SvGYuyx0HE isaWJq0Lg0jUho65ttUSb508DGgTW9b1muFrQqtQXfjJsBwdr1/S/5oqJ3O++NQcPQXm0ODgjUjI f+Y4plIuDcAmFRqXhGn0gHy52dBgauFBdBj5V2BjAc8uqMgvL0kZS9j1IgiZiCFfLdYrYDMBvnlv tBSJ8PIfWgYXXZuKX28gimwAbL4ECM4e5SHodOQ1sHkL99pSlOUa2FhRtiC6IHwf+VUOOHWwl8Lg jhDwVpiIwM4C7NzghT3yu4P4g7poUPbWGdflq9y56st9UhUd4n1V3vV3fPSNu8383u0+ijMEzzr1 ey8kBV1dLegEZxizEeyJGSo63cnwLMAd3VkweVf613aoTmv+HWS8T+Pj5YtlVdP3xvOkEZTpVfG/ AAAA//8DAFBLAwQUAAYACAAAACEAdt0hok0BAAB4AgAAEQAIAWRvY1Byb3BzL2NvcmUueG1sIKIE ASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjJLBT8MgGMXvJv4PDfcW2mZuIW2XqNnJ JSbOaLwR+LYRCyWA6/bfS9utdtGDR3iPH+99UCyPqo4OYJ1sdInShKAING+E1LsSvW5W8QJFzjMt WN1oKNEJHFpWtzcFN5Q3Fp5tY8B6CS4KJO0oNyXae28oxo7vQTGXBIcO4raxivmwtDtsGP9kO8AZ IXdYgWeCeYY7YGxGIjojBR+R5svWPUBwDDUo0N7hNEnxj9eDVe7PA70ycSrpTyZ0OsedsgUfxNF9 dHI0tm2btHkfI+RP8fv66aWvGkvdzYoDqgrBKbfAfGOrVegmCzzZ6aZXM+fXYdBbCeL+dDH9Fjqv hYPsXqhaLAo8XYdr+lbDXSCikJMOrS7KW/7wuFmhKiNpHpNZnM43JKdkTgn56EJdne9yDxvqHO0f xCzfkIyms2viBVD1ia//SvUNAAD//wMAUEsDBBQABgAIAAAAIQCfcHe9XQMAAJQOAAASAAAAd29y ZC9mb250VGFibGUueG1sxFdBb9MwFL4j8R+i3FmdNGvSatnUpsvgwA50E0fkpu5qKY6rOF23G/cd JsSRM1euHBD/BpAQ/Aie7aTr2oQ2RRutojYv9ovz+fu+93JwdMVi45KkgvLEN609ZBokifiIJhe+ eX4WPvNMQ2Q4GeGYJ8Q3r4kwjw6fPjmYd8Y8yYQB8xPRSX1zkmXTTqMhoglhWOzxKUng2pinDGdw ml40+HhMI9Ln0YyRJGvYCLUaKYlxBvcWEzoVZp5tvk22OU9H05RHRAhYLIt1PoZpYh7mqzPmnQQz WPUZZUQYp2RuvOIM6wFTnHBBLBhziWPfRDZ8W6iJ9pEDhw3/HLMhM0UTnAqSLQYiHR5jRuPrIpqq vGr8lGbRpIhf4pTiYUz0HEEv4MJMDJFvHiOE7G4Ymjpi+WYAEddzrDxiw6L0p51HmosIbBMsTOVR QyydByKQJ5+l1tnQ+7SGSBeWFSug1nHoAQ6OwkNiYtfCQcypEPph/xWH5mPg8PPLu29f3ysgcJyd AluKnRtQ9pzQ/FHWuGIBRm04rOKrB65wxWvp8H2uMD4iaVIC0phekZGOLzPFkxtq95aY0vSC0A3C 7ipCVmsDUxzIpPi1PVMG12zIy6myD0KxgCAWcgEKG87cUhiQXQZDfcksiL2QjJWHVoFASiAgtFLJ KEBhppy1PRABn6WUpNJGKoTjgmm0lWSkgTi1hFOXFJX28SiyeQ2WK2uEKEViv9iou98avMCzjOvh WzpIcZecBOCAj0mL759uqh1kMCt0XuogCAizi4PsClHBDYDI9rxQAreqnIewkB8fPwNEb056dtOy FWMexCdzHhT1U1ZCD0mdrD9kESm1B5ggfbKmPfR5NmNlheTX7c3vD29zRq/RQBZb+dlAA6vMQesX 2568FXQdd1JptfsulJLeKg+amyACE22rPNs76MuBcf7COOHZhEalxmEjDYerioknTbTUOLzSHqw+ HIoc9nIP1uoGbthfhwN4q4tOFWOgm60Lh2JMMCF/gaK9IzPqVpP/y4sAsyH0oxU4yHZct+WyPa+i BMhVdd/3W636PUZXKeR4SSHKC5CzppCFrVRRAkRdlxIBjilAUYFEqF5MVEteG4kdxCGr6D1xSCS6 wUIutV5QNiKRv6mIwz8AAAD//wMAUEsDBBQABgAIAAAAIQBK2IqSuwAAAAQBAAAUAAAAd29yZC93 ZWJTZXR0aW5ncy54bWyMzsFqwzAMxvF7Ye8QdF+d9TBKSFIooy/Q9QFcR2kMsWQkbd729DVsl916 FJ/48e8PX2ltPlE0Mg3wsm2hQQo8RboNcHk/Pe+hUfM0+ZUJB/hGhcP4tOlLV/B6RrP6qU1VSDsZ YDHLnXMaFkxet5yR6jazJG/1lJvjeY4B3zh8JCRzu7Z9dYKrt1qgS8wKf1p5RCssUxYOqFpD0vrr JR8JxtrI2WKKP3hiOQoXRXFj7/61j3cAAAD//wMAUEsDBBQABgAIAAAAIQDNLRp69gAAAGwBAAAT AAgBZG9jUHJvcHMvY3VzdG9tLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AJyQy26DMBBF95X6D5b3jgdSkoAMUQPJuou0e8sYgoQfsh1aVPXfa5Q+9lnO3NGZM8P2H2pEk3R+ MLrEyQowklqYdtB9iV/PJ7LDyAeuWz4aLUs8S4/31eMDe3HGShcG6VFEaF/iSwi2oNSLi1Tcr2Ks Y9IZp3iIpeup6bpByMaIq5I60BRgQ8XVB6OI/cPhG6+Ywr3I1ojFzr+dZxt1K/YDn1GnwtCW+LPJ 6qbJICPpMa9JAsmB5Ot8S2AHkB7S+pQ/H78wsstwipHmKp7uu5H3kTaFYrTvPrgqWW9yeAKALaP/ XUZ/91WMLiK3N1XfAAAA//8DAFBLAQItABQABgAIAAAAIQCMimiR9gEAAOIKAAATAAAAAAAAAAAA AAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAJlVfgUEAQAA4QIAAAsA AAAAAAAAAAAAAAAALwQAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAG8BpR95AQAAUggAABwA AAAAAAAAAAAAAAAAZAcAAHdvcmQvX3JlbHMvZG9jdW1lbnQueG1sLnJlbHNQSwECLQAUAAYACAAA ACEAxR+vgmchAAAg0gEAEQAAAAAAAAAAAAAAAAAfCgAAd29yZC9kb2N1bWVudC54bWxQSwECLQAU AAYACAAAACEAz4kcKlMBAAD/AgAAEAAAAAAAAAAAAAAAAAC1KwAAd29yZC9mb290ZXIzLnhtbFBL AQItABQABgAIAAAAIQAukAR+awMAAPEJAAAQAAAAAAAAAAAAAAAAADYtAAB3b3JkL2Zvb3RlcjIu eG1sUEsBAi0AFAAGAAgAAAAhAGx7IwgkBQAAvxEAABAAAAAAAAAAAAAAAAAAzzAAAHdvcmQvaGVh ZGVyMi54bWxQSwECLQAUAAYACAAAACEAvejRAVMBAAD/AgAAEAAAAAAAAAAAAAAAAAAhNgAAd29y ZC9oZWFkZXIxLnhtbFBLAQItABQABgAIAAAAIQDfKmCgagEAALMDAAARAAAAAAAAAAAAAAAAAKI3 AAB3b3JkL2VuZG5vdGVzLnhtbFBLAQItABQABgAIAAAAIQA/ZfsNagEAALkDAAASAAAAAAAAAAAA AAAAADs5AAB3b3JkL2Zvb3Rub3Rlcy54bWxQSwECLQAUAAYACAAAACEAWGCzG7oAAAAiAQAAGwAA AAAAAAAAAAAAAADVOgAAd29yZC9fcmVscy9oZWFkZXIyLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAh AL3o0QFTAQAA/wIAABAAAAAAAAAAAAAAAAAAyDsAAHdvcmQvaGVhZGVyMy54bWxQSwECLQAUAAYA CAAAACEAz4kcKlMBAAD/AgAAEAAAAAAAAAAAAAAAAABJPQAAd29yZC9mb290ZXIxLnhtbFBLAQIt ABQABgAIAAAAIQDHHG0UnAYAAFEbAAAVAAAAAAAAAAAAAAAAAMo+AAB3b3JkL3RoZW1lL3RoZW1l MS54bWxQSwECLQAKAAAAAAAAACEAxxn+6ieNAAAnjQAAFgAAAAAAAAAAAAAAAACZRQAAd29yZC9t ZWRpYS9pbWFnZTEuanBlZ1BLAQItABQABgAIAAAAIQDdQ7CRNwYAAEkSAAARAAAAAAAAAAAAAAAA APTSAAB3b3JkL3NldHRpbmdzLnhtbFBLAQItABQABgAIAAAAIQAhgq5MUw4AAHdWAAAPAAAAAAAA AAAAAAAAAFrZAAB3b3JkL3N0eWxlcy54bWxQSwECLQAUAAYACAAAACEAM4AhTeEAAABVAQAAGAAA AAAAAAAAAAAAAADa5wAAY3VzdG9tWG1sL2l0ZW1Qcm9wczEueG1sUEsBAi0AFAAGAAgAAAAhAIOl ZM3xCwAAPY4AABIAAAAAAAAAAAAAAAAAGekAAHdvcmQvbnVtYmVyaW5nLnhtbFBLAQItABQABgAI AAAAIQB0Pzl6wgAAACgBAAAeAAAAAAAAAAAAAAAAADr1AABjdXN0b21YbWwvX3JlbHMvaXRlbTEu eG1sLnJlbHNQSwECLQAUAAYACAAAACEAqchcqowAAADaAAAAEwAAAAAAAAAAAAAAAABA9wAAY3Vz dG9tWG1sL2l0ZW0xLnhtbFBLAQItABQABgAIAAAAIQBlux6NmwEAAOwCAAAQAAAAAAAAAAAAAAAA ACX4AABkb2NQcm9wcy9hcHAueG1sUEsBAi0AFAAGAAgAAAAhAHbdIaJNAQAAeAIAABEAAAAAAAAA AAAAAAAA9voAAGRvY1Byb3BzL2NvcmUueG1sUEsBAi0AFAAGAAgAAAAhAJ9wd71dAwAAlA4AABIA AAAAAAAAAAAAAAAAev0AAHdvcmQvZm9udFRhYmxlLnhtbFBLAQItABQABgAIAAAAIQBK2IqSuwAA AAQBAAAUAAAAAAAAAAAAAAAAAAcBAQB3b3JkL3dlYlNldHRpbmdzLnhtbFBLAQItABQABgAIAAAA IQDNLRp69gAAAGwBAAATAAAAAAAAAAAAAAAAAPQBAQBkb2NQcm9wcy9jdXN0b20ueG1sUEsFBgAA AAAaABoAlQYAACMEAQAAAA== --_004_F82A4B6D50F9464B8EBA55651F541CF84319B82ESZXEML552MBXchi_-- From zhangfatai@huawei.com Wed May 22 19:39:06 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2E8421F91CB for ; Wed, 22 May 2013 19:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.898 X-Spam-Level: X-Spam-Status: No, score=-5.898 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlY4BnZiMYh8 for ; Wed, 22 May 2013 19:39:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1B521F91B2 for ; Wed, 22 May 2013 19:38:59 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARQ41680; Thu, 23 May 2013 02:38:58 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 23 May 2013 03:38:42 +0100 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 23 May 2013 10:38:52 +0800 Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.235]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.01.0323.007; Thu, 23 May 2013 10:38:41 +0800 From: Fatai Zhang To: Fatai Zhang , Lou Berger , CCAMP Thread-Topic: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues) Thread-Index: AQHOViWQY0rdNLd8TU6gdPkEdNxSL5kSC4BggAAFHTA= Date: Thu, 23 May 2013 02:38:40 +0000 Message-ID: References: <518A82D9.7080508@labn.net> <518BAB17.9090807@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> <518CED28.30303@labn.net> <51924382.2010904@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C90D5@ESESSMB301.ericsson.se> <13ea7ed3bdd.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <5193A26A.1090005@labn.net> <519649B4.5060408@labn.net> <519B73C9.2030308@labn.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: multipart/alternative; boundary="_000_F82A4B6D50F9464B8EBA55651F541CF84319B852SZXEML552MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" Subject: Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 02:39:06 -0000 --_000_F82A4B6D50F9464B8EBA55651F541CF84319B852SZXEML552MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Lou, An typed error should be corrected: For 0x05, why you think that RFC4328 does not cover it (ie., G-PID=3D54)? Best Regards Fatai From: Fatai Zhang Sent: Thursday, May 23, 2013 10:35 AM To: 'Lou Berger'; CCAMP Cc: draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org Subject: RE: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issu= es) Hi Lou, I incorporated your proposal into my table to facilitate the readers. I think you still insist on reusing some existing G-PIDs like 58, 56. For = 0x04, why you think that RFC4328 does not cover it (ie., G-PID=3D54)? Technically, I am not convince by your proposal, but I would like to reserv= e my opinion for your same motivation (ie., to conclude the discussion as s= oon as possible). Any opinions on Lou's proposal from the WG? I will update the signaling dra= ft based on Lou's proposal if there is no comment on Lou's proposal. Note that all the new G-PID values will be re-ordered with TBA. G-PIDs vs Payload types defined in Table 15-8 of G.709 Payload Type in Hex code defined in G.709 G-PID LSP Encoding Note Interpretation from G.709 0x01 None Not needed Experimental mapping (Note 3) 0x02 49 G.709 ODUk, G.709 OCh 1)G-PID defined in RFC4328; 2) Updated in this draft. Asynchronous CBR mapping, see clause 17.2 0x03 50 G.709 ODUk ditto Bit synchronous CBR mapping, see clause 17.2 0x04 32 SDH, G.709 ODUk ditto ATM mapping, see clause 17.3 0x05 54 or TBA (Suggested by Lou) G.709 ODUk (and SDH) G-PIDs defined in RFC4328 for framed GFP GFP mapping, see clause 17.4 0x06 None Not needed and Not defined in RFC4328 Virtual Concatenated signal, see clause 18 (Note 5) 0x07 61(TBA) Or 55(Suggested by Lou) G.709 ODUk (k=3D0,3,4) Is being defined in this draft (new payload type defined in [G.709-2012]) PCS codeword transparent Ethernet mapping: * 1000BASE-X into OPU0, see clauses 17.7.1 and 17.7.1.1 * 40GBASE-R into OPU3, see clauses 17.7.4 and 17.7.4.1 * 100GBASE-R into OPU4, see clauses 17.7.5 and 17.7.5.1 0x08 62(TBA) Or 58(Suggested by Lou) G.709 ODUk (k=3D2e) ditto FC-1200 into OPU2e mapping, see clause 17.8.2 0x09 63(TBA) G.709 ODUk (k=3D2) ditto GFP mapping into Extended OPU2 payload, see clause 17.4.1 (Note 6) 0x0A 64(TBA) G.709 ODUk (k=3D0) ditto STM-1 mapping into OPU0, see clause 17.7.1 0x0B 65(TBA) G.709 ODUk (k=3D0) ditto STM-4 mapping into OPU0, see clause 17.7.1 0x0C 66(TBA) Or 58(Suggested by Lou) G.709 ODUk (k=3D0) ditto FC-100 mapping into OPU0, see clause 17.7.1 0x0D 67(TBA) Or 58(Suggested by Lou) G.709 ODUk (k=3D1) ditto FC-200 mapping into OPU1, see clause 17.7.2 0x0E 68(TBA) Or 58(Suggested by Lou) G.709 ODUflex ditto FC-400 mapping into OPUflex, see clause 17.9 0x0F 69(TBA) Or 58(Suggested by Lou) G.709 ODUflex ditto FC-800 mapping into OPUflex, see clause 17.9 0x10 51 G.709 ODUk 1)G-PID defined in RFC4328; 2) Updated in this draft. Bit stream with octet timing mapping, see clause 17.6.1 0x11 52 G.709 ODUk ditto Bit stream without octet timing mapping, see clause 17.6.2 0x12 70(TBA) G.709 ODUflex Is being defined in this draft (new payload type defined in [G.709-2012]) IB SDR mapping into OPUflex, see 17.9 0x13 71(TBA) G.709 ODUflex ditto IB DDR mapping into OPUflex, see 17.9 0x14 72(TBA) G.709 ODUflex ditto IB QDR mapping into OPUflex, see 17.9 0x15 73(TBA) G.709 ODUk (k=3D0) ditto SDI mapping into OPU0, see 17.7.1 0x16 74(TBA) G.709 ODUk (k=3D1) ditto (1.485/1.001) Gbit/s SDI mapping into OPU1, see 17.7.2 0x17 75(TBA) G.709 ODUk (k=3D1) ditto 1.485 Gbit/s SDI mapping into OPU1, see 17.7.2 0x18 76(TBA) G.709 ODUflex ditto (2.970/1.001) Gbit/s SDI mapping into OPUflex, see 17.9 0x19 77(TBA) G.709 ODUflex ditto 2.970 Gbit/s SDI mapping into OPUflex, see 17.9 0x1A 78(TBA) Or 56(Suggested by Lou) G.709 ODUk (k=3D0) ditto SBCON/ESCON mapping into OPU0, see 17.7.1 0x1B 79(TBA) G.709 ODUk (k=3D0) ditto DVB_ASI mapping into OPU0, see 17.7.1 0x20 47 G.709 ODUk 1) G-PIDs defined in RFC4328. 2) Updated in this draft. ODU multiplex structure supporting ODTUjk only, see clause 19 (AMP only) 0x21 59/60(TBA) G.709 ODUk 1)Are being defined in this draft (new payload type defined in [G.709-2012]= ); 2) 59 for G.709 ODU-1.25G; 60 for G.709 ODU-any ODU multiplex structure supporting ODTUk.ts or ODTUk.ts and ODTUjk, see cla= use 19 (GMP capable) (Note 7) 55 None Not needed Not available (Note 2) 66 None Not needed Not available (Note 2) 80-8F None Not needed Reserved codes for proprietary use (Note 4) FD None Or TBA(Suggested by Lou) Not needed NULL test signal mapping, see clause 17.5.1 FE None Or TBA(Suggested by Lou) Not needed PRBS test signal mapping, see clause 17.5.2 FF None Not needed Not available (Note 2) Best Regards Fatai -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of L= ou Berger Sent: Tuesday, May 21, 2013 9:17 PM To: CCAMP Cc: draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org Subject: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues) All, In the interest of moving this discussion quickly to closure, I spent some time trying to come up with the full list of G.709 PT to G-PID mappings. In coming up with this list I tried to be consistent with the last consensus point that I can identify on this topic (the previously referenced July 2012 thread & presentation), which included: A) Defining new G-PIDs for client types not identified by an assigned G-PID (per http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parameters.x= ml) B) Reusing G-PID wherever {G-PID, ODU rate} unambiguously identify a G.709 payload type, and define new G-PIDs when reuse not possible. C) No G-PID value for unused, reserved, or proprietary 709 Payload Type. Here's what I've come up with: G.709 Payload Type G-PID Type/Comment LSP Encoding =3D=3D=3D=3D =3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 0x01 No standard value 0x02 49 CBRa G.709 ODUk 0x03 50 CBRb G.709 ODUk 0x04 32 ATM G.709 ODUk 0x05 TBA1 Framed GFP G.709 ODUk 0x06 ??? Is any valued needed? 0x07 55 Ethernet PHY G.709 ODUk (k=3D0) (transparent G.709 ODUk (k=3D3) GFP) G.709 ODUk (k=3D4) 0x08 58 Fiber Channel G.709 ODUk (k=3D2e) 0x09 TBA1 Framed GFP G.709 ODUk (k=3D2e) 0x0A TBA2 STM-1 G.709 ODUk (k=3D0) 0x0B TBA3 STM-4 G.709 ODUk (k=3D0) 0x0C 58 Fiber Channel G.709 ODUk (k=3D0) 0x0D 58 Fiber Channel G.709 ODUk (k=3D1) 0x0E 58 Fiber Channel G.709 ODUflex 0x0F 58 Fiber Channel G.709 ODUflex 0x10 51 BSOT G.709 ODUk 0x11 52 BSNT G.709 ODUk 0x12 TBA4 InfiniBand G.709 ODUflex 0x13 TBA4 InfiniBand G.709 ODUflex 0x14 TBA4 InfiniBand G.709 ODUflex 0x15 TBA5 Serial Digital G.709 ODUk (k=3D0) Interface 0x16 TBA6 Serial Digital G.709 ODUk (k=3D1) Interface/1.001 0x17 TBA5 Serial Digital G.709 ODUk (k=3D1) Interface 0x18 TBA6 Serial Digital G.709 ODUflex Interface/1.001 0x19 TBA5 Serial Digital G.709 ODUflex Interface 0x1A 56 SBCON/ESCON G.709 ODUk (k=3D0) (IANA to update Type field) 0x1B TBA7 DVB_ASI G.709 ODUk (k=3D0) 0x1C 58 Fiber Channel G.709 ODUk 0x20 47 G.709 ODU-2.5G G.709 ODUk (k=3D2,3) (IANA to update Type field) TBA8 G.709 ODU-1.25G G.709 ODUk (k=3D1,2,3) 0x21 TBA8 G.709 ODU-1.25G G.709 ODUk (k=3D2,3,4) TBA9 G.709 ODU-Any G.709 ODUk (k=3D2,3) 0x55 No standard value 0x66 No standard value 0x80-0x8F No standard value 0xFD TBA10 Null Test G.709 ODUk 0xFE TBA11 Random Test G.709 ODUk 0xFF No standard value Note that there are a few differences with Fatai's list, which doesn't format well in e-mail, but is available in the archive http://www.ietf.org/mail-archive/web/ccamp/current/msg14845.html Please speak up if you think the above is not aligned with prior consensus or if you have an issue with any of the above. Much thanks, Lou On 5/20/2013 5:09 AM, Fatai Zhang wrote: > Hi Lou, > > > > I think my mail on March 13rd may have answered your following comments. > My response quoted as follows. > > > > In addition, if people look at the full list that I provided, I think > people can realize that RFC4328 (section 3.1.3) used the same approach > as the current approach of this draft (ie., 1:1 mapping between GPIDs > and payload types defined by G.709), ie., we are following what RFC4328 > did. > > > > BTW, I am not sure if we need spend so much on discussing this point > (because there is no issue to stick to the data plane by using the > current approach of this draft). > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > (2) 'Grouped GPID' vs '1:1' mapping (between G.709-2012 and GPIDs > defined in this draft) > > > > We realize that it is safe to use 1:1 mapping approach to avoid some > potential issues after investigation. We know this payload types have > been defined by G.709 (data plane), so physically it is better to use > 1:1 mapping approach. > > For the potential issues I mentioned above, for example, we cannot use > the existing 34 to represent 'STM-1' and 'STM-4 ', because it is > impossible to differentiate which one is 'STM-1' or 'STM-4'. In > addition, from the concept of payload type, we know that e.g, FC-100 is > different from FC-800, right? So, it is better to assign different GPIDs > to these different payload types defined by the data plane. > > > > Furthermore, I think it is much cheaper to create new GPIDs in the > control plane than in the data plane (these payload types will be > carried in the OH). > > > > > > > > > > Best Regards > > > > Fatai > > > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Friday, May 17, 2013 11:16 PM > To: Fatai Zhang > Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; > draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org > Subject: Re: R: Closing G.709 open issues > > > > Fatai, > > > > That's a great start for the WG. Thank you. > > > > To answer your implied question as to why my request for the full list. > > My feeling is that there have been too many "surprises" on the 709 > > documents in areas that I thought were either obvious (but from the IETF > > & GMPLS context, not ITU-T or G.709 perspectives) or resolved by past > > discussions. At this point, as co-chair and Document shepherd, I want > > to ensure that any open point on the documents are unambiguously closed > > and that past discussions (i.e., points of consensus) are 100% captured, > > so that we can smoothly move through the planned second LC and > > publication request. > > > > To that end, in my previous message I asked two questions about points > > where it seems you are proposing moving away from what has been > > previously been discussed & agreed to by the WG. Can you answer the > > following: > > > >>> My questions on the new G-PIDs come down to: > >>> - Why are rate specific G-PIDs being proposed (rather than > >>> continuing to use the previous approach documented in the draft > >>> and in Section 3.1.3 of rfc4328)? > > > >>> - Why are new values being defined rather than using existing > >>> values, e.g., G-PID 56? > >>> > > > > Much thanks, > > Lou > > > > > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --_000_F82A4B6D50F9464B8EBA55651F541CF84319B852SZXEML552MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Lou,=

&n= bsp;

An type= d error should be corrected:

&n= bsp;

For = 0x05, why you think that RFC4328 does not cover it (ie., G-PID=3D54)= ?

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

Best Re= gards

&n= bsp;

Fatai

&n= bsp;

From: Fatai Zhang
Sent: Thursday, May 23, 2013 10:35 AM
To: 'Lou Berger'; CCAMP
Cc: draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org
Subject: RE: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 op= en issues)

 

Hi L= ou,

 

I in= corporated your proposal into my table to facilitate the readers.

 

I th= ink you still insist on reusing some existing G-PIDs like 58, 56.  For= 0x04, why you think that RFC4328 does not cover it (ie., G-PID=3D54)?

 

Tech= nically, I am not convince by your proposal, but I would like to reserve my= opinion for your same motivation (ie., to conclude the discussion as soon = as possible).

 

Any = opinions on Lou’s proposal from the WG? I will update the signaling d= raft based on Lou’s proposal if there is no comment on Lou’s pr= oposal.

 

Note= that all the new G-PID values will be re-ordered with TBA.

 

G-PIDs vs Payload types defined in Table 15-8 = of G.709

 

Pa= yload Type in Hex code defined in G.709

G-PID

LS= P Encoding

No= te

In= terpretation from G.709

0x01

None

 

Not needed

Experimental mapping (Note 3)

0x02

49

G.709 ODUk, G.709 OCh

1)G-PID defined in RFC4328;

2) Updated in this draft.

Asynchronous CBR mapping, see clause 17.2

0x03

50

G.709 ODUk

ditto

Bit synchronous CBR mapping, see clause 17.2

0x04

32

SDH, G.709 ODUk

ditto

ATM mapping, see clause 17.3

0x05

54

or

TBA (= Suggested by Lou)

G.709 ODUk (and SDH)=

 

G-PIDs defined in RFC4328 for framed GFP

 

GFP mapping, see clause 17.4

0x06

None

 

Not needed and Not defined in R= FC4328

Virtual Concatenated signal, se= e clause 18 (Note 5)

0x07

61(TBA)

Or 55(Suggested by Lou)=

G.709 ODUk (k=3D0,3,4)

Is being defined in this draft = (new payload type defined in [G.709-2012])

PCS codeword transparent Ethern= et mapping:

·        1000BASE-X into OPU0, s= ee clauses 17.7.1 and 17.7.1.1

·        40GBASE-R into OPU3, se= e clauses 17.7.4 and 17.7.4.1

·        100GBASE-R into OPU4, s= ee clauses 17.7.5 and 17.7.5.1

0x08

62(TBA)

Or 58(Suggested by Lou)=

G.709 ODUk (k=3D2e)

ditto

FC-1200 into OPU2e mapping, see= clause 17.8.2

0x09

63(TBA)

G.709 ODUk (k=3D2)

ditto

GFP mapping into Extended OPU2 = payload, see clause 17.4.1 (Note 6)

0x0A

64(TBA)

G.709 ODUk (k=3D0)

ditto

STM-1 mapping into OPU0, see cl= ause 17.7.1

0x0B

65(TBA)

G.709 ODUk (k=3D0)

ditto

STM-4 mapping into OPU0, see cl= ause 17.7.1

0x0C

66(TBA)

Or 58(Suggested by Lou)=

G.709 ODUk (k=3D0)

ditto

FC-100 mapping into OPU0, see c= lause 17.7.1

0x0D

67(TBA)

Or 58(Suggested by Lou)=

G.709 ODUk (k=3D1)

ditto

FC-200 mapping into OPU1, see c= lause 17.7.2

0x0E

68(TBA)

Or 58(Suggested by Lou)=

G.709 ODUflex

ditto

FC-400 mapping into OPUflex, se= e clause 17.9

0x0F

69(TBA)

Or 58(Suggested by Lou)=

G.709 ODUflex

ditto

FC-800 mapping into OPUflex, se= e clause 17.9

0x10

51

G.709 ODUk

1)G-PID defined in RFC4328;

2) Updated in this draft.<= /o:p>

Bit stream with octet timing ma= pping, see clause 17.6.1

0x11

52

G.709 ODUk

ditto

Bit stream without octet timing= mapping, see clause 17.6.2

0x12

70(TBA)

G.709 ODUflex

Is being defined in this draft = (new payload type defined in [G.709-2012])

IB SDR  mapping into OPUfl= ex, see 17.9

0x13

71(TBA)

G.709 ODUflex

ditto

IB DDR mapping into OPUflex, se= e 17.9

0x14

72(TBA)

G.709 ODUflex

ditto

IB QDR mapping into OPUflex, se= e 17.9

0x15

73(TBA)

G.709 ODUk (k=3D0)

ditto

SDI  mapping into OPU0, se= e 17.7.1

0x16

74(TBA)

G.709 ODUk (k=3D1)

ditto

(1.485/1.001) Gbit/s SDI mappin= g into OPU1, see 17.7.2

0x17

75(TBA)

G.709 ODUk (k=3D1)

ditto

1.485 Gbit/s SDI mapping into O= PU1, see 17.7.2

0x18

76(TBA)

G.709 ODUflex

ditto

(2.970/1.001) Gbit/s SDI mappin= g into OPUflex, see 17.9

0x19

77(TBA)

G.709 ODUflex

ditto

2.970 Gbit/s SDI mapping into O= PUflex, see 17.9

0x1A

78(TBA)

Or 56(Suggested by Lou)=

G.709 ODUk (k=3D0)

ditto

SBCON/ESCON mapping into OPU0, = see 17.7.1

0x1B

79(TBA)

G.709 ODUk (k=3D0)

ditto

DVB_ASI mappin= g into OPU0, see 17.7.1

0x20

47

G.709 ODUk

1) G-PIDs defined in RFC4328. <= o:p>

2) Updated in this draft.<= /o:p>

ODU multiplex structure support= ing ODTUjk only, see clause 19 (AMP only)

0x21

59/60(TBA)

G.709 ODUk

1)Are being de= fined in this draft (new payload type defined in [G.709-2012]);<= /span>

2) 59 for G.709 ODU-1.25G; 60 f= or G.709 ODU-any

ODU multiplex = structure supporting ODTUk.ts or ODTUk.ts and ODTUjk, see clause 19 (GMP ca= pable) (Note 7)

55

None

 

Not needed

Not available (Note 2)

66

None

 

Not needed

Not available (Note 2)

80-8F

None

 

Not needed

Reserved codes for proprietary = use (Note 4)

FD

None

Or TBA(Suggested by Lou= )

 

Not needed

NULL test signal mapping, see c= lause 17.5.1

FE

None

Or TBA(Suggested by Lou= )

 

Not needed

PRBS test signal mapping, see c= lause 17.5.2

FF

None

 

Not needed

Not available (Note 2)

 

 

 

 

 

 

 

 

 

Best= Regards

 

Fata= i

 

 

-----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of L= ou Berger
Sent: Tuesday, May 21, 2013 9:17 PM
To: CCAMP
Cc: draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org
Subject: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues)<= o:p>

 

All,

 

In the interest of moving th= is discussion quickly to closure, I spent

some time trying to come up = with the full list of G.709 PT to G-PID

mappings.  In coming up= with this list I tried to be consistent with

the last consensus point tha= t I can identify on this topic (the

previously referenced July 2= 012 thread & presentation), which included:

 

A) Defining new G-PIDs for c= lient types not identified by an assigned

G-PID (per=

http://www.iana.org/assignme= nts/gmpls-sig-parameters/gmpls-sig-parameters.xml)

 

B) Reusing G-PID wherever {G= -PID, ODU rate} unambiguously identify a

G.709 payload type, and defi= ne new G-PIDs when reuse not possible.

 

C) No G-PID value for unused= , reserved, or proprietary 709 Payload Type.

 

Here's what I've come up wit= h:

 

    G.709

   Payload

    Type = ;  G-PID   Type/Comment    LSP Encoding<= /o:p>

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

    0x01 = ;          No standard value

    0x02 = ;   49     CBRa     =        G.709 ODUk

    0x03 = ;   50     CBRb     =        G.709 ODUk

    0x04 = ;   32     ATM      =        G.709 ODUk

    0x05 = ;   TBA1   Framed GFP      G.7= 09 ODUk

    0x06 = ;   ???    Is any valued needed?=

    0x07 = ;   55     Ethernet PHY    G.7= 09 ODUk (k=3D0)

    &nbs= p;            &= nbsp; (transparent    G.709 ODUk (k=3D3)

    &nbs= p;            &= nbsp; GFP)           = ; G.709 ODUk (k=3D4)

    0x08 = ;   58     Fiber Channel   G.709 OD= Uk (k=3D2e)

    0x09 = ;   TBA1   Framed GFP      G.7= 09 ODUk (k=3D2e)

    0x0A = ;   TBA2   STM-1      &nb= sp;    G.709 ODUk (k=3D0)

    0x0B = ;   TBA3   STM-4      &nb= sp;    G.709 ODUk (k=3D0)

    0x0C = ;   58     Fiber Channel   G.709 OD= Uk (k=3D0)

    0x0D = ;   58     Fiber Channel   G.709 OD= Uk (k=3D1)

    0x0E = ;   58     Fiber Channel   G.709 OD= Uflex

    0x0F = ;   58     Fiber Channel   G.709 OD= Uflex

    0x10 = ;   51     BSOT     =        G.709 ODUk

    0x11 = ;   52     BSNT     =        G.709 ODUk

    0x12 = ;   TBA4   InfiniBand      G.7= 09 ODUflex

    0x13 = ;   TBA4   InfiniBand      G.7= 09 ODUflex

    0x14 = ;   TBA4   InfiniBand      G.7= 09 ODUflex

    0x15 = ;   TBA5   Serial Digital  G.709 ODUk (k=3D0)=

    &nbs= p;            &= nbsp; Interface

    0x16 = ;   TBA6   Serial Digital  G.709 ODUk (k=3D1)=

    &nbs= p;            &= nbsp; Interface/1.001

    0x17 = ;   TBA5   Serial Digital  G.709 ODUk (k=3D1)=

    &nbs= p;            &= nbsp; Interface

    0x18 = ;   TBA6   Serial Digital  G.709 ODUflex

    &nbs= p;            &= nbsp; Interface/1.001

    0x19 = ;   TBA5   Serial Digital  G.709 ODUflex

    &nbs= p;            &= nbsp; Interface

    0x1A = ;   56     SBCON/ESCON    = ; G.709 ODUk (k=3D0)

    &nbs= p;            &= nbsp; (IANA to update Type field)

    0x1B = ;   TBA7   DVB_ASI      &= nbsp;  G.709 ODUk (k=3D0)

    0x1C = ;   58     Fiber Channel   G.709 OD= Uk

    0x20 = ;   47     G.709 ODU-2.5G  G.709 ODUk

    &nbs= p;            &= nbsp;           &nbs= p;       (k=3D2,3)

    &nbs= p;            &= nbsp; (IANA to update Type field)

    &nbs= p;       TBA8   G.709 ODU-1.25G G.7= 09 ODUk

    &nbs= p;            &= nbsp;           &nbs= p;       (k=3D1,2,3)

    0x21 = ;   TBA8   G.709 ODU-1.25G G.709 ODUk=

    &nbs= p;            &= nbsp;           &nbs= p;       (k=3D2,3,4)

    &nbs= p;       TBA9   G.709 ODU-Any =   G.709 ODUk

    &nbs= p;            &= nbsp;           &nbs= p;     (k=3D2,3)

    0x55 = ;          No standard value

    0x66 = ;          No standard value

    0x80-0x8F=       No standard value

    0xFD = ;   TBA10  Null Test       G.7= 09 ODUk

    0xFE = ;   TBA11  Random Test     G.709 ODUk

    0xFF = ;          No standard value

 

Note that there are a few di= fferences with Fatai's list, which doesn't

format well in e-mail, but i= s available in the archive

http://www.ietf.org/mail-arc= hive/web/ccamp/current/msg14845.html

 

Please speak up if you think= the above is not aligned with prior

consensus or if you have an = issue with any of the above.

 

Much thanks,

Lou

 

 

On 5/20/2013 5:09 AM, Fatai = Zhang wrote:

> Hi Lou,

>

> 

>

> I think my mail on Marc= h 13rd may have answered your following comments.

> My response quoted as f= ollows.

>

> 

>

> In addition, if people = look at the full list that I provided, I think

> people can realize that= RFC4328 (section 3.1.3) used the same approach

> as the current approach= of this draft (ie., 1:1 mapping between GPIDs

> and payload types defin= ed by G.709), ie., we are following what RFC4328

> did.<= /p>

>

> 

>

> BTW, I am not sure if w= e need spend so much on discussing this point

> (because there is no is= sue to stick to the data plane by using the

> current approach of thi= s draft).

>

> 

>

> =3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

>

> (2) 'Grouped GPID' vs '= 1:1' mapping (between G.709-2012 and GPIDs

> defined in this draft)<= o:p>

>

> 

>

> We realize that it is s= afe to use 1:1 mapping approach to avoid some

> potential issues after = investigation. We know this payload types have

> been defined by G.709 (= data plane), so physically it is better to use

> 1:1 mapping approach.

>

> For the potential issue= s I mentioned above, for example, we cannot use

> the existing 34 to repr= esent 'STM-1' and 'STM-4 ', because it is

> impossible to different= iate which one is 'STM-1' or 'STM-4'. In

> addition, from the conc= ept of payload type, we know that e.g, FC-100 is

> different from FC-800, = right? So, it is better to assign different GPIDs

> to these different payl= oad types defined by the data plane.

>

> 

>

> Furthermore, I think it= is much cheaper to create new GPIDs in the

> control plane than in t= he data plane (these payload types will be

> carried in the OH).

>

> 

>

> 

>

> 

>

> 

>

> Best Regards=

>

> 

>

> Fatai=

>

> 

>

> -----Original Message--= ---

> From: Lou Berger [mailt= o:lberger@labn.net]

> Sent: Friday, May 17, 2= 013 11:16 PM

> To: Fatai Zhang

> Cc: BELOTTI, SERGIO (SE= RGIO); Daniele Ceccarelli; CCAMP;

> draft-ietf-ccamp-gmpls-= signaling-g709v3@tools.ietf.org

> Subject: Re: R: Closing= G.709 open issues

>

> 

>

> Fatai,

>

>    =     

>

> That's a great start fo= r the WG.  Thank you.

>

> 

>

> To answer your implied = question as to why my request for the full list.

>

> My feeling is that ther= e have been too many "surprises" on the 709

>

> documents in areas that= I thought were either obvious (but from the IETF

>

> & GMPLS context, no= t ITU-T or G.709 perspectives) or resolved by past

>

> discussions.  At t= his point, as co-chair and Document shepherd, I want

>

> to ensure that any open= point on the documents are unambiguously closed

>

> and that past discussio= ns (i.e., points of consensus) are 100% captured,

>

> so that we can smoothly= move through the planned second LC and

>

> publication request.

>

> 

>

> To that end, in my prev= ious message I asked two questions about points

>

> where it seems you are = proposing moving away from what has been

>

> previously been discuss= ed & agreed to by the WG.  Can you answer the

>

> following:

>

> 

>

>>> My questions on= the new G-PIDs come down to:

>

>>> - Why are rate = specific G-PIDs being proposed (rather than

>

>>>   con= tinuing to use the previous approach documented in the draft

>

>>>   and= in Section 3.1.3 of rfc4328)?

>

> 

>

>>> - Why are new v= alues being defined rather than using existing

>

>>>   val= ues, e.g., G-PID 56?

>

>>>

>

> 

>

> Much thanks,=

>

> Lou

>

> 

>

> 

>

____________________________= ___________________

CCAMP mailing list

CCAMP@ietf.org

https://www.ietf.org/mailman= /listinfo/ccamp

--_000_F82A4B6D50F9464B8EBA55651F541CF84319B852SZXEML552MBXchi_-- From zhangfatai@huawei.com Wed May 22 19:45:31 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 006DA11E8163 for ; Wed, 22 May 2013 19:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67aAF3pYSpNU for ; Wed, 22 May 2013 19:45:26 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 98D0811E8145 for ; Wed, 22 May 2013 19:45:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARQ42067; Thu, 23 May 2013 02:45:23 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 23 May 2013 03:45:11 +0100 Received: from SZXEML422-HUB.china.huawei.com (10.82.67.161) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 23 May 2013 03:45:22 +0100 Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.235]) by szxeml422-hub.china.huawei.com ([10.82.67.161]) with mapi id 14.01.0323.007; Thu, 23 May 2013 10:45:16 +0800 From: Fatai Zhang To: John E Drake , Lou Berger Thread-Topic: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 open issues) Thread-Index: AQHOUz2wRZxL9IlXX0COWaVQpGYsjZkNi3gAgABbtICAAAntgIAAFyOAgABhfgCAAKl/gIAAglWAgABHJgCAAAHwAIABGF6AgAAI+4CAAPgZMP//kJ+AgACPuyA= Date: Thu, 23 May 2013 02:45:16 +0000 Message-ID: References: <518A82D9.7080508@labn.net> <518BAB17.9090807@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> <519657FE.5030602@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D5009B0@BL2PRD0510MB349.namprd05.prod.outlook.com> <519693DF.6000003@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D504EAD@BL2PRD0510MB349.namprd05.prod.outlook.com>, <519A6EC1.4080205@labn.net> <9574E62A-6A68-4290-A103-8A0A750E2004@juniper.net>, <519A8A7D.5020002@labn.net> <519B6A75.5040803@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D508BCA@BL2PRD0510MB349.namprd05.prod.outlook.com> <13ec9ac042d.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D50937C@BL2PRD0510MB349.namprd05.prod.outlook.com>, <519D0049.80709@labn.net> <2F3E6A05-D111-4CB2-B2AD-59AE980A2043@juniper.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D50A4D9@BL2PRD0510MB349.namprd05.prod.outlook.com> In-Reply-To: <0182DEA5604B3A44A2EE61F3EE3ED69E1D50A4D9@BL2PRD0510MB349.namprd05.prod.outlook.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: CCAMP Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 open issues) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 02:45:31 -0000 Lou and John, Thanks.=20 Happy to see that you both provided the same proposed text.=20 Best Regards Fatai -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net]=20 Sent: Thursday, May 23, 2013 10:10 AM To: Fatai Zhang; Lou Berger Cc: CCAMP Subject: RE: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 ope= n issues) Fatai, Length (12 bits): indicates the number of bits of the Bit Map field, i.e., = the number of TS in the HO ODUk link. The TS granularity, 1.25Gbps or 2.5G= bps, may be derived by dividing the HO ODUk link's rate by the value of the= Length field. In the context of [G709-2012], the values of 4 and 16 indic= ate a TS granularity of 2.5Gps, and the values 2, 8, 32 and 80 indicate a T= S granularity of 1.25Gps. Yours Irrespectively, John > -----Original Message----- > From: Fatai Zhang [mailto:zhangfatai@huawei.com] > Sent: Wednesday, May 22, 2013 5:55 PM > To: John E Drake; Lou Berger > Cc: CCAMP > Subject: RE: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 > open issues) >=20 > Hi Lou and John, >=20 > Thanks for your discussion on providing the proposed text. >=20 > However, I am lost by the discussion. >=20 > What is the final proposed text? I hope someone can finalize it. >=20 > I think it is time to conclude the discussion on this point (the > original point 1). >=20 >=20 >=20 > Best Regards >=20 > Fatai >=20 >=20 > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Thursday, May 23, 2013 2:01 AM > To: Lou Berger > Cc: Fatai Zhang; CCAMP > Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 > open issues) >=20 > Bummer >=20 > Sent from my iPhone >=20 > On May 22, 2013, at 10:45 AM, "Lou Berger" wrote: >=20 > > I'm empathetic with the addition, but suspect it's best not to put > the > > first 10 words in the draft... > > > > Lou > > > > On 5/21/2013 8:45 PM, John E Drake wrote: > >> It should be blindingly obvious to the informed reader that in the > context of [G709-2012], the values of 4 and 16 indicate a TS > granularity of 2.5Gps, and the values 2, 8, 32 and 80 indicate a TS > granularity of 1.25Gps. > >> > >> Yours Irrespectively, > >> > >> John > >> > >>> -----Original Message----- > >>> From: Lou Berger [mailto:lberger@labn.net] > >>> Sent: Tuesday, May 21, 2013 5:38 PM > >>> To: John E Drake > >>> Cc: Fatai Zhang; > >>> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; > >>> CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org > >>> Subject: RE: [CCAMP] Confirming plan for Issue #48: (Was: Closing > >>> G.709 open issues) > >>> > >>> John, > >>> > >>> Great. It seems we agree that it shouldn't have been necessary to > >>> discuss this point so many times, and that the additional text > >>> doesn't change the field definition. It is informative narrative > after all. > >>> > >>> Now that said, can you live with the revised "overly precise" text > >>> so that we can move forward (and ensure we're not back here again)? > >>> > >>> Lou > >>> > >>> On May 21, 2013 4:23:37 PM John E Drake wrote: > >>>> Lou, > >>>> > >>>> The question that has always been is whether signaling needed to > >>>> include an explicit TSG filed and the answer has always been no > >>>> because it can be derived from other fields. The text I proposed > >>>> makes that derivation explicit and unambiguous. The additional > >>>> text you are proposing adds neither clarity nor information. > >>>> > >>>> Yours Irrespectively, > >>>> > >>>> John > >>>> > >>>>> -----Original Message----- > >>>>> From: Lou Berger [mailto:lberger@labn.net] > >>>>> Sent: Tuesday, May 21, 2013 5:37 AM > >>>>> To: John E Drake > >>>>> Cc: Fatai Zhang; > >>>>> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; > >>>>> CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org > >>>>> Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing > >>>>> G.709 open issues) John, Really? You're joking right? > >>>>> As I said to Fatai: > >>>>> My feeling is that there have been too many "surprises" on the > >>> 709 > >>>>> documents in areas that I thought were ... resolved by past > >>>>> discussions. At this point, as co-chair and Document shepherd, > >>> I > >>>>> want to ensure that any open point on the documents are > >>>>> unambiguously closed and that past discussions (i.e., points of > >>>>> consensus) are 100% captured, so that we can smoothly move > >>> through > >>>>> the planned second LC and publication request. > >>>>> The particular point of the ambiguity/implicit nature of > >>> determining > >>>>> TSG from length has been brought up at least three times. (Note, > >>> by > >>>>> others in the WG -- this is not my concern.) Each time the > >>> consensus > >>>>> from the discussion is to leave as is, but no or only minimal > >>>>> changes were made to the document. I opened the trac ticket to > >>>>> ensure that the consensus was documented in the draft and that we > >>>>> don't have to yet again revisit this topic -- which *is* my > >>> concern. > >>>>> So, the revised text addresses your concern of not needing to > >>>>> redefine the field for new 709 rate or TSGs, and it is > >>>>> sufficiently precise so that non should misinterpret the current > "implicit" > >>>>> specification of TSG. > >>>>> Can we/you accept the revised "overly precise" text and move > >>> forward? > >>>>> Lou > >>>>> On 5/20/2013 10:30 PM, John E Drake wrote: > >>>>>> What is behind your preoccupation with enumerating all possible > >>>>> combinations of length & TSG? Do you have trouble with > arithmetic? > >>>>>> > >>>>>> Sent from my iPhone > >>>>>> > >>>>>> On May 20, 2013, at 1:42 PM, "Lou Berger" > >>> wrote: > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On 5/20/2013 3:18 PM, John E Drake wrote: > >>>>>>>> I think that's a big mistake(tm). If a new rate or TSG is > >>>>>>>> introduced the RFC would need to be updated even though the > >>>>> encoding > >>>>>>>> does not require it. > >>>>>>> > >>>>>>> Well that's easily addressed, via something like: > >>>>>>> > >>>>>>> Length (12 bits): indicates the number of bits of the Bit Map > >>>>>>> field, i.e., the number of TS in the HO ODUk link. The TS > >>>>>>> granularity, 1.25Gbps or 2.5Gbps, may be derived by dividing > the > >>>>>>> HO ODUk link's rate by the value of the Length field. In the > >>>>>>> context of [G709-2012], the values of 4 and 16 indicate a TS > >>>>>>> granularity of 2.5Gps, and the values 2, 8, 32 and 80 indicate > a > >>>>>>> TS granularity of > >>>>> 1.25Gps. > >>>>>>> > >>>>>>> Lou > >>>>>>> > >>>>>>>> Sent from my iPhone > >>>>>>>> > >>>>>>>> On May 20, 2013, at 2:43 PM, "Lou Berger" > >>> wrote: > >>>>>>>> > >>>>>>>>> John, > >>>>>>>>> There's still some ambiguity here. How about: > >>>>>>>>> On 5/20/2013 9:15 AM, John E Drake wrote: > >>>>>>>>>> Length (12 bits): indicates the number of bits of the Bit > Map > >>>>>>>>>> field, i.e., the number of TS in the HO ODUk link. The TS > >>>>>>>>>> granularity, 1.25Gbps or 2.5Gbps, may be derived by dividing > >>>>>>>>>> the HO ODUk link's rate by the value of the Length field. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Replace: > >>>>>>>>>> For example, for an HO ODU2 > >>>>>>>>>> link, whose link rate is 10Gbps, the value of the Length > >>> field > >>>>>>>>>> will be either 4 or 8 and the TS granularity will be either > >>>>>>>>>> 2.5Gbps or 1.25Gbps, respectively. > >>>>>>>>> With: > >>>>>>>>> > >>>>>>>>> The values of 4 and 16 indicate a TS granularity of 2.5Gps, > >>>>>>>>> while the values 2, 8, 32 and 80 indicate a TS granularity of > >>> 1.25Gps. > >>>>>>>>> > >>>>>>>>> Lou > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> Irrespectively Yours, > >>>>>>>>>> > >>>>>>>>>> John > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> -----Original Message----- > >>>>>>>>>>> From: Lou Berger [mailto:lberger@labn.net] > >>>>>>>>>>> Sent: Friday, May 17, 2013 1:33 PM > >>>>>>>>>>> To: John E Drake > >>>>>>>>>>> Cc: Fatai Zhang; > >>>>>>>>>>> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; > >>>>>>>>>>> CCAMP; draft-ietf-ccamp-gmpls-signaling- > >>> g709v3@tools.ietf.org > >>>>>>>>>>> Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: > >>>>> Closing > >>>>>>>>>>> G.709 open issues) > >>>>>>>>>>> > >>>>>>>>>>> John, > >>>>>>>>>>> I guess you haven't been paying attention! The rewrite > >>>>>>>>>>> originated from Daniele, was tweaked by me and then fixed > by > >>>>> Fatai. > >>>>>>>>>>> > >>>>>>>>>>> Do you have an alternate proposal to address issue#48? > >>>>>>>>>>> Issue #48=3D"In signaling document section 6: Clarify related > >>>>>>>>>>> text [i.e., the OLD text] to unambiguously identify the > >>>>>>>>>>> relationship between label length and TSG." > >>>>>>>>>>> > >>>>>>>>>>> Thanks, > >>>>>>>>>>> Lou > >>>>>>>>>>> > >>>>>>>>>>> On 5/17/2013 1:15 PM, John E Drake wrote: > >>>>>>>>>>>> Lou, > >>>>>>>>>>>> > >>>>>>>>>>>> I think the original text is fine and your attempted > >>>>>>>>>>>> re-write > >>>>>>>>>>> completely mangled its meaning. The label is a bit vector > >>>>>>>>>>> whose length is equal to the ODUk rate / TSG. > >>>>>>>>>>>> > >>>>>>>>>>>> Irrespectively Yours, > >>>>>>>>>>>> > >>>>>>>>>>>> John > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>> From: ccamp-bounces@ietf.org > >>>>>>>>>>>>> [mailto:ccamp-bounces@ietf.org] > >>>>> On > >>>>>>>>>>>>> Behalf Of Lou Berger > >>>>>>>>>>>>> Sent: Friday, May 17, 2013 9:17 AM > >>>>>>>>>>>>> To: Fatai Zhang > >>>>>>>>>>>>> Cc: draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; > >>>>> CCAMP; > >>>>>>>>>>>>> draft- ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org > >>>>>>>>>>>>> Subject: [CCAMP] Confirming plan for Issue #48: (Was: > >>>>>>>>>>>>> Closing > >>>>>>>>>>>>> G.709 open issues) > >>>>>>>>>>>>> > >>>>>>>>>>>>> Authors/WG, > >>>>>>>>>>>>> From the mail on the list it seems to me that we've > >>>>>>>>>>>>> reached > >>>>>>>>>>> closure > >>>>>>>>>>>>> on Issue #48: "Document no explicit indication of TSG in > >>>>>>>>>>>>> the > >>>>> label" > >>>>>>>>>>>>> (http://trac.tools.ietf.org/wg/ccamp/trac/ticket/48). > I'd > >>>>> like > >>>>>>>>>>>>> to confirm my reading. > >>>>>>>>>>>>> > >>>>>>>>>>>>> As I read the list, this issue will be resolved by making > >>>>>>>>>>>>> the following change to draft-ietf-ccamp-gmpls-signaling- > >>> g709v3. > >>>>>>>>>>>>> > >>>>>>>>>>>>> OLD > >>>>>>>>>>>>> Note that the > >>>>>>>>>>>>> Length field in the label format MAY be used to indicate > >>>>>>>>>>>>> the > >>>>> TS > >>>>>>>>>>>>> type of the HO ODUk (i.e., TS granularity at 1.25Gbps or > >>>>>>>>>>>>> 2.5Gbps) since the HO ODUk type can be known from IF_ID > >>>>>>>>>>>>> RSVP_HOP Object. In some cases when there is no Link > >>>>> Management > >>>>>>>>>>>>> Protocol (LMP) or routing to make the two end points of > >>> the > >>>>>>>>>>>>> link to know the TSG, the TSG information used by another > >>>>>>>>>>>>> end can be deduced from the label format. For example, > for > >>>>>>>>>>>>> HO ODU2 link, the value of the length filed will be 4 or > >>> 8, > >>>>>>>>>>>>> which indicates the TS granularity is 2.5Gbps or > 1.25Gbps, > >>>>> respectively. > >>>>>>>>>>>>> > >>>>>>>>>>>>> NEW > >>>>>>>>>>>>> Please note that the TS granularity of an HO ODUk can be > >>>>>>>>>>>>> inferred from the length of the label. The values of 4 > and > >>>>>>>>>>>>> 16 indicate a TS granularity of 2.5Gps, while the values > >>> 2, > >>>>>>>>>>>>> 8, 32 and 80 indicate a > >>>>>>>>>>> TS > >>>>>>>>>>>>> granularity of 1.25Gps. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Please speak up if you disagree with this resolution. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>> Lou > >>>>>>>>>>>>> > >>>>>>>>>>>>> On 5/9/2013 9:41 PM, Fatai Zhang wrote: > >>>>>>>>>>>>>> For point 1), "1" should be dropped and "7" should be > >>>>>>>>>>>>>> corrected to > >>>>>>>>>>>>> "8" in your proposed text. > >>>>>>>>>>>>> > >>>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>>> CCAMP mailing list > >>>>>>>>>>>>> CCAMP@ietf.org > >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp > > >=20 From internet-drafts@ietf.org Thu May 23 04:48:10 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0F5B21F9294; Thu, 23 May 2013 04:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUcOsMBryvud; Thu, 23 May 2013 04:48:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA1721F8A0B; Thu, 23 May 2013 04:48:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130523114810.24178.91323.idtracker@ietfa.amsl.com> Date: Thu, 23 May 2013 04:48:10 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-rsvp-te-li-lb-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 11:48:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : GMPLS RSVP-TE Extensions for Lock Instruct and Loopback Author(s) : Jie Dong Mach(Guoyi) Chen Zhenqiang Li Daniele Ceccarelli Filename : draft-ietf-ccamp-rsvp-te-li-lb-01.txt Pages : 8 Date : 2013-05-23 Abstract: This document specifies extensions to RSVP-TE to support lock instruct and loopback mechanism for LSPs. The mechanisms are applicable to technologies which use GMPLS as control plane. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-li-lb There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-li-lb-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-rsvp-te-li-lb-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From lberger@labn.net Thu May 23 09:15:09 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4525911E813D for ; Thu, 23 May 2013 09:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.127 X-Spam-Level: X-Spam-Status: No, score=-102.127 tagged_above=-999 required=5 tests=[AWL=-0.462, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_52=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPWs7rgoHcpr for ; Thu, 23 May 2013 09:15:00 -0700 (PDT) Received: from oproxy13-pub.unifiedlayer.com (oproxy13-pub.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id 6B15511E812F for ; Thu, 23 May 2013 09:15:00 -0700 (PDT) Received: (qmail 29131 invoked by uid 0); 23 May 2013 16:14:38 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy13.unifiedlayer.com with SMTP; 23 May 2013 16:14:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=5oRL/9282Dc1jo0HzUrQrsux4Obr3zaC3u+BX00BI18=; b=YWJKGofejYeQ+xYKQkOYqdFVxDjADzLRztkI4nlkw0xD6hNVN6WxOFRjHrLv3Fawp5ZROJHdFguCOQNtCXqRdr4yUC/nGSaGiJzGTkDncT3yWOt3C2tutqNZuSLv7gUl; Received: from box313.bluehost.com ([69.89.31.113]:42917 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UfYA1-0005iR-K0; Thu, 23 May 2013 10:14:38 -0600 Message-ID: <519E406C.9030008@labn.net> Date: Thu, 23 May 2013 12:14:36 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Fatai Zhang References: <518A82D9.7080508@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> <518CED28.30303@labn.net> <51924382.2010904@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C90D5@ESESSMB301.ericsson.se> <13ea7ed3bdd.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <5193A26A.1090005@labn.net> <519649B4.5060408@labn.net> <519B73C9.2030308@labn.net> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" Subject: Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 16:15:10 -0000 Fatai, Do we really need to reopen debate on a topic the WG discussed and closed last summer? (i.e., to handle G.709 client adaptation just as we do for every other technology.) I do agree that some new G-PID assignments were missed in the draft that went to LC, but filling in the list doesn't automatically mean that the WG needs to reopen debate on adaptation approaches. Assuming we don't need to reopen the pre-LC debate from last summer, and with respect to the list I sent out, I do agree the WG needs to: A) Ensure that the list doesn't have unneeded new G-PIDs (i.e., reuses the same/existing G-PIDs wherever possible.) B) Identifies the "right" G-PID per payload type, and doesn't have any other technical errors C) Doesn't conflict with past WG decisions/discussions. >From your mails I see the following comment on (A): > For 0x05, why you think that RFC4328 does not cover it (ie., G-PID=54)? G-PID 54, per IANA, is currently defined as "Ethernet MAC (framed GFP)". Per G.709, PT=0x05 maps to "GFP mapping, see clause 17.4" and looking at 17.4 there is no restriction on what is carried in GFP frames. So it seems that PT=0x05 can't be limited to just "Ethernet MAC (framed GFP)". Are you suggesting changing the type description of G-PID 54 to just "Framed GFP", or including G-PID 54 as an additional possibility for PT=0x05? The latter seems to be a valid addition/correction. The former may be problematic for existing implementations, so we'll need to discuss more broadly if that's the direction you want to head. All/ (WG), Again, please speak up if you think the above is not aligned with prior consensus or if you have an issue with any of the above. Lou On 5/22/2013 10:35 PM, Fatai Zhang wrote: > Hi Lou, > > > > I incorporated your proposal into my table to facilitate the readers. > > > > I think you still insist on reusing some existing G-PIDs like 58, 56. > For 0x04, why you think that RFC4328 does not cover it (ie., G-PID=54)? > > > > Technically, I am not convince by your proposal, but I would like to > reserve my opinion for your same motivation (ie., to conclude the > discussion as soon as possible). > > > > Any opinions on Lou’s proposal from the WG? I will update the signaling > draft based on Lou’s proposal if there is no comment on Lou’s proposal. > > > > Note that all the new G-PID values will be re-ordered with TBA. > > > > *G-PIDs vs **Payload types defined in Table 15-8 of G.709* > > > > Payload Type in Hex codedefined in G.709 > > > > G-PID > > > > LSP Encoding > > > > Note > > > > Interpretationfrom G.709 > > 0x01 > > > > None > > > > > > > > Not needed > > > > Experimental mapping (Note 3) > > 0x02 > > > > 49 > > > > G.709 ODUk, G.709 OCh > > > > 1)G-PID defined in RFC4328; > > 2) Updated in this draft. > > > > Asynchronous CBR mapping, see clause 17.2 > > 0x03 > > > > 50 > > > > G.709 ODUk > > > > ditto > > > > Bit synchronous CBR mapping, see clause 17.2 > > 0x04 > > > > 32 > > > > SDH, G.709 ODUk > > > > ditto > > > > ATM mapping, see clause 17.3 > > 0x05 > > > > 54 > > or > > TBA (Suggested by Lou) > > > > G.709 ODUk (and SDH) > > > > > > G-PIDs defined in RFC4328 for framed GFP > > > > > > GFP mapping, see clause 17.4 > > 0x06 > > > > None > > > > > > > > Not needed and Not defined in RFC4328 > > > > Virtual Concatenated signal, see clause 18 (Note 5) > > 0x07 > > > > 61(TBA) > > Or55(Suggested by Lou) > > > > G.709 ODUk (k=0,3,4) > > > > Is being defined in this draft (new payload type defined in [G.709-2012]) > > > > PCS codeword transparent Ethernet mapping: > > · 1000BASE-X into OPU0, see clauses 17.7.1 and 17.7.1.1 > > · 40GBASE-R into OPU3, see clauses 17.7.4 and 17.7.4.1 > > · 100GBASE-R into OPU4, see clauses 17.7.5 and 17.7.5.1 > > 0x08 > > > > 62(TBA) > > Or58(Suggested by Lou) > > > > G.709 ODUk (k=2e) > > > > ditto > > > > FC-1200 into OPU2e mapping, see clause 17.8.2 > > 0x09 > > > > 63(TBA) > > > > G.709 ODUk (k=2) > > > > ditto > > > > GFP mapping into Extended OPU2 payload, see clause 17.4.1 (Note 6) > > 0x0A > > > > 64(TBA) > > > > G.709 ODUk (k=0) > > > > ditto > > > > STM-1 mapping into OPU0, see clause 17.7.1 > > 0x0B > > > > 65(TBA) > > > > G.709 ODUk (k=0) > > > > ditto > > > > STM-4 mapping into OPU0, see clause 17.7.1 > > 0x0C > > > > 66(TBA) > > Or58(Suggested by Lou) > > > > G.709 ODUk (k=0) > > > > ditto > > > > FC-100 mapping into OPU0, see clause 17.7.1 > > 0x0D > > > > 67(TBA) > > Or58(Suggested by Lou) > > > > G.709 ODUk (k=1) > > > > ditto > > > > FC-200 mapping into OPU1, see clause 17.7.2 > > 0x0E > > > > 68(TBA) > > Or58(Suggested by Lou) > > > > G.709 ODUflex > > > > ditto > > > > FC-400 mapping into OPUflex, see clause 17.9 > > 0x0F > > > > 69(TBA) > > Or58(Suggested by Lou) > > > > G.709 ODUflex > > > > ditto > > > > FC-800 mapping into OPUflex, see clause 17.9 > > 0x10 > > > > 51 > > > > G.709 ODUk > > > > 1)G-PID defined in RFC4328; > > 2) Updated in this draft. > > > > Bit stream with octet timing mapping, see clause 17.6.1 > > 0x11 > > > > 52 > > > > G.709 ODUk > > > > ditto > > > > Bit stream without octet timing mapping, see clause 17.6.2 > > 0x12 > > > > 70(TBA) > > > > G.709 ODUflex > > > > Is being defined in this draft (new payload type defined in [G.709-2012]) > > > > IB SDR mapping into OPUflex, see 17.9 > > 0x13 > > > > 71(TBA) > > > > G.709 ODUflex > > > > ditto > > > > IB DDR mapping into OPUflex, see 17.9 > > 0x14 > > > > 72(TBA) > > > > G.709 ODUflex > > > > ditto > > > > IB QDR mapping into OPUflex, see 17.9 > > 0x15 > > > > 73(TBA) > > > > G.709 ODUk (k=0) > > > > ditto > > > > SDI mapping into OPU0, see 17.7.1 > > 0x16 > > > > 74(TBA) > > > > G.709 ODUk (k=1) > > > > ditto > > > > (1.485/1.001) Gbit/s SDI mapping into OPU1, see 17.7.2 > > 0x17 > > > > 75(TBA) > > > > G.709 ODUk (k=1) > > > > ditto > > > > 1.485 Gbit/s SDI mapping into OPU1, see 17.7.2 > > 0x18 > > > > 76(TBA) > > > > G.709 ODUflex > > > > ditto > > > > (2.970/1.001) Gbit/s SDI mapping into OPUflex, see 17.9 > > 0x19 > > > > 77(TBA) > > > > G.709 ODUflex > > > > ditto > > > > 2.970 Gbit/s SDI mapping into OPUflex, see 17.9 > > 0x1A > > > > 78(TBA) > > Or56(Suggested by Lou) > > > > G.709 ODUk (k=0) > > > > ditto > > > > SBCON/ESCON mapping into OPU0, see 17.7.1 > > 0x1B > > > > 79(TBA) > > > > G.709 ODUk (k=0) > > > > ditto > > > > DVB_ASI mapping into OPU0, see 17.7.1 > > 0x20 > > > > 47 > > > > G.709 ODUk > > > > 1) G-PIDs defined in RFC4328. > > 2) Updated in this draft. > > > > ODU multiplex structure supporting ODTUjk only, see clause 19 (AMP only) > > 0x21 > > > > 59/60(TBA) > > > > G.709 ODUk > > > > 1)Are being defined in this draft (new payload type defined in > [G.709-2012]); > > 2) 59 for G.709 ODU-1.25G; 60 for G.709 ODU-any > > > > ODU multiplex structure supporting ODTUk.ts or ODTUk.ts and ODTUjk, see > clause 19 (GMP capable) (Note 7) > > 55 > > > > None > > > > > > > > Not needed > > > > Not available (Note 2) > > 66 > > > > None > > > > > > > > Not needed > > > > Not available (Note 2) > > 80-8F > > > > None > > > > > > > > Not needed > > > > Reserved codes for proprietary use (Note 4) > > FD > > > > None > > OrTBA(Suggested by Lou) > > > > > > > > Not needed > > > > NULL test signal mapping, see clause 17.5.1 > > FE > > > > None > > OrTBA(Suggested by Lou) > > > > > > > > Not needed > > > > PRBS test signal mapping, see clause 17.5.2 > > FF > > > > None > > > > > > > > Not needed > > > > Not available (Note 2) > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > Fatai > > > > > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Lou Berger > Sent: Tuesday, May 21, 2013 9:17 PM > To: CCAMP > Cc: draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org > Subject: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues) > > > > All, > > > > In the interest of moving this discussion quickly to closure, I spent > > some time trying to come up with the full list of G.709 PT to G-PID > > mappings. In coming up with this list I tried to be consistent with > > the last consensus point that I can identify on this topic (the > > previously referenced July 2012 thread & presentation), which included: > > > > A) Defining new G-PIDs for client types not identified by an assigned > > G-PID (per > > http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parameters.xml) > > > > B) Reusing G-PID wherever {G-PID, ODU rate} unambiguously identify a > > G.709 payload type, and define new G-PIDs when reuse not possible. > > > > C) No G-PID value for unused, reserved, or proprietary 709 Payload Type. > > > > Here's what I've come up with: > > > > G.709 > > Payload > > Type G-PID Type/Comment LSP Encoding > > ==== ===== ============== =================== > > 0x01 No standard value > > 0x02 49 CBRa G.709 ODUk > > 0x03 50 CBRb G.709 ODUk > > 0x04 32 ATM G.709 ODUk > > 0x05 TBA1 Framed GFP G.709 ODUk > > 0x06 ??? Is any valued needed? > > 0x07 55 Ethernet PHY G.709 ODUk (k=0) > > (transparent G.709 ODUk (k=3) > > GFP) G.709 ODUk (k=4) > > 0x08 58 Fiber Channel G.709 ODUk (k=2e) > > 0x09 TBA1 Framed GFP G.709 ODUk (k=2e) > > 0x0A TBA2 STM-1 G.709 ODUk (k=0) > > 0x0B TBA3 STM-4 G.709 ODUk (k=0) > > 0x0C 58 Fiber Channel G.709 ODUk (k=0) > > 0x0D 58 Fiber Channel G.709 ODUk (k=1) > > 0x0E 58 Fiber Channel G.709 ODUflex > > 0x0F 58 Fiber Channel G.709 ODUflex > > 0x10 51 BSOT G.709 ODUk > > 0x11 52 BSNT G.709 ODUk > > 0x12 TBA4 InfiniBand G.709 ODUflex > > 0x13 TBA4 InfiniBand G.709 ODUflex > > 0x14 TBA4 InfiniBand G.709 ODUflex > > 0x15 TBA5 Serial Digital G.709 ODUk (k=0) > > Interface > > 0x16 TBA6 Serial Digital G.709 ODUk (k=1) > > Interface/1.001 > > 0x17 TBA5 Serial Digital G.709 ODUk (k=1) > > Interface > > 0x18 TBA6 Serial Digital G.709 ODUflex > > Interface/1.001 > > 0x19 TBA5 Serial Digital G.709 ODUflex > > Interface > > 0x1A 56 SBCON/ESCON G.709 ODUk (k=0) > > (IANA to update Type field) > > 0x1B TBA7 DVB_ASI G.709 ODUk (k=0) > > 0x1C 58 Fiber Channel G.709 ODUk > > 0x20 47 G.709 ODU-2.5G G.709 ODUk > > (k=2,3) > > (IANA to update Type field) > > TBA8 G.709 ODU-1.25G G.709 ODUk > > (k=1,2,3) > > 0x21 TBA8 G.709 ODU-1.25G G.709 ODUk > > (k=2,3,4) > > TBA9 G.709 ODU-Any G.709 ODUk > > (k=2,3) > > 0x55 No standard value > > 0x66 No standard value > > 0x80-0x8F No standard value > > 0xFD TBA10 Null Test G.709 ODUk > > 0xFE TBA11 Random Test G.709 ODUk > > 0xFF No standard value > > > > Note that there are a few differences with Fatai's list, which doesn't > > format well in e-mail, but is available in the archive > > http://www.ietf.org/mail-archive/web/ccamp/current/msg14845.html > > > > Please speak up if you think the above is not aligned with prior > > consensus or if you have an issue with any of the above. > > > > Much thanks, > > Lou > > > > > > On 5/20/2013 5:09 AM, Fatai Zhang wrote: > >> Hi Lou, > >> > >> > >> > >> I think my mail on March 13rd may have answered your following comments. > >> My response quoted as follows. > >> > >> > >> > >> In addition, if people look at the full list that I provided, I think > >> people can realize that RFC4328 (section 3.1.3) used the same approach > >> as the current approach of this draft (ie., 1:1 mapping between GPIDs > >> and payload types defined by G.709), ie., we are following what RFC4328 > >> did. > >> > >> > >> > >> BTW, I am not sure if we need spend so much on discussing this point > >> (because there is no issue to stick to the data plane by using the > >> current approach of this draft). > >> > >> > >> > >> ====================================================================================================================== > >> > >> (2) 'Grouped GPID' vs '1:1' mapping (between G.709-2012 and GPIDs > >> defined in this draft) > >> > >> > >> > >> We realize that it is safe to use 1:1 mapping approach to avoid some > >> potential issues after investigation. We know this payload types have > >> been defined by G.709 (data plane), so physically it is better to use > >> 1:1 mapping approach. > >> > >> For the potential issues I mentioned above, for example, we cannot use > >> the existing 34 to represent 'STM-1' and 'STM-4 ', because it is > >> impossible to differentiate which one is 'STM-1' or 'STM-4'. In > >> addition, from the concept of payload type, we know that e.g, FC-100 is > >> different from FC-800, right? So, it is better to assign different GPIDs > >> to these different payload types defined by the data plane. > >> > >> > >> > >> Furthermore, I think it is much cheaper to create new GPIDs in the > >> control plane than in the data plane (these payload types will be > >> carried in the OH). > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Best Regards > >> > >> > >> > >> Fatai > >> > >> > >> > >> -----Original Message----- > >> From: Lou Berger [mailto:lberger@labn.net] > >> Sent: Friday, May 17, 2013 11:16 PM > >> To: Fatai Zhang > >> Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; > >> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org > >> Subject: Re: R: Closing G.709 open issues > >> > >> > >> > >> Fatai, > >> > >> > >> > >> That's a great start for the WG. Thank you. > >> > >> > >> > >> To answer your implied question as to why my request for the full list. > >> > >> My feeling is that there have been too many "surprises" on the 709 > >> > >> documents in areas that I thought were either obvious (but from the IETF > >> > >> & GMPLS context, not ITU-T or G.709 perspectives) or resolved by past > >> > >> discussions. At this point, as co-chair and Document shepherd, I want > >> > >> to ensure that any open point on the documents are unambiguously closed > >> > >> and that past discussions (i.e., points of consensus) are 100% captured, > >> > >> so that we can smoothly move through the planned second LC and > >> > >> publication request. > >> > >> > >> > >> To that end, in my previous message I asked two questions about points > >> > >> where it seems you are proposing moving away from what has been > >> > >> previously been discussed & agreed to by the WG. Can you answer the > >> > >> following: > >> > >> > >> > >>>> My questions on the new G-PIDs come down to: > >> > >>>> - Why are rate specific G-PIDs being proposed (rather than > >> > >>>> continuing to use the previous approach documented in the draft > >> > >>>> and in Section 3.1.3 of rfc4328)? > >> > >> > >> > >>>> - Why are new values being defined rather than using existing > >> > >>>> values, e.g., G-PID 56? > >> > >>>> > >> > >> > >> > >> Much thanks, > >> > >> Lou > >> > >> > >> > >> > >> > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > From kpithewan@infinera.com Thu May 23 12:54:29 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5E9821F9180 for ; Thu, 23 May 2013 12:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d89MD7Ohx-JL for ; Thu, 23 May 2013 12:54:00 -0700 (PDT) Received: from sv-casht-prod2.infinera.com (sv-casht-prod2.infinera.com [8.4.225.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8198021F97EF for ; Thu, 23 May 2013 12:15:53 -0700 (PDT) Received: from SV-EXDB-PROD2.infinera.com ([fe80::1d05:1822:aaea:ff52]) by sv-casht-prod2.infinera.com ([::1]) with mapi id 14.03.0123.003; Thu, 23 May 2013 12:15:52 -0700 From: Khuzema Pithewan To: Lou Berger , CCAMP Thread-Topic: Closing Issue #49 (Was: Re: R: Closing G.709 open issues) Thread-Index: AQHOViWNlSQKnFOnHEGp0kX3EXiVcJkTJgxw Date: Thu, 23 May 2013 19:15:51 +0000 Message-ID: References: <518A82D9.7080508@labn.net> <518BAB17.9090807@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> <518CED28.30303@labn.net> <51924382.2010904@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C90D5@ESESSMB301.ericsson.se> <13ea7ed3bdd.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <5193A26A.1090005@labn.net> <519649B4.5060408@labn.net> <519B73C9.2030308@labn.net> In-Reply-To: <519B73C9.2030308@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.156.108] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" Subject: Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 19:54:32 -0000 Hi Lou, -> C) No G-PID value for unused, reserved, or proprietary 709 Payload Type. Let say some vendor uses reserved (80-8F, which will never be standardized = by ITU, as per Note4 in Table 15-8) payload code point and uses some GPid '= x' in Control plane for that code point. Now if in future, Control plane de= fines x for some other client.=20 There will be backward compatibility issues. Since it is clearly mentioned that these 16 code points in dataplane, will = not standardized, is a standardization in way, which must be followed up in= control plane by reserving 16 GPids for the purpose. Regds Khuzema -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Tuesday, May 21, 2013 6:47 PM To: CCAMP Cc: draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org Subject: Closing Issue #49 (Was: Re: R: Closing G.709 open issues) All, In the interest of moving this discussion quickly to closure, I spent some time trying to come up with the full list of G.709 PT to G-PID mappings. In coming up with this list I tried to be consistent with the last consensus point that I can identify on this topic (the previously referenced July 2012 thread & presentation), which included: A) Defining new G-PIDs for client types not identified by an assigned G-PID (per http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parameters.x= ml) B) Reusing G-PID wherever {G-PID, ODU rate} unambiguously identify a G.709 payload type, and define new G-PIDs when reuse not possible. C) No G-PID value for unused, reserved, or proprietary 709 Payload Type. Here's what I've come up with: G.709 Payload Type G-PID Type/Comment LSP Encoding =3D=3D=3D=3D =3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 0x01 No standard value 0x02 49 CBRa G.709 ODUk 0x03 50 CBRb G.709 ODUk 0x04 32 ATM G.709 ODUk 0x05 TBA1 Framed GFP G.709 ODUk 0x06 ??? Is any valued needed? 0x07 55 Ethernet PHY G.709 ODUk (k=3D0) (transparent G.709 ODUk (k=3D3) GFP) G.709 ODUk (k=3D4) 0x08 58 Fiber Channel G.709 ODUk (k=3D2e) 0x09 TBA1 Framed GFP G.709 ODUk (k=3D2e) 0x0A TBA2 STM-1 G.709 ODUk (k=3D0) 0x0B TBA3 STM-4 G.709 ODUk (k=3D0) 0x0C 58 Fiber Channel G.709 ODUk (k=3D0) 0x0D 58 Fiber Channel G.709 ODUk (k=3D1) 0x0E 58 Fiber Channel G.709 ODUflex 0x0F 58 Fiber Channel G.709 ODUflex 0x10 51 BSOT G.709 ODUk 0x11 52 BSNT G.709 ODUk 0x12 TBA4 InfiniBand G.709 ODUflex 0x13 TBA4 InfiniBand G.709 ODUflex 0x14 TBA4 InfiniBand G.709 ODUflex 0x15 TBA5 Serial Digital G.709 ODUk (k=3D0) Interface 0x16 TBA6 Serial Digital G.709 ODUk (k=3D1) Interface/1.001 0x17 TBA5 Serial Digital G.709 ODUk (k=3D1) Interface 0x18 TBA6 Serial Digital G.709 ODUflex Interface/1.001 0x19 TBA5 Serial Digital G.709 ODUflex Interface 0x1A 56 SBCON/ESCON G.709 ODUk (k=3D0) (IANA to update Type field) 0x1B TBA7 DVB_ASI G.709 ODUk (k=3D0) 0x1C 58 Fiber Channel G.709 ODUk 0x20 47 G.709 ODU-2.5G G.709 ODUk (k=3D2,3) (IANA to update Type field) TBA8 G.709 ODU-1.25G G.709 ODUk (k=3D1,2,3) 0x21 TBA8 G.709 ODU-1.25G G.709 ODUk (k=3D2,3,4) TBA9 G.709 ODU-Any G.709 ODUk (k=3D2,3) 0x55 No standard value 0x66 No standard value 0x80-0x8F No standard value 0xFD TBA10 Null Test G.709 ODUk 0xFE TBA11 Random Test G.709 ODUk 0xFF No standard value Note that there are a few differences with Fatai's list, which doesn't format well in e-mail, but is available in the archive http://www.ietf.org/mail-archive/web/ccamp/current/msg14845.html Please speak up if you think the above is not aligned with prior consensus or if you have an issue with any of the above. Much thanks, Lou On 5/20/2013 5:09 AM, Fatai Zhang wrote: > Hi Lou, >=20 > =20 >=20 > I think my mail on March 13rd may have answered your following comments. > My response quoted as follows. >=20 > =20 >=20 > In addition, if people look at the full list that I provided, I think > people can realize that RFC4328 (section 3.1.3) used the same approach > as the current approach of this draft (ie., 1:1 mapping between GPIDs > and payload types defined by G.709), ie., we are following what RFC4328 > did. >=20 > =20 >=20 > BTW, I am not sure if we need spend so much on discussing this point > (because there is no issue to stick to the data plane by using the > current approach of this draft). >=20 > =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= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 > (2) 'Grouped GPID' vs '1:1' mapping (between G.709-2012 and GPIDs > defined in this draft) >=20 > =20 >=20 > We realize that it is safe to use 1:1 mapping approach to avoid some > potential issues after investigation. We know this payload types have > been defined by G.709 (data plane), so physically it is better to use > 1:1 mapping approach. >=20 > For the potential issues I mentioned above, for example, we cannot use > the existing 34 to represent 'STM-1' and 'STM-4 ', because it is > impossible to differentiate which one is 'STM-1' or 'STM-4'. In > addition, from the concept of payload type, we know that e.g, FC-100 is > different from FC-800, right? So, it is better to assign different GPIDs > to these different payload types defined by the data plane. >=20 > =20 >=20 > Furthermore, I think it is much cheaper to create new GPIDs in the > control plane than in the data plane (these payload types will be > carried in the OH). >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > Best Regards >=20 > =20 >=20 > Fatai >=20 > =20 >=20 > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Friday, May 17, 2013 11:16 PM > To: Fatai Zhang > Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; > draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org > Subject: Re: R: Closing G.709 open issues >=20 > =20 >=20 > Fatai, >=20 > =20 >=20 > That's a great start for the WG. Thank you. >=20 > =20 >=20 > To answer your implied question as to why my request for the full list. >=20 > My feeling is that there have been too many "surprises" on the 709 >=20 > documents in areas that I thought were either obvious (but from the IETF >=20 > & GMPLS context, not ITU-T or G.709 perspectives) or resolved by past >=20 > discussions. At this point, as co-chair and Document shepherd, I want >=20 > to ensure that any open point on the documents are unambiguously closed >=20 > and that past discussions (i.e., points of consensus) are 100% captured, >=20 > so that we can smoothly move through the planned second LC and >=20 > publication request. >=20 > =20 >=20 > To that end, in my previous message I asked two questions about points >=20 > where it seems you are proposing moving away from what has been >=20 > previously been discussed & agreed to by the WG. Can you answer the >=20 > following: >=20 > =20 >=20 >>> My questions on the new G-PIDs come down to: >=20 >>> - Why are rate specific G-PIDs being proposed (rather than >=20 >>> continuing to use the previous approach documented in the draft >=20 >>> and in Section 3.1.3 of rfc4328)? >=20 > =20 >=20 >>> - Why are new values being defined rather than using existing >=20 >>> values, e.g., G-PID 56? >=20 >>>=20 >=20 > =20 >=20 > Much thanks, >=20 > Lou >=20 > =20 >=20 > =20 >=20 From lberger@labn.net Thu May 23 14:55:01 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCCE21F8F7A for ; Thu, 23 May 2013 14:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.408 X-Spam-Level: X-Spam-Status: No, score=-102.408 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxEjA7k9q61a for ; Thu, 23 May 2013 14:54:47 -0700 (PDT) Received: from oproxy14-pub.unifiedlayer.com (oproxy14-pub.unifiedlayer.com [67.222.51.224]) by ietfa.amsl.com (Postfix) with SMTP id 8E40421F97B7 for ; Thu, 23 May 2013 14:07:12 -0700 (PDT) Received: (qmail 14999 invoked by uid 0); 23 May 2013 21:07:10 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy14.unifiedlayer.com with SMTP; 23 May 2013 21:07:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=1pLgsTDpIc0uBDI4exbPvxJlBW6r5YzHEn2MSt5D1kw=; b=xGbN9Idr/fGfdQD5xmyy7fOBAOC6MVmaLAgHjXsdiLGAOB1JSaXQDOhvFcEPvTNRwVLORpXGeUEgAo72VImVdIP1cthxmJ69cVgNw4qUDZcG9AoZWp62vyXO+SXi4hjt; Received: from box313.bluehost.com ([69.89.31.113]:60168 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Ufcj7-0006Oz-PI; Thu, 23 May 2013 15:07:10 -0600 Message-ID: <519E84F9.1040103@labn.net> Date: Thu, 23 May 2013 17:07:05 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Khuzema Pithewan References: <518A82D9.7080508@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> <518CED28.30303@labn.net> <51924382.2010904@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C90D5@ESESSMB301.ericsson.se> <13ea7ed3bdd.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <5193A26A.1090005@labn.net> <519649B4.5060408@labn.net> <519B73C9.2030308@labn.net> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" Subject: Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 21:55:01 -0000 On 5/23/2013 3:15 PM, Khuzema Pithewan wrote: > Hi Lou, > > > -> C) No G-PID value for unused, reserved, or proprietary 709 Payload Type. > > Let say some vendor uses reserved (80-8F, which will never be > standardized by ITU, as per Note4 in Table 15-8) payload code point > and uses some GPid 'x' in Control plane for that code point. Now if > in future, Control plane defines x for some other client. > > There will be backward compatibility issues. Khuzema, I agree. Vendors have always used (and continue to use) standard code points for proprietary purposes at their own peril. There is nothing new or unique about this in the context of the documents we're discussing. Another way to look at it is to ask/answer the following: What about this draft (supporting [G709-2012]) is different from [RFC4328] (supporting g709-2001) or any other technology supported by GMPLS that has experimental, reserved, and/or unavailable client types? > > Since it is clearly mentioned that these 16 code points in dataplane, > will not standardized, is a standardization in way, > which must be > followed up in control plane by reserving 16 GPids for the purpose. Why? [RFC4328] didn't standardize G-PIDs for the following G.709-2001 defined PTs: PT Interpretation 0x01 Experimental mapping \ 0x55 Not available 0x66 Not available 0x80-0x8F Reserved codes for proprietary use 0xFF Not available Are you just trying to be exhaustive in your definitions, or do you have an actual use case? If the latter, can you elaborate on your desired use? BTW you might want to look at the current IANA G-PID assignments before answering. I suspect you'll find that you can address your concerns using existing assignments. Thanks, Lou > Regds > Khuzema > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Tuesday, May 21, 2013 6:47 PM > To: CCAMP > Cc: draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org > Subject: Closing Issue #49 (Was: Re: R: Closing G.709 open issues) > > All, > > In the interest of moving this discussion quickly to closure, I spent > some time trying to come up with the full list of G.709 PT to G-PID > mappings. In coming up with this list I tried to be consistent with > the last consensus point that I can identify on this topic (the > previously referenced July 2012 thread & presentation), which included: > > A) Defining new G-PIDs for client types not identified by an assigned > G-PID (per > http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parameters.xml) > > B) Reusing G-PID wherever {G-PID, ODU rate} unambiguously identify a > G.709 payload type, and define new G-PIDs when reuse not possible. > > C) No G-PID value for unused, reserved, or proprietary 709 Payload Type. > > Here's what I've come up with: > > G.709 > Payload > Type G-PID Type/Comment LSP Encoding > ==== ===== ============== =================== > 0x01 No standard value > 0x02 49 CBRa G.709 ODUk > 0x03 50 CBRb G.709 ODUk > 0x04 32 ATM G.709 ODUk > 0x05 TBA1 Framed GFP G.709 ODUk > 0x06 ??? Is any valued needed? > 0x07 55 Ethernet PHY G.709 ODUk (k=0) > (transparent G.709 ODUk (k=3) > GFP) G.709 ODUk (k=4) > 0x08 58 Fiber Channel G.709 ODUk (k=2e) > 0x09 TBA1 Framed GFP G.709 ODUk (k=2e) > 0x0A TBA2 STM-1 G.709 ODUk (k=0) > 0x0B TBA3 STM-4 G.709 ODUk (k=0) > 0x0C 58 Fiber Channel G.709 ODUk (k=0) > 0x0D 58 Fiber Channel G.709 ODUk (k=1) > 0x0E 58 Fiber Channel G.709 ODUflex > 0x0F 58 Fiber Channel G.709 ODUflex > 0x10 51 BSOT G.709 ODUk > 0x11 52 BSNT G.709 ODUk > 0x12 TBA4 InfiniBand G.709 ODUflex > 0x13 TBA4 InfiniBand G.709 ODUflex > 0x14 TBA4 InfiniBand G.709 ODUflex > 0x15 TBA5 Serial Digital G.709 ODUk (k=0) > Interface > 0x16 TBA6 Serial Digital G.709 ODUk (k=1) > Interface/1.001 > 0x17 TBA5 Serial Digital G.709 ODUk (k=1) > Interface > 0x18 TBA6 Serial Digital G.709 ODUflex > Interface/1.001 > 0x19 TBA5 Serial Digital G.709 ODUflex > Interface > 0x1A 56 SBCON/ESCON G.709 ODUk (k=0) > (IANA to update Type field) > 0x1B TBA7 DVB_ASI G.709 ODUk (k=0) > 0x1C 58 Fiber Channel G.709 ODUk > 0x20 47 G.709 ODU-2.5G G.709 ODUk > (k=2,3) > (IANA to update Type field) > TBA8 G.709 ODU-1.25G G.709 ODUk > (k=1,2,3) > 0x21 TBA8 G.709 ODU-1.25G G.709 ODUk > (k=2,3,4) > TBA9 G.709 ODU-Any G.709 ODUk > (k=2,3) > 0x55 No standard value > 0x66 No standard value > 0x80-0x8F No standard value > 0xFD TBA10 Null Test G.709 ODUk > 0xFE TBA11 Random Test G.709 ODUk > 0xFF No standard value > > Note that there are a few differences with Fatai's list, which doesn't > format well in e-mail, but is available in the archive > http://www.ietf.org/mail-archive/web/ccamp/current/msg14845.html > > Please speak up if you think the above is not aligned with prior > consensus or if you have an issue with any of the above. > > Much thanks, > Lou > > > On 5/20/2013 5:09 AM, Fatai Zhang wrote: >> Hi Lou, >> >> >> >> I think my mail on March 13rd may have answered your following comments. >> My response quoted as follows. >> >> >> >> In addition, if people look at the full list that I provided, I think >> people can realize that RFC4328 (section 3.1.3) used the same approach >> as the current approach of this draft (ie., 1:1 mapping between GPIDs >> and payload types defined by G.709), ie., we are following what RFC4328 >> did. >> >> >> >> BTW, I am not sure if we need spend so much on discussing this point >> (because there is no issue to stick to the data plane by using the >> current approach of this draft). >> >> >> >> ====================================================================================================================== >> >> (2) 'Grouped GPID' vs '1:1' mapping (between G.709-2012 and GPIDs >> defined in this draft) >> >> >> >> We realize that it is safe to use 1:1 mapping approach to avoid some >> potential issues after investigation. We know this payload types have >> been defined by G.709 (data plane), so physically it is better to use >> 1:1 mapping approach. >> >> For the potential issues I mentioned above, for example, we cannot use >> the existing 34 to represent 'STM-1' and 'STM-4 ', because it is >> impossible to differentiate which one is 'STM-1' or 'STM-4'. In >> addition, from the concept of payload type, we know that e.g, FC-100 is >> different from FC-800, right? So, it is better to assign different GPIDs >> to these different payload types defined by the data plane. >> >> >> >> Furthermore, I think it is much cheaper to create new GPIDs in the >> control plane than in the data plane (these payload types will be >> carried in the OH). >> >> >> >> >> >> >> >> >> >> Best Regards >> >> >> >> Fatai >> >> >> >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Friday, May 17, 2013 11:16 PM >> To: Fatai Zhang >> Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; >> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >> Subject: Re: R: Closing G.709 open issues >> >> >> >> Fatai, >> >> >> >> That's a great start for the WG. Thank you. >> >> >> >> To answer your implied question as to why my request for the full list. >> >> My feeling is that there have been too many "surprises" on the 709 >> >> documents in areas that I thought were either obvious (but from the IETF >> >> & GMPLS context, not ITU-T or G.709 perspectives) or resolved by past >> >> discussions. At this point, as co-chair and Document shepherd, I want >> >> to ensure that any open point on the documents are unambiguously closed >> >> and that past discussions (i.e., points of consensus) are 100% captured, >> >> so that we can smoothly move through the planned second LC and >> >> publication request. >> >> >> >> To that end, in my previous message I asked two questions about points >> >> where it seems you are proposing moving away from what has been >> >> previously been discussed & agreed to by the WG. Can you answer the >> >> following: >> >> >> >>>> My questions on the new G-PIDs come down to: >> >>>> - Why are rate specific G-PIDs being proposed (rather than >> >>>> continuing to use the previous approach documented in the draft >> >>>> and in Section 3.1.3 of rfc4328)? >> >> >> >>>> - Why are new values being defined rather than using existing >> >>>> values, e.g., G-PID 56? >> >>>> >> >> >> >> Much thanks, >> >> Lou >> >> >> >> >> > > > > From zhangfatai@huawei.com Thu May 23 18:01:33 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4744621F90F4 for ; Thu, 23 May 2013 18:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.162 X-Spam-Level: X-Spam-Status: No, score=-6.162 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8FDh-yd3P-H for ; Thu, 23 May 2013 18:01:29 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0B47921F9428 for ; Thu, 23 May 2013 18:01:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARR31812; Fri, 24 May 2013 01:01:26 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 24 May 2013 02:01:11 +0100 Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 24 May 2013 02:01:12 +0100 Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.235]) by szxeml420-hub.china.huawei.com ([10.82.67.159]) with mapi id 14.01.0323.007; Fri, 24 May 2013 09:01:08 +0800 From: Fatai Zhang To: Lou Berger Thread-Topic: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues) Thread-Index: AQHOViWQY0rdNLd8TU6gdPkEdNxSL5kSC4BggABjVQCAARh/YA== Date: Fri, 24 May 2013 01:01:07 +0000 Message-ID: References: <518A82D9.7080508@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> <518CED28.30303@labn.net> <51924382.2010904@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C90D5@ESESSMB301.ericsson.se> <13ea7ed3bdd.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <5193A26A.1090005@labn.net> <519649B4.5060408@labn.net> <519B73C9.2030308@labn.net> <519E406C.9030008@labn.net> In-Reply-To: <519E406C.9030008@labn.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" Subject: Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 01:01:33 -0000 Hi Lou, Fine, thanks for your explanation. As I said, I will update the signaling draft based on your proposal if ther= e are no further comments. Best Regards Fatai -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Friday, May 24, 2013 12:15 AM To: Fatai Zhang Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org Subject: Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issu= es) Fatai, Do we really need to reopen debate on a topic the WG discussed and closed last summer? (i.e., to handle G.709 client adaptation just as we do for every other technology.) I do agree that some new G-PID assignments were missed in the draft that went to LC, but filling in the list doesn't automatically mean that the WG needs to reopen debate on adaptation approaches. Assuming we don't need to reopen the pre-LC debate from last summer, and with respect to the list I sent out, I do agree the WG needs to: A) Ensure that the list doesn't have unneeded new G-PIDs (i.e., reuses the same/existing G-PIDs wherever possible.) B) Identifies the "right" G-PID per payload type, and doesn't have any other technical errors C) Doesn't conflict with past WG decisions/discussions. >From your mails I see the following comment on (A): > For 0x05, why you think that RFC4328 does not cover it (ie., G-PID=3D54)? G-PID 54, per IANA, is currently defined as "Ethernet MAC (framed GFP)". Per G.709, PT=3D0x05 maps to "GFP mapping, see clause 17.4" and looking at 17.4 there is no restriction on what is carried in GFP frames. So it seems that PT=3D0x05 can't be limited to just "Ethernet MAC (framed GFP)". Are you suggesting changing the type description of G-PID 54 to just "Framed GFP", or including G-PID 54 as an additional possibility for PT=3D0x05? The latter seems to be a valid addition/correction. The former may be problematic for existing implementations, so we'll need to discuss more broadly if that's the direction you want to head. All/ (WG), Again, please speak up if you think the above is not aligned with prior consensus or if you have an issue with any of the above. Lou On 5/22/2013 10:35 PM, Fatai Zhang wrote: > Hi Lou, >=20 > =20 >=20 > I incorporated your proposal into my table to facilitate the readers. >=20 > =20 >=20 > I think you still insist on reusing some existing G-PIDs like 58, 56. > For 0x04, why you think that RFC4328 does not cover it (ie., G-PID=3D54)= ? >=20 > =20 >=20 > Technically, I am not convince by your proposal, but I would like to > reserve my opinion for your same motivation (ie., to conclude the > discussion as soon as possible). >=20 > =20 >=20 > Any opinions on Lou's proposal from the WG? I will update the signaling > draft based on Lou's proposal if there is no comment on Lou's proposal. >=20 > =20 >=20 > Note that all the new G-PID values will be re-ordered with TBA. >=20 > =20 >=20 > *G-PIDs vs **Payload types defined in Table 15-8 of G.709* >=20 > =20 >=20 > Payload Type in Hex codedefined in G.709 >=20 > =09 >=20 > G-PID >=20 > =09 >=20 > LSP Encoding >=20 > =09 >=20 > Note >=20 > =09 >=20 > Interpretationfrom G.709 >=20 > 0x01 >=20 > =09 >=20 > None >=20 > =09 >=20 > =20 >=20 > =09 >=20 > Not needed >=20 > =09 >=20 > Experimental mapping (Note 3) >=20 > 0x02 >=20 > =09 >=20 > 49 >=20 > =09 >=20 > G.709 ODUk, G.709 OCh >=20 > =09 >=20 > 1)G-PID defined in RFC4328; >=20 > 2) Updated in this draft. >=20 > =09 >=20 > Asynchronous CBR mapping, see clause 17.2 >=20 > 0x03 >=20 > =09 >=20 > 50 >=20 > =09 >=20 > G.709 ODUk >=20 > =09 >=20 > ditto >=20 > =09 >=20 > Bit synchronous CBR mapping, see clause 17.2 >=20 > 0x04 >=20 > =09 >=20 > 32 >=20 > =09 >=20 > SDH, G.709 ODUk >=20 > =09 >=20 > ditto >=20 > =09 >=20 > ATM mapping, see clause 17.3 >=20 > 0x05 >=20 > =09 >=20 > 54 >=20 > or >=20 > TBA (Suggested by Lou) >=20 > =09 >=20 > G.709 ODUk (and SDH) >=20 > =20 >=20 > =09 >=20 > G-PIDs defined in RFC4328 for framed GFP >=20 > =20 >=20 > =09 >=20 > GFP mapping, see clause 17.4 >=20 > 0x06 >=20 > =09 >=20 > None >=20 > =09 >=20 > =20 >=20 > =09 >=20 > Not needed and Not defined in RFC4328 >=20 > =09 >=20 > Virtual Concatenated signal, see clause 18 (Note 5) >=20 > 0x07 >=20 > =09 >=20 > 61(TBA) >=20 > Or55(Suggested by Lou) >=20 > =09 >=20 > G.709 ODUk (k=3D0,3,4) >=20 > =09 >=20 > Is being defined in this draft (new payload type defined in [G.709-2012]) >=20 > =09 >=20 > PCS codeword transparent Ethernet mapping: >=20 > * 1000BASE-X into OPU0, see clauses 17.7.1 and 17.7.1.1 >=20 > * 40GBASE-R into OPU3, see clauses 17.7.4 and 17.7.4.1 >=20 > * 100GBASE-R into OPU4, see clauses 17.7.5 and 17.7.5.1 >=20 > 0x08 >=20 > =09 >=20 > 62(TBA) >=20 > Or58(Suggested by Lou) >=20 > =09 >=20 > G.709 ODUk (k=3D2e) >=20 > =09 >=20 > ditto >=20 > =09 >=20 > FC-1200 into OPU2e mapping, see clause 17.8.2 >=20 > 0x09 >=20 > =09 >=20 > 63(TBA) >=20 > =09 >=20 > G.709 ODUk (k=3D2) >=20 > =09 >=20 > ditto >=20 > =09 >=20 > GFP mapping into Extended OPU2 payload, see clause 17.4.1 (Note 6) >=20 > 0x0A >=20 > =09 >=20 > 64(TBA) >=20 > =09 >=20 > G.709 ODUk (k=3D0) >=20 > =09 >=20 > ditto >=20 > =09 >=20 > STM-1 mapping into OPU0, see clause 17.7.1 >=20 > 0x0B >=20 > =09 >=20 > 65(TBA) >=20 > =09 >=20 > G.709 ODUk (k=3D0) >=20 > =09 >=20 > ditto >=20 > =09 >=20 > STM-4 mapping into OPU0, see clause 17.7.1 >=20 > 0x0C >=20 > =09 >=20 > 66(TBA) >=20 > Or58(Suggested by Lou) >=20 > =09 >=20 > G.709 ODUk (k=3D0) >=20 > =09 >=20 > ditto >=20 > =09 >=20 > FC-100 mapping into OPU0, see clause 17.7.1 >=20 > 0x0D >=20 > =09 >=20 > 67(TBA) >=20 > Or58(Suggested by Lou) >=20 > =09 >=20 > G.709 ODUk (k=3D1) >=20 > =09 >=20 > ditto >=20 > =09 >=20 > FC-200 mapping into OPU1, see clause 17.7.2 >=20 > 0x0E >=20 > =09 >=20 > 68(TBA) >=20 > Or58(Suggested by Lou) >=20 > =09 >=20 > G.709 ODUflex >=20 > =09 >=20 > ditto >=20 > =09 >=20 > FC-400 mapping into OPUflex, see clause 17.9 >=20 > 0x0F >=20 > =09 >=20 > 69(TBA) >=20 > Or58(Suggested by Lou) >=20 > =09 >=20 > G.709 ODUflex >=20 > =09 >=20 > ditto >=20 > =09 >=20 > FC-800 mapping into OPUflex, see clause 17.9 >=20 > 0x10 >=20 > =09 >=20 > 51 >=20 > =09 >=20 > G.709 ODUk >=20 > =09 >=20 > 1)G-PID defined in RFC4328; >=20 > 2) Updated in this draft. >=20 > =09 >=20 > Bit stream with octet timing mapping, see clause 17.6.1 >=20 > 0x11 >=20 > =09 >=20 > 52 >=20 > =09 >=20 > G.709 ODUk >=20 > =09 >=20 > ditto >=20 > =09 >=20 > Bit stream without octet timing mapping, see clause 17.6.2 >=20 > 0x12 >=20 > =09 >=20 > 70(TBA) >=20 > =09 >=20 > G.709 ODUflex >=20 > =09 >=20 > Is being defined in this draft (new payload type defined in [G.709-2012]) >=20 > =09 >=20 > IB SDR mapping into OPUflex, see 17.9 >=20 > 0x13 >=20 > =09 >=20 > 71(TBA) >=20 > =09 >=20 > G.709 ODUflex >=20 > =09 >=20 > ditto >=20 > =09 >=20 > IB DDR mapping into OPUflex, see 17.9 >=20 > 0x14 >=20 > =09 >=20 > 72(TBA) >=20 > =09 >=20 > G.709 ODUflex >=20 > =09 >=20 > ditto >=20 > =09 >=20 > IB QDR mapping into OPUflex, see 17.9 >=20 > 0x15 >=20 > =09 >=20 > 73(TBA) >=20 > =09 >=20 > G.709 ODUk (k=3D0) >=20 > =09 >=20 > ditto >=20 > =09 >=20 > SDI mapping into OPU0, see 17.7.1 >=20 > 0x16 >=20 > =09 >=20 > 74(TBA) >=20 > =09 >=20 > G.709 ODUk (k=3D1) >=20 > =09 >=20 > ditto >=20 > =09 >=20 > (1.485/1.001) Gbit/s SDI mapping into OPU1, see 17.7.2 >=20 > 0x17 >=20 > =09 >=20 > 75(TBA) >=20 > =09 >=20 > G.709 ODUk (k=3D1) >=20 > =09 >=20 > ditto >=20 > =09 >=20 > 1.485 Gbit/s SDI mapping into OPU1, see 17.7.2 >=20 > 0x18 >=20 > =09 >=20 > 76(TBA) >=20 > =09 >=20 > G.709 ODUflex >=20 > =09 >=20 > ditto >=20 > =09 >=20 > (2.970/1.001) Gbit/s SDI mapping into OPUflex, see 17.9 >=20 > 0x19 >=20 > =09 >=20 > 77(TBA) >=20 > =09 >=20 > G.709 ODUflex >=20 > =09 >=20 > ditto >=20 > =09 >=20 > 2.970 Gbit/s SDI mapping into OPUflex, see 17.9 >=20 > 0x1A >=20 > =09 >=20 > 78(TBA) >=20 > Or56(Suggested by Lou) >=20 > =09 >=20 > G.709 ODUk (k=3D0) >=20 > =09 >=20 > ditto >=20 > =09 >=20 > SBCON/ESCON mapping into OPU0, see 17.7.1 >=20 > 0x1B >=20 > =09 >=20 > 79(TBA) >=20 > =09 >=20 > G.709 ODUk (k=3D0) >=20 > =09 >=20 > ditto >=20 > =09 >=20 > DVB_ASI mapping into OPU0, see 17.7.1 >=20 > 0x20 >=20 > =09 >=20 > 47 >=20 > =09 >=20 > G.709 ODUk >=20 > =09 >=20 > 1) G-PIDs defined in RFC4328. >=20 > 2) Updated in this draft. >=20 > =09 >=20 > ODU multiplex structure supporting ODTUjk only, see clause 19 (AMP only) >=20 > 0x21 >=20 > =09 >=20 > 59/60(TBA) >=20 > =09 >=20 > G.709 ODUk >=20 > =09 >=20 > 1)Are being defined in this draft (new payload type defined in > [G.709-2012]); >=20 > 2) 59 for G.709 ODU-1.25G; 60 for G.709 ODU-any >=20 > =09 >=20 > ODU multiplex structure supporting ODTUk.ts or ODTUk.ts and ODTUjk, see > clause 19 (GMP capable) (Note 7) >=20 > 55 >=20 > =09 >=20 > None >=20 > =09 >=20 > =20 >=20 > =09 >=20 > Not needed >=20 > =09 >=20 > Not available (Note 2) >=20 > 66 >=20 > =09 >=20 > None >=20 > =09 >=20 > =20 >=20 > =09 >=20 > Not needed >=20 > =09 >=20 > Not available (Note 2) >=20 > 80-8F >=20 > =09 >=20 > None >=20 > =09 >=20 > =20 >=20 > =09 >=20 > Not needed >=20 > =09 >=20 > Reserved codes for proprietary use (Note 4) >=20 > FD >=20 > =09 >=20 > None >=20 > OrTBA(Suggested by Lou) >=20 > =09 >=20 > =20 >=20 > =09 >=20 > Not needed >=20 > =09 >=20 > NULL test signal mapping, see clause 17.5.1 >=20 > FE >=20 > =09 >=20 > None >=20 > OrTBA(Suggested by Lou) >=20 > =09 >=20 > =20 >=20 > =09 >=20 > Not needed >=20 > =09 >=20 > PRBS test signal mapping, see clause 17.5.2 >=20 > FF >=20 > =09 >=20 > None >=20 > =09 >=20 > =20 >=20 > =09 >=20 > Not needed >=20 > =09 >=20 > Not available (Note 2) >=20 > =20 >=20 > =09 >=20 > =20 >=20 > =09 >=20 > =20 >=20 > =09 >=20 > =20 >=20 > =09 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > Best Regards >=20 > =20 >=20 > Fatai >=20 > =20 >=20 > =20 >=20 > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Lou Berger > Sent: Tuesday, May 21, 2013 9:17 PM > To: CCAMP > Cc: draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org > Subject: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues= ) >=20 > =20 >=20 > All, >=20 > =20 >=20 > In the interest of moving this discussion quickly to closure, I spent >=20 > some time trying to come up with the full list of G.709 PT to G-PID >=20 > mappings. In coming up with this list I tried to be consistent with >=20 > the last consensus point that I can identify on this topic (the >=20 > previously referenced July 2012 thread & presentation), which included: >=20 > =20 >=20 > A) Defining new G-PIDs for client types not identified by an assigned >=20 > G-PID (per >=20 > http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parameters= .xml) >=20 > =20 >=20 > B) Reusing G-PID wherever {G-PID, ODU rate} unambiguously identify a >=20 > G.709 payload type, and define new G-PIDs when reuse not possible. >=20 > =20 >=20 > C) No G-PID value for unused, reserved, or proprietary 709 Payload Type. >=20 > =20 >=20 > Here's what I've come up with: >=20 > =20 >=20 > G.709 >=20 > Payload >=20 > Type G-PID Type/Comment LSP Encoding >=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > 0x01 No standard value >=20 > 0x02 49 CBRa G.709 ODUk >=20 > 0x03 50 CBRb G.709 ODUk >=20 > 0x04 32 ATM G.709 ODUk >=20 > 0x05 TBA1 Framed GFP G.709 ODUk >=20 > 0x06 ??? Is any valued needed? >=20 > 0x07 55 Ethernet PHY G.709 ODUk (k=3D0) >=20 > (transparent G.709 ODUk (k=3D3) >=20 > GFP) G.709 ODUk (k=3D4) >=20 > 0x08 58 Fiber Channel G.709 ODUk (k=3D2e) >=20 > 0x09 TBA1 Framed GFP G.709 ODUk (k=3D2e) >=20 > 0x0A TBA2 STM-1 G.709 ODUk (k=3D0) >=20 > 0x0B TBA3 STM-4 G.709 ODUk (k=3D0) >=20 > 0x0C 58 Fiber Channel G.709 ODUk (k=3D0) >=20 > 0x0D 58 Fiber Channel G.709 ODUk (k=3D1) >=20 > 0x0E 58 Fiber Channel G.709 ODUflex >=20 > 0x0F 58 Fiber Channel G.709 ODUflex >=20 > 0x10 51 BSOT G.709 ODUk >=20 > 0x11 52 BSNT G.709 ODUk >=20 > 0x12 TBA4 InfiniBand G.709 ODUflex >=20 > 0x13 TBA4 InfiniBand G.709 ODUflex >=20 > 0x14 TBA4 InfiniBand G.709 ODUflex >=20 > 0x15 TBA5 Serial Digital G.709 ODUk (k=3D0) >=20 > Interface >=20 > 0x16 TBA6 Serial Digital G.709 ODUk (k=3D1) >=20 > Interface/1.001 >=20 > 0x17 TBA5 Serial Digital G.709 ODUk (k=3D1) >=20 > Interface >=20 > 0x18 TBA6 Serial Digital G.709 ODUflex >=20 > Interface/1.001 >=20 > 0x19 TBA5 Serial Digital G.709 ODUflex >=20 > Interface >=20 > 0x1A 56 SBCON/ESCON G.709 ODUk (k=3D0) >=20 > (IANA to update Type field) >=20 > 0x1B TBA7 DVB_ASI G.709 ODUk (k=3D0) >=20 > 0x1C 58 Fiber Channel G.709 ODUk >=20 > 0x20 47 G.709 ODU-2.5G G.709 ODUk >=20 > (k=3D2,3) >=20 > (IANA to update Type field) >=20 > TBA8 G.709 ODU-1.25G G.709 ODUk >=20 > (k=3D1,2,3) >=20 > 0x21 TBA8 G.709 ODU-1.25G G.709 ODUk >=20 > (k=3D2,3,4) >=20 > TBA9 G.709 ODU-Any G.709 ODUk >=20 > (k=3D2,3) >=20 > 0x55 No standard value >=20 > 0x66 No standard value >=20 > 0x80-0x8F No standard value >=20 > 0xFD TBA10 Null Test G.709 ODUk >=20 > 0xFE TBA11 Random Test G.709 ODUk >=20 > 0xFF No standard value >=20 > =20 >=20 > Note that there are a few differences with Fatai's list, which doesn't >=20 > format well in e-mail, but is available in the archive >=20 > http://www.ietf.org/mail-archive/web/ccamp/current/msg14845.html >=20 > =20 >=20 > Please speak up if you think the above is not aligned with prior >=20 > consensus or if you have an issue with any of the above. >=20 > =20 >=20 > Much thanks, >=20 > Lou >=20 > =20 >=20 > =20 >=20 > On 5/20/2013 5:09 AM, Fatai Zhang wrote: >=20 >> Hi Lou, >=20 >>=20 >=20 >> =20 >=20 >>=20 >=20 >> I think my mail on March 13rd may have answered your following comments. >=20 >> My response quoted as follows. >=20 >>=20 >=20 >> =20 >=20 >>=20 >=20 >> In addition, if people look at the full list that I provided, I think >=20 >> people can realize that RFC4328 (section 3.1.3) used the same approach >=20 >> as the current approach of this draft (ie., 1:1 mapping between GPIDs >=20 >> and payload types defined by G.709), ie., we are following what RFC4328 >=20 >> did. >=20 >>=20 >=20 >> =20 >=20 >>=20 >=20 >> BTW, I am not sure if we need spend so much on discussing this point >=20 >> (because there is no issue to stick to the data plane by using the >=20 >> current approach of this draft). >=20 >>=20 >=20 >> =20 >=20 >>=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= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 >>=20 >=20 >> (2) 'Grouped GPID' vs '1:1' mapping (between G.709-2012 and GPIDs >=20 >> defined in this draft) >=20 >>=20 >=20 >> =20 >=20 >>=20 >=20 >> We realize that it is safe to use 1:1 mapping approach to avoid some >=20 >> potential issues after investigation. We know this payload types have >=20 >> been defined by G.709 (data plane), so physically it is better to use >=20 >> 1:1 mapping approach. >=20 >>=20 >=20 >> For the potential issues I mentioned above, for example, we cannot use >=20 >> the existing 34 to represent 'STM-1' and 'STM-4 ', because it is >=20 >> impossible to differentiate which one is 'STM-1' or 'STM-4'. In >=20 >> addition, from the concept of payload type, we know that e.g, FC-100 is >=20 >> different from FC-800, right? So, it is better to assign different GPIDs >=20 >> to these different payload types defined by the data plane. >=20 >>=20 >=20 >> =20 >=20 >>=20 >=20 >> Furthermore, I think it is much cheaper to create new GPIDs in the >=20 >> control plane than in the data plane (these payload types will be >=20 >> carried in the OH). >=20 >>=20 >=20 >> =20 >=20 >>=20 >=20 >> =20 >=20 >>=20 >=20 >> =20 >=20 >>=20 >=20 >> =20 >=20 >>=20 >=20 >> Best Regards >=20 >>=20 >=20 >> =20 >=20 >>=20 >=20 >> Fatai >=20 >>=20 >=20 >> =20 >=20 >>=20 >=20 >> -----Original Message----- >=20 >> From: Lou Berger [mailto:lberger@labn.net] >=20 >> Sent: Friday, May 17, 2013 11:16 PM >=20 >> To: Fatai Zhang >=20 >> Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; >=20 >> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >=20 >> Subject: Re: R: Closing G.709 open issues >=20 >>=20 >=20 >> =20 >=20 >>=20 >=20 >> Fatai, >=20 >>=20 >=20 >> =20 >=20 >>=20 >=20 >> That's a great start for the WG. Thank you. >=20 >>=20 >=20 >> =20 >=20 >>=20 >=20 >> To answer your implied question as to why my request for the full list. >=20 >>=20 >=20 >> My feeling is that there have been too many "surprises" on the 709 >=20 >>=20 >=20 >> documents in areas that I thought were either obvious (but from the IETF >=20 >>=20 >=20 >> & GMPLS context, not ITU-T or G.709 perspectives) or resolved by past >=20 >>=20 >=20 >> discussions. At this point, as co-chair and Document shepherd, I want >=20 >>=20 >=20 >> to ensure that any open point on the documents are unambiguously closed >=20 >>=20 >=20 >> and that past discussions (i.e., points of consensus) are 100% captured, >=20 >>=20 >=20 >> so that we can smoothly move through the planned second LC and >=20 >>=20 >=20 >> publication request. >=20 >>=20 >=20 >> =20 >=20 >>=20 >=20 >> To that end, in my previous message I asked two questions about points >=20 >>=20 >=20 >> where it seems you are proposing moving away from what has been >=20 >>=20 >=20 >> previously been discussed & agreed to by the WG. Can you answer the >=20 >>=20 >=20 >> following: >=20 >>=20 >=20 >> =20 >=20 >>=20 >=20 >>>> My questions on the new G-PIDs come down to: >=20 >>=20 >=20 >>>> - Why are rate specific G-PIDs being proposed (rather than >=20 >>=20 >=20 >>>> continuing to use the previous approach documented in the draft >=20 >>=20 >=20 >>>> and in Section 3.1.3 of rfc4328)? >=20 >>=20 >=20 >> =20 >=20 >>=20 >=20 >>>> - Why are new values being defined rather than using existing >=20 >>=20 >=20 >>>> values, e.g., G-PID 56? >=20 >>=20 >=20 >>>>=20 >=20 >>=20 >=20 >> =20 >=20 >>=20 >=20 >> Much thanks, >=20 >>=20 >=20 >> Lou >=20 >>=20 >=20 >> =20 >=20 >>=20 >=20 >> =20 >=20 >>=20 >=20 > _______________________________________________ >=20 > CCAMP mailing list >=20 > CCAMP@ietf.org >=20 > https://www.ietf.org/mailman/listinfo/ccamp >=20 From kpithewan@infinera.com Fri May 24 02:32:33 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04E0421F9643 for ; Fri, 24 May 2013 02:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WtkyEIpHSrC for ; Fri, 24 May 2013 02:32:28 -0700 (PDT) Received: from sv-casht-prod1.infinera.com (sv-casht-prod1.infinera.com [8.4.225.24]) by ietfa.amsl.com (Postfix) with ESMTP id CC24621F9401 for ; Fri, 24 May 2013 02:32:24 -0700 (PDT) Received: from SV-EXDB-PROD2.infinera.com ([fe80::1d05:1822:aaea:ff52]) by sv-casht-prod1.infinera.com ([10.100.97.218]) with mapi id 14.03.0123.003; Fri, 24 May 2013 02:32:23 -0700 From: Khuzema Pithewan To: Lou Berger Thread-Topic: Closing Issue #49 (Was: Re: R: Closing G.709 open issues) Thread-Index: AQHOViWNlSQKnFOnHEGp0kX3EXiVcJkTJgxwgACV9oCAAFWBoA== Date: Fri, 24 May 2013 09:32:22 +0000 Message-ID: References: <518A82D9.7080508@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> <518CED28.30303@labn.net> <51924382.2010904@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C90D5@ESESSMB301.ericsson.se> <13ea7ed3bdd.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <5193A26A.1090005@labn.net> <519649B4.5060408@labn.net> <519B73C9.2030308@labn.net> <519E84F9.1040103@labn.net> In-Reply-To: <519E84F9.1040103@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.96.93] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" Subject: Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 09:32:33 -0000 Hi Lou, -> Are you just trying to be exhaustive in your definitions, or do you have= an actual use case? If the latter, can you elaborate on your desired use? There is no actual usecase, rather intent is to align dataplane spec with c= ontrol plane spec. In reality, there may not arise any backward compatibility issue in foresee= able future, because GPid range is very large (16 bits) and vendor specific= client payload may choose to use very high Gpid value, where standard defi= ned GPid may not reach. Having said that, I am not sure, why RFC 3471 defines 4 Gpid values (1-4) a= s reserved. What purpose does it serve?=20 Either we define reserved values that underlying dataplane defines, or we d= on't define at all.=20 If we have convention of defining reserved GPids, then why not match it wi= th data plane spec.=20 However, I believe defining or not defining reserved value, is not going to= have any material impact on the way standard will be implemented. I am fin= e either way! Regards Khuzema -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Friday, May 24, 2013 2:37 AM To: Khuzema Pithewan Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org Subject: Re: Closing Issue #49 (Was: Re: R: Closing G.709 open issues) On 5/23/2013 3:15 PM, Khuzema Pithewan wrote: > Hi Lou, >=20 >=20 > -> C) No G-PID value for unused, reserved, or proprietary 709 Payload Typ= e. >=20 > Let say some vendor uses reserved (80-8F, which will never be=20 > standardized by ITU, as per Note4 in Table 15-8) payload code point=20 > and uses some GPid 'x' in Control plane for that code point. Now if in=20 > future, Control plane defines x for some other client. >=20 > There will be backward compatibility issues. Khuzema, I agree. Vendors have always used (and continue to use) standard code po= ints for proprietary purposes at their own peril. There is nothing new or = unique about this in the context of the documents we're discussing. Another way to look at it is to ask/answer the following: What about this d= raft (supporting [G709-2012]) is different from [RFC4328] (supporting g709-= 2001) or any other technology supported by GMPLS that has experimental, res= erved, and/or unavailable client types? >=20 > Since it is clearly mentioned that these 16 code points in dataplane,=20 > will not standardized, is a standardization in way, > which must be > followed up in control plane by reserving 16 GPids for the purpose. Why? [RFC4328] didn't standardize G-PIDs for the following G.709-2001 defi= ned PTs: PT Interpretation 0x01 Experimental mapping \ 0x55 Not available 0x66 Not available 0x80-0x8F Reserved codes for proprietary use 0xFF Not available Are you just trying to be exhaustive in your definitions, or do you have an= actual use case? If the latter, can you elaborate on your desired use? BTW you might want to look at the current IANA G-PID assignments before ans= wering. I suspect you'll find that you can address your concerns using exi= sting assignments. Thanks, Lou > Regds > Khuzema >=20 > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Tuesday, May 21, 2013 6:47 PM > To: CCAMP > Cc: draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org > Subject: Closing Issue #49 (Was: Re: R: Closing G.709 open issues) >=20 > All, >=20 > In the interest of moving this discussion quickly to closure, I spent=20 > some time trying to come up with the full list of G.709 PT to G-PID=20 > mappings. In coming up with this list I tried to be consistent with=20 > the last consensus point that I can identify on this topic (the=20 > previously referenced July 2012 thread & presentation), which included: >=20 > A) Defining new G-PIDs for client types not identified by an assigned=20 > G-PID (per > http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-paramet > ers.xml) >=20 > B) Reusing G-PID wherever {G-PID, ODU rate} unambiguously identify a > G.709 payload type, and define new G-PIDs when reuse not possible. >=20 > C) No G-PID value for unused, reserved, or proprietary 709 Payload Type. >=20 > Here's what I've come up with: >=20 > G.709 > Payload > Type G-PID Type/Comment LSP Encoding > =3D=3D=3D=3D =3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 0x01 No standard value > 0x02 49 CBRa G.709 ODUk > 0x03 50 CBRb G.709 ODUk > 0x04 32 ATM G.709 ODUk > 0x05 TBA1 Framed GFP G.709 ODUk > 0x06 ??? Is any valued needed? > 0x07 55 Ethernet PHY G.709 ODUk (k=3D0) > (transparent G.709 ODUk (k=3D3) > GFP) G.709 ODUk (k=3D4) > 0x08 58 Fiber Channel G.709 ODUk (k=3D2e) > 0x09 TBA1 Framed GFP G.709 ODUk (k=3D2e) > 0x0A TBA2 STM-1 G.709 ODUk (k=3D0) > 0x0B TBA3 STM-4 G.709 ODUk (k=3D0) > 0x0C 58 Fiber Channel G.709 ODUk (k=3D0) > 0x0D 58 Fiber Channel G.709 ODUk (k=3D1) > 0x0E 58 Fiber Channel G.709 ODUflex > 0x0F 58 Fiber Channel G.709 ODUflex > 0x10 51 BSOT G.709 ODUk > 0x11 52 BSNT G.709 ODUk > 0x12 TBA4 InfiniBand G.709 ODUflex > 0x13 TBA4 InfiniBand G.709 ODUflex > 0x14 TBA4 InfiniBand G.709 ODUflex > 0x15 TBA5 Serial Digital G.709 ODUk (k=3D0) > Interface > 0x16 TBA6 Serial Digital G.709 ODUk (k=3D1) > Interface/1.001 > 0x17 TBA5 Serial Digital G.709 ODUk (k=3D1) > Interface > 0x18 TBA6 Serial Digital G.709 ODUflex > Interface/1.001 > 0x19 TBA5 Serial Digital G.709 ODUflex > Interface > 0x1A 56 SBCON/ESCON G.709 ODUk (k=3D0) > (IANA to update Type field) > 0x1B TBA7 DVB_ASI G.709 ODUk (k=3D0) > 0x1C 58 Fiber Channel G.709 ODUk > 0x20 47 G.709 ODU-2.5G G.709 ODUk > (k=3D2,3) > (IANA to update Type field) > TBA8 G.709 ODU-1.25G G.709 ODUk > (k=3D1,2,3) > 0x21 TBA8 G.709 ODU-1.25G G.709 ODUk > (k=3D2,3,4) > TBA9 G.709 ODU-Any G.709 ODUk > (k=3D2,3) > 0x55 No standard value > 0x66 No standard value > 0x80-0x8F No standard value > 0xFD TBA10 Null Test G.709 ODUk > 0xFE TBA11 Random Test G.709 ODUk > 0xFF No standard value >=20 > Note that there are a few differences with Fatai's list, which doesn't=20 > format well in e-mail, but is available in the archive=20 > http://www.ietf.org/mail-archive/web/ccamp/current/msg14845.html >=20 > Please speak up if you think the above is not aligned with prior=20 > consensus or if you have an issue with any of the above. >=20 > Much thanks, > Lou >=20 >=20 > On 5/20/2013 5:09 AM, Fatai Zhang wrote: >> Hi Lou, >> >> =20 >> >> I think my mail on March 13rd may have answered your following comments. >> My response quoted as follows. >> >> =20 >> >> In addition, if people look at the full list that I provided, I think=20 >> people can realize that RFC4328 (section 3.1.3) used the same=20 >> approach as the current approach of this draft (ie., 1:1 mapping=20 >> between GPIDs and payload types defined by G.709), ie., we are=20 >> following what RFC4328 did. >> >> =20 >> >> BTW, I am not sure if we need spend so much on discussing this point=20 >> (because there is no issue to stick to the data plane by using the=20 >> current approach of this draft). >> >> =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= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> (2) 'Grouped GPID' vs '1:1' mapping (between G.709-2012 and GPIDs=20 >> defined in this draft) >> >> =20 >> >> We realize that it is safe to use 1:1 mapping approach to avoid some=20 >> potential issues after investigation. We know this payload types have=20 >> been defined by G.709 (data plane), so physically it is better to use >> 1:1 mapping approach. >> >> For the potential issues I mentioned above, for example, we cannot=20 >> use the existing 34 to represent 'STM-1' and 'STM-4 ', because it is=20 >> impossible to differentiate which one is 'STM-1' or 'STM-4'. In=20 >> addition, from the concept of payload type, we know that e.g, FC-100=20 >> is different from FC-800, right? So, it is better to assign different=20 >> GPIDs to these different payload types defined by the data plane. >> >> =20 >> >> Furthermore, I think it is much cheaper to create new GPIDs in the=20 >> control plane than in the data plane (these payload types will be=20 >> carried in the OH). >> >> =20 >> >> =20 >> >> =20 >> >> =20 >> >> Best Regards >> >> =20 >> >> Fatai >> >> =20 >> >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Friday, May 17, 2013 11:16 PM >> To: Fatai Zhang >> Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP;=20 >> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >> Subject: Re: R: Closing G.709 open issues >> >> =20 >> >> Fatai, >> >> =20 >> >> That's a great start for the WG. Thank you. >> >> =20 >> >> To answer your implied question as to why my request for the full list. >> >> My feeling is that there have been too many "surprises" on the 709 >> >> documents in areas that I thought were either obvious (but from the=20 >> IETF >> >> & GMPLS context, not ITU-T or G.709 perspectives) or resolved by past >> >> discussions. At this point, as co-chair and Document shepherd, I=20 >> want >> >> to ensure that any open point on the documents are unambiguously=20 >> closed >> >> and that past discussions (i.e., points of consensus) are 100%=20 >> captured, >> >> so that we can smoothly move through the planned second LC and >> >> publication request. >> >> =20 >> >> To that end, in my previous message I asked two questions about=20 >> points >> >> where it seems you are proposing moving away from what has been >> >> previously been discussed & agreed to by the WG. Can you answer the >> >> following: >> >> =20 >> >>>> My questions on the new G-PIDs come down to: >> >>>> - Why are rate specific G-PIDs being proposed (rather than >> >>>> continuing to use the previous approach documented in the draft >> >>>> and in Section 3.1.3 of rfc4328)? >> >> =20 >> >>>> - Why are new values being defined rather than using existing >> >>>> values, e.g., G-PID 56? >> >>>> >> >> =20 >> >> Much thanks, >> >> Lou >> >> =20 >> >> =20 >> >=20 >=20 >=20 >=20 From lberger@labn.net Fri May 24 06:15:52 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB42F21F8609 for ; Fri, 24 May 2013 06:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.102 X-Spam-Level: X-Spam-Status: No, score=-102.102 tagged_above=-999 required=5 tests=[AWL=-0.437, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_52=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VdS+-3-mjpF for ; Fri, 24 May 2013 06:15:48 -0700 (PDT) Received: from oproxy13-pub.unifiedlayer.com (oproxy13-pub.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id 4B35B21F85EF for ; Fri, 24 May 2013 06:15:48 -0700 (PDT) Received: (qmail 28394 invoked by uid 0); 24 May 2013 13:15:26 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy13.unifiedlayer.com with SMTP; 24 May 2013 13:15:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=8M2UAN3GdiHHnMnk3dfkmshcZchkierrzpZbjfOzDhE=; b=g8O2LwCe0I4qhBorFlUcqLpDsUfRuF00EgTb+kMLzaaiHASC21EV8Mk1jAfKYjElnN7t6Y8ZzaNHIhmrwFruH48n+o6qWignV7ZhqDj3Y/mv/w4jQkgM+lSeI7bfISYX; Received: from box313.bluehost.com ([69.89.31.113]:53597 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UfrqA-0002yS-1c; Fri, 24 May 2013 07:15:26 -0600 Message-ID: <519F67ED.3040701@labn.net> Date: Fri, 24 May 2013 09:15:25 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Fatai Zhang References: <518A82D9.7080508@labn.net> <518CED28.30303@labn.net> <51924382.2010904@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C90D5@ESESSMB301.ericsson.se> <13ea7ed3bdd.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <5193A26A.1090005@labn.net> <519649B4.5060408@labn.net> <519B73C9.2030308@labn.net> <519E406C.9030008@labn.net> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" Subject: Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 13:15:52 -0000 Fatai, Just to be clear, the following covers your correction: G.709 Payload Type G-PID Type/Comment LSP Encoding ==== ===== ============== =================== 0x05 TBA1 Framed GFP G.709 ODUk 54 Ethernet MAC G.709 ODUk (framed GFP) Right? Thanks, Lou On 5/23/2013 9:01 PM, Fatai Zhang wrote: > Hi Lou, > > Fine, thanks for your explanation. > > As I said, I will update the signaling draft based on your proposal if there are no further comments. > > > > Best Regards > > Fatai > > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Friday, May 24, 2013 12:15 AM > To: Fatai Zhang > Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org > Subject: Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues) > > Fatai, > Do we really need to reopen debate on a topic the WG discussed and > closed last summer? (i.e., to handle G.709 client adaptation just as we > do for every other technology.) > > I do agree that some new G-PID assignments were missed in the draft that > went to LC, but filling in the list doesn't automatically mean that the > WG needs to reopen debate on adaptation approaches. > > Assuming we don't need to reopen the pre-LC debate from last summer, and > with respect to the list I sent out, I do agree the WG needs to: > > A) Ensure that the list doesn't have unneeded new G-PIDs (i.e., reuses > the same/existing G-PIDs wherever possible.) > > B) Identifies the "right" G-PID per payload type, and doesn't have any > other technical errors > > C) Doesn't conflict with past WG decisions/discussions. > >>From your mails I see the following comment on (A): > >> For 0x05, why you think that RFC4328 does not cover it (ie., G-PID=54)? > > G-PID 54, per IANA, is currently defined as "Ethernet MAC (framed GFP)". > Per G.709, PT=0x05 maps to "GFP mapping, see clause 17.4" and looking > at 17.4 there is no restriction on what is carried in GFP frames. So it > seems that PT=0x05 can't be limited to just "Ethernet MAC (framed GFP)". > > Are you suggesting changing the type description of G-PID 54 to just > "Framed GFP", or including G-PID 54 as an additional possibility for > PT=0x05? > > The latter seems to be a valid addition/correction. The former may be > problematic for existing implementations, so we'll need to discuss more > broadly if that's the direction you want to head. > > All/ (WG), > > Again, please speak up if you think the above is not aligned with prior > consensus or if you have an issue with any of the above. > > Lou > > On 5/22/2013 10:35 PM, Fatai Zhang wrote: >> Hi Lou, >> >> >> >> I incorporated your proposal into my table to facilitate the readers. >> >> >> >> I think you still insist on reusing some existing G-PIDs like 58, 56. >> For 0x04, why you think that RFC4328 does not cover it (ie., G-PID=54)? >> >> >> >> Technically, I am not convince by your proposal, but I would like to >> reserve my opinion for your same motivation (ie., to conclude the >> discussion as soon as possible). >> >> >> >> Any opinions on Lou's proposal from the WG? I will update the signaling >> draft based on Lou's proposal if there is no comment on Lou's proposal. >> >> >> >> Note that all the new G-PID values will be re-ordered with TBA. >> >> >> >> *G-PIDs vs **Payload types defined in Table 15-8 of G.709* >> >> >> >> Payload Type in Hex codedefined in G.709 >> >> >> >> G-PID >> >> >> >> LSP Encoding >> >> >> >> Note >> >> >> >> Interpretationfrom G.709 >> >> 0x01 >> >> >> >> None >> >> >> >> >> >> >> >> Not needed >> >> >> >> Experimental mapping (Note 3) >> >> 0x02 >> >> >> >> 49 >> >> >> >> G.709 ODUk, G.709 OCh >> >> >> >> 1)G-PID defined in RFC4328; >> >> 2) Updated in this draft. >> >> >> >> Asynchronous CBR mapping, see clause 17.2 >> >> 0x03 >> >> >> >> 50 >> >> >> >> G.709 ODUk >> >> >> >> ditto >> >> >> >> Bit synchronous CBR mapping, see clause 17.2 >> >> 0x04 >> >> >> >> 32 >> >> >> >> SDH, G.709 ODUk >> >> >> >> ditto >> >> >> >> ATM mapping, see clause 17.3 >> >> 0x05 >> >> >> >> 54 >> >> or >> >> TBA (Suggested by Lou) >> >> >> >> G.709 ODUk (and SDH) >> >> >> >> >> >> G-PIDs defined in RFC4328 for framed GFP >> >> >> >> >> >> GFP mapping, see clause 17.4 >> >> 0x06 >> >> >> >> None >> >> >> >> >> >> >> >> Not needed and Not defined in RFC4328 >> >> >> >> Virtual Concatenated signal, see clause 18 (Note 5) >> >> 0x07 >> >> >> >> 61(TBA) >> >> Or55(Suggested by Lou) >> >> >> >> G.709 ODUk (k=0,3,4) >> >> >> >> Is being defined in this draft (new payload type defined in [G.709-2012]) >> >> >> >> PCS codeword transparent Ethernet mapping: >> >> * 1000BASE-X into OPU0, see clauses 17.7.1 and 17.7.1.1 >> >> * 40GBASE-R into OPU3, see clauses 17.7.4 and 17.7.4.1 >> >> * 100GBASE-R into OPU4, see clauses 17.7.5 and 17.7.5.1 >> >> 0x08 >> >> >> >> 62(TBA) >> >> Or58(Suggested by Lou) >> >> >> >> G.709 ODUk (k=2e) >> >> >> >> ditto >> >> >> >> FC-1200 into OPU2e mapping, see clause 17.8.2 >> >> 0x09 >> >> >> >> 63(TBA) >> >> >> >> G.709 ODUk (k=2) >> >> >> >> ditto >> >> >> >> GFP mapping into Extended OPU2 payload, see clause 17.4.1 (Note 6) >> >> 0x0A >> >> >> >> 64(TBA) >> >> >> >> G.709 ODUk (k=0) >> >> >> >> ditto >> >> >> >> STM-1 mapping into OPU0, see clause 17.7.1 >> >> 0x0B >> >> >> >> 65(TBA) >> >> >> >> G.709 ODUk (k=0) >> >> >> >> ditto >> >> >> >> STM-4 mapping into OPU0, see clause 17.7.1 >> >> 0x0C >> >> >> >> 66(TBA) >> >> Or58(Suggested by Lou) >> >> >> >> G.709 ODUk (k=0) >> >> >> >> ditto >> >> >> >> FC-100 mapping into OPU0, see clause 17.7.1 >> >> 0x0D >> >> >> >> 67(TBA) >> >> Or58(Suggested by Lou) >> >> >> >> G.709 ODUk (k=1) >> >> >> >> ditto >> >> >> >> FC-200 mapping into OPU1, see clause 17.7.2 >> >> 0x0E >> >> >> >> 68(TBA) >> >> Or58(Suggested by Lou) >> >> >> >> G.709 ODUflex >> >> >> >> ditto >> >> >> >> FC-400 mapping into OPUflex, see clause 17.9 >> >> 0x0F >> >> >> >> 69(TBA) >> >> Or58(Suggested by Lou) >> >> >> >> G.709 ODUflex >> >> >> >> ditto >> >> >> >> FC-800 mapping into OPUflex, see clause 17.9 >> >> 0x10 >> >> >> >> 51 >> >> >> >> G.709 ODUk >> >> >> >> 1)G-PID defined in RFC4328; >> >> 2) Updated in this draft. >> >> >> >> Bit stream with octet timing mapping, see clause 17.6.1 >> >> 0x11 >> >> >> >> 52 >> >> >> >> G.709 ODUk >> >> >> >> ditto >> >> >> >> Bit stream without octet timing mapping, see clause 17.6.2 >> >> 0x12 >> >> >> >> 70(TBA) >> >> >> >> G.709 ODUflex >> >> >> >> Is being defined in this draft (new payload type defined in [G.709-2012]) >> >> >> >> IB SDR mapping into OPUflex, see 17.9 >> >> 0x13 >> >> >> >> 71(TBA) >> >> >> >> G.709 ODUflex >> >> >> >> ditto >> >> >> >> IB DDR mapping into OPUflex, see 17.9 >> >> 0x14 >> >> >> >> 72(TBA) >> >> >> >> G.709 ODUflex >> >> >> >> ditto >> >> >> >> IB QDR mapping into OPUflex, see 17.9 >> >> 0x15 >> >> >> >> 73(TBA) >> >> >> >> G.709 ODUk (k=0) >> >> >> >> ditto >> >> >> >> SDI mapping into OPU0, see 17.7.1 >> >> 0x16 >> >> >> >> 74(TBA) >> >> >> >> G.709 ODUk (k=1) >> >> >> >> ditto >> >> >> >> (1.485/1.001) Gbit/s SDI mapping into OPU1, see 17.7.2 >> >> 0x17 >> >> >> >> 75(TBA) >> >> >> >> G.709 ODUk (k=1) >> >> >> >> ditto >> >> >> >> 1.485 Gbit/s SDI mapping into OPU1, see 17.7.2 >> >> 0x18 >> >> >> >> 76(TBA) >> >> >> >> G.709 ODUflex >> >> >> >> ditto >> >> >> >> (2.970/1.001) Gbit/s SDI mapping into OPUflex, see 17.9 >> >> 0x19 >> >> >> >> 77(TBA) >> >> >> >> G.709 ODUflex >> >> >> >> ditto >> >> >> >> 2.970 Gbit/s SDI mapping into OPUflex, see 17.9 >> >> 0x1A >> >> >> >> 78(TBA) >> >> Or56(Suggested by Lou) >> >> >> >> G.709 ODUk (k=0) >> >> >> >> ditto >> >> >> >> SBCON/ESCON mapping into OPU0, see 17.7.1 >> >> 0x1B >> >> >> >> 79(TBA) >> >> >> >> G.709 ODUk (k=0) >> >> >> >> ditto >> >> >> >> DVB_ASI mapping into OPU0, see 17.7.1 >> >> 0x20 >> >> >> >> 47 >> >> >> >> G.709 ODUk >> >> >> >> 1) G-PIDs defined in RFC4328. >> >> 2) Updated in this draft. >> >> >> >> ODU multiplex structure supporting ODTUjk only, see clause 19 (AMP only) >> >> 0x21 >> >> >> >> 59/60(TBA) >> >> >> >> G.709 ODUk >> >> >> >> 1)Are being defined in this draft (new payload type defined in >> [G.709-2012]); >> >> 2) 59 for G.709 ODU-1.25G; 60 for G.709 ODU-any >> >> >> >> ODU multiplex structure supporting ODTUk.ts or ODTUk.ts and ODTUjk, see >> clause 19 (GMP capable) (Note 7) >> >> 55 >> >> >> >> None >> >> >> >> >> >> >> >> Not needed >> >> >> >> Not available (Note 2) >> >> 66 >> >> >> >> None >> >> >> >> >> >> >> >> Not needed >> >> >> >> Not available (Note 2) >> >> 80-8F >> >> >> >> None >> >> >> >> >> >> >> >> Not needed >> >> >> >> Reserved codes for proprietary use (Note 4) >> >> FD >> >> >> >> None >> >> OrTBA(Suggested by Lou) >> >> >> >> >> >> >> >> Not needed >> >> >> >> NULL test signal mapping, see clause 17.5.1 >> >> FE >> >> >> >> None >> >> OrTBA(Suggested by Lou) >> >> >> >> >> >> >> >> Not needed >> >> >> >> PRBS test signal mapping, see clause 17.5.2 >> >> FF >> >> >> >> None >> >> >> >> >> >> >> >> Not needed >> >> >> >> Not available (Note 2) >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Best Regards >> >> >> >> Fatai >> >> >> >> >> >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf >> Of Lou Berger >> Sent: Tuesday, May 21, 2013 9:17 PM >> To: CCAMP >> Cc: draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >> Subject: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues) >> >> >> >> All, >> >> >> >> In the interest of moving this discussion quickly to closure, I spent >> >> some time trying to come up with the full list of G.709 PT to G-PID >> >> mappings. In coming up with this list I tried to be consistent with >> >> the last consensus point that I can identify on this topic (the >> >> previously referenced July 2012 thread & presentation), which included: >> >> >> >> A) Defining new G-PIDs for client types not identified by an assigned >> >> G-PID (per >> >> http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parameters.xml) >> >> >> >> B) Reusing G-PID wherever {G-PID, ODU rate} unambiguously identify a >> >> G.709 payload type, and define new G-PIDs when reuse not possible. >> >> >> >> C) No G-PID value for unused, reserved, or proprietary 709 Payload Type. >> >> >> >> Here's what I've come up with: >> >> >> >> G.709 >> >> Payload >> >> Type G-PID Type/Comment LSP Encoding >> >> ==== ===== ============== =================== >> >> 0x01 No standard value >> >> 0x02 49 CBRa G.709 ODUk >> >> 0x03 50 CBRb G.709 ODUk >> >> 0x04 32 ATM G.709 ODUk >> >> 0x05 TBA1 Framed GFP G.709 ODUk >> >> 0x06 ??? Is any valued needed? >> >> 0x07 55 Ethernet PHY G.709 ODUk (k=0) >> >> (transparent G.709 ODUk (k=3) >> >> GFP) G.709 ODUk (k=4) >> >> 0x08 58 Fiber Channel G.709 ODUk (k=2e) >> >> 0x09 TBA1 Framed GFP G.709 ODUk (k=2e) >> >> 0x0A TBA2 STM-1 G.709 ODUk (k=0) >> >> 0x0B TBA3 STM-4 G.709 ODUk (k=0) >> >> 0x0C 58 Fiber Channel G.709 ODUk (k=0) >> >> 0x0D 58 Fiber Channel G.709 ODUk (k=1) >> >> 0x0E 58 Fiber Channel G.709 ODUflex >> >> 0x0F 58 Fiber Channel G.709 ODUflex >> >> 0x10 51 BSOT G.709 ODUk >> >> 0x11 52 BSNT G.709 ODUk >> >> 0x12 TBA4 InfiniBand G.709 ODUflex >> >> 0x13 TBA4 InfiniBand G.709 ODUflex >> >> 0x14 TBA4 InfiniBand G.709 ODUflex >> >> 0x15 TBA5 Serial Digital G.709 ODUk (k=0) >> >> Interface >> >> 0x16 TBA6 Serial Digital G.709 ODUk (k=1) >> >> Interface/1.001 >> >> 0x17 TBA5 Serial Digital G.709 ODUk (k=1) >> >> Interface >> >> 0x18 TBA6 Serial Digital G.709 ODUflex >> >> Interface/1.001 >> >> 0x19 TBA5 Serial Digital G.709 ODUflex >> >> Interface >> >> 0x1A 56 SBCON/ESCON G.709 ODUk (k=0) >> >> (IANA to update Type field) >> >> 0x1B TBA7 DVB_ASI G.709 ODUk (k=0) >> >> 0x1C 58 Fiber Channel G.709 ODUk >> >> 0x20 47 G.709 ODU-2.5G G.709 ODUk >> >> (k=2,3) >> >> (IANA to update Type field) >> >> TBA8 G.709 ODU-1.25G G.709 ODUk >> >> (k=1,2,3) >> >> 0x21 TBA8 G.709 ODU-1.25G G.709 ODUk >> >> (k=2,3,4) >> >> TBA9 G.709 ODU-Any G.709 ODUk >> >> (k=2,3) >> >> 0x55 No standard value >> >> 0x66 No standard value >> >> 0x80-0x8F No standard value >> >> 0xFD TBA10 Null Test G.709 ODUk >> >> 0xFE TBA11 Random Test G.709 ODUk >> >> 0xFF No standard value >> >> >> >> Note that there are a few differences with Fatai's list, which doesn't >> >> format well in e-mail, but is available in the archive >> >> http://www.ietf.org/mail-archive/web/ccamp/current/msg14845.html >> >> >> >> Please speak up if you think the above is not aligned with prior >> >> consensus or if you have an issue with any of the above. >> >> >> >> Much thanks, >> >> Lou >> >> >> >> >> >> On 5/20/2013 5:09 AM, Fatai Zhang wrote: >> >>> Hi Lou, >> >>> >> >>> >> >>> >> >>> I think my mail on March 13rd may have answered your following comments. >> >>> My response quoted as follows. >> >>> >> >>> >> >>> >> >>> In addition, if people look at the full list that I provided, I think >> >>> people can realize that RFC4328 (section 3.1.3) used the same approach >> >>> as the current approach of this draft (ie., 1:1 mapping between GPIDs >> >>> and payload types defined by G.709), ie., we are following what RFC4328 >> >>> did. >> >>> >> >>> >> >>> >> >>> BTW, I am not sure if we need spend so much on discussing this point >> >>> (because there is no issue to stick to the data plane by using the >> >>> current approach of this draft). >> >>> >> >>> >> >>> >> >>> ====================================================================================================================== >> >>> >> >>> (2) 'Grouped GPID' vs '1:1' mapping (between G.709-2012 and GPIDs >> >>> defined in this draft) >> >>> >> >>> >> >>> >> >>> We realize that it is safe to use 1:1 mapping approach to avoid some >> >>> potential issues after investigation. We know this payload types have >> >>> been defined by G.709 (data plane), so physically it is better to use >> >>> 1:1 mapping approach. >> >>> >> >>> For the potential issues I mentioned above, for example, we cannot use >> >>> the existing 34 to represent 'STM-1' and 'STM-4 ', because it is >> >>> impossible to differentiate which one is 'STM-1' or 'STM-4'. In >> >>> addition, from the concept of payload type, we know that e.g, FC-100 is >> >>> different from FC-800, right? So, it is better to assign different GPIDs >> >>> to these different payload types defined by the data plane. >> >>> >> >>> >> >>> >> >>> Furthermore, I think it is much cheaper to create new GPIDs in the >> >>> control plane than in the data plane (these payload types will be >> >>> carried in the OH). >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> Best Regards >> >>> >> >>> >> >>> >> >>> Fatai >> >>> >> >>> >> >>> >> >>> -----Original Message----- >> >>> From: Lou Berger [mailto:lberger@labn.net] >> >>> Sent: Friday, May 17, 2013 11:16 PM >> >>> To: Fatai Zhang >> >>> Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; >> >>> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >> >>> Subject: Re: R: Closing G.709 open issues >> >>> >> >>> >> >>> >> >>> Fatai, >> >>> >> >>> >> >>> >> >>> That's a great start for the WG. Thank you. >> >>> >> >>> >> >>> >> >>> To answer your implied question as to why my request for the full list. >> >>> >> >>> My feeling is that there have been too many "surprises" on the 709 >> >>> >> >>> documents in areas that I thought were either obvious (but from the IETF >> >>> >> >>> & GMPLS context, not ITU-T or G.709 perspectives) or resolved by past >> >>> >> >>> discussions. At this point, as co-chair and Document shepherd, I want >> >>> >> >>> to ensure that any open point on the documents are unambiguously closed >> >>> >> >>> and that past discussions (i.e., points of consensus) are 100% captured, >> >>> >> >>> so that we can smoothly move through the planned second LC and >> >>> >> >>> publication request. >> >>> >> >>> >> >>> >> >>> To that end, in my previous message I asked two questions about points >> >>> >> >>> where it seems you are proposing moving away from what has been >> >>> >> >>> previously been discussed & agreed to by the WG. Can you answer the >> >>> >> >>> following: >> >>> >> >>> >> >>> >> >>>>> My questions on the new G-PIDs come down to: >> >>> >> >>>>> - Why are rate specific G-PIDs being proposed (rather than >> >>> >> >>>>> continuing to use the previous approach documented in the draft >> >>> >> >>>>> and in Section 3.1.3 of rfc4328)? >> >>> >> >>> >> >>> >> >>>>> - Why are new values being defined rather than using existing >> >>> >> >>>>> values, e.g., G-PID 56? >> >>> >> >>>>> >> >>> >> >>> >> >>> >> >>> Much thanks, >> >>> >> >>> Lou >> >>> >> >>> >> >>> >> >>> >> >>> >> >> _______________________________________________ >> >> CCAMP mailing list >> >> CCAMP@ietf.org >> >> https://www.ietf.org/mailman/listinfo/ccamp >> > > > > From lberger@labn.net Fri May 24 06:24:54 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8267C21F870F for ; Fri, 24 May 2013 06:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.386 X-Spam-Level: X-Spam-Status: No, score=-102.386 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zp+oqVSrbHc7 for ; Fri, 24 May 2013 06:24:50 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id CF27D21F8693 for ; Fri, 24 May 2013 06:24:48 -0700 (PDT) Received: (qmail 24451 invoked by uid 0); 24 May 2013 13:24:17 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy6.bluehost.com with SMTP; 24 May 2013 13:24:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=AKojPlqID1R4KIeU3sK0QXtN0dclAKmK5j0dVbmX4Q0=; b=Oql0zQBmWdhuZu4/7TYe5ATZOaozi+HT6/q+NCI8bXK31yel6JqVIr6JwRNskGWAG5IzlGpHsE6jE6SiQiin5zvk5T/WZASZQP3UXgSYN8NPZvRJb+lkhqdgnph6He1d; Received: from box313.bluehost.com ([69.89.31.113]:54806 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Ufryi-0007Fw-UV; Fri, 24 May 2013 07:24:17 -0600 Message-ID: <519F6A00.1050908@labn.net> Date: Fri, 24 May 2013 09:24:16 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Khuzema Pithewan References: <518A82D9.7080508@labn.net> <518CED28.30303@labn.net> <51924382.2010904@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C90D5@ESESSMB301.ericsson.se> <13ea7ed3bdd.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <5193A26A.1090005@labn.net> <519649B4.5060408@labn.net> <519B73C9.2030308@labn.net> <519E84F9.1040103@labn.net> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" Subject: Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 13:24:54 -0000 Khuzema, Glad to hear there's no actual use case / issue to be addressed. As to your general comments/observations, my perspective is that given the generic cross-technology nature of GMPLS there often isn't a direct 1:1 mapping of switching technology semantics to GMPLS semantics. As to your specific (theoretical) concern, I think you might have missed the following IANA controlled (and RFC4328 defined) ranges: 31744-32767 Experimental Usage/temporarily 32768-65535 Reserved Lou On 5/24/2013 5:32 AM, Khuzema Pithewan wrote: > Hi Lou, > > -> Are you just trying to be exhaustive in your definitions, or do you have an actual use case? If the latter, can you elaborate on your desired use? > > > There is no actual usecase, rather intent is to align dataplane spec with control plane spec. > > In reality, there may not arise any backward compatibility issue in foreseeable future, because GPid range is very large (16 bits) and vendor specific client payload may choose to use very high Gpid value, where standard defined GPid may not reach. > > Having said that, I am not sure, why RFC 3471 defines 4 Gpid values (1-4) as reserved. What purpose does it serve? > > Either we define reserved values that underlying dataplane defines, or we don't define at all. > > If we have convention of defining reserved GPids, then why not match it with data plane spec. > > However, I believe defining or not defining reserved value, is not going to have any material impact on the way standard will be implemented. I am fine either way! > > Regards > Khuzema > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Friday, May 24, 2013 2:37 AM > To: Khuzema Pithewan > Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org > Subject: Re: Closing Issue #49 (Was: Re: R: Closing G.709 open issues) > > > > On 5/23/2013 3:15 PM, Khuzema Pithewan wrote: >> Hi Lou, >> >> >> -> C) No G-PID value for unused, reserved, or proprietary 709 Payload Type. >> >> Let say some vendor uses reserved (80-8F, which will never be >> standardized by ITU, as per Note4 in Table 15-8) payload code point >> and uses some GPid 'x' in Control plane for that code point. Now if in >> future, Control plane defines x for some other client. >> >> There will be backward compatibility issues. > > Khuzema, > > I agree. Vendors have always used (and continue to use) standard code points for proprietary purposes at their own peril. There is nothing new or unique about this in the context of the documents we're discussing. > > Another way to look at it is to ask/answer the following: What about this draft (supporting [G709-2012]) is different from [RFC4328] (supporting g709-2001) or any other technology supported by GMPLS that has experimental, reserved, and/or unavailable client types? > >> >> Since it is clearly mentioned that these 16 code points in dataplane, >> will not standardized, is a standardization in way, > >> which must be >> followed up in control plane by reserving 16 GPids for the purpose. > > Why? [RFC4328] didn't standardize G-PIDs for the following G.709-2001 defined PTs: > > PT Interpretation > 0x01 Experimental mapping \ > 0x55 Not available > 0x66 Not available > 0x80-0x8F Reserved codes for proprietary use > 0xFF Not available > > Are you just trying to be exhaustive in your definitions, or do you have an actual use case? If the latter, can you elaborate on your desired use? > > BTW you might want to look at the current IANA G-PID assignments before answering. I suspect you'll find that you can address your concerns using existing assignments. > > Thanks, > Lou > >> Regds >> Khuzema >> >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Tuesday, May 21, 2013 6:47 PM >> To: CCAMP >> Cc: draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >> Subject: Closing Issue #49 (Was: Re: R: Closing G.709 open issues) >> >> All, >> >> In the interest of moving this discussion quickly to closure, I spent >> some time trying to come up with the full list of G.709 PT to G-PID >> mappings. In coming up with this list I tried to be consistent with >> the last consensus point that I can identify on this topic (the >> previously referenced July 2012 thread & presentation), which included: >> >> A) Defining new G-PIDs for client types not identified by an assigned >> G-PID (per >> http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-paramet >> ers.xml) >> >> B) Reusing G-PID wherever {G-PID, ODU rate} unambiguously identify a >> G.709 payload type, and define new G-PIDs when reuse not possible. >> >> C) No G-PID value for unused, reserved, or proprietary 709 Payload Type. >> >> Here's what I've come up with: >> >> G.709 >> Payload >> Type G-PID Type/Comment LSP Encoding >> ==== ===== ============== =================== >> 0x01 No standard value >> 0x02 49 CBRa G.709 ODUk >> 0x03 50 CBRb G.709 ODUk >> 0x04 32 ATM G.709 ODUk >> 0x05 TBA1 Framed GFP G.709 ODUk >> 0x06 ??? Is any valued needed? >> 0x07 55 Ethernet PHY G.709 ODUk (k=0) >> (transparent G.709 ODUk (k=3) >> GFP) G.709 ODUk (k=4) >> 0x08 58 Fiber Channel G.709 ODUk (k=2e) >> 0x09 TBA1 Framed GFP G.709 ODUk (k=2e) >> 0x0A TBA2 STM-1 G.709 ODUk (k=0) >> 0x0B TBA3 STM-4 G.709 ODUk (k=0) >> 0x0C 58 Fiber Channel G.709 ODUk (k=0) >> 0x0D 58 Fiber Channel G.709 ODUk (k=1) >> 0x0E 58 Fiber Channel G.709 ODUflex >> 0x0F 58 Fiber Channel G.709 ODUflex >> 0x10 51 BSOT G.709 ODUk >> 0x11 52 BSNT G.709 ODUk >> 0x12 TBA4 InfiniBand G.709 ODUflex >> 0x13 TBA4 InfiniBand G.709 ODUflex >> 0x14 TBA4 InfiniBand G.709 ODUflex >> 0x15 TBA5 Serial Digital G.709 ODUk (k=0) >> Interface >> 0x16 TBA6 Serial Digital G.709 ODUk (k=1) >> Interface/1.001 >> 0x17 TBA5 Serial Digital G.709 ODUk (k=1) >> Interface >> 0x18 TBA6 Serial Digital G.709 ODUflex >> Interface/1.001 >> 0x19 TBA5 Serial Digital G.709 ODUflex >> Interface >> 0x1A 56 SBCON/ESCON G.709 ODUk (k=0) >> (IANA to update Type field) >> 0x1B TBA7 DVB_ASI G.709 ODUk (k=0) >> 0x1C 58 Fiber Channel G.709 ODUk >> 0x20 47 G.709 ODU-2.5G G.709 ODUk >> (k=2,3) >> (IANA to update Type field) >> TBA8 G.709 ODU-1.25G G.709 ODUk >> (k=1,2,3) >> 0x21 TBA8 G.709 ODU-1.25G G.709 ODUk >> (k=2,3,4) >> TBA9 G.709 ODU-Any G.709 ODUk >> (k=2,3) >> 0x55 No standard value >> 0x66 No standard value >> 0x80-0x8F No standard value >> 0xFD TBA10 Null Test G.709 ODUk >> 0xFE TBA11 Random Test G.709 ODUk >> 0xFF No standard value >> >> Note that there are a few differences with Fatai's list, which doesn't >> format well in e-mail, but is available in the archive >> http://www.ietf.org/mail-archive/web/ccamp/current/msg14845.html >> >> Please speak up if you think the above is not aligned with prior >> consensus or if you have an issue with any of the above. >> >> Much thanks, >> Lou >> >> >> On 5/20/2013 5:09 AM, Fatai Zhang wrote: >>> Hi Lou, >>> >>> >>> >>> I think my mail on March 13rd may have answered your following comments. >>> My response quoted as follows. >>> >>> >>> >>> In addition, if people look at the full list that I provided, I think >>> people can realize that RFC4328 (section 3.1.3) used the same >>> approach as the current approach of this draft (ie., 1:1 mapping >>> between GPIDs and payload types defined by G.709), ie., we are >>> following what RFC4328 did. >>> >>> >>> >>> BTW, I am not sure if we need spend so much on discussing this point >>> (because there is no issue to stick to the data plane by using the >>> current approach of this draft). >>> >>> >>> >>> ===================================================================== >>> ================================================= >>> >>> (2) 'Grouped GPID' vs '1:1' mapping (between G.709-2012 and GPIDs >>> defined in this draft) >>> >>> >>> >>> We realize that it is safe to use 1:1 mapping approach to avoid some >>> potential issues after investigation. We know this payload types have >>> been defined by G.709 (data plane), so physically it is better to use >>> 1:1 mapping approach. >>> >>> For the potential issues I mentioned above, for example, we cannot >>> use the existing 34 to represent 'STM-1' and 'STM-4 ', because it is >>> impossible to differentiate which one is 'STM-1' or 'STM-4'. In >>> addition, from the concept of payload type, we know that e.g, FC-100 >>> is different from FC-800, right? So, it is better to assign different >>> GPIDs to these different payload types defined by the data plane. >>> >>> >>> >>> Furthermore, I think it is much cheaper to create new GPIDs in the >>> control plane than in the data plane (these payload types will be >>> carried in the OH). >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Best Regards >>> >>> >>> >>> Fatai >>> >>> >>> >>> -----Original Message----- >>> From: Lou Berger [mailto:lberger@labn.net] >>> Sent: Friday, May 17, 2013 11:16 PM >>> To: Fatai Zhang >>> Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; >>> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>> Subject: Re: R: Closing G.709 open issues >>> >>> >>> >>> Fatai, >>> >>> >>> >>> That's a great start for the WG. Thank you. >>> >>> >>> >>> To answer your implied question as to why my request for the full list. >>> >>> My feeling is that there have been too many "surprises" on the 709 >>> >>> documents in areas that I thought were either obvious (but from the >>> IETF >>> >>> & GMPLS context, not ITU-T or G.709 perspectives) or resolved by past >>> >>> discussions. At this point, as co-chair and Document shepherd, I >>> want >>> >>> to ensure that any open point on the documents are unambiguously >>> closed >>> >>> and that past discussions (i.e., points of consensus) are 100% >>> captured, >>> >>> so that we can smoothly move through the planned second LC and >>> >>> publication request. >>> >>> >>> >>> To that end, in my previous message I asked two questions about >>> points >>> >>> where it seems you are proposing moving away from what has been >>> >>> previously been discussed & agreed to by the WG. Can you answer the >>> >>> following: >>> >>> >>> >>>>> My questions on the new G-PIDs come down to: >>> >>>>> - Why are rate specific G-PIDs being proposed (rather than >>> >>>>> continuing to use the previous approach documented in the draft >>> >>>>> and in Section 3.1.3 of rfc4328)? >>> >>> >>> >>>>> - Why are new values being defined rather than using existing >>> >>>>> values, e.g., G-PID 56? >>> >>>>> >>> >>> >>> >>> Much thanks, >>> >>> Lou >>> >>> >>> >>> >>> >> >> >> >> > > > > From sergio.belotti@alcatel-lucent.com Fri May 24 08:55:23 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 647A721F9612 for ; Fri, 24 May 2013 08:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.649 X-Spam-Level: X-Spam-Status: No, score=-9.649 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XY4QfmBDlWWT for ; Fri, 24 May 2013 08:55:10 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id C573621F9051 for ; Fri, 24 May 2013 08:55:07 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r4OFsxN8024973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 24 May 2013 10:55:00 -0500 (CDT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r4OFswF5014673 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 May 2013 11:54:59 -0400 Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 24 May 2013 11:54:58 -0400 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.233]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Fri, 24 May 2013 17:54:47 +0200 From: "BELOTTI, SERGIO (SERGIO)" To: Lou Berger Thread-Topic: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues) Thread-Index: AQHOWIDa0uGEPb8n5EC3v4f6WF1pRZkUfDvQ Date: Fri, 24 May 2013 15:54:46 +0000 Message-ID: References: <518A82D9.7080508@labn.net> <518CED28.30303@labn.net> <51924382.2010904@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C90D5@ESESSMB301.ericsson.se> <13ea7ed3bdd.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <5193A26A.1090005@labn.net> <519649B4.5060408@labn.net> <519B73C9.2030308@labn.net> <519E406C.9030008@labn.net> <519F67ED.3040701@labn.net> In-Reply-To: <519F67ED.3040701@labn.net> Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" Subject: [CCAMP] R: Closing Issue #49 (Was: Re: R: Closing G.709 open issues) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 15:55:24 -0000 Hi, Please take care anyway this solution does not consider two cases: G.7041 and G.709, defines respectively: 10GbE --> GFP-F (G.7041, Table 6-3: UPI=3D0x13 [ Frame-mapped 64B/66B enco= ded Ethernet, including the Ethernet frame preamble ]) 10GbE--> extended OPU2/ODU2 (G.709, Table 15-8: PT=3D0x09 [ GFP mapping int= o Extended OPU2 payload, see clause 17.4.1 ]) Please not that this is not the mapping using UPI=3D0x01 and PT=3D0x05 Best Regards Sergio Belotti Sergio- System Architect ALCATE-LUCENT Optics Division via Trento 30 Vimercate (MB) - Italy phone +39 (039) 6863033 -----Messaggio originale----- Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di Lou= Berger Inviato: venerd=EC 24 maggio 2013 15.15 A: Fatai Zhang Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org Oggetto: Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issu= es) Fatai, Just to be clear, the following covers your correction: G.709 Payload Type G-PID Type/Comment LSP Encoding =3D=3D=3D=3D =3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 0x05 TBA1 Framed GFP G.709 ODUk 54 Ethernet MAC G.709 ODUk (framed GFP) Right? Thanks, Lou On 5/23/2013 9:01 PM, Fatai Zhang wrote: > Hi Lou, >=20 > Fine, thanks for your explanation. >=20 > As I said, I will update the signaling draft based on your proposal if th= ere are no further comments. >=20 >=20 >=20 > Best Regards >=20 > Fatai >=20 >=20 > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net]=20 > Sent: Friday, May 24, 2013 12:15 AM > To: Fatai Zhang > Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org > Subject: Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open is= sues) >=20 > Fatai, > Do we really need to reopen debate on a topic the WG discussed and > closed last summer? (i.e., to handle G.709 client adaptation just as we > do for every other technology.) >=20 > I do agree that some new G-PID assignments were missed in the draft that > went to LC, but filling in the list doesn't automatically mean that the > WG needs to reopen debate on adaptation approaches. >=20 > Assuming we don't need to reopen the pre-LC debate from last summer, and > with respect to the list I sent out, I do agree the WG needs to: >=20 > A) Ensure that the list doesn't have unneeded new G-PIDs (i.e., reuses > the same/existing G-PIDs wherever possible.) >=20 > B) Identifies the "right" G-PID per payload type, and doesn't have any > other technical errors >=20 > C) Doesn't conflict with past WG decisions/discussions. >=20 >>From your mails I see the following comment on (A): >=20 >> For 0x05, why you think that RFC4328 does not cover it (ie., G-PID=3D54)= ? >=20 > G-PID 54, per IANA, is currently defined as "Ethernet MAC (framed GFP)". > Per G.709, PT=3D0x05 maps to "GFP mapping, see clause 17.4" and looking > at 17.4 there is no restriction on what is carried in GFP frames. So it > seems that PT=3D0x05 can't be limited to just "Ethernet MAC (framed GFP)"= . >=20 > Are you suggesting changing the type description of G-PID 54 to just > "Framed GFP", or including G-PID 54 as an additional possibility for > PT=3D0x05? >=20 > The latter seems to be a valid addition/correction. The former may be > problematic for existing implementations, so we'll need to discuss more > broadly if that's the direction you want to head. >=20 > All/ (WG), >=20 > Again, please speak up if you think the above is not aligned with prior > consensus or if you have an issue with any of the above. >=20 > Lou >=20 > On 5/22/2013 10:35 PM, Fatai Zhang wrote: >> Hi Lou, >> >> =20 >> >> I incorporated your proposal into my table to facilitate the readers. >> >> =20 >> >> I think you still insist on reusing some existing G-PIDs like 58, 56. >> For 0x04, why you think that RFC4328 does not cover it (ie., G-PID=3D54= )? >> >> =20 >> >> Technically, I am not convince by your proposal, but I would like to >> reserve my opinion for your same motivation (ie., to conclude the >> discussion as soon as possible). >> >> =20 >> >> Any opinions on Lou's proposal from the WG? I will update the signaling >> draft based on Lou's proposal if there is no comment on Lou's proposal. >> >> =20 >> >> Note that all the new G-PID values will be re-ordered with TBA. >> >> =20 >> >> *G-PIDs vs **Payload types defined in Table 15-8 of G.709* >> >> =20 >> >> Payload Type in Hex codedefined in G.709 >> >> =09 >> >> G-PID >> >> =09 >> >> LSP Encoding >> >> =09 >> >> Note >> >> =09 >> >> Interpretationfrom G.709 >> >> 0x01 >> >> =09 >> >> None >> >> =09 >> >> =20 >> >> =09 >> >> Not needed >> >> =09 >> >> Experimental mapping (Note 3) >> >> 0x02 >> >> =09 >> >> 49 >> >> =09 >> >> G.709 ODUk, G.709 OCh >> >> =09 >> >> 1)G-PID defined in RFC4328; >> >> 2) Updated in this draft. >> >> =09 >> >> Asynchronous CBR mapping, see clause 17.2 >> >> 0x03 >> >> =09 >> >> 50 >> >> =09 >> >> G.709 ODUk >> >> =09 >> >> ditto >> >> =09 >> >> Bit synchronous CBR mapping, see clause 17.2 >> >> 0x04 >> >> =09 >> >> 32 >> >> =09 >> >> SDH, G.709 ODUk >> >> =09 >> >> ditto >> >> =09 >> >> ATM mapping, see clause 17.3 >> >> 0x05 >> >> =09 >> >> 54 >> >> or >> >> TBA (Suggested by Lou) >> >> =09 >> >> G.709 ODUk (and SDH) >> >> =20 >> >> =09 >> >> G-PIDs defined in RFC4328 for framed GFP >> >> =20 >> >> =09 >> >> GFP mapping, see clause 17.4 >> >> 0x06 >> >> =09 >> >> None >> >> =09 >> >> =20 >> >> =09 >> >> Not needed and Not defined in RFC4328 >> >> =09 >> >> Virtual Concatenated signal, see clause 18 (Note 5) >> >> 0x07 >> >> =09 >> >> 61(TBA) >> >> Or55(Suggested by Lou) >> >> =09 >> >> G.709 ODUk (k=3D0,3,4) >> >> =09 >> >> Is being defined in this draft (new payload type defined in [G.709-2012]= ) >> >> =09 >> >> PCS codeword transparent Ethernet mapping: >> >> * 1000BASE-X into OPU0, see clauses 17.7.1 and 17.7.1.1 >> >> * 40GBASE-R into OPU3, see clauses 17.7.4 and 17.7.4.1 >> >> * 100GBASE-R into OPU4, see clauses 17.7.5 and 17.7.5.1 >> >> 0x08 >> >> =09 >> >> 62(TBA) >> >> Or58(Suggested by Lou) >> >> =09 >> >> G.709 ODUk (k=3D2e) >> >> =09 >> >> ditto >> >> =09 >> >> FC-1200 into OPU2e mapping, see clause 17.8.2 >> >> 0x09 >> >> =09 >> >> 63(TBA) >> >> =09 >> >> G.709 ODUk (k=3D2) >> >> =09 >> >> ditto >> >> =09 >> >> GFP mapping into Extended OPU2 payload, see clause 17.4.1 (Note 6) >> >> 0x0A >> >> =09 >> >> 64(TBA) >> >> =09 >> >> G.709 ODUk (k=3D0) >> >> =09 >> >> ditto >> >> =09 >> >> STM-1 mapping into OPU0, see clause 17.7.1 >> >> 0x0B >> >> =09 >> >> 65(TBA) >> >> =09 >> >> G.709 ODUk (k=3D0) >> >> =09 >> >> ditto >> >> =09 >> >> STM-4 mapping into OPU0, see clause 17.7.1 >> >> 0x0C >> >> =09 >> >> 66(TBA) >> >> Or58(Suggested by Lou) >> >> =09 >> >> G.709 ODUk (k=3D0) >> >> =09 >> >> ditto >> >> =09 >> >> FC-100 mapping into OPU0, see clause 17.7.1 >> >> 0x0D >> >> =09 >> >> 67(TBA) >> >> Or58(Suggested by Lou) >> >> =09 >> >> G.709 ODUk (k=3D1) >> >> =09 >> >> ditto >> >> =09 >> >> FC-200 mapping into OPU1, see clause 17.7.2 >> >> 0x0E >> >> =09 >> >> 68(TBA) >> >> Or58(Suggested by Lou) >> >> =09 >> >> G.709 ODUflex >> >> =09 >> >> ditto >> >> =09 >> >> FC-400 mapping into OPUflex, see clause 17.9 >> >> 0x0F >> >> =09 >> >> 69(TBA) >> >> Or58(Suggested by Lou) >> >> =09 >> >> G.709 ODUflex >> >> =09 >> >> ditto >> >> =09 >> >> FC-800 mapping into OPUflex, see clause 17.9 >> >> 0x10 >> >> =09 >> >> 51 >> >> =09 >> >> G.709 ODUk >> >> =09 >> >> 1)G-PID defined in RFC4328; >> >> 2) Updated in this draft. >> >> =09 >> >> Bit stream with octet timing mapping, see clause 17.6.1 >> >> 0x11 >> >> =09 >> >> 52 >> >> =09 >> >> G.709 ODUk >> >> =09 >> >> ditto >> >> =09 >> >> Bit stream without octet timing mapping, see clause 17.6.2 >> >> 0x12 >> >> =09 >> >> 70(TBA) >> >> =09 >> >> G.709 ODUflex >> >> =09 >> >> Is being defined in this draft (new payload type defined in [G.709-2012]= ) >> >> =09 >> >> IB SDR mapping into OPUflex, see 17.9 >> >> 0x13 >> >> =09 >> >> 71(TBA) >> >> =09 >> >> G.709 ODUflex >> >> =09 >> >> ditto >> >> =09 >> >> IB DDR mapping into OPUflex, see 17.9 >> >> 0x14 >> >> =09 >> >> 72(TBA) >> >> =09 >> >> G.709 ODUflex >> >> =09 >> >> ditto >> >> =09 >> >> IB QDR mapping into OPUflex, see 17.9 >> >> 0x15 >> >> =09 >> >> 73(TBA) >> >> =09 >> >> G.709 ODUk (k=3D0) >> >> =09 >> >> ditto >> >> =09 >> >> SDI mapping into OPU0, see 17.7.1 >> >> 0x16 >> >> =09 >> >> 74(TBA) >> >> =09 >> >> G.709 ODUk (k=3D1) >> >> =09 >> >> ditto >> >> =09 >> >> (1.485/1.001) Gbit/s SDI mapping into OPU1, see 17.7.2 >> >> 0x17 >> >> =09 >> >> 75(TBA) >> >> =09 >> >> G.709 ODUk (k=3D1) >> >> =09 >> >> ditto >> >> =09 >> >> 1.485 Gbit/s SDI mapping into OPU1, see 17.7.2 >> >> 0x18 >> >> =09 >> >> 76(TBA) >> >> =09 >> >> G.709 ODUflex >> >> =09 >> >> ditto >> >> =09 >> >> (2.970/1.001) Gbit/s SDI mapping into OPUflex, see 17.9 >> >> 0x19 >> >> =09 >> >> 77(TBA) >> >> =09 >> >> G.709 ODUflex >> >> =09 >> >> ditto >> >> =09 >> >> 2.970 Gbit/s SDI mapping into OPUflex, see 17.9 >> >> 0x1A >> >> =09 >> >> 78(TBA) >> >> Or56(Suggested by Lou) >> >> =09 >> >> G.709 ODUk (k=3D0) >> >> =09 >> >> ditto >> >> =09 >> >> SBCON/ESCON mapping into OPU0, see 17.7.1 >> >> 0x1B >> >> =09 >> >> 79(TBA) >> >> =09 >> >> G.709 ODUk (k=3D0) >> >> =09 >> >> ditto >> >> =09 >> >> DVB_ASI mapping into OPU0, see 17.7.1 >> >> 0x20 >> >> =09 >> >> 47 >> >> =09 >> >> G.709 ODUk >> >> =09 >> >> 1) G-PIDs defined in RFC4328. >> >> 2) Updated in this draft. >> >> =09 >> >> ODU multiplex structure supporting ODTUjk only, see clause 19 (AMP only) >> >> 0x21 >> >> =09 >> >> 59/60(TBA) >> >> =09 >> >> G.709 ODUk >> >> =09 >> >> 1)Are being defined in this draft (new payload type defined in >> [G.709-2012]); >> >> 2) 59 for G.709 ODU-1.25G; 60 for G.709 ODU-any >> >> =09 >> >> ODU multiplex structure supporting ODTUk.ts or ODTUk.ts and ODTUjk, see >> clause 19 (GMP capable) (Note 7) >> >> 55 >> >> =09 >> >> None >> >> =09 >> >> =20 >> >> =09 >> >> Not needed >> >> =09 >> >> Not available (Note 2) >> >> 66 >> >> =09 >> >> None >> >> =09 >> >> =20 >> >> =09 >> >> Not needed >> >> =09 >> >> Not available (Note 2) >> >> 80-8F >> >> =09 >> >> None >> >> =09 >> >> =20 >> >> =09 >> >> Not needed >> >> =09 >> >> Reserved codes for proprietary use (Note 4) >> >> FD >> >> =09 >> >> None >> >> OrTBA(Suggested by Lou) >> >> =09 >> >> =20 >> >> =09 >> >> Not needed >> >> =09 >> >> NULL test signal mapping, see clause 17.5.1 >> >> FE >> >> =09 >> >> None >> >> OrTBA(Suggested by Lou) >> >> =09 >> >> =20 >> >> =09 >> >> Not needed >> >> =09 >> >> PRBS test signal mapping, see clause 17.5.2 >> >> FF >> >> =09 >> >> None >> >> =09 >> >> =20 >> >> =09 >> >> Not needed >> >> =09 >> >> Not available (Note 2) >> >> =20 >> >> =09 >> >> =20 >> >> =09 >> >> =20 >> >> =09 >> >> =20 >> >> =09 >> >> =20 >> >> =20 >> >> =20 >> >> =20 >> >> =20 >> >> Best Regards >> >> =20 >> >> Fatai >> >> =20 >> >> =20 >> >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf >> Of Lou Berger >> Sent: Tuesday, May 21, 2013 9:17 PM >> To: CCAMP >> Cc: draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >> Subject: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issue= s) >> >> =20 >> >> All, >> >> =20 >> >> In the interest of moving this discussion quickly to closure, I spent >> >> some time trying to come up with the full list of G.709 PT to G-PID >> >> mappings. In coming up with this list I tried to be consistent with >> >> the last consensus point that I can identify on this topic (the >> >> previously referenced July 2012 thread & presentation), which included: >> >> =20 >> >> A) Defining new G-PIDs for client types not identified by an assigned >> >> G-PID (per >> >> http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parameter= s.xml) >> >> =20 >> >> B) Reusing G-PID wherever {G-PID, ODU rate} unambiguously identify a >> >> G.709 payload type, and define new G-PIDs when reuse not possible. >> >> =20 >> >> C) No G-PID value for unused, reserved, or proprietary 709 Payload Type. >> >> =20 >> >> Here's what I've come up with: >> >> =20 >> >> G.709 >> >> Payload >> >> Type G-PID Type/Comment LSP Encoding >> >> =3D=3D=3D=3D =3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> 0x01 No standard value >> >> 0x02 49 CBRa G.709 ODUk >> >> 0x03 50 CBRb G.709 ODUk >> >> 0x04 32 ATM G.709 ODUk >> >> 0x05 TBA1 Framed GFP G.709 ODUk >> >> 0x06 ??? Is any valued needed? >> >> 0x07 55 Ethernet PHY G.709 ODUk (k=3D0) >> >> (transparent G.709 ODUk (k=3D3) >> >> GFP) G.709 ODUk (k=3D4) >> >> 0x08 58 Fiber Channel G.709 ODUk (k=3D2e) >> >> 0x09 TBA1 Framed GFP G.709 ODUk (k=3D2e) >> >> 0x0A TBA2 STM-1 G.709 ODUk (k=3D0) >> >> 0x0B TBA3 STM-4 G.709 ODUk (k=3D0) >> >> 0x0C 58 Fiber Channel G.709 ODUk (k=3D0) >> >> 0x0D 58 Fiber Channel G.709 ODUk (k=3D1) >> >> 0x0E 58 Fiber Channel G.709 ODUflex >> >> 0x0F 58 Fiber Channel G.709 ODUflex >> >> 0x10 51 BSOT G.709 ODUk >> >> 0x11 52 BSNT G.709 ODUk >> >> 0x12 TBA4 InfiniBand G.709 ODUflex >> >> 0x13 TBA4 InfiniBand G.709 ODUflex >> >> 0x14 TBA4 InfiniBand G.709 ODUflex >> >> 0x15 TBA5 Serial Digital G.709 ODUk (k=3D0) >> >> Interface >> >> 0x16 TBA6 Serial Digital G.709 ODUk (k=3D1) >> >> Interface/1.001 >> >> 0x17 TBA5 Serial Digital G.709 ODUk (k=3D1) >> >> Interface >> >> 0x18 TBA6 Serial Digital G.709 ODUflex >> >> Interface/1.001 >> >> 0x19 TBA5 Serial Digital G.709 ODUflex >> >> Interface >> >> 0x1A 56 SBCON/ESCON G.709 ODUk (k=3D0) >> >> (IANA to update Type field) >> >> 0x1B TBA7 DVB_ASI G.709 ODUk (k=3D0) >> >> 0x1C 58 Fiber Channel G.709 ODUk >> >> 0x20 47 G.709 ODU-2.5G G.709 ODUk >> >> (k=3D2,3) >> >> (IANA to update Type field) >> >> TBA8 G.709 ODU-1.25G G.709 ODUk >> >> (k=3D1,2,3) >> >> 0x21 TBA8 G.709 ODU-1.25G G.709 ODUk >> >> (k=3D2,3,4) >> >> TBA9 G.709 ODU-Any G.709 ODUk >> >> (k=3D2,3) >> >> 0x55 No standard value >> >> 0x66 No standard value >> >> 0x80-0x8F No standard value >> >> 0xFD TBA10 Null Test G.709 ODUk >> >> 0xFE TBA11 Random Test G.709 ODUk >> >> 0xFF No standard value >> >> =20 >> >> Note that there are a few differences with Fatai's list, which doesn't >> >> format well in e-mail, but is available in the archive >> >> http://www.ietf.org/mail-archive/web/ccamp/current/msg14845.html >> >> =20 >> >> Please speak up if you think the above is not aligned with prior >> >> consensus or if you have an issue with any of the above. >> >> =20 >> >> Much thanks, >> >> Lou >> >> =20 >> >> =20 >> >> On 5/20/2013 5:09 AM, Fatai Zhang wrote: >> >>> Hi Lou, >> >>> >> >>> =20 >> >>> >> >>> I think my mail on March 13rd may have answered your following comments= . >> >>> My response quoted as follows. >> >>> >> >>> =20 >> >>> >> >>> In addition, if people look at the full list that I provided, I think >> >>> people can realize that RFC4328 (section 3.1.3) used the same approach >> >>> as the current approach of this draft (ie., 1:1 mapping between GPIDs >> >>> and payload types defined by G.709), ie., we are following what RFC4328 >> >>> did. >> >>> >> >>> =20 >> >>> >> >>> BTW, I am not sure if we need spend so much on discussing this point >> >>> (because there is no issue to stick to the data plane by using the >> >>> current approach of this draft). >> >>> >> >>> =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >>> >> >>> (2) 'Grouped GPID' vs '1:1' mapping (between G.709-2012 and GPIDs >> >>> defined in this draft) >> >>> >> >>> =20 >> >>> >> >>> We realize that it is safe to use 1:1 mapping approach to avoid some >> >>> potential issues after investigation. We know this payload types have >> >>> been defined by G.709 (data plane), so physically it is better to use >> >>> 1:1 mapping approach. >> >>> >> >>> For the potential issues I mentioned above, for example, we cannot use >> >>> the existing 34 to represent 'STM-1' and 'STM-4 ', because it is >> >>> impossible to differentiate which one is 'STM-1' or 'STM-4'. In >> >>> addition, from the concept of payload type, we know that e.g, FC-100 is >> >>> different from FC-800, right? So, it is better to assign different GPID= s >> >>> to these different payload types defined by the data plane. >> >>> >> >>> =20 >> >>> >> >>> Furthermore, I think it is much cheaper to create new GPIDs in the >> >>> control plane than in the data plane (these payload types will be >> >>> carried in the OH). >> >>> >> >>> =20 >> >>> >> >>> =20 >> >>> >> >>> =20 >> >>> >> >>> =20 >> >>> >> >>> Best Regards >> >>> >> >>> =20 >> >>> >> >>> Fatai >> >>> >> >>> =20 >> >>> >> >>> -----Original Message----- >> >>> From: Lou Berger [mailto:lberger@labn.net] >> >>> Sent: Friday, May 17, 2013 11:16 PM >> >>> To: Fatai Zhang >> >>> Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; >> >>> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >> >>> Subject: Re: R: Closing G.709 open issues >> >>> >> >>> =20 >> >>> >> >>> Fatai, >> >>> >> >>> =20 >> >>> >> >>> That's a great start for the WG. Thank you. >> >>> >> >>> =20 >> >>> >> >>> To answer your implied question as to why my request for the full list. >> >>> >> >>> My feeling is that there have been too many "surprises" on the 709 >> >>> >> >>> documents in areas that I thought were either obvious (but from the IET= F >> >>> >> >>> & GMPLS context, not ITU-T or G.709 perspectives) or resolved by past >> >>> >> >>> discussions. At this point, as co-chair and Document shepherd, I want >> >>> >> >>> to ensure that any open point on the documents are unambiguously closed >> >>> >> >>> and that past discussions (i.e., points of consensus) are 100% captured= , >> >>> >> >>> so that we can smoothly move through the planned second LC and >> >>> >> >>> publication request. >> >>> >> >>> =20 >> >>> >> >>> To that end, in my previous message I asked two questions about points >> >>> >> >>> where it seems you are proposing moving away from what has been >> >>> >> >>> previously been discussed & agreed to by the WG. Can you answer the >> >>> >> >>> following: >> >>> >> >>> =20 >> >>> >> >>>>> My questions on the new G-PIDs come down to: >> >>> >> >>>>> - Why are rate specific G-PIDs being proposed (rather than >> >>> >> >>>>> continuing to use the previous approach documented in the draft >> >>> >> >>>>> and in Section 3.1.3 of rfc4328)? >> >>> >> >>> =20 >> >>> >> >>>>> - Why are new values being defined rather than using existing >> >>> >> >>>>> values, e.g., G-PID 56? >> >>> >> >>>>> >> >>> >> >>> =20 >> >>> >> >>> Much thanks, >> >>> >> >>> Lou >> >>> >> >>> =20 >> >>> >> >>> =20 >> >>> >> >> _______________________________________________ >> >> CCAMP mailing list >> >> CCAMP@ietf.org >> >> https://www.ietf.org/mailman/listinfo/ccamp >> >=20 >=20 >=20 >=20 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From kpithewan@infinera.com Fri May 24 09:27:59 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7FC21F965B for ; Fri, 24 May 2013 09:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TV20BrbKEgTq for ; Fri, 24 May 2013 09:27:52 -0700 (PDT) Received: from sv-casht-prod1.infinera.com (sv-casht-prod1.infinera.com [8.4.225.24]) by ietfa.amsl.com (Postfix) with ESMTP id BD93321F966F for ; Fri, 24 May 2013 09:27:48 -0700 (PDT) Received: from SV-EXDB-PROD2.infinera.com ([fe80::1d05:1822:aaea:ff52]) by sv-casht-prod1.infinera.com ([10.100.97.218]) with mapi id 14.03.0123.003; Fri, 24 May 2013 09:27:47 -0700 From: Khuzema Pithewan To: Lou Berger Thread-Topic: Closing Issue #49 (Was: Re: R: Closing G.709 open issues) Thread-Index: AQHOViWNlSQKnFOnHEGp0kX3EXiVcJkTJgxwgACV9oCAAFWBoIAAu4QA//+9sbA= Date: Fri, 24 May 2013 16:27:46 +0000 Message-ID: References: <518A82D9.7080508@labn.net> <518CED28.30303@labn.net> <51924382.2010904@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C90D5@ESESSMB301.ericsson.se> <13ea7ed3bdd.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <5193A26A.1090005@labn.net> <519649B4.5060408@labn.net> <519B73C9.2030308@labn.net> <519E84F9.1040103@labn.net> <519F6A00.1050908@labn.net> In-Reply-To: <519F6A00.1050908@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.156.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" Subject: Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 16:27:59 -0000 Thanks Lou. Appreciate the pointer to RFC4328. I did miss it. Regards Khuzema -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Friday, May 24, 2013 6:54 PM To: Khuzema Pithewan Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org Subject: Re: Closing Issue #49 (Was: Re: R: Closing G.709 open issues) Khuzema, Glad to hear there's no actual use case / issue to be addressed. As to your general comments/observations, my perspective is that given the = generic cross-technology nature of GMPLS there often isn't a direct 1:1 mapping of switching technology semantics to GMPLS semantics. As to your specific (theoretical) concern, I think you might have missed th= e following IANA controlled (and RFC4328 defined) ranges: 31744-32767 Experimental Usage/temporarily 32768-65535 Reserved Lou On 5/24/2013 5:32 AM, Khuzema Pithewan wrote: > Hi Lou, >=20 > -> Are you just trying to be exhaustive in your definitions, or do you ha= ve an actual use case? If the latter, can you elaborate on your desired us= e? >=20 >=20 > There is no actual usecase, rather intent is to align dataplane spec with= control plane spec. >=20 > In reality, there may not arise any backward compatibility issue in fores= eeable future, because GPid range is very large (16 bits) and vendor specif= ic client payload may choose to use very high Gpid value, where standard de= fined GPid may not reach. >=20 > Having said that, I am not sure, why RFC 3471 defines 4 Gpid values (1-4)= as reserved. What purpose does it serve?=20 >=20 > Either we define reserved values that underlying dataplane defines, or we= don't define at all.=20 >=20 > If we have convention of defining reserved GPids, then why not match it = with data plane spec.=20 >=20 > However, I believe defining or not defining reserved value, is not going = to have any material impact on the way standard will be implemented. I am f= ine either way! >=20 > Regards > Khuzema >=20 > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Friday, May 24, 2013 2:37 AM > To: Khuzema Pithewan > Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org > Subject: Re: Closing Issue #49 (Was: Re: R: Closing G.709 open issues) >=20 >=20 >=20 > On 5/23/2013 3:15 PM, Khuzema Pithewan wrote: >> Hi Lou, >> >> >> -> C) No G-PID value for unused, reserved, or proprietary 709 Payload Ty= pe. >> >> Let say some vendor uses reserved (80-8F, which will never be=20 >> standardized by ITU, as per Note4 in Table 15-8) payload code point=20 >> and uses some GPid 'x' in Control plane for that code point. Now if=20 >> in future, Control plane defines x for some other client. >> >> There will be backward compatibility issues. >=20 > Khuzema, >=20 > I agree. Vendors have always used (and continue to use) standard code = points for proprietary purposes at their own peril. There is nothing new o= r unique about this in the context of the documents we're discussing. >=20 > Another way to look at it is to ask/answer the following: What about this= draft (supporting [G709-2012]) is different from [RFC4328] (supporting g70= 9-2001) or any other technology supported by GMPLS that has experimental, r= eserved, and/or unavailable client types? >=20 >> >> Since it is clearly mentioned that these 16 code points in dataplane,=20 >> will not standardized, is a standardization in way, >=20 >> which must be >> followed up in control plane by reserving 16 GPids for the purpose. >=20 > Why? [RFC4328] didn't standardize G-PIDs for the following G.709-2001 de= fined PTs: >=20 > PT Interpretation > 0x01 Experimental mapping \ > 0x55 Not available > 0x66 Not available > 0x80-0x8F Reserved codes for proprietary use > 0xFF Not available >=20 > Are you just trying to be exhaustive in your definitions, or do you have = an actual use case? If the latter, can you elaborate on your desired use? >=20 > BTW you might want to look at the current IANA G-PID assignments before a= nswering. I suspect you'll find that you can address your concerns using e= xisting assignments. >=20 > Thanks, > Lou >=20 >> Regds >> Khuzema >> >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Tuesday, May 21, 2013 6:47 PM >> To: CCAMP >> Cc: draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >> Subject: Closing Issue #49 (Was: Re: R: Closing G.709 open issues) >> >> All, >> >> In the interest of moving this discussion quickly to closure, I spent=20 >> some time trying to come up with the full list of G.709 PT to G-PID=20 >> mappings. In coming up with this list I tried to be consistent with=20 >> the last consensus point that I can identify on this topic (the=20 >> previously referenced July 2012 thread & presentation), which included: >> >> A) Defining new G-PIDs for client types not identified by an assigned=20 >> G-PID (per=20 >> http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parame >> t >> ers.xml) >> >> B) Reusing G-PID wherever {G-PID, ODU rate} unambiguously identify a >> G.709 payload type, and define new G-PIDs when reuse not possible. >> >> C) No G-PID value for unused, reserved, or proprietary 709 Payload Type. >> >> Here's what I've come up with: >> >> G.709 >> Payload >> Type G-PID Type/Comment LSP Encoding >> =3D=3D=3D=3D =3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> 0x01 No standard value >> 0x02 49 CBRa G.709 ODUk >> 0x03 50 CBRb G.709 ODUk >> 0x04 32 ATM G.709 ODUk >> 0x05 TBA1 Framed GFP G.709 ODUk >> 0x06 ??? Is any valued needed? >> 0x07 55 Ethernet PHY G.709 ODUk (k=3D0) >> (transparent G.709 ODUk (k=3D3) >> GFP) G.709 ODUk (k=3D4) >> 0x08 58 Fiber Channel G.709 ODUk (k=3D2e) >> 0x09 TBA1 Framed GFP G.709 ODUk (k=3D2e) >> 0x0A TBA2 STM-1 G.709 ODUk (k=3D0) >> 0x0B TBA3 STM-4 G.709 ODUk (k=3D0) >> 0x0C 58 Fiber Channel G.709 ODUk (k=3D0) >> 0x0D 58 Fiber Channel G.709 ODUk (k=3D1) >> 0x0E 58 Fiber Channel G.709 ODUflex >> 0x0F 58 Fiber Channel G.709 ODUflex >> 0x10 51 BSOT G.709 ODUk >> 0x11 52 BSNT G.709 ODUk >> 0x12 TBA4 InfiniBand G.709 ODUflex >> 0x13 TBA4 InfiniBand G.709 ODUflex >> 0x14 TBA4 InfiniBand G.709 ODUflex >> 0x15 TBA5 Serial Digital G.709 ODUk (k=3D0) >> Interface >> 0x16 TBA6 Serial Digital G.709 ODUk (k=3D1) >> Interface/1.001 >> 0x17 TBA5 Serial Digital G.709 ODUk (k=3D1) >> Interface >> 0x18 TBA6 Serial Digital G.709 ODUflex >> Interface/1.001 >> 0x19 TBA5 Serial Digital G.709 ODUflex >> Interface >> 0x1A 56 SBCON/ESCON G.709 ODUk (k=3D0) >> (IANA to update Type field) >> 0x1B TBA7 DVB_ASI G.709 ODUk (k=3D0) >> 0x1C 58 Fiber Channel G.709 ODUk >> 0x20 47 G.709 ODU-2.5G G.709 ODUk >> (k=3D2,3) >> (IANA to update Type field) >> TBA8 G.709 ODU-1.25G G.709 ODUk >> (k=3D1,2,3) >> 0x21 TBA8 G.709 ODU-1.25G G.709 ODUk >> (k=3D2,3,4) >> TBA9 G.709 ODU-Any G.709 ODUk >> (k=3D2,3) >> 0x55 No standard value >> 0x66 No standard value >> 0x80-0x8F No standard value >> 0xFD TBA10 Null Test G.709 ODUk >> 0xFE TBA11 Random Test G.709 ODUk >> 0xFF No standard value >> >> Note that there are a few differences with Fatai's list, which=20 >> doesn't format well in e-mail, but is available in the archive=20 >> http://www.ietf.org/mail-archive/web/ccamp/current/msg14845.html >> >> Please speak up if you think the above is not aligned with prior=20 >> consensus or if you have an issue with any of the above. >> >> Much thanks, >> Lou >> >> >> On 5/20/2013 5:09 AM, Fatai Zhang wrote: >>> Hi Lou, >>> >>> =20 >>> >>> I think my mail on March 13rd may have answered your following comments= . >>> My response quoted as follows. >>> >>> =20 >>> >>> In addition, if people look at the full list that I provided, I=20 >>> think people can realize that RFC4328 (section 3.1.3) used the same=20 >>> approach as the current approach of this draft (ie., 1:1 mapping=20 >>> between GPIDs and payload types defined by G.709), ie., we are=20 >>> following what RFC4328 did. >>> >>> =20 >>> >>> BTW, I am not sure if we need spend so much on discussing this point=20 >>> (because there is no issue to stick to the data plane by using the=20 >>> current approach of this draft). >>> >>> =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> =3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D >>> >>> (2) 'Grouped GPID' vs '1:1' mapping (between G.709-2012 and GPIDs=20 >>> defined in this draft) >>> >>> =20 >>> >>> We realize that it is safe to use 1:1 mapping approach to avoid some=20 >>> potential issues after investigation. We know this payload types=20 >>> have been defined by G.709 (data plane), so physically it is better=20 >>> to use >>> 1:1 mapping approach. >>> >>> For the potential issues I mentioned above, for example, we cannot=20 >>> use the existing 34 to represent 'STM-1' and 'STM-4 ', because it is=20 >>> impossible to differentiate which one is 'STM-1' or 'STM-4'. In=20 >>> addition, from the concept of payload type, we know that e.g, FC-100=20 >>> is different from FC-800, right? So, it is better to assign=20 >>> different GPIDs to these different payload types defined by the data pl= ane. >>> >>> =20 >>> >>> Furthermore, I think it is much cheaper to create new GPIDs in the=20 >>> control plane than in the data plane (these payload types will be=20 >>> carried in the OH). >>> >>> =20 >>> >>> =20 >>> >>> =20 >>> >>> =20 >>> >>> Best Regards >>> >>> =20 >>> >>> Fatai >>> >>> =20 >>> >>> -----Original Message----- >>> From: Lou Berger [mailto:lberger@labn.net] >>> Sent: Friday, May 17, 2013 11:16 PM >>> To: Fatai Zhang >>> Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP;=20 >>> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>> Subject: Re: R: Closing G.709 open issues >>> >>> =20 >>> >>> Fatai, >>> >>> =20 >>> >>> That's a great start for the WG. Thank you. >>> >>> =20 >>> >>> To answer your implied question as to why my request for the full list. >>> >>> My feeling is that there have been too many "surprises" on the 709 >>> >>> documents in areas that I thought were either obvious (but from the=20 >>> IETF >>> >>> & GMPLS context, not ITU-T or G.709 perspectives) or resolved by=20 >>> past >>> >>> discussions. At this point, as co-chair and Document shepherd, I=20 >>> want >>> >>> to ensure that any open point on the documents are unambiguously=20 >>> closed >>> >>> and that past discussions (i.e., points of consensus) are 100%=20 >>> captured, >>> >>> so that we can smoothly move through the planned second LC and >>> >>> publication request. >>> >>> =20 >>> >>> To that end, in my previous message I asked two questions about=20 >>> points >>> >>> where it seems you are proposing moving away from what has been >>> >>> previously been discussed & agreed to by the WG. Can you answer the >>> >>> following: >>> >>> =20 >>> >>>>> My questions on the new G-PIDs come down to: >>> >>>>> - Why are rate specific G-PIDs being proposed (rather than >>> >>>>> continuing to use the previous approach documented in the draft >>> >>>>> and in Section 3.1.3 of rfc4328)? >>> >>> =20 >>> >>>>> - Why are new values being defined rather than using existing >>> >>>>> values, e.g., G-PID 56? >>> >>>>> >>> >>> =20 >>> >>> Much thanks, >>> >>> Lou >>> >>> =20 >>> >>> =20 >>> >> >> >> >> >=20 >=20 >=20 >=20 From lberger@labn.net Fri May 24 09:33:28 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 078FE21F969D for ; Fri, 24 May 2013 09:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.077 X-Spam-Level: X-Spam-Status: No, score=-102.077 tagged_above=-999 required=5 tests=[AWL=-0.412, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_52=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMiPZCUmt5Ma for ; Fri, 24 May 2013 09:33:23 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id 9D31121F9679 for ; Fri, 24 May 2013 09:33:23 -0700 (PDT) Received: (qmail 10656 invoked by uid 0); 24 May 2013 16:33:01 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 24 May 2013 16:33:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=U6uCGwgqygWYPb/14ASRimUIxJ5wSA6Nb2F7e+LlUWE=; b=k6/06a9NhiWulu/bFkxePX/+hp6W11I6mVJ04L602odtF0xvmUdyHAJpx21y1vcZY01AlJ+W75uEycuWY/k7B6vzeBhyEqpDewnwwqVKQlGWbqluCzF5f2863EMf6GEQ; Received: from box313.bluehost.com ([69.89.31.113]:53261 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UfuvN-0006SM-Em; Fri, 24 May 2013 10:33:01 -0600 Message-ID: <519F963C.9060305@labn.net> Date: Fri, 24 May 2013 12:33:00 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "BELOTTI, SERGIO (SERGIO)" References: <518A82D9.7080508@labn.net> <51924382.2010904@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C90D5@ESESSMB301.ericsson.se> <13ea7ed3bdd.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <5193A26A.1090005@labn.net> <519649B4.5060408@labn.net> <519B73C9.2030308@labn.net> <519E406C.9030008@labn.net> <519F67ED.3040701@labn.net> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" Subject: Re: [CCAMP] R: Closing Issue #49 (Was: Re: R: Closing G.709 open issues) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 16:33:28 -0000 Sergio, On 5/24/2013 11:54 AM, BELOTTI, SERGIO (SERGIO) wrote: > Hi, > > Please take care anyway this solution does not consider two cases: > > G.7041 and G.709, defines respectively: > > 10GbE --> GFP-F (G.7041, Table 6-3: UPI=0x13 [ Frame-mapped 64B/66B encoded > Ethernet, including the Ethernet frame preamble ]) Cool, yet another way to encode Ethernet over GFP. (Pointing to the G.7041 UPI was very helpful, the draft will need to capture that!) What PT is used for this? Are there other client types missing/that you think are missing? > > 10GbE--> extended OPU2/ODU2 (G.709, Table 15-8: PT=0x09 [ GFP mapping into Extended > OPU2 payload, see clause 17.4.1 ]) Is this a different case? If yes, how so? (Do you have a data plane reference?) Thanks, Lou > > Please not that this is not the mapping using UPI=0x01 and PT=0x05 > > Best Regards > > Sergio > > Belotti Sergio- System Architect > ALCATE-LUCENT Optics Division > via Trento 30 Vimercate (MB) - Italy > phone +39 (039) 6863033 > -----Messaggio originale----- > Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di Lou Berger > Inviato: venerdì 24 maggio 2013 15.15 > A: Fatai Zhang > Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org > Oggetto: Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues) > > Fatai, > > Just to be clear, the following covers your correction: > > G.709 > Payload > Type G-PID Type/Comment LSP Encoding > ==== ===== ============== =================== > 0x05 TBA1 Framed GFP G.709 ODUk > 54 Ethernet MAC G.709 ODUk > (framed GFP) > > Right? > > Thanks, > Lou > > On 5/23/2013 9:01 PM, Fatai Zhang wrote: >> Hi Lou, >> >> Fine, thanks for your explanation. >> >> As I said, I will update the signaling draft based on your proposal if there are no further comments. >> >> >> >> Best Regards >> >> Fatai >> >> >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Friday, May 24, 2013 12:15 AM >> To: Fatai Zhang >> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >> Subject: Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues) >> >> Fatai, >> Do we really need to reopen debate on a topic the WG discussed and >> closed last summer? (i.e., to handle G.709 client adaptation just as we >> do for every other technology.) >> >> I do agree that some new G-PID assignments were missed in the draft that >> went to LC, but filling in the list doesn't automatically mean that the >> WG needs to reopen debate on adaptation approaches. >> >> Assuming we don't need to reopen the pre-LC debate from last summer, and >> with respect to the list I sent out, I do agree the WG needs to: >> >> A) Ensure that the list doesn't have unneeded new G-PIDs (i.e., reuses >> the same/existing G-PIDs wherever possible.) >> >> B) Identifies the "right" G-PID per payload type, and doesn't have any >> other technical errors >> >> C) Doesn't conflict with past WG decisions/discussions. >> >> >From your mails I see the following comment on (A): >> >>> For 0x05, why you think that RFC4328 does not cover it (ie., G-PID=54)? >> >> G-PID 54, per IANA, is currently defined as "Ethernet MAC (framed GFP)". >> Per G.709, PT=0x05 maps to "GFP mapping, see clause 17.4" and looking >> at 17.4 there is no restriction on what is carried in GFP frames. So it >> seems that PT=0x05 can't be limited to just "Ethernet MAC (framed GFP)". >> >> Are you suggesting changing the type description of G-PID 54 to just >> "Framed GFP", or including G-PID 54 as an additional possibility for >> PT=0x05? >> >> The latter seems to be a valid addition/correction. The former may be >> problematic for existing implementations, so we'll need to discuss more >> broadly if that's the direction you want to head. >> >> All/ (WG), >> >> Again, please speak up if you think the above is not aligned with prior >> consensus or if you have an issue with any of the above. >> >> Lou >> >> On 5/22/2013 10:35 PM, Fatai Zhang wrote: >>> Hi Lou, >>> >>> >>> >>> I incorporated your proposal into my table to facilitate the readers. >>> >>> >>> >>> I think you still insist on reusing some existing G-PIDs like 58, 56. >>> For 0x04, why you think that RFC4328 does not cover it (ie., G-PID=54)? >>> >>> >>> >>> Technically, I am not convince by your proposal, but I would like to >>> reserve my opinion for your same motivation (ie., to conclude the >>> discussion as soon as possible). >>> >>> >>> >>> Any opinions on Lou's proposal from the WG? I will update the signaling >>> draft based on Lou's proposal if there is no comment on Lou's proposal. >>> >>> >>> >>> Note that all the new G-PID values will be re-ordered with TBA. >>> >>> >>> >>> *G-PIDs vs **Payload types defined in Table 15-8 of G.709* >>> >>> >>> >>> Payload Type in Hex codedefined in G.709 >>> >>> >>> >>> G-PID >>> >>> >>> >>> LSP Encoding >>> >>> >>> >>> Note >>> >>> >>> >>> Interpretationfrom G.709 >>> >>> 0x01 >>> >>> >>> >>> None >>> >>> >>> >>> >>> >>> >>> >>> Not needed >>> >>> >>> >>> Experimental mapping (Note 3) >>> >>> 0x02 >>> >>> >>> >>> 49 >>> >>> >>> >>> G.709 ODUk, G.709 OCh >>> >>> >>> >>> 1)G-PID defined in RFC4328; >>> >>> 2) Updated in this draft. >>> >>> >>> >>> Asynchronous CBR mapping, see clause 17.2 >>> >>> 0x03 >>> >>> >>> >>> 50 >>> >>> >>> >>> G.709 ODUk >>> >>> >>> >>> ditto >>> >>> >>> >>> Bit synchronous CBR mapping, see clause 17.2 >>> >>> 0x04 >>> >>> >>> >>> 32 >>> >>> >>> >>> SDH, G.709 ODUk >>> >>> >>> >>> ditto >>> >>> >>> >>> ATM mapping, see clause 17.3 >>> >>> 0x05 >>> >>> >>> >>> 54 >>> >>> or >>> >>> TBA (Suggested by Lou) >>> >>> >>> >>> G.709 ODUk (and SDH) >>> >>> >>> >>> >>> >>> G-PIDs defined in RFC4328 for framed GFP >>> >>> >>> >>> >>> >>> GFP mapping, see clause 17.4 >>> >>> 0x06 >>> >>> >>> >>> None >>> >>> >>> >>> >>> >>> >>> >>> Not needed and Not defined in RFC4328 >>> >>> >>> >>> Virtual Concatenated signal, see clause 18 (Note 5) >>> >>> 0x07 >>> >>> >>> >>> 61(TBA) >>> >>> Or55(Suggested by Lou) >>> >>> >>> >>> G.709 ODUk (k=0,3,4) >>> >>> >>> >>> Is being defined in this draft (new payload type defined in [G.709-2012]) >>> >>> >>> >>> PCS codeword transparent Ethernet mapping: >>> >>> * 1000BASE-X into OPU0, see clauses 17.7.1 and 17.7.1.1 >>> >>> * 40GBASE-R into OPU3, see clauses 17.7.4 and 17.7.4.1 >>> >>> * 100GBASE-R into OPU4, see clauses 17.7.5 and 17.7.5.1 >>> >>> 0x08 >>> >>> >>> >>> 62(TBA) >>> >>> Or58(Suggested by Lou) >>> >>> >>> >>> G.709 ODUk (k=2e) >>> >>> >>> >>> ditto >>> >>> >>> >>> FC-1200 into OPU2e mapping, see clause 17.8.2 >>> >>> 0x09 >>> >>> >>> >>> 63(TBA) >>> >>> >>> >>> G.709 ODUk (k=2) >>> >>> >>> >>> ditto >>> >>> >>> >>> GFP mapping into Extended OPU2 payload, see clause 17.4.1 (Note 6) >>> >>> 0x0A >>> >>> >>> >>> 64(TBA) >>> >>> >>> >>> G.709 ODUk (k=0) >>> >>> >>> >>> ditto >>> >>> >>> >>> STM-1 mapping into OPU0, see clause 17.7.1 >>> >>> 0x0B >>> >>> >>> >>> 65(TBA) >>> >>> >>> >>> G.709 ODUk (k=0) >>> >>> >>> >>> ditto >>> >>> >>> >>> STM-4 mapping into OPU0, see clause 17.7.1 >>> >>> 0x0C >>> >>> >>> >>> 66(TBA) >>> >>> Or58(Suggested by Lou) >>> >>> >>> >>> G.709 ODUk (k=0) >>> >>> >>> >>> ditto >>> >>> >>> >>> FC-100 mapping into OPU0, see clause 17.7.1 >>> >>> 0x0D >>> >>> >>> >>> 67(TBA) >>> >>> Or58(Suggested by Lou) >>> >>> >>> >>> G.709 ODUk (k=1) >>> >>> >>> >>> ditto >>> >>> >>> >>> FC-200 mapping into OPU1, see clause 17.7.2 >>> >>> 0x0E >>> >>> >>> >>> 68(TBA) >>> >>> Or58(Suggested by Lou) >>> >>> >>> >>> G.709 ODUflex >>> >>> >>> >>> ditto >>> >>> >>> >>> FC-400 mapping into OPUflex, see clause 17.9 >>> >>> 0x0F >>> >>> >>> >>> 69(TBA) >>> >>> Or58(Suggested by Lou) >>> >>> >>> >>> G.709 ODUflex >>> >>> >>> >>> ditto >>> >>> >>> >>> FC-800 mapping into OPUflex, see clause 17.9 >>> >>> 0x10 >>> >>> >>> >>> 51 >>> >>> >>> >>> G.709 ODUk >>> >>> >>> >>> 1)G-PID defined in RFC4328; >>> >>> 2) Updated in this draft. >>> >>> >>> >>> Bit stream with octet timing mapping, see clause 17.6.1 >>> >>> 0x11 >>> >>> >>> >>> 52 >>> >>> >>> >>> G.709 ODUk >>> >>> >>> >>> ditto >>> >>> >>> >>> Bit stream without octet timing mapping, see clause 17.6.2 >>> >>> 0x12 >>> >>> >>> >>> 70(TBA) >>> >>> >>> >>> G.709 ODUflex >>> >>> >>> >>> Is being defined in this draft (new payload type defined in [G.709-2012]) >>> >>> >>> >>> IB SDR mapping into OPUflex, see 17.9 >>> >>> 0x13 >>> >>> >>> >>> 71(TBA) >>> >>> >>> >>> G.709 ODUflex >>> >>> >>> >>> ditto >>> >>> >>> >>> IB DDR mapping into OPUflex, see 17.9 >>> >>> 0x14 >>> >>> >>> >>> 72(TBA) >>> >>> >>> >>> G.709 ODUflex >>> >>> >>> >>> ditto >>> >>> >>> >>> IB QDR mapping into OPUflex, see 17.9 >>> >>> 0x15 >>> >>> >>> >>> 73(TBA) >>> >>> >>> >>> G.709 ODUk (k=0) >>> >>> >>> >>> ditto >>> >>> >>> >>> SDI mapping into OPU0, see 17.7.1 >>> >>> 0x16 >>> >>> >>> >>> 74(TBA) >>> >>> >>> >>> G.709 ODUk (k=1) >>> >>> >>> >>> ditto >>> >>> >>> >>> (1.485/1.001) Gbit/s SDI mapping into OPU1, see 17.7.2 >>> >>> 0x17 >>> >>> >>> >>> 75(TBA) >>> >>> >>> >>> G.709 ODUk (k=1) >>> >>> >>> >>> ditto >>> >>> >>> >>> 1.485 Gbit/s SDI mapping into OPU1, see 17.7.2 >>> >>> 0x18 >>> >>> >>> >>> 76(TBA) >>> >>> >>> >>> G.709 ODUflex >>> >>> >>> >>> ditto >>> >>> >>> >>> (2.970/1.001) Gbit/s SDI mapping into OPUflex, see 17.9 >>> >>> 0x19 >>> >>> >>> >>> 77(TBA) >>> >>> >>> >>> G.709 ODUflex >>> >>> >>> >>> ditto >>> >>> >>> >>> 2.970 Gbit/s SDI mapping into OPUflex, see 17.9 >>> >>> 0x1A >>> >>> >>> >>> 78(TBA) >>> >>> Or56(Suggested by Lou) >>> >>> >>> >>> G.709 ODUk (k=0) >>> >>> >>> >>> ditto >>> >>> >>> >>> SBCON/ESCON mapping into OPU0, see 17.7.1 >>> >>> 0x1B >>> >>> >>> >>> 79(TBA) >>> >>> >>> >>> G.709 ODUk (k=0) >>> >>> >>> >>> ditto >>> >>> >>> >>> DVB_ASI mapping into OPU0, see 17.7.1 >>> >>> 0x20 >>> >>> >>> >>> 47 >>> >>> >>> >>> G.709 ODUk >>> >>> >>> >>> 1) G-PIDs defined in RFC4328. >>> >>> 2) Updated in this draft. >>> >>> >>> >>> ODU multiplex structure supporting ODTUjk only, see clause 19 (AMP only) >>> >>> 0x21 >>> >>> >>> >>> 59/60(TBA) >>> >>> >>> >>> G.709 ODUk >>> >>> >>> >>> 1)Are being defined in this draft (new payload type defined in >>> [G.709-2012]); >>> >>> 2) 59 for G.709 ODU-1.25G; 60 for G.709 ODU-any >>> >>> >>> >>> ODU multiplex structure supporting ODTUk.ts or ODTUk.ts and ODTUjk, see >>> clause 19 (GMP capable) (Note 7) >>> >>> 55 >>> >>> >>> >>> None >>> >>> >>> >>> >>> >>> >>> >>> Not needed >>> >>> >>> >>> Not available (Note 2) >>> >>> 66 >>> >>> >>> >>> None >>> >>> >>> >>> >>> >>> >>> >>> Not needed >>> >>> >>> >>> Not available (Note 2) >>> >>> 80-8F >>> >>> >>> >>> None >>> >>> >>> >>> >>> >>> >>> >>> Not needed >>> >>> >>> >>> Reserved codes for proprietary use (Note 4) >>> >>> FD >>> >>> >>> >>> None >>> >>> OrTBA(Suggested by Lou) >>> >>> >>> >>> >>> >>> >>> >>> Not needed >>> >>> >>> >>> NULL test signal mapping, see clause 17.5.1 >>> >>> FE >>> >>> >>> >>> None >>> >>> OrTBA(Suggested by Lou) >>> >>> >>> >>> >>> >>> >>> >>> Not needed >>> >>> >>> >>> PRBS test signal mapping, see clause 17.5.2 >>> >>> FF >>> >>> >>> >>> None >>> >>> >>> >>> >>> >>> >>> >>> Not needed >>> >>> >>> >>> Not available (Note 2) >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Best Regards >>> >>> >>> >>> Fatai >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf >>> Of Lou Berger >>> Sent: Tuesday, May 21, 2013 9:17 PM >>> To: CCAMP >>> Cc: draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>> Subject: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues) >>> >>> >>> >>> All, >>> >>> >>> >>> In the interest of moving this discussion quickly to closure, I spent >>> >>> some time trying to come up with the full list of G.709 PT to G-PID >>> >>> mappings. In coming up with this list I tried to be consistent with >>> >>> the last consensus point that I can identify on this topic (the >>> >>> previously referenced July 2012 thread & presentation), which included: >>> >>> >>> >>> A) Defining new G-PIDs for client types not identified by an assigned >>> >>> G-PID (per >>> >>> http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parameters.xml) >>> >>> >>> >>> B) Reusing G-PID wherever {G-PID, ODU rate} unambiguously identify a >>> >>> G.709 payload type, and define new G-PIDs when reuse not possible. >>> >>> >>> >>> C) No G-PID value for unused, reserved, or proprietary 709 Payload Type. >>> >>> >>> >>> Here's what I've come up with: >>> >>> >>> >>> G.709 >>> >>> Payload >>> >>> Type G-PID Type/Comment LSP Encoding >>> >>> ==== ===== ============== =================== >>> >>> 0x01 No standard value >>> >>> 0x02 49 CBRa G.709 ODUk >>> >>> 0x03 50 CBRb G.709 ODUk >>> >>> 0x04 32 ATM G.709 ODUk >>> >>> 0x05 TBA1 Framed GFP G.709 ODUk >>> >>> 0x06 ??? Is any valued needed? >>> >>> 0x07 55 Ethernet PHY G.709 ODUk (k=0) >>> >>> (transparent G.709 ODUk (k=3) >>> >>> GFP) G.709 ODUk (k=4) >>> >>> 0x08 58 Fiber Channel G.709 ODUk (k=2e) >>> >>> 0x09 TBA1 Framed GFP G.709 ODUk (k=2e) >>> >>> 0x0A TBA2 STM-1 G.709 ODUk (k=0) >>> >>> 0x0B TBA3 STM-4 G.709 ODUk (k=0) >>> >>> 0x0C 58 Fiber Channel G.709 ODUk (k=0) >>> >>> 0x0D 58 Fiber Channel G.709 ODUk (k=1) >>> >>> 0x0E 58 Fiber Channel G.709 ODUflex >>> >>> 0x0F 58 Fiber Channel G.709 ODUflex >>> >>> 0x10 51 BSOT G.709 ODUk >>> >>> 0x11 52 BSNT G.709 ODUk >>> >>> 0x12 TBA4 InfiniBand G.709 ODUflex >>> >>> 0x13 TBA4 InfiniBand G.709 ODUflex >>> >>> 0x14 TBA4 InfiniBand G.709 ODUflex >>> >>> 0x15 TBA5 Serial Digital G.709 ODUk (k=0) >>> >>> Interface >>> >>> 0x16 TBA6 Serial Digital G.709 ODUk (k=1) >>> >>> Interface/1.001 >>> >>> 0x17 TBA5 Serial Digital G.709 ODUk (k=1) >>> >>> Interface >>> >>> 0x18 TBA6 Serial Digital G.709 ODUflex >>> >>> Interface/1.001 >>> >>> 0x19 TBA5 Serial Digital G.709 ODUflex >>> >>> Interface >>> >>> 0x1A 56 SBCON/ESCON G.709 ODUk (k=0) >>> >>> (IANA to update Type field) >>> >>> 0x1B TBA7 DVB_ASI G.709 ODUk (k=0) >>> >>> 0x1C 58 Fiber Channel G.709 ODUk >>> >>> 0x20 47 G.709 ODU-2.5G G.709 ODUk >>> >>> (k=2,3) >>> >>> (IANA to update Type field) >>> >>> TBA8 G.709 ODU-1.25G G.709 ODUk >>> >>> (k=1,2,3) >>> >>> 0x21 TBA8 G.709 ODU-1.25G G.709 ODUk >>> >>> (k=2,3,4) >>> >>> TBA9 G.709 ODU-Any G.709 ODUk >>> >>> (k=2,3) >>> >>> 0x55 No standard value >>> >>> 0x66 No standard value >>> >>> 0x80-0x8F No standard value >>> >>> 0xFD TBA10 Null Test G.709 ODUk >>> >>> 0xFE TBA11 Random Test G.709 ODUk >>> >>> 0xFF No standard value >>> >>> >>> >>> Note that there are a few differences with Fatai's list, which doesn't >>> >>> format well in e-mail, but is available in the archive >>> >>> http://www.ietf.org/mail-archive/web/ccamp/current/msg14845.html >>> >>> >>> >>> Please speak up if you think the above is not aligned with prior >>> >>> consensus or if you have an issue with any of the above. >>> >>> >>> >>> Much thanks, >>> >>> Lou >>> >>> >>> >>> >>> >>> On 5/20/2013 5:09 AM, Fatai Zhang wrote: >>> >>>> Hi Lou, >>> >>>> >>> >>>> >>> >>>> >>> >>>> I think my mail on March 13rd may have answered your following comments. >>> >>>> My response quoted as follows. >>> >>>> >>> >>>> >>> >>>> >>> >>>> In addition, if people look at the full list that I provided, I think >>> >>>> people can realize that RFC4328 (section 3.1.3) used the same approach >>> >>>> as the current approach of this draft (ie., 1:1 mapping between GPIDs >>> >>>> and payload types defined by G.709), ie., we are following what RFC4328 >>> >>>> did. >>> >>>> >>> >>>> >>> >>>> >>> >>>> BTW, I am not sure if we need spend so much on discussing this point >>> >>>> (because there is no issue to stick to the data plane by using the >>> >>>> current approach of this draft). >>> >>>> >>> >>>> >>> >>>> >>> >>>> ====================================================================================================================== >>> >>>> >>> >>>> (2) 'Grouped GPID' vs '1:1' mapping (between G.709-2012 and GPIDs >>> >>>> defined in this draft) >>> >>>> >>> >>>> >>> >>>> >>> >>>> We realize that it is safe to use 1:1 mapping approach to avoid some >>> >>>> potential issues after investigation. We know this payload types have >>> >>>> been defined by G.709 (data plane), so physically it is better to use >>> >>>> 1:1 mapping approach. >>> >>>> >>> >>>> For the potential issues I mentioned above, for example, we cannot use >>> >>>> the existing 34 to represent 'STM-1' and 'STM-4 ', because it is >>> >>>> impossible to differentiate which one is 'STM-1' or 'STM-4'. In >>> >>>> addition, from the concept of payload type, we know that e.g, FC-100 is >>> >>>> different from FC-800, right? So, it is better to assign different GPIDs >>> >>>> to these different payload types defined by the data plane. >>> >>>> >>> >>>> >>> >>>> >>> >>>> Furthermore, I think it is much cheaper to create new GPIDs in the >>> >>>> control plane than in the data plane (these payload types will be >>> >>>> carried in the OH). >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> Best Regards >>> >>>> >>> >>>> >>> >>>> >>> >>>> Fatai >>> >>>> >>> >>>> >>> >>>> >>> >>>> -----Original Message----- >>> >>>> From: Lou Berger [mailto:lberger@labn.net] >>> >>>> Sent: Friday, May 17, 2013 11:16 PM >>> >>>> To: Fatai Zhang >>> >>>> Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; >>> >>>> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>> >>>> Subject: Re: R: Closing G.709 open issues >>> >>>> >>> >>>> >>> >>>> >>> >>>> Fatai, >>> >>>> >>> >>>> >>> >>>> >>> >>>> That's a great start for the WG. Thank you. >>> >>>> >>> >>>> >>> >>>> >>> >>>> To answer your implied question as to why my request for the full list. >>> >>>> >>> >>>> My feeling is that there have been too many "surprises" on the 709 >>> >>>> >>> >>>> documents in areas that I thought were either obvious (but from the IETF >>> >>>> >>> >>>> & GMPLS context, not ITU-T or G.709 perspectives) or resolved by past >>> >>>> >>> >>>> discussions. At this point, as co-chair and Document shepherd, I want >>> >>>> >>> >>>> to ensure that any open point on the documents are unambiguously closed >>> >>>> >>> >>>> and that past discussions (i.e., points of consensus) are 100% captured, >>> >>>> >>> >>>> so that we can smoothly move through the planned second LC and >>> >>>> >>> >>>> publication request. >>> >>>> >>> >>>> >>> >>>> >>> >>>> To that end, in my previous message I asked two questions about points >>> >>>> >>> >>>> where it seems you are proposing moving away from what has been >>> >>>> >>> >>>> previously been discussed & agreed to by the WG. Can you answer the >>> >>>> >>> >>>> following: >>> >>>> >>> >>>> >>> >>>> >>> >>>>>> My questions on the new G-PIDs come down to: >>> >>>> >>> >>>>>> - Why are rate specific G-PIDs being proposed (rather than >>> >>>> >>> >>>>>> continuing to use the previous approach documented in the draft >>> >>>> >>> >>>>>> and in Section 3.1.3 of rfc4328)? >>> >>>> >>> >>>> >>> >>>> >>> >>>>>> - Why are new values being defined rather than using existing >>> >>>> >>> >>>>>> values, e.g., G-PID 56? >>> >>>> >>> >>>>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> Much thanks, >>> >>>> >>> >>>> Lou >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>> _______________________________________________ >>> >>> CCAMP mailing list >>> >>> CCAMP@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/ccamp >>> >> >> >> >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > > From sergio.belotti@alcatel-lucent.com Tue May 28 08:03:09 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C13F21F97F8 for ; Tue, 28 May 2013 08:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.585 X-Spam-Level: X-Spam-Status: No, score=-7.585 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjOMdERWzncD for ; Tue, 28 May 2013 08:02:57 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id AA17621F97E0 for ; Tue, 28 May 2013 08:02:56 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r4SF2mgE007271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 28 May 2013 10:02:49 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id r4SF2lXk020991 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 May 2013 11:02:47 -0400 Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 28 May 2013 11:02:47 -0400 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.233]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Tue, 28 May 2013 17:02:36 +0200 From: "BELOTTI, SERGIO (SERGIO)" To: Lou Berger Thread-Topic: R: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues) Thread-Index: AQHOWJxlOyTOa4Hi70imTgpK6F7OvJkatmCg Date: Tue, 28 May 2013 15:02:35 +0000 Message-ID: References: <518A82D9.7080508@labn.net> <51924382.2010904@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C90D5@ESESSMB301.ericsson.se> <13ea7ed3bdd.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <5193A26A.1090005@labn.net> <519649B4.5060408@labn.net> <519B73C9.2030308@labn.net> <519E406C.9030008@labn.net> <519F67ED.3040701@labn.net> <519F963C.9060305@labn.net> In-Reply-To: <519F963C.9060305@labn.net> Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/mixed; boundary="_002_B9FEE68CE3A78C41A2B3C67549A96F4802F129FR711WXCHMBA05zeu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" Subject: [CCAMP] R: R: Closing Issue #49 (Was: Re: R: Closing G.709 open issues) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 15:03:09 -0000 --_002_B9FEE68CE3A78C41A2B3C67549A96F4802F129FR711WXCHMBA05zeu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Lou, See below for my notes . I attached the Fatai's doc for GPID mapping with possible suggested addon. Thanks Sergio Belotti Sergio- System Architect ALCATE-LUCENT Optics Division via Trento 30 Vimercate (MB) - Italy phone +39 (039) 6863033 -----Messaggio originale----- Da: Lou Berger [mailto:lberger@labn.net]=20 Inviato: venerd=EC 24 maggio 2013 18.33 A: BELOTTI, SERGIO (SERGIO) Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; Fatai Zh= ang Oggetto: Re: R: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open i= ssues) Sergio, On 5/24/2013 11:54 AM, BELOTTI, SERGIO (SERGIO) wrote: > Hi, >=20 > Please take care anyway this solution does not consider two cases: >=20 > G.7041 and G.709, defines respectively: >=20 > 10GbE --> GFP-F (G.7041, Table 6-3: UPI=3D0x13 [ Frame-mapped 64B/66B en= coded > Ethernet, including the Ethernet frame preamble ]) Cool, yet another way to encode Ethernet over GFP. (Pointing to the G.7041 UPI was very helpful, the draft will need to capture that!) What PT is used for this? Are there other client types missing/that you think are missing? SB> In G.7041 Table 6-3 - User payload identifiers for GFP client frames d= efine the UPI values. UPI is setup according to the transported signal type. Here we can see there is another form of Ethernet mapping via GFP and ODU2= signals can carry diverse payloads including diverse GFP-F mapped Etherne= t. I think the best we can do would be to define GPID values for all possible/= meaningful combinations of PT/UPI values where GFP is used to encapsulate t= he client signal. What I have indicated here are just two possible addon: one is already cons= idered in the file provided by Fatai , the other is the one form G.7041. Attached the doc from Fatai, updated (in yellow) with the new GFP Ethernet = mapping possibility. My suggestion would be to define GPID values for all possible/meaningful co= mbinations of PT/UPI values where GFP is used to encapsulate the client sig= nal. >=20 > 10GbE--> extended OPU2/ODU2 (G.709, Table 15-8: PT=3D0x09 [ GFP mapping i= nto Extended > OPU2 payload, see clause 17.4.1 ]) Is this a different case? If yes, how so? (Do you have a data plane reference?) SB> For ODU2 in OTN there is two possible PT options for 10GbE and are PT=3D 0x05 (ODU2) | PT =3D 0x09 (extended ODU2) Thanks, Lou >=20 > Please not that this is not the mapping using UPI=3D0x01 and PT=3D0x05 >=20 > Best Regards >=20 > Sergio >=20 > Belotti Sergio- System Architect > ALCATE-LUCENT Optics Division > via Trento 30 Vimercate (MB) - Italy > phone +39 (039) 6863033 > -----Messaggio originale----- > Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di L= ou Berger > Inviato: venerd=EC 24 maggio 2013 15.15 > A: Fatai Zhang > Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org > Oggetto: Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open is= sues) >=20 > Fatai, >=20 > Just to be clear, the following covers your correction: >=20 > G.709 > Payload > Type G-PID Type/Comment LSP Encoding > =3D=3D=3D=3D =3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 0x05 TBA1 Framed GFP G.709 ODUk > 54 Ethernet MAC G.709 ODUk > (framed GFP) >=20 > Right? >=20 > Thanks, > Lou >=20 > On 5/23/2013 9:01 PM, Fatai Zhang wrote: >> Hi Lou, >> >> Fine, thanks for your explanation. >> >> As I said, I will update the signaling draft based on your proposal if t= here are no further comments. >> >> >> >> Best Regards >> >> Fatai >> >> >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net]=20 >> Sent: Friday, May 24, 2013 12:15 AM >> To: Fatai Zhang >> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >> Subject: Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open i= ssues) >> >> Fatai, >> Do we really need to reopen debate on a topic the WG discussed and >> closed last summer? (i.e., to handle G.709 client adaptation just as we >> do for every other technology.) >> >> I do agree that some new G-PID assignments were missed in the draft that >> went to LC, but filling in the list doesn't automatically mean that the >> WG needs to reopen debate on adaptation approaches. >> >> Assuming we don't need to reopen the pre-LC debate from last summer, and >> with respect to the list I sent out, I do agree the WG needs to: >> >> A) Ensure that the list doesn't have unneeded new G-PIDs (i.e., reuses >> the same/existing G-PIDs wherever possible.) >> >> B) Identifies the "right" G-PID per payload type, and doesn't have any >> other technical errors >> >> C) Doesn't conflict with past WG decisions/discussions. >> >> >From your mails I see the following comment on (A): >> >>> For 0x05, why you think that RFC4328 does not cover it (ie., G-PID=3D54= )? >> >> G-PID 54, per IANA, is currently defined as "Ethernet MAC (framed GFP)". >> Per G.709, PT=3D0x05 maps to "GFP mapping, see clause 17.4" and looking >> at 17.4 there is no restriction on what is carried in GFP frames. So it >> seems that PT=3D0x05 can't be limited to just "Ethernet MAC (framed GFP)= ". >> >> Are you suggesting changing the type description of G-PID 54 to just >> "Framed GFP", or including G-PID 54 as an additional possibility for >> PT=3D0x05? >> >> The latter seems to be a valid addition/correction. The former may be >> problematic for existing implementations, so we'll need to discuss more >> broadly if that's the direction you want to head. >> >> All/ (WG), >> >> Again, please speak up if you think the above is not aligned with prior >> consensus or if you have an issue with any of the above. >> >> Lou >> >> On 5/22/2013 10:35 PM, Fatai Zhang wrote: >>> Hi Lou, >>> >>> =20 >>> >>> I incorporated your proposal into my table to facilitate the readers. >>> >>> =20 >>> >>> I think you still insist on reusing some existing G-PIDs like 58, 56. >>> For 0x04, why you think that RFC4328 does not cover it (ie., G-PID=3D5= 4)? >>> >>> =20 >>> >>> Technically, I am not convince by your proposal, but I would like to >>> reserve my opinion for your same motivation (ie., to conclude the >>> discussion as soon as possible). >>> >>> =20 >>> >>> Any opinions on Lou's proposal from the WG? I will update the signaling >>> draft based on Lou's proposal if there is no comment on Lou's proposal. >>> >>> =20 >>> >>> Note that all the new G-PID values will be re-ordered with TBA. >>> >>> =20 >>> >>> *G-PIDs vs **Payload types defined in Table 15-8 of G.709* >>> >>> =20 >>> >>> Payload Type in Hex codedefined in G.709 >>> >>> =09 >>> >>> G-PID >>> >>> =09 >>> >>> LSP Encoding >>> >>> =09 >>> >>> Note >>> >>> =09 >>> >>> Interpretationfrom G.709 >>> >>> 0x01 >>> >>> =09 >>> >>> None >>> >>> =09 >>> >>> =20 >>> >>> =09 >>> >>> Not needed >>> >>> =09 >>> >>> Experimental mapping (Note 3) >>> >>> 0x02 >>> >>> =09 >>> >>> 49 >>> >>> =09 >>> >>> G.709 ODUk, G.709 OCh >>> >>> =09 >>> >>> 1)G-PID defined in RFC4328; >>> >>> 2) Updated in this draft. >>> >>> =09 >>> >>> Asynchronous CBR mapping, see clause 17.2 >>> >>> 0x03 >>> >>> =09 >>> >>> 50 >>> >>> =09 >>> >>> G.709 ODUk >>> >>> =09 >>> >>> ditto >>> >>> =09 >>> >>> Bit synchronous CBR mapping, see clause 17.2 >>> >>> 0x04 >>> >>> =09 >>> >>> 32 >>> >>> =09 >>> >>> SDH, G.709 ODUk >>> >>> =09 >>> >>> ditto >>> >>> =09 >>> >>> ATM mapping, see clause 17.3 >>> >>> 0x05 >>> >>> =09 >>> >>> 54 >>> >>> or >>> >>> TBA (Suggested by Lou) >>> >>> =09 >>> >>> G.709 ODUk (and SDH) >>> >>> =20 >>> >>> =09 >>> >>> G-PIDs defined in RFC4328 for framed GFP >>> >>> =20 >>> >>> =09 >>> >>> GFP mapping, see clause 17.4 >>> >>> 0x06 >>> >>> =09 >>> >>> None >>> >>> =09 >>> >>> =20 >>> >>> =09 >>> >>> Not needed and Not defined in RFC4328 >>> >>> =09 >>> >>> Virtual Concatenated signal, see clause 18 (Note 5) >>> >>> 0x07 >>> >>> =09 >>> >>> 61(TBA) >>> >>> Or55(Suggested by Lou) >>> >>> =09 >>> >>> G.709 ODUk (k=3D0,3,4) >>> >>> =09 >>> >>> Is being defined in this draft (new payload type defined in [G.709-2012= ]) >>> >>> =09 >>> >>> PCS codeword transparent Ethernet mapping: >>> >>> * 1000BASE-X into OPU0, see clauses 17.7.1 and 17.7.1.1 >>> >>> * 40GBASE-R into OPU3, see clauses 17.7.4 and 17.7.4.1 >>> >>> * 100GBASE-R into OPU4, see clauses 17.7.5 and 17.7.5.1 >>> >>> 0x08 >>> >>> =09 >>> >>> 62(TBA) >>> >>> Or58(Suggested by Lou) >>> >>> =09 >>> >>> G.709 ODUk (k=3D2e) >>> >>> =09 >>> >>> ditto >>> >>> =09 >>> >>> FC-1200 into OPU2e mapping, see clause 17.8.2 >>> >>> 0x09 >>> >>> =09 >>> >>> 63(TBA) >>> >>> =09 >>> >>> G.709 ODUk (k=3D2) >>> >>> =09 >>> >>> ditto >>> >>> =09 >>> >>> GFP mapping into Extended OPU2 payload, see clause 17.4.1 (Note 6) >>> >>> 0x0A >>> >>> =09 >>> >>> 64(TBA) >>> >>> =09 >>> >>> G.709 ODUk (k=3D0) >>> >>> =09 >>> >>> ditto >>> >>> =09 >>> >>> STM-1 mapping into OPU0, see clause 17.7.1 >>> >>> 0x0B >>> >>> =09 >>> >>> 65(TBA) >>> >>> =09 >>> >>> G.709 ODUk (k=3D0) >>> >>> =09 >>> >>> ditto >>> >>> =09 >>> >>> STM-4 mapping into OPU0, see clause 17.7.1 >>> >>> 0x0C >>> >>> =09 >>> >>> 66(TBA) >>> >>> Or58(Suggested by Lou) >>> >>> =09 >>> >>> G.709 ODUk (k=3D0) >>> >>> =09 >>> >>> ditto >>> >>> =09 >>> >>> FC-100 mapping into OPU0, see clause 17.7.1 >>> >>> 0x0D >>> >>> =09 >>> >>> 67(TBA) >>> >>> Or58(Suggested by Lou) >>> >>> =09 >>> >>> G.709 ODUk (k=3D1) >>> >>> =09 >>> >>> ditto >>> >>> =09 >>> >>> FC-200 mapping into OPU1, see clause 17.7.2 >>> >>> 0x0E >>> >>> =09 >>> >>> 68(TBA) >>> >>> Or58(Suggested by Lou) >>> >>> =09 >>> >>> G.709 ODUflex >>> >>> =09 >>> >>> ditto >>> >>> =09 >>> >>> FC-400 mapping into OPUflex, see clause 17.9 >>> >>> 0x0F >>> >>> =09 >>> >>> 69(TBA) >>> >>> Or58(Suggested by Lou) >>> >>> =09 >>> >>> G.709 ODUflex >>> >>> =09 >>> >>> ditto >>> >>> =09 >>> >>> FC-800 mapping into OPUflex, see clause 17.9 >>> >>> 0x10 >>> >>> =09 >>> >>> 51 >>> >>> =09 >>> >>> G.709 ODUk >>> >>> =09 >>> >>> 1)G-PID defined in RFC4328; >>> >>> 2) Updated in this draft. >>> >>> =09 >>> >>> Bit stream with octet timing mapping, see clause 17.6.1 >>> >>> 0x11 >>> >>> =09 >>> >>> 52 >>> >>> =09 >>> >>> G.709 ODUk >>> >>> =09 >>> >>> ditto >>> >>> =09 >>> >>> Bit stream without octet timing mapping, see clause 17.6.2 >>> >>> 0x12 >>> >>> =09 >>> >>> 70(TBA) >>> >>> =09 >>> >>> G.709 ODUflex >>> >>> =09 >>> >>> Is being defined in this draft (new payload type defined in [G.709-2012= ]) >>> >>> =09 >>> >>> IB SDR mapping into OPUflex, see 17.9 >>> >>> 0x13 >>> >>> =09 >>> >>> 71(TBA) >>> >>> =09 >>> >>> G.709 ODUflex >>> >>> =09 >>> >>> ditto >>> >>> =09 >>> >>> IB DDR mapping into OPUflex, see 17.9 >>> >>> 0x14 >>> >>> =09 >>> >>> 72(TBA) >>> >>> =09 >>> >>> G.709 ODUflex >>> >>> =09 >>> >>> ditto >>> >>> =09 >>> >>> IB QDR mapping into OPUflex, see 17.9 >>> >>> 0x15 >>> >>> =09 >>> >>> 73(TBA) >>> >>> =09 >>> >>> G.709 ODUk (k=3D0) >>> >>> =09 >>> >>> ditto >>> >>> =09 >>> >>> SDI mapping into OPU0, see 17.7.1 >>> >>> 0x16 >>> >>> =09 >>> >>> 74(TBA) >>> >>> =09 >>> >>> G.709 ODUk (k=3D1) >>> >>> =09 >>> >>> ditto >>> >>> =09 >>> >>> (1.485/1.001) Gbit/s SDI mapping into OPU1, see 17.7.2 >>> >>> 0x17 >>> >>> =09 >>> >>> 75(TBA) >>> >>> =09 >>> >>> G.709 ODUk (k=3D1) >>> >>> =09 >>> >>> ditto >>> >>> =09 >>> >>> 1.485 Gbit/s SDI mapping into OPU1, see 17.7.2 >>> >>> 0x18 >>> >>> =09 >>> >>> 76(TBA) >>> >>> =09 >>> >>> G.709 ODUflex >>> >>> =09 >>> >>> ditto >>> >>> =09 >>> >>> (2.970/1.001) Gbit/s SDI mapping into OPUflex, see 17.9 >>> >>> 0x19 >>> >>> =09 >>> >>> 77(TBA) >>> >>> =09 >>> >>> G.709 ODUflex >>> >>> =09 >>> >>> ditto >>> >>> =09 >>> >>> 2.970 Gbit/s SDI mapping into OPUflex, see 17.9 >>> >>> 0x1A >>> >>> =09 >>> >>> 78(TBA) >>> >>> Or56(Suggested by Lou) >>> >>> =09 >>> >>> G.709 ODUk (k=3D0) >>> >>> =09 >>> >>> ditto >>> >>> =09 >>> >>> SBCON/ESCON mapping into OPU0, see 17.7.1 >>> >>> 0x1B >>> >>> =09 >>> >>> 79(TBA) >>> >>> =09 >>> >>> G.709 ODUk (k=3D0) >>> >>> =09 >>> >>> ditto >>> >>> =09 >>> >>> DVB_ASI mapping into OPU0, see 17.7.1 >>> >>> 0x20 >>> >>> =09 >>> >>> 47 >>> >>> =09 >>> >>> G.709 ODUk >>> >>> =09 >>> >>> 1) G-PIDs defined in RFC4328. >>> >>> 2) Updated in this draft. >>> >>> =09 >>> >>> ODU multiplex structure supporting ODTUjk only, see clause 19 (AMP only= ) >>> >>> 0x21 >>> >>> =09 >>> >>> 59/60(TBA) >>> >>> =09 >>> >>> G.709 ODUk >>> >>> =09 >>> >>> 1)Are being defined in this draft (new payload type defined in >>> [G.709-2012]); >>> >>> 2) 59 for G.709 ODU-1.25G; 60 for G.709 ODU-any >>> >>> =09 >>> >>> ODU multiplex structure supporting ODTUk.ts or ODTUk.ts and ODTUjk, see >>> clause 19 (GMP capable) (Note 7) >>> >>> 55 >>> >>> =09 >>> >>> None >>> >>> =09 >>> >>> =20 >>> >>> =09 >>> >>> Not needed >>> >>> =09 >>> >>> Not available (Note 2) >>> >>> 66 >>> >>> =09 >>> >>> None >>> >>> =09 >>> >>> =20 >>> >>> =09 >>> >>> Not needed >>> >>> =09 >>> >>> Not available (Note 2) >>> >>> 80-8F >>> >>> =09 >>> >>> None >>> >>> =09 >>> >>> =20 >>> >>> =09 >>> >>> Not needed >>> >>> =09 >>> >>> Reserved codes for proprietary use (Note 4) >>> >>> FD >>> >>> =09 >>> >>> None >>> >>> OrTBA(Suggested by Lou) >>> >>> =09 >>> >>> =20 >>> >>> =09 >>> >>> Not needed >>> >>> =09 >>> >>> NULL test signal mapping, see clause 17.5.1 >>> >>> FE >>> >>> =09 >>> >>> None >>> >>> OrTBA(Suggested by Lou) >>> >>> =09 >>> >>> =20 >>> >>> =09 >>> >>> Not needed >>> >>> =09 >>> >>> PRBS test signal mapping, see clause 17.5.2 >>> >>> FF >>> >>> =09 >>> >>> None >>> >>> =09 >>> >>> =20 >>> >>> =09 >>> >>> Not needed >>> >>> =09 >>> >>> Not available (Note 2) >>> >>> =20 >>> >>> =09 >>> >>> =20 >>> >>> =09 >>> >>> =20 >>> >>> =09 >>> >>> =20 >>> >>> =09 >>> >>> =20 >>> >>> =20 >>> >>> =20 >>> >>> =20 >>> >>> =20 >>> >>> Best Regards >>> >>> =20 >>> >>> Fatai >>> >>> =20 >>> >>> =20 >>> >>> -----Original Message----- >>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf >>> Of Lou Berger >>> Sent: Tuesday, May 21, 2013 9:17 PM >>> To: CCAMP >>> Cc: draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>> Subject: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issu= es) >>> >>> =20 >>> >>> All, >>> >>> =20 >>> >>> In the interest of moving this discussion quickly to closure, I spent >>> >>> some time trying to come up with the full list of G.709 PT to G-PID >>> >>> mappings. In coming up with this list I tried to be consistent with >>> >>> the last consensus point that I can identify on this topic (the >>> >>> previously referenced July 2012 thread & presentation), which included: >>> >>> =20 >>> >>> A) Defining new G-PIDs for client types not identified by an assigned >>> >>> G-PID (per >>> >>> http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-paramete= rs.xml) >>> >>> =20 >>> >>> B) Reusing G-PID wherever {G-PID, ODU rate} unambiguously identify a >>> >>> G.709 payload type, and define new G-PIDs when reuse not possible. >>> >>> =20 >>> >>> C) No G-PID value for unused, reserved, or proprietary 709 Payload Type= . >>> >>> =20 >>> >>> Here's what I've come up with: >>> >>> =20 >>> >>> G.709 >>> >>> Payload >>> >>> Type G-PID Type/Comment LSP Encoding >>> >>> =3D=3D=3D=3D =3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> 0x01 No standard value >>> >>> 0x02 49 CBRa G.709 ODUk >>> >>> 0x03 50 CBRb G.709 ODUk >>> >>> 0x04 32 ATM G.709 ODUk >>> >>> 0x05 TBA1 Framed GFP G.709 ODUk >>> >>> 0x06 ??? Is any valued needed? >>> >>> 0x07 55 Ethernet PHY G.709 ODUk (k=3D0) >>> >>> (transparent G.709 ODUk (k=3D3) >>> >>> GFP) G.709 ODUk (k=3D4) >>> >>> 0x08 58 Fiber Channel G.709 ODUk (k=3D2e) >>> >>> 0x09 TBA1 Framed GFP G.709 ODUk (k=3D2e) >>> >>> 0x0A TBA2 STM-1 G.709 ODUk (k=3D0) >>> >>> 0x0B TBA3 STM-4 G.709 ODUk (k=3D0) >>> >>> 0x0C 58 Fiber Channel G.709 ODUk (k=3D0) >>> >>> 0x0D 58 Fiber Channel G.709 ODUk (k=3D1) >>> >>> 0x0E 58 Fiber Channel G.709 ODUflex >>> >>> 0x0F 58 Fiber Channel G.709 ODUflex >>> >>> 0x10 51 BSOT G.709 ODUk >>> >>> 0x11 52 BSNT G.709 ODUk >>> >>> 0x12 TBA4 InfiniBand G.709 ODUflex >>> >>> 0x13 TBA4 InfiniBand G.709 ODUflex >>> >>> 0x14 TBA4 InfiniBand G.709 ODUflex >>> >>> 0x15 TBA5 Serial Digital G.709 ODUk (k=3D0) >>> >>> Interface >>> >>> 0x16 TBA6 Serial Digital G.709 ODUk (k=3D1) >>> >>> Interface/1.001 >>> >>> 0x17 TBA5 Serial Digital G.709 ODUk (k=3D1) >>> >>> Interface >>> >>> 0x18 TBA6 Serial Digital G.709 ODUflex >>> >>> Interface/1.001 >>> >>> 0x19 TBA5 Serial Digital G.709 ODUflex >>> >>> Interface >>> >>> 0x1A 56 SBCON/ESCON G.709 ODUk (k=3D0) >>> >>> (IANA to update Type field) >>> >>> 0x1B TBA7 DVB_ASI G.709 ODUk (k=3D0) >>> >>> 0x1C 58 Fiber Channel G.709 ODUk >>> >>> 0x20 47 G.709 ODU-2.5G G.709 ODUk >>> >>> (k=3D2,3) >>> >>> (IANA to update Type field) >>> >>> TBA8 G.709 ODU-1.25G G.709 ODUk >>> >>> (k=3D1,2,3) >>> >>> 0x21 TBA8 G.709 ODU-1.25G G.709 ODUk >>> >>> (k=3D2,3,4) >>> >>> TBA9 G.709 ODU-Any G.709 ODUk >>> >>> (k=3D2,3) >>> >>> 0x55 No standard value >>> >>> 0x66 No standard value >>> >>> 0x80-0x8F No standard value >>> >>> 0xFD TBA10 Null Test G.709 ODUk >>> >>> 0xFE TBA11 Random Test G.709 ODUk >>> >>> 0xFF No standard value >>> >>> =20 >>> >>> Note that there are a few differences with Fatai's list, which doesn't >>> >>> format well in e-mail, but is available in the archive >>> >>> http://www.ietf.org/mail-archive/web/ccamp/current/msg14845.html >>> >>> =20 >>> >>> Please speak up if you think the above is not aligned with prior >>> >>> consensus or if you have an issue with any of the above. >>> >>> =20 >>> >>> Much thanks, >>> >>> Lou >>> >>> =20 >>> >>> =20 >>> >>> On 5/20/2013 5:09 AM, Fatai Zhang wrote: >>> >>>> Hi Lou, >>> >>>> >>> >>>> =20 >>> >>>> >>> >>>> I think my mail on March 13rd may have answered your following comment= s. >>> >>>> My response quoted as follows. >>> >>>> >>> >>>> =20 >>> >>>> >>> >>>> In addition, if people look at the full list that I provided, I think >>> >>>> people can realize that RFC4328 (section 3.1.3) used the same approach >>> >>>> as the current approach of this draft (ie., 1:1 mapping between GPIDs >>> >>>> and payload types defined by G.709), ie., we are following what RFC432= 8 >>> >>>> did. >>> >>>> >>> >>>> =20 >>> >>>> >>> >>>> BTW, I am not sure if we need spend so much on discussing this point >>> >>>> (because there is no issue to stick to the data plane by using the >>> >>>> current approach of this draft). >>> >>>> >>> >>>> =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>>> >>> >>>> (2) 'Grouped GPID' vs '1:1' mapping (between G.709-2012 and GPIDs >>> >>>> defined in this draft) >>> >>>> >>> >>>> =20 >>> >>>> >>> >>>> We realize that it is safe to use 1:1 mapping approach to avoid some >>> >>>> potential issues after investigation. We know this payload types have >>> >>>> been defined by G.709 (data plane), so physically it is better to use >>> >>>> 1:1 mapping approach. >>> >>>> >>> >>>> For the potential issues I mentioned above, for example, we cannot use >>> >>>> the existing 34 to represent 'STM-1' and 'STM-4 ', because it is >>> >>>> impossible to differentiate which one is 'STM-1' or 'STM-4'. In >>> >>>> addition, from the concept of payload type, we know that e.g, FC-100 i= s >>> >>>> different from FC-800, right? So, it is better to assign different GPI= Ds >>> >>>> to these different payload types defined by the data plane. >>> >>>> >>> >>>> =20 >>> >>>> >>> >>>> Furthermore, I think it is much cheaper to create new GPIDs in the >>> >>>> control plane than in the data plane (these payload types will be >>> >>>> carried in the OH). >>> >>>> >>> >>>> =20 >>> >>>> >>> >>>> =20 >>> >>>> >>> >>>> =20 >>> >>>> >>> >>>> =20 >>> >>>> >>> >>>> Best Regards >>> >>>> >>> >>>> =20 >>> >>>> >>> >>>> Fatai >>> >>>> >>> >>>> =20 >>> >>>> >>> >>>> -----Original Message----- >>> >>>> From: Lou Berger [mailto:lberger@labn.net] >>> >>>> Sent: Friday, May 17, 2013 11:16 PM >>> >>>> To: Fatai Zhang >>> >>>> Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; >>> >>>> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>> >>>> Subject: Re: R: Closing G.709 open issues >>> >>>> >>> >>>> =20 >>> >>>> >>> >>>> Fatai, >>> >>>> >>> >>>> =20 >>> >>>> >>> >>>> That's a great start for the WG. Thank you. >>> >>>> >>> >>>> =20 >>> >>>> >>> >>>> To answer your implied question as to why my request for the full list= . >>> >>>> >>> >>>> My feeling is that there have been too many "surprises" on the 709 >>> >>>> >>> >>>> documents in areas that I thought were either obvious (but from the IE= TF >>> >>>> >>> >>>> & GMPLS context, not ITU-T or G.709 perspectives) or resolved by past >>> >>>> >>> >>>> discussions. At this point, as co-chair and Document shepherd, I want >>> >>>> >>> >>>> to ensure that any open point on the documents are unambiguously close= d >>> >>>> >>> >>>> and that past discussions (i.e., points of consensus) are 100% capture= d, >>> >>>> >>> >>>> so that we can smoothly move through the planned second LC and >>> >>>> >>> >>>> publication request. >>> >>>> >>> >>>> =20 >>> >>>> >>> >>>> To that end, in my previous message I asked two questions about points >>> >>>> >>> >>>> where it seems you are proposing moving away from what has been >>> >>>> >>> >>>> previously been discussed & agreed to by the WG. Can you answer the >>> >>>> >>> >>>> following: >>> >>>> >>> >>>> =20 >>> >>>> >>> >>>>>> My questions on the new G-PIDs come down to: >>> >>>> >>> >>>>>> - Why are rate specific G-PIDs being proposed (rather than >>> >>>> >>> >>>>>> continuing to use the previous approach documented in the draft >>> >>>> >>> >>>>>> and in Section 3.1.3 of rfc4328)? >>> >>>> >>> >>>> =20 >>> >>>> >>> >>>>>> - Why are new values being defined rather than using existing >>> >>>> >>> >>>>>> values, e.g., G-PID 56? >>> >>>> >>> >>>>>> >>> >>>> >>> >>>> =20 >>> >>>> >>> >>>> Much thanks, >>> >>>> >>> >>>> Lou >>> >>>> >>> >>>> =20 >>> >>>> >>> >>>> =20 >>> >>>> >>> >>> _______________________________________________ >>> >>> CCAMP mailing list >>> >>> CCAMP@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/ccamp >>> >> >> >> >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp >=20 >=20 >=20 >=20 --_002_B9FEE68CE3A78C41A2B3C67549A96F4802F129FR711WXCHMBA05zeu_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="GPIDs for OTN signaling draft-sb.docx" Content-Description: GPIDs for OTN signaling draft-sb.docx Content-Disposition: attachment; filename="GPIDs for OTN signaling draft-sb.docx"; size=65560; creation-date="Tue, 28 May 2013 14:48:36 GMT"; modification-date="Tue, 28 May 2013 14:48:37 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQDjgPmO3AEAAF4KAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADE Vstu2zAQvAfoPwi8FhadBAiKwLIPfRyTAHE/gCZXNhPxAXKdxH+flWQrgWtLrlWhFwGCsDOzM7uk JrM3UyQvEKJ2NmOX6ZglYKVT2i4z9nv+a/SNJRGFVaJwFjK2gchm0y8Xk/nGQ0yo2saMrRD9LedR rsCImDoPlr7kLhiB9BqW3Av5LJbAr8bjGy6dRbA4whKDTSf3JCBoBcmDCHgnDPHwVxcUz51D6xBi SnAs+V7XldQZE94XWgok4fzFqj3SkctzLUE5uTZElZZwPjgJMVJrpkgb6K8lNJ9OfkAu1gUmP99I W23Hk4flHqs2ZRfVh8M1AYq4V9OhdGtNSpVVN3GlfWxR1W7FtpujljaOtMOc4WiDbIS2O/1Hddi1 WUCgLP59tA10p4iIm2KI4apxO+nBqoGme4fcJoHyegjOR07z2TsEKLdGgRrRknkIqKEZ4aMjEAGR BmCA5d4ht7XfHDAQrnq3f/B4gXAi//X/4G/il+uIzvSWUMP8Tf7lEQzhsjfzueYj3VbAq2d/ERVM Z94rEGqQeauBT+QfYN5O5M/pBp+LRQFDhL6F7jThFRaPgx09n8A7hdSm9Z+9PxagO42P7XfhjDB2 /yySqg+sPK/+DqfvAAAA//8DAFBLAwQUAAYACAAAACEAmVV+BQQBAADhAgAACwAIAl9yZWxzLy5y ZWxzIKIEAiigAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAKySz0rDQBDG74LvsMy9mbSKiDTpRYTeROIDDLvTJJj9w+5U27d3LYgGatKDx535 5pvffOx6c7CDeueYeu8qWBYlKHbam961Fbw2T4t7UEnIGRq84wqOnGBTX1+tX3ggyUOp60NS2cWl CjqR8ICYdMeWUuEDu9zZ+WhJ8jO2GEi/Ucu4Kss7jL89oB55qq2pIG7NDajmGPLmeW+/2/WaH73e W3ZyZgXyQdgZNosQM1uUPl+jGootSwXG6+dcTkghFBkb8DzR6nKiv69Fy0KGhFD7yNM8X4opoOXl QPMRjRU/6Xz4aDBHdMp2iub2P2n0Pom3M/GcNN9IOPqY9ScAAAD//wMAUEsDBBQABgAIAAAAIQCd +s6EYgEAAMMHAAAcAAgBd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVscyCiBAEooAABAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAKyVTW+DMAyG75P2H1DuI9Bu3YcKvUyTet26H5CC+dAgQYm7 rf9+HlUpXVF28QXJRvh9eO04y9V32wSfYF1tdCLiMBIB6MzktS4T8b55uXkQgUOlc9UYDYnYgxOr 9Ppq+QqNQvrIVXXnAqqiXSIqxO5JSpdV0CoXmg40vSmMbRVSaEvZqexDlSBnUbSQdlxDpGc1g3We CLvOSX+z70j5/9qmKOoMnk22a0HjhISsQOVgqaKyJSDV7ONZSJBCTuvHc06AwmjcqG0DJ4Yh5aNg hXCASP11J4Zjxodwz+nDdCNin3484wQojMHxJBziuQ+AVd/hvqGjNEziIfbJx5y/r3ftFiwNwYlg SPkgFpwQoHNNXRi5cMz4EGJWI6YH0TsHd5we/M7dHxOGlNcFWtR8e3H6NHj34i2n/hds3y6W0ijp c+KRE2TaCP9eYnUC6eYcXQ59KPvnACHPrt70BwAA//8DAFBLAwQUAAYACAAAACEAJFrhPloYAABM bAEAEQAAAHdvcmQvZG9jdW1lbnQueG1s7F17b6PKFf+/Ur/DyH8l0iYB/M6tXfmZXWlv1s3jtlJV VdiMNzQYLBjnsZ+mn6WfrGcGsMHGMBBsY2da6XpjwzCcOXPO7zznL399mxnoBduObpmtknwplRA2 J5ammz9bpceH4UWjhByimppqWCZuld6xU/pr+89/+svrtWZNFjNsEgRDmM71C/z6RMj8+urKmTzh mepcWnNswo9Ty56pBP60f17NVPt5Mb+YWLO5SvSxbujk/UqRpFrJG8ZqlRa2ee0NcTHTJ7blWFNC b7m2plN9gr0P/w6b57nunX1vyuyJVzY2YA6W6Tzpc8cfbZZ1NHjFJ3+Ql7iXeJkZ/nWvc56nabb6 CusxM9xpv1q2NretCXYc+Lbv/rgcUZbinu0RkA6xvINnCuFn+jOZqbq5HIZyx9r6LxfvEhbvyn32 FR1q9SJAizbw0tjS3unnHL1eAy9qd62SJA2rUkUalPyvRrDQktRsSo2ysvyyj6fqwiCbl48CF7OR Rzb9+M8EhntRjVZpAqyL7dIV/dZ2fxyzPwzV/AkXYdUhHUdXW6VfTxe9W3rhlXclfM69OyzrmbL0 PVFtAjfpGjyWTs5UZ0CPf9/haaXRlOH/kuQ9Cn5kbxh6nQyTeL1mO+/amasTeNTcxg62X3CpfXMx +tZ3EJ0tcefMRs/2iPaLsz7Qzl9gfepjj8gDU1uS2F02nqn4i0apMVLfDUvVEHmf4/XXykifA5BH w1PdxBrSTfSgjg2M5OpFI5/XoUJ4k6OQNUU3l3WpGXoI3QWUaMl7djisdeV+zJ5lw7g7ytuK/JvQ nwYZG3QY+HAHgn/8HfjjFbSaVG1U6dPpsrdK2pvqbsVoWQD3dUFEgUpkw1n09ZjAoNLWwHQc51er VGH/cPce2/ETy7BAQqkLYrnDG3hKRUKme8cWIdYs6922/vMp86N1E+Qv/pr12e7tf2S7nYqsMPnH xnf13VrQt3FXb6q/Yc0lMFz6HUSD/ygJ/kd/cAdZMsGNrWt0JX/CZ88y4GrKEnLFk8fhr5V6zR07 /HW12oz4Wqk1KxFfl5syG8Sdh/94YsOT41Vbt1Ep95qUr+h1D0zdlXvSoKswHUm8rTFRTXI/B+DE ZCCxv+Lgcjck2Z1TFHfTKXmjkAlj74lHp4m/VyhhYAahrUJv8y5M3uzht7iLV9C1ptID2tKpeBp1 fk/eQaR5+4bJtyeseiv+jPH8O8g+xxX/7tzH/sXeio579GeYM3tT+PRGXi6Aq3m9edJHeySJHuj1 OlkWAX1ctRsSkDCwt5Z36R7pzx1wke29CnshELdsKdyVi14/ysH7W79qtdoYyrtYPx6y721tv9+P 0MAzi0JLTGfAsShUfuxvUXa3qYq0KNFQxUd4D6DqKUAKrVYOG5K0v+I3BAbyBn7MttV5KArSJfpl UQAJbuIzeNvchNtViI58XM/U4/64/pOIoluLhFmPbzEYKFlfDFCyHUP/acL3ayYxDLojjX/kywSE 8QFU+xt1IIDdTZgXKbRDMkuaj8mDqQ1Gw6YkCLEIXVomGPaFSJW6B55PB5ES/EZclE0R6S38xQBp GJ5Gve6Se5IxJV00F+AmosjkwShAvQUHbohJQ2xBN/zRIMp90p+TSgWEePukEofA4+NS6U2SM3Bp EcEGF/09bZJMnB3IA4JMjDWsZaB3JJ6AKR4SNRSc3oO3ObZ1GjFTDTRT53PwJ6IziudQ+Xz7ElCi 7ldfN+qn5kHi4oyi6etKlLudbbHi+H8qklSXqgn+Hy7qH04OMryMfvQfn7+42Bn96D1t34/bgZKA AEk+kGQtB9RtAwRQMtB/zxDgBFg/2qskn7MIctC5dDfsVcpK47ewO40iEiqKco4JnABh28o5epxr KnGjtORJdxBkcUzJZQa+3jPUOgXyd5x3c/JkW6a1cFCve+fDrS/IwRhNDHXhQNS8fhkjZvYPu4Sb ZDMjJ1lhUCGUq5ukKmXYo/J+w26nsEdXsCsLvQXWyg1rlTPQX2CtQGgtWUhRVKvpkNKTgdRC/acm dVcn6BgRgHC8FAIBlGNg4XbrXyCAVSYVn0S8739delzA+5JBNsoCBuQGAyoZ6C9gQGrdJGBAclVF TgHvzsPv2wz/GMwrDP/YkhppKA37lTw8/kWLt1SzSMCDG/4xCSivuma99iyT2CztnaV4eTnSRB27 5Q3qeJn8ZWDVplmqc8tplep+ajtcGX2FDFVNbpxw+yXVRiPpkiaUZrg5zv6cLChHnBrW62hhTty8 GlriRIOlkA+NoZgQaji811ixEC228B4F2Tgsq43VJnqZbauqjF3EmZxfPokUxZ0EHwBauUDQGZRY IgBEUYHgU/KwuzEDKmO9bCOqQP2kAbKsQhC4DjgqUCa4WazAx2EQSqsWH9flp1N2sbu5KB0dSvNK MQNp2l4kDb3q5AmRVws966bmsAK74chBZwPyhG0TE/R7p4fOpjaUkWroZjg6P/XQG59gEM6w1AYH MM82FBwDeAQKLgIKfoLKPkjQXxVzvmMDkBEvxqB7youNBdjmg4NSX/ZxpBJvRskEWGZGQFqwvIlv P8hDAcZMwjm5P5vy7wp4ZwBHp+l03NWK9stKp+FW+HrgLOZJwBfeRaT9OPrWkt7kGE/NyohwhdzS fNizWzJ3+BpDIZ76oMDuylXsR2PcWwz2+jJZLMN+KhimGxnQ1eZhWeDj8aM9BD+KA8JKdSa63io9 QCK3g27xK7qzZip0wQk2jLnXZ/cL9t1TB7opRF49ASfL+iCsiCibwGNyHZsXN93wVGJ619hh0bu5 UY/onb0qeU8OtIfUbrqgOfZgPdUq3atarev2tVordgB5E9giR/vC0TszbDJuVOhsLniM3AlKZt9G /aKbE2NBW4UhsFqR/zViViuCwkh1Bt1ptksEGPNDlQ1Sudar1Zkr2u9qEd8bQznlAPvKFxrR2SrZ hxFQGmG5kNX1dBw2Alc58qqAIYrIPuXo53H2guB7vw0BEuAMlrRf277ViwLVyl1oWNLljl4dzJ0I FrZfnIdoZID+uelFzEDvPYOtVNvL30jxjPaHbpMFVNBBYGsCCfYmS7J3oIuBaoTTuxtecV01KqYC z6IRCPrBEEDGYvjUKkiWKizeFd2JkE3HN2YoMNmMjET1Z4KOZE+0NZ7bxMGP4wUbksGPU92Aroe9 Wr8JDXu8iNsBmzrFyxxgAZcMB1BcNfnsoduJYZqtwiwyGFywxUm1I7dyqe9W3AoVgj4WdPbcCifV x+1w7oWHZWh/KX8JO7HjRibtTIsaFYss2KJydXyK33F8whfiifUMWifSIVMwGqbcGNxsykNY7sEo z39z0BhToysACFYVZujMBKfEPNDoNHjdP5nn80KRZOVfWTZDJHw45oXkWR3oG9u7Zz2/aO9iRGzV hIwUG3KVVzavV89/HbE5ck/fkCv1YafDDWLNxczVpbrxQttfBvOA4LdvS+RQ9ttWenfw0UaGtpvd zv3g4h/Qb41Y6MfoUQoCMYcW2tUvZYZj3X9eRnX4OHEyVaQbRqW7JZXKEVSqrKhU+YxUAmZaJ1Ml gkzVFZmqkWQC1j0IvN+Fh6lg4jUHrHFQdK8IdL8MbsS5s+KR9CqCStG9grOAichA6ulxO58aBWQd 7uFOb0t2J54csuajVq5VFAVjuVSGCB+5hr0LGQ5ZWUIPBW9LCWvssidCam/ZLlpHFmy1j12dloU6 zV+dCm3KUiGywxPQps0IUxykZWzdgdCmlGgQEKFqJRl8fFJvUCCj2tWogzeIQ0EfTer7UHzfW9Bs /d9/wfEBBr0XkarF7G/KonuNSAmTtfRAT1GKd48f1GStCB2bu46VYvbgSkv4sVj/dBwRC6InFLHI NG3T2BE61tWVLp+sZVSG8mOExeptYQotksl1//D7hewbqUu7NRRY8OIK21lw/6p0By38hLnK0ND2 rZUqdlqrClUqVOnyjL08TqeLx4180g5UaXe7HNsKR4S5SokmzNX4UA1VpZWjU6U7SNU/PVXKI13S 6cea0I9CPxZRP/aEfhSmpiTtKDgKsVH/RJ7IJDZha7oHm4s6Aur7Si5KAMjertWFLs1dl8rCbfvx 0Ghf6FKhS3elS2me0boulYPBUFeXxvTY3r/fVhibRQ+BNoQuzVOXTg38lkEJiIzdSij+OchAQ+G0 pUQTTtt4py1k7EL7ug1FSvftui6NSXTbvyYVEdCia9Km0KRCk4LwcXStQOHPodCkwiTdlUnaOLwm LfekQVdxM+e8iJzoVQb9aIrRq6waVZBOwVPsIQUfPvFr0C/LvRpt2MghjVNFPqIbt8Bz3My7ZAc2 vHx0lp4350DXxOTBqDd8VTCaQdJH2p1sfdz3yfkE6hxqsrbSL5QUCv1tw41x6G1MD8RyXqQJuUNy KIoiD5js8nhifk/eDez3klhDvDFNtj/OfgHycQ8G7BfdIPPQJ53X0hCWh6PSkOSYzyhPJQt5CEfa 7MxQQnuWumdzWBMCp3AQfUY77Xj+7HXLu1as3hM7sb3JpAtNb7DNjosaW3CGLRDI7SHjAGkMTNWX 86tVYnqMntTEjmeCL4P95/x+c8uxdiitmkqv6tYo8EirqBrDPPRkRkHVrsYERlaAxFV7y4bnWxrP FWHtBMaheIdDqUdiHLriyz0Dx599jv3HJ7EBPGWB7ZHg6QjpnLsOTAUeci5nOjouz536GwjEWhCU BEJYXXFtXy07xsbIHryx4r+xEZBKxKL2F2srZ1rmEhBIDBlsBwSQRwWHNma7MywI0z3VDh6olO5W HU5z0PDXbHN2b/4jy80ULQVI7v65XAxv4+7fn7QmNQN8kA4ahjkh7b1hXkh7d4gb0t1MlyGonUUT ZnoCPPB3DgdX1qWcw1ShlRKcumz6OTl4u/BUqjTasckHGJcuyHyzXwRnBbDAqclAPs4CUySL2c5j ighRdayiiod1UtlcBWz8LWRfUWVfKq3Kw6rQeL4LJ9TfId8bvuzKsUpKgy5Xe8pGE7aosEXJ+xxi Ddqb6p6HLGRRUWVRDvH0Q4Zk6nkfCCQ4taicmkprCluUenjXwrwfC1LBNg96Z4U/Lpghx4fS8jwz e83BKWzRU7ZFSXuXQT3BO6fNO2Ac9sE4XK/8FbZhIGEqXbAxpAnT3SpsQ2EbttyOLRuZd6fXBe2g tmHex0kJ21DYhpd1qYl+9B9FnNKyV2JM2IbEdXRGpSxz24bh45LpbRnrTYRtGBLVhQp8p3Jj8bGO sA2NzyGMdsA7YBv+TdiG1hoDhfMW0xl4wjb0Eo5X9cMgxoiXTuEXT65XycgVlpMsbMMVqKJUEzms jG949GCqfJ163mcjhlZKOFSP1aGaS9zwmZ67nOchVoK5iup4yCF9gke2ETjRS65m6M4g0lg3w+CF 1qs7gPjCPFxD9yGEfkJ5DDvgnfv+t82kUu+oN8gore+ry4LIKRVxQ2EbCtuwVfr1dNG7pc52UOM7 sg3zPtNXwPeiwvdUGjM/2zDPkzIEcxWVufZpG9aEbaguiOUGYQW+d9VjdJfIQPcrkVa6kSEveIeb d87ky0qjeiVfSpJ8jm7GOrlyoArx20aiqXfEDLMXY2qxqV8Gzh6g//UbVbRKkjSsShVpQMsZNntX eF8+QCqKJEnlWq9Wd/v4CntR2IvCXhT24l7sxbwPrheQvqiQXtiLS5AdbBCXzocuyhA3UM2I4pd9 2ot1YS8KezHUHJ4vDC1iiSKWyLqJZuAdZi4KOxFEPUdtvsg5pZ4A0TdVhYN40sKrU/Vh5QCQDlqP WBN9U4X23NSeucQVRT3i5ygBykEG8iF9SDhtCCNRGIkZgL4wEoWa21RzfGLnTLls1iWOoKLoXiO6 1/hHnnilX8JaFNYiSxLIy51+UGuxLqxFoUY31aiwFjm8p8JjpuUlA/lgG1iLMd3laSE7S+yarJX9 i/JEUZ4orEWh5jbVHJ/YYcZiXEjxEFbiAa2RQnW6ysFVeVAA3sgZgBdqcQ6UyZZnV4xC0TMHZucT eYC0Ovn55QtFw1Q8yUetnMHFiZMLvc2Ma8c9FnhuYwfbL7jUvu/2ftxeDe7hvxulHaFWAGg7X8Jq 5VbbwaVfy9BPDCpZtlrL2fqRFWr9uUTOE1Y1lxDPGM9v8RsBi4PBLY8+HjXHa18bqvkTvsKqQzqO rn4sjz794MAu7XrzlBVwo1GtDPusWsmr05vfk3cD++sQirttZWOOEr/l0aq5t6X6LLsBhBfbJTwq J3I7+QNQrgb93d0uJ9N6Sgq1BFz6O1EgrVoo0xIDr6LX9RuF5YhP1VyW5dMDhWKuSzQi6f/R/Xfn frPQtLBoRGnUc0cjwPbE86fOQWmw4ljOetm7Pp6qC4NsXs68xgOopZWq3KrJE3m5IobkwagsrWQp Y5GVeo2GEELlobsjZrlT7g6lBGLmt/ler5NJl1lg8gwOhI3etAEckkH/ydVqc4+rVu9JtdogYdUI oOnt2/qQvivpTZEyEDkyHLO7rTEc1OVmg5vIB5Mz0fxMex5cjL71HaThqW5iDQ5dRnfDXqWsNC6j TGE4zyFfOX0s9Gsr5+hxrqnEpRF50oFmtjollxl4tNyU9ym+j4bGcCYNmoFO1+cGfkMOsRcTsrAx chbzuWUTHcz5H/2Hx/88I8s03r8gB2M0MdSFg5HcRGed30fsh/PtS0IFgZ1Tfw5vL8dnbFVrte3i lc3GDydHBpfl6J7yhTKZepXqoF5JEIGnhQ7a1eZVLYt2igRuBTsy7TOu5wrYbZcdIDqiM0AicV3B FnVQLjebw49u0kjPEA+izgzX4UbvodTtFFoc+MXHIiPWPCnQFSzzRGGR24oceg6de+ZDrISkhjU6 pAdePu8AghhjCh4CIHcF4NCZiV/RXH03LFVD1KIOXvdPJhkuFElW/nX+WwRf5I6Iwade7yWp05XZ 5nF6rhZz8mBsm5yjahNNLRstpeeFfKlUb35DNWnte9V8j6AdxT+eSI1EP5E4uWCC9TNqS06c/nxJ HATsQTE7+7dqah6A38DuN4DdJ+pcHRv4HJ3dWgSj+g5xfLknDboKU4d+FDUexyv1Zu44nrG/C/9z tqq5wqorGbIKV6zOu1rq3WRhQBWk+xqJCjl5MCpZbi0TZxAXkeB6d0TmChXFE9mnHP1MhhiROHN3 75cDE/nvFwfVSLua26kwuyNGqsXmeW1uve1uCIJMjDWsZdgWkVr0iChF5QFB6ouqG1Q9eNpBKZR2 OKrYWA4bW2gHLSEAmUpgxOfGUHHyebVDLbe+8Eck84R2oGibR48eg3b4bLYDz7ql5HBhEFBfiR8r +js41V5bpVM1CBrSRWOYAenuOfafSsXvYE98apvgzk3t19DE0rDD3I1z25rbOiaq/Y5oTNh1I1WE obD10IkEDJuDobADtheq4BOpgmFf6IHt9SvCN9S+ffz+HRHsEOToP03V8Mu7whGG+mV1l8e8inCC gfk83XGeYGESRAVifA1KPz+vF2g4EHpA6IGt+T6kPbrr3vPpgR0e35ZeDzTzTw8FQeF7CooXVval mdADWStlY/TA/wUAAAD//9RW32/aMBD+V5CftoepcX5BUIO0srLtYVUElfZs4gMyuUnkHFD61+9s h4oJmqJpq8oLOOfz+e7z3Xe3HWL+s7cdblPGoyhhtMRdDSmTj4Jdja6vjEKmR9fbYU17uinkNGWe N4m80Ls16laUaSO8GYTB2Nqwwi+wEGuFx+qZEcWJP6YLreX2ghnuFJDJjVApuxdzBQiPaNzYDn/l +40cSgTdOle7o/qkI+YcjiYTG4WNhQKhiOo2Lrufu19n5xkMP07CNwQjiqLBhJ8JhongtbC1U1Ci XBI0IBr83BQiZU+rT+O7FrtWB0d3FfZKAAnyL5AKEh5fMlIufLERhTIZ1/tAaEDP//gyFKYmbEXg c9od5/j0VEnc2zIJxt7tjW8fG9s3yEWJs1oVaHMd9TcolivcZ7yfxJ1FsLeCp3OZ89B7wxf6B4VN rHJu/u6L4byy5n7/3SZrN8edGd/Fcvh58b1nWv5vSXsJDPvH89GHIUjzN1emvXaNDsdTguXABnLM Ovh1RvuGdb0gHsd9S6YrEBL0FBagoczNIOFGGdhAyXp6WMiU6e+y77j0JW3pppaDAwN3YFFRY3jd fNKtfWyee90OLQrd4IE7nHffcKTvO/16OXsiTMykxxPP0uCK1vEgaAOslz+EQRyrmuQB903T0KYR 0efAsz1kXiFWD/Qdup6iYHGw6zBNWb9vp0CHWMqSxJparpEApEdz/uSVauiCphY5zZuhHzmxrPKv upDGDzuIqqKExnhiFlmBOTltfHPDqUsTm2vzSu7sgiysH2hIHP0GAAD//wMAUEsDBBQABgAIAAAA IQDtCYYJVgEAAAMDAAAQAAAAd29yZC9oZWFkZXIzLnhtbJxSSW7DMAy8F+gfDN0TKV2CwoiTSxr0 0EPR5QGqJcdCtYGS7eb3pbykyyEIehEhjmaGFLnafBqdtRKCcrYgizkjmbSlE8ruC/L2upvdkSxE bgXXzsqCHGQgm/XlxarLawEZsm3IWwTqGH1OaShraXiYOy8tgpUDwyNeYU8Nh4/Gz0pnPI/qXWkV D/SKsSUZZVxBGrD5KDEzqgQXXBUTJXdVpUo5hokB5/gOzK0rGyNt7B0pSI01OBtq5cOkZv6rhi3W k0h7qonW6Old589xE8A7HIXRQ9mdA+HBlTIEzG4H8Ki4YKe8xw9MEkfGOSX89pwqMVzZo0xajD/z Pw5vjsOjgzdNUt+N4F+scY181uW4fuK5IIztbtkNuydTaisr3uj4A+kZT9CHl3jQEp+2XBfkQXIh gdCEKCswXSkI8VGl4q6XLCEU3RI3xf7EFV5/AQAA//8DAFBLAwQUAAYACAAAACEAmqLL/2sDAACz CgAAEAAAAHdvcmQvZm9vdGVyMi54bWzUVstu00AU3SPxD5YXLFBTO+nbNCl9JBVSA1EfYtONa4+b obbHzExiwq5CIFhQVuzooiAhgYoqFkgIFv2ZNhV/wZ3x2ImrtAoUJMjGnvHcc+8951w7s3OPAl9r I8owCct6cdTUNRQ6xMXhdlnfWK8VpnWNcTt0bZ+EqKx3ENPnKtevzcaWx6kG0SGz2vCgyXlkGQZz miiw2SiJUAgPPUIDm8OSbhuBTXdaUcEhQWRzvIV9zDtGyTQndQVDynqLhpaCKATYoYQRj4sQi3ge dpC6pBF0mLxJ5BJxWgEKucxoUORDDSRkTRyxFC34XTRosZmCtC9roh346bk4GiabS+0YpAj8pOyY UDeixEGMwe5S8jBDLJqX5VYECogsYpgS8jnTSgIbhxmMMMY5/TPxRkE8I8ltCKheI8BFBWzEt3x1 aVB1c1+LrbisT5gm2BFOdCJIEDlcN9SBBQACz8oVieBI2/bLuuDERyKCPS7r4/Imsh2IlTAO8QkY xm5xIoAMmbofactfIWQnRTOLVbN3LqttmWJX5N2G6yLx4TRUWpqeKSXF5bdnSsVB25Om3E4qSAFh mmIL5tBdhXrN2oQ5blZFC3KrAYWb5sL0+NjiTMKaI5t3VF2Ooqw4NTmQMqe/z6sw1gMS1av0QoGL Kl9Cnt3yeV9PovAoqTta4x0fQbTUr0YIRzQhDIcubHuYMr6Chb/GoLFENRXr+e4aDiIZjkPGgSFt /U69qm3e1m48bBF+qwO/Qr3gJitN8iYtRpPsIWlQQrwEVe3xSsksjhUmCqVp6RDpEwiCbrOEchUl DlIyXCBGUZrwvH97HAKF/74Y0LqivJ88WiMhZ6BRE4egLrIZn2fYVhplbJ6+3Dv5+u3keP/06NnJ 8UF39yhHK/hGUlcZGbStUIZM1X3z8ez7q+7e8+7+k7P3u91Pb7svPnRfv8shi2aGUG6iNCVm7z9X LrYuGqPYeuCkY0fxdlO+Wq8k9NnhYY7ovnmBRGpAG/PLVV0I3u+kC8Ywh5Yfv3z8kPb4cfAlB5la T/z5sFjynYgoYoi2kV4Z0QYd/jVDnj79fA4ke4X0KNHubtQFLWuatnlTm6f2Fnbkbb26ulyt3Vut z68P++oay6X7C5zlpgcWHHQUl+QT/sc/AyKdeFVnaeEvZ+UnAAAA//8DAFBLAwQUAAYACAAAACEA x5ZKp1QBAAADAwAAEAAAAHdvcmQvZm9vdGVyMS54bWycUsluwyAQvVfqP1jcE0g3VVacXNKceqi6 fAC1IUYFBgG2m7/v4K3LIYp6YcQ83nszzKy3n0ZnrfBBgS3IaslIJmwJlbKHgry97hf3JAuR24pr sKIgRxHIdnN5se5yGX2GbBvyFoE6RpdTGspaGB6W4IRFUII3POLVH6jh/qNxixKM41G9K63ikV4x dkdGGShI420+SiyMKj0EkDFRcpBSlWIME8Of4zswd1A2RtjYO1IvNNYANtTKhUnN/FcNW6wnkfZU E63R07vOneNWed7hKIweyu7AV85DKULA7G4AZ8UVO+U9fmCSmBnnlPDbc6rEcGVnmbQYf+Y/D2+J w6ODN01S343gX2xwjVzW5bh+1XNBGNvfshv2QKbUTkje6PgD6RlPvg8v8agFPm25LsgeIApPaEKU rTAtlQ/xUaXiru9YQii6JW6K/YkrvPkCAAD//wMAUEsDBBQABgAIAAAAIQBYYLMbugAAACIBAAAb AAAAd29yZC9fcmVscy9oZWFkZXIyLnhtbC5yZWxzhI/LCsIwEEX3gv8QZm/TuhCRpm5EcCv1A4Zk mkabB0kU+/cG3CgILude7jlMu3/aiT0oJuOdgKaqgZGTXhmnBVz642oLLGV0CifvSMBMCfbdctGe acJcRmk0IbFCcUnAmHPYcZ7kSBZT5QO50gw+WszljJoHlDfUxNd1veHxkwHdF5OdlIB4Ug2wfg7F /J/th8FIOnh5t+TyDwU3trgLEKOmLMCSMvgOm+oaSAPvWv71WfcCAAD//wMAUEsDBBQABgAIAAAA IQBrWacKEwUAAOURAAAQAAAAd29yZC9oZWFkZXIyLnhtbOxYu3LjNhTtM5N/4DBtbFGyZcuM5ZUf 8WNmd+Kxd+PSA5OgiBgEGAB6eD8gOykykypNqkyKLZM6Rf5m49/IvQAokWtbq6w9aZKGj0vg3HPf kLafTQsejKnSTIp+2F6NwoCKRKZMDPvhq5eHK70w0IaIlHApaD+8oTp8tvPpJ9uTOE9VALuFjsfw ITemjFstneS0IHpVllTAx0yqghh4VcNWQdT1qFxJZFESw64YZ+am1YmijdDDyH44UiL2ECsFS5TU MjO4JZZZxhLqb9UOtYxet/NAJqOCCmM1thTlwEEKnbNSV2jFx6KBiXkFMl5kxLjg1bpJuYy2VJEJ hKLgjvZEqrRUMqFag/TAfZwhtqNFur0DEWK2YxkKTZ0Vk4IwMYPBxHgv/rPgrULwWk53C6HmhoAv diCNzBX3t1PlHy6CSTzph90ognSEFTclKCgTE7b8gj0AgpzFtytpjCxg1Zjwfohu4RQ36df9cN0+ lCSB7RYpkVxCzpCRkYjVstprYMBln3L+glgmnGbGM9mc80inxPFQbJg//N1h19AA+7mU1xVTsC2a c5iZfqRYimYN4b4vuVPfW+84lQ1pt7e1fo+4vdGzYkegwjMKoKDK0zNwRXTYjdajL9EmKzoFn0TR Xm99bX/LxUQ5QgkR5ryEQnWOV8fU25yfjTg4lU4JRKUyabNnaaJiv98kNmCJNy+ZB3buz3lck1ok HhvWORbS8QTKyuB7fHBAMzLipvYFqZeOeXlubjit7CTe7d5IdSiF0fCR6ISxfnggzahA+yjRZlcz UhPlu0LPlrgMtChA0qtSFccqKN3O/oENyhOom8RCniopMxtPTsSwsomZlZOXTdJOVCMJHFlidrbH sc5JSbEsA5b2w8spJvOl2eyGQSKhNDV7DcnRaW9E0ef2GgYy1iU4F5fIuFQ0o8r1YJwdkEIwEvJ+ WAzWB10Ol3Z7sOUu3SmUc8Y4p6Apw2Gk5LV7tkzsa/CNZEJjjACDGaqwLsYxTp8RJ9An4Dmg38KE Y1nAmaDYOkVQsinlz+H1gqUmD2w9zlbqUREMoqB9jzgKomDQ9jocLnTlNBh0YLmtgRmKk68F1g1O oVV2z+bGIldpjVWeEFBqiJ2GjQc0by7WbDF7fk3Tfofb2P8QqXZUR2g1HY+RhZjTqVEjPGXIaxvH oSIpg3lsUwllkAQyTqQQNDGu4yt4QlNlzGVyHYwRA3pOymAp0SV8VTjEcStmaS0tZzlq8/Pdz3/e fv8G3GazsJaxrB114PThtH1WT2OCneD44vL0q/PLs6O9y6+pMiwhML19lk0wY+K19mq3NF/kti1W b2Om/ekmto8wj5APK8iQpsSQQMXIQZ2klpFhBtO2boKdTK7WoDHALML2YNtR1RxqbaoSLWxgT9A7 kAl2w6pVOU5wrZr8va1+DYb4v9fr4RSwy9lQVF3NTRHr2iefAseUwBkEsScxEymozJjSBttJP1zb sMXkXQa3p50RqPOxIQXCORNYUH5MeTd5XLPz109v7AnJhhwCDyr/md4X58Grk+BImpwlmAN++N0R L2bxy6+PYzEbx43Z+0Hr3/34w+P03jHTjf474oXW3779vcFiuaJr49kSLHz/4Dw/FD3+3FzH+r/o lj3yfTDt/uNF99t3jXRfsuV8VGO5/eNtQ1ejtHCsuVnnf54+0U+H+tBY1MD3czj13vkF4aX1RoYi PPz4eYBGVEPaSuFPmp2/AQAA//8DAFBLAwQUAAYACAAAACEA7QmGCVYBAAADAwAAEAAAAHdvcmQv aGVhZGVyMS54bWycUkluwzAMvBfoHwzdEyldgsKIk0sa9NBD0eUBqiXHQrWBku3m96W8pMshCHoR IY5mhhS52nwanbUSgnK2IIs5I5m0pRPK7gvy9rqb3ZEsRG4F187KghxkIJv15cWqy2sBGbJtyFsE 6hh9Tmkoa2l4mDsvLYKVA8MjXmFPDYePxs9KZzyP6l1pFQ/0irElGWVcQRqw+SgxM6oEF1wVEyV3 VaVKOYaJAef4DsytKxsjbewdKUiNNTgbauXDpGb+q4Yt1pNIe6qJ1ujpXefPcRPAOxyF0UPZnQPh wZUyBMxuB/CouGCnvMcPTBJHxjkl/PacKjFc2aNMWow/8z8Ob47Do4M3TVLfjeBfrHGNfNbluH7i uSCM7W7ZDbsnU2orK97o+APpGU/Qh5d40BKftlwX5EFyIYHQhCgrMF0pCPFRpeKulywhFN0SN8X+ xBVefwEAAP//AwBQSwMEFAAGAAgAAAAhAEXIZBRpAQAAswMAABEAAAB3b3JkL2VuZG5vdGVzLnht bKST227DIAyG7yftHSLuU+i0TVPUpDddH2CHB2CENGgBIyDJ+vZzjt2qqoq2GxJs/Pk3Npvtl66i RjqvwKRkvWIkkkZArswhJe9v+/iJRD5wk/MKjEzJUXqyzW5vNm0iTW4gSB8hwvikQW8Zgk0o9aKU mvsVWGnQWYDTPODWHajm7rO2sQBteVAfqlLhSO8YeyQjBlJSO5OMiFgr4cBDEbqQBIpCCTl+pgi3 JO8QuQNRa2lCn5E6WaEGML5U1k80/VcallhOkOZaEY2upnOtXZItd7zFfuhqkN2Cy60DIb1H625w zsQ1u5Z7vMAOMUcskfA756REc2VmTDcdZ/2fm7fC5tEhN+1Qp0LwLrLTLEVtEo4WQV5a7ngAR9Ck 8pTE6/6cxS3Oav6SEsb2D+yePXcnetNOFryuwg9PR3bdMuNotqG9DVfb/49TfEmEABOUqfsZeT0X xP6j5yL5ijZUO7227BsAAP//AwBQSwMEFAAGAAgAAAAhAOfIf8lpAQAAuQMAABIAAAB3b3JkL2Zv b3Rub3Rlcy54bWykkktOwzAQhvdI3CHyPrWLAKGoSTelB+BxAOM4jUXssWwnobdn8qRUVRXBxonn 8c0/ntlsv3QVNdJ5BSYl6xUjkTQCcmUOKXl/28dPJPKBm5xXYGRKjtKTbXZ7s2mTAiAYCNJHyDA+ adBdhmATSr0opeZ+BVYadBbgNA94dQequfusbSxAWx7Uh6pUONI7xh7JiIGU1M4kIyLWSjjwUIQu JYGiUEKOnynDLak7ZO5A1Fqa0FekTlaoAYwvlfUTTf+Vhi2WE6S51kSjqymutUuq5Y63OBBdDbJb cLl1IKT3aN0Nzpm4Ztdqjw/YIeaMJRJ+15yUaK7MjOnW42z+8/BWODw61KYd6qcRfIvsZJmiNglH iyQvLXc8gCNoUnlK4nUfaPGK25q/pISx/QO7Z89dRG/ayYLXVTjxdGjXHTOOZhva2/C0/f+0xxdl CDBBmbpfk9dzSew/ii6Sr6lDwZNUn30DAAD//wMAUEsDBBQABgAIAAAAIQDHlkqnVAEAAAMDAAAQ AAAAd29yZC9mb290ZXIzLnhtbJxSyW7DIBC9V+o/WNwTSDdVVpxc0px6qLp8ALUhRgUGAbabv+/g rcshinphxDzeezPMrLefRmet8EGBLchqyUgmbAmVsoeCvL3uF/ckC5HbimuwoiBHEch2c3mx7nIZ fYZsG/IWgTpGl1MayloYHpbghEVQgjc84tUfqOH+o3GLEozjUb0rreKRXjF2R0YZKEjjbT5KLIwq PQSQMVFykFKVYgwTw5/jOzB3UDZG2Ng7Ui801gA21MqFSc38Vw1brCeR9lQTrdHTu86d41Z53uEo jB7K7sBXzkMpQsDsbgBnxRU75T1+YJKYGeeU8NtzqsRwZWeZtBh/5j8Pb4nDo4M3TVLfjeBfbHCN XNbluH7Vc0EY29+yG/ZAptROSN7o+APpGU++Dy/xqAU+bbkuyB4gCk9oQpStMC2VD/FRpeKu71hC KLolbor9iSu8+QIAAP//AwBQSwMEFAAGAAgAAAAhAJa1reKWBgAAUBsAABUAAAB3b3JkL3RoZW1l L3RoZW1lMS54bWzsWU9v2zYUvw/YdyB0b2MndhoHdYrYsZstTRvEboceaYmW2FCiQNJJfRva44AB w7phhxXYbYdhW4EW2KX7NNk6bB3Qr7BHUpLFWF6SNtiKrT4kEvnj+/8eH6mr1+7HDB0SISlP2l79 cs1DJPF5QJOw7d0e9i+teUgqnASY8YS0vSmR3rWN99+7itdVRGKCYH0i13Hbi5RK15eWpA/DWF7m KUlgbsxFjBW8inApEPgI6MZsablWW12KMU08lOAYyN4aj6lP0FCT9DZy4j0Gr4mSesBnYqBJE2eF wQYHdY2QU9llAh1i1vaAT8CPhuS+8hDDUsFE26uZn7e0cXUJr2eLmFqwtrSub37ZumxBcLBseIpw VDCt9xutK1sFfQNgah7X6/W6vXpBzwCw74OmVpYyzUZ/rd7JaZZA9nGedrfWrDVcfIn+ypzMrU6n 02xlsliiBmQfG3P4tdpqY3PZwRuQxTfn8I3OZre76uANyOJX5/D9K63Vhos3oIjR5GAOrR3a72fU C8iYs+1K+BrA12oZfIaCaCiiS7MY80QtirUY3+OiDwANZFjRBKlpSsbYhyju4ngkKNYM8DrBpRk7 5Mu5Ic0LSV/QVLW9D1MMGTGj9+r596+eP0XHD54dP/jp+OHD4wc/WkLOqm2chOVVL7/97M/HH6M/ nn7z8tEX1XhZxv/6wye//Px5NRDSZybOiy+f/PbsyYuvPv39u0cV8E2BR2X4kMZEopvkCO3zGBQz VnElJyNxvhXDCNPyis0klDjBmksF/Z6KHPTNKWaZdxw5OsS14B0B5aMKeH1yzxF4EImJohWcd6LY Ae5yzjpcVFphR/MqmXk4ScJq5mJSxu1jfFjFu4sTx7+9SQp1Mw9LR/FuRBwx9xhOFA5JQhTSc/yA kArt7lLq2HWX+oJLPlboLkUdTCtNMqQjJ5pmi7ZpDH6ZVukM/nZss3sHdTir0nqLHLpIyArMKoQf EuaY8TqeKBxXkRzimJUNfgOrqErIwVT4ZVxPKvB0SBhHvYBIWbXmlgB9S07fwVCxKt2+y6axixSK HlTRvIE5LyO3+EE3wnFahR3QJCpjP5AHEKIY7XFVBd/lbobod/ADTha6+w4ljrtPrwa3aeiINAsQ PTMR2pdQqp0KHNPk78oxo1CPbQxcXDmGAvji68cVkfW2FuJN2JOqMmH7RPldhDtZdLtcBPTtr7lb eJLsEQjz+Y3nXcl9V3K9/3zJXZTPZy20s9oKZVf3DbYpNi1yvLBDHlPGBmrKyA1pmmQJ+0TQh0G9 zpwOSXFiSiN4zOq6gwsFNmuQ4OojqqJBhFNosOueJhLKjHQoUcolHOzMcCVtjYcmXdljYVMfGGw9 kFjt8sAOr+jh/FxQkDG7TWgOnzmjFU3grMxWrmREQe3XYVbXQp2ZW92IZkqdw61QGXw4rxoMFtaE BgRB2wJWXoXzuWYNBxPMSKDtbvfe3C3GCxfpIhnhgGQ+0nrP+6hunJTHirkJgNip8JE+5J1itRK3 lib7BtzO4qQyu8YCdrn33sRLeQTPvKTz9kQ6sqScnCxBR22v1VxuesjHadsbw5kWHuMUvC51z4dZ CBdDvhI27E9NZpPlM2+2csXcJKjDNYW1+5zCTh1IhVRbWEY2NMxUFgIs0Zys/MtNMOtFKWAj/TWk WFmDYPjXpAA7uq4l4zHxVdnZpRFtO/ualVI+UUQMouAIjdhE7GNwvw5V0CegEq4mTEXQL3CPpq1t ptzinCVd+fbK4Ow4ZmmEs3KrUzTPZAs3eVzIYN5K4oFulbIb5c6vikn5C1KlHMb/M1X0fgI3BSuB 9oAP17gCI52vbY8LFXGoQmlE/b6AxsHUDogWuIuFaQgquEw2/wU51P9tzlkaJq3hwKf2aYgEhf1I RYKQPShLJvpOIVbP9i5LkmWETESVxJWpFXtEDgkb6hq4qvd2D0UQ6qaaZGXA4E7Gn/ueZdAo1E1O Od+cGlLsvTYH/unOxyYzKOXWYdPQ5PYvRKzYVe16szzfe8uK6IlZm9XIswKYlbaCVpb2rynCObda W7HmNF5u5sKBF+c1hsGiIUrhvgfpP7D/UeEz+2VCb6hDvg+1FcGHBk0Mwgai+pJtPJAukHZwBI2T HbTBpElZ02atk7ZavllfcKdb8D1hbC3ZWfx9TmMXzZnLzsnFizR2ZmHH1nZsoanBsydTFIbG+UHG OMZ80ip/deKje+DoLbjfnzAlTTDBNyWBofUcmDyA5LcczdKNvwAAAP//AwBQSwMECgAAAAAAAAAh AMcZ/uonjQAAJ40AABYAAAB3b3JkL21lZGlhL2ltYWdlMS5qcGVn/9j/4AAQSkZJRgABAgEBLAEs AAD/4RpKRXhpZgAATU0AKgAAAAgABwESAAMAAAABAAEAAAEaAAUAAAABAAAAYgEbAAUAAAABAAAA agEoAAMAAAABAAIAAAExAAIAAAAUAAAAcgEyAAIAAAAUAAAAhodpAAQAAAABAAAAnAAAAMgAAAEs AAAAAQAAASwAAAABQWRvYmUgUGhvdG9zaG9wIDcuMAAyMDA2OjA0OjI4IDEzOjUxOjAxAAAAAAOg AQADAAAAAf//AACgAgAEAAAAAQAAASygAwAEAAAAAQAAASwAAAAAAAAABgEDAAMAAAABAAYAAAEa AAUAAAABAAABFgEbAAUAAAABAAABHgEoAAMAAAABAAIAAAIBAAQAAAABAAABJgICAAQAAAABAAAZ HAAAAAAAAABIAAAAAQAAAEgAAAAB/9j/4AAQSkZJRgABAgEASABIAAD/7QAMQWRvYmVfQ00AAv/u AA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwMDAwMEQwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwMDAwMEREM DAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIAIAAgAMBIgACEQEDEQH/3QAE AAj/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgME BQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFiMzRy gtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1 VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMF MoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePz RpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/APVUkkkl KSSSSUxssrqrdba4MrYC573GAGgS5znH6LWrges/4wcq699HR4px2naMl7ZsfH59bH+ypn/GM9T/ AIv6Ctf4yeruqop6RUYN/wCmv/qNMUs/tWtc/wD6yuDo5VLmeYkJcEDVfMXpvgnwjFLCOa5iInx3 7WOXyCI/TlH9LidgZ/Usixtt2XdZYxwfWX2OcGuB3tc2ufT9rh+4vT+k546j06jMA2m1vvb2D2nZ a0f1bGuXleP2Xd/UnJ34V+IeaLN7f6tgn/z4y1N5SZ9wgn5h+IV8dwROATjER9qXQcP6ufpl/wA/ gd/KyGY2PZe/6NbSY8T2b/acuWpflb3Wi17LLHF79jiAXE7ne36K2vrDcGYjKe91gEeTf0h/6TWr Ko2907mpnjEQflH/ADi5fJQ4cMpkXxn/AJsW7jdYyqXBuV+lq4LgIeP5Xt9r1tV2MtrbZW4OY8S1 w4IK5y7bGitdBynC2zDOrINtflqBY3+1u3/56PL5pcQhI2DsT3W8xy8TA5IR4THWQGxi7aSSSuOe pJJJJT//0PVUPIyKcWizIvcGU0tL7Hns1olx0RFwn+MnrL2+j0el8NePWygO4n9BW7+011mz/iUz LkGOBl9nm2uQ5SXN8xDCDQkbnL93HH5i18b/ABg3n6wG64FvSrYqFR5Yyfbknbu/S/nWt/63+ZWv QWPZYxtlbg9jwHNc0yCDq1zXBeErvP8AF99Y+OiZbhpJw3H/AD7KC7/wSr/M/wBEqnLcwTLhmb4j of63Z3vjXwbHHAM/LQ4fZiI5ID9LFH/Kf34fpuf/AIyp/b1M/wDcVkf59y5ikwfmu6/xmdOLqsTq bG/QJotOsw79JT/Za4Xf9uLgmGD8VDzIIyyvrq6nwbJHJ8Ow8P6MTCX96EnUx3cLrPqTaR1OyudL KCSPNj2bf/Pj1xlFi6b6nXR12hv+kZY3/o+p/wCi0MBrJDzH4sHxTFfLZvCEpf4nrd/6zX/r1FPZ lZf/AJ7tv/opUa74Cb603x1ot/dprH3mxyz236J2Y3ln5/k5nLYP6Ni03jf+N6nSffI5VnoL93Vh Hap5P3sWK7I05W39UaXWX5GYfoMaKWHxJi2z/Nb6KOEXlj539i3msYx8tlkf3eH/AB/S9MSAJPC4 fqf10yWdXZbha4OMXVurJEXgmLLJ/M+j+qO/75d6SvfXTrnpsPSMckPsaDlPB4rd/gNPzrv8J/wH /HLhb7FLzPMES4IGuE+o+PZPwb4XGcDmzwEvcBjjhL9yX+U/wv0H17CzMfOxKsvGdvpuaHsPx/Nd /Lb9F6OvP/8AF51kszLukWvOy+bcdp7PaJuaP+MrHqf9aXoCs4cnuQEvofNyfiPJy5TmZ4TrH5sc v3scvl/7x//R9VXjn1rufd9ZOoPs+kLiwf1awKmf9Bi9jXmP+MTpL8TrA6g0TRnAEmNG2MDa3s/t t2Wf9uKtzkScYI6HV2/+LmWEOclGWksmMxh5gifC8qpMe+t7bGEte0hzXAwQRqHNKinWc9kNQ+oY eZV9cvqvfjuLasst2WtB0ba2LKbfzneha9jf/Bal5jbW+qx9Vg22VuLXtPIIO1wWn9WeuP6J1SvJ O52M/wBmTW08sP539ap36Rv/AG3+etT6+dIqx82vq2J78TqQ9TczVgsgO3Bzfb+sNPrfy/0ysZD7 uMT/AE4emf8Ad/Rk5HJ4/uPOT5bbl+avNy3aGWP87h/xHm6rIXQfVG7/ALIsCO73j76rQuZW59Tn k/WXAH8t3/UPUWL+ch/ej+bd5+APK8wf9Vk/9Jydj613R9Yslv7rah/0N3/flnNyET65W7frRmjy q/8APTFkjI80cp/WT/vS/Np8pgvlOXPfFjP/AI3F0nZGncnsByT4BdqcgfVf6tVuuAdlHRrOQ6+3 dbslv+Dq93v/ANFUuW+p/T29R6n9pucG4vT9t9hJ0L9TQ0mRta3Z6z/+LVL6z9f/AGt1N9tbicWm a8Uagbfz7tp/Ovd/4F6akxy9uByfpS9MP+6k1eY5b71zMOVH81hrNzP94/zOH/C/6DSvyHvc59ji +x5LrHnlznGXvd/WVK22VGy6UIknlV7dzHiEXQ+rz3s6/wBOc0wTlVAkeDnta4f2muXs68r+ofSH dQ62zIcP0GBFzz/L/wC07P8APHq/9ZXqi0OSBECT1Ojyv/GbJCXNY4R1ljh6/DjPFGL/AP/Su4H+ M++nOyWZ9P2nCde80Pr2ttrrLnbK49teRtZs/wBE/wD4R67Jz+hfWrpj6WWsyqHgE7SPUqcdwY/a 730XN92zez/wNeJ5dDsPOyMN/wBLGtfU7vqxzq/++qxgZ2Vg5DMrDtdTfWZa9p/A/muY789jvYqX vyjYmOKL00vhWHKI5OXl7GWIEoyj8hI+U/1f8B2Ov/VrqHQr9t49TGeYpymiGu/ku59O3/g1kyu3 6T/jBxcvFdgfWSkWMsAY69jZa5p5dfS36O36e/H/AO2kHrf1FD6z1D6uWNy8RwLvQa7c4R/3Hsl3 r/nezd6v/GqKeESuWI8Q6x/Ti6HLfEcmIxw8/H2sh9MM/wD4Hzf4f+Tm8cu1+q2VV17o2T9Ws94N zG7+nvfqRA9oZp/2mf8Ay9/oWWVfzNa4tzXNcWPBa4aEHQg+aP0/Nv6fm05tH87Q8PaDMGPpMdH5 j2+x6ixz4Ja/KfTId4lvc7y/3jCYxPDlgRkwZP3M0PVCX/cyR5GPdjX2Y97dl1LiyxuhhzTtcNFs /Uhu760YI87D91VpWx9demUZ+FR9aOnNJrvY37UJ1AIayqwtbubvr/mL/wBJ/o/+EWZ9Qai/6zY7 v9Eyxx+bHV/+jE8YzDPGO44omJ7xa0+bjzHwzPlrhmMWWGWH+bzRhKM4f4yvr60t+s2SeN7Kj/0G t/76sGpt1tjKqmmyywhrGNEkuJ2ta0D95dL/AIxmbfrCD+/Qw/i9v/fVY+o3SKaq7/rH1BpGNhtc 7HkcloJtua38/wBL6Ff/AAv/AAlSMsZnnlEfvEk9oowc3Hl/hWDNIcRGKEIQ65MtcEIBP9YLv+bX 1cx+gY5b9szWl+bY06wYFv7vttd+r1v/ANBS9cQSSrXVuo29T6lkZ9ujr3lwbztaPbVXIDf5usNY qoBcQ1oknQAckqPLPilp8o9MR/VDZ5Hljgw+s3myE5c8/wB7Lk+b/Bh8kVlqdB+r2d1zKFOO0spa f02S4exg/wC/2/uVf+i/0i2+ifUS1zG5/XnjCwmje6pztjyO3rOd7cdn73+G/wCKVzqP16wOn4je nfVugNZUCxtz2wxo/fqYffc930/Uv/P+n629PhhAHFlPDHpH9ObW5j4jPJI4Ph8ffy/LLN/4G5f+ 9k/Tn/Uenx2dF+q/TGUvtrxqWAlz3mH2vA/SWbf5y6137rP6i5Tqf+Me+66uvplJopD2l9tkF7mg t3MFfuZV+d+db/1tchm52Zn5DsnMtdfc/lzj252tH0WM/kMQ6KzdfXS3V1j2sA83Hanz5qRqOMcE dh+8wct8CwwMs3Ny+85pXKRl/NiX6R4f0/8Aqj//03/xndAtxepjrNLP1XM2tucPzbwNurY9rbqm Md/xvqrjWPXv+bhYufi2YeZU27HubtsrdwR/31zXe5j2/QXln1i/xcdV6bYbulB/UcMydrQPWZr7 WOrH9I9v+Epb/wBZrVXNhNmQF27vwz4jERjiyS4ZR0iTtKP/AHzzTXLS6P1zqXR7/XwbSwuj1Kzq x4H5tjPzv+rWVYy7HtdTkVuptYYdXY0scD/KY+HKTXjxVQgxNjQh6GM8eWBjMRnCQ1jL1Rk+hVdX +rH1tZXT1pgwOpABrchh2h350NueHM26e2rJ/wCs2eosXrf1K6x0kPua37XiMlxvq5a0T7rafp1+ 0bn/AM5Uz/Srmw4Lo/q/9dup9HimwnMwxA9Gxx3MAG0Ciz3em3/g/wCbT+OE9Moo/wCcj/3cWv8A d+Y5X1clPjx9eUzH0f8Apvl/yX912P8AF71Oq6vJ6BmHfVe1zqK3cEEFuVSNfzmfpNjf+GVn6t9A s6N9cr8Y7nUDGfbjWuiXML6me7b+fXu9N/8AnrQxMH6tdfto6v0h4xc3Hey1/ogMeDO51eXjj6Xq fpGep/hP9LbWun2t3B0DcAQD3g8/kVnHiuMLIPtm4TH6Uezh878Q4cnMe3CWP73Dg5nl8g4Tizx/ ysf7zw31t6Lf1n63YeJX7WOxWuus/drZZb6j+/7zWV/8Io/X/qFeBgYn1ewztq2Ndc3UkV1w3GZu P7z2b3/n/omLu9rd26BuiJ7wuaz+nfVzpGTkda61YMrKyHOfU26HGG6Mpxcb891TPRr9R/0P+BSy YqEyCB7h9Uz+jBHJfEBLJy0ckJZI8pGsGDGOOWfmTtk/q8DxXRPqd1jq+y1rPs+I4ici3QFv71Vf 07vb9D/Bf8Kt5+d9VvqiLK+nN/aHV2yx1jzIYfzt1jR6bGt/Oro/S/4K16yfrB9eOo9VmjF3YWHq CxjjveD7f01jY9u3/BM/656q5qVV44Y9MY4pf5yX/cRegHK8zzfq52XtYj/4Ewn5v/OnN/lP7kHR 6x17qfWbhbm2y1v83S321t/qV/vfy3fpFnppUqqrbrG1UsdbY4w1jAXOJ/ktaoSTI2TZLowjjxQE IRjjhEaRj6YxYrqPqD0R+f1VufbWTiYR3h/DTcINVf8AK9P+e9v/AAe/+cTdC+ofVeoWCzPa7AxQ Ru3iLXfvNrqd9D/jLf8AwVek4ODi4GLXiYlYqoqENaPxc4/nOcrXL8vIyE5CojUA/pOF8Z+M44Yp 8vgkJ5ZjhnKJ9OKJ+b1fvv8A/9T1VYn1o+sV31exa8wYL8zGcS26xjw0VE7fS9T2v9lsub6n7/8A xta20HLxcfMxrcTJYLKL2Gu1hkS1w2uEthzf7KButDRXYzETBnHijfqjto8Bb/jZxrBDukGweD7m /wDpFyEP8aWIf+8Ov/t5v/vKsb60/UTqfRLbMjGY7L6aXHZYwF1lbY3bcpjR7dv0fXb+i/4n1PSX LSPFVZZMoNE19A72DlORyREoR4on+vP/AL59DP8AjOod9Do1TfjaD/7rtSZ/jEzMixtOJ0ih9zzD GAOscT4NZW1rnLC+r31G671nbcWfY8MmDkXggkaSaaPbZbz/AMHT/wAKvT+g/VjpPQqz9jrm97Q2 3JeZe4DX+rWzd+ZUjGOaW8uEeQWcxl+G4BUcXu5f3ePJwj+/LjTdFb1X7ObeqVY+PdZBbTjtMtH7 t1jnvbY//i/+mtFJJWQKFOJknxyMqEb/AEY/KPJSo9Xb1E4vqdNqouya5IqyAYcI1rre1zPTsd/L /Rq8kkRYpUJ8EhKhKjtL5T5vndn+MDOxbXUZnSaWXVmH1ncxw7/Re1ydv+Muv87pFZ+FoH/ohy7H rP1e6X1qoMzqpewEV3MO2xk/uu/75ZvrXm/XfqP1npINtbftuIP8LSDuaPG6j3PZ/WZ6taqZBzEN RLij5C3oeSyfCeZAjkwjDl/dOTJGEv8AZz4/+a7P/jmY/wD5Ts/7eH/vOiM/xoYzNB0wtnnbaP8A 0k1eel4W/wDVv6n9S63ay17HY/TwQbL3jaXNn3DG3NPqP/l/zSjhlzyNA39ItvmPh/wvFAzyQ4Yj vky/9++i/Vr6xu6/Vde3DfjUVENbY524PcZ3tZDW/wA3+d/XW2gYWHjYGLVh4rBVRS3axg8P+/Od 9J7kdX4ggDiNnqXlc8scskjih7eO/RC+Ko+Jk//V9VSXC/UX/GLl/WnrF3TrsKvGbTjuv3seXElr 6qtvua3/AEy7DqeW7C6bl5jGh7saiy5rCYDjW11gaXa/S2pKbSh6NPqersb6sRvgbo8N30lyP1C+ vWT9ax1A3YjMb7C2ot2OLtxs9bncP+BVb6if4xMv61dVuwLsKvGbTjm/ex7nEkPrq27XN/4VJT3S SzfrH1Wzo3Q8zqlVYufi1+o2txIB1A1cFj/UL65ZH1sxcu+/GZi/ZrGsaGOLp3N3a7g1JT1SS5b6 +fXUfVPDxbK6BlZOXYW11OcWtDGAG6zc0O+i59TNv/CKH1D+vdX1sqyWW1Nxc3GcCaGu3B1Tvo3M 3bX+2z2W/ufov9Kkp6xJcL1b/GLl9G+uFfQeoYVbMO2ysNzN5b+iuhrLyHjZtpsP6b/irV1/Vs9v TOl5nUXN3jDosv2TG702us2bv5e3YkptpLzf6q/42retddxel5mFVi15RcxtzbCYs2l1Tdr2/wCF e30f69i7X6y9br6D0PL6rY3f9mZLK+N1jiK6Wf2rXs3JKb5ooNouNbDaNBZtG6P6/wBJEXJfVP67 nq/Qczr/AFdlPTcHFsNYfucZ2tY57zub7t77q6qWV/pLLf0awP8Ax3eo5+VbT0DoF2cyrXcC97yz htj6Mamz0f8At2xJVl9MSXn2B9ffrpk5+Nj3/VbIoputrrtudXeAxjnNbZa4upDfYw7lZ+vn+MPL +qvU8fCpw68ll9AuL3vc0g7317drWn9xJT//1uQ+of1gy+gdbvzMTp1nVLLMd9JoqLmua02U2et7 Ksj2t9LZ9D/CLtOp/wCMzreX03LxX/VbKpZfRZW60vsIYHMc11jv1Nv8233/AElj/wCJhrm/WzL3 NLZwbYkR/hsVesfWGf2B1KOfsl8R/wAW9JT5v/iQ465/Vxv/AHaWf/iT/wDFLmf+Enf+fcdaX+I5 pDutBwiRi8+B+1LG6KOqf4tfrRbd1TCtyMKyt2Ocipp2vrc6u1t2O922p9jfSb+hfYkp9P8Ar/8A +I3q3/hc/lauU/xIf8mdT/4+v/qCqX1s/wAZ2F9YeiX9G6Hg5bsnN2sc6xjNGBzXv2MofkutdZs9 L/BqGFVm/Uf/ABdZhzWmnq3XLCzFoaSLWMfWGb7Gj31W01evd7f5p78euz07UlNd3UKvrZ/jObkX 5VVPSekWB1Vj7Gema8Z42em922u37dl/pP8AwvZ/wKBk9QxPqd/jLOfhWMs6VmnfZ6L2Ob6OQf1h v6Lc1n2bLY66uj/gKld+pf8Aip6d1joFPU+r3ZNN2UXPprocxoFP0anWNuot99m19vtf/MvqS+uv +Krp3RugXdT6RblX3Yrmvurucx49H6Nr2Npoqdurc5ljvds9H1UlN7/HV0L1cXD69U2XY5+y5MST 6bybMd/7rWV2+qz/ANCGKX1v+tjcj/Ffg2ssL8nq7a8e1xMP3Vf098fnM9bH9F3/AIYVv6q3H66f 4u8noeW/9ex2fZS55gyzbd03Is2Df6e5ldb/APTfZ7l5d07G6h1LN6d9XL97KRmmsAt91br3U05f /bbcbds/4xJTtde6L/zb6b9U+u4o/T21Nvt9sD1Wvb1Ch1jx9Kz08n0P+LxV1P8Aje+sGNlfV/pO LiOLx1Nzc1pBAPotZ+iFlf0v0z8n2f8Ahd66X/GT0NnU/qdlVUsAs6eBlY7QYAFIPqtgfS/VHXtY z9/YvK/qV0/L+sn1m6ThZkvxenMkyIiil78oVO/fa/Iv9H+pakp6769dOf8AVv8AxY9P6PXAc++q vMIMhz3Nuzb/AHfnN+01ez+Qsj6j/XHM+r/RRj4P1bvzjdY59udW54FhB2tb7cW/+Zb+j2+r/wCf F6R9efq5Z9Y/q7f0+gtGUHMuxnPMND2HuRP06nW1f21539Vvrt1j6lUWdB650u99NNjjTHsfXuO6 1jdw9LIofZ+lqsY/8/8AwtdlfppT0uB/jM61lZ2Ni2fVfJoZkWsqdc59hDA9zWGx04bPobt30lzH +O3/AMUGD/4TH/ny1dPg/wCN7p2bnY2G3puSx2VdXS17iyAbHNqDj/nLmv8AHWx7vrBg7Wk/qY4E /wCEtSU//9n/7R74UGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAAAAAAAAAAAAAAOEJJ TQPtAAAAAAAQASwAAAABAAIBLAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAAAAA/gAAAOEJJTQQN AAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAAAAEAOEJJTQQKAAAA AAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgABAGxmZgAGAAAAAAAB AC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0AAAAGAAAAAAABOEJJ TQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////////////////////// /////wPoAAAAAP////////////////////////////8D6AAAAAD///////////////////////// ////A+gAADhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4AAAAAAAQAAAAAOEJJTQQa AAAAAANbAAAABgAAAAAAAAAAAAABLAAAASwAAAATAEgAVwBfAFAATwBTAF8AUgBHAEIAXwBWAGUA cgB0AGkAYwBhAGwAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAASwAAAEsAAAAAAAA AAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3Vu ZHNPYmpjAAAAAQAAAAAAAFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAA AAAAQnRvbWxvbmcAAAEsAAAAAFJnaHRsb25nAAABLAAAAAZzbGljZXNWbExzAAAAAU9iamMAAAAB AAAAAAAFc2xpY2UAAAASAAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAG b3JpZ2luZW51bQAAAAxFU2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAA AApFU2xpY2VUeXBlAAAAAEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABU b3AgbG9uZwAAAAAAAAAATGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAABLAAAAABSZ2h0bG9uZwAA ASwAAAADdXJsVEVYVAAAAAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAA AAZhbHRUYWdURVhUAAAAAQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhU AAAAAQAAAAAACWhvcnpBbGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJ dmVydEFsaWduZW51bQAAAA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlw ZWVudW0AAAARRVNsaWNlQkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAA AApsZWZ0T3V0c2V0bG9uZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRz ZXRsb25nAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAE4QklNBAwAAAAAGTgAAAAB AAAAgAAAAIAAAAGAAADAAAAAGRwAGAAB/9j/4AAQSkZJRgABAgEASABIAAD/7QAMQWRvYmVfQ00A Av/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwMDAwM EQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwMDAwM EREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIAIAAgAMBIgACEQEDEQH/ 3QAEAAj/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEA AgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFi MzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF 1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFx IhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPT dePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/APVU kkklKSSSSUxssrqrdba4MrYC573GAGgS5znH6LWrges/4wcq699HR4px2naMl7ZsfH59bH+ypn/G M9T/AIv6Ctf4yeruqop6RUYN/wCmv/qNMUs/tWtc/wD6yuDo5VLmeYkJcEDVfMXpvgnwjFLCOa5i Inx37WOXyCI/TlH9LidgZ/Usixtt2XdZYxwfWX2OcGuB3tc2ufT9rh+4vT+k546j06jMA2m1vvb2 D2nZa0f1bGuXleP2Xd/UnJ34V+IeaLN7f6tgn/z4y1N5SZ9wgn5h+IV8dwROATjER9qXQcP6ufpl /wA/gd/KyGY2PZe/6NbSY8T2b/acuWpflb3Wi17LLHF79jiAXE7ne36K2vrDcGYjKe91gEeTf0h/ 6TWrKo2907mpnjEQflH/ADi5fJQ4cMpkXxn/AJsW7jdYyqXBuV+lq4LgIeP5Xt9r1tV2MtrbZW4O Y8S1w4IK5y7bGitdBynC2zDOrINtflqBY3+1u3/56PL5pcQhI2DsT3W8xy8TA5IR4THWQGxi7aSS SuOepJJJJT//0PVUPIyKcWizIvcGU0tL7Hns1olx0RFwn+MnrL2+j0el8NePWygO4n9BW7+011mz /iUzLkGOBl9nm2uQ5SXN8xDCDQkbnL93HH5i18b/ABg3n6wG64FvSrYqFR5Yyfbknbu/S/nWt/63 +ZWvQWPZYxtlbg9jwHNc0yCDq1zXBeErvP8AF99Y+OiZbhpJw3H/AD7KC7/wSr/M/wBEqnLcwTLh mb4jof63Z3vjXwbHHAM/LQ4fZiI5ID9LFH/Kf34fpuf/AIyp/b1M/wDcVkf59y5ikwfmu6/xmdOL qsTqbG/QJotOsw79JT/Za4Xf9uLgmGD8VDzIIyyvrq6nwbJHJ8Ow8P6MTCX96EnUx3cLrPqTaR1O yudLKCSPNj2bf/Pj1xlFi6b6nXR12hv+kZY3/o+p/wCi0MBrJDzH4sHxTFfLZvCEpf4nrd/6zX/r 1FPZlZf/AJ7tv/opUa74Cb603x1ot/dprH3mxyz236J2Y3ln5/k5nLYP6Ni03jf+N6nSffI5VnoL 93VhHap5P3sWK7I05W39UaXWX5GYfoMaKWHxJi2z/Nb6KOEXlj539i3msYx8tlkf3eH/AB/S9MSA JPC4fqf10yWdXZbha4OMXVurJEXgmLLJ/M+j+qO/75d6SvfXTrnpsPSMckPsaDlPB4rd/gNPzrv8 J/wH/HLhb7FLzPMES4IGuE+o+PZPwb4XGcDmzwEvcBjjhL9yX+U/wv0H17CzMfOxKsvGdvpuaHsP x/Nd/Lb9F6OvP/8AF51kszLukWvOy+bcdp7PaJuaP+MrHqf9aXoCs4cnuQEvofNyfiPJy5TmZ4Tr H5scv3scvl/7x//R9VXjn1rufd9ZOoPs+kLiwf1awKmf9Bi9jXmP+MTpL8TrA6g0TRnAEmNG2MDa 3s/tt2Wf9uKtzkScYI6HV2/+LmWEOclGWksmMxh5gifC8qpMe+t7bGEte0hzXAwQRqHNKinWc9kN Q+oYeZV9cvqvfjuLasst2WtB0ba2LKbfzneha9jf/Bal5jbW+qx9Vg22VuLXtPIIO1wWn9WeuP6J 1SvJO52M/wBmTW08sP539ap36Rv/AG3+etT6+dIqx82vq2J78TqQ9TczVgsgO3Bzfb+sNPrfy/0y sZD7uMT/AE4emf8Ad/Rk5HJ4/uPOT5bbl+avNy3aGWP87h/xHm6rIXQfVG7/ALIsCO73j76rQuZW 59Tnk/WXAH8t3/UPUWL+ch/ej+bd5+APK8wf9Vk/9Jydj613R9Yslv7rah/0N3/flnNyET65W7fr Rmjyq/8APTFkjI80cp/WT/vS/Np8pgvlOXPfFjP/AI3F0nZGncnsByT4BdqcgfVf6tVuuAdlHRrO Q6+3dbslv+Dq93v/ANFUuW+p/T29R6n9pucG4vT9t9hJ0L9TQ0mRta3Z6z/+LVL6z9f/AGt1N9tb icWma8Uagbfz7tp/Ovd/4F6akxy9uByfpS9MP+6k1eY5b71zMOVH81hrNzP94/zOH/C/6DSvyHvc 59ji+x5LrHnlznGXvd/WVK22VGy6UIknlV7dzHiEXQ+rz3s6/wBOc0wTlVAkeDnta4f2muXs68r+ ofSHdQ62zIcP0GBFzz/L/wC07P8APHq/9ZXqi0OSBECT1Ojyv/GbJCXNY4R1ljh6/DjPFGL/AP/S u4H+M++nOyWZ9P2nCde80Pr2ttrrLnbK49teRtZs/wBE/wD4R67Jz+hfWrpj6WWsyqHgE7SPUqcd wY/a730XN92zez/wNeJ5dDsPOyMN/wBLGtfU7vqxzq/++qxgZ2Vg5DMrDtdTfWZa9p/A/muY789j vYqXvyjYmOKL00vhWHKI5OXl7GWIEoyj8hI+U/1f8B2Ov/VrqHQr9t49TGeYpymiGu/ku59O3/g1 kyu36T/jBxcvFdgfWSkWMsAY69jZa5p5dfS36O36e/H/AO2kHrf1FD6z1D6uWNy8RwLvQa7c4R/3 Hsl3r/nezd6v/GqKeESuWI8Q6x/Ti6HLfEcmIxw8/H2sh9MM/wD4Hzf4f+Tm8cu1+q2VV17o2T9W s94NzG7+nvfqRA9oZp/2mf8Ay9/oWWVfzNa4tzXNcWPBa4aEHQg+aP0/Nv6fm05tH87Q8PaDMGPp MdH5j2+x6ixz4Ja/KfTId4lvc7y/3jCYxPDlgRkwZP3M0PVCX/cyR5GPdjX2Y97dl1LiyxuhhzTt cNFs/Uhu760YI87D91VpWx9demUZ+FR9aOnNJrvY37UJ1AIayqwtbubvr/mL/wBJ/o/+EWZ9Qai/ 6zY7v9Eyxx+bHV/+jE8YzDPGO44omJ7xa0+bjzHwzPlrhmMWWGWH+bzRhKM4f4yvr60t+s2SeN7K j/0Gt/76sGpt1tjKqmmyywhrGNEkuJ2ta0D95dL/AIxmbfrCD+/Qw/i9v/fVY+o3SKaq7/rH1BpG Nhtc7HkcloJtua38/wBL6Ff/AAv/AAlSMsZnnlEfvEk9oowc3Hl/hWDNIcRGKEIQ65MtcEIBP9YL v+bX1cx+gY5b9szWl+bY06wYFv7vttd+r1v/ANBS9cQSSrXVuo29T6lkZ9ujr3lwbztaPbVXIDf5 usNYqoBcQ1oknQAckqPLPilp8o9MR/VDZ5Hljgw+s3myE5c8/wB7Lk+b/Bh8kVlqdB+r2d1zKFOO 0spaf02S4exg/wC/2/uVf+i/0i2+ifUS1zG5/XnjCwmje6pztjyO3rOd7cdn73+G/wCKVzqP16wO n4jenfVugNZUCxtz2wxo/fqYffc930/Uv/P+n629PhhAHFlPDHpH9ObW5j4jPJI4Ph8ffy/LLN/4 G5f+9k/Tn/Uenx2dF+q/TGUvtrxqWAlz3mH2vA/SWbf5y6137rP6i5Tqf+Me+66uvplJopD2l9tk F7mgt3MFfuZV+d+db/1tchm52Zn5DsnMtdfc/lzj252tH0WM/kMQ6KzdfXS3V1j2sA83Hanz5qRq OMcEdh+8wct8CwwMs3Ny+85pXKRl/NiX6R4f0/8Aqj//03/xndAtxepjrNLP1XM2tucPzbwNurY9 rbqmMd/xvqrjWPXv+bhYufi2YeZU27HubtsrdwR/31zXe5j2/QXln1i/xcdV6bYbulB/UcMydrQP WZr7WOrH9I9v+Epb/wBZrVXNhNmQF27vwz4jERjiyS4ZR0iTtKP/AHzzTXLS6P1zqXR7/XwbSwuj 1Kzqx4H5tjPzv+rWVYy7HtdTkVuptYYdXY0scD/KY+HKTXjxVQgxNjQh6GM8eWBjMRnCQ1jL1Rk+ hVdX+rH1tZXT1pgwOpABrchh2h350NueHM26e2rJ/wCs2eosXrf1K6x0kPua37XiMlxvq5a0T7ra fp1+0bn/AM5Uz/Srmw4Lo/q/9dup9HimwnMwxA9Gxx3MAG0Ciz3em3/g/wCbT+OE9Moo/wCcj/3c Wv8Ad+Y5X1clPjx9eUzH0f8Apvl/yX912P8AF71Oq6vJ6BmHfVe1zqK3cEEFuVSNfzmfpNjf+GVn 6t9As6N9cr8Y7nUDGfbjWuiXML6me7b+fXu9N/8AnrQxMH6tdfto6v0h4xc3Hey1/ogMeDO51eXj j6XqfpGep/hP9LbWun2t3B0DcAQD3g8/kVnHiuMLIPtm4TH6Uezh878Q4cnMe3CWP73Dg5nl8g4T izx/ysf7zw31t6Lf1n63YeJX7WOxWuus/drZZb6j+/7zWV/8Io/X/qFeBgYn1ewztq2Ndc3UkV1w 3GZuP7z2b3/n/omLu9rd26BuiJ7wuaz+nfVzpGTkda61YMrKyHOfU26HGG6Mpxcb891TPRr9R/0P +BSyYqEyCB7h9Uz+jBHJfEBLJy0ckJZI8pGsGDGOOWfmTtk/q8DxXRPqd1jq+y1rPs+I4ici3QFv 71Vf07vb9D/Bf8Kt5+d9VvqiLK+nN/aHV2yx1jzIYfzt1jR6bGt/Oro/S/4K16yfrB9eOo9VmjF3 YWHqCxjjveD7f01jY9u3/BM/656q5qVV44Y9MY4pf5yX/cRegHK8zzfq52XtYj/4Ewn5v/OnN/lP 7kHR6x17qfWbhbm2y1v83S321t/qV/vfy3fpFnppUqqrbrG1UsdbY4w1jAXOJ/ktaoSTI2TZLowj jxQEIRjjhEaRj6YxYrqPqD0R+f1VufbWTiYR3h/DTcINVf8AK9P+e9v/AAe/+cTdC+ofVeoWCzPa 7AxQRu3iLXfvNrqd9D/jLf8AwVek4ODi4GLXiYlYqoqENaPxc4/nOcrXL8vIyE5CojUA/pOF8Z+M 44Yp8vgkJ5ZjhnKJ9OKJ+b1fvv8A/9T1VYn1o+sV31exa8wYL8zGcS26xjw0VE7fS9T2v9lsub6n 7/8Axta20HLxcfMxrcTJYLKL2Gu1hkS1w2uEthzf7KButDRXYzETBnHijfqjto8Bb/jZxrBDukGw eD7m/wDpFyEP8aWIf+8Ov/t5v/vKsb60/UTqfRLbMjGY7L6aXHZYwF1lbY3bcpjR7dv0fXb+i/4n 1PSXLSPFVZZMoNE19A72DlORyREoR4on+vP/AL59DP8AjOod9Do1TfjaD/7rtSZ/jEzMixtOJ0ih 9zzDGAOscT4NZW1rnLC+r31G671nbcWfY8MmDkXggkaSaaPbZbz/AMHT/wAKvT+g/VjpPQqz9jrm 97Q23JeZe4DX+rWzd+ZUjGOaW8uEeQWcxl+G4BUcXu5f3ePJwj+/LjTdFb1X7ObeqVY+PdZBbTjt MtH7t1jnvbY//i/+mtFJJWQKFOJknxyMqEb/AEY/KPJSo9Xb1E4vqdNqouya5IqyAYcI1rre1zPT sd/L/Rq8kkRYpUJ8EhKhKjtL5T5vndn+MDOxbXUZnSaWXVmH1ncxw7/Re1ydv+Muv87pFZ+FoH/o hy7HrP1e6X1qoMzqpewEV3MO2xk/uu/75ZvrXm/XfqP1npINtbftuIP8LSDuaPG6j3PZ/WZ6taqZ BzENRLij5C3oeSyfCeZAjkwjDl/dOTJGEv8AZz4/+a7P/jmY/wD5Ts/7eH/vOiM/xoYzNB0wtnnb aP8A0k1eel4W/wDVv6n9S63ay17HY/TwQbL3jaXNn3DG3NPqP/l/zSjhlzyNA39ItvmPh/wvFAzy Q4Yjvky/9++i/Vr6xu6/Vde3DfjUVENbY524PcZ3tZDW/wA3+d/XW2gYWHjYGLVh4rBVRS3axg8P +/Od9J7kdX4ggDiNnqXlc8scskjih7eO/RC+Ko+Jk//V9VSXC/UX/GLl/WnrF3TrsKvGbTjuv3se XElr6qtvua3/AEy7DqeW7C6bl5jGh7saiy5rCYDjW11gaXa/S2pKbSh6NPqersb6sRvgbo8N30ly P1C+vWT9ax1A3YjMb7C2ot2OLtxs9bncP+BVb6if4xMv61dVuwLsKvGbTjm/ex7nEkPrq27XN/4V JT3SSzfrH1Wzo3Q8zqlVYufi1+o2txIB1A1cFj/UL65ZH1sxcu+/GZi/ZrGsaGOLp3N3a7g1JT1S S5b6+fXUfVPDxbK6BlZOXYW11OcWtDGAG6zc0O+i59TNv/CKH1D+vdX1sqyWW1Nxc3GcCaGu3B1T vo3M3bX+2z2W/ufov9Kkp6xJcL1b/GLl9G+uFfQeoYVbMO2ysNzN5b+iuhrLyHjZtpsP6b/irV1/ Vs9vTOl5nUXN3jDosv2TG702us2bv5e3YkptpLzf6q/42retddxel5mFVi15RcxtzbCYs2l1Tdr2 /wCFe30f69i7X6y9br6D0PL6rY3f9mZLK+N1jiK6Wf2rXs3JKb5ooNouNbDaNBZtG6P6/wBJEXJf VP67nq/Qczr/AFdlPTcHFsNYfucZ2tY57zub7t77q6qWV/pLLf0awP8Ax3eo5+VbT0DoF2cyrXcC 97yzhtj6Mamz0f8At2xJVl9MSXn2B9ffrpk5+Nj3/VbIoputrrtudXeAxjnNbZa4upDfYw7lZ+vn +MPL+qvU8fCpw68ll9AuL3vc0g7317drWn9xJT//1uQ+of1gy+gdbvzMTp1nVLLMd9JoqLmua02U 2et7Ksj2t9LZ9D/CLtOp/wCMzreX03LxX/VbKpZfRZW60vsIYHMc11jv1Nv8233/AElj/wCJhrm/ WzL3NLZwbYkR/hsVesfWGf2B1KOfsl8R/wAW9JT5v/iQ465/Vxv/AHaWf/iT/wDFLmf+Enf+fcda X+I5pDutBwiRi8+B+1LG6KOqf4tfrRbd1TCtyMKyt2Ocipp2vrc6u1t2O922p9jfSb+hfYkp9P8A r/8A+I3q3/hc/lauU/xIf8mdT/4+v/qCqX1s/wAZ2F9YeiX9G6Hg5bsnN2sc6xjNGBzXv2Mofkut dZs9L/BqGFVm/Uf/ABdZhzWmnq3XLCzFoaSLWMfWGb7Gj31W01evd7f5p78euz07UlNd3UKvrZ/j ObkX5VVPSekWB1Vj7Gema8Z42em922u37dl/pP8AwvZ/wKBk9QxPqd/jLOfhWMs6VmnfZ6L2Ob6O Qf1hv6Lc1n2bLY66uj/gKld+pf8Aip6d1joFPU+r3ZNN2UXPprocxoFP0anWNuot99m19vtf/Mvq S+uv+Krp3RugXdT6RblX3Yrmvurucx49H6Nr2Npoqdurc5ljvds9H1UlN7/HV0L1cXD69U2XY5+y 5MST6bybMd/7rWV2+qz/ANCGKX1v+tjcj/Ffg2ssL8nq7a8e1xMP3Vf098fnM9bH9F3/AIYVv6q3 H66f4u8noeW/9ex2fZS55gyzbd03Is2Df6e5ldb/APTfZ7l5d07G6h1LN6d9XL97KRmmsAt91br3 U05f/bbcbds/4xJTtde6L/zb6b9U+u4o/T21Nvt9sD1Wvb1Ch1jx9Kz08n0P+LxV1P8Aje+sGNlf V/pOLiOLx1Nzc1pBAPotZ+iFlf0v0z8n2f8Ahd66X/GT0NnU/qdlVUsAs6eBlY7QYAFIPqtgfS/V HXtYz9/YvK/qV0/L+sn1m6ThZkvxenMkyIiil78oVO/fa/Iv9H+pakp6769dOf8AVv8AxY9P6PXA c++qvMIMhz3Nuzb/AHfnN+01ez+Qsj6j/XHM+r/RRj4P1bvzjdY59udW54FhB2tb7cW/+Zb+j2+r /wCfF6R9efq5Z9Y/q7f0+gtGUHMuxnPMND2HuRP06nW1f21539Vvrt1j6lUWdB650u99NNjjTHsf XuO61jdw9LIofZ+lqsY/8/8AwtdlfppT0uB/jM61lZ2Ni2fVfJoZkWsqdc59hDA9zWGx04bPobt3 0lzH+O3/AMUGD/4TH/ny1dPg/wCN7p2bnY2G3puSx2VdXS17iyAbHNqDj/nLmv8AHWx7vrBg7Wk/ qY4E/wCEtSU//9k4QklNBCEAAAAAAFUAAAABAQAAAA8AQQBkAG8AYgBlACAAUABoAG8AdABvAHMA aABvAHAAAAATAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwACAANwAuADAAAAABADhCSU0E BgAAAAAABwABAAAAAQEA/+ESSGh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8APD94cGFja2V0 IGJlZ2luPSfvu78nIGlkPSdXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQnPz4KPD9hZG9iZS14YXAt ZmlsdGVycyBlc2M9IkNSIj8+Cjx4OnhhcG1ldGEgeG1sbnM6eD0nYWRvYmU6bnM6bWV0YS8nIHg6 eGFwdGs9J1hNUCB0b29sa2l0IDIuOC4yLTMzLCBmcmFtZXdvcmsgMS41Jz4KPHJkZjpSREYgeG1s bnM6cmRmPSdodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjJyB4bWxu czppWD0naHR0cDovL25zLmFkb2JlLmNvbS9pWC8xLjAvJz4KCiA8cmRmOkRlc2NyaXB0aW9uIGFi b3V0PSd1dWlkOmU2NTBlYTY0LWQ2N2EtMTFkYS1iYjVhLWUyZmVhOGI3NjFlMycKICB4bWxuczp4 YXBNTT0naHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21tLyc+CiAgPHhhcE1NOkRvY3VtZW50 SUQ+YWRvYmU6ZG9jaWQ6cGhvdG9zaG9wOmU2NTBlYTYyLWQ2N2EtMTFkYS1iYjVhLWUyZmVhOGI3 NjFlMzwveGFwTU06RG9jdW1lbnRJRD4KIDwvcmRmOkRlc2NyaXB0aW9uPgoKPC9yZGY6UkRGPgo8 L3g6eGFwbWV0YT4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgCjw/eHBhY2tldCBlbmQ9J3cnPz7/7gAOQWRvYmUAZIAAAAAB/9sAhAAMCAgICQgMCQkMEQsK CxEVDwwMDxUYExMVExMYEQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAQ0LCw0O DRAODhAUDg4OFBQODg4OFBEMDAwMDBERDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM DAz/wAARCAEsASwDASIAAhEBAxEB/90ABAAT/8QBPwAAAQUBAQEBAQEAAAAAAAAAAwABAgQFBgcI CQoLAQABBQEBAQEBAQAAAAAAAAABAAIDBAUGBwgJCgsQAAEEAQMCBAIFBwYIBQMMMwEAAhEDBCES MQVBUWETInGBMgYUkaGxQiMkFVLBYjM0coLRQwclklPw4fFjczUWorKDJkSTVGRFwqN0NhfSVeJl 8rOEw9N14/NGJ5SkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2N0dXZ3eHl6e3x9fn9xEAAgIBAgQE AwQFBgcHBgU1AQACEQMhMRIEQVFhcSITBTKBkRShsUIjwVLR8DMkYuFygpJDUxVjczTxJQYWorKD ByY1wtJEk1SjF2RFVTZ0ZeLys4TD03Xj80aUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9ic3R1dn d4eXp7fH/9oADAMBAAIRAxEAPwD1VJJJJSkkkklKSSSSUpJJJJSkkkklKSSWb13ruH0TDOTknc92 lNI+k93gP5P770CREEk0AvxYp5Zxx44mc5moxHVu5GTj4tLr8mxtNTBLnvIAH3rleo/4xMKpxr6b S7JI09V/sZ/Zb/OP/wCguK6v17qHWsg3Zb/YD+ioboxg/kt/e/lqqwKjl5yRNY/SO/6T1HJ/8XcW OIlzR9yf+bieHHH/AAvmm9HkfXTr+TIbc3Hae1TQCP7b97lRtz8/KJORk22zyHPJH+bO1UmBHYFX lknL5pE/V0I8tgxfzeKEP7sQD/jPof1S6o7O6aKrXTfiwxxPJb/gn/8AfFuLz36q5pw+rVAmK8j9 E/5/zZ/z16EtHlsnHjF7x9JeT+K8uMPMy4RUMn6yP1+aP+MpJJJTNBS5PqWbZlZrrGOLWM9lcGNB +dp+8t/rGScfBeWmH2exvz5/6K5hjFU5ue0B/eP7HS+HYgBLKR/Uj/3TYp6h1CqNt7iB2d7h/wBJ XqOv5LdLq22Dxb7T/Fqz2sUtirxy5I7SLZyYsM/mhH6DhP8AzXosXqWLlaMdtf8AuO0P/mStLkiw jUaEcFanTuruBFGUZB0ZafyP/wDJK1i5kE1PQ9+jRz8lQMsR4h1ifm+jspJJKy0lJJJJKUkkkkpS SSSSlJJJJKUkkkkp/9D1VJJJJSkkkklKSSSSUpJJJJSkkkklIcvKow8a3KyHbKaWl73eQXj3Xes5 PWeoPy7iQz6NNfZjPzWf+TXYf4yuqurox+l1uj1v0twH7rTFTf7T9zv+trz5Z/OZSZcA2jv/AHnr v+LnIxhh+9TH6zLYx/1MQ/79IxHYgMR2Kq7k2wxWGKuxWGItWbYrJaQ5ujmmQfML07CyRlYdOQP8 KxrvmR7l5ixdz9Ucj1el+kTrQ8tjyP6Rv/VK1ycqmY/vD/ouD8cxcWGGTrjlX+DN3EkklfedcD6w 3bsiqgcVt3H4u/8AOVnsClnXetnXWTI3Fo+DfaPyJMWZllxTkfF28UODDCPYa+cvUUrGogYmYjCI TVkpG2u5qC9qtPhV3oL4F1ui55tacW0y9glhPdvh/ZWquQrudRcy5n0mGf7wutre2xjbG6teA4fA q9y2TijwneP5OfzuEQmJx+Wf/S6skkklYaikkkklKSSSSUpJJJJSkkkklP8A/9H1VJJJJSkkkklK SULba6a3W2uDK2Aue92gAGpcV5f9Zfrjl9Rz2HBsdRiYjw6iNC57f8O//vjFFlzRxizqTsG98P8A hubnchjD0xiLnkl8sf3Y/wB6T6mksf6s/WCnrmALdGZNUNyKvB377f8Ag7FsKSMhICQNgtXNhnhy SxZBwzgeGQUkkkixvkv13yjk/WTK19tO2pv9lo3f9PesFaf1lJP1g6hP/ciz/qlmLHyG5yP9Yvo3 JREOVwRGwxwH/MSMR2KuxHYU1km2WKwxVmFHYUWrMNli6n6l3kZGRR2exrx8Wnb/AN/XKsK3Pqrd 6fWKhMCxrmH7tw/6lS4DWSJ8a/xnM+I4+Plso/qmX+J6/wDuXu0O+z0qLLf3Gl33CURUOt2+n0u8 zBcA0f2iGrSmajI9gS8rijx5IR/ekI/a8ux06nk6lWGFVGORmuWW9BOLba5E3qq16nvSYDBK56C9 yYvQ3PSXRgxeV0nQ7TZ02ueWEs+4rl3uXR/Vsz08/wDGO/76p+VP6z6Fh+IR/o4PaQdVJJJX3HUk m41K4P6z/WO3Lym04VhZj4ztzbGmC6xv+E/qM/MUeXLHHGzr2Da5LksnNZOCHpAFymflj2e9SWH9 WfrEzq1Ho3ENzqh+kbwHj/Ss/wC/rcToTE4iUTYLFnwZMGSWLIOGUf5cUVJJJJzEpJJJJT//0vVU kkklKSSWH9buu/sbpTn1mMrImvHHgY91v/WmoSkIxMjsGTBhnmywxYxc8h4Q8x9fvrMb7XdGw3/o aj+tPH5zx/gf6lf5/wDwi4pIuLiXOJLiZJPJJSWTkyHJIyL6DyXKY+VwRw4/0fml1nP9KZdDonWc no3UGZlBkDS2vs9h+kw/99XsGBnY3UMSrMxXb6bm7mnuPFrv5TV4eun+pP1l/ZWZ9jynxg5J1J4r sOjbP6jvo2Kblc/AeGXyy/5pc3478M+84/fxD9fiGoH+Vx/u/wB+P6D6ikmTrReMfH/rfS6n6yZ7 T+dZvHweBZ/35Y667/GTh+l1enLA9uTUAT/KrO0/9B1a5FZGaPDkmPE/i+h/Dcoy8ly8x/m4xP8A eh6Jf86K7eUdhQEVhTGzIaNlhVhhVVhR2FFrTDaYVo9IuFXUsWw8C1k/Anb/ABWWxysUWbLGP/dc D9xlGJog9i1M0OKEo/vAx+19VWL9abduBWzu+0fgHFbIIIBHB1C5z64WADFrnWXuj/NC0+YNYpeX 5vI8hHi5rGPEn/FjxOI1yK16qNeites16CUG0HqXqKsHp96TGYJy9Dc9DL1EvSSIMnOXVfV1hb0u tx/Pc534x/31cc567zp9H2fBopiCxjQfjHu/6Ss8mLmT2H5tL4qeHDCP70r/AMUf+hNhJJZvXusV 9KwjYIORZLaGHu798/yGK7KQiDI7ByMWOeWcccBcpGgHJ+t/XTQw9NxXRbYP1h4/Naf8H/Ws/wCo XEPKLfa+2x1lji97yXOceSTyVXeVl5chySMj9B2D2XI8pHlsQxx1O85fvzXx8zIwsmvKxnbLqjua 78rXfyXfnL1LonV6Or9PZl1e130ba+7Hj6TP/IryV5Wr9U+unpHVWix0YmURXeOwP+Du/sO/6Cfy 2bglR+WW/wDFj+LfDvvOAzgP1+IXH+vD9LH/AN4+qJJJLSeOUkkkkp//0/VUkkklKXkv116uep9c tax04+JNNQ7e0/pX/wBqxem9azfsHScvM701OLf60bWf9NeJkkmSZJ5Kp87PSMO+pej/AOLPLAzy 8wR8n6uH96XzqTpk6ovVBSSSSSX0n6hfWT7bjDpWU6cnHb+hcTq+sfm/16v/AD2uvXhuJlX4eTVl Y7tl1Lg5jvML2HoXWKOs9OrzKva4+22v9x4+mz/yK0OVzcUeCXzR28YvHfH/AIb7GX7xiH6rKfUB /k8v/e5HG/xidPOT0RuU0S/DsDj/AFH/AKN//S9NeYr3LMxa8zEuxbRNd7HVu+DhtXieZi2YmVdi 2iLKHurd8WnaoedhUhP94V9Q6P8AxZ5njwZOXJ9WKXHH/Z5P/Q0KmwqCcaKq9A2GOR2OVRjkdjkm GcW2xyKHaFVWuRWuRa8ovrWE7fh0P/erYfvaFzH1zs/XcdvhUT97v/MV0PRLPU6Rhv8AGln/AFIX KfXO3/K7G/u0t/EvK0OYP6gePC8n8Nx/0+Q/c9z/AL1zGvUw9VWvUw9UHflBtB6feqwen3pLOBOX qJeg70xekkQb/S6DmdRoo5aXhz/6rfe78i79ct9TMTcb85w/4Kv/AKuw/wDULqVocrCsd/vG/o8/ 8Wy8XMcA2xDh/wAOXqkjyL6sah99ztldYLnOPgF5t1nqtvU81+S/Rv0amfusHA/8mtb64dc+0Xfs 7Hd+hpP6Zw/OePzP6tX/AFa5dzlBzWbiPAPljv4ydX4NyHtQ9/IP1mQekfuY/wDvprPcgvcne5Be 5VXdhFi9yA8qb3ILjJQbEA+sfUrqx6n0Sv1Hbr8X9Db4naP0b/7Va315v/i2zTV1W/DJ9uTVuA/l Vmf+oc9ekLU5efHiiTuPSfo8L8Z5YcvzuWMRUJ/rYeWT/wBD4lJJJKZzn//U9VSSSSU85/jAscz6 s3gGN762n4bg7/vq8oC9Z+vtLrfqxk7RJrNbz8A9s/lXkwWfzn84P7r1/wDxbI+5yrf3ZX/iwXTp klVd0LpJJJLlLd+qP1gd0XqQ9Qn7HkQzIb4fu3f9b/6hYSSMJGMhIbhiz4IZ8U8WQXCY4T/H/Bfd 2ua5oc0gtcJBHBBXnH+MbpP2fqFfUqxFeWNtkdrGD/v9f/ULV/xffWH7TjnpGS6bqBOMTy6sc1/9 a/8APf8AUXQfWPpI6v0i/DA/Skb6T4WN9zP876C0Z1nw2N9x/eHR43ljP4X8SEch9F8E5dJ4Mny5 P+7fGkk7muY4scC1zTDgeQQmWa9uyaYRWuQFJroSQRbaa5Ga5VGuRWvSYZQfWfqy7d0DBP8AwQ/B cl9cn/5dePCqv8hXU/VMz9XcE/8AB/8AfnLj/ro+PrDcPBlf/Uq/zH+54f4P/ReV+GR/4U5gdvd/ 9KuaHqQeqoeph6ou+YNkPT71W3p96S322xvTNLnvaxg3PeQ1o8SdAEDet/6mdOOX1E5bxNOJqPA2 H6H+Z9NPhEzkIjqWLmJxwYZ5ZbQF+cv0Y/4T2fS8JuBgU4o5rb7z4uPue7/OWf8AWjrY6XhbKj+t 5Etq/kj8+3+z+b/LWrlZNOJj2ZN7tlVTS57vILyzq3Vbup51mXbpuMVs/dYPoMV7mMoxwEY7kUP6 sXn/AIXycub5iWbLrjgeOd/5TJL1cH/ftdz55Mk8lCc9Rc9Dc9Zz10YLucguck5yE5yDNGKnOUEk kmV2/qZY6v6y4JaY3Pc0/BzHheuryT6k0ut+s2HtGjC57vg1jl62tDkv5s/3nj/+M9fe8ff2hf8A jzUkkkrTgv8A/9X1VJJJJTW6jhszsDIw38X1ur+bhAK8QtqsotfTaNtlbix7T2LTtcF7wvNv8YnQ Ti5o6vQ39BlHbfH5toH0v+ut/wCmqvN47iJj9Hfyd7/i7zYx5p8vI0M2sP8AaQ/R/wAOLxydME6o PWhdJMnQXKSSSSSmw8u/CyqsvHdsupcHsPmF7J0bqtHV+nVZ1OnqCLGfuvH85Wf6q8VXTfUbr/7M 6l9kvdGJmENdPDbOK7P++PVjlc3BPhPyy/Nx/jvw/wC88v7sB+uwAyH9fH+nD/uoM/r/ANF+w9V+ 21NjHzZdpwLB/Ot/t/zi5Zey/WLpDOsdKuxDHqxvod4WN+h/nfQXjljH1vdXYC17CWuaeQRoQhzW LgnY+WWv16p+A89945UQkf1uCoS/rQ/yc/8AuWKSSSgddkHQiNegpwYSQRb6/wDVDX6tYH/Fn/qn Livru6PrJeP5FX/UrtPqh/4msD/iz/1Tlw/17MfWW/zrq/6lXuY/3PD/AAf+i8p8JF/F+aH+2/8A S0XID1IPVYPUg9UXpDBs70t6r70t6K3gbAc5xDWgucTDQOSTwF6l0Dpg6X0urGI/Skb7j4vd9L/N +guL+ovSft3UTnWtmjCgt8Dafof9tt/Sf5i6/wCs/W29G6Y+9pH2m39HjtPd5/P/AKtf01c5WIhG WWX08nnfjWWWbPj5HD6pWDP/AGkvkj/gQ9cnmvr1131rx0rHd+ipIdkEd7Pza/8ArX/VrkS9Dfa5 7i97i5ziS5x1JJ1JKgXqrkyGcjI9Xe5Pk4cthhij+iPVL9+f6UkjnobnqBeoEkpjbEGTnKCSSS9S SSLjY92VkV41DS+21wYxo7kpIJABJNAakl7L/Fp04uycnqTm+2toprP8p3vs/wA1rW/569BVDofS qukdMpwa9SwTY/8AeedbHq+tbBj4MYj13Pm+f/E+b+9c3kyj5L4cf+zh6Y/43zqSSSUjSf/W7i/6 5dFxus29IyrPQtq2/pnfzZc4b9hf/g3N3fnrca5r2h7CHNcJDgZBB8F4R1zLdmdazslxn1L7CPhu LW/9FXehfWvrHRXAY1u/H/OxrJdWf6o/wf8A1tVhzNSIkNL0IdyfwTixQlhlWThHFCfyylXq4Zfo vtaBm4ePnYtmJksFlNzdr2n/AF+k1YXQfr10fq22m132PLOnpWn2uP8AwVv0Xf2l0inEozGhBDkZ MWbl8gE4yxzibH0/SjJ8c+sn1by+g5ZY8GzFsJ+z3xo4fuP/AHbWrIXuWdgYnUMV+Jl1i2mwQWn/ AKpp/Ne1eW/Wf6o5nQ7DdXN+A4+y4ctn8y+Po/11Rz8uYeqOsf8AovV/CfjMeYAw5iI5xoDtHN5f 6z+q4CdRTqq7gXSSSSXKSSSSU+q/Unr37V6WKbnTl4kMsnlzf8Fb/wB9eub/AMYfQ/suY3qtDYpy jtuA4FoH0v8ArrVgfV/rFvRuqVZjZNc7b2D86s/TH/f2r1nPw8TrXS347iH0ZVYLLBrE+6q1v9X6 SvQPv4TA/PH+UXleZifhXxKPMQH9Gz3xRHQS/nYf4H85jfFEkfOwr8DLtw8hu22lxa4fD84fyXfS QFRIo0XqYyEgJRNxkLBHUFSSSSSX2H6piPq5gf8AFA/eSuD/AMYOn1ksPjVWfwXoH1Zbt+r3Tx/w DD94lcF/jFbH1hn96is/i8fwV/mP9zx/wfyeS+DH/hfP4+9/6UeZDinD1BJUHraSb0Siu3Iuropa X22uDGNHdzjDVXXc/wCLroO97utZDfaya8UHx4tt/s/zbf7afixnJMRH18mpz/NQ5Tl55pfoioR/ fyH5IvYdG6ZT0fpdWI0j9G3dbZxuefdbYV5l9auvHrHVX2MdOLTNeOP5IPus/wCuuXX/AOMDrv2L AHTaHRkZg/SEctq/O/7d+h/24vNFY5vIBWKO0d/2ByPgHJylx8/m9WTMZe3fY/zmT/D+VkXppKZJ VHolJJJJKUkki42NflXsx8et1t1hhjGiSSkgkAEk0BqSUbWue4MYC5zjDWjUknsF6Z9S/qmel1/t DOb+vWiGMP8Agmn/ANGv/PU/qp9TKekhuZm7bc8j2jltU/ufvWf8IuoV/luW4anP5ug/deT+M/Gv eEuW5Y/qtsmX/O/1If6v/pqSVXqHU8DptBvzbm0s7buSfBjB7n/2VwnXP8YmVkbqOkMOPUdDkPg2 H+o36FSnyZoY/mOv7o+Zy+S+G8zzZ/VQ9HXLL044/wCF+l/gPadW6/0vo9e7NuDXkS2lvusd/Vr/ AO/OVb/nRh/83v27sPpf6GRu3b/S9Of3l5JbdbfY6257rLHmXPcSST5uK1v2i/8A5p/s+dPtm6P5 OzdH/biqjnTxE8PpA26793cl/wAWcYxQiMpOaUvVkI9AjwT9Mcf9/gf/1+M3lzi52pcZPxKm0qfU aTjdRysciPSusZH9VzmoTSs6Qe0xTsA90oK6XoP146v0nbVY77ZiDT0bTq0f8Fb9Jv8A1C5gFTBT BKUTcTTPPFizw4MsBOJ6H/uf3X2non1p6R1poGNbsyIl2PZ7Xj+r/pP7C1rK67a3V2ND2PEOa4SC D2IK8EY97HB7HFrmmWuBgg+RXYdB/wAYmfh7aOqA5mONPVGlrR8fo3f2/wDPVrHzQOmQV49HD5z4 BON5OVlxga+3I/rB/cn+k3frN/i/cwuzOiNLmcvw51H/ABBP0v8Ai1w7muY4seC1zTDmkQQR2IXt fTOsdO6rR62De21v5zRo5vlZWfcxZ/1g+qPTettNhH2fMj25DBz/AMcz/Cf9Wm5eVEhxY616fon+ 6ych8dyYJexzolUfT7hH62H+1j+n/wBN8jTrR6z9X+p9Fu9PMr/RkxXe3Wt3wd+9/Ics1UpRMTRF F6fFlhlgJ45CcJbSibC6SSSDIpeh/wCLrrnrY7+kXu/SUDfjzyWH6df/AFty88Vnp2ff07Opzccx ZQ4OHgR+cw/yXt9qkw5DjmJdNpeTT+JcmOb5aeL9P5sZ/dyR+X/vXu/8YfQfXx29Yx2zbQNuSB3r /Ns/61/1H9Redr2/EycXqfT68iuLMfKrnaddHCHsd/1D15P9Z+hv6L1R+OAfs9nvxnnuw/mz+9X9 BT83i1GSO0t/4uV/xe54mMuSzaZMN+3xb8A+fH/exuQkkkqj0L7Z0ZmzpGE3wx6h/wBBq4L/ABls jrGO/wDexx+D3r0PCZsw6Gcba2D7mhcF/jOZGdgv8anj7nf+ZLR5kfqPLheL+Bzv4oD+/wC7+Rk8 Ukkks57RvdG6Vf1bqNODTp6hl7/3WD+cs/stXr4GF0jpukVYmHX9zWj/AKpyw/qN0D9mdO+13tjM zAHOB5ZXzXX/AGvpvWX/AIx+twK+jUO5i3Kjw/wVX/oz/ttXsURgwnJL5pfyjF5TnssvinxCHKYj +oxE8Uh/V/nsv/qPG8f1fqd3Veo3Z130rXe1v7rRpXWP6rVSSSVEkkkncvUwhGEYwgOGMAIxA6Ri pJJJJcpJSYx9jwxjS97jDWtEknyAXZ/V7/F9dftyuszTVy3FGjz/AMa7/B/1f5z+on48cshqIv8A Jrc3zuDlYceaYj+7Hec/7kXneifV7qXWrvTxGRU0xZe7Rjf7X5zv5DV6d0H6tdP6HTFDfUyHCLch 30j/ACW/6Ov+QtLHx8bDobTQxtNFY0a0Q0ALmuu/X7p2BuowIzckaSD+iaf5Vg/nP+tq9DFjwDim Rxd/+9Dy3M89zvxXJ7PLwlHD+5H/AKWfI9NkZFGNS6/IsbVUwS57yAB8yuL67/jFrZuo6Mz1HcHJ sHtH/FV/nf8AXFx3VeudT6vb6mdcXgfRrGjG/wBSsKgoMvOSOkPSO/6Tp8h/xcxY6nzR96f+bH8z Hz/zifMzszOvN+Zc6+0/nPM/Jv7qAkkqpJOpd6MYxAjECMRoANAFIu532Xb+b6k/OEJaH2R37A+2 R7ftfpT/ANb3ogbolIAxHc0P8WRf/9DN/wAYfT3YX1oyXR+jyw3IYf6w22f+CseucaV6t/jO6G7O 6SzqVLZu6eSXxyanfzn/AG273/8Abi8nVLNGpnx1el+H5/c5eBv1QHBL/BTNKmCgtKICoSHUxzSg qQKGCpAphDZjJtYmZlYd7cjFtdTa3h7DBXddB/xkNdtx+tM2ngZVY0/67UP+qr/7bXnoKkCnQyzx n0n6dGLmuR5fm41lhZ/RnH05I+Un3ScHqWJp6eVi3DyexwXFdf8A8XRG7J6K6RycR5/882u/6iz/ ALcXIdJ671Po93q4NxYD9Oo6sd/XrXonQfr70zqW2jMjCyjoA4/o3H+RYfo/1bFZGTFmHDMcMv5f LJw5cl8Q+GSOXlZHNh3lGr0/1uH/ANSY3zK+i/GtdTkVuqtYYcx4IIPwKgvaOrdC6X1mn082oPIH stbo9v8AUsXnvXfqH1Ppu6/EnNxRrLB+kaP5dX53/W1Bl5WcNR6o+G7qch8d5fmKhk/UZf3ZH9XL +5P/AL55lJLUGDoQkq7sPdf4uOtbX2dHudo6bcafH/C1j/z5/wBuLpfrV0JvWulvqaB9qpl+M7+U P8H/AFbforybDy7sPKqyqDttpeHsPmCvaOmZ9PUsCjOp+hewOjwPD2f2H+1X+WkMmM4pa1/0f/QX lPjmCfKc3j57D6eM2f6ueP8A6th/6kfE3sfW9zHgte0lrmnQgjkFSx2b8ipn7z2j7yuy/wAYX1e9 K39s4rf0dpDcpo7P4bd/1z6L/wCWuW6LV63WMKr9++sH/Oaqk8Zhk4D30eg5bnYcxyn3iGnpJnH9 ycB64vtQECPBcP8A4z6/0XT7PB1rfvFZ/gu5XH/4zKt3Sca39y+P85rv/ILQ5kXhn5PHfBZcPxHA e8pR/wAaEovm66X6j/V/9qdR+1XtnDxCHOnh7+a6v+/2LCwMHI6hmVYeM3dbc4NaOw8XO/ktb7l7 H0jpdHSun1YNA9tY9zu7nn6djv6zlT5XDxy4j8sfxL0nx34j92we1jP67MKHfHj/AEp/9zBJ1LPp 6dg3Zt383QwuI8T+awf13e1eL5uZdnZd2Xed1t7i9x+PYf1V2P8AjH61vtq6PS721xbkR3cR+iZ/ Zb71w6PN5eKfANo/9JZ/xe5L2eXOeY/WZ9R/Vwj5f8f51JJK503pPUOqX+hg0utd+cRo1o8XvPtY qwBJoCy7U5xhEynIRjHUykeGI+rTWz0P6q9U604OpZ6WNPuybBDf7H+ld/VXYdC/xfYWHtv6oRl3 jUVD+aafP863+17F0XUOqdN6RjC3LtbRWBDGDkx+bVW36St4+U04sp4R2/iXA5z/AIwXL2eRgc2S XpGSrjf+rx/ptPoX1V6X0VodSz1sqIdk2CXf9b/0Tf6qbrn1r6V0YFlr/Wyu2PXq7/rh+jV/aXHd e/xgZ+duo6aDh450Nk/pXD+sP5r+x/nrkyS4lzjJOpJ5JTp81GA4cIHn0YuW+BZ+Yn7/AMQySJlr 7d3P/Dn/AJOP9TG7XXPrb1XrJNb3+hinjHrJAI/4V30rViJJKnKUpG5Gy9FhwYsMBjxQGOA/RipJ JJBkUkkmSQpeg/sN/wD43fp7T6237bEa87//AG3XH/V/pNnV+rUYTR7HHdc7wrbrYf8Avq9l9Kv0 vS2j09uzZ22xt2qaEP1WSflEf40XN5nmh9/5PlgdScmWfkMOWMP+7f/R9TexljHV2NDmPBa5p1BB 0c0rxT64/Vm3oHVHMY0nByCX4tnOnelx/fqXtqoda6NhdawLMHNbNb9WvH0mOH0bKz+81MyY+MeI 2bXJc2eXyWdYS0mP+6fAwVNpWl9Yvq31DoGYcfKbuqcT6GQ0ex48v3X/AL9aygYVKUSDRelxZYyA lE8UTsQmBUwUFpRAUwhtwmlBTgoYKkCmENiMkgKdQBUgU2mUSei6B9dOq9ILanu+1YY09Gw6tH/A 2fSZ/wBQvRui/WTpfWq5xLYuAl+O/Sxv9n89v8ti8YlTputpsbbS91djDLXtJBB8nBTYuZnDQ+qP Y/sc3nvg3L81c4j2cx/TiPTL/aQfW+t/U/pHWN1jmfZ8o/8AaioAEn/hGfRsXn/W/qh1jo82Pr9f GH+HqkgD/hG/SrW59X/8Ytle3G60PUZwMpg9w/46sfT/AK7F3eNk42ZQ2/GsbdS8aPYQQVYMMOcX H0y/H/Ci5Eea+JfCpDHmHu4No8Xqxkf6rL+h/c/5j4au4/xb9Z22W9Hud7Xzbjz+8P51n9pvvW31 v6i9I6lutxx9iyTrvrHsJ/l0/R/zNi4nK6F176s51Waai9mO8PZkV+6swfz/AM6vd/wigGPJgmJ1 cRuY/uupLneT+KctPlxL280hcIZPTL3Y/JwS/TfVsjHpyqLMe9ofVa0se08EFebYPQL+lfXbEwny 6sW+rRYfzq2h1jT/AFm7Nr16Pg5dWdh05lP83ewPb8xwiOppfYy1zGusrn03kAubu+lsd+buVzJi jk4ZfukSB/qvOcnz2XkxnxEExywnjlA/oZa4Iz/wf0ma5r/GFUbPq493+itrefv9P/0YulULqab6 zVcxtlbvpMeA4GNfouT5x4oSj3FNflc/scxizVxe3OM6/eEejyv1D+rn2DE/aWUyMrKb+jaRqyo6 /wCfb9JdJ1LPp6dg35tx9lDC6PE/ms/tu9qsriP8YOdk5NuP0LCY+2x8XXMYC4n82pvt/tPUcqw4 vT00H9aRbeL3PiXPg5TQmeLJr6cWDHvH/F9LwmZlXZmVblXndbc8vefMlLEw8rMuFGLU6613DGCS uv6L/i5yLdt3V7PQZz9nrILz/Xs+hX/Z3ruOn9L6f0yn0cGhtLO8D3Hze8+96qY+UnPWfpB/xnoO c+P8ry49vlwM04jhHDpghX9f9L/AeO6J/i4Ptv6zZ5jGqP8A59t/9J/9uLtKaMHpuLspZXi41Qkx DWgfvOd/5JZfXvrd0vozTW532jL7Y9ZEg/8ACu/wX/Vrzjrf1l6p1p/61ZtoBlmOzRg+X57v5T1M Z4cAqA4p/wAvmk5uPlfiPxWQyZ5nFy+4scMP+o4f0v8AaTet69/jEpp3Y/Rmi6zg5Lx7B/xbP8J/ a9i4TMzcvOvORl2uutdy55n5D91ASVTJmnkPqOnbo9FyXw7luUjWKHqPzZJerJL/AAlJJJKNuKSS SSQpJMkkq1JAEkACSdAAkASQAJJ0AC9B+pf1MdjuZ1TqjIuHux8d35n/AAto/wBJ+4z8xSYsUskq H1PZp89z2LlMRyZDr+hD9LJLsHU+pP1cPR8A35LYzsoA2A8sZ+ZT/wB+sXSJJLS9qPt+3+jVPE/f 8/3v73f63i4v6tfL7f8Ac4PQ/wD/0vVUkkklNbqHTsLqWK/Ezqm30P5Y7x/eafzHt/eavNPrF/iy z8RzsjoxOZj8+g6Bc0fyeG3f+fF6okmTxxlv9rY5fm8uA+g+nrA/KX53tqux7DVex1VjdHMeC1w+ LXJBy99z+k9M6kz08/GryG9t7QSP6r/ptXOZn+LH6t3kuo9bEceBW/c0f2bhZ/1Sgly8uhBdbD8Z xf5SMoHw9cXygFTBXojv8U2HPs6jYB51tP8A35qQ/wAU+P8A+WT/APtof+lFGeXydvxbsfjPJ9ch /wAWf/evnoKkCvQf/Gpo/wDLJ/8A20P/AEqn/wDGqx//ACxf/wBtD/0om/dsv7v4hlHxvkf86f8A Eyf96+fAp5XoP/jV4/8A5Yv/AO2h/wClE4/xWY//AJYv/wC2h/6UQ+65f3fxDIPjvIf50/4mT/vX z6Vo9H691Lo1/q4VpaD9Op2rHf12f9+XYf8AjW43/lg//tsf+TT/APjXYv8A5YWf9tj/AMmkOWzA 2BR80T+NfDMkTDJPjhLQxljmR/0XY+r31z6b1kNpsIxc0/4F50cf+Bf+d/U+mugIDgQRIOhBXED/ ABX4oMjqFkjgisf+TXXdNw7MLBqxbb35T6hHrWfScJ03f1foq5iOWqyR/wAJ5vn4ciJcfJ5SQTri lGY4PGM5/othrGsaGMAa1ugaBAAUkklK0FJJJJKUo7Gb9+0byI3RrHhKkkkpBmZuJg0Oycu1tNLO XOMfIfvOXn31h/xg5WXuxukzjY50N5/nXf1P9C3/AMEXR9e+po63mnJvz7WMAAro2hzGQIds1b9J Zv8A42GJ/wBz7P8Attv/AJJVs3vyuMBwx736pO38NPwnCI5eZyHLm34Djn7WI/4v6yT585xcS5xJ J1JPJKS9B/8AGwxP+59n/bbf/JJf+Nhif9z7P+22/wDklV+65v3fxDu/6f8Ah3+dP/heT/vXz5Je g/8AjYYn/c+z/Mb/AOSS/wDGvxP+59n/AG23/wAkl91zfu/iFf6f+Hf50/4mT/vXz1Jehf8AjX4n /c+z/ttv/kkv/GvxP+59n+Y3/wAkl91zfu/iFf6f+H/50/4mT/vXz1Jehf8AjX4f/c63/Mb/AHo1 P+LLpLHTdk32j90bW/8AfXI/dMvYfatP/GD4eBpkkfAQm+bLT6T9XOsdXeBiY7vTPN7/AG1j+276 X9henYH1Q+r2AQ6rDY94/Ptmw/8Agkt/6K2AABAEAcAKWHJfvy+kf4ufzP8AxmFEcviN/v5f/VcP +/ec+rv1J6f0ctyLiMrNGoscPaw/8Cz/ANGOXSJJK3GEYCoig89n5jLzEzkzTM5HqfyiP0VJJJJz E//T9VSSSSUpZHXfrR0zoBqHUPVaLwfTcxhc0lv0m7v3tVrrL+snQsfr3SrcG2GvPuot/csH0H/9 9f8AyEJXRrdkxe37kfcvgv1cO7iO/wAaP1YHAyHfCsfxehu/xq/V0cU5Lv7DP/Sq8tzcLJwMu3Dy mGu+hxZY0+I/76781AVU55+Dtj4XypAI4iD/AFn1R3+Nnog+jiZLviGD/wBGIR/xtdP/ADen3H4v aP8AyS8wSS9+ff8ABePhfKjeJP8AhSfTD/jax/zemvPxtA/9FqB/xsH83pv32/8AqJecBymHJpzZ P3vwDND4ZyX+av8Awp/989+7/GtmH6GBUPjY4/8AfWqJ/wAafUzxh0D4l5/78uEDlIFMObL+82I/ DOR/zI+2f/fPbO/xodaP0cbGHyef/RiC7/GV9YXfRbjs+DCf+qsK5EEkwNSeAuy+rX+L7MztmV1X di4pgtp4tePP/Qs/rfpEozzTNRkUZuX+GctDjy4scR0BHFKXhGLZ6R9aPrt1vI9DBFUD+ctNYDGD +W87v81eiViwVtFhDrABvIEAuj3FoQsLBxMDHbjYdTaaWcMaI+Z/ecjq5jhKI9UjInu83zvM4s0x 7OGGDHH5REeuXjkkpJJJSNRSSSSSlJJJJKcH60X/AFmxam5PRRXZVW0+vUW7rP67B+c3+S1cYP8A GL9YmmHCgkcg1n+DwvUVzf1j+pXT+sB2RRGLnHX1Wj2vP/DMH/nz6agzY8h9WOZH9W/+i63w3nOS iBi5vl4Sj0z8NzH+1/e/vPMN/wAZnWh9KjGd/ZeP/RimP8Z3VO+JQfhvH/flzPVekdR6TkehnUmt 35ruWOH71b/ouVKVTObMDRkQfF6OPwz4bkiJxw45RlqJRJ4T/iye3H+NDO/Owaj8HuH96K3/ABo2 fn9PHytP/pNcHKUpfeM3734BB+DfDj/kB9JZP+/fQG/40qvzunO+Vo/9JqY/xo4f52BYPg9p/wC+ hedylKP3nN+9+AWH4H8P/wA0R/h5P++fSW/4z+lH6eJePhsP/f2ojf8AGZ0I805A/ss/9KLzGUpT vvWXuPsYz8C5DpGQ/wAMvqQ/xk/V48tyB/YH/k0Rn+MX6tuIAddJ0A9Mkk/2SV5RK7P/ABe/Vk5e QOsZbP1bHd+rtP59g/P/AKlP/nxPx58s5CIr7Gpzfwn4fy+GWWZyAR2HH88v0Yj0vpLHbmh0Fu4A wdCJ8VJJJXXmVJJJJKf/1PVUkkklKSSSSU8r9d/qbX13H+14gDOp0thp4FrR/gbD+9/onryG+i7H ufRex1V1ZLX1uEOBHZwX0Que+tH1M6b9YGeq79XzmiGZLRzH0WXN/wAIz/pqHLi4tY7/AJulyPxD 2qx5dcf6MusP/QXxRJbHW/qn1vojz9roLqAfbk1y6sj+t/g/+uLHVYgg0RTtwnGcRKEhIHqFJwUy udN6R1Pql3o9Pxn5D+5aPaP69h9jP7SFWuMhEWSIgdS1g5avRPq/1Xrd3p4NJcwGH3u0rZ/Xs/74 33rs/q//AIraai3I65Z6zxr9lqJDP+u26Of/ANbXeY+Nj4tLaMattNNYhlbAGtA+AU0OXJ1loO3V z+Y+MxgDHCOOX75+Qf8AfPP/AFc+o3TOiht9oGXnDX1nj2tP/A1/m/1/prpUklZjERFAU4mbNkzT M8kjOR7/ALFJJJIsakkkklKSSSSUpJJJJSkkkklNfO6fh9Qx3Y2ZU26p3LXDg/vNP0mO/qrzz6w/ 4vMzE3ZPSS7Kx+TQf51o/k/6b/z4vS0lHkwwyDUa9+rc5P4hzHKSvHK4H5sctccv+9fA3BzHFrgW uaYIOhBTSvY+u/VLpHWwX31+lkxpk1QH/wBv823+2vPOt/UXrfSy6ytn23GH+FpBLgP+Ep+m3/pq lk5acNR6h3D03J/GeX5gCMj7WT9yZ0/wJvPSlKiTBg6EchNKip0DNlKaU9NV2RYKqK3W2O0axgLn H+y1dr9Xf8W+Ve5uT1sminkYzT+kd/xjh/NN/wDBP6ifDFKZoBrczzuHl48WWYHaP6cv7sXJ+qf1 UyevZIssDq+nVH9Ndxuj/A1fy/8Az2vXMfHpxaGY+OwV01NDWMboAAmxsajFoZj41baqaxtZW0QA EVX8WIYx3J3LyfP8/k5vJZ9OOPyQ/wC6l/XUkkkpGkpJJJJT/9X1VJJJJSkkkklKSSSSUsQCCCJB 5BWVl/VT6uZji/I6dQ57uXNbsJ/tVbFrJIEA7i10ZyibjIx/unhcOj6k/VWgyzp1Tj/L3P8Awsc9 bFNFNFYrorbVWOGMAaB/ZaiJJAAbABM8k5/PKUv7x4lJJJIrFJJJJKUkkkkpSSSSSlJJJJKUkkkk pSSSSSlJJJJKUkkkkpz876v9F6i7dmYdVr/3y2Hf9uM2vVGv6jfVat24YDXHwc57h/muet5JNMIn UxH2MseZzxHDHLOMewnIBrYfTsDBZsw8evHb4VtDfv2qykknVTGZGRskknqVJJJJIUkkkkpSSSSS n//W9VSXjjv8dvXA4j9n4uhjmz/ya7v6gfWvL+tPS783LprofTeamtq3QQGsfuO8u/fSU9Qkkkkp SS4j/GD9fM/6qZWHTiY1OQ3KY97jbukFpa327HN/eWH9Xf8AG31fq3XMLptuFj115dzanvaX7gHd 27nJKfU0kLKtNONbc0Sa2OeAeCWguXkP/j3dc/8AK/F++z/yaSn2NJc99RvrJk/WXoY6nlVMosNr 69lc7YZt195d+8uhSUpJJeafW/8AxpdV6B9YcrpWPh49tWPs22PL9x31stO7a4N/PSU+lpLz/wCo n+MfqX1n6y/p2Vi0UVtodbvrL90tcxu33ud++vQElKSSXIf4wPr076qVYteLVXkZmUS707CYbU3Q vOyPpP8Aaz+2kp69JeOf+Pd1z/yvxfvs/wDJr0n6o/WKv6ydCo6m1oZa6WZFTdQyxv026/8AbjP5 D0lO0kkvKuvf42PrD0brGX0y3AxS7FscwO/SDc3mqz6f59e16Sn1VJcD9Qv8ZOT9Zuq29NzserGe KjbQai73FpHqMPqOd+a7eu+SUpJJeZfWv/Gzn9G6/l9MwcSi+nFcGepYX7i/a02j2Oa32POxJT6a kvHWf47us727+n42yRug2TH5233r17HvryKK8io7q7mNsYfFrhuakpIkksL66fWQ/VroNvUmMbbf vZXRU8kNc5x77fd7aw96SndSXjn/AI93XP8Ayvxfvs/8mvV+j5GZldKxMrOrbTlX1NstqZO1pcN+ z3S72ykpuJLO611/pHQsb7T1TJbjsM7GnV7yPzaqm++z+yuB6l/juxGOczpnTn3AH22XvFYP/Wqx b/58SU+npLxw/wCO7rU+3p2MB5mw/wDfkv8Ax7uuf+V+L99n/k0lPsaS8p6J/jf6x1LrGF0+zBxm V5d9dL3tL5Ae4MLmy7zXqySlJLyPP/xzdaxc7Jxm4GM5tFr62uJskhjiyT7/ACQP/Hu65/5X4v32 f+TSU//X8rf9N3xK9m/xKf8AidzP/DZ/891Lxl/03fEr1b/FJ1/onTOhZVPUM6jFtflFzWWvDSW7 Kxuh3wSU+ppLF/55/VP/AMt8T/t1v96X/PP6p/8Alvif9ut/vSU+d/48P+UOlf8AE2/9Uxch9Rf/ ABYdI/8ADLPyrpP8cHV+l9Uzumv6dlVZba6rBYaXB4aS5sbtq5v6i/8Aiw6R/wCGWflSU/QvUP8A k/J/4mz/AKly+XV9RdQ/5Pyf+Js/6ly+XUlPuf8Aie/8Rzf/AAzb/wB8XbriP8T3/iOb/wCGbf8A vi7dJSl8/wD+NH/xcdR/6z/55qX0Avn/APxo/wDi46j/ANZ/881JKdL/ABM/+Ku3/wAKWf8AV1L2 5eI/4mf/ABV2/wDhSz/q6l7ckpZzmtaXOIDWiSTwAF85fXXr5+sH1jys9pJxw70sUeFTPaz/ALc/ nf8Ari9b/wAan1h/ZH1afjUu25XUyaK4Oorj9Zs/zP0X/XV4n0npt/Vep4vTsf8AncqxtbT4bj7n /wBhvvSUtldMzMTFxMu+vZTnsdZju/eaxxqf/wBJq7b/ABPfWH7B1qzo97ox+pD9FPAvYJZ/27Xv Z/20ux/xi/VOjI+pbKsKuH9EYH44A19Jjdl7P+2m+r/1peJY2Rdi5FWTQ4supe2yt45Dmnc13+ck p+pl4/8A46ei+j1LE61WPZls9C4/8JXrWf7dTv8AwJem/VvrNXXeiYnVKoH2hgNjR+bYPZcz+zY1 yz/8YHRf2z9Vc3Ha3ddS37RR476vfA/4yv1K/wC2kp8N+q3Vj0b6w4PUZhlNrfV863fo7h/209y+ lAQ4BzTIOoI4IXysvof/ABfdX/a/1Twb3GbaWfZrv61X6P8A6dfp2JKd3Lya8TEuyrdK8et1r/6r AXu/6lfMOdl2ZubfmWmbMix9rz5vJefyr3f/ABo9U/Z/1PymtMWZpbis+Dzut/8AAWWLwrpuFZn9 QxsGoTZk2sqb8XuDP4pKa697/wAVvVx1L6o41bjNuATivHeGe6n/AMBexeY/4z+h19H+tDxQz08X KqZdS0CAIHo2NH/XKt39tbH+Jbq/2frOV0l7oZm1epWCdPUq8P61T3/9tpKfZV5L/jt6sH5OB0dh 0qa7JtHm79FT/wBFtq9aXzj9durftj60dQzQ7dV6prpPI9Or9DXH9bZvSUw+p3Rz1r6y4GARuqfa H3d/0df6W2f6zWbF9CdY6pjdH6Xk9SydKcWsvLRoSR9Ctv8AKsf7GrzP/En0fdbndasbowDFoPmY tv8A+j6K1v8AHT1B1H1fxcFhj7ZkS/zZU3ft/wC3H1JKfKev9e6h1/qVvUc95dZYfYz82tn5lVTf zWNV/wCqn1H6z9aLHHDDacWo7bcq2QwH9xm33W2fyVz698+qvW/ql0j6u4GA3qmIx1dLTaDawH1H j1Li7X6XqOckp5qv/EbVtHq9Xdu77aBH/SuUv/GNxv8Ay3f/ANsD/wBLLuf+eH1V/wDLbE/7eZ/5 JL/nh9Vf/LbE/wC3mf8AkklPI9J/xO4/TOqYnUW9UfYcS5lwrNIG7Y4P2bvVdt3QvRllUfWr6t5F zKKOp4tl1rgyuttrS5zjo1rWg/nLVSU/MPWv+Wc//wAM3f8AVuVNXOtf8s5//hm7/q3Kmkp//9Dy t/03fEo2P0/PymF+NjW3sBgurY54B8JYCgv+m74lezf4lP8AxO5n/hs/+e6klPkn7F6x/wBwMn/t l/8A5FL9i9Y/7gZP/bL/APyK+nkklPy1kYeXiloyaLKC7VosY5kgfu7w1bH1F/8AFh0j/wAMs/Ku v/x4f8odK/4m3/qmLkPqL/4sOkf+GWflSU/QvUP+T8n/AImz/qXL5dX1Jl1mzEurHL63N+8EL5bc C0lp0IMFJT7n/ie/8Rzf/DNv/fF264D/ABMZdVv1YvxQR6uPkuL29w2xrHMd/a2vXfpKUvn/APxo /wDi46j/ANZ/881L6AXzv/jDy68z659UtqO5jbRVI8amMof/ANOtJTtf4mf/ABV2/wDhSz/q6l7c vFv8StDn/WTKu/NqxHA/Fz6o/wCpXon+MH6xfsD6tZF9btuXkfq+L473j3WD/ia99iSnyP8AxkfW L9u/WW41O3YeF+r40cHaf0to/wCNt/8AA/TWz/ifwMEdTyOs511VQxG+ljC17Wk2WD9JY0PP5lXt /wCurz1LafApKfp1/VujPaWPzcZzXAhwNrIIPI+kvnb60dKq6R13LwaLG247Hl2PYxwcDW/31e5n 5zWu2PWXtPgUoPgkp9N/xMfWI1ZWR9X73ezIm/Fns9o/TsH9esb/APrS9cIBEHhfL/TOoZHTOoY/ UMY7bsWxtjPPafon+S/6K+luldRx+q9Nxuo4xmnKrbYzykasP8pjvY5JT89/XTop6J9Zc7ADdtIs NmP/AMVZ+kq/zN3prtP8SfWNmVndFsdpc0ZNIP7zP0d0f1mOr/7bVn/HZ0XdVg9brbqwnFyHDwM2 45P9r1lwH1O6uejfWXAz521stDLv+Ls/RW/9B6SntP8AHb1Tfm9P6Sw6UsdkWj+VYfTrn+xW/wDz 1i/4pul/b/rdVe5s14Fb8h08bv5qr/p27/7Cy/r71QdV+tnUclrg+ptvo1OHBZV+haW/1tm9ehf4 k+mel0rO6m4e7JuFLD/IqG4x/wBcu/6CSmf+OnpPr9FxeqMbL8K307Hd/Tt0/wDPzK/89eWfVzqr uj9dwepDjGua5/mwnZcP+2nPX0P9Y+lt6v0LO6aRJyKXNZ5PA3VH/t1rF80PY5jix42uaSHA8ghJ T9IfWzrDOlfVjO6kxw3NpPoHxfZ+jo/6b2r5uXc/Wb62/tD6gdD6aLJyC5zcsTrGL+ho3/8AGtsZ Z/YWB9TejnrX1lwMAjdU60Pu/wCLr/S2/wCc1mxJT7j9ROj/ALG+q2BiOEWvr9a/+vb+ld/mbvTX F/48Z9PpH7s3/fFK9SAAEDhef/45+mvyPq9jZzBJwb/f5MtHpl3/AG62lJT4srjei9YcA5uDklpE gil5BB/sqmvpH6n9Vo6t9Wun5dLg79Cyu0TJbZWBXax39pqSn57/AGJ1n/uBk/8AbNn/AJBL9idZ /wC4GT/2zZ/5BfTqSSn53+qnSOrVfWfpVlmFkMYzLpLnOqeAAHt9znFq+iEkklPzD1r/AJZz/wDw zd/1blTVzrX/ACzn/wDhm7/q3Kmkp//R8rf9N3xK9m/xKf8AidzP/DZ/891Lyp3/ADe3Gftkyf8A RL1v/E99i/YOX9j9X0/tRn1tsz6dX0fT/NSU96kkkkp8h/x4f8odK/4m3/qmLkPqL/4sOkf+GWfl Xc/45f2b9v6b9t9efSs2ejsiNzfpeouU+pf7E/519K9D7V6v2lmzf6e2Z/O2+5JT7+vn76//AFRz Pq91m60Vl3Tcqx1mLeBLRuO80PP5tlX/AE2L6BVTqv7L/Z937X9H7Bt/T/aNvpx/K9T2pKfnb6t/ Wfqv1azvtnTnj3jbdS8TXY392xoLf7L2r0Cj/HizYPtHSDv7mu7T7n1LmPrR/wCNt67/ANi/bd8m fSj0P7H2r9OuSs9PefS3bO26J/BJT6J1r/HP1XLx30dLxGYBeC03uf6tgB/0XtrYx/8AK968699j +77Hn4kk/wDVOcrWD+yd4/aH2jZ39DZP/gq9Y/xff+Np69f7Kn9q6bPt/wDPT/wH/afd/wAR+kSU 3v8AFV9U8noXS7s7PYas3qBafSd9JlTZ9Nr/AN2x7n73tXDf42vrF+1PrD+z6XTi9LBq04NzoOQ7 +zDaf+tr23K9b7Nd6H89sd6XH0oOz6Xt+kvm7I/Ynr2faPtvr73eru9Pdvn37v5W5JTsf4sugjrP 1poNrd2Ngj7VcDqCWEeiz+1cWf2F719no/0bP80Lz7/E3+xfsHUfsHqfafVZ6/rbd2zafQ2+n+Zu 9ZeipKR/Z6P9Gz/NCqdV6PhdU6bk9PuraK8mt1ZcAJBI9r2/ymO96vpJKflzOw78DNvwshu27Gsd VYP5TTtK9T/xMfWL1MfI+r97vdTORiz3Y4/p6x/Us/Sf9cXP/wCMz/m5/wA7sqfX9fbX9p9HZs9T aP3/AM70/T3qn9RvsP8Azr6d+yvtf2r1R9L09vpwftHqR/g/Q9RJT7N9aujt639X83ppEvuqJp8r G/pKT/241q+bHNcxxY4FrmmHA6EEL6pXz39a/wDmz/zk6l6X2rb9psn0/T2bt36X093u2erv2pKe ZX0f9Sul/sr6rdOwy3bYKRZaO++39PZ/0rF4Pg/82ftuP632v0vVZ6m70427hu3R+btX0k3btG36 MaR4JKXXzz/jD6T+yvrdn0taG1Xv+01Acbbf0hj+rZ6jF9DLyj/HJ+xP2n0/7X632r0Hz6Oz+b3f o9/qfy/VSU+WL1L/ABJ9HmzP61Y3RoGLQSO5i2+P/AV59/2Pf93P/Al7f/iy/Zv/ADQxP2du9PdZ 6vqRv9Te7f6mz2/R2f8AW0lPVKt1Lp+N1PAv6flt34+Sw12DvDhy3+U36TVZSSU/OH1q+qnUvqz1 B2NlsLsdxJxsoD2WN+P5tn+krQ/q/wDWvrn1ctc/peQa2Wa2UuG+txHd1bvzv5bPevoTrf7F/Ztv 7c9H7BH6T7RGzy+l+f8AubPevFPrD/42Pru/ZX7QmTPo7fR/sfa/06SnRZ/jq+srWgPxcN5/e22D /wBHJ/8Ax6/rH/3Dw/8ANs/9LLjj/wA3Z0+2R/1pL/se/wC7n/gSSnv+hf43evdS6zg9PuxMVtWV fXS9zRZuDXuDHFs2u92q9aXz19Vf2H/zm6V6P2v1ftdOzd6e2d7Y3R+avoVJT8w9a/5Zz/8Awzd/ 1blTW51f9gftbN3/AGvf9ot3R6cTvdMKp/2Pf93P/AklP//ZUEsDBBQABgAIAAAAIQDzbrBV7QYA AG4TAAARAAAAd29yZC9zZXR0aW5ncy54bWycWNty4zYSfd+q/QeXntdj8E5q40mRFJlx4pm4Rp5N 1b5BJCRhTRIsALSsfP02QHJoOe1UKn4x2Afd6MsBhMYPP760zdUzk4qL7nblfCCrK9ZVoubd4Xb1 7bG8jldXStOupo3o2O3qzNTqx4///McPp7ViWsM0dQUmOrUWt6tBdmtVHVlL1XXLKymU2OvrSrRr sd/zik3/VpOGvF0dte7XNzeT0gfRsw6s7YVsqVYfhDzcjJobUQ0t6/SNS0h4I1lDNTisjrxXs7X2 71qDpY6zkec/C+K5beZ5J4f82cwp3JOQ9XeNv+KeUeilqJhSkNm2GcNtKe9mM6r5K3bGfN7znaTy /MrIRyjb70K0V6d1z2QFCYWaE7K6MUAtvgi94apv6PmBHlgmBii75ExZeAe+AU82ZtZ2kNKgnxgF 2btwKYSeYKXPDXugHSttbUveAAJuPFMIyCuJM/nA9nRo9CPdbbXoZ9x3JxeP5/7IOlv7/wIdZ9yN vUld0hMk7ifJ6/8wqXlFm21PKxDNU50gnKaOgX4Skv8uOk2bzaJbwIY4zxpzdsb5s9n3Zruj9epI Ja0gxGn5HJaQopltwpboJRT5YegqPdh4Rr09ZKyDpD1IU5H5C9R4fbu6npL0RmwdvFlmj7qsqxdD 08cbO5fS2cyFonGUauOLgjya4n27H8tNG9pVbAupbVh21mwjht04+o3X+rgw6p7RZ5bR6kk1VB1T c4xYcGgeJeW2PqPA8q946eGw2R75Xn9lGg4UO5fW/xuUvucd+8T44ajvOmBIM9lRrCzu6VkMerSr 2BfDsWZrKAce33M1InaBb4rddTUwP1VfhnbHJEQw0W1WTxv9C++UeBrMiplk9Onr0EzbgDaNOJmq sl/3W9oyu8prf+wq26G3BR6XsgW21i2YDlrsuQZOKA0p6Fhtoxm3GR3BR1FyqXTJX1htE5qzphkd BO9lA1qgdNdBDEt8E6VpdxiaRdNqwa7m+uFgg0m7+gHo+ZnKp8UpQ+y04YfOLPQb18dtv4BW7ZW/ kNVq8nqZ9N0CZONl92KBQbG0U/wXJjvI8wOFmKy8ovAzUeeiyUYegRAYvLANfo9qZWhnBl9hU8w7 h5A4Dggpxu1i0AUhXpiHEYpEZFNmKJKFXjjtqzfWcj99R6ck5cbHrDlO5G9QDxyPpO4G1fGjMk1R JHPyaDp+Ln1zMs8NYlQnd8NiOoTe6ORRsEkwHddzY3c6Fi91XM8vAtRrNwzJBtfJozxF6+M5xPXQ Kng+eIDmzUu9rERz4KU+cdF4ACk3aA68LAhi3IMsSAOUB15Oigy3VgaZG2AZ9QmJCI7E7qZEq+3H kAXUNz9xCw+N1E8jQlDfYI84GZq3wPWDqMS8DiA5JZqDIAoDH+VBSLzYQZkYOqHrotZA7jooQ8LE zQM00jD3Ex9lSJQ5bokjOQlDdJ1oE4U+jhR+UKDWYsd3HLSmseuTFM1B7AUE9zoO/ChHz5D3zzdA gNhY5eLMD0mOIkUQFLhvJYnme9Plrk/ckDiob0lCYg/lW5KFcFhhHsA2TUNUJ01J6KMcTQsn9lDu ZFGYxChDstj38neQwM3RvGVJ4OHszVKSBChDssyJ8X2aAXcddAfnDnESNAe5oRua6zwhEc7EPPEi 3Os8hXMH5UFehJmDntd5CT+bKEM2jp++g3huildhk7qpO93GL1lVEPhD90/heUmCnkgF0BpnbxG5 Toqvk3lphFauyMKYoJEWG8/J0ewUhUM8NKOl4wUpyqoSNj1+Qynh5I1Qr0v4XXDR34Uyj1wP9a0s IidB4ylLqLb1DW5Vpgxwl2rXptE1zcE4KqEluWrHBiyn7U5yevXZtMJwF2vXO/mU8W7Gd2wvJHuN bIfdDF5fj4CCO3dTQtszA9AFj0gNF9MN21vDDVw7D4tlu/3btUSlNdv//N2a6VaZ/An6zn60epK0 H+/X84KOPx4n7Zp30C20s1wNO7iQj1oddMSvoKGrf32WBrpZEnRaDzy3nU8SPQp4cvAAP601vGxA QwGm4YY9Xzu5vr57NPpwfW3k1rx+sM+078eec3dwbldwqz5qZwUaGr6gpX6yH7uDO2GuxeDLYPaD ViZcmD0NzIRxCLOmwSLzZpm3yPxZ5i+yYJYFiyycZaGRQYNtm4sneGWYh0a+F6btYfWnWXi7+oNo TILtcO66qhlqBiSpRaXuuq2G5xybo+8NkMmvbYE5dMAwsKg60p4BU8wbAFBWrK0AaGAFV89r9gIv FqzmGl6lel639MU8YIyX12k2vF5AK3gx11gyk/sL6VVNNQV1W/wLZduMvPEF3kdYxU1beW53Syf/ rzHqBnrMLeuhq9JCQr7ss8a/reXloezj/wEAAP//AwBQSwMEFAAGAAgAAAAhAPtdH+v2EAAA0YIA AA8AAAB3b3JkL3N0eWxlcy54bWzsXc2P3LYVvxfo/zCYu7Pzsd/IJthde2O39mbjXbfHQDOj3ZGt kaaSxmv71FPTAikC9BC0SA9JExQp0ObSAg1So/1n4o1zyr/Qx0dSokhRIkccu0nty1oUxUe+j997 fOLTvP7mo1nYeegnaRBHe93+a71ux4/G8SSILva6986Orm13O2nmRRMvjCN/r/vYT7tvvvHjH71+ uZtmj0M/7cAAUbqb7HWnWTbfXVtLx1N/5qWvxXM/gnvncTLzMrhMLtbi8/Ng7F+Px4uZH2Vrg15v cy3xQy8D4uk0mKddNtqlyWiXcTKZJ/HYT1OY7Syk4828IOq+AdObxOPr/rm3CLOUXCYnCbtkV/jn KI6ytHO566XjINjrngUzWNGxf9m5G8+8qAt3fC/N9tPA2+ueBrPTBbZN96O0uvc4VQdZI5TSJzDW Qy/c6w4GXdZySCiX2kIvuuBtQXbt1ll5BnnTKJgAfS+5drpPBlvD5fG/wjLn+aJpL4knwHmQwymV I3DMP78djx/4k9MMbux1QRew8d6tkySIkyB7vNfd2WGNp/4suBlMJj5RG94xmgYT/+dTP7qX+pOi /Z0jVAI24jheRBnwYXML5RSmkxuPxv6cKAHQi7wZkD4mD4Rk2BBnxMZKBaI4u0VQTI02SFPAxl9w +n3K+kqSU98jWt/BxbxwqoOXstbhS6G6rlBVxGglsQ3H4206Hm/L8XgAyZJdtOMfmnRJ45cbL4vH jqwHAbLSSgkNN7ZST8ONZdTTUO1gGXyrp6Hahnsaqr24p6HakHsaql25p6HamlsaYw8dqSOEOAuy 0FfGWmbGgFhGmM6Cl86Jl3gXiTefdkiI5mQKekM5XYyyF77S0yyJowsnKzNl7o3ZfOqlAYTZkv9Y pUTPvFHod95KgokTsnopnoTe2J/G4cRPOmf+I1SahRIO6p8/jjunc28MMSCZaC1LMEZUxzaVw+3g Ypp1TqcYcDYS29QEtvqV0PFvBynyoHYlm5qlNA3O5Vk/OHpqlU/6we/4k2Ax46yh0UQ9CXTULUjg FOtJrBMRLUGCCMBkCeijlx3fYP7on5cYn8jYZP7om5cd32D+6JeXHR/1o16+6JNtxr/uJQ86Rua1 ZW27h3EYJ+eLkNtAIzxsWVtwTsJsCdZGnI9vBBJb1hZcgs/O/ngMSQwTPbWWRYGjFlSsxUGpoLGZ r8VaKDKyWqzIWkASrYEFrXZYa0HIGnTv+g8DkiW1dQboBfJwttGchxoOmMYW7yziDEP2WswbaDDP lMqtCDKHqd8xozbUWJ4pNaZPyEkbZWrn+CyUqZ0HtCDUzhVaENLohz5yy32iOZH2ztGCljUs514M 1c4YmbeskTknZOcCHPlNg/hLY716XVD9pgEVawGpftOAirV0JF/W5ypnQMuZ3zSgpfEaehmJmGqz KGu/KRLKwdtgRW7A24CQG/A2IOQGvA0ItQfvZiLuwNuAljU25JgqgrcBIexisxXMCYngbUDIGhso 2rGcEQchHKU20GuTPLKgYi0gFbwN1mItHR14G9CyFpBEK4c6A1puwNuAkBvwNiDkBrwNCLkBbwNC bsDbgFB78G4m4g68DWhZY0OOqSJ4GxCyhoeckAjeBoSwi42XqARvtPqVg7cBFWsBqeBtQMVaOhKg 5kGqAS1rAUm0cvA2oIVdbJSB0ULltlmUG/A2WJEb8DYg5Aa8DQi5AW8DQu3Bu5mIO/A2oGWNDTmm iuBtQMgaHnJCIngbELLGhkrwRmNcOXgbULEWkAreBlSspSMBao5zBrSsBSTRysHbgBbqS2vwNiCE XZYlZLMiN+BtsCI34G1AyA14GxBqD97NRNyBtwEta2zIMVUEbwNC1vCQExLB24CQNTZUgjfayMrB 24CKtYBU8DagYi0dCVBz8DagZS0giVYOdQa03IC3ASFUzNbgbUAIuyxBCK3IRkxuwNtgRW7A24BQ e/BuJuIOvA1oWWNDjqkieBsQsoaHnJAI3gaErLGBnMuFs6PisdVa1O5rlMD0nAE/1WBMcKARkilB tsC7/rmfQNmd33w6pCVBvkILihr1MF3iQRw/6OTnyGvFN9QoiDGpYBQGMZ4af4yndITisOFWTenX 2duHnZu0/Et5DlWqfHQdyu3Eyjks7yM1dDDP7PEcqtfm/PA6GQ2q6kgRIq9gIx1vQW0cq3AjD5OS N+iIlYCsGd/bMqr4fyjQnPA+vV5/fetoH0v/Lnehxo8MknkjrHOEv7xf6J9nZAbzGKoSt3bWKQd0 Hfr9HVYep+2xsb3dMMbO9gbpARzi84mhuPQ8jC9PFtE44zPr0WG8RRaTI9f+9RvaO8fyncn9RZrd JSeob0UFS+iAKT2/DY+MfCg8BVH0B4zW/TEfaBRnU7YMOCW+HwYXESlHzW97qR8Gkc/WwdgL5aNS GSdjZ/pEKONktMQyTj+69tYBkUJRSApN907Z8DgusAuLaRs0CfsQ3WG62sf6SVF7ihpGVJoRLGXy NqmqVHQrgqXzdjYcq0uFtT+Q7vQPp15CWVZUhvE+UBHaoK0HB/3twQHtxdj5wPfnxzAFfDJazCh3 4T+3cpEOuSblt7lKCfo5Dn2YGUxFq+PlHpVKLnWp0nKpS4Oa46oE5Zauj+l1SZGxSVXfwToevvHO Mx8qrMkVdsyqFJcQpLfjRUY0+PbDkAsJnwM1K2tzIpU/7ycBLbotdBWKnm/6AeEwK3qmfXAWIzrp vLJ5WFHZzNskkwD9hyELMk+m1w6PyeRhjm1MYqA1CTY3Q5MQYbjCIAYvyCCCsBAhA+dXNoIlOqA9 HOJd2Qgy2LWNlNwDcxkvyBaGWlsYUphwYwvD1doC8RS3AcxSBJvcF4iWwUy7wTLc4DE9T8PxmF4R rN3rrvdxC0Qu7i5CaKjDY5yyXtcKYGT4S/H2kDLhgZ/kPl0Luc1AOgan7o3BsRAo1kSprBwzP76O xZhyzKqp2cQ56+OFYitAYV8TAYGzpyWomhmekfu1wXQHu1CVN5yOXO6FSxHD8WwUsrB7FNIwFD5Z gq6a7gAmjzxKEDoe+mF4x8PwMYvnwGtNVxKu07v9HqZNpKEgbs3imf75BKsKcfiqAUAhxMnQS7II +J+G92BRIz9hBZEa/h/HJN2gQA0UU2K7jRJUcF0/t5L2jmFLEM9Oyd5K3mfxWBlRStZcdrPT7xQg JqFipQXgqiriAuaj9VpGv7KAj7MdhRyDHXqzEYRhQsQltGg/LzPCIUcVAMEDsOIDNEVLsXPhbZJr arFzsZQPjah08hk4kg9DS718SqDEi6RXLa4ACQRMeIWgBmy3XYohWNtLExR19zpBDR0JikUo/2OC EkSzSeG9JBrW5k40pTxSDcZ5PQV/n3/y+dXHT7/90++v/v45naq44xe3N3oel3NOml18Q2zG1LUU mykbe3nfi2MCkPfYdjfARA/xj6RxG1NyU/hUFnimve5wkyUgigwPKQiFsAbMCvyH4ZZX3d4W0u5X GCJvk6TtamNbJ20170OlffXhe1d//CuVdgupQsQlZxIn/jhg3+PCRAtPJ9CubZgcxSdJHJ8jAhYM h7w6aylcFG97CQxXswrA8Gef/cMRw10r7uilcBN0gQbqdaqr7klRdf/57OkHrfW2YCPP8CqKWWgY N18RwGkbPMRCM5sg/wA+RghfUSR+kQb5mHElHyakTEmfwA6RBHUE6yBIxb3CmNT6ixtFtgVY6tl8 e7DU03zzsNTDAXwOceLfhNW1ePxnyz0O4gI5iez/Pu+4jD2+4vCvPvjds4/+vWKHX5l+YW/WTF08 5k5eefjdOphcV8QLsr36uIBJaZPqMJ7L38rIQdled1t8FwEX6GYK1FWjLrBNTWbBWM83FE4Qp/vJ p1cfvwe6TqewGmZUhEGlF6rlGIgCO8A9oBhPTA8hfoVLliwkV40cy32PnBawfDVTOLphxU6FtnFH ZygllCR5+3gUwxcmEkUu57QZl1gjETFrQkcqUi9ug9byO7uq99/lHm7fDeIbcO7SmGnAJYbP6xt9 pgugZLwPemCiL9hlp0dfXBP3xuLx0pt0ZLOTlLailajlOH7ta0aY2fdma2WajBIUUs5w0Ftt0xt0 lKZQ1zwLpU0IFgDAD0CIkS5vk/ZSLdJ9JUDPoYLkVyugYkqbbaCCjvR/CBX9DZYL00LF9rCHGO8c KiJvfhbjGT8W2DOoUCMDjmZ1xxJ+iHghaKWMF/RWW7ygo/zQ8aIuFN5UAo2rv30KMeB3T3/97Z8/ fP7J+19/+dtvnv7l+X8++u7pb1YQD4Lato1h6XfuxXNakJT95rOvIIO0ggnnbnl+MEmM8xF4rpTl I3r4j0yN2CyOYm68yqtriGiac6swvs2xnzqF2VYVBrktJutq4tMWMShnuGkmpoHnl7s0730eJGlG Nswk141Iu4w0fuoFZ8G7bx0Mhn080dssE1B84WxjOTkGM2hrFTuKnL55+uGzX/3h2b++ev7FF6s0 DIWt63msvUxECwpOwjDhYBx9oYfWxKN7YlJHR8ymGlQdPD1LGvLDwmekhXhihWd4h35duSqcwtuO sgOXwSS+PISvcSdx+VwhbHFXd5AX9otM8YGV5KJ8uEYxBZPAl6MNpg6Nz3GIOUY8x7FUsvNVihd+ A8cuLw7i+gGleE33op6nGDvNAH795S8r0VF/UmUZn6Y5nlL8CFLJ0bMfRtJuR0cUnNgRBwUZeWqs MF7TFJUxN0c6bn71fiU3gf04Z3veGfrGfJN84IVhHEf4yXp5F8Hu0e/ZVwG8iO1iak0YtN2mmelB IZnmN2d6BphKS559HVvabrEEWk0SF09vlepxxLMRsuFobSLV7q/zE/XOeJ0r22E8I8UuRf2XzFov imL4+S/yY1xJXpZWpXnt4UasYjLnWsGcisw2nMGFuXL/rlfEUrqqZjeB8dMU0lUKeuCdd/FWFXdE uxRP3uBjJK/apGvlwzciq1iMWiqhydQzG+Xk9urS36WXIoNtdsYdJsRD31KHDfjVN+SXrsP2Bjv7 oevQ78MnsmuH6K9zu9GOsdVroDIYbLJDP7oxBhsb7Dihtsc2rWEqvQoocWMI7xzq1zJc7zVQGW5u M0PQzWO4Q49IgTlAFzyjoKbwrF/u5a+qRiiMwkHQHzi0tEEZoCq9oYBNhQnV7OVFh8iAj4xr7xAr zI9zUmD6i7K4Mp3+CytGY1ne4o0v6jI1RavMr6ArbEzpRYRpeaRpPCELX3Z67D6GWW3jCYEWNW19 BKmNJ0R9kz2jVdzN+Fo8s2ztaZOPRHuU2XpG0hbvGpmqnkmNjvAlWmIJzF/5PqHcfPB98n2lIlte Y6vCHLi0cn5QwDF00pY+r8mmjmP63YRqs+J3EX9rnKASfRYxawujK0Wf5Ro9NbYgaWuIBtlBmIqS fPXoUCm6sOSrHEvAVzbu+2O1RkkIJ1LWpYqZCqCLHFVuVsQcjL592HHjRr83PKRehGleBdiVQKgq zi91qDzlUu5RVQBf7tEQcvDInzn3FWaH+VGrXKeIs7H7pAMNX3nplGDSbJchhSZwRgKUpFkjLUMT UUdke+fRCeujD1AEZSyUTa+QS4cnol6y8GRFXCzt03O7hl96DKrzZXjHPluWD1iwTY+NekssB+ZV pljuUWmLUpcqY5S6NFgjYppgg9K1xdconG0A5NONh/EiCeBnO4/9S+IoinD1zmnnThCNpzFpZq8s pc4kvyY24fIEM9buMEqE7nvXfnLi1rLLSiUbdaGpenvWp9hEo87pNNmzdKysHFjvDzeu87SJvOXw 0nEQlLncVhziq+X2p9EAjhEc0jf+KwAAAAD//wMAUEsDBBQABgAIAAAAIQBK2IqSuwAAAAQBAAAU AAAAd29yZC93ZWJTZXR0aW5ncy54bWyMzsFqwzAMxvF7Ye8QdF+d9TBKSFIooy/Q9QFcR2kMsWQk bd729DVsl916FJ/48e8PX2ltPlE0Mg3wsm2hQQo8RboNcHk/Pe+hUfM0+ZUJB/hGhcP4tOlLV/B6 RrP6qU1VSDsZYDHLnXMaFkxet5yR6jazJG/1lJvjeY4B3zh8JCRzu7Z9dYKrt1qgS8wKf1p5RCss UxYOqFpD0vrrJR8JxtrI2WKKP3hiOQoXRXFj7/61j3cAAAD//wMAUEsDBBQABgAIAAAAIQCHSeRi BgwAALyWAAASAAAAd29yZC9udW1iZXJpbmcueG1s7F3NbuPIEb4HyDsIAnTIYWT+6sdYz0K2JOwG m81iZ4KcaYkeExFFgaTt9R4XueQBcghyyil5g1ySvM0CyWleIdXdbLIpk2U21dLQnr6MR+wfkh+r ur+qrq7+4ssfwk3v3o+TINpe9M2h0e/521W0DrYfLvq/e798M+n3ktTbrr1NtPUv+o9+0v/y7S9/ 8cXD+fYuvPZjqNiDPrbJ+T0U36bp7vzsLFnd+qGXDKOdv4XCmygOvRR+xh/OQi/+w93uzSoKd14a XAebIH08swxj1M+6iS76d/H2POviTRis4iiJblLS5Dy6uQlWfvaHt4ib3Je1nEeru9DfpvSOZ7G/ gWeItsltsEt4b2Hb3uAVb3kn99hL3IcbXu9h1+Ru69h7AJzDDXvshyhe7+Jo5ScJXJ2zwrxH08Du nQFIushbNHmE8j35k4ResM27IeKx9/3zjzeEj3fG7n1GuipeBLB4C8LkXSdp7K3Sb+/CXunX1+uL vkGrbJNgDWX33gauzOz5eGzZ/TPSOLzbpME3/r2/ef+483kdenVDrrJaabjb8LJLe25cOeMRK9nc k4IA/vB7gcjHKa9sslog78swv7j2V0HoZV1Dy/f+D3nZIGsBl3+94r1s/JuUdbT7LiZPncI7Z395 HbhFH/6/i5KLvmNbpPpZUTHYkvcn/bBS+HHrbT9QVS1qZ73H7CbxMtqmCdRcQZfvg9BPet/6D73v o9CDLwcdBFvozfeSdJYEXnZD2hZuDM9PHhD+QE0Gj0k/xaHwDAf03WjX7RFy2ferQYiUiggVtY+L kKUKoeEgE++DxGhsGYgYkVIRpKL2cUGyVYDkDJk+HYSPOxoj+EztshCNJhzN4+LjqMDH/fivP71a hNyGCG2iBz/+xk9TP86xKI3Vo9eM0kgGJTYp0BkVVKoEEtWRQ4frE2ra2r/xgBRkmo3MZ+OGAOHT PcxnMFoPB85w4A4Ho+FgPBxMcnFrP8OZjsPHG84WRBJAi8XhW6h/3PFpcjzYhoOpCuTciZN9/Urk SHEJuaK+auSAnwjslhAq4Sc8g/CLkF3GsEpk93J05RpLKgltyK7pTGfzmVtQLripHNm92+3QQfR/ f/njz//+sxLaa1oTSntqWB0tFj/c50h8TcfCSAstFjH6TKmv6Y6pIVYnSqRYhOnzI7+mY9Jpqg6h 8WRcQuhzpL9dxahrBLirOHWJAp8Wo1dCgi1rig3jtFgcxjUJBjSoC9FybBchwbS4hFxnSDBzookk 2DIc1160J8FL0xoZI+sqty3gxTtLggtSW2W8kFLxsxW1VZsu2vcr5x3Xvt8GSwja9wt0G3FJad8v XfVCEOoa9e3mGkKXiO8pEXoltFegsVUkQPt+6cI48CAaECCunJsFja1Erru+XzY1irTXNq4mljmb MdoqH+jgGtYMIiV0oIMOdFAdCqLJria7B8cTabKrya6KuDRNdkmkIGIz6UCHVvGOOtCheaQoCKAQ y/BsoAMb+ktkl8SBuyzkpU2gw9XSMsaLqwMCHfAwn9x33D6ip/DVVpkmx/PsPpxfc1MpiyMJ9n4n P/ILEPNIg8CSH69I5DC1r9g1fIjRscFE5iVwzr5ECWce74UM5Zp4U+ItA7VFg8EezkWo2TVcpLWv Wgpl8+nAYdFrOMraCJAbOBime9LcAGftN2dbXE4h09ogkZoL24q0NmtqzBoZGWdBgOXxJA8MRIiI No7qjaPj4C9pYrEBv2RiTazL8dRctF1PMBxjahjmPDeFwECQC6M5vollYUFPDpTCMxcbJ/PaEsEz bF8mohldMoVM08EAmU7L0UTFUq1KQDpms5hTm/OlKjucxmmKUnIcUJRYF2a++SjXyfbuCWtsUuMf xplKXKZ722bGBo8fVyksSuyBAhfYlKUAGts1MJGxXLe8m2DiclNeJTRNKTw+yuYiw/arKUDHsSaY 4NgQfFkadk3T5vuzVMLTlHVLwQPb+RQg5BrobhR7Ant6xCHHtPLt7SoR6jZhdicuJkaOPd3btlds YFEJUueJ7WjkUC93zTjtmkZ5UjfHhprRSJKAMn0UCahjLRfu2JgxjZIPaDHN5eJyMc9c1GJqCpYl RDI1RXJ3cwNax2KIohSiRD7kul7aAW32enlB1fxKySCswPF8G16yCoKL/iwOIEkI3IGn2LjovwvC r/yA6voMkBHqoDk6hLA2GdvipM785mjCDHQgoLenAI8qTdkwtrkiIfS/FduVAg+2m78A/E7qdpfF D7brvwQIKeksi+DpfOoqMqwIVK/SpiBMUCQ+tsmntpopfX9oPcVI0NY/qYSvj36FTj0ZTBxc+JvP aEI+qc/6MzS1C57NFjPWGpGxpbYa0dYA+d4vUbtsZt69Sx83eco3j+mJOBMkO2/l5+ojUrqf//qf yiQtK8gPyJMFdZXVndpj3wh8TpYESl2P/n//9o/KRC+vC31Jc4nphmguuZZjuu48SyYkby7NZqMZ 7JstkhHB1CDnr99C3s9K/WFJX2a9vLDKLGo2NxGnPJLrUIXLnjCMT5DrcAaGjgKAiJO+HiAlLvwW ALUyc/ZTi2V+WgUgPZddgfiKyFvynJmtnPotYOqem98kfvx6eaLFIlKt3PwtkOqk45969uvBUuP4 bwGWEtOitEoCqesUqCH19dfjpWgpoAVgTY2AT7A4QL3/CGZqFgdaYNaWrYtEe7AvZMryI9L1gHrY FC0XtICt8wsIdIWgHjlFCwiNkJPkyAxakSOPbNeB9ZAsbaQ8R14unJFrzwqeBo8tx5FLI0bZJP3K 90gy/cyL94T8KBhvP9WWAvhuiAu8VQRMJXTFd3kyqChAr8iNyP1nYobVF5VEvBK9Iof4E/R0gvGL fklz97VTJxjH8dEJxuHAiGddxjrBOEdJJxincQYZF5A5T2QvYEsZgdZJZoDr0Y8iezzLy00yM6W5 20sEej5ZOpdXM0anqgn07eN1HKx/Q07aqTlTZ7JwZu7IWeSkTKDR8N90t1nB8To0fhwiKcmOp9KC TqVWXN9tNn6a9yhSmI8//TO/3t7zbENcYr0ZRErh0XOPYVEbX5p+9xheRzTsJ1ubFi5QJ7QQzPMc jd6HziZPlMIaFRxdRY7cUgBlpABI08iPRqki0rS4DZRX0V0c+DE5tYh+Chb1s39VDlQaG1eSR7on QC2oH3/6uwpYJ3ngXiWspLgNrL8Hm5TYpXDsGcg3A7V8TQ5SJpVlFVcup2pU3nLRI5FocRtIBR1n eAoX5MCk8TAl+eyo0tsWej4JLW4D5b56q1B6puKihHZW6e0pPiuR4jawlhX8cKWnZ2OV5JRugVA9 jqqY553i6IKqcZQWt4FU0PEDlZ5G/5fA7KjSQ4IWjDPR4jZQHkPp6YJvCdTOKv3IRKclWtwG1sOV XtJBbz49rhNO6nTGixFqYFCzo8a0mE9dOK2TiV05J3nToP8TnmD0ivzx+w5RspCngNS+Ip97FULa r6796gcdH6z96txjrA/ufOYYarr6oP3q2q/e8PzuzgemvFy/usk8saJjfbwwFvalkbnEqx3rGO9d jKzFcrIsOBcYAHKRKTp6+5CZeKaG777m6G0CkRrCq8O34di272KyMMZdVPAXNJ5tThe38unwbYJS M7B0+PZNtoDaDC8dvg0xPb4kZiQ+G1lG1uHbleOYDt/mo7uswHU6fBsCm+C94N/iOHshL/zXa/7S 4ChmOgNVyXheasf2lsm3Y5ut5NuxrUeV7XhGoqrHZJtw6ptRb/Vv7/0YgmfINuUn7F0oK4xY8LiD Y5EXEWyEn3kvQuQHr5pDmyErNKvrRdjEd0Avwh63A3oR9n8d0IuwMeqAXoTdQgf0IuyfOaAXwWpv 1AvIT5WwsleqFFZUF9lLyLdjjy3fjkWoybfLVp4qG1IbugaXzHKXb4cMUuj9kEGK78us+n4mMkjx DdSV7ZBRChuDIRckGTUqcaH7CurwRASG86TK50QEBm2HCAzWDhZca98PZAKZnNjQWwkM3hCRGLwh IjJ4Q0RmUGwQmUHbITKDPygiNHhDRGrwhojYYF8fMoDVig0GDaScbdeurdDYiNDwvK1VeggJmWof FG2HyAzaDpEZuquPjzPs77UfQ+Ti2/8DAAD//wMAUEsDBBQABgAIAAAAIQBj7omfmAEAAPICAAAQ AAgBZG9jUHJvcHMvYXBwLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJyS T0/cMBDF75X4DlHOJQ7QVgjNGlWLEAf+SRvgWFn2JLFwPJbt3bLfvpMNu5uqt+bkeTN5fv7ZcP0x uGKDMVnyi/KsqssCvSZjfbcoX5rb08uySFl5oxx5XJRbTOW1PPkCz5ECxmwxFWzh06Lscw5XQiTd 46BSxW3PnZbioDKXsRPUtlbjDen1gD6L87r+IfAjozdoTsPBsJwcrzb5f00N6TFfem22gQNLaHAI TmWUj2Mc9+uNotHkN5WhPIA4tKGhrFxjB5Q1y4cCnlWHSV6AmBYwGiT5/RtPTUtY9ioqnRmlvKgv WZ8J8DMEZ7XKTFk+WB0pUZuLpx2P4mmdHdE7iPkUMKYV6nW0eTtmmZdwbz2nYXVacLqouqhCvxNn Fay0crhkFrJVLiGIowBLGoLyW3m3Vr/RFg3q3pOjbrzTJVVf77Op+BifU+Om7+klNHQzgvy0+1uc QXizuV8FpaecRxYzHVaMDA2fbO92FOCOby66cUv+13do9jP/Nka6r9MTlmfnVc3fjuVe40s7vC35 BwAA//8DAFBLAwQUAAYACAAAACEA5mKWbJ0BAAAWAwAAEQAIAWRvY1Byb3BzL2NvcmUueG1sIKIE ASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnFLBitswEL0X+g9Cd0d2sluCSbTQLlkK XQg0paU3RZpk1bUloZmN139fyU7cDe2px5n35unN06zuXtuGnSCi9W7Nq1nJGTjtjXXHNf+22xRL zpCUM6rxDta8B+R38v27lQ619hG20QeIZAFZUnJY67DmT0ShFgL1E7QKZ4nhEnjwsVWUyngUQeln dQQxL8sPogVSRpESWbAIkyI/Sxo9SYaX2AwCRgtooAVHKKpZJf5wCWKL/xwYkDfM1lIf0k5nu2+1 jR7Bif2KdiJ2XTfrFoON5L8SPx6/fB1WLazLWWngcmV0TZYakA/F9vM9shOyreobrwzLryIzcLAO DLOO7dS+AVbdFkvmD+xhJabhLIMv+1+gSQ7tqUiAjqDIR7lJ2dkBvXTy7zxD3/loMM1dVWnQAOpo A6U/H1WvGondKKTHdAQHC+ZjL3EPjSdKb/yN5acinGw+IDkfGFOZ3A+Zj07TrinFesz8gnxffLrf bbicl9WiKG+L+XJX3dQ3y7osf+aVruZzqmOjPZv7b8WLwJjO9SXL3wAAAP//AwBQSwMEFAAGAAgA AAAhACdHPJQ4AwAAuhAAABIAAAB3b3JkL2ZvbnRUYWJsZS54bWzcV11P2zAUfZ+0/xDlfcQJLf0Q oYJC2TTBw1q0x8lNXWIptqPYofQf7WFP+wn8sl3bCf1KacMGaKQqpTfXrn187jk3x717ljh3JJNU 8ND1D5DrEB6JCeW3oXszGnxqu45UmE9wIjgJ3TmRbu/k44fjWXcquJIOjOeym4VurFTa9TwZxYRh eSBSwuHeVGQMK/ia3XpiOqURORdRzghXXoDQkZeRBCv4bRnTVLrFbLN9ZpuJbJJmIiJSwmJZYudj mHL3pFidM+tyzGDVI8qIdK7JzPkmGLYJKeZCEh9y7nASuiiA1xE6RE3UgHcA/zVcT88UxTiTRD0m IhueYkaTeRnNzLwmP6Uqisv4Hc4oHifEjpH0Fm7kcoxCF7aPgtN2y7URP3TbENFXEQlgUfaCMzCj Dh8jJicy85gUfzDQORCBeYpRZp2ePacNRE5hWYkBahOHM8ChYfDQmAS1cJAzKqXd7H+Bw5Cyz4Qa IHCiroEtAKMhhHj4+fAb3r96xXY2+OIDTgh44pcvm7jGl/aRDa/yhYkJybi9w4UaZTkZzVOySaAp vScTm7fMnuKM/QV7UBtd6Og6e/wyso09jXLU/uwZztlYVNOnCcXjA2l81AJ4AvjWqoQFBVWw1C+j Aohyk0B/vwitA/EITSUQy8W3PxB9kWeUZFpathRTCwjSMWWkRaVRq5iWSbJSTVtI8baS8h1kWPuG rESiWR7U4rMGL3CuhE1fwWG7upa/sqiP16QFqMowtzazpipGd50bTsFjiXM1LDb1T7VlAdaTyrIT vDcSlz5mY3CnShbpCmoWJq3Nup451VeXU82j4MKYK9g2qItRS9Q4q6culo6dmib9FdMR/XF5Fhz6 QSUcJcuXPiuL6j160NXQuaI8ioVB5pllplu+jml2muCf21q+9q6W78k62yLWxZmtFllLR9eptdPB te6bUfsb17lQOfsb5HSTqK8dzY9v+fjizU/HLqc2dMb29aj9oQPi3XxxLoWKafR8BA14q3+qS7eS e0tt9pPcq6nxr0u/fkxeAb93yMA+TihYpAFv8/FtYB5fzYNbbYdc4tWejVa1Qwao9TIOWTzPypM/ AAAA//8DAFBLAwQUAAYACAAAACEABD3Y1fYAAABsAQAAEwAIAWRvY1Byb3BzL2N1c3RvbS54bWwg ogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACckMtugzAQRfeV+g+W946NEeEhQ9RA su4i7d4yhiDhh2yHFlX99xqlj32XM3d05syww7uawSKdn4yuYbIjEEgtTD/psYYvlzMqIPCB657P RssartLDQ/P4wJ6dsdKFSXoQEdrX8BqCrTD24ioV97sY65gMxikeYulGbIZhErIz4qakDpgSssfi 5oNRyP7i4J1XLeG/yN6Izc6/XlYbdRv2DV/BoMLU1/Cjy9quy0iG6KlsUUKSIyrTMkekIIQeaXsu n06fENhtmEKguYqn+2HmY6QtoZrtmw+uSdJ9keS0zFOG/7oM/+xrGN5E7m9qvgAAAP//AwBQSwEC LQAUAAYACAAAACEA44D5jtwBAABeCgAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNd LnhtbFBLAQItABQABgAIAAAAIQCZVX4FBAEAAOECAAALAAAAAAAAAAAAAAAAABUEAABfcmVscy8u cmVsc1BLAQItABQABgAIAAAAIQCd+s6EYgEAAMMHAAAcAAAAAAAAAAAAAAAAAEoHAAB3b3JkL19y ZWxzL2RvY3VtZW50LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhACRa4T5aGAAATGwBABEAAAAAAAAA AAAAAAAA7gkAAHdvcmQvZG9jdW1lbnQueG1sUEsBAi0AFAAGAAgAAAAhAO0JhglWAQAAAwMAABAA AAAAAAAAAAAAAAAAdyIAAHdvcmQvaGVhZGVyMy54bWxQSwECLQAUAAYACAAAACEAmqLL/2sDAACz CgAAEAAAAAAAAAAAAAAAAAD7IwAAd29yZC9mb290ZXIyLnhtbFBLAQItABQABgAIAAAAIQDHlkqn VAEAAAMDAAAQAAAAAAAAAAAAAAAAAJQnAAB3b3JkL2Zvb3RlcjEueG1sUEsBAi0AFAAGAAgAAAAh AFhgsxu6AAAAIgEAABsAAAAAAAAAAAAAAAAAFikAAHdvcmQvX3JlbHMvaGVhZGVyMi54bWwucmVs c1BLAQItABQABgAIAAAAIQBrWacKEwUAAOURAAAQAAAAAAAAAAAAAAAAAAkqAAB3b3JkL2hlYWRl cjIueG1sUEsBAi0AFAAGAAgAAAAhAO0JhglWAQAAAwMAABAAAAAAAAAAAAAAAAAASi8AAHdvcmQv aGVhZGVyMS54bWxQSwECLQAUAAYACAAAACEARchkFGkBAACzAwAAEQAAAAAAAAAAAAAAAADOMAAA d29yZC9lbmRub3Rlcy54bWxQSwECLQAUAAYACAAAACEA58h/yWkBAAC5AwAAEgAAAAAAAAAAAAAA AABmMgAAd29yZC9mb290bm90ZXMueG1sUEsBAi0AFAAGAAgAAAAhAMeWSqdUAQAAAwMAABAAAAAA AAAAAAAAAAAA/zMAAHdvcmQvZm9vdGVyMy54bWxQSwECLQAUAAYACAAAACEAlrWt4pYGAABQGwAA FQAAAAAAAAAAAAAAAACBNQAAd29yZC90aGVtZS90aGVtZTEueG1sUEsBAi0ACgAAAAAAAAAhAMcZ /uonjQAAJ40AABYAAAAAAAAAAAAAAAAASjwAAHdvcmQvbWVkaWEvaW1hZ2UxLmpwZWdQSwECLQAU AAYACAAAACEA826wVe0GAABuEwAAEQAAAAAAAAAAAAAAAAClyQAAd29yZC9zZXR0aW5ncy54bWxQ SwECLQAUAAYACAAAACEA+10f6/YQAADRggAADwAAAAAAAAAAAAAAAADB0AAAd29yZC9zdHlsZXMu eG1sUEsBAi0AFAAGAAgAAAAhAErYipK7AAAABAEAABQAAAAAAAAAAAAAAAAA5OEAAHdvcmQvd2Vi U2V0dGluZ3MueG1sUEsBAi0AFAAGAAgAAAAhAIdJ5GIGDAAAvJYAABIAAAAAAAAAAAAAAAAA0eIA AHdvcmQvbnVtYmVyaW5nLnhtbFBLAQItABQABgAIAAAAIQBj7omfmAEAAPICAAAQAAAAAAAAAAAA AAAAAAfvAABkb2NQcm9wcy9hcHAueG1sUEsBAi0AFAAGAAgAAAAhAOZilmydAQAAFgMAABEAAAAA AAAAAAAAAAAA1fEAAGRvY1Byb3BzL2NvcmUueG1sUEsBAi0AFAAGAAgAAAAhACdHPJQ4AwAAuhAA ABIAAAAAAAAAAAAAAAAAqfQAAHdvcmQvZm9udFRhYmxlLnhtbFBLAQItABQABgAIAAAAIQAEPdjV 9gAAAGwBAAATAAAAAAAAAAAAAAAAABH4AABkb2NQcm9wcy9jdXN0b20ueG1sUEsFBgAAAAAXABcA wgUAAED6AAAAAA== --_002_B9FEE68CE3A78C41A2B3C67549A96F4802F129FR711WXCHMBA05zeu_-- From lberger@labn.net Tue May 28 08:48:45 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921FC21F9738 for ; Tue, 28 May 2013 08:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.965 X-Spam-Level: X-Spam-Status: No, score=-101.965 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_52=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDWg3dfXr5D5 for ; Tue, 28 May 2013 08:48:41 -0700 (PDT) Received: from oproxy14-pub.unifiedlayer.com (oproxy14-pub.unifiedlayer.com [67.222.51.224]) by ietfa.amsl.com (Postfix) with SMTP id 41B7421F9726 for ; Tue, 28 May 2013 08:48:41 -0700 (PDT) Received: (qmail 15245 invoked by uid 0); 28 May 2013 15:48:38 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy14.unifiedlayer.com with SMTP; 28 May 2013 15:48:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=U9l1js9CtqgJdRbYpWJdZlgrhezty8Ev7HBGNG5VkME=; b=IPBMgCtewcrHnEgUpiV8M1lkmms7B11rvFHBjAK7bYVzoINylP4jp/uV+WPnNnN8jabiSy5z58knFFELhy5k5j6oaOIj1JdaDl4QCCovgO3TF8pFo0IW3vvlor1ovmwb; Received: from box313.bluehost.com ([69.89.31.113]:42459 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UhM8c-0004ey-4V; Tue, 28 May 2013 09:48:38 -0600 Message-ID: <51A4D1D3.8040705@labn.net> Date: Tue, 28 May 2013 11:48:35 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "BELOTTI, SERGIO (SERGIO)" References: <518A82D9.7080508@labn.net> <51924382.2010904@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C90D5@ESESSMB301.ericsson.se> <13ea7ed3bdd.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <5193A26A.1090005@labn.net> <519649B4.5060408@labn.net> <519B73C9.2030308@labn.net> <519E406C.9030008@labn.net> <519F67ED.3040701@labn.net> <519F963C.9060305@labn.net> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" Subject: Re: [CCAMP] R: R: Closing Issue #49 (Was: Re: R: Closing G.709 open issues) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 15:48:46 -0000 Sergio, See below. Also, can you just put your comments/discussion points in mail rather than a word file? I don't think the use of word is providing any value in this context. On 5/28/2013 11:02 AM, BELOTTI, SERGIO (SERGIO) wrote: > Hi Lou, > > See below for my notes . > I attached the Fatai's doc for GPID mapping with possible suggested addon. > > Thanks > > Sergio > > Belotti Sergio- System Architect > ALCATE-LUCENT Optics Division > via Trento 30 Vimercate (MB) - Italy > phone +39 (039) 6863033 > > -----Messaggio originale----- > Da: Lou Berger [mailto:lberger@labn.net] > Inviato: venerdì 24 maggio 2013 18.33 > A: BELOTTI, SERGIO (SERGIO) > Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; Fatai Zhang > Oggetto: Re: R: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues) > > Sergio, > > > On 5/24/2013 11:54 AM, BELOTTI, SERGIO (SERGIO) wrote: >> Hi, >> >> Please take care anyway this solution does not consider two cases: >> >> G.7041 and G.709, defines respectively: >> >> 10GbE --> GFP-F (G.7041, Table 6-3: UPI=0x13 [ Frame-mapped 64B/66B encoded >> Ethernet, including the Ethernet frame preamble ]) > > Cool, yet another way to encode Ethernet over GFP. (Pointing to the > G.7041 UPI was very helpful, the draft will need to capture that!) What > PT is used for this? Are there other client types missing/that you > think are missing? > > SB> In G.7041 Table 6-3 - User payload identifiers for GFP client frames define the UPI values. > UPI is setup according to the transported signal type. > Here we can see there is another form of Ethernet mapping via GFP and ODU2 signals can carry diverse payloads including diverse GFP-F mapped Ethernet. > I think the best we can do would be to define GPID values for all possible/meaningful combinations of PT/UPI values where GFP is used to encapsulate the client signal. > > What I have indicated here are just two possible addon: one is already considered in the file provided by Fatai , the other is the one form G.7041. > Attached the doc from Fatai, updated (in yellow) with the new GFP Ethernet mapping possibility. Unless I misread it, you didn't propose any new G-PIDs. > > > My suggestion would be to define GPID values for all > possible/meaningful combinations of PT/UPI values where GFP is used > to encapsulate the client signal. > If you want to define additional types, please propose them! If there are no specifics, there's nothing for the WG to discuss/agree to. >> >> 10GbE--> extended OPU2/ODU2 (G.709, Table 15-8: PT=0x09 [ GFP mapping into Extended >> OPU2 payload, see clause 17.4.1 ]) > > Is this a different case? If yes, how so? (Do you have a data plane > reference?) > > SB> For ODU2 in OTN there is two possible PT options for 10GbE and are > PT= 0x05 (ODU2) | PT = 0x09 (extended ODU2) Okay, sounds like a new G-PID type (TBA12 below). So here's the updated table as I understand it: G.709 Payload Type G-PID Type/Comment LSP Encoding ==== ===== ============== =================== 0x01 No standard value 0x02 49 CBRa G.709 ODUk 0x03 50 CBRb G.709 ODUk 0x04 32 ATM G.709 ODUk 0x05 TBA1 Framed GFP G.709 ODUk 54 Ethernet MAC G.709 ODUk (framed GFP) TBA12 64B/66B GFP-F G.709 ODUk (k=2) Ethernet 0x06 ??? Is any valued needed? 0x07 55 Ethernet PHY G.709 ODUk (k=0) (transparent G.709 ODUk (k=3) GFP) G.709 ODUk (k=4) 0x08 58 Fiber Channel G.709 ODUk (k=2e) 0x09 TBA1 Framed GFP G.709 ODUk (k=2e) TBA12 64B/66B GFP-F G.709 ODUk (k=2e) Ethernet 0x0A TBA2 STM-1 G.709 ODUk (k=0) 0x0B TBA3 STM-4 G.709 ODUk (k=0) 0x0C 58 Fiber Channel G.709 ODUk (k=0) 0x0D 58 Fiber Channel G.709 ODUk (k=1) 0x0E 58 Fiber Channel G.709 ODUflex 0x0F 58 Fiber Channel G.709 ODUflex 0x10 51 BSOT G.709 ODUk 0x11 52 BSNT G.709 ODUk 0x12 TBA4 InfiniBand G.709 ODUflex 0x13 TBA4 InfiniBand G.709 ODUflex 0x14 TBA4 InfiniBand G.709 ODUflex 0x15 TBA5 Serial Digital G.709 ODUk (k=0) Interface 0x16 TBA6 Serial Digital G.709 ODUk (k=1) Interface/1.001 0x17 TBA5 Serial Digital G.709 ODUk (k=1) Interface 0x18 TBA6 Serial Digital G.709 ODUflex Interface/1.001 0x19 TBA5 Serial Digital G.709 ODUflex Interface 0x1A 56 SBCON/ESCON G.709 ODUk (k=0) (IANA to update Type field) 0x1B TBA7 DVB_ASI G.709 ODUk (k=0) 0x1C 58 Fiber Channel G.709 ODUk 0x20 47 G.709 ODU-2.5G G.709 ODUk (k=2,3) (IANA to update Type field) TBA8 G.709 ODU-1.25G G.709 ODUk (k=1,2,3) 0x21 TBA8 G.709 ODU-1.25G G.709 ODUk (k=2,3,4) TBA9 G.709 ODU-Any G.709 ODUk (k=2,3) 0x55 No standard value 0x66 No standard value 0x80-0x8F No standard value 0xFD TBA10 Null Test G.709 ODUk 0xFE TBA11 Random Test G.709 ODUk 0xFF No standard value What *specific* changes/additions do you think are needed? (Please add to this table and NOT the word file, once we have agreement on e-mail the result can be directly inserted into the draft.) Lou > > Thanks, > Lou > >> >> Please not that this is not the mapping using UPI=0x01 and PT=0x05 >> >> Best Regards >> >> Sergio >> >> Belotti Sergio- System Architect >> ALCATE-LUCENT Optics Division >> via Trento 30 Vimercate (MB) - Italy >> phone +39 (039) 6863033 >> -----Messaggio originale----- >> Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di Lou Berger >> Inviato: venerdì 24 maggio 2013 15.15 >> A: Fatai Zhang >> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >> Oggetto: Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues) >> >> Fatai, >> >> Just to be clear, the following covers your correction: >> >> G.709 >> Payload >> Type G-PID Type/Comment LSP Encoding >> ==== ===== ============== =================== >> 0x05 TBA1 Framed GFP G.709 ODUk >> 54 Ethernet MAC G.709 ODUk >> (framed GFP) >> >> Right? >> >> Thanks, >> Lou >> >> On 5/23/2013 9:01 PM, Fatai Zhang wrote: >>> Hi Lou, >>> >>> Fine, thanks for your explanation. >>> >>> As I said, I will update the signaling draft based on your proposal if there are no further comments. >>> >>> >>> >>> Best Regards >>> >>> Fatai >>> >>> >>> -----Original Message----- >>> From: Lou Berger [mailto:lberger@labn.net] >>> Sent: Friday, May 24, 2013 12:15 AM >>> To: Fatai Zhang >>> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>> Subject: Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues) >>> >>> Fatai, >>> Do we really need to reopen debate on a topic the WG discussed and >>> closed last summer? (i.e., to handle G.709 client adaptation just as we >>> do for every other technology.) >>> >>> I do agree that some new G-PID assignments were missed in the draft that >>> went to LC, but filling in the list doesn't automatically mean that the >>> WG needs to reopen debate on adaptation approaches. >>> >>> Assuming we don't need to reopen the pre-LC debate from last summer, and >>> with respect to the list I sent out, I do agree the WG needs to: >>> >>> A) Ensure that the list doesn't have unneeded new G-PIDs (i.e., reuses >>> the same/existing G-PIDs wherever possible.) >>> >>> B) Identifies the "right" G-PID per payload type, and doesn't have any >>> other technical errors >>> >>> C) Doesn't conflict with past WG decisions/discussions. >>> >>> >From your mails I see the following comment on (A): >>> >>>> For 0x05, why you think that RFC4328 does not cover it (ie., G-PID=54)? >>> >>> G-PID 54, per IANA, is currently defined as "Ethernet MAC (framed GFP)". >>> Per G.709, PT=0x05 maps to "GFP mapping, see clause 17.4" and looking >>> at 17.4 there is no restriction on what is carried in GFP frames. So it >>> seems that PT=0x05 can't be limited to just "Ethernet MAC (framed GFP)". >>> >>> Are you suggesting changing the type description of G-PID 54 to just >>> "Framed GFP", or including G-PID 54 as an additional possibility for >>> PT=0x05? >>> >>> The latter seems to be a valid addition/correction. The former may be >>> problematic for existing implementations, so we'll need to discuss more >>> broadly if that's the direction you want to head. >>> >>> All/ (WG), >>> >>> Again, please speak up if you think the above is not aligned with prior >>> consensus or if you have an issue with any of the above. >>> >>> Lou >>> >>> On 5/22/2013 10:35 PM, Fatai Zhang wrote: >>>> Hi Lou, >>>> >>>> >>>> >>>> I incorporated your proposal into my table to facilitate the readers. >>>> >>>> >>>> >>>> I think you still insist on reusing some existing G-PIDs like 58, 56. >>>> For 0x04, why you think that RFC4328 does not cover it (ie., G-PID=54)? >>>> >>>> >>>> >>>> Technically, I am not convince by your proposal, but I would like to >>>> reserve my opinion for your same motivation (ie., to conclude the >>>> discussion as soon as possible). >>>> >>>> >>>> >>>> Any opinions on Lou's proposal from the WG? I will update the signaling >>>> draft based on Lou's proposal if there is no comment on Lou's proposal. >>>> >>>> >>>> >>>> Note that all the new G-PID values will be re-ordered with TBA. >>>> >>>> >>>> >>>> *G-PIDs vs **Payload types defined in Table 15-8 of G.709* >>>> >>>> >>>> >>>> Payload Type in Hex codedefined in G.709 >>>> >>>> >>>> >>>> G-PID >>>> >>>> >>>> >>>> LSP Encoding >>>> >>>> >>>> >>>> Note >>>> >>>> >>>> >>>> Interpretationfrom G.709 >>>> >>>> 0x01 >>>> >>>> >>>> >>>> None >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Not needed >>>> >>>> >>>> >>>> Experimental mapping (Note 3) >>>> >>>> 0x02 >>>> >>>> >>>> >>>> 49 >>>> >>>> >>>> >>>> G.709 ODUk, G.709 OCh >>>> >>>> >>>> >>>> 1)G-PID defined in RFC4328; >>>> >>>> 2) Updated in this draft. >>>> >>>> >>>> >>>> Asynchronous CBR mapping, see clause 17.2 >>>> >>>> 0x03 >>>> >>>> >>>> >>>> 50 >>>> >>>> >>>> >>>> G.709 ODUk >>>> >>>> >>>> >>>> ditto >>>> >>>> >>>> >>>> Bit synchronous CBR mapping, see clause 17.2 >>>> >>>> 0x04 >>>> >>>> >>>> >>>> 32 >>>> >>>> >>>> >>>> SDH, G.709 ODUk >>>> >>>> >>>> >>>> ditto >>>> >>>> >>>> >>>> ATM mapping, see clause 17.3 >>>> >>>> 0x05 >>>> >>>> >>>> >>>> 54 >>>> >>>> or >>>> >>>> TBA (Suggested by Lou) >>>> >>>> >>>> >>>> G.709 ODUk (and SDH) >>>> >>>> >>>> >>>> >>>> >>>> G-PIDs defined in RFC4328 for framed GFP >>>> >>>> >>>> >>>> >>>> >>>> GFP mapping, see clause 17.4 >>>> >>>> 0x06 >>>> >>>> >>>> >>>> None >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Not needed and Not defined in RFC4328 >>>> >>>> >>>> >>>> Virtual Concatenated signal, see clause 18 (Note 5) >>>> >>>> 0x07 >>>> >>>> >>>> >>>> 61(TBA) >>>> >>>> Or55(Suggested by Lou) >>>> >>>> >>>> >>>> G.709 ODUk (k=0,3,4) >>>> >>>> >>>> >>>> Is being defined in this draft (new payload type defined in [G.709-2012]) >>>> >>>> >>>> >>>> PCS codeword transparent Ethernet mapping: >>>> >>>> * 1000BASE-X into OPU0, see clauses 17.7.1 and 17.7.1.1 >>>> >>>> * 40GBASE-R into OPU3, see clauses 17.7.4 and 17.7.4.1 >>>> >>>> * 100GBASE-R into OPU4, see clauses 17.7.5 and 17.7.5.1 >>>> >>>> 0x08 >>>> >>>> >>>> >>>> 62(TBA) >>>> >>>> Or58(Suggested by Lou) >>>> >>>> >>>> >>>> G.709 ODUk (k=2e) >>>> >>>> >>>> >>>> ditto >>>> >>>> >>>> >>>> FC-1200 into OPU2e mapping, see clause 17.8.2 >>>> >>>> 0x09 >>>> >>>> >>>> >>>> 63(TBA) >>>> >>>> >>>> >>>> G.709 ODUk (k=2) >>>> >>>> >>>> >>>> ditto >>>> >>>> >>>> >>>> GFP mapping into Extended OPU2 payload, see clause 17.4.1 (Note 6) >>>> >>>> 0x0A >>>> >>>> >>>> >>>> 64(TBA) >>>> >>>> >>>> >>>> G.709 ODUk (k=0) >>>> >>>> >>>> >>>> ditto >>>> >>>> >>>> >>>> STM-1 mapping into OPU0, see clause 17.7.1 >>>> >>>> 0x0B >>>> >>>> >>>> >>>> 65(TBA) >>>> >>>> >>>> >>>> G.709 ODUk (k=0) >>>> >>>> >>>> >>>> ditto >>>> >>>> >>>> >>>> STM-4 mapping into OPU0, see clause 17.7.1 >>>> >>>> 0x0C >>>> >>>> >>>> >>>> 66(TBA) >>>> >>>> Or58(Suggested by Lou) >>>> >>>> >>>> >>>> G.709 ODUk (k=0) >>>> >>>> >>>> >>>> ditto >>>> >>>> >>>> >>>> FC-100 mapping into OPU0, see clause 17.7.1 >>>> >>>> 0x0D >>>> >>>> >>>> >>>> 67(TBA) >>>> >>>> Or58(Suggested by Lou) >>>> >>>> >>>> >>>> G.709 ODUk (k=1) >>>> >>>> >>>> >>>> ditto >>>> >>>> >>>> >>>> FC-200 mapping into OPU1, see clause 17.7.2 >>>> >>>> 0x0E >>>> >>>> >>>> >>>> 68(TBA) >>>> >>>> Or58(Suggested by Lou) >>>> >>>> >>>> >>>> G.709 ODUflex >>>> >>>> >>>> >>>> ditto >>>> >>>> >>>> >>>> FC-400 mapping into OPUflex, see clause 17.9 >>>> >>>> 0x0F >>>> >>>> >>>> >>>> 69(TBA) >>>> >>>> Or58(Suggested by Lou) >>>> >>>> >>>> >>>> G.709 ODUflex >>>> >>>> >>>> >>>> ditto >>>> >>>> >>>> >>>> FC-800 mapping into OPUflex, see clause 17.9 >>>> >>>> 0x10 >>>> >>>> >>>> >>>> 51 >>>> >>>> >>>> >>>> G.709 ODUk >>>> >>>> >>>> >>>> 1)G-PID defined in RFC4328; >>>> >>>> 2) Updated in this draft. >>>> >>>> >>>> >>>> Bit stream with octet timing mapping, see clause 17.6.1 >>>> >>>> 0x11 >>>> >>>> >>>> >>>> 52 >>>> >>>> >>>> >>>> G.709 ODUk >>>> >>>> >>>> >>>> ditto >>>> >>>> >>>> >>>> Bit stream without octet timing mapping, see clause 17.6.2 >>>> >>>> 0x12 >>>> >>>> >>>> >>>> 70(TBA) >>>> >>>> >>>> >>>> G.709 ODUflex >>>> >>>> >>>> >>>> Is being defined in this draft (new payload type defined in [G.709-2012]) >>>> >>>> >>>> >>>> IB SDR mapping into OPUflex, see 17.9 >>>> >>>> 0x13 >>>> >>>> >>>> >>>> 71(TBA) >>>> >>>> >>>> >>>> G.709 ODUflex >>>> >>>> >>>> >>>> ditto >>>> >>>> >>>> >>>> IB DDR mapping into OPUflex, see 17.9 >>>> >>>> 0x14 >>>> >>>> >>>> >>>> 72(TBA) >>>> >>>> >>>> >>>> G.709 ODUflex >>>> >>>> >>>> >>>> ditto >>>> >>>> >>>> >>>> IB QDR mapping into OPUflex, see 17.9 >>>> >>>> 0x15 >>>> >>>> >>>> >>>> 73(TBA) >>>> >>>> >>>> >>>> G.709 ODUk (k=0) >>>> >>>> >>>> >>>> ditto >>>> >>>> >>>> >>>> SDI mapping into OPU0, see 17.7.1 >>>> >>>> 0x16 >>>> >>>> >>>> >>>> 74(TBA) >>>> >>>> >>>> >>>> G.709 ODUk (k=1) >>>> >>>> >>>> >>>> ditto >>>> >>>> >>>> >>>> (1.485/1.001) Gbit/s SDI mapping into OPU1, see 17.7.2 >>>> >>>> 0x17 >>>> >>>> >>>> >>>> 75(TBA) >>>> >>>> >>>> >>>> G.709 ODUk (k=1) >>>> >>>> >>>> >>>> ditto >>>> >>>> >>>> >>>> 1.485 Gbit/s SDI mapping into OPU1, see 17.7.2 >>>> >>>> 0x18 >>>> >>>> >>>> >>>> 76(TBA) >>>> >>>> >>>> >>>> G.709 ODUflex >>>> >>>> >>>> >>>> ditto >>>> >>>> >>>> >>>> (2.970/1.001) Gbit/s SDI mapping into OPUflex, see 17.9 >>>> >>>> 0x19 >>>> >>>> >>>> >>>> 77(TBA) >>>> >>>> >>>> >>>> G.709 ODUflex >>>> >>>> >>>> >>>> ditto >>>> >>>> >>>> >>>> 2.970 Gbit/s SDI mapping into OPUflex, see 17.9 >>>> >>>> 0x1A >>>> >>>> >>>> >>>> 78(TBA) >>>> >>>> Or56(Suggested by Lou) >>>> >>>> >>>> >>>> G.709 ODUk (k=0) >>>> >>>> >>>> >>>> ditto >>>> >>>> >>>> >>>> SBCON/ESCON mapping into OPU0, see 17.7.1 >>>> >>>> 0x1B >>>> >>>> >>>> >>>> 79(TBA) >>>> >>>> >>>> >>>> G.709 ODUk (k=0) >>>> >>>> >>>> >>>> ditto >>>> >>>> >>>> >>>> DVB_ASI mapping into OPU0, see 17.7.1 >>>> >>>> 0x20 >>>> >>>> >>>> >>>> 47 >>>> >>>> >>>> >>>> G.709 ODUk >>>> >>>> >>>> >>>> 1) G-PIDs defined in RFC4328. >>>> >>>> 2) Updated in this draft. >>>> >>>> >>>> >>>> ODU multiplex structure supporting ODTUjk only, see clause 19 (AMP only) >>>> >>>> 0x21 >>>> >>>> >>>> >>>> 59/60(TBA) >>>> >>>> >>>> >>>> G.709 ODUk >>>> >>>> >>>> >>>> 1)Are being defined in this draft (new payload type defined in >>>> [G.709-2012]); >>>> >>>> 2) 59 for G.709 ODU-1.25G; 60 for G.709 ODU-any >>>> >>>> >>>> >>>> ODU multiplex structure supporting ODTUk.ts or ODTUk.ts and ODTUjk, see >>>> clause 19 (GMP capable) (Note 7) >>>> >>>> 55 >>>> >>>> >>>> >>>> None >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Not needed >>>> >>>> >>>> >>>> Not available (Note 2) >>>> >>>> 66 >>>> >>>> >>>> >>>> None >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Not needed >>>> >>>> >>>> >>>> Not available (Note 2) >>>> >>>> 80-8F >>>> >>>> >>>> >>>> None >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Not needed >>>> >>>> >>>> >>>> Reserved codes for proprietary use (Note 4) >>>> >>>> FD >>>> >>>> >>>> >>>> None >>>> >>>> OrTBA(Suggested by Lou) >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Not needed >>>> >>>> >>>> >>>> NULL test signal mapping, see clause 17.5.1 >>>> >>>> FE >>>> >>>> >>>> >>>> None >>>> >>>> OrTBA(Suggested by Lou) >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Not needed >>>> >>>> >>>> >>>> PRBS test signal mapping, see clause 17.5.2 >>>> >>>> FF >>>> >>>> >>>> >>>> None >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Not needed >>>> >>>> >>>> >>>> Not available (Note 2) >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Best Regards >>>> >>>> >>>> >>>> Fatai >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf >>>> Of Lou Berger >>>> Sent: Tuesday, May 21, 2013 9:17 PM >>>> To: CCAMP >>>> Cc: draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>> Subject: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues) >>>> >>>> >>>> >>>> All, >>>> >>>> >>>> >>>> In the interest of moving this discussion quickly to closure, I spent >>>> >>>> some time trying to come up with the full list of G.709 PT to G-PID >>>> >>>> mappings. In coming up with this list I tried to be consistent with >>>> >>>> the last consensus point that I can identify on this topic (the >>>> >>>> previously referenced July 2012 thread & presentation), which included: >>>> >>>> >>>> >>>> A) Defining new G-PIDs for client types not identified by an assigned >>>> >>>> G-PID (per >>>> >>>> http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parameters.xml) >>>> >>>> >>>> >>>> B) Reusing G-PID wherever {G-PID, ODU rate} unambiguously identify a >>>> >>>> G.709 payload type, and define new G-PIDs when reuse not possible. >>>> >>>> >>>> >>>> C) No G-PID value for unused, reserved, or proprietary 709 Payload Type. >>>> >>>> >>>> >>>> Here's what I've come up with: >>>> >>>> >>>> >>>> G.709 >>>> >>>> Payload >>>> >>>> Type G-PID Type/Comment LSP Encoding >>>> >>>> ==== ===== ============== =================== >>>> >>>> 0x01 No standard value >>>> >>>> 0x02 49 CBRa G.709 ODUk >>>> >>>> 0x03 50 CBRb G.709 ODUk >>>> >>>> 0x04 32 ATM G.709 ODUk >>>> >>>> 0x05 TBA1 Framed GFP G.709 ODUk >>>> >>>> 0x06 ??? Is any valued needed? >>>> >>>> 0x07 55 Ethernet PHY G.709 ODUk (k=0) >>>> >>>> (transparent G.709 ODUk (k=3) >>>> >>>> GFP) G.709 ODUk (k=4) >>>> >>>> 0x08 58 Fiber Channel G.709 ODUk (k=2e) >>>> >>>> 0x09 TBA1 Framed GFP G.709 ODUk (k=2e) >>>> >>>> 0x0A TBA2 STM-1 G.709 ODUk (k=0) >>>> >>>> 0x0B TBA3 STM-4 G.709 ODUk (k=0) >>>> >>>> 0x0C 58 Fiber Channel G.709 ODUk (k=0) >>>> >>>> 0x0D 58 Fiber Channel G.709 ODUk (k=1) >>>> >>>> 0x0E 58 Fiber Channel G.709 ODUflex >>>> >>>> 0x0F 58 Fiber Channel G.709 ODUflex >>>> >>>> 0x10 51 BSOT G.709 ODUk >>>> >>>> 0x11 52 BSNT G.709 ODUk >>>> >>>> 0x12 TBA4 InfiniBand G.709 ODUflex >>>> >>>> 0x13 TBA4 InfiniBand G.709 ODUflex >>>> >>>> 0x14 TBA4 InfiniBand G.709 ODUflex >>>> >>>> 0x15 TBA5 Serial Digital G.709 ODUk (k=0) >>>> >>>> Interface >>>> >>>> 0x16 TBA6 Serial Digital G.709 ODUk (k=1) >>>> >>>> Interface/1.001 >>>> >>>> 0x17 TBA5 Serial Digital G.709 ODUk (k=1) >>>> >>>> Interface >>>> >>>> 0x18 TBA6 Serial Digital G.709 ODUflex >>>> >>>> Interface/1.001 >>>> >>>> 0x19 TBA5 Serial Digital G.709 ODUflex >>>> >>>> Interface >>>> >>>> 0x1A 56 SBCON/ESCON G.709 ODUk (k=0) >>>> >>>> (IANA to update Type field) >>>> >>>> 0x1B TBA7 DVB_ASI G.709 ODUk (k=0) >>>> >>>> 0x1C 58 Fiber Channel G.709 ODUk >>>> >>>> 0x20 47 G.709 ODU-2.5G G.709 ODUk >>>> >>>> (k=2,3) >>>> >>>> (IANA to update Type field) >>>> >>>> TBA8 G.709 ODU-1.25G G.709 ODUk >>>> >>>> (k=1,2,3) >>>> >>>> 0x21 TBA8 G.709 ODU-1.25G G.709 ODUk >>>> >>>> (k=2,3,4) >>>> >>>> TBA9 G.709 ODU-Any G.709 ODUk >>>> >>>> (k=2,3) >>>> >>>> 0x55 No standard value >>>> >>>> 0x66 No standard value >>>> >>>> 0x80-0x8F No standard value >>>> >>>> 0xFD TBA10 Null Test G.709 ODUk >>>> >>>> 0xFE TBA11 Random Test G.709 ODUk >>>> >>>> 0xFF No standard value >>>> >>>> >>>> >>>> Note that there are a few differences with Fatai's list, which doesn't >>>> >>>> format well in e-mail, but is available in the archive >>>> >>>> http://www.ietf.org/mail-archive/web/ccamp/current/msg14845.html >>>> >>>> >>>> >>>> Please speak up if you think the above is not aligned with prior >>>> >>>> consensus or if you have an issue with any of the above. >>>> >>>> >>>> >>>> Much thanks, >>>> >>>> Lou >>>> >>>> >>>> >>>> >>>> >>>> On 5/20/2013 5:09 AM, Fatai Zhang wrote: >>>> >>>>> Hi Lou, >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> I think my mail on March 13rd may have answered your following comments. >>>> >>>>> My response quoted as follows. >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> In addition, if people look at the full list that I provided, I think >>>> >>>>> people can realize that RFC4328 (section 3.1.3) used the same approach >>>> >>>>> as the current approach of this draft (ie., 1:1 mapping between GPIDs >>>> >>>>> and payload types defined by G.709), ie., we are following what RFC4328 >>>> >>>>> did. >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> BTW, I am not sure if we need spend so much on discussing this point >>>> >>>>> (because there is no issue to stick to the data plane by using the >>>> >>>>> current approach of this draft). >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> ====================================================================================================================== >>>> >>>>> >>>> >>>>> (2) 'Grouped GPID' vs '1:1' mapping (between G.709-2012 and GPIDs >>>> >>>>> defined in this draft) >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> We realize that it is safe to use 1:1 mapping approach to avoid some >>>> >>>>> potential issues after investigation. We know this payload types have >>>> >>>>> been defined by G.709 (data plane), so physically it is better to use >>>> >>>>> 1:1 mapping approach. >>>> >>>>> >>>> >>>>> For the potential issues I mentioned above, for example, we cannot use >>>> >>>>> the existing 34 to represent 'STM-1' and 'STM-4 ', because it is >>>> >>>>> impossible to differentiate which one is 'STM-1' or 'STM-4'. In >>>> >>>>> addition, from the concept of payload type, we know that e.g, FC-100 is >>>> >>>>> different from FC-800, right? So, it is better to assign different GPIDs >>>> >>>>> to these different payload types defined by the data plane. >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> Furthermore, I think it is much cheaper to create new GPIDs in the >>>> >>>>> control plane than in the data plane (these payload types will be >>>> >>>>> carried in the OH). >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> Best Regards >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> Fatai >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> -----Original Message----- >>>> >>>>> From: Lou Berger [mailto:lberger@labn.net] >>>> >>>>> Sent: Friday, May 17, 2013 11:16 PM >>>> >>>>> To: Fatai Zhang >>>> >>>>> Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; >>>> >>>>> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>> >>>>> Subject: Re: R: Closing G.709 open issues >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> Fatai, >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> That's a great start for the WG. Thank you. >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> To answer your implied question as to why my request for the full list. >>>> >>>>> >>>> >>>>> My feeling is that there have been too many "surprises" on the 709 >>>> >>>>> >>>> >>>>> documents in areas that I thought were either obvious (but from the IETF >>>> >>>>> >>>> >>>>> & GMPLS context, not ITU-T or G.709 perspectives) or resolved by past >>>> >>>>> >>>> >>>>> discussions. At this point, as co-chair and Document shepherd, I want >>>> >>>>> >>>> >>>>> to ensure that any open point on the documents are unambiguously closed >>>> >>>>> >>>> >>>>> and that past discussions (i.e., points of consensus) are 100% captured, >>>> >>>>> >>>> >>>>> so that we can smoothly move through the planned second LC and >>>> >>>>> >>>> >>>>> publication request. >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> To that end, in my previous message I asked two questions about points >>>> >>>>> >>>> >>>>> where it seems you are proposing moving away from what has been >>>> >>>>> >>>> >>>>> previously been discussed & agreed to by the WG. Can you answer the >>>> >>>>> >>>> >>>>> following: >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>>>> My questions on the new G-PIDs come down to: >>>> >>>>> >>>> >>>>>>> - Why are rate specific G-PIDs being proposed (rather than >>>> >>>>> >>>> >>>>>>> continuing to use the previous approach documented in the draft >>>> >>>>> >>>> >>>>>>> and in Section 3.1.3 of rfc4328)? >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>>>> - Why are new values being defined rather than using existing >>>> >>>>> >>>> >>>>>>> values, e.g., G-PID 56? >>>> >>>>> >>>> >>>>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> Much thanks, >>>> >>>>> >>>> >>>>> Lou >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>> _______________________________________________ >>>> >>>> CCAMP mailing list >>>> >>>> CCAMP@ietf.org >>>> >>>> https://www.ietf.org/mailman/listinfo/ccamp >>>> >>> >>> >>> >>> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> From lberger@labn.net Tue May 28 08:54:56 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE6E821F974C for ; Tue, 28 May 2013 08:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.908 X-Spam-Level: X-Spam-Status: No, score=-100.908 tagged_above=-999 required=5 tests=[AWL=-1.057, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jf0R3MjQBdbK for ; Tue, 28 May 2013 08:54:45 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 7522221F9802 for ; Tue, 28 May 2013 08:54:45 -0700 (PDT) Received: (qmail 7663 invoked by uid 0); 28 May 2013 15:54:20 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy6.bluehost.com with SMTP; 28 May 2013 15:54:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=6ZTFss1f43hmrVNM+eBbL/HWGFPRRz3amEcOsk01EWo=; b=WbIlqdt9p1cTjhcDfe7IIrSqzH8bEmmD5wX+j9h7/NnBQ/9jRXK2CTZxVAW8dNId/aMjAQsukEEIYOpzKrat58O/jSiEzDEk4zPDDl2Wa5lDHa10aoMmpcZBgKFVv63l; Received: from box313.bluehost.com ([69.89.31.113]:43288 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UhME7-0000BC-KH for ccamp@ietf.org; Tue, 28 May 2013 09:54:20 -0600 Message-ID: <51A4D329.6070806@labn.net> Date: Tue, 28 May 2013 11:54:17 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: CCAMP References: <04ae01ce57f1$a6b72b80$f4258280$@olddog.co.uk> In-Reply-To: <04ae01ce57f1$a6b72b80$f4258280$@olddog.co.uk> X-Enigmail-Version: 1.5.1 X-Forwarded-Message-Id: <04ae01ce57f1$a6b72b80$f4258280$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: [CCAMP] Fwd: [mpls] AD review of draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 15:54:57 -0000 All, You may be interested in this MPLS WG draft and thread (http://www.ietf.org/mail-archive/web/mpls/current/msg10001.html). Discussion should take place on the MPLS list (not here/CCAMP please.) Lou -------- Original Message -------- Subject: [mpls] AD review of draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp Date: Thu, 23 May 2013 21:11:02 +0100 From: Adrian Farrel Reply-To: adrian@olddog.co.uk To: CC: mpls@ietf.org, mpls-chairs@tools.ietf.org Hi, I have done my usual AD review of this draft on receipt of the publication request from the MPLS WG chairs. As well as the desire to remove issues that might otherwise show up during IETF last call and IESG review (thereby saving resources), my review is to make sure that I understand the intention and details of the work so that I can support the document as it goes through these later reviews and also the publication process. As you will see from my comments below, I am not currently comfortable with the document. At the moment I am not saying that the proposals are bad and dangerous, although I am at least believing them to be unnecessary and based on some misstatements of the problems that need to be addressed. I understand that the chairs report there is WG consensus behind this document in its current form, but I am unable to support it for publication as an RFC. You have two options open to you to advance your work as a standards track RFC. Firstly, you could seek to address my concerns through a combination of changes to the text and discussions with me. Secondly, you can attempt to find another AD to sponsor the work - possibly Stewart is a good starting point. For the moment, I am returning the I-D to the working group. Thanks, Adrian --- Was this document shown to the CCAMP working group? The P2MP work (4875) was developed in partnership with CCAMP because it was intended to be equally applicable to MPLS-TE and GMPLS. Presumably this is also true of this work. You might find that by consulting CCAMP you are able to get some more P2MP implementers to have a look at the problems this draft is proposing to solve. --- I am surprised that the working group has taken this approach to the described problem of re-merge avoidance. This problem is addressed by the combination of PCE and Path Keys. However, if the working group has considered that approach and has consensus to take this other approach, I will not object. Could the chairs confirm that the existing mechanisms have been considered and that the WG determined to add new extensions to the signaling protocols instead. --- I'm afraid I find myself wondering whether this document is addressing the wrong problem :-( Re-merge is a bad thing to have as a persistent situation, and certainly must not be allowed to cause data duplication downstream of the re-remerge point. However, avoiding re-merge by selecting disjoint paths is not the solution. If re-merge happens, it is because the path to one set of destinations has intersected the path to another set of destinations. When this happens, one of the two paths to the re-merge point must be optimal (for *any* definition of optimal) or the paths are equally optimal. In either case, the correct solution is to move all of the destinations (the union of the two sets) onto the same path and prune out the sub-optimal one. In this case, the bottom line will be that the upstream branch was wrong to use two distinct domain border nodes for the two sets of destinations. That is the problem that needs to be fixed. What I seem to be reading here is an attempt to avoid re-merge that favors the use of suboptimal paths. In many network configurations that will be impossible. But in any case, it will prove as costly in terms of network resources as the re-merge itself. The discussion about re-optimization using 4736, is a different problem that you can raise. The description of the problem doesn't really surface until the description of the solution in Section 1.1, which is a pity. This is largely a descriptive issue, although I would argue that the partial reomptimization is easily handled using partial resignaling, and therefore without any protocol extensions. --- Please fix the minor spacing not reported by idnits. --- idnits shows several problems with references. You are missing RFC 2119 from the normative references. You are missing RFC 4874 from the informative references. You are missing RFC 2205 from the normative references. RFC 4726 is an informative reference, but not cited. Possibly work it into the 4th para of the Introduction? RFC 5920 is a downref. Does it need to be a normative reference? RFC 4736 is a downref. It appears that you are using it in a normative way - please confirm this so that we can handle the downref correctly. Document Shepherd - please update the write-up to correctly note the downrefs that remain after this work. --- Please remove citations from the Abstract. The Abstract is stand-alone text and cannot have external references. --- The Abstract is not clear and needs work. - The issues *may* arise, but do not always arise - The "computation of loosely routed inter-domain P2MP-TE LSP paths that are re-merge free" is not an issue and is not addressed in this document. Please describe the actual issue you are addressing. - s/vs./versus/ - I don't think "the loosely routing domain ingress border node is not aware of the reoptimization scope" describes a problem well because the issue is the "there is no way to indicate which branches of the P2MP tree are to be reoptimised". - In the light of my observation that techniques already exist to address the problems described in this document, it may be too strong to say "This document defines the required protocol extensions needed for ..." Maybe change this to "This document defines signaling protocol extensions for..." --- It would really help the reader and reviewers if someone could take an editorial pass on the document. This is not so much a problem of English usage as missing words and such like. A native speaker would clean it up very quickly and avoid the risk of the RFC Editor accidentally breaking the technical content. --- In the Introduction... Consequently one of the requirements for signaling P2MP LSPs is to choose a P2MP path that is re-merge free. Is this a signaling requirement? 1. Surely it is a path computation requirement, if it is a requirement at all. 2. Isn't the point that signaling is supposed to detect and resolve re-merge issues rather than avoid them? --- In the Introduction... For the purposes of this document, a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include Interior Gateway Protocol (IGP) areas and Autonomous Systems (ASes). A border node is a node between different routing domains. "domain" or "routing domain"? --- In the Introduction... In that case, the border node for a new domain will be given loose next hops for one or more destinations in a P2MP LSP. s/will be/may be/ ? --- In the Introduction... A border node can ensure that it computes the re-merge free paths while performing loose hop ERO expansions by individually grafting destinations. Note that the computed P2MP tree by a border node in this case may not be optimal. Why are you suggesting a mechanism for computing paths? That is an implementation detail. Furthermore, suggesting a mechanism that is almost certain to generate a suboptimal solution seems perverse! --- In the Introduction... In that case, existing protocol mechanisms do not provide sufficient information for it to be able to expand the loose hop(s) such that the overall P2MP LSP tree is guaranteed to be re-merge free. Weeeeell... Even if you don't want to use PCE and Path Key, you could use RRO and XRO with suitable staggered processing at the branch node. That would provide sufficient information using existing protocol elements, although a small (but obvious) piece of processing needs to added at the branch node --- In the Introduction... [RFC4875] specifies two approaches to handle re-merge conditions. The first method is based on control plane handling the re-merge. In this case the node detecting the re-merge condition, i.e. the re-merge node initiates the removal of the re-merge sub-LSP(s) by sending a PathErr message(s) towards the ingress node. However, this can lead to a deadlock in setting up the P2MP LSP in certain cases; for example, when the first S2L setup causes the re-merge with all subsequent S2Ls in the tree. I am glad you are now discussing the mechanisms in 4875, but I disagree that there is a deadlock condition as you claim. You are saying that if the first S2L sub-LSP takes a route that causes all other S2L sub-LSPs to re-merge then there will be deadlock. Far from it! What will happen is that a PathErr will be sent for each subsequent S2L sub-LSP stating "re-merge", and the destinations for each subsequent S2L sub-LSP will be added to the set of destinations in the first S2L sub-LSP. So, what is the issue with the first mechanism in 4875? --- In the Introduction... [RFC4736] defines procedures and signaling extensions for reoptimizing an inter-domain P2P LSP. Specifically, an ingress node sends a "path re-evaluation request" to a border node by setting a flag (0x20) in SESSION_ATTRIBUTES object in a Path message. A border node sends a PathErr code 25 (notify error defined in [RFC3209]) with sub-code 6 to indicate "preferable path exists" to the ingress node. The ingress node upon receiving this PathErr may initiate reoptimization of the LSP. [RFC4736] however does not define a procedure to reoptimize the entire P2MP LSP as a whole tree. I'm afraid that the mechanism you have accurately described could be used precisely as specified for reoptimising the whole tree since such reoptimization takes place from the ingress node. But I think (from 1.1) that you are trying to describe the subtleties involved in reoptimizing only some parts of the tree downstream of the reporting border node. Firstly, you need to clarify the problem being addressed with clearer text in the Introduction. Then you need to decide why you need to address the problem. In 4736 there is no distinction made about which of the loose hops should be reomptimised and which not. So it is unclear why you should want to apply such a filter in the case of a P2MP LSP. If there is a reason it would be good to set it out in more detail. It is also possible that the ingress will want to dampen its activity to ensure is receives all 25/6 reports before starting reoptimization. It is also possible that if you ignore the way 4875 handles remerge, this could get complicated. --- In the Introduction... The Sub-Group-Based reoptimization is not always applicable because it can lead to data duplication inside the backbone. I am suspicious of this statement! Are you saying that the remerge issues may give rise to data duplication? Or is it the make-before- break nature that may cause the problem? Is it a transitory problem during the one or two seconds of signaling change, or is it a long-term problem? If you want to persist with this assertion then you need to substantiate it in the draft. --- The comparison in Section 1.1 of re-merge "avoidance" with crankback is interesting, but the two issues are different. Crankback is designed to facilitate re-route to avoid blocking resources, while re-merge avoidance is about moving destinations from one sub-tree to another. But, you could consider the PathErr mechanism of 4875 as crankback because it reports the error relating to the re-merge node, it unpicks the LSP setup, and it allows an upstream node to "correct" the issue. The only thing that you might want to add to 4875 is the replacement of the ID of the reporting node with the ID of the reporting domain so that the upstream node can apply meaning to the PathErr. Maybe if the problem was clearly described, this solution would stand out. --- Section 1.3 says that this work is limited to "multiple routing domains that belong to a single administrative area. Use case for the Multiple administrative domains (e.g. autonomous systems) is outside the scope of this document." A couple of points: - An "administrative area" is a new term and the next sentence uses "administrative domains" so that is probably what you mean. - It is unclear whether multiple ASes is in scope since the second sentence appears to rule them out, but multiple ASes may be under the care of one administrator. - You haven't given any reason for excluding multiple administrative domains, and that would help people understand what your objectives are and what the problems are. --- Section 3 It is RECOMMENDED that boundary re-routing is requested for P2MP LSPs The use of upper case "RECOMMENDED" is equivalent to "SHOULD". This is usually protocol requirements language. Anyway, if you use "SHOULD" you also need to discuss the associated "MAY". --- In Section 3.1 you recommend that the ingress node of a P2MP LSP selects the same ingress border node in the loose hop ERO for all sibling S2L sub-LSPs that transit through a given domain. This, of course, produces sub-optimal LSPs and can be resolved using PCE. But I am interested in the overlap between this statement and the scope statement in 1.3. You are recommending using only single attachments between domains: that means that remerge can only happen when the sub- LSPs transit different domains and come back together in a further domain. But since you are (apparently) limiting to IGP areas and ruling out ASes, the largest domain diameter you have is 3 with the result that remerge is entirely impossible! --- In Section 3.1 you have "RECOMMENDED". What is the associated "MAY"? --- Here's another example from Section 3.2 If an ingress border node on the path of the P2MP LSP is unable to find a route that can supply the required resources or that is re- merge free, it MUST generate a PathErr message for the subset of the S2L sub-LSPs which it is not able to route. This implies that the border node is trying to find a disjoint path. Such a path represents a waste of network resources that is *worse* than the data plane remerge case that you reject as a bad idea. The point of re-merge avoidance is simply moving destinations from one sub-tree to another and it can only be done at the branch point for the two trees - or even at the ingress depending on your signaling approach and explicit paths. --- Section 3.2 For this purpose the ingress border node SHOULD try to find a minimum subset of S2L sub- LSPs for which the PathErr needs to be generated towards the ingress node. These are the S2L sub-LSPs on an incoming interface that has less number of S2L sub-LSPs compared to the second incoming interface that is causing the re-merge condition. OK. It took me four or five readings and a lot of pain to parse what you are trying to say. You are saying that, if the border node is a branch node for two sets of sub-LSPs that are remerging, then the border node should fix this by moving the smaller set to share the path with the larger set. There are two reasons why this is a bad idea: 1. The first set may have been set up with a Path/Resv exchange, while the second set has not been set up and a PathErr was returned. Maybe the remerge node could have made the decision you are suggesting, but even that sounds like a bad idea. 2. The choice of the correct path to the remerge node should be made according to which is the shortest path, not which path has the most destinations. --- Section 3.2 The RSVP-TE Notify messages do not include S2L_SUB_LSP objects and cannot be used to send errors for a subset of the S2L sub-LSPs in a Path message. This is not true! A Downstream Notify message (headed upstream) is described in RFC 3473 as: ::= [] [ [ | ] ... ] [ ] ::= [ ] | ::= [...] And according to RFC 4875, nets down to one or more of... ::= [ ] --- Section 3.2 A border node receiving a PathErr message for a set of S2L sub-LSPs MAY hold the message and attempt to signal an alternate path that can avoid re-merge through its domain for those S2L sub-LSPs that pass through it. However, in the case of a re-merge error for which some of the re-merging S2L sub-LSPs do not pass through the border node, it SHOULD propagate the PathErr upstream towards the ingress node. If the subsequent attempt by the border node is successful, the border node discards the held PathErr and follows the crankback roles of [RFC4920] and [RFC5151]. If repeated subsequent attempts by the border node are unsuccessful, the border node MUST send the held PathErr upstream towards the ingress node. How can an attempt to avoid re-merge be unsuccessful? There is already a suitable path. We know this because the re-merge has happened. --- Section 3.2 If the ingress node receives a PathErr message with error code "Routing Problem" and error value "ERO resulted in re-merge", then it SHOULD attempt to signal an alternate path through a different domain or through a different border node for the affected S2L sub-LSPs. The ingress node MAY use the error node information from the PathErr for this purpose. This is plain wrong. It should attempt to move the destinations to the same sub-tree, not try to signal the remerging destinations on a diverse sub-tree. --- Section 4 purports to be about the dataplane re-merge handling scenario, and it starts well. But then... The following sections define the RSVP-TE signaling extensions for "P2MP- TE Re-merge Recording Request" and "P2MP-TE Re-merge Present" messages. That look like it is control plane work and so does not belong in this section. Furthermore, this section appears to be offering a third solution to add to the two noted in 4875. That is, you are proposing that dataplane handling should be used, but that the control plane should be used to resolve the issue. This is an OK idea, but was discussed at the time of 4875 when two approaches handling this situation were discussed. 1. Use a Notify message sent after the Resv 2. Use a non-destructive PathErr sent after the Resv Admittedly, neither of those approaches is quite tidy, but it was thought that if you cared about the remerge you would fix it at setup time, and if you didn't care, then you didn't care. Thus the case you are fixing is a corner case (care a bit, but not too much) and the existing untidy solutions are enough. Nevertheless, the mechanism you describe does provide some additional useful diagnostics, and so should not be ruled out. Of course, those diagnostics are already visible simply by inspecting the full set of RRO information from the various S2L sub-LSPs as a re-merge point will show up as the same node appearing in two different sub-trees. Thus, the question only applies when RRO information is being stripped at domain boundaries. However, this last issue is the one you note in the final paragraph of section 4.3. There you appear to say that since the re-merge report info would be stripped from the Resv, the Resv should be discarded and a PathErr sent upstream. That would be fine, but it does seem to leave half an LSP provisioned and doing nothing (downstream between the border node and the re-merge point) --- 4.3 This can be achieved by computing and selecting alternate path(s) for the S2L(s) bypassing the re-merge node(s). Again, avoiding the remerge node is not the best result. --- Section 5 Re-merges between S2Ls in a single domain can occur due to provisioning errors or path computation errors in the environment where IGP-TE or PCE is used. What is a "provisioning error"? Are you referring to cases where the EROs of P2MP trees are entered by hand? What has IGP-TE to do with this? If PCE (whether a separate component or embedded in an LSR) is making such fundamental computation errors, then we should certainly not crash, but I also don't think we should optimise the protocol to handle it. This represents a critical implementation bug! --- Section 6.3 Using signaling procedure defined in [RFC4736], an ingress node MUST initiate "path re-evaluation request" query to reoptimize a destination in a P2MP LSP. Note that this message MUST be used to reoptimize a single or a sub-set of the destinations in a P2MP LSP. Ingress node MUST send this query in a Path message for each destination it is reoptimizing. When a Path message for a destination in a P2MP LSP with "path re-evaluation request" flag [RFC4736] is received at the border node, it MUST re-compute the loose-hop ERO to see if a preferable path exists for that destination. I am hugely worried about your use of 2119 language in this text. Is it your intention to redefine the procedures of RFC 4736? Because that is what you are doing! Perhaps you consider that you are only defining the procedures for P2MP LSPs with the claim that they were not covered by 4736. I don't see on what evidence such a claim would be made, and I am particularly concerned that you have turned the request in 4736 into a demand in your draft. --- Section 6.3 is almost impossible to understand. I think there are probably some assumptions that a request to reoptimise the path to a single destination would: a. be made b. be responded with "not telling you, but I could reoptimise the whole sub-tree." On the other hand, there also seems to be a desire to send a reoptimise request that identifies just on destination, but is actually a request to reoptimise the whole tree. Colour me confused! _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From sergio.belotti@alcatel-lucent.com Tue May 28 09:12:59 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DDBE21F9820 for ; Tue, 28 May 2013 09:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.792 X-Spam-Level: X-Spam-Status: No, score=-8.792 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BokovvQijKXn for ; Tue, 28 May 2013 09:12:37 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id C070E21F981B for ; Tue, 28 May 2013 09:12:36 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r4SGCOIK018449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 28 May 2013 11:12:25 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id r4SGCNBA011261 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 May 2013 12:12:23 -0400 Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 28 May 2013 12:12:23 -0400 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.233]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Tue, 28 May 2013 18:12:17 +0200 From: "BELOTTI, SERGIO (SERGIO)" To: Lou Berger Thread-Topic: R: R: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues) Thread-Index: AQHOWJxlOyTOa4Hi70imTgpK6F7OvJkatmCg///sf4CAACLsYA== Date: Tue, 28 May 2013 16:12:16 +0000 Message-ID: References: <518A82D9.7080508@labn.net> <51924382.2010904@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C90D5@ESESSMB301.ericsson.se> <13ea7ed3bdd.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <5193A26A.1090005@labn.net> <519649B4.5060408@labn.net> <519B73C9.2030308@labn.net> <519E406C.9030008@labn.net> <519F67ED.3040701@labn.net> <519F963C.9060305@labn.net> <51A4D1D3.8040705@labn.net> In-Reply-To: <51A4D1D3.8040705@labn.net> Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" Subject: [CCAMP] R: R: R: Closing Issue #49 (Was: Re: R: Closing G.709 open issues) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 16:12:59 -0000 Lou, Obviously opinion are opinion since anyone can see things in a different wa= y: I thought to do a favour to include suggestion in the word file used dur= ing the discussion by Fatai... Anyway below my notes. Sergio Belotti Sergio- System Architect ALCATE-LUCENT Optics Division via Trento 30 Vimercate (MB) - Italy phone +39 (039) 6863033 -----Messaggio originale----- Da: Lou Berger [mailto:lberger@labn.net]=20 Inviato: marted=EC 28 maggio 2013 17.49 A: BELOTTI, SERGIO (SERGIO) Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; Fatai Zh= ang; Beller, Dieter (Dieter) Oggetto: Re: R: R: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 ope= n issues) Sergio, See below. Also, can you just put your comments/discussion points in mail rather than a word file? I don't think the use of word is providing any value in this context. On 5/28/2013 11:02 AM, BELOTTI, SERGIO (SERGIO) wrote: > Hi Lou, >=20 > See below for my notes . > I attached the Fatai's doc for GPID mapping with possible suggested addon= . >=20 > Thanks >=20 > Sergio >=20 > Belotti Sergio- System Architect > ALCATE-LUCENT Optics Division > via Trento 30 Vimercate (MB) - Italy > phone +39 (039) 6863033 >=20 > -----Messaggio originale----- > Da: Lou Berger [mailto:lberger@labn.net]=20 > Inviato: venerd=EC 24 maggio 2013 18.33 > A: BELOTTI, SERGIO (SERGIO) > Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; Fatai = Zhang > Oggetto: Re: R: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open= issues) >=20 > Sergio, >=20 >=20 > On 5/24/2013 11:54 AM, BELOTTI, SERGIO (SERGIO) wrote: >> Hi, >> >> Please take care anyway this solution does not consider two cases: >> >> G.7041 and G.709, defines respectively: >> >> 10GbE --> GFP-F (G.7041, Table 6-3: UPI=3D0x13 [ Frame-mapped 64B/66B e= ncoded >> Ethernet, including the Ethernet frame preamble ]) >=20 > Cool, yet another way to encode Ethernet over GFP. (Pointing to the > G.7041 UPI was very helpful, the draft will need to capture that!) What > PT is used for this? Are there other client types missing/that you > think are missing? >=20 > SB> In G.7041 Table 6-3 - User payload identifiers for GFP client frames = define the UPI values. > UPI is setup according to the transported signal type. > Here we can see there is another form of Ethernet mapping via GFP and OD= U2 signals can carry diverse payloads including diverse GFP-F mapped Ether= net. > I think the best we can do would be to define GPID values for all possibl= e/meaningful combinations of PT/UPI values where GFP is used to encapsulate= the client signal. >=20 > What I have indicated here are just two possible addon: one is already co= nsidered in the file provided by Fatai , the other is the one form G.7041. > Attached the doc from Fatai, updated (in yellow) with the new GFP Etherne= t mapping possibility. Unless I misread it, you didn't propose any new G-PIDs. SB> In fact you misread >=20 >=20 > My suggestion would be to define GPID values for all > possible/meaningful combinations of PT/UPI values where GFP is used > to encapsulate the client signal. >=20 If you want to define additional types, please propose them! If there are no specifics, there's nothing for the WG to discuss/agree to. SB> I've attached the file for that as clearly explained. >> >> 10GbE--> extended OPU2/ODU2 (G.709, Table 15-8: PT=3D0x09 [ GFP mapping = into Extended >> OPU2 payload, see clause 17.4.1 ]) >=20 > Is this a different case? If yes, how so? (Do you have a data plane > reference?) >=20 > SB> For ODU2 in OTN there is two possible PT options for 10GbE and are > PT=3D 0x05 (ODU2) | PT =3D 0x09 (extended ODU2) Okay, sounds like a new G-PID type (TBA12 below). So here's the updated table as I understand it: G.709 Payload Type G-PID Type/Comment LSP Encoding =3D=3D=3D=3D =3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 0x01 No standard value 0x02 49 CBRa G.709 ODUk 0x03 50 CBRb G.709 ODUk 0x04 32 ATM G.709 ODUk 0x05 TBA1 Framed GFP G.709 ODUk 54 Ethernet MAC G.709 ODUk (framed GFP) TBA12 64B/66B GFP-F G.709 ODUk (k=3D2) Ethernet 0x06 ??? Is any valued needed? 0x07 55 Ethernet PHY G.709 ODUk (k=3D0) (transparent G.709 ODUk (k=3D3) GFP) G.709 ODUk (k=3D4) 0x08 58 Fiber Channel G.709 ODUk (k=3D2e) 0x09 TBA1 Framed GFP G.709 ODUk (k=3D2e) TBA12 64B/66B GFP-F G.709 ODUk (k=3D2) Ethernet 0x0A TBA2 STM-1 G.709 ODUk (k=3D0) 0x0B TBA3 STM-4 G.709 ODUk (k=3D0) 0x0C 58 Fiber Channel G.709 ODUk (k=3D0) 0x0D 58 Fiber Channel G.709 ODUk (k=3D1) 0x0E 58 Fiber Channel G.709 ODUflex 0x0F 58 Fiber Channel G.709 ODUflex 0x10 51 BSOT G.709 ODUk 0x11 52 BSNT G.709 ODUk 0x12 TBA4 InfiniBand G.709 ODUflex 0x13 TBA4 InfiniBand G.709 ODUflex 0x14 TBA4 InfiniBand G.709 ODUflex 0x15 TBA5 Serial Digital G.709 ODUk (k=3D0) Interface 0x16 TBA6 Serial Digital G.709 ODUk (k=3D1) Interface/1.001 0x17 TBA5 Serial Digital G.709 ODUk (k=3D1) Interface 0x18 TBA6 Serial Digital G.709 ODUflex Interface/1.001 0x19 TBA5 Serial Digital G.709 ODUflex Interface 0x1A 56 SBCON/ESCON G.709 ODUk (k=3D0) (IANA to update Type field) 0x1B TBA7 DVB_ASI G.709 ODUk (k=3D0) 0x1C 58 Fiber Channel G.709 ODUk 0x20 47 G.709 ODU-2.5G G.709 ODUk (k=3D2,3) (IANA to update Type field) TBA8 G.709 ODU-1.25G G.709 ODUk (k=3D1,2,3) 0x21 TBA8 G.709 ODU-1.25G G.709 ODUk (k=3D2,3,4) TBA9 G.709 ODU-Any G.709 ODUk (k=3D2,3) 0x55 No standard value 0x66 No standard value 0x80-0x8F No standard value 0xFD TBA10 Null Test G.709 ODUk 0xFE TBA11 Random Test G.709 ODUk 0xFF No standard value What *specific* changes/additions do you think are needed? (Please add to this table and NOT the word file, once we have agreement on e-mail the result can be directly inserted into the draft.) SB> NO, the changes you have done capture my suggestion. Lou >=20 > Thanks, > Lou >=20 >> >> Please not that this is not the mapping using UPI=3D0x01 and PT=3D0x05 >> >> Best Regards >> >> Sergio >> >> Belotti Sergio- System Architect >> ALCATE-LUCENT Optics Division >> via Trento 30 Vimercate (MB) - Italy >> phone +39 (039) 6863033 >> -----Messaggio originale----- >> Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di = Lou Berger >> Inviato: venerd=EC 24 maggio 2013 15.15 >> A: Fatai Zhang >> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >> Oggetto: Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open i= ssues) >> >> Fatai, >> >> Just to be clear, the following covers your correction: >> >> G.709 >> Payload >> Type G-PID Type/Comment LSP Encoding >> =3D=3D=3D=3D =3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> 0x05 TBA1 Framed GFP G.709 ODUk >> 54 Ethernet MAC G.709 ODUk >> (framed GFP) >> >> Right? >> >> Thanks, >> Lou >> >> On 5/23/2013 9:01 PM, Fatai Zhang wrote: >>> Hi Lou, >>> >>> Fine, thanks for your explanation. >>> >>> As I said, I will update the signaling draft based on your proposal if = there are no further comments. >>> >>> >>> >>> Best Regards >>> >>> Fatai >>> >>> >>> -----Original Message----- >>> From: Lou Berger [mailto:lberger@labn.net]=20 >>> Sent: Friday, May 24, 2013 12:15 AM >>> To: Fatai Zhang >>> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>> Subject: Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open = issues) >>> >>> Fatai, >>> Do we really need to reopen debate on a topic the WG discussed and >>> closed last summer? (i.e., to handle G.709 client adaptation just as w= e >>> do for every other technology.) >>> >>> I do agree that some new G-PID assignments were missed in the draft tha= t >>> went to LC, but filling in the list doesn't automatically mean that the >>> WG needs to reopen debate on adaptation approaches. >>> >>> Assuming we don't need to reopen the pre-LC debate from last summer, an= d >>> with respect to the list I sent out, I do agree the WG needs to: >>> >>> A) Ensure that the list doesn't have unneeded new G-PIDs (i.e., reuses >>> the same/existing G-PIDs wherever possible.) >>> >>> B) Identifies the "right" G-PID per payload type, and doesn't have any >>> other technical errors >>> >>> C) Doesn't conflict with past WG decisions/discussions. >>> >>> >From your mails I see the following comment on (A): >>> >>>> For 0x05, why you think that RFC4328 does not cover it (ie., G-PID=3D5= 4)? >>> >>> G-PID 54, per IANA, is currently defined as "Ethernet MAC (framed GFP)"= . >>> Per G.709, PT=3D0x05 maps to "GFP mapping, see clause 17.4" and lookin= g >>> at 17.4 there is no restriction on what is carried in GFP frames. So i= t >>> seems that PT=3D0x05 can't be limited to just "Ethernet MAC (framed GFP= )". >>> >>> Are you suggesting changing the type description of G-PID 54 to just >>> "Framed GFP", or including G-PID 54 as an additional possibility for >>> PT=3D0x05? >>> >>> The latter seems to be a valid addition/correction. The former may be >>> problematic for existing implementations, so we'll need to discuss more >>> broadly if that's the direction you want to head. >>> >>> All/ (WG), >>> >>> Again, please speak up if you think the above is not aligned with prior >>> consensus or if you have an issue with any of the above. >>> >>> Lou >>> >>> On 5/22/2013 10:35 PM, Fatai Zhang wrote: >>>> Hi Lou, >>>> >>>> =20 >>>> >>>> I incorporated your proposal into my table to facilitate the readers. >>>> >>>> =20 >>>> >>>> I think you still insist on reusing some existing G-PIDs like 58, 56. >>>> For 0x04, why you think that RFC4328 does not cover it (ie., G-PID=3D= 54)? >>>> >>>> =20 >>>> >>>> Technically, I am not convince by your proposal, but I would like to >>>> reserve my opinion for your same motivation (ie., to conclude the >>>> discussion as soon as possible). >>>> >>>> =20 >>>> >>>> Any opinions on Lou's proposal from the WG? I will update the signalin= g >>>> draft based on Lou's proposal if there is no comment on Lou's proposal= . >>>> >>>> =20 >>>> >>>> Note that all the new G-PID values will be re-ordered with TBA. >>>> >>>> =20 >>>> >>>> *G-PIDs vs **Payload types defined in Table 15-8 of G.709* >>>> >>>> =20 >>>> >>>> Payload Type in Hex codedefined in G.709 >>>> >>>> =09 >>>> >>>> G-PID >>>> >>>> =09 >>>> >>>> LSP Encoding >>>> >>>> =09 >>>> >>>> Note >>>> >>>> =09 >>>> >>>> Interpretationfrom G.709 >>>> >>>> 0x01 >>>> >>>> =09 >>>> >>>> None >>>> >>>> =09 >>>> >>>> =20 >>>> >>>> =09 >>>> >>>> Not needed >>>> >>>> =09 >>>> >>>> Experimental mapping (Note 3) >>>> >>>> 0x02 >>>> >>>> =09 >>>> >>>> 49 >>>> >>>> =09 >>>> >>>> G.709 ODUk, G.709 OCh >>>> >>>> =09 >>>> >>>> 1)G-PID defined in RFC4328; >>>> >>>> 2) Updated in this draft. >>>> >>>> =09 >>>> >>>> Asynchronous CBR mapping, see clause 17.2 >>>> >>>> 0x03 >>>> >>>> =09 >>>> >>>> 50 >>>> >>>> =09 >>>> >>>> G.709 ODUk >>>> >>>> =09 >>>> >>>> ditto >>>> >>>> =09 >>>> >>>> Bit synchronous CBR mapping, see clause 17.2 >>>> >>>> 0x04 >>>> >>>> =09 >>>> >>>> 32 >>>> >>>> =09 >>>> >>>> SDH, G.709 ODUk >>>> >>>> =09 >>>> >>>> ditto >>>> >>>> =09 >>>> >>>> ATM mapping, see clause 17.3 >>>> >>>> 0x05 >>>> >>>> =09 >>>> >>>> 54 >>>> >>>> or >>>> >>>> TBA (Suggested by Lou) >>>> >>>> =09 >>>> >>>> G.709 ODUk (and SDH) >>>> >>>> =20 >>>> >>>> =09 >>>> >>>> G-PIDs defined in RFC4328 for framed GFP >>>> >>>> =20 >>>> >>>> =09 >>>> >>>> GFP mapping, see clause 17.4 >>>> >>>> 0x06 >>>> >>>> =09 >>>> >>>> None >>>> >>>> =09 >>>> >>>> =20 >>>> >>>> =09 >>>> >>>> Not needed and Not defined in RFC4328 >>>> >>>> =09 >>>> >>>> Virtual Concatenated signal, see clause 18 (Note 5) >>>> >>>> 0x07 >>>> >>>> =09 >>>> >>>> 61(TBA) >>>> >>>> Or55(Suggested by Lou) >>>> >>>> =09 >>>> >>>> G.709 ODUk (k=3D0,3,4) >>>> >>>> =09 >>>> >>>> Is being defined in this draft (new payload type defined in [G.709-201= 2]) >>>> >>>> =09 >>>> >>>> PCS codeword transparent Ethernet mapping: >>>> >>>> * 1000BASE-X into OPU0, see clauses 17.7.1 and 17.7.1.1 >>>> >>>> * 40GBASE-R into OPU3, see clauses 17.7.4 and 17.7.4.1 >>>> >>>> * 100GBASE-R into OPU4, see clauses 17.7.5 and 17.7.5.1 >>>> >>>> 0x08 >>>> >>>> =09 >>>> >>>> 62(TBA) >>>> >>>> Or58(Suggested by Lou) >>>> >>>> =09 >>>> >>>> G.709 ODUk (k=3D2e) >>>> >>>> =09 >>>> >>>> ditto >>>> >>>> =09 >>>> >>>> FC-1200 into OPU2e mapping, see clause 17.8.2 >>>> >>>> 0x09 >>>> >>>> =09 >>>> >>>> 63(TBA) >>>> >>>> =09 >>>> >>>> G.709 ODUk (k=3D2) >>>> >>>> =09 >>>> >>>> ditto >>>> >>>> =09 >>>> >>>> GFP mapping into Extended OPU2 payload, see clause 17.4.1 (Note 6) >>>> >>>> 0x0A >>>> >>>> =09 >>>> >>>> 64(TBA) >>>> >>>> =09 >>>> >>>> G.709 ODUk (k=3D0) >>>> >>>> =09 >>>> >>>> ditto >>>> >>>> =09 >>>> >>>> STM-1 mapping into OPU0, see clause 17.7.1 >>>> >>>> 0x0B >>>> >>>> =09 >>>> >>>> 65(TBA) >>>> >>>> =09 >>>> >>>> G.709 ODUk (k=3D0) >>>> >>>> =09 >>>> >>>> ditto >>>> >>>> =09 >>>> >>>> STM-4 mapping into OPU0, see clause 17.7.1 >>>> >>>> 0x0C >>>> >>>> =09 >>>> >>>> 66(TBA) >>>> >>>> Or58(Suggested by Lou) >>>> >>>> =09 >>>> >>>> G.709 ODUk (k=3D0) >>>> >>>> =09 >>>> >>>> ditto >>>> >>>> =09 >>>> >>>> FC-100 mapping into OPU0, see clause 17.7.1 >>>> >>>> 0x0D >>>> >>>> =09 >>>> >>>> 67(TBA) >>>> >>>> Or58(Suggested by Lou) >>>> >>>> =09 >>>> >>>> G.709 ODUk (k=3D1) >>>> >>>> =09 >>>> >>>> ditto >>>> >>>> =09 >>>> >>>> FC-200 mapping into OPU1, see clause 17.7.2 >>>> >>>> 0x0E >>>> >>>> =09 >>>> >>>> 68(TBA) >>>> >>>> Or58(Suggested by Lou) >>>> >>>> =09 >>>> >>>> G.709 ODUflex >>>> >>>> =09 >>>> >>>> ditto >>>> >>>> =09 >>>> >>>> FC-400 mapping into OPUflex, see clause 17.9 >>>> >>>> 0x0F >>>> >>>> =09 >>>> >>>> 69(TBA) >>>> >>>> Or58(Suggested by Lou) >>>> >>>> =09 >>>> >>>> G.709 ODUflex >>>> >>>> =09 >>>> >>>> ditto >>>> >>>> =09 >>>> >>>> FC-800 mapping into OPUflex, see clause 17.9 >>>> >>>> 0x10 >>>> >>>> =09 >>>> >>>> 51 >>>> >>>> =09 >>>> >>>> G.709 ODUk >>>> >>>> =09 >>>> >>>> 1)G-PID defined in RFC4328; >>>> >>>> 2) Updated in this draft. >>>> >>>> =09 >>>> >>>> Bit stream with octet timing mapping, see clause 17.6.1 >>>> >>>> 0x11 >>>> >>>> =09 >>>> >>>> 52 >>>> >>>> =09 >>>> >>>> G.709 ODUk >>>> >>>> =09 >>>> >>>> ditto >>>> >>>> =09 >>>> >>>> Bit stream without octet timing mapping, see clause 17.6.2 >>>> >>>> 0x12 >>>> >>>> =09 >>>> >>>> 70(TBA) >>>> >>>> =09 >>>> >>>> G.709 ODUflex >>>> >>>> =09 >>>> >>>> Is being defined in this draft (new payload type defined in [G.709-201= 2]) >>>> >>>> =09 >>>> >>>> IB SDR mapping into OPUflex, see 17.9 >>>> >>>> 0x13 >>>> >>>> =09 >>>> >>>> 71(TBA) >>>> >>>> =09 >>>> >>>> G.709 ODUflex >>>> >>>> =09 >>>> >>>> ditto >>>> >>>> =09 >>>> >>>> IB DDR mapping into OPUflex, see 17.9 >>>> >>>> 0x14 >>>> >>>> =09 >>>> >>>> 72(TBA) >>>> >>>> =09 >>>> >>>> G.709 ODUflex >>>> >>>> =09 >>>> >>>> ditto >>>> >>>> =09 >>>> >>>> IB QDR mapping into OPUflex, see 17.9 >>>> >>>> 0x15 >>>> >>>> =09 >>>> >>>> 73(TBA) >>>> >>>> =09 >>>> >>>> G.709 ODUk (k=3D0) >>>> >>>> =09 >>>> >>>> ditto >>>> >>>> =09 >>>> >>>> SDI mapping into OPU0, see 17.7.1 >>>> >>>> 0x16 >>>> >>>> =09 >>>> >>>> 74(TBA) >>>> >>>> =09 >>>> >>>> G.709 ODUk (k=3D1) >>>> >>>> =09 >>>> >>>> ditto >>>> >>>> =09 >>>> >>>> (1.485/1.001) Gbit/s SDI mapping into OPU1, see 17.7.2 >>>> >>>> 0x17 >>>> >>>> =09 >>>> >>>> 75(TBA) >>>> >>>> =09 >>>> >>>> G.709 ODUk (k=3D1) >>>> >>>> =09 >>>> >>>> ditto >>>> >>>> =09 >>>> >>>> 1.485 Gbit/s SDI mapping into OPU1, see 17.7.2 >>>> >>>> 0x18 >>>> >>>> =09 >>>> >>>> 76(TBA) >>>> >>>> =09 >>>> >>>> G.709 ODUflex >>>> >>>> =09 >>>> >>>> ditto >>>> >>>> =09 >>>> >>>> (2.970/1.001) Gbit/s SDI mapping into OPUflex, see 17.9 >>>> >>>> 0x19 >>>> >>>> =09 >>>> >>>> 77(TBA) >>>> >>>> =09 >>>> >>>> G.709 ODUflex >>>> >>>> =09 >>>> >>>> ditto >>>> >>>> =09 >>>> >>>> 2.970 Gbit/s SDI mapping into OPUflex, see 17.9 >>>> >>>> 0x1A >>>> >>>> =09 >>>> >>>> 78(TBA) >>>> >>>> Or56(Suggested by Lou) >>>> >>>> =09 >>>> >>>> G.709 ODUk (k=3D0) >>>> >>>> =09 >>>> >>>> ditto >>>> >>>> =09 >>>> >>>> SBCON/ESCON mapping into OPU0, see 17.7.1 >>>> >>>> 0x1B >>>> >>>> =09 >>>> >>>> 79(TBA) >>>> >>>> =09 >>>> >>>> G.709 ODUk (k=3D0) >>>> >>>> =09 >>>> >>>> ditto >>>> >>>> =09 >>>> >>>> DVB_ASI mapping into OPU0, see 17.7.1 >>>> >>>> 0x20 >>>> >>>> =09 >>>> >>>> 47 >>>> >>>> =09 >>>> >>>> G.709 ODUk >>>> >>>> =09 >>>> >>>> 1) G-PIDs defined in RFC4328. >>>> >>>> 2) Updated in this draft. >>>> >>>> =09 >>>> >>>> ODU multiplex structure supporting ODTUjk only, see clause 19 (AMP onl= y) >>>> >>>> 0x21 >>>> >>>> =09 >>>> >>>> 59/60(TBA) >>>> >>>> =09 >>>> >>>> G.709 ODUk >>>> >>>> =09 >>>> >>>> 1)Are being defined in this draft (new payload type defined in >>>> [G.709-2012]); >>>> >>>> 2) 59 for G.709 ODU-1.25G; 60 for G.709 ODU-any >>>> >>>> =09 >>>> >>>> ODU multiplex structure supporting ODTUk.ts or ODTUk.ts and ODTUjk, se= e >>>> clause 19 (GMP capable) (Note 7) >>>> >>>> 55 >>>> >>>> =09 >>>> >>>> None >>>> >>>> =09 >>>> >>>> =20 >>>> >>>> =09 >>>> >>>> Not needed >>>> >>>> =09 >>>> >>>> Not available (Note 2) >>>> >>>> 66 >>>> >>>> =09 >>>> >>>> None >>>> >>>> =09 >>>> >>>> =20 >>>> >>>> =09 >>>> >>>> Not needed >>>> >>>> =09 >>>> >>>> Not available (Note 2) >>>> >>>> 80-8F >>>> >>>> =09 >>>> >>>> None >>>> >>>> =09 >>>> >>>> =20 >>>> >>>> =09 >>>> >>>> Not needed >>>> >>>> =09 >>>> >>>> Reserved codes for proprietary use (Note 4) >>>> >>>> FD >>>> >>>> =09 >>>> >>>> None >>>> >>>> OrTBA(Suggested by Lou) >>>> >>>> =09 >>>> >>>> =20 >>>> >>>> =09 >>>> >>>> Not needed >>>> >>>> =09 >>>> >>>> NULL test signal mapping, see clause 17.5.1 >>>> >>>> FE >>>> >>>> =09 >>>> >>>> None >>>> >>>> OrTBA(Suggested by Lou) >>>> >>>> =09 >>>> >>>> =20 >>>> >>>> =09 >>>> >>>> Not needed >>>> >>>> =09 >>>> >>>> PRBS test signal mapping, see clause 17.5.2 >>>> >>>> FF >>>> >>>> =09 >>>> >>>> None >>>> >>>> =09 >>>> >>>> =20 >>>> >>>> =09 >>>> >>>> Not needed >>>> >>>> =09 >>>> >>>> Not available (Note 2) >>>> >>>> =20 >>>> >>>> =09 >>>> >>>> =20 >>>> >>>> =09 >>>> >>>> =20 >>>> >>>> =09 >>>> >>>> =20 >>>> >>>> =09 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> Best Regards >>>> >>>> =20 >>>> >>>> Fatai >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> -----Original Message----- >>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf >>>> Of Lou Berger >>>> Sent: Tuesday, May 21, 2013 9:17 PM >>>> To: CCAMP >>>> Cc: draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>> Subject: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open iss= ues) >>>> >>>> =20 >>>> >>>> All, >>>> >>>> =20 >>>> >>>> In the interest of moving this discussion quickly to closure, I spent >>>> >>>> some time trying to come up with the full list of G.709 PT to G-PID >>>> >>>> mappings. In coming up with this list I tried to be consistent with >>>> >>>> the last consensus point that I can identify on this topic (the >>>> >>>> previously referenced July 2012 thread & presentation), which included= : >>>> >>>> =20 >>>> >>>> A) Defining new G-PIDs for client types not identified by an assigned >>>> >>>> G-PID (per >>>> >>>> http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-paramet= ers.xml) >>>> >>>> =20 >>>> >>>> B) Reusing G-PID wherever {G-PID, ODU rate} unambiguously identify a >>>> >>>> G.709 payload type, and define new G-PIDs when reuse not possible. >>>> >>>> =20 >>>> >>>> C) No G-PID value for unused, reserved, or proprietary 709 Payload Typ= e. >>>> >>>> =20 >>>> >>>> Here's what I've come up with: >>>> >>>> =20 >>>> >>>> G.709 >>>> >>>> Payload >>>> >>>> Type G-PID Type/Comment LSP Encoding >>>> >>>> =3D=3D=3D=3D =3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> >>>> 0x01 No standard value >>>> >>>> 0x02 49 CBRa G.709 ODUk >>>> >>>> 0x03 50 CBRb G.709 ODUk >>>> >>>> 0x04 32 ATM G.709 ODUk >>>> >>>> 0x05 TBA1 Framed GFP G.709 ODUk >>>> >>>> 0x06 ??? Is any valued needed? >>>> >>>> 0x07 55 Ethernet PHY G.709 ODUk (k=3D0) >>>> >>>> (transparent G.709 ODUk (k=3D3) >>>> >>>> GFP) G.709 ODUk (k=3D4) >>>> >>>> 0x08 58 Fiber Channel G.709 ODUk (k=3D2e) >>>> >>>> 0x09 TBA1 Framed GFP G.709 ODUk (k=3D2e) >>>> >>>> 0x0A TBA2 STM-1 G.709 ODUk (k=3D0) >>>> >>>> 0x0B TBA3 STM-4 G.709 ODUk (k=3D0) >>>> >>>> 0x0C 58 Fiber Channel G.709 ODUk (k=3D0) >>>> >>>> 0x0D 58 Fiber Channel G.709 ODUk (k=3D1) >>>> >>>> 0x0E 58 Fiber Channel G.709 ODUflex >>>> >>>> 0x0F 58 Fiber Channel G.709 ODUflex >>>> >>>> 0x10 51 BSOT G.709 ODUk >>>> >>>> 0x11 52 BSNT G.709 ODUk >>>> >>>> 0x12 TBA4 InfiniBand G.709 ODUflex >>>> >>>> 0x13 TBA4 InfiniBand G.709 ODUflex >>>> >>>> 0x14 TBA4 InfiniBand G.709 ODUflex >>>> >>>> 0x15 TBA5 Serial Digital G.709 ODUk (k=3D0) >>>> >>>> Interface >>>> >>>> 0x16 TBA6 Serial Digital G.709 ODUk (k=3D1) >>>> >>>> Interface/1.001 >>>> >>>> 0x17 TBA5 Serial Digital G.709 ODUk (k=3D1) >>>> >>>> Interface >>>> >>>> 0x18 TBA6 Serial Digital G.709 ODUflex >>>> >>>> Interface/1.001 >>>> >>>> 0x19 TBA5 Serial Digital G.709 ODUflex >>>> >>>> Interface >>>> >>>> 0x1A 56 SBCON/ESCON G.709 ODUk (k=3D0) >>>> >>>> (IANA to update Type field) >>>> >>>> 0x1B TBA7 DVB_ASI G.709 ODUk (k=3D0) >>>> >>>> 0x1C 58 Fiber Channel G.709 ODUk >>>> >>>> 0x20 47 G.709 ODU-2.5G G.709 ODUk >>>> >>>> (k=3D2,3) >>>> >>>> (IANA to update Type field) >>>> >>>> TBA8 G.709 ODU-1.25G G.709 ODUk >>>> >>>> (k=3D1,2,3) >>>> >>>> 0x21 TBA8 G.709 ODU-1.25G G.709 ODUk >>>> >>>> (k=3D2,3,4) >>>> >>>> TBA9 G.709 ODU-Any G.709 ODUk >>>> >>>> (k=3D2,3) >>>> >>>> 0x55 No standard value >>>> >>>> 0x66 No standard value >>>> >>>> 0x80-0x8F No standard value >>>> >>>> 0xFD TBA10 Null Test G.709 ODUk >>>> >>>> 0xFE TBA11 Random Test G.709 ODUk >>>> >>>> 0xFF No standard value >>>> >>>> =20 >>>> >>>> Note that there are a few differences with Fatai's list, which doesn't >>>> >>>> format well in e-mail, but is available in the archive >>>> >>>> http://www.ietf.org/mail-archive/web/ccamp/current/msg14845.html >>>> >>>> =20 >>>> >>>> Please speak up if you think the above is not aligned with prior >>>> >>>> consensus or if you have an issue with any of the above. >>>> >>>> =20 >>>> >>>> Much thanks, >>>> >>>> Lou >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> On 5/20/2013 5:09 AM, Fatai Zhang wrote: >>>> >>>>> Hi Lou, >>>> >>>>> >>>> >>>>> =20 >>>> >>>>> >>>> >>>>> I think my mail on March 13rd may have answered your following commen= ts. >>>> >>>>> My response quoted as follows. >>>> >>>>> >>>> >>>>> =20 >>>> >>>>> >>>> >>>>> In addition, if people look at the full list that I provided, I think >>>> >>>>> people can realize that RFC4328 (section 3.1.3) used the same approac= h >>>> >>>>> as the current approach of this draft (ie., 1:1 mapping between GPIDs >>>> >>>>> and payload types defined by G.709), ie., we are following what RFC43= 28 >>>> >>>>> did. >>>> >>>>> >>>> >>>>> =20 >>>> >>>>> >>>> >>>>> BTW, I am not sure if we need spend so much on discussing this point >>>> >>>>> (because there is no issue to stick to the data plane by using the >>>> >>>>> current approach of this draft). >>>> >>>>> >>>> >>>>> =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> >>>>> >>>> >>>>> (2) 'Grouped GPID' vs '1:1' mapping (between G.709-2012 and GPIDs >>>> >>>>> defined in this draft) >>>> >>>>> >>>> >>>>> =20 >>>> >>>>> >>>> >>>>> We realize that it is safe to use 1:1 mapping approach to avoid some >>>> >>>>> potential issues after investigation. We know this payload types have >>>> >>>>> been defined by G.709 (data plane), so physically it is better to use >>>> >>>>> 1:1 mapping approach. >>>> >>>>> >>>> >>>>> For the potential issues I mentioned above, for example, we cannot us= e >>>> >>>>> the existing 34 to represent 'STM-1' and 'STM-4 ', because it is >>>> >>>>> impossible to differentiate which one is 'STM-1' or 'STM-4'. In >>>> >>>>> addition, from the concept of payload type, we know that e.g, FC-100 = is >>>> >>>>> different from FC-800, right? So, it is better to assign different GP= IDs >>>> >>>>> to these different payload types defined by the data plane. >>>> >>>>> >>>> >>>>> =20 >>>> >>>>> >>>> >>>>> Furthermore, I think it is much cheaper to create new GPIDs in the >>>> >>>>> control plane than in the data plane (these payload types will be >>>> >>>>> carried in the OH). >>>> >>>>> >>>> >>>>> =20 >>>> >>>>> >>>> >>>>> =20 >>>> >>>>> >>>> >>>>> =20 >>>> >>>>> >>>> >>>>> =20 >>>> >>>>> >>>> >>>>> Best Regards >>>> >>>>> >>>> >>>>> =20 >>>> >>>>> >>>> >>>>> Fatai >>>> >>>>> >>>> >>>>> =20 >>>> >>>>> >>>> >>>>> -----Original Message----- >>>> >>>>> From: Lou Berger [mailto:lberger@labn.net] >>>> >>>>> Sent: Friday, May 17, 2013 11:16 PM >>>> >>>>> To: Fatai Zhang >>>> >>>>> Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; >>>> >>>>> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>> >>>>> Subject: Re: R: Closing G.709 open issues >>>> >>>>> >>>> >>>>> =20 >>>> >>>>> >>>> >>>>> Fatai, >>>> >>>>> >>>> >>>>> =20 >>>> >>>>> >>>> >>>>> That's a great start for the WG. Thank you. >>>> >>>>> >>>> >>>>> =20 >>>> >>>>> >>>> >>>>> To answer your implied question as to why my request for the full lis= t. >>>> >>>>> >>>> >>>>> My feeling is that there have been too many "surprises" on the 709 >>>> >>>>> >>>> >>>>> documents in areas that I thought were either obvious (but from the I= ETF >>>> >>>>> >>>> >>>>> & GMPLS context, not ITU-T or G.709 perspectives) or resolved by past >>>> >>>>> >>>> >>>>> discussions. At this point, as co-chair and Document shepherd, I wan= t >>>> >>>>> >>>> >>>>> to ensure that any open point on the documents are unambiguously clos= ed >>>> >>>>> >>>> >>>>> and that past discussions (i.e., points of consensus) are 100% captur= ed, >>>> >>>>> >>>> >>>>> so that we can smoothly move through the planned second LC and >>>> >>>>> >>>> >>>>> publication request. >>>> >>>>> >>>> >>>>> =20 >>>> >>>>> >>>> >>>>> To that end, in my previous message I asked two questions about point= s >>>> >>>>> >>>> >>>>> where it seems you are proposing moving away from what has been >>>> >>>>> >>>> >>>>> previously been discussed & agreed to by the WG. Can you answer the >>>> >>>>> >>>> >>>>> following: >>>> >>>>> >>>> >>>>> =20 >>>> >>>>> >>>> >>>>>>> My questions on the new G-PIDs come down to: >>>> >>>>> >>>> >>>>>>> - Why are rate specific G-PIDs being proposed (rather than >>>> >>>>> >>>> >>>>>>> continuing to use the previous approach documented in the draft >>>> >>>>> >>>> >>>>>>> and in Section 3.1.3 of rfc4328)? >>>> >>>>> >>>> >>>>> =20 >>>> >>>>> >>>> >>>>>>> - Why are new values being defined rather than using existing >>>> >>>>> >>>> >>>>>>> values, e.g., G-PID 56? >>>> >>>>> >>>> >>>>>>> >>>> >>>>> >>>> >>>>> =20 >>>> >>>>> >>>> >>>>> Much thanks, >>>> >>>>> >>>> >>>>> Lou >>>> >>>>> >>>> >>>>> =20 >>>> >>>>> >>>> >>>>> =20 >>>> >>>>> >>>> >>>> _______________________________________________ >>>> >>>> CCAMP mailing list >>>> >>>> CCAMP@ietf.org >>>> >>>> https://www.ietf.org/mailman/listinfo/ccamp >>>> >>> >>> >>> >>> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> From lberger@labn.net Tue May 28 09:34:51 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 052CB21F9880 for ; Tue, 28 May 2013 09:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.463 X-Spam-Level: X-Spam-Status: No, score=-101.463 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_52=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqmVJK-U59f3 for ; Tue, 28 May 2013 09:34:46 -0700 (PDT) Received: from oproxy13-pub.unifiedlayer.com (oproxy13-pub.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id 92DB521F983E for ; Tue, 28 May 2013 09:34:46 -0700 (PDT) Received: (qmail 23845 invoked by uid 0); 28 May 2013 16:34:24 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy13.unifiedlayer.com with SMTP; 28 May 2013 16:34:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=3kEjjUirgoILpfcr7J8Ni0H0kq45yjUJXqY3o0l2fXQ=; b=MnorW6hsMyw5A1bsNfJaQASQauUsJh3Of7gYkt2pbmYJGYdKl6vRJTpQLdHAkhQoza1G5NE1tXqKz/d19gLKnVuW+6N+VBkB36ankA03fgM/s6w9NXlAV+iG3wSEbfVM; Received: from box313.bluehost.com ([69.89.31.113]:48897 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UhMqt-0007fj-EU; Tue, 28 May 2013 10:34:23 -0600 Message-ID: <51A4DC8C.8040306@labn.net> Date: Tue, 28 May 2013 12:34:20 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "BELOTTI, SERGIO (SERGIO)" , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" References: <518A82D9.7080508@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C90D5@ESESSMB301.ericsson.se> <13ea7ed3bdd.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <5193A26A.1090005@labn.net> <519649B4.5060408@labn.net> <519B73C9.2030308@labn.net> <519E406C.9030008@labn.net> <519F67ED.3040701@labn.net> <519F963C.9060305@labn.net> <51A4D1D3.8040705@labn.net> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP Subject: Re: [CCAMP] R: R: R: Closing Issue #49 (Was: Re: R: Closing G.709 open issues) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 16:34:51 -0000 >> What *specific* changes/additions do you think are needed? >> > SB> NO, the changes you have done capture my suggestion. Excellent. This comment is now addressed/closed. Authors, Please update the draft based on the table included below, as well as the issue 48 discussion. If there are other corrections/additions, they can be picked up as they come in, or as part of the 2nd LC. Lou On 5/28/2013 12:12 PM, BELOTTI, SERGIO (SERGIO) wrote: > Lou, > > Obviously opinion are opinion since anyone can see things in a different way: I thought to do a favour to include suggestion in the word file used during the discussion by Fatai... > > Anyway below my notes. > > Sergio > > Belotti Sergio- System Architect > ALCATE-LUCENT Optics Division > via Trento 30 Vimercate (MB) - Italy > phone +39 (039) 6863033 > > -----Messaggio originale----- > Da: Lou Berger [mailto:lberger@labn.net] > Inviato: martedì 28 maggio 2013 17.49 > A: BELOTTI, SERGIO (SERGIO) > Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; Fatai Zhang; Beller, Dieter (Dieter) > Oggetto: Re: R: R: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues) > > Sergio, > See below. > > Also, can you just put your comments/discussion points in mail rather > than a word file? I don't think the use of word is providing any value > in this context. > > On 5/28/2013 11:02 AM, BELOTTI, SERGIO (SERGIO) wrote: >> Hi Lou, >> >> See below for my notes . >> I attached the Fatai's doc for GPID mapping with possible suggested addon. >> >> Thanks >> >> Sergio >> >> Belotti Sergio- System Architect >> ALCATE-LUCENT Optics Division >> via Trento 30 Vimercate (MB) - Italy >> phone +39 (039) 6863033 >> >> -----Messaggio originale----- >> Da: Lou Berger [mailto:lberger@labn.net] >> Inviato: venerdì 24 maggio 2013 18.33 >> A: BELOTTI, SERGIO (SERGIO) >> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; Fatai Zhang >> Oggetto: Re: R: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues) >> >> Sergio, >> >> >> On 5/24/2013 11:54 AM, BELOTTI, SERGIO (SERGIO) wrote: >>> Hi, >>> >>> Please take care anyway this solution does not consider two cases: >>> >>> G.7041 and G.709, defines respectively: >>> >>> 10GbE --> GFP-F (G.7041, Table 6-3: UPI=0x13 [ Frame-mapped 64B/66B encoded >>> Ethernet, including the Ethernet frame preamble ]) >> >> Cool, yet another way to encode Ethernet over GFP. (Pointing to the >> G.7041 UPI was very helpful, the draft will need to capture that!) What >> PT is used for this? Are there other client types missing/that you >> think are missing? >> >> SB> In G.7041 Table 6-3 - User payload identifiers for GFP client frames define the UPI values. >> UPI is setup according to the transported signal type. >> Here we can see there is another form of Ethernet mapping via GFP and ODU2 signals can carry diverse payloads including diverse GFP-F mapped Ethernet. >> I think the best we can do would be to define GPID values for all possible/meaningful combinations of PT/UPI values where GFP is used to encapsulate the client signal. >> >> What I have indicated here are just two possible addon: one is already considered in the file provided by Fatai , the other is the one form G.7041. >> Attached the doc from Fatai, updated (in yellow) with the new GFP Ethernet mapping possibility. > > Unless I misread it, you didn't propose any new G-PIDs. > > SB> In fact you misread > >> >> >> My suggestion would be to define GPID values for all >> possible/meaningful combinations of PT/UPI values where GFP is used >> to encapsulate the client signal. >> > > If you want to define additional types, please propose them! If there > are no specifics, there's nothing for the WG to discuss/agree to. > > SB> I've attached the file for that as clearly explained. > >>> >>> 10GbE--> extended OPU2/ODU2 (G.709, Table 15-8: PT=0x09 [ GFP mapping into Extended >>> OPU2 payload, see clause 17.4.1 ]) >> >> Is this a different case? If yes, how so? (Do you have a data plane >> reference?) >> >> SB> For ODU2 in OTN there is two possible PT options for 10GbE and are >> PT= 0x05 (ODU2) | PT = 0x09 (extended ODU2) > > Okay, sounds like a new G-PID type (TBA12 below). So here's the updated > table as I understand it: > > G.709 > Payload > Type G-PID Type/Comment LSP Encoding > ==== ===== ============== =================== > 0x01 No standard value > 0x02 49 CBRa G.709 ODUk > 0x03 50 CBRb G.709 ODUk > 0x04 32 ATM G.709 ODUk > 0x05 TBA1 Framed GFP G.709 ODUk > 54 Ethernet MAC G.709 ODUk > (framed GFP) > TBA12 64B/66B GFP-F G.709 ODUk (k=2) > Ethernet > 0x06 ??? Is any valued needed? > 0x07 55 Ethernet PHY G.709 ODUk (k=0) > (transparent G.709 ODUk (k=3) > GFP) G.709 ODUk (k=4) > 0x08 58 Fiber Channel G.709 ODUk (k=2e) > 0x09 TBA1 Framed GFP G.709 ODUk (k=2e) > TBA12 64B/66B GFP-F G.709 ODUk (k=2) > Ethernet > 0x0A TBA2 STM-1 G.709 ODUk (k=0) > 0x0B TBA3 STM-4 G.709 ODUk (k=0) > 0x0C 58 Fiber Channel G.709 ODUk (k=0) > 0x0D 58 Fiber Channel G.709 ODUk (k=1) > 0x0E 58 Fiber Channel G.709 ODUflex > 0x0F 58 Fiber Channel G.709 ODUflex > 0x10 51 BSOT G.709 ODUk > 0x11 52 BSNT G.709 ODUk > 0x12 TBA4 InfiniBand G.709 ODUflex > 0x13 TBA4 InfiniBand G.709 ODUflex > 0x14 TBA4 InfiniBand G.709 ODUflex > 0x15 TBA5 Serial Digital G.709 ODUk (k=0) > Interface > 0x16 TBA6 Serial Digital G.709 ODUk (k=1) > Interface/1.001 > 0x17 TBA5 Serial Digital G.709 ODUk (k=1) > Interface > 0x18 TBA6 Serial Digital G.709 ODUflex > Interface/1.001 > 0x19 TBA5 Serial Digital G.709 ODUflex > Interface > 0x1A 56 SBCON/ESCON G.709 ODUk (k=0) > (IANA to update Type field) > 0x1B TBA7 DVB_ASI G.709 ODUk (k=0) > 0x1C 58 Fiber Channel G.709 ODUk > 0x20 47 G.709 ODU-2.5G G.709 ODUk > (k=2,3) > (IANA to update Type field) > TBA8 G.709 ODU-1.25G G.709 ODUk > (k=1,2,3) > 0x21 TBA8 G.709 ODU-1.25G G.709 ODUk > (k=2,3,4) > TBA9 G.709 ODU-Any G.709 ODUk > (k=2,3) > 0x55 No standard value > 0x66 No standard value > 0x80-0x8F No standard value > 0xFD TBA10 Null Test G.709 ODUk > 0xFE TBA11 Random Test G.709 ODUk > 0xFF No standard value > > What *specific* changes/additions do you think are needed? (Please add > to this table and NOT the word file, once we have agreement on e-mail > the result can be directly inserted into the draft.) > > SB> NO, the changes you have done capture my suggestion. > > Lou > >> >> Thanks, >> Lou >> >>> >>> Please not that this is not the mapping using UPI=0x01 and PT=0x05 >>> >>> Best Regards >>> >>> Sergio >>> >>> Belotti Sergio- System Architect >>> ALCATE-LUCENT Optics Division >>> via Trento 30 Vimercate (MB) - Italy >>> phone +39 (039) 6863033 >>> -----Messaggio originale----- >>> Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di Lou Berger >>> Inviato: venerdì 24 maggio 2013 15.15 >>> A: Fatai Zhang >>> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>> Oggetto: Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues) >>> >>> Fatai, >>> >>> Just to be clear, the following covers your correction: >>> >>> G.709 >>> Payload >>> Type G-PID Type/Comment LSP Encoding >>> ==== ===== ============== =================== >>> 0x05 TBA1 Framed GFP G.709 ODUk >>> 54 Ethernet MAC G.709 ODUk >>> (framed GFP) >>> >>> Right? >>> >>> Thanks, >>> Lou >>> >>> On 5/23/2013 9:01 PM, Fatai Zhang wrote: >>>> Hi Lou, >>>> >>>> Fine, thanks for your explanation. >>>> >>>> As I said, I will update the signaling draft based on your proposal if there are no further comments. >>>> >>>> >>>> >>>> Best Regards >>>> >>>> Fatai >>>> >>>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: Friday, May 24, 2013 12:15 AM >>>> To: Fatai Zhang >>>> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>> Subject: Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues) >>>> >>>> Fatai, >>>> Do we really need to reopen debate on a topic the WG discussed and >>>> closed last summer? (i.e., to handle G.709 client adaptation just as we >>>> do for every other technology.) >>>> >>>> I do agree that some new G-PID assignments were missed in the draft that >>>> went to LC, but filling in the list doesn't automatically mean that the >>>> WG needs to reopen debate on adaptation approaches. >>>> >>>> Assuming we don't need to reopen the pre-LC debate from last summer, and >>>> with respect to the list I sent out, I do agree the WG needs to: >>>> >>>> A) Ensure that the list doesn't have unneeded new G-PIDs (i.e., reuses >>>> the same/existing G-PIDs wherever possible.) >>>> >>>> B) Identifies the "right" G-PID per payload type, and doesn't have any >>>> other technical errors >>>> >>>> C) Doesn't conflict with past WG decisions/discussions. >>>> >>>> >From your mails I see the following comment on (A): >>>> >>>>> For 0x05, why you think that RFC4328 does not cover it (ie., G-PID=54)? >>>> >>>> G-PID 54, per IANA, is currently defined as "Ethernet MAC (framed GFP)". >>>> Per G.709, PT=0x05 maps to "GFP mapping, see clause 17.4" and looking >>>> at 17.4 there is no restriction on what is carried in GFP frames. So it >>>> seems that PT=0x05 can't be limited to just "Ethernet MAC (framed GFP)". >>>> >>>> Are you suggesting changing the type description of G-PID 54 to just >>>> "Framed GFP", or including G-PID 54 as an additional possibility for >>>> PT=0x05? >>>> >>>> The latter seems to be a valid addition/correction. The former may be >>>> problematic for existing implementations, so we'll need to discuss more >>>> broadly if that's the direction you want to head. >>>> >>>> All/ (WG), >>>> >>>> Again, please speak up if you think the above is not aligned with prior >>>> consensus or if you have an issue with any of the above. >>>> >>>> Lou >>>> >>>> On 5/22/2013 10:35 PM, Fatai Zhang wrote: >>>>> Hi Lou, >>>>> >>>>> >>>>> >>>>> I incorporated your proposal into my table to facilitate the readers. >>>>> >>>>> >>>>> >>>>> I think you still insist on reusing some existing G-PIDs like 58, 56. >>>>> For 0x04, why you think that RFC4328 does not cover it (ie., G-PID=54)? >>>>> >>>>> >>>>> >>>>> Technically, I am not convince by your proposal, but I would like to >>>>> reserve my opinion for your same motivation (ie., to conclude the >>>>> discussion as soon as possible). >>>>> >>>>> >>>>> >>>>> Any opinions on Lou's proposal from the WG? I will update the signaling >>>>> draft based on Lou's proposal if there is no comment on Lou's proposal. >>>>> >>>>> >>>>> >>>>> Note that all the new G-PID values will be re-ordered with TBA. >>>>> >>>>> >>>>> >>>>> *G-PIDs vs **Payload types defined in Table 15-8 of G.709* >>>>> >>>>> >>>>> >>>>> Payload Type in Hex codedefined in G.709 >>>>> >>>>> >>>>> >>>>> G-PID >>>>> >>>>> >>>>> >>>>> LSP Encoding >>>>> >>>>> >>>>> >>>>> Note >>>>> >>>>> >>>>> >>>>> Interpretationfrom G.709 >>>>> >>>>> 0x01 >>>>> >>>>> >>>>> >>>>> None >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Not needed >>>>> >>>>> >>>>> >>>>> Experimental mapping (Note 3) >>>>> >>>>> 0x02 >>>>> >>>>> >>>>> >>>>> 49 >>>>> >>>>> >>>>> >>>>> G.709 ODUk, G.709 OCh >>>>> >>>>> >>>>> >>>>> 1)G-PID defined in RFC4328; >>>>> >>>>> 2) Updated in this draft. >>>>> >>>>> >>>>> >>>>> Asynchronous CBR mapping, see clause 17.2 >>>>> >>>>> 0x03 >>>>> >>>>> >>>>> >>>>> 50 >>>>> >>>>> >>>>> >>>>> G.709 ODUk >>>>> >>>>> >>>>> >>>>> ditto >>>>> >>>>> >>>>> >>>>> Bit synchronous CBR mapping, see clause 17.2 >>>>> >>>>> 0x04 >>>>> >>>>> >>>>> >>>>> 32 >>>>> >>>>> >>>>> >>>>> SDH, G.709 ODUk >>>>> >>>>> >>>>> >>>>> ditto >>>>> >>>>> >>>>> >>>>> ATM mapping, see clause 17.3 >>>>> >>>>> 0x05 >>>>> >>>>> >>>>> >>>>> 54 >>>>> >>>>> or >>>>> >>>>> TBA (Suggested by Lou) >>>>> >>>>> >>>>> >>>>> G.709 ODUk (and SDH) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> G-PIDs defined in RFC4328 for framed GFP >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> GFP mapping, see clause 17.4 >>>>> >>>>> 0x06 >>>>> >>>>> >>>>> >>>>> None >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Not needed and Not defined in RFC4328 >>>>> >>>>> >>>>> >>>>> Virtual Concatenated signal, see clause 18 (Note 5) >>>>> >>>>> 0x07 >>>>> >>>>> >>>>> >>>>> 61(TBA) >>>>> >>>>> Or55(Suggested by Lou) >>>>> >>>>> >>>>> >>>>> G.709 ODUk (k=0,3,4) >>>>> >>>>> >>>>> >>>>> Is being defined in this draft (new payload type defined in [G.709-2012]) >>>>> >>>>> >>>>> >>>>> PCS codeword transparent Ethernet mapping: >>>>> >>>>> * 1000BASE-X into OPU0, see clauses 17.7.1 and 17.7.1.1 >>>>> >>>>> * 40GBASE-R into OPU3, see clauses 17.7.4 and 17.7.4.1 >>>>> >>>>> * 100GBASE-R into OPU4, see clauses 17.7.5 and 17.7.5.1 >>>>> >>>>> 0x08 >>>>> >>>>> >>>>> >>>>> 62(TBA) >>>>> >>>>> Or58(Suggested by Lou) >>>>> >>>>> >>>>> >>>>> G.709 ODUk (k=2e) >>>>> >>>>> >>>>> >>>>> ditto >>>>> >>>>> >>>>> >>>>> FC-1200 into OPU2e mapping, see clause 17.8.2 >>>>> >>>>> 0x09 >>>>> >>>>> >>>>> >>>>> 63(TBA) >>>>> >>>>> >>>>> >>>>> G.709 ODUk (k=2) >>>>> >>>>> >>>>> >>>>> ditto >>>>> >>>>> >>>>> >>>>> GFP mapping into Extended OPU2 payload, see clause 17.4.1 (Note 6) >>>>> >>>>> 0x0A >>>>> >>>>> >>>>> >>>>> 64(TBA) >>>>> >>>>> >>>>> >>>>> G.709 ODUk (k=0) >>>>> >>>>> >>>>> >>>>> ditto >>>>> >>>>> >>>>> >>>>> STM-1 mapping into OPU0, see clause 17.7.1 >>>>> >>>>> 0x0B >>>>> >>>>> >>>>> >>>>> 65(TBA) >>>>> >>>>> >>>>> >>>>> G.709 ODUk (k=0) >>>>> >>>>> >>>>> >>>>> ditto >>>>> >>>>> >>>>> >>>>> STM-4 mapping into OPU0, see clause 17.7.1 >>>>> >>>>> 0x0C >>>>> >>>>> >>>>> >>>>> 66(TBA) >>>>> >>>>> Or58(Suggested by Lou) >>>>> >>>>> >>>>> >>>>> G.709 ODUk (k=0) >>>>> >>>>> >>>>> >>>>> ditto >>>>> >>>>> >>>>> >>>>> FC-100 mapping into OPU0, see clause 17.7.1 >>>>> >>>>> 0x0D >>>>> >>>>> >>>>> >>>>> 67(TBA) >>>>> >>>>> Or58(Suggested by Lou) >>>>> >>>>> >>>>> >>>>> G.709 ODUk (k=1) >>>>> >>>>> >>>>> >>>>> ditto >>>>> >>>>> >>>>> >>>>> FC-200 mapping into OPU1, see clause 17.7.2 >>>>> >>>>> 0x0E >>>>> >>>>> >>>>> >>>>> 68(TBA) >>>>> >>>>> Or58(Suggested by Lou) >>>>> >>>>> >>>>> >>>>> G.709 ODUflex >>>>> >>>>> >>>>> >>>>> ditto >>>>> >>>>> >>>>> >>>>> FC-400 mapping into OPUflex, see clause 17.9 >>>>> >>>>> 0x0F >>>>> >>>>> >>>>> >>>>> 69(TBA) >>>>> >>>>> Or58(Suggested by Lou) >>>>> >>>>> >>>>> >>>>> G.709 ODUflex >>>>> >>>>> >>>>> >>>>> ditto >>>>> >>>>> >>>>> >>>>> FC-800 mapping into OPUflex, see clause 17.9 >>>>> >>>>> 0x10 >>>>> >>>>> >>>>> >>>>> 51 >>>>> >>>>> >>>>> >>>>> G.709 ODUk >>>>> >>>>> >>>>> >>>>> 1)G-PID defined in RFC4328; >>>>> >>>>> 2) Updated in this draft. >>>>> >>>>> >>>>> >>>>> Bit stream with octet timing mapping, see clause 17.6.1 >>>>> >>>>> 0x11 >>>>> >>>>> >>>>> >>>>> 52 >>>>> >>>>> >>>>> >>>>> G.709 ODUk >>>>> >>>>> >>>>> >>>>> ditto >>>>> >>>>> >>>>> >>>>> Bit stream without octet timing mapping, see clause 17.6.2 >>>>> >>>>> 0x12 >>>>> >>>>> >>>>> >>>>> 70(TBA) >>>>> >>>>> >>>>> >>>>> G.709 ODUflex >>>>> >>>>> >>>>> >>>>> Is being defined in this draft (new payload type defined in [G.709-2012]) >>>>> >>>>> >>>>> >>>>> IB SDR mapping into OPUflex, see 17.9 >>>>> >>>>> 0x13 >>>>> >>>>> >>>>> >>>>> 71(TBA) >>>>> >>>>> >>>>> >>>>> G.709 ODUflex >>>>> >>>>> >>>>> >>>>> ditto >>>>> >>>>> >>>>> >>>>> IB DDR mapping into OPUflex, see 17.9 >>>>> >>>>> 0x14 >>>>> >>>>> >>>>> >>>>> 72(TBA) >>>>> >>>>> >>>>> >>>>> G.709 ODUflex >>>>> >>>>> >>>>> >>>>> ditto >>>>> >>>>> >>>>> >>>>> IB QDR mapping into OPUflex, see 17.9 >>>>> >>>>> 0x15 >>>>> >>>>> >>>>> >>>>> 73(TBA) >>>>> >>>>> >>>>> >>>>> G.709 ODUk (k=0) >>>>> >>>>> >>>>> >>>>> ditto >>>>> >>>>> >>>>> >>>>> SDI mapping into OPU0, see 17.7.1 >>>>> >>>>> 0x16 >>>>> >>>>> >>>>> >>>>> 74(TBA) >>>>> >>>>> >>>>> >>>>> G.709 ODUk (k=1) >>>>> >>>>> >>>>> >>>>> ditto >>>>> >>>>> >>>>> >>>>> (1.485/1.001) Gbit/s SDI mapping into OPU1, see 17.7.2 >>>>> >>>>> 0x17 >>>>> >>>>> >>>>> >>>>> 75(TBA) >>>>> >>>>> >>>>> >>>>> G.709 ODUk (k=1) >>>>> >>>>> >>>>> >>>>> ditto >>>>> >>>>> >>>>> >>>>> 1.485 Gbit/s SDI mapping into OPU1, see 17.7.2 >>>>> >>>>> 0x18 >>>>> >>>>> >>>>> >>>>> 76(TBA) >>>>> >>>>> >>>>> >>>>> G.709 ODUflex >>>>> >>>>> >>>>> >>>>> ditto >>>>> >>>>> >>>>> >>>>> (2.970/1.001) Gbit/s SDI mapping into OPUflex, see 17.9 >>>>> >>>>> 0x19 >>>>> >>>>> >>>>> >>>>> 77(TBA) >>>>> >>>>> >>>>> >>>>> G.709 ODUflex >>>>> >>>>> >>>>> >>>>> ditto >>>>> >>>>> >>>>> >>>>> 2.970 Gbit/s SDI mapping into OPUflex, see 17.9 >>>>> >>>>> 0x1A >>>>> >>>>> >>>>> >>>>> 78(TBA) >>>>> >>>>> Or56(Suggested by Lou) >>>>> >>>>> >>>>> >>>>> G.709 ODUk (k=0) >>>>> >>>>> >>>>> >>>>> ditto >>>>> >>>>> >>>>> >>>>> SBCON/ESCON mapping into OPU0, see 17.7.1 >>>>> >>>>> 0x1B >>>>> >>>>> >>>>> >>>>> 79(TBA) >>>>> >>>>> >>>>> >>>>> G.709 ODUk (k=0) >>>>> >>>>> >>>>> >>>>> ditto >>>>> >>>>> >>>>> >>>>> DVB_ASI mapping into OPU0, see 17.7.1 >>>>> >>>>> 0x20 >>>>> >>>>> >>>>> >>>>> 47 >>>>> >>>>> >>>>> >>>>> G.709 ODUk >>>>> >>>>> >>>>> >>>>> 1) G-PIDs defined in RFC4328. >>>>> >>>>> 2) Updated in this draft. >>>>> >>>>> >>>>> >>>>> ODU multiplex structure supporting ODTUjk only, see clause 19 (AMP only) >>>>> >>>>> 0x21 >>>>> >>>>> >>>>> >>>>> 59/60(TBA) >>>>> >>>>> >>>>> >>>>> G.709 ODUk >>>>> >>>>> >>>>> >>>>> 1)Are being defined in this draft (new payload type defined in >>>>> [G.709-2012]); >>>>> >>>>> 2) 59 for G.709 ODU-1.25G; 60 for G.709 ODU-any >>>>> >>>>> >>>>> >>>>> ODU multiplex structure supporting ODTUk.ts or ODTUk.ts and ODTUjk, see >>>>> clause 19 (GMP capable) (Note 7) >>>>> >>>>> 55 >>>>> >>>>> >>>>> >>>>> None >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Not needed >>>>> >>>>> >>>>> >>>>> Not available (Note 2) >>>>> >>>>> 66 >>>>> >>>>> >>>>> >>>>> None >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Not needed >>>>> >>>>> >>>>> >>>>> Not available (Note 2) >>>>> >>>>> 80-8F >>>>> >>>>> >>>>> >>>>> None >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Not needed >>>>> >>>>> >>>>> >>>>> Reserved codes for proprietary use (Note 4) >>>>> >>>>> FD >>>>> >>>>> >>>>> >>>>> None >>>>> >>>>> OrTBA(Suggested by Lou) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Not needed >>>>> >>>>> >>>>> >>>>> NULL test signal mapping, see clause 17.5.1 >>>>> >>>>> FE >>>>> >>>>> >>>>> >>>>> None >>>>> >>>>> OrTBA(Suggested by Lou) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Not needed >>>>> >>>>> >>>>> >>>>> PRBS test signal mapping, see clause 17.5.2 >>>>> >>>>> FF >>>>> >>>>> >>>>> >>>>> None >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Not needed >>>>> >>>>> >>>>> >>>>> Not available (Note 2) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Best Regards >>>>> >>>>> >>>>> >>>>> Fatai >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf >>>>> Of Lou Berger >>>>> Sent: Tuesday, May 21, 2013 9:17 PM >>>>> To: CCAMP >>>>> Cc: draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>>> Subject: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues) >>>>> >>>>> >>>>> >>>>> All, >>>>> >>>>> >>>>> >>>>> In the interest of moving this discussion quickly to closure, I spent >>>>> >>>>> some time trying to come up with the full list of G.709 PT to G-PID >>>>> >>>>> mappings. In coming up with this list I tried to be consistent with >>>>> >>>>> the last consensus point that I can identify on this topic (the >>>>> >>>>> previously referenced July 2012 thread & presentation), which included: >>>>> >>>>> >>>>> >>>>> A) Defining new G-PIDs for client types not identified by an assigned >>>>> >>>>> G-PID (per >>>>> >>>>> http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parameters.xml) >>>>> >>>>> >>>>> >>>>> B) Reusing G-PID wherever {G-PID, ODU rate} unambiguously identify a >>>>> >>>>> G.709 payload type, and define new G-PIDs when reuse not possible. >>>>> >>>>> >>>>> >>>>> C) No G-PID value for unused, reserved, or proprietary 709 Payload Type. >>>>> >>>>> >>>>> >>>>> Here's what I've come up with: >>>>> >>>>> >>>>> >>>>> G.709 >>>>> >>>>> Payload >>>>> >>>>> Type G-PID Type/Comment LSP Encoding >>>>> >>>>> ==== ===== ============== =================== >>>>> >>>>> 0x01 No standard value >>>>> >>>>> 0x02 49 CBRa G.709 ODUk >>>>> >>>>> 0x03 50 CBRb G.709 ODUk >>>>> >>>>> 0x04 32 ATM G.709 ODUk >>>>> >>>>> 0x05 TBA1 Framed GFP G.709 ODUk >>>>> >>>>> 0x06 ??? Is any valued needed? >>>>> >>>>> 0x07 55 Ethernet PHY G.709 ODUk (k=0) >>>>> >>>>> (transparent G.709 ODUk (k=3) >>>>> >>>>> GFP) G.709 ODUk (k=4) >>>>> >>>>> 0x08 58 Fiber Channel G.709 ODUk (k=2e) >>>>> >>>>> 0x09 TBA1 Framed GFP G.709 ODUk (k=2e) >>>>> >>>>> 0x0A TBA2 STM-1 G.709 ODUk (k=0) >>>>> >>>>> 0x0B TBA3 STM-4 G.709 ODUk (k=0) >>>>> >>>>> 0x0C 58 Fiber Channel G.709 ODUk (k=0) >>>>> >>>>> 0x0D 58 Fiber Channel G.709 ODUk (k=1) >>>>> >>>>> 0x0E 58 Fiber Channel G.709 ODUflex >>>>> >>>>> 0x0F 58 Fiber Channel G.709 ODUflex >>>>> >>>>> 0x10 51 BSOT G.709 ODUk >>>>> >>>>> 0x11 52 BSNT G.709 ODUk >>>>> >>>>> 0x12 TBA4 InfiniBand G.709 ODUflex >>>>> >>>>> 0x13 TBA4 InfiniBand G.709 ODUflex >>>>> >>>>> 0x14 TBA4 InfiniBand G.709 ODUflex >>>>> >>>>> 0x15 TBA5 Serial Digital G.709 ODUk (k=0) >>>>> >>>>> Interface >>>>> >>>>> 0x16 TBA6 Serial Digital G.709 ODUk (k=1) >>>>> >>>>> Interface/1.001 >>>>> >>>>> 0x17 TBA5 Serial Digital G.709 ODUk (k=1) >>>>> >>>>> Interface >>>>> >>>>> 0x18 TBA6 Serial Digital G.709 ODUflex >>>>> >>>>> Interface/1.001 >>>>> >>>>> 0x19 TBA5 Serial Digital G.709 ODUflex >>>>> >>>>> Interface >>>>> >>>>> 0x1A 56 SBCON/ESCON G.709 ODUk (k=0) >>>>> >>>>> (IANA to update Type field) >>>>> >>>>> 0x1B TBA7 DVB_ASI G.709 ODUk (k=0) >>>>> >>>>> 0x1C 58 Fiber Channel G.709 ODUk >>>>> >>>>> 0x20 47 G.709 ODU-2.5G G.709 ODUk >>>>> >>>>> (k=2,3) >>>>> >>>>> (IANA to update Type field) >>>>> >>>>> TBA8 G.709 ODU-1.25G G.709 ODUk >>>>> >>>>> (k=1,2,3) >>>>> >>>>> 0x21 TBA8 G.709 ODU-1.25G G.709 ODUk >>>>> >>>>> (k=2,3,4) >>>>> >>>>> TBA9 G.709 ODU-Any G.709 ODUk >>>>> >>>>> (k=2,3) >>>>> >>>>> 0x55 No standard value >>>>> >>>>> 0x66 No standard value >>>>> >>>>> 0x80-0x8F No standard value >>>>> >>>>> 0xFD TBA10 Null Test G.709 ODUk >>>>> >>>>> 0xFE TBA11 Random Test G.709 ODUk >>>>> >>>>> 0xFF No standard value >>>>> >>>>> >>>>> >>>>> Note that there are a few differences with Fatai's list, which doesn't >>>>> >>>>> format well in e-mail, but is available in the archive >>>>> >>>>> http://www.ietf.org/mail-archive/web/ccamp/current/msg14845.html >>>>> >>>>> >>>>> >>>>> Please speak up if you think the above is not aligned with prior >>>>> >>>>> consensus or if you have an issue with any of the above. >>>>> >>>>> >>>>> >>>>> Much thanks, >>>>> >>>>> Lou >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 5/20/2013 5:09 AM, Fatai Zhang wrote: >>>>> >>>>>> Hi Lou, >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> I think my mail on March 13rd may have answered your following comments. >>>>> >>>>>> My response quoted as follows. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> In addition, if people look at the full list that I provided, I think >>>>> >>>>>> people can realize that RFC4328 (section 3.1.3) used the same approach >>>>> >>>>>> as the current approach of this draft (ie., 1:1 mapping between GPIDs >>>>> >>>>>> and payload types defined by G.709), ie., we are following what RFC4328 >>>>> >>>>>> did. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> BTW, I am not sure if we need spend so much on discussing this point >>>>> >>>>>> (because there is no issue to stick to the data plane by using the >>>>> >>>>>> current approach of this draft). >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> ====================================================================================================================== >>>>> >>>>>> >>>>> >>>>>> (2) 'Grouped GPID' vs '1:1' mapping (between G.709-2012 and GPIDs >>>>> >>>>>> defined in this draft) >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> We realize that it is safe to use 1:1 mapping approach to avoid some >>>>> >>>>>> potential issues after investigation. We know this payload types have >>>>> >>>>>> been defined by G.709 (data plane), so physically it is better to use >>>>> >>>>>> 1:1 mapping approach. >>>>> >>>>>> >>>>> >>>>>> For the potential issues I mentioned above, for example, we cannot use >>>>> >>>>>> the existing 34 to represent 'STM-1' and 'STM-4 ', because it is >>>>> >>>>>> impossible to differentiate which one is 'STM-1' or 'STM-4'. In >>>>> >>>>>> addition, from the concept of payload type, we know that e.g, FC-100 is >>>>> >>>>>> different from FC-800, right? So, it is better to assign different GPIDs >>>>> >>>>>> to these different payload types defined by the data plane. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> Furthermore, I think it is much cheaper to create new GPIDs in the >>>>> >>>>>> control plane than in the data plane (these payload types will be >>>>> >>>>>> carried in the OH). >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> Best Regards >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> Fatai >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> -----Original Message----- >>>>> >>>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>> >>>>>> Sent: Friday, May 17, 2013 11:16 PM >>>>> >>>>>> To: Fatai Zhang >>>>> >>>>>> Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; >>>>> >>>>>> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>>> >>>>>> Subject: Re: R: Closing G.709 open issues >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> Fatai, >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> That's a great start for the WG. Thank you. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> To answer your implied question as to why my request for the full list. >>>>> >>>>>> >>>>> >>>>>> My feeling is that there have been too many "surprises" on the 709 >>>>> >>>>>> >>>>> >>>>>> documents in areas that I thought were either obvious (but from the IETF >>>>> >>>>>> >>>>> >>>>>> & GMPLS context, not ITU-T or G.709 perspectives) or resolved by past >>>>> >>>>>> >>>>> >>>>>> discussions. At this point, as co-chair and Document shepherd, I want >>>>> >>>>>> >>>>> >>>>>> to ensure that any open point on the documents are unambiguously closed >>>>> >>>>>> >>>>> >>>>>> and that past discussions (i.e., points of consensus) are 100% captured, >>>>> >>>>>> >>>>> >>>>>> so that we can smoothly move through the planned second LC and >>>>> >>>>>> >>>>> >>>>>> publication request. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> To that end, in my previous message I asked two questions about points >>>>> >>>>>> >>>>> >>>>>> where it seems you are proposing moving away from what has been >>>>> >>>>>> >>>>> >>>>>> previously been discussed & agreed to by the WG. Can you answer the >>>>> >>>>>> >>>>> >>>>>> following: >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>>>> My questions on the new G-PIDs come down to: >>>>> >>>>>> >>>>> >>>>>>>> - Why are rate specific G-PIDs being proposed (rather than >>>>> >>>>>> >>>>> >>>>>>>> continuing to use the previous approach documented in the draft >>>>> >>>>>> >>>>> >>>>>>>> and in Section 3.1.3 of rfc4328)? >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>>>> - Why are new values being defined rather than using existing >>>>> >>>>>> >>>>> >>>>>>>> values, e.g., G-PID 56? >>>>> >>>>>> >>>>> >>>>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> Much thanks, >>>>> >>>>>> >>>>> >>>>>> Lou >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> >>>>> CCAMP mailing list >>>>> >>>>> CCAMP@ietf.org >>>>> >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>> >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >>> >>> >>> >>> > > > > From internet-drafts@ietf.org Wed May 29 07:11:32 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFFF221F8D94; Wed, 29 May 2013 07:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubyb2XzxSmtR; Wed, 29 May 2013 07:11:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F86021F89FF; Wed, 29 May 2013 07:11:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130529141130.31483.25576.idtracker@ietfa.amsl.com> Date: Wed, 29 May 2013 07:11:30 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-otn-g709-info-model-08.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 14:11:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : Evaluation of existing GMPLS encoding against G.709v3 Op= tical Transport Networks (OTN) Author(s) : Sergio Belotti Pietro Vittorio Grandi Daniele Ceccarelli Diego Caviglia Fatai Zhang Dan Li Filename : draft-ietf-ccamp-otn-g709-info-model-08.txt Pages : 22 Date : 2013-05-29 Abstract: ITU-T recommendation G.709 [G.709-2012] has introduced new fixed and flexible Optical Data Unit (ODU) containers in Optical Transport Networks (OTNs). This document provides an evaluation of existing Generalized Multiprotocol Label Switching (GMPLS) routing and signaling methods against the G.709 [G.709-2012] OTN networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-otn-g709-info-model There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-otn-g709-info-model-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-otn-g709-info-model-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From prvs=1862e30311=daniele.ceccarelli@ericsson.com Thu May 30 04:30:25 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B27021F9512 for ; Thu, 30 May 2013 04:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.993 X-Spam-Level: X-Spam-Status: No, score=-4.993 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, FU_ENDS_2_WRDS=0.255, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z60PQQd5dz1u for ; Thu, 30 May 2013 04:30:20 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6449521F94A6 for ; Thu, 30 May 2013 04:30:16 -0700 (PDT) X-AuditID: c1b4fb30-b7f9e6d000002643-36-51a7383b8175 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id BA.A6.09795.B3837A15; Thu, 30 May 2013 13:30:04 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.55]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Thu, 30 May 2013 13:30:02 +0200 From: Daniele Ceccarelli To: CCAMP Thread-Topic: OTN info-model draft update Thread-Index: Ac5dKQUQe8vG7lNETNGuJWYOCeFFvw== Date: Thu, 30 May 2013 11:30:02 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE480D10C4@ESESSMB301.ericsson.se> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/related; boundary="_005_4A1562797D64E44993C5CBF38CF1BE480D10C4ESESSMB301ericsso_"; type="multipart/alternative" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPIsWRmVeSWpSXmKPExsUyM+Jvra6bxfJAg9vv5CyezLnB4sDosWTJ T6YAxihum6TEkrLgzPQ8fbsE7oynS3ayFixuYqxYdGcbawPj+couRg4OCQETibntLF2MnECm mMSFe+vZQMJCAocZJXb4dzFyAZmLGSWuLv3MChJnE7CSeHLIB6RcREBK4ua+W+wgtrCAikTT 5hnsICUiApoSJ2bGQJToSWzqb2EFsVkEVCV+ftnKBmLzCnhLbL60nhnEZhSQlZiwexEjiM0s IC5x68l8JohrRCQeXjzNBmGLSrx8/I8V4mBFieX9ciCXMQt0M0oc/TYBaqagxMmZT1gmMArN QjJqFrK6WUjqIIryJboXrWaHsHUkFuz+xAZha0ssW/iaGcY+c+AxE6a4l8TDpQ8YIWw7iZuT pkPZOxklfuzOhbCtJZ7PmwY1U1FiSvdDdpje9XOWs8P0vj2/lx3iUKDenhNfmWGa3/R3MSJr XsAotIqRPTcxMye93HwTIzD+D275bbCDcdN9sUOM0hwsSuK8+ryLA4UE0hNLUrNTUwtSi+KL SnNSiw8xMnFwggguqQbGooqgxn9c39bulHRdreW3hFPCZ5XHdL9cnwmilaavxdUfHVrNu/fE hS/ZUXN9zN9eMZvvVLp44XOzD6/Zjf/ytG+1WpZy6YHu1bAlq0ut+jKvds2o6NroM6FgQfgT ZdMXjoWm9wtbb8YIPkzY33S6oTL/qkScZrjtpbMfM56EtWaLnUvk/OunxFKckWioxVxUnAgA rOAt1dICAAA= Subject: [CCAMP] OTN info-model draft update X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 11:30:25 -0000 --_005_4A1562797D64E44993C5CBF38CF1BE480D10C4ESESSMB301ericsso_ Content-Type: multipart/alternative; boundary="_000_4A1562797D64E44993C5CBF38CF1BE480D10C4ESESSMB301ericsso_" --_000_4A1562797D64E44993C5CBF38CF1BE480D10C4ESESSMB301ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi CCAMP, The draft-ietf-ccamp-otn-g709-info-model has been updated so to fix some editori= al issues and the HEX decimal issue reported below #50: Identification of hexadecimal representation in G.709 vs decimal in GM= PLS From: http://www.ietf.org/mail-archive/web/ccamp/current/msg14812.html The authors had previously stated the intent to just make this clear in the signaling document. I'd like to make an alternate proposal: let's do the the obvious and have the documents simply use the normal (IETF) convention of using a '0x' prefix anytime a hexadecimal value is represented. I believe this means that only the info-model draft needs to be updated. BR Daniele (and the authors) DANIELE CECCARELLI System & Technology - DU IP & Broadband PDU Optical & Metro Ericsson Via E.Melen, 77 Genova, Italy Phone +390106002512 Mobile +393346725750 daniele.ceccarelli@ericsson.com www.ericsson.com Legal entity: XOS/N, registered office in TEI. This Communication is Confid= ential. We only send and receive email on the basis of the terms set out at= www.ericsson.com/email_disclaimer --_000_4A1562797D64E44993C5CBF38CF1BE480D10C4ESESSMB301ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi CCAMP,
 
The draft-ietf-ccamp-otn-g709-info-model has been updated so to fix some editorial issues and the HEX decimal issue repo= rted below
 
#50: Identification of hexadecimal represen= tation in G.709 vs decimal in GMPLS
 
 
   The authors had previously sta= ted the intent to just make this clear
   in the signaling document.&nbs= p; I'd like to make an alternate proposal:
   let's do the the obvious and h= ave the documents simply use the normal
   (IETF) convention of using a '= 0x' prefix anytime a hexadecimal value
   is represented. I believe this= means that only the info-model draft
   needs to be updated.
 
 
BR
Daniele (and the authors)
 




DANIELE CECCARELLI
System & Technology - DU IP & Broadband
PDU Optical & Metro

Ericsson
Via E.Melen, 77
Genova, Italy
Phone +390106002512
Mobile +393346725750
daniele.ceccarelli@ericsson.com
www.ericsson.co= m

Legal entity: XOS/N, registered office in TEI. This Communication is = Confidential. We only send and receive email on the basis of the terms set = out at <= font face=3D"Arial" size=3D"1" color=3D"#333333">www.ericsson.com/email_disclaimer
 
 
 --_000_4A1562797D64E44993C5CBF38CF1BE480D10C4ESESSMB301ericsso_-- --_005_4A1562797D64E44993C5CBF38CF1BE480D10C4ESESSMB301ericsso_ Content-Type: image/jpeg; name="Picture (Device Independent Bitmap) 1.jpg" Content-Description: Picture (Device Independent Bitmap) 1.jpg Content-Disposition: inline; filename="Picture (Device Independent Bitmap) 1.jpg"; creation-date="Thu, 30 May 2013 11:30:01 GMT"; modification-date="Thu, 30 May 2013 11:30:01 GMT" Content-ID: <28C104E797AD214B9D53BFC67A58A3AE@ericsson.com> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAA8AEQDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD36iii kAdK5nXvH/hnw4GW/wBUi84D/UQnzHP4D+teYfHLxDrllrdppkFzPa6bJbCTMTFfNfcQwJHXAA49 /evMtE8I6/4kkH9l6ZcTqx5mK7U/76PFdtLCxcVOb0OedZp8sUel6/8AHy6l3RaBpiwr0E92dzfg g4H4k/SuItPiJ40m1+3uo9Zvbi5aRQtsG/dyEn7vlj5eenSuog+E2maFEtz408SW1kuN32aBsuR9 TyfwFbXhzxr8NPD+rw2ml6VLGGYJ/aM0YYg9Mkk5A962Xs4p+zjczfO377se1qSUUkYJHIpaAQRk dDRXmHYFFFFABRRRQBwXxE8d+H/DAhstS04aneOvmx2xRSqjOAzFs45B6AnivINc+MPifVVMFlJF pNr0EdoMNj/fPP5Yr1H4kfC4+MdRh1W11CO0uI4hFL5ykoyAkg8dCMmuH/4R/wCGvg/nWdVk1u+X rb2/3M+h2/4130PZKK0uzlqc997I80trPVdfvitvBdX91IcnarSMfc16P4Z+B2tX08M+uyRWFpuD PCG3yuvpxwufXOR6VDqHxkuba3ay8K6PZ6Pa9AwQFz74HGffmuVsPFvi688R21xbarf3OoPKojj8 1irnP3Sg4x68V0y9rJaWiZJQT11PrZQFUKOgGKWkXJQbuuOaWvHO8KKKKACiiigDwX476jrUOt2V oJZ4tJe3DJsJCSSZO7J7kDbx71wOgeAPE3iTa2n6XKIG/wCXiYeXHj1BPX8M19aywxTrtljSRc5w 6gjNPrrhi3CCjFGEqClK7Z4zoHwDtYtkuv6k87dTBajYn0LHk/hivTtF8LaH4diCaVptvbnu6rlz 9WPJrYorGdac/iZpGnGOyCiiisiwooooA8H8L+NNY1W7iF94m1KKU3vlCCHTxJGy5GMv2zkj2qPx F4+1yx13xHHH4ikt5bK98qys/s4ZJRuxgt2wPWr+iaRPo11Hb6frmqwWzXQkaFJlCMSwzkbe+MVt XPhXT7u08dRzGVhd3ImY5GUZSSNvHH616LUVLVaf8E5FzOO4zUvG2uaN4nlF6Rst/Dy3s1muNv2j Bzz6ZrR8J2fi7VbCw8R3niUv9oXzzp6QqIipBwueoPTmqujeH7PUPElnJetLceZoa2kiyEEOnzLz x1x3rK0izu9A8aQ+HrHW9UGlwykpbvMpAGCdv3entWbimmo7lX1uxvhTxZrN34h8jXtcvbPWDI4T SZrUJDLwdqq3XOab4W8aal/ac8niPXL631OCOeV9HmtRHFIFRmARuueM/h3p3hjTJfEPipJtX1XU L19IV5LTzZF+VvU4XJPAP4VJ4O0k+JPFQuNc1C91FtNjZYFuHUqQwKndhRngmrlGKvddCYtu2pUP iDxmPAo8f/24nl+fn+zfJHleV5nl4z1zn9PepX+I2sWvxEWWaVv+EdZbfz4yoxAJkBVs+xP86jHh C2/4Sr/hDv7R1L+wPP8AP+x+cu3P3sZ25xnt+PXmumfwrpl1rfi2KVXMN1ZRxtGCAqBF+XbxxjA9 aJKC3X/DaDTk9mX/AIZa7qGv+GJ7zULk3EovZY1fAHyDGBx9aKPhlpUGkeEza27yMn2l2zIQTkge gHpRXLVS53Y2g3yo/9k= --_005_4A1562797D64E44993C5CBF38CF1BE480D10C4ESESSMB301ericsso_ Content-Type: image/jpeg; name="Picture (Device Independent Bitmap) 2.jpg" Content-Description: Picture (Device Independent Bitmap) 2.jpg Content-Disposition: inline; filename="Picture (Device Independent Bitmap) 2.jpg"; creation-date="Thu, 30 May 2013 11:30:01 GMT"; modification-date="Thu, 30 May 2013 11:30:01 GMT" Content-ID: <3887A142A350C347A697A35792CBEB87@ericsson.com> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABQAfQDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDpD940 lKeppK/LiQpKKKYBSUUlMQUUlFMkKKKSqEFOplOq4iCiikqrCCikJpKpIkKKKQmqSE2GabmiimSF JmikqkiWwpKKKpIm4UlFJVCFpKKSmIKKKKYBSUUUxBSUUUxBSUUU7CCpEOetNjVWcB22rnk4zgUj kBiFPHaqXcCUnsKSmK3rTs5q0FwooopiCkPSlprGmIaTmk+tHSjpz3oJFbKnng02jrSjGf60AGO5 6UhNOYr5hKA7QeN39aaTTEGPWmlvwFIWqNmoE2KX65ANMoopEhS9PrR05pKYhS3ygcYFNoopgFKB yBkAn17UYxyaPpTEJijgUH3NJx9aBE0USOuWmSM56MDRUP5CiqHc6BuppKU9TTa+aPdFpY43lkWO NGd2OAqjJNNrZ0yQWGj3moIQLkssETd0zySPwrehSVSdpOyV2/RARnw1qwj3fZecZ2b13Y+maynV kco6lWBwQRgg04TSibzhI4lznfuOc+uas6lqH9pSRTPEFnEYWVwf9YR3x9K0mqEotwumu7vf8FYT Gf2dd/aobbyT50yho1yOQelXv+EW1r/nz/8AIqf40niL/j5s/wDrzi/lSeHP+QjL/wBe8n/oNdMK FBV/YyTetr3S/Ri62GXHh3VbW3eea12xoMs3mKcD8DVC6tLiylEdxEY3KhgD3B71DW7YyprNkul3 LAXMY/0SZj/44fb0rOFOjVbjBNPpdp3fbZb9PP1FuYQBZgACSeAB3qe5tZ7OYwXEZjlABKk9MjNa 9pbDQrc6jfR/6XkrawP/AHh1cj0H+e1Yks0lxK8srl5HOWY9SaJ0VTguf4n07Lz83+XqS9ARGlkW NBl2IUD1JpZ4pLed4ZV2yIxVl9CKl08/8TK1/wCuyfzFTa5/yHb7/rs386apr2XP1vb8BdCgAWIA 5J6U+5t5bS4eCdNkqHDLnOKSH/Xx/wC8P51o+Jj/AMVFef7w/wDQRTjTTpOfVNL77/5E9Ljo/DGs yxrIlkdrDIzIg4+hNV73QtS0+38+6tvLjyBu3qeT9DVjxH+/1hnh/eJ5cY3JyPuishkdB8ysPqMV 0VoUYSlCMXp1uv8A5H9QlZaF+y0LUtQg8+1tS8ecbt6rk/iamk8LazHGzvZ4VQST5qdPzpbhhceG 9Ohh/eSxySl0QZK5Ixn0rKa2uFBJglAHJJQ8U3ToxSXK3otbrqv8L/MTsiKkoormSMgpKKSqEFFF JTEFFFFMApKKKYgpKKKYgpKKKYgoFFBPamICew6UlFJTEFKGxSUmM00BKHzS/wA6SLyxIBIWC9yo 5/Coy3PFWK5LTW4+tN3kfWkL569KYXFAJPqTSspRiGBBHUGmrMUYMvBByD6USTtLIzuxZmOSxPU0 aC0AnNB4phfHTrTCxNFybkhamGQ4IB4PamZo6c0XFcUnH1ptFFAgpR+lIBmlNMQhNOiKCRTIpZc8 gHGfxpvH/wCujPpTAUjnPQe9KoBBI7evemdaekpTdhVO5SvIzj6e9NCGg5bmtHU4rCOG3NnM8jsg MoYY2t6CszNBOapOyaGno0JS+9J70UiQooooA6A9TSUN1NJXzp7oVq2VtHeaHepHGrXcLrKMD5in QgfTrWTU1rdTWVws9vIY5F6EVtQnGE7zV07r7+3oK5DVq+sJrDyROVDyxiTYDyoPTNX/APhI5A3m rp9gLj/nsIec+vXrWTcXEt1O808hkkc5Zj3rScaMYvlfM/S1v+CJmp4j/wCPqz/684v5U3w3/wAh KX/r3k/9BqheXst88TShQY41iG0Y4HT8aSyvZbCZpYgpYoyHcMjBGK29tD617XpcL63K9AYqwKkg g5BHakorlRBteK3Z9bbcxOIkxnt8oNYoNT319LqF0biYKHKhflGBwMVWHWujETVStKa2bFJ3Zc0/ /kJ2v/XZP5iptc/5Dt9/12b+dUo5GilSRDhkYMD7itd/EryOXk0rS3djlma3ySfU81vTdN0nCTtr fYLq1jIhP7+P/eH860fE3/Ix3n+8P/QRUF7qZvfLIsrO2MZyDbxbM/XnmoL68kv72W6mCiSQ5IUY HpScoKm4Rd9U/wAH/mS2rWN/XNZv9N1AWlncGGCOJAqKowPlHtWLe6xqGoRCK6uWlQNuCkAc/h9a hvr6XULo3E23eVVflGBwMf0qtWlfEzqTlaT5X0v09BSm2zojfXOneFtPazmaFpZZS5Tq2CAKzX1/ VZEZHv5irAgjPUVJZ67Na2SWjWllcxIxZPtEW8rnrjmnv4h3oy/2RpK7gRlbbkfTmt3VUkrVGtEr a9gcr9TGoopK4jIKKKSmIKKKKYgpKKKYBSUUlMQtJRRTEFFFB44piAnsKSikpiCiik60xBS5wMCj 6UhqgEpelABJAHU9BQMBueadhBj1pjHJ9hT5Cu47RgE8DOaiNDEwopQpYFuw600nNAhM0UUYJoJD r9KTqaU4HHWjNMAx60fhSU9mZyu4lmwFA9qaENJ4wPxoxhc9aQHBGRkDtSE80wCjrSUvQe9AgPoK SkopiCiig+g6UwCiijFAgoo4opgbx6mkpT1NJXzp7oVdjtLV7Jrhrt12MqMvk5wzAkd/9k1RqdZ1 XT5rcg73ljcHthQ4P/oQralyp+8r7/kIfdadcWw3mN2iwpEmw4OQD/XFQz209sVE8Mke4ZG9SM1f j1WOO8muAjtuiiVVb1Rozz7fIai1C+iuIUihzgOXOYlj5IHp1+v6VvOnRs3F/wBXE7Ecml3kbxJ5 Ds0qb1CgnioksbuVpFS2mZozhwEOVPofer8OpWyIqsH+aBYnzCrhSpyMAnkH8KbLqVtcv++M8YSU SIYlUFvlVcHoFPy8EZxk9av2VHdP+v6/yFoVZdOuEto7hY3eJo97OFOF5IwT+H61FJY3cUYkktpV QkAMUOMnpVoajH5sLkSYS1khI68sHA/D5h+tSR6tHFfT3AR23mMqD/ssp59OnFP2dB9bf8NuLQqr ptys3lzxPATHJIN6kZ2KWI/TFQtZ3KW63DW8ohbo5U4P41eS/tLaMxQm4kVhKS0igEFo2QAAE+vJ /SnLqdukxukEpuHVEMTgCMY2985I+XgY4/CqVKjbf+v1+X6Cdim2nXsYG+1mXPTchGeCf5A1B5Mh EZ2N+8OE4+9zjityQi2VBbM7TveCVVlZecA56E5HPU9azNTlja9MduT5EA8uI57Dv+JJP41VSjGC v/X9f8AlqxCLW4O3EL/M5QcdWHUU17W4S3WdoJFhbo5U4P41rTa3DIku2Nw5TcvAwJW3bz9MOcf7 o6VDd6rDPZOiIVkkREceUgA24/i6np0wMe9U6VFJ2kJ27lGKxu7iPzIbaWROfmVCRxSLY3TJG620 pWQ7UIQnceeB69DV+GW1TS7Izyzq0c8jqsQBz931Ix068/SmyarHNdI7rIsZheJwvVdxYkr/AN9e 2eapUqaSu+xNkUJbS5hLiWCRNmC25cYz0p/2C4PlqsMrSuSNgQ9gD/I/hVyPULSN4rdlmls1iMb7 gA7ZbdwMkDBA7+vrSDVY5YnS48wGbzfMdACV3MjAgZGfu4xxwaap0u/9f119QtErS6XdJNFCsMjz PH5hjCHK8kc/l+tV44He4MLK6uA2RtJIIBOMfhWqNWtFxCBI0QgSPfJCrnKsT90nGOfXiqn9oIdW ku2VtjKygADPKFR0wKcoUk1Z9RNRKstncwwpNLBIkb/ddlIB71MNLvGtYbhIWdJiwQKCT8oyf0z+ Rqe7v7eexEY8xpzsyWRVxgY5YH5/xAIotNQgt7WIEyiaMTqNqjH7yMqDnPBBx26flQoU+a19P+D/ AJCtG5Uawu1ikka2lCRnDtsOFPvQ+nXqIrtaTBWYKp2HknoPxq9bahZxWQjYSiTyJIjiNW5bOCGJ yBz0AHrzSJq0aXtzOPOHmeXtK43DaynvkdB70/Z0rLULR7kVvo13LcPFLFLFsjMhJQk49h35qr9g u/ISc20vlOQFfYcHPTmr8+o2pyIlc5gePd5YjBJOR8oJA/D8qVdUtUmN0PPM0iIjx7RsUDbyDnJ+ 7wMDHrxVclLa4rRKX9lagSQLKckdQIzmm/YLhGxNDLFmNpFyh5AGatJqaCZXbzT/AKaLk+4/PrRH qUS2xjZZCxa4OcD/AJaIoHf1U5o5KXcVolSTT7yKMSSWsyoSAGKHBJ6U25srq0Cm4t5YgxwN6kZr SttWjXU5ZgrHzWi2BiBjaynk546dabqSw22mQW8bys3nySYlwGwQozgE+nXPOKbpQ5XKL2/zE4q1 0Zptp0LKYm3KgduOinGD+OR+Yp8un3kLIslrMjOCVDIRkAZP5CtI3xs7GwkZQ1wWRmXcDuiQ7lz6 ZJx/wAVHDqNnakLGbmVJJC8hkUBlyrLxycn5s54zgU/Z0+rDliZ0NldXGPJgkkyMjaueMgZ/Mj86 bBaXF1IY4IZJHXkhVzitFtQtYrCS1tzcHMDRB3ULkmRG6AnAwpHeqlpPAttPa3BlRJWRt8ShiCue MEjIO717ClyQTSuS0r2JLfR7q6GIo38wByyshGNuOPrzjFVWtp0MitE4MahnyOgOMH9R+daa6pak hHNx5Z89Wc4d8OoAPJGTxz0pt3Og0yzilJEswXzipDHy1yE/HB6H+6Kt04W0YNRtoULG2W7uvKaT y1CPIzbd2Aqljx+FLLbREFrSSSdUXdITFt2jIGep45qXTLqOx1HzzJMkYSRA8Y+ddyMoIGRyCQet WxqyQXi3n229vZY0IjFymBk8YPztxgnjvRCMHHXv/XX9BJRtqUV0y/kLCOznYqcMAhODgHB/McUg 06d0g8pHkll3fu1U5XacGtKWawn09mea6SN7xpRgBmztXIOSO5OG/TmmTazb3RmWVJY0n8wOyAFl y4cdxu6c9Kv2dNbsfLHuZjWF5mVRay7oeJPkPycE8+nANRTWV1bxxyTW8saSfcZlIDVfutUiksZL WESld0IVnA+ZUD53AH1cYHPA68VJqurQ3sMgiUq00oldfJRdpGf4hyx+bqcd+Khwp2dmQ1G25Tm0 u6jtIrlIpJIWj8xnVDheSME/h+tRjTL4xxSfZJtkxCxtsPzE9APr2q2NSjje3DJIPJs5bcjHO5lc Dv0yw/Wnyarbhp7qAzi6uFQFGUbIyGVsg5yeVGBgYp8tN63C0DMFrcMsbLA5WQMUOPvBfvY+nemC KUxNMI3MYOC+OB+Nbl3rltNDcxwQyIu3bb5A+QP/AKzPPfJArLsrlLRjNmYyjhVRtqke56ke360p QgnZMlqKdkyoxB6ACkxUtxN587ymONCxzsjXCj6CoupqDNi5/Kkyc5oNJQAUlFAoEKOOaN3y4wPr SE5pKYgoopenJpgABJwBkmgjB54pVcqwZSVI5BFISSSSck9TTAByeMD60h60lAoEGD6UUE0UCN49 TSUrdTTa+fPdCkooppE3CkopCapIQE0lFFVYlsKTNGaSqSJuFJRSE1SQgJxTs5FMoBqkSx1FFJVp CCiikqhBSUUUxBRRSUxBRRSUCCiikpgFFFFUIKSigDNMQo9aQnNBOaSmIKSiimIKcqg5BYDjr/Sm 9PrTkHfNNIQmBuwaUqB+PTFTWts9zPsRlDbS3zNgDAzUWM5Gfr71fLpcZGTzRignuaD79TSJAglQ cfLnAppwOtKW49qjPNAmwzn2FJnnNPkQoq8g7hng5/Oo6CRWYuxZiST1JpKKUccn8KADHarENxFH bTRNArs+Nrnqv0qsTSVSdtgvYDS9BQKQmgQUlFFMkKD6Ufzo4FACUvFJmimA4gg4PGKbSn0pKYgp KKKADrQT2oJ7UlAh27gcDj2optFAz//Z --_005_4A1562797D64E44993C5CBF38CF1BE480D10C4ESESSMB301ericsso_-- From db3546@att.com Thu May 30 07:14:04 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688D121F8607 for ; Thu, 30 May 2013 07:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1paQ4ywTVKQG for ; Thu, 30 May 2013 07:13:57 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 264E721F8DB7 for ; Thu, 30 May 2013 07:13:57 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 4ae57a15.0.164818.00-357.462519.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 30 May 2013 14:13:57 +0000 (UTC) X-MXL-Hash: 51a75ea53fd75f1b-e31c933f9462d26ae51eea3fefa57c09c4e1a3fa Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4UEDufr013131 for ; Thu, 30 May 2013 10:13:56 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4UEDkvj012949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 30 May 2013 10:13:49 -0400 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (misout7msghub9c.itservices.sbc.com [144.151.223.82]) by mlpi409.sfdc.sbc.com (RSA Interceptor) for ; Thu, 30 May 2013 14:13:32 GMT Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([144.151.223.75]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.02.0342.003; Thu, 30 May 2013 10:13:34 -0400 From: "BRUNGARD, DEBORAH A" To: "ccamp@ietf.org" Thread-Topic: Oooops CORRECTION Reply to This - Re: Nomcom 2013-14 Volunteering - 2nd Call Thread-Index: AQHOXLDRM6cae++QQku4lHXhsQsFSZkdxjtQ Date: Thu, 30 May 2013 14:13:34 +0000 Message-ID: References: <639CE511-1B0E-47D8-9D9D-1A48964467E2@verisign.com> In-Reply-To: <639CE511-1B0E-47D8-9D9D-1A48964467E2@verisign.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.214] 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-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=E5V6U9hl c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=RWEAq7CW3jcA:10 a=pAFMNKACsioA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=0o6cAPYUCGUA:10 a=48vgC7mUAAAA:8 a=zCHD0xgTAAAA:8] X-AnalysisOut: [ a=OQnLqqP3Yzrb3Te7jSMA:9 a=CjuIK1q_8ugA:10 a=O36pNhtLwKIA] X-AnalysisOut: [:10 a=lZB815dzVvQA:10 a=HsfL9DrasO0A:10 a=jzD9x5mEi5MUZHUb] X-AnalysisOut: [:21 a=RNpRqFkc2ueWtrF8:21] Subject: [CCAMP] FW: Oooops CORRECTION Reply to This - Re: Nomcom 2013-14 Volunteering - 2nd Call X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 14:14:04 -0000 Please consider volunteering (reply to Allison)- -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Man= kin, Allison Sent: Wednesday, May 29, 2013 5:09 PM To: ietf-announce@ietf.org Cc: Subject: Oooops CORRECTION Reply to This - Re: Nomcom 2013-14 Volunteering = - 2nd Call Sorry - my eye was on entering the reply-to field and then I forgot....apol= ogies in advance for=20 pain that may result from this lapse. On May 29, 2013, at 5:04 PM, "Mankin, Allison" wrote= : > Hi, everyone, >=20 > Remember that I'm challenging the IETF to come up with 200 volunteers for= =20 > the upcoming nomcom. You can volunteer just by hitting Reply to this ema= il. >=20 > What are you waiting for?? The more volunteers we get, the better chance= we > have of choosing a random yet representative cross section of the IETF=20 > population. Respond to the 200-volunteer challenge and hit Reply right n= ow.=20 > (Well, much as I want you to do this, please look below at the posts bein= g > filled and be sure you are willing to forgo trying for any of them this y= ear). >=20 > The official information: > The IETF nominating committee (nomcom) process for 2013-14 is under way. = The=20 > IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, > and the IESG. Ten voting members for the nomcom are selected in a verifia= bly > random way from a pool of volunteers.=20 >=20 > The details of the selection and operation of the nomcom can be found=20 > in RFCs 3777, 5078, 5633, 5680, and 6859. Four of those RFCs (3777, 563= 3,=20 > 5680 and 6859) comprise BCP 10. We will also reference RFC 3797. >=20 > Volunteers must have attended 3 of the past 5 IETF meetings. As specifie= d in > RFC 3777, that means three out of the five past meetings up to the time t= his > email announcement goes out to start the solicitation of volunteers. The = five > meetings out of which you must have attended three are IETF 82, 83, 84, 8= 5, 86. >=20 > If you qualify, reply to this email and volunteer. =20 >=20 > The list of people and posts whose terms end with the March 2014 IETF > meeting, and thus the positions for which this nomcom is responsible, are > IAOC: > Chris Griffiths >=20 > IAB: > Bernard Aboba > Marc Blanchet > Ross Callon > Eliot Lear > Hannes Tschofenig >=20 > IESG: > Barry Leiba (Applications) > Brian Haberman (Internet) > Benoit Claise (Operations and Management) > Gonzalo Camarillo (RAI) > Stewart Bryant (Routing) > Sean Turner (Security) > Martin Stiemerling (Transport) >=20 > The primary activity for this nomcom will begin in July 2013 and should b= e > completed in January 2014. Being a nomcom member will require some time > commitment - there will be interviews with candidates at meetings, regula= rly > scheduled conference calls to ensure progress, collection and review of=20 > requirements from the commitment, review of candidate questionnaires and > of community feedback. A more detailed timetable for the nomcom tasks > will appear soon. >=20 > Please respond to this email before 11:59 pm EDT (UTC -4 hours)=20 > June 16, 2013. In the body include:=20 > 1. your Given Name as you enter it when you register for the IETF > 2. your Family Name as you enter it when you register for the IETF > 3. your current primary affilation (the information you enter into the Co= mpany field) > 4. any/all email addresses you've used to register for IETF meetings=20 > 5. which email address you prefer=20 > 6. your phone number (for our use in confirming you if selected). >=20 > You should expect an email response from me within 3 business days statin= g > whether or not you are qualified (and added to the list). If you don't r= eceive this > response, please re-send your email adding the tag "RESEND" to the subjec= t line. >=20 > Participating in the IETF nomcom is a meaningful and fun way to contribut= e to the IETF. =20 > Please help us meet the 200-volunteer challenge by hitting Reply to this = message today. =20 >=20 > Allison=20 >=20 > Allison Mankin > Nomcom Chair 2013-2014 From db3546@att.com Thu May 30 11:12:28 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0DC321F8EC2 for ; Thu, 30 May 2013 11:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vjKJj7ajHss for ; Thu, 30 May 2013 11:12:23 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id BBAAD21F8EEC for ; Thu, 30 May 2013 11:12:22 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 68697a15.0.313288.00-361.890635.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 30 May 2013 18:12:22 +0000 (UTC) X-MXL-Hash: 51a796861df9e08a-7adaa653538767e7a5fa9cd76dc3ff9e6061aacc Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4UICLJi005967 for ; Thu, 30 May 2013 14:12:21 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4UIC7Cn005791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 30 May 2013 14:12:15 -0400 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by mlpi409.sfdc.sbc.com (RSA Interceptor) for ; Thu, 30 May 2013 18:11:46 GMT Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([144.151.223.75]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.02.0342.003; Thu, 30 May 2013 14:11:48 -0400 From: "BRUNGARD, DEBORAH A" To: "ccamp@ietf.org" Thread-Topic: Liaison response to BBF Thread-Index: Ac5dYUQlbdtY5fyZThuYyU68SN8OCg== Date: Thu, 30 May 2013 18:11:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.214] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C82E3025MISOUT7MSGUSR9OIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=AaYG6QrG c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=RWEAq7CW3jcA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=x1HveOwAWuIA:10 a=48vgC7mUA] X-AnalysisOut: [AAA:8 a=lt41-9NqRrI0to9vX64A:9 a=CjuIK1q_8ugA:10 a=uW9MgrU] X-AnalysisOut: [FsTK3N7AD5PAA:9 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 a=xIuC] X-AnalysisOut: [OJFq5JEW-27B:21] Subject: [CCAMP] Liaison response to BBF X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 18:12:28 -0000 --_000_F64C10EAA68C8044B33656FA214632C82E3025MISOUT7MSGUSR9OIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The following liaison was sent to BBF, ccamp was inadvertently left off the= cc list: https://datatracker.ietf.org/liaison/1257/ --_000_F64C10EAA68C8044B33656FA214632C82E3025MISOUT7MSGUSR9OIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The following liaison was sent to BBF, ccamp was inadvertently left of= f the cc list:
 
 
 --_000_F64C10EAA68C8044B33656FA214632C82E3025MISOUT7MSGUSR9OIT_-- From internet-drafts@ietf.org Fri May 31 02:36:07 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD43621F9703; Fri, 31 May 2013 02:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEJkr69DsN4H; Fri, 31 May 2013 02:36:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F7821F96FB; Fri, 31 May 2013 02:36:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130531093607.1919.90207.idtracker@ietfa.amsl.com> Date: Fri, 31 May 2013 02:36:07 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-signaling-g709v3-09.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 09:36:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : Generalized Multi-Protocol Label Switching (GMPLS) Signa= ling Extensions for the evolving G.709 Optical Transport Networks Control Author(s) : Fatai Zhang Guoying Zhang Sergio Belotti Daniele Ceccarelli Khuzema Pithewan Filename : draft-ietf-ccamp-gmpls-signaling-g709v3-09.txt Pages : 28 Date : 2013-05-31 Abstract: ITU-T Recommendation G.709 [G709-2012] has introduced new Optical channel Data Unit (ODU) containers (ODU0, ODU4, ODU2e and ODUflex) and enhanced Optical Transport Networking (OTN) flexibility. This document updates RFC4328 to provide the extensions to the Generalized Multi-Protocol Label Switching (GMPLS) signaling to control the evolving OTN addressing ODUk multiplexing and new features including ODU0, ODU4, ODU2e and ODUflex. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-signaling-g709v3 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-signaling-g709v3-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-gmpls-signaling-g709v3-= 09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From zhangfatai@huawei.com Fri May 31 02:43:41 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 532CE21F941F for ; Fri, 31 May 2013 02:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XPMXiWu0F3y for ; Fri, 31 May 2013 02:43:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id BEDC721F91CA for ; Fri, 31 May 2013 02:43:36 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARZ02939; Fri, 31 May 2013 09:43:36 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 31 May 2013 10:42:59 +0100 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 31 May 2013 10:43:32 +0100 Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.235]) by szxeml411-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.007; Fri, 31 May 2013 17:43:27 +0800 From: Fatai Zhang To: "ccamp@ietf.org" Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-signaling-g709v3-09.txt Thread-Index: AQHOXeJaNUUfCxCzWEKhXR4kX1lVdZkfChVQ Date: Fri, 31 May 2013 09:43:27 +0000 Message-ID: References: <20130531093607.1919.90207.idtracker@ietfa.amsl.com> In-Reply-To: <20130531093607.1919.90207.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-signaling-g709v3-09.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 09:43:41 -0000 Hi all, A new version has been submitted to address the comments from the following= mail. Thanks very much for Lou's suggestions. http://www.ietf.org/mail-archive/web/ccamp/current/msg14812.html=09 Best Regards Fatai -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org Sent: Friday, May 31, 2013 5:36 PM To: i-d-announce@ietf.org Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-signaling-g709v3-09.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : Generalized Multi-Protocol Label Switching (GMPLS) Signa= ling Extensions for the evolving G.709 Optical Transport Networks Control Author(s) : Fatai Zhang Guoying Zhang Sergio Belotti Daniele Ceccarelli Khuzema Pithewan Filename : draft-ietf-ccamp-gmpls-signaling-g709v3-09.txt Pages : 28 Date : 2013-05-31 Abstract: ITU-T Recommendation G.709 [G709-2012] has introduced new Optical channel Data Unit (ODU) containers (ODU0, ODU4, ODU2e and ODUflex) and enhanced Optical Transport Networking (OTN) flexibility. This document updates RFC4328 to provide the extensions to the Generalized Multi-Protocol Label Switching (GMPLS) signaling to control the evolving OTN addressing ODUk multiplexing and new features including ODU0, ODU4, ODU2e and ODUflex. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-signaling-g709v3 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-signaling-g709v3-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-gmpls-signaling-g709v3-= 09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From lberger@labn.net Fri May 31 09:08:21 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9F121F8808 for ; Fri, 31 May 2013 09:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.666 X-Spam-Level: X-Spam-Status: No, score=-99.666 tagged_above=-999 required=5 tests=[IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qmeVShMNZKU for ; Fri, 31 May 2013 09:08:16 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 2C4DA21F8C08 for ; Fri, 31 May 2013 09:08:12 -0700 (PDT) Received: (qmail 2406 invoked by uid 0); 31 May 2013 16:07:47 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.bluehost.com with SMTP; 31 May 2013 16:07:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=2S4gk4cIjEhDKQCZGG4/pDMT6Xiin/6lkY3oLaUKwxg=; b=TLKX9Db6U4fBxaRnrFA0uB3EXlgyWHtFXwOufYYb4/ITmF/O5JniQiQ+PaklO9EX/7UPWu9xVE75EzQg866k4DbUwcIFGbG6iPey8/BQThBmkXfhqS2l0WpOjlTt4+Tc; Received: from box313.bluehost.com ([69.89.31.113]:34168 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UiRrn-00006X-H2; Fri, 31 May 2013 10:07:47 -0600 Message-ID: <51A8CAD3.70609@labn.net> Date: Fri, 31 May 2013 12:07:47 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: jonathan.sadler@tellabs.com References: <5065B22D.5050808@labn.net> <508819E1.1080203@labn.net> In-Reply-To: <508819E1.1080203@labn.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-otn-g709-info-model X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 16:08:22 -0000 Jonathan, I can find no record of you responding to this. Can you please respond to this message (and leave CCAMP cc'ed) and answer the questions listed below? Thank you, Lou On 10/24/2012 12:40 PM, Lou Berger wrote: > Hello, > If you are listed on the to line you are listed in the above draft as > an Author or Contributor and I believe have not responded to the message > included below. > > Can you please respond to this message (and leave CCAMP cc'ed). And > state either: > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" > > If you answer yes, please also state: > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" > > If you answer no, please provide any additional details you think > appropriate. > > Thank you, > Lou > > On 9/28/2012 10:20 AM, Lou Berger wrote: >> Authors, Contributors, (CCAMP) >> >> As part of the preparation for WG Last Call: >> >> Are you aware of any IPR that applies to >> draft-ietf-ccamp-otn-g709-info-model? >> >> If so, has this IPR been disclosed in compliance with IETF IPR rules >> (see RFCs 3979, 4879, 3669 and 5378 for more details)? >> >> If you are listed as a document author or contributor please answer the >> above by responding to this email regardless of whether or not you are >> aware of any relevant IPR. This document will not advance to the next >> stage until a response has been received from each author and listed >> contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS >> MESSAGE'S TO LINES. >> >> If you are on the CCAMP WG email list but are not listed as an author or >> contributor, we remind you of your obligations under the IETF IPR rules >> which encourages you to notify the IETF if you are aware of IPR of >> others on an IETF contribution, or to refrain from participating in any >> contribution or discussion related to your undisclosed IPR. For more >> information, please see the RFCs listed above and >> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. >> >> Thank you, >> CCAMP WG Chairs >> >> PS Please include all listed in the headers of this message in your >> response. >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > > From lberger@labn.net Fri May 31 09:11:56 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9376621F9260 for ; Fri, 31 May 2013 09:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.666 X-Spam-Level: X-Spam-Status: No, score=-99.666 tagged_above=-999 required=5 tests=[IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8Ci1bNPkAGH for ; Fri, 31 May 2013 09:11:52 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 0E91721F8E8C for ; Fri, 31 May 2013 09:11:46 -0700 (PDT) Received: (qmail 5912 invoked by uid 0); 31 May 2013 16:11:11 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy6.bluehost.com with SMTP; 31 May 2013 16:11:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=0mG9Eq+0Ve0rsaRcqGBJNCPABsen6X+F4k/6Bxx2Foc=; b=RbquKRxIXW5TPfDBD086yBH/V+R0DRis+8A8GMUN3kKFDh7DAxzILKy/7INXzyBbr1URZC06kwwDkywrWJskc7L/+0upBsed2gtHVR3lfVlDRoedIO1BToS1Ci/jxyYw; Received: from box313.bluehost.com ([69.89.31.113]:34640 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UiRv5-0002C0-D8 for ccamp@ietf.org; Fri, 31 May 2013 10:11:11 -0600 Message-ID: <51A8CB9D.40009@labn.net> Date: Fri, 31 May 2013 12:11:09 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: CCAMP X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: [CCAMP] 2nd WG Last Call: g709-framework, g709-info-model, ospf-g709v3, signaling-g709v3 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 16:11:56 -0000 This mail begins a 2nd two week working group last call on: http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-g709-framework-12 (Informational) http://tools.ietf.org/html/draft-ietf-ccamp-otn-g709-info-model-08 (Informational) http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ospf-g709v3-06 (Standards Track) http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-signaling-g709v3-09 (Standards Track) This working group last call ends on June 16. Comments should be sent to the CCAMP mailing list. Please remember to include the technical basis for any comments. Please note that we're still missing an IPR statement on the 2nd draft. Any forthcoming publication request will be delayed by late IPR statements/disclosures. Thank you, Lou (and Deborah)